Re: [PATCH] OMAPDSS: VENC: allow switching venc type at runtime

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2012-04-20 at 13:49 +0300, Grazvydas Ignotas wrote:
> On Fri, Apr 20, 2012 at 11:38 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote:
> > On Thu, 2012-03-29 at 02:45 +0300, Grazvydas Ignotas wrote:
> >> VENC type (composite/svideo) doesn't have to be fixed by board wiring,
> >> it is possible to provide both connectors, which is what pandora does.
> >> Having to recompile the kernel for users who have TV connector types
> >> that's don't match default board setting is very inconvenient, especially
> >
> > You don't have to recompile the kernel, you could just set the venc type
> > in the board file depending on a boot parameter.
> >
> >> for users of a consumer device, so add support for switching VENC type
> >> at runtime over a new sysfs file venc_type.
> >
> > I really dislike adding new custom sysfs entries for omapdss, and I'd
> > like to avoid them if at all possible.
> 
> Well some panels already have custom attributes, and venc could be
> considered as special panel type, so if it's allowed for panels, why
> not allow it for venc?

It's not really about "allowing". It's just that each new sysfs file is
a new non-standard custom API to userspace which we need to support
until the end of time. Adding new sysfs files carelessly will cause a
nightmare for me in the future, so by default I'm against new sysfs
files =).

> > Do you need to change the venc
> > type during runtime, or is it enough that it can be set during boot?
> 
> We need this on runtime, otherwise it causes several issues:
> - reboot is required to change the setting, although there is no
> technical reason to really require it. This punishes users who want to
> try both settings or have both TV types (with a portable device this
> may sometimes happen).
> - having to provide a way for users to change this in kernel boot
> arguments. Note that many pandora users don't know how to handle boot
> scripts, so a bootloader menu of some sort would be needed or ability
> to edit u-boot environment from Linux, both of which would be
> needlessly complicated solutions.

Ok. Sounds like we need to have dynamic configuration. I'll review the
patch.

 Tomi

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux