Sorry for the long pause…

On 06/17/2013 06:03 PM, Mark Brown wrote:

quoted

This is a lot of for a simple mmio access. In terms of
performance: If I add a trace point to my read and write I have
still less code which is called and it can be disabled. This
regmap overhead is always there chasing pointers.

Equally well what you're implementing here is support for
something that's typically implemented with an I2C or SPI control
interface so you're already going to be quite a way ahead of the
norm.  This is part of what's confusing me, usually for this
application things aren't that bad performance wise even on a
massively slower bus.

If all you're saying here is that there's some overhead that's fine
if a bit surprising, but the way you're talking made it sound like
there was some issue that made the API actually unusable.

No, sorry for that confusion. I had a problem with the locking in irq
context, changed the driver & pointed out the problem, been told that
there is a fix, applied it, never complained again.

This is simply about I am forced to use regmap and I don't agree with
it.

quoted

As I said before: I doubt that you get this regmap access in an
one GiB network driver and in turn remove their trace points to
register access.

Well, of course for that sort of thing the general trick is not to
talk to the hardware at all and do as much as possible with memory
that the hardware can DMA - there's actually still non-trivial
costs in talking over the buses.

That is true but even while doing DMA you have enough handshake with
the HW to trigger the transfer and if you are lucky your DMA
descriptors are in cached memory.

quoted

Please don't get me wrong: It is still nice for slow buses and
this ADC driver isn't anything close to high performance like a
1GiB network driver but it adds a lot of unwanted overhead which
I prefer not to have.

OK, but equally well remember that from a subsystem maintainer
point of view having things factored out is a win in itself; for
example with the MFDs locking on the register I/O has been a
persistent issue in the past.

I agree with that. But:

The driver here does not use atomic updates but read followed by write
so your locking here is futile. So the API/regmap alone does not make
it right. And look: the MFD part uses regmap. Its children (IIO &
input) do not use it. After I told this Samuel he said that it is okay.
So here I am. Using regmap in MFD which is only used once on init and
never again. It has regmap.

The register access in both child driver is split making sure they do
not use the same ones. I added one function which writes a common
register. That one is reset after an operation and needs to be written
by the currently active child so the HW continues to work. Haven't seen
anything close to it in regmap.

I ask, politely I hope, to get this patch in and remove regmap since
none of its features are used in this driver.

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html