On Wed, Apr 4, 2018 at 2:45 PM, Icenowy Zheng [off-list ref] wrote:

在 2018-04-03二的 11:50 +0200，Maxime Ripard写道：

quoted

On Tue, Apr 03, 2018 at 11:48:45AM +0200, Maxime Ripard wrote:

quoted

On Tue, Mar 20, 2018 at 03:15:02PM +0800, Chen-Yu Tsai wrote:

quoted

On Mon, Mar 19, 2018 at 5:31 AM, Maxime Ripard
[off-list ref] wrote:

quoted

On Sat, Mar 17, 2018 at 05:28:47PM +0800, Chen-Yu Tsai wrote:

quoted

From: Icenowy Zheng <icenowy@aosc.io>

There's a GMAC configuration register, which exists on
A64/A83T/H3/H5 in
the syscon part, in the CCU of R40 SoC.

Export a regmap of the CCU.

Read access is not restricted to all registers, but only the
GMAC
register is allowed to be written.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Chen-Yu Tsai <redacted>

Gah, this is crazy. I'm really starting to regret letting that
syscon
in in the first place...

IMHO syscon is really a better fit. It's part of the glue layer
and
most other dwmac user platforms treat it as such and use a
syscon.
Plus the controls encompass delays (phase), inverters (polarity),
and even signal routing. It's not really just a group of clock
controls,
like what we poorly modeled for A20/A31. I think that was really
a
mistake.

As I mentioned in the cover letter, a slightly saner approach
would
be to let drivers add custom syscon entries, which would then
require
less custom plumbing.

A syscon is convenient, sure, but it also bypasses any abstraction
layer we have everywhere else, which means that we'll have to
maintain
the register layout in each and every driver that uses it.

So far, it's only be the GMAC, but it can also be others (the SRAM
controller comes to my mind), and then, if there's any difference
in
the design in a future SoC, we'll have to maintain that in the GMAC
driver as well.

I guess I forgot to say something, I'm fine with using a syscon we
already have.

As we finally need the SRAM controller on these new SoCs (for VE on all
SoCs targeted by dwmac-sun8i, and for DE on A64), should we deprecate
the syscon and all switch to device regmap (and let sunxi-dram driver
to export a regmap)? (As in the A64 DE2 thread discussed, two device
nodes shouldn't cover the same MMIO region.)

Sounds like a plan.

In addition, there might be multiple registers in the syscon/sram zone
that are needed (for example, if a version driver is written, it will
need the "0x24 Version Register"; and GMAC needs "0x30 EMAC Clock
Register"). How to deal with this if we export the syscon/sram zone as
a generic device regmap?

You can have multiple regmaps for a device. And the API allows you to
request them up by name.

ChenYu

quoted

I'm just questionning if merging any other driver using one is the
right move.

Maxime

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel