On Sat, Dec 14, 2013 at 1:37 PM, Thierry Reding
wrote:
> On Thu, Dec 12, 2013 at 11:30:23PM +0100, Daniel Vetter wrote:
>> On Thu, Dec 12, 2013 at 8:34 PM, Thomas Hellstrom
>> wrote:
>> > On 12/12/2013 03:36 PM, Thierry Reding wrote:
>> >>
>> >>
alloc_chrdev_region() dance. Although that will
> only allocate the major dynamically.
>
> I'm not aware of any function that just allocates a single major/minor
> pair completely dynamically. Is there one that you could point me to?
miscdev seems appropriate for me, I don't t
oot,
> S_IRUGO | S_IWUSR,
> root, dev,
> fops);
> - if (IS_ERR(ent))
> - return PTR_ERR(ent);
> + if (!ent)
> + return -ENOMEM;
>
> return
gh doorbell or
whatever else we want to do). The ring in the ctx would be under the
kernel's control.
Of course there's lots of GEM stuff we don't need at all for such
contexts, but there's still lots of shared code. Imo creating a 2nd driver
has too much interface surface
e started) which means we
can evict any context object if it's getting in the way.
We must do that since the contexts have to be in global gtt, which is
shared for scanouts. So fragmenting that badly with lots of context
objects and other stuff is a no-go, since that means we'll start to fa
On Mon, Jul 21, 2014 at 11:58:52AM -0400, Jerome Glisse wrote:
> On Mon, Jul 21, 2014 at 05:25:11PM +0200, Daniel Vetter wrote:
> > On Mon, Jul 21, 2014 at 03:39:09PM +0200, Christian König wrote:
> > > Am 21.07.2014 14:36, schrieb Oded Gabbay:
> > > >On 20/07
ict stuff.
And if we don't want compute to be a denial of service on the display
side of the driver we need this ability. Now if you go through an
ioctl instead of the doorbell (I agree with Jerome here, the doorbell
should be supported by benchmarks on linux) this gets a bit easier,
but it
gt; u32 len;
> };
> @@ -80,7 +80,7 @@ free:
>
> static void render_state_free(struct i915_render_state *so)
> {
> - kunmap(so->batch);
> + kunmap(kmap_to_page(so->batch));
> i915_gem_object_ggtt_unpin(so->obj);
> drm_gem_object_u
the hw and overload. Imo the kernel
_must_ sit in between and reject clients that don't behave. Of course you
can only ever react (worst case with a gpu reset, there's code floating
around for that on intel-gfx), but at least you can do something.
If userspace has a direct submit path t
On Mon, Jul 21, 2014 at 03:03:07PM -0400, Jerome Glisse wrote:
> On Mon, Jul 21, 2014 at 09:41:29PM +0300, Oded Gabbay wrote:
> > On 21/07/14 21:22, Daniel Vetter wrote:
> > > On Mon, Jul 21, 2014 at 7:28 PM, Oded Gabbay wrote:
> > >>> I'm not sure whethe
On Tue, Jul 22, 2014 at 09:28:51AM +0200, Daniel Vetter wrote:
> On Mon, Jul 21, 2014 at 03:03:07PM -0400, Jerome Glisse wrote:
> > On Mon, Jul 21, 2014 at 09:41:29PM +0300, Oded Gabbay wrote:
> > > On 21/07/14 21:22, Daniel Vetter wrote:
> > > > On Mon, Jul 21
drm_set_unique(struct drm_device *dev, const char *fmt, ...)
Can you please add a bit of kerneldoc for this? drm_ioctl.c isn't yet
pulled into the drm reference docbook, but better to have it there
already. With that fixed this is
Reviewed-by: Daniel Vetter
> +{
> + va_list ap;
&g
robably the same WARN fixed by:
> http://patchwork.freedesktop.org/patch/24126/
Knut, can you please check that this patch gets rid of the WARN?
-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
gt; (Adele, "Rolling In The Deep")
>
>
> --
> --alessandro
>
> "don't underestimate the things that I will do"
>
> (Adele, "Rolling In The Deep")
> ___
> Intel-gfx mailing list
> intel-...@l
;&
> + (sizes->fb_width > intel_fb->base.width ||
> + sizes->fb_height > intel_fb->base.height)) {
> + drm_framebuffer_reference(&ifbdev->fb->base);
> + intel_fb = ifbdev->fb = NULL;
Hm, maybe add a
On Wed, Apr 23, 2014 at 09:17:16AM +0200, Thierry Reding wrote:
> On Tue, Apr 22, 2014 at 05:48:07PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 22, 2014 at 05:09:32PM +0200, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > Add a helper function t
in 3.11-rc2.
Screenshot or more detailed description of what "only top 20% of
screen works in X" means?
Anything in dmesg?
bisect result presuming that it reproduces reliably?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
ed mitigation measures work properly. But those won't get your gpu
back, only the display and it's only for 3.16. We're still hunting a
proper fix for 3.15.
And if you can indeed reliably reproduce this a bisect could be really useful.
-Daniel
--
Daniel Vetter
Software Engin
0x64/0xf0
>> [ 12.012483] [] __pci_register_driver+0x4c/0x50
>> [ 12.012489] [] drm_pci_init+0x10a/0x140 [drm]
>> [ 12.012490] [] ? 0xa02bafff
>> [ 12.012502] [] i915_init+0x89/0x90 [i915]
>> [ 12.012503] [] do_one_initcall+0xbc/0x1f0
>>
On Wed, Jul 30, 2014 at 4:20 AM, Aaron Lu wrote:
> On 07/29/2014 07:10 PM, Daniel Vetter wrote:
>> On Tue, Jul 29, 2014 at 12:14 PM, Ville Syrjälä
>> wrote:
>>> On Tue, Jul 29, 2014 at 10:43:02AM +0800, Aaron Lu wrote:
>>>> FYI, we notice
art of
the crtc, but cut out as a separate plane. In 3.17 this is enabled so
userspace can use it, so I think new drivers should be converted to this
from the go.
It looks like your platform already has universal planes on the hw side,
so removing that fake disdinction for primary planes sh
ions. Instead you should use
drm_connector_register/unregister. Please don't just export randome
functions without digging into the history a bit.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: sen
nly matter for backwards compat with
existing pageflip and cursor ioctls, so doesn't really matter too
much.
Anyway didn't spot anything else which would need to be upgrade to
never kms interfaces, so ack from my side for that. Only looked at
that since right now I'm refreshing dr
_port *)port
>
> (port/uart_port is the first field in uart_amba_port though)
fwiw I like this and I've picked it up into my topic/core-stuff branch. So
if driver writers don't outright nack this it'll all land in Dave's
drm-next (probably still for 3.18).
-Daniel
--
de just calls the relevant plane functions that
should even simplify your driver ;-)
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"
On Thu, Sep 18, 2014 at 04:52:14PM +0200, Daniel Vetter wrote:
> On Thu, Sep 18, 2014 at 05:36:31PM +0800, Mark yao wrote:
> > This patch adds the basic structure of a DRM Driver for Rockchip Socs.
> >
> > Signed-off-by: Mark yao
> > ---
> > Changes in v2:
>
drm_unload(struct drm_device *dev)
> exynos_drm_fbdev_fini(dev);
> drm_kms_helper_poll_fini(dev);
>
> - component_unbind_all(dev->dev, dev);
> drm_vblank_cleanup(dev);
> + component_unbind_all(dev->dev, dev);
> drm_mode_config_cleanu
a output is rather puzzling:
https://bugzilla.kernel.org/show_bug.cgi?id=68451
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
gem module
> >>+ * of kernel side with user virtual address which is allocated
> >>+ * by do_mmap().
> >>+ */
> >>+struct drm_rockchip_gem_mmap {
> >>+ uint32_t handle;
> >>+ uint32_t pad;
> >>+ uint64_t s
*format, ...);
> >
> > /***/
> > /** \name DRM template customization defaults */
> >
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freede
cs to rockchip drm crtc.
> - use vop reset at first init
> - reference framebuffer when used and unreference when swap out vop
>
> Changes in v3:
> - change "crtc->fb" to "crtc->primary-fb"
> Adviced by Daniel Vetter
> - init cursor plane with univer
On Wed, Sep 24, 2014 at 11:31 AM, Mark yao wrote:
> On 2014年09月24日 16:20, Daniel Vetter wrote:
>>
>> On Mon, Sep 22, 2014 at 06:48:54PM +0800, Mark yao wrote:
>>>
>>> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>>>
>>>
end(device);
> + pm_runtime_last_busy_and_autosuspend(device);
> }
>
> void intel_init_runtime_pm(struct drm_i915_private *dev_priv)
> --
> 1.7.0.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from t
a really high
level up I think, so Ack: me.
-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 majordo
def __DRM_BACKLIGHT_H__
> +#define __DRM_BACKLIGHT_H__
> +
> +/*
> + * Copyright (c) 2014 David Herrmann
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software
On Thu, Sep 11, 2014 at 02:22:55PM +0200, David Herrmann wrote:
> Hi
>
> On Thu, Sep 11, 2014 at 8:48 AM, Daniel Vetter wrote:
> > Nice you skid around all the pitfalls and trapdoors, I guess we've all
> > been rather blind ;-)
> >
> > Two high-level c
of each crtc devices, fimd and mixer.
Generally it's not a good idea to drop fb references from irq context,
since if you actually drop the last reference it'll blow up: fb cleanup
needs a bunch of mutexes.
Also the drm core really should be taking care of this for you, you o
On Fri, Sep 12, 2014 at 11:27:41AM +0200, Andrzej Hajda wrote:
> On 09/12/2014 10:57 AM, Daniel Vetter wrote:
> > On Fri, Sep 12, 2014 at 05:34:50PM +0900, Inki Dae wrote:
> >> Hi Andrzej,
> >>
> >> On 2014년 09월 09일 22:16, Andrzej Hajda wrote:
> >&g
* If the acpi_video interface is not supposed to be used, don't
> > -* bother processing backlight level change requests from firmware.
> > -*/
> > - if (!acpi_video_verify_backlight_support()) {
> > + if (should_ignore_backlight_request()) {
> > DRM_DEBUG_KMS(
On Tue, Sep 30, 2014 at 02:14:19PM +0800, Mark Yao wrote:
> From: Mark yao
>
> This add a display subsystem comprise the all display interface nodes.
>
> Signed-off-by: Mark Yao
> Signed-off-by: Daniel Kurtz
> Acked-by: Daniel Vetter
> Reviewed-by: Rob Clark
Just a
On Tue, Sep 30, 2014 at 10:10:20AM +0200, Daniel Vetter wrote:
> On Tue, Sep 30, 2014 at 02:14:19PM +0800, Mark Yao wrote:
> > From: Mark yao
> >
> > This add a display subsystem comprise the all display interface nodes.
> >
> > Signed-off-by: Mark Yao
Andrew's comments somewhen next week. Presuming
the (here one week later than everywhere else) carnival doesn't
interfere too badly ;-)
-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 "
uts - atm only rgba with fixed dimensions can be
support with the current cursor ioctl.
So reviewing the overall situation I actually _don't_ want a new
cap/ioctl/prop here just for now. As long as we need to go with intel
specific hacks userspace might as well probe things manually and act
u
to restructuring cursor size restrictions
> and DRM_DEBUG usage.
>
> Testcase: igt/kms_cursor_crc
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: David Airlie
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: G, Pallavi
> Sign
-EINVAL.
>
> Adding the cap allows existing userspace to dtrt...
1. Move cursor off-screen.
2. Check desired cursor layout with set_cursor.
3. Pick real cursor, set it.
Or
1. Use set_cursor on disabled crtc.
Both aren't pretty, but that ugly should help to move
cursors-as-real-planes forward
On Mon, Mar 10, 2014 at 11:07 AM, Daniel Vetter wrote:
> On Mon, Mar 10, 2014 at 11:04 AM, Chris Wilson
> wrote:
>>> > The cap exposes the max cursor size. Knowing our hardware we can infer
>>> > that pot sizes from 64 to max are supported, but it would be bett
lue
what's amiss, but it seems to /mostly/ work. Thus far I've only hear
reports of this for gm45 and not yet really for upstream. Until
someone digs up more evidence I think we need to classify this as a
rare heisenbug and not really a regression :(
One thing we could try is to simply rep
this patch fix this with just doing the 'max_conn_count' zero check
> in the front of drm_fb_helper_init().
>
> Signed-off-by: Xiubo Li
> CC: Jani Nikula
Makes sense.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c | 3 +++
> 1 file ch
(unsigned long)(batch_end - cmd));
> + batch_end - cmd);
> ret = -EINVAL;
> break;
> }
> --
> 1.8.4.5
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.f
no
longer bother. Which is even worse from my pov as driver maintainer. I
highly consider module options used in production evil.
-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 li
On Thu, May 15, 2014 at 10:46:50PM -0600, Alex Williamson wrote:
> On Fri, 2014-05-16 at 00:50 +0200, Daniel Vetter wrote:
> > On Thu, May 15, 2014 at 11:43 PM, Alex Williamson
> > wrote:
> > > I don't know what to do with this. It seems like a lot of wishful
> &g
On Sun, May 18, 2014 at 08:13:38PM +0100, Chris Wilson wrote:
> On Sun, May 18, 2014 at 09:08:40PM +0200, Thomas Meyer wrote:
> > Am Montag, den 12.05.2014, 07:33 +0100 schrieb Chris Wilson:
> > > On Sun, May 11, 2014 at 07:40:57PM +0200, Daniel Vetter wrote:
> > > >
+9331,7 @@ static void intel_modeset_commit_output_state(struct
> drm_device *dev)
> }
>
> static void
> -connected_sink_compute_bpp(struct intel_connector * connector,
> +connected_sink_compute_bpp(struct intel_connector *connector,
> struct inte
n x86. But on
arm it can cope.
This is somewhat important for dma-buf buffer sharing since if the cpu
cache control is done in drivers you must do double-flushing on shared
buffers. Atm you have to do that anyway, but at least this would make it
easier. The other problem is that ttm reinvents half o
nderruns I think we've fully confirmed that they only
happen on boot-up. I'll try to come up with some ideas what could have
gone wrong there.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send th
On Tue, May 13, 2014 at 12:59 PM, Chris Wilson wrote:
> On Tue, May 13, 2014 at 12:38:41PM +0200, Daniel Vetter wrote:
>> On Tue, May 13, 2014 at 12:29 PM, Jörg Otte wrote:
>> >>> Branch drm-intel-nightly as of
>> >>> ed60c27 drm-intel-nightly: 2014y-0
On Tue, May 13, 2014 at 12:38:41PM +0200, Daniel Vetter wrote:
> On Tue, May 13, 2014 at 12:29 PM, Jörg Otte wrote:
> >>> Branch drm-intel-nightly as of
> >>> ed60c27 drm-intel-nightly: 2014y-05m-09d-21h-51m-45s integration manifest
> >>> looks badly:
>
On Tue, May 13, 2014 at 05:21:49PM +0200, Jörg Otte wrote:
> 2014-05-13 15:22 GMT+02:00 Daniel Vetter :
> > On Tue, May 13, 2014 at 12:38:41PM +0200, Daniel Vetter wrote:
> >> On Tue, May 13, 2014 at 12:29 PM, Jörg Otte wrote:
> >> >>> Branch drm-intel-nigh
On Tue, May 13, 2014 at 05:46:31PM +0100, Damien Lespiau wrote:
> On Tue, May 13, 2014 at 06:38:32PM +0200, Daniel Vetter wrote:
> > > Doesn't work for me, I still have an underrun at boot-up.
> >
> > I'm at a loss tbh with ideas. We successfully disable both pi
t; + list_del_init(&driver->list);
> +
> + pr_debug("driver %ps removed\n", driver);
> +
> + mutex_unlock(&interfaces_lock);
> +}
> diff --git a/include/linux/interface.h b/include/linux/interface.h
> new file mode 100644
> index ..2c49ad3912fe
drm_usb_bus = {
> .set_busid = drm_usb_set_busid,
> };
> -
> +
> +/**
> + * drm_usb_init - Register matching USB devices with the DRM subsystem
> + * @driver: DRM device driver
> + * @udriver: USB device driver
> + *
> + * Registers one or more devices matc
exposes, then I think a real bus driver makes a lot more
sense. And Greg seems to have ideas about that already.
-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&quo
On Tue, May 13, 2014 at 05:32:15PM -0700, Greg Kroah-Hartman wrote:
> On Tue, May 13, 2014 at 07:57:13PM +0200, Daniel Vetter wrote:
> > On Tue, May 13, 2014 at 05:30:47PM +0200, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > Some drivers,
> initialization of the backlight registers.
> >
> > v2: Keep QUIRK_NO_PCH_PWM_ENABLE for now (Imre).
> >
> > Signed-off-by: Jani Nikula
> > Reviewed-by: Imre Deak
> > Signed-off-by: Daniel Vetter
> >
> > Which is in 3.12.0
>
On Wed, May 14, 2014 at 03:43:53PM -0400, Josh Boyer wrote:
> On Wed, May 14, 2014 at 3:33 PM, Greg KH wrote:
> > On Wed, May 14, 2014 at 09:19:32PM +0200, Daniel Vetter wrote:
> >> On Wed, May 14, 2014 at 08:47:38PM +0200, Bruno Prémont wrote:
> >> > CCing intel-gfx
___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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
-- we have another incarnation of the bug
> that is being chased in 76554.
Someone succeeding at a bisect would be awesome ... Note that the only
key here is the ring init failure in dmesg.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
T
On Thu, May 15, 2014 at 07:37:32AM -0700, H. Peter Anvin wrote:
> On 05/15/2014 05:38 AM, Daniel Vetter wrote:
> > On Wed, May 14, 2014 at 09:41:12AM -0600, Ross Zwisler wrote:
> >> With this commit:
> >>
> >> 2a0788dc9bc4 x86: Use clflushopt in drm_clflush_v
d which is still unanswered!
>
> I tried to bisect the thing, but I ran into compile errors. So I
> can only say it came in with
> e9f37d3 "Merge branch 'drm-next' of
> git://people.freedesktop.org/~airlied/linux"
>
> Jörg
--
Daniel Vetter
Software Engineer,
ime we add a substantial amount of new
checks to the modeset state checker it takes 1-2 releases to settle
all the fallout. But we're backporting all the fixes, except when
they're too invasive (in which case we disable the check temporarily
or restrict it).
-Daniel
--
Daniel Vetter
Software
ighly visible for anyone.
To make sure that you're only seeing this at boot up and not elseplace
please check that it doesn't show up when you do anything of the
below:
a) suspend/resume
b) changing the output mode (e.g. with xrandr --mode)
c) changing the output pipe (e.g. with xrandr
17:51:15 localhost.localdomain kernel: atl1c :01:00.0: no hotplug
>> settings from platform
>> Mai 10 17:51:15 localhost.localdomain kernel: iwlwifi :02:00.0: no
>> hotplug settings from platform
>> Mai 10 17:51:15 localhost.localdomain kernel: Rest
Remove the caller side lock for avoid a
> fatal deadlock.
>
> Signed-off-by: Takashi Iwai
Oops, failed to do the audit correctly. Thanks for catching this.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/ast/ast_drv.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff -
On Mon, May 12, 2014 at 07:33:55AM +0100, Chris Wilson wrote:
> On Sun, May 11, 2014 at 07:40:57PM +0200, Daniel Vetter wrote:
> > On Sun, May 11, 2014 at 11:02 AM, Dave Airlie wrote:
> > > On 11 May 2014 18:28, Thomas Meyer wrote:
> > >> Hi,
> > >>
&g
On Mon, May 12, 2014 at 10:09:54AM +0300, Jani Nikula wrote:
> On Sun, 11 May 2014, Daniel Vetter wrote:
> > On Sun, May 11, 2014 at 11:02 AM, Dave Airlie wrote:
> >> On 11 May 2014 18:28, Thomas Meyer wrote:
> >>> Hi,
> >>>
> >>> 3.
On Mon, May 12, 2014 at 01:25:24PM +0200, Jörg Otte wrote:
> 2014-05-11 18:49 GMT+02:00 Daniel Vetter :
> > On Sat, May 10, 2014 at 10:52 AM, Jörg Otte wrote:
> >>> On Fri, May 09, 2014 at 05:14:38PM +0100, Damien Lespiau wrote:
> >>>> On Fri, May 09, 2014
; until after vgacon->fbcon handoff.
>
> Signed-off-by: Alex Williamson
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Dave Airlie
> ---
>
> This should be a nop with the default module setting, so if there's
> any opportunity to get this into v3.15, it would
On Mon, May 12, 2014 at 01:30:39PM -0600, Alex Williamson wrote:
> On Mon, 2014-05-12 at 21:08 +0200, Daniel Vetter wrote:
> > On Fri, May 09, 2014 at 02:20:41PM -0600, Alex Williamson wrote:
> > > Commit 81b5c7bc found that the current VGA arbiter support in i915
> > >
.
Before we go on a wild goose chase, can you please confirm your
suspicion with a revert?
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"
On Fri, Mar 21, 2014 at 12:26:51PM +0100, Peter Senna Tschudin wrote:
> On Thu, Mar 20, 2014 at 10:17 PM, Daniel Vetter wrote:
> > On Thu, Mar 20, 2014 at 05:56:20PM +0100, Peter Senna Tschudin wrote:
> >> When Fedora updated the Kernel package from 3.12 to 3.13 my notebook
&g
ghtly (or drm-intel-testing as
of today) a shot. We've merged a few patches recently to slightly
improve the ring init sequence in the generic code, they might
actually help here. Sorry for not correlating them with your patch
when I've merged them, only just realized this now.
Thanks, Daniel
t-tape.
"Properly" fixing the underlying bug for any sane definition of "proper"
is impossible - the legacy drm driver model is just too broken for that.
And for new-style drivers killing the irq support when they don't expect
it is not cool, since those drivers are sane
On Mon, Mar 24, 2014 at 01:17:12PM -0400, Mikulas Patocka wrote:
>
>
> On Mon, 24 Mar 2014, Daniel Vetter wrote:
>
> > On Mon, Mar 24, 2014 at 07:45:47AM +1000, Dave Airlie wrote:
> > > On Mon, Mar 24, 2014 at 7:27 AM, Andreas Mohr wrote:
> > > > On Sun,
's a
fundamental misdesign of the legacy drm driver architecture and the
_only_ way to fix this bug for real is to rewrite this all. Which was
done for all the still used drivers like i915, radeon, nouveau, ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57
On Tue, Mar 25, 2014 at 12:11 AM, Andreas Mohr wrote:
> On Mon, Mar 24, 2014 at 10:46:49PM +0100, Daniel Vetter wrote:
>> On Mon, Mar 24, 2014 at 9:40 PM, Mikulas Patocka wrote:
>> > If someone understands the locking issues I pointed out above, it could be
>> > eas
might or might not work, actually. I'm silently
>* assuming here that the native panel resolution is
> @@ -459,7 +456,7 @@ static void ns2501_dpms(struct intel_dvo_device *dvo,
> bool enable)
> unsigned char ch;
>
> DRM_DEBUG_KMS("%s: Trying set
On Tue, Mar 25, 2014 at 06:42:13PM -0400, Mikulas Patocka wrote:
>
>
> On Mon, 24 Mar 2014, Daniel Vetter wrote:
>
> > >> Like I've said the entire teardown sequence for legacy drm drivers is
> > >> terminally busted, so the only hope we have is to re
s ;-)
In general don't set any i915 options if you're not a developer or someone
else who _really_ knows what's going on.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the
range so that the gpu
can intercept pte updates and invalidate tlbs accordingly. So yeah, we
need this, too.
-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" i
/* WaTimedSingleVertexDispatch:cl,bw,ctg,elk,ilk,snb */
> if (INTEL_INFO(dev)->gen >= 4 && INTEL_INFO(dev)->gen < 7)
> --
> 1.8.1.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from
aven't managed to convince them to throw people's
time at this.
It looks like a step into the right direction, but until I have the proof
in the form of i915 patches that I won't have to support 2 gfx fencing
frameworks I'm opposed to de-staging android syncpts. Ofc someone els
ubt this is worthwhile to pursue in
upstream with our essentially eternal api guarantees. At least until
we see serious uptake from vendors and gfx driver guys. Unfortunately
the Intel android folks are no exception here and haven't pushed
anything like this in my direction yet at all.
hould have dctx->obj == NULL. And ring init failures
fail earlier so shouldn't even hit the context_fini code below the
cleanup_gem: label in driver_load. Seriously confused here.
-Daniel
On Thu, Jun 19, 2014 at 2:45 PM, Konrad Zapalowicz
wrote:
> On 06/19, Daniel Vetter wrote:
>
On Thu, Jun 19, 2014 at 4:35 PM, Daniel Vetter wrote:
> The actual bug we seem to have is blowing up on the ggtt_unpin in
> context_fini. Which is doubly-impossible: Gen4 doesn't have hw
> contexts, so should have dctx->obj == NULL. And ring init failures
> fail earlier so sh
teams also set up the RMRR ranges with equallly
predictable results.
I don't have a recommendation here, but expect breakage no matter what you do.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list:
attach
dmesg here so we know what kind of hardware you have? Also any dying
breadths over netconsole or similar? Can't hurt to check that before doing
the bisect.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Thu, Jun 19, 2014 at 08:35:29AM -0700, Colin Cross wrote:
> On Thu, Jun 19, 2014 at 5:28 AM, Daniel Vetter wrote:
> > On Thu, Jun 19, 2014 at 1:48 PM, Thierry Reding
> > wrote:
> >>> > With these changes, can we pull the android sync logic out o
drm_device *dev = ring->dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> int ret = init_ring_common(ring);
> + if (ret)
> + return ret;
>
> /* WaTimedSingleVertexDispatch:cl,bw,ctg,elk,ilk,snb */
> if (INTEL_INFO(dev
because such a "benign"
BUG_ON ended up eating my irq handler or a spinlock required by such.
Or some other nonsense that makes debugging a royal pita, especially
if your remote debugger consists of a frustrated users staring at a
hung machine.
Cheers, Daniel
--
Daniel Vetter
Software
work in
> the past in changing the ways of _very_ large companies, why stop now?
Dave should chime in here since currently dma-buf is _GPL and the
drm_prime.c wrapper for it is not (and he merged that one, contributed
from said $vendor). And since we're gfx people everything we do is MIT
1301 - 1400 of 3914 matches
Mail list logo
