public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Oberritter <obi@linuxtv.org>
To: Ralph Metzler <rjkm@metzlerbros.de>
Cc: Martin Vidovic <xtronom@gmail.com>, linux-media@vger.kernel.org
Subject: Re: [PATCH] Ngene cam device name
Date: Sat, 12 Mar 2011 15:38:01 +0100	[thread overview]
Message-ID: <4D7B8549.2090008@linuxtv.org> (raw)
In-Reply-To: <19835.32151.116648.554824@morden.metzler>

On 03/12/2011 03:05 PM, Ralph Metzler wrote:
> Andreas Oberritter writes:
>  > On 03/11/2011 10:44 PM, Martin Vidovic wrote:
>  > > Andreas Oberritter wrote:
>  > >> It's rather unintuitive that some CAMs appear as ca0, while others as
>  > >> cam0.
>  > >>   
>  > > Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used
>  > > as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write
>  > > transport stream. To me it  looks like an extension of the current API.
>  > 
>  > I see. This raises another problem. How to find out, which ca device
>  > cam0 relates to, in case there are more ca devices than cam devices?
>  > 
> 
> They should be in different adapterX directories. 
> Even on the cards where you can connect up to 4 dual frontends or CAM adapters
> I currently use one adapter directory for every frontend and CAM.

That looks like a hack to me, that may work well for your PC style
adapter, e.g frontends and CAMs attached to PCI or USB. But how would
you integrate audio and video decoders and hardware demux devices into
that scenario? Would you expect adapterN's frontend to be able to feed a
TS into adapterN+1's hardware demux and then into adapterN+2's video
decoder?

> If you want to "save" adapters one could put them in the same
> directory and caX would belong to camX. 
> More ca than cam devices could only occur on cards with mixed old and
> new style hardware. I am not aware of such cards.

DVB descramblers use ca devices, too. So it's certainly possible to occur.

And even if no hardware exists that uses CAM slots with such different
capabilities, we should be prepared when such hardware appears.

> I think there are cards with dual frontend and two CAM adapters where
> normally data from frontendX is passed through caX (they are in the same adapter
> directory) but the paths can also be switched. I do not now how this is
> handled.

On our STB platform. we have four frontends and four CAM slots.
Frontends and CAM slots get connected on demand or even chained to allow
multiple CAMs to try to decode parts of the same TS. I don't see how
multiple adapters could fit in that situation.

Regards,
Andreas

  reply	other threads:[~2011-03-12 14:38 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-10 15:29 [PATCH] Ngene cam device name Issa Gorissen
2011-03-11 15:52 ` Andreas Oberritter
2011-03-11 21:44   ` Martin Vidovic
2011-03-12 13:29     ` Andreas Oberritter
2011-03-12 14:05       ` Ralph Metzler
2011-03-12 14:38         ` Andreas Oberritter [this message]
2011-03-12 15:06           ` Ralph Metzler
2011-03-12 23:42       ` Oliver Endriss
2011-03-13 10:47         ` Martin Vidovic
2011-03-16 22:07           ` Issa Gorissen
2011-03-18 20:20             ` Martin Vidovic
  -- strict thread matches above, loose matches on Subject: below --
2011-03-11 18:33 Issa Gorissen
2011-03-11 20:39 ` Andreas Oberritter
2011-03-11 21:46   ` Ralph Metzler
2011-03-12 13:25     ` Andreas Oberritter
2011-03-12 13:55       ` Ralph Metzler
2011-03-12 14:10 Issa Gorissen
2011-03-12 14:48 ` Andreas Oberritter
2011-03-12 14:57   ` Martin Vidovic
2011-03-12 15:06     ` Andreas Oberritter
2011-03-12 14:34 Issa Gorissen
2011-03-12 14:58 ` Andreas Oberritter
2011-03-28  0:44   ` Ralph Metzler
2011-03-28 21:40     ` Mauro Carvalho Chehab
2011-04-24  9:31       ` Issa Gorissen
2011-03-28 22:57     ` Oliver Endriss
2011-04-05 21:50       ` Issa Gorissen
2011-03-12 15:39 Issa Gorissen
2011-04-24 11:38 Issa Gorissen
2011-05-03 23:11 ` Mauro Carvalho Chehab
2011-05-04  7:24   ` Andreas Oberritter
2011-05-04  8:27 Issa Gorissen
2011-05-04  9:59 ` Andreas Oberritter
2011-05-04 11:20   ` Ralph Metzler
2011-05-04 12:30     ` Andreas Oberritter
2011-05-04 13:15       ` Ralph Metzler
2011-05-04 13:35       ` Martin Vidovic
2011-05-04 14:46         ` Andreas Oberritter
2011-05-05 14:43           ` Martin Vidovic
2011-05-06 12:17             ` Andreas Oberritter
2011-05-06 13:43               ` Walter Van Eetvelt
2011-05-08 10:05               ` Martin Vidovic
2011-05-08 17:58                 ` Andreas Oberritter
2011-05-08 23:55                   ` Martin Vidovic
2011-05-09 11:44                     ` Andreas Oberritter
2011-05-04 11:07 Issa Gorissen
2011-05-04 13:51 ` Andreas Oberritter
2011-05-04 11:09 Issa Gorissen
2011-05-04 14:05 Issa Gorissen
2011-05-04 14:27 ` Andreas Oberritter
2011-05-04 14:51 Issa Gorissen
2011-05-06 13:47 Issa Gorissen
2011-05-06 16:07 ` Andreas Oberritter
2011-05-06 18:29 Issa Gorissen
2011-05-08  9:53 ` Andreas Oberritter
2011-05-08 10:30   ` Issa Gorissen

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=4D7B8549.2090008@linuxtv.org \
    --to=obi@linuxtv.org \
    --cc=linux-media@vger.kernel.org \
    --cc=rjkm@metzlerbros.de \
    --cc=xtronom@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox