* Jarkko Nikula <[email protected]> [110614 04:59]:
> On Tue, 14 Jun 2011 14:19:34 +0300
> Péter Ujfalusi <[email protected]> wrote:
> 
> > We have discussion ongoing about the mcbsp code move, and so far the 
> > current 
> > understanding/plan is (Jarkko/Liam correct me if I'm wrong):
> > - Fix the OMAP4 support
> > - move the code under sound/soc/omap/
> >  - the reason for this is that McBSP block can be only used for streaming 
> > type 
> > of modes (from omap2430 onwards McBSP does not have clock stop 
> > functionality).
> > This makes other type of usage hard to say the least.
> > - Clean up the code (remove the SPI mode, remove unused code paths at the 
> > same 
> > time)
> > - Consolidate the interface for audio only use
> 
> Yeah, now is perfect time to tell if there is any need for something
> else than audio.
> 
> OMAP1xxx/59xx and 2420 are already something like more
> than 5 years old obsolete components and we haven't seen that any of
> them would need SPI/clock stop functionality. Actually we haven't seen
> any other use for McBSP than audio.

Yes this sounds OK to me. So the order to do things should be:

- Fix issues
- Remove unused code
- Move to drivers
- Add new features as needed
 
> > - Only OMAP3 has sidetone (on OMAP2 EAC block has the sidetone), might need 
> > some change, but I think the current way can be reused.
> > 
> Yeah, they probably need work on kernel side (hwmod stuff etc) but I
> think for keeping userspace intact over the cleanup we might want to
> keep these special sysfs nodes for sidetone filter coefficients, dma
> operating mode and FIFO threshold as it over the cleanup.

Also related is the sound/soc/omap mess that should not be doing
any platform level stuff at all but instead get the configuration
in platform data and device tree data eventually. Just grep for
platform_set_drvdata in sound/soc/omap to see it..

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to