[PATCH 4/4] drm: Renesas SH Mobile DRM driver
On 06/27/2012 10:27 PM, Laurent Pinchart wrote: > Hi Lars-Peter, > > On Wednesday 27 June 2012 22:06:54 Lars-Peter Clausen wrote: >> On 06/27/2012 02:40 PM, Laurent Pinchart wrote: >>> Hi Lars-Peter, >>> >>> [...] >>> >>> Do you plan to post a v3 of your "DRM: Add DRM kms/fb cma helper" patch in >>> the near future ? >> >> Hi Laurent, >> >> I don't think there have been any changes since v2 except for adjusting to >> the renamed functions in Sascha's patch. I'll send a v3 tomorrow. > > OK, thanks. > > As Ville pointed out, we need to validate the offsets and make sure the frame > buffer fits in the GEM object(s). I don't think there's code in your patch to > do so, have you thought about where/how to implement that ? I think part of it needs to be done in the driver code, since the the generic code does not the specific buffer layout requirements imposed by the hardware. We can probably add some basic sanity checks for the buffer size though. - Lars
[PATCHv7 03/15] v4l: vb2: add support for shared buffer (dma_buf)
Hi Dima, On Tuesday 26 June 2012 13:53:34 Dima Zavin wrote: > On Tue, Jun 26, 2012 at 2:40 AM, Hans Verkuil wrote: > > On Tue 26 June 2012 11:11:06 Laurent Pinchart wrote: > >> On Tuesday 26 June 2012 10:40:44 Tomasz Stanislawski wrote: > >> > Hi Dima Zavin, > >> > Thank you for the patch and for a ping remainder :). > >> > > >> > You are right. The unmap is missing in __vb2_queue_cancel. > >> > I will apply your fix into next version of V4L2 support for dmabuf. > >> > > >> > Please refer to some comments below. > >> > > >> > On 06/20/2012 08:12 AM, Dima Zavin wrote: > >> > > Tomasz, > >> > > > >> > > I've encountered an issue with this patch when userspace does several > >> > > stream_on/stream_off cycles. When the user tries to qbuf a buffer > >> > > after doing stream_off, we trigger the "dmabuf already pinned" > >> > > warning since we didn't unmap the buffer as dqbuf was never called. > >> > > > >> > > The below patch adds calls to unmap in queue_cancel, but my feeling > >> > > is that we probably should be calling detach too (i.e. put_dmabuf). > >> > >> According to the V4L2 specification, the "VIDIOC_STREAMOFF ioctl, apart > >> of aborting or finishing any DMA in progress, unlocks any user pointer > >> buffers locked in physical memory, and it removes all buffers from the > >> incoming and outgoing queues". > > > > Correct. And what that means in practice is that after a streamoff all > > buffers are returned to the state they had just before STREAMON was > > called. > > That can't be right. The buffers had to have been returned to the > state just *after REQBUFS*, not just *before STREAMON*. You need to > re-enqueue buffers before calling STREAMON. I assume that's what you > meant? Your interpretation is correct. > > So after STREAMOFF you can immediately queue all buffers again with QBUF > > and call STREAMON to restart streaming. No mmap or other operations > > should be required. This behavior must be kept. > > > > VIDIOC_REQBUFS() or a close() are the only two operations that will > > actually free the buffers completely. > > > > In practice, a STREAMOFF is either followed by a STREAMON at a later time, > > or almost immediately followed by REQBUFS or close() to tear down the > > buffers. So I don't think the buffers should be detached at streamoff. > > I agree. I was leaning this way which is why I left it out of my patch > and wanted to hear your guys' opinion as you are much more familiar > with the intended behavior than I am. > > Thanks! You're welcome. Thank you for reporting the problem and providing a patch. -- Regards, Laurent Pinchart
[PATCH 10/10] drm/exynos: consider memory releasing to exported gem buffer into dmabuf
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Wednesday, June 27, 2012 9:55 PM
> To: Inki Dae
> Cc: 'Rob Clark'; kyungmin.park at samsung.com; sw0312.kim at samsung.com; dri-
> devel at lists.freedesktop.org
> Subject: Re: [PATCH 10/10] drm/exynos: consider memory releasing to
> exported gem buffer into dmabuf
>
> On Wed, Jun 27, 2012 at 09:44:15PM +0900, Inki Dae wrote:
> > Hi Rob,
> >
> > > -Original Message-
> > > From: robdclark at gmail.com [mailto:robdclark at gmail.com] On Behalf Of
> Rob
> > > Clark
> > > Sent: Wednesday, June 27, 2012 9:20 PM
> > > To: Inki Dae
> > > Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> > > kyungmin.park at samsung.com; sw0312.kim at samsung.com
> > > Subject: Re: [PATCH 10/10] drm/exynos: consider memory releasing to
> > > exported gem buffer into dmabuf
> > >
> > > On Wed, Jun 27, 2012 at 3:03 AM, Inki Dae
wrote:
> > > > exported gem buffer into dmabuf should be released when a gem relese
> is
> > > > requested by user. with dma_buf_put() call, if file->f_count is 0
> then
> > > > a release callback of exynos gem module(exporter) will be called to
> > > release
> > > > its own gem buffer.
> > > >
> > > > Signed-off-by: Inki Dae
> > > > Signed-off-by: Kyungmin Park
> > > > ---
> > > > drivers/gpu/drm/exynos/exynos_drm_drv.c |1 +
> > > > drivers/gpu/drm/exynos/exynos_drm_gem.c | 16
> > > > drivers/gpu/drm/exynos/exynos_drm_gem.h |4
> > > > 3 files changed, 21 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > > b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > > > index d6de2e0..1501dd2 100644
> > > > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > > > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > > > @@ -258,6 +258,7 @@ static struct drm_driver exynos_drm_driver = {
> > > >.gem_init_object= exynos_drm_gem_init_object,
> > > >.gem_free_object= exynos_drm_gem_free_object,
> > > >.gem_vm_ops = &exynos_drm_gem_vm_ops,
> > > > + .gem_close_object = exynos_drm_gem_close_object,
> > > >.dumb_create= exynos_drm_gem_dumb_create,
> > > >.dumb_map_offset= exynos_drm_gem_dumb_map_offset,
> > > >.dumb_destroy = exynos_drm_gem_dumb_destroy,
> > > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> > > b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> > > > index 411d82b..5ca8641 100644
> > > > --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> > > > +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> > > > @@ -27,6 +27,7 @@
> > > > #include "drm.h"
> > > >
> > > > #include
> > > > +#include
> > > > #include
> > > >
> > > > #include "exynos_drm_drv.h"
> > > > @@ -749,6 +750,21 @@ int exynos_drm_gem_dumb_destroy(struct drm_file
> > > *file_priv,
> > > >return 0;
> > > > }
> > > >
> > > > +void exynos_drm_gem_close_object(struct drm_gem_object *obj,
> > > > + struct drm_file *file)
> > > > +{
> > > > + DRM_DEBUG_KMS("%s\n", __FILE__);
> > > > +
> > > > + /*
> > > > +* exported dmabuf should be released when a gem is released
> by
> > > user.
> > > > +* with dma_buf_put() call, if file->f_count is 0 then a
> release
> > > > +* callback of gem module(exporter) will be called to
release
> > > > +* its own gem buffer.
> > > > +*/
> > > > + if (obj->export_dma_buf)
> > > > + dma_buf_put(obj->export_dma_buf);
> > >
> > > this doesn't seem quite right to me.. although I think the dmabuf
> > > release fxn needs to NULL out the obj->export_dma_buf.
> > >
> > > If your GEM obj is getting released before your dmabuf then there is
> > > something going wrong with the ref cnt'ing.
> > >
> > > BR,
> > > -R
> > >
> >
> > Could you look into below steps? I understood gem and dmabuf life cycle
> like below so thought we needs this patch. with this patch, the gem object
> isn't getting released before dmabuf and the gem will be released by
> dma_buf_put(). if there is my missing point then please give me any
> comment.
> >
> > Reference count(step number)
> >
> > gem object1 gem object2 dmabuf
> >
> > 1(1)
> > 2(2) 1(2)
> > 1(3) 2(3)
> > 0(4) 1(4)
> > 1(5) 0(5)
> > 0(5)
> >
> >
> > 1. create gem1
> > 2. export the gem1 into dmabuf
> > 3. import the dmabuf into gem2
> > 4. close gem2
> > 5. close gem1
>
> Step 5 looks wrong, simply closing the gem object 1 (in the exporting
> driver) can't change the reference count of the dmabuf object.
>
> Furthermore the dmabuf object _must_ be able to outlive the object it's
> been created
[PATCH 4/4] drm: Renesas SH Mobile DRM driver
Hi Lars-Peter, On Wednesday 27 June 2012 22:06:54 Lars-Peter Clausen wrote: > On 06/27/2012 02:40 PM, Laurent Pinchart wrote: > > Hi Lars-Peter, > > > > [...] > > > > Do you plan to post a v3 of your "DRM: Add DRM kms/fb cma helper" patch in > > the near future ? > > Hi Laurent, > > I don't think there have been any changes since v2 except for adjusting to > the renamed functions in Sascha's patch. I'll send a v3 tomorrow. OK, thanks. As Ville pointed out, we need to validate the offsets and make sure the frame buffer fits in the GEM object(s). I don't think there's code in your patch to do so, have you thought about where/how to implement that ? > I think it makes most sense if you carry these two patches (Sascha's and > mine) as part of your "Renesas SH Mobile DRM driver" series, so reviewers > can see it in context. OK I'll do that. -- Regards, Laurent Pinchart
[PATCH 4/4] drm: Renesas SH Mobile DRM driver
On 06/27/2012 02:40 PM, Laurent Pinchart wrote: > Hi Lars-Peter, > > [...] > > Do you plan to post a v3 of your "DRM: Add DRM kms/fb cma helper" patch in > the > near future ? Hi Laurent, I don't think there have been any changes since v2 except for adjusting to the renamed functions in Sascha's patch. I'll send a v3 tomorrow. I think it makes most sense if you carry these two patches (Sascha's and mine) as part of your "Renesas SH Mobile DRM driver" series, so reviewers can see it in context. - Lars
[PATCH 10/10] drm/exynos: consider memory releasing to exported gem buffer into dmabuf
Hi Rob,
> -Original Message-
> From: robdclark at gmail.com [mailto:robdclark at gmail.com] On Behalf Of Rob
> Clark
> Sent: Wednesday, June 27, 2012 9:20 PM
> To: Inki Dae
> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> kyungmin.park at samsung.com; sw0312.kim at samsung.com
> Subject: Re: [PATCH 10/10] drm/exynos: consider memory releasing to
> exported gem buffer into dmabuf
>
> On Wed, Jun 27, 2012 at 3:03 AM, Inki Dae wrote:
> > exported gem buffer into dmabuf should be released when a gem relese is
> > requested by user. with dma_buf_put() call, if file->f_count is 0 then
> > a release callback of exynos gem module(exporter) will be called to
> release
> > its own gem buffer.
> >
> > Signed-off-by: Inki Dae
> > Signed-off-by: Kyungmin Park
> > ---
> > drivers/gpu/drm/exynos/exynos_drm_drv.c |1 +
> > drivers/gpu/drm/exynos/exynos_drm_gem.c | 16
> > drivers/gpu/drm/exynos/exynos_drm_gem.h |4
> > 3 files changed, 21 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > index d6de2e0..1501dd2 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > @@ -258,6 +258,7 @@ static struct drm_driver exynos_drm_driver = {
> >.gem_init_object= exynos_drm_gem_init_object,
> >.gem_free_object= exynos_drm_gem_free_object,
> >.gem_vm_ops = &exynos_drm_gem_vm_ops,
> > + .gem_close_object = exynos_drm_gem_close_object,
> >.dumb_create= exynos_drm_gem_dumb_create,
> >.dumb_map_offset= exynos_drm_gem_dumb_map_offset,
> >.dumb_destroy = exynos_drm_gem_dumb_destroy,
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> > index 411d82b..5ca8641 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> > @@ -27,6 +27,7 @@
> > #include "drm.h"
> >
> > #include
> > +#include
> > #include
> >
> > #include "exynos_drm_drv.h"
> > @@ -749,6 +750,21 @@ int exynos_drm_gem_dumb_destroy(struct drm_file
> *file_priv,
> >return 0;
> > }
> >
> > +void exynos_drm_gem_close_object(struct drm_gem_object *obj,
> > + struct drm_file *file)
> > +{
> > + DRM_DEBUG_KMS("%s\n", __FILE__);
> > +
> > + /*
> > +* exported dmabuf should be released when a gem is released by
> user.
> > +* with dma_buf_put() call, if file->f_count is 0 then a release
> > +* callback of gem module(exporter) will be called to release
> > +* its own gem buffer.
> > +*/
> > + if (obj->export_dma_buf)
> > + dma_buf_put(obj->export_dma_buf);
>
> this doesn't seem quite right to me.. although I think the dmabuf
> release fxn needs to NULL out the obj->export_dma_buf.
>
> If your GEM obj is getting released before your dmabuf then there is
> something going wrong with the ref cnt'ing.
>
> BR,
> -R
>
Could you look into below steps? I understood gem and dmabuf life cycle like
below so thought we needs this patch. with this patch, the gem object isn't
getting released before dmabuf and the gem will be released by dma_buf_put().
if there is my missing point then please give me any comment.
Reference count(step number)
gem object1 gem object2 dmabuf
1(1)
2(2) 1(2)
1(3) 2(3)
0(4) 1(4)
1(5) 0(5)
0(5)
1. create gem1
2. export the gem1 into dmabuf
3. import the dmabuf into gem2
4. close gem2
5. close gem1
Thanks,
Inki Dae
> > +}
> > +
> > int exynos_drm_gem_fault(struct vm_area_struct *vma, struct vm_fault
> *vmf)
> > {
> >struct drm_gem_object *obj = vma->vm_private_data;
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
> b/drivers/gpu/drm/exynos/exynos_drm_gem.h
> > index 14d038b..4f1ba1a 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
> > @@ -162,4 +162,8 @@ int exynos_drm_gem_fault(struct vm_area_struct *vma,
> struct vm_fault *vmf);
> > /* set vm_flags and we can change the vm attribute to other one at here.
> */
> > int exynos_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
> >
> > +/* do extra release exynos gem module needs when gem close is called.
> */
> > +void exynos_drm_gem_close_object(struct drm_gem_object *obj,
> > + struct drm_file *file);
> > +
> > #endif
> > --
> > 1.7.4.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/
[RFC][PATCH 0/10] Atomic modesetting v2
On Wed, Jun 27, 2012 at 09:48:26AM -0700, Jesse Barnes wrote: > On Wed, 27 Jun 2012 13:24:02 +0300 > ville.syrjala at linux.intel.com wrote: > > > Second version of the atomic mode setting work. Still very much > > work in progress. > > > > I decided that I can't afford to fight the drm_crtc_helper > > architecture due to the sheer amount of driver code depending on it. > > So I changed the code to do things in way that more closely matches > > drm_crtc_helper. > > :( > > > Next I'll be moving the buffer pinning to happen before any hw state > > is clobbered. This will avoid having to do actual rollbacks when > > pinning fails. And a similar treatment needs to be done to the PLL > > calculations (those should be done before buffer pinning). > > > > I didn't re-post all the i915 specific bits I have in my tree since those > > didn't really change. I pushed the whole work to the drm_atomic_2 branch > > at https://gitorious.org/vsyrjala/linux. > > OTOH introducing an atomic alternative to the helper stuff and moving > drivers over would probably end up looking a lot nicer. But there's no > doubt that's a huge chunk of work... I'm thinking that it should be doable. Well, at least for all the "core" features, but I'm not quite sure how it would handle all driver specific properties in a nice way. Basically what I have now in intel_atomic.c could become the new helper, but then it needs somehow to defer to the driver for some of the props. So either the driver needs to collect the state for those somehow, or we have the core do it the same way as for other objects, ie. overwrite the object state with the new values as we go on, and then roll back later if necessary. But then we potentially need to save/restore all properties in the beginning and end of the operation, or we could try to do it in some lazy fashion. > The other thing I'm worried about with atomic mode setting is handling > the legacy case properly. We'll still need to handle apps that want to > change one CRTC at a time without altering the state of other CRTCs. > In an atomic context, drivers should be able to assume they can shut > anything off that doesn't come in as part of the atomic state, which > means when we build a compat atomic setup, we'll need to read the > current state of any existing objects and pass them in to the driver... My current code collects the current state in the beginning (or rather it saves the state of all the objects in the beginning) and starts to modify the current state of the objects as new values are read in by the ioctl handler. Anything not part of the atomic modeset is left untouched. -- Ville Syrj?l? Intel OTC
[Bug 51484] New: [i915g] piglit fbo-srgb fails since 45fc069600ddbfe07a0a0cd5280161a8c7c55dd0
https://bugs.freedesktop.org/show_bug.cgi?id=51484 Bug #: 51484 Summary: [i915g] piglit fbo-srgb fails since 45fc069600ddbfe07a0a0cd5280161a8c7c55dd0 Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/i915g AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: cme3000 at gmail.com fbo-srgb crashs: http://paste.debian.net/hidden/b3827a62/ this bug also affects wined3d (for example http://www.pouet.net/prod.php?which=1221 in wine) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[dan...@ffwll.ch: [pull] drm-intel-fixes]
I'm so ridiculously good at forgetting about the cc's on these pull requests ... -Daniel - Forwarded message from Daniel Vetter - Date: Wed, 27 Jun 2012 20:39:43 +0200 From: Daniel Vetter To: Dave Airlie Subject: [pull] drm-intel-fixes Message-ID: <20120627183943.GI5326 at phenom.ffwll.local> Hi Dave, Two tiny patches and one revert: - Kill a bogus error message introduced in 3.4, further Bspec reading indicates that this is how the hw is supposed to work. - Reorder one backlight register restore, fixing broken backlight on some machines after resume. - Revert a hack from Jesse for ivb backlight control - it breaks the backlight controls on my shiny new ivb laptop. Otherwise I'm only aware of 1-2 regression reports about new modes that don't work - but it looks like Ajax is already picking up the fallout on that one. Yours, Daniel The following changes since commit 8874e812feb4926f4a51a82c4fca75c7daa05fc5: Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs (2012-06-21 13:41:07 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to 7aa1e7f06d6ea1bce3b27630d50769d13da28b1a: Revert "drm/i915: allow PCH PWM override on IVB" (2012-06-27 20:26:30 +0200) Daniel Vetter (2): drm/i915: rip out the PM_IIR WARN Revert "drm/i915: allow PCH PWM override on IVB" Takashi Iwai (1): drm/i915: Fix eDP blank screen after S3 resume on HP desktops drivers/gpu/drm/i915/i915_irq.c |1 - drivers/gpu/drm/i915/i915_suspend.c |5 - drivers/gpu/drm/i915/intel_display.c | 16 3 files changed, 4 insertions(+), 18 deletions(-) -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48 - End forwarded message - -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[Bug 51344] massive corruption on RV410
https://bugs.freedesktop.org/show_bug.cgi?id=51344 --- Comment #4 from Tormod Volden 2012-06-27 12:33:37 PDT --- Sorry, I don't know when I can have time to do that. I'll try harder if the bug can be confirmed by other people too. Maybe the right developer can make an educated guess if it's limited to this card. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC][PATCH 0/10] Atomic modesetting v2
On Wed, Jun 27, 2012 at 6:11 PM, Adam Jackson wrote: > On Wed, 2012-06-27 at 09:48 -0700, Jesse Barnes wrote: > >> The other thing I'm worried about with atomic mode setting is handling >> the legacy case properly. ?We'll still need to handle apps that want to >> change one CRTC at a time without altering the state of other CRTCs. > > Fortunately that's not true, you can flag-day it (per drm device even, > if we want). ?If the first thing userspace asks for is atomic modeset > then you simply disallow subsequent non-atomic modesets, and the > reverse. ?Userspace code will need to grow atomic support anyway, so can > simply treat -EINVAL from trying it as meaning "no kernel support, > revert to the older thing". > > This does mean you have to update all of userspace to do the new call > instead of the old one, but that's fine, there's only a handful of > clients for this API. > You'll also need to handles cases like render nodes where we split resources for multi-seat on one gpu. Dave.
[PATCH, RFC] displaymodes in devicetree
On Wed, Jun 27, 2012 at 06:16:12AM -1000, Mitch Bradley wrote: > On 6/27/2012 2:43 AM, Sascha Hauer wrote: > >Hi All, > > > >I'd like to have a possibility to describe fixed display modes in the > >devicetree. This topic has been discussed before here: > > > >https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-February/080683.html > > > >The result at that time was that EDID data should be considered to use > >as this is a format that already exists. I want to come back to this > >topic since: > > > >- EDID data is a binary format and as such quite inconvenient to handle. > > There exist several tools to parse EDID data, but I'm not aware of any > > (open source) tool which can generate EDID data. > >- EDID blobs are hard to modify and hard to review in patches. > >- EDID is designed to describe multiple modes, but fixed displays > > usually only support a single fixed mode. > > > >There are several ways of describing the mode, for this patch I chose to > >use the format (and naming) used by the Linux Framebuffer Layer as this > >is the only description which does not allow for inconsistent modes. I > >added the most common flags like [v|h]sync_active_high. Others can be > >added, but these flags are pretty much agreed upon and won't be > >superseeded with other flags. The mode from the devicetree can be > >converted to the most common modes used in Linux, struct fb_videomode > >and struct drm_display_mode. > > > >Comments welcome > > > I like the general approach and the set of names. The separators > inside the names should be hyphen (-) not underscore (_), following > the usual device tree convention. The rationale for that convention > is to follow natural-language usage, not the identifier constraints > of programming languages based on algebraic expressions. Good to hear that this is the convention for devicetree, I like hyphens better aswell. Will change. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Tegra DRM device tree bindings
Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
> On Wed, Jun 27, 2012 at 05:29:14PM +0300, Hiroshi Doyu wrote:
> > On Wed, 27 Jun 2012 16:08:10 +0200
> > Thierry Reding wrote:
> >
> > > * PGP Signed by an unknown key
> > >
> > > On Wed, Jun 27, 2012 at 03:59:07PM +0300, Hiroshi Doyu wrote:
> > > > On Wed, 27 Jun 2012 07:14:18 +0200
> > > > Thierry Reding wrote:
> > > >
> > > > > > Old Signed by an unknown key
> > > > >
> > > > > On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > > > > > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > > > > > >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > > > > > > On Tue, 26 Jun 2012 12:55:13 +0200
> > > > > > > Thierry Reding wrote:
> > > > > > >> ...
> > > > > > I'm not sure I understand how information about the carveout
> > > > > > would be
> > > > > > obtained from the IOMMU API, though.
> > > > > > >>>
> > > > > > >>> I think that can be similar with current gart implementation.
> > > > > > >>> Define carveout as:
> > > > > > >>>
> > > > > > >>> carveout {
> > > > > > >>> compatible = "nvidia,tegra20-carveout";
> > > > > > >>> size = <0x1000>;
> > > > > > >>> };
> > > > > > >>>
> > > > > > >>> Then create a file such like "tegra-carveout.c" to get these
> > > > > > >>> definitions and
> > > > > > >> register itself as platform device's iommu instance.
> > > > > > >>
> > > > > > >> The carveout isn't a HW object, so it doesn't seem appropriate
> > > > > > >> to define a DT
> > > > > > >> node to represent it.
> > > > > > >
> > > > > > > Yes. But I think it's better to export the size of carveout as a
> > > > > > > configurable item.
> > > > > > > So we need to define this somewhere. How about define carveout as
> > > > > > > a property of gart?
> > > > > >
> > > > > > There already exists a way of preventing Linux from using certain
> > > > > > chunks
> > > > > > of memory; the /memreserve/ syntax. From a brief look at the dtc
> > > > > > source,
> > > > > > it looks like /memreserve/ entries can have labels, which implies
> > > > > > that a
> > > > > > property in the GART node could refer to the /memreserve/ entry by
> > > > > > phandle in order to know what memory regions to use.
> > > > >
> > > > > Wasn't the whole point of using a carveout supposed to be a
> > > > > replacement
> > > > > for the GART?
> > > >
> > > > Mostly agree. IIUC, we use both carveout/gart allocated buffers in
> > > > android/tegra2.
> > > >
> > > > >As such I'd think the carveout should rather be a property
> > > > > of the host1x device.
> > > >
> > > > Rather than introducing a new property, how about using
> > > > "coherent_pool=??M" in the kernel command line if necessary? I think
> > > > that this carveout size depends on the system usage/load.
> > >
> > > I was hoping that we could get away with using the CMA and perhaps
> > > initialize it based on device tree content. I agree that the carveout
> > > size depends on the use-case, but I still think it makes sense to
> > > specify it on a per-board basis.
> >
> > DRM driver doesn't know if it uses CMA or not, because DRM only uses
> > DMA API.
>
> So how is the DRM supposed to allocate buffers? Does it call the
> dma_alloc_from_contiguous() function to do that? I can see how it is
> used by arm_dma_ops but how does it end up in the driver?
>
As I said before the DMA API is not a good fit for graphics drivers.
Most of the DMA buffers used by graphics cores are long lived and big,
so we need a special pool to alloc from to avoid eating all contiguous
address space, as DMA API does not provide shrinker callbacks for
clients using large amount of memory.
> > I think that "coherent_pool" can be used only when the amount of
> > contiguous memory is short in your system. Otherwise even unnecessary.
> >
> > Could you explain a bit more why you want carveout size on per-board basis?
>
> In the ideal case I would want to not have a carveout size at all.
> However there may be situations where you need to make sure some driver
> can allocate a given amount of memory. Having to specify this using a
> kernel command-line parameter is cumbersome because it may require
> changes to the bootloader or whatever. So if you know that a particular
> board always needs 128 MiB of carveout, then it makes sense to specify
> it on a per-board basis.
If we go with CMA, this is a non-issue, as CMA allows to use the contig
area for normal allocations and only purges them if it really needs the
space for contig allocs.
>
> Thierry
[PATCH] drm/radeon: disable any GPU activity after unrecovered lockup
On Mit, 2012-06-27 at 10:49 -0400, Jerome Glisse wrote:
> On Wed, Jun 27, 2012 at 5:19 AM, Michel D?nzer wrote:
> > On Die, 2012-06-26 at 17:04 -0400, j.glisse at gmail.com wrote:
> >> From: Jerome Glisse
> >>
> >> After unrecovered GPU lockup avoid any GPU activities to avoid
> >> things like kernel segfault and alike to happen in any of the
> >> path that assume hw is working.
> >
> > Has the patch been tested and confirmed to actually fix such a problem?
>
> Yes it has been tested i dont send untested patch to ml.
I didn't expect (or mean to suggest) otherwise. I think I misread the
related IRC conversation from last night: I thought you basically
whipped up this patch in response to a report of such problems. But on
re-reading now, I guess you wrote this patch a while ago and are just
sending it now in response to the report on IRC.
> >> r = radeon_asic_reset(rdev);
> >> if (!r) {
> >> dev_info(rdev->dev, "GPU reset succeed\n");
> >> radeon_resume(rdev);
> >> - radeon_restore_bios_scratch_regs(rdev);
> >> - drm_helper_resume_force_mode(rdev->ddev);
> >> - ttm_bo_unlock_delayed_workqueue(&rdev->mman.bdev, resched);
> >> }
> >>
> >> + /* no matter what restore video mode */
> >> + radeon_restore_bios_scratch_regs(rdev);
> >> + drm_helper_resume_force_mode(rdev->ddev);
> >> + ttm_bo_unlock_delayed_workqueue(&rdev->mman.bdev, resched);
> >
> > Maybe this should be in a separate patch.
>
> Idea is to send this patch to stable thus having one patch that have it all.
That doesn't make sense. Either the changes belong into a single patch
(but then the commit log should describe all of them) or not. They can
be sent to stable[0] either way.
[0] Actually, patches with Cc: stable are picked up automagically once
they hit mainline, there's no point in sending them there directly.
> >> @@ -399,6 +418,14 @@ static int radeon_bo_move(struct ttm_buffer_object
> >> *bo,
> >> radeon_move_null(bo, new_mem);
> >> return 0;
> >> }
> >> + if (!rdev->accel_working) {
> >> + /* when accel is not working GPU is in broken state just
> >> + * do nothing for any ttm operation to avoid making the
> >> + * situation worst than it's
> >
> > 'worse than it is', same in the following two hunks.
Are you gonna fix these typos?
--
Earthling Michel D?nzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
Tegra DRM device tree bindings
On Wed, 27 Jun 2012 16:08:10 +0200
Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Wed, Jun 27, 2012 at 03:59:07PM +0300, Hiroshi Doyu wrote:
> > On Wed, 27 Jun 2012 07:14:18 +0200
> > Thierry Reding wrote:
> >
> > > > Old Signed by an unknown key
> > >
> > > On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > > > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > > > >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > > > > On Tue, 26 Jun 2012 12:55:13 +0200
> > > > > Thierry Reding wrote:
> > > > >> ...
> > > > I'm not sure I understand how information about the carveout would
> > > > be
> > > > obtained from the IOMMU API, though.
> > > > >>>
> > > > >>> I think that can be similar with current gart implementation.
> > > > >>> Define carveout as:
> > > > >>>
> > > > >>> carveout {
> > > > >>> compatible = "nvidia,tegra20-carveout";
> > > > >>> size = <0x1000>;
> > > > >>> };
> > > > >>>
> > > > >>> Then create a file such like "tegra-carveout.c" to get these
> > > > >>> definitions and
> > > > >> register itself as platform device's iommu instance.
> > > > >>
> > > > >> The carveout isn't a HW object, so it doesn't seem appropriate to
> > > > >> define a DT
> > > > >> node to represent it.
> > > > >
> > > > > Yes. But I think it's better to export the size of carveout as a
> > > > > configurable item.
> > > > > So we need to define this somewhere. How about define carveout as a
> > > > > property of gart?
> > > >
> > > > There already exists a way of preventing Linux from using certain chunks
> > > > of memory; the /memreserve/ syntax. From a brief look at the dtc source,
> > > > it looks like /memreserve/ entries can have labels, which implies that a
> > > > property in the GART node could refer to the /memreserve/ entry by
> > > > phandle in order to know what memory regions to use.
> > >
> > > Wasn't the whole point of using a carveout supposed to be a replacement
> > > for the GART?
> >
> > Mostly agree. IIUC, we use both carveout/gart allocated buffers in
> > android/tegra2.
> >
> > >As such I'd think the carveout should rather be a property
> > > of the host1x device.
> >
> > Rather than introducing a new property, how about using
> > "coherent_pool=??M" in the kernel command line if necessary? I think
> > that this carveout size depends on the system usage/load.
>
> I was hoping that we could get away with using the CMA and perhaps
> initialize it based on device tree content. I agree that the carveout
> size depends on the use-case, but I still think it makes sense to
> specify it on a per-board basis.
DRM driver doesn't know if it uses CMA or not, because DRM only uses
DMA API. I think that "coherent_pool" can be used only when the amount
of contiguous memory is short in your system. Otherwise even unnecessary.
Could you explain a bit more why you want carveout size on per-board basis?
[PATCH] i915: initialize CADL in opregion
On Wednesday 27 June 2012 17:03:02 Daniel Vetter wrote: > On Tue, Jun 26, 2012 at 11:07:55PM +0200, Daniel Vetter wrote: > > On Tue, Jun 26, 2012 at 02:04:00PM -0700, Jesse Barnes wrote: > > > On Tue, 26 Jun 2012 00:36:24 +0200 > > > > > > Lekensteyn wrote: > > > > This is rather a hack to fix brightness hotkeys on a Clevo laptop. > > > > CADL is not used anywhere in the driver code at the moment, but it > > > > could be used in BIOS as is the case with the Clevo laptop. > > > > > > > > The Clevo B7130 requires the CADL field to contain at least the ID of > > > > the LCD device. If this field is empty, the ACPI methods that are > > > > called > > > > on pressing brightness / display switching hotkeys will not trigger a > > > > notification. As a result, it appears as no hotkey has been pressed. > > > > > > Not ideal, but definitely better than nothing. > > > > > > Acked-by: Jesse Barnes > > > > Queued for -next, thanks for the patch. > > Unfortunately this results in a neat black screen on my ivb zenbook. Until > I've figured out what exactly's going on, I have to drop this from -next > again. > -Daniel Can you share your acpidump on https://bugs.freedesktop.org/show_bug.cgi?id=45452 ? TIA Peter
[PATCH 10/10] drm/exynos: consider memory releasing to exported gem buffer into dmabuf
exported gem buffer into dmabuf should be released when a gem relese is
requested by user. with dma_buf_put() call, if file->f_count is 0 then
a release callback of exynos gem module(exporter) will be called to release
its own gem buffer.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |1 +
drivers/gpu/drm/exynos/exynos_drm_gem.c | 16
drivers/gpu/drm/exynos/exynos_drm_gem.h |4
3 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index d6de2e0..1501dd2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -258,6 +258,7 @@ static struct drm_driver exynos_drm_driver = {
.gem_init_object= exynos_drm_gem_init_object,
.gem_free_object= exynos_drm_gem_free_object,
.gem_vm_ops = &exynos_drm_gem_vm_ops,
+ .gem_close_object = exynos_drm_gem_close_object,
.dumb_create= exynos_drm_gem_dumb_create,
.dumb_map_offset= exynos_drm_gem_dumb_map_offset,
.dumb_destroy = exynos_drm_gem_dumb_destroy,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 411d82b..5ca8641 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -27,6 +27,7 @@
#include "drm.h"
#include
+#include
#include
#include "exynos_drm_drv.h"
@@ -749,6 +750,21 @@ int exynos_drm_gem_dumb_destroy(struct drm_file *file_priv,
return 0;
}
+void exynos_drm_gem_close_object(struct drm_gem_object *obj,
+ struct drm_file *file)
+{
+ DRM_DEBUG_KMS("%s\n", __FILE__);
+
+ /*
+* exported dmabuf should be released when a gem is released by user.
+* with dma_buf_put() call, if file->f_count is 0 then a release
+* callback of gem module(exporter) will be called to release
+* its own gem buffer.
+*/
+ if (obj->export_dma_buf)
+ dma_buf_put(obj->export_dma_buf);
+}
+
int exynos_drm_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
struct drm_gem_object *obj = vma->vm_private_data;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 14d038b..4f1ba1a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -162,4 +162,8 @@ int exynos_drm_gem_fault(struct vm_area_struct *vma, struct
vm_fault *vmf);
/* set vm_flags and we can change the vm attribute to other one at here. */
int exynos_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
+/* do extra release exynos gem module needs when gem close is called. */
+void exynos_drm_gem_close_object(struct drm_gem_object *obj,
+ struct drm_file *file);
+
#endif
--
1.7.4.1
[PATCH 09/10] drm/exynos: removed unnecessary variable
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_core.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index eaf630d..84dd099 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -33,7 +33,6 @@
#include "exynos_drm_fbdev.h"
static LIST_HEAD(exynos_drm_subdrv_list);
-static struct drm_device *drm_dev;
static int exynos_drm_subdrv_probe(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
@@ -120,8 +119,6 @@ int exynos_drm_device_register(struct drm_device *dev)
if (!dev)
return -EINVAL;
- drm_dev = dev;
-
list_for_each_entry_safe(subdrv, n, &exynos_drm_subdrv_list, list) {
subdrv->drm_dev = dev;
err = exynos_drm_subdrv_probe(dev, subdrv);
@@ -149,8 +146,6 @@ int exynos_drm_device_unregister(struct drm_device *dev)
list_for_each_entry(subdrv, &exynos_drm_subdrv_list, list)
exynos_drm_subdrv_remove(dev, subdrv);
- drm_dev = NULL;
-
return 0;
}
EXPORT_SYMBOL_GPL(exynos_drm_device_unregister);
--
1.7.4.1
[PATCH 08/10] drm/exynos: do not release memory region from exporter.
the region should be released by exporter once dmabuf's refcount becomes 0. Signed-off-by: Inki Dae Signed-off-by: Seung-Woo Kim Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_drm_gem.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c index c29c02d..411d82b 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c @@ -283,11 +283,21 @@ void exynos_drm_gem_destroy(struct exynos_drm_gem_obj *exynos_gem_obj) if (!buf->pages) return; + /* +* do not release memory region from exporter. +* +* the region will be released by exporter +* once dmabuf's refcount becomes 0. +*/ + if (obj->import_attach) + goto out; + if (exynos_gem_obj->flags & EXYNOS_BO_NONCONTIG) exynos_drm_gem_put_pages(obj); else exynos_drm_free_buf(obj->dev, exynos_gem_obj->flags, buf); +out: exynos_drm_fini_buf(obj->dev, buf); exynos_gem_obj->buffer = NULL; -- 1.7.4.1
[PATCH 07/10] drm/exynos: set buffer type from exporter.
when fd is imported to gem, whether the memory type from exporter
is contigous or not should be set to gem flag so that drm-based
driver can aware of the memory type.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 27 ---
1 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 2749092..38544c1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -25,6 +25,7 @@
#include "drmP.h"
#include "drm.h"
+#include "exynos_drm.h"
#include "exynos_drm_drv.h"
#include "exynos_drm_gem.h"
@@ -186,7 +187,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct
drm_device *drm_dev,
struct exynos_drm_gem_obj *exynos_gem_obj;
struct exynos_drm_gem_buf *buffer;
struct page *page;
- int ret, i = 0;
+ int ret;
DRM_DEBUG_PRIME("%s\n", __FILE__);
@@ -236,13 +237,25 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct
drm_device *drm_dev,
}
sgl = sgt->sgl;
- buffer->dma_addr = sg_dma_address(sgl);
- while (i < sgt->nents) {
- buffer->pages[i] = sg_page(sgl);
- buffer->size += sg_dma_len(sgl);
- sgl = sg_next(sgl);
- i++;
+ if (sgt->nents == 1) {
+ buffer->dma_addr = sg_dma_address(sgt->sgl);
+ buffer->size = sg_dma_len(sgt->sgl);
+
+ /* always physically continuous memory if sgt->nents is 1. */
+ exynos_gem_obj->flags |= EXYNOS_BO_CONTIG;
+ } else {
+ unsigned int i = 0;
+
+ buffer->dma_addr = sg_dma_address(sgl);
+ while (i < sgt->nents) {
+ buffer->pages[i] = sg_page(sgl);
+ buffer->size += sg_dma_len(sgl);
+ sgl = sg_next(sgl);
+ i++;
+ }
+
+ exynos_gem_obj->flags |= EXYNOS_BO_NONCONTIG;
}
exynos_gem_obj->buffer = buffer;
--
1.7.4.1
[PATCH 06/10] drm/exynos: use alloc_page() to allocate pages.
shmem_read_mapping_page_gfp() first tries to allocate pages from page cache
so if pages are allocated from page cache then these pages could have
valid cache line. after that cpu may read garbage data from cache
once gpu operation is completed with allocated pages. so with this patch,
Non-contiguous memory allocation request allocates pages from highmem
through alloc_page() with GFP_HIGHUSER_MOVABLE.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 14 +++---
1 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 5c8b683..c29c02d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -99,25 +99,17 @@ out:
struct page **exynos_gem_get_pages(struct drm_gem_object *obj,
gfp_t gfpmask)
{
- struct inode *inode;
- struct address_space *mapping;
struct page *p, **pages;
int i, npages;
- /* This is the shared memory object that backs the GEM resource */
- inode = obj->filp->f_path.dentry->d_inode;
- mapping = inode->i_mapping;
-
npages = obj->size >> PAGE_SHIFT;
pages = drm_malloc_ab(npages, sizeof(struct page *));
if (pages == NULL)
return ERR_PTR(-ENOMEM);
- gfpmask |= mapping_gfp_mask(mapping);
-
for (i = 0; i < npages; i++) {
- p = shmem_read_mapping_page_gfp(mapping, i, gfpmask);
+ p = alloc_page(gfpmask);
if (IS_ERR(p))
goto fail;
pages[i] = p;
@@ -127,7 +119,7 @@ struct page **exynos_gem_get_pages(struct drm_gem_object
*obj,
fail:
while (i--)
- page_cache_release(pages[i]);
+ __free_page(pages[i]);
drm_free_large(pages);
return ERR_PTR(PTR_ERR(p));
@@ -189,7 +181,7 @@ static int exynos_drm_gem_get_pages(struct drm_gem_object
*obj)
return -EINVAL;
}
- pages = exynos_gem_get_pages(obj, GFP_KERNEL);
+ pages = exynos_gem_get_pages(obj, GFP_HIGHUSER_MOVABLE);
if (IS_ERR(pages)) {
DRM_ERROR("failed to get pages.\n");
return PTR_ERR(pages);
--
1.7.4.1
[PATCH 05/10] drm/exynos: fixed build warning.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 1d7d030..bb1550c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -598,7 +598,7 @@ int vidi_connection_ioctl(struct drm_device *drm_dev, void
*data,
DRM_DEBUG_KMS("edid data is null.\n");
return -EINVAL;
}
- raw_edid = (struct edid *)vidi->edid;
+ raw_edid = (struct edid *)(uint32_t)vidi->edid;
edid_len = (1 + raw_edid->extensions) * EDID_LENGTH;
ctx->raw_edid = kzalloc(edid_len, GFP_KERNEL);
if (!ctx->raw_edid) {
--
1.7.4.1
[PATCH 04/10] drm/exynos: fixed edid data setting at vidi connection request
edid data from user should be allocated and copied into vidi context and also
freed with disconnection.
Signed-off-by: Inki Dae
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 38 -
1 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index dbbf2fc..1d7d030 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -557,6 +557,8 @@ int vidi_connection_ioctl(struct drm_device *drm_dev, void
*data,
struct exynos_drm_manager *manager;
struct exynos_drm_display_ops *display_ops;
struct drm_exynos_vidi_connection *vidi = data;
+ struct edid *raw_edid;
+ int edid_len;
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -565,11 +567,6 @@ int vidi_connection_ioctl(struct drm_device *drm_dev, void
*data,
return -EINVAL;
}
- if (!vidi->edid) {
- DRM_DEBUG_KMS("edid data is null.\n");
- return -EINVAL;
- }
-
if (vidi->connection > 1) {
DRM_DEBUG_KMS("connection should be 0 or 1.\n");
return -EINVAL;
@@ -596,8 +593,30 @@ int vidi_connection_ioctl(struct drm_device *drm_dev, void
*data,
return -EINVAL;
}
- if (vidi->connection)
- ctx->raw_edid = (struct edid *)vidi->edid;
+ if (vidi->connection) {
+ if (!vidi->edid) {
+ DRM_DEBUG_KMS("edid data is null.\n");
+ return -EINVAL;
+ }
+ raw_edid = (struct edid *)vidi->edid;
+ edid_len = (1 + raw_edid->extensions) * EDID_LENGTH;
+ ctx->raw_edid = kzalloc(edid_len, GFP_KERNEL);
+ if (!ctx->raw_edid) {
+ DRM_DEBUG_KMS("failed to allocate raw_edid.\n");
+ return -ENOMEM;
+ }
+ memcpy(ctx->raw_edid, raw_edid, edid_len);
+ } else {
+ /*
+* with connection = 0, free raw_edid
+* only if raw edid data isn't same as fake data.
+*/
+ if (ctx->raw_edid && ctx->raw_edid !=
+ (struct edid *)fake_edid_info) {
+ kfree(ctx->raw_edid);
+ ctx->raw_edid = NULL;
+ }
+ }
ctx->connected = vidi->connection;
drm_helper_hpd_irq_event(ctx->subdrv.drm_dev);
@@ -649,6 +668,11 @@ static int __devexit vidi_remove(struct platform_device
*pdev)
exynos_drm_subdrv_unregister(&ctx->subdrv);
+ if (ctx->raw_edid != (struct edid *)fake_edid_info) {
+ kfree(ctx->raw_edid);
+ ctx->raw_edid = NULL;
+ }
+
kfree(ctx);
return 0;
--
1.7.4.1
[PATCH 03/10] drm/exynos: check if raw edid data is fake or not for test
if raw edid data isn't same as fake data then it can't be tested.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 88dae6b..dbbf2fc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -533,6 +533,12 @@ static int vidi_store_connection(struct device *dev,
if (!ctx->raw_edid)
ctx->raw_edid = (struct edid *)fake_edid_info;
+ /* if raw_edid isn't same as fake data then it can't be tested. */
+ if (ctx->raw_edid != (struct edid *)fake_edid_info) {
+ DRM_DEBUG_KMS("edid data is not fake data.\n");
+ return -EINVAL;
+ }
+
DRM_DEBUG_KMS("requested connection.\n");
drm_helper_hpd_irq_event(ctx->subdrv.drm_dev);
--
1.7.4.1
[PATCH 02/10] drm/exynos: set edid fake data only for test.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 5640d57..88dae6b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -529,6 +529,10 @@ static int vidi_store_connection(struct device *dev,
if (ctx->connected > 1)
return -EINVAL;
+ /* use fake edid data for test. */
+ if (!ctx->raw_edid)
+ ctx->raw_edid = (struct edid *)fake_edid_info;
+
DRM_DEBUG_KMS("requested connection.\n");
drm_helper_hpd_irq_event(ctx->subdrv.drm_dev);
@@ -612,9 +616,6 @@ static int __devinit vidi_probe(struct platform_device
*pdev)
INIT_WORK(&ctx->work, vidi_fake_vblank_handler);
- /* for test */
- ctx->raw_edid = (struct edid *)fake_edid_info;
-
subdrv = &ctx->subdrv;
subdrv->dev = dev;
subdrv->manager = &vidi_manager;
--
1.7.4.1
[PATCH 01/10] drm/exynos: removed unnecessary declaration.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 7b9c153..5640d57 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -85,8 +85,6 @@ static const char fake_edid_info[] = {
0x00, 0x00, 0x00, 0x06
};
-static void vidi_fake_vblank_handler(struct work_struct *work);
-
static bool vidi_display_is_connected(struct device *dev)
{
struct vidi_context *ctx = get_vidi_context(dev);
--
1.7.4.1
[PATCH 00/10] drm/exynos: fix vidi driver and gem module
these patch sets fix some issues to gem and vidi driver and include the following: - fixes cache issue according to gpu operation . shmem_read_mapping_page_gfp function first tries to allocate pages from page cache and if the allocation is done from page cache the the pages could have valid cache line so cpu may read garbage data from cache after gpu operation is completed. - use edid data from user propely and add some exception codes - fixes releasing issue to exported gem buffer into dmabuf - and code clean Thanks. Inki Dae (10): drm/exynos: removed unnecessary declaration. drm/exynos: set edid fake data only for test. drm/exynos: check if raw edid data is fake or not for test drm/exynos: fixed edid data setting at vidi connection request drm/exynos: fixed build warning. drm/exynos: use alloc_page() to allocate pages. drm/exynos: set buffer type from exporter. drm/exynos: do not release memory region from exporter. drm/exynos: removed unnecessary variable drm/exynos: consider memory releasing to exported gem buffer into dmabuf drivers/gpu/drm/exynos/exynos_drm_core.c |5 --- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 27 ++ drivers/gpu/drm/exynos/exynos_drm_drv.c|1 + drivers/gpu/drm/exynos/exynos_drm_gem.c| 40 +++-- drivers/gpu/drm/exynos/exynos_drm_gem.h|4 ++ drivers/gpu/drm/exynos/exynos_drm_vidi.c | 53 +-- 6 files changed, 95 insertions(+), 35 deletions(-) -- 1.7.4.1
[PATCH] i915: initialize CADL in opregion
On Tue, Jun 26, 2012 at 11:07:55PM +0200, Daniel Vetter wrote: > On Tue, Jun 26, 2012 at 02:04:00PM -0700, Jesse Barnes wrote: > > On Tue, 26 Jun 2012 00:36:24 +0200 > > Lekensteyn wrote: > > > > > This is rather a hack to fix brightness hotkeys on a Clevo laptop. CADL > > > is not > > > used anywhere in the driver code at the moment, but it could be used in > > > BIOS as > > > is the case with the Clevo laptop. > > > > > > The Clevo B7130 requires the CADL field to contain at least the ID of > > > the LCD device. If this field is empty, the ACPI methods that are called > > > on pressing brightness / display switching hotkeys will not trigger a > > > notification. As a result, it appears as no hotkey has been pressed. > > > > Not ideal, but definitely better than nothing. > > > > Acked-by: Jesse Barnes > Queued for -next, thanks for the patch. Unfortunately this results in a neat black screen on my ivb zenbook. Until I've figured out what exactly's going on, I have to drop this from -next again. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
Tegra DRM device tree bindings
On Wed, Jun 27, 2012 at 05:29:14PM +0300, Hiroshi Doyu wrote:
> On Wed, 27 Jun 2012 16:08:10 +0200
> Thierry Reding wrote:
>
> > * PGP Signed by an unknown key
> >
> > On Wed, Jun 27, 2012 at 03:59:07PM +0300, Hiroshi Doyu wrote:
> > > On Wed, 27 Jun 2012 07:14:18 +0200
> > > Thierry Reding wrote:
> > >
> > > > > Old Signed by an unknown key
> > > >
> > > > On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > > > > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > > > > >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > > > > >>>>> On Tue, 26 Jun 2012 12:55:13 +0200
> > > > > >>>>> Thierry Reding wrote:
> > > > > >> ...
> > > > > >>>> I'm not sure I understand how information about the carveout
> > > > > >>>> would be
> > > > > >>>> obtained from the IOMMU API, though.
> > > > > >>>
> > > > > >>> I think that can be similar with current gart implementation.
> > > > > >>> Define carveout as:
> > > > > >>>
> > > > > >>> carveout {
> > > > > >>> compatible = "nvidia,tegra20-carveout";
> > > > > >>> size = <0x1000>;
> > > > > >>> };
> > > > > >>>
> > > > > >>> Then create a file such like "tegra-carveout.c" to get these
> > > > > >>> definitions and
> > > > > >> register itself as platform device's iommu instance.
> > > > > >>
> > > > > >> The carveout isn't a HW object, so it doesn't seem appropriate to
> > > > > >> define a DT
> > > > > >> node to represent it.
> > > > > >
> > > > > > Yes. But I think it's better to export the size of carveout as a
> > > > > > configurable item.
> > > > > > So we need to define this somewhere. How about define carveout as a
> > > > > > property of gart?
> > > > >
> > > > > There already exists a way of preventing Linux from using certain
> > > > > chunks
> > > > > of memory; the /memreserve/ syntax. From a brief look at the dtc
> > > > > source,
> > > > > it looks like /memreserve/ entries can have labels, which implies
> > > > > that a
> > > > > property in the GART node could refer to the /memreserve/ entry by
> > > > > phandle in order to know what memory regions to use.
> > > >
> > > > Wasn't the whole point of using a carveout supposed to be a replacement
> > > > for the GART?
> > >
> > > Mostly agree. IIUC, we use both carveout/gart allocated buffers in
> > > android/tegra2.
> > >
> > > >As such I'd think the carveout should rather be a property
> > > > of the host1x device.
> > >
> > > Rather than introducing a new property, how about using
> > > "coherent_pool=??M" in the kernel command line if necessary? I think
> > > that this carveout size depends on the system usage/load.
> >
> > I was hoping that we could get away with using the CMA and perhaps
> > initialize it based on device tree content. I agree that the carveout
> > size depends on the use-case, but I still think it makes sense to
> > specify it on a per-board basis.
>
> DRM driver doesn't know if it uses CMA or not, because DRM only uses
> DMA API.
So how is the DRM supposed to allocate buffers? Does it call the
dma_alloc_from_contiguous() function to do that? I can see how it is
used by arm_dma_ops but how does it end up in the driver?
> I think that "coherent_pool" can be used only when the amount of
> contiguous memory is short in your system. Otherwise even unnecessary.
>
> Could you explain a bit more why you want carveout size on per-board basis?
In the ideal case I would want to not have a carveout size at all.
However there may be situations where you need to make sure some driver
can allocate a given amount of memory. Having to specify this using a
kernel command-line parameter is cumbersome because it may require
changes to the bootloader or whatever. So if you know that a particular
board always needs 128 MiB of carveout, then it makes sense to specify
it on a per-board basis.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120627/b2ef438e/attachment.pgp>
Tegra DRM device tree bindings
On Wed, Jun 27, 2012 at 03:59:07PM +0300, Hiroshi Doyu wrote:
> On Wed, 27 Jun 2012 07:14:18 +0200
> Thierry Reding wrote:
>
> > * PGP Signed by an unknown key
> >
> > On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > > >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > > >>>>> On Tue, 26 Jun 2012 12:55:13 +0200
> > > >>>>> Thierry Reding wrote:
> > > >> ...
> > > >>>> I'm not sure I understand how information about the carveout would be
> > > >>>> obtained from the IOMMU API, though.
> > > >>>
> > > >>> I think that can be similar with current gart implementation. Define
> > > >>> carveout as:
> > > >>>
> > > >>> carveout {
> > > >>> compatible = "nvidia,tegra20-carveout";
> > > >>> size = <0x1000>;
> > > >>> };
> > > >>>
> > > >>> Then create a file such like "tegra-carveout.c" to get these
> > > >>> definitions and
> > > >> register itself as platform device's iommu instance.
> > > >>
> > > >> The carveout isn't a HW object, so it doesn't seem appropriate to
> > > >> define a DT
> > > >> node to represent it.
> > > >
> > > > Yes. But I think it's better to export the size of carveout as a
> > > > configurable item.
> > > > So we need to define this somewhere. How about define carveout as a
> > > > property of gart?
> > >
> > > There already exists a way of preventing Linux from using certain chunks
> > > of memory; the /memreserve/ syntax. From a brief look at the dtc source,
> > > it looks like /memreserve/ entries can have labels, which implies that a
> > > property in the GART node could refer to the /memreserve/ entry by
> > > phandle in order to know what memory regions to use.
> >
> > Wasn't the whole point of using a carveout supposed to be a replacement
> > for the GART?
>
> Mostly agree. IIUC, we use both carveout/gart allocated buffers in
> android/tegra2.
>
> >As such I'd think the carveout should rather be a property
> > of the host1x device.
>
> Rather than introducing a new property, how about using
> "coherent_pool=??M" in the kernel command line if necessary? I think
> that this carveout size depends on the system usage/load.
I was hoping that we could get away with using the CMA and perhaps
initialize it based on device tree content. I agree that the carveout
size depends on the use-case, but I still think it makes sense to
specify it on a per-board basis.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120627/ea14870b/attachment.pgp>
Tegra DRM device tree bindings
On Wed, 27 Jun 2012 07:14:18 +0200
Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > > On Tue, 26 Jun 2012 12:55:13 +0200
> > > Thierry Reding wrote:
> > >> ...
> > I'm not sure I understand how information about the carveout would be
> > obtained from the IOMMU API, though.
> > >>>
> > >>> I think that can be similar with current gart implementation. Define
> > >>> carveout as:
> > >>>
> > >>> carveout {
> > >>> compatible = "nvidia,tegra20-carveout";
> > >>> size = <0x1000>;
> > >>> };
> > >>>
> > >>> Then create a file such like "tegra-carveout.c" to get these
> > >>> definitions and
> > >> register itself as platform device's iommu instance.
> > >>
> > >> The carveout isn't a HW object, so it doesn't seem appropriate to define
> > >> a DT
> > >> node to represent it.
> > >
> > > Yes. But I think it's better to export the size of carveout as a
> > > configurable item.
> > > So we need to define this somewhere. How about define carveout as a
> > > property of gart?
> >
> > There already exists a way of preventing Linux from using certain chunks
> > of memory; the /memreserve/ syntax. From a brief look at the dtc source,
> > it looks like /memreserve/ entries can have labels, which implies that a
> > property in the GART node could refer to the /memreserve/ entry by
> > phandle in order to know what memory regions to use.
>
> Wasn't the whole point of using a carveout supposed to be a replacement
> for the GART?
Mostly agree. IIUC, we use both carveout/gart allocated buffers in
android/tegra2.
>As such I'd think the carveout should rather be a property
> of the host1x device.
Rather than introducing a new property, how about using
"coherent_pool=??M" in the kernel command line if necessary? I think
that this carveout size depends on the system usage/load.
> AIUI what we want to do is have a large contiguous region of memory that
> a central component (host1x) manages as a pool from which clients (DRM,
> V4L, ...) can allocate buffers as needed. Since all of this memory will
> be contiguous anyway there isn't much use for the GART anymore.
Right.
I'd think that the amount of contiguous resion might depend on the
system usage/load.
Tegra DRM device tree bindings
On Wed, 27 Jun 2012 04:48:18 +0200
Stephen Warren wrote:
> On 06/26/2012 08:32 PM, Mark Zhang wrote:
> >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > On Tue, 26 Jun 2012 12:55:13 +0200
> > Thierry Reding wrote:
> >> ...
> I'm not sure I understand how information about the carveout would be
> obtained from the IOMMU API, though.
> >>>
> >>> I think that can be similar with current gart implementation. Define
> >>> carveout as:
> >>>
> >>> carveout {
> >>> compatible = "nvidia,tegra20-carveout";
> >>> size = <0x1000>;
> >>> };
> >>>
> >>> Then create a file such like "tegra-carveout.c" to get these definitions
> >>> and
> >> register itself as platform device's iommu instance.
> >>
> >> The carveout isn't a HW object, so it doesn't seem appropriate to define a
> >> DT
> >> node to represent it.
> >
> > Yes. But I think it's better to export the size of carveout as a
> > configurable item.
> > So we need to define this somewhere. How about define carveout as a
> > property of gart?
>
> There already exists a way of preventing Linux from using certain chunks
> of memory; the /memreserve/ syntax. From a brief look at the dtc source,
> it looks like /memreserve/ entries can have labels, which implies that a
> property in the GART node could refer to the /memreserve/ entry by
> phandle in order to know what memory regions to use.
I think that we don't need the starting address for carveout but we
need its size. carveout memory is just anonymous physically
continguous buffer.
[PATCH v4] DRM: add drm gem CMA helper
Hi Sascha,
Thanks for the patch.
Just one small comment below.
On Wednesday 27 June 2012 15:30:18 Sascha Hauer wrote:
[snip]
> +/*
> + * drm_gem_cma_dumb_create - (struct drm_driver)->dumb_create callback
> + * function
> + *
> + * This aligns the pitch and size arguments to the minimum required. wrap
> + * this into your own function if you need bigger alignment.
> + */
> +int drm_gem_cma_dumb_create(struct drm_file *file_priv,
> + struct drm_device *dev, struct drm_mode_create_dumb *args)
> +{
> + struct drm_gem_cma_object *cma_obj;
> + int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
> +
> + if (args->pitch < min_pitch)
> + args->pitch = min_pitch;
args->pitch is unsigned, so I would make min_pitch an unsigned int.
> +
> + if (args->size < args->pitch * args->height)
> + args->size = args->pitch * args->height;
> +
> + cma_obj = drm_gem_cma_create_with_handle(file_priv, dev,
> + args->size, &args->handle);
> + if (IS_ERR(cma_obj))
> + return PTR_ERR(cma_obj);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_cma_dumb_create);
--
Regards,
Laurent Pinchart
Tegra DRM device tree bindings
On Wed, 27 Jun 2012 04:32:07 +0200
Mark Zhang wrote:
> > On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > >>> On Tue, 26 Jun 2012 12:55:13 +0200
> > >>> Thierry Reding wrote:
> > ...
> > >> I'm not sure I understand how information about the carveout would be
> > >> obtained from the IOMMU API, though.
> > >
> > > I think that can be similar with current gart implementation. Define
> > > carveout as:
> > >
> > > carveout {
> > > compatible = "nvidia,tegra20-carveout";
> > > size = <0x1000>;
> > > };
> > >
> > > Then create a file such like "tegra-carveout.c" to get these definitions
> > > and
> > register itself as platform device's iommu instance.
> >
> > The carveout isn't a HW object, so it doesn't seem appropriate to define a
> > DT
> > node to represent it.
> > --
>
> Yes. But I think it's better to export the size of carveout as a configurable
> item.
> So we need to define this somewhere. How about define carveout as a property
> of gart?
I agree that the carveout size should be configurable. But it may not be
related to gart.
[PATCH 0/11] drm/exynos: update crtc and plane
> -Original Message- > From: Joonyoung Shim [mailto:jy0922.shim at samsung.com] > Sent: Wednesday, June 27, 2012 2:27 PM > To: dri-devel at lists.freedesktop.org > Cc: inki.dae at samsung.com; kyungmin.park at samsung.com > Subject: [PATCH 0/11] drm/exynos: update crtc and plane > > This patchset is about update of crtc and plane. The interface of crtc and > plane to control overlay is integrated internally. For this some code > fixings are added. Also this supports the exynos specific property for > crtc and plane. > > Joonyoung Shim (11): > drm/exynos: fix point to call overlay_ops->mode_set > drm/exynos: fix to set pipe of crtc > drm/exynos: define to_exynos_plane macro > drm/exynos: use private plane for crtc > drm/exynos: update overlay via plane from crtc > drm/exynos: add property for plane zpos > drm/exynos: fix dpms operation for mode set > drm/exynos: remove unnecessary connector dpms control > drm/exynos: add plane enable/disable > drm/exynos: add crtc disable function > drm/exynos: add property for crtc mode > > drivers/gpu/drm/exynos/exynos_drm_crtc.c| 294 --- > > drivers/gpu/drm/exynos/exynos_drm_crtc.h| 31 --- > drivers/gpu/drm/exynos/exynos_drm_drv.c |9 +- > drivers/gpu/drm/exynos/exynos_drm_drv.h |4 + > drivers/gpu/drm/exynos/exynos_drm_encoder.c | 123 +-- > drivers/gpu/drm/exynos/exynos_drm_encoder.h | 12 +- > drivers/gpu/drm/exynos/exynos_drm_plane.c | 246 +++--- > drivers/gpu/drm/exynos/exynos_drm_plane.h | 12 +- > include/drm/exynos_drm.h|9 - > 9 files changed, 373 insertions(+), 367 deletions(-) > -- > 1.7.5.4 these patch sets will go to exynos-drm-next after reviewed. Thanks, Inki Dae
Tegra DRM device tree bindings
On Tue, 26 Jun 2012 16:00:33 +0200
Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Jun 26, 2012 at 04:02:24PM +0300, Hiroshi Doyu wrote:
> > Hi Thierry,
> >
> > On Tue, 26 Jun 2012 12:55:13 +0200
> > Thierry Reding wrote:
> >
> > > > Old Signed by an unknown key
> > >
> > > Hi,
> > >
> > > while I haven't got much time to work on the actual code right now, I
> > > think it might still be useful if we could get the device tree binding
> > > to a point where everybody is happy with it. That'll also save me some
> > > time once I get to writing the code because I won't have to redo it over
> > > again. =)
> > >
> > > So here's the current proposal:
> > >
> > > host1x {
> > > compatible = "nvidia,tegra20-host1x", "simple-bus";
> > > reg = <0x5000 0x00024000>;
> > > interrupts = <0 64 0x04 /* cop syncpt */
> > > 0 65 0x04 /* mpcore syncpt */
> > > 0 66 0x04 /* cop general */
> > > 0 67 0x04>; /* mpcore general */
> > >
> > > #address-cells = <1>;
> > > #size-cells = <1>;
> > >
> > > ranges = <0x5400 0x5400 0x0400>;
> > >
> > > status = "disabled";
> > >
> > > gart = <&gart>;
> > ...
> > > output and hooks up a static EDID block with the LVDS output. There is
> > > also a carveout property which might be a better replacement for the
> > > "crippled" GART on Tegra20. Alternatively the CMA might work just as
> > > well instead.
> > >
> > > The Plutux can be described like this:
> > >
> > > host1x {
> > > carveout = <0x0e00 0x0200>;
> >
> > As discussed in the following ML thread previously, the necessary info
> > related to the "gart" would be got from the standard IOMMU API(or
> > something above layers, DMABUF or TTM?). So I don't think that we need
> > to refer to "gart" and "carveout" here in the end.
> >
> > http://lists.linuxfoundation.org/pipermail/iommu/2012-June/004266.html
>
> Yes, if IOMMU or some layer above can provide the same information, then
> that is certainly better than explicitly referencing it in the DT.
>
> I'm not sure I understand how information about the carveout would be
> obtained from the IOMMU API, though.
I think that there are 2 cases:
(1) discontiguous memory with IOMMU
(2) contiguous memory without IOMMU(called "carveout" in general?)
For (1), the necessary info should be passed via IOMMU API as
mentioned in the previous reply, like DT->{GART,SMMU}->IOMMU->DRM.
[PATCH 0/5] IOMMU: Make IOMMU-API ready for GART-like hardware
https://lkml.org/lkml/2012/1/19/170
For (2), although memory is mostly anonymous one, we may need to know
how much to allocate, where we only need "size". This size is not from
h/w feature, but it depends on the system load/usage. So I think that
this size can be passed from kernel command line? For exmaple, we can
specify how much contiguous memory is necessary with putting
"coherent_pool=??M" in the kernel command line as below:
coherent_pool=nn[KMG] [ARM,KNL]
Sets the size of memory pool for coherent, atomic dma
allocations.
[PATCH] DRM: add drm gem CMA helper
On Wed, Jun 27, 2012 at 03:20:27PM +0200, Laurent Pinchart wrote:
> Hi Sascha,
>
> Thanks for the patch.
>
> On Wednesday 27 June 2012 15:00:05 Sascha Hauer wrote:
> > Many embedded drm devices do not have a IOMMU and no dedicated
> > memory for graphics. These devices use CMA (Contiguous Memory
> > Allocator) backed graphics memory. This patch provides helper
> > functions to be able to share the code. The code technically does
> > not depend on CMA as the backend allocator, the name has been chosen
> > because cma makes for a nice, short but still descriptive function
> > prefix.
> >
> > Signed-off-by: Sascha Hauer
> > ---
> >
> > changes since v2:
> > - make drm_gem_cma_create_with_handle static
> > - use DIV_ROUND_UP(args->width * args->bpp, 8) to calculate the pitch
>
> [snip]
>
> > diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> > b/drivers/gpu/drm/drm_gem_cma_helper.c new file mode 100644
> > index 000..417f45e5
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> > @@ -0,0 +1,250 @@
>
> [snip]
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> Nitpicking, I usually sort headers alphabetically, that helps locating
> duplicates quickly. It's not mandatory though.
>
> [snip]
>
> > +/*
> > + * drm_gem_cma_dumb_create - (struct drm_driver)->dumb_create callback
> > + * function
> > + *
> > + * This aligns the pitch and size arguments to the minimum required. wrap
> > + * this into your own function if you need bigger alignment.
> > + */
> > +int drm_gem_cma_dumb_create(struct drm_file *file_priv,
> > + struct drm_device *dev, struct drm_mode_create_dumb *args)
> > +{
> > + struct drm_gem_cma_object *cma_obj;
> > +
> > + if (args->pitch < args->width * DIV_ROUND_UP(args->bpp, 8))
> > + args->pitch = args->width * DIV_ROUND_UP(args->bpp, 8);
>
> It's nice to mention in the changelog that you fixed the problem, but it
> would
> be even nicer to really fix it ;-)
Damn ;)
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH v4] DRM: add drm gem CMA helper
Many embedded drm devices do not have a IOMMU and no dedicated
memory for graphics. These devices use CMA (Contiguous Memory
Allocator) backed graphics memory. This patch provides helper
functions to be able to share the code. The code technically does
not depend on CMA as the backend allocator, the name has been chosen
because cma makes for a nice, short but still descriptive function
prefix.
Signed-off-by: Sascha Hauer
---
changes since v3:
- *really* use DIV_ROUND_UP(args->width * args->bpp, 8) to calculate the pitch
changes since v2:
- make drm_gem_cma_create_with_handle static
- use DIV_ROUND_UP(args->width * args->bpp, 8) to calculate the pitch
- make drm_gem_cma_vm_ops const
- add missing #include
changes since v1:
- map whole buffer at mmap time, not page by page at fault time
- several cleanups as suggested by Lars-Peter Clausen and Laurent Pinchart
drivers/gpu/drm/Kconfig |6 +
drivers/gpu/drm/Makefile |1 +
drivers/gpu/drm/drm_gem_cma_helper.c | 251 ++
include/drm/drm_gem_cma_helper.h | 44 ++
4 files changed, 302 insertions(+)
create mode 100644 drivers/gpu/drm/drm_gem_cma_helper.c
create mode 100644 include/drm/drm_gem_cma_helper.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index dc5df12..8f362ec 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -53,6 +53,12 @@ config DRM_TTM
GPU memory types. Will be enabled automatically if a device driver
uses it.
+config DRM_GEM_CMA_HELPER
+ tristate
+ depends on DRM
+ help
+ Choose this if you need the GEM CMA helper functions
+
config DRM_TDFX
tristate "3dfx Banshee/Voodoo3+"
depends on DRM && PCI
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 0487ff6..8759cda 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -15,6 +15,7 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o
drm_cache.o \
drm_trace_points.o drm_global.o drm_prime.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
+drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
drm-usb-y := drm_usb.o
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
new file mode 100644
index 000..1aa8fee
--- /dev/null
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -0,0 +1,251 @@
+/*
+ * drm gem CMA (contiguous memory allocator) helper functions
+ *
+ * Copyright (C) 2012 Sascha Hauer, Pengutronix
+ *
+ * Based on Samsung Exynos code
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static unsigned int get_gem_mmap_offset(struct drm_gem_object *obj)
+{
+ return (unsigned int)obj->map_list.hash.key << PAGE_SHIFT;
+}
+
+static void drm_gem_cma_buf_destroy(struct drm_device *drm,
+ struct drm_gem_cma_object *cma_obj)
+{
+ dma_free_writecombine(drm->dev, cma_obj->base.size, cma_obj->vaddr,
+ cma_obj->paddr);
+}
+
+/*
+ * drm_gem_cma_create - allocate an object with the given size
+ *
+ * returns a struct drm_gem_cma_object* on success or ERR_PTR values
+ * on failure.
+ */
+struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
+ unsigned int size)
+{
+ struct drm_gem_cma_object *cma_obj;
+ struct drm_gem_object *gem_obj;
+ int ret;
+
+ size = round_up(size, PAGE_SIZE);
+
+ cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
+ if (!cma_obj)
+ return ERR_PTR(-ENOMEM);
+
+ cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
+ &cma_obj->paddr, GFP_KERNEL | __GFP_NOWARN);
+ if (!cma_obj->vaddr) {
+ dev_err(drm->dev, "failed to allocate buffer with size %d\n",
size);
+ ret = -ENOMEM;
+ goto err_dma_alloc;
+ }
+
+ gem_obj = &cma_obj->base;
+
+ ret = drm_gem_object_init(drm, gem_obj, size);
+ if (ret)
+ goto err_obj_init;
+
+ ret = drm_gem_create_mmap_offset(gem_obj);
+ if (ret)
+ goto err_create_mmap_offset;
+
+ return cma_obj;
+
+err_create_mmap_offset:
+ drm_gem_object_release(gem_obj);
+
+err_obj_init:
+ drm_gem_cma_buf_destroy(drm, cma_obj);
+
+err_dma_alloc:
+ kfree(cma_obj);
[ANN] compat-drm tree
Hi, I'm maintaining a compat-drm tree (based on compat.git) as part of my GSoC project with Linux Foundation, under the mentorship of Luis R. Rodriguez. The aim of the tree is to offer the latest DRM stuff to people stuck with older kernels (Currently all of the popular and maintained drm drivers except i915 (there's an i2c think that I couldn't backport yet) from linux-next can be built against kernels down to 3.0). The tree is on github. I've set up a shiny github pages for it: http://ozancaglayan.github.com/compat-drm/ Thanks! -- Ozan Çağlayan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] DRM: add drm gem CMA helper
Hi Sascha,
Thanks for the patch.
On Wednesday 27 June 2012 15:00:05 Sascha Hauer wrote:
> Many embedded drm devices do not have a IOMMU and no dedicated
> memory for graphics. These devices use CMA (Contiguous Memory
> Allocator) backed graphics memory. This patch provides helper
> functions to be able to share the code. The code technically does
> not depend on CMA as the backend allocator, the name has been chosen
> because cma makes for a nice, short but still descriptive function
> prefix.
>
> Signed-off-by: Sascha Hauer
> ---
>
> changes since v2:
> - make drm_gem_cma_create_with_handle static
> - use DIV_ROUND_UP(args->width * args->bpp, 8) to calculate the pitch
[snip]
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c new file mode 100644
> index 000..417f45e5
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -0,0 +1,250 @@
[snip]
> +#include
> +#include
> +#include
> +#include
> +#include
Nitpicking, I usually sort headers alphabetically, that helps locating
duplicates quickly. It's not mandatory though.
[snip]
> +/*
> + * drm_gem_cma_dumb_create - (struct drm_driver)->dumb_create callback
> + * function
> + *
> + * This aligns the pitch and size arguments to the minimum required. wrap
> + * this into your own function if you need bigger alignment.
> + */
> +int drm_gem_cma_dumb_create(struct drm_file *file_priv,
> + struct drm_device *dev, struct drm_mode_create_dumb *args)
> +{
> + struct drm_gem_cma_object *cma_obj;
> +
> + if (args->pitch < args->width * DIV_ROUND_UP(args->bpp, 8))
> + args->pitch = args->width * DIV_ROUND_UP(args->bpp, 8);
It's nice to mention in the changelog that you fixed the problem, but it would
be even nicer to really fix it ;-)
> +
> + if (args->size < args->pitch * args->height)
> + args->size = args->pitch * args->height;
> +
> + cma_obj = drm_gem_cma_create_with_handle(file_priv, dev,
> + args->size, &args->handle);
> + if (IS_ERR(cma_obj))
> + return PTR_ERR(cma_obj);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_cma_dumb_create);
--
Regards,
Laurent Pinchart
[PATCH] staging: drm/omap: update TODO
From: Rob Clark Update TODO file, which had been neglected. Signed-off-by: Rob Clark --- drivers/staging/omapdrm/TODO |7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/staging/omapdrm/TODO b/drivers/staging/omapdrm/TODO index 55b1837..938c788 100644 --- a/drivers/staging/omapdrm/TODO +++ b/drivers/staging/omapdrm/TODO @@ -1,9 +1,7 @@ TODO -. check error handling/cleanup paths -. add drm_plane / overlay support . add video decode/encode support (via syslink3 + codec-engine) -. still some rough edges with flipping.. event back to userspace should - really come after VSYNC interrupt + . NOTE: with dmabuf this probably could be split into different driver +so perhaps this TODO doesn't belong here . where should we do eviction (detatch_pages())? We aren't necessarily accessing the pages via a GART, so maybe we need some other threshold to put a cap on the # of pages that can be pin'd. (It is mostly only @@ -27,7 +25,6 @@ TODO CRTC's should be disabled, and on resume the LUT should be reprogrammed before CRTC's are re-enabled, to prevent DSS from trying to DMA from a buffer mapped in DMM/TILER before LUT is reloaded. -. Add debugfs information for DMM/TILER Userspace: . git://github.com/robclark/xf86-video-omap.git -- 1.7.9.5
[PATCH] staging: drm/omap: add rotation properties
On Wed, Jun 27, 2012 at 2:40 PM, Greg KH wrote: > On Wed, Jun 27, 2012 at 09:06:26AM -0500, Rob Clark wrote: >> From: Rob Clark >> >> Use tiled buffers for rotated/reflected scanout, with CRTC and plane >> properties as the interface for userspace to configure rotation. >> >> Signed-off-by: Rob Clark >> --- >> ?drivers/staging/omapdrm/omap_crtc.c ? ? ?| ? 17 + >> ?drivers/staging/omapdrm/omap_dmm_tiler.c | ? 47 -- >> ?drivers/staging/omapdrm/omap_dmm_tiler.h | ? 17 - >> ?drivers/staging/omapdrm/omap_drv.c ? ? ? | ? 17 + >> ?drivers/staging/omapdrm/omap_drv.h ? ? ? | ? 32 +- >> ?drivers/staging/omapdrm/omap_fb.c ? ? ? ?| ? 99 >> +- >> ?drivers/staging/omapdrm/omap_gem.c ? ? ? | ? 43 - >> ?drivers/staging/omapdrm/omap_plane.c ? ? | ? 92 --- >> ?8 files changed, 318 insertions(+), 46 deletions(-) > > That's great you are adding new features, but how goes the progress to > get this driver out of the drivers/staging/ area and moved to the real > part of the kernel? ?I don't want to keep taking new features without > seeing some progress on getting the code cleaned up and moved out first. Oh, heh, well I suppose the first thing to do is send a patch to clean up the TODO file.. I just noticed that I'd been forgetting to update it. BR, -R > thanks, > > greg k-h > -- > 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 v2] DRM: add drm gem cma helper
Hi Laurent, On Wed, Jun 27, 2012 at 01:38:39PM +0200, Laurent Pinchart wrote: > Hi Sascha, > > On Thursday 31 May 2012 10:08:54 Sascha Hauer wrote: > > Many embedded drm devices do not have a IOMMU and no dedicated > > memory for graphics. These devices use cma (Contiguous Memory > > Allocator) backed graphics memory. This patch provides helper > > functions to be able to share the code. > > Do you plan to post v3 in the near future ? Just did that. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH] DRM: add drm gem CMA helper
Many embedded drm devices do not have a IOMMU and no dedicated
memory for graphics. These devices use CMA (Contiguous Memory
Allocator) backed graphics memory. This patch provides helper
functions to be able to share the code. The code technically does
not depend on CMA as the backend allocator, the name has been chosen
because cma makes for a nice, short but still descriptive function
prefix.
Signed-off-by: Sascha Hauer
---
changes since v2:
- make drm_gem_cma_create_with_handle static
- use DIV_ROUND_UP(args->width * args->bpp, 8) to calculate the pitch
- make drm_gem_cma_vm_ops const
- add missing #include
changes since v1:
- map whole buffer at mmap time, not page by page at fault time
- several cleanups as suggested by Lars-Peter Clausen and Laurent Pinchart
drivers/gpu/drm/Kconfig |6 +
drivers/gpu/drm/Makefile |1 +
drivers/gpu/drm/drm_gem_cma_helper.c | 250 ++
include/drm/drm_gem_cma_helper.h | 44 ++
4 files changed, 301 insertions(+)
create mode 100644 drivers/gpu/drm/drm_gem_cma_helper.c
create mode 100644 include/drm/drm_gem_cma_helper.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index dc5df12..8f362ec 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -53,6 +53,12 @@ config DRM_TTM
GPU memory types. Will be enabled automatically if a device driver
uses it.
+config DRM_GEM_CMA_HELPER
+ tristate
+ depends on DRM
+ help
+ Choose this if you need the GEM CMA helper functions
+
config DRM_TDFX
tristate "3dfx Banshee/Voodoo3+"
depends on DRM && PCI
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 0487ff6..8759cda 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -15,6 +15,7 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o
drm_cache.o \
drm_trace_points.o drm_global.o drm_prime.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
+drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
drm-usb-y := drm_usb.o
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
new file mode 100644
index 000..417f45e5
--- /dev/null
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -0,0 +1,250 @@
+/*
+ * drm gem CMA (contiguous memory allocator) helper functions
+ *
+ * Copyright (C) 2012 Sascha Hauer, Pengutronix
+ *
+ * Based on Samsung Exynos code
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static unsigned int get_gem_mmap_offset(struct drm_gem_object *obj)
+{
+ return (unsigned int)obj->map_list.hash.key << PAGE_SHIFT;
+}
+
+static void drm_gem_cma_buf_destroy(struct drm_device *drm,
+ struct drm_gem_cma_object *cma_obj)
+{
+ dma_free_writecombine(drm->dev, cma_obj->base.size, cma_obj->vaddr,
+ cma_obj->paddr);
+}
+
+/*
+ * drm_gem_cma_create - allocate an object with the given size
+ *
+ * returns a struct drm_gem_cma_object* on success or ERR_PTR values
+ * on failure.
+ */
+struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
+ unsigned int size)
+{
+ struct drm_gem_cma_object *cma_obj;
+ struct drm_gem_object *gem_obj;
+ int ret;
+
+ size = round_up(size, PAGE_SIZE);
+
+ cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL);
+ if (!cma_obj)
+ return ERR_PTR(-ENOMEM);
+
+ cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
+ &cma_obj->paddr, GFP_KERNEL | __GFP_NOWARN);
+ if (!cma_obj->vaddr) {
+ dev_err(drm->dev, "failed to allocate buffer with size %d\n",
size);
+ ret = -ENOMEM;
+ goto err_dma_alloc;
+ }
+
+ gem_obj = &cma_obj->base;
+
+ ret = drm_gem_object_init(drm, gem_obj, size);
+ if (ret)
+ goto err_obj_init;
+
+ ret = drm_gem_create_mmap_offset(gem_obj);
+ if (ret)
+ goto err_create_mmap_offset;
+
+ return cma_obj;
+
+err_create_mmap_offset:
+ drm_gem_object_release(gem_obj);
+
+err_obj_init:
+ drm_gem_cma_buf_destroy(drm, cma_obj);
+
+err_dma_alloc:
+ kfree(cma_obj);
+
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(drm_gem_cma_create);
+
+/*
+ * drm_gem_cma_
[PATCH 10/10] drm/exynos: consider memory releasing to exported gem buffer into dmabuf
On Wed, Jun 27, 2012 at 09:44:15PM +0900, Inki Dae wrote:
> Hi Rob,
>
> > -Original Message-
> > From: robdclark at gmail.com [mailto:robdclark at gmail.com] On Behalf Of
> > Rob
> > Clark
> > Sent: Wednesday, June 27, 2012 9:20 PM
> > To: Inki Dae
> > Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> > kyungmin.park at samsung.com; sw0312.kim at samsung.com
> > Subject: Re: [PATCH 10/10] drm/exynos: consider memory releasing to
> > exported gem buffer into dmabuf
> >
> > On Wed, Jun 27, 2012 at 3:03 AM, Inki Dae wrote:
> > > exported gem buffer into dmabuf should be released when a gem relese is
> > > requested by user. with dma_buf_put() call, if file->f_count is 0 then
> > > a release callback of exynos gem module(exporter) will be called to
> > release
> > > its own gem buffer.
> > >
> > > Signed-off-by: Inki Dae
> > > Signed-off-by: Kyungmin Park
> > > ---
> > > drivers/gpu/drm/exynos/exynos_drm_drv.c |1 +
> > > drivers/gpu/drm/exynos/exynos_drm_gem.c | 16
> > > drivers/gpu/drm/exynos/exynos_drm_gem.h |4
> > > 3 files changed, 21 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > > index d6de2e0..1501dd2 100644
> > > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > > @@ -258,6 +258,7 @@ static struct drm_driver exynos_drm_driver = {
> > >.gem_init_object= exynos_drm_gem_init_object,
> > >.gem_free_object= exynos_drm_gem_free_object,
> > >.gem_vm_ops = &exynos_drm_gem_vm_ops,
> > > + .gem_close_object = exynos_drm_gem_close_object,
> > >.dumb_create= exynos_drm_gem_dumb_create,
> > >.dumb_map_offset= exynos_drm_gem_dumb_map_offset,
> > >.dumb_destroy = exynos_drm_gem_dumb_destroy,
> > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> > b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> > > index 411d82b..5ca8641 100644
> > > --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> > > +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> > > @@ -27,6 +27,7 @@
> > > #include "drm.h"
> > >
> > > #include
> > > +#include
> > > #include
> > >
> > > #include "exynos_drm_drv.h"
> > > @@ -749,6 +750,21 @@ int exynos_drm_gem_dumb_destroy(struct drm_file
> > *file_priv,
> > >return 0;
> > > }
> > >
> > > +void exynos_drm_gem_close_object(struct drm_gem_object *obj,
> > > + struct drm_file *file)
> > > +{
> > > + DRM_DEBUG_KMS("%s\n", __FILE__);
> > > +
> > > + /*
> > > +* exported dmabuf should be released when a gem is released by
> > user.
> > > +* with dma_buf_put() call, if file->f_count is 0 then a release
> > > +* callback of gem module(exporter) will be called to release
> > > +* its own gem buffer.
> > > +*/
> > > + if (obj->export_dma_buf)
> > > + dma_buf_put(obj->export_dma_buf);
> >
> > this doesn't seem quite right to me.. although I think the dmabuf
> > release fxn needs to NULL out the obj->export_dma_buf.
> >
> > If your GEM obj is getting released before your dmabuf then there is
> > something going wrong with the ref cnt'ing.
> >
> > BR,
> > -R
> >
>
> Could you look into below steps? I understood gem and dmabuf life cycle like
> below so thought we needs this patch. with this patch, the gem object isn't
> getting released before dmabuf and the gem will be released by dma_buf_put().
> if there is my missing point then please give me any comment.
>
> Reference count(step number)
>
> gem object1 gem object2 dmabuf
>
> 1(1)
> 2(2) 1(2)
> 1(3) 2(3)
> 0(4) 1(4)
> 1(5) 0(5)
> 0(5)
>
>
> 1. create gem1
> 2. export the gem1 into dmabuf
> 3. import the dmabuf into gem2
> 4. close gem2
> 5. close gem1
Step 5 looks wrong, simply closing the gem object 1 (in the exporting
driver) can't change the reference count of the dmabuf object.
Furthermore the dmabuf object _must_ be able to outlive the object it's
been created from. E.g. when you use dma-buf fd handles to facilitate
cross-process buffer sharing (maybe even on the same drm device, i.e. not
necessarily across devices), process A exports the dmabuf and passes the
fd and, process B imports it. Currently with dri2/gem_flink process A
needs to keep the gem object around until process B has confirmed that it
has imported the object, which is really ugly. But because fds themselves
hold a reference, this is not required for dma-buf cross-process sharing.
But if you break that (whith something like this patch) that won't work.
Long story short, your description ab
[PATCH, RFC] displaymodes in devicetree
Hi All,
I'd like to have a possibility to describe fixed display modes in the
devicetree. This topic has been discussed before here:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-February/080683.html
The result at that time was that EDID data should be considered to use
as this is a format that already exists. I want to come back to this
topic since:
- EDID data is a binary format and as such quite inconvenient to handle.
There exist several tools to parse EDID data, but I'm not aware of any
(open source) tool which can generate EDID data.
- EDID blobs are hard to modify and hard to review in patches.
- EDID is designed to describe multiple modes, but fixed displays
usually only support a single fixed mode.
There are several ways of describing the mode, for this patch I chose to
use the format (and naming) used by the Linux Framebuffer Layer as this
is the only description which does not allow for inconsistent modes. I
added the most common flags like [v|h]sync_active_high. Others can be
added, but these flags are pretty much agreed upon and won't be
superseeded with other flags. The mode from the devicetree can be
converted to the most common modes used in Linux, struct fb_videomode
and struct drm_display_mode.
Comments welcome
Sascha
8<
of: Add videomode helper
This patch adds a helper function for parsing videomodes from the devicetree.
The videomode is returned either as a struct drm_display_mode or a
struct fb_videomode.
Signed-off-by: Sascha Hauer
---
.../devicetree/bindings/video/displaymode | 40
drivers/of/Kconfig |5 +
drivers/of/Makefile|1 +
drivers/of/of_videomode.c | 108
include/linux/of_videomode.h | 19
5 files changed, 173 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/displaymode
create mode 100644 drivers/of/of_videomode.c
create mode 100644 include/linux/of_videomode.h
diff --git a/Documentation/devicetree/bindings/video/displaymode
b/Documentation/devicetree/bindings/video/displaymode
new file mode 100644
index 000..303cfc8
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/displaymode
@@ -0,0 +1,40 @@
+videomode bindings
+==
+
+Required properties:
+ - xres, yres: Display resolution
+ - left_margin, right_margin, hsync_len: Horizontal Display timing parameters
+ in pixels
+ upper_margin, lower_margin, vsync_len: Vertical display timing parameters in
+ lines
+ - clock: displayclock in Hz
+
+Optional properties:
+ - width_mm, height_mm: Display dimensions in mm
+ - hsync_active_high (bool): Hsync pulse is active high
+ - vsync_active_high (bool): Vsync pulse is active high
+ - interlaced (bool): This is an interlaced mode
+ - doublescan (bool): This is a doublescan mode
+
+There are different ways of describing a display mode. The devicetree
representation
+corresponds to the one used by the Linux Framebuffer framework described here
in
+Documentation/fb/framebuffer.txt. This representation has been chosen because
it's
+the only format which does not allow for inconsistent parameters.Unlike the
Framebuffer
+framework the devicetree has the clock in Hz instead of ps.
+
+Example:
+
+ display at 0 {
+ /* 1920x1080p24 */
+ clock = <5200>;
+ xres = <1920>;
+ yres = <1080>;
+ left_margin = <25>;
+ right_margin = <25>;
+ hsync_len = <25>;
+ lower_margin = <2>;
+ upper_margin = <2>;
+ vsync_len = <2>;
+ hsync_active_high;
+ };
+
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index dfba3e6..a3acaa3 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -83,4 +83,9 @@ config OF_MTD
depends on MTD
def_bool y
+config OF_VIDEOMODE
+ def_bool y
+ help
+ helper to parse videomodes from the devicetree
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index e027f44..80e6db3 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_OF_MDIO) += of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
+obj-$(CONFIG_OF_VIDEOMODE) += of_videomode.o
diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
new file mode 100644
index 000..859aefb
--- /dev/null
+++ b/drivers/of/of_videomode.c
@@ -0,0 +1,108 @@
+/*
+ * OF helpers for parsing display modes
+ *
+ * Copyright (c) 2012 Sascha Hauer , Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+#include
+#include
+#include
+#include
+#include
+
+int of_get_video_mode(struct device_node *np, struct drm_display_mode *dmode,
+ struct fb_videomode *fbmode)
+{
+ int ret = 0;
[PATCH 4/4] drm: Renesas SH Mobile DRM driver
Hi Ville,
Thank you for the review.
On Wednesday 30 May 2012 17:16:46 Ville Syrj?l? wrote:
> On Wed, May 30, 2012 at 02:32:59PM +0200, Laurent Pinchart wrote:
> > +static struct drm_framebuffer *
> > +shmob_drm_fb_create(struct drm_device *dev, struct drm_file *file_priv,
> > + struct drm_mode_fb_cmd2 *mode_cmd)
> > +{
> > + const struct shmob_drm_format_info *format;
> > + struct shmob_drm_framebuffer *sfb;
> > + struct drm_framebuffer *fb;
> > + struct drm_gem_object *obj;
> > + unsigned int i;
> > + int ret;
> > +
> > + format = shmob_drm_format_info(mode_cmd->pixel_format);
> > + if (format == NULL) {
> > + dev_dbg(dev->dev, "unsupported pixel format %08x\n",
> > + mode_cmd->pixel_format);
> > + return ERR_PTR(-EINVAL);
> > + }
> > +
> > + sfb = kzalloc(sizeof(*fb), GFP_KERNEL);
> > + if (sfb == NULL)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + sfb->format = format;
> > + fb = &sfb->base;
> > +
> > + for (i = 0; i < (format->yuv ? 2 : 1); ++i) {
> > + obj = drm_gem_object_lookup(dev, file_priv,
> > + mode_cmd->handles[i]);
> > + if (obj == NULL) {
> > + dev_dbg(dev->dev, "GEM object %u not found\n",
> > + mode_cmd->handles[i]);
> > + ret = -ENOENT;
> > + goto error;
> > + }
> > + sfb->sobj[i] = to_shmob_gem_object(obj);
> > + }
>
> offsets[] not checked, nor is it handled in the code that calculates the
> final offsets.
>
> Based on the rest of the code, it seems that the hardware assumes
> pitches[1] == pitches[0]*chroma_cpp. You should reject other values here.
> Also it's not clear from the code if there are other stride limitations that
> would need checking.
>
> Also there are no checks to make sure the fb fits inside the gem object. At
> one point I tried to cook up a generic function to help with such checks. I
> probably need to revisit that issue and try to make something that'd work
> for tiled formats as well.
You're right. I now use the generic drm_fb_cma_create() function from Lars-
Peter "DRM: Add DRM kms/fb cma helper" patch, so the above code is gone. I'll
make sure your comments get addressed in the patch.
--
Regards,
Laurent Pinchart
[PATCH 4/4] drm: Renesas SH Mobile DRM driver
Hi Lars-Peter,
On Wednesday 30 May 2012 17:10:00 Lars-Peter Clausen wrote:
> On 05/30/2012 04:45 PM, Lars-Peter Clausen wrote:
> > On 05/30/2012 02:32 PM, Laurent Pinchart wrote:
> >> [...]
> >> + for (i = 0; i < (format->yuv ? 2 : 1); ++i) {
> >> + obj = drm_gem_object_lookup(dev, file_priv,
> >> + mode_cmd->handles[i]);
> >> + if (obj == NULL) {
> >> + dev_dbg(dev->dev, "GEM object %u not found\n",
> >> + mode_cmd->handles[i]);
> >> + ret = -ENOENT;
> >> + goto error;
> >> + }
> >> + sfb->sobj[i] = to_shmob_gem_object(obj);
> >> + }
> >> +
> >
> > I added multi-plane support the cma fb helper functions and it seems to
> > work. But all other DRM drivers seem to assume that multi-plane formats
> > still only have a single buffer, while yours seems to assume that there is
> > a plane for each buffer. The exception is the Exynos driver, but it added
> > a new set of formats which are identical to the other formats, but use
> > one buffer per plane.
> >
> > So I'm not sure how to implement this correctly in a generic fashion.
>
> This post by Ville Syrj?l? seems to explain it quite well:
> http://lists.freedesktop.org/archives/dri-devel/2012-April/021044.html
Do you plan to post a v3 of your "DRM: Add DRM kms/fb cma helper" patch in the
near future ?
--
Regards,
Laurent Pinchart
[PATCH 11/11] drm/exynos: add property for crtc mode
This patch adds exynos specific property for crtc mode. The crtc mode
property has tow modes - normal and blank. The normal mode is default
mode and can use crtc normally. The blank mode turns off the private
plane of crtc, so we don't see crtc screen but can see other plane
screens.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 72 ++
drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
2 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 5cf05f8..46df18f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -36,6 +36,11 @@
#define to_exynos_crtc(x) container_of(x, struct exynos_drm_crtc,\
drm_crtc)
+enum exynos_crtc_mode {
+ CRTC_MODE_NORMAL, /* normal mode */
+ CRTC_MODE_BLANK,/* The private plane of crtc is blank */
+};
+
/*
* Exynos specific crtc structure.
*
@@ -49,12 +54,14 @@
* we can refer to the crtc to current hardware interrupt occured through
* this pipe value.
* @dpms: store the crtc dpms value
+ * @mode: store the crtc mode value
*/
struct exynos_drm_crtc {
struct drm_crtc drm_crtc;
struct drm_plane*plane;
unsigned intpipe;
unsigned intdpms;
+ enum exynos_crtc_mode mode;
};
static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
@@ -255,12 +262,75 @@ static void exynos_drm_crtc_destroy(struct drm_crtc *crtc)
kfree(exynos_crtc);
}
+static int exynos_drm_crtc_set_property(struct drm_crtc *crtc,
+ struct drm_property *property,
+ uint64_t val)
+{
+ struct drm_device *dev = crtc->dev;
+ struct exynos_drm_private *dev_priv = dev->dev_private;
+ struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+
+ DRM_DEBUG_KMS("%s\n", __func__);
+
+ if (property == dev_priv->crtc_mode_property) {
+ enum exynos_crtc_mode mode = val;
+
+ if (mode == exynos_crtc->mode)
+ return 0;
+
+ exynos_crtc->mode = mode;
+
+ switch (mode) {
+ case CRTC_MODE_NORMAL:
+ exynos_drm_crtc_commit(crtc);
+ break;
+ case CRTC_MODE_BLANK:
+ exynos_plane_dpms(exynos_crtc->plane,
+ DRM_MODE_DPMS_OFF);
+ break;
+ default:
+ break;
+ }
+
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
static struct drm_crtc_funcs exynos_crtc_funcs = {
.set_config = drm_crtc_helper_set_config,
.page_flip = exynos_drm_crtc_page_flip,
.destroy= exynos_drm_crtc_destroy,
+ .set_property = exynos_drm_crtc_set_property,
+};
+
+static const struct drm_prop_enum_list mode_names[] = {
+ { CRTC_MODE_NORMAL, "normal" },
+ { CRTC_MODE_BLANK, "blank" },
};
+static void exynos_drm_crtc_attach_mode_property(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct exynos_drm_private *dev_priv = dev->dev_private;
+ struct drm_property *prop;
+
+ DRM_DEBUG_KMS("%s\n", __func__);
+
+ prop = dev_priv->crtc_mode_property;
+ if (!prop) {
+ prop = drm_property_create_enum(dev, 0, "mode", mode_names,
+ ARRAY_SIZE(mode_names));
+ if (!prop)
+ return;
+
+ dev_priv->crtc_mode_property = prop;
+ }
+
+ drm_object_attach_property(&crtc->base, prop, 0);
+}
+
int exynos_drm_crtc_create(struct drm_device *dev, unsigned int nr)
{
struct exynos_drm_crtc *exynos_crtc;
@@ -290,6 +360,8 @@ int exynos_drm_crtc_create(struct drm_device *dev, unsigned
int nr)
drm_crtc_init(dev, crtc, &exynos_crtc_funcs);
drm_crtc_helper_add(crtc, &exynos_crtc_helper_funcs);
+ exynos_drm_crtc_attach_mode_property(crtc);
+
return 0;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 22ba658..2c5fa4e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -238,6 +238,7 @@ struct exynos_drm_private {
*/
struct drm_crtc *crtc[MAX_CRTC];
struct drm_property *plane_zpos_property;
+ struct drm_property *crtc_mode_property;
};
/*
--
1.7.5.4
[PATCH 10/11] drm/exynos: add crtc disable function
The crtc disable is used to turn off private plane for crtc.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 7ca2854..5cf05f8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -173,6 +173,16 @@ static void exynos_drm_crtc_load_lut(struct drm_crtc *crtc)
/* drm framework doesn't check NULL */
}
+static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
+{
+ struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+
+ DRM_DEBUG_KMS("%s\n", __FILE__);
+
+ exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_OFF);
+ exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
+}
+
static struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
.dpms = exynos_drm_crtc_dpms,
.prepare= exynos_drm_crtc_prepare,
@@ -181,6 +191,7 @@ static struct drm_crtc_helper_funcs
exynos_crtc_helper_funcs = {
.mode_set = exynos_drm_crtc_mode_set,
.mode_set_base = exynos_drm_crtc_mode_set_base,
.load_lut = exynos_drm_crtc_load_lut,
+ .disable= exynos_drm_crtc_disable,
};
static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
--
1.7.5.4
[PATCH 09/11] drm/exynos: add plane enable/disable
The plane enable/disable can control only a power of plane, so they will
be helpful to handle planes with dpms.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c| 20 ++
drivers/gpu/drm/exynos/exynos_drm_drv.h |2 +
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 16 +++
drivers/gpu/drm/exynos/exynos_drm_encoder.h |1 +
drivers/gpu/drm/exynos/exynos_drm_plane.c | 38 +++
drivers/gpu/drm/exynos/exynos_drm_plane.h |1 +
6 files changed, 50 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 7cda72e..7ca2854 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -71,23 +71,8 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int
mode)
mutex_lock(&dev->struct_mutex);
- switch (mode) {
- case DRM_MODE_DPMS_ON:
- exynos_drm_fn_encoder(crtc, &mode,
- exynos_drm_encoder_crtc_dpms);
- exynos_crtc->dpms = mode;
- break;
- case DRM_MODE_DPMS_STANDBY:
- case DRM_MODE_DPMS_SUSPEND:
- case DRM_MODE_DPMS_OFF:
- exynos_drm_fn_encoder(crtc, &mode,
- exynos_drm_encoder_crtc_dpms);
- exynos_crtc->dpms = mode;
- break;
- default:
- DRM_ERROR("unspecified mode %d\n", mode);
- break;
- }
+ exynos_drm_fn_encoder(crtc, &mode, exynos_drm_encoder_crtc_dpms);
+ exynos_crtc->dpms = mode;
mutex_unlock(&dev->struct_mutex);
}
@@ -106,6 +91,7 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
DRM_DEBUG_KMS("%s\n", __FILE__);
exynos_plane_commit(exynos_crtc->plane);
+ exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
}
static bool
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index c25d929..22ba658 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -59,12 +59,14 @@ enum exynos_drm_output_type {
*
* @mode_set: copy drm overlay info to hw specific overlay info.
* @commit: apply hardware specific overlay data to registers.
+ * @enable: enable hardware specific overlay.
* @disable: disable hardware specific overlay.
*/
struct exynos_drm_overlay_ops {
void (*mode_set)(struct device *subdrv_dev,
struct exynos_drm_overlay *overlay);
void (*commit)(struct device *subdrv_dev, int zpos);
+ void (*enable)(struct device *subdrv_dev, int zpos);
void (*disable)(struct device *subdrv_dev, int zpos);
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index e0e02c2..2c6c977 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -392,6 +392,22 @@ void exynos_drm_encoder_plane_commit(struct drm_encoder
*encoder, void *data)
overlay_ops->commit(manager->dev, zpos);
}
+void exynos_drm_encoder_plane_enable(struct drm_encoder *encoder, void *data)
+{
+ struct exynos_drm_manager *manager =
+ to_exynos_encoder(encoder)->manager;
+ struct exynos_drm_overlay_ops *overlay_ops = manager->overlay_ops;
+ int zpos = DEFAULT_ZPOS;
+
+ DRM_DEBUG_KMS("%s\n", __FILE__);
+
+ if (data)
+ zpos = *(int *)data;
+
+ if (overlay_ops && overlay_ops->enable)
+ overlay_ops->enable(manager->dev, zpos);
+}
+
void exynos_drm_encoder_plane_disable(struct drm_encoder *encoder, void *data)
{
struct exynos_drm_manager *manager =
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.h
b/drivers/gpu/drm/exynos/exynos_drm_encoder.h
index 7692ee4..6470d9d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.h
@@ -44,6 +44,7 @@ void exynos_drm_encoder_crtc_dpms(struct drm_encoder
*encoder, void *data);
void exynos_drm_encoder_crtc_pipe(struct drm_encoder *encoder, void *data);
void exynos_drm_encoder_plane_mode_set(struct drm_encoder *encoder, void
*data);
void exynos_drm_encoder_plane_commit(struct drm_encoder *encoder, void *data);
+void exynos_drm_encoder_plane_enable(struct drm_encoder *encoder, void *data);
void exynos_drm_encoder_plane_disable(struct drm_encoder *encoder, void *data);
#endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index f018c9d..b89829e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -107,8 +107,32 @@ void exynos_plane_commit(struct drm_plane *plane)
exynos_drm_fn_encoder(plane->crtc, &overlay->zpos,
exynos_drm_encoder_plane_commit);
[PATCH 08/11] drm/exynos: remove unnecessary connector dpms control
The connector dpms should be controlled only by DPMS property and mode
set.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index dbf7e5e..e0e02c2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -327,11 +327,9 @@ void exynos_drm_disable_vblank(struct drm_encoder
*encoder, void *data)
void exynos_drm_encoder_crtc_dpms(struct drm_encoder *encoder, void *data)
{
- struct drm_device *dev = encoder->dev;
struct exynos_drm_encoder *exynos_encoder = to_exynos_encoder(encoder);
struct exynos_drm_manager *manager = exynos_encoder->manager;
struct exynos_drm_manager_ops *manager_ops = manager->ops;
- struct drm_connector *connector;
int mode = *(int *)data;
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -340,15 +338,6 @@ void exynos_drm_encoder_crtc_dpms(struct drm_encoder
*encoder, void *data)
manager_ops->dpms(manager->dev, mode);
/*
-* set current dpms mode to the connector connected to
-* current encoder. connector->dpms would be checked
-* at drm_helper_connector_dpms()
-*/
- list_for_each_entry(connector, &dev->mode_config.connector_list, head)
- if (connector->encoder == encoder)
- connector->dpms = mode;
-
- /*
* if this condition is ok then it means that the crtc is already
* detached from encoder and last function for detaching is properly
* done, so clear pipe from manager to prevent repeated call.
--
1.7.5.4
[PATCH 07/11] drm/exynos: fix dpms operation for mode set
When we do mode set, the dpms mode should be ON. Don't control dpms in
crtc commit function.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c| 26 +++---
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 14 ++
drivers/gpu/drm/exynos/exynos_drm_encoder.h |2 --
3 files changed, 5 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 32c166a..7cda72e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -105,28 +105,6 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
DRM_DEBUG_KMS("%s\n", __FILE__);
- /*
-* when set_crtc is requested from user or at booting time,
-* crtc->commit would be called without dpms call so if dpms is
-* no power on then crtc->dpms should be called
-* with DRM_MODE_DPMS_ON for the hardware power to be on.
-*/
- if (exynos_crtc->dpms != DRM_MODE_DPMS_ON) {
- int mode = DRM_MODE_DPMS_ON;
-
- /*
-* enable hardware(power on) to all encoders hdmi connected
-* to current crtc.
-*/
- exynos_drm_crtc_dpms(crtc, mode);
- /*
-* enable dma to all encoders connected to current crtc and
-* lcd panel.
-*/
- exynos_drm_fn_encoder(crtc, &mode,
- exynos_drm_encoder_dpms_from_crtc);
- }
-
exynos_plane_commit(exynos_crtc->plane);
}
@@ -155,6 +133,8 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode,
DRM_DEBUG_KMS("%s\n", __FILE__);
+ exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
+
/*
* copy the mode data adjusted by mode_fixup() into crtc->mode
* so that hardware can be seet to proper mode.
@@ -196,7 +176,7 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc
*crtc, int x, int y,
if (ret)
return ret;
- exynos_plane_commit(exynos_crtc->plane);
+ exynos_drm_crtc_commit(crtc);
return 0;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 316e549..dbf7e5e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -138,6 +138,8 @@ static void exynos_drm_encoder_mode_set(struct drm_encoder
*encoder,
DRM_DEBUG_KMS("%s\n", __FILE__);
+ exynos_drm_encoder_dpms(encoder, DRM_MODE_DPMS_ON);
+
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
if (connector->encoder == encoder)
if (manager_ops && manager_ops->mode_set)
@@ -323,18 +325,6 @@ void exynos_drm_disable_vblank(struct drm_encoder
*encoder, void *data)
manager_ops->disable_vblank(manager->dev);
}
-void exynos_drm_encoder_dpms_from_crtc(struct drm_encoder *encoder, void *data)
-{
- struct exynos_drm_encoder *exynos_encoder = to_exynos_encoder(encoder);
- int mode = *(int *)data;
-
- DRM_DEBUG_KMS("%s\n", __FILE__);
-
- exynos_drm_encoder_dpms(encoder, mode);
-
- exynos_encoder->dpms = mode;
-}
-
void exynos_drm_encoder_crtc_dpms(struct drm_encoder *encoder, void *data)
{
struct drm_device *dev = encoder->dev;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.h
b/drivers/gpu/drm/exynos/exynos_drm_encoder.h
index cabe3eb..7692ee4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.h
@@ -40,8 +40,6 @@ void exynos_drm_fn_encoder(struct drm_crtc *crtc, void *data,
void (*fn)(struct drm_encoder *, void *));
void exynos_drm_enable_vblank(struct drm_encoder *encoder, void *data);
void exynos_drm_disable_vblank(struct drm_encoder *encoder, void *data);
-void exynos_drm_encoder_dpms_from_crtc(struct drm_encoder *encoder,
- void *data);
void exynos_drm_encoder_crtc_dpms(struct drm_encoder *encoder, void *data);
void exynos_drm_encoder_crtc_pipe(struct drm_encoder *encoder, void *data);
void exynos_drm_encoder_plane_mode_set(struct drm_encoder *encoder, void
*data);
--
1.7.5.4
[PATCH 06/11] drm/exynos: add property for plane zpos
The exynos drm driver used a specific ioctl - DRM_EXYNOS_PLANE_SET_ZPOS
to set zpos of plane. It can be substitute to property of plane. This
patch adds a property for plane zpos and removes
DRM_EXYNOS_PLANE_SET_ZPOS ioctl.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |2 -
drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
drivers/gpu/drm/exynos/exynos_drm_plane.c | 92 +++--
drivers/gpu/drm/exynos/exynos_drm_plane.h |2 -
include/drm/exynos_drm.h |9 ---
5 files changed, 48 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index e313dc2..ebacec6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -224,8 +224,6 @@ static struct drm_ioctl_desc exynos_ioctls[] = {
exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET,
exynos_drm_gem_get_ioctl, DRM_UNLOCKED),
- DRM_IOCTL_DEF_DRV(EXYNOS_PLANE_SET_ZPOS, exynos_plane_set_zpos_ioctl,
- DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION,
vidi_connection_ioctl, DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_G2D_GET_VER,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index c82c90c..c25d929 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -235,6 +235,7 @@ struct exynos_drm_private {
* this array is used to be aware of which crtc did it request vblank.
*/
struct drm_crtc *crtc[MAX_CRTC];
+ struct drm_property *plane_zpos_property;
};
/*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 232e323..f018c9d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -150,7 +150,6 @@ static int exynos_disable_plane(struct drm_plane *plane)
exynos_drm_encoder_plane_disable);
exynos_plane->enabled = false;
- exynos_plane->overlay.zpos = DEFAULT_ZPOS;
return 0;
}
@@ -166,26 +165,66 @@ static void exynos_plane_destroy(struct drm_plane *plane)
kfree(exynos_plane);
}
+static int exynos_plane_set_property(struct drm_plane *plane,
+struct drm_property *property,
+uint64_t val)
+{
+ struct drm_device *dev = plane->dev;
+ struct exynos_plane *exynos_plane = to_exynos_plane(plane);
+ struct exynos_drm_private *dev_priv = dev->dev_private;
+
+ DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
+
+ if (property == dev_priv->plane_zpos_property) {
+ exynos_plane->overlay.zpos = val;
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane = exynos_update_plane,
.disable_plane = exynos_disable_plane,
.destroy= exynos_plane_destroy,
+ .set_property = exynos_plane_set_property,
};
+static void exynos_plane_attach_zpos_property(struct drm_plane *plane)
+{
+ struct drm_device *dev = plane->dev;
+ struct exynos_drm_private *dev_priv = dev->dev_private;
+ struct drm_property *prop;
+
+ DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
+
+ prop = dev_priv->plane_zpos_property;
+ if (!prop) {
+ prop = drm_property_create_range(dev, 0, "zpos", 0,
+MAX_PLANE - 1);
+ if (!prop)
+ return;
+
+ dev_priv->plane_zpos_property = prop;
+ }
+
+ drm_object_attach_property(&plane->base, prop, 0);
+}
+
struct drm_plane *exynos_plane_init(struct drm_device *dev,
unsigned int possible_crtcs, bool priv)
{
struct exynos_plane *exynos_plane;
int err;
+ DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
+
exynos_plane = kzalloc(sizeof(struct exynos_plane), GFP_KERNEL);
if (!exynos_plane) {
DRM_ERROR("failed to allocate plane\n");
return NULL;
}
- exynos_plane->overlay.zpos = DEFAULT_ZPOS;
-
err = drm_plane_init(dev, &exynos_plane->base, possible_crtcs,
&exynos_plane_funcs, formats, ARRAY_SIZE(formats),
priv);
@@ -195,47 +234,10 @@ struct drm_plane *exynos_plane_init(struct drm_device
*dev,
return NULL;
}
- return &exynos_plane->base;
-}
-
-int exynos_plane_set_zpos_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
-{
- struct drm_exynos_plane_set_
[PATCH 05/11] drm/exynos: update overlay via plane from crtc
There is no any reason to update overlay at crtc directly because the
crtc uses plane. Move its code to plane and call proper functions of
plane from crtc.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c| 146 +--
drivers/gpu/drm/exynos/exynos_drm_crtc.h| 29 --
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 66 ++---
drivers/gpu/drm/exynos/exynos_drm_encoder.h |8 +-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 117 --
drivers/gpu/drm/exynos/exynos_drm_plane.h |7 +-
6 files changed, 151 insertions(+), 222 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 0dda0de..32c166a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -30,10 +30,7 @@
#include "drm_crtc_helper.h"
#include "exynos_drm_drv.h"
-#include "exynos_drm_crtc.h"
-#include "exynos_drm_fb.h"
#include "exynos_drm_encoder.h"
-#include "exynos_drm_gem.h"
#include "exynos_drm_plane.h"
#define to_exynos_crtc(x) container_of(x, struct exynos_drm_crtc,\
@@ -60,107 +57,6 @@ struct exynos_drm_crtc {
unsigned intdpms;
};
-static void exynos_drm_crtc_apply(struct drm_crtc *crtc)
-{
- struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
- struct exynos_drm_overlay *overlay =
- get_exynos_drm_overlay(exynos_crtc->plane);
-
- exynos_drm_fn_encoder(crtc, overlay,
- exynos_drm_encoder_crtc_mode_set);
- exynos_drm_fn_encoder(crtc, NULL, exynos_drm_encoder_crtc_commit);
-}
-
-int exynos_drm_overlay_update(struct exynos_drm_overlay *overlay,
- struct drm_framebuffer *fb,
- struct drm_display_mode *mode,
- struct exynos_drm_crtc_pos *pos)
-{
- struct exynos_drm_gem_buf *buffer;
- unsigned int actual_w;
- unsigned int actual_h;
- int nr = exynos_drm_format_num_buffers(fb->pixel_format);
- int i;
-
- for (i = 0; i < nr; i++) {
- buffer = exynos_drm_fb_buffer(fb, i);
- if (!buffer) {
- DRM_LOG_KMS("buffer is null\n");
- return -EFAULT;
- }
-
- overlay->dma_addr[i] = buffer->dma_addr;
- overlay->vaddr[i] = buffer->kvaddr;
-
- DRM_DEBUG_KMS("buffer: %d, vaddr = 0x%lx, dma_addr = 0x%lx\n",
- i, (unsigned long)overlay->vaddr[i],
- (unsigned long)overlay->dma_addr[i]);
- }
-
- actual_w = min((mode->hdisplay - pos->crtc_x), pos->crtc_w);
- actual_h = min((mode->vdisplay - pos->crtc_y), pos->crtc_h);
-
- /* set drm framebuffer data. */
- overlay->fb_x = pos->fb_x;
- overlay->fb_y = pos->fb_y;
- overlay->fb_width = fb->width;
- overlay->fb_height = fb->height;
- overlay->src_width = pos->src_w;
- overlay->src_height = pos->src_h;
- overlay->bpp = fb->bits_per_pixel;
- overlay->pitch = fb->pitches[0];
- overlay->pixel_format = fb->pixel_format;
-
- /* set overlay range to be displayed. */
- overlay->crtc_x = pos->crtc_x;
- overlay->crtc_y = pos->crtc_y;
- overlay->crtc_width = actual_w;
- overlay->crtc_height = actual_h;
-
- /* set drm mode data. */
- overlay->mode_width = mode->hdisplay;
- overlay->mode_height = mode->vdisplay;
- overlay->refresh = mode->vrefresh;
- overlay->scan_flag = mode->flags;
-
- DRM_DEBUG_KMS("overlay : offset_x/y(%d,%d), width/height(%d,%d)",
- overlay->crtc_x, overlay->crtc_y,
- overlay->crtc_width, overlay->crtc_height);
-
- return 0;
-}
-
-static int exynos_drm_crtc_update(struct drm_crtc *crtc)
-{
- struct exynos_drm_crtc *exynos_crtc;
- struct exynos_drm_overlay *overlay;
- struct exynos_drm_crtc_pos pos;
- struct drm_display_mode *mode = &crtc->mode;
- struct drm_framebuffer *fb = crtc->fb;
-
- if (!mode || !fb)
- return -EINVAL;
-
- exynos_crtc = to_exynos_crtc(crtc);
- overlay = get_exynos_drm_overlay(exynos_crtc->plane);
-
- memset(&pos, 0, sizeof(struct exynos_drm_crtc_pos));
-
- /* it means the offset of framebuffer to be displayed. */
- pos.fb_x = crtc->x;
- pos.fb_y = crtc->y;
-
- /* OSD position to be displayed. */
- pos.crtc_x = 0;
- pos.crtc_y = 0;
- pos.crtc_w = fb->width - crtc->x;
- pos.crtc_h = fb->height - crtc->y;
- pos.src_w = pos.crtc_w;
- pos.src_h = pos.crtc_h;
-
- return exynos_drm_overlay_update(overlay, crtc->fb, mode, &pos);
-}
-
static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
{
struct drm_device *dev = crtc
[PATCH 04/11] drm/exynos: use private plane for crtc
The crtc can use private plane instead it has overlay struct. It will be
helpful use plane feature from crtc later.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 31 -
drivers/gpu/drm/exynos/exynos_drm_crtc.h |2 -
drivers/gpu/drm/exynos/exynos_drm_drv.c |7 -
drivers/gpu/drm/exynos/exynos_drm_plane.c | 34
drivers/gpu/drm/exynos/exynos_drm_plane.h |4 ++-
5 files changed, 47 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 0dd7c2e..0dda0de 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -29,11 +29,12 @@
#include "drmP.h"
#include "drm_crtc_helper.h"
-#include "exynos_drm_crtc.h"
#include "exynos_drm_drv.h"
+#include "exynos_drm_crtc.h"
#include "exynos_drm_fb.h"
#include "exynos_drm_encoder.h"
#include "exynos_drm_gem.h"
+#include "exynos_drm_plane.h"
#define to_exynos_crtc(x) container_of(x, struct exynos_drm_crtc,\
drm_crtc)
@@ -42,8 +43,7 @@
* Exynos specific crtc structure.
*
* @drm_crtc: crtc object.
- * @overlay: contain information common to display controller and hdmi and
- * contents of this overlay object would be copied to sub driver size.
+ * @drm_plane: pointer of private plane object for this crtc
* @pipe: a crtc index created at load() with a new crtc object creation
* and the crtc object would be set to private->crtc array
* to get a crtc object corresponding to this pipe from private->crtc
@@ -55,7 +55,7 @@
*/
struct exynos_drm_crtc {
struct drm_crtc drm_crtc;
- struct exynos_drm_overlay overlay;
+ struct drm_plane*plane;
unsigned intpipe;
unsigned intdpms;
};
@@ -63,7 +63,8 @@ struct exynos_drm_crtc {
static void exynos_drm_crtc_apply(struct drm_crtc *crtc)
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
- struct exynos_drm_overlay *overlay = &exynos_crtc->overlay;
+ struct exynos_drm_overlay *overlay =
+ get_exynos_drm_overlay(exynos_crtc->plane);
exynos_drm_fn_encoder(crtc, overlay,
exynos_drm_encoder_crtc_mode_set);
@@ -141,7 +142,7 @@ static int exynos_drm_crtc_update(struct drm_crtc *crtc)
return -EINVAL;
exynos_crtc = to_exynos_crtc(crtc);
- overlay = &exynos_crtc->overlay;
+ overlay = get_exynos_drm_overlay(exynos_crtc->plane);
memset(&pos, 0, sizeof(struct exynos_drm_crtc_pos));
@@ -250,7 +251,8 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode,
struct drm_framebuffer *old_fb)
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
- struct exynos_drm_overlay *overlay = &exynos_crtc->overlay;
+ struct exynos_drm_overlay *overlay =
+ get_exynos_drm_overlay(exynos_crtc->plane);
int pipe = exynos_crtc->pipe;
int ret;
@@ -378,14 +380,6 @@ static struct drm_crtc_funcs exynos_crtc_funcs = {
.destroy= exynos_drm_crtc_destroy,
};
-struct exynos_drm_overlay *get_exynos_drm_overlay(struct drm_device *dev,
- struct drm_crtc *crtc)
-{
- struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-
- return &exynos_crtc->overlay;
-}
-
int exynos_drm_crtc_create(struct drm_device *dev, unsigned int nr)
{
struct exynos_drm_crtc *exynos_crtc;
@@ -402,7 +396,12 @@ int exynos_drm_crtc_create(struct drm_device *dev,
unsigned int nr)
exynos_crtc->pipe = nr;
exynos_crtc->dpms = DRM_MODE_DPMS_OFF;
- exynos_crtc->overlay.zpos = DEFAULT_ZPOS;
+ exynos_crtc->plane = exynos_plane_init(dev, 1 << nr, true);
+ if (!exynos_crtc->plane) {
+ kfree(exynos_crtc);
+ return -ENOMEM;
+ }
+
crtc = &exynos_crtc->drm_crtc;
private->crtc[nr] = crtc;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 16b8e21..b1c6e83 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -29,8 +29,6 @@
#ifndef _EXYNOS_DRM_CRTC_H_
#define _EXYNOS_DRM_CRTC_H_
-struct exynos_drm_overlay *get_exynos_drm_overlay(struct drm_device *dev,
- struct drm_crtc *crtc);
int exynos_drm_crtc_create(struct drm_device *dev, unsigned int nr);
int exynos_drm_crtc_enable_vblank(struct drm_device *dev, int crtc);
void exynos_drm_crtc_disable_vblank(struct drm_device *dev, int crtc);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index d6de2e0..e313dc2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
[PATCH 03/11] drm/exynos: define to_exynos_plane macro
Add macro to get struct exynos_plane from struct drm_plane pointer.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index c4c6525..17510f5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -16,6 +16,8 @@
#include "exynos_drm_drv.h"
#include "exynos_drm_encoder.h"
+#define to_exynos_plane(x) container_of(x, struct exynos_plane, base)
+
struct exynos_plane {
struct drm_planebase;
struct exynos_drm_overlay overlay;
@@ -37,8 +39,7 @@ exynos_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
uint32_t src_x, uint32_t src_y,
uint32_t src_w, uint32_t src_h)
{
- struct exynos_plane *exynos_plane =
- container_of(plane, struct exynos_plane, base);
+ struct exynos_plane *exynos_plane = to_exynos_plane(plane);
struct exynos_drm_overlay *overlay = &exynos_plane->overlay;
struct exynos_drm_crtc_pos pos;
int ret;
@@ -73,8 +74,7 @@ exynos_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
static int exynos_disable_plane(struct drm_plane *plane)
{
- struct exynos_plane *exynos_plane =
- container_of(plane, struct exynos_plane, base);
+ struct exynos_plane *exynos_plane = to_exynos_plane(plane);
struct exynos_drm_overlay *overlay = &exynos_plane->overlay;
DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
@@ -93,8 +93,7 @@ static int exynos_disable_plane(struct drm_plane *plane)
static void exynos_plane_destroy(struct drm_plane *plane)
{
- struct exynos_plane *exynos_plane =
- container_of(plane, struct exynos_plane, base);
+ struct exynos_plane *exynos_plane = to_exynos_plane(plane);
DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
@@ -161,7 +160,7 @@ int exynos_plane_set_zpos_ioctl(struct drm_device *dev,
void *data,
}
plane = obj_to_plane(obj);
- exynos_plane = container_of(plane, struct exynos_plane, base);
+ exynos_plane = to_exynos_plane(plane);
exynos_plane->overlay.zpos = zpos_req->zpos;
--
1.7.5.4
[PATCH 02/11] drm/exynos: fix to set pipe of crtc
It is enough to set pipe of crtc to manager only when do mode_set of
crtc.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c|8 +++---
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 33 +++---
drivers/gpu/drm/exynos/exynos_drm_encoder.h |1 +
3 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 0b3b2af..0dd7c2e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -67,8 +67,7 @@ static void exynos_drm_crtc_apply(struct drm_crtc *crtc)
exynos_drm_fn_encoder(crtc, overlay,
exynos_drm_encoder_crtc_mode_set);
- exynos_drm_fn_encoder(crtc, &exynos_crtc->pipe,
- exynos_drm_encoder_crtc_commit);
+ exynos_drm_fn_encoder(crtc, NULL, exynos_drm_encoder_crtc_commit);
}
int exynos_drm_overlay_update(struct exynos_drm_overlay *overlay,
@@ -231,8 +230,7 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
exynos_drm_encoder_dpms_from_crtc);
}
- exynos_drm_fn_encoder(crtc, &exynos_crtc->pipe,
- exynos_drm_encoder_crtc_commit);
+ exynos_drm_fn_encoder(crtc, NULL, exynos_drm_encoder_crtc_commit);
}
static bool
@@ -253,6 +251,7 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode,
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct exynos_drm_overlay *overlay = &exynos_crtc->overlay;
+ int pipe = exynos_crtc->pipe;
int ret;
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -268,6 +267,7 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode,
return ret;
exynos_drm_fn_encoder(crtc, overlay, exynos_drm_encoder_crtc_mode_set);
+ exynos_drm_fn_encoder(crtc, &pipe, exynos_drm_encoder_crtc_pipe);
return 0;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index a47b64c..f0e4ac0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -30,7 +30,6 @@
#include "drm_crtc_helper.h"
#include "exynos_drm_drv.h"
-#include "exynos_drm_crtc.h"
#include "exynos_drm_encoder.h"
#define to_exynos_encoder(x) container_of(x, struct exynos_drm_encoder,\
@@ -303,8 +302,8 @@ void exynos_drm_enable_vblank(struct drm_encoder *encoder,
void *data)
struct exynos_drm_manager_ops *manager_ops = manager->ops;
int crtc = *(int *)data;
- if (manager->pipe == -1)
- manager->pipe = crtc;
+ if (manager->pipe != crtc)
+ return;
if (manager_ops->enable_vblank)
manager_ops->enable_vblank(manager->dev);
@@ -317,8 +316,8 @@ void exynos_drm_disable_vblank(struct drm_encoder *encoder,
void *data)
struct exynos_drm_manager_ops *manager_ops = manager->ops;
int crtc = *(int *)data;
- if (manager->pipe == -1)
- manager->pipe = crtc;
+ if (manager->pipe != crtc)
+ return;
if (manager_ops->disable_vblank)
manager_ops->disable_vblank(manager->dev);
@@ -341,19 +340,10 @@ void exynos_drm_encoder_crtc_plane_commit(struct
drm_encoder *encoder,
void exynos_drm_encoder_crtc_commit(struct drm_encoder *encoder, void *data)
{
- struct exynos_drm_manager *manager =
- to_exynos_encoder(encoder)->manager;
- int crtc = *(int *)data;
int zpos = DEFAULT_ZPOS;
DRM_DEBUG_KMS("%s\n", __FILE__);
- /*
-* when crtc is detached from encoder, this pipe is used
-* to select manager operation
-*/
- manager->pipe = crtc;
-
exynos_drm_encoder_crtc_plane_commit(encoder, &zpos);
}
@@ -429,3 +419,18 @@ void exynos_drm_encoder_crtc_disable(struct drm_encoder
*encoder, void *data)
if (overlay_ops && overlay_ops->disable)
overlay_ops->disable(manager->dev, zpos);
}
+
+void exynos_drm_encoder_crtc_pipe(struct drm_encoder *encoder, void *data)
+{
+ struct exynos_drm_manager *manager =
+ to_exynos_encoder(encoder)->manager;
+ int pipe = *(int *)data;
+
+ DRM_DEBUG_KMS("%s\n", __FILE__);
+
+ /*
+* when crtc is detached from encoder, this pipe is used
+* to select manager operation
+*/
+ manager->pipe = pipe;
+}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.h
b/drivers/gpu/drm/exynos/exynos_drm_encoder.h
index eb7d231..14dab25 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.h
@@ -48,5 +48,6 @@ void exynos_drm_encoder_dpms_from_crtc(struct drm_encoder
*encoder,
void exynos_drm_encoder_crtc_dpms(struct drm_encoder *encoder, void *data);
void exy
[PATCH 01/11] drm/exynos: fix point to call overlay_ops->mode_set
Call overlay->mode_set from crtc->mode_set instead of encoder->mode_set,
it makes codes clearly.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c| 12 +++-
drivers/gpu/drm/exynos/exynos_drm_encoder.c |9 +
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 4afb625..0b3b2af 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -251,6 +251,10 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode,
struct drm_display_mode *adjusted_mode, int x, int y,
struct drm_framebuffer *old_fb)
{
+ struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+ struct exynos_drm_overlay *overlay = &exynos_crtc->overlay;
+ int ret;
+
DRM_DEBUG_KMS("%s\n", __FILE__);
/*
@@ -259,7 +263,13 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct
drm_display_mode *mode,
*/
memcpy(&crtc->mode, adjusted_mode, sizeof(*adjusted_mode));
- return exynos_drm_crtc_update(crtc);
+ ret = exynos_drm_crtc_update(crtc);
+ if (ret)
+ return ret;
+
+ exynos_drm_fn_encoder(crtc, overlay, exynos_drm_encoder_crtc_mode_set);
+
+ return 0;
}
static int exynos_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 23d5ad3..a47b64c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -136,21 +136,14 @@ static void exynos_drm_encoder_mode_set(struct
drm_encoder *encoder,
struct drm_connector *connector;
struct exynos_drm_manager *manager = exynos_drm_get_manager(encoder);
struct exynos_drm_manager_ops *manager_ops = manager->ops;
- struct exynos_drm_overlay_ops *overlay_ops = manager->overlay_ops;
- struct exynos_drm_overlay *overlay = get_exynos_drm_overlay(dev,
- encoder->crtc);
DRM_DEBUG_KMS("%s\n", __FILE__);
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
- if (connector->encoder == encoder) {
+ if (connector->encoder == encoder)
if (manager_ops && manager_ops->mode_set)
manager_ops->mode_set(manager->dev,
adjusted_mode);
-
- if (overlay_ops && overlay_ops->mode_set)
- overlay_ops->mode_set(manager->dev, overlay);
- }
}
}
--
1.7.5.4
[PATCH 0/11] drm/exynos: update crtc and plane
This patchset is about update of crtc and plane. The interface of crtc and plane to control overlay is integrated internally. For this some code fixings are added. Also this supports the exynos specific property for crtc and plane. Joonyoung Shim (11): drm/exynos: fix point to call overlay_ops->mode_set drm/exynos: fix to set pipe of crtc drm/exynos: define to_exynos_plane macro drm/exynos: use private plane for crtc drm/exynos: update overlay via plane from crtc drm/exynos: add property for plane zpos drm/exynos: fix dpms operation for mode set drm/exynos: remove unnecessary connector dpms control drm/exynos: add plane enable/disable drm/exynos: add crtc disable function drm/exynos: add property for crtc mode drivers/gpu/drm/exynos/exynos_drm_crtc.c| 294 --- drivers/gpu/drm/exynos/exynos_drm_crtc.h| 31 --- drivers/gpu/drm/exynos/exynos_drm_drv.c |9 +- drivers/gpu/drm/exynos/exynos_drm_drv.h |4 + drivers/gpu/drm/exynos/exynos_drm_encoder.c | 123 +-- drivers/gpu/drm/exynos/exynos_drm_encoder.h | 12 +- drivers/gpu/drm/exynos/exynos_drm_plane.c | 246 +++--- drivers/gpu/drm/exynos/exynos_drm_plane.h | 12 +- include/drm/exynos_drm.h|9 - 9 files changed, 373 insertions(+), 367 deletions(-) -- 1.7.5.4
[Bug 15078] [KMS] X1300 radeon boot failure
https://bugzilla.kernel.org/show_bug.cgi?id=15078 --- Comment #9 from Tom?? Trnka 2012-06-27 14:18:18 --- KMS works just fine for me for a long time now (can't say exactly since when, but it's more than a year), I just forgot about this bug. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] drm/radeon: improve GPU lockup debugging info on r6xx/r7xx/r8xx/r9xx
On Wed, Jun 27, 2012 at 12:25 PM, wrote:
> From: Jerome Glisse
>
> Print various CP register that have valuable informations regarding
> GPU lockup.
>
> Signed-off-by: Jerome Glisse
Reviewed-by: Alex Deucher
> ---
> ?drivers/gpu/drm/radeon/evergreen.c ?| ? 16
> ?drivers/gpu/drm/radeon/evergreend.h | ? ?4
> ?drivers/gpu/drm/radeon/ni.c ? ? ? ? | ? 16
> ?drivers/gpu/drm/radeon/nid.h ? ? ? ?| ? ?4
> ?drivers/gpu/drm/radeon/r600.c ? ? ? | ? 16
> ?drivers/gpu/drm/radeon/r600d.h ? ? ?| ? ?3 +++
> ?6 files changed, 59 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index 7fb3d2e..c3073f7 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -2188,6 +2188,14 @@ static int evergreen_gpu_soft_reset(struct
> radeon_device *rdev)
> ? ? ? ? ? ? ? ?RREG32(GRBM_STATUS_SE1));
> ? ? ? ?dev_info(rdev->dev, " ?SRBM_STATUS=0x%08X\n",
> ? ? ? ? ? ? ? ?RREG32(SRBM_STATUS));
> + ? ? ? dev_info(rdev->dev, " ?R_008674_CP_STALLED_STAT1 = 0x%08X\n",
> + ? ? ? ? ? ? ? RREG32(CP_STALLED_STAT1));
> + ? ? ? dev_info(rdev->dev, " ?R_008678_CP_STALLED_STAT2 = 0x%08X\n",
> + ? ? ? ? ? ? ? RREG32(CP_STALLED_STAT2));
> + ? ? ? dev_info(rdev->dev, " ?R_00867C_CP_BUSY_STAT ? ? = 0x%08X\n",
> + ? ? ? ? ? ? ? RREG32(CP_BUSY_STAT));
> + ? ? ? dev_info(rdev->dev, " ?R_008680_CP_STAT ? ? ? ? ?= 0x%08X\n",
> + ? ? ? ? ? ? ? RREG32(CP_STAT));
> ? ? ? ?evergreen_mc_stop(rdev, &save);
> ? ? ? ?if (evergreen_mc_wait_for_idle(rdev)) {
> ? ? ? ? ? ? ? ?dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
> @@ -2225,6 +2233,14 @@ static int evergreen_gpu_soft_reset(struct
> radeon_device *rdev)
> ? ? ? ? ? ? ? ?RREG32(GRBM_STATUS_SE1));
> ? ? ? ?dev_info(rdev->dev, " ?SRBM_STATUS=0x%08X\n",
> ? ? ? ? ? ? ? ?RREG32(SRBM_STATUS));
> + ? ? ? dev_info(rdev->dev, " ?R_008674_CP_STALLED_STAT1 = 0x%08X\n",
> + ? ? ? ? ? ? ? RREG32(CP_STALLED_STAT1));
> + ? ? ? dev_info(rdev->dev, " ?R_008678_CP_STALLED_STAT2 = 0x%08X\n",
> + ? ? ? ? ? ? ? RREG32(CP_STALLED_STAT2));
> + ? ? ? dev_info(rdev->dev, " ?R_00867C_CP_BUSY_STAT ? ? = 0x%08X\n",
> + ? ? ? ? ? ? ? RREG32(CP_BUSY_STAT));
> + ? ? ? dev_info(rdev->dev, " ?R_008680_CP_STAT ? ? ? ? ?= 0x%08X\n",
> + ? ? ? ? ? ? ? RREG32(CP_STAT));
> ? ? ? ?evergreen_mc_resume(rdev, &save);
> ? ? ? ?return 0;
> ?}
> diff --git a/drivers/gpu/drm/radeon/evergreend.h
> b/drivers/gpu/drm/radeon/evergreend.h
> index b50b15c..d3bd098 100644
> --- a/drivers/gpu/drm/radeon/evergreend.h
> +++ b/drivers/gpu/drm/radeon/evergreend.h
> @@ -88,6 +88,10 @@
> ?#define ? ? ? ?CONFIG_MEMSIZE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x5428
>
> ?#define ? ? ? ?CP_COHER_BASE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x85F8
> +#define ? ? ? ?CP_STALLED_STAT1 ? ? ? ? ? ? ? ? ? ? ? ?0x8674
> +#define ? ? ? ?CP_STALLED_STAT2 ? ? ? ? ? ? ? ? ? ? ? ?0x8678
> +#define ? ? ? ?CP_BUSY_STAT ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x867C
> +#define ? ? ? ?CP_STAT ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x8680
> ?#define CP_ME_CNTL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x86D8
> ?#define ? ? ? ? ? ? ? ?CP_ME_HALT ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(1 <<
> 28)
> ?#define ? ? ? ? ? ? ? ?CP_PFP_HALT ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (1 <<
> 26)
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index b7bf18e..dc2e34d 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -1132,6 +1132,14 @@ static int cayman_gpu_soft_reset(struct radeon_device
> *rdev)
> ? ? ? ? ? ? ? ?RREG32(GRBM_STATUS_SE1));
> ? ? ? ?dev_info(rdev->dev, " ?SRBM_STATUS=0x%08X\n",
> ? ? ? ? ? ? ? ?RREG32(SRBM_STATUS));
> + ? ? ? dev_info(rdev->dev, " ?R_008674_CP_STALLED_STAT1 = 0x%08X\n",
> + ? ? ? ? ? ? ? RREG32(CP_STALLED_STAT1));
> + ? ? ? dev_info(rdev->dev, " ?R_008678_CP_STALLED_STAT2 = 0x%08X\n",
> + ? ? ? ? ? ? ? RREG32(CP_STALLED_STAT2));
> + ? ? ? dev_info(rdev->dev, " ?R_00867C_CP_BUSY_STAT ? ? = 0x%08X\n",
> + ? ? ? ? ? ? ? RREG32(CP_BUSY_STAT));
> + ? ? ? dev_info(rdev->dev, " ?R_008680_CP_STAT ? ? ? ? ?= 0x%08X\n",
> + ? ? ? ? ? ? ? RREG32(CP_STAT));
> ? ? ? ?dev_info(rdev->dev, " ?VM_CONTEXT0_PROTECTION_FAULT_ADDR ? 0x%08X\n",
> ? ? ? ? ? ? ? ? RREG32(0x14F8));
> ? ? ? ?dev_info(rdev->dev, " ?VM_CONTEXT0_PROTECTION_FAULT_STATUS 0x%08X\n",
> @@ -1180,6 +1188,14 @@ static int cayman_gpu_soft_reset(struct radeon_device
> *rdev)
> ? ? ? ? ? ? ? ?RREG32(GRBM_STATUS_SE1));
> ? ? ? ?dev_info(rdev->dev, " ?SRBM_STATUS=0x%08X\n",
> ? ? ? ? ? ? ? ?RREG32(SRBM_STATUS));
> + ? ? ? dev_info(rdev->dev, " ?R_008674_CP_STALLED_STAT1 = 0x%08X\n",
> + ? ? ? ? ? ? ? RREG32(CP_STALLED_STAT1));
> + ? ? ? dev_info(rdev->dev, " ?R_008678_CP_STALLED_STAT2 = 0x%08X\n",
> + ? ? ? ? ? ? ? RREG32(CP_STALLED_STAT2));
> + ? ? ? dev_info(rdev->dev, " ?R_00867C_CP_BUSY_STAT ? ? = 0x%08X\n",
> + ? ? ? ? ? ? ? RREG32(CP_BUSY_STAT));
> + ? ? ? dev_info(rdev->dev, " ?R_008680_CP_STAT ? ? ? ? ?= 0x%08X\n",
> + ? ? ?
[PATCH] drm/radeon: disable any GPU activity after unrecovered lockup v5
From: Jerome Glisse
After unrecovered GPU lockup avoid any GPU activities to avoid
things like kernel segfault and alike to happen in any of the
path that assume hw is working.
The segfault is due to PCIE vram gart table being unmapped after
suspend in the GPU reset path. To avoid segault to happen and to
avoid further GPU activity if unsuccessful at reseting GPU we
use the accel_working boolean to transform ttm activities into
noop. It does not impact the module load path because in that
path ttm have an empty schedule queue and accel_working will be
set to true as soon as the gart table is in valid state. Because
ttm might have work queued it is better to use the accel working
then disabling radeon_bo ioctl.
To trigger the segfault launch a program that repeatly create bo
in ttm and let it run in background, then trigger gpu lockup from
another process.
This patch also for video mode restoring on r1xx,r2xx,r3xx,r4xx,
r5xx,rs4xx,rs6xx GPU even if GPU reset fail. When GPU reset fails
it is very likely (so far i never had it not working) that the
modesetting part of the GPU is still alive. So we can have a
chance to get kernel backtrace or other debugging informations
on the screen if we always restore the video mode.
v2: fix spelling error and disable accel before suspend and reenable
it after pcie gart initialization to be even more cautious about
possible segfault. Improve commit message
v3: Improve commit message to describe the video mode restoring no
matter what.
v4: Avoid issue after successfull GPU lockup recovery. Don't do noop
ttm move, instead report error if move needs bind or unbind or
fallback to memcpy. Don't restrict new bo domain instead refuse
to create new bo if gpu reset failed. Disable accel working
in gart vram table unpin thus we don't change the behavior of
the suspend path.
v5: Avoid set domain to also trigger noop bind/unbind, instead force
it to wait for GPU reset to go through or return failure if
gpu reset fails.
cc: stable at vger.kernel.org
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm/radeon/ni.c|2 +-
drivers/gpu/drm/radeon/r300.c |2 +-
drivers/gpu/drm/radeon/r520.c |2 +-
drivers/gpu/drm/radeon/r600.c |2 +-
drivers/gpu/drm/radeon/radeon_device.c |8 +---
drivers/gpu/drm/radeon/radeon_gart.c |1 +
drivers/gpu/drm/radeon/radeon_gem.c| 33
drivers/gpu/drm/radeon/radeon_ttm.c| 23 ++
drivers/gpu/drm/radeon/rs400.c |2 +-
drivers/gpu/drm/radeon/rs600.c |2 +-
drivers/gpu/drm/radeon/rs690.c |2 +-
drivers/gpu/drm/radeon/rv515.c |2 +-
drivers/gpu/drm/radeon/rv770.c |2 +-
drivers/gpu/drm/radeon/si.c|2 +-
15 files changed, 73 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index c3073f7..5f154e3 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3071,6 +3071,7 @@ static int evergreen_startup(struct radeon_device *rdev)
if (r)
return r;
}
+ rdev->accel_working = true;
evergreen_gpu_init(rdev);
r = evergreen_blit_init(rdev);
@@ -3145,7 +3146,6 @@ int evergreen_resume(struct radeon_device *rdev)
/* post card */
atom_asic_init(rdev->mode_info.atom_context);
- rdev->accel_working = true;
r = evergreen_startup(rdev);
if (r) {
DRM_ERROR("evergreen startup failed on resume\n");
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index dc2e34d..486faa8 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1245,6 +1245,7 @@ static int cayman_startup(struct radeon_device *rdev)
r = cayman_pcie_gart_enable(rdev);
if (r)
return r;
+ rdev->accel_working = true;
cayman_gpu_init(rdev);
r = evergreen_blit_init(rdev);
@@ -1337,7 +1338,6 @@ int cayman_resume(struct radeon_device *rdev)
/* post card */
atom_asic_init(rdev->mode_info.atom_context);
- rdev->accel_working = true;
r = cayman_startup(rdev);
if (r) {
DRM_ERROR("cayman startup failed on resume\n");
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 97722a3..206ac1f 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1358,6 +1358,7 @@ static int r300_startup(struct radeon_device *rdev)
if (r)
return r;
}
+ rdev->accel_working = true;
if (rdev->family == CHIP_R300 ||
rdev->family == CHIP_R350 ||
@@ -1426,7 +1427,6 @@ int r300_resume(struct radeon_device *rdev)
/* Initialize surface registers */
radeo
[PATCH] drm/radeon: disable any GPU activity after unrecovered lockup v4
From: Jerome Glisse
After unrecovered GPU lockup avoid any GPU activities to avoid
things like kernel segfault and alike to happen in any of the
path that assume hw is working.
The segfault is due to PCIE vram gart table being unmapped after
suspend in the GPU reset path. To avoid segault to happen and to
avoid further GPU activity if unsuccessful at reseting GPU we
use the accel_working boolean to transform ttm activities into
noop. It does not impact the module load path because in that
path ttm have an empty schedule queue and accel_working will be
set to true as soon as the gart table is in valid state. Because
ttm might have work queued it is better to use the accel working
then disabling radeon_bo ioctl.
To trigger the segfault launch a program that repeatly create bo
in ttm and let it run in background, then trigger gpu lockup from
another process.
This patch also for video mode restoring on r1xx,r2xx,r3xx,r4xx,
r5xx,rs4xx,rs6xx GPU even if GPU reset fail. When GPU reset fails
it is very likely (so far i never had it not working) that the
modesetting part of the GPU is still alive. So we can have a
chance to get kernel backtrace or other debugging informations
on the screen if we always restore the video mode.
v2: fix spelling error and disable accel before suspend and reenable
it after pcie gart initialization to be even more cautious about
possible segfault. Improve commit message
v3: Improve commit message to describe the video mode restoring no
matter what.
v4: Avoid issue after successfull GPU lockup recovery. Don't do noop
ttm move, instead report error if move needs bind or unbind or
fallback to memcpy. Don't restrict new bo domain instead refuse
to create new bo if gpu reset failed. Disable accel working
in gart vram table unpin thus we don't change the behavior of
the suspend path.
cc: stable at vger.kernel.org
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm/radeon/ni.c|2 +-
drivers/gpu/drm/radeon/r300.c |2 +-
drivers/gpu/drm/radeon/r520.c |2 +-
drivers/gpu/drm/radeon/r600.c |2 +-
drivers/gpu/drm/radeon/radeon_device.c |8 +---
drivers/gpu/drm/radeon/radeon_gart.c |1 +
drivers/gpu/drm/radeon/radeon_gem.c| 13 +
drivers/gpu/drm/radeon/radeon_ttm.c| 23 +++
drivers/gpu/drm/radeon/rs400.c |2 +-
drivers/gpu/drm/radeon/rs600.c |2 +-
drivers/gpu/drm/radeon/rs690.c |2 +-
drivers/gpu/drm/radeon/rv515.c |2 +-
drivers/gpu/drm/radeon/rv770.c |2 +-
drivers/gpu/drm/radeon/si.c|2 +-
15 files changed, 53 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index c3073f7..5f154e3 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3071,6 +3071,7 @@ static int evergreen_startup(struct radeon_device *rdev)
if (r)
return r;
}
+ rdev->accel_working = true;
evergreen_gpu_init(rdev);
r = evergreen_blit_init(rdev);
@@ -3145,7 +3146,6 @@ int evergreen_resume(struct radeon_device *rdev)
/* post card */
atom_asic_init(rdev->mode_info.atom_context);
- rdev->accel_working = true;
r = evergreen_startup(rdev);
if (r) {
DRM_ERROR("evergreen startup failed on resume\n");
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index dc2e34d..486faa8 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1245,6 +1245,7 @@ static int cayman_startup(struct radeon_device *rdev)
r = cayman_pcie_gart_enable(rdev);
if (r)
return r;
+ rdev->accel_working = true;
cayman_gpu_init(rdev);
r = evergreen_blit_init(rdev);
@@ -1337,7 +1338,6 @@ int cayman_resume(struct radeon_device *rdev)
/* post card */
atom_asic_init(rdev->mode_info.atom_context);
- rdev->accel_working = true;
r = cayman_startup(rdev);
if (r) {
DRM_ERROR("cayman startup failed on resume\n");
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 97722a3..206ac1f 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1358,6 +1358,7 @@ static int r300_startup(struct radeon_device *rdev)
if (r)
return r;
}
+ rdev->accel_working = true;
if (rdev->family == CHIP_R300 ||
rdev->family == CHIP_R350 ||
@@ -1426,7 +1427,6 @@ int r300_resume(struct radeon_device *rdev)
/* Initialize surface registers */
radeon_surface_init(rdev);
- rdev->accel_working = true;
r = r300_startup(rdev);
if (r) {
rdev->accel_working = false;
diff --git a/driver
Re: [PATCH 4/4] drm: Renesas SH Mobile DRM driver
On 06/27/2012 10:27 PM, Laurent Pinchart wrote: > Hi Lars-Peter, > > On Wednesday 27 June 2012 22:06:54 Lars-Peter Clausen wrote: >> On 06/27/2012 02:40 PM, Laurent Pinchart wrote: >>> Hi Lars-Peter, >>> >>> [...] >>> >>> Do you plan to post a v3 of your "DRM: Add DRM kms/fb cma helper" patch in >>> the near future ? >> >> Hi Laurent, >> >> I don't think there have been any changes since v2 except for adjusting to >> the renamed functions in Sascha's patch. I'll send a v3 tomorrow. > > OK, thanks. > > As Ville pointed out, we need to validate the offsets and make sure the frame > buffer fits in the GEM object(s). I don't think there's code in your patch to > do so, have you thought about where/how to implement that ? I think part of it needs to be done in the driver code, since the the generic code does not the specific buffer layout requirements imposed by the hardware. We can probably add some basic sanity checks for the buffer size though. - Lars ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] intel/decode: VERTEX_ELEMENT_STATE, 1 means valid
On Wed, 27 Jun 2012 10:02:35 -0700 Eric Anholt wrote: > Ben Widawsky writes: > > > The logic seemed to be inverse to me. > > > > Signed-off-by: Ben Widawsky > > Reviewed-by: Eric Anholt This patch was bonghits :-( My bad, I've fixed the problem upstream though which turned out to just be a missing GEN7 thing. -- Ben Widawsky, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] intel/decode: VERTEX_ELEMENT_STATE, 1 means valid
On Wed, 27 Jun 2012 10:02:35 -0700 Eric Anholt wrote: > Ben Widawsky writes: > > > The logic seemed to be inverse to me. > > > > Signed-off-by: Ben Widawsky > > Reviewed-by: Eric Anholt This patch was bonghits :-( My bad, I've fixed the problem upstream though which turned out to just be a missing GEN7 thing. -- Ben Widawsky, Intel Open Source Technology Center
exynos: fix buffer pitch calculation
Your patch missed signed-off-by and also please use text format. Thanks, Inki Dae From: Cooper Yuan [mailto:coopery...@gmail.com] Sent: Wednesday, June 27, 2012 4:11 AM To: dri-devel at lists.freedesktop.org Cc: inki.dae at samsung.com Subject: DRI: exynos: fix buffer pitch calculation --- drivers/gpu/drm/exynos/exynos_drm_gem.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c index 5c8b683..acb9f42 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c @@ -668,7 +668,7 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv, * with DRM_IOCTL_MODE_CREATE_DUMB command. */ - args->pitch = args->width * args->bpp >> 3; + args->pitch = args->width * ((args->bpp + 7) / 8); args->size = PAGE_ALIGN(args->pitch * args->height); exynos_gem_obj = exynos_drm_gem_create(dev, args->flags, args->size); -- 1.7.0.4 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120627/79e05a18/attachment-0001.html>
[Bug 51484] New: [i915g] piglit fbo-srgb fails since 45fc069600ddbfe07a0a0cd5280161a8c7c55dd0
https://bugs.freedesktop.org/show_bug.cgi?id=51484 Bug #: 51484 Summary: [i915g] piglit fbo-srgb fails since 45fc069600ddbfe07a0a0cd5280161a8c7c55dd0 Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/i915g AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: cme3...@gmail.com fbo-srgb crashs: http://paste.debian.net/hidden/b3827a62/ this bug also affects wined3d (for example http://www.pouet.net/prod.php?which=1221 in wine) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv7 03/15] v4l: vb2: add support for shared buffer (dma_buf)
Hi Dima, On Tuesday 26 June 2012 13:53:34 Dima Zavin wrote: > On Tue, Jun 26, 2012 at 2:40 AM, Hans Verkuil wrote: > > On Tue 26 June 2012 11:11:06 Laurent Pinchart wrote: > >> On Tuesday 26 June 2012 10:40:44 Tomasz Stanislawski wrote: > >> > Hi Dima Zavin, > >> > Thank you for the patch and for a ping remainder :). > >> > > >> > You are right. The unmap is missing in __vb2_queue_cancel. > >> > I will apply your fix into next version of V4L2 support for dmabuf. > >> > > >> > Please refer to some comments below. > >> > > >> > On 06/20/2012 08:12 AM, Dima Zavin wrote: > >> > > Tomasz, > >> > > > >> > > I've encountered an issue with this patch when userspace does several > >> > > stream_on/stream_off cycles. When the user tries to qbuf a buffer > >> > > after doing stream_off, we trigger the "dmabuf already pinned" > >> > > warning since we didn't unmap the buffer as dqbuf was never called. > >> > > > >> > > The below patch adds calls to unmap in queue_cancel, but my feeling > >> > > is that we probably should be calling detach too (i.e. put_dmabuf). > >> > >> According to the V4L2 specification, the "VIDIOC_STREAMOFF ioctl, apart > >> of aborting or finishing any DMA in progress, unlocks any user pointer > >> buffers locked in physical memory, and it removes all buffers from the > >> incoming and outgoing queues". > > > > Correct. And what that means in practice is that after a streamoff all > > buffers are returned to the state they had just before STREAMON was > > called. > > That can't be right. The buffers had to have been returned to the > state just *after REQBUFS*, not just *before STREAMON*. You need to > re-enqueue buffers before calling STREAMON. I assume that's what you > meant? Your interpretation is correct. > > So after STREAMOFF you can immediately queue all buffers again with QBUF > > and call STREAMON to restart streaming. No mmap or other operations > > should be required. This behavior must be kept. > > > > VIDIOC_REQBUFS() or a close() are the only two operations that will > > actually free the buffers completely. > > > > In practice, a STREAMOFF is either followed by a STREAMON at a later time, > > or almost immediately followed by REQBUFS or close() to tear down the > > buffers. So I don't think the buffers should be detached at streamoff. > > I agree. I was leaning this way which is why I left it out of my patch > and wanted to hear your guys' opinion as you are much more familiar > with the intended behavior than I am. > > Thanks! You're welcome. Thank you for reporting the problem and providing a patch. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] DRM: add drm gem cma helper
Hi Sascha, On Thursday 31 May 2012 10:08:54 Sascha Hauer wrote: > Many embedded drm devices do not have a IOMMU and no dedicated > memory for graphics. These devices use cma (Contiguous Memory > Allocator) backed graphics memory. This patch provides helper > functions to be able to share the code. Do you plan to post v3 in the near future ? I'm preparing the next version of the Renesas Mobile DRM driver, which will depend on this patch (as well as Lars-Peter's kms/fb cma helper). -- Regards, Laurent Pinchart
[PATCH] drm/i915/sprite: Fix mem leak in intel_plane_init()
On Tue, Jun 26, 2012 at 05:12:46PM -0700, Jesse Barnes wrote: > On Wed, 27 Jun 2012 00:55:37 +0200 (CEST) > Jesper Juhl wrote: > > > If we ever hit the default case in the switch statement we'll return > > from the function without freeing the memory we just allocated to > > 'intel_plane' (but that has not been used). > > > > This patch gets rid of the leak by freeing the memory just before we > > return. > > > > Signed-off-by: Jesper Juhl > > --- > > drivers/gpu/drm/i915/intel_sprite.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c > > b/drivers/gpu/drm/i915/intel_sprite.c > > index 2a20fb0..c8851ba 100644 > > --- a/drivers/gpu/drm/i915/intel_sprite.c > > +++ b/drivers/gpu/drm/i915/intel_sprite.c > > @@ -685,6 +685,7 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe) > > break; > > > > default: > > + kfree(intel_plane); > > return -ENODEV; > > } > > > > @@ -699,4 +700,3 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe) > > > > return ret; > > } > > Yeah, looks fine. I just fixed the same thing in a local tree (though > by using a goto since I added another path that could fail). > > Reviewed-by: Jesse Barnes Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
Tegra DRM device tree bindings
> On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > > On Tue, 26 Jun 2012 12:55:13 +0200 Thierry Reding
> > > wrote:
> > >> ...
> > I'm not sure I understand how information about the carveout
> > would be obtained from the IOMMU API, though.
> > >>>
> > >>> I think that can be similar with current gart implementation. Define
> carveout as:
> > >>>
> > >>> carveout {
> > >>> compatible = "nvidia,tegra20-carveout";
> > >>> size = <0x1000>;
> > >>> };
> > >>>
> > >>> Then create a file such like "tegra-carveout.c" to get these
> > >>> definitions and
> > >> register itself as platform device's iommu instance.
> > >>
> > >> The carveout isn't a HW object, so it doesn't seem appropriate to
> > >> define a DT node to represent it.
> > >
> > > Yes. But I think it's better to export the size of carveout as a
> > > configurable item.
> > > So we need to define this somewhere. How about define carveout as a
> property of gart?
> >
> > There already exists a way of preventing Linux from using certain
> > chunks of memory; the /memreserve/ syntax. From a brief look at the
> > dtc source, it looks like /memreserve/ entries can have labels, which
> > implies that a property in the GART node could refer to the
> > /memreserve/ entry by phandle in order to know what memory regions to use.
>
> Wasn't the whole point of using a carveout supposed to be a replacement for
> the
> GART? As such I'd think the carveout should rather be a property of the host1x
> device.
>
> AIUI what we want to do is have a large contiguous region of memory that a
> central component (host1x) manages as a pool from which clients (DRM, V4L,
> ...)
> can allocate buffers as needed. Since all of this memory will be contiguous
> anyway there isn't much use for the GART anymore.
>
I have the same understanding. We don't need GART anymore if carveout is
enabled.
I'm thinking that why we need to define a property and reference to global
/memreserve/ in GART or HOST1X node?
We can just define a label for /memreserve/, so we can distinguish these memory
reservations already in codes.
> But maybe I'm misunderstanding.
>
> Thierry
>
> * Unknown Key
> * 0x7F3EB3A1
Re: [PATCH 4/4] drm: Renesas SH Mobile DRM driver
Hi Lars-Peter, On Wednesday 27 June 2012 22:06:54 Lars-Peter Clausen wrote: > On 06/27/2012 02:40 PM, Laurent Pinchart wrote: > > Hi Lars-Peter, > > > > [...] > > > > Do you plan to post a v3 of your "DRM: Add DRM kms/fb cma helper" patch in > > the near future ? > > Hi Laurent, > > I don't think there have been any changes since v2 except for adjusting to > the renamed functions in Sascha's patch. I'll send a v3 tomorrow. OK, thanks. As Ville pointed out, we need to validate the offsets and make sure the frame buffer fits in the GEM object(s). I don't think there's code in your patch to do so, have you thought about where/how to implement that ? > I think it makes most sense if you carry these two patches (Sascha's and > mine) as part of your "Renesas SH Mobile DRM driver" series, so reviewers > can see it in context. OK I'll do that. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 10/10] WIP drm/i915: "Atomic" modeset test implementation
From: Ville Syrj?l?
Second attempt at the atomic modeset implementation. This versions does
things in a way that's closer to the drm_crtc_helper way. Not exactly
pretty, but there's too much code depending on that design to change it.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/intel_atomic.c | 1101 ++
drivers/gpu/drm/i915/intel_display.c |7 +
3 files changed, 1109 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_atomic.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 2e9268d..f97e7a4 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -15,6 +15,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o \
i915_gem_tiling.o \
i915_sysfs.o \
i915_trace_points.o \
+ intel_atomic.o \
intel_display.o \
intel_crt.o \
intel_lvds.o \
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
new file mode 100644
index 000..173721a
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -0,0 +1,1101 @@
+/*
+ */
+
+#include
+#include
+
+#include "intel_drv.h"
+
+static struct drm_property *prop_src_x;
+static struct drm_property *prop_src_y;
+static struct drm_property *prop_src_w;
+static struct drm_property *prop_src_h;
+static struct drm_property *prop_crtc_x;
+static struct drm_property *prop_crtc_y;
+static struct drm_property *prop_crtc_w;
+static struct drm_property *prop_crtc_h;
+static struct drm_property *prop_fb_id;
+static struct drm_property *prop_crtc_id;
+static struct drm_property *prop_mode_id;
+static struct drm_property *prop_connector_ids;
+
+struct intel_plane_state {
+ struct drm_plane *plane;
+ struct intel_plane_coords coords;
+ bool dirty;
+};
+
+struct intel_crtc_state {
+ struct drm_crtc *crtc;
+ struct drm_framebuffer *old_fb;
+ bool mode_dirty;
+ bool fb_dirty;
+ bool active_dirty;
+ unsigned long connectors_bitmask;
+ unsigned long encoders_bitmask;
+};
+
+struct intel_atomic_state {
+ struct intel_plane_state *plane;
+ struct intel_crtc_state *crtc;
+ bool dirty;
+ bool restore_hw;
+ struct drm_plane *saved_planes;
+ struct drm_crtc *saved_crtcs;
+ struct drm_connector *saved_connectors;
+ struct drm_encoder *saved_encoders;
+};
+
+static void update_connectors_bitmask(struct intel_crtc_state *st)
+{
+ struct drm_device *dev = st->crtc->dev;
+ struct drm_connector *connector;
+ unsigned int i;
+
+ st->connectors_bitmask = 0;
+
+ i = 0;
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ if (connector->encoder && connector->encoder->crtc == st->crtc)
+ __set_bit(i, &st->connectors_bitmask);
+
+ i++;
+ }
+}
+
+static void update_encoders_bitmask(struct intel_crtc_state *st)
+{
+ struct drm_device *dev = st->crtc->dev;
+ struct drm_encoder *encoder;
+ unsigned int i;
+
+ st->encoders_bitmask = 0;
+
+ i = 0;
+ list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
+ if (encoder->crtc == st->crtc)
+ __set_bit(i, &st->encoders_bitmask);
+
+ i++;
+ }
+}
+
+static int process_connectors(struct intel_crtc_state *s, const uint32_t *ids,
int count_ids)
+{
+ struct drm_crtc *crtc = s->crtc;
+ struct drm_device *dev = crtc->dev;
+ struct drm_connector *connectors[count_ids];
+ struct drm_connector *connector;
+ struct drm_encoder *encoder;
+ int i;
+
+ for (i = 0; i < count_ids; i++) {
+ struct drm_encoder *encoder;
+ const struct drm_connector_helper_funcs *connector_funcs;
+ struct drm_mode_object *obj;
+ int j;
+
+ /* don't accept duplicates */
+ for (j = i + 1; j < count_ids; j++)
+ if (ids[i] == ids[j])
+ return -EINVAL;
+
+ obj = drm_mode_object_find(dev, ids[i],
DRM_MODE_OBJECT_CONNECTOR);
+ if (!obj)
+ return -ENOENT;
+
+ connector = obj_to_connector(obj);
+ connector_funcs = connector->helper_private;
+
+ encoder = connector_funcs->best_encoder(connector);
+
+ if (!drm_encoder_crtc_ok(encoder, crtc))
+ return -EINVAL;
+
+ connectors[i] = connector;
+ }
+
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ const struct drm_connector_helper_funcs *connector_funcs =
+ connector->helper_private;
+
+ for (i = 0; i < count_ids; i++) {
+ if (connector == connectors[
[RFC][PATCH 09/10] drm/i915: Split clipping and checking from update_plane hook
From: Ville Syrj?l?
Split the update_plane() codepath into two separate steps. The first
step checkis and clips the plane, and the second step actually commits
the changes to the hardware. This allows the atomic modesetting code
to perform all checks before clobering hardware state.
The update_plane() hook is reduced to a thin wrapper calling both check
and commit functions.
Buffer (un)pinning is still being performed in the commit step. This
needs to be changed as well, so that the atomic modesetting code can
try to pin all new buffers before touching the hardware.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_drv.h| 15 +-
drivers/gpu/drm/i915/intel_sprite.c | 372 ++-
2 files changed, 249 insertions(+), 138 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 08fa52d..3e9506c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -187,6 +187,15 @@ struct intel_crtc {
struct intel_pch_pll *pch_pll;
};
+struct intel_plane_coords {
+ /* disabled or fully clipped? */
+ bool visible;
+ /* coordinates clipped against pipe dimensions */
+ int32_t crtc_x, crtc_y;
+ uint32_t crtc_w, crtc_h;
+ uint32_t src_x, src_y, src_w, src_h;
+};
+
struct intel_plane {
struct drm_plane base;
enum pipe pipe;
@@ -196,11 +205,7 @@ struct intel_plane {
u32 lut_r[1024], lut_g[1024], lut_b[1024];
void (*update_plane)(struct drm_plane *plane,
struct drm_framebuffer *fb,
-struct drm_i915_gem_object *obj,
-int crtc_x, int crtc_y,
-unsigned int crtc_w, unsigned int crtc_h,
-uint32_t x, uint32_t y,
-uint32_t src_w, uint32_t src_h);
+const struct intel_plane_coords *clip);
void (*disable_plane)(struct drm_plane *plane);
int (*update_colorkey)(struct drm_plane *plane,
struct drm_intel_sprite_colorkey *key);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index e2abae6..f2cdb05 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -36,16 +36,173 @@
#include "i915_drm.h"
#include "i915_drv.h"
+static bool
+format_is_yuv(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_YUYV:
+ case DRM_FORMAT_UYVY:
+ case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_YVYU:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static void intel_clip_plane(const struct drm_plane *plane,
+const struct drm_crtc *crtc,
+const struct drm_framebuffer *fb,
+struct intel_plane_coords *coords)
+{
+ const struct intel_plane *intel_plane = to_intel_plane(plane);
+ const struct drm_display_mode *mode = &crtc->mode;
+ int hscale, vscale;
+ struct drm_region src = {
+ .x1 = coords->src_x,
+ .x2 = coords->src_x + coords->src_w,
+ .y1 = coords->src_y,
+ .y2 = coords->src_y + coords->src_h,
+ };
+ struct drm_region dst = {
+ .x1 = coords->crtc_x,
+ .x2 = coords->crtc_x + coords->crtc_w,
+ .y1 = coords->crtc_y,
+ .y2 = coords->crtc_y + coords->crtc_h,
+ };
+ const struct drm_region clip = {
+ .x2 = mode->hdisplay,
+ .y2 = mode->vdisplay,
+ };
+
+ hscale = drm_calc_hscale(&src, &dst, 1, intel_plane->max_downscale <<
16);
+ vscale = drm_calc_vscale(&src, &dst, 1, intel_plane->max_downscale <<
16);
+
+ coords->visible = drm_region_clip_scaled(&src, &dst, &clip, hscale,
vscale);
+
+ coords->crtc_x = dst.x1;
+ coords->crtc_y = dst.y1;
+ coords->crtc_w = drm_region_width(&dst);
+ coords->crtc_h = drm_region_height(&dst);
+
+ /* HW doesn't seem to like smaller sprite, even when scaling */
+ /* FIXME return an error instead? */
+ if (coords->crtc_w < 3 || coords->crtc_h < 3)
+ coords->visible = false;
+
+ /*
+* Hardware doesn't handle subpixel coordinates.
+* Round to nearest (macro)pixel boundary.
+*/
+ if (format_is_yuv(fb->pixel_format)) {
+ coords->src_x = ((src.x1 + 0x1) >> 17) << 1;
+ coords->src_w = (((src.x2 + 0x1) >> 17) << 1) -
coords->src_x;
+ } else {
+ coords->src_x = (src.x1 + 0x8000) >> 16;
+ coords->src_w = ((src.x2 + 0x8000) >> 16) - coords->src_x;
+ }
+ coords->src_y = (src.y1 + 0x8000) >> 16;
+ coords->src_h = ((src.y2 + 0x8000) >> 16) - coords->src_y;
+
+ /* Account for minimum source si
[RFC][PATCH 08/10] WIP: drm: Atomic modeset ioctl
From: Ville Syrj?l?
First draft.
The ioctl simply takes a list of object IDs and property IDs and their
values. For setting values to blob properties, the property value
indicates the length of the data, and the actual data is passed via
another blob pointer.
Detailed error reporting is missing, as is completion event support.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 133
drivers/gpu/drm/drm_drv.c |1 +
include/drm/drm.h |1 +
include/drm/drmP.h |2 +
include/drm/drm_crtc.h | 12
include/drm/drm_mode.h | 14 +
6 files changed, 163 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index cfef9de..35f8882 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4201,3 +4201,136 @@ int drm_calc_vscale(struct drm_region *src, struct
drm_region *dst,
return vscale;
}
EXPORT_SYMBOL(drm_calc_vscale);
+
+int drm_mode_atomic_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+ struct drm_mode_atomic *arg = data;
+ uint32_t __user *objs_ptr = (uint32_t __user *)(unsigned
long)(arg->objs_ptr);
+ uint32_t __user *count_props_ptr = (uint32_t __user *)(unsigned
long)(arg->count_props_ptr);
+ uint32_t __user *props_ptr = (uint32_t __user *)(unsigned
long)(arg->props_ptr);
+ uint64_t __user *prop_values_ptr = (uint64_t __user *)(unsigned
long)(arg->prop_values_ptr);
+ uint64_t __user *blob_values_ptr = (uint64_t __user *)(unsigned
long)(arg->blob_values_ptr);
+ unsigned int copied_objs = 0;
+ unsigned int copied_props = 0;
+ unsigned int copied_blobs = 0;
+ void *state;
+ int ret = 0;
+ unsigned int i, j;
+
+ if (!dev->driver->atomic_funcs ||
+ !dev->driver->atomic_funcs->begin ||
+ !dev->driver->atomic_funcs->set ||
+ !dev->driver->atomic_funcs->check ||
+ !dev->driver->atomic_funcs->commit ||
+ !dev->driver->atomic_funcs->end)
+ return -ENOSYS;
+
+ if (arg->flags & ~DRM_ATOMIC_TEST_ONLY)
+ return -EINVAL;
+
+ mutex_lock(&dev->mode_config.mutex);
+
+ state = dev->driver->atomic_funcs->begin(dev, arg->flags);
+ if (IS_ERR(state)) {
+ ret = PTR_ERR(state);
+ goto unlock;
+ }
+
+ for (i = 0; i < arg->count_objs; i++) {
+ uint32_t obj_id, count_props;
+ struct drm_mode_object *obj;
+
+ if (get_user(obj_id, objs_ptr + copied_objs)) {
+ ret = -EFAULT;
+ goto out;
+ }
+
+ obj = drm_mode_object_find(dev, obj_id, DRM_MODE_OBJECT_ANY);
+ if (!obj || !obj->properties) {
+ ret = -ENOENT;
+ goto out;
+ }
+
+ if (get_user(count_props, count_props_ptr + copied_objs)) {
+ ret = -EFAULT;
+ goto out;
+ }
+
+ copied_objs++;
+
+ for (j = 0; j < count_props; j++) {
+ uint32_t prop_id;
+ uint64_t prop_value;
+ struct drm_mode_object *prop_obj;
+ struct drm_property *prop;
+ void *blob_data = NULL;
+
+ if (get_user(prop_id, props_ptr + copied_props)) {
+ ret = -EFAULT;
+ goto out;
+ }
+
+ if (!object_has_prop(obj, prop_id)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ prop_obj = drm_mode_object_find(dev, prop_id,
DRM_MODE_OBJECT_PROPERTY);
+ if (!prop_obj) {
+ ret = -ENOENT;
+ goto out;
+ }
+ prop = obj_to_property(prop_obj);
+
+ if (get_user(prop_value, prop_values_ptr +
copied_props)) {
+ ret = -EFAULT;
+ goto out;
+ }
+
+ if (!drm_property_change_is_valid(prop, prop_value)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (prop->flags & DRM_MODE_PROP_BLOB && prop_value) {
+ blob_data = kmalloc(prop_value, GFP_KERNEL);
+ if (!blob_data) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ if (copy_from_user(blob_data, blob_values_ptr +
copie
[RFC][PATCH 07/10] drm: Add MODE_IDS property to connectors
From: Ville Syrj?l?
Add a new blob property MODE_IDS to connectors. This property contains
a list a mode object IDs attached to the connector (either probed modes,
or user attached modes).
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c| 77 +
drivers/gpu/drm/drm_crtc_helper.c |1 +
include/drm/drm_crtc.h|2 +
3 files changed, 80 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 958a4b0..cfef9de 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -508,6 +508,9 @@ int drm_connector_init(struct drm_device *dev,
drm_connector_attach_property(connector,
dev->mode_config.dpms_property, 0);
+ drm_connector_attach_property(connector,
+ dev->mode_config.mode_ids_property, 0);
+
out:
mutex_unlock(&dev->mode_config.mutex);
@@ -713,6 +716,7 @@ static int
drm_mode_create_standard_connector_properties(struct drm_device *dev)
{
struct drm_property *edid;
struct drm_property *dpms;
+ struct drm_property *mode_ids;
/*
* Standard properties (apply to all connectors)
@@ -727,6 +731,11 @@ static int
drm_mode_create_standard_connector_properties(struct drm_device *dev)
ARRAY_SIZE(drm_dpms_enum_list));
dev->mode_config.dpms_property = dpms;
+ mode_ids = drm_property_create(dev, DRM_MODE_PROP_BLOB |
+ DRM_MODE_PROP_IMMUTABLE,
+ "MODE_IDS", 0);
+ dev->mode_config.mode_ids_property = mode_ids;
+
return 0;
}
@@ -2648,6 +2657,10 @@ int drm_mode_attachmode_ioctl(struct drm_device *dev,
}
drm_mode_attachmode(dev, connector, mode);
+
+ ret = drm_mode_connector_update_mode_ids_property(connector);
+ if (ret)
+ drm_mode_remove(connector, mode);
out:
mutex_unlock(&dev->mode_config.mutex);
return ret;
@@ -3144,6 +3157,70 @@ int drm_mode_connector_update_edid_property(struct
drm_connector *connector,
}
EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
+int drm_mode_connector_update_mode_ids_property(struct drm_connector
*connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_property_blob *blob = NULL;
+ struct drm_property_blob *old_blob = NULL;
+ struct drm_display_mode *mode;
+ uint64_t value;
+ int i = 0;
+ int ret;
+
+ ret = drm_connector_property_get_value(connector,
+
dev->mode_config.mode_ids_property,
+ &value);
+ if (ret)
+ return ret;
+
+ if (value) {
+ struct drm_mode_object *obj = drm_mode_object_find(dev, value,
DRM_MODE_OBJECT_BLOB);
+ if (!obj)
+ return -ENOENT;
+
+ old_blob = obj_to_blob(obj);
+ }
+
+ list_for_each_entry(mode, &connector->modes, head)
+ i++;
+ list_for_each_entry(mode, &connector->user_modes, head)
+ i++;
+
+ if (i) {
+ uint32_t *mode_ids = kcalloc(i, sizeof mode_ids[0], GFP_KERNEL);
+ if (!mode_ids)
+ return -ENOMEM;
+
+ i = 0;
+ list_for_each_entry(mode, &connector->modes, head)
+ mode_ids[i++] = mode->base.id;
+ list_for_each_entry(mode, &connector->user_modes, head)
+ mode_ids[i++] = mode->base.id;
+
+ blob = drm_property_create_blob(dev, i * sizeof mode_ids[0],
mode_ids);
+
+ kfree(mode_ids);
+
+ if (!blob)
+ return -ENOMEM;
+ }
+
+ ret = drm_connector_property_set_value(connector,
+
dev->mode_config.mode_ids_property,
+ blob ? blob->base.id : 0);
+ if (ret) {
+ if (blob)
+ drm_property_destroy_blob(dev, blob);
+ return ret;
+ }
+
+ if (old_blob)
+ drm_property_destroy_blob(dev, old_blob);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_mode_connector_update_mode_ids_property);
+
static bool range_property_is_signed(const struct drm_property *property)
{
return property->values[0] > property->values[1];
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index ebbfcc6..bc24c0e 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -131,6 +131,7 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
goto prune;
drm_mode_connector_list_update(connector);
+ drm_mode_connector_update_mode_ids_property
[RFC][PATCH 06/10] drm: Refactor object property check code
From: Ville Syrj?l?
Refactor the code to check whether an object has a specific property
to a new function.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 9945e4b..958a4b0 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3301,6 +3301,19 @@ out:
return ret;
}
+static bool object_has_prop(const struct drm_mode_object *obj, u32 prop_id)
+{
+ int i;
+
+ if (!obj->properties)
+ return false;
+
+ for (i = 0; i < obj->properties->count; i++)
+ if (obj->properties->ids[i] == prop_id)
+ return true;
+ return false;
+}
+
int drm_mode_obj_set_property_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
@@ -3309,7 +3322,6 @@ int drm_mode_obj_set_property_ioctl(struct drm_device
*dev, void *data,
struct drm_mode_object *prop_obj;
struct drm_property *property;
int ret = -EINVAL;
- int i;
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
@@ -3322,11 +3334,7 @@ int drm_mode_obj_set_property_ioctl(struct drm_device
*dev, void *data,
if (!arg_obj->properties)
goto out;
- for (i = 0; i < arg_obj->properties->count; i++)
- if (arg_obj->properties->ids[i] == arg->prop_id)
- break;
-
- if (i == arg_obj->properties->count)
+ if (!object_has_prop(arg_obj, arg->prop_id))
goto out;
prop_obj = drm_mode_object_find(dev, arg->prop_id,
--
1.7.3.4
[RFC][PATCH 05/10] drm: Export drm_crtc_prepare_encoders()
From: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc_helper.c |3 ++-
include/drm/drm_crtc_helper.h |1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index c4f7e7c..ebbfcc6 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -307,7 +307,7 @@ EXPORT_SYMBOL(drm_encoder_crtc_ok);
* CRTC. If they don't match, we have to disable the output and the CRTC
* since the driver will have to re-route things.
*/
-static void
+void
drm_crtc_prepare_encoders(struct drm_device *dev)
{
struct drm_encoder_helper_funcs *encoder_funcs;
@@ -324,6 +324,7 @@ drm_crtc_prepare_encoders(struct drm_device *dev)
drm_encoder_disable(encoder);
}
}
+EXPORT_SYMBOL(drm_crtc_prepare_encoders);
/**
* drm_crtc_set_mode - set a mode
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index 79bc76b..c88202d 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -168,5 +168,6 @@ extern void drm_kms_helper_poll_enable(struct drm_device
*dev);
extern bool drm_encoder_crtc_ok(struct drm_encoder *encoder,
struct drm_crtc *crtc);
+extern void drm_crtc_prepare_encoders(struct drm_device *dev);
#endif
--
1.7.3.4
[RFC][PATCH 04/10] drm: Export drm_encoder_crtc_ok
From: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc_helper.c |5 +++--
include/drm/drm_crtc_helper.h |3 +++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 3252e70..c4f7e7c 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -279,8 +279,8 @@ EXPORT_SYMBOL(drm_helper_disable_unused_functions);
*
* Return false if @encoder can't be driven by @crtc, true otherwise.
*/
-static bool drm_encoder_crtc_ok(struct drm_encoder *encoder,
- struct drm_crtc *crtc)
+bool drm_encoder_crtc_ok(struct drm_encoder *encoder,
+struct drm_crtc *crtc)
{
struct drm_device *dev;
struct drm_crtc *tmp;
@@ -300,6 +300,7 @@ static bool drm_encoder_crtc_ok(struct drm_encoder *encoder,
return true;
return false;
}
+EXPORT_SYMBOL(drm_encoder_crtc_ok);
/*
* Check the CRTC we're going to map each output to vs. its current
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index 7988e55..79bc76b 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -166,4 +166,7 @@ extern void drm_helper_hpd_irq_event(struct drm_device
*dev);
extern void drm_kms_helper_poll_disable(struct drm_device *dev);
extern void drm_kms_helper_poll_enable(struct drm_device *dev);
+extern bool drm_encoder_crtc_ok(struct drm_encoder *encoder,
+ struct drm_crtc *crtc);
+
#endif
--
1.7.3.4
[RFC][PATCH 03/10] drm: Allow drm_mode_object_find() to look up an object of any type
From: Ville Syrj?l?
To avoid having to pass object types from userspace for atomic mode
setting ioctl, allow drm_mode_object_find() to look up an object of any
type. This will only work as long as the all object types share the ID
space.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c |3 ++-
include/drm/drm_crtc.h |1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index cc18ae6..9945e4b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -268,7 +268,8 @@ struct drm_mode_object *drm_mode_object_find(struct
drm_device *dev,
mutex_lock(&dev->mode_config.idr_mutex);
obj = idr_find(&dev->mode_config.crtc_idr, id);
- if (!obj || (obj->type != type) || (obj->id != id))
+ if (!obj || (type != DRM_MODE_OBJECT_ANY && obj->type != type) ||
+ (obj->id != id))
obj = NULL;
mutex_unlock(&dev->mode_config.idr_mutex);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 0a2ebb4..99bd489 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -47,6 +47,7 @@ struct drm_object_properties;
#define DRM_MODE_OBJECT_FB 0xfbfbfbfb
#define DRM_MODE_OBJECT_BLOB 0x
#define DRM_MODE_OBJECT_PLANE 0x
+#define DRM_MODE_OBJECT_ANY 0
struct drm_mode_object {
uint32_t id;
--
1.7.3.4
[RFC][PATCH 02/10] drm: Allow signed values for range properties
From: Ville Syrj?l?
Treat a range property as signed when the unsigned minimum value is
larger than the unsigned maximum value.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ce0f446..cc18ae6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3143,14 +3143,25 @@ int drm_mode_connector_update_edid_property(struct
drm_connector *connector,
}
EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
-static bool drm_property_change_is_valid(struct drm_property *property,
+static bool range_property_is_signed(const struct drm_property *property)
+{
+ return property->values[0] > property->values[1];
+}
+
+static bool drm_property_change_is_valid(const struct drm_property *property,
uint64_t value)
{
if (property->flags & DRM_MODE_PROP_IMMUTABLE)
return false;
if (property->flags & DRM_MODE_PROP_RANGE) {
- if (value < property->values[0] || value > property->values[1])
- return false;
+ if (range_property_is_signed(property)) {
+ if ((int64_t)value < (int64_t)property->values[0] ||
+ (int64_t)value > (int64_t)property->values[1])
+ return false;
+ } else {
+ if (value < property->values[0] || value >
property->values[1])
+ return false;
+ }
return true;
} else if (property->flags & DRM_MODE_PROP_BITMASK) {
int i;
--
1.7.3.4
[RFC][PATCH 01/10] drm: Export drm_property_create_blob() and drm_property_destroy_blob()
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c |8 +---
include/drm/drm_crtc.h |4
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6dafb99..ce0f446 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3044,8 +3044,8 @@ done:
return ret;
}
-static struct drm_property_blob *drm_property_create_blob(struct drm_device
*dev, int length,
- void *data)
+struct drm_property_blob *drm_property_create_blob(struct drm_device *dev, int
length,
+ void *data)
{
struct drm_property_blob *blob;
int ret;
@@ -3070,14 +3070,16 @@ static struct drm_property_blob
*drm_property_create_blob(struct drm_device *dev
list_add_tail(&blob->head, &dev->mode_config.property_blob_list);
return blob;
}
+EXPORT_SYMBOL(drm_property_create_blob);
-static void drm_property_destroy_blob(struct drm_device *dev,
+void drm_property_destroy_blob(struct drm_device *dev,
struct drm_property_blob *blob)
{
drm_mode_object_put(dev, &blob->base);
list_del(&blob->head);
kfree(blob);
}
+EXPORT_SYMBOL(drm_property_destroy_blob);
int drm_mode_getblob_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 14bc68d..0a2ebb4 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -952,6 +952,10 @@ struct drm_property *drm_property_create_range(struct
drm_device *dev, int flags
const char *name,
uint64_t min, uint64_t max);
extern void drm_property_destroy(struct drm_device *dev, struct drm_property
*property);
+extern struct drm_property_blob *drm_property_create_blob(struct drm_device
*dev,
+ int length, void
*data);
+extern void drm_property_destroy_blob(struct drm_device *dev,
+ struct drm_property_blob *blob);
extern int drm_property_add_enum(struct drm_property *property, int index,
uint64_t value, const char *name);
extern int drm_mode_create_dvi_i_properties(struct drm_device *dev);
--
1.7.3.4
[RFC][PATCH 0/10] Atomic modesetting v2
Second version of the atomic mode setting work. Still very much work in progress. I decided that I can't afford to fight the drm_crtc_helper architecture due to the sheer amount of driver code depending on it. So I changed the code to do things in way that more closely matches drm_crtc_helper. Next I'll be moving the buffer pinning to happen before any hw state is clobbered. This will avoid having to do actual rollbacks when pinning fails. And a similar treatment needs to be done to the PLL calculations (those should be done before buffer pinning). I didn't re-post all the i915 specific bits I have in my tree since those didn't really change. I pushed the whole work to the drm_atomic_2 branch at https://gitorious.org/vsyrjala/linux.
[Bug 15217] NULL pointer dereference after resume-from-disk
https://bugzilla.kernel.org/show_bug.cgi?id=15217 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||UNREPRODUCIBLE -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] staging: drm/omap: update TODO
From: Rob Clark Update TODO file, which had been neglected. Signed-off-by: Rob Clark --- drivers/staging/omapdrm/TODO |7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/staging/omapdrm/TODO b/drivers/staging/omapdrm/TODO index 55b1837..938c788 100644 --- a/drivers/staging/omapdrm/TODO +++ b/drivers/staging/omapdrm/TODO @@ -1,9 +1,7 @@ TODO -. check error handling/cleanup paths -. add drm_plane / overlay support . add video decode/encode support (via syslink3 + codec-engine) -. still some rough edges with flipping.. event back to userspace should - really come after VSYNC interrupt + . NOTE: with dmabuf this probably could be split into different driver +so perhaps this TODO doesn't belong here . where should we do eviction (detatch_pages())? We aren't necessarily accessing the pages via a GART, so maybe we need some other threshold to put a cap on the # of pages that can be pin'd. (It is mostly only @@ -27,7 +25,6 @@ TODO CRTC's should be disabled, and on resume the LUT should be reprogrammed before CRTC's are re-enabled, to prevent DSS from trying to DMA from a buffer mapped in DMM/TILER before LUT is reloaded. -. Add debugfs information for DMM/TILER Userspace: . git://github.com/robclark/xf86-video-omap.git -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm: Renesas SH Mobile DRM driver
On 06/27/2012 02:40 PM, Laurent Pinchart wrote: > Hi Lars-Peter, > > [...] > > Do you plan to post a v3 of your "DRM: Add DRM kms/fb cma helper" patch in > the > near future ? Hi Laurent, I don't think there have been any changes since v2 except for adjusting to the renamed functions in Sascha's patch. I'll send a v3 tomorrow. I think it makes most sense if you carry these two patches (Sascha's and mine) as part of your "Renesas SH Mobile DRM driver" series, so reviewers can see it in context. - Lars ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 0/10] Atomic modesetting v2
On Wed, 2012-06-27 at 09:48 -0700, Jesse Barnes wrote: > The other thing I'm worried about with atomic mode setting is handling > the legacy case properly. We'll still need to handle apps that want to > change one CRTC at a time without altering the state of other CRTCs. Fortunately that's not true, you can flag-day it (per drm device even, if we want). If the first thing userspace asks for is atomic modeset then you simply disallow subsequent non-atomic modesets, and the reverse. Userspace code will need to grow atomic support anyway, so can simply treat -EINVAL from trying it as meaning "no kernel support, revert to the older thing". This does mean you have to update all of userspace to do the new call instead of the old one, but that's fine, there's only a handful of clients for this API. - ajax -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120627/061eb723/attachment.pgp>
Re: [PATCH] staging: drm/omap: add rotation properties
On Wed, Jun 27, 2012 at 2:40 PM, Greg KH wrote: > On Wed, Jun 27, 2012 at 09:06:26AM -0500, Rob Clark wrote: >> From: Rob Clark >> >> Use tiled buffers for rotated/reflected scanout, with CRTC and plane >> properties as the interface for userspace to configure rotation. >> >> Signed-off-by: Rob Clark >> --- >> drivers/staging/omapdrm/omap_crtc.c | 17 + >> drivers/staging/omapdrm/omap_dmm_tiler.c | 47 -- >> drivers/staging/omapdrm/omap_dmm_tiler.h | 17 - >> drivers/staging/omapdrm/omap_drv.c | 17 + >> drivers/staging/omapdrm/omap_drv.h | 32 +- >> drivers/staging/omapdrm/omap_fb.c | 99 >> +- >> drivers/staging/omapdrm/omap_gem.c | 43 - >> drivers/staging/omapdrm/omap_plane.c | 92 --- >> 8 files changed, 318 insertions(+), 46 deletions(-) > > That's great you are adding new features, but how goes the progress to > get this driver out of the drivers/staging/ area and moved to the real > part of the kernel? I don't want to keep taking new features without > seeing some progress on getting the code cleaned up and moved out first. Oh, heh, well I suppose the first thing to do is send a patch to clean up the TODO file.. I just noticed that I'd been forgetting to update it. BR, -R > thanks, > > greg k-h > -- > 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
[Bug 15078] [KMS] X1300 radeon boot failure
https://bugzilla.kernel.org/show_bug.cgi?id=15078 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||OBSOLETE --- Comment #8 from Alan 2012-06-27 12:57:12 --- Closing as obsolete, please update the bug if it is seen with a modern kernel -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 15030] screen connected to displayport is not detected - kms radeon
https://bugzilla.kernel.org/show_bug.cgi?id=15030 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution||OBSOLETE --- Comment #22 from Alan 2012-06-27 12:55:01 --- Closing as obsolete, if this is still seen with 3.2+ please update the bug -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
Re: [PATCH] staging: drm/omap: add rotation properties
On Wed, Jun 27, 2012 at 09:06:26AM -0500, Rob Clark wrote: > From: Rob Clark > > Use tiled buffers for rotated/reflected scanout, with CRTC and plane > properties as the interface for userspace to configure rotation. > > Signed-off-by: Rob Clark > --- > drivers/staging/omapdrm/omap_crtc.c | 17 + > drivers/staging/omapdrm/omap_dmm_tiler.c | 47 -- > drivers/staging/omapdrm/omap_dmm_tiler.h | 17 - > drivers/staging/omapdrm/omap_drv.c | 17 + > drivers/staging/omapdrm/omap_drv.h | 32 +- > drivers/staging/omapdrm/omap_fb.c| 99 > +- > drivers/staging/omapdrm/omap_gem.c | 43 - > drivers/staging/omapdrm/omap_plane.c | 92 --- > 8 files changed, 318 insertions(+), 46 deletions(-) That's great you are adding new features, but how goes the progress to get this driver out of the drivers/staging/ area and moved to the real part of the kernel? I don't want to keep taking new features without seeing some progress on getting the code cleaned up and moved out first. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] staging: drm/omap: add rotation properties
On Wed, Jun 27, 2012 at 09:06:26AM -0500, Rob Clark wrote: > From: Rob Clark > > Use tiled buffers for rotated/reflected scanout, with CRTC and plane > properties as the interface for userspace to configure rotation. > > Signed-off-by: Rob Clark > --- > drivers/staging/omapdrm/omap_crtc.c | 17 + > drivers/staging/omapdrm/omap_dmm_tiler.c | 47 -- > drivers/staging/omapdrm/omap_dmm_tiler.h | 17 - > drivers/staging/omapdrm/omap_drv.c | 17 + > drivers/staging/omapdrm/omap_drv.h | 32 +- > drivers/staging/omapdrm/omap_fb.c| 99 > +- > drivers/staging/omapdrm/omap_gem.c | 43 - > drivers/staging/omapdrm/omap_plane.c | 92 --- > 8 files changed, 318 insertions(+), 46 deletions(-) That's great you are adding new features, but how goes the progress to get this driver out of the drivers/staging/ area and moved to the real part of the kernel? I don't want to keep taking new features without seeing some progress on getting the code cleaned up and moved out first. thanks, greg k-h
[Bug 51344] massive corruption on RV410
https://bugs.freedesktop.org/show_bug.cgi?id=51344 --- Comment #4 from Tormod Volden 2012-06-27 12:33:37 PDT --- Sorry, I don't know when I can have time to do that. I'll try harder if the bug can be confirmed by other people too. Maybe the right developer can make an educated guess if it's limited to this card. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: disable any GPU activity after unrecovered lockup v3
From: Jerome Glisse
After unrecovered GPU lockup avoid any GPU activities to avoid
things like kernel segfault and alike to happen in any of the
path that assume hw is working.
The segfault is due to PCIE vram gart table being unmapped after
suspend in the GPU reset path. To avoid segault to happen and to
avoid further GPU activity if unsuccessful at reseting GPU we
use the accel_working boolean to transform ttm activities into
noop. It does not impact the module load path because in that
path ttm have an empty schedule queue and accel_working will be
set to true as soon as the gart table is in valid state. Because
ttm might have work queued it is better to use the accel working
then disabling radeon_bo ioctl.
To trigger the segfault launch a program that repeatly create bo
in ttm and let it run in background, then trigger gpu lockup from
another process.
This patch also for video mode restoring on r1xx,r2xx,r3xx,r4xx,
r5xx,rs4xx,rs6xx GPU even if GPU reset fail. When GPU reset fails
it is very likely (so far i never had it not working) that the
modesetting part of the GPU is still alive. So we can have a
chance to get kernel backtrace or other debugging informations
on the screen if we always restore the video mode.
v2: fix spelling error and disable accel before suspend and reenable
it after pcie gart initialization to be even more cautious about
possible segfault. Improve commit message
v3: Improve commit message to describe the video mode restoring no
matter what.
cc: stable at vger.kernel.org
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm/radeon/ni.c|2 +-
drivers/gpu/drm/radeon/r300.c |2 +-
drivers/gpu/drm/radeon/r520.c |2 +-
drivers/gpu/drm/radeon/r600.c |2 +-
drivers/gpu/drm/radeon/radeon_device.c |9 ---
drivers/gpu/drm/radeon/radeon_object.c |7 ++
drivers/gpu/drm/radeon/radeon_ttm.c| 41
drivers/gpu/drm/radeon/rs400.c |2 +-
drivers/gpu/drm/radeon/rs600.c |2 +-
drivers/gpu/drm/radeon/rs690.c |2 +-
drivers/gpu/drm/radeon/rv515.c |2 +-
drivers/gpu/drm/radeon/rv770.c |2 +-
drivers/gpu/drm/radeon/si.c|2 +-
drivers/gpu/drm/ttm/ttm_tt.c |1 +
15 files changed, 66 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index c3073f7..5f154e3 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3071,6 +3071,7 @@ static int evergreen_startup(struct radeon_device *rdev)
if (r)
return r;
}
+ rdev->accel_working = true;
evergreen_gpu_init(rdev);
r = evergreen_blit_init(rdev);
@@ -3145,7 +3146,6 @@ int evergreen_resume(struct radeon_device *rdev)
/* post card */
atom_asic_init(rdev->mode_info.atom_context);
- rdev->accel_working = true;
r = evergreen_startup(rdev);
if (r) {
DRM_ERROR("evergreen startup failed on resume\n");
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index dc2e34d..486faa8 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1245,6 +1245,7 @@ static int cayman_startup(struct radeon_device *rdev)
r = cayman_pcie_gart_enable(rdev);
if (r)
return r;
+ rdev->accel_working = true;
cayman_gpu_init(rdev);
r = evergreen_blit_init(rdev);
@@ -1337,7 +1338,6 @@ int cayman_resume(struct radeon_device *rdev)
/* post card */
atom_asic_init(rdev->mode_info.atom_context);
- rdev->accel_working = true;
r = cayman_startup(rdev);
if (r) {
DRM_ERROR("cayman startup failed on resume\n");
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 97722a3..206ac1f 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1358,6 +1358,7 @@ static int r300_startup(struct radeon_device *rdev)
if (r)
return r;
}
+ rdev->accel_working = true;
if (rdev->family == CHIP_R300 ||
rdev->family == CHIP_R350 ||
@@ -1426,7 +1427,6 @@ int r300_resume(struct radeon_device *rdev)
/* Initialize surface registers */
radeon_surface_init(rdev);
- rdev->accel_working = true;
r = r300_startup(rdev);
if (r) {
rdev->accel_working = false;
diff --git a/drivers/gpu/drm/radeon/r520.c b/drivers/gpu/drm/radeon/r520.c
index b5cf837..6409eb0 100644
--- a/drivers/gpu/drm/radeon/r520.c
+++ b/drivers/gpu/drm/radeon/r520.c
@@ -181,6 +181,7 @@ static int r520_startup(struct radeon_device *rdev)
if (r)
return r;
}
+ rdev->accel_working = true;
/* allocate w
[PATCH] drm/radeon: improve GPU lockup debugging info on r6xx/r7xx/r8xx/r9xx
From: Jerome Glisse
Print various CP register that have valuable informations regarding
GPU lockup.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c | 16
drivers/gpu/drm/radeon/evergreend.h |4
drivers/gpu/drm/radeon/ni.c | 16
drivers/gpu/drm/radeon/nid.h|4
drivers/gpu/drm/radeon/r600.c | 16
drivers/gpu/drm/radeon/r600d.h |3 +++
6 files changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 7fb3d2e..c3073f7 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2188,6 +2188,14 @@ static int evergreen_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(GRBM_STATUS_SE1));
dev_info(rdev->dev, " SRBM_STATUS=0x%08X\n",
RREG32(SRBM_STATUS));
+ dev_info(rdev->dev, " R_008674_CP_STALLED_STAT1 = 0x%08X\n",
+ RREG32(CP_STALLED_STAT1));
+ dev_info(rdev->dev, " R_008678_CP_STALLED_STAT2 = 0x%08X\n",
+ RREG32(CP_STALLED_STAT2));
+ dev_info(rdev->dev, " R_00867C_CP_BUSY_STAT = 0x%08X\n",
+ RREG32(CP_BUSY_STAT));
+ dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
+ RREG32(CP_STAT));
evergreen_mc_stop(rdev, &save);
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
@@ -2225,6 +2233,14 @@ static int evergreen_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(GRBM_STATUS_SE1));
dev_info(rdev->dev, " SRBM_STATUS=0x%08X\n",
RREG32(SRBM_STATUS));
+ dev_info(rdev->dev, " R_008674_CP_STALLED_STAT1 = 0x%08X\n",
+ RREG32(CP_STALLED_STAT1));
+ dev_info(rdev->dev, " R_008678_CP_STALLED_STAT2 = 0x%08X\n",
+ RREG32(CP_STALLED_STAT2));
+ dev_info(rdev->dev, " R_00867C_CP_BUSY_STAT = 0x%08X\n",
+ RREG32(CP_BUSY_STAT));
+ dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
+ RREG32(CP_STAT));
evergreen_mc_resume(rdev, &save);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/evergreend.h
b/drivers/gpu/drm/radeon/evergreend.h
index b50b15c..d3bd098 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -88,6 +88,10 @@
#defineCONFIG_MEMSIZE 0x5428
#defineCP_COHER_BASE 0x85F8
+#defineCP_STALLED_STAT10x8674
+#defineCP_STALLED_STAT20x8678
+#defineCP_BUSY_STAT0x867C
+#defineCP_STAT 0x8680
#define CP_ME_CNTL 0x86D8
#defineCP_ME_HALT (1 <<
28)
#defineCP_PFP_HALT (1 <<
26)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index b7bf18e..dc2e34d 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1132,6 +1132,14 @@ static int cayman_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(GRBM_STATUS_SE1));
dev_info(rdev->dev, " SRBM_STATUS=0x%08X\n",
RREG32(SRBM_STATUS));
+ dev_info(rdev->dev, " R_008674_CP_STALLED_STAT1 = 0x%08X\n",
+ RREG32(CP_STALLED_STAT1));
+ dev_info(rdev->dev, " R_008678_CP_STALLED_STAT2 = 0x%08X\n",
+ RREG32(CP_STALLED_STAT2));
+ dev_info(rdev->dev, " R_00867C_CP_BUSY_STAT = 0x%08X\n",
+ RREG32(CP_BUSY_STAT));
+ dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
+ RREG32(CP_STAT));
dev_info(rdev->dev, " VM_CONTEXT0_PROTECTION_FAULT_ADDR 0x%08X\n",
RREG32(0x14F8));
dev_info(rdev->dev, " VM_CONTEXT0_PROTECTION_FAULT_STATUS 0x%08X\n",
@@ -1180,6 +1188,14 @@ static int cayman_gpu_soft_reset(struct radeon_device
*rdev)
RREG32(GRBM_STATUS_SE1));
dev_info(rdev->dev, " SRBM_STATUS=0x%08X\n",
RREG32(SRBM_STATUS));
+ dev_info(rdev->dev, " R_008674_CP_STALLED_STAT1 = 0x%08X\n",
+ RREG32(CP_STALLED_STAT1));
+ dev_info(rdev->dev, " R_008678_CP_STALLED_STAT2 = 0x%08X\n",
+ RREG32(CP_STALLED_STAT2));
+ dev_info(rdev->dev, " R_00867C_CP_BUSY_STAT = 0x%08X\n",
+ RREG32(CP_BUSY_STAT));
+ dev_info(rdev->dev, " R_008680_CP_STAT = 0x%08X\n",
+ RREG32(CP_STAT));
evergreen_mc_resume(rdev, &save);
return 0;
}
diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
index a0b9806..870db34 100644
--- a/drivers/gpu/drm/radeon/nid.h
+++ b/drivers/gpu/drm/radeo
[patch -resend] drm/i915/bios: cleanup return type of intel_parse_bios()
These are unintuitive. These are type bool and return -1 casted to true
on failure. Let's just make it return an int. The callers don't care,
but let's change this as a cleanup.
Signed-off-by: Dan Carpenter
Acked-by: Daniel Vetter
---
Originally sent on Wed, Mar 28, 2012. This one is prossibly my fault.
I assumed these would be in the same tree, but apparently I should have
broken them out. Daniel acked the patch and told me that if I wanted to
I could break it up and he could merge part (or all of it?). I have no
problem with redoing patches but I understood that to mean it was going
to go through a someone else's tree with his Acked-by. If you give me
an option, of course I'm going to pick the laziest one. That is my firm
promise and commitment.
diff --git a/drivers/gpu/drm/gma500/intel_bios.h
b/drivers/gpu/drm/gma500/intel_bios.h
index 0a73866..2e95523 100644
--- a/drivers/gpu/drm/gma500/intel_bios.h
+++ b/drivers/gpu/drm/gma500/intel_bios.h
@@ -431,7 +431,7 @@ struct bdb_driver_features {
u8 custom_vbt_version;
} __attribute__((packed));
-extern bool psb_intel_init_bios(struct drm_device *dev);
+extern int psb_intel_init_bios(struct drm_device *dev);
extern void psb_intel_destroy_bios(struct drm_device *dev);
/*
diff --git a/drivers/gpu/drm/gma500/intel_bios.c
b/drivers/gpu/drm/gma500/intel_bios.c
index 973d7f6..8d7caf0 100644
--- a/drivers/gpu/drm/gma500/intel_bios.c
+++ b/drivers/gpu/drm/gma500/intel_bios.c
@@ -427,7 +427,7 @@ parse_device_mapping(struct drm_psb_private *dev_priv,
*
* Returns 0 on success, nonzero on failure.
*/
-bool psb_intel_init_bios(struct drm_device *dev)
+int psb_intel_init_bios(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = dev->dev_private;
struct pci_dev *pdev = dev->pdev;
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index dbda6e3..31c2107 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -476,7 +476,7 @@ struct bdb_edp {
} __attribute__ ((packed));
void intel_setup_bios(struct drm_device *dev);
-bool intel_parse_bios(struct drm_device *dev);
+int intel_parse_bios(struct drm_device *dev);
/*
* Driver<->VBIOS interaction occurs through scratch bits in
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 3534593..8c60741 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -692,7 +692,7 @@ static const struct dmi_system_id intel_no_opregion_vbt[] =
{
*
* Returns 0 on success, nonzero on failure.
*/
-bool
+int
intel_parse_bios(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
[PATCH] drm/i2c/ch7006: Convert to dev_pm_ops
On Wed, Jun 27, 2012 at 10:21:46AM +0100, Dave Airlie wrote: > Thanks for this and I like the fact its been posted 5 times but never > compiled once. It's hard to remember since it was so long ago that I wrote the patch but I rather suspect the reason this didn't happen is that it's actually fairly hard to enable for test builds as the relevant Kconfig is buried in a different directory (it's done as part of the Nouveau driver) with no immediate relationship with the code. That said... > Can you at least test compile it? ...it could also be that the build error I get when I enable CONFIG_DRM with -next is a long standing one: In file included from include/drm/drmP.h:75, from drivers/gpu/drm/drm_auth.c:36: include/drm/drm.h:47: fatal error: sys/ioccom.h: No such file or directory compilation terminated. make[3]: *** [drivers/gpu/drm/drm_auth.o] Error 1 The error here seems to be that you're relying on __linux__ to decide if you're building the kernel but that's not something you can rely on, we can build the kernel with a freestanding compiler and the compiler will only define this if it targets a Linux userspace. I happen to do pretty much all of my kernel builds with a freestanding compiler. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120627/c15510a4/attachment-0001.pgp>
[PATCH] drm/i2c/ch7006: Convert to dev_pm_ops
The I2C specific suspend and resume functions have been deprecated and
printing a warning on boot for over a year, dev_pm_ops should be used
instead so convert to that.
Also remove the suspend function since all it does is log.
Signed-off-by: Mark Brown
Acked-by: Francisco Jerez
---
drivers/gpu/drm/i2c/ch7006_drv.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c
index d3f2e87..0fb8742 100644
--- a/drivers/gpu/drm/i2c/ch7006_drv.c
+++ b/drivers/gpu/drm/i2c/ch7006_drv.c
@@ -427,15 +427,10 @@ static int ch7006_remove(struct i2c_client *client)
return 0;
}
-static int ch7006_suspend(struct i2c_client *client, pm_message_t mesg)
+static int ch7006_resume(struct device *dev)
{
- ch7006_dbg(client, "\n");
-
- return 0;
-}
+ struct i2c_client *client = to_i2c_client(dev);
-static int ch7006_resume(struct i2c_client *client)
-{
ch7006_dbg(client, "\n");
ch7006_write(client, 0x3d, 0x0);
@@ -499,15 +494,18 @@ static struct i2c_device_id ch7006_ids[] = {
};
MODULE_DEVICE_TABLE(i2c, ch7006_ids);
+static const struct dev_pm_ops ch7006_pm_ops = {
+ .resume = ch7006_resume,
+};
+
static struct drm_i2c_encoder_driver ch7006_driver = {
.i2c_driver = {
.probe = ch7006_probe,
.remove = ch7006_remove,
- .suspend = ch7006_suspend,
- .resume = ch7006_resume,
.driver = {
.name = "ch7006",
+ .pm = &ch7006_pm_ops,
},
.id_table = ch7006_ids,
--
1.7.10
