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.
Attachment:
signature.asc
Description: Digital signature