Hello,

On Tuesday, June 14, 2011 3:49 PM Arnd Bergmann wrote:

On Monday 13 June 2011, Marek Szyprowski wrote:

quoted

cm_alloc/free are definitely not meant to be called from device drivers.
They should be only considered as a backend for dma-mapping.

'Raw' contiguous memory block doesn't really make sense for the device
drivers. What the drivers require is a contiguous memory block that is
somehow mapped into respective bus address space, so dma-mapping
framework is the right interface.

alloc_pages(..., GFP_CMA) looks nice but in fact it is really impractical.
The driver will need to map such buffer to dma context anyway, so imho
dma_alloc_attributed() will give the drivers much more flexibility. In
terms of dma-mapping the context argument isn't anything odd.

Ok.

quoted

If possible I would like to make cma something similar to
declare_dma_coherent()&friends, so the board/platform/bus startup code
will just call declare_dma_contiguous() to enable support for cma for
particular devices.

Sounds good, I like that.

 
Thanks. I thought a bit more on this and decided that I want to make this
declare_dma_contiguous() optional for the drivers. It should be used only
for some sophisticated cases like for example our video codec with two
memory interfaces for 2 separate banks. By default the dma-mapping will
use system-wide cma pool.

(snipped)

quoted

quoted

* It requires you to pass the exact location of the area. I can see why
  you want that on certain machines that require DMA areas to be spread
  across multiple memory buses, but IMHO it's not appropriate for a
  generic API.

IMHO we can also use some NULL context to indicate some global, system
wide CMA area and again -> in terms of dma-mapping api having a context
isn't anything uncommon.

Please explain the exact requirements that lead you to defining multiple
contexts. My feeling is that in most cases we don't need them and can
simply live with a single area. Depending on how obscure the cases are
where we do need something beyond that, we can then come up with
special-case solutions for them.

Like it was already stated we need such feature for our multimedia codec
to allocate buffers from different memory banks. I really don't see any
problems with the possibility to have additional cma areas for special
purposes.

quoted

quoted

* It requires you to hardcode the size in a machine specific source

file.

quoted

quoted

  This probably seems to be a natural thing to do when you have worked

a

quoted

quoted

  lot on the ARM architecture, but it's really not. We really want to
  get rid of board files and replace them with generic probing based on
  the device tree, and the size of the area is more policy than a

property

quoted

quoted

  of the hardware that can be accurately described in the device tree

or

quoted

quoted

  a board file.

The problem is the fact that right now, we still have board files and we
have to live with them for a while (with all advantages and

disadvantages).

quoted

I hope that you won't require me to rewrite the whole support for all ARM
platforms to get rid of board files to get CMA merged ;)

Of course not. But we need to know what we want a platform with device
tree support to look like when it's using CMA, so we don't make it
harder to change the platforms over than it already is.

quoted

I see no problem defining CMA areas in device tree, as this is something
really specific to particular board configuration.

The problem with defining CMA areas in the device tree is that it's not
a property of the hardware, but really policy. The device tree file
should not contain anything related to a specific operating system
because you might want to boot something on the board that doesn't
know about CMA, and even when you only care about using Linux, the
implementation might change to the point where hardcoded CMA areas
no longer make sense.

I really doubt that the device tree will carry only system-independent
information. Anyway, the preferred or required memory areas/banks for
buffer allocation is something that is a property of the hardware not
the OS policy.

IMHO we should first aim for a solution that works almost everywhere
without the kernel knowing what board it's running on, and then we
can add quirks for devices that have special requirements. I think
the situation is similar to the vmalloc virtual address space, which
normally has a hardcoded size that works almost everywhere, but there
are certain drivers etc that require much more, or there are situations
where you want to make it smaller in order to avoid highmem.

I'm trying to create something that will fulfill the requirements of my
hardware, that's why I cannot focus on a generic case only.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center