Add DT property for defining the pin used for HPD.
Signed-off-by: Tomi Valkeinen
Cc: devicet...@vger.kernel.org
Cc: Rob Herring
Reviewed-by: Rob Herring
---
.../devicetree/bindings/display/bridge/toshiba,tc358767.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation
On 03/05/2019 15:55, Laurent Pinchart wrote:
- if (state) {
- ret = tc_set_video_mode(tc, tc->mode);
- if (ret)
- goto err;
+ ret = tc_set_video_mode(tc, tc->mode);
+ if (ret)
+ goto err;
>>>
>>> Let's return
On 03/05/2019 15:48, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Fri, May 03, 2019 at 02:43:51PM +0300, Tomi Valkeinen wrote:
>> On 23/04/2019 17:56, Laurent Pinchart wrote:
>>
>>>> During initial driver development I had one eDP display that reports 0 in
>>
Hi Laurent, Andrey,
On 03/05/2019 20:11, Laurent Pinchart wrote:
>> I agree that if the panel Andrey mentioned is still used, we need to
>> handle it somehow. But I think explicitly handling such a case is better
>> than guessing.
>
> The risk may not be worth it, I agree. I would explain this in
On 21/05/2019 10:07, Andrzej Hajda wrote:
@@ -1214,19 +1234,43 @@ static int tc_connector_get_modes(struct drm_connector
*connector)
return count;
}
-static void tc_connector_set_polling(struct tc_data *tc,
-struct drm_connector *connector)
-{
-
Hi,
On 25/05/2019 17:56, Matteo Croce wrote:
On Sat, May 25, 2019 at 9:30 AM Hariprasad Kelam
wrote:
fix below warnings reported by coccicheck
Hi,
a similar patch was nacked because it makes backports more difficult:
https://lore.kernel.org/lkml/3dec4093-824e-b13d-d712-2dedd445a...@ti.co
Hi,
On 23/05/2019 23:07, Sebastian Reichel wrote:
Hi,
Here is another round of the DSI command mode panel patchset
integrating the feedback from PATCHv5. The patches are based
on v5.2-rc1 tag. It does not contain the patches required for
OMAP3 support (it needs a workaround for a hardware bug)
On 21/05/2019 17:18, Andrzej Hajda wrote:
DisplayPort spec talks about doing the display-props reading and EDID reading
when
handling HPD.
I think it would be best to change the code so that we read display props and
EDID in HPD,
but so that we also can read them later (when needed, probably
Minor cleanups:
- Use bool for boolean fields
- Use DP_MAX_DOWNSPREAD_0_5 instead of BIT(0)
- debug print down-spread and scrambler status
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/tc358767.c | 13 -
1 file
ave other bits set (e.g. after reset VID_MN_GEN is set)
* Added some reviewed-bys
Tomi
Tomi Valkeinen (24):
drm/bridge: tc358767: fix tc_aux_get_status error handling
drm/bridge: tc358767: reset voltage-swing & pre-emphasis
drm/bridge: tc358767: fix ansi 8b10b use
drm/bridge: tc358767:
It is nicer to have enable/disable functions instead of set(bool enable)
style function.
Split tc_main_link_stream into tc_stream_enable and tc_stream_disable.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 81
We need to reset DPCD voltage-swing & pre-emphasis before starting the
link training, as otherwise tc358767 will use the previous values as
minimums.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 7 +++
1 file changed, 7 insert
swing and preemp fields are not used. Remove them.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/tc358767.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge
working.
This patch makes the driver to always use ANSI 8B10B encoding, and drops
the 'coding8b10b' field which is no longer used.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 11 +++
1 file changed, 3 insertions(+), 8 deletion
be somewhat random if DP link has
erroneously been left enabled, let's add a WARN_ON() for the case and
set DP0CTL to 0.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/b
EN in tc_stream_disable to
stop the video stream while keeping the link enabled.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/b
nable.
Also, currently the PXL PLL is only disabled if the driver if removed.
Let's disable the PXL PLL when the stream is disabled.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/tc358767.c | 20 ++--
1 file c
d the link
disconnects right after those steps.
If I reverse the steps, it works every time. There's a chance that this
is DP sink specific, though, but as my testing shows this sequence to be
much more reliable, let's change it.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
The driver currently sets the video stream registers in
tc_main_link_setup. One should be able to establish the DP link without
any video stream, so a more logical place is to configure the stream in
the tc_main_link_stream. So move them there.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej
tc_aux_get_status() does not report AUX_TIMEOUT correctly, as it only
checks the AUX_TIMEOUT if aux is still busy. Fix this by always checking
for AUX_TIMEOUT.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 11 +++
1 file changed, 7
Modify aux_link_setup so that it does not use tc->link, and thus makes
aux setup independent of the link probing.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/tc358767.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletio
Currently we have tc_main_link_setup(), which configures and enabled the
link, but we have no counter-part for disabling the link.
Add tc_main_link_disable, and rename tc_main_link_setup to
tc_main_link_enable.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm
ff-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 62 +--
1 file changed, 35 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 40f3efcade50..d79b1d0ca0db 1
instead to ensure we don't refer to
freed/modified data.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358
We have tc_connector_mode_valid() to filter out videomdoes that the
tc358767 cannot support. As it is a bridge limitation, change the code
to use drm_bridge_funcs's mode_valid instead.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gp
We need to know the link bandwidth to filter out modes we cannot
support, so we need to have read the display props before doing the
filtering.
To ensure we have up to date display props, call tc_get_display_props()
in the beginning of tc_connector_get_modes().
Signed-off-by: Tomi Valkeinen
drm_connector_helper_funcs.best_encoder is only needed when the
connector can have more than one encoder, and that is never the case
here.
So remove tc_connector_best_encoder.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge
ch handles waiting for the LT
phase to finish, and does the necessary LT register setups in
tc_main_link_enable, without extra loops.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 136 +-
1 file changed, 60 inserti
efore drm_bridge_funcs.enable is
called, so we don't need the check there either.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc3587
Add DT property for defining the pin used for HPD.
Signed-off-by: Tomi Valkeinen
Cc: devicet...@vger.kernel.org
Cc: Rob Herring
Reviewed-by: Rob Herring
---
.../devicetree/bindings/display/bridge/toshiba,tc358767.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation
For some reason the driver has a msleep(100) after writing to
DP_PHY_CTRL. Toshiba's documentation doesn't suggest any delay is
needed, and I have not seen any issues with the sleep removed.
Drop it, as msleep(100) is a rather big one.
Signed-off-by: Tomi Valkeinen
Reviewed-by: And
Add GPIO and interrupt related registers for HPD work. Mark INTSTS_G and
GPIOI as volatile.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers
Add support for interrupt and hotplug handling. Both are optional.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/tc358767.c | 163 ++
1 file changed, 145 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm
On 27/05/2019 14:21, Tony Lindgren wrote:
>> Looks good to me. For some reason I can't boot 5.2-rc2 (on x15) so I haven't
>> been able to test yet. I'll pick the series up in any case, and I'll test it
>> when I get the kernel booting.
>
> Great good to have these merged finally :)
>
> Hmm I won
Hi Sebastian,
On 23/05/2019 23:07, Sebastian Reichel wrote:
@@ -302,6 +328,30 @@ void omap_crtc_vblank_irq(struct drm_crtc *crtc)
DBG("%s: apply done", omap_crtc->name);
}
+void omap_crtc_framedone_irq(struct drm_crtc *crtc, uint32_t irqstatus)
+{
+ struct omap_crtc *omap_cr
On 28/05/2019 13:18, Tony Lindgren wrote:
This change lets me boot. I don't know that's the correct place, though:
diff --git a/arch/arm/boot/dts/am5728.dtsi b/arch/arm/boot/dts/am5728.dtsi
index 82e5427ef6a9..c778f9a86b3a 100644
--- a/arch/arm/boot/dts/am5728.dtsi
+++ b/arch/arm/boot/dts/am572
On 27/05/2019 23:41, Thomas Meyer wrote:
Make sure (of/i2c/platform)_device_id tables are NULL terminated.
Signed-off-by: Thomas Meyer
---
diff -u -p a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
--- a/drivers/gpu/drm/omapdrm/dss/omapdss-b
On 22/05/2019 18:02, Emil Velikov wrote:
From: Emil Velikov
Cc: Tomi Valkeinen
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/omapdrm/omap_drv.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm
On 23/04/2019 10:50, Kefeng Wang wrote:
Using dev_get_drvdata directly.
Cc: Tomi Valkeinen
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kefeng Wang
---
.../gpu/drm/omapdrm/displays/panel-dsi-cm.c| 18 ++
1 file changed, 6
Hi,
On 10/05/2019 22:42, Adam Ford wrote:
Currently the source code is compiled using hard-coded values
from CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. This patch allows this
clock divider value to be moved to the device tree and be changed
without having to recompile the kernel.
Signed-off-by: Adam Fo
Hi,
On 28/05/2019 18:09, Adam Ford wrote:
On Tue, May 28, 2019 at 4:11 AM Tomi Valkeinen wrote:
Hi,
On 10/05/2019 22:42, Adam Ford wrote:
Currently the source code is compiled using hard-coded values
from CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. This patch allows this
clock divider value to be
On 28/05/2019 18:41, Emil Velikov wrote:
On 2019/05/28, Tomi Valkeinen wrote:
On 22/05/2019 18:02, Emil Velikov wrote:
From: Emil Velikov
Cc: Tomi Valkeinen
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/omapdrm/omap_drv.c | 16 +---
1 file changed, 1 insertion(+), 15
On 28/05/2019 13:18, Tony Lindgren wrote:
My board is x15 rev A3, attached to AM5 EVM. I've also attached my kernel
config.
Strange that this is not affecting other x15? I think timer12 would
be blocked on HS devices though?
Seems that the kernel config affects. omap2plus_defconfig boots ok.
Hi Andrey,
On 03/04/2019 14:34, Tomi Valkeinen wrote:
> On 02/04/2019 05:16, Andrey Smirnov wrote:
>
>> The early return above causes tc_get_display_props() to never be
>> called for eDP case, which in turn result in tc_mode_valid() returning
>> MODE_BAD for every m
On 15/04/2019 10:38, Andrzej Hajda wrote:
> On 26.03.2019 11:31, Tomi Valkeinen wrote:
>> Modify aux_link_setup so that it does not use tc->link, and thus makes
>> aux setup independent of the link probing.
>>
>> Signed-off-by: Tomi Valkeinen
>> ---
>&
On 15/04/2019 13:42, Andrzej Hajda wrote:
> Ok we have here 4 combinations:
>
> 1. noHPD + eDP.
>
> 2. noHPD + DP.
>
> 3. HPD + eDP.
>
> 4. HPD + DP.
>
>
> Which ones do you want to support, disallow. It is not clear to me.
They all should work.
If there is HPD, we use it to return connect
On 15/04/2019 12:54, Andrzej Hajda wrote:
> On 26.03.2019 11:31, Tomi Valkeinen wrote:
>> The current link training code does unnecessary retry-loops, and does
>> extra writes to the registers. It is easier to follow the flow and
>> ensure it's similar to Toshiba's d
On 15/04/2019 13:09, Andrzej Hajda wrote:
> On 26.03.2019 11:31, Tomi Valkeinen wrote:
>> In tc_bridge_mode_set callback, we store the pointer to the given
>> drm_display_mode, and use the mode later. Storing a pointer in such a
>> way looks very suspicious to me, and I hav
On 15/04/2019 11:49, Andrzej Hajda wrote:
> On 26.03.2019 11:31, Tomi Valkeinen wrote:
>> Link training will sometimes fail if the DP link is, for some whatever
>> reason, enabled when tc_main_link_enable() is called.
>
>
> Only tc_stream_enable enables it, does it mea
On 15/04/2019 11:36, Andrzej Hajda wrote:
>> +static int tc_main_link_disable(struct tc_data *tc)
>> +{
>> +int ret;
>> +
>> +dev_dbg(tc->dev, "link disable\n");
>> +
>> +tc_write(DP0_SRCCTRL, 0);
>> +tc_write(DP0CTL, 0);
>
>
> The same register is set in stream_disable, is it co
On 17/04/2019 20:42, Emil Velikov wrote:
> Have you looked at the libdrm drmDevice2 (yes use the second version) API?
> It provides various information about the different devices, yet if
> it's missing anything do send us a patch ;-)
No, I didn't notice that. At least with a quick look, looks go
On 20/04/2019 23:14, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Tue, Mar 26, 2019 at 12:31:25PM +0200, Tomi Valkeinen wrote:
>> tc_aux_get_status() does not report AUX_TIMEOUT correctly, as it only
>> checks the AUX_TIMEOUT if aux is sti
On 20/04/2019 23:30, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Tue, Mar 26, 2019 at 12:31:26PM +0200, Tomi Valkeinen wrote:
>> We need to reset DPCD voltage-swing & pre-emphasis before starting the
>> link training, as otherwise tc3587
Hi,
On 17/04/2019 10:32, Andrzej Hajda wrote:
> On 15.04.2019 12:59, Tomi Valkeinen wrote:
>> On 15/04/2019 13:42, Andrzej Hajda wrote:
>>
>>> Ok we have here 4 combinations:
>>>
>>> 1. noHPD + eDP.
>>>
>>> 2. noHPD + DP.
>>>
Hi Andrzej,
On 09/01/19 12:12, Andrzej Hajda wrote:
> On 09.01.2019 10:51, Lucas Stach wrote:
>> Am Mittwoch, den 09.01.2019, 11:12 +0200 schrieb Tomi Valkeinen:
>>> Hi Andrzej,
>>>
>>> On 09/01/19 10:22, Andrzej Hajda wrote:
>>>> Hi Tomi,
>
erties, new files in sysfs or anything else that constitutes an API
> change
> +should have driver-agnostic testcases in IGT for that feature, if such a test
> +can be reasonably made using IGT for the target hardware.
> +
Acked-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland
Hi,
On 30/01/2019 13:03, Damian Kos wrote:
> Hello!
>
> This is the series of patches that will add support for the Cadence's DPI/DP
> bridge. Please note that this is a preliminary version of the driver and there
> will be more patches in the future with updates, fixes and improvements.
> Please
Hi,
On 19/01/2019 20:21, Andreas Kemnade wrote:
> This panel has a backlight, so fetch it from devicetree using the
> as documented in panel-common.txt. It is implemented the same way as in
Extra words above, or maybe some are missing...
> panel-dpi.c
> This ensures the backlight is also disable
Hi Tony,
On 31/01/2019 05:32, Tony Lindgren wrote:
> Currently dsi_display_init_dsi() calls dss_pll_enable() but it is not
> paired with dss_pll_disable() in dsi_display_uninit_dsi(). This leaves
But it is paired with dsi_pll_uninit().
> the DSS clocks enabled when the display is blanked wasting
On 04/02/2019 17:42, Tony Lindgren wrote:
> Hi,
>
> * Tomi Valkeinen [190204 09:57]:
>> On 31/01/2019 05:32, Tony Lindgren wrote:
>>> Currently dsi_display_init_dsi() calls dss_pll_enable() but it is not
>>> paired with dss_pll_disable() in dsi_display_uninit_d
On 05/02/2019 19:58, Tony Lindgren wrote:
> * Tomi Valkeinen [190205 11:07]:
>> Yep... So there's the DSI internal code which needs to deal with ulps
>> and disconnect_lanes, and then the external interface to the DSI PLL (so
>> that DPI can use DSI PLL) without ulps
Hi,
On 11/01/2019 05:50, Laurent Pinchart wrote:
> Hello,
>
> This patch series consolidates the three pending series for the omapdrm and
> tfp410 drivers that all together implement drm_bridge and drm_panel support
> for omapdrm.
>
> The series starts with four patches not posted before as part
On 06/02/2019 18:00, Tony Lindgren wrote:
> OK I'll give it a try. Based on a quick glance, we need to still
> check for enabled regulator to avoid unpaired calls.
>
>> static int dsi_dump_dsi_clocks(struct seq_file *s, void *p)
>> @@ -4108,6 +4094,10 @@ static int dsi_display_init_dsi(struct ds
On 06/02/2019 18:29, Tony Lindgren wrote:
> OK. Looks good to me otherwise.
>
> So I guess we should fix. Do you want me to post it all
> as a single patch after some testing?
Yes please =)
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-
just call dss_pll_disable() from
> dsi_display_uninit_dsi() and the code becomes a bit easier to follow.
>
> However, we need to also consider that DSI PLL can be muxed for DVI too
> as pointed out by Tomi Valkeinen . In the DVI
> case, we want to unconditionally disable the clocks. To get around thi
On 05/02/2019 08:38, Andreas Kemnade wrote:
> This panel has a backlight, so add a property describing that and
> add the code to use that.
> This makes things like xset dpms force off
> also turn off the backlight, so we do not need to rely on additional
> userspace programs to do that.
>
> Andre
On 08/02/2019 17:20, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Fri, Jan 18, 2019 at 12:33:03PM +0200, Tomi Valkeinen wrote:
>> On 11/01/19 05:51, Laurent Pinchart wrote:
>>> Hook up drm_bridge support in the omapdrm driver. Despite the recent
>>> extensive p
ocess cumbersome.
I found a few issues while trying to get a DSI video mode panel working.
Attached WIP patches.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>From d840733d13a9a723824d78aa871e3d847fdf954a M
The H and V syncs of the DP output are always set to active high. This
patch fixes the syncs by configuring them according to the videomode.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion
tc358767 driver does not set DRM bus_flags, even if it does configures
the polarity settings into its registers. This means that the DPI source
can't configure the polarities correctly.
Add sync flags accordingly.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gp
PHY_2LANE bit is always set in DP_PHY_CTRL, breaking 1 lane use.
Set PHY_2LANE only when 2 lanes are used.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu
provides the correct
value.
DP1_SRCCTRL needs two bits to be set to the same value as DP0_SRCCTRL:
SSCG and BW27. All other bits can be zero.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 11 +--
1 file changed, 5 insertions(+), 6
DP1_SRCCTRL register and PHY_2LANE field did not have matching defines.
Add these.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b
v2:
- Addressed the comments
- Added reviewed bys
Tomi
Tomi Valkeinen (7):
drm/bridge: tc358767: add bus flags
drm/bridge: tc358767: add defines for DP1_SRCCTRL & PHY_2LANE
drm/bridge: tc358767: fix single lane configuration
drm/bridge: tc358767: fix initial DP0/1_SRCCTRL value
drm/
tc358767 driver sets the connector type always to eDP.
This patch sets the type to DP if there is no panel defined, which
implies that there's a DP connector on the board.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 3 ++-
1 file chang
The current driver accepts any videomode with pclk < 154MHz. This is not
correct, as with 1 lane and/or 1.62Mbps speed not all videomodes can be
supported.
Add code to reject modes that require more bandwidth that is available.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Ha
The driver always sets InputBusFmt:EDGE to 0 (falling edge).
Add drm_bridge_timings's sampling_edge to reflect that the bridge
samples on falling edges.
Signed-off-by: Tomi Valkeinen
---
NOTE: This needs Laurent's "drm: Clarify definition of the
DRM_BUS_FLAG_(PIXDATA|SYNC)_* ma
Hi Andrzej,
On 09/01/19 10:22, Andrzej Hajda wrote:
> Hi Tomi,
>
> On 03.01.2019 12:59, Tomi Valkeinen wrote:
>> Hi,
>>
>> We have TC358867 on our board, which I believe is almost identical to
>> TC358767. We're using it with a DP connector instead of e
On 09/01/19 11:51, Lucas Stach wrote:
> For the series:
>
> Tested-by: Lucas Stach
>
> on a device with TC358767 and a 4.20 based kernel.
Thanks Lucas.
Does the device use TC358767 as eDP+panel, or as full DP with an
external connector? We have the latter, and I think there are some
missing p
--
> drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
__
On 11/01/19 05:50, Laurent Pinchart wrote:
> From: Tomi Valkeinen
>
> Commit edb715dffdee ("drm/omap: dss: dsi: Move initialization code from
> bind to probe") moved the of_platform_populate() call from dsi_bind() to
> dsi_probe(), but failed to move the corresponding
> drivers/gpu/drm/omapdrm/omap_connector.h | 2 --
> 1 file changed, 2 deletions(-)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
> 1 file changed, 2 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@lis
/omapdrm/dss/venc.c | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
Hmm, I think wss_data served some purpose, but possibly not all of the
wss code was upstreamed at Nokia time...
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Hel
---
> 2 files changed, 2 insertions(+), 51 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
iVision Technologies
> oxsemi Oxford Semiconductor, Ltd.
> panasonicPanasonic Corporation
>
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
__
ys OSD070T1718-19TS 7" WVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "osddisplays,osd070t1718-19ts"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
>
Reviewed-by: Tomi
/panel/panel-simple.c | 29
> 1 file changed, 29 insertions(+)
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri
is:
- if there's a DT gpu alias for the device, use that
- else, if there are any gpu aliases, pick a minor number that is higher
than any of the aliases.
- else, use the full range of possible numbers
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/drm_drv.c | 31 +++
On 17/01/19 14:33, Daniel Vetter wrote:
> On Thu, Jan 17, 2019 at 01:19:18PM +0200, Tomi Valkeinen wrote:
>> The DRM device minor numbers are allocated according to the registration
>> order. This causes confusion in cases where the registration order can
>> change, or whe
On 17/01/19 15:26, Daniel Vetter wrote:
> On Thu, Jan 17, 2019 at 2:04 PM Tomi Valkeinen wrote:
>>
>> On 17/01/19 14:33, Daniel Vetter wrote:
>>> On Thu, Jan 17, 2019 at 01:19:18PM +0200, Tomi Valkeinen wrote:
>>>> The DRM device minor numbers are all
On 18/01/19 00:04, Rob Herring wrote:
> Mesa/libdrm already has lots of code to open the correct devices and
> not care about minor numbers. What's the problem here?
Well, maybe the problem is that I don't know how to do this =).
So, if we have multiple DRM devices, how does one manage those?
It
Hi Laurent,
On 11/01/19 05:51, Laurent Pinchart wrote:
> Hook up drm_bridge support in the omapdrm driver. Despite the recent
> extensive preparation work, this is a rather intrusive change, as the
> management of outputs needs to be adapted through the driver to handle
> both omap_dss_device and
Hi Laurent,
On 11/02/2019 11:46, Laurent Pinchart wrote:
> + /* Get the sampling edge from the endpoint. */
> + of_property_read_u32(ep, "pclk-sample", &pclk_sample);
> + of_node_put(ep);
> +
> + timings->input_bus_flags = DRM_BUS_FLAG_DE_HIGH;
> +
> + switch (pclk_sample) {
>
On 28/02/2019 12:27, Tomi Valkeinen wrote:
> Hi Laurent,
>
> On 11/02/2019 11:46, Laurent Pinchart wrote:
>
>> +/* Get the sampling edge from the endpoint. */
>> +of_property_read_u32(ep, "pclk-sample", &pclk_sample);
>> +of_node_pu
On 06/03/2019 03:41, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Fri, Jan 18, 2019 at 10:29:33AM +0200, Tomi Valkeinen wrote:
>> On 18/01/19 00:04, Rob Herring wrote:
>>
>>> Mesa/libdrm already has lots of code to open the correct devices and
>>> not care
On 30/05/2019 00:55, Sebastian Reichel wrote:
Oh sorry, I missed the part that omap_irq_wait_init() actually
enables the framedone irq. It should be enough to just drop the
warning (and the curly brackets) to keep existing behaviour. The
code exits early with the above warning for any existing c
the token.
Note: the outstanding DRM_AUTH instance is:
- (badly coped) legacy DRI1 ioctl, which is a noop
Cc: Tomi Valkeinen
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/omapdrm/omap_drv.c | 10 +-
1 file changed, 5
WARN().
Fix this by doing the cancel only if we actually had the delayed work
set up.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/ti-tfp410.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
We don't free the edid blob allocated by the call to drm_get_edid(),
causing a memleak. Fix this by calling kfree(edid) at the end of the
get_modes().
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/ti-tfp410.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --
501 - 600 of 3440 matches
Mail list logo
