On Tue, Jan 24, 2012 at 8:32 PM, Rob Clark <rob.clark@xxxxxxxxxx> wrote:
> 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
oh, sorry, I am mistaken, the oampdrm_reserve_vram() cannot be split
into devices.c, since you need the 'struct device *' to register the
CMA region. I'd ask that you don't patch omapfb to "fix" it because
this would have to be undone once CMA is merged (since we should then
remove omap_vram and other carveout mechanism and use CMA instead)
BR,
-R
> BR,
> -R
>
>> --
>> Felipe Contreras
>> _______________________________________________
>> 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
