Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1422135 > unrolled thread

Re: [PATCH 0/3] Convert clk-fixed into module platform driver

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/3] Convert clk-fixed into module platform driver Stephen Boyd <sboyd@codeaurora.org> - 2016-06-14 19:40 +0200
    Re: [PATCH 0/3] Convert clk-fixed into module platform driver Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> - 2016-06-15 01:00 +0200
      Re: [PATCH 0/3] Convert clk-fixed into module platform driver Stephen Boyd <sboyd@codeaurora.org> - 2016-06-16 02:30 +0200

#1422135 — Re: [PATCH 0/3] Convert clk-fixed into module platform driver

On 06/08, Ricardo Ribalda Delgado wrote:
> When clock providers are added to the device tree after of_clk_init is called
> they are not added to the clock provider list. This makes that drivers such
> as i2c-xiic.c fail to init, as they may depend on the unadded clock provider.

Who's the provider here? It isn't clear to me why we're
populating fixed factor and fixed rate clks from DT for i2c
devices? Presumably there's an i2c device driver that should be
populating clks from C code instead?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [next] | [standalone]

#1422436

Hi Stephen

Assume this device tree overlay:


&bus0{

axi_clk: axi_clk {
compatible = "fixed-clock";
#clock-cells = <0x0>;
clock-frequency = <125000000>;
};

iic_0: iic {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,xps-iic-2.00.a";
reg = < 0x00030000 0x10000 >;
interrupt-parent = <&xps_intc_0>;
interrupts = < 2 2 >;
clocks = <&axi_clk>;
 } ;

}

Which is basically a new i2c master and a fixed clock definition.

The fixed clock driver will only be probed to the driver at arch
initialization, when of_clk_init is called.  The device overlay can be
added at any point, usually after arch init. Which will result in ii_0
failing to probe,  because it is missing its clock.

This changeset allows fixed clocks to be added after of_clk_init is
called, by converting the driver into a platform driver.


Thanks!b

On Tue, Jun 14, 2016 at 7:39 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 06/08, Ricardo Ribalda Delgado wrote:
>> When clock providers are added to the device tree after of_clk_init is called
>> they are not added to the clock provider list. This makes that drivers such
>> as i2c-xiic.c fail to init, as they may depend on the unadded clock provider.
>
> Who's the provider here? It isn't clear to me why we're
> populating fixed factor and fixed rate clks from DT for i2c
> devices? Presumably there's an i2c device driver that should be
> populating clks from C code instead?
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project



-- 
Ricardo Ribalda

[toc] | [prev] | [next] | [standalone]

#1423592

On 06/15, Ricardo Ribalda Delgado wrote:
> Hi Stephen
> 
> Assume this device tree overlay:
> 
> 
> &bus0{
> 
> axi_clk: axi_clk {
> compatible = "fixed-clock";
> #clock-cells = <0x0>;
> clock-frequency = <125000000>;
> };
> 
> iic_0: iic {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "xlnx,xps-iic-2.00.a";
> reg = < 0x00030000 0x10000 >;
> interrupt-parent = <&xps_intc_0>;
> interrupts = < 2 2 >;
> clocks = <&axi_clk>;
>  } ;
> 
> }
> 
> Which is basically a new i2c master and a fixed clock definition.
> 
> The fixed clock driver will only be probed to the driver at arch
> initialization, when of_clk_init is called.  The device overlay can be
> added at any point, usually after arch init. Which will result in ii_0
> failing to probe,  because it is missing its clock.
> 
> This changeset allows fixed clocks to be added after of_clk_init is
> called, by converting the driver into a platform driver.
> 

Ok, so this is about supporting clks in overlays. I2C only comes
into the picture here because it's a consumer and happens to also
be on the same overlay.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web