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 = &pdev->dev.coherent_dma_mask;
Please use dma_coerce_mask_and_coherent() here
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
ugust/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(+
MA related
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..ff
-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 = &pdev->dev.coherent_dma_mask;
+ /*
+* PTA and MTLB can have 40 bit b
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 for
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
ugust/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 coheren
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
r_dev()
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/d
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
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]
> 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 = 0x960
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
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
cb=8
[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 inser
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.
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=0xf98
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
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 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
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 a
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
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
| 1 -
Acked-by: Michael Walle
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 panel
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 parsing
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 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
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
. 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
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 mediatek-drm.10
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
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 pipeline
. 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
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 co
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
. 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
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
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
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
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?
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
> 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
; DMT028VGHMCMI-1A - ST7701
> DMT028VGHMCMI-1D - ILI9806E
>
> Signed-off-by: Marek Vasut
Reviewed-by: Michael Walle
-michael
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
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
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 --
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
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
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
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
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
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 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
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
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
: 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
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
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
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
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 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
.
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 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
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
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
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
>
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
> 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
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
+ 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
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
> 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
>> >> > 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)
>>
[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
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
>> >> > 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)
>>
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
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
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
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
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
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
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_
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
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 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
1 - 100 of 162 matches
Mail list logo
