32kHz clock removal causes problems omap_hsmmc

32kHz clock removal causes problems omap_hsmmc

[Luciano Coelho]

Hi,

Since the 32KHz clock was removed from the twl-regulator (0e8e5c34
regulator: twl: Remove references to 32kHz clock from DT bindings),
we've been having problems with our wl12xx chip that is connected
through the omap_hsmmc.

Our card simply doesn't get added to the system and we get lots of
-ETIMEOUTs during mmc_attach.  If I revert 0e8e5c34 (plus a couple of
associated patches), everything works fine.

I've been using a Blaze device with a WiLink 1283 chip connected in the
COM (internal) port.  The funny thing is that I don't have the same
problem with a WiLink 1853 chip (which is connected externally to
another Blaze).

Does anyone know what the problem could and how to fix it?

This is a regression that has been there since 3.6-rc1.

--
Cheers,
Luca.

Re: 32kHz clock removal causes problems omap_hsmmc

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

Hi,

On Thu, Nov 15, 2012 at 10:31:33AM +0200, Luciano Coelho wrote:
> Since the 32KHz clock was removed from the twl-regulator (0e8e5c34
> regulator: twl: Remove references to 32kHz clock from DT bindings),
> we've been having problems with our wl12xx chip that is connected
> through the omap_hsmmc.
> 
> Our card simply doesn't get added to the system and we get lots of
> -ETIMEOUTs during mmc_attach.  If I revert 0e8e5c34 (plus a couple of
> associated patches), everything works fine.
> 
> I've been using a Blaze device with a WiLink 1283 chip connected in the
> COM (internal) port.  The funny thing is that I don't have the same
> problem with a WiLink 1853 chip (which is connected externally to
> another Blaze).
> 
> Does anyone know what the problem could and how to fix it?
> 
> This is a regression that has been there since 3.6-rc1.

damn, this is still part of our v3.7-rc kernel. Original commit was done
with no testing whatsoever and caused a big regression to (at least)
TI's WiFi driver which depend on SDIO to function.

Too bad things break and even when reported nobody gives a rat's ***
about them :-s

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: 32kHz clock removal causes problems omap_hsmmc

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

On Tue, Dec 18, 2012 at 11:54:50AM +0200, Felipe Balbi wrote:

> damn, this is still part of our v3.7-rc kernel. Original commit was done
> with no testing whatsoever and caused a big regression to (at least)
> TI's WiFi driver which depend on SDIO to function.

> Too bad things break and even when reported nobody gives a rat's ***
> about them :-s

I guess it's going to be even more of an issue going forward given the
recent events but FWIW it was always very unusual to see any review of
any TWL patches, the PMIC appeared to have been rather abandoned so the
only way of getting any testing was to put stuff in -next and hope.

Mind you, if there is an issue it doesn't seem that serious given that
it took at least one kernel release before anyone noticed and even when
they did you're the first person who bothered to respond...

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: 32kHz clock removal causes problems omap_hsmmc

[Peter Ujfalusi]

On 12/19/2012 10:45 AM, Mark Brown wrote:
> On Tue, Dec 18, 2012 at 11:54:50AM +0200, Felipe Balbi wrote:
> 
>> damn, this is still part of our v3.7-rc kernel. Original commit was done
>> with no testing whatsoever and caused a big regression to (at least)
>> TI's WiFi driver which depend on SDIO to function.
> 
>> Too bad things break and even when reported nobody gives a rat's ***
>> about them :-s
> 
> I guess it's going to be even more of an issue going forward given the
> recent events but FWIW it was always very unusual to see any review of
> any TWL patches, the PMIC appeared to have been rather abandoned so the
> only way of getting any testing was to put stuff in -next and hope.

As for the twl-regulator I still have plan to do a major cleanup there. It is
just sad that it received the DT bindings for the current code. The DT support
addition would have been the perfect place to sanitize it. Now it is just
going to be a huge pain in the back.

As for the 32k clock:
I don't know the state of the common clock framework for OMAPs. Is it already
up in 3.7? Or going for 3.8? 3.9? 3.10?...
We need CCF to resolve this. I can cook up the clock driver for the 32k clock
from twl, but in order to use it we need CCF on OMAP.

-- 
Péter

Re: 32kHz clock removal causes problems omap_hsmmc

[Luciano Coelho]

Hi Mark,

On Wed, 2012-12-19 at 09:45 +0000, Mark Brown wrote:
> On Tue, Dec 18, 2012 at 11:54:50AM +0200, Felipe Balbi wrote:
> 
> > damn, this is still part of our v3.7-rc kernel. Original commit was done
> > with no testing whatsoever and caused a big regression to (at least)
> > TI's WiFi driver which depend on SDIO to function.
> 
> > Too bad things break and even when reported nobody gives a rat's ***
> > about them :-s
> 
> I guess it's going to be even more of an issue going forward given the
> recent events but FWIW it was always very unusual to see any review of
> any TWL patches, the PMIC appeared to have been rather abandoned so the
> only way of getting any testing was to put stuff in -next and hope.

Unfortunately I don't know how many of us are using this specific
platform with the latest kernel, so not much testing is done.


> Mind you, if there is an issue it doesn't seem that serious given that
> it took at least one kernel release before anyone noticed and even when
> they did you're the first person who bothered to respond...

To me it has been very serious.  I had to revert a bunch of patches to
be able to continue working with the mainline.  It took me a while to
see the bug because I've been away during the 3.6 cycle.

I think one of the reasons not many people use the mainline with TWL is
exactly because something seems to break on every new kernel release.
I'm one of those who care and report things when I see them.

I think saying that it is not important because only one person reported
it is not a good excuse.  I would at least have liked seeing an answer
saying, "this can't be fixed because of this and that" or "can you try
to fix it by doing this or that".

--
Cheers,
Luca.

Re: 32kHz clock removal causes problems omap_hsmmc

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

On Wed, Dec 19, 2012 at 11:00:32AM +0100, Peter Ujfalusi wrote:

> I don't know the state of the common clock framework for OMAPs. Is it already
> up in 3.7? Or going for 3.8? 3.9? 3.10?...
> We need CCF to resolve this. I can cook up the clock driver for the 32k clock
> from twl, but in order to use it we need CCF on OMAP.

Well, we at least ought to make sure it doesn't appear in the regulator
DT bindings even if it's handled via some OMAP magic - that was the key
point here.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: 32kHz clock removal causes problems omap_hsmmc

[Peter Ujfalusi]

On 12/19/2012 11:09 AM, Mark Brown wrote:
> On Wed, Dec 19, 2012 at 11:00:32AM +0100, Peter Ujfalusi wrote:
> 
>> I don't know the state of the common clock framework for OMAPs. Is it already
>> up in 3.7? Or going for 3.8? 3.9? 3.10?...
>> We need CCF to resolve this. I can cook up the clock driver for the 32k clock
>> from twl, but in order to use it we need CCF on OMAP.
> 
> Well, we at least ought to make sure it doesn't appear in the regulator
> DT bindings even if it's handled via some OMAP magic - that was the key
> point here.

Sure. It must be a clock driver. I already have similar driver (for McPDM fclk
clock) for twl6040.
Let me check linux-next, if CCF is there for OMAP I can send the 32k clock
driver soon (after writing it and testing it). It is going to be for 3.9 but
we can roll it with us I think locally to resolv issues.

-- 
Péter

Re: 32kHz clock removal causes problems omap_hsmmc

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]

On Wed, Dec 19, 2012 at 12:01:57PM +0200, Luciano Coelho wrote:

> I think one of the reasons not many people use the mainline with TWL is
> exactly because something seems to break on every new kernel release.
> I'm one of those who care and report things when I see them.

Well, it's a recursive thing - nobody works on mainline, nobody reviews
mainline code and therefore you shouldn't be surprised if there's
issues.

> I think saying that it is not important because only one person reported
> it is not a good excuse.  I would at least have liked seeing an answer
> saying, "this can't be fixed because of this and that" or "can you try
> to fix it by doing this or that".

That's not what I'm saying.  What I'm saying is that it's clearly not
the case that OMAP is completely broken here or anything, it appears to
be one particular system which it appears vanishingly few people cared
about in mainline even before all the stuff with TI recently.

Looking at your report the reason I didn't reply myself is most likely
to be a combination of my expectation that someone from TI would look at
OMAP problems (at the time there were hundreds of people working on
OMAP) and the lack of detail in your mail - the bisection report was a
bit unclear as you said that you'd reverted the patch "plus a couple of
associated patches" without saying what exactly you'd backed out and
there was no analysis of the problem to engage with.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: 32kHz clock removal causes problems omap_hsmmc

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

On Wed, Dec 19, 2012 at 11:18:11AM +0100, Peter Ujfalusi wrote:

> Sure. It must be a clock driver. I already have similar driver (for McPDM fclk
> clock) for twl6040.
> Let me check linux-next, if CCF is there for OMAP I can send the 32k clock
> driver soon (after writing it and testing it). It is going to be for 3.9 but
> we can roll it with us I think locally to resolv issues.

Well, we still haven't got the foggiest idea what the actual problem is
beyond that it's probably related to the 32kHz clock in some way (unless
it was one of the other reverts that coincidentally made a difference,
but we don't know what they were) so it's unlikely that just randomly
implementing clock support is going to fix anything immediately here.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: 32kHz clock removal causes problems omap_hsmmc

[Luciano Coelho]

On Wed, 2012-12-19 at 10:28 +0000, Mark Brown wrote:
> On Wed, Dec 19, 2012 at 12:01:57PM +0200, Luciano Coelho wrote:
> 
> > I think one of the reasons not many people use the mainline with TWL is
> > exactly because something seems to break on every new kernel release.
> > I'm one of those who care and report things when I see them.
> 
> Well, it's a recursive thing - nobody works on mainline, nobody reviews
> mainline code and therefore you shouldn't be surprised if there's
> issues.

Sure, it's a vicious circle.  In any case, I still endure using it and
going against the flow. ;)


> > I think saying that it is not important because only one person reported
> > it is not a good excuse.  I would at least have liked seeing an answer
> > saying, "this can't be fixed because of this and that" or "can you try
> > to fix it by doing this or that".
> 
> That's not what I'm saying.  What I'm saying is that it's clearly not
> the case that OMAP is completely broken here or anything, it appears to
> be one particular system which it appears vanishingly few people cared
> about in mainline even before all the stuff with TI recently.

You're right.  I also had problems with MMC in a Pandaboard too, but I
didn't even bother investigating it (yet) because I can use my other
setup.


> Looking at your report the reason I didn't reply myself is most likely
> to be a combination of my expectation that someone from TI would look at
> OMAP problems (at the time there were hundreds of people working on
> OMAP) and the lack of detail in your mail - the bisection report was a
> bit unclear as you said that you'd reverted the patch "plus a couple of
> associated patches" without saying what exactly you'd backed out and
> there was no analysis of the problem to engage with.

Right, my report was a bit vague indeed.  What I meant by "plus a couple
of associated patches" was the things that would break compilation if I
reverted only the patch in question.  Most likely I ended up reverting
your whole patchset.

I didn't provide further analysis because I had already spent too much
time trying to figure out how to get my stuff to work.  Reverting the
patches locally and hoping someone would respond to my report was good
enough for me at the time.

I also agree that someone from OMAP should have picked it up, but my
report went out exactly when the bomb was exploding inside TI.  So that
probably explains it.

--
Cheers,
Luca.

Re: 32kHz clock removal causes problems omap_hsmmc

[Luciano Coelho]

On Wed, 2012-12-19 at 10:32 +0000, Mark Brown wrote:
> On Wed, Dec 19, 2012 at 11:18:11AM +0100, Peter Ujfalusi wrote:
> 
> > Sure. It must be a clock driver. I already have similar driver (for McPDM fclk
> > clock) for twl6040.
> > Let me check linux-next, if CCF is there for OMAP I can send the 32k clock
> > driver soon (after writing it and testing it). It is going to be for 3.9 but
> > we can roll it with us I think locally to resolv issues.
> 
> Well, we still haven't got the foggiest idea what the actual problem is
> beyond that it's probably related to the 32kHz clock in some way (unless
> it was one of the other reverts that coincidentally made a difference,
> but we don't know what they were) so it's unlikely that just randomly
> implementing clock support is going to fix anything immediately here.

This is exactly what I had to revert (as I mentioned in the other email,
I had to revert the other patches otherwise compilation would break):

0e8e5c34 "regulator: twl: Remove references to 32kHz clock from DT bindings"
e76ab829 "regulator: twl: Remove references to the twl4030 regulator"
029dd3ce "regulator: twl: Remove another unused variable warning"

Let me know if you need more info.

--
Luca.

Re: 32kHz clock removal causes problems omap_hsmmc

