3.5-rc7: nouveau doesn't X on NVC0
On Thu, Sep 6, 2012 at 11:15 AM, Linus Torvalds wrote: > [ This got dropped somehow - it's in my draft folder. The bisection > may be irrelevant now: does it work with current git, since we've had > some nouveau changes? ] > > On Tue, Aug 28, 2012 at 8:26 AM, Alexey Dobriyan > wrote: >> Ping! >> >> No X for me with 3.6-rc2. Can you try -rc4? Ben thinks the pcopy fix should fix it. Dave.
[PATCH] drm/exynos: fix double call of drm_prime_(init/destroy)_file_private
Hi Mandeep, On 2012? 09? 06? 06:47, Mandeep Singh Baines wrote: > The double invocations are incorrect but seem to be safe so I don't > think this will fix any bugs. > > Before: > > [7.639366] drm_prime_init_file ee3675d0 > [7.639377] drm_prime_init_file ee3675d0 > [7.639507] drm_prime_destroy_file ee3675d0 > [7.639518] drm_prime_destroy_file ee3675d0 > [7.639802] drm_prime_init_file ee372390 > [7.639810] drm_prime_init_file ee372390 > [8.473316] drm_prime_init_file ee356390 > [8.473331] drm_prime_init_file ee356390 > > After: > > [6.363842] drm_prime_init_file edc2e5d0 > [6.363994] drm_prime_destroy_file edc2e5d0 > [6.364260] drm_prime_init_file edc2e750 > [8.004837] drm_prime_init_file ee36ded0 > You are right. prime file_priv is handled by drm_fops.c, so it can be removed from exynos drm. Thanks for your patch. > Signed-off-by: Mandeep Singh Baines > CC: St?phane Marchesin > CC: Pawel Osciak > CC: Inki Dae > CC: Joonyoung Shim > CC: Seung-Woo Kim > CC: Kyungmin Park > CC: David Airlie > CC: dri-devel at lists.freedesktop.org Acked-by: Seung-Woo Kim > --- > drivers/gpu/drm/exynos/exynos_drm_drv.c |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c > b/drivers/gpu/drm/exynos/exynos_drm_drv.c > index ebacec6..a27b8ff 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c > @@ -160,7 +160,6 @@ static int exynos_drm_open(struct drm_device *dev, struct > drm_file *file) > if (!file_priv) > return -ENOMEM; > > - drm_prime_init_file_private(&file->prime); > file->driver_priv = file_priv; > > return exynos_drm_subdrv_open(dev, file); > @@ -184,7 +183,6 @@ static void exynos_drm_preclose(struct drm_device *dev, > e->base.destroy(&e->base); > } > } > - drm_prime_destroy_file_private(&file->prime); > spin_unlock_irqrestore(&dev->event_lock, flags); > > exynos_drm_subdrv_close(dev, file); > -- Seung-Woo Kim Samsung Software R&D Center --
[PATCH] drm/exynos: fix double call of drm_prime_(init/destroy)_file_private
Hi, 2012/9/6 Mandeep Singh Baines : > The double invocations are incorrect but seem to be safe so I don't > think this will fix any bugs. > > Before: > > [7.639366] drm_prime_init_file ee3675d0 > [7.639377] drm_prime_init_file ee3675d0 > [7.639507] drm_prime_destroy_file ee3675d0 > [7.639518] drm_prime_destroy_file ee3675d0 > [7.639802] drm_prime_init_file ee372390 > [7.639810] drm_prime_init_file ee372390 > [8.473316] drm_prime_init_file ee356390 > [8.473331] drm_prime_init_file ee356390 > > After: > > [6.363842] drm_prime_init_file edc2e5d0 > [6.363994] drm_prime_destroy_file edc2e5d0 > [6.364260] drm_prime_init_file edc2e750 > [8.004837] drm_prime_init_file ee36ded0 > > Signed-off-by: Mandeep Singh Baines > CC: St?phane Marchesin > CC: Pawel Osciak > CC: Inki Dae > CC: Joonyoung Shim > CC: Seung-Woo Kim > CC: Kyungmin Park > CC: David Airlie > CC: dri-devel at lists.freedesktop.org remove all CCs and can you send it again using text mode? your patch is messed up when I try to get patch file. Thanks. Inki Dae > --- > drivers/gpu/drm/exynos/exynos_drm_drv.c |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c > b/drivers/gpu/drm/exynos/exynos_drm_drv.c > index ebacec6..a27b8ff 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c > @@ -160,7 +160,6 @@ static int exynos_drm_open(struct drm_device *dev, struct > drm_file *file) > if (!file_priv) > return -ENOMEM; > > - drm_prime_init_file_private(&file->prime); > file->driver_priv = file_priv; > > return exynos_drm_subdrv_open(dev, file); > @@ -184,7 +183,6 @@ static void exynos_drm_preclose(struct drm_device *dev, > e->base.destroy(&e->base); > } > } > - drm_prime_destroy_file_private(&file->prime); > spin_unlock_irqrestore(&dev->event_lock, flags); > > exynos_drm_subdrv_close(dev, file); > -- > 1.7.7.3 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/omap: update for interlaced
Hi Rob,
On Thu, Sep 6, 2012 at 3:18 AM, Rob Clark wrote:
> From: Rob Clark
>
> 'struct omap_video_timings' was updated w/ a 'bool interlaced'. Without
> a matching update in omap_connector, this field could have undefined
> values from the stack, which isn't quite ideal.
>
> Update the fxns to convert omapdss<->drm timings structs, and zero-init
> 'struct omap_video_timings' when it is declared on stack to avoid issues
> like this in the future.
>
> Signed-off-by: Rob Clark
Feel free to use
Reviewed-by: Sumit Semwal
> ---
> drivers/staging/omapdrm/omap_connector.c | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/staging/omapdrm/omap_connector.c
> b/drivers/staging/omapdrm/omap_connector.c
> index 5e2856c..5f4a89b 100644
> --- a/drivers/staging/omapdrm/omap_connector.c
> +++ b/drivers/staging/omapdrm/omap_connector.c
> @@ -48,13 +48,10 @@ static inline void copy_timings_omap_to_drm(struct
> drm_display_mode *mode,
> mode->vsync_end = mode->vsync_start + timings->vsw;
> mode->vtotal = mode->vsync_end + timings->vbp;
>
> - /* note: whether or not it is interlaced, +/- h/vsync, etc,
> -* which should be set in the mode flags, is not exposed in
> -* the omap_video_timings struct.. but hdmi driver tracks
> -* those separately so all we have to have to set the mode
> -* is the way to recover these timings values, and the
> -* omap_dss_driver would do the rest.
> -*/
> + mode->flags = 0;
> +
> + if (timings->interlace)
> + mode->flags |= DRM_MODE_FLAG_INTERLACE;
> }
>
> static inline void copy_timings_drm_to_omap(struct omap_video_timings
> *timings,
> @@ -71,6 +68,8 @@ static inline void copy_timings_drm_to_omap(struct
> omap_video_timings *timings,
> timings->vfp = mode->vsync_start - mode->vdisplay;
> timings->vsw = mode->vsync_end - mode->vsync_start;
> timings->vbp = mode->vtotal - mode->vsync_end;
> +
> + timings->interlace = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
> }
>
> static void omap_connector_dpms(struct drm_connector *connector, int mode)
> @@ -187,7 +186,7 @@ static int omap_connector_get_modes(struct drm_connector
> *connector)
> }
> } else {
> struct drm_display_mode *mode = drm_mode_create(dev);
> - struct omap_video_timings timings;
> + struct omap_video_timings timings = {0};
>
> dssdrv->get_timings(dssdev, &timings);
>
> @@ -291,7 +290,7 @@ void omap_connector_mode_set(struct drm_connector
> *connector,
> struct omap_connector *omap_connector = to_omap_connector(connector);
> struct omap_dss_device *dssdev = omap_connector->dssdev;
> struct omap_dss_driver *dssdrv = dssdev->driver;
> - struct omap_video_timings timings;
> + struct omap_video_timings timings = {0};
>
> copy_timings_drm_to_omap(&timings, mode);
>
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] drm/radeon: do not reenable crtc after moving vram start address
> On Wed, Sep 5, 2012 at 12:39 AM, Brad Campbell > wrote: >> On 28/07/12 04:32, j.glisse at gmail.com wrote: >>> >>> From: Jerome Glisse >>> >>> It seems we can not update the crtc scanout address. After disabling >>> crtc, update to base address do not take effect after crtc being >>> reenable leading to at least frame being scanout from the old crtc >>> base address. Disabling crtc display request lead to same behavior. >>> >>> So after changing the vram address if we don't keep crtc disabled >>> we will have the GPU trying to read some random system memory address >>> with some iommu this will broke the crtc engine and will lead to >>> broken display and iommu error message. >>> >>> So to avoid this, disable crtc. For flicker less boot we will need >>> to avoid moving the vram start address. >>> >>> This patch should also fix : >>> >>> https://bugs.freedesktop.org/show_bug.cgi?id=42373 >> >> >> G'day Jerome, >> >> I'm running a Mid 2011, iMac with three heads. Card : >> 01:00.0 VGA compatible controller: ATI Technologies Inc Device 6720 >> >> To make this usable (ie to not cook the machine), I must force the card into >> low power mode which I do with this patch : >> >> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c >> b/drivers/gpu/drm/radeon/radeon_pm.c >> index 6fabe89..de85eda 100644 >> --- a/drivers/gpu/drm/radeon/radeon_pm.c >> +++ b/drivers/gpu/drm/radeon/radeon_pm.c >> @@ -102,7 +102,7 @@ static void radeon_pm_update_profile(struct >> radeon_device *rdev) >>break; >>case PM_PROFILE_LOW: >>if (rdev->pm.active_crtc_count > 1) >> - rdev->pm.profile_index = PM_PROFILE_LOW_MH_IDX; >> + rdev->pm.profile_index = PM_PROFILE_LOW_SH_IDX; >>else >>rdev->pm.profile_index = PM_PROFILE_LOW_SH_IDX; >>break; >> >> The patch this mail refers to causes moving corruption (like noise) on about >> the right hand 1/3rd of the primary monitor. >> >> Reverting either of these patches makes the corruption go away, however >> reverting my patch makes the machine unusable as it simply cooks. >> >> I also have to revert : [PATCH] drm/radeon: fix bo creation retry path or >> the machine simply panics at X login, however I see that has already been >> queued for reversion. >> >> Any advice you could offer to assist me in sorting this would be much >> appreciated. >> >> Regards, >> Brad. > > Low profile is not suited to drive 2 monitors and hence is not supported. > > Cheers, > Jerome Thanks for that. I was naive enough to expect that answer, yet ask anyway. Is there anyone that can point me towards a configuration (three heads) with functioning power management? Regards, Brad
[Patch 0/1]drm_irq: Introducing the irq_thread support
> This possibly ought to be submitted in parallel with the code that uses it so
> that
> the whole proposal can be evaluated as one thing ?
>
> Alan
Patch is here, thanks.
From: liu chuansheng
Subject: [PATCH] drm_irq: Introducing the irq_thread support
For some GPUs, the irq handler need >1ms to handle the irq action.
And it will delay the whole system irq handler.
This patch is adding the irq thread support, it will make the drm_irq
interface more flexible.
The changes include:
1/ Change the request_irq to request_thread_irq, and add new callback
irq_handler_t;
2/ Normally we need IRQF_ONESHOT flag support for irq thread, so add
this option in drm_irq;
Cc: Shi Yang
Signed-off-by: liu chuansheng
---
drivers/gpu/drm/drm_irq.c |8 ++--
include/drm/drmP.h|2 ++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 03f16f3..bc105fe 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -345,13 +345,17 @@ int drm_irq_install(struct drm_device *dev)
if (drm_core_check_feature(dev, DRIVER_IRQ_SHARED))
sh_flags = IRQF_SHARED;
+ if (drm_core_check_feature(dev, DRIVER_IRQ_ONESHOT))
+ sh_flags |= IRQF_ONESHOT;
+
if (dev->devname)
irqname = dev->devname;
else
irqname = dev->driver->name;
- ret = request_irq(drm_dev_to_irq(dev), dev->driver->irq_handler,
- sh_flags, irqname, dev);
+ ret = request_threaded_irq(drm_dev_to_irq(dev),
+ dev->driver->irq_handler, dev->driver->irq_handler_t,
+ sh_flags, irqname, dev);
if (ret < 0) {
mutex_lock(&dev->struct_mutex);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index d6b67bb..b28be4b 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -152,6 +152,7 @@ int drm_err(const char *func, const char *format, ...);
#define DRIVER_GEM 0x1000
#define DRIVER_MODESET 0x2000
#define DRIVER_PRIME 0x4000
+#define DRIVER_IRQ_ONESHOT 0x8000
#define DRIVER_BUS_PCI 0x1
#define DRIVER_BUS_PLATFORM 0x2
@@ -872,6 +873,7 @@ struct drm_driver {
/* these have to be filled in */
irqreturn_t(*irq_handler) (DRM_IRQ_ARGS);
+ irqreturn_t(*irq_handler_t) (DRM_IRQ_ARGS);
void (*irq_preinstall) (struct drm_device *dev);
int (*irq_postinstall) (struct drm_device *dev);
void (*irq_uninstall) (struct drm_device *dev);
--
1.7.0.4
[Patch 0/1]drm_irq: Introducing the irq_thread support
> For a kms drm driver (and tbh, doing a non-kms driver today is not a great > idea), > there's no reason to use the drm_irq_install/_unistall helpers. > Can not understand well, I found many GPU drivers are using drm_irq helpers' function, including ours:)
[Patch 0/1]drm_irq: Introducing the irq_thread support
> Well, you cant use the pre_install/post_install hooks the drm_irq code > provides, > but yes, just do the request_irq in your driver code at the right time, with > the > right parameters. Much easier than adding code to a part of the drm core > fraught with backwards-compat stuff no one really wants to touch ... All the > additional stuff besides calling request_irq and the driver hooks that > drm_irq_install does is really just to support old dri1 userspace. > Please have a look for the patch, I just added the callback of irq thread handler, default is NULL without set, So it should be no impact with others. In case irq threadler func is NULL, it equals to request_irq, thanks.
[PATCH V4 2/2] video: drm: exynos: Add device tree support
Hi, 2012/9/5 Kyungmin Park : > Hi, > > On Thu, Sep 6, 2012 at 12:39 AM, Leela Krishna Amudala > wrote: >> Add device tree based discovery support for DRM-FIMD driver. >> >> Signed-off-by: Leela Krishna Amudala >> --- >> Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 + >> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 95 >> - >> 2 files changed, 173 insertions(+), 2 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt >> >> diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt >> b/Documentation/devicetree/bindings/fb/drm-fimd.txt >> new file mode 100644 >> index 000..4ff1829 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt >> @@ -0,0 +1,80 @@ >> +* Samsung Display Controller using DRM frame work >> + >> +The display controller is used to transfer image data from memory to an >> +external LCD driver interface. It supports various color formats such as >> +rgb and yuv. >> + >> +Required properties: >> + - compatible: Should be "samsung,exynos5-fimd" or "samsung,exynos4-fb" for > Doesn't better to use single word? fimd or fb?. I think 'fb' is used > for framebuffer historically. > but now it's used both fb and drm, so fimd is neutral and architecture > specific. > > To do this, Modify arch-exynos first and update it at each drivers it > properly. > > Thank you, > Kyungmin Park > I agree with Kyungmin but I'd like to use as is. the reason we used 'exynos4-fb' as device name, is for that it uses fimd driver's platform device commonly and gets fimd clock. so I think that dts file should be defined with hardware specific name but not driver name such as 'exynos4-fb'. but with this, we can't get fimd clock with device's name because 'exynos4-fb' is used as device name of fimd clock. so to use 'exynos4-fimd', we should modify the device name of fimd clock from 'exynos4-fb' to 'exynos4-fimd' and also ids definitions of s3c-fb and drm fimd driver. so my conclusion is that it merges this patch set as is and then let's modify related things later. any opinions, welcome~ anytime. Thanks. Inki Dae
[Patch 0/1]drm_irq: Introducing the irq_thread support
On Thu, Sep 06, 2012 at 12:42:05AM +, Liu, Chuansheng wrote:
> > This possibly ought to be submitted in parallel with the code that uses it
> > so that
> > the whole proposal can be evaluated as one thing ?
> >
> > Alan
>
> Patch is here, thanks.
>
> From: liu chuansheng
> Subject: [PATCH] drm_irq: Introducing the irq_thread support
>
> For some GPUs, the irq handler need >1ms to handle the irq action.
> And it will delay the whole system irq handler.
>
> This patch is adding the irq thread support, it will make the drm_irq
> interface more flexible.
>
> The changes include:
> 1/ Change the request_irq to request_thread_irq, and add new callback
>irq_handler_t;
> 2/ Normally we need IRQF_ONESHOT flag support for irq thread, so add
>this option in drm_irq;
>
> Cc: Shi Yang
> Signed-off-by: liu chuansheng
Nacked-by: Daniel Vetter
I _really_ hate when we add random special cases for random strange
drivers to core code - the usual end result is that in a few years we'll
have a maze of special-cases only used by one driver each. And nope,
cleaning that up isn't _that_ much fun ...
So just do all this in your own driver's code (and maybe set
dev->irq_enabled ourselve so that wait_vblank still works).
Yours, Daniel
> ---
> drivers/gpu/drm/drm_irq.c |8 ++--
> include/drm/drmP.h|2 ++
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 03f16f3..bc105fe 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -345,13 +345,17 @@ int drm_irq_install(struct drm_device *dev)
> if (drm_core_check_feature(dev, DRIVER_IRQ_SHARED))
> sh_flags = IRQF_SHARED;
>
> + if (drm_core_check_feature(dev, DRIVER_IRQ_ONESHOT))
> + sh_flags |= IRQF_ONESHOT;
> +
> if (dev->devname)
> irqname = dev->devname;
> else
> irqname = dev->driver->name;
>
> - ret = request_irq(drm_dev_to_irq(dev), dev->driver->irq_handler,
> - sh_flags, irqname, dev);
> + ret = request_threaded_irq(drm_dev_to_irq(dev),
> + dev->driver->irq_handler, dev->driver->irq_handler_t,
> + sh_flags, irqname, dev);
>
> if (ret < 0) {
> mutex_lock(&dev->struct_mutex);
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index d6b67bb..b28be4b 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -152,6 +152,7 @@ int drm_err(const char *func, const char *format, ...);
> #define DRIVER_GEM 0x1000
> #define DRIVER_MODESET 0x2000
> #define DRIVER_PRIME 0x4000
> +#define DRIVER_IRQ_ONESHOT 0x8000
>
> #define DRIVER_BUS_PCI 0x1
> #define DRIVER_BUS_PLATFORM 0x2
> @@ -872,6 +873,7 @@ struct drm_driver {
> /* these have to be filled in */
>
> irqreturn_t(*irq_handler) (DRM_IRQ_ARGS);
> + irqreturn_t(*irq_handler_t) (DRM_IRQ_ARGS);
> void (*irq_preinstall) (struct drm_device *dev);
> int (*irq_postinstall) (struct drm_device *dev);
> void (*irq_uninstall) (struct drm_device *dev);
> --
> 1.7.0.4
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
[PATCH] drm/exynos: fix double call of drm_prime_(init/destroy)_file_private
Dear Inki Dae, Am Donnerstag, den 06.09.2012, 11:35 +0900 schrieb InKi Dae: > 2012/9/6 Mandeep Singh Baines : > > The double invocations are incorrect but seem to be safe so I don't > > think this will fix any bugs. > > > > Before: > > > > [7.639366] drm_prime_init_file ee3675d0 > > [7.639377] drm_prime_init_file ee3675d0 > > [7.639507] drm_prime_destroy_file ee3675d0 > > [7.639518] drm_prime_destroy_file ee3675d0 > > [7.639802] drm_prime_init_file ee372390 > > [7.639810] drm_prime_init_file ee372390 > > [8.473316] drm_prime_init_file ee356390 > > [8.473331] drm_prime_init_file ee356390 > > > > After: > > > > [6.363842] drm_prime_init_file edc2e5d0 > > [6.363994] drm_prime_destroy_file edc2e5d0 > > [6.364260] drm_prime_init_file edc2e750 > > [8.004837] drm_prime_init_file ee36ded0 > > > > Signed-off-by: Mandeep Singh Baines > > CC: St?phane Marchesin > > CC: Pawel Osciak > > CC: Inki Dae > > CC: Joonyoung Shim > > CC: Seung-Woo Kim > > CC: Kyungmin Park > > CC: David Airlie > > CC: dri-devel at lists.freedesktop.org > > remove all CCs I guess they were generated by some script. So they should be fine, no? Mandeep, if you put CC in here those people should be CCed in real. `git send-email` should take care of that but I do not see everyone in the CC field. Or does `git send-email` use blind carbon copy (BCC) field? > and can you send it again using text mode? At least to the list it was send in plain text mode. > your patch is messed up when I try to get patch file. Everything is fine on my side. Especially since Mandeep used `git send-email` which should do everything correctly. > Thanks. > Inki Dae In your From address your name is written InKi with capital K. Which one is correct? Thanks, Paul -- 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/20120906/57587e11/attachment.pgp>
[PATCH] drm/exynos: fix double call of drm_prime_(init/destroy)_file_private
Hi, 2012/9/6 Paul Menzel : > Dear Inki Dae, > > > Am Donnerstag, den 06.09.2012, 11:35 +0900 schrieb InKi Dae: > >> 2012/9/6 Mandeep Singh Baines : >> > The double invocations are incorrect but seem to be safe so I don't >> > think this will fix any bugs. >> > >> > Before: >> > >> > [7.639366] drm_prime_init_file ee3675d0 >> > [7.639377] drm_prime_init_file ee3675d0 >> > [7.639507] drm_prime_destroy_file ee3675d0 >> > [7.639518] drm_prime_destroy_file ee3675d0 >> > [7.639802] drm_prime_init_file ee372390 >> > [7.639810] drm_prime_init_file ee372390 >> > [8.473316] drm_prime_init_file ee356390 >> > [8.473331] drm_prime_init_file ee356390 >> > >> > After: >> > >> > [6.363842] drm_prime_init_file edc2e5d0 >> > [6.363994] drm_prime_destroy_file edc2e5d0 >> > [6.364260] drm_prime_init_file edc2e750 >> > [8.004837] drm_prime_init_file ee36ded0 >> > >> > Signed-off-by: Mandeep Singh Baines >> > CC: St?phane Marchesin >> > CC: Pawel Osciak >> > CC: Inki Dae >> > CC: Joonyoung Shim >> > CC: Seung-Woo Kim >> > CC: Kyungmin Park >> > CC: David Airlie >> > CC: dri-devel at lists.freedesktop.org >> >> remove all CCs > > I guess they were generated by some script. So they should be fine, no? > > Mandeep, if you put CC in here those people should be CCed in real. `git > send-email` should take care of that but I do not see everyone in the CC > field. Or does `git send-email` use blind carbon copy (BCC) field? > >> and can you send it again using text mode? > > At least to the list it was send in plain text mode. > >> your patch is messed up when I try to get patch file. > > Everything is fine on my side. Especially since Mandeep used `git > send-email` which should do everything correctly. > your patch was encoded with 'Content-Transfer-Encoding: base64' so please use 7bit ascii like 'Content-Transfer-Encoding: 7bit' >> Thanks. >> Inki Dae > > In your From address your name is written InKi with capital K. Which one > is correct? > Inki is correct :) Thanks. Inki Dae > > Thanks, > > Paul > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[Bug 51652] [6550D SUMO] problems with secondar monitor on VGA, causing GPU lockups
https://bugs.freedesktop.org/show_bug.cgi?id=51652 --- Comment #2 from okias 2012-09-06 10:00:32 UTC --- Still valid with kernel 3.6.0-rc4 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH libdrm 2/3] radeon: Memory footprint of SI mipmap base level is padded to powers of two.
From: Michel D?nzer
Signed-off-by: Michel D?nzer
---
radeon/radeon_surface.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 593c51c..98faa0b 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -963,9 +963,16 @@ static void si_surf_minify_linear_aligned(struct
radeon_surface *surf,
surf->level[level].npix_x = mip_minify(surf->npix_x, level);
surf->level[level].npix_y = mip_minify(surf->npix_y, level);
surf->level[level].npix_z = mip_minify(surf->npix_z, level);
-surf->level[level].nblk_x = (surf->level[level].npix_x + surf->blk_w - 1)
/ surf->blk_w;
-surf->level[level].nblk_y = (surf->level[level].npix_y + surf->blk_h - 1)
/ surf->blk_h;
-surf->level[level].nblk_z = (surf->level[level].npix_z + surf->blk_d - 1)
/ surf->blk_d;
+
+if (level == 0 && surf->last_level > 0) {
+surf->level[level].nblk_x =
(next_power_of_two(surf->level[level].npix_x) + surf->blk_w - 1) / surf->blk_w;
+surf->level[level].nblk_y =
(next_power_of_two(surf->level[level].npix_y) + surf->blk_h - 1) / surf->blk_h;
+surf->level[level].nblk_z =
(next_power_of_two(surf->level[level].npix_z) + surf->blk_d - 1) / surf->blk_d;
+} else {
+surf->level[level].nblk_x = (surf->level[level].npix_x + surf->blk_w -
1) / surf->blk_w;
+surf->level[level].nblk_y = (surf->level[level].npix_y + surf->blk_h -
1) / surf->blk_h;
+surf->level[level].nblk_z = (surf->level[level].npix_z + surf->blk_d -
1) / surf->blk_d;
+}
/* XXX: Second smallest level uses larger pitch, not sure of the real
reason,
* my best guess so far: rows evenly distributed across slice
--
1.7.10.4
[PATCH libdrm 3/3] radeon: Sampling pitch for non-mipmaps seems padded to slice alignment on SI.
From: Michel D?nzer Another corner case that isn't well-explained yet. Signed-off-by: Michel D?nzer --- radeon/radeon_surface.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c index 98faa0b..80b1505 100644 --- a/radeon/radeon_surface.c +++ b/radeon/radeon_surface.c @@ -974,10 +974,15 @@ static void si_surf_minify_linear_aligned(struct radeon_surface *surf, surf->level[level].nblk_z = (surf->level[level].npix_z + surf->blk_d - 1) / surf->blk_d; } -/* XXX: Second smallest level uses larger pitch, not sure of the real reason, - * my best guess so far: rows evenly distributed across slice +/* XXX: Texture sampling uses unexpectedly large pitches in some cases, + * these are just guesses for the rules behind those */ -xalign = MAX2(xalign, slice_align / surf->bpe / surf->level[level].npix_y); +if (level == 0 && surf->last_level == 0) +/* Non-mipmap pitch padded to slice alignment */ +xalign = MAX2(xalign, slice_align / surf->bpe); +else +/* Small rows evenly distributed across slice */ +xalign = MAX2(xalign, slice_align / surf->bpe / surf->level[level].npix_y); surf->level[level].nblk_x = ALIGN(surf->level[level].nblk_x, xalign); surf->level[level].nblk_y = ALIGN(surf->level[level].nblk_y, yalign); -- 1.7.10.4
[PATCH libdrm 1/3] radeon: Fix layout of linear aligned mipmaps on SI.
From: Michel D?nzer
Signed-off-by: Michel D?nzer
---
radeon/radeon_surface.c | 124 ++-
1 file changed, 123 insertions(+), 1 deletion(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 4118a37..593c51c 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -952,6 +952,124 @@ static int eg_surface_best(struct radeon_surface_manager
*surf_man,
/* ===
+ * Southern Islands family
+ */
+
+static void si_surf_minify_linear_aligned(struct radeon_surface *surf,
+ unsigned level,
+ uint32_t xalign, uint32_t yalign,
uint32_t zalign, uint32_t slice_align,
+ unsigned offset)
+{
+surf->level[level].npix_x = mip_minify(surf->npix_x, level);
+surf->level[level].npix_y = mip_minify(surf->npix_y, level);
+surf->level[level].npix_z = mip_minify(surf->npix_z, level);
+surf->level[level].nblk_x = (surf->level[level].npix_x + surf->blk_w - 1)
/ surf->blk_w;
+surf->level[level].nblk_y = (surf->level[level].npix_y + surf->blk_h - 1)
/ surf->blk_h;
+surf->level[level].nblk_z = (surf->level[level].npix_z + surf->blk_d - 1)
/ surf->blk_d;
+
+/* XXX: Second smallest level uses larger pitch, not sure of the real
reason,
+ * my best guess so far: rows evenly distributed across slice
+ */
+xalign = MAX2(xalign, slice_align / surf->bpe / surf->level[level].npix_y);
+
+surf->level[level].nblk_x = ALIGN(surf->level[level].nblk_x, xalign);
+surf->level[level].nblk_y = ALIGN(surf->level[level].nblk_y, yalign);
+surf->level[level].nblk_z = ALIGN(surf->level[level].nblk_z, zalign);
+
+surf->level[level].offset = offset;
+surf->level[level].pitch_bytes = surf->level[level].nblk_x * surf->bpe *
surf->nsamples;
+surf->level[level].slice_size = ALIGN(surf->level[level].pitch_bytes *
surf->level[level].nblk_y, slice_align);
+
+surf->bo_size = offset + surf->level[level].slice_size *
surf->level[level].nblk_z * surf->array_size;
+}
+
+static int si_surface_init_linear_aligned(struct radeon_surface_manager
*surf_man,
+ struct radeon_surface *surf,
+ uint64_t offset, unsigned
start_level)
+{
+uint32_t xalign, yalign, zalign, slice_align;
+unsigned i;
+
+/* compute alignment */
+if (!start_level) {
+surf->bo_alignment = MAX2(256, surf_man->hw_info.group_bytes);
+}
+xalign = MAX2(8, 64 / surf->bpe);
+yalign = 1;
+zalign = 1;
+slice_align = MAX2(64 * surf->bpe, surf_man->hw_info.group_bytes);
+
+/* build mipmap tree */
+for (i = start_level; i <= surf->last_level; i++) {
+surf->level[i].mode = RADEON_SURF_MODE_LINEAR_ALIGNED;
+si_surf_minify_linear_aligned(surf, i, xalign, yalign, zalign,
slice_align, offset);
+/* level0 and first mipmap need to have alignment */
+offset = surf->bo_size;
+if ((i == 0)) {
+offset = ALIGN(offset, surf->bo_alignment);
+}
+}
+return 0;
+}
+
+static int si_surface_init(struct radeon_surface_manager *surf_man,
+ struct radeon_surface *surf)
+{
+unsigned mode;
+int r;
+
+/* MSAA surfaces support the 2D mode only. */
+if (surf->nsamples > 1) {
+surf->flags = RADEON_SURF_CLR(surf->flags, MODE);
+surf->flags |= RADEON_SURF_SET(RADEON_SURF_MODE_2D, MODE);
+}
+
+/* tiling mode */
+mode = (surf->flags >> RADEON_SURF_MODE_SHIFT) & RADEON_SURF_MODE_MASK;
+
+if (surf->flags & (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
+/* zbuffer only support 1D or 2D tiled surface */
+switch (mode) {
+case RADEON_SURF_MODE_1D:
+case RADEON_SURF_MODE_2D:
+break;
+default:
+mode = RADEON_SURF_MODE_1D;
+surf->flags = RADEON_SURF_CLR(surf->flags, MODE);
+surf->flags |= RADEON_SURF_SET(RADEON_SURF_MODE_1D, MODE);
+break;
+}
+}
+
+r = eg_surface_sanity(surf_man, surf, mode);
+if (r) {
+return r;
+}
+
+surf->stencil_offset = 0;
+surf->stencil_tile_split = 0;
+
+/* check tiling mode */
+switch (mode) {
+case RADEON_SURF_MODE_LINEAR:
+r = r6_surface_init_linear(surf_man, surf, 0, 0);
+break;
+case RADEON_SURF_MODE_LINEAR_ALIGNED:
+r = si_surface_init_linear_aligned(surf_man, surf, 0, 0);
+break;
+case RADEON_SURF_MODE_1D:
+r = eg_surface_init_1d(surf_man, surf, 0, 0);
+break;
+case RADEON_SURF_MODE_2D:
+r = eg_surface_init_2d(surf_man, surf, 0, 0);
+break;
+default:
+return -EINVAL;
+}
+return r;
+}
+
+/* ===
[PATCH V4 2/2] video: drm: exynos: Add device tree support
Hi, On 09/06/2012 09:21 AM, InKi Dae wrote: >>> +Required properties: >>> + - compatible: Should be "samsung,exynos5-fimd" or "samsung,exynos4-fb" for >> Doesn't better to use single word? fimd or fb?. I think 'fb' is used >> for framebuffer historically. >> but now it's used both fb and drm, so fimd is neutral and architecture >> specific. >> >> To do this, Modify arch-exynos first and update it at each drivers it >> properly. >> >> Thank you, >> Kyungmin Park >> > > I agree with Kyungmin but I'd like to use as is. the reason we used > 'exynos4-fb' as device name, is for that it uses fimd driver's > platform device commonly and gets fimd clock. so I think that dts file > should be defined with hardware specific name but not driver name such > as 'exynos4-fb'. but with this, we can't get fimd clock with device's > name because 'exynos4-fb' is used as device name of fimd clock. so to > use 'exynos4-fimd', we should modify the device name of fimd clock > from 'exynos4-fb' to 'exynos4-fimd' and also ids definitions of > s3c-fb and drm fimd driver. so my conclusion is that it merges this I think it's good moment to put those things in order, i.e. use uniform 'compatible' names: "samsung,exynos4-fimd", "samsung,exynos5-fimd". Platform device names are separate issue, but could perhaps be unified at this time as well. > patch set as is and then let's modify related things later. > any opinions, welcome~ anytime. > > Thanks. > Inki Dae -- Regards, Sylwester
[PATCH libdrm 1/3] radeon: Fix layout of linear aligned mipmaps on SI.
On 06.09.2012 12:53, Michel D?nzer wrote:
> From: Michel D?nzer
>
> Signed-off-by: Michel D?nzer
Sounds good to me, but shouldn't we also increase the version number?
Anyway: Reviewed-by: Christian K?nig
> ---
> radeon/radeon_surface.c | 124
> ++-
> 1 file changed, 123 insertions(+), 1 deletion(-)
>
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 4118a37..593c51c 100644
> --- a/radeon/radeon_surface.c
> +++ b/radeon/radeon_surface.c
> @@ -952,6 +952,124 @@ static int eg_surface_best(struct
> radeon_surface_manager *surf_man,
>
>
> /*
> ===
> + * Southern Islands family
> + */
> +
> +static void si_surf_minify_linear_aligned(struct radeon_surface *surf,
> + unsigned level,
> + uint32_t xalign, uint32_t yalign,
> uint32_t zalign, uint32_t slice_align,
> + unsigned offset)
> +{
> +surf->level[level].npix_x = mip_minify(surf->npix_x, level);
> +surf->level[level].npix_y = mip_minify(surf->npix_y, level);
> +surf->level[level].npix_z = mip_minify(surf->npix_z, level);
> +surf->level[level].nblk_x = (surf->level[level].npix_x + surf->blk_w -
> 1) / surf->blk_w;
> +surf->level[level].nblk_y = (surf->level[level].npix_y + surf->blk_h -
> 1) / surf->blk_h;
> +surf->level[level].nblk_z = (surf->level[level].npix_z + surf->blk_d -
> 1) / surf->blk_d;
> +
> +/* XXX: Second smallest level uses larger pitch, not sure of the real
> reason,
> + * my best guess so far: rows evenly distributed across slice
> + */
> +xalign = MAX2(xalign, slice_align / surf->bpe /
> surf->level[level].npix_y);
> +
> +surf->level[level].nblk_x = ALIGN(surf->level[level].nblk_x, xalign);
> +surf->level[level].nblk_y = ALIGN(surf->level[level].nblk_y, yalign);
> +surf->level[level].nblk_z = ALIGN(surf->level[level].nblk_z, zalign);
> +
> +surf->level[level].offset = offset;
> +surf->level[level].pitch_bytes = surf->level[level].nblk_x * surf->bpe *
> surf->nsamples;
> +surf->level[level].slice_size = ALIGN(surf->level[level].pitch_bytes *
> surf->level[level].nblk_y, slice_align);
> +
> +surf->bo_size = offset + surf->level[level].slice_size *
> surf->level[level].nblk_z * surf->array_size;
> +}
> +
> +static int si_surface_init_linear_aligned(struct radeon_surface_manager
> *surf_man,
> + struct radeon_surface *surf,
> + uint64_t offset, unsigned
> start_level)
> +{
> +uint32_t xalign, yalign, zalign, slice_align;
> +unsigned i;
> +
> +/* compute alignment */
> +if (!start_level) {
> +surf->bo_alignment = MAX2(256, surf_man->hw_info.group_bytes);
> +}
> +xalign = MAX2(8, 64 / surf->bpe);
> +yalign = 1;
> +zalign = 1;
> +slice_align = MAX2(64 * surf->bpe, surf_man->hw_info.group_bytes);
> +
> +/* build mipmap tree */
> +for (i = start_level; i <= surf->last_level; i++) {
> +surf->level[i].mode = RADEON_SURF_MODE_LINEAR_ALIGNED;
> +si_surf_minify_linear_aligned(surf, i, xalign, yalign, zalign,
> slice_align, offset);
> +/* level0 and first mipmap need to have alignment */
> +offset = surf->bo_size;
> +if ((i == 0)) {
> +offset = ALIGN(offset, surf->bo_alignment);
> +}
> +}
> +return 0;
> +}
> +
> +static int si_surface_init(struct radeon_surface_manager *surf_man,
> + struct radeon_surface *surf)
> +{
> +unsigned mode;
> +int r;
> +
> +/* MSAA surfaces support the 2D mode only. */
> +if (surf->nsamples > 1) {
> +surf->flags = RADEON_SURF_CLR(surf->flags, MODE);
> +surf->flags |= RADEON_SURF_SET(RADEON_SURF_MODE_2D, MODE);
> +}
> +
> +/* tiling mode */
> +mode = (surf->flags >> RADEON_SURF_MODE_SHIFT) & RADEON_SURF_MODE_MASK;
> +
> +if (surf->flags & (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
> +/* zbuffer only support 1D or 2D tiled surface */
> +switch (mode) {
> +case RADEON_SURF_MODE_1D:
> +case RADEON_SURF_MODE_2D:
> +break;
> +default:
> +mode = RADEON_SURF_MODE_1D;
> +surf->flags = RADEON_SURF_CLR(surf->flags, MODE);
> +surf->flags |= RADEON_SURF_SET(RADEON_SURF_MODE_1D, MODE);
> +break;
> +}
> +}
> +
> +r = eg_surface_sanity(surf_man, surf, mode);
> +if (r) {
> +return r;
> +}
> +
> +surf->stencil_offset = 0;
> +surf->stencil_tile_split = 0;
> +
> +/* check tiling mode */
> +switch (mode) {
> +case RADEON_SURF_MODE_LINEAR:
> +r = r6_surface_init_linear(surf_man, surf, 0, 0);
> +break;
> +case RADEON_SURF_MODE_LINEAR_ALIGNED:
> +
[PATCH] drm/radeon: fix VM syncing with multiple rings
When a VM is used on more than one ring we need to sync to the last user. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_cs.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c index e241506..d59eb59 100644 --- a/drivers/gpu/drm/radeon/radeon_cs.c +++ b/drivers/gpu/drm/radeon/radeon_cs.c @@ -463,7 +463,7 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev, goto out; } radeon_cs_sync_rings(parser); - radeon_cs_sync_to(parser, vm->last_flush); + radeon_cs_sync_to(parser, vm->fence); radeon_cs_sync_to(parser, radeon_vm_grab_id(rdev, vm, parser->ring)); if ((rdev->family >= CHIP_TAHITI) && -- 1.7.9.5
[PATCH libdrm 1/3] radeon: Fix layout of linear aligned mipmaps on SI.
On Don, 2012-09-06 at 13:46 +0200, Christian K?nig wrote: > On 06.09.2012 12:53, Michel D?nzer wrote: > > From: Michel D?nzer > > > > Signed-off-by: Michel D?nzer > Sounds good to me, but shouldn't we also increase the version number? Assuming you mean the libdrm package version, I don't think it's worth doing that just for these fixes. At this point, one should always use latest Git of mesa and libdrm for radeonsi. But of course, once a libdrm release is out with these fixes, we can require that as the minimum version for radeonsi. > Anyway: Reviewed-by: Christian K?nig Thanks, is that for the whole series? -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
[PATCH libdrm 1/3] radeon: Fix layout of linear aligned mipmaps on SI.
On 06.09.2012 15:01, Michel D?nzer wrote: > On Don, 2012-09-06 at 13:46 +0200, Christian K?nig wrote: >> On 06.09.2012 12:53, Michel D?nzer wrote: >>> From: Michel D?nzer >>> >>> Signed-off-by: Michel D?nzer >> Sounds good to me, but shouldn't we also increase the version number? > Assuming you mean the libdrm package version, I don't think it's worth > doing that just for these fixes. At this point, one should always use > latest Git of mesa and libdrm for radeonsi. But of course, once a libdrm > release is out with these fixes, we can require that as the minimum > version for radeonsi. Ok, that makes sense. >> Anyway: Reviewed-by: Christian K?nig > Thanks, is that for the whole series? Yes it is, and also for the four patches to radeonsi which depends on this change. Christian.
radeon power management issues on a 12,2 iMac
I've posted this here simply as google bait for the next poor sod suffering with radeon power management issues. Why does the in-kernel radeon driver try and cook my machine by default? Since I bought this machine, I've run with a hard-coded hack to keep the card in low power mode. This has not previously had any issues, even to being able to watch three full screen HD streams (one on each head). A recent change to the radeon driver left me with noise on the right hand side of all three heads, and a plea for assistance was me with a response that multiple heads are not supported in low-power mode (thus my hack in the first place). The issue here is that all the multi-head profiles run the card in the highest power profile, and the machine ends up sounding like a 747 trying to keep the card cool. Poking into radeon_asic.c tells me my cards power profiles are setup in : r600_pm_init_profile Time to have a look at what profiles the card actually has. Enabling dri debugging and booting up leaves this in my log Sep 6 13:47:37 localhost kernel: [3.919380] [drm:radeon_pm_print_states], 5 Power State(s) Sep 6 13:47:37 localhost kernel: [3.919381] [drm:radeon_pm_print_states], State 0: Default Sep 6 13:47:37 localhost kernel: [3.919382] [drm:radeon_pm_print_states], Default Sep 6 13:47:37 localhost kernel: [3.919383] [drm:radeon_pm_print_states], 16 PCIE Lanes Sep 6 13:47:37 localhost kernel: [3.919384] [drm:radeon_pm_print_states], 3 Clock Mode(s) Sep 6 13:47:37 localhost kernel: [3.919385] [drm:radeon_pm_print_states], 0 e: 68 m: 90 v: 1100 No display only Sep 6 13:47:37 localhost kernel: [3.919386] [drm:radeon_pm_print_states], 1 e: 68 m: 90 v: 1100 Sep 6 13:47:37 localhost kernel: [3.919387] [drm:radeon_pm_print_states], 2 e: 68 m: 90 v: 1100 Sep 6 13:47:37 localhost kernel: [3.919388] [drm:radeon_pm_print_states], State 1: Performance Sep 6 13:47:37 localhost kernel: [3.919389] [drm:radeon_pm_print_states], 16 PCIE Lanes Sep 6 13:47:37 localhost kernel: [3.919390] [drm:radeon_pm_print_states], 3 Clock Mode(s) Sep 6 13:47:37 localhost kernel: [3.919391] [drm:radeon_pm_print_states], 0 e: 10 m: 149000 v: 900 No display only Sep 6 13:47:37 localhost kernel: [3.919392] [drm:radeon_pm_print_states], 1 e: 398000 m: 90 v: 1000 Sep 6 13:47:37 localhost kernel: [3.919393] [drm:radeon_pm_print_states], 2 e: 68 m: 90 v: 1100 Sep 6 13:47:37 localhost kernel: [3.919395] [drm:radeon_pm_print_states], State 2: Default Sep 6 13:47:37 localhost kernel: [3.919395] [drm:radeon_pm_print_states], 16 PCIE Lanes Sep 6 13:47:37 localhost kernel: [3.919396] [drm:radeon_pm_print_states], 3 Clock Mode(s) Sep 6 13:47:37 localhost kernel: [3.919397] [drm:radeon_pm_print_states], 0 e: 298000 m: 90 v: 950 No display only Sep 6 13:47:37 localhost kernel: [3.919398] [drm:radeon_pm_print_states], 1 e: 298000 m: 90 v: 950 Sep 6 13:47:37 localhost kernel: [3.919399] [drm:radeon_pm_print_states], 2 e: 68 m: 90 v: 1100 Sep 6 13:47:37 localhost kernel: [3.919400] [drm:radeon_pm_print_states], State 3: Default Sep 6 13:47:37 localhost kernel: [3.919401] [drm:radeon_pm_print_states], 16 PCIE Lanes Sep 6 13:47:37 localhost kernel: [3.919402] [drm:radeon_pm_print_states], 3 Clock Mode(s) Sep 6 13:47:37 localhost kernel: [3.919403] [drm:radeon_pm_print_states], 0 e: 502000 m: 90 v: 1050 No display only Sep 6 13:47:37 localhost kernel: [3.919404] [drm:radeon_pm_print_states], 1 e: 502000 m: 90 v: 1050 Sep 6 13:47:37 localhost kernel: [3.919405] [drm:radeon_pm_print_states], 2 e: 68 m: 90 v: 1100 Sep 6 13:47:37 localhost kernel: [3.919406] [drm:radeon_pm_print_states], State 4: Battery Sep 6 13:47:37 localhost kernel: [3.919407] [drm:radeon_pm_print_states], 16 PCIE Lanes Sep 6 13:47:37 localhost kernel: [3.919408] [drm:radeon_pm_print_states], 3 Clock Mode(s) Sep 6 13:47:37 localhost kernel: [3.919409] [drm:radeon_pm_print_states], 0 e: 10 m: 149000 v: 900 No display only Sep 6 13:47:37 localhost kernel: [3.919410] [drm:radeon_pm_print_states], 1 e: 10 m: 149000 v: 900 Sep 6 13:47:37 localhost kernel: [3.919411] [drm:radeon_pm_print_states], 2 e: 10 m: 149000 v: 900 Sep 6 13:47:37 localhost kernel: [3.920559] [drm] radeon: power management initialized So, because my GPU is a mobile device (rdev->flags & RADEON_IS_MOBILITY is true), then my single head profiles are selected from the Battery profile, and because there is not a second Battery profile the multi-head profiles come from profile 0 (default). This card actually has 3 profiles ca
drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot
Dave - I couldn't find this patch in your git repo at git://people.freedesktop.org/~airlied/linux in the drm-next or drm-fixes branches. https://patchwork.kernel.org/patch/1379071/ It appears to fix a real problem for Mac users - http://bugs.launchpad.net/bugs/1039157. See https://bugs.launchpad.net/ubuntu/oneiric/+source/linux/+bug/1039157/comments/31 for confirmation. I think it should also be 'Cc: stable at vger.kernel.org'. It applies as far back as 2.6.32 with minor context differences. rtg -- Tim Gardner tim.gardner at canonical.com
[PATCH libdrm 1/3] radeon: Fix layout of linear aligned mipmaps on SI.
On Thu, Sep 6, 2012 at 6:53 AM, Michel D?nzer wrote:
> From: Michel D?nzer
>
> Signed-off-by: Michel D?nzer
for the series:
Reviewed-by: Alex Deucher
> ---
> radeon/radeon_surface.c | 124
> ++-
> 1 file changed, 123 insertions(+), 1 deletion(-)
>
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 4118a37..593c51c 100644
> --- a/radeon/radeon_surface.c
> +++ b/radeon/radeon_surface.c
> @@ -952,6 +952,124 @@ static int eg_surface_best(struct
> radeon_surface_manager *surf_man,
>
>
> /*
> ===
> + * Southern Islands family
> + */
> +
> +static void si_surf_minify_linear_aligned(struct radeon_surface *surf,
> + unsigned level,
> + uint32_t xalign, uint32_t yalign,
> uint32_t zalign, uint32_t slice_align,
> + unsigned offset)
> +{
> +surf->level[level].npix_x = mip_minify(surf->npix_x, level);
> +surf->level[level].npix_y = mip_minify(surf->npix_y, level);
> +surf->level[level].npix_z = mip_minify(surf->npix_z, level);
> +surf->level[level].nblk_x = (surf->level[level].npix_x + surf->blk_w -
> 1) / surf->blk_w;
> +surf->level[level].nblk_y = (surf->level[level].npix_y + surf->blk_h -
> 1) / surf->blk_h;
> +surf->level[level].nblk_z = (surf->level[level].npix_z + surf->blk_d -
> 1) / surf->blk_d;
> +
> +/* XXX: Second smallest level uses larger pitch, not sure of the real
> reason,
> + * my best guess so far: rows evenly distributed across slice
> + */
> +xalign = MAX2(xalign, slice_align / surf->bpe /
> surf->level[level].npix_y);
> +
> +surf->level[level].nblk_x = ALIGN(surf->level[level].nblk_x, xalign);
> +surf->level[level].nblk_y = ALIGN(surf->level[level].nblk_y, yalign);
> +surf->level[level].nblk_z = ALIGN(surf->level[level].nblk_z, zalign);
> +
> +surf->level[level].offset = offset;
> +surf->level[level].pitch_bytes = surf->level[level].nblk_x * surf->bpe *
> surf->nsamples;
> +surf->level[level].slice_size = ALIGN(surf->level[level].pitch_bytes *
> surf->level[level].nblk_y, slice_align);
> +
> +surf->bo_size = offset + surf->level[level].slice_size *
> surf->level[level].nblk_z * surf->array_size;
> +}
> +
> +static int si_surface_init_linear_aligned(struct radeon_surface_manager
> *surf_man,
> + struct radeon_surface *surf,
> + uint64_t offset, unsigned
> start_level)
> +{
> +uint32_t xalign, yalign, zalign, slice_align;
> +unsigned i;
> +
> +/* compute alignment */
> +if (!start_level) {
> +surf->bo_alignment = MAX2(256, surf_man->hw_info.group_bytes);
> +}
> +xalign = MAX2(8, 64 / surf->bpe);
> +yalign = 1;
> +zalign = 1;
> +slice_align = MAX2(64 * surf->bpe, surf_man->hw_info.group_bytes);
> +
> +/* build mipmap tree */
> +for (i = start_level; i <= surf->last_level; i++) {
> +surf->level[i].mode = RADEON_SURF_MODE_LINEAR_ALIGNED;
> +si_surf_minify_linear_aligned(surf, i, xalign, yalign, zalign,
> slice_align, offset);
> +/* level0 and first mipmap need to have alignment */
> +offset = surf->bo_size;
> +if ((i == 0)) {
> +offset = ALIGN(offset, surf->bo_alignment);
> +}
> +}
> +return 0;
> +}
> +
> +static int si_surface_init(struct radeon_surface_manager *surf_man,
> + struct radeon_surface *surf)
> +{
> +unsigned mode;
> +int r;
> +
> +/* MSAA surfaces support the 2D mode only. */
> +if (surf->nsamples > 1) {
> +surf->flags = RADEON_SURF_CLR(surf->flags, MODE);
> +surf->flags |= RADEON_SURF_SET(RADEON_SURF_MODE_2D, MODE);
> +}
> +
> +/* tiling mode */
> +mode = (surf->flags >> RADEON_SURF_MODE_SHIFT) & RADEON_SURF_MODE_MASK;
> +
> +if (surf->flags & (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
> +/* zbuffer only support 1D or 2D tiled surface */
> +switch (mode) {
> +case RADEON_SURF_MODE_1D:
> +case RADEON_SURF_MODE_2D:
> +break;
> +default:
> +mode = RADEON_SURF_MODE_1D;
> +surf->flags = RADEON_SURF_CLR(surf->flags, MODE);
> +surf->flags |= RADEON_SURF_SET(RADEON_SURF_MODE_1D, MODE);
> +break;
> +}
> +}
> +
> +r = eg_surface_sanity(surf_man, surf, mode);
> +if (r) {
> +return r;
> +}
> +
> +surf->stencil_offset = 0;
> +surf->stencil_tile_split = 0;
> +
> +/* check tiling mode */
> +switch (mode) {
> +case RADEON_SURF_MODE_LINEAR:
> +r = r6_surface_init_linear(surf_man, surf, 0, 0);
> +break;
> +case RADEON_SURF_MODE_LINEAR_ALIGNED:
> +r = si_surface_init_linear_aligned(surf_man, surf, 0, 0);
>
drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot
On Thu, Sep 6, 2012 at 3:35 PM, Tim Gardner wrote: > Dave - I couldn't find this patch in your git repo at > git://people.freedesktop.org/~airlied/linux in the drm-next or drm-fixes > branches. > > https://patchwork.kernel.org/patch/1379071/ > > It appears to fix a real problem for Mac users - > http://bugs.launchpad.net/bugs/1039157. See > https://bugs.launchpad.net/ubuntu/oneiric/+source/linux/+bug/1039157/comments/31 > for confirmation. Thanks, I was going to point out that Dave had already fix this, but it seem you already knew about that. There is a companion patch along side with the one mentioned. http://lists.freedesktop.org/archives/dri-devel/2012-August/027124.html http://lists.freedesktop.org/archives/dri-devel/2012-August/027125.html I recommend applying both and turning the config to yes (as long as you have the kms enabled xf86-video-vmware driver installed). I RB:ed them both along with the dumb ioctl interface here: http://lists.freedesktop.org/archives/dri-devel/2012-August/027139.html > > I think it should also be 'Cc: stable at vger.kernel.org'. It applies as > far back as 2.6.32 with minor context differences. > > rtg Its probably safe, but it could mean that the driver gets loaded on distros, where in the past it hasn't tho that should be safe. Cheers, Jakob.
[PATCH] drm/radeon: fix VM syncing with multiple rings
On Thu, Sep 6, 2012 at 7:48 AM, Christian K?nig wrote: > When a VM is used on more than one ring we need to > sync to the last user. > > Signed-off-by: Christian K?nig Reviewed-by: Jerome Glisse > --- > drivers/gpu/drm/radeon/radeon_cs.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_cs.c > b/drivers/gpu/drm/radeon/radeon_cs.c > index e241506..d59eb59 100644 > --- a/drivers/gpu/drm/radeon/radeon_cs.c > +++ b/drivers/gpu/drm/radeon/radeon_cs.c > @@ -463,7 +463,7 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device > *rdev, > goto out; > } > radeon_cs_sync_rings(parser); > - radeon_cs_sync_to(parser, vm->last_flush); > + radeon_cs_sync_to(parser, vm->fence); > radeon_cs_sync_to(parser, radeon_vm_grab_id(rdev, vm, parser->ring)); > > if ((rdev->family >= CHIP_TAHITI) && > -- > 1.7.9.5 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
PCI Radeon RV100 detection hang on sparc64
This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in Ultra 10 (clean, without my "Video RAM" hack that I talked in other sparclinux posts). When I saw that Sun XVR-100 was detected fine by the kernel, I compiled radeon drm driver with modesetting enabled and tried it: [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. PCI: Enabling device: (:02:02.0), cmd 82 [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908). [drm] register mmio base: 0x1000 [drm] register mmio size: 32768 [drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR And here the machine hangs. Debugging printk-s reveal that it does not find any active I/O port resources and then continues into initializing the card. Down in igp_read_bios_from_vram() it successfully ioremaps memory region 0 (vram_base=1ff0800 and size=4) and tries to read 2 bytes from there and hangs on reading bios[0]. With radeon.modeset=0, it boots and I collected the following info: 02:02.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA controller]) Subsystem: Advanced Micro Devices [AMD] nee ATI XVR-100 (supplied by Sun) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR-
[Bug 43360] nouveau on "NVce" 560 Ti: Failed to idle channel 1
https://bugzilla.kernel.org/show_bug.cgi?id=43360 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Component|Staging |Video(DRI - non Intel) AssignedTo|drivers_staging at kernel-bugs |drivers_video-dri at kernel-bu |.osdl.org |gs.osdl.org -- 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/exynos: fix double call of drm_prime_(init/destroy)_file_private
The double invocations are incorrect but seem to be safe so I don't think this will fix any bugs. Before: [7.639366] drm_prime_init_file ee3675d0 [7.639377] drm_prime_init_file ee3675d0 [7.639507] drm_prime_destroy_file ee3675d0 [7.639518] drm_prime_destroy_file ee3675d0 [7.639802] drm_prime_init_file ee372390 [7.639810] drm_prime_init_file ee372390 [8.473316] drm_prime_init_file ee356390 [8.473331] drm_prime_init_file ee356390 After: [6.363842] drm_prime_init_file edc2e5d0 [6.363994] drm_prime_destroy_file edc2e5d0 [6.364260] drm_prime_init_file edc2e750 [8.004837] drm_prime_init_file ee36ded0 Signed-off-by: Mandeep Singh Baines Acked-by: Seung-Woo Kim --- drivers/gpu/drm/exynos/exynos_drm_drv.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index ebacec6..a27b8ff 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -160,7 +160,6 @@ static int exynos_drm_open(struct drm_device *dev, struct drm_file *file) if (!file_priv) return -ENOMEM; - drm_prime_init_file_private(&file->prime); file->driver_priv = file_priv; return exynos_drm_subdrv_open(dev, file); @@ -184,7 +183,6 @@ static void exynos_drm_preclose(struct drm_device *dev, e->base.destroy(&e->base); } } - drm_prime_destroy_file_private(&file->prime); spin_unlock_irqrestore(&dev->event_lock, flags); exynos_drm_subdrv_close(dev, file); -- 1.7.7.3
PCI Radeon RV100 detection hang on sparc64
On Thu, 2012-09-06 at 17:41 +0300, Meelis Roos wrote: > [drm] radeon defaulting to kernel modesetting. > [drm] radeon kernel modesetting enabled. > PCI: Enabling device: (:02:02.0), cmd 82 > [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908). > [drm] register mmio base: 0x1000 > [drm] register mmio size: 32768 > [drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR This particular message looks like it might actually be harmless, all the code paths that use the I/O BAR can use the MMIO mirror of it instead. No idea how well tested that is, but at any rate it's not what's breaking your setup. > And here the machine hangs. Debugging printk-s reveal that it does not > find any active I/O port resources and then continues into initializing > the card. Down in igp_read_bios_from_vram() it successfully ioremaps > memory region 0 (vram_base=1ff0800 and size=4) and tries to read > 2 bytes from there and hangs on reading bios[0]. This is probably because... > 02:02.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV100 > QY [Radeon 7000/VE] (prog-if 00 [VGA controller]) > Subsystem: Advanced Micro Devices [AMD] nee ATI XVR-100 (supplied by > Sun) > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping+ SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 0 (2000ns min) > Interrupt: pin A routed to IRQ 16 > Region 0: Memory at 0800 (32-bit, prefetchable) [size=64M] > Region 1: I/O ports at 0400 [disabled] [size=256] > Region 2: Memory at 1000 (32-bit, non-prefetchable) [size=32K] > Region 3: [virtual] Memory at fe01 (32-bit, > non-prefetchable) [size=1] > Region 4: [virtual] Memory at fe01 (32-bit, > non-prefetchable) [size=1] > Region 5: [virtual] Memory at fe01 (32-bit, > non-prefetchable) [size=1] > Expansion ROM at 1002 [disabled] [size=128K] ... the ROM BAR looks like it's not routed. On x86 you could fix this by booting with 'pci=rom' to force the ROM BAR to be routed regardless of firmware setup, no idea how that's meant to work on sparc though. - 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/20120906/9fada6d8/attachment.pgp>
PCI Radeon RV100 detection hang on sparc64
On Don, 2012-09-06 at 17:41 +0300, Meelis Roos wrote: > This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in > Ultra 10 (clean, without my "Video RAM" hack that I talked in other > sparclinux posts). When I saw that Sun XVR-100 was detected fine by the > kernel, I compiled radeon drm driver with modesetting enabled and tried > it: > > [drm] radeon defaulting to kernel modesetting. > [drm] radeon kernel modesetting enabled. > PCI: Enabling device: (:02:02.0), cmd 82 > [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908). > [drm] register mmio base: 0x1000 > [drm] register mmio size: 32768 > [drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR > > And here the machine hangs. Debugging printk-s reveal that it does not > find any active I/O port resources and then continues into initializing > the card. Down in igp_read_bios_from_vram() it successfully ioremaps > memory region 0 (vram_base=1ff0800 and size=4) and tries to read > 2 bytes from there and hangs on reading bios[0]. Is the card initialized by OpenFirmware? E.g., does it display anything before the kernel boots? > With radeon.modeset=0, it boots [...] Does X work with DRI enabled then? -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #25 from Alexandre Demers 2012-09-06 17:19:09 UTC --- I'll have to confirm it later today by disabling VM, but I'm pretty sure I experienced a lock (can be reproduced every time) related to VM when testing with Unigine Tropics. It loaded, the demo began and then it locked when the island appeared at the horizon (I guess that's what it is since it was the first time I was running this demo). >From the retrieved logs, I could only identify a GPU lock with a reset that failed to reset rings properly. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #50 from Alexandre Demers 2012-09-06 17:24:39 UTC --- I've seen some messages about Hi-Z being released, but not enabled and so on a couple of weeks ago. What is the status? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43360] nouveau on "NVce" 560 Ti: Failed to idle channel 1
https://bugzilla.kernel.org/show_bug.cgi?id=43360 Marcin Slusarz changed: What|Removed |Added CC||marcin.slusarz at gmail.com --- Comment #4 from Marcin Slusarz 2012-09-06 17:54:55 --- Can you test 3.6-rc4? It's probably fixed in this version. -- 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 54527] Crash, kernel BUG ttm/ttm_bo.c:1659!, when running gnibbles
https://bugs.freedesktop.org/show_bug.cgi?id=54527 Michel D?nzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Michel D?nzer 2012-09-06 18:18:05 UTC --- Thanks for confirming. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
PCI Radeon RV100 detection hang on sparc64
From: Meelis Roos Date: Thu, 6 Sep 2012 17:41:13 +0300 (EEST) > And here the machine hangs. Debugging printk-s reveal that it does not > find any active I/O port resources and then continues into initializing > the card. Down in igp_read_bios_from_vram() it successfully ioremaps > memory region 0 (vram_base=1ff0800 and size=4) and tries to read > 2 bytes from there and hangs on reading bios[0]. Mappings obtained from ioremap() may not be derefenced directly. What you get back from ioremap() isn't a pointer. It's an opaque __iomem cookie, which must only be used via readl() et al. On sparc64 ioremap() happens to return a physical address, that's why this non-portable code crashes.
PCI Radeon RV100 detection hang on sparc64
From: Adam Jackson Date: Thu, 06 Sep 2012 12:51:17 -0400 > On Thu, 2012-09-06 at 17:41 +0300, Meelis Roos wrote: > >> And here the machine hangs. Debugging printk-s reveal that it does not >> find any active I/O port resources and then continues into initializing >> the card. Down in igp_read_bios_from_vram() it successfully ioremaps >> memory region 0 (vram_base=1ff0800 and size=4) and tries to read >> 2 bytes from there and hangs on reading bios[0]. > > This is probably because... I think the real issue is that the VRAM bios reading code is buggy, see my other email. It deferences ioremap()'d memory, and that's not allowed. One must use the proper __iomem pointer accessors, such as readl(), readb(), etc.
PCI Radeon RV100 detection hang on sparc64
From: Michel D?nzer Date: Thu, 06 Sep 2012 18:55:51 +0200 > On Don, 2012-09-06 at 17:41 +0300, Meelis Roos wrote: >> This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in >> Ultra 10 (clean, without my "Video RAM" hack that I talked in other >> sparclinux posts). When I saw that Sun XVR-100 was detected fine by the >> kernel, I compiled radeon drm driver with modesetting enabled and tried >> it: >> >> [drm] radeon defaulting to kernel modesetting. >> [drm] radeon kernel modesetting enabled. >> PCI: Enabling device: (:02:02.0), cmd 82 >> [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908). >> [drm] register mmio base: 0x1000 >> [drm] register mmio size: 32768 >> [drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR >> >> And here the machine hangs. Debugging printk-s reveal that it does not >> find any active I/O port resources and then continues into initializing >> the card. Down in igp_read_bios_from_vram() it successfully ioremaps >> memory region 0 (vram_base=1ff0800 and size=4) and tries to read >> 2 bytes from there and hangs on reading bios[0]. > > Is the card initialized by OpenFirmware? E.g., does it display anything > before the kernel boots? I think Meelis gave you every single detail you need to know to analyze and fix this bug. He says it crashes on reading bios[0]. If you look at the function he tells you the crash occurs in, you'll see clearly that bios is an ioremap()'d pointer. You cannot dereference ioremap()'d pointers, you must use the proper accessors such as readl().
Re: [PATCH V4 2/2] video: drm: exynos: Add device tree support
Hi, 2012/9/5 Kyungmin Park : > Hi, > > On Thu, Sep 6, 2012 at 12:39 AM, Leela Krishna Amudala > wrote: >> Add device tree based discovery support for DRM-FIMD driver. >> >> Signed-off-by: Leela Krishna Amudala >> --- >> Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 + >> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 95 >> - >> 2 files changed, 173 insertions(+), 2 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt >> >> diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt >> b/Documentation/devicetree/bindings/fb/drm-fimd.txt >> new file mode 100644 >> index 000..4ff1829 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt >> @@ -0,0 +1,80 @@ >> +* Samsung Display Controller using DRM frame work >> + >> +The display controller is used to transfer image data from memory to an >> +external LCD driver interface. It supports various color formats such as >> +rgb and yuv. >> + >> +Required properties: >> + - compatible: Should be "samsung,exynos5-fimd" or "samsung,exynos4-fb" for > Doesn't better to use single word? fimd or fb?. I think 'fb' is used > for framebuffer historically. > but now it's used both fb and drm, so fimd is neutral and architecture > specific. > > To do this, Modify arch-exynos first and update it at each drivers it > properly. > > Thank you, > Kyungmin Park > I agree with Kyungmin but I'd like to use as is. the reason we used 'exynos4-fb' as device name, is for that it uses fimd driver's platform device commonly and gets fimd clock. so I think that dts file should be defined with hardware specific name but not driver name such as 'exynos4-fb'. but with this, we can't get fimd clock with device's name because 'exynos4-fb' is used as device name of fimd clock. so to use 'exynos4-fimd', we should modify the device name of fimd clock from 'exynos4-fb' to 'exynos4-fimd' and also ids definitions of s3c-fb and drm fimd driver. so my conclusion is that it merges this patch set as is and then let's modify related things later. any opinions, welcome~ anytime. Thanks. Inki Dae ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Patch 0/1]drm_irq: Introducing the irq_thread support
On Thu, Sep 06, 2012 at 12:42:05AM +, Liu, Chuansheng wrote:
> > This possibly ought to be submitted in parallel with the code that uses it
> > so that
> > the whole proposal can be evaluated as one thing ?
> >
> > Alan
>
> Patch is here, thanks.
>
> From: liu chuansheng
> Subject: [PATCH] drm_irq: Introducing the irq_thread support
>
> For some GPUs, the irq handler need >1ms to handle the irq action.
> And it will delay the whole system irq handler.
>
> This patch is adding the irq thread support, it will make the drm_irq
> interface more flexible.
>
> The changes include:
> 1/ Change the request_irq to request_thread_irq, and add new callback
>irq_handler_t;
> 2/ Normally we need IRQF_ONESHOT flag support for irq thread, so add
>this option in drm_irq;
>
> Cc: Shi Yang
> Signed-off-by: liu chuansheng
Nacked-by: Daniel Vetter
I _really_ hate when we add random special cases for random strange
drivers to core code - the usual end result is that in a few years we'll
have a maze of special-cases only used by one driver each. And nope,
cleaning that up isn't _that_ much fun ...
So just do all this in your own driver's code (and maybe set
dev->irq_enabled ourselve so that wait_vblank still works).
Yours, Daniel
> ---
> drivers/gpu/drm/drm_irq.c |8 ++--
> include/drm/drmP.h|2 ++
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 03f16f3..bc105fe 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -345,13 +345,17 @@ int drm_irq_install(struct drm_device *dev)
> if (drm_core_check_feature(dev, DRIVER_IRQ_SHARED))
> sh_flags = IRQF_SHARED;
>
> + if (drm_core_check_feature(dev, DRIVER_IRQ_ONESHOT))
> + sh_flags |= IRQF_ONESHOT;
> +
> if (dev->devname)
> irqname = dev->devname;
> else
> irqname = dev->driver->name;
>
> - ret = request_irq(drm_dev_to_irq(dev), dev->driver->irq_handler,
> - sh_flags, irqname, dev);
> + ret = request_threaded_irq(drm_dev_to_irq(dev),
> + dev->driver->irq_handler, dev->driver->irq_handler_t,
> + sh_flags, irqname, dev);
>
> if (ret < 0) {
> mutex_lock(&dev->struct_mutex);
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index d6b67bb..b28be4b 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -152,6 +152,7 @@ int drm_err(const char *func, const char *format, ...);
> #define DRIVER_GEM 0x1000
> #define DRIVER_MODESET 0x2000
> #define DRIVER_PRIME 0x4000
> +#define DRIVER_IRQ_ONESHOT 0x8000
>
> #define DRIVER_BUS_PCI 0x1
> #define DRIVER_BUS_PLATFORM 0x2
> @@ -872,6 +873,7 @@ struct drm_driver {
> /* these have to be filled in */
>
> irqreturn_t(*irq_handler) (DRM_IRQ_ARGS);
> + irqreturn_t(*irq_handler_t) (DRM_IRQ_ARGS);
> void (*irq_preinstall) (struct drm_device *dev);
> int (*irq_postinstall) (struct drm_device *dev);
> void (*irq_uninstall) (struct drm_device *dev);
> --
> 1.7.0.4
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: fix double call of drm_prime_(init/destroy)_file_private
Dear Inki Dae, Am Donnerstag, den 06.09.2012, 11:35 +0900 schrieb InKi Dae: > 2012/9/6 Mandeep Singh Baines : > > The double invocations are incorrect but seem to be safe so I don't > > think this will fix any bugs. > > > > Before: > > > > [7.639366] drm_prime_init_file ee3675d0 > > [7.639377] drm_prime_init_file ee3675d0 > > [7.639507] drm_prime_destroy_file ee3675d0 > > [7.639518] drm_prime_destroy_file ee3675d0 > > [7.639802] drm_prime_init_file ee372390 > > [7.639810] drm_prime_init_file ee372390 > > [8.473316] drm_prime_init_file ee356390 > > [8.473331] drm_prime_init_file ee356390 > > > > After: > > > > [6.363842] drm_prime_init_file edc2e5d0 > > [6.363994] drm_prime_destroy_file edc2e5d0 > > [6.364260] drm_prime_init_file edc2e750 > > [8.004837] drm_prime_init_file ee36ded0 > > > > Signed-off-by: Mandeep Singh Baines > > CC: Stéphane Marchesin > > CC: Pawel Osciak > > CC: Inki Dae > > CC: Joonyoung Shim > > CC: Seung-Woo Kim > > CC: Kyungmin Park > > CC: David Airlie > > CC: dri-devel@lists.freedesktop.org > > remove all CCs I guess they were generated by some script. So they should be fine, no? Mandeep, if you put CC in here those people should be CCed in real. `git send-email` should take care of that but I do not see everyone in the CC field. Or does `git send-email` use blind carbon copy (BCC) field? > and can you send it again using text mode? At least to the list it was send in plain text mode. > your patch is messed up when I try to get patch file. Everything is fine on my side. Especially since Mandeep used `git send-email` which should do everything correctly. > Thanks. > Inki Dae In your From address your name is written InKi with capital K. Which one is correct? Thanks, Paul signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: fix double call of drm_prime_(init/destroy)_file_private
Hi, 2012/9/6 Paul Menzel : > Dear Inki Dae, > > > Am Donnerstag, den 06.09.2012, 11:35 +0900 schrieb InKi Dae: > >> 2012/9/6 Mandeep Singh Baines : >> > The double invocations are incorrect but seem to be safe so I don't >> > think this will fix any bugs. >> > >> > Before: >> > >> > [7.639366] drm_prime_init_file ee3675d0 >> > [7.639377] drm_prime_init_file ee3675d0 >> > [7.639507] drm_prime_destroy_file ee3675d0 >> > [7.639518] drm_prime_destroy_file ee3675d0 >> > [7.639802] drm_prime_init_file ee372390 >> > [7.639810] drm_prime_init_file ee372390 >> > [8.473316] drm_prime_init_file ee356390 >> > [8.473331] drm_prime_init_file ee356390 >> > >> > After: >> > >> > [6.363842] drm_prime_init_file edc2e5d0 >> > [6.363994] drm_prime_destroy_file edc2e5d0 >> > [6.364260] drm_prime_init_file edc2e750 >> > [8.004837] drm_prime_init_file ee36ded0 >> > >> > Signed-off-by: Mandeep Singh Baines >> > CC: Stéphane Marchesin >> > CC: Pawel Osciak >> > CC: Inki Dae >> > CC: Joonyoung Shim >> > CC: Seung-Woo Kim >> > CC: Kyungmin Park >> > CC: David Airlie >> > CC: dri-devel@lists.freedesktop.org >> >> remove all CCs > > I guess they were generated by some script. So they should be fine, no? > > Mandeep, if you put CC in here those people should be CCed in real. `git > send-email` should take care of that but I do not see everyone in the CC > field. Or does `git send-email` use blind carbon copy (BCC) field? > >> and can you send it again using text mode? > > At least to the list it was send in plain text mode. > >> your patch is messed up when I try to get patch file. > > Everything is fine on my side. Especially since Mandeep used `git > send-email` which should do everything correctly. > your patch was encoded with 'Content-Transfer-Encoding: base64' so please use 7bit ascii like 'Content-Transfer-Encoding: 7bit' >> Thanks. >> Inki Dae > > In your From address your name is written InKi with capital K. Which one > is correct? > Inki is correct :) Thanks. Inki Dae > > Thanks, > > Paul > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 51652] [6550D SUMO] problems with secondar monitor on VGA, causing GPU lockups
https://bugs.freedesktop.org/show_bug.cgi?id=51652 --- Comment #2 from okias 2012-09-06 10:00:32 UTC --- Still valid with kernel 3.6.0-rc4 -- 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 libdrm 2/3] radeon: Memory footprint of SI mipmap base level is padded to powers of two.
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
radeon/radeon_surface.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 593c51c..98faa0b 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -963,9 +963,16 @@ static void si_surf_minify_linear_aligned(struct
radeon_surface *surf,
surf->level[level].npix_x = mip_minify(surf->npix_x, level);
surf->level[level].npix_y = mip_minify(surf->npix_y, level);
surf->level[level].npix_z = mip_minify(surf->npix_z, level);
-surf->level[level].nblk_x = (surf->level[level].npix_x + surf->blk_w - 1)
/ surf->blk_w;
-surf->level[level].nblk_y = (surf->level[level].npix_y + surf->blk_h - 1)
/ surf->blk_h;
-surf->level[level].nblk_z = (surf->level[level].npix_z + surf->blk_d - 1)
/ surf->blk_d;
+
+if (level == 0 && surf->last_level > 0) {
+surf->level[level].nblk_x =
(next_power_of_two(surf->level[level].npix_x) + surf->blk_w - 1) / surf->blk_w;
+surf->level[level].nblk_y =
(next_power_of_two(surf->level[level].npix_y) + surf->blk_h - 1) / surf->blk_h;
+surf->level[level].nblk_z =
(next_power_of_two(surf->level[level].npix_z) + surf->blk_d - 1) / surf->blk_d;
+} else {
+surf->level[level].nblk_x = (surf->level[level].npix_x + surf->blk_w -
1) / surf->blk_w;
+surf->level[level].nblk_y = (surf->level[level].npix_y + surf->blk_h -
1) / surf->blk_h;
+surf->level[level].nblk_z = (surf->level[level].npix_z + surf->blk_d -
1) / surf->blk_d;
+}
/* XXX: Second smallest level uses larger pitch, not sure of the real
reason,
* my best guess so far: rows evenly distributed across slice
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 3/3] radeon: Sampling pitch for non-mipmaps seems padded to slice alignment on SI.
From: Michel Dänzer Another corner case that isn't well-explained yet. Signed-off-by: Michel Dänzer --- radeon/radeon_surface.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c index 98faa0b..80b1505 100644 --- a/radeon/radeon_surface.c +++ b/radeon/radeon_surface.c @@ -974,10 +974,15 @@ static void si_surf_minify_linear_aligned(struct radeon_surface *surf, surf->level[level].nblk_z = (surf->level[level].npix_z + surf->blk_d - 1) / surf->blk_d; } -/* XXX: Second smallest level uses larger pitch, not sure of the real reason, - * my best guess so far: rows evenly distributed across slice +/* XXX: Texture sampling uses unexpectedly large pitches in some cases, + * these are just guesses for the rules behind those */ -xalign = MAX2(xalign, slice_align / surf->bpe / surf->level[level].npix_y); +if (level == 0 && surf->last_level == 0) +/* Non-mipmap pitch padded to slice alignment */ +xalign = MAX2(xalign, slice_align / surf->bpe); +else +/* Small rows evenly distributed across slice */ +xalign = MAX2(xalign, slice_align / surf->bpe / surf->level[level].npix_y); surf->level[level].nblk_x = ALIGN(surf->level[level].nblk_x, xalign); surf->level[level].nblk_y = ALIGN(surf->level[level].nblk_y, yalign); -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 1/3] radeon: Fix layout of linear aligned mipmaps on SI.
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
radeon/radeon_surface.c | 124 ++-
1 file changed, 123 insertions(+), 1 deletion(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 4118a37..593c51c 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -952,6 +952,124 @@ static int eg_surface_best(struct radeon_surface_manager
*surf_man,
/* ===
+ * Southern Islands family
+ */
+
+static void si_surf_minify_linear_aligned(struct radeon_surface *surf,
+ unsigned level,
+ uint32_t xalign, uint32_t yalign,
uint32_t zalign, uint32_t slice_align,
+ unsigned offset)
+{
+surf->level[level].npix_x = mip_minify(surf->npix_x, level);
+surf->level[level].npix_y = mip_minify(surf->npix_y, level);
+surf->level[level].npix_z = mip_minify(surf->npix_z, level);
+surf->level[level].nblk_x = (surf->level[level].npix_x + surf->blk_w - 1)
/ surf->blk_w;
+surf->level[level].nblk_y = (surf->level[level].npix_y + surf->blk_h - 1)
/ surf->blk_h;
+surf->level[level].nblk_z = (surf->level[level].npix_z + surf->blk_d - 1)
/ surf->blk_d;
+
+/* XXX: Second smallest level uses larger pitch, not sure of the real
reason,
+ * my best guess so far: rows evenly distributed across slice
+ */
+xalign = MAX2(xalign, slice_align / surf->bpe / surf->level[level].npix_y);
+
+surf->level[level].nblk_x = ALIGN(surf->level[level].nblk_x, xalign);
+surf->level[level].nblk_y = ALIGN(surf->level[level].nblk_y, yalign);
+surf->level[level].nblk_z = ALIGN(surf->level[level].nblk_z, zalign);
+
+surf->level[level].offset = offset;
+surf->level[level].pitch_bytes = surf->level[level].nblk_x * surf->bpe *
surf->nsamples;
+surf->level[level].slice_size = ALIGN(surf->level[level].pitch_bytes *
surf->level[level].nblk_y, slice_align);
+
+surf->bo_size = offset + surf->level[level].slice_size *
surf->level[level].nblk_z * surf->array_size;
+}
+
+static int si_surface_init_linear_aligned(struct radeon_surface_manager
*surf_man,
+ struct radeon_surface *surf,
+ uint64_t offset, unsigned
start_level)
+{
+uint32_t xalign, yalign, zalign, slice_align;
+unsigned i;
+
+/* compute alignment */
+if (!start_level) {
+surf->bo_alignment = MAX2(256, surf_man->hw_info.group_bytes);
+}
+xalign = MAX2(8, 64 / surf->bpe);
+yalign = 1;
+zalign = 1;
+slice_align = MAX2(64 * surf->bpe, surf_man->hw_info.group_bytes);
+
+/* build mipmap tree */
+for (i = start_level; i <= surf->last_level; i++) {
+surf->level[i].mode = RADEON_SURF_MODE_LINEAR_ALIGNED;
+si_surf_minify_linear_aligned(surf, i, xalign, yalign, zalign,
slice_align, offset);
+/* level0 and first mipmap need to have alignment */
+offset = surf->bo_size;
+if ((i == 0)) {
+offset = ALIGN(offset, surf->bo_alignment);
+}
+}
+return 0;
+}
+
+static int si_surface_init(struct radeon_surface_manager *surf_man,
+ struct radeon_surface *surf)
+{
+unsigned mode;
+int r;
+
+/* MSAA surfaces support the 2D mode only. */
+if (surf->nsamples > 1) {
+surf->flags = RADEON_SURF_CLR(surf->flags, MODE);
+surf->flags |= RADEON_SURF_SET(RADEON_SURF_MODE_2D, MODE);
+}
+
+/* tiling mode */
+mode = (surf->flags >> RADEON_SURF_MODE_SHIFT) & RADEON_SURF_MODE_MASK;
+
+if (surf->flags & (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
+/* zbuffer only support 1D or 2D tiled surface */
+switch (mode) {
+case RADEON_SURF_MODE_1D:
+case RADEON_SURF_MODE_2D:
+break;
+default:
+mode = RADEON_SURF_MODE_1D;
+surf->flags = RADEON_SURF_CLR(surf->flags, MODE);
+surf->flags |= RADEON_SURF_SET(RADEON_SURF_MODE_1D, MODE);
+break;
+}
+}
+
+r = eg_surface_sanity(surf_man, surf, mode);
+if (r) {
+return r;
+}
+
+surf->stencil_offset = 0;
+surf->stencil_tile_split = 0;
+
+/* check tiling mode */
+switch (mode) {
+case RADEON_SURF_MODE_LINEAR:
+r = r6_surface_init_linear(surf_man, surf, 0, 0);
+break;
+case RADEON_SURF_MODE_LINEAR_ALIGNED:
+r = si_surface_init_linear_aligned(surf_man, surf, 0, 0);
+break;
+case RADEON_SURF_MODE_1D:
+r = eg_surface_init_1d(surf_man, surf, 0, 0);
+break;
+case RADEON_SURF_MODE_2D:
+r = eg_surface_init_2d(surf_man, surf, 0, 0);
+break;
+default:
+return -EINVAL;
+}
+return r;
+}
+
+/* ===
Re: [PATCH V4 2/2] video: drm: exynos: Add device tree support
Hi, On 09/06/2012 09:21 AM, InKi Dae wrote: >>> +Required properties: >>> + - compatible: Should be "samsung,exynos5-fimd" or "samsung,exynos4-fb" for >> Doesn't better to use single word? fimd or fb?. I think 'fb' is used >> for framebuffer historically. >> but now it's used both fb and drm, so fimd is neutral and architecture >> specific. >> >> To do this, Modify arch-exynos first and update it at each drivers it >> properly. >> >> Thank you, >> Kyungmin Park >> > > I agree with Kyungmin but I'd like to use as is. the reason we used > 'exynos4-fb' as device name, is for that it uses fimd driver's > platform device commonly and gets fimd clock. so I think that dts file > should be defined with hardware specific name but not driver name such > as 'exynos4-fb'. but with this, we can't get fimd clock with device's > name because 'exynos4-fb' is used as device name of fimd clock. so to > use 'exynos4-fimd', we should modify the device name of fimd clock > from 'exynos4-fb' to 'exynos4-fimd' and also ids definitions of > s3c-fb and drm fimd driver. so my conclusion is that it merges this I think it's good moment to put those things in order, i.e. use uniform 'compatible' names: "samsung,exynos4-fimd", "samsung,exynos5-fimd". Platform device names are separate issue, but could perhaps be unified at this time as well. > patch set as is and then let's modify related things later. > any opinions, welcome~ anytime. > > Thanks. > Inki Dae -- Regards, Sylwester ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 1/3] radeon: Fix layout of linear aligned mipmaps on SI.
On 06.09.2012 12:53, Michel Dänzer wrote:
From: Michel Dänzer
Signed-off-by: Michel Dänzer
Sounds good to me, but shouldn't we also increase the version number?
Anyway: Reviewed-by: Christian König
---
radeon/radeon_surface.c | 124 ++-
1 file changed, 123 insertions(+), 1 deletion(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 4118a37..593c51c 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -952,6 +952,124 @@ static int eg_surface_best(struct radeon_surface_manager
*surf_man,
/* ===
+ * Southern Islands family
+ */
+
+static void si_surf_minify_linear_aligned(struct radeon_surface *surf,
+ unsigned level,
+ uint32_t xalign, uint32_t yalign,
uint32_t zalign, uint32_t slice_align,
+ unsigned offset)
+{
+surf->level[level].npix_x = mip_minify(surf->npix_x, level);
+surf->level[level].npix_y = mip_minify(surf->npix_y, level);
+surf->level[level].npix_z = mip_minify(surf->npix_z, level);
+surf->level[level].nblk_x = (surf->level[level].npix_x + surf->blk_w - 1) /
surf->blk_w;
+surf->level[level].nblk_y = (surf->level[level].npix_y + surf->blk_h - 1) /
surf->blk_h;
+surf->level[level].nblk_z = (surf->level[level].npix_z + surf->blk_d - 1) /
surf->blk_d;
+
+/* XXX: Second smallest level uses larger pitch, not sure of the real
reason,
+ * my best guess so far: rows evenly distributed across slice
+ */
+xalign = MAX2(xalign, slice_align / surf->bpe / surf->level[level].npix_y);
+
+surf->level[level].nblk_x = ALIGN(surf->level[level].nblk_x, xalign);
+surf->level[level].nblk_y = ALIGN(surf->level[level].nblk_y, yalign);
+surf->level[level].nblk_z = ALIGN(surf->level[level].nblk_z, zalign);
+
+surf->level[level].offset = offset;
+surf->level[level].pitch_bytes = surf->level[level].nblk_x * surf->bpe *
surf->nsamples;
+surf->level[level].slice_size = ALIGN(surf->level[level].pitch_bytes *
surf->level[level].nblk_y, slice_align);
+
+surf->bo_size = offset + surf->level[level].slice_size *
surf->level[level].nblk_z * surf->array_size;
+}
+
+static int si_surface_init_linear_aligned(struct radeon_surface_manager
*surf_man,
+ struct radeon_surface *surf,
+ uint64_t offset, unsigned
start_level)
+{
+uint32_t xalign, yalign, zalign, slice_align;
+unsigned i;
+
+/* compute alignment */
+if (!start_level) {
+surf->bo_alignment = MAX2(256, surf_man->hw_info.group_bytes);
+}
+xalign = MAX2(8, 64 / surf->bpe);
+yalign = 1;
+zalign = 1;
+slice_align = MAX2(64 * surf->bpe, surf_man->hw_info.group_bytes);
+
+/* build mipmap tree */
+for (i = start_level; i <= surf->last_level; i++) {
+surf->level[i].mode = RADEON_SURF_MODE_LINEAR_ALIGNED;
+si_surf_minify_linear_aligned(surf, i, xalign, yalign, zalign,
slice_align, offset);
+/* level0 and first mipmap need to have alignment */
+offset = surf->bo_size;
+if ((i == 0)) {
+offset = ALIGN(offset, surf->bo_alignment);
+}
+}
+return 0;
+}
+
+static int si_surface_init(struct radeon_surface_manager *surf_man,
+ struct radeon_surface *surf)
+{
+unsigned mode;
+int r;
+
+/* MSAA surfaces support the 2D mode only. */
+if (surf->nsamples > 1) {
+surf->flags = RADEON_SURF_CLR(surf->flags, MODE);
+surf->flags |= RADEON_SURF_SET(RADEON_SURF_MODE_2D, MODE);
+}
+
+/* tiling mode */
+mode = (surf->flags >> RADEON_SURF_MODE_SHIFT) & RADEON_SURF_MODE_MASK;
+
+if (surf->flags & (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
+/* zbuffer only support 1D or 2D tiled surface */
+switch (mode) {
+case RADEON_SURF_MODE_1D:
+case RADEON_SURF_MODE_2D:
+break;
+default:
+mode = RADEON_SURF_MODE_1D;
+surf->flags = RADEON_SURF_CLR(surf->flags, MODE);
+surf->flags |= RADEON_SURF_SET(RADEON_SURF_MODE_1D, MODE);
+break;
+}
+}
+
+r = eg_surface_sanity(surf_man, surf, mode);
+if (r) {
+return r;
+}
+
+surf->stencil_offset = 0;
+surf->stencil_tile_split = 0;
+
+/* check tiling mode */
+switch (mode) {
+case RADEON_SURF_MODE_LINEAR:
+r = r6_surface_init_linear(surf_man, surf, 0, 0);
+break;
+case RADEON_SURF_MODE_LINEAR_ALIGNED:
+r = si_surface_init_linear_aligned(surf_man, surf, 0, 0);
+break;
+case RADEON_SURF_MODE_1D:
+r = eg_surface_init_1d(surf_man, surf, 0, 0);
+break;
+case RADEON_SURF_MODE_2D:
+r = eg_surface_init_2d(surf_man, surf, 0, 0);
[PATCH] drm/radeon: fix VM syncing with multiple rings
When a VM is used on more than one ring we need to sync to the last user. Signed-off-by: Christian König --- drivers/gpu/drm/radeon/radeon_cs.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c index e241506..d59eb59 100644 --- a/drivers/gpu/drm/radeon/radeon_cs.c +++ b/drivers/gpu/drm/radeon/radeon_cs.c @@ -463,7 +463,7 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev, goto out; } radeon_cs_sync_rings(parser); - radeon_cs_sync_to(parser, vm->last_flush); + radeon_cs_sync_to(parser, vm->fence); radeon_cs_sync_to(parser, radeon_vm_grab_id(rdev, vm, parser->ring)); if ((rdev->family >= CHIP_TAHITI) && -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 1/3] radeon: Fix layout of linear aligned mipmaps on SI.
On Don, 2012-09-06 at 13:46 +0200, Christian König wrote: > On 06.09.2012 12:53, Michel Dänzer wrote: > > From: Michel Dänzer > > > > Signed-off-by: Michel Dänzer > Sounds good to me, but shouldn't we also increase the version number? Assuming you mean the libdrm package version, I don't think it's worth doing that just for these fixes. At this point, one should always use latest Git of mesa and libdrm for radeonsi. But of course, once a libdrm release is out with these fixes, we can require that as the minimum version for radeonsi. > Anyway: Reviewed-by: Christian König Thanks, is that for the whole series? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 1/3] radeon: Fix layout of linear aligned mipmaps on SI.
On 06.09.2012 15:01, Michel Dänzer wrote: On Don, 2012-09-06 at 13:46 +0200, Christian König wrote: On 06.09.2012 12:53, Michel Dänzer wrote: From: Michel Dänzer Signed-off-by: Michel Dänzer Sounds good to me, but shouldn't we also increase the version number? Assuming you mean the libdrm package version, I don't think it's worth doing that just for these fixes. At this point, one should always use latest Git of mesa and libdrm for radeonsi. But of course, once a libdrm release is out with these fixes, we can require that as the minimum version for radeonsi. Ok, that makes sense. Anyway: Reviewed-by: Christian König Thanks, is that for the whole series? Yes it is, and also for the four patches to radeonsi which depends on this change. Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
radeon power management issues on a 12,2 iMac
I've posted this here simply as google bait for the next poor sod suffering with radeon power management issues. Why does the in-kernel radeon driver try and cook my machine by default? Since I bought this machine, I've run with a hard-coded hack to keep the card in low power mode. This has not previously had any issues, even to being able to watch three full screen HD streams (one on each head). A recent change to the radeon driver left me with noise on the right hand side of all three heads, and a plea for assistance was me with a response that multiple heads are not supported in low-power mode (thus my hack in the first place). The issue here is that all the multi-head profiles run the card in the highest power profile, and the machine ends up sounding like a 747 trying to keep the card cool. Poking into radeon_asic.c tells me my cards power profiles are setup in : r600_pm_init_profile Time to have a look at what profiles the card actually has. Enabling dri debugging and booting up leaves this in my log Sep 6 13:47:37 localhost kernel: [3.919380] [drm:radeon_pm_print_states], 5 Power State(s) Sep 6 13:47:37 localhost kernel: [3.919381] [drm:radeon_pm_print_states], State 0: Default Sep 6 13:47:37 localhost kernel: [3.919382] [drm:radeon_pm_print_states], Default Sep 6 13:47:37 localhost kernel: [3.919383] [drm:radeon_pm_print_states], 16 PCIE Lanes Sep 6 13:47:37 localhost kernel: [3.919384] [drm:radeon_pm_print_states], 3 Clock Mode(s) Sep 6 13:47:37 localhost kernel: [3.919385] [drm:radeon_pm_print_states], 0 e: 68 m: 90 v: 1100 No display only Sep 6 13:47:37 localhost kernel: [3.919386] [drm:radeon_pm_print_states], 1 e: 68 m: 90 v: 1100 Sep 6 13:47:37 localhost kernel: [3.919387] [drm:radeon_pm_print_states], 2 e: 68 m: 90 v: 1100 Sep 6 13:47:37 localhost kernel: [3.919388] [drm:radeon_pm_print_states], State 1: Performance Sep 6 13:47:37 localhost kernel: [3.919389] [drm:radeon_pm_print_states], 16 PCIE Lanes Sep 6 13:47:37 localhost kernel: [3.919390] [drm:radeon_pm_print_states], 3 Clock Mode(s) Sep 6 13:47:37 localhost kernel: [3.919391] [drm:radeon_pm_print_states], 0 e: 10 m: 149000 v: 900 No display only Sep 6 13:47:37 localhost kernel: [3.919392] [drm:radeon_pm_print_states], 1 e: 398000 m: 90 v: 1000 Sep 6 13:47:37 localhost kernel: [3.919393] [drm:radeon_pm_print_states], 2 e: 68 m: 90 v: 1100 Sep 6 13:47:37 localhost kernel: [3.919395] [drm:radeon_pm_print_states], State 2: Default Sep 6 13:47:37 localhost kernel: [3.919395] [drm:radeon_pm_print_states], 16 PCIE Lanes Sep 6 13:47:37 localhost kernel: [3.919396] [drm:radeon_pm_print_states], 3 Clock Mode(s) Sep 6 13:47:37 localhost kernel: [3.919397] [drm:radeon_pm_print_states], 0 e: 298000 m: 90 v: 950 No display only Sep 6 13:47:37 localhost kernel: [3.919398] [drm:radeon_pm_print_states], 1 e: 298000 m: 90 v: 950 Sep 6 13:47:37 localhost kernel: [3.919399] [drm:radeon_pm_print_states], 2 e: 68 m: 90 v: 1100 Sep 6 13:47:37 localhost kernel: [3.919400] [drm:radeon_pm_print_states], State 3: Default Sep 6 13:47:37 localhost kernel: [3.919401] [drm:radeon_pm_print_states], 16 PCIE Lanes Sep 6 13:47:37 localhost kernel: [3.919402] [drm:radeon_pm_print_states], 3 Clock Mode(s) Sep 6 13:47:37 localhost kernel: [3.919403] [drm:radeon_pm_print_states], 0 e: 502000 m: 90 v: 1050 No display only Sep 6 13:47:37 localhost kernel: [3.919404] [drm:radeon_pm_print_states], 1 e: 502000 m: 90 v: 1050 Sep 6 13:47:37 localhost kernel: [3.919405] [drm:radeon_pm_print_states], 2 e: 68 m: 90 v: 1100 Sep 6 13:47:37 localhost kernel: [3.919406] [drm:radeon_pm_print_states], State 4: Battery Sep 6 13:47:37 localhost kernel: [3.919407] [drm:radeon_pm_print_states], 16 PCIE Lanes Sep 6 13:47:37 localhost kernel: [3.919408] [drm:radeon_pm_print_states], 3 Clock Mode(s) Sep 6 13:47:37 localhost kernel: [3.919409] [drm:radeon_pm_print_states], 0 e: 10 m: 149000 v: 900 No display only Sep 6 13:47:37 localhost kernel: [3.919410] [drm:radeon_pm_print_states], 1 e: 10 m: 149000 v: 900 Sep 6 13:47:37 localhost kernel: [3.919411] [drm:radeon_pm_print_states], 2 e: 10 m: 149000 v: 900 Sep 6 13:47:37 localhost kernel: [3.920559] [drm] radeon: power management initialized So, because my GPU is a mobile device (rdev->flags & RADEON_IS_MOBILITY is true), then my single head profiles are selected from the Battery profile, and because there is not a second Battery profile the multi-head profiles come from profile 0 (default). This card actually has 3 prof
drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot
Dave - I couldn't find this patch in your git repo at git://people.freedesktop.org/~airlied/linux in the drm-next or drm-fixes branches. https://patchwork.kernel.org/patch/1379071/ It appears to fix a real problem for Mac users - http://bugs.launchpad.net/bugs/1039157. See https://bugs.launchpad.net/ubuntu/oneiric/+source/linux/+bug/1039157/comments/31 for confirmation. I think it should also be 'Cc: sta...@vger.kernel.org'. It applies as far back as 2.6.32 with minor context differences. rtg -- Tim Gardner tim.gard...@canonical.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 1/3] radeon: Fix layout of linear aligned mipmaps on SI.
On Thu, Sep 6, 2012 at 6:53 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
for the series:
Reviewed-by: Alex Deucher
> ---
> radeon/radeon_surface.c | 124
> ++-
> 1 file changed, 123 insertions(+), 1 deletion(-)
>
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 4118a37..593c51c 100644
> --- a/radeon/radeon_surface.c
> +++ b/radeon/radeon_surface.c
> @@ -952,6 +952,124 @@ static int eg_surface_best(struct
> radeon_surface_manager *surf_man,
>
>
> /*
> ===
> + * Southern Islands family
> + */
> +
> +static void si_surf_minify_linear_aligned(struct radeon_surface *surf,
> + unsigned level,
> + uint32_t xalign, uint32_t yalign,
> uint32_t zalign, uint32_t slice_align,
> + unsigned offset)
> +{
> +surf->level[level].npix_x = mip_minify(surf->npix_x, level);
> +surf->level[level].npix_y = mip_minify(surf->npix_y, level);
> +surf->level[level].npix_z = mip_minify(surf->npix_z, level);
> +surf->level[level].nblk_x = (surf->level[level].npix_x + surf->blk_w -
> 1) / surf->blk_w;
> +surf->level[level].nblk_y = (surf->level[level].npix_y + surf->blk_h -
> 1) / surf->blk_h;
> +surf->level[level].nblk_z = (surf->level[level].npix_z + surf->blk_d -
> 1) / surf->blk_d;
> +
> +/* XXX: Second smallest level uses larger pitch, not sure of the real
> reason,
> + * my best guess so far: rows evenly distributed across slice
> + */
> +xalign = MAX2(xalign, slice_align / surf->bpe /
> surf->level[level].npix_y);
> +
> +surf->level[level].nblk_x = ALIGN(surf->level[level].nblk_x, xalign);
> +surf->level[level].nblk_y = ALIGN(surf->level[level].nblk_y, yalign);
> +surf->level[level].nblk_z = ALIGN(surf->level[level].nblk_z, zalign);
> +
> +surf->level[level].offset = offset;
> +surf->level[level].pitch_bytes = surf->level[level].nblk_x * surf->bpe *
> surf->nsamples;
> +surf->level[level].slice_size = ALIGN(surf->level[level].pitch_bytes *
> surf->level[level].nblk_y, slice_align);
> +
> +surf->bo_size = offset + surf->level[level].slice_size *
> surf->level[level].nblk_z * surf->array_size;
> +}
> +
> +static int si_surface_init_linear_aligned(struct radeon_surface_manager
> *surf_man,
> + struct radeon_surface *surf,
> + uint64_t offset, unsigned
> start_level)
> +{
> +uint32_t xalign, yalign, zalign, slice_align;
> +unsigned i;
> +
> +/* compute alignment */
> +if (!start_level) {
> +surf->bo_alignment = MAX2(256, surf_man->hw_info.group_bytes);
> +}
> +xalign = MAX2(8, 64 / surf->bpe);
> +yalign = 1;
> +zalign = 1;
> +slice_align = MAX2(64 * surf->bpe, surf_man->hw_info.group_bytes);
> +
> +/* build mipmap tree */
> +for (i = start_level; i <= surf->last_level; i++) {
> +surf->level[i].mode = RADEON_SURF_MODE_LINEAR_ALIGNED;
> +si_surf_minify_linear_aligned(surf, i, xalign, yalign, zalign,
> slice_align, offset);
> +/* level0 and first mipmap need to have alignment */
> +offset = surf->bo_size;
> +if ((i == 0)) {
> +offset = ALIGN(offset, surf->bo_alignment);
> +}
> +}
> +return 0;
> +}
> +
> +static int si_surface_init(struct radeon_surface_manager *surf_man,
> + struct radeon_surface *surf)
> +{
> +unsigned mode;
> +int r;
> +
> +/* MSAA surfaces support the 2D mode only. */
> +if (surf->nsamples > 1) {
> +surf->flags = RADEON_SURF_CLR(surf->flags, MODE);
> +surf->flags |= RADEON_SURF_SET(RADEON_SURF_MODE_2D, MODE);
> +}
> +
> +/* tiling mode */
> +mode = (surf->flags >> RADEON_SURF_MODE_SHIFT) & RADEON_SURF_MODE_MASK;
> +
> +if (surf->flags & (RADEON_SURF_ZBUFFER | RADEON_SURF_SBUFFER)) {
> +/* zbuffer only support 1D or 2D tiled surface */
> +switch (mode) {
> +case RADEON_SURF_MODE_1D:
> +case RADEON_SURF_MODE_2D:
> +break;
> +default:
> +mode = RADEON_SURF_MODE_1D;
> +surf->flags = RADEON_SURF_CLR(surf->flags, MODE);
> +surf->flags |= RADEON_SURF_SET(RADEON_SURF_MODE_1D, MODE);
> +break;
> +}
> +}
> +
> +r = eg_surface_sanity(surf_man, surf, mode);
> +if (r) {
> +return r;
> +}
> +
> +surf->stencil_offset = 0;
> +surf->stencil_tile_split = 0;
> +
> +/* check tiling mode */
> +switch (mode) {
> +case RADEON_SURF_MODE_LINEAR:
> +r = r6_surface_init_linear(surf_man, surf, 0, 0);
> +break;
> +case RADEON_SURF_MODE_LINEAR_ALIGNED:
> +r = si_surface_init_linear_aligned(surf_man, surf, 0, 0);
>
Re: drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot
On Thu, Sep 6, 2012 at 3:35 PM, Tim Gardner wrote: > Dave - I couldn't find this patch in your git repo at > git://people.freedesktop.org/~airlied/linux in the drm-next or drm-fixes > branches. > > https://patchwork.kernel.org/patch/1379071/ > > It appears to fix a real problem for Mac users - > http://bugs.launchpad.net/bugs/1039157. See > https://bugs.launchpad.net/ubuntu/oneiric/+source/linux/+bug/1039157/comments/31 > for confirmation. Thanks, I was going to point out that Dave had already fix this, but it seem you already knew about that. There is a companion patch along side with the one mentioned. http://lists.freedesktop.org/archives/dri-devel/2012-August/027124.html http://lists.freedesktop.org/archives/dri-devel/2012-August/027125.html I recommend applying both and turning the config to yes (as long as you have the kms enabled xf86-video-vmware driver installed). I RB:ed them both along with the dumb ioctl interface here: http://lists.freedesktop.org/archives/dri-devel/2012-August/027139.html > > I think it should also be 'Cc: sta...@vger.kernel.org'. It applies as > far back as 2.6.32 with minor context differences. > > rtg Its probably safe, but it could mean that the driver gets loaded on distros, where in the past it hasn't tho that should be safe. Cheers, Jakob. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix VM syncing with multiple rings
On Thu, Sep 6, 2012 at 7:48 AM, Christian König wrote: > When a VM is used on more than one ring we need to > sync to the last user. > > Signed-off-by: Christian König Reviewed-by: Jerome Glisse > --- > drivers/gpu/drm/radeon/radeon_cs.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_cs.c > b/drivers/gpu/drm/radeon/radeon_cs.c > index e241506..d59eb59 100644 > --- a/drivers/gpu/drm/radeon/radeon_cs.c > +++ b/drivers/gpu/drm/radeon/radeon_cs.c > @@ -463,7 +463,7 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device > *rdev, > goto out; > } > radeon_cs_sync_rings(parser); > - radeon_cs_sync_to(parser, vm->last_flush); > + radeon_cs_sync_to(parser, vm->fence); > radeon_cs_sync_to(parser, radeon_vm_grab_id(rdev, vm, parser->ring)); > > if ((rdev->family >= CHIP_TAHITI) && > -- > 1.7.9.5 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
PCI Radeon RV100 detection hang on sparc64
This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in Ultra 10 (clean, without my "Video RAM" hack that I talked in other sparclinux posts). When I saw that Sun XVR-100 was detected fine by the kernel, I compiled radeon drm driver with modesetting enabled and tried it: [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. PCI: Enabling device: (:02:02.0), cmd 82 [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908). [drm] register mmio base: 0x1000 [drm] register mmio size: 32768 [drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR And here the machine hangs. Debugging printk-s reveal that it does not find any active I/O port resources and then continues into initializing the card. Down in igp_read_bios_from_vram() it successfully ioremaps memory region 0 (vram_base=1ff0800 and size=4) and tries to read 2 bytes from there and hangs on reading bios[0]. With radeon.modeset=0, it boots and I collected the following info: 02:02.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA controller]) Subsystem: Advanced Micro Devices [AMD] nee ATI XVR-100 (supplied by Sun) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43360] nouveau on "NVce" 560 Ti: Failed to idle channel 1
https://bugzilla.kernel.org/show_bug.cgi?id=43360 Alan changed: What|Removed |Added CC||a...@lxorguk.ukuu.org.uk Component|Staging |Video(DRI - non Intel) AssignedTo|drivers_staging@kernel-bugs |drivers_video-dri@kernel-bu |.osdl.org |gs.osdl.org -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: fix double call of drm_prime_(init/destroy)_file_private
The double invocations are incorrect but seem to be safe so I don't think this will fix any bugs. Before: [7.639366] drm_prime_init_file ee3675d0 [7.639377] drm_prime_init_file ee3675d0 [7.639507] drm_prime_destroy_file ee3675d0 [7.639518] drm_prime_destroy_file ee3675d0 [7.639802] drm_prime_init_file ee372390 [7.639810] drm_prime_init_file ee372390 [8.473316] drm_prime_init_file ee356390 [8.473331] drm_prime_init_file ee356390 After: [6.363842] drm_prime_init_file edc2e5d0 [6.363994] drm_prime_destroy_file edc2e5d0 [6.364260] drm_prime_init_file edc2e750 [8.004837] drm_prime_init_file ee36ded0 Signed-off-by: Mandeep Singh Baines Acked-by: Seung-Woo Kim --- drivers/gpu/drm/exynos/exynos_drm_drv.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index ebacec6..a27b8ff 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -160,7 +160,6 @@ static int exynos_drm_open(struct drm_device *dev, struct drm_file *file) if (!file_priv) return -ENOMEM; - drm_prime_init_file_private(&file->prime); file->driver_priv = file_priv; return exynos_drm_subdrv_open(dev, file); @@ -184,7 +183,6 @@ static void exynos_drm_preclose(struct drm_device *dev, e->base.destroy(&e->base); } } - drm_prime_destroy_file_private(&file->prime); spin_unlock_irqrestore(&dev->event_lock, flags); exynos_drm_subdrv_close(dev, file); -- 1.7.7.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PCI Radeon RV100 detection hang on sparc64
On Thu, 2012-09-06 at 17:41 +0300, Meelis Roos wrote: > [drm] radeon defaulting to kernel modesetting. > [drm] radeon kernel modesetting enabled. > PCI: Enabling device: (:02:02.0), cmd 82 > [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908). > [drm] register mmio base: 0x1000 > [drm] register mmio size: 32768 > [drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR This particular message looks like it might actually be harmless, all the code paths that use the I/O BAR can use the MMIO mirror of it instead. No idea how well tested that is, but at any rate it's not what's breaking your setup. > And here the machine hangs. Debugging printk-s reveal that it does not > find any active I/O port resources and then continues into initializing > the card. Down in igp_read_bios_from_vram() it successfully ioremaps > memory region 0 (vram_base=1ff0800 and size=4) and tries to read > 2 bytes from there and hangs on reading bios[0]. This is probably because... > 02:02.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV100 > QY [Radeon 7000/VE] (prog-if 00 [VGA controller]) > Subsystem: Advanced Micro Devices [AMD] nee ATI XVR-100 (supplied by > Sun) > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping+ SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 0 (2000ns min) > Interrupt: pin A routed to IRQ 16 > Region 0: Memory at 0800 (32-bit, prefetchable) [size=64M] > Region 1: I/O ports at 0400 [disabled] [size=256] > Region 2: Memory at 1000 (32-bit, non-prefetchable) [size=32K] > Region 3: [virtual] Memory at fe01 (32-bit, > non-prefetchable) [size=1] > Region 4: [virtual] Memory at fe01 (32-bit, > non-prefetchable) [size=1] > Region 5: [virtual] Memory at fe01 (32-bit, > non-prefetchable) [size=1] > Expansion ROM at 1002 [disabled] [size=128K] ... the ROM BAR looks like it's not routed. On x86 you could fix this by booting with 'pci=rom' to force the ROM BAR to be routed regardless of firmware setup, no idea how that's meant to work on sparc though. - ajax signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PCI Radeon RV100 detection hang on sparc64
On Don, 2012-09-06 at 17:41 +0300, Meelis Roos wrote: > This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in > Ultra 10 (clean, without my "Video RAM" hack that I talked in other > sparclinux posts). When I saw that Sun XVR-100 was detected fine by the > kernel, I compiled radeon drm driver with modesetting enabled and tried > it: > > [drm] radeon defaulting to kernel modesetting. > [drm] radeon kernel modesetting enabled. > PCI: Enabling device: (:02:02.0), cmd 82 > [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908). > [drm] register mmio base: 0x1000 > [drm] register mmio size: 32768 > [drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR > > And here the machine hangs. Debugging printk-s reveal that it does not > find any active I/O port resources and then continues into initializing > the card. Down in igp_read_bios_from_vram() it successfully ioremaps > memory region 0 (vram_base=1ff0800 and size=4) and tries to read > 2 bytes from there and hangs on reading bios[0]. Is the card initialized by OpenFirmware? E.g., does it display anything before the kernel boots? > With radeon.modeset=0, it boots [...] Does X work with DRI enabled then? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #25 from Alexandre Demers 2012-09-06 17:19:09 UTC --- I'll have to confirm it later today by disabling VM, but I'm pretty sure I experienced a lock (can be reproduced every time) related to VM when testing with Unigine Tropics. It loaded, the demo began and then it locked when the island appeared at the horizon (I guess that's what it is since it was the first time I was running this demo). >From the retrieved logs, I could only identify a GPU lock with a reset that failed to reset rings properly. -- 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
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #50 from Alexandre Demers 2012-09-06 17:24:39 UTC --- I've seen some messages about Hi-Z being released, but not enabled and so on a couple of weeks ago. What is the status? -- 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
[Bug 43360] nouveau on "NVce" 560 Ti: Failed to idle channel 1
https://bugzilla.kernel.org/show_bug.cgi?id=43360 Marcin Slusarz changed: What|Removed |Added CC||marcin.slus...@gmail.com --- Comment #4 from Marcin Slusarz 2012-09-06 17:54:55 --- Can you test 3.6-rc4? It's probably fixed in this version. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 54527] Crash, kernel BUG ttm/ttm_bo.c:1659!, when running gnibbles
https://bugs.freedesktop.org/show_bug.cgi?id=54527 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Michel Dänzer 2012-09-06 18:18:05 UTC --- Thanks for confirming. -- 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: [PATCH V4 2/2] video: drm: exynos: Add device tree support
Hi, On Thu, Sep 6, 2012 at 4:35 PM, Sylwester Nawrocki wrote: > Hi, > > On 09/06/2012 09:21 AM, InKi Dae wrote: +Required properties: + - compatible: Should be "samsung,exynos5-fimd" or "samsung,exynos4-fb" for >>> Doesn't better to use single word? fimd or fb?. I think 'fb' is used >>> for framebuffer historically. >>> but now it's used both fb and drm, so fimd is neutral and architecture >>> specific. >>> >>> To do this, Modify arch-exynos first and update it at each drivers it >>> properly. >>> >>> Thank you, >>> Kyungmin Park >>> >> >> I agree with Kyungmin but I'd like to use as is. the reason we used >> 'exynos4-fb' as device name, is for that it uses fimd driver's >> platform device commonly and gets fimd clock. so I think that dts file >> should be defined with hardware specific name but not driver name such >> as 'exynos4-fb'. but with this, we can't get fimd clock with device's >> name because 'exynos4-fb' is used as device name of fimd clock. so to >> use 'exynos4-fimd', we should modify the device name of fimd clock >> from 'exynos4-fb' to 'exynos4-fimd' and also ids definitions of >> s3c-fb and drm fimd driver. so my conclusion is that it merges this > > I think it's good moment to put those things in order, i.e. use uniform > 'compatible' names: "samsung,exynos4-fimd", "samsung,exynos5-fimd". > Platform device names are separate issue, but could perhaps be unified > at this time as well. Yes, Platform device name is independent of compatible string. Will change the compatible string to "samsung,exynos4-fimd" and will keep the device name as exynos4-fb for now. Will change the platform device names to exynosX-fimd later. > >> patch set as is and then let's modify related things later. >> any opinions, welcome~ anytime. >> >> Thanks. >> Inki Dae > > -- > > Regards, > Sylwester > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: fix double call of drm_prime_(init/destroy)_file_private
Applied. Thanks, Inki Dae 2012/9/7 Mandeep Singh Baines : > The double invocations are incorrect but seem to be safe so I don't > think this will fix any bugs. > > Before: > > [7.639366] drm_prime_init_file ee3675d0 > [7.639377] drm_prime_init_file ee3675d0 > [7.639507] drm_prime_destroy_file ee3675d0 > [7.639518] drm_prime_destroy_file ee3675d0 > [7.639802] drm_prime_init_file ee372390 > [7.639810] drm_prime_init_file ee372390 > [8.473316] drm_prime_init_file ee356390 > [8.473331] drm_prime_init_file ee356390 > > After: > > [6.363842] drm_prime_init_file edc2e5d0 > [6.363994] drm_prime_destroy_file edc2e5d0 > [6.364260] drm_prime_init_file edc2e750 > [8.004837] drm_prime_init_file ee36ded0 > > Signed-off-by: Mandeep Singh Baines > Acked-by: Seung-Woo Kim > --- > drivers/gpu/drm/exynos/exynos_drm_drv.c |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c > b/drivers/gpu/drm/exynos/exynos_drm_drv.c > index ebacec6..a27b8ff 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c > @@ -160,7 +160,6 @@ static int exynos_drm_open(struct drm_device *dev, struct > drm_file *file) > if (!file_priv) > return -ENOMEM; > > - drm_prime_init_file_private(&file->prime); > file->driver_priv = file_priv; > > return exynos_drm_subdrv_open(dev, file); > @@ -184,7 +183,6 @@ static void exynos_drm_preclose(struct drm_device *dev, > e->base.destroy(&e->base); > } > } > - drm_prime_destroy_file_private(&file->prime); > spin_unlock_irqrestore(&dev->event_lock, flags); > > exynos_drm_subdrv_close(dev, file); > -- > 1.7.7.3 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 2/2] video: drm: exynos: Add device tree support
Hi 2012/9/7 Leela Krishna Amudala : > Hi, > > On Thu, Sep 6, 2012 at 4:35 PM, Sylwester Nawrocki > wrote: >> Hi, >> >> On 09/06/2012 09:21 AM, InKi Dae wrote: > +Required properties: > + - compatible: Should be "samsung,exynos5-fimd" or "samsung,exynos4-fb" > for Doesn't better to use single word? fimd or fb?. I think 'fb' is used for framebuffer historically. but now it's used both fb and drm, so fimd is neutral and architecture specific. To do this, Modify arch-exynos first and update it at each drivers it properly. Thank you, Kyungmin Park >>> >>> I agree with Kyungmin but I'd like to use as is. the reason we used >>> 'exynos4-fb' as device name, is for that it uses fimd driver's >>> platform device commonly and gets fimd clock. so I think that dts file >>> should be defined with hardware specific name but not driver name such >>> as 'exynos4-fb'. but with this, we can't get fimd clock with device's >>> name because 'exynos4-fb' is used as device name of fimd clock. so to >>> use 'exynos4-fimd', we should modify the device name of fimd clock >>> from 'exynos4-fb' to 'exynos4-fimd' and also ids definitions of >>> s3c-fb and drm fimd driver. so my conclusion is that it merges this >> >> I think it's good moment to put those things in order, i.e. use uniform >> 'compatible' names: "samsung,exynos4-fimd", "samsung,exynos5-fimd". >> Platform device names are separate issue, but could perhaps be unified >> at this time as well. > > Yes, Platform device name is independent of compatible string. > Will change the compatible string to "samsung,exynos4-fimd" and will keep the > device name as exynos4-fb for now. Will change the platform device > names to exynosX-fimd > later. > I'm not sure that clk_get is worked well with this change. I think, when driver called clk_get(), first of all, it tries to get a clk from the registered list of clock providers in the dts file and next in legacy way. but now legacy way(needing clock name and device' name) would be failed if the dts file has no the list because platform device's name differs from device name of clock. so I think we should change device name of clock and also ids of related drivers for compatibility with non-dt. for this, we need some patch sets, changing arch/arm/mach-exynos/common.c and changing arch/arm/mach-exynos/clock-exynos4/5.c and changing s3c-fb.c and last this patch. if there are no other opinions, I'd like to merge this patch set(v5) and next we can update others(maybe common.c, clock-exynos4/5.c and s3c-fb.c) later. Thanks. Inki Dae >> >>> patch set as is and then let's modify related things later. >>> any opinions, welcome~ anytime. >>> >>> Thanks. >>> Inki Dae >> >> -- >> >> Regards, >> Sylwester >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" >> 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PCI Radeon RV100 detection hang on sparc64
From: Meelis Roos Date: Thu, 6 Sep 2012 17:41:13 +0300 (EEST) > And here the machine hangs. Debugging printk-s reveal that it does not > find any active I/O port resources and then continues into initializing > the card. Down in igp_read_bios_from_vram() it successfully ioremaps > memory region 0 (vram_base=1ff0800 and size=4) and tries to read > 2 bytes from there and hangs on reading bios[0]. Mappings obtained from ioremap() may not be derefenced directly. What you get back from ioremap() isn't a pointer. It's an opaque __iomem cookie, which must only be used via readl() et al. On sparc64 ioremap() happens to return a physical address, that's why this non-portable code crashes. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PCI Radeon RV100 detection hang on sparc64
From: Adam Jackson Date: Thu, 06 Sep 2012 12:51:17 -0400 > On Thu, 2012-09-06 at 17:41 +0300, Meelis Roos wrote: > >> And here the machine hangs. Debugging printk-s reveal that it does not >> find any active I/O port resources and then continues into initializing >> the card. Down in igp_read_bios_from_vram() it successfully ioremaps >> memory region 0 (vram_base=1ff0800 and size=4) and tries to read >> 2 bytes from there and hangs on reading bios[0]. > > This is probably because... I think the real issue is that the VRAM bios reading code is buggy, see my other email. It deferences ioremap()'d memory, and that's not allowed. One must use the proper __iomem pointer accessors, such as readl(), readb(), etc. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PCI Radeon RV100 detection hang on sparc64
From: Michel Dänzer Date: Thu, 06 Sep 2012 18:55:51 +0200 > On Don, 2012-09-06 at 17:41 +0300, Meelis Roos wrote: >> This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in >> Ultra 10 (clean, without my "Video RAM" hack that I talked in other >> sparclinux posts). When I saw that Sun XVR-100 was detected fine by the >> kernel, I compiled radeon drm driver with modesetting enabled and tried >> it: >> >> [drm] radeon defaulting to kernel modesetting. >> [drm] radeon kernel modesetting enabled. >> PCI: Enabling device: (:02:02.0), cmd 82 >> [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1002:0x0908). >> [drm] register mmio base: 0x1000 >> [drm] register mmio size: 32768 >> [drm:radeon_device_init] *ERROR* Unable to find PCI I/O BAR >> >> And here the machine hangs. Debugging printk-s reveal that it does not >> find any active I/O port resources and then continues into initializing >> the card. Down in igp_read_bios_from_vram() it successfully ioremaps >> memory region 0 (vram_base=1ff0800 and size=4) and tries to read >> 2 bytes from there and hangs on reading bios[0]. > > Is the card initialized by OpenFirmware? E.g., does it display anything > before the kernel boots? I think Meelis gave you every single detail you need to know to analyze and fix this bug. He says it crashes on reading bios[0]. If you look at the function he tells you the crash occurs in, you'll see clearly that bios is an ioremap()'d pointer. You cannot dereference ioremap()'d pointers, you must use the proper accessors such as readl(). ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V5 0/2] video: drm: Add Device tree support to DRM-FIMD
This patch set adds device tree support for DRM-FIMD for Samsung's Exynos5250. It includes parsing platform data from dts file. Also, adds the driver data for exynos4 and exynos5 devices. This patchset is based and tested on top of v3.6-rc4 on smdk5250 board Also depends on below patchset http://lists.freedesktop.org/archives/dri-devel/2012-August/026076.html Changes since V4: - Changed the compatible string from "samsung,exynos4-fb" to "samsung,exynos4-fimd". Changes since V3: - Removed the fimd version from driver data and using timing base address instead - Removed the drm_ prefixes to the structures and fucntions Changes since V2: - Added driver data to exynos5-drm-fimd as per Marek Szyprowski suggestion Changes since V1: - Corrected typo errors and changed compatibility string Leela Krishna Amudala (2): drm/exynos: add platform_device_id table and driver data for drm fimd video: drm: exynos: Add device tree support Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 138 - 2 files changed, 212 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V5 1/2] drm/exynos: add platform_device_id table and driver data for drm fimd
Two device ids are created for exynos4-fb and exynos5-fb.
Also, added driver data for exynos4 and exynos5 to pick the timing base address
at runtime to write data into appropriate register address.
Signed-off-by: Leela Krishna Amudala
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 43 +++---
1 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 24c0bd4..65e927b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -57,6 +57,18 @@
#define get_fimd_context(dev) platform_get_drvdata(to_platform_device(dev))
+struct fimd_driver_data {
+ unsigned int timing_base;
+};
+
+struct fimd_driver_data exynos4_fimd_driver_data = {
+ .timing_base = 0x0,
+};
+
+struct fimd_driver_data exynos5_fimd_driver_data = {
+ .timing_base = 0x2,
+};
+
struct fimd_win_data {
unsigned intoffset_x;
unsigned intoffset_y;
@@ -91,6 +103,13 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
};
+static inline struct fimd_driver_data *drm_fimd_get_driver_data(
+ struct platform_device *pdev)
+{
+ return (struct fimd_driver_data *)
+ platform_get_device_id(pdev)->driver_data;
+}
+
static bool fimd_display_is_connected(struct device *dev)
{
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -194,32 +213,35 @@ static void fimd_commit(struct device *dev)
struct fimd_context *ctx = get_fimd_context(dev);
struct exynos_drm_panel_info *panel = ctx->panel;
struct fb_videomode *timing = &panel->timing;
+ struct fimd_driver_data *driver_data;
+ struct platform_device *pdev = to_platform_device(dev);
u32 val;
+ driver_data = drm_fimd_get_driver_data(pdev);
if (ctx->suspended)
return;
DRM_DEBUG_KMS("%s\n", __FILE__);
/* setup polarity values from machine code. */
- writel(ctx->vidcon1, ctx->regs + VIDCON1);
+ writel(ctx->vidcon1, ctx->regs + driver_data->timing_base + VIDCON1);
/* setup vertical timing values. */
val = VIDTCON0_VBPD(timing->upper_margin - 1) |
VIDTCON0_VFPD(timing->lower_margin - 1) |
VIDTCON0_VSPW(timing->vsync_len - 1);
- writel(val, ctx->regs + VIDTCON0);
+ writel(val, ctx->regs + driver_data->timing_base + VIDTCON0);
/* setup horizontal timing values. */
val = VIDTCON1_HBPD(timing->left_margin - 1) |
VIDTCON1_HFPD(timing->right_margin - 1) |
VIDTCON1_HSPW(timing->hsync_len - 1);
- writel(val, ctx->regs + VIDTCON1);
+ writel(val, ctx->regs + driver_data->timing_base + VIDTCON1);
/* setup horizontal and vertical display size. */
val = VIDTCON2_LINEVAL(timing->yres - 1) |
VIDTCON2_HOZVAL(timing->xres - 1);
- writel(val, ctx->regs + VIDTCON2);
+ writel(val, ctx->regs + driver_data->timing_base + VIDTCON2);
/* setup clock source, clock divider, enable dma. */
val = ctx->vidcon0;
@@ -982,6 +1004,18 @@ static int fimd_runtime_resume(struct device *dev)
}
#endif
+static struct platform_device_id fimd_driver_ids[] = {
+ {
+ .name = "exynos4-fb",
+ .driver_data= (unsigned long)&exynos4_fimd_driver_data,
+ }, {
+ .name = "exynos5-fb",
+ .driver_data= (unsigned long)&exynos5_fimd_driver_data,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(platform, fimd_driver_ids);
+
static const struct dev_pm_ops fimd_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
SET_RUNTIME_PM_OPS(fimd_runtime_suspend, fimd_runtime_resume, NULL)
@@ -990,6 +1024,7 @@ static const struct dev_pm_ops fimd_pm_ops = {
struct platform_driver fimd_driver = {
.probe = fimd_probe,
.remove = __devexit_p(fimd_remove),
+ .id_table = fimd_driver_ids,
.driver = {
.name = "exynos4-fb",
.owner = THIS_MODULE,
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V5 2/2] video: drm: exynos: Add device tree support
Add device tree based discovery support for DRM-FIMD driver.
Signed-off-by: Leela Krishna Amudala
---
Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 95 -
2 files changed, 173 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt
diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt
b/Documentation/devicetree/bindings/fb/drm-fimd.txt
new file mode 100644
index 000..bf94cd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/fb/drm-fimd.txt
@@ -0,0 +1,80 @@
+* Samsung Display Controller using DRM frame work
+
+The display controller is used to transfer image data from memory to an
+external LCD driver interface. It supports various color formats such as
+rgb and yuv.
+
+Required properties:
+ - compatible: Should be "samsung,exynos5-fimd" or "samsung,exynos4-fimd" for
+ fimd using DRM frame work.
+ - reg: physical base address of the controller and length of memory
+ mapped region.
+ - interrupts: Three interrupts should be specified. The interrupts should be
+ specified in the following order.
+ - VSYNC interrupt
+ - FIFO level interrupt
+ - FIMD System Interrupt
+
+ - samsung,fimd-display: This property should specify the phandle of the
+ display device node which holds the video interface timing with the
+ below mentioned properties.
+
+ - lcd-htiming: Specifies the horizontal timing for the overlay. The
+ horizontal timing includes four parameters in the following order.
+
+ - horizontal back porch (in number of lcd clocks)
+ - horizontal front porch (in number of lcd clocks)
+ - hsync pulse width (in number of lcd clocks)
+ - Display panels X resolution.
+
+ - lcd-vtiming: Specifies the vertical timing for the overlay. The
+ vertical timing includes four parameters in the following order.
+
+ - vertical back porch (in number of lcd lines)
+ - vertical front porch (in number of lcd lines)
+ - vsync pulse width (in number of lcd clocks)
+ - Display panels Y resolution.
+
+
+ - samsung,default-window: Specifies the default window number of the fimd
controller.
+
+ - samsung,fimd-win-bpp: Specifies the bits per pixel.
+
+Optional properties:
+ - samsung,fimd-vidout-rgb: Video output format is RGB.
+ - samsung,fimd-inv-vclk: invert video clock polarity.
+ - samsung,fimd-frame-rate: Number of video frames per second.
+
+Example:
+
+ The following is an example for the fimd controller is split into
+ two portions. The SoC specific portion can be specified in the SoC
+ specific dts file. The board specific portion can be specified in the
+ board specific dts file.
+
+ - SoC Specific portion
+
+ fimd {
+ compatible = "samsung,exynos5-fimd";
+ interrupt-parent = <&combiner>;
+ reg = <0x1440 0x4>;
+ interrupts = <18 5>, <18 4>, <18 6>;
+ };
+
+ - Board Specific portion
+
+ lcd_fimd0: lcd_panel0 {
+ lcd-htiming = <4 4 4 480>;
+ lcd-vtiming = <4 4 4 320>;
+ supports-mipi-panel;
+ };
+
+ fimd {
+ samsung,fimd-display = <&lcd_fimd0>;
+ samsung,fimd-vidout-rgb;
+ samsung,fimd-inv-vclk;
+ samsung,fimd-frame-rate = <60>;
+ samsung,default-window = <0>;
+ samsung,fimd-win-bpp = <32>;
+ };
+
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 65e927b..cd1b841 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -103,9 +104,18 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
};
+static const struct of_device_id fimd_dt_match[];
+
static inline struct fimd_driver_data *drm_fimd_get_driver_data(
struct platform_device *pdev)
{
+#ifdef CONFIG_OF
+ if (pdev->dev.of_node) {
+ const struct of_device_id *match;
+ match = of_match_ptr(fimd_dt_match);
+ return (struct fimd_driver_data *)match->data;
+ }
+#endif
return (struct fimd_driver_data *)
platform_get_device_id(pdev)->driver_data;
}
@@ -809,12 +819,77 @@ static int fimd_power_on(struct fimd_context *ctx, bool
enable)
return 0;
}
+#ifdef CONFIG_OF
+static struct exynos_drm_fimd_pdata *drm_fimd_dt_parse_pdata(struct device
*dev)
+{
+ struct device_node *np = dev->of_node;
+ struct device_node *disp_np;
+ struct exynos_drm_fimd_pdata *pd;
+ u32 data[4];
+
+ pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd) {
+ dev_err(dev, "memory allocation for pdata failed\n");
+ return ERR_PTR(-ENOMEM);
