[Intel-gfx] [PATCH 1/2] glamor: Move flags check to intel_glamor.
Address Chris comment. We concentrate all the flag check into
intel_glamor layer which makes the interface to glamor
self-contained.
Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
src/Makefile.am|6 +---
src/intel_driver.c | 25 +
src/intel_glamor.c | 75 +--
src/intel_uxa.c| 31 +
4 files changed, 82 insertions(+), 55 deletions(-)
diff --git a/src/Makefile.am b/src/Makefile.am
index 1a29390..12ff6ee 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -40,10 +40,6 @@ SUBDIRS += sna
intel_drv_la_LIBADD += sna/libsna.la
endif
-if GLAMOR
-GLAMOR_SOURCE = intel_glamor.c
-endif
-
NULL:=#
intel_drv_la_SOURCES = \
@@ -74,7 +70,7 @@ intel_drv_la_SOURCES = \
i965_3d.c \
i965_video.c \
i965_render.c \
-$(GLAMOR_SOURCE) \
+intel_glamor.c \
$(NULL)
if DRI
diff --git a/src/intel_driver.c b/src/intel_driver.c
index 0f528f3..2cc418e 100644
--- a/src/intel_driver.c
+++ b/src/intel_driver.c
@@ -714,19 +714,12 @@ static Bool I830PreInit(ScrnInfoPtr scrn, int flags)
return FALSE;
}
-#ifdef GLAMOR
-/* Load glamor module */
-if (!xf86LoadSubModule(scrn, glamor_egl)) {
-PreInitCleanup(scrn);
-return FALSE;
-}
-
-if (!intel_glamor_pre_init(scrn)) {
- xf86DrvMsg(scrn-scrnIndex, X_ERROR,
- Failed to pre init glamor display.\n);
- return FALSE;
-}
-#endif
+ if (!intel_glamor_pre_init(scrn)) {
+ PreInitCleanup(scrn);
+ xf86DrvMsg(scrn-scrnIndex, X_ERROR,
+ Failed to pre init glamor display.\n);
+ return FALSE;
+ }
/* Load the dri2 module if requested. */
if (intel-directRenderingType != DRI_DISABLED)
@@ -1126,8 +1119,7 @@ static void I830FreeScreen(int scrnIndex, int flags)
ScrnInfoPtr scrn = xf86Screens[scrnIndex];
intel_screen_private *intel = intel_get_screen_private(scrn);
- if (intel-uxa_flags UXA_GLAMOR_FLAGS)
- intel_glamor_free_screen(scrnIndex, flags);
+ intel_glamor_free_screen(scrnIndex, flags);
if (intel) {
intel_mode_fini(intel);
@@ -1208,8 +1200,7 @@ static Bool I830CloseScreen(int scrnIndex, ScreenPtr
screen)
DeleteCallback(FlushCallback, intel_flush_callback, scrn);
- if (intel-uxa_flags UXA_GLAMOR_FLAGS)
- intel_glamor_close_screen(screen);
+ intel_glamor_close_screen(screen);
if (intel-uxa_driver) {
uxa_driver_fini(screen);
diff --git a/src/intel_glamor.c b/src/intel_glamor.c
index cadfc71..80cde40 100644
--- a/src/intel_glamor.c
+++ b/src/intel_glamor.c
@@ -48,6 +48,9 @@ intel_glamor_create_screen_resources(ScreenPtr screen)
ScrnInfoPtr scrn = xf86Screens[screen-myNum];
intel_screen_private *intel = intel_get_screen_private(scrn);
+ if (!(intel-uxa_flags UXA_GLAMOR_FLAGS))
+ return TRUE;
+
if (!glamor_glyphs_init(screen))
return FALSE;
if (!glamor_egl_create_textured_screen(screen,
@@ -60,57 +63,100 @@ intel_glamor_create_screen_resources(ScreenPtr screen)
Bool
intel_glamor_pre_init(ScrnInfoPtr scrn)
{
+#ifdef GLAMOR
intel_screen_private *intel;
intel = intel_get_screen_private(scrn);
+
+ /* Load glamor module */
+ if (!xf86LoadSubModule(scrn, glamor_egl))
+ return FALSE;
+
return glamor_egl_init(scrn, intel-drmSubFD);
+#else
+ return TRUE;
+#endif
}
Bool
intel_glamor_create_textured_pixmap(PixmapPtr pixmap)
{
struct intel_pixmap *priv;
+ ScrnInfoPtr scrn = xf86Screens[pixmap-drawable.pScreen-myNum];
+ intel_screen_private * intel;
+
priv = intel_get_pixmap_private(pixmap);
- return glamor_egl_create_textured_pixmap(pixmap, priv-bo-handle,
-priv-stride);
+ intel = intel_get_screen_private(scrn);
+ if ((intel-uxa_flags UXA_GLAMOR_FLAGS)
+ glamor_egl_create_textured_pixmap(pixmap, priv-bo-handle,
+ priv-stride)) {
+ priv-pinned = 1;
+ return TRUE;
+ }
+ return FALSE;
}
void
intel_glamor_destroy_pixmap(PixmapPtr pixmap)
{
- glamor_egl_destroy_textured_pixmap(pixmap);
+ ScrnInfoPtr scrn = xf86Screens[pixmap-drawable.pScreen-myNum];
+ intel_screen_private * intel;
+
+ intel = intel_get_screen_private(scrn);
+ if (intel-uxa_flags UXA_GLAMOR_FLAGS)
+ glamor_egl_destroy_textured_pixmap(pixmap);
}
Bool
intel_glamor_init(ScreenPtr screen)
{
+#ifdef GLAMOR
ScrnInfoPtr scrn = xf86Screens[screen-myNum];
+ intel_screen_private * intel;
+
if
[Intel-gfx] [PATCH 2/2] glamor: Address GLAMOR/UXA flushing problem.
This commit introduces a new function in UXA layer need_flush
which is used to let the UXA layer to notify the lower layer
that some pixmap get modified by GLAMOR. And then the intel
driver could know it need to flush front buffer latter.
This commit also adds some necessary flushing pointis for UXA
layer and glamor layer. Basicly, there are three scenarios:
1. Before calling into glamor layer, it needs to flush all the
corresponding UXA batch comand buffer.
2. After calling the glamor rendering functions, it needs to
flush the pending GL operations.
3. Before we map a pixmap's BO, we also need to flush all the
pending GL operations.
The scenario 2 could be eliminated when we fully change to glamor
path.
Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
src/intel_glamor.c | 13 -
src/intel_uxa.c|8 +++-
uxa/uxa-accel.c| 30 --
uxa/uxa.h | 16 +++-
4 files changed, 58 insertions(+), 9 deletions(-)
diff --git a/src/intel_glamor.c b/src/intel_glamor.c
index 80cde40..0920c05 100644
--- a/src/intel_glamor.c
+++ b/src/intel_glamor.c
@@ -106,6 +106,16 @@ intel_glamor_destroy_pixmap(PixmapPtr pixmap)
glamor_egl_destroy_textured_pixmap(pixmap);
}
+static void
+intel_glamor_need_flush(DrawablePtr pDrawable)
+{
+ ScrnInfoPtr scrn = xf86Screens[pDrawable-pScreen-myNum];
+ intel_screen_private * intel;
+
+ intel = intel_get_screen_private(scrn);
+ intel-needs_flush = TRUE;
+}
+
Bool
intel_glamor_init(ScreenPtr screen)
{
@@ -113,7 +123,6 @@ intel_glamor_init(ScreenPtr screen)
ScrnInfoPtr scrn = xf86Screens[screen-myNum];
intel_screen_private * intel;
-
if (!glamor_init(screen, GLAMOR_INVERTED_Y_AXIS)) {
xf86DrvMsg(scrn-scrnIndex, X_ERROR,
Failed to initialize glamor\n);
@@ -130,6 +139,8 @@ intel_glamor_init(ScreenPtr screen)
intel-uxa_driver-flags |= UXA_USE_GLAMOR;
intel-uxa_flags = intel-uxa_driver-flags;
+ intel-uxa_driver-need_flush = intel_glamor_need_flush;
+
xf86DrvMsg(scrn-scrnIndex, X_INFO,
Use GLAMOR acceleration.\n);
return TRUE;
diff --git a/src/intel_uxa.c b/src/intel_uxa.c
index 5202076..9fa0165 100644
--- a/src/intel_uxa.c
+++ b/src/intel_uxa.c
@@ -705,8 +705,14 @@ static Bool intel_uxa_prepare_access(PixmapPtr pixmap,
uxa_access_t access)
int ret;
if (!list_is_empty(priv-batch)
- (access == UXA_ACCESS_RW || priv-batch_write))
+ ((access == UXA_ACCESS_RW || access == UXA_GLAMOR_ACCESS_RW)
+|| priv-batch_write))
intel_batch_submit(scrn);
+
+ if (access == UXA_GLAMOR_ACCESS_RW || access == UXA_GLAMOR_ACCESS_RO)
+ return TRUE;
+
+ intel_glamor_block_handler(intel);
if (priv-tiling || bo-size = intel-max_gtt_map_size)
ret = drm_intel_gem_bo_map_gtt(bo);
diff --git a/uxa/uxa-accel.c b/uxa/uxa-accel.c
index 5b27aaa..bd9e02b 100644
--- a/uxa/uxa-accel.c
+++ b/uxa/uxa-accel.c
@@ -56,11 +56,16 @@ uxa_fill_spans(DrawablePtr pDrawable, GCPtr pGC, int n,
int x1, x2, y;
int off_x, off_y;
- if ((uxa_screen-info-flags UXA_GLAMOR_FLAGS)
-(glamor_fill_spans_nf(pDrawable, pGC, n, ppt, pwidth, fSorted)))
- return;
- else if(uxa_screen-info-flags UXA_USE_GLAMOR_ONLY)
- goto fallback;
+ if ((uxa_screen-info-flags UXA_GLAMOR_FLAGS)) {
+ uxa_prepare_access(pDrawable, UXA_GLAMOR_ACCESS_RW);
+ if (glamor_fill_spans_nf(pDrawable,
+pGC, n, ppt, pwidth, fSorted)) {
+ uxa_screen-info-need_flush(pDrawable);
+ glamor_block_handler(screen);
+ return;
+ } else if (uxa_screen-info-flags UXA_USE_GLAMOR_ONLY)
+ goto fallback;
+ }
if (uxa_screen-swappedOut || uxa_screen-force_fallback)
goto fallback;
@@ -685,9 +690,22 @@ uxa_poly_fill_rect(DrawablePtr pDrawable,
int n;
RegionPtr pReg = RECTS_TO_REGION(pScreen, nrect, prect, CT_UNSORTED);
+ if ((uxa_screen-info-flags UXA_GLAMOR_FLAGS)) {
+ uxa_prepare_access(pDrawable, UXA_GLAMOR_ACCESS_RW);
+ if (glamor_poly_fill_rect_nf(pDrawable,
+pGC, nrect, prect)) {
+ uxa_screen-info-need_flush(pDrawable);
+ glamor_block_handler(pDrawable-pScreen);
+ return;
+ } else if (uxa_screen-info-flags UXA_USE_GLAMOR_ONLY)
+ goto fallback;
+ }
+
if ((uxa_screen-info-flags UXA_GLAMOR_FLAGS)
-(glamor_poly_fill_rect_nf(pDrawable, pGC, nrect, prect)))
+(glamor_poly_fill_rect_nf(pDrawable, pGC, nrect,
Re: [Intel-gfx] [PATCH 1/2] glamor: Move flags check to intel_glamor.
On Tue, 15 Nov 2011 19:36:13 +0800, Zhigang Gong zhigang.g...@linux.intel.com wrote: Address Chris comment. We concentrate all the flag check into intel_glamor layer which makes the interface to glamor self-contained. Thanks, that looks a lot better and makes it much easier to read how glamor is integrated into the driver. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] glamor: Address GLAMOR/UXA flushing problem.
On Tue, 15 Nov 2011 19:36:14 +0800, Zhigang Gong zhigang.g...@linux.intel.com wrote: This commit introduces a new function in UXA layer need_flush which is used to let the UXA layer to notify the lower layer that some pixmap get modified by GLAMOR. And then the intel driver could know it need to flush front buffer latter. This commit also adds some necessary flushing pointis for UXA layer and glamor layer. Basicly, there are three scenarios: 1. Before calling into glamor layer, it needs to flush all the corresponding UXA batch comand buffer. 2. After calling the glamor rendering functions, it needs to flush the pending GL operations. 3. Before we map a pixmap's BO, we also need to flush all the pending GL operations. The scenario 2 could be eliminated when we fully change to glamor path. I much prefer the one-sided uxa_prepare_access() you have implemented here for the glamor side. For completeness, you still probably want the uxa_finish_access() though. Alternatively you need to mark up all operations with uxa_prepare_access(GLAMOR | NATIVE | SW, READ | WRITE) which then perform the implicit uxa_finish_access() when the mode changes, and would also allow you to only flush the glamor operations as required. Aside from that, this looks like the right approach to handling the flushing. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] glamor: Address GLAMOR/UXA flushing problem.
-Original Message- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Sent: Tuesday, November 15, 2011 8:25 PM To: Zhigang Gong; intel-gfx@lists.freedesktop.org Cc: zhigang.g...@linux.intel.com Subject: Re: [PATCH 2/2] glamor: Address GLAMOR/UXA flushing problem. On Tue, 15 Nov 2011 19:36:14 +0800, Zhigang Gong zhigang.g...@linux.intel.com wrote: This commit introduces a new function in UXA layer need_flush which is used to let the UXA layer to notify the lower layer that some pixmap get modified by GLAMOR. And then the intel driver could know it need to flush front buffer latter. This commit also adds some necessary flushing pointis for UXA layer and glamor layer. Basicly, there are three scenarios: 1. Before calling into glamor layer, it needs to flush all the corresponding UXA batch comand buffer. 2. After calling the glamor rendering functions, it needs to flush the pending GL operations. 3. Before we map a pixmap's BO, we also need to flush all the pending GL operations. The scenario 2 could be eliminated when we fully change to glamor path. I much prefer the one-sided uxa_prepare_access() you have implemented here for the glamor side. For completeness, you still probably want the uxa_finish_access() though. I was thinking about that, but current uxa_finish_access doesn't have a parameter to indicate the access type. I prefer to change the uxa_finish_access's prototype to the same as uxa_prepare_access(). And then will do glamor flush there if the access type is GLAMOR_WRITE. I'm just not very sure whether it is the best way. Will work out a new patch to implement that soon. BTW, May I have your review tag in the commits which get reviewed by you. Thanks. Alternatively you need to mark up all operations with uxa_prepare_access(GLAMOR | NATIVE | SW, READ | WRITE) which then perform the implicit uxa_finish_access() when the mode changes, and would also allow you to only flush the glamor operations as required. This looks much complicate than the first solution. I prefer the first solution. -- Zhigang Aside from that, this looks like the right approach to handling the flushing. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] glamor: Address GLAMOR/UXA flushing problem.
On Tue, 15 Nov 2011 20:54:13 +0800, Zhigang Gong zhigang.g...@linux.intel.com wrote: BTW, May I have your review tag in the commits which get reviewed by you. Thanks. I'm hoping that you will rebase the series into something that can be cleanly merged - i.e. I don't expect the patches in their current form and order to be applied. ;-) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] hda - fix ELD memory leak
memset(eld) clears eld-proc_entry which will leak the struct
snd_info_entry when unloading the module.
Fix it by
- remove memset(eld)
- set eld-eld_valid to true _after_ all eld fields have been filled
- don't access the other eld fields when (eld-eld_valid == false)
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
sound/pci/hda/hda_eld.c|5 +
sound/pci/hda/patch_hdmi.c | 11 +--
2 files changed, 6 insertions(+), 10 deletions(-)
--- linux.orig/sound/pci/hda/hda_eld.c 2011-11-15 21:02:25.0 +0800
+++ linux/sound/pci/hda/hda_eld.c 2011-11-15 21:13:46.0 +0800
@@ -297,10 +297,10 @@ static int hdmi_update_eld(struct hdmi_e
buf + ELD_FIXED_BYTES + mnl + 3 * i);
}
+ e-eld_valid = true;
return 0;
out_fail:
- e-eld_ver = 0;
return -EINVAL;
}
@@ -323,9 +323,6 @@ int snd_hdmi_get_eld(struct hdmi_eld *el
* ELD is valid, actual eld_size is assigned in hdmi_update_eld()
*/
- if (!eld-eld_valid)
- return -ENOENT;
-
size = snd_hdmi_get_eld_size(codec, nid);
if (size == 0) {
/* wfg: workaround for ASUS P5E-VM HDMI board */
--- linux.orig/sound/pci/hda/patch_hdmi.c 2011-11-15 21:02:25.0
+0800
+++ linux/sound/pci/hda/patch_hdmi.c2011-11-15 21:13:42.0 +0800
@@ -980,20 +980,19 @@ static void hdmi_present_sense(struct hd
* the unsolicited response to avoid custom WARs.
*/
int present = snd_hda_pin_sense(codec, pin_nid);
+ bool eld_valid = false;
- memset(eld, 0, sizeof(*eld));
+ eld-eld_valid = false;
eld-monitor_present= !!(present AC_PINSENSE_PRESENCE);
if (eld-monitor_present)
- eld-eld_valid = !!(present AC_PINSENSE_ELDV);
- else
- eld-eld_valid = 0;
+ eld_valid = !!(present AC_PINSENSE_ELDV);
printk(KERN_INFO
HDMI status: Codec=%d Pin=%d Presence_Detect=%d
ELD_Valid=%d\n,
- codec-addr, pin_nid, eld-monitor_present, eld-eld_valid);
+ codec-addr, pin_nid, eld-monitor_present, eld_valid);
- if (eld-eld_valid)
+ if (eld_valid)
if (!snd_hdmi_get_eld(eld, codec, pin_nid))
snd_hdmi_show_eld(eld);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] hda - delayed ELD repoll
The Intel HDMI chips (ironlake at least) are found to have ~250ms delay
between the ELD_Valid=1 hotplug event is send and the ELD buffer becomes
actually readable. During the time the ELD buffer is mysteriously all 0.
Fix it by scheduling a delayed work to re-read ELD buffer after 300ms.
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
sound/pci/hda/hda_local.h |2 +
sound/pci/hda/patch_hdmi.c | 49 ++-
2 files changed, 44 insertions(+), 7 deletions(-)
--- linux.orig/sound/pci/hda/hda_local.h2011-11-15 21:29:53.0
+0800
+++ linux/sound/pci/hda/hda_local.h 2011-11-15 21:29:54.0 +0800
@@ -655,6 +655,8 @@ struct hdmi_eld {
#ifdef CONFIG_PROC_FS
struct snd_info_entry *proc_entry;
#endif
+ struct hda_codec *codec;
+ struct delayed_work work;
};
int snd_hdmi_get_eld_size(struct hda_codec *codec, hda_nid_t nid);
--- linux.orig/sound/pci/hda/patch_hdmi.c 2011-11-15 21:29:53.0
+0800
+++ linux/sound/pci/hda/patch_hdmi.c2011-11-15 21:31:48.0 +0800
@@ -746,7 +746,7 @@ static void hdmi_setup_audio_infoframe(s
*/
static void hdmi_present_sense(struct hda_codec *codec, hda_nid_t pin_nid,
- struct hdmi_eld *eld);
+ struct hdmi_eld *eld, bool retry);
static void hdmi_intrinsic_event(struct hda_codec *codec, unsigned int res)
{
@@ -766,7 +766,7 @@ static void hdmi_intrinsic_event(struct
return;
eld = spec-pins[pin_idx].sink_eld;
- hdmi_present_sense(codec, pin_nid, eld);
+ hdmi_present_sense(codec, pin_nid, eld, true);
/*
* HDMI sink's ELD info cannot always be retrieved for now, e.g.
@@ -969,7 +969,7 @@ static int hdmi_read_pin_conn(struct hda
}
static void hdmi_present_sense(struct hda_codec *codec, hda_nid_t pin_nid,
- struct hdmi_eld *eld)
+ struct hdmi_eld *eld, bool retry)
{
/*
* Always execute a GetPinSense verb here, even when called from
@@ -992,13 +992,31 @@ static void hdmi_present_sense(struct hd
HDMI status: Codec=%d Pin=%d Presence_Detect=%d
ELD_Valid=%d\n,
codec-addr, pin_nid, eld-monitor_present, eld_valid);
- if (eld_valid)
+ if (eld_valid) {
if (!snd_hdmi_get_eld(eld, codec, pin_nid))
snd_hdmi_show_eld(eld);
+ else {
+ queue_delayed_work(codec-bus-workq,
+ eld-work,
+ msecs_to_jiffies(300));
+ }
+ }
snd_hda_input_jack_report(codec, pin_nid);
}
+static void hda_eld_work(struct work_struct *work)
+{
+ struct hdmi_eld *eld = container_of(
+ container_of(work, struct delayed_work, work),
+ struct hdmi_eld, work);
+ struct hdmi_spec_per_pin *per_pin =
+ container_of(eld, struct hdmi_spec_per_pin, sink_eld);
+ struct hda_codec *codec = eld-codec;
+
+ hdmi_present_sense(codec, per_pin-pin_nid, eld, false);
+}
+
static int hdmi_add_pin(struct hda_codec *codec, hda_nid_t pin_nid)
{
struct hdmi_spec *spec = codec-spec;
@@ -1227,7 +1245,7 @@ static int generic_hdmi_build_jack(struc
if (err 0)
return err;
- hdmi_present_sense(codec, per_pin-pin_nid, per_pin-sink_eld);
+ hdmi_present_sense(codec, per_pin-pin_nid, per_pin-sink_eld, false);
return 0;
}
@@ -1263,6 +1281,23 @@ static int generic_hdmi_build_controls(s
return 0;
}
+static void snd_hda_eld_init(struct hda_codec *codec, struct hdmi_eld *eld,
+int pin_idx)
+{
+ eld-codec = codec;
+ INIT_DELAYED_WORK(eld-work, hda_eld_work);
+
+ snd_hda_eld_proc_new(codec, eld, pin_idx);
+}
+
+static void snd_hda_eld_free(struct hda_codec *codec, struct hdmi_eld *eld)
+{
+ cancel_delayed_work(eld-work);
+ flush_workqueue(codec-bus-workq);
+
+ snd_hda_eld_proc_free(codec, eld);
+}
+
static int generic_hdmi_init(struct hda_codec *codec)
{
struct hdmi_spec *spec = codec-spec;
@@ -1278,7 +1313,7 @@ static int generic_hdmi_init(struct hda_
AC_VERB_SET_UNSOLICITED_ENABLE,
AC_USRSP_EN | pin_nid);
- snd_hda_eld_proc_new(codec, eld, pin_idx);
+ snd_hda_eld_init(codec, eld, pin_idx);
}
return 0;
}
@@ -1292,7 +1327,7 @@ static void generic_hdmi_free(struct hda
struct hdmi_spec_per_pin *per_pin = spec-pins[pin_idx];
struct hdmi_eld *eld = per_pin-sink_eld;
- snd_hda_eld_proc_free(codec, eld);
+ snd_hda_eld_free(codec, eld);
}
snd_hda_input_jack_free(codec);
Re: [Intel-gfx] [PATCH 1/2] hda - fix ELD memory leak
At Tue, 15 Nov 2011 22:31:55 +0800,
Wu Fengguang wrote:
memset(eld) clears eld-proc_entry which will leak the struct
snd_info_entry when unloading the module.
Fix it by
- remove memset(eld)
- set eld-eld_valid to true _after_ all eld fields have been filled
- don't access the other eld fields when (eld-eld_valid == false)
Signed-off-by: Wu Fengguang fengguang...@intel.com
This should be send to stable kernel, too, right?
It appears in 3.1, at least.
Takashi
---
sound/pci/hda/hda_eld.c|5 +
sound/pci/hda/patch_hdmi.c | 11 +--
2 files changed, 6 insertions(+), 10 deletions(-)
--- linux.orig/sound/pci/hda/hda_eld.c2011-11-15 21:02:25.0
+0800
+++ linux/sound/pci/hda/hda_eld.c 2011-11-15 21:13:46.0 +0800
@@ -297,10 +297,10 @@ static int hdmi_update_eld(struct hdmi_e
buf + ELD_FIXED_BYTES + mnl + 3 * i);
}
+ e-eld_valid = true;
return 0;
out_fail:
- e-eld_ver = 0;
return -EINVAL;
}
@@ -323,9 +323,6 @@ int snd_hdmi_get_eld(struct hdmi_eld *el
* ELD is valid, actual eld_size is assigned in hdmi_update_eld()
*/
- if (!eld-eld_valid)
- return -ENOENT;
-
size = snd_hdmi_get_eld_size(codec, nid);
if (size == 0) {
/* wfg: workaround for ASUS P5E-VM HDMI board */
--- linux.orig/sound/pci/hda/patch_hdmi.c 2011-11-15 21:02:25.0
+0800
+++ linux/sound/pci/hda/patch_hdmi.c 2011-11-15 21:13:42.0 +0800
@@ -980,20 +980,19 @@ static void hdmi_present_sense(struct hd
* the unsolicited response to avoid custom WARs.
*/
int present = snd_hda_pin_sense(codec, pin_nid);
+ bool eld_valid = false;
- memset(eld, 0, sizeof(*eld));
+ eld-eld_valid = false;
eld-monitor_present= !!(present AC_PINSENSE_PRESENCE);
if (eld-monitor_present)
- eld-eld_valid = !!(present AC_PINSENSE_ELDV);
- else
- eld-eld_valid = 0;
+ eld_valid = !!(present AC_PINSENSE_ELDV);
printk(KERN_INFO
HDMI status: Codec=%d Pin=%d Presence_Detect=%d
ELD_Valid=%d\n,
- codec-addr, pin_nid, eld-monitor_present, eld-eld_valid);
+ codec-addr, pin_nid, eld-monitor_present, eld_valid);
- if (eld-eld_valid)
+ if (eld_valid)
if (!snd_hdmi_get_eld(eld, codec, pin_nid))
snd_hdmi_show_eld(eld);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] hda - fix ELD memory leak
At Tue, 15 Nov 2011 22:41:16 +0800,
Wu Fengguang wrote:
On Tue, Nov 15, 2011 at 10:35:41PM +0800, Takashi Iwai wrote:
At Tue, 15 Nov 2011 22:31:55 +0800,
Wu Fengguang wrote:
memset(eld) clears eld-proc_entry which will leak the struct
snd_info_entry when unloading the module.
Fix it by
- remove memset(eld)
- set eld-eld_valid to true _after_ all eld fields have been filled
- don't access the other eld fields when (eld-eld_valid == false)
Signed-off-by: Wu Fengguang fengguang...@intel.com
This should be send to stable kernel, too, right?
It appears in 3.1, at least.
Yeah. Good point! I'll resend it when everything goes fine.
Ah, no, you don't need to resend. I'd just need to put Cc to stable
in the patch commit log. Then Greg will pick it up automatically
when the tree is merged to the upstream.
But of course I need to know beforehand whether the patch is intended
to be sent to stable or not.
Takashi
Thanks,
Fengguang
---
sound/pci/hda/hda_eld.c|5 +
sound/pci/hda/patch_hdmi.c | 11 +--
2 files changed, 6 insertions(+), 10 deletions(-)
--- linux.orig/sound/pci/hda/hda_eld.c2011-11-15 21:02:25.0
+0800
+++ linux/sound/pci/hda/hda_eld.c 2011-11-15 21:13:46.0 +0800
@@ -297,10 +297,10 @@ static int hdmi_update_eld(struct hdmi_e
buf + ELD_FIXED_BYTES + mnl + 3 * i);
}
+ e-eld_valid = true;
return 0;
out_fail:
- e-eld_ver = 0;
return -EINVAL;
}
@@ -323,9 +323,6 @@ int snd_hdmi_get_eld(struct hdmi_eld *el
* ELD is valid, actual eld_size is assigned in hdmi_update_eld()
*/
- if (!eld-eld_valid)
- return -ENOENT;
-
size = snd_hdmi_get_eld_size(codec, nid);
if (size == 0) {
/* wfg: workaround for ASUS P5E-VM HDMI board */
--- linux.orig/sound/pci/hda/patch_hdmi.c 2011-11-15 21:02:25.0
+0800
+++ linux/sound/pci/hda/patch_hdmi.c 2011-11-15 21:13:42.0
+0800
@@ -980,20 +980,19 @@ static void hdmi_present_sense(struct hd
* the unsolicited response to avoid custom WARs.
*/
int present = snd_hda_pin_sense(codec, pin_nid);
+ bool eld_valid = false;
- memset(eld, 0, sizeof(*eld));
+ eld-eld_valid = false;
eld-monitor_present= !!(present AC_PINSENSE_PRESENCE);
if (eld-monitor_present)
- eld-eld_valid = !!(present AC_PINSENSE_ELDV);
- else
- eld-eld_valid = 0;
+ eld_valid = !!(present AC_PINSENSE_ELDV);
printk(KERN_INFO
HDMI status: Codec=%d Pin=%d Presence_Detect=%d
ELD_Valid=%d\n,
- codec-addr, pin_nid, eld-monitor_present, eld-eld_valid);
+ codec-addr, pin_nid, eld-monitor_present, eld_valid);
- if (eld-eld_valid)
+ if (eld_valid)
if (!snd_hdmi_get_eld(eld, codec, pin_nid))
snd_hdmi_show_eld(eld);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] hda - fix ELD memory leak
On Tue, Nov 15, 2011 at 10:45:15PM +0800, Takashi Iwai wrote: At Tue, 15 Nov 2011 22:41:16 +0800, Wu Fengguang wrote: On Tue, Nov 15, 2011 at 10:35:41PM +0800, Takashi Iwai wrote: At Tue, 15 Nov 2011 22:31:55 +0800, Wu Fengguang wrote: memset(eld) clears eld-proc_entry which will leak the struct snd_info_entry when unloading the module. Fix it by - remove memset(eld) - set eld-eld_valid to true _after_ all eld fields have been filled - don't access the other eld fields when (eld-eld_valid == false) Signed-off-by: Wu Fengguang fengguang...@intel.com This should be send to stable kernel, too, right? It appears in 3.1, at least. Yeah. Good point! I'll resend it when everything goes fine. Ah, no, you don't need to resend. I'd just need to put Cc to stable in the patch commit log. Then Greg will pick it up automatically when the tree is merged to the upstream. Ah OK, that would be convenient. But of course I need to know beforehand whether the patch is intended to be sent to stable or not. Ack. The patch applies cleanly to 3.1. Thanks, Fengguang ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] hda - delayed ELD repoll
- if (eld_valid)
+ if (eld_valid) {
if (!snd_hdmi_get_eld(eld, codec, pin_nid))
snd_hdmi_show_eld(eld);
+ else {
Oops, forgot testing @retry here! Updated patch follows.
+ queue_delayed_work(codec-bus-workq,
+eld-work,
+msecs_to_jiffies(300));
+ }
+ }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2 v2] hda - delayed ELD repoll
The Intel HDMI chips (ironlake at least) are found to have ~250ms delay
between the ELD_Valid=1 hotplug event is send and the ELD buffer becomes
actually readable. During the time the ELD buffer is mysteriously all 0.
Fix it by scheduling a delayed work to re-read ELD buffer after 300ms.
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
sound/pci/hda/hda_local.h |2 +
sound/pci/hda/patch_hdmi.c | 49 ++-
2 files changed, 44 insertions(+), 7 deletions(-)
--- linux.orig/sound/pci/hda/hda_local.h2011-11-15 21:29:53.0
+0800
+++ linux/sound/pci/hda/hda_local.h 2011-11-15 21:29:54.0 +0800
@@ -655,6 +655,8 @@ struct hdmi_eld {
#ifdef CONFIG_PROC_FS
struct snd_info_entry *proc_entry;
#endif
+ struct hda_codec *codec;
+ struct delayed_work work;
};
int snd_hdmi_get_eld_size(struct hda_codec *codec, hda_nid_t nid);
--- linux.orig/sound/pci/hda/patch_hdmi.c 2011-11-15 21:29:53.0
+0800
+++ linux/sound/pci/hda/patch_hdmi.c2011-11-16 00:50:50.0 +0800
@@ -746,7 +746,7 @@ static void hdmi_setup_audio_infoframe(s
*/
static void hdmi_present_sense(struct hda_codec *codec, hda_nid_t pin_nid,
- struct hdmi_eld *eld);
+ struct hdmi_eld *eld, bool retry);
static void hdmi_intrinsic_event(struct hda_codec *codec, unsigned int res)
{
@@ -766,7 +766,7 @@ static void hdmi_intrinsic_event(struct
return;
eld = spec-pins[pin_idx].sink_eld;
- hdmi_present_sense(codec, pin_nid, eld);
+ hdmi_present_sense(codec, pin_nid, eld, true);
/*
* HDMI sink's ELD info cannot always be retrieved for now, e.g.
@@ -969,7 +969,7 @@ static int hdmi_read_pin_conn(struct hda
}
static void hdmi_present_sense(struct hda_codec *codec, hda_nid_t pin_nid,
- struct hdmi_eld *eld)
+ struct hdmi_eld *eld, bool retry)
{
/*
* Always execute a GetPinSense verb here, even when called from
@@ -992,13 +992,31 @@ static void hdmi_present_sense(struct hd
HDMI status: Codec=%d Pin=%d Presence_Detect=%d
ELD_Valid=%d\n,
codec-addr, pin_nid, eld-monitor_present, eld_valid);
- if (eld_valid)
+ if (eld_valid) {
if (!snd_hdmi_get_eld(eld, codec, pin_nid))
snd_hdmi_show_eld(eld);
+ else if (retry) {
+ queue_delayed_work(codec-bus-workq,
+ eld-work,
+ msecs_to_jiffies(300));
+ }
+ }
snd_hda_input_jack_report(codec, pin_nid);
}
+static void hda_eld_work(struct work_struct *work)
+{
+ struct hdmi_eld *eld = container_of(
+ container_of(work, struct delayed_work, work),
+ struct hdmi_eld, work);
+ struct hdmi_spec_per_pin *per_pin =
+ container_of(eld, struct hdmi_spec_per_pin, sink_eld);
+ struct hda_codec *codec = eld-codec;
+
+ hdmi_present_sense(codec, per_pin-pin_nid, eld, false);
+}
+
static int hdmi_add_pin(struct hda_codec *codec, hda_nid_t pin_nid)
{
struct hdmi_spec *spec = codec-spec;
@@ -1227,7 +1245,7 @@ static int generic_hdmi_build_jack(struc
if (err 0)
return err;
- hdmi_present_sense(codec, per_pin-pin_nid, per_pin-sink_eld);
+ hdmi_present_sense(codec, per_pin-pin_nid, per_pin-sink_eld, false);
return 0;
}
@@ -1263,6 +1281,23 @@ static int generic_hdmi_build_controls(s
return 0;
}
+static void snd_hda_eld_init(struct hda_codec *codec, struct hdmi_eld *eld,
+int pin_idx)
+{
+ eld-codec = codec;
+ INIT_DELAYED_WORK(eld-work, hda_eld_work);
+
+ snd_hda_eld_proc_new(codec, eld, pin_idx);
+}
+
+static void snd_hda_eld_free(struct hda_codec *codec, struct hdmi_eld *eld)
+{
+ cancel_delayed_work(eld-work);
+ flush_workqueue(codec-bus-workq);
+
+ snd_hda_eld_proc_free(codec, eld);
+}
+
static int generic_hdmi_init(struct hda_codec *codec)
{
struct hdmi_spec *spec = codec-spec;
@@ -1278,7 +1313,7 @@ static int generic_hdmi_init(struct hda_
AC_VERB_SET_UNSOLICITED_ENABLE,
AC_USRSP_EN | pin_nid);
- snd_hda_eld_proc_new(codec, eld, pin_idx);
+ snd_hda_eld_init(codec, eld, pin_idx);
}
return 0;
}
@@ -1292,7 +1327,7 @@ static void generic_hdmi_free(struct hda
struct hdmi_spec_per_pin *per_pin = spec-pins[pin_idx];
struct hdmi_eld *eld = per_pin-sink_eld;
- snd_hda_eld_proc_free(codec, eld);
+ snd_hda_eld_free(codec, eld);
}
snd_hda_input_jack_free(codec);
Re: [Intel-gfx] [PATCH 2/2 v2] hda - delayed ELD repoll
At Wed, 16 Nov 2011 00:57:08 +0800,
Wu Fengguang wrote:
+static void hda_eld_work(struct work_struct *work)
+{
+ struct hdmi_eld *eld = container_of(
+ container_of(work, struct delayed_work, work),
+ struct hdmi_eld, work);
Ugh, hardly to read. Slightly better to use to_delayed_work()?
struct hdmi_eld *eld = container_of(to_delayed_work(work),
struct hdmi_eld, work);
+ struct hdmi_spec_per_pin *per_pin =
+ container_of(eld, struct hdmi_spec_per_pin, sink_eld);
+ struct hda_codec *codec = eld-codec;
+
+ hdmi_present_sense(codec, per_pin-pin_nid, eld, false);
+}
+
static int hdmi_add_pin(struct hda_codec *codec, hda_nid_t pin_nid)
{
struct hdmi_spec *spec = codec-spec;
@@ -1227,7 +1245,7 @@ static int generic_hdmi_build_jack(struc
if (err 0)
return err;
- hdmi_present_sense(codec, per_pin-pin_nid, per_pin-sink_eld);
+ hdmi_present_sense(codec, per_pin-pin_nid, per_pin-sink_eld, false);
...
Looking through the code, I wonder how about keeping work and codec
pointer in struct hdmi_spec_per_pin instead of struct hdmi_eld. Then
we don't need to expose it in hda_local.h, and changes would be
slightly more compact.
hdmi_present_sense() can be modified to receive hdmi_sepc_per_pin*
directly instead of individual nid and eld pointer.
thanks,
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
-Original Message- From: intel-gfx- bounces+vijay.a.purushothaman=intel@lists.freedesktop.org [mailto:intel-gfx- bounces+vijay.a.purushothaman=intel@lists.freedesktop.org] On Behalf Of Wu Fengguang Sent: Monday, November 14, 2011 6:56 PM To: Takashi Iwai Cc: Wang, Zhenyu Z; intel-gfx@lists.freedesktop.org; Barnes, Jesse; Jeremy Bush; Christopher White; Bossart, Pierre-louis Subject: Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver On Mon, Nov 14, 2011 at 05:45:12PM +0800, Takashi Iwai wrote: At Sat, 12 Nov 2011 10:27:26 +0800, Wu Fengguang wrote: (snip) And I'm not sure whether HDMI audio is played while DPMS is off. I haven't tested it. It will go silence on DPMS. I noticed this while doing long term HDMI audio playback tests. This should better be fixed in future on the graphics side. Hm, but I wonder what could be done alternatively. Hopefully there is a register for video-only control... There may be some mode that can keep video off while still keep minimal signals to play HDMI sound? Let's hope :) You can turn off only the plane (but don't turn off the pipe port) to achieve this. Not much of power saving compared to DPMS though. Looks very possible, here is the clue of hardware support: TRANS_DP_CTL - Transcoder DisplayPort Control bit 26: Transcoder DP Audio Only Mode Good to know! But what about HDMI? I'm not sure.. There are no corresponding TRANS_HDMI_CTL registers... Bit 26 of TRANS_DP_CTL does not work. Also there is no such bit for HDMI. Thanks, Fengguang ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx Thanks, Vijay ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: don't disable a PCH DPLL that's in use
If a PCH pipe PLL is being used by transcoder C, don't disable it.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9fa342e..bb8ed3d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1206,7 +1206,8 @@ static void intel_disable_pch_pll(struct drm_i915_private
*dev_priv,
enum pipe pipe)
{
int reg;
- u32 val;
+ u32 val, pll_mask = TRANSC_DPLL_ENABLE | TRANSC_DPLLB_SEL,
+ pll_sel = TRANSC_DPLL_ENABLE;
if (pipe 1)
return;
@@ -1217,6 +1218,15 @@ static void intel_disable_pch_pll(struct
drm_i915_private *dev_priv,
/* Make sure transcoder isn't still depending on us */
assert_transcoder_disabled(dev_priv, pipe);
+ if (pipe == 0)
+ pll_sel |= TRANSC_DPLLA_SEL;
+ else if (pipe == 1)
+ pll_sel |= TRANSC_DPLLB_SEL;
+
+
+ if ((I915_READ(PCH_DPLL_SEL) pll_mask) == pll_sel)
+ return;
+
reg = PCH_DPLL(pipe);
val = I915_READ(reg);
val = ~DPLL_VCO_ENABLE;
--
1.7.4.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: only set the intel_crtc DPMS mode to on if the mode set succeeded
If it failed, leave it in the off state. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/intel_display.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index bb8ed3d..dc3d735 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -5813,10 +5813,12 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc, ret = dev_priv-display.crtc_mode_set(crtc, mode, adjusted_mode, x, y, old_fb); - drm_vblank_post_modeset(dev, pipe); - intel_crtc-dpms_mode = DRM_MODE_DPMS_ON; + if (ret) + intel_crtc-dpms_mode = DRM_MODE_DPMS_OFF; + else + intel_crtc-dpms_mode = DRM_MODE_DPMS_ON; return ret; } -- 1.7.4.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drivers: i915: Default backlight PWM frequency
At Fri, 11 Nov 2011 14:12:58 -0800,
Simon Que wrote:
If the firmware did not initialize the backlight PWM registers, set up a
default PWM frequency of 200 Hz. This is determined using the following
formula:
freq = refclk / (128 * pwm_max)
The PWM register allows the max PWM value to be set. So we want to use
the formula, where freq = 200:
pwm_max = refclk / (128 * freq)
This patch will, in the case of missing PWM register initialization
values, look for the reference clock frequency. Based on that, it sets
an appropriate max PWM value for a frequency of 200 Hz.
If no refclk frequency is found, the max PWM will be zero, which results
in no change to the PWM registers.
Signed-off-by: Simon Que s...@chromium.org
---
drivers/gpu/drm/i915/intel_panel.c | 38 ++-
1 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index f15388c..dda5de2 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -32,6 +32,12 @@
#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
+/* These are used to calculate a reasonable default when firmware has not
+ * configured a maximum PWM frequency, with 200Hz as the current default
target.
+ */
+#define DEFAULT_BACKLIGHT_PWM_FREQ 200
+#define BACKLIGHT_REFCLK_DIVISOR 128
+
void
intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode)
@@ -129,12 +135,32 @@ static int is_backlight_combination_mode(struct
drm_device *dev)
return 0;
}
+static void i915_set_default_max_backlight(struct drm_i915_private *dev_priv)
+{
+ u32 refclk_freq_mhz = 0;
+ u32 max_pwm;
+
+ if (HAS_PCH_SPLIT(dev_priv-dev))
+ refclk_freq_mhz = I915_READ(PCH_RAWCLK_FREQ) RAWCLK_FREQ_MASK;
+ else if (dev_priv-lvds_use_ssc)
+ refclk_freq_mhz = dev_priv-lvds_ssc_freq;
+
+ max_pwm = refclk_freq_mhz * 100 /
+ (BACKLIGHT_REFCLK_DIVISOR * DEFAULT_BACKLIGHT_PWM_FREQ);
+
+ if (HAS_PCH_SPLIT(dev_priv-dev))
+ dev_priv-saveBLC_PWM_CTL2 = max_pwm 16;
+ else if (IS_PINEVIEW(dev_priv-dev))
+ dev_priv-saveBLC_PWM_CTL = max_pwm 17;
+ else
+ dev_priv-saveBLC_PWM_CTL = max_pwm 16;
Is the pineview case really correct?
The special handling for pineview in some places in intel_panel.c is
just for omitting the bit 0, IIRC. It doesn't mean that the value is
twice larger.
BTW, this handling of bit 0 seems necessary not only for pineview but
for the older chips (gen 4) in general, too, as being discussed in
another thread of LKML. 915GM hits the with problem of bit-0, for
example.
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915: Fix bug where screen brightness is not restored
On Mon, 2011-11-14 at 18:42 -0800, Alex Davis wrote:
From: Alex Davisalex14...@yahoo.com
This patch fixes an issue where the screen would remain dark when
a key was pressed when the laptop lid was reopened or after the
laptop had gone into power-save mode.
[cross-posting to intel-gfx]
Keith, also note that Alex and I did respond to your request to test the
already committed patch drm/i915/panel: Always record the backlight
level again (but cleverly). We both determined that patch does *not*
fix the problem. Alex's patch below does fix it.
Matthew, any comment on the question that I fielded?:
Why does intel_panel_disable_backlight even want to set the
brightness to 0 anyway?... Its only caller is just about to turn
off power to the panel. Is that call to
intel_panel_{,actually_}set_backlight(dev, 0) really necessary
or useful on *any* systems?
-Kamal
It seems that there are a number of people with different machines
that have this problem:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/872652
https://launchpad.net/~kamalmostafa/+archive/stuck-backlight
and https://bugs.freedesktop.org/show_bug.cgi?id=41926
This patch is against Linux 3.1
Putting printk's in ./drivers/gpu/drm/i915/intel_panel.c showed that
intel_get_brightness was being called after the panel was disabled,
which caused a 0 to be saved as the value to restore the brightness.
intel_panel_disable_backlight merely sets the brightness to 0. Commenting
out this call allows the correct brightness value to be saved.
Signed-off-by: Alex Davis alex14...@yahoo.com
Tested-by: Kamal Mostafa ka...@canonical.com
-
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index a9e0c7b..6f56676 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -262,8 +262,6 @@ void intel_panel_disable_backlight(struct drm_device *dev)
dev_priv-backlight_level = intel_panel_get_backlight(dev);
dev_priv-backlight_enabled = false;
}
-
- intel_panel_set_backlight(dev, 0);
}
void intel_panel_enable_backlight(struct drm_device *dev)
I code, therefore I am
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915: Fix bug where screen brightness is not restored
At Tue, 15 Nov 2011 11:58:38 -0800,
Kamal Mostafa wrote:
[1 multipart/signed (7bit)]
[1.1 text/plain; UTF-8 (quoted-printable)]
On Mon, 2011-11-14 at 18:42 -0800, Alex Davis wrote:
From: Alex Davisalex14...@yahoo.com
This patch fixes an issue where the screen would remain dark when
a key was pressed when the laptop lid was reopened or after the
laptop had gone into power-save mode.
[cross-posting to intel-gfx]
Keith, also note that Alex and I did respond to your request to test the
already committed patch drm/i915/panel: Always record the backlight
level again (but cleverly). We both determined that patch does *not*
fix the problem. Alex's patch below does fix it.
My rough guess is the inconsistency of property taken during the
backlight disabled. How about the patch below (untested!) in addition
to the fix in 3.2?
Takashi
---
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 499d4c0..21f60b7 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -326,7 +326,8 @@ static int intel_panel_update_status(struct
backlight_device *bd)
static int intel_panel_get_brightness(struct backlight_device *bd)
{
struct drm_device *dev = bl_get_data(bd);
- return intel_panel_get_backlight(dev);
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ return dev_priv-backlight_level;
}
static const struct backlight_ops intel_panel_bl_ops = {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915: Fix bug where screen brightness is not restored
On Tue, 2011-11-15 at 21:28 +0100, Takashi Iwai wrote:
My rough guess is the inconsistency of property taken during the
backlight disabled. How about the patch below (untested!) in addition
to the fix in 3.2?
Takashi
Yes Takashi, your patch below (plus the already committed fix[0]) does
indeed fix the problem[1] for me. Thanks!
Tested-by: Kamal Mostafa ka...@canonical.com
-Kamal
[0] f52c619a590fa75276c07dfcaf380dee53e4ea4c
drm/i915/panel: Always record the backlight level again (but cleverly)
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/872652
---
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 499d4c0..21f60b7 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -326,7 +326,8 @@ static int intel_panel_update_status(struct
backlight_device *bd)
static int intel_panel_get_brightness(struct backlight_device *bd)
{
struct drm_device *dev = bl_get_data(bd);
- return intel_panel_get_backlight(dev);
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ return dev_priv-backlight_level;
}
static const struct backlight_ops intel_panel_bl_ops = {
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2 v2] hda - delayed ELD repoll
On Wed, Nov 16, 2011 at 01:10:37AM +0800, Takashi Iwai wrote:
At Wed, 16 Nov 2011 00:57:08 +0800,
Wu Fengguang wrote:
+static void hda_eld_work(struct work_struct *work)
+{
+ struct hdmi_eld *eld = container_of(
+ container_of(work, struct delayed_work, work),
+ struct hdmi_eld, work);
Ugh, hardly to read. Slightly better to use to_delayed_work()?
struct hdmi_eld *eld = container_of(to_delayed_work(work),
struct hdmi_eld, work);
Yeah that looks much better! Changed to:
+static void hdmi_repoll_eld(struct work_struct *work)
+{
+ struct hdmi_spec_per_pin *per_pin =
+ container_of(to_delayed_work(work), struct hdmi_spec_per_pin, work);
+
+ hdmi_present_sense(per_pin, false);
+}
+ struct hdmi_spec_per_pin *per_pin =
+ container_of(eld, struct hdmi_spec_per_pin, sink_eld);
+ struct hda_codec *codec = eld-codec;
+
+ hdmi_present_sense(codec, per_pin-pin_nid, eld, false);
+}
+
static int hdmi_add_pin(struct hda_codec *codec, hda_nid_t pin_nid)
{
struct hdmi_spec *spec = codec-spec;
@@ -1227,7 +1245,7 @@ static int generic_hdmi_build_jack(struc
if (err 0)
return err;
- hdmi_present_sense(codec, per_pin-pin_nid, per_pin-sink_eld);
+ hdmi_present_sense(codec, per_pin-pin_nid, per_pin-sink_eld, false);
...
Looking through the code, I wonder how about keeping work and codec
pointer in struct hdmi_spec_per_pin instead of struct hdmi_eld. Then
we don't need to expose it in hda_local.h, and changes would be
slightly more compact.
hdmi_present_sense() can be modified to receive hdmi_sepc_per_pin*
directly instead of individual nid and eld pointer.
Good idea! With the changes I get a much smaller patch :-)
I'll repost the patch series after some more testing.
Thanks,
Fengguang
---
Subject: hda - delayed ELD repoll
Date: Mon Nov 14 11:31:00 CST 2011
The Intel HDMI chips (ironlake at least) are found to have ~250ms delay
between the ELD_Valid=1 hotplug event is send and the ELD buffer becomes
actually readable. During the time the ELD buffer is mysteriously all 0.
Fix it by scheduling a delayed work to re-read ELD buffer after 300ms.
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
sound/pci/hda/patch_hdmi.c | 36 ---
1 file changed, 29 insertions(+), 7 deletions(-)
--- linux.orig/sound/pci/hda/patch_hdmi.c 2011-11-16 09:53:01.0
+0800
+++ linux/sound/pci/hda/patch_hdmi.c2011-11-16 10:33:06.0 +0800
@@ -65,7 +65,10 @@ struct hdmi_spec_per_pin {
hda_nid_t pin_nid;
int num_mux_nids;
hda_nid_t mux_nids[HDA_MAX_CONNECTIONS];
+
+ struct hda_codec *codec;
struct hdmi_eld sink_eld;
+ struct delayed_work work;
};
struct hdmi_spec {
@@ -745,8 +748,7 @@ static void hdmi_setup_audio_infoframe(s
* Unsolicited events
*/
-static void hdmi_present_sense(struct hda_codec *codec, hda_nid_t pin_nid,
- struct hdmi_eld *eld);
+static void hdmi_present_sense(struct hdmi_spec_per_pin *per_pin, bool retry);
static void hdmi_intrinsic_event(struct hda_codec *codec, unsigned int res)
{
@@ -766,7 +768,7 @@ static void hdmi_intrinsic_event(struct
return;
eld = spec-pins[pin_idx].sink_eld;
- hdmi_present_sense(codec, pin_nid, eld);
+ hdmi_present_sense(spec-pins[pin_idx], true);
/*
* HDMI sink's ELD info cannot always be retrieved for now, e.g.
@@ -968,9 +970,11 @@ static int hdmi_read_pin_conn(struct hda
return 0;
}
-static void hdmi_present_sense(struct hda_codec *codec, hda_nid_t pin_nid,
- struct hdmi_eld *eld)
+static void hdmi_present_sense(struct hdmi_spec_per_pin *per_pin, bool retry)
{
+ struct hda_codec *codec = per_pin-codec;
+ struct hdmi_eld *eld = per_pin-sink_eld;
+ hda_nid_t pin_nid = per_pin-pin_nid;
/*
* Always execute a GetPinSense verb here, even when called from
* hdmi_intrinsic_event; for some NVIDIA HW, the unsolicited
@@ -992,13 +996,27 @@ static void hdmi_present_sense(struct hd
HDMI status: Codec=%d Pin=%d Presence_Detect=%d
ELD_Valid=%d\n,
codec-addr, pin_nid, eld-monitor_present, eld_valid);
- if (eld_valid)
+ if (eld_valid) {
if (!snd_hdmi_get_eld(eld, codec, pin_nid))
snd_hdmi_show_eld(eld);
+ else if (retry) {
+ queue_delayed_work(codec-bus-workq,
+ per_pin-work,
+ msecs_to_jiffies(300));
+ }
+ }
snd_hda_input_jack_report(codec, pin_nid);
}
+static void hdmi_repoll_eld(struct work_struct *work)
+{
+ struct hdmi_spec_per_pin *per_pin =
+
Re: [Intel-gfx] [alsa-devel] [PATCH 2/2] hda - delayed ELD repoll
On Wed, Nov 16, 2011 at 02:25:00AM +0800, Stephen Warren wrote: Wu Fengguang wrote at Tuesday, November 15, 2011 7:33 AM: The Intel HDMI chips (ironlake at least) are found to have ~250ms delay between the ELD_Valid=1 hotplug event is send and the ELD buffer becomes actually readable. During the time the ELD buffer is mysteriously all 0. Fix it by scheduling a delayed work to re-read ELD buffer after 300ms. Any idea why; is the graphics driver writing the ELD data to the audio HW after triggering the unsolicited even rather than before, or something like that? Nope. The graphics driver is doing eld_valid = 0 write to eld buffer eld_valid = 1 250mS almost sounds like it's setting ELDV in the audio HW, then going and reading the EDID, then writing the EDID to the audio HW; perhaps the graphics driver is accidentally setting PRESENT+ELDV when it's meant to be setting just PRESENT, and later setting ELDV? From the debug dmesg, I'm pretty sure that the ELDV events are triggered exactly by the eld_valid = 0 and eld_valid = 1 register writes. Since the ELD data is already prepared, there is no EDID read in between. Below is the dmesg representing a video mode set. ELD writes from the graphics driver [ 424.254958] [drm:intel_write_eld], ELD on [CONNECTOR:12:HDMI-A-2], [ENCODER:11:TMDS-11] [ 424.257670] [drm:ironlake_write_eld], ELD on pipe B [ 424.259833] [drm:ironlake_write_eld], Audio directed to unknown port [ 424.262156] [drm:ironlake_write_eld], ELD size 13 ELD events received by audio driver (eld reads 0) [ 424.263258] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=0 [ 424.265877] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 424.272415] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 [ 424.274566] HDMI hot plug event: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 424.277027] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 424.283157] ALSA hda_eld.c:259 HDMI: Unknown ELD version 0 graphics driver go on with its job [ 424.314331] [drm:intel_wait_for_vblank], vblank wait timed out [ 424.367183] [drm:intel_wait_for_vblank], vblank wait timed out [ 424.368960] [drm:ironlake_update_wm], FIFO watermarks For pipe A - plane 5, cursor: 6 [ 424.370700] [drm:ironlake_update_wm], FIFO watermarks For pipe B - plane 42, cursor: 6 [ 424.424056] [drm:intel_wait_for_vblank], vblank wait timed out [ 424.476906] [drm:intel_wait_for_vblank], vblank wait timed out [ 424.479169] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x100 [ 424.481084] [drm:ironlake_fdi_link_train], FDI train 1 done. [ 424.483452] [drm:ironlake_fdi_link_train], FDI_RX_IIR 0x600 [ 424.485444] [drm:ironlake_fdi_link_train], FDI train 2 done. [ 424.486765] [drm:ironlake_fdi_link_train], FDI train done [ 424.490820] [drm:intel_update_fbc], [ 424.491841] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on [ 424.494449] [drm:drm_crtc_helper_set_config],[CONNECTOR:12:HDMI-A-2] set DPMS on [ 424.505904] [drm:intel_prepare_page_flip], preparing flip with no unpin work? audio driver repoll the ELD after 300ms (eld data readable now) [ 424.574763] HDMI status: Codec=3 Pin=6 Presence_Detect=1 ELD_Valid=1 [ 424.580867] HDMI: detected monitor RX-V1800 at connection type HDMI [ 424.582413] HDMI: available speakers: FL/FR LFE FC RL/RR RC RLC/RRC [ 424.584740] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 424.587429] HDMI: supports coding type LPCM: channels = 8, rates = 32000 44100 48000 96000 176400 192000 384000, bits = 16 20 24 [ 424.590968] HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 64 [ 424.594164] HDMI: supports coding type DTS: channels = 7, rates = 32000 44100 48000 96000 176400, max bitrate = 1536000 [ 424.597563] HDMI: supports coding type DSD (One Bit Audio): channels = 6, rates = 44100 [ 424.600284] HDMI: supports coding type E-AC-3/DD+ (Dolby Digital Plus): channels = 8, rates = 44100 48000 [ 424.602420] HDMI: supports coding type MLP (Dolby TrueHD): channels = 8, rates = 48000 176400 384000 [ 424.604478] HDMI: supports coding type DTS-HD: channels = 8, rates = 48000 176400 384000 Thanks, Fengguang ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/2] Introduce Glamor to UXA framework.
After discussion with Chris yesterday, I reworked the previous glamor branch and concentrate the patchset to two patches. The first patch is the same as the previous. The second patch merges all the others into one, and made some slightly change. One major change is that I decide to extent the finish_access to handle the flushing operations by check the access type. And also add some missed glamor flushing operations. This patchset initially enable glamor with UXA. And two functions ,fill_spans and poly_fill_rects, go to the glamor path. I tested it with render check, and it works fine. One of the remaining issues is the vsync'ed copy. I discussed with Chris, and already got a solution. Will do that when I enable the copy_area to glamor path. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] glamor: Initial commit to introduce glamor acceleration.
Added one configuration option --enable-glamor to control
whether use glamor. Added one new file intel_glamor.c to
wrap glamor egl API for intel driver's usage.
This commit doesn't really change the driver's control path.
It just adds necessary files for glamor and change some
configuration.
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
configure.ac | 17 +++
src/Makefile.am|5 ++
src/intel_glamor.c | 130
src/intel_glamor.h | 45 ++
4 files changed, 197 insertions(+), 0 deletions(-)
create mode 100644 src/intel_glamor.c
create mode 100644 src/intel_glamor.h
diff --git a/configure.ac b/configure.ac
index 831f6b3..d990702 100644
--- a/configure.ac
+++ b/configure.ac
@@ -126,6 +126,15 @@ AC_ARG_ENABLE(sna,
[SNA=$enableval],
[SNA=no])
AM_CONDITIONAL(SNA, test x$SNA != xno)
+
+AC_ARG_ENABLE(glamor,
+ AS_HELP_STRING([--enable-glamor],
+[Enable glamor, a new GL-based acceleration
[default=no]]),
+ [GLAMOR=$enableval],
+ [GLAMOR=no])
+
+AM_CONDITIONAL(GLAMOR, test x$GLAMOR != xno)
+
AC_MSG_CHECKING([whether to include SNA support])
required_xorg_xserver_version=1.6
@@ -137,6 +146,14 @@ if test x$SNA != xno; then
fi
AC_MSG_RESULT([$SNA])
+if test x$GLAMOR != xno; then
+ PKG_CHECK_MODULES(LIBGLAMOR, [glamor])
+ PKG_CHECK_MODULES(LIBGLAMOR_EGL, [glamor-egl])
+ AC_DEFINE(GLAMOR, 1, [Enable glamor acceleration])
+fi
+
+AC_MSG_CHECKING([whether to include GLAMOR support])
+AC_MSG_RESULT([$GLAMOR])
AC_ARG_ENABLE(vmap,
AS_HELP_STRING([--enable-vmap],
diff --git a/src/Makefile.am b/src/Makefile.am
index cd1bb36..1a29390 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -40,6 +40,10 @@ SUBDIRS += sna
intel_drv_la_LIBADD += sna/libsna.la
endif
+if GLAMOR
+GLAMOR_SOURCE = intel_glamor.c
+endif
+
NULL:=#
intel_drv_la_SOURCES = \
@@ -70,6 +74,7 @@ intel_drv_la_SOURCES = \
i965_3d.c \
i965_video.c \
i965_render.c \
+$(GLAMOR_SOURCE) \
$(NULL)
if DRI
diff --git a/src/intel_glamor.c b/src/intel_glamor.c
new file mode 100644
index 000..cadfc71
--- /dev/null
+++ b/src/intel_glamor.c
@@ -0,0 +1,130 @@
+/*
+ * Copyright © 2011 Intel Corporation.
+ *
+ * Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy,
+ * modify, merge, publish, distribute, sublicense, and/or sell copies
+ * of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including
+ * the next paragraph) shall be included in all copies or substantial
+ * portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Zhigang Gong zhigang.g...@linux.intel.com
+ *
+ */
+
+#ifdef HAVE_DIX_CONFIG_H
+#include dix-config.h
+#endif
+#include unistd.h
+#include fcntl.h
+#include sys/ioctl.h
+#include errno.h
+#include xf86drm.h
+
+#define GLAMOR_FOR_XORG 1
+
+#include glamor.h
+#include intel.h
+#include intel_glamor.h
+
+Bool
+intel_glamor_create_screen_resources(ScreenPtr screen)
+{
+ ScrnInfoPtr scrn = xf86Screens[screen-myNum];
+ intel_screen_private *intel = intel_get_screen_private(scrn);
+
+ if (!glamor_glyphs_init(screen))
+ return FALSE;
+ if (!glamor_egl_create_textured_screen(screen,
+ intel-front_buffer-handle,
+ intel-front_pitch))
+ return FALSE;
+ return TRUE;
+}
+
+Bool
+intel_glamor_pre_init(ScrnInfoPtr scrn)
+{
+ intel_screen_private *intel;
+ intel = intel_get_screen_private(scrn);
+ return glamor_egl_init(scrn, intel-drmSubFD);
+}
+
+Bool
+intel_glamor_create_textured_pixmap(PixmapPtr pixmap)
+{
+ struct intel_pixmap *priv;
+ priv = intel_get_pixmap_private(pixmap);
+ return glamor_egl_create_textured_pixmap(pixmap, priv-bo-handle,
+priv-stride);
+}
+
+void
+intel_glamor_destroy_pixmap(PixmapPtr pixmap)
+{
+ glamor_egl_destroy_textured_pixmap(pixmap);
+}
+
+Bool
[Intel-gfx] [PATCH 2/2] glamor: Turn on glamor with a few glamor functions enabled.
Integrate glamor acceleration into UXA framework. Add
necessary flushing at the following points:
1. Flush UXA batch buffer before call into glamor.
2. Flush GL operations after return from a glamor function.
3. The point we need to flush UXA batch buffer, we also
need to flush GL operations, for example, in
intel_flush_callback and couple of places in intel_display.c.
This commit only enables two glamor functions for
fill_spans and poly_fill_rects. Will continue to enable the
reset glamor functions soon.
Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
src/Makefile.am |6 +--
src/intel.h |1 +
src/intel_display.c |5 ++
src/intel_driver.c | 17 +++-
src/intel_glamor.c | 111 ++-
src/intel_glamor.h |2 +-
src/intel_uxa.c | 22 +-
uxa/uxa-accel.c | 38 +++--
uxa/uxa-priv.h |4 +-
uxa/uxa-render.c| 16
uxa/uxa-unaccel.c | 58 +-
uxa/uxa.c | 18
uxa/uxa.h | 13 +-
13 files changed, 236 insertions(+), 75 deletions(-)
diff --git a/src/Makefile.am b/src/Makefile.am
index 1a29390..12ff6ee 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -40,10 +40,6 @@ SUBDIRS += sna
intel_drv_la_LIBADD += sna/libsna.la
endif
-if GLAMOR
-GLAMOR_SOURCE = intel_glamor.c
-endif
-
NULL:=#
intel_drv_la_SOURCES = \
@@ -74,7 +70,7 @@ intel_drv_la_SOURCES = \
i965_3d.c \
i965_video.c \
i965_render.c \
-$(GLAMOR_SOURCE) \
+intel_glamor.c \
$(NULL)
if DRI
diff --git a/src/intel.h b/src/intel.h
index 3b3f87d..b24aa02 100644
--- a/src/intel.h
+++ b/src/intel.h
@@ -318,6 +318,7 @@ typedef struct intel_screen_private {
void (*batch_commit_notify) (struct intel_screen_private *intel);
uxa_driver_t *uxa_driver;
+ int uxa_flags;
Bool need_sync;
int accel_pixmap_offset_alignment;
int accel_max_x;
diff --git a/src/intel_display.c b/src/intel_display.c
index 84c7c08..f6ffa30 100644
--- a/src/intel_display.c
+++ b/src/intel_display.c
@@ -43,6 +43,8 @@
#include xf86drmMode.h
#include X11/Xatom.h
+#include intel_glamor.h
+
struct intel_mode {
int fd;
uint32_t fb_id;
@@ -451,6 +453,7 @@ intel_crtc_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr
mode,
crtc-y = y;
crtc-rotation = rotation;
+ intel_glamor_flush(intel);
intel_batch_submit(crtc-scrn);
mode_to_kmode(crtc-scrn, intel_crtc-kmode, mode);
@@ -1368,6 +1371,7 @@ intel_xf86crtc_resize(ScrnInfoPtr scrn, int width, int
height)
if (scrn-virtualX == width scrn-virtualY == height)
return TRUE;
+ intel_glamor_flush(intel);
intel_batch_submit(scrn);
old_width = scrn-virtualX;
@@ -1457,6 +1461,7 @@ intel_do_pageflip(intel_screen_private *intel,
new_front-handle, mode-fb_id))
goto error_out;
+ intel_glamor_flush(intel);
intel_batch_submit(scrn);
/*
diff --git a/src/intel_driver.c b/src/intel_driver.c
index 24696da..ddeb40f 100644
--- a/src/intel_driver.c
+++ b/src/intel_driver.c
@@ -75,6 +75,8 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
#include i915_drm.h
#include xf86drmMode.h
+#include intel_glamor.h
+
/* *INDENT-OFF* */
/*
* Note: ColorKey is provided for compatibility with the i810 driver.
@@ -712,6 +714,13 @@ static Bool I830PreInit(ScrnInfoPtr scrn, int flags)
return FALSE;
}
+ if (!intel_glamor_pre_init(scrn)) {
+ PreInitCleanup(scrn);
+ xf86DrvMsg(scrn-scrnIndex, X_ERROR,
+ Failed to pre init glamor display.\n);
+ return FALSE;
+ }
+
/* Load the dri2 module if requested. */
if (intel-directRenderingType != DRI_DISABLED)
xf86LoadSubModule(scrn, dri2);
@@ -813,8 +822,10 @@ intel_flush_callback(CallbackListPtr *list,
pointer user_data, pointer call_data)
{
ScrnInfoPtr scrn = user_data;
- if (scrn-vtSema)
+ if (scrn-vtSema) {
intel_batch_submit(scrn);
+ intel_glamor_flush(intel_get_screen_private(scrn));
+ }
}
#if HAVE_UDEV
@@ -1110,6 +1121,8 @@ static void I830FreeScreen(int scrnIndex, int flags)
ScrnInfoPtr scrn = xf86Screens[scrnIndex];
intel_screen_private *intel = intel_get_screen_private(scrn);
+ intel_glamor_free_screen(scrnIndex, flags);
+
if (intel) {
intel_mode_fini(intel);
intel_close_drm_master(intel);
@@ -1189,6 +1202,8 @@ static Bool I830CloseScreen(int scrnIndex, ScreenPtr
screen)
DeleteCallback(FlushCallback, intel_flush_callback, scrn);
+ intel_glamor_close_screen(screen);
+
if (intel-uxa_driver) {
uxa_driver_fini(screen);
