[RFC] Virtual CRTCs (proposal + experimental code)

[Ilija Hadzic]

On Wed, 23 Nov 2011, Dave Airlie wrote:

> So another question I have is how you would intend this to work from a
> user POV, like how it would integrate with a desktop environment, X or
> wayland, i.e. with little or no configuration.
>

First thing to understand is that when a virtual CRTC is created, it looks 
to the user like the GPU has an additional DisplayPort connector.
At present I "abuse" DisplayPort, but I have seen that you pushed a patch 
from VMware that adds Virtual connector, so eventually I'll switch to that 
naming. The number of virtual CRTCs is determined when the driver loads 
and that is a static configuration parameter. This does not restrict the 
user because unused virutal CRTCs are just like disconnected connectors on 
the GPU. In extreme case, a user could max out the number of virtual CRTCs 
(i.e. 32 minus #-of-physical-CRTCs), but in general the system needs to be 
booted with maximum number of anticipated CRTCs. Run-time addition and 
removal of CRTCs is not supported at this time and that would be much 
harder to implement and would affect the whole DRM module everywhere.

So now we have a system that booted up and DRM sees all of its real 
connectors as well as virtual ones (as DisplayPorts at present). If there 
is no CTD device attached to virtual CRTCs, these virtual connectors are 
disconnected as far as DRM is concerned. Now the userspace must call 
"attach/fps" ioctl to associate CTDs with CRTCs. I'll explain shortly how 
to automate that and how to eliminate the burden from the user, but for 
now, please assume that "attach/fps" gets called from userland somehow.

When the attach happens, that is a hotplug event (VCRTCM generates it) to 
DRM, just like someone plugged in the monitor. Then when XOrg starts, it
will use the DisplayPort that represents a virtual CRTC just like any 
other connector. How it will use it, will depend on what the xorg.conf 
says, but the key point is that this connector is no different from any 
other connector that the GPU provides and is thus used as an "equal 
citizen". No special configuration is necessary once attached to CTD.

If CTD is detached and new CTD attached, that is just like yanking out 
monitor cable and plugging in the new one. DRM will get all hotplug events 
and windowing system will do the same thing it would normally do with any 
other port. If RANDR is called to resize the desktop it will also work and 
X will have no idea that one of the connectors is on a virtual CRTC. I 
also have another feature, where when CTD is attached, it can ask the 
device it drives for the connection status and propagate that all the way 
back to DRM (this is useful for CTD devices that drive real monitors, like 
DisplayLink).

So now let's go back to the attach/fps ioctl. To attach a CTD device this 
ioctl must happen as a result of some policy. That can be done by having 
CTD device generate UDEV events when it loads for which one can write 
policies to determine which CTD device attaches to which virtual CRTC.
Ultimately that becomes an user configuration, but it's no different from 
what one has to do now with UDEV policies to customize the system.

Having explained this, let's take your hotplug example that you put up on 
your web page and redo it with virtual CRTCs. Here is how it would work: 
Boot up the system and tell the GPU to create a few virtual CRTCs. Bring 
up Xorg with no DisplayLink dongles in it. Now plug in the DisplayLink. 
Once the CTD driver loads as the result of the hotplug (right now UDLCTD 
is a separate driver, but as we discussed before, this is a temporary 
state and at some point its CTD function should be merged wither with 
UDLFB or with your UDL-V2) CTD function in the driver generates an UDEV 
event. The policy directs UDEV to call run the program that issues the 
ioctl to perform attach/fps. Attach/fps of the UDLCTD is now a hotplug 
event and DRM "thinks" that a new connector changed the status from 
disconnected to connected. That causes it to query the modes for the new 
connector and because it's the virtual CRTC, it lands in the virtual CRTC 
helpers in the GPU driver. Virtual CRTC helpers route it to VCRTCM, which 
further routes to it to CTD (UDLCTD in this case). CTD returns the modes 
and DRM gets them ... the rest you know better than me what happens ;-)

So this is your hotplug demo, but the difference is that the new desktop 
can use direct rendering. Also, everything that would work for a normal 
connector works here without having to do any additional tricks. RANDR 
also works seamlessly without having to do anything special. If you move 
away from Xorg, to some other system (Wayland?), it still works for as 
long as the new system knows how to deal with connectors that connect and 
disconnect.

Everything I described above is ready to go except the UDEV event from 
UDLCTD and UDEV rules to automate this. Both are straightforwar and won't 
take long to do. So very shortly, I'll be able to 

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Daniel Vetter]

On Wed, Nov 23, 2011 at 03:43:05PM +, David Woodhouse wrote:
> On Wed, 2011-11-23 at 16:41 +0100, Daniel Vetter wrote:
> > Hm, that comment confuses me a bit. I've always thought that igfx_off only
> > instantiates a identity mapping and leaves the dmar unit on. Is that
> > wrong? 
> 
> It's completely off. If a DMAR unit has *only* graphics devices behind
> it (as the one for the built-in graphics does, because it's a whole
> boatload of speshul case for integration with the GTT), we just don't
> enable it at all. See the second for_each_drhd_unit() loop in
> init_no_remapping_devices().

That explanation confused me even more. So I've rechecked with
intel_iommu=igfx_off and already thought I've made a decent fool of
myself because I couldn't readily hang it. Turns out it's just much harder
to hang with that. So I think moving around the tlb flushing for other
dmar nodes to align with the idled igfx isn't a great solution, simply
because I can't reliably tell whether it fixes anything.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 00/14] update exynos drm driver.

[InKi Dae]

2011/11/23 Dave Airlie :
> On Wed, Nov 23, 2011 at 2:23 AM, InKi Dae  wrote:
>> Hello, Dave.
>>
>> I had posted DRM Driver patchsets for Exsynos SoC but there is no any
>> feedback. could you please review them? and if the patchsets have any
>> problem, please give me your advice anytime. and also we are ready for
>> next patchsets.
>>
>> the next patchsets include the followings:
>> - fix some previous patchset bugs.
>> - add power managerment featrue based on runtim-pm.
>>
>> from next patchset, I would request GIT PULL if you are ok.
>
> I'm mainly trying to decide if they should go to Linus now or just go
> into -next,
>
> do you guys have a major preference one way or the other? later on
> when the driver is more feature complete,
> it would be good to send the fixes for the current tree separate to
> new features.
>
> Dave.
>

Hello, Dave.

the patchsets I sent before include only bug fixes so I think they
have no any new feature. and also now we are working another patchsets
for drm-next. they would include new features such as hdmi, iommu,
plane features. so I think it would be good to send the patchsets for
bug fix to drm-fixes. If you are ok, we'd like to start patch work as
two versions. one is based on drm-fixes for bug fix and another is
based on drm-next for new features. but we are ok whatever you decide.
so please give me your answer so that we can start next patch work.

thank you,
Inki Dae.

[Intel-gfx] [PATCH] iommu: export no_iommu and dmar_disabled symbols

[David Woodhouse]

On Wed, 2011-11-23 at 16:42 -0200, Eugeni Dodonov wrote:
> Those are needed by the rc6 and semaphores support in i915 driver.
> 
> In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
> is enabled. So we use those variables to check the io remapping and iommu
> status.

This is horrid. In the general case, drivers have no business knowing
this. We need to properly identify what is wrong with this hardware, and
put in a quirk for it ? perhaps refusing to enable the IOMMU at all on
the broken chipsets.

-- 
dwmw2
-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2023/2a1941ae/attachment.bin>

WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

[Markus Trippelsdorf]

On 2011.11.21 at 16:36 +0100, Markus Trippelsdorf wrote:
> On 2011.11.21 at 15:16 +0100, Eric Dumazet wrote:
> > Le lundi 21 novembre 2011 ? 14:15 +0100, Markus Trippelsdorf a ?crit :
> > 
> > > I've enabled CONFIG_SLUB_DEBUG_ON and this is what happend:
> > > 
> > 
> > Thanks
> > 
> > Please continue to provide more samples.
> > 
> > There is something wrong somewhere, but where exactly, its hard to say.
> 
> New sample. This one points to lib/idr.c:
> 
> [drm] Initialized drm 1.1.0 20060810
> [drm] radeon defaulting to kernel modesetting.
> [drm] radeon kernel modesetting enabled.
> radeon :01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> radeon :01:05.0: setting latency timer to 64
> [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
> [drm] register mmio base: 0xFBEE
> [drm] register mmio size: 65536
> ATOM BIOS: 113
> radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
> used)
> radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
> [drm] Detected VRAM RAM=128M, BAR=128M
> [drm] RAM width 32bits DDR
> [TTM] Zone  kernel: Available graphics memory: 4083428 kiB.
> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB.
> [TTM] Initializing pool allocator.
> [drm] radeon: 128M of VRAM memory ready
> [drm] radeon: 512M of GTT memory ready.
> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [drm] Driver supports precise vblank timestamp query.
> [drm] radeon: irq initialized.
> [drm] GART: num cpu pages 131072, num gpu pages 131072
> [drm] Loading RS780 Microcode
> [drm] PCIE GART of 512M enabled (table at 0xC004).
> radeon :01:05.0: WB enabled
> [drm] ring test succeeded in 1 usecs
> [drm] radeon: ib pool ready.
> [drm] ib test succeeded in 0 usecs
> =
> BUG idr_layer_cache: Poison overwritten
> -
> 
> INFO: 0x880215650800-0x880215650803. First byte 0x0 instead of 0x6b
> INFO: Slab 0xea0008559400 objects=18 used=18 fp=0x  (null) 
> flags=0x40004080
> INFO: Object 0x8802156506d0 @offset=1744 fp=0x880215650a38
> 
> Bytes b4 8802156506c0: a4 6f fb ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a  
> .o..
> Object 8802156506d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 8802156506e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 8802156506f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650700: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650710: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650720: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650730: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650740: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650750: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650760: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650770: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650780: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650790: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 8802156507a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 8802156507b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 8802156507c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 8802156507d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 8802156507e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 8802156507f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650820: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650830: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650840: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650850: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650860: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650870: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215650880: 6b 6b 6b 6b 6b 6b 6b 6b 6b 

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Daniel Vetter]

On Wed, Nov 23, 2011 at 04:31:54PM +0100, Daniel Vetter wrote:
> - Wait 2 minutes for the stuck-in-atomic detection logic to kick in and
>   grab the backtrace over netconsole. Notice that the kernel is stuck
>   trying to flush the dmar tlb cache (that's how I managed to track it
>   down to a dmar interaction). Backtrace almost identical to the dmar
>   issue on ilk. I've lost the backtrace, if you want I can regrab it.

Ok, I've recaptured the last words from my dying machine:

Listening for netconsole messages
[  136.897673] [ cut here ]
[  136.897694] WARNING: at kernel/watchdog.c:241 
watchdog_overflow_callback+0x9b/0xa6()
[  136.897701] Hardware name: HP EliteBook 8460p
[  136.897707] Watchdog detected hard LOCKUP on cpu 0
[  136.897713] Modules linked in: sunrpc 8021q garp stp llc cpufreq_ondemand 
acpi_cpufreq freq_table mperf snd_hda_codec_hdmi snd_hda_codec_idt arc4 iwlwifi 
mac80211 hp_wmi sparse_keymap ppdev uvcvideo videodev v4l2_compat_ioctl32 btusb 
microcode snd_hda_intel snd_hda_codec snd_hwdep snd_seq bluetooth 
snd_seq_device iTCO_wdt snd_pcm snd_timer snd cfg80211 serio_raw 
iTCO_vendor_support joydev xhci_hcd rfkill e1000e soundcore snd_page_alloc 
parport_pc parport tpm_infineon wmi intel_ips ipv6 firewire_ohci firewire_core 
crc_itu_t sdhci_pci sdhci mmc_core i915 drm_kms_helper drm i2c_algo_bit 
i2c_core video [last unloaded: scsi_wait_scan]
[  136.897967] Pid: 0, comm: swapper Not tainted 3.2.0-rc2+ #162
[  136.897972] Call Trace:
[  136.897978][] warn_slowpath_common+0x83/0x9b
[  136.897998]  [] warn_slowpath_fmt+0x46/0x48
[  136.898007]  [] ? native_sched_clock+0x34/0x36
[  136.898016]  [] watchdog_overflow_callback+0x9b/0xa6
[  136.898026]  [] __perf_event_overflow+0x100/0x17f
[  136.898035]  [] ? perf_event_update_userpage+0xf/0xa2
[  136.898045]  [] ? x86_perf_event_set_period+0x107/0x113
[  136.898053]  [] perf_event_overflow+0x14/0x16
[  136.898062]  [] intel_pmu_handle_irq+0x211/0x271
[  136.898073]  [] perf_event_nmi_handler+0x19/0x1b
[  136.898082]  [] nmi_handle+0x42/0x67
[  136.898091]  [] do_nmi+0x8c/0x26b
[  136.898099]  [] nmi+0x20/0x30
[  136.898109]  [] ? do_raw_spin_lock+0x1/0x25
[  136.898115]  <>[] ? _raw_spin_lock+0xe/0x10
[  136.898135]  [] qi_submit_sync+0x30d/0x312
[  136.898143]  [] qi_flush_iotlb+0x7a/0x7c
[  136.898152]  [] flush_unmaps+0x72/0x131
[  136.898161]  [] flush_unmaps_timeout+0x1f/0x32
[  136.898169]  [] run_timer_softirq+0x19b/0x280
[  136.898177]  [] ? paravirt_read_tsc+0x9/0xd
[  136.898186]  [] ? flush_unmaps+0x131/0x131
[  136.898195]  [] __do_softirq+0xc9/0x1b5
[  136.898203]  [] ? paravirt_read_tsc+0x9/0xd
[  136.898212]  [] call_softirq+0x1c/0x30
[  136.898222]  [] do_softirq+0x46/0x81
[  136.898230]  [] irq_exit+0x57/0xb1
[  136.898238]  [] smp_apic_timer_interrupt+0x7c/0x8a
[  136.898251]  [] apic_timer_interrupt+0x6e/0x80
[  136.898256][] ? paravirt_read_tsc+0x9/0xd
[  136.898271]  [] ? intel_idle+0xef/0x120
[  136.898279]  [] ? intel_idle+0xd1/0x120
[  136.898289]  [] cpuidle_idle_call+0xe2/0x181
[  136.898297]  [] cpu_idle+0xa9/0xf0
[  136.898306]  [] rest_init+0x72/0x74
[  136.898316]  [] start_kernel+0x3b0/0x3bd
[  136.898324]  [] x86_64_start_reservations+0xaf/0xb3
[  136.898332]  [] ? early_idt_handlers+0x140/0x140
[  136.898340]  [] x86_64_start_kernel+0x102/0x111
[  136.898348] ---[ end trace 2d22d2d9c3bfe5c8 ]---
[  161.821354] [ cut here ]
[  161.821365] WARNING: at kernel/watchdog.c:241 
watchdog_overflow_callback+0x9b/0xa6()
[  161.821370] Hardware name: HP EliteBook 8460p
[  161.821376] Watchdog detected hard LOCKUP on cpu 1
[  161.821381] Modules linked in: sunrpc 8021q garp stp llc cpufreq_ondemand 
acpi_cpufreq freq_table mperf snd_hda_codec_hdmi snd_hda_codec_idt arc4 iwlwifi 
mac80211 hp_wmi sparse_keymap ppdev uvcvideo videodev v4l2_compat_ioctl32 btusb 
microcode snd_hda_intel snd_hda_codec snd_hwdep snd_seq bluetooth 
snd_seq_device iTCO_wdt snd_pcm snd_timer snd cfg80211 serio_raw 
iTCO_vendor_support joydev xhci_hcd rfkill e1000e soundcore snd_page_alloc 
parport_pc parport tpm_infineon wmi intel_ips ipv6 firewire_ohci firewire_core 
crc_itu_t sdhci_pci sdhci mmc_core i915 drm_kms_helper drm i2c_algo_bit 
i2c_core video [last unloaded: scsi_wait_scan]
[  161.821609] Pid: 1134, comm: X Tainted: GW3.2.0-rc2+ #162
[  161.821615] Call Trace:
[  161.821619][] warn_slowpath_common+0x83/0x9b
[  161.821633]  [] warn_slowpath_fmt+0x46/0x48
[  161.821640]  [] ? native_sched_clock+0x34/0x36
[  161.821648]  [] watchdog_overflow_callback+0x9b/0xa6
[  161.821655]  [] __perf_event_overflow+0x100/0x17f
[  161.821663]  [] ? perf_event_update_userpage+0xf/0xa2
[  161.821669]  [] ? x86_perf_event_set_period+0x107/0x113
[  161.821677]  [] perf_event_overflow+0x14/0x16
[  161.821684]  [] intel_pmu_handle_irq+0x211/0x271
[  161.821692]  [] perf_event_nmi_handler+0x19/0x1b
[  161.821700]  [] nmi_handle+0x42/0x67
[  161.821708]  [] do_nmi+0x8c/0x26b
[  

[PATCH] iommu: export no_iommu and dmar_disabled symbols

[Eugeni Dodonov]

Those are needed by the rc6 and semaphores support in i915 driver.

In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
is enabled. So we use those variables to check the io remapping and iommu
status.

CC: Keith Packard 
CC: Daniel Vetter 
Signed-off-by: Eugeni Dodonov 
---
 arch/x86/kernel/pci-dma.c   |1 +
 drivers/iommu/intel-iommu.c |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index 80dc793..4c9191e 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -33,6 +33,7 @@ int force_iommu __read_mostly = 0;
 int iommu_merge __read_mostly = 0;

 int no_iommu __read_mostly;
+EXPORT_SYMBOL_GPL(no_iommu);
 /* Set this to 1 if there is a HW IOMMU in the system */
 int iommu_detected __read_mostly = 0;

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index c0c7820..dfe5fd3 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -404,6 +404,7 @@ int dmar_disabled = 0;
 #else
 int dmar_disabled = 1;
 #endif /*CONFIG_INTEL_IOMMU_DEFAULT_ON*/
+EXPORT_SYMBOL_GPL(dmar_disabled);

 static int dmar_map_gfx = 1;
 static int dmar_forcedac;
-- 
1.7.7.4

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Daniel Vetter]

On Wed, Nov 23, 2011 at 03:03:43PM +, David Woodhouse wrote:
> On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
> > At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
> > dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
> > for the dmar+rc6 hangs reported. 
> 
> Um... let me restate that for clarity (and partly for Rajesh's benefit).
> 
> The DMAR associated with the integrated graphics is *disabled*.
> Turned off. Not active. Ever.

Hm, that comment confuses me a bit. I've always thought that igfx_off only
instantiates a identity mapping and leaves the dmar unit on. Is that
wrong?
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Daniel Vetter]

On Wed, Nov 23, 2011 at 03:03:43PM +, David Woodhouse wrote:
> On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
> > At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
> > dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
> > for the dmar+rc6 hangs reported. 
> 
> Um... let me restate that for clarity (and partly for Rajesh's benefit).
> 
> The DMAR associated with the integrated graphics is *disabled*.
> Turned off. Not active. Ever.
> 
> You have a problem when you enable the *other* DMAR units in the system,
> which should not be affecting the graphics device in any way.
> 
> When you do this, you see 'hangs' with semaphores and RC6. Is there a
> better description of these 'hangs' somewhere? Is the hardware
> completely locked?
> 
> These hangs go away when you disable the DMAR units. Again, that is the
> *other* DMAR units in the system that have nothing to do with graphics.
> 
> While I'm getting quite used to DMAR-related errata, this one does make
> me stop and think 'wtf?'. It just seems so incongruous that disabling an
> *unrelated* IOMMU would make the problem go away, and it makes me wonder
> if it's actually a timing-related issue which is always there, but
> something about the use of DMAR for network/disk/etc. makes it more
> likely to trigger?
> 
> We definitely need the hardware folks to get to the bottom of this one.

Ok, let me document the recipe I use to hang my box here. It's about the
dmar+semaphores hang I can reproduce, so might be slightly different in
the actual cause than the dmar+rc6 bug (for that one we only have bug
reports talking about hard freezing requiring power cycling).

- Grab a GT2+ mobile snb (both my and the only other reporters machine
  fits this, so maybe it matters). pci rev 09 (i.e. first production
  silicon).
- Install fc15 with the kde4 spin. I can't reproduce it with any other
  userspace than kde4.
- Grab latest d-i-f from Keith and latest userspace graphics code (to
  avoid hitting any other snb hangs we've tracked down meanwhile).
- Compile kernel with dmar and enable VT-d in the bios.
- Login into the systems with gdm, the machine usually dies within a few
  seconds (while kde4 loads). If that's not good enough, a few minutes of
  light desktop usage will kill it.
- Wait 2 minutes for the stuck-in-atomic detection logic to kick in and
  grab the backtrace over netconsole. Notice that the kernel is stuck
  trying to flush the dmar tlb cache (that's how I managed to track it
  down to a dmar interaction). Backtrace almost identical to the dmar
  issue on ilk. I've lost the backtrace, if you want I can regrab it.

Things I've tried that don't work around the issue:
- Disable dmar for the igfx with intel_iommu=igfx_off
- Apply the ilk workaround (i.e. synchronous dmar tlb flushes + gpu idling
  while flushing).

Things that work:
- Disabling semaphores.
- Disabling dmar in either the bios or on the cmdline with intel_iommu=off

All reporters that tried confirmed that igfx_off is not good enough, only
fully disabling dmar (for both the semaphores and the rc6 related hangs).

Things that look interesting:
- ppgtt support (i.e. using per-proces pagetables on the gfx instead of
  the global gtt) seems to paper over the issue for the original reporter
  of the semaphore related hangs.  Unfortunately not for me, gpu still
  hangs (but doesn't take down the entire system with it). I've not yet
  investigated this one closely. Fyi, the windows driver uses ppgtt
  unconditionally on snb. Also, ppgtt seems to have no effect for at least
  one report of dmar related rc6 hangs.

Cheers, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Wu Fengguang]

On Wed, Nov 23, 2011 at 02:25:14AM +0800, Keith Packard wrote:
> On Tue, 22 Nov 2011 15:40:55 +0800, Wu Fengguang  
> wrote:
> 
> > So the v3 patch will behave equally well on KMS console, gnome desktop
> > and bare X. Shall we just use it, or go back and use the original
> > ->hot_remove patch?
> 
> I'm not sure why we need any change to the core DRM code. The HDMI and
> DP drivers will be told when to turn the monitors on and off, and that's

Yeah, The DP driver will be notified via the intel_dp_hot_plug() hook
if I understand it right.

> the appropriate time to control whether audio is routed to them.

However ->hot_plug() is called too early to be useful for this case.

What I need is a hot plug hook that knows whether the monitor is
plugged or removed, which is only possible if the hook is called
after ->detect().

Or, we can avoid adding the ->hotplug() hook and just add the call
directly to intel_hdmi_detect() and intel_dp_detect().

The below patch does this and eliminates the DRM callback :-)

> Hotplug is considered simply a notification to user space that
> something has changed -- user space is in charge of configuring
> which outputs are in use.

Yeah, and here is another notification to the audio driver demanded by
the HD audio spec.

Thanks,
Fengguang
---
Subject: drm/i915: hot plug/remove notification to HDMI audio driver
Date: Fri Nov 11 13:49:04 CST 2011

On monitor hot plug/unplug, set/clear SDVO_AUDIO_ENABLE or
DP_AUDIO_OUTPUT_ENABLE accordingly, so that the audio driver will
receive hot plug events and take action to refresh its device state and
ELD contents.

After intel_dp_detect() knows whether the monitor is plugged or
removed, it will call intel_dp_hotplug_audio() to notify the audio
driver of the event.

It's noticed that bare metal X may not call ->mode_set() at monitor hot
plug, so it's necessary to call drm_edid_to_eld() earlier at ->detect()
time rather than in intel_ddc_get_modes(), so that intel_write_eld() can
see the new ELD in intel_dp_hotplug_audio().

The call sequence on hot plug is

- KMS console, full blown X (eg. gnome desktop)
->detect
  drm_edid_to_eld
->mode_set
  intel_write_eld
  set SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE
- bare metal X (eg. fluxbox)
->detect
  drm_edid_to_eld
  intel_dp_hotplug_audio()
intel_write_eld
set SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE

On hot remove, the call sequence is

->detect
  intel_dp_hotplug_audio()
clear SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE

cc: Wang Zhenyu 
Signed-off-by: Wu Fengguang 
---
 drivers/gpu/drm/i915/intel_dp.c|   47 ---
 drivers/gpu/drm/i915/intel_hdmi.c  |   32 ++
 drivers/gpu/drm/i915/intel_modes.c |2 -
 3 files changed, 68 insertions(+), 13 deletions(-)

--- linux.orig/drivers/gpu/drm/i915/intel_dp.c  2011-11-23 15:16:10.0 
+0800
+++ linux/drivers/gpu/drm/i915/intel_dp.c   2011-11-23 16:20:25.0 
+0800
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "drmP.h"
 #include "drm.h"
 #include "drm_crtc.h"
@@ -1940,6 +1941,27 @@ intel_dp_get_edid_modes(struct drm_conne
return ret;
 }

+static void intel_dp_hotplug_audio(struct drm_connector *connector,
+  enum drm_connector_status status)
+{
+   struct intel_dp *intel_dp = intel_attached_dp(connector);
+   struct drm_device *dev = intel_dp->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_crtc *crtc = intel_dp->base.base.crtc;
+
+   DRM_DEBUG_DRIVER("hotplug status %d crtc %p eld %#x\n",
+status, crtc, (unsigned int)connector->eld[0]);
+
+   if (status == connector_status_disconnected)
+   intel_dp->DP &= ~DP_AUDIO_OUTPUT_ENABLE;
+   else if (status == connector_status_connected && crtc) {
+   intel_write_eld(_dp->base.base, >mode);
+   intel_dp->DP |= DP_AUDIO_OUTPUT_ENABLE;
+   } else
+   return;
+   I915_WRITE(intel_dp->output_reg, intel_dp->DP);
+   POSTING_READ(intel_dp->output_reg);
+}

 /**
  * Uses CRT_HOTPLUG_EN and CRT_HOTPLUG_STAT to detect DP connection.
@@ -1968,20 +1990,23 @@ intel_dp_detect(struct drm_connector *co
  intel_dp->dpcd[6], intel_dp->dpcd[7]);

if (status != connector_status_connected)
-   return status;
+   goto out;

-   if (intel_dp->force_audio) {
-   intel_dp->has_audio = intel_dp->force_audio > 0;
-   } else {
-   edid = intel_dp_get_edid(connector, _dp->adapter);
-   if (edid) {
-   intel_dp->has_audio = drm_detect_monitor_audio(edid);
-   connector->display_info.raw_edid = NULL;
-   kfree(edid);
-   }
+   edid = intel_dp_get_edid(connector, _dp->adapter);
+   

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[David Woodhouse]

On Wed, 2011-11-23 at 16:41 +0100, Daniel Vetter wrote:
> Hm, that comment confuses me a bit. I've always thought that igfx_off only
> instantiates a identity mapping and leaves the dmar unit on. Is that
> wrong? 

It's completely off. If a DMAR unit has *only* graphics devices behind
it (as the one for the built-in graphics does, because it's a whole
boatload of speshul case for integration with the GTT), we just don't
enable it at all. See the second for_each_drhd_unit() loop in
init_no_remapping_devices().

-- 
dwmw2
-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2023/f271bad1/attachment-0001.bin>

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Daniel Vetter]

On Wed, Nov 23, 2011 at 02:01:54PM +, David Woodhouse wrote:
> On Wed, 2011-11-23 at 11:26 +0100, Daniel Vetter wrote:
> > On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
> > > On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett  
> > > wrote:
> > > 
> > > > So the user has to choose between 5W of power saving or having dmar? 
> > > > And 
> > > > we default to giving them dmar? I think that's going to come as a 
> > > > surprise to people.
> > > 
> > > You'd have to go into the BIOS to turn this on for most machines at
> > > least?
> > > 
> > > But, yeah, it seems like we should be turning DMAR off unless explicitly
> > > requested; I can't understand how you'd ever need this running native on
> > > the hardware. Not exactly an area I care about deeply; I've always
> > > worked hard to make sure all virtualization garbage is disabled on every
> > > machine I use.
> > 
> > Problem is that we need to disable dmar on the entire box, afaics. And I
> > assume that a bunch of people abusing desktop boards as servers will call
> > "regression" on that.
> 
> Hm, do you really have to disable it for the entire box, or just the
> graphics?

At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
for the dmar+rc6 hangs reported.

> Do we have a coherent erratum from Intel for the issues mentioned above
> with DMAR+gfx+RC6?

Afaik no errata applies to our dmar related troubles on snb. I've hoped
that ppgtt would magically fix this, and it seems to help quite a bit for
the semaphore hangs (but not everywhere). Couldn't yet look more into
this.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[David Woodhouse]

On Wed, 2011-11-23 at 16:31 +0100, Daniel Vetter wrote:
> 
> Things I've tried that don't work around the issue:
> - Disable dmar for the igfx with intel_iommu=igfx_off
> - Apply the ilk workaround (i.e. synchronous dmar tlb flushes + gpu
> idling while flushing).

Well, the ILK workaround was only ensuring that the gfx was idle while
the *graphics* IOTLB was flushed. We are still flushing the IOTLB for
*other* IOMMUs at arbitrary times. 

Might be interesting to go for *deferred* IOTLB flushes (i.e. the normal
mode without the workaround or 'intel_iommu=strict' on the command
line), *BUT* to make sure the batched flush (the flush_unmaps() call)
can *only* happen when the GPU is quiescent. You could do that with a
dirty hack for testing, and if *that* fixes the issue well, $DEITY
knows, someone still needs a good kicking, but at least we'll have
learned something :)

-- 
dwmw2
-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2023/be93cddf/attachment.bin>

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[David Woodhouse]

On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
> At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
> dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
> for the dmar+rc6 hangs reported. 

Um... let me restate that for clarity (and partly for Rajesh's benefit).

The DMAR associated with the integrated graphics is *disabled*.
Turned off. Not active. Ever.

You have a problem when you enable the *other* DMAR units in the system,
which should not be affecting the graphics device in any way.

When you do this, you see 'hangs' with semaphores and RC6. Is there a
better description of these 'hangs' somewhere? Is the hardware
completely locked?

These hangs go away when you disable the DMAR units. Again, that is the
*other* DMAR units in the system that have nothing to do with graphics.

While I'm getting quite used to DMAR-related errata, this one does make
me stop and think 'wtf?'. It just seems so incongruous that disabling an
*unrelated* IOMMU would make the problem go away, and it makes me wonder
if it's actually a timing-related issue which is always there, but
something about the use of DMAR for network/disk/etc. makes it more
likely to trigger?

We definitely need the hardware folks to get to the bottom of this one.

-- 
dwmw2
-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2023/32652c1a/attachment-0001.bin>

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[David Woodhouse]

On Wed, 2011-11-23 at 11:26 +0100, Daniel Vetter wrote:
> On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
> > On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett  
> > wrote:
> > 
> > > So the user has to choose between 5W of power saving or having dmar? And 
> > > we default to giving them dmar? I think that's going to come as a 
> > > surprise to people.
> > 
> > You'd have to go into the BIOS to turn this on for most machines at
> > least?
> > 
> > But, yeah, it seems like we should be turning DMAR off unless explicitly
> > requested; I can't understand how you'd ever need this running native on
> > the hardware. Not exactly an area I care about deeply; I've always
> > worked hard to make sure all virtualization garbage is disabled on every
> > machine I use.
> 
> Problem is that we need to disable dmar on the entire box, afaics. And I
> assume that a bunch of people abusing desktop boards as servers will call
> "regression" on that.

Hm, do you really have to disable it for the entire box, or just the
graphics?

Do we have a coherent erratum from Intel for the issues mentioned above
with DMAR+gfx+RC6?

Keith, do you know if a sighting has been filed and the hardware folks
are working on it?

Rajesh, are you familiar with this issue?

-- 
dwmw2
-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2023/86c5b9c5/attachment.bin>

[PATCH 2/2] drm/kms: Use the standard VESA timeout for DDC channels

[Keith Packard]

On Fri, 21 Oct 2011 09:10:12 +0200, Jean Delvare  wrote:

> - /* vesa says 2.2 ms is enough, 1 jiffy doesn't seem to always
> -  * make this, 2 jiffies is a lot more reliable */
> - i2c->algo.bit.timeout = 2;
> + i2c->algo.bit.timeout = usecs_to_jiffies(2200); /* from VESA */

[Intel-gfx] [PATCH] iommu: export no_iommu and dmar_disabled symbols

[Keith Packard]

On Wed, 23 Nov 2011 20:36:00 +, David Woodhouse  
wrote:

> This is horrid. In the general case, drivers have no business knowing
> this. We need to properly identify what is wrong with this hardware, and
> put in a quirk for it ? perhaps refusing to enable the IOMMU at all on
> the broken chipsets.

That'd be fine with me, right now we're disabling RC6 and semaphores --
semaphores aren't all that important, although they do improve
performance a bit. RC6 is important, saving a huge amount of power.

I'd also be OK with requiring special options to enable DMAR and having
that also disable RC6/semaphores, if you'd rather expose that. In either
case, we need something that works and avoids hanging machines.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2023/cba3939a/attachment.pgp>

[RFC] Virtual CRTCs (proposal + experimental code)

[Dave Airlie]

>
> I would like to bring to the attention of dri-devel and linux-fbdev
> community a set of hopefully useful and interesting patches that
> I (and a few other colleagues) have been working on during the past
> few months. Here, I will provide a short abstract, so that you can
> decide whether this is of interest for you. At the end, I will
> provide the pointers to the code and documentation.
>
> The code is based on Dave Arilie's tree, drm-next branch and it
> allows a GPU driver to have an arbitrary number of CRTCs
> (configurable by user) instead of only those CRTCs that represent
> real hardware.

So another question I have is how you would intend this to work from a
user POV, like how it would integrate with a desktop environment, X or
wayland, i.e. with little or no configuration.

I still foresee problems with tiling, we generally don't encourage
accel code to live in the kernel, and you'll really want a
tiled->untiled blit for this thing, also for Intel GPUs where you have
UMA, would you read from the UMA.

It also doesn't solve the optimus GPU problem in any useful fashion,
since it can't deal with all the use cases, so we still have to write
an alternate solution that can deal with them, so we just end up with
two answers.

Dave.

[PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Keith Packard]

On Wed, 23 Nov 2011 16:29:58 +0800, Wu Fengguang  
wrote:

> What I need is a hot plug hook that knows whether the monitor is
> plugged or removed, which is only possible if the hook is called
> after ->detect().

That would be mode_set to tell you that the monitor is in use, and the
disable function to tell you when the monitor is no longer in use.

You do not want to do anything to the hardware in the hot_plug paths;
those are strictly informative; telling user space which connectors are
present.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/2023/fdd0330f/attachment.pgp>

[PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Daniel Vetter]

On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
> On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett  wrote:
> 
> > So the user has to choose between 5W of power saving or having dmar? And 
> > we default to giving them dmar? I think that's going to come as a 
> > surprise to people.
> 
> You'd have to go into the BIOS to turn this on for most machines at
> least?
> 
> But, yeah, it seems like we should be turning DMAR off unless explicitly
> requested; I can't understand how you'd ever need this running native on
> the hardware. Not exactly an area I care about deeply; I've always
> worked hard to make sure all virtualization garbage is disabled on every
> machine I use.

Problem is that we need to disable dmar on the entire box, afaics. And I
assume that a bunch of people abusing desktop boards as servers will call
"regression" on that.
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 00/14] update exynos drm driver.

