I noticed that we don't have any locking. drm_for_each_connector will
soon encapsulate late, so just roll that macro out as prep work.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/
There's various proposals floating around for how to exactly fix
the connector_list locking issue. Most of them need a more fancy
iterator, with a bit more state. Prep for that by creating a
dummy struct drm_connector_iter and add is as a paramter everywhere.
To appease gcc have a dummy member and
Looping when we keep track of this is silly. Only thing we have to
be careful is with sampling the connector count. To avoid inconsisten
results due to gcc re-computing this, use READ_ONCE.
And to avoid surprising userspace, make sure we don't copy more
connectors than planned, and report the actu
- inline functions need to be static inline, otherwise gcc can opt to
not inline and the linker gets unhappy.
- no forward decls for inline functions, just include the right headers.
Cc: Oded Gabbay
Cc: Ben Goz
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_mana
Hi all,
This is a bit nightmare fuel, but I think it's the best we can aim for:
- locking doesn't leak to callers/drivers, no headaches with locking inversions
- it allows us (once fbdev is fixed) to drop the modeset_lock_all from mst
unplug, cleaning up our locking hirarchy quite a bit
As a te
On Fri, Jun 17, 2016 at 09:25:23AM +0100, Chris Wilson wrote:
> Up to now, the recommendation was for drivers to call drm_dev_register()
> followed by drm_connector_register_all(). Now that
> drm_connector_register() is safe against multiple invocations, we can
> move drm_connector_register_all() t
Also extract drm_auth.h for nicer grouping.
v2: Nuke the other comments since they don't really explain a lot, and
within the drm core we generally only document functions exported to
drivers: The main audience for these docs are driver writers.
v3: Limit the exposure of drm_master internals by o
- is_master can be removed, we can compute this by checking allowed_master
(which really just tracks whether a master struct has been allocated
for this fpriv in either open or set_master), and whether the fpriv is
the current master on the device.
- that frees up is_master as a good replace
Just rolling out a bit of abstraction to be able to clean
up the master logic in the next step.
Cc: Chris Wilson
Cc: Thomas Hellstrom
Reviewed-by: Chris Wilson
Reviewed-by: Emil Velikov
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_auth.c | 12 +---
drivers/gpu
File open/set_maseter ioctl and file close/drop_master ioctl share the
same master handling code. Extract it.
Note that vmwgfx's master_set callback needs to know whether the
master is a new one or has been used already, so thread this through.
On the close/drop side a similar parameter existed, b
We already have a fallback in place to fill out the unique from
dev->unique, which is set to something reasonable in drm_dev_alloc.
Which means we only need to have a special set_busid for pci devices,
to be able to care the backwards compat code for drm 1.1 around, which
libdrm still needs.
Whil
Ever since
commit 2e1868b560315a8b20d688e646c489a5ad93eeae
Author: Eric Anholt
Date: Wed Jun 16 09:25:21 2004 +
DRI trunk-20040613 import
the X server supports drm 1.1, thus doesn't call call libdrm's
drmSetBusid - the sole user of this ioctl. When reviewing this note
that for hilarit
Since
commit e112e593b215c394c0303dbf0534db0928e87967
Author: Nicolas Iooss
Date: Fri Dec 11 11:20:28 2015 +0100
drm: use dev_name as default unique name in drm_dev_alloc()
we're using a reasonable default which should work for everyone. Only
mtk, rcar-du and sun4i are affected, and as km
With the previous patch this is now redudant, the core always
sets a reasonable dev->unique string.
Cc: Sean Paul
Reviewed-by: Emil Velikov
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vgem/vgem_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/dr
Lots of arm drivers get this wrong and for most arm boards this is the
right thing actually. And anyway with most loaders you want to chase
sysfs links anyway to figure out which dri device you want.
This will fix dmesg noise for rockchip and sti.
Also add a fallback to driver->name for entirely
- Group declarations for separate files (drm_bridge.c, drm_edid.c)
- Move declarations only used within drm.ko to drm_crtc_internal.h
- drm_property_type_valid to drm_crtc.c, its only callsite
Reviewed-by: Chris Wilson
Reviewed-by: Emil Velikov
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/
There can only be one current master, and it's for the overall device.
Render/control minors don't support master-based auth at all.
This simplifies the master logic a lot, at least in my eyes: All these
additional pointer chases are just confusing.
While doing the conversion I spotted some locki
On Tue, Jun 21, 2016 at 11:10:27AM +0200, Daniel Vetter wrote:
> And to avoid surprising userspace, make sure we don't copy more
> connectors than planned, and report the actual number of connectors
> copied. That way any racing hot-add/remove will be handled.
> @@ -1938,6 +1929,7 @@ int drm_mode_
On Tue, Jun 21, 2016 at 11:10:34AM +0200, Daniel Vetter wrote:
> The only thing this protected is the connector_list, which is
> now protected differently.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/d
On Tue, Jun 21, 2016 at 08:04:00AM +0100, Chris Wilson wrote:
> Rendering operations to the dma-buf are tracked implicitly via the
> reservation_object (dmabuf->resv). This is used to allow poll() to
> wait upon outstanding rendering (or just query the current status of
> rendering). The dma-buf sy
mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/b5550280/attachment.html>
On Tue, Jun 21, 2016 at 01:27:34PM +0900, Tomasz Figa wrote:
> Currently the driver calls drm_dev_register() directly after allocating
> the DRM device and then continues with further initialization. This is
> incorrect, because drm_dev_register() is supposed to be called after all
> initialization
drm_dev_register() will now register all known connectors, so we no
longer have to do so manually.
Signed-off-by: Chris Wilson
Cc: Maxime Ripard
Cc: David Airlie
Cc: Chen-Yu Tsai
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
Cc: linux-arm-kernel at lists.infradead.org
---
drivers/
drm_dev_register() will now register all known connectors, so we no
longer have to do so manually.
Signed-off-by: Chris Wilson
Cc: Eric Anholt
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/vc4/vc4_drv.c | 12
1 file changed, 12 dele
drm_connector_unregister_all() is not automatically called by
drm_dev_unregister() so we can drop the local call.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Boris Brezillon
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 8
A couple of drivers open-coded drm_connector_register_all() and so were
missed in my last pass. Also Emil pointed out that atmel-hlcdc also had
a redundant drm_connector_unregister_all() we could remove.
-Chris
Hi,
On Mon, Jun 20, 2016 at 9:34 PM, Tomasz Figa wrote:
> From: Shunqian Zheng
>
> In .probe(), devm_kzalloc() is called with size == 0 and works only
> by luck, due to internal behavior of the allocator and the fact
> that the proper allocation size is small. Let's use proper value for
> calcul
On Fri, Jun 10, 2016 at 09:26:42AM +0300, Tomi Valkeinen wrote:
> On 10/06/16 09:24, Tomi Valkeinen wrote:
> > On 10/06/16 01:14, Daniel Vetter wrote:
> >> It's a legacy helper function which won't do good with atomic helpers.
> >>
> >> Cc: Tomi Valkeinen
> >> Cc: Laurent Pinchart
> >> Signed-off
On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> Cc: Ville
>
> On Mon, 20 Jun 2016, James Bottomley <
> James.Bottomley at HansenPartnership.com> wrote:
> > OK, my candidate bad commit is this one:
> >
> > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > Author: Ville Syrjälä
> > Dat
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/435c1de6/attachment-0001.html>
Hi Jani,
On Tue, Jun 21, 2016 at 11:38:41AM +0300, Jani Nikula wrote:
> On Mon, 20 Jun 2016, Aristeu Rozanski wrote:
> > while trying to use the NUC DN2820FYK [1], screen goes black as soon
> > i915 is loaded. The NUC is connected by HDMI to a 1920x1080 display.
> > Works normally while on the BIO
On 17 June 2016 at 20:24, Daniel Vetter wrote:
> On Fri, Jun 17, 2016 at 04:38:06PM +0800, Xinliang Liu wrote:
>> Hi,
>>
>> On 17 June 2016 at 15:23, Daniel Vetter wrote:
>> > On Fri, Jun 17, 2016 at 10:09:50AM +0800, Xinliang Liu wrote:
>> >> Hi Daniel,
>> >>
>> >> I have tested your David's drm
Hi,
On 21 June 2016 at 04:24, Rainer Hochecker wrote:
> Thanks a lot.
> Would you know if/when Wayland will support OpenGL?
Er, it always has ... ?
It will never support GLX (as the name implies, that's X-specific),
but EGL is perfectly capable of creating OpenGL contexts. It works
fine.
Cheer
On Tue, Jun 21, 2016 at 3:32 AM, Xinliang Liu
wrote:
> My understanding is that drm_crtc_arm_vblank_event work together with
> drm_crtc_handle_vblank (called in vblank interrupt).
> Arm the event first in somewhere(like atomic_begin/flush) and then
> send it out throuth drm_crtc_handle_vblank in
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/b74223f6/attachment.html>
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/d1540b87/attachment.html>
Rendering operations to the dma-buf are tracked implicitly via the
reservation_object (dmabuf->resv). This is used to allow poll() to
wait upon outstanding rendering (or just query the current status of
rendering). The dma-buf sync ioctl allows userspace to prepare the
dma-buf for CPU access, which
Hi Mathias,
On 19 June 2016 at 18:01, Mathias Krause wrote:
> This small series is the v2 of the patch posted initially here:
>
> http://www.spinics.net/lists/linux-media/msg101347.html
>
> It not only fixes the type mix-up and addresses Daniel's remark (patch 1),
> it also smoothes out the err
gt;
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/68ea0658/attachment-0001.html>
|.org|
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/4046fa8e/attachment.html>
to use
fd = drm_open_driver(DRIVER_INTEL);
anywhere we need to open the device
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachm
ext part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/427ca03b/attachment-0001.html>
d litle glitch
appears in right corner.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/8199e074/attachment.html>
* Tony Lindgren [160412 13:53]:
> * Sebastian Reichel [160324 17:16]:
> > On Thu, Mar 24, 2016 at 05:11:15PM +0200, Jani Nikula wrote:
> > > > I _think_, that your HW team decided to cover the first and the
> > > > last few pixels of the 864 display with plastic. So technically
> > > > it's a 864
Hi Rainer,
On 17 June 2016 at 22:00, Rainer Hochecker wrote:
> I agree. GLX_OML_sync_control fulfils all our requirements apart from being
> available for EGL. It would be great to have it available for EGL. In regard
> to Wayland this is really important. For the time being Kodi stopped
> suppor
101 - 145 of 145 matches
Mail list logo
