[U-Boot] placement for new clock drivers

[U-Boot] placement for new clock drivers

[Dinh Nguyen]

Hi,

I have a few questions regarding the UCLASS_CLK driver. I need to
implement a clock driver for a new-ish platform, an ARMv7 based SoCFPGA
Arria10.

I think going forward, it would make sense to place the driver to be of
UCLASS_CLK and would go into drivers/clk/, instead of under
arch/arm/mach-socfpga directory, Am I correct in assuming that?

My 2nd question is regarding the usage of uclass_get_device(UCLASS_CLK).
If I have a DTS that is from:
arch/arm/dts/socfpga.dtsi

Fragment of the clock portion from the DTS here:

clkmgr at ffd04000 {
	compatible = "altr,clk-mgr";
	reg = <0xffd04000 0x1000>;

	clocks {
		#address-cells = <1>;
		#size-cells = <0>;

		osc1: osc1 {
			#clock-cells = <0>;
			compatible = "fixed-clock";
			clock-frequency = <25000000>;
			
		};

		osc2: osc2 {
 			#clock-cells = <0>;
			compatible = "fixed-clock";
		};

		f2s_periph_ref_clk: f2s_periph_ref_clk {
			#clock-cells = <0>;
			compatible = "fixed-clock";
		};

		f2s_sdram_ref_clk: f2s_sdram_ref_clk {
			#clock-cells = <0>;
			compatible = "fixed-clock";
		};
};

I tried calling uclass_get_device(UCLASS_CLK, 0, dev), thinking that it
would return the "fixed-clock" clocks, then I can get the frequencies
and move forward with calculating the rest of the clocks. But
uclass_get_device() is returning an error for me. I'm sure I might have
missed understood how the clock framework is supposed to work somewhere.
Can you please point me in the right direction?

Thanks,
Dinh

[U-Boot] placement for new clock drivers

[Simon Glass]

Hi,

On 29 February 2016 at 09:56, Dinh Nguyen
<dinguyen@opensource.altera.com> wrote:
> Hi,
>
> I have a few questions regarding the UCLASS_CLK driver. I need to
> implement a clock driver for a new-ish platform, an ARMv7 based SoCFPGA
> Arria10.
>
> I think going forward, it would make sense to place the driver to be of
> UCLASS_CLK and would go into drivers/clk/, instead of under
> arch/arm/mach-socfpga directory, Am I correct in assuming that?

Yes.

>
> My 2nd question is regarding the usage of uclass_get_device(UCLASS_CLK).
> If I have a DTS that is from:
> arch/arm/dts/socfpga.dtsi
>
> Fragment of the clock portion from the DTS here:
>
> clkmgr at ffd04000 {
>         compatible = "altr,clk-mgr";
>         reg = <0xffd04000 0x1000>;
>
>         clocks {
>                 #address-cells = <1>;
>                 #size-cells = <0>;
>
>                 osc1: osc1 {
>                         #clock-cells = <0>;
>                         compatible = "fixed-clock";
>                         clock-frequency = <25000000>;
>
>                 };
>
>                 osc2: osc2 {
>                         #clock-cells = <0>;
>                         compatible = "fixed-clock";
>                 };
>
>                 f2s_periph_ref_clk: f2s_periph_ref_clk {
>                         #clock-cells = <0>;
>                         compatible = "fixed-clock";
>                 };
>
>                 f2s_sdram_ref_clk: f2s_sdram_ref_clk {
>                         #clock-cells = <0>;
>                         compatible = "fixed-clock";
>                 };
> };
>
> I tried calling uclass_get_device(UCLASS_CLK, 0, dev), thinking that it
> would return the "fixed-clock" clocks, then I can get the frequencies
> and move forward with calculating the rest of the clocks. But
> uclass_get_device() is returning an error for me. I'm sure I might have
> missed understood how the clock framework is supposed to work somewhere.
> Can you please point me in the right direction?

Do you have a driver for altr,clk-mgr? If not you could add a driver,
or maybe "simple-bus" to the compatible string.

If you add a driver, see simple_bus_post_bind() for the function you
need to call to bind devices in sub-nodes.

Regards,
Simon

[U-Boot] placement for new clock drivers

[Dinh Nguyen]

Hi Simon,

On 02/29/2016 08:03 PM, Simon Glass wrote:
>>
>> I think going forward, it would make sense to place the driver to be of
>> UCLASS_CLK and would go into drivers/clk/, instead of under
>> arch/arm/mach-socfpga directory, Am I correct in assuming that?
> 
> Yes.
> 

Do you see any benefits to moving an existing clock driver that is in
arch/ to drivers/clk and making it UCLASS_CLK?

> 
> Do you have a driver for altr,clk-mgr? If not you could add a driver,
> or maybe "simple-bus" to the compatible string.
> 
> If you add a driver, see simple_bus_post_bind() for the function you
> need to call to bind devices in sub-nodes.
> 

The reason I ask is that I think I will have to create a driver for
"altr,clk-mgr" for the Arria10 platform, so I'm just wondering if I
should do the same for a legacy clock manager.

Thanks,
Dinh

[U-Boot] placement for new clock drivers

[Simon Glass]

Hi Dinh,

On 1 March 2016 at 15:16, Dinh Nguyen <dinguyen@opensource.altera.com> wrote:
>
> Hi Simon,
>
> On 02/29/2016 08:03 PM, Simon Glass wrote:
> >>
> >> I think going forward, it would make sense to place the driver to be of
> >> UCLASS_CLK and would go into drivers/clk/, instead of under
> >> arch/arm/mach-socfpga directory, Am I correct in assuming that?
> >
> > Yes.
> >
>
> Do you see any benefits to moving an existing clock driver that is in
> arch/ to drivers/clk and making it UCLASS_CLK?

It moves it to the new world, so some benefit there.

>
> >
> > Do you have a driver for altr,clk-mgr? If not you could add a driver,
> > or maybe "simple-bus" to the compatible string.
> >
> > If you add a driver, see simple_bus_post_bind() for the function you
> > need to call to bind devices in sub-nodes.
> >
>
> The reason I ask is that I think I will have to create a driver for
> "altr,clk-mgr" for the Arria10 platform, so I'm just wondering if I
> should do the same for a legacy clock manager.

What do you mean by legacy clock manager?

You'll only need this for driver model. Also, the driver can be very
simple, like simple-bus.

Regards,
Simon