Re: [PATCH] mtd: spi-nor: core: Introduce spi_nor_abort_octal_dtr()

[Michael Walle <michael@walle.cc>]

Hi,

>> > Some flashes contains 8D_8D_8D information in SFDP but did not enter
>> > octal DTR mode if conditions are not satisfied.
>> 
>> What exactly are these conditions? Rather than "abort" the octal mode,
>> the flash shouldn't have that capability in the first place.
> "Abort" is not a good word.
> Is it better for using "discard"?
> 3 conditions should be satisfied before enable octal dtr mode.
> 1. function hook in nor->params->set_octal_dtr
> 2. nor->read_proto and nor->write_proto are SNOR_PROTO_8_8_8_DTR
> 3. nor->flags & SNOR_F_IO_MODE_EN_VOLATILE
> Flash driver still bring 8D_8D_8D protocol instructions in 1s-1s-1s 
> mode if
> conditions are not satisfied.
> In a case, flash ID didn't include in vendor's ID table.
> It will be "spi-nor-generic".
> 8D-8D-8D information could be parsed in SFDP but 
> nor->params->set_octal_dtr
> didn't hook vendor specific function for enabling octal dtr mode.
> So that it still bring 8D protocol in 1s-1s-1s mode and have no chance
> to select 1-1-8 protocol.
> I think it may better to re-select a suitable protocol for this case.

Just that we are on the same page. You are using the spi-nor-generic
driver, but that driver will elect the 8d8d8d protocol but that won't
work, because we don't have a .set_octal_dtr. Therefore, the fallback
is 1s1s1s. Correct?

To me it seems, that spi_nor_select_{read,pp,erase}() will select
the wrong commands/proto. So it should be fixed there. Probably
shared_mask is wrong.

-michael

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/