Hi,
>> > I'm not sure we can do that, as this code is part of the hardware
>> > initialization during probing.
>> > Biju: is this needed that early, or can it be done later, after the
>> > connected device has been identified?
>>
>> I need to check that.
>>
>> You mean patch drivers/spi/spi-rpc-if.c to identify the flash type
>> from sfdp info and pass as a parameter to rpcif_hw_init??
>
> Something like that.
>
> That configuration should be saved somewhere, as rpcif_hw_init() is
> also called from rpcif_resume(), and when recovering from an error in
> rpcif_manual_xfer().
I'm not sure I follow everything here, but apparently you want to set
the
mode of the I/O pins of the controller, right? Shouldn't that depend
on the
spi-mem mode, i.e. the buswidth? Certainly not on the type of flash
which
is connected to the spi controller.
How do you handle the IO states sections mentioned in the HW manual[1]
and [2]?
What do you mean by "IO states" you don't configure anything on the SPI
flash, do you?
I guess you should have to configure your SoC SPI pins in your
.exec_op()
callback according to the buswidth property. Have a look at the other
spi drivers. I'm not that familiar with the spi controller drivers.
Without this setting flash detection/ read/write failing with tx in
4-bit mode.
[1] Figure 20: QUAD INPUT/OUTPUT FAST READ - EBh/ECh
https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-a/mt25q_qlks_u_512_aba_0.pdf?rev=3e5b2a574f7b4790b6e58dacf4c889b2
[2] section 8.14
https://www.renesas.com/eu/en/document/dst/at25ql128a-datasheet?r=1608586
Section 8.14 shows a Read with Quad I/O and the flash will tri-state
the I/O lines during the command and dummy phase and drive them during
data phase (and expect an address from the SoC on all I/Os during
address
and mode phase).
-michael