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

[Gross, Andy]

On Mon, Jan 23, 2012 at 11:24 AM, Cousson, Benoit  wrote:

>
>> +   if (oh) {
>> +   dmm_platdata.base = omap_hwmod_get_mpu_rt_va(oh);
>> +   dmm_platdata.irq = oh->mpu_irqs[0].irq;
>>
>
> These are internal hwmod attributes that should not be retrieved here.
> They are included in the device resources and this is up to the driver to
> get them using the platform_get_resource.


Yeah this can be removed and I can switch to platform_get_resource.



>  +
>> +   if (dmm_platdata.base)
>> +   omapdrm_platdata.dmm_pdata =_platdata;
>>
>
> pdata is supposed to be used for storing board level information, and we
> are in the process of removing all of them for device tree adaptation. So
> you should not use that at all in this case if this is not strictly needed.


Noted.  I'll just remove it.  I was planning ahead when I added this, but I
can cross that bridge when I get there.


>
>  +   }
>> +
>> +   return platform_device_register(&**omap_drm_device);
>>
>
> This is not the proper way to init a device nowadays.
>
> If you want to take advantage of the pm functionality, you should create
> an omap_device.
> Please have a look at the other OMAP devices creation code (GPIO, UART...).


It was my understanding that you needed a hwmod entry that corresponded to
the device if you wanted to use omap_device_build().  In the case of
omap_drm, we don't have a hwmod entry.  We do have an entry for DMM.


Regards,

Andy Gross
-- next part --
An HTML attachment was scrubbed...
URL: 

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

[Gross, Andy]

On Mon, Jan 23, 2012 at 11:24 AM, Cousson, Benoit b-cous...@ti.com wrote:


 +   if (oh) {
 +   dmm_platdata.base = omap_hwmod_get_mpu_rt_va(oh);
 +   dmm_platdata.irq = oh-mpu_irqs[0].irq;


 These are internal hwmod attributes that should not be retrieved here.
 They are included in the device resources and this is up to the driver to
 get them using the platform_get_resource.


Yeah this can be removed and I can switch to platform_get_resource.



  +
 +   if (dmm_platdata.base)
 +   omapdrm_platdata.dmm_pdata =dmm_platdata;


 pdata is supposed to be used for storing board level information, and we
 are in the process of removing all of them for device tree adaptation. So
 you should not use that at all in this case if this is not strictly needed.


Noted.  I'll just remove it.  I was planning ahead when I added this, but I
can cross that bridge when I get there.



  +   }
 +
 +   return platform_device_register(**omap_drm_device);


 This is not the proper way to init a device nowadays.

 If you want to take advantage of the pm functionality, you should create
 an omap_device.
 Please have a look at the other OMAP devices creation code (GPIO, UART...).


It was my understanding that you needed a hwmod entry that corresponded to
the device if you wanted to use omap_device_build().  In the case of
omap_drm, we don't have a hwmod entry.  We do have an entry for DMM.


Regards,

Andy Gross
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Rob Clark]

On Thu, Feb 9, 2012 at 11:28 AM, Greg KH  wrote:
> On Fri, Jan 13, 2012 at 02:41:59PM -0600, Rob Clark wrote:
>> From: Rob Clark 
>>
>> Register OMAP DRM/KMS platform device, and reserve a CMA region for
>> the device to use for buffer allocation.
>>
>> v1: initial patch
>> v2: move platform data structs into plat-omap to avoid having to
>> ? ? #include headers from drivers/staging and cleanups
>>
>> Signed-off-by: Rob Clark 
>> ---
>> Note: after applying this patch there will be duplicate copies of the
>> platform data structs (until the 2nd patch is applied). ?But I tested
>> to ensure this does not cause build breaks. ?So the 2nd patch which
>> should go thru staging tree is safe to be held until this patch hits
>> Linus's master branch.
>>
>> ?arch/arm/plat-omap/Makefile ? ? ? ? ? | ? ?2 +-
>> ?arch/arm/plat-omap/common.c ? ? ? ? ? | ? ?3 +-
>> ?arch/arm/plat-omap/drm.c ? ? ? ? ? ? ?| ? 83 
>> +
>> ?arch/arm/plat-omap/include/plat/drm.h | ? 70 +++
>> ?4 files changed, 156 insertions(+), 2 deletions(-)
>> ?create mode 100644 arch/arm/plat-omap/drm.c
>> ?create mode 100644 arch/arm/plat-omap/include/plat/drm.h
>
> Did this ever get applied?

Not yet, there was requested some omap hwmod related changes for how
the driver gets SoC version specific information (irq, base addr), so
I'll resubmit again the device file registration (and the 2nd patch)
but that might have to be for 3.4

You can drop the existing 2/2 patch

BR,
-R


> As I can't apply 2/2 without it, please feel
> free to add:
> ? ? ? ?Acked-by: Greg Kroah-Hartman 
>
> to 2/2 when some dri/omap developer commits this one.
>
> thanks,
>
> greg k-h

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

[Greg KH]

On Fri, Jan 13, 2012 at 02:41:59PM -0600, Rob Clark wrote:
> From: Rob Clark 
> 
> Register OMAP DRM/KMS platform device, and reserve a CMA region for
> the device to use for buffer allocation.
> 
> v1: initial patch
> v2: move platform data structs into plat-omap to avoid having to
> #include headers from drivers/staging and cleanups
> 
> Signed-off-by: Rob Clark 
> ---
> Note: after applying this patch there will be duplicate copies of the
> platform data structs (until the 2nd patch is applied).  But I tested
> to ensure this does not cause build breaks.  So the 2nd patch which
> should go thru staging tree is safe to be held until this patch hits
> Linus's master branch.
> 
>  arch/arm/plat-omap/Makefile   |2 +-
>  arch/arm/plat-omap/common.c   |3 +-
>  arch/arm/plat-omap/drm.c  |   83 
> +
>  arch/arm/plat-omap/include/plat/drm.h |   70 +++
>  4 files changed, 156 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/plat-omap/drm.c
>  create mode 100644 arch/arm/plat-omap/include/plat/drm.h

Did this ever get applied?  As I can't apply 2/2 without it, please feel
free to add:
Acked-by: Greg Kroah-Hartman 

to 2/2 when some dri/omap developer commits this one.

thanks,

greg k-h

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

