On Tue, Jan 24, 2012 at 8:17 PM, Felipe Contreras felipe.contreras@gmail.com wrote:
On Tue, Jan 24, 2012 at 5:54 PM, Rob Clark rob.clark@linaro.org wrote:
On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras felipe.contreras@gmail.com wrote:
On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark rob.clark@linaro.org wrote:
On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras felipe.contreras@gmail.com wrote:
On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark rob.clark@linaro.org wrote:
On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras felipe.contreras@gmail.com wrote: > #if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE) > extern void omapdrm_reserve_vram(void); > #else > static inline void omapdrm_reserve_vram(void) { } > #endif > > Like how it's done with DSP stuff.
right, but then you'd miss the omapdrm_reserve_vram() call at startup..
Why?
I guess drm.o is ending up in a module, but the code that calls that (in common.c) is not in a module, so you get an unresolved symbol at link
Right... But that code can be moved as well. Just like with the bridge.
Hmm, looks like for dsp bridge the memory reservation is moved to devices.c. Although I'm not entirely sure how that is better... and there is precedent for both approaches, ie. omapfb works like omapdrm, and tidspbridge works as you suggest.
seems a bit bikeshed'ish to me
I will send a patch to fix omapfb, perhaps after that it will be a bit more clear how it should be done :) (if it gets accepted)
ok, but the thing I don't like is it splits up the drm device setup from the omapdrm_reserve_vram() part (and similarly for omapfb),
but if this is the consensus of how it should be done, well.. when in Rome, and all that
BR, -R
-- Felipe Contreras _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel