;& ! chip->pcms[ATI_PCM_SPDIF]->rates)
:: The code at line 1298 was first introduced by commit
:: e36e3b86c78cee9c7435eb33e0ef8a788193e812 ALSA: Implement channel maps
for standard onboard AC97 drivers
:: TO: Takashi Iwai
:: CC: Takashi Iwai
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 28671 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/02168376/attachment-0001.gz>
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/20161220/1438bfd9/attachment.html>
ktop.org/archives/dri-devel/attachments/20161220/348d033a/attachment-0001.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/3e6f2be0/attachment.html>
Hi,
On Dec 19 2016 20:08, Arnaud Pouliquen wrote:
> Aim of this patch is to add 'Playback Channel Map' control to export
> audio capabilities in term of HDMI sink speakers allocation.
>
> V3:
> - "ASoC: hdmi-codec: add channel mapping control":
> => Minor fixes:
> - select stereo s
Hi Wolfram,
Thank you for the patch. It looks like I've missed it, sorry about that.
On Tuesday 01 March 2016 17:37:34 Wolfram Sang wrote:
> From: Wolfram Sang
>
> This change will also make Coverity happy by avoiding a theoretical NULL
> pointer dereference; yet another reason is to use the ab
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/2866b907/attachment.html>
Hi Swati,
On Monday 19 Dec 2016 16:12:22 swati.dhingra at intel.com wrote:
> From: Swati Dhingra
>
> Currently, we don't have a stable ABI which can be used for the purpose of
> providing output debug/loggging/crc and other such data from DRM.
> The ABI in current use (filesystems, ioctls, et al
Hi Daniel,
On Thursday 08 Dec 2016 11:04:47 Daniel Vetter wrote:
> On Thu, Dec 08, 2016 at 10:34:12AM +0200, Tomi Valkeinen wrote:
> > Remove Tomi Valkeinen from fbdev maintainer and mark fbdev as orphan.
> >
> > Signed-off-by: Tomi Valkeinen
> > ---
> >
> > I just don't have time to even prete
Hello,
This patch series implements support for the HDMI output on Renesas R-Car Gen3
SoCs, and more specifically on the R-Car H3.
R-Car Gen3 SoCs include one or multiple Synopsys DWC HDMI TX controllers. The
series thus starts with 20 cleanup or feature patches for the dw-hdmi driver.
Patches 01
The latter is just an int wrapper around the former void function that
unconditionally returns 0. As the return value is never checked, merge
the two functions into one.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 9 +
1 file changed, 1
Make it clear that the core bridge/dw_hdmi.txt document isn't a device
tree binding by itself but is meant to be referenced by platform device
tree bindings, and update the Rockchip and Freescale DWC HDMI TX
bindings to reference it.
Signed-off-by: Laurent Pinchart
Acked-by: Rob Herring
---
...
Detect the PHY type and use it to handle the PHY type-specific SVSRET
signal.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 68 ++--
include/drm/bridge/dw_hdmi.h | 10 ++
2 files changed, 75 insertions(+), 3 deletions(-)
diff
From: Kieran Bingham
The device type isn't used anymore now that workarounds and PHY-specific
operations are performed based on version information read at runtime.
Remove it.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c| 2 --
From: Koji Matsuoka
The implementation hardcodes a workaround for the H3 ES1.x SoC
regardless of the SoC revision, as the workaround can be safely applied
on all devices in the Gen3 family without any side effect.
Signed-off-by: Koji Matsuoka
Signed-off-by: Ulrich Hecht
Signed-off-by: Laurent
From: Koji Matsuoka
Update the device description with the two available HDMI outputs.
Signed-off-by: Koji Matsuoka
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 4 +++-
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 12 ++--
2 files changed, 13 insertions(+)
The color space converter isn't part of the PHY, move its configuration
out of PHY code.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers
The DWC HDMI TX can be recognized by the two product identification
registers. If the registers don't read as expect the IP will be very
different than what the driver has been designed for, or will be
misconfigured in a way that makes it non-operational (invalid memory
address, incorrect clocks, .
From: Kieran Bingham
The current code hard codes the call of hdmi_phy_configure() to be 8bpp
and provides extraneous error checking to verify that this hardcoded
value is correct. Simplify the implementation by removing the argument.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
From: Kieran Bingham
The 'prep' parameter passed to hdmi_phy_configure() is useless. It is
hardcoded as 0, and if set, simply prevents the configure function from
executing.
Remove it.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/
The master argument isn't used. The data argument, a void pointer, is
used by the bind function only where it's cast to a drm_device pointer,
which can easily be obtained from the encoder argument instead. Remove
them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/
The drm_bridge instance is always needed, there's no point in allocating
it separately.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.
From: Koji Matsuoka
Instantiate the HDMI connectors and enable the encoders.
Signed-off-by: Koji Matsuoka
Signed-off-by: Ulrich Hecht
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 50 ++
1 file changed, 50 insertions(+)
diff --g
There's no need to duplicate identical code in multiple drivers (two at
the moment, one more to come soon). Move it to the dw-hdmi core where it
can be shared. If resource allocation ever becomes device-specific later
we'll always have the option of splitting it out again.
While it at pass the pla
The bit is documented in a Rockchip BSP as
#define m_SVSRET_SIG (1 << 5) /* depend on PHY_MHL_COMB0=1 */
This is confirmed by a Renesas platform, which uses a 2.0 DWC HDMI TX as
the RK3288. Rename the bit accordingly.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdm
Bit 0 in CONFIG1_ID tells whether the IP core uses an AHB slave
interface for control. The correct way to identify AHB audio DMA support
is through bit 1 in CONFIG3_ID.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 6 +++---
drivers/gpu/drm/bridge/dw-hdmi.h | 4
2 f
From: Koji Matsuoka
The R-Car Gen3 SoCs include on-chip DesignWare HDMI encoders. Support
them with a platform driver to provide platform glue data to the dw-hdmi
driver.
The driver is a complete rewrite of code coming from the Renesas BSP,
save for the values in the PHY parameters table.
Signe
From: Ulrich Hecht
Add DT nodes for the two HDMI encoders in disabled state.
Based on work by Koji Matsuoka.
Signed-off-by: Ulrich Hecht
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 50
1 file changed, 50 insertions(+)
diff
As an option for drivers not based on the component framework, register
the bridge with the DRM core with the DRM bridge API. Existing drivers
based on dw_hdmi_bind() and dw_hdmi_unbind() are not affected as those
functions are preserved with their current behaviour.
Signed-off-by: Laurent Pinchar
The next commit will reference structures and functions in a way that
currently requires forward declarations. Reorder the functions to avoid
that. No functional change to the code is performed.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 72 ++
When a DT node connected to a DU output is disabled no bridge will ever
be instantiated for it. Skip the output in that case.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
The DU1 and DU2 external dot clocks are fixed frequency clock generators
running at 33MHz.
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 23 ++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvat
The field isn't needed, remove it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 2c85b6c07a80..ef
Hotplug events should only be forwarded to the DRM core by the interrupt
handler when the bridge has been attached, otherwise the DRM device
pointer will be NULL, resulting in a crash.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 3 ++-
1 file c
From: Kieran Bingham
The DWC HDMI TX controller interfaces with a companion PHY. While
Synopsys provides multiple standard PHYs, SoC vendors can also integrate
a custom PHY.
Modularize PHY configuration to support vendor PHYs through platform
data. The existing PHY configuration code was origina
Instead of spreading version-dependent PHY power handling code around,
group it in two functions to power the PHY on and off and use them
through the driver.
Powering off the PHY at the beginning of the setup phase is currently
split in two locations for first and second generation PHYs, group all
Use the device version queried at runtime instead of the device type
provided through platform data to handle the overflow workaround. This
will make support of other SoCs integrating the same HDMI TX controller
version easier.
Among the supported platforms only i.MX6DL and i.MX6Q have been
identi
The DRM device is not guaranteed by the bridge API to be available
before the attach callback. The driver performs properly at the moment
as it doesn't use the drm_bridge_add() registration method. As this will
be changed later, move connector creation to attach time to ensure
compatibility with th
The Renesas R-Car Gen3 SoCs use a Synopsys DWC HDMI TX encoder IP. Add
corresponding device tree bindings based on the DWC HDMI TX bindings
model.
Signed-off-by: Laurent Pinchart
Acked-by: Rob Herring
---
.../bindings/display/bridge/renesas,dw-hdmi.txt| 75 ++
MAINTAINER
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/10a5f923/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/daec4bd4/attachment.html>
988.
--
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/20161220/da505e7c/attachment-0001.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161220/333adb6a/attachment.html>
rrect
?
--
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/20161220/3045e00d/attachment.html>
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/59063165/attachment.html>
|--- |FIXED
--
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/20161220/17e89216/attachment.html>
On 12/19/2016 06:20 PM, Maarten Lankhorst wrote:
> Op 19-12-16 om 13:08 schreef Archit Taneja:
>> This code has been more or less picked up from the vc4 and intel
>> implementations of update_plane() funcs for cursor planes.
>>
>> The update_plane() func is usually the drm_atomic_helper_update_pl
Hi Bibby,
On Wed, 2016-12-14 at 13:14 +0800, Bibby Hsieh wrote:
> MT8173 overlay can support UYVY and YUYV format,
> we add the format in DRM driver.
>
> Signed-off-by: Bibby Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 6 ++
> drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 ++
>
On Mon, Dec 12, 2016 at 11:34:55AM +0100, Maarten Lankhorst wrote:
> Do something similar to vc4, only allow updating the cursor state
> in-place through a fastpath when the watermarks are unaffected. This
> will allow cursor movement to be smooth, but changing cursor size or
> showing/hiding curso
On Mon, Dec 19, 2016 at 11:15:40PM +, Pandiyan, Dhinakaran wrote:
> On Sun, 2016-12-18 at 14:43 +0100, Daniel Vetter wrote:
> > On Sat, Dec 17, 2016 at 05:47:56AM +, Pandiyan, Dhinakaran wrote:
> > > On Fri, 2016-12-16 at 16:47 +0200, Jani Nikula wrote:
> > > > On Fri, 16 Dec 2016, Daniel V
On Tue, 20 Dec 2016, Laurent Pinchart
wrote:
> Hi Swati,
>
> On Monday 19 Dec 2016 16:12:22 swati.dhingra at intel.com wrote:
>> From: Swati Dhingra
>>
>> Currently, we don't have a stable ABI which can be used for the purpose of
>> providing output debug/loggging/crc and other such data from D
On Mon, Dec 19, 2016 at 10:43:49PM +0800, Geliang Tang wrote:
> To make the code clearer, use rb_entry() instead of container_of() to
> deal with rbtree.
>
> Signed-off-by: Geliang Tang
Not sure a direct alias for container_of is all that useful, but we have
list_entry too ...
Queued up for 4.1
this.
--
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/20161220/bf8e0671/attachment.html>
Some cursor SSPP related updates.
Archit Taneja (2):
rnndb: mdp5: Add missing bitfields for MDP5_LM_BLEND_COLOR_OUT
rnndb: mdp5: Update mdp5_pipe
rnndb/mdp/mdp5.xml | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
--
The Qualcomm Innovation Center, Inc.
Signed-off-by: Archit Taneja
---
rnndb/mdp/mdp5.xml | 4
1 file changed, 4 insertions(+)
diff --git a/rnndb/mdp/mdp5.xml b/rnndb/mdp/mdp5.xml
index de9560b..49aa207 100644
--- a/rnndb/mdp/mdp5.xml
+++ b/rnndb/mdp/mdp5.xml
@@ -451,6 +451,10 @@ xsi:schemaLocation="http://nouveau.freedesktop.o
Update mdp5_pipe to incorporate SSPP_NONE and SSPP_CURSORx
pipes
Signed-off-by: Archit Taneja
---
rnndb/mdp/mdp5.xml | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/rnndb/mdp/mdp5.xml b/rnndb/mdp/mdp5.xml
index 49aa207..a5ae1e3 100644
--- a/rnndb/m
--
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/20161220/0cf2cdc8/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/bfd64ae0/attachment.html>
Hi Ville,
On Thu, Dec 08, 2016 at 05:57:55PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 08, 2016 at 11:12:41AM +0800, Shawn Guo wrote:
>
> > +static void zx_vl_plane_atomic_update(struct drm_plane *plane,
> > + struct drm_plane_state *old_state)
> > +{
> > + str
From: Shawn Guo
It enables VOU VL (Video Layer) to support overlay plane with scaling
function. VL0 has some quirks on scaling support. We chose to skip it
and only adds VL1 and VL2 into DRM core for now.
Signed-off-by: Shawn Guo
---
Changes for v2:
- Use clipped coordinates for overlay posi
Hi Laurent,
On 2016-12-18 21:31, Laurent Pinchart wrote:
> Hi Stefan and Thierry,
>
> As the author and suggester of the other bus flags, could you please review
> this patch ?
It looks to me like an appropriate use case for the flag. One remark
below:
>
> On Saturday 19 Nov 2016 05:28:04 Lau
Hi Jose,
On Tuesday 20 Dec 2016 11:39:21 Jose Abreu wrote:
> On 20-12-2016 01:33, Laurent Pinchart wrote:
> > Detect the PHY type and use it to handle the PHY type-specific SVSRET
> > signal.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > drivers/gpu/drm/bridge/dw-hdmi.c | 68
out.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/c71b35da/attachment.sig>
Hi Stefan,
Thank you for the review.
On Tuesday 20 Dec 2016 14:01:46 Stefan Agner wrote:
> On 2016-12-18 21:31, Laurent Pinchart wrote:
> > Hi Stefan and Thierry,
> >
> > As the author and suggester of the other bus flags, could you please
> > review this patch ?
>
> It looks to me like an appr
This patch creates a new structure drm_hdmi_info (inspired from
drm_display_info). Driver will parse HDMI sink's advance capabilities
from HF-VSDB and populate this structure. This structure will be kept
and used as a sub-class within drm_display_info.
We are adding parsing of HF-VSDB In the next
HDMI 2.0 / CEA-861-F specs define a new CEA extension data block,
called hdmi-forum vendor specific data block (HF-VSDB). This block
contains information about sink's support for HDMI 2.0 compliant
features. These features are:
- Deep color YUV 420 support and BPC
- 3D flags for
- O
On 2016-12-20 14:21, Laurent Pinchart wrote:
> Hi Stefan,
>
> Thank you for the review.
>
> On Tuesday 20 Dec 2016 14:01:46 Stefan Agner wrote:
>> On 2016-12-18 21:31, Laurent Pinchart wrote:
>> > Hi Stefan and Thierry,
>> >
>> > As the author and suggester of the other bus flags, could you pleas
Op 20-12-16 om 07:23 schreef Archit Taneja:
>
>
> On 12/19/2016 06:20 PM, Maarten Lankhorst wrote:
>> Op 19-12-16 om 13:08 schreef Archit Taneja:
>>> This code has been more or less picked up from the vc4 and intel
>>> implementations of update_plane() funcs for cursor planes.
>>>
>>> The update_pl
Hi Russell,
Thank you for the review.
On Tuesday 20 Dec 2016 11:45:53 Russell King - ARM Linux wrote:
> On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
> > Instead of spreading version-dependent PHY power handling code around,
> > group it in two functions to power the PHY on an
On Mon, 19 Dec 2016, Arnaud Pouliquen wrote:
> Add helper to allow users to retrieve the speaker allocations without
> knowledge of the ELD structure.
>
> Signed-off-by: Arnaud Pouliquen
I've already replied with my Reviewed-by, please take care to include
them.
Reviewed-by: Jani Nikula
> --
The drm_mm range manager claimed to support top-down insertion, but it
was neither searching for the top-most hole that could fit the
allocation request nor fitting the request to the hole correctly.
In order to search the range efficiently, we create a secondary index
for the holes using either t
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/bf0bdf6e/attachment.html>
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/c0f7b262/attachment.html>
On Mon, Dec 19, 2016 at 03:16:44PM +0100, Juergen Gross wrote:
> On 19/12/16 13:29, Chris Wilson wrote:
> > On Mon, Dec 19, 2016 at 12:39:16PM +0100, Juergen Gross wrote:
> >> With recent 4.10 kernel the graphics isn't coming up under Xen. First
> >> failure message is:
> >>
> >> [ 46.656649] i91
On Tue, Dec 20, 2016 at 4:44 AM, Jani Nikula
wrote:
> On Tue, 20 Dec 2016, Laurent Pinchart
> wrote:
>> Hi Swati,
>>
>> On Monday 19 Dec 2016 16:12:22 swati.dhingra at intel.com wrote:
>>> From: Swati Dhingra
>>>
>>> Currently, we don't have a stable ABI which can be used for the purpose of
>>>
Here is a short trio of drm/msm fixes suitable for 4.10. The first
fixes a hang that occurs when the ring is completely filled, the
other two can be triggered through the API and cause mild distress.
Jordan Crouse (3):
drm/msm: Ensure that the hardware write pointer is valid
drm/msm: Put back
Currently the value written to CP_RB_WPTR is calculated on the fly as
(rb->next - rb->start). But as the code is designed rb->next is wrapped
before writing the commands so if a series of commands happened to
fit perfectly in the ringbuffer, rb->next would end up being equal to
rb->size / 4 and thu
For every submission buffer object one of MSM_SUBMIT_BO_WRITE
and MSM_SUBMIT_BO_READ must be set (and nothing else). If we
allowed zero then the buffer object would never get queued to
be unreferenced.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gem_submit.c | 3 ++-
1 file changed,
The error cases in submit_reloc() need to put back the virtual
address of the bo before failling. Add a single failure path
for the function.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gem_submit.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/
On Fri, Dec 16, 2016 at 8:02 PM, Kees Cook wrote:
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
> extracted from grsecuri
On Tue, Dec 20, 2016 at 09:42:46AM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 19, 2016 at 03:16:44PM +0100, Juergen Gross wrote:
> > On 19/12/16 13:29, Chris Wilson wrote:
> > > On Mon, Dec 19, 2016 at 12:39:16PM +0100, Juergen Gross wrote:
> > >> With recent 4.10 kernel the graphics isn't c
On Thu, Dec 4, 2014 at 8:03 PM, Sean Paul wrote:
> Add new standard connector properties to track whether content protection
> (ex: hdcp) is desired by userspace. There are two properties involved,
> "Content Protection" and "Content Protection KSV".
>
> The "Content Protection" property allows us
https://bugzilla.kernel.org/show_bug.cgi?id=107001
--- Comment #4 from Timo Valtoaho ---
...and with 4.9.0.
Sadly this has been bothering for over a year now. Anybody else suffering from
this?
--
You are receiving this mail because:
You are watching the assignee of the bug.
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/515390aa/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/885bb11f/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/25783faa/attachment.html>
-
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/20161220/3da80e57/attachment.html>
nt was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/8a008f56/attachment-0001.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161220/8d31b457/attachment.html>
From: "Kristian H. Kristensen"
This new ioctl exctends DRM_IOCTL_MODE_GETPLANE, by returning
information about the modifiers that will work with each format.
Signed-off-by: Kristian H. Kristensen
---
drivers/gpu/drm/arm/hdlcd_crtc.c| 1 +
drivers/gpu/drm/armada/armada_crtc.c
Signed-off-by: Kristian H. Kristensen
---
drivers/gpu/drm/i915/intel_display.c | 35 ---
drivers/gpu/drm/i915/intel_sprite.c | 36 +++-
2 files changed, 67 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_displ
From: "Kristian H. Kristensen"
This adds support for the new DRM_IOCTL_MODE_GETPLANE2 ioctl. For older
kernels drmModeGetPlane2() falls back to DRM_IOCTL_MODE_GETPLANE and
return the new, bigger drmModePlaneRec, reporting 0 modifiers.
BUG=chrome-os-partner:56407
TEST=modetest with next commit re
From: "Kristian H. Kristensen"
BUG=chrome-os-partner:56407
TEST=modetest on a KMS driver that exposes modifiers should print those
Change-Id: I91b2a408b1c8f112d7ba5d0998119b3c800b199c
---
tests/modetest/modetest.c | 40
1 file changed, 36 insertions(+),
On Tue, Dec 20, 2016 at 7:12 PM, Kristian H. Kristensen
wrote:
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index ce7efe2..cea3de3 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -209,6 +209,33 @@ struct drm_mode_get_plane {
>
Hi Dave,
Fixes for 4.10. Highlights:
- fix display regression on DCE6/8
- Powergating fixes for GFX8
- amdgpu SI fixes (golden settings, proper rev id setup, etc.)
The following changes since commit 2cf026ae85c42f253feb9f420d1b4bc99bd5503d:
Merge branch 'linux-4.10' of git://github.com/skeggs
This check is useful for drivers that do not have DRIVER_ATOMIC set but
have atomic modesetting internally implemented. Wrap the check into a
function since this is used in many places and as a bonus, the function
name helps to document what the check is for.
Suggested-by: Daniel Vetter
Cc: Danie
The suggested X and Y connector properties are intended as a way for drivers
for virtual machine GPUs to provide information about the layout of the
host system windows (or whatever) corresponding to given guest connectors.
The intention is for the guest system to lay out screens in the virtual
des
Hi Shashank,
On 20-12-2016 13:47, Shashank Sharma wrote:
> HDMI 2.0 / CEA-861-F specs define a new CEA extension data block,
> called hdmi-forum vendor specific data block (HF-VSDB). This block
> contains information about sink's support for HDMI 2.0 compliant
> features. These features are:
>
Hi Laurent,
On 20-12-2016 01:33, Laurent Pinchart wrote:
> Bit 0 in CONFIG1_ID tells whether the IP core uses an AHB slave
> interface for control. The correct way to identify AHB audio DMA support
> is through bit 1 in CONFIG3_ID.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
B
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang
---
drivers/gpu/drm/nouveau/nvkm/engine/dma/base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/dma/base.c
b/drivers
1 - 100 of 112 matches
Mail list logo
