On Wed, Aug 04, 2021 at 06:03:54PM +0200, Sam Ravnborg wrote:
> Hi Shawn,
>
> On Wed, Aug 04, 2021 at 04:13:51PM +0800, Shawn Guo wrote:
> > The Truly NT35521 is a 5.24" 1280x720 DSI panel, and the backlight is
> > managed through DSI link.
> >
> > Signed-off-by: Shawn Guo
>
> Please consider a
Changes since v1:
- Fix null point when dsi next bridge isn't a panel.
- "dsi mmsys reset" is implement by
https://patchwork.kernel.org/project/linux-mediatek/list/?series=515355
Jitao Shi (3):
drm/panel: seperate panel power control from panel prepare/unprepare
drm/panel: boe-tv101wum-n1
Seperate the panel power control from prepare/unprepare.
Signed-off-by: Jitao Shi
---
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 72 +--
1 file changed, 50 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/pa
Some dsi panels require the dsi lanes keeping low before panel power
on. So seperate the panel power control and the communication with panel.
And put the power control in drm_panel_prepare_power and
drm_panel_unprepare_power. Put the communication with panel in
drm_panel_prepare and drm_panel_unp
Add the drm_panel_prepare_power and drm_panel_unprepare_power control.
Turn on panel power(drm_panel_prepare_power) and control before dsi
enable. And then dsi enable, send dcs cmd in drm_panel_prepare, last
turn on backlight.
Most dsi panels, have five steps when poweron.
1. turn on dsi signal t
Changes since v5:
- Remvoe the anx7625 devicetree change. Use the compatible string intead.
Changes since v4:
- Move "dt-bindings: drm/bridge: anx7625: add force_dsi_end_without_null"
before
"drm/mediatek: force hsa hbp hfp packets multiple of lanenum to avoid".
- Retitle "dt-bindings: drm
The bridge chip ANX7625 requires the packets on lanes aligned at the end,
or ANX7625 will shift the screen.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/med
Hi Stephan,
Thanks for looking at the patch!
On Wed, Aug 04, 2021 at 02:09:19PM +0200, Stephan Gerhold wrote:
> Hi Shawn,
>
> Thanks for the patch!
>
> On Wed, Aug 04, 2021 at 04:13:52PM +0800, Shawn Guo wrote:
> > It adds a drm driver for Truly NT35521 5.24" 1280x720 DSI panel, which
> > can b
Hi,
This patchset rework the ingenic-drm driver, improving the code in
various places.
The most important change is the last patch, which updates the
ingenic-drm driver to use a top-level bridge per output, making use of
the bus format and flag negociation implemented in the bridge code. All
the
The priv->ipu_plane would get a different value further down the code,
without the first assigned value being read first; so the first
assignation can be dropped.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/driv
Instead of having one 'hwdesc' variable for the plane #0 and one for the
plane #1, use a 'hwdesc[2]' array, where the DMA hardware descriptors
are indexed by the plane's number.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 38 ---
1 file change
By making the CRTC's .vblank_enable() function return an error when it
is known that the hardware won't deliver a VBLANK, we can drop the
ingenic_drm_atomic_helper_commit_tail() function and use the standard
drm_atomic_helper_commit_tail() function instead.
Signed-off-by: Paul Cercueil
---
drive
Until now, the ingenic-drm as well as the ingenic-ipu drivers used to
put state-specific information in their respective private structure.
Add boilerplate code to support private objects in the two drivers, so
that state-specific information can be put in the state-specific private
structure.
Si
The IPU scaling information is computed in the plane's ".atomic_check"
callback, and used in the ".atomic_update" callback. As such, it is
state-specific, and should be moved to a private state structure.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-ipu.c | 73 +++
Setting the DMA descriptor chain register in the probe function has been
fine until now, because we only ever had one descriptor per foreground.
As the driver will soon have real descriptor chains, and the DMA
descriptor chain register updates itself to point to the current
descriptor being proces
When using C8 color mode, make sure that the palette is always uploaded
before a frame; otherwise the very first frame will have wrong colors.
Do that by changing the link order of the DMA descriptors.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 69 +
Attach a top-level bridge to each encoder, which will be used for
negociating the bus format and flags.
All the bridges are now attached with DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 92 +--
1 file changed,
Hi Sam,
On Wed, Aug 04, 2021 at 06:24:12PM +0200, Sam Ravnborg wrote:
> Hi Shawn,
>
> see a few comments in the following.
Thanks for the review comments! All of them will be addressed in v2.
Shawn
> On Wed, Aug 04, 2021 at 04:13:52PM +0800, Shawn Guo wrote:
> > It adds a drm driver for Truly
This is a 5.7" 2160x1080 panel found on the Motorola Moto G6.
There may be other smartphones using it, as well.
Signed-off-by: Julian Braha
---
drivers/gpu/drm/panel/Kconfig | 7 ++
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-tianma-tl057fvxp01.
On 8/6/2021 4:18 AM, Jason Gunthorpe wrote:
The patch to move the get/put to core and the patch to convert the samples
to use vfio_device crossed in a way that this was missed. When both
patches are together the samples do not need their own get/put.
Fixes: 437e41368c01 ("vfio/mdpy: Convert to
On 07/08/2021 21:04, Rob Clark wrote:
On Sat, Aug 7, 2021 at 12:21 PM Caleb Connolly
wrote:
Hi Rob, Akhil,
On 29/07/2021 21:53, Rob Clark wrote:
On Thu, Jul 29, 2021 at 1:28 PM Caleb Connolly
wrote:
On 29/07/2021 21:24, Rob Clark wrote:
On Thu, Jul 29, 2021 at 1:06 PM Caleb Connolly
On Sun, Aug 08, 2021 at 09:44:57PM +0800, Shawn Guo wrote:
> On Wed, Aug 04, 2021 at 02:09:19PM +0200, Stephan Gerhold wrote:
> > On Wed, Aug 04, 2021 at 04:13:52PM +0800, Shawn Guo wrote:
> > > + ...
> > > + nt_dcs_write(0xb1, 0x6c, 0x21);
> > > + nt_dcs_write(0xf0, 0x55, 0xaa, 0x52, 0x00, 0x00);
On Sun, Aug 8, 2021 at 7:33 AM Caleb Connolly wrote:
>
>
>
> On 07/08/2021 21:04, Rob Clark wrote:
> > On Sat, Aug 7, 2021 at 12:21 PM Caleb Connolly
> > wrote:
> >>
> >> Hi Rob, Akhil,
> >>
> >> On 29/07/2021 21:53, Rob Clark wrote:
> >>> On Thu, Jul 29, 2021 at 1:28 PM Caleb Connolly
> >>> wro
Resets are notoriously hard to get fully working and notoriously racey,
especially with selftests / IGTs that do all sorts of wild things that
would be near impossible to hit during normal use cases. Even though
likely impossible to hit, anything selftests / IGTs uncover needs to be
fixed. This pat
Address CI failure related to reset [1]. In addition to the public CI
failure we also fix several issues uncovered recenting in our internal
CI related to resets. Patch #1 address all of these issues.
Workaround an existing memory corruption, in gt_lrc selftest, exposed by
enabling GuC submission
GuC submission has exposed an existing memory corruption in
live_lrc_isolation. We believe that some writes to the watchdog offsets
in the LRC (0x178 & 0x17c) can result in trashing of portions of the
address space. With GuC submission there are additional objects which
can move the context redzone
While debugging an issue with full GT resets I went down a rabbit hole
thinking the scrubbing of lost G2H wasn't working correctly. This proved
to be incorrect as this was working just fine but this chase inspired me
to write a selftest to prove that this works. This simple selftest
injects errors
Am 08.08.21 um 15:45 schrieb Paul Cercueil:
The priv->ipu_plane would get a different value further down the code,
without the first assigned value being read first; so the first
assignation can be dropped.
Signed-off-by: Paul Cercueil
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/in
On Sun, 2021-08-08 at 19:58 +0200, Thomas Zimmermann wrote:
>
> Am 08.08.21 um 15:45 schrieb Paul Cercueil:
> > The priv->ipu_plane would get a different value further down the code,
> > without the first assigned value being read first; so the first
> > assignation can be dropped.
> >
> > Signed
Hi Joe,
Le dim., août 8 2021 at 11:27:34 -0700, Joe Perches
a écrit :
On Sun, 2021-08-08 at 19:58 +0200, Thomas Zimmermann wrote:
Am 08.08.21 um 15:45 schrieb Paul Cercueil:
> The priv->ipu_plane would get a different value further down the
code,
> without the first assigned value being
Hi
Am 08.08.21 um 15:45 schrieb Paul Cercueil:
Instead of having one 'hwdesc' variable for the plane #0 and one for the
plane #1, use a 'hwdesc[2]' array, where the DMA hardware descriptors
are indexed by the plane's number.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-dr
umented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Julian-Braha/drm-panel-tianma-tl057fvxp01-add-panel-for-Motorola-Moto-G6/20210808-220609
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
85a90500f9a1717c4e142ce92e6c1c
Hi Paul,
all other patches apply cleanly but this one fails on top of v5.14-rc4.
What base are you using?
BR and thanks,
Nikolaus
> Am 08.08.2021 um 15:45 schrieb Paul Cercueil :
>
> Attach a top-level bridge to each encoder, which will be used for
> negociating the bus format and flags.
>
> Al
Hi Nikolaus,
Le dim., août 8 2021 at 20:57:09 +0200, H. Nikolaus Schaller
a écrit :
Hi Paul,
all other patches apply cleanly but this one fails on top of
v5.14-rc4.
What base are you using?
BR and thanks,
Nikolaus
The base is drm-misc (https://cgit.freedesktop.org/drm/drm-misc),
branch dr
> Am 08.08.2021 um 21:04 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
> Le dim., août 8 2021 at 20:57:09 +0200, H. Nikolaus Schaller
> a écrit :
>> Hi Paul,
>> all other patches apply cleanly but this one fails on top of v5.14-rc4.
>> What base are you using?
>> BR and thanks,
>> Nikolaus
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=214001
Bug ID: 214001
Summary: [bisected][regression] After commit "drm/ttm:
Initialize debugfs from ttm_global_init()" kernels
without debugfs explicitly set to 'allow all' fail to
https://bugzilla.kernel.org/show_bug.cgi?id=214001
Linux_Chemist (untaintablean...@hotmail.co.uk) changed:
What|Removed |Added
Regression|No |Yes
--
> Am 08.08.2021 um 21:06 schrieb H. Nikolaus Schaller :
>
>
>
>> Am 08.08.2021 um 21:04 schrieb Paul Cercueil :
>>
>> Hi Nikolaus,
>>
>> Le dim., août 8 2021 at 20:57:09 +0200, H. Nikolaus Schaller
>> a écrit :
>>> Hi Paul,
>>> all other patches apply cleanly but this one fails on top of
https://bugzilla.kernel.org/show_bug.cgi?id=214001
--- Comment #1 from Linux_Chemist (untaintablean...@hotmail.co.uk) ---
As an addendum, I suppose a slight source of confusion is the info for
CONFIG_DEBUG_FS which reads:
"debugfs is a virtual file system that kernel developers use to put
debug
Le 08/08/2021 à 15:45, Paul Cercueil a écrit :
By making the CRTC's .vblank_enable() function return an error when it
is known that the hardware won't deliver a VBLANK, we can drop the
ingenic_drm_atomic_helper_commit_tail() function and use the standard
drm_atomic_helper_commit_tail() function i
This is a 5.7" 2160x1080 panel found on the Motorola Moto G6.
There may be other smartphones using it, as well.
Signed-off-by: Julian Braha
---
drivers/gpu/drm/panel/Kconfig | 7 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-tianma-tl057fvxp01
Hi Christophe,
Le dim., août 8 2021 at 21:50:04 +0200, Christophe JAILLET
a écrit :
Le 08/08/2021 à 15:45, Paul Cercueil a écrit :
By making the CRTC's .vblank_enable() function return an error when
it
is known that the hardware won't deliver a VBLANK, we can drop the
ingenic_drm_atomic_help
Le 08/08/2021 à 22:09, Paul Cercueil a écrit :
Hi Christophe,
Le dim., août 8 2021 at 21:50:04 +0200, Christophe JAILLET
a écrit :
Le 08/08/2021 à 15:45, Paul Cercueil a écrit :
By making the CRTC's .vblank_enable() function return an error when it
is known that the hardware won't deliver a
Hi Thomas,
Le dim., août 8 2021 at 20:42:53 +0200, Thomas Zimmermann
a écrit :
Hi
Am 08.08.21 um 15:45 schrieb Paul Cercueil:
Instead of having one 'hwdesc' variable for the plane #0 and one for
the
plane #1, use a 'hwdesc[2]' array, where the DMA hardware descriptors
are indexed by the pla
These refinements include using standard mailbox callback interface,
timeout detection, and a fixed cmdq_handle.
Changes in v2:
1. Define mtk_drm_cmdq_pkt_create() and mtk_drm_cmdq_pkt_destroy()
when CONFIG_MTK_CMDQ is reachable.
Chun-Kuang Hu (4):
drm/mediatek: Use mailbox rx_callback inste
rx_callback is a standard mailbox callback mechanism and could cover the
function of proprietary cmdq_task_cb, so use the standard one instead of
the proprietary one.
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 16 +---
1 file changed, 13 insertions(+),
In mailbox rx_callback, it pass struct mbox_client to callback
function, but it could not map back to mtk_drm_crtc instance
because struct cmdq_client use a pointer to struct mbox_client:
struct cmdq_client {
struct mbox_client client;
struct mbox_chan *chan;
};
struct mtk_drm_crt
CMDQ is used to update display register in vblank period, so
it should be execute in next vblank. If it fail to execute
in next 2 vblank, tiemout happen.
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
One mtk_crtc need just one cmdq_handle, so add one cmdq_handle
in mtk_crtc to prevent frequently allocation and free of
cmdq_handle.
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 28 -
1 file changed, 18 insertions(+), 10 deletions(-)
diff --
Hello,
The DPSUB is the DisplayPort subsystem, a set of hard IP cores found in
the ZynqMP family of SoCs. It combines a DisplayPort encoder, a video
blender with two input channels, and a DMA engine. The zynqmp_dpsub
driver exposes this as a DRM device with one CRTC and two planes.
In addition to
To prepare for the transition to the DRM bridge API, switch the encoder
operations to the atomic versions of .enable() and .disable(). This
doesn't cause any functional change by itself.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 10 ++
1 file changed, 6 inser
The DP encoder is currently modelled as a DRM encoder and DRM connector.
This doesn't support system configurations where the DP encoder is
driven by the FPGA programmable logic, using the live video input to the
DP subsystem. To enable such use cases, we need to model the encoder as
a DRM bridge.
The DPSUB doesn't live in isolation, but is connected to the
programmable logic for live inputs and outputs, and also has a
DisplayPort output. Model all those using OF graph.
Signed-off-by: Laurent Pinchart
---
.../display/xlnx/xlnx,zynqmp-dpsub.yaml | 67 +++
1 file chang
The zynqmp_dp_encoder_mode_set_transfer_unit() function takes a mode
pointer argument that it doesn't need to modify. Make it const.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xlnx/zynqm
Connector creation requires the DRM encoder, and it thus typically
performed in the bridge attach operation. Move it there, to prepare for
registration of the DRM bridge. For now the zynqmp_dp_bridge_attach() is
called manually at initialization time.
Signed-off-by: Laurent Pinchart
---
drivers/
As part of the transitition of the DP encoder to a DRM bridge, turn the
DRM encoder into a dummy encoder and move it out of the DP code, to the
DPSUB core. DP encoder operations are handled by the DP bridge, which is
now attached to the encoder.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/dr
To prepare for the removal of the connector from the DP encoder, pass
the display info pointer to the zynqmp_dp_set_format() function instead
of accessing the connector internally. The display info is NULL when the
function is called at initialization time, as we have no display info at
that point.
The array of formats passed to drm_universal_plane_init() doesn't need
to outlive the function call, as it's copied internally. Use kcalloc()
instead of drmm_kcalloc() to allocate it, and free it right after usage.
While at it, move the allocation and initialization of the formats array
to a separ
To prepare for control of the blender outside of the CRTC code, move the
setup of the blender to the zynqmp_disp_enable() function. This doesn't
introduce any functional change.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 6 +++---
1 file changed, 3 insertions(+), 3
The event field of the zynqmp_disp structure is unused. Drop it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index ff2b308d8651..4180353b484a
To prepare for usage of the clock setup function outside of the CRTC
code, replace the DRM-specific structures passed as parameters with a
pointer to the zynqmp_disp and the requested clock rate. This doesn't
introduce any functional change.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xl
Reuse the local info variable instead of going through the layer pointer
in zynqmp_disp_layer_update(). This doesn't introduce any functional
change.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
Now that the driver uses the connector bridge helper, HPD can be
reported directly for the connector through the drm_bridge_hpd_notify()
function.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/
Decouple the zynqmp_disp, which handles the hardware configuration, from
the DRM CRTC by moving the CRTC to the zynqmp_dpsub structure. The CRTC
handling code will be moved to a separate file in a subsequent step.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 20 +
Replace the manual connector implementation and registration in the DP
encoder with the DRM connector bridge helper. This removes boilerplate
code and simplifies the driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_dp.c| 90 +
drivers/gpu/dr
Decouple the CRTC handling from the display controller programming by
moving the corresponding code from zynqmp_disp.c to zynqmp_kms.c. This
prepares for using the DPSUB with a live video input, without creating a
DRM CRTC in the DPSUB driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/
The next component in the display chain, after the DP encoder, is most
likely a DP connector. The display connector driver registers a bridge
for it. That bridge doesn't need to be controlled, but is needed in
order to use the DRM connector bridge helper. Retrieve it at init time,
and attach to it
The audio clock is an external resource from the DPSUB point of view,
not a resource internal to the display controller. Move it to the
zynqmp_dpsub structure, to allow accessing it from outside the disp
code.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 54 ++---
The video clock is an external resource from the DPSUB point of view,
not a resource internal to the display controller. Move it to the
zynqmp_dpsub structure, to allow accessing it from outside the disp
code.
While at it, rename the fields from pclk and pclk_from_ps to vid_clk and
vid_clk_from_ps
The zynqmp_disp_layer_set_format() function only needs format
information, not a full plane state. Get the necessary info from the
plane state in the caller and pass it to zynqmp_disp_layer_set_format().
This prepares for calling the function from non-DRM code. This doesn't
introduce any functional
There's no need to delay bridge initialization, move it to
zynqmp_dp_probe() and drop the zynqmp_dp_drm_init() function.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 30 --
drivers/gpu/drm/xlnx/zynqmp_dp.h | 1 -
drivers/gpu/drm/xlnx/zynqm
Use the ARRAY_SIZE() macro to iterate over arrays, instead of hardcoding
their size. This makes the code less error-prone should the array size
change.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
Continue the isolation of DRM/KMS code by moving all DRM init and
cleanup from zynqmp_dpsub.c to zynqmp_kms.c.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 120 +-
drivers/gpu/drm/xlnx/zynqmp_dpsub.h | 5 --
drivers/gpu/drm/xlnx/zynqmp_kms.c
The bus_fmt field of the zynqmp_disp_format structure is unused. Drop
it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 4180353b484a..a6800
To prepare for live video input support, parse the device tree to find
the connected ports. Warn about unsupported configurations, and error
out when invalid.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 54 +
drivers/gpu/drm/xlnx/zynqmp_d
The better convey its purpose, rename the zynqmp_dpsub_handle_vblank()
function that belongs to the DRM layer to
zynqmp_dpsub_drm_handle_vblank().
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
drivers/gpu/drm/xlnx/zynqmp_kms.c | 4 ++--
drivers/gpu/drm/xlnx/zynqmp
To prepare for usage of the DPSUB as a DisplayPort bridge without
creating a DRM device, make initialization and usage of the DMA engine
optional. The flag that controls this feature is currently hardcoded to
operating with the DMA engine, this will be made dynamic based on the
device tree configur
The zynqmp_disp and zynqmp_dp structures are allocated with
drmm_kzalloc(). While this simplifies management of memory, it requires
a DRM device, which will not be available at probe time when the DP
bridge will be used standalone, with a DRM device in the PL. To prepare
for this, switch to manual
To prepare for operating as a standalone DP bridge with the DRM device
implemented in the PL, move registration of the AUX bus to bridge attach
time, as that's the earliest point when a DRM device is available.
The DRM device pointer stored in zynqmp_dp isn't used anymore, drop it.
Signed-off-by:
Decouple the zynqmp_disp, which handles the hardware configuration, from
the DRM planes by moving the planes to the zynqmp_dpsub structure. The
planes handling code will be moved to a separate file in a subsequent
step.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/Makefile | 2
Add partial live video support, with a single video input that bypasses
blending. Skip registration of the DRM device in that case, but register
the DRM bridge instead. The DRM device will be created by the driver for
the display controller in the PL.
Full live video mode with concurrent usage of
Add a mode parameter to the zynqmp_disp_layer_enable() to set the layer
mode, to prepare for live mode support.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 30 +-
drivers/gpu/drm/xlnx/zynqmp_disp.h | 13 -
drivers/gpu/drm/xlnx/
Decouple the planes handling from the display controller programming by
moving the corresponding code from zynqmp_disp.c to zynqmp_kms.c. This
prepares for using the DPSUB with a live video input, without creating
DRM planes in the DPSUB driver.
While at it, fix a typo in a comment.
Signed-off-by
To complete the decoupling of the DRM device from the zynqmp_dpsub,
group all DRM-related structures in a zynqmp_dpsub_drm structure and
allocate it separately from the zynqmp_dpsub. The DRM managed allocation
of the drm_device now doesn't cover the zynqmp_dpsub anymore, so we need
to register a cl
Add a device tree node to describe the DisplayPort connector, and
connect it to the DPSUB output.
Signed-off-by: Laurent Pinchart
---
.../boot/dts/xilinx/zynqmp-zcu106-revA.dts| 20 +++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu106-re
The DPSUB DT bindings now specify ports to model the connections with
the programmable logic and the DisplayPort output. Add them to the
device tree.
Signed-off-by: Laurent Pinchart
---
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 24
1 file changed, 24 insertions(+)
diff -
Hi Dave and Daniel,
The following changes since commit 49f7844b08844ac7029f997702099c552566262b:
Merge tag 'drm-misc-next-2021-08-05' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2021-08-06 06:59:30
+1000)
are available in the Git repository at:
git://linuxtv.org/pinchartl
Building with W=1 complains about an empty 'else' statement, so use the
usual do-nothing-while-0 loop to quieten this warning.
../drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_psr.c:113:53: warning:
suggest braces around empty body in an 'else' statement [-Wempty-body]
113 |
On Sun, Aug 08, 2021 at 05:29:30PM +0200, Stephan Gerhold wrote:
> > 2) The driver works good, if the kernel is launched via "fastboot boot".
> >But if the kernel is flashed to eMMC and launched by bootloader with
> >splash screen, kernel will fail to bring up the panel. After kernel
> >
It adds driver for Sony Tulip Truly NT35521 5.24" 1280x720 DSI panel,
which can be found on Sony Xperia M4 Aqua phone.
Changes for v2:
- Add `port` node into bindings.
- Re-create the driver using linux-mdss-dsi-panel-driver-generator[1].
- Rename the driver to include Sony Tulip.
- Model 5V contr
The Sony Tulip Truly NT35521 is a 5.24" 1280x720 DSI panel, which can
be found on Sony Xperia M4 Aqua phone. The backlight is managed
through DSI link.
Signed-off-by: Shawn Guo
---
.../panel/sony,tulip-truly-nt35521.yaml | 72 +++
1 file changed, 72 insertions(+)
create m
It adds a DRM panel driver for Sony Tulip Truly NT35521 5.24" 1280x720
DSI panel, which can be found on Sony Xperia M4 Aqua phone. The panel
backlight is managed through DSI link.
The driver is built using linux-mdss-dsi-panel-driver-generator[1], and
additionally modeling the 5V control GPIOs wi
Hi Tom,
On 7/27/21 3:26 PM, Tom Lendacky wrote:
This patch series provides a generic helper function, prot_guest_has(),
to replace the sme_active(), sev_active(), sev_es_active() and
mem_encrypt_active() functions.
It is expected that as new protected virtualization technologies are
added to th
From: Julius
Fixed compiler warning: "left shift of negative value"
Signed-off-by: Julius Victorian
---
drivers/gpu/drm/i915/i915_perf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 9f94914958c3..7
94 matches
Mail list logo
