> > > pretty much all SPI flashes have two read commands ("slow" and "fast"
> > > as they're typically called).
> >
> > Not DataFlash.
>
> doesnt it ? AT45DB642D says 0x0B is fast (up to 66mhz) while 0x03 (up to
> 33mhz)
And ...041B, ...081B, ...161B, ...321, ...321C, and others don't.
(From a
On 10/31/07, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 31 October 2007, Mike Frysinger wrote:
> > On 10/31/07, David Brownell <[EMAIL PROTECTED]> wrote:
> > > (ISTR the M25P16 in $SUBJECT has two read commands, one of
> > > which is only usable at clock rates below 33 MHz or so, but
On Wednesday 31 October 2007, Mike Frysinger wrote:
> On 10/31/07, David Brownell <[EMAIL PROTECTED]> wrote:
> > (ISTR the M25P16 in $SUBJECT has two read commands, one of
> > which is only usable at clock rates below 33 MHz or so, but
> > most other commands can work above that speed just fine.)
On Wed, 2007-10-31 at 01:02 -0700, David Brownell wrote:
> On Wednesday 31 October 2007, Bryan Wu wrote:
> > IMO, the spi_transfer.speed_hz <= spi_board_info.max_speed_hz and if
> > spi_trasnfer.speed_hz is 0, we should use spi_board_info.max_speed_hz.
> > From the meaning of max_speed_hz, the
On 10/31/07, David Brownell <[EMAIL PROTECTED]> wrote:
> (ISTR the M25P16 in $SUBJECT has two read commands, one of
> which is only usable at clock rates below 33 MHz or so, but
> most other commands can work above that speed just fine.)
pretty much all SPI flashes have two read commands ("slow"
On Wednesday 31 October 2007, Bryan Wu wrote:
> IMO, the spi_transfer.speed_hz <= spi_board_info.max_speed_hz and if
> spi_trasnfer.speed_hz is 0, we should use spi_board_info.max_speed_hz.
> From the meaning of max_speed_hz, the spi_transfer.speed_hz should not
> beyond max_speed_hz.
According
On Wed, 2007-10-31 at 00:11 -0700, David Brownell wrote:
> On Tuesday 30 October 2007, Bryan Wu wrote:
> > Maybe there are some confusion of mixing up the spi_trasnfer.speed_hz
> > with the spi_device.max_speed_hz.
> >
> > spi_device.max_speed_hz comes from spi_board_info.max_speed_hz, it is
> >
On Tuesday 30 October 2007, Bryan Wu wrote:
> Maybe there are some confusion of mixing up the spi_trasnfer.speed_hz
> with the spi_device.max_speed_hz.
>
> spi_device.max_speed_hz comes from spi_board_info.max_speed_hz, it is
> for the default max speed value.
It's initialized from board_info,
On Tuesday 30 October 2007, Bryan Wu wrote:
Maybe there are some confusion of mixing up the spi_trasnfer.speed_hz
with the spi_device.max_speed_hz.
spi_device.max_speed_hz comes from spi_board_info.max_speed_hz, it is
for the default max speed value.
It's initialized from board_info, yes.
On Wed, 2007-10-31 at 00:11 -0700, David Brownell wrote:
On Tuesday 30 October 2007, Bryan Wu wrote:
Maybe there are some confusion of mixing up the spi_trasnfer.speed_hz
with the spi_device.max_speed_hz.
spi_device.max_speed_hz comes from spi_board_info.max_speed_hz, it is
for the
On Wednesday 31 October 2007, Bryan Wu wrote:
IMO, the spi_transfer.speed_hz = spi_board_info.max_speed_hz and if
spi_trasnfer.speed_hz is 0, we should use spi_board_info.max_speed_hz.
From the meaning of max_speed_hz, the spi_transfer.speed_hz should not
beyond max_speed_hz.
According to the
On 10/31/07, David Brownell [EMAIL PROTECTED] wrote:
(ISTR the M25P16 in $SUBJECT has two read commands, one of
which is only usable at clock rates below 33 MHz or so, but
most other commands can work above that speed just fine.)
pretty much all SPI flashes have two read commands (slow and
On Wed, 2007-10-31 at 01:02 -0700, David Brownell wrote:
On Wednesday 31 October 2007, Bryan Wu wrote:
IMO, the spi_transfer.speed_hz = spi_board_info.max_speed_hz and if
spi_trasnfer.speed_hz is 0, we should use spi_board_info.max_speed_hz.
From the meaning of max_speed_hz, the
On 10/31/07, David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 31 October 2007, Mike Frysinger wrote:
On 10/31/07, David Brownell [EMAIL PROTECTED] wrote:
(ISTR the M25P16 in $SUBJECT has two read commands, one of
which is only usable at clock rates below 33 MHz or so, but
most
On Wednesday 31 October 2007, Mike Frysinger wrote:
On 10/31/07, David Brownell [EMAIL PROTECTED] wrote:
(ISTR the M25P16 in $SUBJECT has two read commands, one of
which is only usable at clock rates below 33 MHz or so, but
most other commands can work above that speed just fine.)
pretty
pretty much all SPI flashes have two read commands (slow and fast
as they're typically called).
Not DataFlash.
doesnt it ? AT45DB642D says 0x0B is fast (up to 66mhz) while 0x03 (up to
33mhz)
And ...041B, ...081B, ...161B, ...321, ...321C, and others don't.
(From a quick scan of
On Tue, 2007-10-30 at 13:05 -0700, David Brownell wrote:
> On Tuesday 30 October 2007, Bryan Wu wrote:
> > Current SPI driver enables SPI controller and set the SPI baud register
> > for each SPI transfer. But, they should never be changed within a SPI
> > message session, in which seveal SPI
On Tuesday 30 October 2007, Bryan Wu wrote:
> Current SPI driver enables SPI controller and set the SPI baud register
> for each SPI transfer. But, they should never be changed within a SPI
> message session, in which seveal SPI transfers are pumped.
That's actually not true. If a driver sets
From: Sonic Zhang <[EMAIL PROTECTED]>
Current SPI driver enables SPI controller and set the SPI baud register
for each SPI transfer. But, they should never be changed within a SPI
message session, in which seveal SPI transfers are pumped. This patch
move move SPI setting to the begining of a
From: Sonic Zhang [EMAIL PROTECTED]
Current SPI driver enables SPI controller and set the SPI baud register
for each SPI transfer. But, they should never be changed within a SPI
message session, in which seveal SPI transfers are pumped. This patch
move move SPI setting to the begining of a
On Tuesday 30 October 2007, Bryan Wu wrote:
Current SPI driver enables SPI controller and set the SPI baud register
for each SPI transfer. But, they should never be changed within a SPI
message session, in which seveal SPI transfers are pumped.
That's actually not true. If a driver sets
On Tue, 2007-10-30 at 13:05 -0700, David Brownell wrote:
On Tuesday 30 October 2007, Bryan Wu wrote:
Current SPI driver enables SPI controller and set the SPI baud register
for each SPI transfer. But, they should never be changed within a SPI
message session, in which seveal SPI transfers
22 matches
Mail list logo
