really think doing a clean up is worthwhile. Maybe while looking for stuff
to clean up we'll even be able to better comment the existing code. Any
other features people would like to get rid of? Any comments or suggestions?
I'd love to start a good discussion about this going so pl
On Thu, Jul 30, 2020 at 07:09:25AM -0300, Melissa Wen wrote:
> On 07/29, Daniel Vetter wrote:
> > On Wed, Jul 29, 2020 at 9:09 PM Melissa Wen wrote:
> > >
> > > Melissa Wen
> > >
> > > On Sat, Jul 25, 2020 at 3:12 PM Daniel Vetter wrote:
> >
; >
> > > > Cheers,
> > > > -Paul
> > > >
> > > > Paul Cercueil (2):
> > > > drm/ingenic: Handle errors of drm_atomic_get_plane_state
> > > > drm/ingenic: Validate mode in a .mode_valid callback
> > >
&
x27;s going on. Or are we
covered already by a different lock (but then maybe the check here should
be moved, and a comment added about which spinlock protects this).
The other question: How did you even end up in here? I think the better
fix would be to make sure the mode we're settin
map_clear(vaddr_out + src_offset, 24, 8);
Yeah that's a pretty good "oops" oversight on review, nice catch!
Cheers, Daniel
> crc = crc32_le(crc, vaddr_out + src_offset,
> sizeof(u32));
> }
> --
> 2.27.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Sat, Aug 01, 2020 at 08:17:13AM +0200, Christoph Hellwig wrote:
> This symbols isn't used anywhere outside of vgaarb.c.
>
> Signed-off-by: Christoph Hellwig
Nice catch, patch queued up for 5.9.
Thanks, Daniel
> ---
> drivers/gpu/vga/vgaarb.c | 3 +--
> inclu
On Wed, Aug 05, 2020 at 06:03:15PM +0800, Huang Jiachai wrote:
> Hi Daniel
>
> 在 2020/8/5 17:36, Daniel Vetter 写道:
> > On Wed, Aug 5, 2020 at 10:37 AM Sandy Huang wrote:
> > > add this node to get the current true mode.
> > >
> > > Signed-off-by: Sandy
07-17' of
> git://people.freedesktop.org/~agd5f/linux into drm-next")
>
> the spelling error has been introduced on one side of the merge and
> introduced and corrected on the other. This would have produced a
> conflict which David presumably resolved in haste b
s not shut it off, it's just the lowest setting.
But I've not been involved in the details of these discussions.
-Daniel
> +
> /*
>* As we use interpolation lets remove current
>* brightness
On Wed, Aug 05, 2020 at 01:42:27PM +0100, Colin King wrote:
> From: Colin Ian King
>
> There a handful of spelling mistakes. fix them.
>
> Signed-off-by: Colin Ian King
Queued up for 5.10, should show up in linux-next right after the merge
window closes.
-Daniel
> ---
xt TEST_ONLY atomic_check
might duplicate the atomic state object in an incosistent state, and fail.
Worse, this looks like if you race like that then you might duplicate an
object with old reservations still in place, and then we've essentially
leaked those resources and need to reboot. Yes m
@Ivan: sorry about the double post.
Am 11.08.2014 um 16:40 schrieb Ivan T. Ivanov :
> diff --git a/include/dt-bindings/pinctrl/qcom,pmic-gpio.h
> b/include/dt-bindings/pinctrl/qcom,pmic-gpio.h
> new file mode 100644
> index 000..994e748
> --- /dev/null
> +++ b/include/dt-bindings/pinctrl/qcom
> old_{rows,row_size} values which were saved before calling resize_screen().
>
> Daniel Vetter explained that resize_screen() should not recurse into
> fbcon_update_vcs() path due to FBINFO_MISC_USEREVENT being still set
> when calling resize_screen().
>
> Instead of mas
treats the warning. I believe that
> in the body of the commit message, it would be nice to have the warning
> that this patch addresses, and when it appears by running an IGT test.
> Also, say why it should be done this way in vkms.
> This info could help future debugging.
Yeah I t
cquires a vblank ref when setup CRC source
> and releases ref when disabling crc capture, ensuring vblanks happen to
> compute CRC.
>
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
> Co-developed-by: Sidong Yang
> Signed-off-by: Sidong Yang
> Co-developed-by: Daniel Ve
reg Kroah-Hartman
If this helps to get the next gpu related entertainment at least cc'ed to
dri-devel, maybe even using an upstream driver, I'm all for it.
Acked-by: Daniel Vetter
> ---
> include/linux/module.h | 1 +
> kernel/module.c| 12
> 2
---
sound/usb/quirks-table.h | 56 +++-
1 file changed, 55 insertions(+), 1 deletion(-)
diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
index 3c1697f6b60c..a39233cb4d72 100644
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -35
e rollout")
> Signed-off-by: Li Heng
Queued up, should make it into 5.9 merge window, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/drm_drv.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/dr
h I kinda want to wait until we cross that bridge ... this entire vendor
heaps thing still sounds very much like vendor trees hacking around
instead of having upstream drivers using upstream infrastructure.
-Daniel
>
> Cc: Sumit Semwal
> Cc: Andrew F. Davis
> Cc: Benjamin Gaignard
On Mon, Jul 27, 2020 at 10:49:48PM -0400, Kazlauskas, Nicholas wrote:
> On 2020-07-27 5:32 p.m., Daniel Vetter wrote:
> > On Mon, Jul 27, 2020 at 11:11 PM Mazin Rezk wrote:
> > >
> > > On Monday, July 27, 2020 4:29 PM, Daniel Vetter wrote:
> > >
>
On Tue, Jul 28, 2020 at 04:16:34PM +, Sidong Yang wrote:
> On Sun, Jul 26, 2020 at 12:26:08PM +0200, Daniel Vetter wrote:
> > On Sat, Jul 25, 2020 at 9:29 PM Melissa Wen wrote:
> > >
> > > On Sat, Jul 25, 2020 at 4:19 PM Melissa Wen wrote:
> > > >
/context swap idea should make the use-after-free behave how it
> > > did in 5.6. Since the bug doesn't cause an issue in 5.6, it's less of a
> > > "less disturbance" workaround and more of a "no disturbance" workaround.
> >
> > Sorry for bothering, but is there now a solution, besides reverting the
> > commits, to avoid freezes/crashes *without* performance regressions?
> >
> >
> > Kind regards,
> >
> > Paul
>
> Mazin's "drm/amd/display: Clear dm_state for fast updates" change
> accomplishes this, at least as a temporary hack.
Yeah I gets it's horrible, but better than nothing. Reverting the old
amdgpu change to a private state object is probably a lot more invasive.
> I've started work on a more large scale fix that we could get in in after.
Does that include a fix for the "stuff needed by irq handler"? Either way
pls cc dri-devel, I think this is something worth of a bit wider
discussion. Feels like unsolved homework from the entire "make DC
integrate into linux" saga ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
s fine, you can add my:
> Reviewed-by: Sam Ravnborg
>
> I assume you will apply the patches.
> Maybe wait for Daniel to take a look, he had some feedback on where
> to add checks. I assume this is covered by the second patch.
Yeah changelog for new versions would be great, but aside
Hi Hyun Kwon,
Are you all sorted with drm-misc commit rights so you can push the 3
(maybe there's more) xlnx fixup patches to drm-misc-next-fixes?
Cheers, Daniel
On Sat, Jul 25, 2020 at 06:34:29AM +, Wei Yongjun wrote:
> Fix typo in parameter description.
>
> Fixes: d762
Also watching the steps of vkms_crtc_atomic_flush, when the very first
> drm_crtc_vblank_get returned an error, the subtest crashed. On the other
> hand, when vblank_get succeeded, the subtest completed. Finally, checking
> the flush steps: it increases counter to hold a vblank reference
xes
tree from http://cgit.freedesktop.org/~danvet/drm-intel The pull
request for that is currently pending with Dave Airlie.
Cheers, Daniel
PS: When reporting regressions, please always include relevant mailing
list, so that other people see them to (and maybe also because your
dear maintainer may miss a mail
ugh the exonys-next tree.
Yours, Daniel
The following changes since commit bf6f036848ab2151c2498f11cb7d31a52a95dd5c:
drm/vmwgfx: Make vmw_dmabuf_unreference handle NULL objects (2012-11-20
16:19:59 +1000)
are available in the git repository at:
git://people.freedesktop.org/~danvet/drm-
On Thu, Nov 29, 2012 at 11:12:00AM +0100, Daniel Vetter wrote:
> Besides the big item of lifting the "preliminary hw support" tag from the
> Haswell code, just small bits&pieces all over:
> - Leftover Haswell patches and some fixes from Paulo
> - LyncPoint PCH support
s/gpu/drm/i915/dvo_tfp410.c
> CC [M] drivers/gpu/drm/i915/dvo_tfp410.o
> CHECK drivers/gpu/drm/i915/dvo_sil164.c
> CC [M] drivers/gpu/drm/i915/dvo_sil164.o
> CHECK drivers/gpu/drm/i915/dvo_ns2501.c
> CC [M] drivers/gpu/drm/i915/dvo_ns2501.o
> CHECK drivers/gpu/drm/i9
o? We need
to know this since stable rules mandate that a regression is fixed on
upstream first. Once that's figured out we can backport a fix (if
3.9-rc works) or start working on a fix for 3.8-rc kernels first and
backport afterwards.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel
with the new code ...). And
the commit above doesn't really change much in the code itself but it
does change the order (and timing) of the different enable/disable
codepaths.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
t;> So tell me, which case can result in a NULL arg?
>> 1. user size == drv_size // better not be this one
>> 2. user size < driver size
>> 3. user size > driver size
>>
>> It seems to me we still must [simply] be missing something in our
>> parameter valid
esses
> > registers and stack or access to all it's memory.
>
> Confused... why do you think PTRACE_EVENT_CORE_DUMPED reported after
> binfmt->core_dump() won't allow to do this?
Oh, I think I see what you mean. I would ptrace attach prior to the
thread crashing , and get an event for when it crashes ?
> Of course, this can't help to ptrace/inspect other threads, they are
> already (well, almost) dead at this point.
Ideally I would want to attach after it crashes, cause other wise I'd
have to ptrace attach to a lot of threads (to monitor the whole system).
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
27;s his
patch. To assign proper blame please cc: relevant people when sending out
reverts.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
e
in ironlake_set_m_n? And if you have the regressing commit a little
citation to assign the blame (it's probably me) would be good.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the l
> > > > > 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 28c70f162a315bdcfbe0bf940a740ef8bfb918
Another pesky BIOS which changes the display state behind our back on lid
closing! Should be duct-tapped over with
commit 45e2b5f640b3766da3eda48f6c35f088155c06f3
Author: Daniel Vetter
Date: Fri Nov 23 18:16:34 2012 +0100
drm/i915: force restore on lid open
which is in 3.8.
Cheers, Daniel
m commits to revert:
15239099d7a7a9ecdc1ccb5b187ae4cda5488ff9 drm/i915: enable irqs earlier
when resuming
52d7ecedac3f96fb562cb482c139015372728638 drm/i915: reorder setup
sequence to have irqs for output setup
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57
On Mon, Mar 18, 2013 at 10:29:16AM +0100, Takashi Iwai wrote:
> At Sun, 17 Mar 2013 23:12:03 +0100,
> Daniel Vetter wrote:
> >
> > On Tue, Mar 12, 2013 at 04:32:28PM +0100, Takashi Iwai wrote:
> > > The eDP output on HP Z1 is still broken when X is started even afte
to overwrite stored Si5351 configuration
> which is very helpful for clock generators with empty eeprom
> configuration. Corresponding device tree binding documentation is
> also added.
>
> Signed-off-by: Sebastian Hesselbarth
Tested-by: Daniel Mack
Thanks!
Daniel
> ---
&g
On Mon, Mar 18, 2013 at 11:05 AM, Daniel Vetter wrote:
> Hi Greg&all,
>
> So a recent stable backport to fix rc6 on ilk (which is disabled by
> default and with dubious power savings at best, unlike rc6 on snb and
> later) totally blew up all over the place:
> https
to attach after it crashes, cause other wise I'd
> > have to ptrace attach to a lot of threads (to monitor the whole system).
>
> See above. You do not need to attach in advance.
>
> But once again, you can't attach the sub-threads, they are already dead
> when coredump_app is called. PTRACE_ATTACH will work but this can help,
> a sub-thread will never report any event and PF_EXITING is already set.
Ok ..
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
t; > 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
dler is already a bit racy, so any interrupt might
push it over the edge. gmbus interrupts are apparently just help to expose
the race (presuming it's indeed the msi race already docuemented in the
code).
-Daniel
> From: Jiri Kosina
> Subject: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 ch
weren't really
> that many suspects. This partial (to avoid having to change any
> following patches) revert of commit 2a98104 ("drm/i915: reorder setup
> sequence to have irqs for output setup") fixes the problem for me. I
> have no idea why, so I leave it to Daniel and
On 03/08/2013 05:03 PM, Thomas Gleixner wrote:
> On Fri, 8 Mar 2013, Daniel Lezcano wrote:
>
>>> Add the dynamic irq affinity feature to the timer clock device.
>>>
>>> Signed-off-by: Daniel Lezcano
>>> Reviewed-by: Vincent Guittot
>>>
?
Likewise I'd rather see macvtap be responsible for fixing this up by
setting the transport header properly, and therfore sending well
formed packets to the rest of the stack.
Ok, haven't checked all other possibility but looks like packet needs to
be fixed also.
Daniel, could you post yo
On 03/19/2013 01:59 PM, Eric Dumazet wrote:
On Tue, 2013-03-19 at 13:58 +0100, Daniel Borkmann wrote:
Yes, will post them in a couple of minutes.
Please target net tree for the first patch (adding thoff into struct
flow_keys), so that Jason or me can fix DODGY providers.
Sorry, I received
ince apparently
gmbus still works, so we get the interrupts we expect). I have no idea
how that could happen. Hence adding a bunch of people with more clue
than me.
For reference below the updated commit message.
Cheers, Daniel
Author: Jiri Kosina
Date: Tue Mar 19 09:56:57 2013 +0100
d
On Tue, Mar 19, 2013 at 4:38 PM, Alan Stern wrote:
> On Tue, 19 Mar 2013, Daniel Vetter wrote:
>
>> For reference below the updated commit message.
>>
>> Cheers, Daniel
>>
>> Author: Jiri Kosina
>> Date: Tue Mar 19 09:56:57 2013 +0100
>
>>
&
On Tue, Mar 19, 2013 at 9:04 PM, David Lang wrote:
> On Wed, 20 Mar 2013, Martin Steigerwald wrote:
>
>> Am Dienstag, 29. Januar 2013 schrieb Daniel Phillips:
>>>
>>> On Mon, Jan 28, 2013 at 5:40 PM, Theodore Ts'o wrote:
>>>>
>>>> On M
necessarily public.
Don't such things also fall under the "we do not break userspace
compatibility - ever" rule?
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info a
u provide a patch against Sebastian's v3 to do that? Then it can
be cleanly applied on top of the driver later.
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http:
Signed-off-by: Daniel Baluta
---
.../testing/selftests/net-afpacket/psock_fanout.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/testing/selftests/net-afpacket/psock_fanout.c
b/tools/testing/selftests/net-afpacket/psock_fanout.c
index f765f09..226e5e3 100644
ck_fanout-selftest-bind-error-message.patch
"David S. Miller" (commit_signer:4/4=100%)
Willem de Bruijn (commit_signer:2/4=50%)
Daniel Baluta (commit_signer:1/4=25%)
Eric Dumazet (commit_signer:1/4=25%)
linux-kernel@vger.kernel.org (open list)
thanks,
Daniel.
--
To unsubscribe from this
ctory index. Not such a small task, as
you might imagine.
Regards,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, Mar 21, 2013 at 12:21:21AM +0100, Jiri Kosina wrote:
> 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
On Sat, Feb 02, 2013 at 05:20:18PM -0800, Tejun Heo wrote:
> Convert to the much saner new idr interface.
>
> Only compile tested.
>
> Signed-off-by: Tejun Heo
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-de...@lists.freedesktop.org
> ---
> This patch depends
> fence_excl could be used for write access(may need buffer sync like
> > blocking) and read access for the fence_shared(may not need buffer
> > sync). I'm not sure that I understand these two things correctly so
> > could you please give me more comments for them?
> Correct,
EN,
> + MODESET_DONE,
> + MODESET_ON_RESUME,
> +};
> +
> typedef struct drm_i915_private {
> struct drm_device *dev;
>
> @@ -750,9 +756,10 @@ typedef struct drm_i915_private {
>
> unsigned long quirks;
>
> - /* Register state */
&
lan to push this patch to
drm-next for 3.9.
-Daniel
>
> In PM_SUSPEND_MEM state, all the GPEs are cleared when system resumes,
> thus it is the i915_resume code does the modeset rather than
> intel_lid_notify().
>
> But in PM_SUSPEND_FREEZE state, this will be broken because
&
cause stalls any more. In short, our
vblank code seems to be ridiculously racy and broken :( Otoh that's not
really news.
Cheers, Daniel
The following changes since commit b5cc6c0387b2f8d269c1df1e68c97c958dd22fed:
Merge tag 'drm-intel-next-2012-12-21' of
git://people.freedes
@ static int intelfb_create(struct intel_fbdev *ifbdev,
> }
> info->screen_size = size;
>
> + /* This driver doesn't need a VT switch to restore the mode on resume */
> + info->skip_vt_switch = true;
> +
> // memset(info->screen_base, 0, size);
Fol
o we can handle multiple drivers (Alan)
> > > > v3: use a list to track device requests (Rafael)
> > > >
> > > > Signed-off-by: Jesse Barnes
> > >
> > > Acked-by: Rafael J. Wysocki
> > >
> > > for all [1-3/3].
> >
>
Obviously this is a typo and could result in memory leaks
if kzalloc fails on a given cpu.
Signed-off-by: Daniel Baluta
---
kernel/events/hw_breakpoint.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
index
rks for me.
> >
> > Is that patch or any other fix being picked up? It's over three weeks
> > now and I'm still seeing those BUGs with the latest 3.8-rc.
> >
>
> None that I'm aware of.
Either this one
https://patchwork.kernel.org/patch/209450
ct more users of such a sg page iterator to pop up. Most possible
users of this will hang around on linaro-mm-sig, so please also cc that
besides the usual suspects.
Cheers, Daniel
>
> Signed-off-by: Imre Deak
> ---
> include/drm/drmP.h | 44 ++
n the attacker can measure the difference in runtime
and deduce which byte was wrong, reducing the attack space from
exponential to polynomial. [Daniel J. Bernstein]
Therefore add memcmp_nta ({n}o {t}iming {a}ttacks) in order to avoid
such scenarios and to facilitate development by providing a generic
fun
On 02/11/2013 12:24 AM, Joe Perches wrote:
On Sun, 2013-02-10 at 23:00 +0100, Daniel Borkmann wrote:
add memcmp_nta ({n}o {t}iming {a}ttacks)
Why should this be in the kernel?
As the commit message already says, so that current or future (e.g.) network
protocol code or modules can make use
On 02/11/2013 12:50 AM, Greg KH wrote:
On Mon, Feb 11, 2013 at 12:30:51AM +0100, Daniel Borkmann wrote:
On 02/11/2013 12:24 AM, Joe Perches wrote:
On Sun, 2013-02-10 at 23:00 +0100, Daniel Borkmann wrote:
add memcmp_nta ({n}o {t}iming {a}ttacks)
Why should this be in the kernel?
As the
On 02/09/2013 02:08 AM, Len Brown wrote:
> From: Len Brown
>
> This field is no longer used.
>
> Signed-off-by: Len Brown
Acked-by: Daniel Lezcano
> ---
> include/linux/cpuidle.h | 22 --
> 1 file changed, 22 deletions(-)
>
> diff --g
On 02/09/2013 02:08 AM, Len Brown wrote:
> From: Len Brown
>
> Cosmetic only.
>
> Replace use of MWAIT_MAX_NUM_CSTATES with CPUIDLE_STATE_MAX.
> They are both 8, so this patch has no functional change.
>
> The reason to change is that intel_idle will soon be able
> to export more than the 8 "ma
On 02/10/2013 06:58 AM, Len Brown wrote:
> From: Len Brown
>
> Update APM to register its local idle routine with cpuidle.
>
> This allows us to stop exporting pm_idle to modules on x86.
>
> The Kconfig sub-option, APM_CPU_IDLE, now depends on on CPU_IDLE.
>
> Compile-tested only.
>
> Signed-
On 02/11/2013 07:37 PM, Andy Lutomirski wrote:
On 02/10/2013 02:00 PM, Daniel Borkmann wrote:
If you need to compare a password or a hash value, the timing of the
comparison function can give valuable clues to the attacker. Let's
say the password is 123456 and the attacker tries abcdef. I
On 02/11/2013 08:00 PM, Florian Weimer wrote:
> * Daniel Borkmann:
Thanks for your feedback, Florian!
>> + * memcmp_nta - memcmp that is secure against timing attacks
>
> It's not providing an ordering, so it should not have "cmp" in the
> name.
I agree. Wha
le-tested only.
>
> Signed-off-by: Len Brown
> Cc: Jiri Kosina
> ---
> v2: updates from Daniel Lezcano's review
> ---
> arch/x86/Kconfig | 1 +
> arch/x86/kernel/apm_32.c | 60
> +--
> arch/x86/kern
On 02/12/2013 12:46 AM, Len Brown wrote:
> On 02/11/2013 03:53 AM, Daniel Lezcano wrote:
>> On 02/09/2013 02:08 AM, Len Brown wrote:
>
>>> The reason to change is that intel_idle will soon be able
>>> to export more than the 8 "major" states supported by
On 04/02/2013 08:17 AM, jonghwa3@samsung.com wrote:
> On 2013년 04월 02일 14:00, Daniel Lezcano wrote:
>
>> On 04/01/2013 10:24 AM, Jonghwa Lee wrote:
>>> This patch adds idle state time stamp to cpuidle device structure to
>>> notify its current idle state. If last
ixlets all over from various people.
All together it's been pretty quiet thus far.
Cheers, Daniel
The following changes since commit a937536b868b8369b98967929045f1df54234323:
Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)
are available in the git repository at:
git://people.freedesktop.
On 04/02/2013 11:37 AM, jonghwa3@samsung.com wrote:
> On 2013년 04월 02일 16:34, Daniel Lezcano wrote:
>
>> On 04/02/2013 08:17 AM, jonghwa3@samsung.com wrote:
>>> On 2013년 04월 02일 14:00, Daniel Lezcano wrote:
>>>
>>>> On 04/01/2013 10:24 AM, Jon
On 04/02/2013 01:07 PM, jonghwa3@samsung.com wrote:
> On 2013년 04월 02일 19:08, Daniel Lezcano wrote:
>
>> On 04/02/2013 11:37 AM, jonghwa3@samsung.com wrote:
>>> On 2013년 04월 02일 16:34, Daniel Lezcano wrote:
>>>
>>>> On 04/02/2013 08:17 AM, jong
grab a
lock simply do a blocking wait. So ticket/reservation in Maartens
patches is the analog of timestamp/transaction.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe l
it ...
In any way I think that all three approaches should fit into the
proposed interfaces, so we should be able to do something sane here.
But since I have pretty much zero clue about rt I have no idea which
of the first two approaches would be preferable.
Cheers, Daniel
--
Daniel Vetter
Softwar
I didn't study cs, but judging from your phrasing I guess you mean you
>> want me to call it transaction_mutexes instead?
>
> Nah, me neither, I just hate reinventing names for something that's
> already got a perfectly fine name under which a bunch of people know
> it.
>
quot;") from Linus' tree and commit
> 31ad8ec6a614 ("drm/i915: group backlight related stuff into a struct")
> from the drm-intel tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, I carry the same me
On Wed, Apr 3, 2013 at 12:28 PM, Matt Fleming wrote:
>
> On 30/03/13 10:04, Daniel Vacek wrote:
> >
> > Resending patch. It got lost somewhere. Thanks for pushing Ben.
>
> I applied this by hand. Your patch appears to be whitespace damaged.
You're right. Sorry f
of a task for deadlock-breaking with
-EAGAIN. The problem is that through PI boosting or normal rt-prio changes
while tasks are trying to acquire ww_mutexes you can create acyclic loops
in the blocked-on graph of ww_mutexes after the fact and so cause
deadlocks. So we've convinced ourselves th
On Thu, Apr 4, 2013 at 3:31 PM, Daniel Vetter wrote:
>> In this case when O blocks Y isn't actually blocked, so our
>> TASK_DEADLOCK wakeup doesn't actually achieve anything.
>>
>> This means we also have to track (task) state so that once Y tries to
>>
On Thu, Apr 4, 2013 at 6:38 PM, Peter Zijlstra wrote:
> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
>> Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the
>> wait
>> times of older task.
>
> No, imagine the following:
>
> struc
On Thu, Apr 4, 2013 at 6:49 PM, Peter Zijlstra wrote:
> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
>> We've discussed this approach of using (rt-prio, age) instead of just
>> age
>> to determine the the "oldness" of a task for deadlock-breaking
Hi,
First of all, thank you for your comments!
On 04/04/2013, at 10:12 PM, Arnd Bergmann wrote:
> For new platforms, we want to have only the absolute minimum amount of
> code in arch/arm and move everything else into drivers. However, that
> is only possible using device tree. It should not ad
ut even with versioning, Tux3 still upholds the single-reference
rule, therefore our fsck problem will continue to look a lot more like Ext4 than
like Btrfs or ZFS. Which suggests some great opportunities for unabashed
imitation.
Regards,
Daniel
--
To unsubscribe from this list: send the line &q
just the '-bpp' and not a full mode, but I haven't
tested. Look for cmdline_mode->bpp_specified in drm_fb_helper.c and the
relevant parsing code in drm_mode_parse_command_line_for_connector in
drm_modes.c
If that doesn't work for you, I think it's better to extend/fix it than
On Tue, Jan 29, 2013 at 10:57 AM, Takashi Iwai wrote:
> At Tue, 29 Jan 2013 10:53:50 +0100,
> Daniel Vetter wrote:
>>
>> On Tue, Jan 29, 2013 at 09:29:17AM +0100, Takashi Iwai wrote:
>> > Add a new option, bpp, to specify the default bpp value.
>> &
On Mon, Jan 28, 2013 at 06:06:38PM +0800, Zhang Rui wrote:
> On Mon, 2013-01-28 at 09:31 +0100, Daniel Vetter wrote:
> > On Mon, Jan 28, 2013 at 3:36 AM, Zhang Rui wrote:
> > >> Given that this essentially requires users to manually set this module
> > >> optio
or otherwise userspace could trick the kernel into creating
a circular fence chain. This wouldn't deadlock the kernel, since
everything is async, but it'll nicely deadlock the gpus involved.
Hence why we need ticketing locks to get dma_buf fences off the
ground.
Maybe wait for
somehow both are fixed with the locking. I'm a bit confused
how these issues could cause failures in the flip tests, but alas:
Tested-by: Lu Hua (for all three patches).
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from th
On Wed, Jan 30, 2013 at 10:52 PM, Russell King wrote:
> Also adding Greg and Daniel to this as Daniel introduced the lockdep
> checking.
>
> This looks extremely horrid to be to solve - the paths are rather deep
> where the dependency occurs. The two paths between the locks are:
&
this issue...
Linus was the guy who shot down the patches for 3.9 since one of the
earlier iterations caused instant deadlocks - I've been pushing them
to merge them ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe
> console_lock, and make re-enabling it part of the patch-series that
>> fixes the locking.
>>
>> Daniel/Dave? Does that sound reasonable?
Yeah, sounds good.
> Reverting the patch is fine with me. Just let me know so I can queue it
> up again for 3.9.
Can you please also pick
1 - 100 of 20726 matches
Mail list logo
