block_all_signals() usage in DRM

On 26 May 2015 at 00:59, Richard Weinberger wrote: > Hi! > > drivers/gpu/drm/drm_lock.c is the only remaining user of block_all_signals(): It's the only user of it, ever. The API was introduced for the drm locking code. No other user will ever exist. Just to clear up the an API exists with one

block_all_signals() usage in DRM

On 26 May 2015 at 02:50, Oleg Nesterov wrote: > On 05/25, Richard Weinberger wrote: >> >> Is this functionality still in use/needed? > > All I can say it doesn't work. > >> Otherwise we could get rid of block_all_signals() and unpuzzle the signaling >> code a bit. :-) > > Yes. I do not even

[PATCH 1/8] acpi: Rename v1 DSM to mux to avoid ambiguity

This is especially true when variables or functions are just called dsm without precising the v1. Signed-off-by: Pierre Moreau --- drm/nouveau/nouveau_acpi.c | 64 +++--- drm/nouveau/nouveau_acpi.h | 4 +-- drm/nouveau/nouveau_drm.c | 4 +--

[PATCH 2/8] acpi: Add evaluate to functons evaluating _DSM

This makes it clearer when reading the function name, as well as following the names of the related ACPI function. Signed-off-by: Pierre Moreau --- drm/nouveau/nouveau_acpi.c | 25 ++--- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git

[PATCH 3/8] acpi: Define static variables for revision ids

Signed-off-by: Pierre Moreau --- drm/nouveau/nouveau_acpi.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c index 1f18018..36f4a40 100644 --- a/drm/nouveau/nouveau_acpi.c +++ b/drm/nouveau/nouveau_acpi.c @@

[PATCH 4/8] acpi: Allow evaluate_optimus_dsm to take NULL results

Signed-off-by: Pierre Moreau --- drm/nouveau/nouveau_acpi.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c index 36f4a40..073f7d7 100644 --- a/drm/nouveau/nouveau_acpi.c +++ b/drm/nouveau/nouveau_acpi.c @@

[PATCH 5/8] acpi: Check returned object type by Optimus _DSM locally

Most _DSM will return an integer value of 0x8002 when given an unknown UUID, revision ID or function ID. Checking locally allows us to differentiate that case from other ACPI errors, and to not report a "failed to evaluate _DSM" if 0x8002 is returned which was confusing. Signed-off-by:

[PATCH 6/8] acpi: Improve some messages level and content

Signed-off-by: Pierre Moreau --- drm/nouveau/nouveau_acpi.c | 8 drm/nouveau/nouveau_vga.c | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c index 7aeaf7d..104d291 100644 --- a/drm/nouveau/nouveau_acpi.c +++

[PATCH 7/8] acpi: Add support for Apple Gmux _DMS

Signed-off-by: Pierre Moreau --- drm/nouveau/nouveau_acpi.c | 53 -- drm/nouveau/nouveau_acpi.h | 2 ++ drm/nouveau/nouveau_drm.c | 6 -- drm/nouveau/nouveau_vga.c | 10 + 4 files changed, 63 insertions(+), 8 deletions(-) diff --git

[PATCH 8/8] acpi: Use booleans when probing different _DSM types

Signed-off-by: Pierre Moreau --- drm/nouveau/nouveau_acpi.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c index 3d6a1ea..5d63621 100644 --- a/drm/nouveau/nouveau_acpi.c +++ b/drm/nouveau/nouveau_acpi.c

[Bug 90439] [LLVM] Xonotic render green (bisected)

nts/20150526/0946d19f/attachment-0001.html>

[Bug 89034] Firefox crashing xserver and some major rendering bugs

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/9c93bc81/attachment.html>

[Nouveau] [PATCH 5/8] acpi: Check returned object type by Optimus _DSM locally

> On 26 May 2015, at 00:39, Ilia Mirkin wrote: > >> On Mon, May 25, 2015 at 6:22 PM, Pierre Moreau >> wrote: >> Most _DSM will return an integer value of 0x8002 when given an unknown >> UUID, revision ID or function ID. Checking locally allows us to differentiate >> that case from

[Nouveau] [PATCH 5/8] acpi: Check returned object type by Optimus _DSM locally

On Tue, May 26, 2015 at 1:10 AM, Pierre Moreau wrote: >> On 26 May 2015, at 00:39, Ilia Mirkin wrote: >> >>> On Mon, May 25, 2015 at 6:22 PM, Pierre Moreau >>> wrote: >>> Most _DSM will return an integer value of 0x8002 when given an unknown >>> UUID, revision ID or function ID. Checking

[Intel-gfx] drivers/gpu/drm/i915/i915_gem_gtt.c

On Mon, May 25, 2015 at 7:32 AM, Jani Nikula wrote: >> I'm not sure what is the approved way of fixing this. Perhaps >> disabling CONFIG_DRM_I915_WERROR when CONFIG_COMPILE_TEST=y. > > Maybe the answer right now is to just drop that config. Daniel? Agreed, that little experiment doesn't seem to

[PATCH] drm/vgem: drop DRIVER_PRIME (v2)

On 22 May 2015 at 02:54, Thomas Hellstrom wrote: > On 05/21/2015 06:07 PM, Daniel Vetter wrote: >> On Thu, May 21, 2015 at 11:58:30AM -0400, Rob Clark wrote: >>> For actual sharing of buffers with other drivers (ie. actual hardware) >>> we'll need to pimp things out a bit better to deal w/

[PATCH 11/11] drm: atomic: Add MODE_ID property

On Mon, May 25, 2015 at 02:06:13PM +0100, Daniel Stone wrote: > On 22 May 2015 at 15:34, Daniel Vetter wrote: > > On Fri, May 22, 2015 at 01:34:54PM +0100, Daniel Stone wrote: > >> - /* FIXME: Mode prop is missing, which also controls ->enable. */ > >> if (property ==

Build regressions/improvements in v4.1-rc5

On Tue, May 26, 2015 at 9:39 AM, Geert Uytterhoeven wrote: > JFYI, when comparing v4.1-rc5[1] to v4.1-rc4[3], the summaries are: > - build errors: +52/-28 + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_MT_BUFFERABLE' undeclared here (not in a function): => 81:10 +

[Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150526/a1fc2d54/attachment.html>

[Nouveau] [PATCH 5/8] acpi: Check returned object type by Optimus _DSM locally

> On 26 May 2015, at 07:17, Ilia Mirkin wrote: > > On Tue, May 26, 2015 at 1:10 AM, Pierre Moreau > wrote: >>> On 26 May 2015, at 00:39, Ilia Mirkin wrote: >>> On Mon, May 25, 2015 at 6:22 PM, Pierre Moreau wrote: Most _DSM will return an integer value of 0x8002 when

[Nouveau] [PATCH 4/8] acpi: Allow evaluate_optimus_dsm to take NULL results

_dsm(nouveau_dsm_priv.dhandle, >> NOUVEAU_DSM_OPTIMUS_FLAGS, >> - 0x3, ); >> + 0x3, NULL); >> nouveau_evaluate_optimus_dsm(nouveau_dsm_priv.dhandle, >> NOUVEAU_DSM_OPTIMU

[Nouveau] [PATCH 7/8] acpi: Add support for Apple Gmux _DMS

_gmux())) >> runtime = true; >> vga_switcheroo_register_client(dev->pdev, _switcheroo_ops, >> runtime); >> - if (runtime && nouveau_has_mux() && !nouveau_is_optimus()) >> +if (runtime && (nouveau_has_mux() || nouveau_has_gmux()) && >> !nouveau_is_optimus()) >> vga_switcheroo_init_domain_pm_ops(drm->dev->dev, >> >vga_pm_domain); >> } >> @@ -112,11 +113,12 @@ nouveau_vga_fini(struct nouveau_drm *drm) >> if (nouveau_runtime_pm == 1) >> runtime = true; >> -if ((nouveau_runtime_pm == -1) && (nouveau_is_optimus() || >> nouveau_has_mux())) >> +if ((nouveau_runtime_pm == -1) && >> +(nouveau_is_optimus() || nouveau_has_mux() || nouveau_has_gmux())) >> runtime = true; >> > > You could maybe factorize a bit here by adding nouveau_has_optimus(). What do > you think? I was thinking of something like that, but I wasn’t sure about the name. Using optimus seems tricky, because you could have nouveau_is_optimus(): false but nouveau_has_optimus(): true… > >> vga_switcheroo_unregister_client(dev->pdev); >> -if (runtime && nouveau_has_mux() && !nouveau_is_optimus()) >> +if (runtime && (nouveau_has_mux() || nouveau_has_gmux()) && >> !nouveau_is_optimus()) >> vga_switcheroo_fini_domain_pm_ops(drm->dev->dev); >> vga_client_register(dev->pdev, NULL, NULL, NULL); >> } -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/6e2572b2/attachment-0001.html>

[Bug 75357] Barts (HD6850): Failure in evergreen_surface_check_2d

as scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/5a15f8ee/attachment.html>

[PATCH] drm/nouveau/platform: fix compilation if !CONFIG_IOMMU

On Wed, May 20, 2015 at 4:07 PM, Arnd Bergmann wrote: > On Wednesday 20 May 2015 15:10:24 Alexandre Courbot wrote: >> The lack of IOMMU API support can make nouveau_platform_probe_iommu() >> fail to compile because struct iommu_ops is then empty. Fix this by >> skipping IOMMU probe in that case -

[Bug 90655] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM

bed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/aa8aab29/attachment.html>

[PATCH 2/2] drm/radeon: Fix max_vblank_count value for current display engines

From: Michel Dänzer The value was much too low, which could cause the userspace visible vblank counter to move backwards when the hardware counter wrapped around. Signed-off-by: Michel Dänzer --- drivers/gpu/drm/radeon/radeon_irq_kms.c | 8 +++- 1 file changed, 7

[PATCH 1/2] drm: Fix off-by-one in vblank hardware counter wraparound handling

From: Michel Dänzer dev->max_vblank_count contains the largest value that can be represented by the hardware counter. When the hardware counter wraps around, we have to add that value + 1 to get the same value as if the hardware counter didn't wrap around.

[PATCH 1/2] drm: Fix off-by-one in vblank hardware counter wraparound handling

Nice catch! Both patches in this series are Reviewed-by: Christian König On 26.05.2015 10:53, Michel Dänzer wrote: > From: Michel Dänzer > > dev->max_vblank_count contains the largest value that can be represented > by the hardware counter. When the hardware counter wraps around, we have >

[Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)

... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/1b2b63d0/attachment-0001.html>

[Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)

t -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/47ed76d6/attachment.html>

[PATCH] drm/plane_helper: Use helper for plane->CRTC linkage

plane_state->crtc shouldn't be assigned directly, but instead use drm_atomic_set_crtc_for_plane, which also takes care of updating the plane_mask on each CRTC's state. Signed-off-by: Daniel Stone --- drivers/gpu/drm/drm_plane_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[PATCH] drm: Remove misleading paragraph from drm_vblank_pre_modeset kerneldoc comment

From: Michel Dänzer drm_vblank_pre/post_modeset work fine for the radeon driver even though it uses hardware counters, including suspend/resume. Signed-off-by: Michel Dänzer --- drivers/gpu/drm/drm_irq.c | 7 --- 1 file changed, 7 deletions(-) diff --git

[PATCH v2] drm/plane_helper: Use helper for plane->CRTC linkage

plane_state->crtc shouldn't be assigned directly, but instead use drm_atomic_set_crtc_for_plane, which also takes care of updating the plane_mask on each CRTC's state. v2: First patch sent by mistake; this one checks the return value. Signed-off-by: Daniel Stone ---

[PATCH v2] drm/plane_helper: Use helper for plane->CRTC linkage

plane_state->crtc shouldn't be assigned directly, but instead use drm_atomic_set_crtc_for_plane, which also takes care of updating the plane_mask on each CRTC's state. v2: First patch sent by mistake; this one checks the return value. Signed-off-by: Daniel Stone ---

[PATCH] drm: atmel_hlcdc: Add support for get_timings

Hi David, On Thu, 21 May 2015 11:06:56 +0200 David Dueck wrote: > drm_panel supports querying timing ranges. If the supplied mode does > not work with the hlcdc we query the panel and try to find a suitable > mode. This patch looks good to me. Philip, Thierry, could you confirm this is the

[Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)

dri-devel/attachments/20150526/5540fb58/attachment-0001.html>

[Bug 75357] Barts (HD6850): Failure in evergreen_surface_check_2d

downgrade seems like a good place to start. -- 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/20150526/618a211a/attachment.html>

[PATCH] drm/radeon: stop using addr to check for BO move

From: Christian König It is theoretically possible that a swapped out BO gets the same GTT address, but different backing pages while being swapped in. Instead just use another VA state to note updated areas. Signed-off-by: Christian König ---

[PATCH] drm/radeon: stop using addr to check for BO move

On 23.05.2015 21:06, Christian König wrote: > On 23.05.2015 20:58, Christian König wrote: >> From: Christian König >> >> It is theoretically possible that a swapped out BO gets the >> same GTT address, but different backing pages while being swapped in. >> >> Instead just use another VA state

[PATCH 1/2] drm: Fix off-by-one in vblank hardware counter wraparound handling

On Tue, May 26, 2015 at 05:53:38PM +0900, Michel Dänzer wrote: > From: Michel Dänzer > > dev->max_vblank_count contains the largest value that can be represented > by the hardware counter. When the hardware counter wraps around, we have > to add that value + 1 to get the same value as if the

[PATCH] drm: check for garbage in unused addfb2 fields

} > + } > + > return 0; > } > > -- > 2.1.4 > -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/a08da836/attachment-0001.sig>

[PATCH] drm: check for garbage in unused addfb2 fields

On Tue, May 26, 2015 at 02:38:44PM +0200, Thierry Reding wrote: > On Wed, May 20, 2015 at 04:53:53PM +0200, Daniel Vetter wrote: > > Unfortunately old userspace didn't clear this properly, but since > > we've added fb modifiers that's fixed. Checking properly that unused > > fields is important

[PATCH 8/8] acpi: Use booleans when probing different _DSM types

I'm thinking of re-writing this patch to just OR the different returned retval and test for individual bits directly in the final conditionals. So this would give something like: int retval = 0; while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev)) != NULL) { vga_count++;

2 questions about git and merging

Hi, a week ago I experienced problems on the skylake platform and got the adivce to try out the drm-intel-nightly branch. I tried and it was a success. So after the initial "git clone" of the tree I tried to keep updated by doing a "git pull" from time to time, but what's really strange is that

[Nouveau] [PATCH v2] nouveau: add coherent BO attribute

On Sun, May 24, 2015 at 3:26 PM, Maarten Lankhorst wrote: > Op 23-05-15 om 08:45 schreef Alexandre Courbot: >> On Fri, May 22, 2015 at 3:23 AM, Martin Peres >> wrote: >>> On 21/05/2015 11:47, Ben Skeggs wrote: On 21 May 2015 at 16:08, Alexandre Courbot wrote: > Add a flag allowing

[PATCH v3 2/4] drm: Add drm_atomic_set_mode_for_crtc

Add a new helper, to be used later for blob property management, that sets the mode for a CRTC state, as well as updating the CRTC enable/active state at the same time. v2: Do not touch active/mode_changed in CRTC state. Document return value. Remove stray drm_atomic_set_mode_prop_for_crtc

[Nouveau] [PATCH 2/8] acpi: Add evaluate to functons evaluating _DSM

s/functons/functions in the commit message. On 05/26/2015 12:22 AM, Pierre Moreau wrote: > This makes it clearer when reading the function name, as well as following the > names of the related ACPI function. > > Signed-off-by: Pierre Moreau > --- > drm/nouveau/nouveau_acpi.c | 25

[Nouveau] [PATCH 4/8] acpi: Allow evaluate_optimus_dsm to take NULL results

On 05/26/2015 12:22 AM, Pierre Moreau wrote: > Signed-off-by: Pierre Moreau > --- > drm/nouveau/nouveau_acpi.c | 10 -- > 1 file changed, 4 insertions(+), 6 deletions(-) > > diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c > index 36f4a40..073f7d7 100644 > ---

[Nouveau] [PATCH 7/8] acpi: Add support for Apple Gmux _DMS

On 05/26/2015 12:22 AM, Pierre Moreau wrote: > Signed-off-by: Pierre Moreau > --- > drm/nouveau/nouveau_acpi.c | 53 > -- > drm/nouveau/nouveau_acpi.h | 2 ++ > drm/nouveau/nouveau_drm.c | 6 -- > drm/nouveau/nouveau_vga.c | 10 +

[Spice-devel] [PATCH] Do not loop on ERESTARTSYS using interruptible waits

u asking if just removing the loop would fix the issue? > So you are proposing a first patch that add the argument always > passing true and another that change some calls to false? It make > sense but still the loop should be removed. Sorry, I was not clear, removing the loop is fine, I was not suggesting to keep it. Christophe -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/f94c5771/attachment.sig>

[Nouveau] [PATCH 5/8] acpi: Check returned object type by Optimus _DSM locally

On 05/26/2015 12:22 AM, Pierre Moreau wrote: > Most _DSM will return an integer value of 0x8002 when given an unknown > UUID, revision ID or function ID. Checking locally allows us to differentiate > that case from other ACPI errors, and to not report a "failed to evaluate > _DSM" > if

[PATCH v3 2/4] drm: Add drm_atomic_set_mode_for_crtc

On Tue, May 26, 2015 at 02:36:48PM +0100, Daniel Stone wrote: > Add a new helper, to be used later for blob property management, that > sets the mode for a CRTC state, as well as updating the CRTC enable/active > state at the same time. > > v2: Do not touch active/mode_changed in CRTC state.

2 questions about git and merging

On Tue, May 26, 2015 at 03:09:04PM +0200, Rainer Koenig wrote: > Hi, > > a week ago I experienced problems on the skylake platform and got the > adivce to try out the drm-intel-nightly branch. I tried and it was a > success. > > So after the initial "git clone" of the tree I tried to keep

[PATCH] drm/radeon: stop using addr to check for BO move

On Tue, May 26, 2015 at 6:24 AM, Christian König wrote: > From: Christian König > > It is theoretically possible that a swapped out BO gets the > same GTT address, but different backing pages while being swapped in. > > Instead just use another VA state to note updated areas. > >

[PATCH] drm: Remove misleading paragraph from drm_vblank_pre_modeset kerneldoc comment

On Tue, May 26, 2015 at 5:14 AM, Michel Dänzer wrote: > From: Michel Dänzer > > drm_vblank_pre/post_modeset work fine for the radeon driver even though > it uses hardware counters, including suspend/resume. > > Signed-off-by: Michel Dänzer Reviewed-by: Alex Deucher > --- >

[PATCH 0/3] R-Car DU fixes

Hello, This patch set fixes a crash in the R-Car DU driver (1/3) and adds two other small cleanups (2/3 and 3/3). Please see individual patches for details. Laurent Pinchart (3): drm: rcar-du: Fix crash with groups that have less than 9 planes drm: rcar-du: Clarify error message when encoder

[PATCH 1/3] drm: rcar-du: Fix crash with groups that have less than 9 planes

Commit 917de180379d ("drm: rcar-du: Implement universal plane support") made the number of planes per group dynamic, but didn't update all loops over the planes array, resulting in out-of-bound accesses on DU instances that have an odd number of CRTCs (such as the R8A7790). Fix it. Fixes:

[PATCH 2/3] drm: rcar-du: Clarify error message when encoder initialization fails

A failure to initialize an encoder currently prints an error message in the kernel log without mentioning which encoder failed to initialize. To help debugging initialization issues print the encoder DT node name. This requires moving the error message to the rcar_du_encoders_init_one function

[PATCH 3/3] drm: rcar-du: Convert rcar_du_encoders_init_one() return value to 0/<0

The function returns 1 on success, and either 0 or a negative error code on failure. As the 0 and negative values don't need to be differentiated by the caller, convert it to the usual scheme of returning 0 on success and a negative error code on failure. Signed-off-by: Laurent Pinchart

2 questions about git and merging

On Tue, 26 May 2015, Daniel Vetter wrote: > On Tue, May 26, 2015 at 03:09:04PM +0200, Rainer Koenig wrote: >> Hi, >> >> a week ago I experienced problems on the skylake platform and got the >> adivce to try out the drm-intel-nightly branch. I tried and it was a >> success. >> >> So after the

[PATCH] drm/atomic: fix out of bounds read in for_each_*_in_state helpers

On Mon, May 25, 2015 at 01:29:44PM +0300, Andrey Ryabinin wrote: > for_each_*_in_state validate array index after > access to array elements, thus perform out of bounds read. > > Fix this by validating index in the first place and read > array element iff validation was successful. > > Fixes:

[Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)

ou are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/5df78d1e/attachment.html>

[Bug 90655] [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM

- next part ------ An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/823ecf50/attachment-0001.html>

[Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)

hives/dri-devel/attachments/20150526/94be4a07/attachment.html>

[Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)

L attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/c5680d4c/attachment.html>

[Bug 90666] Stacktrace / Warning during switch (ctrl+alt+f1) to console on zbook 14 (Radeon/intel)

nts/20150526/c8ca9083/attachment.html>

[PATCH RFC v2 0/7] Implement generic ASoC HDMI codec

Only the first three patches are meant for serious review. The ASoC part should be ready for review in other respects but the EDID SADs handling is waiting for Russell King's DRM ELD helper patches. There is a copy-pasted not-to-be-merged patch with the same functionality in the patch series.

[PATCH RFC v2 1/7] ASoC: core: If component doesn't have of_node use parent's node instead

If an ASoC component device does not have a device tree node, use its parent's node instead, when looking for a matching DAI based on a device tree reference. This allows video device drivers to register a separate child device for their ASoC side audio functionality. Signed-off-by: Jyri Sarha

[PATCH RFC v2 2/7] ASoC: hdmi: Remove obsolete dummy HDMI codec

The hdmi stub codec has not been used since refactoring of OMAP HDMI audio support. Signed-off-by: Jyri Sarha --- sound/soc/codecs/Kconfig | 4 -- sound/soc/codecs/Makefile | 2 - sound/soc/codecs/hdmi.c | 109 -- 3 files changed, 115

[PATCH RFC v2 5/7] drm/i2c: tda998x: Add support of a DT graph of ports DO NOT MERGE

From: Jean-Francois Moine Two kinds of ports may be declared in a DT graph of ports: video and audio. This patch accepts the port value from a video port as an alternative to the video-ports property. It also accepts audio ports in the case the transmitter is not used as a slave

[PATCH RFC v2 4/7] ASoC: hdmi-codec: Add ELD based audio pcm rules DO NOT MERGE

This patch is mostly just a copy paste from Russel King's generic patchs[1] for the same thing. The patche is included only for testing purposes. Do not merge! [1] http://lists.freedesktop.org/archives/dri-devel/2015-April/080525.html Signed-off-by: Jyri Sarha --- sound/soc/codecs/hdmi-codec.c

[PATCH RFC v2 3/7] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

The hdmi-codec is a platform device driver to be registered from drivers of external HDMI encoders with I2S and/or spdif interface. The driver in turn registers an ASoC codec for the encoder's audio functionality. The structures and definitions in the API header are mostly redundant copies of

[PATCH RFC v2 6/7] drm/i2c: tda998x: Register ASoC HDMI codec for audio functionality DO NOT MERGE

This patch is here to demonstrate how to use the ASoC hdmi-codec to implement ASoC codec API in tda998x driver. I do not have proper documentation for tda998x family chips so I lack the necessary information for making a decent binding for audio part of the chip. In stead I use binding from

[PATCH RFC v2 7/7] ARM: dts: am335x-boneblack: Add HDMI audio support DO NOT MERGE

This patch is here only to demonstrate HDMI codec functionality on Beaglebone-Black. Adds mcasp0_pins, clk_mcasp0_fixed, clk_mcasp0, mcasp0, sound node, and changes the tda19988 node to follow the new binding. Signed-off-by: Jyri Sarha --- arch/arm/boot/dts/am335x-boneblack.dts | 78

[Bug 90666] Stacktrace / Warning during switch (ctrl+alt+f1) to console on zbook 14 (Radeon/intel)

ent was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/011cc123/attachment.html>

[Nouveau] [PATCH v2] nouveau: add coherent BO attribute

On 26/05/2015 16:23, Alexandre Courbot wrote: > On Sun, May 24, 2015 at 3:26 PM, Maarten Lankhorst > wrote: >> Op 23-05-15 om 08:45 schreef Alexandre Courbot: >>> On Fri, May 22, 2015 at 3:23 AM, Martin Peres >>> wrote: On 21/05/2015 11:47, Ben Skeggs wrote: > On 21 May 2015 at 16:08,

[Bug 90666] Stacktrace / Warning during switch (ctrl+alt+f1) to console on zbook 14 (Radeon/intel)

nts/20150526/dace950c/attachment.html>

[Bug 90666] Stacktrace / Warning during switch (ctrl+alt+f1) to console on zbook 14 (Radeon/intel)

ing 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/20150526/c78c8ae3/attachment.html>

[PATCH 3/3] drm: rcar-du: Convert rcar_du_encoders_init_one() return value to 0/<0

On Tue, May 26, 2015 at 5:01 PM, Laurent Pinchart wrote: > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > @@ -640,14 +640,14 @@ static int rcar_du_encoders_init_one(struct > rcar_du_device *rcdu, >

[Nouveau] [PATCH v2] nouveau: add coherent BO attribute

On 26/05/15 19:06, Martin Peres wrote: > On 26/05/2015 16:23, Alexandre Courbot wrote: >> On Sun, May 24, 2015 at 3:26 PM, Maarten Lankhorst >> wrote: >>> Op 23-05-15 om 08:45 schreef Alexandre Courbot: On Fri, May 22, 2015 at 3:23 AM, Martin Peres wrote: > On 21/05/2015 11:47, Ben

[Nouveau] [PATCH 8/8] acpi: Use booleans when probing different _DSM types

On 05/26/2015 02:46 PM, Pierre Moreau wrote: > I'm thinking of re-writing this patch to just OR the different returned > retval and test for individual bits directly in the final conditionals. > So this would give something like: > > > int retval = 0; > > while ((pdev =

[Bug 89987] Slow VDPAU (rv770_restrict_performance_levels_before_switch failed)

: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/9340a0c5/attachment.html>

[Bug 90668] vertical stripes/glitches on secondary screen r9 280x

hments/20150526/8b0c1500/attachment-0001.html>

[Bug 90668] vertical stripes/glitches on secondary screen r9 280x

|| -- 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/20150526/5b0ac9c7/attachment.html>

[Bug 98751] radeon: multihead "no signal" on one of the monitors - regression

https://bugzilla.kernel.org/show_bug.cgi?id=98751 --- Comment #10 from Alex Deucher --- Created attachment 178001 --> https://bugzilla.kernel.org/attachment.cgi?id=178001=edit possible fix Does the attached patch help? -- You are receiving this mail because: You are watching the assignee of

[Bug 90668] vertical stripes/glitches on secondary screen r9 280x

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/009cddcf/attachment.html>

[Bug 98751] radeon: multihead "no signal" on one of the monitors - regression

https://bugzilla.kernel.org/show_bug.cgi?id=98751 --- Comment #11 from Mikkel Oscar Lyderik --- It's working for me! -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 90668] vertical stripes/glitches on secondary screen r9 280x

/ -- 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/20150526/8cf8e1e0/attachment.html>

[Bug 90668] vertical stripes/glitches on secondary screen r9 280x

nee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/4fd0b95d/attachment.html>

[PATCH] drm/radeon: don't share plls if monitors differ in audio support

Enabling audio may enable different pll dividers. Don't share plls if the monitors differ in audio support. bug: https://bugzilla.kernel.org/show_bug.cgi?id=98751 Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/atombios_crtc.c | 4 +++- 1 file changed, 3

drm: imx: multi-display support questions

Hi all, After a few days of experimentation on multi-display support on i.MX6, I have some questions regarding the status of the imx-drm driver. Here is description of my testing setup: - Nitrogen6x (a SabreLite would work the same) - Mainline kernel 4.1-rc2 + a few patches for display support