From: Tomi Valkeinen
Improve the DSI shutdown procedure by clearing various bits that were
set while enabling the DSI output. There has been no clear issues caused
by these, but it's safer to ensure that the features are disabled at the
start of the next DSI enable.
Signed-off-by:
From: Tomi Valkeinen
Rename LVDS pclk enable/disable functions to match what we use for DSI.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 4 ++--
drivers/gpu/drm/rcar-du/rcar_lvds.c| 4 ++--
drivers/gpu/drm/rcar-du/rcar_lvds.h| 10 +-
3 files
On 22/08/2022 16:20, Laurent Pinchart wrote:
Hi Tomi,
Thank you for the patch.
On Mon, Aug 22, 2022 at 04:05:10PM +0300, Tomi Valkeinen wrote:
From: Tomi Valkeinen
Improve the DSI shutdown procedure by clearing various bits that were
set while enabling the DSI output. There has been no
On 22/08/2022 16:52, Laurent Pinchart wrote:
Hi Tomi,
Thank you for the patch.
On Mon, Aug 22, 2022 at 04:05:12PM +0300, Tomi Valkeinen wrote:
From: Tomi Valkeinen
Rename LVDS pclk enable/disable functions to match what we use for DSI.
I'd explain here the rationale for the new
Hi,
On 22/08/2022 16:25, Biju Das wrote:
Hi Tomi,
Thanks for the patch.
Subject: [PATCH v2 1/4] drm: rcar-du: dsi: Properly stop video mode TX
From: Tomi Valkeinen
The driver does not explicitly stop the video mode transmission when
disabling the output. While this doesn't seem
On 22/08/2022 17:05, Laurent Pinchart wrote:
On Mon, Aug 22, 2022 at 04:49:02PM +0300, Tomi Valkeinen wrote:
On 22/08/2022 16:20, Laurent Pinchart wrote:
Hi Tomi,
Thank you for the patch.
On Mon, Aug 22, 2022 at 04:05:10PM +0300, Tomi Valkeinen wrote:
From: Tomi Valkeinen
Improve the DSI
Changes to v2:
- Move the LVDS patch to the beginning and improve the patch desc.
- Write 0 to registers in rcar_mipi_dsi_shutdown instead of just
clearing a bit.
- Fix function names in "fix DSI enable & disable sequence" patch desc.
- Add "drm: rcar-du: dsi: Fix VCLKSET
From: Tomi Valkeinen
The driver does not explicitly stop the video mode transmission when
disabling the output. While this doesn't seem to be causing any issues,
lets follow the steps described in the documentation and add a
rcar_mipi_dsi_stop_video() which stop the video mode transmission.
From: Tomi Valkeinen
Improve the DSI shutdown procedure by clearing various bits that were
set while enabling the DSI output. There has been no clear issues caused
by these, but it's safer to ensure that the features are disabled at the
start of the next DSI enable.
Signed-off-by:
From: Tomi Valkeinen
rcar_mipi_dsi_startup() writes correct values to VCLKSET, but as it uses
or-operation to add the new values to the current value in the register,
it should first make sure the fields are cleared.
Do this by using rcar_mipi_dsi_write() to write the VCLKSET_CKEN bit to
From: Tomi Valkeinen
The DU driver uses the rcar_lvds_clk_enable() and
rcar_lvds_clk_disable() functions enable or disable the pixel clock
generated by the LVDS encoder, as it requires that clock for proper DU
operation. Rename the functions by replacing "clk" with "pclk" to
On 22/08/2022 17:45, Laurent Pinchart wrote:
Hi Tomi,
Thank you for the patch.
On Mon, Aug 22, 2022 at 05:34:01PM +0300, Tomi Valkeinen wrote:
From: Tomi Valkeinen
rcar_mipi_dsi_startup() writes correct values to VCLKSET, but as it uses
or-operation to add the new values to the current
From: Tomi Valkeinen
rcar_mipi_dsi_startup() writes correct values to VCLKSET, but as it uses
or-operation to add the new values to the current value in the register,
it should first make sure the fields are cleared.
Do this by using rcar_mipi_dsi_write() to write the VCLKSET register
with a
On 22/08/2022 17:34, Tomi Valkeinen wrote:
+struct drm_atomic_state;
+struct drm_bridge;
+
+#if IS_ENABLED(CONFIG_DRM_RCAR_MIPI_DSI)
+void rcar_mipi_dsi_pclk_enable(struct drm_bridge *bridge,
+ struct drm_atomic_state *state);
+void rcar_mipi_dsi_pclk_disable(struct
Changes to v3:
- Fix LVDS function renames wrt. export symbol.
- Fix missing static inline
- Use rcar_mipi_dsi_write for VCLKSET writes
Tomi
Tomi Valkeinen (5):
drm: rcar-du: lvds: Rename pclk enable/disable functions
drm: rcar-du: dsi: Properly stop video mode TX
drm: rcar-du: dsi
From: Tomi Valkeinen
The driver does not explicitly stop the video mode transmission when
disabling the output. While this doesn't seem to be causing any issues,
lets follow the steps described in the documentation and add a
rcar_mipi_dsi_stop_video() which stop the video mode transmission.
From: Tomi Valkeinen
rcar_mipi_dsi_startup() writes correct values to VCLKSET, but as it uses
or-operation to add the new values to the current value in the register,
it should first make sure the fields are cleared.
Do this by using rcar_mipi_dsi_write() to write the VCLKSET register
with a
From: Tomi Valkeinen
Improve the DSI shutdown procedure by clearing various bits that were
set while enabling the DSI output. There has been no clear issues caused
by these, but it's safer to ensure that the features are disabled at the
start of the next DSI enable.
Signed-off-by:
From: Tomi Valkeinen
The DU driver uses the rcar_lvds_clk_enable() and
rcar_lvds_clk_disable() functions enable or disable the pixel clock
generated by the LVDS encoder, as it requires that clock for proper DU
operation. Rename the functions by replacing "clk" with "pclk" to
From: Tomi Valkeinen
The rcar crtc depends on the clock provided from the rcar DSI bridge.
When the DSI bridge is disabled, the clock is stopped, which causes the
crtc disable to timeout.
Also, while I have no issue with the enable, the documentation suggests
to enable the DSI before the crtc
ort (non-eDP) mode
drm/bridge: ti-sn65dsi86: Implement bridge connector operations
Tomi Valkeinen (2):
drm/bridge: ti-sn65dsi86: check AUX errors better
drm/bridge: ti-sn65dsi86: Reject modes with too large blanking
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 77 +--
From: Tomi Valkeinen
The driver does not check AUX_IRQ_STATUS_NAT_I2C_FAIL bit at all when
sending AUX transfers, which leads to the driver not returning an error.
Add the check.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 5 +
1 file changed, 5 insertions
: Laurent Pinchart
Reworked to set bridge type based on the next bridge/connector.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
Reviewed-by: Douglas Anderson
Signed-off-by: Tomi Valkeinen
--
Changes since v1/RFC:
- Rebased on top of "drm/bridge: ti-sn65dsi86: swit
the comments, they've had issues with eDP panels and HPD. So better be
safe and only enable them for DP for now.
Signed-off-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
Signed-off-by: Tomi Valkeinen
---
Changes since v1:
- The connector .get_modes() operation doesn't rely on ED
From: Tomi Valkeinen
The blanking related registers are 8 bits, so reject any modes
with larger blanking periods.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti
From: Tomi Valkeinen
The rcar crtc depends on the clock provided from the rcar DSI bridge.
When the DSI bridge is disabled, the clock is stopped, which causes the
crtc disable to timeout.
Also, while I have no issue with the enable, the documentation suggests
to enable the DSI before the crtc
From: Tomi Valkeinen
The rcar crtc depends on the clock provided from the rcar DSI bridge.
When the DSI bridge is disabled, the clock is stopped, which causes the
crtc disable to timeout.
Also, while I have no issue with the enable, the documentation suggests
to enable the DSI before the crtc
not valid, this patch is ok and:
Reviewed-by: Tomi Valkeinen
Tomi
Signed-off-by: Devarsh Thakkar
---
drivers/gpu/drm/tidss/tidss_dispc.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index 60
Hi,
On 14/04/2022 09:14, Xiaomeng Tong wrote:
The bug is here:
bus_flags = connector->display_info.bus_flags;
The list iterator 'connector-' will point to a bogus position containing
HEAD if the list is empty or no element is found. This case must
be checked before any use of the iterat
ch/arm64/boot/dts/ti/k3-am65-main.dtsi | 6 --
2 files changed, 11 insertions(+), 5 deletions(-)
Reviewed-by: Tomi Valkeinen
How are you planning to use the common1 area?
Tomi
On 14/03/2022 13:37, Devarsh Thakkar wrote:
Soft reset the display subsystem controller on startup and wait for
the reset to complete. This helps the scenario where display was
already in use by some other core before the linux was booted.
Signed-off-by: Devarsh Thakkar
---
drivers/gpu/drm/ti
Hi Doug,
On 29/08/2022 20:23, Doug Anderson wrote:
Hi,
On Wed, Aug 24, 2022 at 6:00 AM Tomi Valkeinen
wrote:
From: Tomi Valkeinen
The blanking related registers are 8 bits, so reject any modes
with larger blanking periods.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/ti
Hi,
On 29/08/2022 20:38, Doug Anderson wrote:
Hi,
On Wed, Aug 24, 2022 at 6:00 AM Tomi Valkeinen
wrote:
From: Laurent Pinchart
Implement the bridge connector-related .get_edid() and .detect()
operations, and report the related bridge capabilities and type.
These ops are only added for DP
Hi,
On 29/08/2022 20:15, Doug Anderson wrote:
Hi,
On Wed, Aug 24, 2022 at 6:01 AM Tomi Valkeinen
wrote:
From: Tomi Valkeinen
The driver does not check AUX_IRQ_STATUS_NAT_I2C_FAIL bit at all when
sending AUX transfers,
It doesn't? What about a few lines down from where your
Hi,
On 30/08/2022 17:55, Doug Anderson wrote:
Hi,
On Tue, Aug 30, 2022 at 2:00 AM Tomi Valkeinen
wrote:
Hi,
On 29/08/2022 20:38, Doug Anderson wrote:
Hi,
On Wed, Aug 24, 2022 at 6:00 AM Tomi Valkeinen
wrote:
From: Laurent Pinchart
Implement the bridge connector-related .get_edid
On 30/08/2022 21:08, Ivaylo Dimitrov wrote:
flags &= ~OMAP_BO_TILED_MASK;
flags |= 0x0008;
flags |= OMAP_BO_WC;
bo = omap_bo_new(dev, size, flags);
As you can see we use 0x0008 (OMAP_BO_MEM_CONTIG) unconditionally.
This was a hack added since even no
From: Tomi Valkeinen
The front and back porch registers are 8 bits, and pulse width registers
are 15 bits, so reject any modes with larger periods.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 23 +++
1 file changed, 23 insertions(+)
diff
: Laurent Pinchart
Reworked to set bridge type based on the next bridge/connector.
Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
Reviewed-by: Douglas Anderson
Signed-off-by: Tomi Valkeinen
--
Changes since v1/RFC:
- Rebased on top of "drm/bridge: ti-sn65dsi86: swit
From: Laurent Pinchart
Implement the bridge connector-related .get_edid() and .detect()
operations for full DP mode, and report the related bridge capabilities
and type.
Signed-off-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
Signed-off-by: Tomi Valkeinen
Reviewed-by: Douglas Anderson
bout eDP, detect and get_edid from the desc of
"Implement bridge connector operations"
Tomi
Laurent Pinchart (2):
drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode
drm/bridge: ti-sn65dsi86: Implement bridge connector operations for DP
Tomi Valkeinen (1):
drm/bridge: t
Hi,
On 23/02/2022 19:02, Kieran Bingham wrote:
Quoting Laurent Pinchart (2022-02-23 16:25:28)
Hello,
On Wed, Feb 23, 2022 at 04:17:22PM +, Kieran Bingham wrote:
Quoting Laurent Pinchart (2021-12-29 23:44:29)
On Sat, Dec 25, 2021 at 09:31:51AM +0300, Nikita Yushchenko wrote:
Hotplug even
On 31/08/2022 16:02, Tomi Valkeinen wrote:
Hi,
On 23/02/2022 19:02, Kieran Bingham wrote:
Quoting Laurent Pinchart (2022-02-23 16:25:28)
Hello,
On Wed, Feb 23, 2022 at 04:17:22PM +, Kieran Bingham wrote:
Quoting Laurent Pinchart (2021-12-29 23:44:29)
On Sat, Dec 25, 2021 at 09:31:51AM
On 17/05/2022 08:02, Guo Zhengkui wrote:
Fix the following coccicheck warning:
drivers/gpu/drm/omapdrm/dss/dispc.c:2454:21-22: WARNING opportunity for max()
Signed-off-by: Guo Zhengkui
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 22/07/2022 17:43, Liang He wrote:
In dss_init_ports() and __dss_uninit_ports(), we should call
of_node_put() for the reference returned by of_graph_get_port_by_id()
in fail path or when it is not used anymore.
Fixes: 09bffa6e5192 ("drm: omap: use common OF graph helpers")
Signed-off-by: Liang
On 24/08/2022 16:04, Jilin Yuan wrote:
Delete the redundant word 'to'.
Signed-off-by: Jilin Yuan
---
drivers/gpu/drm/tidss/tidss_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tidss/tidss_kms.c
b/drivers/gpu/drm/tidss/tidss_kms.c
index 666e527a0a
On 25/08/2022 19:26, Andrew Davis wrote:
While a scatter-gather table having only 1 entry does imply it is
contiguous, it is a logic error to assume the inverse. Tables can have
more than 1 entry and still be contiguous. Use a proper check here.
Signed-off-by: Andrew Davis
---
Changes from v1:
Hi,
On 29/04/2022 21:51, Dmitry Baryshkov wrote:
From all the drivers using drm_bridge_connector only iMX/dcss and OMAP
DRM driver do a proper work of calling
drm_bridge_connector_en/disable_hpd() in right places. Rather than
teaching each and every driver how to properly handle
drm_bridge_conn
On 29/04/2022 21:51, Dmitry Baryshkov wrote:
Now as all drivers stopped calling drm_bridge_connector_enable_hpd() and
drm_bridge_connector_disable_hpd() it is safe to remove them complelely.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_bridge_connector.c | 25 --
, let's allocate the
struct with kmalloc instead.
Compile-tested only.
Signed-off-by: Tomi Valkeinen
Reported-by: kernel test robot
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/omapdr
Fix doc related warnings seen with W=1: the function names have changed
but the docs have not been changed accordingly.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem.c | 2 +-
drivers/gpu/drm/omapdrm/omap_irq.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions
On 15/09/2022 21:49, Arnd Bergmann wrote:
On Thu, Sep 15, 2022, at 8:17 PM, kernel test robot wrote:
Hi Arnd,
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 3245cb65fd91cd514801bf91f5a3066d562f0ac4
commit: 3d427228f7370894680580fcd0381c0349624fa1 ARM: ixp
Hi,
On 19/07/2022 11:08, Aradhya Bhatia wrote:
The AM625 DSS peripheral supports 2 OLDI TXes which can work to enable 2
duplicated displays of smaller resolutions or enable a single Dual-Link
display with a higher resolution (1920x1200).
Configure the necessary register to enable the different
On 22/07/2022 19:16, Nishanth Menon wrote:
On 17:28-20220720, Rob Herring wrote:
On the bridge side R0->R2, G0->G1, B0->B2 would be tied to ground.
The bridge sees 24bits of data, but the lsb's are always zero.
Unless the bridge ignores the LSBs, that's not the right way to do 16 to
24 bit. T
On 27/07/2022 16:22, Tomi Valkeinen wrote:
Hi,
On 19/07/2022 11:08, Aradhya Bhatia wrote:
The AM625 DSS peripheral supports 2 OLDI TXes which can work to enable 2
duplicated displays of smaller resolutions or enable a single Dual-Link
display with a higher resolution (1920x1200).
Configure
On 19/07/2022 11:08, Aradhya Bhatia wrote:
The OLDI TX(es) require a serial clock which is 7 times the pixel clock
of the display panel. When the OLDI is enabled in DSS, the pixel clock
input of the corresponding videoport gets a divided-by 7 value of the
requested clock.
For the am625-dss, the
On 19/07/2022 11:08, Aradhya Bhatia wrote:
The 2 OLDI TXes in the AM625 SoC can be synced together to output a 2K
resolution video.
Add support in the driver for the discovery of such a dual mode
connection on the OLDI video port, using the values of "ti,oldi-mode"
property.
Signed-off-by: Arad
On 19/07/2022 11:08, Aradhya Bhatia wrote:
Add "ti,oldi-mode" property to indicate the tidss driver the OLDI output
mode. The 2 OLDI TXes on am625-dss allow a 3 different types of panel
connections with the board.
1. Single Link / Single Mode on OLDI TX 0 OR 1.
2. Single Link / Duplicate Mode
On 28/07/2022 11:49, Aradhya Bhatia wrote:
Hi Tomi,
On 28-Jul-22 12:16, Tomi Valkeinen wrote:
On 27/07/2022 16:22, Tomi Valkeinen wrote:
Hi,
On 19/07/2022 11:08, Aradhya Bhatia wrote:
The AM625 DSS peripheral supports 2 OLDI TXes which can work to
enable 2
duplicated displays of smaller
On 28/07/2022 14:03, Tomi Valkeinen wrote:
On 19/07/2022 11:08, Aradhya Bhatia wrote:
The 2 OLDI TXes in the AM625 SoC can be synced together to output a 2K
resolution video.
Add support in the driver for the discovery of such a dual mode
connection on the OLDI video port, using the values of
e similar DSS functionality as we have for
AM65x.
So, I think these two patches could be merged, or we could wait a bit
until the OLDI situation becomes more clear. Up to you. In any case, for
both patches:
Reviewed-by: Tomi Valkeinen
Tomi
On 19/07/2022 11:08, Aradhya Bhatia wrote:
Add support to enable and read the dss port properties.
The "ti,oldi-mode" property indicates the tidss driver how many OLDI
TXes are enabled as well as which mode do they need to be connected in.
The "ti,rgb565_to_888" is a special property that force
On 29/07/2022 06:56, Aradhya Bhatia wrote:
On 28-Jul-22 15:35, Tomi Valkeinen wrote:
On 19/07/2022 11:08, Aradhya Bhatia wrote:
The OLDI TX(es) require a serial clock which is 7 times the pixel clock
of the display panel. When the OLDI is enabled in DSS, the pixel clock
input of the
Hi JJ,
On 10/10/2019 14:59, Jean-Jacques Hiblot wrote:
This would give us a WARN_ON() if the pin/unpin calls are unbalanced.
Proposed-by: Laurent Pinchart
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem.c | 44
On 10/10/2019 12:25, Tomi Valkeinen wrote:
Hi Andrzej,
On 10/10/2019 12:19, Andrzej Hajda wrote:
On 24.09.2019 15:17, Tomi Valkeinen wrote:
max_tu_symbol was programmed to TU_SIZE_RECOMMENDED - 1, which is not
what the spec says. The spec says:
roundup ((input active video bandwidth in bytes
em_unpin if the buffer being unpinned is
contiguous.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index e518d93ca6df..d08ae95ecc0a 100644
--- a/
The LCD panel on AM4 GP EVMs and ePOS boards seems to be
osd070t1718-19ts. The current dts files say osd057T0559-34ts. Possibly
the panel has changed since the early EVMs, or there has been a mistake
with the panel type.
Update the DT files accordingly.
Signed-off-by: Tomi Valkeinen
---
arch
roller driver should be able to deduce the sync drive edge from the
pixdata drive edge. Are they usually the same? I have no idea...
Tomi
Tomi Valkeinen (3):
ARM: dts: am437x-gp/epos-evm: fix panel compatible
ARM: dts: am437x-gp/epos-evm: drop unused panel timings
drm/panel: simple: fix o
fixes this issue.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/panel/panel-simple.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 5d487686d25c..0784536ae6af 100644
--- a/drivers/gpu/drm
panel-simple now handled panel osd070t1718-19ts, and we no longer need
the panel timings in the DT file. So remove them.
Signed-off-by: Tomi Valkeinen
---
arch/arm/boot/dts/am437x-gp-evm.dts | 16
arch/arm/boot/dts/am43x-epos-evm.dts | 16
2 files changed, 32
Hi zhengbin,
On 18/11/2019 14:07, zhengbin wrote:
zhengbin (4):
drm/omap: dss: Use PTR_ERR_OR_ZERO() to simplify code in
hdmi_audio_register
drm/omap: dss: Use PTR_ERR_OR_ZERO() to simplify code in
hdmi4_core_init
drm/omap: dss: Use PTR_ERR_OR_ZERO() to simplify code in
h
gt; impossible to buy a chip with tegra host1x and ompadrm on the same
> SoC, there's no problem here.
>
> Signed-off-by: Daniel Vetter
> Cc: Tomi Valkeinen
> ---
> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 21 -
> 1 file changed, 21 deletions(-
On 17/11/2019 04:39, Sebastian Reichel wrote:
The standard binding for DSI requires, that the channel number
of the panel is encoded in DT. This adds the channel number in
all OMAP3-5 boards, in preparation for using common infrastructure.
Signed-off-by: Sebastian Reichel
---
.../devicetree/b
On 19/11/2019 01:05, Tony Lindgren wrote:
* Sebastian Reichel [191117 07:11]:
We can simply use the atomic helper for
handling the dirtyfb callback.
...
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
-void omap_crtc_flush(struct drm_crtc *crtc)
+static voi
On 11/12/2019 18:53, Tony Lindgren wrote:
* Laurent Pinchart [191202 13:05]:
Hi Tomi,
Thank you for the patch.
On Thu, Nov 14, 2019 at 11:39:49AM +0200, Tomi Valkeinen wrote:
panel-simple now handled panel osd070t1718-19ts, and we no longer need
the panel timings in the DT file. So remove
On 13/12/2019 12:42, Laurent Pinchart wrote:
I think the correct way would be to have DRM framework understand that we have
two displays, which
are mutually exclusive, and the display pipeline drivers would have the means
to switch the gpio.
And that the display setup could be communicated pro
Hi Daniel,
On 13/12/2019 12:30, Daniel Vetter wrote:
+DRM DRIVERS FOR TI KEYSTONE
+M: Jyri Sarha
+M: Tomi Valkeinen
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+F: drivers/gpu/drm/tidss/
+F: Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml
+F
On 13/12/2019 13:42, Laurent Pinchart wrote:
Hi Tomi,
On Fri, Dec 13, 2019 at 12:56:31PM +0200, Tomi Valkeinen wrote:
On 13/12/2019 12:42, Laurent Pinchart wrote:
I think the correct way would be to have DRM framework understand that we have
two displays, which
are mutually exclusive, and
On 12/12/2019 19:31, Tony Lindgren wrote:
* Tony Lindgren [191212 17:21]:
Hi,
* Tomi Valkeinen [191125 05:11]:
Add HDMI support for AM437x GP EVM. The HDMI uses SiI9022 HDMI encoder,
and is mutually exclusive with the LCD. The choice between LCD and HDMI
is made by booting either with
On 13/12/2019 14:28, Laurent Pinchart wrote:
So... In the DT file, we would have multiple endpoints in the same output port
in DSS, one going to
the panel, one to the SiI9022? omapdrm could then create two encoders, one
abstracting the DPI
output and the connection to the panel, one abstractin
On 12/12/2019 19:31, Tony Lindgren wrote:
Anyways, I'm applying the changes to dra76-evm am57xx-idk-common
into omap-for-v5.6/dt as they have no GPIO pin limitation.
Thanks!
I'd like to hear comments from folks on the first two though.
Just to summarize the discussion, let's drop the first
++
3 files changed, 220 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/ti-tpd12s015.c
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
insertions(+), 1 deletion(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https
chart
---
drivers/gpu/drm/omapdrm/dss/dss.c | 43 +++
1 file changed, 26 insertions(+), 17 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Hel
On 11/12/2019 00:57, Laurent Pinchart wrote:
Display connectors are modelled in DT as a device node, but have so far
been handled manually in several bridge drivers. This resulted in
duplicate code in several bridge drivers, with slightly different (and
thus confusing) logics.
In order to fix th
On 11/12/2019 00:57, Laurent Pinchart wrote:
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
con
/drm/omapdrm/dss/hdmi4_core.c | 59 +++
drivers/gpu/drm/omapdrm/dss/hdmi4_core.h | 4 +-
3 files changed, 73 insertions(+), 84 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4
/drm/omapdrm/dss/hdmi5_core.c | 48 +++--
drivers/gpu/drm/omapdrm/dss/hdmi5_core.h | 5 +-
3 files changed, 65 insertions(+), 77 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4
:
- Unregister bridge if output initialisation fails
---
drivers/gpu/drm/omapdrm/dss/hdmi.h | 3 ++
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 78 ++---
2 files changed, 75 insertions(+), 6 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy
:
- Unregister bridge if output initialisation fails
---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 79 ++---
1 file changed, 73 insertions(+), 6 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus
On 18/12/2019 03:45, Laurent Pinchart wrote:
+ dev_info(&pdev->dev,
+"Found %s display connector '%s' %s DDC bus and %s HPD GPIO (ops
0x%x)\n",
+drm_get_connector_type_name(conn->bridge.type),
+conn->label ? conn->label : "",
+
On 11/12/2019 00:57, Laurent Pinchart wrote:
The TI OP362 is an analog video amplifier controlled through a GPIO. Add
support for it to the simple-bridge driver.
Noticed just now, you have "OP" instead of "OPA" above and in the subject.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22,
On 18/12/2019 04:03, Laurent Pinchart wrote:
Hopefully we can soon have this series landed so we can start
working on top of the new bridge/connector handling.
I assume it will be applied direct to drm-misc-next, so we do not
have to wait extra time to get it.
Tomi, how would you like to proc
.set_infoframe() and .set_hdmi_mode() handling in the commit
message
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 201 +++-
1 file changed, 106 insertions(+), 95 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180
.set_infoframe() and .set_hdmi_mode() handling in the commit
message
---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 204 +++-
1 file changed, 106 insertions(+), 98 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180
On 11/12/2019 00:57, Laurent Pinchart wrote:
The HDMI4 encoder is transitioning to the drm_bridge API, implement the
last missing operation.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 10 ++
1 file changed, 10 insertions(+)
Reviewed-by: Tomi
--
2 files changed, 29 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
---
Changes since v2:
- Unregister bridge if output initialisation fails
---
drivers/gpu/drm/omapdrm/dss/venc.c | 247 +++--
1 file changed, 163 insertions(+), 84 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki
deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freed
everything working.
Other than that:
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel
On 18/12/2019 16:46, Laurent Pinchart wrote:
Hi Tomi,
On Wed, Dec 18, 2019 at 09:07:52AM +0200, Tomi Valkeinen wrote:
On 18/12/2019 04:03, Laurent Pinchart wrote:
Hopefully we can soon have this series landed so we can start
working on top of the new bridge/connector handling.
I assume it
701 - 800 of 3844 matches
Mail list logo
