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