On Thu, Nov 19, 2015 at 04:00:45PM +0100, Martin Sperl wrote: Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. > On the bcm2835 there are also some “limitations” (when transfers are not aligned > to word, transfers>65535 can’t DMA) which we work around right now inefficiently. Alignment is a general issue which all clients should be trying to ensure as a matter of course - never mind individual blocks of hardware, some common CPU architectures suffer noticable penalties from unaligned accesses so it's just generally good practice to try to avoid them. You shouldn't be doing anything about transfer size limitations in your driver, if you have this restriction you should be adding code to the core and just flagging the limit in your driver. > I am in the progress of writing a (minimal) spi-core extension, that would allow > a spi_master to have a prepare_message function that would call some “message > translation functions”. > The ones I have currently come up with are: > int spi_split_transfer_alignment(struct spi_message *msg, int alignment); > int spi_split_transfer_maxsize(struct spi_message *msg, size_t max_size); Please don't do things this way, please make this more data driven - have the drivers declare their capabilities so the core can just do these things based on those flags rather than requiring active code in drivers. This keeps the code central which in turn helps keep things maintainable. > I guess this is a more transparent approach that does not require the > individual device drivers to query the spi_master about limitations > and replicate code in several drivers - also there is no maintenance cost on > individual device drivers to track when there is a new limitation introduced. You've got this back to front - drivers are responsible for initialising the master when they instantiate it. There's nothing stopping them using the data if they have variants to handle but they shouldn't be speculatively looking at it on the off chance there's some limit.
Attachment:
signature.asc
Description: PGP signature
