Re: [WHY SUCH DELAY!] Touch Bar support for T2 Macs
On Fri, 27 Sep 2024, Dave Airlie wrote: > > > It has been more than a month since I've sent this patch set and I > > > haven't got a clear yes or not for the same. I understand maintainers > > > are busy people, but I'd really appreciate if I get some response for > > > this series of patches from the HID and DRM maintainers. > > > > Just to reiterate -- I am waiting for Ack from the DRM people and will > > then take it through hid.git. > > > > Dave, who'd be the best person to do this from the DRM side please? > > > > I think Thomas or Maxime could take a look, though it might be easier > to submit this in pieces, does it really need to all go in at once? I'm fine either way, once DRM folks either give their Ack, or express their desire to separate it out, I'll follow :) Thanks, -- Jiri Kosina SUSE Labs
Re: [WHY SUCH DELAY!] Touch Bar support for T2 Macs
On Thu, 26 Sep 2024, Aditya Garg wrote: > It has been more than a month since I've sent this patch set and I > haven't got a clear yes or not for the same. I understand maintainers > are busy people, but I'd really appreciate if I get some response for > this series of patches from the HID and DRM maintainers. Just to reiterate -- I am waiting for Ack from the DRM people and will then take it through hid.git. Dave, who'd be the best person to do this from the DRM side please? Thanks, -- Jiri Kosina SUSE Labs
Re: [WHY SUCH DELAY!] Touch Bar support for T2 Macs
On Thu, 26 Sep 2024, Aditya Garg wrote: > >> It has been more than a month since I've sent this patch set and I > >> haven't got a clear yes or not for the same. I understand maintainers > >> are busy people, but I'd really appreciate if I get some response for > >> this series of patches from the HID and DRM maintainers. > > > > Just to reiterate -- I am waiting for Ack from the DRM people and will > > then take it through hid.git. > > So I should assume the HID portion is fit to be merged now? hid-appletb-* I have gone through, and it looks all good to me. Benjamin, could you please explicitly provide your Ack for the multitouch changes? -- Jiri Kosina SUSE Labs
Re: [PATCH v5 0/10] Touch Bar support for T2 Macs
On Sat, 31 Aug 2024, Aditya Garg wrote: > Hi Maintainers > > It has been 2 weeks but I still haven't received a single reply on this > version of the patch series. Consider this email as a friendly reminder. I think it makes most sense to take this whole set through hid.git, but for that, I'd like to get Acked-by/Reviewed-by for patches 9 and 10 (drm bits). Dave, Daniel, .. ? Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH v4 0/2] Add Add elan-ekth6a12nay on the basis of elan-ekth6915
On Thu, 22 Aug 2024, Jiri Kosina wrote: > > Jiri / Ben, > [ ... snip ... ] > > I think this series is ready for you to merge at your leisure. If > > there's anything blocking it then please yell. Thanks! :-) > > Hmm, for some reason the only mentions of this series in my inbox are your > Reviewed-by: from Jun 10th, but nothing else whatsoever. Seems like some > spam filter really didn't like it. > > I will pick it up. Now in hid.git#for-6.12/elan. Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH v4 0/2] Add Add elan-ekth6a12nay on the basis of elan-ekth6915
On Thu, 22 Aug 2024, Doug Anderson wrote: > Jiri / Ben, [ ... snip ... ] > I think this series is ready for you to merge at your leisure. If > there's anything blocking it then please yell. Thanks! :-) Hmm, for some reason the only mentions of this series in my inbox are your Reviewed-by: from Jun 10th, but nothing else whatsoever. Seems like some spam filter really didn't like it. I will pick it up. -- Jiri Kosina SUSE Labs
Re: [PATCH 25/28] HID: picoLCD: Replace check_fb in favor of struct fb_info.lcd_dev
On Tue, 20 Aug 2024, Thomas Zimmermann wrote: > Store the lcd device in struct fb_info.lcd_dev. The lcd subsystem can > now detect the lcd's fbdev device from this field. > > This makes the implementation of check_fb in picolcd_lcdops obsolete. > Remove it. > > Signed-off-by: Thomas Zimmermann Acked-by: Jiri Kosina -- Jiri Kosina SUSE Labs
Re: [PATCH 11/32] hid/picolcd_fb: Set FBINFO_VIRTFB flag
On Wed, 15 Nov 2023, Thomas Zimmermann wrote: > The picolcd_fb driver operates on system memory. Mark the framebuffer > accordingly. Helpers operating on the framebuffer memory will test > for the presence of this flag. > > Signed-off-by: Thomas Zimmermann > Cc: "Bruno Prémont" > Cc: Jiri Kosina > Cc: Benjamin Tissoires > Cc: linux-in...@vger.kernel.org Acked-by: Jiri Kosina I guess this will go in as one series together, right? -- Jiri Kosina SUSE Labs
Re: [PATCH] drm: fb-helper: Avoid nesting spinlock_t into raw_spinlock_t
On Tue, 15 Feb 2022, John Ogness wrote: > >> drm_fb_helper_damage() is acquiring spinlock_t (helper->damage_lock), > >> while it can be called from contexts where raw_spinlock_t is held (e.g. > >> console_owner lock obtained on vprintk_emit() codepath). > >> > >> As the critical sections protected by damage_lock are super-tiny, let's > >> fix this by converting it to raw_spinlock_t in order not to violate > >> PREEMPT_RT-imposed lock nesting rules. > >> > >> This fixes the splat below. > >> > >> = > >> [ BUG: Invalid wait context ] > >> 5.17.0-rc4-2-gd567f5db412e #1 Not tainted > > > > rc4. Is this also the case in the RT tree which includes John's printk > > changes? > > In the RT tree, the fbcon's write() callback is only called in > preemptible() contexts. So this is only a mainline issue. > > The series I recently posted to LKML [0] should also address this issue > (if/when it gets accepted). > > John > > [0] > https://lore.kernel.org/lkml/20220207194323.273637-1-john.ogn...@linutronix.de Thanks for confirmation, seems like this problem is indeed cured by your series. I still believe though that we shouldn't let 5.17 released with this warning being emitted into dmesg, so I'd suggest going with my patch for mainline, and revert it in your series on top of it. Thanks, -- Jiri Kosina SUSE Labs
[PATCH] drm: fb-helper: Avoid nesting spinlock_t into raw_spinlock_t
From: Jiri Kosina
drm_fb_helper_damage() is acquiring spinlock_t (helper->damage_lock),
while it can be called from contexts where raw_spinlock_t is held (e.g.
console_owner lock obtained on vprintk_emit() codepath).
As the critical sections protected by damage_lock are super-tiny, let's
fix this by converting it to raw_spinlock_t in order not to violate
PREEMPT_RT-imposed lock nesting rules.
This fixes the splat below.
=
[ BUG: Invalid wait context ]
5.17.0-rc4-2-gd567f5db412e #1 Not tainted
-
swapper/0/0 is trying to lock:
8c5687cc4158 (&helper->damage_lock){}-{3:3}, at:
drm_fb_helper_damage.isra.22+0x4a/0xf0
other info that might help us debug this:
context-{2:2}
3 locks held by swapper/0/0:
#0: ad776520 (console_lock){+.+.}-{0:0}, at: vprintk_emit+0xb8/0x2a0
#1: ad696120 (console_owner){-...}-{0:0}, at:
console_unlock+0x17f/0x550
#2: ad926a58 (printing_lock){}-{3:3}, at:
vt_console_print+0x7d/0x3e0
stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-rc4-2-gd567f5db412e #1
bed1d5e19e0e7e8c9d97fd8afa1322f7f47a4f38
Hardware name: LENOVO 20UJS2B905/20UJS2B905, BIOS R1CET63W(1.32 ) 04/09/2021
Call Trace:
dump_stack_lvl+0x58/0x71
__lock_acquire+0x165b/0x1780
? secondary_startup_64_no_verify+0xd5/0xdb
lock_acquire+0x278/0x300
? drm_fb_helper_damage.isra.22+0x4a/0xf0
? save_trace+0x3e/0x340
? __bfs+0x10f/0x240
_raw_spin_lock_irqsave+0x48/0x60
? drm_fb_helper_damage.isra.22+0x4a/0xf0
drm_fb_helper_damage.isra.22+0x4a/0xf0
soft_cursor+0x194/0x240
bit_cursor+0x386/0x630
? get_color+0x29/0x120
? bit_putcs+0x4b0/0x4b0
? console_unlock+0x17f/0x550
hide_cursor+0x2f/0x90
vt_console_print+0x3c5/0x3e0
? console_unlock+0x17f/0x550
console_unlock+0x515/0x550
vprintk_emit+0x1c8/0x2a0
_printk+0x52/0x6e
? sched_clock_tick+0x3d/0x60
collect_cpu_info_amd+0x93/0xd0
collect_cpu_info_local+0x23/0x30
flush_smp_call_function_queue+0x137/0x220
__sysvec_call_function_single+0x43/0x1c0
sysvec_call_function_single+0x43/0x80
asm_sysvec_call_function_single+0x12/0x20
RIP: 0010:cpuidle_enter_state+0x111/0x4b0
Code: 7c ff 45 84 ff 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 71 03 00 00 31
ff e8 bb 21 86 ff e8 76 2f 8e ff fb 66 0f 1f 44 00 00 <45> 85 f6 0f 88 12 01 00
00 49 63 d6 4c 2b 24 24 48 8d 04 52 48 8d
RSP: 0018:ad603e48 EFLAGS: 0206
RAX: 000127c3 RBX: 0003 RCX:
RDX: RSI: RDI: ac32617a
RBP: 8c5687ba4400 R08: 0001 R09: 0001
R10: ad603e10 R11: R12: 685eb4a0
R13: ad918f80 R14: 0003 R15:
? cpuidle_enter_state+0x10a/0x4b0
? cpuidle_enter_state+0x10a/0x4b0
cpuidle_enter+0x29/0x40
do_idle+0x24d/0x2c0
cpu_startup_entry+0x19/0x20
start_kernel+0x9c2/0x9e9
secondary_startup_64_no_verify+0xd5/0xdb
Signed-off-by: Jiri Kosina
---
drivers/gpu/drm/drm_fb_helper.c | 14 +++---
include/drm/drm_fb_helper.h | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index ed43b987d306..7c4ab6e6f865 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -436,11 +436,11 @@ static void drm_fb_helper_damage_work(struct work_struct
*work)
unsigned long flags;
int ret;
- spin_lock_irqsave(&helper->damage_lock, flags);
+ raw_spin_lock_irqsave(&helper->damage_lock, flags);
clip_copy = *clip;
clip->x1 = clip->y1 = ~0;
clip->x2 = clip->y2 = 0;
- spin_unlock_irqrestore(&helper->damage_lock, flags);
+ raw_spin_unlock_irqrestore(&helper->damage_lock, flags);
/* Call damage handlers only if necessary */
if (!(clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2))
@@ -465,12 +465,12 @@ static void drm_fb_helper_damage_work(struct work_struct
*work)
* Restore damage clip rectangle on errors. The next run
* of the damage worker will perform the update.
*/
- spin_lock_irqsave(&helper->damage_lock, flags);
+ raw_spin_lock_irqsave(&helper->damage_lock, flags);
clip->x1 = min_t(u32, clip->x1, clip_copy.x1);
clip->y1 = min_t(u32, clip->y1, clip_copy.y1);
clip->x2 = max_t(u32, clip->x2, clip_copy.x2);
clip->y2 = max_t(u32, clip->y2, clip_copy.y2);
- spin_unlock_irqrestore(&helper->damage_lock, flags);
+ raw_spin_unlock_irqrestore(&helper->damage_lock, flags);
}
/**
@@ -486,7 +486,7 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct
drm_fb_helper *helper,
const struct drm_fb_helper_funcs *func
Re: [PATCH v2 55/63] HID: roccat: Use struct_group() to zero kone_mouse_event
On Fri, 20 Aug 2021, Kees Cook wrote: > > > > > In preparation for FORTIFY_SOURCE performing compile-time and run-time > > > > > field bounds checking for memset(), avoid intentionally writing across > > > > > neighboring fields. > > > > > > > > > > Add struct_group() to mark region of struct kone_mouse_event that > > > > > should > > > > > be initialized to zero. > > > > > > > > > > Cc: Stefan Achatz > > > > > Cc: Jiri Kosina > > > > > Cc: Benjamin Tissoires > > > > > Cc: linux-in...@vger.kernel.org > > > > > Signed-off-by: Kees Cook > > > > > > > > Applied, thank you Kees. > > > > > > > > > > Eek! No, this will break the build: struct_group() is not yet in the tree. > > > I can carry this with an Ack, etc. > > > > I was pretty sure I saw struct_group() already in linux-next, but that was > > apparently a vacation-induced brainfart, sorry. Dropping. > > Oh, for these two patches, can I add your Acked-by while I carry them? Yes, thanks, and sorry for the noise. -- Jiri Kosina SUSE Labs
Re: [PATCH v2 55/63] HID: roccat: Use struct_group() to zero kone_mouse_event
On Fri, 20 Aug 2021, Kees Cook wrote: > > > In preparation for FORTIFY_SOURCE performing compile-time and run-time > > > field bounds checking for memset(), avoid intentionally writing across > > > neighboring fields. > > > > > > Add struct_group() to mark region of struct kone_mouse_event that should > > > be initialized to zero. > > > > > > Cc: Stefan Achatz > > > Cc: Jiri Kosina > > > Cc: Benjamin Tissoires > > > Cc: linux-in...@vger.kernel.org > > > Signed-off-by: Kees Cook > > > > Applied, thank you Kees. > > > > Eek! No, this will break the build: struct_group() is not yet in the tree. > I can carry this with an Ack, etc. I was pretty sure I saw struct_group() already in linux-next, but that was apparently a vacation-induced brainfart, sorry. Dropping. -- Jiri Kosina SUSE Labs
Re: [PATCH v2 55/63] HID: roccat: Use struct_group() to zero kone_mouse_event
On Tue, 17 Aug 2021, Kees Cook wrote: > In preparation for FORTIFY_SOURCE performing compile-time and run-time > field bounds checking for memset(), avoid intentionally writing across > neighboring fields. > > Add struct_group() to mark region of struct kone_mouse_event that should > be initialized to zero. > > Cc: Stefan Achatz > Cc: Jiri Kosina > Cc: Benjamin Tissoires > Cc: linux-in...@vger.kernel.org > Signed-off-by: Kees Cook Applied, thank you Kees. -- Jiri Kosina SUSE Labs
Re: [PATCH v2 22/63] HID: cp2112: Use struct_group() for memcpy() region
On Tue, 17 Aug 2021, Kees Cook wrote: > In preparation for FORTIFY_SOURCE performing compile-time and run-time > field bounds checking for memcpy(), memmove(), and memset(), avoid > intentionally writing across neighboring fields. > > Use struct_group() in struct cp2112_string_report around members report, > length, type, and string, so they can be referenced together. This will > allow memcpy() and sizeof() to more easily reason about sizes, improve > readability, and avoid future warnings about writing beyond the end of > report. > > "pahole" shows no size nor member offset changes to struct > cp2112_string_report. "objdump -d" shows no meaningful object > code changes (i.e. only source line number induced differences.) > > Cc: Jiri Kosina > Cc: Benjamin Tissoires > Cc: linux-in...@vger.kernel.org > Signed-off-by: Kees Cook Applied, thanks. -- Jiri Kosina SUSE Labs
Re: [PATCH v2] drm/amdgpu: Avoid printing of stack contents on firmware load error
On Thu, 24 Jun 2021, Jiri Kosina wrote:
> From: Jiri Kosina
>
> In case when psp_init_asd_microcode() fails to load ASD microcode file,
> psp_v12_0_init_microcode() tries to print the firmware filename that
> failed to load before bailing out.
>
> This is wrong because:
>
> - the firmware filename it would want it print is an incorrect one as
> psp_init_asd_microcode() and psp_v12_0_init_microcode() are loading
> different filenames
> - it tries to print fw_name, but that's not yet been initialized by that
> time, so it prints random stack contents, e.g.
>
> amdgpu :04:00.0: Direct firmware load for amdgpu/renoir_asd.bin
> failed with error -2
> amdgpu :04:00.0: amdgpu: fail to initialize asd microcode
> amdgpu :04:00.0: amdgpu: psp v12.0: Failed to load firmware
> "\xfeTO\x8e\xff\xff"
>
> Fix that by bailing out immediately, instead of priting the bogus error
> message.
Friendly ping on this one too; priting a few bytes of stack is not a
*huge* info leak, but I believe it should be fixed nevertheless.
Thanks.
>
> Reported-by: Vojtech Pavlik
> Signed-off-by: Jiri Kosina
> ---
>
> v1 -> v2: remove now-unused label
>
> drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
> b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
> index c4828bd3264b..b0ee77ee80b9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
> @@ -67,7 +67,7 @@ static int psp_v12_0_init_microcode(struct psp_context *psp)
>
> err = psp_init_asd_microcode(psp, chip_name);
> if (err)
> - goto out;
> + return err;
>
> snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_ta.bin", chip_name);
> err = request_firmware(&adev->psp.ta_fw, fw_name, adev->dev);
> @@ -80,7 +80,7 @@ static int psp_v12_0_init_microcode(struct psp_context *psp)
> } else {
> err = amdgpu_ucode_validate(adev->psp.ta_fw);
> if (err)
> - goto out2;
> + goto out;
>
> ta_hdr = (const struct ta_firmware_header_v1_0 *)
>adev->psp.ta_fw->data;
> @@ -105,10 +105,9 @@ static int psp_v12_0_init_microcode(struct psp_context
> *psp)
>
> return 0;
>
> -out2:
> +out:
> release_firmware(adev->psp.ta_fw);
> adev->psp.ta_fw = NULL;
> -out:
> if (err) {
> dev_err(adev->dev,
> "psp v12.0: Failed to load firmware \"%s\"\n",
> --
> 2.12.3
>
--
Jiri Kosina
SUSE Labs
Re: [PATCH] drm/amdgpu: Fix resource leak on probe error path
On Thu, 24 Jun 2021, Jiri Kosina wrote:
> From: Jiri Kosina
>
> This reverts commit 4192f7b5768912ceda82be2f83c87ea7181f9980.
>
> It is not true (as stated in the reverted commit changelog) that we never
> unmap the BAR on failure; it actually does happen properly on
> amdgpu_driver_load_kms() -> amdgpu_driver_unload_kms() ->
> amdgpu_device_fini() error path.
>
> What's worse, this commit actually completely breaks resource freeing on
> probe failure (like e.g. failure to load microcode), as
> amdgpu_driver_unload_kms() notices adev->rmmio being NULL and bails too
> early, leaving all the resources that'd normally be freed in
> amdgpu_acpi_fini() and amdgpu_device_fini() still hanging around, leading
> to all sorts of oopses when someone tries to, for example, access the
> sysfs and procfs resources which are still around while the driver is
> gone.
>
> Fixes: 4192f7b57689 ("drm/amdgpu: unmap register bar on device init failure")
> Reported-by: Vojtech Pavlik
> Signed-off-by: Jiri Kosina
Friendly ping on this one (as it's easily triggerable in the wild by just
missing proper firwmare).
Thanks.
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 57ec108b5972..0f1c0e17a587 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3414,13 +3414,13 @@ int amdgpu_device_init(struct amdgpu_device *adev,
> r = amdgpu_device_get_job_timeout_settings(adev);
> if (r) {
> dev_err(adev->dev, "invalid lockup_timeout parameter syntax\n");
> - goto failed_unmap;
> + return r;
> }
>
> /* early init functions */
> r = amdgpu_device_ip_early_init(adev);
> if (r)
> - goto failed_unmap;
> + return r;
>
> /* doorbell bar mapping and doorbell index init*/
> amdgpu_device_doorbell_init(adev);
> @@ -3646,10 +3646,6 @@ int amdgpu_device_init(struct amdgpu_device *adev,
> failed:
> amdgpu_vf_error_trans_all(adev);
>
> -failed_unmap:
> - iounmap(adev->rmmio);
> - adev->rmmio = NULL;
> -
> return r;
> }
>
> --
> 2.12.3
>
>
--
Jiri Kosina
SUSE Labs
[PATCH] drm/amdgpu: Fix resource leak on probe error path
From: Jiri Kosina
This reverts commit 4192f7b5768912ceda82be2f83c87ea7181f9980.
It is not true (as stated in the reverted commit changelog) that we never
unmap the BAR on failure; it actually does happen properly on
amdgpu_driver_load_kms() -> amdgpu_driver_unload_kms() ->
amdgpu_device_fini() error path.
What's worse, this commit actually completely breaks resource freeing on
probe failure (like e.g. failure to load microcode), as
amdgpu_driver_unload_kms() notices adev->rmmio being NULL and bails too
early, leaving all the resources that'd normally be freed in
amdgpu_acpi_fini() and amdgpu_device_fini() still hanging around, leading
to all sorts of oopses when someone tries to, for example, access the
sysfs and procfs resources which are still around while the driver is
gone.
Fixes: 4192f7b57689 ("drm/amdgpu: unmap register bar on device init failure")
Reported-by: Vojtech Pavlik
Signed-off-by: Jiri Kosina
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 57ec108b5972..0f1c0e17a587 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3414,13 +3414,13 @@ int amdgpu_device_init(struct amdgpu_device *adev,
r = amdgpu_device_get_job_timeout_settings(adev);
if (r) {
dev_err(adev->dev, "invalid lockup_timeout parameter syntax\n");
- goto failed_unmap;
+ return r;
}
/* early init functions */
r = amdgpu_device_ip_early_init(adev);
if (r)
- goto failed_unmap;
+ return r;
/* doorbell bar mapping and doorbell index init*/
amdgpu_device_doorbell_init(adev);
@@ -3646,10 +3646,6 @@ int amdgpu_device_init(struct amdgpu_device *adev,
failed:
amdgpu_vf_error_trans_all(adev);
-failed_unmap:
- iounmap(adev->rmmio);
- adev->rmmio = NULL;
-
return r;
}
--
2.12.3
[PATCH v2] drm/amdgpu: Avoid printing of stack contents on firmware load error
From: Jiri Kosina
In case when psp_init_asd_microcode() fails to load ASD microcode file,
psp_v12_0_init_microcode() tries to print the firmware filename that
failed to load before bailing out.
This is wrong because:
- the firmware filename it would want it print is an incorrect one as
psp_init_asd_microcode() and psp_v12_0_init_microcode() are loading
different filenames
- it tries to print fw_name, but that's not yet been initialized by that
time, so it prints random stack contents, e.g.
amdgpu :04:00.0: Direct firmware load for amdgpu/renoir_asd.bin failed
with error -2
amdgpu :04:00.0: amdgpu: fail to initialize asd microcode
amdgpu :04:00.0: amdgpu: psp v12.0: Failed to load firmware
"\xfeTO\x8e\xff\xff"
Fix that by bailing out immediately, instead of priting the bogus error
message.
Reported-by: Vojtech Pavlik
Signed-off-by: Jiri Kosina
---
v1 -> v2: remove now-unused label
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
index c4828bd3264b..b0ee77ee80b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
@@ -67,7 +67,7 @@ static int psp_v12_0_init_microcode(struct psp_context *psp)
err = psp_init_asd_microcode(psp, chip_name);
if (err)
- goto out;
+ return err;
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_ta.bin", chip_name);
err = request_firmware(&adev->psp.ta_fw, fw_name, adev->dev);
@@ -80,7 +80,7 @@ static int psp_v12_0_init_microcode(struct psp_context *psp)
} else {
err = amdgpu_ucode_validate(adev->psp.ta_fw);
if (err)
- goto out2;
+ goto out;
ta_hdr = (const struct ta_firmware_header_v1_0 *)
adev->psp.ta_fw->data;
@@ -105,10 +105,9 @@ static int psp_v12_0_init_microcode(struct psp_context
*psp)
return 0;
-out2:
+out:
release_firmware(adev->psp.ta_fw);
adev->psp.ta_fw = NULL;
-out:
if (err) {
dev_err(adev->dev,
"psp v12.0: Failed to load firmware \"%s\"\n",
--
2.12.3
[PATCH] drm/amdgpu: Avoid printing of stack contents on firmware load error
From: Jiri Kosina In case when psp_init_asd_microcode() fails to load ASD microcode file, psp_v12_0_init_microcode() tries to print the firmware filename that failed to load before bailing out. This is wrong because: - the firmware filename it would want it print is an incorrect one as psp_init_asd_microcode() and psp_v12_0_init_microcode() are loading different filenames - it tries to print fw_name, but that's not yet been initialized by that time, so it prints random stack contents, e.g. amdgpu :04:00.0: Direct firmware load for amdgpu/renoir_asd.bin failed with error -2 amdgpu :04:00.0: amdgpu: fail to initialize asd microcode amdgpu :04:00.0: amdgpu: psp v12.0: Failed to load firmware "\xfeTO\x8e\xff\xff" Fix that by bailing out immediately, instead of priting the bogus error message. Reported-by: Vojtech Pavlik Signed-off-by: Jiri Kosina --- drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c index c4828bd3264b..5b21e22ad4b9 100644 --- a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c +++ b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c @@ -67,7 +67,7 @@ static int psp_v12_0_init_microcode(struct psp_context *psp) err = psp_init_asd_microcode(psp, chip_name); if (err) - goto out; + return err; snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_ta.bin", chip_name); err = request_firmware(&adev->psp.ta_fw, fw_name, adev->dev); -- 2.12.3 -- Jiri Kosina SUSE Labs
Re: [PATCH] Revert "drm/dp_mst: Remove VCPI while disabling topology mgr"
ck+0xc3/0x498
> [ 54.397362] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
> [ 54.403492] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
> [ 54.409620] ? drm_dp_dpcd_access+0xd9/0x101
> [ 54.414390] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
> [ 54.420517] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
> [ 54.426645] ? intel_digital_port_connected+0x34d/0x35c
> [ 54.432482] ? intel_dp_detect+0x227/0x44e
> [ 54.437056] ? ww_mutex_lock+0x49/0x9a
> [ 54.441242] ? drm_helper_probe_detect_ctx+0x75/0xfd
> [ 54.446789] ? intel_encoder_hotplug+0x4b/0x97
> [ 54.451752] ? intel_ddi_hotplug+0x61/0x2e0
> [ 54.456423] ? mark_held_locks+0x53/0x68
> [ 54.460803] ? _raw_spin_unlock_irqrestore+0x3a/0x51
> [ 54.466347] ? lockdep_hardirqs_on+0x187/0x1a4
> [ 54.471310] ? drm_connector_list_iter_next+0x89/0x9a
> [ 54.476953] ? i915_hotplug_work_func+0x206/0x2be
> [ 54.482208] ? worker_thread+0x4d5/0x6e2
> [ 54.486587] ? worker_thread+0x455/0x6e2
> [ 54.490966] ? queue_work_on+0x64/0x64
> [ 54.495151] ? kthread+0x1e9/0x1f1
> [ 54.498946] ? queue_work_on+0x64/0x64
> [ 54.503130] ? kthread_unpark+0x5e/0x5e
> [ 54.507413] ? ret_from_fork+0x3a/0x50
>
> The proper fix for this is probably cleanup the VCPI allocations when we're
> enabling the topology, or on the first payload allocation. For now though,
> let's just revert.
>
> Signed-off-by: Lyude Paul
> Fixes: 64e62bdf04ab ("drm/dp_mst: Remove VCPI while disabling topology mgr")
> Cc: Sean Paul
> Cc: Wayne Lin
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 13 -
> 1 file changed, 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 4b74193b89ce..0c585f2bbb69 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3481,7 +3481,6 @@ static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8
> dp_link_count)
> int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr,
> bool mst_state)
> {
> int ret = 0;
> - int i = 0;
> struct drm_dp_mst_branch *mstb = NULL;
>
> mutex_lock(&mgr->lock);
> @@ -3542,22 +3541,10 @@ int drm_dp_mst_topology_mgr_set_mst(struct
> drm_dp_mst_topology_mgr *mgr, bool ms
> /* this can fail if the device is gone */
> drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL, 0);
> ret = 0;
> - mutex_lock(&mgr->payload_lock);
> memset(mgr->payloads, 0, mgr->max_payloads * sizeof(struct
> drm_dp_payload));
> mgr->payload_mask = 0;
> set_bit(0, &mgr->payload_mask);
> - for (i = 0; i < mgr->max_payloads; i++) {
> - struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
> -
> - if (vcpi) {
> - vcpi->vcpi = 0;
> - vcpi->num_slots = 0;
> - }
> - mgr->proposed_vcpis[i] = NULL;
> - }
> mgr->vcpi_mask = 0;
> - mutex_unlock(&mgr->payload_lock);
> -
> mgr->payload_id_table_cleared = false;
> }
>
> --
> 2.24.1
>
--
Jiri Kosina
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/14] HID: picoLCD: constify fb ops
On Thu, 5 Dec 2019, Jani Nikula wrote: > >> Now that the fbops member of struct fb_info is const, we can start > >> making the ops const as well. > >> > >> v2: fixtypo (Christophe de Dinechin) > > > > Fine with me. > > I don't think going through drm-misc would trigger any conflict, but > > adding Jiri to CC for the case there was any preference. > > > > Acked-by: Bruno Prémont > > No response, may I proceed with merging this through drm-misc please? I have been off the grid the past week, sorry for belated response. Feel free to add Acked-by: Jiri Kosina and take it through your tree. -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Paper over locking inversion after registration rework
On Thu, 4 Aug 2016, Daniel Vetter wrote: > drm_connector_register_all requires a few too many locks because our > connector_list locking is busted. Add another FIXME+hack to work > around this. This should address the below lockdep splat: [ ... snip ... ] > v2: Rebase onto the right branch (hand-editing patches ftw) and add more > reporters. > > Reported-by: Imre Deak > Cc: Imre Deak > Cc: Chris Wilson > Acked-by: Chris Wilson > Reported-by: Jiri Kosina Although I have no idea why this is safe thing to do :) I can confirm that it removes the lockdep complaint on my system. So in that regard, Tested-by: Jiri Kosina Thanks, -- Jiri Kosina SUSE Labs
[git pull] drm for v4.8
On Tue, 2 Aug 2016, Jani Nikula wrote: > >> > This is the main drm pull request for 4.8, I'm down with a cold at the > >> > moment > >> > so hopefully this isn't in too bad a state, I finished pulling stuff last > >> > week mostly (nouveau fixes just went in today), so only this message > >> > should > >> > be influenced by illness. Apologies to anyone who's major feature I > >> > missed :-) > >> > > >> > i915: > >> > BXT support enabled by default > >> > GVT-g infrastructure > >> > GuC command submission and fixes > >> > BXT workarounds > >> > SKL/BKL workarounds > >> > Demidlayering device registration > >> > Thundering herd fixes > >> > Missing pci ids > >> > Atomic updates > >> > >> Hmm. I did the merge and pushed it out, but testing it on my laptop > >> shows some very annoying flickering problem. > > > > In addition to that, what I see with current git (HEAD == 731c7d3a205, > > i.e. the drm merge) is lockdep report during bootup about AB-BA between > > mode_config.mutex and fb_notifier_list rwsem; will probably not have time > > to look into it more (look at the code and / or bisect) until tomorrow, so > > sending out early as a heads-up. > > > > Also, trying to suspend the machine to disk hangs, with the "suspend" LED > > constantly blinking, LCD being blank, but the machine never actually > > powering off. Not sure whether it might not be the very deadlock actually > > triggering for real. > > There was [1] before my vacation to fix this, but it doesn't seem to > have gone anywhere since. And it doesn't refer what caused the lockdep > splat to begin with. Confirmed, that patch fixes the lockdep splat, so for that part Tested-by: Jiri Kosina -- Jiri Kosina SUSE Labs
[git pull] drm for v4.8
On Tue, 2 Aug 2016, Jiri Kosina wrote: > In addition to that, what I see with current git (HEAD == 731c7d3a205, > i.e. the drm merge) is lockdep report during bootup about AB-BA between > mode_config.mutex and fb_notifier_list rwsem; will probably not have time > to look into it more (look at the code and / or bisect) until tomorrow, so > sending out early as a heads-up. > > Also, trying to suspend the machine to disk hangs, with the "suspend" LED > constantly blinking, LCD being blank, but the machine never actually > powering off. Not sure whether it might not be the very deadlock actually > triggering for real. Ok, I tried HEAD == 7a66ecf (per-drm merge kernel from yesterday), and it doesn't produce the AB-BA warning (so it's really introduced by the last merge), but still has the suspend issue, so those are two separate issues. -- Jiri Kosina SUSE Labs
[git pull] drm for v4.8
b_notifier_call_chain+0x1b/0x20
[8.733116][] register_framebuffer+0x239/0x320
[8.733126][]
drm_fb_helper_initial_config+0x25a/0x3a3 [drm_kms_helper]
[8.733169][] intel_fbdev_initial_config+0x18/0x30
[i915]
[8.733172][] async_run_entry_fn+0x4a/0x140
[8.733174][] process_one_work+0x1de/0x670
[8.733176][] worker_thread+0x125/0x4a0
[8.733178][] kthread+0xf2/0x110
[8.733181][] ret_from_fork+0x1f/0x40
[8.733181]
other info that might help us debug this:
[8.733182] Possible unsafe locking scenario:
[8.733183]CPU0CPU1
[8.733183]
[8.733185] lock((fb_notifier_list).rwsem);
[8.733186]lock(&dev->mode_config.mutex);
[8.733187]lock((fb_notifier_list).rwsem);
[8.733188] lock(&dev->mode_config.mutex);
[8.733189]
*** DEADLOCK ***
[8.733190] 6 locks held by kworker/u8:3/60:
[8.733194] #0: ("events_unbound"){.+.+.+}, at: []
process_one_work+0x15f/0x670
[8.733198] #1: ((&entry->work)){+.+.+.}, at: []
process_one_work+0x15f/0x670
[8.733201] #2: (registration_lock){+.+.+.}, at: []
register_framebuffer+0x27/0x320
[8.733205] #3: (console_lock){+.+.+.}, at: []
register_framebuffer+0x256/0x320
[8.733208] #4: (&fb_info->lock){+.+.+.}, at: []
lock_fb_info+0x1d/0x40
[8.733212] #5: ((fb_notifier_list).rwsem){.+}, at:
[] __blocking_notifier_call_chain+0x3a/0x70
[8.733212]
stack backtrace:
[8.733214] CPU: 1 PID: 60 Comm: kworker/u8:3 Not tainted
4.7.0-10753-g731c7d3 #459
[8.733215] Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 )
12/19/2008
[8.733218] Workqueue: events_unbound async_run_entry_fn
[8.733221] 95f0b77537d8 8d36c09e
8e822d00
[8.733224] 8e822d00 95f0b7753818 8d18205b
95f0b7753850
[8.733226] 95f0b774d718 0005 0006
95f0b774cd40
[8.733227] Call Trace:
[8.733230] [] dump_stack+0x67/0x99
[8.733232] [] print_circular_bug+0x200/0x20e
[8.733235] [] __lock_acquire+0x16cc/0x1700
[8.733238] [] ? sched_clock_local+0x18/0x80
[8.733240] [] lock_acquire+0xb0/0x1e0
[8.733260] [] ? drm_modeset_lock_all+0x40/0x120 [drm]
[8.733262] [] mutex_lock_nested+0x71/0x390
[8.733281] [] ? drm_modeset_lock_all+0x40/0x120 [drm]
[8.733301] [] ? drm_modeset_lock_all+0x40/0x120 [drm]
[8.733304] [] ? kmem_cache_alloc_trace+0x25c/0x320
[8.733322] [] ? drm_modeset_lock_all+0x25/0x120 [drm]
[8.733341] [] drm_modeset_lock_all+0x40/0x120 [drm]
[8.733351] []
drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80 [drm_kms_helper]
[8.733360] [] drm_fb_helper_set_par+0x2c/0x50
[drm_kms_helper]
[8.733403] [] intel_fbdev_set_par+0x1a/0x60 [i915]
[8.733406] [] fbcon_init+0x4d8/0x550
[8.733408] [] visual_init+0xd6/0x130
[8.733410] [] do_bind_con_driver+0x146/0x310
[8.733413] [] do_take_over_console+0x106/0x180
[8.733415] [] do_fbcon_takeover+0x57/0xb0
[8.733417] [] fbcon_event_notify+0x726/0x870
[8.733419] [] notifier_call_chain+0x4e/0xa0
[8.733422] [] __blocking_notifier_call_chain+0x53/0x70
[8.733424] [] blocking_notifier_call_chain+0x16/0x20
[8.733426] [] fb_notifier_call_chain+0x1b/0x20
[8.733427] [] register_framebuffer+0x239/0x320
[8.733430] [] ? vga_switcheroo_client_fb_set+0x60/0x70
[8.733440] [] drm_fb_helper_initial_config+0x25a/0x3a3
[drm_kms_helper]
[8.733483] [] intel_fbdev_initial_config+0x18/0x30 [i915]
[8.733484] [] async_run_entry_fn+0x4a/0x140
[8.733486] [] process_one_work+0x1de/0x670
[8.733488] [] ? process_one_work+0x15f/0x670
[8.733490] [] worker_thread+0x125/0x4a0
[ 8.733492] [] ? process_one_work+0x670/0x670
[8.733494] [] kthread+0xf2/0x110
[8.733497] [] ret_from_fork+0x1f/0x40
[8.733499] [] ? kthread_create_on_node+0x220/0x220
--
Jiri Kosina
SUSE Labs
[PATCH] backlight: Avoid double fbcon backlight handling
On Thu, 30 Jun 2016, Chris Wilson wrote:
> Backlights controlled by i915.ko and only associated with its connectors
> and also only associated with the intel_drmfb fbcon, controlled by
> i915.ko. In this situation, we already handle adjusting the backlight
> when the fbcon is blanked/unblanked and do not require backlight trying
> to do the same.
>
> Attempting to register with the fbdev as a client causes lockdep to warn
> about a dependency cycle:
[ ... snip ... ]
> drivers/hid/hid-picolcd_backlight.c | 3 ++-
For this one:
Acked-by: Jiri Kosina
--
Jiri Kosina
SUSE Labs
[4.6-rcX regression] closing and opening LID on thinkpad x200s freezes X
On Thu, 7 Apr 2016, Bjørn Mork wrote: > > after updating to 4.6-rcX (where X is 1 or 2, doesn't really matter) on > > thinkpad x200s notebook with > > > > 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series > > Chipset Integrated Graphics Controller (rev 07) > > > > closing and opening the lid freezes the computer completely (after opening > > the LID, I can see either the complete original contents of the screen, or > > silouhette of xscreensaver window decorations, but the machine is dead by > > then (neither ctrl-alt-backspace-backspace nor switching to text console > > doesn't work). > > > > It definitely worked with older kernels, but I unfortunately don't have > > all the data needed for bisection, as the old kernels have been wiped off > > the machine in the meantime. > > > > Is this a known issue? > > Yup. Fix is queued: https://lkml.org/lkml/2016/3/30/151 Excellent. FWIW Tested-by: Jiri Kosina > Good to see that I'm not the only one running rc's on ancient laptops :) Indeed many i915 Gen4 bugs have been discovered on this particular notebook. I like it, there is no way I am getting rid of it :) Thanks, -- Jiri Kosina SUSE Labs
[4.6-rcX regression] closing and opening LID on thinkpad x200s freezes X
Hi, after updating to 4.6-rcX (where X is 1 or 2, doesn't really matter) on thinkpad x200s notebook with 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) closing and opening the lid freezes the computer completely (after opening the LID, I can see either the complete original contents of the screen, or silouhette of xscreensaver window decorations, but the machine is dead by then (neither ctrl-alt-backspace-backspace nor switching to text console doesn't work). It definitely worked with older kernels, but I unfortunately don't have all the data needed for bisection, as the old kernels have been wiped off the machine in the meantime. Is this a known issue? Thanks, -- Jiri Kosina SUSE Labs
[PULL] drm-intel-fixes
On Fri, 8 Aug 2014, Daniel Vetter wrote: > Big fix is the duct-tape for ring init on g4x platforms, we seem to have > found the magic again to make those machines as happy as before (not > perfect though unfortunately, but that was never the case). I unfortunately don't agree with the last part; there are older kernels (such as 3.7) where I have never ever seen this ring initialization failure, despite it being excercised very heavily (hundreds of suspend/resume cycles on the machine I am debugging this problem on). As I said in the bugzilla already, the affected machine will be physically present in my bag at the Kernel Summit, in case it helps you guys from Intel to debug it. -- Jiri Kosina SUSE Labs
[bisect result] Re: 3.15-rc2: i915 regression: only top 20% of screen works in X
On Fri, 25 Apr 2014, Pavel Machek wrote: > > > And we have a winner here :-) > > > > > > Ok, it was not as painfull as I feared. > > > > > > It does not revert cleanly, but doing it by hand was not that bad. > > > > Oh my. That is bizarre, can you check whether you have > > > > commit 9991ae787a0c87fe7c783b4b6f4754c3cdbb6213 > > Yes, with that commit, graphics is back to working state. Please push > it to mainline soon -- it fixes a regression. Feel free to add Alright, most of my testing has been done with that commit present (obviously, as I've been using Chris' branch that has this incorporated), so I have a different ring initialization problem than Pavel had. -- Jiri Kosina SUSE Labs
3.15-rc2: i915 regression: only top 20% of screen works in X
On Thu, 24 Apr 2014, Pavel Machek wrote: > > > [drm:init_ring_common] *ERROR* render ring initialization failed ctl > > > 0001f001 head 2034 tail start 0012f000 > > > > > > Jiri has been seeing a similar issue creep in during resume, but it is > > > not reliable enough to bisect. Is your boot failure reliable enough to > > > bisect? Also drm-intel-nightly should mitigate this failure and allow > > > i915.ko to continue to load and run X, which would be worth testing to > > > make sure that works as intended. > > > > Oh right, g4x going beserk :( Apparently something changed in 3.15 > > somewhere which made this much more likely, but like Chris said in > > Jiri's case it's too unreliable to reproduce for a bisect. We've had > > this come&go pretty much ever since kms support was merged and never > > tracked it down. > > So far I went back to 3.14, and yes, graphics works there. > > Back to 3.15, put it to smaller monitor. This time, top 30% of screen > works, and last working scanline is copied to the rest 60% of > screen. [With the exception of mouse cursor, that somehow affects that > magically.] > > > The bug is https://bugs.freedesktop.org/show_bug.cgi?id=76554 > > > > Like Chris said please test latest drm-intel-nighlty from > > http://cgit.freedesktop.org/drm-intel to make sure that the recently > > merged mitigation measures work properly. But those won't get your gpu > > back, only the display and it's only for 3.16. We're still hunting a > > proper fix for 3.15. > > So you know where the bug is or not? No, but there is a workaround for cases kernel finds out that it cannot execute GPU commands (because the rings failed to initialize), and instead it falls back to CPU rendering directly into the framebuffer. So it's highly sub-optimal, but works around the complete wreckage. -- Jiri Kosina SUSE Labs
3.15-rc2: i915 regression: only top 20% of screen works in X
On Thu, 24 Apr 2014, Pavel Machek wrote: > > That says that i915.ko failed to initialise the GPU (or rather the GPU > > wasn't responding) and bailed during module load. The key line here is > > > [drm:init_ring_common] *ERROR* render ring initialization failed ctl > > 0001f001 head 2034 tail start 0012f000 > > Actually, I'm not using modules -- everything is build-in. Can you try > that config? Perhaps you can then reproduce the failure. > > Jiri has been seeing a similar issue creep in during resume, but it is > > not reliable enough to bisect. Is your boot failure reliable enough to > > bisect? Also drm-intel-nightly should mitigate this failure and allow > > i915.ko to continue to load and run X, which would be worth testing to > > make sure that works as intended. > > So far it failed 100% of time, but this is my main machine, so > bringing it down for extended periods is no-no. > > Greetings to Prague :-). Jiri, do you have i915 a module or build-in? Hi there Pavel, long time no see :) I have i915 built as a module. The thing is, that I can't really bisect this; the problem is, that I've started seeing this quite a long time ago, but only very sporadically (something like once in 40 resumes). But it was getting gradually worse and worse with newer kernels, and with current tree (both Linus' tree and drm-intel-testing), I am getting it 100% reproducibly on every resume. This makes bisection completely impossible though. -- Jiri Kosina
[git pull] drm next tree
On Fri, 7 Feb 2014, Daniel Vetter wrote: > Sorry for missing your report here. Before we disable this again for > gen4 I want to make sure that it's the same irq misrouting issue which > was already the cause for the gmbus irq mess. Can you please boot with > pci=nomsi (so that i915 uses irq16)? > > If that's confirmed then I think we should add the same comment we've > added in intel_i2c.c to this code so that no one dares to wake this > dragon again. I'll do that when I commit the fix. Confirmed, with MSI disabled, i915 is using IRQ 16 and everything is working well. -- Jiri Kosina SUSE Labs
[git pull] drm next tree
On Fri, 7 Feb 2014, Jani Nikula wrote: > >> > git://people.freedesktop.org/~airlied/linux drm-next > >> [ ... snip ... ] > >> > Daniel Vetter (59): > >> [ ... snip ... ] > >> > drm/i915: dp aux irq support for g4x/vlv > >> > >> This commit causes all kinds of havoc on my ThinkPad x200s. It results in > > [ ... snip ... ] > > > > Not having received any response, I suggest the following for 3.14 > > Daniel, it's your commit this bisects to... > > If we end up having to revert, I'd just touch the has_aux_irq part, for > example: > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 5ede4e8..464c047 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -404,7 +404,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp, > int i, ret, recv_bytes; > uint32_t status; > int try, precharge, clock = 0; > - bool has_aux_irq = true; > + bool has_aux_irq = INTEL_INFO(dev)->gen >= 5; > uint32_t timeout; > > /* dp aux is extremely sensitive to irq latency, hence request the That, obviously, works for my system as well. Feel free to add Reported-and-tested-by: Jiri Kosina if you are going with this instead of the revert. -- Jiri Kosina SUSE Labs
[git pull] drm next tree
On Thu, 30 Jan 2014, Jiri Kosina wrote: > > git://people.freedesktop.org/~airlied/linux drm-next > [ ... snip ... ] > > Daniel Vetter (59): > [ ... snip ... ] > > drm/i915: dp aux irq support for g4x/vlv > > This commit causes all kinds of havoc on my ThinkPad x200s. It results in [ ... snip ... ] Not having received any response, I suggest the following for 3.14 From: Jiri Kosina Subject: [PATCH] Revert "drm/i915: dp aux irq support for g4x/vlv" This reverts commit 4aeebd7443e36b0a40032e518a9338f48bd27efc. Conflicts: drivers/gpu/drm/i915/i915_reg.h This commit causes all kinds of havoc on my ThinkPad x200s. It results in irq 16: nobody cared (try booting with the "irqpoll" option) CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.0-00854-g4aeebd7 #1 Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 8800795186c0 88007c203e08 81582503 88007c203e38 810a6a98 88007c203e88 880079518600 0010 88007c203e78 810a6d43 0010ffc4af9d Call Trace: [] dump_stack+0x7a/0x97 [] __report_bad_irq+0x38/0xf0 [] note_interrupt+0x1f3/0x240 [] handle_irq_event_percpu+0x142/0x220 [] handle_irq_event+0x49/0x70 [] handle_fasteoi_irq+0x61/0x100 [] handle_irq+0x59/0x150 [] ? _local_bh_enable+0xe/0x10 [] ? irq_enter+0x81/0x90 [] do_IRQ+0x5b/0xe0 [] common_interrupt+0x6f/0x6f [] ? retint_restore_args+0xe/0xe [] ? poll_idle+0x47/0x90 [] ? poll_idle+0x20/0x90 [] ? ktime_get+0x56/0xd0 [] cpuidle_enter_state+0x40/0xd0 [] cpuidle_idle_call+0x10a/0x160 [] arch_cpu_idle+0x9/0x30 [] cpu_idle_loop+0x8b/0x270 [] cpu_startup_entry+0x1e/0x20 [] rest_init+0xd3/0xe0 [] ? csum_partial_copy_generic+0x170/0x170 [] start_kernel+0x3b3/0x461 [] ? repair_env_string+0x58/0x58 [] x86_64_start_reservations+0x1b/0x32 [] x86_64_start_kernel+0x13a/0x141 handlers: [] usb_hcd_irq [usbcore] Disabling IRQ #16 and things go south afterwards (the machine hangs randomly, I/O is horribly slow, etc). Signed-off-by: Jiri Kosina --- drivers/gpu/drm/i915/i915_irq.c |7 --- drivers/gpu/drm/i915/i915_reg.h |5 - drivers/gpu/drm/i915/intel_dp.c |2 +- 3 files changed, 1 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 17d8fcb..b7fae5b 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1480,9 +1480,6 @@ static irqreturn_t valleyview_irq_handler(int irq, void *arg) intel_hpd_irq_handler(dev, hotplug_trigger, hpd_status_i915); - if (hotplug_status & DP_AUX_CHANNEL_MASK_INT_STATUS_G4X) - dp_aux_irq_handler(dev); - I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status); I915_READ(PORT_HOTPLUG_STAT); } @@ -3670,10 +3667,6 @@ static irqreturn_t i965_irq_handler(int irq, void *arg) intel_hpd_irq_handler(dev, hotplug_trigger, IS_G4X(dev) ? hpd_status_g4x : hpd_status_i915); - if (IS_G4X(dev) && - (hotplug_status & DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)) - dp_aux_irq_handler(dev); - I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status); I915_READ(PORT_HOTPLUG_STAT); } diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index a48b7ca..94b4cd5 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2139,11 +2139,6 @@ #define CRT_HOTPLUG_MONITOR_COLOR(3 << 8) #define CRT_HOTPLUG_MONITOR_MONO (2 << 8) #define CRT_HOTPLUG_MONITOR_NONE (0 << 8) -#define DP_AUX_CHANNEL_D_INT_STATUS_G4X (1 << 6) -#define DP_AUX_CHANNEL_C_INT_STATUS_G4X (1 << 5) -#define DP_AUX_CHANNEL_B_INT_STATUS_G4X (1 << 4) -#define DP_AUX_CHANNEL_MASK_INT_STATUS_G4X (7 << 4) - /* SDVO is different across gen3/4 */ #define SDVOC_HOTPLUG_INT_STATUS_G4X (1 << 3) #define SDVOB_HOTPLUG_INT_STATUS_G4X (1 << 2) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 5ede4e8..464c047 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -404,7 +404,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp, int i, ret, recv_bytes; uint32_t status; int try, precharge, clock = 0; - bool has_aux_irq = true; + bool has_aux_irq = INTEL_INFO(dev)->gen >= 5 && !IS_VALLEYVIEW(dev); uint32_t timeout; /* dp aux is extremely sensitive to irq latency, hence request the -- Jiri Kosina SUSE Labs
[git pull] drm next tree
On Thu, 30 Jan 2014, Dave Airlie wrote:
> git://people.freedesktop.org/~airlied/linux drm-next
[ ... snip ... ]
> Daniel Vetter (59):
[ ... snip ... ]
> drm/i915: dp aux irq support for g4x/vlv
This commit causes all kinds of havoc on my ThinkPad x200s. It results in
irq 16: nobody cared (try booting with the "irqpoll" option)
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.0-00854-g4aeebd7 #1
Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008
8800795186c0 88007c203e08 81582503 88007c203e38
810a6a98 88007c203e88 880079518600
0010 88007c203e78 810a6d43 0010ffc4af9d
Call Trace:
[] dump_stack+0x7a/0x97
[] __report_bad_irq+0x38/0xf0
[] note_interrupt+0x1f3/0x240
[] handle_irq_event_percpu+0x142/0x220
[] handle_irq_event+0x49/0x70
[] handle_fasteoi_irq+0x61/0x100
[] handle_irq+0x59/0x150
[] ? _local_bh_enable+0xe/0x10
[] ? irq_enter+0x81/0x90
[] do_IRQ+0x5b/0xe0
[] common_interrupt+0x6f/0x6f
[] ? retint_restore_args+0xe/0xe
[] ? poll_idle+0x47/0x90
[] ? poll_idle+0x20/0x90
[] ? ktime_get+0x56/0xd0
[] cpuidle_enter_state+0x40/0xd0
[] cpuidle_idle_call+0x10a/0x160
[] arch_cpu_idle+0x9/0x30
[] cpu_idle_loop+0x8b/0x270
[] cpu_startup_entry+0x1e/0x20
[] rest_init+0xd3/0xe0
[] ? csum_partial_copy_generic+0x170/0x170
[] start_kernel+0x3b3/0x461
[] ? repair_env_string+0x58/0x58
[] x86_64_start_reservations+0x1b/0x32
[] x86_64_start_kernel+0x13a/0x141
handlers:
[] usb_hcd_irq [usbcore]
Disabling IRQ #16
and things go south afterwards (the machine hangs randomly, I/O is
horribly slow, etc etc).
This is the same machine that was the reason for
commit c12aba5aa0e60b7947bc8b6ea25ef55c4acf81a4
Author: Jiri Kosina
Date: Tue Mar 19 09:56:57 2013 +0100
drm/i915: stop using GMBUS IRQs on Gen4 chips
back then in 3.9 timeframe, so it might be somehow related. It's, at the
end of the day, again IRQ 16 -- and see the changelog of c12aba5a why this
is rather mysterious (IRQ 16 is assigned to the card when it's not using
MSI, but it *is* in fact using MSI in all the cases).
--
Jiri Kosina
SUSE Labs
HPD flood warning since b8f102e8b
On Thu, 24 Oct 2013, Egbert Eich wrote: > > > > > Can you please attach full dmesg from boot up to the first WARN with > > > > > drm.debug=0xe? This really shouldn't happen and indicates a bug > > > > > somewhere ... > > > > > > > > A bit difficult ... I originally thought that it was reliably > > > > reproducible, but now I didn't get it after 10 suspend/resume cycles. > Will > > > > keep following it, and once it appears, will send you the dmesg. > > > > > > > Could you check if you get any messages regarding HPD storms after > > > suspend/resume ie messages like: > > > "[drm] HPD interrupt storm detected on connector HDMI-A-1" > > > but without the annouing warn messages? > > > > I have this: > > > > [357128.184113] [drm] HPD interrupt storm detected on connector DP-3: > switching from hotplug detection to polling > > > > It appeared in the log approximately 5 seconds after resume has been > > completed. > > > > :( You seem to get this on different connector. > > Any chance for a 'lspci -n' output? 00:00.0 0600: 8086:2a40 (rev 07) 00:02.0 0300: 8086:2a42 (rev 07) 00:02.1 0380: 8086:2a43 (rev 07) 00:03.0 0780: 8086:2a44 (rev 07) 00:03.2 0101: 8086:2a46 (rev 07) 00:03.3 0700: 8086:2a47 (rev 07) 00:19.0 0200: 8086:10f5 (rev 03) 00:1a.0 0c03: 8086:2937 (rev 03) 00:1a.1 0c03: 8086:2938 (rev 03) 00:1a.2 0c03: 8086:2939 (rev 03) 00:1a.7 0c03: 8086:293c (rev 03) 00:1b.0 0403: 8086:293e (rev 03) 00:1c.0 0604: 8086:2940 (rev 03) 00:1c.1 0604: 8086:2942 (rev 03) 00:1c.3 0604: 8086:2946 (rev 03) 00:1d.0 0c03: 8086:2934 (rev 03) 00:1d.1 0c03: 8086:2935 (rev 03) 00:1d.2 0c03: 8086:2936 (rev 03) 00:1d.7 0c03: 8086:293a (rev 03) 00:1e.0 0604: 8086:2448 (rev 93) 00:1f.0 0601: 8086:2917 (rev 03) 00:1f.2 0106: 8086:2929 (rev 03) 00:1f.3 0c05: 8086:2930 (rev 03) 03:00.0 0280: 8086:4237 I (and the computer in question) am in Edinburgh till friday, in case someone wants to have a look. -- Jiri Kosina SUSE Labs
HPD flood warning since b8f102e8b
On Thu, 24 Oct 2013, Jiri Kosina wrote: > I have this: > > [357128.184113] [drm] HPD interrupt storm detected on connector DP-3: > switching from hotplug detection to polling > > It appeared in the log approximately 5 seconds after resume has been > completed. Okay, and it just happened during resume from RAM (it was a very long series of repeating the same trace, I am putting here just the last portion): [362634.813953] [ cut here ] [362634.813980] WARNING: CPU: 0 PID: 666 at drivers/gpu/drm/i915/i915_irq.c:1001 i965_irq_handler+0x492/0x680 [i915]() [362634.813981] Received HPD interrupt although disabled [362634.814021] Modules linked in: sr_mod cdrom dm_mod fuse af_packet tun iptable_mangle xt_DSCP nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables nls_cp1250 nls_cp437 vfat fat rfcomm bnep cpufreq_conservative cpufreq_userspace cpufreq_powersave iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant kvm_intel kvm usb_storage snd_hda_intel iwldvm snd_hda_codec mac80211 snd_hwdep iwlwifi sg snd_pcm cfg80211 snd_seq btusb bluetooth snd_timer pcspkr snd_seq_device thinkpad_acpi lpc_ich rfkill mfd_core i2c_i801 tpm_tis ac tpm battery snd tpm_bios e1000e soundcore snd_page_alloc wmi acpi_cpufreq ehci_pci ptp pps_core autofs4 uhci_hcd ehci_hcd usbcore usb_common i915 drm_kms_helper drm i2c_algo_bit video button edd fan processor ata_generic thermal thermal_sys [362634.814028] CPU: 0 PID: 666 Comm: rs:main Q:Reg Tainted: GW 3.12.0-rc4-6-g162bdaf-dirty #1 [362634.814029] Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 [362634.814033] 03e9 88007c203d18 81583863 88007c203d58 [362634.814035] 8104d297 88007c203d98 0010 0002 [362634.814038] 88003718 0005 88003718 88007c203db8 [362634.814039] Call Trace: [362634.814044][] dump_stack+0x7a/0x97 [362634.814048] [] warn_slowpath_common+0x87/0xb0 [362634.814051] [] warn_slowpath_fmt+0x41/0x50 [362634.814067] [] i965_irq_handler+0x492/0x680 [i915] [362634.814072] [] handle_irq_event_percpu+0xac/0x220 [362634.814074] [] handle_irq_event+0x49/0x70 [362634.814077] [] handle_edge_irq+0x7f/0x150 [362634.814080] [] handle_irq+0x59/0x150 [362634.814083] [] ? irq_enter+0x16/0x90 [362634.814085] [] do_IRQ+0x5b/0xe0 [362634.814089] [] common_interrupt+0x6f/0x6f [362634.814093][] ? lock_acquire+0x110/0x130 [362634.814096] [] ? notifier_call_chain+0xa0/0xa0 [362634.814098] [] __atomic_notifier_call_chain+0x6a/0xc0 [362634.814101] [] ? notifier_call_chain+0xa0/0xa0 [362634.814103] [] atomic_notifier_call_chain+0x11/0x20 [362634.814106] [] do_con_write+0x22f/0xa10 [362634.814109] [] ? mutex_lock_nested+0x2ef/0x370 [362634.814111] [] ? trace_hardirqs_on_caller+0x13d/0x1e0 [362634.814115] [] ? process_output_block+0x3d/0x1e0 [362634.814118] [] con_write+0x19/0x30 [362634.814120] [] process_output_block+0xd0/0x1e0 [362634.814123] [] n_tty_write+0x18b/0x370 [362634.814126] [] ? try_to_wake_up+0x240/0x240 [362634.814129] [] do_tty_write+0xbc/0x200 [362634.814131] [] ? n_tty_ioctl+0x110/0x110 [362634.814134] [] tty_write+0xc4/0xf0 [362634.814137] [] vfs_write+0xe7/0x190 [362634.814139] [] SyS_write+0x60/0xb0 [362634.814142] [] system_call_fastpath+0x16/0x1b [362634.814144] ---[ end trace f54ed427593b8ca0 ]--- [362634.894446] [ cut here ] [362634.894476] WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/i915/i915_irq.c:1001 i965_irq_handler+0x492/0x680 [i915]() [362634.894479] Received HPD interrupt although disabled [362634.894481] Modules linked in: sr_mod cdrom dm_mod fuse af_packet tun iptable_mangle xt_DSCP nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables nls_cp1250 nls_cp437 vfat fat rfcomm bnep cpufreq_conservative cpufreq_userspace cpufreq_powersave iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant kvm_intel kvm usb_storage snd_hda_intel iwldvm snd_hda_codec mac80211 snd_hwdep iwlwifi sg snd_pcm cfg80211 snd_seq btusb bluetooth snd_timer pcspkr snd_seq_device thinkpad_acpi lpc_ich rfkill mfd_core i2c_i801 tpm_tis ac tpm battery snd tpm_bios e1000e soundcore snd_page_alloc wmi acpi_cpufreq ehci_pci ptp pps_core autofs4 uhci_hcd ehci_hcd usbcore usb_common i915 drm_kms_helper drm i2c_algo_bit video button edd fan processor ata_generic thermal thermal_sys [362634.894562] CPU: 1 PID: 1 Comm: systemd Tainted: GW 3.12.0-rc4-6-g162bdaf-dirty #1 [362634.894564] Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 [362634.894567] 03e9 88007c283d18 81583863 88007c283d58 [362634.894572] 8104d297 88007c283d98 0010 00
HPD flood warning since b8f102e8b
On Mon, 21 Oct 2013, Egbert Eich wrote: > > On Thu, 3 Oct 2013, Daniel Vetter wrote: > > > > > Can you please attach full dmesg from boot up to the first WARN with > > > drm.debug=0xe? This really shouldn't happen and indicates a bug > > > somewhere ... > > > > A bit difficult ... I originally thought that it was reliably > > reproducible, but now I didn't get it after 10 suspend/resume cycles. Will > > keep following it, and once it appears, will send you the dmesg. > > > Could you check if you get any messages regarding HPD storms after > suspend/resume ie messages like: > "[drm] HPD interrupt storm detected on connector HDMI-A-1" > but without the annouing warn messages? I have this: [357128.184113] [drm] HPD interrupt storm detected on connector DP-3: switching from hotplug detection to polling It appeared in the log approximately 5 seconds after resume has been completed. Thanks, -- Jiri Kosina SUSE Labs
Re: HPD flood warning since b8f102e8b
On Thu, 3 Oct 2013, Daniel Vetter wrote: > Can you please attach full dmesg from boot up to the first WARN with > drm.debug=0xe? This really shouldn't happen and indicates a bug > somewhere ... OK, I haven't been able to reproduce this any more for ~week ... so please disregard this, and I'll report back if it comes back (will be running with full drm debug output for some time). -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: HPD flood warning since b8f102e8b
On Thu, 3 Oct 2013, Daniel Vetter wrote: > Can you please attach full dmesg from boot up to the first WARN with > drm.debug=0xe? This really shouldn't happen and indicates a bug > somewhere ... A bit difficult ... I originally thought that it was reliably reproducible, but now I didn't get it after 10 suspend/resume cycles. Will keep following it, and once it appears, will send you the dmesg. > > Cheers, Daniel > > On Thu, Oct 3, 2013 at 11:46 AM, Jiri Kosina wrote: > > During resume from hibernation, I started to see the warning below since > > > > commit b8f102e8bf71cacf33326360fdf9dcfd1a63925b > > Author: Egbert Eich > > Date: Fri Jul 26 14:14:24 2013 +0200 > > > > drm/i915: Add messages useful for HPD storm detection debugging > > (v2) > > > > the system is otherwise working properly, and so far it seems to happen > > only during hibernation resume. > > > > [13766.703229] WARNING: CPU: 1 PID: 0 at > > drivers/gpu/drm/i915/i915_irq.c:1001 i965_irq_handler+0x492/0x680 [i915]() > > [13766.703230] Received HPD interrupt although disabled > > [13766.703335] Modules linked in: af_packet tun iptable_mangle xt_DSCP > > nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_tcpudp > > nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter > > ip_tables x_tables rfcomm bn > > ep btusb bluetooth cpufreq_conservative cpufreq_userspace > > cpufreq_powersave iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant > > snd_hda_intel snd_hda_codec kvm_intel snd_hwdep kvm snd_pcm thinkpad_acpi > > snd_seq iwldvm mac80211 sg snd_timer > > iwlwifi snd_seq_device cfg80211 snd i2c_i801 pcspkr rfkill lpc_ich > > mfd_core e1000e ehci_pci snd_page_alloc ptp pps_core tpm_tis tpm soundcore > > battery ac wmi tpm_bios acpi_cpufreq autofs4 uhci_hcd ehci_hcd usbcore > > usb_common i915 drm_kms_he > > lper drm i2c_algo_bit video button edd fan processor ata_generic thermal > > thermal_sys > > [13766.703339] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW > > 3.12.0-rc3 #1 > > [13766.703341] Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 > > ) 12/19/2008 > > [13766.703350] 03e9 88007c283d18 81583013 > > 88007c283d58 > > [13766.703357] 8104d297 88007c283d98 000c > > 0002 > > [13766.703365] 880037158000 0004 880037158000 > > 88007c283db8 > > [13766.703367] Call Trace: > > [13766.703375][] dump_stack+0x7a/0x97 > > [13766.703382] [] warn_slowpath_common+0x87/0xb0 > > [13766.703388] [] warn_slowpath_fmt+0x41/0x50 > > [13766.703425] [] i965_irq_handler+0x492/0x680 [i915] > > [13766.703436] [] handle_irq_event_percpu+0xac/0x220 > > [13766.703442] [] handle_irq_event+0x49/0x70 > > [13766.703449] [] handle_edge_irq+0x7f/0x150 > > [13766.703454] [] handle_irq+0x59/0x150 > > [13766.703461] [] ? > > atomic_notifier_call_chain+0x11/0x20 > > [13766.703466] [] do_IRQ+0x5b/0xe0 > > [13766.703474] [] common_interrupt+0x6f/0x6f > > [13766.703482][] ? > > cpuidle_enter_state+0x54/0xd0 > > [13766.703488] [] ? cpuidle_enter_state+0x50/0xd0 > > [13766.703496] [] cpuidle_idle_call+0x10a/0x160 > > [13766.703503] [] arch_cpu_idle+0x9/0x30 > > [13766.703509] [] cpu_idle_loop+0x8b/0x270 > > [13766.703515] [] cpu_startup_entry+0x1e/0x20 > > [13766.703522] [] start_secondary+0x8e/0x90 > > > > > > It's not a single occurence, it's quite a flood within the same second, > > ending with > > > > [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on > > pin 5 > > [drm] HPD interrupt storm detected on connector HDMI-A-1: switching from > > hotplug detection to pollin > > > > If this really needs to be enabled unconditionally by default (?), having > > it to warn only once would be nice. > > > > If there is anything else I could do to make this go away, please let me > > know. I don't want to be running Tainted: W kernel from now forever on :) > > > > This is a standard x200s thinkpad, no fancy development HW. > > > > -- > > Jiri Kosina > > SUSE Labs > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
HPD flood warning since b8f102e8b
During resume from hibernation, I started to see the warning below since commit b8f102e8bf71cacf33326360fdf9dcfd1a63925b Author: Egbert Eich Date: Fri Jul 26 14:14:24 2013 +0200 drm/i915: Add messages useful for HPD storm detection debugging (v2) the system is otherwise working properly, and so far it seems to happen only during hibernation resume. [13766.703229] WARNING: CPU: 1 PID: 0 at drivers/gpu/drm/i915/i915_irq.c:1001 i965_irq_handler+0x492/0x680 [i915]() [13766.703230] Received HPD interrupt although disabled [13766.703335] Modules linked in: af_packet tun iptable_mangle xt_DSCP nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables rfcomm bn ep btusb bluetooth cpufreq_conservative cpufreq_userspace cpufreq_powersave iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant snd_hda_intel snd_hda_codec kvm_intel snd_hwdep kvm snd_pcm thinkpad_acpi snd_seq iwldvm mac80211 sg snd_timer iwlwifi snd_seq_device cfg80211 snd i2c_i801 pcspkr rfkill lpc_ich mfd_core e1000e ehci_pci snd_page_alloc ptp pps_core tpm_tis tpm soundcore battery ac wmi tpm_bios acpi_cpufreq autofs4 uhci_hcd ehci_hcd usbcore usb_common i915 drm_kms_he lper drm i2c_algo_bit video button edd fan processor ata_generic thermal thermal_sys [13766.703339] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW 3.12.0-rc3 #1 [13766.703341] Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 [13766.703350] 03e9 88007c283d18 81583013 88007c283d58 [13766.703357] 8104d297 88007c283d98 000c 0002 [13766.703365] 880037158000 0004 880037158000 88007c283db8 [13766.703367] Call Trace: [13766.703375][] dump_stack+0x7a/0x97 [13766.703382] [] warn_slowpath_common+0x87/0xb0 [13766.703388] [] warn_slowpath_fmt+0x41/0x50 [13766.703425] [] i965_irq_handler+0x492/0x680 [i915] [13766.703436] [] handle_irq_event_percpu+0xac/0x220 [13766.703442] [] handle_irq_event+0x49/0x70 [13766.703449] [] handle_edge_irq+0x7f/0x150 [13766.703454] [] handle_irq+0x59/0x150 [13766.703461] [] ? atomic_notifier_call_chain+0x11/0x20 [13766.703466] [] do_IRQ+0x5b/0xe0 [13766.703474] [] common_interrupt+0x6f/0x6f [13766.703482][] ? cpuidle_enter_state+0x54/0xd0 [13766.703488] [] ? cpuidle_enter_state+0x50/0xd0 [13766.703496] [] cpuidle_idle_call+0x10a/0x160 [13766.703503] [] arch_cpu_idle+0x9/0x30 [13766.703509] [] cpu_idle_loop+0x8b/0x270 [13766.703515] [] cpu_startup_entry+0x1e/0x20 [13766.703522] [] start_secondary+0x8e/0x90 It's not a single occurence, it's quite a flood within the same second, ending with [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 [drm] HPD interrupt storm detected on connector HDMI-A-1: switching from hotplug detection to pollin If this really needs to be enabled unconditionally by default (?), having it to warn only once would be nice. If there is anything else I could do to make this go away, please let me know. I don't want to be running Tainted: W kernel from now forever on :) This is a standard x200s thinkpad, no fancy development HW. -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dummy-irq: introduce a dummy IRQ handler driver (was Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1]
On Thu, 21 Mar 2013, Daniel Vetter wrote: > Indeed, this is pretty useful and allowed me to quickly reproduce that > phantom irq on my gm45. Thanks to module reloading we can even reset the > kernel's irq disabling logic and so test different tricks quickly without > rebooting. Really useful. Daniel, out of curiosity, have you been able to make some sense of the phantom legacy IRQs on GM45 systems, or are we just staying with my original bandaid (disabling GMBUS IRQs), declaring GM45 broken in this respect? Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH] dummy-irq: introduce a dummy IRQ handler driver (was Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-r
On Thu, 21 Mar 2013, Daniel Vetter wrote: > Indeed, this is pretty useful and allowed me to quickly reproduce that > phantom irq on my gm45. Thanks to module reloading we can even reset the > kernel's irq disabling logic and so test different tricks quickly without > rebooting. Really useful. Daniel, out of curiosity, have you been able to make some sense of the phantom legacy IRQs on GM45 systems, or are we just staying with my original bandaid (disabling GMBUS IRQs), declaring GM45 broken in this respect? Thanks, -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dummy-irq: introduce a dummy IRQ handler driver (was Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1]
On Wed, 20 Mar 2013, Alan Stern wrote:
> > Ok, so how about this?
> > Daniel, is it enough to make the problem appear on your system (by
> > building this into the kernel and booting with dummy-irq.irq=16)?
> >
> > Thanks.
> >
> > From: Jiri Kosina
> > Subject: [PATCH] dummy-irq: introduce a dummy IRQ handler driver
> >
> > This module accepts a single 'irq' parameter, which it should register for.
> >
> > Its sole purpose is to help with debugging of IRQ sharing problems, by
> > force-enabling IRQ that would otherwise be disabled.
> >
> > Suggested-by: Alan Stern
> > Signed-off-by: Jiri Kosina
>
> This is just what I was thinking of. Three extremely minor
> suggestions...
Thanks Alan. Updated version below.
Greg, willing to merge this simple debugging facility?
From: Jiri Kosina
Subject: [PATCH] dummy-irq: introduce a dummy IRQ handler driver
This module accepts a single 'irq' parameter, which it should register for.
Its sole purpose is to help with debugging of IRQ sharing problems, by
force-enabling IRQ that would otherwise be disabled.
Suggested-by: Alan Stern
Signed-off-by: Jiri Kosina
---
drivers/misc/Kconfig |8 ++
drivers/misc/Makefile|1 +
drivers/misc/dummy-irq.c | 59 ++
3 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/dummy-irq.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index e83fdfe..69bb79d 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -93,6 +93,14 @@ config ATMEL_TCB_CLKSRC_BLOCK
TC can be used for other purposes, such as PWM generation and
interval timing.
+config DUMMY_IRQ
+ tristate "Dummy IRQ handler"
+ default n
+ ---help---
+ This module accepts a single 'irq' parameter, which it should
register for.
+ The sole purpose of this module is to help with debugging of systems
on
+ which spurious IRQs would happen on disabled IRQ vector.
+
config IBM_ASM
tristate "Device driver for IBM RSA service processor"
depends on X86 && PCI && INPUT
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 35a1463..28ff261 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_ATMEL_TCLIB) += atmel_tclib.o
obj-$(CONFIG_BMP085) += bmp085.o
obj-$(CONFIG_BMP085_I2C) += bmp085-i2c.o
obj-$(CONFIG_BMP085_SPI) += bmp085-spi.o
+obj-$(CONFIG_DUMMY_IRQ)+= dummy-irq.o
obj-$(CONFIG_ICS932S401) += ics932s401.o
obj-$(CONFIG_LKDTM)+= lkdtm.o
obj-$(CONFIG_TIFM_CORE)+= tifm_core.o
diff --git a/drivers/misc/dummy-irq.c b/drivers/misc/dummy-irq.c
new file mode 100644
index 000..7014167
--- /dev/null
+++ b/drivers/misc/dummy-irq.c
@@ -0,0 +1,59 @@
+/*
+ * Dummy IRQ handler driver.
+ *
+ * This module only registers itself as a handler that is specified to it
+ * by the 'irq' parameter.
+ *
+ * The sole purpose of this module is to help with debugging of systems on
+ * which spurious IRQs would happen on disabled IRQ vector.
+ *
+ * Copyright (C) 2013 Jiri Kosina
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+#include
+#include
+#include
+
+static int irq;
+
+static irqreturn_t dummy_interrupt(int irq, void *dev_id)
+{
+ static int count = 0;
+
+ if (count == 0) {
+ printk(KERN_INFO "dummy-irq: interrupt occured on IRQ %d\n",
+ irq);
+ count++;
+ }
+
+ return IRQ_NONE;
+}
+
+static int __init dummy_irq_init(void)
+{
+ if (request_irq(irq, &dummy_interrupt, IRQF_SHARED, "dummy_irq", &irq))
{
+ printk(KERN_ERR "dummy-irq: cannot register IRQ %d\n", irq);
+ return -EIO;
+ }
+ printk(KERN_INFO "dummy-irq: registered for IRQ %d\n", irq);
+ return 0;
+}
+
+static void __exit dummy_irq_exit(void)
+{
+ printk(KERN_INFO "dummy-irq unloaded\n");
+ free_irq(irq, &irq);
+}
+
+module_init(dummy_irq_init);
+module_exit(dummy_irq_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jiri Kosina");
+module_param(irq, uint, 0444);
+MODULE_PARM_DESC(irq, "The IRQ to register for");
--
Jiri Kosina
SUSE Labs
gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses
On Tue, 19 Mar 2013, Yinghai Lu wrote: > > I guess I should have phrased it more precisely, but that's exactly > > what I expect is happening on my machine: I don't have anything on > > irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence > > the irq is completely disabled. Which obviously makes it impossible > > for me to reproduce the issue. To test that theory, is there a quick > > way to force-enable a given interrupt, short of just hacking up a 2nd > > dummy irq handler in my driver? > > You may try to add another request_irq() > after i915_load_modeset_init==>drm_irq_install. > That could install one dummy action for ioapic irq for i915. > > Also you may need to add one quirk that does not disable intx during > msi enabling like: > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, > 0x2e22, > quirk_msi_intx_disable_bug); > This seemed to be really promising idea to me, as the DisINTx+ vs INTx+ discrepancy is very good hint, but unfortunately, after applying this: --- drivers/pci/quirks.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 0369fb6..8508e24 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -2643,6 +2643,9 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, 0x1073, quirk_msi_intx_disable_bug); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, 0x1083, quirk_msi_intx_disable_bug); + +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2a42, + quirk_msi_intx_disable_bug); #endif /* CONFIG_PCI_MSI */ /* Allow manual resource allocation for PCI hotplug bridges The problem is still there ... so the inconsistency between DisINTx+ and INTx+ is unfortunately not the whole story. -- Jiri Kosina SUSE Labs
gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt respo
On Tue, 19 Mar 2013, Alan Stern wrote:
> > > That might be misleading. It's possible that the erroneous IRQs _are_
> > > being issued but you're simply not aware of them. If the kernel thinks
> > > that no device is using IRQ 16 then it will leave that IRQ disabled.
> >
> > I guess I should have phrased it more precisely, but that's exactly
> > what I expect is happening on my machine: I don't have anything on
> > irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence
> > the irq is completely disabled. Which obviously makes it impossible
> > for me to reproduce the issue. To test that theory, is there a quick
> > way to force-enable a given interrupt, short of just hacking up a 2nd
> > dummy irq handler in my driver?
>
> I don't know of any way. In fact, I have been thinking of writing a
> test driver module, with a module parameter telling it which IRQ number
> to register for. It seems like the sort of thing that would be useful
> to have, from time to time.
Ok, so how about this?
Daniel, is it enough to make the problem appear on your system (by
building this into the kernel and booting with dummy-irq.irq=16)?
Thanks.
From: Jiri Kosina
Subject: [PATCH] dummy-irq: introduce a dummy IRQ handler driver
This module accepts a single 'irq' parameter, which it should register for.
Its sole purpose is to help with debugging of IRQ sharing problems, by
force-enabling IRQ that would otherwise be disabled.
Suggested-by: Alan Stern
Signed-off-by: Jiri Kosina
---
drivers/misc/Kconfig |8 ++
drivers/misc/Makefile|1 +
drivers/misc/dummy-irq.c | 59 ++
3 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/dummy-irq.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index e83fdfe..db24b79 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -93,6 +93,14 @@ config ATMEL_TCB_CLKSRC_BLOCK
TC can be used for other purposes, such as PWM generation and
interval timing.
+config DUMMY_IRQ
+ tristate "Dummy IRQ handler"
+ default n
+ ---help---
+ This module accepts a single 'irq' parameter, which it should
register for.
+ Its sole purpose is to help with debugging of IRQ sharing problems, by
+ force-enabling IRQ that would otherwise be disabled.
+
config IBM_ASM
tristate "Device driver for IBM RSA service processor"
depends on X86 && PCI && INPUT
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 35a1463..28ff261 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_ATMEL_TCLIB) += atmel_tclib.o
obj-$(CONFIG_BMP085) += bmp085.o
obj-$(CONFIG_BMP085_I2C) += bmp085-i2c.o
obj-$(CONFIG_BMP085_SPI) += bmp085-spi.o
+obj-$(CONFIG_DUMMY_IRQ)+= dummy-irq.o
obj-$(CONFIG_ICS932S401) += ics932s401.o
obj-$(CONFIG_LKDTM)+= lkdtm.o
obj-$(CONFIG_TIFM_CORE)+= tifm_core.o
diff --git a/drivers/misc/dummy-irq.c b/drivers/misc/dummy-irq.c
new file mode 100644
index 000..4fc13e0
--- /dev/null
+++ b/drivers/misc/dummy-irq.c
@@ -0,0 +1,59 @@
+/*
+ * Dummy IRQ handler driver.
+ *
+ * This module only registers itself as a handler that is specified to it
+ * by the 'irq' parameter.
+ *
+ * The sole purpose of this module is to help with debugging of systems on
+ * which spurious IRQs cause the IRQ to be disabled.
+ *
+ * Copyright (C) 2013 Jiri Kosina
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+#include
+#include
+#include
+
+static int irq;
+
+static irqreturn_t dummy_interrupt(int irq, void *dev_id)
+{
+ static int count = 0;
+
+ if (count == 0) {
+ printk("dummy-irq: interrupt occured on IRQ %d\n", irq);
+ count++;
+ }
+
+ return IRQ_NONE;
+}
+
+static int __init dummy_irq_init(void)
+{
+ if (request_irq(irq, &dummy_interrupt, IRQF_SHARED, "dummy_irq", &irq))
{
+ printk(KERN_ERR "dummy-irq: cannot register IRQ %d\n", irq);
+ return -EIO;
+ }
+ printk(KERN_INFO "dummy-irq: registered for IRQ %d\n", irq);
+ return 0;
+}
+
+static void __exit dummy_irq_exit(void)
+{
+ printk(KERN_INFO "dummy-irq unloaded\n");
+ free_irq(irq, &irq);
+ return;
+}
+
+module_init(dummy_irq_init);
+module_exit(dummy_irq_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jiri Kosina");
+module_param_named(irq, irq, uint, 0444);
+MODULE_PARM_DESC(irq, "The IRQ to register for");
--
Jiri Kosina
SUSE Labs
[PATCH] dummy-irq: introduce a dummy IRQ handler driver (was Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1]
On Wed, 20 Mar 2013, Alan Stern wrote:
> > Ok, so how about this?
> > Daniel, is it enough to make the problem appear on your system (by
> > building this into the kernel and booting with dummy-irq.irq=16)?
> >
> > Thanks.
> >
> > From: Jiri Kosina
> > Subject: [PATCH] dummy-irq: introduce a dummy IRQ handler driver
> >
> > This module accepts a single 'irq' parameter, which it should register for.
> >
> > Its sole purpose is to help with debugging of IRQ sharing problems, by
> > force-enabling IRQ that would otherwise be disabled.
> >
> > Suggested-by: Alan Stern
> > Signed-off-by: Jiri Kosina
>
> This is just what I was thinking of. Three extremely minor
> suggestions...
Thanks Alan. Updated version below.
Greg, willing to merge this simple debugging facility?
From: Jiri Kosina
Subject: [PATCH] dummy-irq: introduce a dummy IRQ handler driver
This module accepts a single 'irq' parameter, which it should register for.
Its sole purpose is to help with debugging of IRQ sharing problems, by
force-enabling IRQ that would otherwise be disabled.
Suggested-by: Alan Stern
Signed-off-by: Jiri Kosina
---
drivers/misc/Kconfig |8 ++
drivers/misc/Makefile|1 +
drivers/misc/dummy-irq.c | 59 ++
3 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/dummy-irq.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index e83fdfe..69bb79d 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -93,6 +93,14 @@ config ATMEL_TCB_CLKSRC_BLOCK
TC can be used for other purposes, such as PWM generation and
interval timing.
+config DUMMY_IRQ
+ tristate "Dummy IRQ handler"
+ default n
+ ---help---
+ This module accepts a single 'irq' parameter, which it should
register for.
+ The sole purpose of this module is to help with debugging of systems
on
+ which spurious IRQs would happen on disabled IRQ vector.
+
config IBM_ASM
tristate "Device driver for IBM RSA service processor"
depends on X86 && PCI && INPUT
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 35a1463..28ff261 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_ATMEL_TCLIB) += atmel_tclib.o
obj-$(CONFIG_BMP085) += bmp085.o
obj-$(CONFIG_BMP085_I2C) += bmp085-i2c.o
obj-$(CONFIG_BMP085_SPI) += bmp085-spi.o
+obj-$(CONFIG_DUMMY_IRQ)+= dummy-irq.o
obj-$(CONFIG_ICS932S401) += ics932s401.o
obj-$(CONFIG_LKDTM)+= lkdtm.o
obj-$(CONFIG_TIFM_CORE)+= tifm_core.o
diff --git a/drivers/misc/dummy-irq.c b/drivers/misc/dummy-irq.c
new file mode 100644
index 000..7014167
--- /dev/null
+++ b/drivers/misc/dummy-irq.c
@@ -0,0 +1,59 @@
+/*
+ * Dummy IRQ handler driver.
+ *
+ * This module only registers itself as a handler that is specified to it
+ * by the 'irq' parameter.
+ *
+ * The sole purpose of this module is to help with debugging of systems on
+ * which spurious IRQs would happen on disabled IRQ vector.
+ *
+ * Copyright (C) 2013 Jiri Kosina
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+#include
+#include
+#include
+
+static int irq;
+
+static irqreturn_t dummy_interrupt(int irq, void *dev_id)
+{
+ static int count = 0;
+
+ if (count == 0) {
+ printk(KERN_INFO "dummy-irq: interrupt occured on IRQ %d\n",
+ irq);
+ count++;
+ }
+
+ return IRQ_NONE;
+}
+
+static int __init dummy_irq_init(void)
+{
+ if (request_irq(irq, &dummy_interrupt, IRQF_SHARED, "dummy_irq", &irq))
{
+ printk(KERN_ERR "dummy-irq: cannot register IRQ %d\n", irq);
+ return -EIO;
+ }
+ printk(KERN_INFO "dummy-irq: registered for IRQ %d\n", irq);
+ return 0;
+}
+
+static void __exit dummy_irq_exit(void)
+{
+ printk(KERN_INFO "dummy-irq unloaded\n");
+ free_irq(irq, &irq);
+}
+
+module_init(dummy_irq_init);
+module_exit(dummy_irq_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jiri Kosina");
+module_param(irq, uint, 0444);
+MODULE_PARM_DESC(irq, "The IRQ to register for");
--
Jiri Kosina
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt respo
On Tue, 19 Mar 2013, Yinghai Lu wrote: > > I guess I should have phrased it more precisely, but that's exactly > > what I expect is happening on my machine: I don't have anything on > > irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence > > the irq is completely disabled. Which obviously makes it impossible > > for me to reproduce the issue. To test that theory, is there a quick > > way to force-enable a given interrupt, short of just hacking up a 2nd > > dummy irq handler in my driver? > > You may try to add another request_irq() > after i915_load_modeset_init==>drm_irq_install. > That could install one dummy action for ioapic irq for i915. > > Also you may need to add one quirk that does not disable intx during > msi enabling like: > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, > 0x2e22, > quirk_msi_intx_disable_bug); > This seemed to be really promising idea to me, as the DisINTx+ vs INTx+ discrepancy is very good hint, but unfortunately, after applying this: --- drivers/pci/quirks.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 0369fb6..8508e24 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -2643,6 +2643,9 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, 0x1073, quirk_msi_intx_disable_bug); DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, 0x1083, quirk_msi_intx_disable_bug); + +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2a42, + quirk_msi_intx_disable_bug); #endif /* CONFIG_PCI_MSI */ /* Allow manual resource allocation for PCI hotplug bridges The problem is still there ... so the inconsistency between DisINTx+ and INTx+ is unfortunately not the whole story. -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt respo
On Tue, 19 Mar 2013, Alan Stern wrote:
> > > That might be misleading. It's possible that the erroneous IRQs _are_
> > > being issued but you're simply not aware of them. If the kernel thinks
> > > that no device is using IRQ 16 then it will leave that IRQ disabled.
> >
> > I guess I should have phrased it more precisely, but that's exactly
> > what I expect is happening on my machine: I don't have anything on
> > irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence
> > the irq is completely disabled. Which obviously makes it impossible
> > for me to reproduce the issue. To test that theory, is there a quick
> > way to force-enable a given interrupt, short of just hacking up a 2nd
> > dummy irq handler in my driver?
>
> I don't know of any way. In fact, I have been thinking of writing a
> test driver module, with a module parameter telling it which IRQ number
> to register for. It seems like the sort of thing that would be useful
> to have, from time to time.
Ok, so how about this?
Daniel, is it enough to make the problem appear on your system (by
building this into the kernel and booting with dummy-irq.irq=16)?
Thanks.
From: Jiri Kosina
Subject: [PATCH] dummy-irq: introduce a dummy IRQ handler driver
This module accepts a single 'irq' parameter, which it should register for.
Its sole purpose is to help with debugging of IRQ sharing problems, by
force-enabling IRQ that would otherwise be disabled.
Suggested-by: Alan Stern
Signed-off-by: Jiri Kosina
---
drivers/misc/Kconfig |8 ++
drivers/misc/Makefile|1 +
drivers/misc/dummy-irq.c | 59 ++
3 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/dummy-irq.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index e83fdfe..db24b79 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -93,6 +93,14 @@ config ATMEL_TCB_CLKSRC_BLOCK
TC can be used for other purposes, such as PWM generation and
interval timing.
+config DUMMY_IRQ
+ tristate "Dummy IRQ handler"
+ default n
+ ---help---
+ This module accepts a single 'irq' parameter, which it should
register for.
+ Its sole purpose is to help with debugging of IRQ sharing problems, by
+ force-enabling IRQ that would otherwise be disabled.
+
config IBM_ASM
tristate "Device driver for IBM RSA service processor"
depends on X86 && PCI && INPUT
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 35a1463..28ff261 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_ATMEL_TCLIB) += atmel_tclib.o
obj-$(CONFIG_BMP085) += bmp085.o
obj-$(CONFIG_BMP085_I2C) += bmp085-i2c.o
obj-$(CONFIG_BMP085_SPI) += bmp085-spi.o
+obj-$(CONFIG_DUMMY_IRQ)+= dummy-irq.o
obj-$(CONFIG_ICS932S401) += ics932s401.o
obj-$(CONFIG_LKDTM)+= lkdtm.o
obj-$(CONFIG_TIFM_CORE)+= tifm_core.o
diff --git a/drivers/misc/dummy-irq.c b/drivers/misc/dummy-irq.c
new file mode 100644
index 000..4fc13e0
--- /dev/null
+++ b/drivers/misc/dummy-irq.c
@@ -0,0 +1,59 @@
+/*
+ * Dummy IRQ handler driver.
+ *
+ * This module only registers itself as a handler that is specified to it
+ * by the 'irq' parameter.
+ *
+ * The sole purpose of this module is to help with debugging of systems on
+ * which spurious IRQs cause the IRQ to be disabled.
+ *
+ * Copyright (C) 2013 Jiri Kosina
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+#include
+#include
+#include
+
+static int irq;
+
+static irqreturn_t dummy_interrupt(int irq, void *dev_id)
+{
+ static int count = 0;
+
+ if (count == 0) {
+ printk("dummy-irq: interrupt occured on IRQ %d\n", irq);
+ count++;
+ }
+
+ return IRQ_NONE;
+}
+
+static int __init dummy_irq_init(void)
+{
+ if (request_irq(irq, &dummy_interrupt, IRQF_SHARED, "dummy_irq", &irq))
{
+ printk(KERN_ERR "dummy-irq: cannot register IRQ %d\n", irq);
+ return -EIO;
+ }
+ printk(KERN_INFO "dummy-irq: registered for IRQ %d\n", irq);
+ return 0;
+}
+
+static void __exit dummy_irq_exit(void)
+{
+ printk(KERN_INFO "dummy-irq unloaded\n");
+ free_irq(irq, &irq);
+ return;
+}
+
+module_init(dummy_irq_init);
+module_exit(dummy_irq_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jiri Kosina");
+module_param_named(irq, irq, uint, 0444);
+MODULE_PARM_DESC(irq, "The IRQ to register for");
--
Jiri Kosina
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses))
On Mon, 18 Mar 2013, Chris Wilson wrote:
> > +#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
> > void
> > intel_i2c_reset(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > I915_WRITE(dev_priv->gpio_mmio_base + GMBUS0, 0);
> > - I915_WRITE(dev_priv->gpio_mmio_base + GMBUS4, 0);
> > + if (HAS_GMBUS_IRQ(dev))
> > + I915_WRITE(dev_priv->gpio_mmio_base + GMBUS4, 0);
>
> There should not be any harm in always clearing GMBUS4, it exists on all
> platforms.
>
> > }
> >
> > static void intel_i2c_quirk_set(struct drm_i915_private *dev_priv, bool
> > enable)
> > @@ -203,7 +205,6 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
> > algo->data = bus;
> > }
> >
> > -#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 4)
> > static int
> > gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
> > u32 gmbus2_status,
> > @@ -214,6 +215,13 @@ gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
> > u32 gmbus2 = 0;
> > DEFINE_WAIT(wait);
> >
> > + if (!HAS_GMBUS_IRQ(dev_priv->dev)) {
> > + int ret;
> > + ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset)) &
> > + (GMBUS_SATOER | gmbus2_status),
> > + 50);
>
> This should couple up to the normal return code that chooses the
> appropriate return value based on gmbus2.
>
> How about just using:
> if (!HAS_GMBUS_IRQ(dev_priv->dev)) gmbus4_irq_en = 0;
> and the existing wait loop?
I explicitly wanted to avoid touching GMBUS4 register, as the real cause
of the failure is not clear.
But, as Yinghai Lu points out, the problem is most likely caused by
interrupt disabling not working properly (see his very good point
regarding DisINTx+ and INTx+ discrepancy), so zeroing the register out
should work and it indeed does in my case, hence the (tested) patch
below.
I think it's a 3.9-rc material, and I am all open to debug this further
for 3.10 so that the race is closed and gmbus irqs can be used on Gen4
platform properly.
From: Jiri Kosina
Subject: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips
Commit 28c70f162 ("drm/i915: use the gmbus irq for waits") switched to
using GMBUS irqs instead of GPIO bit-banging for chipset generations 4
and above.
It turns out though that on many systems this leads to spurious interrupts
being generated, long after the register write to disable the IRQs has been
issued.
Flushing of the register writes by POSTING_READ() directly after the register
write doesn't work either.
Disable using of GMBUS IRQs on Gen4 systems before the root cause is found and
revert back to old behavior.
Signed-off-by: Jiri Kosina
---
drivers/gpu/drm/i915/intel_i2c.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index acf8aec..9934724 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -203,7 +203,7 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
algo->data = bus;
}
-#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 4)
+#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
static int
gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
u32 gmbus2_status,
@@ -214,6 +214,8 @@ gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
u32 gmbus2 = 0;
DEFINE_WAIT(wait);
+ if (!HAS_GMBUS_IRQ(dev_priv->dev))
+ gmbus4_irq_en = 0;
/* Important: The hw handles only the first bit, so set only one! Since
* we also need to check for NAKs besides the hw ready/idle signal, we
* need to wake up periodically and check that ourselves. */
--
Jiri Kosina
SUSE Labs
Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses))
On Mon, 18 Mar 2013, Chris Wilson wrote:
> > +#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
> > void
> > intel_i2c_reset(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > I915_WRITE(dev_priv->gpio_mmio_base + GMBUS0, 0);
> > - I915_WRITE(dev_priv->gpio_mmio_base + GMBUS4, 0);
> > + if (HAS_GMBUS_IRQ(dev))
> > + I915_WRITE(dev_priv->gpio_mmio_base + GMBUS4, 0);
>
> There should not be any harm in always clearing GMBUS4, it exists on all
> platforms.
>
> > }
> >
> > static void intel_i2c_quirk_set(struct drm_i915_private *dev_priv, bool
> > enable)
> > @@ -203,7 +205,6 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
> > algo->data = bus;
> > }
> >
> > -#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 4)
> > static int
> > gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
> > u32 gmbus2_status,
> > @@ -214,6 +215,13 @@ gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
> > u32 gmbus2 = 0;
> > DEFINE_WAIT(wait);
> >
> > + if (!HAS_GMBUS_IRQ(dev_priv->dev)) {
> > + int ret;
> > + ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset)) &
> > + (GMBUS_SATOER | gmbus2_status),
> > + 50);
>
> This should couple up to the normal return code that chooses the
> appropriate return value based on gmbus2.
>
> How about just using:
> if (!HAS_GMBUS_IRQ(dev_priv->dev)) gmbus4_irq_en = 0;
> and the existing wait loop?
I explicitly wanted to avoid touching GMBUS4 register, as the real cause
of the failure is not clear.
But, as Yinghai Lu points out, the problem is most likely caused by
interrupt disabling not working properly (see his very good point
regarding DisINTx+ and INTx+ discrepancy), so zeroing the register out
should work and it indeed does in my case, hence the (tested) patch
below.
I think it's a 3.9-rc material, and I am all open to debug this further
for 3.10 so that the race is closed and gmbus irqs can be used on Gen4
platform properly.
From: Jiri Kosina
Subject: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips
Commit 28c70f162 ("drm/i915: use the gmbus irq for waits") switched to
using GMBUS irqs instead of GPIO bit-banging for chipset generations 4
and above.
It turns out though that on many systems this leads to spurious interrupts
being generated, long after the register write to disable the IRQs has been
issued.
Flushing of the register writes by POSTING_READ() directly after the register
write doesn't work either.
Disable using of GMBUS IRQs on Gen4 systems before the root cause is found and
revert back to old behavior.
Signed-off-by: Jiri Kosina
---
drivers/gpu/drm/i915/intel_i2c.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index acf8aec..9934724 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -203,7 +203,7 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
algo->data = bus;
}
-#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 4)
+#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
static int
gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
u32 gmbus2_status,
@@ -214,6 +214,8 @@ gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
u32 gmbus2 = 0;
DEFINE_WAIT(wait);
+ if (!HAS_GMBUS_IRQ(dev_priv->dev))
+ gmbus4_irq_en = 0;
/* Important: The hw handles only the first bit, so set only one! Since
* we also need to check for NAKs besides the hw ready/idle signal, we
* need to wake up periodically and check that ourselves. */
--
Jiri Kosina
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Mon, 18 Mar 2013, Yinghai Lu wrote: > > Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost > > interrupts go away. > > > > My understanding from the other mail is that DAniel Vetter already has an > > idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully > > this datapoint regarding MSI will fit into it. > > What is /proc/interrupts difference between with and without pci=nomsi ? > > drm is forced to share irq 16? Yup, IRQ 16 is being shared, and one of the owners is i915. -- Jiri Kosina SUSE Labs
[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Mon, 18 Mar 2013, Daniel Vetter wrote: > Yep, there's a big comment in the irq handler for that chipset that we > have a gaping race with when using MSI interrupts. Although the comment > bodly claims that the race is small enough to avoid the dreaded "nobody > cared" message. Looks like gmbus is good at hitting that race - on newer > chips it already brought up a similar race in handling pch interrupts. I see ... will target my focus in that direction, thanks. > Can you please give the below patch a whirl? It removes the probably race > msi race avoidance code and replaces it with the same trick Paulo used to > fix pch irq handling races. Unfortunately it didn't change anything, the spurious interrupt report is still there. -- Jiri Kosina SUSE Labs
[PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses))
Okay, so I think that for 3.9 we want the patch below, and if eventually
hardware root cause / workaround is found for GM45, we can have it merged
later.
From: Jiri Kosina
Subject: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips
Commit 28c70f162 ("drm/i915: use the gmbus irq for waits") switched to
using GMBUS irqs instead of GPIO bit-banging for chipset generations 4
and above.
It turns out though that on many systems this leads to spurious interrupts
being generated, long after the register write to disable the IRQs has been
issued.
Flushing of the register writes by POSTING_READ() directly after the register
write doesn't work either.
Disable using of GMBUS IRQs on Gen4 systems before the root cause is found and
revert back to old behavior.
Also be more careful about not issuing GMBUS4 register reads in
gmbus_wait_hw_status() if we are not using GMBUS IRQs.
Signed-off-by: Jiri Kosina
---
drivers/gpu/drm/i915/intel_i2c.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index acf8aec..8638036 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -58,12 +58,14 @@ to_intel_gmbus(struct i2c_adapter *i2c)
return container_of(i2c, struct intel_gmbus, adapter);
}
+#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
void
intel_i2c_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
I915_WRITE(dev_priv->gpio_mmio_base + GMBUS0, 0);
- I915_WRITE(dev_priv->gpio_mmio_base + GMBUS4, 0);
+ if (HAS_GMBUS_IRQ(dev))
+ I915_WRITE(dev_priv->gpio_mmio_base + GMBUS4, 0);
}
static void intel_i2c_quirk_set(struct drm_i915_private *dev_priv, bool enable)
@@ -203,7 +205,6 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
algo->data = bus;
}
-#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 4)
static int
gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
u32 gmbus2_status,
@@ -214,6 +215,13 @@ gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
u32 gmbus2 = 0;
DEFINE_WAIT(wait);
+ if (!HAS_GMBUS_IRQ(dev_priv->dev)) {
+ int ret;
+ ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset)) &
+ (GMBUS_SATOER | gmbus2_status),
+ 50);
+ return ret;
+ }
/* Important: The hw handles only the first bit, so set only one! Since
* we also need to check for NAKs besides the hw ready/idle signal, we
* need to wake up periodically and check that ourselves. */
--
Jiri Kosina
SUSE Labs
Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Mon, 18 Mar 2013, Yinghai Lu wrote: > > Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost > > interrupts go away. > > > > My understanding from the other mail is that DAniel Vetter already has an > > idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully > > this datapoint regarding MSI will fit into it. > > What is /proc/interrupts difference between with and without pci=nomsi ? > > drm is forced to share irq 16? Yup, IRQ 16 is being shared, and one of the owners is i915. -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Mon, 18 Mar 2013, Daniel Vetter wrote: > Yep, there's a big comment in the irq handler for that chipset that we > have a gaping race with when using MSI interrupts. Although the comment > bodly claims that the race is small enough to avoid the dreaded "nobody > cared" message. Looks like gmbus is good at hitting that race - on newer > chips it already brought up a similar race in handling pch interrupts. I see ... will target my focus in that direction, thanks. > Can you please give the below patch a whirl? It removes the probably race > msi race avoidance code and replaces it with the same trick Paulo used to > fix pch irq handling races. Unfortunately it didn't change anything, the spurious interrupt report is still there. -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Fri, 15 Mar 2013, Yinghai Lu wrote: > > Just a datapoint -- I have put a trivial debugging patch in place, and it > > reveals that "nobody cared" for irq 16 happens long after last > > > > I915_WRITE(GMBUS4 + reg_offset, 0); > > > > has been performed in gmbus_wait_hw_status(). On the other hand, if I > > comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(), > > then it of course falls back to GPIO bit-banging, but the "nobody cared" > > for irq 16 is gone. > > > > So it seems like something gets severely confused by the I915_WRITE to > > GMBUS4 + reg_offset. So far this seems to have been reported solely on > > Lenovos as far as I can see (although a completely different types), so it > > might be some platform-specific quirk? > > > > Honestly, I still don't understand how all the GMBUS stuff relates to IRQ > > 16 at all. > > that device is using > i915 :00:02.0: irq 44 for MSI/MSI-X > > so can you try to boot with pci=nomsi? Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost interrupts go away. My understanding from the other mail is that DAniel Vetter already has an idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully this datapoint regarding MSI will fit into it. -- Jiri Kosina SUSE Labs
[PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses))
Okay, so I think that for 3.9 we want the patch below, and if eventually
hardware root cause / workaround is found for GM45, we can have it merged
later.
From: Jiri Kosina
Subject: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips
Commit 28c70f162 ("drm/i915: use the gmbus irq for waits") switched to
using GMBUS irqs instead of GPIO bit-banging for chipset generations 4
and above.
It turns out though that on many systems this leads to spurious interrupts
being generated, long after the register write to disable the IRQs has been
issued.
Flushing of the register writes by POSTING_READ() directly after the register
write doesn't work either.
Disable using of GMBUS IRQs on Gen4 systems before the root cause is found and
revert back to old behavior.
Also be more careful about not issuing GMBUS4 register reads in
gmbus_wait_hw_status() if we are not using GMBUS IRQs.
Signed-off-by: Jiri Kosina
---
drivers/gpu/drm/i915/intel_i2c.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index acf8aec..8638036 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -58,12 +58,14 @@ to_intel_gmbus(struct i2c_adapter *i2c)
return container_of(i2c, struct intel_gmbus, adapter);
}
+#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 5)
void
intel_i2c_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
I915_WRITE(dev_priv->gpio_mmio_base + GMBUS0, 0);
- I915_WRITE(dev_priv->gpio_mmio_base + GMBUS4, 0);
+ if (HAS_GMBUS_IRQ(dev))
+ I915_WRITE(dev_priv->gpio_mmio_base + GMBUS4, 0);
}
static void intel_i2c_quirk_set(struct drm_i915_private *dev_priv, bool enable)
@@ -203,7 +205,6 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
algo->data = bus;
}
-#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)->gen >= 4)
static int
gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
u32 gmbus2_status,
@@ -214,6 +215,13 @@ gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
u32 gmbus2 = 0;
DEFINE_WAIT(wait);
+ if (!HAS_GMBUS_IRQ(dev_priv->dev)) {
+ int ret;
+ ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset)) &
+ (GMBUS_SATOER | gmbus2_status),
+ 50);
+ return ret;
+ }
/* Important: The hw handles only the first bit, so set only one! Since
* we also need to check for NAKs besides the hw ready/idle signal, we
* need to wake up periodically and check that ourselves. */
--
Jiri Kosina
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Fri, 15 Mar 2013, Yinghai Lu wrote: > > Just a datapoint -- I have put a trivial debugging patch in place, and it > > reveals that "nobody cared" for irq 16 happens long after last > > > > I915_WRITE(GMBUS4 + reg_offset, 0); > > > > has been performed in gmbus_wait_hw_status(). On the other hand, if I > > comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(), > > then it of course falls back to GPIO bit-banging, but the "nobody cared" > > for irq 16 is gone. > > > > So it seems like something gets severely confused by the I915_WRITE to > > GMBUS4 + reg_offset. So far this seems to have been reported solely on > > Lenovos as far as I can see (although a completely different types), so it > > might be some platform-specific quirk? > > > > Honestly, I still don't understand how all the GMBUS stuff relates to IRQ > > 16 at all. > > that device is using > i915 :00:02.0: irq 44 for MSI/MSI-X > > so can you try to boot with pci=nomsi? Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost interrupts go away. My understanding from the other mail is that DAniel Vetter already has an idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully this datapoint regarding MSI will fit into it. -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Fri, 15 Mar 2013, Greg KH wrote: > > > > > I have the same problem on my Lenovo T500. I think the graphics card > > > > > is > > > > > involved. > > > > > > > > > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI > > > > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq > > > > > 16: > > > > > nobody cared" during boot, not when I boot with the ATI card. > > > > > > > > Confirming this. After a lot of hassle, I have bisected this reliably to > > > > > > > > commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6 > > > > Author: Daniel Vetter > > > > Date: Sat Dec 1 13:53:45 2012 +0100 > > > > > > > > drm/i915: use the gmbus irq for waits > > > > > > > > Adding Daniel, Imre and Daniel to CC while I will try to figure out > > > > what's > > > > happening in parallel. > > > > > > Wasn't this fixed by the merge from David > > > (2cc79544bd0aabb4b3cf467ead5df526d9134c64)? > > > > Why do you think it should, please? > > The line: > - Fix PCH irq handling race which resulted in missed gmbus/dp > aux irqs and subsequent fallout (Paulo) Ah, that one. I believe that should be irrelevant for GM chipsets, as they don't have AUX line, right? > > (I am seeing this with a2362d247 still). > > Ok, I guess it isn't still fixed properly, just was guessing :) Seems like this is a different issue. Thanks, -- Jiri Kosina SUSE Labs
[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Fri, 15 Mar 2013, Greg KH wrote: > > > I have the same problem on my Lenovo T500. I think the graphics card is > > > involved. > > > > > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI > > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16: > > > nobody cared" during boot, not when I boot with the ATI card. > > > > Confirming this. After a lot of hassle, I have bisected this reliably to > > > > commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6 > > Author: Daniel Vetter > > Date: Sat Dec 1 13:53:45 2012 +0100 > > > > drm/i915: use the gmbus irq for waits > > > > Adding Daniel, Imre and Daniel to CC while I will try to figure out what's > > happening in parallel. > > Wasn't this fixed by the merge from David > (2cc79544bd0aabb4b3cf467ead5df526d9134c64)? Why do you think it should, please? (I am seeing this with a2362d247 still). -- Jiri Kosina SUSE Labs
[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Fri, 15 Mar 2013, Jiri Kosina wrote: > > I have the same problem on my Lenovo T500. I think the graphics card is > > involved. > > > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16: > > nobody cared" during boot, not when I boot with the ATI card. > > Confirming this. After a lot of hassle, I have bisected this reliably to > > commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6 > Author: Daniel Vetter > Date: Sat Dec 1 13:53:45 2012 +0100 > > drm/i915: use the gmbus irq for waits > > Adding Daniel, Imre and Daniel to CC while I will try to figure out what's > happening in parallel. > > Attaching dmesg.txt from the machine with 28c70f162a as head, with > drm.debug=0xe. Just a datapoint -- I have put a trivial debugging patch in place, and it reveals that "nobody cared" for irq 16 happens long after last I915_WRITE(GMBUS4 + reg_offset, 0); has been performed in gmbus_wait_hw_status(). On the other hand, if I comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(), then it of course falls back to GPIO bit-banging, but the "nobody cared" for irq 16 is gone. So it seems like something gets severely confused by the I915_WRITE to GMBUS4 + reg_offset. So far this seems to have been reported solely on Lenovos as far as I can see (although a completely different types), so it might be some platform-specific quirk? Honestly, I still don't understand how all the GMBUS stuff relates to IRQ 16 at all. -- Jiri Kosina SUSE Labs
[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Fri, 15 Mar 2013, Jiri Kosina wrote: > Attaching dmesg.txt from the machine with 28c70f162a as head, with > drm.debug=0xe. OK, now actually attaching it, sorry. -- Jiri Kosina SUSE Labs -- next part -- An embedded and charset-unspecified text was scrubbed... Name: dmesg.txt URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130315/20554fc4/attachment-0001.txt>
[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Fri, 15 Mar 2013, Harald Arnesen wrote: > I have the same problem on my Lenovo T500. I think the graphics card is > involved. > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16: > nobody cared" during boot, not when I boot with the ATI card. Confirming this. After a lot of hassle, I have bisected this reliably to commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6 Author: Daniel Vetter Date: Sat Dec 1 13:53:45 2012 +0100 drm/i915: use the gmbus irq for waits Adding Daniel, Imre and Daniel to CC while I will try to figure out what's happening in parallel. Attaching dmesg.txt from the machine with 28c70f162a as head, with drm.debug=0xe. -- Jiri Kosina SUSE Labs
Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Fri, 15 Mar 2013, Greg KH wrote: > > > > > I have the same problem on my Lenovo T500. I think the graphics card > > > > > is > > > > > involved. > > > > > > > > > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI > > > > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq > > > > > 16: > > > > > nobody cared" during boot, not when I boot with the ATI card. > > > > > > > > Confirming this. After a lot of hassle, I have bisected this reliably to > > > > > > > > commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6 > > > > Author: Daniel Vetter > > > > Date: Sat Dec 1 13:53:45 2012 +0100 > > > > > > > > drm/i915: use the gmbus irq for waits > > > > > > > > Adding Daniel, Imre and Daniel to CC while I will try to figure out > > > > what's > > > > happening in parallel. > > > > > > Wasn't this fixed by the merge from David > > > (2cc79544bd0aabb4b3cf467ead5df526d9134c64)? > > > > Why do you think it should, please? > > The line: > - Fix PCH irq handling race which resulted in missed gmbus/dp > aux irqs and subsequent fallout (Paulo) Ah, that one. I believe that should be irrelevant for GM chipsets, as they don't have AUX line, right? > > (I am seeing this with a2362d247 still). > > Ok, I guess it isn't still fixed properly, just was guessing :) Seems like this is a different issue. Thanks, -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Fri, 15 Mar 2013, Greg KH wrote: > > > I have the same problem on my Lenovo T500. I think the graphics card is > > > involved. > > > > > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI > > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16: > > > nobody cared" during boot, not when I boot with the ATI card. > > > > Confirming this. After a lot of hassle, I have bisected this reliably to > > > > commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6 > > Author: Daniel Vetter > > Date: Sat Dec 1 13:53:45 2012 +0100 > > > > drm/i915: use the gmbus irq for waits > > > > Adding Daniel, Imre and Daniel to CC while I will try to figure out what's > > happening in parallel. > > Wasn't this fixed by the merge from David > (2cc79544bd0aabb4b3cf467ead5df526d9134c64)? Why do you think it should, please? (I am seeing this with a2362d247 still). -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Fri, 15 Mar 2013, Jiri Kosina wrote: > > I have the same problem on my Lenovo T500. I think the graphics card is > > involved. > > > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16: > > nobody cared" during boot, not when I boot with the ATI card. > > Confirming this. After a lot of hassle, I have bisected this reliably to > > commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6 > Author: Daniel Vetter > Date: Sat Dec 1 13:53:45 2012 +0100 > > drm/i915: use the gmbus irq for waits > > Adding Daniel, Imre and Daniel to CC while I will try to figure out what's > happening in parallel. > > Attaching dmesg.txt from the machine with 28c70f162a as head, with > drm.debug=0xe. Just a datapoint -- I have put a trivial debugging patch in place, and it reveals that "nobody cared" for irq 16 happens long after last I915_WRITE(GMBUS4 + reg_offset, 0); has been performed in gmbus_wait_hw_status(). On the other hand, if I comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(), then it of course falls back to GPIO bit-banging, but the "nobody cared" for irq 16 is gone. So it seems like something gets severely confused by the I915_WRITE to GMBUS4 + reg_offset. So far this seems to have been reported solely on Lenovos as far as I can see (although a completely different types), so it might be some platform-specific quirk? Honestly, I still don't understand how all the GMBUS stuff relates to IRQ 16 at all. -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Fri, 15 Mar 2013, Harald Arnesen wrote: > I have the same problem on my Lenovo T500. I think the graphics card is > involved. > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16: > nobody cared" during boot, not when I boot with the ATI card. Confirming this. After a lot of hassle, I have bisected this reliably to commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6 Author: Daniel Vetter Date: Sat Dec 1 13:53:45 2012 +0100 drm/i915: use the gmbus irq for waits Adding Daniel, Imre and Daniel to CC while I will try to figure out what's happening in parallel. Attaching dmesg.txt from the machine with 28c70f162a as head, with drm.debug=0xe. -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
Hi,
I am getting this during hibernate/resume with current Linus' head
(5f738967e89584f99c6a11c6bf09b16c50b6a03e).
==
[ INFO: possible circular locking dependency detected ]
3.8.0-rc2-00038-ge93d369 #178 Not tainted
---
s2disk/3024 is trying to acquire lock:
((fb_notifier_list).rwsem){.+}, at: []
__blocking_notifier_call_chain+0x5a/0xd0
but task is already holding lock:
(console_lock){+.+.+.}, at: [] do_fb_ioctl+0x455/0x590
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (console_lock){+.+.+.}:
[] validate_chain+0x632/0x720
[] __lock_acquire+0x359/0x580
[] lock_acquire+0x121/0x190
[] console_lock+0x6f/0x80
[] register_con_driver+0x5d/0x160
[] take_over_console+0x2d/0x70
[] fbcon_takeover+0x63/0xc0
[] fbcon_fb_registered+0xc5/0x170
[] fbcon_event_notify+0x1d8/0x690
[] notifier_call_chain+0x93/0x140
[] __blocking_notifier_call_chain+0x71/0xd0
[] blocking_notifier_call_chain+0x11/0x20
[] fb_notifier_call_chain+0x16/0x20
[] do_register_framebuffer+0x221/0x2e0
[] register_framebuffer+0x22/0x40
[] drm_fb_helper_single_fb_probe+0x2bc/0x300
[drm_kms_helper]
[] drm_fb_helper_initial_config+0x92/0xd0
[drm_kms_helper]
[] intel_fbdev_init+0x8b/0xc0 [i915]
[] i915_load_modeset_init+0x113/0x1d0 [i915]
[] i915_driver_load+0x5e5/0x940 [i915]
[] drm_get_pci_dev+0x196/0x2a0 [drm]
[] i915_pci_probe+0x3d/0x90 [i915]
[] local_pci_probe+0x49/0x80
[] __pci_device_probe+0xd9/0xe0
[] pci_device_probe+0x36/0x60
[] really_probe+0x79/0x350
[] driver_probe_device+0x54/0xa0
[] __driver_attach+0x9b/0xa0
[] bus_for_each_dev+0x68/0x90
[] driver_attach+0x1c/0x20
[] bus_add_driver+0x1d8/0x290
[] driver_register+0x63/0x150
[] __pci_register_driver+0x62/0x70
[] drm_pci_init+0x10c/0x120 [drm]
[] tpm_bios_measurements_start+0x5d/0xa0 [tpm_bios]
[] do_one_initcall+0x3d/0x180
[] do_init_module+0x6b/0x1d0
[] load_module+0x6fe/0x7e0
[] sys_init_module+0x9b/0xc0
[] system_call_fastpath+0x16/0x1b
-> #0 ((fb_notifier_list).rwsem){.+}:
[] check_prev_add+0x3de/0x440
[] validate_chain+0x632/0x720
[] __lock_acquire+0x359/0x580
[] lock_acquire+0x121/0x190
[] down_read+0x42/0x60
[] __blocking_notifier_call_chain+0x5a/0xd0
[] blocking_notifier_call_chain+0x11/0x20
[] fb_notifier_call_chain+0x16/0x20
[] fb_set_var+0x232/0x3e0
[] do_fb_ioctl+0x468/0x590
[] fb_ioctl+0x3d/0x50
[] do_vfs_ioctl+0x9d/0x350
[] sys_ioctl+0x91/0xb0
[] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(console_lock);
lock((fb_notifier_list).rwsem);
lock(console_lock);
lock((fb_notifier_list).rwsem);
*** DEADLOCK ***
2 locks held by s2disk/3024:
#0: (&fb_info->lock){+.+.+.}, at: [] lock_fb_info+0x22/0x50
#1: (console_lock){+.+.+.}, at: [] do_fb_ioctl+0x455/0x590
stack backtrace:
Pid: 3024, comm: s2disk Not tainted 3.8.0-rc2-00038-ge93d369 #178
Call Trace:
[] print_circular_bug+0x10f/0x120
[] check_prev_add+0x3de/0x440
[] validate_chain+0x632/0x720
[] __lock_acquire+0x359/0x580
[] ? trace_hardirqs_on+0xd/0x10
[] lock_acquire+0x121/0x190
[] ? __blocking_notifier_call_chain+0x5a/0xd0
[] down_read+0x42/0x60
[] ? __blocking_notifier_call_chain+0x5a/0xd0
[] __blocking_notifier_call_chain+0x5a/0xd0
[] blocking_notifier_call_chain+0x11/0x20
[] fb_notifier_call_chain+0x16/0x20
[] fb_set_var+0x232/0x3e0
[] ? do_fb_ioctl+0x455/0x590
[] ? trace_hardirqs_on+0xd/0x10
[] do_fb_ioctl+0x468/0x590
[] ? __lock_acquire+0x359/0x580
[] ? fget_light+0xbc/0x480
[] fb_ioctl+0x3d/0x50
[] do_vfs_ioctl+0x9d/0x350
[] ? fget_light+0x37/0x480
[] sys_ioctl+0x91/0xb0
[] system_call_fastpath+0x16/0x1b
--
Jiri Kosina
SUSE Labs
3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem
Hi,
I am getting this during hibernate/resume with current Linus' head
(5f738967e89584f99c6a11c6bf09b16c50b6a03e).
==
[ INFO: possible circular locking dependency detected ]
3.8.0-rc2-00038-ge93d369 #178 Not tainted
---
s2disk/3024 is trying to acquire lock:
((fb_notifier_list).rwsem){.+}, at: []
__blocking_notifier_call_chain+0x5a/0xd0
but task is already holding lock:
(console_lock){+.+.+.}, at: [] do_fb_ioctl+0x455/0x590
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (console_lock){+.+.+.}:
[] validate_chain+0x632/0x720
[] __lock_acquire+0x359/0x580
[] lock_acquire+0x121/0x190
[] console_lock+0x6f/0x80
[] register_con_driver+0x5d/0x160
[] take_over_console+0x2d/0x70
[] fbcon_takeover+0x63/0xc0
[] fbcon_fb_registered+0xc5/0x170
[] fbcon_event_notify+0x1d8/0x690
[] notifier_call_chain+0x93/0x140
[] __blocking_notifier_call_chain+0x71/0xd0
[] blocking_notifier_call_chain+0x11/0x20
[] fb_notifier_call_chain+0x16/0x20
[] do_register_framebuffer+0x221/0x2e0
[] register_framebuffer+0x22/0x40
[] drm_fb_helper_single_fb_probe+0x2bc/0x300
[drm_kms_helper]
[] drm_fb_helper_initial_config+0x92/0xd0
[drm_kms_helper]
[] intel_fbdev_init+0x8b/0xc0 [i915]
[] i915_load_modeset_init+0x113/0x1d0 [i915]
[] i915_driver_load+0x5e5/0x940 [i915]
[] drm_get_pci_dev+0x196/0x2a0 [drm]
[] i915_pci_probe+0x3d/0x90 [i915]
[] local_pci_probe+0x49/0x80
[] __pci_device_probe+0xd9/0xe0
[] pci_device_probe+0x36/0x60
[] really_probe+0x79/0x350
[] driver_probe_device+0x54/0xa0
[] __driver_attach+0x9b/0xa0
[] bus_for_each_dev+0x68/0x90
[] driver_attach+0x1c/0x20
[] bus_add_driver+0x1d8/0x290
[] driver_register+0x63/0x150
[] __pci_register_driver+0x62/0x70
[] drm_pci_init+0x10c/0x120 [drm]
[] tpm_bios_measurements_start+0x5d/0xa0 [tpm_bios]
[] do_one_initcall+0x3d/0x180
[] do_init_module+0x6b/0x1d0
[] load_module+0x6fe/0x7e0
[] sys_init_module+0x9b/0xc0
[] system_call_fastpath+0x16/0x1b
-> #0 ((fb_notifier_list).rwsem){.+}:
[] check_prev_add+0x3de/0x440
[] validate_chain+0x632/0x720
[] __lock_acquire+0x359/0x580
[] lock_acquire+0x121/0x190
[] down_read+0x42/0x60
[] __blocking_notifier_call_chain+0x5a/0xd0
[] blocking_notifier_call_chain+0x11/0x20
[] fb_notifier_call_chain+0x16/0x20
[] fb_set_var+0x232/0x3e0
[] do_fb_ioctl+0x468/0x590
[] fb_ioctl+0x3d/0x50
[] do_vfs_ioctl+0x9d/0x350
[] sys_ioctl+0x91/0xb0
[] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(console_lock);
lock((fb_notifier_list).rwsem);
lock(console_lock);
lock((fb_notifier_list).rwsem);
*** DEADLOCK ***
2 locks held by s2disk/3024:
#0: (&fb_info->lock){+.+.+.}, at: [] lock_fb_info+0x22/0x50
#1: (console_lock){+.+.+.}, at: [] do_fb_ioctl+0x455/0x590
stack backtrace:
Pid: 3024, comm: s2disk Not tainted 3.8.0-rc2-00038-ge93d369 #178
Call Trace:
[] print_circular_bug+0x10f/0x120
[] check_prev_add+0x3de/0x440
[] validate_chain+0x632/0x720
[] __lock_acquire+0x359/0x580
[] ? trace_hardirqs_on+0xd/0x10
[] lock_acquire+0x121/0x190
[] ? __blocking_notifier_call_chain+0x5a/0xd0
[] down_read+0x42/0x60
[] ? __blocking_notifier_call_chain+0x5a/0xd0
[] __blocking_notifier_call_chain+0x5a/0xd0
[] blocking_notifier_call_chain+0x11/0x20
[] fb_notifier_call_chain+0x16/0x20
[] fb_set_var+0x232/0x3e0
[] ? do_fb_ioctl+0x455/0x590
[] ? trace_hardirqs_on+0xd/0x10
[] do_fb_ioctl+0x468/0x590
[] ? __lock_acquire+0x359/0x580
[] ? fget_light+0xbc/0x480
[] fb_ioctl+0x3d/0x50
[] do_vfs_ioctl+0x9d/0x350
[] ? fget_light+0x37/0x480
[] sys_ioctl+0x91/0xb0
[] system_call_fastpath+0x16/0x1b
--
Jiri Kosina
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
(Short?) merge window reminder
On Tue, 24 May 2011, Andy Lutomirski wrote: > Also, when someone in my lab installs here> on a box that's running software I wrote that needs to support > modern high-speed peripherals, then I can say "What? You seriously > expect this stuff to work on Linux 2007? Let's install a slightly less > stable distro from at least 2010." This sounds a lot less nerdy than > "What? You seriously expect this stuff to work on Linux 2.6.27? Let's > install a slightly less stable distro that uses at least 2.6.36." I hate to jump into this excellent example of bike-shedding discussion, but anyway ... Your example doesn't really reflect reality. It's common for older enterprise distributions to gradually incorporate a lot of backported code (and most importantly new hardware support code/drivers) while not upgrading the kernel major version. So yes, you will in reality get 2.6.16 kernel (at least according to uname) with libata with newer service packs of SLES 10, for example (and you could find many of those across distributions). -- Jiri Kosina SUSE Labs
Re: (Short?) merge window reminder
On Tue, 24 May 2011, Andy Lutomirski wrote: > Also, when someone in my lab installs here> on a box that's running software I wrote that needs to support > modern high-speed peripherals, then I can say "What? You seriously > expect this stuff to work on Linux 2007? Let's install a slightly less > stable distro from at least 2010." This sounds a lot less nerdy than > "What? You seriously expect this stuff to work on Linux 2.6.27? Let's > install a slightly less stable distro that uses at least 2.6.36." I hate to jump into this excellent example of bike-shedding discussion, but anyway ... Your example doesn't really reflect reality. It's common for older enterprise distributions to gradually incorporate a lot of backported code (and most importantly new hardware support code/drivers) while not upgrading the kernel major version. So yes, you will in reality get 2.6.16 kernel (at least according to uname) with libata with newer service packs of SLES 10, for example (and you could find many of those across distributions). -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [TRIVIAL] Fix printk typo 'failled'
adeon/r520.c
> index 3c8677f..3e85628 100644
> --- a/drivers/gpu/drm/radeon/r520.c
> +++ b/drivers/gpu/drm/radeon/r520.c
> @@ -193,12 +193,12 @@ static int r520_startup(struct radeon_device *rdev)
> /* 1M ring buffer */
> r = r100_cp_init(rdev, 1024 * 1024);
> if (r) {
> - dev_err(rdev->dev, "failled initializing CP (%d).\n", r);
> + dev_err(rdev->dev, "failed initializing CP (%d).\n", r);
> return r;
> }
> r = r100_ib_init(rdev);
> if (r) {
> - dev_err(rdev->dev, "failled initializing IB (%d).\n", r);
> + dev_err(rdev->dev, "failed initializing IB (%d).\n", r);
> return r;
> }
> return 0;
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 6b50716..d4821e0 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -2467,7 +2467,7 @@ int r600_resume(struct radeon_device *rdev)
>
> r = r600_ib_test(rdev);
> if (r) {
> - DRM_ERROR("radeon: failled testing IB (%d).\n", r);
> + DRM_ERROR("radeon: failed testing IB (%d).\n", r);
> return r;
> }
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
> b/drivers/gpu/drm/radeon/radeon_ring.c
> index 06e7982..239c3d7 100644
> --- a/drivers/gpu/drm/radeon/radeon_ring.c
> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
> @@ -151,7 +151,7 @@ int radeon_ib_schedule(struct radeon_device *rdev, struct
> radeon_ib *ib)
> /* 64 dwords should be enough for fence too */
> r = radeon_ring_lock(rdev, 64);
> if (r) {
> - DRM_ERROR("radeon: scheduling IB failled (%d).\n", r);
> + DRM_ERROR("radeon: scheduling IB failed (%d).\n", r);
> return r;
> }
> radeon_ring_ib_execute(rdev, ib);
> diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c
> index 5512e4e..7080ee2 100644
> --- a/drivers/gpu/drm/radeon/rs400.c
> +++ b/drivers/gpu/drm/radeon/rs400.c
> @@ -409,12 +409,12 @@ static int rs400_startup(struct radeon_device *rdev)
> /* 1M ring buffer */
> r = r100_cp_init(rdev, 1024 * 1024);
> if (r) {
> - dev_err(rdev->dev, "failled initializing CP (%d).\n", r);
> + dev_err(rdev->dev, "failed initializing CP (%d).\n", r);
> return r;
> }
> r = r100_ib_init(rdev);
> if (r) {
> - dev_err(rdev->dev, "failled initializing IB (%d).\n", r);
> + dev_err(rdev->dev, "failed initializing IB (%d).\n", r);
> return r;
> }
> return 0;
> diff --git a/drivers/gpu/drm/radeon/rs600.c b/drivers/gpu/drm/radeon/rs600.c
> index b4192ac..e92f320 100644
> --- a/drivers/gpu/drm/radeon/rs600.c
> +++ b/drivers/gpu/drm/radeon/rs600.c
> @@ -866,12 +866,12 @@ static int rs600_startup(struct radeon_device *rdev)
> /* 1M ring buffer */
> r = r100_cp_init(rdev, 1024 * 1024);
> if (r) {
> - dev_err(rdev->dev, "failled initializing CP (%d).\n", r);
> + dev_err(rdev->dev, "failed initializing CP (%d).\n", r);
> return r;
> }
> r = r100_ib_init(rdev);
> if (r) {
> - dev_err(rdev->dev, "failled initializing IB (%d).\n", r);
> + dev_err(rdev->dev, "failed initializing IB (%d).\n", r);
> return r;
> }
>
> diff --git a/drivers/gpu/drm/radeon/rs690.c b/drivers/gpu/drm/radeon/rs690.c
> index 0137d3e..2e72b4f 100644
> --- a/drivers/gpu/drm/radeon/rs690.c
> +++ b/drivers/gpu/drm/radeon/rs690.c
> @@ -628,12 +628,12 @@ static int rs690_startup(struct radeon_device *rdev)
> /* 1M ring buffer */
> r = r100_cp_init(rdev, 1024 * 1024);
> if (r) {
> - dev_err(rdev->dev, "failled initializing CP (%d).\n", r);
> + dev_err(rdev->dev, "failed initializing CP (%d).\n", r);
> return r;
> }
> r = r100_ib_init(rdev);
> if (r) {
> - dev_err(rdev->dev, "failled initializing IB (%d).\n", r);
> + dev_err(rdev->dev, "failed initializing IB (%d).\n", r);
> return r;
> }
>
> diff --git a/drivers/gpu/drm/radeon/rv515.c b/drivers/gpu/drm/radeon/rv515.c
> index 5d569f4..a5a4e2e 100644
> --- a/drivers/gpu/drm/radeon/rv515.c
> +++ b/drivers/gpu/drm/radeon/rv515.c
> @@ -398,12 +398,12 @@ static int rv515_startup(struct radeon_device *rdev)
> /* 1M ring buffer */
> r = r100_cp_init(rdev, 1024 * 1024);
> if (r) {
> - dev_err(rdev->dev, "failled initializing CP (%d).\n", r);
> + dev_err(rdev->dev, "failed initializing CP (%d).\n", r);
> return r;
> }
> r = r100_ib_init(rdev);
> if (r) {
> - dev_err(rdev->dev, "failled initializing IB (%d).\n", r);
> + dev_err(rdev->dev, "failed initializing IB (%d).\n", r);
> return r;
> }
> return 0;
> diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
> index 3a264aa..f0b8814 100644
> --- a/drivers/gpu/drm/radeon/rv770.c
> +++ b/drivers/gpu/drm/radeon/rv770.c
> @@ -1201,7 +1201,7 @@ int rv770_resume(struct radeon_device *rdev)
>
> r = r600_ib_test(rdev);
> if (r) {
> - DRM_ERROR("radeon: failled testing IB (%d).\n", r);
> + DRM_ERROR("radeon: failed testing IB (%d).\n", r);
> return r;
> }
>
> --
> 1.7.3.5
>
>
--
Jiri Kosina
SUSE Labs, Novell Inc.
Re: [PATCH] [TRIVIAL] Fix printk typo 'failled'
adeon/r520.c
> index 3c8677f..3e85628 100644
> --- a/drivers/gpu/drm/radeon/r520.c
> +++ b/drivers/gpu/drm/radeon/r520.c
> @@ -193,12 +193,12 @@ static int r520_startup(struct radeon_device *rdev)
> /* 1M ring buffer */
> r = r100_cp_init(rdev, 1024 * 1024);
> if (r) {
> - dev_err(rdev->dev, "failled initializing CP (%d).\n", r);
> + dev_err(rdev->dev, "failed initializing CP (%d).\n", r);
> return r;
> }
> r = r100_ib_init(rdev);
> if (r) {
> - dev_err(rdev->dev, "failled initializing IB (%d).\n", r);
> + dev_err(rdev->dev, "failed initializing IB (%d).\n", r);
> return r;
> }
> return 0;
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 6b50716..d4821e0 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -2467,7 +2467,7 @@ int r600_resume(struct radeon_device *rdev)
>
> r = r600_ib_test(rdev);
> if (r) {
> - DRM_ERROR("radeon: failled testing IB (%d).\n", r);
> + DRM_ERROR("radeon: failed testing IB (%d).\n", r);
> return r;
> }
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
> b/drivers/gpu/drm/radeon/radeon_ring.c
> index 06e7982..239c3d7 100644
> --- a/drivers/gpu/drm/radeon/radeon_ring.c
> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
> @@ -151,7 +151,7 @@ int radeon_ib_schedule(struct radeon_device *rdev, struct
> radeon_ib *ib)
> /* 64 dwords should be enough for fence too */
> r = radeon_ring_lock(rdev, 64);
> if (r) {
> - DRM_ERROR("radeon: scheduling IB failled (%d).\n", r);
> + DRM_ERROR("radeon: scheduling IB failed (%d).\n", r);
> return r;
> }
> radeon_ring_ib_execute(rdev, ib);
> diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c
> index 5512e4e..7080ee2 100644
> --- a/drivers/gpu/drm/radeon/rs400.c
> +++ b/drivers/gpu/drm/radeon/rs400.c
> @@ -409,12 +409,12 @@ static int rs400_startup(struct radeon_device *rdev)
> /* 1M ring buffer */
> r = r100_cp_init(rdev, 1024 * 1024);
> if (r) {
> - dev_err(rdev->dev, "failled initializing CP (%d).\n", r);
> + dev_err(rdev->dev, "failed initializing CP (%d).\n", r);
> return r;
> }
> r = r100_ib_init(rdev);
> if (r) {
> - dev_err(rdev->dev, "failled initializing IB (%d).\n", r);
> + dev_err(rdev->dev, "failed initializing IB (%d).\n", r);
> return r;
> }
> return 0;
> diff --git a/drivers/gpu/drm/radeon/rs600.c b/drivers/gpu/drm/radeon/rs600.c
> index b4192ac..e92f320 100644
> --- a/drivers/gpu/drm/radeon/rs600.c
> +++ b/drivers/gpu/drm/radeon/rs600.c
> @@ -866,12 +866,12 @@ static int rs600_startup(struct radeon_device *rdev)
> /* 1M ring buffer */
> r = r100_cp_init(rdev, 1024 * 1024);
> if (r) {
> - dev_err(rdev->dev, "failled initializing CP (%d).\n", r);
> + dev_err(rdev->dev, "failed initializing CP (%d).\n", r);
> return r;
> }
> r = r100_ib_init(rdev);
> if (r) {
> - dev_err(rdev->dev, "failled initializing IB (%d).\n", r);
> + dev_err(rdev->dev, "failed initializing IB (%d).\n", r);
> return r;
> }
>
> diff --git a/drivers/gpu/drm/radeon/rs690.c b/drivers/gpu/drm/radeon/rs690.c
> index 0137d3e..2e72b4f 100644
> --- a/drivers/gpu/drm/radeon/rs690.c
> +++ b/drivers/gpu/drm/radeon/rs690.c
> @@ -628,12 +628,12 @@ static int rs690_startup(struct radeon_device *rdev)
> /* 1M ring buffer */
> r = r100_cp_init(rdev, 1024 * 1024);
> if (r) {
> - dev_err(rdev->dev, "failled initializing CP (%d).\n", r);
> + dev_err(rdev->dev, "failed initializing CP (%d).\n", r);
> return r;
> }
> r = r100_ib_init(rdev);
> if (r) {
> - dev_err(rdev->dev, "failled initializing IB (%d).\n", r);
> + dev_err(rdev->dev, "failed initializing IB (%d).\n", r);
> return r;
> }
>
> diff --git a/drivers/gpu/drm/radeon/rv515.c b/drivers/gpu/drm/radeon/rv515.c
> index 5d569f4..a5a4e2e 100644
> --- a/drivers/gpu/drm/radeon/rv515.c
> +++ b/drivers/gpu/drm/radeon/rv515.c
> @@ -398,12 +398,12 @@ static i
drm:i915_report_and_clear_eir -- *ERROR* EIR stuck: 0x00000010, masking
Hi, I am getting this during boot with current Linus' tree on x200s thinkpad: [8.312007] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010, masking head -39 /sys/kernel/debug/dri/64/i915_error_state shows: Time: 1295452835 s 347238 us PCI ID: 0x2a42 EIR: 0x0010 PGTBL_ER: 0x0001 Render command stream: ACTHD: 0x00534024 IPEIR: 0x IPEHR: 0x0200 INSTDONE: 0x INSTDONE1: 0xbfbb INSTPS: 0x8001e025 INSTPM: 0x seqno: 0x fence[0] = fence[1] = fence[2] = fence[3] = fence[4] = fence[5] = fence[6] = fence[7] = fence[8] = fence[9] = fence[10] = fence[11] = fence[12] = fence[13] = fence[14] = fence[15] = Active [3]: 0053400016384 0009 0001 dirty render uncached 00042000 5185536 0043 0001 P render uncached (name: 1) 00538000 20971520 0002 0002 P X dirty render uncached Pinned [4]: 4096 0001 0001 P snooped 1000 131072 0001 0001 P uncached 00021000 4096 0001 0001 P snooped 00022000 131072 0001 0001 P uncached Apart from the error in the kernel buffer, graphics seems to work normally. -- Jiri Kosina SUSE Labs, Novell Inc.
[PATCH 03/17][trivial] GPU DRM: Remove unnecessary casts of void ptr returning alloc function return values
On Tue, 9 Nov 2010, Jesper Juhl wrote:
> Hi,
>
> The [vk][cmz]alloc(_node) family of functions return void pointers which
> it's completely unnecessary/pointless to cast to other pointer types since
> that happens implicitly.
>
> This patch removes such casts from drivers/gpu/drm/
>
>
> Signed-off-by: Jesper Juhl
> ---
> drm_sman.c |4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_sman.c b/drivers/gpu/drm/drm_sman.c
> index 463aed9..3466458 100644
> --- a/drivers/gpu/drm/drm_sman.c
> +++ b/drivers/gpu/drm/drm_sman.c
> @@ -59,9 +59,7 @@ drm_sman_init(struct drm_sman * sman, unsigned int
> num_managers,
> {
> int ret = 0;
>
> - sman->mm = (struct drm_sman_mm *) kcalloc(num_managers,
> - sizeof(*sman->mm),
> - GFP_KERNEL);
> + sman->mm = kcalloc(num_managers, sizeof(*sman->mm), GFP_KERNEL);
> if (!sman->mm) {
> ret = -ENOMEM;
> goto out;
>
Doesn't seem to be present in linux-next as of today, applied to trivial
queue.
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
drm:i915_report_and_clear_eir -- *ERROR* EIR stuck: 0x00000010, masking
Hi, I am getting this during boot with current Linus' tree on x200s thinkpad: [8.312007] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010, masking head -39 /sys/kernel/debug/dri/64/i915_error_state shows: Time: 1295452835 s 347238 us PCI ID: 0x2a42 EIR: 0x0010 PGTBL_ER: 0x0001 Render command stream: ACTHD: 0x00534024 IPEIR: 0x IPEHR: 0x0200 INSTDONE: 0x INSTDONE1: 0xbfbb INSTPS: 0x8001e025 INSTPM: 0x seqno: 0x fence[0] = fence[1] = fence[2] = fence[3] = fence[4] = fence[5] = fence[6] = fence[7] = fence[8] = fence[9] = fence[10] = fence[11] = fence[12] = fence[13] = fence[14] = fence[15] = Active [3]: 0053400016384 0009 0001 dirty render uncached 00042000 5185536 0043 0001 P render uncached (name: 1) 00538000 20971520 0002 0002 P X dirty render uncached Pinned [4]: 4096 0001 0001 P snooped 1000 131072 0001 0001 P uncached 00021000 4096 0001 0001 P snooped 00022000 131072 0001 0001 P uncached Apart from the error in the kernel buffer, graphics seems to work normally. -- Jiri Kosina SUSE Labs, Novell Inc. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/17][trivial] GPU DRM: Remove unnecessary casts of void ptr returning alloc function return values
On Tue, 9 Nov 2010, Jesper Juhl wrote:
> Hi,
>
> The [vk][cmz]alloc(_node) family of functions return void pointers which
> it's completely unnecessary/pointless to cast to other pointer types since
> that happens implicitly.
>
> This patch removes such casts from drivers/gpu/drm/
>
>
> Signed-off-by: Jesper Juhl
> ---
> drm_sman.c |4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_sman.c b/drivers/gpu/drm/drm_sman.c
> index 463aed9..3466458 100644
> --- a/drivers/gpu/drm/drm_sman.c
> +++ b/drivers/gpu/drm/drm_sman.c
> @@ -59,9 +59,7 @@ drm_sman_init(struct drm_sman * sman, unsigned int
> num_managers,
> {
> int ret = 0;
>
> - sman->mm = (struct drm_sman_mm *) kcalloc(num_managers,
> - sizeof(*sman->mm),
> - GFP_KERNEL);
> + sman->mm = kcalloc(num_managers, sizeof(*sman->mm), GFP_KERNEL);
> if (!sman->mm) {
> ret = -ENOMEM;
> goto out;
>
Doesn't seem to be present in linux-next as of today, applied to trivial
queue.
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, 19 Oct 2010, Greg KH wrote: > > > > So no need to clean it up for multiprocessor support. > > > > > > > > http://download.intel.com/design/chipsets/datashts/29067602.pdf > > > > http://www.intel.com/design/chipsets/specupdt/29069403.pdf > > > > > > Great, we can just drop all calls to lock_kernel() and the like in the > > > driver and be done with it, right? > > > > No, > > > > you still need to switch off preemption. > > Hm, how would you do that from within a driver? preempt_disable() -- Jiri Kosina SUSE Labs, Novell Inc. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Tue, 19 Oct 2010, Greg KH wrote: > > > > So no need to clean it up for multiprocessor support. > > > > > > > > http://download.intel.com/design/chipsets/datashts/29067602.pdf > > > > http://www.intel.com/design/chipsets/specupdt/29069403.pdf > > > > > > Great, we can just drop all calls to lock_kernel() and the like in the > > > driver and be done with it, right? > > > > No, > > > > you still need to switch off preemption. > > Hm, how would you do that from within a driver? preempt_disable() -- Jiri Kosina SUSE Labs, Novell Inc.
[PATCH 01/13] drivers/gpu/drm: Remove unnecessary casts of private_data
On Sat, 4 Sep 2010, Joe Perches wrote:
> Signed-off-by: Joe Perches
> ---
> drivers/gpu/drm/radeon/radeon_ttm.c |2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c |2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c |2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 84c53e4..a823d8f 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -631,7 +631,7 @@ int radeon_mmap(struct file *filp, struct vm_area_struct
> *vma)
> return drm_mmap(filp, vma);
> }
>
> - file_priv = (struct drm_file *)filp->private_data;
> + file_priv = filp->private_data;
> rdev = file_priv->minor->dev->dev_private;
> if (rdev == NULL) {
> return -EINVAL;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
> index e6a1eb7..dc043c3 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
> @@ -542,7 +542,7 @@ int vmw_fifo_mmap(struct file *filp, struct
> vm_area_struct *vma)
> struct drm_file *file_priv;
> struct vmw_private *dev_priv;
>
> - file_priv = (struct drm_file *)filp->private_data;
> + file_priv = filp->private_data;
> dev_priv = vmw_priv(file_priv->minor->dev);
>
> if (vma->vm_pgoff != (dev_priv->mmio_start >> PAGE_SHIFT) ||
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> index 8312328..1e8eedd 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> @@ -39,7 +39,7 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
> return drm_mmap(filp, vma);
> }
>
> - file_priv = (struct drm_file *)filp->private_data;
> + file_priv = filp->private_data;
> dev_priv = vmw_priv(file_priv->minor->dev);
> return ttm_bo_mmap(filp, vma, &dev_priv->bdev);
> }
This patch isn't present in linux-next as of today. Taking through trivial
queue.
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
Re: [PATCH 01/13] drivers/gpu/drm: Remove unnecessary casts of private_data
On Sat, 4 Sep 2010, Joe Perches wrote:
> Signed-off-by: Joe Perches
> ---
> drivers/gpu/drm/radeon/radeon_ttm.c |2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c |2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c |2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 84c53e4..a823d8f 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -631,7 +631,7 @@ int radeon_mmap(struct file *filp, struct vm_area_struct
> *vma)
> return drm_mmap(filp, vma);
> }
>
> - file_priv = (struct drm_file *)filp->private_data;
> + file_priv = filp->private_data;
> rdev = file_priv->minor->dev->dev_private;
> if (rdev == NULL) {
> return -EINVAL;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
> index e6a1eb7..dc043c3 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
> @@ -542,7 +542,7 @@ int vmw_fifo_mmap(struct file *filp, struct
> vm_area_struct *vma)
> struct drm_file *file_priv;
> struct vmw_private *dev_priv;
>
> - file_priv = (struct drm_file *)filp->private_data;
> + file_priv = filp->private_data;
> dev_priv = vmw_priv(file_priv->minor->dev);
>
> if (vma->vm_pgoff != (dev_priv->mmio_start >> PAGE_SHIFT) ||
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> index 8312328..1e8eedd 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> @@ -39,7 +39,7 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
> return drm_mmap(filp, vma);
> }
>
> - file_priv = (struct drm_file *)filp->private_data;
> + file_priv = filp->private_data;
> dev_priv = vmw_priv(file_priv->minor->dev);
> return ttm_bo_mmap(filp, vma, &dev_priv->bdev);
> }
This patch isn't present in linux-next as of today. Taking through trivial
queue.
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/16] trivial: use ARRAY_SIZE
On Mon, 28 Jun 2010, Kulikov Vasiliy wrote:
> Change sizeof(x) / sizeof(*x) to ARRAY_SIZE(x).
>
> Signed-off-by: Kulikov Vasiliy
> ---
> drivers/gpu/drm/i915/intel_tv.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 6d553c2..d2d4e40 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1424,7 +1424,7 @@ intel_tv_get_modes(struct drm_connector *connector)
> int j, count = 0;
> u64 tmp;
>
> - for (j = 0; j < sizeof(input_res_table) / sizeof(input_res_table[0]);
> + for (j = 0; j < ARRAY_SIZE(input_res_table);
>j++) {
> struct input_res *input = &input_res_table[j];
Folded into the sdvo change you did and applied.
--
Jiri Kosina
SUSE Labs, Novell Inc.
[PATCH 04/16] trivial: use ARRAY_SIZE
On Mon, 28 Jun 2010, Kulikov Vasiliy wrote:
> Change sizeof(x) / sizeof(*x) to ARRAY_SIZE(x).
>
> Signed-off-by: Kulikov Vasiliy
> ---
> drivers/gpu/drm/i915/intel_sdvo.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 76993ac..03c231b 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -392,13 +392,13 @@ static void intel_sdvo_debug_write(struct intel_encoder
> *intel_encoder, u8 cmd,
> DRM_LOG_KMS("%02X ", ((u8 *)args)[i]);
> for (; i < 8; i++)
> DRM_LOG_KMS(" ");
> - for (i = 0; i < sizeof(sdvo_cmd_names) / sizeof(sdvo_cmd_names[0]);
> i++) {
> + for (i = 0; i < ARRAY_SIZE(sdvo_cmd_names); i++) {
> if (cmd == sdvo_cmd_names[i].cmd) {
> DRM_LOG_KMS("(%s)", sdvo_cmd_names[i].name);
> break;
> }
> }
> - if (i == sizeof(sdvo_cmd_names)/ sizeof(sdvo_cmd_names[0]))
> + if (i == ARRAY_SIZE(sdvo_cmd_names))
> DRM_LOG_KMS("(%02X)", cmd);
> DRM_LOG_KMS("\n");
> }
Applied to trivial queue, as linux-next as of today doesn't carry this
patch.
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
[PATCH 03/16] trivial: use ARRAY_SIZE
On Mon, 28 Jun 2010, Kulikov Vasiliy wrote:
> Change sizeof(x) / sizeof(*x) to ARRAY_SIZE(x).
>
> Signed-off-by: Kulikov Vasiliy
> ---
> drivers/gpu/drm/drm_edid.c |7 ++-
> 1 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index c198186..da06476 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -929,13 +929,11 @@ drm_mode_do_interlace_quirk(struct drm_display_mode
> *mode,
> { 1440, 576 },
> { 2880, 576 },
> };
> - static const int n_sizes =
> - sizeof(cea_interlaced)/sizeof(cea_interlaced[0]);
>
> if (!(pt->misc & DRM_EDID_PT_INTERLACED))
> return;
>
> - for (i = 0; i < n_sizes; i++) {
> + for (i = 0; i < ARRAY_SIZE(cea_interlaced); i++) {
> if ((mode->hdisplay == cea_interlaced[i].w) &&
> (mode->vdisplay == cea_interlaced[i].h / 2)) {
> mode->vdisplay *= 2;
> @@ -1375,7 +1373,6 @@ static const struct {
> { 1920, 1440, 60, 0 },
> { 1920, 1440, 75, 0 },
> };
> -static const int num_est3_modes = sizeof(est3_modes) / sizeof(est3_modes[0]);
>
> static int
> drm_est3_modes(struct drm_connector *connector, struct detailed_timing
> *timing)
> @@ -1387,7 +1384,7 @@ drm_est3_modes(struct drm_connector *connector, struct
> detailed_timing *timing)
> for (i = 0; i < 6; i++) {
> for (j = 7; j > 0; j--) {
> m = (i * 8) + (7 - j);
> - if (m >= num_est3_modes)
> + if (m >= ARRAY_SIZE(est3_modes))
> break;
> if (est[i] & (1 << j)) {
> mode = drm_mode_find_dmt(connector->dev,
Not found in linux-next as of today. Applied, thanks.
--
Jiri Kosina
SUSE Labs, Novell Inc.
Re: [PATCH 05/16] trivial: use ARRAY_SIZE
On Mon, 28 Jun 2010, Kulikov Vasiliy wrote:
> Change sizeof(x) / sizeof(*x) to ARRAY_SIZE(x).
>
> Signed-off-by: Kulikov Vasiliy
> ---
> drivers/gpu/drm/i915/intel_tv.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 6d553c2..d2d4e40 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1424,7 +1424,7 @@ intel_tv_get_modes(struct drm_connector *connector)
> int j, count = 0;
> u64 tmp;
>
> - for (j = 0; j < sizeof(input_res_table) / sizeof(input_res_table[0]);
> + for (j = 0; j < ARRAY_SIZE(input_res_table);
>j++) {
> struct input_res *input = &input_res_table[j];
Folded into the sdvo change you did and applied.
--
Jiri Kosina
SUSE Labs, Novell Inc.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/16] trivial: use ARRAY_SIZE
On Mon, 28 Jun 2010, Kulikov Vasiliy wrote:
> Change sizeof(x) / sizeof(*x) to ARRAY_SIZE(x).
>
> Signed-off-by: Kulikov Vasiliy
> ---
> drivers/gpu/drm/i915/intel_sdvo.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 76993ac..03c231b 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -392,13 +392,13 @@ static void intel_sdvo_debug_write(struct intel_encoder
> *intel_encoder, u8 cmd,
> DRM_LOG_KMS("%02X ", ((u8 *)args)[i]);
> for (; i < 8; i++)
> DRM_LOG_KMS(" ");
> - for (i = 0; i < sizeof(sdvo_cmd_names) / sizeof(sdvo_cmd_names[0]);
> i++) {
> + for (i = 0; i < ARRAY_SIZE(sdvo_cmd_names); i++) {
> if (cmd == sdvo_cmd_names[i].cmd) {
> DRM_LOG_KMS("(%s)", sdvo_cmd_names[i].name);
> break;
> }
> }
> - if (i == sizeof(sdvo_cmd_names)/ sizeof(sdvo_cmd_names[0]))
> + if (i == ARRAY_SIZE(sdvo_cmd_names))
> DRM_LOG_KMS("(%02X)", cmd);
> DRM_LOG_KMS("\n");
> }
Applied to trivial queue, as linux-next as of today doesn't carry this
patch.
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/16] trivial: use ARRAY_SIZE
On Mon, 28 Jun 2010, Kulikov Vasiliy wrote:
> Change sizeof(x) / sizeof(*x) to ARRAY_SIZE(x).
>
> Signed-off-by: Kulikov Vasiliy
> ---
> drivers/gpu/drm/drm_edid.c |7 ++-
> 1 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index c198186..da06476 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -929,13 +929,11 @@ drm_mode_do_interlace_quirk(struct drm_display_mode
> *mode,
> { 1440, 576 },
> { 2880, 576 },
> };
> - static const int n_sizes =
> - sizeof(cea_interlaced)/sizeof(cea_interlaced[0]);
>
> if (!(pt->misc & DRM_EDID_PT_INTERLACED))
> return;
>
> - for (i = 0; i < n_sizes; i++) {
> + for (i = 0; i < ARRAY_SIZE(cea_interlaced); i++) {
> if ((mode->hdisplay == cea_interlaced[i].w) &&
> (mode->vdisplay == cea_interlaced[i].h / 2)) {
> mode->vdisplay *= 2;
> @@ -1375,7 +1373,6 @@ static const struct {
> { 1920, 1440, 60, 0 },
> { 1920, 1440, 75, 0 },
> };
> -static const int num_est3_modes = sizeof(est3_modes) / sizeof(est3_modes[0]);
>
> static int
> drm_est3_modes(struct drm_connector *connector, struct detailed_timing
> *timing)
> @@ -1387,7 +1384,7 @@ drm_est3_modes(struct drm_connector *connector, struct
> detailed_timing *timing)
> for (i = 0; i < 6; i++) {
> for (j = 7; j > 0; j--) {
> m = (i * 8) + (7 - j);
> - if (m >= num_est3_modes)
> + if (m >= ARRAY_SIZE(est3_modes))
> break;
> if (est[i] & (1 << j)) {
> mode = drm_mode_find_dmt(connector->dev,
Not found in linux-next as of today. Applied, thanks.
--
Jiri Kosina
SUSE Labs, Novell Inc.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
