[PATCH] omap2+: add drm device

[Gross, Andy]

Tony,

Please queue this patch at your earliest convenience.

We had some discussion on the splitting out of the DMM/Tiler driver
from the omapdrm driver.  There might be some interest in leveraging
the Tiler for omapfb.  However, we agreed this can be deferred until
some other device (omapfb or otherwise) needs to use the Tiler.

Regards,

Andy Gross


On Mon, Jun 11, 2012 at 10:51 AM, Rob Clark  wrote:
>
> On Wed, May 23, 2012 at 3:08 PM, Andy Gross  wrote:
> > Register OMAP DRM/KMS platform device. ?DMM is split into a
> > separate device using hwmod.
> >
> > Signed-off-by: Andy Gross 
>
> Signed-off-by: Rob Clark 
>
> > ---
> > ?arch/arm/mach-omap2/Makefile ? ? ? ? ? | ? ?4 ++
> > ?arch/arm/mach-omap2/drm.c ? ? ? ? ? ? ?| ? 61 
> > 
> > ?drivers/staging/omapdrm/omap_drv.h ? ? | ? ?2 +-
> > ?drivers/staging/omapdrm/omap_priv.h ? ?| ? 55 
> > ?include/linux/platform_data/omap_drm.h | ? 52 +++
> > ?5 files changed, 118 insertions(+), 56 deletions(-)
> > ?create mode 100644 arch/arm/mach-omap2/drm.c
> > ?delete mode 100644 drivers/staging/omapdrm/omap_priv.h
> > ?create mode 100644 include/linux/platform_data/omap_drm.h
> >
> > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> > index 49f92bc..c301ab7 100644
> > --- a/arch/arm/mach-omap2/Makefile
> > +++ b/arch/arm/mach-omap2/Makefile
> > @@ -187,6 +187,10 @@ ifneq ($(CONFIG_TIDSPBRIDGE),)
> > ?obj-y ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+= dsp.o
> > ?endif
> >
> > +ifneq ($(CONFIG_DRM_OMAP),)
> > +obj-y ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+= drm.o
> > +endif
> > +
> > ?# Specific board support
> > ?obj-$(CONFIG_MACH_OMAP_GENERIC) ? ? ? ? ? ? ? ?+= board-generic.o
> > ?obj-$(CONFIG_MACH_OMAP_H4) ? ? ? ? ? ? += board-h4.o
> > diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
> > new file mode 100644
> > index 000..72e0f01b
> > --- /dev/null
> > +++ b/arch/arm/mach-omap2/drm.c
> > @@ -0,0 +1,61 @@
> > +/*
> > + * 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 
> > +
> > +#include 
> > +#include 
> > +
> > +#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
> > +
> > +static struct platform_device omap_drm_device = {
> > + ? ? ? .dev = {
> > + ? ? ? ? ? ? ? .coherent_dma_mask = DMA_BIT_MASK(32),
> > + ? ? ? },
> > + ? ? ? .name = "omapdrm",
> > + ? ? ? .id = 0,
> > +};
> > +
> > +static int __init omap_init_drm(void)
> > +{
> > + ? ? ? struct omap_hwmod *oh = NULL;
> > + ? ? ? struct platform_device *pdev;
> > +
> > + ? ? ? /* lookup and populate the DMM information, if present - OMAP4+ */
> > + ? ? ? oh = omap_hwmod_lookup("dmm");
> > +
> > + ? ? ? if (oh) {
> > + ? ? ? ? ? ? ? pdev = omap_device_build(oh->name, -1, oh, NULL, 0, NULL, 0,
> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? false);
> > + ? ? ? ? ? ? ? WARN(IS_ERR(pdev), "Could not build omap_device for %s\n",
> > + ? ? ? ? ? ? ? ? ? ? ? oh->name);
> > + ? ? ? }
> > +
> > + ? ? ? return platform_device_register(_drm_device);
> > +
> > +}
> > +
> > +arch_initcall(omap_init_drm);
> > +
> > +#endif
> > diff --git a/drivers/staging/omapdrm/omap_drv.h 
> > b/drivers/staging/omapdrm/omap_drv.h
> > index b7e0f07..96296e0 100644
> > --- a/drivers/staging/omapdrm/omap_drv.h
> > +++ b/drivers/staging/omapdrm/omap_drv.h
> > @@ -25,8 +25,8 @@
> > ?#include 
> > ?#include 
> > ?#include 
> > +#include 
> > ?#include "omap_drm.h"
> > -#include "omap_priv.h"
> >
> > ?#define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
> > ?#define VERB(fmt, ...) if (0) DRM_DEBUG(fmt, ##__VA_ARGS__) /* verbose 
> > debug */
> > diff --git a/drivers/staging/omapdrm/omap_priv.h 
> > b/drivers/staging/omapdrm/omap_priv.h
> > deleted file mode 100644
> > index ef64414..000
> > --- a/drivers/staging/omapdrm/omap_priv.h
> > +++ /dev/null
> > @@ -1,55 +0,0 @@
> > -/*
> > - * include/drm/omap_priv.h
> > - *
> > - * Copyright (C) 2011 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 

Re: [PATCH] omap2+: add drm device

[Gross, Andy]

Tony,

Please queue this patch at your earliest convenience.

We had some discussion on the splitting out of the DMM/Tiler driver
from the omapdrm driver.  There might be some interest in leveraging
the Tiler for omapfb.  However, we agreed this can be deferred until
some other device (omapfb or otherwise) needs to use the Tiler.

Regards,

Andy Gross


On Mon, Jun 11, 2012 at 10:51 AM, Rob Clark rob.cl...@linaro.org wrote:

 On Wed, May 23, 2012 at 3:08 PM, Andy Gross andy.gr...@ti.com wrote:
  Register OMAP DRM/KMS platform device.  DMM is split into a
  separate device using hwmod.
 
  Signed-off-by: Andy Gross andy.gr...@ti.com

 Signed-off-by: Rob Clark rob.cl...@linaro.org

  ---
   arch/arm/mach-omap2/Makefile           |    4 ++
   arch/arm/mach-omap2/drm.c              |   61 
  
   drivers/staging/omapdrm/omap_drv.h     |    2 +-
   drivers/staging/omapdrm/omap_priv.h    |   55 
   include/linux/platform_data/omap_drm.h |   52 +++
   5 files changed, 118 insertions(+), 56 deletions(-)
   create mode 100644 arch/arm/mach-omap2/drm.c
   delete mode 100644 drivers/staging/omapdrm/omap_priv.h
   create mode 100644 include/linux/platform_data/omap_drm.h
 
  diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
  index 49f92bc..c301ab7 100644
  --- a/arch/arm/mach-omap2/Makefile
  +++ b/arch/arm/mach-omap2/Makefile
  @@ -187,6 +187,10 @@ ifneq ($(CONFIG_TIDSPBRIDGE),)
   obj-y                                  += dsp.o
   endif
 
  +ifneq ($(CONFIG_DRM_OMAP),)
  +obj-y                                  += drm.o
  +endif
  +
   # Specific board support
   obj-$(CONFIG_MACH_OMAP_GENERIC)                += board-generic.o
   obj-$(CONFIG_MACH_OMAP_H4)             += board-h4.o
  diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
  new file mode 100644
  index 000..72e0f01b
  --- /dev/null
  +++ b/arch/arm/mach-omap2/drm.c
  @@ -0,0 +1,61 @@
  +/*
  + * 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
  +
  +#include plat/omap_device.h
  +#include plat/omap_hwmod.h
  +
  +#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
  +
  +static struct platform_device omap_drm_device = {
  +       .dev = {
  +               .coherent_dma_mask = DMA_BIT_MASK(32),
  +       },
  +       .name = omapdrm,
  +       .id = 0,
  +};
  +
  +static int __init omap_init_drm(void)
  +{
  +       struct omap_hwmod *oh = NULL;
  +       struct platform_device *pdev;
  +
  +       /* lookup and populate the DMM information, if present - OMAP4+ */
  +       oh = omap_hwmod_lookup(dmm);
  +
  +       if (oh) {
  +               pdev = omap_device_build(oh-name, -1, oh, NULL, 0, NULL, 0,
  +                                       false);
  +               WARN(IS_ERR(pdev), Could not build omap_device for %s\n,
  +                       oh-name);
  +       }
  +
  +       return platform_device_register(omap_drm_device);
  +
  +}
  +
  +arch_initcall(omap_init_drm);
  +
  +#endif
  diff --git a/drivers/staging/omapdrm/omap_drv.h 
  b/drivers/staging/omapdrm/omap_drv.h
  index b7e0f07..96296e0 100644
  --- a/drivers/staging/omapdrm/omap_drv.h
  +++ b/drivers/staging/omapdrm/omap_drv.h
  @@ -25,8 +25,8 @@
   #include linux/types.h
   #include drm/drmP.h
   #include drm/drm_crtc_helper.h
  +#include linux/platform_data/omap_drm.h
   #include omap_drm.h
  -#include omap_priv.h
 
   #define DBG(fmt, ...) DRM_DEBUG(fmt\n, ##__VA_ARGS__)
   #define VERB(fmt, ...) if (0) DRM_DEBUG(fmt, ##__VA_ARGS__) /* verbose 
  debug */
  diff --git a/drivers/staging/omapdrm/omap_priv.h 
  b/drivers/staging/omapdrm/omap_priv.h
  deleted file mode 100644
  index ef64414..000
  --- a/drivers/staging/omapdrm/omap_priv.h
  +++ /dev/null
  @@ -1,55 +0,0 @@
  -/*
  - * include/drm/omap_priv.h
  - *
  - * Copyright (C) 2011 Texas Instruments
  - * Author: Rob Clark r...@ti.com
  - *
  - * 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
  

[PATCH] omap2+: add drm device

[Gross, Andy]

Tomi,

So at this point, are you OK with deferring a split of the DMM until it
necessary to do so (if ever)?  I'd like to get this patch in so that people
have a working omapdrm device when they enable the config options.

Regards,

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

Re: [PATCH] omap2+: add drm device

[Gross, Andy]

Tomi,

So at this point, are you OK with deferring a split of the DMM until it
necessary to do so (if ever)?  I'd like to get this patch in so that people
have a working omapdrm device when they enable the config options.

Regards,

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

[PATCH] omap2+: add drm device

[Gross, Andy]

On Thu, May 24, 2012 at 7:13 AM, Tomi Valkeinen  
wrote:
> On Thu, 2012-05-24 at 02:44 -0600, Rob Clark wrote:
>
>> but other drivers *can* use tiler, thanks to dmabuf.. I have omap4iss
>> v4l2 camera working w/ tiler buffers on my pandaboard, for example.
>>
>> Maybe fbdev is an exception to the rule because it has no way for
>> userspace to pass it a buffer to use. ?But on the other hand it is a
>> legacy API so I'm not sure if it is worth loosing too much sleep over
>> that.
>
> I'm not that familiar with dmabuf, but are you saying it's not possible
> for a kernel driver to request the buffers? They _must_ come from the
> userspace?
>
> Anyway, even if it would be possible, if the tiler is a part of omapdrm
> we need omapdrm to get and use the tiler buffers. And we can't have
> omapdrm running when using omapfb, because they both use omapdss.

And that is a good point.  The DSS is kind of a sticking point to anyone
having to enable DRM to get Tiler.  However, omapfb doesn't currently utilize
DMM/Tiler features.  Can't we defer generalizing until there is a
requirement for it?

Andy

[PATCH] omap2+: add drm device

[Gross, Andy]

On Thu, May 24, 2012 at 1:01 AM, Tomi Valkeinen  
wrote:
>> +struct omap_drm_platform_data {
>> + ? ? struct omap_kms_platform_data *kms_pdata;
>> +};
>
> This one is missing struct omap_dmm_platform_data *dmm_pdata, so you
> didn't just move the struct. Is that on purpose?

Good point.  I can clean that up.


Andy

Re: [PATCH] omap2+: add drm device

[Gross, Andy]

On Thu, May 24, 2012 at 1:01 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 +struct omap_drm_platform_data {
 +     struct omap_kms_platform_data *kms_pdata;
 +};

 This one is missing struct omap_dmm_platform_data *dmm_pdata, so you
 didn't just move the struct. Is that on purpose?

Good point.  I can clean that up.


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

Re: [PATCH] omap2+: add drm device

[Gross, Andy]

On Thu, May 24, 2012 at 7:13 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
 On Thu, 2012-05-24 at 02:44 -0600, Rob Clark wrote:

 but other drivers *can* use tiler, thanks to dmabuf.. I have omap4iss
 v4l2 camera working w/ tiler buffers on my pandaboard, for example.

 Maybe fbdev is an exception to the rule because it has no way for
 userspace to pass it a buffer to use.  But on the other hand it is a
 legacy API so I'm not sure if it is worth loosing too much sleep over
 that.

 I'm not that familiar with dmabuf, but are you saying it's not possible
 for a kernel driver to request the buffers? They _must_ come from the
 userspace?

 Anyway, even if it would be possible, if the tiler is a part of omapdrm
 we need omapdrm to get and use the tiler buffers. And we can't have
 omapdrm running when using omapfb, because they both use omapdss.

And that is a good point.  The DSS is kind of a sticking point to anyone
having to enable DRM to get Tiler.  However, omapfb doesn't currently utilize
DMM/Tiler features.  Can't we defer generalizing until there is a
requirement for it?

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

[PATCH] omap2+: add drm device

[Gross, Andy]

On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen  wrote:
>
> Does this "DMM has become synonymous" mean that people just started
> calling TILER DMM, and thus the name has stuck, or are there technical
> reasons to handle it as DMM in the kernel? If the former, and if TILER
> is the technically exact name for it, perhaps it would make sense to
> call it TILER, as that's what (at least I) would be looking for if I
> read the TRM and try to find the code for the TILER.
>
> ?Tomi

Well the breakdown of the DMM/Tiler kind of goes like this.  The DMM
defines a set of registers used to manipulate the PAT table that backs
the address space with physical memory.  The Tiler portion of the DMM
really just describes the address space that is exposed.  Depending on
what address range you access, you'll get a different mode of access
and rotation.  Management of the address space is attributed to the
Tiler as well and that is where we have managed the address space and
provided APIs to reserve address space and pin/unpin memory to those
regions.

Re: [PATCH] omap2+: add drm device

[Gross, Andy]

On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:

 Does this DMM has become synonymous mean that people just started
 calling TILER DMM, and thus the name has stuck, or are there technical
 reasons to handle it as DMM in the kernel? If the former, and if TILER
 is the technically exact name for it, perhaps it would make sense to
 call it TILER, as that's what (at least I) would be looking for if I
 read the TRM and try to find the code for the TILER.

  Tomi

Well the breakdown of the DMM/Tiler kind of goes like this.  The DMM
defines a set of registers used to manipulate the PAT table that backs
the address space with physical memory.  The Tiler portion of the DMM
really just describes the address space that is exposed.  Depending on
what address range you access, you'll get a different mode of access
and rotation.  Management of the address space is attributed to the
Tiler as well and that is where we have managed the address space and
provided APIs to reserve address space and pin/unpin memory to those
regions.

From a hardware perspective, we need access to the resources provided
by the DMM so that we can do the PAT programming and that can only be
gotten from the hwmod entry.  And if you use the hwmod device entry,
you have to match the name used for that entry.

Regards,

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

[PATCH] omap2+: add drm device

[Gross, Andy]

On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen wrote:
>
>
> I have to say I don't know much about DMM, but my understanding is that
> DMM is a bigger entity, of which TILER is only a small part, and DMM
> manages all memory accesses.
>
> Can there be other users for the DMM than DRM? I know there could be
> other users for the TILER, and I know you want to combine that with the
> DRM driver, but I'm wondering about the other parts of DMM than the
> TILER.
>
> Somehow having a DMM driver inside omapdrm sounds strange.


The DMM does indeed contain a number of entities.  However, the TILER
portion is the only part that requires a driver.  All other register
modifications (LISA map settings, EMIF, etc) are done statically in the
loader or u-boot and never changed again.  As such, DMM has become
synonymous with TILER.

Regards,

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

Re: [PATCH] omap2+: add drm device

[Gross, Andy]

On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen tomi.valkei...@ti.comwrote:


 I have to say I don't know much about DMM, but my understanding is that
 DMM is a bigger entity, of which TILER is only a small part, and DMM
 manages all memory accesses.

 Can there be other users for the DMM than DRM? I know there could be
 other users for the TILER, and I know you want to combine that with the
 DRM driver, but I'm wondering about the other parts of DMM than the
 TILER.

 Somehow having a DMM driver inside omapdrm sounds strange.


The DMM does indeed contain a number of entities.  However, the TILER
portion is the only part that requires a driver.  All other register
modifications (LISA map settings, EMIF, etc) are done statically in the
loader or u-boot and never changed again.  As such, DMM has become
synonymous with TILER.

Regards,

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

[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 0/2] omap/drm: dmm/tiler support for GEM buffers

[Gross, Andy]

On Thu, Dec 8, 2011 at 2:45 AM, Tomi Valkeinen wrote:

> On Wed, 2011-12-07 at 07:29 -0600, Rob Clark wrote:
> > On Wed, Dec 7, 2011 at 3:31 AM, Tomi Valkeinen 
> wrote:
> > > Hi,
> > >
> > > On Mon, 2011-12-05 at 19:19 -0600, Rob Clark wrote:
> > >> From: Rob Clark 
> > >>
> > >> Support for DMM and tiled buffers.  The DMM/TILER block in omap4+ SoC
> > >> provides support for remapping physically discontiguous buffers for
> > >> various DMA initiators (DSS, IVAHD, etc) which do not otherwise
> support
> > >> non-physically contiguous buffers, as well as providing support for
> > >> tiled buffers.
> > >>
> > >> See the descriptions in the following two patches for more details.
> > >
> > > Why is the tiler/dmm driver integrated into the drm driver?
> >
> > Basically because of a big list of reasons to keep it integrated, and
> > no good reason that I could think of to make it a standalone driver.
>
> Well, I think it's good architecture to keep independent things
> separate. Also we have other display frameworks in the kernel than DRM.
>
>
I think we can split it out if we need to support other frameworks.  It
isn't that difficult to do.  If we were to do that, I presume it would
still reside in the gpu/ somewhere.  But I think I'd rather wait until we
have another framework require access.



> > 1) Because the function/usage is most like a GTT in other systems..
> > the usage is really graphics/multimedia related so GEM is a natural
> > way to expose it to userspace.  Other places we want to use tiler
> > buffers, like camera, are neatly handled by using dmabuf to export the
> > GEM buffer to a different device.
> >
> > 2) We went down the separate driver path in the past, and it really
> > exposes a lot of problems.  See the hacks that were done in the past
> > to get wakeup/resume sequencing correct when tiler was a separate
> > driver.  (hint: the table of page addresses needs to be reprogrammed
> > before any access to buffer mapped in DMM is done.. this can be
> > accomplished quite simply by restoring the LUT before enabling any
> > video pipes when it is in a single driver... although that is still in
> > the TODO)
> >
> > 3) Doing some of the more advanced stuff, like page flipping using
> > DMM's synchronized refill to update page addresses synchronized with
> > scannout will, I think, end up being some kinda weird API.. I don't
> > think I'd want to make that a public API exported by one driver
> > consumed by another, but not such a problem if it is just something
> > used internally by one driver.
> >
> > 4) The LUT isn't really big enough to be managed statically like we
> > did in the past.. it needs to be managed dynamically, mapping and
> > evicting buffers.  This is something that is typical with other gfx
> > drivers in their management of their GTT..
> >
> > 5) I wouldn't really want to duplicate the userspace mmap'ing games
> > for 2d buffers in a lot of different drivers.
>
> I can't really argue your points as I'm not familiar with the problems
> with the tiler. So I'm not questioning the decision to integrate the
> tiler code into drm, just expressing my toughts =).
>
> If the tiler driver had only kernel internal API, and no userspace APIs,
> I don't see why it'd be much more difficult to have as a separate driver
> than integrated into DRM. Well, except if the tiler code itself uses
> features offered by DRM extensively, and having the tiler code as an
> independent driver would mean replicating all those features.
>
> I guess it's not quite a fair comparison, but I'm comparing tiler to the
> vrfb driver (well, lib is perhaps a better word for it), which doesn't
> depend on any framework and can be used by any kernel component.
>
>
No I appreciate your input.  I had thoughts along the same line.  But since
I did not have any exported kernel functions, I figured that it should just
sit underneath the omapdrm umbrella (so to speak).
-- next part --
An HTML attachment was scrubbed...
URL: 

Re: [PATCH 0/2] omap/drm: dmm/tiler support for GEM buffers

[Gross, Andy]

On Thu, Dec 8, 2011 at 2:45 AM, Tomi Valkeinen tomi.valkei...@ti.comwrote:

 On Wed, 2011-12-07 at 07:29 -0600, Rob Clark wrote:
  On Wed, Dec 7, 2011 at 3:31 AM, Tomi Valkeinen tomi.valkei...@ti.com
 wrote:
   Hi,
  
   On Mon, 2011-12-05 at 19:19 -0600, Rob Clark wrote:
   From: Rob Clark r...@ti.com
  
   Support for DMM and tiled buffers.  The DMM/TILER block in omap4+ SoC
   provides support for remapping physically discontiguous buffers for
   various DMA initiators (DSS, IVAHD, etc) which do not otherwise
 support
   non-physically contiguous buffers, as well as providing support for
   tiled buffers.
  
   See the descriptions in the following two patches for more details.
  
   Why is the tiler/dmm driver integrated into the drm driver?
 
  Basically because of a big list of reasons to keep it integrated, and
  no good reason that I could think of to make it a standalone driver.

 Well, I think it's good architecture to keep independent things
 separate. Also we have other display frameworks in the kernel than DRM.


I think we can split it out if we need to support other frameworks.  It
isn't that difficult to do.  If we were to do that, I presume it would
still reside in the gpu/ somewhere.  But I think I'd rather wait until we
have another framework require access.



  1) Because the function/usage is most like a GTT in other systems..
  the usage is really graphics/multimedia related so GEM is a natural
  way to expose it to userspace.  Other places we want to use tiler
  buffers, like camera, are neatly handled by using dmabuf to export the
  GEM buffer to a different device.
 
  2) We went down the separate driver path in the past, and it really
  exposes a lot of problems.  See the hacks that were done in the past
  to get wakeup/resume sequencing correct when tiler was a separate
  driver.  (hint: the table of page addresses needs to be reprogrammed
  before any access to buffer mapped in DMM is done.. this can be
  accomplished quite simply by restoring the LUT before enabling any
  video pipes when it is in a single driver... although that is still in
  the TODO)
 
  3) Doing some of the more advanced stuff, like page flipping using
  DMM's synchronized refill to update page addresses synchronized with
  scannout will, I think, end up being some kinda weird API.. I don't
  think I'd want to make that a public API exported by one driver
  consumed by another, but not such a problem if it is just something
  used internally by one driver.
 
  4) The LUT isn't really big enough to be managed statically like we
  did in the past.. it needs to be managed dynamically, mapping and
  evicting buffers.  This is something that is typical with other gfx
  drivers in their management of their GTT..
 
  5) I wouldn't really want to duplicate the userspace mmap'ing games
  for 2d buffers in a lot of different drivers.

 I can't really argue your points as I'm not familiar with the problems
 with the tiler. So I'm not questioning the decision to integrate the
 tiler code into drm, just expressing my toughts =).

 If the tiler driver had only kernel internal API, and no userspace APIs,
 I don't see why it'd be much more difficult to have as a separate driver
 than integrated into DRM. Well, except if the tiler code itself uses
 features offered by DRM extensively, and having the tiler code as an
 independent driver would mean replicating all those features.

 I guess it's not quite a fair comparison, but I'm comparing tiler to the
 vrfb driver (well, lib is perhaps a better word for it), which doesn't
 depend on any framework and can be used by any kernel component.


No I appreciate your input.  I had thoughts along the same line.  But since
I did not have any exported kernel functions, I figured that it should just
sit underneath the omapdrm umbrella (so to speak).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

ELC and memory management

[Gross, Andy]

All,

There has been some discussion on the linaro-dev list about having a memory
management meeting at the ELC.  See links below:

http://lists.linaro.org/pipermail/linaro-dev/2011-March/003053.html
http://lists.linaro.org/pipermail/linaro-dev/2011-March/003623.html

Our interest in this stems from our current effort to migrate our OMAP
display and memory management functionality to the DRI/DRM model.  Like
everyone else, we have to allocate large blocks of memory that are used for
display, video encode/decode, and capture.  We're in the same boat of having
implementations that are not upstream.

We'd like to get a meeting going on one of the days where there is a
graphics centric presentation (Tues/Wed).   I'm trying to cast a wider net
to get more involvement in this issue.

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

ELC and memory management

[Gross, Andy]

All,

There has been some discussion on the linaro-dev list about having a memory
management meeting at the ELC.  See links below:

http://lists.linaro.org/pipermail/linaro-dev/2011-March/003053.html
http://lists.linaro.org/pipermail/linaro-dev/2011-March/003623.html

Our interest in this stems from our current effort to migrate our OMAP
display and memory management functionality to the DRI/DRM model.  Like
everyone else, we have to allocate large blocks of memory that are used for
display, video encode/decode, and capture.  We're in the same boat of having
implementations that are not upstream.

We'd like to get a meeting going on one of the days where there is a
graphics centric presentation (Tues/Wed).   I'm trying to cast a wider net
to get more involvement in this issue.

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