[InKi Dae]

Hello, Dave.

I had posted DRM Driver patchsets for Exsynos SoC but there is no any
feedback. could you please review them? and if the patchsets have any
problem, please give me your advice anytime. and also we are ready for
next patchsets.

the next patchsets include the followings:
- fix some previous patchset bugs.
- add power managerment featrue based on runtim-pm.

from next patchset, I would request GIT PULL if you are ok.

Thank you,
Inki Dae.

2011/11/12 Inki Dae :
> Hello, Dave. sorry but please, ignor previous patch sets posted
> by Seung-Woo Kim. I am seding patch sets again.
>
> this patch sets are as the following.
> - add kms poll to handle hdp event.
> - fix converting between display mode and timing.
> - fix connector and crtc callbacks to call proper display driver.
> - fix vblank bug that manager->pipe could be -1 at vsync interrupt handler.
> - add exynos_drm_gem_init() that is used commonly.
> - change buffer structure to support IOMMU in the future.
> - add comments and code clean.
>
> this patch is based on git repository below:
> git://people.freedesktop.org/~airlied/linux.git
> branch name: drm-fixes
> commit-id: 8f3f1c9a22a6420e28c2d3eff59b832893bc8efc
>
> Inki Dae (7):
> ?drm/exynos: added manager object to connector
> ?drm/exynos: changed exynos_drm_display to exynos_drm_display_ops
> ?drm/exynos: use gem create function generically
> ?drm/exynos: removed unnecessary variable.
> ?drm/exynos: changed buffer structure.
> ?drm/exynos: fix vblank bug.
> ?drm/exynos: include linux/module.h
>
> Joonyoung Shim (2):
> ?drm/exynos: restored kernel_fb_list when reiniting fb_helper
> ?drm/exynos: added crtc dpms for disable crtc
>
> Seung-Woo Kim (5):
> ?drm/exynos: added kms poll for handling hpd event
> ?drm/exynos: fixed connector flag with hpd and interlace scan for hdmi
> ?drm/exynos: fixed converting between display mode and timing
> ?drm/exynos: removed meaningless parameter from fbdev update
> ?drm/exynos: checked for null pointer
>
> ?drivers/gpu/drm/exynos/exynos_drm_buf.c ? ? ? | ? 62 +
> ?drivers/gpu/drm/exynos/exynos_drm_buf.h ? ? ? | ? 21 +-
> ?drivers/gpu/drm/exynos/exynos_drm_connector.c | ? 78 +++--
> ?drivers/gpu/drm/exynos/exynos_drm_crtc.c ? ? ?| ? 76 ++--
> ?drivers/gpu/drm/exynos/exynos_drm_crtc.h ? ? ?| ? 25 +++
> ?drivers/gpu/drm/exynos/exynos_drm_drv.c ? ? ? | ? ?5 ++
> ?drivers/gpu/drm/exynos/exynos_drm_drv.h ? ? ? | ? 11 ++--
> ?drivers/gpu/drm/exynos/exynos_drm_encoder.c ? | ? 65 ++---
> ?drivers/gpu/drm/exynos/exynos_drm_encoder.h ? | ? ?1 +
> ?drivers/gpu/drm/exynos/exynos_drm_fb.c ? ? ? ?| ? 66 ++---
> ?drivers/gpu/drm/exynos/exynos_drm_fbdev.c ? ? | ? 44 +++
> ?drivers/gpu/drm/exynos/exynos_drm_fimd.c ? ? ?| ? 62 -
> ?drivers/gpu/drm/exynos/exynos_drm_gem.c ? ? ? | ? 94 
> +++--
> ?drivers/gpu/drm/exynos/exynos_drm_gem.h ? ? ? | ? 28 ++--
> ?include/drm/exynos_drm.h ? ? ? ? ? ? ? ? ? ? ?| ? ?9 +--
> ?15 files changed, 416 insertions(+), 231 deletions(-)
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH 00/14] update exynos drm driver.

[InKi Dae]

Mr. Park. I rebased the drm-fixes tree.
commit-id: 8f3f1c9a22a6420e28c2d3eff59b832893bc8efc

and you can find patches at git
http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/exynos-drm

thank you.

2011/11/14 Kyungmin Park :
> Hi,
>
> Also you can find relevant patches at git
> http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/samsung-drm
>
> To Mr. Dae.
> Can you rebase the latest drm-next tree or mainline to merge easily?
>
> Thank you,
> Kyungmin Park
>
> On 11/12/11, Inki Dae  wrote:
>> Hello, Dave. sorry but please, ignor previous patch sets posted
>> by Seung-Woo Kim. I am seding patch sets again.
>>
>> this patch sets are as the following.
>> - add kms poll to handle hdp event.
>> - fix converting between display mode and timing.
>> - fix connector and crtc callbacks to call proper display driver.
>> - fix vblank bug that manager->pipe could be -1 at vsync interrupt handler.
>> - add exynos_drm_gem_init() that is used commonly.
>> - change buffer structure to support IOMMU in the future.
>> - add comments and code clean.
>>
>> this patch is based on git repository below:
>> git://people.freedesktop.org/~airlied/linux.git
>> branch name: drm-fixes
>> commit-id: 8f3f1c9a22a6420e28c2d3eff59b832893bc8efc
>>
>> Inki Dae (7):
>> ? drm/exynos: added manager object to connector
>> ? drm/exynos: changed exynos_drm_display to exynos_drm_display_ops
>> ? drm/exynos: use gem create function generically
>> ? drm/exynos: removed unnecessary variable.
>> ? drm/exynos: changed buffer structure.
>> ? drm/exynos: fix vblank bug.
>> ? drm/exynos: include linux/module.h
>>
>> Joonyoung Shim (2):
>> ? drm/exynos: restored kernel_fb_list when reiniting fb_helper
>> ? drm/exynos: added crtc dpms for disable crtc
>>
>> Seung-Woo Kim (5):
>> ? drm/exynos: added kms poll for handling hpd event
>> ? drm/exynos: fixed connector flag with hpd and interlace scan for hdmi
>> ? drm/exynos: fixed converting between display mode and timing
>> ? drm/exynos: removed meaningless parameter from fbdev update
>> ? drm/exynos: checked for null pointer
>>
>> ?drivers/gpu/drm/exynos/exynos_drm_buf.c ? ? ? | ? 62 +
>> ?drivers/gpu/drm/exynos/exynos_drm_buf.h ? ? ? | ? 21 +-
>> ?drivers/gpu/drm/exynos/exynos_drm_connector.c | ? 78 +++--
>> ?drivers/gpu/drm/exynos/exynos_drm_crtc.c ? ? ?| ? 76 ++--
>> ?drivers/gpu/drm/exynos/exynos_drm_crtc.h ? ? ?| ? 25 +++
>> ?drivers/gpu/drm/exynos/exynos_drm_drv.c ? ? ? | ? ?5 ++
>> ?drivers/gpu/drm/exynos/exynos_drm_drv.h ? ? ? | ? 11 ++--
>> ?drivers/gpu/drm/exynos/exynos_drm_encoder.c ? | ? 65 ++---
>> ?drivers/gpu/drm/exynos/exynos_drm_encoder.h ? | ? ?1 +
>> ?drivers/gpu/drm/exynos/exynos_drm_fb.c ? ? ? ?| ? 66 ++---
>> ?drivers/gpu/drm/exynos/exynos_drm_fbdev.c ? ? | ? 44 +++
>> ?drivers/gpu/drm/exynos/exynos_drm_fimd.c ? ? ?| ? 62 -
>> ?drivers/gpu/drm/exynos/exynos_drm_gem.c ? ? ? | ? 94
>> +++--
>> ?drivers/gpu/drm/exynos/exynos_drm_gem.h ? ? ? | ? 28 ++--
>> ?include/drm/exynos_drm.h ? ? ? ? ? ? ? ? ? ? ?| ? ?9 +--
>> ?15 files changed, 416 insertions(+), 231 deletions(-)
>> --
>> 1.7.4.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH 00/14] update exynos drm driver.

[Dave Airlie]

On Wed, Nov 23, 2011 at 2:23 AM, InKi Dae  wrote:
> Hello, Dave.
>
> I had posted DRM Driver patchsets for Exsynos SoC but there is no any
> feedback. could you please review them? and if the patchsets have any
> problem, please give me your advice anytime. and also we are ready for
> next patchsets.
>
> the next patchsets include the followings:
> - fix some previous patchset bugs.
> - add power managerment featrue based on runtim-pm.
>
> from next patchset, I would request GIT PULL if you are ok.

I'm mainly trying to decide if they should go to Linus now or just go
into -next,

do you guys have a major preference one way or the other? later on
when the driver is more feature complete,
it would be good to send the fixes for the current tree separate to
new features.

Dave.

Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0

[Meelis Roos]

> > Yes, VT-x and VT-d are both enabled from BIOS setup.
> 
> Any reason for that? We've found all kinds of problems with DMAR enabled
> on these machines that is only resolved by completely turning it
> off. You might try with intel_iommu=off and make sure that's stable.

Well, there is reason for VT-x but actually none for VT-d because I am 
not giving out any PCI devices to virtual machines. Will also test 
witout it.

-- 
Meelis Roos (mroos at linux.ee)

WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

[Christoph Lameter]

On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:

> > FIX idr_layer_cache: Marking all objects used
>
> Yesterday I couldn't reproduce the issue at all. But today I've hit
> exactly the same spot again. (CCing the drm list)

Well this is looks like write after free.

> =
> BUG idr_layer_cache: Poison overwritten
> -
> Object 8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 
> Object 880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
> 

And its an integer sized write of 0. If you look at the struct definition
and lookup the offset you should be able to locate the field that
was modified.

i915: hangcheck timer elapsed

[Chris Wilson]

On Tue, 22 Nov 2011 19:44:52 -0800, Keith Packard  wrote:
> On Tue, 22 Nov 2011 14:43:00 -0800 (PST), Linus Torvalds  linux-foundation.org> wrote:
> 
> > X is hung, but I can at least switch VT's and send this from a text 
> > terminal..
> 
> Yeah, the GPU is locked up; doesn't look like we did anything wrong in
> the kernel here; it's happily waiting for the GPU which isn't moving.
> 
> Presumably a bug in either the 2D driver or Mesa. I'm betting the 2D
> driver, and yes, I'm trying to fix this (by deleting code, which is
> always the best way).

Indeed the fix landed in 2.13.902 by removing some erroneous hardcoded
maxima, and since we currently have lots of duplication in the code the
video paths remained broken until 2.15.0.

commit 3c5b1399e29ef577b8b91655b5e1c215d1b6dfbb
Author: Chris Wilson 
Date:   Tue Nov 9 20:20:06 2010 +

i915: Disable maximum state addresses

As the kernel controls the relocation of state buffers, we should not
hard code the maximum permissible value for them.

Fixes an eventual hang with full-gtt.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

Keith finally decloaked and sent me his -fixes queue so this is mostly 
that along with some radeon i2c fixes/cleanups, a radeon fix for some 
userspace problems and a couple of drm core and vga arb fixes.

I have some exynos changes I might send separatly to you, as that driver 
only went in during the merge window so it not like they can really cause 
any regressions.

Dave.

The following changes since commit 6991b8f2a3193397461104a27be417addb8d032b:

  drm/radeon/kms: fix segfault in pm rework (2011-11-15 19:44:03 +)

are available in the git repository at:
  git://people.freedesktop.org/~airlied/linux drm-fixes

Adam Jackson (1):
  drm/i915: intel_choose_pipe_bpp_dither messages should be DRM_DEBUG_KMS

Alex Deucher (2):
  drm/radeon/kms: fix up gpio i2c mask bits for r4xx for real
  drm/radeon/kms/atom: unify i2c gpio table handling

Ben Widawsky (1):
  drm/i915: forcewake warning fixes in debugfs

Dan Carpenter (1):
  drm/i915: fix if statement (bogus semi-colon)

Daniel Vetter (4):
  drm/i915: disable temporal dithering on the internal panel
  drm/i915: only match on PCI_BASE_CLASS_DISPLAY
  drm/i915: Ivybridge still has fences!
  drm/i915: add constants to size fence arrays and fields

Dave Airlie (1):
  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~keithp/linux into drm-fixes

Eric Anholt (3):
  drm/i915: Fix object refcount leak on mmappable size limit error path.
  drm/i915: Turn on a required 3D clock gating bit on Sandybridge.
  drm/i915: Turn on another required clock gating bit on gen6.

Jesse Barnes (1):
  drm/i915: enable cacheable objects on Ivybridge

Julia Lawall (1):
  drivers/gpu/vga/vgaarb.c: add missing kfree

Keith Packard (12):
  agp: iommu_gfx_mapped only available if CONFIG_INTEL_IOMMU is set
  drm/i915: Use mode_config.mutex in ironlake_panel_vdd_work
  drm/i915: Module parameters using '-1' as default must be signed type
  drm/i915: Move common PCH_PP_CONTROL setup to ironlake_get_pp_control
  drm/i915: Remove link_status field from intel_dp structure
  drm/i915: Treat PCH eDP like DP in most places
  drm/i915: Let panel power sequencing hardware do its job
  drm/i915: Make DP prepare/commit consistent with DP dpms
  drm/i915: Try harder during dp pattern 1 link training
  drm/i915: Remove trailing white space
  drm/i915: Initiate DP link training only on the lanes we'll be using
  drm/i915: Use DPCD value for max DP lanes.

Marek Ol??k (1):
  drm/radeon/kms: add a CS ioctl flag not to rewrite tiling flags in the CS

Rakib Mullick (1):
  drm, i915: Fix memory leak in i915_gem_busy_ioctl().

Takashi Iwai (1):
  drm/i915: Fix inconsistent backlight level during disabled

Thomas Hellstrom (1):
  ttm: Don't return the bo reserved on error path

Xi Wang (1):
  drm: integer overflow in drm_mode_dirtyfb_ioctl()

 drivers/gpu/drm/drm_crtc.c   |4 +
 drivers/gpu/drm/i915/i915_debugfs.c  |   57 -
 drivers/gpu/drm/i915/i915_drv.c  |6 +-
 drivers/gpu/drm/i915/i915_drv.h  |   19 +-
 drivers/gpu/drm/i915/i915_gem.c  |   12 +-
 drivers/gpu/drm/i915/i915_irq.c  |1 +
 drivers/gpu/drm/i915/i915_reg.h  |   21 ++-
 drivers/gpu/drm/i915/i915_suspend.c  |2 +
 drivers/gpu/drm/i915/intel_display.c |   33 ++-
 drivers/gpu/drm/i915/intel_dp.c  |  411 +-
 drivers/gpu/drm/i915/intel_panel.c   |3 +-
 drivers/gpu/drm/radeon/evergreen_cs.c|   92 ---
 drivers/gpu/drm/radeon/r300.c|   94 ---
 drivers/gpu/drm/radeon/r600_cs.c |   26 ++-
 drivers/gpu/drm/radeon/radeon.h  |3 +-
 drivers/gpu/drm/radeon/radeon_atombios.c |  204 +++-
 drivers/gpu/drm/radeon/radeon_cs.c   |   11 +-
 drivers/gpu/drm/radeon/radeon_drv.c  |3 +-
 drivers/gpu/drm/ttm/ttm_bo.c |8 +-
 drivers/gpu/vga/vgaarb.c |   18 +-
 include/drm/drm_mode.h   |2 +
 include/drm/radeon_drm.h |4 +
 22 files changed, 601 insertions(+), 433 deletions(-)

Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0

[Meelis Roos]

> > > 3.0 worked fine, 3.1-rc9 worked fine, I think -rc10 too. 3.1 release 
> > > hangs in random places while using X.

Also found out that 3.1-rc10 was already bad, will redo the bisect but 
it takes days sinc I'm not at the machine most of the time.

> Do you have VT-d enabled in the BIOS?

Yes, VT-x and VT-d are both enabled from BIOS setup.

Also, bootup dmesg from 3.2-rc2+git from when it failed silently:

