lkml.org 
[lkml]   [2017]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH 1/3] ASoC: Add platforms directory
From
Date
On 12/06/2017 12:42 PM, Mark Brown wrote:
> On Wed, Dec 06, 2017 at 12:13:22PM -0600, Andrew F. Davis wrote:
>> On 12/06/2017 11:29 AM, Mark Brown wrote:
>
>>> Machine and drivers for SoC internal stuff tend to be bound fairly
>>> closely together, simiarly the various drivers for an IP on a SoC often
>>> know things about each other for various reasons.
>
>> This is the problem, we don't want them to be so tightly bound, and
>> luckily, for the most part they are not. Even a complex and history rich
>> platform like OMAP was rather trivial to split from its various machine
>> drivers.
>
> Anything new that can is already getting pushed into using the existing
> generic cards. New machine drivers are only for things where that's not
> possible.
>
>>> What I am saying is that they go together very closely. Moving the code
>>> around isn't going to change that.
>
>> Not at first, but this partition will discourage future machine-platform
>> mash-ups (like omap-hdmi-audio.c, yuck).
>
> It's not a pressing problem.
>
>> My end-goal here is to start trimming the needed machine drivers and
>> replacing them with generics, a couple OMAP machine drivers do nothing
>> that couldn't be done with the "asoc-simple-card" driver. With the
>> machine drivers split out form the platform drivers it becomes easier to
>> target them.
>
> We need to preserve old bindings to ensure DT compatiblity, the easiest
> way to do that is to keep old machine drivers around. There are plenty
> of older drivers that wouldn't be accepted now but would at least need
> replacing with a compatibility layer that adapts the bindings onto one
> of the generic drivers. That adaption layer would definitely be useful
> (basically a big table of platform data) but it'd take time to implement
> it.
>

We then should at least start depreciating them now so that someday we
can drop that stuff. Isolating them would be the first step.

>> I don't have any need to group the TI platforms (Davinci / OMAP) right
>> now, but I *have* been thinking about grouping the TI CODECs, they share
>> a lot of code that could be factored out if they were stored in their
>> own space sound/soc/codecs/ti/. Plus it would make it easy to add myself
>
> You can share code easily enough without moving anything, just make a
> library like the arizona drivers did.
>

The lack of organization bugs me, this is why directories exist.

>> as a reviewer for them (I seem to be getting a lot of internal support
>> requests for these drivers these days). That can be a re-org for another
>> day, unless you would like me to post an RFC with what I had in mind?
>
> Wouldn't a few regexps in the MAINTAINERS file cover it? We've already
> got a bunch of vendors doing this.
>

pcm*
tas*
tlv*
twl*

It's messy how many prefixes we have :/

>>> If we were going to do this reshuffling then we *really* shouldn't be
>>> doing it randomly for only a few vendors. Doing it inconsistently is
>>> not going to make anything clearer.
>
>> I can send patches for rest of the vendors if you would like to see that
>> and what the end result would look like.
>
> I'm not convinced this is a good idea.
>

\
 
 \ /
  Last update: 2017-12-06 19:50    [W:0.063 / U:0.980 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site