https://bugs.freedesktop.org/show_bug.cgi?id=27314
Alex Deucher changed:
What|Removed |Added
Summary|DP link training fails on |displayport link training
https://bugs.freedesktop.org/show_bug.cgi?id=27314
Alex Deucher changed:
What|Removed |Added
CC||merl...@wajer.org
--- Comment #33 from Al
https://bugzilla.kernel.org/show_bug.cgi?id=30922
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #1 f
https://bugzilla.kernel.org/show_bug.cgi?id=30922
--- Comment #2 from Alex Deucher 2011-03-15 07:30:38
---
Laptops generally expose the GPU temperature via an acpi thermal zone or an oem
specific sensor.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You
On 03/14/11 23:20, Alex Deucher wrote:
> On Sun, Mar 13, 2011 at 10:08 AM, Anders Eriksson
> wrote:
>> Hi,
>>
>> I've found what I guess is a radeon (or drm/kms) regression post 2.6.35.
>> I've got my TV conneced to my RS690G over HDMI, and the display has
>> always been jittery after POST and
On Mon, 2011-03-14 at 12:50 +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> So we used to use lpfn directly to restrict VRAM when we couldn't
> access the unmappable area, however this was removed in
> 93225b0d7bc030f4a93165347a65893685822d70 as it also restricted
> the gtt placements. However
> Does this patch help?
>
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index 1d89259..a2bd944 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -524,7 +524,7 @@ static u32 atombios_adjust
On Tue, 15 Mar 2011 02:18:02 +0100 (CET), "Indan Zupancic" wrote:
> Hello,
>
> Some nitpicks below.
>
> On Mon, March 14, 2011 18:59, Chris Wilson wrote:
> > Note: neither the opregion_dev interface or the alse_set_* properly report
> > failures. As such we have a slight change in behaviour on I
On Tue, March 15, 2011 09:37, Chris Wilson wrote:
> On Tue, 15 Mar 2011 02:18:02 +0100 (CET), "Indan Zupancic"
> wrote:
>> Hello,
>>
>> Some nitpicks below.
>>
>> On Mon, March 14, 2011 18:59, Chris Wilson wrote:
>> > Note: neither the opregion_dev interface or the alse_set_* properly report
>> >
Indan Zupancic wrote:
> Everything would be a lot simpler if the BIOSes were open source.
coreboot has existed for about eleven years and some 250 mainboards of
varying shapes and sizes (from laptop to server) are supported, but it's
only just recently that things are really taking off, with the c
As detect will use hw registers and may modify structures, it needs to be
serialised by use of the dev->mode_config.mutex. Make it so.
Otherwise, we may cause random crashes as the sysfs file is queried
whilst a concurrent hotplug poll is being run. For example:
[ 1189.189626] BUG: unable to hand
Usually EDID retrieval is fine. However, sometimes, especially when the
machine is loaded, it fails, but succeeds after a few retries.
Based on a patch by Michael Buesch.
Reported-by: Michael Buesch
Signed-off-by: Chris Wilson
---
I was going to suggest tuning the i2c_adapter.retries of the af
On Tue, March 15, 2011 12:27, Peter Stuge wrote:
> coreboot has existed for about eleven years and some 250 mainboards of
> varying shapes and sizes (from laptop to server) are supported, but it's
I've been wanting to get rid of BIOSes and use Coreboot for ages,
but the amount of hassle needed to
On Tue, Mar 15, 2011 at 11:40:00 +, Chris Wilson wrote:
> [Digression: what is upowerd doing reading those power hungry files?]
>
Apparently, checking "docked" status every 30 seconds, by reading the
status of drm outputs. Where "docked" means "more than one output
connected". Yes, it's sil
On Tue, Mar 15, 2011 at 02:30:55PM +0100, Olivier Galibert wrote:
> On Tue, Mar 15, 2011 at 01:52:26AM +, Matthew Garrett wrote:
> > Now that we've got multiple consumers it's probably not helpful to move
> > the (potentially chip-specific) VBT handling to general code. We've got
> > zero doc
On Tue, Mar 15, 2011 at 02:40:59PM +0100, Olivier Galibert wrote:
> On Tue, Mar 15, 2011 at 01:32:40PM +, Matthew Garrett wrote:
> > Opregion is one mechanism to provide VBT - it doesn't define it.
>
> Then let me repeat that I haven't seen anything in the VBT tables of
> the gma500-using netb
On Tue, Mar 15, 2011 at 01:52:26AM +, Matthew Garrett wrote:
> Now that we've got multiple consumers it's probably not helpful to move
> the (potentially chip-specific) VBT handling to general code. We've got
> zero documentation on how GMA500 handles VBT, and not a great deal more
> for i91
On Tue, Mar 15, 2011 at 01:32:40PM +, Matthew Garrett wrote:
> Opregion is one mechanism to provide VBT - it doesn't define it.
Then let me repeat that I haven't seen anything in the VBT tables of
the gma500-using netbook I have that didn't seem to be parsed
correctly by the current gpu/drm/i9
https://bugs.freedesktop.org/show_bug.cgi?id=33515
--- Comment #12 from rockm...@gmail.com 2011-03-15 08:22:42 PDT ---
Seems the patch works!
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for t
On Tue, 15 Mar 2011 11:40:00 +
Chris Wilson wrote:
> As detect will use hw registers and may modify structures, it needs to be
> serialised by use of the dev->mode_config.mutex. Make it so.
>
> Otherwise, we may cause random crashes as the sysfs file is queried
> whilst a concurrent hotplug
https://bugs.freedesktop.org/show_bug.cgi?id=33515
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=35183
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Tue, Mar 15, 2011 at 7:46 AM, Indan Zupancic wrote:
> On Tue, March 15, 2011 12:27, Peter Stuge wrote:
>> coreboot has existed for about eleven years and some 250 mainboards of
>> varying shapes and sizes (from laptop to server) are supported, but it's
>
> I've been wanting to get rid of BIOSes
https://bugs.freedesktop.org/show_bug.cgi?id=35254
--- Comment #5 from Michael Larabel 2011-03-15 09:43:56
PDT ---
Just got around to test the 2.6.38 final kernel and the system ends up going
down completely - Padman loading screen -> blank screen for ~2 seconds -> BIOS
screen as the system just
On Tue, Mar 15, 2011 at 7:04 AM, Chris Wilson wrote:
> Usually EDID retrieval is fine. However, sometimes, especially when the
> machine is loaded, it fails, but succeeds after a few retries.
>
> Based on a patch by Michael Buesch.
>
> Reported-by: Michael Buesch
> Signed-off-by: Chris Wilson
L
On 03/14/11 23:22, Alex Deucher wrote:
> On Mon, Mar 14, 2011 at 6:20 PM, Alex Deucher wrote:
> > On Sun, Mar 13, 2011 at 10:08 AM, Anders Eriksson
> > wrote:
> >> Hi,
> >>
> >> I've found what I guess is a radeon (or drm/kms) regression post 2.6.35.
> >> I've got my TV conneced to my RS690G o
On Tue, Mar 15, 2011 at 4:58 PM, Anders Eriksson wrote:
> On 03/14/11 23:22, Alex Deucher wrote:
>> On Mon, Mar 14, 2011 at 6:20 PM, Alex Deucher wrote:
>> > On Sun, Mar 13, 2011 at 10:08 AM, Anders Eriksson
>> > wrote:
>> >> Hi,
>> >>
>> >> I've found what I guess is a radeon (or drm/kms) re
On Tue, Mar 15, 2011 at 4:58 PM, Anders Eriksson wrote:
> On 03/14/11 23:22, Alex Deucher wrote:
>> On Mon, Mar 14, 2011 at 6:20 PM, Alex Deucher wrote:
>> > On Sun, Mar 13, 2011 at 10:08 AM, Anders Eriksson
>> > wrote:
>> >> Hi,
>> >>
>> >> I've found what I guess is a radeon (or drm/kms) re
On Tue, 2011-03-15 at 11:04 +, Chris Wilson wrote:
> Usually EDID retrieval is fine. However, sometimes, especially when the
> machine is loaded, it fails, but succeeds after a few retries.
>
> Based on a patch by Michael Buesch.
>
> Reported-by: Michael Buesch
> Signed-off-by: Chris Wilson
On Tue, 2011-03-15 at 13:31 +0100, Julien Cristau wrote:
> On Tue, Mar 15, 2011 at 11:40:00 +, Chris Wilson wrote:
>
> > [Digression: what is upowerd doing reading those power hungry files?]
> >
> Apparently, checking "docked" status every 30 seconds, by reading the
> status of drm outputs.
On Tue, March 15, 2011 17:06, Alex Deucher wrote:
> On Tue, Mar 15, 2011 at 7:46 AM, Indan Zupancic wrote:
>> They don't give their Linux devs any Fusion hardware, nor do they
>> open the UVD spec, but at least they release info like this.
>
> They do give us fusion hw; before launch even. That's
On Tue, Mar 15, 2011 at 8:02 PM, Indan Zupancic wrote:
> On Tue, March 15, 2011 17:06, Alex Deucher wrote:
>> On Tue, Mar 15, 2011 at 7:46 AM, Indan Zupancic wrote:
>>> They don't give their Linux devs any Fusion hardware, nor do they
>>> open the UVD spec, but at least they release info like thi
>
> Read the changelog and thread on the patch that disabled this logic, the
> failure (or at least inconsistent behaviour with the expectations of the
> HP BIOS authors) appears to be in how we initialise ACPI on the HP
> machines that causes the initial value of lid state to be incorrect. Since
>
On Wed, March 16, 2011 03:17, Alex Deucher wrote:
> It's not HDCP, encrypted bluray is the main issue. And while
> there are hacks for bluray around already, contractual obligations
> don't care whether existing hacks are available or not.
So the contract says to keep it secret, not to make it se
34 matches
Mail list logo
