[lkml]   [2020]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2] clk: imx8mm: Switch to platform driver
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 <>
>>>>> Acked-by: Stephen Boyd <>
>>>> 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:
The only difference is that in the OK case this patch is applied:

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

 \ /
  Last update: 2020-03-17 11:47    [W:0.067 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site