From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ryder Lee Subject: Re: [SPAM]Re: [PATCH v3 4/5] dt-bindings: clock: mediatek: update audsys documentation to adapt MFD device Date: Wed, 21 Feb 2018 14:04:08 +0800 Message-ID: <1519193048.18794.42.camel@mtkswgap22> References: <61928ad523a7aeffb8f16d4caad56836b65ae407.1518424204.git.ryder.lee@mediatek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Rob Herring , Lee Jones , Matthias Brugger Cc: devicetree@vger.kernel.org, Garlic Tseng , Stephen Boyd , "linux-kernel@vger.kernel.org" , Mark Brown , linux-mediatek@lists.infradead.org, linux-clk , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" List-Id: devicetree@vger.kernel.org On Mon, 2018-02-19 at 12:29 -0600, Rob Herring wrote: > On Mon, Feb 12, 2018 at 5:28 AM, Ryder Lee wrote: > > The MediaTek audio hardware block that exposes functionalities that are > > handled by separate subsystems in the kernel. These functions are all > > mapped somewhere at 0x112xxxxx, and there are some control bits are mixed > > up with other functions within the same registers. > > I still don't think this change is necessary. > > Just because a hardware block in DT maps to different subsystems in a > particular OS doesn't mean you need a DT node for each OS subsystem. > What we have subsystems for changes over time and DT shouldn't really > be changing based on that. And DT is not the only way to instantiate > drivers. > Apart right now we have the definition of both functions. The other location is here:../sonud/mt2701-afe-pcm.txt. The ways I could come up with are: 1. Add a dummy MFD driver (need to think a new compatible or just use '*-audsys' which has already been picked by clock driver) to instantiate two sub-devices through id_table and mfd_cell. 2. For the sake of simplification - add a new compatible "simple-mfd". 3. The last thing - keep two nodes separated/independent. (x) I'm not sure which one is better. @Lee @Matthias: What do you suggest? Ryder. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <1519193048.18794.42.camel@mtkswgap22> Subject: Re: [SPAM]Re: [PATCH v3 4/5] dt-bindings: clock: mediatek: update audsys documentation to adapt MFD device From: Ryder Lee To: Rob Herring , Lee Jones , Matthias Brugger Date: Wed, 21 Feb 2018 14:04:08 +0800 In-Reply-To: References: <61928ad523a7aeffb8f16d4caad56836b65ae407.1518424204.git.ryder.lee@mediatek.com> MIME-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Garlic Tseng , Stephen Boyd , "linux-kernel@vger.kernel.org" , Mark Brown , linux-mediatek@lists.infradead.org, linux-clk , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" Content-Type: text/plain; charset="us-ascii" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+mturquette=baylibre.com@lists.infradead.org List-ID: On Mon, 2018-02-19 at 12:29 -0600, Rob Herring wrote: > On Mon, Feb 12, 2018 at 5:28 AM, Ryder Lee wrote: > > The MediaTek audio hardware block that exposes functionalities that are > > handled by separate subsystems in the kernel. These functions are all > > mapped somewhere at 0x112xxxxx, and there are some control bits are mixed > > up with other functions within the same registers. > > I still don't think this change is necessary. > > Just because a hardware block in DT maps to different subsystems in a > particular OS doesn't mean you need a DT node for each OS subsystem. > What we have subsystems for changes over time and DT shouldn't really > be changing based on that. And DT is not the only way to instantiate > drivers. > Apart right now we have the definition of both functions. The other location is here:../sonud/mt2701-afe-pcm.txt. The ways I could come up with are: 1. Add a dummy MFD driver (need to think a new compatible or just use '*-audsys' which has already been picked by clock driver) to instantiate two sub-devices through id_table and mfd_cell. 2. For the sake of simplification - add a new compatible "simple-mfd". 3. The last thing - keep two nodes separated/independent. (x) I'm not sure which one is better. @Lee @Matthias: What do you suggest? Ryder. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: ryder.lee@mediatek.com (Ryder Lee) Date: Wed, 21 Feb 2018 14:04:08 +0800 Subject: [SPAM]Re: [PATCH v3 4/5] dt-bindings: clock: mediatek: update audsys documentation to adapt MFD device In-Reply-To: References: <61928ad523a7aeffb8f16d4caad56836b65ae407.1518424204.git.ryder.lee@mediatek.com> Message-ID: <1519193048.18794.42.camel@mtkswgap22> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, 2018-02-19 at 12:29 -0600, Rob Herring wrote: > On Mon, Feb 12, 2018 at 5:28 AM, Ryder Lee wrote: > > The MediaTek audio hardware block that exposes functionalities that are > > handled by separate subsystems in the kernel. These functions are all > > mapped somewhere at 0x112xxxxx, and there are some control bits are mixed > > up with other functions within the same registers. > > I still don't think this change is necessary. > > Just because a hardware block in DT maps to different subsystems in a > particular OS doesn't mean you need a DT node for each OS subsystem. > What we have subsystems for changes over time and DT shouldn't really > be changing based on that. And DT is not the only way to instantiate > drivers. > Apart right now we have the definition of both functions. The other location is here:../sonud/mt2701-afe-pcm.txt. The ways I could come up with are: 1. Add a dummy MFD driver (need to think a new compatible or just use '*-audsys' which has already been picked by clock driver) to instantiate two sub-devices through id_table and mfd_cell. 2. For the sake of simplification - add a new compatible "simple-mfd". 3. The last thing - keep two nodes separated/independent. (x) I'm not sure which one is better. @Lee @Matthias: What do you suggest? Ryder.