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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> >> > 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



[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux