[Bug 27314] displayport link training fails on certain panels (channel equalization fails)
https://bugs.freedesktop.org/show_bug.cgi?id=27314 Alex Deucher changed: What|Removed |Added Summary|DP link training fails on |displayport link training |2560x1440 panels|fails on certain panels ||(channel equalization ||fails) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27314] displayport link training fails on certain panels (channel equalization fails)
https://bugs.freedesktop.org/show_bug.cgi?id=27314 Alex Deucher changed: What|Removed |Added CC||merl...@wajer.org --- Comment #33 from Alex Deucher 2011-03-15 00:11:48 PDT --- *** Bug 35179 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30922] [radeon] Noisy fan with Radeon R600 and Toshiba Satellite L500-164
https://bugzilla.kernel.org/show_bug.cgi?id=30922 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher 2011-03-15 07:29:57 --- For more information about the power management options in the driver, see the "KMS Power Management Options" section of this page: http://wiki.x.org/wiki/RadeonFeature -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30922] [radeon] Noisy fan with Radeon R600 and Toshiba Satellite L500-164
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 are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Radeon jittery post 2.6.35
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 at the GRUB screen. Pre-KMS, the X >> server (or driver got it sorted), and when KMS started, the display >> stabilized right after the kernel driver was initiated. However, post >> 2.6.35, I see the jitter is back. >> >> I've spent the last month trying to bisect it, but pretty much failed. >> It appears that versions closer to 2.6.38-rcX are more prone to display >> jitter, while 2.6.36 or so can have many successful runs. It also >> appears to be related to device power-on order, or so I've come to >> believe; A stable display can turn jittery, just by power cycling the TV. >> >> I've uploaded a video of a 38-rc8 boot: >> http://www.easy-share.com/1914220540/2.6.38-rc8_bad_x.mp4 >> >> You'll see jitter at the POST screen and GRUB. When KMS kicks in it >> stabilizes, and when Freevo starts X, it's back to jitter. > Does plain X or gnome/kde jitter too or just freevo? > Yes. A plain xinit with an xterm without window manager shows the same thing. (I run freevo on on X, not fb) Btw, These are the X packages I use: libXxf86misc-1.0.3 libXxf86dga-1.1.2 libXxf86vm-1.1.1 xf86dga-1.0.3 xf86vidmodeproto-2.3.1 xf86miscproto-0.9.3 xf86dgaproto-2.1 xf86bigfontproto-1.2.0 xf86driproto-2.1.1 xf86rushproto-1.1.2 xf86-input-evdev-2.6.0 xf86-video-ati-6.14.0 xf86-input-keyboard-1.5.0 xf86-input-mouse-1.6.0 > Alex > >> The jitter is always of the same kind. It looks like an old tv set which >> loses sync. The contents on the display is, for a split second, placed >> at the wrong part of the screen (vertically and to some extent >> horizontally), and every 5-15 seconds or so, there is a big reset when >> the TV tries to restart things (I guess). At the resets, thee is a loud >> 'ping' in the nearby stereo too... >> >> During the bisect (and a t 38-rc8) I've seen this both at the console >> (post KMS) and in X, so I'm not sure where the error is. I hope some of >> you can get a better idea of where to hunt for the bug by looking at the >> video. >> >> -Anders >> ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix problem with changing active VRAM size. (v2)
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 it was only later noticed that this > broke on some hw. > > This removes the active_vram_size, and just explicitly sets it > when it changes, TTM/drm_mm will always use the real_vram_size, > and the active vram size will change the TTM size used for lpfn > setting. > > We should re-work the fpfn/lpfn to per-placement at some point > I suspect, but that is too late for this kernel. > > Hopefully this addresses: > https://bugs.freedesktop.org/show_bug.cgi?id=35254 > > v2: fix reported useful VRAM size to userspace to be correct. > > Signed-off-by: Dave Airlie Looks good, Dave. Thanks for getting rid of one of the *_vram_size fields, those were getting out of hand. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Radeon jittery post 2.6.35
> 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_pll(struct drm_crtc *crtc, > if ((rdev->family == CHIP_RS600) || > (rdev->family == CHIP_RS690) || > (rdev->family == CHIP_RS740)) > - pll->flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/ > + pll->flags |= (RADEON_PLL_USE_FRAC_FB_DIV | >RADEON_PLL_PREFER_CLOSEST_LOWER); > > if (ASIC_IS_DCE32(rdev) && mode->clock > 20) > /* range limits??? */ No. No improvement on rc8. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] ACPI/Intel: Rework Opregion support
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 Ironlake+ > > platforms and an uncorrected bug for earlier chipsets. > > -Chris > > What uncorrected bug? For later chipsets we currently report the failure to respond to the ALSE requests, for earlier we do not. The patch harmonises the two code paths reusing the earlier code for later chipsets, hence the change in behaviour and potential regression. Alternatively, actually reporting the failure for earlier chipsets may also break existing setups. > And are there earlier chipsets with ASLE support at all, besides gen 4? > If there are no gen 2 or gen 3 chipsets with ASLE then the backlight > code can be simplified further. The OpRegion interface was devised midway through gen3 (afaik), and you find it on some i915-class hw and not others. In theory, there is nothing to prevent a BIOS/ACPI from being rewritten for it to be of use in gen2, and who knows one such beast may already exist (considering much to our horror you can still buy gen2 chipsets). > > diff --git a/drivers/gpu/drm/i915/intel_panel.c > > b/drivers/gpu/drm/i915/intel_panel.c > > index 4e5ff59..51565bb 100644 > > --- a/drivers/gpu/drm/i915/intel_panel.c > > +++ b/drivers/gpu/drm/i915/intel_panel.c > > @@ -261,8 +261,8 @@ intel_panel_detect(struct drm_device *dev) > > * appears to be either the BIOS or Linux ACPI fault */ > > #if 0 > > /* Assume that the BIOS does not lie through the OpRegion... */ > > - if (dev_priv->opregion.lid_state) > > - return ioread32(dev_priv->opregion.lid_state) & 0x1 ? > > + if (dev_priv->opregion_dev.opregion.acpi) > > + return ioread32(&dev_priv->opregion_dev.opregion.acpi->clid) & > > 0x1 ? > > What guarantees that opregion.acpi != NULL here? You mean other than the explicit test for opregion.acpi != NULL? > Or perhaps just remove that #if 0 code chunk altogether? 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 one of the laptops that Dave tests drm-next on is a HP, he was bitten by the bug and temporarily (we hope) disabled the logic. Or else once again, we will continue to light up the panel on a closed laptop. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] ACPI/Intel: Rework Opregion support
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 >> > failures. As such we have a slight change in behaviour on Ironlake+ >> > platforms and an uncorrected bug for earlier chipsets. >> > -Chris >> >> What uncorrected bug? > > For later chipsets we currently report the failure to respond to the ALSE > requests, for earlier we do not. The patch harmonises the two code paths > reusing the earlier code for later chipsets, hence the change in behaviour > and potential regression. Alternatively, actually reporting the failure > for earlier chipsets may also break existing setups. Ah, okay, for the ASLE_SET_ALS_ILLUM/ASLE_SET_PFIT/ASLE_SET_PWM_FREQ cases. Hopefully this change doesn't cause regressions, that would be sad. >> And are there earlier chipsets with ASLE support at all, besides gen 4? >> If there are no gen 2 or gen 3 chipsets with ASLE then the backlight >> code can be simplified further. > > The OpRegion interface was devised midway through gen3 (afaik), and you > find it on some i915-class hw and not others. In theory, there is nothing > to prevent a BIOS/ACPI from being rewritten for it to be of use in gen2, > and who knows one such beast may already exist (considering much to our > horror you can still buy gen2 chipsets). Pity, if they're still sold any bets are off. >> > diff --git a/drivers/gpu/drm/i915/intel_panel.c >> > b/drivers/gpu/drm/i915/intel_panel.c >> > index 4e5ff59..51565bb 100644 >> > --- a/drivers/gpu/drm/i915/intel_panel.c >> > +++ b/drivers/gpu/drm/i915/intel_panel.c >> > @@ -261,8 +261,8 @@ intel_panel_detect(struct drm_device *dev) >> > * appears to be either the BIOS or Linux ACPI fault */ >> > #if 0 >> >/* Assume that the BIOS does not lie through the OpRegion... */ >> > - if (dev_priv->opregion.lid_state) >> > - return ioread32(dev_priv->opregion.lid_state) & 0x1 ? >> > + if (dev_priv->opregion_dev.opregion.acpi) >> > + return ioread32(&dev_priv->opregion_dev.opregion.acpi->clid) & >> > 0x1 ? >> >> What guarantees that opregion.acpi != NULL here? > > You mean other than the explicit test for opregion.acpi != NULL? I'm blind. I checked all the rest of the code, but not the line just above it. Gah! >> Or perhaps just remove that #if 0 code chunk altogether? > > Read the changelog and thread on the patch that disabled this logic, the I just subscribed to intel-gfx, seemed like a good idea after the reject. > 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 > one of the laptops that Dave tests drm-next on is a HP, he was bitten by > the bug and temporarily (we hope) disabled the logic. Or else once again, > we will continue to light up the panel on a closed laptop. Hopefully it's fixed by the next BIOS upgrade by HP... Everything would be a lot simpler if the BIOSes were open source. It's shocking with what you guys have to deal with. Good luck and thanks for all the hard work! Indan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] ACPI/Intel: Rework Opregion support
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 code release from AMD to initialize their most recent Fusion platform. http://www.coreboot.org/Welcome_to_coreboot http://blogs.amd.com/work/2011/02/28/amd-coreboot/ http://news.slashdot.org/story/11/03/04/1736241/AMD-Provides-Fusion-Support-For-Coreboot //Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Hold the mode mutex whilst probing for sysfs status
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 handle kernel NULL pointer dereference at 0100
[ 1189.189821] IP: [] intel_tv_detect_type+0xa2/0x203 [i915]
[ 1189.190020] *pde =
[ 1189.190104] Oops: [#1] SMP
[ 1189.190209] last sysfs file:
/sys/devices/pci:00/:00:02.0/drm/card0/card0-SVIDEO-1/status
[ 1189.190412] Modules linked in: mperf cpufreq_conservative cpufreq_userspace
cpufreq_powersave cpufreq_stats decnet uinput fuse loop joydev snd_hd
a_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss
snd_pcm i915 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq drm_kms_helper
snd_timer uvcvideo d rm snd_seq_device eeepc_laptop tpm_tis usbhid videodev
i2c_algo_bit v4l1_compat snd sparse_keymap i2c_core hid serio_raw tpm psmouse
evdev tpm_bios rfkill shpchp ac processor rng_c ore battery video power_supply
soundcore pci_hotplug button output snd_page_alloc usb_storage uas ext3 jbd
mbcache sd_mod crc_t10dif ata_generic ahci libahci ata_piix libata uhci_h cd
ehci_hcd scsi_mod usbcore thermal atl2 thermal_sys nls_base [last unloaded:
scsi_wait_scan]
[ 1189.192007]
[ 1189.192007] Pid: 1464, comm: upowerd Not tainted 2.6.37-2-686 #1 ASUSTeK
Computer INC. 701/701
[ 1189.192007] EIP: 0060:[] EFLAGS: 00010246 CPU: 0
[ 1189.192007] EIP is at intel_tv_detect_type+0xa2/0x203 [i915]
[ 1189.192007] EAX: EBX: dca74000 ECX: e0f68004 EDX: 00068004
[ 1189.192007] ESI: dd110c00 EDI: 400c0c37 EBP: dca7429c ESP: de365e2c
[ 1189.192007] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 1189.192007] Process upowerd (pid: 1464, ti=de364000 task=dcc8acb0
task.ti=de364000)
[ 1189.192007] Stack: Mar 15 03:43:23 hostname kernel: [ 1189.192007] e0c2cda4
7000 400c0c30 dd111000 de365e54 de365f24 dd110c00
[ 1189.192007] e0c22203 0100 0003
4353544e
[ 1189.192007] 30383420 0069
[ 1189.192007] Call Trace: Mar 15 03:43:23 hostname kernel: [ 1189.192007]
[] ? intel_tv_detect+0x89/0x12d [i915]
[ 1189.192007] [] ? status_show+0x0/0x2f [drm]
[ 1189.192007] [] ? status_show+0x14/0x2f [drm]
[Digression: what is upowerd doing reading those power hungry files?]
Reported-by: Paul Menzel
Signed-off-by: Chris Wilson
Cc: sta...@kernel.org
---
drivers/gpu/drm/drm_sysfs.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 85da4c4..2eee8e0 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -158,8 +158,15 @@ static ssize_t status_show(struct device *device,
{
struct drm_connector *connector = to_drm_connector(device);
enum drm_connector_status status;
+ int ret;
+
+ ret = mutex_lock_interruptible(&connector->dev->mode_config.mutex);
+ if (ret)
+ return ret;
status = connector->funcs->detect(connector, true);
+ mutex_unlock(&connector->dev->mode_config.mutex);
+
return snprintf(buf, PAGE_SIZE, "%s\n",
drm_get_connector_status_name(status));
}
--
1.7.2.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Retry i2c transfer of EDID block after failure
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 affected
components, but that only covers EGAIN and not EREMOTEIO/ETIMEDOUT that
afflicts us. With the alteration to only retry the transfer of the
affected block, this looks to be a reasonable idea and complements the
logic to retry corrupted transfers.
-Chris
---
drivers/gpu/drm/drm_edid.c | 44 ++--
1 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a245d17..ddc3da9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -230,24 +230,32 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
unsigned char *buf,
int block, int len)
{
unsigned char start = block * EDID_LENGTH;
- struct i2c_msg msgs[] = {
- {
- .addr = DDC_ADDR,
- .flags = 0,
- .len= 1,
- .buf= &start,
- }, {
- .addr = DDC_ADDR,
- .flags = I2C_M_RD,
- .len= len,
- .buf= buf,
- }
- };
+ int ret, retries = 5;
- if (i2c_transfer(adapter, msgs, 2) == 2)
- return 0;
+ /* The core i2c driver will automatically retry the transfer if the
+* adapter reports EAGAIN. However, we find that bit-banging transfers
+* are susceptible to errors under a heavily loaded machine and
+* generate spurious NAKs and timeouts. Retrying the transfer
+* of the individual block a few times seems to overcome this.
+*/
+ do {
+ struct i2c_msg msgs[] = {
+ {
+ .addr = DDC_ADDR,
+ .flags = 0,
+ .len= 1,
+ .buf= &start,
+ }, {
+ .addr = DDC_ADDR,
+ .flags = I2C_M_RD,
+ .len= len,
+ .buf= buf,
+ }
+ };
+ ret = i2c_transfer(adapter, msgs, 2);
+ } while (ret != 2 && --retries);
- return -1;
+ return ret == 2 ? 0 : -1;
}
static u8 *
--
1.7.2.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] ACPI/Intel: Rework Opregion support
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 get it working for my hardware and the lack of features (suspend), as well the chance of bricking the system always put me off. > only just recently that things are really taking off, with the code > release from AMD to initialize their most recent Fusion platform. 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. Greetings, Indan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm: Hold the mode mutex whilst probing for sysfs status
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 silly. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613745 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618329 Cheers, Julien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support
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 documentation on how GMA500 handles VBT, and not a great deal more > > for i915. > > I'm not sure what you mean by "handles". If you mean find it, the > gma500 driver code reads a 32-bit pointer to the opregion at offset > 0xfc in the pci configuration space. If you mean parse it, I haven't > seen anything that looked different to what the current kernel code > parses. Opregion is one mechanism to provide VBT - it doesn't define it. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support
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 netbook I have that didn't seem to be parsed > correctly by the current gpu/drm/i915/intel_bios.c code and its > friends. Have a look at it if you want. gma600 *certainly* has a bunch of additional functionality. It may be that this is code that can be split out in a reasonable manner, but there's been sufficient fragility here that I think doing it at this stage for the benefit of a driver in staging doesn't buy us a great deal. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support
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 i915. I'm not sure what you mean by "handles". If you mean find it, the gma500 driver code reads a 32-bit pointer to the opregion at offset 0xfc in the pci configuration space. If you mean parse it, I haven't seen anything that looked different to what the current kernel code parses. OG. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support
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/i915/intel_bios.c code and its friends. Have a look at it if you want. OG. asl.bin Description: Binary data ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33515] System lockup with Page-flipping
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 the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Hold the mode mutex whilst probing for sysfs status
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 poll is being run. For example:
>
> [ 1189.189626] BUG: unable to handle kernel NULL pointer dereference at
> 0100
> [ 1189.189821] IP: [] intel_tv_detect_type+0xa2/0x203 [i915]
> [ 1189.190020] *pde =
> [ 1189.190104] Oops: [#1] SMP
> [ 1189.190209] last sysfs file:
> /sys/devices/pci:00/:00:02.0/drm/card0/card0-SVIDEO-1/status
> [ 1189.190412] Modules linked in: mperf cpufreq_conservative
> cpufreq_userspace cpufreq_powersave cpufreq_stats decnet uinput fuse loop
> joydev snd_hd a_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep
> snd_pcm_oss snd_mixer_oss snd_pcm i915 snd_seq_midi snd_rawmidi
> snd_seq_midi_event snd_seq drm_kms_helper snd_timer uvcvideo d rm
> snd_seq_device eeepc_laptop tpm_tis usbhid videodev i2c_algo_bit v4l1_compat
> snd sparse_keymap i2c_core hid serio_raw tpm psmouse evdev tpm_bios rfkill
> shpchp ac processor rng_c ore battery video power_supply soundcore
> pci_hotplug button output snd_page_alloc usb_storage uas ext3 jbd mbcache
> sd_mod crc_t10dif ata_generic ahci libahci ata_piix libata uhci_h cd ehci_hcd
> scsi_mod usbcore thermal atl2 thermal_sys nls_base [last unloaded:
> scsi_wait_scan]
> [ 1189.192007]
> [ 1189.192007] Pid: 1464, comm: upowerd Not tainted 2.6.37-2-686 #1 ASUSTeK
> Computer INC. 701/701
> [ 1189.192007] EIP: 0060:[] EFLAGS: 00010246 CPU: 0
> [ 1189.192007] EIP is at intel_tv_detect_type+0xa2/0x203 [i915]
> [ 1189.192007] EAX: EBX: dca74000 ECX: e0f68004 EDX: 00068004
> [ 1189.192007] ESI: dd110c00 EDI: 400c0c37 EBP: dca7429c ESP: de365e2c
> [ 1189.192007] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> [ 1189.192007] Process upowerd (pid: 1464, ti=de364000 task=dcc8acb0
> task.ti=de364000)
> [ 1189.192007] Stack: Mar 15 03:43:23 hostname kernel: [ 1189.192007]
> e0c2cda4 7000 400c0c30 dd111000 de365e54 de365f24 dd110c00
> [ 1189.192007] e0c22203 0100 0003
> 4353544e
> [ 1189.192007] 30383420 0069
>
> [ 1189.192007] Call Trace: Mar 15 03:43:23 hostname kernel: [ 1189.192007]
> [] ? intel_tv_detect+0x89/0x12d [i915]
> [ 1189.192007] [] ? status_show+0x0/0x2f [drm]
> [ 1189.192007] [] ? status_show+0x14/0x2f [drm]
>
> [Digression: what is upowerd doing reading those power hungry files?]
>
> Reported-by: Paul Menzel
> Signed-off-by: Chris Wilson
> Cc: sta...@kernel.org
> ---
> drivers/gpu/drm/drm_sysfs.c |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 85da4c4..2eee8e0 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -158,8 +158,15 @@ static ssize_t status_show(struct device *device,
> {
> struct drm_connector *connector = to_drm_connector(device);
> enum drm_connector_status status;
> + int ret;
> +
> + ret = mutex_lock_interruptible(&connector->dev->mode_config.mutex);
> + if (ret)
> + return ret;
>
> status = connector->funcs->detect(connector, true);
> + mutex_unlock(&connector->dev->mode_config.mutex);
> +
How about adding a mutex assertion check in the detect hook as well? I
think we need a more generous sprinkling of those around the CRTC
helper code in general...
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33515] System lockup with Page-flipping
https://bugs.freedesktop.org/show_bug.cgi?id=33515 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from Marek Olšák 2011-03-15 08:51:30 PDT --- Closing because the patch is now part of kernel 2.6.38. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35183] system freezes with 2.6.38-rc kernel and kms pageflip enabled
https://bugs.freedesktop.org/show_bug.cgi?id=35183 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Marek Olšák 2011-03-15 08:55:00 PDT --- I think the fix is part of kernel 2.6.38. Closing then. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] ACPI/Intel: Rework Opregion support
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 and use Coreboot for ages, > but the amount of hassle needed to get it working for my hardware > and the lack of features (suspend), as well the chance of bricking > the system always put me off. > >> only just recently that things are really taking off, with the code >> release from AMD to initialize their most recent Fusion platform. > > 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 why we had Linux support before hw was available publicly. My board just happened to get bricked recently during a failed bios upgrade. A new one is on the way. Also we are looking into a potential release of UVD, but unfortunately, our decode hw is intimately tied in with our drm implementation and if someone managed to use the released information to compromise the drm in our windows driver it would very negatively impact our ability to sell into the windows market and would probably get the open source graphics initiative shut down. Alex > Greetings, > > Indan > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35254] Radeon TTM Crash With E-350 Fusion
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 restarted. That's when launching Padman or related games where previously there was this TTM issue. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Retry i2c transfer of EDID block after failure
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
Looks good.
Reviewed-by: Alex Deucher
> ---
>
> I was going to suggest tuning the i2c_adapter.retries of the affected
> components, but that only covers EGAIN and not EREMOTEIO/ETIMEDOUT that
> afflicts us. With the alteration to only retry the transfer of the
> affected block, this looks to be a reasonable idea and complements the
> logic to retry corrupted transfers.
> -Chris
>
> ---
> drivers/gpu/drm/drm_edid.c | 44
> ++--
> 1 files changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index a245d17..ddc3da9 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -230,24 +230,32 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> int block, int len)
> {
> unsigned char start = block * EDID_LENGTH;
> - struct i2c_msg msgs[] = {
> - {
> - .addr = DDC_ADDR,
> - .flags = 0,
> - .len = 1,
> - .buf = &start,
> - }, {
> - .addr = DDC_ADDR,
> - .flags = I2C_M_RD,
> - .len = len,
> - .buf = buf,
> - }
> - };
> + int ret, retries = 5;
>
> - if (i2c_transfer(adapter, msgs, 2) == 2)
> - return 0;
> + /* The core i2c driver will automatically retry the transfer if the
> + * adapter reports EAGAIN. However, we find that bit-banging transfers
> + * are susceptible to errors under a heavily loaded machine and
> + * generate spurious NAKs and timeouts. Retrying the transfer
> + * of the individual block a few times seems to overcome this.
> + */
> + do {
> + struct i2c_msg msgs[] = {
> + {
> + .addr = DDC_ADDR,
> + .flags = 0,
> + .len = 1,
> + .buf = &start,
> + }, {
> + .addr = DDC_ADDR,
> + .flags = I2C_M_RD,
> + .len = len,
> + .buf = buf,
> + }
> + };
> + ret = i2c_transfer(adapter, msgs, 2);
> + } while (ret != 2 && --retries);
>
> - return -1;
> + return ret == 2 ? 0 : -1;
> }
>
> static u8 *
> --
> 1.7.2.3
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Radeon jittery post 2.6.35
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 over HDMI, and the display has > >> always been jittery after POST and at the GRUB screen. Pre-KMS, the X > >> server (or driver got it sorted), and when KMS started, the display > >> stabilized right after the kernel driver was initiated. However, post > >> 2.6.35, I see the jitter is back. > >> > >> I've spent the last month trying to bisect it, but pretty much failed. > >> It appears that versions closer to 2.6.38-rcX are more prone to display > >> jitter, while 2.6.36 or so can have many successful runs. It also > >> appears to be related to device power-on order, or so I've come to > >> believe; A stable display can turn jittery, just by power cycling the TV. > >> Some further testing on a clean rc8 suggests that the jitter seen there can reliably be removed by power cycling the TV while in X, or starting X with the TV off. I'm tempted to think that something makes too much out of bad info collected from the TV, and falls backs to saner defaults if the TV has nothing to say. I've seen in the logs that the EDID is disliked: [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Not sure if that is related though (cannot seem to be able to provoke that error message right now) -A ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Radeon jittery post 2.6.35
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) 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 at the GRUB screen. Pre-KMS, the X >> >> server (or driver got it sorted), and when KMS started, the display >> >> stabilized right after the kernel driver was initiated. However, post >> >> 2.6.35, I see the jitter is back. >> >> >> >> I've spent the last month trying to bisect it, but pretty much failed. >> >> It appears that versions closer to 2.6.38-rcX are more prone to display >> >> jitter, while 2.6.36 or so can have many successful runs. It also >> >> appears to be related to device power-on order, or so I've come to >> >> believe; A stable display can turn jittery, just by power cycling the TV. >> >> > > Some further testing on a clean rc8 suggests that the jitter seen > there can reliably be removed by power cycling the TV while in X, > or starting X with the TV off. > > I'm tempted to think that something makes too much out of bad > info collected from the TV, and falls backs to saner defaults if > the TV has nothing to say. > > I've seen in the logs that the EDID is disliked: > [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but > no|invalid EDID > Not sure if that is related though (cannot seem to be able to provoke > that error message right now) > > -A EDID failure could very well explain it, EDID retrieval seems to fails on some GPU under some circonstance (when there is CPU load that interfer with i2c timing i guess). Does the log have the edid failure message when the tv is jittering ? Or is it the otherway around ? Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Radeon jittery post 2.6.35
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) 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 at the GRUB screen. Pre-KMS, the X >> >> server (or driver got it sorted), and when KMS started, the display >> >> stabilized right after the kernel driver was initiated. However, post >> >> 2.6.35, I see the jitter is back. >> >> >> >> I've spent the last month trying to bisect it, but pretty much failed. >> >> It appears that versions closer to 2.6.38-rcX are more prone to display >> >> jitter, while 2.6.36 or so can have many successful runs. It also >> >> appears to be related to device power-on order, or so I've come to >> >> believe; A stable display can turn jittery, just by power cycling the TV. >> >> > > Some further testing on a clean rc8 suggests that the jitter seen > there can reliably be removed by power cycling the TV while in X, > or starting X with the TV off. > > I'm tempted to think that something makes too much out of bad > info collected from the TV, and falls backs to saner defaults if > the TV has nothing to say. > > I've seen in the logs that the EDID is disliked: > [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but > no|invalid EDID > Not sure if that is related though (cannot seem to be able to provoke > that error message right now) Try booting with radeon.audio=0 on 2.6.38rc, some TVs have problems with the hdmi packets we send by default. disabling audio will treat the hdmi like dvi. Alex > > -A > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Retry i2c transfer of EDID block after failure
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 > --- I'm currently testing this. It boots, but to see if it fixes the issue, I'll have to run some more tests. Note that this patch is subject to .37-table and probably earlier releases, too. -- Greetings, Michael. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm: Hold the mode mutex whilst probing for sysfs status
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. Where "docked" means "more than one output > connected". Yes, it's silly. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613745 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618329 > Its also now disabled by default upstream. I think he was using an 965 or GM45 laptop that seemed to not report output changes properly. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] ACPI/Intel: Rework Opregion support
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 why we had > Linux support before hw was available publicly. My board just > happened to get bricked recently during a failed bios upgrade. > A new one is on the way. Okay, that's better than I thought. I remember a dev saying that no one had Fusion hardware, that's where I got this notion from. > Also we are looking into a potential release of > UVD, but unfortunately, our decode hw is intimately tied in with > our drm implementation and if someone managed to use the released > information to compromise the drm in our windows driver it would very > negatively impact our ability to sell into the windows market and > would probably get the open source graphics initiative shut down. Are you talking about HDCP or something else? Because the HDCP master key already leaked, so the whole security aspect of it is already a joke, open source UVD won't make any difference. Basically you're telling me that I or someone else should reverse engineer de Catalyst driver and break all drm before you consider opening up UVD? I'd argue that opening up UVD now is more secure because it takes away the only morivation to break UVD's drm. Alternatively, can't you open up UVD spec except the drm bits, so people can at least write their own UVD driver to watch unencrypted data? It would be nice to have an open source Fusion based media player/ IPTV decoder, but I guess that's hoping for too much. I understand if AMD/ATI wants to keep its 3D driver secret, but hardware video decoding?! If you have to keep it secret it means shortcuts were taken and it's all insecure anyway. That if it gets broken the Open source driver gets blamed is ridiculous and more politics than anything else. This is getting more and more off-topic though, sorry for the noise. Greetings, Indan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] ACPI/Intel: Rework Opregion support
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 this. >> >> They do give us fusion hw; before launch even. That's why we had >> Linux support before hw was available publicly. My board just >> happened to get bricked recently during a failed bios upgrade. >> A new one is on the way. > > Okay, that's better than I thought. I remember a dev saying that > no one had Fusion hardware, that's where I got this notion from. > >> Also we are looking into a potential release of >> UVD, but unfortunately, our decode hw is intimately tied in with >> our drm implementation and if someone managed to use the released >> information to compromise the drm in our windows driver it would very >> negatively impact our ability to sell into the windows market and >> would probably get the open source graphics initiative shut down. > > Are you talking about HDCP or something else? Because the HDCP master > key already leaked, so the whole security aspect of it is already a > joke, open source UVD won't make any difference. > 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. > Basically you're telling me that I or someone else should reverse > engineer de Catalyst driver and break all drm before you consider > opening up UVD? I'd argue that opening up UVD now is more secure > because it takes away the only morivation to break UVD's drm. > > Alternatively, can't you open up UVD spec except the drm bits, > so people can at least write their own UVD driver to watch > unencrypted data? Without going into detail, they are very intertwined. The hw was designed long before we planned to support open source as much as we are now. Fortunately, we have been working with our hw teams to make future UVD implementations take the open source driver into account. > > It would be nice to have an open source Fusion based media player/ > IPTV decoder, but I guess that's hoping for too much. > > I understand if AMD/ATI wants to keep its 3D driver secret, but > hardware video decoding?! If you have to keep it secret it means > shortcuts were taken and it's all insecure anyway. That if it gets > broken the Open source driver gets blamed is ridiculous and more > politics than anything else. We don't keep the 3D engine secret. Most of the code we've written and specs we've released are 3D engine stuff. Fortunately 3D is less tied up in drm compared to video. It's all about mitigating risk. Imagine you run a company and someone asks you this: "Can we release programming info for a part of our chip to support 2-3% of our market that may put at risk 90% of our market?" What would you do? The reason the review is taking so long is that we want to be real sure that the risk is safe. > > This is getting more and more off-topic though, sorry for the noise. > Agreed. Alex > Greetings, > > Indan > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] ACPI/Intel: Rework Opregion support
> > 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 > one of the laptops that Dave tests drm-next on is a HP, he was bitten by > the bug and temporarily (we hope) disabled the logic. Or else once again, > we will continue to light up the panel on a closed laptop. Yeah I've no idea if the ACPI implementation is wrong or not :-( I suspects its the BIOS actually, the BIOS wants _INI called before _REG. The ACPI video device isn't in the EC address space, so it ends up in the default region address space. So we'd really need to know how Windows sets up the _REG calls for the non-EC spaces and where its calls the _INI methods wrt to that. The thing is I think the actual ACPI lid device is fine, its just opregion isn't updated until we get an event later. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] ACPI/Intel: Rework Opregion support
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 secure. Wonderful. > Without going into detail, they are very intertwined. The hw was > designed long before we planned to support open source as much as we > are now. Fortunately, we have been working with our hw teams to make > future UVD implementations take the open source driver into account. It has nothing to do with open source, if you need to trust the driver you're already screwed from a security point of view. >> >> It would be nice to have an open source Fusion based media player/ >> IPTV decoder, but I guess that's hoping for too much. >> >> I understand if AMD/ATI wants to keep its 3D driver secret, but >> hardware video decoding?! If you have to keep it secret it means >> shortcuts were taken and it's all insecure anyway. That if it gets >> broken the Open source driver gets blamed is ridiculous and more >> politics than anything else. > > We don't keep the 3D engine secret. Most of the code we've written > and specs we've released are 3D engine stuff. Fortunately 3D is less > tied up in drm compared to video. That's not what I said, I was talking about the driver. There are always details not documented, and plenty of optimisation tricks that make the hardware go fast. Just compare the performance of the Windows driver with the open source Linux driver. It doesn't give the impression that AMD is putting much effort in the open source drivers or that it takes it seriously. > It's all about mitigating risk. > Imagine you run a company and someone asks you this: "Can we release > programming info for a part of our chip to support 2-3% of our market > that may put at risk 90% of our market?" What would you do? The > reason the review is taking so long is that we want to be real sure > that the risk is safe. That's what AMD doesn't get, it only has 2-3% because its drivers aren't great. If AMD had good performing open source drivers they would not only get a bigger market share, their hardware would also be used more for embedded kind of things like decoders, media boxes and who knows what. The risk you're talking about is how to best hide that the hardware is totally insecure as far as the drm goes. Well no, you wouldn't want to make that public indeed. It's probably the crazy drm's that more or less forced AMD to implement it this way, but still. >> >> This is getting more and more off-topic though, sorry for the noise. > > Agreed. Last post from me about this... Greetings, Indan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] ACPI/Intel: Rework Opregion support
Hello, Some nitpicks below. On Mon, March 14, 2011 18:59, Chris Wilson wrote: > From: Matthew Garrett > > The Integrated Graphics Device opregion specification defines a mechanism > for the OS and system firmware to collaborate on various graphics-related > functionality. This is currently implemented in the i915 driver but isn't > strictly limited to these devices. Move it to a more generic location and > remove the i915 dependency, while simultaneously reworking i915 to make > use of the new driver. > > Signed-off-by: Matthew Garrett > Acked-by: Acked-by: Jesse Barnes > Cc: Alan Cox > Cc: Keith Packard > Cc: Len Brown > [ickle: rebase onto drm-core-next] > Signed-off-by: Chris Wilson > --- > > Note: neither the opregion_dev interface or the alse_set_* properly report > failures. As such we have a slight change in behaviour on Ironlake+ > platforms and an uncorrected bug for earlier chipsets. > -Chris What uncorrected bug? And are there earlier chipsets with ASLE support at all, besides gen 4? If there are no gen 2 or gen 3 chipsets with ASLE then the backlight code can be simplified further. > > --- > drivers/acpi/Kconfig |8 + > drivers/acpi/Makefile |1 + > drivers/acpi/acpi_igd_opregion.c | 411 ++ > drivers/gpu/drm/Kconfig |1 + > drivers/gpu/drm/i915/Makefile |1 - > drivers/gpu/drm/i915/i915_debugfs.c |2 +- > drivers/gpu/drm/i915/i915_dma.c | 13 +- > drivers/gpu/drm/i915/i915_drv.c |6 +- > drivers/gpu/drm/i915/i915_drv.h | 34 +-- > drivers/gpu/drm/i915/i915_irq.c |7 +- > drivers/gpu/drm/i915/intel_bios.c |8 +- > drivers/gpu/drm/i915/intel_lvds.c |2 +- > drivers/gpu/drm/i915/intel_opregion.c | 516 > - > drivers/gpu/drm/i915/intel_panel.c|4 +- > include/acpi/acpi_igd_opregion.h | 105 +++ > 15 files changed, 552 insertions(+), 567 deletions(-) > create mode 100644 drivers/acpi/acpi_igd_opregion.c > delete mode 100644 drivers/gpu/drm/i915/intel_opregion.c > create mode 100644 include/acpi/acpi_igd_opregion.h > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig > index 2aa042a..7ace174 100644 > --- a/drivers/acpi/Kconfig > +++ b/drivers/acpi/Kconfig > @@ -383,4 +383,12 @@ config ACPI_HED > > source "drivers/acpi/apei/Kconfig" > > +config ACPI_IGD_OPREGION > + tristate "ACPI Integrated Graphics Device OpRegion support" > + help > + This driver adds support for the Intel ACPI Integrated Graphics > + Device OpRegion specification, allowing communication between > + the firmware and graphics driver on mobile systems with Intel > + graphics > + Isn't this option always selected automatically when needed? That is, it shouldn't show up as an option at all, so people can't accidentally select it when they don't need it? Though that doesn't quite work with modules I suppose, never mind. > endif# ACPI > diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile > index d113fa5..dcade4b 100644 > --- a/drivers/acpi/Makefile > +++ b/drivers/acpi/Makefile > @@ -62,6 +62,7 @@ obj-$(CONFIG_ACPI_SBS) += sbs.o > obj-$(CONFIG_ACPI_POWER_METER) += power_meter.o > obj-$(CONFIG_ACPI_HED) += hed.o > obj-$(CONFIG_ACPI_EC_DEBUGFS)+= ec_sys.o > +obj-$(CONFIG_ACPI_IGD_OPREGION) += acpi_igd_opregion.o > > # processor has its own "processor." module_param namespace > processor-y := processor_driver.o processor_throttling.o > diff --git a/drivers/acpi/acpi_igd_opregion.c > b/drivers/acpi/acpi_igd_opregion.c > new file mode 100644 > index 000..0015ca8 > --- /dev/null > +++ b/drivers/acpi/acpi_igd_opregion.c > @@ -0,0 +1,411 @@ > +/* > + * Copyright 2008 Intel Corporation > + * Copyright 2008 Red Hat > + * > + * 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, sub license, 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 > + * NON-INFRINGEMENT. IN NO EVENT SHALL INTEL AND/OR ITS SUPPLIERS BE > + * LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN > + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN > + * C
[PATCH] ACPI/Intel: Rework Opregion support
On Tue, Mar 15, 2011 at 02:18:02AM +0100, Indan Zupancic wrote:
> > +
> > + if (dev->set_backlight)
> > + dev->set_backlight(dev->drm_dev, bclp * max / 255);
>
> I would hide the max backlight from the opregion code and move this
> calculation into set_brightness. Then change the interface to one
> based on a scale from 0-255 or 0-100, which fits better with what
> opregion actually does. On the other hand, it's the same code in
> a different place, so it doesn't make much difference.
That would require an extra layer of indirection in every driver, so
keeping it here seems reasonable.
> > +void igd_opregion_enable_asle(struct opregion_dev *dev)
> > +{
> > + struct opregion_asle *asle = dev->opregion.asle;
> > +
> > + if (asle && dev->enable_asle) {
> > + dev->enable_asle(dev->drm_dev);
> > +
> > + asle->tche = ASLE_ALS_EN | ASLE_BLC_EN | ASLE_PFIT_EN |
> > + ASLE_PFMB_EN;
>
> Shouldn't which flags are set depend on which callback functions are set?
> Then you can remove all the function != NULL tests too. e.g:
Our experience is that we should give BIOSes the full set of support
flags even if we don't actually do anything with them. That way we avoid
cases where BIOS authors refuse to do anything with partial
implementations (even if we support everything they use) and we get
feedback when we actually find cases of advanced functionality in the
real world.
> > + if (IS_MOBILE(dev)) {
> > + dev_priv->opregion_dev.max_backlight =
> > intel_panel_get_max_backlight(dev);
> > + dev_priv->opregion_dev.set_backlight =
> > intel_panel_set_backlight;
> > + }
> > + dev_priv->opregion_dev.enable_asle = intel_enable_asle;
> > + dev_priv->opregion_dev.drm_dev = dev;
>
> So we have a drm_device->drm_i915_private->opregion_dev.drm_device loop,
> which is a bit messy, but consistent with other existing code.
Anyone who wants to clean that up is welcome to do so, but really I
optimised for ease of transition here.
> >
> > - /* XXX Should this validation be moved to intel_opregion.c? */
> > - if (dev_priv->opregion.vbt) {
> > - struct vbt_header *vbt = dev_priv->opregion.vbt;
> > + /* XXX Should this validation be moved to acpi_igd_opregion.c? */
>
> Should it? Seems like a good moment to do so.
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 i915.
> About the naming, as this is Intel-only intel_opregion seems clearer than
> igd-opregion, which sounds like it could be anything.
It's Intel-only in implementation, not in specification. As much as I
dislike vendor-neutral specs that have been pushed and implemented by a
single vendor, I'd rather not make the naming Intel-specific if there's
a chance someone else can end up depending on it.
--
Matthew Garrett | mjg59 at srcf.ucam.org
[mesa] git-fedc5b0: Diverse User errors and ABORTS
With mesa-from-git, I see this messages in VT-1 from where I run startx: Mesa: User error: GL_INVALID_ENUM in CreateShader(type) Mesa: User error: GL_INVALID_VALUE in glShaderSourceARB Mesa: User error: GL_INVALID_VALUE in glCompileShader Mesa: User error: GL_INVALID_VALUE in glGetObjectParameterivARB ###!!! ABORT: X_GLXSwapBuffers: BadMatch (invalid parameter attributes): file ../../../toolkit/xre/nsX11ErrorHandler.cpp, line 190 ###!!! ABORT: X_GLXSwapBuffers: BadMatch (invalid parameter attributes): file ../../../toolkit/xre/nsX11ErrorHandler.cpp, line 190 Last commit: commit fedc5b03db64cbb76d101945017a46c5d27f1bbb Author: Dave Airlie glx: add ARB_create_context functions/ops to glx xml My autogen-line: $ ./autogen.sh --prefix=/usr --with-driver=dri --with-dri-driverdir=/usr/lib/dri --with-dri-drivers=r200,swrast --disable-gallium --disable-egl --disable-glu --disable-glut --disable-glw --enable-glx-tls --enable-debug I am here on linux-next (next-20110314) and xserver-1.10-rc3. - Sedat -
[Bug 27314] displayport link training fails on certain panels (channel equalization fails)
https://bugs.freedesktop.org/show_bug.cgi?id=27314 Alex Deucher changed: What|Removed |Added Summary|DP link training fails on |displayport link training |2560x1440 panels|fails on certain panels ||(channel equalization ||fails) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27314] displayport link training fails on certain panels (channel equalization fails)
https://bugs.freedesktop.org/show_bug.cgi?id=27314 Alex Deucher changed: What|Removed |Added CC||merlijn at wajer.org --- Comment #33 from Alex Deucher 2011-03-15 00:11:48 PDT --- *** Bug 35179 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30922] [radeon] Noisy fan with Radeon R600 and Toshiba Satellite L500-164
https://bugzilla.kernel.org/show_bug.cgi?id=30922 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher 2011-03-15 07:29:57 --- For more information about the power management options in the driver, see the "KMS Power Management Options" section of this page: http://wiki.x.org/wiki/RadeonFeature -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 30922] [radeon] Noisy fan with Radeon R600 and Toshiba Satellite L500-164
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 are receiving this mail because: --- You are watching the assignee of the bug. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Radeon jittery post 2.6.35
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 at the GRUB screen. Pre-KMS, the X >> server (or driver got it sorted), and when KMS started, the display >> stabilized right after the kernel driver was initiated. However, post >> 2.6.35, I see the jitter is back. >> >> I've spent the last month trying to bisect it, but pretty much failed. >> It appears that versions closer to 2.6.38-rcX are more prone to display >> jitter, while 2.6.36 or so can have many successful runs. It also >> appears to be related to device power-on order, or so I've come to >> believe; A stable display can turn jittery, just by power cycling the TV. >> >> I've uploaded a video of a 38-rc8 boot: >> http://www.easy-share.com/1914220540/2.6.38-rc8_bad_x.mp4 >> >> You'll see jitter at the POST screen and GRUB. When KMS kicks in it >> stabilizes, and when Freevo starts X, it's back to jitter. > Does plain X or gnome/kde jitter too or just freevo? > Yes. A plain xinit with an xterm without window manager shows the same thing. (I run freevo on on X, not fb) Btw, These are the X packages I use: libXxf86misc-1.0.3 libXxf86dga-1.1.2 libXxf86vm-1.1.1 xf86dga-1.0.3 xf86vidmodeproto-2.3.1 xf86miscproto-0.9.3 xf86dgaproto-2.1 xf86bigfontproto-1.2.0 xf86driproto-2.1.1 xf86rushproto-1.1.2 xf86-input-evdev-2.6.0 xf86-video-ati-6.14.0 xf86-input-keyboard-1.5.0 xf86-input-mouse-1.6.0 > Alex > >> The jitter is always of the same kind. It looks like an old tv set which >> loses sync. The contents on the display is, for a split second, placed >> at the wrong part of the screen (vertically and to some extent >> horizontally), and every 5-15 seconds or so, there is a big reset when >> the TV tries to restart things (I guess). At the resets, thee is a loud >> 'ping' in the nearby stereo too... >> >> During the bisect (and a t 38-rc8) I've seen this both at the console >> (post KMS) and in X, so I'm not sure where the error is. I hope some of >> you can get a better idea of where to hunt for the bug by looking at the >> video. >> >> -Anders >>
[PATCH] drm/radeon: fix problem with changing active VRAM size. (v2)
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 it was only later noticed that this > broke on some hw. > > This removes the active_vram_size, and just explicitly sets it > when it changes, TTM/drm_mm will always use the real_vram_size, > and the active vram size will change the TTM size used for lpfn > setting. > > We should re-work the fpfn/lpfn to per-placement at some point > I suspect, but that is too late for this kernel. > > Hopefully this addresses: > https://bugs.freedesktop.org/show_bug.cgi?id=35254 > > v2: fix reported useful VRAM size to userspace to be correct. > > Signed-off-by: Dave Airlie Looks good, Dave. Thanks for getting rid of one of the *_vram_size fields, those were getting out of hand. -- Earthling Michel D?nzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer
Radeon jittery post 2.6.35
> 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_pll(struct drm_crtc *crtc, > if ((rdev->family == CHIP_RS600) || > (rdev->family == CHIP_RS690) || > (rdev->family == CHIP_RS740)) > - pll->flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/ > + pll->flags |= (RADEON_PLL_USE_FRAC_FB_DIV | >RADEON_PLL_PREFER_CLOSEST_LOWER); > > if (ASIC_IS_DCE32(rdev) && mode->clock > 20) > /* range limits??? */ No. No improvement on rc8.
[PATCH] ACPI/Intel: Rework Opregion support
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 Ironlake+ > > platforms and an uncorrected bug for earlier chipsets. > > -Chris > > What uncorrected bug? For later chipsets we currently report the failure to respond to the ALSE requests, for earlier we do not. The patch harmonises the two code paths reusing the earlier code for later chipsets, hence the change in behaviour and potential regression. Alternatively, actually reporting the failure for earlier chipsets may also break existing setups. > And are there earlier chipsets with ASLE support at all, besides gen 4? > If there are no gen 2 or gen 3 chipsets with ASLE then the backlight > code can be simplified further. The OpRegion interface was devised midway through gen3 (afaik), and you find it on some i915-class hw and not others. In theory, there is nothing to prevent a BIOS/ACPI from being rewritten for it to be of use in gen2, and who knows one such beast may already exist (considering much to our horror you can still buy gen2 chipsets). > > diff --git a/drivers/gpu/drm/i915/intel_panel.c > > b/drivers/gpu/drm/i915/intel_panel.c > > index 4e5ff59..51565bb 100644 > > --- a/drivers/gpu/drm/i915/intel_panel.c > > +++ b/drivers/gpu/drm/i915/intel_panel.c > > @@ -261,8 +261,8 @@ intel_panel_detect(struct drm_device *dev) > > * appears to be either the BIOS or Linux ACPI fault */ > > #if 0 > > /* Assume that the BIOS does not lie through the OpRegion... */ > > - if (dev_priv->opregion.lid_state) > > - return ioread32(dev_priv->opregion.lid_state) & 0x1 ? > > + if (dev_priv->opregion_dev.opregion.acpi) > > + return ioread32(&dev_priv->opregion_dev.opregion.acpi->clid) & > > 0x1 ? > > What guarantees that opregion.acpi != NULL here? You mean other than the explicit test for opregion.acpi != NULL? > Or perhaps just remove that #if 0 code chunk altogether? 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 one of the laptops that Dave tests drm-next on is a HP, he was bitten by the bug and temporarily (we hope) disabled the logic. Or else once again, we will continue to light up the panel on a closed laptop. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH] ACPI/Intel: Rework Opregion support
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 >> > failures. As such we have a slight change in behaviour on Ironlake+ >> > platforms and an uncorrected bug for earlier chipsets. >> > -Chris >> >> What uncorrected bug? > > For later chipsets we currently report the failure to respond to the ALSE > requests, for earlier we do not. The patch harmonises the two code paths > reusing the earlier code for later chipsets, hence the change in behaviour > and potential regression. Alternatively, actually reporting the failure > for earlier chipsets may also break existing setups. Ah, okay, for the ASLE_SET_ALS_ILLUM/ASLE_SET_PFIT/ASLE_SET_PWM_FREQ cases. Hopefully this change doesn't cause regressions, that would be sad. >> And are there earlier chipsets with ASLE support at all, besides gen 4? >> If there are no gen 2 or gen 3 chipsets with ASLE then the backlight >> code can be simplified further. > > The OpRegion interface was devised midway through gen3 (afaik), and you > find it on some i915-class hw and not others. In theory, there is nothing > to prevent a BIOS/ACPI from being rewritten for it to be of use in gen2, > and who knows one such beast may already exist (considering much to our > horror you can still buy gen2 chipsets). Pity, if they're still sold any bets are off. >> > diff --git a/drivers/gpu/drm/i915/intel_panel.c >> > b/drivers/gpu/drm/i915/intel_panel.c >> > index 4e5ff59..51565bb 100644 >> > --- a/drivers/gpu/drm/i915/intel_panel.c >> > +++ b/drivers/gpu/drm/i915/intel_panel.c >> > @@ -261,8 +261,8 @@ intel_panel_detect(struct drm_device *dev) >> > * appears to be either the BIOS or Linux ACPI fault */ >> > #if 0 >> >/* Assume that the BIOS does not lie through the OpRegion... */ >> > - if (dev_priv->opregion.lid_state) >> > - return ioread32(dev_priv->opregion.lid_state) & 0x1 ? >> > + if (dev_priv->opregion_dev.opregion.acpi) >> > + return ioread32(&dev_priv->opregion_dev.opregion.acpi->clid) & >> > 0x1 ? >> >> What guarantees that opregion.acpi != NULL here? > > You mean other than the explicit test for opregion.acpi != NULL? I'm blind. I checked all the rest of the code, but not the line just above it. Gah! >> Or perhaps just remove that #if 0 code chunk altogether? > > Read the changelog and thread on the patch that disabled this logic, the I just subscribed to intel-gfx, seemed like a good idea after the reject. > 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 > one of the laptops that Dave tests drm-next on is a HP, he was bitten by > the bug and temporarily (we hope) disabled the logic. Or else once again, > we will continue to light up the panel on a closed laptop. Hopefully it's fixed by the next BIOS upgrade by HP... Everything would be a lot simpler if the BIOSes were open source. It's shocking with what you guys have to deal with. Good luck and thanks for all the hard work! Indan
[PATCH] ACPI/Intel: Rework Opregion support
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 code release from AMD to initialize their most recent Fusion platform. http://www.coreboot.org/Welcome_to_coreboot http://blogs.amd.com/work/2011/02/28/amd-coreboot/ http://news.slashdot.org/story/11/03/04/1736241/AMD-Provides-Fusion-Support-For-Coreboot //Peter
[PATCH] drm: Hold the mode mutex whilst probing for sysfs status
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 handle kernel NULL pointer dereference at 0100
[ 1189.189821] IP: [] intel_tv_detect_type+0xa2/0x203 [i915]
[ 1189.190020] *pde =
[ 1189.190104] Oops: [#1] SMP
[ 1189.190209] last sysfs file:
/sys/devices/pci:00/:00:02.0/drm/card0/card0-SVIDEO-1/status
[ 1189.190412] Modules linked in: mperf cpufreq_conservative cpufreq_userspace
cpufreq_powersave cpufreq_stats decnet uinput fuse loop joydev snd_hd
a_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss
snd_pcm i915 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq drm_kms_helper
snd_timer uvcvideo d rm snd_seq_device eeepc_laptop tpm_tis usbhid videodev
i2c_algo_bit v4l1_compat snd sparse_keymap i2c_core hid serio_raw tpm psmouse
evdev tpm_bios rfkill shpchp ac processor rng_c ore battery video power_supply
soundcore pci_hotplug button output snd_page_alloc usb_storage uas ext3 jbd
mbcache sd_mod crc_t10dif ata_generic ahci libahci ata_piix libata uhci_h cd
ehci_hcd scsi_mod usbcore thermal atl2 thermal_sys nls_base [last unloaded:
scsi_wait_scan]
[ 1189.192007]
[ 1189.192007] Pid: 1464, comm: upowerd Not tainted 2.6.37-2-686 #1 ASUSTeK
Computer INC. 701/701
[ 1189.192007] EIP: 0060:[] EFLAGS: 00010246 CPU: 0
[ 1189.192007] EIP is at intel_tv_detect_type+0xa2/0x203 [i915]
[ 1189.192007] EAX: EBX: dca74000 ECX: e0f68004 EDX: 00068004
[ 1189.192007] ESI: dd110c00 EDI: 400c0c37 EBP: dca7429c ESP: de365e2c
[ 1189.192007] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 1189.192007] Process upowerd (pid: 1464, ti=de364000 task=dcc8acb0
task.ti=de364000)
[ 1189.192007] Stack: Mar 15 03:43:23 hostname kernel: [ 1189.192007] e0c2cda4
7000 400c0c30 dd111000 de365e54 de365f24 dd110c00
[ 1189.192007] e0c22203 0100 0003
4353544e
[ 1189.192007] 30383420 0069
[ 1189.192007] Call Trace: Mar 15 03:43:23 hostname kernel: [ 1189.192007]
[] ? intel_tv_detect+0x89/0x12d [i915]
[ 1189.192007] [] ? status_show+0x0/0x2f [drm]
[ 1189.192007] [] ? status_show+0x14/0x2f [drm]
[Digression: what is upowerd doing reading those power hungry files?]
Reported-by: Paul Menzel
Signed-off-by: Chris Wilson
Cc: stable at kernel.org
---
drivers/gpu/drm/drm_sysfs.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 85da4c4..2eee8e0 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -158,8 +158,15 @@ static ssize_t status_show(struct device *device,
{
struct drm_connector *connector = to_drm_connector(device);
enum drm_connector_status status;
+ int ret;
+
+ ret = mutex_lock_interruptible(&connector->dev->mode_config.mutex);
+ if (ret)
+ return ret;
status = connector->funcs->detect(connector, true);
+ mutex_unlock(&connector->dev->mode_config.mutex);
+
return snprintf(buf, PAGE_SIZE, "%s\n",
drm_get_connector_status_name(status));
}
--
1.7.2.3
[PATCH] drm: Retry i2c transfer of EDID block after failure
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 affected
components, but that only covers EGAIN and not EREMOTEIO/ETIMEDOUT that
afflicts us. With the alteration to only retry the transfer of the
affected block, this looks to be a reasonable idea and complements the
logic to retry corrupted transfers.
-Chris
---
drivers/gpu/drm/drm_edid.c | 44 ++--
1 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a245d17..ddc3da9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -230,24 +230,32 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
unsigned char *buf,
int block, int len)
{
unsigned char start = block * EDID_LENGTH;
- struct i2c_msg msgs[] = {
- {
- .addr = DDC_ADDR,
- .flags = 0,
- .len= 1,
- .buf= &start,
- }, {
- .addr = DDC_ADDR,
- .flags = I2C_M_RD,
- .len= len,
- .buf= buf,
- }
- };
+ int ret, retries = 5;
- if (i2c_transfer(adapter, msgs, 2) == 2)
- return 0;
+ /* The core i2c driver will automatically retry the transfer if the
+* adapter reports EAGAIN. However, we find that bit-banging transfers
+* are susceptible to errors under a heavily loaded machine and
+* generate spurious NAKs and timeouts. Retrying the transfer
+* of the individual block a few times seems to overcome this.
+*/
+ do {
+ struct i2c_msg msgs[] = {
+ {
+ .addr = DDC_ADDR,
+ .flags = 0,
+ .len= 1,
+ .buf= &start,
+ }, {
+ .addr = DDC_ADDR,
+ .flags = I2C_M_RD,
+ .len= len,
+ .buf= buf,
+ }
+ };
+ ret = i2c_transfer(adapter, msgs, 2);
+ } while (ret != 2 && --retries);
- return -1;
+ return ret == 2 ? 0 : -1;
}
static u8 *
--
1.7.2.3
[PATCH] ACPI/Intel: Rework Opregion support
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 get it working for my hardware and the lack of features (suspend), as well the chance of bricking the system always put me off. > only just recently that things are really taking off, with the code > release from AMD to initialize their most recent Fusion platform. 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. Greetings, Indan
[Intel-gfx] [PATCH] drm: Hold the mode mutex whilst probing for sysfs status
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 silly. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613745 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618329 Cheers, Julien
[Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support
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 documentation on how GMA500 handles VBT, and not a great deal more > > for i915. > > I'm not sure what you mean by "handles". If you mean find it, the > gma500 driver code reads a 32-bit pointer to the opregion at offset > 0xfc in the pci configuration space. If you mean parse it, I haven't > seen anything that looked different to what the current kernel code > parses. Opregion is one mechanism to provide VBT - it doesn't define it. -- Matthew Garrett | mjg59 at srcf.ucam.org
[Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support
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 netbook I have that didn't seem to be parsed > correctly by the current gpu/drm/i915/intel_bios.c code and its > friends. Have a look at it if you want. gma600 *certainly* has a bunch of additional functionality. It may be that this is code that can be split out in a reasonable manner, but there's been sufficient fragility here that I think doing it at this stage for the benefit of a driver in staging doesn't buy us a great deal. -- Matthew Garrett | mjg59 at srcf.ucam.org
[Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support
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 i915. I'm not sure what you mean by "handles". If you mean find it, the gma500 driver code reads a 32-bit pointer to the opregion at offset 0xfc in the pci configuration space. If you mean parse it, I haven't seen anything that looked different to what the current kernel code parses. OG.
[Intel-gfx] [PATCH] ACPI/Intel: Rework Opregion support
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/i915/intel_bios.c code and its friends. Have a look at it if you want. OG. -- next part -- A non-text attachment was scrubbed... Name: asl.bin Type: application/octet-stream Size: 8192 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110315/89a503cb/attachment.bin>
[Bug 33515] System lockup with Page-flipping
https://bugs.freedesktop.org/show_bug.cgi?id=33515 --- Comment #12 from rockmen1 at 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 the bug.
[PATCH] drm: Hold the mode mutex whilst probing for sysfs status
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 poll is being run. For example:
>
> [ 1189.189626] BUG: unable to handle kernel NULL pointer dereference at
> 0100
> [ 1189.189821] IP: [] intel_tv_detect_type+0xa2/0x203 [i915]
> [ 1189.190020] *pde =
> [ 1189.190104] Oops: [#1] SMP
> [ 1189.190209] last sysfs file:
> /sys/devices/pci:00/:00:02.0/drm/card0/card0-SVIDEO-1/status
> [ 1189.190412] Modules linked in: mperf cpufreq_conservative
> cpufreq_userspace cpufreq_powersave cpufreq_stats decnet uinput fuse loop
> joydev snd_hd a_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep
> snd_pcm_oss snd_mixer_oss snd_pcm i915 snd_seq_midi snd_rawmidi
> snd_seq_midi_event snd_seq drm_kms_helper snd_timer uvcvideo d rm
> snd_seq_device eeepc_laptop tpm_tis usbhid videodev i2c_algo_bit v4l1_compat
> snd sparse_keymap i2c_core hid serio_raw tpm psmouse evdev tpm_bios rfkill
> shpchp ac processor rng_c ore battery video power_supply soundcore
> pci_hotplug button output snd_page_alloc usb_storage uas ext3 jbd mbcache
> sd_mod crc_t10dif ata_generic ahci libahci ata_piix libata uhci_h cd ehci_hcd
> scsi_mod usbcore thermal atl2 thermal_sys nls_base [last unloaded:
> scsi_wait_scan]
> [ 1189.192007]
> [ 1189.192007] Pid: 1464, comm: upowerd Not tainted 2.6.37-2-686 #1 ASUSTeK
> Computer INC. 701/701
> [ 1189.192007] EIP: 0060:[] EFLAGS: 00010246 CPU: 0
> [ 1189.192007] EIP is at intel_tv_detect_type+0xa2/0x203 [i915]
> [ 1189.192007] EAX: EBX: dca74000 ECX: e0f68004 EDX: 00068004
> [ 1189.192007] ESI: dd110c00 EDI: 400c0c37 EBP: dca7429c ESP: de365e2c
> [ 1189.192007] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> [ 1189.192007] Process upowerd (pid: 1464, ti=de364000 task=dcc8acb0
> task.ti=de364000)
> [ 1189.192007] Stack: Mar 15 03:43:23 hostname kernel: [ 1189.192007]
> e0c2cda4 7000 400c0c30 dd111000 de365e54 de365f24 dd110c00
> [ 1189.192007] e0c22203 0100 0003
> 4353544e
> [ 1189.192007] 30383420 0069
>
> [ 1189.192007] Call Trace: Mar 15 03:43:23 hostname kernel: [ 1189.192007]
> [] ? intel_tv_detect+0x89/0x12d [i915]
> [ 1189.192007] [] ? status_show+0x0/0x2f [drm]
> [ 1189.192007] [] ? status_show+0x14/0x2f [drm]
>
> [Digression: what is upowerd doing reading those power hungry files?]
>
> Reported-by: Paul Menzel
> Signed-off-by: Chris Wilson
> Cc: stable at kernel.org
> ---
> drivers/gpu/drm/drm_sysfs.c |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 85da4c4..2eee8e0 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -158,8 +158,15 @@ static ssize_t status_show(struct device *device,
> {
> struct drm_connector *connector = to_drm_connector(device);
> enum drm_connector_status status;
> + int ret;
> +
> + ret = mutex_lock_interruptible(&connector->dev->mode_config.mutex);
> + if (ret)
> + return ret;
>
> status = connector->funcs->detect(connector, true);
> + mutex_unlock(&connector->dev->mode_config.mutex);
> +
How about adding a mutex assertion check in the detect hook as well? I
think we need a more generous sprinkling of those around the CRTC
helper code in general...
--
Jesse Barnes, Intel Open Source Technology Center
[Bug 33515] System lockup with Page-flipping
https://bugs.freedesktop.org/show_bug.cgi?id=33515 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from Marek Ol??k 2011-03-15 08:51:30 PDT --- Closing because the patch is now part of kernel 2.6.38. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35183] system freezes with 2.6.38-rc kernel and kms pageflip enabled
https://bugs.freedesktop.org/show_bug.cgi?id=35183 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Marek Ol??k 2011-03-15 08:55:00 PDT --- I think the fix is part of kernel 2.6.38. Closing then. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] ACPI/Intel: Rework Opregion support
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 and use Coreboot for ages, > but the amount of hassle needed to get it working for my hardware > and the lack of features (suspend), as well the chance of bricking > the system always put me off. > >> only just recently that things are really taking off, with the code >> release from AMD to initialize their most recent Fusion platform. > > 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 why we had Linux support before hw was available publicly. My board just happened to get bricked recently during a failed bios upgrade. A new one is on the way. Also we are looking into a potential release of UVD, but unfortunately, our decode hw is intimately tied in with our drm implementation and if someone managed to use the released information to compromise the drm in our windows driver it would very negatively impact our ability to sell into the windows market and would probably get the open source graphics initiative shut down. Alex > Greetings, > > Indan > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[Bug 35254] Radeon TTM Crash With E-350 Fusion
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 restarted. That's when launching Padman or related games where previously there was this TTM issue. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm: Retry i2c transfer of EDID block after failure
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
Looks good.
Reviewed-by: Alex Deucher
> ---
>
> I was going to suggest tuning the i2c_adapter.retries of the affected
> components, but that only covers EGAIN and not EREMOTEIO/ETIMEDOUT that
> afflicts us. With the alteration to only retry the transfer of the
> affected block, this looks to be a reasonable idea and complements the
> logic to retry corrupted transfers.
> -Chris
>
> ---
> ?drivers/gpu/drm/drm_edid.c | ? 44
> ++--
> ?1 files changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index a245d17..ddc3da9 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -230,24 +230,32 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> ? ? ? ? ? ? ? ? ? ? ?int block, int len)
> ?{
> ? ? ? ?unsigned char start = block * EDID_LENGTH;
> - ? ? ? struct i2c_msg msgs[] = {
> - ? ? ? ? ? ? ? {
> - ? ? ? ? ? ? ? ? ? ? ? .addr ? = DDC_ADDR,
> - ? ? ? ? ? ? ? ? ? ? ? .flags ?= 0,
> - ? ? ? ? ? ? ? ? ? ? ? .len ? ?= 1,
> - ? ? ? ? ? ? ? ? ? ? ? .buf ? ?= &start,
> - ? ? ? ? ? ? ? }, {
> - ? ? ? ? ? ? ? ? ? ? ? .addr ? = DDC_ADDR,
> - ? ? ? ? ? ? ? ? ? ? ? .flags ?= I2C_M_RD,
> - ? ? ? ? ? ? ? ? ? ? ? .len ? ?= len,
> - ? ? ? ? ? ? ? ? ? ? ? .buf ? ?= buf,
> - ? ? ? ? ? ? ? }
> - ? ? ? };
> + ? ? ? int ret, retries = 5;
>
> - ? ? ? if (i2c_transfer(adapter, msgs, 2) == 2)
> - ? ? ? ? ? ? ? return 0;
> + ? ? ? /* The core i2c driver will automatically retry the transfer if the
> + ? ? ? ?* adapter reports EAGAIN. However, we find that bit-banging transfers
> + ? ? ? ?* are susceptible to errors under a heavily loaded machine and
> + ? ? ? ?* generate spurious NAKs and timeouts. Retrying the transfer
> + ? ? ? ?* of the individual block a few times seems to overcome this.
> + ? ? ? ?*/
> + ? ? ? do {
> + ? ? ? ? ? ? ? struct i2c_msg msgs[] = {
> + ? ? ? ? ? ? ? ? ? ? ? {
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .addr ? = DDC_ADDR,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .flags ?= 0,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .len ? ?= 1,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .buf ? ?= &start,
> + ? ? ? ? ? ? ? ? ? ? ? }, {
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .addr ? = DDC_ADDR,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .flags ?= I2C_M_RD,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .len ? ?= len,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .buf ? ?= buf,
> + ? ? ? ? ? ? ? ? ? ? ? }
> + ? ? ? ? ? ? ? };
> + ? ? ? ? ? ? ? ret = i2c_transfer(adapter, msgs, 2);
> + ? ? ? } while (ret != 2 && --retries);
>
> - ? ? ? return -1;
> + ? ? ? return ret == 2 ? 0 : -1;
> ?}
>
> ?static u8 *
> --
> 1.7.2.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Radeon jittery post 2.6.35
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 > fastmail.fm> 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 at the GRUB screen. Pre-KMS, the X > >> server (or driver got it sorted), and when KMS started, the display > >> stabilized right after the kernel driver was initiated. However, post > >> 2.6.35, I see the jitter is back. > >> > >> I've spent the last month trying to bisect it, but pretty much failed. > >> It appears that versions closer to 2.6.38-rcX are more prone to display > >> jitter, while 2.6.36 or so can have many successful runs. It also > >> appears to be related to device power-on order, or so I've come to > >> believe; A stable display can turn jittery, just by power cycling the TV. > >> Some further testing on a clean rc8 suggests that the jitter seen there can reliably be removed by power cycling the TV while in X, or starting X with the TV off. I'm tempted to think that something makes too much out of bad info collected from the TV, and falls backs to saner defaults if the TV has nothing to say. I've seen in the logs that the EDID is disliked: [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID Not sure if that is related though (cannot seem to be able to provoke that error message right now) -A
Radeon jittery post 2.6.35
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 > > fastmail.fm> 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 at the GRUB screen. Pre-KMS, the X >> >> server (or driver got it sorted), and when KMS started, the display >> >> stabilized right after the kernel driver was initiated. However, post >> >> 2.6.35, I see the jitter is back. >> >> >> >> I've spent the last month trying to bisect it, but pretty much failed. >> >> It appears that versions closer to 2.6.38-rcX are more prone to display >> >> jitter, while 2.6.36 or so can have many successful runs. It also >> >> appears to be related to device power-on order, or so I've come to >> >> believe; A stable display can turn jittery, just by power cycling the TV. >> >> > > Some further testing on a clean rc8 suggests that the jitter seen > there can ?reliably be removed by power cycling the TV while in X, > or starting X with the TV off. > > I'm tempted to think that something makes too much out of bad > info collected from the TV, and falls backs to saner defaults if > the TV has nothing to say. > > I've seen in the logs that the EDID is disliked: > [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but > no|invalid EDID > Not sure if that is related though (cannot seem to be able to provoke > that error message right now) > > -A EDID failure could very well explain it, EDID retrieval seems to fails on some GPU under some circonstance (when there is CPU load that interfer with i2c timing i guess). Does the log have the edid failure message when the tv is jittering ? Or is it the otherway around ? Cheers, Jerome
Radeon jittery post 2.6.35
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 > > fastmail.fm> 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 at the GRUB screen. Pre-KMS, the X >> >> server (or driver got it sorted), and when KMS started, the display >> >> stabilized right after the kernel driver was initiated. However, post >> >> 2.6.35, I see the jitter is back. >> >> >> >> I've spent the last month trying to bisect it, but pretty much failed. >> >> It appears that versions closer to 2.6.38-rcX are more prone to display >> >> jitter, while 2.6.36 or so can have many successful runs. It also >> >> appears to be related to device power-on order, or so I've come to >> >> believe; A stable display can turn jittery, just by power cycling the TV. >> >> > > Some further testing on a clean rc8 suggests that the jitter seen > there can ?reliably be removed by power cycling the TV while in X, > or starting X with the TV off. > > I'm tempted to think that something makes too much out of bad > info collected from the TV, and falls backs to saner defaults if > the TV has nothing to say. > > I've seen in the logs that the EDID is disliked: > [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but > no|invalid EDID > Not sure if that is related though (cannot seem to be able to provoke > that error message right now) Try booting with radeon.audio=0 on 2.6.38rc, some TVs have problems with the hdmi packets we send by default. disabling audio will treat the hdmi like dvi. Alex > > -A > > > >
[PATCH] drm: Retry i2c transfer of EDID block after failure
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 > --- I'm currently testing this. It boots, but to see if it fixes the issue, I'll have to run some more tests. Note that this patch is subject to .37-table and probably earlier releases, too. -- Greetings, Michael.
[PATCH] ACPI/Intel: Rework Opregion support
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 this. >> >> They do give us fusion hw; before launch even. ?That's why we had >> Linux support before hw was available publicly. ?My board just >> happened to get bricked recently during a failed bios upgrade. >> A new one is on the way. > > Okay, that's better than I thought. I remember a dev saying that > no one had Fusion hardware, that's where I got this notion from. > >> Also we are looking into a potential release of >> UVD, but unfortunately, our decode hw is intimately tied in with >> our drm implementation and if someone managed to use the released >> information to compromise the drm in our windows driver it would very >> negatively impact our ability to sell into the windows market and >> would probably get the open source graphics initiative shut down. > > Are you talking about HDCP or something else? Because the HDCP master > key already leaked, so the whole security aspect of it is already a > joke, open source UVD won't make any difference. > 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. > Basically you're telling me that I or someone else should reverse > engineer de Catalyst driver and break all drm before you consider > opening up UVD? I'd argue that opening up UVD now is more secure > because it takes away the only morivation to break UVD's drm. > > Alternatively, can't you open up UVD spec except the drm bits, > so people can at least write their own UVD driver to watch > unencrypted data? Without going into detail, they are very intertwined. The hw was designed long before we planned to support open source as much as we are now. Fortunately, we have been working with our hw teams to make future UVD implementations take the open source driver into account. > > It would be nice to have an open source Fusion based media player/ > IPTV decoder, but I guess that's hoping for too much. > > I understand if AMD/ATI wants to keep its 3D driver secret, but > hardware video decoding?! If you have to keep it secret it means > shortcuts were taken and it's all insecure anyway. That if it gets > broken the Open source driver gets blamed is ridiculous and more > politics than anything else. We don't keep the 3D engine secret. Most of the code we've written and specs we've released are 3D engine stuff. Fortunately 3D is less tied up in drm compared to video. It's all about mitigating risk. Imagine you run a company and someone asks you this: "Can we release programming info for a part of our chip to support 2-3% of our market that may put at risk 90% of our market?" What would you do? The reason the review is taking so long is that we want to be real sure that the risk is safe. > > This is getting more and more off-topic though, sorry for the noise. > Agreed. Alex > Greetings, > > Indan > > >
