Re: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?

[Andrey Utkin]

On Sat, Nov 15, 2014 at 6:08 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 Hi Andrey,

 On 11/15/2014 02:48 PM, Andrey Utkin wrote:
 Thanks to all for the great help so far, but I've got another issue
 with upstream driver.

 In upstream there's no more module parameter for video standard
 (NTSC/PAL). But there's VIDIOC_S_STD handling procedure. But it turns
 out not to work correctly: the frame is offset, so that in the bottom
 there's black horizontal bar.
 The S_STD ioctl call actually makes difference, because without that
 the frame slides vertically all the time. But after the call the
 picture is not correct.

 That's strange. I know I tested it at the time. I assume it is the PAL
 standard that isn't working (as opposed to NTSC)? Or does it just always
 fail when you switch between the two standards?

Switching to PAL is not working (NTSC is default).
Not sure if it fails to make _any_ switching, or whether it fails to
switch between (hardcoded or switched) PAL to NTSC. I can test it a
bit later.


 Such change didn't help:
 https://github.com/krieger-od/linux/commit/55b796c010b622430cb85f5b8d7d14fef6f04fb4
 So, temporarily, I've hardcoded this for exact customer who uses PAL:
 https://github.com/krieger-od/linux/commit/2c26302dfa6d7aa74cf17a89793daecbb89ae93a
 rmmod/modprobe cycle works fine and doesn't make any difference from
 reboot, but still it works correctly only with PAL hardcoded for the
 first-time initialization.

 Any ideas why wouldn't it work to change the mode after the driver load?

 Not really. I will have to test this next week (either Monday or Friday) with
 my solo board.

Thanks in advance.

 Would it be allowed to add back that kernel module parameter (the one
 passed at module load time)?

 No. That's a hack, the S_STD call should just work and we need to figure out
 why it fails.

Ok.

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

Re: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?

[Krzysztof Hałasa]

Andrey Utkin andrey.ut...@corp.bluecherry.net writes:

 In upstream there's no more module parameter for video standard
 (NTSC/PAL). But there's VIDIOC_S_STD handling procedure. But it turns
 out not to work correctly: the frame is offset, so that in the bottom
 there's black horizontal bar.
 The S_STD ioctl call actually makes difference, because without that
 the frame slides vertically all the time. But after the call the
 picture is not correct.

Which kernel version are you using?
I remember there were some problems with earlier versions, where the
NTSC vs PAL wasn't consistenly a bool but rather a raw register value
(or something like this), but it was fixed last time I checked.
I'm personally using SOLO6110-based cards with v3.17 and PAL and it
works, with minimal unrelated patches.

 Any ideas why wouldn't it work to change the mode after the driver load?
 Would it be allowed to add back that kernel module parameter (the one
 passed at module load time)?

I don't think this alone would help.

Looking at my patch queue (will try to remember to have them posted)...
Well, it could be the SDRAM size detection routine. I'm using cards with
64 MB of RAM and the routine repeatedly detected 128 MB or so (max
supported). I have a temporary fix for this but it needs a bit more
work, I have seen a case when it failed (I'm using ARM and MIPS
platforms and they may differ from x86 in endianness, cache coherency
etc).

If you have a card with 64 MB RAM you may want to check if the driver
detects it correctly, and if not e.g. hardcode the size. Otherwise,
I have no idea what could be wrong, it works for me.
-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
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: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?

[Andrey Utkin]

On Sun, Nov 16, 2014 at 12:42 AM, Krzysztof Hałasa khal...@piap.pl wrote:
 Andrey Utkin andrey.ut...@corp.bluecherry.net writes:

 In upstream there's no more module parameter for video standard
 (NTSC/PAL). But there's VIDIOC_S_STD handling procedure. But it turns
 out not to work correctly: the frame is offset, so that in the bottom
 there's black horizontal bar.
 The S_STD ioctl call actually makes difference, because without that
 the frame slides vertically all the time. But after the call the
 picture is not correct.

 Which kernel version are you using?

linux-next from Oct 31 with few my patches which are not in linux-next yet.


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

Re: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?

[Krzysztof Hałasa]

Andrey Utkin andrey.ut...@corp.bluecherry.net writes:

 The problem is the following: after ~1 hour of uptime with working
 application reading the streams, one card (the same one every time)
 stops producing interrupts (counter in /proc/interrupts freezes), and
 all threads reading from that card hang forever in
 ioctl(VIDIOC_DQBUF).

There is a race condition in the IRQ handler, at least in 3.17.
I don't know if it's related, will post a patch.
-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
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: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?

[Andrey Utkin]

2014-11-14 15:00 GMT+04:00 Krzysztof Hałasa khal...@piap.pl:
 There is a race condition in the IRQ handler, at least in 3.17.
 I don't know if it's related, will post a patch.

Thank you for your interest.
Looking forward for your patch. If you don't have time, please just
say what races with what, I'll check by myself.

-- 
Andrey Utkin
--
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: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?

[Andrey Utkin]

On Tue, Nov 11, 2014 at 10:16 PM, Andrey Utkin
andrey.ut...@corp.bluecherry.net wrote:
 On Tue, Nov 11, 2014 at 8:05 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 I would first try to exclude hardware issues: since you say it is always
 the same card, try either replacing it or swapping it with another solo
 card and see if the problem follows the card or not. If it does, then it
 is likely a hardware problem. If it doesn't, then it suggests a race
 condition in the interrupt handling somewhere.

 Thanks for reply, Hans.
 Surely valid idea. I will ask for this, but it is out of my physical reach.
 If you have any suspects about driver code, please let me know.

(We haven't tested the replacement yet.)
To the big surprise, it turned out that FPS=2 on the channels works
unstable, but FPS=30 works stable.

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

[RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?

[Andrey Utkin]

At Bluecherry, we have issues with servers which have 3 solo6110 cards
(and cards have up to 16 analog video cameras connected to them, and
being actively read).
This is a kernel which I tested with such a server last time. It is
based on linux-next of October, 31, with few patches of mine (all are
in review for upstream).
https://github.com/krieger-od/linux/ . The HEAD commit is
949e18db86ebf45acab91d188b247abd40b6e2a1 at the moment.

The problem is the following: after ~1 hour of uptime with working
application reading the streams, one card (the same one every time)
stops producing interrupts (counter in /proc/interrupts freezes), and
all threads reading from that card hang forever in
ioctl(VIDIOC_DQBUF). The application uses libavformat (ffmpeg) API to
read the corresponding /dev/videoX devices of H264 encoders.
Application restart doesn't help, just interrupt counter increases by
64. To help that, we need reboot or programmatic PCI device reset by
echo 1  /sys/bus/pci/devices/\:03\:05.0/reset, which requires
unloading app and driver and is not a solution obviously.

We had this issue for a long time, even before we used libavformat for
reading from such sources.
A few days ago, we had standalone ffmpeg processes working stable for
several days. The kernel was 3.17, the only probably-relevant change
in code over the above mentioned revision is an additional bool
variable set in solo_enc_v4l2_isr() and checked in solo_ring_thread()
to figure out whether to do or skip solo_handle_ring(). The variable
was guarded with spin_lock_irqsave(). I am not sure if it makes any
difference, will try it again eventually.

Any thoughts, can it be a bug in driver code causing that (please
point which areas of code to review/fix)? Or is that desperate
hardware issue? How to figure out for sure whether it is the former or
the latter?

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

Re: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?

[Hans Verkuil]

On 11/11/2014 06:46 PM, Andrey Utkin wrote:
 At Bluecherry, we have issues with servers which have 3 solo6110 cards
 (and cards have up to 16 analog video cameras connected to them, and
 being actively read).
 This is a kernel which I tested with such a server last time. It is
 based on linux-next of October, 31, with few patches of mine (all are
 in review for upstream).
 https://github.com/krieger-od/linux/ . The HEAD commit is
 949e18db86ebf45acab91d188b247abd40b6e2a1 at the moment.
 
 The problem is the following: after ~1 hour of uptime with working
 application reading the streams, one card (the same one every time)
 stops producing interrupts (counter in /proc/interrupts freezes), and
 all threads reading from that card hang forever in
 ioctl(VIDIOC_DQBUF). The application uses libavformat (ffmpeg) API to
 read the corresponding /dev/videoX devices of H264 encoders.
 Application restart doesn't help, just interrupt counter increases by
 64. To help that, we need reboot or programmatic PCI device reset by
 echo 1  /sys/bus/pci/devices/\:03\:05.0/reset, which requires
 unloading app and driver and is not a solution obviously.
 
 We had this issue for a long time, even before we used libavformat for
 reading from such sources.
 A few days ago, we had standalone ffmpeg processes working stable for
 several days. The kernel was 3.17, the only probably-relevant change
 in code over the above mentioned revision is an additional bool
 variable set in solo_enc_v4l2_isr() and checked in solo_ring_thread()
 to figure out whether to do or skip solo_handle_ring(). The variable
 was guarded with spin_lock_irqsave(). I am not sure if it makes any
 difference, will try it again eventually.
 
 Any thoughts, can it be a bug in driver code causing that (please
 point which areas of code to review/fix)? Or is that desperate
 hardware issue? How to figure out for sure whether it is the former or
 the latter?

I would first try to exclude hardware issues: since you say it is always
the same card, try either replacing it or swapping it with another solo
card and see if the problem follows the card or not. If it does, then it
is likely a hardware problem. If it doesn't, then it suggests a race
condition in the interrupt handling somewhere.

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: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?

[Andrey Utkin]

On Tue, Nov 11, 2014 at 8:05 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 I would first try to exclude hardware issues: since you say it is always
 the same card, try either replacing it or swapping it with another solo
 card and see if the problem follows the card or not. If it does, then it
 is likely a hardware problem. If it doesn't, then it suggests a race
 condition in the interrupt handling somewhere.

Thanks for reply, Hans.
Surely valid idea. I will ask for this, but it is out of my physical reach.
If you have any suspects about driver code, please let me know.

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

Help required for TVP5151 on Overo

[Francesco Marletta]

Hello to everyone,
I'd like to know who have used the TVP5151 video decoder with the OMAP3
Overo module.

I'm trying to have the processor to capture the video from a TVP5151
boarda, but without success (both gstreamer and yavta wait forever the
data from the V4L2 subsystem).

Thanks in advance!
--
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

I Need A Help from You

[Raymond Walter]

-- 
I came down to  Russia  for a short vacation. Unfortunately, i was mugged at 
the park of the hotel where i stayed. All cash, credit cards and mobile phones 
were stolen from me but luckily i still have my passport with me. I've been to 
the Embassy and the Police here but they're not helping issues at all the bad 
news is my flight will be leaving in less than 8-hrs from now but i am having 
problems settling the hotel bills and the hotel manager won't let me leave 
until i settle the bills. I'll need your help (LOAN) financially of $2,530 USD. 
I promise to make the refund once i get back home. Please let me know how you 
can help and I need you to keep me posted via email.





Bu e-posta (ve ekler) mesaji, mesajin alici kisminda belirtilmis olan kullanici 
icindir ve sadece gonderilen kisiye yoneliktir. Bu e-postayi yanlislikla 
aldiysaniz, lutfen dogrudan veya dolayli olarak mesaji kullanmayiniz, yollayan 
kisiyi bilgilendirip mesajin tum kopyalarini sisteminizden derhal siliniz. E- 
posta iletiminin guvenli veya hatasiz oldugunun garantisi olmadigindan gec veya 
eksik iletim veya icerik ve bilgilerde eksiklik, kayip, degisiklik veya virus 
olabileceginden, bu mesajin iletiminden, icerikteki hatadan, eksiklikten, 
dogrulugun ve gizliligin ihlalinden veya bu yolla bilgi paylasimi, iletimi, 
depolanmasi gibi herhangi bir kullanimdan Universitemiz hicbir sekilde sorumlu 
degildir. Bu mesajin icerigi yazarina ait olup hicbir sekilde Yuzuncu Yil 
Universitesi'ne atfedilemeyecegi gibi, Universitemizi baglayici da degildir.


This e-mail (and the attachments), is solely for the individual or the entity 
who has been mentioned specifically in the recipient section of the e- mail and 
intended solely for the addressee. If you are not the recipient of this message 
or the intended addressee (or if you have received it accidentally), please do 
not use it directly or indirectly and delete the message and all its copies 
from your system by notifying the sender immediately. Since safe and healthy 
transmission of an e-mail cannot be guaranteed and there is a possibility of 
delayed or incomplete delivery of a message or absence, loss, change or 
presence of virus in content and information,Yuzuncu Yil University is not 
liable for the delivery of the message; the fault and incompleteness in the 
content; violation of confidentiality or integrity; or sharing, transmission 
and storage of information via this way. The content of the message does solely 
belong to the writer of it and under no circumstances can be endorsed b
 y Yuzuncu Yil University. Also, Yuzuncu Yil University does not accept any 
legal responsibility whatsoever for the content of the message. 
--
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

Help required

[Vishwanatha Hattera]

Hi
While doing some experiment I have done git commit and sent the mail
with subject [PATCH] added new files Signed-off-by: Vishwanatha Hatter
vishwanatha.hatt...@itasin.com  Please ignore and remove this from
the mailing list.

Regards,
Vishwa

-- 
iTAS Innovations Pvt. Ltd.
#1585, 3rd floor, B-Block, Sahakaranagar,
Bangalore, Karanataka, India, pin: 560092
Email:vishwanatha.hatt...@itasin.com
Phone: +91-80-41675006
Mob: +91-9945089777

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

Help!

[Raymond Jender]

Since I appear to be reaching the list, here goes.

I am running Ubuntu 12.04.  I have a Sabrent USB 2.0 grabber with a
Sony HDR SR11 plugged into it.
I am using the most current stk1160 driver.

I can see video using Camorama as well as a couple other tools.

Skype does not see my video.  Yahoo Messenger does see my video.
WebRTC does not access my camera.

Any ideas how I can trouble shoot this?

Thanks,

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

help needed to install and run (in Zoneminder) the DVR pci card JY 4008a

[clarkeem]

Are you able to assist with the above running Mageia4 32 bit sys but cannot 
seem to get a camera recognised in either xawtv or zoneminder

Thanks for any help you can give me.Ernie Clarke

clark...@slingshot.co.nz
--
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

Help needed for TechniSat Skystar 2 HD

[Andreas Pilz]

Dear DVB-S2 Knowers!

I am trying to get with a new kernel my two TechniSat Skystar HD 2 working.

I have 3 cards:

05:00.0 0480: 1822:4e35 (rev 01)
Subsystem: 153b:1179
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
TAbort+ MAbort- SERR- PERR- INTx-
Latency: 64 (2000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fafff000 (32-bit, prefetchable) [size=4K]
Kernel driver in use: Mantis
Kernel modules: mantis

05:01.0 0480: 1822:4e35 (rev 01)
Subsystem: 1ae4:0003
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
TAbort+ MAbort- SERR- PERR- INTx-
Latency: 64 (2000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 17
Region 0: Memory at faffe000 (32-bit, prefetchable) [size=4K]
Kernel driver in use: Mantis
Kernel modules: mantis

05:02.0 0480: 1822:4e35 (rev 01)
Subsystem: 1ae4:0003
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
TAbort+ MAbort- SERR- PERR- INTx-
Latency: 64 (2000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 18
Region 0: Memory at faffd000 (32-bit, prefetchable) [size=4K]
Kernel driver in use: Mantis
Kernel modules: mantis

This is the kernel (from SuSE 13.1):

Linux godiva 3.11.10-7-desktop #1 SMP PREEMPT Mon Feb 3 09:41:24 UTC 
2014 (750023e) x86_64 x86_64 x86_64 GNU/Linux

I used the s2-liplianin-v39 drivers from here :

https://bitbucket.org/CrazyCat/s2-liplianin-v39

as these were the only ones I could compile under this kernel.

lsmod shows all fine, except that a dependency between mantis and stb0899 is 
missing.

Yet, with neither tool I can tune with the first card to Astra 19.2E. Yet, the 
other two cards always report no lock and a timeout of fronted in VDR.

Any hints? Much appreciated.

Thanks

Andi


--
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: Help with SMS2270 @ linux-sunxi (A20 devices)

[Roberto Alcantara]

Guys,

As I could’n some the error I tried another approach.

I checkout commit 80ccb51a from 09/11/2013 as I know it is a working version 
for sms2270 device but not so newer.

I copy siano files from commit 80ccb51a to my kernel tree (3.4.75) and I need 
only disable IR support to compiles without errors.

So, I copy my new kernel and modules to device to test, now device is found 
but...:

root@awsom:~# insmod smsdvb.ko 
insmod: error inserting 'smsdvb.ko': -1 Unknown symbol in module
root@awsom:~# insmod smsmdtv.ko 
root@awsom:~# insmod smsusb.ko 

dmesg:
[  404.935357] smsdvb: Unknown symbol smsendian_handle_tx_message (err 0)
[  404.940520] smsdvb: Unknown symbol smscore_get_device_mode (err 0)
[  404.954893] smsdvb: Unknown symbol smscore_register_client (err 0)
[  404.959986] smsdvb: Unknown symbol sms_board_led_feedback (err 0)
[  404.974160] smsdvb: Unknown symbol sms_board_power (err 0)
[  404.978477] smsdvb: Unknown symbol sms_get_board (err 0)
[  404.983893] smsdvb: Unknown symbol smscore_unregister_hotplug (err 0)
[  405.001147] smsdvb: Unknown symbol smscore_putbuffer (err 0)
[  405.007305] smsdvb: Unknown symbol smsendian_handle_rx_message (err 0)
[  405.012321] smsdvb: Unknown symbol sms_board_lna_control (err 0)
[  405.020188] smsdvb: Unknown symbol smsclient_sendrequest (err 0)
[  405.026278] smsdvb: Unknown symbol smscore_unregister_client (err 0)
[  405.030765] smsdvb: Unknown symbol sms_board_event (err 0)
[  405.036086] smsdvb: Unknown symbol sms_board_setup (err 0)
[  405.040981] smsdvb: Unknown symbol smscore_get_board_id (err 0)
[  405.047036] smsdvb: Unknown symbol smscore_register_hotplug (err 0)
[  415.683285] smsusb_init_device: line: 372: Unspecified sms device type!
[  415.742576] smsusb_init_device: line: 433: smscore_start_device(...) failed
[  415.757505] smsusb_onresponse: line: 143: error, urb status -2, 0 bytes
[  415.770102] smsusb_onresponse: line: 143: error, urb status -2, 0 bytes
[  415.782723] smsusb_onresponse: line: 143: error, urb status -2, 0 bytes
[  415.795353] smsusb_onresponse: line: 143: error, urb status -2, 0 bytes
[  415.807982] smsusb_onresponse: line: 143: error, urb status -2, 0 bytes
[  415.820605] smsusb_onresponse: line: 143: error, urb status -2, 0 bytes
[  415.833095] smsusb_onresponse: line: 143: error, urb status -2, 0 bytes
[  415.845595] smsusb_onresponse: line: 143: error, urb status -2, 0 bytes
[  415.858099] smsusb_onresponse: line: 143: error, urb status -2, 0 bytes
[  415.870594] smsusb_onresponse: line: 143: error, urb status -2, 0 bytes
[  415.927506] smsusb: probe of 1-1.4:1.0 failed with error -2
[  415.933670] usbcore: registered new interface driver smsusb

root@awsom:~# lsusb 
Bus 001 Device 002: ID 058f:6254 Alcor Micro Corp. USB Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 003: ID 0e8f:0021 GreenAsia Inc. Multimedia Keyboard Controller
Bus 001 Device 004: ID 187f:0600 Siano Mobile Silicon 
root@awsom:~# lsmod 
Module  Size  Used by
smsdvb 13909  0 
smsusb 10075  0 
smsmdtv44375  2 smsdvb,smsusb
disp_ump 854  0 
mali_drm2638  1 
mali  113459  0 
ump56392  4 disp_ump,mali
lcd 3646  0 
root@awsom:~# 



[  415.742576] smsusb_init_device: line: 433: smscore_start_device(...) failed

this error starting device can happen because symbols wasn’t found or are 
distinct problems? 


Thank you for any tips.

Best regards,
 - Roberto





Em 17/04/2014, à(s) 00:06, Sat satt...@aim.com escreveu:

 (2014/04/17 10:27), Roberto Alcantara wrote:
 Bad news for me.
 
 I will try to debug something about MTP despite I don’t know yet how to.
 
 I will let know about this guys.
 
 Thank you !
 
 
 Em 16/04/2014, à(s) 13:34, Mauro Carvalho Chehab m.che...@samsung.com 
 escreveu:
 
 
 
 I suspect that it is trying to load this device via smsdio driver, but
 I'm not sure.
 
 Those MTP probe messages look weird to me. I suspect that it didn't even
 called the USB probing method for this device, but I'm not a MTP
 expert.
 
 I also suspect so.
 It seems to step in MTP probing but not USB probing instead.
 In my case, such MTP probe messages doesn't appear as follows:
 
 [   87.008265] usb 1-1.2.4: new high-speed USB device number 7 using dwc_otg
 [   87.109401] usb 1-1.2.4: New USB device found, idVendor=3275, 
 idProduct=0080
 [   87.109441] usb 1-1.2.4: New USB device strings: Mfr=1, Product=2, 
 SerialNumber=0
 [   87.109460] usb 1-1.2.4: Product: PX-S1UD Digital TV Tuner
 [   87.109476] usb 1-1.2.4: Manufacturer: PLEX Digital TV Tuner
 [   87.304940] smscore_load_firmware_family2: line: 986: sending 
 MSG_SMS_DATA_VALIDITY_REQ expecting 0xef779751
 
 
 Regards,
 Satoshi
 
 

Help to solve compile errors in smsusb driver.

[Roberto Alcantara]

Guys,

I’m trying to compile most recent Siano drivers with old kernel tree (3.4.75 
linux-sunxi). The module seems compile but final linker (?) give me a few 
errors. 

smsendian_handle_tx_message is in media/common/siano/smsendian.c as expected.  
All tips are appreciated  ;-)

Thank you !
- Roberto


robertoalcantara@ubuntu:/media/robertoalcantara/awsom-linux-sunxi/linux-sunxi$ 
./build.sh -p awsom20

Using previous  config file .config.awsom20
  CHK include/linux/version.h
  CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
  CALLscripts/checksyscalls.sh
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/gpu/mali/ump/../mali/linux/mali_osk_atomics.o
  CC [M]  drivers/gpu/mali/ump/../mali/linux/mali_osk_locks.o
  CC [M]  drivers/gpu/mali/ump/../mali/linux/mali_osk_memory.o
  CC [M]  drivers/media/dvb/siano/smsusb.o
  CC [M]  drivers/gpu/mali/ump/../mali/linux/mali_osk_math.o
  CC [M]  drivers/gpu/mali/ump/../mali/linux/mali_osk_misc.o
  LD [M]  drivers/gpu/mali/ump/ump.o
  Kernel: arch/arm/boot/Image is ready
  Building modules, stage 2.
  Kernel: arch/arm/boot/zImage is ready
  Image arch/arm/boot/uImage is ready
  MODPOST 138 modules
ERROR: smsendian_handle_tx_message [drivers/media/dvb/siano/smsusb.ko] 
undefined!
ERROR: smscore_registry_getmode [drivers/media/dvb/siano/smsusb.ko] undefined!
ERROR: sms_board_load_modules [drivers/media/dvb/siano/smsusb.ko] undefined!
ERROR: smscore_start_device [drivers/media/dvb/siano/smsusb.ko] undefined!
ERROR: smscore_set_board_id [drivers/media/dvb/siano/smsusb.ko] undefined!
ERROR: smscore_register_device [drivers/media/dvb/siano/smsusb.ko] undefined!
ERROR: sms_get_board [drivers/media/dvb/siano/smsusb.ko] undefined!
ERROR: smscore_translate_msg [drivers/media/dvb/siano/smsusb.ko] undefined!
ERROR: smscore_onresponse [drivers/media/dvb/siano/smsusb.ko] undefined!
ERROR: smsendian_handle_rx_message [drivers/media/dvb/siano/smsusb.ko] 
undefined!
ERROR: smsendian_handle_message_header [drivers/media/dvb/siano/smsusb.ko] 
undefined!
ERROR: smscore_getbuffer [drivers/media/dvb/siano/smsusb.ko] undefined!
ERROR: smscore_unregister_device [drivers/media/dvb/siano/smsusb.ko] 
undefined!
ERROR: smscore_putbuffer [drivers/media/dvb/siano/smsusb.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
robertoalcantara@ubuntu:/media/robertoalcantara/awsom-linux-sunxi/linux-sunxi$ 
--
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: Help with SMS2270 @ linux-sunxi (A20 devices)

[Sat]

Hi Roberto,

Did you check if the device id of your tuner is included in smsusb.c?
id can be gotten by lsusb command.

Thanks,
Satoshi

(2014/04/16 8:28), Roberto Alcantara wrote:

Guys,

I’m trying enable Siano SMS2270 ISDB-T tuner in development board with 
Allwinner A20 SoC.

I recompiled kernel with modules I can load them but something seems wrong. 
After insert USB Sms2270 dongle I only see:

Jan  1 00:15:20 awsom kernel: [  922.645502] usb 1-1.4: new high-speed USB 
device number 6 using sw-ehci
Jan  1 00:15:20 awsom mtp-probe: checking bus 1, device 6: 
/sys/devices/platform/sw-ehci.1/usb1/1-1/1-1.4
Jan  1 00:15:20 awsom mtp-probe: bus: 1, device: 6 was not an MTP device

and no more logs.

smsusb was loaded with debug=2.

The usb dongle is plugged on usb powered hub and other devices like keyboard 
are working fine with this hub port.

What I missing here? Thanks for all tips !  :-)

Best regards,
  - Roberto


root@awsom:/home/linaro# lsmod
Module  Size  Used by
sunxi_cedar_mod10284  0
smsdvb 13909  0
smsusb  8936  0
smsmdtv28266  2 smsdvb,smsusb
disp_ump 854  0
mali_drm2638  1
mali  113459  0
ump56392  4 disp_ump,mali
lcd 3646  0

root@awsom:/home/linaro# lsusb
Bus 001 Device 002: ID 058f:6254 Alcor Micro Corp. USB Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 003: ID 0e8f:0021 GreenAsia Inc. Multimedia Keyboard Controller
Bus 001 Device 004: ID 187f:0600 Siano Mobile Silicon

root@awsom:/home/linaro# uname -a
Linux awsom 3.4.75.sun7i_CRAFF+ #4 SMP PREEMPT Thu Apr 10 01:17:47 BRT 2014 
armv7l armv7l armv7l GNU/Linux




root@awsom:/home/linaro# lsusb -v

Bus 001 Device 002: ID 058f:6254 Alcor Micro Corp. USB Hub
Device Descriptor:
   bLength18
   bDescriptorType 1
   bcdUSB   2.00
   bDeviceClass9 Hub
   bDeviceSubClass 0 Unused
   bDeviceProtocol 1 Single TT
   bMaxPacketSize064
   idVendor   0x058f Alcor Micro Corp.
   idProduct  0x6254 USB Hub
   bcdDevice1.00
   iManufacturer   0
   iProduct1 USB2.0Hub
   iSerial 0
   bNumConfigurations  1
   Configuration Descriptor:
 bLength 9
 bDescriptorType 2
 wTotalLength   25
 bNumInterfaces  1
 bConfigurationValue 1
 iConfiguration  0
 bmAttributes 0xe0
   Self Powered
   Remote Wakeup
 MaxPower  100mA
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber0
   bAlternateSetting   0
   bNumEndpoints   1
   bInterfaceClass 9 Hub
   bInterfaceSubClass  0 Unused
   bInterfaceProtocol  0 Full speed (or root) hub
   iInterface  0
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x81  EP 1 IN
 bmAttributes3
   Transfer TypeInterrupt
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0001  1x 1 bytes
 bInterval  12
Hub Descriptor:
   bLength   9
   bDescriptorType  41
   nNbrPorts 4
   wHubCharacteristic 0x0080
 Ganged power switching
 Ganged overcurrent protection
 TT think time 8 FS bits
 Port indicators
   bPwrOn2PwrGood   50 * 2 milli seconds
   bHubContrCurrent100 milli Ampere
   DeviceRemovable0x00
   PortPwrCtrlMask0xff
  Hub Port Status:
Port 1: .0303 lowspeed power enable connect
Port 2: .0100 power
Port 3: .0100 power
Port 4: .0503 highspeed power enable connect
Device Qualifier (for other device speed):
   bLength10
   bDescriptorType 6
   bcdUSB   2.00
   bDeviceClass9 Hub
   bDeviceSubClass 0 Unused
   bDeviceProtocol 0 Full speed (or root) hub
   bMaxPacketSize064
   bNumConfigurations  1
Device Status: 0x0001
   Self Powered

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
   bLength18
   bDescriptorType 1
   bcdUSB   2.00
   bDeviceClass9 Hub
   bDeviceSubClass 0 Unused
   bDeviceProtocol 0 Full speed (or root) hub
   bMaxPacketSize064
   idVendor   0x1d6b Linux Foundation
   idProduct  0x0002 2.0 root hub
   bcdDevice3.04
   iManufacturer   3 Linux 3.4.75.sun7i_CRAFF+ 

Re: Help with SMS2270 @ linux-sunxi (A20 devices)

[Mauro Carvalho Chehab]

Em Wed, 16 Apr 2014 17:51:21 +0900
Sat satt...@aim.com escreveu:

 Hi Roberto,
 
 Did you check if the device id of your tuner is included in smsusb.c?
 id can be gotten by lsusb command.
 
 Thanks,
 Satoshi
 
 (2014/04/16 8:28), Roberto Alcantara wrote:
  Guys,
 
  I’m trying enable Siano SMS2270 ISDB-T tuner in development board with 
  Allwinner A20 SoC.
 
  I recompiled kernel with modules I can load them but something seems wrong. 
  After insert USB Sms2270 dongle I only see:
 
  Jan  1 00:15:20 awsom kernel: [  922.645502] usb 1-1.4: new high-speed USB 
  device number 6 using sw-ehci
  Jan  1 00:15:20 awsom mtp-probe: checking bus 1, device 6: 
  /sys/devices/platform/sw-ehci.1/usb1/1-1/1-1.4
  Jan  1 00:15:20 awsom mtp-probe: bus: 1, device: 6 was not an MTP device
 
  and no more logs.
 
  smsusb was loaded with debug=2.
 
  The usb dongle is plugged on usb powered hub and other devices like 
  keyboard are working fine with this hub port.
 
  What I missing here? Thanks for all tips !  :-)

I suspect that it is trying to load this device via smsdio driver, but
I'm not sure.

Those MTP probe messages look weird to me. I suspect that it didn't even
called the USB probing method for this device, but I'm not a MTP
expert.

Regards,
Mauro

 
  Best regards,
- Roberto
 
 
  root@awsom:/home/linaro# lsmod
  Module  Size  Used by
  sunxi_cedar_mod10284  0
  smsdvb 13909  0
  smsusb  8936  0
  smsmdtv28266  2 smsdvb,smsusb
  disp_ump 854  0
  mali_drm2638  1
  mali  113459  0
  ump56392  4 disp_ump,mali
  lcd 3646  0
 
  root@awsom:/home/linaro# lsusb
  Bus 001 Device 002: ID 058f:6254 Alcor Micro Corp. USB Hub
  Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  Bus 001 Device 003: ID 0e8f:0021 GreenAsia Inc. Multimedia Keyboard 
  Controller
  Bus 001 Device 004: ID 187f:0600 Siano Mobile Silicon
 
  root@awsom:/home/linaro# uname -a
  Linux awsom 3.4.75.sun7i_CRAFF+ #4 SMP PREEMPT Thu Apr 10 01:17:47 BRT 2014 
  armv7l armv7l armv7l GNU/Linux
 
 
 
 
  root@awsom:/home/linaro# lsusb -v
 
  Bus 001 Device 002: ID 058f:6254 Alcor Micro Corp. USB Hub
  Device Descriptor:
 bLength18
 bDescriptorType 1
 bcdUSB   2.00
 bDeviceClass9 Hub
 bDeviceSubClass 0 Unused
 bDeviceProtocol 1 Single TT
 bMaxPacketSize064
 idVendor   0x058f Alcor Micro Corp.
 idProduct  0x6254 USB Hub
 bcdDevice1.00
 iManufacturer   0
 iProduct1 USB2.0Hub
 iSerial 0
 bNumConfigurations  1
 Configuration Descriptor:
   bLength 9
   bDescriptorType 2
   wTotalLength   25
   bNumInterfaces  1
   bConfigurationValue 1
   iConfiguration  0
   bmAttributes 0xe0
 Self Powered
 Remote Wakeup
   MaxPower  100mA
   Interface Descriptor:
 bLength 9
 bDescriptorType 4
 bInterfaceNumber0
 bAlternateSetting   0
 bNumEndpoints   1
 bInterfaceClass 9 Hub
 bInterfaceSubClass  0 Unused
 bInterfaceProtocol  0 Full speed (or root) hub
 iInterface  0
 Endpoint Descriptor:
   bLength 7
   bDescriptorType 5
   bEndpointAddress 0x81  EP 1 IN
   bmAttributes3
 Transfer TypeInterrupt
 Synch Type   None
 Usage Type   Data
   wMaxPacketSize 0x0001  1x 1 bytes
   bInterval  12
  Hub Descriptor:
 bLength   9
 bDescriptorType  41
 nNbrPorts 4
 wHubCharacteristic 0x0080
   Ganged power switching
   Ganged overcurrent protection
   TT think time 8 FS bits
   Port indicators
 bPwrOn2PwrGood   50 * 2 milli seconds
 bHubContrCurrent100 milli Ampere
 DeviceRemovable0x00
 PortPwrCtrlMask0xff
Hub Port Status:
  Port 1: .0303 lowspeed power enable connect
  Port 2: .0100 power
  Port 3: .0100 power
  Port 4: .0503 highspeed power enable connect
  Device Qualifier (for other device speed):
 bLength10
 bDescriptorType 6
 bcdUSB   2.00
 bDeviceClass9 Hub
 bDeviceSubClass 0 Unused
 bDeviceProtocol 0 Full speed (or root) hub
 bMaxPacketSize064

Re: Help with SMS2270 @ linux-sunxi (A20 devices)

[Roberto Alcantara]

Bad news for me.

I will try to debug something about MTP despite I don’t know yet how to. 

I will let know about this guys.

Thank you !


Em 16/04/2014, à(s) 13:34, Mauro Carvalho Chehab m.che...@samsung.com 
escreveu:

 
 
 I suspect that it is trying to load this device via smsdio driver, but
 I'm not sure.
 
 Those MTP probe messages look weird to me. I suspect that it didn't even
 called the USB probing method for this device, but I'm not a MTP
 expert.
 
 Regards,
 Mauro
 
 
 Best regards,
  - Roberto
 
 
 root@awsom:/home/linaro# lsmod
 Module  Size  Used by
 sunxi_cedar_mod10284  0
 smsdvb 13909  0
 smsusb  8936  0
 smsmdtv28266  2 smsdvb,smsusb
 disp_ump 854  0
 mali_drm2638  1
 mali  113459  0
 ump56392  4 disp_ump,mali
 lcd 3646  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: Help with SMS2270 @ linux-sunxi (A20 devices)

[Sat]

(2014/04/17 10:27), Roberto Alcantara wrote:

Bad news for me.

I will try to debug something about MTP despite I don’t know yet how to.

I will let know about this guys.

Thank you !


Em 16/04/2014, à(s) 13:34, Mauro Carvalho Chehab m.che...@samsung.com 
escreveu:




I suspect that it is trying to load this device via smsdio driver, but
I'm not sure.

Those MTP probe messages look weird to me. I suspect that it didn't even
called the USB probing method for this device, but I'm not a MTP
expert.


I also suspect so.
It seems to step in MTP probing but not USB probing instead.
In my case, such MTP probe messages doesn't appear as follows:

[   87.008265] usb 1-1.2.4: new high-speed USB device number 7 using dwc_otg
[   87.109401] usb 1-1.2.4: New USB device found, idVendor=3275, 
idProduct=0080
[   87.109441] usb 1-1.2.4: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0

[   87.109460] usb 1-1.2.4: Product: PX-S1UD Digital TV Tuner
[   87.109476] usb 1-1.2.4: Manufacturer: PLEX Digital TV Tuner
[   87.304940] smscore_load_firmware_family2: line: 986: sending 
MSG_SMS_DATA_VALIDITY_REQ expecting 0xef779751



Regards,
Satoshi


Regards,
Mauro



Best regards,
  - Roberto


root@awsom:/home/linaro# lsmod
Module  Size  Used by
sunxi_cedar_mod10284  0
smsdvb 13909  0
smsusb  8936  0
smsmdtv28266  2 smsdvb,smsusb
disp_ump 854  0
mali_drm2638  1
mali  113459  0
ump56392  4 disp_ump,mali
lcd 3646  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

Help with SMS2270 @ linux-sunxi (A20 devices)

[Roberto Alcantara]

Guys,

I’m trying enable Siano SMS2270 ISDB-T tuner in development board with 
Allwinner A20 SoC.

I recompiled kernel with modules I can load them but something seems wrong. 
After insert USB Sms2270 dongle I only see:

Jan  1 00:15:20 awsom kernel: [  922.645502] usb 1-1.4: new high-speed USB 
device number 6 using sw-ehci
Jan  1 00:15:20 awsom mtp-probe: checking bus 1, device 6: 
/sys/devices/platform/sw-ehci.1/usb1/1-1/1-1.4
Jan  1 00:15:20 awsom mtp-probe: bus: 1, device: 6 was not an MTP device

and no more logs.

smsusb was loaded with debug=2.

The usb dongle is plugged on usb powered hub and other devices like keyboard 
are working fine with this hub port.

What I missing here? Thanks for all tips !  :-)

Best regards,
 - Roberto


root@awsom:/home/linaro# lsmod
Module  Size  Used by
sunxi_cedar_mod10284  0
smsdvb 13909  0
smsusb  8936  0
smsmdtv28266  2 smsdvb,smsusb
disp_ump 854  0
mali_drm2638  1
mali  113459  0
ump56392  4 disp_ump,mali
lcd 3646  0

root@awsom:/home/linaro# lsusb
Bus 001 Device 002: ID 058f:6254 Alcor Micro Corp. USB Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 003: ID 0e8f:0021 GreenAsia Inc. Multimedia Keyboard Controller
Bus 001 Device 004: ID 187f:0600 Siano Mobile Silicon

root@awsom:/home/linaro# uname -a
Linux awsom 3.4.75.sun7i_CRAFF+ #4 SMP PREEMPT Thu Apr 10 01:17:47 BRT 2014 
armv7l armv7l armv7l GNU/Linux




root@awsom:/home/linaro# lsusb -v

Bus 001 Device 002: ID 058f:6254 Alcor Micro Corp. USB Hub
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 1 Single TT
  bMaxPacketSize064
  idVendor   0x058f Alcor Micro Corp.
  idProduct  0x6254 USB Hub
  bcdDevice1.00
  iManufacturer   0
  iProduct1 USB2.0Hub
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0001  1x 1 bytes
bInterval  12
Hub Descriptor:
  bLength   9
  bDescriptorType  41
  nNbrPorts 4
  wHubCharacteristic 0x0080
Ganged power switching
Ganged overcurrent protection
TT think time 8 FS bits
Port indicators
  bPwrOn2PwrGood   50 * 2 milli seconds
  bHubContrCurrent100 milli Ampere
  DeviceRemovable0x00
  PortPwrCtrlMask0xff
 Hub Port Status:
   Port 1: .0303 lowspeed power enable connect
   Port 2: .0100 power
   Port 3: .0100 power
   Port 4: .0503 highspeed power enable connect
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize064
  bNumConfigurations  1
Device Status: 0x0001
  Self Powered

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize064
  idVendor   0x1d6b Linux Foundation
  idProduct  0x0002 2.0 root hub
  bcdDevice3.04
  iManufacturer   3 Linux 3.4.75.sun7i_CRAFF+ ehci_hcd
  iProduct2 SW USB2.0 'Enhanced' Host Controller (EHCI) Driver
  iSerial 1 sw-ehci
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
   

Kworld PlusTV All in One PI610 - need help

[Julian Day]

Hi,

I have this board which I think is about 2007 vintange. It has a PLX
PCI6140 PCI-PCI bridge, with both a TI TSB43AB22 IEEE1394 FireWire
controller and an NXP SAA7131E on the far side.

The tuner is a TDA8275A and the DVB-T decoder is the TDA10046A. It
reports a subsystem ID of 17de:7256.

The card has inputs for DVB-T/ATV, FM, S-Video, composite, stereo
audio and IR remote in addition to two Firewire ports.

In saa7134-cards.c I added an entry to the saa7134_pci_tbl so that it
is recognised. I also created a new entry in saa7134_boards, so that I
can experiment with the settings for this card, as I don't know that
it is going to be exactly the same as anything else:

[SAA7134_BOARD_KWORLD_PI610] = {
.name  = Kworld PlusTV All in One (PI610),
.tuner_type= TUNER_PHILIPS_TDA8290,
.radio_type= UNSET,
.tuner_addr= ADDR_UNSET,
.radio_addr= ADDR_UNSET,
.mpeg  = SAA7134_MPEG_DVB,
.inputs = {{
.name = name_tv,
.vmux = 1,
.amux = TV,
.tv   = 1,
}},
.radio = {
.name = name_radio,
.amux = TV,
}

I know I could probably add more inputs for the Composite/S-Video
inputs, but I don't know which mux settings they would be on yet, I
suspect that is trial and error. Also probably a bit more is needed to
get the IR remote working. Is there any wisdom for determining GPIO
settings?

So, next in saa7134-dvb.c, I think I need a tda1004x_config for this
board, so that I can use that in dvb_init(), which is where I'm really
stuck. I've no idea where to get the parameters for this struct.
I presume that agc_config will be TDA_10046_AGC_TDA827x and
.request_firmware will need to be set to
philips_tda1004x_request_firmware.

It seems that existing implementations are either 4MHz or 16MHz
xtal_freq. On this board there is what I take to be a 20.000 MHz
oscillator, (It's just marked 20.000) right next to the TDA10046A, no
sign of either a 4MHz or 16MHz source. How does this relate to
xtal_freq and if_freq? Looking at the dvb frontend for tda1004x.c, it
seems like a PLL is used to generate either a 48MHz or 53MHz clock
from this xtal. I would suppose that 48MHz is correct, in that it
should be like the 16MHz source, but with an N of 4 instead of 3,
which I think would imply that if_freq would be 045.

I guess demod_address is likely to be 0x8 and tuner_address is likely
to be 0x61 or 0x60. I think 0x61 seems more like it. What else needs
to be set there and is there any guidance on how to probe this type of
info?

With these mods scan shows tuning failed for every channel:
 tune to: 
 47400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_16:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
WARNING:  tuning failed!!!

and:
julian@pabay:~$ dmesg |grep -i saa
[   19.248098] saa7130/34: v4l2 driver version 0, 2, 17 loaded
[   19.248462] saa7133[0]: found at :04:08.0, rev: 209, irq: 16,
latency: 64, mmio: 0xfe6fb000
[   19.248467] saa7133[0]: subsystem: 17de:7256, board: Kworld PlusTV
All in One (PI610) [card=193,autodetected]
[   19.248482] saa7133[0]: board init: gpio is 100
[   19.400046] saa7133[0]: i2c eeprom 00: de 17 56 72 54 20 1c 00 43
43 a9 1c 55 d2 b2 92
[   19.400058] saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff
ff ff ff ff ff ff 01
[   19.400068] saa7133[0]: i2c eeprom 20: 01 40 01 03 03 01 01 03 08
ff 00 fe ff ff ff ff
[   19.400077] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   19.400087] saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 03 32 15
56 ff ff ff ff ff ff
[   19.400096] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   19.400106] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   19.400115] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   19.400124] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   19.400134] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   19.400143] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   19.400153] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   19.400162] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   19.400171] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   19.400181] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   19.400190] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff
[   24.053223] saa7133[0]: dsp access wait timeout [bit=WRR]
[   24.053764] saa7133[0]: dsp access wait timeout [bit=WRR]
[   24.116116] saa7133[0]: registered device video0 [v4l2]
[   24.116202] saa7133[0]: registered device vbi0
[   24.116260] saa7133[0]: registered device radio0
[   24.174563] saa7134 ALSA driver for DMA sound loaded
[   24.174590] saa7133[0]/alsa: saa7133[0] at 0xfe6fb000 irq 16
registered as 

Re: Kworld PlusTV All in One PI610 - need help

[Steven Toth]

I don't know the 7131 but the following advice is generic for any USB,
PCI or PCIE device:

Essentially, when correctly configured, the tuner will output an
Intermediate Frequency (IF). This is the frequency you've selected to
tune, for example 474MHz, isolated into a 8MHz band and shifted down
to a different frequency that the 10046 demodulator is designed to
receive. Typicaly IFs are 44Mhz, 6MHz or variations of.

So, rule #1, match the IF on the tuner to the IF settings for the
10046 demodulator. These are typically passed to tuner and demodulator
parts during dvb_attach with tuner and demodualtor specific
structures. Generally, this is very simple to to. If you create a
miss-match, the demodulator is never going to lock, no matter how many
times you tune the tuner to a new 474, 482 etc frequency.

Rule #2, you need reliable communication via i2c to the tuner. Look
for any i2c errors during communication.

 I guess demod_address is likely to be 0x8 and tuner_address is likely
 to be 0x61 or 0x60. I think 0x61 seems more like it. What else needs
 to be set there and is there any guidance on how to probe this type of
 info?

I typically probe the i2c bus using a logic analyzer to do this with a
PCI device. Often, poking at the windows driver configuration files
can reveal the I2C addresses but ideally, look directly at the I2C bus
when running the device under windows.


 With these mods scan shows tuning failed for every channel:
 tune to: 
 47400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_16:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
 WARNING:  tuning failed!!!

My advice, don't rely on scanning. Find an exact and strong frequency
that's working reliably for you with another product and focus
specificially on that frequency when test the new PCI board. Use tzap
exclusive as a test tool until you see the tool report a LOCKED
status.

Once you have a LOCK, use the dvbtraffic tool in addition to tzap to
help diagnose, no other s/w tools should be required.


 and:
 julian@pabay:~$ dmesg |grep -i saa
 [   19.248098] saa7130/34: v4l2 driver version 0, 2, 17 loaded
 [   19.248462] saa7133[0]: found at :04:08.0, rev: 209, irq: 16,
 latency: 64, mmio: 0xfe6fb000
 [   19.248467] saa7133[0]: subsystem: 17de:7256, board: Kworld PlusTV
 All in One (PI610) [card=193,autodetected]
 [   19.248482] saa7133[0]: board init: gpio is 100
 [   19.400046] saa7133[0]: i2c eeprom 00: de 17 56 72 54 20 1c 00 43
 43 a9 1c 55 d2 b2 92
 [   19.400058] saa7133[0]: i2c eeprom 10: ff ff ff 0f ff 20 ff ff ff
 ff ff ff ff ff ff 01
 [   19.400068] saa7133[0]: i2c eeprom 20: 01 40 01 03 03 01 01 03 08
 ff 00 fe ff ff ff ff
 [   19.400077] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   19.400087] saa7133[0]: i2c eeprom 40: ff 21 00 c2 96 10 03 32 15
 56 ff ff ff ff ff ff
 [   19.400096] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   19.400106] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   19.400115] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   19.400124] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   19.400134] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   19.400143] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   19.400153] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   19.400162] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   19.400171] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   19.400181] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   19.400190] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff
 [   24.053223] saa7133[0]: dsp access wait timeout [bit=WRR]
 [   24.053764] saa7133[0]: dsp access wait timeout [bit=WRR]
 [   24.116116] saa7133[0]: registered device video0 [v4l2]
 [   24.116202] saa7133[0]: registered device vbi0
 [   24.116260] saa7133[0]: registered device radio0
 [   24.174563] saa7134 ALSA driver for DMA sound loaded
 [   24.174590] saa7133[0]/alsa: saa7133[0] at 0xfe6fb000 irq 16
 registered as card -2
 [   24.179995] saa7133[0]: dsp access wait timeout [bit=WRR]
 [   24.180539] saa7133[0]: dsp access wait timeout [bit=WRR]
 [   24.185216] saa7133[0]: dsp access wait timeout [bit=WRR]
 [   24.185756] saa7133[0]: dsp access wait timeout [bit=WRR]
 [   24.640035] DVB: registering new adapter (saa7133[0])
 [   24.640043] saa7134 :04:08.0: DVB: registering adapter 0
 frontend 0 (Philips TDA10046H DVB-T)...
 [   25.632561] saa7133[0]: dsp access wait timeout [bit=WRR]

Once you have the demodulator locking, he next issue you'll
potentially come across is the MPEG interfacing between the
demodulator and the PCI controller. These are settings, usually passed
in the 10046 struct during

Help with Compro VideoMate M330F PCI Analog TV/FM Capture Card

[ZRADU]

)

SAA7134_I2S_OUTPUT_LEVEL:00 ()
SAA7134_I2S_AUDIO_OUTPUT:01 (0001)
SAA7134_TS_PARALLEL: 04 (0100)
SAA7134_TS_PARALLEL_SERIAL:  00 ()
SAA7134_TS_SERIAL0:  00 ()
SAA7134_TS_SERIAL1:  00 ()
SAA7134_TS_DMA0: 00 ()
SAA7134_TS_DMA1: 00 ()
SAA7134_TS_DMA2: 00 ()
SAA7134_SPECIAL_MODE:01 (0001)


Changes: State 2 - State 3:
SAA7134_GPIO_GPSTATUS:   02c0103f - 00c0083f  (--1- 
 ---10--- )

SAA7134_ANALOG_IN_CTRL1: 83   - 86 (-0-1)

2 changes


-- 



SAA7134 Card - State 3:
SAA7134_GPIO_GPMODE: 808c1800   (1000 10001100 00011000 
)
SAA7134_GPIO_GPSTATUS:   00c0083f * ( 1100 1000 
0011)  (was: 02c0103f)
SAA7134_ANALOG_IN_CTRL1: 86 * 
(1110) (was: 83)

SAA7134_ANALOG_IO_SELECT:00 * ()
SAA7134_AUDIO_CLOCK: 02187de7   (0010 00011000 0101 
11100111)
SAA7134_VIDEO_PORT_CTRL0:   (   
)
SAA7134_VIDEO_PORT_CTRL4:   (   
)

SAA7134_VIDEO_PORT_CTRL8:00 ()
SAA7134_I2S_OUTPUT_SELECT:   00 ()
SAA7134_I2S_OUTPUT_FORMAT:   01 (0001)
SAA7134_I2S_OUTPUT_LEVEL:00 ()
SAA7134_I2S_AUDIO_OUTPUT:01 (0001)
SAA7134_TS_PARALLEL: 04 (0100)
SAA7134_TS_PARALLEL_SERIAL:  00 ()
SAA7134_TS_SERIAL0:  00 ()
SAA7134_TS_SERIAL1:  00 ()
SAA7134_TS_DMA0: 00 ()
SAA7134_TS_DMA1: 00 ()
SAA7134_TS_DMA2: 00 ()
SAA7134_SPECIAL_MODE:01 (0001)


Changes: State 3 - Register Dump:
SAA7134_GPIO_GPSTATUS:   00c0083f - 06c4103f  (-00- 
-0-- ---01--- )
SAA7134_ANALOG_IN_CTRL1: 86   - 83 
(-1-0) (same as 0, 2)
SAA7134_ANALOG_IO_SELECT:00   - 07 
(-000) (same as 0)


3 changes


= 



SAA7134 Card - Register Dump:
SAA7134_GPIO_GPMODE: 808c1800   (1000 10001100 00011000 
)
SAA7134_GPIO_GPSTATUS:   06c4103f   (0110 11000100 0001 
0011)  (was: 00c0083f)
SAA7134_ANALOG_IN_CTRL1: 83 
(1011) (was: 86)
SAA7134_ANALOG_IO_SELECT:07 
(0111) (was: 00)
SAA7134_AUDIO_CLOCK: 02187de7   (0010 00011000 0101 
11100111)
SAA7134_VIDEO_PORT_CTRL0:   (   
)
SAA7134_VIDEO_PORT_CTRL4:   (   
)

SAA7134_VIDEO_PORT_CTRL8:00 ()
SAA7134_I2S_OUTPUT_SELECT:   00 ()
SAA7134_I2S_OUTPUT_FORMAT:   01 (0001)
SAA7134_I2S_OUTPUT_LEVEL:00 ()
SAA7134_I2S_AUDIO_OUTPUT:01 (0001)
SAA7134_TS_PARALLEL: 04 (0100)
SAA7134_TS_PARALLEL_SERIAL:  00 ()
SAA7134_TS_SERIAL0:  00 ()
SAA7134_TS_SERIAL1:  00 ()
SAA7134_TS_DMA0: 00 ()
SAA7134_TS_DMA1: 00 ()
SAA7134_TS_DMA2: 00 ()
SAA7134_SPECIAL_MODE:01 (0001)

end of dump

Please help gpio set for this card and add to saa7134-cards.c
--
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

Help wanted patching saa7164 driver to work with Compro E900F

[Daniel Playfair Cal]

Hello all,

I've been working on patching the saa7164 driver to work with the
Compro Videomate Vista E900F. This is a PCI-e tuner card that seems to
be almost identical to the Hauppauge HVR-2200, many versions of which
are supported. I've had some success but there are a few problems
which I'm not sure how to approach and I would appreciate any
help/advice. The most important point is number 2 under things that
are confusing.

CARD DETAILS:
 - Dual hybrid DVB-T/analogue TV tuner
 - hardware analogue source encoders
 - Various analogue video inputs
 - IR remote input
 - pci ID: 185b:e900
 - Main IC: phillips saa7164 rev2
 - Tuners: 2x NXP tda18271
 - DVB-T Demodulators: 2x NXP tda10048

