https://bugzilla.kernel.org/show_bug.cgi?id=119631
--- Comment #11 from Mathieu Belanger ---
I will test the patch this night.
Isn't thread_submit just to fix rendering on DRI PRIME or something like that?
--
You are receiving this mail because:
You are watching the assignee of the bug.
Doug,
On 06/14/2016 11:24 PM, Doug Anderson wrote:
> Yakir,
>
> On Tue, Jun 14, 2016 at 4:46 AM, Yakir Yang wrote:
>> RK3399 and RK3288 shared the same eDP IP controller, only some light
>> difference with VOP configure and GRF configure.
>>
>> Signed-off-by: Yakir Yang
>> Acked-by: Mark Yao
>>
On 06/15/2016 12:28 AM, Daniel Vetter wrote:
> On Tue, Jun 14, 2016 at 06:26:56PM +0200, Daniel Vetter wrote:
>> On Tue, Jun 14, 2016 at 07:46:29PM +0800, Yakir Yang wrote:
>>> It's better to pass the connector to platform driver in .get_modes()
>>> callback, just like what the .get_modes() helper
Hi,
On Mon, Jun 13, 2016 at 03:08:19PM +0530, Anshuman Khandual wrote:
> On 05/31/2016 05:31 AM, Minchan Kim wrote:
> > @@ -791,6 +921,7 @@ static int __unmap_and_move(struct page *page, struct
> > page *newpage,
> > int rc = -EAGAIN;
> > int page_was_mapped = 0;
> > struct anon_vma *
Excuse me for top posting.
So I finally got back to this patch, still don't like it.
Apart from the doing 3 things in once which is just annoying, current
userspace for tiled monitors
relies on the behaviour that the cached edids are retrieved before the
connector is show to userspace.
This is s
On 15 June 2016 at 13:49, Dave Airlie wrote:
> Excuse me for top posting.
>
> So I finally got back to this patch, still don't like it.
>
> Apart from the doing 3 things in once which is just annoying, current
> userspace for tiled monitors
> relies on the behaviour that the cached edids are retri
esktop.org/archives/dri-devel/attachments/20160615/d02de036/attachment.html>
a04 Dave Airlie 2008-11-07 1251 /**
144ecb97 Daniel Vetter 2014-10-27 1252 * struct drm_plane_state - mutable
plane state
07cc0ef6 Daniel Vetter 2014-11-27 1253 * @plane: backpointer to the plane
144ecb97 Daniel Vetter 2014-10-27 1254 * @crtc: currently bound CRTC, NULL
if disabled
cc4ceb48 Daniel Vetter 2014-07-25 1255 * @fb: currently bound framebuffer
e2330f07 Daniel Vetter 2014-10-29 1256 * @fence: optional fence to wait for
before scanning out @fb
144ecb97 Daniel Vetter 2014-10-27 1257 * @crtc_x: left position of visible
portion of plane on crtc
:: The code at line 1249 was first introduced by commit
:: f453ba0460742ad027ae0c4c7d61e62817b3e7ef DRM: add mode setting support
:: TO: Dave Airlie
:: CC: Dave Airlie
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 6370 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/928c5942/attachment-0001.obj>
On Mon, Jun 13, 2016 at 4:10 PM, Alex Williamson
wrote:
> On Mon, 13 Jun 2016 15:45:20 -0400
> Alex Deucher wrote:
>
>> When executing in a PCI passthrough based virtuzliation environment, the
>> hypervisor will usually attempt to send a PCIe bus reset signal to the
>> ASIC when the VM reboots. I
https://bugzilla.kernel.org/show_bug.cgi?id=119631
--- Comment #12 from Axel Davy ---
thread_submit delays submission of buffers to the X server until the moment the
buffer has all rendering finished.
This is useful for DRI PRIME, because the kernel doesn't have yet all the
pieces to have the ot
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/7711845a/attachment.html>
vel/attachments/20160615/16e31ebf/attachment.html>
On 14.06.2016 18:35, Daniel Vetter wrote:
> On Tue, Jun 14, 2016 at 11:09 AM, Michel Dänzer
> wrote:
>> On 14.06.2016 18:03, Daniel Vetter wrote:
>>> Somehow this escaped us, this is a KMS ioctl which should only be used
>>> by the master (which is the thing that's also in control of kms
>>> res
On 14.06.2016 17:06, Daniel Vetter wrote:
> On Tue, Jun 14, 2016 at 04:25:28PM +0900, Michel Dänzer wrote:
>> On 14.06.2016 14:53, Daniel Vetter wrote:
>>> On Tue, Jun 14, 2016 at 11:09:10AM +0900, Michel Dänzer wrote:
On 06/13/16 23:06, Daniel Vetter wrote:
> On Mon, Jun 13, 2016 at 05:
Hi Alexander,
Thanks for your comments!
On Tuesday, June 14, 2016 5:54 PM, Alexander wrote:
> > +static struct
> > +device_node *detect_hdmi_connection(struct fsl_dcu_drm_device
> > +*fsl_dev) {
> > + struct device_node *remote_port;
> > + struct of_endpoint *ep;
> > + struct device_node *
Am Dienstag, den 14.06.2016, 18:08 +0200 schrieb Daniel Vetter:
> On Thu, Jun 02, 2016 at 07:27:51PM +0200, Philipp Zabel wrote:
> > Since commit 0955c1250e96 ("drm/crtc: take references to connectors used
> > in a modeset. (v2)"), the reference counts of all connectors in the
> > drm_mode_set give
[Added Sinclair, Thomas, and "VMware Graphics".]
On do, 2016-04-14 at 07:34 -0700, Joe Perches wrote:
> On Thu, 2016-04-14 at 13:32 +0200, Paul Bolle wrote:
> > On do, 2016-03-03 at 11:26 +0100, Paul Bolle wrote:
> > >
> > > Use the upper_32_bits() macro instead of the four line equivalent that
>
Some fixes and cleanups that should get merged to tilcdc even if my
atomic changes are still a work in progress.
Jyri Sarha (6):
drm/tilcdc: Restore old dpms state in pm_resume()
drm/tilcdc: Write to LCDC_END_OF_INT_IND_REG at the end of IRQ
function
drm/tilcdc: Move waiting of LCDC_FRAM
Restore old dpms state in pm_resume(). The dpms is turned off in
pm_suspend() and it should be restored to its original state in
pm_resume().
Fixes commit 614b3cfeb8d2 ("drm/tilcdc: disable the lcd controller/dma
engine when suspend invoked")
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc
Reorder the IRQ function so that the write to LCDC_END_OF_INT_IND_REG
is done last. The write to LCDC_END_OF_INT_IND_REG indicates to LCDC
that the interrupt service routine has completed (see section
13.3.6.1.6 in AM335x TRM). This is needed if LCDC's ipgvmodirq module
is configured for pulse inte
Move wait queue waiting of LCDC_FRAME_DONE IRQ from tilcdc_crtc_dpms()
into stop() function.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc
Add drm_crtc_vblank_on() and *_off() calls to start() and stop()
functions, to make sure any vblank waits etc. gets properly cleaned
up.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
The legacy panel.txt and tfp410.txt bindings are still the only supported
way to connect lcd panel and tfp410 DVI encoder to tilcdc.
Signed-off-by: Jyri Sarha
---
Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/dev
Avoid error print by of_graph_get_next_endpoint() if there is no ports
present.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_external.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c
b/drivers/gpu/drm/ti
On Tue, Jun 14, 2016 at 1:19 PM, Jose Abreu wrote:
>> I assume that xilinx VDMA is the only way to feed pixel data into your
>> display pipeline. Under that assumption:
>>
>> drm_plane should map to Xilinx VDMA, and the drm_plane->drm_crtc link
>> would represent the dma channel. With atomic you c
On Wed, Jun 15, 2016 at 9:29 AM, Michel Dänzer wrote:
> On 14.06.2016 18:35, Daniel Vetter wrote:
>> On Tue, Jun 14, 2016 at 11:09 AM, Michel Dänzer
>> wrote:
>>> On 14.06.2016 18:03, Daniel Vetter wrote:
Somehow this escaped us, this is a KMS ioctl which should only be used
by the m
On Wed, Jun 15, 2016 at 05:03:41PM +0900, Michel Dänzer wrote:
> On 14.06.2016 17:06, Daniel Vetter wrote:
> > On Tue, Jun 14, 2016 at 04:25:28PM +0900, Michel Dänzer wrote:
> >> On 14.06.2016 14:53, Daniel Vetter wrote:
> >>> On Tue, Jun 14, 2016 at 11:09:10AM +0900, Michel Dänzer wrote:
>
Hi Yakir,
Yakir Yang rock-chips.com> writes:
> >> Required properties:
> >> -- compatible: "rockchip,rk3288-edp";
> >> +- compatible: "rockchip,rk3288-edp",
> >> + "rockchip,rk3399-edp";
> > As commented by Tomasz on gerrit, there is a pre-existing typo here.
> > Specifically "rockc
Hi Yakir,
Yakir Yang rock-chips.com> writes:
>
> RK3399 and RK3288 shared the same eDP IP controller, only some light
> difference with VOP configure and GRF configure.
>
> Also same misc fix to analogix_dp driver:
> - Hotplug invalid which report by Dan Carpenter
> - Make panel detect to an op
esktop.org/archives/dri-devel/attachments/20160615/2caf6141/attachment.html>
Hi Dave,
just a single fix for a regression introduced by IOMMU API changes in
v4.7.
Regards,
Lucas
The following changes since commit 1a695a905c18548062509178b98bc91e67510864:
Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)
are available in the git repository at:
git://git.pengutronix.de/git/l
It's not obvious at first sight that this is a fastpath, make that
clearer with a goto. Fallout from a discussion with Liviu on irc.
Cc: Liviu.Dudau at arm.com
Acked-by: Liviu.Dudau at arm.com
Signed-off-by: Daniel Vetter
---
.../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h | 4 ++--
drivers/
On Wed, Jun 15, 2016 at 11:48 AM, Jose Abreu wrote:
>
> On 15-06-2016 09:52, Daniel Vetter wrote:
>> On Tue, Jun 14, 2016 at 1:19 PM, Jose Abreu
>> wrote:
I assume that xilinx VDMA is the only way to feed pixel data into your
display pipeline. Under that assumption:
drm_plane
On Wed, Jun 15, 2016 at 12:08:29PM +0200, Daniel Vetter wrote:
> It's not obvious at first sight that this is a fastpath, make that
> clearer with a goto. Fallout from a discussion with Liviu on irc.
>
> Cc: Liviu.Dudau at arm.com
> Acked-by: Liviu.Dudau at arm.com
Nope, I did not agree to *all*
It's not obvious at first sight that this is a fastpath, make that
clearer with a goto. Fallout from a discussion with Liviu on irc.
v2: Drop bogus hunks that crept in.
Cc: Liviu.Dudau at arm.com
Acked-by: Liviu.Dudau at arm.com
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper
On Wed, Jun 15, 2016 at 10:37:24AM +0200, Paul Bolle wrote:
> [Added Sinclair, Thomas, and "VMware Graphics".]
>
> On do, 2016-04-14 at 07:34 -0700, Joe Perches wrote:
> > On Thu, 2016-04-14 at 13:32 +0200, Paul Bolle wrote:
> > > On do, 2016-03-03 at 11:26 +0100, Paul Bolle wrote:
> > > >
> > >
On Tue, Jun 14, 2016 at 08:50:56PM +0200, Daniel Vetter wrote:
> GEM stopped using those a while ago, and no one should ever
> need to use them again to debug legacy horror show drivers.
>
> Nuke it all. Aside: It would kinda be nice if we'd have some
> generic debugfs dumps for at least kms ...
>
On 06/14/2016 01:12 PM, Boris Brezillon wrote:
> Add basic support for the sii902x RGB -> HDMI bridge.
> This driver does not support audio output yet.
>
Thanks for incorporating the comments.
Acked-by: Archit Taneja
> Signed-off-by: Boris Brezillon
> Tested-by: Nicolas Ferre
> ---
> Change
On Tue, Jun 14, 2016 at 08:50:57PM +0200, Daniel Vetter wrote:
> A few things:
> - Rename the cleanup function from drm_master_release to
> drm_legacy_lock_release. It doesn't relase any master stuff, but
> just the legacy hw lock.
> - Hide it in drm_lock.c, which allows us to make a few more f
On Tue, Jun 14, 2016 at 08:50:58PM +0200, Daniel Vetter wrote:
> Master-based auth only exists for the legacy/primary drm_minor, hence
> there can only be one per device. The goal here is to untangle the
> epic dereference games of minor->master and master->minor which is
> just massively confusing
On Tue, Jun 14, 2016 at 08:50:59PM +0200, Daniel Vetter wrote:
> For modern drivers pretty much the only thing drm_master does is
> handling authentication for the primary/legacy drm_minor node. Instead
> of having it all over drm files, move it all together into drm_auth.c.
>
> This patch just do
On Tue, Jun 14, 2016 at 04:18:00PM -0400, Alex Deucher wrote:
> On Thu, Jun 9, 2016 at 2:50 AM, Daniel Vetter wrote:
> > On Wed, Jun 08, 2016 at 06:47:27PM +0200, Lukas Wunner wrote:
> >> Second iteration of my endeavour to rid nouveau, radeon and amdgpu of
> >> runtime pm ref leaks.
> >>
> >> Pat
On Tue, Jun 14, 2016 at 08:51:00PM +0200, Daniel Vetter wrote:
> And pull out the primary_client check to make it really obvious that
> this can't happen on control/render nodes. Bonus that we can avoid the
> master lock in this case.
...as the minor->type is statically assigned on creation and so
On Tue, Jun 14, 2016 at 08:51:01PM +0200, Daniel Vetter wrote:
> Like with drm_master_open protect it with a check for primary_client
> to make it clear that this can't happen on render/control nodes.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open
From: Christian König
As far as I can see no need for a custom implementation any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 37 -
1 file changed, 4 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/dr
From: Christian König
This boosts Xonotic from 38fps to 47fps when artificially limiting VRAM to
256MB for testing. It should improve all CPU bound rendering situations
where we have a lot of swapping to/from VRAM.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |
From: Christian König
It isn't used and not waiting for the GPU after scheduling a move is
actually quite dangerous.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 +--
drivers/gpu/drm/nouveau/nouveau_bo.c| 1 -
drivers/gpu/drm/radeon/radeon_ttm.c | 3
From: Christian König
Instead of using the flag just remember the fence of the last move operation.
This avoids waiting for command submissions pipelined after the move, but
before accessing the BO with the CPU again.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 4
From: Christian König
Free up the memory immediately, remember the last eviction for each domain and
make new allocations depend on the last eviction to be completed.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 49 ++---
drivers/gpu/drm/ttm/ttm_bo_u
From: Christian König
When we pipeline evictions the page directory could already be
moving somewhere else when grab_id is called.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++
2 files changed, 4 insertion
org/archives/dri-devel/attachments/20160615/edd12514/attachment.html>
On Tue, Jun 14, 2016 at 08:51:02PM +0200, Daniel Vetter wrote:
> Another place gone where modern drivers could have hit
> dev->struct_mutex.
>
> To avoid too deeply nesting control flow rework it a bit.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_auth.c | 20 ---
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/20160615/07ad7281/attachment.html>
On Tue, Jun 14, 2016 at 08:51:03PM +0200, Daniel Vetter wrote:
> It's related, and soon authmagic will also use the master_mutex.
>
> There is an ever-so-slightly semantic change here:
> - authmagic will only be cleaned up for primary_client drm_minors. But
> it's impossible to create authmagic
Hi Boris,
On 14 June 2016 at 08:42, Boris Brezillon
wrote:
> Add basic support for the sii902x RGB -> HDMI bridge.
> This driver does not support audio output yet.
>
> Signed-off-by: Boris Brezillon
> Tested-by: Nicolas Ferre
Thanks for sticking with my questions/nitpicking.
FWIW the patch is
On Tue, Jun 14, 2016 at 08:51:04PM +0200, Daniel Vetter wrote:
> Simplifies cleanup, and there's no reason drivers should ever care
> about authmagic at all - it's all handled in the core.
>
> And with that, Ladies and Gentlemen, it's time to pop the champagen
> and celebrate: dev->struct_mutex is
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/fa9903f0/attachment-0001.html>
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/20160615/28842c13/attachment.html>
On Tue, Jun 14, 2016 at 08:51:05PM +0200, Daniel Vetter wrote:
> All protected by dev->master_mutex. And there's no driver callbacks,
> which means no need to sync with old dri1 horror show drivers at all.
> Hence safe to drop the drm legacy BKL from these paths.
>
> Signed-off-by: Daniel Vetter
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/606d9b1b/attachment.html>
On Tue, Jun 14, 2016 at 08:51:06PM +0200, Daniel Vetter wrote:
> Again this is neatly protected by the dev->master_mutex now. There is
> a driver callback both for set and drop, but it's only used by vmwgfx.
> And vmwgfx has it's own solid locking for shared resources (besides
> dev->master_mutex),
On 06/15/2016 01:11 PM, Daniel Vetter wrote:
> On Wed, Jun 15, 2016 at 10:37:24AM +0200, Paul Bolle wrote:
>> [Added Sinclair, Thomas, and "VMware Graphics".]
>>
>> On do, 2016-04-14 at 07:34 -0700, Joe Perches wrote:
>>> On Thu, 2016-04-14 at 13:32 +0200, Paul Bolle wrote:
On do, 2016-03-03 a
On 14 June 2016 at 19:50, Daniel Vetter wrote:
> GEM stopped using those a while ago, and no one should ever
> need to use them again to debug legacy horror show drivers.
>
> Nuke it all. Aside: It would kinda be nice if we'd have some
> generic debugfs dumps for at least kms ...
>
> Signed-off-by
.
--
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/20160615/83baaed0/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160615/b088d744/attachment.html>
Hi Daniel,
On 15-06-2016 09:52, Daniel Vetter wrote:
> On Tue, Jun 14, 2016 at 1:19 PM, Jose Abreu
> wrote:
>>> I assume that xilinx VDMA is the only way to feed pixel data into your
>>> display pipeline. Under that assumption:
>>>
>>> drm_plane should map to Xilinx VDMA, and the drm_plane->drm
Hello there,
>yup, looks like we can drop the two pipe<0 checks.
Righto.
>Care to send a patch?
Oh dear. My success rate with patches is near zero. Maybe something
like this might be suitable:
*** linux-3.7-rc3/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c.sav
2016-06-15 10:58:04.868619030 +0100
---
This series patches mainly for ARM64 supporting.
To do this, it first add virtual iommu slave device which DRM can attach to,
convert DRM driver to use common iommu API instead of the ARM32
functions, and then use DMA API in iommu driver to map, to flush cache.
Mainly changes of V3:
- Instead
From: Simon Xue
Even though the iommu shares irq with its master, using the *dev of iommu
instead of master's *dev for devm_{request,free}_irq makes things clear.
Signed-off-by: Simon Xue
Signed-off-by: Shunqian Zheng
Reviewed-by: Tomasz Figa
---
drivers/iommu/rockchip-iommu.c | 4 ++--
1 fi
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-by: Tomasz Figa
---
drivers/iommu/r
An virtual master device like DRM need to attach to iommu
domain to share the mapping with VOPs(the one with actual
iommu slaves).
DRM attaches to iommu and allocates buffers before VOPs enabled,
which means there may have not real iommu devices can be used
to do dma mapping.
This patch creates a
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.
The general idea is domain_alloc(), attach_device() and
arch_setup_dma_ops() to set dma_ops manually for DRM at the last.
Signed-off-
Use DMA API instead of architecture internal functions like
__cpuc_flush_dcache_area() etc.
To support the virtual device like DRM the virtual slave iommu
added in the previous patch, attaching to which the DRM can use
it own domain->dev for dma_map_*(), dma_sync_*() even VOP is disabled.
With th
From: Simon Xue
This patch makes it possible to compile the rockchip-iommu driver on
ARM64 platform to be used with 64-bit SoCs equipped with this type
of IOMMU.
Signed-off-by: Simon Xue
Signed-off-by: Shunqian Zheng
Reviewed-by: Tomasz Figa
---
drivers/iommu/Kconfig | 2 +-
1 file changed,
On Tue, Jun 14, 2016 at 08:51:07PM +0200, Daniel Vetter wrote:
> 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 ch
On 14 June 2016 at 19:50, Daniel Vetter wrote:
> A few things:
> - Rename the cleanup function from drm_master_release to
> drm_legacy_lock_release. It doesn't relase any master stuff, but
> just the legacy hw lock.
> - Hide it in drm_lock.c, which allows us to make a few more functions
> st
If a driver wants to more precisely control its initialisation and in
particular, defer registering its interfaces with userspace until after
everything is setup, it also needs to defer registering the connectors.
As some devices need more work during registration, add a callback so
that drivers ca
As we now can call drm_connector_unregister() multiple times, provide a
failsafe unregister for a connector when cleaning it up.
v2: Add a WARN to catch any connectors that are still visible to
userspace when we come to destoy them.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
Cc: dri-devel at l
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() to drm_dev_register() and not suffer
from any backwards compatibility i
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() to drm_dev_register() and not suffer
from any backwards compatibility i
In order to allow drivers to pack their privates and drm_device into one
struct (e.g. for subclassing), export the initialisation routines for
struct drm_device.
v2: Missed return ret. That error path had only one job to do!
v3: Cross-referencing drm_dev_init/drm_dev_alloc in kerneldoc, fix
missed
Protect against drivers that may try to register the connector more
than once, or who try to unregister it multiple times.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
Cc: dri-devel at lists.freedesktop.org
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 9 +
include/drm/drm
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() to drm_dev_register() and not suffer
from any backwards compatibility i
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() to drm_dev_register() and not suffer
from any backwards compatibility i
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() to drm_dev_register() and not suffer
from any backwards compatibility i
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() to drm_dev_register() and not suffer
from any backwards compatibility i
Rather than have both drm_dp_aux lock within its transfer, and i2c to
lock around the transfer, use the same lock by filling in the locking
callbacks that i2c wants to use. We require our own hw_mutex as we
bypass i2c_transfer for drm_dp_dpcd_access().
Signed-off-by: Chris Wilson
Cc: Dave Airlie
When trying to split up the initialisation phase and the registration
phase, one immediate problem encountered is trying to use our own i2c
devices before registration with userspace (to read EDID during device
discovery). drm_dp_aux in particular only offers an interface for setting
up the device
On 06/15/16 11:39, Jyri Sarha wrote:
> Some fixes and cleanups that should get merged to tilcdc even if my
> atomic changes are still a work in progress.
>
I forgot to add changelog. So here it is:
Changes since first version:
- "drm/tilcdc: Restore old dpms state in pm_resume()"
- Fix typos f
On 14 June 2016 at 19:50, Daniel Vetter wrote:
> Master-based auth only exists for the legacy/primary drm_minor, hence
> there can only be one per device. The goal here is to untangle the
> epic dereference games of minor->master and master->minor which is
> just massively confusing.
>
Good riddan
Alex do you want to pull that in through your branches or should I send
Dave a separate pull request for the TTM changes?
BTW: I'm trying to enable this on radeon as well. In theory it should
work out of the box.
Regards,
Christian.
Am 15.06.2016 um 13:44 schrieb Christian König:
> From: Chri
Using the common hdmi-codec driver to support hdmi audio function.
Signed-off-by: Yakir Yang
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 237 ++-
drivers/gpu/drm/rockchip/inno_hdmi.h | 2 +
2 files changed, 237 insertions(+), 2 deletions(-)
diff --git a/drivers/
Using I2S as the audio input source, and force the mclk_fs to 256.
Signed-off-by: Yakir Yang
---
arch/arm/boot/dts/rk3036.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 843d2be..ecff071 100644
-
Enable the basic hdmi audio function on rk3036 kylin board.
Signed-off-by: Yakir Yang
---
arch/arm/boot/dts/rk3036-kylin.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/rk3036-kylin.dts
b/arch/arm/boot/dts/rk3036-kylin.dts
index 1df1557..070cfe1 100644
--- a/arch/a
On Fri, Jun 03, 2016 at 03:21:30PM +0100, Russell King wrote:
> Convert DT component matching to use component_match_add_release().
>
> Signed-off-by: Russell King
> ---
> drivers/iommu/mtk_iommu.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
Applied, thanks.
On Tue, Jun 14, 2016 at 07:50:58PM +0200, Daniel Vetter wrote:
> stall_checks carefully picked out the right commit to stall on, then
> promptly used the wrong variable. Due to the break in the next loop
> iteration this could be the 3rd commit, or if the list only has 2
> entries commit would now
Hi Shunqian,
On Wed, Jun 15, 2016 at 9:04 PM, Shunqian Zheng
wrote:
> An virtual master device like DRM need to attach to iommu
> domain to share the mapping with VOPs(the one with actual
> iommu slaves).
> DRM attaches to iommu and allocates buffers before VOPs enabled,
> which means there may
On Wed, Jun 15, 2016 at 12:24:26PM +0200, Daniel Vetter wrote:
> It's not obvious at first sight that this is a fastpath, make that
> clearer with a goto. Fallout from a discussion with Liviu on irc.
>
> v2: Drop bogus hunks that crept in.
>
> Cc: Liviu.Dudau at arm.com
> Acked-by: Liviu.Dudau at
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/20160615/6f957803/attachment.html>
Hello,
This is the fifth revision of the driver for the Mali Display Processors (Mali
DP).
Currently, the driver supports the Display Engine found in Mali DP500, DP550
and DP650, with up to 3 planes that can be rotated by the hardware. There are
features that the hardware supports that are not cu
1 - 100 of 168 matches
Mail list logo
