On 05/09/2011 01:55 AM, Martin Vidovic wrote:
> Hi Andreas,
>
> Andreas Oberritter wrote:
>> Hello Martin,
>>
>>>
>>> Binding to bus id is not a problem. However, especially for USB devices,
>>> it may be useful to have adapter MAC address in sysfs.
>>
>> a DVB adapter isn't required to have a uni
Hi Andreas,
Andreas Oberritter wrote:
Hello Martin,
Binding to bus id is not a problem. However, especially for USB devices,
it may be useful to have adapter MAC address in sysfs.
a DVB adapter isn't required to have a unique MAC address, but we could
add this attribute to sysfs, if present
Hello Martin,
On 05/08/2011 12:05 PM, Martin Vidovic wrote:
> Andreas Oberritter wrote:
>> On 05/05/2011 04:43 PM, Martin Vidovic wrote:
>>>
>>> a) Plug two TerraTec Cinergy T RC MKII and try to distinguish between
>>> them.
>>
>> I don't have any USB or PCI hardware within reach, but if udev is a
On 08/05/11 11:53, Andreas Oberritter wrote:
> Hello Issa,
>
> On 05/06/2011 08:29 PM, Issa Gorissen wrote:
>> From: Andreas Oberritter
>>> On 05/06/2011 03:47 PM, Issa Gorissen wrote:
Also, it seems linux en50221 stack provides for the slot selection. So,
>> why
would you need two ca no
Andreas Oberritter wrote:
On 05/05/2011 04:43 PM, Martin Vidovic wrote:
a) Plug two TerraTec Cinergy T RC MKII and try to distinguish between them.
I don't have any USB or PCI hardware within reach, but if udev is able
to create the devices, there should be some way to connect adapters to
the
Hello Issa,
On 05/06/2011 08:29 PM, Issa Gorissen wrote:
> From: Andreas Oberritter
>> On 05/06/2011 03:47 PM, Issa Gorissen wrote:
>>> Also, it seems linux en50221 stack provides for the slot selection. So,
> why
>>> would you need two ca nodes ?
>>
>> Because it's the most obvious way to use it
From: Andreas Oberritter
> On 05/06/2011 03:47 PM, Issa Gorissen wrote:
> > From: Andreas Oberritter
> >>> The best would be to create independent adapters for each independent
CA
> >>> device (ca0/caio0 pair) - they are independent after all (physically
and
> >>> in the way they're used).
> >>
>
On 05/06/2011 03:47 PM, Issa Gorissen wrote:
> From: Andreas Oberritter
>>> The best would be to create independent adapters for each independent CA
>>> device (ca0/caio0 pair) - they are independent after all (physically and
>>> in the way they're used).
>>
>> Physically, it's a general purpose T
Hi,
On Fri, 06 May 2011 14:17:11 +0200, Andreas Oberritter
wrote:
> On 05/05/2011 04:43 PM, Martin Vidovic wrote:
>> Hi,
>>
>> Broadly speaking, I could put issues discussed in this thread into
>> following categories:
>>
>> - How devices are named;
>> - How devices are used;
>> - How devices
From: Andreas Oberritter
> > The best would be to create independent adapters for each independent CA
> > device (ca0/caio0 pair) - they are independent after all (physically and
> > in the way they're used).
>
> Physically, it's a general purpose TS I/O interface of the nGene
> chipset. It just
On 05/05/2011 04:43 PM, Martin Vidovic wrote:
> Hi,
>
> Broadly speaking, I could put issues discussed in this thread into
> following categories:
>
> - How devices are named;
> - How devices are used;
> - How devices relate to one another;
> - How devices are enumerated;
> - How devices are desc
Hi,
Broadly speaking, I could put issues discussed in this thread into
following categories:
- How devices are named;
- How devices are used;
- How devices relate to one another;
- How devices are enumerated;
- How devices are described;
Mostly we discuss category 1 and 2 with relation to nGE
From: Andreas Oberritter
>
> I don't think this is going to happen, as nobody really seems to care
> (me included). I was just pointing out ways that I consider more likely
> to succeed.
>
> Regards,
> Andreas
If you don't care, why fueling all this fuss ???
--
To unsubscribe from this list:
On 05/04/2011 03:35 PM, Martin Vidovic wrote:
>>
>>> Or is there a standard way this is supposed to be handled?
>>
>> Yes. Since ages. The ioctl is called DMX_SET_SOURCE.
>
> DMX_SET_SOURCE seems to not be implemented anywhere, all it does is
> return EINVAL. I also fail to find any useful documen
On 05/04/2011 04:05 PM, Issa Gorissen wrote:
> From: Andreas Oberritter
>> It wouldn't have multiple adapters numbers either.
>
> What do you mean by they shouldn't have mulitple adapters numbers ? Multiple
> WinTV-CI devices should have distinct node parents, ie
> /dev/dvb/adapter[01]/
I wrote
From: Andreas Oberritter
> >> Last but not least, using a different adapter number wouldn't fit
> >> either, because a DVB adapter is supposed to
> >> - be one independent piece of hardware
> >> - provide at least a frontend and a demux device
> >
> >
> > How would you support device like the Ha
On 05/04/2011 01:07 PM, Issa Gorissen wrote:
> From: Andreas Oberritter
>>
>> Of course I'm referring to devices connected to the same physical
>> adapter. Otherwise they would all be called ca0. Device enumeration
>> always starts at 0, for each adapter. What you're describing just
>> doesn't mak
Or is there a standard way this is supposed to be handled?
Yes. Since ages. The ioctl is called DMX_SET_SOURCE.
DMX_SET_SOURCE seems to not be implemented anywhere, all it does is
return EINVAL. I also fail to find any useful documentation about what
it is supposed to do.
There are no
Andreas Oberritter writes:
> > Of course it does since it is not feasible to use the same adapter
> > number even on the same card when it provides multi-standard
> > frontends which share dvr and demux devices. E.g., frontend0 and
> > frontend1 can belong to the same demod which can be DVB-C
On 05/04/2011 01:20 PM, Ralph Metzler wrote:
> Andreas Oberritter writes:
> > > - ca0 would be reached from /dev/dvb/adapter0/ca0
> > > - ca[12], depending on if they are connected to the same physical adapter
> > > (PCI, USB, ...), would be reached from /dev/dvb/adapter1/ca[12] or
> > > /dev/d
Andreas Oberritter writes:
> > - ca0 would be reached from /dev/dvb/adapter0/ca0
> > - ca[12], depending on if they are connected to the same physical adapter
> > (PCI, USB, ...), would be reached from /dev/dvb/adapter1/ca[12] or
> > /dev/dvb/adapter1/ca1 and /dev/dvb/adapter2/ca2 and there res
From: Mauro Carvalho Chehab
>
> It is not that simple. The question is not just how to name the interface,
> but that such interface will work on a different way than the current
> ca interface.
>
> In other words, the DVB API should clearly explain why this
> interface is different, when it s
From: Andreas Oberritter
>
> Of course I'm referring to devices connected to the same physical
> adapter. Otherwise they would all be called ca0. Device enumeration
> always starts at 0, for each adapter. What you're describing just
> doesn't make sense.
Yes indeed you're right, I answered too
On 05/04/2011 10:27 AM, Issa Gorissen wrote:
> From: Andreas Oberritter
>> Also, there's still no mapping between ca and caio devices. Imagine a
>> built-in descrambler ca0 and two CI slots ca1 and ca2.
>>
>> ca0 won't get a caio device, at least for now.
>> ca1 and ca2 might or might not have a c
From: Andreas Oberritter
> Also, there's still no mapping between ca and caio devices. Imagine a
> built-in descrambler ca0 and two CI slots ca1 and ca2.
>
> ca0 won't get a caio device, at least for now.
> ca1 and ca2 might or might not have a caio device.
>
> If there is caio0, how am I suppos
On 05/04/2011 01:11 AM, Mauro Carvalho Chehab wrote:
> Em 24-04-2011 08:38, Issa Gorissen escreveu:
>> On 28/03/11 23:40, Mauro Carvalho Chehab wrote:
>>> Em 27-03-2011 21:44, Ralph Metzler escreveu:
Hi,
since I just saw cxd2099 appear in staging in the latest git kernel, a
simp
Em 24-04-2011 08:38, Issa Gorissen escreveu:
> On 28/03/11 23:40, Mauro Carvalho Chehab wrote:
>> Em 27-03-2011 21:44, Ralph Metzler escreveu:
>>> Hi,
>>>
>>> since I just saw cxd2099 appear in staging in the latest git kernel, a
>>> simple question which has been pointed out to me before:
>>>
>>>
On 28/03/11 23:40, Mauro Carvalho Chehab wrote:
> Em 27-03-2011 21:44, Ralph Metzler escreveu:
>> Hi,
>>
>> since I just saw cxd2099 appear in staging in the latest git kernel, a
>> simple question which has been pointed out to me before:
>>
>> Why is cxd2099.c in staging regarding the device name
On 28/03/11 23:40, Mauro Carvalho Chehab wrote:
> Em 27-03-2011 21:44, Ralph Metzler escreveu:
>> Hi,
>>
>> since I just saw cxd2099 appear in staging in the latest git kernel, a
>> simple question which has been pointed out to me before:
>>
>> Why is cxd2099.c in staging regarding the device name
Hello all,
Here is the patch for the NGene card family and the new caio device
Signed-off-by: Issa Gorissen
---
drivers/media/dvb/dvb-core/dvbdev.c |2 +-
drivers/media/dvb/dvb-core/dvbdev.h |1 +
drivers/media/dvb/ngene/ngene-core.c |2 +-
3 files changed, 3 insertions(+), 2 dele
On Monday 28 March 2011 02:44:14 Ralph Metzler wrote:
> Hi,
>
> since I just saw cxd2099 appear in staging in the latest git kernel, a
> simple question which has been pointed out to me before:
>
> Why is cxd2099.c in staging regarding the device name question?
> It has nothing to do with the nam
Em 27-03-2011 21:44, Ralph Metzler escreveu:
> Hi,
>
> since I just saw cxd2099 appear in staging in the latest git kernel, a
> simple question which has been pointed out to me before:
>
> Why is cxd2099.c in staging regarding the device name question?
> It has nothing to do with the naming.
It
Hi,
since I just saw cxd2099 appear in staging in the latest git kernel, a
simple question which has been pointed out to me before:
Why is cxd2099.c in staging regarding the device name question?
It has nothing to do with the naming.
Regards,
Ralph
--
To unsubscribe from this list: send the lin
Issa Gorissen wrote:
On 13/03/11 11:47, Martin Vidovic wrote:
Btw, we should choose a more meaningful name for 'camX'.
I would prefer something like cainoutX or caioX or cinoutX or cioX.
I agree, camX could be misleading since it's not necessarily a CAM
application.
According to E
On 13/03/11 11:47, Martin Vidovic wrote:
>>
>> Btw, we should choose a more meaningful name for 'camX'.
>> I would prefer something like cainoutX or caioX or cinoutX or cioX.
>>
>
>
> I agree, camX could be misleading since it's not necessarily a CAM
> application.
>
> According to EN 50221 the
Oliver Endriss wrote:
Hi,
On Saturday 12 March 2011 14:29:08 Andreas Oberritter wrote:
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 a
Hi,
On Saturday 12 March 2011 14:29:08 Andreas Oberritter wrote:
> 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
From: Andreas Oberritter
>
> I'm not against adding a new node if its behaviour is well defined and
> documented and if it integrates well into the existing API.
Integration is okay; current API is left untouched.
The behaviour is defined as a write encrypted stream / read decrypted stream
devi
On 03/12/2011 03:57 PM, Martin Vidovic wrote:
> Andreas Oberritter wrote:
>> On 03/12/2011 03:10 PM, Issa Gorissen wrote:
>>
>>> From: Andreas Oberritter
>>>
On 03/11/2011 10:44 PM, Martin Vidovic wrote:
> Andreas Oberritter wrote:
>
>> It's rather unintui
Andreas Oberritter writes:
> > 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
On 03/12/2011 03:34 PM, Issa Gorissen wrote:
> From: Ralph Metzler
>> Andreas Oberritter writes:
>> > > Unless you want to move the writing to/reading from the CI module into
>> > > ioctls of the ci device you need another node.
>> > > Even nicer would be having the control messages moved to i
Andreas Oberritter wrote:
On 03/12/2011 03:10 PM, Issa Gorissen wrote:
From: Andreas Oberritter
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
On 03/12/2011 03:10 PM, Issa Gorissen wrote:
> From: Andreas Oberritter
>> 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).
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 an
From: Ralph Metzler
> Andreas Oberritter writes:
> > > Unless you want to move the writing to/reading from the CI module into
> > > ioctls of the ci device you need another node.
> > > Even nicer would be having the control messages moved to ioctls and
the
> > > TS IO in read/write of ci, but
From: Andreas Oberritter
> 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
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 se
Andreas Oberritter writes:
> > Unless you want to move the writing to/reading from the CI module into
> > ioctls of the ci device you need another node.
> > Even nicer would be having the control messages moved to ioctls and the
> > TS IO in read/write of ci, but this would break the old inter
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
On 03/11/2011 10:46 PM, Ralph Metzler wrote:
> Andreas Oberritter writes:
> > >> On 03/10/2011 04:29 PM, Issa Gorissen wrote:
> > > Now, according to Mauro comments, he has put this code into staging
> because of
> > > the usage of sec0 name for a cam device.
> > >
> > > Please comment on Ol
Andreas Oberritter wrote:
On 03/10/2011 04:29 PM, Issa Gorissen wrote:
As the cxd20099 driver is in staging due to abuse of the sec0 device, this
patch renames it to cam0. The sec0 device is not in use and can be removed
That doesn't solve anything. Besides, your patch doesn't even do
Andreas Oberritter writes:
> >> On 03/10/2011 04:29 PM, Issa Gorissen wrote:
> > Now, according to Mauro comments, he has put this code into staging
> > because of
> > the usage of sec0 name for a cam device.
> >
> > Please comment on Oliver's explanations from this thread
> >
> > http:/
>> On 03/10/2011 04:29 PM, Issa Gorissen wrote:
>>> As the cxd20099 driver is in staging due to abuse of the sec0 device,
> this
>>> patch renames it to cam0. The sec0 device is not in use and can be
> removed
>>
>> That doesn't solve anything. Besides, your patch doesn't even do what
>> you descri
From: Andreas Oberritter
To: Issa Gorissen Cc: linux-media@vger.kernel.org,
r...@metzlerbros.de
Subject: Re: [PATCH] Ngene cam device name
> On 03/10/2011 04:29 PM, Issa Gorissen wrote:
> > As the cxd20099 driver is in staging due to abuse of the sec0 device,
this
> > patch ren
On 03/10/2011 04:29 PM, Issa Gorissen wrote:
> As the cxd20099 driver is in staging due to abuse of the sec0 device, this
> patch renames it to cam0. The sec0 device is not in use and can be removed
That doesn't solve anything. Besides, your patch doesn't even do what
you describe.
Wouldn't it be
As the cxd20099 driver is in staging due to abuse of the sec0 device, this
patch renames it to cam0. The sec0 device is not in use and can be removed
Signed-off-by: Issa Gorissen
---
drivers/media/dvb/dvb-core/dvbdev.h |2 +-
drivers/media/dvb/ngene/ngene-core.c |2 +-
2 files changed,
56 matches
Mail list logo
