Re: [PATCH] memory: renesas-rpc-if: Fix IO state based on flash type

[Michael Walle <michael@walle.cc>]

>> >> >> > 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.
> 
> Here, same 4-bit tx_mode IO pin (QSPIn_IO0 Fixed Value for 1-bit Size)
> to be configured based on flash type and bus width right?

Just bus width. There should be no dependency on the flash type.


> For eg: here Adesto flash requires HI-Z for IO3 pin and Micron flash
> requires setting "1" for IO3 pin for 4-bit mode to work.

That is odd. You'd need to ask Micron, but I assume it is because
IO3 is shared with hold# and reset#. And there is a note "For pin
configurations that share the DQ3 pin with RESET#, the RESET#
functionality is disabled in QIO-SPI mode". So I guess the reason
why they asking for a '1' is because they don't want to reset the
flash. I'm pretty sure, we don't really support this in linux, so
you'd probably want to disable that feature, i.e. see Table 7,
bit 4. You could also come around this by enabling a pull-up on
that line (assuming the SPI controller 'drives' HiZ during command
phase).


> 
> 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
>> >
>> >  [2] section 8.14
>> >
>> > https://www.renesas.com/eu/en/document/dst/at25ql128a-datasheet?r=1608
>> > 586
>> 
>> 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).
> 
> I agree, What about micron flash??
> 
> Cheers,
> Biju