From nobody Wed Oct 25 01:49:20 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SFX0t1xzsz4xpLm for ; Wed, 25 Oct 2023 01:49:34 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SFX0t00Y3z3d7p for ; Wed, 25 Oct 2023 01:49:33 +0000 (UTC) (envelope-from ganbold@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-xd32.google.com with SMTP id ca18e2360f4ac-7a94c5538aeso103137439f.3 for ; Tue, 24 Oct 2023 18:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698198572; x=1698803372; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5sYe1MHTq6zJ90p9eF3UxweeQp1hv96IiX7IKLAHM5U=; b=Nez+2DKmuOh2GIwkNPEH+Fa2RfuBy8dbUyYpL/cDfbt5iutR68kH2iTATcKTu95LNw WTw8zmv/LmxN+n2X+Ch8vWVSymSSfWnkQgqCwckv88826QwCwXoL43F1+zSNKx+99H8j 8VghZq0+o5nrcN5hXztYQtYAv9onpz2oUfls96HCujI4vHZOT25FsuAIM08PLwNGt+4Y UvyZyuxHkw74C/yuH/IKgDpQRWJ1eOnJSIixslBPeJbxd8S9FGx3bQCBkR9XZB21MoUO JguSOg0KJIVuZEccvskdk454CiXMYZmHhUSPt1kcsHqGwkYxQf0AptWMN2kQlqg0+4l6 QCRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698198572; x=1698803372; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5sYe1MHTq6zJ90p9eF3UxweeQp1hv96IiX7IKLAHM5U=; b=kxhUXBd4EQ2ryAGKwvb8mVW7yCQBeycMMy5qyWu4ZA5NerCfcXO7W3Am4uC2j/FBRD fUP79M8hz00bImnq8SRHUuxQi7MxAiTTNT2w6Fm6Nd6NtvVCmdrr2T4WlEHq4g6jJ6ZB nosPQcdHJ4iokVuBRjp8evBXbk4tbVql4wXM0b5tdTxv9Ee5XyQm0QGAKxbCaAsKq7WL LrCyXqf09MjWrAisIsegOHsDLSFtG52xVB0+zpj9q5wWylk7UiWdouBkwdll97IoNR3q F6MBPIxE9eqVbeAtI25RkVGezsukVWdbwG5FwhTADdsg5bUTVMyJBjz5Jx/SuPNYXebq uUgA== X-Gm-Message-State: AOJu0YzdDRu3kHWHnzrWo5gWDXRjdISxkFnaj3ff3Tcyrl/6CBRc6991 m1Pm+2mASfgiQveumL+510jIKFeNTvRHLRVFXcjZIZ90E2Q= X-Google-Smtp-Source: AGHT+IHtMIiAoR4b6V0qHher4xY4N7kZ2LZey6DyXspRW8HNvdeCx9YrXO05CL9IQpXBbAQKc4/MeJ1Gn9VSm3+uGkU= X-Received: by 2002:a05:6602:154a:b0:7a6:7bbe:5aa0 with SMTP id h10-20020a056602154a00b007a67bbe5aa0mr17164694iow.0.1698198572652; Tue, 24 Oct 2023 18:49:32 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ganbold Tsagaankhuu Date: Wed, 25 Oct 2023 09:49:20 +0800 Message-ID: Subject: Re: RK3568 clock tree problems To: titus Cc: freebsd-arm Content-Type: multipart/alternative; boundary="000000000000ae613a060880aabb" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4SFX0t00Y3z3d7p --000000000000ae613a060880aabb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 25, 2023 at 4:43=E2=80=AFAM titus wrote: > while trying to make emmc work on an opi 3b i spotted some possible > problems with the clock tree / drivers > > the problems won=E2=80=99t surface if you don=E2=80=99t want to set to ma= ny frequencies > but still > > rk_clk_mux.c > will select any bogus frequency from the last parent if the initial > set_clock_freq call had ROUND_UP or ROUND_DOWN flag > because it does not keeps a best frequency > > rk_clk_mux.c may select a =E2=80=9CBUSY=E2=80=9D parent if the parent cho= sen is busy and > it need its freq adjusted and the function will fail but return succes > because the > last call that sets the parent freq will ignore return code (the set_freq > function succeeds when DRYRUN is set even if the clock is busy) > > rk_clk_composite will not try to find a good frequency starting with the > current parent but with the first one and may change parent > when only changing the div is possible > > neither of the above will stop searching if the required freq is reached > > rk3568_cru has incorrect div with definitions for some clocks which make > their designed frequency unconfigurable > ex div25m with a parent of 1GHz has a div width of 5 bits instead of 6 > > > i have some rough/wip patches if anyone needs them > Does eMMC work with your patches? In any case please submit them into phab https://reviews.freebsd.org/ so that they are reviewed and not lost. thanks, Ganbold --000000000000ae613a060880aabb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 25, 2023 at 4:43=E2=80=AF= AM titus <titus@edc.ro= > wrote:
= while trying to make emmc work on an opi 3b=C2=A0 i spotted some possible p= roblems with the clock tree / drivers

the problems won=E2=80=99t surface if you don=E2=80=99t want to set to many= frequencies but still

rk_clk_mux.c
will select any bogus frequency from the last parent if the initial set_clo= ck_freq call had ROUND_UP or ROUND_DOWN flag
because it does not keeps a best frequency

rk_clk_mux.c may select a =E2=80=9CBUSY=E2=80=9D parent if the parent chose= n is busy and it need its freq adjusted and the function will fail but retu= rn succes because the
last call that sets the parent freq will ignore return code (the set_freq f= unction succeeds when DRYRUN is set even if the clock is busy)

rk_clk_composite will not try to find a good frequency starting with the cu= rrent parent but with the first one and may change parent
when only changing the div is possible

neither of the above will stop searching if the required freq is reached
rk3568_cru has incorrect div with definitions for some clocks which make th= eir designed frequency unconfigurable
ex div25m with a parent of 1GHz has a div width of 5 bits instead of 6


i have some rough/wip patches if anyone needs them

Does eMMC work with your patches?
In a= ny case please submit them into phab https://reviews.freebsd.org/ so that they are reviewed and not lost.=

thanks,

Ganbold


--000000000000ae613a060880aabb--