[PATCH 1/6] Revert "spi: zynq_qspi: Add parallel memories support in QSPI driver"

[Marek Vasut]

On 11/6/24 10:58 PM, Jon Humphreys wrote:
> Marek Vasut <marek.vasut at mailbox.org> writes:
> 
>> On 11/6/24 8:18 PM, Jon Humphreys wrote:
>>> Marek Vasut <marek.vasut at mailbox.org> writes:
>>>
>>>> On 10/23/24 10:17 AM, Michal Simek wrote:
>>>>>
>>>>>
>>>>> On 10/22/24 23:06, Marek Vasut wrote:
>>>>>> This reverts commit 1e36d34b52e7a1ebe5a2a5339d6905540f4253aa.
>>>>>>
>>>>>> This parallel/stacked support breaks basic SPI NOR support,
>>>>>> e.g. this no longer works:
>>>>>>
>>>>>> => sf probe && sf update 0x50000000 0 0x160000
>>>>>> SF: Detected s25fs512s with page size 256 Bytes, erase size 256 KiB,
>>>>>> total 64 MiB
>>>>>> device 0 offset 0x0, size 0x160000
>>>>>> SPI flash failed in read step
>>>>>
>>>>> Reverting everything seems to me too much. Tom has tested it on his HW
>>>>> and didn't see any issue. That's why better to look at code which is
>>>>> causing this.
>>>>> You are reverting everything but likely there is specific patch which is
>>>>> causing this. Which one is it?
>>>>> Which board was used for your testing? Likely we don't have access to it.
>>>>> Is there any QEMU available which can be used for debugging?
>>>>
>>>> The testcase including the exact SPI NOR model is above.
>>>>
>>>> iMX6 with w25q16dw seems to be broken too.
>>>>
>>>> Basically every board I have access no longer has a working "sf probe ;
>>>> sf update" combination ... so yeah, this means this patchset is
>>>> fundamentally broken.
>>>>
>>>
>>> I can also confirm that the patch series:
>>>
>>> f8efc68b30e Merge patch series "spi-nor: Add parallel and stacked memories
>>> support"
>>>
>>> breaks SPI NOR on TI platforms, particularly SK-AM62 and SK-AM62P:
>>>
>>> U-Boot 2024.10-00752-gf8efc68b30e2 (Nov 06 2024 - 12:25:13 -0600)
>>>
>>> SoC:   AM62X SR1.0 HS-FS
>>> Model: Texas Instruments AM625 SK
>>> ...
>>> Hit any key to stop autoboot:  0
>>> => sf probe && sf update ${loadaddr} 0x400000 0x10
>>> SF: Detected s28hs512t with page size 256 Bytes, erase size 256 KiB, total 64 MiB
>>> device 0 offset 0x400000, size 0x10
>>> SPI flash failed in read step
>>> =>
>> Sigh ... can you please test current u-boot/master and see if the error
>> is fixed there ?
>>
> 
> Yes I had verified it also fails against master, although the behavior was
> a bit different.  The .'s below are our DMA engine waiting indefinitely.
> 
> => sf probe && sf update ${loadaddr} 0x400000 0x10
> SF: Detected s28hs512t with page size 256 Bytes, erase size 256 KiB, total 64 MiB
> device 0 offset 0x400000, size 0x10
> .....................................................
> 
> I have not investigated further.

Can you try and run some 'git bisect' to find out exactly which commit 
broke your use case ? There is a bunch of fixes for the worst breakage 
that landed recently, but clearly there is more.

Full revert seems increasingly appealing ...