On Wed, Mar 14, 2012 at 8:07 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
On Wed, 2012-03-14 at 07:55 -0500, Rob Clark wrote:
On Wed, Mar 14, 2012 at 7:38 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Hi,
On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote:
From: Andy Gross andy.gross@ti.com
Register OMAP DRM/KMS platform device, and reserve a CMA region for the device to use for buffer allocation. DMM is split into a separate device using hwmod.
What's the diff with this and the previous one?
Moving drm.c to mach-omap2 (header could not move because omap_reserve() is in plat-omap.. but this seems to be the same as what is done for dspbridge).
I see you still have the platform data there. You didn't comment on that. Where is it used after the board files are gone when we use DT?
I was kind-of thinking that there would be some DT<->data-structure glue somewhere.. not sure if this goes in mach-omap2 or in the driver itself, but presumably it is needed somewhere.
It is only really special cases where some board specific device-tree data is needed, so it seems like this is ok to handle later.
Afaik DT data should only contain information about the hardware. This is SW configuration, so I think DT people won't accept things like that.
hmm, then where *does* it go.. it is a bit too much for bootargs..
And how about the size of the contiguous memory area, it was left a bit unclear to me why it cannot be dynamic.
I don't think there is anything preventing adding a bootarg, but I think it is not essential so ok to add later
Well, maybe not essential to you =). But you are reserving 32MB memory, which is quite a big amount. Even if the reserved memory can be used for some other purposes, it's still a big chunk of "special" memory being reserved even if the user doesn't use or have a display at all.
If you didn't have display, and were tight on memory, wouldn't you just disable the display device in your kernel config?
Well, it's not an issue for me either, but I just feel that doing things like that without allowing the user to avoid it is a bit bad thing.
Btw, do you know why the dma_declare_contiguous() takes a dev pointer as an argument, if the memory is not private to that device? (at least I understood from you that the memory can be used for other purposes).
contiguous use of the memory is private to the device. There is also a global CMA pool, from which all dma_alloc_xyz() which is not associated w/ a per-device pool comes from.. but the advantage of a per-device-pool is it puts an upper limit on how much dma memory that device can allocate so that it cannot starve other devices.
BR, -R
Tomi
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel