From: Aidan MacDonald <aidanmacdonald.0x0@gmail.com>
To: Paul Cercueil <paul@crapouillou.net>
Cc: alsa-devel@alsa-project.org, Zhou Yanjie <zhouyu@wanyeetech.com>,
lgirdwood@gmail.com, linux-kernel@vger.kernel.org,
tiwai@suse.com, linux-mips@vger.kernel.org, broonie@kernel.org
Subject: Re: [PATCH v4 07/11] ASoC: jz4740-i2s: Make the PLL clock name SoC-specific
Date: Tue, 25 Oct 2022 10:20:10 +0100 [thread overview]
Message-ID: <ebyFOPJskfdtIoKsYnqp2IcYTMYA1ESE@localhost> (raw)
In-Reply-To: <DQD9KR.BW8U6333OSCP3@crapouillou.net>
Paul Cercueil <paul@crapouillou.net> writes:
> Hi Aidan,
>
> Le dim. 23 oct. 2022 à 14:29:24 +0100, Aidan MacDonald
> <aidanmacdonald.0x0@gmail.com> a écrit :
>> Paul Cercueil <paul@crapouillou.net> writes:
>>
>>> Hi Aidan,
>>> Le sam. 22 oct. 2022 à 18:15:05 +0100, Aidan MacDonald
>>> <aidanmacdonald.0x0@gmail.com> a écrit :
>>>> Actually, the clock names in the DT are meaningless. The clk_get() call
>>>> matches only the clock's name in the CGU driver. So in fact the driver
>>>> is "broken" for jz4780. It seems jz4770 doesn't work correctly either,
>>>> it has no "pll half", and three possible parents for its "i2s" clock.
>>> That's not true. The clock names are matched via DT.
>>> Only in the case where a corresponding clock cannot be found via DT will it
>>> search for the clock name among the clock providers. I believe this is a
>>> legacy
>>> mechanism and you absolutely shouldn't rely on it.
>>> -Paul
>>>
>> What you say is only true for clk_get() with a device argument. When the
>> device argument is NULL -- which is the case in .set_sysclk() -- then
>> the DT name is not matched. Check drivers/clk/clkdev.c, in clk_find().
>> When the dev_id is NULL, it will not match any lookup entries with a
>> non-null dev_id, and I believe dev_id is the mechanism that implements
>> DT clock lookup. Only the wildcard entries from the CGU driver will be
>> matched if dev_id is NULL, so the DT is being ignored.
>> If you don't believe me, try changing "pll half" in the device tree and
>> the I2S driver to something else. I have done this, and it doesn't work.
>> That proves the name in the device tree is not being used.
>
> Well, let's pass them a device pointer then.
>
Yes, I'll do that when I revise the patch.
>> I agree we shouldn't rely on this, it's a legacy behavior, but the fact
>> is that's how the driver already works. I'm dropping this patch because
>> the driver is wrong and needs a different fix...
>
> "How the driver already works" is a bit misleading, I never saw this
> .set_sysclk() callback being called, so I can't really say that it works.
>
>>>> I think a better approach is to have the DT define an array of parent
>>>> clocks for .set_sysclk()'s use, instead of hardcoding parents in the
>>>> driver. If the parent array is missing the driver can default to using
>>>> "ext" so existing DTs will work.
>> As much as I like this idea there doesn't seem to be a mechanism for
>> handling a free-floating array of clocks in the DT. Everything has
>> to be put in the main "clocks" array. That makes it pretty hard to
>> figure out which ones are meant to be the parent clocks.
>> Do you know of any way to do this generically from the DT? If there's
>> no way to get away from a hardcoded array of names in the driver, I can
>> at least add a device argument to clk_get() so it'll use the DT names.
>
> In jz4740_i2s_set_sysclk():
>
> #define JZ4740_I2S_FIRST_PARENT_CLK 2
> parent = of_clk_get(dev->of_node, JZ4740_I2S_FIRST_PARENT_CLK + clk_id);
>
> is how I'd do it.
>
> The DTs all have "aic", "i2s" as the first two clocks. It is even enforced in
> the DT schemas.
>
> Cheers,
> -Paul
Sounds like a plan. I was hoping to avoid adding CONFIG_OF back
considering I removed it in an earlier patch since it was unused. :)
Guess it doesn't really matter for this driver since the Ingenic
SoCs need CONFIG_OF anyway.
Regards,
Aidan
next prev parent reply other threads:[~2022-10-25 9:21 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-08 16:02 [PATCH v4 00/11] ASoC: cleanups and improvements for jz4740-i2s Aidan MacDonald
2022-07-08 16:02 ` [PATCH v4 01/11] ASoC: jz4740-i2s: Handle independent FIFO flush bits Aidan MacDonald
2022-07-20 11:44 ` Paul Cercueil
2022-07-20 14:43 ` Aidan MacDonald
2022-07-21 10:08 ` Paul Cercueil
2022-10-22 15:43 ` Aidan MacDonald
2022-07-08 16:02 ` [PATCH v4 02/11] ASoC: jz4740-i2s: Remove unused 'mem' resource Aidan MacDonald
2022-07-20 11:44 ` Paul Cercueil
2022-07-08 16:02 ` [PATCH v4 03/11] ASoC: jz4740-i2s: Convert to regmap API Aidan MacDonald
2022-07-20 12:05 ` Paul Cercueil
2022-07-08 16:02 ` [PATCH v4 04/11] ASoC: jz4740-i2s: Simplify using regmap fields Aidan MacDonald
2022-07-20 11:50 ` Paul Cercueil
2022-07-08 16:02 ` [PATCH v4 05/11] ASoC: jz4740-i2s: Use FIELD_PREP() macros in hw_params callback Aidan MacDonald
2022-07-20 11:52 ` Paul Cercueil
2022-07-08 16:02 ` [PATCH v4 06/11] ASoC: jz4740-i2s: Align macro values and sort includes Aidan MacDonald
2022-07-08 16:02 ` [PATCH v4 07/11] ASoC: jz4740-i2s: Make the PLL clock name SoC-specific Aidan MacDonald
2022-07-13 14:33 ` Zhou Yanjie
2022-07-13 15:07 ` Paul Cercueil
2022-07-13 15:29 ` Zhou Yanjie
2022-10-22 17:15 ` Aidan MacDonald
2022-10-22 20:03 ` Paul Cercueil
2022-10-23 13:29 ` Aidan MacDonald
2022-10-24 13:06 ` Paul Cercueil
2022-10-25 9:20 ` Aidan MacDonald [this message]
2022-07-20 11:53 ` Paul Cercueil
2022-07-08 16:02 ` [PATCH v4 08/11] ASoC: jz4740-i2s: Support S20_LE and S24_LE sample formats Aidan MacDonald
2022-07-20 11:56 ` Paul Cercueil
2022-07-08 16:02 ` [PATCH v4 09/11] ASoC: jz4740-i2s: Support continuous sample rate Aidan MacDonald
2022-07-08 16:02 ` [PATCH v4 10/11] ASoC: jz4740-i2s: Move component functions near the component driver Aidan MacDonald
2022-07-20 11:58 ` Paul Cercueil
2022-07-08 16:02 ` [PATCH v4 11/11] ASoC: jz4740-i2s: Refactor DAI probe/remove ops as component ops Aidan MacDonald
2022-07-20 12:04 ` Paul Cercueil
2022-07-20 23:12 ` (subset) [PATCH v4 00/11] ASoC: cleanups and improvements for jz4740-i2s Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ebyFOPJskfdtIoKsYnqp2IcYTMYA1ESE@localhost \
--to=aidanmacdonald.0x0@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=paul@crapouillou.net \
--cc=tiwai@suse.com \
--cc=zhouyu@wanyeetech.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).