509] [] dpm_run_callback.isra.3+0x3b/0x70
>> [ 2097.548513] [] device_resume+0xd4/0x1b0
>> [ 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+
r original 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 fr
sier to merge this all 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
> -
if (!client) {
> err = -ENOMEM;
> goto fail;
> --
> 1.7.2.5
>
> _______
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Dani
for signal
interrupts, so ioctl restarting is a very natural fit for this.
Resubmitting victim workloads when a gpu crash happened is something
the reset handler would do (kernel work item currently), not any
userspace process doing an ioctl. But atm we don't resubmit victimized
work
On Tue, Jun 11, 2013 at 1:43 PM, Terje Bergström wrote:
> On 11.06.2013 14:00, Daniel Vetter wrote:
>> We don't use the EAGAIN ioctl restarting to resubmit the batchbuffer
>> which blew up the gpu (that one has been submitted already in a
>> different ioctl call), but
On Wed, Jun 12, 2013 at 12:28 PM, Terje Bergström wrote:
> On 11.06.2013 15:09, Daniel Vetter wrote:
>> Maybe it wasn't clear, but -EAGAIN does _not_ resubmit work. -EAGAIN
>> is used to restart the ioctl if we had to kick a thread (to make sure
>> it doesn't hold
> specifics.
>
> Is this known? Do you want me to bisect?
Screenshot of the garbage would be a good start I'd say. Also, does a
vt-switch not resolve the issue?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscri
>
> [ CC drm and drm-intel folks ]
>
> [ Did not check any relevant MLs ]
>
> Please, see attached dmesg output.
Clock mismatch, one for Jesse to figure out. Note that this patch is
for 3.12, I simply haven't yet gotten around to properly split my
patch queue so a few spilled
;
> commit cf0a6584aa6d382f802f2c3cacac23ccbccde0cd
> drm/i915: write backlight harder
>
>
> The first commit affects no matter whether power well is on or off.
> It brings the eDP output always blank.
Can you please attach the xrandr output and drm.debug=0xe dmesg from
bootin
ees (once it passes review)? I'd like to ditch the
dummy page hack we're currently using (i.e. patch 2).
-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-k
er("intel_backlight",
> &connector->kdev, dev,
> @@ -440,7 +473,8 @@ int intel_panel_setup_backlight(struct drm_connector
> *connector)
> dev_priv->backlight = NULL;
> return -ENODEV;
>
.cgi?id=46991
Reported-and-tested-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
[danvet: Added note about workqueu deadlock.]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56337
Signed-off-by: Daniel Vetter
Later investigations showed that there _is_ lockdep support, it j
e
> preferred branch to base patches on. Daniel might fix this himself as
> this is rather trivial to solve.
Yeah, -nightly is the preferred branch for everything. Queued for -next,
thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 -
EK_END, 0); lseek(fd, SEEK_CUR, 0);
> idiom.
>
> Signed-off-by: Christopher James Halse Rogers
>
Yeah, loosk good to me and rather useful, so (with the dma-buf docs
improved as suggested below):
Reviewed-by: Daniel Vetter
I've also written some small prime tests in ig
);
> +
> + gen6_gt_force_wake_put(dev_priv);
> }
>
> static void gen7_setup_fixed_func_scheduler(struct drm_i915_private
> *dev_priv)
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: se
On Sun, Jul 14, 2013 at 09:56:45PM +0400, Konstantin Khlebnikov wrote:
> Daniel Vetter wrote:
> >On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov
> > wrote:
> >>This patch fixes regression in power consumtion of sandy bridge gpu, which
> >>exists since v
);
> +
> + gen6_gt_force_wake_put(dev_priv);
> }
>
> static void gen7_setup_fixed_func_scheduler(struct drm_i915_private
> *dev_priv)
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: se
On Tue, Jul 16, 2013 at 11:34:25AM +0400, Konstantin Khlebnikov wrote:
> On Tue, Jul 16, 2013 at 10:31 AM, Daniel Vetter wrote:
>
> > On Sun, Jul 14, 2013 at 09:56:45PM +0400, Konstantin Khlebnikov wrote:
> > > Daniel Vetter wrote:
> > > >On Sun, Jul 14, 2013
On Tue, Jul 16, 2013 at 10:31 AM, Chris Wilson wrote:
> On Tue, Jul 16, 2013 at 09:44:59AM +0200, Daniel Vetter wrote:
>> The issue I have with the current patch is that it looks a bit like
>> duct-tape since the point where we drop the forcewake references seems to
>> la
On Tue, Jul 16, 2013 at 08:32:40AM +0200, Daniel Vetter wrote:
> On Sun, Jul 14, 2013 at 08:30:09PM +0400, Konstantin Khlebnikov wrote:
> > This patch fixes regression in power consumtion of sandy bridge gpu, which
> > exists since v3.6 Sometimes after resuming from s2ram gpu
ironlake version,
which restores probably bogus values (since we haven't read them out yet
in the enable code) into the hw.
-Daniel
> +
> if (INTEL_INFO(dev)->gen < 6 && !intel_enable_gtt())
> return -EIO;
>
> ___
>
: https://bugs.freedesktop.org/show_bug.cgi?id=54089
> References: https://bugzilla.kernel.org/show_bug.cgi?id=58971
> Signed-off-by: Konstantin Khlebnikov
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: Jesse Barnes
lgtm, thanks a lot for digging through this giant mess and fig
aintainer.
-Daniel
> ---
> 0-DAY kernel build testing backend Open Source Technology Center
> http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To uns
On Wed, Jul 17, 2013 at 03:01:38AM -0700, Joe Perches wrote:
> On Wed, 2013-07-17 at 11:29 +0200, Daniel Vetter wrote:
> > On Wed, Jul 17, 2013 at 11:10 AM, Fengguang Wu
> > wrote:
> > > FYI, there are new warnings show up in
> > > tree: git://people.freedesk
0.10.2010).
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
;display.get_clock = ironlake_crtc_clock_get;
> dev_priv->display.crtc_mode_set = haswell_crtc_mode_set;
> dev_priv->display.crtc_enable = haswell_crtc_enable;
> dev_priv->display.crtc_disable = haswell_crtc_disable;
> --
> 1.8.3
>
>
other
> > value in another range.
> >
> >>
> >> I guess I need to write me a dirty script for now ... :-)
> >
> > :-)
> >
> >>
> >> Thanks guys.
> >>
> > Thanks,
> > Aaron
> > --
> > To unsubscri
tate.. I vote we kill it with fire.
Can we make it burn brighter while at it?
http://cgit.freedesktop.org/~danvet/drm/commit/?h=for-dvdhrm&id=151591c2828e18fde1eb8447874704f3422168b0
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.c
on radeon with
> CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y because a function that shouldn't be able
> to return -EDEADLK did.
>
> Cc: Alex Deucher
> Signed-off-by: Maarten Lankhorst
Oops, thanks for catching this.
Reviewed-by: Daniel Vetter
> ---
> diff --git a/kernel/mutex.c b
ntel_display.c
> @@ -9579,6 +9579,7 @@ static void intel_init_display(struct drm_device *dev)
>
> if (HAS_DDI(dev)) {
> dev_priv->display.get_pipe_config = haswell_get_pipe_config;
> + dev_priv->display.get_clock = ironlake_crtc_clock_get;
>
:
>
> [1] Revert this commit:
>
> commit 5456fe3882812aba251886e36fe55bfefb8e8829
> "drm/i915: Allocate LLC ringbuffers from stolen"
Since with a rather decent chance the next testing cycle I'll do this
friday will be the last chunk of features for 3.12 I'll probab
On Wed, Aug 21, 2013 at 08:11:27PM +0200, Sedat Dilek wrote:
> On Wed, Aug 21, 2013 at 3:44 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2013 at 12:35:08PM +0200, Sedat Dilek wrote:
> >> On Wed, Aug 21, 2013 at 11:21 AM, Stephen Rothwell
> >> wrote:
> >> >
truct i915_vma *vma)
WARN_ON(vma->node.allocated);
list_del(&vma->vma_link);
- /* Keep the vma as a placeholder in the execbuffer reservation lists */
- if (!list_empty(&vma->exec_list))
- return;
-
kfree(vma);
}
--
Daniel Vet
Is "drm/i915: More vma fixups around unbind/destroy" the nearly same fix?
Yeah, that version should get rid of the WARN noise in dmesg.
-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
On Thu, Aug 22, 2013 at 1:30 PM, Daniel Vetter wrote:
> On Thu, Aug 22, 2013 at 1:13 PM, Sedat Dilek wrote:
>> dmesg (a lot of traces) and kernel-config attached.
>>
>> UXA causes still screen corruption.
>
> Hm, was only a slim chance that this patch would fix anythi
lock computation).
-Daniel
>
> Thanks,
> Furquan
>
>
> On Mon, Aug 5, 2013 at 12:24 AM, Daniel Vetter wrote:
>
> > On Thu, Aug 01, 2013 at 02:12:22PM -0700, Furquan Shaikh wrote:
> > > Enables getting correct mode clock when reading pipe config
> > >
ling
information should be an issue for those cases.
-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
- 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;
>
= 8192;
> 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 dis
nk flips we've hit
ugly issues by 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
up and opted for
quirk entries :(
> But if that kind of "revert behavior" isn't easy, we need to just
> revert the patches entirely.
I think a i915 module option should be doable, otoh people seem to have a
viable workaround by setting a different acpi os version already.
On Wed, Jul 24, 2013 at 01:26:32PM -0700, Keith Packard wrote:
> Daniel Vetter writes:
>
> > Matching tiling modes is actually already a requirement on gen4+ (since
> > the tiling bit and the linear/tiled offset registers can't be changed with
> > a MI_DISPLAY_FLIP
On Wed, Jul 24, 2013 at 06:40:16PM -0700, Keith Packard wrote:
> Daniel Vetter writes:
>
> > We could just unconditionally increase the alignement in
> > intel_pin_and_fence_fb_obj - we already have more strict requirements due
> > to a bunch of w/a in other places.
I disabled a driver.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> [ CCing drm and drm-intel folks ]
> >>>>>
> >
On Thu, Jul 25, 2013 at 04:23:40PM +0200, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 3:36 PM, Daniel Vetter wrote:
> > On Thu, Jul 25, 2013 at 12:37:44PM +0200, Sedat Dilek wrote:
> >> On Thu, Jul 25, 2013 at 12:21 PM, Jani Nikula
> >> wrote:
> >> >
ess.
> >
> > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended
> > patch
> > fixes the backlight for you.
>
> Yes, this revert patch does re-enable backlight control for the affected
> Dell XPS13 models.
Are these the same models that neeed th
On Thu, Jul 25, 2013 at 5:03 PM, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 4:27 PM, Daniel Vetter wrote:
>> On Thu, Jul 25, 2013 at 04:23:40PM +0200, Sedat Dilek wrote:
>>> On Thu, Jul 25, 2013 at 3:36 PM, Daniel Vetter wrote:
>>> > On Thu, Jul 25, 2013 at 12:37
On Thu, Jul 25, 2013 at 8:13 PM, Keith Packard wrote:
> Daniel Vetter writes:
>
>> On Wed, Jul 24, 2013 at 06:40:16PM -0700, Keith Packard wrote:
>>> Daniel Vetter writes:
>>>
>>> > We could just unconditionally increase the alignement in
>>>
tches should satisfy there. They make
> it a new E820 type so it's clear in /proc/iomem too.
I think it'd be good to get it all in in one go, since with Chris' patches
i915 will also use the detection logic from the quirk code, so more
testing for it. And imo the i915 cleanup
gt; +
> +#define I855_GMCH_GMS_MASK 0xF0
> +#define I855_GMCH_GMS_STOLEN_0M 0x0
> +#define I855_GMCH_GMS_STOLEN_1M (0x1 << 4)
> +#define I855_GMCH_GMS_STOLEN_4M (0x2 << 4)
> +#define I855_GMCH_GMS_STOLEN_8M (0x3 << 4)
t test cycle,
and gtt mmaps seem to fail across the board :( Currently I'd wager
that the vma offset manager is the culprit, since I've only recently
pulled that stuff in from drm-next.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
dev->struct_mutex);
That should fix stuff up again, David Herrmann is working on a real
patch already.
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&q
tection against the bootloader using
> this as memory or even placing the kernel there. The BIOS needs to be
> fixed regardless of what workarounds we do in the kernel.
Like I've said we haven't seen it earmarked as ram anywhere yet, so I
don't think this is somethin
would prefer to see it marked as reserved.
Yeah, current patches mark it as reserved. But since we don't want to
duplicate the detection code we want to switch to a more unique name
when mapping the e820 region into a iomem reservation so that when
i915.ko loads we can dig it out again
). I guess drm/i915 hit a few
more of those than other people since we're always citing commits in full
(we paste --pretty=short into commit messages). And we also tend to cite
a lot of commits, sometimes mentioning all relevant changes to the code in
the past few years ;-) Together with our t
- bool wait;
> uint32_t val;
> + bool wait = false;
>
> if (I915_READ(DP_TP_CTL(port)) & DP_TP_CTL_ENABLE) {
> val = I915_READ(DDI_BUF_CTL(port));
> --
> 1.7.9.5
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57
programming model afforded by that for
userspace isn't of much use for the google guys now that they've
pushed the effort to convert SurfaceFlinger to explicit fence handling
...
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
-
ht be good to keep things together in a bugzilla report.
bugs.freedesktop.org, DRI -> DRM (Intel) is the preferred location,
please file a report there and attach the dump files (and the debug
dmesg logs we've gathered already).
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporat
Meh, forgotten to actually cc more lists ...
-Daniel
On Mon, Mar 4, 2013 at 6:49 PM, Daniel Vetter wrote:
> On Mon, Mar 4, 2013 at 6:11 PM, Chris Li wrote:
>> To recap, the black screen first show up after the ACPI change to use widows
>> 8
>> string. The i915_setmode f
3acd9658cdce1ecdf427 drm/i915: also disable 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 t
h buffer object sucks performance 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/pat
go away, 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 2c438c0273b76d6cb158f8bdd0aa3
ally
> doable.
>
> >"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 ther
On Fri, May 10, 2013 at 11:00:56AM -0700, Andy Lutomirski wrote:
> On Fri, May 10, 2013 at 2:19 AM, Daniel Vetter wrote:
> > On Thu, May 09, 2013 at 12:46:20PM -0700, Andy Lutomirski wrote:
> >> Several drivers currently use mtrr_add through various #ifdef guards
> >>
On Fri, May 10, 2013 at 12:27:54PM -0700, Andy Lutomirski wrote:
> On Fri, May 10, 2013 at 12:09 PM, Daniel Vetter wrote:
> > On Fri, May 10, 2013 at 11:00:56AM -0700, Andy Lutomirski wrote:
> >> On Fri, May 10, 2013 at 2:19 AM, Daniel Vetter wrote:
> >> > On T
the authors of those patches, and anyone who
>> signed-off on them in order to get their approval as well?
>>
>> thanks,
>>
>> greg k-h
>>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsub
is stays in limbo :(
-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.kern
On Mon, Apr 08, 2013 at 12:39:24PM +0200, Peter Zijlstra wrote:
> On Thu, 2013-04-04 at 18:56 +0200, Daniel Vetter wrote:
> > Presuming I'm still following we should be able to fix this with the
> > new sleep state TASK_DEADLOCK and a flag somewhere in the thread info
> &
On Tue, Apr 09, 2013 at 02:54:34PM +0300, Tomas Melin wrote:
> On Mon, 18 Mar 2013 09:32:51 +0100, Daniel Vetter wrote:
> >
> > On Sat, Mar 16, 2013 at 01:28:50PM +0100, Richard Cochran wrote:
> >>
> >> I have an Acer Aspire One netbook, and on it I get the follow
On Tue, Apr 09, 2013 at 03:21:35PM +0200, Richard Cochran wrote:
> On Tue, Apr 09, 2013 at 02:50:03PM +0200, Daniel Vetter wrote:
> >
> > This should be fixed with the above mentioned patch. The issue is that the
> > bios fumbles around with the output configuration beh
ate at the end, so we don't reduce the amount of
checking.
v2: Try harder not to create a big patch (Chris).
References: https://lkml.org/lkml/2013/3/16/60
Cc: Tomas Melin
Cc: Richard Cochran
Cc: Chris Wilson
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/
On Wed, Apr 10, 2013 at 12:27 AM, Steven Rostedt wrote:
> On Thu, Apr 04, 2013 at 06:38:36PM +0200, 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
>>
On Tue, Apr 09, 2013 at 06:28:08PM -0400, 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
> &g
On Mon, Apr 08, 2013 at 01:50:26PM +0200, Daniel Vetter wrote:
> On Mon, Apr 08, 2013 at 12:39:24PM +0200, Peter Zijlstra wrote:
> > On Thu, 2013-04-04 at 18:56 +0200, Daniel Vetter wrote:
> > > Presuming I'm still following we should be able to fix this with th
On Wed, Apr 10, 2013 at 01:59:02PM +0200, Richard Cochran wrote:
> On Tue, Apr 09, 2013 at 09:51:30PM +0200, Daniel Vetter wrote:
> > It will be only consistent once we've restored all the crtcs. Since a
> > bunch of other callers also want to just restore a single crtc,
On Wed, Apr 10, 2013 at 7:27 PM, Richard Cochran
wrote:
> On Wed, Apr 10, 2013 at 02:07:24PM +0200, Daniel Vetter wrote:
>>
>> It's written against drm-intel-next-queued at
>>
>> http://cgit.freedesktop.org/~danvet/drm-intel
>>
>> I've thought
hris Wilson
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b
EADLK will only 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 +++
li
s intuitive as 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 |
ething horrible.
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/linu
25.449478] [] ? loglevel+0x46/0x46
> [ 25.449478] [] ? rest_init+0x1f0/0x1f0
> [ 25.449478] [] kernel_init+0x16/0x1a0
> [ 25.449478] [] ret_from_fork+0x7c/0xb0
> [ 25.449478] [] ? rest_init+0x1f0/0x1f0
> [ 25.449478] ---[ end trace be42dd504bbfe2a9 ]---
> [EOF]
>
> --
> Regards/Gruss,
> Boris.
>
&
Since we know that locking is broken in that case and it's more
important to not flood the dmesg with random gunk.
Cc: Dave Airlie
Cc: Borislav Petkov
References:
https://groups.google.com/forum/?fromgroups=#!topic/linux.kernel/QFzFxSUeV4I
Cc: sta...@vger.kernel.org
Signed-off-by: D
se even where we
switch between the interruptible and not interruptible
wait_event_timeout variants, foolishly presuming they have the same
semantics. I very much like this.
Acked-by: Daniel Vetter
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To uns
ll to
wait_for_event and checking the return value over the timeout, even
when condition was signalled in time.
If there's any case which relies on accurate timeout detection that
simply won't work with wait_for_event (they need an nmi or a hw
timestamp counter or something similar).
-Da
On Thu, May 2, 2013 at 3:56 PM, Imre Deak wrote:
> On Thu, 2013-05-02 at 14:54 +0200, Jens Axboe wrote:
>> On Thu, May 02 2013, Imre Deak wrote:
>> > On Thu, 2013-05-02 at 14:23 +0200, Jens Axboe wrote:
>> > > On Thu, May 02 2013, Daniel Vetter wrote:
>> &
On Thu, May 02, 2013 at 12:13:08PM +0200, Borislav Petkov wrote:
> On Thu, May 02, 2013 at 09:43:05AM +0200, Daniel Vetter wrote:
> > Since we know that locking is broken in that case and it's more
> > important to not flood the dmesg with random gunk.
> >
> > C
org
> CC: linux-kernel@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 mess
t that broke
> things, but I thought I would give a heads up now in case anyone has any
> ideas.
Looked through the log files and didn't see a clue. And usually DP
tends to fail pretty noisily. So I think the bisect result would be
interestin. Meanwhile:
- do you have drm.debug=0x
On Fri, May 03, 2013 at 03:03:37PM +0300, Jani Nikula wrote:
> On Fri, 03 May 2013, Daniel Vetter wrote:
> > On Fri, May 03, 2013 at 11:17:42AM +0200, dl...@gmx.de wrote:
> >> From: Jan-Simon Möller
> >>
> >> Description:
> >> intel_gmbus_is_force
On Fri, May 3, 2013 at 10:31 PM, Josh Boyer wrote:
> OK. Git bisect tells me this:
>
> 57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit
> commit 57c219633275c7e7413f8bc7be250dc092887458
> Author: Daniel Vetter
> Date: Thu Apr 4 17:19:37 2013 +0200
>
>
On Sat, May 4, 2013 at 3:18 AM, Josh Boyer wrote:
> On Fri, May 03, 2013 at 10:40:17PM +0200, Daniel Vetter wrote:
>>On Fri, May 3, 2013 at 10:31 PM, Josh Boyer wrote:
>>> OK. Git bisect tells me this:
>>>
>>> 57c219633275c7e7413f8bc7be250dc09288745
drivers could be used
unchanged on Linux and the *BSD. But those days are long gone and drm
drivers are now proper Linux drivers, and generally OS HALs seem to be
frowned upon.
Is there another reason than just being consistent with the historic stuff
here? If we need dummy functions for !CONFIG_MTR
t; CC: intel-...@lists.freedesktop.org
> CC: dri-de...@lists.freedesktop.org
> CC: linux-kernel@vger.kernel.org
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 the line &quo
now created
a for-linux-next branch which will not contain patches heading for
3.x+1 while 3.x-rc1 hasn't been released yet.
Can you please switch over to that branch for inclusion into linux-next?
Yours, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - htt
TRRs.)
> + *
> + * arch_phys_del_wc(0) or arch_phys_del_wc(any error code) is guaranteed
> + * to have no effect.
> + */
> +#ifndef arch_phys_wc_add
> +static inline int __must_check arch_phys_wc_add(unsigned long base,
> + unsigned long size)
_mapping_free(dev_priv->gtt.mappable);
> - if (dev_priv->mm.gtt_mtrr >= 0) {
> - mtrr_del(dev_priv->mm.gtt_mtrr,
> - dev_priv->gtt.mappable_base,
> - dev_priv->gtt.mappable_end);
> - dev_priv->mm.gtt_mtrr =
radeon: Switch to arch_phys_wc_add and add a missing ..._del
> uvesafb: Clean up MTRR code
> drm: Remove mtrr_add and mtrr_del fallback hack for non-MTRR systems
With my two comments addressed, the entire series is
Reviewed-by: Daniel Vetter
My knowledge for the userspace driver
_jiffies
> that most likely do the wrong thing - for example set a timeout value of
> msecs_to_jiffies(1) - and converting them to use the new helpers.
>
> Kudos to Daniel Vetter for the idea of the new helpers.
>
> Signed-off-by: Imre Deak
> ---
> include/linux/jiffies.h
On Thu, Apr 11, 2013 at 7:52 PM, Richard Cochran
wrote:
> On Wed, Apr 10, 2013 at 10:03:25PM +0200, Daniel Vetter wrote:
>
>> That patch should crash at all, so this is not expected. Can you pls
>> check whether plain drm-intel-nightly is broken, too?
>
> I did try dr
201 - 300 of 3914 matches
Mail list logo
