Re: [PATCH v3 1/3] drm: add prime helpers
On Thu, Jan 17, 2013 at 12:36 AM, Aaron Plattner wrote: > Can I consider this a Reviewed-by? Essentially it was just a drive-by bikeshed ;-) I think it'd be good if Maarten takes a look at this and checks whether it complies with his massive prime/dma_buf rework to use fences and ticketing reservations ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: CDF discussions at FOSDEM
On Fri, 11 Jan 2013, Laurent Pinchart wrote: > Would anyone be interested in meeting at the FOSDEM to discuss the Common > Display Framework ? There will be a CDF meeting at the ELC at the end of > February, the FOSDEM would be a good venue for European developers. Yes, count me in, Jani. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: > On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf > wrote: > > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote: > >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf > >> wrote: > >> > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf wrote: > >> >> On 2013.01.15 at 16:26 +0100, Michel Dänzer wrote: > >> >> > On Die, 2013-01-15 at 16:23 +0100, Markus Trippelsdorf wrote: > >> >> > > On 2013.01.15 at 15:43 +0100, Michel Dänzer wrote: > >> >> > > > On Sam, 2013-01-05 at 11:41 +0100, Markus Trippelsdorf wrote: > >> >> > > > > On 2012.12.20 at 14:58 +0100, Markus Trippelsdorf wrote: > >> >> > > > > > > >> >> > > > > > And just in case it got lost in the noise yesterday: > >> >> > > > > > The image corruption is caused by Dave's commit: > >> >> > > > > > > >> >> > > > > > commit dd54fee7d440c4a9756cce2c24a50c15e4c17ccb > >> >> > > > > > Author: Dave Airlie > >> >> > > > > > Date: Fri Dec 14 21:04:46 2012 +1000 > >> >> > > > > > > >> >> > > > > > radeon: fix regression with eviction since evict caching > >> >> > > > > > changes > >> >> > > > > > > >> >> > > > > > Reverting it 'fixes' the issue. > >> >> > > > > > >> >> > > > > Ping. > >> >> > > > > The issue still happens with todays Linus git tree. > >> >> > > > > >> >> > > > Does the corruption also occur with > >> >> > > > dd54fee7d440c4a9756cce2c24a50c15e4c17ccb applied manually on top > >> >> > > > of > >> >> > > > 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d? > >> >> > > > >> >> > > No. > >> >> > > >> >> > So, can you bisect which change between those two actually introduced > >> >> > the corruption? > >> > > >> > The real cause of the image corruption is: > >> > > >> > d025e9e2b890db679f1246037bf65bd4be512627 is the first bad commit > >> > commit d025e9e2b890db679f1246037bf65bd4be512627 > >> > Author: Jerome Glisse > >> > Date: Thu Nov 29 10:35:41 2012 -0500 > >> > > >> > drm/radeon: do not move bo to different placement at each cs > >> > > >> > The bo creation placement is where the bo will be. Instead of trying > >> > to move bo at each command stream let this work to another worker > >> > thread that will use more advance heuristic. > >> > > >> > agd5f: remove leftover unused variable > >> > > >> > Signed-off-by: Jerome Glisse > >> > Reviewed-by: Alex Deucher > >> > > >> > Reverting d025e9e2b890d on top of Linus' tree fixes the issue. > >> > >> Can you try this patch from Jerome: > >> https://bugzilla.kernel.org/attachment.cgi?id=91421 > > > > It fixes the corruption, but it degrades performance so much that it > > takes several seconds to switch virtual desktops under xmonad. And > > sometimes the website used for the scroll test is stuck for several > > seconds and unscrollable during that time. > > > > -- > > Markus > > What about this patch instead : > http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch This one doesn't work: Jan 17 09:40:53 x4 kernel: radeon :01:05.0: GPU lockup CP stall for more than 1msec Jan 17 09:40:53 x4 kernel: radeon :01:05.0: GPU lockup (waiting for 0x0a63 last fence id 0x0a62) Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 0
Re: [Intel-gfx] [PATCH 3/4] drm/edid: Add drm_rgb_quant_range_selectable()
Hi
2013/1/16 :
> From: Ville Syrjälä
>
> drm_rgb_quant_range_selectable() will report whether the monitor
> claims to support for RGB quantization range selection.
>
> The information can be found in the CEA Video capability block.
Looks correct (checked against the spec, did not really test).
Reviewed-by: Paulo Zanoni
See below for optional bikeshedding:
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 33 +
> include/drm/drm_crtc.h |1 +
> 2 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 5a3770f..deba722 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1483,9 +1483,11 @@ add_detailed_modes(struct drm_connector *connector,
> struct edid *edid,
> #define VIDEO_BLOCK 0x02
> #define VENDOR_BLOCK0x03
> #define SPEAKER_BLOCK 0x04
> +#define VIDEO_CAPABILITY_BLOCK 0x07
> #define EDID_BASIC_AUDIO (1 << 6)
> #define EDID_CEA_YCRCB444 (1 << 5)
> #define EDID_CEA_YCRCB422 (1 << 4)
> +#define EDID_CEA_VCDB_QS (1 << 6)
>
> /**
> * Search EDID for CEA extension block.
> @@ -1902,6 +1904,37 @@ end:
> EXPORT_SYMBOL(drm_detect_monitor_audio);
>
> /**
> + * drm_rgb_quant_range_selectable - is RGB quantization range selectable?
> + *
> + * Check whether the monitor reports the RGB quantization range selection
> + * as supported. The AVI infoframe can then be used to inform the monitor
> + * which quantzation range (full or limited) is used.
s/quantzation/quantization/
> + */
> +bool drm_rgb_quant_range_selectable(struct edid *edid)
> +{
> + u8 *edid_ext;
> + int i, start, end;
> +
> + edid_ext = drm_find_cea_extension(edid);
> + if (!edid_ext)
> + return false;
> +
> + if (cea_db_offsets(edid_ext, &start, &end))
> + return false;
> +
> + for_each_cea_db(edid_ext, i, start, end) {
> + if (cea_db_tag(&edid_ext[i]) == VIDEO_CAPABILITY_BLOCK &&
> + cea_db_payload_len(&edid_ext[i]) == 2) {
> + DRM_DEBUG_KMS("CEA VCDB 0x%02x\n", edid_ext[i + 2]);
> + return edid_ext[i + 2] & EDID_CEA_VCDB_QS;
> + }
> + }
> +
> + return false;
> +}
> +EXPORT_SYMBOL(drm_rgb_quant_range_selectable);
> +
> +/**
> * drm_add_display_info - pull display info out if present
> * @edid: EDID data
> * @info: display info (attached to connector)
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 00d78b5..30892dc 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1033,6 +1033,7 @@ extern u8 *drm_find_cea_extension(struct edid *edid);
> extern u8 drm_match_cea_mode(struct drm_display_mode *to_match);
> extern bool drm_detect_hdmi_monitor(struct edid *edid);
> extern bool drm_detect_monitor_audio(struct edid *edid);
> +extern bool drm_rgb_quant_range_selectable(struct edid *edid);
> extern int drm_mode_page_flip_ioctl(struct drm_device *dev,
> void *data, struct drm_file *file_priv);
> extern struct drm_display_mode *drm_cvt_mode(struct drm_device *dev,
> --
> 1.7.8.6
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/i915: Provide the quantization range in the AVI infoframe
Hi
2013/1/16 :
> From: Ville Syrjälä
>
> The AVI infoframe is able to inform the display whether the source is
> sending full or limited range RGB data.
>
> As per CEA-861 we must first check whether the display reports the
> quantization range as selectable, and if so we can set the approriate
> bits in the AVI inforframe.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_drv.h |3 +++
> drivers/gpu/drm/i915/intel_hdmi.c | 11 +++
> drivers/gpu/drm/i915/intel_sdvo.c | 16 ++--
> 3 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 1a698c6..c5251d9 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -289,6 +289,8 @@ struct cxsr_latency {
> #define DIP_LEN_AVI 13
> #define DIP_AVI_PR_10
> #define DIP_AVI_PR_21
> +#define DIP_AVI_Q0 0x4
> +#define DIP_AVI_Q1 0x8
I'd define more descriptive names here... How about the following?
#define DIP_AVI_QUANTIZATION_DEFAULT (0 << 2)
#define DIP_AVI_QUANTIZATION_LIMITED (1 << 2)
#define DIP_AVI_QUANTIZATION_FULL (2 << 2)
Everything else looks fine.
With or without that:
Reviewed-by: Paulo Zanoni
Also, these things kinda conflict with Thierry's patches, but I know
you're aware because you've reviewed some of them :)
>
> #define DIP_TYPE_SPD 0x83
> #define DIP_VERSION_SPD0x1
> @@ -347,6 +349,7 @@ struct intel_hdmi {
> bool has_hdmi_sink;
> bool has_audio;
> enum hdmi_force_audio force_audio;
> + bool rgb_quant_range_selectable;
> void (*write_infoframe)(struct drm_encoder *encoder,
> struct dip_infoframe *frame);
> void (*set_infoframes)(struct drm_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 58b072e..270d7ee 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -331,6 +331,7 @@ static void intel_set_infoframe(struct drm_encoder
> *encoder,
> static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
> struct drm_display_mode
> *adjusted_mode)
> {
> + struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> struct dip_infoframe avi_if = {
> .type = DIP_TYPE_AVI,
> .ver = DIP_VERSION_AVI,
> @@ -340,6 +341,13 @@ static void intel_hdmi_set_avi_infoframe(struct
> drm_encoder *encoder,
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
> avi_if.body.avi.YQ_CN_PR |= DIP_AVI_PR_2;
>
> + if (intel_hdmi->rgb_quant_range_selectable) {
> + if (adjusted_mode->private_flags &
> INTEL_MODE_LIMITED_COLOR_RANGE)
> + avi_if.body.avi.ITC_EC_Q_SC |= DIP_AVI_Q0;
> + else
> + avi_if.body.avi.ITC_EC_Q_SC |= DIP_AVI_Q1;
> + }
> +
> avi_if.body.avi.VIC = drm_mode_cea_vic(adjusted_mode);
>
> intel_set_infoframe(encoder, &avi_if);
> @@ -825,6 +833,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
>
> intel_hdmi->has_hdmi_sink = false;
> intel_hdmi->has_audio = false;
> + intel_hdmi->rgb_quant_range_selectable = false;
> edid = drm_get_edid(connector,
> intel_gmbus_get_adapter(dev_priv,
> intel_hdmi->ddc_bus));
> @@ -836,6 +845,8 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
> intel_hdmi->has_hdmi_sink =
> drm_detect_hdmi_monitor(edid);
> intel_hdmi->has_audio =
> drm_detect_monitor_audio(edid);
> + intel_hdmi->rgb_quant_range_selectable =
> + drm_rgb_quant_range_selectable(edid);
> }
> kfree(edid);
> }
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index b422109..af93999 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -126,6 +126,7 @@ struct intel_sdvo {
> bool is_hdmi;
> bool has_hdmi_monitor;
> bool has_hdmi_audio;
> + bool rgb_quant_range_selectable;
>
> /**
> * This is set if we detect output of sdvo device as LVDS and
> @@ -947,7 +948,8 @@ static bool intel_sdvo_write_infoframe(struct intel_sdvo
> *intel_sdvo,
> &tx_rate, 1);
> }
>
> -static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo)
> +static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo,
> +const struct drm_display_mode
> *adjusted_mode)
> {
> struct dip_infoframe avi_if = {
>
Re: CDF discussions at FOSDEM
On Thu, Jan 17, 2013 at 9:42 AM, Jani Nikula wrote: > On Fri, 11 Jan 2013, Laurent Pinchart > wrote: >> Would anyone be interested in meeting at the FOSDEM to discuss the Common >> Display Framework ? There will be a CDF meeting at the ELC at the end of >> February, the FOSDEM would be a good venue for European developers. > > Yes, count me in, Jesse, Ville and me should also be around. Do we have a slot fixed already? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/i915: Provide the quantization range in the AVI infoframe
On Thu, Jan 17, 2013 at 10:16:46AM -0200, Paulo Zanoni wrote:
> Hi
>
> 2013/1/16 :
> > From: Ville Syrjälä
> >
> > The AVI infoframe is able to inform the display whether the source is
> > sending full or limited range RGB data.
> >
> > As per CEA-861 we must first check whether the display reports the
> > quantization range as selectable, and if so we can set the approriate
> > bits in the AVI inforframe.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_drv.h |3 +++
> > drivers/gpu/drm/i915/intel_hdmi.c | 11 +++
> > drivers/gpu/drm/i915/intel_sdvo.c | 16 ++--
> > 3 files changed, 28 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 1a698c6..c5251d9 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -289,6 +289,8 @@ struct cxsr_latency {
> > #define DIP_LEN_AVI 13
> > #define DIP_AVI_PR_10
> > #define DIP_AVI_PR_21
> > +#define DIP_AVI_Q0 0x4
> > +#define DIP_AVI_Q1 0x8
>
>
>
> I'd define more descriptive names here... How about the following?
> #define DIP_AVI_QUANTIZATION_DEFAULT (0 << 2)
> #define DIP_AVI_QUANTIZATION_LIMITED (1 << 2)
> #define DIP_AVI_QUANTIZATION_FULL (2 << 2)
Sure, that seems like sensible idea. I think I'll want the fact that
these only refer to RGB to be included in the name though.
So something like this probably:
DIP_AVI_RGB_QUANT_RANGE_DEFAULT
DIP_AVI_RGB_QUANT_RANGE_LIMITED
DIP_AVI_RGB_QUANT_RANGE_FULL
>
>
> Everything else looks fine.
>
> With or without that:
> Reviewed-by: Paulo Zanoni
>
> Also, these things kinda conflict with Thierry's patches, but I know
> you're aware because you've reviewed some of them :)
Yeah. BTW are we (as in i915 folks) mostly OK with those?
> > #define DIP_TYPE_SPD 0x83
> > #define DIP_VERSION_SPD0x1
> > @@ -347,6 +349,7 @@ struct intel_hdmi {
> > bool has_hdmi_sink;
> > bool has_audio;
> > enum hdmi_force_audio force_audio;
> > + bool rgb_quant_range_selectable;
> > void (*write_infoframe)(struct drm_encoder *encoder,
> > struct dip_infoframe *frame);
> > void (*set_infoframes)(struct drm_encoder *encoder,
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 58b072e..270d7ee 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -331,6 +331,7 @@ static void intel_set_infoframe(struct drm_encoder
> > *encoder,
> > static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
> > struct drm_display_mode
> > *adjusted_mode)
> > {
> > + struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> > struct dip_infoframe avi_if = {
> > .type = DIP_TYPE_AVI,
> > .ver = DIP_VERSION_AVI,
> > @@ -340,6 +341,13 @@ static void intel_hdmi_set_avi_infoframe(struct
> > drm_encoder *encoder,
> > if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
> > avi_if.body.avi.YQ_CN_PR |= DIP_AVI_PR_2;
> >
> > + if (intel_hdmi->rgb_quant_range_selectable) {
> > + if (adjusted_mode->private_flags &
> > INTEL_MODE_LIMITED_COLOR_RANGE)
> > + avi_if.body.avi.ITC_EC_Q_SC |= DIP_AVI_Q0;
> > + else
> > + avi_if.body.avi.ITC_EC_Q_SC |= DIP_AVI_Q1;
> > + }
> > +
> > avi_if.body.avi.VIC = drm_mode_cea_vic(adjusted_mode);
> >
> > intel_set_infoframe(encoder, &avi_if);
> > @@ -825,6 +833,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> > force)
> >
> > intel_hdmi->has_hdmi_sink = false;
> > intel_hdmi->has_audio = false;
> > + intel_hdmi->rgb_quant_range_selectable = false;
> > edid = drm_get_edid(connector,
> > intel_gmbus_get_adapter(dev_priv,
> > intel_hdmi->ddc_bus));
> > @@ -836,6 +845,8 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> > force)
> > intel_hdmi->has_hdmi_sink =
> >
> > drm_detect_hdmi_monitor(edid);
> > intel_hdmi->has_audio =
> > drm_detect_monitor_audio(edid);
> > + intel_hdmi->rgb_quant_range_selectable =
> > + drm_rgb_quant_range_selectable(edid);
> > }
> > kfree(edid);
> > }
> > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> > b/drivers/gpu/drm/i915/intel_sdvo.c
> > index b422109..af93999 100644
> > --- a/drivers/gpu/drm/i915/intel_sdvo.c
> > +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> > @@ -126,6 +126,7 @@ struct intel_sdvo {
> > bool is_hdmi;
> > bool has_hdmi_monitor;
> > b
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Fix RGB color range property for PCH platforms
Hi
2013/1/16 :
> From: Ville Syrjälä
>
> The RGB color range select bit on the DP/SDVO/HDMI registers
> disappeared when PCH was introduced, and instead a new PIPECONF bit
> was added that performs the same function.
>
> Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
> it in the encoder mode_fixup if limited color range is requested.
> Set the the PIPECONF bit 13 based on the flag.
>
> Experimentation showed that simply toggling the bit while the pipe is
> active doesn't work. We need to restart the pipe, which luckily already
> happens.
>
> The DP/SDVO/HDMI bit 8 is marked MBZ in the docs, so avoid setting it,
> although it doesn't seem to do any harm in practice.
>
> TODO:
> - the PIPECONF bit too seems to have disappeared from HSW. Need a
> volunteer to test if it's just a documentation issue or if it's really
> gone. If the bit is gone and no easy replacement is found, then I suppose
> we may need to use the pipe CSC unit to perform the range compression.
>
> v2: Use mode private_flags instead of intel_encoder virtual functions
> v3: Moved the intel_dp color_range handling after bpc check to help
> later patches
Things look correct. As you mention, the only problem seems to be the
Haswell. I could not find anything on the specs, so I think we should
send some emails and maybe consider removing the property on Haswell?
If-you-promise-to-find-a-solution-for-the-Haswell-case:
Reviewed-by: Paulo Zanoni
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46800
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h |1 +
> drivers/gpu/drm/i915/intel_display.c |5 +
> drivers/gpu/drm/i915/intel_dp.c |7 ++-
> drivers/gpu/drm/i915/intel_drv.h |5 +
> drivers/gpu/drm/i915/intel_hdmi.c|5 +
> drivers/gpu/drm/i915/intel_sdvo.c|5 -
> 6 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 36789bf..a2550c5 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2652,6 +2652,7 @@
> #define PIPECONF_INTERLACED_DBL_ILK (4 << 21) /* ilk/snb only */
> #define PIPECONF_PFIT_PF_INTERLACED_DBL_ILK (5 << 21) /* ilk/snb only */
> #define PIPECONF_CXSR_DOWNCLOCK (1<<16)
> +#define PIPECONF_COLOR_RANGE_SELECT (1 << 13)
> #define PIPECONF_BPC_MASK(0x7 << 5)
> #define PIPECONF_8BPC(0<<5)
> #define PIPECONF_10BPC (1<<5)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index c7313f8..f48f698 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5097,6 +5097,11 @@ static void ironlake_set_pipeconf(struct drm_crtc
> *crtc,
> else
> val |= PIPECONF_PROGRESSIVE;
>
> + if (adjusted_mode->private_flags & INTEL_MODE_LIMITED_COLOR_RANGE)
> + val |= PIPECONF_COLOR_RANGE_SELECT;
> + else
> + val &= ~PIPECONF_COLOR_RANGE_SELECT;
> +
> I915_WRITE(PIPECONF(pipe), val);
> POSTING_READ(PIPECONF(pipe));
> }
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index cf25481..64824d0 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -763,6 +763,10 @@ intel_dp_mode_fixup(struct drm_encoder *encoder,
> return false;
>
> bpp = adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 :
> 24;
> +
> + if (intel_dp->color_range)
> + adjusted_mode->private_flags |=
> INTEL_MODE_LIMITED_COLOR_RANGE;
> +
> mode_rate = intel_dp_link_required(adjusted_mode->clock, bpp);
>
> for (clock = 0; clock <= max_clock; clock++) {
> @@ -967,7 +971,8 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct
> drm_display_mode *mode,
> else
> intel_dp->DP |= DP_PLL_FREQ_270MHZ;
> } else if (!HAS_PCH_CPT(dev) || is_cpu_edp(intel_dp)) {
> - intel_dp->DP |= intel_dp->color_range;
> + if (!HAS_PCH_SPLIT(dev))
> + intel_dp->DP |= intel_dp->color_range;
>
> if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
> intel_dp->DP |= DP_SYNC_HS_HIGH;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 54a034c..4df47be 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -109,6 +109,11 @@
> * timings in the mode to prevent the crtc fixup from overwriting them.
> * Currently only lvds needs that. */
> #define INTEL_MODE_CRTC_TIMINGS_SET (0x20)
> +/*
> + * Set when limited 16-235 (as opposed to full 0-255) RGB color range is
> + * to be used.
> + */
> +#define INTEL_MODE_LIMITED_COLOR_RANGE (0x40)
>
> static inline void
> intel_mode_set_pixel_multipli
[PATCH] drm/nouveau/mc: complain loudly if we can't call a interrupt handler
I noticed that bsp, vp and ppp had no interrupt handler after investigating why
15% of my cpu time went to interrupts.
nouveau was silent about it, but it should be an error since we have no way of
acking in that case.
Signed-off-by: Maarten Lankhorst
---
fwiw, the interrupt was 10, the exit interrupt after secret scrubber finishes..
I have absolutely no idea why, as it times out on wait before the engine
initialization..
Maybe just ack it from the bsp/vp/ppp interrupt handler? Or should it be part
of the base fuc class..
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index 8379aaf..16bf49c 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -36,8 +36,16 @@ nouveau_mc_intr(struct nouveau_subdev *subdev)
while (stat && map->stat) {
if (stat & map->stat) {
unit = nouveau_subdev(subdev, map->unit);
- if (unit && unit->intr)
- unit->intr(unit);
+ if (unit) {
+ if (unit->intr)
+ unit->intr(unit);
+ else if (printk_ratelimit())
+ nv_error(pmc,
+"%s has no interrupt handler,
ignoring interrupt %x\n",
+unit->name, intr & map->stat);
+ } else if (printk_ratelimit())
+ nv_error(pmc, "subdev %u does not exist for
interrupt %x\n",
+map->unit, intr & map->stat);
intr &= ~map->stat;
}
map++;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/i915: Add "Automatic" mode for the "Broadcast RGB" property
Hi
2013/1/16 :
> From: Ville Syrjälä
>
> Add a new "Automatic" mode to the "Broadcast RGB" range property.
> When selected the driver automagically selects between full range and
> limited range output.
>
> Based on CEA-861 guidelines, limited range output is selected if the
> mode is a CEA mode, except 640x480. Otherwise full range output is used.
> Additionally DVI monitors should most likely default to full range
> always.
>
> As per DP1.2a DisplayPort should always use full range for 18bpp, and
> otherwise will follow CEA-861 rules.
>
> NOTE: The default value for the property will now be "Automatic"
> so some people may be affected in case they're relying on the
> current full range default.
>
> v2: Use has_hdmi_sink to check if a HDMI monitor is present
Looks correct. And let's hope this patches fixes even more "my screen
is black" or "my screen has weird colors" bugs.
Reviewed-by: Paulo Zanoni
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.h|4 +++
> drivers/gpu/drm/i915/intel_dp.c| 28 ++---
> drivers/gpu/drm/i915/intel_drv.h |2 +
> drivers/gpu/drm/i915/intel_hdmi.c | 29 +++---
> drivers/gpu/drm/i915/intel_modes.c |5 ++-
> drivers/gpu/drm/i915/intel_sdvo.c | 38 +--
> 6 files changed, 89 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d0f051b..449bbe0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1803,5 +1803,9 @@ __i915_write(64, q)
> #define POSTING_READ(reg) (void)I915_READ_NOTRACE(reg)
> #define POSTING_READ16(reg)(void)I915_READ16_NOTRACE(reg)
>
> +/* "Broadcast RGB" property */
> +#define INTEL_BROADCAST_RGB_AUTO 0
> +#define INTEL_BROADCAST_RGB_FULL 1
> +#define INTEL_BROADCAST_RGB_LIMITED 2
>
> #endif
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 64824d0..633a4db 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -764,6 +764,14 @@ intel_dp_mode_fixup(struct drm_encoder *encoder,
>
> bpp = adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 :
> 24;
>
> + if (intel_dp->color_range_auto) {
> + /* as per DP1.2a and CEA-861 */
> + if (bpp != 18 && drm_mode_cea_vic(adjusted_mode) > 1)
> + intel_dp->color_range = DP_COLOR_RANGE_16_235;
> + else
> + intel_dp->color_range = 0;
> + }
> +
> if (intel_dp->color_range)
> adjusted_mode->private_flags |=
> INTEL_MODE_LIMITED_COLOR_RANGE;
>
> @@ -2462,10 +2470,21 @@ intel_dp_set_property(struct drm_connector *connector,
> }
>
> if (property == dev_priv->broadcast_rgb_property) {
> - if (val == !!intel_dp->color_range)
> - return 0;
> -
> - intel_dp->color_range = val ? DP_COLOR_RANGE_16_235 : 0;
> + switch (val) {
> + case INTEL_BROADCAST_RGB_AUTO:
> + intel_dp->color_range_auto = true;
> + break;
> + case INTEL_BROADCAST_RGB_FULL:
> + intel_dp->color_range_auto = false;
> + intel_dp->color_range = 0;
> + break;
> + case INTEL_BROADCAST_RGB_LIMITED:
> + intel_dp->color_range_auto = false;
> + intel_dp->color_range = DP_COLOR_RANGE_16_235;
> + break;
> + default:
> + return -EINVAL;
> + }
> goto done;
> }
>
> @@ -2606,6 +2625,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
> struct drm_connector *connect
>
> intel_attach_force_audio_property(connector);
> intel_attach_broadcast_rgb_property(connector);
> + intel_dp->color_range_auto = true;
>
> if (is_edp(intel_dp)) {
> drm_mode_create_scaling_mode_property(connector->dev);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 4df47be..1a698c6 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -343,6 +343,7 @@ struct intel_hdmi {
> u32 sdvox_reg;
> int ddc_bus;
> uint32_t color_range;
> + bool color_range_auto;
> bool has_hdmi_sink;
> bool has_audio;
> enum hdmi_force_audio force_audio;
> @@ -362,6 +363,7 @@ struct intel_dp {
> bool has_audio;
> enum hdmi_force_audio force_audio;
> uint32_t color_range;
> + bool color_range_auto;
> uint8_t link_bw;
> uint8_t lane_count;
> uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index f194d75..58b0
[pull] drm-intel-fixes
Hi Dave More important fixes for 3.9: - error_state improvements to help debug the new scanline wait code added for gen6+ - bug reports started popping up :( patch from Chris Wilson. - fix a panel power sequence confusion between the eDP and lvds detection code resulting in black screens - regression introduce in 3.8 (Jani Nikula) - Chris fixed the root-cause of the ilk relocation vs. evict bug. - Another piece of cargo-culted rc6 lore from Jani, fixes up a regression where a system refused to go into rc6 after suspend sometimes. The last two are cc: stable. Cheers, Daniel The following changes since commit 93927ca52a55c23e0a6a305e7e9082e8411ac9fa: drm/i915: Revert shrinker changes from "Track unbound pages" (2013-01-10 18:02:44 +0100) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to b514407547890686572606c9dfa4b7f832db9958: drm/i915: fix FORCEWAKE posting reads (2013-01-17 11:09:25 +0100) Chris Wilson (2): drm/i915: Record DERRMR, FORCEWAKE and RING_CTL in error-state drm/i915: Invalidate the relocation presumed_offsets along the slow path Jani Nikula (2): drm/i915/eDP: do not write power sequence registers for ghost eDP drm/i915: fix FORCEWAKE posting reads drivers/gpu/drm/i915/i915_debugfs.c|3 ++ drivers/gpu/drm/i915/i915_drv.h|3 ++ drivers/gpu/drm/i915/i915_gem_execbuffer.c | 21 + drivers/gpu/drm/i915/i915_irq.c| 11 +++ drivers/gpu/drm/i915/i915_reg.h|2 ++ drivers/gpu/drm/i915/intel_dp.c| 47 +++- drivers/gpu/drm/i915/intel_pm.c| 17 +++--- 7 files changed, 84 insertions(+), 20 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
drm/i915: RGB quantization range stuff v3
Third attempt at handling the RGB quantization range for HDMI and DP. Changes since the last time: - Addressed all of Paulo's review comments. I think this is ready to go in, unless someone complains loudly. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] drm/i915: Fix RGB color range property for PCH platforms
From: Ville Syrjälä
The RGB color range select bit on the DP/SDVO/HDMI registers
disappeared when PCH was introduced, and instead a new PIPECONF bit
was added that performs the same function.
Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
it in the encoder mode_fixup if limited color range is requested.
Set the the PIPECONF bit 13 based on the flag.
Experimentation showed that simply toggling the bit while the pipe is
active doesn't work. We need to restart the pipe, which luckily already
happens.
The DP/SDVO/HDMI bit 8 is marked MBZ in the docs, so avoid setting it,
although it doesn't seem to do any harm in practice.
TODO:
- the PIPECONF bit too seems to have disappeared from HSW. Need a
volunteer to test if it's just a documentation issue or if it's really
gone. If the bit is gone and no easy replacement is found, then I suppose
we may need to use the pipe CSC unit to perform the range compression.
v2: Use mode private_flags instead of intel_encoder virtual functions
v3: Moved the intel_dp color_range handling after bpc check to help
later patches
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46800
Reviewed-by: Paulo Zanoni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c |5 +
drivers/gpu/drm/i915/intel_dp.c |7 ++-
drivers/gpu/drm/i915/intel_drv.h |5 +
drivers/gpu/drm/i915/intel_hdmi.c|5 +
drivers/gpu/drm/i915/intel_sdvo.c|5 -
6 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 36789bf..a2550c5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2652,6 +2652,7 @@
#define PIPECONF_INTERLACED_DBL_ILK (4 << 21) /* ilk/snb only */
#define PIPECONF_PFIT_PF_INTERLACED_DBL_ILK (5 << 21) /* ilk/snb only */
#define PIPECONF_CXSR_DOWNCLOCK (1<<16)
+#define PIPECONF_COLOR_RANGE_SELECT (1 << 13)
#define PIPECONF_BPC_MASK(0x7 << 5)
#define PIPECONF_8BPC(0<<5)
#define PIPECONF_10BPC (1<<5)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c7313f8..f48f698 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5097,6 +5097,11 @@ static void ironlake_set_pipeconf(struct drm_crtc *crtc,
else
val |= PIPECONF_PROGRESSIVE;
+ if (adjusted_mode->private_flags & INTEL_MODE_LIMITED_COLOR_RANGE)
+ val |= PIPECONF_COLOR_RANGE_SELECT;
+ else
+ val &= ~PIPECONF_COLOR_RANGE_SELECT;
+
I915_WRITE(PIPECONF(pipe), val);
POSTING_READ(PIPECONF(pipe));
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index cf25481..64824d0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -763,6 +763,10 @@ intel_dp_mode_fixup(struct drm_encoder *encoder,
return false;
bpp = adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 : 24;
+
+ if (intel_dp->color_range)
+ adjusted_mode->private_flags |= INTEL_MODE_LIMITED_COLOR_RANGE;
+
mode_rate = intel_dp_link_required(adjusted_mode->clock, bpp);
for (clock = 0; clock <= max_clock; clock++) {
@@ -967,7 +971,8 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct
drm_display_mode *mode,
else
intel_dp->DP |= DP_PLL_FREQ_270MHZ;
} else if (!HAS_PCH_CPT(dev) || is_cpu_edp(intel_dp)) {
- intel_dp->DP |= intel_dp->color_range;
+ if (!HAS_PCH_SPLIT(dev))
+ intel_dp->DP |= intel_dp->color_range;
if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
intel_dp->DP |= DP_SYNC_HS_HIGH;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 54a034c..4df47be 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -109,6 +109,11 @@
* timings in the mode to prevent the crtc fixup from overwriting them.
* Currently only lvds needs that. */
#define INTEL_MODE_CRTC_TIMINGS_SET (0x20)
+/*
+ * Set when limited 16-235 (as opposed to full 0-255) RGB color range is
+ * to be used.
+ */
+#define INTEL_MODE_LIMITED_COLOR_RANGE (0x40)
static inline void
intel_mode_set_pixel_multiplier(struct drm_display_mode *mode,
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 6387f9b..f194d75 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -766,6 +766,11 @@ bool intel_hdmi_mode_fixup(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
+ struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(e
[PATCH v3 2/4] drm/i915: Add "Automatic" mode for the "Broadcast RGB" property
From: Ville Syrjälä
Add a new "Automatic" mode to the "Broadcast RGB" range property.
When selected the driver automagically selects between full range and
limited range output.
Based on CEA-861 [1] guidelines, limited range output is selected if the
mode is a CEA mode, except 640x480. Otherwise full range output is used.
Additionally DVI monitors should most likely default to full range
always.
As per DP1.2a [2] DisplayPort should always use full range for 18bpp, and
otherwise will follow CEA-861 rules.
NOTE: The default value for the property will now be "Automatic"
so some people may be affected in case they're relying on the
current full range default.
[1] CEA-861-E - 5.1 Default Encoding Parameters
[2] VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
v2: Use has_hdmi_sink to check if a HDMI monitor is present
v3: Add information about relevant spec chapters
Reviewed-by: Paulo Zanoni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h|4 +++
drivers/gpu/drm/i915/intel_dp.c| 32 ++---
drivers/gpu/drm/i915/intel_drv.h |2 +
drivers/gpu/drm/i915/intel_hdmi.c | 29 +++---
drivers/gpu/drm/i915/intel_modes.c |5 ++-
drivers/gpu/drm/i915/intel_sdvo.c | 38 +--
6 files changed, 93 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d0f051b..449bbe0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1803,5 +1803,9 @@ __i915_write(64, q)
#define POSTING_READ(reg) (void)I915_READ_NOTRACE(reg)
#define POSTING_READ16(reg)(void)I915_READ16_NOTRACE(reg)
+/* "Broadcast RGB" property */
+#define INTEL_BROADCAST_RGB_AUTO 0
+#define INTEL_BROADCAST_RGB_FULL 1
+#define INTEL_BROADCAST_RGB_LIMITED 2
#endif
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 64824d0..4590620 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -764,6 +764,18 @@ intel_dp_mode_fixup(struct drm_encoder *encoder,
bpp = adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 : 24;
+ if (intel_dp->color_range_auto) {
+ /*
+* See:
+* CEA-861-E - 5.1 Default Encoding Parameters
+* VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
+*/
+ if (bpp != 18 && drm_mode_cea_vic(adjusted_mode) > 1)
+ intel_dp->color_range = DP_COLOR_RANGE_16_235;
+ else
+ intel_dp->color_range = 0;
+ }
+
if (intel_dp->color_range)
adjusted_mode->private_flags |= INTEL_MODE_LIMITED_COLOR_RANGE;
@@ -2462,10 +2474,21 @@ intel_dp_set_property(struct drm_connector *connector,
}
if (property == dev_priv->broadcast_rgb_property) {
- if (val == !!intel_dp->color_range)
- return 0;
-
- intel_dp->color_range = val ? DP_COLOR_RANGE_16_235 : 0;
+ switch (val) {
+ case INTEL_BROADCAST_RGB_AUTO:
+ intel_dp->color_range_auto = true;
+ break;
+ case INTEL_BROADCAST_RGB_FULL:
+ intel_dp->color_range_auto = false;
+ intel_dp->color_range = 0;
+ break;
+ case INTEL_BROADCAST_RGB_LIMITED:
+ intel_dp->color_range_auto = false;
+ intel_dp->color_range = DP_COLOR_RANGE_16_235;
+ break;
+ default:
+ return -EINVAL;
+ }
goto done;
}
@@ -2606,6 +2629,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
+ intel_dp->color_range_auto = true;
if (is_edp(intel_dp)) {
drm_mode_create_scaling_mode_property(connector->dev);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 4df47be..1a698c6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -343,6 +343,7 @@ struct intel_hdmi {
u32 sdvox_reg;
int ddc_bus;
uint32_t color_range;
+ bool color_range_auto;
bool has_hdmi_sink;
bool has_audio;
enum hdmi_force_audio force_audio;
@@ -362,6 +363,7 @@ struct intel_dp {
bool has_audio;
enum hdmi_force_audio force_audio;
uint32_t color_range;
+ bool color_range_auto;
uint8_t link_bw;
uint8_t lane_count;
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index f194d75..db67be6 100644
--- a/drivers/gpu/drm/i915/intel_h
[PATCH v2 3/4] drm/edid: Add drm_rgb_quant_range_selectable()
From: Ville Syrjälä
drm_rgb_quant_range_selectable() will report whether the monitor
claims to support for RGB quantization range selection.
The information can be found in the CEA Video capability block.
v2: s/quantzation/quantization/ in the comment
Reviewed-by: Paulo Zanoni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 33 +
include/drm/drm_crtc.h |1 +
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5a3770f..a3a3b61 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1483,9 +1483,11 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
#define VIDEO_BLOCK 0x02
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK 0x04
+#define VIDEO_CAPABILITY_BLOCK 0x07
#define EDID_BASIC_AUDIO (1 << 6)
#define EDID_CEA_YCRCB444 (1 << 5)
#define EDID_CEA_YCRCB422 (1 << 4)
+#define EDID_CEA_VCDB_QS (1 << 6)
/**
* Search EDID for CEA extension block.
@@ -1902,6 +1904,37 @@ end:
EXPORT_SYMBOL(drm_detect_monitor_audio);
/**
+ * drm_rgb_quant_range_selectable - is RGB quantization range selectable?
+ *
+ * Check whether the monitor reports the RGB quantization range selection
+ * as supported. The AVI infoframe can then be used to inform the monitor
+ * which quantization range (full or limited) is used.
+ */
+bool drm_rgb_quant_range_selectable(struct edid *edid)
+{
+ u8 *edid_ext;
+ int i, start, end;
+
+ edid_ext = drm_find_cea_extension(edid);
+ if (!edid_ext)
+ return false;
+
+ if (cea_db_offsets(edid_ext, &start, &end))
+ return false;
+
+ for_each_cea_db(edid_ext, i, start, end) {
+ if (cea_db_tag(&edid_ext[i]) == VIDEO_CAPABILITY_BLOCK &&
+ cea_db_payload_len(&edid_ext[i]) == 2) {
+ DRM_DEBUG_KMS("CEA VCDB 0x%02x\n", edid_ext[i + 2]);
+ return edid_ext[i + 2] & EDID_CEA_VCDB_QS;
+ }
+ }
+
+ return false;
+}
+EXPORT_SYMBOL(drm_rgb_quant_range_selectable);
+
+/**
* drm_add_display_info - pull display info out if present
* @edid: EDID data
* @info: display info (attached to connector)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 00d78b5..30892dc 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1033,6 +1033,7 @@ extern u8 *drm_find_cea_extension(struct edid *edid);
extern u8 drm_match_cea_mode(struct drm_display_mode *to_match);
extern bool drm_detect_hdmi_monitor(struct edid *edid);
extern bool drm_detect_monitor_audio(struct edid *edid);
+extern bool drm_rgb_quant_range_selectable(struct edid *edid);
extern int drm_mode_page_flip_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
extern struct drm_display_mode *drm_cvt_mode(struct drm_device *dev,
--
1.7.8.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm/i915: Provide the quantization range in the AVI infoframe
From: Ville Syrjälä
The AVI infoframe is able to inform the display whether the source is
sending full or limited range RGB data.
As per CEA-861 [1] we must first check whether the display reports the
quantization range as selectable, and if so we can set the approriate
bits in the AVI inforframe.
[1] CEA-861-E - 6.4 Format of Version 2 AVI InfoFrame
v2: Give the Q bits better names, add spec chapter information
Reviewed-by: Paulo Zanoni
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_drv.h |4
drivers/gpu/drm/i915/intel_hdmi.c | 11 +++
drivers/gpu/drm/i915/intel_sdvo.c | 16 ++--
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1a698c6..aeff0d1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -289,6 +289,9 @@ struct cxsr_latency {
#define DIP_LEN_AVI 13
#define DIP_AVI_PR_10
#define DIP_AVI_PR_21
+#define DIP_AVI_RGB_QUANT_RANGE_DEFAULT(0 << 2)
+#define DIP_AVI_RGB_QUANT_RANGE_LIMITED(1 << 2)
+#define DIP_AVI_RGB_QUANT_RANGE_FULL (2 << 2)
#define DIP_TYPE_SPD 0x83
#define DIP_VERSION_SPD0x1
@@ -347,6 +350,7 @@ struct intel_hdmi {
bool has_hdmi_sink;
bool has_audio;
enum hdmi_force_audio force_audio;
+ bool rgb_quant_range_selectable;
void (*write_infoframe)(struct drm_encoder *encoder,
struct dip_infoframe *frame);
void (*set_infoframes)(struct drm_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index db67be6..d53b731 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -331,6 +331,7 @@ static void intel_set_infoframe(struct drm_encoder *encoder,
static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
struct drm_display_mode *adjusted_mode)
{
+ struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
struct dip_infoframe avi_if = {
.type = DIP_TYPE_AVI,
.ver = DIP_VERSION_AVI,
@@ -340,6 +341,13 @@ static void intel_hdmi_set_avi_infoframe(struct
drm_encoder *encoder,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
avi_if.body.avi.YQ_CN_PR |= DIP_AVI_PR_2;
+ if (intel_hdmi->rgb_quant_range_selectable) {
+ if (adjusted_mode->private_flags &
INTEL_MODE_LIMITED_COLOR_RANGE)
+ avi_if.body.avi.ITC_EC_Q_SC |=
DIP_AVI_RGB_QUANT_RANGE_LIMITED;
+ else
+ avi_if.body.avi.ITC_EC_Q_SC |=
DIP_AVI_RGB_QUANT_RANGE_FULL;
+ }
+
avi_if.body.avi.VIC = drm_mode_cea_vic(adjusted_mode);
intel_set_infoframe(encoder, &avi_if);
@@ -825,6 +833,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
intel_hdmi->has_hdmi_sink = false;
intel_hdmi->has_audio = false;
+ intel_hdmi->rgb_quant_range_selectable = false;
edid = drm_get_edid(connector,
intel_gmbus_get_adapter(dev_priv,
intel_hdmi->ddc_bus));
@@ -836,6 +845,8 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
intel_hdmi->has_hdmi_sink =
drm_detect_hdmi_monitor(edid);
intel_hdmi->has_audio = drm_detect_monitor_audio(edid);
+ intel_hdmi->rgb_quant_range_selectable =
+ drm_rgb_quant_range_selectable(edid);
}
kfree(edid);
}
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 3e34a35..f01063a 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -126,6 +126,7 @@ struct intel_sdvo {
bool is_hdmi;
bool has_hdmi_monitor;
bool has_hdmi_audio;
+ bool rgb_quant_range_selectable;
/**
* This is set if we detect output of sdvo device as LVDS and
@@ -947,7 +948,8 @@ static bool intel_sdvo_write_infoframe(struct intel_sdvo
*intel_sdvo,
&tx_rate, 1);
}
-static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo)
+static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo,
+const struct drm_display_mode
*adjusted_mode)
{
struct dip_infoframe avi_if = {
.type = DIP_TYPE_AVI,
@@ -956,6 +958,13 @@ static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo
*intel_sdvo)
};
uint8_t sdvo_data[4 + sizeof(avi_if.body.avi)];
+ if (intel_sdvo->rgb_quant_range_selectable) {
+ if (adjusted_mode->private_flags &
INTEL_MODE_LIMITED_COLOR_RANGE)
+
Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf wrote: > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf >> wrote: >> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote: >> >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf >> >> wrote: >> >> > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf wrote: >> >> >> On 2013.01.15 at 16:26 +0100, Michel Dänzer wrote: >> >> >> > On Die, 201301-15 at 16:23 +0100, Markus Trippelsdorf wrote: >> >> >> > > On 2013.01.15 at 15:43 +0100, Michel Dänzer wrote: >> >> >> > > > On Sam, 2013-01-05 at 11:41 +0100, Markus Trippelsdorf wrote: >> >> >> > > > > On 2012.12.20 at 14:58 +0100, Markus Trippelsdorf wrote: >> >> >> > > > > > >> >> >> > > > > > And just in case it got lost in the noise yesterday: >> >> >> > > > > > The image corruption is caused by Dave's commit: >> >> >> > > > > > >> >> >> > > > > > commit dd54fee7d440c4a9756cce2c24a50c15e4c17ccb >> >> >> > > > > > Author: Dave Airlie >> >> >> > > > > > Date: Fri Dec 14 21:04:46 2012 +1000 >> >> >> > > > > > >> >> >> > > > > > radeon: fix regression with eviction since evict caching >> >> >> > > > > > changes >> >> >> > > > > > >> >> >> > > > > > Reverting it 'fixes' the issue. >> >> >> > > > > >> >> >> > > > > Ping. >> >> >> > > > > The issue still happens with todays Linus git tree. >> >> >> > > > >> >> >> > > > Does the corruption also occur with >> >> >> > > > dd54fee7d440c4a9756cce2c24a50c15e4c17ccb applied manually on top >> >> >> > > > of >> >> >> > > > 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d? >> >> >> > > >> >> >> > > No. >> >> >> > >> >> >> > So, can you bisect which change between those two actually introduced >> >> >> > the corruption? >> >> > >> >> > The real cause of the image corruption is: >> >> > >> >> > d025e9e2b890db679f1246037bf65bd4be512627 is the first bad commit >> >> > commit d025e9e2b890db679f1246037bf65bd4be512627 >> >> > Author: Jerome Glisse >> >> > Date: Thu Nov 29 10:35:41 2012 -0500 >> >> > >> >> > drm/radeon: do not move bo to different placement at each cs >> >> > >> >> > The bo creation placement is where the bo will be. Instead of trying >> >> > to move bo at each command stream let this work to another worker >> >> > thread that will use more advance heuristic. >> >> > >> >> > agd5f: remove leftover unused variable >> >> > >> >> > Signed-off-by: Jerome Glisse >> >> > Reviewed-by: Alex Deucher >> >> > >> >> > Reverting d025e9e2b890d on top of Linus' tree fixes the issue. >> >> >> >> Can you try this patch from Jerome: >> >> https://bugzilla.kernel.org/attachment.cgi?id=91421 >> > >> > It fixes the corruption, but it degrades performance so much that it >> > takes several seconds to switch virtual desktops under xmonad. And >> > sometimes the website used for the scroll test is stuck for several >> > seconds and unscrollable during that time. >> > >> > -- >> > Markus >> >> What about this patch instead : >> http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch > > This one doesn't work: > > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: GPU lockup CP stall for more > than 1msec > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: GPU lockup (waiting for > 0x0a63 last fence id 0x0a62) > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to parse > relocation -12! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_
[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot
https://bugs.freedesktop.org/show_bug.cgi?id=58659 --- Comment #19 from Jerome Glisse --- Updated patch http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch Still weird that you point to same commit and first patch did not solve it. -- 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] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote: > On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf > wrote: > > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: > >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf > >> wrote: > >> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote: > >> >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf > >> >> wrote: > >> >> > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf wrote: > >> >> >> On 2013.01.15 at 16:26 +0100, Michel Dänzer wrote: > >> >> >> > On Die, 201301-15 at 16:23 +0100, Markus Trippelsdorf wrote: > >> >> >> > > On 2013.01.15 at 15:43 +0100, Michel Dänzer wrote: > >> >> >> > > > On Sam, 2013-01-05 at 11:41 +0100, Markus Trippelsdorf wrote: > >> >> >> > > > > On 2012.12.20 at 14:58 +0100, Markus Trippelsdorf wrote: > >> >> >> > > > > > > >> >> >> > > > > > And just in case it got lost in the noise yesterday: > >> >> >> > > > > > The image corruption is caused by Dave's commit: > >> >> >> > > > > > > >> >> >> > > > > > commit dd54fee7d440c4a9756cce2c24a50c15e4c17ccb > >> >> >> > > > > > Author: Dave Airlie > >> >> >> > > > > > Date: Fri Dec 14 21:04:46 2012 +1000 > >> >> >> > > > > > > >> >> >> > > > > > radeon: fix regression with eviction since evict > >> >> >> > > > > > caching changes > >> >> >> > > > > > > >> >> >> > > > > > Reverting it 'fixes' the issue. > >> >> >> > > > > > >> >> >> > > > > Ping. > >> >> >> > > > > The issue still happens with todays Linus git tree. > >> >> >> > > > > >> >> >> > > > Does the corruption also occur with > >> >> >> > > > dd54fee7d440c4a9756cce2c24a50c15e4c17ccb applied manually on > >> >> >> > > > top of > >> >> >> > > > 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d? > >> >> >> > > > >> >> >> > > No. > >> >> >> > > >> >> >> > So, can you bisect which change between those two actually > >> >> >> > introduced > >> >> >> > the corruption? > >> >> > > >> >> > The real cause of the image corruption is: > >> >> > > >> >> > d025e9e2b890db679f1246037bf65bd4be512627 is the first bad commit > >> >> > commit d025e9e2b890db679f1246037bf65bd4be512627 > >> >> > Author: Jerome Glisse > >> >> > Date: Thu Nov 29 10:35:41 2012 -0500 > >> >> > > >> >> > drm/radeon: do not move bo to different placement at each cs > >> >> > > >> >> > The bo creation placement is where the bo will be. Instead of > >> >> > trying > >> >> > to move bo at each command stream let this work to another worker > >> >> > thread that will use more advance heuristic. > >> >> > > >> >> > agd5f: remove leftover unused variable > >> >> > > >> >> > Signed-off-by: Jerome Glisse > >> >> > Reviewed-by: Alex Deucher > >> >> > > >> >> > Reverting d025e9e2b890d on top of Linus' tree fixes the issue. > >> >> > >> >> Can you try this patch from Jerome: > >> >> https://bugzilla.kernel.org/attachment.cgi?id=91421 > >> > > >> > It fixes the corruption, but it degrades performance so much that it > >> > takes several seconds to switch virtual desktops under xmonad. And > >> > sometimes the website used for the scroll test is stuck for several > >> > seconds and unscrollable during that time. > >> > > >> > -- > >> > Markus > >> > >> What about this patch instead : > >> http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch > > > > This one doesn't work: > > Same address updated patch > > http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch It still doesn't work unfortunately. Can you please just revert d025e9e2b89 for now? Maybe it's better to wait for the next kernel release for another solution. Jan 17 17:05:34 x4 kernel: radeon :01:05.0: GPU lockup CP stall for more than 1msec Jan 17 17:05:34 x4 kernel: radeon :01:05.0: GPU lockup (waiting for 0x022b last fence id 0x0224) Jan 17 17:05:34 x4 kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (764, 6, 4096, -12) Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (764, 6, 4096, -12) Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (764, 6, 4096, -12) Jan 17 17:05:34 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 17:05:34 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (7098368, 6, 4096, -12) Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (7278592, 2, 4096, -12) -- Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59521] New: [Serious Sam 3] Missing textures with R600g
https://bugs.freedesktop.org/show_bug.cgi?id=59521 Priority: medium Bug ID: 59521 Assignee: dri-devel@lists.freedesktop.org Summary: [Serious Sam 3] Missing textures with R600g Severity: normal Classification: Unclassified OS: Linux (All) Reporter: lordhea...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa OpenGL renderer string: Gallium 0.4 on AMD BARTS OpenGL version string: 3.0 Mesa 9.1-devel (git-1cedf78) OpenGL shading language version string: 1.30 Linux archMain 3.7.2-1-ARCH With recent OpenGL 3.1/glsl 1.40 support, SS3 is now rendering empty textures. Here is the log output: --8<-- INF: Encoded user ID = 07c6d27b:425ae20b saving roaming config store to 'sharedconfig.vdf' roaming config store 2 saved successfully INF: INF: * Desktop settings... INF: Color depth: 32-bit INF: Desktop resolution: 1920 x 1080 INF: Fullscreen on primary display Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=0x9047) Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=0x87fc) WRN: [OpenGL] Unable to determine VRAM size... assuming 512 MB. Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=0x9048) Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=0x87fc) Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?) INF: INF: Gfx API: OpenGL INF: Resolution: 1920 x 1080 INF: Vendor: ATI (0x1002) INF: Driver: X.Org (0x6738) INF: Renderer: Gallium 0.4 on AMD BARTS INF: Version: 3.0 Mesa 9.1-devel (git-1cedf78) INF: Video memory size: 512 MB INF: Available for textures: 512 MB INF: Active GPU(s): 1 WRN: Display driver is too old, please update it ASAP! INF: INF: Sfx API: OpenAL INF: Device: OpenAL Soft INF: Mixer frequency: 44100 Hz INF: Mixer voices: 64 INF: Max sound sources: 30 INF: Max total volume: 3 INF: Speaker config: (unknown) INF: Environment FX: not supported INF: ERR: OpenGL: API error! (CreateStaticVertexBuffer) INF: AutoDetect: Hardware values unchanged, nothing to do. Installing breakpad exception handler for appid(steam)/version(1358286427_client) Installing breakpad exception handler for appid(steam)/version(1358286427_client) INF: Started simulation on 'Content/SeriousSam3/Levels/Menu/Intro.wld' in 0.53 seconds. Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?) ERR: OpenGL: API error! (NewTextureCanvas, texture-buffer object) Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?) ERR: OpenGL: API error! (NewTextureCanvas, texture-buffer object) Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?) ERR: OpenGL: API error! (NewTextureCanvas, texture-buffer object) Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?) ERR: OpenGL: API error! (NewTextureCanvas, texture-buffer object) INF: Started simulation on 'Content/SeriousSam3/Levels/Menu/MenuLevel.wld' in 0.16 seconds. Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?) ERR: OpenGL: API error! (NewTextureCanvas, texture-buffer object) Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?) ERR: OpenGL: API error! (NewTextureCanvas, texture-buffer object) Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?) ERR: OpenGL: API error! (NewTextureCanvas, texture-buffer object) Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?) ERR: OpenGL: API error! (NewTextureCanvas, texture-buffer object) Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?) Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?) Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?) ERR: OpenGL: API error! (NewTextureCanvas, texture-buffer object) Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?) Game removed: AppID 41070 "Serious Sam 3: BFE", ProcID 19760 saving roaming config store to 'sharedconfig.vdf' roaming config store 2 saved successfully Generating new string page texture 116: 24x256, total string texture memory is 2,42 MB Shutting down. . . unlinked 2 orphaned pipes CAsyncIOManager: 0 threads terminating. 0 reads, 0 writes, 0 deferrals. CAsyncIOManager: 371866 single object sleeps, 598 multi object sle
[Bug 59521] [Serious Sam 3] Missing textures with R600g
https://bugs.freedesktop.org/show_bug.cgi?id=59521 --- Comment #1 from Alex Deucher --- If the game uses compressed textures, make sure you have libtxc-dxtn installed. -- 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 59521] [Serious Sam 3] Missing textures with R600g
https://bugs.freedesktop.org/show_bug.cgi?id=59521 --- Comment #2 from Laurent carlier --- Of course, lib32-libtxc_dxtn is installed: $ pacman -Qs lib32-libtxc_dxtn local/lib32-libtxc_dxtn 1.0.1-3 Texture compression library for Mesa (32-bit) -- 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 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #38 from Thomas Rohloff --- (In reply to comment #37) > This patch might help: I applied it to a 3.8-rc3 kernel and while I didn't see the message spam till now the GPU crashes extremely often (so often that this might be the case I'm unable to see the spam). Either the image freezes or the monitor goes into standby. In both cases the keyboard doesn't react anymore (not even SysMagRQ). -- 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 2377] Polygon stipple broken.
https://bugs.freedesktop.org/show_bug.cgi?id=2377 --- Comment #7 from Roland Scheidegger --- Looks to me like the offsets for the stipple pattern are wrong. These are set in r200UpdateViewportOffset - which has no callers. I noted this in bug 57842, and tried to address it there though the patch probably wasn't really right in any case, but you could try that as a starting point. (I'm not sure though if actually we don't also need to take viewport into account for the offsets? Maybe not though. I'm pretty sure though stippling also additionally would be broken for fbo's (but certainly should go unnoticed by this test), as the code does as the comment says, always invert the stippling pattern, and the y offset is also always calculated taking the window height into account, and I strongly suspect both aren't right for fbos.) -- 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] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf wrote: > On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote: >> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf >> wrote: >> > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: >> >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf >> >> wrote: >> >> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote: >> >> >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf >> >> >> wrote: >> >> >> > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf wrote: >> >> >> >> On 2013.01.15 at 16:26 +0100, Michel Dänzer wrote: >> >> >> >> > On Die, 201301-15 at 16:23 +0100, Markus Trippelsdorf wrote: >> >> >> >> > > On 2013.01.15 at 15:43 +0100, Michel Dänzer wrote: >> >> >> >> > > > On Sam, 2013-01-05 at 11:41 +0100, Markus Trippelsdorf wrote: >> >> >> >> > > > > On 2012.12.20 at 14:58 +0100, Markus Trippelsdorf wrote: >> >> >> >> > > > > > >> >> >> >> > > > > > And just in case it got lost in the noise yesterday: >> >> >> >> > > > > > The image corruption is caused by Dave's commit: >> >> >> >> > > > > > >> >> >> >> > > > > > commit dd54fee7d440c4a9756cce2c24a50c15e4c17ccb >> >> >> >> > > > > > Author: Dave Airlie >> >> >> >> > > > > > Date: Fri Dec 14 21:04:46 2012 +1000 >> >> >> >> > > > > > >> >> >> >> > > > > > radeon: fix regression with eviction since evict >> >> >> >> > > > > > caching changes >> >> >> >> > > > > > >> >> >> >> > > > > > Reverting it 'fixes' the issue. >> >> >> >> > > > > >> >> >> >> > > > > Ping. >> >> >> >> > > > > The issue still happens with todays Linus git tree. >> >> >> >> > > > >> >> >> >> > > > Does the corruption also occur with >> >> >> >> > > > dd54fee7d440c4a9756cce2c24a50c15e4c17ccb applied manually on >> >> >> >> > > > top of >> >> >> >> > > > 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d? >> >> >> >> > > >> >> >> >> > > No. >> >> >> >> > >> >> >> >> > So, can you bisect which change between those two actually >> >> >> >> > introduced >> >> >> >> > the corruption? >> >> >> > >> >> >> > The real cause of the image corruption is: >> >> >> > >> >> >> > d025e9e2b890db679f1246037bf65bd4be512627 is the first bad commit >> >> >> > commit d025e9e2b890db679f1246037bf65bd4be512627 >> >> >> > Author: Jerome Glisse >> >> >> > Date: Thu Nov 29 10:35:41 2012 -0500 >> >> >> > >> >> >> > drm/radeon: do not move bo to different placement at each cs >> >> >> > >> >> >> > The bo creation placement is where the bo will be. Instead of >> >> >> > trying >> >> >> > to move bo at each command stream let this work to another worker >> >> >> > thread that will use more advance heuristic. >> >> >> > >> >> >> > agd5f: remove leftover unused variable >> >> >> > >> >> >> > Signed-off-by: Jerome Glisse >> >> >> > Reviewed-by: Alex Deucher >> >> >> > >> >> >> > Reverting d025e9e2b890d on top of Linus' tree fixes the issue. >> >> >> >> >> >> Can you try this patch from Jerome: >> >> >> https://bugzilla.kernel.org/attachment.cgi?id=91421 >> >> > >> >> > It fixes the corruption, but it degrades performance so much that it >> >> > takes several seconds to switch virtual desktops under xmonad. And >> >> > sometimes the website used for the scroll test is stuck for several >> >> > seconds and unscrollable during that time. >> >> > >> >> > -- >> >> > Markus >> >> >> >> What about this patch instead : >> >> http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch >> > >> > This one doesn't work: >> >> Same address updated patch >> >> http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch > > It still doesn't work unfortunately. Can you please just revert > d025e9e2b89 for now? Maybe it's better to wait for the next kernel > release for another solution. > > Jan 17 17:05:34 x4 kernel: radeon :01:05.0: GPU lockup CP stall for more > than 1msec > Jan 17 17:05:34 x4 kernel: radeon :01:05.0: GPU lockup (waiting for > 0x022b last fence id 0x0224) > Jan 17 17:05:34 x4 kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to parse > relocation -12! > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to > allocate GEM object (764, 6, 4096, -12) > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to > allocate GEM object (764, 6, 4096, -12) > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to > allocate GEM object (764, 6, 4096, -12) > Jan 17 17:05:34 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 17:05:34 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to > allocate GEM object (7098368, 6, 4096, -12) > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to > allocate GEM object (7278592, 2, 4096, -12) > > -- > Markus I am trying to understand why i can't reproduce, what is your desktop (gnome
[PATCH] drm/edid: add quirk for Acer 19" display AL1917WA
From: Alex Deucher
1440x900 (native) monitor contains a bogus 1400x1050@75Hz
mode in the standard timings and fails to flag the first
detailed mode as preferred. As such, X picks 1400x1050@75Hz
which fails to display.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=59211
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/drm_edid.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5a3770f..aad38b6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -96,6 +96,8 @@ static struct edid_quirk {
{ "API", 0x7602, EDID_QUIRK_PREFER_LARGE_60 },
/* Unknown Acer */
{ "ACR", 2423, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
+ /* Acer AL1917WA */
+ { "ACR", 0xad87, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
/* Belinea 10 15 55 */
{ "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On 2013.01.17 at 12:55 -0500, Jerome Glisse wrote: > On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf > wrote: > > On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote: > >> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf > >> wrote: > >> > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: > >> >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf > >> >> wrote: > >> >> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote: > >> >> >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf > >> >> >> wrote: > >> >> >> > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf wrote: > >> >> >> >> On 2013.01.15 at 16:26 +0100, Michel Dänzer wrote: > >> >> >> >> > On Die, 201301-15 at 16:23 +0100, Markus Trippelsdorf wrote: > >> >> >> >> > > On 2013.01.15 at 15:43 +0100, Michel Dänzer wrote: > >> >> >> >> > > > On Sam, 2013-01-05 at 11:41 +0100, Markus Trippelsdorf > >> >> >> >> > > > wrote: > >> >> >> >> > > > > On 2012.12.20 at 14:58 +0100, Markus Trippelsdorf wrote: > >> >> >> >> > > > > > > >> >> >> >> > > > > > And just in case it got lost in the noise yesterday: > >> >> >> >> > > > > > The image corruption is caused by Dave's commit: > >> >> >> >> > > > > > > >> >> >> >> > > > > > commit dd54fee7d440c4a9756cce2c24a50c15e4c17ccb > >> >> >> >> > > > > > Author: Dave Airlie > >> >> >> >> > > > > > Date: Fri Dec 14 21:04:46 2012 +1000 > >> >> >> >> > > > > > > >> >> >> >> > > > > > radeon: fix regression with eviction since evict > >> >> >> >> > > > > > caching changes > >> >> >> >> > > > > > > >> >> >> >> > > > > > Reverting it 'fixes' the issue. > >> >> >> >> > > > > > >> >> >> >> > > > > Ping. > >> >> >> >> > > > > The issue still happens with todays Linus git tree. > >> >> >> >> > > > > >> >> >> >> > > > Does the corruption also occur with > >> >> >> >> > > > dd54fee7d440c4a9756cce2c24a50c15e4c17ccb applied manually > >> >> >> >> > > > on top of > >> >> >> >> > > > 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d? > >> >> >> >> > > > >> >> >> >> > > No. > >> >> >> >> > > >> >> >> >> > So, can you bisect which change between those two actually > >> >> >> >> > introduced > >> >> >> >> > the corruption? > >> >> >> > > >> >> >> > The real cause of the image corruption is: > >> >> >> > > >> >> >> > d025e9e2b890db679f1246037bf65bd4be512627 is the first bad commit > >> >> >> > commit d025e9e2b890db679f1246037bf65bd4be512627 > >> >> >> > Author: Jerome Glisse > >> >> >> > Date: Thu Nov 29 10:35:41 2012 -0500 > >> >> >> > > >> >> >> > drm/radeon: do not move bo to different placement at each cs > >> >> >> > > >> >> >> > The bo creation placement is where the bo will be. Instead of > >> >> >> > trying > >> >> >> > to move bo at each command stream let this work to another > >> >> >> > worker > >> >> >> > thread that will use more advance heuristic. > >> >> >> > > >> >> >> > agd5f: remove leftover unused variable > >> >> >> > > >> >> >> > Signed-off-by: Jerome Glisse > >> >> >> > Reviewed-by: Alex Deucher > >> >> >> > > >> >> >> > Reverting d025e9e2b890d on top of Linus' tree fixes the issue. > >> >> >> > >> >> >> Can you try this patch from Jerome: > >> >> >> https://bugzilla.kernel.org/attachment.cgi?id=91421 > >> >> > > >> >> > It fixes the corruption, but it degrades performance so much that it > >> >> > takes several seconds to switch virtual desktops under xmonad. And > >> >> > sometimes the website used for the scroll test is stuck for several > >> >> > seconds and unscrollable during that time. > >> >> > > >> >> > -- > >> >> > Markus > >> >> > >> >> What about this patch instead : > >> >> http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch > >> > > >> > This one doesn't work: > >> > >> Same address updated patch > >> > >> http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch > > > > It still doesn't work unfortunately. Can you please just revert > > d025e9e2b89 for now? Maybe it's better to wait for the next kernel > > release for another solution. > > > > Jan 17 17:05:34 x4 kernel: radeon :01:05.0: GPU lockup CP stall for > > more than 1msec > > Jan 17 17:05:34 x4 kernel: radeon :01:05.0: GPU lockup (waiting for > > 0x022b last fence id 0x0224) > > Jan 17 17:05:34 x4 kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to parse > > relocation -12! > > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to > > allocate GEM object (764, 6, 4096, -12) > > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to > > allocate GEM object (764, 6, 4096, -12) > > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to > > allocate GEM object (764, 6, 4096, -12) > > Jan 17 17:05:34 x4 kernel: radeon :01:05.0: couldn't schedule ib > > Jan 17 17:05:34 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > > schedule IB ! > > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_ob
[PATCH libdrm] radeon: Fix 1D tiling layout on SI.
From: Michel Dänzer
Very similar to Evergreen, but slightly different rules for tile / slice
alignment. Fortunately, these map quite naturally onto the previous fixes for
linear aligned layout on SI.
2D tiling still needs more work here and possibly in the kernel.
Signed-off-by: Michel Dänzer
---
radeon/radeon_surface.c | 111 +--
1 file changed, 88 insertions(+), 23 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index eb587d2..8e93873 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -1000,25 +1000,28 @@ 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)
+static void si_surf_minify(struct radeon_surface *surf,
+ struct radeon_surface_level *surflevel,
+ unsigned bpe, 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);
+surflevel->npix_x = mip_minify(surf->npix_x, level);
+surflevel->npix_y = mip_minify(surf->npix_y, level);
+surflevel->npix_z = mip_minify(surf->npix_z, level);
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;
+surflevel->nblk_x = (next_power_of_two(surflevel->npix_x) +
surf->blk_w - 1) / surf->blk_w;
+surflevel->nblk_y = (next_power_of_two(surflevel->npix_y) +
surf->blk_h - 1) / surf->blk_h;
+surflevel->nblk_z = (next_power_of_two(surflevel->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;
+surflevel->nblk_x = (surflevel->npix_x + surf->blk_w - 1) /
surf->blk_w;
+surflevel->nblk_y = (surflevel->npix_y + surf->blk_h - 1) /
surf->blk_h;
+surflevel->nblk_z = (surflevel->npix_z + surf->blk_d - 1) /
surf->blk_d;
}
+surflevel->nblk_y = ALIGN(surflevel->nblk_y, yalign);
+
/* XXX: Texture sampling uses unexpectedly large pitches in some cases,
* these are just guesses for the rules behind those
*/
@@ -1027,17 +1030,16 @@ static void si_surf_minify_linear_aligned(struct
radeon_surface *surf,
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);
+xalign = MAX2(xalign, slice_align / surf->bpe / surflevel->nblk_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);
+surflevel->nblk_x = ALIGN(surflevel->nblk_x, xalign);
+surflevel->nblk_z = ALIGN(surflevel->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);
+surflevel->offset = offset;
+surflevel->pitch_bytes = surflevel->nblk_x * surf->bpe * surf->nsamples;
+surflevel->slice_size = ALIGN(surflevel->pitch_bytes * surflevel->nblk_y,
slice_align);
-surf->bo_size = offset + surf->level[level].slice_size *
surf->level[level].nblk_z * surf->array_size;
+surf->bo_size = offset + surflevel->slice_size * surflevel->nblk_z *
surf->array_size;
}
static int si_surface_init_linear_aligned(struct radeon_surface_manager
*surf_man,
@@ -1059,7 +1061,48 @@ static int si_surface_init_linear_aligned(struct
radeon_surface_manager *surf_ma
/* 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
[Bug 2377] Polygon stipple broken.
https://bugs.freedesktop.org/show_bug.cgi?id=2377 --- Comment #8 from smoki --- I was tested your patch from bug 57842 when you posted it there, but as i remember many random mesa demos i tried started to segfault with it. -- 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] drm/radeon: fix NULL pointer dereference in UMS mode in radeon_cs_parser_fini()
On Wed, 2013-01-16 at 21:06 -0600, Ilija Hadzic wrote: > Actually, the code path affected by your patch is not executed in UMS mode > at all. Notice that radeon_cs_parser_fini is only called from > radeon_cs_ioctl which is a KMS-only ioctl (see radeon_kms.c). > > The equivalent of the fix you are trying to do is in > a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e (function patched by that one is > the one used by legacy-CS ioctl), which you should go together > with ff4bd0827764e10a428a9d39e6814c5478863f94 if you are backporting UMS > fixes to 3.7. Both are needed to prevent kernel crashes in UMS mode. > > -- Ilija Thanks. I will take a look at a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e. I sent back-ported ff4bd0827764e10a428a9d39e6814c5478863f94 patch to stable and I will back-port and send a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e as well. -- Shuah ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf wrote: > On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote: >> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf >> wrote: >> > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: >> >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf >> >> wrote: >> >> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote: >> >> >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf >> >> >> wrote: >> >> >> > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf wrote: >> >> >> >> On 2013.01.15 at 16:26 +0100, Michel Dänzer wrote: >> >> >> >> > On Die, 201301-15 at 16:23 +0100, Markus Trippelsdorf wrote: >> >> >> >> > > On 2013.01.15 at 15:43 +0100, Michel Dänzer wrote: >> >> >> >> > > > On Sam, 2013-01-05 at 11:41 +0100, Markus Trippelsdorf wrote: >> >> >> >> > > > > On 2012.12.20 at 14:58 +0100, Markus Trippelsdorf wrote: >> >> >> >> > > > > > >> >> >> >> > > > > > And just in case it got lost in the noise yesterday: >> >> >> >> > > > > > The image corruption is caused by Dave's commit: >> >> >> >> > > > > > >> >> >> >> > > > > > commit dd54fee7d440c4a9756cce2c24a50c15e4c17ccb >> >> >> >> > > > > > Author: Dave Airlie >> >> >> >> > > > > > Date: Fri Dec 14 21:04:46 2012 +1000 >> >> >> >> > > > > > >> >> >> >> > > > > > radeon: fix regression with eviction since evict >> >> >> >> > > > > > caching changes >> >> >> >> > > > > > >> >> >> >> > > > > > Reverting it 'fixes' the issue. >> >> >> >> > > > > >> >> >> >> > > > > Ping. >> >> >> >> > > > > The issue still happens with todays Linus git tree. >> >> >> >> > > > >> >> >> >> > > > Does the corruption also occur with >> >> >> >> > > > dd54fee7d440c4a9756cce2c24a50c15e4c17ccb applied manually on >> >> >> >> > > > top of >> >> >> >> > > > 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d? >> >> >> >> > > >> >> >> >> > > No. >> >> >> >> > >> >> >> >> > So, can you bisect which change between those two actually >> >> >> >> > introduced >> >> >> >> > the corruption? >> >> >> > >> >> >> > The real cause of the image corruption is: >> >> >> > >> >> >> > d025e9e2b890db679f1246037bf65bd4be512627 is the first bad commit >> >> >> > commit d025e9e2b890db679f1246037bf65bd4be512627 >> >> >> > Author: Jerome Glisse >> >> >> > Date: Thu Nov 29 10:35:41 2012 -0500 >> >> >> > >> >> >> > drm/radeon: do not move bo to different placement at each cs >> >> >> > >> >> >> > The bo creation placement is where the bo will be. Instead of >> >> >> > trying >> >> >> > to move bo at each command stream let this work to another worker >> >> >> > thread that will use more advance heuristic. >> >> >> > >> >> >> > agd5f: remove leftover unused variable >> >> >> > >> >> >> > Signed-off-by: Jerome Glisse >> >> >> > Reviewed-by: Alex Deucher >> >> >> > >> >> >> > Reverting d025e9e2b890d on top of Linus' tree fixes the issue. >> >> >> >> >> >> Can you try this patch from Jerome: >> >> >> https://bugzilla.kernel.org/attachment.cgi?id=91421 >> >> > >> >> > It fixes the corruption, but it degrades performance so much that it >> >> > takes several seconds to switch virtual desktops under xmonad. And >> >> > sometimes the website used for the scroll test is stuck for several >> >> > seconds and unscrollable during that time. >> >> > >> >> > -- >> >> > Markus >> >> >> >> What about this patch instead : >> >> http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch >> > >> > This one doesn't work: >> >> Same address updated patch >> >> http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch > > It still doesn't work unfortunately. Can you please just revert > d025e9e2b89 for now? Maybe it's better to wait for the next kernel > release for another solution. > > Jan 17 17:05:34 x4 kernel: radeon :01:05.0: GPU lockup CP stall for more > than 1msec > Jan 17 17:05:34 x4 kernel: radeon :01:05.0: GPU lockup (waiting for > 0x022b last fence id 0x0224) > Jan 17 17:05:34 x4 kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to parse > relocation -12! > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to > allocate GEM object (764, 6, 4096, -12) > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to > allocate GEM object (764, 6, 4096, -12) > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to > allocate GEM object (764, 6, 4096, -12) > Jan 17 17:05:34 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 17:05:34 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to > allocate GEM object (7098368, 6, 4096, -12) > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to > allocate GEM object (7278592, 2, 4096, -12) > > -- > Markus For 3.9 sake can you try if http://people.freedesktop.org/~glisse/0001-drm-r
Re: [pull] radeon drm-fixes-3.8
One more fix on top. Just a revert of the bo placement patch that has been causing corruption for a number of people. Revert "drm/radeon: do not move bo to different placement at each cs" This reverts commit d025e9e2b890db679f1246037bf65bd4be512627. This causes corruption for a number of users and needs further investigation in the next cycle. https://bugzilla.kernel.org/show_bug.cgi?id=52491 https://bugs.freedesktop.org/show_bug.cgi?id=58659 http://lists.freedesktop.org/archives/dri-devel/2013-January/032961.html Signed-off-by: Alex Deucher Thanks! Alex On Tue, Jan 15, 2013 at 9:21 AM, wrote: > From: Alex Deucher > > Hi Dave, > > Just a few small fixes. > > The following changes since commit 7b4cf994e4c6ba48872bb25253cc393b7fb74c82: > > udldrmfb: udl_get_edid: drop unneeded i-- (2013-01-14 08:45:27 +1000) > > are available in the git repository at: > git://people.freedesktop.org/~agd5f/linux drm-fixes-3.8 > > Alex Deucher (1): > drm/radeon: clear reset flags if engines are idle > > Jerome Glisse (1): > drm/radeon: improve semaphore debugging on lockup > > Marek Olšák (1): > drm/radeon: allow FP16 color clear registers on r500 > > drivers/gpu/drm/radeon/evergreen.c|6 ++ > drivers/gpu/drm/radeon/ni.c |6 ++ > drivers/gpu/drm/radeon/r600.c |6 ++ > drivers/gpu/drm/radeon/radeon.h |2 ++ > drivers/gpu/drm/radeon/radeon_drv.c |3 ++- > drivers/gpu/drm/radeon/radeon_ring.c |2 ++ > drivers/gpu/drm/radeon/radeon_semaphore.c |4 > drivers/gpu/drm/radeon/reg_srcs/rv515 |2 ++ > drivers/gpu/drm/radeon/si.c |6 ++ > 9 files changed, 36 insertions(+), 1 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #39 from Alexandre Demers --- (In reply to comment #38) > (In reply to comment #37) > > This patch might help: > > I applied it to a 3.8-rc3 kernel and while I didn't see the message spam > till now the GPU crashes extremely often (so often that this might be the > case I'm unable to see the spam). Either the image freezes or the monitor > goes into standby. In both cases the keyboard doesn't react anymore (not > even SysMagRQ). Does it do the same thing without the patch? I applied it yesterday and I haven't seen any difference. -- 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] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On 2013.01.17 at 13:28 -0500, Jerome Glisse wrote: > On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf > wrote: > > On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote: > >> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf > >> wrote: > >> > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: > >> >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf > >> >> wrote: > >> >> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote: > >> >> >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf > >> >> >> wrote: > >> >> >> > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf wrote: > >> >> >> >> On 2013.01.15 at 16:26 +0100, Michel Dänzer wrote: > >> >> >> >> > On Die, 201301-15 at 16:23 +0100, Markus Trippelsdorf wrote: > >> >> >> >> > > On 2013.01.15 at 15:43 +0100, Michel Dänzer wrote: > >> >> >> >> > > > On Sam, 2013-01-05 at 11:41 +0100, Markus Trippelsdorf > >> >> >> >> > > > wrote: > >> >> >> >> > > > > On 2012.12.20 at 14:58 +0100, Markus Trippelsdorf wrote: > >> >> >> >> > > > > > > >> >> >> >> > > > > > And just in case it got lost in the noise yesterday: > >> >> >> >> > > > > > The image corruption is caused by Dave's commit: > >> >> >> >> > > > > > > >> >> >> >> > > > > > commit dd54fee7d440c4a9756cce2c24a50c15e4c17ccb > >> >> >> >> > > > > > Author: Dave Airlie > >> >> >> >> > > > > > Date: Fri Dec 14 21:04:46 2012 +1000 > >> >> >> >> > > > > > > >> >> >> >> > > > > > radeon: fix regression with eviction since evict > >> >> >> >> > > > > > caching changes > >> >> >> >> > > > > > > >> >> >> >> > > > > > Reverting it 'fixes' the issue. > >> >> >> >> > > > > > >> >> >> >> > > > > Ping. > >> >> >> >> > > > > The issue still happens with todays Linus git tree. > >> >> >> >> > > > > >> >> >> >> > > > Does the corruption also occur with > >> >> >> >> > > > dd54fee7d440c4a9756cce2c24a50c15e4c17ccb applied manually > >> >> >> >> > > > on top of > >> >> >> >> > > > 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d? > >> >> >> >> > > > >> >> >> >> > > No. > >> >> >> >> > > >> >> >> >> > So, can you bisect which change between those two actually > >> >> >> >> > introduced > >> >> >> >> > the corruption? > >> >> >> > > >> >> >> > The real cause of the image corruption is: > >> >> >> > > >> >> >> > d025e9e2b890db679f1246037bf65bd4be512627 is the first bad commit > >> >> >> > commit d025e9e2b890db679f1246037bf65bd4be512627 > >> >> >> > Author: Jerome Glisse > >> >> >> > Date: Thu Nov 29 10:35:41 2012 -0500 > >> >> >> > > >> >> >> > drm/radeon: do not move bo to different placement at each cs > >> >> >> > > >> >> >> > The bo creation placement is where the bo will be. Instead of > >> >> >> > trying > >> >> >> > to move bo at each command stream let this work to another > >> >> >> > worker > >> >> >> > thread that will use more advance heuristic. > >> >> >> > > >> >> >> > agd5f: remove leftover unused variable > >> >> >> > > >> >> >> > Signed-off-by: Jerome Glisse > >> >> >> > Reviewed-by: Alex Deucher > >> >> >> > > >> >> >> > Reverting d025e9e2b890d on top of Linus' tree fixes the issue. > >> >> >> > >> >> >> Can you try this patch from Jerome: > >> >> >> https://bugzilla.kernel.org/attachment.cgi?id=91421 > >> >> > > >> >> > It fixes the corruption, but it degrades performance so much that it > >> >> > takes several seconds to switch virtual desktops under xmonad. And > >> >> > sometimes the website used for the scroll test is stuck for several > >> >> > seconds and unscrollable during that time. > >> >> > > >> >> > -- > >> >> > Markus > >> >> > >> >> What about this patch instead : > >> >> http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch > >> > > >> > This one doesn't work: > >> > >> Same address updated patch > >> > >> http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch > > > > It still doesn't work unfortunately. Can you please just revert > > d025e9e2b89 for now? Maybe it's better to wait for the next kernel > > release for another solution. > > > > Jan 17 17:05:34 x4 kernel: radeon :01:05.0: GPU lockup CP stall for > > more than 1msec > > Jan 17 17:05:34 x4 kernel: radeon :01:05.0: GPU lockup (waiting for > > 0x022b last fence id 0x0224) > > Jan 17 17:05:34 x4 kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to parse > > relocation -12! > > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to > > allocate GEM object (764, 6, 4096, -12) > > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to > > allocate GEM object (764, 6, 4096, -12) > > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to > > allocate GEM object (764, 6, 4096, -12) > > Jan 17 17:05:34 x4 kernel: radeon :01:05.0: couldn't schedule ib > > Jan 17 17:05:34 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > > schedule IB ! > > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_ob
[Bug 2377] Polygon stipple broken.
https://bugs.freedesktop.org/show_bug.cgi?id=2377 --- Comment #9 from smoki --- Created attachment 73194 --> https://bugs.freedesktop.org/attachment.cgi?id=73194&action=edit ums and mesa 7.5.2 r200 render But overal, it is not quite correct but polys renders better now then it was with UMS. -- 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 58659] With latest kernel 3.8-rc1, compiz crashes after boot
https://bugs.freedesktop.org/show_bug.cgi?id=58659 --- Comment #20 from Bryan Quigley --- This last patch (0001-drm-radeon-exclude-system-placement-when-validating) creates a full Xorg freeze: Form xorg.log: [ 207.780] (WW) RADEON(0): flip queue failed: Invalid argument [ 207.781] (WW) RADEON(0): Page flip failed: Invalid argument Repeated many times >From kern.log: [ 207.595082] radeon :01:00.0: efaa7000 pin failed [ 207.595096] [drm:radeon_crtc_page_flip] *ERROR* failed to pin new rbo buffer before flip [ 207.595434] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -22! [ 207.601745] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -22! [ 207.602094] radeon :01:00.0: efaa7000 pin failed Repeated many times I'm going to git pull to latest and try building again... Does it depend on some other patch? -- 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: [pull] radeon drm-fixes-3.8
This might be responsible for the bad r300g MSAA performance results on Phoronix. I have no other explanation. There is an optimization in r300g which forces the VRAM domain for non-staging CB and DB only. Other than that, VRAM|GTT is the default for all textures and GTT is the default for all buffers, so it's pretty conservative. For the future buffer-eviction heuristics, we should take into account the actual resource usage - MSAA resources (and presumably scanout resources as well) should stay in VRAM and shouldn't be evicted by lesser resources unless the MSAA ones are idle for a very long time. MSAA resources are usually pretty big (128 MB is needed for Full HD 8x MSAA (CB+DB)), but that shouldn't stop the kernel from evicting as many less-important resources as is necessary to reserve enough space for MSAA. Marek On Thu, Jan 17, 2013 at 7:30 PM, Alex Deucher wrote: > One more fix on top. Just a revert of the bo placement patch that has > been causing corruption for a number of people. > > Revert "drm/radeon: do not move bo to different placement at each cs" > > This reverts commit d025e9e2b890db679f1246037bf65bd4be512627. > > This causes corruption for a number of users and needs further > investigation in the next cycle. > https://bugzilla.kernel.org/show_bug.cgi?id=52491 > https://bugs.freedesktop.org/show_bug.cgi?id=58659 > http://lists.freedesktop.org/archives/dri-devel/2013-January/032961.html > > Signed-off-by: Alex Deucher > > Thanks! > > Alex > > > On Tue, Jan 15, 2013 at 9:21 AM, wrote: >> From: Alex Deucher >> >> Hi Dave, >> >> Just a few small fixes. >> >> The following changes since commit 7b4cf994e4c6ba48872bb25253cc393b7fb74c82: >> >> udldrmfb: udl_get_edid: drop unneeded i-- (2013-01-14 08:45:27 +1000) >> >> are available in the git repository at: >> git://people.freedesktop.org/~agd5f/linux drm-fixes-3.8 >> >> Alex Deucher (1): >> drm/radeon: clear reset flags if engines are idle >> >> Jerome Glisse (1): >> drm/radeon: improve semaphore debugging on lockup >> >> Marek Olšák (1): >> drm/radeon: allow FP16 color clear registers on r500 >> >> drivers/gpu/drm/radeon/evergreen.c|6 ++ >> drivers/gpu/drm/radeon/ni.c |6 ++ >> drivers/gpu/drm/radeon/r600.c |6 ++ >> drivers/gpu/drm/radeon/radeon.h |2 ++ >> drivers/gpu/drm/radeon/radeon_drv.c |3 ++- >> drivers/gpu/drm/radeon/radeon_ring.c |2 ++ >> drivers/gpu/drm/radeon/radeon_semaphore.c |4 >> drivers/gpu/drm/radeon/reg_srcs/rv515 |2 ++ >> drivers/gpu/drm/radeon/si.c |6 ++ >> 9 files changed, 36 insertions(+), 1 deletions(-) > ___ > 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 52491] radeon massive screen corruption BARTS HD6870
https://bugzilla.kernel.org/show_bug.cgi?id=52491 --- Comment #15 from Bruno Jacquet 2013-01-17 19:26:36 --- (In reply to comment #14) > Better to try this patch instead first : > http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch With this patch, my game froze before I could even check the rendering. My cursor still moved, I could switch to tty1. I checked dmesg : nothing added. I went back to tty7 (X) and then it was stuck there. -- 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 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #40 from Thomas Rohloff --- (In reply to comment #39) > Does it do the same thing without the patch? It has random crashes without, too, yes. But way less frequent. In fact I had to revert that patch to be able to use my desktop for more than 5 minutes again. -- 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
Radeon HDMI question
Hi, I experience a strange problem, I don't know whether it's a feature or a bug, and if it's a bug, where. I have a Radeon HD6570. A monitor via DVI and an LCD TV via HDMI are connected. Fedora 18/x86_64 is installed on the computer. (Previously it was F17, F16 and F14.) When playing videos via Xine, all videos with 5.1 sound works nicely via the HDMI, the sound output is on the TV. However, when only stereo or mono sound is present in the video, the sound doesn't go out to the TV. I have an internal soundcard and speakers are connected. Pulseaudio on modern Linuxen has the feature to switch the audio output device on the fly and per-application, so I can switch between the outputs. Is is possible to make mono and stereo audio work via HDMI? Thanks in advance, Zoltán Böszörményi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: CDF discussions at FOSDEM
On Fri, Jan 11, 2013 at 09:27:03PM +0100, Laurent Pinchart wrote: > Would anyone be interested in meeting at the FOSDEM to discuss the Common > Display Framework ? There will be a CDF meeting at the ELC at the end of > February, the FOSDEM would be a good venue for European developers. We are interested as well (Philipp, Michael, Sascha, me, maybe also some of the others from the Pengutronix crew...). rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58033] [r300g] Black gap artifacts when playing WoW
https://bugs.freedesktop.org/show_bug.cgi?id=58033 --- Comment #8 from Chris Rankin --- Still broken as of git HEAD: commit ca39c0f94a4e3cc25b6cc9507fb729b85140733a Author: Ian Romanick Date: Wed Jan 16 15:34:49 2013 -0800 mesa/es3: Don't check dimensions in _mesa_es3_error_check_format_and_type -- 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 58033] [r300g] Black gap artifacts when playing WoW
https://bugs.freedesktop.org/show_bug.cgi?id=58033 --- Comment #9 from Marek Olšák --- Could you please attach a screenshot showing the issue? -- 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 58033] [r300g] Black gap artifacts when playing WoW
https://bugs.freedesktop.org/show_bug.cgi?id=58033 --- Comment #10 from Chris Rankin --- (In reply to comment #9) > Could you please attach a screenshot showing the issue? Sorry, the corruption is not showing up which I press the "Print Screen" button. I shall attempt to describe instead: Imagine moving towards a forest, with the trees in the centre of your screen. As you approach the forest, you expect the trees to get larger and appear to slide towards the left and right edges of your screen. (That's perfectly ordinary depth-perception). The corruption seems to be that nothing is immediately rendered where the trees used to be, leaving large black gaps. When you stop moving, the black gaps are quickly filled again. -- 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: mesa-8.0.x: Cherry-pick "dri/nouveau: don't use nested functions"
On 01/17/2013 02:14 PM, Sedat Dilek wrote: Hi I am playing again with llvm/clang v3.2 and patches I adapted from LLVMLinux project. I wanted to test my new toolchain before doing a rough testing of the mainline Linux-kernel. I decided to build the latest mesa-8.0.5 as I am on Ubuntu/precise AMD64 here by making me and my build-deps happy (so NO mesa-9.x as it requires a higher version of libdrm). Unfortunately, I hit the same problem Johannes Obermayr already described. Gratefully he points also in the BTS to the patch which is NOT in "8.0" mesa GIT branch! Thank you Johannes. Can someone cherry-pick this one? commit 4aa1ac5fe94b5696095229ee3568bf4fa7cfed95 "dri/nouveau: don't use nested functions" Done. -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: mesa-8.0.5: LLVM-3.2 patchset and request for cherry-picking
On 01/17/2013 04:23 PM, Sedat Dilek wrote: Hi, with the following patchset (13 patches) I was able to build mesa-8.0.5 with LLVM v3.2. There is one big fat patch called "gallivm,draw,llvmpipe: Support wider native registers." [1] which makes backporting hard. Jose? Regards, - Sedat - [1] http://cgit.freedesktop.org/mesa/mesa/commit/?id=3469715 P.S.: Patchset fixing build of mesa-8.0.5 with LLVM/CLANG v3.2 [ gallium-auxiliary-fixes-for-8-0-5 (PENDING) ] 4b7b71a rtti was removed from more llvm libraries. Thanks to d0k for the hint via IRC #llvm on irc.oftc.net For more details see [1] and followup [2] discussion (Thanks Johannes Obermayr again)! [1] http://lists.freedesktop.org/archives/mesa-dev/2012-October/029167.html [2] http://lists.freedesktop.org/archives/mesa-dev/2012-October/029184.html [ gallivm-fixes-for-8-0-5 (CHERRY-PICKED) ] 920a940 gallivm: Fix createOProfileJITEventListener namespace with llvm-3.1. d998daf gallivm: Add constructor for raw_debug_ostream. af1f68a gallivm: Add MCRegisterInfo.h to silence benign warnings about missing implementation. ad88aac gallivm: Pass in a MCInstrInfo to createMCInstPrinter on llvm-3.1. 395c791 gallivm: Fix method overriding in raw_debug_ostream. 557632f gallivm: Use InitializeNativeTargetDisassembler(). 6c0144a gallivm: Pass in a MCRegisterInfo to MCInstPrinter on llvm-3.1. 1bb5b0d gallivm: Initialize x86 disassembler on x86_64 too. 4d25e57 gallivm: Replace architecture test with PIPE_ARCH_* 192859a gallivm: Fix LLVM-2.7 build. 2dfd7e5 Initialize only native LLVM Disassembler. [ dri-nouveau-fixes-for-8-0-5 (CHERRY-PICKED) ] abd8713 dri/nouveau: don't use nested functions - EOT - Why are you using mesa 8.0.5? Wouldn't it be better to get into 9.x or master (aka 9.1)? -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #2 from Roland Scheidegger --- (In reply to comment #1) > So default command like > > glColorMaterial (GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE) > > never worked quite right on tcl. How did you arrive at this conclusion? You could try some things (like throwing out the dlist stuff) and see if that improves things. Or figure out if actually all of the subtests don't pass to narrow it down. -- 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 54133] [radeon][RV620] Resuming from suspend/hibernation randomly fails since kernel 3.5.0
https://bugs.freedesktop.org/show_bug.cgi?id=54133 --- Comment #6 from Ash --- I am using kernel 3.7.2-201.fc18.x86_64 (Fedora 18) and no libdrm_radeon and am also experiencing this problem. Problem not present in Fedora 17. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix a bogus kfree
parser->chunks[.].kpage[.] is not always kmalloc-ed
by the parser initialization, so parser_fini should
not try to kfree it if it didn't allocate it.
This patch fixes a kernel oops that can be provoked
in UMS mode.
Upstream commit-id: a6b7e1a02b77ab8fe8775d20a88c53d8ba55482e
Tested on stable 3.7
Signed-off-by: Ilija Hadzic
Signed-off-by: Alex Deucher
Signed-off-by: Shuah Khan
CC: sta...@vger.kernel.org 3.7
---
drivers/gpu/drm/radeon/r600_cs.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 03191a5..6858a40 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -2476,8 +2476,10 @@ static void r600_cs_parser_fini(struct radeon_cs_parser
*parser, int error)
kfree(parser->relocs);
for (i = 0; i < parser->nchunks; i++) {
kfree(parser->chunks[i].kdata);
- kfree(parser->chunks[i].kpage[0]);
- kfree(parser->chunks[i].kpage[1]);
+ if (parser->rdev && (parser->rdev->flags & RADEON_IS_AGP)) {
+ kfree(parser->chunks[i].kpage[0]);
+ kfree(parser->chunks[i].kpage[1]);
+ }
}
kfree(parser->chunks);
kfree(parser->chunks_array);
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
mesa-8.0.x: Cherry-pick "dri/nouveau: don't use nested functions"
Hi I am playing again with llvm/clang v3.2 and patches I adapted from LLVMLinux project. I wanted to test my new toolchain before doing a rough testing of the mainline Linux-kernel. I decided to build the latest mesa-8.0.5 as I am on Ubuntu/precise AMD64 here by making me and my build-deps happy (so NO mesa-9.x as it requires a higher version of libdrm). Unfortunately, I hit the same problem Johannes Obermayr already described. Gratefully he points also in the BTS to the patch which is NOT in "8.0" mesa GIT branch! Thank you Johannes. Can someone cherry-pick this one? commit 4aa1ac5fe94b5696095229ee3568bf4fa7cfed95 "dri/nouveau: don't use nested functions" Have fun! Regards, - Sedat - P.S.: I have hit another build-error while writing this email, grrr! [1] https://bugs.freedesktop.org/show_bug.cgi?id=44061 [2] http://cgit.freedesktop.org/mesa/mesa/patch/?id=4aa1ac5fe94b5696095229ee3568bf4fa7cfed95 [3] http://cgit.freedesktop.org/mesa/mesa/log/?h=8.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
mesa-8.0.5: LLVM-3.2 patchset and request for cherry-picking
Hi, with the following patchset (13 patches) I was able to build mesa-8.0.5 with LLVM v3.2. There is one big fat patch called "gallivm,draw,llvmpipe: Support wider native registers." [1] which makes backporting hard. Jose? Regards, - Sedat - [1] http://cgit.freedesktop.org/mesa/mesa/commit/?id=3469715 P.S.: Patchset fixing build of mesa-8.0.5 with LLVM/CLANG v3.2 [ gallium-auxiliary-fixes-for-8-0-5 (PENDING) ] 4b7b71a rtti was removed from more llvm libraries. Thanks to d0k for the hint via IRC #llvm on irc.oftc.net For more details see [1] and followup [2] discussion (Thanks Johannes Obermayr again)! [1] http://lists.freedesktop.org/archives/mesa-dev/2012-October/029167.html [2] http://lists.freedesktop.org/archives/mesa-dev/2012-October/029184.html [ gallivm-fixes-for-8-0-5 (CHERRY-PICKED) ] 920a940 gallivm: Fix createOProfileJITEventListener namespace with llvm-3.1. d998daf gallivm: Add constructor for raw_debug_ostream. af1f68a gallivm: Add MCRegisterInfo.h to silence benign warnings about missing implementation. ad88aac gallivm: Pass in a MCInstrInfo to createMCInstPrinter on llvm-3.1. 395c791 gallivm: Fix method overriding in raw_debug_ostream. 557632f gallivm: Use InitializeNativeTargetDisassembler(). 6c0144a gallivm: Pass in a MCRegisterInfo to MCInstPrinter on llvm-3.1. 1bb5b0d gallivm: Initialize x86 disassembler on x86_64 too. 4d25e57 gallivm: Replace architecture test with PIPE_ARCH_* 192859a gallivm: Fix LLVM-2.7 build. 2dfd7e5 Initialize only native LLVM Disassembler. [ dri-nouveau-fixes-for-8-0-5 (CHERRY-PICKED) ] abd8713 dri/nouveau: don't use nested functions - EOT - ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: mesa-8.0.5: LLVM-3.2 patchset and request for cherry-picking
On Fri, Jan 18, 2013 at 12:44 AM, Brian Paul wrote: > On 01/17/2013 04:23 PM, Sedat Dilek wrote: >> >> Hi, >> >> with the following patchset (13 patches) I was able to build >> mesa-8.0.5 with LLVM v3.2. >> >> There is one big fat patch called "gallivm,draw,llvmpipe: Support >> wider native registers." [1] which makes backporting hard. >> Jose? >> >> Regards, >> - Sedat - >> >> [1] http://cgit.freedesktop.org/mesa/mesa/commit/?id=3469715 >> >> P.S.: Patchset fixing build of mesa-8.0.5 with LLVM/CLANG v3.2 >> >> [ gallium-auxiliary-fixes-for-8-0-5 (PENDING) ] >> 4b7b71a rtti was removed from more llvm libraries. Thanks to d0k for >> the hint via IRC #llvm on irc.oftc.net >> >> For more details see [1] and followup [2] discussion (Thanks Johannes >> Obermayr again)! >> [1] >> http://lists.freedesktop.org/archives/mesa-dev/2012-October/029167.html >> [2] >> http://lists.freedesktop.org/archives/mesa-dev/2012-October/029184.html >> >> [ gallivm-fixes-for-8-0-5 (CHERRY-PICKED) ] >> 920a940 gallivm: Fix createOProfileJITEventListener namespace with >> llvm-3.1. >> d998daf gallivm: Add constructor for raw_debug_ostream. >> af1f68a gallivm: Add MCRegisterInfo.h to silence benign warnings about >> missing implementation. >> ad88aac gallivm: Pass in a MCInstrInfo to createMCInstPrinter on llvm-3.1. >> 395c791 gallivm: Fix method overriding in raw_debug_ostream. >> 557632f gallivm: Use InitializeNativeTargetDisassembler(). >> 6c0144a gallivm: Pass in a MCRegisterInfo to MCInstPrinter on llvm-3.1. >> 1bb5b0d gallivm: Initialize x86 disassembler on x86_64 too. >> 4d25e57 gallivm: Replace architecture test with PIPE_ARCH_* >> 192859a gallivm: Fix LLVM-2.7 build. >> 2dfd7e5 Initialize only native LLVM Disassembler. >> >> [ dri-nouveau-fixes-for-8-0-5 (CHERRY-PICKED) ] >> abd8713 dri/nouveau: don't use nested functions >> >> - EOT - > > > Why are you using mesa 8.0.5? Wouldn't it be better to get into 9.x or > master (aka 9.1)? > As pointed out in my other email, I am here on Ubuntu/precise AMD64 which runs mesa-8.0.x. The simplest way was to install the so-called build-deps and build mesa-8.0.5 after that. Switching to a higher mesa-version results here in circular build-dependencies. For example: mesa-9.x wants a higher libdrm-version and I don't know what libdrm requires for new build-deps to be resolved. Finally, I have to bump my complete Linux graphics stack - I wanted to avoid this! - Sedat - > -Brian > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #3 from smoki --- Created attachment 73222 --> https://bugs.freedesktop.org/attachment.cgi?id=73222&action=edit swtcl -- 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 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #4 from smoki --- Created attachment 73223 --> https://bugs.freedesktop.org/attachment.cgi?id=73223&action=edit swtcl -- 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 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #5 from smoki --- Created attachment 73224 --> https://bugs.freedesktop.org/attachment.cgi?id=73224&action=edit tcl -- 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 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #6 from smoki --- Created attachment 73226 --> https://bugs.freedesktop.org/attachment.cgi?id=73226&action=edit tcl -- 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 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #7 from smoki --- Supertuxkart game use irlicht engine and ECM_DIFFUSE_AND_AMBIENT command for the material color, which use vertex color for both diffuse and ambient light. That irlicht command is actualy glColorMaterial (GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE). mb->getMaterial().ColorMaterial = video::ECM_DIFFUSE_AND_AMBIENT; http://sourceforge.net/apps/trac/supertuxkart/browser/main/trunk/src/graphics/material_manager.cpp And i get this results (see attached pictures) when i use tcl or tcl_mode=0. It get correct lighting with swtcl and incorrect with tcl. -- 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 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 smoki changed: What|Removed |Added Attachment #73223|text/plain |image/png mime type|| -- 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 v2 2/5] drm/tegra: Add plane support
On 01/15/2013 06:50 PM, Lucas Stach wrote:
> Am Dienstag, den 15.01.2013, 17:53 +0800 schrieb Mark Zhang:
>> On 01/15/2013 12:05 AM, Thierry Reding wrote:
>>> Add support for the B and C planes which support RGB and YUV pixel
>>> formats and can be used as overlays or hardware cursor.
>>
>> I think "hardware cursor" has specific meaning for Tegra(e.g: Tegra30
>> has a 32x32 24bpp or 64x64 2bpp hardware cursor). So you may change it
>> to "hardware accelerated cursor"?
>>
> According to the TRM no Tegra has ARGB hardware cursor support, but only
> 2-color. So we talked about doing the hardware cursor by using a plane.
> If the TRM is wrong in this regard and we can get a ARGB cursor on Tegra
> 3 it would be nice to know.
>
Lucas, yes, TRM says "Hardware cursor is supported for 32x32 or for
64x64 2-bpp cursor.", but just as you can see, we can set cursor's
foreground & background color by register "DC_DISP_CURSOR_FOREGROUND_0
" & "DC_DISP_CURSOR_BACKGROUND_0".
So I asked the expert in nvidia and here is the explanation of the
hardware cursor:
"each pixel in the cursor is encoded by 2 bits.
only 3 values are used per pixel: transparent, foreground, background.
when pixel is transparent - no pixel is displayed. (also known as a mask)
when pixel is foreground - color of pixel is 24-bit value in
DC_DISP_CURSOR_FOREGROUND_0.
when pixel is background - color of pixel is 24-bit value in
DC_DISP_CURSOR_BACKGROUND_0.
So I would still phrase it as a 2-bit cursor. It's a palette with 2
colors plus a 1-bit alpha. The palette entries are 24-bit."
Mark
>>>
>>> Signed-off-by: Thierry Reding
>>> ---
>> [...]
>>> +};
>>> +
>>> +static int tegra_dc_add_planes(struct drm_device *drm, struct tegra_dc *dc)
>>> +{
>>> + unsigned int i;
>>> + int err = 0;
>>> +
>>> + for (i = 0; i < 2; i++) {
>>> + struct tegra_plane *plane;
>>> +
>>> + plane = devm_kzalloc(drm->dev, sizeof(*plane), GFP_KERNEL);
>>> + if (!plane)
>>> + return -ENOMEM;
>>> +
>>> + plane->index = i;
>>
>> I suggest to change this line to: "plane->index = i + 1;". This makes
>> the plane's index be consistent with Tegra's windows number. And also we
>> don't need to worry about passing "plane->index + 1" to some functions
>> which need to know which window is operating on.
>>
> Again, if we make WIN_C the root window, we can keep the plane index
> assignment as is and get rid of the "index + 1" passing.
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
clang: warning: argument unused during compilation: '-fno-builtin-memcmp'
Hi, I am playing with llvm/clang v3.2 and mesa. It's annoying to see these hundreds of warnings... clang: warning: argument unused during compilation: '-fno-builtin-memcmp' NOTE: '-fno-builtin-memcmp' is a gcc-specific compiler-flag. I have done here a brutal solution, maybe someone else has a more elegant one. Thanks. Regards, - Sedat - ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:drm-intel-nightly 150/152] include/uapi/drm/i915_drm.h:311:1: error: expected identifier or '(' before '<<' token
tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-nightly
head: bef8f38486aaeef0818d0b79c797b0d6bbb1ce06
commit: 3f43d56a721d4f2ed29218bb365edc7a2b5a7a25 [150/152] Merge
remote-tracking branch 'origin/drm-intel-fixes' into drm-intel-nightly
config: x86_64-allyesdebian (attached as .config)
All error/warnings:
In file included from include/drm/i915_drm.h:29:0,
from drivers/gpu/drm/i915/i915_drv.c:32:
>> include/uapi/drm/i915_drm.h:311:1: error: expected identifier or '(' before
>> '<<' token
>> include/uapi/drm/i915_drm.h:320:3: warning: data definition has no type or
>> storage class [enabled by default]
>> include/uapi/drm/i915_drm.h:320:3: warning: type defaults to 'int' in
>> declaration of 'drm_i915_getparam_t' [-Wimplicit-int]
In file included from include/drm/i915_drm.h:29:0,
from drivers/gpu/drm/i915/i915_drv.c:32:
include/uapi/drm/i915_drm.h:690:1: error: expected identifier or '(' before
'<<' token
--
In file included from include/drm/i915_drm.h:29:0,
from drivers/gpu/drm/i915/intel_drv.h:29,
from drivers/gpu/drm/i915/i915_dma.c:34:
>> include/uapi/drm/i915_drm.h:311:1: error: expected identifier or '(' before
>> '<<' token
>> include/uapi/drm/i915_drm.h:320:3: warning: data definition has no type or
>> storage class [enabled by default]
>> include/uapi/drm/i915_drm.h:320:3: warning: type defaults to 'int' in
>> declaration of 'drm_i915_getparam_t' [-Wimplicit-int]
In file included from include/drm/i915_drm.h:29:0,
from drivers/gpu/drm/i915/intel_drv.h:29,
from drivers/gpu/drm/i915/i915_dma.c:34:
include/uapi/drm/i915_drm.h:690:1: error: expected identifier or '(' before
'<<' token
drivers/gpu/drm/i915/i915_dma.c: In function 'i915_getparam':
>> drivers/gpu/drm/i915/i915_dma.c:916:23: error: 'param' undeclared (first use
>> in this function)
drivers/gpu/drm/i915/i915_dma.c:916:23: note: each undeclared identifier is
reported only once for each function it appears in
>> drivers/gpu/drm/i915/i915_dma.c:917:2: warning: ISO C90 forbids mixed
>> declarations and code [-Wdeclaration-after-statement]
>> drivers/gpu/drm/i915/i915_dma.c:992:1: error: expected expression before
>> '<<' token
drivers/gpu/drm/i915/i915_dma.c:997:1: error: expected expression before
'==' token
drivers/gpu/drm/i915/i915_dma.c: At top level:
>> drivers/gpu/drm/i915/i915_dma.c:1845:240: error: subscripted value is
>> neither array nor pointer nor vector
>> drivers/gpu/drm/i915/i915_dma.c:1859:204: error: invalid application of
>> 'sizeof' to incomplete type 'struct drm_i915_gem_pin'
>> drivers/gpu/drm/i915/i915_dma.c:1859:246: error: array type has incomplete
>> element type
drivers/gpu/drm/i915/i915_dma.c:1859:277: error: invalid application of
'sizeof' to incomplete type 'struct drm_i915_gem_pin'
drivers/gpu/drm/i915/i915_dma.c:1859:324: error: invalid application of
'sizeof' to incomplete type 'struct drm_i915_gem_pin'
--
In file included from include/drm/i915_drm.h:29:0,
from drivers/gpu/drm/i915/i915_gem.c:29:
>> include/uapi/drm/i915_drm.h:311:1: error: expected identifier or '(' before
>> '<<' token
>> include/uapi/drm/i915_drm.h:320:3: warning: data definition has no type or
>> storage class [enabled by default]
>> include/uapi/drm/i915_drm.h:320:3: warning: type defaults to 'int' in
>> declaration of 'drm_i915_getparam_t' [-Wimplicit-int]
In file included from include/drm/i915_drm.h:29:0,
from drivers/gpu/drm/i915/i915_gem.c:29:
include/uapi/drm/i915_drm.h:690:1: error: expected identifier or '(' before
'<<' token
drivers/gpu/drm/i915/i915_gem.c: In function 'i915_gem_pin_ioctl':
>> drivers/gpu/drm/i915/i915_gem.c:3492:115: error: dereferencing pointer to
>> incomplete type
drivers/gpu/drm/i915/i915_gem.c:3505:73: error: dereferencing pointer to
incomplete type
drivers/gpu/drm/i915/i915_gem.c:3512:38: error: dereferencing pointer to
incomplete type
drivers/gpu/drm/i915/i915_gem.c:3524:6: error: dereferencing pointer to
incomplete type
drivers/gpu/drm/i915/i915_gem.c: In function 'i915_gem_unpin_ioctl':
drivers/gpu/drm/i915/i915_gem.c:3544:115: error: dereferencing pointer to
incomplete type
drivers/gpu/drm/i915/i915_gem.c:3551:79: error: dereferencing pointer to
incomplete type
--
In file included from include/drm/i915_drm.h:29:0,
from drivers/gpu/drm/i915/i915_ioc32.c:35:
>> include/uapi/drm/i915_drm.h:311:1: error: expected identifier or '(' before
>> '<<' token
>> include/uapi/drm/i915_drm.h:320:3: warning: data definition has no type or
>> storage class [enabled by default]
>> include/uapi/drm/i915_drm.h:320:3: warning: type defaults to 'int' in
>> declaration of 'drm_i915_getparam_t' [-Wimplicit-int]
In file included from include/drm/i915_drm.h:29:0,
from drivers/gpu/drm/i915/i915_ioc32.c:35:
[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On 2013.01.16 at 17:36 -0500, Alex Deucher wrote: > On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf > wrote: > > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf wrote: > >> On 2013.01.15 at 16:26 +0100, Michel D?nzer wrote: > >> > On Die, 2013-01-15 at 16:23 +0100, Markus Trippelsdorf wrote: > >> > > On 2013.01.15 at 15:43 +0100, Michel D?nzer wrote: > >> > > > On Sam, 2013-01-05 at 11:41 +0100, Markus Trippelsdorf wrote: > >> > > > > On 2012.12.20 at 14:58 +0100, Markus Trippelsdorf wrote: > >> > > > > > > >> > > > > > And just in case it got lost in the noise yesterday: > >> > > > > > The image corruption is caused by Dave's commit: > >> > > > > > > >> > > > > > commit dd54fee7d440c4a9756cce2c24a50c15e4c17ccb > >> > > > > > Author: Dave Airlie > >> > > > > > Date: Fri Dec 14 21:04:46 2012 +1000 > >> > > > > > > >> > > > > > radeon: fix regression with eviction since evict caching > >> > > > > > changes > >> > > > > > > >> > > > > > Reverting it 'fixes' the issue. > >> > > > > > >> > > > > Ping. > >> > > > > The issue still happens with todays Linus git tree. > >> > > > > >> > > > Does the corruption also occur with > >> > > > dd54fee7d440c4a9756cce2c24a50c15e4c17ccb applied manually on top of > >> > > > 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d? > >> > > > >> > > No. > >> > > >> > So, can you bisect which change between those two actually introduced > >> > the corruption? > > > > The real cause of the image corruption is: > > > > d025e9e2b890db679f1246037bf65bd4be512627 is the first bad commit > > commit d025e9e2b890db679f1246037bf65bd4be512627 > > Author: Jerome Glisse > > Date: Thu Nov 29 10:35:41 2012 -0500 > > > > drm/radeon: do not move bo to different placement at each cs > > > > The bo creation placement is where the bo will be. Instead of trying > > to move bo at each command stream let this work to another worker > > thread that will use more advance heuristic. > > > > agd5f: remove leftover unused variable > > > > Signed-off-by: Jerome Glisse > > Reviewed-by: Alex Deucher > > > > Reverting d025e9e2b890d on top of Linus' tree fixes the issue. > > Can you try this patch from Jerome: > https://bugzilla.kernel.org/attachment.cgi?id=91421 It fixes the corruption, but it degrades performance so much that it takes several seconds to switch virtual desktops under xmonad. And sometimes the website used for the scroll test is stuck for several seconds and unscrollable during that time. -- Markus
[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot
https://bugs.freedesktop.org/show_bug.cgi?id=58659 --- Comment #14 from Bryan Quigley --- I tested with just this second patch and it did not help. Do you want me to test with both patches applied? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/37aa5577/attachment.html>
[Bug 52491] radeon massive screen corruption BARTS HD6870
https://bugzilla.kernel.org/show_bug.cgi?id=52491 J?r?me Glisse changed: What|Removed |Added CC||glisse at freedesktop.org --- Comment #14 from J?r?me Glisse 2013-01-17 00:20:44 --- Better to try this patch instead first : http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch -- 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 58667] Random crashes on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=58667 --- Comment #37 from Jerome Glisse --- This patch might help: http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/74c00f48/attachment.html>
[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot
https://bugs.freedesktop.org/show_bug.cgi?id=58659 --- Comment #15 from Jerome Glisse --- You sure you using the module with the patch ? You rebuilded your initrd and all ? Other user that pointed to same commit have the issue fixed by this patch. A better version of this patch is also at : http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/dc247a23/attachment.html>
[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot
https://bugs.freedesktop.org/show_bug.cgi?id=58659 --- Comment #16 from Bryan Quigley --- I'm building with https://wiki.ubuntu.com/KernelTeam/GitKernelBuild#Kernel_Build_and_Installation I'm running step 9 after doing git apply patch and then git commit. I'll try the latest patch. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/4317e866/attachment.html>
[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot
https://bugs.freedesktop.org/show_bug.cgi?id=58659
--- Comment #17 from Jerome Glisse ---
You also need step 12 of and please add :
printk(KERN_INFO "TITITOTOTUTUPOPO\n");
to
radeon_device.c line 992 after DRM_INFO("initializing ke
And when testing to make sure you are using the patched module dmesg | grep
TITITOTO
should tell you if it's the case.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/30d0e056/attachment-0001.html>
[Bug 59492] New: piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 Priority: medium Bug ID: 59492 Assignee: dri-devel at lists.freedesktop.org Summary: piglit dlist-color-material test fail Severity: normal Classification: Unclassified OS: All Reporter: smoki00790 at gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/DRI/r200 Product: Mesa Piglit test "dlist-color-material" not passed on rv280. That is essential thing, i even tried 7.5.2. and UMS, and no go. Acctualy it seems to me that never worked on tcl_mode=1. So yeah it works with swtcl, but never on tcl. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/b6961e8a/attachment.html>
[Bug 59492] piglit dlist-color-material test fail
https://bugs.freedesktop.org/show_bug.cgi?id=59492 --- Comment #1 from smoki --- So default command like glColorMaterial (GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE) never worked quite right on tcl. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/b74c59e7/attachment.html>
[Bug 59089] [bisected, regression] flood of GPU fault detected in logs caused by 9af20... drm/radeon: fix fence locking in the pageflip callback
https://bugs.freedesktop.org/show_bug.cgi?id=59089 --- Comment #8 from Alexandre Demers --- (In reply to comment #7) > I would consider it a flood, the message continually appears until glxgears > is exited. Can you confirm whether 3e163a137be7f9a80ec720903c4bda028de5681f > in mesa stops all of the GPU faults? If it does I will open another bug > report seeing as it may be different. Neither glxgears nor Heroes of Newerth produce GPU fault flood since applied fix in mesa. If you are still experiencing a flood when glxgears is running, I'm pretty sure it is not the same thing under the hood. Which makes me think: what kernel version are you using? Did you test with latest mesa version since fix was pushed in git? Which gpu do you have? I'm running latest kernel from Linus' git, latest mesa git and I'm using an HD 6950. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/a27371e9/attachment.html>
[Bug 59089] [bisected, regression] flood of GPU fault detected in logs caused by 9af20... drm/radeon: fix fence locking in the pageflip callback
https://bugs.freedesktop.org/show_bug.cgi?id=59089 --- Comment #9 from Anthony Waters --- Mesa is at latest git, however, my kernel wasn't at Linus' git, so that may be the issue, using HD 6950. I will try the newest kernel and if it doesn't work I'll create a new bug report. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/f4fc2342/attachment.html>
[Bug 59089] [bisected, regression] flood of GPU fault detected in logs caused by 9af20... drm/radeon: fix fence locking in the pageflip callback
https://bugs.freedesktop.org/show_bug.cgi?id=59089 --- Comment #10 from Alexandre Demers --- (In reply to comment #9) > Mesa is at latest git, however, my kernel wasn't at Linus' git, so that may > be the issue, using HD 6950. I will try the newest kernel and if it doesn't > work I'll create a new bug report. Ok, let me know. Meanwhile, I'll test something on my side to see if your bad commit could be related to another bug I'm experiencing with Tropics. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/785e88ea/attachment-0001.html>
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 --- Comment #21 from Alexandre Demers --- (In reply to comment #19) > (In reply to comment #18) > > Created attachment 72794 [details] [review] [review] > > possible fix > > > > Does this kernel patch help? > > No. I was able to catch something in errors.log and kernel.log though. I'm > attaching the truncated file in a few seconds. I hit a GPU fault. > > I'll do the same test without the patch to know if it is related or not. Just to let you know, it does the same thing either I apply the patch or not, even with today's latest kernel git. I just have to prepare to launch Tropics, connect through ssh from my tablet, launch Tropics and when it freezes, call dmesg from the tablet. Then, I'll have the GPU faults logged in my different log files. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/4cf8dfd4/attachment.html>
[PATCH v2 5/5] drm/tegra: Implement page-flipping support
On 01/16/2013 07:53 PM, Lucas Stach wrote: > Am Mittwoch, den 16.01.2013, 19:10 +0800 schrieb Mark Zhang: >> I'm testing the pageflip & vblank change on cardhu. Seems the HDMI >> doesn't work(LVDS only is OK). I'll let you know if I get something. >> > Just to provide another data point: I'm running this series and don't > see any failures with DVI output. Though I'm only run a single output, > not some dual-head config. > Yes. HDMI only is OK. I met some problems when the LVDS & HDMI are enabled at the same time. Mark > Even vbltest from libdrm/tests works and shows correct refresh rate. > > Regards, > Lucas >
[Bug 59089] [bisected, regression] flood of GPU fault detected in logs caused by 9af20... drm/radeon: fix fence locking in the pageflip callback
https://bugs.freedesktop.org/show_bug.cgi?id=59089 --- Comment #11 from Alexandre Demers --- (In reply to comment #9) > Mesa is at latest git, however, my kernel wasn't at Linus' git, so that may > be the issue, using HD 6950. I will try the newest kernel and if it doesn't > work I'll create a new bug report. Also, you could see if updating libdrm and/or ddx driver could help, there were some commits for both of them in the last couple of weeks. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/4d08701d/attachment.html>
[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot
https://bugs.freedesktop.org/show_bug.cgi?id=58659 --- Comment #18 from Bryan Quigley --- I didn't need to do step 12 to get the TITITOTO message printed. I did what I've been doing all along. (I'm also trying to update the GitKernelBuild page as I go) If the message was printed that means it was loaded correctly, right? The better version of the patch (drm-radeon-exclude-system-placement-when-validating) was tested and it still didn't work. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/0a72a81e/attachment.html>
[PATCH v2 3/5] drm/tegra: Implement .mode_set_base()
On 01/15/2013 12:05 AM, Thierry Reding wrote:
> The sequence for replacing the scanout buffer is much shorter than a
> full mode change operation so implementing this callback considerably
> speeds up cases where only a new framebuffer is to be scanned out.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/tegra/dc.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index 157e962..8dd7d8a 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -116,6 +116,25 @@ static int tegra_dc_add_planes(struct drm_device *drm,
> struct tegra_dc *dc)
> return 0;
> }
>
> +static int tegra_dc_set_base(struct tegra_dc *dc, int x, int y,
> + struct tegra_framebuffer *fb)
> +{
> + unsigned long value;
> +
> + tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);
> +
> + value = fb->base.offsets[0] + y * fb->base.pitches[0] +
> + x * fb->base.bits_per_pixel / 8;
> +
> + tegra_dc_writel(dc, fb->obj->paddr + value, DC_WINBUF_START_ADDR);
> +
Add one line here:
tegra_dc_writel(dc, fb->base.pitches[0], DC_WIN_LINE_STRIDE);
I mentioned in previous mail that the page-flip doesn't work well while
multiple heads attached(in my test case, LVDS & HDMI are enabled). And I
found out that this is because we didn't update the line stride
according to the new FB.
But ideally, I think we don't need to update the line stride setting.
The reason that we need it here is: We set a "incorrect" line stride
intentionally when multiple-head is enabled.
I use a Tegra30 cardhu board for testing. The LVDS panel works on
1366x768 while the resolution of the HDMI is 1080p. The size of the FB
created during KMS is 1080p. To make the LVDS & HDMI show correct, we
set the dc0's(connected with LVDS) line stride to 7680(1920x4). So the
final result is, the LVDS panel shows the (0,0)/(1366,768) portion in a
1080p FB.
But the video mode of the LVDS which reported to user space is still
1366x768. So the userspace program creates 2 FBs based on that and ask
drm driver to flip them. So we need to update the line stride here.
Actually, I think we need to find a better solution when multi-head is
enabled. For example, create a large FB and make two dcs display the
different part of it(just like the XRANDR's extension mode). Or maybe we
can take a look at other drm drivers for inspiration.
Mark
> + value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
> + value |= GENERAL_UPDATE | WIN_A_UPDATE;
> + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
> +
> + return 0;
> +}
> +
> static const struct drm_crtc_funcs tegra_crtc_funcs = {
> .set_config = drm_crtc_helper_set_config,
> .destroy = drm_crtc_cleanup,
> @@ -404,6 +423,15 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
> return 0;
> }
>
> +static int tegra_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
> + struct drm_framebuffer *old_fb)
> +{
> + struct tegra_framebuffer *fb = to_tegra_fb(crtc->fb);
> + struct tegra_dc *dc = to_tegra_dc(crtc);
> +
> + return tegra_dc_set_base(dc, x, y, fb);
> +}
> +
> static void tegra_crtc_prepare(struct drm_crtc *crtc)
> {
> struct tegra_dc *dc = to_tegra_dc(crtc);
> @@ -483,6 +511,7 @@ static const struct drm_crtc_helper_funcs
> tegra_crtc_helper_funcs = {
> .dpms = tegra_crtc_dpms,
> .mode_fixup = tegra_crtc_mode_fixup,
> .mode_set = tegra_crtc_mode_set,
> + .mode_set_base = tegra_crtc_mode_set_base,
> .prepare = tegra_crtc_prepare,
> .commit = tegra_crtc_commit,
> .load_lut = tegra_crtc_load_lut,
>
[PATCH v2 5/5] drm/tegra: Implement page-flipping support
On 01/15/2013 12:06 AM, Thierry Reding wrote:
> All the necessary support bits like .mode_set_base() and VBLANK are now
> available, so page-flipping case easily be implemented on top.
>
> Signed-off-by: Thierry Reding
[...]
> +
> +static int tegra_dc_page_flip(struct drm_crtc *crtc, struct drm_framebuffer
> *fb,
> + struct drm_pending_vblank_event *event)
> +{
> + struct tegra_framebuffer *newfb = to_tegra_fb(fb);
> + struct tegra_dc *dc = to_tegra_dc(crtc);
> + struct drm_device *drm = crtc->dev;
> + unsigned long flags;
> +
> + if (dc->event)
> + return -EBUSY;
> +
> + tegra_dc_set_base(dc, 0, 0, newfb);
"tegra_dc_set_base" only updates the frame buffer start address to dc
registers. I think this is not enough because it's possible that this
new FB may trigger a full modeset while not just a fb change. For
example, the "bpp" of the new FB differs from current setting in dc
register.
So I suggest to trigger a full modeset here(although it's slower than fb
change) or maybe you can explain why the FB change is enough.
Mark
> +
> + if (event) {
> + event->pipe = dc->pipe;
> +
> + spin_lock_irqsave(&drm->event_lock, flags);
> + dc->event = event;
> + spin_unlock_irqrestore(&drm->event_lock, flags);
> +
> + drm_vblank_get(drm, dc->pipe);
> + }
> +
> + return 0;
> +}
> +
[...]
> struct tegra_output_ops {
> int (*enable)(struct tegra_output *output);
>
[PATCH v3 1/3] drm: add prime helpers
On Thu, Jan 17, 2013 at 12:36 AM, Aaron Plattner wrote: > Can I consider this a Reviewed-by? Essentially it was just a drive-by bikeshed ;-) I think it'd be good if Maarten takes a look at this and checks whether it complies with his massive prime/dma_buf rework to use fences and ticketing reservations ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
CDF discussions at FOSDEM
On Fri, 11 Jan 2013, Laurent Pinchart wrote: > Would anyone be interested in meeting at the FOSDEM to discuss the Common > Display Framework ? There will be a CDF meeting at the ELC at the end of > February, the FOSDEM would be a good venue for European developers. Yes, count me in, Jani.
[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: > On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf > wrote: > > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote: > >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf > >> wrote: > >> > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf wrote: > >> >> On 2013.01.15 at 16:26 +0100, Michel D?nzer wrote: > >> >> > On Die, 2013-01-15 at 16:23 +0100, Markus Trippelsdorf wrote: > >> >> > > On 2013.01.15 at 15:43 +0100, Michel D?nzer wrote: > >> >> > > > On Sam, 2013-01-05 at 11:41 +0100, Markus Trippelsdorf wrote: > >> >> > > > > On 2012.12.20 at 14:58 +0100, Markus Trippelsdorf wrote: > >> >> > > > > > > >> >> > > > > > And just in case it got lost in the noise yesterday: > >> >> > > > > > The image corruption is caused by Dave's commit: > >> >> > > > > > > >> >> > > > > > commit dd54fee7d440c4a9756cce2c24a50c15e4c17ccb > >> >> > > > > > Author: Dave Airlie > >> >> > > > > > Date: Fri Dec 14 21:04:46 2012 +1000 > >> >> > > > > > > >> >> > > > > > radeon: fix regression with eviction since evict caching > >> >> > > > > > changes > >> >> > > > > > > >> >> > > > > > Reverting it 'fixes' the issue. > >> >> > > > > > >> >> > > > > Ping. > >> >> > > > > The issue still happens with todays Linus git tree. > >> >> > > > > >> >> > > > Does the corruption also occur with > >> >> > > > dd54fee7d440c4a9756cce2c24a50c15e4c17ccb applied manually on top > >> >> > > > of > >> >> > > > 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d? > >> >> > > > >> >> > > No. > >> >> > > >> >> > So, can you bisect which change between those two actually introduced > >> >> > the corruption? > >> > > >> > The real cause of the image corruption is: > >> > > >> > d025e9e2b890db679f1246037bf65bd4be512627 is the first bad commit > >> > commit d025e9e2b890db679f1246037bf65bd4be512627 > >> > Author: Jerome Glisse > >> > Date: Thu Nov 29 10:35:41 2012 -0500 > >> > > >> > drm/radeon: do not move bo to different placement at each cs > >> > > >> > The bo creation placement is where the bo will be. Instead of trying > >> > to move bo at each command stream let this work to another worker > >> > thread that will use more advance heuristic. > >> > > >> > agd5f: remove leftover unused variable > >> > > >> > Signed-off-by: Jerome Glisse > >> > Reviewed-by: Alex Deucher > >> > > >> > Reverting d025e9e2b890d on top of Linus' tree fixes the issue. > >> > >> Can you try this patch from Jerome: > >> https://bugzilla.kernel.org/attachment.cgi?id=91421 > > > > It fixes the corruption, but it degrades performance so much that it > > takes several seconds to switch virtual desktops under xmonad. And > > sometimes the website used for the scroll test is stuck for several > > seconds and unscrollable during that time. > > > > -- > > Markus > > What about this patch instead : > http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch This one doesn't work: Jan 17 09:40:53 x4 kernel: radeon :01:05.0: GPU lockup CP stall for more than 1msec Jan 17 09:40:53 x4 kernel: radeon :01:05.0: GPU lockup (waiting for 0x0a63 last fence id 0x0a62) Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 0
[Intel-gfx] [PATCH 3/4] drm/edid: Add drm_rgb_quant_range_selectable()
Hi
2013/1/16 :
> From: Ville Syrj?l?
>
> drm_rgb_quant_range_selectable() will report whether the monitor
> claims to support for RGB quantization range selection.
>
> The information can be found in the CEA Video capability block.
Looks correct (checked against the spec, did not really test).
Reviewed-by: Paulo Zanoni
See below for optional bikeshedding:
>
> Signed-off-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/drm_edid.c | 33 +
> include/drm/drm_crtc.h |1 +
> 2 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 5a3770f..deba722 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1483,9 +1483,11 @@ add_detailed_modes(struct drm_connector *connector,
> struct edid *edid,
> #define VIDEO_BLOCK 0x02
> #define VENDOR_BLOCK0x03
> #define SPEAKER_BLOCK 0x04
> +#define VIDEO_CAPABILITY_BLOCK 0x07
> #define EDID_BASIC_AUDIO (1 << 6)
> #define EDID_CEA_YCRCB444 (1 << 5)
> #define EDID_CEA_YCRCB422 (1 << 4)
> +#define EDID_CEA_VCDB_QS (1 << 6)
>
> /**
> * Search EDID for CEA extension block.
> @@ -1902,6 +1904,37 @@ end:
> EXPORT_SYMBOL(drm_detect_monitor_audio);
>
> /**
> + * drm_rgb_quant_range_selectable - is RGB quantization range selectable?
> + *
> + * Check whether the monitor reports the RGB quantization range selection
> + * as supported. The AVI infoframe can then be used to inform the monitor
> + * which quantzation range (full or limited) is used.
s/quantzation/quantization/
> + */
> +bool drm_rgb_quant_range_selectable(struct edid *edid)
> +{
> + u8 *edid_ext;
> + int i, start, end;
> +
> + edid_ext = drm_find_cea_extension(edid);
> + if (!edid_ext)
> + return false;
> +
> + if (cea_db_offsets(edid_ext, &start, &end))
> + return false;
> +
> + for_each_cea_db(edid_ext, i, start, end) {
> + if (cea_db_tag(&edid_ext[i]) == VIDEO_CAPABILITY_BLOCK &&
> + cea_db_payload_len(&edid_ext[i]) == 2) {
> + DRM_DEBUG_KMS("CEA VCDB 0x%02x\n", edid_ext[i + 2]);
> + return edid_ext[i + 2] & EDID_CEA_VCDB_QS;
> + }
> + }
> +
> + return false;
> +}
> +EXPORT_SYMBOL(drm_rgb_quant_range_selectable);
> +
> +/**
> * drm_add_display_info - pull display info out if present
> * @edid: EDID data
> * @info: display info (attached to connector)
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 00d78b5..30892dc 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1033,6 +1033,7 @@ extern u8 *drm_find_cea_extension(struct edid *edid);
> extern u8 drm_match_cea_mode(struct drm_display_mode *to_match);
> extern bool drm_detect_hdmi_monitor(struct edid *edid);
> extern bool drm_detect_monitor_audio(struct edid *edid);
> +extern bool drm_rgb_quant_range_selectable(struct edid *edid);
> extern int drm_mode_page_flip_ioctl(struct drm_device *dev,
> void *data, struct drm_file *file_priv);
> extern struct drm_display_mode *drm_cvt_mode(struct drm_device *dev,
> --
> 1.7.8.6
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
[PATCH 4/4] drm/i915: Provide the quantization range in the AVI infoframe
Hi
2013/1/16 :
> From: Ville Syrj?l?
>
> The AVI infoframe is able to inform the display whether the source is
> sending full or limited range RGB data.
>
> As per CEA-861 we must first check whether the display reports the
> quantization range as selectable, and if so we can set the approriate
> bits in the AVI inforframe.
>
> Signed-off-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/i915/intel_drv.h |3 +++
> drivers/gpu/drm/i915/intel_hdmi.c | 11 +++
> drivers/gpu/drm/i915/intel_sdvo.c | 16 ++--
> 3 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 1a698c6..c5251d9 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -289,6 +289,8 @@ struct cxsr_latency {
> #define DIP_LEN_AVI 13
> #define DIP_AVI_PR_10
> #define DIP_AVI_PR_21
> +#define DIP_AVI_Q0 0x4
> +#define DIP_AVI_Q1 0x8
I'd define more descriptive names here... How about the following?
#define DIP_AVI_QUANTIZATION_DEFAULT (0 << 2)
#define DIP_AVI_QUANTIZATION_LIMITED (1 << 2)
#define DIP_AVI_QUANTIZATION_FULL (2 << 2)
Everything else looks fine.
With or without that:
Reviewed-by: Paulo Zanoni
Also, these things kinda conflict with Thierry's patches, but I know
you're aware because you've reviewed some of them :)
>
> #define DIP_TYPE_SPD 0x83
> #define DIP_VERSION_SPD0x1
> @@ -347,6 +349,7 @@ struct intel_hdmi {
> bool has_hdmi_sink;
> bool has_audio;
> enum hdmi_force_audio force_audio;
> + bool rgb_quant_range_selectable;
> void (*write_infoframe)(struct drm_encoder *encoder,
> struct dip_infoframe *frame);
> void (*set_infoframes)(struct drm_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 58b072e..270d7ee 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -331,6 +331,7 @@ static void intel_set_infoframe(struct drm_encoder
> *encoder,
> static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
> struct drm_display_mode
> *adjusted_mode)
> {
> + struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> struct dip_infoframe avi_if = {
> .type = DIP_TYPE_AVI,
> .ver = DIP_VERSION_AVI,
> @@ -340,6 +341,13 @@ static void intel_hdmi_set_avi_infoframe(struct
> drm_encoder *encoder,
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
> avi_if.body.avi.YQ_CN_PR |= DIP_AVI_PR_2;
>
> + if (intel_hdmi->rgb_quant_range_selectable) {
> + if (adjusted_mode->private_flags &
> INTEL_MODE_LIMITED_COLOR_RANGE)
> + avi_if.body.avi.ITC_EC_Q_SC |= DIP_AVI_Q0;
> + else
> + avi_if.body.avi.ITC_EC_Q_SC |= DIP_AVI_Q1;
> + }
> +
> avi_if.body.avi.VIC = drm_mode_cea_vic(adjusted_mode);
>
> intel_set_infoframe(encoder, &avi_if);
> @@ -825,6 +833,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
>
> intel_hdmi->has_hdmi_sink = false;
> intel_hdmi->has_audio = false;
> + intel_hdmi->rgb_quant_range_selectable = false;
> edid = drm_get_edid(connector,
> intel_gmbus_get_adapter(dev_priv,
> intel_hdmi->ddc_bus));
> @@ -836,6 +845,8 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
> intel_hdmi->has_hdmi_sink =
> drm_detect_hdmi_monitor(edid);
> intel_hdmi->has_audio =
> drm_detect_monitor_audio(edid);
> + intel_hdmi->rgb_quant_range_selectable =
> + drm_rgb_quant_range_selectable(edid);
> }
> kfree(edid);
> }
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index b422109..af93999 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -126,6 +126,7 @@ struct intel_sdvo {
> bool is_hdmi;
> bool has_hdmi_monitor;
> bool has_hdmi_audio;
> + bool rgb_quant_range_selectable;
>
> /**
> * This is set if we detect output of sdvo device as LVDS and
> @@ -947,7 +948,8 @@ static bool intel_sdvo_write_infoframe(struct intel_sdvo
> *intel_sdvo,
> &tx_rate, 1);
> }
>
> -static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo)
> +static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo,
> +const struct drm_display_mode
> *adjusted_mode)
> {
> struct dip_infoframe avi_if = {
>
CDF discussions at FOSDEM
On Thu, Jan 17, 2013 at 9:42 AM, Jani Nikula wrote: > On Fri, 11 Jan 2013, Laurent Pinchart > wrote: >> Would anyone be interested in meeting at the FOSDEM to discuss the Common >> Display Framework ? There will be a CDF meeting at the ELC at the end of >> February, the FOSDEM would be a good venue for European developers. > > Yes, count me in, Jesse, Ville and me should also be around. Do we have a slot fixed already? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 4/4] drm/i915: Provide the quantization range in the AVI infoframe
On Thu, Jan 17, 2013 at 10:16:46AM -0200, Paulo Zanoni wrote:
> Hi
>
> 2013/1/16 :
> > From: Ville Syrj?l?
> >
> > The AVI infoframe is able to inform the display whether the source is
> > sending full or limited range RGB data.
> >
> > As per CEA-861 we must first check whether the display reports the
> > quantization range as selectable, and if so we can set the approriate
> > bits in the AVI inforframe.
> >
> > Signed-off-by: Ville Syrj?l?
> > ---
> > drivers/gpu/drm/i915/intel_drv.h |3 +++
> > drivers/gpu/drm/i915/intel_hdmi.c | 11 +++
> > drivers/gpu/drm/i915/intel_sdvo.c | 16 ++--
> > 3 files changed, 28 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 1a698c6..c5251d9 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -289,6 +289,8 @@ struct cxsr_latency {
> > #define DIP_LEN_AVI 13
> > #define DIP_AVI_PR_10
> > #define DIP_AVI_PR_21
> > +#define DIP_AVI_Q0 0x4
> > +#define DIP_AVI_Q1 0x8
>
>
>
> I'd define more descriptive names here... How about the following?
> #define DIP_AVI_QUANTIZATION_DEFAULT (0 << 2)
> #define DIP_AVI_QUANTIZATION_LIMITED (1 << 2)
> #define DIP_AVI_QUANTIZATION_FULL (2 << 2)
Sure, that seems like sensible idea. I think I'll want the fact that
these only refer to RGB to be included in the name though.
So something like this probably:
DIP_AVI_RGB_QUANT_RANGE_DEFAULT
DIP_AVI_RGB_QUANT_RANGE_LIMITED
DIP_AVI_RGB_QUANT_RANGE_FULL
>
>
> Everything else looks fine.
>
> With or without that:
> Reviewed-by: Paulo Zanoni
>
> Also, these things kinda conflict with Thierry's patches, but I know
> you're aware because you've reviewed some of them :)
Yeah. BTW are we (as in i915 folks) mostly OK with those?
> > #define DIP_TYPE_SPD 0x83
> > #define DIP_VERSION_SPD0x1
> > @@ -347,6 +349,7 @@ struct intel_hdmi {
> > bool has_hdmi_sink;
> > bool has_audio;
> > enum hdmi_force_audio force_audio;
> > + bool rgb_quant_range_selectable;
> > void (*write_infoframe)(struct drm_encoder *encoder,
> > struct dip_infoframe *frame);
> > void (*set_infoframes)(struct drm_encoder *encoder,
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 58b072e..270d7ee 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -331,6 +331,7 @@ static void intel_set_infoframe(struct drm_encoder
> > *encoder,
> > static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
> > struct drm_display_mode
> > *adjusted_mode)
> > {
> > + struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> > struct dip_infoframe avi_if = {
> > .type = DIP_TYPE_AVI,
> > .ver = DIP_VERSION_AVI,
> > @@ -340,6 +341,13 @@ static void intel_hdmi_set_avi_infoframe(struct
> > drm_encoder *encoder,
> > if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
> > avi_if.body.avi.YQ_CN_PR |= DIP_AVI_PR_2;
> >
> > + if (intel_hdmi->rgb_quant_range_selectable) {
> > + if (adjusted_mode->private_flags &
> > INTEL_MODE_LIMITED_COLOR_RANGE)
> > + avi_if.body.avi.ITC_EC_Q_SC |= DIP_AVI_Q0;
> > + else
> > + avi_if.body.avi.ITC_EC_Q_SC |= DIP_AVI_Q1;
> > + }
> > +
> > avi_if.body.avi.VIC = drm_mode_cea_vic(adjusted_mode);
> >
> > intel_set_infoframe(encoder, &avi_if);
> > @@ -825,6 +833,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> > force)
> >
> > intel_hdmi->has_hdmi_sink = false;
> > intel_hdmi->has_audio = false;
> > + intel_hdmi->rgb_quant_range_selectable = false;
> > edid = drm_get_edid(connector,
> > intel_gmbus_get_adapter(dev_priv,
> > intel_hdmi->ddc_bus));
> > @@ -836,6 +845,8 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> > force)
> > intel_hdmi->has_hdmi_sink =
> >
> > drm_detect_hdmi_monitor(edid);
> > intel_hdmi->has_audio =
> > drm_detect_monitor_audio(edid);
> > + intel_hdmi->rgb_quant_range_selectable =
> > + drm_rgb_quant_range_selectable(edid);
> > }
> > kfree(edid);
> > }
> > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> > b/drivers/gpu/drm/i915/intel_sdvo.c
> > index b422109..af93999 100644
> > --- a/drivers/gpu/drm/i915/intel_sdvo.c
> > +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> > @@ -126,6 +126,7 @@ struct intel_sdvo {
> > bool is_hdmi;
> > bool has_hdmi_monitor;
> > b
[Intel-gfx] [PATCH 1/4] drm/i915: Fix RGB color range property for PCH platforms
Hi
2013/1/16 :
> From: Ville Syrj?l?
>
> The RGB color range select bit on the DP/SDVO/HDMI registers
> disappeared when PCH was introduced, and instead a new PIPECONF bit
> was added that performs the same function.
>
> Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
> it in the encoder mode_fixup if limited color range is requested.
> Set the the PIPECONF bit 13 based on the flag.
>
> Experimentation showed that simply toggling the bit while the pipe is
> active doesn't work. We need to restart the pipe, which luckily already
> happens.
>
> The DP/SDVO/HDMI bit 8 is marked MBZ in the docs, so avoid setting it,
> although it doesn't seem to do any harm in practice.
>
> TODO:
> - the PIPECONF bit too seems to have disappeared from HSW. Need a
> volunteer to test if it's just a documentation issue or if it's really
> gone. If the bit is gone and no easy replacement is found, then I suppose
> we may need to use the pipe CSC unit to perform the range compression.
>
> v2: Use mode private_flags instead of intel_encoder virtual functions
> v3: Moved the intel_dp color_range handling after bpc check to help
> later patches
Things look correct. As you mention, the only problem seems to be the
Haswell. I could not find anything on the specs, so I think we should
send some emails and maybe consider removing the property on Haswell?
If-you-promise-to-find-a-solution-for-the-Haswell-case:
Reviewed-by: Paulo Zanoni
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46800
> Signed-off-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/i915/i915_reg.h |1 +
> drivers/gpu/drm/i915/intel_display.c |5 +
> drivers/gpu/drm/i915/intel_dp.c |7 ++-
> drivers/gpu/drm/i915/intel_drv.h |5 +
> drivers/gpu/drm/i915/intel_hdmi.c|5 +
> drivers/gpu/drm/i915/intel_sdvo.c|5 -
> 6 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 36789bf..a2550c5 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2652,6 +2652,7 @@
> #define PIPECONF_INTERLACED_DBL_ILK (4 << 21) /* ilk/snb only */
> #define PIPECONF_PFIT_PF_INTERLACED_DBL_ILK (5 << 21) /* ilk/snb only */
> #define PIPECONF_CXSR_DOWNCLOCK (1<<16)
> +#define PIPECONF_COLOR_RANGE_SELECT (1 << 13)
> #define PIPECONF_BPC_MASK(0x7 << 5)
> #define PIPECONF_8BPC(0<<5)
> #define PIPECONF_10BPC (1<<5)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index c7313f8..f48f698 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5097,6 +5097,11 @@ static void ironlake_set_pipeconf(struct drm_crtc
> *crtc,
> else
> val |= PIPECONF_PROGRESSIVE;
>
> + if (adjusted_mode->private_flags & INTEL_MODE_LIMITED_COLOR_RANGE)
> + val |= PIPECONF_COLOR_RANGE_SELECT;
> + else
> + val &= ~PIPECONF_COLOR_RANGE_SELECT;
> +
> I915_WRITE(PIPECONF(pipe), val);
> POSTING_READ(PIPECONF(pipe));
> }
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index cf25481..64824d0 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -763,6 +763,10 @@ intel_dp_mode_fixup(struct drm_encoder *encoder,
> return false;
>
> bpp = adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 :
> 24;
> +
> + if (intel_dp->color_range)
> + adjusted_mode->private_flags |=
> INTEL_MODE_LIMITED_COLOR_RANGE;
> +
> mode_rate = intel_dp_link_required(adjusted_mode->clock, bpp);
>
> for (clock = 0; clock <= max_clock; clock++) {
> @@ -967,7 +971,8 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct
> drm_display_mode *mode,
> else
> intel_dp->DP |= DP_PLL_FREQ_270MHZ;
> } else if (!HAS_PCH_CPT(dev) || is_cpu_edp(intel_dp)) {
> - intel_dp->DP |= intel_dp->color_range;
> + if (!HAS_PCH_SPLIT(dev))
> + intel_dp->DP |= intel_dp->color_range;
>
> if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
> intel_dp->DP |= DP_SYNC_HS_HIGH;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 54a034c..4df47be 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -109,6 +109,11 @@
> * timings in the mode to prevent the crtc fixup from overwriting them.
> * Currently only lvds needs that. */
> #define INTEL_MODE_CRTC_TIMINGS_SET (0x20)
> +/*
> + * Set when limited 16-235 (as opposed to full 0-255) RGB color range is
> + * to be used.
> + */
> +#define INTEL_MODE_LIMITED_COLOR_RANGE (0x40)
>
> static inline void
> intel_mode_set_pixel_multipli
[PATCH] drm/nouveau/mc: complain loudly if we can't call a interrupt handler
I noticed that bsp, vp and ppp had no interrupt handler after investigating why
15% of my cpu time went to interrupts.
nouveau was silent about it, but it should be an error since we have no way of
acking in that case.
Signed-off-by: Maarten Lankhorst
---
fwiw, the interrupt was 10, the exit interrupt after secret scrubber finishes..
I have absolutely no idea why, as it times out on wait before the engine
initialization..
Maybe just ack it from the bsp/vp/ppp interrupt handler? Or should it be part
of the base fuc class..
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index 8379aaf..16bf49c 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -36,8 +36,16 @@ nouveau_mc_intr(struct nouveau_subdev *subdev)
while (stat && map->stat) {
if (stat & map->stat) {
unit = nouveau_subdev(subdev, map->unit);
- if (unit && unit->intr)
- unit->intr(unit);
+ if (unit) {
+ if (unit->intr)
+ unit->intr(unit);
+ else if (printk_ratelimit())
+ nv_error(pmc,
+"%s has no interrupt handler,
ignoring interrupt %x\n",
+unit->name, intr & map->stat);
+ } else if (printk_ratelimit())
+ nv_error(pmc, "subdev %u does not exist for
interrupt %x\n",
+map->unit, intr & map->stat);
intr &= ~map->stat;
}
map++;
[PATCH 2/4] drm/i915: Add "Automatic" mode for the "Broadcast RGB" property
Hi
2013/1/16 :
> From: Ville Syrj?l?
>
> Add a new "Automatic" mode to the "Broadcast RGB" range property.
> When selected the driver automagically selects between full range and
> limited range output.
>
> Based on CEA-861 guidelines, limited range output is selected if the
> mode is a CEA mode, except 640x480. Otherwise full range output is used.
> Additionally DVI monitors should most likely default to full range
> always.
>
> As per DP1.2a DisplayPort should always use full range for 18bpp, and
> otherwise will follow CEA-861 rules.
>
> NOTE: The default value for the property will now be "Automatic"
> so some people may be affected in case they're relying on the
> current full range default.
>
> v2: Use has_hdmi_sink to check if a HDMI monitor is present
Looks correct. And let's hope this patches fixes even more "my screen
is black" or "my screen has weird colors" bugs.
Reviewed-by: Paulo Zanoni
>
> Signed-off-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/i915/i915_drv.h|4 +++
> drivers/gpu/drm/i915/intel_dp.c| 28 ++---
> drivers/gpu/drm/i915/intel_drv.h |2 +
> drivers/gpu/drm/i915/intel_hdmi.c | 29 +++---
> drivers/gpu/drm/i915/intel_modes.c |5 ++-
> drivers/gpu/drm/i915/intel_sdvo.c | 38 +--
> 6 files changed, 89 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d0f051b..449bbe0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1803,5 +1803,9 @@ __i915_write(64, q)
> #define POSTING_READ(reg) (void)I915_READ_NOTRACE(reg)
> #define POSTING_READ16(reg)(void)I915_READ16_NOTRACE(reg)
>
> +/* "Broadcast RGB" property */
> +#define INTEL_BROADCAST_RGB_AUTO 0
> +#define INTEL_BROADCAST_RGB_FULL 1
> +#define INTEL_BROADCAST_RGB_LIMITED 2
>
> #endif
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 64824d0..633a4db 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -764,6 +764,14 @@ intel_dp_mode_fixup(struct drm_encoder *encoder,
>
> bpp = adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 :
> 24;
>
> + if (intel_dp->color_range_auto) {
> + /* as per DP1.2a and CEA-861 */
> + if (bpp != 18 && drm_mode_cea_vic(adjusted_mode) > 1)
> + intel_dp->color_range = DP_COLOR_RANGE_16_235;
> + else
> + intel_dp->color_range = 0;
> + }
> +
> if (intel_dp->color_range)
> adjusted_mode->private_flags |=
> INTEL_MODE_LIMITED_COLOR_RANGE;
>
> @@ -2462,10 +2470,21 @@ intel_dp_set_property(struct drm_connector *connector,
> }
>
> if (property == dev_priv->broadcast_rgb_property) {
> - if (val == !!intel_dp->color_range)
> - return 0;
> -
> - intel_dp->color_range = val ? DP_COLOR_RANGE_16_235 : 0;
> + switch (val) {
> + case INTEL_BROADCAST_RGB_AUTO:
> + intel_dp->color_range_auto = true;
> + break;
> + case INTEL_BROADCAST_RGB_FULL:
> + intel_dp->color_range_auto = false;
> + intel_dp->color_range = 0;
> + break;
> + case INTEL_BROADCAST_RGB_LIMITED:
> + intel_dp->color_range_auto = false;
> + intel_dp->color_range = DP_COLOR_RANGE_16_235;
> + break;
> + default:
> + return -EINVAL;
> + }
> goto done;
> }
>
> @@ -2606,6 +2625,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
> struct drm_connector *connect
>
> intel_attach_force_audio_property(connector);
> intel_attach_broadcast_rgb_property(connector);
> + intel_dp->color_range_auto = true;
>
> if (is_edp(intel_dp)) {
> drm_mode_create_scaling_mode_property(connector->dev);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 4df47be..1a698c6 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -343,6 +343,7 @@ struct intel_hdmi {
> u32 sdvox_reg;
> int ddc_bus;
> uint32_t color_range;
> + bool color_range_auto;
> bool has_hdmi_sink;
> bool has_audio;
> enum hdmi_force_audio force_audio;
> @@ -362,6 +363,7 @@ struct intel_dp {
> bool has_audio;
> enum hdmi_force_audio force_audio;
> uint32_t color_range;
> + bool color_range_auto;
> uint8_t link_bw;
> uint8_t lane_count;
> uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index f194d75..58b0
[pull] drm-intel-fixes
Hi Dave More important fixes for 3.9: - error_state improvements to help debug the new scanline wait code added for gen6+ - bug reports started popping up :( patch from Chris Wilson. - fix a panel power sequence confusion between the eDP and lvds detection code resulting in black screens - regression introduce in 3.8 (Jani Nikula) - Chris fixed the root-cause of the ilk relocation vs. evict bug. - Another piece of cargo-culted rc6 lore from Jani, fixes up a regression where a system refused to go into rc6 after suspend sometimes. The last two are cc: stable. Cheers, Daniel The following changes since commit 93927ca52a55c23e0a6a305e7e9082e8411ac9fa: drm/i915: Revert shrinker changes from "Track unbound pages" (2013-01-10 18:02:44 +0100) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to b514407547890686572606c9dfa4b7f832db9958: drm/i915: fix FORCEWAKE posting reads (2013-01-17 11:09:25 +0100) Chris Wilson (2): drm/i915: Record DERRMR, FORCEWAKE and RING_CTL in error-state drm/i915: Invalidate the relocation presumed_offsets along the slow path Jani Nikula (2): drm/i915/eDP: do not write power sequence registers for ghost eDP drm/i915: fix FORCEWAKE posting reads drivers/gpu/drm/i915/i915_debugfs.c|3 ++ drivers/gpu/drm/i915/i915_drv.h|3 ++ drivers/gpu/drm/i915/i915_gem_execbuffer.c | 21 + drivers/gpu/drm/i915/i915_irq.c| 11 +++ drivers/gpu/drm/i915/i915_reg.h|2 ++ drivers/gpu/drm/i915/intel_dp.c| 47 +++- drivers/gpu/drm/i915/intel_pm.c| 17 +++--- 7 files changed, 84 insertions(+), 20 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
drm/i915: RGB quantization range stuff v3
Third attempt at handling the RGB quantization range for HDMI and DP. Changes since the last time: - Addressed all of Paulo's review comments. I think this is ready to go in, unless someone complains loudly.
[PATCH v3 1/4] drm/i915: Fix RGB color range property for PCH platforms
From: Ville Syrj?l?
The RGB color range select bit on the DP/SDVO/HDMI registers
disappeared when PCH was introduced, and instead a new PIPECONF bit
was added that performs the same function.
Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
it in the encoder mode_fixup if limited color range is requested.
Set the the PIPECONF bit 13 based on the flag.
Experimentation showed that simply toggling the bit while the pipe is
active doesn't work. We need to restart the pipe, which luckily already
happens.
The DP/SDVO/HDMI bit 8 is marked MBZ in the docs, so avoid setting it,
although it doesn't seem to do any harm in practice.
TODO:
- the PIPECONF bit too seems to have disappeared from HSW. Need a
volunteer to test if it's just a documentation issue or if it's really
gone. If the bit is gone and no easy replacement is found, then I suppose
we may need to use the pipe CSC unit to perform the range compression.
v2: Use mode private_flags instead of intel_encoder virtual functions
v3: Moved the intel_dp color_range handling after bpc check to help
later patches
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46800
Reviewed-by: Paulo Zanoni
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c |5 +
drivers/gpu/drm/i915/intel_dp.c |7 ++-
drivers/gpu/drm/i915/intel_drv.h |5 +
drivers/gpu/drm/i915/intel_hdmi.c|5 +
drivers/gpu/drm/i915/intel_sdvo.c|5 -
6 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 36789bf..a2550c5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2652,6 +2652,7 @@
#define PIPECONF_INTERLACED_DBL_ILK (4 << 21) /* ilk/snb only */
#define PIPECONF_PFIT_PF_INTERLACED_DBL_ILK (5 << 21) /* ilk/snb only */
#define PIPECONF_CXSR_DOWNCLOCK (1<<16)
+#define PIPECONF_COLOR_RANGE_SELECT (1 << 13)
#define PIPECONF_BPC_MASK(0x7 << 5)
#define PIPECONF_8BPC(0<<5)
#define PIPECONF_10BPC (1<<5)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c7313f8..f48f698 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5097,6 +5097,11 @@ static void ironlake_set_pipeconf(struct drm_crtc *crtc,
else
val |= PIPECONF_PROGRESSIVE;
+ if (adjusted_mode->private_flags & INTEL_MODE_LIMITED_COLOR_RANGE)
+ val |= PIPECONF_COLOR_RANGE_SELECT;
+ else
+ val &= ~PIPECONF_COLOR_RANGE_SELECT;
+
I915_WRITE(PIPECONF(pipe), val);
POSTING_READ(PIPECONF(pipe));
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index cf25481..64824d0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -763,6 +763,10 @@ intel_dp_mode_fixup(struct drm_encoder *encoder,
return false;
bpp = adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 : 24;
+
+ if (intel_dp->color_range)
+ adjusted_mode->private_flags |= INTEL_MODE_LIMITED_COLOR_RANGE;
+
mode_rate = intel_dp_link_required(adjusted_mode->clock, bpp);
for (clock = 0; clock <= max_clock; clock++) {
@@ -967,7 +971,8 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct
drm_display_mode *mode,
else
intel_dp->DP |= DP_PLL_FREQ_270MHZ;
} else if (!HAS_PCH_CPT(dev) || is_cpu_edp(intel_dp)) {
- intel_dp->DP |= intel_dp->color_range;
+ if (!HAS_PCH_SPLIT(dev))
+ intel_dp->DP |= intel_dp->color_range;
if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
intel_dp->DP |= DP_SYNC_HS_HIGH;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 54a034c..4df47be 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -109,6 +109,11 @@
* timings in the mode to prevent the crtc fixup from overwriting them.
* Currently only lvds needs that. */
#define INTEL_MODE_CRTC_TIMINGS_SET (0x20)
+/*
+ * Set when limited 16-235 (as opposed to full 0-255) RGB color range is
+ * to be used.
+ */
+#define INTEL_MODE_LIMITED_COLOR_RANGE (0x40)
static inline void
intel_mode_set_pixel_multiplier(struct drm_display_mode *mode,
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 6387f9b..f194d75 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -766,6 +766,11 @@ bool intel_hdmi_mode_fixup(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
+ struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encode
[PATCH v3 2/4] drm/i915: Add "Automatic" mode for the "Broadcast RGB" property
From: Ville Syrj?l?
Add a new "Automatic" mode to the "Broadcast RGB" range property.
When selected the driver automagically selects between full range and
limited range output.
Based on CEA-861 [1] guidelines, limited range output is selected if the
mode is a CEA mode, except 640x480. Otherwise full range output is used.
Additionally DVI monitors should most likely default to full range
always.
As per DP1.2a [2] DisplayPort should always use full range for 18bpp, and
otherwise will follow CEA-861 rules.
NOTE: The default value for the property will now be "Automatic"
so some people may be affected in case they're relying on the
current full range default.
[1] CEA-861-E - 5.1 Default Encoding Parameters
[2] VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
v2: Use has_hdmi_sink to check if a HDMI monitor is present
v3: Add information about relevant spec chapters
Reviewed-by: Paulo Zanoni
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/i915_drv.h|4 +++
drivers/gpu/drm/i915/intel_dp.c| 32 ++---
drivers/gpu/drm/i915/intel_drv.h |2 +
drivers/gpu/drm/i915/intel_hdmi.c | 29 +++---
drivers/gpu/drm/i915/intel_modes.c |5 ++-
drivers/gpu/drm/i915/intel_sdvo.c | 38 +--
6 files changed, 93 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d0f051b..449bbe0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1803,5 +1803,9 @@ __i915_write(64, q)
#define POSTING_READ(reg) (void)I915_READ_NOTRACE(reg)
#define POSTING_READ16(reg)(void)I915_READ16_NOTRACE(reg)
+/* "Broadcast RGB" property */
+#define INTEL_BROADCAST_RGB_AUTO 0
+#define INTEL_BROADCAST_RGB_FULL 1
+#define INTEL_BROADCAST_RGB_LIMITED 2
#endif
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 64824d0..4590620 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -764,6 +764,18 @@ intel_dp_mode_fixup(struct drm_encoder *encoder,
bpp = adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 : 24;
+ if (intel_dp->color_range_auto) {
+ /*
+* See:
+* CEA-861-E - 5.1 Default Encoding Parameters
+* VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
+*/
+ if (bpp != 18 && drm_mode_cea_vic(adjusted_mode) > 1)
+ intel_dp->color_range = DP_COLOR_RANGE_16_235;
+ else
+ intel_dp->color_range = 0;
+ }
+
if (intel_dp->color_range)
adjusted_mode->private_flags |= INTEL_MODE_LIMITED_COLOR_RANGE;
@@ -2462,10 +2474,21 @@ intel_dp_set_property(struct drm_connector *connector,
}
if (property == dev_priv->broadcast_rgb_property) {
- if (val == !!intel_dp->color_range)
- return 0;
-
- intel_dp->color_range = val ? DP_COLOR_RANGE_16_235 : 0;
+ switch (val) {
+ case INTEL_BROADCAST_RGB_AUTO:
+ intel_dp->color_range_auto = true;
+ break;
+ case INTEL_BROADCAST_RGB_FULL:
+ intel_dp->color_range_auto = false;
+ intel_dp->color_range = 0;
+ break;
+ case INTEL_BROADCAST_RGB_LIMITED:
+ intel_dp->color_range_auto = false;
+ intel_dp->color_range = DP_COLOR_RANGE_16_235;
+ break;
+ default:
+ return -EINVAL;
+ }
goto done;
}
@@ -2606,6 +2629,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
+ intel_dp->color_range_auto = true;
if (is_edp(intel_dp)) {
drm_mode_create_scaling_mode_property(connector->dev);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 4df47be..1a698c6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -343,6 +343,7 @@ struct intel_hdmi {
u32 sdvox_reg;
int ddc_bus;
uint32_t color_range;
+ bool color_range_auto;
bool has_hdmi_sink;
bool has_audio;
enum hdmi_force_audio force_audio;
@@ -362,6 +363,7 @@ struct intel_dp {
bool has_audio;
enum hdmi_force_audio force_audio;
uint32_t color_range;
+ bool color_range_auto;
uint8_t link_bw;
uint8_t lane_count;
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index f194d75..db67be6 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++
[PATCH v2 3/4] drm/edid: Add drm_rgb_quant_range_selectable()
From: Ville Syrj?l?
drm_rgb_quant_range_selectable() will report whether the monitor
claims to support for RGB quantization range selection.
The information can be found in the CEA Video capability block.
v2: s/quantzation/quantization/ in the comment
Reviewed-by: Paulo Zanoni
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_edid.c | 33 +
include/drm/drm_crtc.h |1 +
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5a3770f..a3a3b61 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1483,9 +1483,11 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
#define VIDEO_BLOCK 0x02
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK 0x04
+#define VIDEO_CAPABILITY_BLOCK 0x07
#define EDID_BASIC_AUDIO (1 << 6)
#define EDID_CEA_YCRCB444 (1 << 5)
#define EDID_CEA_YCRCB422 (1 << 4)
+#define EDID_CEA_VCDB_QS (1 << 6)
/**
* Search EDID for CEA extension block.
@@ -1902,6 +1904,37 @@ end:
EXPORT_SYMBOL(drm_detect_monitor_audio);
/**
+ * drm_rgb_quant_range_selectable - is RGB quantization range selectable?
+ *
+ * Check whether the monitor reports the RGB quantization range selection
+ * as supported. The AVI infoframe can then be used to inform the monitor
+ * which quantization range (full or limited) is used.
+ */
+bool drm_rgb_quant_range_selectable(struct edid *edid)
+{
+ u8 *edid_ext;
+ int i, start, end;
+
+ edid_ext = drm_find_cea_extension(edid);
+ if (!edid_ext)
+ return false;
+
+ if (cea_db_offsets(edid_ext, &start, &end))
+ return false;
+
+ for_each_cea_db(edid_ext, i, start, end) {
+ if (cea_db_tag(&edid_ext[i]) == VIDEO_CAPABILITY_BLOCK &&
+ cea_db_payload_len(&edid_ext[i]) == 2) {
+ DRM_DEBUG_KMS("CEA VCDB 0x%02x\n", edid_ext[i + 2]);
+ return edid_ext[i + 2] & EDID_CEA_VCDB_QS;
+ }
+ }
+
+ return false;
+}
+EXPORT_SYMBOL(drm_rgb_quant_range_selectable);
+
+/**
* drm_add_display_info - pull display info out if present
* @edid: EDID data
* @info: display info (attached to connector)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 00d78b5..30892dc 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1033,6 +1033,7 @@ extern u8 *drm_find_cea_extension(struct edid *edid);
extern u8 drm_match_cea_mode(struct drm_display_mode *to_match);
extern bool drm_detect_hdmi_monitor(struct edid *edid);
extern bool drm_detect_monitor_audio(struct edid *edid);
+extern bool drm_rgb_quant_range_selectable(struct edid *edid);
extern int drm_mode_page_flip_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
extern struct drm_display_mode *drm_cvt_mode(struct drm_device *dev,
--
1.7.8.6
[PATCH v2 4/4] drm/i915: Provide the quantization range in the AVI infoframe
From: Ville Syrj?l?
The AVI infoframe is able to inform the display whether the source is
sending full or limited range RGB data.
As per CEA-861 [1] we must first check whether the display reports the
quantization range as selectable, and if so we can set the approriate
bits in the AVI inforframe.
[1] CEA-861-E - 6.4 Format of Version 2 AVI InfoFrame
v2: Give the Q bits better names, add spec chapter information
Reviewed-by: Paulo Zanoni
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_drv.h |4
drivers/gpu/drm/i915/intel_hdmi.c | 11 +++
drivers/gpu/drm/i915/intel_sdvo.c | 16 ++--
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1a698c6..aeff0d1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -289,6 +289,9 @@ struct cxsr_latency {
#define DIP_LEN_AVI 13
#define DIP_AVI_PR_10
#define DIP_AVI_PR_21
+#define DIP_AVI_RGB_QUANT_RANGE_DEFAULT(0 << 2)
+#define DIP_AVI_RGB_QUANT_RANGE_LIMITED(1 << 2)
+#define DIP_AVI_RGB_QUANT_RANGE_FULL (2 << 2)
#define DIP_TYPE_SPD 0x83
#define DIP_VERSION_SPD0x1
@@ -347,6 +350,7 @@ struct intel_hdmi {
bool has_hdmi_sink;
bool has_audio;
enum hdmi_force_audio force_audio;
+ bool rgb_quant_range_selectable;
void (*write_infoframe)(struct drm_encoder *encoder,
struct dip_infoframe *frame);
void (*set_infoframes)(struct drm_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index db67be6..d53b731 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -331,6 +331,7 @@ static void intel_set_infoframe(struct drm_encoder *encoder,
static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
struct drm_display_mode *adjusted_mode)
{
+ struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
struct dip_infoframe avi_if = {
.type = DIP_TYPE_AVI,
.ver = DIP_VERSION_AVI,
@@ -340,6 +341,13 @@ static void intel_hdmi_set_avi_infoframe(struct
drm_encoder *encoder,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
avi_if.body.avi.YQ_CN_PR |= DIP_AVI_PR_2;
+ if (intel_hdmi->rgb_quant_range_selectable) {
+ if (adjusted_mode->private_flags &
INTEL_MODE_LIMITED_COLOR_RANGE)
+ avi_if.body.avi.ITC_EC_Q_SC |=
DIP_AVI_RGB_QUANT_RANGE_LIMITED;
+ else
+ avi_if.body.avi.ITC_EC_Q_SC |=
DIP_AVI_RGB_QUANT_RANGE_FULL;
+ }
+
avi_if.body.avi.VIC = drm_mode_cea_vic(adjusted_mode);
intel_set_infoframe(encoder, &avi_if);
@@ -825,6 +833,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
intel_hdmi->has_hdmi_sink = false;
intel_hdmi->has_audio = false;
+ intel_hdmi->rgb_quant_range_selectable = false;
edid = drm_get_edid(connector,
intel_gmbus_get_adapter(dev_priv,
intel_hdmi->ddc_bus));
@@ -836,6 +845,8 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
intel_hdmi->has_hdmi_sink =
drm_detect_hdmi_monitor(edid);
intel_hdmi->has_audio = drm_detect_monitor_audio(edid);
+ intel_hdmi->rgb_quant_range_selectable =
+ drm_rgb_quant_range_selectable(edid);
}
kfree(edid);
}
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 3e34a35..f01063a 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -126,6 +126,7 @@ struct intel_sdvo {
bool is_hdmi;
bool has_hdmi_monitor;
bool has_hdmi_audio;
+ bool rgb_quant_range_selectable;
/**
* This is set if we detect output of sdvo device as LVDS and
@@ -947,7 +948,8 @@ static bool intel_sdvo_write_infoframe(struct intel_sdvo
*intel_sdvo,
&tx_rate, 1);
}
-static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo)
+static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo,
+const struct drm_display_mode
*adjusted_mode)
{
struct dip_infoframe avi_if = {
.type = DIP_TYPE_AVI,
@@ -956,6 +958,13 @@ static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo
*intel_sdvo)
};
uint8_t sdvo_data[4 + sizeof(avi_if.body.avi)];
+ if (intel_sdvo->rgb_quant_range_selectable) {
+ if (adjusted_mode->private_flags &
INTEL_MODE_LIMITED_COLOR_RANGE)
+ avi_
[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf wrote: > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf >> wrote: >> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote: >> >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf >> >> wrote: >> >> > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf wrote: >> >> >> On 2013.01.15 at 16:26 +0100, Michel D?nzer wrote: >> >> >> > On Die, 201301-15 at 16:23 +0100, Markus Trippelsdorf wrote: >> >> >> > > On 2013.01.15 at 15:43 +0100, Michel D?nzer wrote: >> >> >> > > > On Sam, 2013-01-05 at 11:41 +0100, Markus Trippelsdorf wrote: >> >> >> > > > > On 2012.12.20 at 14:58 +0100, Markus Trippelsdorf wrote: >> >> >> > > > > > >> >> >> > > > > > And just in case it got lost in the noise yesterday: >> >> >> > > > > > The image corruption is caused by Dave's commit: >> >> >> > > > > > >> >> >> > > > > > commit dd54fee7d440c4a9756cce2c24a50c15e4c17ccb >> >> >> > > > > > Author: Dave Airlie >> >> >> > > > > > Date: Fri Dec 14 21:04:46 2012 +1000 >> >> >> > > > > > >> >> >> > > > > > radeon: fix regression with eviction since evict caching >> >> >> > > > > > changes >> >> >> > > > > > >> >> >> > > > > > Reverting it 'fixes' the issue. >> >> >> > > > > >> >> >> > > > > Ping. >> >> >> > > > > The issue still happens with todays Linus git tree. >> >> >> > > > >> >> >> > > > Does the corruption also occur with >> >> >> > > > dd54fee7d440c4a9756cce2c24a50c15e4c17ccb applied manually on top >> >> >> > > > of >> >> >> > > > 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d? >> >> >> > > >> >> >> > > No. >> >> >> > >> >> >> > So, can you bisect which change between those two actually introduced >> >> >> > the corruption? >> >> > >> >> > The real cause of the image corruption is: >> >> > >> >> > d025e9e2b890db679f1246037bf65bd4be512627 is the first bad commit >> >> > commit d025e9e2b890db679f1246037bf65bd4be512627 >> >> > Author: Jerome Glisse >> >> > Date: Thu Nov 29 10:35:41 2012 -0500 >> >> > >> >> > drm/radeon: do not move bo to different placement at each cs >> >> > >> >> > The bo creation placement is where the bo will be. Instead of trying >> >> > to move bo at each command stream let this work to another worker >> >> > thread that will use more advance heuristic. >> >> > >> >> > agd5f: remove leftover unused variable >> >> > >> >> > Signed-off-by: Jerome Glisse >> >> > Reviewed-by: Alex Deucher >> >> > >> >> > Reverting d025e9e2b890d on top of Linus' tree fixes the issue. >> >> >> >> Can you try this patch from Jerome: >> >> https://bugzilla.kernel.org/attachment.cgi?id=91421 >> > >> > It fixes the corruption, but it degrades performance so much that it >> > takes several seconds to switch virtual desktops under xmonad. And >> > sometimes the website used for the scroll test is stuck for several >> > seconds and unscrollable during that time. >> > >> > -- >> > Markus >> >> What about this patch instead : >> http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch > > This one doesn't work: > > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: GPU lockup CP stall for more > than 1msec > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: GPU lockup (waiting for > 0x0a63 last fence id 0x0a62) > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to parse > relocation -12! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to > schedule IB ! > Jan 17 09:40:53 x4 kernel: radeon :01:05.0: couldn't schedule ib > Jan 17 09:40:53 x4 kernel: [drm:radeon_cs_
[Bug 58659] With latest kernel 3.8-rc1, compiz crashes after boot
https://bugs.freedesktop.org/show_bug.cgi?id=58659 --- Comment #19 from Jerome Glisse --- Updated patch http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch Still weird that you point to same commit and first patch did not solve it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/77c82471/attachment.html>
[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote: > On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf > wrote: > > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote: > >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf > >> wrote: > >> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote: > >> >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf > >> >> wrote: > >> >> > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf wrote: > >> >> >> On 2013.01.15 at 16:26 +0100, Michel D?nzer wrote: > >> >> >> > On Die, 201301-15 at 16:23 +0100, Markus Trippelsdorf wrote: > >> >> >> > > On 2013.01.15 at 15:43 +0100, Michel D?nzer wrote: > >> >> >> > > > On Sam, 2013-01-05 at 11:41 +0100, Markus Trippelsdorf wrote: > >> >> >> > > > > On 2012.12.20 at 14:58 +0100, Markus Trippelsdorf wrote: > >> >> >> > > > > > > >> >> >> > > > > > And just in case it got lost in the noise yesterday: > >> >> >> > > > > > The image corruption is caused by Dave's commit: > >> >> >> > > > > > > >> >> >> > > > > > commit dd54fee7d440c4a9756cce2c24a50c15e4c17ccb > >> >> >> > > > > > Author: Dave Airlie > >> >> >> > > > > > Date: Fri Dec 14 21:04:46 2012 +1000 > >> >> >> > > > > > > >> >> >> > > > > > radeon: fix regression with eviction since evict > >> >> >> > > > > > caching changes > >> >> >> > > > > > > >> >> >> > > > > > Reverting it 'fixes' the issue. > >> >> >> > > > > > >> >> >> > > > > Ping. > >> >> >> > > > > The issue still happens with todays Linus git tree. > >> >> >> > > > > >> >> >> > > > Does the corruption also occur with > >> >> >> > > > dd54fee7d440c4a9756cce2c24a50c15e4c17ccb applied manually on > >> >> >> > > > top of > >> >> >> > > > 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d? > >> >> >> > > > >> >> >> > > No. > >> >> >> > > >> >> >> > So, can you bisect which change between those two actually > >> >> >> > introduced > >> >> >> > the corruption? > >> >> > > >> >> > The real cause of the image corruption is: > >> >> > > >> >> > d025e9e2b890db679f1246037bf65bd4be512627 is the first bad commit > >> >> > commit d025e9e2b890db679f1246037bf65bd4be512627 > >> >> > Author: Jerome Glisse > >> >> > Date: Thu Nov 29 10:35:41 2012 -0500 > >> >> > > >> >> > drm/radeon: do not move bo to different placement at each cs > >> >> > > >> >> > The bo creation placement is where the bo will be. Instead of > >> >> > trying > >> >> > to move bo at each command stream let this work to another worker > >> >> > thread that will use more advance heuristic. > >> >> > > >> >> > agd5f: remove leftover unused variable > >> >> > > >> >> > Signed-off-by: Jerome Glisse > >> >> > Reviewed-by: Alex Deucher > >> >> > > >> >> > Reverting d025e9e2b890d on top of Linus' tree fixes the issue. > >> >> > >> >> Can you try this patch from Jerome: > >> >> https://bugzilla.kernel.org/attachment.cgi?id=91421 > >> > > >> > It fixes the corruption, but it degrades performance so much that it > >> > takes several seconds to switch virtual desktops under xmonad. And > >> > sometimes the website used for the scroll test is stuck for several > >> > seconds and unscrollable during that time. > >> > > >> > -- > >> > Markus > >> > >> What about this patch instead : > >> http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch > > > > This one doesn't work: > > Same address updated patch > > http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch It still doesn't work unfortunately. Can you please just revert d025e9e2b89 for now? Maybe it's better to wait for the next kernel release for another solution. Jan 17 17:05:34 x4 kernel: radeon :01:05.0: GPU lockup CP stall for more than 1msec Jan 17 17:05:34 x4 kernel: radeon :01:05.0: GPU lockup (waiting for 0x022b last fence id 0x0224) Jan 17 17:05:34 x4 kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12! Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (764, 6, 4096, -12) Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (764, 6, 4096, -12) Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (764, 6, 4096, -12) Jan 17 17:05:34 x4 kernel: radeon :01:05.0: couldn't schedule ib Jan 17 17:05:34 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (7098368, 6, 4096, -12) Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (7278592, 2, 4096, -12) -- Markus
[Bug 59521] New: [Serious Sam 3] Missing textures with R600g
syncIOManager: 371866 single object sleeps, 598 multi object sleeps CAsyncIOManager: 0 single object alertable sleeps, 2 multi object alertable sleeps -->8-- Steam is launched with MESA_DEBUG=1 and R600_LLVM=0, community support is disabled. Upstream bug report: steamcommunity.com/app/41070/discussions/0/846942784171341620/ -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/546d8237/attachment.html>
[Bug 59521] [Serious Sam 3] Missing textures with R600g
https://bugs.freedesktop.org/show_bug.cgi?id=59521 --- Comment #1 from Alex Deucher --- If the game uses compressed textures, make sure you have libtxc-dxtn installed. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130117/d25e29cc/attachment.html>
