Let me provide
Acked-by: Jiri Kosina
so that this patch can be merged by the drm folks together with the rest
of the enablement series.
Thanks,
--
Jiri Kosina
SUSE Labs
> Immutable branch between Backlight, HID and fbdev due for the v6.13 merge
> window
As picoLCD is the only affected driver in HID, I will be pulling this only
if there are any patches for picoLCD submitted for 6.13 (which is not yet
the case).
Thanks,
--
Jiri Kosina
SUSE Labs
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
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
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
ut
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
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
iewed-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
-off-by: Thomas Zimmermann
Acked-by: Jiri Kosina
--
Jiri Kosina
SUSE Labs
no 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
07194323.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
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
; >
> > > > > Add struct_group() to mark region of struct kone_mouse_event that
> > > > > should
> > > > > be initialized to zero.
> > > > >
> > > > > Cc: Stefan Achatz
> > > > > Cc: Jiri Kosina
&
o 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
&g
hat 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
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
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
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
> a
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_devic
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
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
; 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
hink 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 f
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 lock
; > 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 deadl
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 m
3483] [] 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
ed/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
e 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 bug
els, 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
achine 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
ith 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
round 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
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
t 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 e
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
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
b6ea25ef55c4acf81a4
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 c12a
0: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
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,
g
from hotplug detection to polling
It appeared in the log approximately 5 seconds after resume has been
completed.
Thanks,
--
Jiri Kosina
SUSE Labs
gard 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
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 warni
n :)
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
ng. 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
ng. 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
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
&
CI hotplug bridges
The problem is still there ... so the inconsistency between DisINTx+ and
INTx+ is unfortunately not the whole story.
--
Jiri Kosina
SUSE Labs
t, 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 appe
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
&
CI 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
t, 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 appe
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]
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]
th 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
idance 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
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
th 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 o
idance 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 maili
errupts 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
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
errupts 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
s 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
;
> 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
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 t
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..
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
s 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)
;
> 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
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 t
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
_
? 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
cquire+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.fr
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
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
_
rs/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.
rs/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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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.
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.
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
sizeof(*sman->mm),
> - GFP_KERNEL);
> + sman->mm = kcalloc(num_managers, sizeof(*sman->mm), GFP_KERNEL);
> if (!sman->mm) {
> ret = -ENOMEM;
> goto out;
>
Doesn't se
gt; > >
> > > 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?
pree
gt; > >
> > > 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.
_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.
_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
64 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.
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.
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.
64 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
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
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
91 matches
Mail list logo
