Thank you for Russel.
It is Right, when this sti_tvout (component) finish executing component ".bind"
function while sti_hdmi or sti_hda is not registered. the bug will occur .
this patch will prepare this bug by calling master .bind of sti_tvout after
sti_hdmi or sti_hda is register to finish bi
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/dacf1e28/attachment-0001.html>
On Tue, Jul 14, 2015 at 3:45 AM, Andrew Chew wrote:
> I apologize for my ignorance. In digging through nouveau, I've become
> a bit confused regarding the relationship between virtual address
> allocations and nouveau bo's.
>
> From my reading of the code, it seems that a nouveau_bo really
> enca
Hi Dave,
Ok next attempt at drm-fixes pull. Big thing really is just the compat32
one for addfb2.1.
Cheers, Daniel
The following changes since commit e24ff467e12e1560de753313976c46e84fa6306a:
drm/crtc: Fix edid length computation (2015-07-04 00:52:34 +0200)
are available in the git reposito
On Wed, Jul 15, 2015 at 04:48:33PM +0100, Daniel Stone wrote:
> On 15 July 2015 at 16:44, Daniel Vetter wrote:
> > Avoids legacy userspace/code getting confused when dpms doesn't
> > reflect reality of what's going on.
> >
> > Signed-off-by: Daniel Vetter
>
> Reviewed-by: Daniel Stone
Applied
This patch isn't the good one, I send the fix here:
http://lists.freedesktop.org/archives/dri-devel/2015-July/086568.html
Regards,
Benjamin
2015-07-16 3:13 GMT+02:00 Xinwei Kong :
> Thank you for Russel.
>
> It is Right, when this sti_tvout (component) finish executing component
> ".bind"
> func
test
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/eed71639/attachment-0001.html>
On Thu, Jul 09, 2015 at 11:14:43PM +0200, Daniel Vetter wrote:
> On Thu, Jul 09, 2015 at 01:15:34PM +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > This really doesn't seem to have much chance of working anymore,
> >
> > esp for irq context, qxl at least tries to talk to the hw,
> > and
Trying to do anything with kms drivers when oopsing has become a
failing proposition. But since we can end up in the fbdev code simply
due to the console unblanking that's done unconditionally just
removing our panic handler isn't enough. We need to block all fbdev
callbacks when oopsing.
There wa
The driver requires OF support, add a dependency in Kconfig and remove
the platform_device_id table that isn't used anymore.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/Kconfig | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 11 +--
2 files changed, 2 insertions(+)
This is required for DPMS to work correctly, during a modeset
the DPMS property should be turned off, unless the crtc
is made active in which case it should be set to DPMS on.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 16 +++
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 0898afbc9e23..70e69904291d 10
On Thu, Jul 16, 2015 at 10:44 AM, Laurent Pinchart
wrote:
> The driver requires OF support, add a dependency in Kconfig and remove
> the platform_device_id table that isn't used anymore.
>
> Signed-off-by: Laurent Pinchart
Once Simon has queued up the removal of board-marzen.c:
Acked-by: Geert
hi ben:
your patch is ok, i don't know your hardware how to use. In this first
code why use that style dts? If you detail research our patch, you will
find that it can compatiable your fixing dts.
If you don't approve our patch better, I will be glad to see you to slove
this bug
Thank you
Xinwei
On Thu, Jul 16, 2015 at 10:59:14AM +0200, Maarten Lankhorst wrote:
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_he
On Thu, Jul 16, 2015 at 10:59:15AM +0200, Maarten Lankhorst wrote:
> This is required for DPMS to work correctly, during a modeset
> the DPMS property should be turned off, unless the crtc
> is made active in which case it should be set to DPMS on.
>
> Cc: dri-devel at lists.freedesktop.org
> Sign
Op 16-07-15 om 11:19 schreef Daniel Vetter:
> On Thu, Jul 16, 2015 at 10:59:14AM +0200, Maarten Lankhorst wrote:
>> Cc: dri-devel at lists.freedesktop.org
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/drm_atomic_helper.c | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions
hi ben:
your patch is ok, i don't know your hardware how to use. In this first
code why use that style dts? If you detail research our patch, you will
find that it can compatiable your fixing dts.
If you don't approve our patch better, I will be glad to see you to slove
this bug
Thank you
Xinwei
Op 16-07-15 om 11:19 schreef Daniel Vetter:
> On Thu, Jul 16, 2015 at 10:59:15AM +0200, Maarten Lankhorst wrote:
>> This is required for DPMS to work correctly, during a modeset
>> the DPMS property should be turned off, unless the crtc
>> is made active in which case it should be set to DPMS on.
>
On Thu, Jul 16, 2015 at 11:17:29AM +0200, Maarten Lankhorst wrote:
> Op 16-07-15 om 11:19 schreef Daniel Vetter:
> > On Thu, Jul 16, 2015 at 10:59:14AM +0200, Maarten Lankhorst wrote:
> >> Cc: dri-devel at lists.freedesktop.org
> >> Signed-off-by: Maarten Lankhorst
> >> ---
> >> drivers/gpu/drm/d
On Thu, Jul 16, 2015 at 11:24:02AM +0200, Maarten Lankhorst wrote:
> Op 16-07-15 om 11:19 schreef Daniel Vetter:
> > On Thu, Jul 16, 2015 at 10:59:15AM +0200, Maarten Lankhorst wrote:
> >> This is required for DPMS to work correctly, during a modeset
> >> the DPMS property should be turned off, unl
https://bugzilla.kernel.org/show_bug.cgi?id=99041
--- Comment #1 from Florent Le Coz ---
The issue is still present on kernel 4.0.7.
Little precision, that may be useful to diagnose the problem:
- If I boot with that HDMI-connected screen turned off and then I turn it on
with my X session alrea
Op 16-07-15 om 11:29 schreef Daniel Vetter:
> On Thu, Jul 16, 2015 at 11:17:29AM +0200, Maarten Lankhorst wrote:
>> Op 16-07-15 om 11:19 schreef Daniel Vetter:
>>> On Thu, Jul 16, 2015 at 10:59:14AM +0200, Maarten Lankhorst wrote:
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Maar
Hi Geert,
On Thursday 16 July 2015 11:08:58 Geert Uytterhoeven wrote:
> On Thu, Jul 16, 2015 at 10:44 AM, Laurent Pinchart wrote:
> > The driver requires OF support, add a dependency in Kconfig and remove
> > the platform_device_id table that isn't used anymore.
> >
> > Signed-off-by: Laurent Pin
> >
> > Thierry
>
>
>
> --
> Benjamin Gaignard
>
> Graphic Working Group
>
> Linaro.org â Open source software for ARM SoCs
>
> Follow Linaro: Facebook | Twitter | Blog
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/621fcbba/attachment.sig>
Hi Thierry,
Thank you very much for your patient and careful guidance. I'm updating my
driver according to your comments.
> -Original Message-
> From: Thierry Reding [mailto:thierry.reding at gmail.com]
> Sent: Tuesday, July 14, 2015 6:49 PM
> To: Wang Jianwei-B52261
> Cc: dri-devel at l
> -Original Message-
> From: Thierry Reding [mailto:thierry.reding at gmail.com]
> Sent: Tuesday, July 14, 2015 6:54 PM
> To: Wang Jianwei-B52261
> Cc: dri-devel at lists.freedesktop.org; linux-kernel at vger.kernel.org;
> linux-
> arm-kernel at lists.infradead.org; devicetree at vger.ke
abled you're going to pick up the values for VF610 and
cause LS1021A to not work.
> > > +void fsl_dcu_drm_plane_destroy(struct drm_plane *plane) {
> > > + fsl_dcu_drm_plane_disable(plane);
> >
> > Hmm? This function doesn't do anything, so why not just drop it?
> >
>
>
> I'll implement fsl_dcu_drm_plane_disable(plane)
>
>
>
> > > + drm_plane_cleanup(plane);
> > > +}
> >
> > Also this function and ->atomic_update() should be static. Perhaps make it
> > a habit of running your build tests with C=1 occasionally to get notified
> > of this kind of error.
> >
> > Thierry
>
>
>
> One question: How can I set C=1?
Just add it to the make command-line along with any other parameters,
like this for example:
$ make ARCH=arm CROSS_COMPILE=armv7l-unknown-linux-gnueabihf- \
O=build/vf610 C=1
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/4dadc8ad/attachment.sig>
From: Zhao Junwang
- planes:
drm_atomic_helper_update_plane()
drm_atomic_helper_diable_plane()
- Driver:
drm_atomic_helper_check()
drm_atomic_helper_commit()
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/bochs/bochs_km
From: Zhao Junwang
with transitional helpers we've used the new callbacks, but control
flow was still old, but with atomic first step is to call atomic_check,
then prepare_fb, and so on, by this time, we can not look at any legacy
state like plane->fb or crtc->enabled, because they are updated at
From: Zhao Junwang
PageFlips now use the atomic helper to work through the atomic
modesetting API.
v2: -Since driver is now fully atomic, we should add DRIVER_ATOMIC
to .driver_features.
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/bochs/bochs
From: Zhao Junwang
-register driver's own primary plane
-use drm_crtc_init_with_planes instead of drm_crtc_init
-split ->mode_set into:
1. set the new hw mode
2. update the primary plane (This is done by ->set_base)
-move what ->set_base do into ->atomic_update
-the new atomic i
From: Zhao Junwang
This supports the asynchronous commits, required for page-flipping
Since it's virtual hw it's ok to commit async stuff right away, we
never have to wait for vblank.
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/bochs/bochs_mm.c |
From: Zhao Junwang
Now that phase 1 and phase 2 are complete, switch .set_config helper
to use the atomic one.
-since .prepare() callbacks are no more needed, remove them
-.mode_set() and .mode_set_base() are no longer needed, remove
-as we are not using the transitional helper now, we can use
From: Zhao Junwang
- use ->disable() and ->enable() for crct and plane
- use drm_atomic_helper_connector_dpms for connector
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/bochs/bochs_kms.c | 34 ++
1 file changed, 22
From: Zhao Junwang
Set CRTC, planes and connectors to use the default implementations
from the atomic helper library.
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/bochs/bochs_kms.c | 12
1 file changed, 12 insertions(+)
diff --git a/
From: Zhao Junwang
This patch series aim to convert DRM_BOCHS to atomic mode-setting.
I did this mostly reference Gustavo Padovan's patch series on
drm/exynos conversion.
Zhao Junwang (8):
drm/bochs: phase 1 - use the transitional helpers
drm/bochs: phase 2: wire up state reset(), duplicate(
On Thu, Jul 16, 2015 at 11:38:18AM +0200, Maarten Lankhorst wrote:
> Op 16-07-15 om 11:29 schreef Daniel Vetter:
> > On Thu, Jul 16, 2015 at 11:17:29AM +0200, Maarten Lankhorst wrote:
> >> Op 16-07-15 om 11:19 schreef Daniel Vetter:
> >>> On Thu, Jul 16, 2015 at 10:59:14AM +0200, Maarten Lankhorst
Maxime, as STi DT maintainer, could you give us your point of view ?
If needed I could split the patch in two: one for driver and one for DT.
2015-07-16 12:59 GMT+02:00 Thierry Reding :
> On Wed, Jul 15, 2015 at 03:56:41PM +0200, Benjamin Gaignard wrote:
>> It doesn't change any bindings fields,
Marek, Kamil,
On 06/29/15 12:14, Hans Verkuil wrote:
> From: Kamil Debski
>
> Add CEC interface driver present in the Samsung Exynos range of
> SoCs.
>
> The following files were based on work by SangPil Moon:
> - exynos_hdmi_cec.h
> - exynos_hdmi_cecctl.c
>
> Signed-off-by: Kamil Debski
>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/7fb72fe5/attachment-0001.html>
On Tue, 14 Jul 2015 16:45:52 +0200,
Nariman Poushin wrote:
>
> We treat a delay in a sequence the same way we treat a page change as
> they are logically similar in that you can coalesce all write before
> a delay (in the same way you can coalesce all writes before a page
> change is needed)
>
>
Op 16-07-15 om 14:34 schreef Daniel Vetter:
> On Thu, Jul 16, 2015 at 11:38:18AM +0200, Maarten Lankhorst wrote:
>> Op 16-07-15 om 11:29 schreef Daniel Vetter:
>>> On Thu, Jul 16, 2015 at 11:17:29AM +0200, Maarten Lankhorst wrote:
Op 16-07-15 om 11:19 schreef Daniel Vetter:
> On Thu, Jul 1
Universal planes may not be assigned to the current crtc, so only
update crtc->x/y when the primary is part of the state and bound
to the current crtc.
Changes since v1:
- Add the crtc check.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/ba074959/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/adfea97b/attachment.html>
This removes the need to separately track fb changes i915.
Changes since v1:
- Add dri-devel to cc.
- Fix a check in intel's prepare and cleanup fb to take rotation
into account.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/atmel-hlcd
;t know.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/0891a411/attachment.html>
you don't enable dpm at all (which is the default)?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/a33ad372/attachment.html>
It's causing piles of issues since we've stopped forcing full detect
cycles in the sysfs interfaces with
commit c484f02d0f02fbbfc6decc945a69aae011041a27
Author: Chris Wilson
Date: Fri Mar 6 12:36:42 2015 +
drm: Lighten sysfs connector 'status'
The original justification for this was t
If we don't force the connector state to unknown there's no reason any
more to force a reprobe. Also no other driver bothers with this, so
probably it's not required - userspace handles lid/resume events
through other channels already.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_d
Trying to do anything with kms drivers when oopsing has become a
failing proposition. But since we can end up in the fbdev code simply
due to the console unblanking that's done unconditionally just
removing our panic handler isn't enough. We need to block all fbdev
callbacks when oopsing.
There wa
tp://lists.freedesktop.org/archives/dri-devel/attachments/20150716/0ea92985/attachment-0001.html>
On Thu, Jul 16, 2015 at 03:51:01PM +0200, Maarten Lankhorst wrote:
> Universal planes may not be assigned to the current crtc, so only
> update crtc->x/y when the primary is part of the state and bound
> to the current crtc.
>
> Changes since v1:
> - Add the crtc check.
>
> Cc: dri-devel at lists
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/e6827358/attachment.html>
From: Gustavo Padovan
Instead of giving -1 to as arg to drm_send_vblank_event() pass the
correct pipe number to it.
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driv
From: Gustavo Padovan
Get rid of legacy DRM vblank function that are less clear to use.
The new ones basically requires only the crtc as parameters.
It also clean ups exynos_drm_crtc_finish_pageflip() parameters as a
consequence.
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
---
From: Gustavo Padovan
The same check is placed twice in fimd/decon_update_plane(), remove
one of them.
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 3 ---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 ---
2 files changed, 6 dele
From: Gustavo Padovan
Rename win_commit() helper to update_plane() and win_disable() to
disable_plane().
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 10 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 10 +-
From: Gustavo Padovan
We already have the plane pointer in before calling .update_plane() or
disable_plane() so pass it directly to those calls avoiding a new
conversion from zpos to struct exynos_drm_plane.
v2: don't remove check for suspended in FIMD (comment by Joonyoung)
Signed-off-by: Gust
From: Gustavo Padovan
For some fields the use of struct exynos_drm_plane filled with data from
the plane state just creates a source of duplicated information and
overhead. Here we change the crtc drivers to access the plane state
directly simplifying the code by not relying on a exynos internal
From: Gustavo Padovan
Now after the move to use drm_plane_state directly struct drm_plane_state
has many unused fields, along with others that weren't used before the
plane state change. Thus remove them all.
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exyno
From: Gustavo Padovan
Rename crtc_{widht,height} to crtc_{w,h} and src_{width,height} to
src_{w,h} to make it similar to the atomic state names.
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 10 +-
drivers/gpu/drm/exynos
From: Gustavo Padovan
Instead of blindly ignore the return value of enable_vblank return it
to the upper DRM layer for error handling.
Suggested-by: Joonyoung Shim
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
1 file changed,
2015-07-14 Joonyoung Shim :
> On 07/06/2015 11:20 PM, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Hi,
> >
> > This set improves exynos in a number of ways. The first five patches are
> > general clean up/fixes.
> >
> > Patches 06 to 12 are improvements on top of the newly added atomi
On Thu, Jul 16, 2015 at 04:47:51PM +0200, Daniel Vetter wrote:
> If we don't force the connector state to unknown there's no reason any
> more to force a reprobe. Also no other driver bothers with this, so
> probably it's not required - userspace handles lid/resume events
> through other channels a
On Do, 2015-07-16 at 20:20 +0800, John Hunter wrote:
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -10,6 +10,11 @@
>
> static int defx = 1024;
> static int defy = 768;
> +static u64 gpu_addr = 0;
That isn't going to fly. Guess you could it that into
The whole thing is quite messy - the file is used to indicate that the
man pages were correctly generated prior to applying the "fixup" (alias)
At the same time we use a rule with the same name, to create the same
file if the generation has failed.
In other words - it attempts to create the file
On 15 July 2015 at 13:47, Thierry Reding wrote:
> On Wed, Jul 15, 2015 at 01:37:22PM +0100, Emil Velikov wrote:
>> On 15 July 2015 at 12:47, Thierry Reding wrote:
>> > On Tue, Jul 14, 2015 at 03:10:04PM +0100, Emil Velikov wrote:
>> >> Spotted by looking for similar "let's assume fd == 0 is inval
e test.
I just did and it happened fast, 20 mins after game started.
So, answer is yes, I see this bug when dpm is disabled.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http:/
The file sound/core/pcm_drm_eld.c which was added by the commit
838d1631b766529213684f07dd71cdf2e92f0623
ALSA: pcm: add DRM ELD helper
lacks the function drm_eld_sad() which was defined by Russell's patch
http://article.gmane.org/gmane.linux.ports.arm.kernel/411574
Hi,
this series uses the IPU IC post-processing task to implement
a mem2mem device for scaling and colorspace conversion. This
version addresses a few review commends, and includes some
further cleanup.
Changes since v2:
- Limit downscaling to 4:1
- Disabled USERPTR memory
- Set icc pointer to
This patch adds the remaining missing IDMAC channel names: all VDIC
channels for deinterlacing and combining, the separate alpha channels
for the MEM->IC and MEM->DC ASYNC channels, and the DC read, command,
and output mask channels.
Signed-off-by: Philipp Zabel
---
include/video/imx-ipu-v3.h |
This patch adds support for mem2mem scaling and colorspace conversion
using the IC module's post-processing task.
Scaling images larger than 1024x1024 is supported by tiling over multiple
IC scaling runs. Since the IDMAC and IC units have interesting and
different alignment limitations for buffer
From: Sascha Hauer
Add video4linux API routines common to drivers for units that
accept or provide video data via the i.MX IPU IDMAC channels,
such as scaler or deinterlacer drivers.
Signed-off-by: Sascha Hauer
Signed-off-by: Lucas Stach
Signed-off-by: Philipp Zabel
---
drivers/media/platfor
This patch registers the scaler device using the IC post-processing task,
to be handled by a mem2mem scaler driver.
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-comm
From: Sascha Hauer
This patch adds support for hardware accelerated scaling and color
space conversion between memory buffers using the IPUv3 IC.
Since the maximum output size of the IC unit is 1024x1024 pixels, multiple
IC tasks with overlapping tiles are used internally to scale and convert
lar
On Thu, Jul 16, 2015 at 06:16:58PM +0200, Jean-Francois Moine wrote:
> The file sound/core/pcm_drm_eld.c which was added by the commit
>
> 838d1631b766529213684f07dd71cdf2e92f0623
> ALSA: pcm: add DRM ELD helper
>
> lacks the function drm_eld_sad() which was defined by Russell's patch
On Thu, Jul 16, 2015 at 4:47 PM, Daniel Vetter
wrote:
> It's causing piles of issues since we've stopped forcing full detect
> cycles in the sysfs interfaces with
I tested this one on top of 4.1.2 and it does what it says on the tin,
i.e. after resuming I get the connected/disconnected strings o
On Thu, Jul 16, 2015 at 5:32 PM, Chris Wilson
wrote:
> On Thu, Jul 16, 2015 at 04:47:51PM +0200, Daniel Vetter wrote:
>> If we don't force the connector state to unknown there's no reason any
>> more to force a reprobe. Also no other driver bothers with this, so
>> probably it's not required - us
On Thu, Jul 16, 2015 at 05:49:43PM +0200, Gerd Hoffmann wrote:
> On Do, 2015-07-16 at 20:20 +0800, John Hunter wrote:
> > --- a/drivers/gpu/drm/bochs/bochs_kms.c
> > +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> > @@ -10,6 +10,11 @@
> >
> > static int defx = 1024;
> > static int defy = 768;
> > +st
On Thu, Jul 16, 2015 at 07:41:14PM +0200, Rui Tiago Cação Matos wrote:
> On Thu, Jul 16, 2015 at 5:32 PM, Chris Wilson
> wrote:
> > On Thu, Jul 16, 2015 at 04:47:51PM +0200, Daniel Vetter wrote:
> >> If we don't force the connector state to unknown there's no reason any
> >> more to force a rep
On Thu, Jul 16, 2015 at 04:32:44PM +0100, Chris Wilson wrote:
> On Thu, Jul 16, 2015 at 04:47:51PM +0200, Daniel Vetter wrote:
> > If we don't force the connector state to unknown there's no reason any
> > more to force a reprobe. Also no other driver bothers with this, so
> > probably it's not req
On 7/16/15, Daniel Vetter wrote:
> You only get a hotplug event when something has actually changed, not for
> every suspend/resume.
Sure. But what about the case where something did get
plugged/unplugged while suspended. That's what I was referring to,
sorry for not being clear.
Rui
|issues with 7950|issues with 7950
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/494d6db0/attachment.html>
Hi Dave,
More radeon and amdgpu fixes for 4.2. Mostly amdgpu bug fixes.
The following changes since commit 3aa20508a6fe386c2a893027ef4c4ef78ee4eac2:
Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
(2015-07-15 18:38:24 -0700)
are available in
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/cf3f09b7/attachment.html>
On Thu, Jul 16, 2015 at 01:52:54PM +0100, Mark Brown wrote:
> On Tue, Jul 14, 2015 at 03:45:51PM +0100, Nariman Poushin wrote:
>
> Please submit patches in the format covered in SubmittingPatches,
> version information goes inside the [].
>
> > Add support for writing sequences of registers / pat
h the extra information.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/cc443ef9/attachment-0001.sig>
...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/6cdaab6b/attachment.sig>
ytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/006edd00/attachment.sig>
nt was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/d182932d/attachment.sig>
From: Boris Brezillon
drm_vblank_on() now warns on nested use or if vblank is not properly
initialized. This patch fixes Atmel HLCDC vblank initial state.
Signed-off-by: Boris Brezillon
Reported-by: Sylvain Rochet
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 1 +
drivers/gpu/drm/atme
icking out
platform devices as opposed to just deferring all devices is.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel
Add an optional delay_us field in reg_sequence to allow the client to
specify a delay (in microseconds) to be applied after any given write
in a sequence of writes.
We treat a delay in a sequence the same way we treat a page change as
they are logically similar in that you can coalesce all write b
Separate the functionality using sequences of register writes from the
functions that take register defaults. This change renames the arguments
in order to support the extension of reg_sequence to take an optional
delay to be applied after any given register in a sequence is written.
This avoids ad
96 matches
Mail list logo
