On Mon, Sep 09, 2013 at 11:32:10AM +0200, Daniel Vetter wrote:
> Hi Aaaron,
>
> Have we grown any clue meanwhile about which Intel boxes need this and for
> which we still need to keep the acpi backlight around? I've grown _very_
Sorry, no general rule has been found. As Rafael has said, it appea
On 09/10/2013 01:22 PM, Igor Gnatenko wrote:
> On Tue, 2013-09-10 at 13:16 +0800, Aaron Lu wrote:
>> On 09/10/2013 01:13 PM, Igor Gnatenko wrote:
>>> On Tue, 2013-09-10 at 11:27 +0800, Aaron Lu wrote:
On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
> On Mon, 2013-09-09 at 16:42 +0800, Aaron L
Replace "%8x" with "%08x".
The hex number should be shown with zero stuffed instead of spaces.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i9
On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
> According to Matthew Garrett, "Windows 8 leaves backlight control up
> to individual graphics drivers rather than making ACPI calls itself.
> There's plenty of evidence to suggest that the Intel driver for
> Windows [8] doesn't use the ACPI inte
On Mon, 2013-09-09 at 16:40 +0800, Aaron Lu wrote:
> The backlight control and event delivery functionality provided by ACPI
> video module is mixed together and registered all during video device
> enumeration time. As a result, the two functionality are also removed
> together on module unload t
On Tue, 2013-09-10 at 13:16 +0800, Aaron Lu wrote:
> On 09/10/2013 01:13 PM, Igor Gnatenko wrote:
> > On Tue, 2013-09-10 at 11:27 +0800, Aaron Lu wrote:
> >> On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
> >>> On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
> diff --git a/drivers/gpu/drm/i91
On 09/10/2013 01:13 PM, Igor Gnatenko wrote:
> On Tue, 2013-09-10 at 11:27 +0800, Aaron Lu wrote:
>> On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
>>> On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c
ind
On Tue, 2013-09-10 at 11:27 +0800, Aaron Lu wrote:
> On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
> > On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
> >> diff --git a/drivers/gpu/drm/i915/i915_dma.c
> >> b/drivers/gpu/drm/i915/i915_dma.c
> >> index f466980..75fba17 100644
> >> --- a/drivers/gp
On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
> On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_dma.c
>> b/drivers/gpu/drm/i915/i915_dma.c
>> index f466980..75fba17 100644
>> --- a/drivers/gpu/drm/i915/i915_dma.c
>> +++ b/drivers/gpu/drm/i915/i915_dma.c
From: Mengdong Lin
The PCH transcoder config register (PCH_TRANS_CONF, 0xf0008) is not the
correct config register for transcoder A, B or C. This register is in
PCH and for CRT display, nothing to do with display audio.
So This patch removes misuse of it as config register for transcoder A/B/C.
From: Mengdong Lin
For Haswell, some audio configuration registers have changed their name and
some bit definitions.
This patch applies the changes, and uses subfunctions to parse registers for
code reuse.
Here is the name change list:
Audio configuration: AUD_CONFIG_x to AUD_TCx_CONFIG
Audio M
From: Mengdong Lin
Three patches are included, reviewed by Haihao, Xiang.
Mengdong Lin (3):
intel_audio_dump/hsw: remove misuse of PCH transcoder configuration
register
intel_audio_dump/hsw: align code with tab
intel_audio_dump/hsw: rename some audio configuration registers for
Has
On Monday, September 09, 2013 05:21:18 PM Daniel Vetter wrote:
> On Mon, Sep 09, 2013 at 02:16:12PM +0200, Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Monday, September 09, 2013 11:32:10 AM Daniel Vetter wrote:
> > > Hi Aaaron,
> > >
> > > Have we grown any clue meanwhile about which Intel boxes
On Mon, 2013-09-09 at 17:21 +0200, Daniel Vetter wrote:
> If Win8 is as broken as we are I'm ok with the module option. It just
> sounded to me like right now we don't know of a way to make all machines
> somewhat happy, combined with the other pile of random backlight issues
> the assumption that
On Mon, Sep 09, 2013 at 02:16:12PM +0200, Rafael J. Wysocki wrote:
> Hi,
>
> On Monday, September 09, 2013 11:32:10 AM Daniel Vetter wrote:
> > Hi Aaaron,
> >
> > Have we grown any clue meanwhile about which Intel boxes need this and for
> > which we still need to keep the acpi backlight around?
Hi,
On Monday, September 09, 2013 11:32:10 AM Daniel Vetter wrote:
> Hi Aaaron,
>
> Have we grown any clue meanwhile about which Intel boxes need this and for
> which we still need to keep the acpi backlight around?
First of all, there is a bunch of boxes where ACPI backlight works incorrectly
b
On 09.09.2013 11:53, Daniel Vetter wrote:
On Mon, Sep 9, 2013 at 11:39 AM, Chris Wilson wrote:
On Mon, Sep 09, 2013 at 11:34:19AM +0200, Knut Petersen wrote:
Problem:
===
Your changes to i915_stolen_to_physical() (commit:
eaba1b8f3379b5d100bd146b9a41d28348bdfd09) expose the following pro
On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index f466980..75fba17 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1650,7 +1650,7 @@ int i915_driver_load(struct drm
From: Ville Syrjälä
Now that adjusted_mode.clock no longer contains the pixel_multiplier, we
can kill the get_clock() callback and instead do the clock readout
in get_pipe_config().
Also i9xx_crtc_clock_get() can now extract the frequency of the PCH
DPLL, so use it to populate port_clock accurat
From: Ville Syrjälä
Add the 120MHz refernce clock case for PCH DPLLs.
Also determine the reference clock frequency more accurately by
checking for the PLLB_REF_INPUT_SPREADSPECTRUMIN refclk input
mode. The gen2 code already checked it, but it stil assumed a
fixed 66MHz refclk. Instead we need to
From: Ville Syrjälä
Now that adjusted_mode.clock no longer contains the pixel_multiplier, we
can kill the get_clock() callback and instead do the clock readout
in get_pipe_config().
Also i9xx_crtc_clock_get() can now extract the frequency of the PCH
DPLL, so use it to populate port_clock accurat
On Mon, Sep 9, 2013 at 11:39 AM, Chris Wilson wrote:
> On Mon, Sep 09, 2013 at 11:34:19AM +0200, Knut Petersen wrote:
>> Problem:
>> ===
>>
>> Your changes to i915_stolen_to_physical() (commit:
>> eaba1b8f3379b5d100bd146b9a41d28348bdfd09) expose the following problem
>>
>> [2.272218] [drm
On Mon, Sep 09, 2013 at 11:34:19AM +0200, Knut Petersen wrote:
> Problem:
> ===
>
> Your changes to i915_stolen_to_physical() (commit:
> eaba1b8f3379b5d100bd146b9a41d28348bdfd09) expose the following problem
>
> [2.272218] [drm:i915_stolen_to_physical] *ERROR* conflict detected with
> s
Problem:
===
Your changes to i915_stolen_to_physical() (commit:
eaba1b8f3379b5d100bd146b9a41d28348bdfd09) expose the following problem
[2.272218] [drm:i915_stolen_to_physical] *ERROR* conflict detected with
stolen region: [0x7f80 - 0x8000]
Related bug reports:
==
Hi Aaaron,
Have we grown any clue meanwhile about which Intel boxes need this and for
which we still need to keep the acpi backlight around? I've grown _very_
reluctant to just adding tons of quirks to our driver for the backlight.
Almost all the quirks we have added recently (or that have been pr
On Sun, Sep 08, 2013 at 09:57:13PM +0200, Daniel Vetter wrote:
> My g33 here seems to be shockingly good at hitting them all. This time
> around kms_flip/flip-vs-panning-vs-hang blows up:
>
> intel_crtc_wait_for_pending_flips correctly checks for gpu hangs and
> if a gpu hang is pending aborts the
On Tue, Sep 03, 2013 at 08:31:59AM +0800, Zhang Rui wrote:
> acpi_has_method() is a new ACPI API introduced to check
> the existence of an ACPI control method.
>
> It can be used to replace acpi_get_handle() in the case that
> 1. the calling function doesn't need the ACPI handle of the control met
According to Matthew Garrett, "Windows 8 leaves backlight control up
to individual graphics drivers rather than making ACPI calls itself.
There's plenty of evidence to suggest that the Intel driver for
Windows [8] doesn't use the ACPI interface, including the fact that
it's broken on a bunch of mac
The backlight control and event delivery functionality provided by ACPI
video module is mixed together and registered all during video device
enumeration time. As a result, the two functionality are also removed
together on module unload time or by the acpi_video_unregister function.
The two functi
The ACPI video module provides two functionalities: backlight control
and backlight hotkey event delivery. It is possible the backlight
control interface is broken while the system still needs its event
delivery, so it's worth to seperate the two interfaces clearly.
This patchset has two patches,
30 matches
Mail list logo
