[U-Boot] [PATCH 30/52] rockchip: rk3368: grf: use shifted-constants and prefix with RK3368_

[Dr. Philipp Tomsich]

> On 24 Jul 2017, at 19:17, Simon Glass <sjg at chromium.org> wrote:
> 
> Hi Philipp,
> 
> On 24 July 2017 at 10:49, Dr. Philipp Tomsich
> <philipp.tomsich at theobroma-systems.com> wrote:
>> 
>>> On 24 Jul 2017, at 18:43, Simon Glass <sjg at chromium.org> wrote:
>>> 
>>> Hi Philipp,
>>> 
>>> On 24 July 2017 at 07:10, Dr. Philipp Tomsich
>>> <philipp.tomsich at theobroma-systems.com> wrote:
>>>> 
>>>> 
>>>>> On 24 Jul 2017, at 14:45, Kever Yang <kever.yang at rock-chips.com> wrote:
>>>>> 
>>>>> Hi Philipp,
>>>>> 
>>>>> 
>>>>> On 07/24/2017 05:11 PM, Dr. Philipp Tomsich wrote:
>>>>>>> On 24 Jul 2017, at 10:34, Andy Yan <andy.yan at rock-chips.com> wrote:
>>>>>>> 
>>>>>>> Hi Philipp:
>>>>>>> 
>>>>>>> 
>>>>>>> On 2017年07月21日 16:34, Dr. Philipp Tomsich wrote:
>>>>>>>>> On 21 Jul 2017, at 05:50, Andy Yan <andy.yan at rock-chips.com> wrote:
>>>>>>>>> 
>>>>>>>>> Hi Philipp:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 2017年07月19日 04:36, Philipp Tomsich wrote:
>>>>>>>>>> The RK3368 GRF header was still defines with a shifted-mask but with
>>>>>>>>>> non-shifted function selectors for the IOMUX defines.  As the RK3368
>>>>>>>>>> support is still fresh enough to allow a quick rename, we do this now
>>>>>>>>>> before having more code use this.
>>>>>>>>>> 
>>>>>>>>>> As some of the downstream drivers (e.g. the Designware GMAC wrapper)
>>>>>>>>>> may need to include the grf-header of multiple devices, we rename the
>>>>>>>>>> various defines for the RK3368 by prefixing them with the device name.
>>>>>>>>>> This avoids future trouble during driver integration.
>>>>>>>>>  Is that really necessary to add such a prefix for all the register definition, just to fit  the GMAC dirver?
>>>>>>>>> Maybe the gmac driver can define the platform specific macro in its own code like dwmac-rk in the kernel. Then we can keep the register header file a little tidy.
>>>>>>>> The problem is not the GMAC driver (although it was the motivation for doing
>>>>>>>> this change), but rather how easy it is to pick up the wrong grf-file and refer
>>>>>>>> to the wrong definitions/values… the conflicts are not through the GMAC-specifc
>>>>>>>> defines but rather through things like the IOMUX masks or (before I moved
>>>>>>>> this to the DDR-driver) things like the defines to enable DRAM in GRF.
>>>>>>>> 
>>>>>>>> Until we find a way to consistently structure things in such a way that
>>>>>>>>  (a) common constructs can be shared (e.g. the masks in the IOMUX)
>>>>>>>>  (b) specific definitions (e.g. the pin-out for a specific device) is not visible outside of its driver
>>>>>>>> I prefer the names to explicitly refer to each device.
>>>>>>>> That said, the longer-term plan (especially with a larger number of devices
>>>>>>>> being supported) needs to include a consistent rework of how (and where)
>>>>>>>> we manage all these definitions from the grf-header files.
>>>>>>> It's true that many devices use GRF, we also face this condition in the kernel land.And all the drivers in kernel handle this device specific definition in the driver itself(by of_device_id->data or MACRO). And there is also no need to use the grf constructs, the common syscon api will provide  you the grf base address. I think this keeps things simple, we don't need to rely on too much of the grf or cru header, maybe some day we can remove the header file, just as clean as the kernel.
>>>>>> The problem is not the base-address of GRF, but rather the need to pull in the
>>>>>> register structure (so we can refer to individual registers by name instead of by
>>>>>> hard-coded offset): as we pull this in today, the definitions for the various IOMUX
>>>>>> entries will also be pulled in, which will cause duplicate definitions.
>>>>> 
>>>>> I really don't like the idea of add the prefix, which end with longer MACRO but no other improve.
>>>>> I think the GRF is used mostly for the IOMUX, in this case the better solution is
>>>>> port the kernel rockchip-pinctrl driver in uboot, which not rely on the dtsi instead of header file.
>>>>> 
>>>>> If we do this, we can remove most of the GRF header definition for IOMUX, I can ask David Wu
>>>>> to do this, but maybe few weeks later.
>>>> 
>>>> As indicated earlier: this is a temporary solution (although we have a local saying that
>>>> "nothing is more permanent than a temporary solution”) and should remain limited to
>>>> the RK3368 until we can clean this up across all boards.
>>> 
>>> Can we drop the prefix for now? I do worry about the precedent this
>>> sets. If this is needed anywhere then it suggests to me that we have
>>> not split up the drivers correctly. We should not be including two
>>> different GRF headers into the same file. E.g. there should be
>>> different pinctrl drivers for each SoC.
>> 
>> If we drop it, we can’t get RK3368-support merged into the GMAC driver for now.
>> Splitting the Rockchip-wrapper of the GMAC-driver doesn’t appear like a workable
>> solution either, as this would create a new file for each chip-variant in drivers/net.
>> 
>> I’ll just pull the RK3368 GMAC (driver) support for now and split it off this series.
> 
> My view of GRF is that we should try to have a driver for the various
> operations that each thing needs (e.g. using the ioctl model). Imagine
> a world where we have a U-Boot that supports running on all available
> Rockchip SoCs and can boot on any board. In that case we probably want
> a GRF driver with operations that can be implemented by each SoC.
> 
> I have not sketched this out or tried it though. It needs more thought
> / prototyping.
> 
> I am concerned about #ifdefs in the code and including private
> SoC-specific RK header files in generic Rockchip drivers. To me that
> is the wrong approach.
> 

This echoes some of my ideas, especially the litmus-test of considering
an universal U-Boot for all Rockchip devices.

I currently don’t see us winning much by moving the inclusion to new
drivers (as these would then need to include the RK header files).  The
direction that I am taking this avoids any chip-specific #ifdef as well, as
the device-model offers plenty better solutions.

In fact, I had sketched out a misc-device that would provide the required
functionality for the GMAC driver last week and this would have resolved
my issue at hand.  Yet, this seems a bit overkill, as it would add a number
of misc-devices w/o gaining any simplification (i.e. each misc-device would
then include the grf-header for one of the chips).

Either way, there’s one detail that I haven’t been able to fully flesh out yet:
the TPL/SPL stages use the GRF directly to set up the debug uart pin-mux.
I haven’t had time to see if there’s space to pull pinctrl in to resolve this
specific case—either way, it shows that there may be cases where we
need to access the GRF w/o the device-model support…

My hope is that the few remaining cases of needing the GRF bits before
the device-model is ready are sufficiently few to accept duplicating the
bit-definitions (e.g. I’d be willing to live with this, if it’s only the debug-uart).

—Philipp.