WHAT I'VE DONE
My approach has been to modify the driver to make the kernel output
resemble the sample shown for the HVR-2200 here:
http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-2200#Sample_kernel_output
I patched saa7164-cards.c and saa7164.h to include the details of the
card (see https://gist.github.com/anonymous/8801027), and added the
card to the first case in saa7164_dvb_register() in saa7164-dvb.c (the
case covering the Hauppauge DVB-T cards). This results in the card
being recognised, the tuner/digital demodulator chips being detected,
and the DVB frontend devices being registered correctly. Kernel log of
this process is here: https://gist.github.com/anonymous/8799960. The
output of w_scan is here: https://gist.github.com/anonymous/881.
w_scan correctly finds frequencies on which there is a signal in my
area but seems to fail to get any data from those transmissions like
channel names etc. Kernel logs collected during that run of w_scan are
here: https://gist.github.com/anonymous/8800084. The behaviour is the
same on both adapters.

MISCELLANEOUS OBSERVATIONS/ACTIONS:
 - the card's firmware is different to any of the hauppauge firmwares.
The earlier two rev2 firmwares on Steven Toth's site boot correctly
and behave similarly to the stock firmware under linux but result in
the card failing to work at all under windows. The rev3 firmwares and
the newer/larger rev2 firmwares fail to boot. The firmware in the
windows driver has a different header structure to that in the
hauppauge firmware files, but I haven't bothered tackling that problem
yet since the firmware persists even through a full power cycle. I've
just been using the Compro firmware as flashed by the windows driver.
 - My best guess is that the two GPIO pins connected to the tda10048
demodulator reset pin are the same as on the HVR-2200. When I disabled
setting these pins on initialisation, the demodulators were not
correctly detected after a reboot, and strobing these pins as is done
for the HVR-2200 fixed the problem.

THINGS THAT ARE CONFUSING TO ME AND SEEM TO BE WRONG:
1. RF calibration for the tda18271 occurs only on the second of the
two tuners. When tda18271c2_rf_cal_init() is called from within
tda18271_attach(...) in tda18271-fe.c, cfg-rf_cal_on_startup is 0 for
the first chip and 1 for the second. I don't know why this is the
case, but I'm currently assuming its not a serious problem.
2. firmware is not loaded onto either of the tda10048's.
tda10048_init() seems to never be called. I don't understand how it is
meant to be called and why it isn't being called. Does the firmware on
this chip not persist through a reboot or reset, and would this
explain why w_scan is unable to see the channels on the frequencies?
What is the expected series of events that results in tda10048_init
being called to initialise the demodulator? At the moment I feel like
this is likely the biggest problem.
3. The firmware seems to object the the get firmware debug status
command sent from saa7164_api_set_debug() with a 0x9 status code
(SAA_ERR_BAD_PARAMETER), but not to the set debug status command, so I
don't see that this matters. I can see messages in the log starting
with FWMSG like what saa7164_api_collect_debug() would print, so it
seems that the firmware debugging is working in any case.
4. The output of saa7164_api_dump_subdevs() (see kernel log:
https://gist.github.com/anonymous/8799960) indicates that there is an
EEPROM with unitID 0x02. I have configured the card with this unitID
but the firmware returns 0x09 (SAA_ERR_BAD_PARAMETER) and the eeprom
is not read. I don't know why this is the case, and I am curious as to
why the particular read addresses are used in
saa7164_api_read_eeprom() in saa7164-api.c. (u8 reg[] = { 0x0f, 0x00
};). Might the correct address vary between cards? If so, how would I
got about finding the correct address? Am I correct in thinking that
the failure to read the EEPROM will not affect digital reception?
(btw, I also tried using all other unitIDs 0-0xff and none resulted in
a successful eeprom read)
5. Some of the configurations of hvr-2200 cards do not include analog
demodulators. I assume one must be present and configured in the card
struct to enable analog reception, and that the driver currently only
supports

Re: Help wanted patching saa7164 driver to work with Compro E900F

[Steven Toth]

On Tue, Feb 4, 2014 at 5:29 AM, Daniel Playfair Cal
daniel.playfair@gmail.com wrote:
 Hello all,

 I've been working on patching the saa7164 driver to work with the
 Compro Videomate Vista E900F. This is a PCI-e tuner card that seems to
 be almost identical to the Hauppauge HVR-2200, many versions of which
 are supported. I've had some success but there are a few problems

Hey Daniel,

Thanks for showing an interest in the driver.

I've been trying to source one of these cards for quite a while,
occasionally checking amazon etc. I can't seem to find anything in
retail on amazon or on ebay.

Where did you purchase the card?

- Steve

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
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: Help wanted patching saa7164 driver to work with Compro E900F

[Daniel Playfair Cal]

On Wed, Feb 5, 2014 at 12:32 AM, Steven Toth st...@kernellabs.com wrote:
 On Tue, Feb 4, 2014 at 5:29 AM, Daniel Playfair Cal
.

 Hey Daniel,

 Thanks for showing an interest in the driver.

 I've been trying to source one of these cards for quite a while,
 occasionally checking amazon etc. I can't seem to find anything in
 retail on amazon or on ebay.

 Where did you purchase the card?

Hi Steve

It is a pleasure, I'm finding it very interesting, and it would
certainly be satisfying if I did get it working. Thankyou for writing
the driver!

I bought it from either msy.com.au or skycomp.com.au quite a few years
ago, but I don't see it listed anywhere now in Australia except here
(http://www.foxcomp.com.au/ProductDetail.asp?ID=10591,
http://www.ht.com.au/part/AF826-Compro-VideoMate-Vista-E900F-DVB-T-HDTV-receiver-analogue-TV-radio-tuner-video-input-adapter-PCIe/detail.hts).
I can't see many tv tuners for sale anymore.

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

Re: Help wanted patching saa7164 driver to work with Compro E900F

[Steven Toth]

 Where did you purchase the card?

 Hi Steve

 It is a pleasure, I'm finding it very interesting, and it would
 certainly be satisfying if I did get it working. Thankyou for writing
 the driver!

You are welcome!


 I bought it from either msy.com.au or skycomp.com.au quite a few years
 ago, but I don't see it listed anywhere now in Australia except here
 (http://www.foxcomp.com.au/ProductDetail.asp?ID=10591,
 http://www.ht.com.au/part/AF826-Compro-VideoMate-Vista-E900F-DVB-T-HDTV-receiver-analogue-TV-radio-tuner-video-input-adapter-PCIe/detail.hts).
 I can't see many tv tuners for sale anymore.

Crazy prices, a sign that its generally no longer available in quantity.

HVR2200 is still a good option and generally available worldwide.

I did find a E900F available in the UK (amazon - roughly $40 USD) but
they won't ship it overseas.

Grrr.

- Steve

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
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

Help needed for zolid usb dvb-t stick

[mjs]

(a better request)

Hallo,

I'm new to linux and step by step learning by working with debian.
I'm using the 2.6.32-5-686 kernel and i have no knowledge about c+ other
then common sense and copy-paste.
(upgrading to the latest kernel will be a project in the future).

I've mechanical opened a :ZOLID Hybrid TV Stick, a usb dvb-t analog and
digital receiver (the : in front of the name is no typo mistake).
Next hardware was found, EM2882 - XC3028L (needs XC3028L-v36.fw) -
WJCE6353 (equal to ZL10353) - TVP5150 - EM202 - T24LC02.
I believe every component is known by the EM28xx driver but not in this
specific configuration and therefore no card in the EM28xx driver was
found as a direct (or induced) match.

I've made some modifications in the source code em28xx.h, em28xx-dvb.c
and em28xx-cards.c (see below).
Successfully compiled the driver, made progress but sadly no victory.

After a scan /usr/share/dvb/dvb-t/nl-all and at each frequentie tuning
failed, the following lines were added to the dmesg.
[ 2876.028035] xc2028 3-0061: Loading firmware for type=BASE F8MHZ MTS
   (7), id .
[ 2876.949274] xc2028 3-0061: Loading firmware for type=D2633 DTV8
   (210), id .
[ 2876.961893] xc2028 3-0061: Loading SCODE for type=DTV6 QAM DTV7
   ZARLINK456 SCODE HAS_IF_4760 (62e0),
   id .

At this point i think i have two problems which i cannot solve.
* gpio values em2882.
* dmesg informed me the stick uses a IF=4500 which isn't listed
  in tuner_xc2028.h  (XC3028L-v36.fw ??).

I'm stuck and i hope some one can help me to take the next step.

Thanks.
  Marcel Stork (Netherlands).



Modifications:


em28xx.h

+ #define  EM2882_BOARD_ZOLID_HYBRID_TV_STICK  74


em28xx-dvb.c

+ static struct zl10353_config em28xx_zl10353_with_xc3028_zolid = {
+ .demod_address = (0x1e  1),
+ .no_tuner = 1,
+ .parallel_ts = 1,
+ .if2 = 45000,
+  };

  static int dvb_init(struct em28xx *dev)
+ case EM2882_BOARD_ZOLID_HYBRID_TV_STICK:
+  dvb-frontend = dvb_attach(zl10353_attach,
+ em28xx_zl10353_with_xc3028_zolid,
+ dev-i2c_adap);
+  if (attach_xc3028(0x61, dev)  0) {
+   result = -EINVAL;
+   goto out_free;
+  }
+  break;


em28xx-cards.c

+ static struct em28xx_reg_seq zolid_tuner_gpio[] = { /* [FIXME-MJS] */
+ {EM28XX_R08_GPIO, EM_GPIO_4, EM_GPIO_4, 10},
+ {EM28XX_R08_GPIO, 0, EM_GPIO_4, 10},
+ {EM28XX_R08_GPIO, EM_GPIO_4, EM_GPIO_4, 10},
+ { -1,-1,-1, -1},
+ };

+ static struct em28xx_reg_seq zolid_digital[] = { /* [FIXME-MJS] */
+ {EM28XX_R08_GPIO, 0x6e, ~EM_GPIO_4,  10},
+ {EM2880_R04_GPO , 0x04, 0xff  , 100},  /* zl10353 reset */
+ {EM2880_R04_GPO , 0x0c, 0xff  ,   1},
+ { -1,  -1 ,  -1   ,  -1},
+ };

+ static struct em28xx_reg_seq zolid_analog[] = { /* [FIXME-MJS] */
+ {EM28XX_R08_GPIO, 0x6d,   ~EM_GPIO_4, 10},
+ { -1,  -1 ,   -1, -1},
+ };

  struct em28xx_board em28xx_boards[] = {
+ [EM2882_BOARD_ZOLID_HYBRID_TV_STICK] = {
+  .name = :ZOLID Hybrid TV Stick,
+  .tuner_type   = TUNER_XC2028,
+  .tuner_gpio   = zolid_tuner_gpio,
+  .decoder  = EM28XX_TVP5150,
+  .xclk = EM28XX_XCLK_FREQUENCY_12MHZ,
+  .mts_firmware = 1,
+  .has_dvb  = 1,
+  .dvb_gpio = zolid_digital,
+   /* .ir_codes = ir_codes_evga_indtube_table, [FIXME-MJS] */
+   .input= { {
+   .type = EM28XX_VMUX_TELEVISION,
+   .vmux = TVP5150_COMPOSITE0,
+   .amux = EM28XX_AMUX_VIDEO,
+   .gpio = zolid_analog,
+  }, {
+   .type = EM28XX_VMUX_COMPOSITE1,
+   .vmux = TVP5150_COMPOSITE1,
+   .amux = EM28XX_AMUX_LINE_IN,
+   .gpio = zolid_analog,
+  }, {
+   .type = EM28XX_VMUX_SVIDEO,
+   .vmux = TVP5150_SVIDEO,
+   .amux = EM28XX_AMUX_LINE_IN,
+   .gpio = zolid_analog,
+  } },
+ },

  struct usb_device_id em28xx_id_table

Re: Need help with AverMedia306 driver on linux system.

[remi]

Sorry

I need clarify one thing,


For the DVB, it's not the xc3028 here,

It's the AF9013

I have read the phrase available C API in the datasheet , I googled it and
found this thread for example :


http://forum.stmlabs.com/showthread.php?tid=3404


It's for raspberry and the likes linux-toy-SBC/SOC ,

I will go thru it , and keep you informed .


The datasheet shows that it's accessible by i2c too, so it must be linked to the
cx23885 by I2c ,

I think it's at the address 0x66,

once it's linked up I should be able to port their code .


Best regards

Rémi .


 Le 27 septembre 2013 à 22:11, remi r...@remis.cc a écrit :
 
 
 Good news, and thank you for the feedback
 
 
 Must be because I am in Paris/FRANCE, they went all TNT (dvb)
 
 I thaught they left a channel or two in the hertzerian analog but not :( or my
 reception is really bad ...
 
 And you have the right cables if it's in it's original laptop !! :)
 
 
 Thnx again for your help !!
 
 
 
 
 
  Le 27 septembre 2013 à 13:20, Nguyễn Minh Hoàng minhhoang1...@yahoo.com a 
écrit :
  
  
  Yes, you are so smart, buddy. I know you are not developer of these card 
driver. But you got the way to make this card worked well. So i wrote to you. 
I am not successful with your 306 patches because i use other revision of 
linuxtv driver, i tried modprobe option with card=39 too and as you say, it 
works as analog - no dvb. This card is hybridge, not single analog or dvb. If 
you get the way, help me with your way :) thank you. 
  
  Sent from my iPhone
  
   On Sep 27, 2013, at 6:06 PM, remi r...@remis.cc wrote:
   
   Oh, I am not the person who wrote the driver ... :(
   
   
   I merly cloned the HC81r, gave it the proper PCI ID, and the correct 
firmware ,
   
   I also have no DVB either,
   
   Unless I get time to learn V4L API, or the mainter of the xc2028 finds 
more
   infos too ...
   
   we are prety much at this stage, some analog, but no dvb ...
   
   at my knowlodge .
   
   
   Best regards
   
   Rémi
   
   
   
   
Le 27 septembre 2013 à 12:46, Nguyễn Minh Hoàng 
minhhoang1...@yahoo.com a écrit :


Thank you for your relying. I know that your patch is not same my 
revision, i can't apply it. I think i should find and add your patches 
manually, but there are so much code to do. I am on phone now. I will send you 
some more detail when i am back to my computer. Pls help me. 
Ps: i used option=39 before, my system got it as video and vbi 
device, not dvb device. Maybe i need some patches in this case as your 
suggestion today.
Thank you again!

Sent from my iPhone

 On Sep 27, 2013, at 3:24 PM, remi r...@remis.cc wrote:
 
 :)
 
 Also,
 
 
 by the time I redo the patch,
 
 
 You must have seen how i have reached this point,
 
 I have actually started by insering the module with card=39 as an 
option,
 
 
 So you can for now, add theses line to
 
 gpunk@gpunk-Aspire-8930:~$cat /etc/modprobe.d/video-tv.conf
 
 
 options tuner-xc2028 firmware_name=xc3028-v27.fw
 options cx23885 card=39
 
 
 I called my file this way ... it's arbitrary, please check the man 
modprobe of
 your ditribution/kernel .
 
 
 Best regards
 
 Rémi
 
 
 
  Le 21 septembre 2013 à 19:43, ad...@tydaikho.com 
minhhoang1...@yahoo.com a écrit :
  
  
  Hi Remi!
  I got my card but i have not finish to install driver. I follow 
your patch on linuxtv.org but i am not successful. it makes some mistake: 
malform and hunk errors.
  ===
  root@ty-debian:/usr/local/src/linuxtv# patch -p1  ./cx23885.patch
  can't find file to patch at input line 3
  Perhaps you used the wrong -p or --strip option?
  The text leading up to this was:
  --
  |--- drivers/media/pci/cx23885/cx23885.h   2013-03-25 
05:45:50.0 +0100
  |+++ drivers/media/pci/cx23885/cx23885.h  2013-08-21 
13:55:20.010625134 +0200
  --
  File to patch: ./drivers/media/pci/cx23885/cx23885.h
  
  patching file ./drivers/media/pci/cx23885/cx23885.h
  patch:  malformed patch at line 4:  #define 
CX23885_BOARD_PROF_800037
  ==
  root@ty-debian:/usr/local/src/linuxtv# patch -p1  
./cx23885-video.patch
  can't find file to patch at input line 4
  Perhaps you used the wrong -p or --strip option?
  The text leading up to this was:
  --
  |--- drivers/media/pci/cx23885/cx23885-video.c 2013-08-02 
05:45:59.0 +0200
  |+++ drivers/media/pci/cx23885/cx23885-video.c2013-08-21 
13:55:20.017625046
  |+0200
  --
  File to patch: ./drivers/media/pci/cx23885/cx23885-video.c
  patching file ./drivers/media/pci/cx23885/cx23885-video.c
  Hunk #1

Re: Need help with AverMedia306 driver on linux system.

[remi]

:)

Also,


by the time I redo the patch,


You must have seen how i have reached this point,

I have actually started by insering the module with card=39 as an option,


So you can for now, add theses line to

gpunk@gpunk-Aspire-8930:~$cat /etc/modprobe.d/video-tv.conf


options tuner-xc2028 firmware_name=xc3028-v27.fw
options cx23885 card=39


I called my file this way ... it's arbitrary, please check the man modprobe of
your ditribution/kernel .


Best regards

Rémi



 Le 21 septembre 2013 à 19:43, ad...@tydaikho.com minhhoang1...@yahoo.com 
a écrit :
 
 
 Hi Remi!
 I got my card but i have not finish to install driver. I follow your patch on 
linuxtv.org but i am not successful. it makes some mistake: malform and 
hunk errors.
 ===
 root@ty-debian:/usr/local/src/linuxtv# patch -p1  ./cx23885.patch
 can't find file to patch at input line 3
 Perhaps you used the wrong -p or --strip option?
 The text leading up to this was:
 --
 |--- drivers/media/pci/cx23885/cx23885.h   2013-03-25 05:45:50.0 +0100
 |+++ drivers/media/pci/cx23885/cx23885.h  2013-08-21 13:55:20.010625134 
+0200
 --
 File to patch: ./drivers/media/pci/cx23885/cx23885.h  

 patching file ./drivers/media/pci/cx23885/cx23885.h
 patch:  malformed patch at line 4:  #define CX23885_BOARD_PROF_8000   
 37
 ==
 root@ty-debian:/usr/local/src/linuxtv# patch -p1  ./cx23885-video.patch
 can't find file to patch at input line 4
 Perhaps you used the wrong -p or --strip option?
 The text leading up to this was:
 --
 |--- drivers/media/pci/cx23885/cx23885-video.c 2013-08-02 
05:45:59.0 +0200
 |+++ drivers/media/pci/cx23885/cx23885-video.c2013-08-21 
13:55:20.017625046
 |+0200
 --
 File to patch: ./drivers/media/pci/cx23885/cx23885-video.c
 patching file ./drivers/media/pci/cx23885/cx23885-video.c
 Hunk #1 FAILED at 511.
 Hunk #2 FAILED at 1888.
 2 out of 2 hunks FAILED -- saving rejects to file 
./drivers/media/pci/cx23885/cx23885-video.c.rej
 
 root@ty-debian:/usr/local/src/linuxtv# patch -p1  ./cx23885-cards.patch
 can't find file to patch at input line 4
 Perhaps you used the wrong -p or --strip option?
 The text leading up to this was:
 --
 |--- drivers/media/pci/cx23885/cx23885-cards.c 2012-12-28 
00:04:05.0 +0100
 |+++ drivers/media/pci/cx23885/cx23885-cards.c2013-08-21 
14:15:54.173195979
 |+0200
 --
 File to patch: ./drivers/media/pci/cx23885/cx23885-cards.c
 patching file ./drivers/media/pci/cx23885/cx23885-cards.c
 Hunk #1 FAILED at 604.
 Hunk #2 FAILED at 841.
 Hunk #3 FAILED at 1069.
 Hunk #4 FAILED at 1394.
 Hunk #5 FAILED at 1623.
 Hunk #6 FAILED at 1758.
 6 out of 6 hunks FAILED -- saving rejects to file 
./drivers/media/pci/cx23885/cx23885-cards.c.rej
 ===
 
 If you don't mind, i need your support to get my card works well. Thank you 
very much!
 
  
 --
 Yahoo: minhhoang1004 + Google: minhhoang1004 + Skype: minhhoang1004 + MSN: 
tydaikho
 --
 
 (http://tydaikho.com)  VS  (http://vnluser.net)
--
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: Need help with AverMedia306 driver on linux system.

[remi]

Oh, I am not the person who wrote the driver ... :(


I merly cloned the HC81r, gave it the proper PCI ID, and the correct firmware ,

I also have no DVB either,

Unless I get time to learn V4L API, or the mainter of the xc2028 finds more
infos too ...

we are prety much at this stage, some analog, but no dvb ...

at my knowlodge .


Best regards

Rémi




 Le 27 septembre 2013 à 12:46, Nguyễn Minh Hoàng minhhoang1...@yahoo.com a 
écrit :
 
 
 Thank you for your relying. I know that your patch is not same my revision, i 
can't apply it. I think i should find and add your patches manually, but there 
are so much code to do. I am on phone now. I will send you some more detail 
when i am back to my computer. Pls help me. 
 Ps: i used option=39 before, my system got it as video and vbi device, not 
dvb device. Maybe i need some patches in this case as your suggestion today.
 Thank you again!
 
 Sent from my iPhone
 
  On Sep 27, 2013, at 3:24 PM, remi r...@remis.cc wrote:
  
  :)
  
  Also,
  
  
  by the time I redo the patch,
  
  
  You must have seen how i have reached this point,
  
  I have actually started by insering the module with card=39 as an option,
  
  
  So you can for now, add theses line to
  
  gpunk@gpunk-Aspire-8930:~$cat /etc/modprobe.d/video-tv.conf
  
  
  options tuner-xc2028 firmware_name=xc3028-v27.fw
  options cx23885 card=39
  
  
  I called my file this way ... it's arbitrary, please check the man modprobe 
of
  your ditribution/kernel .
  
  
  Best regards
  
  Rémi
  
  
  
   Le 21 septembre 2013 à 19:43, ad...@tydaikho.com 
minhhoang1...@yahoo.com a écrit :
   
   
   Hi Remi!
   I got my card but i have not finish to install driver. I follow your 
patch on linuxtv.org but i am not successful. it makes some mistake: malform 
and hunk errors.
   ===
   root@ty-debian:/usr/local/src/linuxtv# patch -p1  ./cx23885.patch
   can't find file to patch at input line 3
   Perhaps you used the wrong -p or --strip option?
   The text leading up to this was:
   --
   |--- drivers/media/pci/cx23885/cx23885.h   2013-03-25 05:45:50.0 
+0100
   |+++ drivers/media/pci/cx23885/cx23885.h  2013-08-21 
13:55:20.010625134 +0200
   --
   File to patch: ./drivers/media/pci/cx23885/cx23885.h  

   patching file ./drivers/media/pci/cx23885/cx23885.h
   patch:  malformed patch at line 4:  #define CX23885_BOARD_PROF_8000   
 37
   ==
   root@ty-debian:/usr/local/src/linuxtv# patch -p1  ./cx23885-video.patch
   can't find file to patch at input line 4
   Perhaps you used the wrong -p or --strip option?
   The text leading up to this was:
   --
   |--- drivers/media/pci/cx23885/cx23885-video.c 2013-08-02 
05:45:59.0 +0200
   |+++ drivers/media/pci/cx23885/cx23885-video.c2013-08-21 
13:55:20.017625046
   |+0200
   --
   File to patch: ./drivers/media/pci/cx23885/cx23885-video.c
   patching file ./drivers/media/pci/cx23885/cx23885-video.c
   Hunk #1 FAILED at 511.
   Hunk #2 FAILED at 1888.
   2 out of 2 hunks FAILED -- saving rejects to file 
./drivers/media/pci/cx23885/cx23885-video.c.rej
   
   root@ty-debian:/usr/local/src/linuxtv# patch -p1  ./cx23885-cards.patch
   can't find file to patch at input line 4
   Perhaps you used the wrong -p or --strip option?
   The text leading up to this was:
   --
   |--- drivers/media/pci/cx23885/cx23885-cards.c 2012-12-28 
00:04:05.0 +0100
   |+++ drivers/media/pci/cx23885/cx23885-cards.c2013-08-21 
14:15:54.173195979
   |+0200
   --
   File to patch: ./drivers/media/pci/cx23885/cx23885-cards.c
   patching file ./drivers/media/pci/cx23885/cx23885-cards.c
   Hunk #1 FAILED at 604.
   Hunk #2 FAILED at 841.
   Hunk #3 FAILED at 1069.
   Hunk #4 FAILED at 1394.
   Hunk #5 FAILED at 1623.
   Hunk #6 FAILED at 1758.
   6 out of 6 hunks FAILED -- saving rejects to file 
./drivers/media/pci/cx23885/cx23885-cards.c.rej
   ===
   
   If you don't mind, i need your support to get my card works well. Thank 
you very much!
   

   --
   Yahoo: minhhoang1004 + Google: minhhoang1004 + Skype: minhhoang1004 + 
MSN: tydaikho
   --
   
   (http://tydaikho.com)  VS  (http://vnluser.net)
--
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: Need help with AverMedia306 driver on linux system.

[remi]

Good news, and thank you for the feedback


Must be because I am in Paris/FRANCE, they went all TNT (dvb)

I thaught they left a channel or two in the hertzerian analog but not :( or my
reception is really bad ...

And you have the right cables if it's in it's original laptop !! :)


Thnx again for your help !!





 Le 27 septembre 2013 à 13:20, Nguyễn Minh Hoàng minhhoang1...@yahoo.com a 
écrit :
 
 
 Yes, you are so smart, buddy. I know you are not developer of these card 
driver. But you got the way to make this card worked well. So i wrote to you. 
I am not successful with your 306 patches because i use other revision of 
linuxtv driver, i tried modprobe option with card=39 too and as you say, it 
works as analog - no dvb. This card is hybridge, not single analog or dvb. If 
you get the way, help me with your way :) thank you. 
 
 Sent from my iPhone
 
  On Sep 27, 2013, at 6:06 PM, remi r...@remis.cc wrote:
  
  Oh, I am not the person who wrote the driver ... :(
  
  
  I merly cloned the HC81r, gave it the proper PCI ID, and the correct 
firmware ,
  
  I also have no DVB either,
  
  Unless I get time to learn V4L API, or the mainter of the xc2028 finds 
more
  infos too ...
  
  we are prety much at this stage, some analog, but no dvb ...
  
  at my knowlodge .
  
  
  Best regards
  
  Rémi
  
  
  
  
   Le 27 septembre 2013 à 12:46, Nguyễn Minh Hoàng minhhoang1...@yahoo.com 
a écrit :
   
   
   Thank you for your relying. I know that your patch is not same my 
revision, i can't apply it. I think i should find and add your patches 
manually, but there are so much code to do. I am on phone now. I will send you 
some more detail when i am back to my computer. Pls help me. 
   Ps: i used option=39 before, my system got it as video and vbi device, 
not dvb device. Maybe i need some patches in this case as your suggestion 
today.
   Thank you again!
   
   Sent from my iPhone
   
On Sep 27, 2013, at 3:24 PM, remi r...@remis.cc wrote:

:)

Also,


by the time I redo the patch,


You must have seen how i have reached this point,

I have actually started by insering the module with card=39 as an 
option,


So you can for now, add theses line to

gpunk@gpunk-Aspire-8930:~$cat /etc/modprobe.d/video-tv.conf


options tuner-xc2028 firmware_name=xc3028-v27.fw
options cx23885 card=39


I called my file this way ... it's arbitrary, please check the man 
modprobe of
your ditribution/kernel .


Best regards

Rémi



 Le 21 septembre 2013 à 19:43, ad...@tydaikho.com 
minhhoang1...@yahoo.com a écrit :
 
 
 Hi Remi!
 I got my card but i have not finish to install driver. I follow your 
patch on linuxtv.org but i am not successful. it makes some mistake: malform 
and hunk errors.
 ===
 root@ty-debian:/usr/local/src/linuxtv# patch -p1  ./cx23885.patch
 can't find file to patch at input line 3
 Perhaps you used the wrong -p or --strip option?
 The text leading up to this was:
 --
 |--- drivers/media/pci/cx23885/cx23885.h   2013-03-25 
05:45:50.0 +0100
 |+++ drivers/media/pci/cx23885/cx23885.h  2013-08-21 
13:55:20.010625134 +0200
 --
 File to patch: ./drivers/media/pci/cx23885/cx23885.h  

 patching file ./drivers/media/pci/cx23885/cx23885.h
 patch:  malformed patch at line 4:  #define 
CX23885_BOARD_PROF_800037
 ==
 root@ty-debian:/usr/local/src/linuxtv# patch -p1  
./cx23885-video.patch
 can't find file to patch at input line 4
 Perhaps you used the wrong -p or --strip option?
 The text leading up to this was:
 --
 |--- drivers/media/pci/cx23885/cx23885-video.c 2013-08-02 
05:45:59.0 +0200
 |+++ drivers/media/pci/cx23885/cx23885-video.c2013-08-21 
13:55:20.017625046
 |+0200
 --
 File to patch: ./drivers/media/pci/cx23885/cx23885-video.c
 patching file ./drivers/media/pci/cx23885/cx23885-video.c
 Hunk #1 FAILED at 511.
 Hunk #2 FAILED at 1888.
 2 out of 2 hunks FAILED -- saving rejects to file 
./drivers/media/pci/cx23885/cx23885-video.c.rej
 
 root@ty-debian:/usr/local/src/linuxtv# patch -p1  
./cx23885-cards.patch
 can't find file to patch at input line 4
 Perhaps you used the wrong -p or --strip option?
 The text leading up to this was:
 --
 |--- drivers/media/pci/cx23885/cx23885-cards.c 2012-12-28 
00:04:05.0 +0100
 |+++ drivers/media/pci/cx23885/cx23885-cards.c2013-08-21 
14:15:54.173195979
 |+0200
 --
 File to patch: ./drivers/media/pci/cx23885/cx23885-cards.c
 patching file ./drivers

Re: Help with omap3isp resizing from CCDC

[Laurent Pinchart]

Hi Samuel,

On Friday 02 August 2013 13:12:24 samuel.rasmus...@gdc4s.com wrote:
 Hi,
 
 I've been having problems getting the resizer to take its input from the
 CCDC. From the linux-media mail-archive, it looks like Paul Chiha ran into a
 similar problem in Oct 2011 with his message Help with omap3isp resizing. 
 Paul had a patch at the end of the discussion, but even his patch hasn't
 fixed my problem yet. I might have made a mistake porting the patch since
 I'm on a newer kernel, or perhaps it doesn't work with my TVP5151 decoder.
 
 My setup: DM 3730 board, 3.5 kernel, and TVP5151 decoder.
 
 The video looks great with a 640x480 resolution, and the CCDC is de-
 interlacing the video. However, for my needs the video must be resized to
 320x240 or 160x120. The video, coming from the resizer, is split into a top
 and bottom half. Both halves are identical where everything in the video is
 too wide and too short. The CCDC must not be de-interlacing the video going
 to the resizer. I tried setting up the pipeline to send the CCDC to the
 resizer, but something must have gone wrong.

Unfortunately the CCDC can't deinterlace frames sent to the resizer. The 
deinterlacing process takes place at the CCDC output DMA engine when writing 
the frames to memory.

There's two solutions to resize interlaced video. The first one would be to 
capture the deinterlaced frames at the CCDC output to memory and then use the 
resizer in memory-to-memory mode. The second one would be to modify the driver 
to support deinterlacing at the resizer output, by doubling the line offset 
and computing the correct start address for each odd/even frame.

As you only need to downscale by two or four, another much simpler solution 
would be to drop every other interlaced frame. You would then get 640x240 
frames that you could resize to 320x240 or 160x120 with the resizer.

 Up until this point, I was using the UYVY2X8 format.  Then I saw the
 
 discussion Paul Chiha created.  In that discussion Laurent said:
  But the original poster wants to use the sensor - ccdc - resizer -
  resizeroutput pipeline.
 
  Also several sensor drivers that i have checked, usually define its
  output as 2X8 output. I think is more natural to add 2X8 support to
  CCDC and Resizer engines instead to modifying exiting drivers.
 
  Sure, sensor drivers should not be modified. What I was talking about
  was to configure the pipeline as
 
  sensor:0 [YUYV8_2X8], CCDC:0 [YUYV8_2X8], CCDC:1 [YUYV8_1X16],
  resizer:0 [YUYV8_1X16]
 
 I wasn't sure if Laurent's advice would also apply to the TVP5151, but I
 wanted to test it out.  I implemented Paul's patch so I could use the
 YUYV8_2X8 and YUYV8_1X16 formats.  The 640x480 resolution looked good in
 the YUYV8_2X8 format.  However, once again the video from the resizer
 was not de-interlaced so it had a top and bottom half (using YUYV8_2X8
 and YUYV8_1X16).  This time it was even worse because the video from the
 resizer was very green.
 
 Does anyone have suggestions for resizing video from the TVP5151?
 
 Thanks for taking the time to read this,
 Samuel
 
 I'm adding some media-ctl details below.
 media-ctl commands I'm using:
 
 media-ctl -v -l 'tvp5150 3-005c:0-OMAP3 ISP CCDC:0[1]'
 media-ctl -v -l 'OMAP3 ISP CCDC:1-OMAP3 ISP resizer:0[1]'
 media-ctl -v -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]'
 media-ctl -v -f 'tvp5150 3-005c:0 [YUYV2X8 640x480]'
 media-ctl -v -f 'OMAP3 ISP CCDC:0 [YUYV2X8 640x480]'
 media-ctl -v -f 'OMAP3 ISP CCDC:1 [YUYV 640x480]'
 media-ctl -v -f 'OMAP3 ISP resizer:1 [YUYV 320x240]'
 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so mplayer tv:// -tv
 driver=v4l2:device=/dev/video6
 
 Output of medi-ctl -p:
 
 Opening media device /dev/media0
 Enumerating entities
 Found 16 entities
 Enumerating pads and links
 Media controller API version 0.0.0
 
 Media device information
 
 driver  omap3isp
 model   TI OMAP3 ISP
 serial
 bus info
 hw revision 0xf0
 driver version  0.0.0
 
 Device topology
 - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev0
   pad0: Sink
   [fmt:SGRBG10/4096x4096]
   - OMAP3 ISP CCP2 input:0 []
   pad1: Source
   [fmt:SGRBG10/4096x4096]
   - OMAP3 ISP CCDC:0 []
 
 - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link)
 type Node subtype V4L flags 0
 device node name /dev/video0
   pad0: Source
   - OMAP3 ISP CCP2:0 []
 
 - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links)
 type V4L2 subdev subtype Unknown flags 0
 device node name /dev/v4l-subdev1
   pad0: Sink
   [fmt:SGRBG10/4096x4096]
   pad1: Source
   [fmt:SGRBG10/4096x4096]
   - OMAP3 ISP CSI2a output:0 []
   - OMAP3 ISP CCDC:0 []
 
 - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link)
 type Node subtype

Help with omap3isp resizing from CCDC

[Samuel.Rasmussen]

Hi,

I've been having problems getting the resizer to take its input from the
CCDC.  From the linux-media mail-archive, it looks like Paul Chiha ran
into a similar problem in Oct 2011 with his message Help with omap3isp
resizing.  Paul had a patch at the end of the discussion, but even his
patch hasn't fixed my problem yet.  I might have made a mistake porting
the patch since I'm on a newer kernel, or perhaps it doesn't work with
my TVP5151 decoder.

My setup: DM 3730 board, 3.5 kernel, and TVP5151 decoder.

The video looks great with a 640x480 resolution, and the CCDC is
de-interlacing the video.  However, for my needs the video must be
resized to 320x240 or 160x120.  The video, coming from the resizer, is
split into a top and bottom half.  Both halves are identical where
everything in the video is too wide and too short.  The CCDC must not be
de-interlacing the video going to the resizer.  I tried setting up the
pipeline to send the CCDC to the resizer, but something must have gone
wrong.

Up until this point, I was using the UYVY2X8 format.  Then I saw the
discussion Paul Chiha created.  In that discussion Laurent said:

But the original poster wants to use the sensor - ccdc - resizer -
resizer 
output pipeline.

 Also several sensor drivers that i have checked, usually define its
 output as 2X8 output. I think is more natural to add 2X8 support to
 CCDC and Resizer engines instead to modifying exiting drivers.

Sure, sensor drivers should not be modified. What I was talking about
was to 
configure the pipeline as

sensor:0 [YUYV8_2X8], CCDC:0 [YUYV8_2X8], CCDC:1 [YUYV8_1X16],
resizer:0 [YUYV8_1X16]

I wasn't sure if Laurent's advice would also apply to the TVP5151, but I
wanted to test it out.  I implemented Paul's patch so I could use the
YUYV8_2X8 and YUYV8_1X16 formats.  The 640x480 resolution looked good in
the YUYV8_2X8 format.  However, once again the video from the resizer
was not de-interlaced so it had a top and bottom half (using YUYV8_2X8
and YUYV8_1X16).  This time it was even worse because the video from the
resizer was very green.

Does anyone have suggestions for resizing video from the TVP5151?

Thanks for taking the time to read this,
Samuel

I'm adding some media-ctl details below.
media-ctl commands I'm using:

media-ctl -v -l 'tvp5150 3-005c:0-OMAP3 ISP CCDC:0[1]'
media-ctl -v -l 'OMAP3 ISP CCDC:1-OMAP3 ISP resizer:0[1]'
media-ctl -v -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]'
media-ctl -v -f 'tvp5150 3-005c:0 [YUYV2X8 640x480]'
media-ctl -v -f 'OMAP3 ISP CCDC:0 [YUYV2X8 640x480]'
media-ctl -v -f 'OMAP3 ISP CCDC:1 [YUYV 640x480]'
media-ctl -v -f 'OMAP3 ISP resizer:1 [YUYV 320x240]'
LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so mplayer tv:// -tv
driver=v4l2:device=/dev/video6

Output of medi-ctl -p:

Opening media device /dev/media0
Enumerating entities
Found 16 entities
Enumerating pads and links
Media controller API version 0.0.0

Media device information

driver  omap3isp
model   TI OMAP3 ISP
serial  
bus info
hw revision 0xf0
driver version  0.0.0

Device topology
- entity 1: OMAP3 ISP CCP2 (2 pads, 2 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev0
pad0: Sink
[fmt:SGRBG10/4096x4096]
- OMAP3 ISP CCP2 input:0 []
pad1: Source
[fmt:SGRBG10/4096x4096]
- OMAP3 ISP CCDC:0 []

- entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Source
- OMAP3 ISP CCP2:0 []

- entity 3: OMAP3 ISP CSI2a (2 pads, 2 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev1
pad0: Sink
[fmt:SGRBG10/4096x4096]
pad1: Source
[fmt:SGRBG10/4096x4096]
- OMAP3 ISP CSI2a output:0 []
- OMAP3 ISP CCDC:0 []

- entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video1
pad0: Sink
- OMAP3 ISP CSI2a:1 []

- entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev2
pad0: Sink
[fmt:YUYV2X8/640x480]
- OMAP3 ISP CCP2:1 []
- OMAP3 ISP CSI2a:1 []
- tvp5150 3-005c:0 [ENABLED]
pad1: Source
[fmt:YUYV/640x480
 crop.bounds:(0,0)/640x480
 crop:(0,0)/640x480]
- OMAP3 ISP CCDC output:0 []
- OMAP3 ISP resizer:0 [ENABLED]
pad2: Source
[fmt:unknown/640x479]
- OMAP3 ISP preview:0 []
- OMAP3 ISP AEWB:0 [ENABLED,IMMUTABLE]
- OMAP3 ISP AF:0 [ENABLED,IMMUTABLE]
- OMAP3 ISP histogram:0

Help needed: Wrong Maintainer Contact

[Florian Streibelt]

Hi,

the maintainer contact for the cx231xx driver is broken - the author of that 
driver is not reachable via the email adress stated in the source file: 
srinivasa.de...@conexant.com

[ host cnxtsmtp1.conexant.com [198.62.9.252]: 550 5.1.1 
srinivasa.de...@conexant.com:  Recipient address rejected: User unknown in 
relay recipient table]

Is this the right place to report this?

/Florian
--
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] s5c73m3: fix indentation of the help section in Kconfig

[Gianluca Gennari]

The 'help' section of the Kconfig entry for this driver is missing a couple of
extra spaces.
The effect is an error running 'make xconfig' (seen on the old 2.6.32 kernel
from Ubuntu 10.04 when compiling the latest media-build tree):

/lib/modules/2.6.32-46-generic-pae/build/scripts/kconfig/qconf ./Kconfig
./Kconfig:4985: unknown option This
./Kconfig:4986: unknown option 8
make[1]: *** [xconfig] Errore 1

Signed-off-by: Gianluca Gennari gennar...@gmail.com
---
 drivers/media/i2c/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 9e7ce8b..f981d50 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -559,8 +559,8 @@ config VIDEO_S5C73M3
tristate Samsung S5C73M3 sensor support
depends on I2C  SPI  VIDEO_V4L2  VIDEO_V4L2_SUBDEV_API
---help---
-   This is a V4L2 sensor-level driver for Samsung S5C73M3
-   8 Mpixel camera.
+ This is a V4L2 sensor-level driver for Samsung S5C73M3
+ 8 Mpixel camera.
 
 comment Flash devices
 
-- 
1.8.2.1

--
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: need help debugging ISP problem

[Laurent Pinchart]

Hi Adam,

On Monday 05 November 2012 16:02:08 Adam Wozniak wrote:
 I'm working with a custom board based on an Overo WaterStorm com. The
 processor is a DM3730.  The kernel is 2.6.32 based.

2.6.32 very probably means you're using the old TI driver. Please don't. 
That's buggy and totally unsupported. I advice upgrading to the latest 
mainline kernel.

 I'm trying to stress test the camera ISP by rapidly opening and closing
 the video device with ( while true; do gst-launch v4l2src
 device=/dev/video0 ! video/x-raw-yuv,width=320,height=240 !
 ffmpegcolorspace ! pngenc snapshot=true ! fakesink; done )
 
 After many iterations, I will see the kernel spit out:
 
 [ 2502.802795] Unhandled fault: external abort on non-linefetch (0x1028)
 at 0xfa0bce04
 [ 2502.810516] Internal error: : 1028 [#1]
 [ ... ]
 [ 2502.846893] PC is at isp_reg_readl+0x18/0x20
 [ 2502.851196] LR is at isp_reg_readl+0x10/0x20
 [ ... ]
 [ 2503.296447] [c02954a0] (isp_reg_readl+0x18/0x20) from [c02954f8]
 (isp_reg_and_or+0x1c/0x38)
 [ 2503.305206] [c02954f8] (isp_reg_and_or+0x1c/0x38) from [c029bad0]
 (isppreview_config_cfa+0x38/0x90)
 [ 2503.314666] [c029bad0] (isppreview_config_cfa+0x38/0x90) from
 [c029bc5c] (isppreview_config_datapath+0x134/0x330)
 [ 2503.325347] [c029bc5c] (isppreview_config_datapath+0x134/0x330)
 from [c029be68] (isppreview_s_pipeline+0x10/0xd0)
 [ 2503.336029] [c029be68] (isppreview_s_pipeline+0x10/0xd0) from
 [c0296e98] (isp_s_pipeline+0x1d8/0x280)
 [ 2503.345672] [c0296e98] (isp_s_pipeline+0x1d8/0x280) from
 [bf036b98] (cammux_streamon+0x218/0xa28 [cammux])
 [ ... ]
 
 
 The register we're trying to access here is the ISP PRV_PCR.  If I try
 to add debug code to read ISP_CTRL right before the fault, the ISP_CTRL
 access faults in the same way (i.e. the whole ISP is borked, not just
 the previewer).
 
 At first I thought the clocks were being disabled somehow, but tracking
 them seems to indicate that's not the case.  Adding an early return in
 arch/arm/mach/omap2/clock.c omap2_dflt_clk_disable() (i.e. to disable
 disabling of clocks) does NOT help.
 
 What else might I be missing?  What is necessary to be able to read the
 ISP registers?

-- 
Regards,

Laurent Pinchart

--
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: Please help me with cx88 audio

[Gene K]

Gene K dataclue at yahoo.com writes:

 
 I can't get the cx88-alsa driver to produce anything but loud noise (white 
noise 
 or pink noise) from my FusionHDTV 5 Gold card. This problem has been reported 
on 
 this list and elsewhere, but seemingly with no resolution, despite a LOT of 
RTFM 
 and Googling. I have tried a variety of tools and settings, but the result is 
 always the same. Video works. Audio in digital mode works. This is for line 
in 
 inputs on the card.
 
 This is on 3.6.1.fc17.x86_64. 
 
 Disturbingly, dmesg has a lot of this
 
 [ 2754.810011] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*



Can anyone help? It is probably something simple, like the audio-mux/GPIO 
settings, but I just can't find enough information to fix it myself or even 
experiment! 

Is there a way to control audio mux or GPIO explicitly from userspace, so I can 
try to poke around to see if it's that? 

Thanks again. 





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

Please help me with cx88 audio

[Gene K]

I can't get the cx88-alsa driver to produce anything but loud noise (white 
noise 
or pink noise) from my FusionHDTV 5 Gold card. This problem has been reported 
on 
this list and elsewhere, but seemingly with no resolution, despite a LOT of 
RTFM 
and Googling. I have tried a variety of tools and settings, but the result is 
always the same. Video works. Audio in digital mode works. This is for line 
in 
inputs on the card.

This is on 3.6.1.fc17.x86_64. 

Disturbingly, dmesg has a lot of this


[ 2754.810011] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
[ 2754.810019] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
[ 2754.810029] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
[ 2754.810038] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*
[ 2754.810045] cx88[0]: irq aud [0x1001] dn_risci1* dn_sync*

Thank you in advance for any suggestions. 


--
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] [media] Add missing help for some menuconfig items

[Mauro Carvalho Chehab]

Help was missing during some items reorganization. Add them.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
 drivers/media/i2c/Kconfig | 2 +-
 drivers/media/parport/Kconfig | 5 -
 drivers/media/pci/Kconfig | 3 +++
 drivers/media/usb/Kconfig | 3 +++
 4 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index d41dc0a..9a5a059 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -549,7 +549,7 @@ config VIDEO_M52790
 To compile this driver as a module, choose M here: the
 module will be called m52790.
 endmenu
-
+
 menu Sensors used on soc_camera driver
 
 if SOC_CAMERA
diff --git a/drivers/media/parport/Kconfig b/drivers/media/parport/Kconfig
index a1c7853..ece13dc 100644
--- a/drivers/media/parport/Kconfig
+++ b/drivers/media/parport/Kconfig
@@ -1,6 +1,9 @@
 menuconfig MEDIA_PARPORT_SUPPORT
-   bool V4L ISA and parallel port devices
+   bool ISA and parallel port devices
depends on (ISA || PARPORT)  MEDIA_CAMERA_SUPPORT
+   help
+ Enables drivers for ISA and parallel port bus. If you
+ need media drivers using those legacy buses, say Y.
 
 if MEDIA_PARPORT_SUPPORT
 config VIDEO_BWQCAM
diff --git a/drivers/media/pci/Kconfig b/drivers/media/pci/Kconfig
index 083b62f..d4e2ed3 100644
--- a/drivers/media/pci/Kconfig
+++ b/drivers/media/pci/Kconfig
@@ -1,6 +1,9 @@
 menuconfig MEDIA_PCI_SUPPORT
bool Media PCI Adapters
depends on PCI  MEDIA_SUPPORT
+   help
+ Enable media drivers for PCI/PCIe bus.
+ If you have such devices, say Y.
 
 if MEDIA_PCI_SUPPORT
 
diff --git a/drivers/media/usb/Kconfig b/drivers/media/usb/Kconfig
index f960e7ca4..6746994 100644
--- a/drivers/media/usb/Kconfig
+++ b/drivers/media/usb/Kconfig
@@ -1,6 +1,9 @@
 menuconfig MEDIA_USB_SUPPORT
bool Media USB Adapters
depends on USB  MEDIA_SUPPORT
+   help
+ Enable media drivers for USB bus.
+ If you have such devices, say Y.
 
 if MEDIA_USB_SUPPORT
 
-- 
1.7.11.4

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

help me, Kconfig problem

[Antti Palosaari]

I added Kernel GPIO interface for cxd2820r driver. What I understand I 
should select GPIOLIB in order to compile cxd2820r now. I am not sure if 
that problem comes from recent Media Kconfig re-arrangement or not, but 
for some reason I didn't saw it earlier.


What I should put for Kconfig in order to prevent these errors?

config DVB_CXD2820R
tristate Sony CXD2820R
depends on DVB_CORE  I2C  GPIOLIB
default m if DVB_FE_CUSTOMISE
help
  Say Y when you want to support this frontend.

[crope@localhost linux]$ make silentoldconfig
scripts/kconfig/conf --silentoldconfig Kconfig
warning: (VIDEO_EM28XX_DVB  DVB_USB_ANYSEE) selects DVB_CXD2820R which 
has unmet direct dependencies (MEDIA_SUPPORT  DVB_CAPTURE_DRIVERS  
DVB_CORE  I2C  GPIOLIB)
warning: (VIDEO_EM28XX_DVB  DVB_USB_ANYSEE) selects DVB_CXD2820R which 
has unmet direct dependencies (MEDIA_SUPPORT  DVB_CAPTURE_DRIVERS  
DVB_CORE  I2C  GPIOLIB)


***

config DVB_CXD2820R
tristate Sony CXD2820R
depends on DVB_CORE  I2C
select GPIOLIB
default m if DVB_FE_CUSTOMISE
help
  Say Y when you want to support this frontend.

[crope@localhost linux]$ make silentoldconfig
scripts/kconfig/conf --silentoldconfig Kconfig
drivers/usb/Kconfig:88:error: recursive dependency detected!
drivers/usb/Kconfig:88: symbol USB is selected by MOUSE_APPLETOUCH
drivers/input/mouse/Kconfig:152:	symbol MOUSE_APPLETOUCH depends on 
USB_ARCH_HAS_HCD

drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI
drivers/usb/Kconfig:17: symbol USB_ARCH_HAS_OHCI depends on MFD_TC6393XB
drivers/mfd/Kconfig:396:symbol MFD_TC6393XB depends on GPIOLIB
drivers/gpio/Kconfig:35:symbol GPIOLIB is selected by DVB_CXD2820R
drivers/media/dvb/frontends/Kconfig:422:	symbol DVB_CXD2820R is selected 
by VIDEO_EM28XX_DVB
drivers/media/video/em28xx/Kconfig:33:	symbol VIDEO_EM28XX_DVB depends 
on V4L_USB_DRIVERS

drivers/media/video/Kconfig:668:symbol V4L_USB_DRIVERS depends on USB
#
# configuration written to .config
#

regards
Antti

--
http://palosaari.fi/
--
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] DVB Multiplexing Help Required , Using Mplex iso138-18 or Caster

[Choi Wing Chan]

i am afraid that i can not help. i am only a beginner on dvb coding.

2012/6/28 sam sakthi...@gmail.com:

 Dear All,

 Can any one help me on DVB Multiplexing using Mplex or caster.

 Regards
 sakthi






 --
 --
 Regards
 K.S.Sampath Kumar
 Author for Book Understanding FOSS v 1.0 2.0 3.0c 3.0i
 http://en.wikipedia.org/wiki/Opensource
 வாழ்க வளமுடன்

 ___
 linux-dvb users mailing list
 For V4L/DVB development, please use instead linux-media@vger.kernel.org
 linux-...@linuxtv.org
 http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb



-- 
http://chanchoiwing.blogspot.com
--
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 RFC 4/4] tuner-xc2028: tag the usual firmwares to help dracut

[Mauro Carvalho Chehab]

When tuner-xc2028 is not compiled as a module, dracut will
need to copy the firmware inside the initfs image.

So, use MODULE_FIRMWARE() to indicate such need.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
 drivers/media/common/tuners/tuner-xc2028.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/common/tuners/tuner-xc2028.c 
b/drivers/media/common/tuners/tuner-xc2028.c
index b5ee3eb..2e6c966 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -1375,3 +1375,5 @@ MODULE_DESCRIPTION(Xceive xc2028/xc3028 tuner driver);
 MODULE_AUTHOR(Michel Ludwig michel.lud...@gmail.com);
 MODULE_AUTHOR(Mauro Carvalho Chehab mche...@infradead.org);
 MODULE_LICENSE(GPL);
+MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
+MODULE_FIRMWARE(XC3028L_DEFAULT_FIRMWARE);
-- 
1.7.10.2

--
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 RFC 4/4] tuner-xc2028: tag the usual firmwares to help dracut

[Greg KH]

On Tue, Jun 26, 2012 at 04:34:22PM -0300, Mauro Carvalho Chehab wrote:
 When tuner-xc2028 is not compiled as a module, dracut will
 need to copy the firmware inside the initfs image.
 
 So, use MODULE_FIRMWARE() to indicate such need.
 
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 ---
  drivers/media/common/tuners/tuner-xc2028.c |2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/drivers/media/common/tuners/tuner-xc2028.c 
 b/drivers/media/common/tuners/tuner-xc2028.c
 index b5ee3eb..2e6c966 100644
 --- a/drivers/media/common/tuners/tuner-xc2028.c
 +++ b/drivers/media/common/tuners/tuner-xc2028.c
 @@ -1375,3 +1375,5 @@ MODULE_DESCRIPTION(Xceive xc2028/xc3028 tuner driver);
  MODULE_AUTHOR(Michel Ludwig michel.lud...@gmail.com);
  MODULE_AUTHOR(Mauro Carvalho Chehab mche...@infradead.org);
  MODULE_LICENSE(GPL);
 +MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
 +MODULE_FIRMWARE(XC3028L_DEFAULT_FIRMWARE);

This is proabably something that needs to get in now, independant of the
other 3 patches, right?

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

Re: [PATCH RFC 4/4] tuner-xc2028: tag the usual firmwares to help dracut

[Mauro Carvalho Chehab]

Em 26-06-2012 17:44, Greg KH escreveu:
 On Tue, Jun 26, 2012 at 04:34:22PM -0300, Mauro Carvalho Chehab wrote:
 When tuner-xc2028 is not compiled as a module, dracut will
 need to copy the firmware inside the initfs image.

 So, use MODULE_FIRMWARE() to indicate such need.

 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 ---
   drivers/media/common/tuners/tuner-xc2028.c |2 ++
   1 file changed, 2 insertions(+)

 diff --git a/drivers/media/common/tuners/tuner-xc2028.c 
 b/drivers/media/common/tuners/tuner-xc2028.c
 index b5ee3eb..2e6c966 100644
 --- a/drivers/media/common/tuners/tuner-xc2028.c
 +++ b/drivers/media/common/tuners/tuner-xc2028.c
 @@ -1375,3 +1375,5 @@ MODULE_DESCRIPTION(Xceive xc2028/xc3028 tuner 
 driver);
   MODULE_AUTHOR(Michel Ludwig michel.lud...@gmail.com);
   MODULE_AUTHOR(Mauro Carvalho Chehab mche...@infradead.org);
   MODULE_LICENSE(GPL);
 +MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE);
 +MODULE_FIRMWARE(XC3028L_DEFAULT_FIRMWARE);
 
 This is proabably something that needs to get in now, independant of the
 other 3 patches, right?

Yes, this one is independent. 

This were not added before as the firmware names are/used to be device-specific,
and there's a modprobe parameter that allows overriding it.

Currently, all xc3028 devices since a long time uses version 2.7, and all
XC3028L uses version 3.2. (I still have here a device that only works with
a custom v 1.f firmware).

Anyway, it makes sense to at least use the two most common possible firmwares
there.

Regards,
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: cron job: media_tree daily build: ERRORS: help needed

[Hans Verkuil]

On Wed June 20 2012 08:19:40 Hans Verkuil wrote:
 On 19/06/12 21:41, Peter Senna Tschudin wrote:
  Full diff:
  http://pastebin.com/BJS2EXcH
 
  On Tue, Jun 19, 2012 at 4:39 PM, Peter Senna Tschudin
  peter.se...@gmail.com  wrote:
  Hans,
 
  I've:
  [peter@ace tmp]$ diff linux-2.6.35.13/scripts/mod/file2alias.c
  linux-3.4.3/scripts/mod/file2alias.c
 
  And found:
  727a840
  ADD_TO_DEVTABLE(i2c, struct i2c_device_id, do_i2c_entry);
 
  This line only exists on 3.4.3 version of file2alias.c. Isn't this why
  it successfully compile with newer Kernel?
 
 That looks very promising! I never thought to look for differences in 
 file2alias.c.
 I'll try this later this week.

That was a great clue: the fix was commit 
e88aa7bbbe3046a125ea1936b16bb921cc9c6349:

commit e88aa7bbbe3046a125ea1936b16bb921cc9c6349
Author: David Miller da...@davemloft.net
Date:   Thu Apr 12 14:37:30 2012 -0400

Fix modpost failures in fedora 17

The symbol table on x86-64 starts to have entries that have names
like:

_GLOBAL__sub_I_65535_0___mod_x86cpu_device_table

They are of type STT_FUNCTION and this one had a length of 18.  This
matched the device ID validation logic and it barfed because the
length did not meet the device type's criteria.


FATAL: arch/x86/crypto/aesni-intel: sizeof(struct x86cpu_device_id)=16 is 
not a modulo of the size of section __mod_x86cpu_device_table=18.
Fix definition of struct x86cpu_device_id in mod_devicetable.h


These are some kind of compiler tool internal stuff being emitted and
not something we want to inspect in modpost's device ID table
validation code.

So skip the symbol if it is not of type STT_OBJECT.

Signed-off-by: David S. Miller da...@davemloft.net
Acked-by: Sam Ravnborg s...@ravnborg.org
Signed-off-by: Michal Marek mma...@suse.cz

diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 8e730cc..44ddaa5 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -1100,6 +1100,10 @@ void handle_moddevtable(struct module *mod, struct 
elf_info *info,
if (!sym-st_shndx || get_secindex(info, sym) = info-num_sections)
return;
 
+   /* We're looking for an object */
+   if (ELF_ST_TYPE(sym-st_info) != STT_OBJECT)
+   return;
+
/* All our symbols are of form prefix__mod_XXX_device_table. */
name = strstr(symname, __mod_);
if (!name)

So probably because of the new compiler file2alias was misidentifying symbol 
table
entries.

I've applied this fix to all the affected kernels and hopefully today's daily 
build
will work again.

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: cron job: media_tree daily build: ERRORS: help needed

[Hans Verkuil]

On 19/06/12 21:41, Peter Senna Tschudin wrote:

Full diff:
http://pastebin.com/BJS2EXcH

On Tue, Jun 19, 2012 at 4:39 PM, Peter Senna Tschudin
peter.se...@gmail.com  wrote:

Hans,

I've:
[peter@ace tmp]$ diff linux-2.6.35.13/scripts/mod/file2alias.c
linux-3.4.3/scripts/mod/file2alias.c

And found:
727a840

ADD_TO_DEVTABLE(i2c, struct i2c_device_id, do_i2c_entry);


This line only exists on 3.4.3 version of file2alias.c. Isn't this why
it successfully compile with newer Kernel?


That looks very promising! I never thought to look for differences in 
file2alias.c.
I'll try this later this week.

Regards,

Hans



[]'s

Peter


On Tue, Jun 19, 2012 at 11:03 AM, Hans Verkuilhverk...@xs4all.nl  wrote:

On Tue 19 June 2012 14:50:09 Ezequiel Garcia wrote:

Hi Hans,

On Tue, Jun 19, 2012 at 3:34 AM, Hans Verkuilhverk...@xs4all.nl  wrote:

Hi all,

Yesterday I upgraded the gcc version I use to compile the daily build to
4.7.1.

This causes very strange errors when compiling 2.6.39 - 3.3:

FATAL: media_build/v4l/tuner: sizeof(struct i2c_device_id)=32 is not a
modulo of the size of section __mod_i2c_device_table=18.
Fix definition of struct i2c_device_id in mod_devicetable.h

This error does not appear when compiling with gcc 4.6.3, and I see
absolutely nothing
wrong with mod_devicetable.h.

I tried very hard to figure out what is going on and why older and newer
kernels
are not affected, but I still have no idea.

The error itself it reported by scripts/mod/file2alias.c. I can suppress
that error
but that will just lead to a modpost crash later in the compile process.

The tuner.o file always causes this. Commenting tuner.o in the Makefile will
cause
the same problems in other modules (cafe_ccic), but there are also i2c
modules that
compile just fine.

Does anyone have an insight into this? Did something magical change in
kernel 3.4
that fixed this?



Perhaps this thread could be useful:

https://lkml.org/lkml/2012/6/15/323


Yeah, I read that as well. But there there is a clear change that caused the
problem. As far as I can tell include/linux/mod_devicetable.h has identical
i2c_device_id structs for linux-3.0/1/2/3/4, yet all compile fine with 
gcc-4.6.3,
but for gcc-4.7.1 only linux-3.4 compiles.

I'm stumped.

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




--
Peter Senna Tschudin
peter.se...@gmail.com
gpg id: 48274C36






--
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: cron job: media_tree daily build: ERRORS: help needed

[Ezequiel Garcia]

Hi Peter and Hans,

On Wed, Jun 20, 2012 at 3:19 AM, Hans Verkuil hverk...@xs4all.nl wrote:
 On 19/06/12 21:41, Peter Senna Tschudin wrote:

 Full diff:
 http://pastebin.com/BJS2EXcH

 On Tue, Jun 19, 2012 at 4:39 PM, Peter Senna Tschudin
 peter.se...@gmail.com  wrote:

 Hans,

 I've:
 [peter@ace tmp]$ diff linux-2.6.35.13/scripts/mod/file2alias.c
 linux-3.4.3/scripts/mod/file2alias.c

 And found:
 727a840

 ADD_TO_DEVTABLE(i2c, struct i2c_device_id, do_i2c_entry);


 This line only exists on 3.4.3 version of file2alias.c. Isn't this why
 it successfully compile with newer Kernel?


 That looks very promising! I never thought to look for differences in
 file2alias.c.
 I'll try this later this week.


I've compiled remotes/linuxtv/staging/for_v3.0
branch from linuxtv tree using gcc 4.7.1. Here are gcc specs:

Using built-in specs.
COLLECT_GCC=/usr/i686-pc-linux-gnu/gcc-bin/4.7.0/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.7.0/work/gcc-4.7.0/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.7.0
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.0/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.0/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.0/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-ppl --without-cloog --enable-lto
--enable-nls --without-included-gettext --with-system-zlib
--disable-werror --enable-secureplt --disable-multilib
--enable-libmudflap --disable-libssp --disable-libgomp
--with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.7.0/python
--enable-checking=release --disable-libgcj --disable-libquadmath
--with-arch=i686 --enable-languages=c,c++ --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-targets=all --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.7.0 p1.1, pie-0.5.3'
Thread model: posix
gcc version 4.7.0 (Gentoo 4.7.0 p1.1, pie-0.5.3)

I can compile it without errors.

I'm far from expert, but I'm confused by the fact that
__mod_i2c_device_table reports 18 in size in Hans first mail.

Could you send us the output of this command:

objdump -D -z drivers/media/video/tuner.o ?

I hope I'm not messing things.

Regards,
Ezequiel.
--
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: cron job: media_tree daily build: ERRORS: help needed

[Hans Verkuil]

Hi all,

Yesterday I upgraded the gcc version I use to compile the daily build to 4.7.1.

This causes very strange errors when compiling 2.6.39 - 3.3:

FATAL: media_build/v4l/tuner: sizeof(struct i2c_device_id)=32 is not a modulo 
of the size of section __mod_i2c_device_table=18.
Fix definition of struct i2c_device_id in mod_devicetable.h

This error does not appear when compiling with gcc 4.6.3, and I see absolutely 
nothing
wrong with mod_devicetable.h.

I tried very hard to figure out what is going on and why older and newer kernels
are not affected, but I still have no idea.

The error itself it reported by scripts/mod/file2alias.c. I can suppress that 
error
but that will just lead to a modpost crash later in the compile process.

The tuner.o file always causes this. Commenting tuner.o in the Makefile will 
cause
the same problems in other modules (cafe_ccic), but there are also i2c modules 
that
compile just fine.

Does anyone have an insight into this? Did something magical change in kernel 
3.4
that fixed this?

Regards,

Hans

On 18/06/12 20:58, Hans Verkuil wrote:

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

Results of the daily build of media_tree:

date:Mon Jun 18 19:00:12 CEST 2012
git hash:5472d3f17845c4398c6a510b46855820920c2181
gcc version:  i686-linux-gcc (GCC) 4.7.1
host hardware:x86_64
host os:  3.4.07-marune

linux-git-arm-eabi-davinci: WARNINGS
linux-git-arm-eabi-exynos: WARNINGS
linux-git-arm-eabi-omap: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: WARNINGS
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-x86_64: WARNINGS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: ERRORS
linux-3.0-x86_64: ERRORS
linux-3.1-x86_64: ERRORS
linux-3.2.1-x86_64: ERRORS
linux-3.3-x86_64: ERRORS
linux-3.4-x86_64: WARNINGS
linux-2.6.31.12-i686: WARNINGS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: ERRORS
linux-3.0-i686: ERRORS
linux-3.1-i686: ERRORS
linux-3.2.1-i686: ERRORS
linux-3.3-i686: ERRORS
linux-3.4-i686: WARNINGS
apps: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.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


--
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: cron job: media_tree daily build: ERRORS: help needed

[Ezequiel Garcia]

Hi Hans,

On Tue, Jun 19, 2012 at 3:34 AM, Hans Verkuil hverk...@xs4all.nl wrote:
 Hi all,

 Yesterday I upgraded the gcc version I use to compile the daily build to
 4.7.1.

 This causes very strange errors when compiling 2.6.39 - 3.3:

 FATAL: media_build/v4l/tuner: sizeof(struct i2c_device_id)=32 is not a
 modulo of the size of section __mod_i2c_device_table=18.
 Fix definition of struct i2c_device_id in mod_devicetable.h

 This error does not appear when compiling with gcc 4.6.3, and I see
 absolutely nothing
 wrong with mod_devicetable.h.

 I tried very hard to figure out what is going on and why older and newer
 kernels
 are not affected, but I still have no idea.

 The error itself it reported by scripts/mod/file2alias.c. I can suppress
 that error
 but that will just lead to a modpost crash later in the compile process.

 The tuner.o file always causes this. Commenting tuner.o in the Makefile will
 cause
 the same problems in other modules (cafe_ccic), but there are also i2c
 modules that
 compile just fine.

 Does anyone have an insight into this? Did something magical change in
 kernel 3.4
 that fixed this?


Perhaps this thread could be useful:

https://lkml.org/lkml/2012/6/15/323

Hope it helps,
Ezequiel.
--
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: cron job: media_tree daily build: ERRORS: help needed

[Hans Verkuil]

On Tue 19 June 2012 14:50:09 Ezequiel Garcia wrote:
 Hi Hans,
 
 On Tue, Jun 19, 2012 at 3:34 AM, Hans Verkuil hverk...@xs4all.nl wrote:
  Hi all,
 
  Yesterday I upgraded the gcc version I use to compile the daily build to
  4.7.1.
 
  This causes very strange errors when compiling 2.6.39 - 3.3:
 
  FATAL: media_build/v4l/tuner: sizeof(struct i2c_device_id)=32 is not a
  modulo of the size of section __mod_i2c_device_table=18.
  Fix definition of struct i2c_device_id in mod_devicetable.h
 
  This error does not appear when compiling with gcc 4.6.3, and I see
  absolutely nothing
  wrong with mod_devicetable.h.
 
  I tried very hard to figure out what is going on and why older and newer
  kernels
  are not affected, but I still have no idea.
 
  The error itself it reported by scripts/mod/file2alias.c. I can suppress
  that error
  but that will just lead to a modpost crash later in the compile process.
 
  The tuner.o file always causes this. Commenting tuner.o in the Makefile will
  cause
  the same problems in other modules (cafe_ccic), but there are also i2c
  modules that
  compile just fine.
 
  Does anyone have an insight into this? Did something magical change in
  kernel 3.4
  that fixed this?
 
 
 Perhaps this thread could be useful:
 
 https://lkml.org/lkml/2012/6/15/323

Yeah, I read that as well. But there there is a clear change that caused the
problem. As far as I can tell include/linux/mod_devicetable.h has identical
i2c_device_id structs for linux-3.0/1/2/3/4, yet all compile fine with 
gcc-4.6.3,
but for gcc-4.7.1 only linux-3.4 compiles.

I'm stumped.

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: cron job: media_tree daily build: ERRORS: help needed

[Peter Senna Tschudin]

Hans,

I've:
[peter@ace tmp]$ diff linux-2.6.35.13/scripts/mod/file2alias.c
linux-3.4.3/scripts/mod/file2alias.c

And found:
727a840
 ADD_TO_DEVTABLE(i2c, struct i2c_device_id, do_i2c_entry);

This line only exists on 3.4.3 version of file2alias.c. Isn't this why
it successfully compile with newer Kernel?

[]'s

Peter


On Tue, Jun 19, 2012 at 11:03 AM, Hans Verkuil hverk...@xs4all.nl wrote:
 On Tue 19 June 2012 14:50:09 Ezequiel Garcia wrote:
 Hi Hans,

 On Tue, Jun 19, 2012 at 3:34 AM, Hans Verkuil hverk...@xs4all.nl wrote:
  Hi all,
 
  Yesterday I upgraded the gcc version I use to compile the daily build to
  4.7.1.
 
  This causes very strange errors when compiling 2.6.39 - 3.3:
 
  FATAL: media_build/v4l/tuner: sizeof(struct i2c_device_id)=32 is not a
  modulo of the size of section __mod_i2c_device_table=18.
  Fix definition of struct i2c_device_id in mod_devicetable.h
 
  This error does not appear when compiling with gcc 4.6.3, and I see
  absolutely nothing
  wrong with mod_devicetable.h.
 
  I tried very hard to figure out what is going on and why older and newer
  kernels
  are not affected, but I still have no idea.
 
  The error itself it reported by scripts/mod/file2alias.c. I can suppress
  that error
  but that will just lead to a modpost crash later in the compile process.
 
  The tuner.o file always causes this. Commenting tuner.o in the Makefile 
  will
  cause
  the same problems in other modules (cafe_ccic), but there are also i2c
  modules that
  compile just fine.
 
  Does anyone have an insight into this? Did something magical change in
  kernel 3.4
  that fixed this?
 

 Perhaps this thread could be useful:

 https://lkml.org/lkml/2012/6/15/323

 Yeah, I read that as well. But there there is a clear change that caused the
 problem. As far as I can tell include/linux/mod_devicetable.h has identical
 i2c_device_id structs for linux-3.0/1/2/3/4, yet all compile fine with 
 gcc-4.6.3,
 but for gcc-4.7.1 only linux-3.4 compiles.

 I'm stumped.

 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



-- 
Peter Senna Tschudin
peter.se...@gmail.com
gpg id: 48274C36
--
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: cron job: media_tree daily build: ERRORS: help needed

[Peter Senna Tschudin]

Full diff:
http://pastebin.com/BJS2EXcH

On Tue, Jun 19, 2012 at 4:39 PM, Peter Senna Tschudin
peter.se...@gmail.com wrote:
 Hans,

 I've:
 [peter@ace tmp]$ diff linux-2.6.35.13/scripts/mod/file2alias.c
 linux-3.4.3/scripts/mod/file2alias.c

 And found:
 727a840
 ADD_TO_DEVTABLE(i2c, struct i2c_device_id, do_i2c_entry);

 This line only exists on 3.4.3 version of file2alias.c. Isn't this why
 it successfully compile with newer Kernel?

 []'s

 Peter


 On Tue, Jun 19, 2012 at 11:03 AM, Hans Verkuil hverk...@xs4all.nl wrote:
 On Tue 19 June 2012 14:50:09 Ezequiel Garcia wrote:
 Hi Hans,

 On Tue, Jun 19, 2012 at 3:34 AM, Hans Verkuil hverk...@xs4all.nl wrote:
  Hi all,
 
  Yesterday I upgraded the gcc version I use to compile the daily build to
  4.7.1.
 
  This causes very strange errors when compiling 2.6.39 - 3.3:
 
  FATAL: media_build/v4l/tuner: sizeof(struct i2c_device_id)=32 is not a
  modulo of the size of section __mod_i2c_device_table=18.
  Fix definition of struct i2c_device_id in mod_devicetable.h
 
  This error does not appear when compiling with gcc 4.6.3, and I see
  absolutely nothing
  wrong with mod_devicetable.h.
 
  I tried very hard to figure out what is going on and why older and newer
  kernels
  are not affected, but I still have no idea.
 
  The error itself it reported by scripts/mod/file2alias.c. I can suppress
  that error
  but that will just lead to a modpost crash later in the compile process.
 
  The tuner.o file always causes this. Commenting tuner.o in the Makefile 
  will
  cause
  the same problems in other modules (cafe_ccic), but there are also i2c
  modules that
  compile just fine.
 
  Does anyone have an insight into this? Did something magical change in
  kernel 3.4
  that fixed this?
 

 Perhaps this thread could be useful:

 https://lkml.org/lkml/2012/6/15/323

 Yeah, I read that as well. But there there is a clear change that caused the
 problem. As far as I can tell include/linux/mod_devicetable.h has identical
 i2c_device_id structs for linux-3.0/1/2/3/4, yet all compile fine with 
 gcc-4.6.3,
 but for gcc-4.7.1 only linux-3.4 compiles.

 I'm stumped.

 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



 --
 Peter Senna Tschudin
 peter.se...@gmail.com
 gpg id: 48274C36



-- 
Peter Senna Tschudin
peter.se...@gmail.com
gpg id: 48274C36
--
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: cron job: media_tree daily build: ERRORS: help needed

[Ezequiel Garcia]

On Tue, Jun 19, 2012 at 4:39 PM, Peter Senna Tschudin
peter.se...@gmail.com wrote:
 Hans,

 I've:
 [peter@ace tmp]$ diff linux-2.6.35.13/scripts/mod/file2alias.c
 linux-3.4.3/scripts/mod/file2alias.c

 And found:
 727a840
 ADD_TO_DEVTABLE(i2c, struct i2c_device_id, do_i2c_entry);

FWIW, that macro was added on commit:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=e49ce14150c64b29a8dd211df785576fa19a9858
--
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

Help requested, frame grabber stops working on Debian upgrade (Lenny to Squeeze)

[Rob Murgatroyd]

Hello,

Please could anyone try to assist with this problem with video capture after a 
system upgrade?

I have a frame grabber that has 8 BT878 (or very similar) chips on one card, 
also a V4L2 application that reads single frames from attached video cameras. 
I was using this set-up successfully under Debian 'Lenny' on a modest AMD 
system. As Lenny seems to be no longer supported I upgraded to 'Squeeze' 
using the aptitude manager which seemed to go fairly smoothly. 

Unfortunately post the upgrade I no longer see the 8 /dev/video[0-7] devices 
that were previously in the /dev directory. I was expecting them to appear 
automatically when the card was initialised but I also tried creating one 
manually which created the file but that was not readable by my app. 
(mknod /dev/video0 c 81 0)

I've Googled extensively but can't find anything that looks like this problem. 
I'd be very grateful if anyone was able to assist.

Rob Murgatroyd


This is the modprobe option list it needs to be able to see the card:
options i2c-algo-bit bit_test=1
options bttv gbuffers=32 card=102,102,102,102,102,102,102,102 tuner=0 coring=1 
full_luma_range=1 chroma_agc=1 pll=1 combfilter=1 triton1=0


Extract from the 'messages' log after it broke:
[   10.797179] Linux video capture interface: v2.00
[   11.259971] bttv: driver version 0.9.18 loaded
[   11.259976] bttv: using 32 buffers with 2080k (520 pages) each for capture
[   11.260426] bttv: Bt8xx card found (0).
[   11.260901] ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
[   11.260917] bttv :04:08.0: PCI INT A - Link[APC3] - GSI 18 (level, 
low) - IRQ 18
[   11.260934] bttv0: Bt878 (rev 17) at :04:08.0, irq: 18, latency: 32, 
mmio: 0xfdcff000
[   11.260984] bttv0: using: IVC-200 [card=102,insmod option]
[   11.260987] IRQ 18/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs
[   11.261059] bt878 #0 [sw]: bus seems to be busy
[   11.264545] ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 23
[   11.264551] Intel ICH :00:10.2: PCI INT C - Link[APCJ] - GSI 23 
(level, low) - IRQ 23
[   11.596024] intel8x0_measure_ac97_clock: measured 54870 usecs (2696 
samples)
[   11.596028] intel8x0: clocking to 46892
[   12.064864] bttv0: tuner type=0
[   12.127363] *pde = 
[   12.127404] Modules linked in: msp3400 snd_intel8x0 bttv(+) snd_ac97_codec 
ac97_bus v4l2_common snd_pcm videodev v4l1_compat snd_seq ir_
common videobuf_dma_sg videobuf_core btcx_risc tveeprom snd_timer 
snd_seq_device shpchp snd nouveau soundcore snd_page_alloc k8temp ttm 
drm_kms_helper pcspkr pci_hotplug serio_raw evdev parport_pc drm i2c_nforce2 
i2c_algo_bit i2c_core parport processor button ext3 jbd mbcache sg sr_mod 
cdrom usbhid hid sd_mod crc_t10dif ata_generic usb_storage pata_amd ohci_hcd 
fan sata_nv forcedeth thermal ehci_hcd libata floppy scsi_mod usbcore nls_base 
thermal_sys [last unloaded: scsi_wait_scan]
[   12.127660]
[   12.127670] Pid: 726, comm: modprobe Not tainted (2.6.32-5-686 #1)
[   12.127683] EIP: 0060:[dcb84374] EFLAGS: 00010246 CPU: 0
[   12.127700] EIP is at i2c_new_probed_device+0x22/0x133 [i2c_core]
[   12.127713] EAX: d48e383c EBX: d4931eac ECX: d4931eac EDX: 
[   12.127725] ESI: d4931eac EDI: d48e383c EBP: d4931eac ESP: d4931d7c
[   12.127738]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[   12.127770]  2b6ce215 d4931dfc  0092  0001 0092 
c1393118
[   12.127803] 0 afab c1047882 b46116fa d48e383c b46116fa d48e383c 
d4931eac dee0eeeb
[   12.127839] 0 0009 ded43ed0 d48e3800  d4931dfc d4931e20 
0009 ded44048
[   12.127893]  [c1047882] ? up+0x9/0x2a
[   12.128259]  [ded43ed0] ? v4l2_i2c_new_subdev_board+0x40/0x133 
[v4l2_common]
[   12.128866]  [dee0b6cb] ? bttv_init_card2+0x13fc/0x149a [bttv]
[   12.128866]  [c126e107] ? _cond_resched+0x25/0x3c
[   12.128866]  [dcb9c0bb] ? sclhi+0x3c/0x4d [i2c_algo_bit]
[   12.128866]  [dcb9c313] ? test_bus+0x126/0x140 [i2c_algo_bit]
[   12.128866]  [dcb9c763] ? i2c_bit_add_bus+0x1a/0x3b [i2c_algo_bit]
[   12.128866]  [dee0bee7] ? init_bttv_i2c+0x16f/0x1e3 [bttv]
[   12.128866]  [dee09bd3] ? bttv_probe+0x4d6/0x8e4 [bttv]
[   12.128866]  [c11470e5] ? local_pci_probe+0xb/0xc
[   12.128866]  [c1147a2f] ? pci_device_probe+0x41/0x63
[   12.128866]  [c11b3c96] ? driver_probe_device+0x8a/0x11e
[   12.128866]  [c11b3d6a] ? __driver_attach+0x40/0x5b
[   12.128866]  [c11b36d9] ? bus_for_each_dev+0x37/0x5f
[   12.128866]  [c11b3b69] ? driver_attach+0x11/0x13
[   12.128866]  [c11b3d2a] ? __driver_attach+0x0/0x5b
[   12.128866]  [c11b31a1] ? bus_add_driver+0x99/0x1c5
[   12.128866]  [c11b3f9b] ? driver_register+0x87/0xe0
[   12.128866]  [c11b3803] ? bus_create_file+0x33/0x39
[   12.128866]  [c1147c00] ? __pci_register_driver+0x33/0x89
[   12.128866]  [dee19000] ? bttv_init_module+0x0/0xcf [bttv]
[   12.128866]  [dee190bb] ? bttv_init_module+0xbb/0xcf [bttv]
[   12.128866]  [c100113e] ? do_one_initcall+0x55/0x155
[   12.128866]  [c1057c4d] ? sys_init_module+0xa7/0x1d7
[   12.128866]  

RDS help needed

[Matthias Bock]

Hi there!

I hacked a RDS TMC-message receiver to work on the serial port.

http://www.matthiasbock.net/wiki/?title=Kategorie:GNS_TrafficBox_FM9_RDS_TMC-Receiver

According to
 http://linuxtv.org/wiki/index.php/Radio_Data_System_(RDS)
already several different receivers are available for usage
with Linux but development of the RDS message daemon,
that would be required to collect, decode and distribute
the RDS messages to client applications
 http://rdsd.berlios.de/
kindof stucked, didn't progress since 2009 (!)

The available SVN sources only support
SAA6588-based RDS receivers.

Is RDS support still an important task to
someone on this list ?

Is there someone, who would consider assisting me a little
in writing some documentation on the RDS daemon project,
some code maybe, lateron some linux kernel modules ?

Cheers! Matthias


--
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: RDS help needed

[Hans Verkuil]

On Tue May 1 2012 12:56:49 Matthias Bock wrote:
 Hi there!
 
 I hacked a RDS TMC-message receiver to work on the serial port.
 
 http://www.matthiasbock.net/wiki/?title=Kategorie:GNS_TrafficBox_FM9_RDS_TMC-Receiver
 
 According to
  http://linuxtv.org/wiki/index.php/Radio_Data_System_(RDS)
 already several different receivers are available for usage
 with Linux but development of the RDS message daemon,
 that would be required to collect, decode and distribute
 the RDS messages to client applications
  http://rdsd.berlios.de/
 kindof stucked, didn't progress since 2009 (!)
 
 The available SVN sources only support
 SAA6588-based RDS receivers.
 
 Is RDS support still an important task to
 someone on this list ?

It is on my list. I might actually be able to get someone to work on this as
a summerjob (no guarantees yet). The kernel side of things is well in hand,
but that RDS daemon is crap software and should be replaced with something
different (and above all, not daemon based).

 Is there someone, who would consider assisting me a little
 in writing some documentation on the RDS daemon project,
 some code maybe, lateron some linux kernel modules ?

I'd be happy to help with the kernel modules, but the userspace part depends
on whether I can get someone to work on this or not.

BTW, that RDS daemon does work fine, it's just way overengineered.

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

Need help to get Tevii S471 running

[Hubert Fink]

Hello dear all,
i have buy a DVB-S2 card from Tevii S471 and i need help to get it 
running with

Debian Wheezy/Sid Kernel 3.2.0-2-686-pae.

The Tevii S471 was similar to the Tevii S470 but it has different LNB 
control.


The first thing I have to use the s2-liplianin drivers unfortunately I 
was not successful.

s2-liplianin:
cx23885: add TeVii s471 card.
From: Igor M. Liplianin liplia...@me.by
New TeVii s471 card is like s470 model,
but there is different LNB power control.

Next, I have made a git clone from media_build and change the files 
(cx23885-dvb.c, cx23885-cards.c, cx23885.h)

with code from s2-liplianin. See the diff output at the end of this message.
The compiling was now ready and i have installed the new driver.
It was loaded and the adapter0 was installed.

A scan with w_scan (w_scan -fs -s S19E2 -X  channels-sat1.conf) give me 
some errors like this:

(time: 00:11) diseqc_send_msg: FE_SET_VOLTAGE failed.
diseqc_send_msg: FE_SET_VOLTAGE failed.
But it found some but not all Channels it is a problem to switch the LNB.

A test was successful with Mplayer and a scanned channel (mplayer 
dvb://ZDF) unfortunately

the picture and sound output was disturbed.
After a restart and a new scan it found new channels but the card dont 
switch to the older channels.


Many Thanks for reading this message, hopefully
Hubert Fink

Some outputs and diffs:

ls -rl /dev/dvb/
insgesamt 0
drwxr-xr-x 2 root root 120 Apr  7 19:31 adapter0

dmesg output:
[   17.423214] cx23885 driver version 0.0.3 loaded
[   17.423246] cx23885 :05:00.0: PCI INT A - GSI 48 (level, low) - 
IRQ 48
[   17.423519] CORE cx23885[0]: subsystem: d471:9022, board: TeVii S471 
[card=35,autodetected]

[   17.549784] cx23885_dvb_register() allocating 1 frontend(s)
[   17.549788] cx23885[0]: cx23885 based dvb card
[   17.645414] DS3000 chip version: 0.192 attached.
[   17.645417] DVB: registering new adapter (cx23885[0])
[   17.645419] DVB: registering adapter 0 frontend 0 (Montage Technology 
DS3000/TS2020)...

[   17.672210] TeVii S471 MAC= 00:18:bd:5b:63:ad
[   17.672213] cx23885_dev_checkrevision() Hardware revision = 0xb0
[   17.672217] cx23885[0]/0: found at :05:00.0, rev: 2, irq: 48, 
latency: 0, mmio: 0xfe40

[   17.67] cx23885 :05:00.0: setting latency timer to 64



diff ./cx23885-dvb.c ./cx23885-dvb.c.orig
491,494d490
 static int prof_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t 
voltage)

 {
 struct cx23885_tsport *port = fe-dvb-priv;
 struct cx23885_dev *dev = port-dev;
496,503d491
 if (voltage == SEC_VOLTAGE_18)
 cx_write(MC417_RWD, 0x1e00);/* GPIO-13 high */
 else if (voltage == SEC_VOLTAGE_13)
 cx_write(MC417_RWD, 0x1a00);/* GPIO-13 low */
 else
 cx_write(MC417_RWD, 0x1800);/* GPIO-12 low */
 return 0;
 }
985,994d972
 case CX23885_BOARD_TEVII_S471:
 i2c_bus = dev-i2c_bus[1];

 fe0-dvb.frontend = dvb_attach(ds3000_attach,
 tevii_ds3000_config,
 i2c_bus-i2c_adap);
 if (fe0-dvb.frontend != NULL)
 fe0-dvb.frontend-ops.set_voltage = f300_set_voltage;

 break;
1270,1282d1247
 memcpy(port-frontends.adapter.proposed_mac, eeprom + 0xa0, 6);
 break;
 }
 case CX23885_BOARD_TEVII_S471: {
 u8 eeprom[256]; /* 24C02 i2c eeprom */

 if (port-nr != 1)
 break;

 /* Read entire EEPROM */
 dev-i2c_bus[0].i2c_client.addr = 0xa0  1;
 tveeprom_read(dev-i2c_bus[0].i2c_client, eeprom, 
sizeof(eeprom));

 printk(KERN_INFO TeVii S471 MAC= %pM\n, eeprom + 0xa0);

diff ./cx23885-cards.c ./cx23885-cards.c.orig:
500,504c500
 },
 [CX23885_BOARD_TEVII_S471] = {
 .name= TeVii S471,
 .portb= CX23885_MPEG_DVB,
 },
---

 }

712,715d707
 }, {
 .subvendor = 0xd471,
 .subdevice = 0x9022,
 .card  = CX23885_BOARD_TEVII_S471,
1312,1322d1303
 case CX23885_BOARD_TEVII_S471:
 if (!enable_885_ir)
 break;
 dev-sd_ir = cx23885_find_hw(dev, CX23885_HW_AV_CORE);
 if (dev-sd_ir == NULL) {
 ret = -ENODEV;
 break;
 }
 v4l2_subdev_call(dev-sd_cx25840, core, s_io_pin_config,
  ir_rx_pin_cfg_count, ir_rx_pin_cfg);
 break;
1353d1333
 case CX23885_BOARD_TEVII_S471:
1397d1376
 case CX23885_BOARD_TEVII_S471:
1484d1462
 case CX23885_BOARD_TEVII_S471:
1542d1519
 case CX23885_BOARD_TEVII_S471:

diff ./cx23885.h ./cx23885.h.orig
92d91
 #define CX23885_BOARD_TEVII_S471   35

--
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: OV2640 and iMX25PDK - help needed

[Fernandez Gonzalo]

Hi again,

Hi,

On 2 February 2012 15:01, Fabio Estevam feste...@gmail.com wrote:
 On 2/1/12, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
 Hello Gonzalo

 On Tue, 31 Jan 2012, Fernandez Gonzalo wrote:

 Hi all,

 I've been working for a while with an iMX25PDK using the BSP
provided by
 Freescale (L2.6.31). The camera driver (V4L2-int) and examples do
the
 job quite well but I need to move my design to a more recent
kernel.
 I've been extensively googling but haven't found any info/examples
about
 how to run the mx2_camera driver in the i.MX25PDK. I'm stuck at
this,
 could someone point me in the right direction? Thank you in
advance...

 i.MX25PDK is supported in the mainline kernel
 (arch/arm/mach-imx/mach-mx25_3ds.c), but it doesn't attach any
cameras.
 Unfortunately, I also don't currently see any i.MX2x platforms in
the
 mainline with cameras, so, you have to begin by looking at
 arch/arm/plat-mxc/include/mach/mx2_cam.h, at
 arch/arm/plat-mxc/devices/platform-mx2-camera.c for the
 imx27_add_mx2_camera() function and maybe some i.MX3x or i.MX1
examples.

 Javier has been doing a lot of work on mx2-camera lately.

 Javier,

 Is mach-imx27_visstrim_m10 board connected to a CMOS camera? Do you
 have patches for adding camera support to mach-imx27_visstrim_m10?

visstrim_m10 is connected to a tvp5150 but it uses the same interface
as a CMOS sensor. Let me find some time to send a patch that I have
pending in my queue. Then it can be used by Gonzalo as a reference.

Regards.
-- 
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com

I've been finally able to attach the ov2640 camera in the i.MX25PDK.
I've had some problems with the clocks, but a quick dirty fix looks to
solve this issue (I'll work on cleaner solution later).

Now I have to send the camera stream to somewhere. In the example
provided by Freescale based on L2.6.31, somewhere is the framebuffer,
and this is done using VIDIOC_S_FBUF and VIDIOC_OVERLAY ioctls. As these
2 ioctls are not currently implemented in soc_camera.c, I was wondefing
if it exist a different preferred method to implement this
functionality?

Regards,
Gonzalo. 
--
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: OV2640 and iMX25PDK - help needed

[Fabio Estevam]

Hi Gonzalo,

On 2/10/12, Fernandez Gonzalo gfernan...@copreci.es wrote:

 I've been finally able to attach the ov2640 camera in the i.MX25PDK.
 I've had some problems with the clocks, but a quick dirty fix looks to
 solve this issue (I'll work on cleaner solution later).

Great to know that you are having progress.

 Now I have to send the camera stream to somewhere. In the example
 provided by Freescale based on L2.6.31, somewhere is the framebuffer,
 and this is done using VIDIOC_S_FBUF and VIDIOC_OVERLAY ioctls. As these
 2 ioctls are not currently implemented in soc_camera.c, I was wondefing
 if it exist a different preferred method to implement this
 functionality?

In order to test if you are capturing the image correctly you can
launch a Gstreamer pipeline and use filesink to save the stream to a
file.

Or you can also send it to the framebuffer, with something like:

gst-launch -v v4l2src device=/dev/video0 !\
video/x-raw-yuv,width=320,height=240 !\
ffmpegcolorspace ! fbdevsink

Regards,

Fabio Estevam
--
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: OV2640 and iMX25PDK - help needed

[Guennadi Liakhovetski]

Hello Gonzalo

On Tue, 31 Jan 2012, Fernandez Gonzalo wrote:

 Hi all,
 
 I've been working for a while with an iMX25PDK using the BSP provided by
 Freescale (L2.6.31). The camera driver (V4L2-int) and examples do the
 job quite well but I need to move my design to a more recent kernel.
 I've been extensively googling but haven't found any info/examples about
 how to run the mx2_camera driver in the i.MX25PDK. I'm stuck at this,
 could someone point me in the right direction? Thank you in advance...

i.MX25PDK is supported in the mainline kernel 
(arch/arm/mach-imx/mach-mx25_3ds.c), but it doesn't attach any cameras. 
Unfortunately, I also don't currently see any i.MX2x platforms in the 
mainline with cameras, so, you have to begin by looking at 
arch/arm/plat-mxc/include/mach/mx2_cam.h, at 
arch/arm/plat-mxc/devices/platform-mx2-camera.c for the 
imx27_add_mx2_camera() function and maybe some i.MX3x or i.MX1 examples.

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: OV2640 and iMX25PDK - help needed

[Fernandez Gonzalo]

Hi Guennadi,

Hello Gonzalo

On Tue, 31 Jan 2012, Fernandez Gonzalo wrote:

 Hi all,
 
 I've been working for a while with an iMX25PDK using the BSP
provided by
 Freescale (L2.6.31). The camera driver (V4L2-int) and examples do
the
 job quite well but I need to move my design to a more recent kernel.
 I've been extensively googling but haven't found any info/examples
about
 how to run the mx2_camera driver in the i.MX25PDK. I'm stuck at
this,
 could someone point me in the right direction? Thank you in
advance...

i.MX25PDK is supported in the mainline kernel 
(arch/arm/mach-imx/mach-mx25_3ds.c), but it doesn't attach any cameras.

Unfortunately, I also don't currently see any i.MX2x platforms in the 
mainline with cameras, so, you have to begin by looking at 
arch/arm/plat-mxc/include/mach/mx2_cam.h, at 
arch/arm/plat-mxc/devices/platform-mx2-camera.c for the 
imx27_add_mx2_camera() function and maybe some i.MX3x or i.MX1
examples.

Thanks
Guennadi

Thank you very much for the tip !!! 
I'll look at the files you have pointed.

Regards,
Gonzalo.
--
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: OV2640 and iMX25PDK - help needed

[Fabio Estevam]

On 2/1/12, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
 Hello Gonzalo

 On Tue, 31 Jan 2012, Fernandez Gonzalo wrote:

 Hi all,

 I've been working for a while with an iMX25PDK using the BSP provided by
 Freescale (L2.6.31). The camera driver (V4L2-int) and examples do the
 job quite well but I need to move my design to a more recent kernel.
 I've been extensively googling but haven't found any info/examples about
 how to run the mx2_camera driver in the i.MX25PDK. I'm stuck at this,
 could someone point me in the right direction? Thank you in advance...

 i.MX25PDK is supported in the mainline kernel
 (arch/arm/mach-imx/mach-mx25_3ds.c), but it doesn't attach any cameras.
 Unfortunately, I also don't currently see any i.MX2x platforms in the
 mainline with cameras, so, you have to begin by looking at
 arch/arm/plat-mxc/include/mach/mx2_cam.h, at
 arch/arm/plat-mxc/devices/platform-mx2-camera.c for the
 imx27_add_mx2_camera() function and maybe some i.MX3x or i.MX1 examples.

Javier has been doing a lot of work on mx2-camera lately.

Javier,

Is mach-imx27_visstrim_m10 board connected to a CMOS camera? Do you
have patches for adding camera support to mach-imx27_visstrim_m10?

Thanks,

Fabio Estevm
--
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: OV2640 and iMX25PDK - help needed

[javier Martin]

Hi,

On 2 February 2012 15:01, Fabio Estevam feste...@gmail.com wrote:
 On 2/1/12, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
 Hello Gonzalo

 On Tue, 31 Jan 2012, Fernandez Gonzalo wrote:

 Hi all,

 I've been working for a while with an iMX25PDK using the BSP provided by
 Freescale (L2.6.31). The camera driver (V4L2-int) and examples do the
 job quite well but I need to move my design to a more recent kernel.
 I've been extensively googling but haven't found any info/examples about
 how to run the mx2_camera driver in the i.MX25PDK. I'm stuck at this,
 could someone point me in the right direction? Thank you in advance...

 i.MX25PDK is supported in the mainline kernel
 (arch/arm/mach-imx/mach-mx25_3ds.c), but it doesn't attach any cameras.
 Unfortunately, I also don't currently see any i.MX2x platforms in the
 mainline with cameras, so, you have to begin by looking at
 arch/arm/plat-mxc/include/mach/mx2_cam.h, at
 arch/arm/plat-mxc/devices/platform-mx2-camera.c for the
 imx27_add_mx2_camera() function and maybe some i.MX3x or i.MX1 examples.

 Javier has been doing a lot of work on mx2-camera lately.

 Javier,

 Is mach-imx27_visstrim_m10 board connected to a CMOS camera? Do you
 have patches for adding camera support to mach-imx27_visstrim_m10?

visstrim_m10 is connected to a tvp5150 but it uses the same interface
as a CMOS sensor. Let me find some time to send a patch that I have
pending in my queue. Then it can be used by Gonzalo as a reference.

Regards.
-- 
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
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

OV2640 and iMX25PDK - help needed

[Fernandez Gonzalo]

Hi all,

I've been working for a while with an iMX25PDK using the BSP provided by
Freescale (L2.6.31). The camera driver (V4L2-int) and examples do the
job quite well but I need to move my design to a more recent kernel.
I've been extensively googling but haven't found any info/examples about
how to run the mx2_camera driver in the i.MX25PDK. I'm stuck at this,
could someone point me in the right direction? Thank you in advance...

Best regards,
Gonzalo
--
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

need help with x3m dvb-t tuner on linux

[Paweł Drobek]

Hi
I herbly please for assistance with x3m dvb-t tuner on linux. Let me know if 
this device has any chance to work on linux.
I followed http://linuxtv.org/wiki/index.php/X3m_digital_S.A_HPC2000 without 
success.
lspci output below 

pdmainframe pd # lspci 
00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a1)
00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2)
00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1)
00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)
00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)
00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2)
00:06.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2)
00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2)
00:0b.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:0c.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:0d.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address 
Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM 
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Miscellaneous Control
01:00.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI 
Video and Audio Decoder (rev 05)
01:00.1 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video 
and Audio Decoder [Audio Port] (rev 05)
01:00.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video 
and Audio Decoder [MPEG Port] (rev 05)
06:00.0 PCI bridge: nVidia Corporation PCI express bridge for GTX 295 (rev a3)
07:00.0 PCI bridge: nVidia Corporation PCI express bridge for GTX 295 (rev a3)
07:02.0 PCI bridge: nVidia Corporation PCI express bridge for GTX 295 (rev a3)
08:00.0 3D controller: nVidia Corporation Device 05eb (rev a1)
09:00.0 VGA compatible controller: nVidia Corporation Device 05eb (rev a1)

dmesg | grep cx88 below

pdmainframe pd # dmesg | grep cx88
cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.9 loaded
cx88/0: cx2388x v4l2 driver version 0.0.9 loaded
cx88[0]: subsystem: 14f1:8852, board: Leadtek WinFast DTV1800 Hybrid 
[card=81,insmod option], frontend(s): 1
cx88[0]: TV tuner type 71, Radio tuner type 71
cx88[0]: Asking xc2028/3028 to load firmware xc3028-v27.fw
input: cx88 IR (Leadtek WinFast DTV180 as 
/devices/pci:00/:00:06.0/:01:00.2/rc/rc1/input6
rc1: cx88 IR (Leadtek WinFast DTV180 as 
/devices/pci:00/:00:06.0/:01:00.2/rc/rc1
cx88[0]/2: cx2388x 8802 Driver Manager
cx88-mpeg driver manager :01:00.2: PCI INT A - Link[LNKA] - GSI 19 
(level, low) - IRQ 19
cx88[0]/2: found at :01:00.2, rev: 5, irq: 19, latency: 64, mmio: 0xf300
cx8800 :01:00.0: PCI INT A - Link[LNKA] - GSI 19 (level, low) - IRQ 19
cx88[0]/0: found at :01:00.0, rev: 5, irq: 19, latency: 64, mmio: 0xf500
cx88/2: cx2388x dvb driver version 0.0.9 loaded
cx88/2: registering cx8802 driver, type: dvb access: shared
cx88[0]/2: subsystem: 14f1:8852, board: Leadtek WinFast DTV1800 Hybrid [card=81]
cx88[0]/0: registered device video0 [v4l2]
cx88[0]/0: registered device vbi0
cx88[0]/0: registered device radio0
cx88[0]/2: cx2388x based DVB/ATSC card
cx8802_alloc_frontends() allocating 1 frontend(s)
cx88_audio :01:00.1: PCI INT A - Link[LNKA] - GSI 19 (level, low) - IRQ 
19
cx88[0]/1: CX88x/0: ALSA support for cx2388x boards
cx88[0]/2: xc3028 attached
DVB: registering new adapter (cx88[0])

dmesg | grep xc2 below

xc2028 2-0061: i2c output error: rc = -5 (should be 4)
xc2028 2-0061: -5 returned from send
xc2028 2-0061: Error -22 while loading base firmware 

i tried a lot of firmwares (from debian, or other sources) - result is the same 
- stuck
--
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

Strange problem, help needed

[David Engel]

Hi,

I have a MythTV backend with a Hauppauge HVR-2250 (dual tuner,
ATSC?QAM, PCIe) and a Ceton InfiniTV4 (quad tuner, QAM/cable card,
PCIe).  Over the weekend, I started intermittently seeing corrupt
recordings that were painful to watch.

I eventually narrowed the problem down to when both tuners on the 2250
are active at the same time.  In this case, both recordings have
corruption (CRC errors, etc.).  The InfiniTV4 does not appear to be
affected by anything going on on the 2250.  Likewise, the 2250 does
not appear to be affected by anything going on on the InfiniTV4.

I noticed something strange while diagnosinig the problem.  When the
2250 is busy recording, top reports the CPU as being in wait for an
abnormally high amount of time (~30% for one tuner busy and ~50% for
both tuners busy).  I don't recall seeing that before.  I quickly
tried a KWorld ATSC 110 on a different system and it showed no, or
negligible wait time.

Thinking that the 2250 was going bad, I replaced it with two KWorld
ATSC 110s (single tuner, ATSC/QAM, PCI).  The two 110s had the same
problem as the 2250 -- corruption when both tuners are busy and
unusually high wait time when either is busy.

At this point, I'm suspecting a motherboard, memory or grounding
issue, but would like some feedback in case there's anything I'm
missing.  The high wait time seems extremely odd to me.  Perhaps it
means something to those of you who are much more familiar with the
cards and drivers.

Oh, the problem appear shortly after switching to the 3.1.9 kernel.  I
also tried the 3.1.8 and 3.0.14 kernels to rule out software and there
was no effect on the problem.

David
-- 
David Engel
da...@istwok.net
--
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: Strange problem, help needed

[Andy Walls]

On Mon, 2012-01-16 at 11:55 -0600, David Engel wrote:
 Hi,
 
 I have a MythTV backend with a Hauppauge HVR-2250 (dual tuner,
 ATSC?QAM, PCIe) and a Ceton InfiniTV4 (quad tuner, QAM/cable card,
 PCIe).  Over the weekend, I started intermittently seeing corrupt
 recordings that were painful to watch.
 
 I eventually narrowed the problem down to when both tuners on the 2250
 are active at the same time.  In this case, both recordings have
 corruption (CRC errors, etc.).  The InfiniTV4 does not appear to be
 affected by anything going on on the 2250.  Likewise, the 2250 does
 not appear to be affected by anything going on on the InfiniTV4.
 
 I noticed something strange while diagnosinig the problem.  When the
 2250 is busy recording, top reports the CPU as being in wait for an
 abnormally high amount of time (~30% for one tuner busy and ~50% for
 both tuners busy).  I don't recall seeing that before.  I quickly
 tried a KWorld ATSC 110 on a different system and it showed no, or
 negligible wait time.
 
 Thinking that the 2250 was going bad, I replaced it with two KWorld
 ATSC 110s (single tuner, ATSC/QAM, PCI).  The two 110s had the same
 problem as the 2250 -- corruption when both tuners are busy and
 unusually high wait time when either is busy.
 
 At this point, I'm suspecting a motherboard, memory or grounding
 issue, but would like some feedback in case there's anything I'm
 missing.  The high wait time seems extremely odd to me.  Perhaps it
 means something to those of you who are much more familiar with the
 cards and drivers.

A long time in IO Wait and (presumably) dropped video data buffers for a
TV card driver usually means:

a. The devices are not producing interrupts
b. Your system is dropping interrupts from the devices
c. Something in your system keeps interrupt processing disabled for a
long time.

Of the above c. is unlikely.

The root causes of a. and b. are many and varied.  However most of those
root causes are under control of kernel software: core IRQ handling,
core PCI/e bus setup, or tv card driver modules and their supporting
modules.

Hardware related root causes would be buggy PCI chipsets, poor RF
signal, a motherboard problem, or a power problem.

I tend to blame the software before the hardware.


Sometimes, dust in the shared, conventional PCI bus can cause problems.
If you have conventional PCI slots in the system - whether you use them
or not -  unplug the conventional PCI cards, blow the dust out of all
the slots, and reseat the cards.  You should not need to do this for any
PCIe card slots, but it doesn't hurt.


Regards,
Andy 

 Oh, the problem appear shortly after switching to the 3.1.9 kernel.  I
 also tried the 3.1.8 and 3.0.14 kernels to rule out software and there
 was no effect on the problem.

 David


--
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: Strange problem, help needed

[David Engel]

On Mon, Jan 16, 2012 at 01:45:24PM -0500, Andy Walls wrote:
 On Mon, 2012-01-16 at 11:55 -0600, David Engel wrote:
  Hi,
  
  I have a MythTV backend with a Hauppauge HVR-2250 (dual tuner,
  ATSC?QAM, PCIe) and a Ceton InfiniTV4 (quad tuner, QAM/cable card,
  PCIe).  Over the weekend, I started intermittently seeing corrupt
  recordings that were painful to watch.
  
  I eventually narrowed the problem down to when both tuners on the 2250
  are active at the same time.  In this case, both recordings have
  corruption (CRC errors, etc.).  The InfiniTV4 does not appear to be
  affected by anything going on on the 2250.  Likewise, the 2250 does
  not appear to be affected by anything going on on the InfiniTV4.
  
  I noticed something strange while diagnosinig the problem.  When the
  2250 is busy recording, top reports the CPU as being in wait for an
  abnormally high amount of time (~30% for one tuner busy and ~50% for
  both tuners busy).  I don't recall seeing that before.  I quickly
  tried a KWorld ATSC 110 on a different system and it showed no, or
  negligible wait time.
  
  Thinking that the 2250 was going bad, I replaced it with two KWorld
  ATSC 110s (single tuner, ATSC/QAM, PCI).  The two 110s had the same
  problem as the 2250 -- corruption when both tuners are busy and
  unusually high wait time when either is busy.
  
  At this point, I'm suspecting a motherboard, memory or grounding
  issue, but would like some feedback in case there's anything I'm
  missing.  The high wait time seems extremely odd to me.  Perhaps it
  means something to those of you who are much more familiar with the
  cards and drivers.
 
 A long time in IO Wait and (presumably) dropped video data buffers for a
 TV card driver usually means:
 
 a. The devices are not producing interrupts
 b. Your system is dropping interrupts from the devices
 c. Something in your system keeps interrupt processing disabled for a
 long time.

I tried the crude test of monitoring /proc/interrupts while recording.
Using a third KWorld ATSC 110 on my development system, which isn't
showing any problems, the driver serviced ~1200 interrupts per minute.
I saw the same amount per card using two other 110s on my MythTV system, which
is exhibiting the problem.

 Of the above c. is unlikely.
 
 The root causes of a. and b. are many and varied.  However most of those
 root causes are under control of kernel software: core IRQ handling,
 core PCI/e bus setup, or tv card driver modules and their supporting
 modules.
 
 Hardware related root causes would be buggy PCI chipsets, poor RF
 signal, a motherboard problem, or a power problem.
 
 I tend to blame the software before the hardware.
 
 
 Sometimes, dust in the shared, conventional PCI bus can cause problems.
 If you have conventional PCI slots in the system - whether you use them
 or not -  unplug the conventional PCI cards, blow the dust out of all
 the slots, and reseat the cards.  You should not need to do this for any
 PCIe card slots, but it doesn't hurt.

I also tried the HVR-2250 in my development system this evening.  It
worked fine.  It's definitely something specific to my MythTV system.
I can't do any further testing until Wednesday.  Thoroughly blowing
out the case might have to wait until the weekend.

Thanks for you help.

David

 Regards,
 Andy 
 
  Oh, the problem appear shortly after switching to the 3.1.9 kernel.  I
  also tried the 3.1.8 and 3.0.14 kernels to rule out software and there
  was no effect on the problem.
 
  David
 
 
 --
 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

-- 
David Engel
da...@istwok.net
--
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: Tr. : Irdeto Cam Problem, any help

[COEXSI]

en50221_stdcam_llci_poll: Error reported by stack:-7 :
This isn’t really an error, it’s a design flaw in the libdvben50221 (it’s 
receving something it isn’t waiting for), it’s more a warning.I’ve published a 
patch for correcting that  few months ago (I think the patch wasn’t noticed...)

There must be something wrong elsewhere, as I never got this error 
EN50221ERR_BADCAMDATA.
There is only one place where the code generate this error, in 
en50221_stdcam_llci.c, during CAM reset :

static void llci_cam_in_reset(struct en50221_stdcam_llci *llci)
{
if (dvbca_get_cam_state(llci-cafd, llci-slotnum) != 
DVBCA_CAMSTATE_READY) {
return;
}

// register the slot
if ((llci-tl_slot_id = en50221_tl_register_slot(llci-tl, llci-cafd, 
llci-slotnum,
 
LLCI_RESPONSE_TIMEOUT_MS, LLCI_POLL_DELAY_MS))  0) {
llci-state = EN50221_STDCAM_CAM_BAD;
return;
}

// create a new connection on the slot
if (en50221_tl_new_tc(llci-tl, llci-tl_slot_id)  0) {
llci-state = EN50221_STDCAM_CAM_BAD;
llci-tl_slot_id = -1;
en50221_tl_destroy_slot(llci-tl, llci-tl_slot_id);
return;
}

llci-state = EN50221_STDCAM_CAM_OK;
}

As there are many possible sources for this error, it may be useful to check 
the value of the tl-error variable.

Sebastien.


From: dub...@crans.org [mailto:dub...@crans.org] 
Sent: mercredi 7 décembre 2011 00:05
To: sraill...@coexsi.fr
Subject: Tr. : Irdeto Cam Problem, any help

C'est pour toi ça. 

-- 
Brice

- Forwarded message -
De : JULIAN GARDNER joo...@btinternet.com
Pour : linux-media@vger.kernel.org linux-media@vger.kernel.org
Objet : Irdeto Cam Problem, any help
Date : mar., déc. 6, 2011 23:50


Been trying now to get my IrdetoCam and card working, im using mumudvb for this.

Turning on debug i get the folowing in the output

nfo:  Autoconf:  Channel number :   0, name : ERT World  service id 0 
Info:  Autoconf:  Multicast4 ip : 227.25.0.1:1234
Deb0:  Autoconf:  pids : 5001 (PMT), 1160 (Video (MPEG4-AVC)), 1120 
(Audio (MPEG2)), 
Info:  Main:  Channel ERT World is
now higly scrambled (97% of scrambled packets). Card 0
en50221_tl_handle_sb: Received T_SB for connection not in T_STATE_ACTIVE from 
module on slot 00

en50221_stdcam_llci_poll: Error reported by stack:-7

Deb1:  CAM:  Status change from EN50221_STDCAM_CAM_INRESET to 
EN50221_STDCAM_CAM_OK.
WARN: 
CAM:  Transport Layer Error change from EN50221ERR_NONE (No Error.) to 
EN50221ERR_BADCAMDATA (CAM supplied an invalid request.)
Deb1:  CAM:  CAM Application_Info_Callback
Info:  CAM:  CAM Application type: 01
Info:  CAM:  CAM Application manufacturer: cafe
Info:  CAM:  CAM Manufacturer code: babe
Info:  CAM:  CAM Menu string: Irdeto Access

Now can anybody help with the -7 error, as i am getting no decryption.

Patches would be welcome, before i start trying to delve deeper in

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

Irdeto Cam Problem, any help

[JULIAN GARDNER]

Been trying now to get my IrdetoCam and card working, im using mumudvb for this.

Turning on debug i get the folowing in the output

nfo:  Autoconf:  Channel number :   0, name : ERT World  service id 0 
Info:  Autoconf:      Multicast4 ip : 227.25.0.1:1234
Deb0:  Autoconf:  pids : 5001 (PMT), 1160 (Video (MPEG4-AVC)), 1120 
(Audio (MPEG2)), 
Info:  Main:  Channel ERT World is
 now higly scrambled (97% of scrambled packets). Card 0
en50221_tl_handle_sb: Received T_SB for connection not in T_STATE_ACTIVE from 
module on slot 00

en50221_stdcam_llci_poll: Error reported by stack:-7

Deb1:  CAM:  Status change from EN50221_STDCAM_CAM_INRESET to 
EN50221_STDCAM_CAM_OK.
WARN: 
 CAM:  Transport Layer Error change from EN50221ERR_NONE (No Error.) to 
EN50221ERR_BADCAMDATA (CAM supplied an invalid request.)
Deb1:  CAM:  CAM Application_Info_Callback
Info:  CAM:  CAM Application type: 01
Info:  CAM:  CAM Application manufacturer: cafe
Info:  CAM:  CAM Manufacturer code: babe
Info:  CAM:  CAM Menu string: Irdeto Access

Now can anybody help with the -7 error, as i am getting no decryption.

Patches would be welcome, before i start trying to delve deeper in

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

help

[Mario Torres]

Can I say a word to you guys?

Cool

I got one AVerMedia M792 PCIe Combo (OEM) on Ubuntu 11.10 and i wonder 
if we can work it out, it is a pci-e and yes it is on the unsupported 
list. but if we can work it out lets do it.


when i do a lspci -vv
it gives me this


03:00.0 Multimedia video controller: Conexant Systems, Inc. CX23887/8 
PCIe Broadcast Audio and Video Decoder with 3D Comb (rev 0f)

Subsystem: Avermedia Technologies Inc Device df39
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- 
TAbort- MAbort- SERR- PERR- INTx-

Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory at f9e0 (64-bit, non-prefetchable) [size=2M]
Capabilities: access denied
Kernel driver in use: cx23885
Kernel modules: cx23885
--
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

help

[Mario Torres]

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

help

[Mario Torres]

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

help with azap

[James]

$ more channels.conf
CIII-HD:8500:8VSB:49:52+53:1
OTTAWA CBOFT-DT:18900:8VSB:49:53+52:3
CJOH:21300:8VSB:49:51+52:1
TVO:53300:8VSB:49:52+53:1
OTTAWA  CBOT-DT:53900:8VSB:49:52+53:3
Télé-Québec_HD:56900:8VSB:49:52+53:3
CHOT:62900:8VSB:49:52:3

$ azap -c channels.conf CJOH
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
ERROR: error while parsing Audio PID (not a number)

$ tzap -c channels.conf CJOH
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file 'channels.conf'
ERROR: error while parsing inversion (syntax error)

Why does tzap show what file it is reading the channel list from but 
azap doesn't?


What does ERROR: error while parsing Audio PID (not a number) mean?
--
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: help with azap

[Devin Heitmueller]

On Thu, Oct 13, 2011 at 2:14 PM, James bjloc...@lockie.ca wrote:
 $ more channels.conf
 CIII-HD:8500:8VSB:49:52+53:1
 OTTAWA CBOFT-DT:18900:8VSB:49:53+52:3
 CJOH:21300:8VSB:49:51+52:1
 TVO    :53300:8VSB:49:52+53:1
 OTTAWA  CBOT-DT:53900:8VSB:49:52+53:3
 Télé-Québec_HD:56900:8VSB:49:52+53:3
 CHOT:62900:8VSB:49:52:3

 $ azap -c channels.conf CJOH
 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
 ERROR: error while parsing Audio PID (not a number)

 $ tzap -c channels.conf CJOH
 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
 reading channels from file 'channels.conf'
 ERROR: error while parsing inversion (syntax error)

 Why does tzap show what file it is reading the channel list from but azap
 doesn't?

If I recall, tzap and azap are actually from different codebases
(although I believe one was originally derived from the other).  That
is why the output is a little inconsistent.

That said, you should not be using tzap for ATSC/ClearQAM.  tzap is for DVB-T.

 What does ERROR: error while parsing Audio PID (not a number) mean?

I don't know where your channels.conf came from, but it appears to be
malformed.  You cannot have 52+53 as the audio PID.  If you just
want to get up and running, remove the +53 part.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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: help with azap

[James]

On 10/13/11 14:30, Devin Heitmueller wrote:

On Thu, Oct 13, 2011 at 2:14 PM, Jamesbjloc...@lockie.ca  wrote:

$ more channels.conf
CIII-HD:8500:8VSB:49:52+53:1
OTTAWA CBOFT-DT:18900:8VSB:49:53+52:3
CJOH:21300:8VSB:49:51+52:1
TVO:53300:8VSB:49:52+53:1
OTTAWA  CBOT-DT:53900:8VSB:49:52+53:3
Télé-Québec_HD:56900:8VSB:49:52+53:3
CHOT:62900:8VSB:49:52:3



What does ERROR: error while parsing Audio PID (not a number) mean?

I don't know where your channels.conf came from, but it appears to be
malformed.  You cannot have 52+53 as the audio PID.  If you just
want to get up and running, remove the +53 part.

Devin


I used:
w_scan -f a -c US -M
(mplayer format)

I redid it with:
w_scan -f a -c US -X
(czap/tzap/szap/xine)
and got:
CIII-HD:8500:8VSB:49:52:1
OTTAWA CBOFT-DT:18900:8VSB:49:53:3
CJOH:21300:8VSB:49:51:1
TVO:53300:8VSB:49:52:1
OTTAWA  CBOT-DT:53900:8VSB:49:52:3
Télé-Québec_HD:56900:8VSB:49:52:3
CHOT:62900:8VSB:49:52:3

It is weird there is not a standard format. :-)

--
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: Help with omap3isp resizing

[Sakari Ailus]

On Wed, Oct 05, 2011 at 01:51:29PM +1100, Paul Chiha wrote:
 On Tue, Oct 04, 2011 at 03:00:55PM +0200, Laurent Pinchart wrote:
  Hi Ivan,
  
  On Tuesday 04 October 2011 13:54:12 Ivan T. Ivanov wrote:
   On Tue, 2011-10-04 at 13:50 +0200, Laurent Pinchart wrote:
On Tuesday 04 October 2011 13:46:32 Ivan T. Ivanov wrote:
 On Tue, 2011-10-04 at 13:03 +0200, Laurent Pinchart wrote:
  On Monday 03 October 2011 07:51:34 Paul Chiha wrote:
   Hi,
  
   I've been having trouble getting the resizer to work, and
   mainly because I don't know how to correctly configure it.
   I'm using kernel 2.6.37 on arm DM37x board.
  
   I've been able to configure the media links
   sensor=ccdc=ccdc_output (all with 640x480
   V4L2_MBUS_FMT_UYVY8_2X8) and VIDIOC_STREAMON works on
  /dev/video2.
   But if I configure media links
   sensor=ccdc=resizer=resizer_output, then VIDIOC_STREAMON
   fails on /dev/video6 (with pixelformat mismatch). I noticed
   that the resizer driver only supports
   V4L2_MBUS_FMT_UYVY8_1X16  V4L2_MBUS_FMT_YUYV8_1X16, so I
   tried again with all the links set to V4L2_MBUS_FMT_UYVY8_1X16
   instead, but then ioctl VIDIOC_SUBDEV_S_FMT fails on
   /dev/v4l-subdev8, because the sensor driver doesn't support 1X16.
   Then I tried using V4L2_MBUS_FMT_UYVY8_2X8 for the sensor and
   V4L2_MBUS_FMT_UYVY8_1X16 for the resizer, but it either failed
   with pixelformat mismatch or link pipeline mismatch, depending
   on which pads were different.
  
   Can someone please tell me what I need to do to make this work?
 
  Long story short, I don't think that pipeline has ever been tested.
  I'm unfortunately lacking hardware to work on that, as none of
  my
  OMAP3 hardware has a YUV input.

 If i am not mistaken currently resizer sub device supports only:

 /* resizer pixel formats */
 static const unsigned int resizer_formats[] = {

   V4L2_MBUS_FMT_UYVY8_1X16,
   V4L2_MBUS_FMT_YUYV8_1X16,

 };

 Adding something like this [1] in ispresizer.c  should add support
 2X8 formats. Completely untested :-).

 Regards,
 iivanov


 [1]

 @@ -1307,6 +1311,10 @@ static int resizer_s_crop(struct
 v4l2_subdev *sd, struct v4l2_subdev_fh *fh, static const unsigned
 int resizer_formats[] = {

   V4L2_MBUS_FMT_UYVY8_1X16,
   V4L2_MBUS_FMT_YUYV8_1X16,

 + V4L2_MBUS_FMT_UYVY8_2X8,
 + V4L2_MBUS_FMT_VYUY8_2X8,
 + V4L2_MBUS_FMT_YUYV8_2X8,
 + V4L2_MBUS_FMT_YVYU8_2X8,

  };
   
I'd rather modify ispccdc.c to output V4L2_MBUS_FMT_YUYV8_1X16. What
do you think ?
  
   For memory-Resizer-memory use cases, CCDC is no involved in pipeline.
  
  But the original poster wants to use the sensor - ccdc - resizer - 
  resizer output
  pipeline.
  
   Also several sensor drivers that i have checked, usually define its
   output as 2X8 output. I think is more natural to add 2X8 support to
   CCDC and Resizer engines instead to modifying exiting drivers.
  
  Sure, sensor drivers should not be modified. What I was talking about was to
  configure the pipeline as
  
  sensor:0 [YUYV8_2X8], CCDC:0 [YUYV8_2X8], CCDC:1 [YUYV8_1X16], resizer:0
  [YUYV8_1X16]
  
  --
  Regards,
  
  Laurent Pinchart
 
 Thanks for your help. I've updated ispccdc.c to support the _1X16 codes
 and the pipeline seems to work now. However, I needed to take out the
 memcpy in ccdc_try_format(), because otherwise pad 0 format was being
 copied to pad 1 or 2, regardless of what pad 1 or 2 were being set to. I'm
 not sure why it was done that way. I think it's better that the given code
 gets checked to see if it's in the list and if so use it. Do you know of
 any valid reason why this copy is done?

If I remember corretly, it's because there's nothing the CCDC may do to the
size of the image --- the driver doesn't either support cropping on the
CCDC. The sink format used to be always the same as the source format, the
assumption which no longer is valid when YUYV8_2X8 etc. formats are
supported. This must be taken into account, i.e. YUYV8_2X8 must be converted
to YUYV8_1X16 instead of just copying the format as such.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
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: Help with omap3isp resizing

[Enrico]

On Wed, Oct 5, 2011 at 12:54 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
 On Wed, Oct 05, 2011 at 01:51:29PM +1100, Paul Chiha wrote:
 Thanks for your help. I've updated ispccdc.c to support the _1X16 codes
 and the pipeline seems to work now. However, I needed to take out the
 memcpy in ccdc_try_format(), because otherwise pad 0 format was being
 copied to pad 1 or 2, regardless of what pad 1 or 2 were being set to. I'm
 not sure why it was done that way. I think it's better that the given code
 gets checked to see if it's in the list and if so use it. Do you know of
 any valid reason why this copy is done?

 If I remember corretly, it's because there's nothing the CCDC may do to the
 size of the image --- the driver doesn't either support cropping on the
 CCDC. The sink format used to be always the same as the source format, the
 assumption which no longer is valid when YUYV8_2X8 etc. formats are
 supported. This must be taken into account, i.e. YUYV8_2X8 must be converted
 to YUYV8_1X16 instead of just copying the format as such.

Looking at omap trm (spruf98t, July 2011) figure 12-103 it seems
possible to set some registers (start pixel horizontal/vertical and so
on...) to crop the final image, but i never tested it.

Enrico
--
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: Help with omap3isp resizing

[Sakari Ailus]

On Wed, Oct 05, 2011 at 03:09:48PM +0200, Enrico wrote:
 On Wed, Oct 5, 2011 at 12:54 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
  On Wed, Oct 05, 2011 at 01:51:29PM +1100, Paul Chiha wrote:
  Thanks for your help. I've updated ispccdc.c to support the _1X16 codes
  and the pipeline seems to work now. However, I needed to take out the
  memcpy in ccdc_try_format(), because otherwise pad 0 format was being
  copied to pad 1 or 2, regardless of what pad 1 or 2 were being set to. I'm
  not sure why it was done that way. I think it's better that the given code
  gets checked to see if it's in the list and if so use it. Do you know of
  any valid reason why this copy is done?
 
  If I remember corretly, it's because there's nothing the CCDC may do to the
  size of the image --- the driver doesn't either support cropping on the
  CCDC. The sink format used to be always the same as the source format, the
  assumption which no longer is valid when YUYV8_2X8 etc. formats are
  supported. This must be taken into account, i.e. YUYV8_2X8 must be converted
  to YUYV8_1X16 instead of just copying the format as such.
 
 Looking at omap trm (spruf98t, July 2011) figure 12-103 it seems
 possible to set some registers (start pixel horizontal/vertical and so
 on...) to crop the final image, but i never tested it.

Yeah; cropping should work fine on the CCDC as well but the driver doesn't
implement it.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
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: Help with omap3isp resizing

[Javier Martinez Canillas]

On Wed, Oct 5, 2011 at 3:42 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
 On Wed, Oct 05, 2011 at 03:09:48PM +0200, Enrico wrote:
 On Wed, Oct 5, 2011 at 12:54 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
  On Wed, Oct 05, 2011 at 01:51:29PM +1100, Paul Chiha wrote:
  Thanks for your help. I've updated ispccdc.c to support the _1X16 codes
  and the pipeline seems to work now. However, I needed to take out the
  memcpy in ccdc_try_format(), because otherwise pad 0 format was being
  copied to pad 1 or 2, regardless of what pad 1 or 2 were being set to. I'm
  not sure why it was done that way. I think it's better that the given code
  gets checked to see if it's in the list and if so use it. Do you know of
  any valid reason why this copy is done?
 
  If I remember corretly, it's because there's nothing the CCDC may do to the
  size of the image --- the driver doesn't either support cropping on the
  CCDC. The sink format used to be always the same as the source format, the
  assumption which no longer is valid when YUYV8_2X8 etc. formats are
  supported. This must be taken into account, i.e. YUYV8_2X8 must be 
  converted
  to YUYV8_1X16 instead of just copying the format as such.

 Looking at omap trm (spruf98t, July 2011) figure 12-103 it seems
 possible to set some registers (start pixel horizontal/vertical and so
 on...) to crop the final image, but i never tested it.

 Yeah; cropping should work fine on the CCDC as well but the driver doesn't
 implement it.


Hello,

Yes, cropping with the CCDC is possible, we modified the driver to
only get the active lines of a frame. This is a small part of our
patch that configures the CCDC to decide what is the first line to
output to memory for both even and odd fields.

+   if (pdata-is_bt656)
+   if (format-priv == V4L2_STD_PAL)
+   isp_reg_writel(isp, (PAL_NON_ACTIVE 
+ISPCCDC_VERT_START_SLV0_SHIFT |
+PAL_NON_ACTIVE 
+ISPCCDC_VERT_START_SLV1_SHIFT),
+  OMAP3_ISP_IOMEM_CCDC,
ISPCCDC_VERT_START);
+   else if (format-priv == V4L2_STD_NTSC)
+   isp_reg_writel(isp, (NTSC_NON_ACTIVE 
+ISPCCDC_VERT_START_SLV0_SHIFT |
+NTSC_NON_ACTIVE 
+ISPCCDC_VERT_START_SLV1_SHIFT),
+  OMAP3_ISP_IOMEM_CCDC,
ISPCCDC_VERT_START);


As I told in a previous email [1] we are working to get add proper
support for ITU-R BT656 video data using the ISP and a TVP5151 video
encoder. We are kind of busy to get this working for our tree. But
once it is done, I'll forward port to the last ISP driver and post for
review.

[1]: http://www.spinics.net/lists/linux-media/msg38715.html

Best regards,

 --
 Sakari Ailus
 e-mail: sakari.ai...@iki.fi     jabber/XMPP/Gmail: sai...@retiisi.org.uk
 --
 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


-- 
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
--
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: Help with omap3isp resizing

[Paul Chiha]

On Wednesday, 5 October 2011 9:55 PM Sakari Ailus wrote:
 On Wed, Oct 05, 2011 at 01:51:29PM +1100, Paul Chiha wrote:
  On Tue, Oct 04, 2011 at 03:00:55PM +0200, Laurent Pinchart wrote:
   Hi Ivan,
  
   On Tuesday 04 October 2011 13:54:12 Ivan T. Ivanov wrote:
On Tue, 2011-10-04 at 13:50 +0200, Laurent Pinchart wrote:
 On Tuesday 04 October 2011 13:46:32 Ivan T. Ivanov wrote:
  On Tue, 2011-10-04 at 13:03 +0200, Laurent Pinchart wrote:
   On Monday 03 October 2011 07:51:34 Paul Chiha wrote:
Hi,
   
I've been having trouble getting the resizer to work,
and
mainly because I don't know how to correctly configure
it.
I'm using kernel 2.6.37 on arm DM37x board.
   
I've been able to configure the media links
sensor=ccdc=ccdc_output (all with 640x480
V4L2_MBUS_FMT_UYVY8_2X8) and VIDIOC_STREAMON works on
   /dev/video2.
But if I configure media links
sensor=ccdc=resizer=resizer_output, then
VIDIOC_STREAMON fails on /dev/video6 (with pixelformat
mismatch). I noticed that the resizer driver only
supports
V4L2_MBUS_FMT_UYVY8_1X16  V4L2_MBUS_FMT_YUYV8_1X16,
 so I
tried again with all the links set to
V4L2_MBUS_FMT_UYVY8_1X16 instead, but then ioctl
VIDIOC_SUBDEV_S_FMT fails on /dev/v4l-subdev8, because
the
 sensor driver doesn't support 1X16.
Then I tried using V4L2_MBUS_FMT_UYVY8_2X8 for the
sensor
and
V4L2_MBUS_FMT_UYVY8_1X16 for the resizer, but it either
failed with pixelformat mismatch or link pipeline
mismatch, depending on which pads were different.
   
Can someone please tell me what I need to do to make
this work?
  
   Long story short, I don't think that pipeline has ever
been tested.
   I'm unfortunately lacking hardware to work on that, as
none
   of my
   OMAP3 hardware has a YUV input.
 
  If i am not mistaken currently resizer sub device supports
only:
 
  /* resizer pixel formats */
  static const unsigned int resizer_formats[] = {
 
  V4L2_MBUS_FMT_UYVY8_1X16,
  V4L2_MBUS_FMT_YUYV8_1X16,
 
  };
 
  Adding something like this [1] in ispresizer.c  should add
  support
  2X8 formats. Completely untested :-).
 
  Regards,
  iivanov
 
 
  [1]
 
  @@ -1307,6 +1311,10 @@ static int resizer_s_crop(struct
  v4l2_subdev *sd, struct v4l2_subdev_fh *fh, static const
  unsigned int resizer_formats[] = {
 
  V4L2_MBUS_FMT_UYVY8_1X16,
  V4L2_MBUS_FMT_YUYV8_1X16,
 
  +   V4L2_MBUS_FMT_UYVY8_2X8,
  +   V4L2_MBUS_FMT_VYUY8_2X8,
  +   V4L2_MBUS_FMT_YUYV8_2X8,
  +   V4L2_MBUS_FMT_YVYU8_2X8,
 
   };

 I'd rather modify ispccdc.c to output
V4L2_MBUS_FMT_YUYV8_1X16.
 What do you think ?
   
For memory-Resizer-memory use cases, CCDC is no involved in
pipeline.
  
   But the original poster wants to use the sensor - ccdc - resizer
   - resizer output pipeline.
  
Also several sensor drivers that i have checked, usually define
its output as 2X8 output. I think is more natural to add 2X8
support to CCDC and Resizer engines instead to modifying exiting
drivers.
  
   Sure, sensor drivers should not be modified. What I was talking
   about was to configure the pipeline as
  
   sensor:0 [YUYV8_2X8], CCDC:0 [YUYV8_2X8], CCDC:1 [YUYV8_1X16],
   resizer:0 [YUYV8_1X16]
  
   --
   Regards,
  
   Laurent Pinchart
 
  Thanks for your help. I've updated ispccdc.c to support the _1X16
  codes and the pipeline seems to work now. However, I needed to take
  out the memcpy in ccdc_try_format(), because otherwise pad 0 format
  was being copied to pad 1 or 2, regardless of what pad 1 or 2 were
  being set to. I'm not sure why it was done that way. I think it's
  better that the given code gets checked to see if it's in the list
and
  if so use it. Do you know of any valid reason why this copy is done?
 
 If I remember corretly, it's because there's nothing the CCDC may do
to the size
 of the image --- the driver doesn't either support cropping on the
CCDC. The sink
 format used to be always the same as the source format, the assumption
which
 no longer is valid when YUYV8_2X8 etc. formats are supported. This
must be
 taken into account, i.e. YUYV8_2X8 must be converted to YUYV8_1X16
instead of
 just copying the format as such.
 
 --
 Sakari Ailus
 e-mail: sakari.ai...@iki.fi   jabber/XMPP/Gmail: sai...@retiisi.org.uk

FYI ... here's the diff of the ISP CCDC changes I made to get the
sensor-ccdc-resizer pipeline to work.
Note: it's based on kernel 2.6.37.

--- drivers/media/video/isp/ispccdc.c
+++ drivers/media/video/isp/ispccdc.c 
@@ -53,6 +53,10 @@
V4L2_MBUS_FMT_SGBRG12_1X12,
V4L2_MBUS_FMT_UYVY8_2X8,
V4L2_MBUS_FMT_YUYV8_2X8,
+   V4L2_MBUS_FMT_UYVY8_1X16,
+   V4L2_MBUS_FMT_VYUY8_1X16,
+   V4L2_MBUS_FMT_YUYV8_1X16

Re: Help with omap3isp resizing

[Laurent Pinchart]

Hi Paul,

On Monday 03 October 2011 07:51:34 Paul Chiha wrote:
 Hi,
 
 I've been having trouble getting the resizer to work, and mainly because
 I don't know how to correctly configure it.
 I'm using kernel 2.6.37 on arm DM37x board.
 
 I've been able to configure the media links sensor=ccdc=ccdc_output
 (all with 640x480 V4L2_MBUS_FMT_UYVY8_2X8) and VIDIOC_STREAMON works on
 /dev/video2.
 But if I configure media links sensor=ccdc=resizer=resizer_output,
 then VIDIOC_STREAMON fails on /dev/video6 (with pixelformat mismatch).
 I noticed that the resizer driver only supports V4L2_MBUS_FMT_UYVY8_1X16
  V4L2_MBUS_FMT_YUYV8_1X16, so I tried again with all the links set to
 V4L2_MBUS_FMT_UYVY8_1X16 instead, but then ioctl VIDIOC_SUBDEV_S_FMT
 fails on /dev/v4l-subdev8, because the sensor driver doesn't support
 1X16.
 Then I tried using V4L2_MBUS_FMT_UYVY8_2X8 for the sensor and
 V4L2_MBUS_FMT_UYVY8_1X16 for the resizer, but it either failed with
 pixelformat mismatch or link pipeline mismatch, depending on which pads
 were different.
 
 Can someone please tell me what I need to do to make this work?

Long story short, I don't think that pipeline has ever been tested. I'm 
unfortunately lacking hardware to work on that, as none of my OMAP3 hardware 
has a YUV input.

-- 
Regards,

Laurent Pinchart
--
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: Help with omap3isp resizing

[Laurent Pinchart]

Hi Ivan,

On Tuesday 04 October 2011 13:46:32 Ivan T. Ivanov wrote:
 On Tue, 2011-10-04 at 13:03 +0200, Laurent Pinchart wrote:
  On Monday 03 October 2011 07:51:34 Paul Chiha wrote:
   Hi,
   
   I've been having trouble getting the resizer to work, and mainly
   because I don't know how to correctly configure it.
   I'm using kernel 2.6.37 on arm DM37x board.
   
   I've been able to configure the media links sensor=ccdc=ccdc_output
   (all with 640x480 V4L2_MBUS_FMT_UYVY8_2X8) and VIDIOC_STREAMON works on
   /dev/video2.
   But if I configure media links sensor=ccdc=resizer=resizer_output,
   then VIDIOC_STREAMON fails on /dev/video6 (with pixelformat mismatch).
   I noticed that the resizer driver only supports
   V4L2_MBUS_FMT_UYVY8_1X16  V4L2_MBUS_FMT_YUYV8_1X16, so I tried again
   with all the links set to V4L2_MBUS_FMT_UYVY8_1X16 instead, but then
   ioctl VIDIOC_SUBDEV_S_FMT fails on /dev/v4l-subdev8, because the
   sensor driver doesn't support 1X16.
   Then I tried using V4L2_MBUS_FMT_UYVY8_2X8 for the sensor and
   V4L2_MBUS_FMT_UYVY8_1X16 for the resizer, but it either failed with
   pixelformat mismatch or link pipeline mismatch, depending on which pads
   were different.
   
   Can someone please tell me what I need to do to make this work?
  
  Long story short, I don't think that pipeline has ever been tested. I'm
  unfortunately lacking hardware to work on that, as none of my OMAP3
  hardware has a YUV input.
 
 If i am not mistaken currently resizer sub device supports only:
 
 /* resizer pixel formats */
 static const unsigned int resizer_formats[] = {
   V4L2_MBUS_FMT_UYVY8_1X16,
   V4L2_MBUS_FMT_YUYV8_1X16,
 };
 
 Adding something like this [1] in ispresizer.c  should add
 support 2X8 formats. Completely untested :-).
 
 Regards,
 iivanov
 
 
 [1]
 
 @@ -1307,6 +1311,10 @@ static int resizer_s_crop(struct v4l2_subdev *sd,
 struct v4l2_subdev_fh *fh, static const unsigned int resizer_formats[] = {
   V4L2_MBUS_FMT_UYVY8_1X16,
   V4L2_MBUS_FMT_YUYV8_1X16,
 + V4L2_MBUS_FMT_UYVY8_2X8,
 + V4L2_MBUS_FMT_VYUY8_2X8,
 + V4L2_MBUS_FMT_YUYV8_2X8,
 + V4L2_MBUS_FMT_YVYU8_2X8,
  };

I'd rather modify ispccdc.c to output V4L2_MBUS_FMT_YUYV8_1X16. What do you 
think ?

  static unsigned int resizer_max_in_width(struct isp_res_device *res)
 @@ -1340,12 +1348,21 @@ static void resizer_try_format(struct
 isp_res_device *res, struct resizer_ratio ratio;
   struct v4l2_rect crop;
 
 + switch (fmt-code) {
 +
 + case V4L2_MBUS_FMT_YUYV8_1X16:
 + case V4L2_MBUS_FMT_UYVY8_1X16:
 + case V4L2_MBUS_FMT_UYVY8_2X8:
 + case V4L2_MBUS_FMT_VYUY8_2X8:
 + case V4L2_MBUS_FMT_YUYV8_2X8:
 + case V4L2_MBUS_FMT_YVYU8_2X8:
 + break;
 + default:
 + fmt-code = V4L2_MBUS_FMT_YUYV8_1X16;
 + }
 +
   switch (pad) {
   case RESZ_PAD_SINK:
 - if (fmt-code != V4L2_MBUS_FMT_YUYV8_1X16 
 - fmt-code != V4L2_MBUS_FMT_UYVY8_1X16)
 - fmt-code = V4L2_MBUS_FMT_YUYV8_1X16;
 -
   fmt-width = clamp_t(u32, fmt-width, MIN_IN_WIDTH,
resizer_max_in_width(res));
   fmt-height = clamp_t(u32, fmt-height, MIN_IN_HEIGHT,

-- 
Regards,

Laurent Pinchart
--
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: Help with omap3isp resizing

[Laurent Pinchart]

Hi Ivan,

On Tuesday 04 October 2011 13:54:12 Ivan T. Ivanov wrote:
 On Tue, 2011-10-04 at 13:50 +0200, Laurent Pinchart wrote:
  On Tuesday 04 October 2011 13:46:32 Ivan T. Ivanov wrote:
   On Tue, 2011-10-04 at 13:03 +0200, Laurent Pinchart wrote:
On Monday 03 October 2011 07:51:34 Paul Chiha wrote:
 Hi,
 
 I've been having trouble getting the resizer to work, and mainly
 because I don't know how to correctly configure it.
 I'm using kernel 2.6.37 on arm DM37x board.
 
 I've been able to configure the media links
 sensor=ccdc=ccdc_output (all with 640x480
 V4L2_MBUS_FMT_UYVY8_2X8) and VIDIOC_STREAMON works on /dev/video2.
 But if I configure media links
 sensor=ccdc=resizer=resizer_output, then VIDIOC_STREAMON fails
 on /dev/video6 (with pixelformat mismatch). I noticed that the
 resizer driver only supports
 V4L2_MBUS_FMT_UYVY8_1X16  V4L2_MBUS_FMT_YUYV8_1X16, so I tried
 again with all the links set to V4L2_MBUS_FMT_UYVY8_1X16 instead,
 but then ioctl VIDIOC_SUBDEV_S_FMT fails on /dev/v4l-subdev8,
 because the sensor driver doesn't support 1X16.
 Then I tried using V4L2_MBUS_FMT_UYVY8_2X8 for the sensor and
 V4L2_MBUS_FMT_UYVY8_1X16 for the resizer, but it either failed with
 pixelformat mismatch or link pipeline mismatch, depending on which
 pads were different.
 
 Can someone please tell me what I need to do to make this work?

Long story short, I don't think that pipeline has ever been tested.
I'm unfortunately lacking hardware to work on that, as none of my
OMAP3 hardware has a YUV input.
   
   If i am not mistaken currently resizer sub device supports only:
   
   /* resizer pixel formats */
   static const unsigned int resizer_formats[] = {
   
 V4L2_MBUS_FMT_UYVY8_1X16,
 V4L2_MBUS_FMT_YUYV8_1X16,
   
   };
   
   Adding something like this [1] in ispresizer.c  should add
   support 2X8 formats. Completely untested :-).
   
   Regards,
   iivanov
   
   
   [1]
   
   @@ -1307,6 +1311,10 @@ static int resizer_s_crop(struct v4l2_subdev
   *sd, struct v4l2_subdev_fh *fh, static const unsigned int
   resizer_formats[] = {
   
 V4L2_MBUS_FMT_UYVY8_1X16,
 V4L2_MBUS_FMT_YUYV8_1X16,
   
   + V4L2_MBUS_FMT_UYVY8_2X8,
   + V4L2_MBUS_FMT_VYUY8_2X8,
   + V4L2_MBUS_FMT_YUYV8_2X8,
   + V4L2_MBUS_FMT_YVYU8_2X8,
   
};
  
  I'd rather modify ispccdc.c to output V4L2_MBUS_FMT_YUYV8_1X16. What do
  you think ?
 
 For memory-Resizer-memory use cases, CCDC is no involved in pipeline.

But the original poster wants to use the sensor - ccdc - resizer - resizer 
output pipeline.

 Also several sensor drivers that i have checked, usually define its
 output as 2X8 output. I think is more natural to add 2X8 support to
 CCDC and Resizer engines instead to modifying exiting drivers.

Sure, sensor drivers should not be modified. What I was talking about was to 
configure the pipeline as

sensor:0 [YUYV8_2X8], CCDC:0 [YUYV8_2X8], CCDC:1 [YUYV8_1X16], resizer:0 
[YUYV8_1X16]

-- 
Regards,

Laurent Pinchart
--
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: Help with omap3isp resizing

[Ivan T. Ivanov]

Hi Laurent, 

On Tue, 2011-10-04 at 15:00 +0200, Laurent Pinchart wrote:
 Hi Ivan,
 
 On Tuesday 04 October 2011 13:54:12 Ivan T. Ivanov wrote:
  On Tue, 2011-10-04 at 13:50 +0200, Laurent Pinchart wrote:
   On Tuesday 04 October 2011 13:46:32 Ivan T. Ivanov wrote:
On Tue, 2011-10-04 at 13:03 +0200, Laurent Pinchart wrote:
 On Monday 03 October 2011 07:51:34 Paul Chiha wrote:
  Hi,
  
  I've been having trouble getting the resizer to work, and mainly
  because I don't know how to correctly configure it.
  I'm using kernel 2.6.37 on arm DM37x board.
  
  I've been able to configure the media links
  sensor=ccdc=ccdc_output (all with 640x480
  V4L2_MBUS_FMT_UYVY8_2X8) and VIDIOC_STREAMON works on /dev/video2.
  But if I configure media links
  sensor=ccdc=resizer=resizer_output, then VIDIOC_STREAMON fails
  on /dev/video6 (with pixelformat mismatch). I noticed that the
  resizer driver only supports
  V4L2_MBUS_FMT_UYVY8_1X16  V4L2_MBUS_FMT_YUYV8_1X16, so I tried
  again with all the links set to V4L2_MBUS_FMT_UYVY8_1X16 instead,
  but then ioctl VIDIOC_SUBDEV_S_FMT fails on /dev/v4l-subdev8,
  because the sensor driver doesn't support 1X16.
  Then I tried using V4L2_MBUS_FMT_UYVY8_2X8 for the sensor and
  V4L2_MBUS_FMT_UYVY8_1X16 for the resizer, but it either failed with
  pixelformat mismatch or link pipeline mismatch, depending on which
  pads were different.
  
  Can someone please tell me what I need to do to make this work?
 
 Long story short, I don't think that pipeline has ever been tested.
 I'm unfortunately lacking hardware to work on that, as none of my
 OMAP3 hardware has a YUV input.

If i am not mistaken currently resizer sub device supports only:

/* resizer pixel formats */
static const unsigned int resizer_formats[] = {

V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,

};

Adding something like this [1] in ispresizer.c  should add
support 2X8 formats. Completely untested :-).

Regards,
iivanov


[1]

@@ -1307,6 +1311,10 @@ static int resizer_s_crop(struct v4l2_subdev
*sd, struct v4l2_subdev_fh *fh, static const unsigned int
resizer_formats[] = {

V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,

+   V4L2_MBUS_FMT_UYVY8_2X8,
+   V4L2_MBUS_FMT_VYUY8_2X8,
+   V4L2_MBUS_FMT_YUYV8_2X8,
+   V4L2_MBUS_FMT_YVYU8_2X8,

 };
   
   I'd rather modify ispccdc.c to output V4L2_MBUS_FMT_YUYV8_1X16. What do
   you think ?
  
  For memory-Resizer-memory use cases, CCDC is no involved in pipeline.
 
 But the original poster wants to use the sensor - ccdc - resizer - resizer 
 output pipeline.

Ah, right, i have miss that,

 
  Also several sensor drivers that i have checked, usually define its
  output as 2X8 output. I think is more natural to add 2X8 support to
  CCDC and Resizer engines instead to modifying exiting drivers.
 
 Sure, sensor drivers should not be modified. What I was talking about was to 
 configure the pipeline as
 
 sensor:0 [YUYV8_2X8], CCDC:0 [YUYV8_2X8], CCDC:1 [YUYV8_1X16], resizer:0 
 [YUYV8_1X16]
 

This sound simpler and reasonable. In this case maybe for every
reference to V4L2_MBUS_FMT_8_2X8 in ispccdc.c,  additional
V4L2_MBUS_FMT_xxx8_1X16 can be added.

Regards, 
iivanov


--
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: Help with omap3isp resizing

[Sakari Ailus]

On Tue, Oct 04, 2011 at 03:00:55PM +0200, Laurent Pinchart wrote:
 Hi Ivan,

Hi all,

 On Tuesday 04 October 2011 13:54:12 Ivan T. Ivanov wrote:
  On Tue, 2011-10-04 at 13:50 +0200, Laurent Pinchart wrote:
   On Tuesday 04 October 2011 13:46:32 Ivan T. Ivanov wrote:
On Tue, 2011-10-04 at 13:03 +0200, Laurent Pinchart wrote:
 On Monday 03 October 2011 07:51:34 Paul Chiha wrote:
  Hi,
  
  I've been having trouble getting the resizer to work, and mainly
  because I don't know how to correctly configure it.
  I'm using kernel 2.6.37 on arm DM37x board.
  
  I've been able to configure the media links
  sensor=ccdc=ccdc_output (all with 640x480
  V4L2_MBUS_FMT_UYVY8_2X8) and VIDIOC_STREAMON works on /dev/video2.
  But if I configure media links
  sensor=ccdc=resizer=resizer_output, then VIDIOC_STREAMON fails
  on /dev/video6 (with pixelformat mismatch). I noticed that the
  resizer driver only supports
  V4L2_MBUS_FMT_UYVY8_1X16  V4L2_MBUS_FMT_YUYV8_1X16, so I tried
  again with all the links set to V4L2_MBUS_FMT_UYVY8_1X16 instead,
  but then ioctl VIDIOC_SUBDEV_S_FMT fails on /dev/v4l-subdev8,
  because the sensor driver doesn't support 1X16.
  Then I tried using V4L2_MBUS_FMT_UYVY8_2X8 for the sensor and
  V4L2_MBUS_FMT_UYVY8_1X16 for the resizer, but it either failed with
  pixelformat mismatch or link pipeline mismatch, depending on which
  pads were different.
  
  Can someone please tell me what I need to do to make this work?
 
 Long story short, I don't think that pipeline has ever been tested.
 I'm unfortunately lacking hardware to work on that, as none of my
 OMAP3 hardware has a YUV input.

If i am not mistaken currently resizer sub device supports only:

/* resizer pixel formats */
static const unsigned int resizer_formats[] = {

V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,

};

Adding something like this [1] in ispresizer.c  should add
support 2X8 formats. Completely untested :-).

Regards,
iivanov


[1]

@@ -1307,6 +1311,10 @@ static int resizer_s_crop(struct v4l2_subdev
*sd, struct v4l2_subdev_fh *fh, static const unsigned int
resizer_formats[] = {

V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,

+   V4L2_MBUS_FMT_UYVY8_2X8,
+   V4L2_MBUS_FMT_VYUY8_2X8,
+   V4L2_MBUS_FMT_YUYV8_2X8,
+   V4L2_MBUS_FMT_YVYU8_2X8,

 };
   
   I'd rather modify ispccdc.c to output V4L2_MBUS_FMT_YUYV8_1X16. What do
   you think ?
  
  For memory-Resizer-memory use cases, CCDC is no involved in pipeline.
 
 But the original poster wants to use the sensor - ccdc - resizer - resizer 
 output pipeline.
 
  Also several sensor drivers that i have checked, usually define its
  output as 2X8 output. I think is more natural to add 2X8 support to
  CCDC and Resizer engines instead to modifying exiting drivers.
 
 Sure, sensor drivers should not be modified. What I was talking about was to 
 configure the pipeline as
 
 sensor:0 [YUYV8_2X8], CCDC:0 [YUYV8_2X8], CCDC:1 [YUYV8_1X16], resizer:0 
 [YUYV8_1X16]

Looks good to me. This also does reflect the real bus formats in the device
quite well; the links from ccdc onwards only use one clock cycle for sample.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
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: Help with omap3isp resizing

[Paul Chiha]

On Tue, Oct 04, 2011 at 03:00:55PM +0200, Laurent Pinchart wrote:
 Hi Ivan,
 
 On Tuesday 04 October 2011 13:54:12 Ivan T. Ivanov wrote:
  On Tue, 2011-10-04 at 13:50 +0200, Laurent Pinchart wrote:
   On Tuesday 04 October 2011 13:46:32 Ivan T. Ivanov wrote:
On Tue, 2011-10-04 at 13:03 +0200, Laurent Pinchart wrote:
 On Monday 03 October 2011 07:51:34 Paul Chiha wrote:
  Hi,
 
  I've been having trouble getting the resizer to work, and
  mainly because I don't know how to correctly configure it.
  I'm using kernel 2.6.37 on arm DM37x board.
 
  I've been able to configure the media links
  sensor=ccdc=ccdc_output (all with 640x480
  V4L2_MBUS_FMT_UYVY8_2X8) and VIDIOC_STREAMON works on
 /dev/video2.
  But if I configure media links
  sensor=ccdc=resizer=resizer_output, then VIDIOC_STREAMON
  fails on /dev/video6 (with pixelformat mismatch). I noticed
  that the resizer driver only supports
  V4L2_MBUS_FMT_UYVY8_1X16  V4L2_MBUS_FMT_YUYV8_1X16, so I
  tried again with all the links set to V4L2_MBUS_FMT_UYVY8_1X16
  instead, but then ioctl VIDIOC_SUBDEV_S_FMT fails on
  /dev/v4l-subdev8, because the sensor driver doesn't support 1X16.
  Then I tried using V4L2_MBUS_FMT_UYVY8_2X8 for the sensor and
  V4L2_MBUS_FMT_UYVY8_1X16 for the resizer, but it either failed
  with pixelformat mismatch or link pipeline mismatch, depending
  on which pads were different.
 
  Can someone please tell me what I need to do to make this work?

 Long story short, I don't think that pipeline has ever been tested.
 I'm unfortunately lacking hardware to work on that, as none of
 my
 OMAP3 hardware has a YUV input.
   
If i am not mistaken currently resizer sub device supports only:
   
/* resizer pixel formats */
static const unsigned int resizer_formats[] = {
   
V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,
   
};
   
Adding something like this [1] in ispresizer.c  should add support
2X8 formats. Completely untested :-).
   
Regards,
iivanov
   
   
[1]
   
@@ -1307,6 +1311,10 @@ static int resizer_s_crop(struct
v4l2_subdev *sd, struct v4l2_subdev_fh *fh, static const unsigned
int resizer_formats[] = {
   
V4L2_MBUS_FMT_UYVY8_1X16,
V4L2_MBUS_FMT_YUYV8_1X16,
   
+   V4L2_MBUS_FMT_UYVY8_2X8,
+   V4L2_MBUS_FMT_VYUY8_2X8,
+   V4L2_MBUS_FMT_YUYV8_2X8,
+   V4L2_MBUS_FMT_YVYU8_2X8,
   
 };
  
   I'd rather modify ispccdc.c to output V4L2_MBUS_FMT_YUYV8_1X16. What
   do you think ?
 
  For memory-Resizer-memory use cases, CCDC is no involved in pipeline.
 
 But the original poster wants to use the sensor - ccdc - resizer - resizer 
 output
 pipeline.
 
  Also several sensor drivers that i have checked, usually define its
  output as 2X8 output. I think is more natural to add 2X8 support to
  CCDC and Resizer engines instead to modifying exiting drivers.
 
 Sure, sensor drivers should not be modified. What I was talking about was to
 configure the pipeline as
 
 sensor:0 [YUYV8_2X8], CCDC:0 [YUYV8_2X8], CCDC:1 [YUYV8_1X16], resizer:0
 [YUYV8_1X16]
 
 --
 Regards,
 
 Laurent Pinchart

Thanks for your help.
I've updated ispccdc.c to support the _1X16 codes and the pipeline seems to 
work now.
However, I needed to take out the memcpy in ccdc_try_format(), because 
otherwise pad 0 format was being copied to pad 1 or 2, regardless of what pad 1 
or 2 were being set to.
I'm not sure why it was done that way.  I think it's better that the given code 
gets checked to see if it's in the list and if so use it.  Do you know of any 
valid reason why this copy is done?

Paul
N�r��yb�X��ǧv�^�)޺{.n�+{���bj)w*jg����ݢj/���z�ޖ��2�ޙ�)ߡ�a�����G���h��j:+v���w��٥

Help with omap3isp resizing

[Paul Chiha]

Hi,

I've been having trouble getting the resizer to work, and mainly because
I don't know how to correctly configure it.
I'm using kernel 2.6.37 on arm DM37x board.

I've been able to configure the media links sensor=ccdc=ccdc_output
(all with 640x480 V4L2_MBUS_FMT_UYVY8_2X8) and VIDIOC_STREAMON works on
/dev/video2.
But if I configure media links sensor=ccdc=resizer=resizer_output,
then VIDIOC_STREAMON fails on /dev/video6 (with pixelformat mismatch).
I noticed that the resizer driver only supports V4L2_MBUS_FMT_UYVY8_1X16
 V4L2_MBUS_FMT_YUYV8_1X16, so I tried again with all the links set to
V4L2_MBUS_FMT_UYVY8_1X16 instead, but then ioctl VIDIOC_SUBDEV_S_FMT
fails on /dev/v4l-subdev8, because the sensor driver doesn't support
1X16.
Then I tried using V4L2_MBUS_FMT_UYVY8_2X8 for the sensor and
V4L2_MBUS_FMT_UYVY8_1X16 for the resizer, but it either failed with
pixelformat mismatch or link pipeline mismatch, depending on which pads
were different.

Can someone please tell me what I need to do to make this work?

Thanks,
Paul


--
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: Help getting TechniSat SkyStar HD2 working in Ubuntu 10.10

[Lou]

Hello John,

 I'm having problems with this card- I can get it to scan DVB-S and
 DVB-S2 using scan-s2, and can get it to tune to DVB-S channels, but I
 cannot szap to DVB-S2 channels
 
 szap2 -p -t 2 BBC HD reports error ioctl DVBFE_SET_DELSYS failed:
 Operation not supported
 
 I have tried the latest s2-liplianin and v4l-dvb mantis drivers but no joy
 
 Can anyone help?

szap2 needs a list of channels in zap or vdr format to tune correctly,
so try this:

szap2 -c your-szap-s2-channel-list-including-BBC HD BBC HD

gathering the list using scan-s2 should work like this:

scan-s2 -s [DISEQC OUT] -t 3 -o zap -n -I 50 /usr/local/share/dvb/dvb-
s/Astra-28.2E  astra.conf

note: Astra-28.2E is the transponder file, where astra.conf will be the 
resulting list of channels.

Since you are using a mantis bridge card, consider the patch of Lutz Sammer to 
fix the tuning algo of your card [1]

And there's brand new remote support for your card in v4l-dvb, if you apply 
the patch of Christoph Pinkl [2]

[1] https://patchwork.kernel.org/patch/753382/
[2] http://www.spinics.net/lists/linux-media/msg33632.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

Help getting TechniSat SkyStar HD2 working in Ubuntu 10.10

[John Taylor]

I'm having problems with this card- I can get it to scan DVB-S and
DVB-S2 using scan-s2, and can get it to tune to DVB-S channels, but I
cannot szap to DVB-S2 channels

szap2 -p -t 2 BBC HD reports error ioctl DVBFE_SET_DELSYS failed:
Operation not supported

I have tried the latest s2-liplianin and v4l-dvb mantis drivers but no joy

Can anyone help?

John

output lspci -vv
01:08.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV
PCI Bridge Controller [Ver 1.0] (rev 01)
Subsystem: Device 1ae4:0003
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort+ MAbort- SERR- PERR- INTx-
Latency: 32 (2000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 18
Region 0: Memory at f5fff000 (32-bit, prefetchable) [size=4K]
Kernel driver in use: Mantis
 lspci -vvn
01:08.0 0480: 1822:4e35 (rev 01)
Subsystem: 1ae4:0003
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort+ MAbort- SERR- PERR- INTx-
Latency: 32 (2000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 18
Region 0: Memory at f5fff000 (32-bit, prefetchable) [size=4K]
Kernel driver in use: Mantis

dmesg:
[  161.580721] Mantis :01:08.0: PCI INT A - Link[LNKA] - GSI 18
(level, low) - IRQ 18
[  161.582113] DVB: registering new adapter (Mantis DVB adapter)
[  162.471365] stb0899_attach: Attaching STB0899
[  162.471375] stb6100_attach: Attaching STB6100
[  162.471593] LNBx2x attached on addr=8
[  162.471601] DVB: registering adapter 1 frontend 0 (STB0899 Multistandard)...
--
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

DVB_NET help message is useless

[Jiri Slaby]

Hi,

I've just updated to 3.0-rc and saw CONFIG_DVB_NET. Hmm, let's see
what's that by asking with '?'. And I got this crap:

CONFIG_DVB_NET:

The DVB network support in the DVB core can
optionally be disabled if this
option is set to N.

If unsure say Y.

Why do you think this help message is useful? It's clear to
everybody that if one eventually disables it it will be disabled. The
help message should mention _what_ the network support is.

I would send a patch, but I really have no idea what's that good for.

thanks,
-- 
js
--
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: DVB_NET help message is useless

[Hans Petter Selasky]

On Thursday 16 June 2011 09:06:59 Jiri Slaby wrote:
 I would send a patch, but I really have no idea what's that good for.

DVB network support is referring to the IP stack. This option is set to N 
when compiling the Linux DVB stack on systems without IP networking.

Please submit a patch if you need a better description.

--HPS
--
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: DVB_NET help message is useless

[Mauro Carvalho Chehab]

Em 16-06-2011 04:06, Jiri Slaby escreveu:
 Hi,
 
 I've just updated to 3.0-rc and saw CONFIG_DVB_NET. Hmm, let's see
 what's that by asking with '?'. And I got this crap:
 
 CONFIG_DVB_NET:
 
 The DVB network support in the DVB core can
 optionally be disabled if this
 option is set to N.
 
 If unsure say Y.
 
 Why do you think this help message is useful? It's clear to
 everybody that if one eventually disables it it will be disabled. The
 help message should mention _what_ the network support is.
 
 I would send a patch, but I really have no idea what's that good for.

As Hans answered this option disables the IP stack from the DVB driver. The
IP stack is part of the DVB standard. It is used, for example, by automatic 
firmware updates used on STB's. It can also be used to access the Internet,
via the DVB card, if the network provider supports it.

Before 3.0, this were enabled on all cards. However, if the IP stack is
disabled, this would mean that the entire DVB would also be disabled.
So, this option were added. It may make sense to make it dependent of
CONFIG_EMBEDDED, as normal users should not need to disable it.

Feel free to send us a patch if you want to improve the Kconfig logic or
help message.

Thanks,
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: [linux-dvb] Terratec Cinergy C HD - CAM support.... Need help?

[Willem van Asperen]

On Saturday 28 May 2011 10:33:16 Bjørn Mork wrote:
 Marc Coevoet ma...@dommel.be writes:
  Op 27-05-11 21:48, Willem van Asperen schreef:
  a) CAM support is currently not implemented for terratec HD
 
  For all cards?
 
 The CA code in the mantis driver isn't actually hooked into the driver
 anywhere, so that't correct: No CAM will currently work with the
 Terratec Cinergy C HD.
 
 Exported, but never called:
 
  bjorn@canardo:/usr/local/src/git/linux-2.6/drivers/media/dvb/mantis$ grep
  mantis_ca_init *.c mantis_ca.c:int mantis_ca_init(struct mantis_pci
  *mantis)
  mantis_ca.c:EXPORT_SYMBOL_GPL(mantis_ca_init);

Actually, doing this on s2-liplianin-41388e396e0f (the one I downloaded today) 
gets:
$ grep mantis_ca_init *.c

mantis_ca.c:int mantis_ca_init(struct mantis_pci *mantis)
mantis_dvb.c:   mantis_ca_init(mantis);

And in the function __devinit mantis_dvb_init(struct mantis_pci *mantis) it 
actually says:

...
dvb_net_init(mantis-dvb_adapter, mantis-dvbnet, mantis-demux.dmx);
tasklet_init(mantis-tasklet, mantis_dma_xfer, (unsigned long) mantis);
mantis_frontend_init(mantis);
mantis_ca_init(mantis);

return 0;
...

So it seems that this mantis_ca_init call is actually made nowadays.

I'll do some more digging -- check the /var/log/messages file for output of the 
mantis initialization -- and report back.

Willem
--
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] Terratec Cinergy C HD - CAM support.... Need help?

[Bjørn Mork]

Willem van Asperen wil...@ereprijs.demon.nl writes:

 Actually, doing this on s2-liplianin-41388e396e0f (the one I downloaded 
 today) 
 gets:
 $ grep mantis_ca_init *.c

 mantis_ca.c:int mantis_ca_init(struct mantis_pci *mantis)
 mantis_dvb.c:   mantis_ca_init(mantis);

 And in the function __devinit mantis_dvb_init(struct mantis_pci *mantis) it 
 actually says:

 ...
   dvb_net_init(mantis-dvb_adapter, mantis-dvbnet, mantis-demux.dmx);
   tasklet_init(mantis-tasklet, mantis_dma_xfer, (unsigned long) mantis);
   mantis_frontend_init(mantis);
   mantis_ca_init(mantis);

   return 0;
 ...

 So it seems that this mantis_ca_init call is actually made nowadays.

In the s2-liplianin yes.  Not in mainline.  Investigating the
differences might be useful.


Bjørn

--
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] Terratec Cinergy C HD - CAM support.... Need help?

[Willem van Asperen]

On Sunday 29 May 2011 14:11:23 Bjørn Mork wrote:
 Willem van Asperen wil...@ereprijs.demon.nl writes:
  Actually, doing this on s2-liplianin-41388e396e0f (the one I downloaded
  today) gets:
  $ grep mantis_ca_init *.c
 
  mantis_ca.c:int mantis_ca_init(struct mantis_pci *mantis)
  mantis_dvb.c:   mantis_ca_init(mantis);
 
  And in the function __devinit mantis_dvb_init(struct mantis_pci *mantis)
  it actually says:
 
  ...
  dvb_net_init(mantis-dvb_adapter, mantis-dvbnet, mantis-demux.dmx);
  tasklet_init(mantis-tasklet, mantis_dma_xfer, (unsigned long) mantis);
  mantis_frontend_init(mantis);
  mantis_ca_init(mantis);
 
  return 0;
  ...
 
  So it seems that this mantis_ca_init call is actually made nowadays.
 
 In the s2-liplianin yes.  Not in mainline.  Investigating the
 differences might be useful.

Indeed.

% modprobe -r mantis
% modprobe mantis

gives:
May 29 14:37:51 mythbox kernel: Mantis :03:02.0: PCI INT A - GSI 17 
(level, low) - IRQ 17
May 29 14:37:51 mythbox kernel: DVB: registering new adapter (Mantis DVB 
adapter)
May 29 14:37:52 mythbox kernel: DVB: registering adapter 0 frontend 0 (Philips 
TDA10023 DVB-C)...


Nothing about CA

--
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] Terratec Cinergy C HD - CAM support.... Need help?

[Bjørn Mork]

Marc Coevoet ma...@dommel.be writes:
 Op 27-05-11 21:48, Willem van Asperen schreef:

 a) CAM support is currently not implemented for terratec HD

 For all cards?

The CA code in the mantis driver isn't actually hooked into the driver
anywhere, so that't correct: No CAM will currently work with the
Terratec Cinergy C HD.

Exported, but never called:

 bjorn@canardo:/usr/local/src/git/linux-2.6/drivers/media/dvb/mantis$ grep 
mantis_ca_init *.c
 mantis_ca.c:int mantis_ca_init(struct mantis_pci *mantis)
 mantis_ca.c:EXPORT_SYMBOL_GPL(mantis_ca_init);


I don't know why, but I assume it's the same as with the remote control
code that was recently fixed Christoph Pinkl: The code probably wasn't
considered production ready when the driver was merged, and was therefore
temporarily disabled until it could be fixed.


Bjørn

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