Boot time errors/warnings on snowball

Boot time errors/warnings on snowball

[Olof Johansson]

Hi,

I noticed these with last night's -next on the snowball:

of_dma_request_slave_channel: dma-names property of node
'/soc/msp at 80124000' missing or empty
of_dma_request_slave_channel: dma-names property of node
'/soc/msp at 80124000' missing or empty
of_dma_request_slave_channel: dma-names property of node
'/soc/msp at 80125000' missing or empty
of_dma_request_slave_channel: dma-names property of node
'/soc/msp at 80125000' missing or empty
dma dma0chan22: [d40_config_memcpy] No memcpy
dma dma0chan22: [d40_alloc_chan_resources] Failed to configure memcpy channel
ux500-msp-i2s ux500-msp-i2s.1: Missing dma channel for stream: 0
ux500-msp-i2s ux500-msp-i2s.1: ASoC: pcm constructor failed: -22



-Olof

Boot time errors/warnings on snowball

[Linus Walleij]

On Wed, Dec 4, 2013 at 5:37 PM, Olof Johansson <olof@lixom.net> wrote:

> I noticed these with last night's -next on the snowball:
>
> of_dma_request_slave_channel: dma-names property of node
> '/soc/msp at 80124000' missing or empty
> of_dma_request_slave_channel: dma-names property of node
> '/soc/msp at 80124000' missing or empty
> of_dma_request_slave_channel: dma-names property of node
> '/soc/msp at 80125000' missing or empty
> of_dma_request_slave_channel: dma-names property of node
> '/soc/msp at 80125000' missing or empty
> dma dma0chan22: [d40_config_memcpy] No memcpy
> dma dma0chan22: [d40_alloc_chan_resources] Failed to configure memcpy channel
> ux500-msp-i2s ux500-msp-i2s.1: Missing dma channel for stream: 0
> ux500-msp-i2s ux500-msp-i2s.1: ASoC: pcm constructor failed: -22

I don't see this when booting from the stuff I sent for v3.14,
but I know Mark applied some fixes from Lee yesterday,
Lee can you see if you recognize this?

Yours,
Linus Walleij

Boot time errors/warnings on snowball

[Lee Jones]

> > I noticed these with last night's -next on the snowball:
> >
> > of_dma_request_slave_channel: dma-names property of node
> > '/soc/msp at 80124000' missing or empty
> > of_dma_request_slave_channel: dma-names property of node
> > '/soc/msp at 80124000' missing or empty
> > of_dma_request_slave_channel: dma-names property of node
> > '/soc/msp at 80125000' missing or empty
> > of_dma_request_slave_channel: dma-names property of node
> > '/soc/msp at 80125000' missing or empty
> > dma dma0chan22: [d40_config_memcpy] No memcpy`
> > dma dma0chan22: [d40_alloc_chan_resources] Failed to configure memcpy channel
> > ux500-msp-i2s ux500-msp-i2s.1: Missing dma channel for stream: 0
> > ux500-msp-i2s ux500-msp-i2s.1: ASoC: pcm constructor failed: -22
> 
> I don't see this when booting from the stuff I sent for v3.14,
> but I know Mark applied some fixes from Lee yesterday,
> Lee can you see if you recognize this?

It looks like whatever tree you're building from is missing this patch:
  
  ARM: ux500: Add DMA config bindings for MSP devices

Which is part of the initial reason I said this:

  "If this patch-set could go through ASoC as a whole, it would drive
  down the chance of a dependency mess. Vinod has already provided
  Acks for his parts, so it's just between you two Linus and Mark."

But in Mark's defence, I also tentatively said this:

  "I'm not aware of any dependencies on the ARM changes. I haven't
  tested the arch/arm and sound/soc adaptions orthogonally, but I
  _think_ the right decisions should be made depending on the
  information passed from platform/dt code."

But this error seems strange, as I thought we were still passing the
MSP stuff as AUXDATA for this very reason i.e. lack of DMA support. So
I assumed that the MSP driver(s) would take the platform data
route. At least until the AUXDATAs have been removed, which was my
next step.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Boot time errors/warnings on snowball

[Olof Johansson]

On Wed, Dec 4, 2013 at 9:26 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> > I noticed these with last night's -next on the snowball:
>> >
>> > of_dma_request_slave_channel: dma-names property of node
>> > '/soc/msp at 80124000' missing or empty
>> > of_dma_request_slave_channel: dma-names property of node
>> > '/soc/msp at 80124000' missing or empty
>> > of_dma_request_slave_channel: dma-names property of node
>> > '/soc/msp at 80125000' missing or empty
>> > of_dma_request_slave_channel: dma-names property of node
>> > '/soc/msp at 80125000' missing or empty
>> > dma dma0chan22: [d40_config_memcpy] No memcpy`
>> > dma dma0chan22: [d40_alloc_chan_resources] Failed to configure memcpy channel
>> > ux500-msp-i2s ux500-msp-i2s.1: Missing dma channel for stream: 0
>> > ux500-msp-i2s ux500-msp-i2s.1: ASoC: pcm constructor failed: -22
>>
>> I don't see this when booting from the stuff I sent for v3.14,
>> but I know Mark applied some fixes from Lee yesterday,
>> Lee can you see if you recognize this?
>
> It looks like whatever tree you're building from is missing this patch:
>
>   ARM: ux500: Add DMA config bindings for MSP devices

