[PATCH 1/2] omap2+: add drm device

Felipe Contreras felipe.contreras at gmail.com
Tue Jan 24 18:17:54 PST 2012


On Tue, Jan 24, 2012 at 5:54 PM, Rob Clark <rob.clark at linaro.org> wrote:
> On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras
> <felipe.contreras at gmail.com> wrote:
>> On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark <rob.clark at linaro.org> wrote:
>>> On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
>>> <felipe.contreras at gmail.com> wrote:
>>>> On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark <rob.clark at linaro.org> wrote:
>>>>> On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
>>>>> <felipe.contreras at 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)

-- 
Felipe Contreras


More information about the dri-devel mailing list