On Wed, Apr 02, 2014 at 10:40:41PM +0200, Martin Sperl wrote: > Will try to keep emails shorter - I wanted to get everything out in one > and document it also trying to answer questions I thought would come up. Sending several mails might've helped too - the way a patch series is structured is actually a fairly good way of breaking things up for comprehnsibility. > Just to summarize the current "modules" and their respective files: > spi-optimize - essentially the patch shared with my original email touching: > include/linux/spi/spi.h > driver/spi/spi.c > maybe adding some documentation on how to "optimize" high-volume drivers > to make optimal use of the interface. There should be some win from this purely from the framework too even without drivers doing anything. > Does this look "ok" from an approach perspective? Broadly. Like I say the DMA stuff is the biggest alarm bell - if it's not playing nicely with dmaengine that'll need to be dealt with. > I will share one module after the other for initial review. It's OK to post the lot at once as part of a series but it needs to be split up into separate logical patches. Hopefully we can get the externally visible optimisation stuff merged relatively quickly so that drivers can start building on it. > I will brush up the code for the generic DMA fragment code, so that it > becomes presentable and will share that part in the hope that it live in > parallel to dmaengine and/or get somehow integrated - possibly as another target > besides cyclic. Yes, something like that. The most important thing is to make it usable with any driver. > As such drivers using this specific interface will need to know enough about > the HW itself, my assumption is that the driver will need to know about the DMA > engine used to work properly - so I left all sorts of abstractions out of the > design - this can get added later if needed... > Anyway this should come with deeper integration with dma-engine. That would seem very surprising - I'd really have expected that we'd be able to expose enough capability information from the DMA controllers to allow fairly generic code; there's several controllers that have to work over multiple SoCs. > P.s: as an afterthought: I actually think that I could implement a DMA driven > bit-bang SPI bus driver with up to 8 data-lines using the above dma_fragment > approach - not sure about the effective clock speed that this could run... > But right now it is not worth pursuing that further. Right, and it does depend on being able to DMA to set GPIOs which is challenging in the general case.
Attachment:
signature.asc
Description: Digital signature
