[PATCH v6 2/2] mtd: rawnand: nuvoton: add new driver for the Nuvoton MA35 SoC
Hui-Ping Chen
hpchen0nvt at gmail.com
Thu Oct 10 17:31:41 PDT 2024
Dear Miquel,
Thank you for your reply.
On 2024/10/9 下午 04:04, Miquel Raynal wrote:
> Hi Hui-Ping,
>
>>>>>> + return 0;
>>>>>> + }
>>>>>> +
>>>>>> + ma35_nand_dmac_init(nand);
>>>>>> +
>>>>>> + writel(mtd->oobsize, nand->regs + MA35_NFI_REG_NANDRACTL);
>>>>>> +
>>>>>> + /* setup and start DMA using dma_addr */
>>>>>> + dma_addr = dma_map_single(nand->dev, (void *)addr, len, DMA_FROM_DEVICE);
>>>>>> + ret = dma_mapping_error(nand->dev, dma_addr);
>>>>>> + if (ret) {
>>>>>> + dev_err(nand->dev, "dma mapping error\n");
>>>>>> + return -EINVAL;
>>>>>> + }
>>>>>> +
>>>>>> + writel((unsigned long)dma_addr, nand->regs + MA35_NFI_REG_DMASA);
>>>>> Please enforce a dma mask of 32 (even though it might be the fault).
>>>> I will change it to dma_addr & 0xffffffff.
>>> That's not what I mean, I believe you should use the dma API to ask for
>>> a mapping within the accessible 32-bit address range. The
>>> dma_mapping_error() check should return an error if that's not the
>>> case. Then you can safely write the value.
>> Here is my misunderstanding: just fill in the dma_addr directly,
>>
>> no type conversion is needed. I have already tested it.
> FYI, it only works because the default DMA mask for your device is gonna
> be 32 bits. If the reality (what your peripheral DMA can do) was
> different than this, you would have to set a different mask explicitly
> to make sure the dma-mapping step would not provide buffers which are
> out of reach.
Sure, I will keep that in mind. However, due to the memory architecture
of the MA35,
which is designed for a maximum of 4GB, there won’t be any situation
exceeding 32 bits.
Thank you.
> Thanks,
> Miquèl
Best regards,
Hui-Ping Chen
More information about the linux-mtd
mailing list