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
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 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 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
Add ade and dsi DT nodes for hikey board.
The binding docs were acked by Rob Herring in this thread:
https://lists.freedesktop.org/archives/dri-devel/2016-March/102135.html
Signed-off-by: Xinliang Liu
---
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 8
arch/arm64/boot/dts/hisilicon/hi
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 is done. This problem was masked by the fact that
drm_dev_register()
This series intends mostly to enable support for ARM64 architecture
in the rockchip-iommu driver. On the way to do so, some bugs are also
fixed.
The most important changes here are:
- making the Rockchip IOMMU driver use DMA API for managing cache
coherency of page tables,
- making the Rockch
From: Simon Xue
Even though the IOMMU shares IRQ with its master, the struct device
passed to {request,free}_irq is supposed to represent the device that is
signalling the interrupt. This patch makes the driver use IOMMU device
instead of master's device to make things clear.
Signed-off-by: Simo
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
calculating the size.
Fixes: cd6438c5f844 ("iommu/rockchip: Reconstruct to
The API is not suitable for subsystems consisting of multiple devices
and requires severe hacks to use it. To mitigate this, this patch
implements allocation and address space management locally by using
helpers provided by DRM framework, like other DRM drivers do, e.g.
Tegra.
This patch should no
From: Shunqian Zheng
Use DMA API instead of architecture internal functions like
__cpuc_flush_dcache_area() etc.
The biggest difficulty here is that dma_map and _sync calls require some
struct device, while there is no real 1:1 relation between an IOMMU
domain and some device. To overcome this,
From: Shunqian Zheng
Rockchip DRM used the arm special API, arm_iommu_*(), to attach
iommu for ARM32 SoCs. This patch convert to common iommu API
so it would support ARM64 like RK3399.
Since previous patch added support for direct IOMMU address space
management, there is no need to use DMA API a
From: Simon Xue
This patch makes it possible to compile the rockchip-iommu driver on
ARM64, so that it can be used with 64-bit SoCs equipped with this type
of IOMMU.
Signed-off-by: Simon Xue
Signed-off-by: Shunqian Zheng
Signed-off-by: Tomasz Figa
---
drivers/iommu/Kconfig | 2 +-
1 file cha
From: Simon Xue
The iommu_dma_alloc() in iommu/dma-iommu.c calls iommu_map_sg()
that requires the callback iommu_ops .map_sg(). Adding the
default_iommu_map_sg() to Rockchip IOMMU accordingly.
Signed-off-by: Simon Xue
Signed-off-by: Shunqian Zheng
Reviewed-on: https://chromium-review.googlesou
From: Shunqian Zheng
Set geometry for allocated domains and fix .domain_alloc() callback to
work with IOMMU_DOMAIN_DMA domain type, which is used for implicit
domains on ARM64.
Signed-off-by: Shunqian Zheng
Signed-off-by: Tomasz Figa
---
drivers/iommu/rockchip-iommu.c | 16 +++-
1
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>
Hi,
On 21 June 2016 at 14:57, Rainer Hochecker wrote:
> Are you saying that this is outdated:
> https://wayland.freedesktop.org/faq.html#heading_toc_j_12
>
> A more subtle point is that libGL.so includes the GLX symbols, so linking to
> that library will pull in all the X dependencies. This means
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
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
|.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>
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
ext part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/427ca03b/attachment-0001.html>
gt;
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/68ea0658/attachment-0001.html>
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
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/d1540b87/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/b74223f6/attachment.html>
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 BIOS (upgraded to the latest one just in
> case today) and while on grub. Here's
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
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
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
- 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/
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
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
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
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
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
- 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
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
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
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
- 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
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
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
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/
Just prep work to for the revamped connector_list locking.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_hotplug.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index
With the reworked connector_list locking we don't need this
any more. Also, we can remove the FIXME comment from the unregister
function, too, by using drm_for_each_connector.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(
Again, we now have a safe way to iterate over the connector list
and can remove the locking.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 0a678cfd9920..1064a41ed38b 1
We can't hotplug encoders/planes, there's no point in that locking. It
was also inconsistent because lacking from plane_init.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/d
This is a pretty good horror show, but I think it's the best tradeoff:
- Thanks to srcu and delayed freeing the locking doesn't leak out to
callers, hence no added headaches with locking inversions.
- For core and drivers which hot-remove connectors all the connector
list walking details are hi
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/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d104717cab6b..0a678cfd9920 10064
Hi Daniel,
On Thursday 09 Jun 2016 10:26:44 Daniel Vetter wrote:
> On Thu, Jun 09, 2016 at 01:36:30AM +0300, Laurent Pinchart wrote:
> > On Wednesday 08 Jun 2016 14:19:18 Daniel Vetter wrote:
> >> Rockchip just blew up here on testing, because I removed some "is this
> >> crtc already disabled/ena
Hi Chris,
Thank you for the patch.
On Friday 17 Jun 2016 09:25:23 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_
On Tue, Jun 21, 2016 at 01:34:33PM +0900, Tomasz Figa wrote:
> This series intends mostly to enable support for ARM64 architecture
> in the rockchip-iommu driver. On the way to do so, some bugs are also
> fixed.
>
> The most important changes here are:
> - making the Rockchip IOMMU driver use DMA
edded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/d2365af8/attachment.sig>
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
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
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_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/
version 2:
create functions drm_modeset_register_all and drm_modeset_unregister_all
to regroup all callbacks calls to avoid loops into drm_dev_register
and drm_dev_unregister.
Call order is now planes, crtcs, encoders and connectors
Fix sti driver to not call drm_connector_register_all and drm_dev
Like what has been done for connectors add callbacks on encoder,
crtc and plane to let driver do actions after drm device registration.
Correspondingly, add callbacks called before unregister drm device.
version 2:
add drm_modeset_register_all() and drm_modeset_unregister_all()
to centralize all
Make sti driver use register callback to move debugfs
initialization out of sub-components creation.
This will allow to convert driver .load() to
drm_dev_alloc() and drm_dev_register().
sti_compositor bring up 2 crtc but only one debugfs init is
needed so use drm_crtc_index to do it on the first o
Use drm_dev_alloc() and drm_dev_register() instead of .load()
To simplify init sequence only create fbdev when requested
in output_poll_changed().
version 2:
remove call to drm_connector_unregister_all() and
drm_dev_set_unique()
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_drv.c
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 12:12:54PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Thursday 09 Jun 2016 10:26:44 Daniel Vetter wrote:
> > On Thu, Jun 09, 2016 at 01:36:30AM +0300, Laurent Pinchart wrote:
> > > On Wednesday 08 Jun 2016 14:19:18 Daniel Vetter wrote:
> > >> Rockchip just blew up h
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 10:28:02AM +0100, Chris Wilson wrote:
> 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
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/435c1de6/attachment-0001.html>
On Tue, Jun 21, 2016 at 11:31:34AM +0200, Benjamin Gaignard wrote:
> Like what has been done for connectors add callbacks on encoder,
> crtc and plane to let driver do actions after drm device registration.
>
> Correspondingly, add callbacks called before unregister drm device.
>
> version 2:
> a
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>
Hi,
this series basically takes the facility for continuously capturing CRCs
of frames from the i915 driver and into the DRM core.
The idea is that test suites such as IGT use this information to check
that frames that are expected to be identical, also have identical CRC
values.
Other drivers f
In preparation to using a generic API in the DRM core for continuous CRC
generation, move the related code out of i915_debugfs.c into a new file.
Eventually, only the Intel-specific code will remain in this new file.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/i915/Makefile | 2 +
Adds a per-device debugfile "drm_crc_control" that allows selecting a
source for frame checksums in each CRTC that supports them.
The checksums for each subsequent frame can be read from the per-CRTC
file "drm_crtc_N_crc".
The code is taken from the i915 driver and other drivers can now provide
f
The core provides now an ABI to userspace for generation of CRCs that is
compatible with the one currently in i915. So remove the code that is
now duplicated and implement instead the ->set_crc_source() callback to
start and end CRC generation.
We still register files in the old debugfs paths so t
2016-06-21 12:31 GMT+02:00 Chris Wilson :
> On Tue, Jun 21, 2016 at 11:31:34AM +0200, Benjamin Gaignard wrote:
>> Like what has been done for connectors add callbacks on encoder,
>> crtc and plane to let driver do actions after drm device registration.
>>
>> Correspondingly, add callbacks called be
Take two of [1], see the cover letter there.
I've renamed drm-userland-interfaces.rst to drm-uapi.rst and added a
further split-up patch of drm internals, extracting mm, kms and kms
helpers to separate documents.
BR,
Jani.
[1] http://mid.gmane.org/cover.1466434348.git.jani.nikula at intel.com
We'll want to keep an eye on what's going on in these files.
Signed-off-by: Jani Nikula
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index cb88f724e07c..ce9c23dd02c6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3857,6 +3857,7 @@ F:driv
While splitting the document up, the headings "shifted" from what pandoc
generated. Use the following order for headings for consistency:
==
Document title
==
First
=
Second
--
Third
~
Leave the lower level headings as they are; I think those are less
import
Make the documents more manageable.
Signed-off-by: Jani Nikula
---
Documentation/gpu/drm-internals.rst | 1379 +
Documentation/gpu/drm-kms-helpers.rst | 260 +++
Documentation/gpu/drm-kms.rst | 656
Documentation/gpu/drm-mm.rst
The gpu documentation has now been converted to reStructuredText files
under Documentation/gpu. Remove the obsolete DocBook template. Also
remove it from MAINTAINERS.
Good riddance.
Signed-off-by: Jani Nikula
---
Documentation/DocBook/Makefile |2 +-
Documentation/DocBook/gpu.tmpl | 3528 --
Le 03/06/2016 09:26, Boris Brezillon a écrit :
> atmel_hlcdc_create_outputs() iterates over OF graph nodes and releases
> the node (using of_node_put()) after each iteration, which is wrong
> since for_each_endpoint_of_node() is already taking care of that.
>
> Move the of_node_put() call in the
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
On Tue, Jun 21, 2016 at 02:48:56PM +0300, Jani Nikula wrote:
> Take two of [1], see the cover letter there.
>
> I've renamed drm-userland-interfaces.rst to drm-uapi.rst and added a
> further split-up patch of drm internals, extracting mm, kms and kms
> helpers to separate documents.
All applied t
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
On Tue, Jun 21, 2016 at 10:48:08AM +0100, Chris Wilson wrote:
> 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
Hi Dave,
Here is a PR containing two fixes for 4.7.
Regards,
Boris
The following changes since commit 58a2ab3af722550b2e4e8155eb08660e16c20ee6:
drm: atmel-hlcdc: fix a NULL check (2016-06-01 15:59:36 +0200)
are available in the git repository at:
git at github.com:bbrezillon/linux-at91.g
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
On Tue, Jun 21, 2016 at 02:29:48PM +0200, Daniel Vetter wrote:
> 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,
The only thing this protected is the connector_list, which is
now protected differently.
v2: Also remove comment (Chris).
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu
Hi Joerg,
On Tue, Jun 21, 2016 at 6:17 PM, Joerg Roedel wrote:
>
> On Tue, Jun 21, 2016 at 01:34:33PM +0900, Tomasz Figa wrote:
> > This series intends mostly to enable support for ARM64 architecture
> > in the rockchip-iommu driver. On the way to do so, some bugs are also
> > fixed.
> >
> > The
Hi Tomasz,
On Tue, Jun 21, 2016 at 09:42:16PM +0900, Tomasz Figa wrote:
> In simple words, DRM patches depend on IOMMU patches.
>
> More precisely: The IOMMU patches alone are supposed to not break
> anything. Same goes for the first DRM patch (7/8). Only second DRM
> patch (8/8) depends on chang
version 3:
Dont export functions if not needed.
Fix uninitialized return variable.
In case of error while calling late_register unwind what was
aldeay done.
drm_modeset_unregister_all() call callbacks in reverse order
compare to drm_modeset_register_all()
version 2:
create functions drm_modeset_re
Like what has been done for connectors add callbacks on encoder,
crtc and plane to let driver do actions after drm device registration.
Correspondingly, add callbacks called before unregister drm device.
version 2:
add drm_modeset_register_all() and drm_modeset_unregister_all()
to centralize all
Make sti driver use register callback to move debugfs
initialization out of sub-components creation.
This will allow to convert driver .load() to
drm_dev_alloc() and drm_dev_register().
sti_compositor bring up 2 crtc but only one debugfs init is
needed so use drm_crtc_index to do it on the first o
Use drm_dev_alloc() and drm_dev_register() instead of .load()
To simplify init sequence only create fbdev when requested
in output_poll_changed().
version 2:
remove call to drm_connector_unregister_all() and
drm_dev_set_unique()
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_drv.c
Am Dienstag, 21. Juni 2016, 14:54:35 schrieb Joerg Roedel:
> Hi Tomasz,
>
> On Tue, Jun 21, 2016 at 09:42:16PM +0900, Tomasz Figa wrote:
> > In simple words, DRM patches depend on IOMMU patches.
> >
> > More precisely: The IOMMU patches alone are supposed to not break
> > anything. Same goes for
y.
That's probably the reason why patchwork didn't include the commit
message in the downloaded mbox. I've pieced it together manually and
applied this to topic/drm-misc.
Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/563249f9/attachment.sig>
On Tue, Jun 21, 2016 at 03:09:38PM +0200, Benjamin Gaignard wrote:
> Like what has been done for connectors add callbacks on encoder,
> crtc and plane to let driver do actions after drm device registration.
>
> Correspondingly, add callbacks called before unregister drm device.
>
> version 2:
> a
attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160621/4934490a/attachment-0001.sig>
1 - 100 of 145 matches
Mail list logo
