From: Jyri Sarha
The core.c just for registering the drivers is kind of useless. Let's
get rid of it and register the dss drivers in dss.c.
Signed-off-by: Jyri Sarha
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/Makefile | 2 +-
drivers/gp
/omap: hdmi4: fix use of uninitialized var
Fixed the issues pointed out by Laurent.
Tomi
Alejandro Hernandez (1):
drm/omap: tweak HDMI DDC timings
Jyri Sarha (1):
drm/omap: dss: move platform_register_drivers() to dss.c and remove
core.c
Tomi Valkeinen (5):
drm/omap: drop unneeded
ff-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 3c9315b17ef2..c19e0af33013 100644
--- a/dr
the error is not observed
Signed-off-by: Alejandro Hernandez
Signed-off-by: Tomi Valkeinen
Acked-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
b/drivers/gpu/drm/o
Hi Laurent,
On 07/07/2019 21:18, 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 or
On 30/09/2019 16:17, Adam Ford wrote:
It looks like it's unhappy that its trying to get one frequency and
getting something different instead.
[ 10.014099] WARNING: CPU: 0 PID: 111 at
drivers/gpu/drm/omapdrm/dss/dss.c:655 dss_set_fck_rate+0x70/0x90
[omapdss]
[ 10.014129] clk rate mismatch:
On 30/09/2019 17:12, Adam Ford wrote:
I don't know the implications, so if the people from TI say stick with
16, I'm fine with that, but at least there is some evidence that it
can be higher than 16, but lower than 32.
Sorry for all the spam, but I moved both of them to 31 from 32, and it
als
On 30/09/2019 17:20, Tomi Valkeinen wrote:
Let's see what Tero says, but yeah, something is odd here. I expected
the max divider to be 16 with Tero's patch, but I don't see it having
that effect. I can get the div to 31.
You can see this from the clock register 0x48004e40
On 30/09/2019 20:48, Tero Kristo wrote:
Hmmh, after some testing, it seems there is bad stuff happening with the
divider clock implementation, I am re-working it as of now. Basically
what is wrong is that with a divider max value of say 16, the driver
attempts to craft the max value into a mas
On 20/08/2019 04:16, Laurent Pinchart wrote:
@@ -,7 +1113,7 @@ int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi, struct
drm_encoder *encoder)
{
int ret;
- ret = drm_bridge_attach(encoder, &dsi->bridge, NULL);
+ ret = drm_bridge_attach(encoder, &dsi->bridge, NULL, true);
Th
On 01/10/2019 11:12, Tero Kristo wrote:
On 01/10/2019 08:07, Tomi Valkeinen wrote:
On 30/09/2019 20:48, Tero Kristo wrote:
Hmmh, after some testing, it seems there is bad stuff happening with
the divider clock implementation, I am re-working it as of now.
Basically what is wrong is that with
On 01/10/2019 16:06, Adam Ford wrote:
Do you want me to push a patch to remove the
CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK hack once these patches have been
posted? It seems like the divider fix eliminates the need for this
hack.
No, the point of OMAP2_DSS_MIN_FCK_PER_PCK was never to work around
d
files to limit the divider correctly,
but as the DSS driver also needs to know the maximum divider to be able
to iteratively find good rates, we also need to do the fix in the DSS
driver.
Signed-off-by: Tomi Valkeinen
Cc: Adam Ford
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/omapdrm/dss/dss.c
On 01/10/2019 23:08, Laurent Pinchart wrote:
Many drivers print an info message at probe time when everything goes
fine, to inform about the device that has been succesfully probed. Do
you think this is overkill and a dev_dbg() would be better ?
Ah, I didn't realize this is a "probed" message.
Hi Sam,
On 20/08/2019 13:37, Sam Ravnborg wrote:
@@ -123,6 +123,18 @@ static void panel_bridge_post_disable(struct drm_bridge
*bridge)
drm_panel_unprepare(panel_bridge->panel);
}
+static int panel_bridge_get_modes(struct drm_bridge *bridge,
+ struc
On 19/11/2019 16:32, Tony Lindgren wrote:
We haven't had omap_gem_op_finish() in the kernel for some years now...
Shouldn't a normal page flip, or if doing single-buffering, using the
dirtyfb ioctl, do the job?
It does not seem to happen with the old pvr-omap4 related patches
and whatever gle
On 19/11/2019 17:06, Tony Lindgren wrote:
The userspace apps need to do this. If they're using single-buffering, then
using the dirtyfb ioctl should do the trick, after the SGX has finished
drawing.
Sounds like that's not happening.
But why would the userspace app need to know this might be n
-epos-evm-hdmi.dtb.
Signed-off-by: Jyri Sarha
Signed-off-by: Tomi Valkeinen
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/am43x-epos-evm-hdmi.dts | 120 ++
2 files changed, 121 insertions(+)
create mode 100644 arch/arm/boot/dts/am43x-epos-evm
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 am437x-gp-evm.dtb or
am437x-gp-evm-hdmi.dtb.
Signed-off-by: Tomi Valkeinen
---
arch/arm/boot/dts/Makefile
Add DRA76 EVM HDMI output for the base board.
Signed-off-by: Tomi Valkeinen
---
arch/arm/boot/dts/dra76-evm.dts | 66 +
1 file changed, 66 insertions(+)
diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts
index 1fb6f13fb5e2
AM571x/AM572x/AM574x IDK base boards have HDMI output. Add DT nodes to
am57xx-idk-common.dtsi to enable HDMI.
Signed-off-by: Tomi Valkeinen
---
arch/arm/boot/dts/am57xx-idk-common.dtsi | 59
1 file changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-idk
Hi Tony, Thierry, Laurent,
Any thoughts on the below points?
I think yet another option is to write some omap boot time quirks code, which looks at the DT data,
and changes the panel compatible string (for 1), and removes the timings node (for 2).
Tomi
On 14/11/2019 11:39, Tomi Valkeinen
Hi Tony,
On 27/11/2019 17:45, Tony Lindgren wrote:
Interestingly, the actual panel at least on my EVMs and ePOSes is not
osd057T0559-34ts, but osd070t1718-19ts. Also, I was unable to find any
information about osd057T0559-34ts. I don't know the history with this,
so it is possible that the earl
On 02/12/2019 14:36, Laurent Pinchart wrote:
Hi Tomi,
Thank you for the patch.
On Thu, Nov 14, 2019 at 10:03:43AM +0200, Tomi Valkeinen wrote:
cec4fa7511ef7a73eb635834e9d85b25a5b47a98 ("drm/omap: use refcount API to
track the number of users of dma_addr") changed omap_gem.c to use
r
Hi Andrey,
On 19/06/2019 08:27, Andrey Smirnov wrote:
@@ -748,22 +748,19 @@ static int tc_set_video_mode(struct tc_data *tc,
static int tc_wait_link_training(struct tc_data *tc)
{
- u32 timeout = 1000;
u32 value;
int ret;
- do {
- udelay(1);
-
On 04/12/2019 20:27, Tomi Valkeinen wrote:
Hi Andrey,
On 19/06/2019 08:27, Andrey Smirnov wrote:
@@ -748,22 +748,19 @@ static int tc_set_video_mode(struct tc_data *tc,
static int tc_wait_link_training(struct tc_data *tc)
{
- u32 timeout = 1000;
u32 value;
int ret;
- do
+
1 file changed, 32 insertions(+)
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.freedeskto
leep times are set to
such values that they result in multiple loops, but not too many (say,
5-10 loops). The timeouts were all increased to 100ms, which should be
more than enough for all of these, but in case of bad errors, shouldn't
stop the driver as multi-second timeouts could do.
Sign
(Cc'ing Daniel for the last paragraph)
On 09/12/2019 07:08, Andrey Smirnov wrote:
Presently, the driver code artificially limits test pattern mode to a
single pattern with fixed color selection. It being a kernel module
parameter makes switching "test pattern" <-> "proper output" modes
on-the-fl
On 09/12/2019 16:38, Andrey Smirnov wrote:
On Mon, Dec 9, 2019 at 1:38 AM Tomi Valkeinen wrote:
(Cc'ing Daniel for the last paragraph)
On 09/12/2019 07:08, Andrey Smirnov wrote:
Presently, the driver code artificially limits test pattern mode to a
single pattern with fixed color sele
On 21/08/2019 23:26, Aaro Koskinen wrote:
Hi,
On Wed, Aug 21, 2019 at 09:32:26PM +0300, Laurent Pinchart wrote:
When refactoring port lookup for DSS outputs, commit d17eb4537a7e
("drm/omap: Factor out common init/cleanup code for output devices")
incorrectly hardcoded usage of DT port 0. This b
Hi,
On 20/08/2019 04:16, Laurent Pinchart wrote:
In preparation of adding DRM bridge support to the hdmi4 encoder code,
rework the EDID read to isolate data read.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 94 +++-
drivers/gpu/drm/omap
On 20/08/2019 04:17, Laurent Pinchart wrote:
Move the omap_dss_device .set_timings(), .enable() and .disable()
operations to the drm_bridge functions. As the drm_bridge for the HDMI
encoder is unconditionally registered and attached, those operations
will be called at the appropriate time.
Signe
Hi Laurent,
On 20/08/2019 04:16, Laurent Pinchart wrote:
> The patches can be found at
>
> git://linuxtv.org/pinchartl/media.git omapdrm/bridge/devel
I took your branch, booted AM5 EVM (I see you had the hack dts patch in your
branch), and:
insmod nfs/work/linux/drivers/media/cec/cec.ko
ng to normal operation WILL. This is
done so:
a) we can isolate and verify (e)DP link functionality by switching to
one of the test patters
b) trigger a link re-establishment by switching back to normal mode
Signed-off-by: Andrey Smirnov
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Tomi Valkein
.type = DRM_MODE_CONNECTOR_Composite,
+ },
I have to say I'm pretty clueless about the analog TV, but OMAP DSS
supports also s-video outputs. But I don't know if OPA362 can be used
with s-video, or does it dictate composite.
In any case,
Reviewed-by: Tomi Valkeinen
Tomi
--
-- /dev/null
+++ b/drivers/gpu/drm/bridge/ti-tpd12s015.c
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TPD12S015 HDMI ESD protection & level shifter chip driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated
+ * Author: Tomi Valkeinen
+ */
You may want to ment
On 07/07/2019 21:18, Laurent Pinchart wrote:
The drmP.h header is deprecated, replace it with the headers
specifically needed by the tfp410 driver. While at it, replace the DRM
print macros with dev_info() and dev_err() instead of including
drm_print.h
Signed-off-by: Laurent Pinchart
---
driv
On 26/08/2019 16:51, Laurent Pinchart wrote:
Hi Tomi,
On Mon, Aug 26, 2019 at 03:15:23PM +0300, Tomi Valkeinen wrote:
On 20/08/2019 04:16, Laurent Pinchart wrote:
The patches can be found at
git://linuxtv.org/pinchartl/media.git omapdrm/bridge/devel
I took your branch, booted AM5
On 20/08/2019 04:16, Laurent Pinchart wrote:
Now that a driver is available for display connectors, replace the
manual connector handling code with usage of the DRM bridge API. The
tfp410 driver doesn't deal with the display connector directly anymore,
but still delegates drm_connector operations
On 27/08/2019 12:29, Laurent Pinchart wrote:
Hi Tomi,
On Tue, Aug 27, 2019 at 10:34:59AM +0300, Tomi Valkeinen wrote:
On 26/08/2019 16:51, Laurent Pinchart wrote:
On Mon, Aug 26, 2019 at 03:15:23PM +0300, Tomi Valkeinen wrote:
On 20/08/2019 04:16, Laurent Pinchart wrote:
The patches can be
On 25/08/2019 23:23, Ilia Mirkin wrote:
You'll probably get a more detailed reply during the week, but for now
have a look at the "link-status" property, which was made for
precisely this situation. I think basically the idea is to ignore link
training as part of the modeset, and just return the
On 28/08/2019 01:51, Andrey Smirnov wrote:
The whole point of a
driver is to avoid needing detailed knowledge of the device's internals
in userspace.
You won't avoid needing detailed knowledge of the device's internals
if you don't have a priori knowledge in the form of a agreed upon/well
kno
/omap: Implement CTM property for CRTC using OVL managers CPR
matrix
drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes
drm/omap: dss: platform_register_drivers() to dss.c and remove core.c
Tomi Valkeinen (3):
drm/omap: drop unneeded locking from mgr_fld_write()
drm/omap
Sarha
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 119 --
drivers/gpu/drm/omapdrm/dss/omapdss.h | 4 +
drivers/gpu/drm/omapdrm/omap_plane.c | 30 +++
3 files changed, 127 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm
.
This is not needed for omapdrm, so we can remove the locking.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
inde
From: Jyri Sarha
The core.c just for registering the drivers is kind of useless. Let's
get rid of it and register the dss drivers in dss.c.
Signed-off-by: Jyri Sarha
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/Makefile | 2 +-
drivers/gpu/drm/omapdrm/dss/core.c
the error is not observed
Signed-off-by: Alejandro Hernandez
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
b/drivers/gpu/drm/omapdrm/dss/hdmi5_co
ff-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index c6da33e7014f..7d87d60edb80 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
add a
custom property just for that.
Signed-off-by: Jyri Sarha
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 39 +++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_c
Currently the HDMI driver uses always limited range RGB output. This
patch improves the behavior by using limited range only if the output is
identified as a HDMI display, and VIC > 1.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 121 ---
Hi,
On 08/08/2019 13:10, Christoph Hellwig wrote:
The omapfb platform devices does not have a DMA mask set. The
traditional arm DMA code ignores, but the generic dma-direct/swiotlb
has stricter checks and thus fails mappings without a DMA mask.
As we use swiotlb for arm with LPAE now, omap need
never do something different based on this.
Cc: Tomi Valkeinen
Cc: David Airlie
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: Sebastian Reichel
Cc: Jyri Sarha
Cc: Tony Lindgren
Cc: zhong jiang
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman
This makes sense.
Reviewed-by
On 09/08/2019 11:07, Christoph Hellwig wrote:
> On Fri, Aug 09, 2019 at 09:40:32AM +0300, Tomi Valkeinen wrote:
>> We do call dma_set_coherent_mask() in omapdrm's probe() (in omap_drv.c),
>> but apparently that's not enough anymore. Changing that call to
>> dma_coe
On 07/07/2019 21:19, Laurent Pinchart wrote:
The omapdrm driver attaches to panels with drm_panel_attach() at probe
time but never calls drm_panel_detach(). Fix it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.c | 24 +++-
1 file changed, 19 insert
apdrm/omap_connector.h | 1 -
drivers/gpu/drm/omapdrm/omap_encoder.c | 4 +---
3 files changed, 1 insertion(+), 15 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Hel
: 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.freedesktop.org/mailman
--
5 files changed, 34 insertions(+), 46 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
this by repurposing the
currently unused of_ports bitmask in omap_dss_device with an of_port
output port number, and use it to traverse the OF graph.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus
bridge in the chain, and the omap_dss_device.next_bridge field is
set to the next bridge for the use of the internal encoders' bridges.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Busine
om it?
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@lists.freedesktop.org
ugh for everyone? =)
Maybe still keep it as a define for clarity?
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 l
video/fbdev/omap2/omapfb/displays/Kconfig | 5 +
1 file changed, 5 insertions(+)
Cc'd Bartlomiej.
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile
/displays/panel-tpo-td028ttec1.c
delete mode 100644 drivers/gpu/drm/omapdrm/displays/panel-tpo-td043mtea1.c
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 21/05/2021 12:09, Daniel Vetter wrote:
I guess no one ever tried running omap together with lima or panfrost,
not even sure that's possible. Anyway for consistency, fix this.
Signed-off-by: Daniel Vetter
Cc: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_plane.c | 3 +++
1 file ch
Cc: Maxime Ripard
Cc: Chen-Yu Tsai
Cc: Jernej Skrabec
Cc: Jyri Sarha
Cc: Tomi Valkeinen
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-s
On 23/05/2021 20:04, Paul Cercueil wrote:
Having GEM buffers backed by non-coherent memory is interesting in the
particular case where it is faster to render to a non-coherent buffer
then sync the data cache, than to render to a write-combine buffer, and
(by extension) much faster than using a sh
Hi Daniel,
On 21/01/2021 17:29, Daniel Vetter wrote:
Ends right after hw_done(), totally standard case.
Acked-by: Jyri Sarha
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_kms.c | 4
1 file changed, 4 insertions(+)
diff --git a
dma_mmap_pages() when it has the non-coherent cache attribute.
Signed-off-by: Paul Cercueil
Reported-by: Tomi Valkeinen
Fixes: cf8ccbc72d61 ("drm: Add support for GEM buffers backed by non-coherent
memory")
---
drivers/gpu/drm/drm_gem_cma_helper.c | 16 ++--
1 file c
go Vivi
Cc: Roland Scheidegger
Cc: Russell King
Cc: Sam Ravnborg
Cc: Sandy Huang
Cc: Sascha Hauer
Cc: Sean Paul
Cc: Seung-Woo Kim
Cc: Shawn Guo
Cc: Stefan Agner
Cc: Steven Price
Cc: Sumit Semwal
Cc: Thierry Reding
Cc: Tian Tao
Cc: Tomeu Vizoso
Cc: Tomi Valkeinen
Cc: VMware Graphics
Cc
On 25/01/2023 13:35, Aradhya Bhatia wrote:
Make DSS Video Ports agnostic of output bus types.
DSS controllers have had a 1-to-1 coupling between its VPs and its
output ports. This no longer stands true for the new AM625 DSS. This
coupling, hence, has been removed by renaming the 'vp_bus_type' to
On 25/01/2023 13:35, Aradhya Bhatia wrote:
The newer version of DSS (AM625-DSS) has 2 OLDI TXes at its disposal.
These can be configured to support the following modes:
1. OLDI_SINGLE_LINK_SINGLE_MODE
Single Output over OLDI 0.
+--++-+ +---+
| ||
bits */
+#define AM625_OLDI0_PWRDN_TX BIT(0)
+#define AM625_OLDI1_PWRDN_TX BIT(1)
+
+/* LVDS Bandgap reference Enable/Disable */
+#define AM625_OLDI_PWRDN_BG BIT(8)
#endif /* __TIDSS_DISPC_REGS_H */
Reviewed-by: Tomi Valkeinen
Tomi
On 25/01/2023 13:35, Aradhya Bhatia wrote:
Add support for the DSS controller on TI's new AM625 SoC in the tidss
driver.
The first video port (VP0) in am625-dss can output OLDI signals through
2 OLDI TXes. A 3rd output port has been added with "DISPC_PORT_OLDI" bus
type.
Not a big thing here a
On 05/02/2023 16:31, Aradhya Bhatia wrote:
On 03-Feb-23 21:03, Tomi Valkeinen wrote:
On 25/01/2023 13:35, Aradhya Bhatia wrote:
Add support for the DSS controller on TI's new AM625 SoC in the tidss
driver.
The first video port (VP0) in am625-dss can output OLDI signals through
2 OLDI
On 05/02/2023 15:08, Aradhya Bhatia wrote:
Hi Tomi,
Thanks for the review!
On 03-Feb-23 16:53, Tomi Valkeinen wrote:
On 25/01/2023 13:35, Aradhya Bhatia wrote:
Make DSS Video Ports agnostic of output bus types.
DSS controllers have had a 1-to-1 coupling between its VPs and its
output ports
On 05/02/2023 15:42, Aradhya Bhatia wrote:
Hi Tomi,
On 03-Feb-23 20:42, Tomi Valkeinen wrote:
On 25/01/2023 13:35, Aradhya Bhatia wrote:
The newer version of DSS (AM625-DSS) has 2 OLDI TXes at its disposal.
These can be configured to support the following modes:
1
On 06/02/2023 19:34, Aradhya Bhatia wrote:
On 06-Feb-23 18:35, Tomi Valkeinen wrote:
On 05/02/2023 15:08, Aradhya Bhatia wrote:
Hi Tomi,
Thanks for the review!
On 03-Feb-23 16:53, Tomi Valkeinen wrote:
On 25/01/2023 13:35, Aradhya Bhatia wrote:
Make DSS Video Ports agnostic of output bus
and BGRA1010102 formats.
Signed-off-by: Tomi Valkeinen
---
.../userspace-api/media/v4l/pixfmt-rgb.rst| 194 ++
drivers/media/v4l2-core/v4l2-ioctl.c | 3 +
include/uapi/linux/videodev2.h| 3 +
3 files changed, 200 insertions(+)
diff --git a/Document
ue.
Fixes: 8d0e3fc61abd ("media: Add 2-10-10-10 RGB formats")
Reported-by: Akira Yokosawa
Signed-off-by: Tomi Valkeinen
---
Note: the offending patch was merged via drm tree, so we may want to
apply the fix to the drm tree also.
Documentation/userspace-api/media/v4l/pixfmt-rgb.rst | 3 --
23 13:17, Mauro Carvalho Chehab wrote:
Em Wed, 8 Feb 2023 11:11:34 +0200
Laurent Pinchart escreveu:
Hi Tomi,
Thank you for the patch.
On Wed, Feb 08, 2023 at 10:29:16AM +0200, Tomi Valkeinen wrote:
Commit 8d0e3fc61abd ("media: Add 2-10-10-10 RGB formats") added
documatation for a few
gt;atomic_disable(lvds->companion,
- old_bridge_state);
+ rcar_lvds_atomic_disable(lvds->companion, old_bridge_state);
pm_runtime_put_sync(lvds->dev);
}
Reviewed-by: Tomi Valkeinen
Tomi
code,
but the diff shows you moving the lvds pclk enable/disable code. Other
than that:
Reviewed-by: Tomi Valkeinen
Tomi
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 97 +++--
1 file changed, 50 insertions(+), 47 deletions(-)
diff --git
a minor comment below, other than that:
Reviewed-by: Tomi Valkeinen
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 18 ++--
drivers/gpu/drm/rcar-du/rcar_lvds.c| 114 +++--
drivers/gpu/drm/rcar-du/rcar_lvds.h| 12 ++-
3 files
/gpu/drm/tidss/tidss_plane.c | 11 +--
3 files changed, 9 insertions(+), 22 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
enable = tidss_plane_atomic_enable,
.atomic_disable = tidss_plane_atomic_disable,
};
I haven't tested this, but looks fine to me.
Reviewed-by: Tomi Valkeinen
One thought, though, is that we still do dispc_plane_enable(false) in
tidss_plane_atomic_update() when the plane is not visible.
.format = rcar_du_format_info(DRM_FORMAT_XRGB),
.source = RCAR_DU_PLANE_VSPD1,
.colorkey = 0,
};
Reviewed-by: Tomi Valkeinen
Tomi
;routes[RCAR_DU_OUTPUT_DPAD1].possible_crtcs) &
+ BIT(rcrtc->index))
rcar_du_crtc_write(rcrtc, rcrtc->index % 2 ? OTAR13 : OTAR02,
0);
- }
/* Signal polarities */
dsmr = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DSMR_VSL : 0)
Reviewed-by: Tomi Valkeinen
Tomi
Hi,
On 22/02/2023 17:28, Nicolas Dufresne wrote:
Hi Tomi,
Le mercredi 21 décembre 2022 à 11:24 +0200, Tomi Valkeinen a écrit :
Add Y210, Y212 and Y216 formats.
Signed-off-by: Tomi Valkeinen
---
.../media/v4l/pixfmt-packed-yuv.rst | 49 ++-
drivers/media/v4l2
thought I already did this... And I see I did, but never sent the
patch as I couldn't figure the part 2 =).
Reviewed-by: Tomi Valkeinen
Tomi
be written to 0 temporarily
before starting the hardware, make sure that the registers are always
set to valid values.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_group.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
Reviewed-by: Tomi Valkeinen
Tomi
On 27/02/2023 14:06, Akira Yokosawa wrote:
Hi Mauro,
On Sun, 26 Feb 2023 11:47:44 +0100, Mauro Carvalho Chehab wrote:
Em Sun, 26 Feb 2023 08:39:32 +0900
Akira Yokosawa escreveu:
[+CC: Jon, linux-doc]
On Wed, 8 Feb 2023 10:29:16 +0200, Tomi Valkeinen wrote:
Commit 8d0e3fc61abd ("
m-misc-fixes ASAP.
If it's not too late:
Reviewed-by: Tomi Valkeinen
Tomi
Hi,
On 03/01/2023 12:19, Rahul T R wrote:
Following series of patches adds supports for CDNS DSI
bridge on j721e.
v11:
- Wrap commmit messages at 72 chars
- Fix the order in Kconfig and Makefile
- Clean up the includes, move macros and some headers to .c file
- Add missing forward decla
From: Tomi Valkeinen
Hi,
Here are some small rcar-du patches based on commits in the Renesas BSP
tree.
Tomi
Koji Matsuoka (2):
drm: rcar-du: lvds: Add reset control
drm: rcar-du: Fix LVDS stop sequence
Tomi Valkeinen (4):
drm: rcar-du: dsi: add 'select RESET_CONTROLLER'
dr
On 09/01/2023 18:21, Aradhya Bhatia wrote:
Hi Angelo,
Thanks for taking a look at the patches!
On 03-Jan-23 17:21, AngeloGioacchino Del Regno wrote:
Il 03/01/23 07:46, Aradhya Bhatia ha scritto:
Dual-link LVDS interfaces have 2 links, with even pixels traveling on
one link, and odd pixels on
The RCAR DSI driver uses reset controller, so we should select it in the
Kconfig.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/rcar-du/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index fd2c2eaee26b
From: Koji Matsuoka
According to H/W manual, LVDCR0 register must be cleared bit by bit when
disabling LVDS.
Signed-off-by: Koji Matsuoka
Signed-off-by: LUU HOAI
[tomi.valkeinen: simplified the code a bit]
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 27
From: Koji Matsuoka
Reset LVDS using the reset control as CPG reset/release is required in
H/W manual sequence.
Signed-off-by: Koji Matsuoka
Signed-off-by: LUU HOAI
[tomi.valkeinen: Rewrite the patch description]
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/rcar-du/Kconfig | 1
The following registers do not exist on gen4, so we should not write
them: DEF6Rm, DEF8Rm, ESCRn, OTARn.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 8 +---
drivers/gpu/drm/rcar-du/rcar_du_group.c | 6 --
2 files changed, 9 insertions(+), 5 deletions
901 - 1000 of 3844 matches
Mail list logo
