; For all these reasons, add support for the OLDI TXes as DRM bridges.
>
> Reviewed-by: Tomi Valkeinen
> Tested-by: Alexander Sverdlin
> Signed-off-by: Aradhya Bhatia
> Signed-off-by: Aradhya Bhatia
Tested-by: Michael Walle # on a j722s/am67a
FWIW, I have a few downstream patches
Move to using the new API devm_drm_panel_alloc() to allocate the
panel.
Signed-off-by: Anusha Srivatsa
Reviewed-by: Michael Walle
-michael
Hi Daniel,
> > To cite the datasheet on VSDELAY:
> > During DSI link speed is slower than that of LVDS link’s, data needs
> > to be buffer within 775XBG before outputting to prevent data from
> > underflow. Register field VPCTRL[VSDELAY] is used to for this purpose
> >
> > This driver assume
Hi Daniel,
On Fri Sep 6, 2024 at 3:47 PM CEST, Daniel Semkowicz wrote:
> > tc->i2c = client;
>
> so the assignment above is no longer correct and should
> be also removed. Otherwise, this code will not compile.
Ahh yes. Thanks for noticing. I have a wip patch which I didn't
post, which h
Hi,
On Thu Jul 4, 2024 at 10:29 AM CEST, AngeloGioacchino Del Regno wrote:
> Il 19/06/24 12:56, AngeloGioacchino Del Regno ha scritto:
> > Il 18/06/24 12:17, AngeloGioacchino Del Regno ha scritto:
> >> Changes in v8:
> >> - Rebased on next-20240617
> >> - Changed to allow probing a VDO with no
Hi,
> with more and more patches for TC9595 support got meged into linux-next,
> only a few remain on my patch stack.
>
> This is one of them and is necessary for DP support:
> Tested-by: Alexander Stein
As mentioned in [1] I expect a new version of this series with a
proper documentation update
; DMT028VGHMCMI-1A - ST7701
> DMT028VGHMCMI-1D - ILI9806E
>
> Signed-off-by: Marek Vasut
Reviewed-by: Michael Walle
-michael
> Thank you for testing and keeping up with this. I will wait for more
> feedback if there is any (Frieder? Lucas? Michael?). If there are no
> objections, then I can merge it in a week or two ?
> >>>
> >>> I'll try to use your approach on the tc358775. Hopefully, I'll find
> >>> som
Hi Marek,
> >> Thank you for testing and keeping up with this. I will wait for more
> >> feedback if there is any (Frieder? Lucas? Michael?). If there are no
> >> objections, then I can merge it in a week or two ?
> >
> > I'll try to use your approach on the tc358775. Hopefully, I'll find
> > som
On Wed Jul 10, 2024 at 9:12 PM CEST, Doug Anderson wrote:
> Hi,
>
> On Wed, Jul 10, 2024 at 2:02 AM Michael Walle wrote:
> >
> > On Wed Jul 10, 2024 at 10:47 AM CEST, Cong Yang wrote:
> > > Break select page cmds into helper function.
> >
> > Why though?
On Wed Jul 10, 2024 at 10:47 AM CEST, Cong Yang wrote:
> Break select page cmds into helper function.
Why though? I don't find that anything easier to read. In fact, I
deliberately chose not to factor that out into a function. It's just
a sequence of magic commands, taken straight from the datashe
The Ortustech COM35H3P70ULC panel is based on the ILI9806E DSI display
controller.
Co-developed-by: Gunnar Dibbern
Signed-off-by: Gunnar Dibbern
Signed-off-by: Michael Walle
---
MAINTAINERS | 5 +
drivers/gpu/drm/panel/Kconfig | 9
Add the device tree binding for the Ilitek ILI9806E controller which can
be found on the Ortustech COME35H3P70ULC DSI display panel.
There are no peculiarities except for two different power signals.
Reviewed-by: Conor Dooley
Signed-off-by: Michael Walle
---
.../display/panel/ilitek
Add initial support for the 480x640 DSI panel from Ortustech. The
panel uses an Ilitek ILI9806E panel driver IC.
v2:
- use drm_connector_helper_get_modes_fixed(), thanks Dmitry.
- slight header files cleanup
Michael Walle (2):
dt-bindings: display: panel: add Ilitek ili9806e panel controller
On Wed Jun 26, 2024 at 5:21 AM CEST, Marek Vasut wrote:
> Thank you for testing and keeping up with this. I will wait for more
> feedback if there is any (Frieder? Lucas? Michael?). If there are no
> objections, then I can merge it in a week or two ?
I'll try to use your approach on the tc358775
The Ortustech COM35H3P70ULC panel is based on the ILI9806E DSI display
controller.
Co-developed-by: Gunnar Dibbern
Signed-off-by: Gunnar Dibbern
Signed-off-by: Michael Walle
---
MAINTAINERS | 5 +
drivers/gpu/drm/panel/Kconfig | 9
Add the device tree binding for the Ilitek ILI9806E controller which can
be found on the Ortustech COME35H3P70ULC DSI display panel.
There are no peculiarities except for two different power signals.
Signed-off-by: Michael Walle
---
.../display/panel/ilitek,ili9806e.yaml| 63
Add initial support for the 480x640 DSI panel from Ortustech. The
panel uses an Ilitek ILI9806E panel driver IC.
Michael Walle (2):
dt-bindings: display: panel: add Ilitek ili9806e panel controller
drm/panel: add Ilitek ILI9806E panel driver
.../display/panel/ilitek,ili9806e.yaml
Add OF graph support for board path
> dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
> drm/mediatek: Implement OF graphs support for display paths
Thanks!
Tested-by: Michael Walle # on kontron-sbc-i1200
-michael
signature.asc
Description: PGP signature
Hi Angelo,
> +/**
> + * mtk_drm_of_ddp_path_build_one - Build a Display HW Pipeline for a CRTC
> Path
> + * @dev: The mediatek-drm device
> + * @cpath:CRTC Path relative to a VDO or MMSYS
> + * @out_path: Pointer to an array that will contain the new pipeline
> + * @out_path_
: 5aa8e7647676 ("drm/mediatek: dpi/dsi: Change the getting possible_crtc
way")
Suggested-by: Nícolas F. R. A. Prado
Signed-off-by: Michael Walle
---
You can find v4 at [1]. Unfortunately, it was never applied and in the
meantime there was a change in mtk_find_possible_crtcs(). So I've
its reset while the clock lane is still in LP-11 mode.
> > >
> > > Unfortunately, (3) is crucial for a correct operation of the bridge.
> > > To satisfy this requriment, introduce a new callback .dsi_lp11_notify()
> > > which will be called by the DSI
On Mon May 6, 2024 at 3:34 PM CEST, Michael Walle wrote:
> This patchset fixes the bridge initialization according to the
> datasheet. Not sure how that even worked before. Maybe because the
> initialization was done prior to linux (?).
>
> The bridge has some peculiarities:
>
Hi Angelo,
> >> Implement OF graphs support to the mediatek-drm drivers, allowing to
> >> stop hardcoding the paths, and preventing this driver to get a huge
> >> amount of arrays for each board and SoC combination, also paving the
> >> way to share the same mtk_mmsys_driver_data between multiple
Hi Angelo,
On Thu May 16, 2024 at 10:11 AM CEST, AngeloGioacchino Del Regno wrote:
> Implement OF graphs support to the mediatek-drm drivers, allowing to
> stop hardcoding the paths, and preventing this driver to get a huge
> amount of arrays for each board and SoC combination, also paving the
> w
: 5aa8e7647676 ("drm/mediatek: dpi/dsi: Change the getting possible_crtc
way")
Suggested-by: Nícolas F. R. A. Prado
Signed-off-by: Michael Walle
---
You can find v4 at [1]. Unfortunately, it was never applied and in the
meantime there was a change in mtk_find_possible_crtcs(). So I've
Use the device resource managed version of drm_bridge_add(). This
simplifies the error handling and we can get rid of tc_remove_bridge().
Also, add a check for the return code.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 21 -
1 file changed, 4
d the additional
reset, nor the additional write to VFUEN. With that fixed, the init
sequence is exactly how the vendor is requiring it.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 62 +++
1 file changed, 37 insertions(+), 25 deletions(-)
: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
index d5b3d691d2c1..99dbbb1fee78 100644
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm
Move the bridge power-up and power-down handling into own functions.
This is a preparation patch to fix the power-up sequencing of the
bridge. No functional change.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 21 +
1 file changed, 17 insertions(+), 4
Provide bitfield macros for the individual fields in the LVDS timing
registers and get rid of the magic values.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 52 +--
1 file changed, 33 insertions(+), 19 deletions(-)
diff --git a
applies to a different bridge and was just a
leftover. Remove the DSI_START handling and the (unused) DSI_BUSY macro.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/Kconfig| 1 +
drivers/gpu/drm/bridge/tc358775.c | 58 +++
2 files changed, 35
The PLL setting was hardcoded to a LVDS clock between 60MHz and 135MHz.
This adds support for slower frequencies. Also, rework the reset
sequence to match the initialization sequence provided by the vendor.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 50
Split the initialization code in tc_bridge_enable() into specific
functions. This is a preparation for further code cleanup and fixes.
No functional change.
While at it, rename tc_bridge_enable() to the more specific
tc358775_bridge_enable().
Signed-off-by: Michael Walle
---
drivers/gpu/drm
() inline functions style by the more common
linux bitfields functions.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 48 +--
1 file changed, 21 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm
Reformat the indentation of the mipi_dsi_device_info initialization.
While at it, move it to the top of the function.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
The LVDS link can either be a single link or a dual link. No need for a
u8. Replace it with a bool "lvds_dual_link".
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/
TC358775_VPCTRL_MSF() and
TC358775_VPCTRL_OPXLFMT() inline functions by the usual macros for a bit
flag.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 49 +++
1 file changed, 8 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm
A missing regulator node will automatically be replaced by a dummy. Thus
regulators are optional anyway. Remove the error message.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu
-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 150 +-
1 file changed, 68 insertions(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
index 7ae86e8d4c72..b7f15164e655 100644
--- a/drivers/gpu/drm
Drop the FLD_VAL macro, just use bit shifts. This is a preparation patch
to switch to regmap and to remove the FLD_VAL().
While at it, reformat the LV_x enum.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc358775.c | 36 ++--
1 file changed, 6
the pulse width and the back porch
until these requirements are satisfied. The added pixels are then
substracted from the front porch so we don't actually change the pixel
clock (or framerate).
Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver")
Signed-off-by
The regulator id is given without the "-supply" postfix. With that
fixed, the driver will look up the correct regulator from the device
tree.
Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver")
Signed-off-by: Michael Walle
---
drivers/gpu/drm/bridge/tc35877
drm_bridge_dsi_lp11_notify() shall be called while both the clock and
data lanes are still in LP-11 mode. Add the callback.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu
efactored.
The bridge was successfully tested on a Mediatek MT8195 SoC with the
following panels:
- Innolux G101ICE
- AUO G121EAN01.0
- Innolux G156HCE (dual-link LVDS)
[1]
https://lore.kernel.org/r/20231016165355.1327217-1-dmitry.barysh...@linaro.org/
Signed-off-by: Michael Walle
---
Mi
As per specification in drivers/gpu/drm/drm_bridge.c the data lanes
should be in LP-11 mode after .pre_enable() has been run. HS mode of the
data lanes are enabled with mtk_dsi_start(). Therefore, move that call
to the .enable() callback.
Signed-off-by: Michael Walle
---
drivers/gpu/drm
operation of the bridge.
To satisfy this requriment, introduce a new callback .dsi_lp11_notify()
which will be called by the DSI host driver.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/drm_bridge.c | 16
include/drm/drm_bridge.h | 12
2 files changed, 28
Hi Angelo,
On Mon May 6, 2024 at 1:22 PM CEST, AngeloGioacchino Del Regno wrote:
> > The problem with this is that you need DDP_COMPONENT_DRM_OVL_ADAPTOR...
> > which is
> > a software thing and not HW, so that can't be described in devicetree.
> >
> > The only thing this series won't deal with
Hi Angelo,
On Tue Apr 30, 2024 at 1:33 PM CEST, AngeloGioacchino Del Regno wrote:
> >> This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
> >> NIO-12L with both hardcoded paths, OF graph support and partially
> >> hardcoded paths (meaning main display through OF graph and external
Hi Angelo,
On Tue Apr 9, 2024 at 2:02 PM CEST, AngeloGioacchino Del Regno wrote:
> +static int mtk_drm_of_get_ddp_ep_cid(struct device_node *node,
> + int output_port, enum mtk_drm_crtc_path
> crtc_path,
Not sure what's your base branch is, but "enum mtk_drm_crtc
Hi DRM maintainers,
On Sun Feb 25, 2024 at 7:19 AM CET, Tony Lindgren wrote:
> Here are v5 patches to improve tc358775 driver and add support for
> tc358765.
Any news on this series? Is there anything open or can it be merged?
FWIW, I have another tc358775 improvement series based on this.
-mic
On Sun Feb 11, 2024 at 10:51 AM CET, Tony Lindgren wrote:
> The hs_rate and lp_rate may be used by the dsi host for timing
> calculations. The tc358775 has a maximum bit rate of 1 Gbps/lane,
> tc358765 has maximurate of 800 Mbps per lane.
>
> Signed-off-by: Tony Lindgren
Revie
Hi Stephen and all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/bridge/samsung-dsim.c
between commit:
ff3d5d04db07 ("drm: bridge: samsung-dsim: Don't use
FORCE_STOP_STATE")
from Linus' tree and commit:
b2fe2292624a ("drm: bridge: samsung-dsim: en
Hi Dario,
>> Just FYI this conflictted pretty heavily with drm-misc-next changes in
>> the same area, someone should check drm-tip has the correct
>> resolution, I'm not really sure what is definitely should be.
>
> FWIW, this looks rather messy now. The drm-tip doesn't build.
>
> There was a ne
Just FYI this conflictted pretty heavily with drm-misc-next changes in
the same area, someone should check drm-tip has the correct
resolution, I'm not really sure what is definitely should be.
FWIW, this looks rather messy now. The drm-tip doesn't build.
There was a new call to samsung_dsim_set
Also merge commit 663a907e199b (Merge remote-tracking branch
'drm-misc/drm-misc-next' into drm-tip) is broken because it
completely removes samsung_dsim_atomic_disable(). Dunno whats
going on there.
Actually, that merge commit looks even worse. It somehow folds
the original samsung_dsim_atomic_d
Just FYI this conflictted pretty heavily with drm-misc-next changes in
the same area, someone should check drm-tip has the correct
resolution, I'm not really sure what is definitely should be.
FWIW, this looks rather messy now. The drm-tip doesn't build.
There was a new call to samsung_dsim_set
Hi,
Inki, are you picking this up? Or if not, who will?
I can pick it up but it would be better to go to the drm-misc tree. If
nobody cares about it then I will pick it up. :)
acked-by : Inki Dae
Who is going to pick this up? Who has access to the drm-misc tree?
-michael
> The hs_rate and lp_rate may be used by the dsi host for timing
> calculations. The tc358775 has a maximum bit rate of 1 Gbps/lane,
> tc358765 has maximurate of 800 Mbps per lane.
>
> Signed-off-by: Tony Lindgren
> ---
> drivers/gpu/drm/bridge/tc358775.c | 5 +
> 1 file changed, 5 insertion
quot;);
It wasn't obvious what this warning should tell me at first. Maybe
add something like ". Falling back to the property of the remote
endpoint". A little verbose, maybe you could come up with a more
dense wording.
In any case,
Reviewed-by: Michael Walle
-michael
> Set pre_enable_prev_first to ensure the previous bridge is enabled
> first.
>
> Signed-off-by: Tony Lindgren
Reviewed-by: Michael Walle
Tested-by: Michael Walle
- dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
> + MIPI_DSI_MODE_LPM;
Could you align it with the equal sign of the former line?
Reviewed-by: Michael Walle
Tested-by: Michael Walle
-michael
val |= TC358775_VPCTRL_MSF(1);
>>
>> dsiclk = mode->crtc_clock * 3 * tc->bpc / tc->num_dsi_lanes / 1000;
>> clkdiv = dsiclk / (tc->lvds_link == DUAL_LINK ? DIVIDE_BY_6 :
>> DIVIDE_BY_3);
>> @@ -643,6 +658,7 @@ static int tc_probe(st
For a normal operation, the vdd supplies nor the stby GPIO is needed.
There are boards, where these voltages are statically enabled during
board power-up.
This means supply is still required.
You mean using fixed-regulator? I didn't consider that. But yes, you're
right.
-michael
The stby pin is optional. It is only needed for power-up and down
sequencing. It is not needed, if the power rails cannot by dynamically
enabled.
Because the GPIO is not optional, remove the error message.
I just noticed a typo: "is *now* optional.
-michael
link. As a side
note, the command mode seems to just work in HS mode. I couldn't find
that the bridge will handle commands in LP mode.
Fixes: 20c827683de0 ("drm: bridge: samsung-dsim: Fix init during host
transfer")
Fixes: 0c14d3130654 ("drm: bridge: samsung-dsim: Fix i.MX8M enable
With the latest dynamic selection of the output component, we can now
support different outputs. Move current output component into the
dynamic routes array and add the new DSI0 output.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 8 +++-
1 file changed, 7
>> >> > DSI device lifetime has three different stages:
>> >> > 1. before the DSI link being powered up and clocking,
>> >> > 2. when the DSI link is in LP state (for the purpose of this question,
>> >> > this is the time between the DSI link being powered up and the video
>> >> > stream start)
>>
I'm facing similar issues with the tc358775 bridge. This bridge needs
to release its reset while both clock and data lanes are in LP-11
mode.
But then it needs to be configured (via I2C) while the clock lane is
in enabled (HS mode), but the data lanes are still in LP-11 mode.
This is quite an in
[sorry I fat fingered my former reply and converted all CCs to BCCs..]
>> >> > DSI device lifetime has three different stages:
>> >> > 1. before the DSI link being powered up and clocking,
>> >> > 2. when the DSI link is in LP state (for the purpose of this question,
>> >> > this is the time bet
>> >> > DSI device lifetime has three different stages:
>> >> > 1. before the DSI link being powered up and clocking,
>> >> > 2. when the DSI link is in LP state (for the purpose of this question,
>> >> > this is the time between the DSI link being powered up and the video
>> >> > stream start)
>>
> DSI device lifetime has three different stages:
> 1. before the DSI link being powered up and clocking,
> 2. when the DSI link is in LP state (for the purpose of this question,
> this is the time between the DSI link being powered up and the video
> stream start)
> 3. when the DSI link is in HS
Hi,
> DSI device lifetime has three different stages:
> 1. before the DSI link being powered up and clocking,
> 2. when the DSI link is in LP state (for the purpose of this question,
> this is the time between the DSI link being powered up and the video
> stream start)
> 3. when the DSI link is in
+ dt maintainers
I actually have the same fix, but with one additional detail, which
I'm
unsure about though: This looks at the data-lanes property of the
*remote*
endpoint whereas other bridge drivers (see tc358767, ti-sn65dsi83,
lt8912b,
anx7625) look at the local endpoint and I'm not sure
acd69c432e Mon Sep 17 00:00:00 2001
From: Michael Walle
Date: Wed, 4 Oct 2023 13:52:57 +0200
Subject: [PATCH] drm/bridge: tc358775: fix support for jeida-18 and jeida-24
The bridge always uses 24bpp internally. Therefore, for jeida-18
mapping we need to discard the lowest two bits for each ch
> The current code assume hardcoded dsi host endpoint 1, which may not
> be the case. Let's fix that and simplify the code by getting the dsi
> endpoint with of_graph_get_remote_endpoint() that does not assume any
> endpoint numbering.
>
> Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVD
Hi,
> The tc358765 is similar to tc358775 except for the stdby-gpios.
Bad timing (for me). I'm about to send a bigger patch series for the
tc358775 which fixes the (completely) broken initialialization. And also
contains some of your fixes.
That being said, I intend to make the standby gpio opti
ENT if no
> path is found and handle the error in the callers.
>
> Fixes: 5aa8e7647676 ("drm/mediatek: dpi/dsi: Change the getting
> possible_crtc way")
> Suggested-by: Nícolas F. R. A. Prado
> Signed-off-by: Michael Walle
> Reviewed-by: Nícolas F. R. A. Prado
>
Xinlei Lee's mail is bouncing:
: host mailgw02.mediatek.com[216.200.240.185] said:
550 Relaying mail to xinlei@mediatek.com is not allowed (in reply to
RCPT TO command)
Remove it.
Signed-off-by: Michael Walle
---
.../devicetree/bindings/display/mediatek/mediatek,dsi.yaml
With the latest dynamic selection of the output component, we can now
support different outputs. Move current output component into the
dynamic routes array and add the new DSI0 output.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 8 +++-
1 file changed, 7
Add the two DSI controller node and the associated DPHY nodes.
Individual boards have to enable them in the board device tree.
Signed-off-by: Michael Walle
---
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 48
1 file changed, 48 insertions(+)
diff --git a/arch/arm64/boot
Add the compatible string for MediaTek MT8195 SoC, using the same DSI
block as the MT8183.
Signed-off-by: Michael Walle
---
.../devicetree/bindings/display/mediatek/mediatek,dsi.yaml| 4
1 file changed, 4 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek
Add the compatible string for MediaTek MT8195 SoC, using the same MIPI
D-PHY block as the MT8183.
Signed-off-by: Michael Walle
---
Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi
.
This was tested with a Toshiba TC358775 DSI-to-LVDS bridge and
three different panels. Please note, that the driver for this
bridge doesn't work well and needs a more or less complete rework,
which will be posted on a separate series.
Michael Walle (4):
dt-bindings: display: mediatek: dsi
: add mipi_tx driver for mt8183")
Signed-off-by: Michael Walle
---
drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8183.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8183.c
b/drivers/phy/mediatek/phy-mtk-mipi-dsi-mt8183.c
index f0
144 | 175 |
DEN pulse width | - | 640 | - |
VS pulse width | 1 | 3 | 5 |
VS-DEN time | - |35 | - |
VS period| - | 525 | - |
Signed-off-by: Michael Walle
---
drivers/gpu/drm/panel/panel-simple.c | 30
1 file change
Add Evervision VGG644804 5.7" 640x480 LVDS panel compatible string.
Signed-off-by: Michael Walle
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.ya
callers.
Fixes: 5aa8e7647676 ("drm/mediatek: dpi/dsi: Change the getting
possible_crtc way")
Suggested-by: Nícolas F. R. A. Prado
Signed-off-by: Michael Walle
Reviewed-by: Nícolas F. R. A. Prado
Tested-by: Nícolas F. R. A. Prado
Is there anything wrong with these two patches? Th
Hi,
My current guess would be that the issue I was seeing was already fixed
with dd9e329af723 ("drm/bridge: ti-sn65dsi83: Fix enable/disable flow
to
meet spec") and I didn't properly test both changes separately.
I had the exact same thought, as I've found your second patch.
My cheap scope
on the actual link.
-michael
best regards,
Alexander
Fixes: 20c827683de0 ("drm: bridge: samsung-dsim: Fix init during host
transfer") Fixes: 0c14d3130654 ("drm: bridge: samsung-dsim: Fix i.MX8M
enable flow to meet spec") Signed-off-by: Michael Walle
---
Let me know wether
a side
note, the command mode seems to just work in HS mode. I couldn't find
that the bridge will handle commands in LP mode.
Fixes: 20c827683de0 ("drm: bridge: samsung-dsim: Fix init during host transfer")
Fixes: 0c14d3130654 ("drm: bridge: samsung-dsim: Fix i.MX8M enable flow
d by
> EOTp")
> Fixes: 2d52bfba09d1 ("drm/mediatek: add non-continuous clock mode and EOT
> packet control")
> Signed-off-by: AngeloGioacchino Del Regno
>
Tested-by: Michael Walle
Thanks,
-michael
Hi,
Am 2023-09-15 10:58, schrieb AngeloGioacchino Del Regno:
Il 15/09/23 09:57, Michael Walle ha scritto:
The commit c87d1c4b5b9a ("drm/mediatek: dsi: Use symbolized register
definition") inverted the logic of the control bit. Maybe it was
because
of the bad naming which was fixed
the logic
wrong and there will be no EOTp on the DSI link by default. Fix it.
Fixes: c87d1c4b5b9a ("drm/mediatek: dsi: Use symbolized register definition")
Signed-off-by: Michael Walle
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
.
Fixes: 5aa8e7647676 ("drm/mediatek: dpi/dsi: Change the getting possible_crtc
way")
Suggested-by: Nícolas F. R. A. Prado
Signed-off-by: Michael Walle
Reviewed-by: Nícolas F. R. A. Prado
Tested-by: Nícolas F. R. A. Prado
---
v4:
- return -ENOENT if mtk_drm_find_possible_crtc_by_comp() do
drm_crtc_from_index(0) might return NULL if there are no CRTCs
registered at all which will lead to a kernel oops in
mtk_drm_crtc_dma_dev_get(). Add the missing return value check.
Fixes: 0d9eee9118b7 ("drm/mediatek: Add drm ovl_adaptor sub driver for MT8195")
Signed-off-by: Mic
At this point, I think that it would be sane to change this function to
return a signed type, so that we can return -ENOENT if we couldn't find
any DDP path (so, if we couldn't find any possible crtc).
Fair enough, but should it be part of the fixes commit or a different
one?
-michael
. A. Prado
Signed-off-by: Michael Walle
Reviewed-by: Nícolas F. R. A. Prado
Tested-by: Nícolas F. R. A. Prado
---
v3:
- use data instead of priv_n->data
- fixed typos
- collected Rb and Tb tags
v2:
- iterate over all_drm_private[] to get any vdosys
- new check if a path is available
---
dr
drm_crtc_from_index(0) might return NULL if there are no CRTCs
registered at all which will lead to a kernel oops in
mtk_drm_crtc_dma_dev_get(). Add the missing return value check.
Fixes: 0d9eee9118b7 ("drm/mediatek: Add drm ovl_adaptor sub driver for MT8195")
Signed-off-by: Mic
drm_crtc_from_index(0) might return NULL if there are no CRTCs
registered at all which will lead to a kernel oops in
mtk_drm_crtc_dma_dev_get(). Add the missing return value check.
Fixes: 0d9eee9118b7 ("drm/mediatek: Add drm ovl_adaptor sub driver for MT8195")
Signed-off-by: Mic
1 - 100 of 140 matches
Mail list logo