[Greg KH]

On Fri, Jan 13, 2012 at 02:41:59PM -0600, Rob Clark wrote:
 From: Rob Clark r...@ti.com
 
 Register OMAP DRM/KMS platform device, and reserve a CMA region for
 the device to use for buffer allocation.
 
 v1: initial patch
 v2: move platform data structs into plat-omap to avoid having to
 #include headers from drivers/staging and cleanups
 
 Signed-off-by: Rob Clark r...@ti.com
 ---
 Note: after applying this patch there will be duplicate copies of the
 platform data structs (until the 2nd patch is applied).  But I tested
 to ensure this does not cause build breaks.  So the 2nd patch which
 should go thru staging tree is safe to be held until this patch hits
 Linus's master branch.
 
  arch/arm/plat-omap/Makefile   |2 +-
  arch/arm/plat-omap/common.c   |3 +-
  arch/arm/plat-omap/drm.c  |   83 
 +
  arch/arm/plat-omap/include/plat/drm.h |   70 +++
  4 files changed, 156 insertions(+), 2 deletions(-)
  create mode 100644 arch/arm/plat-omap/drm.c
  create mode 100644 arch/arm/plat-omap/include/plat/drm.h

Did this ever get applied?  As I can't apply 2/2 without it, please feel
free to add:
Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org

to 2/2 when some dri/omap developer commits this one.

thanks,

greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Rob Clark]

On Thu, Feb 9, 2012 at 11:28 AM, Greg KH gre...@linuxfoundation.org wrote:
 On Fri, Jan 13, 2012 at 02:41:59PM -0600, Rob Clark wrote:
 From: Rob Clark r...@ti.com

 Register OMAP DRM/KMS platform device, and reserve a CMA region for
 the device to use for buffer allocation.

 v1: initial patch
 v2: move platform data structs into plat-omap to avoid having to
     #include headers from drivers/staging and cleanups

 Signed-off-by: Rob Clark r...@ti.com
 ---
 Note: after applying this patch there will be duplicate copies of the
 platform data structs (until the 2nd patch is applied).  But I tested
 to ensure this does not cause build breaks.  So the 2nd patch which
 should go thru staging tree is safe to be held until this patch hits
 Linus's master branch.

  arch/arm/plat-omap/Makefile           |    2 +-
  arch/arm/plat-omap/common.c           |    3 +-
  arch/arm/plat-omap/drm.c              |   83 
 +
  arch/arm/plat-omap/include/plat/drm.h |   70 +++
  4 files changed, 156 insertions(+), 2 deletions(-)
  create mode 100644 arch/arm/plat-omap/drm.c
  create mode 100644 arch/arm/plat-omap/include/plat/drm.h

 Did this ever get applied?

Not yet, there was requested some omap hwmod related changes for how
the driver gets SoC version specific information (irq, base addr), so
I'll resubmit again the device file registration (and the 2nd patch)
but that might have to be for 3.4

You can drop the existing 2/2 patch

BR,
-R


 As I can't apply 2/2 without it, please feel
 free to add:
        Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org

 to 2/2 when some dri/omap developer commits this one.

 thanks,

 greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Rob Clark]

On Tue, Jan 24, 2012 at 8:32 PM, Rob Clark  wrote:
> On Tue, Jan 24, 2012 at 8:17 PM, Felipe Contreras
>  wrote:
>> On Tue, Jan 24, 2012 at 5:54 PM, Rob Clark  wrote:
>>> On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras
>>>  wrote:
 On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark  
 wrote:
> On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
>  wrote:
>> On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark  
>> wrote:
>>> On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
>>>  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 at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Felipe Contreras]

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

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

[Rob Clark]

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

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@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Rob Clark]

On Tue, Jan 24, 2012 at 8:17 PM, Felipe Contreras
 wrote:
> On Tue, Jan 24, 2012 at 5:54 PM, Rob Clark  wrote:
>> On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras
>>  wrote:
>>> On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark  wrote:
 On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
  wrote:
> On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark  
> wrote:
>> On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
>>  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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Felipe Contreras]

On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark  wrote:
> On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
>  wrote:
>> On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark  wrote:
>>> On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
>>>  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.

-- 
Felipe Contreras

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

[Rob Clark]

On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras
 wrote:
> On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark  wrote:
>> On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
>>  wrote:
>>> On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark  wrote:
 On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
  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

BR,
-R

> --
> Felipe Contreras

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

[Felipe Contreras]

On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
 felipe.contre...@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.

-- 
Felipe Contreras
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Rob Clark]

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

BR,
-R

 --
 Felipe Contreras
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Felipe Contreras]

On Tue, Jan 24, 2012 at 5:54 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
 felipe.contre...@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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Rob Clark]

On Tue, Jan 24, 2012 at 8:17 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Tue, Jan 24, 2012 at 5:54 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
 felipe.contre...@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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Cousson, Benoit]

Hi Rob,

On 1/13/2012 9:41 PM, Rob Clark wrote:
> From: Rob Clark

[...]

> +static int __init omap_init_gpu(void)

Why is the function to init drm device is named gpu?

> +{
> + struct omap_hwmod *oh = NULL;
> +
> + /* lookup and populate the DMM information, if present - OMAP4+ */
> + oh = omap_hwmod_lookup("dmm");
> +
> + if (oh) {
> + dmm_platdata.base = omap_hwmod_get_mpu_rt_va(oh);
> + dmm_platdata.irq = oh->mpu_irqs[0].irq;

These are internal hwmod attributes that should not be retrieved here. 
They are included in the device resources and this is up to the driver 
to get them using the platform_get_resource.

> +
> + if (dmm_platdata.base)
> + omapdrm_platdata.dmm_pdata =_platdata;

pdata is supposed to be used for storing board level information, and we 
are in the process of removing all of them for device tree adaptation. 
So you should not use that at all in this case if this is not strictly 
needed.

> + }
> +
> + return platform_device_register(_drm_device);

This is not the proper way to init a device nowadays.

If you want to take advantage of the pm functionality, you should create 
an omap_device.
Please have a look at the other OMAP devices creation code (GPIO, UART...).

> +}
> +
> +arch_initcall(omap_init_gpu);
> +
> +void omapdrm_reserve_vram(void)
> +{
> +#ifdef CONFIG_CMA
> + /*
> +  * Create private 32MiB contiguous memory area for omapdrm.0 device
> +  * TODO revisit size.. if uc/wc buffers are allocated from CMA pages
> +  * then the amount of memory we need goes up..
> +  */
> + dma_declare_contiguous(_drm_device.dev, 32 * SZ_1M, 0, 0);
> +#else
> +#  warning "CMA is not enabled, there may be limitations about scanout 
> buffer allocations on OMAP3 and earlier"
> +#endif
> +}
> +
> +#endif
> diff --git a/arch/arm/plat-omap/include/plat/drm.h 
> b/arch/arm/plat-omap/include/plat/drm.h
> new file mode 100644
> index 000..e29be29
> --- /dev/null
> +++ b/arch/arm/plat-omap/include/plat/drm.h

