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
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
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
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
-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
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
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
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.
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
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.
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
- 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,
+
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.
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,
-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
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
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
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
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]
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
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
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),
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.
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
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.
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,
26 matches
Mail list logo
