[PATCH] sh_mobile_ceu_camera: Add physical address alignment checks V2

[Magnus Damm]

From: Magnus Damm 

Make sure physical addresses are 32-bit aligned in the SuperH
Mobile CEU driver V2. The lowest two bits of the frame address
registers are fixed to zero so frame buffers have to be 32-bit
aligned. The V4L2 mmap() case is using dma_alloc_coherent() for
this driver which will return already aligned addresses, but in
the USERPTR case we must make sure that the user space pointer
is valid.

Signed-off-by: Magnus Damm 
---

 Tested with a hacked up capture.c on a sh7722 Migo-R board.

 V2 moves the checks to sh_mobile_ceu_videobuf_prepare()

 drivers/media/video/sh_mobile_ceu_camera.c |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

--- 0010/drivers/media/video/sh_mobile_ceu_camera.c
+++ work/drivers/media/video/sh_mobile_ceu_camera.c 2009-12-11 
16:52:19.0 +0900
@@ -339,7 +339,7 @@ static int sh_mobile_ceu_videobuf_prepar
}
 
vb->size = vb->width * vb->height * ((buf->fmt->depth + 7) >> 3);
-   if (0 != vb->baddr && vb->bsize < vb->size) {
+   if (0 != vb->baddr && vb->bsize < vb->size && !(vb->width & 3)) {
ret = -EINVAL;
goto out;
}
@@ -348,6 +348,13 @@ static int sh_mobile_ceu_videobuf_prepar
ret = videobuf_iolock(vq, vb, NULL);
if (ret)
goto fail;
+
+   /* the physical address must be 32-bit aligned (USERPTR) */
+   if (videobuf_to_dma_contig(vb) & 3) {
+   ret = -EINVAL;
+   goto fail;
+   }
+
vb->state = VIDEOBUF_PREPARED;
}
 
--
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,

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

for the following 2 changesets:

01/02: gspca - some subdrivers: Make device_table[]s constant.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=0ba73f8e8517

02/02: gspca - ov534: Fix a compilation warning.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=612a98aa8eec


 conex.c   |4 ++--
 etoms.c   |4 ++--
 ov534.c   |2 +-
 pac7302.c |4 ++--
 pac7311.c |4 ++--
 sonixb.c  |4 ++--
 spca506.c |4 ++--
 7 files changed, 13 insertions(+), 13 deletions(-)

Thanks.

-- 
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: [linux-dvb] Hauppauge PVR-150 Vertical sync issue?

[Andy Walls]

On Thu, 2009-12-10 at 11:56 -0500, Robert Longfield wrote:
> Ok I've been able to do some troubleshooting with some interesting results.
> I removed the one splitter being used, connected to the main cable
> coming into the house, isolated the grounds with no change in sync
> issues.
> I pulled the pvr-150 card out of the linux machine and put it into my
> window box, hooked it up to the original setup splitter and no ground
> isolation and the video is crystal clear with no sync issues.
> 
> I can only come up with a few possible problems, but I am sure there are more.
> Could this be a driver issue on my linux box?

Given your results, yes it is most likely a linux driver issue.  The
suspects would be the cx25840 module, or the modules for the analog
tuner.

What analog tuner assembly type does the tveeprom module show for your
card in dmesg?

Also what video standard are you capturing: NTSC or something else?


> Could a bad or failing PCI slot cause this problem?

No.  A *very* busy PCI bus may cause some I2C transactions that set up
the tuner or CX25843 to fail, but it is more likely simply a suboptimal
tuner or CX25843 configuration issue.


> However the sync
> problem is not on every channel.
> 
> I'm going to try moving the linux box across the house to see if there
> is a source of EMI near by, but since the windows box doesn't have
> this issue I assume this is a problem with the linux box.

I suppose you could try a linux liveCD in the Windows box and use

$ cat /dev/video0 > foo.mpg

to capture video.  Then move foo.mpg to a USB flash disk and play back
foo.mpg where ever it is convenient.  If foo.mpg shows artifacts then
you can be somewhat sure of a linux driver issue.


> -Rob
> 
> On Tue, Nov 24, 2009 at 6:43 PM, Andy Walls  wrote:
> > On Tue, 2009-11-24 at 13:05 -0500, Robert Longfield wrote:
> >> I have a PVR-150 card running on mythbuntu 9 and it appears that my
> >> card is suffering a vertical (and possibly a horizontal) sync issue.
> >>
> >> The video jumps around, shifts from side to side, up and down and when
> >> it shifts the video wraps. I'm including a link to a screen shot
> >> showing the vertical sync problem
> >>
> >> http://imagebin.ca/view/6fS-14Yi.html
> >
> > It looks like you have strong singal reflections in your cable due to
> > impedance mismatches, a bad splitter, a bad cable or connector, etc.
> >
> > Please read:
> >
> > http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality
> >
> > and take steps to ensure you've got a good cabling plant in your home.
> >
> > Regards,
> > Andy
> >
> >> This is pretty tame to what happens sometimes. I haven't noticed this
> >> on all channels as we are mostly using this to record shows for my
> >> son.
> >>
> >> Here is my setup. Pentium 4 2 Ghz with a gig of ram. 40 gig OS drive,
> >> 150 gig drive for recording, 250 gig drive for backup and storage, a
> >> dvd-burner.
> >> The 150 gig drive is on a Promise Ultra133 TX2 card but exhibits no
> >> issues on reads or writes.
> >> I have cable connected to the internal tuner of my PVR-150 card and
> >> S-video from an Nvidia card (running Nvidea drivers) out to the TV.
> >>
> >> I don't know what else I can provide to help out but let me know and
> >> I'll get it.
> >>
> >> Thanks,
> >> -Rob


--
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] uvcvideo: add another YUYV format GUID

[Daniel Ritz]

On 11.12.2009 02:21, Laurent Pinchart wrote:
> On Thursday 10 December 2009 17:34:25 Daniel Ritz wrote:
>> On Thu, 2009-12-10 at 02:46 +0100, Laurent Pinchart wrote:
>>> Hi Daniel,
>>>
>>> On Friday 04 December 2009 03:05:37 Daniel Ritz wrote:
 Hi Laurent

 On Thu, 2009-12-03 at 21:15 +0100, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday 02 December 2009 00:48:44 Daniel Ritz wrote:
>> For some unknown reason, on a MacBookPro5,3 the iSight
>
> Could you please send me the output of lsusb -v both with the correct
> and wrong GUID ?

 sure. i attached three files:
   isight-good.txt, isight-bad.txt, isight-good2.txt

 this is three reboots in a row from like 10 minutes ago. the first
 boot into linux was actually rebooting from OSX...first cold boot
 today directly into linux had the right GUID.
>>>
>>> Thanks. diff'ing the descriptors shows something interesting (from good
>>> to good2):
>>>
>>> @@ -264,7 +264,7 @@
>>>  dwMaxVideoFrameBufferSize  614400
>>>  dwDefaultFrameInterval 33
>>>  bFrameIntervalType 11
>>> -dwFrameInterval( 0) 3758429717
>>> +dwFrameInterval( 0)33
>>>  dwFrameInterval( 1)363636
>>>  dwFrameInterval( 2)40
>>>  dwFrameInterval( 3)44
>>>
>>> 3758429717 is 0xe0051615 in hex, and 33 is 0x00051615.
>>>
>>> I wonder what other parts of the descriptors could get corrupted that
>>> way.
>>
>> hmm..dunno..but even with this it just worked.
>>
>> _sometimes_ report a different video format GUID.
>
> Sometimes only ? Now that's weird. Is that completely random ?

 yes, sometimes only. it seems to be related to reboots, but i don't
 know what exactly triggers it. rmmod/modprobe doesn't trigger it.
 also, when the wrong GUID is reported, the only way of fixing it is
 to reboot. it really is just the GUID. even when the wrong one is
 reported, the device works just fine.

 i started with a plain ubuntu 9.10, kernel 2.6.31 which was supposed
 to fail, so i upgraded to a 2.6.32-rc8 to fix the iSight and some other
 things, just to see it fail again. a reboot later and it worked, some
 time and reboot later it failed again...
>>>
>>> All of those are warm reboots, and you don't boot any alternative OS in-
>>> between, right ?
>>
>> yes, linux only.
>>
>>> Does Linux reload the iSight firmware at every boot ? If it does, could
>>> you try to reload the firmware manually when you get a "bad" GUID to see
>>> if it helps ? You will probably need to unload the uvcvideo driver before
>>> reloading the firmware.
>>
>> linux does not load isight firmware at all. the new macbooks don't
>> require to load FW the device just "works".
>> FW loading is only required for the devices with ID 0x05AC:0x8300,
>> what i have is 05ac:8507
> 
> Ok, thanks for the information.
> 
> I guess the camera is really broken. As MacOSX probably doesn't even try to 
> parse the USB descriptors, the Apple developers never noticed.
> 
> Anyway, I'll apply your patch. Can I still keep your SoB line if I rename 
> YUY2_2 to YUY2_ISIGHT ?

sure.

thanks, rgds
-daniel


--
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://kernellabs.com/hg/~mkrufky/build-fix

[Michael Krufky]

Mauro,

Backwards compat got broken a few weeks ago... Please pull for the fix.

Please pull from:

http://kernellabs.com/hg/~mkrufky/build-fix

for:

- saa7134: fix build against older kernels

 saa7134-input.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Cheers,

Mike
--
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: TveiiS470 and DVBWorld2005 not working

[Guillem Solà]

Guillem Solà wrote:

Hi,

I come to this list as my last resort. I have two DVB-S PCIE cards and 
no one can get channels, but I have another computer with a PCI 
SAA7146 that can get 1400 services from same dish.


* Tveii S470 *

One is the Tveii S470. I guess that the S470 should work because you 
are working in IR support.


I have tried V4L tip, drivers from website, from website and patched 
like in wiki says... but all I get is:


scandvb -a 0 /usr/share/dvb-apps/dvb-s/Astra-19.2E

scanning /usr/share/dvb-apps/dvb-s/Astra-19.2E
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder 12551500 V 2200 5
>>> tune to: 12551:v:0:22000
WARNING: filter timeout pid 0x0011
WARNING: filter timeout pid 0x
WARNING: filter timeout pid 0x0010it's going on

dumping lists (0 services)

Done.


* DVBWorld 2005 *

The other is the DVBWorld DVB-S2 2005. I have tried also latest V4l, 
liplianin branch... and I get the same: 0 services.



The hardware were I'm trying to run this is a Dell 1 unit Rack Server 
with RHEL with kernels 2.6.30, 2.6.31 and 2.6.32 patched by myself.


As I said I have another computer with a PCI dvb-s card that can get 
lot of channels so I thing that the disk is working well.



Any idea about what's going on?

Thanks in advance,

Guillem Solà

Sorry for the noise,

The sooner I wrote the email, the sooner my TeviiS470 started to work!

I did it work with the latest s2-liplianin tip, of course firmwares were 
in /lib/firmware dir.


Now I'm doing some compatibility tests. As I said I can get a few less 
channels than with the saa7164 that I'm using in old computers.


My aim is to certify it for the company I work for, so if there is 
something I could do testing it to help the community, I could do it 
during my work journey.


regards,

Guillem
--
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

dib0700: Nova-T-500 remote - mixed button codes

[Antonio Marcos López Alonso]

Hi all,

I own a Hauppauge Nova-T-500 in a box running Mythbuntu 9.10. The card runs 
fine except when it comes to the in-built remote sensor: 

Whenever I press any button, the remote sensor seems to receive some other 
keycodes aside the proper one (i.e. when I press Volume Up button the sensor 
receives it most of the time, but sometimes it understands some other buttons 
are pressed like ArrowDown, Red button and so, making MythTV experience very 
annoying). There are only three buttons that are always well received with no 
confusion at all: "OK", "ArrowDown" and "Play". This behavior occurs with two 
identical remotes I own (one of them belonging to a WinTV HVR-1100) and 
another card user has reported a similar behavior with its own and same 
remote.

I tested both remotes with the HVR-1100 and they behave perfectly, so I guess 
this is not a remote related issue.

Though I have tried several LIRC setup files and swapped dvb_usb_dib0700 
firmware files (1.10 and 1.20 versions) they make no working difference at 
all.

I also tried rebuilding v4l-dvb code to no avail.

Any suggestions? I would gladly provide further info/logs upon request.

Cheers,
Antonio
--
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

New ASUS P3-100 DVB-T/DVB-S device (1043:48cd)

[dvblinux]

Hi all, I'm new on this list.

I modified on my own the SAA driver to manage an ASUS PS3-100 combo card not
supported yet in current version.

It features two DVB-S and DVB-T receivers packed on the same PCI card.

The DVB-T part is identical to ASUS P7131 Hybrid and therefore is managed thru
the existing driver after a light patch in the driver source (and card.c):
copying relevant stuff from (1043:4876) to (1043:48cd).

I'm not a developper, how to share my successfull experiments ?

Regards.

--
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

dib0700: Nova-T-500 remote - mixed button codes

[Antonio Marcos López Alonso]

Hi all,

I own a Hauppauge Nova-T-500 in a box running Mythbuntu 9.10. The card runs 
fine except when it comes to the in-built remote sensor: 

Whenever I press any button, the remote sensor seems to receive some other 
keycodes aside the proper one (i.e. when I press Volume Up button the sensor 
receives it most of the time, but sometimes it understands some other buttons 
are pressed like ArrowDown, Red button and so, making MythTV experience very 
annoying). There are only three buttons that are always well received with no 
confusion at all: "OK", "ArrowDown" and "Play". This behavior occurs with two 
identical remotes I own (one of them belonging to a WinTV HVR-1100) and 
another card user has reported a similar behavior with its own and same 
remote.

I tested both remotes with the HVR-1100 and they behave perfectly, so I guess 
this is not a remote related issue.

Though I have tried several LIRC setup files and swapped dvb_usb_dib0700 
firmware files (1.10 and 1.20 versions) they make no working difference at 
all.

I also tried rebuilding v4l-dvb code to no avail.

Any suggestions? I would gladly provide further info/logs upon request.

Cheers,
Antonio
--
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: dib0700: Nova-T-500 remote - mixed button codes

[Rochet, Christophe]

Hi Antonio.

Did you switched also the IR remote sensor itself ?

I experienced same weird things with a WinovaTV years ago, and finally the IR 
phototransistor in the small round receiver was crappy.
When I changed it by a common spare it all came right.

Protect also your IR sensor from AC lights...

If you experiment "random" keys, a noisy IR signal or dead receiver is perhaps 
the cause.

If you experiment always the same button jam, that's something else.

Regards.

-Message d'origine-
De : linux-media-ow...@vger.kernel.org 
[mailto:linux-media-ow...@vger.kernel.org] De la part de Antonio Marcos López 
Alonso
Envoyé : vendredi 11 décembre 2009 16:10
À : linux-media@vger.kernel.org
Objet : dib0700: Nova-T-500 remote - mixed button codes

Hi all,

I own a Hauppauge Nova-T-500 in a box running Mythbuntu 9.10. The card runs 
fine except when it comes to the in-built remote sensor: 

Whenever I press any button, the remote sensor seems to receive some other 
keycodes aside the proper one (i.e. when I press Volume Up button the sensor 
receives it most of the time, but sometimes it understands some other buttons 
are pressed like ArrowDown, Red button and so, making MythTV experience very 
annoying). There are only three buttons that are always well received with no 
confusion at all: "OK", "ArrowDown" and "Play". This behavior occurs with two 
identical remotes I own (one of them belonging to a WinTV HVR-1100) and 
another card user has reported a similar behavior with its own and same 
remote.

I tested both remotes with the HVR-1100 and they behave perfectly, so I guess 
this is not a remote related issue.

Though I have tried several LIRC setup files and swapped dvb_usb_dib0700 
firmware files (1.10 and 1.20 versions) they make no working difference at 
all.

I also tried rebuilding v4l-dvb code to no avail.

Any suggestions? I would gladly provide further info/logs upon request.

Cheers,
Antonio
--
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
--
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] V4L/DVB: lgs8gxx: Use shifts rather than multiply/divide when possible

[David Howells]

If val is a u64, then following:

val *= (u64)1 << 32;
val /= (u64)1 << 32;

should surely be better represented as:

val <<= 32;
val >>= 32;

Especially as, for the division, the compiler might want to actually do a
division:

drivers/built-in.o: In function `lgs8gxx_get_afc_phase':
drivers/media/dvb/frontends/lgs8gxx.c:250: undefined reference to `__udivdi3'

Signed-off-by: David Howells 
---

 drivers/media/dvb/frontends/lgs8gxx.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


diff --git a/drivers/media/dvb/frontends/lgs8gxx.c 
b/drivers/media/dvb/frontends/lgs8gxx.c
index eabcadc..dee5396 100644
--- a/drivers/media/dvb/frontends/lgs8gxx.c
+++ b/drivers/media/dvb/frontends/lgs8gxx.c
@@ -199,7 +199,7 @@ static int lgs8gxx_set_if_freq(struct lgs8gxx_state *priv, 
u32 freq /*in kHz*/)
 
val = freq;
if (freq != 0) {
-   val *= (u64)1 << 32;
+   val <<= 32;
if (if_clk != 0)
do_div(val, if_clk);
v32 = val & 0x;
@@ -246,7 +246,7 @@ static int lgs8gxx_get_afc_phase(struct lgs8gxx_state *priv)
 
val = v32;
val *= priv->config->if_clk_freq;
-   val /= (u64)1 << 32;
+   val >>= 32;
dprintk("AFC = %u kHz\n", (u32)val);
return 0;
 }

--
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: TveiiS470 and DVBWorld2005 not working

[Guillem Solà]

Guillem Aranda wrote:

Sorry for the noise,

The sooner I wrote the email, the sooner my TeviiS470 started to work!

I did it work with the latest s2-liplianin tip, of course firmwares 
were in /lib/firmware dir.


Now I'm doing some compatibility tests. As I said I can get a few less 
channels than with the saa7164 that I'm using in old computers.


My aim is to certify it for the company I work for, so if there is 
something I could do testing it to help the community, I could do it 
during my work journey.


regards,

Guillem


On Thu, Dec 10, 2009 at 7:35 PM, Igor M. Liplianin > wrote:


On 10 декабря 2009 18:47:09 Guillem Solà wrote:
> Hi,
>
> I come to this list as my last resort. I have two DVB-S PCIE
cards and
> no one can get channels, but I have another computer with a PCI
SAA7146
> that can get 1400 services from same dish.
>
> * Tveii S470 *
>
> One is the Tveii S470. I guess that the S470 should work because
you are
> working in IR support.
>
> I have tried V4L tip, drivers from website, from website and patched
> like in wiki says... but all I get is:
>
> scandvb -a 0 /usr/share/dvb-apps/dvb-s/Astra-19.2E
>
> scanning /usr/share/dvb-apps/dvb-s/Astra-19.2E
> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
> initial transponder 12551500 V 2200 5
>
>  >>> tune to: 12551:v:0:22000
>
> WARNING: filter timeout pid 0x0011
> WARNING: filter timeout pid 0x
> WARNING: filter timeout pid 0x0010it's going on
>
> dumping lists (0 services)
>
> Done.
>
>
> * DVBWorld 2005 *
>
> The other is the DVBWorld DVB-S2 2005. I have tried also latest V4l,
> liplianin branch... and I get the same: 0 services.
>
>
> The hardware were I'm trying to run this is a Dell 1 unit Rack
Server
> with RHEL with kernels 2.6.30, 2.6.31 and 2.6.32 patched by myself.
>
> As I said I have another computer with a PCI dvb-s card that can
get lot
> of channels so I thing that the disk is working well.
>
>
> Any idea about what's going on?
Hi Guillem,
I think you are missing firmwares, though you give too little
information.

>
> Thanks in advance,
>
> Guillem Solà
> --
> 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

--
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks



Hi,

I have been testing my TeviiS470 against the saa7164 and basically what 
I get is that the signal and s/n ratio is lower tuning from the same 
dish with TeviiS470.


For example tuning the same channel on each one and comparing the femon 
output:


On saa7164 AragonTv from Astra works well

FE: ST STV0299 DVB-S (SAT)
status 1f | signal e600 | snr edba | ber  | unc  | 
FE_HAS_LOCK
status 1f | signal e4c0 | snr ed84 | ber  | unc  | 
FE_HAS_LOCK
status 1f | signal e73e | snr ed5a | ber  | unc  | 
FE_HAS_LOCK
status 1f | signal e607 | snr ed0c | ber  | unc  | 
FE_HAS_LOCK
status 1f | signal e608 | snr ee02 | ber  | unc  | 
FE_HAS_LOCK
status 1f | signal e607 | snr edf3 | ber  | unc  | 
FE_HAS_LOCK


On TeviiS470 the same channel have some problems :

FE: Montage Technology DS3000/TS2020 (SAT)
status 1f | signal 9088 | snr 51e0 | ber  | unc 1010 | 
FE_HAS_LOCK
status 1f | signal 9088 | snr 51e0 | ber 3f67 | unc 5669 | 
FE_HAS_LOCK
status 1f | signal 9088 | snr 51e0 | ber 400e | unc 56ed | 
FE_HAS_LOCK

status 00 | signal 9088 | snr 51e0 | ber 3f84 | unc 56ec |
status 1f | signal 9088 | snr 51e0 | ber 3ebb | unc 56cb | 
FE_HAS_LOCK
status 1f | signal 9088 | snr 51e0 | ber 4057 | unc 5507 | 
FE_HAS_LOCK
status 1f | signal 9088 | snr 51e0 | ber 4083 | unc 56d1 | 
FE_HAS_LOCK
status 1f | signal 9088 | snr 51e0 | ber 3e63 | unc 56bc | 
FE_HAS_LOCK
status 1f | signal 9088 | snr 51e0 | ber 3fe9 | unc 56be | 
FE_HAS_LOCK




Here femon output of a channel that works better than the last one

FE: Montage Technology DS3000/TS2020 (SAT)
status 1f | signal 9088 | snr 7ad0 | ber 02dc | unc  | 
FE_HAS_LOCK
status 1f | signal 9088 | snr 7ad0 | ber 024a | unc  | 
FE_HAS_LOCK
status 1f | signal 9088 | snr 8f48 | ber 0262 | unc  | 
FE_HAS_LOCK
status 1f | signal 9088 | snr 8f48 | ber 0314 | unc  | 
FE_HAS_LOCK
status 1f | signal 9088 | snr 8f48 | ber 02db | unc  | 
FE_HAS_LOCK
status 1f | signal 9088 | snr 8f48 | ber 02ed | unc  | 
FE_HAS_LOCK
status 1f | signal 9088 | snr 8f48 | ber 03a3 | unc  | 
FE_HAS_L

Re: soc_camera: OV2640

[Alan Carvalho de Assis]

Hi Guennadi,

On 12/8/09, Alan Carvalho de Assis  wrote:
> Hi Guennadi,
...
>>> I am trying to use an OV2640 camera with soc_camera.
>>>
>>> I'm using ov772x driver as base, but it needs too much modification to
>>> work with ov2640.
>>
>> I don't know that sensor specifically, but they can be quite different.
>>
>
> Yes, in fact ov2640 appears quite different compared to ov772x and ov9640.
>
>>> The OV2640 chip remaps all registers when register 0xFF is 1 or when it
>>> is
>>> 0.
>>
>> This is not unusual. There are a few ways to implement this, for example,
>> drivers/media/video/rj54n1cb0c.c uses 16-bit addresses, and decodes them
>> to bank:register pairs in its reg_read() and reg_write() routines.
>>
>
> Ok, I will try to implement it this way, case nobody suggests me a
> better approach.
>

I got mx27_camera from pengutronix tree and modified it to work with
kernel 2.6.32 (few modifications). I added platform data/device on my
board using pcm970-baseboard.c as example.

In the kernel config I selected:
CONFIG_VIDEO_MX27
CONFIG_SOC_CAMERA_OV9640


I noticed a strange behavior: the ov9640 driver is called before mx27_camera:

Linux video capture interface: v2.00
>>> Probe OK until now, going to ProbeVideo <<<
>>> Probing OV9640 <<<
Parent missing or invalid!
Driver for 1-wire Dallas network protocol.
i.MX SDHC driver
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
oprofile: using timer interrupt.
TCP cubic registered
NET: Registered protocol family 17
mx27-camera mx27-camera.0: initialising
>>> mx27_camera: IRQ request OK!
>>> mx27_camera: pcdev OK!
>>> mx27_camera: clk_csi OK!
mx27-camera mx27-camera.0: Camera clock frequency: 2660
>>> mx27_camera: DMA request OK!
mx27-camera mx27-camera.0: Using EMMA
>>> mx27_camera: probe OK until now!
mx27-camera mx27-camera.0: Non-NULL drvdata on register
>>> mx27_camera: soc_camera_host_register returned 0!

Then ov9640 returns error because icd->dev.parent doesn't exist.

Did you already see this issue?

Best Regards,

Alan
--
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] soc-camera and mediabus

[Guennadi Liakhovetski]

Hi Mauro,

At last soc-camera and mediabus lot for 2.6.33. Note, that one of this 
patches adds new fourcc codes. A patch for their documentation will be 
submitted immediately.

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

for the following 30 changesets:

01/30: tw9910: The driver can also handle revision 1 of the chip
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f1e67c4ca734

02/30: soc-camera: remove no longer needed struct members
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ac42a43c9d3c

03/30: v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in 
soc-camera
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f3ce29815a19

04/30: soc-camera: fix multi-line comment coding style
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=e893641bb109

05/30: sh_mobile_ceu_camera: do not mark host occupied, when adding a client 
fails
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=9505453960fb

06/30: v4l: Add a 10-bit monochrome and missing 8- and 10-bit Bayer fourcc codes
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=fc70aabadc59

07/30: soc-camera: add a private field to struct soc_camera_link
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8144ecd97132

08/30: Subject: kernel-sync for arch/sh/boards/mach-ap325rxa/setup.c
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ea27f790755c

09/30: soc-camera: switch drivers and platforms to use .priv in struct 
soc_camera_link
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=54707961f633

10/30: sh_mobile_ceu_camera: document the scaling and cropping algorithm
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f490679b43c3

11/30: tw9910: Add revision control
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4d27f0bec0f3

12/30: tw9910: simplify chip ID calculation
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=b919641bdf84

13/30: tw9910: Tri-state pins when idle
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=bb97c53db3c0

14/30: tw9910: Add power control
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2d8774ea617f

15/30: tw9910: tw9910_set_hsync clean up
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=669d0a9ca121

16/30: tw9910: Add revision control to tw9910_set_hsync
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=d3619f5f5679

17/30: v4l: add a media-bus API for configuring v4l2 subdev pixel and frame 
formats
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2c60bd900a7a

18/30: soc-camera: convert to the new mediabus API
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2a8289e3de7b

19/30: Subject: kernel-sync for arch/sh/boards/mach-kfr2r09/setup.c
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4e1dcff622e0

20/30: rj54n1cb0c: Add cropping, auto white balance, restrict sizes, add 
platform data
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c2ede215a03c

21/30: mt9t031: make the use of the soc-camera client API optional
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be8b7a9252d8

22/30: sh_mobile_ceu: Add V4L2_FIELD_INTERLACED_BT/TB support
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1a36ae75bdb1

23/30: tw9910: use V4L2_FIELD_INTERLACED_BT
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be43ab8c8490

24/30: sh_mobile_ceu_camera: Add support for sync polarity selection
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=596e9b685f9b

25/30: tw9910: modify V/H outpit pin setting to use VALID
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8e7ca505b942

26/30: tw9910: modify output format
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a42544f649b1

27/30: tw9910: remove cropping
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c141cc75045a

28/30: tw9910: Add sync polarity support
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=750376b279e0

29/30: soc-camera: Add mt9t112 camera driver
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=37cdd4e97937

30/30: sh_mobile_ceu_camera: Remove frame size page alignment
http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8da6f7deee9f


 a/linux/arch/sh/boards/board-ap325rxa.c|  606 --
 b/linux/Documentation/video4linux/sh_mobile_ceu_camera.txt |  157 +
 b/linux/arch/sh/boards/mach-ap325rxa/setup.c   |  657 +++
 b/linux/arch/sh/boards/mach-kfr2r09/setup.c|  622 ++
 b/linux/drivers/media/video/mt9t112.c  | 1177 +
 b/linux/drivers/media/video/soc_mediabus.c |  157 +
 b/linux/include/media/mt9t112.h|   30 
 b/linux/include/media/rj54n1cb0c.h |   19 
 b/linux/include/media

[PATCH] document new pixel formats

[Guennadi Liakhovetski]

Document all four 10-bit Bayer formats, 10-bit monochrome and a missing 
8-bit Bayer formats.

Signed-off-by: Guennadi Liakhovetski 
---

Notice, this is a linux git patch, so, it includes manual additions to 
media-entities.tmpl, which will hopefully not be needed for hg. I'm also 
adding all four 10-bit Bayer formats here, including the 
V4L2_PIX_FMT_SGRBG10, which is already documented in pixfmt.xml. We can 
remove that bit then.

diff --git a/Documentation/DocBook/media-entities.tmpl 
b/Documentation/DocBook/media-entities.tmpl
index bb5ab74..5524e32 100644
--- a/Documentation/DocBook/media-entities.tmpl
+++ b/Documentation/DocBook/media-entities.tmpl
@@ -222,8 +222,11 @@
 
 
 
+
+
 
 
+
 
 
 
@@ -313,8 +316,11 @@
 
 
 
+
+
 
 
+
 
 
 
diff --git a/Documentation/DocBook/v4l/pixfmt-srggb10.xml 
b/Documentation/DocBook/v4l/pixfmt-srggb10.xml
new file mode 100644
index 000..1be1815
--- /dev/null
+++ b/Documentation/DocBook/v4l/pixfmt-srggb10.xml
@@ -0,0 +1,98 @@
+
+  
+   V4L2_PIX_FMT_SRGGB10 ('RG10'),
+V4L2_PIX_FMT_SGRBG10 ('BA10'),
+V4L2_PIX_FMT_SGBRG10 ('GB10'),
+V4L2_PIX_FMT_SBGGR10 ('BG10'),
+
+   &manvol;
+  
+  
+   V4L2_PIX_FMT_SRGGB10
+   V4L2_PIX_FMT_SGRBG10
+   V4L2_PIX_FMT_SGBRG10
+   V4L2_PIX_FMT_SBGGR10
+   10-bit Bayer formats expanded to 16 bits
+  
+  
+   Description
+
+   The following four pixel formats are raw sRGB / Bayer formats with
+10 bits per colour. Each colour component is stored in a 16-bit word, with 6
+unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
+and n/2 blue or red samples, with alternating red and blue rows. Bytes are
+stored in memory in little endian order. They are conventionally described
+as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
+formats
+
+
+  V4L2_PIX_FMT_SBGGR10 4 × 4
+pixel image
+
+  
+   Byte Order.
+   Each cell is one byte, high 6 bits in high bytes are 0.
+ 
+   
+ 
+ 
+   
+ start + 0:
+ B00low
+ B00high
+ G01low
+ G01high
+ B02low
+ B02high
+ G03low
+ G03high
+   
+   
+ start + 8:
+ G10low
+ G10high
+ R11low
+ R11high
+ G12low
+ G12high
+ R13low
+ R13high
+   
+   
+ start + 16:
+ B20low
+ B20high
+ G21low
+ G21high
+ B22low
+ B22high
+ G23low
+ G23high
+   
+   
+ start + 24:
+ G30low
+ G30high
+ R31low
+ R31high
+ G32low
+ G32high
+ R33low
+ R33high
+   
+ 
+   
+ 
+   
+  
+
+  
+
+
+  
diff --git a/Documentation/DocBook/v4l/pixfmt-srggb8.xml 
b/Documentation/DocBook/v4l/pixfmt-srggb8.xml
new file mode 100644
index 000..cfae228
--- /dev/null
+++ b/Documentation/DocBook/v4l/pixfmt-srggb8.xml
@@ -0,0 +1,75 @@
+
+  
+   V4L2_PIX_FMT_SRGGB8 ('RGGB')
+   &manvol;
+  
+  
+   V4L2_PIX_FMT_SRGGB8
+   Bayer RGB format
+  
+  
+   Description
+
+   This is commonly the native format of digital cameras,
+reflecting the arrangement of sensors on the CCD device. Only one red,
+green or blue value is given for each pixel. Missing components must
+be interpolated from neighbouring pixels. From left to right the first
+row consists of a red and green value, the second row of a green and
+blue value. This scheme repeats to the right and down for every two
+columns and rows.
+
+   
+ V4L2_PIX_FMT_SRGGB8 4 × 4
+pixel image
+
+ 
+   Byte Order.
+   Each cell is one byte.
+ 
+   
+ 
+ 
+   
+ start + 0:
+ R00
+ G01
+ R02
+ G03
+   
+   
+ start + 4:
+ G10
+ B11
+ G12
+ B13
+   
+   
+ start + 8:
+ R20
+ G21
+ R22
+ G23
+   
+   
+ start + 12:
+ G30
+ B31
+ G32
+ B33
+   
+ 

Re: soc_camera: OV2640

[Guennadi Liakhovetski]

On Fri, 11 Dec 2009, Alan Carvalho de Assis wrote:

> Hi Guennadi,
> 
> On 12/8/09, Alan Carvalho de Assis  wrote:
> > Hi Guennadi,
> ...
> >>> I am trying to use an OV2640 camera with soc_camera.
> >>>
> >>> I'm using ov772x driver as base, but it needs too much modification to
> >>> work with ov2640.
> >>
> >> I don't know that sensor specifically, but they can be quite different.
> >>
> >
> > Yes, in fact ov2640 appears quite different compared to ov772x and ov9640.
> >
> >>> The OV2640 chip remaps all registers when register 0xFF is 1 or when it
> >>> is
> >>> 0.
> >>
> >> This is not unusual. There are a few ways to implement this, for example,
> >> drivers/media/video/rj54n1cb0c.c uses 16-bit addresses, and decodes them
> >> to bank:register pairs in its reg_read() and reg_write() routines.
> >>
> >
> > Ok, I will try to implement it this way, case nobody suggests me a
> > better approach.
> >
> 
> I got mx27_camera from pengutronix tree and modified it to work with
> kernel 2.6.32 (few modifications).

Sorry, I cannot help you with an out-of-tree driver, and generally I would 
expect significant changes when going to 2.6.32.

> I added platform data/device on my
> board using pcm970-baseboard.c as example.
> 
> In the kernel config I selected:
> CONFIG_VIDEO_MX27
> CONFIG_SOC_CAMERA_OV9640
> 
> 
> I noticed a strange behavior: the ov9640 driver is called before mx27_camera:
> 
> Linux video capture interface: v2.00
> >>> Probe OK until now, going to ProbeVideo <<<
> >>> Probing OV9640 <<<
> Parent missing or invalid!
> Driver for 1-wire Dallas network protocol.
> i.MX SDHC driver
> usbcore: registered new interface driver usbhid
> usbhid: v2.6:USB HID core driver
> oprofile: using timer interrupt.
> TCP cubic registered
> NET: Registered protocol family 17
> mx27-camera mx27-camera.0: initialising
> >>> mx27_camera: IRQ request OK!
> >>> mx27_camera: pcdev OK!
> >>> mx27_camera: clk_csi OK!
> mx27-camera mx27-camera.0: Camera clock frequency: 2660
> >>> mx27_camera: DMA request OK!
> mx27-camera mx27-camera.0: Using EMMA
> >>> mx27_camera: probe OK until now!
> mx27-camera mx27-camera.0: Non-NULL drvdata on register
> >>> mx27_camera: soc_camera_host_register returned 0!
> 
> Then ov9640 returns error because icd->dev.parent doesn't exist.
> 
> Did you already see this issue?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: linux-next: Tree for December 11 (media/dvb/frontends)

[Randy Dunlap]

On Fri, 11 Dec 2009 16:01:51 +1100 Stephen Rothwell wrote:

> Hi all,
> 
> My usual call for calm: please do not put stuff destined for 2.6.34 into
> linux-next trees until after 2.6.33-rc1.
> 
> Changes since 20091210:


drivers/media/dvb/frontends/dib0090.h:103: error: expected '=', ',', ';', 'asm' 
or '__attribute__' before 'frontend_tune_state'

static inline num frontend_tune_state dib0090_get_tune_state(struct 
dvb_frontend *fe)

s/num/enum/



drivers/media/dvb/frontends/dib8000.h:104: error: expected expression before 
'}' token
drivers/media/dvb/frontends/dib8000.h:104: warning: left-hand operand of comma 
expression has no effect

return CT_SHUTDOWN,

s/,/;/
and use tab to indent.



someone built/tested these??

---
~Randy
--
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: soc_camera: OV2640

[Alan Carvalho de Assis]

Hi Guennadi,

On 12/11/09, Guennadi Liakhovetski  wrote:
> On Fri, 11 Dec 2009, Alan Carvalho de Assis wrote:
>> I got mx27_camera from pengutronix tree and modified it to work with
>> kernel 2.6.32 (few modifications).
>
> Sorry, I cannot help you with an out-of-tree driver, and generally I would
> expect significant changes when going to 2.6.32.
>

Right, I can post a patch to add mx27_camera on mainstream kernel
since Sascha (original author) let me do it.

Sascha, can I submit it?

Best Regards,

Alan
--
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 - v1 1/2] V4L - vpfe capture - make clocks configurable

[Kevin Hilman]

"Karicheri, Muralidharan"  writes:

>>> Kevin,
>>>
>>> I think I have figured it out...
>>>
>>> First issue was that I was adding my entry at the end of dm644x_clks[]
>>> array. I need to add it before the CLK(NULL, NULL, NULL)
>>>
>>> secondly, your suggestion didn't work as is. This is what I had to
>>> do to get it working...
>>>
>>> static struct clk ccdc_master_clk = {
>>> .name = "dm644x_ccdc",
>>> .parent = &vpss_master_clk,
>>> };
>>>
>>> static struct clk ccdc_slave_clk = {
>>> .name = "dm644x_ccdc",
>>> .parent = &vpss_slave_clk,
>>> };
>
> It doesn't work with out doing this. The cat /proc/davinci_clocks hangs with
> your suggestion implemented...

Can you track down the hang.  It sounds like a bug in the walking of
the clock tree for davinci_clocks.

>>
>>You should not need to add new clocks with new names.  I don't thinke
>>the name field of the struct clk is used anywhere in the matching.
>>I think it's only used in /proc/davinci_clocks
>>
>>> static struct davinci_clk dm365_clks = {
>>> 
>>> 
>>> CLK("dm644x_ccdc", "master", &ccdc_master_clk),
>>> CLK("dm644x_ccdc", "slave", &ccdc_slave_clk),
>>
>>Looks like the drivers name is 'dm644x_ccdc', not 'isif'.  I'm
>>guessing just this should work without having to add new clock names.
>>
> No. I have mixed up the names. ISIF is for the new ISIF driver on DM365.
> Below are for DM644x ccdc driver. With just these entries added, two
> things observed
>
> 1) Only one clock is shown disabled (usually many are shown disabled) during 
> bootup
> 2) cat /proc/davinci_clocks hangs.
>
> So this is the only way I got it working.

Hmm, it worked just fine for me without any of these side effects.  I
applied the simple patch below on top of current master branch.  It booted
fine showing all the unused clocks being disabled, and I was able to 
see davinci_clocks just fine:


diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index e65e29e..e6f3570 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -293,8 +293,8 @@ struct davinci_clk dm644x_clks[] = {
CLK(NULL, "dsp", &dsp_clk),
CLK(NULL, "arm", &arm_clk),
CLK(NULL, "vicp", &vicp_clk),
-   CLK(NULL, "vpss_master", &vpss_master_clk),
-   CLK(NULL, "vpss_slave", &vpss_slave_clk),
+   CLK("dm644x_ccdc", "master", &vpss_master_clk),
+   CLK("dm644x_ccdc", "slave", &vpss_slave_clk),
CLK(NULL, "arm", &arm_clk),
CLK(NULL, "uart0", &uart0_clk),
CLK(NULL, "uart1", &uart1_clk),


[...]
Clocks: disable unused uart1
Clocks: disable unused uart2
Clocks: disable unused emac 
Clocks: disable unused ide  
Clocks: disable unused asp0 
Clocks: disable unused mmcsd
Clocks: disable unused spi  
Clocks: disable unused usb  
Clocks: disable unused vlynq
Clocks: disable unused pwm0 
Clocks: disable unused pwm1 
Clocks: disable unused pwm2 
Clocks: disable unused timer1
[...]

r...@dm644x:~# uname -r 
2.6.32-arm-davinci-default-06873-g1a7277b-dirty 
r...@dm644x:~# cat /debug/davinci_clocks
ref_clk   users= 8  2700 Hz 
  pll1users= 8 pll 59400 Hz 
pll1_sysclk1  users= 0 pll 59400 Hz 
  dsp users= 1 psc 59400 Hz 
pll1_sysclk2  users= 2 pll 29700 Hz 
  arm users= 2 psc 29700 Hz 
pll1_sysclk3  users= 0 pll 19800 Hz 
  vpss_master users= 0 psc 19800 Hz 
  vpss_slave  users= 0 psc 19800 Hz 
pll1_sysclk5  users= 3 pll  9900 Hz 
  emacusers= 1 psc  9900 Hz 
  ide users= 0 psc  9900 Hz 
  asp0users= 0 psc  9900 Hz 
  mmcsd   users= 0 psc  9900 Hz 
  spi users= 0 psc  9900 H

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

[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:Fri Dec 11 19:00:05 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   13611:db37ff59927f
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.30-armv5: OK
linux-2.6.31-armv5: OK
linux-2.6.32-armv5: OK
linux-2.6.32-armv5-davinci: OK
linux-2.6.30-armv5-ixp: OK
linux-2.6.31-armv5-ixp: OK
linux-2.6.32-armv5-ixp: ERRORS
linux-2.6.30-armv5-omap2: OK
linux-2.6.31-armv5-omap2: OK
linux-2.6.32-armv5-omap2: OK
linux-2.6.22.19-i686: ERRORS
linux-2.6.23.12-i686: ERRORS
linux-2.6.24.7-i686: ERRORS
linux-2.6.25.11-i686: ERRORS
linux-2.6.26-i686: ERRORS
linux-2.6.27-i686: ERRORS
linux-2.6.28-i686: ERRORS
linux-2.6.29.1-i686: ERRORS
linux-2.6.30-i686: OK
linux-2.6.31-i686: OK
linux-2.6.32-i686: OK
linux-2.6.30-m32r: OK
linux-2.6.31-m32r: OK
linux-2.6.32-m32r: OK
linux-2.6.30-mips: OK
linux-2.6.31-mips: OK
linux-2.6.32-mips: ERRORS
linux-2.6.30-powerpc64: OK
linux-2.6.31-powerpc64: OK
linux-2.6.32-powerpc64: OK
linux-2.6.22.19-x86_64: ERRORS
linux-2.6.23.12-x86_64: ERRORS
linux-2.6.24.7-x86_64: ERRORS
linux-2.6.25.11-x86_64: ERRORS
linux-2.6.26-x86_64: ERRORS
linux-2.6.27-x86_64: ERRORS
linux-2.6.28-x86_64: ERRORS
linux-2.6.29.1-x86_64: ERRORS
linux-2.6.30-x86_64: OK
linux-2.6.31-x86_64: OK
linux-2.6.32-x86_64: OK
spec: OK
sparse (linux-2.6.32): ERRORS
linux-2.6.16.61-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.5-i686: ERRORS
linux-2.6.20.21-i686: ERRORS
linux-2.6.21.7-i686: ERRORS
linux-2.6.16.61-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.5-x86_64: ERRORS
linux-2.6.20.21-x86_64: ERRORS
linux-2.6.21.7-x86_64: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
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

[SOLVED] dib0700: Nova-T-500 remote - mixed button codes

[Antonio Marcos López Alonso]

Spot on, Christophe!

I didn't realize I have not tried swapping the sensor wires and this little 
damned thing is working now!

However I must point the "faulty" sensor wire works right with the HVR-1100. I 
cannot tell which sensor belongs to which card (both of them are identical 
except the "working" Nova-T-500 wire that shows a label with what seems to be 
a P/N or a S/N on it) so I suppose the Nova-T-500 wire works well with the 
HVR-1100 but not the opposite (maybe a bandwidth issue). To support this 
theory there is the fact that the spurious keycodes are not random but always 
the same per remote button (but the happening frequency is random indeed).

Thanks a lot for your help!

Antonio



El Viernes 11 Diciembre 2009, Rochet, Christophe escribió:
> Hi Antonio.
> 
> Did you switched also the IR remote sensor itself ?
> 
> I experienced same weird things with a WinovaTV years ago, and finally the
>  IR phototransistor in the small round receiver was crappy. When I changed
>  it by a common spare it all came right.
> 
> Protect also your IR sensor from AC lights...
> 
> If you experiment "random" keys, a noisy IR signal or dead receiver is
>  perhaps the cause.
> 
> If you experiment always the same button jam, that's something else.
> 
> Regards.
> 
> -Message d'origine-
> De : linux-media-ow...@vger.kernel.org
>  [mailto:linux-media-ow...@vger.kernel.org] De la part de Antonio Marcos
>  López Alonso Envoyé : vendredi 11 décembre 2009 16:10
> À : linux-media@vger.kernel.org
> Objet : dib0700: Nova-T-500 remote - mixed button codes
> 
> Hi all,
> 
> I own a Hauppauge Nova-T-500 in a box running Mythbuntu 9.10. The card runs
> fine except when it comes to the in-built remote sensor:
> 
> Whenever I press any button, the remote sensor seems to receive some other
> keycodes aside the proper one (i.e. when I press Volume Up button the
>  sensor receives it most of the time, but sometimes it understands some
>  other buttons are pressed like ArrowDown, Red button and so, making MythTV
>  experience very annoying). There are only three buttons that are always
>  well received with no confusion at all: "OK", "ArrowDown" and "Play". This
>  behavior occurs with two identical remotes I own (one of them belonging to
>  a WinTV HVR-1100) and another card user has reported a similar behavior
>  with its own and same remote.
> 
> I tested both remotes with the HVR-1100 and they behave perfectly, so I
>  guess this is not a remote related issue.
> 
> Though I have tried several LIRC setup files and swapped dvb_usb_dib0700
> firmware files (1.10 and 1.20 versions) they make no working difference at
> all.
> 
> I also tried rebuilding v4l-dvb code to no avail.
> 
> Any suggestions? I would gladly provide further info/logs upon request.
> 
> Cheers,
> Antonio
> --
> 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
> --
> 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
> 

--
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: [stable] [PATCH] ov511: fix probe() hang due to double mutex_lock

[Brandon Philips]

On 19:32 Thu 10 Dec 2009, Greg KH wrote:
> On Thu, Dec 10, 2009 at 05:04:49PM -0800, Brandon Philips wrote:
> > Commit 163fe744c3283fd267268629afff4cfc846ed0e0 added a double
> > mutex_lock which hangs ov51x_probe(). This was clearly a typo.
> > 
> > Change final mutex_lock() -> mutex_unlock()
> > 
> > Signed-off-by: Brandon Philips 
> 
> Brandon, when you want patches to be added to the stable tree, just add
> a:
>   Cc: stable 
> to the signed-off-by area of the patch.  That way, when they get merged
> into Linus's tree eventually, they will be automagically sent to the
> sta...@kernel.org alias, so I know to add it to the tree at that time.
> 
> It saves you time, and me time, so I don't have to go hunt for this
> upstream sometime in the future.

That is a handy feature. It might be nice to document it in the
-stable documentation. See patch below for an attempt.

I will ping stable again on this patch once this reaches Linus's tree
so you don't need to track it. Sorry for messing up the stable
procedure. :D

Thanks,

Brandon

diff --git a/Documentation/stable_kernel_rules.txt 
b/Documentation/stable_kernel_rules.txt
index a452227..5d24504 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -36,6 +36,23 @@ Procedure for submitting patches to the -stable tree:
  - Security patches should not be sent to this alias, but instead to the
documented secur...@kernel.org address.
 
+Submitting to -stable automatically upon reaching Linus's tree:
+
+ - As mentioned above, patches must be merged into Linus's tree before being
+   considered for -stable. But, if you are sending a patch for inclusion
+   into Linus's tree that you know you will eventually submit to -stable when
+   it is merged then you can save yourself the trouble of tracking the patch by
+   adding:
+
+ Cc: stable 
+
+   in the signed-off-by area of the patch. Then once it is merged with Linus
+   an email with the patch will be sent to sta...@kernel.org automatically.
+
+   This only works for patches that are for both -stable and Linus's tree at
+   the time of submission. If a fix has already made its way into Linus's tree
+   or a maintainer's queue for Linus's tree then follow the regular submission
+   rules outlined above.
 
 Review cycle:
 
--
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 - v1 1/2] V4L - vpfe capture - make clocks configurable

[Karicheri, Muralidharan]

Kevin,

That is what I had seen. I will check it again on Monday
and let you know.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com

>-Original Message-
>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: Friday, December 11, 2009 1:35 PM
>To: Karicheri, Muralidharan
>Cc: davinci-linux-open-sou...@linux.davincidsp.com; linux-
>me...@vger.kernel.org
>Subject: Re: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable
>
>"Karicheri, Muralidharan"  writes:
>
 Kevin,

 I think I have figured it out...

 First issue was that I was adding my entry at the end of dm644x_clks[]
 array. I need to add it before the CLK(NULL, NULL, NULL)

 secondly, your suggestion didn't work as is. This is what I had to
 do to get it working...

 static struct clk ccdc_master_clk = {
.name = "dm644x_ccdc",
.parent = &vpss_master_clk,
 };

 static struct clk ccdc_slave_clk = {
.name = "dm644x_ccdc",
.parent = &vpss_slave_clk,
 };
>>
>> It doesn't work with out doing this. The cat /proc/davinci_clocks hangs
>with
>> your suggestion implemented...
>
>Can you track down the hang.  It sounds like a bug in the walking of
>the clock tree for davinci_clocks.
>
>>>
>>>You should not need to add new clocks with new names.  I don't thinke
>>>the name field of the struct clk is used anywhere in the matching.
>>>I think it's only used in /proc/davinci_clocks
>>>
 static struct davinci_clk dm365_clks = {
 
 
 CLK("dm644x_ccdc", "master", &ccdc_master_clk),
 CLK("dm644x_ccdc", "slave", &ccdc_slave_clk),
>>>
>>>Looks like the drivers name is 'dm644x_ccdc', not 'isif'.  I'm
>>>guessing just this should work without having to add new clock names.
>>>
>> No. I have mixed up the names. ISIF is for the new ISIF driver on DM365.
>> Below are for DM644x ccdc driver. With just these entries added, two
>> things observed
>>
>> 1) Only one clock is shown disabled (usually many are shown disabled)
>during bootup
>> 2) cat /proc/davinci_clocks hangs.
>>
>> So this is the only way I got it working.
>
>Hmm, it worked just fine for me without any of these side effects.  I
>applied the simple patch below on top of current master branch.  It booted
>fine showing all the unused clocks being disabled, and I was able to
>see davinci_clocks just fine:
>
>
>diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-
>davinci/dm644x.c
>index e65e29e..e6f3570 100644
>--- a/arch/arm/mach-davinci/dm644x.c
>+++ b/arch/arm/mach-davinci/dm644x.c
>@@ -293,8 +293,8 @@ struct davinci_clk dm644x_clks[] = {
>CLK(NULL, "dsp", &dsp_clk),
>CLK(NULL, "arm", &arm_clk),
>CLK(NULL, "vicp", &vicp_clk),
>-   CLK(NULL, "vpss_master", &vpss_master_clk),
>-   CLK(NULL, "vpss_slave", &vpss_slave_clk),
>+   CLK("dm644x_ccdc", "master", &vpss_master_clk),
>+   CLK("dm644x_ccdc", "slave", &vpss_slave_clk),
>CLK(NULL, "arm", &arm_clk),
>CLK(NULL, "uart0", &uart0_clk),
>CLK(NULL, "uart1", &uart1_clk),
>
>
>[...]
>Clocks: disable unused uart1
>Clocks: disable unused uart2
>Clocks: disable unused emac
>Clocks: disable unused ide
>Clocks: disable unused asp0
>Clocks: disable unused mmcsd
>Clocks: disable unused spi
>Clocks: disable unused usb
>Clocks: disable unused vlynq
>Clocks: disable unused pwm0
>Clocks: disable unused pwm1
>Clocks: disable unused pwm2
>Clocks: disable unused timer1
>[...]
>
>r...@dm644x:~# uname -r
>2.6.32-arm-davinci-default-06873-g1a7277b-dirty
>r...@dm644x:~# cat /debug/davinci_clocks
>ref_clk   users= 8  2700 Hz
>  pll1users= 8 pll 59400 Hz
>pll1_sysclk1  users= 0 pll 59400 Hz
>  dsp users= 1 psc 59400 Hz
>pll1_sysclk2  users= 2 pll 29700 Hz
>  arm users= 2 psc 29700 Hz
>pll1_sysclk3  users= 0 pll 19800 Hz
>  vpss_master users= 0 psc 19800 Hz
>  vpss_slave  users= 0 psc 19800 Hz
>pll1_sysclk5  users= 3 pll  9900 Hz
>  emacusers= 1 psc  9900 Hz
>  ide users= 0 psc  9900 Hz
>  asp0users= 0 psc  9900 Hz
>  mmcsd   users= 0 psc  9900 Hz
>  spi users= 0 psc  9900 Hz
>  gpiousers= 1 psc  9900 Hz
>  usb users= 0 psc  9900 Hz
>  vlynq   users= 0 psc  9900 Hz
>  aemif   users= 1 psc  9900 Hz
>pll1_aux_clk  users= 3 pll  2700 Hz
>  uart0   users= 1 psc  2700 Hz
>  uart1   users= 0 psc  2700 Hz
>  uart2   users= 0 psc  2700 Hz
>  i2c users= 1 psc  2700 Hz
>  pwm0users= 0 psc  2700 Hz
>  pwm1users= 0 psc  2700 Hz
>  pwm2users= 0 psc  2700 Hz
>  timer0  users= 1 psc  2700 Hz
>  timer1  users= 0 psc  2700 Hz
>  timer2   

RE: [PATCH - v1 5/6] V4L - vpfe capture - build environment for ISIF driver

[Karicheri, Muralidharan]

Ok. I will do.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com

>-Original Message-
>From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com]
>Sent: Thursday, December 10, 2009 12:38 PM
>To: Karicheri, Muralidharan
>Cc: linux-media@vger.kernel.org; hverk...@xs4all.nl;
>khil...@deeprootsystems.com; Nori, Sekhar; Hiremath, Vaibhav; davinci-
>linux-open-sou...@linux.davincidsp.com
>Subject: Re: [PATCH - v1 5/6] V4L - vpfe capture - build environment for
>ISIF driver
>
>Hello.
>
>m-kariche...@ti.com wrote:
>
>> From: Muralidharan Karicheri 
>>
>> Adding Makefile and Kconfig for ISIF driver
>>
>> Signed-off-by: Muralidharan Karicheri 
>> ---
>> Applies to linux-next tree
>>  drivers/media/video/Kconfig  |   15 ++-
>>  drivers/media/video/davinci/Makefile |1 +
>>  2 files changed, 15 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
>> index 9dc74c9..8250c68 100644
>> --- a/drivers/media/video/Kconfig
>> +++ b/drivers/media/video/Kconfig
>> @@ -552,7 +552,7 @@ config VIDEO_VPSS_SYSTEM
>>  depends on ARCH_DAVINCI
>>  help
>>Support for vpss system module for video driver
>> -default y
>> +default n
>>
>
>   You might as well have deleted "default".
>
>WBR, Sergei

--
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] gspca m5602: eliminate sparse warnings

[Németh Márton]

From: Márton Németh 

Eliminate the following sparse warnings (see "make C=1"):
 * v4l/m5602_s5k4aa.c:530:23: warning: dubious: x | !y
 * v4l/m5602_s5k4aa.c:575:23: warning: dubious: x | !y

Signed-off-by: Márton Németh 
---
../../m5602_s5k4aa_dubious.patch
diff -r f5662ce08663 linux/drivers/media/video/gspca/m5602/m5602_s5k4aa.c
--- a/linux/drivers/media/video/gspca/m5602/m5602_s5k4aa.c  Fri Dec 11 
09:53:41 2009 +0100
+++ b/linux/drivers/media/video/gspca/m5602/m5602_s5k4aa.c  Fri Dec 11 
22:25:50 2009 +0100
@@ -527,7 +527,7 @@
err = m5602_read_sensor(sd, S5K4AA_ROWSTART_LO, &data, 1);
if (err < 0)
return err;
-   data = (data & 0xfe) | !val;
+   data = (data & 0xfe) | (val ? 0 : 1);
err = m5602_write_sensor(sd, S5K4AA_ROWSTART_LO, &data, 1);
return err;
 }
@@ -572,7 +572,7 @@
err = m5602_read_sensor(sd, S5K4AA_COLSTART_LO, &data, 1);
if (err < 0)
return err;
-   data = (data & 0xfe) | !val;
+   data = (data & 0xfe) | (val ? 0 : 1);
err = m5602_write_sensor(sd, S5K4AA_COLSTART_LO, &data, 1);
return err;
 }
--
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: Latest stack that can be merged on top of linux-next tree

[Karicheri, Muralidharan]

Hi,

Thanks for the response. One more question that I have is if
the devices on the two buses can use the same i2c address.
That is the case for my board. So wondering if this works as
well.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com

>-Original Message-
>From: HoP [mailto:jpetr...@gmail.com]
>Sent: Thursday, December 10, 2009 4:16 PM
>To: Karicheri, Muralidharan
>Cc: Daniel Glöckner; linux-media@vger.kernel.org
>Subject: Re: Latest stack that can be merged on top of linux-next tree
>
>Hi,
>
>2009/12/10 Karicheri, Muralidharan :
>> Hi,
>>
>> Thanks for the email.
>>
>> Any idea how i2c drivers can work with this?
>>
>> Currently in my board, I have adapter id = 1 for main i2c bus. So when
>this mux driver is built into the kernel, I guess I can access it using a
>different adapter id, right? If so, what is the adapter id?
>
>Yes, exactly that is way of using - additional i2c buses were born when
>pca954x
>started.
>
>Daniel already described this in his mail:
>
>"With these patches the bus segments beyond the i2c multiplexer will be
>registered as separate i2c busses. Access to a device on those busses
>will then automatically reconfigure the multiplexer."
>
>Additional i2c buses (adapters) were counted from number +1 higher
>then highest i2c bus number. If you main i2c bus is i2c-1, then you
>you should find i2c-2,i2c-3,i2c-4,i2c-5 new buses after pca954x loading.
>
>You can check that with i2cdetect tools.
>
>>
>> How do I use this with MT9T031 driver? Any idea to share?
>>
>
>I never had a look inside mt9t031 driver, but in general - you simply
>point to some of that additional adaper by i2c_get_adapter(x)
>
>Idea is very smart. You don't need to manage pca954x on your own.
>Driver do it itself :)
>
>/Honza
--
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: Latest stack that can be merged on top of linux-next tree

[HoP]

Hi

2009/12/11 Karicheri, Muralidharan :
> Hi,
>
> Thanks for the response. One more question that I have is if
> the devices on the two buses can use the same i2c address.
> That is the case for my board. So wondering if this works as
> well.
>

That is IMHO exactly reason of existence such "expanders".
We, for example have two DVB-S2 tuners, using totally
same i2c addresses (for demod & pll).

If you are carefull and access such devices only using
those virtual i2c buses, then you not need to manage
switching between them at all. It is job for pca954x
driver. Simple and easy :)

/Honza
--
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] dib8000: make some constant static

[Németh Márton]

From: Márton Németh 

Eliminate the following sparse warnings (see "make C=1"):
 * dib8000.c:125:15: warning: symbol 'coeff_2k_sb_1seg_dqpsk' was not declared. 
Should it be static?
 * dib8000.c:130:15: warning: symbol 'coeff_2k_sb_1seg' was not declared. 
Should it be static?
 * dib8000.c:134:15: warning: symbol 'coeff_2k_sb_3seg_0dqpsk_1dqpsk' was not 
declared. Should it be static?
 * dib8000.c:139:15: warning: symbol 'coeff_2k_sb_3seg_0dqpsk' was not 
declared. Should it be static?
 * dib8000.c:144:15: warning: symbol 'coeff_2k_sb_3seg_1dqpsk' was not 
declared. Should it be static?
 * dib8000.c:149:15: warning: symbol 'coeff_2k_sb_3seg' was not declared. 
Should it be static?
 * dib8000.c:154:15: warning: symbol 'coeff_4k_sb_1seg_dqpsk' was not declared. 
Should it be static?
 * dib8000.c:159:15: warning: symbol 'coeff_4k_sb_1seg' was not declared. 
Should it be static?
 * dib8000.c:164:15: warning: symbol 'coeff_4k_sb_3seg_0dqpsk_1dqpsk' was not 
declared. Should it be static?
 * dib8000.c:169:15: warning: symbol 'coeff_4k_sb_3seg_0dqpsk' was not 
declared. Should it be static?
 * dib8000.c:174:15: warning: symbol 'coeff_4k_sb_3seg_1dqpsk' was not 
declared. Should it be static?
 * dib8000.c:179:15: warning: symbol 'coeff_4k_sb_3seg' was not declared. 
Should it be static?
 * dib8000.c:184:15: warning: symbol 'coeff_8k_sb_1seg_dqpsk' was not declared. 
Should it be static?
 * dib8000.c:189:15: warning: symbol 'coeff_8k_sb_1seg' was not declared. 
Should it be static?
 * dib8000.c:194:15: warning: symbol 'coeff_8k_sb_3seg_0dqpsk_1dqpsk' was not 
declared. Should it be static?
 * dib8000.c:199:15: warning: symbol 'coeff_8k_sb_3seg_0dqpsk' was not 
declared. Should it be static?
 * dib8000.c:204:15: warning: symbol 'coeff_8k_sb_3seg_1dqpsk' was not 
declared. Should it be static?
 * dib8000.c:209:15: warning: symbol 'coeff_8k_sb_3seg' was not declared. 
Should it be static?
 * dib8000.c:214:15: warning: symbol 'ana_fe_coeff_3seg' was not declared. 
Should it be static?
 * dib8000.c:218:15: warning: symbol 'ana_fe_coeff_1seg' was not declared. 
Should it be static?
 * dib8000.c:222:15: warning: symbol 'ana_fe_coeff_13seg' was not declared. 
Should it be static?

Signed-off-by: Márton Németh 
---
diff -r f5662ce08663 linux/drivers/media/dvb/frontends/dib8000.c
--- a/linux/drivers/media/dvb/frontends/dib8000.c   Fri Dec 11 09:53:41 
2009 +0100
+++ b/linux/drivers/media/dvb/frontends/dib8000.c   Fri Dec 11 23:33:26 
2009 +0100
@@ -122,104 +122,104 @@
return dib8000_i2c_write16(&state->i2c, reg, val);
 }

-const int16_t coeff_2k_sb_1seg_dqpsk[8] = {
+static const int16_t coeff_2k_sb_1seg_dqpsk[8] = {
(769 << 5) | 0x0a, (745 << 5) | 0x03, (595 << 5) | 0x0d, (769 << 5) | 
0x0a, (920 << 5) | 0x09, (784 << 5) | 0x02, (519 << 5) | 0x0c,
(920 << 5) | 0x09
 };

-const int16_t coeff_2k_sb_1seg[8] = {
+static const int16_t coeff_2k_sb_1seg[8] = {
(692 << 5) | 0x0b, (683 << 5) | 0x01, (519 << 5) | 0x09, (692 << 5) | 
0x0b, 0 | 0x1f, 0 | 0x1f, 0 | 0x1f, 0 | 0x1f
 };

-const int16_t coeff_2k_sb_3seg_0dqpsk_1dqpsk[8] = {
+static const int16_t coeff_2k_sb_3seg_0dqpsk_1dqpsk[8] = {
(832 << 5) | 0x10, (912 << 5) | 0x05, (900 << 5) | 0x12, (832 << 5) | 
0x10, (-931 << 5) | 0x0f, (912 << 5) | 0x04, (807 << 5) | 0x11,
(-931 << 5) | 0x0f
 };

-const int16_t coeff_2k_sb_3seg_0dqpsk[8] = {
+static const int16_t coeff_2k_sb_3seg_0dqpsk[8] = {
(622 << 5) | 0x0c, (941 << 5) | 0x04, (796 << 5) | 0x10, (622 << 5) | 
0x0c, (982 << 5) | 0x0c, (519 << 5) | 0x02, (572 << 5) | 0x0e,
(982 << 5) | 0x0c
 };

-const int16_t coeff_2k_sb_3seg_1dqpsk[8] = {
+static const int16_t coeff_2k_sb_3seg_1dqpsk[8] = {
(699 << 5) | 0x14, (607 << 5) | 0x04, (944 << 5) | 0x13, (699 << 5) | 
0x14, (-720 << 5) | 0x0d, (640 << 5) | 0x03, (866 << 5) | 0x12,
(-720 << 5) | 0x0d
 };

-const int16_t coeff_2k_sb_3seg[8] = {
+static const int16_t coeff_2k_sb_3seg[8] = {
(664 << 5) | 0x0c, (925 << 5) | 0x03, (937 << 5) | 0x10, (664 << 5) | 
0x0c, (-610 << 5) | 0x0a, (697 << 5) | 0x01, (836 << 5) | 0x0e,
(-610 << 5) | 0x0a
 };

-const int16_t coeff_4k_sb_1seg_dqpsk[8] = {
+static const int16_t coeff_4k_sb_1seg_dqpsk[8] = {
(-955 << 5) | 0x0e, (687 << 5) | 0x04, (818 << 5) | 0x10, (-955 << 5) | 
0x0e, (-922 << 5) | 0x0d, (750 << 5) | 0x03, (665 << 5) | 0x0f,
(-922 << 5) | 0x0d
 };

-const int16_t coeff_4k_sb_1seg[8] = {
+static const int16_t coeff_4k_sb_1seg[8] = {
(638 << 5) | 0x0d, (683 << 5) | 0x02, (638 << 5) | 0x0d, (638 << 5) | 
0x0d, (-655 << 5) | 0x0a, (517 << 5) | 0x00, (698 << 5) | 0x0d,
(-655 << 5) | 0x0a
 };

-const int16_t coeff_4k_sb_3seg_0dqpsk_1dqpsk[8] = {
+static const int16_t coeff_4k_sb_3seg_0dqpsk_1dqpsk[8] = {
(-707 << 5) | 0x14, (910 << 5) | 0x06, (889 << 5) | 0x16, (-707 << 5) | 
0x14, (-958 << 5) | 0x13, (993 << 5) | 0x05, (523 << 5) | 0x14,
(-958 << 5) | 0x13
 };

[PATCH] sanio-ms: clean up init, exit and id_table

[Németh Márton]

From: Márton Németh 

Make module_init static and mark it with __init.
Make module_exit static and mark it with __exit.
Mark probe functions with __devinit.
Make id table static and mark with __devinitconst.

This will eliminate the following sparse warnings (see "make C=1"):
 * smsdvb.c:668:5: warning: symbol 'smsdvb_module_init' was not declared. 
Should it be static?
 * smsdvb.c:682:6: warning: symbol 'smsdvb_module_exit' was not declared. 
Should it be static?
 * smsusb.c:491:22: warning: symbol 'smsusb_id_table' was not declared. Should 
it be static?
 * smsusb.c:567:5: warning: symbol 'smsusb_module_init' was not declared. 
Should it be static?
 * smsusb.c:578:6: warning: symbol 'smsusb_module_exit' was not declared. 
Should it be static?
 * smssdio.c:341:5: warning: symbol 'smssdio_module_init' was not declared. 
Should it be static?
 * smssdio.c:353:6: warning: symbol 'smssdio_module_exit' was not declared. 
Should it be static?

Signed-off-by: Márton Németh 
---
diff -r f5662ce08663 linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cFri Dec 11 09:53:41 2009 +0100
+++ b/linux/drivers/media/dvb/siano/smsdvb.cFri Dec 11 23:58:27 2009 +0100
@@ -665,7 +665,7 @@
return rc;
 }

-int smsdvb_module_init(void)
+static int __init smsdvb_module_init(void)
 {
int rc;

@@ -679,7 +679,7 @@
return rc;
 }

-void smsdvb_module_exit(void)
+static void __exit smsdvb_module_exit(void)
 {
smscore_unregister_hotplug(smsdvb_hotplug);

diff -r f5662ce08663 linux/drivers/media/dvb/siano/smssdio.c
--- a/linux/drivers/media/dvb/siano/smssdio.c   Fri Dec 11 09:53:41 2009 +0100
+++ b/linux/drivers/media/dvb/siano/smssdio.c   Fri Dec 11 23:58:27 2009 +0100
@@ -48,7 +48,7 @@
 #define SMSSDIO_INT0x04
 #define SMSSDIO_BLOCK_SIZE 128

-static const struct sdio_device_id smssdio_ids[] = {
+static const struct sdio_device_id smssdio_ids[] __devinitconst = {
{SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_STELLAR),
 .driver_data = SMS1XXX_BOARD_SIANO_STELLAR},
{SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_NOVA_A0),
@@ -222,7 +222,7 @@
smscore_onresponse(smsdev->coredev, cb);
 }

-static int smssdio_probe(struct sdio_func *func,
+static int __devinit smssdio_probe(struct sdio_func *func,
 const struct sdio_device_id *id)
 {
int ret;
@@ -338,7 +338,7 @@
 /* Module functions*/
 /***/

-int smssdio_module_init(void)
+static int __init smssdio_module_init(void)
 {
int ret = 0;

@@ -350,7 +350,7 @@
return ret;
 }

-void smssdio_module_exit(void)
+static void __exit smssdio_module_exit(void)
 {
sdio_unregister_driver(&smssdio_driver);
 }
diff -r f5662ce08663 linux/drivers/media/dvb/siano/smsusb.c
--- a/linux/drivers/media/dvb/siano/smsusb.cFri Dec 11 09:53:41 2009 +0100
+++ b/linux/drivers/media/dvb/siano/smsusb.cFri Dec 11 23:58:27 2009 +0100
@@ -394,7 +394,7 @@
return rc;
 }

-static int smsusb_probe(struct usb_interface *intf,
+static int __devinit smsusb_probe(struct usb_interface *intf,
const struct usb_device_id *id)
 {
struct usb_device *udev = interface_to_usbdev(intf);
@@ -488,7 +488,7 @@
return 0;
 }

-struct usb_device_id smsusb_id_table[] = {
+static const struct usb_device_id smsusb_id_table[] __devinitconst = {
{ USB_DEVICE(0x187f, 0x0010),
.driver_info = SMS1XXX_BOARD_SIANO_STELLAR },
{ USB_DEVICE(0x187f, 0x0100),
@@ -564,7 +564,7 @@
.resume = smsusb_resume,
 };

-int smsusb_module_init(void)
+static int __init smsusb_module_init(void)
 {
int rc = usb_register(&smsusb_driver);
if (rc)
@@ -575,7 +575,7 @@
return rc;
 }

-void smsusb_module_exit(void)
+static void __exit smsusb_module_exit(void)
 {
/* Regular USB Cleanup */
usb_deregister(&smsusb_driver);
--
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: IR Receiver on an Tevii S470

[Igor M. Liplianin]

On 11 декабря 2009, "Igor M. Liplianin"  wrote:
> On Thu, 2009-12-10 at 18:16 +0200, Igor M. Liplianin wrote:
> > On 10 декабря 2009 03:12:39 Andy Walls wrote:
> > > On Wed, 2009-12-09 at 17:54 +0200, Igor M. Liplianin wrote:
> > > > > > > Igor and Matthias,
> > > > > > >
> > > > > > > Please try the changes that I have for the TeVii S470 that are
> > > > > > > here:
> > > > > > >
> > > > > > >   http://linuxtv.org/hg/~awalls/cx23885-ir
> > > >
> > > > In fact some time ago I was writing some code for cx23885 IR, but not
> > > > reached IR interrupts to work. Though I used PCI_MSK_AV_CORE (1 <<
> > > > 27), then test register PIN_CTRL for field FLD_IR_IRQ_STAT.
> > >
> > > Igor,
> > >
> > > You are exactly right on this.  I used the wrong interrupt status flag.
> > > I have pushed a patch to my repository to use the PCI_MSK_AV_CORE
> > > status flag.
> > >
> > > Could you please update an test the TeVii S470 again when you have
> > > time?
> > >
> > > > I have Compro E650F with RC6 remote, also have RC5 remote from TV
> > > > set. I will made little hack to test Compro & RC5.
> > >
> > > OK. Thank you.
> > >
> > > Regards,
> > > Andy
> >
> > First try, without pressing IR keys
> >
> > cx25840 3-0044: IRQ Enables: rse rte roe
> > cx25840 3-0044: IRQ Status:  tsr
> > cx25840 3-0044: IRQ Enables: rse rte roe
> > irq 16: nobody cared (try booting with the "irqpoll" option)
> > Pid: 0, comm: swapper Not tainted 2.6.32 #2
> > Call Trace:
> >  [] ? __report_bad_irq+0x24/0x69
> >  [] ? __report_bad_irq+0x2b/0x69
> >  [] ? note_interrupt+0xe7/0x13f
> >  [] ? handle_fasteoi_irq+0x7a/0x97
> >  [] ? handle_irq+0x38/0x3f
> >  [] ? do_IRQ+0x38/0x89
> >  [] ? common_interrupt+0x29/0x30
> >  [] ? mwait_idle+0x7a/0x7f
> >  [] ? cpu_idle+0x37/0x4c
> > handlers:
> > [] (usb_hcd_irq+0x0/0x59)
> > [] (azx_interrupt+0x0/0xe7 [snd_hda_intel])
> > [] (cx23885_irq+0x0/0x4a5 [cx23885])
> > Disabling IRQ #16
> > cx25840 3-0044: IRQ Status:  tsr
> > cx25840 3-0044: IRQ Enables: rse rte roe
> > cx25840 3-0044: IRQ Status:  tsr
>
> OK.  We're getting interrupts from the A/V core, but they are not IR
> related.  They must be audio and video interrupts from the A/V core.
>
> I have checked in new changes:
>
>   http://linuxtv.org/hg/~awalls/cx23885-ir
>
> please try again when you have time.
>
>   # modprobe cx25840 debug=2 ir_debug=2
>   # modprobe cx23885 debug=7
>
> My only concern now, is that I have not turned off all the audio
> interrupts from the A/V core - I could not determine if registers
> 0x80c-0x80f were improtant to set.
>
> Regards,
> Andy
dmesg is full of repeated lines:

cx25840 3-0044: AV Core IRQ status (entry):   
cx25840 3-0044: AV Core IRQ status (exit):   
cx23885[0]/0: pci_status: 0x083f4000  pci_mask: 0x0801
cx23885[0]/0: vida_status: 0x vida_mask: 0x count: 0x0
cx23885[0]/0: ts1_status: 0x  ts1_mask: 0x count: 0x20
cx23885[0]/0: ts2_status: 0x  ts2_mask: 0x count: 0xc7383f3a
cx23885[0]/0:  (PCI_MSK_AV_CORE   0x0800)


Igor
--
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: Latest stack that can be merged on top of linux-next tree

[Guennadi Liakhovetski]

Hi Muralidharan

On Thu, 10 Dec 2009, Karicheri, Muralidharan wrote:

> Guennadi,
> 
> I am not sure if your MT9T031 changes are part of linux-next tree at 
> v4l-dvb. If not, can you point me to the latest stack that I can apply 
> on top of linux-next tree to get your latest changes for MT9T031 sensor 
> driver?

As you probably have seen, I posted a pull request a couple of hours ago, 
which also contains the change to mt9t031, that you're asking about.

> I plan to do integrate sensor driver with vpfe capture driver this week.
> 
> BTW, Is there a driver for the PCA9543 i2c switch that is part of 
> MT9T031 headboard?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: IR Receiver on an Tevii S470

[Andy Walls]

On Sat, 2009-12-12 at 02:30 +0200, Igor M. Liplianin wrote:
> On 11 декабря 2009, "Igor M. Liplianin"  wrote:
> > On Thu, 2009-12-10 at 18:16 +0200, Igor M. Liplianin wrote:
> > > On 10 декабря 2009 03:12:39 Andy Walls wrote:
> > > > On Wed, 2009-12-09 at 17:54 +0200, Igor M. Liplianin wrote:
> > > > > > > > Igor and Matthias,
> > > > > > > >
> > > > > > > > Please try the changes that I have for the TeVii S470 that are
> > > > > > > > here:
> > > > > > > >
> > > > > > > > http://linuxtv.org/hg/~awalls/cx23885-ir

> > > First try, without pressing IR keys
> > >
> > > cx25840 3-0044: IRQ Enables: rse rte roe
> > > cx25840 3-0044: IRQ Status:  tsr
> > > cx25840 3-0044: IRQ Enables: rse rte roe
> > > irq 16: nobody cared (try booting with the "irqpoll" option)

> > please try again when you have time.
> >
> > # modprobe cx25840 debug=2 ir_debug=2
> > # modprobe cx23885 debug=7
> >
> dmesg is full of repeated lines:
> 
> cx25840 3-0044: AV Core IRQ status (entry):   
> cx25840 3-0044: AV Core IRQ status (exit):   

A strange thing here is that under this condition my changes should
never claim the AV Core interrupt is "handled".  I don't know why you
didn't get the "nobody cared" message again.

> cx23885[0]/0: pci_status: 0x083f4000  pci_mask: 0x0801
> cx23885[0]/0: vida_status: 0x vida_mask: 0x count: 0x0
> cx23885[0]/0: ts1_status: 0x  ts1_mask: 0x count: 0x20
> cx23885[0]/0: ts2_status: 0x  ts2_mask: 0x count: 0xc7383f3a
> cx23885[0]/0:  (PCI_MSK_AV_CORE   0x0800)

I'll read over the documentation again to see if I missed something.
I'll have some changes later tonight that will always try to clear every
interrupt that the AV Core could possibly generate.

-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: IR Receiver on an Tevii S470

[Igor M. Liplianin]

On 12 декабря 2009 03:00:37 Andy Walls wrote:
> On Sat, 2009-12-12 at 02:30 +0200, Igor M. Liplianin wrote:
> > On 11 декабря 2009, "Igor M. Liplianin"  wrote:
> > > On Thu, 2009-12-10 at 18:16 +0200, Igor M. Liplianin wrote:
> > > > On 10 декабря 2009 03:12:39 Andy Walls wrote:
> > > > > On Wed, 2009-12-09 at 17:54 +0200, Igor M. Liplianin wrote:
> > > > > > > > > Igor and Matthias,
> > > > > > > > >
> > > > > > > > > Please try the changes that I have for the TeVii S470 that
> > > > > > > > > are here:
> > > > > > > > >
> > > > > > > > >   http://linuxtv.org/hg/~awalls/cx23885-ir
> > > >
> > > > First try, without pressing IR keys
> > > >
> > > > cx25840 3-0044: IRQ Enables: rse rte roe
> > > > cx25840 3-0044: IRQ Status:  tsr
> > > > cx25840 3-0044: IRQ Enables: rse rte roe
> > > > irq 16: nobody cared (try booting with the "irqpoll" option)
> > >
> > > please try again when you have time.
> > >
> > >   # modprobe cx25840 debug=2 ir_debug=2
> > >   # modprobe cx23885 debug=7
> >
> > dmesg is full of repeated lines:
> >
> > cx25840 3-0044: AV Core IRQ status (entry):
> > cx25840 3-0044: AV Core IRQ status (exit):
>
> A strange thing here is that under this condition my changes should
> never claim the AV Core interrupt is "handled".  I don't know why you
> didn't get the "nobody cared" message again.
I did, but not frequently. I thought it is obvious :)

cx23885[0]/0: pci_status: 0x083f4000  pci_mask: 0x0801
cx23885[0]/0: vida_status: 0x vida_mask: 0x count: 0x0
cx23885[0]/0: ts1_status: 0x  ts1_mask: 0x count: 0x20
cx23885[0]/0: ts2_status: 0x  ts2_mask: 0x count: 0xc7383f3a
cx23885[0]/0:  (PCI_MSK_AV_CORE   0x0800)
cx25840 3-0044: AV Core IRQ status (entry):   
cx25840 3-0044: AV Core IRQ status (exit):   
irq 16: nobody cared (try booting with the "irqpoll" option)
Pid: 2521, comm: syslogd Not tainted 2.6.32 #2
Call Trace:
 [] ? __report_bad_irq+0x24/0x69
 [] ? __report_bad_irq+0x2b/0x69
 [] ? note_interrupt+0xe7/0x13f
 [] ? handle_fasteoi_irq+0x7a/0x97
 [] ? handle_irq+0x38/0x3f
 [] ? do_IRQ+0x38/0x89
 [] ? common_interrupt+0x29/0x30
handlers:
[] (usb_hcd_irq+0x0/0x59)
[] (azx_interrupt+0x0/0xe7 [snd_hda_intel])
[] (cx23885_irq+0x0/0x4e1 [cx23885])
Disabling IRQ #16
cx23885[0]/0: pci_status: 0x083f4000  pci_mask: 0x0801
cx23885[0]/0: vida_status: 0x vida_mask: 0x count: 0x0
cx23885[0]/0: ts1_status: 0x  ts1_mask: 0x count: 0x20
cx23885[0]/0: ts2_status: 0x  ts2_mask: 0x count: 0xc7383f3a
cx23885[0]/0:  (PCI_MSK_AV_CORE   0x0800)

Igor

--
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: IR Receiver on an Tevii S470

[Andy Walls]

On Sat, 2009-12-12 at 03:42 +0200, Igor M. Liplianin wrote:
> On 12 декабря 2009 03:00:37 Andy Walls wrote:
> > On Sat, 2009-12-12 at 02:30 +0200, Igor M. Liplianin wrote:
> > > On 11 декабря 2009, "Igor M. Liplianin"  wrote:
> > > > On Thu, 2009-12-10 at 18:16 +0200, Igor M. Liplianin wrote:
> > > > > On 10 декабря 2009 03:12:39 Andy Walls wrote:
> > > > > > On Wed, 2009-12-09 at 17:54 +0200, Igor M. Liplianin wrote:
> > > > > > > > > > Igor and Matthias,
> > > > > > > > > >
> > > > > > > > > > Please try the changes that I have for the TeVii S470 that
> > > > > > > > > > are here:
> > > > > > > > > >
> > > > > > > > > > http://linuxtv.org/hg/~awalls/cx23885-ir
> > > > >
> > > > > First try, without pressing IR keys
> > > > >
> > > > > cx25840 3-0044: IRQ Enables: rse rte roe
> > > > > cx25840 3-0044: IRQ Status:  tsr
> > > > > cx25840 3-0044: IRQ Enables: rse rte roe
> > > > > irq 16: nobody cared (try booting with the "irqpoll" option)
> > > >
> > > > please try again when you have time.
> > > >
> > > > # modprobe cx25840 debug=2 ir_debug=2
> > > > # modprobe cx23885 debug=7
> > >
> > > dmesg is full of repeated lines:
> > >
> > > cx25840 3-0044: AV Core IRQ status (entry):
> > > cx25840 3-0044: AV Core IRQ status (exit):
> >
> > A strange thing here is that under this condition my changes should
> > never claim the AV Core interrupt is "handled".  I don't know why you
> > didn't get the "nobody cared" message again.
> I did, but not frequently. I thought it is obvious :)

OK, that's better. :P

I have checked in more changes, please try when you get the chance.

Please be aware that I reconfigured the drive of one signal PAD in the
AV Core - I'm hoping to stop false interrupts.  I did not reconfigure
the corresponding IO pin in the bridge driver - I left it at whatever
was the default.  


(I think I'm going to have to buy a CX23885 based card soon...)

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