https://bugzilla.kernel.org/show_bug.cgi?id=85351
--- Comment #5 from Ralf-Peter Rohbeck ---
The latest Debian 4.6 kernel (4.6.0-1-amd64 #1 SMP Debian 4.6.1-1 (2016-06-06))
still shows
[ 20.413954] [drm:mgag200_driver_load [mgag200]] *ERROR* can't reserve VRAM
[ 20.413962] mgag200 :06:04.
On Wed, Jun 08, 2016 at 04:07:59PM -0300, Gustavo Padovan wrote:
> Hi Greg,
>
> Any comment on this?
I am just starting to catch up on patches, please give me some time,
staging patches are at the bottom of my priority list, sorry.
greg k-h
rc2 to see if I can find
the culprit commit on the kernel side.
--
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/20160608/dcde4b
.
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160608/5e5f74c4/attachment.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160608/bd17bdce/attachment.html>
From: Simon Xue
Signed-off-by: Simon Xue
Signed-off-by: Shunqian Zheng
---
drivers/iommu/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index ad08603..5572621 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconf
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
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-
An virtual iommu without reg or interrupts for display.
Adding this according to iommu driver changes.
Signed-off-by: Shunqian Zheng
---
arch/arm/boot/dts/rk3288.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 7fa
An virtual master device like DRM need to attach to iommu
domain to share the domain with VOP(the one with actual
iommu slave). We currently check the group is NULL to indicate
a virtual master, which is not true since we decide to use
the common iommu api to attach device in DRM.
With this patch,
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
---
drivers/iommu/rockchip-iommu.c | 1 +
1 f
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
---
drivers/iommu/rockchip-iommu.c | 4 ++--
1 file changed, 2 insertions(+
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.
The v2 patches make a lot changes vs
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160608/8d102bbf/attachment.html>
On 8 June 2016 at 18:35, Rob Herring wrote:
> On Wed, Jun 8, 2016 at 1:51 AM, Marek Szyprowski
> wrote:
>> Change return value back to -ENODEV when no region is defined for given
>> device. This restores old behavior of this function, as some drivers rely
>> on such error code.
>>
>> Reported-by:
f the crash?
--
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/20160608/5a6345d5/attachment.html>
bbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160608/9742bebf/attachment-0001.html>
|Linux (All)
--
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/20160608/ef7690be/attachment.html>
.org/archives/dri-devel/attachments/20160608/e5541642/attachment.html>
Hello Inki,
Thanks for your feedback.
On 06/08/2016 07:09 PM, Inki Dae wrote:
> Hi Javier,
>
> 2016ë
06ì 02ì¼ 23:20ì Javier Martinez Canillas ì´(ê°) ì´ ê¸:
>> Commit a6f75aa161c5 ("drm/exynos: fimd: add HW trigger support") added
>> hardware trigger support to the FIMD controller driv
, 3.19-4.1 crash always after few minutes(max. 10) even latest
4.1.25
--
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/20160
The Sharp LQ123P1JX31 is an 12.3", 2400x1600 TFT-LCD panel connected
using eDP interfaces.
Signed-off-by: Yakir Yang
---
Changes in v2:
- Add detail timing of Sharp LQ123P1JX31 panel in v2
drivers/gpu/drm/panel/panel-simple.c | 26 ++
1 file changed, 26 insertions(+)
di
The Sharp LQ123P1JX31 is an 12.3" 2400x1600 TFT-LCD panel
connected using eDP interfaces.
Signed-off-by: Yakir Yang
---
Changes in v2:
- Add dt-bindings of Sharp LQ123P1JX31 panel in v2
.../devicetree/bindings/display/panel/sharp,lq123p1jx31.txt| 7 +++
1 file changed, 7 insertions(
The Samsung LSN122DL01-C01 is an 12.2" 2560x1600 (WQXGA) TFT-LCD panel
connected using eDP interfaces.
Signed-off-by: Yakir Yang
---
Changes in v2: None
drivers/gpu/drm/panel/panel-simple.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/panel/pane
The Samsung LSN122DL01-C01 is an 12.2" 2560x1600 (WQXGA) TFT-LCD
panel connected using eDP interfaces.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
---
Changes in v2:
- Add Rob's acked for dt-bindings of Samsung LSN122DL01 panel
.../devicetree/bindings/display/panel/samsung,lsn122dl01-c01.t
The LG LP097QX1-SPA1 is an 9.7", 2048x1536 (QXGA) TFT-LCD panel
connected using eDP interfaces.
Signed-off-by: Yakir Yang
---
Changes in v2: None
drivers/gpu/drm/panel/panel-simple.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simpl
The LG LP097QX1-SPA1 is an 9.7", 2048x1536 (QXGA) TFT-LCD panel
connected using eDP interfaces.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
---
Changes in v2:
- Add Rob's acked for dt-bindings of LG LP097QX1-SPA1 panel
.../devicetree/bindings/display/panel/lg,lp097qx1-spa1.txt | 7
ions(-)
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160608/ee0302c5/attachment.html>
Mark,
On 06/01/2016 09:57 AM, Mark yao wrote:
> On 2016å¹´05æ24æ¥ 13:02, Yakir Yang wrote:
>> eDP controller need to declare which vop provide the video source,
>> and it's defined in GRF registers.
>>
>> But different chips have different GRF register address, so we need to
>> create a device
On Fri, Jun 03, 2016 at 08:21:50PM +0200, Daniel Vetter wrote:
> On Fri, Jun 03, 2016 at 09:30:06AM +0200, Lukas Wunner wrote:
> > On Wed, Jun 01, 2016 at 04:40:12PM +0200, Daniel Vetter wrote:
> > > On Wed, Jun 01, 2016 at 02:36:41PM +0200, Lukas Wunner wrote:
> > > > On Wed, May 25, 2016 at 03:43
Marc, Javier
On 06/08/2016 03:44 PM, Marc Zyngier wrote:
> On Wed, 8 Jun 2016 09:28:32 +0800
> Yakir Yang wrote:
>
>> Hi Javier,
>>
>> On 06/08/2016 01:06 AM, Javier Martinez Canillas wrote:
>>> Hello Yakir,
>>>
>>> On 03/17/2016 05:47 PM, Heiko Stübner wrote:
Split the dp core driver from
On Wed, Jun 08, 2016 at 12:44:12PM -0400, Alex Deucher wrote:
> If the ring and IB tests pass on resume, you should be good to go.
Yap, they do. I pasted that output earlier but here it is again:
[ 64.745988] [drm] ring test on 0 succeeded in 1 usecs
[ 64.920633] [drm] ring test on 5 succeede
Second iteration of my endeavour to rid nouveau, radeon and amdgpu of
runtime pm ref leaks.
Patches 1 to 8 are identical to v1.
Patch 9 of v1 modified the DRM core to turn off all CRTCs on driver
unload. Based on feedback by Daniel Vetter, I've replaced this with
a helper to turn off all CRTCs, w
nouveau_drm_load() calls pm_runtime_put() if nouveau_runtime_pm != 0,
but nouveau_drm_unload() calls pm_runtime_get_sync() unconditionally.
We therefore leak a runtime pm ref whenever nouveau is loaded with
runpm=0 and then unloaded. The GPU will subsequently never runtime
suspend even if nouveau i
The PCI core calls pm_runtime_forbid() on device probe in pci_pm_init(),
making this the default state when nouveau is loaded. nouveau_drm_load()
therefore calls pm_runtime_allow(), but there's no pm_runtime_forbid()
in nouveau_drm_unload() to balance it. Add it so that we leave the
device in the s
radeon_driver_load_kms() calls pm_runtime_put_autosuspend() if
radeon_is_px(dev), but radeon_driver_unload_kms() calls
pm_runtime_get_sync() unconditionally. We therefore leak a runtime pm
ref whenever radeon is unloaded on a non-PX machine or if runpm=0. The
GPU will subsequently never runtime sus
radeon_device_init() returns an error if either of the two calls to
radeon_init() fail. One level up in the call stack,
radeon_driver_load_kms() will then skip runtime pm initialization and
call radeon_driver_unload_kms(), which acquires a runtime pm ref that
is leaked.
Balance by releasing a runt
The PCI core calls pm_runtime_forbid() on device probe in pci_pm_init(),
making this the default state when radeon is loaded.
radeon_driver_load_kms() therefore calls pm_runtime_allow(), but there's
no pm_runtime_forbid() in radeon_driver_unload_kms() to balance it. Add
it so that we leave the devi
amdgpu_driver_load_kms() calls pm_runtime_put_autosuspend() if
amdgpu_device_is_px(dev), but amdgpu_driver_unload_kms() calls
pm_runtime_get_sync() unconditionally. We therefore leak a runtime pm
ref whenever amdgpu is unloaded on a non-PX machine or if runpm=0. The
GPU will subsequently never runt
If an error occurs in amdgpu_device_init() after adev->rmmio has been
set, its caller amdgpu_driver_load_kms() will skip runtime pm
initialization and call amdgpu_driver_unload_kms(), which acquires a
runtime pm ref that is leaked.
Balance by releasing a runtime pm ref in the error path of
amdgpu_
The PCI core calls pm_runtime_forbid() on device probe in pci_pm_init(),
making this the default state when amdgpu is loaded.
amdgpu_driver_load_kms() therefore calls pm_runtime_allow(), but there's
no pm_runtime_forbid() in amdgpu_driver_unload_kms() to balance it. Add
it so that we leave the devi
Turning off a single CRTC or all active CRTCs of a DRM device is a
fairly common pattern. Add helpers to avoid open coding this everywhere.
The name was chosen to be consistent with drm_plane_force_disable().
Cc: Daniel Vetter
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/drm_crtc.c | 45 +++
nouveau leaks a runtime pm ref if at least one CRTC is enabled on
unload. The ref is taken by nouveau_crtc_set_config() and held as long
as a CRTC is in use.
nv04_display_destroy() should solve this by turning off all CRTCs, but
(1) nv50_display_destroy() doesn't do the same and
(2) it's broken
radeon leaks a runtime pm ref if at least one CRTC is enabled on unload.
The ref is taken by radeon_crtc_set_config() and held as long as a CRTC
is in use. Fix by turning off all CRTCs on unload.
Cc: Alex Deucher
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/radeon/radeon_display.c | 1 +
1 f
amdgpu leaks a runtime pm ref if at least one CRTC is enabled on unload.
The ref is taken by amdgpu_crtc_set_config() and held as long as a CRTC
is in use. Fix by turning off all CRTCs on unload.
Cc: Alex Deucher
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
Use shiny new drm_crtc_force_disable() instead of open coding the same.
No functional change intended.
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/drm_crtc.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
ind
Use shiny new drm_crtc_force_disable() instead of open coding the same.
No functional change intended.
Cc: Francisco Jerez
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/i2c/ch7006_drv.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i2c/ch7006_drv
Use shiny new drm_crtc_force_disable() instead of open coding the same.
No functional change intended.
Cc: Ben Skeggs
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/di
On Wed, Jun 08, 2016 at 05:28:53PM +0200, Grigori Goronzy wrote:
> Are you sure it is using accelerated decoding? CPU load should be just 1-2%.
Ha, good point. So with mplayer vo=vdpau, CPU load was at something over 12%.
Doing:
$ mpv --vo=vdpau --hwdec=vdpau $file
(+) Video --vid=1 (*) (h264)
On Wed, Jun 8, 2016 at 6:19 PM, Daniel Vetter wrote:
> But the main one is kms_flip - this is one shockingly nasty testcase ;-)
Also note that kms_flip wasn't just run on i915, but also on other
drivers in this conversion (not all iirc), thanks to collabora's work
to port igt testcase to generic
On Wed, Jun 8, 2016 at 5:54 PM, Chris Wilson
wrote:
>
> On Wed, Jun 08, 2016 at 05:05:04PM +0200, Daniel Vetter wrote:
>> On Wed, Jun 08, 2016 at 04:44:24PM +0200, Maarten Lankhorst wrote:
>> > Op 08-06-16 om 14:19 schreef Daniel Vetter:
>> > > Once that's done stall can be set to false in swap
Hi Eric,
On Wednesday 08 Jun 2016 11:27:32 Eric Engestrom wrote:
> On Wed, Jun 08, 2016 at 02:35:35AM +0300, Laurent Pinchart wrote:
> > Various pieces of information about DRM formats (number of planes, color
> > depth, chroma subsampling, ...) are scattered across different helper
> > functions
On 2016-06-08 15:47, Borislav Petkov wrote:
> On Wed, Jun 08, 2016 at 03:30:34PM +0200, Christian König wrote:
>
>> Try forcing mplayer to use VDPAU with "mplayer -vo vdpau $file".
>
> All good. Actually, this hw accel thing is much better, I better make
> it
> default :-P
>
Are you sure it i
To facilitate easier reviewing this is split out from the overall
nonblocking commit rework. It just rolls out the helper functions
and uses them in the main drm_atomic_helper_commit() function
to make it clear where in the flow they're used.
The next patch will actually split drm_atomic_helper_co
On Wed, Jun 08, 2016 at 04:44:24PM +0200, Maarten Lankhorst wrote:
> Op 08-06-16 om 14:19 schreef Daniel Vetter:
> > Design ideas:
> >
> > - split up the actual commit into different phases, and have
> > completions for each of them. This will be useful for the future
> > when we want to interl
On Wed, Jun 08, 2016 at 05:05:04PM +0200, Daniel Vetter wrote:
> On Wed, Jun 08, 2016 at 04:44:24PM +0200, Maarten Lankhorst wrote:
> > Op 08-06-16 om 14:19 schreef Daniel Vetter:
> > > Once that's done stall can be set to false in swap_states.
> > >
> > > Features: Contains bugs because totally
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160608/6a4f7e8f/attachment.html>
Op 08-06-16 om 14:19 schreef Daniel Vetter:
> Design ideas:
>
> - split up the actual commit into different phases, and have
> completions for each of them. This will be useful for the future
> when we want to interleave phases much more aggressively, for e.g.
> queue depth > 1. For not it's
Op 08-06-16 om 14:19 schreef Daniel Vetter:
> Split out from my big nonblocking atomic commit helper code as prep
> work. While add it, also add some neat asciiart to document how it's
> supposed to be used.
>
> v2: Resurrect misplaced hunk in the kerneldoc.
>
> Tested-by: Tomeu Vizoso
> Cc: Maart
Op 08-06-16 om 14:19 schreef Daniel Vetter:
> To facilitate easier reviewing this is split out from the overall
> nonblocking commit rework. It just rolls out the helper functions
> and uses them in the main drm_atomic_helper_commit() function
> to make it clear where in the flow they're used.
>
>
On Wed, Jun 08, 2016 at 03:24:01PM +0100, Chris Wilson wrote:
> On Wed, Jun 08, 2016 at 02:19:08PM +0200, Daniel Vetter wrote:
> > Note that I didn't start garbage collecting all the legacy flip code
> > yet, to make it easier to revert this. But there will be _lots_ of
> > code that can be removed
On Wed, Jun 08, 2016 at 04:17:55PM +0200, Maarten Lankhorst wrote:
> Op 08-06-16 om 14:18 schreef Daniel Vetter:
> > atomic_flush seems to be the right place, but I'm not entirely sure
> > whether this will catch them all. It could be that when disabling the
> > crtc we'll miss the vblank.
> >
> >
On Wed, Jun 08, 2016 at 04:14:38PM +0200, Maarten Lankhorst wrote:
> Op 08-06-16 om 14:18 schreef Daniel Vetter:
> > The drm core has a nice ready-made helper for exactly the simple case
> > where it should fire on the next vblank.
> >
> > Note that arming the vblank event in _begin is probably too
Op 08-06-16 om 14:19 schreef Daniel Vetter:
> Committing with block it is not.
>
> Thanks to the fixed up vblank event handling we can just use the
> helper support for nonblocking commits now.
>
> Cc: Carlos Palminha
> Cc: Alexey Brodkin
> Cc: linux-snps-arc at lists.infradead.org
> Signed-off-b
Op 08-06-16 om 14:19 schreef Daniel Vetter:
> This is part of what atomic must implement. And it's also required
> to be able to use the helper nonblocking support.
>
> v2: Always send out the drm event, remove the planes_changed check.
What happened to the patch that added event tests to the kms_a
On Wed, Jun 08, 2016 at 10:06:23AM -0400, Jerome Glisse wrote:
> To be clear, you mean that after hibernation video acceleration keeps working
> ?
Apparently. At lest the vdpau output looks fine to me.
> Can you copy radeon dmesg after hibernation cycle (once you resumed
> from hibernation).
$
Op 08-06-16 om 14:18 schreef Daniel Vetter:
> atomic_flush seems to be the right place, but I'm not entirely sure
> whether this will catch them all. It could be that when disabling the
> crtc we'll miss the vblank.
>
> While at it nuke the dummy functions.
>
> v2: Be more robust and either arm, wh
Op 08-06-16 om 14:18 schreef Daniel Vetter:
> No idea how exactly fsl-du commits hw state changes, but here in flush
> is probably the safest place.
>
> While at it nuke the dummy functions.
>
> v2: Be more robust and either arm, when the CRTC is on, or just send
> the event out right away.
>
> Cc:
Op 08-06-16 om 14:18 schreef Daniel Vetter:
> The drm core has a nice ready-made helper for exactly the simple case
> where it should fire on the next vblank.
>
> Note that arming the vblank event in _begin is probably too early, and
> might easily result in the vblank firing too early, before the
Op 08-06-16 om 14:18 schreef Daniel Vetter:
> This is just used for cleanup in preclose, and with the reworked event
> handling code this is now done properly by the core.
>
> Nuke it!
>
> But it also shows that arc totally fails at sending out drm events for
> flips. Next patch will hack that up.
Hey,
Op 08-06-16 om 14:18 schreef Daniel Vetter:
> - dev is redundant, we have state->atomic
> - add stall parameter, which must be set when swapping needs to stall
> for preceeding commits to stop looking at ->state pointers. Currently
> all drivers need this to be, just prep work for a glori
Hi Greg,
Any comment on this?
Gustavo
2016-05-31 Gustavo Padovan :
> From: Gustavo Padovan
>
> Hi,
>
> The following patches do a clean up on the sw_sync inteface. It starts by
> removing struct sync_timeline_ops, which was creating unecessary wrappers
> in the code and the start to
Add description of ADV7533. Add the required and optional properties that
are specific to it.
Cc: devicetree at vger.kernel.org
Acked-by: Rob Herring
Signed-off-by: Archit Taneja
---
.../bindings/display/bridge/adi,adv7511.txt| 26 +-
1 file changed, 21 insertions(
Lower modes on ADV7533 require lower number of DSI lanes for correct
operation. If ADV7533 is being used with 4 DSI lanes, then switch the
lanes to 3 when the target mode's pixel clock is less than 80 Mhz.
Based on patch by Andy Green
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/i2c/adv751
ADV7533 provides an internal timing generator for certain modes that it
can't use the DSI clock directly.
We've observed that HDMI is more stable with the internal timing
generator, especially if there are instabilities in the DSI clock source.
The data spec also seems to recommend the usage of th
In order to pass DSI specific parameters to the DSI host, we need the
driver to create a mipi_dsi_device DSI device that attaches to the
host.
Use of_graph helpers to get the DSI host DT node. Create a MIPI DSI
device using this host. Finally, attach this device to the DSI host.
Populate DT param
ADV7533 is a DSI to HDMI encoder chip. It is a derivative of ADV7511,
with additional blocks to translate input DSI data to parallel RGB
data. Besides the ADV7511 I2C register map, it has additional registers
that require to be configured to activate the DSI Rx block.
Create a new config that enab
When the adv7511 i2c client doesn't have an interrupt line, we observe a
deadlock on caused by trying to lock drm device's mode_config.mutex twice
in the same context.
Here is the sequence that causes it:
ioctl DRM_IOCTL_MODE_GETCONNECTOR from userspace
drm_mode_getconnector (acquires mode_conf
We don't want to use the old i2c slave encoder interface anymore.
Remove that and make the i2c driver create a drm_bridge entity instead.
Converting to bridges helps because the kms drivers don't need to
exract encoder slave ops from this driver and use it within their
own encoder/connector ops.
ADV7533 is a DSI to HDMI encoder chip. It's like ADV7511, but with an
additional DSI RX block that takes in DSI video mode output.
Trying to get this driver merged has had some challenges:
- ADV7533 has an I2C control bus, but acts as a DSI peripheral too.
After discussions, it was concluded th
On Wed, Jun 08, 2016 at 03:47:12PM +0200, Borislav Petkov wrote:
> All good. Actually, this hw accel thing is much better, I better make it
> default :-P
And yes, this is with Jérôme's fix to exclude r600 and r700 from hard
reset before hibernation. And after a s2d cycle I did earlier.
--
Rega
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160608/68b50faa/attachment.html>
On Wed, Jun 08, 2016 at 03:30:34PM +0200, Christian König wrote:
> Try forcing mplayer to use VDPAU with "mplayer -vo vdpau $file".
All good. Actually, this hw accel thing is much better, I better make it
default :-P
libavformat version 56.23.105 (internal)
libavformat file format detected.
[la
Hi,
On 06/07/2016 05:18 PM, Boris Brezillon wrote:
> For all outputs except DSI we have a 1:1 relationship between connectors
> and encoders and the driver is relying on the atomic helpers: we can
> drop the custom ->best_encoder() and let the core call
> drm_atomic_helper_best_encoder() for us.
Yes, exactly.
> VO: [xv] 1280x720 => 1280x720 Planar YV12
Mplayer is using xv without any acceleration (except for color space
conversion).
Try forcing mplayer to use VDPAU with "mplayer -vo vdpau $file".
Regards,
Christian.
Am 08.06.2016 um 15:26 schrieb Borislav Petkov:
> On Wed, Jun 08, 201
On Wed, Jun 08, 2016 at 01:50:28PM +0200, Christian König wrote:
> What's the output of mplayer? Mplayer usually uses video acceleration when
> it is available.
Something like this?
libavformat version 56.23.105 (internal)
libavformat file format detected.
[lavf] stream 0: video (h264), -vid 0
[
On Wed, Jun 08, 2016 at 02:19:08PM +0200, Daniel Vetter wrote:
> Note that I didn't start garbage collecting all the legacy flip code
> yet, to make it easier to revert this. But there will be _lots_ of
> code that can be removed once this is tested on all platforms.
>
> FIXME: obj->frontbuffer_bi
The following changes since commit af8c34ce6ae32addda3788d54a7e340cad22516b:
Linux 4.7-rc2 (2016-06-05 14:31:26 -0700)
are available in the git repository at:
http://git.agner.ch/git/linux-drm-fsl-dcu.git fixes-for-v4.7-rc3
for you to fetch changes up to ce492b3b8f99cf9d2f807ec22d8805c996a0
On Fri, Jun 03, 2016 at 11:15:11PM +0800, Chris Zhong wrote:
> Add support for cdn DP controller which is embedded in the rk3399
> SoCs. The DP is compliant with DisplayPort Specification,
> Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
> There is a uCPU in DP controller, it n
On Wed, Jun 08, 2016 at 02:18:59PM +0200, Daniel Vetter wrote:
> Just a bit of drive-by ocd.
>
> v2: Improve per Liviu's feedback.
>
> Cc: Liviu Dudau
> Signed-off-by: Daniel Vetter
Acked-by: Liviu Dudau
> ---
> include/drm/drm_atomic.h | 10 ++
> 1 file changed, 10 insertions(+)
>
Hi!
> Could you try to apply the following patch [1], hopefully this fixes
> the issue for you.
>
> [1] https://patchwork.freedesktop.org/patch/89111/
I updated the kernel, applied the patch and yes, that helped.
Thanks!
P
On Wed, 8 Jun 2016 14:19:15 +0200
Daniel Vetter wrote:
> Drivers transitioning to atomic might not yet want to enable full
> DRIVER_ATOMIC support when it's not entirely working. But using atomic
> internally makes a lot more sense earlier.
>
> Instead of spreading such flags to more places I f
Add Sii9022 DT bindings description.
Signed-off-by: Boris Brezillon
Acked-by: Rob Herring
---
Changes since v6:
- make 'reset-gpios' optional
Changes since v1:
- rename doc file
- s/sil902/sii902/
---
.../devicetree/bindings/display/bridge/sii902x.txt | 35 ++
1 file change
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
---
Hi Archit,
I recently learned you were the drm/bridge maintainer, and I realize
you were not in Cc of the previous versions.
Once you
kernel-doc wants a : at the end.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 73b345323cf1..2bcba98976a2 100644
---
Rockchip just blew up here on testing, because I removed some "is this
crtc already disabled/enabled" state tracking from callbacks (not needed
with atomic). Turns out that was needed to work around rockchip still
calling legacy helper code.
Since me explaining on irc/mailing-list plus kerneldoc i
Atomic drivers are supposed to do hw/sw state reset with the
drm_mode_config_reset() call right above it.
Cc: Benjamin Gaignard
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/sti/sti_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/s
This was somehow lost between v3 and the merged version in Maarten's
patch merged as:
commit f2d580b9a8149735cbc4b59c4a8df60173658140
Author: Maarten Lankhorst
Date: Wed May 4 14:38:26 2016 +0200
drm/core: Do not preserve framebuffer on rmfb, v4.
Actual code copied from Maarten's patch, b
Drivers transitioning to atomic might not yet want to enable full
DRIVER_ATOMIC support when it's not entirely working. But using atomic
internally makes a lot more sense earlier.
Instead of spreading such flags to more places I figured it's simpler
to just check for mode_config->funcs->atomic_com
Now that the core helpers support nonblocking atomic commits there's
no need to invent that wheel separately (instead of fixing the bug in
the atomic implementation of virtio, as it should have been done!).
Cc: Gerd Hoffmann
Tested-by: Gerd Hoffmann
Reviewed-by: Gerd Hoffmann
Signed-off-by: Dan
1 - 100 of 169 matches
Mail list logo
