On Tue, Jan 24, 2012 at 8:17 PM, Felipe Contreras
<felipe.contreras@xxxxxxxxx> wrote:
> 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)
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@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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
