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
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
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
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
> >
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 |
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:
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
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
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
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.
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 -
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
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.
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 |
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 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
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 ++--
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 +
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
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 --
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
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 -
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
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
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 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
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
---
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 +
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
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
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
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
---
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
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
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
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
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
---
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
---
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
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
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.
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
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
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
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
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
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
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
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
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 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
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 +
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
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
> 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
Linux_Chemist (untaintablean...@hotmail.co.uk) changed:
What|Removed |Added
Regression|No |Yes
--
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
> 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
>
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
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.
>
>
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
85a90500f9a1717c4e142ce92e6c1cb1a339ec78
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
---
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
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.
> >
> >
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
---
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
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
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
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
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
> >>>
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 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
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
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 +
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
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,
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
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
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
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.
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
---
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
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
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
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
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
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:
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
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
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
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:
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
92 matches
Mail list logo
