Re: [PATCH] [RFC] spi: cadence-quadspi: Disable DAC on SoCFPGA

[Marek Vasut <marex@denx.de>]

On 2/23/22 17:46, Dinh Nguyen wrote:
> 
> 
> On 2/23/22 10:43, Marek Vasut wrote:
>> On 2/23/22 17:28, Dinh Nguyen wrote:
>>>
>>>
>>> On 2/22/22 18:54, Marek Vasut wrote:
>>>> On 2/22/22 22:32, Dinh Nguyen wrote:
>>>>>
>>>>>
>>>>> On 2/22/22 12:30, Marek Vasut wrote:
>>>>>> On 2/22/22 16:49, Dinh Nguyen wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 2/21/22 11:05, Marek Vasut wrote:
>>>>>>>> On 2/21/22 17:38, Dinh Nguyen wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2/20/22 22:32, Marek Vasut wrote:
>>>>>>>>>> On SoCFPGA Gen5, DAC memcpy_fromio() in 
>>>>>>>>>> cqspi_direct_read_execute()
>>>>>>>>>> leads to data abort, disable DAC to avoid triggering it:
>>>>>>>>>>
>>>>>>>>>> Unhandled fault: imprecise external abort (0x1406) at 0x0400d3e9
>>>>>>>>>> [0400d3e9] *pgd=00000000
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>>>>>>>>> Cc: Dinh Nguyen <dinguyen@kernel.org>
>>>>>>>>>> Cc: Pratyush Yadav <p.yadav@ti.com>
>>>>>>>>>> ---
>>>>>>>>>>   drivers/spi/spi-cadence-quadspi.c | 2 +-
>>>>>>>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/spi/spi-cadence-quadspi.c 
>>>>>>>>>> b/drivers/spi/spi-cadence-quadspi.c
>>>>>>>>>> index b808c94641fa6..65f2c2449be09 100644
>>>>>>>>>> --- a/drivers/spi/spi-cadence-quadspi.c
>>>>>>>>>> +++ b/drivers/spi/spi-cadence-quadspi.c
>>>>>>>>>> @@ -1870,7 +1870,7 @@ static const struct 
>>>>>>>>>> cqspi_driver_platdata intel_lgm_qspi = {
>>>>>>>>>>   };
>>>>>>>>>>   static const struct cqspi_driver_platdata socfpga_qspi = {
>>>>>>>>>> -    .quirks = CQSPI_NO_SUPPORT_WR_COMPLETION,
>>>>>>>>>> +    .quirks = CQSPI_DISABLE_DAC_MODE | 
>>>>>>>>>> CQSPI_NO_SUPPORT_WR_COMPLETION,
>>>>>>>>>>   };
>>>>>>>>>>   static const struct cqspi_driver_platdata versal_ospi = {
>>>>>>>>>
>>>>>>>>> Acked-by: Dinh Nguyen <dinguyen@kernel.org>
>>>>>>>>
>>>>>>>> Is this DAC really not working on socfpga gen5 or is there some 
>>>>>>>> other issue ?
>>>>>>>
>>>>>>> I don't know the answer to this question. What is the DAC in the 
>>>>>>> QSPI module and how do I go about testing it?
>>>>>>
>>>>>> DAC = direct access.
>>>>>>
>>>>>> How do you go about testing this -- compile kernel with/without 
>>>>>> this patch, boot on SoCFPGA Gen5 with QSPI NOR attached, the 
>>>>>> kernel crashes without this patch on imprecise external abort.
>>>>>
>>>>> Hmm...I just tested v5.17-rc3 on a C5 board and QSPI looks to be 
>>>>> working fine:
>>>>>
>>>>> [    1.744489] spi-nor spi1.0: found n25q512ax3, expected mt25qu02g
>>>>> [    1.750534] dma-pl330 ffe01000.pdma: Reset Channel-0  CS-f 
>>>>> FTC-40000
>>>>> [    1.756941] spi-nor spi1.0: n25q512ax3 (65536 Kbytes)
>>>>> [    1.762369] 2 fixed-partitions partitions found on MTD device 
>>>>> ff705000.spi.0
>>>>> [    1.769425] Creating 2 MTD partitions on "ff705000.spi.0":
>>>>> [    1.774925] 0x000000000000-0x000000800000 : "Flash 0 Raw Data"
>>>>> [    1.781942] 0x000000800000-0x000008000000 : "Flash 0 jffs2 
>>>>> Filesystem"
>>>>> [    1.788468] mtd: partition "Flash 0 jffs2 Filesystem" extends 
>>>>> beyond the end of device "ff705000.spi.0" -- size truncated to 
>>>>> 0x3800000
>>>>
>>>> I wonder if we might be missing some clock enable somewhere.
>>>>
>>>> Can you mail me the whole boot log ? (I'm using u-boot 2022.01 btw.)
>>>
>>> I tested with U-Boot 2022.01 as well:
>>>
>>>
>>> => run nfsboot_dinh
>>> Kernel image @ 0x1000000 [ 0x000000 - 0x54edd0 ]
>>> ## Flattened Device Tree blob at 02000000
>>>     Booting using the fdt blob at 0x2000000
>>>     Loading Device Tree to 09ff8000, end 09fffeb1 ... OK
>>>
>>> Starting kernel ...
>>>
>>> Deasserting all peripheral resets
>>> [    0.000000] Booting Linux on physical CPU 0x0
>>> [    0.000000] Linux version 5.17.0-rc3 (dinguyen@linux-builds1) 
>>> (arm-linux-gnue abihf-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0, 
>>> GNU ld (GNU Binutils for U buntu) 2.30) #1 SMP Wed Feb 23 08:51:18 
>>> CST 2022
>>> [    0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), 
>>> cr=10c5387d
>>> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
>>> instructio n cache
>>> [    0.000000] OF: fdt: Machine model: Altera SOCFPGA Cyclone V SoC 
>>> Development  Kit
>>> [    0.000000] Memory policy: Data cache writealloc
>>
>> This is weird.
>>
>> One more thing, I have two SPI NORs on this CQSPI, one on each chip 
>> select, do you think that can make any difference ?
>>
>> Besides that, I used latest next for my tests, not latest linus tree.
> 
> Let me test on latest next.

Thank you

If you cannot reproduce it there, drop this patch and I'll revisit this 
on my side.