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
it is not complete.
I only see signs of drm/nouveau, not the i915 driver in your logs. So
definitely something else.
Yours, 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
t
> available,
> reverting the patch seems to be the way to go (otherwise me and others with
> the same problem won't be able to run the upstream kernel on affected boards).
>
> Cc: Jesse Barnes
> Cc: Daniel Vetter
> Cc: Mika Kuoppala
> Signed-off-by: Guenter Roeck
abled, since
> this condition can result in secondary issues.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60541
> Cc: Jesse Barnes
> Cc: Daniel Vetter
> Cc: Mika Kuoppala
> Signed-off-by: Guenter Roeck
Picked up for -fixes, thanks for the patch.
-Daniel
--
Daniel
ble at driver load time will allow us to get rid
of tons of ulgy
if (dev_mapping)
unmap_mapping_rang(dev_mapping, ...);
code sprinkled all over drm core and drivers. So
Wanted-by: Daniel Vetter
> ---
> fs/anon_inodes.c| 36 +
to me whether some of the
> old drivers might depend on this (for what reason?), but I remember Daniel
> told me that i810 might.
i915 in gem+ums mode might. i810 is a different level of horror show
entirely, but since it doesn't do gem we can ignore it here.
>
> Tested with nouveau
;ve added this in
commit b6e45f866465f42b53d803b0c574da0fc508a0e9
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
>
> Regard
the new shrinker api in 3.12, I
simply 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_bu
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 r
(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 o
81e49f or will 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 ma
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
userspace 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
> >
>
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 V
type,
> @@ -33,4 +33,9 @@ static inline 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/inc
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
ady gets 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/
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
for the selected 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 Vett
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
> >
copies stuff into a
temp allocation and then continues. At 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'
stra
Cc: Linux 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
++
fer objects - in i915 we have just one lock
and so suffer quite 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 li
: Linux Kernel Mailing List
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d80f33d..3871060 100644
--- a/drivers/gpu/drm/i915
p into slowpath" fasion, at least in drm/i915.
-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
hink for ttm drivers it's just execbuf being exploitable. But on
drm/i915 we've
had the same issue with the pwrite/pread ioctls, so a simple
glBufferData(glMap) kind of recursion from gl clients blew the kernel
to pieces ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0
rt performance, with either blocking or the yield spinning loop.
-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 major
be mmaped 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-ke
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
d more
important good assurance 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
and proper slowpaths
using copy_*_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 linu
nd all copy_*_user
callsites 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 - ht
x27;s usage with a trylock+yield is a 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
tions.
Reported-by: kbuild test robot
Cc: kbuild test robot
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Daniel Vetter
---
A quick ack for merging this this through the drm-intel tree
On Thu, Aug 29, 2013 at 01:11:07PM -0700, Joe Perches wrote:
> The helper exists, might as well use it instead of __GFP_ZERO.
>
> Signed-off-by: Joe Perches
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57
On Tue, Aug 27, 2013 at 01:49:08PM -0500, H. Peter Anvin wrote:
> If noone hers to them first poke me tomorrow. On an aircraft right now.
As discussed on irc I've pulled these in through drm-intel-next trees.
Should show up in the next linux-next.
-Daniel
--
Daniel Vetter
Software
es looks good to me.
>
> Reviewed-by: Ville Syrjälä
Merged to dinq with Dave's irc-ack. I'll shuffle my tree a bit so that
this will be part of my 3.12 latecomers pull request to Dave.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.
ev, VGA_RSRC_LEGACY_IO |
> > + VGA_RSRC_LEGACY_MEM |
> > + VGA_RSRC_NORMAL_IO |
> > + VGA_RSRC_NORMAL_MEM);
> > + vga_put(dev->pdev, VGA_RSRC_LEGACY_I
>
> 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 li
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:/
> > > [ 354.803142] [] ? 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 ]---
> > >
> > >
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
--
Da
t 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 relevant maili
;
> 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 d
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://blo
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 +02
roblem and
then 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'
helpers.
So if you driver has special needs wrt irq handling that don't neatly fit
what the drm_irq stuff provides, simply don't use it - all the generic
code that's there is just to keep non-kms userspace going.
Yours, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile:
and the driver hooks that drm_irq_install does is really just to support
old dri1 userspace.
Yours, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to major
rm_irq
> interface more flexible.
>
> The changes include:
> 1/ Change the request_irq to request_thread_irq, and add new callback
>irq_handler_t;
> 2/ Normally we need IRQF_ONESHOT flag support for irq thread, so add
>this option in drm_irq;
>
> Cc: Shi Yang
eem to work on 3.5, I haven't gotten any regression reports for gm45
on 3.5 (and these boxes are rather popular). And all the people who
reported issues with this patch on 3.4 had no such problems on 3.5
(with the same patch applied).
And I've looked again at the patches in that area and don&#x
el-next, 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://vger.kernel.o
--git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 35926ad..fc6683a 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3658,7 +3658,6 @@ i915_gem_entervt_ioctl(struct drm_device *dev, void
> *data,
>
> BUG_ON(!list
On Thu, Oct 4, 2012 at 4:56 PM, Daniel Vetter wrote:
> This should help: https://patchwork.kernel.org/patch/1436231/
>
> It's not merged yet since it cause a black screen on resume on one of
> my really old machines. Issue isn't new at all, but the new modeset
> code
_early_param+0x83/0x83
> [0.646643] [] ? schedule_tail+0x21/0xb0
> [0.646644] [] ? rest_init+0x70/0x70
> [0.646645] [] ? ret_from_fork+0x7c/0xb0
> [0.646646] [] ? rest_init+0x70/0x70
> [0.646650] ---[ end trace ed6fe7a7042b42d8 ]---
> [ 0.702400] [drm:intel_di
hw+sw (e.g.
crap left behind by the bios ...) and coverage seemed to be a poor
proxy for that. Hence why I wonder what you're doing with this data
...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send
d whether any of them still
work on 3.7)?
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.o
Including a bunch more lists to the cc.
On Sun, Dec 2, 2012 at 12:42 PM, Daniel Vetter wrote:
> On Sun, Dec 2, 2012 at 12:32 PM, Tom St Denis
> wrote:
>> I've narrowed it down to sometime between v3.6.8 and v3.7-rc1. So none of
>> the v3.7 series will work with this GP
he X driver that
you want a different backlight driver in the xorg.conf (Option
"Backlight" "intel_backlight" should do the trick).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this
pat ioctl code which copies the old 32bit
struct into the 64bit struct the kernel understands. Hence your ioctl
must be laid out exactly the same for both 32bit and 64bit, which
happens if you naturally align/pad everything to 64bits and only use
fixed-sized integers and no pointers.
-Daniel
--
Dan
s. Atm we're trying to come up
with ways to dump more debug information, but with no clue whatsoever
what's going on that's slow-going.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from thi
On Tue, Dec 04, 2012 at 01:35:22PM +0100, Heinz Diehl wrote:
> On 04.12.2012, Daniel Vetter wrote:
>
> > Yeah, if anyone can somewhat reliably reproduce this
>
> Ok, I see. So the beginning would be to reliably reproduce the the
> hang. I have encountered it in any possbile
Hence
also why we're asking everyone who can still reproduce to try a
bisect, since with rc6 disabled we've can't reproduce the hang any
more (beforehand we could reproduce it on 3 different ilk machines).
The important part is to not enable rc6 (on ironlake at least) when
bisect
it
> was caused by relatively low memory pressure combined with high I/O (caching?
> delays? Who knows).
Nope, we could only reproduce quickly with rc6 enabled :(
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from t
yond
calling request_irq() itself.
So feel free to burn this down, I'll be happy to carry wood to the
pyre in the from of reviews (not much time for more right now ...).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To u
On Wed, Dec 5, 2012 at 1:03 PM, Daniel Vetter wrote:
> On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergström
> wrote:
>> You're right in that binding to a sub-device is not a nice way. DRM
>> framework just needs a "struct device" to bind to. exynos seems to solve
y, creating a
depency on the tegradrm module. When trying to unload host1x it can
then also call down into tegradrm to tear down the drm device.
Afterwards you should be able to unload tegradrm without fuzz. And if
the hard dependcy is an issue for other host1x clients this
setup/teardown cou
lpers to make those not a pain to
call). The other possibility (and I'm not proud at all of that code)
which we've used in the intel-ips driver is to use symbol_get at
runtime - but there the requirement was explicitly that intel-ips
needs to work on server systems without the drm/i915 driver loaded
On Mon, Oct 15, 2012 at 5:11 PM, Greg KH wrote:
> On Mon, Oct 15, 2012 at 10:11:22AM +0200, Daniel Vetter wrote:
>> Hi Greg&stable-team,
>>
>> The below patch papers over a graphics corruption issue in 3.5/3.6. The
>> regression happened due to pwrite tunings in
actor so that saved_mode and saved_hwmode are dynamically allocated as
> > opposed
> > to being automatic variables. 500 bytes seems like it could run the
> > potential for blowing
> > the kernel stack.
>
> Reviewed-by: Jani Nikula
Queued for -next, thanks for the p
d with
commit b4a98e57fc27854b5938fc8b08b68e5e68b91e1f
Author: Chris Wilson
Date: Thu Nov 1 09:26:26 2012 +
drm/i915: Flush outstanding unpin tasks before pageflipping
available from the drm-next (or linux-next) trees. If it holds up once
merged, we'll backport it.
-Daniel
--
Dan
checksum field at byte 4. All intel hw computes the ECC itself, but
some want us to store the infoframe with an empty ECC byte as
placeholder, whereas others (sdvo encoders) insert that byte
themselves, i.e. the infoframe is actually one byte shorter. In any
case, that kind of mangling can be
ing in such a fashion, so ideas highly welcome. QA people are
cc'ed, and hopefully I haven't missed anyone else on the cc list.
Yours, 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 &qu
struct drm_display_mode *mode);
>
> /*
> * Packs the struct hdmi_avi_infoframe into a binary buffer that can be
> * programmed to the hardware-specific registers.
> */
> ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame,
>
file a bug report against DRM -> DRI/Intel and please attach the
i915_error_state from debugfs after your gpu hung).
Yours, 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-ker
ang needs it's own bug (until we've analyzed the
error_state and triaged the bug taking other evidence into account).
Also, this is on a different gpu generation, so even more likely that
it's a different kind of hang.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Cor
ed by Aaron Plattner. We might want to do similar checks for
attachments, but that's for another patch. Also fix up ERR_PTR return
for vmap.
Cc: Aaron Plattner
Signed-off-by: Daniel Vetter
---
Compile-tested only - Aaron has been bugging me too a bit too often
about this on irc.
Chee
o the kmap functions there's no need for the vaddr for
unmapping. Suggested by Chris Wilson.
Cc: Aaron Plattner
Signed-off-by: Daniel Vetter
---
Compile-tested only - Aaron has been bugging me too a bit too often
about this on irc.
Cheers, Daniel
---
Documentation/dma-buf-sharing.txt | 6 +
o the kmap functions there's no need for the vaddr for
unmapping. Suggested by Chris Wilson.
v4: Fix a brown-paper-bag bug spotted by Aaron Plattner.
Cc: Aaron Plattner
Signed-off-by: Daniel Vetter
---
Documentation/dma-buf-sharing.txt | 6 +-
drivers/base/dma-buf.c
the primary plane
drm/i915: Error out when trying to set a y-tiled as a sprite
drm/i915: Fix primary plane offset on HSW
drm/i915: Fix sprite offset on HSW
drm/i915: adjust sprite base address
drm/i915: Flush using only the correct base address register
Daniel Ve
no need to merge them through the intel tree.
-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
On Wed, Apr 10, 2013 at 12:28 AM, Steven Rostedt wrote:
> On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote:
>> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
>> > The thing is now that you're not expected to hold these locks for a
>> >
all over the place. So I think the backtrace you see
there is actually a secondary effect. I've looked into fixing this up,
but the issue is that drivers themselves have tons of state protected
with mutexes, which all potentially affects the panic handler. So I've
given up on that for
tree, so:
Acked-by: Daniel Vetter
on the i915 parts of it. If you want I can also slurp them in through the
intel tree, including the new dmi match code.
Thanks, Daniel
>
> On Thu, 06 Jun 2013, Jani Nikula wrote:
> > Hi Greg, Andrew -
> >
> > Patch 1 is for DMI, bugfix
On Fri, Jun 14, 2013 at 6:23 PM, Greg Kroah-Hartman
wrote:
> On Thu, Jun 13, 2013 at 10:22:05AM +0200, Daniel Vetter wrote:
>> On Thu, Jun 06, 2013 at 04:59:26PM +0300, Jani Nikula wrote:
>> >
>> > With Greg's address fixed. Please drop the old one from any
&
nd
doesn't just use that as a fallback 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
--
Dani
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:
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
get 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 d
|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.c
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-buf a
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.
> > >
>
t; amount of PFNs that can be combined together - but with this issue
> discovered during rc7 that might be too risky.
>
> Reported-and-Tested-by: Konrad Rzeszutek Wilk
> CC: Chris Wilson
> CC: Imre Deak
> CC: Daniel Vetter
> CC: David Airlie
> CC:
> Signed-off
On Mon, Jun 24, 2013 at 7:32 PM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Jun 24, 2013 at 07:09:12PM +0200, Daniel Vetter wrote:
>> On Mon, Jun 24, 2013 at 11:47:48AM -0400, Konrad Rzeszutek Wilk wrote:
>> > Git commit 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4
>> > (&q
t; amount of PFNs that can be combined together - but with this issue
> discovered during rc7 that might be too risky.
>
> Reported-and-Tested-by: Konrad Rzeszutek Wilk
> CC: Chris Wilson
> CC: Imre Deak
> CC: Daniel Vetter
> CC: David Airlie
> CC:
> Signed-of
ind of complex policy
> 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
Sof
101 - 200 of 3914 matches
Mail list logo
