qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 04/13] mxs/imx23: Add DMA driver


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 04/13] mxs/imx23: Add DMA driver
Date: Fri, 10 Jan 2014 10:55:02 +0000

On 10 January 2014 00:52, Peter Crosthwaite
<address@hidden> wrote:
> On Tue, Jan 7, 2014 at 1:35 AM, Peter Maydell <address@hidden> wrote:

>> I'd rather have the #defines before the struct than
>> interleaved, personally.
>>
>
> TBH, this is the same as my own preferred personal coding style (and I
> refactor on upstreaming due to it's contention). I'd like to push for
> it's general acceptance. #defining at the point of relevance is a well
> adopted concept and makes code much more readable.

I find it kind of weird because it is making use of
the fact that the preprocessor really is a separate
textual step, when it doesn't actually need to. If
we were using enum or 'const int' here you wouldn't
be able to interleave like this and I don't think
you'd be complaining that the language wasn't flexible
enough.

That said, this is really a very minor point as far as
I'm concerned so if people think it's reasonable to do
I'm happy to let it pass.

>> ...for instance this is probably best done via
>> stl_le_phys() to write each word to the guest memory.
>>
>
> Last I knew, dma_memory_read|write is the correct way to do DMA from
> device land. cpu_physical_memory and stl_ are more CPU concepts.
> dma_memory_read|write has the added advantage of accepting and
> address_space which allows for DMA in machines with non-flat
> bus/memory layouts.

You're probably right, yes. I said I wasn't particularly
up on our current practices for DMA :-)

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]