Re: [PATCH v11 2/6] mailbox: qcom: Create APCS child device for clock controller

[Jassi Brar]

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?

>> For example, if this APCS had a mac controller, would we also populate
>> a netdev from mailbox driver? And what if next revision moves/drops
>> this clock controller out of APCS, keeping mailbox controller exactly
>> same?
>
> The clock controller may change in some next SoC architecture and that's
> why the SoC version is also part of the the compatible string.
>
So the mailbox driver will be updated to spawn yet another type of clock?
And again for next revision and so on... I know that is unlikely but
the point is why not have separate clock drivers for independent h/w
clocks?
I'll let Rob take the final call.

Cheers!