from userspace, so needs to be moved both in the fault
handler and then back for the execbuf to continue ;-)
-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&qu
On Thu, Sep 12, 2013 at 05:59:51PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 12, 2013 at 05:57:28PM +0200, Daniel Vetter wrote:
> > This is just a remnant from the old days when our reset handling was
> > horribly racy, suffered from terribly locking issues and often happily
urance that any regressions in this tricky code will
get caught.
Cheers, 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 body of a m
py_*_user everywhere instead of trying to pin the userspace
storage with get_user_pages.
-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 body of
allsites that already hold a bo_reserve ww_mutex. At least that's
been my conclusion after much head-banging against this issue for
drm/i915, and we've tried a lot approaches ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsub
different form of duct-tape to
paper over locking inversions between copy_*_user callsites and the
pagefault handler.
In any case there's no way it actually works properly ;-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To u
c574da0fc508a0e9
Author: Keith Packard
Date: Fri Jan 6 11:34:04 2012 -0800
drm/i915: Move reset forcewake processing to gen6_do_reset
Reverting this change should be enough (code moved obviously a bit).
Cheers, Daniel
>
> Regards,
> Peter Hurley
>
>
>
>>
ply haven't rolled my trees forward yet. In any case I just want to
get the discussion started on this.
Cc: Glauber Costa
Cc: Andrew Morton
Cc: Rik van Riel
Cc: Mel Gorman
Cc: Johannes Weiner
Cc: Michal Hocko
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69247
Signed-off-by: Daniel Vet
On Wed, Sep 18, 2013 at 12:38:23PM +0200, Knut Petersen wrote:
> On 18.09.2013 11:10, Daniel Vetter wrote:
>
> Just now I prepared a patch changing the same function in vmscan.c
> >Also, this needs to be rebased to the new shrinker api in 3.12, I
> >simply haven't rolled
at
0x4 (i.e. forcewake is only used for the rendering side of
things). For those platforms the DPLL macro is called PCH_DPLL (and
it's in the south display range starting at 0xc. VLV itself
inherited the old display register blocks (mostly) but moved them all
by the vlv display base offset
the early return 0; completely upset
the core shrinker logic?
-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 body of a message to majord...@vger.ke
eason: PAGE_NOT_PRESENT
> >
> > I will try next with the patch series you sent to Linus yesterday, to
> > see if that happens to fix this.
>
> Nope, with your patch series from yesterday the problem still exists.
Just to double-check: Does the revert still work, ev
git around to bisecting it.
> This is the commit that introduces the warning.
>
> commit 9f11a9e4e50006b615ba94722dfc33ced89664cf
> Author: Daniel Vetter
> Date: Thu Jun 13 00:54:58 2013 +0200
>
> drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms
My apologies
ted display to avoid the
> flicker?
>
> Any help would be appreciated.
>
> Greetings,
> Thomas
>
--
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
On Mon, Sep 23, 2013 at 12:33:04AM +0200, Thomas Richter wrote:
> On 22.09.2013 22:03, Daniel Vetter wrote:
> >Hm, that sounds a bit more like the ddx is having fun with rendering.
> >Have you tried switching the backed from to either SNA or UXA? Also
> >adding r
;
> On 10.09.2013 11:44, Daniel Vetter wrote:
> >The native TV encoder has it's own flags to adjust sync modes and
> >enabled interlaced modes which are totally irrelevant for the adjusted
> >mode. This worked out nicely since the input modes used by both the
> >load detect
I've completely missed thus far: Does the flicker
only happen when you pan, or also when the image is at a stable postion
(but not aligned to one of the safe boundaries you've identified)?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
p 13-09-13 11:00, Peter Zijlstra schreef:
> >>>>On Fri, Sep 13, 2013 at 10:41:54AM +0200, Daniel Vetter wrote:
> >>>>>On Fri, Sep 13, 2013 at 10:29 AM, Peter Zijlstra
> >>>>>wrote:
> >>>>>>On Fri, Sep 13, 2013 at 09:46:03AM
SE Linux) ) #34
> PREEMPT Fri Sep 6 09:46:35 CEST 2013
http://cgit.freedesktop.org/~danvet/drm-intel/commit/?id=4c6df4b4ca1b26f4532d403b544f649a1c801fd1
could be of interest for you. If that doesn't help please boot with
drm.debug=0xe and attach the complete dmesg.
Thanks, Daniel
--
Daniel Vetter
ne int acpi_video_get_edid(struct acpi_device
> *device, int type,
> }
> #endif
>
> +static inline int acpi_video_register(void)
> +{
> + return __acpi_video_register(false);
> +}
> +
> #endif
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index a5db4ae..a0
On Mon, Sep 09, 2013 at 02:16:12PM +0200, Rafael J. Wysocki wrote:
> Hi,
>
> On Monday, September 09, 2013 11:32:10 AM Daniel Vetter wrote:
> > Hi Aaaron,
> >
> > Have we grown any clue meanwhile about which Intel boxes need this and for
> > which we still need
ets this right).
Reported-by: Knut Petersen
Cc: Knut Petersen
References:
http://www.gossamer-threads.com/lists/linux/kernel/1778688?do=post_view_threaded
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i
On Tue, Sep 10, 2013 at 10:41:33AM +0200, Knut Petersen wrote:
> On 10.09.2013 10:02, Daniel Vetter wrote:
> >Instead of just a flag bit for each of the positive/negative sync
> >modes drm actually uses a separate flag for each ... This upsets the
> >modeset checker since the
d TV mode.
So we'll happily fall over if userspace tries to pull us. But that's
definitely work for a different patch series. So just add a FIXME
comment for now.
Reported-by: Knut Petersen
Cc: Knut Petersen
Cc: Imre Deak
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/
On Tue, Sep 10, 2013 at 11:24:52AM +0300, Ville Syrjälä wrote:
> On Tue, Sep 10, 2013 at 10:02:48AM +0200, Daniel Vetter wrote:
> > Instead of just a flag bit for each of the positive/negative sync
> > modes drm actually uses a separate flag for each ... This upsets the
> >
least that's how we've fixed
all those inversions in i915-gem. I'm not volunteering to fix this ;-)
The one in udl just looks like copypasta from i915, without any
justification (at least I don't see any) for why it's there. Probably
can die, too, since there isn't any gpu to reset on usb display-link
dev
Kernel Mailing List
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/udl/udl_gem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index 8dbe9d0..8bf6461 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu
ite a bit more from contention. So no idea how much
removing the yield would hurt.
-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 body of a mes
. I think we
need a DMI_EXACT_MATCH. I haven't found out whether the D410PT board also
has such a cousin, so please digg in a bit for me.
Thanks, Daniel
> + },
> + },
> + {
> + .callback = intel_no_lvds_dmi_callback,
> .ident = "Supermicro X7SPA-H&qu
10PLTW don't.
>
> Any reason you don't want this in the stable tree as well?
None. Picked up for -fixes, thanks for the patch. Also I prefer the patch
change log in the commit message proper and less screaming in the summary
;-) All fixed while applying.
-Daniel
--
Daniel Vetter
Software En
all to make ?
> Did I get this wrong ?
Maintainer occasionally fumble it, so it's better when the patch submitter
also thinks about this. I can always change it when I disagree ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubsc
>
> Signed-off-by: Kamal Mostafa
Nack. Piling quirk over quirk isn't the right approach and I think I
should just revert the pch_pwm enable quirk again.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this
pace already has an fd, expose the size using the
> >size = lseek(fd, SEEK_END, 0); lseek(fd, SEEK_CUR, 0);
> >idiom.
> >
> >v2: Added Daniel's sugeested documentation, with minor fixups
> >
> >Signed-off-by: Christopher James Halse Rogers
> >
> >Revi
if (HAS_PCH_SPLIT(dev)) {
> + if (HAS_PCH_SPLIT(dev) &&
> + !(dev_priv->quirks & QUIRK_NO_PCH_PWM_ENABLE)) {
> tmp = I915_READ(BLC_PWM_PCH_CTL1);
> tmp |= BLM_PCH_PWM_ENABLE;
>
dev->mode_config.max_height = 8192;
> }
> +
> + if (IS_GEN7(dev))
> + dev->mode_config.async_page_flip = true;
> +
> dev->mode_config.fb_base = dev_priv->gtt.mappable_base;
>
> DRM_DEBUG_KMS("%d display pipe%s avai
e.g. starving the unpin workers.
Oh and my little comment about moving all checks into core code is a bit
wrong, we'd still need to check for X-tiling with async flips ofc.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscr
ble south
interrupts when handling them
Just in case you want to give it a quick whirl. Since the failed dp aux
transaction caused the resume modeset to fail for you (resulting in the
black screen) I hope that this should fix both issues.
I'll forward the pull to Dave in a few days since atm I'm s
nce wise.
For performance reasons we want to also use get_user_pages_fast, so I
don't think mixing that together with the "please migrate out of CMA"
trick here is a good thing.
Current drm/i915 wip patch is at: https://patchwork.kernel.org/patch/1748601/
Just my 2 cents on this ent
and the bus is stable.
Can you please retest with latest drm-intel-fixes merged into -rc1?
Paulo's patch fixes a race in handling PCH interrupts (where the gmbus
hw is) which matches rather well with your description here.
Thanks, Daniel
> commit 2c438c0273b76d6cb158f8bdd0aa3ebf66e48a28
>
; >"To guarantee CMA can migrate pages pinned by drivers I think you need
> >migrate-related callsbacks to unpin, barrier the driver until migration
> >completes and repin."
>
> Right, this might improve the migration reliability. Are there any works
> being done in
attach the complete dmesg? Please make sure dmesg contains everything
since boot-up, if not please increase the dmesg buffer size with
log_buf_len=4M.
Also please test the latest drm-intel-fixes release to check that we
haven't just forgotten to send the patch to stable (there's at least one
flags mis
On Fri, Sep 27, 2013 at 7:27 PM, Woody Suwalski wrote:
> Daniel Vetter wrote:
>>
>> On Thu, Sep 26, 2013 at 2:36 PM, Woody Suwalski
>> wrote:
>>>
>>> Daniel, I have noticed these warnings on 3.12-rc1, did not go away on
>>> 3.12-rc2.
>
esting the patch.
-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 body of a message to majord...@vger.kernel.org
More majordomo info at http:/
3142] [] ? kthread_create_on_node+0x120/0x120
> > > [ 354.803144] [] ret_from_fork+0x7c/0xb0
> > > [ 354.803145] [] ? kthread_create_on_node+0x120/0x120
> > > [ 354.803145] ---[ end trace 590553ce6c6f5fa9 ]---
> > >
> > > --
> > > Micr
On Mon, Sep 30, 2013 at 1:26 PM, Thierry Reding
wrote:
> Today's linux-next merge of the drm-intel tree got conflicts in
>
> drivers/gpu/drm/i915/intel_display.c
>
> I fixed it up (see below). Please check if the resolution looks correct.
Looks good.
-Daniel
--
Daniel
y
> decision that's best left to userspace, which is where it should have
> been to begin with.
Do we have any chances to amend this mistake by (gradually) phasing
out support for the direct keypress forwarding in ACPI? Or at least
some plans?
-Daniel
--
Daniel Vetter
Software Engineer, Intel
>> [ 2097.548517] [] async_resume+0x21/0x50
>> [ 2097.548524] [] async_run_entry_fn+0x3b/0x140
>> [ 2097.548529] [] process_one_work+0x16e/0x3f0
>> [ 2097.548534] [] worker_thread+0x122/0x370
>> [ 2097.548540] [] ? rescuer_thread+0x330/0x330
>> [ 2097.548544] [
in.
I'd prefer all to go through the same tree (to avoid tracking them), and
conflicts around lvds quirks will be trivial at most. So no problem for me
if this doesn't go in through drm-next. So
Acked-by: Daniel Vetter
on the i915 patches for merging through whatever tree the drm stuff goes
t
iginal issue.
The locking in the current drm panic handler is pretty much terminally
broken. At best we're trying not too flood dmesg too badly when it
happens.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: s
ll through the acpi
tree. So
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_dma.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 3b315ba..23b6292 100644
> --- a/drivers/gpu/drm
llback if the xrandr backligh property isn't
available, then that's just a serious bug in gnome and should be fixed
asap. But imo that's not something we should try to (nor do I see any way
how to) work around in the kernel.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0)
On Sat, Jun 15, 2013 at 10:27:06PM +0200, Rafael J. Wysocki wrote:
> On Saturday, June 15, 2013 08:29:42 PM Daniel Vetter wrote:
> > Hi all,
> >
> > So to me it looks like the discussion is going in circles a bit, hence let
> > me drop my maintainer-opinion here:
bal' atomic is ok, if/when we find
> it hurts performance we can revisit. I was just spewing ideas :-)
We could do a simple
ctx->stamp = (local_clock() << nr_cpu_shift) | local_processor_id()
to work around any bad luck in grabbing the ticket. With sufficient
fine clocks the bias
On Mon, May 27, 2013 at 4:47 PM, Daniel Vetter wrote:
> On Mon, May 27, 2013 at 10:21 AM, Peter Zijlstra wrote:
>> On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
>>> >> +static inline void ww_acquire_init(struct ww_acquire_ctx *ctx,
>>> >&g
On Tue, May 28, 2013 at 05:51:44PM +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fix to return -ENOMEM in the kmap() error handling case
> instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun
Queued for -next, thanks for the patch.
-Daniel
LOCKTYPE_WW);
> + printk("\n");
> +
> + print_testname("spinlock nest unlocked");
> + dotest(ww_test_spin_nest_unlocked, FAILURE, LOCKTYPE_WW);
> + printk("\n");
> +
> + printk("
platform information to implemented workarounds
drm/i915: Add references to some workaround we implement
drm/i915: Compute WR PLL dividers dynamically
drm/i915: Add missing platform tags to FBC workaround comments
Daniel Vetter (56):
drm/i915: don't enable the plane too early
ght lock.
>>
>> Otherwise I didn't spot anything that seems missing in these self-tests
>> here.
>>
> Yes it would be nice, doing so is left as an excercise for the reviewer, who
> failed to raise this point sooner. ;-)
Hm, I guess I've volunteered myself to look into t
1 +
> drivers/gpu/drm/udl/udl_gem.c |1 +
> include/linux/dma-buf.h|4 +++
> 6 files changed, 52 insertions(+), 5 deletions(-)
>
> --
> 1.7.4.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
On Fri, May 31, 2013 at 07:22:24PM +0900, 김승우 wrote:
> Hello Daniel,
>
> Thanks for your comment.
>
> On 2013년 05월 31일 18:14, Daniel Vetter wrote:
> > On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim
> > wrote:
> >> importer private data in dma-bu
On Fri, May 31, 2013 at 06:21:09PM +0200, Lucas Stach wrote:
> Am Freitag, den 31.05.2013, 17:29 +0200 schrieb Daniel Vetter:
> > On Fri, May 31, 2013 at 07:22:24PM +0900, 김승우 wrote:
> > > Hello Daniel,
> > >
> > > Thanks for your comment.
> > >
>
On Tue, Jun 04, 2013 at 07:42:22PM +0900, 김승우 wrote:
>
>
> On 2013년 06월 01일 00:29, Daniel Vetter wrote:
> > On Fri, May 31, 2013 at 07:22:24PM +0900, 김승우 wrote:
> >> Hello Daniel,
> >>
> >> Thanks for your comment.
> >>
> >> On 2013년 05
On Wed, Jun 05, 2013 at 11:52:59AM +0900, 김승우 wrote:
>
>
> On 2013년 06월 04일 21:55, Daniel Vetter wrote:
> > On Tue, Jun 04, 2013 at 07:42:22PM +0900, 김승우 wrote:
> >>
> >>
> >> On 2013년 06월 01일 00:29, Daniel Vetter wrote:
> >>> On Fri, May
hread_create_on_node+0x150/0x150
>
> ___________
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.f
On Wed, May 22, 2013 at 1:24 AM, Dave Jones wrote:
> On Wed, May 22, 2013 at 01:10:36AM +0200, Daniel Vetter wrote:
> > On Wed, May 22, 2013 at 1:01 AM, Dave Jones wrote:
> > > This is new to me as of 3.10-rc2.
> >
> > If this is an ironlake with a DP output
n the
>> next patch.
>> - Updated documentation slightly.
>> Changes since v2:
>> - Renamed everything to ww_mutex. (mlankhorst)
>> - Added ww_acquire_ctx and ww_class. (mlankhorst)
>> - Added a lot of checks for wrong api usage. (mlankhorst)
>>
On Wed, May 22, 2013 at 11:07:09PM +0200, Thomas Meyer wrote:
>
> Signed-off-by: Thomas Meyer
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send th
bit
what to do, and I don't there's much we can do in the implementation
(beside all the existing debug support we have) to help. So now I'm
leaning more towards dropping the _slow variants to avoid interface
proliferation.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 4
On Wed, Feb 20, 2013 at 8:45 PM, Chris Li wrote:
> On Wed, Feb 20, 2013 at 2:57 AM, Daniel Vetter wrote:
>
>> Starts to smell like a bog-standard i915 black screen bug (albeit with
>> a strange cause for the regression). Can you please boot the broken
>> kernels again wit
ve the #if 0 clause?
I guess we could just put this into a comment explaining where stolen
memory for the gfx devices is at on gen2. But tbh I don't mind if we just
keep the #if 0 code around. For all newer platforms we can get at that
offset through mch bar registers, so I don't really care.
-Dani
On Sun, Mar 10, 2013 at 02:22:48PM +0200, Mihnea Dobrescu-Balaur wrote:
> Signed-off-by: Mihnea Dobrescu-Balaur
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this l
GEN6_MBC_SNPCR_SHIFT);
> -
> - if (len > sizeof(buf))
> - len = sizeof(buf);
> + *val = (snpcr & GEN6_MBC_SNPCR_MASK) >> GEN6_MBC_SNPCR_SHIFT;
>
> - return simple_read_from_buffer(ubuf, max, ppos, buf, len);
> + return 0;
> }
>
On Mon, Mar 11, 2013 at 02:37:35PM -0700, Kees Cook wrote:
> This clarifies the comment above the access_ok check so a missing
> VERIFY_READ doesn't alarm anyone.
>
> Signed-off-by: Kees Cook
> Cc: Daniel Vetter
> ---
> v2:
> - rewrote comment, thanks to Chris Wilson
..@vger.kernel.org
Picked up for -fixes, thanks for the patch.
-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 body of a message to majord...@vger.ke
On Mon, Mar 11, 2013 at 10:46:31PM -0700, Kees Cook wrote:
> This replaces the open-coded divisions in the debugfs code by calls
> to do_div().
>
> Signed-off-by: Kees Cook
> Cc: Daniel Vetter
Squashed into the debugfs patch which introduced this regression, thanks
for the quick
> I have reverted that commit for today.
Should be fixed now, thanks for the report (and my apologies for the
little screw-up).
-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 "uns
ether we should
> just collapse the two variables into one, but the current 'max - count'
> is more idiomatic and so preferrable.
> Reviewed-by: Chris Wilson
Picked up for -fixes, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48
On Wed, Mar 13, 2013 at 9:28 PM, Daniel Vetter wrote:
> On Tue, Mar 12, 2013 at 09:07:46AM +, Chris Wilson wrote:
>> On Mon, Mar 11, 2013 at 05:31:45PM -0700, Kees Cook wrote:
>> > It is possible to wrap the counter used to allocate the buffer for
>> > relocat
ever be injected when we managed to
acquire the lock. This prevents any behaviour changes for users which
rely on the EALREADY semantics.
Signed-off-by: Daniel Vetter
---
include/linux/mutex.h |8
kernel/mutex.c| 31 +++
lib/Kconfig.debug
it gets.
So all together I'm pretty happy with what the interface looks like. And
one quick bikeshed below on the implementation.
-Daniel
>
> Signed-off-by: Maarten Lankhorst
> Signed-off-by: Daniel Vetter
> ---
> Documentation/ww-mutex-design.txt | 322
.
Cc: Steven Rostedt
Signed-off-by: Daniel Vetter
---
include/linux/mutex.h |8
kernel/mutex.c| 32
lib/Kconfig.debug | 10 ++
3 files changed, 50 insertions(+)
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index
he tree for today.
Meh, that fail was already reported from Wu's kernel builder a few
days ago, but no patch yet showed up to fix things. Since the i915
side of that work isn't ready yet either I've dropped the offending
patches.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corpo
On Fri, Feb 15, 2013 at 12:27 AM, Stephen Rothwell
wrote:
> Hi Daniel,
>
> On Thu, 14 Feb 2013 15:19:53 +0100 Borislav Petkov wrote:
>>
>> On Thu, Feb 14, 2013 at 03:12:02PM +0100, Daniel Vetter wrote:
>> >
>> > Since about a year ago we've switched drm/i
}
> +#endif /* CONFIG_VT_CONSOLE_SLEEP */
>
> /*
> * Device power management
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/list
abled)
+ continue;
+
+ intel_crtc_restore_mode(crtc);
}
i915_redisable_vga(dev);
The issue is that we save a pointer to the fb (since those are refcounted)
but copy the mode into the crtc struct (since modes are n
On Sun, Feb 17, 2013 at 2:38 PM, Daniel Vetter wrote:
> 2. The new i915 force restore code is indeed missing a safety check
> compared to the old crtc helper based one:
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 6eb38
On Sun, Feb 17, 2013 at 5:31 PM, Hugh Dickins wrote:
> On Sun, 17 Feb 2013, Daniel Vetter wrote:
>> On Sun, Feb 17, 2013 at 3:21 AM, Hugh Dickins wrote:
>> > On Sat, 16 Feb 2013, Hugh Dickins wrote:
>> >> On Sat, 16 Feb 2013, Linus Torvalds wrote:
>> >&g
On Wed, Feb 13, 2013 at 07:40:05PM +0100, Daniel Vetter wrote:
> On Tue, Jan 22, 2013 at 7:55 PM, David Woodhouse wrote:
> > On Mon, 2013-01-21 at 19:48 +0100, Daniel Vetter wrote:
> >> We already have the quirk entry for the mobile platform, but also
> >> reports o
On Tue, Feb 19, 2013 at 3:01 AM, Stephen Rothwell wrote:
> On Fri, 15 Feb 2013 08:16:26 -0800 Jesse Barnes
> wrote:
>>
>> On Fri, 15 Feb 2013 10:30:16 +0100
>> Daniel Vetter wrote:
>>
>> > On Fri, Feb 15, 2013 at 3:37 AM, Stephen Rothwell
>> >
ly works.
Starts to smell like a bog-standard i915 black screen bug (albeit with
a strange cause for the regression). Can you please boot the broken
kernels again with drm.debug=0xe and grab the complete dmesg?
Depending upon how long it takes for your wifi to get up, you might
need to e
On Mon, Jan 13, 2014 at 03:16:42PM -0500, Alan Stern wrote:
> On Wed, 8 Jan 2014, Daniel Vetter wrote:
>
> > On Wed, Jan 08, 2014 at 01:34:02PM -0500, Alan Stern wrote:
> > > On Wed, 8 Jan 2014, Daniel Vetter wrote:
> > >
> > > > On Wed, Jan 08,
On Tue, Jan 21, 2014 at 11:34 PM, wrote:
> From: Daniel Vetter
> Subject: drm/fb-helper: don't sleep for screen unblank when an oops is in
> progress
>
> Otherwise the system will burn even brighter and worse, leave the user
> wondering what's going on exactly.
>
&g
tc(crtc)->pipe,
> ++ i915_get_crtc_scanoutpos(crtc->dev, to_intel_crtc(crtc)->pipe, 0,
> +, , NULL, NULL, false);
> +
> + return vpos;
> + }
> +
> static int i915_get_vblank_timestamp(struct drm_device *dev, int pipe,
>
On Sun, Jan 26, 2014 at 1:51 AM, Imre Deak wrote:
> On Sat, 2014-01-25 at 21:37 +0100, Daniel Vetter wrote:
>> On Fri, Jan 24, 2014 at 02:47:33PM +0200, Imre Deak wrote:
>> > Atm we try to remove the connector's i2c sysfs entry too late in the
>> > encoder's des
l_tree_remove);
> +EXPORT_SYMBOL(interval_tree_iter_first);
> +EXPORT_SYMBOL(interval_tree_iter_next);
Hm, I've thought kernel coding style nowadays is to put the EXPORT_SYMBOL
right below the definition of the function?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79
op.org/patch/18810/
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 body of a message to majord...@vger.kernel.org
More majordomo info at http:/
On Mon, Jan 27, 2014 at 10:30:11AM -0500, Alan Stern wrote:
> On Mon, 27 Jan 2014, Daniel Vetter wrote:
>
> > On Tue, Jan 14, 2014 at 3:43 PM, Alan Stern
> > wrote:
> > > Don't bother. I'll redo it using the drm-intel-nightly branch, but I
> > > won't h
On Mon, Jan 27, 2014 at 11:05:47AM -0500, Alan Stern wrote:
> On Mon, 27 Jan 2014, Daniel Vetter wrote:
>
> > > By the way, I tried getting an up-to-date version of your
> > > drm-intel-nightly branch, and ended up with the following:
> > >
> > >
DRM_DEBUG_DRIVER(" hpd mux info: %s\n",
> +intel_dsm_mux_type(info->buffer.pointer[3]));
> }
>
> -out:
> - kfree(output.pointer);
> + ACPI_FREE(pkg);
> }
>
> static bool intel_dsm_pci_probe(struct pci_dev *pdev)
> {
ioctl will still be
there, but as long as no encoder/connector/crtc/... gets set up by the
driver the only thing userspace can do is create framebuffers. Which
is rather harmless ;-)
And having legacy dev nodes around helps on older userspace (e.g.
X/Prime with dri2 which uses flink).
-Daniel
--
1001 - 1100 of 6575 matches
Mail list logo