FWIW, this was with next-20131204.


-Olof

Boot time errors/warnings on snowball

[Olof Johansson]

On Wed, Dec 4, 2013 at 9:26 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> > I noticed these with last night's -next on the snowball:
>> >
>> > of_dma_request_slave_channel: dma-names property of node
>> > '/soc/msp at 80124000' missing or empty
>> > of_dma_request_slave_channel: dma-names property of node
>> > '/soc/msp at 80124000' missing or empty
>> > of_dma_request_slave_channel: dma-names property of node
>> > '/soc/msp at 80125000' missing or empty
>> > of_dma_request_slave_channel: dma-names property of node
>> > '/soc/msp at 80125000' missing or empty
>> > dma dma0chan22: [d40_config_memcpy] No memcpy`
>> > dma dma0chan22: [d40_alloc_chan_resources] Failed to configure memcpy channel
>> > ux500-msp-i2s ux500-msp-i2s.1: Missing dma channel for stream: 0
>> > ux500-msp-i2s ux500-msp-i2s.1: ASoC: pcm constructor failed: -22
>>
>> I don't see this when booting from the stuff I sent for v3.14,
>> but I know Mark applied some fixes from Lee yesterday,
>> Lee can you see if you recognize this?
>
> It looks like whatever tree you're building from is missing this patch:
>
>   ARM: ux500: Add DMA config bindings for MSP devices
>
> Which is part of the initial reason I said this:
>
>   "If this patch-set could go through ASoC as a whole, it would drive
>   down the chance of a dependency mess. Vinod has already provided
>   Acks for his parts, so it's just between you two Linus and Mark."
>
> But in Mark's defence, I also tentatively said this:
>
>   "I'm not aware of any dependencies on the ARM changes. I haven't
>   tested the arch/arm and sound/soc adaptions orthogonally, but I
>   _think_ the right decisions should be made depending on the
>   information passed from platform/dt code."
>
> But this error seems strange, as I thought we were still passing the
> MSP stuff as AUXDATA for this very reason i.e. lack of DMA support. So
> I assumed that the MSP driver(s) would take the platform data
> route. At least until the AUXDATAs have been removed, which was my
> next step.

By the way, if these things keep happening, then it's an indicator
that you should slow down the rate of change a bit and make sure
things are tested properly. You get a lot of patches produced quickly,
which is awesome, but please make sure things are coordinated and
tested especially for the more complex and inter-dependent changes
like these. If it needs to take another release (or just another week
or two) to get something staged in the right order, then that's OK.


-Olof

Boot time errors/warnings on snowball

[Lee Jones]

On Wed, 04 Dec 2013, Olof Johansson wrote:

> On Wed, Dec 4, 2013 at 9:26 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >> > I noticed these with last night's -next on the snowball:
> >> >
> >> > of_dma_request_slave_channel: dma-names property of node
> >> > '/soc/msp at 80124000' missing or empty
> >> > of_dma_request_slave_channel: dma-names property of node
> >> > '/soc/msp at 80124000' missing or empty
> >> > of_dma_request_slave_channel: dma-names property of node
> >> > '/soc/msp at 80125000' missing or empty
> >> > of_dma_request_slave_channel: dma-names property of node
> >> > '/soc/msp at 80125000' missing or empty
> >> > dma dma0chan22: [d40_config_memcpy] No memcpy`
> >> > dma dma0chan22: [d40_alloc_chan_resources] Failed to configure memcpy channel
> >> > ux500-msp-i2s ux500-msp-i2s.1: Missing dma channel for stream: 0
> >> > ux500-msp-i2s ux500-msp-i2s.1: ASoC: pcm constructor failed: -22
> >>
> >> I don't see this when booting from the stuff I sent for v3.14,
> >> but I know Mark applied some fixes from Lee yesterday,
> >> Lee can you see if you recognize this?
> >
> > It looks like whatever tree you're building from is missing this patch:
> >
> >   ARM: ux500: Add DMA config bindings for MSP devices
> 
> FWIW, this was with next-20131204.

$ git log --oneline --grep="Add DMA config bindings for MSP devices" \
  next-20131204 | wc -l
0

$ git log --oneline --grep="Add DMA config bindings for MSP devices" \
  arm-soc/for-next | wc -l
1

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Boot time errors/warnings on snowball

[Olof Johansson]

On Wed, Dec 4, 2013 at 9:38 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Wed, 04 Dec 2013, Olof Johansson wrote:
>
>> On Wed, Dec 4, 2013 at 9:26 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> >> > I noticed these with last night's -next on the snowball:
>> >> >
>> >> > of_dma_request_slave_channel: dma-names property of node
>> >> > '/soc/msp at 80124000' missing or empty
>> >> > of_dma_request_slave_channel: dma-names property of node
>> >> > '/soc/msp at 80124000' missing or empty
>> >> > of_dma_request_slave_channel: dma-names property of node
>> >> > '/soc/msp at 80125000' missing or empty
>> >> > of_dma_request_slave_channel: dma-names property of node
>> >> > '/soc/msp at 80125000' missing or empty
>> >> > dma dma0chan22: [d40_config_memcpy] No memcpy`
>> >> > dma dma0chan22: [d40_alloc_chan_resources] Failed to configure memcpy channel
>> >> > ux500-msp-i2s ux500-msp-i2s.1: Missing dma channel for stream: 0
>> >> > ux500-msp-i2s ux500-msp-i2s.1: ASoC: pcm constructor failed: -22
>> >>
>> >> I don't see this when booting from the stuff I sent for v3.14,
>> >> but I know Mark applied some fixes from Lee yesterday,
>> >> Lee can you see if you recognize this?
>> >
>> > It looks like whatever tree you're building from is missing this patch:
>> >
>> >   ARM: ux500: Add DMA config bindings for MSP devices
>>
>> FWIW, this was with next-20131204.
>
> $ git log --oneline --grep="Add DMA config bindings for MSP devices" \
>   next-20131204 | wc -l
> 0
>
> $ git log --oneline --grep="Add DMA config bindings for MSP devices" \
>   arm-soc/for-next | wc -l
> 1

Ah, yes, with winter time Stephen pulls -next branches earlier than I
am used to, the set of merges I did yesterday didn't make it in.
Sounds good.


-Olof

Boot time errors/warnings on snowball

[Lee Jones]

> >> > I noticed these with last night's -next on the snowball:
> >> >
> >> > of_dma_request_slave_channel: dma-names property of node
> >> > '/soc/msp at 80124000' missing or empty
> >> > of_dma_request_slave_channel: dma-names property of node
> >> > '/soc/msp at 80124000' missing or empty
> >> > of_dma_request_slave_channel: dma-names property of node
> >> > '/soc/msp at 80125000' missing or empty
> >> > of_dma_request_slave_channel: dma-names property of node
> >> > '/soc/msp at 80125000' missing or empty
> >> > dma dma0chan22: [d40_config_memcpy] No memcpy`
> >> > dma dma0chan22: [d40_alloc_chan_resources] Failed to configure memcpy channel
> >> > ux500-msp-i2s ux500-msp-i2s.1: Missing dma channel for stream: 0
> >> > ux500-msp-i2s ux500-msp-i2s.1: ASoC: pcm constructor failed: -22
> >>
> >> I don't see this when booting from the stuff I sent for v3.14,
> >> but I know Mark applied some fixes from Lee yesterday,
> >> Lee can you see if you recognize this?
> >
> > It looks like whatever tree you're building from is missing this patch:
> >
> >   ARM: ux500: Add DMA config bindings for MSP devices
> >
> > Which is part of the initial reason I said this:
> >
> >   "If this patch-set could go through ASoC as a whole, it would drive
> >   down the chance of a dependency mess. Vinod has already provided
> >   Acks for his parts, so it's just between you two Linus and Mark."
> >
> > But in Mark's defence, I also tentatively said this:
> >
> >   "I'm not aware of any dependencies on the ARM changes. I haven't
> >   tested the arch/arm and sound/soc adaptions orthogonally, but I
> >   _think_ the right decisions should be made depending on the
> >   information passed from platform/dt code."
> >
> > But this error seems strange, as I thought we were still passing the
> > MSP stuff as AUXDATA for this very reason i.e. lack of DMA support. So
> > I assumed that the MSP driver(s) would take the platform data
> > route. At least until the AUXDATAs have been removed, which was my
> > next step.
> 
> By the way, if these things keep happening, then it's an indicator
> that you should slow down the rate of change a bit and make sure
> things are tested properly. You get a lot of patches produced quickly,
> which is awesome, but please make sure things are coordinated and
> tested especially for the more complex and inter-dependent changes
> like these. If it needs to take another release (or just another week
> or two) to get something staged in the right order, then that's OK.

