Re: SPI rework
.. what's wrong with your first suggestion? I liked it. :) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SPI rework
On Wed, 19 Oct 2011 19:14:07 +0800 Adrian Chadd adr...@freebsd.org wrote: .. what's wrong with your first suggestion? I liked it. :) Adrian Because we can't do duplex operations in that way. But if we use old struct, we will be able send and receive in the same time. I don't know if such device exists. But if we implement SPI device then we will be able to communicate between two FreeBSD boxes in a duplex manner! :) -- Aleksandr Rybalko r...@ddteam.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SPI rework
On Tue, 18 Oct 2011 06:17:46 +0800 Adrian Chadd adr...@freebsd.org wrote: Hi, That sounds logical to me. Maybe getting it done before 9.0-RELEASE is a bit rushed? I can help you test out the flash side of things on my atheros SoC boards. Adrian More thinking give me a better way to fix that. We leave same structure, but remove KASSERT(cmd-tx_cmd_sz == cmd-rx_cmd_sz,); and fix SPI controllers drivers to care about possible different sizes. And of course will fix consumers to set exact what they need. (dev/flash: cmd_tx_sz=1, data_rx_sz=3 for device ID call) That way better because we will have ability to duplex SPI transfers on controllers that able to do that, RT305x SPI will return error in case when sizes specified for both directions. Comments? WBW -- Alexandr Rybalko r...@dlink.ua aka Alex RAY r...@ddteam.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
SPI rework
Hi all!
I implement new SPI controller driver (for RT305XF) and found interest
problem: our current SPI implementation based on transfer data in
structure spi_command:
struct spi_command {
void*tx_cmd;
uint32_t tx_cmd_sz;
void*rx_cmd;
uint32_t rx_cmd_sz;
void*tx_data;
uint32_t tx_data_sz;
void*rx_data;
uint32_t rx_data_sz;
};
There is the problem 1, because all SPI requests I know use only two
transaction parts:
1 - write command (or read command if SPI slave)
2 - read/write device data
so something like:
{
void*cmd;
size_t cmd_sz;
uint32_tcmd_flags;
#define SPI_DIRECTION_READ (00)
#define SPI_DIRECTION_WRITE (10)
void*data;
size_t data_sz;
uint32_tdata_flags;
};
will be more accurate.
And the problem number 2: most controllers verify tx_cmd_sz ==
rx_cmd_sz, so seems `cmd` part must contain only request, and `data`
must contain only payload.
And the problem number 3: SPI flash driver for example:
set buf[0] = 0x9f; /* SPI flash identify query */
then
tx_cmd = buf;
tx_cmd_sz = rx_cmd_sz = 4;
And expect to receive device id in buf[1], buf[2], buf[3].
S, how controller will decide which part of `buf` is a command, and
which part is a data? And again which part should be to write, which
to read?
Somebody maybe ask me: Why you need it? Answer: because RT305XF spi
controller can't do bidirectional transfer, that controller can only
write or read.
Currently we have spi controllers for arm/at91 and mips/atheros (I have
also GPIO spi controller) and only one consumer for spibus -
dev/flash
I swear to take care about mips/atheros, dev/flash and dev/spibus,
but seems will need some help from someone who work with Atmel's.
It will be very nice to have it discussed and done before 9.0.
Will wait for any comments and suggestions.
WBW
--
Aleksandr Rybalko r...@ddteam.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SPI rework
Hi, That sounds logical to me. Maybe getting it done before 9.0-RELEASE is a bit rushed? I can help you test out the flash side of things on my atheros SoC boards. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
