Question about ci drivers in dvb

[loody]

Dear all:
I have read ci.txt under documents/dvb, and at end of it, it mentions
about apdu protocol defined in en50221.
but I cannot see this part of source in dvb_ca_en50221.c.
Is this part implemented at other place or I check the wrong document?
appreciate your help,
miloody
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Uri Shkolnik]

--- On Mon, 4/6/09, Mauro Carvalho Chehab  wrote:

> From: Mauro Carvalho Chehab 
> Subject: Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding 
> model
> To: "Andy Walls" 
> Cc: "hermann pitton" , "Jean Delvare" 
> , "Janne Grunau" , "Hans Verkuil" 
> , "Mike Isely" , is...@isely.net, "LMML" 
> , "Jarod Wilson" 
> Date: Monday, April 6, 2009, 4:51 AM
> On Sun, 05 Apr 2009 18:00:04 -0400
> Andy Walls 
> wrote:
> 
> > On Sun, 2009-04-05 at 23:22 +0200, hermann pitton
> wrote:
> > > Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb
> Jean Delvare:
> > > > On Sun, 05 Apr 2009 14:58:17 -0400, Andy
> Walls wrote:
> > 
> > 
> > > What can not be translated to the input system I
> would like to know.
> > > Andy seems to have closer looked into that.
> > 
> > 1. IR blasting: sending IR codes to transmit out to a
> cable convertor
> > box, DTV to analog convertor box, or similar devices
> to change channels
> > before recording starts.  An input interface
> doesn't work well for
> > output.
> 
> On my understanding, IR output is a separate issue. AFAIK,
> only a very few ivtv
> devices support IR output. I'm not sure how this is
> currently implemented.
> 
> 
> > 2. Sending raw IR samples to user space: user space
> applications can
> > then decode or match an unknown or non-standard IR
> remote protocol in
> > user space software.  Timing information to go
> along with the sample
> > data probably needs to be
> preserved.   I'm assuming the input
> interface
> > currently doesn't support that.
> 
> If the driver processes correctly the IR samples, I don't
> see why you would
> need to pass the raw protocols to userspace. Maybe we need
> to add some ioctls
> at the API to allow certain controls, like, for example,
> ask kernel to decode
> IR using RC4 instead or RC5, on devices that supports more
> than one IR protocol.
> 
> > That's all the Gerd mentioned.
> > 
> > 
> > One more nice feature to have, that I'm not sure how
> easily the input
> > system could support:
> > 
> > 3. specifying remote control code to key/button
> translations with a
> > configuration file instead of recompiling a module.
> 
> The input and the current drivers that use input already
> supports this feature.
> You just need to load a new code table to replace the
> existing one.
> 
> See v4l2-apps/util/keytable.c to see how easy is to change
> a key code. It
> contains a complete code to fully replace a key code table.
> Also, the Makefile
> there will extract the current keytables for the in-kernel
> drivers.
> 
> Btw, with only 12 lines, you can create a keycode replace
> "hello world!":
> 
> #include    
>     /* due to O_RDONLY */
> #include    
>     /* open() */
> #include     /* input
> ioctls and keycode macros */
> #include    
>     /* ioctl() */
> void main(void)
> {
>     int codes[2];
>     int fd = open("/dev/video0",
> O_RDONLY);    /* Hmm.. in real apps, we
> should check for errors */
>     codes[0] = 10;   
>             /*
> Scan code */
>     codes[1] = KEY_UP;   
>         /* Key code */
>     ioctl(fd, EVIOCSKEYCODE,
> codes);    /* hello world! */
> }
> 
> Cheers,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


Hi,

ir-kbd-i2c is a confusing name and wrong architecture if all are truly combined 
together.

Why to combine interface driver (I2C) with logical implementation (RC5 samples 
to input device codes)?

There are many IR hardware devices which are not I2C based. Lately I added a 
patch (http://patchwork.kernel.org/patch/16406/) which uses such IR device.

There should be a complete separation between I2C interface driver with RC5 
(and/or RCMM) data output, to the ir-kbd (RC5/kbd, RCMM/kbd) module, which 
should only convert RC5 sample to system events (either input device/keyboard, 
or IOCTL events sent through the DVB characters devices to user space).

If the code will stay combined (ir-kbd-i2c) than for other than I2C interface 
drivers, we'll have to add a duplicated (redundant) logical layer to handle the 
RC5 to system events layer (which already exist at the ir-kbd-i2c).

Uri


  
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PULL] http://linuxtv.org/hg/~mcisely/pvrusb2

[Mike Isely]

Mauro:

Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2 for two pvrusb2 
changesets.  One sets up the ability to track what kind of IR receiver 
is expected, the other optionally autoloads ir-kbd-i2c based on that 
result and a module option that can be used to disable that autoloading.  
This is the result of what I had posted about an hour ago.  It looks 
like a lot of lines, but it was all basically trivial stuff.

Note that these changes are safe; nothing is regressed here and this 
does not depend on anyone else's changes.  Even though that second 
changeset won't really do much until Jean's ir-kbd-i2c stuff is merged, 
the fact is that it won't cause any harm either.  Since the pvrusb2 
driver wasn't previously autoloading ir-kbd-i2c anyway, this change 
therefore breaks nothing.  But it does have the desirable effect in that 
it should take me out of the IR debate for now and I can stop being a 
pain to Jean :-)

Jean: I hope I didn't break any etiquette here.  Though that second 
change is "from" me, the majority of the changeset really is from your 
patch to the pvrusb2 driver.  I made changes to it so I didn't feel 
right in still trying to blame you for it ;-)  Plus, if I were to hand 
it back to you for inclusion in your patch series then you would be 
dependant upon the pvrusb2 change I made to drive the decision about 
loading based on the device hardware.  Since this change as a whole is 
mergeable without the rest of your changeset I felt it most expedient 
just to push this up now.

  -Mike


- pvrusb2: Select, track, and report IR scheme in use with the device
- pvrusb2: autoload ir-kbd when appropriate

 pvrusb2-devattr.c  |1 +
 pvrusb2-devattr.h  |   22 +++---
 pvrusb2-hdw-internal.h |3 +++
 pvrusb2-hdw.c  |   18 +-
 pvrusb2-i2c-core.c |   40 ++--
 5 files changed, 66 insertions(+), 18 deletions(-)

-- 

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Trent Piepho]

On Sun, 5 Apr 2009, Mike Isely wrote:
> 1. The switch statement in ir-kbd-i2c.c:ir_attach() is apparently
> implicitly trying to assume a particular type of remote based on the I2C
> address of the IR receiver it's talking to.  Yuck.  That's really not
> right at all.  The IR receiver used does not automatically mean which
> remote is used.  What if the vendor switches remotes?  That's happened
> with the PVR-USB2 hardware in the past (based on photos I've seen).
> Who's to say the next remote to be supplied is compatible?

IMHO, the way the remote supported is compiled into the kernel is absurd.
The system I setup 12 years ago was better than this.  At least the remote
was compiled into a userspace daemon and multiple remotes were supported at
the same time.  The keycode system I used had a remote id/key id split, so
you could have volume up key on any remote control the mixer but make the
power buttons on different remotes turn on different apps.

> 3. A given IR remote may be described by much more than what 'scan
> codes' it produces.  I don't know a lot about IR, but looking at the
> typical lirc definition for a remote, there's obvious timing and
> protocol parameters as well.  Just being able to swap scan codes around
> is not always going to be enough.

A remote typically sends a header sequence of a long pulse and space before
the code.  The length of the pulse on the space varies greatly by remote
and makes a good way to identify the remote when multiple ones are
supported.

Then a pulse coded remote sends a sequence bits, usually 8 to 32.  The
length of the pulse identifies 1s or 0s.  Different remotes have different
pulse lengths and different spaces between them.  RC5 remotes use
Manchester encoding for this part.

When you hold a key down some remotes just repeat the same sequence over
and over again.  Some repeat the scan code but omit the header part.  Some
send out a special pulse sequence to indicate the last key is being held
down.  With the latter two methods you can tell the difference between a
key being held down and a key being pressed repeatedly.  With the first you
have guess based on how fast the repeats are coming in.  This is very
different than a keyboard, which sends a code when you press a key and
another when you release it.

The rate at which remotes repeat varies greatly.  You might find that one
remote makes your volume change annoying slowly while another is much too
fast to be usable.  Remote keys usually start repeating without delay, so
if you let a toggle like 'mute' repeat it becomes almost impossible to hit
it just once.  Entering numbers becomes impossible as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

pvrusb2 IR changes coming [was: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model]

[Mike Isely]

Jean:

Here's a description of what I've got on the front burner right now:

1. The pvrusb2 driver now can unambiguously know if it is dealing with a 
device that is known to have ir-kbd-i2c compatible IR capabilities.

2. There is a new module option, "disable_autoload_ir_kbd", which if 
present and set to 1 will indicate that ir-kbd should not be loaded.

2. Based upon (1) and (2), the driver will optionally attempt to load 
ir-kbd using the code from your patch.

3. In the pvrusb2 case, the only i2c address that currently matters is 
0x18 (though I have some suspicions about another case but that can be 
dealt with later), so I trimmed the probe list in the register function 
you had added.

Since calling i2c_new_probed_device() for a non-existent target driver 
doesn't cause any harm, then merging the above now should not result in 
any kind of regression.  So it can go in even before the rest of your 
changes.  That I believe also removes the objection Mauro had - this way 
there's no issues / dependencies.  I've tested this enough to know that 
it at least doesn't do any further harm.

I will put this up in a changeset shortly.

With all that said, we should not ignore lirc and instead do whatever is 
reasonable to help ensure it continues to work.  Though admittedly 
there's been plenty of opportunity to update and this whole transition 
has been going on for a long time.  The stuff I describe above should at 
least keep the pvrusb2 driver out of the fray for now.

  -Mike


-- 

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Trent Piepho]

On Sun, 5 Apr 2009, Andy Walls wrote:
>
> Here is where LIRC may be its own worst enemy.  LIRC has filled some
> shortcomings in the kernel for support of IR device functions for so
> long (LWN says LIRC is 10 years old), that large numbers of users have
> come to depend on its operation, while at the same time apparently
> removing impetus for doing much to update the in kernel IR device
> support.

More than that.  In 1997 I bought a serial port remote off ebay and tried
to get it to work with linux.  I found an abandoned project from the
Metzler brothers called LIRC, though it didn't work.  I wrote a new
protocol for the serial port driver, which was the only one at the time,
rewrote the remote pulse decoding code and came up a new socket based the
client/server protocol and wrote the x-event client.  At that point remotes
were defined in header files so make was still needed to add a new one.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[hermann pitton]

Am Sonntag, den 05.04.2009, 21:52 -0500 schrieb Mike Isely:
> On Sun, 5 Apr 2009, Mauro Carvalho Chehab wrote:
> 
> > On Sun, 05 Apr 2009 18:00:04 -0400
> > Andy Walls  wrote:
> > 
> > > On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote:
> > > > Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare:
> > > > > On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote:
> > > 
> > > 
> > > > What can not be translated to the input system I would like to know.
> > > > Andy seems to have closer looked into that.
> > > 
> > > 1. IR blasting: sending IR codes to transmit out to a cable convertor
> > > box, DTV to analog convertor box, or similar devices to change channels
> > > before recording starts.  An input interface doesn't work well for
> > > output.
> > 
> > On my understanding, IR output is a separate issue. AFAIK, only a very few 
> > ivtv
> > devices support IR output. I'm not sure how this is currently implemented.
> 
> For the pvrusb2 driver, MCE style 24xxx devices (2nd generation 24xxx) 
> and HVR-1950 devices have IR blasting capabilities.  At the moment, 
> people have gotten this to work on the 24xxx model with the appropriate 
> lirc driver.  In theory it should be doable for HVR-1950 as well (and 
> the pvrusb2 does what is needed to make it possible) but I don't think 
> anyone has succeeded there yet.
> 
> Sure IR output as a concept and interface is a separate issue.  But it 
> can be implemented in the same chip (which is the case in the two 
> examples I list above).  So the issue is not separate; it must be dealt 
> with as a whole.  Two drivers implementing different features but trying 
> to share one chip is just not fun.
> 
> 
> > 
> > 
> > > 2. Sending raw IR samples to user space: user space applications can
> > > then decode or match an unknown or non-standard IR remote protocol in
> > > user space software.  Timing information to go along with the sample
> > > data probably needs to be preserved.   I'm assuming the input interface
> > > currently doesn't support that.
> > 
> > If the driver processes correctly the IR samples, I don't see why you would
> > need to pass the raw protocols to userspace. Maybe we need to add some 
> > ioctls
> > at the API to allow certain controls, like, for example, ask kernel to 
> > decode
> > IR using RC4 instead or RC5, on devices that supports more than one IR 
> > protocol.
> 
> Ugh.  Why should v4l-dvb get into this business when it's already solved 
> somewhere else?  In userspace even.
> 
> I see in so many other places people arguing for V4L functionality that 
> needs to be kicked out of the kernel and put into userspace.  For 
> example, there's all that silliness over pixel formats that I'm soon 
> going to have to deal with...
> 
> Yet in this case with IR, there already exists a subsystem that does 
> *more* than ir-kbd-i2c.c, AND it does all the crazy configuration / 
> control in userspace - and yet you argue that ir-kbd-i2c.c should be 
> preferred?  Purely because lirc is not in-tree?  Well heck, lirc should 
> be in-tree.  Let's help them get there and forget ever having to deal 
> with IR again ourselves.  Let them do it.
> 
> 
> > 
> > > That's all the Gerd mentioned.
> > > 
> > > 
> > > One more nice feature to have, that I'm not sure how easily the input
> > > system could support:
> > > 
> > > 3. specifying remote control code to key/button translations with a
> > > configuration file instead of recompiling a module.
> > 
> > The input and the current drivers that use input already supports this 
> > feature.
> > You just need to load a new code table to replace the existing one.
> > 
> > See v4l2-apps/util/keytable.c to see how easy is to change a key code. It
> > contains a complete code to fully replace a key code table. Also, the 
> > Makefile
> > there will extract the current keytables for the in-kernel drivers.
> > 
> > Btw, with only 12 lines, you can create a keycode replace "hello world!":
> > 
> > #include   /* due to O_RDONLY */
> > #include   /* open() */
> > #include /* input ioctls and keycode macros */
> > #include   /* ioctl() */
> > void main(void)
> > {
> > int codes[2];
> > int fd = open("/dev/video0", O_RDONLY); /* Hmm.. in real apps, we 
> > should check for errors */
> > codes[0] = 10;  /* Scan code */
> > codes[1] = KEY_UP;  /* Key code */
> > ioctl(fd, EVIOCSKEYCODE, codes);/* hello world! */
> > }
> 
> I just looked at this.  I freely admit I haven't noticed this before, 
> but having looked at it now, and having examined ir-kbd-i2c.c, I still 
> don't see the whole picture here:
> 
> 1. The switch statement in ir-kbd-i2c.c:ir_attach() is apparently 
> implicitly trying to assume a particular type of remote based on the I2C 
> address of the IR receiver it's talking to.  Yuck.  That's really not 
> right at all.  The IR receiver used does not automatically mean which 
> remote is used.  W

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Mike Isely]

On Sun, 5 Apr 2009, Mauro Carvalho Chehab wrote:

> On Sun, 05 Apr 2009 18:00:04 -0400
> Andy Walls  wrote:
> 
> > On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote:
> > > Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare:
> > > > On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote:
> > 
> > 
> > > What can not be translated to the input system I would like to know.
> > > Andy seems to have closer looked into that.
> > 
> > 1. IR blasting: sending IR codes to transmit out to a cable convertor
> > box, DTV to analog convertor box, or similar devices to change channels
> > before recording starts.  An input interface doesn't work well for
> > output.
> 
> On my understanding, IR output is a separate issue. AFAIK, only a very few 
> ivtv
> devices support IR output. I'm not sure how this is currently implemented.

For the pvrusb2 driver, MCE style 24xxx devices (2nd generation 24xxx) 
and HVR-1950 devices have IR blasting capabilities.  At the moment, 
people have gotten this to work on the 24xxx model with the appropriate 
lirc driver.  In theory it should be doable for HVR-1950 as well (and 
the pvrusb2 does what is needed to make it possible) but I don't think 
anyone has succeeded there yet.

Sure IR output as a concept and interface is a separate issue.  But it 
can be implemented in the same chip (which is the case in the two 
examples I list above).  So the issue is not separate; it must be dealt 
with as a whole.  Two drivers implementing different features but trying 
to share one chip is just not fun.


> 
> 
> > 2. Sending raw IR samples to user space: user space applications can
> > then decode or match an unknown or non-standard IR remote protocol in
> > user space software.  Timing information to go along with the sample
> > data probably needs to be preserved.   I'm assuming the input interface
> > currently doesn't support that.
> 
> If the driver processes correctly the IR samples, I don't see why you would
> need to pass the raw protocols to userspace. Maybe we need to add some ioctls
> at the API to allow certain controls, like, for example, ask kernel to decode
> IR using RC4 instead or RC5, on devices that supports more than one IR 
> protocol.

Ugh.  Why should v4l-dvb get into this business when it's already solved 
somewhere else?  In userspace even.

I see in so many other places people arguing for V4L functionality that 
needs to be kicked out of the kernel and put into userspace.  For 
example, there's all that silliness over pixel formats that I'm soon 
going to have to deal with...

Yet in this case with IR, there already exists a subsystem that does 
*more* than ir-kbd-i2c.c, AND it does all the crazy configuration / 
control in userspace - and yet you argue that ir-kbd-i2c.c should be 
preferred?  Purely because lirc is not in-tree?  Well heck, lirc should 
be in-tree.  Let's help them get there and forget ever having to deal 
with IR again ourselves.  Let them do it.


> 
> > That's all the Gerd mentioned.
> > 
> > 
> > One more nice feature to have, that I'm not sure how easily the input
> > system could support:
> > 
> > 3. specifying remote control code to key/button translations with a
> > configuration file instead of recompiling a module.
> 
> The input and the current drivers that use input already supports this 
> feature.
> You just need to load a new code table to replace the existing one.
> 
> See v4l2-apps/util/keytable.c to see how easy is to change a key code. It
> contains a complete code to fully replace a key code table. Also, the Makefile
> there will extract the current keytables for the in-kernel drivers.
> 
> Btw, with only 12 lines, you can create a keycode replace "hello world!":
> 
> #include /* due to O_RDONLY */
> #include /* open() */
> #include   /* input ioctls and keycode macros */
> #include /* ioctl() */
> void main(void)
> {
>   int codes[2];
>   int fd = open("/dev/video0", O_RDONLY); /* Hmm.. in real apps, we 
> should check for errors */
>   codes[0] = 10;  /* Scan code */
>   codes[1] = KEY_UP;  /* Key code */
>   ioctl(fd, EVIOCSKEYCODE, codes);/* hello world! */
> }

I just looked at this.  I freely admit I haven't noticed this before, 
but having looked at it now, and having examined ir-kbd-i2c.c, I still 
don't see the whole picture here:

1. The switch statement in ir-kbd-i2c.c:ir_attach() is apparently 
implicitly trying to assume a particular type of remote based on the I2C 
address of the IR receiver it's talking to.  Yuck.  That's really not 
right at all.  The IR receiver used does not automatically mean which 
remote is used.  What if the vendor switches remotes?  That's happened 
with the PVR-USB2 hardware in the past (based on photos I've seen).  
Who's to say the next remote to be supplied is compatible?

2. Your example above is opening the video device endpoint and issuing 
ioctl()s that are no

how to watch Pay TV under linux

[loody]

Dear all:
I know if I want to see pay tv, it seems I have to got a tv card which
supports ci module.
Would anyone tell me which card that linux driver already support so far?
appreciate your help,
miloody
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] au0828: fix Kconfig dependance

[Alexander Beregalov]

Fix this build error:
ERROR: "videobuf_queue_vmalloc_init" [drivers/media/video/au0828/au0828.ko] 
undefined!
ERROR: "videobuf_vmalloc_free" [drivers/media/video/au0828/au0828.ko] undefined!
ERROR: "videobuf_to_vmalloc" [drivers/media/video/au0828/au0828.ko] undefined!

Signed-off-by: Alexander Beregalov 
---

 drivers/media/video/au0828/Kconfig |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/au0828/Kconfig 
b/drivers/media/video/au0828/Kconfig
index 05cdf49..0c3a5ba 100644
--- a/drivers/media/video/au0828/Kconfig
+++ b/drivers/media/video/au0828/Kconfig
@@ -4,6 +4,7 @@ config VIDEO_AU0828
depends on I2C && INPUT && DVB_CORE && USB && VIDEO_V4L2
select I2C_ALGOBIT
select VIDEO_TVEEPROM
+   select VIDEOBUF_VMALLOC
select DVB_AU8522 if !DVB_FE_CUSTOMISE
select MEDIA_TUNER_XC5000 if !MEDIA_TUNER_CUSTOMISE
select MEDIA_TUNER_MXL5007T if !MEDIA_TUNER_CUSTOMISE
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[hermann pitton]

Hi Andy,

Am Sonntag, den 05.04.2009, 18:00 -0400 schrieb Andy Walls:
> On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote:
> > Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare:
> > > On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote:
> 
> 
> > What can not be translated to the input system I would like to know.
> > Andy seems to have closer looked into that.
> 
> 1. IR blasting: sending IR codes to transmit out to a cable convertor
> box, DTV to analog convertor box, or similar devices to change channels
> before recording starts.  An input interface doesn't work well for
> output.
> 
> 2. Sending raw IR samples to user space: user space applications can
> then decode or match an unknown or non-standard IR remote protocol in
> user space software.  Timing information to go along with the sample
> data probably needs to be preserved.   I'm assuming the input interface
> currently doesn't support that.
> 
> That's all the Gerd mentioned.
> 
> 
> One more nice feature to have, that I'm not sure how easily the input
> system could support:
> 
> 3. specifying remote control code to key/button translations with a
> configuration file instead of recompiling a module.
> 
> In effect there are actually two devices the ir-kbd-i2c input driver is
> supporting in various combinations: an IR receiver and an IR remote.
> 
> 
> Regards,
> Andy
> 

you always end up with something transmitting series of 0s and 1s.

It does not matter if the medium is infrared, infradead ;), wireless or
whats or ever.

If it spares a chip for the remote and you have to get it from IRQs
triggered, you have to do that.

It could also be some voltage change, a ultrasound beeper or what ever.

The first place for such is the input layer and nothing out of the
kernel.

Cheers,
Hermann


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Mauro Carvalho Chehab]

On Sun, 05 Apr 2009 18:00:04 -0400
Andy Walls  wrote:

> On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote:
> > Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare:
> > > On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote:
> 
> 
> > What can not be translated to the input system I would like to know.
> > Andy seems to have closer looked into that.
> 
> 1. IR blasting: sending IR codes to transmit out to a cable convertor
> box, DTV to analog convertor box, or similar devices to change channels
> before recording starts.  An input interface doesn't work well for
> output.

On my understanding, IR output is a separate issue. AFAIK, only a very few ivtv
devices support IR output. I'm not sure how this is currently implemented.


> 2. Sending raw IR samples to user space: user space applications can
> then decode or match an unknown or non-standard IR remote protocol in
> user space software.  Timing information to go along with the sample
> data probably needs to be preserved.   I'm assuming the input interface
> currently doesn't support that.

If the driver processes correctly the IR samples, I don't see why you would
need to pass the raw protocols to userspace. Maybe we need to add some ioctls
at the API to allow certain controls, like, for example, ask kernel to decode
IR using RC4 instead or RC5, on devices that supports more than one IR protocol.

> That's all the Gerd mentioned.
> 
> 
> One more nice feature to have, that I'm not sure how easily the input
> system could support:
> 
> 3. specifying remote control code to key/button translations with a
> configuration file instead of recompiling a module.

The input and the current drivers that use input already supports this feature.
You just need to load a new code table to replace the existing one.

See v4l2-apps/util/keytable.c to see how easy is to change a key code. It
contains a complete code to fully replace a key code table. Also, the Makefile
there will extract the current keytables for the in-kernel drivers.

Btw, with only 12 lines, you can create a keycode replace "hello world!":

#include   /* due to O_RDONLY */
#include   /* open() */
#include /* input ioctls and keycode macros */
#include   /* ioctl() */
void main(void)
{
int codes[2];
int fd = open("/dev/video0", O_RDONLY); /* Hmm.. in real apps, we 
should check for errors */
codes[0] = 10;  /* Scan code */
codes[1] = KEY_UP;  /* Key code */
ioctl(fd, EVIOCSKEYCODE, codes);/* hello world! */
}

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1 of 3] cx88: Add support for stereo and sap detection for A2

[Mauro Carvalho Chehab]

On Mon, 6 Apr 2009 02:36:01 +0200 (CEST)
Marton Balint  wrote:

> On Sun, 5 Apr 2009, Mauro Carvalho Chehab wrote:
> 
> > Hi Marton,
> > 
> > I suspect that you will need to use div64 math or some othe way to 
> > calculate the freq:
> > 
> > /home/v4l/master/v4l/cx88-dsp.c: In function 'detect_a2_a2m_eiaj':
> > /home/v4l/master/v4l/cx88-dsp.c:147: error: SSE register return with SSE 
> > disabled
> > make[3]: *** [/home/v4l/master/v4l/cx88-dsp.o] Error 1
> > make[3]: *** Waiting for unfinished jobs
> 
> Gcc should have optimised away the floating point operations and the 
> __builtin_remainder function. Hmm, it seems that older gcc's don't do 
> this. Would you try the attached patch? It uses integer modulo instead 
> of __builtin_remainder, so only basic floating point operations needs 
> optimising, hopefully every common gcc version will be able to do it.

Worked. I've folded this patch with the previous one, to avoid bisect breakage 
upstream.

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1 of 3] cx88: Add support for stereo and sap detection for A2

[Marton Balint]

On Sun, 5 Apr 2009, Mauro Carvalho Chehab wrote:

> Hi Marton,
> 
> I suspect that you will need to use div64 math or some othe way to calculate 
> the freq:
> 
> /home/v4l/master/v4l/cx88-dsp.c: In function 'detect_a2_a2m_eiaj':
> /home/v4l/master/v4l/cx88-dsp.c:147: error: SSE register return with SSE 
> disabled
> make[3]: *** [/home/v4l/master/v4l/cx88-dsp.o] Error 1
> make[3]: *** Waiting for unfinished jobs

Gcc should have optimised away the floating point operations and the 
__builtin_remainder function. Hmm, it seems that older gcc's don't do 
this. Would you try the attached patch? It uses integer modulo instead 
of __builtin_remainder, so only basic floating point operations needs 
optimising, hopefully every common gcc version will be able to do it.

Regards,
  Marton

# HG changeset patch
# User Marton Balint 
# Date 1238977280 -7200
# Node ID 5a396f71d463b738c363c12bf53a3e446016aa95
# Parent  119acaa1dee387960325ba637c6257af2b0fd3af
cx88: dsp: more gcc compatible remainder function

From: Marton Balint 

Priority: normal

Signed-off-by: Marton Balint 

diff -r 119acaa1dee3 -r 5a396f71d463 linux/drivers/media/video/cx88/cx88-dsp.c
--- a/linux/drivers/media/video/cx88/cx88-dsp.c Tue Mar 31 23:35:57 2009 +0200
+++ b/linux/drivers/media/video/cx88/cx88-dsp.c Mon Apr 06 02:21:20 2009 +0200
@@ -28,8 +28,11 @@
 
 #define INT_PI ((s32)(3.141592653589 * 32768.0))
 
+#define compat_remainder(a, b) \
+((float)(((s32)((a)*100))%((s32)((b)*100)))/100.0)
+
 #define baseband_freq(carrier, srate, tone) ((s32)( \
-(__builtin_remainder(carrier + tone, srate)) / srate * 2 * INT_PI))
+(compat_remainder(carrier + tone, srate)) / srate * 2 * INT_PI))
 
 /* We calculate the baseband frequencies of the carrier and the pilot tones
  * based on the the sampling rate of the audio rds fifo. */
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Test results for ir-kbd-i2c.c changes (Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model)

[Andy Walls]

On Sun, 2009-04-05 at 16:40 +0200, Jean Delvare wrote: 
> Hi Mauro,
> 
> On Sun, 5 Apr 2009 07:01:16 -0300, Mauro Carvalho Chehab wrote:

> > 
> > 3) So far, nobody gave us any positive return that the new IR model is 
> > working with
> > any of the touched drivers. So, more tests are needed. I'm expecting to 
> > have a
> > positive reply for each of the touched drivers. People, please test!
> 
> Yes, please! :)

Jean,

I tested your original patch set so you can get some real feedback.  The
news is good, but I'll bore you with the details first. :)


1. My setup:

HVR-1600: Hauppauge model 74041, rev C5B2, serial# 891351
  has no radio, has IR receiver, has IR transmitter (Zilog Z8F0811)

Hauppauge Remote: Grey top side & black bottom side;
  with 4 colored buttons Red, Green, Yellow, Blue;
  Numbers inside battery cover:
A415-HPG
M25909070211590

uname -a: 
Linux morgan.walls.org 2.6.27.9-73.fc9.x86_64 #1 SMP Tue Dec 16 14:54:03
EST 2008 x86_64 x86_64 x86_64 GNU/Linux

v4l-dvb: pulled this morning.


2. OK, my first test had no effect, because I'm an idiot. :)
In the cx18 driver, I didn't remove the I2C addresses in your original
patch, and I didn't add 0x71 as a valid address.



3. My second test had bad results:

# modprobe ir-kbd-i2c debug=3 hauppauge=1

Message from sysl...@morgan at Apr  5 18:47:14 ...
kernel:Oops: 0010 [1] SMP 

Message from sysl...@morgan at Apr  5 18:47:14 ...
kernel:Code:  Bad RIP value.

Message from sysl...@morgan at Apr  5 18:47:14 ...
kernel:CR2: 


input: i2c IR (SAA713x remote) as /devices/virtual/input/input6
ir-kbd-i2c: i2c IR (SAA713x remote) detected at i2c-1/1-0071/ir0 [cx18 i2c 
driver #0-0]
ir-kbd-i2c: ir_poll_key
BUG: unable to handle kernel NULL pointer dereference at 
IP: [<>] 0x0
PGD 71c36067 PUD 2cca2067 PMD 0 
Oops: 0010 [1] SMP 
CPU 0 
Modules linked in: ir_kbd_i2c(+) ir_common mxl5005s s5h1409 tuner_simple 
tuner_types cs5345 tuner cx18 dvb_core cx2341x v4l2_common videodev v4l1_compat 
v4l2_compat_ioctl32 tveeprom i2c_algo_bit fuse ipt_REJECT nf_conntrack_ipv4 
iptable_filter ip_tables ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state 
nf_conntrack ip6table_filter ip6_tables x_tables cpufreq_ondemand powernow_k8 
freq_table loop dm_multipath scsi_dh ipv6 snd_hda_intel snd_seq_dummy 
snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss 
snd_pcm i2c_piix4 snd_timer snd_page_alloc ppdev parport_pc snd_hwdep i2c_core 
shpchp parport pcspkr snd soundcore sr_mod r8169 mii k8temp hwmon cdrom sg 
floppy dm_snapshot dm_zero dm_mirror dm_log dm_mod pata_acpi ata_generic 
pata_atiixp libata sd_mod scsi_mod crc_t10dif ext3 jbd mbcache uhci_hcd 
ohci_hcd ehci_hcd [last unloaded: tveeprom]
Pid: 9, comm: events/0 Not tainted 2.6.27.9-73.fc9.x86_64 #1
RIP: 0010:[<>]  [<>] 0x0
RSP: 0018:880077bede58  EFLAGS: 00010286
RAX: 001b RBX: 88005e73ee30 RCX: ccc6
RDX: a031ba00 RSI: a031ba04 RDI: 88005e73ec00
RBP: 880077bede80 R08: 880077bec000 R09: ccc6
R10: 0126a7e22b3d R11: 880073159bd8 R12: 88005e73ec00
R13: 0064 R14: a0318371 R15: 880077804908
FS:  7fa0409126f0() GS:814ad100() knlGS:
CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2:  CR3: 569f6000 CR4: 06e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process events/0 (pid: 9, threadinfo 880077bec000, task 880077bbdb80)
Stack:  a03183df 880077bede80 88005e73ee38 880077804900
 88005e73ee30 880077bedec0 8104fe45 880077bedec0
 880077804900 880077804918 880077804908 880077beded0
Call Trace:
 [] ? ir_work+0x6e/0xd2 [ir_kbd_i2c]
 [] run_workqueue+0xa3/0x146
 [] worker_thread+0xf5/0x109
 [] ? autoremove_wake_function+0x0/0x38
 [] ? worker_thread+0x0/0x109
 [] kthread+0x49/0x76
 [] child_rip+0xa/0x11
 [] ? restore_args+0x0/0x30
 [] ? kthread+0x0/0x76
 [] ? child_rip+0x0/0x11


Code:  Bad RIP value.
RIP  [<>] 0x0
 RSP 
CR2: 
---[ end trace 6076b08e85151d70 ]---


That's because in ir-kbd-i2c.c:ir_poll_key(), ir->get_key() was a NULL
function pointer.

I realized that ir-kbd-i2c.c:ir_probe() would need a fix-up for address
0x71 for cx18 (and ivtv) or I would need to set the parameters via
struct IR_i2c_init_data.  

There's a usable get_key function for Hauppauge remotes in ir-kbd-i2c,
but no way via struct IR_i2c_init_data to specify that one wants to use
it from the bridge driver.  Nor is there a way to set the RC5 ir_type
from the bridge driver.  So mucking with ir-kbd-i2c.c for address 0x71
is what I did next.


4. For my third test I modified a few lines in ir-kbd-i2c:ir_probe.c:
...
case 0x7a:
case 0x47:
case 0x71:
  

HVR-1300 experience

[Ing. David Rehor]

Dear linuxtv developers,
  this is an email about my experience with the HVR-1300. I've been 
"fighting" with the Hauppauge HVR-1300 for almost 3 years in Linux. I'm 
pretty sure the card's hardware is ok, since most of its components did 
their job during the last years in Linux (not alltogether at once though 
:) ).
  During the years I've been watching the linuxtv site occasionally and 
I was trying various patches.


for the rest of the text:
#define hibernation "system suspend to disk using uswsusp v. 0.8"

-
My current configuration:

Disto: Kubuntu 8.10 Interpid Ibex

Kernel: right now custom compiled kernel linux-2.6.27-7 PREEMPT (that 
comes with kubuntu). I have seen all the following issues in older 
kernels too (stock and/or custom built)


Machine: Intel Pentium4 1600MHz

V4l sources status: hg clone from the beginning of 2009

Analog signal: PAL-DK

i2c_udelay: 16

I use mplayer to watch TV. The symptoms described further apply to 
tvtime, kdetv, kaffeine etc. too though.


Mplayer cmdlines:
VBI:
  mplayer tv:// -tv 

MPEG2:
  v4l2-ctl -d /dev/video1 --set-freq=some_frequency
  mplayer /dev/video1 -cache 8192
or even
  cat /dev/video1 > file.mpeg2

DVB:
  mplayer dvb://... with proper channels.conf from dvb-scan, when it 
last worked...


-
The current status of tv via HVR-1300 on my computer is as follows:
- VBI works ok with proper stereo-sound + tuning channels, even S-Video 
works ok
- MPEG2 works ok (analog) with proper stereo sound + tuning channels, 
however see below...

- IR worked, when the lirc drivers were in the kernel
- DVB-T is a kind of mystery to me (explanation follows).
- analog radio - never managed to get any sound from it

Details:
VBI:
 The card tunes analog channels ok in mplayer. When changing channels 
in mplayer, the newly selected channel displays only in the topleft 
quarter of the window, the rest contains the last tv-frame of the 
previous channel mixed with garbage. Maybe it's an mplayer bug or maybe 
mplayer gets some inconsistent tv-picture resolution information from 
the v4l2 subsystem. This is not a problem for me, I'm not using VBI too 
much.


MPEG2 - cx88_blackbird:
  Works well IFF the tuner gets the selected frequency. Then the mpeg 
PS stream also contains a valid audio stream. The frequency problem was 
an issue (i2c write errors) in the previous kubuntu 8.04, the problem is 
gone now in the kubuntu 8.10.
  The v4l implicitly initialized the blackbird into NTSC, which was 
very annoying. I'm not sure, if the problem persists in the current v4l 
sources, I hardcoded it to PAL in the v4l sources for my machine.
  Setting different mpeg2 controls in the hvr-1300 firmware via v4l 
interface works also well, e.g. setting mpeg2 stream bitrate, audio 
bitrate, temporal and spatial filters setup etc.


DVB-T (+digital radio stations):
  DVB-T worked in kubuntu 8.04 only AFTER hibernation using kaffeine or 
mplayer. I'd say this has to do something with the different tuners on 
the card not being setup properly (or differently) during normal boot 
and during resume from hibernation.
  However, in the current kubuntu 8.10 the dvb-t does not work at all, 
the tuner timeouts when doing dvb-scan. I also tried the Kaffeine 
player, that worked in the 8.04 ok too, but again - only after 
hibernation. I'd really like to have the DVB-T work again...


Analog Radio:
Don't know, never managed to tune any existing station so far.


And now the most interesting issue:

Hibernation:

  It is absolutely necessary to rmmod the following modules before 
hibernation on my machine:

rmmod cx88_blackbird
rmmod wm8775
rmmod cx88_dvb
rmmod cx8802

  If I forget to do the unloads, NO process must EVER touch the 
cx88_blackbird module after resume from hibernation until a HW reset of 
the system.
  If any process touches the blackbird (even starting xsane which scans 
for "scanning device" at start), the computer hangs really bad, only 
Ctrl-Alt-SysRq-B is a solution besides a HW reset.


After resume the following rmmod-modprobe sequence must be run 4 times 
(four times, not once, not twice, not three times, but four times!):

rmmod cx88_blackbird
rmmod wm8775
rmmod cx88_dvb
rmmod cx8802

modprobe wm8775
modprobe cx8802
modprobe cx88_blackbird
modprobe cx88_dvb

Why four times? It has definitely something to do with initialization of 
the wm8775 chip:
1. Doing the rmmod-modprobe sequence only once results in mpeg2 stream 
not containing ANY audio track.
2. Doing it twice results in mpeg2 stream containing muted audio track, 
but no way to unmute it.
3. Doing it three times results in mpeg2 stream containing audio track 
with just noise.
4. Doing it for the fourth time results finally in mpeg2 stream 
containing the expected and correct audio track.


Since then:
VBI - no problem
Blackbird works, event its audio source is correct (due to reloaded

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[hermann pitton]

Am Sonntag, den 05.04.2009, 18:00 -0400 schrieb Andy Walls:
> On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote:
> > Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare:
> > > On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote:
> 
> 
> > What can not be translated to the input system I would like to know.
> > Andy seems to have closer looked into that.
> 
> 1. IR blasting: sending IR codes to transmit out to a cable convertor
> box, DTV to analog convertor box, or similar devices to change channels
> before recording starts.  An input interface doesn't work well for
> output.
> 
> 2. Sending raw IR samples to user space: user space applications can
> then decode or match an unknown or non-standard IR remote protocol in
> user space software.  Timing information to go along with the sample
> data probably needs to be preserved.   I'm assuming the input interface
> currently doesn't support that.
> 
> That's all the Gerd mentioned.

Hmmm 

> One more nice feature to have, that I'm not sure how easily the input
> system could support:
> 
> 3. specifying remote control code to key/button translations with a
> configuration file instead of recompiling a module.

Maybe try that from 5 years back.

Or what Mauro has.

Who ever had to recompile a module for changing the key tables?

> In effect there are actually two devices the ir-kbd-i2c input driver is
> supporting in various combinations: an IR receiver and an IR remote.
> 
> 
> Regards,
> Andy
> 

I doubt you are down to it.

Cheers,
Hermann


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1 of 3] cx88: Add support for stereo and sap detection for A2

[Mauro Carvalho Chehab]

Hi Marton,

I suspect that you will need to use div64 math or some othe way to calculate 
the freq:

/home/v4l/master/v4l/cx88-dsp.c: In function 'detect_a2_a2m_eiaj':
/home/v4l/master/v4l/cx88-dsp.c:147: error: SSE register return with SSE 
disabled
make[3]: *** [/home/v4l/master/v4l/cx88-dsp.o] Error 1
make[3]: *** Waiting for unfinished jobs


On Wed, 01 Apr 2009 00:01:51 +0200
Marton Balint  wrote:

> # HG changeset patch
> # User Marton Balint 
> # Date 1238461695 -7200
> # Node ID 32593e0b3a9253e4f3d2cb415cb3143136f61504
> # Parent  ff5430b54ac291d69c1bbb35af1b80b5b7ec692e
> cx88: Add support for stereo and sap detection for A2
> 
> From: Marton Balint 
> 
> The patch implements reliable stereo and sap detection for the A2 sound
> standard.  This is achieved by processing the samples of the audio RDS fifo of
> the cx2388x chip. A2M, EIAJ and BTSC stereo/sap detection is also possible 
> with
> this new approach, but it's not implemented yet. Stereo detection when alsa
> handles the sound also does not work yet.
> 
> Priority: normal
> 
> Signed-off-by: Marton Balint 
> 
> diff -r ff5430b54ac2 -r 32593e0b3a92 linux/drivers/media/video/cx88/Makefile
> --- a/linux/drivers/media/video/cx88/Makefile Mon Mar 30 08:27:06 2009 -0300
> +++ b/linux/drivers/media/video/cx88/Makefile Tue Mar 31 03:08:15 2009 +0200
> @@ -1,5 +1,5 @@
>  cx88xx-objs  := cx88-cards.o cx88-core.o cx88-i2c.o cx88-tvaudio.o \
> -cx88-input.o
> +cx88-dsp.o cx88-input.o
>  cx8800-objs  := cx88-video.o cx88-vbi.o
>  cx8802-objs  := cx88-mpeg.o
>  
> diff -r ff5430b54ac2 -r 32593e0b3a92 
> linux/drivers/media/video/cx88/cx88-core.c
> --- a/linux/drivers/media/video/cx88/cx88-core.c  Mon Mar 30 08:27:06 
> 2009 -0300
> +++ b/linux/drivers/media/video/cx88/cx88-core.c  Tue Mar 31 03:08:15 
> 2009 +0200
> @@ -232,7 +232,7 @@
>   * can use the whole SDRAM for the DMA fifos.  To simplify things, we
>   * use a static memory layout.  That surely will waste memory in case
>   * we don't use all DMA channels at the same time (which will be the
> - * case most of the time).  But that still gives us enougth FIFO space
> + * case most of the time).  But that still gives us enough FIFO space
>   * to be able to deal with insane long pci latencies ...
>   *
>   * FIFO space allocations:
> @@ -242,6 +242,7 @@
>   *channel  24(vbi)  -  4.0k
>   *channels 25+26 (audio)-  4.0k
>   *channel  28(mpeg) -  4.0k
> + *channel  27(audio rds)-  3.0k
>   *TOTAL = 29.0k
>   *
>   * Every channel has 160 bytes control data (64 bytes instruction
> @@ -337,6 +338,18 @@
>   .ptr2_reg   = MO_DMA28_PTR2,
>   .cnt1_reg   = MO_DMA28_CNT1,
>   .cnt2_reg   = MO_DMA28_CNT2,
> + },
> + [SRAM_CH27] = {
> + .name   = "audio rds",
> + .cmds_start = 0x1801C0,
> + .ctrl_start = 0x180860,
> + .cdt= 0x180860 + 64,
> + .fifo_start = 0x187400,
> + .fifo_size  = 0x000C00,
> + .ptr1_reg   = MO_DMA27_PTR1,
> + .ptr2_reg   = MO_DMA27_PTR2,
> + .cnt1_reg   = MO_DMA27_CNT1,
> + .cnt2_reg   = MO_DMA27_CNT2,
>   },
>  };
>  
> @@ -623,6 +636,7 @@
>   cx88_sram_channel_setup(core, &cx88_sram_channels[SRAM_CH25], 128, 0);
>   cx88_sram_channel_setup(core, &cx88_sram_channels[SRAM_CH26], 128, 0);
>   cx88_sram_channel_setup(core, &cx88_sram_channels[SRAM_CH28], 188*4, 0);
> + cx88_sram_channel_setup(core, &cx88_sram_channels[SRAM_CH27], 128, 0);
>  
>   /* misc init ... */
>   cx_write(MO_INPUT_FORMAT, ((1 << 13) |   // agc enable
> @@ -821,6 +835,8 @@
>   /* constant 128 made buzz in analog Nicam-stereo for bigger fifo_size */
>   int bpl = cx88_sram_channels[SRAM_CH25].fifo_size/4;
>  
> + int rds_bpl = cx88_sram_channels[SRAM_CH27].fifo_size/AUD_RDS_LINES;
> +
>   /* If downstream RISC is enabled, bail out; ALSA is managing DMA */
>   if (cx_read(MO_AUD_DMACNTRL) & 0x10)
>   return 0;
> @@ -828,12 +844,14 @@
>   /* setup fifo + format */
>   cx88_sram_channel_setup(core, &cx88_sram_channels[SRAM_CH25], bpl, 0);
>   cx88_sram_channel_setup(core, &cx88_sram_channels[SRAM_CH26], bpl, 0);
> + cx88_sram_channel_setup(core, &cx88_sram_channels[SRAM_CH27],
> + rds_bpl, 0);
>  
>   cx_write(MO_AUDD_LNGTH, bpl); /* fifo bpl size */
> - cx_write(MO_AUDR_LNGTH, bpl); /* fifo bpl size */
> + cx_write(MO_AUDR_LNGTH, rds_bpl); /* fifo bpl size */
>  
> - /* start dma */
> - cx_write(MO_AUD_DMACNTRL, 0x0003); /* Up and Down fifo enable */
> + /* enable Up, Down and Audio RDS fifo */
> + cx_write(MO_AUD_DMACNTRL, 0x0007);
>  
>   return 0;
>  }
> diff -r ff5430b54ac2 -r 32593e0b3a92 linux/drivers/media/video/cx88/cx88-dsp.c
> --- /dev/null Thu Jan 01 00:00:00 1970 +
> +++ b/linux/drivers/media/

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Andy Walls]

On Sun, 2009-04-05 at 23:22 +0200, hermann pitton wrote:
> Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare:
> > On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote:


> What can not be translated to the input system I would like to know.
> Andy seems to have closer looked into that.

1. IR blasting: sending IR codes to transmit out to a cable convertor
box, DTV to analog convertor box, or similar devices to change channels
before recording starts.  An input interface doesn't work well for
output.

2. Sending raw IR samples to user space: user space applications can
then decode or match an unknown or non-standard IR remote protocol in
user space software.  Timing information to go along with the sample
data probably needs to be preserved.   I'm assuming the input interface
currently doesn't support that.

That's all the Gerd mentioned.


One more nice feature to have, that I'm not sure how easily the input
system could support:

3. specifying remote control code to key/button translations with a
configuration file instead of recompiling a module.

In effect there are actually two devices the ir-kbd-i2c input driver is
supporting in various combinations: an IR receiver and an IR remote.


Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[hermann pitton]

Am Sonntag, den 05.04.2009, 22:22 +0200 schrieb Jean Delvare:
> On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote:
> > On Sun, 2009-04-05 at 20:31 +0200, Janne Grunau wrote:
> > > I have devices for lirc_zilog (which should probably be merged with
> > > lirc_i2c) 
> > 
> > Hmmm. Following Jean's reasoning, that may be the wrong way to go, if
> > you want to avoid probing.  A module to handle each specific type of I2C
> > IR chip, splitting up lirc_i2c and leaving lirc_zilog as is, may be
> > better in the long run.
> 
> This really doesn't matter. With the new binding model, probing is
> under control. You can do probing on some cards and not others, and you
> can probe some addresses and not others. And one i2c drivers can
> cleanly support more than one device type.

Hmm, I'm still "happy" with the broken DVB-T for saa7134 on 2.6.29,
tasting some Chianti vine now and need to sleep soon, but I'm also not
that confident that your saa7134 MSI t...@nywhere Plus i2c remote does
work addressing it directly, since previous reports always said it
becomes only visible at all after other devices are probed previously.

Unfortunately I can't test it, but will try to reach some with such
hardware and ask for testing, likely not on the list currently.

> What should be considered to decide whether two devices should be
> supported by the same driver or not, is how much their supporting code
> has in common.

What can not be translated to the input system I would like to know.
Andy seems to have closer looked into that.

To have it was a need after 2.5.x turned into 2.6.x. It was not even in
sight if and when lirc would be ever usable on it again. You have it
from Gerd.

I also think we currently have lots of users with all sorts of "TV"
cards. Triple cards are still quite expensive and can have only one DVB
and one analog stream at once, Quad cards depend on special PCI slots
and PCIe multi capable cards are not yet supported.

Because of that, there are lots of mythtv and similar machines stuffed
with all sort of cards in every free PCI slot I think.

Cheers,
Hermann










--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Jean Delvare]

On Sun, 05 Apr 2009 14:58:17 -0400, Andy Walls wrote:
> On Sun, 2009-04-05 at 20:31 +0200, Janne Grunau wrote:
> > I have devices for lirc_zilog (which should probably be merged with
> > lirc_i2c) 
> 
> Hmmm. Following Jean's reasoning, that may be the wrong way to go, if
> you want to avoid probing.  A module to handle each specific type of I2C
> IR chip, splitting up lirc_i2c and leaving lirc_zilog as is, may be
> better in the long run.

This really doesn't matter. With the new binding model, probing is
under control. You can do probing on some cards and not others, and you
can probe some addresses and not others. And one i2c drivers can
cleanly support more than one device type.

What should be considered to decide whether two devices should be
supported by the same driver or not, is how much their supporting code
has in common.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Andy Walls]

On Sun, 2009-04-05 at 13:33 -0500, Mike Isely wrote:

>  Also, lirc makes it possible to userspace map the underlying 
> IR codes to keybindings and associate multiple different remotes - all 
> of that is apparently hardcoded in ir-kbd-i2c.

Yes.  My first remote for my PC was an HP OEM'ed and customized unit.
LIRC's text configuration files made support for the remote's
non-standard keys a task for 'vi' and not 'make'.

Key mappings belong in configuration files - not hard coded in the
kernel.



>   Wierd or not, your 
> change makes it hard(er) on those who legitimately wish to use lirc.  
> Here's an interesting summary:
> 
> If fact, the only pvrusb2-driven hardware from Hauppauge that is known 
> to work with ir-kbd-i2c are the old 29xxx and 24xxx model series (not 
> the "MCE" series).  Those devices are out of production, AFAIK.  The 
> current devices being sold by Hauppauge don't work at all with 
> ir-kbd-i2c and probably never will.
> 
> Perhaps one can conclude that there hasn't been a lot of pressure (that 
> I know about) to deal with updating / enhancing / replacing ir-kbd-i2c 
> because lirc happens to be filling the niche better in many cases.

Here is where LIRC may be its own worst enemy.  LIRC has filled some
shortcomings in the kernel for support of IR device functions for so
long (LWN says LIRC is 10 years old), that large numbers of users have
come to depend on its operation, while at the same time apparently
removing impetus for doing much to update the in kernel IR device
support.

Some of the discussion on the LKML about why an input layer device is
sufficient for handling most, but not all cases is interesting:

http://lkml.org/lkml/2008/9/11/63

Gerd also enlightens us on why we have ir-kdb-i2c in kernel in that
post.  It appears that ir-kbd-i2c was written to avoid using LIRC for TV
card I2C IR devices for the most common use cases.  As such, it's a 90%
(80%, 70% ?) solution: no blasting, no raw IR parsing for unknown
protocols, only the most "common" remotes supported, and, of course, no
support for non-I2C devices.


My needs don't fit that unfortunately.  I need IR blasting, an uncommon
remote supported, and both USB and I2C IR device support.


Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Andy Walls]

On Sun, 2009-04-05 at 16:05 +0200, Jean Delvare wrote:
> Hi Hans,


Hi Jean,

> Updated patch set is available at:
> http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/
> 


--- v4l-dvb.orig/linux/drivers/media/video/ivtv/ivtv-i2c.c  2009-04-04 
10:53:08.0 +0200
+++ v4l-dvb/linux/drivers/media/video/ivtv/ivtv-i2c.c   2009-04-04 
10:58:36.0 +0200
[snip]
-
+   const unsigned short addr_list[] = {
+   0x1a, 0x18, 0x64, 0x30,
+   I2C_CLIENT_END
+   };
[snip]


I just noticed you're missing address 0x71 for ivtv.  At least some
PVR-150 boards have a Zilog chip at that address.

Regards,
Andy



--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Andy Walls]

On Sun, 2009-04-05 at 20:31 +0200, Janne Grunau wrote:
> On Sun, Apr 05, 2009 at 01:39:33PM -0400, Andy Walls wrote:

> > If one focuses on satisfying the LKML comments to lirc_dev and the
> > Makefile to get that kernel module in the kernel, then, at least for
> > video card hosted IR devices, there is an infrastructure to which to
> > hook new or rewritten i2c IR driver modules.
> 
> I guess lkml would NAK patches adding infrastructure only bits but we
> will probably for the next patchset concentrate on a few lirc drivers.
> Christopher doesn't participate in the merge attempt.

Oh, OK.

> > >  A git tree is available at
> > > 
> > > git://git.wilsonet.com/linux-2.6-lirc.git
> > > 
> > > Jared Wilson and I were working on it (mainly last september). Since the
> > > IR on the HD PVR is also driven by the same zilog chip as on other
> > > hauppauge devices I'll take of lirc_zilog. Help converting the i2c
> > > drivers to the new i2c model is welcome. General cleanup of lirc to make
> > > it ready for mainline is of course wellcome too.
> > 
> > I can help with this.  I'm mainly concerned with lirc_dev, lirc_i2c (for
> > Rx only use of the zilog at 0x71), lirc_zilog, and lirc_mceusb2.  That's
> > because, of course, I have devices that use those modules. :)
> 
> I have devices for lirc_zilog (which should probably be merged with
> lirc_i2c) 

Hmmm. Following Jean's reasoning, that may be the wrong way to go, if
you want to avoid probing.  A module to handle each specific type of I2C
IR chip, splitting up lirc_i2c and leaving lirc_zilog as is, may be
better in the long run.

I'd personally leave lirc_zilog separate since it handles Tx and RX for
one specific chip, and lirc_i2c is Rx only for a number of chips.
Perhaps dropping Rx support for the Zilog Z8 in lirc_i2c and then
modifying lirc_zilog to still do Rx, even if the "firmware" wasn't
available for Tx, is a better way to go.




> and lirc serial. Jarod has at least mce usb and imon devices.
> That are probably the devices we'll concentrate on the next submission.

OK.

> > lirc_dev and the API header would be my first priority, if you need
> > help.  Did anyone consolidate all the comments from the LKML on Jarrod's
> > patch submission?
> 
> no and I lost track which comments were already handled.

Hmm.  Well good luck.

Let me know if I can help.  I have 2 cards with the Zilog and a USB unit
that is supported by lirc_mceusb2.

Regards,
Andy

> Janne


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel 2.6.29 breaks DVB-T ASUSTeK Tiger LNA Hybrid Capture Device

[hermann pitton]

Hi,

Am Samstag, den 04.04.2009, 17:20 +0200 schrieb Ra.M.:
> hermann pitton ha scritto:
> > Am Samstag, den 04.04.2009, 02:45 +0200 schrieb hermann pitton:
> >   
> >> Hi Ralph,
> >>
> >> Am Freitag, den 03.04.2009, 20:49 + schrieb Ralph:
> >> 
> >>> ASUSTeK Tiger LNA Hybrid Capture Device PCI - Analog/DVB-T card
> >>> Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 
> >>> Video
> >>> Broadcast Decoder (rev d1)
> >>>
> >>> Works perfectly with kernel 2.6.28.4 (or older).
> >>> Recently, I have switched to 2.6.29 (same .config as 2.6.28.4) and now, at
> >>> boot
> >>> time, I get the message:
> >>>
> >>> IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
> >>>
> >>> Signal strength is very low and Kaffeine is unable to tune in any channel.
> >>> Same problem with kernel 2.6.29.1
> >>>
> >>> -
> >>>
> >>> Messages from /var/log/dmesg
> >>>
> >>> saa7134 :03:0a.0: PCI INT A -> Link[APC3] -> GSI 18 (level, low) -> \
> >>>  IRQ 18
> >>> saa7133[0]: found at :03:0a.0, rev: 209, irq: 18, latency: 32, mmio: \
> >>> 0xfdefe000
> >>> saa7133[0]: subsystem: 1043:4871, board: ASUS P7131 4871 \
> >>> [card=111,autodetected]
> >>> saa7133[0]: board init: gpio is 0
> >>> IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
> >>> saa7133[0]: i2c eeprom 00: 43 10 71 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
> >>> saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff ff ff ff ff ff ff ff
> >>> saa7133[0]: i2c eeprom 20: 01 40 01 02 03 00 01 03 08 ff 00 cf ff ff ff ff
> >>> saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >>> saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 03 22 15 50 ff ff ff ff ff ff
> >>> saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >>> saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >>> saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >>> saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >>> saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >>> saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >>> saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >>> saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >>> saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >>> saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >>> saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >>> tuner' 2-004b: chip found @ 0x96 (saa7133[0])
> >>> tda829x 2-004b: setting tuner address to 61
> >>> tda829x 2-004b: type set to tda8290+75a
> >>> saa7133[0]: registered device video0 [v4l2]
> >>> saa7133[0]: registered device vbi0
> >>> dvb_init() allocating 1 frontend
> >>> DVB: registering new adapter (saa7133[0])
> >>> DVB: registering adapter 0 frontend -32769 (Philips TDA10046H DVB-T)...
> >>> tda1004x: setting up plls for 48MHz sampling clock
> >>> tda1004x: timeout waiting for DSP ready
> >>> tda1004x: found firmware revision 0 -- invalid
> >>> tda1004x: trying to boot from eeprom
> >>> tda1004x: timeout waiting for DSP ready
> >>> tda1004x: found firmware revision 0 -- invalid
> >>> tda1004x: waiting for firmware upload...
> >>> saa7134 :03:0a.0: firmware: requesting dvb-fe-tda10046.fw
> >>> tda1004x: found firmware revision 29 -- ok
> >>> saa7134 ALSA driver for DMA sound loaded
> >>> IRQ 18/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
> >>> saa7133[0]/alsa: saa7133[0] at 0xfdefe000 irq 18 registered as card -1
> >>>
> >>>   
> >> thanks for your report, as announced previously, I unfortunately did not
> >> have time to run with latest always ... (guess why ...)
> >>
> >> The driver always worked with shared IRQs, if not, it was always a
> >> limitation of certain hardware or mostly in some combination with binary
> >> only drivers.
> >>
> >> If the above should be the case in general now, and not only caused by
> >> some blacklist, no print out in that direction, the driver is pretty
> >> broken again.
> >>
> >> I for sure don't have all for last months, but that
> >> "IRQF_DISABLED is not guaranteed on shared IRQs" for sure does not come
> >> from us here.
> >> 
> >
> > Do use something unusual like pollirq or something?
> >
> > We only have in saa7134-core.c
> >
> > /* initialize hardware #1 */
> > saa7134_board_init1(dev);
> > saa7134_hwinit1(dev);
> >
> > /* get irq */
> > err = request_irq(pci_dev->irq, saa7134_irq,
> >   IRQF_SHARED | IRQF_DISABLED, dev->name, dev);
> > if (err < 0) {
> > printk(KERN_ERR "%s: can't get IRQ %d\n",
> >dev->name,pci_dev->irq);
> > goto fail3;
> > }
> >
> > and in saa7134-alsa.c
> >
> > err = request_irq(dev->pci->irq, saa7134_alsa_irq,
> >  

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Erik Andrén]

2009/4/5 Jean-Francois Moine :
> On Sat, 04 Apr 2009 22:22:19 +0200
> Erik Andrén  wrote:
>        [snip]
>> When flipping the image horizontally, vertically or both, the sensor
>> pixel ordering changes. In the m5602 driver I was able to compensate
>> for this in the bridge code. In the stv06xx I don't have this
>> option. One way of solving this problem is by changing the
>> pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
>> format. When a vertical flip is required, change the format to
>> V4L2_SBGGR8.
>>
>> My current understanding of libv4l is that it probes the pixelformat
>>   upon device open. In order for this to work we would need either
>> poll the current pixelformat regularly or implement some kind of
>> notification mechanism upon a flipping request.
>>
>> What do you think is this the right way to go or is there another
>> alternative.
>
> Hi Erik,
>
> I saw such a problem in some other webcams. When doing a flip, the
> sensor scans the pixels in the reverse order. So,
>        R G R G
>        G B G B
> becomes
>        B G B G
>        G R G R
>
> The solution is to start the scan one line lower or higher for VFLIP
> and one pixel on the left or on the right for HFLIP.
>

As I wrote in my original email I haven't found out a way to adjust
this when using the vv6410 sensor.

> May you do this with all the sensors of the stv06xx?

This issue is vv6410 specific.

Best regards,
Erik Andrén

>
> Cheers.
>
> --
> Ken ar c'hentan |             ** Breizh ha Linux atav! **
> Jef             |               http://moinejf.free.fr/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Theodore Kilgore]

On Sun, 5 Apr 2009, Jean-Francois Moine wrote:


On Sat, 04 Apr 2009 22:22:19 +0200
Erik Andrén  wrote:
[snip]

When flipping the image horizontally, vertically or both, the sensor
pixel ordering changes. In the m5602 driver I was able to compensate
for this in the bridge code. In the stv06xx I don't have this
option. One way of solving this problem is by changing the
pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
format. When a vertical flip is required, change the format to
V4L2_SBGGR8.

My current understanding of libv4l is that it probes the pixelformat
  upon device open. In order for this to work we would need either
poll the current pixelformat regularly or implement some kind of
notification mechanism upon a flipping request.

What do you think is this the right way to go or is there another
alternative.


Hi Erik,

I saw such a problem in some other webcams. When doing a flip, the
sensor scans the pixels in the reverse order. So,
R G R G
G B G B
becomes
B G B G
G R G R

The solution is to start the scan one line lower or higher for VFLIP
and one pixel on the left or on the right for HFLIP.

May you do this with all the sensors of the stv06xx?


That is a very clever solution -- if the hardware will do such a thing. I 
can not speak for the stv06xx cameras, of course. But I am pretty sure it 
is impossible for the sq905 cameras. Therefore it is not a universal 
solution. If it can be done, great. But it seems to me that the general 
way to do this would be just to adjust the Bayer tiling to be in accord 
with the flipping after it is done (one of the possibilities already 
mentioned above).


The problem which I would address is that the need for image flipping 
ought to be handled in a standard way, if possible. The sq905 cameras 
(with which I have been directly concerned) do give rise to similar 
problems. The big difference is that there is no way with an sq905 to tell 
the camera to do any flipping in hardware, nor to shift the pixel reading 
one space over or down. Hence my obvious interest in seeing this problem 
analysed completely, and in seeing the best solution adopted. One possible 
way to do that would be to have the choice for the pixel format to reflect 
what it ought to be, after any flipping has taken place. From this point 
of view, it would not matter if the flipping is done in V4L or in 
hardware, before the data has left the camera. It would only be necessary 
to agree that any required flipping takes place first, and then the Bayer 
interpolation afterwards.


Theodore Kilgore

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Mike Isely]

On Sun, 5 Apr 2009, Hans Verkuil wrote:

   [...]

> 
> Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those 
> drivers that did not autoload this module. The driver author can refine 
> things later (I'll definitely will do that for ivtv).

Yes, and I will do the same for pvrusb2.  Simple is good.


> 
> It will be interesting if someone can find out whether lirc will work at all 
> once autoprobing is removed from i2c. If it isn't, then perhaps that will 
> wake them up to the realization that they really need to move to the 
> kernel.

It's probably going to break, and that will wake them up.  There's no 
choice otherwise.


> 
> The new mechanism is the right way to do it: the adapter driver has all the 
> information if, where and what IR is used and so should be the one to tell 
> the kernel what to do. Attempting to autodetect and magically figure out 
> what IR might be there is awkward and probably impossible to get right 
> 100%.
> 
> Hell, it's wrong already: if you have another board that already loads 
> ir-kbd-i2c then if you load ivtv or pvrusb2 afterwards you get ir-kbd-i2c 
> whether you like it or not, because ir-kbd-i2c will connect to your i2c 
> adapter like a leech. So with the addition of a module option you at least 
> give back control of this to the user.

Yes, I know this is a possibility.  It sucks and long term the new 
mechanism is the solution.  I don't want anyone to think I am against 
the new mechanism.  I'm for it.  But I'd like to minimize the damage 
potential on the way there.


> 
> When this initial conversion is done I'm pretty sure we can improve 
> ir-kbd-i2c to make it easier to let the adapter driver tell it what to do. 
> So we don't need those horrible adapter ID tests and other magic that's 
> going on in that driver. But that's phase two.

My impression (at least for pvrusb2-driven devices) is that the later IR 
receivers require a completely different driver to work properly; one 
can't just bolt additional features into ir-kbd-i2c for this.  In lirc's 
case, a different driver is in fact used.  But you know this already.

I haven't looked at ir-kbd-i2c in a while, but one other thing I 
seriously did not like about it was that the mapping of IR codes to key 
events was effectively hardcoded in the driver.  That makes it difficult 
to make the same driver work with different kinds of remotes.  Even if 
the bridge driver (e.g. pvrusb2) were to supply such a map, that's still 
wrong because it's within the realm of possibility that the user might 
actually want to use a different remote transmitter (provided it is 
compatible enough to work with the receiver hardware).  The lirc 
architecture solves this easily via a conf file in userspace.  In fact, 
lirc can map multiple mappings to a single receiver, permitting it to 
work concurrently with more than one remote.  But is such a thing even 
possible with ir-kbd-i2c?  I know this is one reason people tend to 
choose lirc.

  -Mike

-- 

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model

[Mike Isely]

On Sun, 5 Apr 2009, Jean Delvare wrote:

> Hi Mauro,
> 
> On Sun, 5 Apr 2009 07:01:16 -0300, Mauro Carvalho Chehab wrote:
> > From the discussions we already have, I noticed some points to take care of:
> > 
> > 1) about the lirc support, I don't think we should change a kernel driver 
> > due
> > to an out-of-tree kernel driver. As I've commented on PATCH 3/6 discussion, 
> > we
> > need to better address this with lirc developers;
> 
> Well, the new binding model makes it harder for "rogue" drivers such as
> lirc_i2c. They will need _some_ form of cooperation from us, which will
> most likely come when they get merged into the kernel tree.
> 
> > 2) the way Mike is proposing to solve the issue with pvrusb2 will break
> > userspace usage for people that have those devices whose IR work with the
> > in-kernel IR i2c driver. This means that we'll cause a kernel regression 
> > due to
> > an out-of-tree driver;

It's an either/or.  If nothing is done, the ir-kbd-i2c become unusable 
for pvrusb2 but lirc (for now) continues to work.  If Jean's change is 
accepted as-is, then ir-kbd-i2c will be ok but now lirc is toast.  If I 
implement what I am suggesting, then it becomes possible at least for 
both cases to still work, but with a module option.  Not perfect, but it 
is the only way I see to allow this situation to retain some sanity.

In the longer term, the lirc folks are going to have to change what they 
are doing.  Fine, that's a problem they have to solve.  It's nothing I 
can do anyting about.  But I am not going to be the instigator that 
breaks lirc as used by the pvrusb2 driver.

In the short term, implementing the module option breaks the deadlock 
here.  Jean can continue getting rid of the old i2c model and I won't be 
a pain about it.


> > 
> > 3) So far, nobody gave us any positive return that the new IR model is 
> > working with
> > any of the touched drivers. So, more tests are needed. I'm expecting to 
> > have a
> > positive reply for each of the touched drivers. People, please test!
> 
> Yes, please! :)
> 
> > Since the merge window is almost finished, IMO, we should postpone those
> > changes to 2.6.31, (...)
> 
> The legacy i2c model will be gone in 2.6.30. Really. Hans and myself
> have put enough energy into this to not let it slip for just a
> miserable infrared support module which I understand is hardly used by
> anyone.
> 
> So it's really up to you, either you accept my ir-kbd-i2c conversion
> "now" (that is, when it has received the minimum testing and reviewing
> it deserves) and ir-kbd-i2c has a chance to work in 2.6.30, or you
> don't and I'll just have to mark ir-kbd-i2c as BROKEN to prevent build
> failures.

Accept his ir-kbd-i2c conversion now, minus the pvrusb2 changes.  I will 
deal with the pvrusb2 driver appropriately (and immediately).  That 
should resolve the issue for the short term.


> 
> > to better address the lirc issue and to give people more
> > time for testing, applying the changesets after the end of the merge window 
> > at
> > the v4l/dvb development tree. This will help people to test, review and 
> > propose
> > changes if needed.
> 
> These changes are on-going for over a year now. If the lirc people
> didn't hear about it so far, I doubt they will pay more attention just
> because we delay the deadline by 2 months. The only thing that will get
> their attention is when lirc_i2c break. So let's just do that ;)
> 
> Don't get me wrong. I don't want to be (too) rude to lirc developers.
> If they need help to port their code to the new i2c binding model, I'll
> help them. If they need help to merge lirc_i2c into the kernel, I'll
> help as well. But I don't see any point in delaying important, long
> awaited kernel changes just for them. As long as they are out-of-tree,
> they can fix things after the fact easily. They aren't affected by the
> merge window. They'll have several weeks before kernel 2.6.30 is
> actually released, which they can use to fix anything that broke.
> 

I agree.

  -Mike


-- 

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Mike Isely]

Jean:

More comments interspersed below...

On Sun, 5 Apr 2009, Jean Delvare wrote:

   [...]

> 
> > Remember 
> > that the pvrusb2 driver did not autoload ir-kbd-i2c before this patch.  
> > Before this change, a user could elect not to use ir-i2c-kbd simply by 
> > not loading it.
> 
> Which was pretty fragile because another bridge driver could still have
> loaded it.

Well I didn't say it was perfect.  But this has been a valid use-case 
and I know people have been using this it this way.

> 
> > The pvrusb2 driver didn't request it, because the 
> > intent all along there is that the user makes the choice by loading the 
> > desired driver.
> 
> Which simply underlines how weird the current situation is... Forcing
> the choice on the user is pretty bad from a usability perspective.

What's worse is taking away a choice when the alternatives are not 
interchangeable.  In this case we have two different drivers with two 
different interfaces which do not cover the same range of hardware.  
The lirc case happens to work quite well in MythTV.  In addition, lirc 
covers hardware situations involving the pvrusb2 driver that ir-kbd-i2c 
does not.  Also, lirc makes it possible to userspace map the underlying 
IR codes to keybindings and associate multiple different remotes - all 
of that is apparently hardcoded in ir-kbd-i2c.  Wierd or not, your 
change makes it hard(er) on those who legitimately wish to use lirc.  
Here's an interesting summary:

If fact, the only pvrusb2-driven hardware from Hauppauge that is known 
to work with ir-kbd-i2c are the old 29xxx and 24xxx model series (not 
the "MCE" series).  Those devices are out of production, AFAIK.  The 
current devices being sold by Hauppauge don't work at all with 
ir-kbd-i2c and probably never will.

Perhaps one can conclude that there hasn't been a lot of pressure (that 
I know about) to deal with updating / enhancing / replacing ir-kbd-i2c 
because lirc happens to be filling the niche better in many cases.


> 
> >  Now with this change, the pvrusb2 driver is going to 
> > attempt to load ir-kbd-i2c where asked for or not.
> 
> Not exactly, only the device will be the instantiated, the drivers
> won't be loaded, but the result is indeed the same: it's getting in
> lirc_i2c's way if that's what the user wants to use.

Well yes.  The binding of the address is enough to mess things up.


> 
> >  And if not, the 
> > resulting binding will prevent lirc_i2c from later on loading.  If the 
> > user had been loading lirc_i2c previously, this will cause his/her usage 
> > of IR to break.  No, it's not perfect, but it worked.  I'm all for 
> > improving things, but not by removing an ability that people are using.
> 
> I have just added a disable_ir module parameter to work around this
> issue. Set it to 1 and no "ir-kbd" device will be instantiated, letting
> lirc_i2c do whatever it wants with the IR receiver device.
> 
> You might argue that this is still a regression because the user now
> has to pass an extra parameter to get the same result as before, but
> OTOH lirc_i2c will need changes pretty soon anyway, its behavior will
> have to be changed and the users will notice. There's no way we can go
> from the current weird situation to a sane situation without changing
> the (unfortunate) user habits.

Yes, I would argue that this is still a regression.  I really think this 
should be an *enable* switch in order to match previous behavior.  In 
the long term I agree that this is less than optimal / undesirable, 
however in the long term none of it is going to matter anyway, since it 
looks like lirc without further changes is going to have problems here.  
Once (if) lirc is changed to use the new binding model then this whole 
argument becomes moot.  Given that, then anything done here is a short 
term strategy, designed to avoid a regression, so I would much rather 
this be an enable not a disable switch.


> 
> > (...)
> > I really don't want to throw rocks here; it's always better to work out 
> > the solution than simply block any changes at all.  I realize that 
> > something has to be done here in order to keep ir-kbd-i2c viable as a 
> > choice for users of the pvrusb2 driver.  To that end, how about this 
> > strategy:
> > 
> > 1. Just drop the part of the patch for the pvrusb2 driver and get the 
> > rest merged.  Yes, I realize that this will break use of ir-kbd-i2c in 
> > cooperation with the pvrusb2 driver.
> 
> As Mauro already said: not acceptable. Breaking an in-tree driver
> (ir-kbd-i2c) is worse than breaking an out-of-tree driver (lirc_i2c)
> regardless of the respective number of users or usefulness of these
> drivers.

*I* didn't break ir-kbd-i2c.  And now because of what has effectively 
"broken" (viewed in just the wrong light) you are asking me to accept 
changes in the pvrusb2 driver to make up the difference?  Normally I 
wouldn't object, except those proposed changes in turn will break 
another driver (lirc).  That is why I nack

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Janne Grunau]

On Sun, Apr 05, 2009 at 01:39:33PM -0400, Andy Walls wrote:
> On Sun, 2009-04-05 at 16:37 +0200, Janne Grunau wrote:
> > 
> > I would guess that it won't work. There is an effort to merge lirc. It's
> > currently stalled though.
> 
> Perhaps you and Jarrod and Christopher have already discussed this,
> but...
> 
> Instead of trying to push all of the LIRC kernel components through in
> one big patch set, perhaps it would be easier to just get the lirc_dev
> and any other needed infrastructure components in first.
> 
> If one focuses on satisfying the LKML comments to lirc_dev and the
> Makefile to get that kernel module in the kernel, then, at least for
> video card hosted IR devices, there is an infrastructure to which to
> hook new or rewritten i2c IR driver modules.

I guess lkml would NAK patches adding infrastructure only bits but we
will probably for the next patchset concentrate on a few lirc drivers.
Christopher doesn't participate in the merge attempt.

> >  A git tree is available at
> > 
> > git://git.wilsonet.com/linux-2.6-lirc.git
> > 
> > Jared Wilson and I were working on it (mainly last september). Since the
> > IR on the HD PVR is also driven by the same zilog chip as on other
> > hauppauge devices I'll take of lirc_zilog. Help converting the i2c
> > drivers to the new i2c model is welcome. General cleanup of lirc to make
> > it ready for mainline is of course wellcome too.
> 
> I can help with this.  I'm mainly concerned with lirc_dev, lirc_i2c (for
> Rx only use of the zilog at 0x71), lirc_zilog, and lirc_mceusb2.  That's
> because, of course, I have devices that use those modules. :)

I have devices for lirc_zilog (which should probably be merged with
lirc_i2c) and lirc serial. Jarod has at least mce usb and imon devices.
That are probably the devices we'll concentrate on the next submission.

> lirc_dev and the API header would be my first priority, if you need
> help.  Did anyone consolidate all the comments from the LKML on Jarrod's
> patch submission?

no and I lost track which comments were already handled.

Janne
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[cron job] v4l-dvb daily build 2.6.22 and up: OK, 2.6.16-2.6.21: WARNINGS

[Hans Verkuil]

This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Sun Apr  5 19:00:09 CEST 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   11392:151524ab300a
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.22.19-armv5: OK
linux-2.6.23.12-armv5: OK
linux-2.6.24.7-armv5: OK
linux-2.6.25.11-armv5: OK
linux-2.6.26-armv5: OK
linux-2.6.27-armv5: OK
linux-2.6.28-armv5: OK
linux-2.6.29-armv5: OK
linux-2.6.27-armv5-ixp: OK
linux-2.6.28-armv5-ixp: OK
linux-2.6.29-armv5-ixp: OK
linux-2.6.28-armv5-omap2: OK
linux-2.6.29-armv5-omap2: OK
linux-2.6.22.19-i686: OK
linux-2.6.23.12-i686: OK
linux-2.6.24.7-i686: OK
linux-2.6.25.11-i686: OK
linux-2.6.26-i686: OK
linux-2.6.27-i686: OK
linux-2.6.28-i686: OK
linux-2.6.29-i686: OK
linux-2.6.23.12-m32r: OK
linux-2.6.24.7-m32r: OK
linux-2.6.25.11-m32r: OK
linux-2.6.26-m32r: OK
linux-2.6.27-m32r: OK
linux-2.6.28-m32r: OK
linux-2.6.29-m32r: OK
linux-2.6.22.19-mips: OK
linux-2.6.26-mips: OK
linux-2.6.27-mips: OK
linux-2.6.28-mips: OK
linux-2.6.29-mips: OK
linux-2.6.27-powerpc64: OK
linux-2.6.28-powerpc64: OK
linux-2.6.29-powerpc64: OK
linux-2.6.22.19-x86_64: OK
linux-2.6.23.12-x86_64: OK
linux-2.6.24.7-x86_64: OK
linux-2.6.25.11-x86_64: OK
linux-2.6.26-x86_64: OK
linux-2.6.27-x86_64: OK
linux-2.6.28-x86_64: OK
linux-2.6.29-x86_64: OK
fw/apps: OK
sparse (linux-2.6.29): OK
linux-2.6.16.61-i686: WARNINGS
linux-2.6.17.14-i686: OK
linux-2.6.18.8-i686: OK
linux-2.6.19.5-i686: OK
linux-2.6.20.21-i686: OK
linux-2.6.21.7-i686: OK
linux-2.6.16.61-x86_64: WARNINGS
linux-2.6.17.14-x86_64: OK
linux-2.6.18.8-x86_64: OK
linux-2.6.19.5-x86_64: OK
linux-2.6.20.21-x86_64: OK
linux-2.6.21.7-x86_64: OK

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2

The V4L2 specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/v4l2.html

The DVB API specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Fwd: topro 6800 driver

[Andy Shevchenko]

On Thu, Apr 2, 2009 at 7:41 PM, Anders Blomdell
 wrote:
>> However I still no luck with it neither on F-9 kernel nor 2.6.29+ (git
>> HEAD from Saturday).
>> The driver is loaded ok, but no program can capture a picture.
> What programs did you try?
>
> On my 2.6.27.19-170.2.35.fc10.i686 the following works:
Ok, today I've updated system to F-10.

[a...@dhcppc38 ~]$ uname -a
Linux dhcppc38 2.6.27.21-170.2.56.fc10.i686 #1 SMP Mon Mar 23 23:37:54
EDT 2009 i686 i686 i386 GNU/Linux

[a...@dhcppc38 ~]$ modinfo tp6800
filename:       /lib/modules/2.6.27.21-170.2.56.fc10.i686/extra/tp6800.ko
license:        GPL
author:         Anders Blomdell 
description:    Topro TP6800 gspca webcam driver
srcversion:     1FF6924D74770F52CB21F9F
alias:          usb:v06A2p0003d*dc*dsc*dp*ic*isc*ip*
depends:        gspca_main
vermagic:       2.6.27.21-170.2.56.fc10.i686 SMP mod_unload 686 4KSTACKS

[a...@dhcppc38 ~]$ lsusb
...
Bus 002 Device 003: ID 06a2:0003 Topro Technology, Inc.
...

>  mplayer tv:// -tv driver=v4l2:device=/dev/video0:width=640:height=480

[a...@dhcppc38 ~]$ mplayer tv:// -tv
driver=v4l2:device=/dev/video0:width=640:height=480
MPlayer SVN-r28461-4.3.2 (C) 2000-2009 MPlayer Team
...
Selected device: USB Camera (06a2:0003)
...
 Current format: unknown (0x4745504a)
tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
v4l2: ioctl enum norm failed: Invalid argument
Error: Cannot set norm!
Selected input hasn't got a tuner!
v4l2: Cannot get fps
v4l2: ioctl set mute failed: Invalid argument
v4l2: ioctl query control failed: Invalid argument
v4l2: ioctl query control failed: Invalid argument
v4l2: ioctl query control failed: Invalid argument
v4l2: ioctl query control failed: Invalid argument
==
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffmjpeg] vfm: ffmpeg (FFmpeg MJPEG decoder)
==
Audio: no sound
Starting playback...
v4l2: select timeout ??% ??,?% 0 0
v4l2: select timeout ??% ??,?% 0 0
v4l2: select timeout ??% ??,?% 0 0
V:   0.0   8/  8 ??% ??% ??,?% 0 0

MPlayer interrupted by signal 2 in module: video_read_frame
v4l2: select timeout
v4l2: select timeout ??% ??,?% 0 0
v4l2: ioctl set mute failed: Invalid argument
v4l2: 0 frames successfully processed, 1 frames dropped.

Exiting... (Quit)

So, the same effect on 2.6.29.

vlc:
[a...@dhcppc38 ~]$ vlc v4l2://dev/video0:width=640:height=480
VLC media player 0.9.8a Grishenko
[0001] main libvlc debug: VLC media player - version 0.9.8a
Grishenko - (c) 1996-2008 the VideoLAN team
[0001] main libvlc debug: libvlc was configured with ./configure
'--build=i686-pc-linux-gnu' '--host=i686-pc-linux-gnu'
'--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr'
'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--disable-dependency-tracking'
'--disable-rpath' '--enable-release' '--with-tuning=no'
'--enable-switcher' '--enable-shout' '--enable-live555'
'--enable-opencv' '--enable-v4l' '--enable-pvr' '--enable-gnomevfs'
'--enable-cddax' '--enable-faad' '--enable-twolame' '--enable-real'
'--enable-realrtsp' '--enable-flac' '--enable-tremor' '--enable-speex'
'--enable-tarkin' '--enable-theora' '--enable-svg' '--enable-snapshot'
'--enable-svgalib' '--enable-xvmc' '--enable-directfb' '--enable-aa'
'--enable-caca' '--enable-jack' '--enable-portaudio' '--enable-pulse'
'--enable-ncurses' '--enable-xosd' '--enable-fbosd'
'--enable-galaktos' '--enable-lirc' '--enable-loader'
'--enable-mozilla' 'build_alias=i686-pc-linux-gnu'
'host_alias=i686-pc-linux-gnu' 'target_alias=i386-redhat-linux-gnu'
'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386
-mtune=generic -fasynchronous-unwind-tables' 'CXXFLAGS=-O2 -g -pipe
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables'
'PKG_CONFIG_PATH=/usr/lib/pkgconfig:/usr/share/pkgconfig'
[0001] main libvlc debug: translation test: code is "ru"
[0001] main libvlc: Running vlc with the default interface. Use
'cvlc' to use vlc without interface.
[0432] v4l2 demux error: cannot open video device (No such file or
directory)
ALSA lib pcm.c:2202:(snd_pcm_open_noupdate) Unknown PCM dev/video0
[0432] v4l2 demux error: cannot open device dev/video0 for ALSA
audio (No such file or directory)
[0432] v4l2 demux error: cannot open device dev/video0 for OSS
audio (No such file or directory)
libv4l2: error dequeuing buf: Input/output error
[0432] v4l2 demux error: Failed to wait (VIDIOC_DQBUF)
libv4l2: error dequeuing buf: Input/output e

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Andy Walls]

On Sun, 2009-04-05 at 15:08 +0200, Jean Delvare wrote:
> Hi Andy,
> 

> > > If IR on the cx18 is not supported (by the ir-kbd-i2c driver) then I
> > > can simplify my patch set and omit the cx18 entirely.
> 
> Which I just did...
> 
> > The HVR-1600 could have been supported by ir-kbd-i2c.
> > 
> > It's submission was redirected slightly here:
> > 
> > http://lkml.org/lkml/2009/2/3/118
> > 
> > And deferred here:
> > 
> > http://www.spinics.net/lists/linux-media/msg03883.html
> > 
> > until your changes were done.
> 
> OK. Then let's indeed get my changes merged first, and then we can see
> the best way to add support for the HVR-1600 IR.

OK.  I'll test your change anyway if I can.



> > lirc_pvr150 has always been out of kernel and likely always will be.
> 
> Any valid reason? Out-of-free drivers are a pain for users :(

Well, like many of the lirc modules, it's a little kludged.  The main
problem is this:

1. lirc_pvr150, in the past, needed to make a direct call into the ivtv
module to reset the IR chip, if it detected that the chip was hung up.
That's why it tries to load the ivtv module, to make sure that symbol is
in the kernel.  This could cause problems, if it was a Z8 chip that was
supported by some other bridge driver.  I wrote a patch for lirc_pvr150
for cx18 devices for users who needed it. 

lirc_zilog is the cut down version of lirc_pvr150 module that was
submitted in the patchset to the LKML, and no longer has the reset
logic.  The reset logic is not needed anymore as far as I can tell, and
thus the cx18 specific patch is probably irrelevant for lirc_zilog.


Other weird things include:

2. In lirc_pvr150 and lirc_zilog, both the IR Rx and IR Tx support are
in one module, which is a break from the normal LIRC driver modules that
keep those functions separate.  This was done for the sake of detecting
if the chip had hung up and to call the reset logic, AFAICT.

3. lirc_pvr150 and lirc_zilog have an IR blaster "firmware" image that
is really an encoding of a bunch of captured sequences between the
Windows driver and the Z8F0811 chip.  It allows the lirc_zilog or
lirc_pvr150 driver to do IR blasting by essentially performing a replay
attack on the Z8F0811.

Since the Zilog EULA that comes with the Hauppauge Windows IR driver for
the Z8F0811 is pretty draconian, replaying captured snoops is probably
the best that can be done legally to stimulate the microcontroller IR Tx
code in the Z8 as delivered.


Regards,
Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [0904_11] Siano: smsendian & smsdvb - binding the smsendian to smsdvb

[Uri Shkolnik]

--- On Sun, 4/5/09, Uri Shkolnik  wrote:

> From: Uri Shkolnik 
> Subject: [PATCH] [0904_11] Siano: smsendian & smsdvb - binding the smsendian 
> to smsdvb
> To: "LinuxML" 
> Date: Sunday, April 5, 2009, 1:20 PM
> 
> # HG changeset patch
> # User Uri Shkolnik 
> # Date 1238743608 -10800
> # Node ID 01979ae55ffec22d74b77681613f38bd606be227
> # Parent  ec7ee486fb86d51bdb48e6a637a6ddd52e9e08c2
> [PATCH] [0904_11] Siano: smsendian & smsdvb - binding
> the smsendian to smsdvb
> 
> From: Uri Shkolnik 
> 
> Bind the smsendian, which manipulates some Siano's messages
> content
> when using Siano chip-set with big-endian target, 
> with the DVB-API v3 client adapter.
> 
> Priority: normal
> 
> Signed-off-by: Uri Shkolnik 
> 
> diff -r ec7ee486fb86 -r 01979ae55ffe
> linux/drivers/media/dvb/siano/Makefile
> ---
> a/linux/drivers/media/dvb/siano/Makefile   
> Fri Apr 03 10:10:22 2009 +0300
> +++
> b/linux/drivers/media/dvb/siano/Makefile   
> Fri Apr 03 10:26:48 2009 +0300
> @@ -1,4 +1,4 @@ sms1xxx-objs := smscoreapi.o sms-cards.o
> -sms1xxx-objs := smscoreapi.o sms-cards.o
> +sms1xxx-objs := smscoreapi.o sms-cards.o smsendian.o
>  
>  obj-$(CONFIG_DVB_SIANO_SMS1XXX) += sms1xxx.o
>  obj-$(CONFIG_DVB_SIANO_SMS1XXX) += smsusb.o
> diff -r ec7ee486fb86 -r 01979ae55ffe
> linux/drivers/media/dvb/siano/smsdvb.c
> ---
> a/linux/drivers/media/dvb/siano/smsdvb.c   
> Fri Apr 03 10:10:22 2009 +0300
> +++
> b/linux/drivers/media/dvb/siano/smsdvb.c   
> Fri Apr 03 10:26:48 2009 +0300
> @@ -24,7 +24,7 @@ along with this program.  If not,
> see   #include 
>  
>  #include "smscoreapi.h"
> -/*#include "smsendian.h"*/
> +#include "smsendian.h"
>  #include "sms-cards.h"
>  
>  #ifndef DVB_DEFINE_MOD_OPT_ADAPTER_NR
> @@ -52,7 +52,7 @@ struct smsdvb_client_t {
>      fe_status_t fe_status;
>      int fe_ber, fe_snr, fe_unc,
> fe_signal_strength;
>  
> -    struct completion tune_done,
> stat_done;
> +    struct completion tune_done;
>  
>      /* todo: save freq/band instead whole
> struct */
>      struct dvb_frontend_parameters
> fe_params;
> @@ -114,7 +114,7 @@ static int smsdvb_onresponse(void
> *conte
>      u32 *pMsgData = (u32 *) phdr + 1;
>      /*u32 MsgDataLen = phdr->msgLength -
> sizeof(struct SmsMsgHdr_ST);*/
>  
> -    /*smsendian_handle_rx_message((struct
> SmsMsgData_ST *) phdr);*/
> +    smsendian_handle_rx_message((struct
> SmsMsgData_ST *) phdr);
>  
>      switch (phdr->msgType) {
>      case MSG_SMS_DVBT_BDA_DATA:
> @@ -271,7 +271,7 @@ static int smsdvb_start_feed(struct
> dvb_
>      PidMsg.xMsgHeader.msgLength =
> sizeof(PidMsg);
>      PidMsg.msgData[0] = feed->pid;
>  
> -    /* smsendian_handle_tx_message((struct
> SmsMsgHdr_ST *)&PidMsg); */
> +    smsendian_handle_tx_message((struct
> SmsMsgHdr_ST *)&PidMsg);
>      return
> smsclient_sendrequest(client->smsclient, &PidMsg,
>             
> sizeof(PidMsg));
>  }
> @@ -291,7 +291,7 @@ static int smsdvb_stop_feed(struct
> dvb_d
>      PidMsg.xMsgHeader.msgLength =
> sizeof(PidMsg);
>      PidMsg.msgData[0] = feed->pid;
>  
> -    /* smsendian_handle_tx_message((struct
> SmsMsgHdr_ST *)&PidMsg); */
> +    smsendian_handle_tx_message((struct
> SmsMsgHdr_ST *)&PidMsg);
>      return
> smsclient_sendrequest(client->smsclient, &PidMsg,
>             
> sizeof(PidMsg));
>  }
> @@ -302,7 +302,7 @@ static int
> smsdvb_sendrequest_and_wait(s
>  {
>      int rc;
>  
> -    /* smsendian_handle_tx_message((struct
> SmsMsgHdr_ST *)buffer); */
> +    smsendian_handle_tx_message((struct
> SmsMsgHdr_ST *)buffer);
>      rc =
> smsclient_sendrequest(client->smsclient, buffer, size);
>      if (rc < 0)
>          return rc;
> 
> 
> 
>       
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


This patch is voided and been replaced by another (newer) patch.


  
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Jean-Francois Moine]

On Sat, 04 Apr 2009 22:22:19 +0200
Erik Andrén  wrote:
[snip]
> When flipping the image horizontally, vertically or both, the sensor
> pixel ordering changes. In the m5602 driver I was able to compensate
> for this in the bridge code. In the stv06xx I don't have this
> option. One way of solving this problem is by changing the
> pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
> format. When a vertical flip is required, change the format to
> V4L2_SBGGR8.
> 
> My current understanding of libv4l is that it probes the pixelformat
>   upon device open. In order for this to work we would need either
> poll the current pixelformat regularly or implement some kind of
> notification mechanism upon a flipping request.
> 
> What do you think is this the right way to go or is there another
> alternative.

Hi Erik,

I saw such a problem in some other webcams. When doing a flip, the
sensor scans the pixels in the reverse order. So,
R G R G
G B G B
becomes
B G B G
G R G R

The solution is to start the scan one line lower or higher for VFLIP
and one pixel on the left or on the right for HFLIP.

May you do this with all the sensors of the stv06xx?

Cheers.

-- 
Ken ar c'hentan | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Andy Walls]

Hi Janne,

On Sun, 2009-04-05 at 16:37 +0200, Janne Grunau wrote:
> On Sun, Apr 05, 2009 at 07:46:47AM +0200, Hans Verkuil wrote:
> >
> > Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those 
> > drivers that did not autoload this module. The driver author can refine 
> > things later (I'll definitely will do that for ivtv).
> > 
> > It will be interesting if someone can find out whether lirc will work at 
> > all 
> > once autoprobing is removed from i2c. If it isn't, then perhaps that will 
> > wake them up to the realization that they really need to move to the 
> > kernel.
> 
> I would guess that it won't work. There is an effort to merge lirc. It's
> currently stalled though.

Perhaps you and Jarrod and Christopher have already discussed this,
but...

Instead of trying to push all of the LIRC kernel components through in
one big patch set, perhaps it would be easier to just get the lirc_dev
and any other needed infrastructure components in first.

If one focuses on satisfying the LKML comments to lirc_dev and the
Makefile to get that kernel module in the kernel, then, at least for
video card hosted IR devices, there is an infrastructure to which to
hook new or rewritten i2c IR driver modules.

 
>  A git tree is available at
> 
> git://git.wilsonet.com/linux-2.6-lirc.git
> 
> Jared Wilson and I were working on it (mainly last september). Since the
> IR on the HD PVR is also driven by the same zilog chip as on other
> hauppauge devices I'll take of lirc_zilog. Help converting the i2c
> drivers to the new i2c model is welcome. General cleanup of lirc to make
> it ready for mainline is of course wellcome too.


I can help with this.  I'm mainly concerned with lirc_dev, lirc_i2c (for
Rx only use of the zilog at 0x71), lirc_zilog, and lirc_mceusb2.  That's
because, of course, I have devices that use those modules. :)

lirc_dev and the API header would be my first priority, if you need
help.  Did anyone consolidate all the comments from the LKML on Jarrod's
patch submission?

Regards,
Andy

> Janne


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: topro 6800 driver

[Jean-Francois Moine]

On Sat, 04 Apr 2009 13:29:09 +0200
Anders Blomdell  wrote:
> >> Jean-Francois: feel free to add this to gspca if it lives up to
> >> your standards, otherwise tell me what needs to be changed.

Hi Anders,

Your driver seems fine, but, to add it to gspca, I need a full patch,
i.e the diff of the source, Kconfig, Makefile, webcam reference in
gspca.txt (linux/Documentation/..) and your SOB (signature).

You should also ask Mauro to add you as a maintainer with a diff of the
MAINTAINERS file from the last Linux kernel.

Cheers.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Janne Grunau]

On Sun, Apr 05, 2009 at 06:37:43PM +0200, Jean Delvare wrote:
> Hi Janne,
> 
> On Sun, 5 Apr 2009 16:37:49 +0200, Janne Grunau wrote:
> > On Sun, Apr 05, 2009 at 07:46:47AM +0200, Hans Verkuil wrote:
> > >
> > > Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those 
> > > drivers that did not autoload this module. The driver author can refine 
> > > things later (I'll definitely will do that for ivtv).
> > > 
> > > It will be interesting if someone can find out whether lirc will work at 
> > > all 
> > > once autoprobing is removed from i2c. If it isn't, then perhaps that will 
> > > wake them up to the realization that they really need to move to the 
> > > kernel.
> > 
> > I would guess that it won't work. There is an effort to merge lirc. It's
> > currently stalled though. A git tree is available at
> > 
> > git://git.wilsonet.com/linux-2.6-lirc.git
> 
> I tried to clone this but it failed:
> 
> git.wilsonet.com[0: 72.93.233.4]: errno=Connection timed out
> fatal: unable to connect a socket (Connection timed out)

hmm, getting that here too. I'll send Jarod a mail. You can use my clone
instead: git://git.jannau.net/linux-2.6-lirc.git

> I will happily help you with the i2c side of things. Without an access
> to your git tree however, I don't know the latest state of your code.
> And I can't see any lirc_zilog module in the CVS repository of lirc
> either. But if you show me the i2c code you're worried about, I'll let
> you know what I think about it.

lirc_zilog or lirc_pvr is not in lirc's cvs since it requires a
'firmware' for mapping keys to sequences for the ir blaster.

Janne
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Driver for GL861+AF9003+MT2060]

[Luca Olivetti]

El Fri, 03 Apr 2009 01:03:23 +0300
Antti Palosaari  escribió:

> You don't need to implement all those in most cases.
> read_ber, read_signal_strength, read_snr, read_ucblocks and
> get_frontend are not obligatory *required* in any? case.

Besides, IIRC, not all signal information functions were implemented
in the af9005 (I didn't know all the details of the chipset and the
expected scale in the dvb driver).
They're nice to have but not indispensable.

Bye
-- 
Luca
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Theodore Kilgore]

On Sun, 5 Apr 2009, Hans de Goede wrote:


On 04/05/2009 01:26 PM, Erik Andrén wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Hans de Goede wrote:

On 04/04/2009 10:22 PM, Erik Andrén wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

While trying to get hflip and vflip working for the stv06xx webcam
bridge coupled to the vv6410 sensor I've come across the following
problem.

When flipping the image horizontally, vertically or both, the sensor
pixel ordering changes. In the m5602 driver I was able to compensate
for this in the bridge code. In the stv06xx I don't have this
option. One way of solving this problem is by changing the
pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
format. When a vertical flip is required, change the format to
V4L2_SBGGR8.

My current understanding of libv4l is that it probes the pixelformat
upon device open. In order for this to work we would need either
poll the current pixelformat regularly or implement some kind of
notification mechanism upon a flipping request.

What do you think is this the right way to go or is there another
alternative.


The changing of the pixelformat only happens when you flip the data
before conversion. If you look at the current upside down handling
code you will see it does the rotate 180 degrees after conversion.

This is how the vflip / hflip should be handled too. We only have
4 (2 really since we don't care about r versus b / u versus v while
flippiing) destination formats for which we then need to write flipping
code. Otherwise we need to write flipping code for *all* supported input
formats, not to mention flipping some input formats is close to impossible
(JPEG for example).



So you mean we should do the vflip/hflip in software, just exposing
one native format?



Erm, yes that is what I was saying, but that is because I was confusing
things with the sq905 driver some other people are working on.

Now I understand what you were trying to ask. So the problem is that
the vv6410 sensor can do flipping in hardware, and then the order in
which it sends out the pixels changes from gbgbgb (for example)
to bgbgbg, for the lines which have blue, effectively changing the
pixelformat, right?



You mention the sq905 cameras, and the general problem of image flipping. 
You comment that the order of the data changes if any kind of flipping 
is done, with the result that the image format (Bayer tiling) changes. One 
difference I do see here is that "the vv6410 sensor can do flipping in 
hardware" which the sq905 cameras obviously can not. However, the fact 
that the Bayer tiling of the image must change in accordance with the 
flipping is equally present. And I do not see how that problem could be 
avoided, on any occasion when flipping is needed.


This brings up an interesting question of what would be the most efficient 
way actually to do the required image flipping:


If the flipping is done before the finished image is produced, then the 
Bayer tiling of the image has changed. Therefore a different treatment is 
needed.


If the flipping is done after the finished image is produced, then there 
is three times as much data, and the flipping might take longer (or might 
not if it were done exactly right?).


Therefore, how best to do this? As I said, I am thinking about the sq905 
driver. One of its peculiarities, as far as I can tell, is that the 
cameras all use the same Bayer tiling before the flipping. But after the 
flipping it is obviously a different story. The approach that was taken in 
the libgphoto2 driver for the sq905 cameras was to do the flipping first, 
and then to apply the right Bayer tiling afterward for the particular 
camera. Clearly, that could also be done here. However, is that the best 
way to go about it? Perhaps in fact it is simpler to do the flipping of an 
entire finished image, instead. Then one would of course have to move 
triples instead of single bytes, in order to leave the color mapping 
unmolested.


It is interesting that this problem comes up with some other cameras, too.

Theodore Kilgore

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Jean Delvare]

Hi Janne,

On Sun, 5 Apr 2009 16:37:49 +0200, Janne Grunau wrote:
> On Sun, Apr 05, 2009 at 07:46:47AM +0200, Hans Verkuil wrote:
> >
> > Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those 
> > drivers that did not autoload this module. The driver author can refine 
> > things later (I'll definitely will do that for ivtv).
> > 
> > It will be interesting if someone can find out whether lirc will work at 
> > all 
> > once autoprobing is removed from i2c. If it isn't, then perhaps that will 
> > wake them up to the realization that they really need to move to the 
> > kernel.
> 
> I would guess that it won't work. There is an effort to merge lirc. It's
> currently stalled though. A git tree is available at
> 
> git://git.wilsonet.com/linux-2.6-lirc.git

I tried to clone this but it failed:

git.wilsonet.com[0: 72.93.233.4]: errno=Connection timed out
fatal: unable to connect a socket (Connection timed out)

> Jared Wilson and I were working on it (mainly last september). Since the
> IR on the HD PVR is also driven by the same zilog chip as on other
> hauppauge devices I'll take of lirc_zilog. Help converting the i2c
> drivers to the new i2c model is welcome. General cleanup of lirc to make
> it ready for mainline is of course wellcome too.

I will happily help you with the i2c side of things. Without an access
to your git tree however, I don't know the latest state of your code.
And I can't see any lirc_zilog module in the CVS repository of lirc
either. But if you show me the i2c code you're worried about, I'll let
you know what I think about it.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/

[Jean-Francois Moine]

Hi Mauro,

Here is my previous pull request.

Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb/
for:

changeset:   11224:2258bd92f522
gspca - vc032x: Remove the JPEG tables of mi1320_soc.

changeset:   11225:ea6d8f0cd083
gspca - m5602-s5k4aa: No more "default" mode

changeset:   11226:630fa8f75f42
gspca - m5602-s5k4aa: Add start function and VGA resolution init.

changeset:   11227:7b14d00aa61c
gspca - m5602: Simplify error handling

changeset:   11228:89647a4acf75
gspca - m5602-ov9650: Add QCIF resolution support

changeset:   11229:7578294f06cd
gspca - m5602-ov9650: Clean up ov9650_start() function.

changeset:   11230:8863f4fdf25e
gspca - m5602-s5k83a: Add led support to the s5k83a sensor.

changeset:   11231:817e36da4fd9
gspca - m5602-ov9650: Set the ov9650 sensor in soft sleep when inactive.

changeset:   11232:9d0a113a28a4
gspca - m5602-ov9650: Always init the ov9650 before starting a stream

changeset:   11233:871b2546315d
gspca - m5602: Rework v4l ctrl handling in all sensors

changeset:   11234:04c1227d412f
gspca - m5602-ov9650: Checkpatch fixes

changeset:   11235:089b896afa94
gspca - m5602-mt9m111: Separate mode vectors per sensor.

changeset:   11236:531f8383ff70
gspca - m5602-mt9m111: Move v4l2 controls to main sensor file.

changeset:   11237:ea5335dfb00e
gspca - m5602: Remove an unused member in the sd struct.

changeset:   11238:f915d64a686e
gspca - m5602: Constify all sensor structs

changeset:   11239:be006d6783fb
gspca - m5602-ov9650: Autogain is on by default

changeset:   11240:ad9622150aea
gspca - m5602-ov9650: Auto white balancing is on by default

changeset:   11241:82263c1cbdee
gspca - m5602-ov9650: Don't read exposure data from COM1.

changeset:   11242:a640fe97ac35
gspca - m5602: Improve error handling in the ov9650 driver

changeset:   11243:9d70484bfca5
gspca - m5602-ov9650: Synthesize modesetting.

changeset:   11244:dc66997ccf36
gspca - m5602-ov9650: Replace a magic constant with a define

changeset:   11245:ecbaf91c8745
gspca - m5602-ov9650: Add a disconnect hook, setup a ctrl cache ctrl.

changeset:   11246:0310786ebedc
gspca - m5602-ov9650: Use the local ctrl cache. Adjust image on vflip.

changeset:   11247:1bebd29cecc3
gspca - m5602: Move the vflip quirk to probe stage.

changeset:   11248:6b4f4f173a66
gspca - m5602: Don't touch hflip/vflip register on Read/Modify/Write

changeset:   11249:7c1aa8d0507f
gspca - m5602: Minor cleanups

Cheers.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] http://linuxtv.org/hg/~eandren/v4l-dvb/

[Jean-Francois Moine]

On Sun, 5 Apr 2009 07:29:00 -0300
Mauro Carvalho Chehab  wrote:

> On Fri, 03 Apr 2009 20:29:08 +0200
> Erik Andrén  wrote:
> > Please pull http://linuxtv.org/hg/~eandren/v4l-dvb/
> > for more m5602-gspca changeset that are 2.6.30 material.
> 
> I'm preparing the last 2.6.30 material for sending upstream. Could
> you please merge this quickly today?

Hello Mauro,

It seems there is a problem with my messages: on March 27, I sent to you
and to the list a pull request for the first set of Erik's changesets.
The message came back normally to me as if it was sent to all people.
But I cannot see it in the list archives!

I am resending it now.

Then, for 2.6.30, there are still the second set of Erik and 2 or three
changesfrom me. Do I add these changesets to the current unpulled ones
in my stable repository?

Cheers.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Problem with the Hauppauge Nexus CA

[Carl Cedergren]

Hi,

i am trying to get the Hauppauge Nexus CA's analogue tuner to work with 
2.6.26. No matter what i do all i get is the DVB as tuner. I got some 
help on #linuxtv that indicated that the saa7146 driver lacks support 
for the analogue tuner, and has lacked it for some time. Is this by 
design? Should i get a new card, or is this fixable in any way?


/Carl
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Remove support for Genpix-CW3K (damages hardware)

[Alan Nisota]

Mauro Carvalho Chehab wrote:

We shouldn't drop support for a device just because the manufacturer doesn't
want it to be supported. If it really damages the hardware or violates the
warranty, then we can print a warning message clearly stating that the vendor
refuses to collaborate, briefly explaining the issues and recommending the user
to replace the device to some other from a vendor-friendly at dmesg, but keep
allowing they to use it, with some force option for people that wants to take
the risk.
  
I'm not going to go through the entire soap-opera as I know it, but 
basically the manufacturer has 2 tiers of devices, those that were 
designed to work only with a specific piece of hardware, and those that 
are supported in Windows and Linux, but come with a significant price 
premium.  The latter devices are supported by the kernel and should be 
continued to be.  The former is what we're talking about and what my 
patch removes support for.  The patch was in response to real users with 
real problems.


I am in no way associated with the manufacturer other than that he 
provided me with initial help writing the Linux drivers several years 
ago.  I no longer have a use for the drivers myself, and any support I 
do is just to help the community out.  I have provided a patch which 
makes the driver safe to use.  If you prefer an alternate method of 
achieving the same goal, or wish to just ignore it altogether, that is 
ok, but I don't have the time to develop and test a patch that is more 
complicated then what I've already posted.  If you are going to take any 
action, I would prefer it get pushed into the current kernel development 
tree to minimize the potential harm to users.



--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PULL] http://www.linuxtv.org/hg/~dougsland/v4l-dvb

[Douglas Schilling Landgraf]

Hello Mauro,

   This is a new request pull to rewrite_eeprom tool. I have added
validations, warning messages and a backup feature.
Since I don't have any em2874/em2884 device I am not able to implement
any addicional validation but it seems already safe enough. for these
devices too.

- v4l2-apps/util: Add rewrite_eeprom tool

Thanks,
Douglas
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Remove support for Genpix-CW3K (damages hardware)

[Mauro Carvalho Chehab]

Hi Alan,

On Wed, 01 Apr 2009 13:01:25 -0700
Alan Nisota  wrote:

> Patrick Boettcher wrote:
> > Hi Alan,
> >
> > Don't you think it is enough to put a Kconfig option to activate the 
> > USB-IDs (by default: off) rather than throwing everything away?
> >
> We could, but honestly, there are likely few people using this device 
> who don't have to patch their kernel anyway, and it is a trivial patch 
> to apply.  There have been 4 incarnations of the CW3K as the 
> manufacturer has tried to actively make it not work in Linux (and users 
> have found ways around that for each subsequent revision).  When I 
> created the patch, I was not aware that the developer would take this 
> stance.  Only the 1st batch of devices works with the existing code, and 
> I'm not aware of any way to detect the device version. 
> 
> Given the manufacturer's stance and the potential to unknowingly damage 
> the device (I've been informed that the manufacturer has stated that use 
> of the Linux drivers with the CW3K will void any manufacturer's 
> warranty), I would rather remove support for this piece of hardware 
> outright.  I believe the manufacturer still supports the 8PSK->USB and 
> Skywalker1 versions of the hardware on Linux (plus a new Skywalker2 
> which requires a kernel patch to enable).

We shouldn't drop support for a device just because the manufacturer doesn't
want it to be supported. If it really damages the hardware or violates the
warranty, then we can print a warning message clearly stating that the vendor
refuses to collaborate, briefly explaining the issues and recommending the user
to replace the device to some other from a vendor-friendly at dmesg, but keep
allowing they to use it, with some force option for people that wants to take
the risk.

This is just my 2 cents.

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model

[Jean Delvare]

Hi Mauro,

On Sun, 5 Apr 2009 07:01:16 -0300, Mauro Carvalho Chehab wrote:
> From the discussions we already have, I noticed some points to take care of:
> 
> 1) about the lirc support, I don't think we should change a kernel driver due
> to an out-of-tree kernel driver. As I've commented on PATCH 3/6 discussion, we
> need to better address this with lirc developers;

Well, the new binding model makes it harder for "rogue" drivers such as
lirc_i2c. They will need _some_ form of cooperation from us, which will
most likely come when they get merged into the kernel tree.

> 2) the way Mike is proposing to solve the issue with pvrusb2 will break
> userspace usage for people that have those devices whose IR work with the
> in-kernel IR i2c driver. This means that we'll cause a kernel regression due 
> to
> an out-of-tree driver;
> 
> 3) So far, nobody gave us any positive return that the new IR model is 
> working with
> any of the touched drivers. So, more tests are needed. I'm expecting to have a
> positive reply for each of the touched drivers. People, please test!

Yes, please! :)

> Since the merge window is almost finished, IMO, we should postpone those
> changes to 2.6.31, (...)

The legacy i2c model will be gone in 2.6.30. Really. Hans and myself
have put enough energy into this to not let it slip for just a
miserable infrared support module which I understand is hardly used by
anyone.

So it's really up to you, either you accept my ir-kbd-i2c conversion
"now" (that is, when it has received the minimum testing and reviewing
it deserves) and ir-kbd-i2c has a chance to work in 2.6.30, or you
don't and I'll just have to mark ir-kbd-i2c as BROKEN to prevent build
failures.

> to better address the lirc issue and to give people more
> time for testing, applying the changesets after the end of the merge window at
> the v4l/dvb development tree. This will help people to test, review and 
> propose
> changes if needed.

These changes are on-going for over a year now. If the lirc people
didn't hear about it so far, I doubt they will pay more attention just
because we delay the deadline by 2 months. The only thing that will get
their attention is when lirc_i2c break. So let's just do that ;)

Don't get me wrong. I don't want to be (too) rude to lirc developers.
If they need help to port their code to the new i2c binding model, I'll
help them. If they need help to merge lirc_i2c into the kernel, I'll
help as well. But I don't see any point in delaying important, long
awaited kernel changes just for them. As long as they are out-of-tree,
they can fix things after the fact easily. They aren't affected by the
merge window. They'll have several weeks before kernel 2.6.30 is
actually released, which they can use to fix anything that broke.

Thanks,
-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Janne Grunau]

On Sun, Apr 05, 2009 at 07:46:47AM +0200, Hans Verkuil wrote:
>
> Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those 
> drivers that did not autoload this module. The driver author can refine 
> things later (I'll definitely will do that for ivtv).
> 
> It will be interesting if someone can find out whether lirc will work at all 
> once autoprobing is removed from i2c. If it isn't, then perhaps that will 
> wake them up to the realization that they really need to move to the 
> kernel.

I would guess that it won't work. There is an effort to merge lirc. It's
currently stalled though. A git tree is available at

git://git.wilsonet.com/linux-2.6-lirc.git

Jared Wilson and I were working on it (mainly last september). Since the
IR on the HD PVR is also driven by the same zilog chip as on other
hauppauge devices I'll take of lirc_zilog. Help converting the i2c
drivers to the new i2c model is welcome. General cleanup of lirc to make
it ready for mainline is of course wellcome too.

Janne
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [0904_16] Siano: smsdvb - additional case of endian handling.

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238758726 -10800
# Node ID c582116cfbb96671629143fced33e3f88c28b3c7
# Parent  856813745905e07d9fc6be5e136fdf7060c6fc37
[PATCH] [0904_16] Siano: smsdvb - additional case of endian handling.

From: Uri Shkolnik 

Additional case of endian handling.

Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r 856813745905 -r c582116cfbb9 linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 14:30:50 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 14:38:46 2009 +0300
@@ -273,7 +273,7 @@ static int smsdvb_start_feed(struct dvb_
PidMsg.xMsgHeader.msgLength = sizeof(PidMsg);
PidMsg.msgData[0] = feed->pid;
 
-   /* smsendian_handle_tx_message((struct SmsMsgHdr_ST *)&PidMsg); */
+   smsendian_handle_tx_message((struct SmsMsgHdr_ST *)&PidMsg);
return smsclient_sendrequest(client->smsclient, &PidMsg,
sizeof(PidMsg));
 }
@@ -546,10 +546,15 @@ static int smsdvb_hotplug(struct smscore
}
 



  
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Siano's patches

[Uri Shkolnik]

 Hi Mauro,
 
 
 Please note patches (1..19) series @ 
http://patchwork.kernel.org/project/linux-media/list/?submitter=uri
 
 I'll wait for reviews and commit for this series before submitting additional 
patches.
 
 
Pierre - the SDIO binding (registering) is still to be submitted, it isn't 
included within patches 1..19. 
 
 
 
Regards,
 
Uri
 


  
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Jean Delvare]

Hi Mike,

Selected answers, as most points have already been discussed elsewhere
meanwhile...

On Sat, 4 Apr 2009 18:29:35 -0500 (CDT), Mike Isely wrote:
> On Sun, 5 Apr 2009, Jean Delvare wrote:
> > This is excellent news. As I said in the header comment of the patch,
> > avoiding probing when we know what the IR receiver is and at which
> > address it sits is the way to go. Please send me all the information
> > you have and I'll be happy to add a patch to the series, that skips
> > probing whenever possible. Or write that patch yourself if you prefer.
> 
> I have samples of most of the devices in question and can code proper 
> I2C addresses for each of those for each resident I2C client.  The 
> pvrusb2 driver's device attribute structure already has allowance for 
> specification of the correct I2C addresses to use for chips specific to 
> each device (part of the v4l2-subdev rework I recently did).  Right now 
> the driver has built in defaults, and if a particular model needs 
> something else, it can be overridden as part of the device's profile in 
> pvrusb2-devattr.c.

Good. Declaring the right IR receiver device based on board information
is clearly the way to go.

> > I didn't make any assumption, sorry. I simply copied the code from
> > ir-kbd-i2c. If my code does the wrong thing for some devices, that was
> > already the case before. And this will certainly be easier to fix after
> > my changes than before.
> 
> No, I think the point you are missing is that by moving that logic from 
> ir-kbd-i2c into each driver (e.g. pvrusb2) you are moving logic that 
> *might* be executed into a spot where it *will* be executed.

Yes, you are right.

> Remember 
> that the pvrusb2 driver did not autoload ir-kbd-i2c before this patch.  
> Before this change, a user could elect not to use ir-i2c-kbd simply by 
> not loading it.

Which was pretty fragile because another bridge driver could still have
loaded it.

> The pvrusb2 driver didn't request it, because the 
> intent all along there is that the user makes the choice by loading the 
> desired driver.

Which simply underlines how weird the current situation is... Forcing
the choice on the user is pretty bad from a usability perspective.

>  Now with this change, the pvrusb2 driver is going to 
> attempt to load ir-kbd-i2c where asked for or not.

Not exactly, only the device will be the instantiated, the drivers
won't be loaded, but the result is indeed the same: it's getting in
lirc_i2c's way if that's what the user wants to use.

>  And if not, the 
> resulting binding will prevent lirc_i2c from later on loading.  If the 
> user had been loading lirc_i2c previously, this will cause his/her usage 
> of IR to break.  No, it's not perfect, but it worked.  I'm all for 
> improving things, but not by removing an ability that people are using.

I have just added a disable_ir module parameter to work around this
issue. Set it to 1 and no "ir-kbd" device will be instantiated, letting
lirc_i2c do whatever it wants with the IR receiver device.

You might argue that this is still a regression because the user now
has to pass an extra parameter to get the same result as before, but
OTOH lirc_i2c will need changes pretty soon anyway, its behavior will
have to be changed and the users will notice. There's no way we can go
from the current weird situation to a sane situation without changing
the (unfortunate) user habits.

> (...)
> I really don't want to throw rocks here; it's always better to work out 
> the solution than simply block any changes at all.  I realize that 
> something has to be done here in order to keep ir-kbd-i2c viable as a 
> choice for users of the pvrusb2 driver.  To that end, how about this 
> strategy:
> 
> 1. Just drop the part of the patch for the pvrusb2 driver and get the 
> rest merged.  Yes, I realize that this will break use of ir-kbd-i2c in 
> cooperation with the pvrusb2 driver.

As Mauro already said: not acceptable. Breaking an in-tree driver
(ir-kbd-i2c) is worse than breaking an out-of-tree driver (lirc_i2c)
regardless of the respective number of users or usefulness of these
drivers.

> 2. Once ir-kbd-i2c has been updated, I will push another set of changes 
> into the pvrusb2 driver that will make it usable there.  Basically what 
> I have in mind is similar to what you tried but I'm going to integrate 
> it with the device profiles so that it can be appropriately loaded based 
> on device model, with the correct I2C address in each case.  And most 
> importantly, I will add a module option to enable/disable loading or 
> ir-kbd-i2c.  This will fix my main objection, since then it will still 
> allow lirc to be usable, for now...

This sounds like a good idea.

> 3. I'd like to fix the "abuse" you mention regarding I2C_HW_B_BT848.  
> I'm unclear on what the cleanest solution is there, but if you like to 
> (a) point at some documentation, (b) describe what I should do, or (c) 
> suggest a patch, I will work to deal with the pro

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Hans de Goede]

On 04/05/2009 02:58 PM, Erik Andrén wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Hans de Goede wrote:

On 04/05/2009 01:26 PM, Erik Andrén wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Hans de Goede wrote:

On 04/04/2009 10:22 PM, Erik Andrén wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

While trying to get hflip and vflip working for the stv06xx webcam
bridge coupled to the vv6410 sensor I've come across the following
problem.

When flipping the image horizontally, vertically or both, the sensor
pixel ordering changes. In the m5602 driver I was able to compensate
for this in the bridge code. In the stv06xx I don't have this
option. One way of solving this problem is by changing the
pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
format. When a vertical flip is required, change the format to
V4L2_SBGGR8.

My current understanding of libv4l is that it probes the pixelformat
 upon device open. In order for this to work we would need either
poll the current pixelformat regularly or implement some kind of
notification mechanism upon a flipping request.

What do you think is this the right way to go or is there another
alternative.


The changing of the pixelformat only happens when you flip the data
before conversion. If you look at the current upside down handling
code you will see it does the rotate 180 degrees after conversion.

This is how the vflip / hflip should be handled too. We only have
4 (2 really since we don't care about r versus b / u versus v while
flippiing) destination formats for which we then need to write flipping
code. Otherwise we need to write flipping code for *all* supported input
formats, not to mention flipping some input formats is close to
impossible
(JPEG for example).


So you mean we should do the vflip/hflip in software, just exposing
one native format?


Erm, yes that is what I was saying, but that is because I was confusing
things with the sq905 driver some other people are working on.



Glad that you were confused as I couldn't really make out the
meaning of your answer. :)


Now I understand what you were trying to ask. So the problem is that
the vv6410 sensor can do flipping in hardware, and then the order in
which it sends out the pixels changes from gbgbgb (for example)
to bgbgbg, for the lines which have blue, effectively changing the
pixelformat, right?


Correct.


In that case I think the only solution is to simply return -EBUSY when
the vflip / hflip controls are changed while a stream is active.



So this effectively forces a reprobe of the hardware?



No, it just disallows changing the flipping (and thus the format) while
an app is actively streaming. so one can use something like v4l2ucp, and
change the flipping while the cam is not being used otherwise, but
if for example skype or cheese or whatever is streaming data from the cam
then the flip will be disallowed (and a device busy error will be returned).

This may not seem very user friendly but normally one does not want to
mess with the flip controls anyways unless the cam is mounted upside down
or something like that.


As for the race window with one application querying the format (or even
setting it) and then another app changing the flip before the application
which just set the format starts the stream, we already have that wrt 2
applications doing this:
app a: setformat x
app b: setformat y
app a: start stream (thinking format is x)

Which is something which normally (luckily) never happens.



If this ever becomes a real issue, shouldn't some kind of user-space
master program aquire the device and then handle format requests for
all client programs?



Yes, one of these days we need to think (very hard) about a much better
way for sharing v4l devices.


Does that sound like a plan ?



Yes, I'll try this ASAP.


Note that this is a solution at the driver level, which IMHO is the only
way as we cannot assume libv4l is always being used.



If it works this sounds like the most clean and elegant solution.
The weak point being that the application must try to renegotiate
the format upon the -EBUSY signal.



No, the idea is that the flipping will simply not change (hence the
error, signaling the setting of the flip control failed).

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [0904_4] Siano: core header indentation

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238692069 -10800
# Node ID 83b19eba46dd4f8253d02c26db4f42728d60e28f
# Parent  19925582e5dded86fccce7d8c9965285c1240836
siano: core header identation
[PATCH] [0904_4] Siano: core header indentation

From: Uri Shkolnik 

smscoreapi.h - indentation and removing lots of white spaces
There are no implementation changes in this patch.

Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r 19925582e5dd -r 83b19eba46dd linux/drivers/media/dvb/siano/smscoreapi.h
--- a/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 19:56:01 
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 20:07:49 
2009 +0300
@@ -103,31 +103,31 @@ struct smscore_buffer_t {
 };
 
 struct smsdevice_params_t {
-   struct device   *device;
+   struct device *device;
 
-   int buffer_size;
-   int num_buffers;
+   int buffer_size;
+   int num_buffers;
 
-   chardevpath[32];
-   unsigned long   flags;
+   char devpath[32];
+   unsigned long flags;
 
-   setmode_t   setmode_handler;
-   detectmode_tdetectmode_handler;
-   sendrequest_t   sendrequest_handler;
-   preload_t   preload_handler;
-   postload_t  postload_handler;
+   setmode_t setmode_handler;
+   detectmode_t detectmode_handler;
+   sendrequest_t sendrequest_handler;
+   preload_t preload_handler;
+   postload_t postload_handler;
 
-   void*context;
+   void *context;
enum sms_device_type_st device_type;
 };
 
 struct smsclient_params_t {
-   int initial_id;
-   int data_type;
-   onresponse_tonresponse_handler;
-   onremove_t  onremove_handler;
+   int initial_id;
+   int data_type;
+   onresponse_t onresponse_handler;
+   onremove_t onremove_handler;
 
-   void*context;
+   void *context;
 };
 
 struct smscore_device_t {
@@ -185,26 +185,26 @@ struct smscore_device_t {
 };
 
 /* GPIO definitions for antenna frequency domain control (SMS8021) */
-#define SMS_ANTENNA_GPIO_0 1
-#define SMS_ANTENNA_GPIO_1 0
+#define SMS_ANTENNA_GPIO_0 1
+#define SMS_ANTENNA_GPIO_1 0
 
-#define BW_8_MHZ   0
-#define BW_7_MHZ   1
-#define BW_6_MHZ   2
-#define BW_5_MHZ   3
-#define BW_ISDBT_1SEG  4
-#define BW_ISDBT_3SEG  5
+#define BW_8_MHZ   0
+#define BW_7_MHZ   1
+#define BW_6_MHZ   2
+#define BW_5_MHZ   3
+#define BW_ISDBT_1SEG  4
+#define BW_ISDBT_3SEG  5
 
 #define MSG_HDR_FLAG_SPLIT_MSG 4
 
-#define MAX_GPIO_PIN_NUMBER31
+#define MAX_GPIO_PIN_NUMBER31
 
-#define HIF_TASK   11
-#define SMS_HOST_LIB   150
+#define HIF_TASK   11
+#define SMS_HOST_LIB   150
 #define DVBT_BDA_CONTROL_MSG_ID201
 
 #define SMS_MAX_PAYLOAD_SIZE   240
-#define SMS_TUNE_TIMEOUT   500
+#define SMS_TUNE_TIMEOUT   500
 
 #define MSG_SMS_GPIO_CONFIG_REQ507
 #define MSG_SMS_GPIO_CONFIG_RES508
@@ -212,45 +212,45 @@ struct smscore_device_t {
 #define MSG_SMS_GPIO_SET_LEVEL_RES 510
 #define MSG_SMS_GPIO_GET_LEVEL_REQ 511
 #define MSG_SMS_GPIO_GET_LEVEL_RES 512
-#define MSG_SMS_RF_TUNE_REQ561
-#define MSG_SMS_RF_TUNE_RES562
+#define MSG_SMS_RF_TUNE_REQ561
+#define MSG_SMS_RF_TUNE_RES562
 #define MSG_SMS_INIT_DEVICE_REQ578
 #define MSG_SMS_INIT_DEVICE_RES579
 #define MSG_SMS_ADD_PID_FILTER_REQ 601
 #define MSG_SMS_ADD_PID_FILTER_RES 602
-#define MSG_SMS_REMOVE_PID_FILTER_REQ  603
-#define MSG_SMS_REMOVE_PID_FILTER_RES  604
-#define MSG_SMS_DAB_CHANNEL

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Jean Delvare]

Hi Hans,

On Sun, 5 Apr 2009 07:46:47 +0200, Hans Verkuil wrote:
> Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those 
> drivers that did not autoload this module. The driver author can refine 
> things later (I'll definitely will do that for ivtv).

I'd rather name the parameter "disable_ir", to make it consistent with
what other bridge drivers already use, and also because what the
parameter really does is preventing I2C devices from being
instantiated, _not_ preventing the ir-kbd-i2c module from loading.

I have a patch doing that already, it's pretty simple, I'll post it in
a minute.

> It will be interesting if someone can find out whether lirc will work at all 
> once autoprobing is removed from i2c. If it isn't, then perhaps that will 
> wake them up to the realization that they really need to move to the 
> kernel.

lirc_i2c will break, it still uses the legacy binding model. That's
what you get for living outside the kernel tree... Upgrading it
shouldn't be too hard, given that the difficult part is to update the
bridge drivers and I've already taken care of this part (although
lirc_i2c might need to probe more addresses than ir-kbd-i2c does).

> The new mechanism is the right way to do it: the adapter driver has all the 
> information if, where and what IR is used and so should be the one to tell 
> the kernel what to do. Attempting to autodetect and magically figure out 
> what IR might be there is awkward and probably impossible to get right 
> 100%.

I wholeheartedly agree.

> Hell, it's wrong already: if you have another board that already loads 
> ir-kbd-i2c then if you load ivtv or pvrusb2 afterwards you get ir-kbd-i2c 
> whether you like it or not, because ir-kbd-i2c will connect to your i2c 
> adapter like a leech. So with the addition of a module option you at least 
> give back control of this to the user.

Totally correct. The current mess^Wmodel vaguely works when a single TV
card is present, but mixing different TV cards in the same system would
certainly break. Admittedly this is probably not a very common case, I
guess the vast majority of users have a single TV card.

> When this initial conversion is done I'm pretty sure we can improve 
> ir-kbd-i2c to make it easier to let the adapter driver tell it what to do. 
> So we don't need those horrible adapter ID tests and other magic that's 
> going on in that driver. But that's phase two.

Please note that my conversion _already_ no longer makes any use of
adapter IDs. What it still does is probing, except for a few selected
cards (AVerMedia Cardbus and MSI t...@nywhere Plus). The idea is clearly
to turn probing into a fallback and use per-card data for IR device
instantiation the first choice for as many cards as possible in the
future.

Updated patch set is available at:
http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/

Changes since previous version:
* Dropped cx18 changes on request by Andy Walls.
* Added disable_ir module parameter to all bridge drivers which didn't
  have it.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Jean Delvare]

Hi Andy,

On Sat, 04 Apr 2009 21:50:08 -0400, Andy Walls wrote:
> On Sun, 2009-04-05 at 00:51 +0200, Jean Delvare wrote:
> > On Sat, 04 Apr 2009 09:42:09 -0400, Andy Walls wrote:
> > > I think this is way out of date for cx18 based boards.  The only IR chip
> > > I know of so far is the Zilog Z8F0811 sitting at 7 bit addresses
> > > 0x70-0x74.  I guess 0x71 is the proper address for Rx.  I'll let you
> > > know when I test.
> > 
> > This address list comes from the ir-kbd-i2c driver. The cx18 driver
> > happens to use the same I2C adapter ID as the ivtv driver
> > (I2C_HW_B_CX2341X) and this is what the ir-kbd-i2c driver used to
> > decide which addresses to probe. As I don't know anything about the
> > hardware, I had to keep the new code compatible with the old one and
> > keep probing the same addresses.
> 
> This is the i2cdetect output from my HVR-1600 - the only cx18 based card
> known or reported to have an IR chip:
> 
> [r...@morgan ~]# i2cdetect -l
> i2c-0 smbus   SMBus PIIX4 adapter at 0b00 SMBus adapter
> i2c-1 i2c ivtv i2c driver #0  I2C adapter
> i2c-2 i2c cx18 i2c driver #0-0I2C adapter
> i2c-3 i2c cx18 i2c driver #0-1I2C adapter
> [r...@morgan ~]# i2cdetect 2
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-2.
> I will probe address range 0x03-0x77.
> Continue? [Y/n] y
>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:  -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 10: -- -- -- -- -- -- -- -- -- 19 -- -- -- -- -- -- 
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 40: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- 
> 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 60: -- -- -- 63 -- -- -- -- -- -- -- -- -- -- -- -- 
> 70: 70 71 72 73 -- -- -- -- 
> [r...@morgan ~]# i2cdetect 3
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-3.
> I will probe address range 0x03-0x77.
> Continue? [Y/n] y
>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:  -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 60: -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 70: -- -- -- -- -- -- -- -- 
> 
> The Zilog is at 0x70-0x73.  The standard IR Tx and RX addresses are 0x70
> and 0x71
> 
> 
> > Now, if you tell me that this list doesn't make sense for cx18 boards,
> > we can change it.
> 
> I owe you the right address to probe.  I think it is 0x71, but I want to
> double check.

Well, it doesn't really matter to me at this point. All I care about is
that ir-kbd-i2c didn't support cx18 adapters before, so my patch can
just ignore them. Support can be added later. More interestingly, if
only one board needs to be supported for now and you have all the
information about the IR receiver, then we simply don't need
auto-detection of IR devices on cx18 at all. We can directly take the
clean route of device declaration. As far as I know the cx18 does that
very well for all other chips (tuner, decoder etc.) much like the ivtv
driver does, so adding support for IR should be easy.

> >  As addresses 0x70-0x74 were not probed so far on cx18
> > boards, I guess that IR support never worked for cx18 (at least not with
> > ir-kbd-i2c)?
> 
> No, the lirc_i2c, lirc_pvr150, and lirc_zilog come in via the i2c
> subsystem.
> 
> >  Does ir-kbd-i2c support the Zilog Z8F0811 at all?
> > 
> > If IR on the cx18 is not supported (by the ir-kbd-i2c driver) then I
> > can simplify my patch set and omit the cx18 entirely.

Which I just did...

> The HVR-1600 could have been supported by ir-kbd-i2c.
> 
> It's submission was redirected slightly here:
> 
> http://lkml.org/lkml/2009/2/3/118
> 
> And deferred here:
> 
> http://www.spinics.net/lists/linux-media/msg03883.html
> 
> until your changes were done.

OK. Then let's indeed get my changes merged first, and then we can see
the best way to add support for the HVR-1600 IR.

> > > I have an I2C related question.  If the cx18 or ivtv driver autoloads
> > > "ir-kbd-i2c" and registers an I2C client on the bus, does that preclude
> > > lirc_i2c, lirc_pvr150 or lirc_zilog from using the device?  LIRC users
> > > may notice, if it does.
> > 
> > I don't know anything about lirc_i2c, lirc_pvr150 or lirc_zilog. I tend
> > to ignore all the code that is neither in the Linux kernel tree nor in
> > the v4l-dvb tree.
> 
> lirc_pvr150 has always been out of kernel and likely always will be.

Any valid reason? Out-of-free drivers are a pain for users :(

> lirc_i2c and lirc_zilog

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Erik Andrén]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Hans de Goede wrote:
> On 04/05/2009 01:26 PM, Erik Andrén wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>
>>
>> Hans de Goede wrote:
>>> On 04/04/2009 10:22 PM, Erik Andrén wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi,

 While trying to get hflip and vflip working for the stv06xx webcam
 bridge coupled to the vv6410 sensor I've come across the following
 problem.

 When flipping the image horizontally, vertically or both, the sensor
 pixel ordering changes. In the m5602 driver I was able to compensate
 for this in the bridge code. In the stv06xx I don't have this
 option. One way of solving this problem is by changing the
 pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
 format. When a vertical flip is required, change the format to
 V4L2_SBGGR8.

 My current understanding of libv4l is that it probes the pixelformat
 upon device open. In order for this to work we would need either
 poll the current pixelformat regularly or implement some kind of
 notification mechanism upon a flipping request.

 What do you think is this the right way to go or is there another
 alternative.

>>> The changing of the pixelformat only happens when you flip the data
>>> before conversion. If you look at the current upside down handling
>>> code you will see it does the rotate 180 degrees after conversion.
>>>
>>> This is how the vflip / hflip should be handled too. We only have
>>> 4 (2 really since we don't care about r versus b / u versus v while
>>> flippiing) destination formats for which we then need to write flipping
>>> code. Otherwise we need to write flipping code for *all* supported input
>>> formats, not to mention flipping some input formats is close to
>>> impossible
>>> (JPEG for example).
>>>
>>
>> So you mean we should do the vflip/hflip in software, just exposing
>> one native format?
>>
> 
> Erm, yes that is what I was saying, but that is because I was confusing
> things with the sq905 driver some other people are working on.
> 

Glad that you were confused as I couldn't really make out the
meaning of your answer. :)

> Now I understand what you were trying to ask. So the problem is that
> the vv6410 sensor can do flipping in hardware, and then the order in
> which it sends out the pixels changes from gbgbgb (for example)
> to bgbgbg, for the lines which have blue, effectively changing the
> pixelformat, right?

Correct.

> 
> In that case I think the only solution is to simply return -EBUSY when
> the vflip / hflip controls are changed while a stream is active.
> 

So this effectively forces a reprobe of the hardware?

> As for the race window with one application querying the format (or even
> setting it) and then another app changing the flip before the application
> which just set the format starts the stream, we already have that wrt 2
> applications doing this:
> app a: setformat x
> app b: setformat y
> app a: start stream (thinking format is x)
> 
> Which is something which normally (luckily) never happens.
> 

If this ever becomes a real issue, shouldn't some kind of user-space
master program aquire the device and then handle format requests for
all client programs?

> Does that sound like a plan ?
> 

Yes, I'll try this ASAP.

> Note that this is a solution at the driver level, which IMHO is the only
> way as we cannot assume libv4l is always being used.
> 

If it works this sounds like the most clean and elegant solution.
The weak point being that the application must try to renegotiate
the format upon the -EBUSY signal.

Thanks for the help!

Regards,
Erik


> Regards,
> 
> Hans
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknYqtwACgkQN7qBt+4UG0FBgACggwgmVfMKj2bQAj/UVSL/vHSH
Ss0Anj/8xoRpXiIzBg3HdtDa0SXK6WK2
=yIxz
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Andy Walls]

On Sun, 2009-04-05 at 06:14 -0300, Mauro Carvalho Chehab wrote:

> 
> IMO, doing all those tricks to support an out-of-tree driver is the wrong
> approach. This is just postponing a more serious discussion about what should
> be done in kernel, in order to better support IR's.

The "tricks" were to not break the current user experience by saddling
them with a kernel module that they may not want.  (If the tricks are
needed at all - I'm will test later today.)

I agree that better in kernel infrastructure needs to be in place for
IR.

LIRC's kernel space infrastructure module, lirc_dev, probably isn't a
bad model for support of IR devices.  The individual LIRC modules for
supporting specific sets of devices are the ones that have problems to
varying degrees.


> In the case of lirc, the userspace part has already an event interface. If the
> drivers are doing the right thing with their IR part, lirc can just use the
> event interface for all drivers. This seems to be the proper approach.

Input event interfaces alone neglect IR blasters.


> >From what I got from Andy and Mike's comments is that the real issue is that
> the IR kernel code is incomplete, broken or bad designed. So, several users 
> and
> userspace apps don't rely on the kernel code but, instead, use lirc as an
> alternative.

There is at least one other motivation:

LIRC also handles a number of other hardware interfaces that are not
I2C: serial ports (/dev/ttySX), parallel port, USB, etc.


I happen to use the lirc_mceusb2 module for my Phillips Home IR
receiver/blaster (I'm not sure if the blaster works under linux.)


> That's said, I propose a different approach:
> 
> 1) Add some entry at feature-removal-schedule.txt posting a date to end 
> support
>for out-of-tree I2C IR modules;
> 
> 2) Start discussing with lirc people (and input/event maintainers if needed)
> about what is needed to properly support the required functionalities for a
> better lirc usage;
> 
> 3) Propose a few API additions in order to support those functionalities;

> 4) apply IR patches on kernel to support the missing functionalities;

The scope of a complete kernel IR infrastructure goes a bit beyond I2C
bus devices that are only input devices.

What's the scope of what you want to tackle here?

I certainly don't want to reinvent something that's going to look just
like the LIRC driver model:

http://www.lirc.org/html/technical.html

Which already has an infrastructure for IR driver module writers:
http://www.lirc.org/html/technical.html#lirc_dev


Do we just convert lirc_dev, lirc_i2c, and lirc_zilog to a cleaned up
set of in kernel modules?  lirc_i2c can certainly be broken up into
several modules: 1 per supported device.  Should these create an input
device as well to maintain compatability with apps expecting an
ir-kbd-i2c like function?

Or do we split up ir-kbd-i2c into per device modules and in addition to
the input event interface, have it register with the lirc_dev module?

Do we leverage LIRC's lirc_dev infrastructure module at all? (I think it
would be a waste of time not to do so.) 

Regards,
Andy

> 5) remove the support for out-of-tree i2c IR modules.


> 
> Cheers,
> Mauro
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Hans de Goede]

On 04/05/2009 01:26 PM, Erik Andrén wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Hans de Goede wrote:

On 04/04/2009 10:22 PM, Erik Andrén wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

While trying to get hflip and vflip working for the stv06xx webcam
bridge coupled to the vv6410 sensor I've come across the following
problem.

When flipping the image horizontally, vertically or both, the sensor
pixel ordering changes. In the m5602 driver I was able to compensate
for this in the bridge code. In the stv06xx I don't have this
option. One way of solving this problem is by changing the
pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
format. When a vertical flip is required, change the format to
V4L2_SBGGR8.

My current understanding of libv4l is that it probes the pixelformat
upon device open. In order for this to work we would need either
poll the current pixelformat regularly or implement some kind of
notification mechanism upon a flipping request.

What do you think is this the right way to go or is there another
alternative.


The changing of the pixelformat only happens when you flip the data
before conversion. If you look at the current upside down handling
code you will see it does the rotate 180 degrees after conversion.

This is how the vflip / hflip should be handled too. We only have
4 (2 really since we don't care about r versus b / u versus v while
flippiing) destination formats for which we then need to write flipping
code. Otherwise we need to write flipping code for *all* supported input
formats, not to mention flipping some input formats is close to impossible
(JPEG for example).



So you mean we should do the vflip/hflip in software, just exposing
one native format?



Erm, yes that is what I was saying, but that is because I was confusing
things with the sq905 driver some other people are working on.

Now I understand what you were trying to ask. So the problem is that
the vv6410 sensor can do flipping in hardware, and then the order in
which it sends out the pixels changes from gbgbgb (for example)
to bgbgbg, for the lines which have blue, effectively changing the
pixelformat, right?

In that case I think the only solution is to simply return -EBUSY when
the vflip / hflip controls are changed while a stream is active.

As for the race window with one application querying the format (or even
setting it) and then another app changing the flip before the application
which just set the format starts the stream, we already have that wrt 2
applications doing this:
app a: setformat x
app b: setformat y
app a: start stream (thinking format is x)

Which is something which normally (luckily) never happens.

Does that sound like a plan ?

Note that this is a solution at the driver level, which IMHO is the only
way as we cannot assume libv4l is always being used.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/4] Add support to libv4l to use orientation from VIDIOC_ENUMINPUT

[Mauro Carvalho Chehab]

On Mon, 30 Mar 2009 10:30:22 +0200
Hans de Goede  wrote:

> On 03/30/2009 12:28 AM, Adam Baker wrote:
> > Add check to libv4l of the sensor orientation as reported by
> > VIDIOC_ENUMINPUT
> >
> > Signed-off-by: Adam Baker
> >
> 
> Looks good, thanks. I'll apply this to my libv4l tree, as soon
> as its certain that the matching kernel changes will go in to
> the kernel without any API changes.

kernel patches merged. As per your request, I'm letting the libv4l one for you 
to take care.


Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [0904_19] Siano: sms-cards - update cards (targets) component header

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238760946 -10800
# Node ID 8377a5e61286b90e293e287cefc9638d2ddd938e
# Parent  ab731e3cec5cb076b8f87f827c3c97a4dd84e0ca
[PATCH] [0904_19] Siano: sms-cards - update cards (targets) component header

From: Uri Shkolnik 

sms-cards component holds all target-specific information.
The component' header has been added with:
1) Include the infra-red header
2) More target types (definitions)
3) Structure for various GPIO usage
4) Extend "sms_board" struct to include
a) GPIO structure
b) IR structure
5) Some 'extern' declartion (for future commits usage)
6) "Board Events" structure
7) "board event" function prototype.

All modifications are in the declaration level only.

Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r ab731e3cec5c -r 8377a5e61286 linux/drivers/media/dvb/siano/sms-cards.h
--- a/linux/drivers/media/dvb/siano/sms-cards.h Fri Apr 03 15:00:32 2009 +0300
+++ b/linux/drivers/media/dvb/siano/sms-cards.h Fri Apr 03 15:15:46 2009 +0300
@@ -22,6 +22,7 @@
 
 #include 
 #include "smscoreapi.h"
+#include "smsir.h"
 
 #define SMS_BOARD_UNKNOWN 0
 #define SMS1XXX_BOARD_SIANO_STELLAR 1
@@ -34,6 +35,41 @@
 #define SMS1XXX_BOARD_HAUPPAUGE_WINDHAM 8
 #define SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD 9
 #define SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD_R2 10
+#define SMS1XXX_BOARD_SIANO_NICE   11
+#define SMS1XXX_BOARD_SIANO_VENICE 12
+
+struct sms_board_gpio_cfg {
+   int lna_vhf_exist;
+   int lna_vhf_ctrl;
+   int lna_uhf_exist;
+   int lna_uhf_ctrl;
+   int lna_uhf_d_ctrl;
+   int lna_sband_exist;
+   int lna_sband_ctrl;
+   int lna_sband_d_ctrl;
+   int foreign_lna0_ctrl;
+   int foreign_lna1_ctrl;
+   int foreign_lna2_ctrl;
+   int rf_switch_vhf;
+   int rf_switch_uhf;
+   int rf_switch_sband;
+   int leds_power;
+   int led0;
+   int led1;
+   int led2;
+   int led3;
+   int led4;
+   int ir;
+   int eeprom_wp;
+   int mrc_sense;
+   int mrc_pdn_resetn;
+   int mrc_gp0; /* mrcs spi int */
+   int mrc_gp1;
+   int mrc_gp2;
+   int mrc_gp3;
+   int mrc_gp4;
+   int host_spi_gsp_ts_int;
+};
 
 struct sms_board {
enum sms_device_type_st type;
@@ -41,9 +77,14 @@ struct sms_board {
 
/* gpios */
int led_power, led_hi, led_lo, lna_ctrl, rf_switch;
+   struct sms_board_gpio_cfg board_cfg;
+   enum ir_kb_type ir_kb_type;
 };
 
 struct sms_board *sms_get_board(int id);
+
+extern struct usb_device_id smsusb_id_table[];
+extern struct smscore_device_t *coredev;
 
 int sms_board_setup(struct smscore_device_t *coredev);
 
@@ -56,4 +97,28 @@ int sms_board_lna_control(struct smscore
 
 extern int sms_board_load_modules(int id);
 
+enum SMS_BOARD_EVENTS {
+   BOARD_EVENT_POWER_INIT,
+   BOARD_EVENT_POWER_SUSPEND,
+   BOARD_EVENT_POWER_RESUME,
+   BOARD_EVENT_BIND,
+   BOARD_EVENT_SCAN_PROG,
+   BOARD_EVENT_SCAN_COMP,
+   BOARD_EVENT_EMERGENCY_WARNING_SIGNAL,
+   BOARD_EVENT_FE_LOCK,
+   BOARD_EVENT_FE_UNLOCK,
+   BOARD_EVENT_DEMOD_LOCK,
+   BOARD_EVENT_DEMOD_UNLOCK,
+   BOARD_EVENT_RECEPTION_MAX_4,
+   BOARD_EVENT_RECEPTION_3,
+   BOARD_EVENT_RECEPTION_2,
+   BOARD_EVENT_RECEPTION_1,
+   BOARD_EVENT_RECEPTION_LOST_0,
+   BOARD_EVENT_MULTIPLEX_OK,
+   BOARD_EVENT_MULTIPLEX_ERRORS
+};
+
+int sms_board_event(struct smscore_device_t *coredev,
+   enum SMS_BOARD_EVENTS gevent);
+
 #endif /* __SMS_CARDS_H__ */



  
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [0904_18] Siano: smsusb - byte ordering and big endian support

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238760032 -10800
# Node ID ab731e3cec5cb076b8f87f827c3c97a4dd84e0ca
# Parent  73c6299ef5f518beb07b6eb371402fe1be4e26ea
[PATCH] [0904_18] Siano: smsusb - byte ordering and big endian support

From: Uri Shkolnik 

This patch add support for Siano's messaging in big endian systems.
Few indentations (without implementation impact) have been added.

Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r 73c6299ef5f5 -r ab731e3cec5c linux/drivers/media/dvb/siano/smsusb.c
--- a/linux/drivers/media/dvb/siano/smsusb.cFri Apr 03 14:50:58 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsusb.cFri Apr 03 15:00:32 2009 +0300
@@ -27,7 +27,6 @@ along with this program.  If not, see context;
+   struct smsusb_urb_t *surb = (struct smsusb_urb_t *)urb->context;
struct smsusb_device_t *dev = surb->dev;
 
if (urb->status < 0) {
@@ -76,6 +75,7 @@ static void smsusb_onresponse(struct urb
if (urb->actual_length > 0) {
struct SmsMsgHdr_ST *phdr = (struct SmsMsgHdr_ST *)surb->cb->p;
 
+   smsendian_handle_message_header(phdr);
if (urb->actual_length >= phdr->msgLength) {
surb->cb->size = phdr->msgLength;
 
@@ -179,6 +179,7 @@ static int smsusb_sendrequest(void *cont
struct smsusb_device_t *dev = (struct smsusb_device_t *)context;
int dummy;
 
+   smsendian_handle_message_header((struct SmsMsgHdr_ST *)buffer);
return usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 2),
buffer, size, &dummy, 1000);
 }
@@ -336,8 +337,8 @@ static int smsusb_init_device(struct usb
case SMS_VEGA:
dev->buffer_size = USB2_BUFFER_SIZE;
dev->response_alignment =
-   dev->udev->ep_in[1]->desc.wMaxPacketSize -
-   sizeof(struct SmsMsgHdr_ST);
+   le16_to_cpu(dev->udev->ep_in[1]->desc.wMaxPacketSize) -
+   sizeof(struct SmsMsgHdr_ST);
 
params.flags |= SMS_DEVICE_FAMILY2;
break;
@@ -532,13 +533,12 @@ MODULE_DEVICE_TABLE(usb, smsusb_id_table
 MODULE_DEVICE_TABLE(usb, smsusb_id_table);
 
 static struct usb_driver smsusb_driver = {
-   .name   = "smsusb",
-   .probe  = smsusb_probe,
-   .disconnect = smsusb_disconnect,
-   .id_table   = smsusb_id_table,
-
-   .suspend= smsusb_suspend,
-   .resume = smsusb_resume,
+   .name = "smsusb",
+   .probe = smsusb_probe,
+   .disconnect = smsusb_disconnect,
+   .suspend = smsusb_suspend,
+   .resume = smsusb_resume,
+   .id_table = smsusb_id_table,
 };
 
 int smsusb_register(void)



  
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb

[Jean Delvare]

On Sun, 5 Apr 2009 08:43:35 -0300, Mauro Carvalho Chehab wrote:
> On Thu, 2 Apr 2009 18:16:42 +0200
> Hans Verkuil  wrote:
> 
> > Hi Mauro,
> > 
> > Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
> 
> Done. We should convert TUNER_SET_CONFIG to v4l2-subdev, in order to stop 
> using
> the i2c command interface. I didn't checked, but I suspect that this is the
> last case of using the i2c command on v4l drivers.
> 
> The removal of i2c command will probably make Jean happy as well, since
> this will also remove some legacy code from i2c core.

Oh yeah \o/

> > This finalizes (I hope :-) ) the v4l2-subdev conversion. Most of these 
> > patches above remove code that's no longer needed. There are also some 
> > v4l2-subdev.h API improvements that I postponed until all the drivers were 
> > converted. These changes are trivial, but touch on a lot of files.
> 
> Please let's avoid changing the internal API again on 2.6.31. We should focus
> on fixing the bugs during this cycle, since the changes were far above the
> usual, and affected all drivers.
> 
> > The other major change is that the old i2c autoprobing API is now used for 
> > kernels < 2.6.26. This was < 2.6.22, but a bug in i2c_new_probed_subdev 
> > prevent us from using the new i2c API for kernels 2.6.22-2.6.25. Actually 
> > it would be possible with 2.6.25, but since there were some other i2c API 
> > changes in 2.6.26 anyway I decided that it made life easier if we put the 
> > switchover point at 2.6.26.
> 
> Ok.
> 
> > There are some other cleanups I could do, but all the important ones are 
> > now 
> > taken care of.
> > 
> > I would like to take the opportunity to thank Jean Delvare for his support 
> > and his help in testing various drivers and working on ir-kbd-i2c, and 
> > Mauro for processing and merging all my patches. I feel a little guilty for 
> > burying Mauro in this big pile of patches :-)
> > 
> > I also want to thank Andy Walls for doing the cx18 conversion, Mike Isely 
> > for doing the pvrusb2 conversion, Douglas Landgraf for doing the em28xx 
> > conversion, Trent Piepho for his reviews, Steve Toth for testing the 
> > cx23885 driver, Devin Heitmueller for converting au8522/au0828 and Sri 
> > Deevi for converting the cx231xx driver at short notice.
> > 
> > I've no doubt forgotten people, for which I apologize.
> 
> Thank you and all the others for the efforts. I expect you all to take extra
> care to fix all regressions that may eventually rise with those changes. In
> particular, please track the bugzillas at kernel.org.

Yes, I am totally committed to help fix any i2c issue that may arise as
a consequence of the recent driver conversions.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [0904_17] Siano: smsusb - update header and indentation

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238759458 -10800
# Node ID 73c6299ef5f518beb07b6eb371402fe1be4e26ea
# Parent  c582116cfbb96671629143fced33e3f88c28b3c7
[PATCH] [0904_17] Siano: smsusb - update header and indentation

From: Uri Shkolnik 

This patch does not introduce any implementation change.
It include modified license and included files list and
align indentation.

Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r c582116cfbb9 -r 73c6299ef5f5 linux/drivers/media/dvb/siano/smsusb.c
--- a/linux/drivers/media/dvb/siano/smsusb.cFri Apr 03 14:38:46 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsusb.cFri Apr 03 14:50:58 2009 +0300
@@ -1,35 +1,34 @@
-/*
- *  Driver for the Siano SMS1xxx USB dongle
- *
- *  author: Anatoly Greenblat
- *
- *  Copyright (c), 2005-2008 Siano Mobile Silicon, Inc.
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License version 2 as
- *  published by the Free Software Foundation;
- *
- *  Software distributed under the License is distributed on an "AS IS"
- *  basis, WITHOUT WARRANTY OF ANY KIND, either express or implied.
- *
- *  See the GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
+/
+
+Siano Mobile Silicon, Inc.
+MDTV receiver kernel modules.
+Copyright (C) 2006-2008, Uri Shkolnik, Anatoly Greenblat
+
+This program is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 2 of the License, or
+(at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program.  If not, see .
+
+/
 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "smscoreapi.h"
 #include "sms-cards.h"
 
-static int sms_dbg;
-module_param_named(debug, sms_dbg, int, 0644);
-MODULE_PARM_DESC(debug, "set debug level (info=1, adv=2 (or-able))");
+#include "smsendian.h"
 
 #define USB1_BUFFER_SIZE   0x1000
 #define USB2_BUFFER_SIZE   0x4000
@@ -41,7 +40,7 @@ struct smsusb_device_t;
 
 struct smsusb_urb_t {
struct smscore_buffer_t *cb;
-   struct smsusb_device_t  *dev;
+   struct smsusb_device_t *dev;
 
struct urb urb;
 };
@@ -50,10 +49,10 @@ struct smsusb_device_t {
struct usb_device *udev;
struct smscore_device_t *coredev;
 
-   struct smsusb_urb_t surbs[MAX_URBS];
+   struct smsusb_urb_t surbs[MAX_URBS];
 
-   int response_alignment;
-   int buffer_size;
+   int response_alignment;
+   int buffer_size;
 };
 
 static int smsusb_submit_urb(struct smsusb_device_t *dev,
@@ -75,7 +74,7 @@ static void smsusb_onresponse(struct urb
}
 
if (urb->actual_length > 0) {
-   struct SmsMsgHdr_ST *phdr = (struct SmsMsgHdr_ST *) surb->cb->p;
+   struct SmsMsgHdr_ST *phdr = (struct SmsMsgHdr_ST *)surb->cb->p;
 
if (urb->actual_length >= phdr->msgLength) {
surb->cb->size = phdr->msgLength;
@@ -84,11 +83,11 @@ static void smsusb_onresponse(struct urb
(phdr->msgFlags & MSG_HDR_FLAG_SPLIT_MSG)) {
 
surb->cb->offset =
-   dev->response_alignment +
-   ((phdr->msgFlags >> 8) & 3);
+   dev->response_alignment +
+   ((phdr->msgFlags >> 8) & 3);
 
/* sanity check */
-   if (((int) phdr->msgLength +
+   if (((int)phdr->msgLength +
 surb->cb->offset) > urb->actual_length) {
sms_err("invalid response "
"msglen %d offset %d "
@@ -101,7 +100,7 @@ static void smsusb_onresponse(struct urb
 
/* move buffer pointer and
 * copy header to its new location */
-   memcpy((char *) phdr + surb->cb->offset,
+   memcpy((char *)phdr + surb->cb->offset,
   phdr, sizeof(struct SmsMsgHdr_ST));
} 

Re: [PATCH] [0904_16] Siano: smsdvb - additional case of endian handling.

[Trent Piepho]

On Sun, 5 Apr 2009, Uri Shkolnik wrote:
>   PidMsg.xMsgHeader.msgLength = sizeof(PidMsg);
>   PidMsg.msgData[0] = feed->pid;
>
> - /* smsendian_handle_tx_message((struct SmsMsgHdr_ST *)&PidMsg); */
> + smsendian_handle_tx_message((struct SmsMsgHdr_ST *)&PidMsg);
>   return smsclient_sendrequest(client->smsclient, &PidMsg,
>   sizeof(PidMsg));

I don't get it, you wrote the code commented out in one patch, and now
you're going to sumbit patches to uncomment it one line at a time?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tm6010 development repository

[Mauro Carvalho Chehab]

On Sun, 05 Apr 2009 12:45:56 +1200
Kevin Wells  wrote:

> Steven Toth wrote:
> > Kevin Wells wrote:
> >> I've started trying to understand the code in the following repository:
> >>
> >> http://www.linuxtv.org/hg/~mchehab/tm6010/
> >>
> >> I have a few patches I would like to apply. How should I do this?
> > Submit the patches to the list and I'll try to get some time to create 
> > and maintain a ~stoth/tm6010 tree. I think I can get the nova-s-usb2 
> > running with just a little effort.
> Thanks Steve. Sorry for the slow reply. I'm doing this in my limited 
> spare time.
> 
> Patches to follow. Nothing exciting. Just trying to make the code more 
> robust. Patches are very granular. Let me know if that doesn't work for you.
> 
> Knowing the driver works on the nova-s-usb2 would be encouraging. I'm 
> trying to get it to work on an hvr-900h.

I'll merge those with some patches I have here. hvr-900h analog part is working
with a some troubles on the experimental tree I have here. A good thing to do,
after I merge yours and my patches, is to convert it to the new v4l2 dev/subdev
interface. I suspect that this will solve several bugs we currently have with
the i2c interface of this driver.

I intend to do this later this week, after the end of the merge window. For
now, I still have lots of patches to review, in order to submit for 2.6.30.

-- 

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [0904_16] Siano: smsdvb - additional case of endian handling.

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238758726 -10800
# Node ID c582116cfbb96671629143fced33e3f88c28b3c7
# Parent  856813745905e07d9fc6be5e136fdf7060c6fc37
siano: smsdvb - add support for old dvb-core version
[PATCH] [0904_16] Siano: smsdvb - additional case of endian handling.

From: Uri Shkolnik 

Additional case of endian handling.

Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r 856813745905 -r c582116cfbb9 linux/drivers/media/dvb/siano/smsdvb.c
- a/linux/drivers/media/dvb/siano/smsdvb.c  Fri Apr 03 14:30:50 2009 +0300
+ b/linux/drivers/media/dvb/siano/smsdvb.c  Fri Apr 03 14:38:46 2009 +0300
@@ -273,7 +273,7 @@ static int smsdvb_start_feed(struct dvb_
PidMsg.xMsgHeader.msgLength = sizeof(PidMsg);
PidMsg.msgData[0] = feed->pid;
 
-   /* smsendian_handle_tx_message((struct SmsMsgHdr_ST *)&PidMsg); */
+   smsendian_handle_tx_message((struct SmsMsgHdr_ST *)&PidMsg);
return smsclient_sendrequest(client->smsclient, &PidMsg,
sizeof(PidMsg));
 }
@@ -546,10 +546,15 @@ static int smsdvb_hotplug(struct smscore
}
 



  
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [0904_15] Siano: core header - bind SMS messages endian handling

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238758250 -10800
# Node ID 856813745905e07d9fc6be5e136fdf7060c6fc37
# Parent  0ddd2fd20badbf2bb33566a05ff2ea2a6dff8600
[PATCH] [0904_15] Siano: core header - bind SMS messages endian handling

From: Uri Shkolnik 

This patch bind the smsedian (which manipulate the content
of Siano's protocol messages) to the smsdvb component.

Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r 0ddd2fd20bad -r 856813745905 linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 14:18:10 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 14:30:50 2009 +0300
@@ -29,7 +29,7 @@ along with this program.  If not, see msgLength - sizeof(struct SmsMsgHdr_ST);*/
 
-   /*smsendian_handle_rx_message((struct SmsMsgData_ST *) phdr);*/
+   smsendian_handle_rx_message((struct SmsMsgData_ST *) phdr);
 
switch (phdr->msgType) {
case MSG_SMS_DVBT_BDA_DATA:
@@ -293,7 +293,7 @@ static int smsdvb_stop_feed(struct dvb_d
PidMsg.xMsgHeader.msgLength = sizeof(PidMsg);
PidMsg.msgData[0] = feed->pid;
 
-   /* smsendian_handle_tx_message((struct SmsMsgHdr_ST *)&PidMsg); */
+   smsendian_handle_tx_message((struct SmsMsgHdr_ST *)&PidMsg);
return smsclient_sendrequest(client->smsclient, &PidMsg,
sizeof(PidMsg));
 }
@@ -304,7 +304,7 @@ static int smsdvb_sendrequest_and_wait(s
 {
int rc;
 
-   /* smsendian_handle_tx_message((struct SmsMsgHdr_ST *)buffer); */
+   smsendian_handle_tx_message((struct SmsMsgHdr_ST *)buffer);
rc = smsclient_sendrequest(client->smsclient, buffer, size);
if (rc < 0)
return rc;



  
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb

[Mauro Carvalho Chehab]

On Thu, 2 Apr 2009 18:16:42 +0200
Hans Verkuil  wrote:

> Hi Mauro,
> 
> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb

Done. We should convert TUNER_SET_CONFIG to v4l2-subdev, in order to stop using
the i2c command interface. I didn't checked, but I suspect that this is the
last case of using the i2c command on v4l drivers.

The removal of i2c command will probably make Jean happy as well, since
this will also remove some legacy code from i2c core.

> This finalizes (I hope :-) ) the v4l2-subdev conversion. Most of these 
> patches above remove code that's no longer needed. There are also some 
> v4l2-subdev.h API improvements that I postponed until all the drivers were 
> converted. These changes are trivial, but touch on a lot of files.

Please let's avoid changing the internal API again on 2.6.31. We should focus
on fixing the bugs during this cycle, since the changes were far above the
usual, and affected all drivers.

> The other major change is that the old i2c autoprobing API is now used for 
> kernels < 2.6.26. This was < 2.6.22, but a bug in i2c_new_probed_subdev 
> prevent us from using the new i2c API for kernels 2.6.22-2.6.25. Actually 
> it would be possible with 2.6.25, but since there were some other i2c API 
> changes in 2.6.26 anyway I decided that it made life easier if we put the 
> switchover point at 2.6.26.

Ok.

> There are some other cleanups I could do, but all the important ones are now 
> taken care of.
> 
> I would like to take the opportunity to thank Jean Delvare for his support 
> and his help in testing various drivers and working on ir-kbd-i2c, and 
> Mauro for processing and merging all my patches. I feel a little guilty for 
> burying Mauro in this big pile of patches :-)
> 
> I also want to thank Andy Walls for doing the cx18 conversion, Mike Isely 
> for doing the pvrusb2 conversion, Douglas Landgraf for doing the em28xx 
> conversion, Trent Piepho for his reviews, Steve Toth for testing the 
> cx23885 driver, Devin Heitmueller for converting au8522/au0828 and Sri 
> Deevi for converting the cx231xx driver at short notice.
> 
> I've no doubt forgotten people, for which I apologize.

Thank you and all the others for the efforts. I expect you all to take extra
care to fix all regressions that may eventually rise with those changes. In
particular, please track the bugzillas at kernel.org.

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [0904_14] Siano: assemble all components to one kernel module

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238756860 -10800
# Node ID 616e696ce6f0c0d76a1aaea8b36e0345112c5ab6
# Parent  f65a29f0f9a66f82a91525ae0085a15f00ac91c2
[PATCH] [0904_14] Siano: assemble all components to one kernel module

From: Uri Shkolnik 

Previously, the support for Siano-based devices
has been combined from several kernel modules. 
This patch assembles all into single kernel module.

Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r f65a29f0f9a6 -r 616e696ce6f0 linux/drivers/media/dvb/siano/Makefile
--- a/linux/drivers/media/dvb/siano/MakefileFri Apr 03 13:40:04 2009 +0300
+++ b/linux/drivers/media/dvb/siano/MakefileFri Apr 03 14:07:40 2009 +0300
@@ -1,8 +1,6 @@ sms1xxx-objs := smscoreapi.o sms-cards.o
-sms1xxx-objs := smscoreapi.o sms-cards.o
+sms1xxx-objs := smscoreapi.o sms-cards.o smsusb.o smsdvb.o smsendian.o
 
 obj-$(CONFIG_DVB_SIANO_SMS1XXX) += sms1xxx.o
-obj-$(CONFIG_DVB_SIANO_SMS1XXX) += smsusb.o
-obj-$(CONFIG_DVB_SIANO_SMS1XXX) += smsdvb.o
 
 EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
 
diff -r f65a29f0f9a6 -r 616e696ce6f0 linux/drivers/media/dvb/siano/smscoreapi.c
--- a/linux/drivers/media/dvb/siano/smscoreapi.cFri Apr 03 13:40:04 
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.cFri Apr 03 14:07:40 
2009 +0300
@@ -1321,8 +1321,8 @@ static int __init smscore_module_init(vo
}
 #endif
 
-#if 0 /* def SMS_DVB_CLIENT */
-   /* DVB Register */
+#ifdef SMS_DVB3_SUBSYS
+   /* DVB v.3 Register */
rc = smsdvb_register();
if (rc) {
sms_err("Error registering DVB client.\n");
@@ -1339,7 +1339,7 @@ static int __init smscore_module_init(vo
}
 #endif
 
-#if 0 /* def SMS_USB_BUS_DRV */
+#ifdef SMS_USB_DRV
/* USB Register */
rc = smsusb_register();
if (rc) {
@@ -1385,8 +1385,7 @@ static void __exit smscore_module_exit(v
smschar_unregister();
 #endif
 
-#if 0 /* def SMS_DVB_CLIENT */
-   /* DVB UnRegister */
+#ifdef SMS_DVB3_SUBSYS
smsdvb_unregister();
 #endif
 
@@ -1395,8 +1394,9 @@ static void __exit smscore_module_exit(v
smsnet_unregister();
 #endif
 
-#if 0 /* def SMS_USB_BUS_DRV */
-   /* Unregister USB */
+   /* Unegister interfaces objects */
+#ifdef SMS_USB_DRV
+   /* USB unregister */
smsusb_unregister();
 #endif
 
diff -r f65a29f0f9a6 -r 616e696ce6f0 linux/drivers/media/dvb/siano/smscoreapi.h
--- a/linux/drivers/media/dvb/siano/smscoreapi.hFri Apr 03 13:40:04 
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.hFri Apr 03 14:07:40 
2009 +0300
@@ -617,6 +617,17 @@ int smscore_get_board_id(struct smscore_
 
 int smscore_led_state(struct smscore_device_t *core, int led);
 
+
+#ifdef SMS_DVB3_SUBSYS
+extern int smsdvb_register(void);
+extern void smsdvb_unregister(void);
+#endif
+
+#ifdef SMS_USB_DRV
+extern int smsusb_register(void);
+extern void smsusb_unregister(void);
+#endif
+
 /*  */
 
 #define DBG_INFO 1
diff -r f65a29f0f9a6 -r 616e696ce6f0 linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 13:40:04 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 14:07:40 2009 +0300
@@ -638,7 +638,7 @@ adapter_error:
return rc;
 }
 
-int smsdvb_module_init(void)
+int smsdvb_register(void)
 {
int rc;
 
@@ -652,7 +652,7 @@ int smsdvb_module_init(void)
return rc;
 }
 
-void smsdvb_module_exit(void)
+void smsdvb_unregister(void)
 {
smscore_unregister_hotplug(smsdvb_hotplug);
 
@@ -665,9 +665,6 @@ void smsdvb_module_exit(void)
kmutex_unlock(&g_smsdvb_clientslock);
 }
 
-module_init(smsdvb_module_init);
-module_exit(smsdvb_module_exit);
-
 MODULE_DESCRIPTION("SMS DVB subsystem adaptation module");
 MODULE_AUTHOR("Siano Mobile Silicon, INC. (u...@siano-ms.com)");
 MODULE_LICENSE("GPL");
diff -r f65a29f0f9a6 -r 616e696ce6f0 linux/drivers/media/dvb/siano/smsusb.c
--- a/linux/drivers/media/dvb/siano/smsusb.cFri Apr 03 13:40:04 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsusb.cFri Apr 03 14:07:40 2009 +0300
@@ -539,7 +539,7 @@ static struct usb_driver smsusb_driver =
.resume = smsusb_resume,
 };
 
-int smsusb_module_init(void)
+int smsusb_register(void)
 {
int rc = usb_register(&smsusb_driver);
if (rc)
@@ -550,16 +550,13 @@ int smsusb_module_init(void)
return rc;
 }
 
-void smsusb_module_exit(void)
+void smsusb_unregister(void)
 {
-   sms_debug("");
/* Regular USB Cleanup */
usb_deregister(&smsusb_driver);
+   sms_info("end");
 }
 
-module_init(smsusb_module_init);
-module_exit(smsusb_module_exit);
-
-MODULE_DESCRIPTION("Driver for the Siano SMS1XXX USB dongle");
+MODULE_DESCRIPTION("Driver for the Siano SMS1xxx USB dongle");
 MODULE_AUTHOR("Siano Mobile Silicon, INC. (u...@siano-ms.com)");
 MODULE_LICENSE("GPL");



  
--
To unsubscribe from this l

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Erik Andrén]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Hans de Goede wrote:
> On 04/04/2009 10:22 PM, Erik Andrén wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hi,
>>
>> While trying to get hflip and vflip working for the stv06xx webcam
>> bridge coupled to the vv6410 sensor I've come across the following
>> problem.
>>
>> When flipping the image horizontally, vertically or both, the sensor
>> pixel ordering changes. In the m5602 driver I was able to compensate
>> for this in the bridge code. In the stv06xx I don't have this
>> option. One way of solving this problem is by changing the
>> pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
>> format. When a vertical flip is required, change the format to
>> V4L2_SBGGR8.
>>
>> My current understanding of libv4l is that it probes the pixelformat
>>upon device open. In order for this to work we would need either
>> poll the current pixelformat regularly or implement some kind of
>> notification mechanism upon a flipping request.
>>
>> What do you think is this the right way to go or is there another
>> alternative.
>>
> 
> The changing of the pixelformat only happens when you flip the data
> before conversion. If you look at the current upside down handling
> code you will see it does the rotate 180 degrees after conversion.
> 
> This is how the vflip / hflip should be handled too. We only have
> 4 (2 really since we don't care about r versus b / u versus v while
> flippiing) destination formats for which we then need to write flipping
> code. Otherwise we need to write flipping code for *all* supported input
> formats, not to mention flipping some input formats is close to impossible
> (JPEG for example).
> 

So you mean we should do the vflip/hflip in software, just exposing
one native format?

Best regards,
Erik

> Regards,
> 
> Hans

> 
> p.s.
> 
> One problem with this approach is that if an apps ask for a native
> cam format which is not one which we can also convert to, the
> flipping won't work. I think this is best solved by simply not
> listing the native formats in the enum-fmt output when the cam
> needs flipping.
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknYlVoACgkQN7qBt+4UG0FwqACfQtawSmcm8rtFUCGZtV9pzVd+
jmkAoKHkibnapkZkDfl4pXd8pjaJ9M0E
=odkv
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] soc-camera: one new host-driver, one driver extension and one fix

[Mauro Carvalho Chehab]

On Sun, 5 Apr 2009 12:26:45 +0200 (CEST)
Guennadi Liakhovetski  wrote:

> Hi Mauro,
> 
> On Sun, 5 Apr 2009, Mauro Carvalho Chehab wrote:
> 
> > On Fri, 3 Apr 2009 21:34:59 +0200 (CEST)
> > Guennadi Liakhovetski  wrote:
> > 
> > > Hi Mauro,
> > > 
> >  
> > > 04/04: Add camera (CSI) driver for MX1
> > > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f115ddf29d64
> > 
> > There are two checkpatch.pl warnings on the last one. Please add later a 
> > patch to fix.
> > 
> > WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
> > #128: FILE: linux/arch/arm/mach-mx1/ksym_mx1.c:17:
> > +EXPORT_SYMBOL(mx1_camera_sof_fiq_start);
> > 
> > WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
> > #129: FILE: linux/arch/arm/mach-mx1/ksym_mx1.c:18:
> > +EXPORT_SYMBOL(mx1_camera_sof_fiq_end);
> 
> They are irrelevant. These two symbols are defined in assembly, so, you 
> cannot put EXPORT_SYMBOL() there.

OK.


Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [0904_13] Siano: move DVB_API and remove redundant code

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238755204 -10800
# Node ID f65a29f0f9a66f82a91525ae0085a15f00ac91c2
# Parent  897669fdeb3be75a2bde978557b5398a4a7d8914
[PATCH] [0904_13] Siano: move DVB_API and remove redundant code

From: Uri Shkolnik 

The DVB-API related information has been moved from the core header
to the smsdvb, and the redundant code has been removed from the
core header.

This code has been moved since it is used only by
the smsdvb client component.

Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r 897669fdeb3b -r f65a29f0f9a6 linux/drivers/media/dvb/siano/smscoreapi.h
--- a/linux/drivers/media/dvb/siano/smscoreapi.hFri Apr 03 13:31:13 
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.hFri Apr 03 13:40:04 
2009 +0300
@@ -36,15 +36,6 @@ along with this program.  If not, see 
 
 /* #include "smsir.h" */
-
-#define SMS_DVB3_SUBSYS
-#ifdef SMS_DVB3_SUBSYS
-#include "dmxdev.h"
-#include "dvbdev.h"
-#include "dvb_demux.h"
-#include "dvb_frontend.h"
-
-#endif
 
 #define kmutex_init(_p_) mutex_init(_p_)
 #define kmutex_lock(_p_) mutex_lock(_p_)
diff -r 897669fdeb3b -r f65a29f0f9a6 linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 13:31:13 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 13:40:04 2009 +0300
@@ -22,6 +22,11 @@ along with this program.  If not, see 
 #include 
 #include 
+
+#include "dmxdev.h"
+#include "dvbdev.h"
+#include "dvb_demux.h"
+#include "dvb_frontend.h"
 
 #include "smscoreapi.h"
 /*#include "smsendian.h"*/
@@ -52,7 +57,7 @@ struct smsdvb_client_t {
fe_status_t fe_status;
int fe_ber, fe_snr, fe_unc, fe_signal_strength;
 
-   struct completion tune_done, stat_done;
+   struct completion tune_done;
 
/* todo: save freq/band instead whole struct */
struct dvb_frontend_parameters fe_params;



  
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] http://linuxtv.org/hg/~eandren/v4l-dvb/

[Mauro Carvalho Chehab]

On Fri, 03 Apr 2009 20:29:08 +0200
Erik Andrén  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi Jean-Francois,
> 
> Please pull http://linuxtv.org/hg/~eandren/v4l-dvb/
> for more m5602-gspca changeset that are 2.6.30 material.
> 

Jean,

I'm preparing the last 2.6.30 material for sending upstream. Could you please
merge this quickly today?

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] soc-camera: one new host-driver, one driver extension and one fix

[Guennadi Liakhovetski]

Hi Mauro,

On Sun, 5 Apr 2009, Mauro Carvalho Chehab wrote:

> On Fri, 3 Apr 2009 21:34:59 +0200 (CEST)
> Guennadi Liakhovetski  wrote:
> 
> > Hi Mauro,
> > 
>  
> > 04/04: Add camera (CSI) driver for MX1
> > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f115ddf29d64
> 
> There are two checkpatch.pl warnings on the last one. Please add later a 
> patch to fix.
> 
> WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
> #128: FILE: linux/arch/arm/mach-mx1/ksym_mx1.c:17:
> +EXPORT_SYMBOL(mx1_camera_sof_fiq_start);
> 
> WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
> #129: FILE: linux/arch/arm/mach-mx1/ksym_mx1.c:18:
> +EXPORT_SYMBOL(mx1_camera_sof_fiq_end);

They are irrelevant. These two symbols are defined in assembly, so, you 
cannot put EXPORT_SYMBOL() there.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [0904_12] Siano: unified the debug filter module parameter (dvb and core)

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238744721 -10800
# Node ID 5b86da897fbaf03ea4f5bca50abeaad15634f1d9
# Parent  01979ae55ffec22d74b77681613f38bd606be227
[PATCH] [0904_12] Siano: unified the debug filter module parameter (dvb and 
core)

From: Uri Shkolnik 

The sms_debug module parameter sets the debug filter
for the smsmdtv module. It has been moved to the core
component, and replace the smsdvb's.

Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r 01979ae55ffe -r 5b86da897fba linux/drivers/media/dvb/siano/smscoreapi.c
--- a/linux/drivers/media/dvb/siano/smscoreapi.cFri Apr 03 10:26:48 
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.cFri Apr 03 10:45:21 
2009 +0300
@@ -34,8 +34,8 @@
 #include "smscoreapi.h"
 #include "sms-cards.h"
 
-static int sms_dbg;
-module_param_named(debug, sms_dbg, int, 0644);
+int sms_debug;
+module_param_named(debug, sms_debug, int, 0644);
 MODULE_PARM_DESC(debug, "set debug level (info=1, adv=2 (or-able))");
 
 struct smscore_device_notifyee_t {
diff -r 01979ae55ffe -r 5b86da897fba linux/drivers/media/dvb/siano/smscoreapi.h
--- a/linux/drivers/media/dvb/siano/smscoreapi.hFri Apr 03 10:26:48 
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.hFri Apr 03 10:45:21 
2009 +0300
@@ -627,6 +627,7 @@ int smscore_led_state(struct smscore_dev
 int smscore_led_state(struct smscore_device_t *core, int led);
 
 /*  */
+extern int sms_debug;
 
 #define DBG_INFO 1
 #define DBG_ADV  2
@@ -635,7 +636,7 @@ int smscore_led_state(struct smscore_dev
printk(kern "%s: " fmt "\n", __func__, ##arg)
 
 #define dprintk(kern, lvl, fmt, arg...) do {\
-   if (sms_dbg & lvl) \
+   if (sms_debug & lvl) \
sms_printk(kern, fmt, ##arg); } while (0)
 
 #define sms_log(fmt, arg...) sms_printk(KERN_INFO, fmt, ##arg)
diff -r 01979ae55ffe -r 5b86da897fba linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 10:26:48 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 10:45:21 2009 +0300
@@ -63,9 +63,6 @@ static struct list_head g_smsdvb_clients
 static struct list_head g_smsdvb_clients;
 static struct mutex g_smsdvb_clientslock;
 
-static int sms_dbg;
-module_param_named(debug, sms_dbg, int, 0644);
-MODULE_PARM_DESC(debug, "set debug level (info=1, adv=2 (or-able))");
 
 /* Events that may come from DVB v3 adapter */
 static void sms_board_dvb3_event(struct smscore_device_t *coredev,



  
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [0904_11] Siano: smsendian & smsdvb - binding the smsendian to smsdvb

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238743608 -10800
# Node ID 01979ae55ffec22d74b77681613f38bd606be227
# Parent  ec7ee486fb86d51bdb48e6a637a6ddd52e9e08c2
[PATCH] [0904_11] Siano: smsendian & smsdvb - binding the smsendian to smsdvb

From: Uri Shkolnik 

Bind the smsendian, which manipulates some Siano's messages content
when using Siano chip-set with big-endian target, 
with the DVB-API v3 client adapter.

Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r ec7ee486fb86 -r 01979ae55ffe linux/drivers/media/dvb/siano/Makefile
--- a/linux/drivers/media/dvb/siano/MakefileFri Apr 03 10:10:22 2009 +0300
+++ b/linux/drivers/media/dvb/siano/MakefileFri Apr 03 10:26:48 2009 +0300
@@ -1,4 +1,4 @@ sms1xxx-objs := smscoreapi.o sms-cards.o
-sms1xxx-objs := smscoreapi.o sms-cards.o
+sms1xxx-objs := smscoreapi.o sms-cards.o smsendian.o
 
 obj-$(CONFIG_DVB_SIANO_SMS1XXX) += sms1xxx.o
 obj-$(CONFIG_DVB_SIANO_SMS1XXX) += smsusb.o
diff -r ec7ee486fb86 -r 01979ae55ffe linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 10:10:22 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 10:26:48 2009 +0300
@@ -24,7 +24,7 @@ along with this program.  If not, see 
 
 #include "smscoreapi.h"
-/*#include "smsendian.h"*/
+#include "smsendian.h"
 #include "sms-cards.h"
 
 #ifndef DVB_DEFINE_MOD_OPT_ADAPTER_NR
@@ -52,7 +52,7 @@ struct smsdvb_client_t {
fe_status_t fe_status;
int fe_ber, fe_snr, fe_unc, fe_signal_strength;
 
-   struct completion tune_done, stat_done;
+   struct completion tune_done;
 
/* todo: save freq/band instead whole struct */
struct dvb_frontend_parameters fe_params;
@@ -114,7 +114,7 @@ static int smsdvb_onresponse(void *conte
u32 *pMsgData = (u32 *) phdr + 1;
/*u32 MsgDataLen = phdr->msgLength - sizeof(struct SmsMsgHdr_ST);*/
 
-   /*smsendian_handle_rx_message((struct SmsMsgData_ST *) phdr);*/
+   smsendian_handle_rx_message((struct SmsMsgData_ST *) phdr);
 
switch (phdr->msgType) {
case MSG_SMS_DVBT_BDA_DATA:
@@ -271,7 +271,7 @@ static int smsdvb_start_feed(struct dvb_
PidMsg.xMsgHeader.msgLength = sizeof(PidMsg);
PidMsg.msgData[0] = feed->pid;
 
-   /* smsendian_handle_tx_message((struct SmsMsgHdr_ST *)&PidMsg); */
+   smsendian_handle_tx_message((struct SmsMsgHdr_ST *)&PidMsg);
return smsclient_sendrequest(client->smsclient, &PidMsg,
sizeof(PidMsg));
 }
@@ -291,7 +291,7 @@ static int smsdvb_stop_feed(struct dvb_d
PidMsg.xMsgHeader.msgLength = sizeof(PidMsg);
PidMsg.msgData[0] = feed->pid;
 
-   /* smsendian_handle_tx_message((struct SmsMsgHdr_ST *)&PidMsg); */
+   smsendian_handle_tx_message((struct SmsMsgHdr_ST *)&PidMsg);
return smsclient_sendrequest(client->smsclient, &PidMsg,
sizeof(PidMsg));
 }
@@ -302,7 +302,7 @@ static int smsdvb_sendrequest_and_wait(s
 {
int rc;
 
-   /* smsendian_handle_tx_message((struct SmsMsgHdr_ST *)buffer); */
+   smsendian_handle_tx_message((struct SmsMsgHdr_ST *)buffer);
rc = smsclient_sendrequest(client->smsclient, buffer, size);
if (rc < 0)
return rc;



  
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] soc-camera: one new host-driver, one driver extension and one fix

[Mauro Carvalho Chehab]

On Sun, 5 Apr 2009 07:09:18 -0300
Mauro Carvalho Chehab  wrote:

> On Fri, 3 Apr 2009 21:34:59 +0200 (CEST)
> Guennadi Liakhovetski  wrote:
> 
> > Hi Mauro,
> > 
>  
> > 04/04: Add camera (CSI) driver for MX1
> > http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f115ddf29d64
> 
> There are two checkpatch.pl warnings on the last one. Please add later a 
> patch to fix.
> 
> WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
> #128: FILE: linux/arch/arm/mach-mx1/ksym_mx1.c:17:
> +EXPORT_SYMBOL(mx1_camera_sof_fiq_start);
> 
> WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
> #129: FILE: linux/arch/arm/mach-mx1/ksym_mx1.c:18:
> +EXPORT_SYMBOL(mx1_camera_sof_fiq_end);

Hmm... I also suspect that you can do some cleanups at the includes. For
example, You don't need this one:

+#include 

since it is already included by module.h.

> 
> Cheers,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html




Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [0904_10] Siano: smsdvb - add events mechanism

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238742622 -10800
# Node ID ec7ee486fb86d51bdb48e6a637a6ddd52e9e08c2
# Parent  020ba7b31c963bd36d607848198e9e4258a6f80e
[PATCH] [0904_10] Siano: smsdvb - add events mechanism

From: Uri Shkolnik 

Add events mechanism that will notify the "cards" component
(which represent the specific hardware target) for DVB related
events.

Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r 020ba7b31c96 -r ec7ee486fb86 linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cThu Apr 02 21:33:14 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsdvb.cFri Apr 03 10:10:22 2009 +0300
@@ -66,6 +66,45 @@ static int sms_dbg;
 static int sms_dbg;
 module_param_named(debug, sms_dbg, int, 0644);
 MODULE_PARM_DESC(debug, "set debug level (info=1, adv=2 (or-able))");
+
+/* Events that may come from DVB v3 adapter */
+static void sms_board_dvb3_event(struct smscore_device_t *coredev,
+   enum SMS_DVB3_EVENTS event) {
+   switch (event) {
+   case DVB3_EVENT_INIT:
+   sms_debug("DVB3_EVENT_INIT");
+   /* sms_board_event(coredev, BOARD_EVENT_BIND); */
+   break;
+   case DVB3_EVENT_SLEEP:
+   sms_debug("DVB3_EVENT_SLEEP");
+   /* sms_board_event(coredev, BOARD_EVENT_POWER_SUSPEND); */
+   break;
+   case DVB3_EVENT_HOTPLUG:
+   sms_debug("DVB3_EVENT_HOTPLUG");
+   /* sms_board_event(coredev, BOARD_EVENT_POWER_INIT); */
+   break;
+   case DVB3_EVENT_FE_LOCK:
+   sms_debug("DVB3_EVENT_FE_LOCK");
+   /* sms_board_event(coredev, BOARD_EVENT_FE_LOCK); */
+   break;
+   case DVB3_EVENT_FE_UNLOCK:
+   sms_debug("DVB3_EVENT_FE_UNLOCK");
+   /* sms_board_event(coredev, BOARD_EVENT_FE_UNLOCK); */
+   break;
+   case DVB3_EVENT_UNC_OK:
+   sms_debug("DVB3_EVENT_UNC_OK");
+   /* sms_board_event(coredev, BOARD_EVENT_MULTIPLEX_OK); */
+   break;
+   case DVB3_EVENT_UNC_ERR:
+   sms_debug("DVB3_EVENT_UNC_ERR");
+   /* sms_board_event(coredev, BOARD_EVENT_MULTIPLEX_ERRORS); */
+   break;
+
+   default:
+   sms_err("Unknown dvb3 api event");
+   break;
+   }
+}
 
 static int smsdvb_onresponse(void *context, struct smscore_buffer_t *cb)
 {
@@ -174,17 +213,15 @@ static int smsdvb_onresponse(void *conte
client->fe_status = 0;
}
 
-   /*
-if (client->fe_status & FE_HAS_LOCK)
-sms_board_dvb3_event(client->coredev, DVB3_EVENT_FE_LOCK);
-else
-sms_board_dvb3_event(client->coredev, DVB3_EVENT_FE_UNLOCK);
+   if (client->fe_status & FE_HAS_LOCK)
+   sms_board_dvb3_event(client->coredev, DVB3_EVENT_FE_LOCK);
+   else
+   sms_board_dvb3_event(client->coredev, DVB3_EVENT_FE_UNLOCK);
 
-if (client->sms_stat_dvb.ReceptionData.ErrorTSPackets == 0)
-sms_board_dvb3_event(client->coredev, DVB3_EVENT_UNC_OK);
-else
-sms_board_dvb3_event(client->coredev, DVB3_EVENT_UNC_ERR);
-*/
+   if (client->sms_stat_dvb.ReceptionData.ErrorTSPackets == 0)
+   sms_board_dvb3_event(client->coredev, DVB3_EVENT_UNC_OK);
+   else
+   sms_board_dvb3_event(client->coredev, DVB3_EVENT_UNC_ERR);
 
if (client->fe_status & FE_HAS_LOCK)
sms_board_led_feedback(client->coredev,
@@ -346,13 +383,12 @@ static int smsdvb_set_frontend(struct dv
   struct dvb_frontend_parameters *fep)
 {
struct smsdvb_client_t *client =
-   container_of(fe, struct smsdvb_client_t, frontend);
+   container_of(fe, struct smsdvb_client_t, frontend);
 
struct {
struct SmsMsgHdr_ST Msg;
u32 Data[3];
} Msg;
-   int ret;
 
Msg.Msg.msgSrcId = DVBT_BDA_CONTROL_MSG_ID;
Msg.Msg.msgDstId = HIF_TASK;
@@ -387,7 +423,8 @@ static int smsdvb_set_frontend(struct dv
}
 
/* Disable LNA, if any. An error is returned if no LNA is present */
-   ret = sms_board_lna_control(client->coredev, 0);
+   {
+   int ret = sms_board_lna_control(client->coredev, 0);
if (ret == 0) {
fe_status_t status;
 
@@ -403,7 +440,7 @@ static int smsdvb_set_frontend(struct dv
/* previous tune didnt lock - enable LNA and tune again */
sms_board_lna_control(client->coredev, 1);
}
-
+   }
return smsdvb_sendrequest_and_wait(client, &Msg, sizeof(Msg),
   &client->tune_done);
 }
@@ -428,6 +465,7 @@ static int smsdvb_init(struct dvb_fronte
struct smsdvb_client_t *client =
container_of(fe, struct smsdvb_client_t, frontend);
 
+   sms_board_dvb3_event(client->coredev, DVB3_EVENT_INIT);
sms_bo

Re: [PULL] soc-camera: one new host-driver, one driver extension and one fix

[Mauro Carvalho Chehab]

On Fri, 3 Apr 2009 21:34:59 +0200 (CEST)
Guennadi Liakhovetski  wrote:

> Hi Mauro,
> 
 
> 04/04: Add camera (CSI) driver for MX1
> http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f115ddf29d64

There are two checkpatch.pl warnings on the last one. Please add later a patch 
to fix.

WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
#128: FILE: linux/arch/arm/mach-mx1/ksym_mx1.c:17:
+EXPORT_SYMBOL(mx1_camera_sof_fiq_start);

WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
#129: FILE: linux/arch/arm/mach-mx1/ksym_mx1.c:18:
+EXPORT_SYMBOL(mx1_camera_sof_fiq_end);

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] ir-kbd-i2c conversion to the new i2c binding model

[Mauro Carvalho Chehab]

On Sat, 4 Apr 2009 14:24:27 +0200
Jean Delvare  wrote:

> Hi all,
> 
> Here finally comes my conversion of ir-kbd-i2c to the new i2c binding
> model. I've split it into 6 pieces for easier review. Firstly there are
> 2 preliminary patches:
> 
> media-video-01-cx18-fix-i2c-error-handling.patch
> media-video-02-ir-kbd-i2c-dont-abuse-client-name.patch
> 
> Then 2 patches doing the actual conversion:
> 
> media-video-03-ir-kbd-i2c-convert-to-new-style.patch
> media-video-04-configure-ir-receiver.patch
> 
> And lastly 2 patches cleaning up saa7134-input thanks to the new
> possibilities offered by the conversion:
> 
> media-video-05-saa7134-input-cleanup-msi-ir.patch
> media-video-06-saa7134-input-cleanup-avermedia-cardbus.patch
> 
> This patch set is against the v4l-dvb repository, but I didn't pay
> attention to the compatibility issues. I simply build-tested it on
> 2.6.27 and 2.6.29.
> 
> This patch set touches many different drivers and I can't test any of
> them. My only TV card with an IR receiver doesn't make use of
> ir-kbd-i2c. So I would warmly welcome testers. The more testing my
> changes can get, the better.
> 
> And of course I welcome reviews and comments as well. I had to touch
> many drivers I don't know anything about so it is possible that I
> missed something.
> 
> I'll post all 6 patches as replies to this post. They can also be
> temporarily downloaded from:
>   http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/
> Additionally I've put a combined patch there, to make testing easier:
>   
> http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ir-kbd-i2c-conversion-ALL-IN-ONE.patch
> But for review the individual patches are much better.
> 
> Thanks,

>From the discussions we already have, I noticed some points to take care of:

1) about the lirc support, I don't think we should change a kernel driver due
to an out-of-tree kernel driver. As I've commented on PATCH 3/6 discussion, we
need to better address this with lirc developers;

2) the way Mike is proposing to solve the issue with pvrusb2 will break
userspace usage for people that have those devices whose IR work with the
in-kernel IR i2c driver. This means that we'll cause a kernel regression due to
an out-of-tree driver;

3) So far, nobody gave us any positive return that the new IR model is working 
with
any of the touched drivers. So, more tests are needed. I'm expecting to have a
positive reply for each of the touched drivers. People, please test!

Since the merge window is almost finished, IMO, we should postpone those
changes to 2.6.31, to better address the lirc issue and to give people more
time for testing, applying the changesets after the end of the merge window at
the v4l/dvb development tree. This will help people to test, review and propose
changes if needed.

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] ir-kbd-i2c: Switch to the new-style device binding model

[Mauro Carvalho Chehab]

On Sun, 5 Apr 2009 07:46:47 +0200
Hans Verkuil  wrote:

> On Sunday 05 April 2009 01:05:39 Jean Delvare wrote:
> > Hi Mike,
> >
> > On Sat, 4 Apr 2009 10:51:01 -0500 (CDT), Mike Isely wrote:
> > > Nacked-by: Mike Isely 
> > >
> > > This will interfere with the alternative use of LIRC drivers (which
> > > work in more cases that ir-kbd).
> >
> > Why then is ir-kbd in the kernel tree and not LIRC drivers?
> >
> > > It will thus break some peoples' use of the driver.
> >
> > Do you think it will, or did you test and it actually does? If it
> > indeed breaks, please explain why, so that a solution can be found.
> >
> > > Also we have better information on what i2c addresses needed to
> > > be probed based on the model of the device
> >
> > This is excellent news. As I said in the header comment of the patch,
> > avoiding probing when we know what the IR receiver is and at which
> > address it sits is the way to go. Please send me all the information
> > you have and I'll be happy to add a patch to the series, that skips
> > probing whenever possible. Or write that patch yourself if you prefer.
> >
> > > - and some devices supported
> > > by this device are not from Hauppauge so you are making a too-strong
> > > assumption that IR should be probed this way in all cases.
> >
> > I didn't make any assumption, sorry. I simply copied the code from
> > ir-kbd-i2c. If my code does the wrong thing for some devices, that was
> > already the case before. And this will certainly be easier to fix after
> > my changes than before.
> >
> > On top of that, the "Hauppauge trick" is really only the order in which
> > the addresses are probed. Just because a specific order is better for
> > Hauppauge boards, doesn't mean it won't work for non-Hauppauge boards.
> >
> > > Also, unless
> > > ir-kbd has suddenly improved, this will not work at all for HVR-1950
> > > class devices nor MCE type PVR-24xxx devices (different incompatible IR
> > > receiver).
> >
> > I'm sorry but you can't blame me for ir-kbd-i2c not supporting some
> > devices. I updated the driver to make use of the new binding model, but
> > that's about all I did.
> >
> > > This is why the pvrusb2 driver has never directly attempted to load
> > > ir-kbd.
> >
> > The pvrusb2 driver however abuses the bttv driver's I2C adapter ID
> > (I2C_HW_B_BT848) and was thus affected when ir-kbd-i2c is loaded. This
> > is the only reason why my patch touches the pvrusb2 driver. If you tell
> > me you want the ir-kbd-i2c driver to leave pvrusb2 alone, I can drop
> > all the related changes from my patch, that's very easy.
> 
> Let's keep it simple: add a 'load_ir_kbd_i2c' module option for those 
> drivers that did not autoload this module. The driver author can refine 
> things later (I'll definitely will do that for ivtv).
> 
> It will be interesting if someone can find out whether lirc will work at all 
> once autoprobing is removed from i2c. If it isn't, then perhaps that will 
> wake them up to the realization that they really need to move to the 
> kernel.
> 
> The new mechanism is the right way to do it: the adapter driver has all the 
> information if, where and what IR is used and so should be the one to tell 
> the kernel what to do. Attempting to autodetect and magically figure out 
> what IR might be there is awkward and probably impossible to get right 
> 100%.
> 
> Hell, it's wrong already: if you have another board that already loads 
> ir-kbd-i2c then if you load ivtv or pvrusb2 afterwards you get ir-kbd-i2c 
> whether you like it or not, because ir-kbd-i2c will connect to your i2c 
> adapter like a leech. So with the addition of a module option you at least 
> give back control of this to the user.
> 
> When this initial conversion is done I'm pretty sure we can improve 
> ir-kbd-i2c to make it easier to let the adapter driver tell it what to do. 
> So we don't need those horrible adapter ID tests and other magic that's 
> going on in that driver. But that's phase two.

IMO, doing all those tricks to support an out-of-tree driver is the wrong
approach. This is just postponing a more serious discussion about what should
be done in kernel, in order to better support IR's.

In the case of lirc, the userspace part has already an event interface. If the
drivers are doing the right thing with their IR part, lirc can just use the
event interface for all drivers. This seems to be the proper approach.

>From what I got from Andy and Mike's comments is that the real issue is that
the IR kernel code is incomplete, broken or bad designed. So, several users and
userspace apps don't rely on the kernel code but, instead, use lirc as an
alternative.

That's said, I propose a different approach:

1) Add some entry at feature-removal-schedule.txt posting a date to end support
   for out-of-tree I2C IR modules;

2) Start discussing with lirc people (and input/event maintainers if needed)
about what is needed to properly support the required functionalities for a
better lirc usage;

Re: libv4l: Possibility of changing the current pixelformat on the fly

[Hans de Goede]

On 04/04/2009 10:22 PM, Erik Andrén wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

While trying to get hflip and vflip working for the stv06xx webcam
bridge coupled to the vv6410 sensor I've come across the following
problem.

When flipping the image horizontally, vertically or both, the sensor
pixel ordering changes. In the m5602 driver I was able to compensate
for this in the bridge code. In the stv06xx I don't have this
option. One way of solving this problem is by changing the
pixelformat on the fly, i. e V4L2_PIX_FMT_SGRB8 is the normal
format. When a vertical flip is required, change the format to
V4L2_SBGGR8.

My current understanding of libv4l is that it probes the pixelformat
   upon device open. In order for this to work we would need either
poll the current pixelformat regularly or implement some kind of
notification mechanism upon a flipping request.

What do you think is this the right way to go or is there another
alternative.



The changing of the pixelformat only happens when you flip the data
before conversion. If you look at the current upside down handling
code you will see it does the rotate 180 degrees after conversion.

This is how the vflip / hflip should be handled too. We only have
4 (2 really since we don't care about r versus b / u versus v while
flippiing) destination formats for which we then need to write flipping
code. Otherwise we need to write flipping code for *all* supported input
formats, not to mention flipping some input formats is close to impossible
(JPEG for example).

Regards,

Hans


p.s.

One problem with this approach is that if an apps ask for a native
cam format which is not one which we can also convert to, the
flipping won't work. I think this is best solved by simply not
listing the native formats in the enum-fmt output when the cam
needs flipping.

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [0904_9] Siano: add support for infra-red (IR) controllers

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238697194 -10800
# Node ID 020ba7b31c963bd36d607848198e9e4258a6f80e
# Parent  e8d224d81e2adde182162ab156aa98725e43f5c0
[PATCH] [0904_9] Siano: add support for infra-red (IR) controllers

From: Uri Shkolnik 

This patch add support for IR (infra-red)
remote controllers.
Further commits are needed in order to enable the
activation of the IR components.

Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r e8d224d81e2a -r 020ba7b31c96 linux/drivers/media/dvb/siano/smsir.c
--- /dev/null   Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/dvb/siano/smsir.c Thu Apr 02 21:33:14 2009 +0300
@@ -0,0 +1,301 @@
+/
+
+ Siano Mobile Silicon, Inc.
+ MDTV receiver kernel modules.
+ Copyright (C) 2006-2009, Uri Shkolnik
+
+ This program is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation, either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program.  If not, see .
+
+ /
+
+
+#include 
+#include 
+
+#include "smscoreapi.h"
+#include "smsir.h"
+#include "sms-cards.h"
+
+/* In order to add new IR remote control -
+ * 1) Add it to the  @ smsir,h,
+ * 2) Add its map to keyboard_layout_maps below
+ * 3) Set your board (sms-cards sub-module) to use it
+ */
+
+static struct keyboard_layout_map_t keyboard_layout_maps[] = {
+   [SMS_IR_KB_DEFAULT_TV] = {
+   .ir_protocol = IR_RC5,
+   .rc5_kbd_address = KEYBOARD_ADDRESS_TV1,
+   .keyboard_layout_map = {
+   KEY_0, KEY_1, KEY_2,
+   KEY_3, KEY_4, KEY_5,
+   KEY_6, KEY_7, KEY_8,
+   KEY_9, 0, 0, KEY_POWER,
+   KEY_MUTE, 0, 0,
+   KEY_VOLUMEUP, KEY_VOLUMEDOWN,
+   KEY_BRIGHTNESSUP,
+   KEY_BRIGHTNESSDOWN, KEY_CHANNELUP,
+   KEY_CHANNELDOWN,
+   0, 0, 0, 0, 0, 0, 0, 0,
+   0, 0, 0, 0, 0, 0, 0, 0,
+   0, 0, 0, 0, 0, 0, 0, 0,
+   0, 0, 0, 0, 0, 0, 0, 0,
+   0, 0, 0, 0, 0, 0, 0, 0, 0, 0
+   }
+   },
+   [SMS_IR_KB_HCW_SILVER] = {
+   .ir_protocol = IR_RC5,
+   .rc5_kbd_address = KEYBOARD_ADDRESS_LIGHTING1,
+   .keyboard_layout_map = {
+   KEY_0, KEY_1, KEY_2,
+   KEY_3, KEY_4, KEY_5,
+   KEY_6, KEY_7, KEY_8,
+   KEY_9, KEY_TEXT, KEY_RED,
+   KEY_RADIO, KEY_MENU,
+   KEY_SUBTITLE,
+   KEY_MUTE, KEY_VOLUMEUP,
+   KEY_VOLUMEDOWN, KEY_PREVIOUS, 0,
+   KEY_UP, KEY_DOWN, KEY_LEFT,
+   KEY_RIGHT, KEY_VIDEO, KEY_AUDIO,
+   KEY_MHP, KEY_EPG, KEY_TV,
+   0, KEY_NEXTSONG, KEY_EXIT,
+   KEY_CHANNELUP,  KEY_CHANNELDOWN,
+   KEY_CHANNEL, 0,
+   KEY_PREVIOUSSONG, KEY_ENTER,
+   KEY_SLEEP, 0, 0, KEY_BLUE,
+   0, 0, 0, 0, KEY_GREEN, 0,
+   KEY_PAUSE, 0, KEY_REWIND,
+   0, KEY_FASTFORWARD, KEY_PLAY,
+   KEY_STOP, KEY_RECORD,
+   KEY_YELLOW, 0, 0, KEY_SELECT,
+   KEY_ZOOM, KEY_POWER, 0, 0
+   }
+   },
+   { } /* Terminating entry */
+};
+
+u32 ir_pos;
+u32ir_word;
+u32 ir_toggle;
+
+#define RC5_PUSH_BIT(dst, bit, pos)\
+   { dst <<= 1; dst |= bit; pos++; }
+
+
+static void sms_ir_rc5_event(struct smscore_device_t *coredev,
+ 

[PATCH] [0904_8] Siano: add messages handling for big-endian target

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238696826 -10800
# Node ID e8d224d81e2adde182162ab156aa98725e43f5c0
# Parent  7b5d5a3a7b8e80359e770041ca4c8cf407d893d6
[PATCH] [0904_8] Siano: add messages handling for big-endian target

From: Uri Shkolnik 

Add code that modify the content of Siano's protocol
messages when running with big-endian target.

Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r 7b5d5a3a7b8e -r e8d224d81e2a linux/drivers/media/dvb/siano/smsendian.c
--- /dev/null   Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/dvb/siano/smsendian.c Thu Apr 02 21:27:06 2009 +0300
@@ -0,0 +1,100 @@
+/
+
+ Siano Mobile Silicon, Inc.
+ MDTV receiver kernel modules.
+ Copyright (C) 2006-2009, Uri Shkolnik
+
+ This program is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation, either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program.  If not, see .
+
+ /
+
+#include 
+
+#include "smsendian.h"
+#include "smscoreapi.h"
+
+void smsendian_handle_tx_message(void *buffer)
+{
+#ifdef __BIG_ENDIAN
+   struct SmsMsgData_ST *msg = (struct SmsMsgData_ST *)buffer;
+   int i;
+   int msgWords;
+
+   switch (msg->xMsgHeader.msgType) {
+   case MSG_SMS_DATA_DOWNLOAD_REQ:
+   {
+   msg->msgData[0] = le32_to_cpu(msg->msgData[0]);
+   break;
+   }
+
+   default:
+   msgWords = (msg->xMsgHeader.msgLength -
+   sizeof(struct SmsMsgHdr_ST))/4;
+
+   for (i = 0; i < msgWords; i++)
+   msg->msgData[i] = le32_to_cpu(msg->msgData[i]);
+
+   break;
+   }
+#endif /* __BIG_ENDIAN */
+}
+
+void smsendian_handle_rx_message(void *buffer)
+{
+#ifdef __BIG_ENDIAN
+   struct SmsMsgData_ST *msg = (struct SmsMsgData_ST *)buffer;
+   int i;
+   int msgWords;
+
+   switch (msg->xMsgHeader.msgType) {
+   case MSG_SMS_GET_VERSION_EX_RES:
+   {
+   struct SmsVersionRes_ST *ver =
+   (struct SmsVersionRes_ST *) msg;
+   ver->ChipModel = le16_to_cpu(ver->ChipModel);
+   break;
+   }
+
+   case MSG_SMS_DVBT_BDA_DATA:
+   case MSG_SMS_DAB_CHANNEL:
+   case MSG_SMS_DATA_MSG:
+   {
+   break;
+   }
+
+   default:
+   {
+   msgWords = (msg->xMsgHeader.msgLength -
+   sizeof(struct SmsMsgHdr_ST))/4;
+
+   for (i = 0; i < msgWords; i++)
+   msg->msgData[i] = le32_to_cpu(msg->msgData[i]);
+
+   break;
+   }
+   }
+#endif /* __BIG_ENDIAN */
+}
+
+void smsendian_handle_message_header(void *msg)
+{
+#ifdef __BIG_ENDIAN
+   struct SmsMsgHdr_ST *phdr = (struct SmsMsgHdr_ST *)msg;
+
+   phdr->msgType = le16_to_cpu(phdr->msgType);
+   phdr->msgLength = le16_to_cpu(phdr->msgLength);
+   phdr->msgFlags = le16_to_cpu(phdr->msgFlags);
+#endif /* __BIG_ENDIAN */
+}
+
diff -r 7b5d5a3a7b8e -r e8d224d81e2a linux/drivers/media/dvb/siano/smsendian.h
--- /dev/null   Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/dvb/siano/smsendian.h Thu Apr 02 21:27:06 2009 +0300
@@ -0,0 +1,32 @@
+/
+
+Siano Mobile Silicon, Inc.
+MDTV receiver kernel modules.
+Copyright (C) 2006-2009, Uri Shkolnik
+
+This program is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 2 of the License, or
+(at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program.  If not, see .
+
+/
+
+#ifndef __SMS_ENDIAN_H__
+#define __SMS_ENDIAN_H__
+
+#include 
+
+void smsendian_handle_tx_message(void *buffer);
+void smsendian_handle_rx_message(void *buffer);
+void smsendian_handle_message_header(void *msg);
+
+#endif /* __SMS_ENDIAN_H__ */
+



  
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body

[PATCH] [0904_7] Siano: smsdvb - modify license header and included file list.

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238695774 -10800
# Node ID 7b5d5a3a7b8e80359e770041ca4c8cf407d893d6
# Parent  4a0b207a424af7f05d8eb417a698a82a61dd086f
[PATCH] [0904_7] Siano: smsdvb - modify license header
and included file list.

From: Uri Shkolnik 

smsdvb.c (client for DVB-API v3) - modify license header
and included file list. Removing white spaces.
There are no implementation changes.


Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r 4a0b207a424a -r 7b5d5a3a7b8e linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cThu Apr 02 20:50:24 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smsdvb.cThu Apr 02 21:09:34 2009 +0300
@@ -1,29 +1,40 @@
-/*
- *  Driver for the Siano SMS1xxx USB dongle
- *
- *  Author: Uri Shkolni
- *
- *  Copyright (c), 2005-2008 Siano Mobile Silicon, Inc.
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License version 2 as
- *  published by the Free Software Foundation;
- *
- *  Software distributed under the License is distributed on an "AS IS"
- *  basis, WITHOUT WARRANTY OF ANY KIND, either express or implied.
- *
- *  See the GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
+/
+
+Siano Mobile Silicon, Inc.
+MDTV receiver kernel modules.
+Copyright (C) 2006-2008, Uri Shkolnik
+
+This program is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 2 of the License, or
+(at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program.  If not, see .
+
+/
 
 #include 
 #include 
+#include 
 
 #include "smscoreapi.h"
+/*#include "smsendian.h"*/
 #include "sms-cards.h"
+
+#ifndef DVB_DEFINE_MOD_OPT_ADAPTER_NR
+#define DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr) \
+   static short adapter_nr[] = \
+   {[0 ... (8 - 1)] = -1 }; \
+   module_param_array(adapter_nr, short, NULL, 0444); \
+   MODULE_PARM_DESC(adapter_nr, "DVB adapter numbers")
+#define SMS_DVB_OLD_DVB_REGISTER_ADAPTER
+#endif
 
 DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
@@ -33,15 +44,15 @@ struct smsdvb_client_t {
struct smscore_device_t *coredev;
struct smscore_client_t *smsclient;
 
-   struct dvb_adapter  adapter;
-   struct dvb_demuxdemux;
-   struct dmxdev   dmxdev;
-   struct dvb_frontend frontend;
+   struct dvb_adapter adapter;
+   struct dvb_demux demux;
+   struct dmxdev dmxdev;
+   struct dvb_frontend frontend;
 
-   fe_status_t fe_status;
-   int fe_ber, fe_snr, fe_unc, fe_signal_strength;
+   fe_status_t fe_status;
+   int fe_ber, fe_snr, fe_unc, fe_signal_strength;
 
-   struct completion   tune_done, stat_done;
+   struct completion tune_done, stat_done;
 
/* todo: save freq/band instead whole struct */
struct dvb_frontend_parameters fe_params;
@@ -61,7 +72,7 @@ static int smsdvb_onresponse(void *conte
struct smsdvb_client_t *client = (struct smsdvb_client_t *) context;
struct SmsMsgHdr_ST *phdr = (struct SmsMsgHdr_ST *) (((u8 *) cb->p)
+ cb->offset);
-   u32 *pMsgData = (u32 *)phdr+1;
+   u32 *pMsgData = (u32 *) phdr + 1;
/*u32 MsgDataLen = phdr->msgLength - sizeof(struct SmsMsgHdr_ST);*/
 
/*smsendian_handle_rx_message((struct SmsMsgData_ST *) phdr);*/
@@ -163,22 +174,22 @@ static int smsdvb_onresponse(void *conte
client->fe_status = 0;
}
 
-/*
-   if (client->fe_status & FE_HAS_LOCK)
-   sms_board_dvb3_event(client->coredev, DVB3_EVENT_FE_LOCK);
-   else
-   sms_board_dvb3_event(client->coredev, DVB3_EVENT_FE_UNLOCK);
+   /*
+if (client->fe_status & FE_HAS_LOCK)
+sms_board_dvb3_event(client->coredev, DVB3_EVENT_FE_LOCK);
+else
+sms_board_dvb3_event(client->coredev, DVB3_EVENT_FE_UNLOCK);
 
-   if (client->sms_stat_dvb.ReceptionData.ErrorTSPackets == 0)
-   sms_board_dvb3_event(client->coredev, DVB3_EVENT_UNC_OK);
-   else
-   sms_board_dvb3_event(client->coredev, DVB3_EVENT_UNC_ERR);
-*/
+if (client->sms_stat_dv

[PATCH] [0904_6] Siano: smsdvb - new device status mechanism

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238694624 -10800
# Node ID 4a0b207a424af7f05d8eb417a698a82a61dd086f
# Parent  eb9fed366b2bb2b8a99760f52b9c0e40d72a71e0
siano: smsdvb - new device status mechanism
[PATCH] [0904_6] Siano: smsdvb - new device status mechanism

From: Uri Shkolnik 

This is quite large patch, but it atomic. The patch introduces
new , and much better way to be updated about SMS device status.
Instead of pulling (by submitting statistics_request message),
the driver use the information which is pushed by the device.
Changes are: updated statistics structure (header file) and
the implementation in the smsdvb which use this information.

Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r eb9fed366b2b -r 4a0b207a424a linux/drivers/media/dvb/siano/smscoreapi.h
--- a/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 20:14:17 
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 20:50:24 
2009 +0300
@@ -351,240 +351,203 @@ struct SmsFirmware_ST {
u8 Payload[1];
 };
 
-struct SMSHOSTLIB_STATISTICS_ST {
-   u32 Reserved; /* Reserved */
+/* Statistics information returned as response for
+ * SmsHostApiGetStatistics_Req */
+struct SMSHOSTLIB_STATISTICS_S {
+   u32 Reserved;   /* Reserved */
 
/* Common parameters */
-   u32 IsRfLocked; /* 0 - not locked, 1 - locked */
-   u32 IsDemodLocked; /* 0 - not locked, 1 - locked */
-   u32 IsExternalLNAOn; /* 0 - external LNA off, 1 - external LNA on */
+   u32 IsRfLocked; /* 0 - not locked, 1 - locked */
+   u32 IsDemodLocked;  /* 0 - not locked, 1 - locked */
+   u32 IsExternalLNAOn;/* 0 - external LNA off, 1 - external LNA on */
 
/* Reception quality */
-   s32 SNR; /* dB */
-   u32 BER; /* Post Viterbi BER [1E-5] */
-   u32 FIB_CRC; /* CRC errors percentage, valid only for DAB */
-   /* Transport stream PER, 0x indicate N/A,
-* valid only for DVB-T/H */
-   u32 TS_PER;
-   /* DVB-H frame error rate in percentage,
-* 0x indicate N/A, valid only for DVB-H */
-   u32 MFER;
-   s32 RSSI; /* dBm */
-   s32 InBandPwr; /* In band power in dBM */
-   s32 CarrierOffset; /* Carrier Offset in bin/1024 */
+   s32 SNR;/* dB */
+   u32 BER;/* Post Viterbi BER [1E-5] */
+   u32 FIB_CRC;/* CRC errors percentage, valid only for DAB */
+   u32 TS_PER; /* Transport stream PER,
+   0x indicate N/A, valid only for DVB-T/H */
+   u32 MFER;   /* DVB-H frame error rate in percentage,
+   0x indicate N/A, valid only for DVB-H */
+   s32 RSSI;   /* dBm */
+   s32 InBandPwr;  /* In band power in dBM */
+   s32 CarrierOffset;  /* Carrier Offset in bin/1024 */
 
-   /* Transmission parameters, valid only for DVB-T/H */
-   u32 Frequency; /* Frequency in Hz */
-   u32 Bandwidth; /* Bandwidth in MHz */
-   /* Transmission Mode, for DAB modes 1-4,
-* for DVB-T/H FFT mode carriers in Kilos */
-   u32 TransmissionMode;
-   u32 ModemState; /* from SMS_DvbModemState_ET */
-   u32 GuardInterval; /* Guard Interval, 1 divided by value */
-   u32 CodeRate; /* Code Rate from SMS_DvbModemState_ET */
-   u32 LPCodeRate; /* Low Priority Code Rate from SMS_DvbModemState_ET */
-   u32 Hierarchy; /* Hierarchy from SMS_Hierarchy_ET */
-   u32 Constellation; /* Constellation from SMS_Constellation_ET */
+   /* Transmission parameters */
+   u32 Frequency;  /* Frequency in Hz */
+   u32 Bandwidth;  /* Bandwidth in MHz, valid only for DVB-T/H */
+   u32 TransmissionMode;   /* Transmission Mode, for DAB modes 1-4,
+   for DVB-T/H FFT mode carriers in Kilos */
+   u32 ModemState; /* from SMSHOSTLIB_DVB_MODEM_STATE_ET,
+   valid only for DVB-T/H */
+   u32 GuardInterval;  /* Guard Interval from
+   SMSHOSTLIB_GUARD_INTERVALS_ET,  valid only for DVB-T/H */
+   u32 CodeRate;   /* Code Rate from SMSHOSTLIB_CODE_RATE_ET,
+   valid only for DVB-T/H */
+   u32 LPCodeRate; /* Low Priority Code Rate from
+   SMSHOSTLIB_CODE_RATE_ET, valid only for DVB-T/H */
+   u32 Hierarchy;  /* Hierarchy from SMSHOSTLIB_HIERARCHY_ET,
+   valid only for DVB-T/H */
+   u32 Constellation;  /* Constellation from
+   SMSHOSTLIB_CONSTELLATION_ET, valid only for DVB-T/H */
 
/* Burst parameters, valid only for DVB-H */
-   u32 BurstSize; /* Current burst size in bytes */
-   u32 BurstDuration; /* Current burst duration in mSec */
-   u32 BurstCycleTime; /* Current burst cycle time in mSec */
-   u32 CalculatedBurstCycleTime; /* Current burst cycle time in mSec,
-* as calculated by demodulator */
-   u32 NumOfRows; /* Number of rows in MPE table */
-   u32 NumOfPaddCols; /* Numb

[PATCH] [0904_5] Siano: core header - indentation

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238692457 -10800
# Node ID eb9fed366b2bb2b8a99760f52b9c0e40d72a71e0
# Parent  83b19eba46dd4f8253d02c26db4f42728d60e28f
[PATCH] [0904_5] Siano: core header - indentation

From: Uri Shkolnik 

Some more indentation for the smscoreapi.h
There are no implementation changes in this patch.

Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r 83b19eba46dd -r eb9fed366b2b linux/drivers/media/dvb/siano/smscoreapi.h
--- a/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 20:07:49 
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 20:14:17 
2009 +0300
@@ -55,14 +55,14 @@ along with this program.  If not, see msgType = type; (ptr)->msgSrcId = src; (ptr)->msgDstId = dst; \
(ptr)->msgLength = len; (ptr)->msgFlags = 0; \
 } while (0)
+
 #define SMS_INIT_MSG(ptr, type, len) \
SMS_INIT_MSG_EX(ptr, type, 0, HIF_TASK, len)
+
 enum SMS_DVB3_EVENTS {
DVB3_EVENT_INIT = 0,
DVB3_EVENT_SLEEP,
@@ -324,11 +324,12 @@ struct SmsVersionRes_ST {
u8 Step; /* 0 - Step A */
u8 MetalFix; /* 0 - Metal 0 */
 
-   u8 FirmwareId; /* 0xFF � ROM, otherwise the
-* value indicated by
-* SMSHOSTLIB_DEVICE_MODES_E */
-   u8 SupportedProtocols; /* Bitwise OR combination of
+   /* FirmwareId 0xFF if ROM, otherwise the
+* value indicated by SMSHOSTLIB_DEVICE_MODES_E */
+   u8 FirmwareId;
+   /* SupportedProtocols Bitwise OR combination of
 * supported protocols */
+   u8 SupportedProtocols;
 
u8 VersionMajor;
u8 VersionMinor;
@@ -362,10 +363,12 @@ struct SMSHOSTLIB_STATISTICS_ST {
s32 SNR; /* dB */
u32 BER; /* Post Viterbi BER [1E-5] */
u32 FIB_CRC; /* CRC errors percentage, valid only for DAB */
-   u32 TS_PER; /* Transport stream PER, 0x indicate N/A,
+   /* Transport stream PER, 0x indicate N/A,
 * valid only for DVB-T/H */
-   u32 MFER; /* DVB-H frame error rate in percentage,
+   u32 TS_PER;
+   /* DVB-H frame error rate in percentage,
 * 0x indicate N/A, valid only for DVB-H */
+   u32 MFER;
s32 RSSI; /* dBm */
s32 InBandPwr; /* In band power in dBM */
s32 CarrierOffset; /* Carrier Offset in bin/1024 */
@@ -373,8 +376,9 @@ struct SMSHOSTLIB_STATISTICS_ST {
/* Transmission parameters, valid only for DVB-T/H */
u32 Frequency; /* Frequency in Hz */
u32 Bandwidth; /* Bandwidth in MHz */
-   u32 TransmissionMode; /* Transmission Mode, for DAB modes 1-4,
+   /* Transmission Mode, for DAB modes 1-4,
 * for DVB-T/H FFT mode carriers in Kilos */
+   u32 TransmissionMode;
u32 ModemState; /* from SMS_DvbModemState_ET */
u32 GuardInterval; /* Guard Interval, 1 divided by value */
u32 CodeRate; /* Code Rate from SMS_DvbModemState_ET */



  
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [0904_3] Siano: core - move and update the main core structure declaration

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238691361 -10800
# Node ID 19925582e5dded86fccce7d8c9965285c1240836
# Parent  05cf6606192642241ff25a152e249118cb8a129b
[PATCH] [0904_3] Siano: core - move and update the main core structure 
declaration

From: Uri Shkolnik 

smscoreapi - move the main core structure declaration
to the header, in order to enable other components
(such as IR) to use it.

Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r 05cf66061926 -r 19925582e5dd linux/drivers/media/dvb/siano/smscoreapi.c
--- a/linux/drivers/media/dvb/siano/smscoreapi.cThu Apr 02 19:47:39 
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.cThu Apr 02 19:56:01 
2009 +0300
@@ -56,42 +56,6 @@ struct smscore_client_t {
struct list_headidlist;
onresponse_tonresponse_handler;
onremove_t  onremove_handler;
-};
-
-struct smscore_device_t {
-   struct list_head entry;
-
-   struct list_head clients;
-   struct list_head subclients;
-   spinlock_t  clientslock;
-
-   struct list_head buffers;
-   spinlock_t  bufferslock;
-   int num_buffers;
-
-   void*common_buffer;
-   int common_buffer_size;
-   dma_addr_t  common_buffer_phys;
-
-   void*context;
-   struct device   *device;
-
-   chardevpath[32];
-   unsigned long   device_flags;
-
-   setmode_t   setmode_handler;
-   detectmode_tdetectmode_handler;
-   sendrequest_t   sendrequest_handler;
-   preload_t   preload_handler;
-   postload_t  postload_handler;
-
-   int mode, modes_supported;
-
-   struct completion version_ex_done, data_download_done, trigger_done;
-   struct completion init_device_done, reload_start_done, resume_done;
-
-   int board_id;
-   int led_state;
 };
 
 void smscore_set_board_id(struct smscore_device_t *core, int id)
diff -r 05cf66061926 -r 19925582e5dd linux/drivers/media/dvb/siano/smscoreapi.h
--- a/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 19:47:39 
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 19:56:01 
2009 +0300
@@ -128,6 +128,60 @@ struct smsclient_params_t {
onremove_t  onremove_handler;
 
void*context;
+};
+
+struct smscore_device_t {
+   struct list_head entry;
+
+   struct list_head clients;
+   struct list_head subclients;
+   spinlock_t clientslock;
+
+   struct list_head buffers;
+   spinlock_t bufferslock;
+   int num_buffers;
+
+   void *common_buffer;
+   int common_buffer_size;
+   dma_addr_t common_buffer_phys;
+
+   void *context;
+   struct device *device;
+
+   char devpath[32];
+   unsigned long device_flags;
+
+   setmode_t setmode_handler;
+   detectmode_t detectmode_handler;
+   sendrequest_t sendrequest_handler;
+   preload_t preload_handler;
+   postload_t postload_handler;
+
+   int mode, modes_supported;
+
+   /* host <--> device messages */
+   struct completion version_ex_done, data_download_done, trigger_done;
+   struct completion init_device_done, reload_start_done, resume_done;
+   struct completion gpio_configuration_done, gpio_set_level_done;
+   struct completion gpio_get_level_done, ir_init_done;
+
+   /* Buffer management */
+   wait_queue_head_t buffer_mng_waitq;
+
+   /* GPIO */
+   int gpio_get_res;
+
+   /* Target hardware board */
+   int board_id;
+
+   /* Firmware */
+   u8 *fw_buf;
+   u32 fw_buf_size;
+
+   /* Infrared (IR) */
+   /* struct ir_t ir; */
+
+   int led_state;
 };
 
 /* GPIO definitions for antenna frequency domain control (SMS8021) */



  
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [0904_2] Siano: core header - add definitions and structures

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238690859 -10800
# Node ID 05cf6606192642241ff25a152e249118cb8a129b
# Parent  c3f0f50d46058f07fb355d8e5531f35cfd0ca37e
[PATCH] [0904_2] Siano: core header - add definitions and structures

From: Uri Shkolnik 

Add new definitions (of Siano's protocol messages),
and protocol structures (for future commits usage)

Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r c3f0f50d4605 -r 05cf66061926 linux/drivers/media/dvb/siano/smscoreapi.h
--- a/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 19:32:10 
2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 19:47:39 
2009 +0300
@@ -55,6 +55,7 @@ along with this program.  If not, see msgType = type; (ptr)->msgSrcId = src; (ptr)->msgDstId = dst; \
@@ -206,6 +215,15 @@ struct smsclient_params_t {
 } while (0)
 #define SMS_INIT_MSG(ptr, type, len) \
SMS_INIT_MSG_EX(ptr, type, 0, HIF_TASK, len)
+enum SMS_DVB3_EVENTS {
+   DVB3_EVENT_INIT = 0,
+   DVB3_EVENT_SLEEP,
+   DVB3_EVENT_HOTPLUG,
+   DVB3_EVENT_FE_LOCK,
+   DVB3_EVENT_FE_UNLOCK,
+   DVB3_EVENT_UNC_OK,
+   DVB3_EVENT_UNC_ERR
+};
 
 enum SMS_DEVICE_MODE {
DEVICE_MODE_NONE = -1,
@@ -230,8 +248,13 @@ struct SmsMsgHdr_ST {
 };
 
 struct SmsMsgData_ST {
-   struct SmsMsgHdr_ST xMsgHeader;
-   u32 msgData[1];
+   struct SmsMsgHdr_ST xMsgHeader;
+   u32 msgData[1];
+};
+
+struct SmsMsgData_ST2 {
+   struct SmsMsgHdr_ST xMsgHeader;
+   u32 msgData[2];
 };
 
 struct SmsDataDownload_ST {



  
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [0904_1] Siano: core header - update license and include files

[Uri Shkolnik]

# HG changeset patch
# User Uri Shkolnik 
# Date 1238689930 -10800
# Node ID c3f0f50d46058f07fb355d8e5531f35cfd0ca37e
# Parent  7311d23c3355629b617013cd51223895a2423770
[PATCH] [0904_1] Siano: core header - update license and included files

From: Uri Shkolnik 

This patch does not include any implementation changes.
It update the smscoreapi.h license to be identical to 
other Siano's headers and the #include files list.


Priority: normal

Signed-off-by: Uri Shkolnik 

diff -r 7311d23c3355 -r c3f0f50d4605 linux/drivers/media/dvb/siano/smscoreapi.h
--- a/linux/drivers/media/dvb/siano/smscoreapi.hSun Mar 15 12:05:57 
2009 +0200
+++ b/linux/drivers/media/dvb/siano/smscoreapi.hThu Apr 02 19:32:10 
2009 +0300
@@ -1,26 +1,26 @@
-/*
- *  Driver for the Siano SMS1xxx USB dongle
- *
- *  author: Anatoly Greenblat
- *
- *  Copyright (c), 2005-2008 Siano Mobile Silicon, Inc.
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License version 2 as
- *  published by the Free Software Foundation;
- *
- *  Software distributed under the License is distributed on an "AS IS"
- *  basis, WITHOUT WARRANTY OF ANY KIND, either express or implied.
- *
- *  See the GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
+/
 
-#ifndef __smscoreapi_h__
-#define __smscoreapi_h__
+Siano Mobile Silicon, Inc.
+MDTV receiver kernel modules.
+Copyright (C) 2006-2008, Uri Shkolnik, Anatoly Greenblat
+
+This program is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 2 of the License, or
+(at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program.  If not, see .
+
+/
+
+#ifndef __SMS_CORE_API_H__
+#define __SMS_CORE_API_H__
 
 #include 
 #include 
@@ -28,15 +28,23 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+
 #include 
-#include 
-#include "compat.h"
 
+/* #include "smsir.h" */
+
+#define SMS_DVB3_SUBSYS
+#ifdef SMS_DVB3_SUBSYS
 #include "dmxdev.h"
 #include "dvbdev.h"
 #include "dvb_demux.h"
 #include "dvb_frontend.h"
 
+#endif
 
 #define kmutex_init(_p_) mutex_init(_p_)
 #define kmutex_lock(_p_) mutex_lock(_p_)
@@ -598,4 +606,4 @@ int smscore_led_state(struct smscore_dev
dprintk(KERN_DEBUG, DBG_ADV, fmt, ##arg)
 
 
-#endif /* __smscoreapi_h__ */
+#endif /* __SMS_CORE_API_H__ */



  
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html