On Wed, Mar 25, 2015 at 06:59:22PM +0100, Martin Sperl wrote: > > On 25.03.2015, at 17:54, Mark Brown <broonie@xxxxxxxxxx> wrote: > > There is no need for it to be exported, as I said you simply need to set > > cs_gpio and it will be used. > That is not true, because for that to work you need to move the driver > away from using transfer_one_message to use transfer_one. I'm confused. You're writing a set_cs() operation but you can't use it? > But then, as explained I have to revert back to transfer_one_message > to implement the "aggregating/handling" of transfers inside the interrupt > handler itself without having to call complete(master->xfer_completion) > on every spi_transfer. If I wrap it arround transfer_one the code will > look ugly, as it needs to work arround limitations of this api. This sounds like you're trying to work aroud the core rather than work with the core - enhance the core so that it can express what you need. > From my perspective I want to minimize the dependencies while I create > this proof of concept. > And for my testing this with several different devices I need support > for multiple devices and for that I need this patch go in first. > Taking baby steps here. I had been under the impression that you had already done a lot of proof of concept work with this stuff? > Also there is another point here, that Stephen pointed out: > Would not a switch from the use of the "native-cs" to "gpio-only" mean > a required change in Device-tree? And isn't DT assumed to be a stabe API? Can you be more specific about what change you think might be required? Currently the driver doesn't support GPIOs as chip selects at all so anything enabling them is going to be new. > So to summarize: do you want me to move to transfer_one instead and > then revert back for the optimizations? Drivers should in general be moving to use modern APIs. If current APIs need enhancing then look into doing that.
Attachment:
signature.asc
Description: Digital signature
