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@xxxxxx> wrote: > > Hi, > > > > On Tue, 2012-03-13 at 15:34 -0500, Rob Clark wrote: > >> From: Andy Gross <andy.gross@xxxxxx> > >> > >> 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. > > 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. 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). Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
