Am 2020-03-10 08:40, schrieb Michael Walle:
Am 2020-03-10 08:33, schrieb Michael Walle:
Use the correct device to request the DMA mapping. Otherwise the IOMMU
doesn't get the mapping and it will generate a page fault.
The error messages look like:
[3.008452] arm-smmu 500.iommu
[3.020123] arm-smmu 500.iommu: Unhandled context fault: fsr=0x402,
iova=0xf980, fsynr=0x3f0022, cbfrsynra=0x828, cb=8
This was tested on a custom board with a LS1028A SoC.
Signed-off-by: Michael Walle
---
drivers/spi/spi-fsl-dspi.c | 17 ++---
1 file changed, 10 insertions
Am 2020-03-10 08:33, schrieb Michael Walle:
Use the correct device to request the DMA mapping. Otherwise the IOMMU
doesn't get the mapping and it will generate a page fault.
The error messages look like:
[3.008452] arm-smmu 500.iommu: Unhandled context fault:
fsr=0x402, iova=0xf980
Am 2020-03-10 14:02, schrieb Vladimir Oltean:
On Tue, 10 Mar 2020 at 10:12, Michael Walle wrote:
Am 2020-03-10 08:40, schrieb Michael Walle:
> Am 2020-03-10 08:33, schrieb Michael Walle:
>> Use the correct device to request the DMA mapping. Otherwise the IOMMU
>> doesn't
The GPU is found on the NXP LS1028A SoC. The feature bits are taken from
the NXP downstream kernel driver 6.4.3.p1.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 31 ++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv
duo an using
ETNA_MESA_DEBUG=no_supertile,no_ts.
Michael Walle (2):
drm/etnaviv: add HWDB entry for GC7000 r6202
drm/etnaviv: add clock gating workaround for GC7000 r6202
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 6 +
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 31 ++
2
The LS1028A SoC errata sheet mentions A-050121 "GPU hangs if clock
gating for Rasterizer, Setup Engine and Texture Engine are enabled".
The workaround is to disable the corresponding clock gatings.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 6 ++
1 fi
/GC7000 duo, fixes from mesa merge request
9255 [2] and using ETNA_MESA_DEBUG=no_supertile,no_ts.
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11419
[2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9255
Michael Walle (2):
drm/etnaviv: add HWDB entry for GC7000 r6202
drm
The GPU is found on the NXP LS1028A SoC. The feature bits are taken from
the NXP downstream kernel driver 6.4.3.p1.
Signed-off-by: Michael Walle
---
changes since RFC:
- none
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 31 ++
1 file changed, 31 insertions(+)
diff --git
The LS1028A SoC errata sheet mentions A-050121 "GPU hangs if clock
gating for Rasterizer, Setup Engine and Texture Engine are enabled".
The workaround is to disable the corresponding clock gatings.
Signed-off-by: Michael Walle
---
changes since RFC:
- corrected the wording of t
Am 2021-08-26 14:14, schrieb Russell King (Oracle):
On Thu, Aug 26, 2021 at 02:10:05PM +0200, Michael Walle wrote:
+ pdev->dev.coherent_dma_mask = DMA_BIT_MASK(40);
+ pdev->dev.dma_mask = >dev.coherent_dma_mask;
Please use dma_coerce_mask_and_coherent() her
-off-by: Michael Walle
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index ff6425f6ebad..0b756ecb1bc2 100644
--- a/drivers/gpu/drm
Am 2021-08-26 14:19, schrieb Russell King (Oracle):
On Thu, Aug 26, 2021 at 02:10:06PM +0200, Michael Walle wrote:
- pdev->dev.coherent_dma_mask = DMA_BIT_MASK(40);
- pdev->dev.dma_mask = >dev.coherent_dma_mask;
+ /*
+* PTA and MTLB can have 40 bit base
Am 2021-08-26 14:10, schrieb Michael Walle:
The STLB and the first command buffer (which is used to set up the
TLBs)
has a 32 bit size restriction in hardware. There seems to be no way to
specify addresses larger than 32 bit. Keep it simple and restict the
addresses to the lower 4 GiB range
There is already a macro for the magic value. Use it.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 7dcc6392792d
/003682.html
Michael Walle (3):
drm/etnaviv: use PLATFORM_DEVID_NONE
drm/etnaviv: fix dma configuration of the virtual device
drm/etnaviv: use a 32 bit mask as coherent DMA mask
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 41 ---
1 file changed, 31 insertions(+), 10
settings together.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 2509b3e85709..ff6425f6ebad
()
iommu_group_add_device()
Move of_dma_configure() into the probe function, which is called after
device_add(). Normally, the platform code will already call it itself
if .of_node is set. Unfortunately, this isn't the case here.
Signed-off-by: Michael Walle
---
drivers/gpu/drm/etnaviv
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
/003682.html
changes since v1:
- don't move the former dma_mask setup code around in patch 2/3. Will
avoid any confusion.
Michael Walle (3):
drm/etnaviv: use PLATFORM_DEVID_NONE
drm/etnaviv: fix dma configuration of the virtual device
drm/etnaviv: use a 32 bit mask as coherent DMA mask
There is already a macro for the magic value. Use it.
Signed-off-by: Michael Walle
Reviewed-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv
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
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
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
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
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 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
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
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
.
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
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
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
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
. 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
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 --
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 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
. 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 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
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
.
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 =
-
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
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:
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,
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
| 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
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 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
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 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
.
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
> 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
[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)
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
>> >> > 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)
>>
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
+ 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
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
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
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
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
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
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
> 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
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
> 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
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
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 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
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
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
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
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
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
-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
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
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
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
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
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 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
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
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
1 - 100 of 120 matches
Mail list logo