[Peter Ujfalusi]

On 12/19/2012 11:45 AM, Luciano Coelho wrote:
>> Well, we still haven't got the foggiest idea what the actual problem is
>> beyond that it's probably related to the 32kHz clock in some way (unless
>> it was one of the other reverts that coincidentally made a difference,
>> but we don't know what they were) so it's unlikely that just randomly
>> implementing clock support is going to fix anything immediately here.
> 
> This is exactly what I had to revert (as I mentioned in the other email,
> I had to revert the other patches otherwise compilation would break):
> 
> 0e8e5c34 "regulator: twl: Remove references to 32kHz clock from DT bindings"
> e76ab829 "regulator: twl: Remove references to the twl4030 regulator"
> 029dd3ce "regulator: twl: Remove another unused variable warning"

Yeah. 32k clock is not provided by twl.

As I said I need to take a look at CCF to see if it already there. If it is
clock driver + mapping + patch for wl12xx should fix the issue you are facing.

> Let me know if you need more info.

BTW: have you happened to ubdate u-boot recently? There is a nice easter egg
added there:
f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.

Which means that _essential_ clocks and pads are no longer configured.

-- 
Péter

Re: 32kHz clock removal causes problems omap_hsmmc

[Peter Ujfalusi]

On 12/19/2012 11:56 AM, Peter Ujfalusi wrote:
> BTW: have you happened to ubdate u-boot recently? There is a nice easter egg
> added there:
> f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.
> 
> Which means that _essential_ clocks and pads are no longer configured.

Meanwhile you can try to hack the u-boot to enable the 32k from there. It is
going to stay up since we do not have code to control it in the kernel anymore.

Also do something like this at the same time to get things working:
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index cbc9bdb..b0ff1ec 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -271,4 +271,8 @@

 #define CONFIG_SYS_THUMB_BUILD

+/* Configure all pins and clocks */
+#define CONFIG_SYS_ENABLE_PADS_ALL
+#define CONFIG_SYS_CLOCKS_ENABLE_ALL
+
 #endif /* __CONFIG_OMAP4_COMMON_H */

-- 
Péter

Re: 32kHz clock removal causes problems omap_hsmmc

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
> On 12/19/2012 11:45 AM, Luciano Coelho wrote:

> > 0e8e5c34 "regulator: twl: Remove references to 32kHz clock from DT bindings"
> > e76ab829 "regulator: twl: Remove references to the twl4030 regulator"
> > 029dd3ce "regulator: twl: Remove another unused variable warning"

> Yeah. 32k clock is not provided by twl.

If these changes do anything to the platform I'd expect them to be
leaving the clock enabled instead of disabling it...

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: 32kHz clock removal causes problems omap_hsmmc

[Luciano Coelho]

On Wed, 2012-12-19 at 11:56 +0100, Peter Ujfalusi wrote:
> On 12/19/2012 11:45 AM, Luciano Coelho wrote:
> >> Well, we still haven't got the foggiest idea what the actual problem is
> >> beyond that it's probably related to the 32kHz clock in some way (unless
> >> it was one of the other reverts that coincidentally made a difference,
> >> but we don't know what they were) so it's unlikely that just randomly
> >> implementing clock support is going to fix anything immediately here.
> > 
> > This is exactly what I had to revert (as I mentioned in the other email,
> > I had to revert the other patches otherwise compilation would break):
> > 
> > 0e8e5c34 "regulator: twl: Remove references to 32kHz clock from DT bindings"
> > e76ab829 "regulator: twl: Remove references to the twl4030 regulator"
> > 029dd3ce "regulator: twl: Remove another unused variable warning"
> 
> Yeah. 32k clock is not provided by twl.
> 
> As I said I need to take a look at CCF to see if it already there. If it is
> clock driver + mapping + patch for wl12xx should fix the issue you are facing.
> 
> > Let me know if you need more info.
> 
> BTW: have you happened to ubdate u-boot recently? There is a nice easter egg
> added there:
> f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.
> 
> Which means that _essential_ clocks and pads are no longer configured.

Actually no, I haven't updated my u-boot for a while.  I'll check if
that improves things.

--
Luca.

Re: 32kHz clock removal causes problems omap_hsmmc

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]

Hi,

+Sricharan who commited that

On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
> On 12/19/2012 11:45 AM, Luciano Coelho wrote:
> >> Well, we still haven't got the foggiest idea what the actual problem is
> >> beyond that it's probably related to the 32kHz clock in some way (unless
> >> it was one of the other reverts that coincidentally made a difference,
> >> but we don't know what they were) so it's unlikely that just randomly
> >> implementing clock support is going to fix anything immediately here.
> > 
> > This is exactly what I had to revert (as I mentioned in the other email,
> > I had to revert the other patches otherwise compilation would break):
> > 
> > 0e8e5c34 "regulator: twl: Remove references to 32kHz clock from DT bindings"
> > e76ab829 "regulator: twl: Remove references to the twl4030 regulator"
> > 029dd3ce "regulator: twl: Remove another unused variable warning"
> 
> Yeah. 32k clock is not provided by twl.
> 
> As I said I need to take a look at CCF to see if it already there. If it is
> clock driver + mapping + patch for wl12xx should fix the issue you are facing.
> 
> > Let me know if you need more info.
> 
> BTW: have you happened to ubdate u-boot recently? There is a nice easter egg
> added there:
> f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.
> 
> Which means that _essential_ clocks and pads are no longer configured.

anything essential you can list ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: 32kHz clock removal causes problems omap_hsmmc

[Benoit Cousson]

On 12/19/2012 02:01 PM, Felipe Balbi wrote:
> Hi,
> 
> +Sricharan who commited that
> 
> On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
>> On 12/19/2012 11:45 AM, Luciano Coelho wrote:
>>>> Well, we still haven't got the foggiest idea what the actual problem is
>>>> beyond that it's probably related to the 32kHz clock in some way (unless
>>>> it was one of the other reverts that coincidentally made a difference,
>>>> but we don't know what they were) so it's unlikely that just randomly
>>>> implementing clock support is going to fix anything immediately here.
>>>
>>> This is exactly what I had to revert (as I mentioned in the other email,
>>> I had to revert the other patches otherwise compilation would break):
>>>
>>> 0e8e5c34 "regulator: twl: Remove references to 32kHz clock from DT bindings"
>>> e76ab829 "regulator: twl: Remove references to the twl4030 regulator"
>>> 029dd3ce "regulator: twl: Remove another unused variable warning"
>>
>> Yeah. 32k clock is not provided by twl.
>>
>> As I said I need to take a look at CCF to see if it already there. If it is
>> clock driver + mapping + patch for wl12xx should fix the issue you are facing.
>>
>>> Let me know if you need more info.
>>
>> BTW: have you happened to ubdate u-boot recently? There is a nice easter egg
>> added there:
>> f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.
>>
>> Which means that _essential_ clocks and pads are no longer configured.
> 
> anything essential you can list ?

Yeah, that u-boot version is just unusable at all with any mainline
kernel, since we are still missing pads conf for every drivers.

Regarding the 32k clock, I noticed as well that the OMAP4460 panda
u-boot is the only one to enable it at boot time, and thus this is the
only board that can probe the wilink chip properly as of today.

Regards,
Benoit

Re: 32kHz clock removal causes problems omap_hsmmc

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2088 bytes --]

Hi,

On Wed, Dec 19, 2012 at 02:51:14PM +0100, Benoit Cousson wrote:
> On 12/19/2012 02:01 PM, Felipe Balbi wrote:
> > Hi,
> > 
> > +Sricharan who commited that
> > 
> > On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
> >> On 12/19/2012 11:45 AM, Luciano Coelho wrote:
> >>>> Well, we still haven't got the foggiest idea what the actual problem is
> >>>> beyond that it's probably related to the 32kHz clock in some way (unless
> >>>> it was one of the other reverts that coincidentally made a difference,
> >>>> but we don't know what they were) so it's unlikely that just randomly
> >>>> implementing clock support is going to fix anything immediately here.
> >>>
> >>> This is exactly what I had to revert (as I mentioned in the other email,
> >>> I had to revert the other patches otherwise compilation would break):
> >>>
> >>> 0e8e5c34 "regulator: twl: Remove references to 32kHz clock from DT bindings"
> >>> e76ab829 "regulator: twl: Remove references to the twl4030 regulator"
> >>> 029dd3ce "regulator: twl: Remove another unused variable warning"
> >>
> >> Yeah. 32k clock is not provided by twl.
> >>
> >> As I said I need to take a look at CCF to see if it already there. If it is
> >> clock driver + mapping + patch for wl12xx should fix the issue you are facing.
> >>
> >>> Let me know if you need more info.
> >>
> >> BTW: have you happened to ubdate u-boot recently? There is a nice easter egg
> >> added there:
> >> f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.
> >>
> >> Which means that _essential_ clocks and pads are no longer configured.
> > 
> > anything essential you can list ?
> 
> Yeah, that u-boot version is just unusable at all with any mainline
> kernel, since we are still missing pads conf for every drivers.
> 
> Regarding the 32k clock, I noticed as well that the OMAP4460 panda
> u-boot is the only one to enable it at boot time, and thus this is the
> only board that can probe the wilink chip properly as of today.

hah, way to cause regression

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: 32kHz clock removal causes problems omap_hsmmc

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 421 bytes --]

On Wed, Dec 19, 2012 at 02:51:14PM +0100, Benoit Cousson wrote:

> Regarding the 32k clock, I noticed as well that the OMAP4460 panda
> u-boot is the only one to enable it at boot time, and thus this is the
> only board that can probe the wilink chip properly as of today.

Well, there was nothing in the code that was disabled which would have
turned on the 32kHz clock and no references to it in the standard
kernel...

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: 32kHz clock removal causes problems omap_hsmmc

[Luciano Coelho]

On Wed, 2012-12-19 at 14:51 +0100, Benoit Cousson wrote:
> On 12/19/2012 02:01 PM, Felipe Balbi wrote:
> > On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
> >> BTW: have you happened to ubdate u-boot recently? There is a nice easter egg
> >> added there:
> >> f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.
> >>
> >> Which means that _essential_ clocks and pads are no longer configured.
> > 
> > anything essential you can list ?
> 
> Yeah, that u-boot version is just unusable at all with any mainline
> kernel, since we are still missing pads conf for every drivers.
> 
> Regarding the 32k clock, I noticed as well that the OMAP4460 panda
> u-boot is the only one to enable it at boot time, and thus this is the
> only board that can probe the wilink chip properly as of today.

Do you mean that with the latest mainline u-boot all boards will have
trouble except panda?

I'm still reorganizing everything and update my stuff with the latest
mainline u-boot, but at least blaze and panda now boot and recognize
their wilink chips (with the patches I mentioned reverted).

Now I'll try to remove my reverts and see what happens.

--
Luca.

Re: 32kHz clock removal causes problems omap_hsmmc

[Benoit Cousson]

On 12/19/2012 02:58 PM, Luciano Coelho wrote:
> On Wed, 2012-12-19 at 14:51 +0100, Benoit Cousson wrote:
>> On 12/19/2012 02:01 PM, Felipe Balbi wrote:
>>> On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
>>>> BTW: have you happened to ubdate u-boot recently? There is a nice easter egg
>>>> added there:
>>>> f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.
>>>>
>>>> Which means that _essential_ clocks and pads are no longer configured.
>>>
>>> anything essential you can list ?
>>
>> Yeah, that u-boot version is just unusable at all with any mainline
>> kernel, since we are still missing pads conf for every drivers.
>>
>> Regarding the 32k clock, I noticed as well that the OMAP4460 panda
>> u-boot is the only one to enable it at boot time, and thus this is the
>> only board that can probe the wilink chip properly as of today.
> 
> Do you mean that with the latest mainline u-boot all boards will have
> trouble except panda?

I don't know since the u-boot mainline has never ever supported properly
the SDP4430, I stopped wasting my time with that code a long time ago.
But the braves who tried using the latest u-boot mainline code that does
not configure anything anymore had some troubles...

Benoit

Re: 32kHz clock removal causes problems omap_hsmmc

[Peter Ujfalusi]

On 12/19/2012 02:01 PM, Felipe Balbi wrote:
> Hi,
> 
> +Sricharan who commited that
> 
> On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
>> On 12/19/2012 11:45 AM, Luciano Coelho wrote:
>>>> Well, we still haven't got the foggiest idea what the actual problem is
>>>> beyond that it's probably related to the 32kHz clock in some way (unless
>>>> it was one of the other reverts that coincidentally made a difference,
>>>> but we don't know what they were) so it's unlikely that just randomly
>>>> implementing clock support is going to fix anything immediately here.
>>>
>>> This is exactly what I had to revert (as I mentioned in the other email,
>>> I had to revert the other patches otherwise compilation would break):
>>>
>>> 0e8e5c34 "regulator: twl: Remove references to 32kHz clock from DT bindings"
>>> e76ab829 "regulator: twl: Remove references to the twl4030 regulator"
>>> 029dd3ce "regulator: twl: Remove another unused variable warning"
>>
>> Yeah. 32k clock is not provided by twl.
>>
>> As I said I need to take a look at CCF to see if it already there. If it is
>> clock driver + mapping + patch for wl12xx should fix the issue you are facing.
>>
>>> Let me know if you need more info.
>>
>> BTW: have you happened to ubdate u-boot recently? There is a nice easter egg
>> added there:
>> f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.
>>
>> Which means that _essential_ clocks and pads are no longer configured.
> 
> anything essential you can list ?

Depends on the definition of essential.
Serial and mmc works.
I said it was an easter egg since it was... well... quite a bit of surprise
that the same kernel started to fail for example in all audio operation when I
updated the u-boot, which I tend to do every now and then to see if there are
no regression.

So it was a nice surprise. Even the commit message agreed that it is going to
break the drivers:

    Note that this is going to break the kernel drivers. But this
    is the only way to get things fixed in the kernel.

Usually if I know I will going to break something intentionally I tend to send
warnings and give some grace periods for the interested guys to adopt.

And this is why people are not testing u-boot. We tend to have one working
binary moving from SD card to other and update it only, __only__ when it can
not be avoided.

If we work together, we should work together...

Do not take it personal. I just had tough days...

-- 
Péter

Re: 32kHz clock removal causes problems omap_hsmmc

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@ti.com> [121219 02:20]:
> On 12/19/2012 11:09 AM, Mark Brown wrote:
> > On Wed, Dec 19, 2012 at 11:00:32AM +0100, Peter Ujfalusi wrote:
> > 
> >> I don't know the state of the common clock framework for OMAPs. Is it already
> >> up in 3.7? Or going for 3.8? 3.9? 3.10?...
> >> We need CCF to resolve this. I can cook up the clock driver for the 32k clock
> >> from twl, but in order to use it we need CCF on OMAP.
> > 
> > Well, we at least ought to make sure it doesn't appear in the regulator
> > DT bindings even if it's handled via some OMAP magic - that was the key
> > point here.
> 
> Sure. It must be a clock driver. I already have similar driver (for McPDM fclk
> clock) for twl6040.
> Let me check linux-next, if CCF is there for OMAP I can send the 32k clock
> driver soon (after writing it and testing it). It is going to be for 3.9 but
> we can roll it with us I think locally to resolv issues.

The omap common clock patches are now in mainline kernel as of v3.8
merge window.

Tony

Re: 32kHz clock removal causes problems omap_hsmmc

[R Sricharan]

Hi,

On Wednesday 19 December 2012 07:34 PM, Benoit Cousson wrote:
> On 12/19/2012 02:58 PM, Luciano Coelho wrote:
>> On Wed, 2012-12-19 at 14:51 +0100, Benoit Cousson wrote:
>>> On 12/19/2012 02:01 PM, Felipe Balbi wrote:
>>>> On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
>>>>> BTW: have you happened to ubdate u-boot recently? There is a nice easter egg
>>>>> added there:
>>>>> f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.
>>>>>
>>>>> Which means that _essential_ clocks and pads are no longer configured.
>>>>
>>>> anything essential you can list ?
>>>
>>> Yeah, that u-boot version is just unusable at all with any mainline
>>> kernel, since we are still missing pads conf for every drivers.
>>>
>>> Regarding the 32k clock, I noticed as well that the OMAP4460 panda
>>> u-boot is the only one to enable it at boot time, and thus this is the
>>> only board that can probe the wilink chip properly as of today.
>>
>> Do you mean that with the latest mainline u-boot all boards will have
>> trouble except panda?
>
> I don't know since the u-boot mainline has never ever supported properly
> the SDP4430, I stopped wasting my time with that code a long time ago.
> But the braves who tried using the latest u-boot mainline code that does
> not configure anything anymore had some troubles...
>
   Configuring every pad and clocks in the u-boot was removed to
   force kernel drivers to fix up things. Dependency on boot loader
   was always a problem. Bootloader should not configure anything apart
   from what is required for boot.

Regards,
  Sricharan