From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752367AbdLFSts (ORCPT ); Wed, 6 Dec 2017 13:49:48 -0500 Received: from fllnx210.ext.ti.com ([198.47.19.17]:27979 "EHLO fllnx210.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751945AbdLFStq (ORCPT ); Wed, 6 Dec 2017 13:49:46 -0500 Subject: Re: [RFC PATCH 1/3] ASoC: Add platforms directory To: Mark Brown CC: Liam Girdwood , , References: <20171205181448.18513-1-afd@ti.com> <20171205181448.18513-2-afd@ti.com> <20171206123908.GB1827@finisterre> <561a6ebd-c978-c52a-a13a-3300be9a58bb@ti.com> <20171206172924.mrd233uipzorrymc@sirena.org.uk> <20171206184219.fhhohxdihsm33kf6@sirena.org.uk> From: "Andrew F. Davis" Message-ID: Date: Wed, 6 Dec 2017 12:49:39 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171206184219.fhhohxdihsm33kf6@sirena.org.uk> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. >