On Friday 21 November 2014 22:06:51 Jassi Brar wrote:
On 21 November 2014 20:04, Arnd Bergmann [off-list ref] wrote:
quoted
On Friday 21 November 2014 18:52:47 Jassi Brar wrote:
quoted
On 21 November 2014 18:33, Arnd Bergmann [off-list ref] wrote:
quoted
On Thursday 20 November 2014 20:36:15 Vincent Yang wrote:
quoted
+#define __DTS_MB86S70_CLK_H
+
+#define MB86S70_CRG11_ALW 0
+#define MB86S70_CRG11_DDR3 1
+#define MB86S70_CRG11_MAIN 2
+#define MB86S70_CRG11_CA15 3
+#define MB86S70_CRG11_HDMI 4
+#define MB86S70_CRG11_DPHY 5
+
+#define MB86S70_CRG11_UNGPRT 8
The clock driver doesn't seem to use those macros at all, how does the
driver know which clock you are referring to?
That was just an attempt to make a bit verbose the controller
instance. Instead of specifying controller:=4, it reads better
controller:=MB86S70_CRG11_HDMI in the clock DT nodes. The clock driver
simply fills in controller+domain+port of the given clock into mailbox
payload.
See my other comments on the clock nodes. If these are hardware properties,
just leave them as numbers in the DT, the header files are only used to
establish an interface between the binding and the driver in case there
is no sensible way to express which one you have.
OK, I'll hardcode numbers there.
quoted
quoted
Only MB86S70_CRG11_UNGPRT is marked to mean one special (non-maskable)
port on the controller, which the clock driver does make use of.
Is this the actual port number that is known to be non-maskable?
Yes the clock comes out of the controller and is also the parent of
other 8 independently maskable clock ports of the domain.
I'm getting confused by the terminology here. Is MB86S70_CRG11_ALW
a port or a controller?
The firmware on remote master, lets say, don't wanna be bothered by
the clock topology. Even for set-rate the onus is on Linux to request
only appropriate rates at appropriate times so that other devices are
not messed up.
Is there any code to validate that, or does Linux just treat all
clocks transparently?
quoted
How about adding a property to the clock node to mark the logical
controller nonmaskable (in case you go for #clock-cells=2)?
For the #clock-cells=3 case, you should probably just hardcode this
in the driver based on the compatible string.
The SoC has 6 controllers, each controller has 16domains and each
domain has 8+1 ports. Instead of 864 clocks, we wanted to populate
only clocks that some device actually use (some clocks seem unused in
this patchset but we have users that will be upstreamed later).
The remote f/w can't manage inter-dependencies and expect Linux to
send only appropriate requests on port basis, so we populate ports as
tiny independent clock controllers with single clock output.
My impression is that it would be best to model each controller of the
SoC as a clock controller device node with #clock-cells=<2>, and hardcode
the behavior of the special port in the driver.
Arnd
On 21 November 2014 22:45, Arnd Bergmann [off-list ref] wrote:
On Friday 21 November 2014 22:06:51 Jassi Brar wrote:
quoted
quoted
quoted
Only MB86S70_CRG11_UNGPRT is marked to mean one special (non-maskable)
port on the controller, which the clock driver does make use of.
Is this the actual port number that is known to be non-maskable?
Yes the clock comes out of the controller and is also the parent of
other 8 independently maskable clock ports of the domain.
I'm getting confused by the terminology here. Is MB86S70_CRG11_ALW
a port or a controller?
Sorry, bad symbols. ALW..DPHY are controllers. UNGPRT is the ninth
parent clock (port) of a domain that can't be masked.
FYKI, there are 6 instances, of some CRG11 clock controller, under
control of the remote f/w. The Mailbox protocol between remote f/w and
Linux assigned indices [0-5] to these controllers.
quoted
The firmware on remote master, lets say, don't wanna be bothered by
the clock topology. Even for set-rate the onus is on Linux to request
only appropriate rates at appropriate times so that other devices are
not messed up.
Is there any code to validate that, or does Linux just treat all
clocks transparently?
The remote does not expose the clock topology and only accepts
requests on port-basis. The remote f/w is supposed to keep track of
which ports are used by Linux and then work out inter-dependencies
upon receiving a request from Linux. So for Linux there are N
independent 'root' clocks, ops on which may or may not succeed at any
given time.
thanks
jassi
On Friday 21 November 2014 23:28:38 Jassi Brar wrote:
On 21 November 2014 22:45, Arnd Bergmann [off-list ref] wrote:
quoted
On Friday 21 November 2014 22:06:51 Jassi Brar wrote:
quoted
quoted
quoted
quoted
Only MB86S70_CRG11_UNGPRT is marked to mean one special (non-maskable)
port on the controller, which the clock driver does make use of.
Is this the actual port number that is known to be non-maskable?
Yes the clock comes out of the controller and is also the parent of
other 8 independently maskable clock ports of the domain.
I'm getting confused by the terminology here. Is MB86S70_CRG11_ALW
a port or a controller?
Sorry, bad symbols. ALW..DPHY are controllers. UNGPRT is the ninth
parent clock (port) of a domain that can't be masked.
FYKI, there are 6 instances, of some CRG11 clock controller, under
control of the remote f/w. The Mailbox protocol between remote f/w and
Linux assigned indices [0-5] to these controllers.
Ok, not it makes sense, thanks for clearing that up!
quoted
quoted
The firmware on remote master, lets say, don't wanna be bothered by
the clock topology. Even for set-rate the onus is on Linux to request
only appropriate rates at appropriate times so that other devices are
not messed up.
Is there any code to validate that, or does Linux just treat all
clocks transparently?
The remote does not expose the clock topology and only accepts
requests on port-basis. The remote f/w is supposed to keep track of
which ports are used by Linux and then work out inter-dependencies
upon receiving a request from Linux. So for Linux there are N
independent 'root' clocks, ops on which may or may not succeed at any
given time.
Ok.
Arnd