Re: [PATCH v4 0/6] MC preparation patches

[Mauro Carvalho Chehab <mchehab@osg.samsung.com>]

Em Sat, 15 Aug 2015 01:37:44 +0300
Sakari Ailus <sakari.ailus@iki.fi> escreveu:

> Hi Mauro,
> 
> On Fri, Aug 14, 2015 at 11:56:37AM -0300, Mauro Carvalho Chehab wrote:
> > Those are the initial patches from my previous series of MC changes.
> > 
> > The first patch removes an unused parameter when creating links.
> > 
> > The next 5 patches warrant that all object types (entities, pads and
> > links) will have an unique ID, as agreed at the MC workshop.
> > 
> > They prepare for the addition of the media interfaces and interface
> > links.
> 
> Having looked the set through, I don't think the patches in the set are
> strictly necessary for adding media interfaces. Again, I need to stress I'd
> very much prefer to keep things simple in order to get support for media
> interfaces in soon, as I understand your intention is as well.

Well, the new API we've agreed requires unique IDs. So, those patches are
a mandatory requirement. Also, the ID is a requirement for links (see
patch 9/16 and latter patches on my RFC v3).

> We could make things more dynamic later on, and represent associations using
> links --- if there's a use case for that.
> 
> I don't as such object the patchset, but my question is: where will this all
> lead to? I'd like to see that, or at least some more, before finally acking
> the patches. I sense these should be closely related to supporting the
> property API rather than media interfaces (or DVB), but unfortunately I
> won't have time to work on the property API for the following ~ three weeks.

Well my goals are different then yours and so my test environment.

Currently, I have only the hybrid PC-consumer TV devices handy for test
and my goal is to address what's needed for them to be properly and fully
supported. Nothing more, nothing less.

Yet, I'm aiming to future support TV sets and Set Top Boxes. Even the
simpler of such hardware would be at least 4x or 5x more complex than
a PC consumer devices. So, whenever I need to take some design decision,
I'll have those complex hardware in mind.

With regards to properties, I don't intend to touch on them. Those are
on your action items, so I'm counting that you'll be doing that ;)

I might need to add something to internally replace the entity->type on
some future patch, but I'm not there yet, and, if I need to do, I'll
try to do the minimal amount required for my patches to work.

> struct media_interface could be pointed to from entities using a statically
> allocated array of pointers, a bit like links (except that they're not
> pointers). I think we'd get quite far with this already while making much
> fewer changes to the framework.

No, I won't be coding links using arrays, nor using a different
struct to represent the links. We need dynamic link addition/removal.
Doing it using realloc would fragment the memory and cause lots of
harm.

So, my plan is do it right, in a way that will allow us to share the
same code and data model, and to future allow graph traversals though
interface links too. Graph traversal using both pad/pad and interface/entity
links is needed to properly address conflicts when multiple drivers and
multiple interfaces may control the same piece of the hardware.

> One thing that wasn't discussed at length in the meeting, but which I
> understood was generally agreed on, was DMA engines as entities (vs. having
> a pad for the sake of the interface in the video node entity, which is
> ugly). IMHO a sound foundation is important for the proposed changes.

Not sure if I understood. Anyway, the comments below are actually
unrelated to this patch series, and looks more like a RFC ;)

---

At the V4L2 case, DMA engines will be mapped as entities (on non-USB
hardware). We still need to agree how we'll name such entities.

It should be noticed that:

- On V4L2, the video/VBI stream output is not the DMA engine. The DMA
engine is actually linked to the USB EHCI/UHCI/xHCI driver. the
USB driver sends a block of data to the V4L2 driver, with decapsulate
the data packages and copy into a transfer buffer. Such buffer
is mapped to userspace or made available via I/O (read() sysctl).

- Some hardware may not provide a stream sink. This is the case of
  DVB devices that are compliant with the ETSI encryption standards.
  All userspace can do is to control the pipeline to direct the
  unencrypted streams to the GPU and to the ASoC hardware;

- On DVB, the DMA is internal to the Kernel, even on PCI/SoC
  hardware. The Kernel splits the Transport Stream data into
  several ring buffers. The ring buffers are sent to userspace -
  currently, only via I/O (read() sysctl. We're planning to improve
  it, but we need to keep supporting the old way, as several hardware
  can only work on that mode;

- On Radio, it may or may not have DMA. Some devices work via
  reading the audio samples on some register. This can even be done
  on some firmware inside the device. The radio output can be:
	- a wire from the radio board into the Motherboard's audio
	  card;
	- an I/O read() operation at ALSA.

So, I won't be calling the hardware that may or may not be doing
DMA as "DMA". I guess we can simply call it as:

For output:
	- video stream output
	- vbi stream output
	- TS stream output
	- audio stream playback

For input:
	- video stream capture
	- vbi stream capture
	- TS stream capture
	- audio stream capture

Or something equivalent.

Just my 2 euro cents ;)


> 
> Just my one euro cent --- got some left from Italy. :-)
>