OMAP Zoom kernel ALSA build problem

OMAP Zoom kernel ALSA build problem

[Smith, Stephen]

I am trying to build sound support for the MDK (3430LDP).  There is a build problem on the current git master of the OMAP Zoom kernel.  If "OMAP3 TWL4030 alsa driver" is turned on, the compile fails (looks like the header for the twl4030 gpio routines is missing).  Additionally, if it is selected as a Module, the build will also fail because only CONFIG_SND_OMAP3_TWL4030 is being checked (not CONFIG_SND_OMAP3_TWL403_MODULE) in sound/arm/omap/omap-alsa-dma.h.

Device Drivers - 
  Sound card support - 
    Advanced Linux Sound Architecture - 
      ARM sound devices -
        OMAP3 TWL4030 alsa driver


sound/arm/omap/omap-alsa-twl4030.c: In function 'twl4030_ext_mut_conf':
sound/arm/omap/omap-alsa-twl4030.c:312: error: implicit declaration of function 'twl4030_request_gpio'
sound/arm/omap/omap-alsa-twl4030.c:317: error: implicit declaration of function 'twl4030_set_gpio_direction'
sound/arm/omap/omap-alsa-twl4030.c: In function 'twl4030_ext_mut_unconf':
sound/arm/omap/omap-alsa-twl4030.c:329: error: implicit declaration of function 'twl4030_free_gpio'
sound/arm/omap/omap-alsa-twl4030.c: In function 'twl4030_ext_mut_off':
sound/arm/omap/omap-alsa-twl4030.c:344: error: implicit declaration of function 'twl4030_set_gpio_dataout'


OMAP Linux Kernel Tracker Bug ID 224

Stephen

--
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

Re: OMAP Zoom kernel ALSA build problem

[David Brownell]

On Thursday 04 December 2008, Smith, Stephen wrote:
> I am trying to build sound support for the MDK (3430LDP).  There is a build
> problem on the current git master of the OMAP Zoom kernel.

Perhaps that kernel should sync with newer code?

Both linux-omap and mainline use standard GPIO calls for
such stuff now.

And for that matter, the ASoC framework holds current
twl4030 codec support... those patches are in linux-omap,
linux-next, and of course the ALSA tree.

- Dave



> If "OMAP3 TWL4030 alsa driver" is turned on, the compile fails (looks like
> the header for the twl4030 gpio routines is missing).  Additionally, if it
> is selected as a Module, the build will also fail because only
> CONFIG_SND_OMAP3_TWL4030 is being checked (not CONFIG_SND_OMAP3_TWL403_MODULE)
> in sound/arm/omap/omap-alsa-dma.h.      
> 
> Device Drivers - 
>   Sound card support - 
>     Advanced Linux Sound Architecture - 
>       ARM sound devices -
>         OMAP3 TWL4030 alsa driver
> 
> 
> sound/arm/omap/omap-alsa-twl4030.c: In function 'twl4030_ext_mut_conf':
> sound/arm/omap/omap-alsa-twl4030.c:312: error: implicit declaration of function 'twl4030_request_gpio'
> sound/arm/omap/omap-alsa-twl4030.c:317: error: implicit declaration of function 'twl4030_set_gpio_direction'
> sound/arm/omap/omap-alsa-twl4030.c: In function 'twl4030_ext_mut_unconf':
> sound/arm/omap/omap-alsa-twl4030.c:329: error: implicit declaration of function 'twl4030_free_gpio'
> sound/arm/omap/omap-alsa-twl4030.c: In function 'twl4030_ext_mut_off':
> sound/arm/omap/omap-alsa-twl4030.c:344: error: implicit declaration of function 'twl4030_set_gpio_dataout'
> 
> 
> OMAP Linux Kernel Tracker Bug ID 224
> 
> Stephen
> 
> --
> 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
> 
> 


--
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

Re: OMAP Zoom kernel ALSA build problem

[Trilok Soni]

Hi,

On Thu, Dec 4, 2008 at 11:10 PM, David Brownell <david-b@pacbell.net> wrote:
> On Thursday 04 December 2008, Smith, Stephen wrote:
>> I am trying to build sound support for the MDK (3430LDP).  There is a build
>> problem on the current git master of the OMAP Zoom kernel.
>
> Perhaps that kernel should sync with newer code?

This is going to happen on some other drivers in future too, because
for some unknown reasons (atleast I don't know), that OMAP Zoom went
ahead with their tree. I don't see any reason why they have to create
new tree. See, how beagleboard guys are working.

-- 
---Trilok Soni
http://triloksoni.wordpress.com
http://www.linkedin.com/in/triloksoni

Re: OMAP Zoom kernel ALSA build problem

[Koen Kooi]

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


Op 4 dec 2008, om 18:51 heeft Trilok Soni het volgende geschreven:

> Hi,
>
> On Thu, Dec 4, 2008 at 11:10 PM, David Brownell <david- 
> b@pacbell.net> wrote:
>> On Thursday 04 December 2008, Smith, Stephen wrote:
>>> I am trying to build sound support for the MDK (3430LDP).  There  
>>> is a build
>>> problem on the current git master of the OMAP Zoom kernel.
>>
>> Perhaps that kernel should sync with newer code?
>
> This is going to happen on some other drivers in future too, because
> for some unknown reasons (atleast I don't know), that OMAP Zoom went
> ahead with their tree. I don't see any reason why they have to create
> new tree. See, how beagleboard guys are working.

Well, the from the 'beagleboard guys' AFAIK only Khasim is being paid  
(or rather allowed to work in it at the office) to work on beagle  
kernel stuff, so maintaining a fork is out of the question. The rest  
of the beagleboards peeps wants to get things as fast as possible into  
mainline instead of wanting awesomely good powermanagement.

regards,

Koen

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: OMAP Zoom kernel ALSA build problem

[Koen Kooi]

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


Op 4 dec 2008, om 19:25 heeft Koen Kooi het volgende geschreven:

>
> Op 4 dec 2008, om 18:51 heeft Trilok Soni het volgende geschreven:
>
>> Hi,
>>
>> On Thu, Dec 4, 2008 at 11:10 PM, David Brownell <david- 
>> b@pacbell.net> wrote:
>>> On Thursday 04 December 2008, Smith, Stephen wrote:
>>>> I am trying to build sound support for the MDK (3430LDP).  There  
>>>> is a build
>>>> problem on the current git master of the OMAP Zoom kernel.
>>>
>>> Perhaps that kernel should sync with newer code?
>>
>> This is going to happen on some other drivers in future too, because
>> for some unknown reasons (atleast I don't know), that OMAP Zoom went
>> ahead with their tree. I don't see any reason why they have to create
>> new tree. See, how beagleboard guys are working.
>
> Well, the from the 'beagleboard guys' AFAIK only Khasim is being  
> paid (or rather allowed to work in it at the office) to work on  
> beagle kernel stuff, so maintaining a fork is out of the question.  
> The rest of the beagleboards peeps wants to get things as fast as  
> possible into mainline instead of wanting awesomely good  
> powermanagement.


To be clear: I'm not fond of long-running forks like the zoom tree,  
but I can see why people (read: companies) find them attractive.

regards,

Koen

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: OMAP Zoom kernel ALSA build problem

[David Brownell]

On Thursday 04 December 2008, Koen Kooi wrote:
> >>> Perhaps that kernel should sync with newer code?
>
>  	The rest  
> of the beagleboards peeps wants to get things as fast as possible into  
> mainline instead of wanting awesomely good powermanagement.

Bull hockey ... they want *BOTH* mainline support and good PM.  :)

PM support is still cooking.  Support for other OMAP goodness
can -- and does! -- evolve in parallel.


Having a ZOOM fork to help roll goodies out of TI-internal trees
into mainline is fine -- TI has OMAP hardware for a long time before 
the chips go public -- but the goal should be to *help* and that means
both (a) tracking mainline, probably via linux-omap, and (b) pushing
goodies out of that ZOOM fork so they're more broadly available.

So for example the NAND acceleration stuff seems to have gone
nowhere ... while that ZOOM fork may have some updates, they've not
gotten into the main OMAP tree, or into mainline.

- Dave
--
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

Re: OMAP Zoom kernel ALSA build problem

[Tony Lindgren]

* David Brownell <david-b@pacbell.net> [081204 11:03]:
> On Thursday 04 December 2008, Koen Kooi wrote:
> > >>> Perhaps that kernel should sync with newer code?
> >
> >  	The rest  
> > of the beagleboards peeps wants to get things as fast as possible into  
> > mainline instead of wanting awesomely good powermanagement.
> 
> Bull hockey ... they want *BOTH* mainline support and good PM.  :)
> 
> PM support is still cooking.  Support for other OMAP goodness
> can -- and does! -- evolve in parallel.

Paul and RMK are working on getting the omap clock patches into
mainline. After that we can work on getting Kevin's PM branch into
mainline.

> Having a ZOOM fork to help roll goodies out of TI-internal trees
> into mainline is fine -- TI has OMAP hardware for a long time before 
> the chips go public -- but the goal should be to *help* and that means
> both (a) tracking mainline, probably via linux-omap, and (b) pushing
> goodies out of that ZOOM fork so they're more broadly available.

Yes, the upstream feedback seems to be still missing from zoom.

> So for example the NAND acceleration stuff seems to have gone
> nowhere ... while that ZOOM fork may have some updates, they've not
> gotten into the main OMAP tree, or into mainline.

That is frustrating. People at TI _should_ be working on sending
patches from zoom to upstream. Sure the other people can also
produce patches against the mainline and linux-omap kernel out
of the zoom tree.

In general, here's how the patch flow needs to happen:

- All driver patches need to be posted to the right driver mailing
  lists with linux-omap mailing list Cc'd. The patches need need
  to be against the mainline kernel tree. The recent developments
  with the ASoC and the new fb/v4l code is a good example how this
  is working.

- All core omap code needs to be posted to linux-omap for review
  and will then be queued up into going into the mainline tree.
  For any patches that apply already into the mainline kernel,
  the patches need to be against the mainline kernel. For any
  more complex patches, also linux-arm-kernel and maybe LKML lists
  should be Cc'd.

Soonish the linux-omap tree will become just a queue for patches
for the merge windows. So essentially we'll be using the mainline
kernel with some branches automerged hopefully real-soon-now.

I think the right time to make that switch after Paul's clock
patches are integrated into the mainline kernel. Then we'll move
the non-mainline code into their own branches, or just drop it
if nobody wants to maintain it.

In general, people are encouraged to maintain their own branches
for more larger patches, like we already have for pm, clocks,
dspbridge, mmc, i2c. Then I can mirror these branches and automerge
them branches on daily basis.

Cheers,

Tony
--
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

Re: OMAP Zoom kernel ALSA build problem

[David Brownell]

On Thursday 04 December 2008, Tony Lindgren wrote:
> > So for example the NAND acceleration stuff seems to have gone
> > nowhere ... while that ZOOM fork may have some updates, they've not
> > gotten into the main OMAP tree, or into mainline.
> 
> That is frustrating. People at TI _should_ be working on sending
> patches from zoom to upstream.

Or even just getting their goodness into the linux-omap tree,
as a first step towards getting upstream.

I used the OMAP3 NAND stuff as an example, since we saw a few
(unmergeable) patches but then everything seemed to fizzle.


> Sure the other people can also 
> produce patches against the mainline and linux-omap kernel out
> of the zoom tree.

That would require people to track the ZOOM kernels, as well
as mainline and linux-omap (and their own patch queues).
Not too realistic.


> In general, here's how the patch flow needs to happen:
> 
> - All driver patches need to be posted to the right driver mailing
>   lists with linux-omap mailing list Cc'd. The patches need need
>   to be against the mainline kernel tree. The recent developments
>   with the ASoC and the new fb/v4l code is a good example how this
>   is working.

Yes.  And in the case of stuff like NAND, where there's a ZOOM
driver and a Linux-OMAP driver but nothing in mainline, I suggest
syncing those two *before* pushing to mainline ... though there
may well be a case for involving the relevant mainline team at
that point too, or ignoring one driver.


> - All core omap code needs to be posted to linux-omap for review
>   and will then be queued up into going into the mainline tree.
>   For any patches that apply already into the mainline kernel,
>   the patches need to be against the mainline kernel. For any
>   more complex patches, also linux-arm-kernel and maybe LKML lists
>   should be Cc'd.

Yep, that's straightforward.  By "core" I presume you mean
arch/arm/plat-omap or maybe mach-omap{1,2}.


> Soonish the linux-omap tree will become just a queue for patches
> for the merge windows. So essentially we'll be using the mainline
> kernel with some branches automerged hopefully real-soon-now.

That sounds like an interesting plan.  It'll cause some level
of disruption ... which we probably need to have, since without
it folk seem to have little incentive to track mainline.

A slightly different spin:  treat every divergence from mainline
as a bug that needs fixing.  Those branches should mostly have
fairly short lifespans...


> I think the right time to make that switch after Paul's clock
> patches are integrated into the mainline kernel. Then we'll move
> the non-mainline code into their own branches, or just drop it
> if nobody wants to maintain it.

Sounds like a plan.  Let's see how different the OMAP tree is
from mainline at that point, and see what the branches will be.

- Dave

--
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

Re: OMAP Zoom kernel ALSA build problem

[Tony Lindgren]

* David Brownell <david-b@pacbell.net> [081205 15:36]:
> On Thursday 04 December 2008, Tony Lindgren wrote:
> > > So for example the NAND acceleration stuff seems to have gone
> > > nowhere ... while that ZOOM fork may have some updates, they've not
> > > gotten into the main OMAP tree, or into mainline.
> > 
> > That is frustrating. People at TI _should_ be working on sending
> > patches from zoom to upstream.
> 
> Or even just getting their goodness into the linux-omap tree,
> as a first step towards getting upstream.
> 
> I used the OMAP3 NAND stuff as an example, since we saw a few
> (unmergeable) patches but then everything seemed to fizzle.

Well if somebody does a nand branch against the mainline tree
that we can automerge to l-o tree on daily basis, sure :)

> > Sure the other people can also 
> > produce patches against the mainline and linux-omap kernel out
> > of the zoom tree.
> 
> That would require people to track the ZOOM kernels, as well
> as mainline and linux-omap (and their own patch queues).
> Not too realistic.

Yeah well drivers are easier as they should be just patches
against the mainline tree.

> > In general, here's how the patch flow needs to happen:
> > 
> > - All driver patches need to be posted to the right driver mailing
> >   lists with linux-omap mailing list Cc'd. The patches need need
> >   to be against the mainline kernel tree. The recent developments
> >   with the ASoC and the new fb/v4l code is a good example how this
> >   is working.
> 
> Yes.  And in the case of stuff like NAND, where there's a ZOOM
> driver and a Linux-OMAP driver but nothing in mainline, I suggest
> syncing those two *before* pushing to mainline ... though there
> may well be a case for involving the relevant mainline team at
> that point too, or ignoring one driver.

Sure.

> > - All core omap code needs to be posted to linux-omap for review
> >   and will then be queued up into going into the mainline tree.
> >   For any patches that apply already into the mainline kernel,
> >   the patches need to be against the mainline kernel. For any
> >   more complex patches, also linux-arm-kernel and maybe LKML lists
> >   should be Cc'd.
> 
> Yep, that's straightforward.  By "core" I presume you mean
> arch/arm/plat-omap or maybe mach-omap{1,2}.

Yup.

> > Soonish the linux-omap tree will become just a queue for patches
> > for the merge windows. So essentially we'll be using the mainline
> > kernel with some branches automerged hopefully real-soon-now.
> 
> That sounds like an interesting plan.  It'll cause some level
> of disruption ... which we probably need to have, since without
> it folk seem to have little incentive to track mainline.
> 
> A slightly different spin:  treat every divergence from mainline
> as a bug that needs fixing.  Those branches should mostly have
> fairly short lifespans...

Yeah, and they should be against the mainline tree so they're
ready for merging when the time is right.

> > I think the right time to make that switch after Paul's clock
> > patches are integrated into the mainline kernel. Then we'll move
> > the non-mainline code into their own branches, or just drop it
> > if nobody wants to maintain it.
> 
> Sounds like a plan.  Let's see how different the OMAP tree is
> from mainline at that point, and see what the branches will be.

Sounds like clocks and pm branches, then maybe usb, nand, alsa
as needed. And dspgateway branch and dspbridge branch. And then
maybe also twl4030 branch, hehe :)

Tony

--
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