mach header files

[Grant Likely]

On Fri, Apr 4, 2014 at 6:14 AM, Phil Edworthy <phil.edworthy at renesas.com> wrote:
> Hi Grant,
>
> On: 04 April 2014 13:23, Grant wrote:
>> On Fri, Apr 4, 2014 at 5:16 AM, Phil Edworthy <phil.edworthy at renesas.com>
>> wrote:
>> > Hi Grant,
>> >
>> > On: 04 April 2014 11:30, Grant wrote:
>> >> On Fri, Apr 4, 2014 at 1:19 AM, Phil Edworthy
>> <phil.edworthy at renesas.com>
>> >> wrote:
>> >> > Resent, hopefully without the automatic corporate signature appended
>> >> this time...
>> >> >
>> >> > Hi,
>> >> >
>> >> > I am porting the kernel to a new device, for which I've created a new
>> >> arch/arm/mach-... directory, and I also a clock driver that lives under
>> >> driver/clk. Everything is all working fine, though I am now cleaning up the
>> >> code and have a question about mach specific header files.
>> >> >
>> >> > The clock driver is completely specific to this device, but needs to read
>> from
>> >> a system register (just for external boot mode pins) to determine some
>> PLL
>> >> settings. This register is in a block of system registers which are also used
>> by
>> >> the mach code in arch/arm/mach-...
>> >> >
>> >> > Since the clock driver is specific to the mach, is there any point in
>> specifying
>> >> the address of this reg in the corresponding dtsi? The format and
>> >> functionality described by this register would not be the same on any
>> other
>> >> device.
>> >>
>> >> Why would you not? The dts is a central place where the entire memory
>> map
>> >> layout of the device can be specified. If I were working on the board
>> support,
>> >> I would create a node for the register block and have the driver retrieve
>> that
>> >> node.
>> >
>> > Ok, that's a slightly different view to the one I had. I had thought that the
>> dts would only contain information that could be changed from one platform
>> to another.
>> >
>> >> > If I don't specify the address of the register in the dtsi, I think it would
>> be
>> >> best to have a common header file for all of the system registers. I've
>> seen
>> >> some drivers, e.g.  exynos-cpufreq.c, doing this by including files from
>> mach-
>> >> exynos/include/mach. Is that the right way to do this?
>> >>
>> >> You'd still want to have a header file for each of the register offsets within
>> >> the block. You wouldn't want to itemize register offsets in the device tree
>> >> node.
>> >
>> > You would put that include file in a mach-.../include/mach/ dir, right?
>>
>> If it is used only by one driver, then it should go directly into that
>> driver without a #include. For SoC defines, you'll need to check with
>> the arm-soc maintainers. I *think* we're trying to get away from
>> separate arch/arm/mach-* directories, but I'm slightly out of touch.
>> You certainly should not do anything that breaks multiplatform builds.
>
> This is where it gets tricky. The clock driver only wants to know about one reg in a block of general system control registers. There is very little input to the clock driver... the SoC code needs to access other registers in the system control block.

As long as it can find the registers and if the clock driver is only
reading the registers then there is no problem. You don't need to
worry about locking and the driver can access the registers directly.

If the driver needs to coordinate with other drivers, then you should
have a little block of code to manage the system register block.

g.