Em Wed, 02 Mar 2016 12:28:10 +0100
Hans Verkuil <hverkuil@xxxxxxxxx> escreveu:
> On 03/02/16 12:16, Laurent Pinchart wrote:
> > Hi Mauro,
> >
> > On Wednesday 02 March 2016 08:13:23 Mauro Carvalho Chehab wrote:
> >> Em Wed, 02 Mar 2016 12:34:42 +0200 Laurent Pinchart escreveu:
> >>> On Friday 26 February 2016 09:13:17 Mauro Carvalho Chehab wrote:
> >
> > [snip]
> >
> >>>> NOTE:
> >>>>
> >>>> The labels at the PADs currently can't be represented, but the
> >>>> idea is adding it as a property via the upcoming properties API.
> >>>
> >>> Whether to add labels to pads, and more generically how to differentiate
> >>> them from userspace, is an interesting question. I'd like to decouple it
> >>> from the connectors entities discussion if possible, in such a way that
> >>> using labels wouldn't be required to leave the discussion open on that
> >>> topic. If we foresee a dependency on labels for pads then we should open
> >>> that discussion now.
> >>
> >> We can postpone such discussion. PAD labels are not needed for
> >> what we have so far (RF, Composite, S-Video). Still, I think that
> >> we'll need it by the time we add connector support for more complex
> >> connector types, like HDMI.
> >
> > If we don't add pad labels now then they should be optional for future
> > connectors too, including HDMI. If you think that HDMI connectors will require
> > them then we should discuss them now.
> >
>
> Pad labels are IMHO only useful for producing human readable output. For complex
> designs that helps a lot to understand what is going on.
>
> But for kernel/applications all you need are #defines with the pad numbers (e.g.
> HDMI_PAD_TMDS, HDMI_PAD_CEC, HDMI_PAD_ARC) to use for connectors.
As we add complexity to MC graph, just hardcoding PAD numbers don't work
fine even at the Kernel level.
Basically, what we currently call as "PAD number", is actually a PAD
number+type, as different PADs have different types/functions on most
cases.
Any code that needs to connect PADs need to know which type corresponds
to a pad number on a given entity.
See for example the code at : it only
works because we've created a generic enum demod_pad_index that
is been used by the analog TV demods currently supported by the
drivers that enable the MC API.
There, we had to standardize the PAD numbers for the analog TV
demod, as we need to be able to link the connectors for v4l2-interface
centric devices, in order to have a generic function to build the
links:
enum demod_pad_index {
DEMOD_PAD_IF_INPUT,
DEMOD_PAD_VID_OUT,
DEMOD_PAD_VBI_OUT,
DEMOD_NUM_PADS
};
(I'll ommit DEMOD_NUM_PADS on the discussions below, just to make
the enums clearer)
Due to S-Video, we'll need to add an extra input PAD there
(and one extra PAD for audio output - currently only supported
by au0828 driver):
enum demod_pad_index {
/* Input PADs */
DEMOD_PAD_IF_INPUT, /* Composite or Y input */
DEMOD_PAD_C_INPUT,
/* Output PADs*/
DEMOD_PAD_VID_OUT,
DEMOD_PAD_VBI_OUT,
DEMOD_PAD_AUDIO_OUT,
};
But, an HDMI-only demod would need, instead:
enum hdmi_demod_pad_index {
/* HDMI-specific input PADs*/
DEMOD_HDMI_PAD_TMDS,
DEMOD_HDMI_PAD_CEC,
DEMOD_HDMI_PAD_ARC,
/* Output PADs */
DEMOD_HDMI_PAD_VID_OUT,
DEMOD_HDMI_PAD_VBI_OUT,
DEMOD_HDMI_PAD_AUDIO_OUT,
};
If we do that, an extra logic to handle the "HDMI" special case
would need at v4l2_mc_create_media_graph(), and we'll need to
use a different function for such entity, for it to work.
A demod capable of handling both HDMI and analog TV would need a mix
of the above enums:
enum hdmi_and_composite_demod_pad_index {
/* HDMI-specific input PADs*/
DEMOD2_PAD_HDMI_TMDS,
DEMOD2_PAD_HDMI_CEC,
DEMOD2_PAD_HDMI_ARC,
/* non-HDMI Input PADs */
DEMOD2_PAD_IF_INPUT, /* Composite or Y input */
DEMOD2_PAD_C_INPUT,
/* Output PADs */
DEMOD2_PAD_VID_OUT,
DEMOD2_PAD_VBI_OUT,
};
Again, we'll need an extra logic v4l2_mc_create_media_graph(), and
a different function for the entity.
We could, instead, just add those new PADs at the existing
enum demod_pad_index, but, if add pad numbers to existing enums,
we will be breaking binary compatibility on every new release,
and entities will be exporting PADs that the hardware don't support.
The same trouble will happen also at userspace side, as a generic
application written to work with subdev-centric devices would need to
know the PAD numbers for each PAD type and for each entity type.
Also, a given entity type would need to have a fixed number of PADs,
and such pad numbers are actually part of the uAPI/ABI.
So, IMHO, the proper fix is to create, inside the Kernel, a PAD type
field, with will be used by the Kernel generic functions and allow each
driver to create as many PADs it needs, without needing to add
PADs for non-supported types. So, a demod like saa7115 will never have
DEMOD_HDMI_PAD_*. It will be driver's responsibility to fill the PAD
type for each PAD.
The core will then use the PAD type to create the pads via
v4l2_mc_create_media_graph().
For a generic mc-centric application, the PAD type (or PAD label?)
will need to be exported to userspace, for the userspace logic
that would be equivalent to what's done at v4l2_mc_create_media_graph().
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
