Am 16.12.20 um 06:41 schrieb Chen Li:
When using e8860(gcn1) on arm64, the kernel crashed on drm/radeon:
[ 11.240414] pc : __memset+0x4c/0x188
[ 11.244101] lr : radeon_uvd_get_create_msg+0x114/0x1d0 [radeon]
[ 11.249995] sp : 0d7eb700
[ 11.253295] x29: 0d7eb700 x28:
On Wed, Dec 16, 2020 at 09:06:50AM +0800, Philip Li wrote:
> On Mon, Dec 14, 2020 at 09:49:17PM +0300, Dan Carpenter wrote:
> > On Sat, Dec 12, 2020 at 04:54:45PM +0800, Philip Li wrote:
> > > On Fri, Dec 11, 2020 at 04:42:00PM +0200, Ville Syrjälä wrote:
> > > > On Fri, Dec 11, 2020 at 01:24:49PM
The DP-HDMI2.1 PCON spec provides way for a source to set PPS
parameters: slice height, slice width and bits_per_pixel, based on
the HDMI2.1 sink capabilities. The DSC encoder of the PCON will
respect these parameters, while preparing the 128 byte PPS.
This patch adds helper functions to
When a source supporting DSC1.1 is connected to DSC1.2 HDMI2.1 sink
via DP HDMI2.1 PCON, the PCON can be configured to decode the
DSC1.1 compressed stream and encode to DSC1.2. It then sends the
DSC1.2 compressed stream to the HDMI2.1 sink.
This patch configures the PCON for DSC1.1 to DSC1.2
If PCON has capability to convert RGB->YUV colorspace and also
to 444->420 downsampling then for any YUV420 only mode, we can
let the PCON do all the conversion.
v2: As suggested by Uma Shankar, considered case for colorspace
BT709 and BT2020, and default to BT609. Also appended dir
'display' in
This patch adds support to read and store the DSC capabilities of the
HDMI2.1 PCon encoder. It also adds a new field to store these caps,
The caps are read during dfp update and can later be used to get the
PPS parameters for PCON-HDMI2.1 sink pair. Which inturn will be used
to take a call to
From: Swati Sharma
In this patch enables support for detecting link failures between
PCON and HDMI sink in i915 driver. HDMI link loss indication to
upstream DP source is indicated via IRQ_HPD. This is followed by
reading of HDMI link configuration status (HDMI_TX_LINK_ACTIVE_STATUS).
If the
This patch calls functions to check FRL training requirements
for an HDMI2.1 sink, when connected through PCON.
The call is made before the DP link training. In case FRL is not
required or failure during FRL training, the TMDS mode is selected
for the pcon.
v2: moved check_frl_training() just
HDMI2.1 PCON advertises Max FRL bandwidth supported by the PCON.
This patch captures this in dfp cap structure in intel_dp and uses
this to prune connector modes that cannot be supported by the PCON
and FRL bandwidth.
v2: Addressed review comments from Uma Shankar:
-tweaked the comparison of
This patch adds functions to start FRL training for an HDMI2.1 sink,
connected via a PCON as a DP branch device.
This patch also adds a new structure for storing frl training related
data, when FRL training is completed.
v2: As suggested by Uma Shankar:
-renamed couple of variables for better
This patch adds registers for getting DSC encoder capability for
a HDMI2.1 PCon. It also addes helper functions to configure
DSC between the PCON and HDMI2.1 sink.
v2: Corrected offset for DSC encoder bpc and minor changes.
Also added helper functions for getting pcon dsc encoder capabilities
as
DP Specification for DP2.0 to HDMI2.1 Pcon specifies support for conversion
of colorspace from RGB to YCbCr.
https://groups.vesa.org/wg/DP/document/previewpdf/15651
This patch adds the relavant registers and helper functions to
get the capability and set the color conversion bits for rgb->ycbcr
From: Swati Sharma
There are specific DPCDs defined for detecting link failures between
the PCON and HDMI sink and check the link status. In case of link
failure, PCON will communicate the same using an IRQ_HPD to source.
HDMI sink would have indicated the same to PCON using SCDC interrupt
This patch adds support for configuring a PCON device,
connected as a DP branched device to enable FRL Link training
with a HDMI2.1 + sink.
v2: Fixed typos and addressed other review comments from Uma Shankar.
-changed the commit message for better clarity (Uma Shankar)
-removed unnecessary
This patch parses HFVSDB fields for DSC1.2 capabilities of an
HDMI2.1 sink. These fields are required by a source to understand the
DSC capability of the sink, to set appropriate PPS parameters,
before transmitting compressed data stream.
v2: Addressed following issues as suggested by Uma
From: Swati Sharma
This patch parses MAX_FRL field to get the MAX rate in Gbps that
the HDMI 2.1 panel can support in FRL mode. Source need this
field to determine the optimal rate between the source and sink
during FRL training.
v2: Fixed minor bugs, and removed extra wrapper function (Uma
From: Swati Sharma
The HDMI2.1 extends HFVSDB (HDMI Forum Vendor Specific
Data block) to have fields related to newly defined methods of FRL
(Fixed Rate Link) levels, number of lanes supported, DSC Color bit
depth, VRR min/max, FVA (Fast Vactive), ALLM etc.
This patch adds the new HFVSDB fields
This patch series attempts to add support for a DP-HDMI2.1 Protocol
Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata
E5 to DisplayPort_v2.0:
https://vesa.org/join-vesamemberships/member-downloads/?action=stamp=42299
The details are mentioned in:
VESA DP-to-HDMI PCON
On Wed, Mar 13, 2019 at 02:00:28AM +0200, Laurent Pinchart wrote:
> On Thu, Feb 21, 2019 at 12:39:24PM +0200, Laurent Pinchart wrote:
> > Forgot to CC Rob, sorry about that.
>
> Rob, could you take this in your tree ?
Gentle ping.
> > On Thu, Feb 21, 2019 at 12:32:08PM +0200, Laurent Pinchart
The legacy DRM drivers uAPI headers are licensed under the MIT license,
and carry copies of the license with slight variations. Replace them
with SPDX headers.
Signed-off-by: Laurent Pinchart
---
include/uapi/drm/mga_drm.h| 20 +---
include/uapi/drm/savage_drm.h | 20
The Nouveau DRM driver uAPI header is licensed under the MIT license,
and carries a copy of the license with slight variations. Replace it
with an SPDX header.
Signed-off-by: Laurent Pinchart
---
include/uapi/drm/nouveau_drm.h | 20 +---
1 file changed, 1 insertion(+), 19
Several DRM drivers uAPI headers that are licensed under the GPL carry
both an SPDX header and a copy of the license text. Drop the latter.
Signed-off-by: Laurent Pinchart
Reviewed-by: Daniel Vetter
---
include/uapi/drm/armada_drm.h | 4
include/uapi/drm/etnaviv_drm.h | 12
The DRM drivers uAPI headers are licensed under the MIT license, and
carry copies of the license with slight variations. Replace them with
SPDX headers for headers copyrighted by Red Hat.
Signed-off-by: Laurent Pinchart
---
include/uapi/drm/msm_drm.h | 20 +---
The VMware DRM driver uAPI header is licensed under the MIT license, and
carries a copy of the license with slight variations. Replace it with an
SPDX header.
Signed-off-by: Laurent Pinchart
Reviewed-by: Roland Scheidegger
---
include/uapi/drm/vmwgfx_drm.h | 21 +
1 file
The Broadcom DRM drivers uAPI headers are licensed under the MIT
license, and carry copies of the license with slight variations. Replace
them with SPDX headers.
Signed-off-by: Laurent Pinchart
---
include/uapi/drm/v3d_drm.h | 20 +---
include/uapi/drm/vc4_drm.h | 20
The Nvidia Tegra DRM driver uAPI header is licensed under the MIT
license, and carries a copy of the license with slight variations.
Replace it with an SPDX header.
Signed-off-by: Laurent Pinchart
---
include/uapi/drm/tegra_drm.h | 19 +--
1 file changed, 1 insertion(+), 18
The Intel DRM drivers uAPI headers are licensed under the MIT license,
and carry copies of the license with slight variations. Replace them
with SPDX headers.
Signed-off-by: Laurent Pinchart
---
include/uapi/drm/i915_drm.h | 22 +-
include/uapi/drm/vgem_drm.h | 22
The AMD DRM drivers uAPI headers are licensed under the MIT license,
and carry copies of the license with slight variations. Replace them
with SPDX headers.
Signed-off-by: Laurent Pinchart
---
include/uapi/drm/amdgpu_drm.h | 19 +--
include/uapi/drm/r128_drm.h | 20
The DRM core uAPI headers are licensed under the MIT license, and carry
copies of the license with slight variations. Replace them with SPDX
headers.
Following a discussion with Daniel Vetter on this topic, add a
clarification in the drm-uapi.rst file that independent closed-source
userspace
Hi Christian,
On Fri, Jul 17, 2020 at 04:05:42PM +0200, Christian König wrote:
> Am 17.07.20 um 04:27 schrieb Laurent Pinchart:
> > On Mon, Jun 22, 2020 at 11:29:33AM +0200, Daniel Vetter wrote:
> >> On Mon, Jun 22, 2020 at 09:58:44AM +0200, Christian König wrote:
> >>> Am 21.06.20 um 04:07
Hi Daniel,
Thank you for the patch.
On Fri, Oct 23, 2020 at 02:21:25PM +0200, Daniel Vetter wrote:
> Ends right after drm_atomic_helper_commit_hw_done(), absolutely
> nothing fancy going on here.
>
> Signed-off-by: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc:
The device references acquired by of_find_device_by_node() are not
released by the driver. Fix this by registering a cleanup action.
Fixes: 8de707aeb452 ("drm: rcar-du: kms: Initialize CMM instances")
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 20
On Mon, Dec 14, 2020 at 09:49:17PM +0300, Dan Carpenter wrote:
> On Sat, Dec 12, 2020 at 04:54:45PM +0800, Philip Li wrote:
> > On Fri, Dec 11, 2020 at 04:42:00PM +0200, Ville Syrjälä wrote:
> > > On Fri, Dec 11, 2020 at 01:24:49PM +0200, Tomi Valkeinen wrote:
> > > > On 10/12/2020 20:06, kernel
On Wed, Dec 16, 2020 at 03:00:43AM +0200, Laurent Pinchart wrote:
> Hi Wang,
>
> Thank you for the patch.
>
> On Wed, Nov 11, 2020 at 11:14:52AM +0800, Wang Xiaojun wrote:
> > of_parse_phandle and of_find_device_by_node may return NULL
> > which cannot be checked by IS_ERR.
> >
> >
Hi Wang,
Thank you for the patch.
On Wed, Nov 11, 2020 at 11:14:52AM +0800, Wang Xiaojun wrote:
> of_parse_phandle and of_find_device_by_node may return NULL
> which cannot be checked by IS_ERR.
>
> Signed-off-by: Wang Xiaojun
> Reported-by: Hulk Robot
Reviewed-by: Laurent Pinchart
and
Use the drm_bridge_connector_init() helper to create a drm_connector for
each output, instead of relying on the bridge drivers doing so. Attach
the bridges with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag to instruct
them not to create a connector.
Signed-off-by: Laurent Pinchart
---
Report the DT output port number in dw_hdmi_plat_data to connect to the
next bridge in the dw-hdmi driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
Replace the manual panel handling with usage of the DRM panel bridge
helper. This simplifies the driver, and brings support for
DRM_BRIDGE_ATTACH_NO_CONNECTOR as an added bonus.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 120 +++-
1 file
On all platforms except i.MX and Rockchip, the dw-hdmi DT bindings
require a video output port connected to an HDMI sink (most likely an
HDMI connector, in rare cases another bridges converting HDMI to another
protocol). For those platforms, retrieve the next bridge and attach it
from the dw-hdmi
Hello,
This patch series converts the R-Car DU driver to use the DRM bridge
connector helper drm_bridge_connector_init().
The bulk of the v1 series was converting the adv7511, simple-bridge and
dw-hdmi drivers to make connector creation optional (through the
DRM_BRIDGE_ATTACH_NO_CONNECTOR flag),
We need to include in order for MIPS to find
vmap(), as it doesn't otherwise get included there.
Without this patch, one can hit the following build error:
drivers/dma-buf/heaps/cma_heap.c: In function 'cma_heap_do_vmap':
drivers/dma-buf/heaps/cma_heap.c:195:10: error: implicit declaration
On Tue, Dec 15, 2020 at 3:53 PM Guenter Roeck wrote:
>
> On Sat, Nov 21, 2020 at 11:49:59PM +, John Stultz wrote:
> > Since the heap-helpers logic ended up not being as generic as
> > hoped, move the heap-helpers dma_buf_ops implementations into
> > the cma_heap directly.
> >
> > This will
Convert the Renesas R-Car DU text binding to YAML.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Use pattern instead of enum for dclkin
- Update MAINTAINERS
---
.../bindings/display/renesas,du.txt | 145 ---
.../bindings/display/renesas,du.yaml | 854
From: Fabrizio Castro
Document RZ/G2E support for property renesas,companion.
Signed-off-by: Fabrizio Castro
Reviewed-by: Laurent Pinchart
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Slight reword of SoC list in description
---
Every heap needs to create a dmabuf and then export it to a fd
via dma_buf_fd(), so to consolidate things a bit, have the heaps
just return a struct dmabuf * and let the top level
dma_heap_buffer_alloc() call handle creating the fd via
dma_buf_fd().
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura
We shouldn't vunmap more then we vmap, but if we do, make
sure we complain loudly.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc:
If we abort from the allocation due to a fatal_signal_pending(),
be sure we report an error so any return code paths don't trip
over the fact that the allocation didn't succeed.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc:
This is the sixteenth version of the patch set. Changelog:
v16:
* Add "select DMA_SHARED_BUFFER" to Kconfig when IB UMEM is enabled.
This fixes the auto build test error with a random config.
v15: https://www.spinics.net/lists/linux-rdma/msg98369.html
* Rebase to the latest linux-rdma
Implement a new uverbs ioctl method for memory registration with file
descriptor as an extra parameter.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel Vetter
Reviewed-by: Leon Romanovsky
---
Implement the new driver method 'reg_user_mr_dmabuf'. Utilize the core
functions to import dma-buf based memory region and update the mappings.
Add code to handle dma-buf related page fault.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian
Dma-buf based memory region requires one extra parameter and is processed
quite differently. Adding a separate method allows clean separation from
regular memory regions.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel
Dma-buf is a standard cross-driver buffer sharing mechanism that can be
used to support peer-to-peer access from RDMA devices.
Device memory exported via dma-buf is associated with a file descriptor.
This is passed to the user space as a property associated with the
buffer allocation. When the
Hi Mark,
Thank you for the patch.
On Fri, Nov 08, 2019 at 05:32:08PM +, Mark Brown wrote:
> The thc63lvd1024 driver requests a supply using regulator_get_optional()
> but both the name of the supply and the usage pattern suggest that it is
> being used for the main power for the device and
Now that the legacy PCI support code doesn't need to write to the
drm_driver structure, it can be treated as const through the whole DRM
core, unconditionally. This allows declaring the structure as const in
all drivers, removing one possible attack vector.
Signed-off-by: Laurent Pinchart
---
A non-const structure containing function pointers is a possible attack
vector. The drm_driver structure is already const in most drivers, but
there are a few exceptions. Constify the structure in the drivers that
don't need to modify at, as a low-hanging fruit. The rest of the drivers
will need a
Hello,
This patch series finishes the constification of struct drm_driver in
the DRM core by avoiding modifications to the structure for legacy PCI
drivers. This improves security by avoiding function pointers in
writable memory.
The change turned out to be fairly easy, with preparation in patch
The drm_driver structure contains a single field (legacy_dev_list) that
is modified by the DRM core, used to store a linked list of legacy DRM
devices associated with the driver. In order to make the structure
const, move the field out to a global variable. This requires locking
access to the
On 11/24/20 11:44 AM, Christian König wrote:
Am 24.11.20 um 17:22 schrieb Andrey Grodzovsky:
On 11/24/20 2:41 AM, Christian König wrote:
Am 23.11.20 um 22:08 schrieb Andrey Grodzovsky:
On 11/23/20 3:41 PM, Christian König wrote:
Am 23.11.20 um 21:38 schrieb Andrey Grodzovsky:
On
The drm_gem_dumb_destroy() isn't used in drivers, don't export it.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Move function prototype from drm_gem.h to drm_internal.h
- Drop function documentation
- Replace uint32_t with u32
---
drivers/gpu/drm/drm_dumb_buffers.c | 8 +---
Use the drm_plane_cleanup() function directly as the drm_plane_funcs
.destroy() handler without creating an unnecessary wrapper around it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/sti/sti_cursor.c | 9 +
drivers/gpu/drm/sti/sti_gdp.c| 9 +
Use the drm_plane_cleanup() function directly as the drm_plane_funcs
.destroy() handler without creating an unnecessary wrapper around it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/vc4/vc4_plane.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git
Use the drm_plane_cleanup() function directly as the drm_plane_funcs
.destroy() handler without creating an unnecessary wrapper around it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/zte/zx_plane.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git
Use the drm_plane_cleanup() function directly as the drm_plane_funcs
.destroy() handler without creating an unnecessary wrapper around it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git
[AMD Public Use]
this branch should be ignored by test robots. It's just a public mirror of our
packaged driver source code. It contains kernel compatibility and dkms support
which is not going upstream.
Alex
From: Mauro Rossi
Sent: Tuesday, December 15,
On 14/12/2020 15:46, Zheng Yongjun wrote:
The parameter of kfree function is NULL, so kfree code is useless, delete it.
Signed-off-by: Zheng Yongjun
---
drivers/gpu/drm/omapdrm/tcm-sita.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/tcm-sita.c
Hello,
the mentioned branch requires the following commit, but it is already
applied in 5.10 released kernel,
so I really do not know what next step here.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8c4e4fd607b17973e54a7e9cc4c275b12ab7308e
Mauro
On Tue, Dec 15,
On 12/15/20 10:13 AM, Chris Wilson wrote:
> Quoting t...@redhat.com (2020-12-15 14:41:01)
>> From: Tom Rix
>>
>> See Documentation/core-api/printk-formats.rst.
>> h should no longer be used in the format specifier for printk.
> It's understood by format_decode().
> * 'h', 'l', or 'L' for
Hi Qinglang,
Thank you for the patch.
On Fri, Nov 27, 2020 at 05:44:44PM +0800, Qinglang Miao wrote:
> pm_runtime_get_sync will increment pm usage counter even it
> failed. Forgetting to putting operation will result in a
> reference leak here.
>
> A new function pm_runtime_resume_and_get is
Quoting t...@redhat.com (2020-12-15 14:41:01)
> From: Tom Rix
>
> See Documentation/core-api/printk-formats.rst.
> h should no longer be used in the format specifier for printk.
It's understood by format_decode().
* 'h', 'l', or 'L' for integer fields
At least reference commit cbacb5ab0aa0
Hi Maxime
On Tue, 15 Dec 2020 at 15:43, Maxime Ripard wrote:
>
> The BCM2711 supports higher bpc count than just 8, so let's support it in
> our driver.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 70
On 11/12/2020 13:42, Tomi Valkeinen wrote:
+/**
+ * drm_crtc_supports_legacy_gamma - does the crtc support legacy gamma
correction table
+ * @crtc: CRTC object
+ *
+ * Returns true/false if the given crtc supports setting the legacy gamma
+ * correction table.
+ */
+static bool
My employment with TI is coming to an end and I will not have access to
the board where this bridge is connected to.
It is better to remove a soon bouncing email address.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/display/bridge/toshiba,tc358768.yaml | 3 ---
1 file changed, 3
On Tue, Dec 15, 2020 at 02:04:31PM +0100, Thomas Zimmermann wrote:
> Hi Dave and Daniel,
>
> here's this week's PR for drm-misc-next-fixes. IIRC the radeon fix is
> already in drm-misc-next.
Pulled, and also your previous -next pull which got stuck somewhere.
Thanks, Daniel
>
> Best regards
>
Hi Maxime
On Tue, 15 Dec 2020 at 15:42, Maxime Ripard wrote:
>
> When run with a higher bpc than 8, the clock of the HDMI controller needs
> to be adjusted. Let's create a connector state that will be used at
> atomic_check and atomic_enable to compute and store the clock rate
> associated to
On Sat, 12 Dec 2020 12:11:43 +0800, Yongqiang Niu wrote:
> add description for mt8192 display
>
> Signed-off-by: Yongqiang Niu
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Acked-by: Rob Herring
On Sat, Dec 12, 2020 at 12:11:41PM +0800, Yongqiang Niu wrote:
> add description for postmask
>
> Signed-off-by: Yongqiang Niu
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
>
On Tue, Dec 15, 2020 at 03:43:00PM +, Souza, Jose wrote:
> On Tue, 2020-12-15 at 16:44 +0200, Ville Syrjälä wrote:
> > On Mon, Dec 14, 2020 at 09:49:08AM -0800, José Roberto de Souza wrote:
> > > Much more clear to read one function call than four lines doing this
> > > conversion.
> > >
> >
On Tue, 2020-12-15 at 16:44 +0200, Ville Syrjälä wrote:
> On Mon, Dec 14, 2020 at 09:49:08AM -0800, José Roberto de Souza wrote:
> > Much more clear to read one function call than four lines doing this
> > conversion.
> >
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Gwan-gyeong Mun
> >
Hi Laurent,
On Mon, Dec 14, 2020 at 5:28 PM Laurent Pinchart
wrote:
> On Mon, Dec 14, 2020 at 04:20:17PM +, Kieran Bingham wrote:
> > On 04/12/2020 22:01, Laurent Pinchart wrote:
> > > devm_kcalloc() is the wrong API to allocate planes, as the lifetime of
> > > the planes is tied to the DRM
On Tue, Dec 15, 2020 at 10:11 AM Christian König
wrote:
>
> Am 15.12.20 um 16:06 schrieb Tom Rix:
> > On 12/15/20 6:47 AM, Christian König wrote:
> >> Am 15.12.20 um 15:38 schrieb t...@redhat.com:
> >>> From: Tom Rix
> >>>
> >>> See Documentation/core-api/printk-formats.rst.
> >>> h should no
On Mon, Dec 14, 2020 at 7:24 PM Jiaying Liang wrote:
>
>
> On 12/11/20 11:39 AM, Daniel Vetter wrote:
> > Hi all
> >
> > On Fri, Dec 11, 2020 at 8:03 PM Alex Deucher wrote:
> >> On Mon, Nov 30, 2020 at 3:25 AM Wendy Liang wrote:
> >>> AI engine is the acceleration engine provided by Xilinx.
Am 15.12.20 um 16:06 schrieb Tom Rix:
On 12/15/20 6:47 AM, Christian König wrote:
Am 15.12.20 um 15:38 schrieb t...@redhat.com:
From: Tom Rix
See Documentation/core-api/printk-formats.rst.
h should no longer be used in the format specifier for printk.
In general looks valid to me, but my
On 12/15/20 6:47 AM, Christian König wrote:
> Am 15.12.20 um 15:38 schrieb t...@redhat.com:
>> From: Tom Rix
>>
>> See Documentation/core-api/printk-formats.rst.
>> h should no longer be used in the format specifier for printk.
>
> In general looks valid to me, but my question is how does that
On Tue, Dec 15, 2020 at 5:56 AM Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake in a comment in the Kconfig. Fix it.
>
> Signed-off-by: Colin Ian King
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1
We have a useless 'if' in the dsicm_bl_update_status(), a left over from
the conversion to DRM model. Drop the if.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/panel/panel-dsi-cm.c | 8 +++-
1
As we now have a fixed setup for VCs (VC0 for video stream, VC1 for
commands), we can simplify the VC setup.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 85 +++
1 file changed, 31 insertions(+), 54
The functions in display.c are not used, so drop the file.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/Makefile | 2 +-
drivers/gpu/drm/omapdrm/dss/display.c | 58 ---
We only need to set VC_CTRL:DCS_CMD_ENABLE for command mode panels when
the HW has DSI_QUIRK_DCS_CMD_CONFIG_VC quirk. The old code did this
right by accident, but now we set DCS_CMD_ENABLE for video mode panels
too.
Fix this by skipping the set for video mode.
Signed-off-by: Tomi Valkeinen
If the PLL calc function is given bad parameters, n_start/m_start may be
higher than n_stop/m_stop, which leads to the loops iterating through
the whole u32 number space.
Fix this by failing early on such cases.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
Reviewed-by: Sebastian
From: Sebastian Reichel
Move dsi_ops into the main structure, since all other ops
are gone. Instead of checking the device type we can simply
check if dsi_ops are set.
Signed-off-by: Sebastian Reichel
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
To start fixing the issues related to channels and vcs described in the
previous commit, pass vc and/or channel to various functions which will
need it do properly handle different DSI channels and VCs.
No functional changes.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
ULPS is a niche power-saving feature which only really affects command
mode panels showing a static picture. I know the ULPS code used to work
very long time ago, but I could not get it working with the current
driver. As the ULPS code is not trivial and includes delayed work (so
lots of chances
From: Sebastian Reichel
The DSI command mode panel is no longer specific
to OMAP and thus the config option has been renamed
slightly.
Signed-off-by: Sebastian Reichel
Signed-off-by: Tomi Valkeinen
Cc: Tony Lindgren
Reviewed-by: Laurent Pinchart
Acked-by: Tony Lindgren
---
From: Sebastian Reichel
In order to integrate with a chain of drm_bridge, the internal DSI
output has to expose its operations through the drm_bridge API.
Register a bridge at initialisation time to do so and remove the
omap_dss_device operations that are now unused.
Signed-off-by: Sebastian
The "channel" usage in omap dsi driver is confusing. We have three
different "channels":
1) DSI virtual channel ID. This is a number from 0 to 3, included in the
packet payload.
2) VC. This is a register block in the DSI IP. There are four of those
blocks. A VC is a DSI "pipeline", with defined
From: Sebastian Reichel
The omapdss device's ops_flags field is no longer
used and can be dropped.
Signed-off-by: Sebastian Reichel
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 9 -
drivers/gpu/drm/omapdrm/dss/venc.c| 1
The OMAP DSI command mode panel driver used to send page & column
address before each frame update, and this code was moved into the DSI
host driver when converting it to the DRM bridge model.
However, it's not really required to send the page & column address
before each frame. It's also
Drop unneeded includes.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/panel/panel-dsi-cm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c
Add a panel database to the driver instead of reading propertes from DT
data. This is similar to panel-simple, and I believe it's more future
safe way to handle the panels.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Sam Ravnborg
Reviewed-by: Sebastian Reichel
---
Panel drivers can send DSI commands in panel's prepare(), which happens
before the bridge's enable() is called. The OMAP DSI driver currently
only sets up the DSI interface at bridge's enable(), so prepare() cannot
be used to send DSI commands.
This patch fixes the issue by making it possible to
1 - 100 of 228 matches
Mail list logo
