Re: [Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing
Two things I've noticed: - Why not dev->mode_config.mutex? I was under the impression that mode_config.mutex protects most of the modesetting state and dev->struct_mutex protects things related to the gpu execution cores (i.e. all things gem), with struct_mutex nested within mode_config.mutex. It's hazy at the edges and likely broken in tons of corner cases, but still ... This has also the benefit that it won't stall execbuf. - And a nitpick: Why the dev_priv->dev indirection, when dev is already lying around? -Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/i915: Delay 250ms before running the hotplug code
queue_delayed_work? Plays nicer with other workqueue-items. -Daniel PS: Scrap my other mail, just noticed that the merged patched r-b'ed by Jesse uses the mode_config mutex. -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm pull for -rc1
Hi Linus, Main drm pull request for -rc1, main highlights, Nouveau: open source fermi ucode, per-client gpu address spaces for nv50 and up. Intel: FBC cleanups (on by default now), high color support, ring frequency scaling, shared LLC support, and hangcheck module disabling. radeon: initial compute shader support for evergreen, pageflip changes, powerpc/big endian fixes core: misc changes, nothing major. (and btw I know Keith has a lot of fixes into next merges, its hard to balance the requirement about not merging with the fact his QA team need to test merged trees and I want to pull what the QA team has tested). Dave. The following changes since commit 620917de59eeb934b9f8cf35cc2d95c1ac8ed0fc: Linux 3.0-rc7 (2011-07-11 16:51:52 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-core-next Alan Cox (1): drm/gem: add support for private objects Alex Deucher (5): drm/radeon/kms: set dma_copy to NULL for r6xx+ drm/radeon/kms: add initial CS checker support for compute drm/radeon/kms: add info query for backend map drm/radeon/kms: fix i2c map for rv250/280 drm/radeon/kms: add missing vddci setting on NI+ Ben Skeggs (64): drm/gem: add hooks to notify driver when object handle is created/destroyed drm/nvc0/fb: allocate page for some unknown PFFB object drm/nvc0/fifo: fix typos in unload_context drm/nvc0/gr: macro to determine fermi class, will use it in a few places drm/nvc0/gr: 0x9197/0x9297 state init drm/nvc0/gr: some initial state modifications drm/nvc0/gr: enable 0xc8/0xce support, no idea if it works or not.. drm/nvc1/gr: switch on acceleration support drm/nouveau: default to noaccel on 0xc1/0xc8/0xce for now drm/nvc0: fix suspend/resume of PGRAPH/PCOPYn drm/nvc0/gr: import and use our own fuc by default drm/nvc0/gr: add some missing magics for 0xc1/0xc8/0xce drm/nvc0/gr: calculate magicgpc918 ourselves drm/nvc0/gr: fix typo in class9197 init drm/nvc0/gr: fill in some more data for 0xc1/0xc8/0xce drm/nouveau: log if accel is disabled by default on a chipset drm/nv50: DCB table quirks for another busted XFX board drm/nouveau: silence error for missing dac loadval table drm/nouveau: allocate structure to store per-client data drm/nouveau: use NULL file_priv for DRM-created channels drm/nouveau: store a per-client channel list drm/nouveau: no need to update bo.offset from vma after validate drm/nv50-nvc0/vm: don't touch chan_vm drm/nv50-nvc0/vm: take client reference on shared channel vm drm/nv50-nvc0/chan: inherit vm from fpriv, rather than chan_vm directly drm/nouveau: remove 'chan' argument from nouveau_gem_new drm/nouveau/gem: implement stub hooks for GEM object open/close drm/nouveau: modify gpuobj/ntfy takedown ordering drm/nouveau: initialise any vm for a channel before pushbuf/ntfy drm/nouveau: will need to specify channel for vm-ful gpuobj allocations drm/nouveau: skip move_notify() if bo does not have a vma attached drm/nouveau: store bo's page size in nouveau_bo drm/nouveau: create temp vmas for both src and dst of bo moves drm/nouveau: convert some bo.offset use to vma.offset drm/nouveau: convert bo.mem.start usage to bo.offset drm/nv50-nvc0: completely disable relocs drm/nouveau: initial changes to support multiple VMAs per buffer object drm/nv50-nvc0: explicitly map fbcon fb into channel vm drm/nv50-nvc0: explicitly map notifier bo into channel vm drm/nv50-nvc0: explicitly map pushbuf bo into channel vm drm/nv84-nvc0: explicitly map semaphore buffer into channel vm drm/nv50-nvc0: lookup pushbuf virtual address on dma_push drm/nvc0: explicitly map PDISP semaphore buffer into each channel's vm drm/nouveau: fixup gem_info ioctl to return client-specific bo virtual drm/nouveau: remove 'chan' argument from nouveau_bo_new drm/nouveau: remove implicit mapping of every bo into chan_vm drm/nv50: enable use of per-client gpu address space drm/nouveau: add some debug output if nouveau_mm busy at destroy time drm/nvc0: enable per-client address spaces drm/nouveau: fix display takedown order to match reverse init order drm/nouveau: shut lockdep up if last vm ref needs to destroy pgd drm/nouveau: rework vram init/fini ordering a little drm/nouveau: fix null pointer deref on pre-nv50 chipsets drm/nouveau: un-blacklist nvce accel drm/nvc0: push prunk140 irq messages to debug loglevel drm/nouveau: fix off-by-one drm/nouveau: fix fetching vbios from above 4GiB vram addresses drm/nv50/dp: fix hack to work for macbooks booted via EFI drm/nouveau: ignore connector type when deciding digital/analog on DVI-I drm/nouveau: detect disabled d
[Bug 35697] System locks up when watching fullscreen flash video
https://bugs.freedesktop.org/show_bug.cgi?id=35697 Nikos Chantziaras changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #27 from Nikos Chantziaras 2011-07-26 05:28:44 PDT --- Something changed somewhere (no idea where), and I can't reproduce it anymore. -- 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: [Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing
On Tue, Jul 26, 2011 at 1:54 AM, Keith Packard wrote: > From 59b920597999381fab70c485c161dd50590e561a Mon Sep 17 00:00:00 2001 > From: Keith Packard > Date: Mon, 25 Jul 2011 22:37:51 -0700 > Subject: [PATCH] Revert and fix "drm/i915/dp: remove DPMS mode tracking from > DP" > > This reverts commit 885a50147f00a8a80108904bf58a18af357717f3. > > We actually *do* need to track DPMS state so that on hotplug, we don't > retrain the link until DPMS is disabled. > > intel_dp->output_reg = output_reg; > + intel_dp->dpms_mode = -1; Should that be some actual mode constant instead of -1? In any case, this patch, applied manually on top of the struct_mutex fix, seems to work. xset dpms force off turns the display off briefly (presumably X or GNOME helpfully turns it back on), but if I let the display turn off on its own, it comes back. There's still an obnoxious bug, though: I use audio over DP, and when the display turns off, the attached speaker crackles loudly for a second or two. I don't think it's a hardware problem with the monitor, because if I just pull the plug it doesn't make any noise. Should the driver do something to drop the audio link before turning off the DP link as a whole? --Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: Fix ECS A740GM-M DVI-D EDID error flooding problem
On Wed, Jul 20, 2011 at 4:34 AM, wrote:
> From: Thomas Reim
>
> ECS A740GM-M with ATI RADEON 2100 sends data to i2c bus
> for a DVI connector that is not implemented/existent on the board.
>
> Fix by applying extented DDC probing for this connector.
>
> Requires [PATCH] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding
> problem
>
> BugLink: http://bugs.launchpad.net/bugs/810926
>
> Signed-off-by: Thomas Reim
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_connectors.c | 9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index 2e70be2..82dacc6 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -449,6 +449,15 @@ static bool radeon_connector_needs_extended_probe(struct
> radeon_device *dev,
> (supported_device == ATOM_DEVICE_DFP2_SUPPORT))
> return true;
> }
> + /* ECS A740GM-M with ATI RADEON 2100 sends data to i2c bus
> + * for a DVI connector that is not implemented */
> + if ((dev->pdev->device == 0x796e) &&
> + (dev->pdev->subsystem_vendor == 0x1019) &&
> + (dev->pdev->subsystem_device == 0x2615)) {
> + if ((connector_type == DRM_MODE_CONNECTOR_DVID) &&
> + (supported_device == ATOM_DEVICE_DFP2_SUPPORT))
> + return true;
> + }
>
> /* Default: no EDID header probe required for DDC probing */
> return false;
> --
> 1.7.1
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?
On Sat, Jul 23, 2011 at 11:10:53AM -0400, Alex Deucher wrote: > On Fri, Jul 22, 2011 at 5:31 PM, Kirill Smelkov wrote: > > On Sat, Jul 23, 2011 at 01:08:14AM +0400, Kirill Smelkov wrote: > >> On Fri, Jul 22, 2011 at 01:50:04PM -0700, Keith Packard wrote: > > > >> > You're right, of course -- UMS is a huge wart on the kernel driver at > >> > this point, keeping it working while also adding new functionality > >> > continues to cause challenges. We tend to expect that most people will > >> > run reasonably contemporaneous kernel and user space code, and so three > >> > years after the switch, it continues to surprise us when someone > >> > actually tries UMS. > >> > >> We are planning upgrade to KMS too. The kernel is upgraded more often > >> compared to userspace, because of already mentioned (thanks!) "no > >> regression" rule. Userspace is more complex and more work in my context, > >> so it is lagging, but eventually we'll get there. > > > > Also wanted to say, that if whole X could be built, like the kernel, from > > one > > repo without multirepo-setup tool, with 100% reliable working > > incremental rebuild, etc... it would be a bit easier to upgrade X too. > > > > Sorry for being a bit offtopic, could not resist. I was keeping that > > though in my head for ~ 2 years already, and now had a chance to mention it. > > You don't have to rebuild all of X to use KMS. In most cases, you > just need to update the ddx for your card. I meant the rebuilt not to use KMS, but general case. To me the kernel has one of the great advantage of being lots of self-consistent code because of being maintained in one repo + good build system + good development process. And as the result it is (relatively) easy to upgrade. Anyway, this is just a note from both kernel and X stranger, so whatever... Kirill ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem
On Thu, Jul 7, 2011 at 3:01 PM, Alex Deucher wrote: > On Wed, Jul 6, 2011 at 7:30 PM, wrote: >> From: Thomas Reim Guys I really still hate this :-) Other OSes must deal with this sort of thing and I can't say they don't do it like this but I can't say for certain this feels like the right answer. My thinking is that we could probably just trust the hot plug detect if its reported on HDMI and DVI-D connectors, we still need to poll DVI-D as the VGA->DVI convertors don't often assert hpd. Am I missing something that this wouldn't fix? otherwise I''ll push these after another few reads. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem
On Tue, Jul 26, 2011 at 9:20 AM, Dave Airlie wrote: > On Thu, Jul 7, 2011 at 3:01 PM, Alex Deucher wrote: >> On Wed, Jul 6, 2011 at 7:30 PM, wrote: >>> From: Thomas Reim > > Guys I really still hate this :-) > > Other OSes must deal with this sort of thing and I can't say they > don't do it like this but I can't say for certain this feels like the > right answer. > I emailed the closed driver display team, but as the issue seems to only afflict certain rs690/rs740 boards, I'm not sure anyone will remember what quirks those boards had as they are about 5 generations old at this point. > My thinking is that we could probably just trust the hot plug detect > if its reported on HDMI and DVI-D connectors, we still need to poll > DVI-D as the VGA->DVI convertors don't often assert hpd. > > Am I missing something that this wouldn't fix? The issue in this case is that the problematic connectors don't have HPD pin wired up and the ddc lines seem to be wired improperly so a ddc probe always reports something connected unless you actually look at the EDID header. For DVI-I we probably have to poll since only the digital portion will assert hpd in most cases. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem
On Tue, Jul 26, 2011 at 10:52 AM, Alex Deucher wrote: > On Tue, Jul 26, 2011 at 9:20 AM, Dave Airlie wrote: >> On Thu, Jul 7, 2011 at 3:01 PM, Alex Deucher wrote: >>> On Wed, Jul 6, 2011 at 7:30 PM, wrote: From: Thomas Reim >> >> Guys I really still hate this :-) >> >> Other OSes must deal with this sort of thing and I can't say they >> don't do it like this but I can't say for certain this feels like the >> right answer. >> > > I emailed the closed driver display team, but as the issue seems to > only afflict certain rs690/rs740 boards, I'm not sure anyone will > remember what quirks those boards had as they are about 5 generations > old at this point. Another possibility is that the closed driver uses the hw i2c engine which may not be affected, or they just tell the hw i2c engine to fetch several bytes and they inspect the result similar to what this patch does. I'll let you know what I hear back. > >> My thinking is that we could probably just trust the hot plug detect >> if its reported on HDMI and DVI-D connectors, we still need to poll >> DVI-D as the VGA->DVI convertors don't often assert hpd. >> >> Am I missing something that this wouldn't fix? > > The issue in this case is that the problematic connectors don't have > HPD pin wired up and the ddc lines seem to be wired improperly so a > ddc probe always reports something connected unless you actually look > at the EDID header. For DVI-I we probably have to poll since only the > digital portion will assert hpd in most cases. > > Alex > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing
On Tue, 26 Jul 2011 09:24:39 +0200, Daniel Vetter wrote: > Two things I've noticed: > - Why not dev->mode_config.mutex? You're right, of course. I noticed that just after posting that version and updated it; the updated version is on my drm-intel-fixes branch already (having been reviewed by Jesse). > - And a nitpick: Why the dev_priv->dev indirection, when dev is > already lying around? All nicely cleaned up by using &mode_config->mutex instead :-) Thanks for looking it over! -- keith.pack...@intel.com pgp5OsayjzgDM.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/i915: Delay 250ms before running the hotplug code
On Tue, 26 Jul 2011 09:44:32 +0200, Daniel Vetter wrote: > queue_delayed_work? Plays nicer with other workqueue-items. Yeah, I'll change this. -- keith.pack...@intel.com pgpifulG3hqfz.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Rename i915_dp_detect_common to intel_dp_get_dpcd
On Mon, 25 Jul 2011 23:36:31 -0700 Keith Packard wrote: > This describes the function better, allowing it to be used where the > DPCD value is relevant. > > Signed-off-by: Keith Packard > --- Ah I see you've addressed my previous comment already. :) You can add my Reviewed-by: Jesse Barnes to 1/5 and 2/5. -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/5] drm/i915: In intel_dp_init, replace read of DPCD with intel_dp_get_dpcd
On Mon, 25 Jul 2011 23:36:32 -0700
Keith Packard wrote:
> Eliminates an open-coded read and also gains the retry behaviour of
> intel_dp_get_dpcd, which seems like a good idea.
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/intel_dp.c |8 +++-
> 1 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 41674e1..9f134d2 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2015,7 +2015,7 @@ intel_dp_init(struct drm_device *dev, int output_reg)
>
> /* Cache some DPCD data in the eDP case */
> if (is_edp(intel_dp)) {
> - int ret;
> + bool ret;
> u32 pp_on, pp_div;
>
> pp_on = I915_READ(PCH_PP_ON_DELAYS);
> @@ -2028,11 +2028,9 @@ intel_dp_init(struct drm_device *dev, int output_reg)
> dev_priv->panel_t12 *= 100; /* t12 in 100ms units */
>
> ironlake_edp_panel_vdd_on(intel_dp);
> - ret = intel_dp_aux_native_read(intel_dp, DP_DPCD_REV,
> -intel_dp->dpcd,
> -sizeof(intel_dp->dpcd));
> + ret = intel_dp_get_dpcd(intel_dp);
> ironlake_edp_panel_vdd_off(intel_dp);
> - if (ret == sizeof(intel_dp->dpcd)) {
> + if (ret) {
> if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11)
> dev_priv->no_aux_handshake =
> intel_dp->dpcd[DP_MAX_DOWNSPREAD] &
Reviewed-by: Jesse Barnes
Now we just have to enable fast link training in the eDP case (and
optionally when we know the DP monitor hasn't changed, just DPMS'd).
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Use dp_detect_common in hotplug helper function
On Mon, 25 Jul 2011 23:36:30 -0700 Keith Packard wrote: > This uses the common dpcd reading routine, i915_dp_detect_common, > instead of open-coding a call to intel_dp_aux_native_read. Besides > reducing duplicated code, this also gains the read retries which > may be necessary when a cable is first plugged back in and the link > needs to be retrained. > > Signed-off-by: Keith Packard > --- > drivers/gpu/drm/i915/intel_dp.c | 39 > +++ > 1 files changed, 19 insertions(+), 20 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index dcc7ae6..45db810 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -1567,6 +1567,20 @@ intel_dp_link_down(struct intel_dp *intel_dp) > POSTING_READ(intel_dp->output_reg); > } > > +static enum drm_connector_status > +i915_dp_detect_common(struct intel_dp *intel_dp) Maybe you can fix the prefix of this function while you're at it since it's not i915 or even i9xx specific? -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 5/5] drm/i915: DP_PIPE_ENABLED must check transcoder on CPT
On Mon, 25 Jul 2011 23:36:34 -0700 Keith Packard wrote: > Display port pipe selection on CPT is not done with a bit in the > output register, rather it is controlled by a couple of bits in the > separate transcoder register which indicate which display port output > is connected to the transcoder. > > This patch replaces the simplistic macro DP_PIPE_ENABLED with the > rather more complicated function dp_pipe_enabled which checks the > output register to see if that is enabled, and then goes on to either > check the output register pipe selection bit (on non-CPT) or the > transcoder DP selection bits (on CPT). > > Before this patch, any time the mode of pipe A was changed, any > display port outputs on pipe B would get disabled as > intel_disable_pch_ports would ensure that the mode setting operation > could occur on pipe A without interference from other outputs > connected to that pch port > > Signed-off-by: Keith Packard > --- Ah nice catch. I expect one day we'll have all the chipset and PCH differences coded... Reviewed-by: Jesse Barnes -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] drm/i915: A selection of display port fixes
On Mon, 2011-07-25 at 23:36 -0700, Keith Packard wrote: > [PATCH 1/5] drm/i915: Use dp_detect_common in hotplug helper > [PATCH 2/5] drm/i915: Rename i915_dp_detect_common to > [PATCH 3/5] drm/i915: In intel_dp_init, replace read of DPCD with > > These three are simple cleanups to centralize all places where the > DPCD block was read from the device. Now everyone shares the same > function, and that function retries the reads. Reviewed-by: Adam Jackson > [PATCH 4/5] drm/i915: Delay 250ms before running the hotplug code > > I was experimenting with DP hotplugging -- moving the plug in and out > of the jack very slowly and discovered that the hotplug interrupt > occurred well before or after the link for the aux data channel was > connected or disconnected. The result of this was that a sufficiently > rapid cycle back through user mode could easily beat the motion of the > plug and cause the hotplug detection to get the wrong status. Sticking > a 250ms delay before doing anything gives the user sufficient time to > actually get the plug connected or disconnected. At the very least this should instead be queue_delayed_work(). But if we're going to delay, can we instead set up PCH_PORT_HOTPLUG to do a 100ms delay for us? I'll try this locally, at any rate. > [PATCH 5/5] drm/i915: DP_PIPE_ENABLED must check transcoder on CPT > > > > Turns out the bug wasn't that the mode setting code was doing it wrong > and turning the DP2 output off intentionally as a part of the mode > change. Instead, the intel driver was trying to adjust the PCH link > for the LVDS1 output and thought it needed to turn the DP2 output off > because it mistakenly believed the DP2 output was sharing the same > pipe as the LVDS1 output. Just a matter of using the wrong mechanism > to detect which pipe the DP2 output was connected to. Reviewed-by: Adam Jackson - ajax signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing
On Tue, 26 Jul 2011 08:23:13 -0700 Keith Packard wrote: > On Tue, 26 Jul 2011 09:24:39 +0200, Daniel Vetter wrote: > > Two things I've noticed: > > > - Why not dev->mode_config.mutex? > > You're right, of course. I noticed that just after posting that version > and updated it; the updated version is on my drm-intel-fixes branch > already (having been reviewed by Jesse). > > > - And a nitpick: Why the dev_priv->dev indirection, when dev is > > already lying around? > > All nicely cleaned up by using &mode_config->mutex instead :-) > > Thanks for looking it over! I'd like to amend my reviewed by and say the lock shouldn't be held around the call to the drm helper function. It queues some work that also takes the mode config lock, which will break. So you can drop it before that... Previously I had only checked our internal driver callbacks but missed that the lock was held across the helper too. -- 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 39572] New: Cogs: GPU hang
https://bugs.freedesktop.org/show_bug.cgi?id=39572 Summary: Cogs: GPU hang Product: Mesa Version: git Platform: Other URL: http://www.humblebundle.com/ OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: s...@whiz.se Created an attachment (id=49589) --> (https://bugs.freedesktop.org/attachment.cgi?id=49589) dmesg output The game Cogs (from the Humble Indie Bundle) is causing a GPU hang. Unless the process is killed quickly the reset functionality doesn't seem to work so a full reboot is necessary. The hang only happens if shadows is turned on in the game options, which it is by default so the hang happens right after launching the game. No difference between 7.11 and git master. Something else seems to be wrong with the game as it's pegging the CPU at 100% and performance is just a few frames per second. System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: REDWOOD -- Model: XFX Radeon HD 5670 1GB -- Display connector: DVI -- xf86-video-ati: 6.14.2 -- xserver: 1.10.2.902 -- mesa: 860c51d82711936d343b55aafb46befc8c032fe6 -- drm: 2.4.26 -- kernel: 3.0 -- 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
[PATCH] drm/radeon/kms: disable CP interrupt when disabling interrupt
From: Jerome Glisse
Some CP interrupt were left enabled when disabling interrupt.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm/radeon/r600.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 14dce9f..852565d 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2434,7 +2434,7 @@ void evergreen_disable_interrupt_state(struct
radeon_device *rdev)
{
u32 tmp;
- WREG32(CP_INT_CNTL, CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE);
+ WREG32(CP_INT_CNTL, 0);
WREG32(GRBM_INT_CNTL, 0);
WREG32(INT_MASK + EVERGREEN_CRTC0_REGISTER_OFFSET, 0);
WREG32(INT_MASK + EVERGREEN_CRTC1_REGISTER_OFFSET, 0);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index aa5571b..d2c74e7 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2900,7 +2900,7 @@ static void r600_disable_interrupt_state(struct
radeon_device *rdev)
{
u32 tmp;
- WREG32(CP_INT_CNTL, CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE);
+ WREG32(CP_INT_CNTL, 0);
WREG32(GRBM_INT_CNTL, 0);
WREG32(DxMODE_INT_MASK, 0);
WREG32(D1GRPH_INTERRUPT_CONTROL, 0);
--
1.7.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: disable CP interrupt when disabling interrupt
On Tue, Jul 26, 2011 at 5:28 PM, wrote:
> From: Jerome Glisse
>
> Some CP interrupt were left enabled when disabling interrupt.
>
Is there a specific issue this fixes? The bits are not interrupt
sources per se but rather are related to the internal state of the
interrupt controller and should always be enabled.
Alex
> Signed-off-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/evergreen.c | 2 +-
> drivers/gpu/drm/radeon/r600.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index 14dce9f..852565d 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -2434,7 +2434,7 @@ void evergreen_disable_interrupt_state(struct
> radeon_device *rdev)
> {
> u32 tmp;
>
> - WREG32(CP_INT_CNTL, CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE);
> + WREG32(CP_INT_CNTL, 0);
> WREG32(GRBM_INT_CNTL, 0);
> WREG32(INT_MASK + EVERGREEN_CRTC0_REGISTER_OFFSET, 0);
> WREG32(INT_MASK + EVERGREEN_CRTC1_REGISTER_OFFSET, 0);
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index aa5571b..d2c74e7 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -2900,7 +2900,7 @@ static void r600_disable_interrupt_state(struct
> radeon_device *rdev)
> {
> u32 tmp;
>
> - WREG32(CP_INT_CNTL, CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE);
> + WREG32(CP_INT_CNTL, 0);
> WREG32(GRBM_INT_CNTL, 0);
> WREG32(DxMODE_INT_MASK, 0);
> WREG32(D1GRPH_INTERRUPT_CONTROL, 0);
> --
> 1.7.3.2
>
> ___
> 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: [PATCH] drm/radeon/kms: disable CP interrupt when disabling interrupt
On Tue, Jul 26, 2011 at 5:47 PM, Alex Deucher wrote: > On Tue, Jul 26, 2011 at 5:28 PM, wrote: >> From: Jerome Glisse >> >> Some CP interrupt were left enabled when disabling interrupt. >> > > Is there a specific issue this fixes? The bits are not interrupt > sources per se but rather are related to the internal state of the > interrupt controller and should always be enabled. > > Alex > Might, might not i have seen flgrx unsetting this bit on my rv670 which reboot with the radeon driver. Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix version comment due to merge timing
From: Alex Deucher Compute cs support was actually added in 2.11.0 rather than 2.10.0, but the patch was written prior. Update comment to match. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_drv.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c index 85f033f..e71d2ed 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -50,8 +50,8 @@ * 2.7.0 - fixups for r600 2D tiling support. (no external ABI change), add eg dyn gpr regs * 2.8.0 - pageflip support, r500 US_FORMAT regs. r500 ARGB2101010 colorbuf, r300->r500 CMASK, clock crystal query * 2.9.0 - r600 tiling (s3tc,rgtc) working, SET_PREDICATION packet 3 on r600 + eg, backend query - * 2.10.0 - fusion 2D tiling, initial compute support for the CS checker - * 2.11.0 - backend map + * 2.10.0 - fusion 2D tiling + * 2.11.0 - backend map, initial compute support for the CS checker */ #define KMS_DRIVER_MAJOR 2 #define KMS_DRIVER_MINOR 11 -- 1.7.1.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm: add plane support
2011/7/25 Rob Clark :
> On Mon, Jul 25, 2011 at 3:18 AM, Joonyoung Shim wrote:
>> 2011/7/22 Jesse Barnes :
>>> On Thu, 21 Jul 2011 19:30:00 +0900
>>> Joonyoung Shim wrote:
>>>
Hi,
simple questions :)
2011/6/21 Jesse Barnes :
> Planes are a bit like half-CRTCs. ?They have a location and fb, but
> don't drive outputs directly. ?Add support for handling them to the core
> KMS code.
>
> Signed-off-by: Jesse Barnes
> ---
> ?drivers/gpu/drm/drm_crtc.c | ?235
> +++-
> ?drivers/gpu/drm/drm_drv.c ?| ? ?3 +
> ?include/drm/drm.h ? ? ? ? ?| ? ?3 +
> ?include/drm/drm_crtc.h ? ? | ? 73 ++-
> ?include/drm/drm_mode.h ? ? | ? 35 +++
> ?5 files changed, 346 insertions(+), 3 deletions(-)
>
snip
> diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
> index c4961ea..fa6d348 100644
> --- a/include/drm/drm_mode.h
> +++ b/include/drm/drm_mode.h
> @@ -120,6 +120,41 @@ struct drm_mode_crtc {
> ? ? ? ?struct drm_mode_modeinfo mode;
> ?};
>
> +/* Planes blend with or override other bits on the CRTC */
> +struct drm_mode_set_plane {
> + ? ? ? __u32 plane_id;
> + ? ? ? __u32 crtc_id;
> + ? ? ? __u32 fb_id; /* fb object contains surface format type */
> +
> + ? ? ? /* Signed dest location allows it to be partially off screen */
> + ? ? ? __s32 crtc_x, crtc_y;
Is this location offset from base(0, 0) of fb for plane, or from base
of crtc(mode)?
>>>
>>> This is the offset on the crtc specifically (which could be displaying
>>> a nonzero offset of a given fb).
>>>
>>
>> Then if i want to use the specific area of a given fb for overlay, how
>> can we know the offset on a given fb?
>> In other words, can we use the specific offset from fb to origin(base
>> pointer) of plane? or can we use each overlays from each specific
>> offsets of one fb?
>
> The x,y parameters give the position within the fb, the crtc_x,crtc_y
> parameters give the position within the crtc (screen)..
>
Hmm, i can't understand well, which x, y parameters? As you know,
struct drm_mode_set_plane hasn't x , y parameters for fb,
so how can know x, y parameters?
> So if you had full-screen video spanning two 1280x1024 displays, where
> the video was 1080p. ?Say the video was nearly but not completely
> full-screen (say, 5 pixel border all around.. just to pick some #'s):
>
> display one:
> ?plane: ?x,y=0,0, crtc_x,crtc_y=5,5, crtc_w=1275, crtc_h=1014
>
> display two: ?(to right of display one)
> ?plane: x,y=960,0, crtc_x,crtc_y=0,5, crtc_w=1275, crtc_h=1014
>
> (or at least that is my understanding..)
>
> BR,
> -R
>
>> Thanks.
>>
>> --
>> - Joonyoung Shim
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
--
- Joonyoung Shim
[Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing
Two things I've noticed: - Why not dev->mode_config.mutex? I was under the impression that mode_config.mutex protects most of the modesetting state and dev->struct_mutex protects things related to the gpu execution cores (i.e. all things gem), with struct_mutex nested within mode_config.mutex. It's hazy at the edges and likely broken in tons of corner cases, but still ... This has also the benefit that it won't stall execbuf. - And a nitpick: Why the dev_priv->dev indirection, when dev is already lying around? -Daniel -- Daniel Vetter daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
[PATCH 4/5] drm/i915: Delay 250ms before running the hotplug code
queue_delayed_work? Plays nicer with other workqueue-items. -Daniel PS: Scrap my other mail, just noticed that the merged patched r-b'ed by Jesse uses the mode_config mutex. -- Daniel Vetter daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
[git pull] drm pull for -rc1
Hi Linus, Main drm pull request for -rc1, main highlights, Nouveau: open source fermi ucode, per-client gpu address spaces for nv50 and up. Intel: FBC cleanups (on by default now), high color support, ring frequency scaling, shared LLC support, and hangcheck module disabling. radeon: initial compute shader support for evergreen, pageflip changes, powerpc/big endian fixes core: misc changes, nothing major. (and btw I know Keith has a lot of fixes into next merges, its hard to balance the requirement about not merging with the fact his QA team need to test merged trees and I want to pull what the QA team has tested). Dave. The following changes since commit 620917de59eeb934b9f8cf35cc2d95c1ac8ed0fc: Linux 3.0-rc7 (2011-07-11 16:51:52 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-core-next Alan Cox (1): drm/gem: add support for private objects Alex Deucher (5): drm/radeon/kms: set dma_copy to NULL for r6xx+ drm/radeon/kms: add initial CS checker support for compute drm/radeon/kms: add info query for backend map drm/radeon/kms: fix i2c map for rv250/280 drm/radeon/kms: add missing vddci setting on NI+ Ben Skeggs (64): drm/gem: add hooks to notify driver when object handle is created/destroyed drm/nvc0/fb: allocate page for some unknown PFFB object drm/nvc0/fifo: fix typos in unload_context drm/nvc0/gr: macro to determine fermi class, will use it in a few places drm/nvc0/gr: 0x9197/0x9297 state init drm/nvc0/gr: some initial state modifications drm/nvc0/gr: enable 0xc8/0xce support, no idea if it works or not.. drm/nvc1/gr: switch on acceleration support drm/nouveau: default to noaccel on 0xc1/0xc8/0xce for now drm/nvc0: fix suspend/resume of PGRAPH/PCOPYn drm/nvc0/gr: import and use our own fuc by default drm/nvc0/gr: add some missing magics for 0xc1/0xc8/0xce drm/nvc0/gr: calculate magicgpc918 ourselves drm/nvc0/gr: fix typo in class9197 init drm/nvc0/gr: fill in some more data for 0xc1/0xc8/0xce drm/nouveau: log if accel is disabled by default on a chipset drm/nv50: DCB table quirks for another busted XFX board drm/nouveau: silence error for missing dac loadval table drm/nouveau: allocate structure to store per-client data drm/nouveau: use NULL file_priv for DRM-created channels drm/nouveau: store a per-client channel list drm/nouveau: no need to update bo.offset from vma after validate drm/nv50-nvc0/vm: don't touch chan_vm drm/nv50-nvc0/vm: take client reference on shared channel vm drm/nv50-nvc0/chan: inherit vm from fpriv, rather than chan_vm directly drm/nouveau: remove 'chan' argument from nouveau_gem_new drm/nouveau/gem: implement stub hooks for GEM object open/close drm/nouveau: modify gpuobj/ntfy takedown ordering drm/nouveau: initialise any vm for a channel before pushbuf/ntfy drm/nouveau: will need to specify channel for vm-ful gpuobj allocations drm/nouveau: skip move_notify() if bo does not have a vma attached drm/nouveau: store bo's page size in nouveau_bo drm/nouveau: create temp vmas for both src and dst of bo moves drm/nouveau: convert some bo.offset use to vma.offset drm/nouveau: convert bo.mem.start usage to bo.offset drm/nv50-nvc0: completely disable relocs drm/nouveau: initial changes to support multiple VMAs per buffer object drm/nv50-nvc0: explicitly map fbcon fb into channel vm drm/nv50-nvc0: explicitly map notifier bo into channel vm drm/nv50-nvc0: explicitly map pushbuf bo into channel vm drm/nv84-nvc0: explicitly map semaphore buffer into channel vm drm/nv50-nvc0: lookup pushbuf virtual address on dma_push drm/nvc0: explicitly map PDISP semaphore buffer into each channel's vm drm/nouveau: fixup gem_info ioctl to return client-specific bo virtual drm/nouveau: remove 'chan' argument from nouveau_bo_new drm/nouveau: remove implicit mapping of every bo into chan_vm drm/nv50: enable use of per-client gpu address space drm/nouveau: add some debug output if nouveau_mm busy at destroy time drm/nvc0: enable per-client address spaces drm/nouveau: fix display takedown order to match reverse init order drm/nouveau: shut lockdep up if last vm ref needs to destroy pgd drm/nouveau: rework vram init/fini ordering a little drm/nouveau: fix null pointer deref on pre-nv50 chipsets drm/nouveau: un-blacklist nvce accel drm/nvc0: push prunk140 irq messages to debug loglevel drm/nouveau: fix off-by-one drm/nouveau: fix fetching vbios from above 4GiB vram addresses drm/nv50/dp: fix hack to work for macbooks booted via EFI drm/nouveau: ignore connector type when deciding digital/analog on DVI-I drm/nouveau: detect disabled d
[Bug 35697] System locks up when watching fullscreen flash video
https://bugs.freedesktop.org/show_bug.cgi?id=35697 Nikos Chantziaras changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #27 from Nikos Chantziaras 2011-07-26 05:28:44 PDT --- Something changed somewhere (no idea where), and I can't reproduce it anymore. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing
On Tue, Jul 26, 2011 at 1:54 AM, Keith Packard wrote: > From 59b920597999381fab70c485c161dd50590e561a Mon Sep 17 00:00:00 2001 > From: Keith Packard > Date: Mon, 25 Jul 2011 22:37:51 -0700 > Subject: [PATCH] Revert and fix "drm/i915/dp: remove DPMS mode tracking from > ?DP" > > This reverts commit 885a50147f00a8a80108904bf58a18af357717f3. > > We actually *do* need to track DPMS state so that on hotplug, we don't > retrain the link until DPMS is disabled. > > ? ? ? ?intel_dp->output_reg = output_reg; > + ? ? ? intel_dp->dpms_mode = -1; Should that be some actual mode constant instead of -1? In any case, this patch, applied manually on top of the struct_mutex fix, seems to work. xset dpms force off turns the display off briefly (presumably X or GNOME helpfully turns it back on), but if I let the display turn off on its own, it comes back. There's still an obnoxious bug, though: I use audio over DP, and when the display turns off, the attached speaker crackles loudly for a second or two. I don't think it's a hardware problem with the monitor, because if I just pull the plug it doesn't make any noise. Should the driver do something to drop the audio link before turning off the DP link as a whole? --Andy
[PATCH] drm/radeon: Fix ECS A740GM-M DVI-D EDID error flooding problem
On Wed, Jul 20, 2011 at 4:34 AM, wrote:
> From: Thomas Reim
>
> ? ECS A740GM-M with ATI RADEON 2100 sends data to i2c bus
> ? for a DVI connector that is not implemented/existent on the board.
>
> ? Fix by applying extented DDC probing for this connector.
>
> ? Requires [PATCH] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding
> problem
>
> ? BugLink: http://bugs.launchpad.net/bugs/810926
>
> Signed-off-by: Thomas Reim
Reviewed-by: Alex Deucher
> ---
> ?drivers/gpu/drm/radeon/radeon_connectors.c | ? ?9 +
> ?1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index 2e70be2..82dacc6 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -449,6 +449,15 @@ static bool radeon_connector_needs_extended_probe(struct
> radeon_device *dev,
> ? ? ? ? ? ? ? ? ? ?(supported_device == ATOM_DEVICE_DFP2_SUPPORT))
> ? ? ? ? ? ? ? ? ? ? ? ?return true;
> ? ? ? ?}
> + ? ? ? /* ECS A740GM-M with ATI RADEON 2100 sends data to i2c bus
> + ? ? ? ?* for a DVI connector that is not implemented */
> + ? ? ? if ((dev->pdev->device == 0x796e) &&
> + ? ? ? ? ? (dev->pdev->subsystem_vendor == 0x1019) &&
> + ? ? ? ? ? (dev->pdev->subsystem_device == 0x2615)) {
> + ? ? ? ? ? ? ? if ((connector_type == DRM_MODE_CONNECTOR_DVID) &&
> + ? ? ? ? ? ? ? ? ? (supported_device == ATOM_DEVICE_DFP2_SUPPORT))
> + ? ? ? ? ? ? ? ? ? ? ? return true;
> + ? ? ? }
>
> ? ? ? ?/* Default: no EDID header probe required for DDC probing */
> ? ? ? ?return false;
> --
> 1.7.1
>
>
[PATCH 2/3] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem
On Thu, Jul 7, 2011 at 3:01 PM, Alex Deucher wrote: > On Wed, Jul 6, 2011 at 7:30 PM, ? wrote: >> From: Thomas Reim Guys I really still hate this :-) Other OSes must deal with this sort of thing and I can't say they don't do it like this but I can't say for certain this feels like the right answer. My thinking is that we could probably just trust the hot plug detect if its reported on HDMI and DVI-D connectors, we still need to poll DVI-D as the VGA->DVI convertors don't often assert hpd. Am I missing something that this wouldn't fix? otherwise I''ll push these after another few reads. Dave.
[PATCH 2/3] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem
On Tue, Jul 26, 2011 at 9:20 AM, Dave Airlie wrote: > On Thu, Jul 7, 2011 at 3:01 PM, Alex Deucher wrote: >> On Wed, Jul 6, 2011 at 7:30 PM, ? wrote: >>> From: Thomas Reim > > Guys I really still hate this :-) > > Other OSes must deal with this sort of thing and I can't say they > don't do it like this but I can't say for certain this feels like the > right answer. > I emailed the closed driver display team, but as the issue seems to only afflict certain rs690/rs740 boards, I'm not sure anyone will remember what quirks those boards had as they are about 5 generations old at this point. > My thinking is that we could probably just trust the hot plug detect > if its reported on HDMI and DVI-D connectors, we still need to poll > DVI-D as the VGA->DVI convertors don't often assert hpd. > > Am I missing something that this wouldn't fix? The issue in this case is that the problematic connectors don't have HPD pin wired up and the ddc lines seem to be wired improperly so a ddc probe always reports something connected unless you actually look at the EDID header. For DVI-I we probably have to poll since only the digital portion will assert hpd in most cases. Alex
[PATCH 2/3] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem
On Tue, Jul 26, 2011 at 10:52 AM, Alex Deucher wrote: > On Tue, Jul 26, 2011 at 9:20 AM, Dave Airlie wrote: >> On Thu, Jul 7, 2011 at 3:01 PM, Alex Deucher >> wrote: >>> On Wed, Jul 6, 2011 at 7:30 PM, ? wrote: From: Thomas Reim >> >> Guys I really still hate this :-) >> >> Other OSes must deal with this sort of thing and I can't say they >> don't do it like this but I can't say for certain this feels like the >> right answer. >> > > I emailed the closed driver display team, but as the issue seems to > only afflict certain rs690/rs740 boards, I'm not sure anyone will > remember what quirks those boards had as they are about 5 generations > old at this point. Another possibility is that the closed driver uses the hw i2c engine which may not be affected, or they just tell the hw i2c engine to fetch several bytes and they inspect the result similar to what this patch does. I'll let you know what I hear back. > >> My thinking is that we could probably just trust the hot plug detect >> if its reported on HDMI and DVI-D connectors, we still need to poll >> DVI-D as the VGA->DVI convertors don't often assert hpd. >> >> Am I missing something that this wouldn't fix? > > The issue in this case is that the problematic connectors don't have > HPD pin wired up and the ddc lines seem to be wired improperly so a > ddc probe always reports something connected unless you actually look > at the EDID header. ?For DVI-I we probably have to poll since only the > digital portion will assert hpd in most cases. > > Alex >
[Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing
On Tue, 26 Jul 2011 09:24:39 +0200, Daniel Vetter wrote: > Two things I've noticed: > - Why not dev->mode_config.mutex? You're right, of course. I noticed that just after posting that version and updated it; the updated version is on my drm-intel-fixes branch already (having been reviewed by Jesse). > - And a nitpick: Why the dev_priv->dev indirection, when dev is > already lying around? All nicely cleaned up by using &mode_config->mutex instead :-) Thanks for looking it over! -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110726/1b607231/attachment-0001.pgp>
[PATCH 4/5] drm/i915: Delay 250ms before running the hotplug code
On Tue, 26 Jul 2011 09:44:32 +0200, Daniel Vetter wrote: > queue_delayed_work? Plays nicer with other workqueue-items. Yeah, I'll change this. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110726/8c274b70/attachment.pgp>
[Intel-gfx] [PATCH 2/5] drm/i915: Rename i915_dp_detect_common to intel_dp_get_dpcd
On Mon, 25 Jul 2011 23:36:31 -0700 Keith Packard wrote: > This describes the function better, allowing it to be used where the > DPCD value is relevant. > > Signed-off-by: Keith Packard > --- Ah I see you've addressed my previous comment already. :) You can add my Reviewed-by: Jesse Barnes to 1/5 and 2/5. -- Jesse Barnes, Intel Open Source Technology Center
[Intel-gfx] [PATCH 3/5] drm/i915: In intel_dp_init, replace read of DPCD with intel_dp_get_dpcd
On Mon, 25 Jul 2011 23:36:32 -0700
Keith Packard wrote:
> Eliminates an open-coded read and also gains the retry behaviour of
> intel_dp_get_dpcd, which seems like a good idea.
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/intel_dp.c |8 +++-
> 1 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 41674e1..9f134d2 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2015,7 +2015,7 @@ intel_dp_init(struct drm_device *dev, int output_reg)
>
> /* Cache some DPCD data in the eDP case */
> if (is_edp(intel_dp)) {
> - int ret;
> + bool ret;
> u32 pp_on, pp_div;
>
> pp_on = I915_READ(PCH_PP_ON_DELAYS);
> @@ -2028,11 +2028,9 @@ intel_dp_init(struct drm_device *dev, int output_reg)
> dev_priv->panel_t12 *= 100; /* t12 in 100ms units */
>
> ironlake_edp_panel_vdd_on(intel_dp);
> - ret = intel_dp_aux_native_read(intel_dp, DP_DPCD_REV,
> -intel_dp->dpcd,
> -sizeof(intel_dp->dpcd));
> + ret = intel_dp_get_dpcd(intel_dp);
> ironlake_edp_panel_vdd_off(intel_dp);
> - if (ret == sizeof(intel_dp->dpcd)) {
> + if (ret) {
> if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11)
> dev_priv->no_aux_handshake =
> intel_dp->dpcd[DP_MAX_DOWNSPREAD] &
Reviewed-by: Jesse Barnes
Now we just have to enable fast link training in the eDP case (and
optionally when we know the DP monitor hasn't changed, just DPMS'd).
--
Jesse Barnes, Intel Open Source Technology Center
[Intel-gfx] [PATCH 1/5] drm/i915: Use dp_detect_common in hotplug helper function
On Mon, 25 Jul 2011 23:36:30 -0700 Keith Packard wrote: > This uses the common dpcd reading routine, i915_dp_detect_common, > instead of open-coding a call to intel_dp_aux_native_read. Besides > reducing duplicated code, this also gains the read retries which > may be necessary when a cable is first plugged back in and the link > needs to be retrained. > > Signed-off-by: Keith Packard > --- > drivers/gpu/drm/i915/intel_dp.c | 39 > +++ > 1 files changed, 19 insertions(+), 20 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index dcc7ae6..45db810 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -1567,6 +1567,20 @@ intel_dp_link_down(struct intel_dp *intel_dp) > POSTING_READ(intel_dp->output_reg); > } > > +static enum drm_connector_status > +i915_dp_detect_common(struct intel_dp *intel_dp) Maybe you can fix the prefix of this function while you're at it since it's not i915 or even i9xx specific? -- Jesse Barnes, Intel Open Source Technology Center
[Intel-gfx] [PATCH 5/5] drm/i915: DP_PIPE_ENABLED must check transcoder on CPT
On Mon, 25 Jul 2011 23:36:34 -0700 Keith Packard wrote: > Display port pipe selection on CPT is not done with a bit in the > output register, rather it is controlled by a couple of bits in the > separate transcoder register which indicate which display port output > is connected to the transcoder. > > This patch replaces the simplistic macro DP_PIPE_ENABLED with the > rather more complicated function dp_pipe_enabled which checks the > output register to see if that is enabled, and then goes on to either > check the output register pipe selection bit (on non-CPT) or the > transcoder DP selection bits (on CPT). > > Before this patch, any time the mode of pipe A was changed, any > display port outputs on pipe B would get disabled as > intel_disable_pch_ports would ensure that the mode setting operation > could occur on pipe A without interference from other outputs > connected to that pch port > > Signed-off-by: Keith Packard > --- Ah nice catch. I expect one day we'll have all the chipset and PCH differences coded... Reviewed-by: Jesse Barnes -- Jesse Barnes, Intel Open Source Technology Center
[Intel-gfx] drm/i915: A selection of display port fixes
On Mon, 2011-07-25 at 23:36 -0700, Keith Packard wrote: > [PATCH 1/5] drm/i915: Use dp_detect_common in hotplug helper > [PATCH 2/5] drm/i915: Rename i915_dp_detect_common to > [PATCH 3/5] drm/i915: In intel_dp_init, replace read of DPCD with > > These three are simple cleanups to centralize all places where the > DPCD block was read from the device. Now everyone shares the same > function, and that function retries the reads. Reviewed-by: Adam Jackson > [PATCH 4/5] drm/i915: Delay 250ms before running the hotplug code > > I was experimenting with DP hotplugging -- moving the plug in and out > of the jack very slowly and discovered that the hotplug interrupt > occurred well before or after the link for the aux data channel was > connected or disconnected. The result of this was that a sufficiently > rapid cycle back through user mode could easily beat the motion of the > plug and cause the hotplug detection to get the wrong status. Sticking > a 250ms delay before doing anything gives the user sufficient time to > actually get the plug connected or disconnected. At the very least this should instead be queue_delayed_work(). But if we're going to delay, can we instead set up PCH_PORT_HOTPLUG to do a 100ms delay for us? I'll try this locally, at any rate. > [PATCH 5/5] drm/i915: DP_PIPE_ENABLED must check transcoder on CPT > > > > Turns out the bug wasn't that the mode setting code was doing it wrong > and turning the DP2 output off intentionally as a part of the mode > change. Instead, the intel driver was trying to adjust the PCH link > for the LVDS1 output and thought it needed to turn the DP2 output off > because it mistakenly believed the DP2 output was sharing the same > pipe as the LVDS1 output. Just a matter of using the wrong mechanism > to detect which pipe the DP2 output was connected to. Reviewed-by: Adam Jackson - ajax -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110726/2993b7d6/attachment.pgp>
[Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing
On Tue, 26 Jul 2011 08:23:13 -0700 Keith Packard wrote: > On Tue, 26 Jul 2011 09:24:39 +0200, Daniel Vetter wrote: > > Two things I've noticed: > > > - Why not dev->mode_config.mutex? > > You're right, of course. I noticed that just after posting that version > and updated it; the updated version is on my drm-intel-fixes branch > already (having been reviewed by Jesse). > > > - And a nitpick: Why the dev_priv->dev indirection, when dev is > > already lying around? > > All nicely cleaned up by using &mode_config->mutex instead :-) > > Thanks for looking it over! I'd like to amend my reviewed by and say the lock shouldn't be held around the call to the drm helper function. It queues some work that also takes the mode config lock, which will break. So you can drop it before that... Previously I had only checked our internal driver callbacks but missed that the lock was held across the helper too. -- Jesse Barnes, Intel Open Source Technology Center
[Bug 39572] New: Cogs: GPU hang
https://bugs.freedesktop.org/show_bug.cgi?id=39572 Summary: Cogs: GPU hang Product: Mesa Version: git Platform: Other URL: http://www.humblebundle.com/ OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: sa at whiz.se Created an attachment (id=49589) --> (https://bugs.freedesktop.org/attachment.cgi?id=49589) dmesg output The game Cogs (from the Humble Indie Bundle) is causing a GPU hang. Unless the process is killed quickly the reset functionality doesn't seem to work so a full reboot is necessary. The hang only happens if shadows is turned on in the game options, which it is by default so the hang happens right after launching the game. No difference between 7.11 and git master. Something else seems to be wrong with the game as it's pegging the CPU at 100% and performance is just a few frames per second. System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: REDWOOD -- Model: XFX Radeon HD 5670 1GB -- Display connector: DVI -- xf86-video-ati: 6.14.2 -- xserver: 1.10.2.902 -- mesa: 860c51d82711936d343b55aafb46befc8c032fe6 -- drm: 2.4.26 -- kernel: 3.0 -- 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/radeon/kms: disable CP interrupt when disabling interrupt
From: Jerome Glisse
Some CP interrupt were left enabled when disabling interrupt.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm/radeon/r600.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 14dce9f..852565d 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2434,7 +2434,7 @@ void evergreen_disable_interrupt_state(struct
radeon_device *rdev)
{
u32 tmp;
- WREG32(CP_INT_CNTL, CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE);
+ WREG32(CP_INT_CNTL, 0);
WREG32(GRBM_INT_CNTL, 0);
WREG32(INT_MASK + EVERGREEN_CRTC0_REGISTER_OFFSET, 0);
WREG32(INT_MASK + EVERGREEN_CRTC1_REGISTER_OFFSET, 0);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index aa5571b..d2c74e7 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2900,7 +2900,7 @@ static void r600_disable_interrupt_state(struct
radeon_device *rdev)
{
u32 tmp;
- WREG32(CP_INT_CNTL, CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE);
+ WREG32(CP_INT_CNTL, 0);
WREG32(GRBM_INT_CNTL, 0);
WREG32(DxMODE_INT_MASK, 0);
WREG32(D1GRPH_INTERRUPT_CONTROL, 0);
--
1.7.3.2
[PATCH] drm/radeon/kms: disable CP interrupt when disabling interrupt
On Tue, Jul 26, 2011 at 5:28 PM, wrote:
> From: Jerome Glisse
>
> Some CP interrupt were left enabled when disabling interrupt.
>
Is there a specific issue this fixes? The bits are not interrupt
sources per se but rather are related to the internal state of the
interrupt controller and should always be enabled.
Alex
> Signed-off-by: Jerome Glisse
> ---
> ?drivers/gpu/drm/radeon/evergreen.c | ? ?2 +-
> ?drivers/gpu/drm/radeon/r600.c ? ? ?| ? ?2 +-
> ?2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index 14dce9f..852565d 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -2434,7 +2434,7 @@ void evergreen_disable_interrupt_state(struct
> radeon_device *rdev)
> ?{
> ? ? ? ?u32 tmp;
>
> - ? ? ? WREG32(CP_INT_CNTL, CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE);
> + ? ? ? WREG32(CP_INT_CNTL, 0);
> ? ? ? ?WREG32(GRBM_INT_CNTL, 0);
> ? ? ? ?WREG32(INT_MASK + EVERGREEN_CRTC0_REGISTER_OFFSET, 0);
> ? ? ? ?WREG32(INT_MASK + EVERGREEN_CRTC1_REGISTER_OFFSET, 0);
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index aa5571b..d2c74e7 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -2900,7 +2900,7 @@ static void r600_disable_interrupt_state(struct
> radeon_device *rdev)
> ?{
> ? ? ? ?u32 tmp;
>
> - ? ? ? WREG32(CP_INT_CNTL, CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE);
> + ? ? ? WREG32(CP_INT_CNTL, 0);
> ? ? ? ?WREG32(GRBM_INT_CNTL, 0);
> ? ? ? ?WREG32(DxMODE_INT_MASK, 0);
> ? ? ? ?WREG32(D1GRPH_INTERRUPT_CONTROL, 0);
> --
> 1.7.3.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[PATCH] drm/radeon/kms: disable CP interrupt when disabling interrupt
On Tue, Jul 26, 2011 at 5:47 PM, Alex Deucher wrote: > On Tue, Jul 26, 2011 at 5:28 PM, ? wrote: >> From: Jerome Glisse >> >> Some CP interrupt were left enabled when disabling interrupt. >> > > Is there a specific issue this fixes? ?The bits are not interrupt > sources per se but rather are related to the internal state of the > interrupt controller and should always be enabled. > > Alex > Might, might not i have seen flgrx unsetting this bit on my rv670 which reboot with the radeon driver. Jerome
[Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?
On Sat, Jul 23, 2011 at 12:23:36AM +0400, Kirill Smelkov wrote:
> Keith,
>
> first of all thanks for your prompt reply. Then...
>
> On Fri, Jul 22, 2011 at 11:00:41AM -0700, Keith Packard wrote:
> > On Fri, 22 Jul 2011 15:08:06 +0400, Kirill Smelkov
> > wrote:
> >
> > > And now after v3.0 is out, I've tested it again, and yes, like it was
> > > broken on v3.0-rc5, it is (now even more) broken on v3.0 -- after first
> > > bad io access the system freezes completely:
> >
> > I looked at this when I first saw it (a couple of weeks ago), and I
> > couldn't see any obvious reason this patch would cause this particular
> > problem. I didn't want to revert the patch at that point as I feared it
> > would cause other subtle problems. Given that you've got a work-around,
> > it seemed best to just push this off past 3.0.
>
> What kind of a workaround are you talking about? Sorry, to me it all
> looked like "UMS is being ignored forever". Anyway, let's move on to try
> to solve the issue.
>
>
> > Given the failing address passed to ioread32, this seems like it's
> > probably the call to READ_BREADCRUMB -- I915_BREADCRUMB_INDEX is 0x21,
> > which is an offset in 32-bit units within the hardware status page. If
> > the status_page.page_addr value was zero, then the computed address
> > would end up being 0x84.
> >
> > And, it looks like status_page.page_addr *will* end up being zero as a
> > result of the patch in question. The patch resets the entire ring
> > structure contents back to the initial values, which includes smashing
> > the status_page structure to zero, clearing the value of
> > status_page.page_addr set in i915_init_phys_hws.
> >
> > Here's an untested patch which moves the initialization of
> > status_page.page_addr into intel_render_ring_init_dri. I note that
> > intel_init_render_ring_buffer *already* has the setting of the
> > status_page.page_addr value, and so I've removed the setting of
> > status_page.page_addr from i915_init_phys_hws.
> >
> > I suspect we could remove the memset from intel_init_render_ring_buffer;
> > it seems entirely superfluous given the memset in i915_init_phys_hws.
> >
> > From 159ba1dd207fc52590ce8a3afd83f40bd2cedf46 Mon Sep 17 00:00:00 2001
> > From: Keith Packard
> > Date: Fri, 22 Jul 2011 10:44:39 -0700
> > Subject: [PATCH] drm/i915: Initialize RCS ring status page address in
> > intel_render_ring_init_dri
> >
> > Physically-addressed hardware status pages are initialized early in
> > the driver load process by i915_init_phys_hws. For UMS environments,
> > the ring structure is not initialized until the X server starts. At
> > that point, the entire ring structure is re-initialized with all new
> > values. Any values set in the ring structure (including
> > ring->status_page.page_addr) will be lost when the ring is
> > re-initialized.
> >
> > This patch moves the initialization of the status_page.page_addr value
> > to intel_render_ring_init_dri.
> >
> > Signed-off-by: Keith Packard
> > ---
> > drivers/gpu/drm/i915/i915_dma.c |6 ++
> > drivers/gpu/drm/i915/intel_ringbuffer.c |3 +++
> > 2 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 1271282..8a3942c 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -61,7 +61,6 @@ static void i915_write_hws_pga(struct drm_device *dev)
> > static int i915_init_phys_hws(struct drm_device *dev)
> > {
> > drm_i915_private_t *dev_priv = dev->dev_private;
> > - struct intel_ring_buffer *ring = LP_RING(dev_priv);
> >
> > /* Program Hardware Status Page */
> > dev_priv->status_page_dmah =
> > @@ -71,10 +70,9 @@ static int i915_init_phys_hws(struct drm_device *dev)
> > DRM_ERROR("Can not allocate hardware status page\n");
> > return -ENOMEM;
> > }
> > - ring->status_page.page_addr =
> > - (void __force __iomem *)dev_priv->status_page_dmah->vaddr;
> >
> > - memset_io(ring->status_page.page_addr, 0, PAGE_SIZE);
> > + memset_io((void __force __iomem *)dev_priv->status_page_dmah->vaddr,
> > + 0, PAGE_SIZE);
> >
> > i915_write_hws_pga(dev);
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index e961568..47b9b27 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -1321,6 +1321,9 @@ int intel_render_ring_init_dri(struct drm_device
> > *dev, u64 start, u32 size)
> > ring->get_seqno = pc_render_get_seqno;
> > }
> >
> > + if (!I915_NEED_GFX_HWS(dev))
> > + ring->status_page.page_addr = dev_priv->status_page_dmah->vaddr;
> > +
> > ring->dev = dev;
> > INIT_LIST_HEAD(&ring->active_list);
> > INIT_LIST_HEAD(&ring->request_list);
>
> I can't tell whether this is correct, because intel gfx driver is
> unknown to me, but
[PATCH] i915: add Dell OptiPlex FX170 to intel_no_lvds
The Dell OptiPlex FX170 claims to have LVDS, but doesn't.
Signed-off-by: Pieterjan Camerlynck
---
drivers/gpu/drm/i915/intel_lvds.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index b28f7bd..2e8ddfc 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -690,6 +690,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
},
{
.callback = intel_no_lvds_dmi_callback,
+ .ident = "Dell OptiPlex FX170",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex FX170"),
+ },
+ },
+ {
+ .callback = intel_no_lvds_dmi_callback,
.ident = "AOpen Mini PC",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "AOpen"),
--
1.7.3.4
