[PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Florian Vaussard]

Hello,

Trying to get my SMSC9221 working on OMAP4 with DT,
I faced a misconfigured gpmc_fck (dummy clock set to 0)
resulting in serveral division-by-zero, misconfigured
timings and driver lost in the La La Land.

To solve this, patch 1 removes gpmc_fck from the dummy
clocks, and patch 2 adds the gpmc_fck DT node and
reference it from the gpmc node.

Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.

Regards,
Florian
---
Since v1:
- Removed the gpmc_fck clock node, and reference directly l3_ick

Florian Vaussard (2):
  CLK: TI: OMAP4: Remove gpmc_fck from dummy clocks
  ARM: DTS: OMAP4: Use l3_ick for the gpmc node

 arch/arm/boot/dts/omap4.dtsi | 2 ++
 drivers/clk/ti/clk-44xx.c    | 1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

-- 
1.8.1.2

[PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Florian Vaussard]

Hello,

Trying to get my SMSC9221 working on OMAP4 with DT,
I faced a misconfigured gpmc_fck (dummy clock set to 0)
resulting in serveral division-by-zero, misconfigured
timings and driver lost in the La La Land.

To solve this, patch 1 removes gpmc_fck from the dummy
clocks, and patch 2 adds the gpmc_fck DT node and
reference it from the gpmc node.

Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.

Regards,
Florian
---
Since v1:
- Removed the gpmc_fck clock node, and reference directly l3_ick

Florian Vaussard (2):
  CLK: TI: OMAP4: Remove gpmc_fck from dummy clocks
  ARM: DTS: OMAP4: Use l3_ick for the gpmc node

 arch/arm/boot/dts/omap4.dtsi | 2 ++
 drivers/clk/ti/clk-44xx.c    | 1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

-- 
1.8.1.2

[PATCH v2 1/2] CLK: TI: OMAP4: Remove gpmc_fck from dummy clocks

[Florian Vaussard]

When arch/arm/mach-omap2/gpmc.c calls clk_get(..., "fck"), it will
get a dummy clock and try to use it. As the rate is configured to zero,
this will result in several divisions by zero, and misconfigured
timings, with devices on the bus being lost in the La La Land.

It is better to remove gpmc_fck from the dummy clocks, so that gpmc.c
can fail gracefully.

Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
---
 drivers/clk/ti/clk-44xx.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/clk/ti/clk-44xx.c b/drivers/clk/ti/clk-44xx.c
index ae00218..02517a8 100644
--- a/drivers/clk/ti/clk-44xx.c
+++ b/drivers/clk/ti/clk-44xx.c
@@ -222,7 +222,6 @@ static struct ti_dt_clk omap44xx_clks[] = {
 	DT_CLK(NULL, "auxclk5_src_ck", "auxclk5_src_ck"),
 	DT_CLK(NULL, "auxclk5_ck", "auxclk5_ck"),
 	DT_CLK(NULL, "auxclkreq5_ck", "auxclkreq5_ck"),
-	DT_CLK("50000000.gpmc", "fck", "dummy_ck"),
 	DT_CLK("omap_i2c.1", "ick", "dummy_ck"),
 	DT_CLK("omap_i2c.2", "ick", "dummy_ck"),
 	DT_CLK("omap_i2c.3", "ick", "dummy_ck"),
-- 
1.8.1.2

[PATCH v2 1/2] CLK: TI: OMAP4: Remove gpmc_fck from dummy clocks

[Florian Vaussard]

When arch/arm/mach-omap2/gpmc.c calls clk_get(..., "fck"), it will
get a dummy clock and try to use it. As the rate is configured to zero,
this will result in several divisions by zero, and misconfigured
timings, with devices on the bus being lost in the La La Land.

It is better to remove gpmc_fck from the dummy clocks, so that gpmc.c
can fail gracefully.

Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
---
 drivers/clk/ti/clk-44xx.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/clk/ti/clk-44xx.c b/drivers/clk/ti/clk-44xx.c
index ae00218..02517a8 100644
--- a/drivers/clk/ti/clk-44xx.c
+++ b/drivers/clk/ti/clk-44xx.c
@@ -222,7 +222,6 @@ static struct ti_dt_clk omap44xx_clks[] = {
 	DT_CLK(NULL, "auxclk5_src_ck", "auxclk5_src_ck"),
 	DT_CLK(NULL, "auxclk5_ck", "auxclk5_ck"),
 	DT_CLK(NULL, "auxclkreq5_ck", "auxclkreq5_ck"),
-	DT_CLK("50000000.gpmc", "fck", "dummy_ck"),
 	DT_CLK("omap_i2c.1", "ick", "dummy_ck"),
 	DT_CLK("omap_i2c.2", "ick", "dummy_ck"),
 	DT_CLK("omap_i2c.3", "ick", "dummy_ck"),
-- 
1.8.1.2

[PATCH v2 2/2] ARM: DTS: OMAP4: Use l3_ick for the gpmc node

[Florian Vaussard]

The GPMC clock is derived from l3_ick. The simplest solution is
to reference directly l3_ick to provide the GPMC fck in order to
get correct timings. The real management of the clock is left to
hwmod.

Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
---
 arch/arm/boot/dts/omap4.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..69409f7 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -275,6 +275,8 @@
 			gpmc,num-waitpins = <4>;
 			ti,hwmods = "gpmc";
 			ti,no-idle-on-init;
+			clocks = <&l3_div_ck>;
+			clock-names = "fck";
 		};
 
 		uart1: serial@4806a000 {
-- 
1.8.1.2

[PATCH v2 2/2] ARM: DTS: OMAP4: Use l3_ick for the gpmc node

[Florian Vaussard]

The GPMC clock is derived from l3_ick. The simplest solution is
to reference directly l3_ick to provide the GPMC fck in order to
get correct timings. The real management of the clock is left to
hwmod.

Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
---
 arch/arm/boot/dts/omap4.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..69409f7 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -275,6 +275,8 @@
 			gpmc,num-waitpins = <4>;
 			ti,hwmods = "gpmc";
 			ti,no-idle-on-init;
+			clocks = <&l3_div_ck>;
+			clock-names = "fck";
 		};
 
 		uart1: serial at 4806a000 {
-- 
1.8.1.2

Re: [PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Tero Kristo]

On 02/19/2014 11:15 AM, Florian Vaussard wrote:
> Hello,
>
> Trying to get my SMSC9221 working on OMAP4 with DT,
> I faced a misconfigured gpmc_fck (dummy clock set to 0)
> resulting in serveral division-by-zero, misconfigured
> timings and driver lost in the La La Land.
>
> To solve this, patch 1 removes gpmc_fck from the dummy
> clocks, and patch 2 adds the gpmc_fck DT node and
> reference it from the gpmc node.
>
> Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.

I can't test GPMC myself, but other than that, this set looks good to go.

-Tero

>
> Regards,
> Florian
> ---
> Since v1:
> - Removed the gpmc_fck clock node, and reference directly l3_ick
>
> Florian Vaussard (2):
>    CLK: TI: OMAP4: Remove gpmc_fck from dummy clocks
>    ARM: DTS: OMAP4: Use l3_ick for the gpmc node
>
>   arch/arm/boot/dts/omap4.dtsi | 2 ++
>   drivers/clk/ti/clk-44xx.c    | 1 -
>   2 files changed, 2 insertions(+), 1 deletion(-)
>

[PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Tero Kristo]

On 02/19/2014 11:15 AM, Florian Vaussard wrote:
> Hello,
>
> Trying to get my SMSC9221 working on OMAP4 with DT,
> I faced a misconfigured gpmc_fck (dummy clock set to 0)
> resulting in serveral division-by-zero, misconfigured
> timings and driver lost in the La La Land.
>
> To solve this, patch 1 removes gpmc_fck from the dummy
> clocks, and patch 2 adds the gpmc_fck DT node and
> reference it from the gpmc node.
>
> Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.

I can't test GPMC myself, but other than that, this set looks good to go.

-Tero

>
> Regards,
> Florian
> ---
> Since v1:
> - Removed the gpmc_fck clock node, and reference directly l3_ick
>
> Florian Vaussard (2):
>    CLK: TI: OMAP4: Remove gpmc_fck from dummy clocks
>    ARM: DTS: OMAP4: Use l3_ick for the gpmc node
>
>   arch/arm/boot/dts/omap4.dtsi | 2 ++
>   drivers/clk/ti/clk-44xx.c    | 1 -
>   2 files changed, 2 insertions(+), 1 deletion(-)
>

Re: [PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Florian Vaussard]

On 02/19/2014 05:22 PM, Tero Kristo wrote:
> On 02/19/2014 11:15 AM, Florian Vaussard wrote:
>> Hello,
>>
>> Trying to get my SMSC9221 working on OMAP4 with DT,
>> I faced a misconfigured gpmc_fck (dummy clock set to 0)
>> resulting in serveral division-by-zero, misconfigured
>> timings and driver lost in the La La Land.
>>
>> To solve this, patch 1 removes gpmc_fck from the dummy
>> clocks, and patch 2 adds the gpmc_fck DT node and
>> reference it from the gpmc node.
>>
>> Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.
> 
> I can't test GPMC myself, but other than that, this set looks good to go.
> 

Thank you. Would you like more test coverage by other people? I would
like to see this in -rc if possible, as it is needed to boot my OMAP4
system.

Regards,
Florian

[PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Florian Vaussard]

On 02/19/2014 05:22 PM, Tero Kristo wrote:
> On 02/19/2014 11:15 AM, Florian Vaussard wrote:
>> Hello,
>>
>> Trying to get my SMSC9221 working on OMAP4 with DT,
>> I faced a misconfigured gpmc_fck (dummy clock set to 0)
>> resulting in serveral division-by-zero, misconfigured
>> timings and driver lost in the La La Land.
>>
>> To solve this, patch 1 removes gpmc_fck from the dummy
>> clocks, and patch 2 adds the gpmc_fck DT node and
>> reference it from the gpmc node.
>>
>> Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.
> 
> I can't test GPMC myself, but other than that, this set looks good to go.
> 

Thank you. Would you like more test coverage by other people? I would
like to see this in -rc if possible, as it is needed to boot my OMAP4
system.

Regards,
Florian

Re: [PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Tero Kristo]

On 02/19/2014 09:26 PM, Florian Vaussard wrote:
>
> On 02/19/2014 05:22 PM, Tero Kristo wrote:
>> On 02/19/2014 11:15 AM, Florian Vaussard wrote:
>>> Hello,
>>>
>>> Trying to get my SMSC9221 working on OMAP4 with DT,
>>> I faced a misconfigured gpmc_fck (dummy clock set to 0)
>>> resulting in serveral division-by-zero, misconfigured
>>> timings and driver lost in the La La Land.
>>>
>>> To solve this, patch 1 removes gpmc_fck from the dummy
>>> clocks, and patch 2 adds the gpmc_fck DT node and
>>> reference it from the gpmc node.
>>>
>>> Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.
>>
>> I can't test GPMC myself, but other than that, this set looks good to go.
>>
>
> Thank you. Would you like more test coverage by other people? I would
> like to see this in -rc if possible, as it is needed to boot my OMAP4
> system.

Well, I just think the driver clock change should be acked by someone 
who knows gpmc better than me.

-Tero

[PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Tero Kristo]

On 02/19/2014 09:26 PM, Florian Vaussard wrote:
>
> On 02/19/2014 05:22 PM, Tero Kristo wrote:
>> On 02/19/2014 11:15 AM, Florian Vaussard wrote:
>>> Hello,
>>>
>>> Trying to get my SMSC9221 working on OMAP4 with DT,
>>> I faced a misconfigured gpmc_fck (dummy clock set to 0)
>>> resulting in serveral division-by-zero, misconfigured
>>> timings and driver lost in the La La Land.
>>>
>>> To solve this, patch 1 removes gpmc_fck from the dummy
>>> clocks, and patch 2 adds the gpmc_fck DT node and
>>> reference it from the gpmc node.
>>>
>>> Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.
>>
>> I can't test GPMC myself, but other than that, this set looks good to go.
>>
>
> Thank you. Would you like more test coverage by other people? I would
> like to see this in -rc if possible, as it is needed to boot my OMAP4
> system.

Well, I just think the driver clock change should be acked by someone 
who knows gpmc better than me.

-Tero

Re: [PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Tony Lindgren]

* Tero Kristo <t-kristo@ti.com> [140220 01:54]:
> On 02/19/2014 09:26 PM, Florian Vaussard wrote:
> >
> >On 02/19/2014 05:22 PM, Tero Kristo wrote:
> >>On 02/19/2014 11:15 AM, Florian Vaussard wrote:
> >>>Hello,
> >>>
> >>>Trying to get my SMSC9221 working on OMAP4 with DT,
> >>>I faced a misconfigured gpmc_fck (dummy clock set to 0)
> >>>resulting in serveral division-by-zero, misconfigured
> >>>timings and driver lost in the La La Land.
> >>>
> >>>To solve this, patch 1 removes gpmc_fck from the dummy
> >>>clocks, and patch 2 adds the gpmc_fck DT node and
> >>>reference it from the gpmc node.
> >>>
> >>>Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.
> >>
> >>I can't test GPMC myself, but other than that, this set looks good to go.
> >>
> >
> >Thank you. Would you like more test coverage by other people? I would
> >like to see this in -rc if possible, as it is needed to boot my OMAP4
> >system.
> 
> Well, I just think the driver clock change should be acked by
> someone who knows gpmc better than me.

Hmm do we also need to fix this for other omaps? We at least have
the following refrerences:

$ git grep dummy_ck drivers/ | grep -i gpmc
drivers/clk/ti/clk-44xx.c:      DT_CLK("50000000.gpmc", "fck", "dummy_ck"),
drivers/clk/ti/clk-54xx.c:      DT_CLK(NULL, "gpmc_ck", "dummy_ck"),
drivers/clk/ti/clk-7xx.c:       DT_CLK(NULL, "gpmc_ck", "dummy_ck"),

Regards,

Tony

[PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Tony Lindgren]

* Tero Kristo <t-kristo@ti.com> [140220 01:54]:
> On 02/19/2014 09:26 PM, Florian Vaussard wrote:
> >
> >On 02/19/2014 05:22 PM, Tero Kristo wrote:
> >>On 02/19/2014 11:15 AM, Florian Vaussard wrote:
> >>>Hello,
> >>>
> >>>Trying to get my SMSC9221 working on OMAP4 with DT,
> >>>I faced a misconfigured gpmc_fck (dummy clock set to 0)
> >>>resulting in serveral division-by-zero, misconfigured
> >>>timings and driver lost in the La La Land.
> >>>
> >>>To solve this, patch 1 removes gpmc_fck from the dummy
> >>>clocks, and patch 2 adds the gpmc_fck DT node and
> >>>reference it from the gpmc node.
> >>>
> >>>Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.
> >>
> >>I can't test GPMC myself, but other than that, this set looks good to go.
> >>
> >
> >Thank you. Would you like more test coverage by other people? I would
> >like to see this in -rc if possible, as it is needed to boot my OMAP4
> >system.
> 
> Well, I just think the driver clock change should be acked by
> someone who knows gpmc better than me.

Hmm do we also need to fix this for other omaps? We at least have
the following refrerences:

$ git grep dummy_ck drivers/ | grep -i gpmc
drivers/clk/ti/clk-44xx.c:      DT_CLK("50000000.gpmc", "fck", "dummy_ck"),
drivers/clk/ti/clk-54xx.c:      DT_CLK(NULL, "gpmc_ck", "dummy_ck"),
drivers/clk/ti/clk-7xx.c:       DT_CLK(NULL, "gpmc_ck", "dummy_ck"),

Regards,

Tony

Re: [PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Florian Vaussard]

On 02/22/2014 12:23 AM, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [140220 01:54]:
>> On 02/19/2014 09:26 PM, Florian Vaussard wrote:
>>>
>>> On 02/19/2014 05:22 PM, Tero Kristo wrote:
>>>> On 02/19/2014 11:15 AM, Florian Vaussard wrote:
>>>>> Hello,
>>>>>
>>>>> Trying to get my SMSC9221 working on OMAP4 with DT,
>>>>> I faced a misconfigured gpmc_fck (dummy clock set to 0)
>>>>> resulting in serveral division-by-zero, misconfigured
>>>>> timings and driver lost in the La La Land.
>>>>>
>>>>> To solve this, patch 1 removes gpmc_fck from the dummy
>>>>> clocks, and patch 2 adds the gpmc_fck DT node and
>>>>> reference it from the gpmc node.
>>>>>
>>>>> Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.
>>>>
>>>> I can't test GPMC myself, but other than that, this set looks good to go.
>>>>
>>>
>>> Thank you. Would you like more test coverage by other people? I would
>>> like to see this in -rc if possible, as it is needed to boot my OMAP4
>>> system.
>>
>> Well, I just think the driver clock change should be acked by
>> someone who knows gpmc better than me.
> 
> Hmm do we also need to fix this for other omaps? We at least have
> the following refrerences:
> 
> $ git grep dummy_ck drivers/ | grep -i gpmc
> drivers/clk/ti/clk-44xx.c:      DT_CLK("50000000.gpmc", "fck", "dummy_ck"),
> drivers/clk/ti/clk-54xx.c:      DT_CLK(NULL, "gpmc_ck", "dummy_ck"),
> drivers/clk/ti/clk-7xx.c:       DT_CLK(NULL, "gpmc_ck", "dummy_ck"),
> 

Yes, the same applies to OMAP5 and DRA7. For OMAP5, gpmc_fclk is
connected to L3MAIN2_L3_GICLK, which is a gated l3_iclk. For DRA7, I
have no idea, as the TRM is not public. Someone from  TI?

And I have no way to test this.

Cheers,
Florian

[PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Florian Vaussard]

On 02/22/2014 12:23 AM, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [140220 01:54]:
>> On 02/19/2014 09:26 PM, Florian Vaussard wrote:
>>>
>>> On 02/19/2014 05:22 PM, Tero Kristo wrote:
>>>> On 02/19/2014 11:15 AM, Florian Vaussard wrote:
>>>>> Hello,
>>>>>
>>>>> Trying to get my SMSC9221 working on OMAP4 with DT,
>>>>> I faced a misconfigured gpmc_fck (dummy clock set to 0)
>>>>> resulting in serveral division-by-zero, misconfigured
>>>>> timings and driver lost in the La La Land.
>>>>>
>>>>> To solve this, patch 1 removes gpmc_fck from the dummy
>>>>> clocks, and patch 2 adds the gpmc_fck DT node and
>>>>> reference it from the gpmc node.
>>>>>
>>>>> Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.
>>>>
>>>> I can't test GPMC myself, but other than that, this set looks good to go.
>>>>
>>>
>>> Thank you. Would you like more test coverage by other people? I would
>>> like to see this in -rc if possible, as it is needed to boot my OMAP4
>>> system.
>>
>> Well, I just think the driver clock change should be acked by
>> someone who knows gpmc better than me.
> 
> Hmm do we also need to fix this for other omaps? We at least have
> the following refrerences:
> 
> $ git grep dummy_ck drivers/ | grep -i gpmc
> drivers/clk/ti/clk-44xx.c:      DT_CLK("50000000.gpmc", "fck", "dummy_ck"),
> drivers/clk/ti/clk-54xx.c:      DT_CLK(NULL, "gpmc_ck", "dummy_ck"),
> drivers/clk/ti/clk-7xx.c:       DT_CLK(NULL, "gpmc_ck", "dummy_ck"),
> 

Yes, the same applies to OMAP5 and DRA7. For OMAP5, gpmc_fclk is
connected to L3MAIN2_L3_GICLK, which is a gated l3_iclk. For DRA7, I
have no idea, as the TRM is not public. Someone from  TI?

And I have no way to test this.

Cheers,
Florian

Re: [PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Florian Vaussard]

On 02/23/2014 10:23 PM, Mike Turquette wrote:
> Quoting Florian Vaussard (2014-02-19 11:26:43)
>>
>> On 02/19/2014 05:22 PM, Tero Kristo wrote:
>>> On 02/19/2014 11:15 AM, Florian Vaussard wrote:
>>>> Hello,
>>>>
>>>> Trying to get my SMSC9221 working on OMAP4 with DT,
>>>> I faced a misconfigured gpmc_fck (dummy clock set to 0)
>>>> resulting in serveral division-by-zero, misconfigured
>>>> timings and driver lost in the La La Land.
>>>>
>>>> To solve this, patch 1 removes gpmc_fck from the dummy
>>>> clocks, and patch 2 adds the gpmc_fck DT node and
>>>> reference it from the gpmc node.
>>>>
>>>> Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.
>>>
>>> I can't test GPMC myself, but other than that, this set looks good to go.
>>>
>>
>> Thank you. Would you like more test coverage by other people? I would
>> like to see this in -rc if possible, as it is needed to boot my OMAP4
>> system.
> 
> What OMAP4 system is this? Is this a regression for board that already
> has support merged into mainline?
> 

No, it is not yet merged into mainline. I was planning to post the DTS
this week, when most issues are cleared. Looking at the current mainline
boards, no one seems to use the GPMC, so I am just the first one to hit
this issue.

Regards,
Florian

[PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Florian Vaussard]

On 02/23/2014 10:23 PM, Mike Turquette wrote:
> Quoting Florian Vaussard (2014-02-19 11:26:43)
>>
>> On 02/19/2014 05:22 PM, Tero Kristo wrote:
>>> On 02/19/2014 11:15 AM, Florian Vaussard wrote:
>>>> Hello,
>>>>
>>>> Trying to get my SMSC9221 working on OMAP4 with DT,
>>>> I faced a misconfigured gpmc_fck (dummy clock set to 0)
>>>> resulting in serveral division-by-zero, misconfigured
>>>> timings and driver lost in the La La Land.
>>>>
>>>> To solve this, patch 1 removes gpmc_fck from the dummy
>>>> clocks, and patch 2 adds the gpmc_fck DT node and
>>>> reference it from the gpmc node.
>>>>
>>>> Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.
>>>
>>> I can't test GPMC myself, but other than that, this set looks good to go.
>>>
>>
>> Thank you. Would you like more test coverage by other people? I would
>> like to see this in -rc if possible, as it is needed to boot my OMAP4
>> system.
> 
> What OMAP4 system is this? Is this a regression for board that already
> has support merged into mainline?
> 

No, it is not yet merged into mainline. I was planning to post the DTS
this week, when most issues are cleared. Looking at the current mainline
boards, no one seems to use the GPMC, so I am just the first one to hit
this issue.

Regards,
Florian

Re: [PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Florian Vaussard]

On 02/25/2014 07:26 AM, Mike Turquette wrote:
> Quoting Florian Vaussard (2014-02-23 21:44:25)
>> On 02/23/2014 10:23 PM, Mike Turquette wrote:
>>> Quoting Florian Vaussard (2014-02-19 11:26:43)
>>>>
>>>> On 02/19/2014 05:22 PM, Tero Kristo wrote:
>>>>> On 02/19/2014 11:15 AM, Florian Vaussard wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Trying to get my SMSC9221 working on OMAP4 with DT,
>>>>>> I faced a misconfigured gpmc_fck (dummy clock set to 0)
>>>>>> resulting in serveral division-by-zero, misconfigured
>>>>>> timings and driver lost in the La La Land.
>>>>>>
>>>>>> To solve this, patch 1 removes gpmc_fck from the dummy
>>>>>> clocks, and patch 2 adds the gpmc_fck DT node and
>>>>>> reference it from the gpmc node.
>>>>>>
>>>>>> Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.
>>>>>
>>>>> I can't test GPMC myself, but other than that, this set looks good to go.
>>>>>
>>>>
>>>> Thank you. Would you like more test coverage by other people? I would
>>>> like to see this in -rc if possible, as it is needed to boot my OMAP4
>>>> system.
>>>
>>> What OMAP4 system is this? Is this a regression for board that already
>>> has support merged into mainline?
>>>
>>
>> No, it is not yet merged into mainline. I was planning to post the DTS
>> this week, when most issues are cleared. Looking at the current mainline
>> boards, no one seems to use the GPMC, so I am just the first one to hit
>> this issue.
> 
> OK, well typically the later -rc's are for fixing observed regressions.
> Since your platform is not yet merged in then it's probably fine to push
> this for 3.15.
> 

Fair enough. 3.15 is fine.

> This also gives time to test the fix for other OMAP-ish processors.
> 

I can do the v3, including OMAP5 and DRA7. But for DRA7, I will need
someone with the TRM telling me where is connected gpmc_fclk (Suman?).

BTW, your mail client seems to have corrupted the To: header, double
quotes " are missing between Tero, Benoît and Tony's addresses, mixing
them as the same person. Maybe an indigestion caused by the UTF8
character of Benoît?

Regards,
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Florian Vaussard]

On 02/25/2014 07:26 AM, Mike Turquette wrote:
> Quoting Florian Vaussard (2014-02-23 21:44:25)
>> On 02/23/2014 10:23 PM, Mike Turquette wrote:
>>> Quoting Florian Vaussard (2014-02-19 11:26:43)
>>>>
>>>> On 02/19/2014 05:22 PM, Tero Kristo wrote:
>>>>> On 02/19/2014 11:15 AM, Florian Vaussard wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Trying to get my SMSC9221 working on OMAP4 with DT,
>>>>>> I faced a misconfigured gpmc_fck (dummy clock set to 0)
>>>>>> resulting in serveral division-by-zero, misconfigured
>>>>>> timings and driver lost in the La La Land.
>>>>>>
>>>>>> To solve this, patch 1 removes gpmc_fck from the dummy
>>>>>> clocks, and patch 2 adds the gpmc_fck DT node and
>>>>>> reference it from the gpmc node.
>>>>>>
>>>>>> Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.
>>>>>
>>>>> I can't test GPMC myself, but other than that, this set looks good to go.
>>>>>
>>>>
>>>> Thank you. Would you like more test coverage by other people? I would
>>>> like to see this in -rc if possible, as it is needed to boot my OMAP4
>>>> system.
>>>
>>> What OMAP4 system is this? Is this a regression for board that already
>>> has support merged into mainline?
>>>
>>
>> No, it is not yet merged into mainline. I was planning to post the DTS
>> this week, when most issues are cleared. Looking at the current mainline
>> boards, no one seems to use the GPMC, so I am just the first one to hit
>> this issue.
> 
> OK, well typically the later -rc's are for fixing observed regressions.
> Since your platform is not yet merged in then it's probably fine to push
> this for 3.15.
> 

Fair enough. 3.15 is fine.

> This also gives time to test the fix for other OMAP-ish processors.
> 

I can do the v3, including OMAP5 and DRA7. But for DRA7, I will need
someone with the TRM telling me where is connected gpmc_fclk (Suman?).

BTW, your mail client seems to have corrupted the To: header, double
quotes " are missing between Tero, Beno?t and Tony's addresses, mixing
them as the same person. Maybe an indigestion caused by the UTF8
character of Beno?t?

Regards,
Florian

Re: [PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Suman Anna]

Florian,

On 02/25/2014 02:10 AM, Florian Vaussard wrote:
> On 02/25/2014 07:26 AM, Mike Turquette wrote:
>> Quoting Florian Vaussard (2014-02-23 21:44:25)
>>> On 02/23/2014 10:23 PM, Mike Turquette wrote:
>>>> Quoting Florian Vaussard (2014-02-19 11:26:43)
>>>>>
>>>>> On 02/19/2014 05:22 PM, Tero Kristo wrote:
>>>>>> On 02/19/2014 11:15 AM, Florian Vaussard wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Trying to get my SMSC9221 working on OMAP4 with DT,
>>>>>>> I faced a misconfigured gpmc_fck (dummy clock set to 0)
>>>>>>> resulting in serveral division-by-zero, misconfigured
>>>>>>> timings and driver lost in the La La Land.
>>>>>>>
>>>>>>> To solve this, patch 1 removes gpmc_fck from the dummy
>>>>>>> clocks, and patch 2 adds the gpmc_fck DT node and
>>>>>>> reference it from the gpmc node.
>>>>>>>
>>>>>>> Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.
>>>>>>
>>>>>> I can't test GPMC myself, but other than that, this set looks good to go.
>>>>>>
>>>>>
>>>>> Thank you. Would you like more test coverage by other people? I would
>>>>> like to see this in -rc if possible, as it is needed to boot my OMAP4
>>>>> system.
>>>>
>>>> What OMAP4 system is this? Is this a regression for board that already
>>>> has support merged into mainline?
>>>>
>>>
>>> No, it is not yet merged into mainline. I was planning to post the DTS
>>> this week, when most issues are cleared. Looking at the current mainline
>>> boards, no one seems to use the GPMC, so I am just the first one to hit
>>> this issue.
>>
>> OK, well typically the later -rc's are for fixing observed regressions.
>> Since your platform is not yet merged in then it's probably fine to push
>> this for 3.15.
>>
>
> Fair enough. 3.15 is fine.
>
>> This also gives time to test the fix for other OMAP-ish processors.
>>
>
> I can do the v3, including OMAP5 and DRA7. But for DRA7, I will need
> someone with the TRM telling me where is connected gpmc_fclk (Suman?).

For DRA7, GPMC is connected off L3MAIN1_L3_GICLK (compared to 
L3MAIN2_L3_GICLK on OMAP5), both of which are actually just L3_ICLK.
This is the l3_iclk_div in both the omap54xx-clocks.dtsi and 
dra7xx-clocks.dtsi files.

regards
Suman

[PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Suman Anna]

Florian,

On 02/25/2014 02:10 AM, Florian Vaussard wrote:
> On 02/25/2014 07:26 AM, Mike Turquette wrote:
>> Quoting Florian Vaussard (2014-02-23 21:44:25)
>>> On 02/23/2014 10:23 PM, Mike Turquette wrote:
>>>> Quoting Florian Vaussard (2014-02-19 11:26:43)
>>>>>
>>>>> On 02/19/2014 05:22 PM, Tero Kristo wrote:
>>>>>> On 02/19/2014 11:15 AM, Florian Vaussard wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Trying to get my SMSC9221 working on OMAP4 with DT,
>>>>>>> I faced a misconfigured gpmc_fck (dummy clock set to 0)
>>>>>>> resulting in serveral division-by-zero, misconfigured
>>>>>>> timings and driver lost in the La La Land.
>>>>>>>
>>>>>>> To solve this, patch 1 removes gpmc_fck from the dummy
>>>>>>> clocks, and patch 2 adds the gpmc_fck DT node and
>>>>>>> reference it from the gpmc node.
>>>>>>>
>>>>>>> Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.
>>>>>>
>>>>>> I can't test GPMC myself, but other than that, this set looks good to go.
>>>>>>
>>>>>
>>>>> Thank you. Would you like more test coverage by other people? I would
>>>>> like to see this in -rc if possible, as it is needed to boot my OMAP4
>>>>> system.
>>>>
>>>> What OMAP4 system is this? Is this a regression for board that already
>>>> has support merged into mainline?
>>>>
>>>
>>> No, it is not yet merged into mainline. I was planning to post the DTS
>>> this week, when most issues are cleared. Looking at the current mainline
>>> boards, no one seems to use the GPMC, so I am just the first one to hit
>>> this issue.
>>
>> OK, well typically the later -rc's are for fixing observed regressions.
>> Since your platform is not yet merged in then it's probably fine to push
>> this for 3.15.
>>
>
> Fair enough. 3.15 is fine.
>
>> This also gives time to test the fix for other OMAP-ish processors.
>>
>
> I can do the v3, including OMAP5 and DRA7. But for DRA7, I will need
> someone with the TRM telling me where is connected gpmc_fclk (Suman?).

For DRA7, GPMC is connected off L3MAIN1_L3_GICLK (compared to 
L3MAIN2_L3_GICLK on OMAP5), both of which are actually just L3_ICLK.
This is the l3_iclk_div in both the omap54xx-clocks.dtsi and 
dra7xx-clocks.dtsi files.

regards
Suman

Re: [PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Florian Vaussard]

Hi Suman,

On 02/26/2014 01:05 AM, Suman Anna wrote:
> Florian,
> 
> On 02/25/2014 02:10 AM, Florian Vaussard wrote:
>> On 02/25/2014 07:26 AM, Mike Turquette wrote:
>>> Quoting Florian Vaussard (2014-02-23 21:44:25)
>>>> On 02/23/2014 10:23 PM, Mike Turquette wrote:
>>>>> Quoting Florian Vaussard (2014-02-19 11:26:43)
>>>>>>
>>>>>> On 02/19/2014 05:22 PM, Tero Kristo wrote:
>>>>>>> On 02/19/2014 11:15 AM, Florian Vaussard wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Trying to get my SMSC9221 working on OMAP4 with DT,
>>>>>>>> I faced a misconfigured gpmc_fck (dummy clock set to 0)
>>>>>>>> resulting in serveral division-by-zero, misconfigured
>>>>>>>> timings and driver lost in the La La Land.
>>>>>>>>
>>>>>>>> To solve this, patch 1 removes gpmc_fck from the dummy
>>>>>>>> clocks, and patch 2 adds the gpmc_fck DT node and
>>>>>>>> reference it from the gpmc node.
>>>>>>>>
>>>>>>>> Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.
>>>>>>>
>>>>>>> I can't test GPMC myself, but other than that, this set looks
>>>>>>> good to go.
>>>>>>>
>>>>>>
>>>>>> Thank you. Would you like more test coverage by other people? I would
>>>>>> like to see this in -rc if possible, as it is needed to boot my OMAP4
>>>>>> system.
>>>>>
>>>>> What OMAP4 system is this? Is this a regression for board that already
>>>>> has support merged into mainline?
>>>>>
>>>>
>>>> No, it is not yet merged into mainline. I was planning to post the DTS
>>>> this week, when most issues are cleared. Looking at the current
>>>> mainline
>>>> boards, no one seems to use the GPMC, so I am just the first one to hit
>>>> this issue.
>>>
>>> OK, well typically the later -rc's are for fixing observed regressions.
>>> Since your platform is not yet merged in then it's probably fine to push
>>> this for 3.15.
>>>
>>
>> Fair enough. 3.15 is fine.
>>
>>> This also gives time to test the fix for other OMAP-ish processors.
>>>
>>
>> I can do the v3, including OMAP5 and DRA7. But for DRA7, I will need
>> someone with the TRM telling me where is connected gpmc_fclk (Suman?).
> 
> For DRA7, GPMC is connected off L3MAIN1_L3_GICLK (compared to
> L3MAIN2_L3_GICLK on OMAP5), both of which are actually just L3_ICLK.
> This is the l3_iclk_div in both the omap54xx-clocks.dtsi and
> dra7xx-clocks.dtsi files.
> 

Thank you very much. So I will send a v3 including this.

Regards,
Florian

[PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock

[Florian Vaussard]

Hi Suman,

On 02/26/2014 01:05 AM, Suman Anna wrote:
> Florian,
> 
> On 02/25/2014 02:10 AM, Florian Vaussard wrote:
>> On 02/25/2014 07:26 AM, Mike Turquette wrote:
>>> Quoting Florian Vaussard (2014-02-23 21:44:25)
>>>> On 02/23/2014 10:23 PM, Mike Turquette wrote:
>>>>> Quoting Florian Vaussard (2014-02-19 11:26:43)
>>>>>>
>>>>>> On 02/19/2014 05:22 PM, Tero Kristo wrote:
>>>>>>> On 02/19/2014 11:15 AM, Florian Vaussard wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Trying to get my SMSC9221 working on OMAP4 with DT,
>>>>>>>> I faced a misconfigured gpmc_fck (dummy clock set to 0)
>>>>>>>> resulting in serveral division-by-zero, misconfigured
>>>>>>>> timings and driver lost in the La La Land.
>>>>>>>>
>>>>>>>> To solve this, patch 1 removes gpmc_fck from the dummy
>>>>>>>> clocks, and patch 2 adds the gpmc_fck DT node and
>>>>>>>> reference it from the gpmc node.
>>>>>>>>
>>>>>>>> Tested on DuoVero/Parlor (OMAP4430) with SMSC9221.
>>>>>>>
>>>>>>> I can't test GPMC myself, but other than that, this set looks
>>>>>>> good to go.
>>>>>>>
>>>>>>
>>>>>> Thank you. Would you like more test coverage by other people? I would
>>>>>> like to see this in -rc if possible, as it is needed to boot my OMAP4
>>>>>> system.
>>>>>
>>>>> What OMAP4 system is this? Is this a regression for board that already
>>>>> has support merged into mainline?
>>>>>
>>>>
>>>> No, it is not yet merged into mainline. I was planning to post the DTS
>>>> this week, when most issues are cleared. Looking at the current
>>>> mainline
>>>> boards, no one seems to use the GPMC, so I am just the first one to hit
>>>> this issue.
>>>
>>> OK, well typically the later -rc's are for fixing observed regressions.
>>> Since your platform is not yet merged in then it's probably fine to push
>>> this for 3.15.
>>>
>>
>> Fair enough. 3.15 is fine.
>>
>>> This also gives time to test the fix for other OMAP-ish processors.
>>>
>>
>> I can do the v3, including OMAP5 and DRA7. But for DRA7, I will need
>> someone with the TRM telling me where is connected gpmc_fclk (Suman?).
> 
> For DRA7, GPMC is connected off L3MAIN1_L3_GICLK (compared to
> L3MAIN2_L3_GICLK on OMAP5), both of which are actually just L3_ICLK.
> This is the l3_iclk_div in both the omap54xx-clocks.dtsi and
> dra7xx-clocks.dtsi files.
> 

Thank you very much. So I will send a v3 including this.

Regards,
Florian