From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey Brodkin Date: Fri, 2 Mar 2018 21:51:12 +0000 Subject: [U-Boot] [RFC] ns16550: Add support for AUX regs usage on some ARC SoCs In-Reply-To: References: <20180221122605.8128-1-abrodkin@synopsys.com> <1519316626.19466.15.camel@synopsys.com> Message-ID: <1520027469.4430.43.camel@synopsys.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > 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 ? Regards, Alexey