https://bugzilla.kernel.org/show_bug.cgi?id=120591
Dmitrii Tcvetkov changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #8 from Dmitrii Tc
From: Christian König
Looks like the VCE block sometimes still sends nonsense
fence numbers on startup.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgp
From: Christian König
We want to keep the newest fence, not the oldest one.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 0c
since both use OpenGL...).
--
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/20160624/4be58c25/attachment.html>
irmware: firmware-amd-graphics/20160110-1
libclc: Git:master/20d977a3e6
DDX: 1:7.7.0-1
--
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/
crubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160624/5c8c5179/attachment.html>
Support non-legacy drivers without mode-setting functionality by using
the new DRIVER_LEGACY feature to separate out legacy code, rather than
relying on DRIVER_MODESET not being advertised.
Signed-off-by: Thierry Reding
v2:
- Rebase
- Change a few more places to check against DRIVER_LEGACY
- Mov
From: Thierry Reding
Currently drivers that set the DRIVER_MODESET feature are considered to
be non-legacy drivers. At the same time DRIVER_MODESET implies that the
mode-setting IOCTLs are available. It is therefore not possible to
distinguish between a non-legacy driver with full mode-setting su
From: Thierry Reding
The QXL driver sets DRIVER_MODESET unconditionally, so testing for the
absence of the feature will always fail.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/qxl/qxl_kms.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gp
This flag was being set unconditionally at runtime so just set it at
compile time instead.
Signed-off-by: Frank Binns
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/a
This brings the minor type name into line with how the actual minor,
using this type, is referenced throughout the rest of drm.
Signed-off-by: Frank Binns
---
drivers/gpu/drm/drm_drv.c | 16
include/drm/drmP.h| 4 ++--
2 files changed, 10 insertions(+), 10 deletions(-)
Use the appropriate drm minor type helper instead.
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Signed-off-by: Frank Binns
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx
This series resurrects work originally done by Thierry Reding (hence
the v2) but without taking things quite as far as the original [1].
The motivation for this series is to remove the dual meaning of
the DRIVER_MODESET feature flag, whereby it means "support kernel
modesetting" and "don't expose
On Fri, Jun 24, 2016 at 1:15 PM, Frank Binns wrote:
> This flag was being set unconditionally at runtime so just set it at
> compile time instead.
>
> Signed-off-by: Frank Binns
Reviewed-by: Alex Deucher
Do you want to take this as part of the patch set, or should I apply
this to my tree?
Ale
DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not
disconnections. Because of this, we end up losing hotplug polling for
analog connectors once they get connected.
Easy way to reproduce:
- Grab a machine with an AMD GPU and a VGA port
- Plug a monitor into the VGA port, wait fo
DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not
disconnections. Because of this, we end up losing hotplug polling for
analog connectors once they get connected.
Easy way to reproduce:
- Grab a machine with a radeon GPU and a VGA port
- Plug a monitor into the VGA port, wait
Whoops, very sorry about this! I ran git send-email, and it looks like
I had forgotten to remove some other patches in my patches/ folder.
Going to resend this to avoid confusing anyone trying to review this.
On Fri, 2016-06-24 at 17:45 -0400, Lyude wrote:
> DRM_CONNECTOR_POLL_CONNECT only enables
While VGA hotplugging worked(ish) before, it looks like that was mainly
because we'd unintentionally enable it in
valleyview_crt_detect_hotplug() when we did a force trigger. This
doesn't work reliably enough because whenever the display powerwell on
vlv gets disabled, the values set in VLV_ADPA ge
This lets call intel_crt_reset() in contexts where IRQs are disabled and
as such, can't hold the locks required to work with the connectors.
Cc: stable at vger.kernel.org
Cc: Ville Syrjälä
Acked-by: Daniel Vetter
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_crt.c | 10 +-
1 fi
Latest version of:
https://lists.freedesktop.org/archives/intel-gfx/2016-June/098787.html
The only patch that's changed here is 4/4, the rest are just being sent so that
they can be in one thread to make things easier for reviewers
Lyude (4):
drm/i915/vlv: Make intel_crt_reset() per-encoder
DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not
disconnections. Because of this, we end up losing hotplug polling for
analog connectors once they get connected.
Easy way to reproduce:
- Grab a machine with an AMD GPU and a VGA port
- Plug a monitor into the VGA port, wait fo
DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not
disconnections. Because of this, we end up losing hotplug polling for
analog connectors once they get connected.
Easy way to reproduce:
- Grab a machine with a radeon GPU and a VGA port
- Plug a monitor into the VGA port, wait
Am 24.06.2016 um 16:59 schrieb Gustavo Padovan:
> 2016-06-24 Christian König :
>
>> Am 24.06.2016 um 15:17 schrieb Gustavo Padovan:
>>> Hi Christian,
>>>
>>> 2016-06-24 Christian König :
>>>
Am 23.06.2016 um 17:29 schrieb Gustavo Padovan:
> From: Gustavo Padovan
>
> Hi all,
The current output code only supports connection to drm panels.
Add codes to support drm bridge, to supports connection to
external connectors.
Signed-off-by: Meng Yi
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm
This patch rework the output code to add of_graph dt binding support
for panel device and also keeps the backward compatibility
Signed-off-by: Meng Yi
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c| 2 +-
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h | 3 +-
drivers/gpu/drm/fsl-dcu/fsl_dcu_d
From: Michel Dänzer
Consolidate the _DRM_VBLANK_NEXTONMISS handling between drm_wait_vblank
and drm_queue_vblank_event.
This is a cleanup spotted while working on other changes.
(The way it was previously handled could also theoretically result in
drm_queue_vblank_event unnecessarily bumping v
Am 24.06.2016 um 15:17 schrieb Gustavo Padovan:
> Hi Christian,
>
> 2016-06-24 Christian König :
>
>> Am 23.06.2016 um 17:29 schrieb Gustavo Padovan:
>>> From: Gustavo Padovan
>>>
>>> Hi all,
>>>
>>> This is an attempt to improve fence support on Sync File. The basic idea
>>> is to have only sync
On Fri, Jun 17, 2016 at 8:48 PM, Daniel Vetter wrote:
> On Fri, Jun 17, 2016 at 12:13:41PM +0200, Lucas Stach wrote:
>> Drop the load/unload driver ops, as they are deprecated because of their
>> inherent races, with devices being visible to userspace before they are
>> fully initialized.
>>
>> Mo
Thanks!
Reviewed-by: Sinclair Yeh
On Fri, Jun 24, 2016 at 06:15:15PM +0100, Frank Binns wrote:
> Use the appropriate drm minor type helper instead.
>
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> Signed-off-by: Frank Binns
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 3 +--
> 1 file changed
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160624/3639d4a2/attachment.html>
This has now been removed from all drivers as it is performed centrally
as a part of device unregistration for modesetting drivers. With the last
user gone, we can unexport it from the DRM module. That requires us to
move the code slightly to avoid the need for a forward declaration.
Signed-off-by
Rather than manually perform our unregistration actions before shutting
down the device, move them to drm_unplug_dev().
Signed-off-by: Chris Wilson
Cc: David Airlie
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: Alexey Brodkin
Cc: Amitoj Kaur Chawla
Cc: dri-devel at lists.freedesktop.org
---
dr
Rather than do a partial unregister of just the minors, unregister the
device (drm_dev_unregister(), and so remove all userspace interfaces,
when the device is unplugged (drm_unplug_dev()).
Signed-off-by: Chris Wilson
Cc: David Airlie
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: Alexey Brodkin
drm_connector_unregister_all() is automatically called by
drm_dev_unregister() and so the manual call can be dropped.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Maxime Ripard
Cc: David Airlie
Cc: Chen-Yu Tsai
Cc: dri-devel at lists.freedesktop.org
Cc: linux-arm-kernel at lists.infradea
This has now been removed from all drivers as it is performed centrally
as a part of device registration for modesetting drivers. With the last
user gone, we can unexport it from the DRM module.
Signed-off-by: Chris Wilson
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel at lists.freedesktop.or
Hi Dave,
Please consider merging this tag, which contains the v2 MT8173 gamma & dither
function patches I sent on 2016-06-17, rebased onto v4.7-rc1. There have been
no further comments.
Thanks
Bibby
The following changes since commit 1a695a905c18548062509178b98bc91e67510864:
Linux 4.7-rc1 (
On Thu, Jun 23, 2016 at 04:59:02PM +0100, Jon Hunter wrote:
> On Tegra124, Tegra132 and Tegra210 devices the pads used by the Display
> Port Auxiliary (DPAUX) channel are multiplexed such that they can also
> be used by one of the internal I2C controllers. Note that this is
> different from I2C-ove
On Thu, Jun 23, 2016 at 04:59:00PM +0100, Jon Hunter wrote:
> The I2C driver core for boards using device-tree assumes any subnode of
> an I2C adapter in the device-tree blob as being a I2C slave device.
> Although this makes complete sense, some I2C adapters may have subnodes
> which are not I2C s
On Thu, Jun 23, 2016 at 04:58:57PM +0100, Jon Hunter wrote:
> Update the DPAUX compatibility string information for Tegra124, Tegra132
> and Tegra210.
>
> Signed-off-by: Jon Hunter
> ---
> .../devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt | 6
> +++---
> 1 file changed, 3 inse
On Thu, Jun 23, 2016 at 08:51:03PM +0800, Chris Zhong wrote:
> This patch adds a binding that describes the cdn DP controller for
> rk3399.
>
> Signed-off-by: Chris Zhong
>
> ---
>
> Changes in v3:
> - add SoC specific compatible string
> - remove reg = <1>;
>
> Changes in v2: None
> Changes i
On Thu, Jun 23, 2016 at 12:27:59PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> When running in HDMI mode, the sor1 IP block needs to use the sor1_src
> as parent clock, and in turn configure the sor1_src to use pll_d2_out0
> as its parent.
>
> Signed-off-by: Thierry Reding
> ---
>
Currently enabling Exynos DRM support automatically pulls in
lots of fbdev dependencies. However these deps are
unnecessary since DRM core already enables them when
needed.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/Kconfig | 4
1 file changed, 4 deletions(-)
diff --git a/driv
On Fri, Jun 24, 2016 at 12:48:17PM +0100, Steven Newbury wrote:
> On Fri, 2016-06-24 at 11:59 +0100, Chris Wilson wrote:
> > On Thu, Jun 23, 2016 at 02:14:12PM +0100, Steven Newbury wrote:
> > > On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote:
> > > > On Thu, 23 Jun 2016, Steven Newbury
> > >
r the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160624/28b1934d/attachment.html>
ves/dri-devel/attachments/20160624/08fe91bc/attachment.html>
der requires
230 registers
--
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/20160624/26c49ee9/attachment.html>
orking properly
on IVB?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160624/3537ed86/attachment.sig>
2016-06-24 Christian König :
> Am 24.06.2016 um 16:59 schrieb Gustavo Padovan:
> > 2016-06-24 Christian König :
> >
> > > Am 24.06.2016 um 15:17 schrieb Gustavo Padovan:
> > > > Hi Christian,
> > > >
> > > > 2016-06-24 Christian König :
> > > >
> > > > > Am 23.06.2016 um 17:29 schrieb Gustav
2016-06-24 Christian König :
> Am 24.06.2016 um 15:17 schrieb Gustavo Padovan:
> > Hi Christian,
> >
> > 2016-06-24 Christian König :
> >
> > > Am 23.06.2016 um 17:29 schrieb Gustavo Padovan:
> > > > From: Gustavo Padovan
> > > >
> > > > Hi all,
> > > >
> > > > This is an attempt to improve
On Thu, Jun 23, 2016 at 02:14:12PM +0100, Steven Newbury wrote:
> On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote:
> > On Thu, 23 Jun 2016, Steven Newbury wrote:
> > > I'm seeing this on my IvyBridge. Â I'll try reverting the commit
> > > here
> > > too, to see if it's the same issue.
> >
>
On Fri, Jun 24, 2016 at 11:23:56AM +0100, Frank Binns wrote:
> Stop claiming that UMS support is disabled when it's not actually
> supported anymore.
>
> Signed-off-by: Frank Binns
But not technically untrue!
Reviewed-by: Chris Wilson
Since I have a series touching this code, I'll pull it into
From: Kuninori Morimoto
Current dw-hdmi is supporting sound via AHB bus, but it has
I2S audio feature too. This patch adds I2S audio support to dw-hdmi.
This HDMI I2S is supported by using ALSA SoC common HDMI encoder
driver.
Signed-off-by: Kuninori Morimoto
---
drivers/gpu/drm/bridge/Kconfig
Am 23.06.2016 um 17:29 schrieb Gustavo Padovan:
> From: Gustavo Padovan
>
> Hi all,
>
> This is an attempt to improve fence support on Sync File. The basic idea
> is to have only sync_file->fence and store all fences there, either as
> normal fences or fence_arrays. That way we can remove some pot
On 16-06-13 15:35:51, Petko Manolov wrote:
> On 16-06-13 13:29:46, Petko Manolov wrote:
> > Hello guys,
> >
> > Running xorg on my Lenovo Yoga 2 Pro (MY2013) on recent kernels turn into a
> > major PITA. After a couple of minutes the screen starts to flicker and
> > only
> > killing xorg o
Stop claiming that UMS support is disabled when it's not actually
supported anymore.
Signed-off-by: Frank Binns
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3eb47fb.
Signed-off-by: Frank Binns
---
drivers/gpu/drm/drm_irq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 8ca3d2b..149453c 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -532,7 +532,7 @@
On 06/23/2016 08:15 PM, Rob Herring wrote:
> On Thu, Jun 23, 2016 at 9:13 AM, Archit Taneja
> wrote:
>> The DSI host and PHY driver currently expects the DT bindings to provide
>> custom properties "qcom,dsi-host-index" and "qcom,dsi-phy-index" so that
>> the driver can identify which DSI insta
2016-06-23 Chris Wilson :
> On Thu, Jun 23, 2016 at 12:29:50PM -0300, Gustavo Padovan wrote:
> > -static void sync_file_add_pt(struct sync_file *sync_file, int *i,
> > +static int sync_file_set_fence(struct sync_file *sync_file,
> > + struct fence **fences)
> > +{
> > +
Here's a regression you might add. I only reported it to dri-devel,
since it's DRI-specific, but since there's been thunderous silence
for a few weeks, I'm trying to be a squeakier wheel.
Given that I bisected it to a single, small, revertable commit, I'd
hoped it would be easy to deal with.
[BI
2016-06-23 Chris Wilson :
> On Thu, Jun 23, 2016 at 12:29:46PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > fence_array requires a function to clean up its state before we
> > are able to call fence_put() and release it.
>
> An explanation along the lines of:
>
> As the arra
Hi Christian,
2016-06-24 Christian König :
> Am 23.06.2016 um 17:29 schrieb Gustavo Padovan:
> > From: Gustavo Padovan
> >
> > Hi all,
> >
> > This is an attempt to improve fence support on Sync File. The basic idea
> > is to have only sync_file->fence and store all fences there, either as
>
From: Simon Xue
This patch makes it possible to compile the rockchip-iommu driver on
ARM64, so that it can be used with 64-bit SoCs equipped with this type
of IOMMU.
Signed-off-by: Simon Xue
Signed-off-by: Shunqian Zheng
Signed-off-by: Tomasz Figa
---
drivers/iommu/Kconfig | 2 +-
1 file cha
Rockchip DRM used the arm special API, arm_iommu_*(), to attach
iommu for ARM32 SoCs. This patch convert to common iommu API
so it would support ARM64 like RK3399.
Since previous patch added support for direct IOMMU address space
management, there is no need to use DMA API anymore and this patch w
From: Tomasz Figa
The API is not suitable for subsystems consisting of multiple devices
and requires severe hacks to use it. To mitigate this, this patch
implements allocation and address space management locally by using
helpers provided by DRM framework, like other DRM drivers do, e.g.
Tegra.
Set geometry for allocated domains and fix .domain_alloc() callback to
work with IOMMU_DOMAIN_DMA domain type, which is used for implicit
domains on ARM64.
Signed-off-by: Shunqian Zheng
Signed-off-by: Tomasz Figa
---
drivers/iommu/rockchip-iommu.c | 16 +++-
1 file changed, 11 inser
Use DMA API instead of architecture internal functions like
__cpuc_flush_dcache_area() etc.
The biggest difficulty here is that dma_map and _sync calls require some
struct device, while there is no real 1:1 relation between an IOMMU
domain and some device. To overcome this, a simple platform devic
In .probe(), devm_kzalloc() is called with size == 0 and works only
by luck, due to internal behavior of the allocator and the fact
that the proper allocation size is small. Let's use proper value for
calculating the size.
Fixes: cd6438c5f844 ("iommu/rockchip: Reconstruct to support multi slaves")
From: Simon Xue
The iommu_dma_alloc() in iommu/dma-iommu.c calls iommu_map_sg()
that requires the callback iommu_ops .map_sg(). Adding the
default_iommu_map_sg() to Rockchip IOMMU accordingly.
Signed-off-by: Simon Xue
Signed-off-by: Shunqian Zheng
Reviewed-by: Douglas Anderson
Signed-off-by:
From: Simon Xue
Even though the IOMMU shares IRQ with its master, the struct device
passed to {request,free}_irq is supposed to represent the device that is
signalling the interrupt. This patch makes the driver use IOMMU device
instead of master's device to make things clear.
Signed-off-by: Simo
This series intends mostly to enable support for ARM64 architecture
in the rockchip-iommu driver. On the way to do so, some bugs are also
fixed.
The most important changes here are:
- making the Rockchip IOMMU driver use DMA API for managing cache
coherency of page tables,
- making the Rockch
A challenge in driver initialisation is the coordination of many small
sometimes independent, sometimes interdependent tasks. We would like to
schedule the independent tasks for execution in parallel across as many
cores as possible for rapid initialisation, and then schedule all the
dependent task
A frequent mode of operation is fanning out N tasks to execute in
parallel, collating results, fanning out M tasks, rinse and repeat. This
is also common to the notion of the async/sync kernel domain split.
A barrier provides a mechanism by which all work queued after the
barrier must wait (i.e. no
The current async-domain model supports running a multitude of
independent tasks with a coarse synchronisation point. This is
sufficient for its original purpose of allowing independent drivers to
run concurrently during various phases (booting, early resume, late
resume etc), and keep the asynchro
dma-buf implicitly track their (DMA) rendering using a
reservation_object, which tracks ether the last write (in an exclusive
fence) or the current renders (with a set of shared fences). To wait
upon a reservation object in conjunction with other sources,
kfence_add_reservation() extracts the DMA f
kfence_add_delay() is a convenience wrapper around
hrtimer_start_range_ns() to provide a time source for a kfence graph.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Shuah Khan
Cc: Tejun Heo
Cc: Daniel Vetter
Cc: Andrew Morton
Cc: Ingo Molnar
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: "Pau
dma-buf provides an interfaces for receiving notifications from DMA
hardware. kfence provides a useful interface for collecting such fences
and combining them with other events.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Shuah Khan
Cc: Tejun Heo
Cc: Daniel Vetter
Cc: Andrew Morton
Cc:
Provide a kfence_init() function for use for embedding the kfence into a
parent structure. kfence_init() takes an optional function pointer argument
should the caller wish to be notified when the kfence is complete. This is
useful for allowing the kfences to drive other state machinery.
Signed-off
Completions are a simple synchronization mechanism, suitable for 1:M
barriers where many waiters maybe waiting for a single event. In
situations where a single waiter needs to wait for multiple events they
could wait on a list of individual completions. If many waiters need the
same set of completi
On Fri, Jun 24, 2016 at 04:59:47PM +0900, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Consolidate the _DRM_VBLANK_NEXTONMISS handling between drm_wait_vblank
> and drm_queue_vblank_event.
>
> This is a cleanup spotted while working on other changes.
>
> (The way it was previously handled c
On Fri, Jun 24, 2016 at 6:15 AM, Frank Binns wrote:
> Signed-off-by: Frank Binns
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_irq.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 8ca3d2b..1494
Hi Rainer,
On 24 June 2016 at 05:54, Rainer Hochecker wrote:
> I spent some time reading and investigating on this. Bear with me, I am
> doing Kodi development in my spare time and may not be up-to-date on all
> platforms. Seems Wayland is much better suited to serve as reference
> platform as X1
Hi Linus,
This is the drm fixes tree for 4.7-rc5. It's a bit larger than normal,
due to fixes for production AMD Polaris GPUs. We only merged support for
these in 4.7-rc1 so it would be good if we got all the fixes into final.
The changes don't hit any other hardware.
Other than the amdgpu Polar
From: Kuninori Morimoto
hdmi-codec driver is common HDMI sound driver,
but it doesn't care about multi sound ports.
For example, hdmi-codec driver is supporting 1 I2S and 1 SPDIF ports,
so, we can't use this driver if HDMI has 2 or more I2S ports.
And we would like to use multi detection.
For e
From: Kuninori Morimoto
Current hdmi-codec driver is assuming that it will be registered
from HDMI driver. Because of this assumption, each callback function
has struct device pointer which is parent device (= HDMI).
Then, it can use dev_get_drvdata() to get private data.
OTOH, on some SoC/HDMI
Hi Mark, Thierry, Russell
These are DesignWare HDMI I2S support patches.
It will use ALSA SoC hdmi-codec driver, but we can't use it as-is.
So, 2), 3) patches modify hdmi-codec style.
Kuninori Morimoto (3):
1) drm: bridge: add DesignWare HDMI I2S audio support
2) ASoC: hdmi-codec: callback f
.
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160624/eef21cde/attachment-0001.sig>
86 matches
Mail list logo