[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.2.0-rc2-00369-gbbbc479 (mroos at prometheus) 
(gcc version 4.6.2 (Debian 4.6.2-4) ) #14 SMP Tue Nov 22 12:41:30 EET 2011
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-rc2-00369-gbbbc479 
root=/dev/sda1 ro
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009f800 (usable)
[0.00]  BIOS-e820: 0009f800 - 000a (reserved)
[0.00]  BIOS-e820: 000e8000 - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - db7ac440 (usable)
[0.00]  BIOS-e820: db7ac440 - db7ae4a0 (ACPI NVS)
[0.00]  BIOS-e820: db7ae4a0 - e000 (reserved)
[0.00]  BIOS-e820: f400 - f800 (reserved)
[0.00]  BIOS-e820: fe00 - fed4 (reserved)
[0.00]  BIOS-e820: fed45000 - 0001 (reserved)
[0.00]  BIOS-e820: 0001 - 00011800 (usable)
[0.00] NX (Execute Disable) protection: active
[0.00] DMI 2.6 present.
[0.00] DMI: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 
786H1 v01.05 06/09/2010
[0.00] e820 update range:  - 0001 (usable) 
==> (reserved)
[0.00] e820 remove range: 000a - 0010 (usable)
[0.00] No AGP bridge found
[0.00] last_pfn = 0x118000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-E3FFF write-protect
[0.00]   E4000-E write-back
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask E write-back
[0.00]   1 base 0DB80 mask FFF80 uncachable
[0.00]   2 base 0DC00 mask FFC00 uncachable
[0.00]   3 base 0E000 mask FE000 uncachable
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] e820 update range: db80 - 0001 (usable) 
==> (reserved)
[0.00] last_pfn = 0xdb7ac max_arch_pfn = 0x4
[0.00] found SMP MP-table at [880f9bf0] f9bf0
[0.00] initial memory mapped : 0 - 2000
[0.00] Base memory trampoline at [8809a000] 9a000 size 20480
[0.00] init_memory_mapping: -db7ac000
[0.00]  00 - 00db60 page 2M
[0.00]  00db60 - 00db7ac000 page 4k
[0.00] kernel direct mapping tables up to db7ac000 @ 1fffa000-2000
[0.00] init_memory_mapping: 0001-00011800
[0.00]  01 - 011800 page 2M
[0.00] kernel direct mapping tables up to 11800 @ db7a6000-db7ac000
[0.00] ACPI: RSDP 000e5210 00014 (v00 COMPAQ)
[0.00] ACPI: RSDT db7d0540 00044 (v01 HPQOEM SLIC-BPC 20100609  
)
[0.00] ACPI: FACP db7d05e8 00074 (v01 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI Warning: Optional field Pm2ControlBlock has zero address or 
length: 0x0050/0x0 (20110623/tbfadt-560)
[0.00] ACPI Warning: Invalid length for Pm2ControlBlock: 0, using 
default 8 (20110623/tbfadt-610)
[0.00] ACPI: DSDT db7d0a4f 0A69E (v01 COMPAQ DSDT_PRJ 0001 
MSFT 010E)
[0.00] ACPI: FACS db7d0500 00040
[0.00] ACPI: APIC db7d065c 000BC (v01 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI: ASF! db7d0718 00063 (v32 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI: MCFG db7d077b 0003C (v01 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI: TCPA db7d07b7 00032 (v01 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI: SLIC db7d07e9 00176 (v01 HPQOEM SLIC-BPC 0001  
)
[0.00] ACPI: HPET db7d095f 00038 (v01 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI: DMAR db7d0997 000B8 (v01 COMPAQ IBEXPEAK 0001  
)
[0.00] ACPI: Local APIC address 0xfee0
[0.00]  [ea00-ea00045f] PMD -> 

3.2-rc2+: Reported regressions from 3.0 and 3.1

[Rafał Miłecki]

W dniu 21 listopada 2011 23:22 u?ytkownik Linus Torvalds
 napisa?:
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki  wrote:
>>
>> Subject ? ?: [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or 
>> suspending
>> Submitter ?: Rafa? Mi?ecki 
>> Date ? ? ? : 2011-11-09 11:46
>> Message-ID : CACna6ryTdLcWVYgHu=_mRFga1sFivpE_DyZOY-HMmKggkWAJAw at 
>> mail.gmail.com
>> References : http://marc.info/?l=linux-netdev=13208398088=4
>
> This should be fixed by commit 1401a8008a09 ("sky2: fix hang on
> shutdown (and other irq issues)") in current -git.

This patch doesn't fix my hang.

However git contains also:
sky2: fix hang in napi_disable
This is the one fixing my case.

So the bug is resolved, however I'm a little disappointed noone
ping-ed me about that patches. I've spent some time on bisecting this
issue, expected to get some response :/

-- 
Rafa?

[PATCH] drm: integer overflow in drm_mode_dirtyfb_ioctl()

[Xi Wang]

There is a potential integer overflow in drm_mode_dirtyfb_ioctl()
if userspace passes in a large num_clips.  The call to kmalloc would
allocate a small buffer, and the call to fb->funcs->dirty may result
in a memory corruption.

Reported-by: Haogang Chen 
Signed-off-by: Xi Wang 
---
 drivers/gpu/drm/drm_crtc.c |4 
 include/drm/drm_mode.h |2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 405c63b..8323fc3 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1873,6 +1873,10 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
}

if (num_clips && clips_ptr) {
+   if (num_clips < 0 || num_clips > DRM_MODE_FB_DIRTY_MAX_CLIPS) {
+   ret = -EINVAL;
+   goto out_err1;
+   }
clips = kzalloc(num_clips * sizeof(*clips), GFP_KERNEL);
if (!clips) {
ret = -ENOMEM;
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index d30bedf..ddd46db 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -235,6 +235,8 @@ struct drm_mode_fb_cmd {
 #define DRM_MODE_FB_DIRTY_ANNOTATE_FILL 0x02
 #define DRM_MODE_FB_DIRTY_FLAGS 0x03

+#define DRM_MODE_FB_DIRTY_MAX_CLIPS 256
+
 /*
  * Mark a region of a framebuffer as dirty.
  *
-- 
1.7.5.4

Re: [PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Wu Fengguang]

On Wed, Nov 23, 2011 at 02:25:14AM +0800, Keith Packard wrote:
 On Tue, 22 Nov 2011 15:40:55 +0800, Wu Fengguang fengguang...@intel.com 
 wrote:
 
  So the v3 patch will behave equally well on KMS console, gnome desktop
  and bare X. Shall we just use it, or go back and use the original
  -hot_remove patch?
 
 I'm not sure why we need any change to the core DRM code. The HDMI and
 DP drivers will be told when to turn the monitors on and off, and that's

Yeah, The DP driver will be notified via the intel_dp_hot_plug() hook
if I understand it right.

 the appropriate time to control whether audio is routed to them.

However -hot_plug() is called too early to be useful for this case.

What I need is a hot plug hook that knows whether the monitor is
plugged or removed, which is only possible if the hook is called
after -detect().

Or, we can avoid adding the -hotplug() hook and just add the call
directly to intel_hdmi_detect() and intel_dp_detect().

The below patch does this and eliminates the DRM callback :-)

 Hotplug is considered simply a notification to user space that
 something has changed -- user space is in charge of configuring
 which outputs are in use.

Yeah, and here is another notification to the audio driver demanded by
the HD audio spec.

Thanks,
Fengguang
---
Subject: drm/i915: hot plug/remove notification to HDMI audio driver
Date: Fri Nov 11 13:49:04 CST 2011

On monitor hot plug/unplug, set/clear SDVO_AUDIO_ENABLE or
DP_AUDIO_OUTPUT_ENABLE accordingly, so that the audio driver will
receive hot plug events and take action to refresh its device state and
ELD contents.

After intel_dp_detect() knows whether the monitor is plugged or
removed, it will call intel_dp_hotplug_audio() to notify the audio
driver of the event.

It's noticed that bare metal X may not call -mode_set() at monitor hot
plug, so it's necessary to call drm_edid_to_eld() earlier at -detect()
time rather than in intel_ddc_get_modes(), so that intel_write_eld() can
see the new ELD in intel_dp_hotplug_audio().

The call sequence on hot plug is

- KMS console, full blown X (eg. gnome desktop)
-detect
  drm_edid_to_eld
-mode_set
  intel_write_eld
  set SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE
- bare metal X (eg. fluxbox)
-detect
  drm_edid_to_eld
  intel_dp_hotplug_audio()
intel_write_eld
set SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE

On hot remove, the call sequence is

-detect
  intel_dp_hotplug_audio()
clear SDVO_AUDIO_ENABLE/DP_AUDIO_OUTPUT_ENABLE

cc: Wang Zhenyu zhenyu.z.w...@intel.com
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c|   47 ---
 drivers/gpu/drm/i915/intel_hdmi.c  |   32 ++
 drivers/gpu/drm/i915/intel_modes.c |2 -
 3 files changed, 68 insertions(+), 13 deletions(-)

--- linux.orig/drivers/gpu/drm/i915/intel_dp.c  2011-11-23 15:16:10.0 
+0800
+++ linux/drivers/gpu/drm/i915/intel_dp.c   2011-11-23 16:20:25.0 
+0800
@@ -28,6 +28,7 @@
 #include linux/i2c.h
 #include linux/slab.h
 #include linux/export.h
+#include drm/drm_edid.h
 #include drmP.h
 #include drm.h
 #include drm_crtc.h
@@ -1940,6 +1941,27 @@ intel_dp_get_edid_modes(struct drm_conne
return ret;
 }
 
+static void intel_dp_hotplug_audio(struct drm_connector *connector,
+  enum drm_connector_status status)
+{
+   struct intel_dp *intel_dp = intel_attached_dp(connector);
+   struct drm_device *dev = intel_dp-base.base.dev;
+   struct drm_i915_private *dev_priv = dev-dev_private;
+   struct drm_crtc *crtc = intel_dp-base.base.crtc;
+
+   DRM_DEBUG_DRIVER(hotplug status %d crtc %p eld %#x\n,
+status, crtc, (unsigned int)connector-eld[0]);
+
+   if (status == connector_status_disconnected)
+   intel_dp-DP = ~DP_AUDIO_OUTPUT_ENABLE;
+   else if (status == connector_status_connected  crtc) {
+   intel_write_eld(intel_dp-base.base, crtc-mode);
+   intel_dp-DP |= DP_AUDIO_OUTPUT_ENABLE;
+   } else
+   return;
+   I915_WRITE(intel_dp-output_reg, intel_dp-DP);
+   POSTING_READ(intel_dp-output_reg);
+}
 
 /**
  * Uses CRT_HOTPLUG_EN and CRT_HOTPLUG_STAT to detect DP connection.
@@ -1968,20 +1990,23 @@ intel_dp_detect(struct drm_connector *co
  intel_dp-dpcd[6], intel_dp-dpcd[7]);
 
if (status != connector_status_connected)
-   return status;
+   goto out;
 
-   if (intel_dp-force_audio) {
-   intel_dp-has_audio = intel_dp-force_audio  0;
-   } else {
-   edid = intel_dp_get_edid(connector, intel_dp-adapter);
-   if (edid) {
-   intel_dp-has_audio = drm_detect_monitor_audio(edid);
-   connector-display_info.raw_edid = NULL;
-   kfree(edid);
- 

Re: Bisected regression: hang on i915 between 3.1.0-rc9 and 3.1.0

[Meelis Roos]

  Yes, VT-x and VT-d are both enabled from BIOS setup.
 
 Any reason for that? We've found all kinds of problems with DMAR enabled
 on these machines that is only resolved by completely turning it
 off. You might try with intel_iommu=off and make sure that's stable.

Well, there is reason for VT-x but actually none for VT-d because I am 
not giving out any PCI devices to virtual machines. Will also test 
witout it.

-- 
Meelis Roos (mr...@linux.ee)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

Keith finally decloaked and sent me his -fixes queue so this is mostly 
that along with some radeon i2c fixes/cleanups, a radeon fix for some 
userspace problems and a couple of drm core and vga arb fixes.

I have some exynos changes I might send separatly to you, as that driver 
only went in during the merge window so it not like they can really cause 
any regressions.

Dave.

The following changes since commit 6991b8f2a3193397461104a27be417addb8d032b:

  drm/radeon/kms: fix segfault in pm rework (2011-11-15 19:44:03 +)

are available in the git repository at:
  git://people.freedesktop.org/~airlied/linux drm-fixes

Adam Jackson (1):
  drm/i915: intel_choose_pipe_bpp_dither messages should be DRM_DEBUG_KMS

Alex Deucher (2):
  drm/radeon/kms: fix up gpio i2c mask bits for r4xx for real
  drm/radeon/kms/atom: unify i2c gpio table handling

Ben Widawsky (1):
  drm/i915: forcewake warning fixes in debugfs

Dan Carpenter (1):
  drm/i915: fix if statement (bogus semi-colon)

Daniel Vetter (4):
  drm/i915: disable temporal dithering on the internal panel
  drm/i915: only match on PCI_BASE_CLASS_DISPLAY
  drm/i915: Ivybridge still has fences!
  drm/i915: add constants to size fence arrays and fields

Dave Airlie (1):
  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~keithp/linux into drm-fixes

Eric Anholt (3):
  drm/i915: Fix object refcount leak on mmappable size limit error path.
  drm/i915: Turn on a required 3D clock gating bit on Sandybridge.
  drm/i915: Turn on another required clock gating bit on gen6.

Jesse Barnes (1):
  drm/i915: enable cacheable objects on Ivybridge

Julia Lawall (1):
  drivers/gpu/vga/vgaarb.c: add missing kfree

Keith Packard (12):
  agp: iommu_gfx_mapped only available if CONFIG_INTEL_IOMMU is set
  drm/i915: Use mode_config.mutex in ironlake_panel_vdd_work
  drm/i915: Module parameters using '-1' as default must be signed type
  drm/i915: Move common PCH_PP_CONTROL setup to ironlake_get_pp_control
  drm/i915: Remove link_status field from intel_dp structure
  drm/i915: Treat PCH eDP like DP in most places
  drm/i915: Let panel power sequencing hardware do its job
  drm/i915: Make DP prepare/commit consistent with DP dpms
  drm/i915: Try harder during dp pattern 1 link training
  drm/i915: Remove trailing white space
  drm/i915: Initiate DP link training only on the lanes we'll be using
  drm/i915: Use DPCD value for max DP lanes.

Marek Olšák (1):
  drm/radeon/kms: add a CS ioctl flag not to rewrite tiling flags in the CS

Rakib Mullick (1):
  drm, i915: Fix memory leak in i915_gem_busy_ioctl().

Takashi Iwai (1):
  drm/i915: Fix inconsistent backlight level during disabled

Thomas Hellstrom (1):
  ttm: Don't return the bo reserved on error path

Xi Wang (1):
  drm: integer overflow in drm_mode_dirtyfb_ioctl()

 drivers/gpu/drm/drm_crtc.c   |4 +
 drivers/gpu/drm/i915/i915_debugfs.c  |   57 -
 drivers/gpu/drm/i915/i915_drv.c  |6 +-
 drivers/gpu/drm/i915/i915_drv.h  |   19 +-
 drivers/gpu/drm/i915/i915_gem.c  |   12 +-
 drivers/gpu/drm/i915/i915_irq.c  |1 +
 drivers/gpu/drm/i915/i915_reg.h  |   21 ++-
 drivers/gpu/drm/i915/i915_suspend.c  |2 +
 drivers/gpu/drm/i915/intel_display.c |   33 ++-
 drivers/gpu/drm/i915/intel_dp.c  |  411 +-
 drivers/gpu/drm/i915/intel_panel.c   |3 +-
 drivers/gpu/drm/radeon/evergreen_cs.c|   92 ---
 drivers/gpu/drm/radeon/r300.c|   94 ---
 drivers/gpu/drm/radeon/r600_cs.c |   26 ++-
 drivers/gpu/drm/radeon/radeon.h  |3 +-
 drivers/gpu/drm/radeon/radeon_atombios.c |  204 +++-
 drivers/gpu/drm/radeon/radeon_cs.c   |   11 +-
 drivers/gpu/drm/radeon/radeon_drv.c  |3 +-
 drivers/gpu/drm/ttm/ttm_bo.c |8 +-
 drivers/gpu/vga/vgaarb.c |   18 +-
 include/drm/drm_mode.h   |2 +
 include/drm/radeon_drm.h |4 +
 22 files changed, 601 insertions(+), 433 deletions(-)___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915: hangcheck timer elapsed

[Chris Wilson]

On Tue, 22 Nov 2011 19:44:52 -0800, Keith Packard kei...@keithp.com wrote:
 On Tue, 22 Nov 2011 14:43:00 -0800 (PST), Linus Torvalds 
 torva...@linux-foundation.org wrote:
 
  X is hung, but I can at least switch VT's and send this from a text 
  terminal..
 
 Yeah, the GPU is locked up; doesn't look like we did anything wrong in
 the kernel here; it's happily waiting for the GPU which isn't moving.
 
 Presumably a bug in either the 2D driver or Mesa. I'm betting the 2D
 driver, and yes, I'm trying to fix this (by deleting code, which is
 always the best way).

Indeed the fix landed in 2.13.902 by removing some erroneous hardcoded
maxima, and since we currently have lots of duplication in the code the
video paths remained broken until 2.15.0.

commit 3c5b1399e29ef577b8b91655b5e1c215d1b6dfbb
Author: Chris Wilson ch...@chris-wilson.co.uk
Date:   Tue Nov 9 20:20:06 2010 +

i915: Disable maximum state addresses

As the kernel controls the relocation of state buffers, we should not
hard code the maximum permissible value for them.

Fixes an eventual hang with full-gtt.
-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] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Daniel Vetter]

On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
 On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett m...@redhat.com wrote:
 
  So the user has to choose between 5W of power saving or having dmar? And 
  we default to giving them dmar? I think that's going to come as a 
  surprise to people.
 
 You'd have to go into the BIOS to turn this on for most machines at
 least?
 
 But, yeah, it seems like we should be turning DMAR off unless explicitly
 requested; I can't understand how you'd ever need this running native on
 the hardware. Not exactly an area I care about deeply; I've always
 worked hard to make sure all virtualization garbage is disabled on every
 machine I use.

Problem is that we need to disable dmar on the entire box, afaics. And I
assume that a bunch of people abusing desktop boards as servers will call
regression on that.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/14] update exynos drm driver.

[Dave Airlie]

On Wed, Nov 23, 2011 at 2:23 AM, InKi Dae daei...@gmail.com wrote:
 Hello, Dave.

 I had posted DRM Driver patchsets for Exsynos SoC but there is no any
 feedback. could you please review them? and if the patchsets have any
 problem, please give me your advice anytime. and also we are ready for
 next patchsets.

 the next patchsets include the followings:
 - fix some previous patchset bugs.
 - add power managerment featrue based on runtim-pm.

 from next patchset, I would request GIT PULL if you are ok.

I'm mainly trying to decide if they should go to Linus now or just go
into -next,

do you guys have a major preference one way or the other? later on
when the driver is more feature complete,
it would be good to send the fixes for the current tree separate to
new features.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Virtual CRTCs (proposal + experimental code)

[Dave Airlie]

 I would like to bring to the attention of dri-devel and linux-fbdev
 community a set of hopefully useful and interesting patches that
 I (and a few other colleagues) have been working on during the past
 few months. Here, I will provide a short abstract, so that you can
 decide whether this is of interest for you. At the end, I will
 provide the pointers to the code and documentation.

 The code is based on Dave Arilie's tree, drm-next branch and it
 allows a GPU driver to have an arbitrary number of CRTCs
 (configurable by user) instead of only those CRTCs that represent
 real hardware.

So another question I have is how you would intend this to work from a
user POV, like how it would integrate with a desktop environment, X or
wayland, i.e. with little or no configuration.

I still foresee problems with tiling, we generally don't encourage
accel code to live in the kernel, and you'll really want a
tiled-untiled blit for this thing, also for Intel GPUs where you have
UMA, would you read from the UMA.

It also doesn't solve the optimus GPU problem in any useful fashion,
since it can't deal with all the use cases, so we still have to write
an alternate solution that can deal with them, so we just end up with
two answers.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/14] update exynos drm driver.

[InKi Dae]

2011/11/23 Dave Airlie airl...@gmail.com:
 On Wed, Nov 23, 2011 at 2:23 AM, InKi Dae daei...@gmail.com wrote:
 Hello, Dave.

 I had posted DRM Driver patchsets for Exsynos SoC but there is no any
 feedback. could you please review them? and if the patchsets have any
 problem, please give me your advice anytime. and also we are ready for
 next patchsets.

 the next patchsets include the followings:
 - fix some previous patchset bugs.
 - add power managerment featrue based on runtim-pm.

 from next patchset, I would request GIT PULL if you are ok.

 I'm mainly trying to decide if they should go to Linus now or just go
 into -next,

 do you guys have a major preference one way or the other? later on
 when the driver is more feature complete,
 it would be good to send the fixes for the current tree separate to
 new features.

 Dave.


Hello, Dave.

the patchsets I sent before include only bug fixes so I think they
have no any new feature. and also now we are working another patchsets
for drm-next. they would include new features such as hdmi, iommu,
plane features. so I think it would be good to send the patchsets for
bug fix to drm-fixes. If you are ok, we'd like to start patch work as
two versions. one is based on drm-fixes for bug fix and another is
based on drm-next for new features. but we are ok whatever you decide.
so please give me your answer so that we can start next patch work.

thank you,
Inki Dae.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[David Woodhouse]

On Wed, 2011-11-23 at 11:26 +0100, Daniel Vetter wrote:
 On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
  On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett m...@redhat.com wrote:
  
   So the user has to choose between 5W of power saving or having dmar? And 
   we default to giving them dmar? I think that's going to come as a 
   surprise to people.
  
  You'd have to go into the BIOS to turn this on for most machines at
  least?
  
  But, yeah, it seems like we should be turning DMAR off unless explicitly
  requested; I can't understand how you'd ever need this running native on
  the hardware. Not exactly an area I care about deeply; I've always
  worked hard to make sure all virtualization garbage is disabled on every
  machine I use.
 
 Problem is that we need to disable dmar on the entire box, afaics. And I
 assume that a bunch of people abusing desktop boards as servers will call
 regression on that.

Hm, do you really have to disable it for the entire box, or just the
graphics?

Do we have a coherent erratum from Intel for the issues mentioned above
with DMAR+gfx+RC6?

Keith, do you know if a sighting has been filed and the hardware folks
are working on it?

Rajesh, are you familiar with this issue?

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Daniel Vetter]

On Wed, Nov 23, 2011 at 02:01:54PM +, David Woodhouse wrote:
 On Wed, 2011-11-23 at 11:26 +0100, Daniel Vetter wrote:
  On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
   On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett m...@redhat.com 
   wrote:
   
So the user has to choose between 5W of power saving or having dmar? 
And 
we default to giving them dmar? I think that's going to come as a 
surprise to people.
   
   You'd have to go into the BIOS to turn this on for most machines at
   least?
   
   But, yeah, it seems like we should be turning DMAR off unless explicitly
   requested; I can't understand how you'd ever need this running native on
   the hardware. Not exactly an area I care about deeply; I've always
   worked hard to make sure all virtualization garbage is disabled on every
   machine I use.
  
  Problem is that we need to disable dmar on the entire box, afaics. And I
  assume that a bunch of people abusing desktop boards as servers will call
  regression on that.
 
 Hm, do you really have to disable it for the entire box, or just the
 graphics?

At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
for the dmar+rc6 hangs reported.

 Do we have a coherent erratum from Intel for the issues mentioned above
 with DMAR+gfx+RC6?

Afaik no errata applies to our dmar related troubles on snb. I've hoped
that ppgtt would magically fix this, and it seems to help quite a bit for
the semaphore hangs (but not everywhere). Couldn't yet look more into
this.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[David Woodhouse]

On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
 At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
 dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
 for the dmar+rc6 hangs reported. 

Um... let me restate that for clarity (and partly for Rajesh's benefit).

The DMAR associated with the integrated graphics is *disabled*.
Turned off. Not active. Ever.

You have a problem when you enable the *other* DMAR units in the system,
which should not be affecting the graphics device in any way.

When you do this, you see 'hangs' with semaphores and RC6. Is there a
better description of these 'hangs' somewhere? Is the hardware
completely locked?

These hangs go away when you disable the DMAR units. Again, that is the
*other* DMAR units in the system that have nothing to do with graphics.

While I'm getting quite used to DMAR-related errata, this one does make
me stop and think 'wtf?'. It just seems so incongruous that disabling an
*unrelated* IOMMU would make the problem go away, and it makes me wonder
if it's actually a timing-related issue which is always there, but
something about the use of DMAR for network/disk/etc. makes it more
likely to trigger?

We definitely need the hardware folks to get to the bottom of this one.

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Daniel Vetter]

On Wed, Nov 23, 2011 at 03:03:43PM +, David Woodhouse wrote:
 On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
  At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
  dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
  for the dmar+rc6 hangs reported. 
 
 Um... let me restate that for clarity (and partly for Rajesh's benefit).
 
 The DMAR associated with the integrated graphics is *disabled*.
 Turned off. Not active. Ever.
 
 You have a problem when you enable the *other* DMAR units in the system,
 which should not be affecting the graphics device in any way.
 
 When you do this, you see 'hangs' with semaphores and RC6. Is there a
 better description of these 'hangs' somewhere? Is the hardware
 completely locked?
 
 These hangs go away when you disable the DMAR units. Again, that is the
 *other* DMAR units in the system that have nothing to do with graphics.
 
 While I'm getting quite used to DMAR-related errata, this one does make
 me stop and think 'wtf?'. It just seems so incongruous that disabling an
 *unrelated* IOMMU would make the problem go away, and it makes me wonder
 if it's actually a timing-related issue which is always there, but
 something about the use of DMAR for network/disk/etc. makes it more
 likely to trigger?
 
 We definitely need the hardware folks to get to the bottom of this one.

Ok, let me document the recipe I use to hang my box here. It's about the
dmar+semaphores hang I can reproduce, so might be slightly different in
the actual cause than the dmar+rc6 bug (for that one we only have bug
reports talking about hard freezing requiring power cycling).

- Grab a GT2+ mobile snb (both my and the only other reporters machine
  fits this, so maybe it matters). pci rev 09 (i.e. first production
  silicon).
- Install fc15 with the kde4 spin. I can't reproduce it with any other
  userspace than kde4.
- Grab latest d-i-f from Keith and latest userspace graphics code (to
  avoid hitting any other snb hangs we've tracked down meanwhile).
- Compile kernel with dmar and enable VT-d in the bios.
- Login into the systems with gdm, the machine usually dies within a few
  seconds (while kde4 loads). If that's not good enough, a few minutes of
  light desktop usage will kill it.
- Wait 2 minutes for the stuck-in-atomic detection logic to kick in and
  grab the backtrace over netconsole. Notice that the kernel is stuck
  trying to flush the dmar tlb cache (that's how I managed to track it
  down to a dmar interaction). Backtrace almost identical to the dmar
  issue on ilk. I've lost the backtrace, if you want I can regrab it.

Things I've tried that don't work around the issue:
- Disable dmar for the igfx with intel_iommu=igfx_off
- Apply the ilk workaround (i.e. synchronous dmar tlb flushes + gpu idling
  while flushing).

Things that work:
- Disabling semaphores.
- Disabling dmar in either the bios or on the cmdline with intel_iommu=off

All reporters that tried confirmed that igfx_off is not good enough, only
fully disabling dmar (for both the semaphores and the rc6 related hangs).

Things that look interesting:
- ppgtt support (i.e. using per-proces pagetables on the gfx instead of
  the global gtt) seems to paper over the issue for the original reporter
  of the semaphore related hangs.  Unfortunately not for me, gpu still
  hangs (but doesn't take down the entire system with it). I've not yet
  investigated this one closely. Fyi, the windows driver uses ppgtt
  unconditionally on snb. Also, ppgtt seems to have no effect for at least
  one report of dmar related rc6 hangs.

Cheers, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[David Woodhouse]

On Wed, 2011-11-23 at 16:31 +0100, Daniel Vetter wrote:
 
 Things I've tried that don't work around the issue:
 - Disable dmar for the igfx with intel_iommu=igfx_off
 - Apply the ilk workaround (i.e. synchronous dmar tlb flushes + gpu
 idling while flushing).

Well, the ILK workaround was only ensuring that the gfx was idle while
the *graphics* IOTLB was flushed. We are still flushing the IOTLB for
*other* IOMMUs at arbitrary times. 

Might be interesting to go for *deferred* IOTLB flushes (i.e. the normal
mode without the workaround or 'intel_iommu=strict' on the command
line), *BUT* to make sure the batched flush (the flush_unmaps() call)
can *only* happen when the GPU is quiescent. You could do that with a
dirty hack for testing, and if *that* fixes the issue well, $DEITY
knows, someone still needs a good kicking, but at least we'll have
learned something :)
 
-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Daniel Vetter]

On Wed, Nov 23, 2011 at 03:03:43PM +, David Woodhouse wrote:
 On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
  At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
  dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
  for the dmar+rc6 hangs reported. 
 
 Um... let me restate that for clarity (and partly for Rajesh's benefit).
 
 The DMAR associated with the integrated graphics is *disabled*.
 Turned off. Not active. Ever.

Hm, that comment confuses me a bit. I've always thought that igfx_off only
instantiates a identity mapping and leaves the dmar unit on. Is that
wrong?
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[David Woodhouse]

On Wed, 2011-11-23 at 16:41 +0100, Daniel Vetter wrote:
 Hm, that comment confuses me a bit. I've always thought that igfx_off only
 instantiates a identity mapping and leaves the dmar unit on. Is that
 wrong? 

It's completely off. If a DMAR unit has *only* graphics devices behind
it (as the one for the built-in graphics does, because it's a whole
boatload of speshul case for integration with the GTT), we just don't
enable it at all. See the second for_each_drhd_unit() loop in
init_no_remapping_devices().

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

[Markus Trippelsdorf]

On 2011.11.21 at 16:36 +0100, Markus Trippelsdorf wrote:
 On 2011.11.21 at 15:16 +0100, Eric Dumazet wrote:
  Le lundi 21 novembre 2011 à 14:15 +0100, Markus Trippelsdorf a écrit :
  
   I've enabled CONFIG_SLUB_DEBUG_ON and this is what happend:
   
  
  Thanks
  
  Please continue to provide more samples.
  
  There is something wrong somewhere, but where exactly, its hard to say.
 
 New sample. This one points to lib/idr.c:
 
 [drm] Initialized drm 1.1.0 20060810
 [drm] radeon defaulting to kernel modesetting.
 [drm] radeon kernel modesetting enabled.
 radeon :01:05.0: PCI INT A - GSI 18 (level, low) - IRQ 18
 radeon :01:05.0: setting latency timer to 64
 [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
 [drm] register mmio base: 0xFBEE
 [drm] register mmio size: 65536
 ATOM BIOS: 113
 radeon :01:05.0: VRAM: 128M 0xC000 - 0xC7FF (128M 
 used)
 radeon :01:05.0: GTT: 512M 0xA000 - 0xBFFF
 [drm] Detected VRAM RAM=128M, BAR=128M
 [drm] RAM width 32bits DDR
 [TTM] Zone  kernel: Available graphics memory: 4083428 kiB.
 [TTM] Zone   dma32: Available graphics memory: 2097152 kiB.
 [TTM] Initializing pool allocator.
 [drm] radeon: 128M of VRAM memory ready
 [drm] radeon: 512M of GTT memory ready.
 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
 [drm] Driver supports precise vblank timestamp query.
 [drm] radeon: irq initialized.
 [drm] GART: num cpu pages 131072, num gpu pages 131072
 [drm] Loading RS780 Microcode
 [drm] PCIE GART of 512M enabled (table at 0xC004).
 radeon :01:05.0: WB enabled
 [drm] ring test succeeded in 1 usecs
 [drm] radeon: ib pool ready.
 [drm] ib test succeeded in 0 usecs
 =
 BUG idr_layer_cache: Poison overwritten
 -
 
 INFO: 0x880215650800-0x880215650803. First byte 0x0 instead of 0x6b
 INFO: Slab 0xea0008559400 objects=18 used=18 fp=0x  (null) 
 flags=0x40004080
 INFO: Object 0x8802156506d0 @offset=1744 fp=0x880215650a38
 
 Bytes b4 8802156506c0: a4 6f fb ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a  
 .o..
 Object 8802156506d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 8802156506e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 8802156506f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650700: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650710: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650720: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650730: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650740: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650750: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650760: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650770: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650780: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650790: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 8802156507a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 8802156507b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 8802156507c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 8802156507d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 8802156507e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 8802156507f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650820: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650830: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650840: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650850: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650860: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650870: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650880: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215650890: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 

[PATCH] iommu: export no_iommu and dmar_disabled symbols

[Eugeni Dodonov]

Those are needed by the rc6 and semaphores support in i915 driver.

In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
is enabled. So we use those variables to check the io remapping and iommu
status.

CC: Keith Packard kei...@keithp.com
CC: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
 arch/x86/kernel/pci-dma.c   |1 +
 drivers/iommu/intel-iommu.c |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index 80dc793..4c9191e 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -33,6 +33,7 @@ int force_iommu __read_mostly = 0;
 int iommu_merge __read_mostly = 0;
 
 int no_iommu __read_mostly;
+EXPORT_SYMBOL_GPL(no_iommu);
 /* Set this to 1 if there is a HW IOMMU in the system */
 int iommu_detected __read_mostly = 0;
 
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index c0c7820..dfe5fd3 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -404,6 +404,7 @@ int dmar_disabled = 0;
 #else
 int dmar_disabled = 1;
 #endif /*CONFIG_INTEL_IOMMU_DEFAULT_ON*/
+EXPORT_SYMBOL_GPL(dmar_disabled);
 
 static int dmar_map_gfx = 1;
 static int dmar_forcedac;
-- 
1.7.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver

[Keith Packard]

On Wed, 23 Nov 2011 16:29:58 +0800, Wu Fengguang fengguang...@intel.com wrote:

 What I need is a hot plug hook that knows whether the monitor is
 plugged or removed, which is only possible if the hook is called
 after -detect().

That would be mode_set to tell you that the monitor is in use, and the
disable function to tell you when the monitor is no longer in use.

You do not want to do anything to the hardware in the hot_plug paths;
those are strictly informative; telling user space which connectors are
present.

-- 
keith.pack...@intel.com


pgpOxnjFD8SfE.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

[Daniel Vetter]

On Wed, Nov 23, 2011 at 03:43:05PM +, David Woodhouse wrote:
 On Wed, 2011-11-23 at 16:41 +0100, Daniel Vetter wrote:
  Hm, that comment confuses me a bit. I've always thought that igfx_off only
  instantiates a identity mapping and leaves the dmar unit on. Is that
  wrong? 
 
 It's completely off. If a DMAR unit has *only* graphics devices behind
 it (as the one for the built-in graphics does, because it's a whole
 boatload of speshul case for integration with the GTT), we just don't
 enable it at all. See the second for_each_drhd_unit() loop in
 init_no_remapping_devices().

That explanation confused me even more. So I've rechecked with
intel_iommu=igfx_off and already thought I've made a decent fool of
myself because I couldn't readily hang it. Turns out it's just much harder
to hang with that. So I think moving around the tlb flushing for other
dmar nodes to align with the idled igfx isn't a great solution, simply
because I can't reliably tell whether it fixes anything.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] iommu: export no_iommu and dmar_disabled symbols

[David Woodhouse]

On Wed, 2011-11-23 at 16:42 -0200, Eugeni Dodonov wrote:
 Those are needed by the rc6 and semaphores support in i915 driver.
 
 In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
 is enabled. So we use those variables to check the io remapping and iommu
 status.

This is horrid. In the general case, drivers have no business knowing
this. We need to properly identify what is wrong with this hardware, and
put in a quirk for it — perhaps refusing to enable the IOMMU at all on
the broken chipsets.

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] iommu: export no_iommu and dmar_disabled symbols

[Keith Packard]

On Wed, 23 Nov 2011 20:36:00 +, David Woodhouse dw...@infradead.org wrote:

 This is horrid. In the general case, drivers have no business knowing
 this. We need to properly identify what is wrong with this hardware, and
 put in a quirk for it — perhaps refusing to enable the IOMMU at all on
 the broken chipsets.

That'd be fine with me, right now we're disabling RC6 and semaphores --
semaphores aren't all that important, although they do improve
performance a bit. RC6 is important, saving a huge amount of power.

I'd also be OK with requiring special options to enable DMAR and having
that also disable RC6/semaphores, if you'd rather expose that. In either
case, we need something that works and avoids hanging machines.

-- 
keith.pack...@intel.com


pgpxTRscEyNin.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/kms: Use the standard VESA timeout for DDC channels

[Keith Packard]

On Fri, 21 Oct 2011 09:10:12 +0200, Jean Delvare jdelv...@suse.de wrote:

 - /* vesa says 2.2 ms is enough, 1 jiffy doesn't seem to always
 -  * make this, 2 jiffies is a lot more reliable */
 - i2c-algo.bit.timeout = 2;
 + i2c-algo.bit.timeout = usecs_to_jiffies(2200); /* from VESA */

From my reading of the usecs_to_jiffies code, it always returns a time
at least as long as requested, so this will ensure that you're waiting
at least 2.2ms, unlike 2 jiffies which is some random amount of time
depending on the HZ setting in the kernel.

Reviewed-by: Keith Packard kei...@keithp.com

-- 
keith.pack...@intel.com


pgpY1RP4t0c3h.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

[Christoph Lameter]

On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:

  FIX idr_layer_cache: Marking all objects used

 Yesterday I couldn't reproduce the issue at all. But today I've hit
 exactly the same spot again. (CCing the drm list)

Well this is looks like write after free.

 =
 BUG idr_layer_cache: Poison overwritten
 -
 Object 8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 
 Object 880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
 

And its an integer sized write of 0. If you look at the struct definition
and lookup the offset you should be able to locate the field that
was modified.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel