Hello,
Various pieces of information about DRM formats (number of planes, color
depth, chroma subsampling, ...) are scattered across different helper
functions in the DRM core. Callers of those functions often need to access
more than a single parameter of the format, leading to inefficiencies due
The drm_crtc.c file is a mess, making the ABI documentation confusing
since all functions are in the same bag. Split the format-related
helpers to a new drm_fourcc.c file.
Signed-off-by: Laurent Pinchart
---
Documentation/DocBook/gpu.tmpl | 5 +
drivers/gpu/drm/Makefile | 2 +-
drivers
Various pieces of information about DRM formats (number of planes, color
depth, chroma subsampling, ...) are scattered across different helper
functions in the DRM core. Callers of those functions often need to
access more than a single parameter of the format, leading to
inefficiencies due to mult
Turn the drm_format_*() helpers into wrappers around the drm_format_info
lookup function to centralize all format information in a single place.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_fourcc.c | 180 ---
1 file changed, 34 insertions(+), 1
Replace calls to the drm_format_*() helper functions with direct use of
the drm_format_info structure. This improves efficiency by removing
duplicate lookups.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_crtc.c | 100 +---
drivers/gpu/drm/drm_f
The format helpers have historically treated unsupported formats as part
of the default case, returning values that are likely wrong. We can't
change this behaviour now without risking breaking drivers in difficult
to detect ways, but we can WARN on unsupported formats to catch faulty
callers.
The
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160608/820cc91e/attachment.html>
On 07.06.2016 20:38, Liu, Monk wrote:
>
>> There's something else about these two patches I'm a bit worried about:
>
>> The GPU should only read data from ring buffers and IBs that we previously
>> explicitly wrote there. I'm afraid these patches might just paper over
>> bugs elsewhere, which mig
On 07.06.2016 23:07, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Replace the legacy drm_vblank_{on,off}() with the new helper functions.
>
> Signed-off-by: Gustavo Padovan
Patches 6 & 8-10 are
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | htt
On 06/03/2016 08:58 PM, Thierry Reding wrote:
> From: Thierry Reding
>
> Implement a uevent callback for devices on the MIPI DSI bus. This
> callback will append MODALIAS information to the uevent and allow
> modules to be loaded when devices are added to the bus.
Reviewed-by: Archit Taneja
>
ing 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/1d3469ff/attachment-0001.html>
t was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160608/0929abdc/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160608/bd7b6f85/attachment.html>
ktop.org/archives/dri-devel/attachments/20160608/d1bdb734/attachment.html>
ytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160608/32beb163/attachment.sig>
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: Liviu Dudau
Fixes: 59ce4039727ef40 ("of: reserved_mem: add support for using more than
one region for given dev
Hi All,
On 2016-06-07 16:34, liviu.dudau at arm.com wrote:
> On Tue, Jun 07, 2016 at 03:11:14PM +0100, Robin Murphy wrote:
>> Hi Liviu,
>>
>> On 07/06/16 14:35, liviu.dudau at arm.com wrote:
>>> On Tue, Jun 07, 2016 at 01:06:00PM +0100, Robin Murphy wrote:
Having just inadvertently merged -n
On 06/08/2016 08: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: Liviu Dudau
> Fixes: 59ce4039727ef40 ("of: reserved_mem: add
On Tue, Jun 07, 2016 at 05:50:02PM +0100, Eric Engestrom wrote:
> On Mon, Jun 06, 2016 at 09:14:51PM +0300, Laurent Pinchart wrote:
> > The function has no side effect and its returned values are ignored,
> > don't call it.
> >
> > Signed-off-by: Laurent Pinchart
>
> Reviewed-by: Eric Engestrom
Am 07.06.2016 um 23:51 schrieb Jerome Glisse:
>> On Mon, Jun 06, 2016 at 05:40:19PM -0400, Jerome Glisse wrote:
>>> Brokens how ? Symptoms ?
>> Whoops, sorry, I meant to elaborate...
>>
>> After doing:
>>
>> echo "shutdown" > /sys/power/disk
>> echo "disk" > /sys/power/state
>>
>>
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 exynos directory to bridge directory,
>> and rename the core driver to analogix_dp_*, rename the platform
>> code to exynos_dp.
>>
>>
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 exynos directory to bridge directory,
> >> and rename the core
On Wed, Jun 08, 2016 at 08:58:33AM +0200, Marek Szyprowski wrote:
> Hi All,
Hi Marek,
>
>
> On 2016-06-07 16:34, liviu.dudau at arm.com wrote:
> >On Tue, Jun 07, 2016 at 03:11:14PM +0100, Robin Murphy wrote:
> >>Hi Liviu,
> >>
> >>On 07/06/16 14:35, liviu.dudau at arm.com wrote:
> >>>On Tue, Ju
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160608/1a6dc507/attachment.html>
Hi Boris,
On 7 June 2016 at 12:59, 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
> ---
> Hello,
>
> This patch is only adding basic support for the sii
Hi Liviu,
On 2016-06-08 11:05, liviu.dudau at arm.com wrote:
> On Wed, Jun 08, 2016 at 08:58:33AM +0200, Marek Szyprowski wrote:
>> On 2016-06-07 16:34, liviu.dudau at arm.com wrote:
>>> On Tue, Jun 07, 2016 at 03:11:14PM +0100, Robin Murphy wrote:
Hi Liviu,
On 07/06/16 14:35, livi
On Wed, 8 Jun 2016 10:39:11 +0100
Emil Velikov wrote:
> Hi Boris,
>
> On 7 June 2016 at 12:59, 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 Fer
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 in the DRM core. Callers of those functions often need to
> access more th
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
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.
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
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
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(
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 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
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
On 8 June 2016 at 11:06, Boris Brezillon
wrote:
> On Wed, 8 Jun 2016 10:39:11 +0100
> Emil Velikov wrote:
>
>> Hi Boris,
>>
>> On 7 June 2016 at 12:59, Boris Brezillon
>> wrote:
>> > Add basic support for the sii902x RGB -> HDMI bridge.
>> > This driver does not support audio output yet.
>> >
>>
On Wed, Jun 08, 2016 at 12:01:20PM +0200, Marek Szyprowski wrote:
> Hi Liviu,
Hi Marek,
[HDLCD bug report content removed]
> >>>OK, the problem is that commit 59ce4039727ef40 has changed the behaviour
> >>>from when
> >>>there is no "memory-region" phandle in the DT: before it used to return
>
The PM core introduced the ability to keep devices runtime suspended
during the entire system suspend/resume process with commit aae4518b3124
("PM / sleep: Mechanism to avoid resuming runtime-suspended devices
unnecessarily"). Before this so-called "direct-complete" procedure was
introduced, device
On Wed, Jun 08, 2016 at 08:51:53AM +0200, 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: Liviu Dudau
> Fixes: 59ce4039727ef40 ("of:
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
ions(-)
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160608/ee0302c5/attachment.html>
On Tue, Jun 07, 2016 at 05:51:52PM -0400, Jerome Glisse wrote:
> Ok i don't have too much time to dig into r600 i assume that r700 breaks
> the same way so could you verify that attached patch fix the issue for
> you. Note that video decoding is likely broken for you after hibernation
> but you mig
Am 08.06.2016 um 13:36 schrieb Borislav Petkov:
> On Tue, Jun 07, 2016 at 05:51:52PM -0400, Jerome Glisse wrote:
>> Ok i don't have too much time to dig into r600 i assume that r700 breaks
>> the same way so could you verify that attached patch fix the issue for
>> you. Note that video decoding is
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
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 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 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 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 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
On Wed, Jun 08, 2016 at 12:49:29PM +0200, Lukas Wunner wrote:
> The PM core introduced the ability to keep devices runtime suspended
> during the entire system suspend/resume process with commit aae4518b3124
> ("PM / sleep: Mechanism to avoid resuming runtime-suspended devices
> unnecessarily"). Be
- 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 glorious future.
Signed-off-by: Daniel Vetter
---
drivers/gp
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.
v2: Rebase it!
Cc: Carlos Palminha
Cc: Alexey Brodkin
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 new set
of planes are actually disabled. But that's k
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, when the CRTC is on, or just send
the event out right away
atomic_flush seems to be the right place, right after we commit the
plane updates. Again use the fullproof version, since the pipe might
be off.
Cc: Boris Brezillon
Cc: Maxime Ripard
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/sun4i/sun4i_crtc.c | 12
1 file changed, 12 inser
Just a bit of drive-by ocd.
v2: Improve per Liviu's feedback.
Cc: Liviu Dudau
Signed-off-by: Daniel Vetter
---
include/drm/drm_atomic.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index d12cfb9c6062..a16861c882aa 100644
--
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: Maarten Lankhorst
Cc: Tomeu Vizoso
Cc: Daniel Stone
Tested-b
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
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-by: Daniel Vetter
---
drivers/gpu/drm/arc/arcpgu_drv.c | 8
With the fixed up drm event handling for crtc_state->event we can just
use the helper support for nonblocking commits.
Cc: Liviu Dudau
Tested-by: Liviu Dudau
Acked-by: Liviu Dudau
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arm/hdlcd_drv.c | 8 +---
1 file changed, 1 insertion(+), 7
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.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 13 ++---
drivers/gpu/drm/i915
Right now still all blocking, no worker anywhere to be seen.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0618
Simply split intel_atomic_commit in half and place the new
nonblocking commit helpers at the right spots.
NOTE: There's still trouble with obj->frontbuffer bits getting mangled
when pipelining atomic commits.
v2:
- Remove the check for nonblocking which returned -EINVAL.
- Do wait for requests in
Currently it's part of prepare_fb, still in the first phase of
atomic_commit which might fail. Which means that we need to have some
heuristics in cleanup_fb to figure out whether things failed, or
whether we just clean up the old fbs.
That's fragile, and worse, once we start pipelining commits ge
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: Stefan Agner
Signed-off-by: Daniel Vetter
---
drivers/g
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 just a minimal optimization compared
to current commo
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_bits gets out of whack when pipelining
commits too hard.
Signed-off-by: Da
With atomic helpers there's no need to track the enabled state of a pipe
any more, because atomic helpers track this accurately already.
Just disable the early returns, since the debug checks might be useful.
v2: Don't call drm_helper_disable_unused_functions, it blows up
without this check. At l
It's not permissible to look at plane->state from interrupt context,
since doing that would need the irq handler to acquire the
plane->mutex lock.
The other problem is that if we pipeline updates using the new
nonblocking atomic helpers new state gets commit before the irq
handler fires, resulting
With the various bits fixed rockchip now has an atomic compliant
handling/signalling of crtc_state->event, which means we can just
switch over to the new nonblocking helpers and remove some code.
v2: Fixes from Tomeu.
v3: Send out vblank events correctly when shutting down a crtc for
good. This i
This is now handled by the core, drivers can totally ignore lifetime
issues of drm events.
Cc: Tomeu Vizoso
Cc: Mark yao
Tested-by: Tomeu Vizoso
Reviewed-by: Tomeu Vizoso
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 22 --
drivers/gpu/drm
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
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
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
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
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
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
---
Hi Yakir,
On 8 June 2016 at 12:52, Yakir Yang wrote:
> 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 ch
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
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
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
In hdlcd_drm_bind()/hdlcd_drm_unbind() we unwind the DRM setup in the
wrong order (drm_mode_config_cleanup() before connector and encoder
had a chance to cleanup their memory or before drm_dev_unregister()).
The correct order should match in both functions.
Reported-by: Robin Murphy
Signed-off-by
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: Liviu Dudau
> Fixes: 59ce4039727ef40 ("of: reserved_
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, 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
[
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 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
On Mon, Jun 6, 2016 at 4:17 AM, Christian König
wrote:
> Hi everyone,
>
> this set of patches moves waiting for TTM BOs to become idle before moving
> them into the driver callbacks and the CPU copy fallback function.
>
> Then the amdgpu driver is patched to completely remove this premove idle
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
> 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 earlie
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
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(+)
>
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.
From: Yakir Yang
Commit 3424e3a4f844 ("drm: bridge: analogix/dp: split exynos dp driver to
bridge directory") split the Exynos DP core driver into a core driver and
a bridge driver for the Analogix chip since that is also used by Rockchip.
But the change introduced a regression causing a NULL po
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:
> 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:
> 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
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).
$
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
1 - 100 of 169 matches
Mail list logo
