SD-over-SPI with shared SPI bus

SD-over-SPI with shared SPI bus

[Leonardo Rodrigues Magalhães]

    Hello Guys,

    is there any news on the mmc_spi driver which supports shared SPI 
bus ???

    i'm looking for this feature for enabling MicroSD support on some 
RouterBoard boards with OpenWRT.

    Thanks.

-- 


	Atenciosamente / Sincerily,
	Leonardo Rodrigues
	Solutti Tecnologia
	http://www.solutti.com.br

	Minha armadilha de SPAM, NÃO mandem email
	gertrudes-RDcRC1KzKCbQ4tFLR8X5nw@public.gmane.org
	My SPAMTRAP, do not email it





------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB

SD-over-SPI with shared SPI bus

[Hendrik Sattler]

Hi,

I contact you because you are mentioned in the MAINTAINERS file of  
linux-2.6.26 for the mmc_spi drive and SPI subsystem.

I want to share the bus with other SPI devices. The drivers mentions  
pending updates that would allow that.
Are those available somewhere?

If not, the changes seem to fairly trivial: change SPI controller  
drivers to allow adding a spi_transfer to an spi_message during the  
complete() callback or add another callback that can do this.

Additionally, the current definition of a chipselect number seems not  
optimal. The pxa2xx driver even has it's own way to overcome this. The  
problem is that the method about activating a device might not be that  
sequentially numbered,
e.g. I have devices here that have a group chipselect with a  
subchipselect beside it.
I suggest to actually tell the owner of the spi_transfer and  
spi_message when a specific transfer starts and ends. The chipselect  
could still be handled by the spi controller driver but e.g. the  
subchipselect could be handled by the spi group device driver. Another  
use case would be devices that needs e.g. to be powered-up/-down.

Finally: is there a working SPI controller driver for the IXP46x out  
there? The register layout is mostly like the PX2xx driver the IXP46x  
doesn't have the DMA engine of the PXA2xx.

Thanks for your help.

HS

PS: For the list, please CC me as I am not subscribed.



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: SD-over-SPI with shared SPI bus

[Erwin Authried]

Am Donnerstag, den 21.08.2008, 10:46 +0200 schrieb Hendrik Sattler:
> Hi,
> 
> I contact you because you are mentioned in the MAINTAINERS file of  
> linux-2.6.26 for the mmc_spi drive and SPI subsystem.
> 
> I want to share the bus with other SPI devices. The drivers mentions  
> pending updates that would allow that.
> Are those available somewhere?
> 
> If not, the changes seem to fairly trivial: change SPI controller  
> drivers to allow adding a spi_transfer to an spi_message during the  
> complete() callback or add another callback that can do this.

Hi,

I have done this in a slightly different, rather simple way. I have
added a new "transfer_end" callback function pointer to the spi_transfer
structure. This function can have three return values: 

<0 ... stop spi message after the transfer
0  ... continue with next transfer 
1  ... repeat current transfer

If the transfer_end callback is not required, the function pointer must
be set to NULL.

I have modified the bitbang driver for this new functionality. In
addition, the mmc_spi driver has been changed to make use of the
callback function. It is necessary to pack all transfers that must be
done without being interrupted into a single message. I have done a lot
of testing with a SD card on a shared bus with a lot of other activity,
and I couldn't see any problems. 

Regards,
Erwin



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: SD-over-SPI with shared SPI bus

[Hendrik Sattler]

Zitat von Erwin Authried <eauth-T13/FXdtSm+ALaLeEb27IQ@public.gmane.org>:

> Am Donnerstag, den 21.08.2008, 10:46 +0200 schrieb Hendrik Sattler:
>> Hi,
>>
>> I contact you because you are mentioned in the MAINTAINERS file of
>> linux-2.6.26 for the mmc_spi drive and SPI subsystem.
>>
>> I want to share the bus with other SPI devices. The drivers mentions
>> pending updates that would allow that.
>> Are those available somewhere?
>>
>> If not, the changes seem to fairly trivial: change SPI controller
>> drivers to allow adding a spi_transfer to an spi_message during the
>> complete() callback or add another callback that can do this.
>
> Hi,
>
> I have done this in a slightly different, rather simple way. I have
> added a new "transfer_end" callback function pointer to the spi_transfer
> structure. This function can have three return values:
>
> <0 ... stop spi message after the transfer
> 0  ... continue with next transfer
> 1  ... repeat current transfer
>
> If the transfer_end callback is not required, the function pointer must
> be set to NULL.
>
> I have modified the bitbang driver for this new functionality. In
> addition, the mmc_spi driver has been changed to make use of the
> callback function. It is necessary to pack all transfers that must be
> done without being interrupted into a single message. I have done a lot
> of testing with a SD card on a shared bus with a lot of other activity,
> and I couldn't see any problems.

I'd imagine something like this but instead of the return code, let it  
fill/clear spi_message::transfers as it likes during this callback and  
let the caller check the that after the callback (list_empty()).

Nice to know that there are no further pitfalls :)

HS



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: SD-over-SPI with shared SPI bus

[Erwin Authried]

Am Donnerstag, den 21.08.2008, 11:47 +0200 schrieb Hendrik Sattler:
> Zitat von Erwin Authried <eauth-T13/FXdtSm+ALaLeEb27IQ@public.gmane.org>:
> 
> > Am Donnerstag, den 21.08.2008, 10:46 +0200 schrieb Hendrik Sattler:
> >> Hi,
> >>
> >> I contact you because you are mentioned in the MAINTAINERS file of
> >> linux-2.6.26 for the mmc_spi drive and SPI subsystem.
> >>
> >> I want to share the bus with other SPI devices. The drivers mentions
> >> pending updates that would allow that.
> >> Are those available somewhere?
> >>
> >> If not, the changes seem to fairly trivial: change SPI controller
> >> drivers to allow adding a spi_transfer to an spi_message during the
> >> complete() callback or add another callback that can do this.
> >
> > Hi,
> >
> > I have done this in a slightly different, rather simple way. I have
> > added a new "transfer_end" callback function pointer to the spi_transfer
> > structure. This function can have three return values:
> >
> > <0 ... stop spi message after the transfer
> > 0  ... continue with next transfer
> > 1  ... repeat current transfer
> >
> > If the transfer_end callback is not required, the function pointer must
> > be set to NULL.
> >
> > I have modified the bitbang driver for this new functionality. In
> > addition, the mmc_spi driver has been changed to make use of the
> > callback function. It is necessary to pack all transfers that must be
> > done without being interrupted into a single message. I have done a lot
> > of testing with a SD card on a shared bus with a lot of other activity,
> > and I couldn't see any problems.
> 
> I'd imagine something like this but instead of the return code, let it  
> fill/clear spi_message::transfers as it likes during this callback and  
> let the caller check the that after the callback (list_empty()).
> 
I wanted to keep it simple. You can modify the buffers in the callback
function and repeat that transfer (with return code 1), thus there are
virtually no restrictions in the message transfers.

> Nice to know that there are no further pitfalls :)
There are a few hacks that I had to do during initialization of the SD
card. The cards seem to be quite fuzzy if someone else is using the bus
during this phase. I'll need some time to see if my changes are working
with the actual version, and I'll post the patch then.

Regards,
Erwin



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/