Ideally, platform data should not exist anymore in a device tree world, 
but meanwhile there is a directory to store them:
include/linux/platform_data

> @@ -0,0 +1,70 @@
> +/*
> + * DRM/KMS device registration for TI OMAP platforms
> + *
> + * Copyright (C) 2012 Texas Instruments
> + * Author: Rob Clark
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see.
> + */
> +
> +#ifndef __PLAT_OMAP_DRM_H__
> +#define __PLAT_OMAP_DRM_H__
> +
> +/*
> + * Optional platform data to configure the default configuration of which
> + * pipes/overlays/CRTCs are used.. if this is not provided, then instead the
> + * first CONFIG_DRM_OMAP_NUM_CRTCS are used, and they are each connected to
> + * one manager, with priority given to managers that are connected to
> + * detected devices.  Remaining overlays are used as video planes.  This
> + * should be a good default behavior for most cases, but yet there still
> + * might be times when you wish to do something different.
> + */
> +struct omap_kms_platform_data {
> + /* overlays to use as CRTCs: */
> + int ovl_cnt;
> + const int *ovl_ids;
> +
> + /* overlays to use as video planes: */
> + int pln_cnt;
> + const int *pln_ids;
> +
> + int mgr_cnt;
> + const int *mgr_ids;
> +
> + int dev_cnt;
> + const char **dev_names;
> +};
> +
> +struct omap_drm_platform_data {
> + struct omap_kms_platform_data *kms_pdata;
> + struct omap_dmm_platform_data *dmm_pdata;
> +};

Since the dmm_platform_data should not exist in theory, it should not be 
used by this structure either.

Where is the driver that will use these devices?

Regards,
Benoit

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

[Rob Clark]

On Mon, Jan 23, 2012 at 11:24 AM, Cousson, Benoit  wrote:
> Hi Rob,
>
> On 1/13/2012 9:41 PM, Rob Clark wrote:
>>
>> From: Rob Clark
>
>
> [...]
>
>> +static int __init omap_init_gpu(void)
>
>
> Why is the function to init drm device is named gpu?
>

drm drivers are typically gpu drivers (although due to lack of opensrc
pvr userspace most of the actual gpu bits are stripped out)

The function can be renamed.. the name is really not too important
since it is only used within this file

