All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marko Ristola <marko.ristola@kolumbus.fi>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
	linux-media@vger.kernel.org,
	sakari.ailus@maxwell.research.nokia.com
Subject: Re: [RFC/PATCH v3 06/10] media: Entities, pads and links enumeration
Date: Wed, 04 Aug 2010 22:28:22 +0300	[thread overview]
Message-ID: <4C59BF56.903@kolumbus.fi> (raw)
In-Reply-To: <201008031122.55036.laurent.pinchart@ideasonboard.com>


Hi Hans and Laurent.

I hope my thoughts help you further.

03.08.2010 12:22, Laurent Pinchart wrote:
> Hi Hans,
>
> On Monday 02 August 2010 23:01:55 Hans Verkuil wrote:
>> On Monday 02 August 2010 16:35:54 Laurent Pinchart wrote:
>>> On Sunday 01 August 2010 13:58:20 Hans Verkuil wrote:
>>>> On Thursday 29 July 2010 18:06:39 Laurent Pinchart wrote:
>>> [snip]
>>>
[snip]
>> It's a possibility, but it's always a bit of a hassle in an application to
>> work with group IDs. I wonder if there is a more elegant method.
> The problem is a bit broader than just showing relationships between video
> nodes and ALSA devices. We also need to show relationships between lens/flash
> controllers and sensors for instance. Group IDs sound easy, but I'm open to
> suggestions.

Low level example

DVB I2C bus is easy: get all I2C devices from an entity (DVB demuxer).
Some external chip (entity, the tuner) might be behind some I2C bridge 
device.

With I2C you need to know the characteristics, how you talk with
the destination device via the bus (extra sleeps, clock speed,
quiesce the whole bus for 50ms after talking to the slave device).
I'd like that each device would describe how it should be
talked to via the bus.

On i2c_transfer you could hide opening and closing the I2C bridge, and hide
the callbacks for extra sleeps so that the main driver and core 
framework code is free from such ugly details.
By storing entity's special requirements inside of it, you could reuse 
the callbacks with another product variant.

With I2C, an array of I2C slave devices that are reachable via I2C bus 
would work for controlling the device
rather nicely.

Higher abstraction level

So detailed descriptions and bus knowledge is needed for controlling 
each entity and pad.
That hierarchy is a bit different than optimal hierarchy of how the 
streams can flow
into, within and out from the entity (the driver). Buses are the 
gateways for the data stream flows,
shared by two or more entities/pads by links.

Thus I'd suggest to separate these two hierarchies (initialization time 
hierarchy and
stream flow capability hierarchy) at necessary points, and use buses
to bind the entities/pads by links to each other.

A single wire with just two end points can also be thought like a bus.

Regards,
Marko Ristola

[ snip ]


  reply	other threads:[~2010-08-04 19:28 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-29 16:06 [RFC/PATCH v3 00/10] Media controller (core and V4L2) Laurent Pinchart
2010-07-29 16:06 ` [RFC/PATCH v3 01/10] media: Media device node support Laurent Pinchart
2010-08-01 11:14   ` Hans Verkuil
2010-08-02 13:55     ` Laurent Pinchart
2010-07-29 16:06 ` [RFC/PATCH v3 02/10] media: Media device Laurent Pinchart
2010-07-29 16:06 ` [RFC/PATCH v3 03/10] media: Entities, pads and links Laurent Pinchart
2010-07-30 14:00   ` Sakari Ailus
2010-08-02 14:05     ` Laurent Pinchart
2010-08-01 11:32   ` Hans Verkuil
2010-08-02 14:19     ` Laurent Pinchart
2010-07-29 16:06 ` [RFC/PATCH v3 04/10] media: Entity graph traversal Laurent Pinchart
2010-07-29 16:06 ` [RFC/PATCH v3 05/10] media: Reference count and power handling Laurent Pinchart
2010-07-29 16:06 ` [RFC/PATCH v3 06/10] media: Entities, pads and links enumeration Laurent Pinchart
2010-08-01 11:58   ` Hans Verkuil
2010-08-02 14:35     ` Laurent Pinchart
2010-08-02 21:01       ` Hans Verkuil
2010-08-03  9:22         ` Laurent Pinchart
2010-08-04 19:28           ` Marko Ristola [this message]
2010-08-05  9:38             ` Laurent Pinchart
2010-08-05 19:45               ` Marko Ristola
2010-07-29 16:06 ` [RFC/PATCH v3 07/10] media: Links setup Laurent Pinchart
2010-07-29 16:06 ` [RFC/PATCH v3 08/10] v4l: Add a media_device pointer to the v4l2_device structure Laurent Pinchart
2010-07-29 16:06 ` [RFC/PATCH v3 09/10] v4l: Make video_device inherit from media_entity Laurent Pinchart
2010-07-29 16:06 ` [RFC/PATCH v3 10/10] v4l: Make v4l2_subdev " Laurent Pinchart
2010-07-29 16:06 ` [SAMPLE v3 00/12] V4L2 API additions and OMAP3 ISP driver Laurent Pinchart
2010-07-29 16:06 ` [SAMPLE v3 01/12] v4l: Move the media/v4l2-mediabus.h header to include/linux Laurent Pinchart
2010-07-29 16:06 ` [SAMPLE v3 02/12] v4l: Add 16 bit YUYV and SGRBG10 media bus format codes Laurent Pinchart
2010-07-29 16:06 ` [SAMPLE v3 03/12] v4l: Create v4l2 subdev file handle structure Laurent Pinchart
2010-07-29 16:06 ` [SAMPLE v3 04/12] v4l-subdev: Add pads operations Laurent Pinchart
2010-07-29 16:06 ` [SAMPLE v3 05/12] v4l: v4l2_subdev userspace format API Laurent Pinchart
2010-07-29 16:06 ` [SAMPLE v3 06/12] v4l: Add subdev userspace API to enumerate and configure frame interval Laurent Pinchart
2010-07-29 16:06 ` [SAMPLE v3 07/12] v4l: Add crop ioctl to V4L2 subdev API Laurent Pinchart
2010-07-29 16:06 ` [SAMPLE v3 08/12] v4l: subdev: Generic ioctl support Laurent Pinchart
2010-07-29 16:06 ` [SAMPLE v3 09/12] ARM: OMAP3: Update Camera ISP definitions for OMAP3630 Laurent Pinchart
2010-07-29 16:06 ` [SAMPLE v3 10/12] omap3: Export omap3isp platform device structure Laurent Pinchart
2010-07-29 16:06 ` [SAMPLE v3 11/12] omap34xxcam: Register the ISP platform device during omap34xxcam probe Laurent Pinchart
2010-08-19 19:09 ` [RFC/PATCH v3 00/10] Media controller (core and V4L2) Aguirre, Sergio
2010-08-19 19:12   ` Laurent Pinchart
2010-08-19 19:13     ` Aguirre, Sergio
2010-08-20 15:25     ` Laurent Pinchart
2010-08-20 15:26       ` Aguirre, Sergio
2010-08-20 15:31         ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C59BF56.903@kolumbus.fi \
    --to=marko.ristola@kolumbus.fi \
    --cc=hverkuil@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=sakari.ailus@maxwell.research.nokia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.