Re: Questions regarding regarding idt/renesas versaclock5 driver

Re: Questions regarding regarding idt/renesas versaclock5 driver

[Sean Anderson]

On 2/28/22 7:35 AM, Fillion, Claude wrote:
> 	
> You don't often get email from claude.fillion@mksinst.com. Learn why this is important <http://aka.ms/LearnAboutSenderIdentification>
> 	
> 
> Hello  Sean,
> 
>  
> 
> I have a design that is looking to use the Renesas 5P49V6965 or 5P49V690 clock chip and am looking to use the versaclock 5 driver (https://github.com/Xilinx/linux-xlnx/blob/master/drivers/clk/clk-versaclock5.c).
> 
>  
> 
> I am new to writing drivers and have two questions I am hoping you can help me with:
> 
> 1) In the driver I see the following code:
> 
> static const struct vc5_chip_info idt_5p49v6901_info = {
> 
>             .model = IDT_VC6_5P49V6901,
> 
>             .clk_fod_cnt = 4,
> 
>             .clk_out_cnt = 5,
> 
>             .flags = VC5_HAS_PFD_FREQ_DBL,
> 
> };
> 
>  
> 
> static const struct vc5_chip_info idt_5p49v6965_info = {
> 
>             .model = IDT_VC6_5P49V6965,
> 
>             .clk_fod_cnt = 4,
> 
>             .clk_out_cnt = 5,
> 
>             .flags =  VC5_HAS_BYPASS_SYNC_BIT,
> 
> };
> 
>  
> 
> However, the 6965 part also has the same frequency doubling bit as the 6901.  Would it be better to set the flags for the 6965 to something like this?
> 
>  
> 
> static const struct vc5_chip_info idt_5p49v6965_info = {
> 
>             .model = IDT_VC6_5P49V6965,
> 
>             .clk_fod_cnt = 4,
> 
>             .clk_out_cnt = 5,
> 
>             .flags = VC5_HAS_PFD_FREQ_DBL | VC5_HAS_BYPASS_SYNC_BIT,
> 
> };

I think Adam will have a better idea about this.

> 2) I am unclear how to set the output frequencies for the device. For my application I would like to set output clock 1 to 250MHz and output clock 2 to 46.8MHz but I am unclear how to do so.  I have looked at the documentation at https://mjmwired.net/kernel/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml but remain unclear how to set the output frequencies.  Any insight you could provide would be greatly appreciated.

Use assigned-clock-frequencies as described in
Documentation/devicetree/bindings/clock/clock-bindings.txt


> I saw your name mentioned so I am emailing  you directly.  If there is a better place to ask these questions can you please direct me there?  Thanks you so much.

Adam (CC'd) wrote the original driver, so he's probably a
better person to start with. You should also CC the linux-clk
mailing list for questions about clock drivers.

--Sean

Re: Questions regarding regarding idt/renesas versaclock5 driver

[Adam Ford]

On Mon, Feb 28, 2022 at 10:04 AM Sean Anderson <sean.anderson@seco.com> wrote:
>
>
>
> On 2/28/22 7:35 AM, Fillion, Claude wrote:
> >
> > You don't often get email from claude.fillion@mksinst.com. Learn why this is important <http://aka.ms/LearnAboutSenderIdentification>
> >
> >
> > Hello  Sean,
> >
> >

+ Luca Ceresoli

> >
> > I have a design that is looking to use the Renesas 5P49V6965 or 5P49V690 clock chip and am looking to use the versaclock 5 driver (https://github.com/Xilinx/linux-xlnx/blob/master/drivers/clk/clk-versaclock5.c).
> >
> >
> >
> > I am new to writing drivers and have two questions I am hoping you can help me with:
> >
> > 1) In the driver I see the following code:
> >
> > static const struct vc5_chip_info idt_5p49v6901_info = {
> >
> >             .model = IDT_VC6_5P49V6901,
> >
> >             .clk_fod_cnt = 4,
> >
> >             .clk_out_cnt = 5,
> >
> >             .flags = VC5_HAS_PFD_FREQ_DBL,
> >
> > };
> >
> >
> >
> > static const struct vc5_chip_info idt_5p49v6965_info = {
> >
> >             .model = IDT_VC6_5P49V6965,
> >
> >             .clk_fod_cnt = 4,
> >
> >             .clk_out_cnt = 5,
> >
> >             .flags =  VC5_HAS_BYPASS_SYNC_BIT,
> >
> > };
> >
> >
> >
> > However, the 6965 part also has the same frequency doubling bit as the 6901.  Would it be better to set the flags for the 6965 to something like this?
> >
> >
> >
> > static const struct vc5_chip_info idt_5p49v6965_info = {
> >
> >             .model = IDT_VC6_5P49V6965,
> >
> >             .clk_fod_cnt = 4,
> >
> >             .clk_out_cnt = 5,
> >
> >             .flags = VC5_HAS_PFD_FREQ_DBL | VC5_HAS_BYPASS_SYNC_BIT,
> >
> > };
>
> I think Adam will have a better idea about this.
>
> > 2) I am unclear how to set the output frequencies for the device. For my application I would like to set output clock 1 to 250MHz and output clock 2 to 46.8MHz but I am unclear how to do so.  I have looked at the documentation at https://mjmwired.net/kernel/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml but remain unclear how to set the output frequencies.  Any insight you could provide would be greatly appreciated.
>
> Use assigned-clock-frequencies as described in
> Documentation/devicetree/bindings/clock/clock-bindings.txt
>

I agree that the clock-bindings have the instructions on how to set
them.  If you check
arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi, there are some
examples of how to set the frequency.
In my instance,  the chip wasn't enabling the output by default, so I
needed to submit some patches upstream to make sure the device that
was being clocked by this device had get and enable functions to make
sure the clock chip would turn on the clock when requested.

>
> > I saw your name mentioned so I am emailing  you directly.  If there is a better place to ask these questions can you please direct me there?  Thanks you so much.
>
> Adam (CC'd) wrote the original driver, so he's probably a
> better person to start with. You should also CC the linux-clk
> mailing list for questions about clock drivers.

I've reviewed the datasheet for the 6965, and it doesn't explicitly
show the multiplier, but the programmer's guide does appear to show
the existence of bit that when set, it will "double the reference
frequency for the Phase frequency detector" but on the programmer's
guide for the 6901, the same bit reads "Enables frequency doubler when
set to 1" so it's not clear to me that these functions are exactly the
same, but implies that it might be.  I'll need some time to test this,
but if I find it works, I can push a patch to this driver.  I added
Luca, as he is the maintainer for this driver as well.

adam
>
> --Sean

Re: Questions regarding regarding idt/renesas versaclock5 driver

[Luca Ceresoli]

Hi,

On 28/02/22 18:06, Adam Ford wrote:
> On Mon, Feb 28, 2022 at 10:04 AM Sean Anderson <sean.anderson@seco.com> wrote:
>>
>>
>>
>> On 2/28/22 7:35 AM, Fillion, Claude wrote:
>>>
>>> You don't often get email from claude.fillion@mksinst.com. Learn why this is important <http://aka.ms/LearnAboutSenderIdentification>
>>>
>>>
>>> Hello  Sean,
>>>
>>>
> 
> + Luca Ceresoli
> 
>>>
>>> I have a design that is looking to use the Renesas 5P49V6965 or 5P49V690 clock chip and am looking to use the versaclock 5 driver (https://github.com/Xilinx/linux-xlnx/blob/master/drivers/clk/clk-versaclock5.c).
>>>
>>>
>>>
>>> I am new to writing drivers and have two questions I am hoping you can help me with:
>>>
>>> 1) In the driver I see the following code:
>>>
>>> static const struct vc5_chip_info idt_5p49v6901_info = {
>>>
>>>             .model = IDT_VC6_5P49V6901,
>>>
>>>             .clk_fod_cnt = 4,
>>>
>>>             .clk_out_cnt = 5,
>>>
>>>             .flags = VC5_HAS_PFD_FREQ_DBL,
>>>
>>> };
>>>
>>>
>>>
>>> static const struct vc5_chip_info idt_5p49v6965_info = {
>>>
>>>             .model = IDT_VC6_5P49V6965,
>>>
>>>             .clk_fod_cnt = 4,
>>>
>>>             .clk_out_cnt = 5,
>>>
>>>             .flags =  VC5_HAS_BYPASS_SYNC_BIT,
>>>
>>> };
>>>
>>>
>>>
>>> However, the 6965 part also has the same frequency doubling bit as the 6901.  Would it be better to set the flags for the 6965 to something like this?
>>>
>>>
>>>
>>> static const struct vc5_chip_info idt_5p49v6965_info = {
>>>
>>>             .model = IDT_VC6_5P49V6965,
>>>
>>>             .clk_fod_cnt = 4,
>>>
>>>             .clk_out_cnt = 5,
>>>
>>>             .flags = VC5_HAS_PFD_FREQ_DBL | VC5_HAS_BYPASS_SYNC_BIT,
>>>
>>> };
>>
>> I think Adam will have a better idea about this.
>>
>>> 2) I am unclear how to set the output frequencies for the device. For my application I would like to set output clock 1 to 250MHz and output clock 2 to 46.8MHz but I am unclear how to do so.  I have looked at the documentation at https://mjmwired.net/kernel/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml but remain unclear how to set the output frequencies.  Any insight you could provide would be greatly appreciated.
>>
>> Use assigned-clock-frequencies as described in
>> Documentation/devicetree/bindings/clock/clock-bindings.txt
>>
> 
> I agree that the clock-bindings have the instructions on how to set
> them.  If you check
> arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi, there are some
> examples of how to set the frequency.
> In my instance,  the chip wasn't enabling the output by default, so I
> needed to submit some patches upstream to make sure the device that
> was being clocked by this device had get and enable functions to make
> sure the clock chip would turn on the clock when requested.

Indeed assigned-clocks is the way to enable a clock when the downstream
driver does not request it. Not that it is easy to find: it took me a
while to find it the first time I needed it.

>>> I saw your name mentioned so I am emailing  you directly.  If there is a better place to ask these questions can you please direct me there?  Thanks you so much.
>>
>> Adam (CC'd) wrote the original driver, so he's probably a
>> better person to start with. You should also CC the linux-clk
>> mailing list for questions about clock drivers.
> 
> I've reviewed the datasheet for the 6965, and it doesn't explicitly
> show the multiplier, but the programmer's guide does appear to show
> the existence of bit that when set, it will "double the reference
> frequency for the Phase frequency detector" but on the programmer's
> guide for the 6901, the same bit reads "Enables frequency doubler when
> set to 1" so it's not clear to me that these functions are exactly the
> same, but implies that it might be.  I'll need some time to test this,
> but if I find it works, I can push a patch to this driver.  I added
> Luca, as he is the maintainer for this driver as well.

Thanks Adam. I'm afraid I have no detailed answer as I never tried this
bit, but according to the docs indeed it looks like there is a doubler
as you noticed, that it is disabled by default. It would be nice to test
it and submit a patch, thanks!

-- 
Luca

Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Adam Ford]

On Tue, Mar 1, 2022 at 8:12 AM Fillion, Claude
<Claude.Fillion@mksinst.com> wrote:
>
> Thanks for your replies.  A few more points/questions.
>
>
>
> > -----Original Message-----
>
> > From: Luca Ceresoli <luca@lucaceresoli.net>
>
> > Sent: Monday, February 28, 2022 5:14 PM
>
> > To: Adam Ford <aford173@gmail.com>; Sean Anderson
>
> > <sean.anderson@seco.com>
>
> > Cc: Fillion, Claude <Claude.Fillion@mksinst.com>; linux-clk <linux-
>
> > clk@vger.kernel.org>
>
> > Subject: [EXTERNAL] Re: Questions regarding regarding idt/renesas
>
> > versaclock5 driver
>
> >
>
> > This email originated outside of MKS.  Use caution when sharing information
>
> > or opening attachments and links.
>
> >
>
> > ----------------------------------------------------------------------------------------------
>
> > ----------------------------------------------
>
> > Hi,
>
> >
>
> > On 28/02/22 18:06, Adam Ford wrote:
>
> > > On Mon, Feb 28, 2022 at 10:04 AM Sean Anderson
>
> > <sean.anderson@seco.com> wrote:
>
> > >>
>
> > >>
>
> > >>
>
> > >> On 2/28/22 7:35 AM, Fillion, Claude wrote:
>
> > >>>
>
> > >>> You don't often get email from claude.fillion@mksinst.com. Learn why
>
> > >>> this is important
>
> > >>>
>
> > <https://urldefense.com/v3/__http://aka.ms/LearnAboutSenderIdentific
>
> > >>> ation__;!!KnJ4-
>
> > rp7!1bH43_JT7scsjwzrGD8lPeXvlXh9WieG2jadu9NICLiUrW-We
>
> > >>> UZR3sOMdn4NpYPGkfDG$ >
>
> > >>>
>
> > >>>
>
> > >>> Hello  Sean,
>
> > >>>
>
> > >>>
>
> > >
>
> > > + Luca Ceresoli
>
> > >
>
> > >>>
>
> > >>> I have a design that is looking to use the Renesas 5P49V6965 or 5P49V690
>
> > clock chip and am looking to use the versaclock 5 driver
>
> > (https://urldefense.com/v3/__https://github.com/Xilinx/linux-
>
> > xlnx/blob/master/drivers/clk/clk-versaclock5.c__;!!KnJ4-
>
> > rp7!1bH43_JT7scsjwzrGD8lPeXvlXh9WieG2jadu9NICLiUrW-
>
> > WeUZR3sOMdn4NpaBSRqIM$ ).
>
> > >>>
>
> > >>>
>
> > >>>
>
> > >>> I am new to writing drivers and have two questions I am hoping you can
>
> > help me with:
>
> > >>>
>
> > >>> 1) In the driver I see the following code:
>
> > >>>
>
> > >>> static const struct vc5_chip_info idt_5p49v6901_info = {
>
> > >>>
>
> > >>>             .model = IDT_VC6_5P49V6901,
>
> > >>>
>
> > >>>             .clk_fod_cnt = 4,
>
> > >>>
>
> > >>>             .clk_out_cnt = 5,
>
> > >>>
>
> > >>>             .flags = VC5_HAS_PFD_FREQ_DBL,
>
> > >>>
>
> > >>> };
>
> > >>>
>
> > >>>
>
> > >>>
>
> > >>> static const struct vc5_chip_info idt_5p49v6965_info = {
>
> > >>>
>
> > >>>             .model = IDT_VC6_5P49V6965,
>
> > >>>
>
> > >>>             .clk_fod_cnt = 4,
>
> > >>>
>
> > >>>             .clk_out_cnt = 5,
>
> > >>>
>
> > >>>             .flags =  VC5_HAS_BYPASS_SYNC_BIT,
>
> > >>>
>
> > >>> };
>
> > >>>
>
> > >>>
>
> > >>>
>
> > >>> However, the 6965 part also has the same frequency doubling bit as the
>
> > 6901.  Would it be better to set the flags for the 6965 to something like this?
>
> > >>>
>
> > >>>
>
> > >>>
>
> > >>> static const struct vc5_chip_info idt_5p49v6965_info = {
>
> > >>>
>
> > >>>             .model = IDT_VC6_5P49V6965,
>
> > >>>
>
> > >>>             .clk_fod_cnt = 4,
>
> > >>>
>
> > >>>             .clk_out_cnt = 5,
>
> > >>>
>
> > >>>             .flags = VC5_HAS_PFD_FREQ_DBL | VC5_HAS_BYPASS_SYNC_BIT,
>
> > >>>
>
> > >>> };
>
> > >>
>
> > >> I think Adam will have a better idea about this.
>
> > >>
>
> > >>> 2) I am unclear how to set the output frequencies for the device. For my
>
> > application I would like to set output clock 1 to 250MHz and output clock 2 to
>
> > 46.8MHz but I am unclear how to do so.  I have looked at the documentation
>
> > at
>
> > https://urldefense.com/v3/__https://mjmwired.net/kernel/Documentation
>
> > /devicetree/bindings/clock/idt,versaclock5.yaml__;!!KnJ4-
>
> > rp7!1bH43_JT7scsjwzrGD8lPeXvlXh9WieG2jadu9NICLiUrW-
>
> > WeUZR3sOMdn4NpVQVg6al$  but remain unclear how to set the output
>
> > frequencies.  Any insight you could provide would be greatly appreciated.
>
> > >>
>
> > >> Use assigned-clock-frequencies as described in
>
> > >> Documentation/devicetree/bindings/clock/clock-bindings.txt
>
> > >>
>
> > >
>
> > > I agree that the clock-bindings have the instructions on how to set
>
> > > them.  If you check
>
> > > arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi, there are some
>
> > > examples of how to set the frequency.
>
> > > In my instance,  the chip wasn't enabling the output by default, so I
>
> > > needed to submit some patches upstream to make sure the device that
>
> > > was being clocked by this device had get and enable functions to make
>
> > > sure the clock chip would turn on the clock when requested.
>
> >
>
> > Indeed assigned-clocks is the way to enable a clock when the downstream
>
> > driver does not request it. Not that it is easy to find: it took me a while to find
>
> > it the first time I needed it.
>
> >
>
>
>
> Trying to follow the example beacon-renesom-som.dtsi implementation but am still not getting proper output.  I should note I am running this as a patch on an older Petalinux  code base (4.14.0-xilinx-v2018.3). After replacing dev_err_probe() calls with older dev_err() calls the code compiles and seems to run without issue. Is it possible other files need to be updated?
>
>
>
> Added the provider code at the beginning of dtsi as follows;
>
> #include <dt-bindings/clk/versaclock.h>
>
>
>
> /include/ "system-conf.dtsi"
>
> / {
>
>   /* Clock Provider */
>
>   x304_clk: x304-clock {
>
>     compatible = "fixed-clock";
>
>     #clock-cells = <0>;
>
>     clock-frequency = <25000000>;
>
>   };
>
> …
>
>
>
> And added consumer code:
>
>
>
> &i2c1 {
>
>     clock-frequency = <100000>;
>
>
>
>     // Use patch.  Updated driver for 5p49v6965 available  at https://github.com/Xilinx/linux-xlnx/blob/master/drivers/clk/clk-versaclock5.c
>
>     // Device Tree Setup -> https://github.com/Xilinx/linux-xlnx/blob/master/Documentation/devicetree/bindings/clock/idt%2Cversaclock5.yaml
>
>     versaclock6: clock-controller@6a {
>
>         /* Clock Consumer */
>
>         compatible = "idt,5p49v6965";
>
>                                 reg = <0x6a>;
>
>                                 #clock-cells = <1>;
>
>                                 clocks = <&x304_clk>;
>
>                                 clock-names = "xin";
>
>
>
>         assigned_clocks = <&versaclock6 1>,
>
>                           <&versaclock6 2>,
>
>                           <&versaclock6 3>,
>
>                           <&versaclock6 4>;
>
>         assigned_clock_rates = <46800000>, <250000000>, <1000000>, <13000000>;


Assigned clocks and assigned clock rates should be hyphens and not underscores.

assigned-clocks =  <&versaclock6 1>,   <&versaclock6 2>,
<&versaclock6 3>, <&versaclock6 4>;

assigned-clock-rates =  <46800000>, <250000000>, <1000000>, <13000000>;

Another thing to check is to make sure the consumers of these clocks
is enabling them.  They do not necessarily get enabled by default.

adam



>
>         /* Set the SD/OE pin's settings */
>
>         OUT1 {
>
>             idt,mode = <VC5_LVDS>;
>
>             idt,voltage-microvolt = <3300000>;
>
>             idt,slew-percent = <100>;
>
>         };
>
>         OUT2 {
>
>             idt,mode = <VC5_LVDS>;
>
>             idt,voltage-microvolt = <3300000>;
>
>             idt,slew-percent = <100>;
>
>         };
>
>         OUT3 {
>
>             idt,mode = <VC5_LVDS>;
>
>             idt,voltage-microvolt = <3300000>;
>
>             idt,slew-percent = <100>;
>
>         };
>
>         OUT4 {
>
>             idt,mode = <VC5_LVDS>;
>
>             idt,voltage-microvolt = <3300000>;
>
>             idt,slew-percent = <100>;
>
>         };
>
>     };
>
> …
>
>
>
> But still only seeing default clocks (100MHz on out 1, nothing on out2-4).
>
>
>
> Any suggestions?
>
>
>
> > >>> I saw your name mentioned so I am emailing  you directly.  If there is a
>
> > better place to ask these questions can you please direct me there?  Thanks
>
> > you so much.
>
> > >>
>
> > >> Adam (CC'd) wrote the original driver, so he's probably a better
>
> > >> person to start with. You should also CC the linux-clk mailing list
>
> > >> for questions about clock drivers.
>
> > >
>
> > > I've reviewed the datasheet for the 6965, and it doesn't explicitly
>
> > > show the multiplier, but the programmer's guide does appear to show
>
> > > the existence of bit that when set, it will "double the reference
>
> > > frequency for the Phase frequency detector" but on the programmer's
>
> > > guide for the 6901, the same bit reads "Enables frequency doubler when
>
> > > set to 1" so it's not clear to me that these functions are exactly the
>
> > > same, but implies that it might be.  I'll need some time to test this,
>
> > > but if I find it works, I can push a patch to this driver.  I added
>
> > > Luca, as he is the maintainer for this driver as well.
>
> >
>
> > Thanks Adam. I'm afraid I have no detailed answer as I never tried this bit,
>
> > but according to the docs indeed it looks like there is a doubler as you
>
> > noticed, that it is disabled by default. It would be nice to test it and submit a
>
> > patch, thanks!
>
> >
>
> > --
>
> > Luca
>
>
>
> For what it's worth, I have played around with Renesas' Timing Commander  tool and they seem to use the doubler bit in the same fashion.
>
>
>
>
>
> Thanks,
>
> Claude
>
> ________________________________
> This message and any attachments are intended only for the designated recipient(s) and may contain confidential or proprietary information and be subject to the attorney-client privilege or other confidentiality protections. If you are not a designated recipient, you may not review, use, copy or distribute this message or any attachments. If you received this email in error, please notify the sender by reply e-mail and permanently delete the original and any copies of this message and any attachments thereto. Thank you.

RE: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Fillion, Claude]

> -----Original Message-----
> From: Adam Ford <aford173@gmail.com>
> Sent: Tuesday, March 1, 2022 9:30 AM
> To: Fillion, Claude <Claude.Fillion@mksinst.com>
> Cc: Luca Ceresoli <luca@lucaceresoli.net>; Sean Anderson
> <sean.anderson@seco.com>; linux-clk <linux-clk@vger.kernel.org>
> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> versaclock5 driver
> 
> On Tue, Mar 1, 2022 at 8:12 AM Fillion, Claude <Claude.Fillion@mksinst.com>
> wrote:
> >
> > Thanks for your replies.  A few more points/questions.
> >
> >
> >
> > > -----Original Message-----
> >
> > > From: Luca Ceresoli <luca@lucaceresoli.net>
> >
> > > Sent: Monday, February 28, 2022 5:14 PM
> >
> > > To: Adam Ford <aford173@gmail.com>; Sean Anderson
> >
> > > <sean.anderson@seco.com>
> >
> > > Cc: Fillion, Claude <Claude.Fillion@mksinst.com>; linux-clk <linux-
> >
> > > clk@vger.kernel.org>
> >
> > > Subject: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> >
> > > versaclock5 driver
> >
> > >
> >
> > > This email originated outside of MKS.  Use caution when sharing
> > > information
> >
> > > or opening attachments and links.
> >
> > >
> >
> > > --------------------------------------------------------------------
> > > --------------------------
> >
> > > ----------------------------------------------
> >
> > > Hi,
> >
> > >
> >
> > > On 28/02/22 18:06, Adam Ford wrote:
> >
> > > > On Mon, Feb 28, 2022 at 10:04 AM Sean Anderson
> >
> > > <sean.anderson@seco.com> wrote:
> >
> > > >>
> >
> > > >>
> >
> > > >>
> >
> > > >> On 2/28/22 7:35 AM, Fillion, Claude wrote:
> >
> > > >>>
> >
> > > >>> You don't often get email from claude.fillion@mksinst.com. Learn
> > > >>> why
> >
> > > >>> this is important
> >
> > > >>>
> >
> > >
> <https://urldefense.com/v3/__http://aka.ms/LearnAboutSenderIdentific
> >
> > > >>> ation__;!!KnJ4-
> >
> > > rp7!1bH43_JT7scsjwzrGD8lPeXvlXh9WieG2jadu9NICLiUrW-We
> >
> > > >>> UZR3sOMdn4NpYPGkfDG$ >
> >
> > > >>>
> >
> > > >>>
> >
> > > >>> Hello  Sean,
> >
> > > >>>
> >
> > > >>>
> >
> > > >
> >
> > > > + Luca Ceresoli
> >
> > > >
> >
> > > >>>
> >
> > > >>> I have a design that is looking to use the Renesas 5P49V6965 or
> > > >>> 5P49V690
> >
> > > clock chip and am looking to use the versaclock 5 driver
> >
> > > (https://urldefense.com/v3/__https://github.com/Xilinx/linux-
> >
> > > xlnx/blob/master/drivers/clk/clk-versaclock5.c__;!!KnJ4-
> >
> > > rp7!1bH43_JT7scsjwzrGD8lPeXvlXh9WieG2jadu9NICLiUrW-
> >
> > > WeUZR3sOMdn4NpaBSRqIM$ ).
> >
> > > >>>
> >
> > > >>>
> >
> > > >>>
> >
> > > >>> I am new to writing drivers and have two questions I am hoping
> > > >>> you can
> >
> > > help me with:
> >
> > > >>>
> >
> > > >>> 1) In the driver I see the following code:
> >
> > > >>>
> >
> > > >>> static const struct vc5_chip_info idt_5p49v6901_info = {
> >
> > > >>>
> >
> > > >>>             .model = IDT_VC6_5P49V6901,
> >
> > > >>>
> >
> > > >>>             .clk_fod_cnt = 4,
> >
> > > >>>
> >
> > > >>>             .clk_out_cnt = 5,
> >
> > > >>>
> >
> > > >>>             .flags = VC5_HAS_PFD_FREQ_DBL,
> >
> > > >>>
> >
> > > >>> };
> >
> > > >>>
> >
> > > >>>
> >
> > > >>>
> >
> > > >>> static const struct vc5_chip_info idt_5p49v6965_info = {
> >
> > > >>>
> >
> > > >>>             .model = IDT_VC6_5P49V6965,
> >
> > > >>>
> >
> > > >>>             .clk_fod_cnt = 4,
> >
> > > >>>
> >
> > > >>>             .clk_out_cnt = 5,
> >
> > > >>>
> >
> > > >>>             .flags =  VC5_HAS_BYPASS_SYNC_BIT,
> >
> > > >>>
> >
> > > >>> };
> >
> > > >>>
> >
> > > >>>
> >
> > > >>>
> >
> > > >>> However, the 6965 part also has the same frequency doubling bit
> > > >>> as the
> >
> > > 6901.  Would it be better to set the flags for the 6965 to something like
> this?
> >
> > > >>>
> >
> > > >>>
> >
> > > >>>
> >
> > > >>> static const struct vc5_chip_info idt_5p49v6965_info = {
> >
> > > >>>
> >
> > > >>>             .model = IDT_VC6_5P49V6965,
> >
> > > >>>
> >
> > > >>>             .clk_fod_cnt = 4,
> >
> > > >>>
> >
> > > >>>             .clk_out_cnt = 5,
> >
> > > >>>
> >
> > > >>>             .flags = VC5_HAS_PFD_FREQ_DBL |
> > > >>> VC5_HAS_BYPASS_SYNC_BIT,
> >
> > > >>>
> >
> > > >>> };
> >
> > > >>
> >
> > > >> I think Adam will have a better idea about this.
> >
> > > >>
> >
> > > >>> 2) I am unclear how to set the output frequencies for the
> > > >>> device. For my
> >
> > > application I would like to set output clock 1 to 250MHz and output
> > > clock 2 to
> >
> > > 46.8MHz but I am unclear how to do so.  I have looked at the
> > > documentation
> >
> > > at
> >
> > >
> https://urldefense.com/v3/__https://mjmwired.net/kernel/Documentatio
> > > n
> >
> > > /devicetree/bindings/clock/idt,versaclock5.yaml__;!!KnJ4-
> >
> > > rp7!1bH43_JT7scsjwzrGD8lPeXvlXh9WieG2jadu9NICLiUrW-
> >
> > > WeUZR3sOMdn4NpVQVg6al$  but remain unclear how to set the output
> >
> > > frequencies.  Any insight you could provide would be greatly appreciated.
> >
> > > >>
> >
> > > >> Use assigned-clock-frequencies as described in
> >
> > > >> Documentation/devicetree/bindings/clock/clock-bindings.txt
> >
> > > >>
> >
> > > >
> >
> > > > I agree that the clock-bindings have the instructions on how to
> > > > set
> >
> > > > them.  If you check
> >
> > > > arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi, there are
> > > > some
> >
> > > > examples of how to set the frequency.
> >
> > > > In my instance,  the chip wasn't enabling the output by default,
> > > > so I
> >
> > > > needed to submit some patches upstream to make sure the device
> > > > that
> >
> > > > was being clocked by this device had get and enable functions to
> > > > make
> >
> > > > sure the clock chip would turn on the clock when requested.
> >
> > >
> >
> > > Indeed assigned-clocks is the way to enable a clock when the
> > > downstream
> >
> > > driver does not request it. Not that it is easy to find: it took me
> > > a while to find
> >
> > > it the first time I needed it.
> >
> > >
> >
> >
> >
> > Trying to follow the example beacon-renesom-som.dtsi implementation
> but am still not getting proper output.  I should note I am running this as a
> patch on an older Petalinux  code base (4.14.0-xilinx-v2018.3). After replacing
> dev_err_probe() calls with older dev_err() calls the code compiles and seems
> to run without issue. Is it possible other files need to be updated?
> >
> >
> >
> > Added the provider code at the beginning of dtsi as follows;
> >
> > #include <dt-bindings/clk/versaclock.h>
> >
> >
> >
> > /include/ "system-conf.dtsi"
> >
> > / {
> >
> >   /* Clock Provider */
> >
> >   x304_clk: x304-clock {
> >
> >     compatible = "fixed-clock";
> >
> >     #clock-cells = <0>;
> >
> >     clock-frequency = <25000000>;
> >
> >   };
> >
> > …
> >
> >
> >
> > And added consumer code:
> >
> >
> >
> > &i2c1 {
> >
> >     clock-frequency = <100000>;
> >
> >
> >
> >     // Use patch.  Updated driver for 5p49v6965 available  at
> > https://urldefense.com/v3/__https://github.com/Xilinx/linux-xlnx/blob/
> > master/drivers/clk/clk-versaclock5.c__;!!KnJ4-rp7!3K4sRtgFBeaZQ8IrEvZ8
> > dkvJDiPMBlDRradrS0adfnpa1dNXMNjeIwNfOyHPLkFkwVpJ$
> >
> >     // Device Tree Setup ->
> > https://urldefense.com/v3/__https://github.com/Xilinx/linux-xlnx/blob/
> >
> master/Documentation/devicetree/bindings/clock/idt*2Cversaclock5.yaml_
> > _;JQ!!KnJ4-
> rp7!3K4sRtgFBeaZQ8IrEvZ8dkvJDiPMBlDRradrS0adfnpa1dNXMNjeIwN
> > fOyHPLhF0Uums$
> >
> >     versaclock6: clock-controller@6a {
> >
> >         /* Clock Consumer */
> >
> >         compatible = "idt,5p49v6965";
> >
> >                                 reg = <0x6a>;
> >
> >                                 #clock-cells = <1>;
> >
> >                                 clocks = <&x304_clk>;
> >
> >                                 clock-names = "xin";
> >
> >
> >
> >         assigned_clocks = <&versaclock6 1>,
> >
> >                           <&versaclock6 2>,
> >
> >                           <&versaclock6 3>,
> >
> >                           <&versaclock6 4>;
> >
> >         assigned_clock_rates = <46800000>, <250000000>, <1000000>,
> > <13000000>;
> 
> 
> Assigned clocks and assigned clock rates should be hyphens and not
> underscores.
> 
> assigned-clocks =  <&versaclock6 1>,   <&versaclock6 2>,
> <&versaclock6 3>, <&versaclock6 4>;
> 
> assigned-clock-rates =  <46800000>, <250000000>, <1000000>, <13000000>;
> 
> Another thing to check is to make sure the consumers of these clocks is
> enabling them.  They do not necessarily get enabled by default.
> 
> adam

Doh - thanks.  I looked at it a million times 😊 . 

Now getting desired out1 frequency but nothing on other outputs.  From the code it seems vc5_clk_out_prepare() is the method that enables outputs but this method is not being called I am not clear how to make the 'consumer enable them.'  

I have added this to my dtsi to no avail.

   	 /* Consumer referencing 5P49V5965 pin OUT1 and OUT2 */
    	consumer {
      	    clocks = <&versaclock6 1>, <&versaclock6 2>;
       	    /* ... */
   	 };

Looking through device tree documentation.

> 
> 
> 
> >
> >         /* Set the SD/OE pin's settings */
> >
> >         OUT1 {
> >
> >             idt,mode = <VC5_LVDS>;
> >
> >             idt,voltage-microvolt = <3300000>;
> >
> >             idt,slew-percent = <100>;
> >
> >         };
> >
> >         OUT2 {
> >
> >             idt,mode = <VC5_LVDS>;
> >
> >             idt,voltage-microvolt = <3300000>;
> >
> >             idt,slew-percent = <100>;
> >
> >         };
> >
> >         OUT3 {
> >
> >             idt,mode = <VC5_LVDS>;
> >
> >             idt,voltage-microvolt = <3300000>;
> >
> >             idt,slew-percent = <100>;
> >
> >         };
> >
> >         OUT4 {
> >
> >             idt,mode = <VC5_LVDS>;
> >
> >             idt,voltage-microvolt = <3300000>;
> >
> >             idt,slew-percent = <100>;
> >
> >         };
> >
> >     };
> >
> > …
> >
> >
> >
> > But still only seeing default clocks (100MHz on out 1, nothing on out2-4).
> >
> >
> >
> > Any suggestions?
> >
> >
> >
> > > >>> I saw your name mentioned so I am emailing  you directly.  If
> > > >>> there is a
> >
> > > better place to ask these questions can you please direct me there?
> > > Thanks
> >
> > > you so much.
> >
> > > >>
> >
> > > >> Adam (CC'd) wrote the original driver, so he's probably a better
> >
> > > >> person to start with. You should also CC the linux-clk mailing
> > > >> list
> >
> > > >> for questions about clock drivers.
> >
> > > >
> >
> > > > I've reviewed the datasheet for the 6965, and it doesn't
> > > > explicitly
> >
> > > > show the multiplier, but the programmer's guide does appear to
> > > > show
> >
> > > > the existence of bit that when set, it will "double the reference
> >
> > > > frequency for the Phase frequency detector" but on the
> > > > programmer's
> >
> > > > guide for the 6901, the same bit reads "Enables frequency doubler
> > > > when
> >
> > > > set to 1" so it's not clear to me that these functions are exactly
> > > > the
> >
> > > > same, but implies that it might be.  I'll need some time to test
> > > > this,
> >
> > > > but if I find it works, I can push a patch to this driver.  I
> > > > added
> >
> > > > Luca, as he is the maintainer for this driver as well.
> >
> > >
> >
> > > Thanks Adam. I'm afraid I have no detailed answer as I never tried
> > > this bit,
> >
> > > but according to the docs indeed it looks like there is a doubler as
> > > you
> >
> > > noticed, that it is disabled by default. It would be nice to test it
> > > and submit a
> >
> > > patch, thanks!
> >
> > >
> >
> > > --
> >
> > > Luca
> >
> >
> >
> > For what it's worth, I have played around with Renesas' Timing Commander
> tool and they seem to use the doubler bit in the same fashion.
> >
> >
> >
> >
> >
> > Thanks,
> >
> > Claude
> >
> > ________________________________
> > This message and any attachments are intended only for the designated
> recipient(s) and may contain confidential or proprietary information and be
> subject to the attorney-client privilege or other confidentiality protections. If
> you are not a designated recipient, you may not review, use, copy or
> distribute this message or any attachments. If you received this email in
> error, please notify the sender by reply e-mail and permanently delete the
> original and any copies of this message and any attachments thereto. Thank
> you.

======================================================================
This message and any attachments are intended only for the designated recipient(s) and may contain confidential or proprietary information and be subject to the attorney-client privilege or other confidentiality protections.  If you are not a designated recipient, you may not review, use, copy or distribute this message or any attachments.  If you received this email in error, please notify the sender by reply e-mail and permanently delete the original and any copies of this message and any attachments thereto.  Thank you.

Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Adam Ford]

On Tue, Mar 1, 2022 at 12:16 PM Fillion, Claude
<Claude.Fillion@mksinst.com> wrote:
>
>
> > -----Original Message-----
> > From: Adam Ford <aford173@gmail.com>
> > Sent: Tuesday, March 1, 2022 9:30 AM
> > To: Fillion, Claude <Claude.Fillion@mksinst.com>
> > Cc: Luca Ceresoli <luca@lucaceresoli.net>; Sean Anderson
> > <sean.anderson@seco.com>; linux-clk <linux-clk@vger.kernel.org>
> > Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> > versaclock5 driver
> >
> > On Tue, Mar 1, 2022 at 8:12 AM Fillion, Claude <Claude.Fillion@mksinst.com>
> > wrote:
> > >
> > > Thanks for your replies.  A few more points/questions.
> > >
> > >
> > >
> > > > -----Original Message-----
> > >
> > > > From: Luca Ceresoli <luca@lucaceresoli.net>
> > >
> > > > Sent: Monday, February 28, 2022 5:14 PM
> > >
> > > > To: Adam Ford <aford173@gmail.com>; Sean Anderson
> > >
> > > > <sean.anderson@seco.com>
> > >
> > > > Cc: Fillion, Claude <Claude.Fillion@mksinst.com>; linux-clk <linux-
> > >
> > > > clk@vger.kernel.org>
> > >
> > > > Subject: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> > >
> > > > versaclock5 driver
> > >
> > > >
> > >
> > > > This email originated outside of MKS.  Use caution when sharing
> > > > information
> > >
> > > > or opening attachments and links.
> > >
> > > >
> > >
> > > > --------------------------------------------------------------------
> > > > --------------------------
> > >
> > > > ----------------------------------------------
> > >
> > > > Hi,
> > >
> > > >
> > >
> > > > On 28/02/22 18:06, Adam Ford wrote:
> > >
> > > > > On Mon, Feb 28, 2022 at 10:04 AM Sean Anderson
> > >
> > > > <sean.anderson@seco.com> wrote:
> > >
> > > > >>
> > >
> > > > >>
> > >
> > > > >>
> > >
> > > > >> On 2/28/22 7:35 AM, Fillion, Claude wrote:
> > >
> > > > >>>
> > >
> > > > >>> You don't often get email from claude.fillion@mksinst.com. Learn
> > > > >>> why
> > >
> > > > >>> this is important
> > >
> > > > >>>
> > >
> > > >
> > <https://urldefense.com/v3/__http://aka.ms/LearnAboutSenderIdentific
> > >
> > > > >>> ation__;!!KnJ4-
> > >
> > > > rp7!1bH43_JT7scsjwzrGD8lPeXvlXh9WieG2jadu9NICLiUrW-We
> > >
> > > > >>> UZR3sOMdn4NpYPGkfDG$ >
> > >
> > > > >>>
> > >
> > > > >>>
> > >
> > > > >>> Hello  Sean,
> > >
> > > > >>>
> > >
> > > > >>>
> > >
> > > > >
> > >
> > > > > + Luca Ceresoli
> > >
> > > > >
> > >
> > > > >>>
> > >
> > > > >>> I have a design that is looking to use the Renesas 5P49V6965 or
> > > > >>> 5P49V690
> > >
> > > > clock chip and am looking to use the versaclock 5 driver
> > >
> > > > (https://urldefense.com/v3/__https://github.com/Xilinx/linux-
> > >
> > > > xlnx/blob/master/drivers/clk/clk-versaclock5.c__;!!KnJ4-
> > >
> > > > rp7!1bH43_JT7scsjwzrGD8lPeXvlXh9WieG2jadu9NICLiUrW-
> > >
> > > > WeUZR3sOMdn4NpaBSRqIM$ ).
> > >
> > > > >>>
> > >
> > > > >>>
> > >
> > > > >>>
> > >
> > > > >>> I am new to writing drivers and have two questions I am hoping
> > > > >>> you can
> > >
> > > > help me with:
> > >
> > > > >>>
> > >
> > > > >>> 1) In the driver I see the following code:
> > >
> > > > >>>
> > >
> > > > >>> static const struct vc5_chip_info idt_5p49v6901_info = {
> > >
> > > > >>>
> > >
> > > > >>>             .model = IDT_VC6_5P49V6901,
> > >
> > > > >>>
> > >
> > > > >>>             .clk_fod_cnt = 4,
> > >
> > > > >>>
> > >
> > > > >>>             .clk_out_cnt = 5,
> > >
> > > > >>>
> > >
> > > > >>>             .flags = VC5_HAS_PFD_FREQ_DBL,
> > >
> > > > >>>
> > >
> > > > >>> };
> > >
> > > > >>>
> > >
> > > > >>>
> > >
> > > > >>>
> > >
> > > > >>> static const struct vc5_chip_info idt_5p49v6965_info = {
> > >
> > > > >>>
> > >
> > > > >>>             .model = IDT_VC6_5P49V6965,
> > >
> > > > >>>
> > >
> > > > >>>             .clk_fod_cnt = 4,
> > >
> > > > >>>
> > >
> > > > >>>             .clk_out_cnt = 5,
> > >
> > > > >>>
> > >
> > > > >>>             .flags =  VC5_HAS_BYPASS_SYNC_BIT,
> > >
> > > > >>>
> > >
> > > > >>> };
> > >
> > > > >>>
> > >
> > > > >>>
> > >
> > > > >>>
> > >
> > > > >>> However, the 6965 part also has the same frequency doubling bit
> > > > >>> as the
> > >
> > > > 6901.  Would it be better to set the flags for the 6965 to something like
> > this?
> > >
> > > > >>>
> > >
> > > > >>>
> > >
> > > > >>>
> > >
> > > > >>> static const struct vc5_chip_info idt_5p49v6965_info = {
> > >
> > > > >>>
> > >
> > > > >>>             .model = IDT_VC6_5P49V6965,
> > >
> > > > >>>
> > >
> > > > >>>             .clk_fod_cnt = 4,
> > >
> > > > >>>
> > >
> > > > >>>             .clk_out_cnt = 5,
> > >
> > > > >>>
> > >
> > > > >>>             .flags = VC5_HAS_PFD_FREQ_DBL |
> > > > >>> VC5_HAS_BYPASS_SYNC_BIT,
> > >
> > > > >>>
> > >
> > > > >>> };
> > >
> > > > >>
> > >
> > > > >> I think Adam will have a better idea about this.
> > >
> > > > >>
> > >
> > > > >>> 2) I am unclear how to set the output frequencies for the
> > > > >>> device. For my
> > >
> > > > application I would like to set output clock 1 to 250MHz and output
> > > > clock 2 to
> > >
> > > > 46.8MHz but I am unclear how to do so.  I have looked at the
> > > > documentation
> > >
> > > > at
> > >
> > > >
> > https://urldefense.com/v3/__https://mjmwired.net/kernel/Documentatio
> > > > n
> > >
> > > > /devicetree/bindings/clock/idt,versaclock5.yaml__;!!KnJ4-
> > >
> > > > rp7!1bH43_JT7scsjwzrGD8lPeXvlXh9WieG2jadu9NICLiUrW-
> > >
> > > > WeUZR3sOMdn4NpVQVg6al$  but remain unclear how to set the output
> > >
> > > > frequencies.  Any insight you could provide would be greatly appreciated.
> > >
> > > > >>
> > >
> > > > >> Use assigned-clock-frequencies as described in
> > >
> > > > >> Documentation/devicetree/bindings/clock/clock-bindings.txt
> > >
> > > > >>
> > >
> > > > >
> > >
> > > > > I agree that the clock-bindings have the instructions on how to
> > > > > set
> > >
> > > > > them.  If you check
> > >
> > > > > arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi, there are
> > > > > some
> > >
> > > > > examples of how to set the frequency.
> > >
> > > > > In my instance,  the chip wasn't enabling the output by default,
> > > > > so I
> > >
> > > > > needed to submit some patches upstream to make sure the device
> > > > > that
> > >
> > > > > was being clocked by this device had get and enable functions to
> > > > > make
> > >
> > > > > sure the clock chip would turn on the clock when requested.
> > >
> > > >
> > >
> > > > Indeed assigned-clocks is the way to enable a clock when the
> > > > downstream
> > >
> > > > driver does not request it. Not that it is easy to find: it took me
> > > > a while to find
> > >
> > > > it the first time I needed it.
> > >
> > > >
> > >
> > >
> > >
> > > Trying to follow the example beacon-renesom-som.dtsi implementation
> > but am still not getting proper output.  I should note I am running this as a
> > patch on an older Petalinux  code base (4.14.0-xilinx-v2018.3). After replacing
> > dev_err_probe() calls with older dev_err() calls the code compiles and seems
> > to run without issue. Is it possible other files need to be updated?
> > >
> > >
> > >
> > > Added the provider code at the beginning of dtsi as follows;
> > >
> > > #include <dt-bindings/clk/versaclock.h>
> > >
> > >
> > >
> > > /include/ "system-conf.dtsi"
> > >
> > > / {
> > >
> > >   /* Clock Provider */
> > >
> > >   x304_clk: x304-clock {
> > >
> > >     compatible = "fixed-clock";
> > >
> > >     #clock-cells = <0>;
> > >
> > >     clock-frequency = <25000000>;
> > >
> > >   };
> > >
> > > …
> > >
> > >
> > >
> > > And added consumer code:
> > >
> > >
> > >
> > > &i2c1 {
> > >
> > >     clock-frequency = <100000>;
> > >
> > >
> > >
> > >     // Use patch.  Updated driver for 5p49v6965 available  at
> > > https://urldefense.com/v3/__https://github.com/Xilinx/linux-xlnx/blob/
> > > master/drivers/clk/clk-versaclock5.c__;!!KnJ4-rp7!3K4sRtgFBeaZQ8IrEvZ8
> > > dkvJDiPMBlDRradrS0adfnpa1dNXMNjeIwNfOyHPLkFkwVpJ$
> > >
> > >     // Device Tree Setup ->
> > > https://urldefense.com/v3/__https://github.com/Xilinx/linux-xlnx/blob/
> > >
> > master/Documentation/devicetree/bindings/clock/idt*2Cversaclock5.yaml_
> > > _;JQ!!KnJ4-
> > rp7!3K4sRtgFBeaZQ8IrEvZ8dkvJDiPMBlDRradrS0adfnpa1dNXMNjeIwN
> > > fOyHPLhF0Uums$
> > >
> > >     versaclock6: clock-controller@6a {
> > >
> > >         /* Clock Consumer */
> > >
> > >         compatible = "idt,5p49v6965";
> > >
> > >                                 reg = <0x6a>;
> > >
> > >                                 #clock-cells = <1>;
> > >
> > >                                 clocks = <&x304_clk>;
> > >
> > >                                 clock-names = "xin";
> > >
> > >
> > >
> > >         assigned_clocks = <&versaclock6 1>,
> > >
> > >                           <&versaclock6 2>,
> > >
> > >                           <&versaclock6 3>,
> > >
> > >                           <&versaclock6 4>;
> > >
> > >         assigned_clock_rates = <46800000>, <250000000>, <1000000>,
> > > <13000000>;
> >
> >
> > Assigned clocks and assigned clock rates should be hyphens and not
> > underscores.
> >
> > assigned-clocks =  <&versaclock6 1>,   <&versaclock6 2>,
> > <&versaclock6 3>, <&versaclock6 4>;
> >
> > assigned-clock-rates =  <46800000>, <250000000>, <1000000>, <13000000>;
> >
> > Another thing to check is to make sure the consumers of these clocks is
> > enabling them.  They do not necessarily get enabled by default.
> >
> > adam
>
> Doh - thanks.  I looked at it a million times 😊 .
>
> Now getting desired out1 frequency but nothing on other outputs.  From the code it seems vc5_clk_out_prepare() is the method that enables outputs but this method is not being called I am not clear how to make the 'consumer enable them.'
>
> I have added this to my dtsi to no avail.
>
>          /* Consumer referencing 5P49V5965 pin OUT1 and OUT2 */
>         consumer {
>             clocks = <&versaclock6 1>, <&versaclock6 2>;
>             /* ... */
>          };
>
> Looking through device tree documentation.

It's likely going to be in the consumer's driver.  Check the consumer
device tree binding to make sure you've correctly associated the
clock.  If the binding doesnt't show a clock is required, it might not
know that you using a programmable clock.

Here is a patch that I needed to apply to an Ethernet driver which
wasn't expecting a programmable clock to drive a reference clock, so
the clock wasn't being enabled.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/ethernet/renesas/ravb_main.c?id=8ef7adc6beb2ef0bce83513dc9e4505e7b21e8c2

Look at the use of devm_clk_get_optional and clk_prepare_enable from
that patch.  (yes, there is a subsequent patch that fixes something I
didn't quite do right, but the basics are here)

The consumer drivers need to 'get' the clock so it can associate
itself to the clock in question.  Once the relationship is
established, the consumer needs to call clk_prepare_enable() which
uses the clock system to turn the clock on.  Without this step, it's
likely the Versaclock won't generate a signal, because it doesn't know
it needs to turn it on.

adam
>
> >
> >
> >
> > >
> > >         /* Set the SD/OE pin's settings */
> > >
> > >         OUT1 {
> > >
> > >             idt,mode = <VC5_LVDS>;
> > >
> > >             idt,voltage-microvolt = <3300000>;
> > >
> > >             idt,slew-percent = <100>;
> > >
> > >         };
> > >
> > >         OUT2 {
> > >
> > >             idt,mode = <VC5_LVDS>;
> > >
> > >             idt,voltage-microvolt = <3300000>;
> > >
> > >             idt,slew-percent = <100>;
> > >
> > >         };
> > >
> > >         OUT3 {
> > >
> > >             idt,mode = <VC5_LVDS>;
> > >
> > >             idt,voltage-microvolt = <3300000>;
> > >
> > >             idt,slew-percent = <100>;
> > >
> > >         };
> > >
> > >         OUT4 {
> > >
> > >             idt,mode = <VC5_LVDS>;
> > >
> > >             idt,voltage-microvolt = <3300000>;
> > >
> > >             idt,slew-percent = <100>;
> > >
> > >         };
> > >
> > >     };
> > >
> > > …
> > >
> > >
> > >
> > > But still only seeing default clocks (100MHz on out 1, nothing on out2-4).
> > >
> > >
> > >
> > > Any suggestions?
> > >
> > >
> > >
> > > > >>> I saw your name mentioned so I am emailing  you directly.  If
> > > > >>> there is a
> > >
> > > > better place to ask these questions can you please direct me there?
> > > > Thanks
> > >
> > > > you so much.
> > >
> > > > >>
> > >
> > > > >> Adam (CC'd) wrote the original driver, so he's probably a better
> > >
> > > > >> person to start with. You should also CC the linux-clk mailing
> > > > >> list
> > >
> > > > >> for questions about clock drivers.
> > >
> > > > >
> > >
> > > > > I've reviewed the datasheet for the 6965, and it doesn't
> > > > > explicitly
> > >
> > > > > show the multiplier, but the programmer's guide does appear to
> > > > > show
> > >
> > > > > the existence of bit that when set, it will "double the reference
> > >
> > > > > frequency for the Phase frequency detector" but on the
> > > > > programmer's
> > >
> > > > > guide for the 6901, the same bit reads "Enables frequency doubler
> > > > > when
> > >
> > > > > set to 1" so it's not clear to me that these functions are exactly
> > > > > the
> > >
> > > > > same, but implies that it might be.  I'll need some time to test
> > > > > this,
> > >
> > > > > but if I find it works, I can push a patch to this driver.  I
> > > > > added
> > >
> > > > > Luca, as he is the maintainer for this driver as well.
> > >
> > > >
> > >
> > > > Thanks Adam. I'm afraid I have no detailed answer as I never tried
> > > > this bit,
> > >
> > > > but according to the docs indeed it looks like there is a doubler as
> > > > you
> > >
> > > > noticed, that it is disabled by default. It would be nice to test it
> > > > and submit a
> > >
> > > > patch, thanks!
> > >
> > > >
> > >
> > > > --
> > >
> > > > Luca
> > >
> > >
> > >
> > > For what it's worth, I have played around with Renesas' Timing Commander
> > tool and they seem to use the doubler bit in the same fashion.
> > >
> > >
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Claude
> > >
> > > ________________________________
> > > This message and any attachments are intended only for the designated
> > recipient(s) and may contain confidential or proprietary information and be
> > subject to the attorney-client privilege or other confidentiality protections. If
> > you are not a designated recipient, you may not review, use, copy or
> > distribute this message or any attachments. If you received this email in
> > error, please notify the sender by reply e-mail and permanently delete the
> > original and any copies of this message and any attachments thereto. Thank
> > you.
>
> ======================================================================
> This message and any attachments are intended only for the designated recipient(s) and may contain confidential or proprietary information and be subject to the attorney-client privilege or other confidentiality protections.  If you are not a designated recipient, you may not review, use, copy or distribute this message or any attachments.  If you received this email in error, please notify the sender by reply e-mail and permanently delete the original and any copies of this message and any attachments thereto.  Thank you.

RE: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Fillion, Claude]

> -----Original Message-----
> From: Adam Ford <aford173@gmail.com>
> Sent: Tuesday, March 1, 2022 1:28 PM
> To: Fillion, Claude <Claude.Fillion@mksinst.com>
> Cc: Luca Ceresoli <luca@lucaceresoli.net>; Sean Anderson
> <sean.anderson@seco.com>; linux-clk <linux-clk@vger.kernel.org>
> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> versaclock5 driver
> 
> On Tue, Mar 1, 2022 at 12:16 PM Fillion, Claude
> <Claude.Fillion@mksinst.com> wrote:
> >
> >
> > > -----Original Message-----
> > > From: Adam Ford <aford173@gmail.com>
> > > Sent: Tuesday, March 1, 2022 9:30 AM
> > > To: Fillion, Claude <Claude.Fillion@mksinst.com>
> > > Cc: Luca Ceresoli <luca@lucaceresoli.net>; Sean Anderson
> > > <sean.anderson@seco.com>; linux-clk <linux-clk@vger.kernel.org>
> > > Subject: Re: [EXTERNAL] Re: Questions regarding regarding
> > > idt/renesas
> > > versaclock5 driver
> > >
> > > On Tue, Mar 1, 2022 at 8:12 AM Fillion, Claude
> > > <Claude.Fillion@mksinst.com>
> > > wrote:
> > > >
> > > > Thanks for your replies.  A few more points/questions.
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > >
> > > > > From: Luca Ceresoli <luca@lucaceresoli.net>
> > > >
> > > > > Sent: Monday, February 28, 2022 5:14 PM
> > > >
> > > > > To: Adam Ford <aford173@gmail.com>; Sean Anderson
> > > >
> > > > > <sean.anderson@seco.com>
> > > >
> > > > > Cc: Fillion, Claude <Claude.Fillion@mksinst.com>; linux-clk
> > > > > <linux-
> > > >
> > > > > clk@vger.kernel.org>
> > > >
> > > > > Subject: [EXTERNAL] Re: Questions regarding regarding
> > > > > idt/renesas
> > > >
> > > > > versaclock5 driver
> > > >
> > > > >
> > > >
> > > > > This email originated outside of MKS.  Use caution when sharing
> > > > > information
> > > >
> > > > > or opening attachments and links.
> > > >
> > > > >
> > > >
> > > > > ----------------------------------------------------------------
> > > > > ----
> > > > > --------------------------
> > > >
> > > > > ----------------------------------------------
> > > >
> > > > > Hi,
> > > >
> > > > >
> > > >
> > > > > On 28/02/22 18:06, Adam Ford wrote:
> > > >
> > > > > > On Mon, Feb 28, 2022 at 10:04 AM Sean Anderson
> > > >
> > > > > <sean.anderson@seco.com> wrote:
> > > >
> > > > > >>
> > > >
> > > > > >>
> > > >
> > > > > >>
> > > >
> > > > > >> On 2/28/22 7:35 AM, Fillion, Claude wrote:
> > > >
> > > > > >>>
> > > >
> > > > > >>> You don't often get email from claude.fillion@mksinst.com.
> > > > > >>> Learn why
> > > >
> > > > > >>> this is important
> > > >
> > > > > >>>
> > > >
> > > > >
> > >
> <https://urldefense.com/v3/__http://aka.ms/LearnAboutSenderIdentific
> > > >
> > > > > >>> ation__;!!KnJ4-
> > > >
> > > > > rp7!1bH43_JT7scsjwzrGD8lPeXvlXh9WieG2jadu9NICLiUrW-We
> > > >
> > > > > >>> UZR3sOMdn4NpYPGkfDG$ >
> > > >
> > > > > >>>
> > > >
> > > > > >>>
> > > >
> > > > > >>> Hello  Sean,
> > > >
> > > > > >>>
> > > >
> > > > > >>>
> > > >
> > > > > >
> > > >
> > > > > > + Luca Ceresoli
> > > >
> > > > > >
> > > >
> > > > > >>>
> > > >
> > > > > >>> I have a design that is looking to use the Renesas 5P49V6965
> > > > > >>> or
> > > > > >>> 5P49V690
> > > >
> > > > > clock chip and am looking to use the versaclock 5 driver
> > > >
> > > > > (https://urldefense.com/v3/__https://github.com/Xilinx/linux-
> > > >
> > > > > xlnx/blob/master/drivers/clk/clk-versaclock5.c__;!!KnJ4-
> > > >
> > > > > rp7!1bH43_JT7scsjwzrGD8lPeXvlXh9WieG2jadu9NICLiUrW-
> > > >
> > > > > WeUZR3sOMdn4NpaBSRqIM$ ).
> > > >
> > > > > >>>
> > > >
> > > > > >>>
> > > >
> > > > > >>>
> > > >
> > > > > >>> I am new to writing drivers and have two questions I am
> > > > > >>> hoping you can
> > > >
> > > > > help me with:
> > > >
> > > > > >>>
> > > >
> > > > > >>> 1) In the driver I see the following code:
> > > >
> > > > > >>>
> > > >
> > > > > >>> static const struct vc5_chip_info idt_5p49v6901_info = {
> > > >
> > > > > >>>
> > > >
> > > > > >>>             .model = IDT_VC6_5P49V6901,
> > > >
> > > > > >>>
> > > >
> > > > > >>>             .clk_fod_cnt = 4,
> > > >
> > > > > >>>
> > > >
> > > > > >>>             .clk_out_cnt = 5,
> > > >
> > > > > >>>
> > > >
> > > > > >>>             .flags = VC5_HAS_PFD_FREQ_DBL,
> > > >
> > > > > >>>
> > > >
> > > > > >>> };
> > > >
> > > > > >>>
> > > >
> > > > > >>>
> > > >
> > > > > >>>
> > > >
> > > > > >>> static const struct vc5_chip_info idt_5p49v6965_info = {
> > > >
> > > > > >>>
> > > >
> > > > > >>>             .model = IDT_VC6_5P49V6965,
> > > >
> > > > > >>>
> > > >
> > > > > >>>             .clk_fod_cnt = 4,
> > > >
> > > > > >>>
> > > >
> > > > > >>>             .clk_out_cnt = 5,
> > > >
> > > > > >>>
> > > >
> > > > > >>>             .flags =  VC5_HAS_BYPASS_SYNC_BIT,
> > > >
> > > > > >>>
> > > >
> > > > > >>> };
> > > >
> > > > > >>>
> > > >
> > > > > >>>
> > > >
> > > > > >>>
> > > >
> > > > > >>> However, the 6965 part also has the same frequency doubling
> > > > > >>> bit as the
> > > >
> > > > > 6901.  Would it be better to set the flags for the 6965 to
> > > > > something like
> > > this?
> > > >
> > > > > >>>
> > > >
> > > > > >>>
> > > >
> > > > > >>>
> > > >
> > > > > >>> static const struct vc5_chip_info idt_5p49v6965_info = {
> > > >
> > > > > >>>
> > > >
> > > > > >>>             .model = IDT_VC6_5P49V6965,
> > > >
> > > > > >>>
> > > >
> > > > > >>>             .clk_fod_cnt = 4,
> > > >
> > > > > >>>
> > > >
> > > > > >>>             .clk_out_cnt = 5,
> > > >
> > > > > >>>
> > > >
> > > > > >>>             .flags = VC5_HAS_PFD_FREQ_DBL |
> > > > > >>> VC5_HAS_BYPASS_SYNC_BIT,
> > > >
> > > > > >>>
> > > >
> > > > > >>> };
> > > >
> > > > > >>
> > > >
> > > > > >> I think Adam will have a better idea about this.
> > > >
> > > > > >>
> > > >
> > > > > >>> 2) I am unclear how to set the output frequencies for the
> > > > > >>> device. For my
> > > >
> > > > > application I would like to set output clock 1 to 250MHz and
> > > > > output clock 2 to
> > > >
> > > > > 46.8MHz but I am unclear how to do so.  I have looked at the
> > > > > documentation
> > > >
> > > > > at
> > > >
> > > > >
> > >
> https://urldefense.com/v3/__https://mjmwired.net/kernel/Documentatio
> > > > > n
> > > >
> > > > > /devicetree/bindings/clock/idt,versaclock5.yaml__;!!KnJ4-
> > > >
> > > > > rp7!1bH43_JT7scsjwzrGD8lPeXvlXh9WieG2jadu9NICLiUrW-
> > > >
> > > > > WeUZR3sOMdn4NpVQVg6al$  but remain unclear how to set the
> output
> > > >
> > > > > frequencies.  Any insight you could provide would be greatly
> appreciated.
> > > >
> > > > > >>
> > > >
> > > > > >> Use assigned-clock-frequencies as described in
> > > >
> > > > > >> Documentation/devicetree/bindings/clock/clock-bindings.txt
> > > >
> > > > > >>
> > > >
> > > > > >
> > > >
> > > > > > I agree that the clock-bindings have the instructions on how
> > > > > > to set
> > > >
> > > > > > them.  If you check
> > > >
> > > > > > arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi, there
> are
> > > > > > some
> > > >
> > > > > > examples of how to set the frequency.
> > > >
> > > > > > In my instance,  the chip wasn't enabling the output by
> > > > > > default, so I
> > > >
> > > > > > needed to submit some patches upstream to make sure the device
> > > > > > that
> > > >
> > > > > > was being clocked by this device had get and enable functions
> > > > > > to make
> > > >
> > > > > > sure the clock chip would turn on the clock when requested.
> > > >
> > > > >
> > > >
> > > > > Indeed assigned-clocks is the way to enable a clock when the
> > > > > downstream
> > > >
> > > > > driver does not request it. Not that it is easy to find: it took
> > > > > me a while to find
> > > >
> > > > > it the first time I needed it.
> > > >
> > > > >
> > > >
> > > >
> > > >
> > > > Trying to follow the example beacon-renesom-som.dtsi
> > > > implementation
> > > but am still not getting proper output.  I should note I am running
> > > this as a patch on an older Petalinux  code base
> > > (4.14.0-xilinx-v2018.3). After replacing
> > > dev_err_probe() calls with older dev_err() calls the code compiles
> > > and seems to run without issue. Is it possible other files need to be
> updated?
> > > >
> > > >
> > > >
> > > > Added the provider code at the beginning of dtsi as follows;
> > > >
> > > > #include <dt-bindings/clk/versaclock.h>
> > > >
> > > >
> > > >
> > > > /include/ "system-conf.dtsi"
> > > >
> > > > / {
> > > >
> > > >   /* Clock Provider */
> > > >
> > > >   x304_clk: x304-clock {
> > > >
> > > >     compatible = "fixed-clock";
> > > >
> > > >     #clock-cells = <0>;
> > > >
> > > >     clock-frequency = <25000000>;
> > > >
> > > >   };
> > > >
> > > > …
> > > >
> > > >
> > > >
> > > > And added consumer code:
> > > >
> > > >
> > > >
> > > > &i2c1 {
> > > >
> > > >     clock-frequency = <100000>;
> > > >
> > > >
> > > >
> > > >     // Use patch.  Updated driver for 5p49v6965 available  at
> > > > https://urldefense.com/v3/__https://github.com/Xilinx/linux-xlnx/b
> > > > lob/
> > > > master/drivers/clk/clk-versaclock5.c__;!!KnJ4-rp7!3K4sRtgFBeaZQ8Ir
> > > > EvZ8 dkvJDiPMBlDRradrS0adfnpa1dNXMNjeIwNfOyHPLkFkwVpJ$
> > > >
> > > >     // Device Tree Setup ->
> > > > https://urldefense.com/v3/__https://github.com/Xilinx/linux-xlnx/b
> > > > lob/
> > > >
> > >
> master/Documentation/devicetree/bindings/clock/idt*2Cversaclock5.yam
> > > l_
> > > > _;JQ!!KnJ4-
> > > rp7!3K4sRtgFBeaZQ8IrEvZ8dkvJDiPMBlDRradrS0adfnpa1dNXMNjeIwN
> > > > fOyHPLhF0Uums$
> > > >
> > > >     versaclock6: clock-controller@6a {
> > > >
> > > >         /* Clock Consumer */
> > > >
> > > >         compatible = "idt,5p49v6965";
> > > >
> > > >                                 reg = <0x6a>;
> > > >
> > > >                                 #clock-cells = <1>;
> > > >
> > > >                                 clocks = <&x304_clk>;
> > > >
> > > >                                 clock-names = "xin";
> > > >
> > > >
> > > >
> > > >         assigned_clocks = <&versaclock6 1>,
> > > >
> > > >                           <&versaclock6 2>,
> > > >
> > > >                           <&versaclock6 3>,
> > > >
> > > >                           <&versaclock6 4>;
> > > >
> > > >         assigned_clock_rates = <46800000>, <250000000>, <1000000>,
> > > > <13000000>;
> > >
> > >
> > > Assigned clocks and assigned clock rates should be hyphens and not
> > > underscores.
> > >
> > > assigned-clocks =  <&versaclock6 1>,   <&versaclock6 2>,
> > > <&versaclock6 3>, <&versaclock6 4>;
> > >
> > > assigned-clock-rates =  <46800000>, <250000000>, <1000000>,
> > > <13000000>;
> > >
> > > Another thing to check is to make sure the consumers of these clocks
> > > is enabling them.  They do not necessarily get enabled by default.
> > >
> > > adam
> >
> > Doh - thanks.  I looked at it a million times 😊 .
> >
> > Now getting desired out1 frequency but nothing on other outputs.  From
> the code it seems vc5_clk_out_prepare() is the method that enables outputs
> but this method is not being called I am not clear how to make the 'consumer
> enable them.'
> >
> > I have added this to my dtsi to no avail.
> >
> >          /* Consumer referencing 5P49V5965 pin OUT1 and OUT2 */
> >         consumer {
> >             clocks = <&versaclock6 1>, <&versaclock6 2>;
> >             /* ... */
> >          };
> >
> > Looking through device tree documentation.
> 
> It's likely going to be in the consumer's driver.  Check the consumer device
> tree binding to make sure you've correctly associated the clock.  If the
> binding doesnt't show a clock is required, it might not know that you using a
> programmable clock.
> 
> Here is a patch that I needed to apply to an Ethernet driver which wasn't
> expecting a programmable clock to drive a reference clock, so the clock
> wasn't being enabled.
> 
> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/g
> it/torvalds/linux.git/commit/drivers/net/ethernet/renesas/ravb_main.c?id=
> 8ef7adc6beb2ef0bce83513dc9e4505e7b21e8c2__;!!KnJ4-rp7!1Qb17q-
> TWrV62AeQtTNNVDErVbyhbXB1sukyT2ggvFPUltIBI5nIKzNnjVOcqlw8qJyy$
> 
> Look at the use of devm_clk_get_optional and clk_prepare_enable from that
> patch.  (yes, there is a subsequent patch that fixes something I didn't quite
> do right, but the basics are here)
> 
> The consumer drivers need to 'get' the clock so it can associate itself to the
> clock in question.  Once the relationship is established, the consumer needs
> to call clk_prepare_enable() which uses the clock system to turn the clock on.
> Without this step, it's likely the Versaclock won't generate a signal, because it
> doesn't know it needs to turn it on.
> 
> adam

Not sure I fully follow.  I see that clk out1 is enabled but the other channels are not so it would seem my difficulty is with individual channels. 

In my simple application I would like to enable outputs, on a per channel basis, from the device tree.  Would it make sense  to add  an 'idt,enable' property in similar fashion to the existing idt,mode, idt,voltage-microvolt, and idt,slew-percent properties?  Then vc5_get_output_config() could be modified to also call vc5_clk_out_prepare() (or clk_prepare_enable(), which in turn would call vc5_clk_out_prepare()).

Seems like this would work nicely for my application but not sure it would be generally useful.

-Claude

> >
> > >
> > >
> > >
> > > >
> > > >         /* Set the SD/OE pin's settings */
> > > >
> > > >         OUT1 {
> > > >
> > > >             idt,mode = <VC5_LVDS>;
> > > >
> > > >             idt,voltage-microvolt = <3300000>;
> > > >
> > > >             idt,slew-percent = <100>;
> > > >
> > > >         };
> > > >
> > > >         OUT2 {
> > > >
> > > >             idt,mode = <VC5_LVDS>;
> > > >
> > > >             idt,voltage-microvolt = <3300000>;
> > > >
> > > >             idt,slew-percent = <100>;
> > > >
> > > >         };
> > > >
> > > >         OUT3 {
> > > >
> > > >             idt,mode = <VC5_LVDS>;
> > > >
> > > >             idt,voltage-microvolt = <3300000>;
> > > >
> > > >             idt,slew-percent = <100>;
> > > >
> > > >         };
> > > >
> > > >         OUT4 {
> > > >
> > > >             idt,mode = <VC5_LVDS>;
> > > >
> > > >             idt,voltage-microvolt = <3300000>;
> > > >
> > > >             idt,slew-percent = <100>;
> > > >
> > > >         };
> > > >
> > > >     };
> > > >
> > > > …
> > > >
> > > >
> > > >
> > > > But still only seeing default clocks (100MHz on out 1, nothing on out2-4).
> > > >
> > > >
> > > >
> > > > Any suggestions?
> > > >
> > > >
> > > >
> > > > > >>> I saw your name mentioned so I am emailing  you directly.
> > > > > >>> If there is a
> > > >
> > > > > better place to ask these questions can you please direct me there?
> > > > > Thanks
> > > >
> > > > > you so much.
> > > >
> > > > > >>
> > > >
> > > > > >> Adam (CC'd) wrote the original driver, so he's probably a
> > > > > >> better
> > > >
> > > > > >> person to start with. You should also CC the linux-clk
> > > > > >> mailing list
> > > >
> > > > > >> for questions about clock drivers.
> > > >
> > > > > >
> > > >
> > > > > > I've reviewed the datasheet for the 6965, and it doesn't
> > > > > > explicitly
> > > >
> > > > > > show the multiplier, but the programmer's guide does appear to
> > > > > > show
> > > >
> > > > > > the existence of bit that when set, it will "double the
> > > > > > reference
> > > >
> > > > > > frequency for the Phase frequency detector" but on the
> > > > > > programmer's
> > > >
> > > > > > guide for the 6901, the same bit reads "Enables frequency
> > > > > > doubler when
> > > >
> > > > > > set to 1" so it's not clear to me that these functions are
> > > > > > exactly the
> > > >
> > > > > > same, but implies that it might be.  I'll need some time to
> > > > > > test this,
> > > >
> > > > > > but if I find it works, I can push a patch to this driver.  I
> > > > > > added
> > > >
> > > > > > Luca, as he is the maintainer for this driver as well.
> > > >
> > > > >
> > > >
> > > > > Thanks Adam. I'm afraid I have no detailed answer as I never
> > > > > tried this bit,
> > > >
> > > > > but according to the docs indeed it looks like there is a
> > > > > doubler as you
> > > >
> > > > > noticed, that it is disabled by default. It would be nice to
> > > > > test it and submit a
> > > >
> > > > > patch, thanks!
> > > >
> > > > >
> > > >
> > > > > --
> > > >
> > > > > Luca
> > > >
> > > >
> > > >
> > > > For what it's worth, I have played around with Renesas' Timing
> > > > Commander
> > > tool and they seem to use the doubler bit in the same fashion.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Claude
> > > >
> > > > ________________________________
> > > > This message and any attachments are intended only for the
> > > > designated
> > > recipient(s) and may contain confidential or proprietary information
> > > and be subject to the attorney-client privilege or other
> > > confidentiality protections. If you are not a designated recipient,
> > > you may not review, use, copy or distribute this message or any
> > > attachments. If you received this email in error, please notify the
> > > sender by reply e-mail and permanently delete the original and any
> > > copies of this message and any attachments thereto. Thank you.
> >
> >
> ==========================================================
> ============
> > This message and any attachments are intended only for the designated
> recipient(s) and may contain confidential or proprietary information and be
> subject to the attorney-client privilege or other confidentiality protections.  If
> you are not a designated recipient, you may not review, use, copy or
> distribute this message or any attachments.  If you received this email in
> error, please notify the sender by reply e-mail and permanently delete the
> original and any copies of this message and any attachments thereto.  Thank
> you.

======================================================================
This message and any attachments are intended only for the designated recipient(s) and may contain confidential or proprietary information and be subject to the attorney-client privilege or other confidentiality protections.  If you are not a designated recipient, you may not review, use, copy or distribute this message or any attachments.  If you received this email in error, please notify the sender by reply e-mail and permanently delete the original and any copies of this message and any attachments thereto.  Thank you.

Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Adam Ford]

On Wed, Mar 2, 2022 at 8:44 AM Fillion, Claude
<Claude.Fillion@mksinst.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Adam Ford <aford173@gmail.com>
> > Sent: Tuesday, March 1, 2022 1:28 PM
> > To: Fillion, Claude <Claude.Fillion@mksinst.com>
> > Cc: Luca Ceresoli <luca@lucaceresoli.net>; Sean Anderson
> > <sean.anderson@seco.com>; linux-clk <linux-clk@vger.kernel.org>
> > Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> > versaclock5 driver
> >
> > On Tue, Mar 1, 2022 at 12:16 PM Fillion, Claude
> > <Claude.Fillion@mksinst.com> wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Adam Ford <aford173@gmail.com>
> > > > Sent: Tuesday, March 1, 2022 9:30 AM
> > > > To: Fillion, Claude <Claude.Fillion@mksinst.com>
> > > > Cc: Luca Ceresoli <luca@lucaceresoli.net>; Sean Anderson
> > > > <sean.anderson@seco.com>; linux-clk <linux-clk@vger.kernel.org>
> > > > Subject: Re: [EXTERNAL] Re: Questions regarding regarding
> > > > idt/renesas
> > > > versaclock5 driver
> > > >
> > > > On Tue, Mar 1, 2022 at 8:12 AM Fillion, Claude
> > > > <Claude.Fillion@mksinst.com>
> > > > wrote:
> > > > >
> > > > > Thanks for your replies.  A few more points/questions.
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > >
> > > > > > From: Luca Ceresoli <luca@lucaceresoli.net>
> > > > >
> > > > > > Sent: Monday, February 28, 2022 5:14 PM
> > > > >
> > > > > > To: Adam Ford <aford173@gmail.com>; Sean Anderson
> > > > >
> > > > > > <sean.anderson@seco.com>
> > > > >
> > > > > > Cc: Fillion, Claude <Claude.Fillion@mksinst.com>; linux-clk
> > > > > > <linux-
> > > > >
> > > > > > clk@vger.kernel.org>
> > > > >
> > > > > > Subject: [EXTERNAL] Re: Questions regarding regarding
> > > > > > idt/renesas
> > > > >
> > > > > > versaclock5 driver
> > > > >
> > > > > >
> > > > >
> > > > > > This email originated outside of MKS.  Use caution when sharing
> > > > > > information
> > > > >
> > > > > > or opening attachments and links.
> > > > >
> > > > > >
> > > > >
> > > > > > ----------------------------------------------------------------
> > > > > > ----
> > > > > > --------------------------
> > > > >
> > > > > > ----------------------------------------------
> > > > >
> > > > > > Hi,
> > > > >
> > > > > >
> > > > >
> > > > > > On 28/02/22 18:06, Adam Ford wrote:
> > > > >
> > > > > > > On Mon, Feb 28, 2022 at 10:04 AM Sean Anderson
> > > > >
> > > > > > <sean.anderson@seco.com> wrote:
> > > > >
> > > > > > >>
> > > > >
> > > > > > >>
> > > > >
> > > > > > >>
> > > > >
> > > > > > >> On 2/28/22 7:35 AM, Fillion, Claude wrote:
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>> You don't often get email from claude.fillion@mksinst.com.
> > > > > > >>> Learn why
> > > > >
> > > > > > >>> this is important
> > > > >
> > > > > > >>>
> > > > >
> > > > > >
> > > >
> > <https://urldefense.com/v3/__http://aka.ms/LearnAboutSenderIdentific
> > > > >
> > > > > > >>> ation__;!!KnJ4-
> > > > >
> > > > > > rp7!1bH43_JT7scsjwzrGD8lPeXvlXh9WieG2jadu9NICLiUrW-We
> > > > >
> > > > > > >>> UZR3sOMdn4NpYPGkfDG$ >
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>> Hello  Sean,
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >
> > > > >
> > > > > > > + Luca Ceresoli
> > > > >
> > > > > > >
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>> I have a design that is looking to use the Renesas 5P49V6965
> > > > > > >>> or
> > > > > > >>> 5P49V690
> > > > >
> > > > > > clock chip and am looking to use the versaclock 5 driver
> > > > >
> > > > > > (https://urldefense.com/v3/__https://github.com/Xilinx/linux-
> > > > >
> > > > > > xlnx/blob/master/drivers/clk/clk-versaclock5.c__;!!KnJ4-
> > > > >
> > > > > > rp7!1bH43_JT7scsjwzrGD8lPeXvlXh9WieG2jadu9NICLiUrW-
> > > > >
> > > > > > WeUZR3sOMdn4NpaBSRqIM$ ).
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>> I am new to writing drivers and have two questions I am
> > > > > > >>> hoping you can
> > > > >
> > > > > > help me with:
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>> 1) In the driver I see the following code:
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>> static const struct vc5_chip_info idt_5p49v6901_info = {
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>             .model = IDT_VC6_5P49V6901,
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>             .clk_fod_cnt = 4,
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>             .clk_out_cnt = 5,
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>             .flags = VC5_HAS_PFD_FREQ_DBL,
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>> };
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>> static const struct vc5_chip_info idt_5p49v6965_info = {
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>             .model = IDT_VC6_5P49V6965,
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>             .clk_fod_cnt = 4,
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>             .clk_out_cnt = 5,
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>             .flags =  VC5_HAS_BYPASS_SYNC_BIT,
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>> };
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>> However, the 6965 part also has the same frequency doubling
> > > > > > >>> bit as the
> > > > >
> > > > > > 6901.  Would it be better to set the flags for the 6965 to
> > > > > > something like
> > > > this?
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>> static const struct vc5_chip_info idt_5p49v6965_info = {
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>             .model = IDT_VC6_5P49V6965,
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>             .clk_fod_cnt = 4,
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>             .clk_out_cnt = 5,
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>>             .flags = VC5_HAS_PFD_FREQ_DBL |
> > > > > > >>> VC5_HAS_BYPASS_SYNC_BIT,
> > > > >
> > > > > > >>>
> > > > >
> > > > > > >>> };
> > > > >
> > > > > > >>
> > > > >
> > > > > > >> I think Adam will have a better idea about this.
> > > > >
> > > > > > >>
> > > > >
> > > > > > >>> 2) I am unclear how to set the output frequencies for the
> > > > > > >>> device. For my
> > > > >
> > > > > > application I would like to set output clock 1 to 250MHz and
> > > > > > output clock 2 to
> > > > >
> > > > > > 46.8MHz but I am unclear how to do so.  I have looked at the
> > > > > > documentation
> > > > >
> > > > > > at
> > > > >
> > > > > >
> > > >
> > https://urldefense.com/v3/__https://mjmwired.net/kernel/Documentatio
> > > > > > n
> > > > >
> > > > > > /devicetree/bindings/clock/idt,versaclock5.yaml__;!!KnJ4-
> > > > >
> > > > > > rp7!1bH43_JT7scsjwzrGD8lPeXvlXh9WieG2jadu9NICLiUrW-
> > > > >
> > > > > > WeUZR3sOMdn4NpVQVg6al$  but remain unclear how to set the
> > output
> > > > >
> > > > > > frequencies.  Any insight you could provide would be greatly
> > appreciated.
> > > > >
> > > > > > >>
> > > > >
> > > > > > >> Use assigned-clock-frequencies as described in
> > > > >
> > > > > > >> Documentation/devicetree/bindings/clock/clock-bindings.txt
> > > > >
> > > > > > >>
> > > > >
> > > > > > >
> > > > >
> > > > > > > I agree that the clock-bindings have the instructions on how
> > > > > > > to set
> > > > >
> > > > > > > them.  If you check
> > > > >
> > > > > > > arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi, there
> > are
> > > > > > > some
> > > > >
> > > > > > > examples of how to set the frequency.
> > > > >
> > > > > > > In my instance,  the chip wasn't enabling the output by
> > > > > > > default, so I
> > > > >
> > > > > > > needed to submit some patches upstream to make sure the device
> > > > > > > that
> > > > >
> > > > > > > was being clocked by this device had get and enable functions
> > > > > > > to make
> > > > >
> > > > > > > sure the clock chip would turn on the clock when requested.
> > > > >
> > > > > >
> > > > >
> > > > > > Indeed assigned-clocks is the way to enable a clock when the
> > > > > > downstream
> > > > >
> > > > > > driver does not request it. Not that it is easy to find: it took
> > > > > > me a while to find
> > > > >
> > > > > > it the first time I needed it.
> > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > Trying to follow the example beacon-renesom-som.dtsi
> > > > > implementation
> > > > but am still not getting proper output.  I should note I am running
> > > > this as a patch on an older Petalinux  code base
> > > > (4.14.0-xilinx-v2018.3). After replacing
> > > > dev_err_probe() calls with older dev_err() calls the code compiles
> > > > and seems to run without issue. Is it possible other files need to be
> > updated?
> > > > >
> > > > >
> > > > >
> > > > > Added the provider code at the beginning of dtsi as follows;
> > > > >
> > > > > #include <dt-bindings/clk/versaclock.h>
> > > > >
> > > > >
> > > > >
> > > > > /include/ "system-conf.dtsi"
> > > > >
> > > > > / {
> > > > >
> > > > >   /* Clock Provider */
> > > > >
> > > > >   x304_clk: x304-clock {
> > > > >
> > > > >     compatible = "fixed-clock";
> > > > >
> > > > >     #clock-cells = <0>;
> > > > >
> > > > >     clock-frequency = <25000000>;
> > > > >
> > > > >   };
> > > > >
> > > > > …
> > > > >
> > > > >
> > > > >
> > > > > And added consumer code:
> > > > >
> > > > >
> > > > >
> > > > > &i2c1 {
> > > > >
> > > > >     clock-frequency = <100000>;
> > > > >
> > > > >
> > > > >
> > > > >     // Use patch.  Updated driver for 5p49v6965 available  at
> > > > > https://urldefense.com/v3/__https://github.com/Xilinx/linux-xlnx/b
> > > > > lob/
> > > > > master/drivers/clk/clk-versaclock5.c__;!!KnJ4-rp7!3K4sRtgFBeaZQ8Ir
> > > > > EvZ8 dkvJDiPMBlDRradrS0adfnpa1dNXMNjeIwNfOyHPLkFkwVpJ$
> > > > >
> > > > >     // Device Tree Setup ->
> > > > > https://urldefense.com/v3/__https://github.com/Xilinx/linux-xlnx/b
> > > > > lob/
> > > > >
> > > >
> > master/Documentation/devicetree/bindings/clock/idt*2Cversaclock5.yam
> > > > l_
> > > > > _;JQ!!KnJ4-
> > > > rp7!3K4sRtgFBeaZQ8IrEvZ8dkvJDiPMBlDRradrS0adfnpa1dNXMNjeIwN
> > > > > fOyHPLhF0Uums$
> > > > >
> > > > >     versaclock6: clock-controller@6a {
> > > > >
> > > > >         /* Clock Consumer */
> > > > >
> > > > >         compatible = "idt,5p49v6965";
> > > > >
> > > > >                                 reg = <0x6a>;
> > > > >
> > > > >                                 #clock-cells = <1>;
> > > > >
> > > > >                                 clocks = <&x304_clk>;
> > > > >
> > > > >                                 clock-names = "xin";
> > > > >
> > > > >
> > > > >
> > > > >         assigned_clocks = <&versaclock6 1>,
> > > > >
> > > > >                           <&versaclock6 2>,
> > > > >
> > > > >                           <&versaclock6 3>,
> > > > >
> > > > >                           <&versaclock6 4>;
> > > > >
> > > > >         assigned_clock_rates = <46800000>, <250000000>, <1000000>,
> > > > > <13000000>;
> > > >
> > > >
> > > > Assigned clocks and assigned clock rates should be hyphens and not
> > > > underscores.
> > > >
> > > > assigned-clocks =  <&versaclock6 1>,   <&versaclock6 2>,
> > > > <&versaclock6 3>, <&versaclock6 4>;
> > > >
> > > > assigned-clock-rates =  <46800000>, <250000000>, <1000000>,
> > > > <13000000>;
> > > >
> > > > Another thing to check is to make sure the consumers of these clocks
> > > > is enabling them.  They do not necessarily get enabled by default.
> > > >
> > > > adam
> > >
> > > Doh - thanks.  I looked at it a million times 😊 .
> > >
> > > Now getting desired out1 frequency but nothing on other outputs.  From
> > the code it seems vc5_clk_out_prepare() is the method that enables outputs
> > but this method is not being called I am not clear how to make the 'consumer
> > enable them.'
> > >
> > > I have added this to my dtsi to no avail.
> > >
> > >          /* Consumer referencing 5P49V5965 pin OUT1 and OUT2 */
> > >         consumer {
> > >             clocks = <&versaclock6 1>, <&versaclock6 2>;
> > >             /* ... */
> > >          };
> > >
> > > Looking through device tree documentation.
> >
> > It's likely going to be in the consumer's driver.  Check the consumer device
> > tree binding to make sure you've correctly associated the clock.  If the
> > binding doesnt't show a clock is required, it might not know that you using a
> > programmable clock.
> >
> > Here is a patch that I needed to apply to an Ethernet driver which wasn't
> > expecting a programmable clock to drive a reference clock, so the clock
> > wasn't being enabled.
> >
> > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/g
> > it/torvalds/linux.git/commit/drivers/net/ethernet/renesas/ravb_main.c?id=
> > 8ef7adc6beb2ef0bce83513dc9e4505e7b21e8c2__;!!KnJ4-rp7!1Qb17q-
> > TWrV62AeQtTNNVDErVbyhbXB1sukyT2ggvFPUltIBI5nIKzNnjVOcqlw8qJyy$
> >
> > Look at the use of devm_clk_get_optional and clk_prepare_enable from that
> > patch.  (yes, there is a subsequent patch that fixes something I didn't quite
> > do right, but the basics are here)
> >
> > The consumer drivers need to 'get' the clock so it can associate itself to the
> > clock in question.  Once the relationship is established, the consumer needs
> > to call clk_prepare_enable() which uses the clock system to turn the clock on.
> > Without this step, it's likely the Versaclock won't generate a signal, because it
> > doesn't know it needs to turn it on.
> >
> > adam
>
> Not sure I fully follow.  I see that clk out1 is enabled but the other channels are not so it would seem my difficulty is with individual channels.

Do the devices that need the clock from the versaclock reference the
versaclock?  If so, to those drivers use the get and enable?  If not,
the versaclock will stay off.  In the patch example I showed, I had to
modify the Ethernet driver on a processor, because it didn't
explicitly enable the reference clock.  That Ethernet driver expected
the refclk was always present which was a false assumption.  Once I
got the consumer device (in this case, Ethernet) to request and enable
the clock, the clock subsystem enabled the corresponding output on the
versaclock.

For the Ethernet example I cited above, the corresponding device tree
looks like:

&avb {
     clocks = <&cpg CPG_MOD 812>, <&versaclock5 4>;
     clock-names = "fck", "refclk";
     status = "okay";
};

With this device tree reference, the 'refclk' gets associated to
versaclock ouput 4.  When the Ethernet needs the clock, it calls
clk_prepare_enable on that clock reference, and the clock system calls
on the versaclock driver to enable the output.  The reason I needed to
submit that patch was that the consumer driver (the Ethernet in this
case) wasn't calling the clk_prepare_enable, so the clock remained
off.  It's likely that whatever devices that need the clock from the
versaclock will need both a device tree reference to it as well as a
call to clk_prepare_enable.

>
> In my simple application I would like to enable outputs, on a per channel basis, from the device tree.  Would it make sense  to add  an 'idt,enable' property in similar fashion to the existing idt,mode, idt,voltage-microvolt, and idt,slew-percent properties?  Then vc5_get_output_config() could be modified to also call vc5_clk_out_prepare() (or clk_prepare_enable(), which in turn would call vc5_clk_out_prepare()).

I can't speak for the linux clock group, but the advantage of patching
the drivers that need the clocks generated from the versaclock is the
ability to stop these clocks when the drivers are halted and/or
suspended.

adam
>
> Seems like this would work nicely for my application but not sure it would be generally useful.
>
> -Claude
>
> > >
> > > >
> > > >
> > > >
> > > > >
> > > > >         /* Set the SD/OE pin's settings */
> > > > >
> > > > >         OUT1 {
> > > > >
> > > > >             idt,mode = <VC5_LVDS>;
> > > > >
> > > > >             idt,voltage-microvolt = <3300000>;
> > > > >
> > > > >             idt,slew-percent = <100>;
> > > > >
> > > > >         };
> > > > >
> > > > >         OUT2 {
> > > > >
> > > > >             idt,mode = <VC5_LVDS>;
> > > > >
> > > > >             idt,voltage-microvolt = <3300000>;
> > > > >
> > > > >             idt,slew-percent = <100>;
> > > > >
> > > > >         };
> > > > >
> > > > >         OUT3 {
> > > > >
> > > > >             idt,mode = <VC5_LVDS>;
> > > > >
> > > > >             idt,voltage-microvolt = <3300000>;
> > > > >
> > > > >             idt,slew-percent = <100>;
> > > > >
> > > > >         };
> > > > >
> > > > >         OUT4 {
> > > > >
> > > > >             idt,mode = <VC5_LVDS>;
> > > > >
> > > > >             idt,voltage-microvolt = <3300000>;
> > > > >
> > > > >             idt,slew-percent = <100>;
> > > > >
> > > > >         };
> > > > >
> > > > >     };
> > > > >
> > > > > …
> > > > >
> > > > >
> > > > >
> > > > > But still only seeing default clocks (100MHz on out 1, nothing on out2-4).
> > > > >
> > > > >
> > > > >
> > > > > Any suggestions?
> > > > >
> > > > >
> > > > >
> > > > > > >>> I saw your name mentioned so I am emailing  you directly.
> > > > > > >>> If there is a
> > > > >
> > > > > > better place to ask these questions can you please direct me there?
> > > > > > Thanks
> > > > >
> > > > > > you so much.
> > > > >
> > > > > > >>
> > > > >
> > > > > > >> Adam (CC'd) wrote the original driver, so he's probably a
> > > > > > >> better
> > > > >
> > > > > > >> person to start with. You should also CC the linux-clk
> > > > > > >> mailing list
> > > > >
> > > > > > >> for questions about clock drivers.
> > > > >
> > > > > > >
> > > > >
> > > > > > > I've reviewed the datasheet for the 6965, and it doesn't
> > > > > > > explicitly
> > > > >
> > > > > > > show the multiplier, but the programmer's guide does appear to
> > > > > > > show
> > > > >
> > > > > > > the existence of bit that when set, it will "double the
> > > > > > > reference
> > > > >
> > > > > > > frequency for the Phase frequency detector" but on the
> > > > > > > programmer's
> > > > >
> > > > > > > guide for the 6901, the same bit reads "Enables frequency
> > > > > > > doubler when
> > > > >
> > > > > > > set to 1" so it's not clear to me that these functions are
> > > > > > > exactly the
> > > > >
> > > > > > > same, but implies that it might be.  I'll need some time to
> > > > > > > test this,
> > > > >
> > > > > > > but if I find it works, I can push a patch to this driver.  I
> > > > > > > added
> > > > >
> > > > > > > Luca, as he is the maintainer for this driver as well.
> > > > >
> > > > > >
> > > > >
> > > > > > Thanks Adam. I'm afraid I have no detailed answer as I never
> > > > > > tried this bit,
> > > > >
> > > > > > but according to the docs indeed it looks like there is a
> > > > > > doubler as you
> > > > >
> > > > > > noticed, that it is disabled by default. It would be nice to
> > > > > > test it and submit a
> > > > >
> > > > > > patch, thanks!
> > > > >
> > > > > >
> > > > >
> > > > > > --
> > > > >
> > > > > > Luca
> > > > >
> > > > >
> > > > >
> > > > > For what it's worth, I have played around with Renesas' Timing
> > > > > Commander
> > > > tool and they seem to use the doubler bit in the same fashion.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Claude
> > > > >
> > > > > ________________________________
> > > > > This message and any attachments are intended only for the
> > > > > designated
> > > > recipient(s) and may contain confidential or proprietary information
> > > > and be subject to the attorney-client privilege or other
> > > > confidentiality protections. If you are not a designated recipient,
> > > > you may not review, use, copy or distribute this message or any
> > > > attachments. If you received this email in error, please notify the
> > > > sender by reply e-mail and permanently delete the original and any
> > > > copies of this message and any attachments thereto. Thank you.
> > >
> > >
> > ==========================================================
> > ============
> > > This message and any attachments are intended only for the designated
> > recipient(s) and may contain confidential or proprietary information and be
> > subject to the attorney-client privilege or other confidentiality protections.  If
> > you are not a designated recipient, you may not review, use, copy or
> > distribute this message or any attachments.  If you received this email in
> > error, please notify the sender by reply e-mail and permanently delete the
> > original and any copies of this message and any attachments thereto.  Thank
> > you.
>
> ======================================================================
> This message and any attachments are intended only for the designated recipient(s) and may contain confidential or proprietary information and be subject to the attorney-client privilege or other confidentiality protections.  If you are not a designated recipient, you may not review, use, copy or distribute this message or any attachments.  If you received this email in error, please notify the sender by reply e-mail and permanently delete the original and any copies of this message and any attachments thereto.  Thank you.

Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Luca Ceresoli]

Hi,

On 02/03/22 16:45, Adam Ford wrote:
...
>>>>>>     versaclock6: clock-controller@6a {
>>>>>>
>>>>>>         /* Clock Consumer */
>>>>>>
>>>>>>         compatible = "idt,5p49v6965";
>>>>>>
>>>>>>                                 reg = <0x6a>;
>>>>>>
>>>>>>                                 #clock-cells = <1>;
>>>>>>
>>>>>>                                 clocks = <&x304_clk>;
>>>>>>
>>>>>>                                 clock-names = "xin";
>>>>>>
>>>>>>
>>>>>>
>>>>>>         assigned_clocks = <&versaclock6 1>,
>>>>>>
>>>>>>                           <&versaclock6 2>,
>>>>>>
>>>>>>                           <&versaclock6 3>,
>>>>>>
>>>>>>                           <&versaclock6 4>;
>>>>>>
>>>>>>         assigned_clock_rates = <46800000>, <250000000>, <1000000>,
>>>>>> <13000000>;
>>>>>
>>>>>
>>>>> Assigned clocks and assigned clock rates should be hyphens and not
>>>>> underscores.
>>>>>
>>>>> assigned-clocks =  <&versaclock6 1>,   <&versaclock6 2>,
>>>>> <&versaclock6 3>, <&versaclock6 4>;
>>>>>
>>>>> assigned-clock-rates =  <46800000>, <250000000>, <1000000>,
>>>>> <13000000>;
>>>>>
>>>>> Another thing to check is to make sure the consumers of these clocks
>>>>> is enabling them.  They do not necessarily get enabled by default.
>>>>>
>>>>> adam
>>>>
>>>> Doh - thanks.  I looked at it a million times 😊 .
>>>>
>>>> Now getting desired out1 frequency but nothing on other outputs.  From
>>> the code it seems vc5_clk_out_prepare() is the method that enables outputs
>>> but this method is not being called I am not clear how to make the 'consumer
>>> enable them.'
>>>>
>>>> I have added this to my dtsi to no avail.
>>>>
>>>>          /* Consumer referencing 5P49V5965 pin OUT1 and OUT2 */
>>>>         consumer {
>>>>             clocks = <&versaclock6 1>, <&versaclock6 2>;
>>>>             /* ... */
>>>>          };
>>>>
>>>> Looking through device tree documentation.
>>>
>>> It's likely going to be in the consumer's driver.  Check the consumer device
>>> tree binding to make sure you've correctly associated the clock.  If the
>>> binding doesnt't show a clock is required, it might not know that you using a
>>> programmable clock.
>>>
>>> Here is a patch that I needed to apply to an Ethernet driver which wasn't
>>> expecting a programmable clock to drive a reference clock, so the clock
>>> wasn't being enabled.
>>>
>>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/g
>>> it/torvalds/linux.git/commit/drivers/net/ethernet/renesas/ravb_main.c?id=
>>> 8ef7adc6beb2ef0bce83513dc9e4505e7b21e8c2__;!!KnJ4-rp7!1Qb17q-
>>> TWrV62AeQtTNNVDErVbyhbXB1sukyT2ggvFPUltIBI5nIKzNnjVOcqlw8qJyy$
>>>
>>> Look at the use of devm_clk_get_optional and clk_prepare_enable from that
>>> patch.  (yes, there is a subsequent patch that fixes something I didn't quite
>>> do right, but the basics are here)
>>>
>>> The consumer drivers need to 'get' the clock so it can associate itself to the
>>> clock in question.  Once the relationship is established, the consumer needs
>>> to call clk_prepare_enable() which uses the clock system to turn the clock on.
>>> Without this step, it's likely the Versaclock won't generate a signal, because it
>>> doesn't know it needs to turn it on.
>>>
>>> adam
>>
>> Not sure I fully follow.  I see that clk out1 is enabled but the other channels are not so it would seem my difficulty is with individual channels.
> 
> Do the devices that need the clock from the versaclock reference the
> versaclock?  If so, to those drivers use the get and enable?  If not,
> the versaclock will stay off.  In the patch example I showed, I had to
> modify the Ethernet driver on a processor, because it didn't
> explicitly enable the reference clock.  That Ethernet driver expected
> the refclk was always present which was a false assumption.  Once I
> got the consumer device (in this case, Ethernet) to request and enable
> the clock, the clock subsystem enabled the corresponding output on the
> versaclock.
> 
> For the Ethernet example I cited above, the corresponding device tree
> looks like:
> 
> &avb {
>      clocks = <&cpg CPG_MOD 812>, <&versaclock5 4>;
>      clock-names = "fck", "refclk";
>      status = "okay";
> };
> 
> With this device tree reference, the 'refclk' gets associated to
> versaclock ouput 4.  When the Ethernet needs the clock, it calls
> clk_prepare_enable on that clock reference, and the clock system calls
> on the versaclock driver to enable the output.  The reason I needed to
> submit that patch was that the consumer driver (the Ethernet in this
> case) wasn't calling the clk_prepare_enable, so the clock remained
> off.  It's likely that whatever devices that need the clock from the
> versaclock will need both a device tree reference to it as well as a
> call to clk_prepare_enable.
> 
>>
>> In my simple application I would like to enable outputs, on a per channel basis, from the device tree.  Would it make sense  to add  an 'idt,enable' property in similar fashion to the existing idt,mode, idt,voltage-microvolt, and idt,slew-percent properties?  Then vc5_get_output_config() could be modified to also call vc5_clk_out_prepare() (or clk_prepare_enable(), which in turn would call vc5_clk_out_prepare()).
> 
> I can't speak for the linux clock group, but the advantage of patching
> the drivers that need the clocks generated from the versaclock is the
> ability to stop these clocks when the drivers are halted and/or
> suspended.

Having the consumer driver get, prepare and enable the clock is of
course the best as Adam explained.

However I think using assigned-clocks and assigned-clock-rates should
enable the clocks unconditionally even if the consumer driver does not
do any clk_*() calls. Might be worth double checking that.

-- 
Luca

RE: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Fillion, Claude]

> -----Original Message-----
> From: Luca Ceresoli <luca@lucaceresoli.net>
> Sent: Wednesday, March 2, 2022 12:27 PM
> To: Adam Ford <aford173@gmail.com>; Fillion, Claude
> <Claude.Fillion@mksinst.com>
> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> clk@vger.kernel.org>
> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> versaclock5 driver
> 
> Hi,
> 
> On 02/03/22 16:45, Adam Ford wrote:
> ...
> >>>>>>     versaclock6: clock-controller@6a {
> >>>>>>
> >>>>>>         /* Clock Consumer */
> >>>>>>
> >>>>>>         compatible = "idt,5p49v6965";
> >>>>>>
> >>>>>>                                 reg = <0x6a>;
> >>>>>>
> >>>>>>                                 #clock-cells = <1>;
> >>>>>>
> >>>>>>                                 clocks = <&x304_clk>;
> >>>>>>
> >>>>>>                                 clock-names = "xin";
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>         assigned_clocks = <&versaclock6 1>,
> >>>>>>
> >>>>>>                           <&versaclock6 2>,
> >>>>>>
> >>>>>>                           <&versaclock6 3>,
> >>>>>>
> >>>>>>                           <&versaclock6 4>;
> >>>>>>
> >>>>>>         assigned_clock_rates = <46800000>, <250000000>,
> >>>>>> <1000000>, <13000000>;
> >>>>>
> >>>>>
> >>>>> Assigned clocks and assigned clock rates should be hyphens and not
> >>>>> underscores.
> >>>>>
> >>>>> assigned-clocks =  <&versaclock6 1>,   <&versaclock6 2>,
> >>>>> <&versaclock6 3>, <&versaclock6 4>;
> >>>>>
> >>>>> assigned-clock-rates =  <46800000>, <250000000>, <1000000>,
> >>>>> <13000000>;
> >>>>>
> >>>>> Another thing to check is to make sure the consumers of these
> >>>>> clocks is enabling them.  They do not necessarily get enabled by
> default.
> >>>>>
> >>>>> adam
> >>>>
> >>>> Doh - thanks.  I looked at it a million times 😊 .
> >>>>
> >>>> Now getting desired out1 frequency but nothing on other outputs.
> >>>> From
> >>> the code it seems vc5_clk_out_prepare() is the method that enables
> >>> outputs but this method is not being called I am not clear how to
> >>> make the 'consumer enable them.'
> >>>>
> >>>> I have added this to my dtsi to no avail.
> >>>>
> >>>>          /* Consumer referencing 5P49V5965 pin OUT1 and OUT2 */
> >>>>         consumer {
> >>>>             clocks = <&versaclock6 1>, <&versaclock6 2>;
> >>>>             /* ... */
> >>>>          };
> >>>>
> >>>> Looking through device tree documentation.
> >>>
> >>> It's likely going to be in the consumer's driver.  Check the
> >>> consumer device tree binding to make sure you've correctly
> >>> associated the clock.  If the binding doesnt't show a clock is
> >>> required, it might not know that you using a programmable clock.
> >>>
> >>> Here is a patch that I needed to apply to an Ethernet driver which
> >>> wasn't expecting a programmable clock to drive a reference clock, so
> >>> the clock wasn't being enabled.
> >>>
> >>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/ker
> >>> nel/g
> >>> it/torvalds/linux.git/commit/drivers/net/ethernet/renesas/ravb_main.
> >>> c?id=
> >>> 8ef7adc6beb2ef0bce83513dc9e4505e7b21e8c2__;!!KnJ4-rp7!1Qb17q-
> >>>
> TWrV62AeQtTNNVDErVbyhbXB1sukyT2ggvFPUltIBI5nIKzNnjVOcqlw8qJyy$
> >>>
> >>> Look at the use of devm_clk_get_optional and clk_prepare_enable from
> >>> that patch.  (yes, there is a subsequent patch that fixes something
> >>> I didn't quite do right, but the basics are here)
> >>>
> >>> The consumer drivers need to 'get' the clock so it can associate
> >>> itself to the clock in question.  Once the relationship is
> >>> established, the consumer needs to call clk_prepare_enable() which
> uses the clock system to turn the clock on.
> >>> Without this step, it's likely the Versaclock won't generate a
> >>> signal, because it doesn't know it needs to turn it on.
> >>>
> >>> adam
> >>
> >> Not sure I fully follow.  I see that clk out1 is enabled but the other
> channels are not so it would seem my difficulty is with individual channels.
> >
> > Do the devices that need the clock from the versaclock reference the
> > versaclock?  If so, to those drivers use the get and enable?  If not,
> > the versaclock will stay off.  In the patch example I showed, I had to
> > modify the Ethernet driver on a processor, because it didn't
> > explicitly enable the reference clock.  That Ethernet driver expected
> > the refclk was always present which was a false assumption.  Once I
> > got the consumer device (in this case, Ethernet) to request and enable
> > the clock, the clock subsystem enabled the corresponding output on the
> > versaclock.
> >
> > For the Ethernet example I cited above, the corresponding device tree
> > looks like:
> >
> > &avb {
> >      clocks = <&cpg CPG_MOD 812>, <&versaclock5 4>;
> >      clock-names = "fck", "refclk";
> >      status = "okay";
> > };
> >
> > With this device tree reference, the 'refclk' gets associated to
> > versaclock ouput 4.  When the Ethernet needs the clock, it calls
> > clk_prepare_enable on that clock reference, and the clock system calls
> > on the versaclock driver to enable the output.  The reason I needed to
> > submit that patch was that the consumer driver (the Ethernet in this
> > case) wasn't calling the clk_prepare_enable, so the clock remained
> > off.  It's likely that whatever devices that need the clock from the
> > versaclock will need both a device tree reference to it as well as a
> > call to clk_prepare_enable.
> >
> >>
> >> In my simple application I would like to enable outputs, on a per channel
> basis, from the device tree.  Would it make sense  to add  an 'idt,enable'
> property in similar fashion to the existing idt,mode, idt,voltage-microvolt,
> and idt,slew-percent properties?  Then vc5_get_output_config() could be
> modified to also call vc5_clk_out_prepare() (or clk_prepare_enable(), which
> in turn would call vc5_clk_out_prepare()).
> >
> > I can't speak for the linux clock group, but the advantage of patching
> > the drivers that need the clocks generated from the versaclock is the
> > ability to stop these clocks when the drivers are halted and/or
> > suspended.
> 
> Having the consumer driver get, prepare and enable the clock is of course
> the best as Adam explained.
> 
> However I think using assigned-clocks and assigned-clock-rates should
> enable the clocks unconditionally even if the consumer driver does not do
> any clk_*() calls. Might be worth double checking that.
> 
> --
> Luca

In our application we plan to use the 6965/6901 to replace a part that does not use a consumer driver.  We just set clock options in our device tree.  Ideally that is how we would like to use the Renesas part as well. 

In the limited testing I have done thus far behavior is a bit puzzling.  From the device tree I am able to change the clock frequency for out1 (which is enabled by default) and I can disable outputs using 'idt,shutdown', but I cannot change the logic levels for out1 using the 'idt,mode' parameter.  Clock outputs for out2-4 are disabled by default so haven't tested those yet.

Enabling the clocks unconditionally would help in our use case, but individually enabling/disabling via device tree would be more helpful.

-Claude

======================================================================
This message and any attachments are intended only for the designated recipient(s) and may contain confidential or proprietary information and be subject to the attorney-client privilege or other confidentiality protections.  If you are not a designated recipient, you may not review, use, copy or distribute this message or any attachments.  If you received this email in error, please notify the sender by reply e-mail and permanently delete the original and any copies of this message and any attachments thereto.  Thank you.

Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Luca Ceresoli]

Hi Claude,

On 02/03/22 21:49, Fillion, Claude wrote:
> 
> 
>> -----Original Message-----
>> From: Luca Ceresoli <luca@lucaceresoli.net>
>> Sent: Wednesday, March 2, 2022 12:27 PM
>> To: Adam Ford <aford173@gmail.com>; Fillion, Claude
>> <Claude.Fillion@mksinst.com>
>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
>> clk@vger.kernel.org>
>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
>> versaclock5 driver
>>
>> Hi,
>>
>> On 02/03/22 16:45, Adam Ford wrote:
>> ...
>>>>>>>>     versaclock6: clock-controller@6a {
>>>>>>>>
>>>>>>>>         /* Clock Consumer */
>>>>>>>>
>>>>>>>>         compatible = "idt,5p49v6965";
>>>>>>>>
>>>>>>>>                                 reg = <0x6a>;
>>>>>>>>
>>>>>>>>                                 #clock-cells = <1>;
>>>>>>>>
>>>>>>>>                                 clocks = <&x304_clk>;
>>>>>>>>
>>>>>>>>                                 clock-names = "xin";
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>         assigned_clocks = <&versaclock6 1>,
>>>>>>>>
>>>>>>>>                           <&versaclock6 2>,
>>>>>>>>
>>>>>>>>                           <&versaclock6 3>,
>>>>>>>>
>>>>>>>>                           <&versaclock6 4>;
>>>>>>>>
>>>>>>>>         assigned_clock_rates = <46800000>, <250000000>,
>>>>>>>> <1000000>, <13000000>;
>>>>>>>
>>>>>>>
>>>>>>> Assigned clocks and assigned clock rates should be hyphens and not
>>>>>>> underscores.
>>>>>>>
>>>>>>> assigned-clocks =  <&versaclock6 1>,   <&versaclock6 2>,
>>>>>>> <&versaclock6 3>, <&versaclock6 4>;
>>>>>>>
>>>>>>> assigned-clock-rates =  <46800000>, <250000000>, <1000000>,
>>>>>>> <13000000>;
>>>>>>>
>>>>>>> Another thing to check is to make sure the consumers of these
>>>>>>> clocks is enabling them.  They do not necessarily get enabled by
>> default.
>>>>>>>
>>>>>>> adam
>>>>>>
>>>>>> Doh - thanks.  I looked at it a million times 😊 .
>>>>>>
>>>>>> Now getting desired out1 frequency but nothing on other outputs.
>>>>>> From
>>>>> the code it seems vc5_clk_out_prepare() is the method that enables
>>>>> outputs but this method is not being called I am not clear how to
>>>>> make the 'consumer enable them.'
>>>>>>
>>>>>> I have added this to my dtsi to no avail.
>>>>>>
>>>>>>          /* Consumer referencing 5P49V5965 pin OUT1 and OUT2 */
>>>>>>         consumer {
>>>>>>             clocks = <&versaclock6 1>, <&versaclock6 2>;
>>>>>>             /* ... */
>>>>>>          };
>>>>>>
>>>>>> Looking through device tree documentation.
>>>>>
>>>>> It's likely going to be in the consumer's driver.  Check the
>>>>> consumer device tree binding to make sure you've correctly
>>>>> associated the clock.  If the binding doesnt't show a clock is
>>>>> required, it might not know that you using a programmable clock.
>>>>>
>>>>> Here is a patch that I needed to apply to an Ethernet driver which
>>>>> wasn't expecting a programmable clock to drive a reference clock, so
>>>>> the clock wasn't being enabled.
>>>>>
>>>>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/ker
>>>>> nel/g
>>>>> it/torvalds/linux.git/commit/drivers/net/ethernet/renesas/ravb_main.
>>>>> c?id=
>>>>> 8ef7adc6beb2ef0bce83513dc9e4505e7b21e8c2__;!!KnJ4-rp7!1Qb17q-
>>>>>
>> TWrV62AeQtTNNVDErVbyhbXB1sukyT2ggvFPUltIBI5nIKzNnjVOcqlw8qJyy$
>>>>>
>>>>> Look at the use of devm_clk_get_optional and clk_prepare_enable from
>>>>> that patch.  (yes, there is a subsequent patch that fixes something
>>>>> I didn't quite do right, but the basics are here)
>>>>>
>>>>> The consumer drivers need to 'get' the clock so it can associate
>>>>> itself to the clock in question.  Once the relationship is
>>>>> established, the consumer needs to call clk_prepare_enable() which
>> uses the clock system to turn the clock on.
>>>>> Without this step, it's likely the Versaclock won't generate a
>>>>> signal, because it doesn't know it needs to turn it on.
>>>>>
>>>>> adam
>>>>
>>>> Not sure I fully follow.  I see that clk out1 is enabled but the other
>> channels are not so it would seem my difficulty is with individual channels.
>>>
>>> Do the devices that need the clock from the versaclock reference the
>>> versaclock?  If so, to those drivers use the get and enable?  If not,
>>> the versaclock will stay off.  In the patch example I showed, I had to
>>> modify the Ethernet driver on a processor, because it didn't
>>> explicitly enable the reference clock.  That Ethernet driver expected
>>> the refclk was always present which was a false assumption.  Once I
>>> got the consumer device (in this case, Ethernet) to request and enable
>>> the clock, the clock subsystem enabled the corresponding output on the
>>> versaclock.
>>>
>>> For the Ethernet example I cited above, the corresponding device tree
>>> looks like:
>>>
>>> &avb {
>>>      clocks = <&cpg CPG_MOD 812>, <&versaclock5 4>;
>>>      clock-names = "fck", "refclk";
>>>      status = "okay";
>>> };
>>>
>>> With this device tree reference, the 'refclk' gets associated to
>>> versaclock ouput 4.  When the Ethernet needs the clock, it calls
>>> clk_prepare_enable on that clock reference, and the clock system calls
>>> on the versaclock driver to enable the output.  The reason I needed to
>>> submit that patch was that the consumer driver (the Ethernet in this
>>> case) wasn't calling the clk_prepare_enable, so the clock remained
>>> off.  It's likely that whatever devices that need the clock from the
>>> versaclock will need both a device tree reference to it as well as a
>>> call to clk_prepare_enable.
>>>
>>>>
>>>> In my simple application I would like to enable outputs, on a per channel
>> basis, from the device tree.  Would it make sense  to add  an 'idt,enable'
>> property in similar fashion to the existing idt,mode, idt,voltage-microvolt,
>> and idt,slew-percent properties?  Then vc5_get_output_config() could be
>> modified to also call vc5_clk_out_prepare() (or clk_prepare_enable(), which
>> in turn would call vc5_clk_out_prepare()).
>>>
>>> I can't speak for the linux clock group, but the advantage of patching
>>> the drivers that need the clocks generated from the versaclock is the
>>> ability to stop these clocks when the drivers are halted and/or
>>> suspended.
>>
>> Having the consumer driver get, prepare and enable the clock is of course
>> the best as Adam explained.
>>
>> However I think using assigned-clocks and assigned-clock-rates should
>> enable the clocks unconditionally even if the consumer driver does not do
>> any clk_*() calls. Might be worth double checking that.
>>
>> --
>> Luca
> 
> In our application we plan to use the 6965/6901 to replace a part that does not use a consumer driver.  We just set clock options in our device tree.  Ideally that is how we would like to use the Renesas part as well. 
> 
> In the limited testing I have done thus far behavior is a bit puzzling.  From the device tree I am able to change the clock frequency for out1 (which is enabled by default) and I can disable outputs using 'idt,shutdown', but I cannot change the logic levels for out1 using the 'idt,mode' parameter.

This is very strange.

Did you double-check that your device tree description of the versaclock
node is correct according to [0]?

Please send the complete  description of the versaclock node in your
device tree, so we can check it and see if any detail is misplaced.

[0]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml#n169


-- 
Luca

RE: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Fillion, Claude]

Hello Luca,

> -----Original Message-----
> From: Luca Ceresoli <luca@lucaceresoli.net>
> Sent: Thursday, March 3, 2022 9:42 AM
> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> <aford173@gmail.com>
> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> versaclock5 driver
> 
> Hi Claude,
> 
> On 02/03/22 21:49, Fillion, Claude wrote:
> >
> >
> >> -----Original Message-----
> >> From: Luca Ceresoli <luca@lucaceresoli.net>
> >> Sent: Wednesday, March 2, 2022 12:27 PM
> >> To: Adam Ford <aford173@gmail.com>; Fillion, Claude
> >> <Claude.Fillion@mksinst.com>
> >> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> >> clk@vger.kernel.org>
> >> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> >> versaclock5 driver
> >>
> >> Hi,
> >>
> >> On 02/03/22 16:45, Adam Ford wrote:
> >> ...
> >>>>>>>>     versaclock6: clock-controller@6a {
> >>>>>>>>
> >>>>>>>>         /* Clock Consumer */
> >>>>>>>>
> >>>>>>>>         compatible = "idt,5p49v6965";
> >>>>>>>>
> >>>>>>>>                                 reg = <0x6a>;
> >>>>>>>>
> >>>>>>>>                                 #clock-cells = <1>;
> >>>>>>>>
> >>>>>>>>                                 clocks = <&x304_clk>;
> >>>>>>>>
> >>>>>>>>                                 clock-names = "xin";
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>         assigned_clocks = <&versaclock6 1>,
> >>>>>>>>
> >>>>>>>>                           <&versaclock6 2>,
> >>>>>>>>
> >>>>>>>>                           <&versaclock6 3>,
> >>>>>>>>
> >>>>>>>>                           <&versaclock6 4>;
> >>>>>>>>
> >>>>>>>>         assigned_clock_rates = <46800000>, <250000000>,
> >>>>>>>> <1000000>, <13000000>;
> >>>>>>>
> >>>>>>>
> >>>>>>> Assigned clocks and assigned clock rates should be hyphens and
> >>>>>>> not underscores.
> >>>>>>>
> >>>>>>> assigned-clocks =  <&versaclock6 1>,   <&versaclock6 2>,
> >>>>>>> <&versaclock6 3>, <&versaclock6 4>;
> >>>>>>>
> >>>>>>> assigned-clock-rates =  <46800000>, <250000000>, <1000000>,
> >>>>>>> <13000000>;
> >>>>>>>
> >>>>>>> Another thing to check is to make sure the consumers of these
> >>>>>>> clocks is enabling them.  They do not necessarily get enabled by
> >> default.
> >>>>>>>
> >>>>>>> adam
> >>>>>>
> >>>>>> Doh - thanks.  I looked at it a million times 😊 .
> >>>>>>
> >>>>>> Now getting desired out1 frequency but nothing on other outputs.
> >>>>>> From
> >>>>> the code it seems vc5_clk_out_prepare() is the method that enables
> >>>>> outputs but this method is not being called I am not clear how to
> >>>>> make the 'consumer enable them.'
> >>>>>>
> >>>>>> I have added this to my dtsi to no avail.
> >>>>>>
> >>>>>>          /* Consumer referencing 5P49V5965 pin OUT1 and OUT2 */
> >>>>>>         consumer {
> >>>>>>             clocks = <&versaclock6 1>, <&versaclock6 2>;
> >>>>>>             /* ... */
> >>>>>>          };
> >>>>>>
> >>>>>> Looking through device tree documentation.
> >>>>>
> >>>>> It's likely going to be in the consumer's driver.  Check the
> >>>>> consumer device tree binding to make sure you've correctly
> >>>>> associated the clock.  If the binding doesnt't show a clock is
> >>>>> required, it might not know that you using a programmable clock.
> >>>>>
> >>>>> Here is a patch that I needed to apply to an Ethernet driver which
> >>>>> wasn't expecting a programmable clock to drive a reference clock,
> >>>>> so the clock wasn't being enabled.
> >>>>>
> >>>>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/k
> >>>>> er
> >>>>> nel/g
> >>>>>
> it/torvalds/linux.git/commit/drivers/net/ethernet/renesas/ravb_main.
> >>>>> c?id=
> >>>>> 8ef7adc6beb2ef0bce83513dc9e4505e7b21e8c2__;!!KnJ4-rp7!1Qb17q-
> >>>>>
> >>
> TWrV62AeQtTNNVDErVbyhbXB1sukyT2ggvFPUltIBI5nIKzNnjVOcqlw8qJyy$
> >>>>>
> >>>>> Look at the use of devm_clk_get_optional and clk_prepare_enable
> >>>>> from that patch.  (yes, there is a subsequent patch that fixes
> >>>>> something I didn't quite do right, but the basics are here)
> >>>>>
> >>>>> The consumer drivers need to 'get' the clock so it can associate
> >>>>> itself to the clock in question.  Once the relationship is
> >>>>> established, the consumer needs to call clk_prepare_enable() which
> >> uses the clock system to turn the clock on.
> >>>>> Without this step, it's likely the Versaclock won't generate a
> >>>>> signal, because it doesn't know it needs to turn it on.
> >>>>>
> >>>>> adam
> >>>>
> >>>> Not sure I fully follow.  I see that clk out1 is enabled but the
> >>>> other
> >> channels are not so it would seem my difficulty is with individual channels.
> >>>
> >>> Do the devices that need the clock from the versaclock reference the
> >>> versaclock?  If so, to those drivers use the get and enable?  If
> >>> not, the versaclock will stay off.  In the patch example I showed, I
> >>> had to modify the Ethernet driver on a processor, because it didn't
> >>> explicitly enable the reference clock.  That Ethernet driver
> >>> expected the refclk was always present which was a false assumption.
> >>> Once I got the consumer device (in this case, Ethernet) to request
> >>> and enable the clock, the clock subsystem enabled the corresponding
> >>> output on the versaclock.
> >>>
> >>> For the Ethernet example I cited above, the corresponding device
> >>> tree looks like:
> >>>
> >>> &avb {
> >>>      clocks = <&cpg CPG_MOD 812>, <&versaclock5 4>;
> >>>      clock-names = "fck", "refclk";
> >>>      status = "okay";
> >>> };
> >>>
> >>> With this device tree reference, the 'refclk' gets associated to
> >>> versaclock ouput 4.  When the Ethernet needs the clock, it calls
> >>> clk_prepare_enable on that clock reference, and the clock system
> >>> calls on the versaclock driver to enable the output.  The reason I
> >>> needed to submit that patch was that the consumer driver (the
> >>> Ethernet in this
> >>> case) wasn't calling the clk_prepare_enable, so the clock remained
> >>> off.  It's likely that whatever devices that need the clock from the
> >>> versaclock will need both a device tree reference to it as well as a
> >>> call to clk_prepare_enable.
> >>>
> >>>>
> >>>> In my simple application I would like to enable outputs, on a per
> >>>> channel
> >> basis, from the device tree.  Would it make sense  to add  an 'idt,enable'
> >> property in similar fashion to the existing idt,mode,
> >> idt,voltage-microvolt, and idt,slew-percent properties?  Then
> >> vc5_get_output_config() could be modified to also call
> >> vc5_clk_out_prepare() (or clk_prepare_enable(), which in turn would call
> vc5_clk_out_prepare()).
> >>>
> >>> I can't speak for the linux clock group, but the advantage of
> >>> patching the drivers that need the clocks generated from the
> >>> versaclock is the ability to stop these clocks when the drivers are
> >>> halted and/or suspended.
> >>
> >> Having the consumer driver get, prepare and enable the clock is of
> >> course the best as Adam explained.
> >>
> >> However I think using assigned-clocks and assigned-clock-rates should
> >> enable the clocks unconditionally even if the consumer driver does
> >> not do any clk_*() calls. Might be worth double checking that.
> >>
> >> --
> >> Luca
> >
> > In our application we plan to use the 6965/6901 to replace a part that does
> not use a consumer driver.  We just set clock options in our device tree.
> Ideally that is how we would like to use the Renesas part as well.
> >
> > In the limited testing I have done thus far behavior is a bit puzzling.  From
> the device tree I am able to change the clock frequency for out1 (which is
> enabled by default) and I can disable outputs using 'idt,shutdown', but I
> cannot change the logic levels for out1 using the 'idt,mode' parameter.
> 
> This is very strange.
> 
> Did you double-check that your device tree description of the versaclock
> node is correct according to [0]?
> 
> Please send the complete  description of the versaclock node in your device
> tree, so we can check it and see if any detail is misplaced.
> 
> [0]
> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/g
> it/torvalds/linux.git/tree/Documentation/devicetree/bindings/clock/idt,vers
> aclock5.yaml*n169__;Iw!!KnJ4-
> rp7!yalfgsfaZKSlo4yNfQfvlbsmNKBRltGSetoIonP--5aGebuHUJ-M-
> am93tjT8aEhsSJJ$
> 
> 
> --
> Luca

Here is the relevant portions of my device tree.  On the scope I see the default 'CMOSD' voltages and a modified frequency of 46.8MHz.  

I have also modified my local copy of the driver to accept an 'idt,enable' pattern property that allows me to enable outputs from the device tree. It needs some refinement but I can pass it along if there is interest.

-Claude

==================
Top of device tree file:
==================
/*
This is a message for system-user.dtsi. If you are reading from system-user.dtsi.genxxxx, please note that this message is
for explaining the purpose of system-user.dist in relation to system-user.dtsi.genxxx.

system-user.dtsi is merely a writable file handled by ./buildPetaLinux.sh to copy the appropriate system-user.dtsi.genxxxx to this filename for use
in the build image. Do not put your device tree here. They belong to the system-user.dtsi.genxxxx.

If you add a new dtsi, please create an appropriate device tree file and modify the ./buildPetaLinux.sh to handle it 
*/

#include <dt-bindings/clk/versaclock.h>

/include/ "system-conf.dtsi"
/ {
 
  /* Clock Provider */
  x304_clk: x304-clock {
    compatible = "fixed-clock";
    #clock-cells = <0>;
    clock-frequency = <25000000>;
  };

...

==================
Device Tree Node:
==================
&i2c1 {
    clock-frequency = <100000>;

    // Use patch.  Updated driver for 5p49v6965 available  at https://github.com/Xilinx/linux-xlnx/blob/master/drivers/clk/clk-versaclock5.c
    // Device Tree Setup -> https://github.com/Xilinx/linux-xlnx/blob/master/Documentation/devicetree/bindings/clock/idt%2Cversaclock5.yaml
    versaclock6: clock-controller@6a {
        /* Clock Consumer */
        compatible = "idt,5p49v6965";
		reg = <0x6a>;
		#clock-cells = <1>;
		clocks = <&x304_clk>;
		clock-names = "xin";

        assigned-clocks = <&versaclock6 1>,
                          <&versaclock6 2>,
                          <&versaclock6 3>,
                          <&versaclock6 4>;
        // assigned-clock-rates = <46800000>, <250000000>, <1000000>, <13000000>;
        assigned-clock-rates = <46800000>, <250000000>, <1000000>, <13000000>;
        /* Set the SD/OE pin's settings */
        idt,shutdown = <0>;
        idt,output-enable-active = <0>;
        OUT1 {
            idt,mode = <VC5_CMOS>;
            idt,voltage-microvolt = <3300000>;
            idt,slew-percent = <100>;
        };
        OUT2 {
            idt,mode = <VC5_CMOS>;
            idt,voltage-microvolt = <3300000>;
            idt,slew-percent = <100>;
        };
        OUT3 {
            idt,mode = <VC5_CMOSD>;
            idt,voltage-microvolt = <3300000>;
            idt,slew-percent = <100>;
        };
        OUT4 {
            idt,mode = <VC5_CMOS>;
            idt,voltage-microvolt = <3300000>;
            idt,slew-percent = <100>;
        };
    };

======================================================================
This message and any attachments are intended only for the designated recipient(s) and may contain confidential or proprietary information and be subject to the attorney-client privilege or other confidentiality protections.  If you are not a designated recipient, you may not review, use, copy or distribute this message or any attachments.  If you received this email in error, please notify the sender by reply e-mail and permanently delete the original and any copies of this message and any attachments thereto.  Thank you.

Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Luca Ceresoli]

Hi Claude,

On 03/03/22 19:15, Fillion, Claude wrote:
> Hello Luca,
> 
>> -----Original Message-----
>> From: Luca Ceresoli <luca@lucaceresoli.net>
>> Sent: Thursday, March 3, 2022 9:42 AM
>> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
>> <aford173@gmail.com>
>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
>> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
>> versaclock5 driver
>>
>> Hi Claude,
>>
>> On 02/03/22 21:49, Fillion, Claude wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Luca Ceresoli <luca@lucaceresoli.net>
>>>> Sent: Wednesday, March 2, 2022 12:27 PM
>>>> To: Adam Ford <aford173@gmail.com>; Fillion, Claude
>>>> <Claude.Fillion@mksinst.com>
>>>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
>>>> clk@vger.kernel.org>
>>>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
>>>> versaclock5 driver
>>>>
>>>> Hi,
>>>>
>>>> On 02/03/22 16:45, Adam Ford wrote:
>>>> ...
>>>>>>>>>>     versaclock6: clock-controller@6a {
>>>>>>>>>>
>>>>>>>>>>         /* Clock Consumer */
>>>>>>>>>>
>>>>>>>>>>         compatible = "idt,5p49v6965";
>>>>>>>>>>
>>>>>>>>>>                                 reg = <0x6a>;
>>>>>>>>>>
>>>>>>>>>>                                 #clock-cells = <1>;
>>>>>>>>>>
>>>>>>>>>>                                 clocks = <&x304_clk>;
>>>>>>>>>>
>>>>>>>>>>                                 clock-names = "xin";
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>         assigned_clocks = <&versaclock6 1>,
>>>>>>>>>>
>>>>>>>>>>                           <&versaclock6 2>,
>>>>>>>>>>
>>>>>>>>>>                           <&versaclock6 3>,
>>>>>>>>>>
>>>>>>>>>>                           <&versaclock6 4>;
>>>>>>>>>>
>>>>>>>>>>         assigned_clock_rates = <46800000>, <250000000>,
>>>>>>>>>> <1000000>, <13000000>;
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Assigned clocks and assigned clock rates should be hyphens and
>>>>>>>>> not underscores.
>>>>>>>>>
>>>>>>>>> assigned-clocks =  <&versaclock6 1>,   <&versaclock6 2>,
>>>>>>>>> <&versaclock6 3>, <&versaclock6 4>;
>>>>>>>>>
>>>>>>>>> assigned-clock-rates =  <46800000>, <250000000>, <1000000>,
>>>>>>>>> <13000000>;
>>>>>>>>>
>>>>>>>>> Another thing to check is to make sure the consumers of these
>>>>>>>>> clocks is enabling them.  They do not necessarily get enabled by
>>>> default.
>>>>>>>>>
>>>>>>>>> adam
>>>>>>>>
>>>>>>>> Doh - thanks.  I looked at it a million times 😊 .
>>>>>>>>
>>>>>>>> Now getting desired out1 frequency but nothing on other outputs.
>>>>>>>> From
>>>>>>> the code it seems vc5_clk_out_prepare() is the method that enables
>>>>>>> outputs but this method is not being called I am not clear how to
>>>>>>> make the 'consumer enable them.'
>>>>>>>>
>>>>>>>> I have added this to my dtsi to no avail.
>>>>>>>>
>>>>>>>>          /* Consumer referencing 5P49V5965 pin OUT1 and OUT2 */
>>>>>>>>         consumer {
>>>>>>>>             clocks = <&versaclock6 1>, <&versaclock6 2>;
>>>>>>>>             /* ... */
>>>>>>>>          };
>>>>>>>>
>>>>>>>> Looking through device tree documentation.
>>>>>>>
>>>>>>> It's likely going to be in the consumer's driver.  Check the
>>>>>>> consumer device tree binding to make sure you've correctly
>>>>>>> associated the clock.  If the binding doesnt't show a clock is
>>>>>>> required, it might not know that you using a programmable clock.
>>>>>>>
>>>>>>> Here is a patch that I needed to apply to an Ethernet driver which
>>>>>>> wasn't expecting a programmable clock to drive a reference clock,
>>>>>>> so the clock wasn't being enabled.
>>>>>>>
>>>>>>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/k
>>>>>>> er
>>>>>>> nel/g
>>>>>>>
>> it/torvalds/linux.git/commit/drivers/net/ethernet/renesas/ravb_main.
>>>>>>> c?id=
>>>>>>> 8ef7adc6beb2ef0bce83513dc9e4505e7b21e8c2__;!!KnJ4-rp7!1Qb17q-
>>>>>>>
>>>>
>> TWrV62AeQtTNNVDErVbyhbXB1sukyT2ggvFPUltIBI5nIKzNnjVOcqlw8qJyy$
>>>>>>>
>>>>>>> Look at the use of devm_clk_get_optional and clk_prepare_enable
>>>>>>> from that patch.  (yes, there is a subsequent patch that fixes
>>>>>>> something I didn't quite do right, but the basics are here)
>>>>>>>
>>>>>>> The consumer drivers need to 'get' the clock so it can associate
>>>>>>> itself to the clock in question.  Once the relationship is
>>>>>>> established, the consumer needs to call clk_prepare_enable() which
>>>> uses the clock system to turn the clock on.
>>>>>>> Without this step, it's likely the Versaclock won't generate a
>>>>>>> signal, because it doesn't know it needs to turn it on.
>>>>>>>
>>>>>>> adam
>>>>>>
>>>>>> Not sure I fully follow.  I see that clk out1 is enabled but the
>>>>>> other
>>>> channels are not so it would seem my difficulty is with individual channels.
>>>>>
>>>>> Do the devices that need the clock from the versaclock reference the
>>>>> versaclock?  If so, to those drivers use the get and enable?  If
>>>>> not, the versaclock will stay off.  In the patch example I showed, I
>>>>> had to modify the Ethernet driver on a processor, because it didn't
>>>>> explicitly enable the reference clock.  That Ethernet driver
>>>>> expected the refclk was always present which was a false assumption.
>>>>> Once I got the consumer device (in this case, Ethernet) to request
>>>>> and enable the clock, the clock subsystem enabled the corresponding
>>>>> output on the versaclock.
>>>>>
>>>>> For the Ethernet example I cited above, the corresponding device
>>>>> tree looks like:
>>>>>
>>>>> &avb {
>>>>>      clocks = <&cpg CPG_MOD 812>, <&versaclock5 4>;
>>>>>      clock-names = "fck", "refclk";
>>>>>      status = "okay";
>>>>> };
>>>>>
>>>>> With this device tree reference, the 'refclk' gets associated to
>>>>> versaclock ouput 4.  When the Ethernet needs the clock, it calls
>>>>> clk_prepare_enable on that clock reference, and the clock system
>>>>> calls on the versaclock driver to enable the output.  The reason I
>>>>> needed to submit that patch was that the consumer driver (the
>>>>> Ethernet in this
>>>>> case) wasn't calling the clk_prepare_enable, so the clock remained
>>>>> off.  It's likely that whatever devices that need the clock from the
>>>>> versaclock will need both a device tree reference to it as well as a
>>>>> call to clk_prepare_enable.
>>>>>
>>>>>>
>>>>>> In my simple application I would like to enable outputs, on a per
>>>>>> channel
>>>> basis, from the device tree.  Would it make sense  to add  an 'idt,enable'
>>>> property in similar fashion to the existing idt,mode,
>>>> idt,voltage-microvolt, and idt,slew-percent properties?  Then
>>>> vc5_get_output_config() could be modified to also call
>>>> vc5_clk_out_prepare() (or clk_prepare_enable(), which in turn would call
>> vc5_clk_out_prepare()).
>>>>>
>>>>> I can't speak for the linux clock group, but the advantage of
>>>>> patching the drivers that need the clocks generated from the
>>>>> versaclock is the ability to stop these clocks when the drivers are
>>>>> halted and/or suspended.
>>>>
>>>> Having the consumer driver get, prepare and enable the clock is of
>>>> course the best as Adam explained.
>>>>
>>>> However I think using assigned-clocks and assigned-clock-rates should
>>>> enable the clocks unconditionally even if the consumer driver does
>>>> not do any clk_*() calls. Might be worth double checking that.
>>>>
>>>> --
>>>> Luca
>>>
>>> In our application we plan to use the 6965/6901 to replace a part that does
>> not use a consumer driver.  We just set clock options in our device tree.
>> Ideally that is how we would like to use the Renesas part as well.
>>>
>>> In the limited testing I have done thus far behavior is a bit puzzling.  From
>> the device tree I am able to change the clock frequency for out1 (which is
>> enabled by default) and I can disable outputs using 'idt,shutdown', but I
>> cannot change the logic levels for out1 using the 'idt,mode' parameter.
>>
>> This is very strange.
>>
>> Did you double-check that your device tree description of the versaclock
>> node is correct according to [0]?
>>
>> Please send the complete  description of the versaclock node in your device
>> tree, so we can check it and see if any detail is misplaced.
>>
>> [0]
>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/g
>> it/torvalds/linux.git/tree/Documentation/devicetree/bindings/clock/idt,vers
>> aclock5.yaml*n169__;Iw!!KnJ4-
>> rp7!yalfgsfaZKSlo4yNfQfvlbsmNKBRltGSetoIonP--5aGebuHUJ-M-
>> am93tjT8aEhsSJJ$
>>
>>
>> --
>> Luca
> 
> Here is the relevant portions of my device tree.  On the scope I see the default 'CMOSD' voltages and a modified frequency of 46.8MHz.  
> 
> I have also modified my local copy of the driver to accept an 'idt,enable' pattern property that allows me to enable outputs from the device tree. It needs some refinement but I can pass it along if there is interest.
> 
> -Claude
> 
> ==================
> Top of device tree file:
> ==================
> /*
> This is a message for system-user.dtsi. If you are reading from system-user.dtsi.genxxxx, please note that this message is
> for explaining the purpose of system-user.dist in relation to system-user.dtsi.genxxx.
> 
> system-user.dtsi is merely a writable file handled by ./buildPetaLinux.sh to copy the appropriate system-user.dtsi.genxxxx to this filename for use
> in the build image. Do not put your device tree here. They belong to the system-user.dtsi.genxxxx.
> 
> If you add a new dtsi, please create an appropriate device tree file and modify the ./buildPetaLinux.sh to handle it 
> */
> 
> #include <dt-bindings/clk/versaclock.h>
> 
> /include/ "system-conf.dtsi"
> / {
>  
>   /* Clock Provider */
>   x304_clk: x304-clock {
>     compatible = "fixed-clock";
>     #clock-cells = <0>;
>     clock-frequency = <25000000>;
>   };
> 
> ...
> 
> ==================
> Device Tree Node:
> ==================
> &i2c1 {
>     clock-frequency = <100000>;
> 
>     // Use patch.  Updated driver for 5p49v6965 available  at https://github.com/Xilinx/linux-xlnx/blob/master/drivers/clk/clk-versaclock5.c
>     // Device Tree Setup -> https://github.com/Xilinx/linux-xlnx/blob/master/Documentation/devicetree/bindings/clock/idt%2Cversaclock5.yaml
>     versaclock6: clock-controller@6a {
>         /* Clock Consumer */
>         compatible = "idt,5p49v6965";
> 		reg = <0x6a>;
> 		#clock-cells = <1>;
> 		clocks = <&x304_clk>;
> 		clock-names = "xin";
> 
>         assigned-clocks = <&versaclock6 1>,
>                           <&versaclock6 2>,
>                           <&versaclock6 3>,
>                           <&versaclock6 4>;
>         // assigned-clock-rates = <46800000>, <250000000>, <1000000>, <13000000>;
>         assigned-clock-rates = <46800000>, <250000000>, <1000000>, <13000000>;
>         /* Set the SD/OE pin's settings */
>         idt,shutdown = <0>;
>         idt,output-enable-active = <0>;
>         OUT1 {
>             idt,mode = <VC5_CMOS>;
>             idt,voltage-microvolt = <3300000>;
>             c = <100>;
>         };
>         OUT2 {
>             idt,mode = <VC5_CMOS>;
>             idt,voltage-microvolt = <3300000>;
>             idt,slew-percent = <100>;
>         };
>         OUT3 {
>             idt,mode = <VC5_CMOSD>;
>             idt,voltage-microvolt = <3300000>;
>             idt,slew-percent = <100>;
>         };
>         OUT4 {
>             idt,mode = <VC5_CMOS>;
>             idt,voltage-microvolt = <3300000>;
>             idt,slew-percent = <100>;
>         };
>     };

Strange. Something you may check (or double check if you already did):

1. Read if the register has been set:

  # not tested, check carefully
  i2cget -y -r 1 0x6a 0x60

the three low bits in register 0x60 should read 0x1 for CMOS, 0x5 for CMOSD.

2. Change idt,mode in device tree and see whether the register changes
or the scope show any different output mode.

3. Enable debugging output (simpliy add #define DEBUG on top of file and
rebuild), then see whether during clk prepare you see this in dmesg:

  Update output ... mask 0x... val 0x....

4. Check whether the OUT1 node is actually found by adding a dev_dbg()
in vc5_get_output_config(), just before the of_get_child_by_name() call
and ~5 lines below, between 'return 0' and vc5_update_mode().

Let us know your findings.

-- 
Luca

RE: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Fillion, Claude]

Hello Luca,

> -----Original Message-----
> From: Luca Ceresoli <luca@lucaceresoli.net>
> Sent: Thursday, March 3, 2022 5:34 PM
> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> <aford173@gmail.com>
> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> versaclock5 driver
> 
> Hi Claude,
> 
> On 03/03/22 19:15, Fillion, Claude wrote:
> > Hello Luca,
> >
> >> -----Original Message-----
> >> From: Luca Ceresoli <luca@lucaceresoli.net>
> >> Sent: Thursday, March 3, 2022 9:42 AM
> >> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> >> <aford173@gmail.com>
> >> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> >> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
> >> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> >> versaclock5 driver
> >>
> >> Hi Claude,
> >>
> >> On 02/03/22 21:49, Fillion, Claude wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Luca Ceresoli <luca@lucaceresoli.net>
> >>>> Sent: Wednesday, March 2, 2022 12:27 PM
> >>>> To: Adam Ford <aford173@gmail.com>; Fillion, Claude
> >>>> <Claude.Fillion@mksinst.com>
> >>>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> >>>> clk@vger.kernel.org>
> >>>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding
> >>>> idt/renesas
> >>>> versaclock5 driver
> >>>>
> >>>> Hi,
> >>>>
> >>>> On 02/03/22 16:45, Adam Ford wrote:
> >>>> ...
> >>>>>>>>>>     versaclock6: clock-controller@6a {
> >>>>>>>>>>
> >>>>>>>>>>         /* Clock Consumer */
> >>>>>>>>>>
> >>>>>>>>>>         compatible = "idt,5p49v6965";
> >>>>>>>>>>
> >>>>>>>>>>                                 reg = <0x6a>;
> >>>>>>>>>>
> >>>>>>>>>>                                 #clock-cells = <1>;
> >>>>>>>>>>
> >>>>>>>>>>                                 clocks = <&x304_clk>;
> >>>>>>>>>>
> >>>>>>>>>>                                 clock-names = "xin";
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>         assigned_clocks = <&versaclock6 1>,
> >>>>>>>>>>
> >>>>>>>>>>                           <&versaclock6 2>,
> >>>>>>>>>>
> >>>>>>>>>>                           <&versaclock6 3>,
> >>>>>>>>>>
> >>>>>>>>>>                           <&versaclock6 4>;
> >>>>>>>>>>
> >>>>>>>>>>         assigned_clock_rates = <46800000>, <250000000>,
> >>>>>>>>>> <1000000>, <13000000>;
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Assigned clocks and assigned clock rates should be hyphens and
> >>>>>>>>> not underscores.
> >>>>>>>>>
> >>>>>>>>> assigned-clocks =  <&versaclock6 1>,   <&versaclock6 2>,
> >>>>>>>>> <&versaclock6 3>, <&versaclock6 4>;
> >>>>>>>>>
> >>>>>>>>> assigned-clock-rates =  <46800000>, <250000000>, <1000000>,
> >>>>>>>>> <13000000>;
> >>>>>>>>>
> >>>>>>>>> Another thing to check is to make sure the consumers of these
> >>>>>>>>> clocks is enabling them.  They do not necessarily get enabled
> >>>>>>>>> by
> >>>> default.
> >>>>>>>>>
> >>>>>>>>> adam
> >>>>>>>>
> >>>>>>>> Doh - thanks.  I looked at it a million times 😊 .
> >>>>>>>>
> >>>>>>>> Now getting desired out1 frequency but nothing on other
> outputs.
> >>>>>>>> From
> >>>>>>> the code it seems vc5_clk_out_prepare() is the method that
> >>>>>>> enables outputs but this method is not being called I am not
> >>>>>>> clear how to make the 'consumer enable them.'
> >>>>>>>>
> >>>>>>>> I have added this to my dtsi to no avail.
> >>>>>>>>
> >>>>>>>>          /* Consumer referencing 5P49V5965 pin OUT1 and OUT2 */
> >>>>>>>>         consumer {
> >>>>>>>>             clocks = <&versaclock6 1>, <&versaclock6 2>;
> >>>>>>>>             /* ... */
> >>>>>>>>          };
> >>>>>>>>
> >>>>>>>> Looking through device tree documentation.
> >>>>>>>
> >>>>>>> It's likely going to be in the consumer's driver.  Check the
> >>>>>>> consumer device tree binding to make sure you've correctly
> >>>>>>> associated the clock.  If the binding doesnt't show a clock is
> >>>>>>> required, it might not know that you using a programmable clock.
> >>>>>>>
> >>>>>>> Here is a patch that I needed to apply to an Ethernet driver
> >>>>>>> which wasn't expecting a programmable clock to drive a reference
> >>>>>>> clock, so the clock wasn't being enabled.
> >>>>>>>
> >>>>>>>
> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux
> >>>>>>> /k
> >>>>>>> er
> >>>>>>> nel/g
> >>>>>>>
> >> it/torvalds/linux.git/commit/drivers/net/ethernet/renesas/ravb_main.
> >>>>>>> c?id=
> >>>>>>> 8ef7adc6beb2ef0bce83513dc9e4505e7b21e8c2__;!!KnJ4-
> rp7!1Qb17q-
> >>>>>>>
> >>>>
> >>
> TWrV62AeQtTNNVDErVbyhbXB1sukyT2ggvFPUltIBI5nIKzNnjVOcqlw8qJyy$
> >>>>>>>
> >>>>>>> Look at the use of devm_clk_get_optional and clk_prepare_enable
> >>>>>>> from that patch.  (yes, there is a subsequent patch that fixes
> >>>>>>> something I didn't quite do right, but the basics are here)
> >>>>>>>
> >>>>>>> The consumer drivers need to 'get' the clock so it can associate
> >>>>>>> itself to the clock in question.  Once the relationship is
> >>>>>>> established, the consumer needs to call clk_prepare_enable()
> >>>>>>> which
> >>>> uses the clock system to turn the clock on.
> >>>>>>> Without this step, it's likely the Versaclock won't generate a
> >>>>>>> signal, because it doesn't know it needs to turn it on.
> >>>>>>>
> >>>>>>> adam
> >>>>>>
> >>>>>> Not sure I fully follow.  I see that clk out1 is enabled but the
> >>>>>> other
> >>>> channels are not so it would seem my difficulty is with individual
> channels.
> >>>>>
> >>>>> Do the devices that need the clock from the versaclock reference
> >>>>> the versaclock?  If so, to those drivers use the get and enable?
> >>>>> If not, the versaclock will stay off.  In the patch example I
> >>>>> showed, I had to modify the Ethernet driver on a processor,
> >>>>> because it didn't explicitly enable the reference clock.  That
> >>>>> Ethernet driver expected the refclk was always present which was a
> false assumption.
> >>>>> Once I got the consumer device (in this case, Ethernet) to request
> >>>>> and enable the clock, the clock subsystem enabled the
> >>>>> corresponding output on the versaclock.
> >>>>>
> >>>>> For the Ethernet example I cited above, the corresponding device
> >>>>> tree looks like:
> >>>>>
> >>>>> &avb {
> >>>>>      clocks = <&cpg CPG_MOD 812>, <&versaclock5 4>;
> >>>>>      clock-names = "fck", "refclk";
> >>>>>      status = "okay";
> >>>>> };
> >>>>>
> >>>>> With this device tree reference, the 'refclk' gets associated to
> >>>>> versaclock ouput 4.  When the Ethernet needs the clock, it calls
> >>>>> clk_prepare_enable on that clock reference, and the clock system
> >>>>> calls on the versaclock driver to enable the output.  The reason I
> >>>>> needed to submit that patch was that the consumer driver (the
> >>>>> Ethernet in this
> >>>>> case) wasn't calling the clk_prepare_enable, so the clock remained
> >>>>> off.  It's likely that whatever devices that need the clock from
> >>>>> the versaclock will need both a device tree reference to it as
> >>>>> well as a call to clk_prepare_enable.
> >>>>>
> >>>>>>
> >>>>>> In my simple application I would like to enable outputs, on a per
> >>>>>> channel
> >>>> basis, from the device tree.  Would it make sense  to add  an
> 'idt,enable'
> >>>> property in similar fashion to the existing idt,mode,
> >>>> idt,voltage-microvolt, and idt,slew-percent properties?  Then
> >>>> vc5_get_output_config() could be modified to also call
> >>>> vc5_clk_out_prepare() (or clk_prepare_enable(), which in turn would
> >>>> call
> >> vc5_clk_out_prepare()).
> >>>>>
> >>>>> I can't speak for the linux clock group, but the advantage of
> >>>>> patching the drivers that need the clocks generated from the
> >>>>> versaclock is the ability to stop these clocks when the drivers
> >>>>> are halted and/or suspended.
> >>>>
> >>>> Having the consumer driver get, prepare and enable the clock is of
> >>>> course the best as Adam explained.
> >>>>
> >>>> However I think using assigned-clocks and assigned-clock-rates
> >>>> should enable the clocks unconditionally even if the consumer
> >>>> driver does not do any clk_*() calls. Might be worth double checking
> that.
> >>>>
> >>>> --
> >>>> Luca
> >>>
> >>> In our application we plan to use the 6965/6901 to replace a part
> >>> that does
> >> not use a consumer driver.  We just set clock options in our device tree.
> >> Ideally that is how we would like to use the Renesas part as well.
> >>>
> >>> In the limited testing I have done thus far behavior is a bit
> >>> puzzling.  From
> >> the device tree I am able to change the clock frequency for out1
> >> (which is enabled by default) and I can disable outputs using
> >> 'idt,shutdown', but I cannot change the logic levels for out1 using the
> 'idt,mode' parameter.
> >>
> >> This is very strange.
> >>
> >> Did you double-check that your device tree description of the
> >> versaclock node is correct according to [0]?
> >>
> >> Please send the complete  description of the versaclock node in your
> >> device tree, so we can check it and see if any detail is misplaced.
> >>
> >> [0]
> >> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kern
> >> el/g
> >> it/torvalds/linux.git/tree/Documentation/devicetree/bindings/clock/id
> >> t,vers
> >> aclock5.yaml*n169__;Iw!!KnJ4-
> >> rp7!yalfgsfaZKSlo4yNfQfvlbsmNKBRltGSetoIonP--5aGebuHUJ-M-
> >> am93tjT8aEhsSJJ$
> >>
> >>
> >> --
> >> Luca
> >
> > Here is the relevant portions of my device tree.  On the scope I see the
> default 'CMOSD' voltages and a modified frequency of 46.8MHz.
> >
> > I have also modified my local copy of the driver to accept an 'idt,enable'
> pattern property that allows me to enable outputs from the device tree. It
> needs some refinement but I can pass it along if there is interest.
> >
> > -Claude
> >
> > ==================
> > Top of device tree file:
> > ==================
> > /*
> > This is a message for system-user.dtsi. If you are reading from
> > system-user.dtsi.genxxxx, please note that this message is for explaining
> the purpose of system-user.dist in relation to system-user.dtsi.genxxx.
> >
> > system-user.dtsi is merely a writable file handled by
> > ./https://urldefense.com/v3/__http://buildPetaLinux.sh__;!!KnJ4-
> rp7!w34odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
> J3Uswvovc00BUt$  to copy the appropriate system-user.dtsi.genxxxx to this
> filename for use in the build image. Do not put your device tree here. They
> belong to the system-user.dtsi.genxxxx.
> >
> > If you add a new dtsi, please create an appropriate device tree file
> > and modify the
> > ./https://urldefense.com/v3/__http://buildPetaLinux.sh__;!!KnJ4-rp7!w3
> > 4odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
> J3Uswvovc00BUt$
> > to handle it */
> >
> > #include <dt-bindings/clk/versaclock.h>
> >
> > /include/ "system-conf.dtsi"
> > / {
> >
> >   /* Clock Provider */
> >   x304_clk: x304-clock {
> >     compatible = "fixed-clock";
> >     #clock-cells = <0>;
> >     clock-frequency = <25000000>;
> >   };
> >
> > ...
> >
> > ==================
> > Device Tree Node:
> > ==================
> > &i2c1 {
> >     clock-frequency = <100000>;
> >
> >     // Use patch.  Updated driver for 5p49v6965 available  at
> https://urldefense.com/v3/__https://github.com/Xilinx/linux-
> xlnx/blob/master/drivers/clk/clk-versaclock5.c__;!!KnJ4-
> rp7!w34odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
> J3UswvoiTIHWiN$
> >     // Device Tree Setup ->
> https://urldefense.com/v3/__https://github.com/Xilinx/linux-
> xlnx/blob/master/Documentation/devicetree/bindings/clock/idt*2Cversaclo
> ck5.yaml__;JQ!!KnJ4-rp7!w34odUyH6hHBct-rWC671nddpz5440f-
> viaETLtFnGYMlkuB7P0ye-J3Uswvor3hNb3f$
> >     versaclock6: clock-controller@6a {
> >         /* Clock Consumer */
> >         compatible = "idt,5p49v6965";
> > 		reg = <0x6a>;
> > 		#clock-cells = <1>;
> > 		clocks = <&x304_clk>;
> > 		clock-names = "xin";
> >
> >         assigned-clocks = <&versaclock6 1>,
> >                           <&versaclock6 2>,
> >                           <&versaclock6 3>,
> >                           <&versaclock6 4>;
> >         // assigned-clock-rates = <46800000>, <250000000>, <1000000>,
> <13000000>;
> >         assigned-clock-rates = <46800000>, <250000000>, <1000000>,
> <13000000>;
> >         /* Set the SD/OE pin's settings */
> >         idt,shutdown = <0>;
> >         idt,output-enable-active = <0>;
> >         OUT1 {
> >             idt,mode = <VC5_CMOS>;
> >             idt,voltage-microvolt = <3300000>;
> >             c = <100>;
> >         };
> >         OUT2 {
> >             idt,mode = <VC5_CMOS>;
> >             idt,voltage-microvolt = <3300000>;
> >             idt,slew-percent = <100>;
> >         };
> >         OUT3 {
> >             idt,mode = <VC5_CMOSD>;
> >             idt,voltage-microvolt = <3300000>;
> >             idt,slew-percent = <100>;
> >         };
> >         OUT4 {
> >             idt,mode = <VC5_CMOS>;
> >             idt,voltage-microvolt = <3300000>;
> >             idt,slew-percent = <100>;
> >         };
> >     };
> 
> Strange. Something you may check (or double check if you already did):
> 
> 1. Read if the register has been set:
> 
>   # not tested, check carefully
>   i2cget -y -r 1 0x6a 0x60
> 
> the three low bits in register 0x60 should read 0x1 for CMOS, 0x5 for CMOSD.

Apparently the register is not getting set properly.

In response to 'i2cget -y -f 1 0x6a 0x60' (-r not supported maybe a typo?)

I get 0xbb, which according to the spec I believe should give me CMOSD, which is what I am seeing ( (D7, D6, D5) = 101: CMOSD ).

I can set address 0x60 to 0x3b using i2cset to get single ended CMOS.


> 
> 2. Change idt,mode in device tree and see whether the register changes or
> the scope show any different output mode.

Changing ide,mode to VC5_LVDS does not the value of register 0x06.  I still get a value of 0xbb

> 
> 3. Enable debugging output (simpliy add #define DEBUG on top of file and
> rebuild), then see whether during clk prepare you see this in dmesg:
> 
>   Update output ... mask 0x... val 0x....
> 
> 4. Check whether the OUT1 node is actually found by adding a dev_dbg() in
> vc5_get_output_config(), just before the of_get_child_by_name() call and
> ~5 lines below, between 'return 0' and vc5_update_mode().
> 
> Let us know your findings.
> 

Seems to be finding the nodes ok. Here is the relevant code section:

	// temp for driver debug
	dev_dbg(&client->dev,
			"get_output_config(before of_get_child_by_name)  OUT%d\n",
			clk_out->num + 1);

	np_output = of_get_child_by_name(client->dev.of_node, child_name);
	kfree(child_name);
	if (!np_output)
		return 0;

	// temp for driver debug
	dev_dbg(&client->dev,
			"get_output_config(before update_mode)  OUT%d\n",
			clk_out->num + 1);

	ret = vc5_update_mode(np_output, clk_out);
	if (ret)
		goto output_error;
 
And dmesg output:

	[    7.498005] vc5 1-006a: get_output_config(before of_get_child_by_name)  OUT1                                                                               
	[    7.498017] vc5 1-006a: get_output_config(before update_mode)  OUT1                                                                                        
	[    7.511631] vc5 1-006a: get_output_config(before of_get_child_by_name)  OUT2                                                                               
	[    7.511643] vc5 1-006a: get_output_config(before update_mode)  OUT2                                                                                        
	[    7.525257] vc5 1-006a: get_output_config(before of_get_child_by_name)  OUT3                                                                               
	[    7.525270] vc5 1-006a: get_output_config(before update_mode)  OUT3                                                                                        
	[    7.538905] vc5 1-006a: get_output_config(before of_get_child_by_name)  OUT4                                                                               
	[    7.538919] vc5 1-006a: get_output_config(before update_mode)  OUT4

> --
> Luca

======================================================================
This message and any attachments are intended only for the designated recipient(s) and may contain confidential or proprietary information and be subject to the attorney-client privilege or other confidentiality protections.  If you are not a designated recipient, you may not review, use, copy or distribute this message or any attachments.  If you received this email in error, please notify the sender by reply e-mail and permanently delete the original and any copies of this message and any attachments thereto.  Thank you.

Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Luca Ceresoli]

Hi Claude,

On 04/03/22 21:07, Fillion, Claude wrote:
> Hello Luca,
> 
>> -----Original Message-----
>> From: Luca Ceresoli <luca@lucaceresoli.net>
>> Sent: Thursday, March 3, 2022 5:34 PM
>> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
>> <aford173@gmail.com>
>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
>> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
>> versaclock5 driver
>>
>> Hi Claude,
>>
>> On 03/03/22 19:15, Fillion, Claude wrote:
>>> Hello Luca,
>>>
>>>> -----Original Message-----
>>>> From: Luca Ceresoli <luca@lucaceresoli.net>
>>>> Sent: Thursday, March 3, 2022 9:42 AM
>>>> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
>>>> <aford173@gmail.com>
>>>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
>>>> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
>>>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
>>>> versaclock5 driver
>>>>
>>>> Hi Claude,
>>>>
>>>> On 02/03/22 21:49, Fillion, Claude wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Luca Ceresoli <luca@lucaceresoli.net>
>>>>>> Sent: Wednesday, March 2, 2022 12:27 PM
>>>>>> To: Adam Ford <aford173@gmail.com>; Fillion, Claude
>>>>>> <Claude.Fillion@mksinst.com>
>>>>>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
>>>>>> clk@vger.kernel.org>
>>>>>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding
>>>>>> idt/renesas
>>>>>> versaclock5 driver
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 02/03/22 16:45, Adam Ford wrote:
>>>>>> ...
>>>>>>>>>>>>     versaclock6: clock-controller@6a {
>>>>>>>>>>>>
>>>>>>>>>>>>         /* Clock Consumer */
>>>>>>>>>>>>
>>>>>>>>>>>>         compatible = "idt,5p49v6965";
>>>>>>>>>>>>
>>>>>>>>>>>>                                 reg = <0x6a>;
>>>>>>>>>>>>
>>>>>>>>>>>>                                 #clock-cells = <1>;
>>>>>>>>>>>>
>>>>>>>>>>>>                                 clocks = <&x304_clk>;
>>>>>>>>>>>>
>>>>>>>>>>>>                                 clock-names = "xin";
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>         assigned_clocks = <&versaclock6 1>,
>>>>>>>>>>>>
>>>>>>>>>>>>                           <&versaclock6 2>,
>>>>>>>>>>>>
>>>>>>>>>>>>                           <&versaclock6 3>,
>>>>>>>>>>>>
>>>>>>>>>>>>                           <&versaclock6 4>;
>>>>>>>>>>>>
>>>>>>>>>>>>         assigned_clock_rates = <46800000>, <250000000>,
>>>>>>>>>>>> <1000000>, <13000000>;
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Assigned clocks and assigned clock rates should be hyphens and
>>>>>>>>>>> not underscores.
>>>>>>>>>>>
>>>>>>>>>>> assigned-clocks =  <&versaclock6 1>,   <&versaclock6 2>,
>>>>>>>>>>> <&versaclock6 3>, <&versaclock6 4>;
>>>>>>>>>>>
>>>>>>>>>>> assigned-clock-rates =  <46800000>, <250000000>, <1000000>,
>>>>>>>>>>> <13000000>;
>>>>>>>>>>>
>>>>>>>>>>> Another thing to check is to make sure the consumers of these
>>>>>>>>>>> clocks is enabling them.  They do not necessarily get enabled
>>>>>>>>>>> by
>>>>>> default.
>>>>>>>>>>>
>>>>>>>>>>> adam
>>>>>>>>>>
>>>>>>>>>> Doh - thanks.  I looked at it a million times 😊 .
>>>>>>>>>>
>>>>>>>>>> Now getting desired out1 frequency but nothing on other
>> outputs.
>>>>>>>>>> From
>>>>>>>>> the code it seems vc5_clk_out_prepare() is the method that
>>>>>>>>> enables outputs but this method is not being called I am not
>>>>>>>>> clear how to make the 'consumer enable them.'
>>>>>>>>>>
>>>>>>>>>> I have added this to my dtsi to no avail.
>>>>>>>>>>
>>>>>>>>>>          /* Consumer referencing 5P49V5965 pin OUT1 and OUT2 */
>>>>>>>>>>         consumer {
>>>>>>>>>>             clocks = <&versaclock6 1>, <&versaclock6 2>;
>>>>>>>>>>             /* ... */
>>>>>>>>>>          };
>>>>>>>>>>
>>>>>>>>>> Looking through device tree documentation.
>>>>>>>>>
>>>>>>>>> It's likely going to be in the consumer's driver.  Check the
>>>>>>>>> consumer device tree binding to make sure you've correctly
>>>>>>>>> associated the clock.  If the binding doesnt't show a clock is
>>>>>>>>> required, it might not know that you using a programmable clock.
>>>>>>>>>
>>>>>>>>> Here is a patch that I needed to apply to an Ethernet driver
>>>>>>>>> which wasn't expecting a programmable clock to drive a reference
>>>>>>>>> clock, so the clock wasn't being enabled.
>>>>>>>>>
>>>>>>>>>
>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux
>>>>>>>>> /k
>>>>>>>>> er
>>>>>>>>> nel/g
>>>>>>>>>
>>>> it/torvalds/linux.git/commit/drivers/net/ethernet/renesas/ravb_main.
>>>>>>>>> c?id=
>>>>>>>>> 8ef7adc6beb2ef0bce83513dc9e4505e7b21e8c2__;!!KnJ4-
>> rp7!1Qb17q-
>>>>>>>>>
>>>>>>
>>>>
>> TWrV62AeQtTNNVDErVbyhbXB1sukyT2ggvFPUltIBI5nIKzNnjVOcqlw8qJyy$
>>>>>>>>>
>>>>>>>>> Look at the use of devm_clk_get_optional and clk_prepare_enable
>>>>>>>>> from that patch.  (yes, there is a subsequent patch that fixes
>>>>>>>>> something I didn't quite do right, but the basics are here)
>>>>>>>>>
>>>>>>>>> The consumer drivers need to 'get' the clock so it can associate
>>>>>>>>> itself to the clock in question.  Once the relationship is
>>>>>>>>> established, the consumer needs to call clk_prepare_enable()
>>>>>>>>> which
>>>>>> uses the clock system to turn the clock on.
>>>>>>>>> Without this step, it's likely the Versaclock won't generate a
>>>>>>>>> signal, because it doesn't know it needs to turn it on.
>>>>>>>>>
>>>>>>>>> adam
>>>>>>>>
>>>>>>>> Not sure I fully follow.  I see that clk out1 is enabled but the
>>>>>>>> other
>>>>>> channels are not so it would seem my difficulty is with individual
>> channels.
>>>>>>>
>>>>>>> Do the devices that need the clock from the versaclock reference
>>>>>>> the versaclock?  If so, to those drivers use the get and enable?
>>>>>>> If not, the versaclock will stay off.  In the patch example I
>>>>>>> showed, I had to modify the Ethernet driver on a processor,
>>>>>>> because it didn't explicitly enable the reference clock.  That
>>>>>>> Ethernet driver expected the refclk was always present which was a
>> false assumption.
>>>>>>> Once I got the consumer device (in this case, Ethernet) to request
>>>>>>> and enable the clock, the clock subsystem enabled the
>>>>>>> corresponding output on the versaclock.
>>>>>>>
>>>>>>> For the Ethernet example I cited above, the corresponding device
>>>>>>> tree looks like:
>>>>>>>
>>>>>>> &avb {
>>>>>>>      clocks = <&cpg CPG_MOD 812>, <&versaclock5 4>;
>>>>>>>      clock-names = "fck", "refclk";
>>>>>>>      status = "okay";
>>>>>>> };
>>>>>>>
>>>>>>> With this device tree reference, the 'refclk' gets associated to
>>>>>>> versaclock ouput 4.  When the Ethernet needs the clock, it calls
>>>>>>> clk_prepare_enable on that clock reference, and the clock system
>>>>>>> calls on the versaclock driver to enable the output.  The reason I
>>>>>>> needed to submit that patch was that the consumer driver (the
>>>>>>> Ethernet in this
>>>>>>> case) wasn't calling the clk_prepare_enable, so the clock remained
>>>>>>> off.  It's likely that whatever devices that need the clock from
>>>>>>> the versaclock will need both a device tree reference to it as
>>>>>>> well as a call to clk_prepare_enable.
>>>>>>>
>>>>>>>>
>>>>>>>> In my simple application I would like to enable outputs, on a per
>>>>>>>> channel
>>>>>> basis, from the device tree.  Would it make sense  to add  an
>> 'idt,enable'
>>>>>> property in similar fashion to the existing idt,mode,
>>>>>> idt,voltage-microvolt, and idt,slew-percent properties?  Then
>>>>>> vc5_get_output_config() could be modified to also call
>>>>>> vc5_clk_out_prepare() (or clk_prepare_enable(), which in turn would
>>>>>> call
>>>> vc5_clk_out_prepare()).
>>>>>>>
>>>>>>> I can't speak for the linux clock group, but the advantage of
>>>>>>> patching the drivers that need the clocks generated from the
>>>>>>> versaclock is the ability to stop these clocks when the drivers
>>>>>>> are halted and/or suspended.
>>>>>>
>>>>>> Having the consumer driver get, prepare and enable the clock is of
>>>>>> course the best as Adam explained.
>>>>>>
>>>>>> However I think using assigned-clocks and assigned-clock-rates
>>>>>> should enable the clocks unconditionally even if the consumer
>>>>>> driver does not do any clk_*() calls. Might be worth double checking
>> that.
>>>>>>
>>>>>> --
>>>>>> Luca
>>>>>
>>>>> In our application we plan to use the 6965/6901 to replace a part
>>>>> that does
>>>> not use a consumer driver.  We just set clock options in our device tree.
>>>> Ideally that is how we would like to use the Renesas part as well.
>>>>>
>>>>> In the limited testing I have done thus far behavior is a bit
>>>>> puzzling.  From
>>>> the device tree I am able to change the clock frequency for out1
>>>> (which is enabled by default) and I can disable outputs using
>>>> 'idt,shutdown', but I cannot change the logic levels for out1 using the
>> 'idt,mode' parameter.
>>>>
>>>> This is very strange.
>>>>
>>>> Did you double-check that your device tree description of the
>>>> versaclock node is correct according to [0]?
>>>>
>>>> Please send the complete  description of the versaclock node in your
>>>> device tree, so we can check it and see if any detail is misplaced.
>>>>
>>>> [0]
>>>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kern
>>>> el/g
>>>> it/torvalds/linux.git/tree/Documentation/devicetree/bindings/clock/id
>>>> t,vers
>>>> aclock5.yaml*n169__;Iw!!KnJ4-
>>>> rp7!yalfgsfaZKSlo4yNfQfvlbsmNKBRltGSetoIonP--5aGebuHUJ-M-
>>>> am93tjT8aEhsSJJ$
>>>>
>>>>
>>>> --
>>>> Luca
>>>
>>> Here is the relevant portions of my device tree.  On the scope I see the
>> default 'CMOSD' voltages and a modified frequency of 46.8MHz.
>>>
>>> I have also modified my local copy of the driver to accept an 'idt,enable'
>> pattern property that allows me to enable outputs from the device tree. It
>> needs some refinement but I can pass it along if there is interest.
>>>
>>> -Claude
>>>
>>> ==================
>>> Top of device tree file:
>>> ==================
>>> /*
>>> This is a message for system-user.dtsi. If you are reading from
>>> system-user.dtsi.genxxxx, please note that this message is for explaining
>> the purpose of system-user.dist in relation to system-user.dtsi.genxxx.
>>>
>>> system-user.dtsi is merely a writable file handled by
>>> ./https://urldefense.com/v3/__http://buildPetaLinux.sh__;!!KnJ4-
>> rp7!w34odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
>> J3Uswvovc00BUt$  to copy the appropriate system-user.dtsi.genxxxx to this
>> filename for use in the build image. Do not put your device tree here. They
>> belong to the system-user.dtsi.genxxxx.
>>>
>>> If you add a new dtsi, please create an appropriate device tree file
>>> and modify the
>>> ./https://urldefense.com/v3/__http://buildPetaLinux.sh__;!!KnJ4-rp7!w3
>>> 4odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
>> J3Uswvovc00BUt$
>>> to handle it */
>>>
>>> #include <dt-bindings/clk/versaclock.h>
>>>
>>> /include/ "system-conf.dtsi"
>>> / {
>>>
>>>   /* Clock Provider */
>>>   x304_clk: x304-clock {
>>>     compatible = "fixed-clock";
>>>     #clock-cells = <0>;
>>>     clock-frequency = <25000000>;
>>>   };
>>>
>>> ...
>>>
>>> ==================
>>> Device Tree Node:
>>> ==================
>>> &i2c1 {
>>>     clock-frequency = <100000>;
>>>
>>>     // Use patch.  Updated driver for 5p49v6965 available  at
>> https://urldefense.com/v3/__https://github.com/Xilinx/linux-
>> xlnx/blob/master/drivers/clk/clk-versaclock5.c__;!!KnJ4-
>> rp7!w34odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
>> J3UswvoiTIHWiN$
>>>     // Device Tree Setup ->
>> https://urldefense.com/v3/__https://github.com/Xilinx/linux-
>> xlnx/blob/master/Documentation/devicetree/bindings/clock/idt*2Cversaclo
>> ck5.yaml__;JQ!!KnJ4-rp7!w34odUyH6hHBct-rWC671nddpz5440f-
>> viaETLtFnGYMlkuB7P0ye-J3Uswvor3hNb3f$
>>>     versaclock6: clock-controller@6a {
>>>         /* Clock Consumer */
>>>         compatible = "idt,5p49v6965";
>>> 		reg = <0x6a>;
>>> 		#clock-cells = <1>;
>>> 		clocks = <&x304_clk>;
>>> 		clock-names = "xin";
>>>
>>>         assigned-clocks = <&versaclock6 1>,
>>>                           <&versaclock6 2>,
>>>                           <&versaclock6 3>,
>>>                           <&versaclock6 4>;
>>>         // assigned-clock-rates = <46800000>, <250000000>, <1000000>,
>> <13000000>;
>>>         assigned-clock-rates = <46800000>, <250000000>, <1000000>,
>> <13000000>;
>>>         /* Set the SD/OE pin's settings */
>>>         idt,shutdown = <0>;
>>>         idt,output-enable-active = <0>;
>>>         OUT1 {
>>>             idt,mode = <VC5_CMOS>;
>>>             idt,voltage-microvolt = <3300000>;
>>>             c = <100>;
>>>         };
>>>         OUT2 {
>>>             idt,mode = <VC5_CMOS>;
>>>             idt,voltage-microvolt = <3300000>;
>>>             idt,slew-percent = <100>;
>>>         };
>>>         OUT3 {
>>>             idt,mode = <VC5_CMOSD>;
>>>             idt,voltage-microvolt = <3300000>;
>>>             idt,slew-percent = <100>;
>>>         };
>>>         OUT4 {
>>>             idt,mode = <VC5_CMOS>;
>>>             idt,voltage-microvolt = <3300000>;
>>>             idt,slew-percent = <100>;
>>>         };
>>>     };
>>
>> Strange. Something you may check (or double check if you already did):
>>
>> 1. Read if the register has been set:
>>
>>   # not tested, check carefully
>>   i2cget -y -r 1 0x6a 0x60
>>
>> the three low bits in register 0x60 should read 0x1 for CMOS, 0x5 for CMOSD.
> 
> Apparently the register is not getting set properly.
> 
> In response to 'i2cget -y -f 1 0x6a 0x60' (-r not supported maybe a typo?)
> 
> I get 0xbb, which according to the spec I believe should give me CMOSD, which is what I am seeing ( (D7, D6, D5) = 101: CMOSD ).
> 
> I can set address 0x60 to 0x3b using i2cset to get single ended CMOS.

I see. 0xbb is the reset default, so as you said it is not set.

>> 2. Change idt,mode in device tree and see whether the register changes or
>> the scope show any different output mode.
> 
> Changing ide,mode to VC5_LVDS does not the value of register 0x06.  I still get a value of 0xbb

Ok, coherent with test 1.

>> 3. Enable debugging output (simpliy add #define DEBUG on top of file and
>> rebuild), then see whether during clk prepare you see this in dmesg:
>>
>>   Update output ... mask 0x... val 0x....
>>
>> 4. Check whether the OUT1 node is actually found by adding a dev_dbg() in
>> vc5_get_output_config(), just before the of_get_child_by_name() call and
>> ~5 lines below, between 'return 0' and vc5_update_mode().
>>
>> Let us know your findings.
>>
> 
> Seems to be finding the nodes ok. Here is the relevant code section:
> 
> 	// temp for driver debug
> 	dev_dbg(&client->dev,
> 			"get_output_config(before of_get_child_by_name)  OUT%d\n",
> 			clk_out->num + 1);
> 
> 	np_output = of_get_child_by_name(client->dev.of_node, child_name);
> 	kfree(child_name);
> 	if (!np_output)
> 		return 0;
> 
> 	// temp for driver debug
> 	dev_dbg(&client->dev,
> 			"get_output_config(before update_mode)  OUT%d\n",
> 			clk_out->num + 1);
> 
> 	ret = vc5_update_mode(np_output, clk_out);
> 	if (ret)
> 		goto output_error;
>  
> And dmesg output:
> 
> 	[    7.498005] vc5 1-006a: get_output_config(before of_get_child_by_name)  OUT1                                                                               
> 	[    7.498017] vc5 1-006a: get_output_config(before update_mode)  OUT1                                                                                        
> 	[    7.511631] vc5 1-006a: get_output_config(before of_get_child_by_name)  OUT2                                                                               
> 	[    7.511643] vc5 1-006a: get_output_config(before update_mode)  OUT2                                                                                        
> 	[    7.525257] vc5 1-006a: get_output_config(before of_get_child_by_name)  OUT3                                                                               
> 	[    7.525270] vc5 1-006a: get_output_config(before update_mode)  OUT3                                                                                        
> 	[    7.538905] vc5 1-006a: get_output_config(before of_get_child_by_name)  OUT4                                                                               
> 	[    7.538919] vc5 1-006a: get_output_config(before update_mode)  OUT4

So the values are picked up from DT and if you print the content of
clk_out->clk_output_cfg0[_mask] you should see the correct register values.

Now the relevant question is question 3: do you enter the
'if (hwdata->clk_output_cfg0_mask)' in vc5_clk_out_prepare()? Do you
even enter vc5_clk_out_prepare()?

You can add dev_dbg()s there and track the problem on your own. If
regmap_update_bits(...hwdata->clk_output_cfg0) is not called then the
code is not doing the right thing. If it is called and returns no error,
then it looks like there is a problem in the i2c controller which thinks
it has done the transaction but it really hasn't. Or some other mystery.

-- 
Luca

Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Sean Anderson]

Hi Fillion,

On 3/3/22 1:15 PM, Fillion, Claude wrote:
> 
> Here is the relevant portions of my device tree.  On the scope I see the default 'CMOSD' voltages and a modified frequency of 46.8MHz.  
> 
> I have also modified my local copy of the driver to accept an 'idt,enable' pattern property that allows me to enable outputs from the device tree. It needs some refinement but I can pass it along if there is interest.
> 
> -Claude
> 
> ==================
> Top of device tree file:
> ==================
> /*
> This is a message for system-user.dtsi. If you are reading from system-user.dtsi.genxxxx, please note that this message is
> for explaining the purpose of system-user.dist in relation to system-user.dtsi.genxxx.
> 
> system-user.dtsi is merely a writable file handled by ./buildPetaLinux.sh to copy the appropriate system-user.dtsi.genxxxx to this filename for use
> in the build image. Do not put your device tree here. They belong to the system-user.dtsi.genxxxx.
> 
> If you add a new dtsi, please create an appropriate device tree file and modify the ./buildPetaLinux.sh to handle it 
> */
> 
> #include <dt-bindings/clk/versaclock.h>
> 
> /include/ "system-conf.dtsi"
> / {
>  
>   /* Clock Provider */
>   x304_clk: x304-clock {
>     compatible = "fixed-clock";
>     #clock-cells = <0>;
>     clock-frequency = <25000000>;
>   };
> 
> ...
> 
> ==================
> Device Tree Node:
> ==================
> &i2c1 {
>     clock-frequency = <100000>;
> 
>     // Use patch.  Updated driver for 5p49v6965 available  at https://github.com/Xilinx/linux-xlnx/blob/master/drivers/clk/clk-versaclock5.c
>     // Device Tree Setup -> https://github.com/Xilinx/linux-xlnx/blob/master/Documentation/devicetree/bindings/clock/idt%2Cversaclock5.yaml
>     versaclock6: clock-controller@6a {
>         /* Clock Consumer */
>         compatible = "idt,5p49v6965";
> 		reg = <0x6a>;
> 		#clock-cells = <1>;
> 		clocks = <&x304_clk>;
> 		clock-names = "xin";
> 
>         assigned-clocks = <&versaclock6 1>,
>                           <&versaclock6 2>,
>                           <&versaclock6 3>,
>                           <&versaclock6 4>;
>         // assigned-clock-rates = <46800000>, <250000000>, <1000000>, <13000000>;
>         assigned-clock-rates = <46800000>, <250000000>, <1000000>, <13000000>;
>         /* Set the SD/OE pin's settings */
>         idt,shutdown = <0>;
>         idt,output-enable-active = <0>;

Have you verified that these are correct? E.g. on my board I had to set

idt,output-enable-active = <1>;

You can also remove these properties to use the default values from the OTP.

--Sean

>         OUT1 {
>             idt,mode = <VC5_CMOS>;
>             idt,voltage-microvolt = <3300000>;
>             idt,slew-percent = <100>;
>         };
>         OUT2 {
>             idt,mode = <VC5_CMOS>;
>             idt,voltage-microvolt = <3300000>;
>             idt,slew-percent = <100>;
>         };
>         OUT3 {
>             idt,mode = <VC5_CMOSD>;
>             idt,voltage-microvolt = <3300000>;
>             idt,slew-percent = <100>;
>         };
>         OUT4 {
>             idt,mode = <VC5_CMOS>;
>             idt,voltage-microvolt = <3300000>;
>             idt,slew-percent = <100>;
>         };
>     };

RE: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Fillion, Claude]

Hello Luca

> -----Original Message-----
> From: Luca Ceresoli <luca@lucaceresoli.net>
> Sent: Friday, March 4, 2022 3:30 PM
> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> <aford173@gmail.com>
> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> versaclock5 driver
> 
> Hi Claude,
> 
> On 04/03/22 21:07, Fillion, Claude wrote:
> > Hello Luca,
> >
> >> -----Original Message-----
> >> From: Luca Ceresoli <luca@lucaceresoli.net>
> >> Sent: Thursday, March 3, 2022 5:34 PM
> >> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> >> <aford173@gmail.com>
> >> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> >> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
> >> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> >> versaclock5 driver
> >>
> >> Hi Claude,
> >>
> >> On 03/03/22 19:15, Fillion, Claude wrote:
> >>> Hello Luca,
> >>>
> >>>> -----Original Message-----
> >>>> From: Luca Ceresoli <luca@lucaceresoli.net>
> >>>> Sent: Thursday, March 3, 2022 9:42 AM
> >>>> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> >>>> <aford173@gmail.com>
> >>>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> >>>> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
> >>>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding
> >>>> idt/renesas
> >>>> versaclock5 driver
> >>>>
> >>>> Hi Claude,
> >>>>
> >>>> On 02/03/22 21:49, Fillion, Claude wrote:
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Luca Ceresoli <luca@lucaceresoli.net>
> >>>>>> Sent: Wednesday, March 2, 2022 12:27 PM
> >>>>>> To: Adam Ford <aford173@gmail.com>; Fillion, Claude
> >>>>>> <Claude.Fillion@mksinst.com>
> >>>>>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> >>>>>> clk@vger.kernel.org>
> >>>>>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding
> >>>>>> idt/renesas
> >>>>>> versaclock5 driver
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> On 02/03/22 16:45, Adam Ford wrote:
> >>>>>> ...
> >>>>>>>>>>>>     versaclock6: clock-controller@6a {
> >>>>>>>>>>>>
> >>>>>>>>>>>>         /* Clock Consumer */
> >>>>>>>>>>>>
> >>>>>>>>>>>>         compatible = "idt,5p49v6965";
> >>>>>>>>>>>>
> >>>>>>>>>>>>                                 reg = <0x6a>;
> >>>>>>>>>>>>
> >>>>>>>>>>>>                                 #clock-cells = <1>;
> >>>>>>>>>>>>
> >>>>>>>>>>>>                                 clocks = <&x304_clk>;
> >>>>>>>>>>>>
> >>>>>>>>>>>>                                 clock-names = "xin";
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>         assigned_clocks = <&versaclock6 1>,
> >>>>>>>>>>>>
> >>>>>>>>>>>>                           <&versaclock6 2>,
> >>>>>>>>>>>>
> >>>>>>>>>>>>                           <&versaclock6 3>,
> >>>>>>>>>>>>
> >>>>>>>>>>>>                           <&versaclock6 4>;
> >>>>>>>>>>>>
> >>>>>>>>>>>>         assigned_clock_rates = <46800000>, <250000000>,
> >>>>>>>>>>>> <1000000>, <13000000>;
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Assigned clocks and assigned clock rates should be hyphens
> >>>>>>>>>>> and not underscores.
> >>>>>>>>>>>
> >>>>>>>>>>> assigned-clocks =  <&versaclock6 1>,   <&versaclock6 2>,
> >>>>>>>>>>> <&versaclock6 3>, <&versaclock6 4>;
> >>>>>>>>>>>
> >>>>>>>>>>> assigned-clock-rates =  <46800000>, <250000000>, <1000000>,
> >>>>>>>>>>> <13000000>;
> >>>>>>>>>>>
> >>>>>>>>>>> Another thing to check is to make sure the consumers of
> >>>>>>>>>>> these clocks is enabling them.  They do not necessarily get
> >>>>>>>>>>> enabled by
> >>>>>> default.
> >>>>>>>>>>>
> >>>>>>>>>>> adam
> >>>>>>>>>>
> >>>>>>>>>> Doh - thanks.  I looked at it a million times 😊 .
> >>>>>>>>>>
> >>>>>>>>>> Now getting desired out1 frequency but nothing on other
> >> outputs.
> >>>>>>>>>> From
> >>>>>>>>> the code it seems vc5_clk_out_prepare() is the method that
> >>>>>>>>> enables outputs but this method is not being called I am not
> >>>>>>>>> clear how to make the 'consumer enable them.'
> >>>>>>>>>>
> >>>>>>>>>> I have added this to my dtsi to no avail.
> >>>>>>>>>>
> >>>>>>>>>>          /* Consumer referencing 5P49V5965 pin OUT1 and OUT2
> */
> >>>>>>>>>>         consumer {
> >>>>>>>>>>             clocks = <&versaclock6 1>, <&versaclock6 2>;
> >>>>>>>>>>             /* ... */
> >>>>>>>>>>          };
> >>>>>>>>>>
> >>>>>>>>>> Looking through device tree documentation.
> >>>>>>>>>
> >>>>>>>>> It's likely going to be in the consumer's driver.  Check the
> >>>>>>>>> consumer device tree binding to make sure you've correctly
> >>>>>>>>> associated the clock.  If the binding doesnt't show a clock is
> >>>>>>>>> required, it might not know that you using a programmable
> clock.
> >>>>>>>>>
> >>>>>>>>> Here is a patch that I needed to apply to an Ethernet driver
> >>>>>>>>> which wasn't expecting a programmable clock to drive a
> >>>>>>>>> reference clock, so the clock wasn't being enabled.
> >>>>>>>>>
> >>>>>>>>>
> >> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux
> >>>>>>>>> /k
> >>>>>>>>> er
> >>>>>>>>> nel/g
> >>>>>>>>>
> >>>> it/torvalds/linux.git/commit/drivers/net/ethernet/renesas/ravb_main.
> >>>>>>>>> c?id=
> >>>>>>>>> 8ef7adc6beb2ef0bce83513dc9e4505e7b21e8c2__;!!KnJ4-
> >> rp7!1Qb17q-
> >>>>>>>>>
> >>>>>>
> >>>>
> >>
> TWrV62AeQtTNNVDErVbyhbXB1sukyT2ggvFPUltIBI5nIKzNnjVOcqlw8qJyy$
> >>>>>>>>>
> >>>>>>>>> Look at the use of devm_clk_get_optional and
> >>>>>>>>> clk_prepare_enable from that patch.  (yes, there is a
> >>>>>>>>> subsequent patch that fixes something I didn't quite do right,
> >>>>>>>>> but the basics are here)
> >>>>>>>>>
> >>>>>>>>> The consumer drivers need to 'get' the clock so it can
> >>>>>>>>> associate itself to the clock in question.  Once the
> >>>>>>>>> relationship is established, the consumer needs to call
> >>>>>>>>> clk_prepare_enable() which
> >>>>>> uses the clock system to turn the clock on.
> >>>>>>>>> Without this step, it's likely the Versaclock won't generate a
> >>>>>>>>> signal, because it doesn't know it needs to turn it on.
> >>>>>>>>>
> >>>>>>>>> adam
> >>>>>>>>
> >>>>>>>> Not sure I fully follow.  I see that clk out1 is enabled but
> >>>>>>>> the other
> >>>>>> channels are not so it would seem my difficulty is with
> >>>>>> individual
> >> channels.
> >>>>>>>
> >>>>>>> Do the devices that need the clock from the versaclock reference
> >>>>>>> the versaclock?  If so, to those drivers use the get and enable?
> >>>>>>> If not, the versaclock will stay off.  In the patch example I
> >>>>>>> showed, I had to modify the Ethernet driver on a processor,
> >>>>>>> because it didn't explicitly enable the reference clock.  That
> >>>>>>> Ethernet driver expected the refclk was always present which was
> >>>>>>> a
> >> false assumption.
> >>>>>>> Once I got the consumer device (in this case, Ethernet) to
> >>>>>>> request and enable the clock, the clock subsystem enabled the
> >>>>>>> corresponding output on the versaclock.
> >>>>>>>
> >>>>>>> For the Ethernet example I cited above, the corresponding device
> >>>>>>> tree looks like:
> >>>>>>>
> >>>>>>> &avb {
> >>>>>>>      clocks = <&cpg CPG_MOD 812>, <&versaclock5 4>;
> >>>>>>>      clock-names = "fck", "refclk";
> >>>>>>>      status = "okay";
> >>>>>>> };
> >>>>>>>
> >>>>>>> With this device tree reference, the 'refclk' gets associated to
> >>>>>>> versaclock ouput 4.  When the Ethernet needs the clock, it calls
> >>>>>>> clk_prepare_enable on that clock reference, and the clock system
> >>>>>>> calls on the versaclock driver to enable the output.  The reason
> >>>>>>> I needed to submit that patch was that the consumer driver (the
> >>>>>>> Ethernet in this
> >>>>>>> case) wasn't calling the clk_prepare_enable, so the clock
> >>>>>>> remained off.  It's likely that whatever devices that need the
> >>>>>>> clock from the versaclock will need both a device tree reference
> >>>>>>> to it as well as a call to clk_prepare_enable.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> In my simple application I would like to enable outputs, on a
> >>>>>>>> per channel
> >>>>>> basis, from the device tree.  Would it make sense  to add  an
> >> 'idt,enable'
> >>>>>> property in similar fashion to the existing idt,mode,
> >>>>>> idt,voltage-microvolt, and idt,slew-percent properties?  Then
> >>>>>> vc5_get_output_config() could be modified to also call
> >>>>>> vc5_clk_out_prepare() (or clk_prepare_enable(), which in turn
> >>>>>> would call
> >>>> vc5_clk_out_prepare()).
> >>>>>>>
> >>>>>>> I can't speak for the linux clock group, but the advantage of
> >>>>>>> patching the drivers that need the clocks generated from the
> >>>>>>> versaclock is the ability to stop these clocks when the drivers
> >>>>>>> are halted and/or suspended.
> >>>>>>
> >>>>>> Having the consumer driver get, prepare and enable the clock is
> >>>>>> of course the best as Adam explained.
> >>>>>>
> >>>>>> However I think using assigned-clocks and assigned-clock-rates
> >>>>>> should enable the clocks unconditionally even if the consumer
> >>>>>> driver does not do any clk_*() calls. Might be worth double
> >>>>>> checking
> >> that.
> >>>>>>
> >>>>>> --
> >>>>>> Luca
> >>>>>
> >>>>> In our application we plan to use the 6965/6901 to replace a part
> >>>>> that does
> >>>> not use a consumer driver.  We just set clock options in our device tree.
> >>>> Ideally that is how we would like to use the Renesas part as well.
> >>>>>
> >>>>> In the limited testing I have done thus far behavior is a bit
> >>>>> puzzling.  From
> >>>> the device tree I am able to change the clock frequency for out1
> >>>> (which is enabled by default) and I can disable outputs using
> >>>> 'idt,shutdown', but I cannot change the logic levels for out1 using
> >>>> the
> >> 'idt,mode' parameter.
> >>>>
> >>>> This is very strange.
> >>>>
> >>>> Did you double-check that your device tree description of the
> >>>> versaclock node is correct according to [0]?
> >>>>
> >>>> Please send the complete  description of the versaclock node in
> >>>> your device tree, so we can check it and see if any detail is misplaced.
> >>>>
> >>>> [0]
> >>>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/ke
> >>>> rn
> >>>> el/g
> >>>> it/torvalds/linux.git/tree/Documentation/devicetree/bindings/clock/
> >>>> id
> >>>> t,vers
> >>>> aclock5.yaml*n169__;Iw!!KnJ4-
> >>>> rp7!yalfgsfaZKSlo4yNfQfvlbsmNKBRltGSetoIonP--5aGebuHUJ-M-
> >>>> am93tjT8aEhsSJJ$
> >>>>
> >>>>
> >>>> --
> >>>> Luca
> >>>
> >>> Here is the relevant portions of my device tree.  On the scope I see
> >>> the
> >> default 'CMOSD' voltages and a modified frequency of 46.8MHz.
> >>>
> >>> I have also modified my local copy of the driver to accept an 'idt,enable'
> >> pattern property that allows me to enable outputs from the device
> >> tree. It needs some refinement but I can pass it along if there is interest.
> >>>
> >>> -Claude
> >>>
> >>> ==================
> >>> Top of device tree file:
> >>> ==================
> >>> /*
> >>> This is a message for system-user.dtsi. If you are reading from
> >>> system-user.dtsi.genxxxx, please note that this message is for
> >>> explaining
> >> the purpose of system-user.dist in relation to system-user.dtsi.genxxx.
> >>>
> >>> system-user.dtsi is merely a writable file handled by
> >>> ./https://urldefense.com/v3/__http://buildPetaLinux.sh__;!!KnJ4-
> >> rp7!w34odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
> >> J3Uswvovc00BUt$  to copy the appropriate system-user.dtsi.genxxxx to
> >> this filename for use in the build image. Do not put your device tree
> >> here. They belong to the system-user.dtsi.genxxxx.
> >>>
> >>> If you add a new dtsi, please create an appropriate device tree file
> >>> and modify the
> >>> ./https://urldefense.com/v3/__http://buildPetaLinux.sh__;!!KnJ4-rp7!
> >>> w3
> >>> 4odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
> >> J3Uswvovc00BUt$
> >>> to handle it */
> >>>
> >>> #include <dt-bindings/clk/versaclock.h>
> >>>
> >>> /include/ "system-conf.dtsi"
> >>> / {
> >>>
> >>>   /* Clock Provider */
> >>>   x304_clk: x304-clock {
> >>>     compatible = "fixed-clock";
> >>>     #clock-cells = <0>;
> >>>     clock-frequency = <25000000>;
> >>>   };
> >>>
> >>> ...
> >>>
> >>> ==================
> >>> Device Tree Node:
> >>> ==================
> >>> &i2c1 {
> >>>     clock-frequency = <100000>;
> >>>
> >>>     // Use patch.  Updated driver for 5p49v6965 available  at
> >> https://urldefense.com/v3/__https://github.com/Xilinx/linux-
> >> xlnx/blob/master/drivers/clk/clk-versaclock5.c__;!!KnJ4-
> >> rp7!w34odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
> >> J3UswvoiTIHWiN$
> >>>     // Device Tree Setup ->
> >> https://urldefense.com/v3/__https://github.com/Xilinx/linux-
> >>
> xlnx/blob/master/Documentation/devicetree/bindings/clock/idt*2Cversac
> >> lo
> >> ck5.yaml__;JQ!!KnJ4-rp7!w34odUyH6hHBct-rWC671nddpz5440f-
> >> viaETLtFnGYMlkuB7P0ye-J3Uswvor3hNb3f$
> >>>     versaclock6: clock-controller@6a {
> >>>         /* Clock Consumer */
> >>>         compatible = "idt,5p49v6965";
> >>> 		reg = <0x6a>;
> >>> 		#clock-cells = <1>;
> >>> 		clocks = <&x304_clk>;
> >>> 		clock-names = "xin";
> >>>
> >>>         assigned-clocks = <&versaclock6 1>,
> >>>                           <&versaclock6 2>,
> >>>                           <&versaclock6 3>,
> >>>                           <&versaclock6 4>;
> >>>         // assigned-clock-rates = <46800000>, <250000000>,
> >>> <1000000>,
> >> <13000000>;
> >>>         assigned-clock-rates = <46800000>, <250000000>, <1000000>,
> >> <13000000>;
> >>>         /* Set the SD/OE pin's settings */
> >>>         idt,shutdown = <0>;
> >>>         idt,output-enable-active = <0>;
> >>>         OUT1 {
> >>>             idt,mode = <VC5_CMOS>;
> >>>             idt,voltage-microvolt = <3300000>;
> >>>             c = <100>;
> >>>         };
> >>>         OUT2 {
> >>>             idt,mode = <VC5_CMOS>;
> >>>             idt,voltage-microvolt = <3300000>;
> >>>             idt,slew-percent = <100>;
> >>>         };
> >>>         OUT3 {
> >>>             idt,mode = <VC5_CMOSD>;
> >>>             idt,voltage-microvolt = <3300000>;
> >>>             idt,slew-percent = <100>;
> >>>         };
> >>>         OUT4 {
> >>>             idt,mode = <VC5_CMOS>;
> >>>             idt,voltage-microvolt = <3300000>;
> >>>             idt,slew-percent = <100>;
> >>>         };
> >>>     };
> >>
> >> Strange. Something you may check (or double check if you already did):
> >>
> >> 1. Read if the register has been set:
> >>
> >>   # not tested, check carefully
> >>   i2cget -y -r 1 0x6a 0x60
> >>
> >> the three low bits in register 0x60 should read 0x1 for CMOS, 0x5 for
> CMOSD.
> >
> > Apparently the register is not getting set properly.
> >
> > In response to 'i2cget -y -f 1 0x6a 0x60' (-r not supported maybe a
> > typo?)
> >
> > I get 0xbb, which according to the spec I believe should give me CMOSD,
> which is what I am seeing ( (D7, D6, D5) = 101: CMOSD ).
> >
> > I can set address 0x60 to 0x3b using i2cset to get single ended CMOS.
> 
> I see. 0xbb is the reset default, so as you said it is not set.
> 
> >> 2. Change idt,mode in device tree and see whether the register
> >> changes or the scope show any different output mode.
> >
> > Changing ide,mode to VC5_LVDS does not the value of register 0x06.  I
> > still get a value of 0xbb
> 
> Ok, coherent with test 1.
> 
> >> 3. Enable debugging output (simpliy add #define DEBUG on top of file
> >> and rebuild), then see whether during clk prepare you see this in dmesg:
> >>
> >>   Update output ... mask 0x... val 0x....
> >>
> >> 4. Check whether the OUT1 node is actually found by adding a
> >> dev_dbg() in vc5_get_output_config(), just before the
> >> of_get_child_by_name() call and
> >> ~5 lines below, between 'return 0' and vc5_update_mode().
> >>
> >> Let us know your findings.
> >>
> >
> > Seems to be finding the nodes ok. Here is the relevant code section:
> >
> > 	// temp for driver debug
> > 	dev_dbg(&client->dev,
> > 			"get_output_config(before of_get_child_by_name)
> OUT%d\n",
> > 			clk_out->num + 1);
> >
> > 	np_output = of_get_child_by_name(client->dev.of_node,
> child_name);
> > 	kfree(child_name);
> > 	if (!np_output)
> > 		return 0;
> >
> > 	// temp for driver debug
> > 	dev_dbg(&client->dev,
> > 			"get_output_config(before update_mode)
> OUT%d\n",
> > 			clk_out->num + 1);
> >
> > 	ret = vc5_update_mode(np_output, clk_out);
> > 	if (ret)
> > 		goto output_error;
> >
> > And dmesg output:
> >
> > 	[    7.498005] vc5 1-006a: get_output_config(before
> of_get_child_by_name)  OUT1
> > 	[    7.498017] vc5 1-006a: get_output_config(before update_mode)
> OUT1
> > 	[    7.511631] vc5 1-006a: get_output_config(before
> of_get_child_by_name)  OUT2
> > 	[    7.511643] vc5 1-006a: get_output_config(before update_mode)
> OUT2
> > 	[    7.525257] vc5 1-006a: get_output_config(before
> of_get_child_by_name)  OUT3
> > 	[    7.525270] vc5 1-006a: get_output_config(before update_mode)
> OUT3
> > 	[    7.538905] vc5 1-006a: get_output_config(before
> of_get_child_by_name)  OUT4
> > 	[    7.538919] vc5 1-006a: get_output_config(before update_mode)
> OUT4
> 
> So the values are picked up from DT and if you print the content of clk_out-
> >clk_output_cfg0[_mask] you should see the correct register values.
> 
> Now the relevant question is question 3: do you enter the 'if (hwdata-
> >clk_output_cfg0_mask)' in vc5_clk_out_prepare()? Do you even enter
> vc5_clk_out_prepare()?
> 
> You can add dev_dbg()s there and track the problem on your own. If
> regmap_update_bits(...hwdata->clk_output_cfg0) is not called then the
> code is not doing the right thing. If it is called and returns no error, then it
> looks like there is a problem in the i2c controller which thinks it has done the
> transaction but it really hasn't. Or some other mystery.
> 
> --
> Luca

I added a few debug statements and I see that vc5_clk_out_prepare() is not being called. So perhaps this ties back to the point Adam made earlier about their needing to be a consumer driver that enables the reference clock because it is not enabled by default.  For my application there is no consumer driver, I only have the device tree.

In my local copy of the driver that adds an 'idt,enable' pattern property I call vc5_clk_out_prepare() if idt,enable is set for an output.  There may be a cleaner way, but this seems to allow enabling of outputs from the device tree.

I did the following:

        // idt,enable mod: add struct clk_hw *hw  arg
        static int vc5_get_output_config(struct i2c_client *client,
                                      struct vc5_out_data *clk_out, struct clk_hw *hw)
        {
            ...
            ret = vc5_update_slew(np_output, clk_out);

            // idt,enable mod: call to vc5_update_enable()
            ret = vc5_update_enable(np_output, hw);
            if (ret)
                goto output_error;

And:

        // begin idt,enable mod
        static int vc5_update_enable(struct device_node *np_output,
                                  struct clk_hw *hw)
        {
            u32 value;

            if (!of_property_read_u32(np_output, "idt,enable", &value)) {
                if (value) {
                    vc5_clk_out_prepare(hw);
                } else {
                    vc5_clk_out_unprepare(hw);
                }
            }
            return 0;
        }
        // end idt,enable mod



-Claude

======================================================================
This message and any attachments are intended only for the designated recipient(s) and may contain confidential or proprietary information and be subject to the attorney-client privilege or other confidentiality protections.  If you are not a designated recipient, you may not review, use, copy or distribute this message or any attachments.  If you received this email in error, please notify the sender by reply e-mail and permanently delete the original and any copies of this message and any attachments thereto.  Thank you.

RE: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Fillion, Claude]

Hello Sean,

> -----Original Message-----
> From: Sean Anderson <sean.anderson@seco.com>
> Sent: Friday, March 4, 2022 3:54 PM
> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Luca Ceresoli
> <luca@lucaceresoli.net>; Adam Ford <aford173@gmail.com>
> Cc: linux-clk <linux-clk@vger.kernel.org>; Klein, Jesse
> <Jesse.Klein@mksinst.com>
> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> versaclock5 driver
> 
> Hi Fillion,
> 
> On 3/3/22 1:15 PM, Fillion, Claude wrote:
> >
> > Here is the relevant portions of my device tree.  On the scope I see the
> default 'CMOSD' voltages and a modified frequency of 46.8MHz.
> >
> > I have also modified my local copy of the driver to accept an 'idt,enable'
> pattern property that allows me to enable outputs from the device tree. It
> needs some refinement but I can pass it along if there is interest.
> >
> > -Claude
> >
> > ==================
> > Top of device tree file:
> > ==================
> > /*
> > This is a message for system-user.dtsi. If you are reading from
> > system-user.dtsi.genxxxx, please note that this message is for explaining
> the purpose of system-user.dist in relation to system-user.dtsi.genxxx.
> >
> > system-user.dtsi is merely a writable file handled by
> > ./https://urldefense.com/v3/__http://buildPetaLinux.sh__;!!KnJ4-
> rp7!1nWV4o1Z2a1YosRnH4Go42ZoidfkoAVwR09FIx4_-
> 813HoUpAhvsxeSOvjKTQyI4B2bf$  to copy the appropriate system-
> user.dtsi.genxxxx to this filename for use in the build image. Do not put your
> device tree here. They belong to the system-user.dtsi.genxxxx.
> >
> > If you add a new dtsi, please create an appropriate device tree file
> > and modify the
> > ./https://urldefense.com/v3/__http://buildPetaLinux.sh__;!!KnJ4-rp7!1n
> > WV4o1Z2a1YosRnH4Go42ZoidfkoAVwR09FIx4_-
> 813HoUpAhvsxeSOvjKTQyI4B2bf$
> > to handle it */
> >
> > #include <dt-bindings/clk/versaclock.h>
> >
> > /include/ "system-conf.dtsi"
> > / {
> >
> >   /* Clock Provider */
> >   x304_clk: x304-clock {
> >     compatible = "fixed-clock";
> >     #clock-cells = <0>;
> >     clock-frequency = <25000000>;
> >   };
> >
> > ...
> >
> > ==================
> > Device Tree Node:
> > ==================
> > &i2c1 {
> >     clock-frequency = <100000>;
> >
> >     // Use patch.  Updated driver for 5p49v6965 available  at
> https://urldefense.com/v3/__https://github.com/Xilinx/linux-
> xlnx/blob/master/drivers/clk/clk-versaclock5.c__;!!KnJ4-
> rp7!1nWV4o1Z2a1YosRnH4Go42ZoidfkoAVwR09FIx4_-
> 813HoUpAhvsxeSOvjKTQx9uQrhl$
> >     // Device Tree Setup ->
> https://urldefense.com/v3/__https://github.com/Xilinx/linux-
> xlnx/blob/master/Documentation/devicetree/bindings/clock/idt*2Cversaclo
> ck5.yaml__;JQ!!KnJ4-rp7!1nWV4o1Z2a1YosRnH4Go42ZoidfkoAVwR09FIx4_-
> 813HoUpAhvsxeSOvjKTQ32kVZaB$
> >     versaclock6: clock-controller@6a {
> >         /* Clock Consumer */
> >         compatible = "idt,5p49v6965";
> > 		reg = <0x6a>;
> > 		#clock-cells = <1>;
> > 		clocks = <&x304_clk>;
> > 		clock-names = "xin";
> >
> >         assigned-clocks = <&versaclock6 1>,
> >                           <&versaclock6 2>,
> >                           <&versaclock6 3>,
> >                           <&versaclock6 4>;
> >         // assigned-clock-rates = <46800000>, <250000000>, <1000000>,
> <13000000>;
> >         assigned-clock-rates = <46800000>, <250000000>, <1000000>,
> <13000000>;
> >         /* Set the SD/OE pin's settings */
> >         idt,shutdown = <0>;
> >         idt,output-enable-active = <0>;
> 
> Have you verified that these are correct? E.g. on my board I had to set
> 
> idt,output-enable-active = <1>;
> 
> You can also remove these properties to use the default values from the
> OTP.
> 
> --Sean

I have removed both properties and observe the same behavior(differential cmos on output 1 and 46.8MHz, no clock on output 2).

-Claude

> 
> >         OUT1 {
> >             idt,mode = <VC5_CMOS>;
> >             idt,voltage-microvolt = <3300000>;
> >             idt,slew-percent = <100>;
> >         };
> >         OUT2 {
> >             idt,mode = <VC5_CMOS>;
> >             idt,voltage-microvolt = <3300000>;
> >             idt,slew-percent = <100>;
> >         };
> >         OUT3 {
> >             idt,mode = <VC5_CMOSD>;
> >             idt,voltage-microvolt = <3300000>;
> >             idt,slew-percent = <100>;
> >         };
> >         OUT4 {
> >             idt,mode = <VC5_CMOS>;
> >             idt,voltage-microvolt = <3300000>;
> >             idt,slew-percent = <100>;
> >         };
> >     };

======================================================================
This message and any attachments are intended only for the designated recipient(s) and may contain confidential or proprietary information and be subject to the attorney-client privilege or other confidentiality protections.  If you are not a designated recipient, you may not review, use, copy or distribute this message or any attachments.  If you received this email in error, please notify the sender by reply e-mail and permanently delete the original and any copies of this message and any attachments thereto.  Thank you.

RE: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Fillion, Claude]

> -----Original Message-----
> From: Fillion, Claude
> Sent: Monday, March 7, 2022 3:39 PM
> To: Luca Ceresoli <luca@lucaceresoli.net>; Adam Ford
> <aford173@gmail.com>
> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
> Subject: RE: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> versaclock5 driver
> 
> Hello Luca
> 
> > -----Original Message-----
> > From: Luca Ceresoli <luca@lucaceresoli.net>
> > Sent: Friday, March 4, 2022 3:30 PM
> > To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> > <aford173@gmail.com>
> > Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> > clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
> > Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> > versaclock5 driver
> >
> > Hi Claude,
> >
> > On 04/03/22 21:07, Fillion, Claude wrote:
> > > Hello Luca,
> > >
> > >> -----Original Message-----
> > >> From: Luca Ceresoli <luca@lucaceresoli.net>
> > >> Sent: Thursday, March 3, 2022 5:34 PM
> > >> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> > >> <aford173@gmail.com>
> > >> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> > >> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
> > >> Subject: Re: [EXTERNAL] Re: Questions regarding regarding
> > >> idt/renesas
> > >> versaclock5 driver
> > >>
> > >> Hi Claude,
> > >>
> > >> On 03/03/22 19:15, Fillion, Claude wrote:
> > >>> Hello Luca,
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Luca Ceresoli <luca@lucaceresoli.net>
> > >>>> Sent: Thursday, March 3, 2022 9:42 AM
> > >>>> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> > >>>> <aford173@gmail.com>
> > >>>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> > >>>> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
> > >>>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding
> > >>>> idt/renesas
> > >>>> versaclock5 driver
> > >>>>
> > >>>> Hi Claude,
> > >>>>
> > >>>> On 02/03/22 21:49, Fillion, Claude wrote:
> > >>>>>
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Luca Ceresoli <luca@lucaceresoli.net>
> > >>>>>> Sent: Wednesday, March 2, 2022 12:27 PM
> > >>>>>> To: Adam Ford <aford173@gmail.com>; Fillion, Claude
> > >>>>>> <Claude.Fillion@mksinst.com>
> > >>>>>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> > >>>>>> clk@vger.kernel.org>
> > >>>>>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding
> > >>>>>> idt/renesas
> > >>>>>> versaclock5 driver
> > >>>>>>
> > >>>>>> Hi,
> > >>>>>>
> > >>>>>> On 02/03/22 16:45, Adam Ford wrote:
> > >>>>>> ...
> > >>>>>>>>>>>>     versaclock6: clock-controller@6a {
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>         /* Clock Consumer */
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>         compatible = "idt,5p49v6965";
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>                                 reg = <0x6a>;
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>                                 #clock-cells = <1>;
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>                                 clocks = <&x304_clk>;
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>                                 clock-names = "xin";
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>         assigned_clocks = <&versaclock6 1>,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>                           <&versaclock6 2>,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>                           <&versaclock6 3>,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>                           <&versaclock6 4>;
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>         assigned_clock_rates = <46800000>, <250000000>,
> > >>>>>>>>>>>> <1000000>, <13000000>;
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> Assigned clocks and assigned clock rates should be hyphens
> > >>>>>>>>>>> and not underscores.
> > >>>>>>>>>>>
> > >>>>>>>>>>> assigned-clocks =  <&versaclock6 1>,   <&versaclock6 2>,
> > >>>>>>>>>>> <&versaclock6 3>, <&versaclock6 4>;
> > >>>>>>>>>>>
> > >>>>>>>>>>> assigned-clock-rates =  <46800000>, <250000000>,
> > >>>>>>>>>>> <1000000>, <13000000>;
> > >>>>>>>>>>>
> > >>>>>>>>>>> Another thing to check is to make sure the consumers of
> > >>>>>>>>>>> these clocks is enabling them.  They do not necessarily
> > >>>>>>>>>>> get enabled by
> > >>>>>> default.
> > >>>>>>>>>>>
> > >>>>>>>>>>> adam
> > >>>>>>>>>>
> > >>>>>>>>>> Doh - thanks.  I looked at it a million times 😊 .
> > >>>>>>>>>>
> > >>>>>>>>>> Now getting desired out1 frequency but nothing on other
> > >> outputs.
> > >>>>>>>>>> From
> > >>>>>>>>> the code it seems vc5_clk_out_prepare() is the method that
> > >>>>>>>>> enables outputs but this method is not being called I am not
> > >>>>>>>>> clear how to make the 'consumer enable them.'
> > >>>>>>>>>>
> > >>>>>>>>>> I have added this to my dtsi to no avail.
> > >>>>>>>>>>
> > >>>>>>>>>>          /* Consumer referencing 5P49V5965 pin OUT1 and
> > >>>>>>>>>> OUT2
> > */
> > >>>>>>>>>>         consumer {
> > >>>>>>>>>>             clocks = <&versaclock6 1>, <&versaclock6 2>;
> > >>>>>>>>>>             /* ... */
> > >>>>>>>>>>          };
> > >>>>>>>>>>
> > >>>>>>>>>> Looking through device tree documentation.
> > >>>>>>>>>
> > >>>>>>>>> It's likely going to be in the consumer's driver.  Check the
> > >>>>>>>>> consumer device tree binding to make sure you've correctly
> > >>>>>>>>> associated the clock.  If the binding doesnt't show a clock
> > >>>>>>>>> is required, it might not know that you using a programmable
> > clock.
> > >>>>>>>>>
> > >>>>>>>>> Here is a patch that I needed to apply to an Ethernet driver
> > >>>>>>>>> which wasn't expecting a programmable clock to drive a
> > >>>>>>>>> reference clock, so the clock wasn't being enabled.
> > >>>>>>>>>
> > >>>>>>>>>
> > >> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux
> > >>>>>>>>> /k
> > >>>>>>>>> er
> > >>>>>>>>> nel/g
> > >>>>>>>>>
> > >>>>
> it/torvalds/linux.git/commit/drivers/net/ethernet/renesas/ravb_main.
> > >>>>>>>>> c?id=
> > >>>>>>>>> 8ef7adc6beb2ef0bce83513dc9e4505e7b21e8c2__;!!KnJ4-
> > >> rp7!1Qb17q-
> > >>>>>>>>>
> > >>>>>>
> > >>>>
> > >>
> > TWrV62AeQtTNNVDErVbyhbXB1sukyT2ggvFPUltIBI5nIKzNnjVOcqlw8qJyy$
> > >>>>>>>>>
> > >>>>>>>>> Look at the use of devm_clk_get_optional and
> > >>>>>>>>> clk_prepare_enable from that patch.  (yes, there is a
> > >>>>>>>>> subsequent patch that fixes something I didn't quite do
> > >>>>>>>>> right, but the basics are here)
> > >>>>>>>>>
> > >>>>>>>>> The consumer drivers need to 'get' the clock so it can
> > >>>>>>>>> associate itself to the clock in question.  Once the
> > >>>>>>>>> relationship is established, the consumer needs to call
> > >>>>>>>>> clk_prepare_enable() which
> > >>>>>> uses the clock system to turn the clock on.
> > >>>>>>>>> Without this step, it's likely the Versaclock won't generate
> > >>>>>>>>> a signal, because it doesn't know it needs to turn it on.
> > >>>>>>>>>
> > >>>>>>>>> adam
> > >>>>>>>>
> > >>>>>>>> Not sure I fully follow.  I see that clk out1 is enabled but
> > >>>>>>>> the other
> > >>>>>> channels are not so it would seem my difficulty is with
> > >>>>>> individual
> > >> channels.
> > >>>>>>>
> > >>>>>>> Do the devices that need the clock from the versaclock
> > >>>>>>> reference the versaclock?  If so, to those drivers use the get and
> enable?
> > >>>>>>> If not, the versaclock will stay off.  In the patch example I
> > >>>>>>> showed, I had to modify the Ethernet driver on a processor,
> > >>>>>>> because it didn't explicitly enable the reference clock.  That
> > >>>>>>> Ethernet driver expected the refclk was always present which
> > >>>>>>> was a
> > >> false assumption.
> > >>>>>>> Once I got the consumer device (in this case, Ethernet) to
> > >>>>>>> request and enable the clock, the clock subsystem enabled the
> > >>>>>>> corresponding output on the versaclock.
> > >>>>>>>
> > >>>>>>> For the Ethernet example I cited above, the corresponding
> > >>>>>>> device tree looks like:
> > >>>>>>>
> > >>>>>>> &avb {
> > >>>>>>>      clocks = <&cpg CPG_MOD 812>, <&versaclock5 4>;
> > >>>>>>>      clock-names = "fck", "refclk";
> > >>>>>>>      status = "okay";
> > >>>>>>> };
> > >>>>>>>
> > >>>>>>> With this device tree reference, the 'refclk' gets associated
> > >>>>>>> to versaclock ouput 4.  When the Ethernet needs the clock, it
> > >>>>>>> calls clk_prepare_enable on that clock reference, and the
> > >>>>>>> clock system calls on the versaclock driver to enable the
> > >>>>>>> output.  The reason I needed to submit that patch was that the
> > >>>>>>> consumer driver (the Ethernet in this
> > >>>>>>> case) wasn't calling the clk_prepare_enable, so the clock
> > >>>>>>> remained off.  It's likely that whatever devices that need the
> > >>>>>>> clock from the versaclock will need both a device tree
> > >>>>>>> reference to it as well as a call to clk_prepare_enable.
> > >>>>>>>
> > >>>>>>>>
> > >>>>>>>> In my simple application I would like to enable outputs, on a
> > >>>>>>>> per channel
> > >>>>>> basis, from the device tree.  Would it make sense  to add  an
> > >> 'idt,enable'
> > >>>>>> property in similar fashion to the existing idt,mode,
> > >>>>>> idt,voltage-microvolt, and idt,slew-percent properties?  Then
> > >>>>>> vc5_get_output_config() could be modified to also call
> > >>>>>> vc5_clk_out_prepare() (or clk_prepare_enable(), which in turn
> > >>>>>> would call
> > >>>> vc5_clk_out_prepare()).
> > >>>>>>>
> > >>>>>>> I can't speak for the linux clock group, but the advantage of
> > >>>>>>> patching the drivers that need the clocks generated from the
> > >>>>>>> versaclock is the ability to stop these clocks when the
> > >>>>>>> drivers are halted and/or suspended.
> > >>>>>>
> > >>>>>> Having the consumer driver get, prepare and enable the clock is
> > >>>>>> of course the best as Adam explained.
> > >>>>>>
> > >>>>>> However I think using assigned-clocks and assigned-clock-rates
> > >>>>>> should enable the clocks unconditionally even if the consumer
> > >>>>>> driver does not do any clk_*() calls. Might be worth double
> > >>>>>> checking
> > >> that.
> > >>>>>>
> > >>>>>> --
> > >>>>>> Luca
> > >>>>>
> > >>>>> In our application we plan to use the 6965/6901 to replace a
> > >>>>> part that does
> > >>>> not use a consumer driver.  We just set clock options in our device
> tree.
> > >>>> Ideally that is how we would like to use the Renesas part as well.
> > >>>>>
> > >>>>> In the limited testing I have done thus far behavior is a bit
> > >>>>> puzzling.  From
> > >>>> the device tree I am able to change the clock frequency for out1
> > >>>> (which is enabled by default) and I can disable outputs using
> > >>>> 'idt,shutdown', but I cannot change the logic levels for out1
> > >>>> using the
> > >> 'idt,mode' parameter.
> > >>>>
> > >>>> This is very strange.
> > >>>>
> > >>>> Did you double-check that your device tree description of the
> > >>>> versaclock node is correct according to [0]?
> > >>>>
> > >>>> Please send the complete  description of the versaclock node in
> > >>>> your device tree, so we can check it and see if any detail is misplaced.
> > >>>>
> > >>>> [0]
> > >>>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/
> > >>>> ke
> > >>>> rn
> > >>>> el/g
> > >>>> it/torvalds/linux.git/tree/Documentation/devicetree/bindings/cloc
> > >>>> k/
> > >>>> id
> > >>>> t,vers
> > >>>> aclock5.yaml*n169__;Iw!!KnJ4-
> > >>>> rp7!yalfgsfaZKSlo4yNfQfvlbsmNKBRltGSetoIonP--5aGebuHUJ-M-
> > >>>> am93tjT8aEhsSJJ$
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Luca
> > >>>
> > >>> Here is the relevant portions of my device tree.  On the scope I
> > >>> see the
> > >> default 'CMOSD' voltages and a modified frequency of 46.8MHz.
> > >>>
> > >>> I have also modified my local copy of the driver to accept an
> 'idt,enable'
> > >> pattern property that allows me to enable outputs from the device
> > >> tree. It needs some refinement but I can pass it along if there is interest.
> > >>>
> > >>> -Claude
> > >>>
> > >>> ==================
> > >>> Top of device tree file:
> > >>> ==================
> > >>> /*
> > >>> This is a message for system-user.dtsi. If you are reading from
> > >>> system-user.dtsi.genxxxx, please note that this message is for
> > >>> explaining
> > >> the purpose of system-user.dist in relation to system-user.dtsi.genxxx.
> > >>>
> > >>> system-user.dtsi is merely a writable file handled by
> > >>> ./https://urldefense.com/v3/__http://buildPetaLinux.sh__;!!KnJ4-
> > >> rp7!w34odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
> > >> J3Uswvovc00BUt$  to copy the appropriate system-user.dtsi.genxxxx
> > >> to this filename for use in the build image. Do not put your device
> > >> tree here. They belong to the system-user.dtsi.genxxxx.
> > >>>
> > >>> If you add a new dtsi, please create an appropriate device tree
> > >>> file and modify the
> > >>> ./https://urldefense.com/v3/__http://buildPetaLinux.sh__;!!KnJ4-
> rp7!
> > >>> w3
> > >>> 4odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
> > >> J3Uswvovc00BUt$
> > >>> to handle it */
> > >>>
> > >>> #include <dt-bindings/clk/versaclock.h>
> > >>>
> > >>> /include/ "system-conf.dtsi"
> > >>> / {
> > >>>
> > >>>   /* Clock Provider */
> > >>>   x304_clk: x304-clock {
> > >>>     compatible = "fixed-clock";
> > >>>     #clock-cells = <0>;
> > >>>     clock-frequency = <25000000>;
> > >>>   };
> > >>>
> > >>> ...
> > >>>
> > >>> ==================
> > >>> Device Tree Node:
> > >>> ==================
> > >>> &i2c1 {
> > >>>     clock-frequency = <100000>;
> > >>>
> > >>>     // Use patch.  Updated driver for 5p49v6965 available  at
> > >> https://urldefense.com/v3/__https://github.com/Xilinx/linux-
> > >> xlnx/blob/master/drivers/clk/clk-versaclock5.c__;!!KnJ4-
> > >> rp7!w34odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
> > >> J3UswvoiTIHWiN$
> > >>>     // Device Tree Setup ->
> > >> https://urldefense.com/v3/__https://github.com/Xilinx/linux-
> > >>
> > xlnx/blob/master/Documentation/devicetree/bindings/clock/idt*2Cversac
> > >> lo
> > >> ck5.yaml__;JQ!!KnJ4-rp7!w34odUyH6hHBct-rWC671nddpz5440f-
> > >> viaETLtFnGYMlkuB7P0ye-J3Uswvor3hNb3f$
> > >>>     versaclock6: clock-controller@6a {
> > >>>         /* Clock Consumer */
> > >>>         compatible = "idt,5p49v6965";
> > >>> 		reg = <0x6a>;
> > >>> 		#clock-cells = <1>;
> > >>> 		clocks = <&x304_clk>;
> > >>> 		clock-names = "xin";
> > >>>
> > >>>         assigned-clocks = <&versaclock6 1>,
> > >>>                           <&versaclock6 2>,
> > >>>                           <&versaclock6 3>,
> > >>>                           <&versaclock6 4>;
> > >>>         // assigned-clock-rates = <46800000>, <250000000>,
> > >>> <1000000>,
> > >> <13000000>;
> > >>>         assigned-clock-rates = <46800000>, <250000000>, <1000000>,
> > >> <13000000>;
> > >>>         /* Set the SD/OE pin's settings */
> > >>>         idt,shutdown = <0>;
> > >>>         idt,output-enable-active = <0>;
> > >>>         OUT1 {
> > >>>             idt,mode = <VC5_CMOS>;
> > >>>             idt,voltage-microvolt = <3300000>;
> > >>>             c = <100>;
> > >>>         };
> > >>>         OUT2 {
> > >>>             idt,mode = <VC5_CMOS>;
> > >>>             idt,voltage-microvolt = <3300000>;
> > >>>             idt,slew-percent = <100>;
> > >>>         };
> > >>>         OUT3 {
> > >>>             idt,mode = <VC5_CMOSD>;
> > >>>             idt,voltage-microvolt = <3300000>;
> > >>>             idt,slew-percent = <100>;
> > >>>         };
> > >>>         OUT4 {
> > >>>             idt,mode = <VC5_CMOS>;
> > >>>             idt,voltage-microvolt = <3300000>;
> > >>>             idt,slew-percent = <100>;
> > >>>         };
> > >>>     };
> > >>
> > >> Strange. Something you may check (or double check if you already did):
> > >>
> > >> 1. Read if the register has been set:
> > >>
> > >>   # not tested, check carefully
> > >>   i2cget -y -r 1 0x6a 0x60
> > >>
> > >> the three low bits in register 0x60 should read 0x1 for CMOS, 0x5
> > >> for
> > CMOSD.
> > >
> > > Apparently the register is not getting set properly.
> > >
> > > In response to 'i2cget -y -f 1 0x6a 0x60' (-r not supported maybe a
> > > typo?)
> > >
> > > I get 0xbb, which according to the spec I believe should give me
> > > CMOSD,
> > which is what I am seeing ( (D7, D6, D5) = 101: CMOSD ).
> > >
> > > I can set address 0x60 to 0x3b using i2cset to get single ended CMOS.
> >
> > I see. 0xbb is the reset default, so as you said it is not set.
> >
> > >> 2. Change idt,mode in device tree and see whether the register
> > >> changes or the scope show any different output mode.
> > >
> > > Changing ide,mode to VC5_LVDS does not the value of register 0x06.
> > > I still get a value of 0xbb
> >
> > Ok, coherent with test 1.
> >
> > >> 3. Enable debugging output (simpliy add #define DEBUG on top of
> > >> file and rebuild), then see whether during clk prepare you see this in
> dmesg:
> > >>
> > >>   Update output ... mask 0x... val 0x....
> > >>
> > >> 4. Check whether the OUT1 node is actually found by adding a
> > >> dev_dbg() in vc5_get_output_config(), just before the
> > >> of_get_child_by_name() call and
> > >> ~5 lines below, between 'return 0' and vc5_update_mode().
> > >>
> > >> Let us know your findings.
> > >>
> > >
> > > Seems to be finding the nodes ok. Here is the relevant code section:
> > >
> > > 	// temp for driver debug
> > > 	dev_dbg(&client->dev,
> > > 			"get_output_config(before of_get_child_by_name)
> > OUT%d\n",
> > > 			clk_out->num + 1);
> > >
> > > 	np_output = of_get_child_by_name(client->dev.of_node,
> > child_name);
> > > 	kfree(child_name);
> > > 	if (!np_output)
> > > 		return 0;
> > >
> > > 	// temp for driver debug
> > > 	dev_dbg(&client->dev,
> > > 			"get_output_config(before update_mode)
> > OUT%d\n",
> > > 			clk_out->num + 1);
> > >
> > > 	ret = vc5_update_mode(np_output, clk_out);
> > > 	if (ret)
> > > 		goto output_error;
> > >
> > > And dmesg output:
> > >
> > > 	[    7.498005] vc5 1-006a: get_output_config(before
> > of_get_child_by_name)  OUT1
> > > 	[    7.498017] vc5 1-006a: get_output_config(before update_mode)
> > OUT1
> > > 	[    7.511631] vc5 1-006a: get_output_config(before
> > of_get_child_by_name)  OUT2
> > > 	[    7.511643] vc5 1-006a: get_output_config(before update_mode)
> > OUT2
> > > 	[    7.525257] vc5 1-006a: get_output_config(before
> > of_get_child_by_name)  OUT3
> > > 	[    7.525270] vc5 1-006a: get_output_config(before update_mode)
> > OUT3
> > > 	[    7.538905] vc5 1-006a: get_output_config(before
> > of_get_child_by_name)  OUT4
> > > 	[    7.538919] vc5 1-006a: get_output_config(before update_mode)
> > OUT4
> >
> > So the values are picked up from DT and if you print the content of
> > clk_out-
> > >clk_output_cfg0[_mask] you should see the correct register values.
> >
> > Now the relevant question is question 3: do you enter the 'if (hwdata-
> > >clk_output_cfg0_mask)' in vc5_clk_out_prepare()? Do you even enter
> > vc5_clk_out_prepare()?
> >
> > You can add dev_dbg()s there and track the problem on your own. If
> > regmap_update_bits(...hwdata->clk_output_cfg0) is not called then the
> > code is not doing the right thing. If it is called and returns no
> > error, then it looks like there is a problem in the i2c controller
> > which thinks it has done the transaction but it really hasn't. Or some other
> mystery.
> >
> > --
> > Luca
> 
> I added a few debug statements and I see that vc5_clk_out_prepare() is not
> being called. So perhaps this ties back to the point Adam made earlier about
> their needing to be a consumer driver that enables the reference clock
> because it is not enabled by default.  For my application there is no consumer
> driver, I only have the device tree.
> 
> In my local copy of the driver that adds an 'idt,enable' pattern property I call
> vc5_clk_out_prepare() if idt,enable is set for an output.  There may be a
> cleaner way, but this seems to allow enabling of outputs from the device
> tree.
> 
> I did the following:
> 
>         // idt,enable mod: add struct clk_hw *hw  arg
>         static int vc5_get_output_config(struct i2c_client *client,
>                                       struct vc5_out_data *clk_out, struct clk_hw *hw)
>         {
>             ...
>             ret = vc5_update_slew(np_output, clk_out);
> 
>             // idt,enable mod: call to vc5_update_enable()
>             ret = vc5_update_enable(np_output, hw);
>             if (ret)
>                 goto output_error;
> 
> And:
> 
>         // begin idt,enable mod
>         static int vc5_update_enable(struct device_node *np_output,
>                                   struct clk_hw *hw)
>         {
>             u32 value;
> 
>             if (!of_property_read_u32(np_output, "idt,enable", &value)) {
>                 if (value) {
>                     vc5_clk_out_prepare(hw);
>                 } else {
>                     vc5_clk_out_unprepare(hw);
>                 }
>             }
>             return 0;
>         }
>         // end idt,enable mod
> 
> 
> 
> -Claude

Here is the relevant Device Tree section:

versaclock6: clock-controller@6a {
        /* Clock Consumer */
        compatible = "idt,5p49v6965";
		reg = <0x6a>;
		#clock-cells = <1>;
		clocks = <&x304_clk>;
		clock-names = "xin";

        assigned-clocks = <&versaclock6 1>,
                          <&versaclock6 2>,
                          <&versaclock6 3>,
                          <&versaclock6 4>;
        // assigned-clock-rates = <46800000>, <250000000>, <1000000>, <13000000>;
        assigned-clock-rates = <46800000>, <250000000>, <1000000>, <13000000>;
        /* Set the SD/OE pin's settings */
        // idt,shutdown = <0>;
        // idt,output-enable-active = <0>;
        OUT1 {
            idt,mode = <VC5_CMOS>;
            idt,voltage-microvolt = <3300000>;
            idt,slew-percent = <100>;
            idt,enable = <1>;
        };
        OUT2 {
            // idt,mode = <VC5_LVDS>;
            idt,mode = <VC5_LVDS>;
            idt,voltage-microvolt = <3300000>;
            idt,slew-percent = <100>;
            idt,enable = <1>;
        };
        OUT3 {
            idt,mode = <VC5_CMOSD>;
            idt,voltage-microvolt = <3300000>;
            idt,slew-percent = <100>;
            idt,enable = <0>;
        };
        OUT4 {
            idt,mode = <VC5_CMOS>;
            idt,voltage-microvolt = <3300000>;
            idt,slew-percent = <100>;
            idt,enable = <1>;
        };
    };

======================================================================
This message and any attachments are intended only for the designated recipient(s) and may contain confidential or proprietary information and be subject to the attorney-client privilege or other confidentiality protections.  If you are not a designated recipient, you may not review, use, copy or distribute this message or any attachments.  If you received this email in error, please notify the sender by reply e-mail and permanently delete the original and any copies of this message and any attachments thereto.  Thank you.

Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Luca Ceresoli]

Hi Claude,

On 07/03/22 21:39, Fillion, Claude wrote:
> Hello Luca
> 
>> -----Original Message-----
>> From: Luca Ceresoli <luca@lucaceresoli.net>
>> Sent: Friday, March 4, 2022 3:30 PM
>> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
>> <aford173@gmail.com>
>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
>> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
>> versaclock5 driver
>>
>> Hi Claude,
>>
>> On 04/03/22 21:07, Fillion, Claude wrote:
>>> Hello Luca,
>>>
>>>> -----Original Message-----
>>>> From: Luca Ceresoli <luca@lucaceresoli.net>
>>>> Sent: Thursday, March 3, 2022 5:34 PM
>>>> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
>>>> <aford173@gmail.com>
>>>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
>>>> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
>>>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
>>>> versaclock5 driver
>>>>
>>>> Hi Claude,
>>>>
>>>> On 03/03/22 19:15, Fillion, Claude wrote:
>>>>> Hello Luca,
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Luca Ceresoli <luca@lucaceresoli.net>
>>>>>> Sent: Thursday, March 3, 2022 9:42 AM
>>>>>> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
>>>>>> <aford173@gmail.com>
>>>>>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
>>>>>> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
>>>>>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding
>>>>>> idt/renesas
>>>>>> versaclock5 driver
>>>>>>
>>>>>> Hi Claude,
>>>>>>
>>>>>> On 02/03/22 21:49, Fillion, Claude wrote:
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Luca Ceresoli <luca@lucaceresoli.net>
>>>>>>>> Sent: Wednesday, March 2, 2022 12:27 PM
>>>>>>>> To: Adam Ford <aford173@gmail.com>; Fillion, Claude
>>>>>>>> <Claude.Fillion@mksinst.com>
>>>>>>>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
>>>>>>>> clk@vger.kernel.org>
>>>>>>>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding
>>>>>>>> idt/renesas
>>>>>>>> versaclock5 driver
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 02/03/22 16:45, Adam Ford wrote:
>>>>>>>> ...
>>>>>>>>>>>>>>     versaclock6: clock-controller@6a {
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         /* Clock Consumer */
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         compatible = "idt,5p49v6965";
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                                 reg = <0x6a>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                                 #clock-cells = <1>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                                 clocks = <&x304_clk>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                                 clock-names = "xin";
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         assigned_clocks = <&versaclock6 1>,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                           <&versaclock6 2>,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                           <&versaclock6 3>,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                           <&versaclock6 4>;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         assigned_clock_rates = <46800000>, <250000000>,
>>>>>>>>>>>>>> <1000000>, <13000000>;
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Assigned clocks and assigned clock rates should be hyphens
>>>>>>>>>>>>> and not underscores.
>>>>>>>>>>>>>
>>>>>>>>>>>>> assigned-clocks =  <&versaclock6 1>,   <&versaclock6 2>,
>>>>>>>>>>>>> <&versaclock6 3>, <&versaclock6 4>;
>>>>>>>>>>>>>
>>>>>>>>>>>>> assigned-clock-rates =  <46800000>, <250000000>, <1000000>,
>>>>>>>>>>>>> <13000000>;
>>>>>>>>>>>>>
>>>>>>>>>>>>> Another thing to check is to make sure the consumers of
>>>>>>>>>>>>> these clocks is enabling them.  They do not necessarily get
>>>>>>>>>>>>> enabled by
>>>>>>>> default.
>>>>>>>>>>>>>
>>>>>>>>>>>>> adam
>>>>>>>>>>>>
>>>>>>>>>>>> Doh - thanks.  I looked at it a million times 😊 .
>>>>>>>>>>>>
>>>>>>>>>>>> Now getting desired out1 frequency but nothing on other
>>>> outputs.
>>>>>>>>>>>> From
>>>>>>>>>>> the code it seems vc5_clk_out_prepare() is the method that
>>>>>>>>>>> enables outputs but this method is not being called I am not
>>>>>>>>>>> clear how to make the 'consumer enable them.'
>>>>>>>>>>>>
>>>>>>>>>>>> I have added this to my dtsi to no avail.
>>>>>>>>>>>>
>>>>>>>>>>>>          /* Consumer referencing 5P49V5965 pin OUT1 and OUT2
>> */
>>>>>>>>>>>>         consumer {
>>>>>>>>>>>>             clocks = <&versaclock6 1>, <&versaclock6 2>;
>>>>>>>>>>>>             /* ... */
>>>>>>>>>>>>          };
>>>>>>>>>>>>
>>>>>>>>>>>> Looking through device tree documentation.
>>>>>>>>>>>
>>>>>>>>>>> It's likely going to be in the consumer's driver.  Check the
>>>>>>>>>>> consumer device tree binding to make sure you've correctly
>>>>>>>>>>> associated the clock.  If the binding doesnt't show a clock is
>>>>>>>>>>> required, it might not know that you using a programmable
>> clock.
>>>>>>>>>>>
>>>>>>>>>>> Here is a patch that I needed to apply to an Ethernet driver
>>>>>>>>>>> which wasn't expecting a programmable clock to drive a
>>>>>>>>>>> reference clock, so the clock wasn't being enabled.
>>>>>>>>>>>
>>>>>>>>>>>
>>>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux
>>>>>>>>>>> /k
>>>>>>>>>>> er
>>>>>>>>>>> nel/g
>>>>>>>>>>>
>>>>>> it/torvalds/linux.git/commit/drivers/net/ethernet/renesas/ravb_main.
>>>>>>>>>>> c?id=
>>>>>>>>>>> 8ef7adc6beb2ef0bce83513dc9e4505e7b21e8c2__;!!KnJ4-
>>>> rp7!1Qb17q-
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> TWrV62AeQtTNNVDErVbyhbXB1sukyT2ggvFPUltIBI5nIKzNnjVOcqlw8qJyy$
>>>>>>>>>>>
>>>>>>>>>>> Look at the use of devm_clk_get_optional and
>>>>>>>>>>> clk_prepare_enable from that patch.  (yes, there is a
>>>>>>>>>>> subsequent patch that fixes something I didn't quite do right,
>>>>>>>>>>> but the basics are here)
>>>>>>>>>>>
>>>>>>>>>>> The consumer drivers need to 'get' the clock so it can
>>>>>>>>>>> associate itself to the clock in question.  Once the
>>>>>>>>>>> relationship is established, the consumer needs to call
>>>>>>>>>>> clk_prepare_enable() which
>>>>>>>> uses the clock system to turn the clock on.
>>>>>>>>>>> Without this step, it's likely the Versaclock won't generate a
>>>>>>>>>>> signal, because it doesn't know it needs to turn it on.
>>>>>>>>>>>
>>>>>>>>>>> adam
>>>>>>>>>>
>>>>>>>>>> Not sure I fully follow.  I see that clk out1 is enabled but
>>>>>>>>>> the other
>>>>>>>> channels are not so it would seem my difficulty is with
>>>>>>>> individual
>>>> channels.
>>>>>>>>>
>>>>>>>>> Do the devices that need the clock from the versaclock reference
>>>>>>>>> the versaclock?  If so, to those drivers use the get and enable?
>>>>>>>>> If not, the versaclock will stay off.  In the patch example I
>>>>>>>>> showed, I had to modify the Ethernet driver on a processor,
>>>>>>>>> because it didn't explicitly enable the reference clock.  That
>>>>>>>>> Ethernet driver expected the refclk was always present which was
>>>>>>>>> a
>>>> false assumption.
>>>>>>>>> Once I got the consumer device (in this case, Ethernet) to
>>>>>>>>> request and enable the clock, the clock subsystem enabled the
>>>>>>>>> corresponding output on the versaclock.
>>>>>>>>>
>>>>>>>>> For the Ethernet example I cited above, the corresponding device
>>>>>>>>> tree looks like:
>>>>>>>>>
>>>>>>>>> &avb {
>>>>>>>>>      clocks = <&cpg CPG_MOD 812>, <&versaclock5 4>;
>>>>>>>>>      clock-names = "fck", "refclk";
>>>>>>>>>      status = "okay";
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> With this device tree reference, the 'refclk' gets associated to
>>>>>>>>> versaclock ouput 4.  When the Ethernet needs the clock, it calls
>>>>>>>>> clk_prepare_enable on that clock reference, and the clock system
>>>>>>>>> calls on the versaclock driver to enable the output.  The reason
>>>>>>>>> I needed to submit that patch was that the consumer driver (the
>>>>>>>>> Ethernet in this
>>>>>>>>> case) wasn't calling the clk_prepare_enable, so the clock
>>>>>>>>> remained off.  It's likely that whatever devices that need the
>>>>>>>>> clock from the versaclock will need both a device tree reference
>>>>>>>>> to it as well as a call to clk_prepare_enable.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In my simple application I would like to enable outputs, on a
>>>>>>>>>> per channel
>>>>>>>> basis, from the device tree.  Would it make sense  to add  an
>>>> 'idt,enable'
>>>>>>>> property in similar fashion to the existing idt,mode,
>>>>>>>> idt,voltage-microvolt, and idt,slew-percent properties?  Then
>>>>>>>> vc5_get_output_config() could be modified to also call
>>>>>>>> vc5_clk_out_prepare() (or clk_prepare_enable(), which in turn
>>>>>>>> would call
>>>>>> vc5_clk_out_prepare()).
>>>>>>>>>
>>>>>>>>> I can't speak for the linux clock group, but the advantage of
>>>>>>>>> patching the drivers that need the clocks generated from the
>>>>>>>>> versaclock is the ability to stop these clocks when the drivers
>>>>>>>>> are halted and/or suspended.
>>>>>>>>
>>>>>>>> Having the consumer driver get, prepare and enable the clock is
>>>>>>>> of course the best as Adam explained.
>>>>>>>>
>>>>>>>> However I think using assigned-clocks and assigned-clock-rates
>>>>>>>> should enable the clocks unconditionally even if the consumer
>>>>>>>> driver does not do any clk_*() calls. Might be worth double
>>>>>>>> checking
>>>> that.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Luca
>>>>>>>
>>>>>>> In our application we plan to use the 6965/6901 to replace a part
>>>>>>> that does
>>>>>> not use a consumer driver.  We just set clock options in our device tree.
>>>>>> Ideally that is how we would like to use the Renesas part as well.
>>>>>>>
>>>>>>> In the limited testing I have done thus far behavior is a bit
>>>>>>> puzzling.  From
>>>>>> the device tree I am able to change the clock frequency for out1
>>>>>> (which is enabled by default) and I can disable outputs using
>>>>>> 'idt,shutdown', but I cannot change the logic levels for out1 using
>>>>>> the
>>>> 'idt,mode' parameter.
>>>>>>
>>>>>> This is very strange.
>>>>>>
>>>>>> Did you double-check that your device tree description of the
>>>>>> versaclock node is correct according to [0]?
>>>>>>
>>>>>> Please send the complete  description of the versaclock node in
>>>>>> your device tree, so we can check it and see if any detail is misplaced.
>>>>>>
>>>>>> [0]
>>>>>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/ke
>>>>>> rn
>>>>>> el/g
>>>>>> it/torvalds/linux.git/tree/Documentation/devicetree/bindings/clock/
>>>>>> id
>>>>>> t,vers
>>>>>> aclock5.yaml*n169__;Iw!!KnJ4-
>>>>>> rp7!yalfgsfaZKSlo4yNfQfvlbsmNKBRltGSetoIonP--5aGebuHUJ-M-
>>>>>> am93tjT8aEhsSJJ$
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Luca
>>>>>
>>>>> Here is the relevant portions of my device tree.  On the scope I see
>>>>> the
>>>> default 'CMOSD' voltages and a modified frequency of 46.8MHz.
>>>>>
>>>>> I have also modified my local copy of the driver to accept an 'idt,enable'
>>>> pattern property that allows me to enable outputs from the device
>>>> tree. It needs some refinement but I can pass it along if there is interest.
>>>>>
>>>>> -Claude
>>>>>
>>>>> ==================
>>>>> Top of device tree file:
>>>>> ==================
>>>>> /*
>>>>> This is a message for system-user.dtsi. If you are reading from
>>>>> system-user.dtsi.genxxxx, please note that this message is for
>>>>> explaining
>>>> the purpose of system-user.dist in relation to system-user.dtsi.genxxx.
>>>>>
>>>>> system-user.dtsi is merely a writable file handled by
>>>>> ./https://urldefense.com/v3/__http://buildPetaLinux.sh__;!!KnJ4-
>>>> rp7!w34odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
>>>> J3Uswvovc00BUt$  to copy the appropriate system-user.dtsi.genxxxx to
>>>> this filename for use in the build image. Do not put your device tree
>>>> here. They belong to the system-user.dtsi.genxxxx.
>>>>>
>>>>> If you add a new dtsi, please create an appropriate device tree file
>>>>> and modify the
>>>>> ./https://urldefense.com/v3/__http://buildPetaLinux.sh__;!!KnJ4-rp7!
>>>>> w3
>>>>> 4odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
>>>> J3Uswvovc00BUt$
>>>>> to handle it */
>>>>>
>>>>> #include <dt-bindings/clk/versaclock.h>
>>>>>
>>>>> /include/ "system-conf.dtsi"
>>>>> / {
>>>>>
>>>>>   /* Clock Provider */
>>>>>   x304_clk: x304-clock {
>>>>>     compatible = "fixed-clock";
>>>>>     #clock-cells = <0>;
>>>>>     clock-frequency = <25000000>;
>>>>>   };
>>>>>
>>>>> ...
>>>>>
>>>>> ==================
>>>>> Device Tree Node:
>>>>> ==================
>>>>> &i2c1 {
>>>>>     clock-frequency = <100000>;
>>>>>
>>>>>     // Use patch.  Updated driver for 5p49v6965 available  at
>>>> https://urldefense.com/v3/__https://github.com/Xilinx/linux-
>>>> xlnx/blob/master/drivers/clk/clk-versaclock5.c__;!!KnJ4-
>>>> rp7!w34odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
>>>> J3UswvoiTIHWiN$
>>>>>     // Device Tree Setup ->
>>>> https://urldefense.com/v3/__https://github.com/Xilinx/linux-
>>>>
>> xlnx/blob/master/Documentation/devicetree/bindings/clock/idt*2Cversac
>>>> lo
>>>> ck5.yaml__;JQ!!KnJ4-rp7!w34odUyH6hHBct-rWC671nddpz5440f-
>>>> viaETLtFnGYMlkuB7P0ye-J3Uswvor3hNb3f$
>>>>>     versaclock6: clock-controller@6a {
>>>>>         /* Clock Consumer */
>>>>>         compatible = "idt,5p49v6965";
>>>>> 		reg = <0x6a>;
>>>>> 		#clock-cells = <1>;
>>>>> 		clocks = <&x304_clk>;
>>>>> 		clock-names = "xin";
>>>>>
>>>>>         assigned-clocks = <&versaclock6 1>,
>>>>>                           <&versaclock6 2>,
>>>>>                           <&versaclock6 3>,
>>>>>                           <&versaclock6 4>;
>>>>>         // assigned-clock-rates = <46800000>, <250000000>,
>>>>> <1000000>,
>>>> <13000000>;
>>>>>         assigned-clock-rates = <46800000>, <250000000>, <1000000>,
>>>> <13000000>;
>>>>>         /* Set the SD/OE pin's settings */
>>>>>         idt,shutdown = <0>;
>>>>>         idt,output-enable-active = <0>;
>>>>>         OUT1 {
>>>>>             idt,mode = <VC5_CMOS>;
>>>>>             idt,voltage-microvolt = <3300000>;
>>>>>             c = <100>;
>>>>>         };
>>>>>         OUT2 {
>>>>>             idt,mode = <VC5_CMOS>;
>>>>>             idt,voltage-microvolt = <3300000>;
>>>>>             idt,slew-percent = <100>;
>>>>>         };
>>>>>         OUT3 {
>>>>>             idt,mode = <VC5_CMOSD>;
>>>>>             idt,voltage-microvolt = <3300000>;
>>>>>             idt,slew-percent = <100>;
>>>>>         };
>>>>>         OUT4 {
>>>>>             idt,mode = <VC5_CMOS>;
>>>>>             idt,voltage-microvolt = <3300000>;
>>>>>             idt,slew-percent = <100>;
>>>>>         };
>>>>>     };
>>>>
>>>> Strange. Something you may check (or double check if you already did):
>>>>
>>>> 1. Read if the register has been set:
>>>>
>>>>   # not tested, check carefully
>>>>   i2cget -y -r 1 0x6a 0x60
>>>>
>>>> the three low bits in register 0x60 should read 0x1 for CMOS, 0x5 for
>> CMOSD.
>>>
>>> Apparently the register is not getting set properly.
>>>
>>> In response to 'i2cget -y -f 1 0x6a 0x60' (-r not supported maybe a
>>> typo?)
>>>
>>> I get 0xbb, which according to the spec I believe should give me CMOSD,
>> which is what I am seeing ( (D7, D6, D5) = 101: CMOSD ).
>>>
>>> I can set address 0x60 to 0x3b using i2cset to get single ended CMOS.
>>
>> I see. 0xbb is the reset default, so as you said it is not set.
>>
>>>> 2. Change idt,mode in device tree and see whether the register
>>>> changes or the scope show any different output mode.
>>>
>>> Changing ide,mode to VC5_LVDS does not the value of register 0x06.  I
>>> still get a value of 0xbb
>>
>> Ok, coherent with test 1.
>>
>>>> 3. Enable debugging output (simpliy add #define DEBUG on top of file
>>>> and rebuild), then see whether during clk prepare you see this in dmesg:
>>>>
>>>>   Update output ... mask 0x... val 0x....
>>>>
>>>> 4. Check whether the OUT1 node is actually found by adding a
>>>> dev_dbg() in vc5_get_output_config(), just before the
>>>> of_get_child_by_name() call and
>>>> ~5 lines below, between 'return 0' and vc5_update_mode().
>>>>
>>>> Let us know your findings.
>>>>
>>>
>>> Seems to be finding the nodes ok. Here is the relevant code section:
>>>
>>> 	// temp for driver debug
>>> 	dev_dbg(&client->dev,
>>> 			"get_output_config(before of_get_child_by_name)
>> OUT%d\n",
>>> 			clk_out->num + 1);
>>>
>>> 	np_output = of_get_child_by_name(client->dev.of_node,
>> child_name);
>>> 	kfree(child_name);
>>> 	if (!np_output)
>>> 		return 0;
>>>
>>> 	// temp for driver debug
>>> 	dev_dbg(&client->dev,
>>> 			"get_output_config(before update_mode)
>> OUT%d\n",
>>> 			clk_out->num + 1);
>>>
>>> 	ret = vc5_update_mode(np_output, clk_out);
>>> 	if (ret)
>>> 		goto output_error;
>>>
>>> And dmesg output:
>>>
>>> 	[    7.498005] vc5 1-006a: get_output_config(before
>> of_get_child_by_name)  OUT1
>>> 	[    7.498017] vc5 1-006a: get_output_config(before update_mode)
>> OUT1
>>> 	[    7.511631] vc5 1-006a: get_output_config(before
>> of_get_child_by_name)  OUT2
>>> 	[    7.511643] vc5 1-006a: get_output_config(before update_mode)
>> OUT2
>>> 	[    7.525257] vc5 1-006a: get_output_config(before
>> of_get_child_by_name)  OUT3
>>> 	[    7.525270] vc5 1-006a: get_output_config(before update_mode)
>> OUT3
>>> 	[    7.538905] vc5 1-006a: get_output_config(before
>> of_get_child_by_name)  OUT4
>>> 	[    7.538919] vc5 1-006a: get_output_config(before update_mode)
>> OUT4
>>
>> So the values are picked up from DT and if you print the content of clk_out-
>>> clk_output_cfg0[_mask] you should see the correct register values.
>>
>> Now the relevant question is question 3: do you enter the 'if (hwdata-
>>> clk_output_cfg0_mask)' in vc5_clk_out_prepare()? Do you even enter
>> vc5_clk_out_prepare()?
>>
>> You can add dev_dbg()s there and track the problem on your own. If
>> regmap_update_bits(...hwdata->clk_output_cfg0) is not called then the
>> code is not doing the right thing. If it is called and returns no error, then it
>> looks like there is a problem in the i2c controller which thinks it has done the
>> transaction but it really hasn't. Or some other mystery.
>>
>> --
>> Luca
> 
> I added a few debug statements and I see that vc5_clk_out_prepare() is not being called.

My bad, I was quite sure assigned-clocks also enables the clock. :-/
Apologies for having led you to a dead end.

> So perhaps this ties back to the point Adam made earlier about their needing to be a consumer driver that enables the reference clock because it is not enabled by default.  For my application there is no consumer driver, I only have the device tree.

Well, this is clearly the "correct" thing to do. However it's uncommon
that you have no consumer driver. What is the device that uses that
clock and why does it have no driver? Is it a device that "just works"
in the expected way without any configuration? Is it even avvessible by
the CPU?

You might consider writing a "dummy" driver, with just a simple probe()
function that does devm_clk_get and clk_prepare_enable(). You'll find
many examples in the kernel. is it doable?

> In my local copy of the driver that adds an 'idt,enable' pattern property I call vc5_clk_out_prepare() if idt,enable is set for an output.  There may be a cleaner way, but this seems to allow enabling of outputs from the device tree.
> 
> I did the following:
> 
>         // idt,enable mod: add struct clk_hw *hw  arg
>         static int vc5_get_output_config(struct i2c_client *client,
>                                       struct vc5_out_data *clk_out, struct clk_hw *hw)
>         {
>             ...
>             ret = vc5_update_slew(np_output, clk_out);
> 
>             // idt,enable mod: call to vc5_update_enable()
>             ret = vc5_update_enable(np_output, hw);
>             if (ret)
>                 goto output_error;
> 
> And:
> 
>         // begin idt,enable mod
>         static int vc5_update_enable(struct device_node *np_output,
>                                   struct clk_hw *hw)
>         {
>             u32 value;
> 
>             if (!of_property_read_u32(np_output, "idt,enable", &value)) {
>                 if (value) {
>                     vc5_clk_out_prepare(hw);
>                 } else {
>                     vc5_clk_out_unprepare(hw);
>                 }
>             }
>             return 0;
>         }
>         // end idt,enable mod

This is not the "expected" way to do it in the kernel, I would call it a
shortcut for not writing a consumer driver. However if it is enough for
you and you don't mind maintaining this modification in your own kernel
fork, it will do. Only, if were me, I would write a simple, dummy driver
for the consumer device to have things clean, learn something and, well,
have fun.

-- 
Luca

RE: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Fillion, Claude]

Hello Luca,

> -----Original Message-----
> From: Luca Ceresoli <luca@lucaceresoli.net>
> Sent: Wednesday, March 9, 2022 12:20 PM
> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> <aford173@gmail.com>
> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> versaclock5 driver
> 
> Hi Claude,
> 
> On 07/03/22 21:39, Fillion, Claude wrote:
> > Hello Luca
> >
> >> -----Original Message-----
> >> From: Luca Ceresoli <luca@lucaceresoli.net>
> >> Sent: Friday, March 4, 2022 3:30 PM
> >> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> >> <aford173@gmail.com>
> >> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> >> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
> >> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> >> versaclock5 driver
> >>
> >> Hi Claude,
> >>
> >> On 04/03/22 21:07, Fillion, Claude wrote:
> >>> Hello Luca,
> >>>
> >>>> -----Original Message-----
> >>>> From: Luca Ceresoli <luca@lucaceresoli.net>
> >>>> Sent: Thursday, March 3, 2022 5:34 PM
> >>>> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> >>>> <aford173@gmail.com>
> >>>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> >>>> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
> >>>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding
> >>>> idt/renesas
> >>>> versaclock5 driver
> >>>>
> >>>> Hi Claude,
> >>>>
> >>>> On 03/03/22 19:15, Fillion, Claude wrote:
> >>>>> Hello Luca,
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Luca Ceresoli <luca@lucaceresoli.net>
> >>>>>> Sent: Thursday, March 3, 2022 9:42 AM
> >>>>>> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> >>>>>> <aford173@gmail.com>
> >>>>>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> >>>>>> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
> >>>>>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding
> >>>>>> idt/renesas
> >>>>>> versaclock5 driver
> >>>>>>
> >>>>>> Hi Claude,
> >>>>>>
> >>>>>> On 02/03/22 21:49, Fillion, Claude wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Luca Ceresoli <luca@lucaceresoli.net>
> >>>>>>>> Sent: Wednesday, March 2, 2022 12:27 PM
> >>>>>>>> To: Adam Ford <aford173@gmail.com>; Fillion, Claude
> >>>>>>>> <Claude.Fillion@mksinst.com>
> >>>>>>>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> >>>>>>>> clk@vger.kernel.org>
> >>>>>>>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding
> >>>>>>>> idt/renesas
> >>>>>>>> versaclock5 driver
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> On 02/03/22 16:45, Adam Ford wrote:
> >>>>>>>> ...
> >>>>>>>>>>>>>>     versaclock6: clock-controller@6a {
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>         /* Clock Consumer */
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>         compatible = "idt,5p49v6965";
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>                                 reg = <0x6a>;
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>                                 #clock-cells = <1>;
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>                                 clocks = <&x304_clk>;
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>                                 clock-names = "xin";
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>         assigned_clocks = <&versaclock6 1>,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>                           <&versaclock6 2>,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>                           <&versaclock6 3>,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>                           <&versaclock6 4>;
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>         assigned_clock_rates = <46800000>, <250000000>,
> >>>>>>>>>>>>>> <1000000>, <13000000>;
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Assigned clocks and assigned clock rates should be hyphens
> >>>>>>>>>>>>> and not underscores.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> assigned-clocks =  <&versaclock6 1>,   <&versaclock6 2>,
> >>>>>>>>>>>>> <&versaclock6 3>, <&versaclock6 4>;
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> assigned-clock-rates =  <46800000>, <250000000>,
> >>>>>>>>>>>>> <1000000>, <13000000>;
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Another thing to check is to make sure the consumers of
> >>>>>>>>>>>>> these clocks is enabling them.  They do not necessarily
> >>>>>>>>>>>>> get enabled by
> >>>>>>>> default.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> adam
> >>>>>>>>>>>>
> >>>>>>>>>>>> Doh - thanks.  I looked at it a million times 😊 .
> >>>>>>>>>>>>
> >>>>>>>>>>>> Now getting desired out1 frequency but nothing on other
> >>>> outputs.
> >>>>>>>>>>>> From
> >>>>>>>>>>> the code it seems vc5_clk_out_prepare() is the method that
> >>>>>>>>>>> enables outputs but this method is not being called I am not
> >>>>>>>>>>> clear how to make the 'consumer enable them.'
> >>>>>>>>>>>>
> >>>>>>>>>>>> I have added this to my dtsi to no avail.
> >>>>>>>>>>>>
> >>>>>>>>>>>>          /* Consumer referencing 5P49V5965 pin OUT1 and
> >>>>>>>>>>>> OUT2
> >> */
> >>>>>>>>>>>>         consumer {
> >>>>>>>>>>>>             clocks = <&versaclock6 1>, <&versaclock6 2>;
> >>>>>>>>>>>>             /* ... */
> >>>>>>>>>>>>          };
> >>>>>>>>>>>>
> >>>>>>>>>>>> Looking through device tree documentation.
> >>>>>>>>>>>
> >>>>>>>>>>> It's likely going to be in the consumer's driver.  Check the
> >>>>>>>>>>> consumer device tree binding to make sure you've correctly
> >>>>>>>>>>> associated the clock.  If the binding doesnt't show a clock
> >>>>>>>>>>> is required, it might not know that you using a programmable
> >> clock.
> >>>>>>>>>>>
> >>>>>>>>>>> Here is a patch that I needed to apply to an Ethernet driver
> >>>>>>>>>>> which wasn't expecting a programmable clock to drive a
> >>>>>>>>>>> reference clock, so the clock wasn't being enabled.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux
> >>>>>>>>>>> /k
> >>>>>>>>>>> er
> >>>>>>>>>>> nel/g
> >>>>>>>>>>>
> >>>>>>
> it/torvalds/linux.git/commit/drivers/net/ethernet/renesas/ravb_main.
> >>>>>>>>>>> c?id=
> >>>>>>>>>>> 8ef7adc6beb2ef0bce83513dc9e4505e7b21e8c2__;!!KnJ4-
> >>>> rp7!1Qb17q-
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> TWrV62AeQtTNNVDErVbyhbXB1sukyT2ggvFPUltIBI5nIKzNnjVOcqlw8qJyy$
> >>>>>>>>>>>
> >>>>>>>>>>> Look at the use of devm_clk_get_optional and
> >>>>>>>>>>> clk_prepare_enable from that patch.  (yes, there is a
> >>>>>>>>>>> subsequent patch that fixes something I didn't quite do
> >>>>>>>>>>> right, but the basics are here)
> >>>>>>>>>>>
> >>>>>>>>>>> The consumer drivers need to 'get' the clock so it can
> >>>>>>>>>>> associate itself to the clock in question.  Once the
> >>>>>>>>>>> relationship is established, the consumer needs to call
> >>>>>>>>>>> clk_prepare_enable() which
> >>>>>>>> uses the clock system to turn the clock on.
> >>>>>>>>>>> Without this step, it's likely the Versaclock won't generate
> >>>>>>>>>>> a signal, because it doesn't know it needs to turn it on.
> >>>>>>>>>>>
> >>>>>>>>>>> adam
> >>>>>>>>>>
> >>>>>>>>>> Not sure I fully follow.  I see that clk out1 is enabled but
> >>>>>>>>>> the other
> >>>>>>>> channels are not so it would seem my difficulty is with
> >>>>>>>> individual
> >>>> channels.
> >>>>>>>>>
> >>>>>>>>> Do the devices that need the clock from the versaclock
> >>>>>>>>> reference the versaclock?  If so, to those drivers use the get and
> enable?
> >>>>>>>>> If not, the versaclock will stay off.  In the patch example I
> >>>>>>>>> showed, I had to modify the Ethernet driver on a processor,
> >>>>>>>>> because it didn't explicitly enable the reference clock.  That
> >>>>>>>>> Ethernet driver expected the refclk was always present which
> >>>>>>>>> was a
> >>>> false assumption.
> >>>>>>>>> Once I got the consumer device (in this case, Ethernet) to
> >>>>>>>>> request and enable the clock, the clock subsystem enabled the
> >>>>>>>>> corresponding output on the versaclock.
> >>>>>>>>>
> >>>>>>>>> For the Ethernet example I cited above, the corresponding
> >>>>>>>>> device tree looks like:
> >>>>>>>>>
> >>>>>>>>> &avb {
> >>>>>>>>>      clocks = <&cpg CPG_MOD 812>, <&versaclock5 4>;
> >>>>>>>>>      clock-names = "fck", "refclk";
> >>>>>>>>>      status = "okay";
> >>>>>>>>> };
> >>>>>>>>>
> >>>>>>>>> With this device tree reference, the 'refclk' gets associated
> >>>>>>>>> to versaclock ouput 4.  When the Ethernet needs the clock, it
> >>>>>>>>> calls clk_prepare_enable on that clock reference, and the
> >>>>>>>>> clock system calls on the versaclock driver to enable the
> >>>>>>>>> output.  The reason I needed to submit that patch was that the
> >>>>>>>>> consumer driver (the Ethernet in this
> >>>>>>>>> case) wasn't calling the clk_prepare_enable, so the clock
> >>>>>>>>> remained off.  It's likely that whatever devices that need the
> >>>>>>>>> clock from the versaclock will need both a device tree
> >>>>>>>>> reference to it as well as a call to clk_prepare_enable.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> In my simple application I would like to enable outputs, on a
> >>>>>>>>>> per channel
> >>>>>>>> basis, from the device tree.  Would it make sense  to add  an
> >>>> 'idt,enable'
> >>>>>>>> property in similar fashion to the existing idt,mode,
> >>>>>>>> idt,voltage-microvolt, and idt,slew-percent properties?  Then
> >>>>>>>> vc5_get_output_config() could be modified to also call
> >>>>>>>> vc5_clk_out_prepare() (or clk_prepare_enable(), which in turn
> >>>>>>>> would call
> >>>>>> vc5_clk_out_prepare()).
> >>>>>>>>>
> >>>>>>>>> I can't speak for the linux clock group, but the advantage of
> >>>>>>>>> patching the drivers that need the clocks generated from the
> >>>>>>>>> versaclock is the ability to stop these clocks when the
> >>>>>>>>> drivers are halted and/or suspended.
> >>>>>>>>
> >>>>>>>> Having the consumer driver get, prepare and enable the clock is
> >>>>>>>> of course the best as Adam explained.
> >>>>>>>>
> >>>>>>>> However I think using assigned-clocks and assigned-clock-rates
> >>>>>>>> should enable the clocks unconditionally even if the consumer
> >>>>>>>> driver does not do any clk_*() calls. Might be worth double
> >>>>>>>> checking
> >>>> that.
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Luca
> >>>>>>>
> >>>>>>> In our application we plan to use the 6965/6901 to replace a
> >>>>>>> part that does
> >>>>>> not use a consumer driver.  We just set clock options in our device
> tree.
> >>>>>> Ideally that is how we would like to use the Renesas part as well.
> >>>>>>>
> >>>>>>> In the limited testing I have done thus far behavior is a bit
> >>>>>>> puzzling.  From
> >>>>>> the device tree I am able to change the clock frequency for out1
> >>>>>> (which is enabled by default) and I can disable outputs using
> >>>>>> 'idt,shutdown', but I cannot change the logic levels for out1
> >>>>>> using the
> >>>> 'idt,mode' parameter.
> >>>>>>
> >>>>>> This is very strange.
> >>>>>>
> >>>>>> Did you double-check that your device tree description of the
> >>>>>> versaclock node is correct according to [0]?
> >>>>>>
> >>>>>> Please send the complete  description of the versaclock node in
> >>>>>> your device tree, so we can check it and see if any detail is
> misplaced.
> >>>>>>
> >>>>>> [0]
> >>>>>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/
> >>>>>> ke
> >>>>>> rn
> >>>>>> el/g
> >>>>>> it/torvalds/linux.git/tree/Documentation/devicetree/bindings/cloc
> >>>>>> k/
> >>>>>> id
> >>>>>> t,vers
> >>>>>> aclock5.yaml*n169__;Iw!!KnJ4-
> >>>>>> rp7!yalfgsfaZKSlo4yNfQfvlbsmNKBRltGSetoIonP--5aGebuHUJ-M-
> >>>>>> am93tjT8aEhsSJJ$
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Luca
> >>>>>
> >>>>> Here is the relevant portions of my device tree.  On the scope I
> >>>>> see the
> >>>> default 'CMOSD' voltages and a modified frequency of 46.8MHz.
> >>>>>
> >>>>> I have also modified my local copy of the driver to accept an
> 'idt,enable'
> >>>> pattern property that allows me to enable outputs from the device
> >>>> tree. It needs some refinement but I can pass it along if there is
> interest.
> >>>>>
> >>>>> -Claude
> >>>>>
> >>>>> ==================
> >>>>> Top of device tree file:
> >>>>> ==================
> >>>>> /*
> >>>>> This is a message for system-user.dtsi. If you are reading from
> >>>>> system-user.dtsi.genxxxx, please note that this message is for
> >>>>> explaining
> >>>> the purpose of system-user.dist in relation to system-user.dtsi.genxxx.
> >>>>>
> >>>>> system-user.dtsi is merely a writable file handled by
> >>>>> ./https://urldefense.com/v3/__http://buildPetaLinux.sh__;!!KnJ4-
> >>>> rp7!w34odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
> >>>> J3Uswvovc00BUt$  to copy the appropriate system-user.dtsi.genxxxx
> >>>> to this filename for use in the build image. Do not put your device
> >>>> tree here. They belong to the system-user.dtsi.genxxxx.
> >>>>>
> >>>>> If you add a new dtsi, please create an appropriate device tree
> >>>>> file and modify the
> >>>>> ./https://urldefense.com/v3/__http://buildPetaLinux.sh__;!!KnJ4-
> rp7!
> >>>>> w3
> >>>>> 4odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
> >>>> J3Uswvovc00BUt$
> >>>>> to handle it */
> >>>>>
> >>>>> #include <dt-bindings/clk/versaclock.h>
> >>>>>
> >>>>> /include/ "system-conf.dtsi"
> >>>>> / {
> >>>>>
> >>>>>   /* Clock Provider */
> >>>>>   x304_clk: x304-clock {
> >>>>>     compatible = "fixed-clock";
> >>>>>     #clock-cells = <0>;
> >>>>>     clock-frequency = <25000000>;
> >>>>>   };
> >>>>>
> >>>>> ...
> >>>>>
> >>>>> ==================
> >>>>> Device Tree Node:
> >>>>> ==================
> >>>>> &i2c1 {
> >>>>>     clock-frequency = <100000>;
> >>>>>
> >>>>>     // Use patch.  Updated driver for 5p49v6965 available  at
> >>>> https://urldefense.com/v3/__https://github.com/Xilinx/linux-
> >>>> xlnx/blob/master/drivers/clk/clk-versaclock5.c__;!!KnJ4-
> >>>> rp7!w34odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
> >>>> J3UswvoiTIHWiN$
> >>>>>     // Device Tree Setup ->
> >>>> https://urldefense.com/v3/__https://github.com/Xilinx/linux-
> >>>>
> >>
> xlnx/blob/master/Documentation/devicetree/bindings/clock/idt*2Cversac
> >>>> lo
> >>>> ck5.yaml__;JQ!!KnJ4-rp7!w34odUyH6hHBct-rWC671nddpz5440f-
> >>>> viaETLtFnGYMlkuB7P0ye-J3Uswvor3hNb3f$
> >>>>>     versaclock6: clock-controller@6a {
> >>>>>         /* Clock Consumer */
> >>>>>         compatible = "idt,5p49v6965";
> >>>>> 		reg = <0x6a>;
> >>>>> 		#clock-cells = <1>;
> >>>>> 		clocks = <&x304_clk>;
> >>>>> 		clock-names = "xin";
> >>>>>
> >>>>>         assigned-clocks = <&versaclock6 1>,
> >>>>>                           <&versaclock6 2>,
> >>>>>                           <&versaclock6 3>,
> >>>>>                           <&versaclock6 4>;
> >>>>>         // assigned-clock-rates = <46800000>, <250000000>,
> >>>>> <1000000>,
> >>>> <13000000>;
> >>>>>         assigned-clock-rates = <46800000>, <250000000>, <1000000>,
> >>>> <13000000>;
> >>>>>         /* Set the SD/OE pin's settings */
> >>>>>         idt,shutdown = <0>;
> >>>>>         idt,output-enable-active = <0>;
> >>>>>         OUT1 {
> >>>>>             idt,mode = <VC5_CMOS>;
> >>>>>             idt,voltage-microvolt = <3300000>;
> >>>>>             c = <100>;
> >>>>>         };
> >>>>>         OUT2 {
> >>>>>             idt,mode = <VC5_CMOS>;
> >>>>>             idt,voltage-microvolt = <3300000>;
> >>>>>             idt,slew-percent = <100>;
> >>>>>         };
> >>>>>         OUT3 {
> >>>>>             idt,mode = <VC5_CMOSD>;
> >>>>>             idt,voltage-microvolt = <3300000>;
> >>>>>             idt,slew-percent = <100>;
> >>>>>         };
> >>>>>         OUT4 {
> >>>>>             idt,mode = <VC5_CMOS>;
> >>>>>             idt,voltage-microvolt = <3300000>;
> >>>>>             idt,slew-percent = <100>;
> >>>>>         };
> >>>>>     };
> >>>>
> >>>> Strange. Something you may check (or double check if you already did):
> >>>>
> >>>> 1. Read if the register has been set:
> >>>>
> >>>>   # not tested, check carefully
> >>>>   i2cget -y -r 1 0x6a 0x60
> >>>>
> >>>> the three low bits in register 0x60 should read 0x1 for CMOS, 0x5
> >>>> for
> >> CMOSD.
> >>>
> >>> Apparently the register is not getting set properly.
> >>>
> >>> In response to 'i2cget -y -f 1 0x6a 0x60' (-r not supported maybe a
> >>> typo?)
> >>>
> >>> I get 0xbb, which according to the spec I believe should give me
> >>> CMOSD,
> >> which is what I am seeing ( (D7, D6, D5) = 101: CMOSD ).
> >>>
> >>> I can set address 0x60 to 0x3b using i2cset to get single ended CMOS.
> >>
> >> I see. 0xbb is the reset default, so as you said it is not set.
> >>
> >>>> 2. Change idt,mode in device tree and see whether the register
> >>>> changes or the scope show any different output mode.
> >>>
> >>> Changing ide,mode to VC5_LVDS does not the value of register 0x06.
> >>> I still get a value of 0xbb
> >>
> >> Ok, coherent with test 1.
> >>
> >>>> 3. Enable debugging output (simpliy add #define DEBUG on top of
> >>>> file and rebuild), then see whether during clk prepare you see this in
> dmesg:
> >>>>
> >>>>   Update output ... mask 0x... val 0x....
> >>>>
> >>>> 4. Check whether the OUT1 node is actually found by adding a
> >>>> dev_dbg() in vc5_get_output_config(), just before the
> >>>> of_get_child_by_name() call and
> >>>> ~5 lines below, between 'return 0' and vc5_update_mode().
> >>>>
> >>>> Let us know your findings.
> >>>>
> >>>
> >>> Seems to be finding the nodes ok. Here is the relevant code section:
> >>>
> >>> 	// temp for driver debug
> >>> 	dev_dbg(&client->dev,
> >>> 			"get_output_config(before of_get_child_by_name)
> >> OUT%d\n",
> >>> 			clk_out->num + 1);
> >>>
> >>> 	np_output = of_get_child_by_name(client->dev.of_node,
> >> child_name);
> >>> 	kfree(child_name);
> >>> 	if (!np_output)
> >>> 		return 0;
> >>>
> >>> 	// temp for driver debug
> >>> 	dev_dbg(&client->dev,
> >>> 			"get_output_config(before update_mode)
> >> OUT%d\n",
> >>> 			clk_out->num + 1);
> >>>
> >>> 	ret = vc5_update_mode(np_output, clk_out);
> >>> 	if (ret)
> >>> 		goto output_error;
> >>>
> >>> And dmesg output:
> >>>
> >>> 	[    7.498005] vc5 1-006a: get_output_config(before
> >> of_get_child_by_name)  OUT1
> >>> 	[    7.498017] vc5 1-006a: get_output_config(before update_mode)
> >> OUT1
> >>> 	[    7.511631] vc5 1-006a: get_output_config(before
> >> of_get_child_by_name)  OUT2
> >>> 	[    7.511643] vc5 1-006a: get_output_config(before update_mode)
> >> OUT2
> >>> 	[    7.525257] vc5 1-006a: get_output_config(before
> >> of_get_child_by_name)  OUT3
> >>> 	[    7.525270] vc5 1-006a: get_output_config(before update_mode)
> >> OUT3
> >>> 	[    7.538905] vc5 1-006a: get_output_config(before
> >> of_get_child_by_name)  OUT4
> >>> 	[    7.538919] vc5 1-006a: get_output_config(before update_mode)
> >> OUT4
> >>
> >> So the values are picked up from DT and if you print the content of
> >> clk_out-
> >>> clk_output_cfg0[_mask] you should see the correct register values.
> >>
> >> Now the relevant question is question 3: do you enter the 'if
> >> (hwdata-
> >>> clk_output_cfg0_mask)' in vc5_clk_out_prepare()? Do you even enter
> >> vc5_clk_out_prepare()?
> >>
> >> You can add dev_dbg()s there and track the problem on your own. If
> >> regmap_update_bits(...hwdata->clk_output_cfg0) is not called then the
> >> code is not doing the right thing. If it is called and returns no
> >> error, then it looks like there is a problem in the i2c controller
> >> which thinks it has done the transaction but it really hasn't. Or some other
> mystery.
> >>
> >> --
> >> Luca
> >
> > I added a few debug statements and I see that vc5_clk_out_prepare() is
> not being called.
> 
> My bad, I was quite sure assigned-clocks also enables the clock. :-/ Apologies
> for having led you to a dead end.

No problem.  You have been a tremendous help!

> 
> > So perhaps this ties back to the point Adam made earlier about their
> needing to be a consumer driver that enables the reference clock because it
> is not enabled by default.  For my application there is no consumer driver, I
> only have the device tree.
> 
> Well, this is clearly the "correct" thing to do. However it's uncommon that
> you have no consumer driver. What is the device that uses that clock and
> why does it have no driver? Is it a device that "just works"
> in the expected way without any configuration? Is it even avvessible by the
> CPU?
> 
> You might consider writing a "dummy" driver, with just a simple probe()
> function that does devm_clk_get and clk_prepare_enable(). You'll find many
> examples in the kernel. is it doable?
> 
> > In my local copy of the driver that adds an 'idt,enable' pattern property I call
> vc5_clk_out_prepare() if idt,enable is set for an output.  There may be a
> cleaner way, but this seems to allow enabling of outputs from the device
> tree.
> >
> > I did the following:
> >
> >         // idt,enable mod: add struct clk_hw *hw  arg
> >         static int vc5_get_output_config(struct i2c_client *client,
> >                                       struct vc5_out_data *clk_out, struct clk_hw *hw)
> >         {
> >             ...
> >             ret = vc5_update_slew(np_output, clk_out);
> >
> >             // idt,enable mod: call to vc5_update_enable()
> >             ret = vc5_update_enable(np_output, hw);
> >             if (ret)
> >                 goto output_error;
> >
> > And:
> >
> >         // begin idt,enable mod
> >         static int vc5_update_enable(struct device_node *np_output,
> >                                   struct clk_hw *hw)
> >         {
> >             u32 value;
> >
> >             if (!of_property_read_u32(np_output, "idt,enable", &value)) {
> >                 if (value) {
> >                     vc5_clk_out_prepare(hw);
> >                 } else {
> >                     vc5_clk_out_unprepare(hw);
> >                 }
> >             }
> >             return 0;
> >         }
> >         // end idt,enable mod
> 
> This is not the "expected" way to do it in the kernel, I would call it a shortcut
> for not writing a consumer driver. However if it is enough for you and you
> don't mind maintaining this modification in your own kernel fork, it will do.
> Only, if were me, I would write a simple, dummy driver for the consumer
> device to have things clean, learn something and, well, have fun.
> 
> --
> Luca

In our application the requirement only that we set the clock frequencies at boot time so device tree is sufficient.  That being said, I hope to work on a simple consumer driver next.  Thought is to allow user to make changes via config file or something similar.  As you say should be fun!

Thanks again for all the help you and others have provided.

-Claude

======================================================================
This message and any attachments are intended only for the designated recipient(s) and may contain confidential or proprietary information and be subject to the attorney-client privilege or other confidentiality protections.  If you are not a designated recipient, you may not review, use, copy or distribute this message or any attachments.  If you received this email in error, please notify the sender by reply e-mail and permanently delete the original and any copies of this message and any attachments thereto.  Thank you.

Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Adam Ford]

On Wed, Mar 9, 2022 at 12:02 PM Fillion, Claude
<Claude.Fillion@mksinst.com> wrote:
>
> Hello Luca,
>
> > -----Original Message-----
> > From: Luca Ceresoli <luca@lucaceresoli.net>
> > Sent: Wednesday, March 9, 2022 12:20 PM
> > To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> > <aford173@gmail.com>
> > Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> > clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
> > Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> > versaclock5 driver
> >
> > Hi Claude,
> >
> > On 07/03/22 21:39, Fillion, Claude wrote:
> > > Hello Luca
> > >
> > >> -----Original Message-----
> > >> From: Luca Ceresoli <luca@lucaceresoli.net>
> > >> Sent: Friday, March 4, 2022 3:30 PM
> > >> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> > >> <aford173@gmail.com>
> > >> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> > >> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
> > >> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> > >> versaclock5 driver
> > >>
> > >> Hi Claude,
> > >>
> > >> On 04/03/22 21:07, Fillion, Claude wrote:
> > >>> Hello Luca,
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Luca Ceresoli <luca@lucaceresoli.net>
> > >>>> Sent: Thursday, March 3, 2022 5:34 PM
> > >>>> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> > >>>> <aford173@gmail.com>
> > >>>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> > >>>> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
> > >>>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding
> > >>>> idt/renesas
> > >>>> versaclock5 driver
> > >>>>
> > >>>> Hi Claude,
> > >>>>
> > >>>> On 03/03/22 19:15, Fillion, Claude wrote:
> > >>>>> Hello Luca,
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Luca Ceresoli <luca@lucaceresoli.net>
> > >>>>>> Sent: Thursday, March 3, 2022 9:42 AM
> > >>>>>> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> > >>>>>> <aford173@gmail.com>
> > >>>>>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> > >>>>>> clk@vger.kernel.org>; Klein, Jesse <Jesse.Klein@mksinst.com>
> > >>>>>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding
> > >>>>>> idt/renesas
> > >>>>>> versaclock5 driver
> > >>>>>>
> > >>>>>> Hi Claude,
> > >>>>>>
> > >>>>>> On 02/03/22 21:49, Fillion, Claude wrote:
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>> -----Original Message-----
> > >>>>>>>> From: Luca Ceresoli <luca@lucaceresoli.net>
> > >>>>>>>> Sent: Wednesday, March 2, 2022 12:27 PM
> > >>>>>>>> To: Adam Ford <aford173@gmail.com>; Fillion, Claude
> > >>>>>>>> <Claude.Fillion@mksinst.com>
> > >>>>>>>> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> > >>>>>>>> clk@vger.kernel.org>
> > >>>>>>>> Subject: Re: [EXTERNAL] Re: Questions regarding regarding
> > >>>>>>>> idt/renesas
> > >>>>>>>> versaclock5 driver
> > >>>>>>>>
> > >>>>>>>> Hi,
> > >>>>>>>>
> > >>>>>>>> On 02/03/22 16:45, Adam Ford wrote:
> > >>>>>>>> ...
> > >>>>>>>>>>>>>>     versaclock6: clock-controller@6a {
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>         /* Clock Consumer */
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>         compatible = "idt,5p49v6965";
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>                                 reg = <0x6a>;
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>                                 #clock-cells = <1>;
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>                                 clocks = <&x304_clk>;
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>                                 clock-names = "xin";
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>         assigned_clocks = <&versaclock6 1>,
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>                           <&versaclock6 2>,
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>                           <&versaclock6 3>,
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>                           <&versaclock6 4>;
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>         assigned_clock_rates = <46800000>, <250000000>,
> > >>>>>>>>>>>>>> <1000000>, <13000000>;
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Assigned clocks and assigned clock rates should be hyphens
> > >>>>>>>>>>>>> and not underscores.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> assigned-clocks =  <&versaclock6 1>,   <&versaclock6 2>,
> > >>>>>>>>>>>>> <&versaclock6 3>, <&versaclock6 4>;
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> assigned-clock-rates =  <46800000>, <250000000>,
> > >>>>>>>>>>>>> <1000000>, <13000000>;
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Another thing to check is to make sure the consumers of
> > >>>>>>>>>>>>> these clocks is enabling them.  They do not necessarily
> > >>>>>>>>>>>>> get enabled by
> > >>>>>>>> default.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> adam
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Doh - thanks.  I looked at it a million times 😊 .
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Now getting desired out1 frequency but nothing on other
> > >>>> outputs.
> > >>>>>>>>>>>> From
> > >>>>>>>>>>> the code it seems vc5_clk_out_prepare() is the method that
> > >>>>>>>>>>> enables outputs but this method is not being called I am not
> > >>>>>>>>>>> clear how to make the 'consumer enable them.'
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I have added this to my dtsi to no avail.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>          /* Consumer referencing 5P49V5965 pin OUT1 and
> > >>>>>>>>>>>> OUT2
> > >> */
> > >>>>>>>>>>>>         consumer {
> > >>>>>>>>>>>>             clocks = <&versaclock6 1>, <&versaclock6 2>;
> > >>>>>>>>>>>>             /* ... */
> > >>>>>>>>>>>>          };
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Looking through device tree documentation.
> > >>>>>>>>>>>
> > >>>>>>>>>>> It's likely going to be in the consumer's driver.  Check the
> > >>>>>>>>>>> consumer device tree binding to make sure you've correctly
> > >>>>>>>>>>> associated the clock.  If the binding doesnt't show a clock
> > >>>>>>>>>>> is required, it might not know that you using a programmable
> > >> clock.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Here is a patch that I needed to apply to an Ethernet driver
> > >>>>>>>>>>> which wasn't expecting a programmable clock to drive a
> > >>>>>>>>>>> reference clock, so the clock wasn't being enabled.
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux
> > >>>>>>>>>>> /k
> > >>>>>>>>>>> er
> > >>>>>>>>>>> nel/g
> > >>>>>>>>>>>
> > >>>>>>
> > it/torvalds/linux.git/commit/drivers/net/ethernet/renesas/ravb_main.
> > >>>>>>>>>>> c?id=
> > >>>>>>>>>>> 8ef7adc6beb2ef0bce83513dc9e4505e7b21e8c2__;!!KnJ4-
> > >>>> rp7!1Qb17q-
> > >>>>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>
> > >>
> > TWrV62AeQtTNNVDErVbyhbXB1sukyT2ggvFPUltIBI5nIKzNnjVOcqlw8qJyy$
> > >>>>>>>>>>>
> > >>>>>>>>>>> Look at the use of devm_clk_get_optional and
> > >>>>>>>>>>> clk_prepare_enable from that patch.  (yes, there is a
> > >>>>>>>>>>> subsequent patch that fixes something I didn't quite do
> > >>>>>>>>>>> right, but the basics are here)
> > >>>>>>>>>>>
> > >>>>>>>>>>> The consumer drivers need to 'get' the clock so it can
> > >>>>>>>>>>> associate itself to the clock in question.  Once the
> > >>>>>>>>>>> relationship is established, the consumer needs to call
> > >>>>>>>>>>> clk_prepare_enable() which
> > >>>>>>>> uses the clock system to turn the clock on.
> > >>>>>>>>>>> Without this step, it's likely the Versaclock won't generate
> > >>>>>>>>>>> a signal, because it doesn't know it needs to turn it on.
> > >>>>>>>>>>>
> > >>>>>>>>>>> adam
> > >>>>>>>>>>
> > >>>>>>>>>> Not sure I fully follow.  I see that clk out1 is enabled but
> > >>>>>>>>>> the other
> > >>>>>>>> channels are not so it would seem my difficulty is with
> > >>>>>>>> individual
> > >>>> channels.
> > >>>>>>>>>
> > >>>>>>>>> Do the devices that need the clock from the versaclock
> > >>>>>>>>> reference the versaclock?  If so, to those drivers use the get and
> > enable?
> > >>>>>>>>> If not, the versaclock will stay off.  In the patch example I
> > >>>>>>>>> showed, I had to modify the Ethernet driver on a processor,
> > >>>>>>>>> because it didn't explicitly enable the reference clock.  That
> > >>>>>>>>> Ethernet driver expected the refclk was always present which
> > >>>>>>>>> was a
> > >>>> false assumption.
> > >>>>>>>>> Once I got the consumer device (in this case, Ethernet) to
> > >>>>>>>>> request and enable the clock, the clock subsystem enabled the
> > >>>>>>>>> corresponding output on the versaclock.
> > >>>>>>>>>
> > >>>>>>>>> For the Ethernet example I cited above, the corresponding
> > >>>>>>>>> device tree looks like:
> > >>>>>>>>>
> > >>>>>>>>> &avb {
> > >>>>>>>>>      clocks = <&cpg CPG_MOD 812>, <&versaclock5 4>;
> > >>>>>>>>>      clock-names = "fck", "refclk";
> > >>>>>>>>>      status = "okay";
> > >>>>>>>>> };
> > >>>>>>>>>
> > >>>>>>>>> With this device tree reference, the 'refclk' gets associated
> > >>>>>>>>> to versaclock ouput 4.  When the Ethernet needs the clock, it
> > >>>>>>>>> calls clk_prepare_enable on that clock reference, and the
> > >>>>>>>>> clock system calls on the versaclock driver to enable the
> > >>>>>>>>> output.  The reason I needed to submit that patch was that the
> > >>>>>>>>> consumer driver (the Ethernet in this
> > >>>>>>>>> case) wasn't calling the clk_prepare_enable, so the clock
> > >>>>>>>>> remained off.  It's likely that whatever devices that need the
> > >>>>>>>>> clock from the versaclock will need both a device tree
> > >>>>>>>>> reference to it as well as a call to clk_prepare_enable.
> > >>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> In my simple application I would like to enable outputs, on a
> > >>>>>>>>>> per channel
> > >>>>>>>> basis, from the device tree.  Would it make sense  to add  an
> > >>>> 'idt,enable'
> > >>>>>>>> property in similar fashion to the existing idt,mode,
> > >>>>>>>> idt,voltage-microvolt, and idt,slew-percent properties?  Then
> > >>>>>>>> vc5_get_output_config() could be modified to also call
> > >>>>>>>> vc5_clk_out_prepare() (or clk_prepare_enable(), which in turn
> > >>>>>>>> would call
> > >>>>>> vc5_clk_out_prepare()).
> > >>>>>>>>>
> > >>>>>>>>> I can't speak for the linux clock group, but the advantage of
> > >>>>>>>>> patching the drivers that need the clocks generated from the
> > >>>>>>>>> versaclock is the ability to stop these clocks when the
> > >>>>>>>>> drivers are halted and/or suspended.
> > >>>>>>>>
> > >>>>>>>> Having the consumer driver get, prepare and enable the clock is
> > >>>>>>>> of course the best as Adam explained.
> > >>>>>>>>
> > >>>>>>>> However I think using assigned-clocks and assigned-clock-rates
> > >>>>>>>> should enable the clocks unconditionally even if the consumer
> > >>>>>>>> driver does not do any clk_*() calls. Might be worth double
> > >>>>>>>> checking
> > >>>> that.
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>> Luca
> > >>>>>>>
> > >>>>>>> In our application we plan to use the 6965/6901 to replace a
> > >>>>>>> part that does
> > >>>>>> not use a consumer driver.  We just set clock options in our device
> > tree.
> > >>>>>> Ideally that is how we would like to use the Renesas part as well.
> > >>>>>>>
> > >>>>>>> In the limited testing I have done thus far behavior is a bit
> > >>>>>>> puzzling.  From
> > >>>>>> the device tree I am able to change the clock frequency for out1
> > >>>>>> (which is enabled by default) and I can disable outputs using
> > >>>>>> 'idt,shutdown', but I cannot change the logic levels for out1
> > >>>>>> using the
> > >>>> 'idt,mode' parameter.
> > >>>>>>
> > >>>>>> This is very strange.
> > >>>>>>
> > >>>>>> Did you double-check that your device tree description of the
> > >>>>>> versaclock node is correct according to [0]?
> > >>>>>>
> > >>>>>> Please send the complete  description of the versaclock node in
> > >>>>>> your device tree, so we can check it and see if any detail is
> > misplaced.
> > >>>>>>
> > >>>>>> [0]
> > >>>>>> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/
> > >>>>>> ke
> > >>>>>> rn
> > >>>>>> el/g
> > >>>>>> it/torvalds/linux.git/tree/Documentation/devicetree/bindings/cloc
> > >>>>>> k/
> > >>>>>> id
> > >>>>>> t,vers
> > >>>>>> aclock5.yaml*n169__;Iw!!KnJ4-
> > >>>>>> rp7!yalfgsfaZKSlo4yNfQfvlbsmNKBRltGSetoIonP--5aGebuHUJ-M-
> > >>>>>> am93tjT8aEhsSJJ$
> > >>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Luca
> > >>>>>
> > >>>>> Here is the relevant portions of my device tree.  On the scope I
> > >>>>> see the
> > >>>> default 'CMOSD' voltages and a modified frequency of 46.8MHz.
> > >>>>>
> > >>>>> I have also modified my local copy of the driver to accept an
> > 'idt,enable'
> > >>>> pattern property that allows me to enable outputs from the device
> > >>>> tree. It needs some refinement but I can pass it along if there is
> > interest.
> > >>>>>
> > >>>>> -Claude
> > >>>>>
> > >>>>> ==================
> > >>>>> Top of device tree file:
> > >>>>> ==================
> > >>>>> /*
> > >>>>> This is a message for system-user.dtsi. If you are reading from
> > >>>>> system-user.dtsi.genxxxx, please note that this message is for
> > >>>>> explaining
> > >>>> the purpose of system-user.dist in relation to system-user.dtsi.genxxx.
> > >>>>>
> > >>>>> system-user.dtsi is merely a writable file handled by
> > >>>>> ./https://urldefense.com/v3/__http://buildPetaLinux.sh__;!!KnJ4-
> > >>>> rp7!w34odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
> > >>>> J3Uswvovc00BUt$  to copy the appropriate system-user.dtsi.genxxxx
> > >>>> to this filename for use in the build image. Do not put your device
> > >>>> tree here. They belong to the system-user.dtsi.genxxxx.
> > >>>>>
> > >>>>> If you add a new dtsi, please create an appropriate device tree
> > >>>>> file and modify the
> > >>>>> ./https://urldefense.com/v3/__http://buildPetaLinux.sh__;!!KnJ4-
> > rp7!
> > >>>>> w3
> > >>>>> 4odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
> > >>>> J3Uswvovc00BUt$
> > >>>>> to handle it */
> > >>>>>
> > >>>>> #include <dt-bindings/clk/versaclock.h>
> > >>>>>
> > >>>>> /include/ "system-conf.dtsi"
> > >>>>> / {
> > >>>>>
> > >>>>>   /* Clock Provider */
> > >>>>>   x304_clk: x304-clock {
> > >>>>>     compatible = "fixed-clock";
> > >>>>>     #clock-cells = <0>;
> > >>>>>     clock-frequency = <25000000>;
> > >>>>>   };
> > >>>>>
> > >>>>> ...
> > >>>>>
> > >>>>> ==================
> > >>>>> Device Tree Node:
> > >>>>> ==================
> > >>>>> &i2c1 {
> > >>>>>     clock-frequency = <100000>;
> > >>>>>
> > >>>>>     // Use patch.  Updated driver for 5p49v6965 available  at
> > >>>> https://urldefense.com/v3/__https://github.com/Xilinx/linux-
> > >>>> xlnx/blob/master/drivers/clk/clk-versaclock5.c__;!!KnJ4-
> > >>>> rp7!w34odUyH6hHBct-rWC671nddpz5440f-viaETLtFnGYMlkuB7P0ye-
> > >>>> J3UswvoiTIHWiN$
> > >>>>>     // Device Tree Setup ->
> > >>>> https://urldefense.com/v3/__https://github.com/Xilinx/linux-
> > >>>>
> > >>
> > xlnx/blob/master/Documentation/devicetree/bindings/clock/idt*2Cversac
> > >>>> lo
> > >>>> ck5.yaml__;JQ!!KnJ4-rp7!w34odUyH6hHBct-rWC671nddpz5440f-
> > >>>> viaETLtFnGYMlkuB7P0ye-J3Uswvor3hNb3f$
> > >>>>>     versaclock6: clock-controller@6a {
> > >>>>>         /* Clock Consumer */
> > >>>>>         compatible = "idt,5p49v6965";
> > >>>>>                 reg = <0x6a>;
> > >>>>>                 #clock-cells = <1>;
> > >>>>>                 clocks = <&x304_clk>;
> > >>>>>                 clock-names = "xin";
> > >>>>>
> > >>>>>         assigned-clocks = <&versaclock6 1>,
> > >>>>>                           <&versaclock6 2>,
> > >>>>>                           <&versaclock6 3>,
> > >>>>>                           <&versaclock6 4>;
> > >>>>>         // assigned-clock-rates = <46800000>, <250000000>,
> > >>>>> <1000000>,
> > >>>> <13000000>;
> > >>>>>         assigned-clock-rates = <46800000>, <250000000>, <1000000>,
> > >>>> <13000000>;
> > >>>>>         /* Set the SD/OE pin's settings */
> > >>>>>         idt,shutdown = <0>;
> > >>>>>         idt,output-enable-active = <0>;
> > >>>>>         OUT1 {
> > >>>>>             idt,mode = <VC5_CMOS>;
> > >>>>>             idt,voltage-microvolt = <3300000>;
> > >>>>>             c = <100>;
> > >>>>>         };
> > >>>>>         OUT2 {
> > >>>>>             idt,mode = <VC5_CMOS>;
> > >>>>>             idt,voltage-microvolt = <3300000>;
> > >>>>>             idt,slew-percent = <100>;
> > >>>>>         };
> > >>>>>         OUT3 {
> > >>>>>             idt,mode = <VC5_CMOSD>;
> > >>>>>             idt,voltage-microvolt = <3300000>;
> > >>>>>             idt,slew-percent = <100>;
> > >>>>>         };
> > >>>>>         OUT4 {
> > >>>>>             idt,mode = <VC5_CMOS>;
> > >>>>>             idt,voltage-microvolt = <3300000>;
> > >>>>>             idt,slew-percent = <100>;
> > >>>>>         };
> > >>>>>     };
> > >>>>
> > >>>> Strange. Something you may check (or double check if you already did):
> > >>>>
> > >>>> 1. Read if the register has been set:
> > >>>>
> > >>>>   # not tested, check carefully
> > >>>>   i2cget -y -r 1 0x6a 0x60
> > >>>>
> > >>>> the three low bits in register 0x60 should read 0x1 for CMOS, 0x5
> > >>>> for
> > >> CMOSD.
> > >>>
> > >>> Apparently the register is not getting set properly.
> > >>>
> > >>> In response to 'i2cget -y -f 1 0x6a 0x60' (-r not supported maybe a
> > >>> typo?)
> > >>>
> > >>> I get 0xbb, which according to the spec I believe should give me
> > >>> CMOSD,
> > >> which is what I am seeing ( (D7, D6, D5) = 101: CMOSD ).
> > >>>
> > >>> I can set address 0x60 to 0x3b using i2cset to get single ended CMOS.
> > >>
> > >> I see. 0xbb is the reset default, so as you said it is not set.
> > >>
> > >>>> 2. Change idt,mode in device tree and see whether the register
> > >>>> changes or the scope show any different output mode.
> > >>>
> > >>> Changing ide,mode to VC5_LVDS does not the value of register 0x06.
> > >>> I still get a value of 0xbb
> > >>
> > >> Ok, coherent with test 1.
> > >>
> > >>>> 3. Enable debugging output (simpliy add #define DEBUG on top of
> > >>>> file and rebuild), then see whether during clk prepare you see this in
> > dmesg:
> > >>>>
> > >>>>   Update output ... mask 0x... val 0x....
> > >>>>
> > >>>> 4. Check whether the OUT1 node is actually found by adding a
> > >>>> dev_dbg() in vc5_get_output_config(), just before the
> > >>>> of_get_child_by_name() call and
> > >>>> ~5 lines below, between 'return 0' and vc5_update_mode().
> > >>>>
> > >>>> Let us know your findings.
> > >>>>
> > >>>
> > >>> Seems to be finding the nodes ok. Here is the relevant code section:
> > >>>
> > >>>   // temp for driver debug
> > >>>   dev_dbg(&client->dev,
> > >>>                   "get_output_config(before of_get_child_by_name)
> > >> OUT%d\n",
> > >>>                   clk_out->num + 1);
> > >>>
> > >>>   np_output = of_get_child_by_name(client->dev.of_node,
> > >> child_name);
> > >>>   kfree(child_name);
> > >>>   if (!np_output)
> > >>>           return 0;
> > >>>
> > >>>   // temp for driver debug
> > >>>   dev_dbg(&client->dev,
> > >>>                   "get_output_config(before update_mode)
> > >> OUT%d\n",
> > >>>                   clk_out->num + 1);
> > >>>
> > >>>   ret = vc5_update_mode(np_output, clk_out);
> > >>>   if (ret)
> > >>>           goto output_error;
> > >>>
> > >>> And dmesg output:
> > >>>
> > >>>   [    7.498005] vc5 1-006a: get_output_config(before
> > >> of_get_child_by_name)  OUT1
> > >>>   [    7.498017] vc5 1-006a: get_output_config(before update_mode)
> > >> OUT1
> > >>>   [    7.511631] vc5 1-006a: get_output_config(before
> > >> of_get_child_by_name)  OUT2
> > >>>   [    7.511643] vc5 1-006a: get_output_config(before update_mode)
> > >> OUT2
> > >>>   [    7.525257] vc5 1-006a: get_output_config(before
> > >> of_get_child_by_name)  OUT3
> > >>>   [    7.525270] vc5 1-006a: get_output_config(before update_mode)
> > >> OUT3
> > >>>   [    7.538905] vc5 1-006a: get_output_config(before
> > >> of_get_child_by_name)  OUT4
> > >>>   [    7.538919] vc5 1-006a: get_output_config(before update_mode)
> > >> OUT4
> > >>
> > >> So the values are picked up from DT and if you print the content of
> > >> clk_out-
> > >>> clk_output_cfg0[_mask] you should see the correct register values.
> > >>
> > >> Now the relevant question is question 3: do you enter the 'if
> > >> (hwdata-
> > >>> clk_output_cfg0_mask)' in vc5_clk_out_prepare()? Do you even enter
> > >> vc5_clk_out_prepare()?
> > >>
> > >> You can add dev_dbg()s there and track the problem on your own. If
> > >> regmap_update_bits(...hwdata->clk_output_cfg0) is not called then the
> > >> code is not doing the right thing. If it is called and returns no
> > >> error, then it looks like there is a problem in the i2c controller
> > >> which thinks it has done the transaction but it really hasn't. Or some other
> > mystery.
> > >>
> > >> --
> > >> Luca
> > >
> > > I added a few debug statements and I see that vc5_clk_out_prepare() is
> > not being called.
> >
> > My bad, I was quite sure assigned-clocks also enables the clock. :-/ Apologies
> > for having led you to a dead end.
>
> No problem.  You have been a tremendous help!
>
> >
> > > So perhaps this ties back to the point Adam made earlier about their
> > needing to be a consumer driver that enables the reference clock because it
> > is not enabled by default.  For my application there is no consumer driver, I
> > only have the device tree.
> >
> > Well, this is clearly the "correct" thing to do. However it's uncommon that
> > you have no consumer driver. What is the device that uses that clock and
> > why does it have no driver? Is it a device that "just works"
> > in the expected way without any configuration? Is it even avvessible by the
> > CPU?
> >
> > You might consider writing a "dummy" driver, with just a simple probe()
> > function that does devm_clk_get and clk_prepare_enable(). You'll find many
> > examples in the kernel. is it doable?
> >
> > > In my local copy of the driver that adds an 'idt,enable' pattern property I call
> > vc5_clk_out_prepare() if idt,enable is set for an output.  There may be a
> > cleaner way, but this seems to allow enabling of outputs from the device
> > tree.
> > >
> > > I did the following:
> > >
> > >         // idt,enable mod: add struct clk_hw *hw  arg
> > >         static int vc5_get_output_config(struct i2c_client *client,
> > >                                       struct vc5_out_data *clk_out, struct clk_hw *hw)
> > >         {
> > >             ...
> > >             ret = vc5_update_slew(np_output, clk_out);
> > >
> > >             // idt,enable mod: call to vc5_update_enable()
> > >             ret = vc5_update_enable(np_output, hw);
> > >             if (ret)
> > >                 goto output_error;
> > >
> > > And:
> > >
> > >         // begin idt,enable mod
> > >         static int vc5_update_enable(struct device_node *np_output,
> > >                                   struct clk_hw *hw)
> > >         {
> > >             u32 value;
> > >
> > >             if (!of_property_read_u32(np_output, "idt,enable", &value)) {
> > >                 if (value) {
> > >                     vc5_clk_out_prepare(hw);
> > >                 } else {
> > >                     vc5_clk_out_unprepare(hw);
> > >                 }
> > >             }
> > >             return 0;
> > >         }
> > >         // end idt,enable mod
> >
> > This is not the "expected" way to do it in the kernel, I would call it a shortcut
> > for not writing a consumer driver. However if it is enough for you and you
> > don't mind maintaining this modification in your own kernel fork, it will do.
> > Only, if were me, I would write a simple, dummy driver for the consumer
> > device to have things clean, learn something and, well, have fun.
> >
> > --
> > Luca
>
> In our application the requirement only that we set the clock frequencies at boot time so device tree is sufficient.  That being said, I hope to work on a simple consumer driver next.  Thought is to allow user to make changes via config file or something similar.  As you say should be fun!
>
> Thanks again for all the help you and others have provided.

Good luck.  I am hoping to find time tomorrow to test the clock
multiplier bit on my versaclock implementations.  If I find they work
without issue, I'll submit a formal patch with you in CC as
'suggested-by" so you get some credit for it.

adam
>
> -Claude
>
> ======================================================================
> This message and any attachments are intended only for the designated recipient(s) and may contain confidential or proprietary information and be subject to the attorney-client privilege or other confidentiality protections.  If you are not a designated recipient, you may not review, use, copy or distribute this message or any attachments.  If you received this email in error, please notify the sender by reply e-mail and permanently delete the original and any copies of this message and any attachments thereto.  Thank you.

RE: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Fillion, Claude]

> -----Original Message-----
> From: Adam Ford <aford173@gmail.com>
> Sent: Wednesday, March 2, 2022 10:46 AM
> To: Fillion, Claude <Claude.Fillion@mksinst.com>
> Cc: Luca Ceresoli <luca@lucaceresoli.net>; Sean Anderson
> <sean.anderson@seco.com>; linux-clk <linux-clk@vger.kernel.org>
> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> versaclock5 driver
> 
> On Wed, Mar 2, 2022 at 8:44 AM Fillion, Claude
> <Claude.Fillion@mksinst.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Adam Ford <aford173@gmail.com>
> > > Sent: Tuesday, March 1, 2022 1:28 PM
> > > To: Fillion, Claude <Claude.Fillion@mksinst.com>
> > > Cc: Luca Ceresoli <luca@lucaceresoli.net>; Sean Anderson
> > > <sean.anderson@seco.com>; linux-clk <linux-clk@vger.kernel.org>
> > > Subject: Re: [EXTERNAL] Re: Questions regarding regarding
> > > idt/renesas
> > > versaclock5 driver
> > >
> > > On Tue, Mar 1, 2022 at 12:16 PM Fillion, Claude
> > > <Claude.Fillion@mksinst.com> wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Adam Ford <aford173@gmail.com>
> > > > > Sent: Tuesday, March 1, 2022 9:30 AM
> > > > > To: Fillion, Claude <Claude.Fillion@mksinst.com>
> > > > > Cc: Luca Ceresoli <luca@lucaceresoli.net>; Sean Anderson
> > > > > <sean.anderson@seco.com>; linux-clk <linux-clk@vger.kernel.org>
> > > > > Subject: Re: [EXTERNAL] Re: Questions regarding regarding
> > > > > idt/renesas
> > > > > versaclock5 driver
> > > > >
> > > > > On Tue, Mar 1, 2022 at 8:12 AM Fillion, Claude
> > > > > <Claude.Fillion@mksinst.com>
> > > > > wrote:
> > > > > >
> > > > > > Thanks for your replies.  A few more points/questions.
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > >
> > > > > > > From: Luca Ceresoli <luca@lucaceresoli.net>
> > > > > >
> > > > > > > Sent: Monday, February 28, 2022 5:14 PM
> > > > > >
> > > > > > > To: Adam Ford <aford173@gmail.com>; Sean Anderson
> > > > > >
> > > > > > > <sean.anderson@seco.com>
> > > > > >
> > > > > > > Cc: Fillion, Claude <Claude.Fillion@mksinst.com>; linux-clk
> > > > > > > <linux-
> > > > > >
> > > > > > > clk@vger.kernel.org>
> > > > > >
> > > > > > > Subject: [EXTERNAL] Re: Questions regarding regarding
> > > > > > > idt/renesas
> > > > > >
> > > > > > > versaclock5 driver
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > This email originated outside of MKS.  Use caution when
> > > > > > > sharing information
> > > > > >
> > > > > > > or opening attachments and links.
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > ------------------------------------------------------------
> > > > > > > ----
> > > > > > > ----
> > > > > > > --------------------------
> > > > > >
> > > > > > > ----------------------------------------------
> > > > > >
> > > > > > > Hi,
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > On 28/02/22 18:06, Adam Ford wrote:
> > > > > >
> > > > > > > > On Mon, Feb 28, 2022 at 10:04 AM Sean Anderson
> > > > > >
> > > > > > > <sean.anderson@seco.com> wrote:
> > > > > >
> > > > > > > >>
> > > > > >
> > > > > > > >>
> > > > > >
> > > > > > > >>
> > > > > >
> > > > > > > >> On 2/28/22 7:35 AM, Fillion, Claude wrote:
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>> You don't often get email from claude.fillion@mksinst.com.
> > > > > > > >>> Learn why
> > > > > >
> > > > > > > >>> this is important
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > >
> > > > >
> > >
> <https://urldefense.com/v3/__http://aka.ms/LearnAboutSenderIdentific
> > > > > >
> > > > > > > >>> ation__;!!KnJ4-
> > > > > >
> > > > > > > rp7!1bH43_JT7scsjwzrGD8lPeXvlXh9WieG2jadu9NICLiUrW-We
> > > > > >
> > > > > > > >>> UZR3sOMdn4NpYPGkfDG$ >
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>> Hello  Sean,
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > + Luca Ceresoli
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>> I have a design that is looking to use the Renesas
> > > > > > > >>> 5P49V6965 or
> > > > > > > >>> 5P49V690
> > > > > >
> > > > > > > clock chip and am looking to use the versaclock 5 driver
> > > > > >
> > > > > > > (https://urldefense.com/v3/__https://github.com/Xilinx/linux
> > > > > > > -
> > > > > >
> > > > > > > xlnx/blob/master/drivers/clk/clk-versaclock5.c__;!!KnJ4-
> > > > > >
> > > > > > > rp7!1bH43_JT7scsjwzrGD8lPeXvlXh9WieG2jadu9NICLiUrW-
> > > > > >
> > > > > > > WeUZR3sOMdn4NpaBSRqIM$ ).
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>> I am new to writing drivers and have two questions I am
> > > > > > > >>> hoping you can
> > > > > >
> > > > > > > help me with:
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>> 1) In the driver I see the following code:
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>> static const struct vc5_chip_info idt_5p49v6901_info = {
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>             .model = IDT_VC6_5P49V6901,
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>             .clk_fod_cnt = 4,
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>             .clk_out_cnt = 5,
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>             .flags = VC5_HAS_PFD_FREQ_DBL,
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>> };
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>> static const struct vc5_chip_info idt_5p49v6965_info = {
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>             .model = IDT_VC6_5P49V6965,
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>             .clk_fod_cnt = 4,
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>             .clk_out_cnt = 5,
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>             .flags =  VC5_HAS_BYPASS_SYNC_BIT,
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>> };
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>> However, the 6965 part also has the same frequency
> > > > > > > >>> doubling bit as the
> > > > > >
> > > > > > > 6901.  Would it be better to set the flags for the 6965 to
> > > > > > > something like
> > > > > this?
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>> static const struct vc5_chip_info idt_5p49v6965_info = {
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>             .model = IDT_VC6_5P49V6965,
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>             .clk_fod_cnt = 4,
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>             .clk_out_cnt = 5,
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>>             .flags = VC5_HAS_PFD_FREQ_DBL |
> > > > > > > >>> VC5_HAS_BYPASS_SYNC_BIT,
> > > > > >
> > > > > > > >>>
> > > > > >
> > > > > > > >>> };
> > > > > >
> > > > > > > >>
> > > > > >
> > > > > > > >> I think Adam will have a better idea about this.
> > > > > >
> > > > > > > >>
> > > > > >
> > > > > > > >>> 2) I am unclear how to set the output frequencies for
> > > > > > > >>> the device. For my
> > > > > >
> > > > > > > application I would like to set output clock 1 to 250MHz and
> > > > > > > output clock 2 to
> > > > > >
> > > > > > > 46.8MHz but I am unclear how to do so.  I have looked at the
> > > > > > > documentation
> > > > > >
> > > > > > > at
> > > > > >
> > > > > > >
> > > > >
> > >
> https://urldefense.com/v3/__https://mjmwired.net/kernel/Documentatio
> > > > > > > n
> > > > > >
> > > > > > > /devicetree/bindings/clock/idt,versaclock5.yaml__;!!KnJ4-
> > > > > >
> > > > > > > rp7!1bH43_JT7scsjwzrGD8lPeXvlXh9WieG2jadu9NICLiUrW-
> > > > > >
> > > > > > > WeUZR3sOMdn4NpVQVg6al$  but remain unclear how to set the
> > > output
> > > > > >
> > > > > > > frequencies.  Any insight you could provide would be greatly
> > > appreciated.
> > > > > >
> > > > > > > >>
> > > > > >
> > > > > > > >> Use assigned-clock-frequencies as described in
> > > > > >
> > > > > > > >> Documentation/devicetree/bindings/clock/clock-bindings.tx
> > > > > > > >> t
> > > > > >
> > > > > > > >>
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > I agree that the clock-bindings have the instructions on
> > > > > > > > how to set
> > > > > >
> > > > > > > > them.  If you check
> > > > > >
> > > > > > > > arch/arm64/boot/dts/renesas/beacon-renesom-som.dtsi, there
> > > are
> > > > > > > > some
> > > > > >
> > > > > > > > examples of how to set the frequency.
> > > > > >
> > > > > > > > In my instance,  the chip wasn't enabling the output by
> > > > > > > > default, so I
> > > > > >
> > > > > > > > needed to submit some patches upstream to make sure the
> > > > > > > > device that
> > > > > >
> > > > > > > > was being clocked by this device had get and enable
> > > > > > > > functions to make
> > > > > >
> > > > > > > > sure the clock chip would turn on the clock when requested.
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > Indeed assigned-clocks is the way to enable a clock when the
> > > > > > > downstream
> > > > > >
> > > > > > > driver does not request it. Not that it is easy to find: it
> > > > > > > took me a while to find
> > > > > >
> > > > > > > it the first time I needed it.
> > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Trying to follow the example beacon-renesom-som.dtsi
> > > > > > implementation
> > > > > but am still not getting proper output.  I should note I am
> > > > > running this as a patch on an older Petalinux  code base
> > > > > (4.14.0-xilinx-v2018.3). After replacing
> > > > > dev_err_probe() calls with older dev_err() calls the code
> > > > > compiles and seems to run without issue. Is it possible other
> > > > > files need to be
> > > updated?
> > > > > >
> > > > > >
> > > > > >
> > > > > > Added the provider code at the beginning of dtsi as follows;
> > > > > >
> > > > > > #include <dt-bindings/clk/versaclock.h>
> > > > > >
> > > > > >
> > > > > >
> > > > > > /include/ "system-conf.dtsi"
> > > > > >
> > > > > > / {
> > > > > >
> > > > > >   /* Clock Provider */
> > > > > >
> > > > > >   x304_clk: x304-clock {
> > > > > >
> > > > > >     compatible = "fixed-clock";
> > > > > >
> > > > > >     #clock-cells = <0>;
> > > > > >
> > > > > >     clock-frequency = <25000000>;
> > > > > >
> > > > > >   };
> > > > > >
> > > > > > …
> > > > > >
> > > > > >
> > > > > >
> > > > > > And added consumer code:
> > > > > >
> > > > > >
> > > > > >
> > > > > > &i2c1 {
> > > > > >
> > > > > >     clock-frequency = <100000>;
> > > > > >
> > > > > >
> > > > > >
> > > > > >     // Use patch.  Updated driver for 5p49v6965 available  at
> > > > > > https://urldefense.com/v3/__https://github.com/Xilinx/linux-xl
> > > > > > nx/b
> > > > > > lob/
> > > > > > master/drivers/clk/clk-versaclock5.c__;!!KnJ4-rp7!3K4sRtgFBeaZ
> > > > > > Q8Ir
> > > > > > EvZ8 dkvJDiPMBlDRradrS0adfnpa1dNXMNjeIwNfOyHPLkFkwVpJ$
> > > > > >
> > > > > >     // Device Tree Setup ->
> > > > > > https://urldefense.com/v3/__https://github.com/Xilinx/linux-xl
> > > > > > nx/b
> > > > > > lob/
> > > > > >
> > > > >
> > >
> master/Documentation/devicetree/bindings/clock/idt*2Cversaclock5.yam
> > > > > l_
> > > > > > _;JQ!!KnJ4-
> > > > >
> rp7!3K4sRtgFBeaZQ8IrEvZ8dkvJDiPMBlDRradrS0adfnpa1dNXMNjeIwN
> > > > > > fOyHPLhF0Uums$
> > > > > >
> > > > > >     versaclock6: clock-controller@6a {
> > > > > >
> > > > > >         /* Clock Consumer */
> > > > > >
> > > > > >         compatible = "idt,5p49v6965";
> > > > > >
> > > > > >                                 reg = <0x6a>;
> > > > > >
> > > > > >                                 #clock-cells = <1>;
> > > > > >
> > > > > >                                 clocks = <&x304_clk>;
> > > > > >
> > > > > >                                 clock-names = "xin";
> > > > > >
> > > > > >
> > > > > >
> > > > > >         assigned_clocks = <&versaclock6 1>,
> > > > > >
> > > > > >                           <&versaclock6 2>,
> > > > > >
> > > > > >                           <&versaclock6 3>,
> > > > > >
> > > > > >                           <&versaclock6 4>;
> > > > > >
> > > > > >         assigned_clock_rates = <46800000>, <250000000>,
> > > > > > <1000000>, <13000000>;
> > > > >
> > > > >
> > > > > Assigned clocks and assigned clock rates should be hyphens and
> > > > > not underscores.
> > > > >
> > > > > assigned-clocks =  <&versaclock6 1>,   <&versaclock6 2>,
> > > > > <&versaclock6 3>, <&versaclock6 4>;
> > > > >
> > > > > assigned-clock-rates =  <46800000>, <250000000>, <1000000>,
> > > > > <13000000>;
> > > > >
> > > > > Another thing to check is to make sure the consumers of these
> > > > > clocks is enabling them.  They do not necessarily get enabled by
> default.
> > > > >
> > > > > adam
> > > >
> > > > Doh - thanks.  I looked at it a million times 😊 .
> > > >
> > > > Now getting desired out1 frequency but nothing on other outputs.
> > > > From
> > > the code it seems vc5_clk_out_prepare() is the method that enables
> > > outputs but this method is not being called I am not clear how to
> > > make the 'consumer enable them.'
> > > >
> > > > I have added this to my dtsi to no avail.
> > > >
> > > >          /* Consumer referencing 5P49V5965 pin OUT1 and OUT2 */
> > > >         consumer {
> > > >             clocks = <&versaclock6 1>, <&versaclock6 2>;
> > > >             /* ... */
> > > >          };
> > > >
> > > > Looking through device tree documentation.
> > >
> > > It's likely going to be in the consumer's driver.  Check the
> > > consumer device tree binding to make sure you've correctly
> > > associated the clock.  If the binding doesnt't show a clock is
> > > required, it might not know that you using a programmable clock.
> > >
> > > Here is a patch that I needed to apply to an Ethernet driver which
> > > wasn't expecting a programmable clock to drive a reference clock, so
> > > the clock wasn't being enabled.
> > >
> > > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/ker
> > > nel/g
> > > it/torvalds/linux.git/commit/drivers/net/ethernet/renesas/ravb_main.
> > > c?id=
> > > 8ef7adc6beb2ef0bce83513dc9e4505e7b21e8c2__;!!KnJ4-rp7!1Qb17q-
> > >
> TWrV62AeQtTNNVDErVbyhbXB1sukyT2ggvFPUltIBI5nIKzNnjVOcqlw8qJyy$
> > >
> > > Look at the use of devm_clk_get_optional and clk_prepare_enable from
> > > that patch.  (yes, there is a subsequent patch that fixes something
> > > I didn't quite do right, but the basics are here)
> > >
> > > The consumer drivers need to 'get' the clock so it can associate
> > > itself to the clock in question.  Once the relationship is
> > > established, the consumer needs to call clk_prepare_enable() which uses
> the clock system to turn the clock on.
> > > Without this step, it's likely the Versaclock won't generate a
> > > signal, because it doesn't know it needs to turn it on.
> > >
> > > adam
> >
> > Not sure I fully follow.  I see that clk out1 is enabled but the other channels
> are not so it would seem my difficulty is with individual channels.
> 
> Do the devices that need the clock from the versaclock reference the
> versaclock?  If so, to those drivers use the get and enable?  If not, the
> versaclock will stay off.  In the patch example I showed, I had to modify the
> Ethernet driver on a processor, because it didn't explicitly enable the
> reference clock.  That Ethernet driver expected the refclk was always
> present which was a false assumption.  Once I got the consumer device (in
> this case, Ethernet) to request and enable the clock, the clock subsystem
> enabled the corresponding output on the versaclock.
> 
> For the Ethernet example I cited above, the corresponding device tree looks
> like:
> 
> &avb {
>      clocks = <&cpg CPG_MOD 812>, <&versaclock5 4>;
>      clock-names = "fck", "refclk";
>      status = "okay";
> };
> 
> With this device tree reference, the 'refclk' gets associated to versaclock
> ouput 4.  When the Ethernet needs the clock, it calls clk_prepare_enable on
> that clock reference, and the clock system calls on the versaclock driver to
> enable the output.  The reason I needed to submit that patch was that the
> consumer driver (the Ethernet in this
> case) wasn't calling the clk_prepare_enable, so the clock remained off.  It's
> likely that whatever devices that need the clock from the versaclock will
> need both a device tree reference to it as well as a call to
> clk_prepare_enable.

For my application I would like the ability to set clock frequencies according  to values that are stored in a json formatted config file. Is there a way to change these values from user space app code?  If not, would it be ok to add code to my consumer driver (say in the probe method) that would read the values from the json and then call set_rate() and prepare_enable()) ?

Thanks,
Claude

> 
> >
> > In my simple application I would like to enable outputs, on a per channel
> basis, from the device tree.  Would it make sense  to add  an 'idt,enable'
> property in similar fashion to the existing idt,mode, idt,voltage-microvolt,
> and idt,slew-percent properties?  Then vc5_get_output_config() could be
> modified to also call vc5_clk_out_prepare() (or clk_prepare_enable(), which
> in turn would call vc5_clk_out_prepare()).
> 
> I can't speak for the linux clock group, but the advantage of patching the
> drivers that need the clocks generated from the versaclock is the ability to
> stop these clocks when the drivers are halted and/or suspended.
> 
> adam
> >
> > Seems like this would work nicely for my application but not sure it would
> be generally useful.
> >
> > -Claude
> >
> > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >         /* Set the SD/OE pin's settings */
> > > > > >
> > > > > >         OUT1 {
> > > > > >
> > > > > >             idt,mode = <VC5_LVDS>;
> > > > > >
> > > > > >             idt,voltage-microvolt = <3300000>;
> > > > > >
> > > > > >             idt,slew-percent = <100>;
> > > > > >
> > > > > >         };
> > > > > >
> > > > > >         OUT2 {
> > > > > >
> > > > > >             idt,mode = <VC5_LVDS>;
> > > > > >
> > > > > >             idt,voltage-microvolt = <3300000>;
> > > > > >
> > > > > >             idt,slew-percent = <100>;
> > > > > >
> > > > > >         };
> > > > > >
> > > > > >         OUT3 {
> > > > > >
> > > > > >             idt,mode = <VC5_LVDS>;
> > > > > >
> > > > > >             idt,voltage-microvolt = <3300000>;
> > > > > >
> > > > > >             idt,slew-percent = <100>;
> > > > > >
> > > > > >         };
> > > > > >
> > > > > >         OUT4 {
> > > > > >
> > > > > >             idt,mode = <VC5_LVDS>;
> > > > > >
> > > > > >             idt,voltage-microvolt = <3300000>;
> > > > > >
> > > > > >             idt,slew-percent = <100>;
> > > > > >
> > > > > >         };
> > > > > >
> > > > > >     };
> > > > > >
> > > > > > …
> > > > > >
> > > > > >
> > > > > >
> > > > > > But still only seeing default clocks (100MHz on out 1, nothing on
> out2-4).
> > > > > >
> > > > > >
> > > > > >
> > > > > > Any suggestions?
> > > > > >
> > > > > >
> > > > > >
> > > > > > > >>> I saw your name mentioned so I am emailing  you directly.
> > > > > > > >>> If there is a
> > > > > >
> > > > > > > better place to ask these questions can you please direct me
> there?
> > > > > > > Thanks
> > > > > >
> > > > > > > you so much.
> > > > > >
> > > > > > > >>
> > > > > >
> > > > > > > >> Adam (CC'd) wrote the original driver, so he's probably a
> > > > > > > >> better
> > > > > >
> > > > > > > >> person to start with. You should also CC the linux-clk
> > > > > > > >> mailing list
> > > > > >
> > > > > > > >> for questions about clock drivers.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > I've reviewed the datasheet for the 6965, and it doesn't
> > > > > > > > explicitly
> > > > > >
> > > > > > > > show the multiplier, but the programmer's guide does
> > > > > > > > appear to show
> > > > > >
> > > > > > > > the existence of bit that when set, it will "double the
> > > > > > > > reference
> > > > > >
> > > > > > > > frequency for the Phase frequency detector" but on the
> > > > > > > > programmer's
> > > > > >
> > > > > > > > guide for the 6901, the same bit reads "Enables frequency
> > > > > > > > doubler when
> > > > > >
> > > > > > > > set to 1" so it's not clear to me that these functions are
> > > > > > > > exactly the
> > > > > >
> > > > > > > > same, but implies that it might be.  I'll need some time
> > > > > > > > to test this,
> > > > > >
> > > > > > > > but if I find it works, I can push a patch to this driver.
> > > > > > > > I added
> > > > > >
> > > > > > > > Luca, as he is the maintainer for this driver as well.
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > Thanks Adam. I'm afraid I have no detailed answer as I never
> > > > > > > tried this bit,
> > > > > >
> > > > > > > but according to the docs indeed it looks like there is a
> > > > > > > doubler as you
> > > > > >
> > > > > > > noticed, that it is disabled by default. It would be nice to
> > > > > > > test it and submit a
> > > > > >
> > > > > > > patch, thanks!
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > --
> > > > > >
> > > > > > > Luca
> > > > > >
> > > > > >
> > > > > >
> > > > > > For what it's worth, I have played around with Renesas' Timing
> > > > > > Commander
> > > > > tool and they seem to use the doubler bit in the same fashion.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Claude
> > > > > >
> > > > > > ________________________________ This message and any
> > > > > > attachments are intended only for the designated
> > > > > recipient(s) and may contain confidential or proprietary
> > > > > information and be subject to the attorney-client privilege or
> > > > > other confidentiality protections. If you are not a designated
> > > > > recipient, you may not review, use, copy or distribute this
> > > > > message or any attachments. If you received this email in error,
> > > > > please notify the sender by reply e-mail and permanently delete
> > > > > the original and any copies of this message and any attachments
> thereto. Thank you.
> > > >
> > > >
> > >
> ==========================================================
> > > ============
> > > > This message and any attachments are intended only for the
> > > > designated
> > > recipient(s) and may contain confidential or proprietary information
> > > and be subject to the attorney-client privilege or other
> > > confidentiality protections.  If you are not a designated recipient,
> > > you may not review, use, copy or distribute this message or any
> > > attachments.  If you received this email in error, please notify the
> > > sender by reply e-mail and permanently delete the original and any
> > > copies of this message and any attachments thereto.  Thank you.
> >
> >
> ==========================================================
> ============
> > This message and any attachments are intended only for the designated
> recipient(s) and may contain confidential or proprietary information and be
> subject to the attorney-client privilege or other confidentiality protections.  If
> you are not a designated recipient, you may not review, use, copy or
> distribute this message or any attachments.  If you received this email in
> error, please notify the sender by reply e-mail and permanently delete the
> original and any copies of this message and any attachments thereto.  Thank
> you.

======================================================================
This message and any attachments are intended only for the designated recipient(s) and may contain confidential or proprietary information and be subject to the attorney-client privilege or other confidentiality protections.  If you are not a designated recipient, you may not review, use, copy or distribute this message or any attachments.  If you received this email in error, please notify the sender by reply e-mail and permanently delete the original and any copies of this message and any attachments thereto.  Thank you.

Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Luca Ceresoli]

Hi Claude,

On 21/03/22 22:21, Fillion, Claude wrote:
[...]
>>>> Look at the use of devm_clk_get_optional and clk_prepare_enable from
>>>> that patch.  (yes, there is a subsequent patch that fixes something
>>>> I didn't quite do right, but the basics are here)
>>>>
>>>> The consumer drivers need to 'get' the clock so it can associate
>>>> itself to the clock in question.  Once the relationship is
>>>> established, the consumer needs to call clk_prepare_enable() which uses
>> the clock system to turn the clock on.
>>>> Without this step, it's likely the Versaclock won't generate a
>>>> signal, because it doesn't know it needs to turn it on.
>>>>
>>>> adam
>>>
>>> Not sure I fully follow.  I see that clk out1 is enabled but the other channels
>> are not so it would seem my difficulty is with individual channels.
>>
>> Do the devices that need the clock from the versaclock reference the
>> versaclock?  If so, to those drivers use the get and enable?  If not, the
>> versaclock will stay off.  In the patch example I showed, I had to modify the
>> Ethernet driver on a processor, because it didn't explicitly enable the
>> reference clock.  That Ethernet driver expected the refclk was always
>> present which was a false assumption.  Once I got the consumer device (in
>> this case, Ethernet) to request and enable the clock, the clock subsystem
>> enabled the corresponding output on the versaclock.
>>
>> For the Ethernet example I cited above, the corresponding device tree looks
>> like:
>>
>> &avb {
>>      clocks = <&cpg CPG_MOD 812>, <&versaclock5 4>;
>>      clock-names = "fck", "refclk";
>>      status = "okay";
>> };
>>
>> With this device tree reference, the 'refclk' gets associated to versaclock
>> ouput 4.  When the Ethernet needs the clock, it calls clk_prepare_enable on
>> that clock reference, and the clock system calls on the versaclock driver to
>> enable the output.  The reason I needed to submit that patch was that the
>> consumer driver (the Ethernet in this
>> case) wasn't calling the clk_prepare_enable, so the clock remained off.  It's
>> likely that whatever devices that need the clock from the versaclock will
>> need both a device tree reference to it as well as a call to
>> clk_prepare_enable.
> 
> For my application I would like the ability to set clock frequencies according  to values that are stored in a json formatted config file. Is there a way to change these values from user space app code?  If not, would it be ok to add code to my consumer driver (say in the probe method) that would read the values from the json and then call set_rate() and prepare_enable()) ?

This is absolutely not a standard practice in the kernel. If drivers are
well written then a consumer driver knows which clock it needs, it will
ask the produced that frequency and configure the consumer device
accordingly.

E.g. if the consumer device is an audio codec then user space will never
say "I want you to ask for a 1 MHz clock" but rather "I want to playback
at 48 kHz", then the driver will ask for a given clock frequency and
configure the codec to use it, perhaps setting divisor/multiplier
registers etc.

So I really suggest you to understand what the correct kernel-userspace
interface would be for your consumer driver. If you want you can share
what the consumer device is so we can be give some suggestions.

That said, if you don't want to mainline your consumer driver nobody
will prevent you from doing anything "strange". But keep it limited to
your driver, you don't want to have conflicts in the versaclock code
when you upgrade to a more recent kernel.

Also, I don't think json is expected to be in the kernel. If you want to
do something like that then maybe parse json at userspace level and then
send just the frequency in Hz via a sysfs entry.

-- 
Luca

RE: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Fillion, Claude]

Hello Luca,

> -----Original Message-----
> From: Luca Ceresoli <luca@lucaceresoli.net>
> Sent: Tuesday, March 22, 2022 12:00 PM
> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> <aford173@gmail.com>
> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> clk@vger.kernel.org>
> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> versaclock5 driver
> 
> Hi Claude,
> 
> On 21/03/22 22:21, Fillion, Claude wrote:
> [...]
> >>>> Look at the use of devm_clk_get_optional and clk_prepare_enable
> >>>> from that patch.  (yes, there is a subsequent patch that fixes
> >>>> something I didn't quite do right, but the basics are here)
> >>>>
> >>>> The consumer drivers need to 'get' the clock so it can associate
> >>>> itself to the clock in question.  Once the relationship is
> >>>> established, the consumer needs to call clk_prepare_enable() which
> >>>> uses
> >> the clock system to turn the clock on.
> >>>> Without this step, it's likely the Versaclock won't generate a
> >>>> signal, because it doesn't know it needs to turn it on.
> >>>>
> >>>> adam
> >>>
> >>> Not sure I fully follow.  I see that clk out1 is enabled but the
> >>> other channels
> >> are not so it would seem my difficulty is with individual channels.
> >>
> >> Do the devices that need the clock from the versaclock reference the
> >> versaclock?  If so, to those drivers use the get and enable?  If not,
> >> the versaclock will stay off.  In the patch example I showed, I had
> >> to modify the Ethernet driver on a processor, because it didn't
> >> explicitly enable the reference clock.  That Ethernet driver expected
> >> the refclk was always present which was a false assumption.  Once I
> >> got the consumer device (in this case, Ethernet) to request and
> >> enable the clock, the clock subsystem enabled the corresponding output
> on the versaclock.
> >>
> >> For the Ethernet example I cited above, the corresponding device tree
> >> looks
> >> like:
> >>
> >> &avb {
> >>      clocks = <&cpg CPG_MOD 812>, <&versaclock5 4>;
> >>      clock-names = "fck", "refclk";
> >>      status = "okay";
> >> };
> >>
> >> With this device tree reference, the 'refclk' gets associated to
> >> versaclock ouput 4.  When the Ethernet needs the clock, it calls
> >> clk_prepare_enable on that clock reference, and the clock system
> >> calls on the versaclock driver to enable the output.  The reason I
> >> needed to submit that patch was that the consumer driver (the
> >> Ethernet in this
> >> case) wasn't calling the clk_prepare_enable, so the clock remained
> >> off.  It's likely that whatever devices that need the clock from the
> >> versaclock will need both a device tree reference to it as well as a
> >> call to clk_prepare_enable.
> >
> > For my application I would like the ability to set clock frequencies according
> to values that are stored in a json formatted config file. Is there a way to
> change these values from user space app code?  If not, would it be ok to add
> code to my consumer driver (say in the probe method) that would read the
> values from the json and then call set_rate() and prepare_enable()) ?
> 
> This is absolutely not a standard practice in the kernel. If drivers are well
> written then a consumer driver knows which clock it needs, it will ask the
> produced that frequency and configure the consumer device accordingly.
> 
> E.g. if the consumer device is an audio codec then user space will never say "I
> want you to ask for a 1 MHz clock" but rather "I want to playback at 48 kHz",
> then the driver will ask for a given clock frequency and configure the codec to
> use it, perhaps setting divisor/multiplier registers etc.
> 
> So I really suggest you to understand what the correct kernel-userspace
> interface would be for your consumer driver. If you want you can share what
> the consumer device is so we can be give some suggestions.
> 
> That said, if you don't want to mainline your consumer driver nobody will
> prevent you from doing anything "strange". But keep it limited to your driver,
> you don't want to have conflicts in the versaclock code when you upgrade to
> a more recent kernel.
> 
> Also, I don't think json is expected to be in the kernel. If you want to do
> something like that then maybe parse json at userspace level and then send
> just the frequency in Hz via a sysfs entry.
> 
> --
> Luca

Hello Luca,
Thank you for responding.  I will attempt to provide a little more detail on our use case.  Our products do a fair amount of signal processing, both in transmitting and receiving chains. The clocks we would like to adjust control ADC and DAC sample rates.  These rates do not change frequently, but depending on particular features we enable or on conditions that are specific to a certain customer there will be times where we will need to change sample rates. Our products have an extensive set of configuration parameters contained in json files that control many details of our signal processing chains.  Ideally we would like to add the ability to get/set clock rates through this mechanism.

When changing frequency we expect to reboot the device, but would like to avoid rebuilding/distributing new code.  Essentially  1 code package, configured multiple different ways.

The idea of parsing json at userspace and just sending the frequency in Hz via a sysfs entry seems appealing. I thought I would need to call the set_rate() method of the driver in order to change frequency.  If it is not too much trouble can you explain how I could change frequency via sysfs call?

This is what I see on the device in /sys:
      root@CLAUDE:/sys/class/i2c-dev/i2c-1/device/1-006a# ls
      driver     modalias   name       of_node    power      subsystem  uevent

From this I am not clear on how to set frequency.

Regards,
Claude

======================================================================
This message and any attachments are intended only for the designated recipient(s) and may contain confidential or proprietary information and be subject to the attorney-client privilege or other confidentiality protections.  If you are not a designated recipient, you may not review, use, copy or distribute this message or any attachments.  If you received this email in error, please notify the sender by reply e-mail and permanently delete the original and any copies of this message and any attachments thereto.  Thank you.

Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Luca Ceresoli]

Hello Claude,

apologies for the extremely delayed reply...

On 22/03/22 21:09, Fillion, Claude wrote:
>>> For my application I would like the ability to set clock frequencies according
>> to values that are stored in a json formatted config file. Is there a way to
>> change these values from user space app code?  If not, would it be ok to add
>> code to my consumer driver (say in the probe method) that would read the
>> values from the json and then call set_rate() and prepare_enable()) ?
>>
>> This is absolutely not a standard practice in the kernel. If drivers are well
>> written then a consumer driver knows which clock it needs, it will ask the
>> produced that frequency and configure the consumer device accordingly.
>>
>> E.g. if the consumer device is an audio codec then user space will never say "I
>> want you to ask for a 1 MHz clock" but rather "I want to playback at 48 kHz",
>> then the driver will ask for a given clock frequency and configure the codec to
>> use it, perhaps setting divisor/multiplier registers etc.
>>
>> So I really suggest you to understand what the correct kernel-userspace
>> interface would be for your consumer driver. If you want you can share what
>> the consumer device is so we can be give some suggestions.
>>
>> That said, if you don't want to mainline your consumer driver nobody will
>> prevent you from doing anything "strange". But keep it limited to your driver,
>> you don't want to have conflicts in the versaclock code when you upgrade to
>> a more recent kernel.
>>
>> Also, I don't think json is expected to be in the kernel. If you want to do
>> something like that then maybe parse json at userspace level and then send
>> just the frequency in Hz via a sysfs entry.
>>
>> --
>> Luca
> 
> Hello Luca,
> Thank you for responding.  I will attempt to provide a little more detail on our use case.  Our products do a fair amount of signal processing, both in transmitting and receiving chains. The clocks we would like to adjust control ADC and DAC sample rates.  These rates do not change frequently, but depending on particular features we enable or on conditions that are specific to a certain customer there will be times where we will need to change sample rates. Our products have an extensive set of configuration parameters contained in json files that control many details of our signal processing chains.  Ideally we would like to add the ability to get/set clock rates through this mechanism.
> 
> When changing frequency we expect to reboot the device, but would like to avoid rebuilding/distributing new code.  Essentially  1 code package, configured multiple different ways.
> 
> The idea of parsing json at userspace and just sending the frequency in Hz via a sysfs entry seems appealing. I thought I would need to call the set_rate() method of the driver in order to change frequency.  If it is not too much trouble can you explain how I could change frequency via sysfs call?
> 
> This is what I see on the device in /sys:
>       root@CLAUDE:/sys/class/i2c-dev/i2c-1/device/1-006a# ls
>       driver     modalias   name       of_node    power      subsystem  uevent
> 
> From this I am not clear on how to set frequency.

You can't change the frequency using those sysfs interfaces. This is
because you are not supposed to change a frequency from userspace.

The reason is that a clock is not generally supposed to be used per se,
but rather to be consumed by another device (hence the name "consumer
driver"). Se my example about an audio codec.

Given the use case that you broadly described it looks like you need one
or another clock frequency based on some features that the consumer
device can optionally deliver. E.g. is you enable feature foo then it
will need a faster clock for the extra processing. If it is the case
then a proper way is probably to write your consumer driver to request
the clock it needs based on the enabled features:

  clk_set_rate(clk, feature_foo_is_enabled ? 2000000 : 1000000);

Does it make sense?

-- 
Luca

RE: [EXTERNAL] Re: Questions regarding regarding idt/renesas versaclock5 driver

[Fillion, Claude]

Hello Luca,

No problem on the delayed response.  I ended up working from this patch( https://lkml.iu.edu/hypermail/linux/kernel/1305.1/01893.html) that provides the type of userspace access we were looking for.  Allows us to read a config file and update clock frequencies as part of our boot process.   Not accessible to users, seems to be working well for our application.  

Thanks again for your help throughout my learning process.

-Claude

> -----Original Message-----
> From: Luca Ceresoli <luca@lucaceresoli.net>
> Sent: Thursday, April 14, 2022 6:37 PM
> To: Fillion, Claude <Claude.Fillion@mksinst.com>; Adam Ford
> <aford173@gmail.com>
> Cc: Sean Anderson <sean.anderson@seco.com>; linux-clk <linux-
> clk@vger.kernel.org>
> Subject: Re: [EXTERNAL] Re: Questions regarding regarding idt/renesas
> versaclock5 driver
> 
> Hello Claude,
> 
> apologies for the extremely delayed reply...
> 
> On 22/03/22 21:09, Fillion, Claude wrote:
> >>> For my application I would like the ability to set clock frequencies
> >>> according
> >> to values that are stored in a json formatted config file. Is there a
> >> way to change these values from user space app code?  If not, would
> >> it be ok to add code to my consumer driver (say in the probe method)
> >> that would read the values from the json and then call set_rate() and
> prepare_enable()) ?
> >>
> >> This is absolutely not a standard practice in the kernel. If drivers
> >> are well written then a consumer driver knows which clock it needs,
> >> it will ask the produced that frequency and configure the consumer
> device accordingly.
> >>
> >> E.g. if the consumer device is an audio codec then user space will
> >> never say "I want you to ask for a 1 MHz clock" but rather "I want to
> >> playback at 48 kHz", then the driver will ask for a given clock
> >> frequency and configure the codec to use it, perhaps setting
> divisor/multiplier registers etc.
> >>
> >> So I really suggest you to understand what the correct
> >> kernel-userspace interface would be for your consumer driver. If you
> >> want you can share what the consumer device is so we can be give some
> suggestions.
> >>
> >> That said, if you don't want to mainline your consumer driver nobody
> >> will prevent you from doing anything "strange". But keep it limited
> >> to your driver, you don't want to have conflicts in the versaclock
> >> code when you upgrade to a more recent kernel.
> >>
> >> Also, I don't think json is expected to be in the kernel. If you want
> >> to do something like that then maybe parse json at userspace level
> >> and then send just the frequency in Hz via a sysfs entry.
> >>
> >> --
> >> Luca
> >
> > Hello Luca,
> > Thank you for responding.  I will attempt to provide a little more detail on
> our use case.  Our products do a fair amount of signal processing, both in
> transmitting and receiving chains. The clocks we would like to adjust control
> ADC and DAC sample rates.  These rates do not change frequently, but
> depending on particular features we enable or on conditions that are specific
> to a certain customer there will be times where we will need to change
> sample rates. Our products have an extensive set of configuration
> parameters contained in json files that control many details of our signal
> processing chains.  Ideally we would like to add the ability to get/set clock
> rates through this mechanism.
> >
> > When changing frequency we expect to reboot the device, but would like
> to avoid rebuilding/distributing new code.  Essentially  1 code package,
> configured multiple different ways.
> >
> > The idea of parsing json at userspace and just sending the frequency in Hz
> via a sysfs entry seems appealing. I thought I would need to call the
> set_rate() method of the driver in order to change frequency.  If it is not too
> much trouble can you explain how I could change frequency via sysfs call?
> >
> > This is what I see on the device in /sys:
> >       root@CLAUDE:/sys/class/i2c-dev/i2c-1/device/1-006a# ls
> >       driver     modalias   name       of_node    power      subsystem  uevent
> >
> > From this I am not clear on how to set frequency.
> 
> You can't change the frequency using those sysfs interfaces. This is because
> you are not supposed to change a frequency from userspace.
> 
> The reason is that a clock is not generally supposed to be used per se, but
> rather to be consumed by another device (hence the name "consumer
> driver"). Se my example about an audio codec.
> 
> Given the use case that you broadly described it looks like you need one or
> another clock frequency based on some features that the consumer device
> can optionally deliver. E.g. is you enable feature foo then it will need a faster
> clock for the extra processing. If it is the case then a proper way is probably
> to write your consumer driver to request the clock it needs based on the
> enabled features:
> 
>   clk_set_rate(clk, feature_foo_is_enabled ? 2000000 : 1000000);
> 
> Does it make sense?
> 
> --
> Luca

======================================================================
This message and any attachments are intended only for the designated recipient(s) and may contain confidential or proprietary information and be subject to the attorney-client privilege or other confidentiality protections.  If you are not a designated recipient, you may not review, use, copy or distribute this message or any attachments.  If you received this email in error, please notify the sender by reply e-mail and permanently delete the original and any copies of this message and any attachments thereto.  Thank you.