I know that you've had a bee in your bonnet about the rate of which I
sent patches for a while, but this instance has nothing to do with
rushing. This is merely an ordering issue and the speed in which
varying subsystems are merged into -next.

This is what -next is for though right? To identify these kinds of
decencies before they're merged into Mainline. So let's do something
about it now. I'm not sure what though, as I know that Mark isn't fond
of rebasing his tree.

Ideally we should have setup an immutable branch between ASoC and
either ux500 or ARM-SoC where both parties can pull from. That's what
Mark and I usually do when ASoC/Regulators and MFD have dependencies
on one another.

It might not even be an issue though. We just need to ensure that
Linus pulls from ARM-SoC prior to ASoC during the next merge
window. Can that be done?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Boot time errors/warnings on snowball

[Olof Johansson]

On Wed, Dec 4, 2013 at 9:51 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> >> > I noticed these with last night's -next on the snowball:
>> >> >
>> >> > of_dma_request_slave_channel: dma-names property of node
>> >> > '/soc/msp at 80124000' missing or empty
>> >> > of_dma_request_slave_channel: dma-names property of node
>> >> > '/soc/msp at 80124000' missing or empty
>> >> > of_dma_request_slave_channel: dma-names property of node
>> >> > '/soc/msp at 80125000' missing or empty
>> >> > of_dma_request_slave_channel: dma-names property of node
>> >> > '/soc/msp at 80125000' missing or empty
>> >> > dma dma0chan22: [d40_config_memcpy] No memcpy`
>> >> > dma dma0chan22: [d40_alloc_chan_resources] Failed to configure memcpy channel
>> >> > ux500-msp-i2s ux500-msp-i2s.1: Missing dma channel for stream: 0
>> >> > ux500-msp-i2s ux500-msp-i2s.1: ASoC: pcm constructor failed: -22
>> >>
>> >> I don't see this when booting from the stuff I sent for v3.14,
>> >> but I know Mark applied some fixes from Lee yesterday,
>> >> Lee can you see if you recognize this?
>> >
>> > It looks like whatever tree you're building from is missing this patch:
>> >
>> >   ARM: ux500: Add DMA config bindings for MSP devices
>> >
>> > Which is part of the initial reason I said this:
>> >
>> >   "If this patch-set could go through ASoC as a whole, it would drive
>> >   down the chance of a dependency mess. Vinod has already provided
>> >   Acks for his parts, so it's just between you two Linus and Mark."
>> >
>> > But in Mark's defence, I also tentatively said this:
>> >
>> >   "I'm not aware of any dependencies on the ARM changes. I haven't
>> >   tested the arch/arm and sound/soc adaptions orthogonally, but I
>> >   _think_ the right decisions should be made depending on the
>> >   information passed from platform/dt code."
>> >
>> > But this error seems strange, as I thought we were still passing the
>> > MSP stuff as AUXDATA for this very reason i.e. lack of DMA support. So
>> > I assumed that the MSP driver(s) would take the platform data
>> > route. At least until the AUXDATAs have been removed, which was my
>> > next step.
>>
>> By the way, if these things keep happening, then it's an indicator
>> that you should slow down the rate of change a bit and make sure
>> things are tested properly. You get a lot of patches produced quickly,
>> which is awesome, but please make sure things are coordinated and
>> tested especially for the more complex and inter-dependent changes
>> like these. If it needs to take another release (or just another week
>> or two) to get something staged in the right order, then that's OK.
>
> I know that you've had a bee in your bonnet about the rate of which I
> sent patches for a while, but this instance has nothing to do with
> rushing. This is merely an ordering issue and the speed in which
> varying subsystems are merged into -next.

I don't have a problem with the rate of change, but it can easily
become error prone with too many patches in flight which is my main
concern. I'm just asking you to be careful, I'm not saying you're
doing anything wrong. It's great to see these conversions happening!

> This is what -next is for though right? To identify these kinds of
> decencies before they're merged into Mainline. So let's do something
> about it now. I'm not sure what though, as I know that Mark isn't fond
> of rebasing his tree.

This is exactly what -next is for, and that's why I'm reporting the
issue so it can be resolved. Since it's been fixed by an existing
patch, all is good. But it does bring up the below, which is good to
cover here:

> Ideally we should have setup an immutable branch between ASoC and
> either ux500 or ARM-SoC where both parties can pull from. That's what
> Mark and I usually do when ASoC/Regulators and MFD have dependencies
> on one another.
>
> It might not even be an issue though. We just need to ensure that
> Linus pulls from ARM-SoC prior to ASoC during the next merge
> window. Can that be done?

It can be done. It's unfortunate to lose bisectability though (since
when you bisect you can end up in a state where the ASoC patches are
enabled but not the ux500 counterparts. Setting up a shared branch is
indeed the best (only) way to solve that. Next time around we should
do so.

We're usually fairly quick at merging our branches during the merge
window, so sequencing should be fine. Even if Mark does his pull
requests before us, the window of breakage should be minimal (and
we're now aware of it).


-Olof

Boot time errors/warnings on snowball

[Lee Jones]

> >> By the way, if these things keep happening, then it's an indicator
> >> that you should slow down the rate of change a bit and make sure
> >> things are tested properly. You get a lot of patches produced quickly,
> >> which is awesome, but please make sure things are coordinated and
> >> tested especially for the more complex and inter-dependent changes
> >> like these. If it needs to take another release (or just another week
> >> or two) to get something staged in the right order, then that's OK.
> >
> > I know that you've had a bee in your bonnet about the rate of which I
> > sent patches for a while, but this instance has nothing to do with
> > rushing. This is merely an ordering issue and the speed in which
> > varying subsystems are merged into -next.
> 
> I don't have a problem with the rate of change, but it can easily
> become error prone with too many patches in flight which is my main
> concern. I'm just asking you to be careful, I'm not saying you're
> doing anything wrong. It's great to see these conversions happening!
> 
> > This is what -next is for though right? To identify these kinds of
> > decencies before they're merged into Mainline. So let's do something
> > about it now. I'm not sure what though, as I know that Mark isn't fond
> > of rebasing his tree.
> 
> This is exactly what -next is for, and that's why I'm reporting the
> issue so it can be resolved. Since it's been fixed by an existing
> patch, all is good. But it does bring up the below, which is good to
> cover here:
> 
> > Ideally we should have setup an immutable branch between ASoC and
> > either ux500 or ARM-SoC where both parties can pull from. That's what
> > Mark and I usually do when ASoC/Regulators and MFD have dependencies
> > on one another.
> >
> > It might not even be an issue though. We just need to ensure that
> > Linus pulls from ARM-SoC prior to ASoC during the next merge
> > window. Can that be done?
> 
> It can be done. It's unfortunate to lose bisectability though (since
> when you bisect you can end up in a state where the ASoC patches are
> enabled but not the ux500 counterparts. Setting up a shared branch is
> indeed the best (only) way to solve that. Next time around we should
> do so.
> 
> We're usually fairly quick at merging our branches during the merge
> window, so sequencing should be fine. Even if Mark does his pull
> requests before us, the window of breakage should be minimal (and
> we're now aware of it).

FWIW, I agree with everything you said.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Boot time errors/warnings on snowball

[Mark Brown]

On Wed, Dec 04, 2013 at 09:58:29AM -0800, Olof Johansson wrote:

> It can be done. It's unfortunate to lose bisectability though (since
> when you bisect you can end up in a state where the ASoC patches are
> enabled but not the ux500 counterparts. Setting up a shared branch is
> indeed the best (only) way to solve that. Next time around we should
> do so.

Right, that's why I asked about dependencies for the ASoC patch.

> We're usually fairly quick at merging our branches during the merge
> window, so sequencing should be fine. Even if Mark does his pull
> requests before us, the window of breakage should be minimal (and
> we're now aware of it).

If there's a topic branch for the ARM side I can pull it into ASoC to
get the window down to a few commits (or even rebase the ux500 stuff
onto it to remove it).  Or I can sign the ux500 branch for arm-soc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131204/f1bea071/attachment.sig>

Boot time errors/warnings on snowball

[Russell King - ARM Linux]

On Wed, Dec 04, 2013 at 05:51:19PM +0000, Lee Jones wrote:
> I know that you've had a bee in your bonnet about the rate of which I
> sent patches for a while, but this instance has nothing to do with
> rushing. This is merely an ordering issue and the speed in which
> varying subsystems are merged into -next.
> 
> This is what -next is for though right? To identify these kinds of
> decencies before they're merged into Mainline. So let's do something
> about it now. I'm not sure what though, as I know that Mark isn't fond
> of rebasing his tree.

You can't solve dependencies by "tree X needs to merge before tree Y
otherwise Z breaks", period.

It gives the _illusion_ that it solves it, but it doesn't.  Just try
doing a git bisect and hitting commits in tree Y without tree X being
merged.  By doing it this way, you're basically telling people that
you can't bisect a merge window.  The merge window is _precisely_ the
period where we need bisectability to find bugs.

> It might not even be an issue though. We just need to ensure that
> Linus pulls from ARM-SoC prior to ASoC during the next merge
> window.

No you don't.  People need to understand how git works and realise that
"tree X merges before tree Y" is never a solution to a dependency
problem.

Boot time errors/warnings on snowball

[Lee Jones]

> > We're usually fairly quick at merging our branches during the merge
> > window, so sequencing should be fine. Even if Mark does his pull
> > requests before us, the window of breakage should be minimal (and
> > we're now aware of it).
> 
> If there's a topic branch for the ARM side I can pull it into ASoC to
> get the window down to a few commits (or even rebase the ux500 stuff
> onto it to remove it).

If you're happy to rebase your asoc/topic/ux500 onto Linus'
ux500-devicetree-v3.14-1 tag, I believe that would solve the
dependency.

> Or I can sign the ux500 branch for arm-soc.

What does that do?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Boot time errors/warnings on snowball

[Lee Jones]

> > I know that you've had a bee in your bonnet about the rate of which I
> > sent patches for a while, but this instance has nothing to do with
> > rushing. This is merely an ordering issue and the speed in which
> > varying subsystems are merged into -next.
> > 
> > This is what -next is for though right? To identify these kinds of
> > decencies before they're merged into Mainline. So let's do something
> > about it now. I'm not sure what though, as I know that Mark isn't fond
> > of rebasing his tree.
> 
> You can't solve dependencies by "tree X needs to merge before tree Y
> otherwise Z breaks", period.
> 
> It gives the _illusion_ that it solves it, but it doesn't.  Just try
> doing a git bisect and hitting commits in tree Y without tree X being
> merged.  By doing it this way, you're basically telling people that
> you can't bisect a merge window.  The merge window is _precisely_ the
> period where we need bisectability to find bugs.

Right, Olof was already kind enough to point this out:

 "It can be done. It's unfortunate to lose bisectability though (since
  when you bisect you can end up in a state where the ASoC patches are
  enabled but not the ux500 counterparts. Setting up a shared branch
  is indeed the best (only) way to solve that. Next time around we
  should do so."
 
Which reminded me of "how git works"; non-linear history, yada yada.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Boot time errors/warnings on snowball

[Lee Jones]

> If there's a topic branch for the ARM side I can pull it into ASoC to
> get the window down to a few commits (or even rebase the ux500 stuff
> onto it to remove it).  Or I can sign the ux500 branch for arm-soc.

Mark, don't trouble yourself with this.

As far as I'm aware there shouldn't be any dependency or ordering
issues here. I planned on the transition from platform data to DT to
be fully seamless. We should be using the platform data up until we
remove the AUXDATA, but the driver (or the dmaengine) is attempting to
pull in DMA configuration from the Device Tree, which isn't populated
fully yet.

There is something going on here that I am missing and I'd very much
like to get to the bottom of it before merging upstream.

Please remove the asoc/topic/ux500 altogether and I will resubmit in
its entirety once I've solved all of the issues.

Linus/Olof, the arch/arm stuff is still fine to be merged.

Sorry for any issues this has caused, I'll get to the bottom of it.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Boot time errors/warnings on snowball

[Mark Brown]

On Thu, Dec 05, 2013 at 09:49:27AM +0000, Lee Jones wrote:

> Please remove the asoc/topic/ux500 altogether and I will resubmit in
> its entirety once I've solved all of the issues.

Done - the whole thing with the MMC is very weird.

> Sorry for any issues this has caused, I'll get to the bottom of it.

No worries.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131205/ca5a8609/attachment.sig>

Boot time errors/warnings on snowball

[Lee Jones]

Okay, so I think I figured this out.

Original comment from Olof:

> > > of_dma_request_slave_channel: dma-names property of node
> > > '/soc/msp at 80124000' missing or empty
> > > of_dma_request_slave_channel: dma-names property of node
> > > '/soc/msp at 80124000' missing or empty
> > > of_dma_request_slave_channel: dma-names property of node
> > > '/soc/msp at 80125000' missing or empty
> > > of_dma_request_slave_channel: dma-names property of node
> > > '/soc/msp at 80125000' missing or empty
> > > dma dma0chan22: [d40_config_memcpy] No memcpy
> > > dma dma0chan22: [d40_alloc_chan_resources] Failed to configure memcpy chan
> > > ux500-msp-i2s ux500-msp-i2s.1: Missing dma channel for stream: 0
> > > ux500-msp-i2s ux500-msp-i2s.1: ASoC: pcm constructor failed: -22

> > As far as I'm aware there shouldn't be any dependency or ordering
> > issues here. I planned on the transition from platform data to DT to
> > be fully seamless. We should be using the platform data up until we
> > remove the AUXDATA, but the driver (or the dmaengine) is attempting to
> > pull in DMA configuration from the Device Tree, which isn't populated
> > fully yet.
> > 
> > There is something going on here that I am missing and I'd very much
> > like to get to the bottom of it before merging upstream.

Okay so the basic issue here is the way in which we're requesting our
DMA channel. The Sound DMA handlers make an assumption that because
we're enabling the device via Device Tree, our channels should be
allocated using dma_request_slave_channel(). Sadly this is a Device
Tree only routine and expects certain properties to be present,
including 'dma-names' mentioned above.

The solution is to continue using .compat_request_channel() until all
of the required Device Tree properties are provided. We will be able
to pull this back out to force full Device Tree enablement in the next
cycle.

When I mentioned the use of AUXDATA for smooth platform data -> Device
Tree transition, that only covers the slave configuration. Something
which only comes into force _after_ we've obtained the DMA
channel. Thus, it doesn't help us in this case.

> > Please remove the asoc/topic/ux500 altogether and I will resubmit in
> > its entirety once I've solved all of the issues.

> > Done - the whole thing with the MMC is very weird.

Right, and was actually unrelated. -next still has this issue. Sadly
this will have to be looked at by someone other than myself, as I have
far too much on at the moment.

Linus, can you ask Ulf to have a look at this please?

So unless there are any objections, I'm going to fix-up my set now and
resubmit.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Boot time errors/warnings on snowball

[Linus Walleij]

On Tue, Dec 17, 2013 at 3:47 PM, Lee Jones <lee.jones@linaro.org> wrote:
> Original comment from Olof:

>> > Done - the whole thing with the MMC is very weird.
>
> Right, and was actually unrelated. -next still has this issue. Sadly
> this will have to be looked at by someone other than myself, as I have
> far too much on at the moment.
>
> Linus, can you ask Ulf to have a look at this please?

I think I have some MMC-related patches from Ulf in my tree
queued up, I'll send a pull request for these on top of previous
device tree patches so you can check of that solves the issues.

Yours,
Linus Walleij