Re: [PATCH V2 - RESEND] SPI: BCM2835: allow arbitrary GPIO to act as SPI-chip_select

[Martin Sperl <kernel@xxxxxxxxxxxxxxxx>]

> 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.

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.
> 
> We've been round this loop repeatedly, as we've discussed improving the
> framework is a good idea.

That is what I try to do provide something we can take as a template
and then come up with approaches how we can generalize it to other
use-cases.

>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.

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?

>> Keeping it as is means we can easily backport(=copy) it to the kernel
>> that the RPI foundation maintains and that gets lots of exposure and
>> testing.
> The thing to do here is to get this code upstream, supporting out of
> tree code isn't particularly persuasive here - people commonly try to
> use their out of tree requirements as a reason to merge code that's
> got problems upstream and I don't want people to get the idea that this
> is an argument that's going to work.

That is what I am doing: I am developing on spi/for-next and if we get
something of interest we will merge into the 3.18 kernel that the 
foundation is using - not the other way around!

Note that in principle you can take: bcm2835_spi_start_transfer
and use that as transfer_one (it needs master as an extra argument)
also there is the bcm2835_spi_finish_transfer that we would need to
move to some other place...

So to summarize: do you want me to move to transfer_one instead and
then revert back for the optimizations?

Thanks,
	Martin


--
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