Re: [PATCH] mtd: spi-nor: spansion: Add support for CY15V104QSN

From: Tudor Ambarus <tudor.ambarus@linaro.org>
To: LECOINTRE Philippe <philippe.lecointre@thalesgroup.com>,
	Pratyush Yadav <pratyush@kernel.org>,
	Michael Walle <mwalle@kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Cc: LEJEUNE Sebastien <sebastien.lejeune@thalesgroup.com>,
	LENAIN Simon <simon.lenain@thalesgroup.com>,
	RENAULT Xavier <xavier.renault@thalesgroup.com>
Subject: Re: [PATCH] mtd: spi-nor: spansion: Add support for CY15V104QSN
Date: Fri, 21 Mar 2025 07:10:57 +0000	[thread overview]
Message-ID: <3c176372-ad82-460f-979e-9bf1cf09d931@linaro.org> (raw)
In-Reply-To: <a76c17aeb7a645b9a5adbc79c2337b16@thalesgroup.com>

On 3/20/25 4:55 PM, LECOINTRE Philippe wrote:

>> I encounter some issue attempting to use the at25 driver.
>>> I am not able to read the flash ID with at25 driver because the chipselect
>> appear to be deselected between the RDID command and the read data. The
>> RDID command is not taken into account and the chip only reply with 0xff.
>>> With at25 driver, it use a spi_message containing two spi_transfer, one
>> spi_transfer for the command and one spi_transfer for the read data. For
>> some reason, this end up in .transfer_one() in the spi_controller driver of my
>> SoC.
>>
>> What spi controller driver, is it upstreamed?
> 
> The SoC use the upstream "snps,dw-apb-ssi" spi controller driver.
> 
>>
>>> With spi-nor driver, it use spi_mem_exec_op() which work well in my case.
>>> It appear at25 driver can currently be used with Cypress FM25 chip and
>> from some of the datasheet of this family it seems that the chipselect need
>> to be driven low during the entire RDID sequence.
>>> Am I missing something here ?
>>
>> Splitting opcode, address, dummy and data per spi_transfers shall work,
>> spi_mem_exec_op() does it too when the controller does not define
>> mem_ops.
>>
>> It probably just a bug somewhere, raising CS up between the transfers shall
>> be fine.
> 
> Using an oscilloscope with spi protocol decode, it is the big difference I can see.
> 
>>>
>>> Currently, the at25 driver assume a lot of property from the ID data
>> (manufacturer and size) which don't seems to be relevant with the
>> CY15V104QSN model.
>>> This chip is similar to cy15b104q and cy15v104q currently supported by spi-
>> nor driver.
>>> https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/c
>>> ommit/drivers/mtd/spi-
>> nor/spansion.c?id=8a2644d5f3608822925c9204a3d19a
>>> 8e3025fd4a
>>
>> having those flashes in SPI NOR was a mistake. We can't just drop them as
>> we'll break backward compatibility.
>>
>>> Also, I don't have access to at25 spi eeprom to validate any deep
>> modifications on this driver if we need to do so according to the thread you
>> are pointing to.
>>>
>>> How can we handle this ?
>>
>> You need to figure out why your flash doesn't work as expected and fix it. Is
>> your controller spimem capable? If yes, try dropping the ctrl mem_ops and
>> see if it behaves sane using SPI NOR and the controller using spi transfers. If
>> it doesn't behave sane, then there's probably a problem into the controller
>> driver.
> 
> Good advice !
> I have commented out the dw_spi_init_mem_ops() function call in dw_spi_add_host() and I end up with the same result as at25 driver.
> spi-nor spi3.0: unrecognized JEDEC id bytes: ff ff ff ff ff ff

Can you plugin a different flash and test?

What frequency are you running the flash? Do things improve if you run
it at 50 MHz for example?

Cheers,
ta

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