>> +{
>> + ? ? ? struct omap_hwmod *oh = NULL;
>> +
>> + ? ? ? /* lookup and populate the DMM information, if present - OMAP4+ */
>> + ? ? ? oh = omap_hwmod_lookup("dmm");
>> +
>> + ? ? ? if (oh) {
>> + ? ? ? ? ? ? ? dmm_platdata.base = omap_hwmod_get_mpu_rt_va(oh);
>> + ? ? ? ? ? ? ? dmm_platdata.irq = oh->mpu_irqs[0].irq;
>
>
> These are internal hwmod attributes that should not be retrieved here. They
> are included in the device resources and this is up to the driver to get
> them using the platform_get_resource.
>


hmm, I don't claim to be a hwmod expert, but how is the platform
device mapped back to the needed resources then?

Andy looked more at that part so I'll let him comment.


>> +
>> + ? ? ? ? ? ? ? if (dmm_platdata.base)
>> + ? ? ? ? ? ? ? ? ? ? ? omapdrm_platdata.dmm_pdata =_platdata;
>
>
> pdata is supposed to be used for storing board level information, and we are
> in the process of removing all of them for device tree adaptation. So you
> should not use that at all in this case if this is not strictly needed.
>
>
>> + ? ? ? }
>> +
>> + ? ? ? return platform_device_register(_drm_device);
>
>
> This is not the proper way to init a device nowadays.
>
> If you want to take advantage of the pm functionality, you should create an
> omap_device.
> Please have a look at the other OMAP devices creation code (GPIO, UART...).
>


Because omapdss is a separate layer below omapdrm, there really isn't
any PM in omapdrm (yet).  We do need to add support to restore the LUT
on resume although there are some complications when it comes to
correct sequence, ie. ensure LUT is reprogrammed before DSS overlays
are enabled, or IVAHD, etc, is allowed to start accessing buffer.
(But at least it should be possible to do correctly now, compared to
old state where there was a separate standalone tiler driver.)



>> +}
>> +
>> +arch_initcall(omap_init_gpu);
>> +
>> +void omapdrm_reserve_vram(void)
>> +{
>> +#ifdef CONFIG_CMA
>> + ? ? ? /*
>> + ? ? ? ?* Create private 32MiB contiguous memory area for omapdrm.0
>> device
>> + ? ? ? ?* TODO revisit size.. if uc/wc buffers are allocated from CMA
>> pages
>> + ? ? ? ?* then the amount of memory we need goes up..
>> + ? ? ? ?*/
>> + ? ? ? dma_declare_contiguous(_drm_device.dev, 32 * SZ_1M, 0, 0);
>> +#else
>> +# ?warning "CMA is not enabled, there may be limitations about scanout
>> buffer allocations on OMAP3 and earlier"
>> +#endif
>> +}
>> +
>> +#endif
>> diff --git a/arch/arm/plat-omap/include/plat/drm.h
>> b/arch/arm/plat-omap/include/plat/drm.h
>> new file mode 100644
>> index 000..e29be29
>> --- /dev/null
>> +++ b/arch/arm/plat-omap/include/plat/drm.h
>
>
> Ideally, platform data should not exist anymore in a device tree world, but
> meanwhile there is a directory to store them:
> include/linux/platform_data
>
>
>> @@ -0,0 +1,70 @@
>> +/*
>> + * DRM/KMS device registration for TI OMAP platforms
>> + *
>> + * Copyright (C) 2012 Texas Instruments
>> + * Author: Rob Clark
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> it
>> + * under the terms of the GNU General Public License version 2 as
>> published by
>> + * the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but
>> WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE. ?See the GNU General Public License
>> for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> along with
>> + * this program. ?If not, see.
>> + */
>> +
>> +#ifndef __PLAT_OMAP_DRM_H__
>> +#define __PLAT_OMAP_DRM_H__
>> +
>> +/*
>> + * Optional platform data to configure the default configuration of which
>> + * pipes/overlays/CRTCs are used.. if this is not provided, then instead
>> the
>> + * first CONFIG_DRM_OMAP_NUM_CRTCS are used, and they are each connected
>> to
>> + * one manager, with priority given to managers that are connected to
>> + * detected devices. ?Remaining overlays are used as video planes. ?This
>> + * should be a good default behavior for most cases, but yet there still
>> + * might be times when you wish to do something different.
>> + */
>> +struct omap_kms_platform_data {
>> + ? ? ? /* overlays to use as CRTCs: */
>> + ? ? ? int ovl_cnt;
>> + ? ? ? const int *ovl_ids;
>> +
>> + ? ? ? /* overlays to use as video planes: */
>> + ? ? ? int pln_cnt;
>> + ? ? ? const int *pln_ids;
>> +
>> + ? ? ? 

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

[Rob Clark]

On Mon, Jan 23, 2012 at 11:24 AM, Cousson, Benoit b-cous...@ti.com wrote:
 Hi Rob,

 On 1/13/2012 9:41 PM, Rob Clark wrote:

 From: Rob Clarkr...@ti.com


 [...]

 +static int __init omap_init_gpu(void)


 Why is the function to init drm device is named gpu?


drm drivers are typically gpu drivers (although due to lack of opensrc
pvr userspace most of the actual gpu bits are stripped out)

The function can be renamed.. the name is really not too important
since it is only used within this file

 +{
 +       struct omap_hwmod *oh = NULL;
 +
 +       /* lookup and populate the DMM information, if present - OMAP4+ */
 +       oh = omap_hwmod_lookup(dmm);
 +
 +       if (oh) {
 +               dmm_platdata.base = omap_hwmod_get_mpu_rt_va(oh);
 +               dmm_platdata.irq = oh-mpu_irqs[0].irq;


 These are internal hwmod attributes that should not be retrieved here. They
 are included in the device resources and this is up to the driver to get
 them using the platform_get_resource.



hmm, I don't claim to be a hwmod expert, but how is the platform
device mapped back to the needed resources then?

Andy looked more at that part so I'll let him comment.


 +
 +               if (dmm_platdata.base)
 +                       omapdrm_platdata.dmm_pdata =dmm_platdata;


 pdata is supposed to be used for storing board level information, and we are
 in the process of removing all of them for device tree adaptation. So you
 should not use that at all in this case if this is not strictly needed.


 +       }
 +
 +       return platform_device_register(omap_drm_device);


 This is not the proper way to init a device nowadays.

 If you want to take advantage of the pm functionality, you should create an
 omap_device.
 Please have a look at the other OMAP devices creation code (GPIO, UART...).



Because omapdss is a separate layer below omapdrm, there really isn't
any PM in omapdrm (yet).  We do need to add support to restore the LUT
on resume although there are some complications when it comes to
correct sequence, ie. ensure LUT is reprogrammed before DSS overlays
are enabled, or IVAHD, etc, is allowed to start accessing buffer.
(But at least it should be possible to do correctly now, compared to
old state where there was a separate standalone tiler driver.)



 +}
 +
 +arch_initcall(omap_init_gpu);
 +
 +void omapdrm_reserve_vram(void)
 +{
 +#ifdef CONFIG_CMA
 +       /*
 +        * Create private 32MiB contiguous memory area for omapdrm.0
 device
 +        * TODO revisit size.. if uc/wc buffers are allocated from CMA
 pages
 +        * then the amount of memory we need goes up..
 +        */
 +       dma_declare_contiguous(omap_drm_device.dev, 32 * SZ_1M, 0, 0);
 +#else
 +#  warning CMA is not enabled, there may be limitations about scanout
 buffer allocations on OMAP3 and earlier
 +#endif
 +}
 +
 +#endif
 diff --git a/arch/arm/plat-omap/include/plat/drm.h
 b/arch/arm/plat-omap/include/plat/drm.h
 new file mode 100644
 index 000..e29be29
 --- /dev/null
 +++ b/arch/arm/plat-omap/include/plat/drm.h


 Ideally, platform data should not exist anymore in a device tree world, but
 meanwhile there is a directory to store them:
 include/linux/platform_data


 @@ -0,0 +1,70 @@
 +/*
 + * DRM/KMS device registration for TI OMAP platforms
 + *
 + * Copyright (C) 2012 Texas Instruments
 + * Author: Rob Clarkrob.cl...@linaro.org
 + *
 + * This program is free software; you can redistribute it and/or modify
 it
 + * under the terms of the GNU General Public License version 2 as
 published by
 + * the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be useful, but
 WITHOUT
 + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 for
 + * more details.
 + *
 + * You should have received a copy of the GNU General Public License
 along with
 + * this program.  If not, seehttp://www.gnu.org/licenses/.
 + */
 +
 +#ifndef __PLAT_OMAP_DRM_H__
 +#define __PLAT_OMAP_DRM_H__
 +
 +/*
 + * Optional platform data to configure the default configuration of which
 + * pipes/overlays/CRTCs are used.. if this is not provided, then instead
 the
 + * first CONFIG_DRM_OMAP_NUM_CRTCS are used, and they are each connected
 to
 + * one manager, with priority given to managers that are connected to
 + * detected devices.  Remaining overlays are used as video planes.  This
 + * should be a good default behavior for most cases, but yet there still
 + * might be times when you wish to do something different.
 + */
 +struct omap_kms_platform_data {
 +       /* overlays to use as CRTCs: */
 +       int ovl_cnt;
 +       const int *ovl_ids;
 +
 +       /* overlays to use as video planes: */
 +       int pln_cnt;
 +       const int *pln_ids;
 +
 +       int mgr_cnt;
 +       const int *mgr_ids;
 +
 +       int dev_cnt;
 +       const char **dev_names;
 +};
 +
 +struct omap_drm_platform_data {
 +       struct 

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

[Cousson, Benoit]

Hi Rob,

On 1/13/2012 9:41 PM, Rob Clark wrote:

From: Rob Clarkr...@ti.com


[...]


+static int __init omap_init_gpu(void)


Why is the function to init drm device is named gpu?


+{
+   struct omap_hwmod *oh = NULL;
+
+   /* lookup and populate the DMM information, if present - OMAP4+ */
+   oh = omap_hwmod_lookup(dmm);
+
+   if (oh) {
+   dmm_platdata.base = omap_hwmod_get_mpu_rt_va(oh);
+   dmm_platdata.irq = oh-mpu_irqs[0].irq;


These are internal hwmod attributes that should not be retrieved here. 
They are included in the device resources and this is up to the driver 
to get them using the platform_get_resource.



+
+   if (dmm_platdata.base)
+   omapdrm_platdata.dmm_pdata =dmm_platdata;


pdata is supposed to be used for storing board level information, and we 
are in the process of removing all of them for device tree adaptation. 
So you should not use that at all in this case if this is not strictly 
needed.



+   }
+
+   return platform_device_register(omap_drm_device);


This is not the proper way to init a device nowadays.

If you want to take advantage of the pm functionality, you should create 
an omap_device.

Please have a look at the other OMAP devices creation code (GPIO, UART...).


+}
+
+arch_initcall(omap_init_gpu);
+
+void omapdrm_reserve_vram(void)
+{
+#ifdef CONFIG_CMA
+   /*
+* Create private 32MiB contiguous memory area for omapdrm.0 device
+* TODO revisit size.. if uc/wc buffers are allocated from CMA pages
+* then the amount of memory we need goes up..
+*/
+   dma_declare_contiguous(omap_drm_device.dev, 32 * SZ_1M, 0, 0);
+#else
+#  warning CMA is not enabled, there may be limitations about scanout buffer 
allocations on OMAP3 and earlier
+#endif
+}
+
+#endif
diff --git a/arch/arm/plat-omap/include/plat/drm.h 
b/arch/arm/plat-omap/include/plat/drm.h
new file mode 100644
index 000..e29be29
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/drm.h


Ideally, platform data should not exist anymore in a device tree world, 
but meanwhile there is a directory to store them:

include/linux/platform_data


@@ -0,0 +1,70 @@
+/*
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clarkrob.cl...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, seehttp://www.gnu.org/licenses/.
+ */
+
+#ifndef __PLAT_OMAP_DRM_H__
+#define __PLAT_OMAP_DRM_H__
+
+/*
+ * Optional platform data to configure the default configuration of which
+ * pipes/overlays/CRTCs are used.. if this is not provided, then instead the
+ * first CONFIG_DRM_OMAP_NUM_CRTCS are used, and they are each connected to
+ * one manager, with priority given to managers that are connected to
+ * detected devices.  Remaining overlays are used as video planes.  This
+ * should be a good default behavior for most cases, but yet there still
+ * might be times when you wish to do something different.
+ */
+struct omap_kms_platform_data {
+   /* overlays to use as CRTCs: */
+   int ovl_cnt;
+   const int *ovl_ids;
+
+   /* overlays to use as video planes: */
+   int pln_cnt;
+   const int *pln_ids;
+
+   int mgr_cnt;
+   const int *mgr_ids;
+
+   int dev_cnt;
+   const char **dev_names;
+};
+
+struct omap_drm_platform_data {
+   struct omap_kms_platform_data *kms_pdata;
+   struct omap_dmm_platform_data *dmm_pdata;
+};


Since the dmm_platform_data should not exist in theory, it should not be 
used by this structure either.


Where is the driver that will use these devices?

Regards,
Benoit
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Felipe Contreras]

On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark  wrote:
> On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
>  wrote:
>> On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark  wrote:
>>> On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
>>>  wrote:
 On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark  
 wrote:
> On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
>  wrote:
>> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark  
>> wrote:
>>> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
>>> index 9a58461..b86e6cb 100644
>>> --- a/arch/arm/plat-omap/Makefile
>>> +++ b/arch/arm/plat-omap/Makefile
>>> @@ -4,7 +4,7 @@
>>>
>>> ?# Common support
>>> ?obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
>>> - ? ? ? ?usb.o fb.o counter_32k.o
>>> + ? ? ? ?usb.o fb.o counter_32k.o drm.o
>>
>> Should be something like this:
>> obj-$(CONFIG_DRM_OMAP) += drm.o
>
> btw, how does that work if CONFIG_DRM_OMAP=m? ?Do you end up w/ a
> plat-omap module?

 Yes, and platform drivers are supposed to be loaded automatically at
 boot-time by udev (or similar).
>>>
>>> oh, but this won't work, because common.c has to call
>>> omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock()
>>> works).. so I think it has to stay the way it is in this patch.
>>
>> #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?

-- 
Felipe Contreras

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

[Felipe Contreras]

On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark  wrote:
> On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
>  wrote:
>> On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark  wrote:
>>> On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
>>>  wrote:
 On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark  
 wrote:
> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
> index 9a58461..b86e6cb 100644
> --- a/arch/arm/plat-omap/Makefile
> +++ b/arch/arm/plat-omap/Makefile
> @@ -4,7 +4,7 @@
>
> ?# Common support
> ?obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
> - ? ? ? ?usb.o fb.o counter_32k.o
> + ? ? ? ?usb.o fb.o counter_32k.o drm.o

 Should be something like this:
 obj-$(CONFIG_DRM_OMAP) += drm.o
>>>
>>> btw, how does that work if CONFIG_DRM_OMAP=m? ?Do you end up w/ a
>>> plat-omap module?
>>
>> Yes, and platform drivers are supposed to be loaded automatically at
>> boot-time by udev (or similar).
>
> oh, but this won't work, because common.c has to call
> omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock()
> works).. so I think it has to stay the way it is in this patch.

#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.

-- 
Felipe Contreras

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

[Felipe Contreras]

On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark  wrote:
> On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
>  wrote:
>> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark  wrote:
>>> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
>>> index 9a58461..b86e6cb 100644
>>> --- a/arch/arm/plat-omap/Makefile
>>> +++ b/arch/arm/plat-omap/Makefile
>>> @@ -4,7 +4,7 @@
>>>
>>> ?# Common support
>>> ?obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
>>> - ? ? ? ?usb.o fb.o counter_32k.o
>>> + ? ? ? ?usb.o fb.o counter_32k.o drm.o
>>
>> Should be something like this:
>> obj-$(CONFIG_DRM_OMAP) += drm.o
>
> btw, how does that work if CONFIG_DRM_OMAP=m? ?Do you end up w/ a
> plat-omap module?

