[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51B88CF1.4060708@linutronix.de>
Date: Wed, 12 Jun 2013 17:00:01 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Samuel Ortiz <sameo@...ux.intel.com>
CC: Jonathan Cameron <jic23@...nel.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Jonathan Cameron <jic23@....ac.uk>,
Lee Jones <lee.jones@...aro.org>,
BenoƮt Cousson <b-cousson@...com>,
Tony Lindgren <tony@...mide.com>, Felipe Balbi <balbi@...com>,
linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
linux-iio@...r.kernel.org, linux-input@...r.kernel.org
Subject: Re: am335x: TSC & ADC reworking including DT pieces, take 4
On 06/12/2013 04:41 PM, Samuel Ortiz wrote:
>> This forces me redo a few things and most likely adding it to the
>> iio and input driver to be consistent here.
> I'm not asking for that. The current MFD code uses regmap fine without
> the iio and input using it, I don't see why you would have to add regmap
> support there.
Right. Since no reg-cache is used then this should be fine then.
>> Could you please give a reason why using the regmap here is a good
>> thing? I mentioned a few why it is not and why is better to leave it
>> out.
> Yes, and I'm not convinced obviously. regmap prevents you from open
> coding your MMIO access, and this is the right approach.
I am not convinced that adding another layer of indirection for doing
the same thing is a good approach. Pointer chasing _is_ expensive.
_None_ of the regmap features are used here.
I would understand if I would re-implement register caching or a
wrapper across multiple buses but nothing of this is the case.
The current code even ignores the return value.
So, are we going to convert all drivers to use regmap now?
> Cheers,
> Samuel.
>
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists