[U-Boot] [RFC] ns16550: Add support for AUX regs usage on some ARC SoCs
Simon Glass
sjg at chromium.org
Thu Mar 8 20:27:09 UTC 2018
Hi Alexey.
On 2 March 2018 at 14:51, Alexey Brodkin <Alexey.Brodkin at synopsys.com> wrote:
>
> Hi Simon,
>
> On Thu, 2018-02-22 at 10:29 -0700, Simon Glass wrote:
> > Hi Alexey,
> >
> > On 22 February 2018 at 09:23, Alexey Brodkin
> > <Alexey.Brodkin at synopsys.com> wrote:
> > > Hi Simon,
> > >
> > > On Thu, 2018-02-22 at 09:17 -0700, Simon Glass wrote:
>
> [snip]
>
> > > > I think a separate driver might be better, unless we want to make the
> > > > read/write interface go through regmap or similar?
> > >
> > > But in case of ARC's AUX regs portmap won't help because those AUX regs are
> > > couldn't be mapped - that a completely different address space and we may
> > > only access them via dedicated instructions (LR vs LD and SR vs ST).
> >
> > Well...
> >
> > 1. With a separate driver, you can do whatever you want :-) I know it
> > introduces code duplication though...
>
> Exactly I hate to introduce another driver which will be 99,9% the same
> as an existing one and then we'll need to care of it as well.
>
> > 2. With regmap you can add your own regmap driver, and again do
> > whatever you want. I can help with that if it sounds attractive
>
> Ok so I took a look at regmap in Linux kernel and indeed that
> will solve our problem: we'll have a regmap-mmio.c and regmap-arcaux.c
> with appropriate implementation of accessors but I'm not really sure
> it worth the trouble. Or your idea was to move all the different #ifdefs from
> serial_{in|out}_shift() to the corresponding regmap implementations such that
> we have something like below:
> regmap-mem32-le.c
> regmap-mem32-be.c
> regmap-portmapped.c
> etc
> ?
Yes, that's it.
I'm not sure why that driver is so special. Presumably other drivers
would have the same problem?
Regards,
Simon
More information about the U-Boot
mailing list