On Wed, Jan 14, 2015 at 11:10:08PM +, Russell King - ARM Linux wrote:
> On Wed, Jan 14, 2015 at 11:09:26AM -0800, Tony Lindgren wrote:
> > This seems like it could be a similar issue to what we were seeing on
> > omap3 where the legacy IRQ mappings went wrong without using the
> > irq_domain_ad
On Wed, Jan 14, 2015 at 11:09:26AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [150114 09:54]:
> > On Wed, Dec 17, 2014 at 09:52:52AM +, Russell King - ARM Linux wrote:
> > > The "combined" kernel boot follows a similar pattern, but yets a bit
> > > further before oopsing, with AS
* Tony Lindgren [150114 11:16]:
> * Russell King - ARM Linux [150114 09:54]:
> > On Wed, Dec 17, 2014 at 09:52:52AM +, Russell King - ARM Linux wrote:
> > > The "combined" kernel boot follows a similar pattern, but yets a bit
> > > further before oopsing, with ASoC DAPM code printing random b
* Russell King - ARM Linux [150114 09:54]:
> On Wed, Dec 17, 2014 at 09:52:52AM +, Russell King - ARM Linux wrote:
> > The "combined" kernel boot follows a similar pattern, but yets a bit
> > further before oopsing, with ASoC DAPM code printing random bits of
> > kernel memory.
>
> Note that
On Wed, Dec 17, 2014 at 09:52:52AM +, Russell King - ARM Linux wrote:
> The "combined" kernel boot follows a similar pattern, but yets a bit
> further before oopsing, with ASoC DAPM code printing random bits of
> kernel memory.
Note that the "combined" kernel (which is OMAP4 + Versatile Expres
On Wed, Dec 31, 2014 at 04:00:14PM +0200, Peter Ujfalusi wrote:
> On 12/18/2014 01:49 PM, Mark Brown wrote:
> > Right, spot on - I'll send a revert for that upstream. Thanks for
> > tracking this down.
> Mark, can you send the e3b1e6a19e09877b91517dfe304a2b3f6b2138fc (found it in
> linux-next) f
On 12/18/2014 01:49 PM, Mark Brown wrote:
> On Thu, Dec 18, 2014 at 10:16:18AM +, Russell King - ARM Linux wrote:
>
>> So that doesn't work - but importantly, it does point towards a
>> possible culpret - snd_soc_of_parse_audio_routing().
>
>> This is obvious when you stop and think about wha
On 12/18/2014 06:41 PM, Tony Lindgren wrote:
> * Tony Lindgren [141217 09:28]:
>>
>> And then there are these too in the current mainline that are
>> clock related:
>>
>> omap4xxx_dt_clk_init: failed to configure ABE DPLL!
>> ...
>> clock: dpll_abe_ck failed transition to 'locked'
>> clock: dpll_a
* Tony Lindgren [141217 09:28]:
>
> And then there are these too in the current mainline that are
> clock related:
>
> omap4xxx_dt_clk_init: failed to configure ABE DPLL!
> ...
> clock: dpll_abe_ck failed transition to 'locked'
> clock: dpll_abe_ck failed transition to 'locked'
> clock: dpll_abe
On 12/18/2014 01:48 PM, Peter Rosin wrote:
Russel King wrote:
*snip*
Now, we have this call to snd_soc_of_parse_audio_routing(), which
allocates some memory, copies the old routes into it, and then adds
to them from DT. That explains why the pointer and number of routes
are different - there's
Russel King wrote:
*snip*
> Now, we have this call to snd_soc_of_parse_audio_routing(), which
> allocates some memory, copies the old routes into it, and then adds
> to them from DT. That explains why the pointer and number of routes
> are different - there's 19 routes in omap4-sdp.dts - 17 + 19 =
On Thu, Dec 18, 2014 at 10:16:18AM +, Russell King - ARM Linux wrote:
> So that doesn't work - but importantly, it does point towards a
> possible culpret - snd_soc_of_parse_audio_routing().
> This is obvious when you stop and think about what it's doing, this is
> truely where this bug lies,
On Wed, Dec 17, 2014 at 11:08:06PM +0200, Jyri Sarha wrote:
> I tried booting my 4460 Panda - which is the closest thing to 4430SDP that
> I've got - on next-20141217, but I could not get it to the point where the
> omap-abe-twl6040 probed. It probably is the problem you are talking about as
> the
On 12/17/2014 08:51 PM, Russell King - ARM Linux wrote:
On Wed, Dec 17, 2014 at 09:23:33AM -0800, Tony Lindgren wrote:
Hi,
* Russell King - ARM Linux [141217 01:55]:
Tony,
As the IOMMU stuff was merged last night, which removed a really quite
horrid conflict resolution, I updated my nightly
* Tony Lindgren [141217 11:14]:
>
> Also, in your 3430-LDP logs, the DMA setup_irq related "In-band Error"
> is a mystery. I'm not seeing that with omap2plus_defconfig, but can
> reproduce it here with your LDP .config file. Got any ideas on that one?
Hmm it looks like that's some CONFIG_PREEMPT
* Russell King - ARM Linux [141217 10:54]:
> On Wed, Dec 17, 2014 at 09:23:33AM -0800, Tony Lindgren wrote:
> > Hi,
> >
> > * Russell King - ARM Linux [141217 01:55]:
> > > Tony,
> > >
> > > As the IOMMU stuff was merged last night, which removed a really quite
> > > horrid conflict resolution,
On Wed, Dec 17, 2014 at 09:23:33AM -0800, Tony Lindgren wrote:
> Hi,
>
> * Russell King - ARM Linux [141217 01:55]:
> > Tony,
> >
> > As the IOMMU stuff was merged last night, which removed a really quite
> > horrid conflict resolution, I updated my nightly build tree from its
> > previous state
* Nishanth Menon [141217 09:35]:
> On Wed, Dec 17, 2014 at 11:23 AM, Tony Lindgren wrote:
> >
> >> twl: not initialized
> >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
> >> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
> >> twl6030_uv
On Wed, Dec 17, 2014 at 11:23 AM, Tony Lindgren wrote:
>
>> twl: not initialized
>> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
>> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660
>> twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 137
Hi,
* Russell King - ARM Linux [141217 01:55]:
> Tony,
>
> As the IOMMU stuff was merged last night, which removed a really quite
> horrid conflict resolution, I updated my nightly build tree from its
> previous state last Thursday.
>
> Now, SDP4430 seems to be really quite broken.
Sigh, thing
20 matches
Mail list logo
