Re: [PATCH net-next 02/12] clk: sunxi-ng: r40: export a regmap to access the GMAC register

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 4, 2018 at 2:45 PM, Icenowy Zheng <icenowy@xxxxxxx> wrote:
> 在 2018-04-03二的 11:50 +0200,Maxime Ripard写道:
>> On Tue, Apr 03, 2018 at 11:48:45AM +0200, Maxime Ripard wrote:
>> > On Tue, Mar 20, 2018 at 03:15:02PM +0800, Chen-Yu Tsai wrote:
>> > > On Mon, Mar 19, 2018 at 5:31 AM, Maxime Ripard
>> > > <maxime.ripard@xxxxxxxxxxx> wrote:
>> > > > On Sat, Mar 17, 2018 at 05:28:47PM +0800, Chen-Yu Tsai wrote:
>> > > > > From: Icenowy Zheng <icenowy@xxxxxxx>
>> > > > >
>> > > > > 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@xxxxxxx>
>> > > > > Signed-off-by: Chen-Yu Tsai <wens@xxxxxxxx>
>> > > >
>> > > > 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

>>
>> I'm just questionning if merging any other driver using one is the
>> right move.
>>
>> Maxime
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux