Thread (27 messages) 27 messages, 6 authors, 2018-02-01

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

From: Jassi Brar <jassisinghbrar@gmail.com>
Date: 2018-02-01 06:57:32
Also in: linux-arm-msm, linux-clk, lkml

On Thu, Feb 1, 2018 at 12:10 AM, Georgi Djakov [off-list ref] wrote:
Hi Jassi,

On 01/27/2018 05:44 AM, Jassi Brar wrote:
quoted
On Thu, Jan 4, 2018 at 10:26 PM, Georgi Djakov [off-list ref] wrote:
quoted
Hi Jassi,

On 12/29/2017 08:14 AM, Jassi Brar wrote:
quoted
Hi Bjorn,

On Sun, Dec 24, 2017 at 10:36 AM, Bjorn Andersson
[off-list ref] wrote:
quoted
On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote:
quoted
On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov [off-list ref] wrote:
quoted
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!
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help