Hi Arnd, On Thu, 10 Dec 2020 at 23:28, Arnd Bergmann <arnd@xxxxxxxxxx> wrote: > > I did think about this and I did this with the clk mux driver I > > haven't pushed yet. In that case there is a random lump of registers > > with some muxes mixed into it so I decided to make the lump a syscon > > and then have a node for each clk mux in the lump and some properties > > for the muxes within. The driver is certainly less complex but the > > device tree is pretty unmanageable as there are probably 30 or more > > muxes. > > Right, for clk drivers, the trade-off is often different, it's not > unusual that they are a bit of a mess and require a separate driver for > each cheap. I will try to clean up the additions for the ssd202 (the smp enabled chip) this weekend and send a series for that. If it still seems wrong after adding that I will can that series and refactor this before lumping more on top of it. > > > It would be helpful here to replace all the readb_relaxed/writeb_relaxed() > > > with normal readb()/writeb(). Don't use _relaxed() unless there is a strong > > > reason why you have to do it, and if you do, explain it in a comment what > > > the reason is. > > > > The reason is that readb()/writeb() will invoke the heavy memory > > barrier even though it's not needed for peripheral registers. > > I guess it doesn't actually make all that much difference in reality. > > Ah, I forgot you had that heavy barrier. It depends a bit on what you > use the GPIOs for then. For most uses I think the overhead does not > matter, but if there is any bit-banged I/O it might make a difference. Bit-banged buses are likely to happen I think as there is a lot of gpio compared to hardware peripherals. Anyhow, I'll add a comment for the readb_relaxed()/writeb_relaxed() usage. Cheers, Daniel
