: 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
dropp
set 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 host drive
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
>
: 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
dropp
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
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(-)
diff
-by: 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
that it 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/
the 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
to 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: Mic
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
refactored.
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
---
Michael
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
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.
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:
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
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
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
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
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
t 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
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(struct i2c_client
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 flow
to
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
[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
>> >> > 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
+ 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
c432e 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 channel
> 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
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
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. P
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 | 1
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
: 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
| 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 changed, 30
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
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
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
hael
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 this should be two commit
de
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 to meet
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
ase, 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
Hi,
I was just curious if you know of any development for that (or
similar)
in the kernel.
This is probably because support for this SoC began with Chromebooks,
which have fixed and defined uses for the pipelines. I suspect that
what you are working on is much more flexible.
Yes. that is
. A. Prado
Signed-off-by: Michael Walle
---
v2:
- iterate over all_drm_private[] to get any vdosys
- new check if a path is available
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 72 +
1 file changed, 58 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/dr
While digging through the code I realized that all the outputs and
pipelines
are harcoded. Doh. For all the mediatek SoCs. Looks like major
restriction
to
me. E.g. there is also DSI and HDMI output on the mt8195. I looked at
the
downstream linux and there, the output is not part of the
This won't work. On MT8195 there are two display IPs, vdosys0 and
vdosys1,
vdosys0 only has the main path while vdosys1 only has the external
path. So you
need to loop over each one in all_drm_private[j] to get the right crtc
ID for
MT8195.
Ahh thanks, got it.
-michael
Hi Nícolas,
But the real reason I've enabled it was because I'll get an kernel
oops otherwise. I thought it might be some quirk that you'll need
both,
because eDP will register even if theres no display - as you've
mentioned below.
Here's the splat:
[3.237064] mediatek-drm
. A. Prado
Signed-off-by: Michael Walle
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 41 ++---
1 file changed, 27 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 771f4e173353..f3064bff6
drm_crtc_from_index(0) might return NULL if there are not 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
Hi Nicolas,
> For the eDP case we can support using aux-bus on MediaTek DP: this
> gives us the possibility to declare our panel as generic "panel-edp"
> which will automatically configure the timings and available modes
> via the EDID that we read from it.
>
> To do this, move the panel
Hi AngeloGioacchino,
> For the eDP case we can support using aux-bus on MediaTek DP: this
> gives us the possibility to declare our panel as generic "panel-edp"
> which will automatically configure the timings and available modes
> via the EDID that we read from it.
>
> To do this, move the
-
Acked-by: Michael Walle
r lower
frequencies, esp. the Ths_prepare+Ths_zero timing. Thus, the bridge
will read a wrong HS sync sequence and set it's internal SoT error
bit (and don't generate any RGB signals on the LVDS side).
Tested-by: Michael Walle
Thanks!
-michael
.
An exception is the newly added drm_sched_job_cleanup, which must only
be called when the submit failed before handing the job to the
scheduler.
Fixes: b827c84f5e84 ("drm/etnaviv: Use scheduler dependency handling")
Reported-by: Michael Walle
Signed-off-by: Lucas Stach
FWIW (because it
> We need to pull the drm_sched_job_init much earlier, but that's very
> minor surgery.
This patch breaks the GC7000 on the LS1028A:
[ 35.671102] Unable to handle kernel NULL pointer dereference at virtual
address 0078
[ 35.680925] Mem abort info:
[ 35.685127] ESR =
Am 2022-04-05 15:58, schrieb codrin.ciubota...@microchip.com:
On 05.04.2022 14:09, Michael Walle wrote:
Am 2022-04-05 12:02, schrieb codrin.ciubota...@microchip.com:
On 05.04.2022 12:38, Michael Walle wrote:
Am 2022-04-05 11:23, schrieb codrin.ciubota...@microchip.com:
+ if (dev
Am 2022-04-05 12:02, schrieb codrin.ciubota...@microchip.com:
On 05.04.2022 12:38, Michael Walle wrote:
Am 2022-04-05 11:23, schrieb codrin.ciubota...@microchip.com:
+ if (dev->use_dma) {
+ dma_buf = i2c_get_dma_safe_msg_buf(m_start, 1);
If you want, you could just
Am 2022-04-05 11:23, schrieb codrin.ciubota...@microchip.com:
On 03.03.2022 18:17, Michael Walle wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know
the content is safe
The supplied buffer might be on the stack and we get the following
error
message:
[3.312058
Hi all,
Am 2022-03-03 17:17, schrieb Michael Walle:
The supplied buffer might be on the stack and we get the following
error
message:
[3.312058] at91_i2c e0070600.i2c: rejecting DMA map of vmalloc
memory
Use i2c_{get,put}_dma_safe_msg_buf() to get a DMA-able memory region if
necessary
The supplied buffer might be on the stack and we get the following error
message:
[3.312058] at91_i2c e0070600.i2c: rejecting DMA map of vmalloc memory
Use i2c_{get,put}_dma_safe_msg_buf() to get a DMA-able memory region if
necessary.
Cc: sta...@vger.kernel.org
Signed-off-by: Michael Walle
Am 2021-09-07 18:49, schrieb Michael Walle:
This patch series fixes usage of the etnaviv driver with GPUs behind a
IOMMU. It was tested on a NXP LS1028A SoC. Together with Lucas' MMU
patches
[1] there are not more (GPU internal) MMU nor (system) IOMMU faults on
the
LS1028A.
[1]
https
Signed-off-by: Michael Walle
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 54eb653ca295..0b756ecb1bc2 100644
--- a/drivers/g
1 - 100 of 120 matches
Mail list logo
