[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130617160326.GE1403@sirena.org.uk>
Date: Mon, 17 Jun 2013 17:03:26 +0100
From: Mark Brown <broonie@...nel.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Samuel Ortiz <sameo@...ux.intel.com>,
Lee Jones <lee.jones@...aro.org>,
BenoƮt Cousson <b-cousson@...com>,
Tony Lindgren <tony@...mide.com>,
Jonathan Cameron <jic23@....ac.uk>,
Dmitry Torokhov <dmitry.torokhov@...il.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: [PATCH 01/22] mfd/ti_am335x_tscadc: remove regmap
On Mon, Jun 17, 2013 at 01:41:40PM +0200, Sebastian Andrzej Siewior wrote:
> On 06/14/2013 03:53 PM, Mark Brown wrote:
> > It does give you tracepoints and debugfs. If it's making things at
> > all complicated we need to look at why that is and figure out how
> > to fix that since it's probably an issue for other users.
> debugfs are tracepoints is our offer? Let me check the price one more
> time.
OK...
> 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.
> 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.
> 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.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists