Diagnosing issues with OMAPDSS scaling of overlay 0

Diagnosing issues with OMAPDSS scaling of overlay 0

[Tomasz Młoduchowski]

Hi!

Is there a way to diagnose why the omapdss fails to scale ovl 0?

[ 2470.719604] omapdss OVERLAY: check_overlay 0: (0,0 1280x768 -> 1360x768) disp (1360x768)
[ 2470.719635] omapdss MANAGER: omap_dss_mgr_apply(lcd)
[ 2470.719665] omapdss OVERLAY: check_overlay 0: (0,0 1280x768 -> 1360x768) disp (1360x768)
[ 2470.719726] omapdss MANAGER: configure_overlay(0)
[ 2470.719757] omapdss DISPC: dispc_setup_plane 0, pa 86800000, sw 1280, 0,0, 1280x768 -> 1360x768, ilace 0, cmode 80, rot 0, mir 0 chan 0
[ 2470.719787] omapdss MANAGER error: dispc_setup_plane failed for ovl 0
[ 2470.726593] omapdss DISPC: dispc_enable_plane 0, 0

Cheers,
Tomasz

Re: Diagnosing issues with OMAPDSS scaling of overlay 0

[Tomi Valkeinen]

On Sat, 2011-04-09 at 17:27 +0200, Tomasz Młoduchowski wrote:
> Hi!
> 
> Is there a way to diagnose why the omapdss fails to scale ovl 0?
> 
> [ 2470.719604] omapdss OVERLAY: check_overlay 0: (0,0 1280x768 -> 1360x768) disp (1360x768)
> [ 2470.719635] omapdss MANAGER: omap_dss_mgr_apply(lcd)
> [ 2470.719665] omapdss OVERLAY: check_overlay 0: (0,0 1280x768 -> 1360x768) disp (1360x768)
> [ 2470.719726] omapdss MANAGER: configure_overlay(0)
> [ 2470.719757] omapdss DISPC: dispc_setup_plane 0, pa 86800000, sw 1280, 0,0, 1280x768 -> 1360x768, ilace 0, cmode 80, rot 0, mir 0 chan 0
> [ 2470.719787] omapdss MANAGER error: dispc_setup_plane failed for ovl 0
> [ 2470.726593] omapdss DISPC: dispc_enable_plane 0, 0

No need to diagnose, graphics overlay (overlay 0) cannot be scaled =).

 Tomi


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Diagnosing issues with OMAPDSS scaling of overlay 0

[Tomasz Młoduchowski]

>> Is there a way to diagnose why the omapdss fails to scale ovl 0?
> No need to diagnose, graphics overlay (overlay 0) cannot be scaled =).
Thanks so much! 

Now that you pointed me in the right direction - the only place this limitation is actually mentioned is the TRM document (and the driver seems quite content to export unsupported functionality to the sysfs)

Perhaps next time someone stumbles over my naive question and finds this thread. If I find the time this week, I'll try adding something to the documentation.

- Tomasz

Re: Diagnosing issues with OMAPDSS scaling of overlay 0

[Tomi Valkeinen]

On Mon, 2011-04-11 at 12:08 +0200, Tomasz Młoduchowski wrote:
> >> Is there a way to diagnose why the omapdss fails to scale ovl 0?
> > No need to diagnose, graphics overlay (overlay 0) cannot be scaled =).
> Thanks so much! 
> 
> Now that you pointed me in the right direction - the only place this
> limitation is actually mentioned is the TRM document (and the driver
> seems quite content to export unsupported functionality to the sysfs)

True. I've long had plan to add the sysfs files only if the feature is
actually supported.

> Perhaps next time someone stumbles over my naive question and finds
> this thread. If I find the time this week, I'll try adding something
> to the documentation.

I've mostly tried to keep the documentation only discuss about the
software side. The TRM is public and should be used to understand the
hardware.

But you are right that normal user shouldn't need to read the TRM if he
just wants to use scaling =). So either the sysfs/ioctl interfaces
should force the user to use things correctly, or he should get clear
warnings/errors when he uses things incorrectly, or the documentation
should say these things.

 Tomi


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Diagnosing issues with OMAPDSS scaling of overlay 0

[Kalle Vahlman]

2011/4/11 Tomi Valkeinen <tomi.valkeinen@ti.com>
> But you are right that normal user shouldn't need to read the TRM if he
> just wants to use scaling =). So either the sysfs/ioctl interfaces
> should force the user to use things correctly, or he should get clear
> warnings/errors when he uses things incorrectly, or the documentation
> should say these things.

If the sysfs interface is not there, the questions will just turn from
"why does it not work" to "why is there no sysfs entry"...

Good, descriptive error messages are the best way to avoid confusion.
If there is no reason to suspect that future hardware revisions will
support scaling the gfx layer, then a documentation mention would be a
nice addition (but not replacement).

--
Kalle Vahlman, zuh@iki.fi
Powered by http://movial.com
Interesting stuff at http://sandbox.movial.com

Re: Diagnosing issues with OMAPDSS scaling of overlay 0

[Tomasz Młoduchowski]

> From: "Kalle Vahlman" <kalle.vahlman@gmail.com>
> 2011/4/11 Tomi Valkeinen <tomi.valkeinen@ti.com>
> > But you are right that normal user shouldn't need to read the TRM
> > if he
> > just wants to use scaling =). So either the sysfs/ioctl interfaces
> > should force the user to use things correctly, or he should get
> > clear
> > warnings/errors when he uses things incorrectly, or the
> > documentation
> > should say these things.
> 
> If the sysfs interface is not there, the questions will just turn
> from
> "why does it not work" to "why is there no sysfs entry"...

I believe there is a significant difference between 'why does it not work' and 'why is there no sysfs entry'.

The former (especially together with a non-descriptive debug message under omapdss.debug), indicates that it should work (interface present) but fails to do (for some reason - things like resolutions divisible by 16, integer scaling coefficients, etc were running through my head from past experience with scaler hardware).

The latter indicates that it shouldn't work (as intended by the developers - not present, not tested) - at least I'd be more likely to dig into TRM without assuming that it should be working (since someone put the interface to support it).

Best Regards,
Tomasz