> On 22.05.2015, at 13:34, Mark Brown <broonie@xxxxxxxxxx> wrote: > > Quite a few process issues here which are rather annoying so I'm just > going to ignore the technical content for now. > Accepting those - thanks for the clarifications. > >> If you can tell me that: >> (master->flags & (SPI_MASTER_MUST_TX | SPI_MASTER_MUST_RX)) && >> master->can_dma && master->can_dma(...) >> means that we do NOT need real memory allocated in the first place but >> we only expect a scatter list to be created >> and memory allocated in all other cases then that be it. > > I replied to your last mail on this in the other thread. Well - I will take that as a yes. With the logic based only on can_dma we still would be allocating memory for those cases where can_dma returns false - even if the driver only requires the scatter/gather list but would not require memory for those rx/tx_buf == NULL cases (which is the case for the spi-bcm2835). The extra flags solve that requirement cleanly. An alternative would be that we provide a spi_map_dummy function that the driver could call explicitly if it just needs the scatter_gather list for null-buffers and leave the master->flags = 0. One other reasons was that with this logic we need to run can_dma several times in the process at different stages which is a waste of CPU-resources (especially as the compiler can not inline those function pointer calls). To reduce that overhead, would it be acceptable if we add a field to spi_transfer (and possibly to spi_message) - say bool can_dma - that is filled during the loop over all the transfers in __spi_validate? Essentially adding something like this to __spi_validate: message->can_dma = false; list_for_each_entry(xfer, &message->transfers, transfer_list) { /* calculate can_dma once and cache it */ xfer->can_dma = master->can_dma ? master->can_dma(xfer) : false; /* and set it also in the message itself */ message->can_dma |= xfer->can_dma } -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html