[RESEND PATCH] drm/gma500: remove comment for non-existent parameter

[jiang.bi...@zte.com.cn]

Remove comment for non-existent parameter in psbfb_alloc().

Signed-off-by: Jiang Biao 
---
The previous patch was corrupted by the mail server, have to resend it. 

---
 drivers/gpu/drm/gma500/framebuffer.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 7440bf9..f323989 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -308,7 +308,6 @@ static struct drm_framebuffer *psb_framebuffer_create
  * psbfb_alloc -   allocate frame buffer memory
  * @dev: the DRM device
  * @aligned_size: space needed
- * @force: fall back to GEM buffers if need be
  *
  * Allocate the frame buffer. In the usual case we get a GTT range 
that
  * is stolen memory backed and life is simple. If there isn't 
sufficient
-- 
2.1.0
-- next part --
An HTML attachment was scrubbed...
URL: 

[RFC] drm/gma500: add virtual mapping support for fbdev.

[jiang.bi...@zte.com.cn]

Alan Cox  Wrote 2016/09/07 05:16:49:

> Alan Cox  
> 2016/09/07 05:16
> Re: [RFC] drm/gma500: add virtual mapping support for fbdev.
> 
> On Tue, 2016-09-06 at 19:28 +0800, jiang.biao2 at zte.com.cn wrote:
> > Hi, 
> > 
> > I found current gma500 fbdev driver does not support the virtual 
> > mapping for the fb pages, instead it only uses stolen pages and 
> > supports high resolution console by reducing the color depth. It 
> > works well with fbcon for high resolution envirnment. 
> 
> The text mode console code can't support a non-linear mapping and
> trying to grab one used most or all of the vmalloc address space on a
> 32bit box (and most of those systems are only able to run 32bit).
> 
> For the sake of a bootscreen loader (which could use DRM directly
> instead if it needed high resolution) it didn't seem worht it.
> 
> Either way it's not IMHO a good idea for 32bit, 64bit maybe.
> 
> Alan
> 

In addition to plymouth, one of our own app is using the fbdev 
directly too, so encounter the problem. Maybe it should also use DRM.

Thanks for you reply. 
-- next part --
An HTML attachment was scrubbed...
URL: 

[RFC] drm/gma500: add virtual mapping support for fbdev.

[jiang.bi...@zte.com.cn]

Hi,

I found current gma500 fbdev driver does not support the virtual 
mapping for the fb pages, instead it only uses stolen pages and 
supports high resolution console by reducing the color depth. It 
works well with fbcon for high resolution envirnment.

However, other programs, such as plymouth(a boot animation program) 
may also use fbdev driver to flush screen in high resolution 
envirnment, in that case, reducing the color depth will decrease the 
quality or result in other problem. 

Noticed that Alan's patch(commit 
dffc9ceb55695f121adc57dd1fde7304c3afe81e) killed the virtual mapping 
support for short of vmap space. But the vmalloc space(128M) should 
be enough for most high resolution envirnments.

So I'm considering add the virual mapping support for fbdev driver. 
The following patch has not done completely yet, still having console 
flicking problem need to be solved.

I'm not sure whether the patch will be useful for others or if there
is something I missed. Need your comments.

Thanks.

Signed-off-by: Jiang Biao

---
 drivers/gpu/drm/gma500/framebuffer.c | 110 
++-
 drivers/gpu/drm/gma500/framebuffer.h |   2 +
 2 files changed, 73 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 0fcdce0..21f14df 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -117,34 +117,43 @@ static int psbfb_vm_fault(struct vm_area_struct 
*vma, struct vm_fault *vmf)
struct psb_framebuffer *psbfb = vma->vm_private_data;
struct drm_device *dev = psbfb->base.dev;
struct drm_psb_private *dev_priv = dev->dev_private;
-   int page_num;
-   int i;
-   unsigned long address;
int ret;
unsigned long pfn;
-   unsigned long phys_addr = (unsigned long)dev_priv->stolen_base +
- psbfb->gtt->offset;
-
-   page_num = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
-   address = (unsigned long)vmf->virtual_address - (vmf->pgoff << 
PAGE_SHIFT);
-
-   vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
-
-   for (i = 0; i < page_num; i++) {
-   pfn = (phys_addr >> PAGE_SHIFT);
-
-   ret = vm_insert_mixed(vma, address,
-   __pfn_to_pfn_t(pfn, PFN_DEV));
-   if (unlikely((ret == -EBUSY) || (ret != 0 && i > 0)))
-   break;
-   else if (unlikely(ret != 0)) {
-   ret = (ret == -ENOMEM) ? VM_FAULT_OOM : 
VM_FAULT_SIGBUS;
-   return ret;
+   struct gtt_range *r;
+   pgoff_t page_offset;
+   r = psbfb->gtt;
+
+   mutex_lock(>struct_mutex);
+   if (r->mmapping == 0) {
+   ret = psb_gtt_pin(r);
+   if (ret < 0) {
+goto fail;
}
-   address += PAGE_SIZE;
-   phys_addr += PAGE_SIZE;
+   r->mmapping = 1;
+   }
+
+   page_offset = ((unsigned long) vmf->virtual_address - 
vma->vm_start)
+   >> PAGE_SHIFT;
+
+   if (r->stolen)
+   pfn = (dev_priv->stolen_base + r->offset) >> PAGE_SHIFT;
+   else
+   pfn = page_to_pfn(r->pages[page_offset]);
+
+   ret = vm_insert_pfn(vma, (unsigned long)vmf->virtual_address, 
pfn);
+
+fail:
+   mutex_unlock(>struct_mutex);
+   switch (ret) {
+   case 0:
+   case -ERESTARTSYS:
+   case -EINTR:
+   return VM_FAULT_NOPAGE;
+   case -ENOMEM:
+   return VM_FAULT_OOM;
+   default:
+   return VM_FAULT_SIGBUS;
}
-   return VM_FAULT_NOPAGE;
 }

 static void psbfb_vm_open(struct vm_area_struct *vma)
@@ -180,7 +189,7 @@ static int psbfb_mmap(struct fb_info *info, struct 
vm_area_struct *vma)
 */
vma->vm_ops = _vm_ops;
vma->vm_private_data = (void *)psbfb;
-   vma->vm_flags |= VM_IO | VM_MIXEDMAP | VM_DONTEXPAND | 
VM_DONTDUMP;
+   vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
return 0;
 }

@@ -317,7 +326,17 @@ static struct gtt_range *psbfb_alloc(struct 
drm_device *dev, int aligned_size)
drm_gem_private_object_init(dev, >gem, 
aligned_size);
return backing;
}
-   return NULL;
+   /* Next try using GEM host memory */
+backing = psb_gtt_alloc_range(dev, aligned_size, "fb(gem)", 0, 
PAGE_SIZE);
+if (backing == NULL)
+return NULL;
+
+/* Now back it with an object */
+if (drm_gem_object_init(dev, >gem, aligned_size) != 0) {
+psb_gtt_free_range(dev, backing);
+return NULL;
+}
+return backing;
 }

 /**
@@ -397,7 +416,8 @@ static int psbfb_create(struct psb_fbdev *fbdev,
return -ENOMEM;
}

-   memset(dev_priv->vram_addr + backing->offset, 0, size);

[PATCH] drm/gma500: remove the process of stolen page in page fault handler.

[jiang.bi...@zte.com.cn]

Patrik Jakobsson  wrote 2016/09/02 21:54:41:

> Patrik Jakobsson  
> 2016/09/02 21:54
> 
> Re: [PATCH] drm/gma500: remove the process of stolen page in page 
> fault handler.
> 
> On Fri, Sep 2, 2016 at 11:31 AM,   wrote:
> >
> > JiangBiao162664/user/zte_ltd Wrote 2016/08/31 10:27:34:
> >
> >> JiangBiao162664/user/zte_ltd
> >> 2016/08/31 10:27
> >>
> >> From
> >> Patrik Jakobsson ,
> >> Re: [PATCH] drm/gma500: remove the process of stolen page in page
> >> fault handler.
> >>
> >> Patrik Jakobsson  wrote on 2016/08/30
> >> 18:21:08:
> >>
> >> > Patrik Jakobsson 
> >> > 2016/08/30 18:21
> >> >
> >> > From
> >> > jiang.biao2 at zte.com.cn,
> >> > cc
> >> > dri-devel 
> >> > Re: [PATCH] drm/gma500: remove the process of stolen page in page
> >> fault handler.
> >> >
> >> > On Tue, Aug 30, 2016 at 7:10 AM,   wrote:
> >> > >
> >> > > Direct gtt range is used in the page fault scene in current 
driver,
> >> > > instead of stolen page. So no need to keep relative process.
> >> >
> >> > Hi
> >> >
> >> > Are you saying that we don't use stolen memory? Afaik stolen memory
> >> > should be accessed through the stolen range so we do need this.
> >> >
> >> > -Patrik
> >> >
> >> As far as I can see, the stolen memory is only used by fbdev driver
> >> in gma500,
> >> but the fbdev driver maps the stloen memory directly in 
psbfb_vm_fault,
> >> not
> >> using psb_gem_fault to map the stolen memory.
> >> The only scenario using the psb_gem_fault is the gtt range created by
> >> psb_gem_create, which alloc the gtt range without stolen memory 
backed.
> >
> >> If I missed something, pls enlighten me.
> >> Thanks a lot.
> >
> > Hi Patrik,
> >
> > Could you please help to confirm my question?
> > Thank you very much.
> 
> Hi,
> 
> The assumption that stolen memory will never be used with
> psb_gem_create() might not hold true in the future and silently
> breaking support for it ito save a few lines of code is not the right
> way to do it. Actually, if we find use for stolen memory we would
> basically get memory for free since it is already reserved for
> graphics usage.
> 
> Cheers
> Patrik

Understood, but maybe It's better to add it when it's actually used.
Indeed, that does not that matter.

Thanks for the reply.
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH] drm/gma500: remove the process of stolen page in page fault handler.

[jiang.bi...@zte.com.cn]

JiangBiao162664/user/zte_ltd Wrote 2016/08/31 10:27:34:

> JiangBiao162664/user/zte_ltd
> 2016/08/31 10:27
> 
> From
> Patrik Jakobsson , 
> Re: [PATCH] drm/gma500: remove the process of stolen page in page 
> fault handler.
> 
> Patrik Jakobsson  wrote on 2016/08/30 
18:21:08:
> 
> > Patrik Jakobsson  
> > 2016/08/30 18:21
> > 
> > From
> > jiang.biao2 at zte.com.cn, 
> > cc
> > dri-devel 
> > Re: [PATCH] drm/gma500: remove the process of stolen page in page 
> fault handler.
> > 
> > On Tue, Aug 30, 2016 at 7:10 AM,   wrote:
> > >
> > > Direct gtt range is used in the page fault scene in current driver,
> > > instead of stolen page. So no need to keep relative process.
> > 
> > Hi
> > 
> > Are you saying that we don't use stolen memory? Afaik stolen memory
> > should be accessed through the stolen range so we do need this.
> > 
> > -Patrik
> >
> As far as I can see, the stolen memory is only used by fbdev driver 
> in gma500, 
> but the fbdev driver maps the stloen memory directly in psbfb_vm_fault, 
not 
> using psb_gem_fault to map the stolen memory. 
> The only scenario using the psb_gem_fault is the gtt range created by 
> psb_gem_create, which alloc the gtt range without stolen memory backed.

> If I missed something, pls enlighten me.
> Thanks a lot. 

Hi Patrik,

Could you please help to confirm my question?
Thank you very much.
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH] drm/gma500: remove the process of stolen page in page fault handler.

[jiang.bi...@zte.com.cn]

Patrik Jakobsson  wrote on 2016/08/30 18:21:08:

> Patrik Jakobsson 
> 2016/08/30 18:21
>
> From
> jiang.biao2 at zte.com.cn,
> cc
> dri-devel 
> Re: [PATCH] drm/gma500: remove the process of stolen page in page fault 
> handler.
>
> On Tue, Aug 30, 2016 at 7:10 AM,   wrote:
> >
> > Direct gtt range is used in the page fault scene in current driver,
> > instead of stolen page. So no need to keep relative process.
>
> Hi
>
> Are you saying that we don't use stolen memory? Afaik stolen memory
> should be accessed through the stolen range so we do need this.
>
> -Patrik
>
As far as I can see, the stolen memory is only used by fbdev driver in gma500,
but the fbdev driver maps the stloen memory directly in psbfb_vm_fault, not
using psb_gem_fault to map the stolen memory.
The only scenario using the psb_gem_fault is the gtt range created by
psb_gem_create, which alloc the gtt range without stolen memory backed.

If I missed something, pls enlighten me.
Thanks a lot.

[PATCH] drm/gma500: remove the process of stolen page in page fault handler.

[jiang.bi...@zte.com.cn]

Direct gtt range is used in the page fault scene in current driver,
instead of stolen page. So no need to keep relative process.

---
 drivers/gpu/drm/gma500/gem.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index 6d1cb6b..53cb6704 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -201,10 +201,7 @@ int psb_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
>> PAGE_SHIFT;

/* CPU view of the page, don't go via the GART for CPU writes */
-   if (r->stolen)
-   pfn = (dev_priv->stolen_base + r->offset) >> PAGE_SHIFT;
-   else
-   pfn = page_to_pfn(r->pages[page_offset]);
+   pfn = page_to_pfn(r->pages[page_offset]);
ret = vm_insert_pfn(vma, (unsigned long)vmf->virtual_address, pfn);

 fail:
--
2.1.0

[RESEND PATCH] drm/gma500: remove comment for non-existent parameter

[jiang.bi...@zte.com.cn]

Remove comment for non-existent parameter in psbfb_alloc().

Signed-off-by: Jiang Biao 
---
The previous patch was corrupted by the mail server, have to resend it.

---
 drivers/gpu/drm/gma500/framebuffer.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 7440bf9..f323989 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -308,7 +308,6 @@ static struct drm_framebuffer *psb_framebuffer_create
  * psbfb_alloc -   allocate frame buffer memory
  * @dev: the DRM device
  * @aligned_size: space needed
- * @force: fall back to GEM buffers if need be
  *
  * Allocate the frame buffer. In the usual case we get a GTT range that
  * is stolen memory backed and life is simple. If there isn't sufficient
--
2.1.0

答复: Re: [RESEND PATCH] drm/gma500: Fix comments in gtt.c

[jiang.bi...@zte.com.cn]

Daniel Vetter  wrote on 2016/08/10 17:22:14:

> Daniel Vetter 
> From:  Daniel Vetter 
> 2016/08/10 17:22
>
> To: jiang.biao2 at zte.com.cn,
>
> Re: [RESEND PATCH] drm/gma500: Fix comments in gtt.c
>
> On Wed, Aug 10, 2016 at 04:52:53PM +0800, jiang.biao2 at zte.com.cn wrote:
> >
> >
> > Daniel Vetter  wrote on 2016/08/10 16:35:29:
> >
> > > Daniel Vetter 
> > > From: Daniel Vetter 
> > >
> > > 2016/08/10 16:35
> > >
> > >
> > > jiang.biao2 at zte.com.cn,
> > >
> > >
> > > Re: [RESEND PATCH] drm/gma500: Fix comments in gtt.c
> > >
> > > On Wed, Aug 10, 2016 at 11:35:14AM +0800, jiang.biao2 at zte.com.cn wrote:
> > > >
> > > > Fix some comment faults in gtt.c.
> > > >
> > > > Signed-off-by: Jiang Biao 
> > >
> > > Sending the same patch 3 times in just one hour doesn't help - people
> > > sometimes sleep, or are busy. Please let at least a few days pass until
> > > you ping (with a reply) or resend.
> > >
> > > Thanks, Daniel
> > >
> > I'm so sorry about the interruption.
> > The mail server of my company corrupted the format of first two patchs,
> > and I have to resend it with correct format, after I corrected the
> > configuration of the mail server. The format of the last one should be
> > right.
> > I'm fresh to this mailing list, next time should be right.
> > Thanks a lot.
>
> Ah now worries. In such a case simply add a small comment to your resend
> patches why you're resending. You can add such comments to the commit
> message at the and after a line with just --- git will then cut it away.
> E.g.
>
> ... commmit message ...
>
> Signed-off-by: Daniel Vetter 
> ---
> This here is an additional comment which will not get applied to the real
> git log.
>
> Making sure that the patch isn't corrupted is definitely appreciated!
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Actually, as newcomer, I didn't exactly know how to resend a patch in this
case. Thank you very much for your guidance, that's very helpful for me.

What I want is just to make my contribution, hope to communicate with you
more often.

Next time will be better. Thanks again.

[RESEND PATCH] drm/gma500: Fix comments in gtt.c

[jiang.bi...@zte.com.cn]

Daniel Vetter  wrote on 2016/08/10 16:35:29:

> Daniel Vetter 
> From: Daniel Vetter 
>
> 2016/08/10 16:35
>
>
> jiang.biao2 at zte.com.cn,
>
>
> Re: [RESEND PATCH] drm/gma500: Fix comments in gtt.c
>
> On Wed, Aug 10, 2016 at 11:35:14AM +0800, jiang.biao2 at zte.com.cn wrote:
> >
> > Fix some comment faults in gtt.c.
> >
> > Signed-off-by: Jiang Biao 
>
> Sending the same patch 3 times in just one hour doesn't help - people
> sometimes sleep, or are busy. Please let at least a few days pass until
> you ping (with a reply) or resend.
>
> Thanks, Daniel
>
I'm so sorry about the interruption.
The mail server of my company corrupted the format of first two patchs,
and I have to resend it with correct format, after I corrected the
configuration of the mail server. The format of the last one should be
right.
I'm fresh to this mailing list, next time should be right.
Thanks a lot.

[RESEND PATCH] drm/gma500: Fix comments in gtt.c

[jiang.bi...@zte.com.cn]

Fix some comment faults in gtt.c.

Signed-off-by: Jiang Biao 
---
 drivers/gpu/drm/gma500/gtt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index 8f69225..9f9f588 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/drivers/gpu/drm/gma500/gtt.c
@@ -76,6 +76,7 @@ static u32 __iomem *psb_gtt_entry(struct drm_device *dev, 
struct gtt_range *r)
  * psb_gtt_insert  -   put an object into the GTT
  * @dev: our DRM device
  * @r: our GTT range
+ * @resume: on resume
  *
  * Take our preallocated GTT range and insert the GEM object into
  * the GTT. This is protected via the gtt mutex which the caller
@@ -321,6 +322,7 @@ out:
  * @len: length (bytes) of address space required
  * @name: resource name
  * @backed: resource should be backed by stolen pages
+ * @align: requested alignment
  *
  * Ask the kernel core to find us a suitable range of addresses
  * to use for a GTT mapping.
@@ -440,7 +442,6 @@ int psb_gtt_init(struct drm_device *dev, int resume)
PSB_WVDC32(dev_priv->pge_ctl | _PSB_PGETBL_ENABLED, PSB_PGETBL_CTL);
(void) PSB_RVDC32(PSB_PGETBL_CTL);

-   /* The root resource we allocate address space from */
dev_priv->gtt_initialized = 1;

pg->gtt_phys_start = dev_priv->pge_ctl & PAGE_MASK;
--
2.1.0

[RESEND PATCH] drm/gma500: Fix comments in gtt.c

[jiang.bi...@zte.com.cn]

Fix some comment faults in gtt.c.

Signed-off-by: Jiang Biao 
---
 drivers/gpu/drm/gma500/gtt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index 8f69225..9f9f588 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/drivers/gpu/drm/gma500/gtt.c
@@ -76,6 +76,7 @@ static u32 __iomem *psb_gtt_entry(struct drm_device 
*dev, struct gtt_range *r)
  * psb_gtt_insert  -   put an object into the GTT
  * @dev: our DRM device
  * @r: our GTT range