Yes, and platform drivers are supposed to be loaded automatically at
boot-time by udev (or similar).

-- 
Felipe Contreras

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

[Rob Clark]

On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
 wrote:
> On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark  wrote:
>> On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
>>  wrote:
>>> On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark  wrote:
 On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
  wrote:
> On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark  
> wrote:
>> On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
>>  wrote:
>>> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark  
>>> wrote:
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@

 ?# Common support
 ?obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 - ? ? ? ?usb.o fb.o counter_32k.o
 + ? ? ? ?usb.o fb.o counter_32k.o drm.o
>>>
>>> Should be something like this:
>>> obj-$(CONFIG_DRM_OMAP) += drm.o
>>
>> btw, how does that work if CONFIG_DRM_OMAP=m? ?Do you end up w/ a
>> plat-omap module?
>
> Yes, and platform drivers are supposed to be loaded automatically at
> boot-time by udev (or similar).

 oh, but this won't work, because common.c has to call
 omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock()
 works).. so I think it has to stay the way it is in this patch.
>>>
>>> #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

BR,
-R

> --
> Felipe Contreras
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html

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

[Rob Clark]

On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
 wrote:
> On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark  wrote:
>> On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
>>  wrote:
>>> On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark  wrote:
 On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
  wrote:
> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark  
> wrote:
>> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
>> index 9a58461..b86e6cb 100644
>> --- a/arch/arm/plat-omap/Makefile
>> +++ b/arch/arm/plat-omap/Makefile
>> @@ -4,7 +4,7 @@
>>
>> ?# Common support
>> ?obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
>> - ? ? ? ?usb.o fb.o counter_32k.o
>> + ? ? ? ?usb.o fb.o counter_32k.o drm.o
>
> Should be something like this:
> obj-$(CONFIG_DRM_OMAP) += drm.o

 btw, how does that work if CONFIG_DRM_OMAP=m? ?Do you end up w/ a
 plat-omap module?
>>>
>>> Yes, and platform drivers are supposed to be loaded automatically at
>>> boot-time by udev (or similar).
>>
>> oh, but this won't work, because common.c has to call
>> omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock()
>> works).. so I think it has to stay the way it is in this patch.
>
> #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..

BR,
-R

> --
> Felipe Contreras
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html

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

[Rob Clark]

On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
 wrote:
> On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark  wrote:
>> On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
>>  wrote:
>>> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark  wrote:
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@

 ?# Common support
 ?obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 - ? ? ? ?usb.o fb.o counter_32k.o
 + ? ? ? ?usb.o fb.o counter_32k.o drm.o
>>>
>>> Should be something like this:
>>> obj-$(CONFIG_DRM_OMAP) += drm.o
>>
>> btw, how does that work if CONFIG_DRM_OMAP=m? ?Do you end up w/ a
>> plat-omap module?
>
> Yes, and platform drivers are supposed to be loaded automatically at
> boot-time by udev (or similar).

oh, but this won't work, because common.c has to call
omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock()
works).. so I think it has to stay the way it is in this patch.

I guess this is the reason that omapfb (fb.c is the example I copied)
device is setup in the same way.

BR,
-R

> --
> Felipe Contreras
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Felipe Contreras]

On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark rob.cl...@linaro.org wrote:
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@

  # Common support
  obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 -        usb.o fb.o counter_32k.o
 +        usb.o fb.o counter_32k.o drm.o

 Should be something like this:
 obj-$(CONFIG_DRM_OMAP) += drm.o

 btw, how does that work if CONFIG_DRM_OMAP=m?  Do you end up w/ a
 plat-omap module?

Yes, and platform drivers are supposed to be loaded automatically at
boot-time by udev (or similar).

-- 
Felipe Contreras
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Rob Clark]

On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark rob.cl...@linaro.org wrote:
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@

  # Common support
  obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 -        usb.o fb.o counter_32k.o
 +        usb.o fb.o counter_32k.o drm.o

 Should be something like this:
 obj-$(CONFIG_DRM_OMAP) += drm.o

 btw, how does that work if CONFIG_DRM_OMAP=m?  Do you end up w/ a
 plat-omap module?

 Yes, and platform drivers are supposed to be loaded automatically at
 boot-time by udev (or similar).

oh, but this won't work, because common.c has to call
omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock()
works).. so I think it has to stay the way it is in this patch.

I guess this is the reason that omapfb (fb.c is the example I copied)
device is setup in the same way.

BR,
-R

 --
 Felipe Contreras
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Felipe Contreras]

On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark rob.cl...@linaro.org wrote:
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@

  # Common support
  obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 -        usb.o fb.o counter_32k.o
 +        usb.o fb.o counter_32k.o drm.o

 Should be something like this:
 obj-$(CONFIG_DRM_OMAP) += drm.o

 btw, how does that work if CONFIG_DRM_OMAP=m?  Do you end up w/ a
 plat-omap module?

 Yes, and platform drivers are supposed to be loaded automatically at
 boot-time by udev (or similar).

 oh, but this won't work, because common.c has to call
 omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock()
 works).. so I think it has to stay the way it is in this patch.

#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.

-- 
Felipe Contreras
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Rob Clark]

On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark rob.cl...@linaro.org wrote:
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@

  # Common support
  obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 -        usb.o fb.o counter_32k.o
 +        usb.o fb.o counter_32k.o drm.o

 Should be something like this:
 obj-$(CONFIG_DRM_OMAP) += drm.o

 btw, how does that work if CONFIG_DRM_OMAP=m?  Do you end up w/ a
 plat-omap module?

 Yes, and platform drivers are supposed to be loaded automatically at
 boot-time by udev (or similar).

 oh, but this won't work, because common.c has to call
 omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock()
 works).. so I think it has to stay the way it is in this patch.

 #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..

BR,
-R

 --
 Felipe Contreras
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Felipe Contreras]

On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark rob.cl...@linaro.org wrote:
 On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark rob.cl...@linaro.org wrote:
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@

  # Common support
  obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 -        usb.o fb.o counter_32k.o
 +        usb.o fb.o counter_32k.o drm.o

 Should be something like this:
 obj-$(CONFIG_DRM_OMAP) += drm.o

 btw, how does that work if CONFIG_DRM_OMAP=m?  Do you end up w/ a
 plat-omap module?

 Yes, and platform drivers are supposed to be loaded automatically at
 boot-time by udev (or similar).

 oh, but this won't work, because common.c has to call
 omapdrm_reserve_vram() (similar to how omapfb_reserve_sdram_memblock()
 works).. so I think it has to stay the way it is in this patch.

 #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?

-- 
Felipe Contreras
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Felipe Contreras]

On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark  wrote:
> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
> index 9a58461..b86e6cb 100644
> --- a/arch/arm/plat-omap/Makefile
> +++ b/arch/arm/plat-omap/Makefile
> @@ -4,7 +4,7 @@
>
> ?# Common support
> ?obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
> - ? ? ? ?usb.o fb.o counter_32k.o
> + ? ? ? ?usb.o fb.o counter_32k.o drm.o

Should be something like this:
obj-$(CONFIG_DRM_OMAP) += drm.o

No?

-- 
Felipe Contreras

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

[Rob Clark]

On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
 wrote:
> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark  wrote:
>> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
>> index 9a58461..b86e6cb 100644
>> --- a/arch/arm/plat-omap/Makefile
>> +++ b/arch/arm/plat-omap/Makefile
>> @@ -4,7 +4,7 @@
>>
>> ?# Common support
>> ?obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
>> - ? ? ? ?usb.o fb.o counter_32k.o
>> + ? ? ? ?usb.o fb.o counter_32k.o drm.o
>
> Should be something like this:
> obj-$(CONFIG_DRM_OMAP) += drm.o

btw, how does that work if CONFIG_DRM_OMAP=m?  Do you end up w/ a
plat-omap module?

BR,
-R

> No?
>
> --
> Felipe Contreras
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Rob Clark]

On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
 wrote:
> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark  wrote:
>> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
>> index 9a58461..b86e6cb 100644
>> --- a/arch/arm/plat-omap/Makefile
>> +++ b/arch/arm/plat-omap/Makefile
>> @@ -4,7 +4,7 @@
>>
>> ?# Common support
>> ?obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
>> - ? ? ? ?usb.o fb.o counter_32k.o
>> + ? ? ? ?usb.o fb.o counter_32k.o drm.o
>
> Should be something like this:
> obj-$(CONFIG_DRM_OMAP) += drm.o
>
> No?

I think it would work either way.  Currently drm.c would be empty if
the driver isn't enabled in the kconfig.. if it is preferred to do
that in the Makefile, I could change it.

BR,
-R

> --
> Felipe Contreras
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Rob Clark]

From: Rob Clark 

Register OMAP DRM/KMS platform device, and reserve a CMA region for
the device to use for buffer allocation.

v1: initial patch
v2: move platform data structs into plat-omap to avoid having to
#include headers from drivers/staging and cleanups

Signed-off-by: Rob Clark 
---
Note: after applying this patch there will be duplicate copies of the
platform data structs (until the 2nd patch is applied).  But I tested
to ensure this does not cause build breaks.  So the 2nd patch which
should go thru staging tree is safe to be held until this patch hits
Linus's master branch.

 arch/arm/plat-omap/Makefile   |2 +-
 arch/arm/plat-omap/common.c   |3 +-
 arch/arm/plat-omap/drm.c  |   83 +
 arch/arm/plat-omap/include/plat/drm.h |   70 +++
 4 files changed, 156 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/plat-omap/drm.c
 create mode 100644 arch/arm/plat-omap/include/plat/drm.h

diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 9a58461..b86e6cb 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -4,7 +4,7 @@

 # Common support
 obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
-usb.o fb.o counter_32k.o
+usb.o fb.o counter_32k.o drm.o
 obj-m :=
 obj-n :=
 obj-  :=
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 06383b5..0d87dab 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -21,10 +21,10 @@
 #include 
 #include 
 #include 
+#include 

 #include 

-
 #define NO_LENGTH_CHECK 0x

 struct omap_board_config_kernel *omap_board_config __initdata;
