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, f
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.
Revie
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 f
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.
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_wor
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])
At Tue, 15 Nov 2011 11:58:38 -0800,
Kamal Mostafa wrote:
>
> [1 ]
> [1.1 ]
> On Mon, 2011-11-14 at 18:42 -0800, Alex Davis wrote:
> > From: Alex Davis
> >
> > This patch fixes an issue where the screen would remain dark when
> >
> > a key was pressed when the laptop lid was reopened or after t
On Mon, 2011-11-14 at 18:42 -0800, Alex Davis wrote:
> From: Alex Davis
>
> 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
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 va
If it failed, leave it in the "off" state.
Signed-off-by: Jesse Barnes
---
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
If a PCH pipe PLL is being used by transcoder C, don't disable it.
Signed-off-by: Jesse Barnes
---
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.
> -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,
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
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-o
> - 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,
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 el
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 t
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->e
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 ot
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-o
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 Fengguan
On Tue, 15 Nov 2011 20:54:13 +0800, "Zhigang Gong"
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 t
> -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,
On Tue, 15 Nov 2011 19:36:14 +0800, Zhigang Gong
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 la
On Tue, 15 Nov 2011 19:36:13 +0800, Zhigang Gong
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 dr
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 U
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
---
src/Makefile.am|6 +---
src/intel_driver.c | 25 +
src/intel_glamor.c | 75
27 matches
Mail list logo
