Re: [mtd:nand/next 11/31] drivers/mtd/nand/raw/cadence-nand-controller.c:1893:4: error: implicit declaration of function 'ioread64_rep' is invalid in C99

[Valentin Korenblit <vkorenblit@sequans.com>]

[-- Attachment #1: Type: text/plain, Size: 2623 bytes --]

Hi Arnd, Miquel

On 9/22/22 12:52, Arnd Bergmann wrote:
> On Thu, Sep 22, 2022, at 11:36 AM, Miquel Raynal wrote:
>> vkorenblit(a)sequans.com  wrote on Thu, 22 Sep 2022 10:18:46 +0200:
>>> Correct, this was my initial idea. However, this driver should work
>>> with every architecture or do we limit the scope to arm/arm64/x86_64?
>> The driver should work on ARM and aarch64, I'm not aware of other
>> architectures with this IP.
>>
>> The driver should compile when COMPILE_TEST=y.
> It should also be written in a way that makes it plausible to
> use elsewhere. Since this is just a licensed IP core, there is
> a good chance that someone reused it on mips or riscv, or
> anything else.
>
>>>>> I believe what Valentin wanted to achieve in the first place, was to
>>>>> use 64-bit accesses when relevant (otherwise it does not work).
>>>> The width is read from a device specific register at
>>>> runtime, it is not related to the architecture you are
>>>> running on, presumably this is hardwired during the
>>>> design of an SoC, based on the capabilities of the DMA
>>>> engine:
>> Well, yes, but in the mean time 64-bit DMA width will never be
>> used on 32-bit platforms.
> Why? Most architectures (including x86 and arm) allow you to
> run a 32-bit kernel on a 64-bit SoC. While this is almost always
> a bad idea to actually do, a driver should be written to
> work correctly in this setup.
>
>>>> This usually means the largest access that is valid for
>>>> reading from the FIFO, but usually smaller accesses work
>>>> as well, just slower.
>> Mmh, ok, that's interesting, thanks for the pointer.
>>
>> But in the mean time I am only half satisfied, because we plan to do
>> twice more accesses than needed _just_ because of a the COMPILE_TEST
>> constraint.
> In my example, I had an #ifdef so it would only fall back
> to 32-bit accesses on the 64-bit register when running an
> actual 32-bit kernel, but leaving the 64-bit case efficient.

Sorry for my late reply. I've just tested this and unfortunately
the two sequential 32-bit accesses (with OFF0==0 and OFF1==4 seem
to trigger sdma_err. I need to check some waveforms to verify if it
happens right after the first access.

>      Arnd

Best regards,

Valentin
-- IMPORTANT NOTICE:



The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.



Thank you.

[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 4411 bytes --]