Some 3.0 source has it set behind a if (omap4).
Maybe it is helpful maybe not, at least in the omap4460
trm these bits are marked as reserved.
But maybe some dsi video mode panel starts magically working.
Signed-off-by: Andreas Kemnade <[email protected]>
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 60189a23506a1..e2f576cd9f63c 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -4505,7 +4505,7 @@ static const struct dss_pll_hw dss_omap4_dsi_pll_hw = {
.has_stopmode = true,
.has_freqsel = false,
.has_selfreqdco = false,
- .has_refsel = false,
+ .has_refsel = true,
};
static const struct dss_pll_hw dss_omap5_dsi_pll_hw = {
--
2.39.2
* Andreas Kemnade <[email protected]> [230913 06:59]:
> Some 3.0 source has it set behind a if (omap4).
> Maybe it is helpful maybe not, at least in the omap4460
> trm these bits are marked as reserved.
> But maybe some dsi video mode panel starts magically working.
Interesting. So Andreas mentioned that dsi video mode works on omap5
but not on omap4. Adding Sebastian to the list too.
Regards,
Tony
>
> Signed-off-by: Andreas Kemnade <[email protected]>
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 60189a23506a1..e2f576cd9f63c 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -4505,7 +4505,7 @@ static const struct dss_pll_hw dss_omap4_dsi_pll_hw = {
> .has_stopmode = true,
> .has_freqsel = false,
> .has_selfreqdco = false,
> - .has_refsel = false,
> + .has_refsel = true,
> };
>
> static const struct dss_pll_hw dss_omap5_dsi_pll_hw = {
> --
> 2.39.2
>
On 13/09/2023 09:59, Andreas Kemnade wrote:
> Some 3.0 source has it set behind a if (omap4).
> Maybe it is helpful maybe not, at least in the omap4460
> trm these bits are marked as reserved.
> But maybe some dsi video mode panel starts magically working.
Sorry, what does this mean? That this fixes something, or you are just
guessing?
I'm somewhat sure that the upstream driver used to work on omap4 sdp,
which has two DSI panels. But I can't even remember what omap4 version
it had.
Tomi
> Signed-off-by: Andreas Kemnade <[email protected]>
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 60189a23506a1..e2f576cd9f63c 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -4505,7 +4505,7 @@ static const struct dss_pll_hw dss_omap4_dsi_pll_hw = {
> .has_stopmode = true,
> .has_freqsel = false,
> .has_selfreqdco = false,
> - .has_refsel = false,
> + .has_refsel = true,
> };
>
> static const struct dss_pll_hw dss_omap5_dsi_pll_hw = {
On Wed, 13 Sep 2023 15:11:08 +0300
Tomi Valkeinen <[email protected]> wrote:
> On 13/09/2023 09:59, Andreas Kemnade wrote:
> > Some 3.0 source has it set behind a if (omap4).
> > Maybe it is helpful maybe not, at least in the omap4460
> > trm these bits are marked as reserved.
> > But maybe some dsi video mode panel starts magically working.
>
> Sorry, what does this mean? That this fixes something, or you are
> just guessing?
>
just diffing registers between good and bad. It does not fix anything,
just reducing the diff.
> I'm somewhat sure that the upstream driver used to work on omap4 sdp,
> which has two DSI panels. But I can't even remember what omap4
> version it had.
>
after we are using displays from gpu/drm/displays?
Regards
Andreas
On 13/09/2023 15:48, Tony Lindgren wrote:
> * Tomi Valkeinen <[email protected]> [230913 12:11]:
>> I'm somewhat sure that the upstream driver used to work on omap4 sdp, which
>> has two DSI panels. But I can't even remember what omap4 version it had.
>
> I think those were both dsi command mode panels though, not video mode?
Yes, true. If the PLL is totally wrong due to refsel, I'm sure a command
mode panel would also fail. But it's true that video mode panels are
more sensitive to the clock rate.
Tomi
* Tomi Valkeinen <[email protected]> [230913 12:11]:
> I'm somewhat sure that the upstream driver used to work on omap4 sdp, which
> has two DSI panels. But I can't even remember what omap4 version it had.
I think those were both dsi command mode panels though, not video mode?
Regards,
Tony
Am Wed, 13 Sep 2023 15:58:11 +0300
schrieb Tomi Valkeinen <[email protected]>:
> On 13/09/2023 15:48, Tony Lindgren wrote:
> > * Tomi Valkeinen <[email protected]> [230913 12:11]:
> >> I'm somewhat sure that the upstream driver used to work on omap4
> >> sdp, which has two DSI panels. But I can't even remember what
> >> omap4 version it had.
> >
> > I think those were both dsi command mode panels though, not video
> > mode?
>
> Yes, true. If the PLL is totally wrong due to refsel, I'm sure a
> command mode panel would also fail. But it's true that video mode
> panels are more sensitive to the clock rate.
>
hmm, still analyzing:
What works:
OMAP5 + Pyra (Videomode display requiring some init commands)
some command mode stuff with OMAP4 (droid4)
What does not work:
OMAP4 with some dsi videomode to something else (LVDS/DPI) converter
if init commands are sent through dsi, then these commands fail
with bta sync problems.
So sending init commands to video mode displays seems not to be a
principal problem.
But looking deeper at the drivers, there seem to be commands sent
to the converters to configure lanes on that side, e.g.
tc358762_write(ctx, DSI_LANEENABLE,
LANEENABLE_L0EN | LANEENABLE_CLEN);
There might be trouble if these are not sent in low power mode.
So probably the next analyzing step would be to check if things
are really sent in low power mode.
Regards,
Andreas