RFD on DMA_BIT_MASK and LPAE

RFD on DMA_BIT_MASK and LPAE

[Alexander Tarasikov]

Hello, linux hackers!

I've tried enabling LPAE (for the purpose of using KVM on A15) and
have found out that many drivers break because of the DMA_BIT_MASK.
I've found some patches and a discussion on the mailing list, but have
not found what the final verdict on the problem was.

What is the proposed solution to fixing the DMA stuff? Currently, I've
hacked the of/platform and all omap drivers to use a 64-bit mask and
that made my board boot, but this will surely break the devices that
are not 64-bit-dma-capable.

Do you think it is a good idea to define a generic initializer macro
like the following (probably not, but my question is whether it is
possible to somehow fix the situation so that we can boot with and
without LPAE without falling into tons of idfeffery)?

+#ifdef CONFIG_ARCH_PHYS_ADDR_T_64BIT
+#define DMA_BIT_MASK_FULL DMA_BIT_MASK(64)
+#else
+#define DMA_BIT_MASK_FULL DMA_BIT_MASK(32)
+#endif

P.S. I am extremely sorry for sending the email separately to rmk and
mailing list, my web client accidentially enabled HTML in mail and it
was not delivered from the first attempt.

-- 
Regards, Alexander

RFD on DMA_BIT_MASK and LPAE

[Russell King - ARM Linux]

On Tue, Sep 17, 2013 at 02:52:28AM +0400, Alexander Tarasikov wrote:
> Hello, linux hackers!
> 
> I've tried enabling LPAE (for the purpose of using KVM on A15) and have
> found out that many drivers break because of the DMA_BIT_MASK. I've found
> some patches and a discussion on the mailing list, but have not found what
> the final verdict on the problem was.

The problem is that Linux insists that system memory will start at physical
address zero.

That is not true on a lot of ARM platforms, especially with LPAE.  This
assumption needs to be fixed.

I have a large patch series which I posted a few months back - now that
-rc1 is out, I will be re-posting it and if it gets mostly ignored again,
I'll drop it into linux-next for more exposure and as a candidiate for
merging at the next window.

Even with LPAE, even with memory all above the 4GB mark, if you have
32-bit DMA controllers a 32-bit DMA mask should _still_ work.

RFD on DMA_BIT_MASK and LPAE

[Alexander Tarasikov]

On Tue, Sep 17, 2013 at 3:04 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Sep 17, 2013 at 02:52:28AM +0400, Alexander Tarasikov wrote:
>> Hello, linux hackers!
>>
>> I've tried enabling LPAE (for the purpose of using KVM on A15) and have
>> found out that many drivers break because of the DMA_BIT_MASK. I've found
>> some patches and a discussion on the mailing list, but have not found what
>> the final verdict on the problem was.
>
> The problem is that Linux insists that system memory will start at physical
> address zero.
>
> That is not true on a lot of ARM platforms, especially with LPAE.  This
> assumption needs to be fixed.
>
> I have a large patch series which I posted a few months back - now that
> -rc1 is out, I will be re-posting it and if it gets mostly ignored again,
> I'll drop it into linux-next for more exposure and as a candidiate for
> merging at the next window.

Hello, Russell!
Thanks for the explanation.

>
> Even with LPAE, even with memory all above the 4GB mark, if you have
> 32-bit DMA controllers a 32-bit DMA mask should _still_ work.

Does that mean that the of/platform file (which parses the DTS) will
need no patching
or that it should set the DMA mask based on what the ARM core supports?

Either way, I hope in some time the vanilla linux will be usable
across all those new A15
boards, and you guys have done a fantastic job with migrating to DTS
and moving the
code out of arch/arm. In the meantime, I am happy to use the
vendor-supplied tree
with custom patches because my proof-of-concept KVM port on OMAP5 is working
fine.

-- 
Regards, Alexander