On Wed, Mar 14, 2012 at 8:07 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> 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@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. 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@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