@@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t *len)

 void __init omap_reserve(void)
 {
+   omapdrm_reserve_vram();
omapfb_reserve_sdram_memblock();
omap_vram_reserve_sdram_memblock();
omap_dsp_reserve_sdram_memblock();
diff --git a/arch/arm/plat-omap/drm.c b/arch/arm/plat-omap/drm.c
new file mode 100644
index 000..aa0ba69
--- /dev/null
+++ b/arch/arm/plat-omap/drm.c
@@ -0,0 +1,83 @@
+/*
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#ifdef CONFIG_CMA
+#  include 
+#endif
+
+#include 
+#include 
+
+#include 
+
+#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
+
+static struct omap_drm_platform_data omapdrm_platdata;
+static struct omap_dmm_platform_data dmm_platdata;
+
+static struct platform_device omap_drm_device = {
+   .dev = {
+   .coherent_dma_mask = DMA_BIT_MASK(32),
+   .platform_data = _platdata,
+   },
+   .name = "omapdrm",
+   .id = 0,
+};
+
+static int __init omap_init_gpu(void)
+{
+   struct omap_hwmod *oh = NULL;
+
+   /* lookup and populate the DMM information, if present - OMAP4+ */
+   oh = omap_hwmod_lookup("dmm");
+
+   if (oh) {
+   dmm_platdata.base = omap_hwmod_get_mpu_rt_va(oh);
+   dmm_platdata.irq = oh->mpu_irqs[0].irq;
+
+   if (dmm_platdata.base)
+   omapdrm_platdata.dmm_pdata = _platdata;
+   }
+
+   return platform_device_register(_drm_device);
+}
+
+arch_initcall(omap_init_gpu);
+
+void omapdrm_reserve_vram(void)
+{
+#ifdef CONFIG_CMA
+   /*
+* Create private 32MiB contiguous memory area for omapdrm.0 device
+* TODO revisit size.. if uc/wc buffers are allocated from CMA pages
+* then the amount of memory we need goes up..
+*/
+   dma_declare_contiguous(_drm_device.dev, 32 * SZ_1M, 0, 0);
+#else
+#  warning "CMA is not enabled, there may be limitations about scanout buffer 
allocations on OMAP3 and earlier"
+#endif
+}
+
+#endif
diff --git a/arch/arm/plat-omap/include/plat/drm.h 
b/arch/arm/plat-omap/include/plat/drm.h
new file mode 100644
index 000..e29be29
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/drm.h
@@ -0,0 +1,70 @@
+/*
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General 

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

[Rob Clark]

From: Rob Clark r...@ti.com

Register OMAP DRM/KMS platform device, and reserve a CMA region for
the device to use for buffer allocation.

v1: initial patch
v2: move platform data structs into plat-omap to avoid having to
#include headers from drivers/staging and cleanups

Signed-off-by: Rob Clark r...@ti.com
---
Note: after applying this patch there will be duplicate copies of the
platform data structs (until the 2nd patch is applied).  But I tested
to ensure this does not cause build breaks.  So the 2nd patch which
should go thru staging tree is safe to be held until this patch hits
Linus's master branch.

 arch/arm/plat-omap/Makefile   |2 +-
 arch/arm/plat-omap/common.c   |3 +-
 arch/arm/plat-omap/drm.c  |   83 +
 arch/arm/plat-omap/include/plat/drm.h |   70 +++
 4 files changed, 156 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/plat-omap/drm.c
 create mode 100644 arch/arm/plat-omap/include/plat/drm.h

diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 9a58461..b86e6cb 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -4,7 +4,7 @@
 
 # Common support
 obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
-usb.o fb.o counter_32k.o
+usb.o fb.o counter_32k.o drm.o
 obj-m :=
 obj-n :=
 obj-  :=
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 06383b5..0d87dab 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -21,10 +21,10 @@
 #include plat/board.h
 #include plat/vram.h
 #include plat/dsp.h
+#include plat/drm.h
 
 #include plat/omap-secure.h
 
-
 #define NO_LENGTH_CHECK 0x
 
 struct omap_board_config_kernel *omap_board_config __initdata;
@@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t *len)
 
 void __init omap_reserve(void)
 {
+   omapdrm_reserve_vram();
omapfb_reserve_sdram_memblock();
omap_vram_reserve_sdram_memblock();
omap_dsp_reserve_sdram_memblock();
diff --git a/arch/arm/plat-omap/drm.c b/arch/arm/plat-omap/drm.c
new file mode 100644
index 000..aa0ba69
--- /dev/null
+++ b/arch/arm/plat-omap/drm.c
@@ -0,0 +1,83 @@
+/*
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark rob.cl...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/dma-mapping.h
+#ifdef CONFIG_CMA
+#  include linux/dma-contiguous.h
+#endif
+
+#include plat/omap_device.h
+#include plat/omap_hwmod.h
+
+#include plat/drm.h
+
+#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
+
+static struct omap_drm_platform_data omapdrm_platdata;
+static struct omap_dmm_platform_data dmm_platdata;
+
+static struct platform_device omap_drm_device = {
+   .dev = {
+   .coherent_dma_mask = DMA_BIT_MASK(32),
+   .platform_data = omapdrm_platdata,
+   },
+   .name = omapdrm,
+   .id = 0,
+};
+
+static int __init omap_init_gpu(void)
+{
+   struct omap_hwmod *oh = NULL;
+
+   /* lookup and populate the DMM information, if present - OMAP4+ */
+   oh = omap_hwmod_lookup(dmm);
+
+   if (oh) {
+   dmm_platdata.base = omap_hwmod_get_mpu_rt_va(oh);
+   dmm_platdata.irq = oh-mpu_irqs[0].irq;
+
+   if (dmm_platdata.base)
+   omapdrm_platdata.dmm_pdata = dmm_platdata;
+   }
+
+   return platform_device_register(omap_drm_device);
+}
+
+arch_initcall(omap_init_gpu);
+
+void omapdrm_reserve_vram(void)
+{
+#ifdef CONFIG_CMA
+   /*
+* Create private 32MiB contiguous memory area for omapdrm.0 device
+* TODO revisit size.. if uc/wc buffers are allocated from CMA pages
+* then the amount of memory we need goes up..
+*/
+   dma_declare_contiguous(omap_drm_device.dev, 32 * SZ_1M, 0, 0);
+#else
+#  warning CMA is not enabled, there may be limitations about scanout buffer 
allocations on OMAP3 and earlier
+#endif
+}
+
+#endif
diff --git a/arch/arm/plat-omap/include/plat/drm.h 
b/arch/arm/plat-omap/include/plat/drm.h
new file mode 100644
index 000..e29be29
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/drm.h

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

[Felipe Contreras]

On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark rob.cl...@linaro.org wrote:
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@

  # Common support
  obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 -        usb.o fb.o counter_32k.o
 +        usb.o fb.o counter_32k.o drm.o

Should be something like this:
obj-$(CONFIG_DRM_OMAP) += drm.o

No?

-- 
Felipe Contreras
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Rob Clark]

On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark rob.cl...@linaro.org wrote:
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@

  # Common support
  obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 -        usb.o fb.o counter_32k.o
 +        usb.o fb.o counter_32k.o drm.o

 Should be something like this:
 obj-$(CONFIG_DRM_OMAP) += drm.o

 No?

I think it would work either way.  Currently drm.c would be empty if
the driver isn't enabled in the kconfig.. if it is preferred to do
that in the Makefile, I could change it.

BR,
-R

 --
 Felipe Contreras
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Rob Clark]

On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark rob.cl...@linaro.org wrote:
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 9a58461..b86e6cb 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -4,7 +4,7 @@

  # Common support
  obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
 -        usb.o fb.o counter_32k.o
 +        usb.o fb.o counter_32k.o drm.o

 Should be something like this:
 obj-$(CONFIG_DRM_OMAP) += drm.o

btw, how does that work if CONFIG_DRM_OMAP=m?  Do you end up w/ a
plat-omap module?

BR,
-R

 No?

 --
 Felipe Contreras
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel