On Thu, Feb 1, 2018 at 12:10 AM, Georgi Djakov <georgi.djakov@xxxxxxxxxx> wrote: > > Hi Jassi, > > On 01/27/2018 05:44 AM, Jassi Brar wrote: > > On Thu, Jan 4, 2018 at 10:26 PM, Georgi Djakov <georgi.djakov@xxxxxxxxxx> wrote: > >> Hi Jassi, > >> > >> On 12/29/2017 08:14 AM, Jassi Brar wrote: > >>> Hi Bjorn, > >>> > >>> On Sun, Dec 24, 2017 at 10:36 AM, Bjorn Andersson > >>> <bjorn.andersson@xxxxxxxxxx> wrote: > >>>> On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote: > >>>> > >>>>> On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov <georgi.djakov@xxxxxxxxxx> wrote: > >>>>>> There is a clock controller functionality provided by the APCS hardware > >>>>>> block of msm8916 devices. The device-tree would represent an APCS node > >>>>>> with both mailbox and clock provider properties. > >>>>>> > >>>>> The spec might depict a 'clock' box and 'mailbox' box inside the > >>>>> bigger APCS box. However, from the code I see in this patchset, they > >>>>> are orthogonal and can & should be represented as independent DT > >>>>> nodes. > >>>> > >>>> The APCS consists of a number of different hardware blocks, one of them > >>>> being the "APCS global" block, which is what this node and drivers > >>>> relate to. On 8916 this contains both the IPC register and clock > >>>> control. But it's still just one block according to the hardware > >>>> specification. > >>>> > >>>> As such DT should describe the one hardware block by one node IMHO. > >>>> > >>> In my even humbler opinion, DT should describe a h/w functional unit > >>> which _could_ be seen as a standalone component. > >> > >> The APCS is one separate register block related to the CPU cluster. I > >> haven't seen any strict guidelines for such cases in the DT docs, and > >> during the discussion got the impression that this is the preferred > >> binding. Rob has also reviewed the binding, so we should be fine to move > >> forward with this one. > >> > > Well, I can't overrule Rob. But I am really not happy with random > > device spawning from mailbox drivers. I know there are such instances > > already in the kernel but that doesn't make it legit... unless there > > is some hard dependency. Is there? > > The dependency is that on this SoC, these functionalities are combined > into this "CPU subsystem" block. > I see the register space is shared between mailbox and the clock. So I guess, yes, simply creating a device here and passing the common regmap is tidier. Which patches are already picked up? Cheers! -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
