Skip to contentSkip to conversation

placement for new clock drivers

U-Boot Dinh Nguyen 2 participants 4 messages Feb 29, 2016 – Mar 2, 2016

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw

Hi,

Quoted 9 lines · 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?

Yes.

Quoted 38 lines

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";
                };
};
Quoted 6 lines

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

#2 lore raw

Hi Simon,

Quoted 7 lines · Simon Glass
Quoted 4 lines

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?

Quoted 7 lines

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

#3 lore raw

Hi Dinh,

Quoted 9 lines · Dinh Nguyen

Hi Simon,

Quoted 5 lines · Simon Glass
Quoted 4 lines

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?

Quoted 5 lines
Quoted 2 lines

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.

Quoted 5 lines
Quoted 5 lines

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

Quoted 7 lines
Quoted 3 lines

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