Re: [PATCH v2] clk: imx8mm: Switch to platform driver

[Schrempf Frieder <frieder.schrempf@kontron.de>]

Hi Peng,

On 17.03.20 04:56, Peng Fan wrote:
>> Subject: Re: [PATCH v2] clk: imx8mm: Switch to platform driver
>>
>> On 06.02.20 11:37, Frieder Schrempf wrote:
>>> On 06.02.20 11:34, Schrempf Frieder wrote:
>>>> Hi,
>>>>
>>>> On 09.07.19 16:20, Abel Vesa wrote:
>>>>> There is no strong reason for this to use CLK_OF_DECLARE instead of
>>>>> being a platform driver. Plus, this will now be aligned with the
>>>>> other i.MX8M clock drivers which are platform drivers.
>>>>>
>>>>> In order to make the clock provider a platform driver all the data
>>>>> and code needs to be outside of .init section.
>>>>>
>>>>> Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
>>>>> Acked-by: Stephen Boyd <sboyd@kernel.org>
>>>>
>>>> This has been upstream for quite some time now, but somehow I have an
>>>> issue with SPI on the i.MX8MM that gets resolved when I revert this
>>>> patch.
>>>>
>>>> When I try to probe an SPI NOR flash with latest 5.4 or even 5.5:
>>>>
>>>>      spi_imx 30820000.spi: dma setup error -19, use pio
>>>>      spi-nor spi0.0: unrecognized JEDEC id bytes: 00 00 00 00 00 00
>>>>      spi_imx 30820000.spi: probed
>>>>
>>>> When I revert this patch:
>>>>
>>>>      spi_imx 30820000.spi: dma setup error -19, use pio
>>>>      spi-nor spi0.0: mx25r1635f (2048 Kbytes)
>>>>      spi_imx 30820000.spi: probed
>>>>
>>>> Please note, that in both cases I have disabled DMA, as this causes
>>>> even more trouble (see [1]). But even with DMA enabled and ignoring
>>>> the DMA errors, the issue described above occurs.
>>>>
>>>> Does someone have an idea what's wrong?
>>>> Am I the only user of SPI on i.MX8MM as this issue seems to exist
>>>> upstream since v5.4-rc1?
>>
>> This issue still persists in v5.6-rc6. Can someone please have a look?
> 
> Would you post your full boot log somewhere?

Sure, the two bootlogs are here: https://paste.ee/p/8uDwd.
The only difference is that in the OK case this patch is applied: 
https://paste.ee/p/xUBrO

> 
> With success/fail case, are there any differences in spi controller registers?
> I suppose no.

No, they are the same, except for BURST_LENGTH in ECSPI1_CONREG, which 
is 0x2F in case of failure and 0x3F in case it is working. But I guess 
that's a result of the failed/successful transfers.

> 
> Did you measure the signal saying data in when cs is low?

It's a bit difficult to access the signals on the board so I didn't 
check the signals, yet.

> 
> Anyway it is a bit wired since this patch just delayed the probe for a while.

Yes, it's really weird and it's very unfortunate that the EVK does not 
have a SPI device onboard. I guess that would have helped to prevent 
regressions due to better testing.

If you have any suggestions, please let me know.

Thanks,
Frieder