+ * @resume: on resume
  *
  * Take our preallocated GTT range and insert the GEM object into
  * the GTT. This is protected via the gtt mutex which the caller
@@ -321,6 +322,7 @@ out:
  * @len: length (bytes) of address space required
  * @name: resource name
  * @backed: resource should be backed by stolen pages
+ * @align: requested alignment
  *
  * Ask the kernel core to find us a suitable range of addresses
  * to use for a GTT mapping.
@@ -440,7 +442,6 @@ int psb_gtt_init(struct drm_device *dev, int resume)
PSB_WVDC32(dev_priv->pge_ctl | _PSB_PGETBL_ENABLED, 
PSB_PGETBL_CTL);
(void) PSB_RVDC32(PSB_PGETBL_CTL);

-   /* The root resource we allocate address space from */
dev_priv->gtt_initialized = 1;

pg->gtt_phys_start = dev_priv->pge_ctl & PAGE_MASK;
-- 
2.1.0

[PATCH] drm/gma500: Fix comments in gtt.c

[jiang.bi...@zte.com.cn]

Fix some comment faults in gtt.c.

Signed-off-by: Jiang Biao 
---
 drivers/gpu/drm/gma500/gtt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index 8f69225..9f9f588 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/drivers/gpu/drm/gma500/gtt.c
@@ -76,6 +76,7 @@ static u32 __iomem *psb_gtt_entry(struct drm_device 
*dev, struct gtt_range *r)
  * psb_gtt_insert  -   put an object into the GTT
  * @dev: our DRM device
  * @r: our GTT range
+ * @resume: on resume
  *
  * Take our preallocated GTT range and insert the GEM object into
  * the GTT. This is protected via the gtt mutex which the caller
@@ -321,6 +322,7 @@ out:
  * @len: length (bytes) of address space required
  * @name: resource name
  * @backed: resource should be backed by stolen pages
+ * @align: requested alignment
  *
  * Ask the kernel core to find us a suitable range of addresses
  * to use for a GTT mapping.
@@ -440,7 +442,6 @@ int psb_gtt_init(struct drm_device *dev, int resume)
PSB_WVDC32(dev_priv->pge_ctl | _PSB_PGETBL_ENABLED, 
PSB_PGETBL_CTL);
(void) PSB_RVDC32(PSB_PGETBL_CTL);

-   /* The root resource we allocate address space from */
dev_priv->gtt_initialized = 1;

pg->gtt_phys_start = dev_priv->pge_ctl & PAGE_MASK;
-- 
2.1.0

[PATCH] drm/gma500: remove comment for non-existent parameter

[jiang.bi...@zte.com.cn]

Remove comment for non-existent parameter in psbfb_alloc().

Signed-off-by: Jiang Biao 
---
 drivers/gpu/drm/gma500/framebuffer.c | 1 - 
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 7440bf9..f323989 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -308,7 +308,6 @@ static struct drm_framebuffer *psb_framebuffer_create
  * psbfb_alloc -   allocate frame buffer memory
  * @dev: the DRM device
  * @aligned_size: space needed
- * @force: fall back to GEM buffers if need be
  *
  * Allocate the frame buffer. In the usual case we get a GTT range that
  * is stolen memory backed and life is simple. If there isn't sufficient
-- 
2.1.0

[PATCH] drm/gma500: remove comment for non-existent parameter

[jiang.bi...@zte.com.cn]

Remove comment for non-existent parameter in psbfb_alloc().

Signed-off-by: Jiang Biao 
---
 drivers/gpu/drm/gma500/framebuffer.c | 1 - 
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 7440bf9..f323989 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -308,7 +308,6 @@ static struct drm_framebuffer *psb_framebuffer_create
  * psbfb_alloc -   allocate frame buffer memory
  * @dev: the DRM device
  * @aligned_size: space needed
- * @force: fall back to GEM buffers if need be
  *
  * Allocate the frame buffer. In the usual case we get a GTT range that
  * is stolen memory backed and life is simple. If there isn't sufficient
-- 
2.1.0