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 h
* Peter Ujfalusi [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 nee
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'
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
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: OMAP
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 i
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, w
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'
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 (unle
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 th
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: R
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.
Meanwh
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 th
On Wed, 2012-12-19 at 10:32 +, 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
On Wed, 2012-12-19 at 10:28 +, 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 ca
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
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 t
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 drive
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 u
Hi Mark,
On Wed, 2012-12-19 at 09:45 +, 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 drive
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 t
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
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_hsmm
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
-
24 matches
Mail list logo
