Messages in this thread | | | From | Daniel Palmer <> | Date | Fri, 11 Dec 2020 00:49:04 +0900 | Subject | Re: [PATCH v4 3/5] gpio: msc313: MStar MSC313 GPIO driver |
| |
Hi Arnd,
On Thu, 10 Dec 2020 at 23:28, Arnd Bergmann <arnd@kernel.org> 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
| |