Hi Alexey.
On 2 March 2018 at 14:51, Alexey Brodkin Alexey.Brodkin@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@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...
- 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.
- 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