Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement
from DDI into transcoder.
v9:
s/trans/cpu_transcoder
enum port and transcoders are declared at few headers.
Ramalingam C (6):
drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
drm: Move port definition back to i91
From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.
Hence required changes in HW programming is handled here.
As ME FW needs the transcoder detail on which HDCP is enabled
on Gen12+ platform, we are populating the detail in hdcp_port_data
I915 needs to send the index of the transcoder as per ME FW.
To support this, define enum mei_fw_ddi and add as a member into
the struct hdcp_port_data.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
include/drm/i915_mei_hdcp_interface.h | 13 +
1 file changed, 13 insertions(
I915 converts it's port value into ddi index defiend by ME FW
and pass it as a member of hdcp_port_data structure.
Hence expose the enum mei_fw_ddi to I915 through
i915_mei_interface.h.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 15 +++
On gen12+ platforms, HDCP HW is associated to the transcoder.
Hence on every modeset update associated transcoder into the
intel_hdcp of the port.
v2:
s/trans/cpu_transcoder [Jani]
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
.../drm/i915/display/intel_display_types.h| 7 +++
d
Hi Jacopo,
On Thu, Aug 22, 2019 at 03:01:46PM +0200, Jacopo Mondi wrote:
> On Tue, Aug 20, 2019 at 08:34:44PM +0300, Laurent Pinchart wrote:
> > On Sat, Jul 06, 2019 at 04:07:41PM +0200, Jacopo Mondi wrote:
> >> Add a driver for the R-Car Display Unit Color Correction Module.
> >>
> >> In most of
Hi Jacopo,
On Thu, Aug 22, 2019 at 12:00:51PM +0200, Jacopo Mondi wrote:
> On Wed, Aug 21, 2019 at 02:16:02PM +0200, Geert Uytterhoeven wrote:
> > On Sat, Jul 6, 2019 at 4:07 PM Jacopo Mondi
> > wrote:
> > > Update the 'vsps' property in the R-Car Gen3 SoC device tree files to
> > > match what's
We've added a set of new APIs to manipulate syncobjs holding timelines
of dma_fence. This adds a bit of documentation about how this works.
Signed-off-by: Lionel Landwerlin
Cc: Christian Koenig
Cc: Jason Ekstrand
Cc: David(ChunMing) Zhou
---
drivers/gpu/drm/drm_syncobj.c | 87
On 8/22/19 3:36 PM, Daniel Vetter wrote:
On Thu, Aug 22, 2019 at 3:30 PM Thomas Hellström (VMware)
wrote:
On 8/22/19 3:07 PM, Daniel Vetter wrote:
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submis
This patch introduce new enum which contains all VPU family (GXBB,
GXL, GXM and G12A).
This enum is used to detect the VPU compatible with the device.
We only need to set .data to the corresponding enum in the device
table, no need to check .compatible string anymore.
Signed-off-by: Julien Masson
On Thu 22 Aug 07:37 PDT 2019, Brian Masney wrote:
> From: Rob Clark
>
> Add support to restore the secure configuration for qcm_scm-32.c. This
> is needed by the On Chip MEMory (OCMEM) that is present on some
> Snapdragon devices.
>
> Signed-off-by: Rob Clark
> [masn...@onstation.org: ported t
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #39 from Nicholas Kazlauskas ---
Disabling the compositor doesn't make a difference as far as stuttering goes
for Hitman 2's DXVK - I don't see any commits in the log that are lock the
connector and all the planes.
I don't have Obli
Add device tree bindings for the On Chip Memory (OCMEM) that is present
on some Qualcomm Snapdragon SoCs.
Signed-off-by: Brian Masney
Reviewed-by: Rob Herring
---
Changes since v5:
- None
Changes since v4:
- remove qcom from path in $id
Changes since v3:
- add ranges property
- remove unnecess
The OCMEM driver handles allocation and configuration of the On Chip
MEMory that is present on some Snapdragon SoCs. Devices which have
OCMEM do not have GMEM inside the GPU core, so the GPU must instead
use OCMEM to be functional. Since the GPU is currently the only OCMEM
user with an upstream dri
The files a3xx_gpu.c and a4xx_gpu.c have ifdefs for the OCMEM support
that was missing upstream. Add two new functions (adreno_gpu_ocmem_init
and adreno_gpu_ocmem_cleanup) that removes some duplicated code.
Signed-off-by: Brian Masney
---
Changes since v5:
- None
Changes since v4:
- None
Change
Add ocmem driver that's needed for some a3xx and a4xx based systems.
Signed-off-by: Brian Masney
---
Changes since v5:
- None
This patch was introduced in v5.
arch/arm/configs/qcom_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/
From: Rob Clark
Add support to restore the secure configuration for qcm_scm-32.c. This
is needed by the On Chip MEMory (OCMEM) that is present on some
Snapdragon devices.
Signed-off-by: Rob Clark
[masn...@onstation.org: ported to latest kernel; set ctx_bank_num to
spare parameter.]
Signed-off-
Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
must use the On Chip MEMory (OCMEM) in order to be functional. Add the
optional ocmem property to the Adreno Graphics Management Unit bindings.
Signed-off-by: Brian Masney
---
Changes since v5:
- rename ocmem property to sram
From: Rob Clark
Add support for the OCMEM lock/unlock interface that is needed by the
On Chip MEMory (OCMEM) that is present on some Snapdragon devices.
Signed-off-by: Rob Clark
[masn...@onstation.org: ported to latest kernel; minor reformatting.]
Signed-off-by: Brian Masney
Reviewed-by: Bjorn
This patch series adds support for Qualcomm's On Chip MEMory (OCMEM)
that is needed in order to support some a3xx and a4xx-based GPUs
upstream. This is based on Rob Clark's patch series that he submitted
in October 2015 and I am resubmitting updated patches with his
permission. See the individual p
On Thu, 22 Aug 2019, Ramalingam C wrote:
> On gen12+ platforms, HDCP HW is associated to the transcoder.
> Hence on every modeset associated transcoder is updated into the
> intel_hdcp.
>
> Signed-off-by: Ramalingam C
> ---
> .../drm/i915/display/intel_display_types.h| 7 +++
> drivers/gpu/
On Wed, Aug 21, 2019 at 06:57:24PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> b/drivers/gpu/
On Wed, Aug 21, 2019 at 10:38:35PM +0200, Daniel Vetter wrote:
> Oops.
>
> Fixes: 9edbf1fa600a ("drm: Add API for capturing frame CRCs")
> Cc: Tomeu Vizoso
> Cc: Emil Velikov
> Cc: Benjamin Gaignard
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_debugfs_crc.c | 2 +-
> 1 file chan
On 8/22/19 4:24 PM, Thomas Hellström (VMware) wrote:
On 8/22/19 4:02 PM, Koenig, Christian wrote:
Am 22.08.19 um 15:06 schrieb Daniel Vetter:
On Thu, Aug 22, 2019 at 07:56:56AM +, Koenig, Christian wrote:
Am 22.08.19 um 08:49 schrieb Daniel Vetter:
With nouveau fixed all ttm-using drives
On Thu, Aug 22, 2019 at 4:24 PM Jason Gunthorpe wrote:
>
> On Thu, Aug 22, 2019 at 10:42:39AM +0200, Daniel Vetter wrote:
>
> > > RDMA has a mutex:
> > >
> > > ib_umem_notifier_invalidate_range_end
> > > rbt_ib_umem_for_each_in_range
> > >invalidate_range_start_trampoline
> > > ib_umem_n
On 8/22/19 4:02 PM, Koenig, Christian wrote:
Am 22.08.19 um 15:06 schrieb Daniel Vetter:
On Thu, Aug 22, 2019 at 07:56:56AM +, Koenig, Christian wrote:
Am 22.08.19 um 08:49 schrieb Daniel Vetter:
With nouveau fixed all ttm-using drives have the correct nesting of
mmap_sem vs dma_resv, and
On Thu, Aug 22, 2019 at 10:42:39AM +0200, Daniel Vetter wrote:
> > RDMA has a mutex:
> >
> > ib_umem_notifier_invalidate_range_end
> > rbt_ib_umem_for_each_in_range
> >invalidate_range_start_trampoline
> > ib_umem_notifier_end_account
> > mutex_lock(&umem_odp->umem_mutex);
> >
> >
On Thu, 22 Aug 2019, Ramalingam C wrote:
> From Gen12 onwards, HDCP HW block is implemented within transcoders.
> Till Gen11 HDCP HW block was part of DDI.
>
> Hence required changes in HW programming is handled here.
>
> As ME FW needs the transcoder detail on which HDCP is enabled
> on Gen12+ pl
Hi Neil,
On Thu 22 Aug 2019 at 16:14, Julien Masson wrote:
> On 22/08/2019 11:03, Julien Masson wrote:
>> This patch introduce new enum which contains all VPU family (GXBB,
>> GXL, GXM and G12A).
>> This enum is used to detect the VPU compatible with the device.
>>
>> We only need to set .data
Am 22.08.19 um 15:06 schrieb Daniel Vetter:
> On Thu, Aug 22, 2019 at 07:56:56AM +, Koenig, Christian wrote:
>> Am 22.08.19 um 08:49 schrieb Daniel Vetter:
>>> With nouveau fixed all ttm-using drives have the correct nesting of
>>> mmap_sem vs dma_resv, and we can just lock the buffer.
>>>
>>>
Add drm_dp_mst_dsc_caps_for_port and drm_dp_mst_dsc_enable,
two helper functions for MST DSC
The former, given a port, returns the raw DPCD DSC caps off
that port.
The latter, given a port, enables or disables DSC on that port.
In both cases, the port given as input should be a leaf of
the MST t
This field on drm_dp_mst_branch was never filled
Initialize it to zero when the list of ports is created.
When a port is added to the list, increment num_ports,
and when a port is removed from the list, decrement num_ports.
v2: remember to decrement on port removal
Signed-off-by: David Francis
As of DP1.4, ENUM_PATH_RESOURCES returns a bit indicating
if FEC can be supported up to that point in the MST network.
The bit is the first byte of the ENUM_PATH_RESOURCES ack reply,
bottom-most bit (refer to section 2.11.9.4 of DP standard,
v1.4)
That value is needed for FEC and DSC support
Sto
Instead of having drm_dp_dpcd_read/write and
drm_dp_mst_dpcd_read/write as entry points into the
aux code, have drm_dp_dpcd_read/write handle both.
This means that DRM drivers can make MST DPCD read/writes.
v2: Fix spacing
Cc: Leo Li
Cc: Lyude Paul
Signed-off-by: David Francis
---
drivers/gp
With DSC, bpp can be a multiple of 1/16, so
drm_dp_calc_pbn_mode is insufficient.
Add drm_dp_calc_pbn_mode_dsc, a function which is
the same as drm_dp_calc_pbn_mode, but the bpp is
in units of 1/16.
Reviewed-by: Lyude Paul
Signed-off-by: David Francis
---
drivers/gpu/drm/drm_dp_mst_topology.c
Add necessary support for MST DSC.
(Display Stream COmpression over Multi-Stream Transport)
v4: Split patchset and rebase onto drm-tip
David Francis (5):
drm/dp-mst: Add PBN calculation for DSC modes
drm/dp-mst: Parse FEC capability on MST ports
drm/dp-mst: Add MST support to DP DPCD R/W fu
Am 22.08.19 um 15:02 schrieb Daniel Vetter:
> On Thu, Aug 22, 2019 at 10:23:29AM +0200, Christian König wrote:
>> Am 21.08.19 um 18:04 schrieb Daniel Vetter:
>>> On Wed, Aug 21, 2019 at 02:31:44PM +0200, Christian König wrote:
[SNIP]
+ /* Try to drop the last reference */
+ if (!dm
I was building against amd-staging-drm-next (commit e4a67e6cf14c).
v4 will contain just the drm-mst patches and will apply on latest
drm-tip/drm-tip (commit 018886de4726)
From: Lyude Paul
Sent: August 21, 2019 5:20 PM
To: Francis, David; dri-devel@lists.
On Thu, Aug 22, 2019 at 3:30 PM Thomas Hellström (VMware)
wrote:
>
> On 8/22/19 3:07 PM, Daniel Vetter wrote:
> > Full audit of everyone:
> >
> > - i915, radeon, amdgpu should be clean per their maintainers.
> >
> > - vram helpers should be fine, they don't do command submission, so
> >really
On 8/22/19 3:07 PM, Daniel Vetter wrote:
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them al
Whoops, left in a test print. Ignore this patch
From: David Francis
Sent: August 21, 2019 4:01 PM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: Francis, David; Liu, Wenjing; Cornij, Nikola
Subject: [PATCH v3 13/16] drm/amd/display
Hi Guido,
I added my signed-off, plus some comments inline.
On Jo, 2019-08-22 at 12:44 +0200, Guido Günther wrote:
> This adds initial support for the NWL MIPI DSI Host controller found
> on
> i.MX8 SoCs.
>
> It adds support for the i.MX8MQ but the same IP can be found on
> e.g. the i.MX8QXP.
>
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #42 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Alex Deucher from comment #37)
> The TearFree option is there to deal with compositors that do not support
> sync to vblank.
Also for cases where a compositor cannot prevent
On Thu, Aug 22, 2019 at 11:06:45AM +0200, Gerd Hoffmann wrote:
> No need for a home-grown version, the generic helper should work just
> fine. It also handles vgacon removal these days, see commit
> 1c74ca7a1a9a ("drm/fb-helper: call vga_remove_vgacon automatically."),
> so that can be removed too
From: Colin Ian King
Variable baco_state is initialized to a value that is never read and it is
re-assigned later. The initialization is redundant and can be removed.
Addresses-Coverity: ("Unused Value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 2 +-
1 file
On Thu, Aug 22, 2019 at 11:06:44AM +0200, Gerd Hoffmann wrote:
> Not needed any more for remove_conflicting_pci_framebuffers calls.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
> ---
> include/drm/drm_fb_helper.h | 4 +---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |
On Thu, Aug 22, 2019 at 11:06:43AM +0200, Gerd Hoffmann wrote:
> Since commit b0e999c95581 ("fbdev: list all pci memory bars as
> conflicting apertures") the parameter was used for some sanity checks
> only, to make sure we detect any issues with the new approach to just
> list all memory bars as a
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them all.
- panfrost seems to dma_resv_lock only in
On Thu, Aug 22, 2019 at 07:56:56AM +, Koenig, Christian wrote:
> Am 22.08.19 um 08:49 schrieb Daniel Vetter:
> > With nouveau fixed all ttm-using drives have the correct nesting of
> > mmap_sem vs dma_resv, and we can just lock the buffer.
> >
> > Assuming I didn't screw up anything with my aud
On Thu, Aug 22, 2019 at 10:23:29AM +0200, Christian König wrote:
> Am 21.08.19 um 18:04 schrieb Daniel Vetter:
> > On Wed, Aug 21, 2019 at 02:31:44PM +0200, Christian König wrote:
> > > [SNIP]
> > > + /* Try to drop the last reference */
> > > + if (!dma_fence_array_recycle(staged))
> > Without an
Hi Laurent,
thanks for review
On Tue, Aug 20, 2019 at 08:34:44PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Sat, Jul 06, 2019 at 04:07:41PM +0200, Jacopo Mondi wrote:
> > Add a driver for the R-Car Display Unit Color Correction Module.
> >
> > In most of Gen
On Thu, Aug 22, 2019 at 1:55 AM Daniel Vetter wrote:
>
> Full audit of everyone:
>
> - i915, radeon, amdgpu should be clean per their maintainers.
>
> - vram helpers should be fine, they don't do command submission, so
> really no business holding struct_mutex while doing copy_*_user. But
> I
Acked-by: Alex Deucher
From: Hans Verkuil
Sent: Thursday, August 22, 2019 4:08 AM
To: Dariusz Marcinkiewicz ; dri-devel@lists.freedesktop.org
; linux-me...@vger.kernel.org
Cc: David Airlie ; nouv...@lists.freedesktop.org
; Dhinakaran Pandiyan
; Koo, Anthony ;
Outch, it reapared on the backmerge I did yesterday and I didn't noticed. Sorry
Chris has fixed this now.
Thank you both.
> On Aug 22, 2019, at 3:20 AM, Stephen Rothwell wrote:
>
> Hi all,
>
> I noticed that the drm tree has been back merge into the drm-intel
> tree. Unfortunately, it seems
On Thu, Aug 22, 2019 at 02:09:27PM +0300, Simon Ser wrote:
> This patch adds a line with the port name to connectors in
> debugfs/i915_debug_info. If the port is Type-C, the Type-C port number is
> printed too.
>
> Signed-off-by: Simon Ser
> Cc: Imre Deak
> Cc: Manasi Navare
Looks ok to me:
Re
On Wed, Aug 21, 2019 at 02:31:47PM +0200, Christian König wrote:
> Additional to readers and writers add another class of operations
> which never participate in implicit synchronization.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-resv.c | 27 ---
> in
On 20.08.2019 00:45, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Mon, Aug 19, 2019 at 10:38:35AM +0200, Andrzej Hajda wrote:
>> On 14.08.2019 14:40, Daniel Vetter wrote:
>>> On Wed, Aug 14, 2019 at 01:04:03PM +0300, Laurent Pinchart wrote:
On Wed, Aug 14, 2019 at 08:23:12AM +0200, Andrzej Haj
On Thu, 22 Aug 2019, Ramalingam C wrote:
> Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement
> from DDI into transcoder.
>
> v7:
> port, transcoder definitions are kept within I915.
> corresponding changes in i915-mei interface.
I had some superficial comments here and t
Handled the need for exposing enum port to mei_hdcp driver, by
converting the port into ddi index as per ME FW.
Hence enum port definition moved into I915 driver itself.
v2:
intel_display.h is included in intel_hdcp.h
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_bios.h
On 08/21/19 13:12, Gerd Hoffmann wrote:
> We must make sure our scatterlist segments are not too big, otherwise
> we might see swiotlb failures (happens with sev, also reproducable with
> swiotlb=force).
>
> Suggested-by: Laszlo Ersek
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virti
On 22/08/2019 12:34, Boris Brezillon wrote:
> On Thu, 22 Aug 2019 12:22:02 +0200
> Neil Armstrong wrote:
>
>> On 22/08/2019 12:09, Boris Brezillon wrote:
>>> On Thu, 22 Aug 2019 11:29:40 +0200
>>> Neil Armstrong wrote:
>>>
>>> +/**
>>> + * struct drm_bus_caps - bus capabilities
>>
I915 will convert it's port value into ddi index defiend by ME FW
and will pass it as part of hdcp_port_data structure.
Hence we are exposing the enum mei_fw_ddi to I915 through
i915_mei_interface.h.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 15 +-
driv
From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.
Hence required changes in HW programming is handled here.
As ME FW needs the transcoder detail on which HDCP is enabled
on Gen12+ platform, we are populating the detail in hdcp_port_data
On gen12+ platforms, HDCP HW is associated to the transcoder.
Hence on every modeset associated transcoder is updated into the
intel_hdcp.
Signed-off-by: Ramalingam C
---
.../drm/i915/display/intel_display_types.h| 7 +++
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++
drivers/gpu/dr
For gen12+ platform we need to pass the transcoder info
as part of the port info.
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 11 +++
drivers/misc/mei/hdcp/mei_hdcp.h | 4 +++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/me
I915 needs to send the index of the transcoder as per ME FW.
To support this, enum mei_fw_ddi is defined and added as a member into
the struct hdcp_port_data.
Signed-off-by: Ramalingam C
---
include/drm/i915_mei_hdcp_interface.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/
Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block movement
from DDI into transcoder.
v7:
port, transcoder definitions are kept within I915.
corresponding changes in i915-mei interface.
Ramalingam C (6):
drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
drm: port definitio
Handled the need for exposing enum port to mei_hdcp driver, by
converting the port into ddi index as per ME FW.
Hence enum port definition moved into I915 driver itself.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_bios.h| 2 ++
drivers/gpu/drm/i915/display/intel_disp
This patch adds a line with the port name to connectors in
debugfs/i915_debug_info. If the port is Type-C, the Type-C port number is
printed too.
Signed-off-by: Simon Ser
Cc: Imre Deak
Cc: Manasi Navare
---
Thanks for your comments, Imre and Manasi. Here is v2:
- Use same port formatting as i
Hi Laurent,
thanks for having a look!
On Wed, Aug 21, 2019 at 09:15:18PM +0300, Laurent Pinchart wrote:
> Hi Guido,
>
> Thank you for the patch.
>
> On Fri, Aug 09, 2019 at 06:24:22PM +0200, Guido Günther wrote:
> > The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
> >
> > S
This adds initial support for the NWL MIPI DSI Host controller found on
i.MX8 SoCs.
It adds support for the i.MX8MQ but the same IP can be found on
e.g. the i.MX8QXP.
It has been tested on the Librem 5 devkit using mxsfb.
Signed-off-by: Guido Günther
Co-developed-by: Robert Chiras
---
drivers
The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
Signed-off-by: Guido Günther
---
.../bindings/display/bridge/nwl-dsi.yaml | 155 ++
1 file changed, 155 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
dif
This adds initial support for the NWL MIPI DSI Host controller found on i.MX8
SoCs.
It adds support for the i.MX8MQ but the same IP core can also be found on e.g.
i.MX8QXP. I added the necessary hooks to support other imx8 variants but since
I only have imx8mq boards to test I omitted the platform
On Thu, 22 Aug 2019 12:22:02 +0200
Neil Armstrong wrote:
> On 22/08/2019 12:09, Boris Brezillon wrote:
> > On Thu, 22 Aug 2019 11:29:40 +0200
> > Neil Armstrong wrote:
> >
> > +/**
> > + * struct drm_bus_caps - bus capabilities
> > + * @supported_fmts: array of MEDIA_BUS_FMT_ form
On Mon, Aug 19, 2019 at 08:01:57AM +, james qian wang (Arm Technology
China) wrote:
> The patch 5d51f6c0da1b: "drm/komeda: Add writeback support" from May
> 23, 2019, leads to the following static checker warning:
>
> drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c:151
> kom
On Mon, Aug 12, 2019 at 11:23:41AM +, james qian wang (Arm Technology
China) wrote:
> Fixed two -Wunused-but-set-variable warnings:
>
> /arm/linux/display/aosp-4.14-drm-next/drivers/gpu/drm/arm/display/komeda/komeda_kms.c:
> In function ‘komeda_crtc_normalize_zpos’:
> /arm/linux/display/aosp
On Tue, Aug 13, 2019 at 11:08:20AM +, james qian wang (Arm Technology
China) wrote:
> komeda/komeda_pipeline.c: In function 'komeda_component_add':
> komeda/komeda_pipeline.c:212:3: warning: function 'komeda_component_add'
> might be a candidate for 'gnu_printf' format attribute
> [-Wsuggest
Also update the comment with a reference to the virglrenderer fix.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_object.c | 44 ++---
1 file changed, 24 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
b/drivers/gpu/drm/v
drm-misc-fixes-2019-08-22:
Fixes for v5.3-rc6:
- dma fix for omap.
- Make output polling work on komeda.
- Fix bpp computing for AFBC formats in komeda.
- Support the memory-region property in komeda.
The following changes since commit d45331b00ddb179e291766617259261c112db872:
Linux 5.3-rc4 (201
On 22/08/2019 12:09, Boris Brezillon wrote:
> On Thu, 22 Aug 2019 11:29:40 +0200
> Neil Armstrong wrote:
>
> +/**
> + * struct drm_bus_caps - bus capabilities
> + * @supported_fmts: array of MEDIA_BUS_FMT_ formats
> + * @num_supported_fmts: size of the supported_fmts array
> +
Hi all,
I noticed that the drm tree has been back merge into the drm-intel
tree. Unfortunately, it seems that the file
drivers/gpu/drm/i915/i915_gem_batch_pool.c has been resurrected.
It was removed in commit
b40d73784ffc ("drm/i915: Replace struct_mutex for batch pool serialisation")
but ha
On Thu, 22 Aug 2019 11:29:40 +0200
Neil Armstrong wrote:
> >>> +/**
> >>> + * struct drm_bus_caps - bus capabilities
> >>> + * @supported_fmts: array of MEDIA_BUS_FMT_ formats
> >>> + * @num_supported_fmts: size of the supported_fmts array
> >>> + *
> >>> + * Used by the core to negotiate the bus
On Wed, 2019-08-21 at 19:42 +0200, Guido Günther wrote:
> Hi,
> On Tue, Aug 13, 2019 at 01:07:52PM +0200, Arnd Bergmann wrote:
> > On Tue, Aug 13, 2019 at 12:10 PM Guido Günther wrote:
> > > On Tue, Aug 13, 2019 at 10:08:44AM +0200, Arnd Bergmann wrote:
> > > > On Fri, Aug 9, 2019 at 6:24 PM Guido
On Thu, Aug 22, 2019 at 11:14 AM Christian König
wrote:
>
> Am 21.08.19 um 22:22 schrieb Daniel Vetter:
> > On Wed, Aug 21, 2019 at 10:11 PM Chris Wilson
> > wrote:
> >> Quoting Christian König (2019-08-21 13:31:37)
> >>> Hi everyone,
> >>>
> >>> In previous discussion it surfaced that different
Hi Geert,
On Wed, Aug 21, 2019 at 02:16:02PM +0200, Geert Uytterhoeven wrote:
> On Sat, Jul 6, 2019 at 4:07 PM Jacopo Mondi wrote:
> > Update the 'vsps' property in the R-Car Gen3 SoC device tree files to
> > match what's in in the documentation example.
>
> double in (no worries, I'll fix that u
On 8/22/19 10:47 AM, Daniel Vetter wrote:
On Thu, Aug 22, 2019 at 9:56 AM Koenig, Christian
wrote:
Am 22.08.19 um 08:49 schrieb Daniel Vetter:
With nouveau fixed all ttm-using drives have the correct nesting of
mmap_sem vs dma_resv, and we can just lock the buffer.
Assuming I didn't screw up
Use drm_atomic_helper_check_plane_state()
to sanity check the plane state.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virti
The Vulkan timeline semaphores allow signaling to happen on the point
of the timeline without all of the its dependencies to be created.
The current 2 implementations (AMD/Intel) of the Vulkan spec on top of
the Linux kernel are using a thread to wait on the dependencies of a
given point to materi
Reported-by: Yann Droneaud
Signed-off-by: Gerd Hoffmann
---
drivers/dma-buf/udmabuf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 9635897458a0..6c3ec8fcef01 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.
Signed-off-by: Gerd Hoffmann
Reported-by: Yann Droneaud
---
drivers/dma-buf/udmabuf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 6c3ec8fcef01..ca1364102b18 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf
Signed-off-by: Gerd Hoffmann
---
include/uapi/linux/udmabuf.h | 52 ++--
Documentation/driver-api/dma-buf.rst | 8 +
2 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h
index 46b6532ed855.
Just noticed a bunch of udmabuf tweaks (add documentation & sanity checks)
are still lingering in a local branch. Resending.
Gerd Hoffmann (3):
udmabuf: add documentation
udmabuf: check that __pad is zero
udmabuf: check that flags has no unsupported bits set
include/uapi/linux/udmabuf.h
When modifying panfrost_devfreq_target() to support a device without a
regulator defined I missed the check on the error path. Let's add it.
Reported-by: Dan Carpenter
Fixes: e21dd290881b ("drm/panfrost: Enable devfreq to work without regulator")
Signed-off-by: Steven Price
---
drivers/gpu/drm/
On 22/08/2019 09:48, Boris Brezillon wrote:
> On Thu, 22 Aug 2019 03:55:56 +0300
> Laurent Pinchart wrote:
>
>> Hi Boris,
>>
>> Thank you for the patch.
>>
>> On Thu, Aug 08, 2019 at 05:11:45PM +0200, Boris Brezillon wrote:
>>> This takes the form of various helpers, plus the addition of 2 new
>>
Am 21.08.19 um 22:05 schrieb Daniel Vetter:
On Wed, Aug 21, 2019 at 06:13:27PM +0200, Daniel Vetter wrote:
On Wed, Aug 21, 2019 at 02:31:37PM +0200, Christian König wrote:
Hi everyone,
In previous discussion it surfaced that different drivers use the shared
and explicit fences in the dma_resv
Am 22.08.19 um 10:37 schrieb Christian König:
Am 21.08.19 um 19:35 schrieb Chris Wilson:
Quoting Chris Wilson (2019-08-21 16:24:22)
Quoting Christian König (2019-08-21 13:31:45)
@@ -117,17 +120,10 @@ i915_gem_busy_ioctl(struct drm_device *dev,
void *data,
busy_check_writer(rcu_dereference(obj
Hello Steven Price,
This is a semi-automatic email about new static checker warnings.
The patch e21dd290881b: "drm/panfrost: Enable devfreq to work without
regulator" from Aug 16, 2019, leads to the following Smatch complaint:
drivers/gpu/drm/panfrost/panfrost_devfreq.c:56 panfrost_devfreq_
On Tue, 20 Aug 2019 04:16:34 +0300
Laurent Pinchart wrote:
> The drm_display_info structure contains many fields related to HDMI
> sinks, but none that identifies if a sink compliant with CEA-861 (EDID)
> shall be treated as an HDMI sink or a DVI sink. Add such a flag, and
> populate it according
Am 21.08.19 um 22:22 schrieb Daniel Vetter:
On Wed, Aug 21, 2019 at 10:11 PM Chris Wilson wrote:
Quoting Christian König (2019-08-21 13:31:37)
Hi everyone,
In previous discussion it surfaced that different drivers use the shared and
explicit fences in the dma_resv object with different meani
On Tue, 20 Aug 2019 04:16:33 +0300
Laurent Pinchart wrote:
> drm_connector.c contains a map of connector types (DRM_MODE_CONNECTOR_*)
> to name strings, but doesn't expose it. This leads to drivers having to
> store a similar map.
>
> Add a new drm_get_connector_type_name() helper function that
101 - 200 of 250 matches
Mail list logo