date:20091203

Andy Walls wrote:
 On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote:
 On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:

 Dmitry Torokhov wrote:
 ...
 (for each remote/substream that they can recognize).
 I'm assuming that, by remote, you're referring to a remote receiver (and 
 not to 
 the remote itself), right?
 If we could separate by remote transmitter that would be the best I
 think, but I understand that it is rarely possible?
 IMHO, the better is to use a separate interface for the IR transmitters,
 on the devices that support this feature. There are only a few devices
 I'm aware of that are able to transmit IR codes.
 If I'm thinking clearly, there are only three lirc kernel drivers that
 support transmit, lirc_mceusb, lirc_zilog and lirc_serial. The mceusb
 driver was posted, so I won't rehash what it is here. The zilog driver
 binds to a Zilog z80 microprocessor thingy (iirc) exposed via i2c,
 found on many Hauppauge v4l/dvb devices (PVR-150, HVR-1600, HD-PVR,
 etc). The serial driver is fairly self-explanatory as well.

 There are also a few userspace-driven devices that do transmit, but
 I'm assuming they're (currently) irrelevant to this discussion.
 
 
 I've got the CX23888 integrated IR Rx done and Tx nearly done.  I was
 waiting to see how kfifo and lirc_dev panned out before making the
 interface to userspace.
 
 The CX23885, CX23418, and CX2584x integrated IR is essentially the same.
 I hope to have CX23885 IR done by Christmas.
 
 Both of those IR devices are/will be encapsulated in a v4l2_subdevice
 object internally.  I was going to write lirc_v4l glue between the
 v4l2_device/v4l2_subdev_ir_ops and lirc_dev.
 
 As for the the I2C chips, I was going to go back and encapsulate those
 in the v4l2_subdevice object as well, so then my notional lirc_v4l could
 pick those up too.  The I2C subsystem only allows one binding to an I2C
 client address/name on a bus.  So without some new glue like a notional
 lirc_v4l, it *may* be hard to share between ir-kbd-i2c and lirc_i2c and
 lirc_zilog.

Maybe you're having a bad time because you may be trying to integrate lirc
at the wrong place.

All devices at V4L tree including ir-kbd-i2c use ir-common.ko 
(at /drivers/media/common tree) module to communicate to IR's. 
I'm preparing some patches to extend this also to dvb-usb devices 
(that uses a close enough infrastructure). 

Also, most of the decoding code are there, in a form of helper routines.

As the idea is to provide lirc interface to all devices that can work with
raw pulse/space, the proper place is to write a subroutine there that, once
called, will make those pulse/space raw codes available to lirc and will
call the needed decoders to export them also to evdev.

The code at ir-common module was originally built to be used by V4L, but I'm
porting the code there to be generic enough to be a library that can be used
by other drivers. So, lirc_zilog and other lirc devices that will need to open
evdev interfaces after running a decoder can use them.

Due to that, we shouldn't add v4l2_subdevice there. Nothing prevents to create
a v4l2-ir-subdev glue if you want to see the IR's as subdevices, but this should
be implemented as a separate module.

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

cx2388x driver appears broken

2009-12-03 Thread Shaun Amy

Hi,

I have successfully been running Ubuntu 9.10 on an old Pentium4
test-box.  The machine has two PCI cards, both of which worked with
stock 9.10 and with a slightly upgraded kernel (2.6.31-14-generic-pae
and 2.6.31-15-generic-pae).  These cards, have, in the past also
worked on Ubuntu 6.10 so have been supported for a long time.  The
output on the 2.6.31-15-generic-pae gives:

[6.173285] cx88/0: cx2388x v4l2 driver version 0.0.7 loaded
[6.173349] cx8800 :02:0b.0: PCI INT A - GSI 23 (level, low) - IRQ 23
[6.174531] cx88[0]: subsystem: 18ac:db10, board: DViCO FusionHDTV
DVB-T Plus [card=21,insmod option], frontend(s): 1
[6.174537] cx88[0]: TV tuner type 4, Radio tuner type -1
[6.183548] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded
[6.340041] cx88[0]/0: found at :02:0b.0, rev: 5, irq: 23,
latency: 32, mmio: 0xef00
[6.340065] IRQ 23/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs
[6.340191] cx88[0]/0: registered device video0 [v4l2]
[6.340237] cx88[0]/0: registered device vbi0
[6.340313] cx88[0]/2: cx2388x 8802 Driver Manager
[6.340335] cx88-mpeg driver manager :02:0b.2: PCI INT A - GSI
23 (level, low) - IRQ 23
[6.340349] cx88[0]/2: found at :02:0b.2, rev: 5, irq: 23,
latency: 32, mmio: 0xee00
[6.340358] IRQ 23/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs
[6.340395] cx8800 :02:0c.0: PCI INT A - GSI 20 (level, low) - IRQ 20
[6.341628] cx88[1]: subsystem: 17de:a8a6, board: Conexant DVB-T
reference design [card=19,insmod option], frontend(s): 1
[6.341635] cx88[1]: TV tuner type 4, Radio tuner type -1
[6.504094] cx88[1]/0: found at :02:0c.0, rev: 5, irq: 20,
latency: 32, mmio: 0xed00
[6.504166] IRQ 20/cx88[1]: IRQF_DISABLED is not guaranteed on shared IRQs
[6.504294] cx88[1]/0: registered device video1 [v4l2]
[6.504342] cx88[1]/0: registered device vbi1
[6.506583] cx88[1]/2: cx2388x 8802 Driver Manager
[6.506609] cx88-mpeg driver manager :02:0c.2: PCI INT A - GSI
20 (level, low) - IRQ 20
[6.506625] cx88[1]/2: found at :02:0c.2, rev: 5, irq: 20,
latency: 32, mmio: 0xec00
[6.506638] IRQ 20/cx88[1]: IRQF_DISABLED is not guaranteed on shared IRQs
[6.609088]   alloc irq_desc for 18 on node -1
[6.609095]   alloc kstat_irqs on node -1
[6.609108] C-Media PCI :02:0d.0: PCI INT A - GSI 18 (level,
low) - IRQ 18
[6.873923] EXT4-fs (sda11): internal journal on sda11:8
[7.011870] cx88/2: cx2388x dvb driver version 0.0.7 loaded
[7.011877] cx88/2: registering cx8802 driver, type: dvb access: shared
[7.011884] cx88[0]/2: subsystem: 18ac:db10, board: DViCO
FusionHDTV DVB-T Plus [card=21]
[7.011889] cx88[0]/2: cx2388x based DVB/ATSC card
[7.011893] cx8802_alloc_frontends() allocating 1 frontend(s)
[7.092877] ip_tables: (C) 2000-2006 Netfilter Core Team
[7.397447] DVB: registering new adapter (cx88[0])
[7.397457] DVB: registering adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)...
[7.398038] cx88[1]/2: subsystem: 17de:a8a6, board: Conexant DVB-T
reference design [card=19]
[7.398046] cx88[1]/2: cx2388x based DVB/ATSC card
[7.398050] cx8802_alloc_frontends() allocating 1 frontend(s)
[7.434445] DVB: registering new adapter (cx88[1])
[7.434456] DVB: registering adapter 1 frontend 0 (Conexant CX22702 DVB-T)...

In order to debug a problem with a new dual tuner USB module, I
grabbed the latest v4l-dvb and built all the modules from source (sans
FireTV) and installed them using the provided makefile targets.  This
results in the following:

[5.831860] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded
[5.833100] cx88[0]: subsystem: 18ac:db10, board: DViCO FusionHDTV
DVB-T Plus [card=21,insmod option], frontend(s): 1
[5.833107] cx88[0]: TV tuner type 4, Radio tuner type -1
[5.846548] cx88/0: cx2388x v4l2 driver version 0.0.7 loaded
[5.884782] EXT4-fs (sda11): internal journal on sda11:8
[6.012069] BUG: unable to handle kernel NULL pointer dereference at (null)
[6.012313] IP: [e0db9aa6] ir_input_free+0x16/0x40 [ir_common]
[6.012490] *pdpt = 1e550001 *pde = 
[6.012725] Oops:  [#1] SMP
[6.012957] last sysfs file: /sys/devices/virtual/dmi/id/sys_vendor
[6.013048] Modules linked in: snd_opl3_lib snd_timer x_tables
snd_hwdep cx8800(+) cx8802(+) snd_mpu401_uart cx88xx ir_common
i2c_algo_bit snd_rawmidi v4l2_common snd_seq_device tveeprom videodev
v4l1_compat videobuf_dma_sg btcx_risc snd videobuf_core soundcore
ppdev parport_pc shpchp lp intel_agp parport agpgart psmouse serio_raw
e100 mii natsemi floppy
[6.015697]
[6.015784] Pid: 534, comm: modprobe Not tainted
(2.6.31-15-generic-pae #50-Ubuntu) System Name
[6.015886] EIP: 0060:[e0db9aa6] EFLAGS: 00010246 CPU: 0
[6.015983] EIP is at ir_input_free+0x16/0x40 [ir_common]
[6.016013] EAX:  EBX:  ECX: ffed EDX: de08778c
[6.016013] ESI:

Re: [RFC v2] Another approach to IR

Andy Walls wrote:
 On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote:
 On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:

 Dmitry Torokhov wrote:
 ...
 (for each remote/substream that they can recognize).
 I'm assuming that, by remote, you're referring to a remote receiver (and 
 not to 
 the remote itself), right?
 If we could separate by remote transmitter that would be the best I
 think, but I understand that it is rarely possible?
 IMHO, the better is to use a separate interface for the IR transmitters,
 on the devices that support this feature. There are only a few devices
 I'm aware of that are able to transmit IR codes.
 If I'm thinking clearly, there are only three lirc kernel drivers that
 support transmit, lirc_mceusb, lirc_zilog and lirc_serial. The mceusb
 driver was posted, so I won't rehash what it is here. The zilog driver
 binds to a Zilog z80 microprocessor thingy (iirc) exposed via i2c,
 found on many Hauppauge v4l/dvb devices (PVR-150, HVR-1600, HD-PVR,
 etc). The serial driver is fairly self-explanatory as well.

 There are also a few userspace-driven devices that do transmit, but
 I'm assuming they're (currently) irrelevant to this discussion.
 
 
 I've got the CX23888 integrated IR Rx done and Tx nearly done.  I was
 waiting to see how kfifo and lirc_dev panned out before making the
 interface to userspace.
 
 The CX23885, CX23418, and CX2584x integrated IR is essentially the same.
 I hope to have CX23885 IR done by Christmas.
 
 Both of those IR devices are/will be encapsulated in a v4l2_subdevice
 object internally.  I was going to write lirc_v4l glue between the
 v4l2_device/v4l2_subdev_ir_ops and lirc_dev.
 
 As for the the I2C chips, I was going to go back and encapsulate those
 in the v4l2_subdevice object as well, so then my notional lirc_v4l could
 pick those up too.  The I2C subsystem only allows one binding to an I2C
 client address/name on a bus.  So without some new glue like a notional
 lirc_v4l, it *may* be hard to share between ir-kbd-i2c and lirc_i2c and
 lirc_zilog.

The better is to add the lirc glue at ir-common module. There, we have the 
support
functions used by all V4L devices, and they'll be expanded to cover also
dvb-usb, as soon as I can find some time to do a patch for it.

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

Re: [RFC v2] Another approach to IR

Jon Smirl wrote:
On Wed, Dec 2, 2009 at 9:22 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Jon Smirl wrote:
On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson ja...@wilsonet.com wrote:
On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:

On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
On 12/2/09 12:30 PM, Jon Smirl wrote:
(for each remote/substream that they can recognize).
I'm assuming that, by remote, you're referring to a remote receiver
(and not to
the remote itself), right?
If we could separate by remote transmitter that would be the best I
think, but I understand that it is rarely possible?
The code I posted using configfs did that. Instead of making apps IR
aware it mapped the vendor/device/command triplets into standard Linux
keycodes. Each remote was its own evdev device.
Note, of course, that you can only do that iff each remote uses distinct
triplets. A good portion of mythtv users use a universal of some sort,
programmed to emulate another remote, such as the mce remote bundled
with mceusb transceivers, or the imon remote bundled with most imon
receivers. I do just that myself.

Personally, I've always considered the driver/interface to be the
receiver, not the remote. The lirc drivers operate at the receiver
level, anyway, and the distinction between different remotes is made by
the lirc daemon.
The fact that lirc does it this way does not necessarily mean it is the
most corerct way.
No, I know that, I'm just saying that's how I've always looked at it, and
that's how lirc does it right now, not that it must be that way.

Do you expect all bluetooth input devices be presented
as a single blob just because they happen to talk to the sane receiver
in yoru laptop? Do you expect your USB mouse and keyboard be merged
together just because they end up being serviced by the same host
controller? If not why remotes should be any different?
A bluetooth remote has a specific device ID that the receiver has to pair
with. Your usb mouse and keyboard each have specific device IDs. A usb IR
*receiver* has a specific device ID, the remotes do not. So there's the
major difference from your examples.
Actually remotes do have an ID. They all transmit vendor/device pairs
which is exactly how USB works.

Well, the description of NEC and RC5 protocol at
http://www.sbprojects.com/knowledge/ir/rc5.htm
doesn't mention any vendor/device pair, nor I'm able to get them with the IR
hardware decoders
I have.

Some of the protocols were not intended to be multi-vendor - the
vendor is implicit in the protocol encoding. You don't have to split
the IR codes into vendor/device/command triplets. I just do that
because it is convenient to think of them that way. It is equally
valid to treat them as a 64b integers and use four bits of the int to
encode the protocol. It should really be a quad
protocol/vendor/device/command and some of the fields may be missing.
Bottom line, you are looking for unique codes how the fields are split
up doesn't really matter.

Currently, there aren't any in-kernel driver that support 64 bit IR's.
They support only up to 16 bits. So, we have only address (device)/command.
As I said before, AFAIK, only RC6 mode 6 remotes support 64 bits.

As pointed by Andy, it is risky to support such protocol in kernel,
since you won't be able to ship the kernel to countries where RC6 patents
got accepted, or you would need.

A fixed protocol receiver is more of a challenge. You have to figure
out how to make a universal remote transmit device codes for a device
you don't already own that is also encoded in the protocol your
hardware supports.
There's nothing we can do about that problem in
Linux, its a side effect of fixed protocol decode hardware.

With hardware decoders, you're limited to the supported protocols, but yet,
you can use a different scancode than the one that comes with the shipped
device.

If you take a look, for example, at the NEC protocol decoder we have on
drivers/media/video/saa7134/saa7134-input.c [1], you'll see that the
tasklet (nec_task) holds CPU control up to 76.5 ms, in order to be able
to receive the entire sequence at the GPIO port. Fortunately, on the device
where this decoder is called (Avermedia M135A), we can trigger the start
of the IR code via IRQ.

[1]http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-2.6.git;a=blob;f=drivers/media/video/saa7134/saa7134-input.c;h=6e219c2db8419013ab3ced30470ad1c19431974a;hb=HEAD

In this specific decoder I've implemented it some time ago. I think
I tried first to get the pulse/space width using just IRQ without the tasklet,
but the lengths weren't precise enough for decoding. Also, if you have a bad
contact at the IR sensor connector, as it is directly connected to an IRQ pin,
you may end by hanging the machine, if the code is not carefully written.

I remember I had some bad time due to the bad contacts at the IR sensor
with the sample I had available

Re: [RFC v2] Another approach to IR

Jon Smirl wrote:
 On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson ja...@wilsonet.com wrote:
 On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote:
 ...
 Now I understand that if 2 remotes send completely identical signals we
 won't be able to separate them, but in cases when we can I think we
 should.
 I don't have a problem with that, if its a truly desired feature.  But
 for the most part, I don't see the point.  Generally, you go from
 having multiple remotes, one per device (where device is your TV,
 amplifier, set top box, htpc, etc), to having a single universal remote
 that controls all of those devices.  But for each device (IR receiver),
 *one* IR command set.  The desire to use multiple distinct remotes with
 a single IR receiver doesn't make sense to me.  Perhaps I'm just not
 creative enough in my use of IR.  :)
 Most universal remotes I'm familiar with emulate multiple remotes.  I.e.
 my tv remote generates one set of scancodes for the numeric keys.  The DVD
 remote generates a different set.  The amplifier remote in tv mode
 generates the same codes as the tv remote, and in dvd mode the same codes
 as the dvd remote.  From the perspective of the IR receiver there is no
 difference between having both the DVD and TV remotes, or using the
 aplifier remote to control both devices.
 Okay, in the above scenario, you've still got a single input device...

 Now, my aplifier remote has a number of modes.  Some control devices I
 have, like vcr mode, and there is nothing I can do about that.  Some,
 like md mode don't control devices I have.  That means they are free to
 do things on the computer.  Someone else with the same remote (or any
 number of remotes that use the same protocol and scancodes) might have
 different devices.

 So I want my computer to do stuff when I push JVC MD #xx keys, but ignore
 JVC VCR #yyy yets.  Someone with an MD player and not a VCR would want to
 opposite.  Rather than force everyone to create custom keymaps, it's much
 easier if we can use the standard keymaps from a database of common remotes
 and simply tell mythtv to only use remote #xxx or not to use remote #yyy.
 Sure, but the key is that this can't be done automagically. The IR driver 
 has no way of knowing that user A wants JVC MD keys handled and JVC VCR keys 
 ignored, and user B wants vice versa, while user C wants both ignored, etc. 
 This is somewhat tangential to whether or not there's a separate input 
 device per remote though. You can use multiple remotes/protocols with a 
 single input device or lirc device already (if the hardware doesn't have to 
 be put explicitly into a mode to listen for that proto, of course, but then 
 its a hardware decoding device feeding a single input device anyway, so...).

 It sounds like you're thinking of a receiver that came bundled with a
 remote and that's it.  Not someone with a number of remotes that came with
 different pieces of AV gear that they want to use with their computer.
 No, I just pick *one* remote and use it for everything, not 
 schizophrenically hopping from one remote to another, expecting them all the 
 be able to control everything. :) Its a hell of a lot easier to find buttons 
 w/o looking at the remote if you always use the same one for everything, for 
 one.

 Anyway, I think I'm talking myself in circles. Supporting multiple remotes 
 via multiple input devices (or even via a single input device) isn't at all 
 interesting to me for my own use, but if there really is demand for such 
 support (and it appears there is), then fine, lets do it.
 
 Simple use case:
 
 You have a multifunction remote. Press the CABLE key - it sends out
 commands that control the cable box, press the TV key - now the
 commands control the TV, press CD - now the CD player, etc.
 
 Now imagine a headless Linux box running a music server and a home
 automation app. Press the CD key - commands get routed to the music
 server, press the AUX key - commands get routed to the home automation
 app.
 
 This is accomplished by recognizing the device code part of the IR
 signal and figuring out that there are two different device codes in
 use. The commands of then routed to two evdev devices corresponding to
 the two different device codes.
 
 Using things like Alt-Tab to switch apps is impossible. There's no
 screen to look at.

This usecase makes sense to me.

With the risk of repeating myself, you don't have two physical remotes.
The needed feature is a way to split one source of input events (that
happens to be an infrared remote, but it could also be any other type of input
device, like a bluetooth remote) into several different evdev interfaces,
based on scancode groups. 

Also, as you're thinking on 64 bits scancodes, this also means that the
current evdev KABI and API will require changes to support bigger scancodes.

Anyway, IMO, this subject should be handled as a different requirement than
integrating the lirc drivers.

Cheers,
Mauro.
--
To unsubscribe from this list:

Re: Replace Mercurial with GIT as SCM

2009-12-03 Thread Laurent Pinchart

On Thursday 03 December 2009 09:04:48 Hans de Goede wrote:
 +1 for git, I really really really miss being able to do
 a simple git rebase, and no rebase is not evil not as long
 as you don't use it for anything but local patches.

For what it's worth, I second that. git rebase -i is one of git's killer 
features (I personally learned about it during Linus' talk at the LPC 2009, so 
if you haven't heard about git rebase -i before, take a look at it).

-- 
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: [RFC v2] Another approach to IR

2009-12-03 Thread Andy Walls

On Thu, 2009-12-03 at 08:00 -0200, Mauro Carvalho Chehab wrote:
 Andy Walls wrote:
  On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote:
  On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:

 
  Both of those IR devices are/will be encapsulated in a v4l2_subdevice
  object internally.  I was going to write lirc_v4l glue between the
  v4l2_device/v4l2_subdev_ir_ops and lirc_dev.
  
  As for the the I2C chips, I was going to go back and encapsulate those
  in the v4l2_subdevice object as well, so then my notional lirc_v4l could
  pick those up too.  The I2C subsystem only allows one binding to an I2C
  client address/name on a bus.  So without some new glue like a notional
  lirc_v4l, it *may* be hard to share between ir-kbd-i2c and lirc_i2c and
  lirc_zilog.
 
 Maybe you're having a bad time because you may be trying to integrate lirc
 at the wrong place.

These were just ideas.  I haven't done *anything* yet. ;)


 All devices at V4L tree including ir-kbd-i2c use ir-common.ko 
 (at /drivers/media/common tree) module to communicate to IR's. 
 I'm preparing some patches to extend this also to dvb-usb devices 
 (that uses a close enough infrastructure). 
 
 Also, most of the decoding code are there, in a form of helper routines.
 
 As the idea is to provide lirc interface to all devices that can work with
 raw pulse/space, the proper place is to write a subroutine there that, once
 called, will make those pulse/space raw codes available to lirc and will
 call the needed decoders to export them also to evdev.
 
 The code at ir-common module was originally built to be used by V4L, but I'm
 porting the code there to be generic enough to be a library that can be used
 by other drivers. So, lirc_zilog and other lirc devices that will need to open
 evdev interfaces after running a decoder can use them.

I think I see what you are saying (I wish could see look at a whiteboard
somewhere...).  Wherever we come through internally to split to 2
different userspace interfaces is fine, if you've got a big picture plan
you think is feasible.

That seems like a bit of perturbation to lirc_zilog and lirc_i2c.  My
thought was that lirc_v4l using the standardized v4l2_subdev_ir_ops
interface, and maybe some new calls associted with v4l2_device, could
subsume/unify all the functionality of lirc_i2c, lirc_zilog, ...
lirc_whatever.

Maybe that's just a poorly thought out dream though...


 Due to that, we shouldn't add v4l2_subdevice there. Nothing prevents to create
 a v4l2-ir-subdev glue if you want to see the IR's as subdevices, but this 
 should
 be implemented as a separate module.

The v4l_subdevice just abstracted the IR hardware into a nice (mental)
box for me -- easier to keep hardware separate from software decoders
and userspace interface logic.

Also, since v4l2_subdevices may have per subdevice /dev nodes and
the /dev/../mcN nodes providing a discovery mechanism due to the Meda
Controller framework, wrapping things in v4l2_subdevice may be handy for
development and debug.  Or ... as an additional operational interface to
userspace. :D  *ducks and runs for cover*

Regards,
Andy

 Cheers,
 Mauro.


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

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-03 Thread Gerd Hoffmann


On 12/03/09 05:29, Jarod Wilson wrote:

On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote:


Anyway, we shouldn't postpone lirc drivers addition due to that.
There are still lots of work to do before we'll be able to split
the tables from the kernel drivers.


Indeed.  The sysfs bits are future work for both lirc and evdev
drivers.  There is no reason to make the lirc merge wait for it.


At this point, my plan is to try to finish cleaning up lirc_dev and
lirc_mceusb at least over the weekend while at FUDCon up in Toronto,
and resubmit them next week.


Good plan IMHO.  Having lirc_dev merged quickly allows in-kernel drivers 
start supporting lirc.


One final pass over the lirc interface would be good, taking the chance 
to fixup anything before the ABI is set in stone with the mainline 
merge.  Things to look at:


  (1) Make sure ioctl structs are 32/64 bit invariant.
  (2) Maybe add some reserved fields to allow extending later
  without breaking the ABI.
  (3) Someone suggested a 'commit' ioctl which would activate
  the parameters set in (multiple) previous ioctls.  Makes sense?
  (4) Add a ioctl to enable/disable evdev event submission for
  evdev/lirc hybrid drivers.


I'm still on the fence over what to do about lirc_imon. The driver
supports essentially 3 generations of devices. First-gen is very old
imon parts that don't do onboard decoding. Second-gen is the devices
that all got (insanely stupidly) tagged with the exact same usb
device ID (0x15c2:0xffdc), some of which have an attached VFD, some
with an attached LCD, some with neither, some that are actually RF
parts, but all (I think) of which do onboard decoding. Third-gen is
the latest stuff, which is all pretty sane, unique device IDs for
unique devices, onboard decoding, etc.


Do have second-gen and third-gen devices have a 'raw mode'?  If so, then 
there should be a lirc interface for raw data access.



So the lirc_imon I submitted supports all device types, with the
onboard decode devices defaulting to operating as pure input devices,
but an option to pass hex values out via the lirc interface (which is
how they've historically been used -- the pure input stuff I hacked
together just a few weeks ago), to prevent functional setups from
being broken for those who prefer the lirc way.


Hmm.  I'd tend to limit the lirc interface to the 'raw samples' case.

Historically it has also been used to pass decoded data (i.e. rc5) from 
devices with onboard decoding, but for that in-kernel mapping + input 
layer really fits better.



What I'm debating is whether this should be split into two drivers,
one for the older devices that don't do onboard decoding (which would
use the lirc_dev interface) called 'lirc_imon' or 'lirc_imon_legacy',
and one that is a pure input driver, not unlike the ati_remote{,2}
drivers, with no lirc_dev dependency at all, probably called simply
'imon'.


i.e. lirc_imon would support first+second gen, and imon third-gen 
devices, without overlap?


 But if I split it out, there may end up being a

fair amount of code duplication,


You could try to split common code into a third module used by the other 
two.  Or have one module for all devices which is a evdev/lirc hybrid.


cheers,
  Gerd

--
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: /dev/dvb/adapter0/net0 -- what is this for and how to use it?

2009-12-03 Thread pierre.gronlier

Leszek Koltunski wrote, On 12/03/2009 09:21 AM:
 Hello DVB gurus,
 
 I've got a TwinHan DVB-S2 card. I compiled the 'liplianin' drivers and
 it's working nicely; thanks for all your work!
 
 One question: in /dev/dvb/adapter0 I can see
 
 les...@satellite:~$ ls -l /dev/dvb/adapter0/
 total 0
 crw-rw+ 1 root video 212, 4 2009-12-02 18:22 ca0
 crw-rw+ 1 root video 212, 0 2009-12-02 18:22 demux0
 crw-rw+ 1 root video 212, 1 2009-12-02 18:22 dvr0
 crw-rw+ 1 root video 212, 3 2009-12-02 18:22 frontend0
 crw-rw+ 1 root video 212, 2 2009-12-02 18:22 net0
 
 What is this 'net0' device and how do I use it? Can I use it to
 directly multicast my (FTA) satellite stream to my lan by any chance?

You can use MuMuDVB for this: http://mumudvb.braice.net/

And net0 is related to network over dvb. look at the dvbnet tool (in
dvb-apps package)

Pierre

 
 I have found no documentation about this...

--
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 v2 0/3] patches for radio-si470x-i2c driver

2009-12-03 Thread Joonyoung Shim

Hi,

I post patches v2 for radio-si470x-i2c driver.

[PATCH v2 1/3] radio-si470x: move some file operations to common file
[PATCH v2 2/3] radio-si470x: support RDS on si470x i2c driver
[PATCH v2 3/3] radio-si470x: support PM functions

1/3 patch is same with v1.
2/3 patch is updated the RDS interrupt enable code by review of Tobias.
3/3 patch is to support PM.

And first patch of v1 is unnecessary by 2/3 patch of v2.

Thanks.
--
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 v2 3/3] radio-si470x: support PM functions

2009-12-03 Thread Joonyoung Shim

This patch is to support PM of the si470x i2c driver.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
 drivers/media/radio/si470x/radio-si470x-i2c.c |   40 +
 1 files changed, 40 insertions(+), 0 deletions(-)

diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c 
b/drivers/media/radio/si470x/radio-si470x-i2c.c
index 77532e6..4c6e586 100644
--- a/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -486,6 +486,44 @@ static __devexit int si470x_i2c_remove(struct i2c_client 
*client)
 }
 
 
+#ifdef CONFIG_PM
+/*
+ * si470x_i2c_suspend - suspend the device
+ */
+static int si470x_i2c_suspend(struct i2c_client *client, pm_message_t mesg)
+{
+   struct si470x_device *radio = i2c_get_clientdata(client);
+
+   /* power down */
+   radio-registers[POWERCFG] |= POWERCFG_DISABLE;
+   if (si470x_set_register(radio, POWERCFG)  0)
+   return -EIO;
+
+   return 0;
+}
+
+
+/*
+ * si470x_i2c_resume - resume the device
+ */
+static int si470x_i2c_resume(struct i2c_client *client)
+{
+   struct si470x_device *radio = i2c_get_clientdata(client);
+
+   /* power up : need 110ms */
+   radio-registers[POWERCFG] |= POWERCFG_ENABLE;
+   if (si470x_set_register(radio, POWERCFG)  0)
+   return -EIO;
+   msleep(110);
+
+   return 0;
+}
+#else
+#define si470x_i2c_suspend NULL
+#define si470x_i2c_resume  NULL
+#endif
+
+
 /*
  * si470x_i2c_driver - i2c driver interface
  */
@@ -496,6 +534,8 @@ static struct i2c_driver si470x_i2c_driver = {
},
.probe  = si470x_i2c_probe,
.remove = __devexit_p(si470x_i2c_remove),
+   .suspend= si470x_i2c_suspend,
+   .resume = si470x_i2c_resume,
.id_table   = si470x_i2c_id,
 };
 
-- 
1.6.3.3
--
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 v2 1/3] radio-si470x: move some file operations to common file

2009-12-03 Thread Joonyoung Shim

The read and poll file operations of the si470x usb driver can be used
also equally on the si470x i2c driver, so they go to the common file.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
 drivers/media/radio/si470x/radio-si470x-common.c |   98 ++
 drivers/media/radio/si470x/radio-si470x-i2c.c|   15 +---
 drivers/media/radio/si470x/radio-si470x-usb.c|   97 +-
 drivers/media/radio/si470x/radio-si470x.h|3 +-
 4 files changed, 104 insertions(+), 109 deletions(-)

diff --git a/drivers/media/radio/si470x/radio-si470x-common.c 
b/drivers/media/radio/si470x/radio-si470x-common.c
index 7296cf4..f4645d4 100644
--- a/drivers/media/radio/si470x/radio-si470x-common.c
+++ b/drivers/media/radio/si470x/radio-si470x-common.c
@@ -426,6 +426,104 @@ int si470x_rds_on(struct si470x_device *radio)
 
 
 /**
+ * File Operations Interface
+ **/
+
+/*
+ * si470x_fops_read - read RDS data
+ */
+static ssize_t si470x_fops_read(struct file *file, char __user *buf,
+   size_t count, loff_t *ppos)
+{
+   struct si470x_device *radio = video_drvdata(file);
+   int retval = 0;
+   unsigned int block_count = 0;
+
+   /* switch on rds reception */
+   if ((radio-registers[SYSCONFIG1]  SYSCONFIG1_RDS) == 0)
+   si470x_rds_on(radio);
+
+   /* block if no new data available */
+   while (radio-wr_index == radio-rd_index) {
+   if (file-f_flags  O_NONBLOCK) {
+   retval = -EWOULDBLOCK;
+   goto done;
+   }
+   if (wait_event_interruptible(radio-read_queue,
+   radio-wr_index != radio-rd_index)  0) {
+   retval = -EINTR;
+   goto done;
+   }
+   }
+
+   /* calculate block count from byte count */
+   count /= 3;
+
+   /* copy RDS block out of internal buffer and to user buffer */
+   mutex_lock(radio-lock);
+   while (block_count  count) {
+   if (radio-rd_index == radio-wr_index)
+   break;
+
+   /* always transfer rds complete blocks */
+   if (copy_to_user(buf, radio-buffer[radio-rd_index], 3))
+   /* retval = -EFAULT; */
+   break;
+
+   /* increment and wrap read pointer */
+   radio-rd_index += 3;
+   if (radio-rd_index = radio-buf_size)
+   radio-rd_index = 0;
+
+   /* increment counters */
+   block_count++;
+   buf += 3;
+   retval += 3;
+   }
+   mutex_unlock(radio-lock);
+
+done:
+   return retval;
+}
+
+
+/*
+ * si470x_fops_poll - poll RDS data
+ */
+static unsigned int si470x_fops_poll(struct file *file,
+   struct poll_table_struct *pts)
+{
+   struct si470x_device *radio = video_drvdata(file);
+   int retval = 0;
+
+   /* switch on rds reception */
+   if ((radio-registers[SYSCONFIG1]  SYSCONFIG1_RDS) == 0)
+   si470x_rds_on(radio);
+
+   poll_wait(file, radio-read_queue, pts);
+
+   if (radio-rd_index != radio-wr_index)
+   retval = POLLIN | POLLRDNORM;
+
+   return retval;
+}
+
+
+/*
+ * si470x_fops - file operations interface
+ */
+static const struct v4l2_file_operations si470x_fops = {
+   .owner  = THIS_MODULE,
+   .read   = si470x_fops_read,
+   .poll   = si470x_fops_poll,
+   .ioctl  = video_ioctl2,
+   .open   = si470x_fops_open,
+   .release= si470x_fops_release,
+};
+
+
+
+/**
  * Video4Linux Interface
  **/
 
diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c 
b/drivers/media/radio/si470x/radio-si470x-i2c.c
index 2d53b6a..4816a6d 100644
--- a/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -173,7 +173,7 @@ int si470x_disconnect_check(struct si470x_device *radio)
 /*
  * si470x_fops_open - file open
  */
-static int si470x_fops_open(struct file *file)
+int si470x_fops_open(struct file *file)
 {
struct si470x_device *radio = video_drvdata(file);
int retval = 0;
@@ -194,7 +194,7 @@ static int si470x_fops_open(struct file *file)
 /*
  * si470x_fops_release - file release
  */
-static int si470x_fops_release(struct file *file)
+int si470x_fops_release(struct file *file)
 {
struct si470x_device *radio = video_drvdata(file);
int retval = 0;
@@ -215,17 +215,6 @@ static int si470x_fops_release(struct file *file)
 }
 
 
-/*
- * si470x_fops - file operations interface
- */

[PATCH] max2165 32bit build patch

2009-12-03 Thread David T. L. Wong


Randy Dunlap wrote:

On Mon, 30 Nov 2009 10:07:21 -0800 Randy Dunlap wrote:


Stephen Rothwell wrote:

Hi all,

Changes since 20091127:

The v4l-dvb tree lost its conflict.


on i386 (X86_32):

a 'double' variable is used, causing:

ERROR: __floatunsidf [drivers/media/common/tuners/max2165.ko] undefined!
ERROR: __adddf3 [drivers/media/common/tuners/max2165.ko] undefined!
ERROR: __fixunsdfsi [drivers/media/common/tuners/max2165.ko] undefined!



linux-next-20091202:

still have this one (above) and similar with
drivers/media/dvb/frontends/atbm8830.c:

drivers/built-in.o: In function `atbm8830_init':
atbm8830.c:(.text+0x9012f9): undefined reference to `__udivdi3'
atbm8830.c:(.text+0x901384): undefined reference to `__floatunsidf'
atbm8830.c:(.text+0x901395): undefined reference to `__muldf3'
atbm8830.c:(.text+0x9013a5): undefined reference to `__floatunsidf'
atbm8830.c:(.text+0x9013b2): undefined reference to `__divdf3'
atbm8830.c:(.text+0x9013c3): undefined reference to `__muldf3'
atbm8830.c:(.text+0x9013cd): undefined reference to `__fixunsdfsi'

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


This patch drops usage of floating point variable for 32bit build

Signed-off-by: David T. L. Wong davidtlw...@gmail.com
diff --git a/linux/drivers/media/common/tuners/max2165.c b/linux/drivers/media/common/tuners/max2165.c
--- a/linux/drivers/media/common/tuners/max2165.c
+++ b/linux/drivers/media/common/tuners/max2165.c
@@ -193,7 +193,7 @@
 {
 	u8 tf;
 	u8 tf_ntch;
-	double t;
+	u32 t;
 	u32 quotient, fraction;
 
 	/* Set PLL divider according to RF frequency */
@@ -217,9 +217,6 @@
 	t += (priv-tf_balun_hi_ref - priv-tf_balun_low_ref)
 		* (freq / 1000 - 47) / (78 - 47);
 
-#if 0
-	tf = t + 0.5; /* round up */
-#endif
 	tf = t;
 	dprintk(tf = %X\n, tf);
 	tf |= tf_ntch  4;

[PATCH] atbm8830: replace 64-bit division and floating point usage

2009-12-03 Thread David T. L. Wong


Randy Dunlap wrote:

On Mon, 30 Nov 2009 10:07:21 -0800 Randy Dunlap wrote:


Stephen Rothwell wrote:

Hi all,

Changes since 20091127:

The v4l-dvb tree lost its conflict.


on i386 (X86_32):

a 'double' variable is used, causing:

ERROR: __floatunsidf [drivers/media/common/tuners/max2165.ko] undefined!
ERROR: __adddf3 [drivers/media/common/tuners/max2165.ko] undefined!
ERROR: __fixunsdfsi [drivers/media/common/tuners/max2165.ko] undefined!



linux-next-20091202:

still have this one (above) and similar with
drivers/media/dvb/frontends/atbm8830.c:

drivers/built-in.o: In function `atbm8830_init':
atbm8830.c:(.text+0x9012f9): undefined reference to `__udivdi3'
atbm8830.c:(.text+0x901384): undefined reference to `__floatunsidf'
atbm8830.c:(.text+0x901395): undefined reference to `__muldf3'
atbm8830.c:(.text+0x9013a5): undefined reference to `__floatunsidf'
atbm8830.c:(.text+0x9013b2): undefined reference to `__divdf3'
atbm8830.c:(.text+0x9013c3): undefined reference to `__muldf3'
atbm8830.c:(.text+0x9013cd): undefined reference to `__fixunsdfsi'

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


This patch replace 64-bit division by do_div() macro and remove usage of 
floating point variable


Signed-off-by: David T. L. Wong davidtlw...@gmail.com
diff --git a/linux/drivers/media/dvb/frontends/atbm8830.c b/linux/drivers/media/dvb/frontends/atbm8830.c
--- a/linux/drivers/media/dvb/frontends/atbm8830.c
+++ b/linux/drivers/media/dvb/frontends/atbm8830.c
@@ -19,6 +19,7 @@
  *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
+#include asm/div64.h
 #include dvb_frontend.h
 
 #include atbm8830.h
@@ -102,8 +103,12 @@
 static int set_osc_freq(struct atbm_state *priv, u32 freq /*in kHz*/)
 {
 	u32 val;
+	u64 t;
 
-	val = (u64)0x10 * freq / 30400;
+	/* 0x10 * freq / 30.4MHz */
+	t = (u64)0x10 * freq;
+	do_div(t, 30400);
+	val = t;
 
 	atbm8830_write_reg(priv, REG_OSC_CLK, val);
 	atbm8830_write_reg(priv, REG_OSC_CLK + 1, val  8);
@@ -116,14 +121,18 @@
 {
 	
 	u32 fs = priv-config-osc_clk_freq;
-	double t;
+	u64 t;
 	u32 val;
 	u8 dat;
 
-	t = 2 * 3.141593 * (freq - fs) / fs * (1  22);
-	val = t;
+	if (freq != 0) {
+		/* 2 * PI * (freq - fs) / fs * (2 ^ 22) */
+		t = (u64) 2 * 31416 * (freq - fs);
+		t = 22;
+		do_div(t, fs);
+		do_div(t, 1000);
+		val = t;
 
-	if (freq != 0) {
 		atbm8830_write_reg(priv, REG_TUNER_BASEBAND, 1);
 		atbm8830_write_reg(priv, REG_IF_FREQ, val);
 		atbm8830_write_reg(priv, REG_IF_FREQ+1, val  8);

[PULL] http://kernellabs.com/hg/~mkrufky/hcw-ids

2009-12-03 Thread Michael Krufky

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/hcw-ids

for:

- smsusb: add autodetection support for five additional Hauppauge USB IDs

 smsusb.c |   10 ++
 1 file changed, 10 insertions(+)

Regards,

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

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

Hans,

Thanks for sending this pull request. No problem in my name being mentioned in 
the spec.

Thanks. 

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Wednesday, December 02, 2009 11:40 PM
To: linux-media@vger.kernel.org
Cc: Mauro Carvalho Chehab; Karicheri, Muralidharan
Subject: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings

Hi Mauro,

Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings for
the following:

- v4l: Adding Digital Video Timings APIs
- v4l2-spec: Digital Video Timings API documentation
- v4l2-spec: updated revision history, updated version to 2.6.33.

Murali, I've added you as one of the authors of the v4l2-spec (you did this
timings API after all) and included your email as well. If that is a
problem
for you (either being mentioned at all, or that your email is mentioned),
then
let me know asap and I'll remove it. I don't expect it to be a problem
since
all this information is already public.

Mauro, before adding these documentation patches it is probably a good idea
to build and release a final 2.6.32 version of the documentation on
http://www.linuxtv.org/docs.php.

If you want to see an example of this api being used, then take a look at
the
tvp7002 driver patches that have been posted recently. I expect that driver
to be merged soon after this pull request is merged.

Thanks,

Hans

diffstat:
 b/linux/Documentation/DocBook/v4l/vidioc-enum-dv-presets.xml |  238
+++
 b/linux/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml |  111 +
 b/linux/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml|  224
++
 b/linux/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml |   85 +++
 linux/Documentation/DocBook/media-entities.tmpl  |   18
 linux/Documentation/DocBook/media-indices.tmpl   |4
 linux/Documentation/DocBook/v4l/common.xml   |   35 +
 linux/Documentation/DocBook/v4l/compat.xml   |   16
 linux/Documentation/DocBook/v4l/v4l2.xml |   26 +
 linux/Documentation/DocBook/v4l/videodev2.h.xml  |  116 +
 linux/Documentation/DocBook/v4l/vidioc-enuminput.xml |   36 +
 linux/Documentation/DocBook/v4l/vidioc-enumoutput.xml|   36 +
 linux/drivers/media/video/v4l2-compat-ioctl32.c  |6
 linux/drivers/media/video/v4l2-ioctl.c   |  147 ++
 linux/include/linux/videodev2.h  |  116 +
 linux/include/media/v4l2-ioctl.h |   15
 linux/include/media/v4l2-subdev.h|   21
 media-specs/Makefile |   14
 18 files changed, 1252 insertions(+), 12 deletions(-)

Fwd: DVB-APPS patch for uk-WinterHill

2009-12-03 Thread Justin Hornsby

Since 02 Dec 2009 the UK WinterHill transmitter site has been
broadcasting on different frequencies  in a different mode with
different modulation.  Channels have been re-arranged to occupy five
multiplexes and the original BBC 'B' mux is now broadcasting DVB-T2
for high definition services (which of course cannot yet be tuned by
mere mortals). The 'WinterHill B' transmitter stopped broadcasting on
02 Dec.

The attached file is a patch to reflect these changes.

NOTE: All UK DVB-T services will eventually be moving to 8k mode in
64QAM  other local frequencies will be changing once DSO (digital
switch over) is complete in each area.

Hope this info is of use to you folks :-)

Regards,
Justin

uk-WinterHill.patch

--- uk-WinterHill       2009-12-03 14:30:32.0 +
+++ uk-WinterHill.new   2009-12-03 14:26:05.0 +
@@ -1,13 +1,11 @@
 # UK, Winter Hill
-# Auto-generated from http://www.dtg.org.uk/retailer/dtt_channels.html
-# and http://www.ofcom.org.uk/static/reception_advice/index.asp.html
+# Populated by J. Hornsby from a scan of active multiplexes
 # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
-T 754167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-T 834167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE
-T 850167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE
-T 842167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-T 786167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-T 810167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-# UK, Winter Hill B
-T 65000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-T 62600 8MHz 3/4 NONE QAM16 2k 1/32 NONE
+T 74600 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 77000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 77800 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 79400 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 801833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+
+# UK, Winter Hill B Ceased broadcasting on 02 December 2009
+
--- uk-WinterHill	2009-12-03 14:30:32.0 +
+++ uk-WinterHill.new	2009-12-03 14:26:05.0 +
@@ -1,13 +1,11 @@
 # UK, Winter Hill
-# Auto-generated from http://www.dtg.org.uk/retailer/dtt_channels.html
-# and http://www.ofcom.org.uk/static/reception_advice/index.asp.html
+# Populated by J. Hornsby from a scan of active multiplexes
 # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
-T 754167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-T 834167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE
-T 850167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE
-T 842167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-T 786167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-T 810167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-# UK, Winter Hill B
-T 65000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-T 62600 8MHz 3/4 NONE QAM16 2k 1/32 NONE
+T 74600 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 77000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 77800 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 79400 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 801833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+
+# UK, Winter Hill B Ceased broadcasting on 02 December 2009
+

Syncing videobuf buffers before an operation

2009-12-03 Thread Pawel Osciak

Hello!

We have been facing the problem of sync()ing buffers before performing
operations on them.

This is the current buffer life cycle in videobuf (for streaming, slightly
simplified):

- qbuf:
  buf_prepare, from which drivers call videobuf_iolock() if the state is
  VIDEOBUF_NEEDS_INIT (i.e. once per streamon)

- dqbuf:
  where per-memory method sync() is called

- streamoff:
  where buffers are released (i.e. iolock is released)


We are working with devices that have a non-coherent cache (ARM-based).
For them sync()ing means flushing CPU cache for the physical memory to
contain valid data. We require syncing buffers not only after, but before
running the operation as well.

For CAPTURE devices this prevents corruption in case a flush occurs after
the operation has finished and overwrites the results with old data (from
before the operation).

For OUTPUT-type devices sync()ing is even more important, as the source
data may be completely invalid before the operation - before DMA can
be started, CPU cache has to be flushed.


We have divided sync operations into the following types:
- sync CAPTURE buffers before the operation
- sync CAPTURE buffers after the operation
- sync OUTPUT buffers before the operation

Our idea is to add an additional sync() call to videobuf_qbuf and
a parameter that would allow differentiating between syncs before and
after the operation. Alternatively, an additional function for that
could be added, if we don't want to change the API.

Please note that this is different from iolock(). Iolock is performed
once per streamon and what we need is a sync (which should also be
more lightweight than a full iolock) per each qbuf.

I would be grateful for your opinions on this topic. We'd like to
propose a patch if we come to an agreement on this as well.
Thank you!


Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland RD Center

--
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 - v0 2/2] DaVinci - vpfe capture - Make clocks configurable

I was talking to Sekhar about this and actually he made some good points
about this implementation.

If we consider specific IP, then the required clocks would remain always be
the same. There might be some devices which may not be using some clocks
(so as that specific feature).

Actually we are trying to create one more wrapper for clock configuration.
Just to illustrate I am putting some other generic drivers examples -

Omap-hsmmc.c -

This driver requires 2 clocks, interface and functional. The devices which
would be using this driver have to define clock with names ick and fck.

VPFE-Capture (Considering only current implementation) -

Currently we have vpfe_capture.c file (master/bridge driver) which is
handling clk_get/put, and platform data is providing the details about it.
Ideally we should handle it in respective ccdc driver file, since he has
all the knowledge about required number of clocks and its name. This way we
don't have to maintain/pass clock information in platform data.

I would appreciate any comments/thoughts/pointers here.

Though I agree that this clock could be set by the ccdc driver, I am not sure 
if the same clock is used by an IP on different SOCs. For example take
the case of ccdc on DM6446 which is also used on OMAP 35xx SOC. Do they use
vpss master and slave clocks as is done on DM6446? If this is true, then we
could set the clock inside ccdc driver. 

Let me know so that I can re-work the patch and send it to the list.

Murali
Thanks,
Vaibhav

  };

  static struct platform_device *davinci_evm_devices[] __initdata = {
 diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
 b/arch/arm/mach-davinci/board-dm644x-evm.c
 index fd0398b..45beb99 100644
 --- a/arch/arm/mach-davinci/board-dm644x-evm.c
 +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
 @@ -250,6 +250,8 @@ static struct vpfe_config vpfe_cfg = {
  .sub_devs = vpfe_sub_devs,
  .card_name = DM6446 EVM,
  .ccdc = DM6446 CCDC,
 +.num_clocks = 2,
 +.clocks = {vpss_master, vpss_slave},
  };

  static struct platform_device rtc_dev = {
 --
 1.6.0.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

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Ferenc Wagner

Mauro Carvalho Chehab mche...@redhat.com writes:

 Dmitry Torokhov wrote:

 On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:

 Now I understand that if 2 remotes send completely identical
 signals we won't be able to separete them, but in cases when we
 can I think we should.

 They are the same key events (Lets's say KEY_PLAY) but one is
 supposed to affect CD player while another DVD player
 application. Evdev will not be able to distinguish them but if we had
 2 separate devices then applications could read from the one thet
 user assigned to them.

 This is clear, but the point is that the two distinguish scancodes can
 (and, in practice, will) be generated by the same IR. For example, my
 Satellite IR produces two different sets of codes. if you press SAT,
 all keys you press after that will have the sat address. If you
 press TV, they'll get a different address.

The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
by any remote (ok, I'm stretching it a bit).  Instead, a multifunction
remote (or two distinct remotes) would send different scan codes[1],
which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example.
Btw. the former is already defined, besides the generic KEY_PLAY.

Even if all this worked, user space would need integration with
hal/devicekit to open the new input devices appearing on the fly (if
it's initiated by the arrival of a scan code belonging to some new
protocol), and also be able to decide whether the new event source is
for it or not.

Given that commodity home appliances manage not to be confused by
multiple or multifunction remotes, decent software should be able to do
so as well.

[1] scan codes in the broadest possible sense, containing vendor,
address and whatever, and only treating the case which is possible to
handle in principle.
-- 
Regards,
Feri.
--
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] V4L/DVB: pms: KERNEL_VERSION requires version.h

2009-12-03 Thread Randy Dunlap

On Thu,  3 Dec 2009 12:48:27 +0300 Alexander Beregalov wrote:

 Fix this build error:
 drivers/media/video/pms.c:682: error: implicit declaration of function 
 'KERNEL_VERSION'
 
 Signed-off-by: Alexander Beregalov a.berega...@gmail.com

I've already sent this patch, so I can also ack it...

Acked-by: Randy Dunlap randy.dun...@oracle.com


 ---
  drivers/media/video/pms.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/media/video/pms.c b/drivers/media/video/pms.c
 index 00228d5..a118bb1 100644
 --- a/drivers/media/video/pms.c
 +++ b/drivers/media/video/pms.c
 @@ -35,6 +35,7 @@
  #include media/v4l2-ioctl.h
  #include media/v4l2-device.h
  #include linux/mutex.h
 +#include linux/version.h
  
  #include asm/uaccess.h
  
 -- 


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

RE: [linux-dvb] ds3000.c driver question (Tevii S660 USB DVB-S/S2 tuner)

2009-12-03 Thread Matthias

Dear Michael,

We have update Linux driver released today; you can find it from the link
below
http://www.tevii.com/Support.asp

TeVii Support

-Original Message-
From: linux-dvb-boun...@linuxtv.org [mailto:linux-dvb-boun...@linuxtv.org]
On Behalf Of Michael Durket
Sent: Wednesday, December 02, 2009 10:39 PM
To: linux-...@linuxtv.org
Subject: [linux-dvb] ds3000.c driver question (Tevii S660 USB DVB-S/S2
tuner)

I have some questions about the ds3000.c driver. I (and also someone at
Tevii at my 
request) have attempted to contact the driver author to no avail. Is there
anyone here
familiar enough with that driver (and the firmware) that can answer some
detailed questions
about the device?


___
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


--
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 - v1] V4L - Documentation:Adds EBUSY error code for S_STD and QUERYSTD ioctls

2009-12-03 Thread m-karicheri2

From: Muralidharan Karicheri m-kariche...@ti.com

During review of Video Timing API documentation, Hans Verkuil had a comment
on adding EBUSY error code for VIDIOC_S_STD and VIDIOC_QUERYSTD ioctls. This
patch updates the document for this.

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
diff -uNr 
v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/vidioc-g-std.xml 
v4l-dvb_patch1/linux/Documentation/DocBook/v4l/vidioc-g-std.xml
--- 
v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/vidioc-g-std.xml
2009-12-01 17:02:04.0 -0500
+++ v4l-dvb_patch1/linux/Documentation/DocBook/v4l/vidioc-g-std.xml 
2009-12-03 11:18:34.0 -0500
@@ -86,6 +86,12 @@
 constantVIDIOC_S_STD/constant parameter was unsuitable./para
/listitem
   /varlistentry
+  varlistentry
+   termerrorcodeEBUSY/errorcode/term
+   listitem
+ paraThe device is busy and therefore can not change the 
standard/para
+   /listitem
+  /varlistentry
 /variablelist
   /refsect1
 /refentry
diff -uNr 
v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/vidioc-querystd.xml 
v4l-dvb_patch1/linux/Documentation/DocBook/v4l/vidioc-querystd.xml
--- 
v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/vidioc-querystd.xml 
2009-12-01 17:02:04.0 -0500
+++ v4l-dvb_patch1/linux/Documentation/DocBook/v4l/vidioc-querystd.xml  
2009-12-03 11:18:44.0 -0500
@@ -70,6 +70,12 @@
  paraThis ioctl is not supported./para
/listitem
   /varlistentry
+  varlistentry
+   termerrorcodeEBUSY/errorcode/term
+   listitem
+ paraThe device is busy and therefore can not detect the 
standard/para
+   /listitem
+  /varlistentry
 /variablelist
   /refsect1
 /refentry
--
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 v2] Another approach to IR

Ferenc Wagner wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 
 Dmitry Torokhov wrote:


 The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
 KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
 by any remote (ok, I'm stretching it a bit). 

Unfortunately, this is not true. Some IR's do send a keycode for TV/PC/SAT/CD, 
etc.

On those remotes, if you press TV and then press for example Channel UP
and press Radio, then press Channel UP, the channel UP code will be the same.

For example, on Hauppauge Grey IR, we have:

TV
[13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e1c 
keycode 0x179
[13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 
down=1
[13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 
down=0

CHANNEL UP
[13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 
keycode 0x192
[13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
down=1
[13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
down=0

Radio
[13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e0c 
keycode 0x181
[13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 
down=1
[13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 
down=0

CHANNEL UP
[13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 
keycode 0x192
[13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
down=1
[13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
down=0

In this IR, the address is bogus: it is always 0x1e. This scenario is very 
common with the
shipped IR's.

 Instead, a multifunction
 remote (or two distinct remotes) would send different scan codes[1],
 which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example.
 Btw. the former is already defined, besides the generic KEY_PLAY.
 
 Even if all this worked, user space would need integration with
 hal/devicekit to open the new input devices appearing on the fly (if
 it's initiated by the arrival of a scan code belonging to some new
 protocol), and also be able to decide whether the new event source is
 for it or not.
 
 Given that commodity home appliances manage not to be confused by
 multiple or multifunction remotes, decent software should be able to do
 so as well.
 
 [1] scan codes in the broadest possible sense, containing vendor,
 address and whatever, and only treating the case which is possible to
 handle in principle.

I see two alternatives for it:
1) to map a multifunction scancode Address=TV/command=channel up as two
separate events: KEY_TV | KEY_CHANNELUP and let some userspace program to
handle it (lirc or other programs that knows IR keycodes);

2) to implement Jon's filter idea of splitting one evdev interface into
several evdevs interface, one for each address.

We should not forget that simple IR's don't have any key to select the address,
so the produced codes there will never have KEY_TV/KEY_DVD, etc.

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

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Jon Smirl

On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Ferenc Wagner wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:

 Dmitry Torokhov wrote:


 The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
 KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
 by any remote (ok, I'm stretching it a bit).

 Unfortunately, this is not true. Some IR's do send a keycode for 
 TV/PC/SAT/CD, etc.

 On those remotes, if you press TV and then press for example Channel UP
 and press Radio, then press Channel UP, the channel UP code will be the same.

 For example, on Hauppauge Grey IR, we have:

 TV
 [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
 0x1e1c keycode 0x179
 [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 
 down=1
 [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 
 down=0

 CHANNEL UP
 [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
 0x1e20 keycode 0x192
 [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
 down=1
 [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
 down=0

 Radio
 [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
 0x1e0c keycode 0x181
 [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 
 down=1
 [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 
 down=0

 CHANNEL UP
 [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
 0x1e20 keycode 0x192
 [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
 down=1
 [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
 down=0

 In this IR, the address is bogus: it is always 0x1e. This scenario is very 
 common with the
 shipped IR's.

The remote is treating everything as a single integrated device which
is not inconsistent with what has been said. In this case there really
is only one multi-function device not two independent ones.

If you want to control two independent devices you need to buy a
different remote. Remotes are cheap so that's not a big deal.

If you really want to use this remote to control two independent
devices you need user space scripting to split the single device into
two devices and then inject new events into the input layer. This is a
complex case and not in the goal of getting 90% of users to just
work.


 Instead, a multifunction
 remote (or two distinct remotes) would send different scan codes[1],
 which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example.
 Btw. the former is already defined, besides the generic KEY_PLAY.

 Even if all this worked, user space would need integration with
 hal/devicekit to open the new input devices appearing on the fly (if
 it's initiated by the arrival of a scan code belonging to some new
 protocol), and also be able to decide whether the new event source is
 for it or not.

 Given that commodity home appliances manage not to be confused by
 multiple or multifunction remotes, decent software should be able to do
 so as well.

 [1] scan codes in the broadest possible sense, containing vendor,
 address and whatever, and only treating the case which is possible to
 handle in principle.

 I see two alternatives for it:
        1) to map a multifunction scancode Address=TV/command=channel up as two
 separate events: KEY_TV | KEY_CHANNELUP and let some userspace program to
 handle it (lirc or other programs that knows IR keycodes);

        2) to implement Jon's filter idea of splitting one evdev interface into
 several evdevs interface, one for each address.

 We should not forget that simple IR's don't have any key to select the 
 address,
 so the produced codes there will never have KEY_TV/KEY_DVD, etc.

 Cheers,
 Mauro.




-- 
Jon Smirl
jonsm...@gmail.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: [PATCH] max2165 32bit build patch

2009-12-03 Thread Randy Dunlap

On Thu, 03 Dec 2009 21:54:25 +0800 David T. L. Wong wrote:

 Randy Dunlap wrote:
  On Mon, 30 Nov 2009 10:07:21 -0800 Randy Dunlap wrote:
  
  Stephen Rothwell wrote:
  Hi all,
 
  Changes since 20091127:
 
  The v4l-dvb tree lost its conflict.
 
  on i386 (X86_32):
 
  a 'double' variable is used, causing:
 
  ERROR: __floatunsidf [drivers/media/common/tuners/max2165.ko] undefined!
  ERROR: __adddf3 [drivers/media/common/tuners/max2165.ko] undefined!
  ERROR: __fixunsdfsi [drivers/media/common/tuners/max2165.ko] undefined!
  
  
  linux-next-20091202:
  
  still have this one (above) and similar with
  drivers/media/dvb/frontends/atbm8830.c:
  
  drivers/built-in.o: In function `atbm8830_init':
  atbm8830.c:(.text+0x9012f9): undefined reference to `__udivdi3'
  atbm8830.c:(.text+0x901384): undefined reference to `__floatunsidf'
  atbm8830.c:(.text+0x901395): undefined reference to `__muldf3'
  atbm8830.c:(.text+0x9013a5): undefined reference to `__floatunsidf'
  atbm8830.c:(.text+0x9013b2): undefined reference to `__divdf3'
  atbm8830.c:(.text+0x9013c3): undefined reference to `__muldf3'
  atbm8830.c:(.text+0x9013cd): undefined reference to `__fixunsdfsi'
  
  ---
 
 This patch drops usage of floating point variable for 32bit build
 
 Signed-off-by: David T. L. Wong davidtlw...@gmail.com

Acked-by: Randy Dunlap randy.dun...@oracle.com

Please generate patches so that they can be applied by using
$ patch -p1
at the top of the kernel source tree.

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

Re: [PATCH] atbm8830: replace 64-bit division and floating point usage

2009-12-03 Thread Randy Dunlap

On Thu, 03 Dec 2009 21:57:02 +0800 David T. L. Wong wrote:

 Randy Dunlap wrote:
  On Mon, 30 Nov 2009 10:07:21 -0800 Randy Dunlap wrote:
  
  Stephen Rothwell wrote:
  Hi all,
 
  Changes since 20091127:
 
  The v4l-dvb tree lost its conflict.
 
  on i386 (X86_32):
 
  a 'double' variable is used, causing:
 
  ERROR: __floatunsidf [drivers/media/common/tuners/max2165.ko] undefined!
  ERROR: __adddf3 [drivers/media/common/tuners/max2165.ko] undefined!
  ERROR: __fixunsdfsi [drivers/media/common/tuners/max2165.ko] undefined!
  
  
  linux-next-20091202:
  
  still have this one (above) and similar with
  drivers/media/dvb/frontends/atbm8830.c:
  
  drivers/built-in.o: In function `atbm8830_init':
  atbm8830.c:(.text+0x9012f9): undefined reference to `__udivdi3'
  atbm8830.c:(.text+0x901384): undefined reference to `__floatunsidf'
  atbm8830.c:(.text+0x901395): undefined reference to `__muldf3'
  atbm8830.c:(.text+0x9013a5): undefined reference to `__floatunsidf'
  atbm8830.c:(.text+0x9013b2): undefined reference to `__divdf3'
  atbm8830.c:(.text+0x9013c3): undefined reference to `__muldf3'
  atbm8830.c:(.text+0x9013cd): undefined reference to `__fixunsdfsi'
  
  ---
 This patch replace 64-bit division by do_div() macro and remove usage of 
 floating point variable
 
 Signed-off-by: David T. L. Wong davidtlw...@gmail.com

Acked-by: Randy Dunlap randy.dun...@oracle.com

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

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Emmanuel Fusté

Jon Smirl wrote:
On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson ja...@wilsonet.com wrote:
On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote:
...
Now I understand that if 2 remotes send completely identical signals we
won't be able to separate them, but in cases when we can I think we
should.
I don't have a problem with that, if its a truly desired feature. But
for the most part, I don't see the point. Generally, you go from
having multiple remotes, one per device (where device is your TV,
amplifier, set top box, htpc, etc), to having a single universal remote
that controls all of those devices. But for each device (IR receiver),
*one* IR command set. The desire to use multiple distinct remotes with
a single IR receiver doesn't make sense to me. Perhaps I'm just not
creative enough in my use of IR. :)
Most universal remotes I'm familiar with emulate multiple remotes. I.e.
my tv remote generates one set of scancodes for the numeric keys. The DVD
remote generates a different set. The amplifier remote in tv mode
generates the same codes as the tv remote, and in dvd mode the same codes
as the dvd remote. From the perspective of the IR receiver there is no
difference between having both the DVD and TV remotes, or using the
aplifier remote to control both devices.
Okay, in the above scenario, you've still got a single input device...

Now, my aplifier remote has a number of modes. Some control devices I
have, like vcr mode, and there is nothing I can do about that. Some,
like md mode don't control devices I have. That means they are free to
do things on the computer. Someone else with the same remote (or any
number of remotes that use the same protocol and scancodes) might have
different devices.

So I want my computer to do stuff when I push JVC MD #xx keys, but ignore
JVC VCR #yyy yets. Someone with an MD player and not a VCR would want to
opposite. Rather than force everyone to create custom keymaps, it's much
easier if we can use the standard keymaps from a database of common remotes
and simply tell mythtv to only use remote #xxx or not to use remote #yyy.
Sure, but the key is that this can't be done automagically. The IR driver has no way
of knowing that user A wants JVC MD keys handled and JVC VCR keys ignored, and user B wants
vice versa, while user C wants both ignored, etc. This is somewhat tangential to whether or not
there's a separate input device per remote though. You can use multiple
remotes/protocols with a single input device or lirc device already (if the hardware doesn't
have to be put explicitly into a mode to listen for that proto, of course, but then its a
hardware decoding device feeding a single input device anyway, so...).

It sounds like you're thinking of a receiver that came bundled with a
remote and that's it. Not someone with a number of remotes that came with
different pieces of AV gear that they want to use with their computer.
No, I just pick *one* remote and use it for everything, not
schizophrenically hopping from one remote to another, expecting them all the be able
to control everything. :) Its a hell of a lot easier to find buttons w/o looking at
the remote if you always use the same one for everything, for one.

Anyway, I think I'm talking myself in circles. Supporting multiple remotes
via multiple input devices (or even via a single input device) isn't at all
interesting to me for my own use, but if there really is demand for such support (and
it appears there is), then fine, lets do it.

Simple use case:

You have a multifunction remote. Press the CABLE key - it sends out

commands that control the cable box, press the TV key - now the
commands control the TV, press CD - now the CD player, etc.

Now imagine a headless Linux box running a music server and a home

automation app. Press the CD key - commands get routed to the music
server, press the AUX key - commands get routed to the home automation
app.

This is accomplished by recognizing the device code part of the IR

signal and figuring out that there are two different device codes in
use. The commands of then routed to two evdev devices corresponding to
the two different device codes.

Using things like Alt-Tab to switch apps is impossible. There's no

screen to look at.

This usecase makes sense to me.

With the risk of repeating myself, you don't have two physical remotes.
The needed feature is a way to split one source of input events (that
happens to be an infrared remote, but it could also be any other type of input
device, like a bluetooth remote) into several different evdev interfaces,
based on scancode groups.

In real world you generally have two physical remote. In this particular case
you simply have a sort of semi-universal remote, a two or tree in one remote.
More particularly, you have a remote which is aimed at talking to two or tree different
real devices or in our case different applications. If the application

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Dmitry Torokhov

On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
 Ferenc Wagner wrote:
  Mauro Carvalho Chehab mche...@redhat.com writes:
 
 We should not forget that simple IR's don't have any key to select the 
 address,
 so the produced codes there will never have KEY_TV/KEY_DVD, etc.

Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select
media inputs in a device/application. My receiver accepts codees like
that.

-- 
Dmitry
--
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] What are the goals for the architecture of an in-kernel IR system?

l...@bartelmus.de (Christoph Bartelmus) writes:

 Currently I would tend to an approach like this:
 - raw interface to userspace using LIRC
 - fixed set of in-kernel decoders that can handle bundled remotes

I'd modify it a bit:
- raw interface to userspace using LIRC
- fixed set of in-kernel decoders

Longer term:

Removing the key assignment tables from the kernel. Plug-and-play can be
then achieved with udev. The only thing needed from the kernel is
indicating the tuner/sensor type, udev can guess the bundled remote type.

Porting the in-kernel drivers (such as ir-common) to LIRC interface
(while not removing the input layer mode).
-- 
Krzysztof Halasa
--
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] What are the goals for the architecture of an in-kernel IR system?

Gerd Hoffmann kra...@redhat.com writes:

 I'd pick a more descriptive name like 'bundled_remote'.
 Maybe an additional attribute could say which protocol the bundled
 remote speaks (rc5, ...), so userspace could do something sensible by
 default even if it has no data about the bundled remote.

This is problematic since there can be more that one remote bundled.
If we export the sensor (tuner etc) name, userspace can make some
decision (or ask the user etc).

The protocol alone won't help - the user will have to teach the system
about the remote anyway. This should be made trivial at least for common
protocols, though.

 Name them by the hardware they are bundled with should work reasonable
 well.

I guess udev can look at parent PCI vendor/device and subsystem
vendor/device for most PCI cases. Ditto with USB. For generic stuff like
TSOP* coupled with a resistor and connected to RS232 port, we can't
guess anyway.

 We also could also provide a list of possible remotes directly via
 sysfs

The kernel has no way to _know_ this information. The policy is better
handled in userland.

 Anyway, we shouldn't postpone lirc drivers addition due to that.

Actually merging lirc is a prerequisite for a number of changes.
-- 
Krzysztof Halasa
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-03 Thread Dmitry Torokhov

On Thu, Dec 03, 2009 at 01:09:14PM +0100, Gerd Hoffmann wrote:
 On 12/03/09 05:29, Jarod Wilson wrote:
 On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote:

 Anyway, we shouldn't postpone lirc drivers addition due to that.
 There are still lots of work to do before we'll be able to split
 the tables from the kernel drivers.

 Indeed.  The sysfs bits are future work for both lirc and evdev
 drivers.  There is no reason to make the lirc merge wait for it.

 At this point, my plan is to try to finish cleaning up lirc_dev and
 lirc_mceusb at least over the weekend while at FUDCon up in Toronto,
 and resubmit them next week.

 Good plan IMHO.  Having lirc_dev merged quickly allows in-kernel drivers  
 start supporting lirc.

No, please, wait just a minute. I know it is tempting to just merge
lirc_dev and start working, but can we first agree on the overall
subsystem structure before doing so. It is still quite inclear to me.

The open questions (for me at least):

- do we create a new class infrastructure for all receivers or only for
  ones plugged into lirc_dev? Remember that classifying objects affects
  how udev and friemds see them and may either help or hurt writing PnP
  rules.

- do we intend to support in-kernel sotfware decoders? What is the
  structure? Do we organize them as a module to be used by driver
  directly or the driver streams the data to IR core and the core
  applies decoders (in the same fashion input events from drivers flow
  into input core and then distributed to all bound interfaces for
  processing/conversion/transmission to userspace)?

- how do we control which decoder should handle particular
  receiver/remote? Is it driver's decision, decoder's decision, user's
  or all of the above?

- do we allow to have several decorers active at once for a receiver?

- who decides that we want to utilize lirc_dev? Driver's themselves, IR
  core (looking at the driver/device capabilities), something else?

- do we recognize and create input devices on-fly or require user
  intervention? Semantics for splitting into several input/event
  devices?

Could anyone please draw me a picture, starting with a receiver
piece of hardware. I am not concerned much with how exactly receiver is
plugged into a particular subsystem (DVB/V4L etc) since it would be
_their_ implementation detail, but with the flow in/out of that
receiver device.

Now as far as input core goes I see very limited number of changes that
may be needed:

- Allow to extend size of scancode in EVIOC{S,G}KEYCODE if we are
  unable to limit ourselves to 32 bits (keeping compatibility of course)

- Maybe adding new ioctl to zap the keymap table

- Adding more key EV_KEY/KEY_* definitons, if needed

Thanks.

-- 
Dmitry
--
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 v2] Another approach to IR

2009-12-03 Thread Emmanuel Fusté



Em Thu, 3 Dec 2009 11:50:04 -0500
Jon Smirl jonsm...@gmail.com escreveu:

 On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
  Ferenc Wagner wrote:
  Mauro Carvalho Chehab mche...@redhat.com writes:
 
  Dmitry Torokhov wrote:
 
 
  The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
  KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
  by any remote (ok, I'm stretching it a bit).
 
  Unfortunately, this is not true. Some IR's do send a keycode for 
TV/PC/SAT/CD, etc.
 
  On those remotes, if you press TV and then press for example Channel UP
  and press Radio, then press Channel UP, the channel UP code will be the 
same.
 
  For example, on Hauppauge Grey IR, we have:
 
  TV
  [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
0x1e1c keycode 0x179
  [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=377 down=1
  [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=377 down=0
 
  CHANNEL UP
  [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
0x1e20 keycode 0x192
  [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=402 down=1
  [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=402 down=0
 
  Radio
  [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
0x1e0c keycode 0x181
  [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=385 down=1
  [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=385 down=0
 
  CHANNEL UP
  [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
0x1e20 keycode 0x192
  [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=402 down=1
  [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=402 down=0
 
  In this IR, the address is bogus: it is always 0x1e. This scenario is very 
common with the
  shipped IR's.
 
 The remote is treating everything as a single integrated device which

 is not inconsistent with what has been said. In this case there really
 is only one multi-function device not two independent ones.
 
 If you want to control two independent devices you need to buy a

 different remote. Remotes are cheap so that's not a big deal.
 
 If you really want to use this remote to control two independent

 devices you need user space scripting to split the single device into
 two devices and then inject new events into the input layer. This is a
 complex case and not in the goal of getting 90% of users to just
 work.

This remote is a typical example of the IR's that are provided together with 
media boards.
On all such IR's I know, it does generate one key event for TV, SAT, DVB, 
DVD... keys and
this event doesn't change the status of subsequent keys.

100% of the users of such boards will have the shipped IR. Some amount will be 
happy of
just using the provided IR to control different applications at their computer 
or embedded
hardware, and some amount will prefer to buy a multi-purpose IR that will allow 
him
to control not only his computer, but also, his TV, his Air conditioning, etc.

Both usages should be supported.

All I'm saying is that, in the case where people have only the shipped IR, if 
he wants to
see TV, the produced keycode will be KEY_TV, and then to change a channel, it 
will
receive KEY_CHANNELUP, to control his TV app. When the user decides to switch to DVB, 
he will press KEY_DVB and then KEY_PLAY to play his movie.


So, an application like MythTV should be able to work with those keys.
  

Eeeerrrkkk, what a .. device .
For such quirky device, we could imagine a special mapping support:
We could maps scancode 0x1e1c and 0x1e0c special keycode wich inform the 
input layer to surcharge the  vendor or device with a specific 
value/mask for following  keypresses of such remote. The mask could be 
choose to generate out of bound value in regards of the used protocol 
for the vendor or the device part to not overlap with another existing 
remote.
Generate a complete map and so a device for each special key and you're 
done. No special case on the application side.
In kernel states are a bit ugly, but this particular case is not too 
complicated and your dumb shitty remote is promoted to first class one.



Regards,
Emmanuel.


--
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 v2] Another approach to IR

2009-12-03 Thread Emmanuel Fusté



On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
 Ferenc Wagner wrote:
  Mauro Carvalho Chehab mche...@redhat.com writes:
 
 We should not forget that simple IR's don't have any key to select the address,

 so the produced codes there will never have KEY_TV/KEY_DVD, etc.

Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select
media inputs in a device/application. My receiver accepts codees like
that.
  

Yes, it seem that there is confusion here.
Forget my proposition. It is a corner case that could be handled later 
if needed.



Cheers,
Emmanuel.
--
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 v2] Another approach to IR

Jarod Wilson ja...@wilsonet.com writes:

 Perhaps we should clarify something here. Are we intending to
 auto-create a new input device for every IR command set we see arrive
 at the IR receiver?

We don't want this, and we aren't really able to do this, because we
never know if two different scan codes are part of the same or different
command set.

Sharing the protocol and e.g. group code doesn't mean it's the same
remote.

Different protocol doesn't mean it's a different remote and what's more
important, doesn't mean the user wants it to be a different logical
remote.
-- 
Krzysztof Halasa
--
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 v2] Another approach to IR

Mauro Carvalho Chehab mche...@redhat.com writes:

 Btw, looking at that code, while it is not impossible to split the 
 IR pulse/space measures from the NEC decoder itself, and make it generic
 to support other protocols, it is not a trivial task, and may result on
 a less stable driver.

And it's not needed at all.
Protocol decoders can be easily run in parallel, I've done it on saa713x
and this is trivial at least there. Can do that when the lirc interface
is available.

 The advantage of the NEC decoding approach on saa7134 is that you know for
 sure how much time it is required to get the entire code. So, the code 
 can easily abort the reception of a bad code. The disadvantage is that 
 only one protocol can be decoded at the same time.

This isn't a hard thing to fix.

 The same problem also happens with almost all in-kernel drivers: the decoders
 for raw mode were constructed to work with just one pulse/space code at the
 same time. A conversion into a generic code can happen, but it will require
 several tests to be sure that they won't cause undesirable side-effects.

IOW any such receiver has to be tested, sure.

 The advantage of hardware decoders is that you don't need to be polling the
 IR serial port at a high rate, as you'll get directly the code. So, you'll
 free the CPU to do something else.

Which device requires polling the port?
Most are IRQ-driven, aren't they?
-- 
Krzysztof Halasa
--
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] Document the videobuf layer

2009-12-03 Thread Jonathan Corbet

I've taken the liberty of dropping this into my docs-next tree, and
will send it upward unless there are objections.  Hopefully it's
useful...

jon
---
V4L2: Add a document describing the videobuf layer

Videobuf is a moderately complex API which most V4L2 drivers should use,
but its documentation is...sparse.  This document attempts to improve the
situation.

Signed-off-by: Jonathan Corbet cor...@lwn.net

diff --git a/Documentation/video4linux/videobuf 
b/Documentation/video4linux/videobuf
new file mode 100644
index 000..4e21ea7
--- /dev/null
+++ b/Documentation/video4linux/videobuf
@@ -0,0 +1,341 @@
+An introduction to the videobuf layer
+Jonathan Corbet cor...@lwn.net
+Current as of 2.6.32
+
+The videobuf layer functions as a sort of glue layer between a V4L2 driver
+and user space.  It handles the allocation and management of buffers for
+the storage of video frames.  There is a set of functions which can be used
+to implement many of the standard POSIX I/O system calls, including read(),
+poll(), and, happily, mmap().  Another set of functions can be used to
+implement the bulk of the V4L2 ioctl() calls related to streaming I/O,
+including buffer allocation, queueing and dequeueing, and streaming
+control.  Using videobuf imposes a few design decisions on the driver
+author, but the payback comes in the form of reduced code in the driver and
+a consistent implementation of the V4L2 user-space API.
+
+Buffer types
+
+Not all video devices use the same kind of buffers.  In fact, there are (at
+least) three common variations:
+
+ - Buffers which are scattered in both the physical and (kernel) virtual
+   address spaces.  All user-space buffers are like this, but it makes
+   great sense to allocate kernel-space buffers this way as well when it is
+   possible.  Unfortunately, it is not always possible; working with this
+   kind of buffer normally requires hardware which can do scatter/gather
+   DMA operations.
+
+ - Buffers which are physically scattered, but which are virtually
+   contiguous; buffers allocated with vmalloc(), in other words.  These
+   buffers are just as hard to use for DMA operations, but they can be
+   useful in situations where DMA is not available but virtually-contiguous
+   buffers are convenient.
+
+ - Buffers which are physically contiguous.  Allocation of this kind of
+   buffer can be unreliable on fragmented systems, but simpler DMA
+   controllers cannot deal with anything else.
+
+Videobuf can work with all three types of buffers, but the driver author
+must pick one at the outset and design the driver around that decision.
+
+Data structures, callbacks, and initialization
+
+Depending on which type of buffers are being used, the driver should
+include one of the following files:
+
+media/videobuf-dma-sg.h  /* Physically scattered */
+media/videobuf-vmalloc.h /* vmalloc() buffers*/
+media/videobuf-dma-contig.h  /* Physically contiguous */
+
+The driver's data structure describing a V4L2 device should include a
+struct videobuf_queue instance for the management of the buffer queue,
+along with a list_head for the queue of available buffers.  There will also
+need to be an interrupt-safe spinlock which is used to protect (at least)
+the queue.
+
+The next step is to write four simple callbacks to help videobuf deal with
+the management of buffers:
+
+struct videobuf_queue_ops {
+   int (*buf_setup)(struct videobuf_queue *q,
+unsigned int *count, unsigned int *size);
+   int (*buf_prepare)(struct videobuf_queue *q,
+  struct videobuf_buffer *vb,
+  enum v4l2_field field);
+   void (*buf_queue)(struct videobuf_queue *q,
+ struct videobuf_buffer *vb);
+   void (*buf_release)(struct videobuf_queue *q,
+   struct videobuf_buffer *vb);
+};
+
+buf_setup() is called early in the I/O process, when streaming is being
+initiated; its purpose is to tell videobuf about the I/O stream.  The count
+parameter will be a suggested number of buffers to use; the driver should
+check it for rationality and adjust it if need be.  As a practical rule, a
+minimum of two buffers are needed for proper streaming, and there is
+usually a maximum (which cannot exceed 32) which makes sense for each
+device.  The size parameter should be set to the expected (maximum) size
+for each frame of data.
+
+Each buffer (in the form of a struct videobuf_buffer pointer) will be
+passed to buf_prepare(), which should set the buffer's size, width, height,
+and field fields properly.  If the buffer's state field is
+VIDEOBUF_NEEDS_INIT, the driver should pass it to:
+
+int videobuf_iolock(struct videobuf_queue* q, struct videobuf_buffer *vb,
+   struct v4l2_framebuffer *fbuf);
+
+Among other things, this call will usually allocate memory for the buffer.
+Finally, the buf_setup() function should set the

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

Let me draw my view:

Em Thu, 3 Dec 2009 09:55:31 -0800
Dmitry Torokhov dmitry.torok...@gmail.com escreveu:

 No, please, wait just a minute. I know it is tempting to just merge
 lirc_dev and start working, but can we first agree on the overall
 subsystem structure before doing so. It is still quite inclear to me.
 
 The open questions (for me at least):
 
 - do we create a new class infrastructure for all receivers or only for
   ones plugged into lirc_dev? Remember that classifying objects affects
   how udev and friemds see them and may either help or hurt writing PnP
   rules.

IMO, I would create it as /sys/class/input/IR (just like the /mice). I
don't see why do we need to different lirc than no-lirc drivers in the
case of sysfs class. As devices with raw input capabilities will have
another dev to communicate, this means that we'll need a /lirc node
there to point to lirc dev.

 
 - do we intend to support in-kernel sotfware decoders?

Yes.

 - What is the structure? Do we organize them as a module to be used by driver
   directly or the driver streams the data to IR core and the core
   applies decoders (in the same fashion input events from drivers flow
   into input core and then distributed to all bound interfaces for
   processing/conversion/transmission to userspace)?

My plan is to expand ir-common.ko module and rename it to ir-core, to be 
the IR core module for the evdev interface. I'm already working on it. 
My idea for an architecture is that the lirc-core module will use 
ir-common where the IR decoders will be, and the evdev interface.

IMO, we should move them from /drivers/media/common to /drivers/input/ir.
It makes sense to use kfifo to send the data to the in-kernel decoders.

 - how do we control which decoder should handle particular
   receiver/remote? Is it driver's decision, decoder's decision, user's
   or all of the above?

It should be all the above, since some hardware will only work with certain
decoders (hardware limitation) or they may have already a raw mode-scancode
legacy decoder. In the latter case, those decoders will be removed from
the existing drivers, but this action will take some time.

Some sysfs attributes are needed to specify a list of the supported protocols
and the currently used one. I'll prepare a proposed patch for it, after we
finish aligning the requirements.
 
 - do we allow to have several decorers active at once for a receiver?

Yes, as an optional requirement, since some hardware won't support it.

 - who decides that we want to utilize lirc_dev? Driver's themselves, IR
   core (looking at the driver/device capabilities), something else?

Drivers that support raw mode, should interface via lirc-core, that will,
in turn use ir-core.

Drivers that have in-hardware decode will directly use ir-core.

 - do we recognize and create input devices on-fly or require user
   intervention? Semantics for splitting into several input/event
   devices?

I don't have a strong opinion here. 

I don't see any way for doing it, except with very few protocols that
sends vendor IDs. I don't care if this feature can be used by the
drivers/decoders that could support it.

 Could anyone please draw me a picture, starting with a receiver
 piece of hardware. I am not concerned much with how exactly receiver is
 plugged into a particular subsystem (DVB/V4L etc) since it would be
 _their_ implementation detail, but with the flow in/out of that
 receiver device.

Not sure if I got your idea. Basically, what I see is:

For device drivers that work in raw mode:
[IR physical device] == [IR receiver driver]  == [lirc-core] == [decoder] 
== [ir-core] == [evdev]

(eventually, we can merge decoder and ir-core into one module at the beginning,
depending on the size of the decoders)

For device drivers that work only in evdev mode (those with hardware 
decoders):

[IR physical device] == [IR receiver driver]  == [ir-core] == [evdev]

 
 Now as far as input core goes I see very limited number of changes that
 may be needed:
 
 - Allow to extend size of scancode in EVIOC{S,G}KEYCODE if we are
   unable to limit ourselves to 32 bits (keeping compatibility of course)

Yes, but the way EVIOC{S,G}KEYCODE currently works, it performs poorly when you 
have a
table with 2^64 size. The table is very sparsed, but, as the key to get/set a 
code is
the scancode, it is very hard to enumberate what are the actual entries there. 
The
better is to use an index parameter for they, instead of using the scancode as 
such.

 - Maybe adding new ioctl to zap the keymap table

Yes, this is needed.

 - Adding more key EV_KEY/KEY_* definitons, if needed

Probably.

-- 

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

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-03 Thread Jon Smirl

On Thu, Dec 3, 2009 at 12:55 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
 On Thu, Dec 03, 2009 at 01:09:14PM +0100, Gerd Hoffmann wrote:
 On 12/03/09 05:29, Jarod Wilson wrote:
 On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote:

 Anyway, we shouldn't postpone lirc drivers addition due to that.
 There are still lots of work to do before we'll be able to split
 the tables from the kernel drivers.

 Indeed.  The sysfs bits are future work for both lirc and evdev
 drivers.  There is no reason to make the lirc merge wait for it.

 At this point, my plan is to try to finish cleaning up lirc_dev and
 lirc_mceusb at least over the weekend while at FUDCon up in Toronto,
 and resubmit them next week.

 Good plan IMHO.  Having lirc_dev merged quickly allows in-kernel drivers
 start supporting lirc.

 No, please, wait just a minute. I know it is tempting to just merge
 lirc_dev and start working, but can we first agree on the overall
 subsystem structure before doing so. It is still quite inclear to me.

 The open questions (for me at least):

Great list, good starting point for evaluating the design alternatives.

Have the various use cases all been enumerated?

 - do we create a new class infrastructure for all receivers or only for
  ones plugged into lirc_dev? Remember that classifying objects affects
  how udev and friemds see them and may either help or hurt writing PnP
  rules.

 - do we intend to support in-kernel sotfware decoders? What is the
  structure? Do we organize them as a module to be used by driver
  directly or the driver streams the data to IR core and the core
  applies decoders (in the same fashion input events from drivers flow
  into input core and then distributed to all bound interfaces for
  processing/conversion/transmission to userspace)?

 - how do we control which decoder should handle particular
  receiver/remote? Is it driver's decision, decoder's decision, user's
  or all of the above?

 - do we allow to have several decoders active at once for a receiver?

 - who decides that we want to utilize lirc_dev? Driver's themselves, IR
  core (looking at the driver/device capabilities), something else?

Is the lirc device protocol documented? The lirc device only allows a
single app to read from it, it that ok? What about the problem the
mouse driver had with reading partial messages in one read and by the
time you came back around to read the second half the first read was
overwritten? That led to the transactions in evdev.


 - do we recognize and create input devices on-fly or require user
  intervention? Semantics for splitting into several input/event
  devices?

Complete on-the-fly is not going to do what you want it to. For
example Sony TVs use three variations of the Sony protocol in a single
TV.

A slick solution would have unknown IR events trigger a mapping
definition app via udev. The mapping app would ask you to hit a few
more keys until it locates the corresponding device profile in the IR
database. Then it could write a script which will load create a new
evdev device for this device and load the keycode map for it at boot.

The big IR profile database from All-In-One is published. For this
application you'd need to add entries mapping each IR code to a Linux
keycode. This is the same problem you have with scancodes and various
languages on keyboards. I'll bet the guys at http://www.openremote.org
would help with this.


 Could anyone please draw me a picture, starting with a receiver
 piece of hardware. I am not concerned much with how exactly receiver is
 plugged into a particular subsystem (DVB/V4L etc) since it would be
 _their_ implementation detail, but with the flow in/out of that
 receiver device.

 Now as far as input core goes I see very limited number of changes that
 may be needed:

 - Allow to extend size of scancode in EVIOC{S,G}KEYCODE if we are
  unable to limit ourselves to 32 bits (keeping compatibility of course)

 - Maybe adding new ioctl to zap the keymap table

 - Adding more key EV_KEY/KEY_* definitons, if needed

Aren't EV_IR events needed so that an app for building keymaps can be written?
Normal apps would not use EV_IR events.

-- 
Jon Smirl
jonsm...@gmail.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

V4L1 compatibility broken for VIDIOCGTUNER with radio

2009-12-03 Thread Herton Ronaldo Krzesinski

Hi,

After commit 9bedc7f (V4L/DVB (12429): v4l2-ioctl: fix G_STD and G_PARM 
default handlers), radio software using V4L1 stopped to work on a saa7134 
card, a git bisect pointed to this commit introducing the regression. All 
VIDIOCGTUNER calls on a v4l1 application are returning -EINVAL after this 
commit.

Investigating the issue, it turns out that v4l1_compat_get_tuner calls 
VIDIOC_G_STD ioctl, but as it is a radio device (saa7134-radio) it now is 
returning -EINVAL to user space applications which are being confused about 
this.

May be VIDIOC_G_STD change in the commit above should be reverted, or 
v4l1_compat_get_tuner changed to not return error with G_STD, or not call 
G_STD ioctl for a radio device?

--
[]'s
Herton
--
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] Document the videobuf layer

Jonathan Corbet wrote:
 I've taken the liberty of dropping this into my docs-next tree, and
 will send it upward unless there are objections.  Hopefully it's
 useful...

Hi Jon,

Thanks for the doc!

I'll take a more detailed review, but I've added already some bits about
videobuf at:

Documentation/video4linux/v4l2-framework.txt

Your documentation seems more complete on a very quick view, but it also
seemed to have some duplicated info.

Cheers,
Mauro

 
 jon
 ---
 V4L2: Add a document describing the videobuf layer
 
 Videobuf is a moderately complex API which most V4L2 drivers should use,
 but its documentation is...sparse.  This document attempts to improve the
 situation.
 
 Signed-off-by: Jonathan Corbet cor...@lwn.net
 
 diff --git a/Documentation/video4linux/videobuf 
 b/Documentation/video4linux/videobuf
 new file mode 100644
 index 000..4e21ea7
 --- /dev/null
 +++ b/Documentation/video4linux/videobuf
 @@ -0,0 +1,341 @@
 +An introduction to the videobuf layer
 +Jonathan Corbet cor...@lwn.net
 +Current as of 2.6.32
 +
 +The videobuf layer functions as a sort of glue layer between a V4L2 driver
 +and user space.  It handles the allocation and management of buffers for
 +the storage of video frames.  There is a set of functions which can be used
 +to implement many of the standard POSIX I/O system calls, including read(),
 +poll(), and, happily, mmap().  Another set of functions can be used to
 +implement the bulk of the V4L2 ioctl() calls related to streaming I/O,
 +including buffer allocation, queueing and dequeueing, and streaming
 +control.  Using videobuf imposes a few design decisions on the driver
 +author, but the payback comes in the form of reduced code in the driver and
 +a consistent implementation of the V4L2 user-space API.
 +
 +Buffer types
 +
 +Not all video devices use the same kind of buffers.  In fact, there are (at
 +least) three common variations:
 +
 + - Buffers which are scattered in both the physical and (kernel) virtual
 +   address spaces.  All user-space buffers are like this, but it makes
 +   great sense to allocate kernel-space buffers this way as well when it is
 +   possible.  Unfortunately, it is not always possible; working with this
 +   kind of buffer normally requires hardware which can do scatter/gather
 +   DMA operations.
 +
 + - Buffers which are physically scattered, but which are virtually
 +   contiguous; buffers allocated with vmalloc(), in other words.  These
 +   buffers are just as hard to use for DMA operations, but they can be
 +   useful in situations where DMA is not available but virtually-contiguous
 +   buffers are convenient.
 +
 + - Buffers which are physically contiguous.  Allocation of this kind of
 +   buffer can be unreliable on fragmented systems, but simpler DMA
 +   controllers cannot deal with anything else.
 +
 +Videobuf can work with all three types of buffers, but the driver author
 +must pick one at the outset and design the driver around that decision.
 +
 +Data structures, callbacks, and initialization
 +
 +Depending on which type of buffers are being used, the driver should
 +include one of the following files:
 +
 +media/videobuf-dma-sg.h/* Physically scattered */
 +media/videobuf-vmalloc.h   /* vmalloc() buffers*/
 +media/videobuf-dma-contig.h/* Physically contiguous */
 +
 +The driver's data structure describing a V4L2 device should include a
 +struct videobuf_queue instance for the management of the buffer queue,
 +along with a list_head for the queue of available buffers.  There will also
 +need to be an interrupt-safe spinlock which is used to protect (at least)
 +the queue.
 +
 +The next step is to write four simple callbacks to help videobuf deal with
 +the management of buffers:
 +
 +struct videobuf_queue_ops {
 + int (*buf_setup)(struct videobuf_queue *q,
 +  unsigned int *count, unsigned int *size);
 + int (*buf_prepare)(struct videobuf_queue *q,
 +struct videobuf_buffer *vb,
 +enum v4l2_field field);
 + void (*buf_queue)(struct videobuf_queue *q,
 +   struct videobuf_buffer *vb);
 + void (*buf_release)(struct videobuf_queue *q,
 + struct videobuf_buffer *vb);
 +};
 +
 +buf_setup() is called early in the I/O process, when streaming is being
 +initiated; its purpose is to tell videobuf about the I/O stream.  The count
 +parameter will be a suggested number of buffers to use; the driver should
 +check it for rationality and adjust it if need be.  As a practical rule, a
 +minimum of two buffers are needed for proper streaming, and there is
 +usually a maximum (which cannot exceed 32) which makes sense for each
 +device.  The size parameter should be set to the expected (maximum) size
 +for each frame of data.
 +
 +Each buffer (in the form of a struct videobuf_buffer pointer) will be
 +passed to buf_prepare(), which should set the

RE: [PATCH 2/2] DaVinci - vpfe capture - converting ccdc to platform driver


 -/*
 - * setup Mux configuration for vpfe input and register
 - * vpfe capture platform device
 - */
 -davinci_cfg_reg(DM355_VIN_PCLK);
 -davinci_cfg_reg(DM355_VIN_CAM_WEN);
 -davinci_cfg_reg(DM355_VIN_CAM_VD);
 -davinci_cfg_reg(DM355_VIN_CAM_HD);
 -davinci_cfg_reg(DM355_VIN_YIN_EN);
 -davinci_cfg_reg(DM355_VIN_CINL_EN);
 -davinci_cfg_reg(DM355_VIN_CINH_EN);
[Hiremath, Vaibhav] Why have you removed mux configuration from here and
moved to CCDC driver? Any specific reason?

Good catch. I wanted to do this clean up, but missed it. Actually platform data 
should have a function setup_pinmux() to set up the pin mux for the
ccdc input. This function will be defined in the platform file and will be
called during probe()

Murali
 +platform_device_register(dm355_ccdc_dev);
  platform_device_register(vpfe_capture_dev);

  return 0;
 diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-
 davinci/dm644x.c
 index 2cd0081..982be1f 100644
 --- a/arch/arm/mach-davinci/dm644x.c
 +++ b/arch/arm/mach-davinci/dm644x.c
 @@ -612,6 +612,11 @@ static struct resource vpfe_resources[] = {
  .end= IRQ_VDINT1,
  .flags  = IORESOURCE_IRQ,
  },
 +};
 +
 +static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
 +static struct resource dm644x_ccdc_resource[] = {
 +/* CCDC Base address */
  {
  .start  = 0x01c70400,
  .end= 0x01c70400 + 0xff,
 @@ -619,7 +624,17 @@ static struct resource vpfe_resources[] = {
  },
  };

 -static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
 +static struct platform_device dm644x_ccdc_dev = {
 +.name   = dm644x_ccdc,
 +.id = -1,
 +.num_resources  = ARRAY_SIZE(dm644x_ccdc_resource),
 +.resource   = dm644x_ccdc_resource,
 +.dev = {
 +.dma_mask   = vpfe_capture_dma_mask,
 +.coherent_dma_mask  = DMA_BIT_MASK(32),
 +},
 +};
 +
  static struct platform_device vpfe_capture_dev = {
  .name   = CAPTURE_DRV_NAME,
  .id = -1,
 @@ -772,6 +787,7 @@ static int __init dm644x_init_devices(void)
  platform_device_register(dm644x_edma_device);
  platform_device_register(dm644x_emac_device);
  platform_device_register(dm644x_vpss_device);
 +platform_device_register(dm644x_ccdc_dev);
  platform_device_register(vpfe_capture_dev);

  return 0;
 --
 1.6.0.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

Re: [RFC v2] Another approach to IR

2009-12-03 Thread alhaz


Quoting Jon Smirl jonsm...@gmail.com:


Now I understand that if 2 remotes send completely identical signals we
won't be able to separate them, but in cases when we can I think we
should.


I don't have a problem with that, if its a truly desired feature.   
But for the most part, I don't see the point. Generally, you go   
from having multiple remotes, one per device (where device is   
your TV, amplifier, set top box, htpc, etc), to having a single   
universal remote that controls all of those devices. But for each   
device (IR receiver), *one* IR command set. The desire to use   
multiple distinct remotes with a single IR receiver doesn't make   
sense to me. Perhaps I'm just not creative enough in my use of IR. :)


From a hobbiest's perspective there's likely rarely any reason to be  
able to do the same thing with two different remotes that send  
different signals, but i could see it come up - For example if you  
wanted to have both a feature-rich,  busy/complicated remote but also  
wanted to provide a simpler remote with a relatively small number of  
large buttons on it for basic functions, as for children or people  
with poor eyesight or poor motor control.


From a business perspective, I've worked for a company that sold  
turn-key video training systems, and depending on the whims of our  
so-called business partners and the desires of customers, there were  
as many as three distinct remotes that might get shipped with the  
training system, and they all sent different signals.


That was a less than ideal situation, and if we had been really on top  
of things we'd have just declined to use any of those remotes and  
bought custom remotes from any of the numerous vendors that sell them  
which would allow us to have one set of IR signals used by remotes  
with different features - but for whatever reason that wasn't how  
management decided to do things.

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

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

2009-12-03 Thread Hans Verkuil

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

Results of the daily build of v4l-dvb:

date:Thu Dec  3 19:00:03 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   13538:e0cd9a337600
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

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

Detailed results are available here:

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

Full logs are available here:

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

RE: [PATCH v0 1/2] V4L - vpfe capture - convert ccdc drivers to platform drivers


 +#include mach/mux.h
[Hiremath, Vaibhav] This should not be here, this should get handled in
board file. The driver should be generic.

See my comments against the platform part of this patch.

  #include media/davinci/dm355_ccdc.h
  #include media/davinci/vpss.h
  #include dm355_ccdc_regs.h
 @@ -105,7 +106,6 @@ static struct ccdc_params_ycbcr
 ccdc_hw_params_ycbcr = {

  static enum vpfe_hw_if_type ccdc_if_type;
  static void *__iomem ccdc_base_addr;
 -static int ccdc_addr_size;

  /* Raw Bayer formats */
  static u32 ccdc_raw_bayer_pix_formats[] =
 @@ -126,12 +126,6 @@ static inline void regw(u32 val, u32 offset)
  __raw_writel(val, ccdc_base_addr + offset);
  }

 -static void ccdc_set_ccdc_base(void *addr, int size)
 -{
 -ccdc_base_addr = addr;
 -ccdc_addr_size = size;
 -}
 -
  static void ccdc_enable(int en)
  {
  unsigned int temp;
 @@ -938,7 +932,6 @@ static struct ccdc_hw_device ccdc_hw_dev = {
  .hw_ops = {
  .open = ccdc_open,
  .close = ccdc_close,
 -.set_ccdc_base = ccdc_set_ccdc_base,
  .enable = ccdc_enable,
  .enable_out_to_sdram = ccdc_enable_output_to_sdram,
  .set_hw_if_params = ccdc_set_hw_if_params,
 @@ -959,19 +952,89 @@ static struct ccdc_hw_device ccdc_hw_dev = {
  },
  };

 -static int __init dm355_ccdc_init(void)
 +static int __init dm355_ccdc_probe(struct platform_device *pdev)
  {
 -printk(KERN_NOTICE dm355_ccdc_init\n);
 -if (vpfe_register_ccdc_device(ccdc_hw_dev)  0)
 -return -1;
 +static resource_size_t  res_len;
 +struct resource *res;
 +int status = 0;
 +
 +/**
 + * first try to register with vpfe. If not correct platform,
 then we
 + * don't have to iomap
 + */
 +status = vpfe_register_ccdc_device(ccdc_hw_dev);
 +if (status  0)
 +return status;
 +
 +res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 +if (!res) {
 +status = -ENOENT;
[Hiremath, Vaibhav] I think right return value is -ENODEV.

Right. I will change it.

 +goto fail_nores;
 +}
 +res_len = res-end - res-start + 1;
 +
 +res = request_mem_region(res-start, res_len, res-name);
[Hiremath, Vaibhav] You should use resource_size here for res_len here.
Ok. I didn't know about such a function :(

Will change res_len - resource_size(res)


 +if (!res) {
 +status = -EBUSY;
 +goto fail_nores;
 +}
 +
 +ccdc_base_addr = ioremap_nocache(res-start, res_len);
 +if (!ccdc_base_addr) {
 +status = -EBUSY;
[Hiremath, Vaibhav] Is -EBUSY right return value, I think it should be -
ENXIO or -ENOMEM.

I see -ENXIO  -ENOMEM being used by drivers. -ENXIO stands for No such device 
or address. ENOMEM stands for Out of memory . Since we are trying to map the 
address here, -ENXIO looks reasonable to me. Same if request_mem_region() fails.
 
 +goto fail;
 +}
 +/**
 + * setup Mux configuration for vpfe input and register
 + * vpfe capture platform device
 + */
 +davinci_cfg_reg(DM355_VIN_PCLK);
 +davinci_cfg_reg(DM355_VIN_CAM_WEN);
 +davinci_cfg_reg(DM355_VIN_CAM_VD);
 +davinci_cfg_reg(DM355_VIN_CAM_HD);
 +davinci_cfg_reg(DM355_VIN_YIN_EN);
 +davinci_cfg_reg(DM355_VIN_CINL_EN);
 +davinci_cfg_reg(DM355_VIN_CINH_EN);
 +
[Hiremath, Vaibhav] This should not be here, this code must be generic and
might get used in another SoC.
yes. See my suggestion against the architecture part. will be replaced
with a setup_pinmux() fuction from platform_data. 

  printk(KERN_NOTICE %s is registered with vpfe.\n,
  ccdc_hw_dev.name);
  return 0;
 +fail:
 +release_mem_region(res-start, res_len);
 +fail_nores:
 +vpfe_unregister_ccdc_device(ccdc_hw_dev);
 +return status;
  }

 -static void __exit dm355_ccdc_exit(void)
 +static int dm355_ccdc_remove(struct platform_device *pdev)
  {
 +struct resource *res;
 +
 +iounmap(ccdc_base_addr);
 +res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 +if (res)
 +release_mem_region(res-start, res-end - res-start +
 1);
[Hiremath, Vaibhav] Please use resource_size here for size.
Ok.

  vpfe_unregister_ccdc_device(ccdc_hw_dev);
 +return 0;
 +}
 +
 +static struct platform_driver dm355_ccdc_driver = {
 +.driver = {
 +.name   = dm355_ccdc,
 +.owner = THIS_MODULE,
 +},
 +.remove = __devexit_p(dm355_ccdc_remove),
 +.probe = dm355_ccdc_probe,
 +};
 +
 +static int __init dm355_ccdc_init(void)
 +{
 +return platform_driver_register(dm355_ccdc_driver);
 +}
 +
 +static void __exit dm355_ccdc_exit(void)
 +{
 +platform_driver_unregister(dm355_ccdc_driver);
  }

  module_init(dm355_ccdc_init);
 diff --git a/drivers/media/video/davinci/dm644x_ccdc.c
 b/drivers/media/video/davinci/dm644x_ccdc.c
 index d5fa193..89ea6ae 100644
 --- a/drivers/media/video/davinci/dm644x_ccdc.c
 +++

[PATCH -v2] Adding helper function to get dv preset description

2009-12-03 Thread m-karicheri2

From: Muralidharan Karicheri m-kariche...@ti.com

Updated based on comments against v1 of the patch

This patch adds a helper function to get description of a digital
video preset added by the video timing API. This will be usefull for drivers
implementing the above API.

NOTE: depends on the patch that adds video timing API.

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
---
Applies to V4L-DVB linux-next branch
 drivers/media/video/v4l2-common.c |   47 +
 include/media/v4l2-common.h   |2 +-
 2 files changed, 48 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/v4l2-common.c 
b/drivers/media/video/v4l2-common.c
index e8e5aff..36b5cb8 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -1024,3 +1024,50 @@ void v4l_bound_align_image(u32 *w, unsigned int wmin, 
unsigned int wmax,
}
 }
 EXPORT_SYMBOL_GPL(v4l_bound_align_image);
+
+/**
+ * v4l_fill_dv_preset_info - fill description of a digital video preset
+ * @preset - preset value
+ * @info - pointer to struct v4l2_dv_enum_preset
+ *
+ * drivers can use this helper function to fill description of dv preset
+ * in info.
+ */
+int v4l_fill_dv_preset_info(u32 preset, struct v4l2_dv_enum_preset *info)
+{
+   static const struct v4l2_dv_preset_info {
+   u16 width;
+   u16 height;
+   const char *name;
+   } dv_presets[] = {
+   { 0, 0, Invalid },/* V4L2_DV_INVALID */
+   { 720,  480, 4...@59.94 },/* V4L2_DV_480P59_94 */
+   { 720,  576, 5...@50 },   /* V4L2_DV_576P50 */
+   { 1280, 720, 7...@24 },   /* V4L2_DV_720P24 */
+   { 1280, 720, 7...@25 },   /* V4L2_DV_720P25 */
+   { 1280, 720, 7...@30 },   /* V4L2_DV_720P30 */
+   { 1280, 720, 7...@50 },   /* V4L2_DV_720P50 */
+   { 1280, 720, 7...@59.94 },/* V4L2_DV_720P59_94 */
+   { 1280, 720, 7...@60 },   /* V4L2_DV_720P60 */
+   { 1920, 1080, 10...@29.97 },  /* V4L2_DV_1080I29_97 */
+   { 1920, 1080, 10...@30 }, /* V4L2_DV_1080I30 */
+   { 1920, 1080, 10...@25 }, /* V4L2_DV_1080I25 */
+   { 1920, 1080, 10...@50 }, /* V4L2_DV_1080I50 */
+   { 1920, 1080, 10...@60 }, /* V4L2_DV_1080I60 */
+   { 1920, 1080, 10...@24 }, /* V4L2_DV_1080P24 */
+   { 1920, 1080, 10...@25 }, /* V4L2_DV_1080P25 */
+   { 1920, 1080, 10...@30 }, /* V4L2_DV_1080P30 */
+   { 1920, 1080, 10...@50 }, /* V4L2_DV_1080P50 */
+   { 1920, 1080, 10...@60 }, /* V4L2_DV_1080P60 */
+   };
+
+   if (info == NULL || preset = ARRAY_SIZE(dv_presets))
+   return -EINVAL;
+
+   info-preset = preset;
+   info-width = dv_presets[preset].width;
+   info-height = dv_presets[preset].height;
+   strlcpy(info-name, dv_presets[preset].name, sizeof(info-name));
+   return 0;
+}
+EXPORT_SYMBOL_GPL(v4l_fill_dv_preset_info);
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index 1c25b10..1c7b259 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -212,5 +212,5 @@ void v4l_bound_align_image(unsigned int *w, unsigned int 
wmin,
   unsigned int *h, unsigned int hmin,
   unsigned int hmax, unsigned int halign,
   unsigned int salign);
-
+int v4l_fill_dv_preset_info(u32 preset, struct v4l2_dv_enum_preset *info);
 #endif /* V4L2_COMMON_H_ */
-- 
1.6.0.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

RE: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable

Hans,

Please hold on to this. I will send you an updated patch.

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

-Original Message-
From: Karicheri, Muralidharan
Sent: Tuesday, December 01, 2009 12:22 PM
To: 'Hans Verkuil'
Cc: Hiremath, Vaibhav; linux-media@vger.kernel.org
Subject: FW: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable

Hans,

Could you please add this to your hg tree and send a pull
request to Mauro? This was reviewed by Vaibhav and tested on
DM355, DM6446, AM3517  DM365. I will request Kevin to pull
the Architecture part of this patch.

Thanks.

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

-Original Message-
From: Karicheri, Muralidharan
Sent: Tuesday, December 01, 2009 12:19 PM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Hiremath, Vaibhav;
Karicheri, Muralidharan
Subject: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable

From: Muralidharan Karicheri m-kariche...@ti.com

v1  - updated based on comments from Vaibhav Hiremath.

On DM365 we use only vpss master clock, where as on DM355 and
DM6446, we use vpss master and slave clocks for vpfe capture and AM3517
we use internal clock and pixel clock. So this patch makes it configurable
on a per platform basis. This is needed for supporting DM365 for which
patches
will be available soon.

Tested-by: Vaibhav Hiremath hvaib...@ti.com, Muralidharan Karicheri m-
kariche...@ti.com
Acked-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
 drivers/media/video/davinci/vpfe_capture.c |   98 +--
-
---
 include/media/davinci/vpfe_capture.h   |   11 ++-
 2 files changed, 70 insertions(+), 39 deletions(-)

diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 12a1b3d..c3468ee 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -1787,61 +1787,87 @@ static struct vpfe_device *vpfe_initialize(void)
  return vpfe_dev;
 }

+/**
+ * vpfe_disable_clock() - Disable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Disables clocks defined in vpfe configuration.
+ */
 static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
 {
  struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
+ int i;

- clk_disable(vpfe_cfg-vpssclk);
- clk_put(vpfe_cfg-vpssclk);
- clk_disable(vpfe_cfg-slaveclk);
- clk_put(vpfe_cfg-slaveclk);
- v4l2_info(vpfe_dev-pdev-driver,
-  vpfe vpss master  slave clocks disabled\n);
+ for (i = 0; i  vpfe_cfg-num_clocks; i++) {
+ clk_disable(vpfe_dev-clks[i]);
+ clk_put(vpfe_dev-clks[i]);
+ }
+ kfree(vpfe_dev-clks);
+ v4l2_info(vpfe_dev-pdev-driver, vpfe capture clocks disabled\n);
 }

+/**
+ * vpfe_enable_clock() - Enable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Enables clocks defined in vpfe configuration. The function
+ * assumes that at least one clock is to be defined which is
+ * true as of now. re-visit this if this assumption is not true
+ */
 static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
 {
  struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
- int ret = -ENOENT;
+ int i;

- vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
- if (NULL == vpfe_cfg-vpssclk) {
- v4l2_err(vpfe_dev-pdev-driver, No clock defined for
-  vpss_master\n);
- return ret;
- }
+ if (!vpfe_cfg-num_clocks)
+ return 0;

- if (clk_enable(vpfe_cfg-vpssclk)) {
- v4l2_err(vpfe_dev-pdev-driver,
- vpfe vpss master clock not enabled\n);
- goto out;
- }
- v4l2_info(vpfe_dev-pdev-driver,
-  vpfe vpss master clock enabled\n);
+ vpfe_dev-clks = kzalloc(vpfe_cfg-num_clocks *
+sizeof(struct clock *), GFP_KERNEL);

- vpfe_cfg-slaveclk = clk_get(vpfe_dev-pdev, vpss_slave);
- if (NULL == vpfe_cfg-slaveclk) {
- v4l2_err(vpfe_dev-pdev-driver,
- No clock defined for vpss slave\n);
- goto out;
+ if (NULL == vpfe_dev-clks) {
+ v4l2_err(vpfe_dev-pdev-driver, Memory allocation failed\n);
+ return -ENOMEM;
  }

- if (clk_enable(vpfe_cfg-slaveclk)) {
- v4l2_err(vpfe_dev-pdev-driver,
-  vpfe vpss slave clock not enabled\n);
- goto out;
+ for (i = 0; i  vpfe_cfg-num_clocks; i++) {
+ if (NULL == vpfe_cfg-clocks[i]) {
+ v4l2_err(vpfe_dev-pdev-driver,
+ clock %s is not defined in vpfe

How to help with RTL2832U based TV?

2009-12-03 Thread Peter Rasmussen


I looked around in the archives of:

http://dir.gmane.org/gmane.linux.drivers.video-input-infrastructure
http://www.spinics.net/lists/linux-media/

as mentioned in the welcome email of this list, but it isn't apparent to me 
what the status in Linux of using a device based on this chip is?


When inserting the USB dongle I get the following:

Dec  3 20:56:22 kultorvet kernel: usb 1-1: new high speed USB device 
using ehci_hcd and address 5
Dec  3 20:56:22 kultorvet kernel: usb 1-1: New USB device found, 
idVendor=1d19, idProduct=1102
Dec  3 20:56:22 kultorvet kernel: usb 1-1: New USB device strings: 
Mfr=1, Product=2, SerialNumber=3

Dec  3 20:56:22 kultorvet kernel: usb 1-1: Product: Rtl2832UDVB
Dec  3 20:56:22 kultorvet kernel: usb 1-1: Manufacturer: Realtek
Dec  3 20:56:22 kultorvet kernel: usb 1-1: SerialNumber: 1
Dec  3 20:56:22 kultorvet kernel: usb 1-1: configuration #1 chosen from 
1 choice


In Windows Vista it runs fine, showing TV using both MPEG2 and MPEG4 
encoded signals, but I would much rather run it with Linux.


I am also developing software for a living, but not this close to 
hardware, however I would like to help out the way I can.


Thanks,
Peter
--
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 v2] Another approach to IR

Krzysztof Halasa wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 
 Btw, looking at that code, while it is not impossible to split the 
 IR pulse/space measures from the NEC decoder itself, and make it generic
 to support other protocols, it is not a trivial task, and may result on
 a less stable driver.
 
 And it's not needed at all.
 Protocol decoders can be easily run in parallel, I've done it on saa713x
 and this is trivial at least there. Can do that when the lirc interface
 is available.

 The advantage of the NEC decoding approach on saa7134 is that you know for
 sure how much time it is required to get the entire code. So, the code 
 can easily abort the reception of a bad code. The disadvantage is that 
 only one protocol can be decoded at the same time.
 
 This isn't a hard thing to fix.

Good to know. We're open to patches to improve it. 

The point is that we've got in the past several complains about saa713x
machines hanging due to IRQ's generated by IR sensor port. We ended by adding
an option to disable IR and a code at the driver that disables IR IRQ if it 
happens too often.

 
 The same problem also happens with almost all in-kernel drivers: the decoders
 for raw mode were constructed to work with just one pulse/space code at the
 same time. A conversion into a generic code can happen, but it will require
 several tests to be sure that they won't cause undesirable side-effects.
 
 IOW any such receiver has to be tested, sure.
 
 The advantage of hardware decoders is that you don't need to be polling the
 IR serial port at a high rate, as you'll get directly the code. So, you'll
 free the CPU to do something else.
 
 Which device requires polling the port?
 Most are IRQ-driven, aren't they?

Most of the devices that have a hardware IR decodes needs polling. Most of they
simply outputs the scan code on some set of GPIO pins.

In general, the devices with the IR sensor connected to a GPIO pin are 
IRQ-driven.

Cheers,
Mauro.



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

Re: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c

2009-12-03 Thread Alan Stern

On Wed, 2 Dec 2009, Sean wrote:

 Is there anything I can do to help? This is a show stopping bug for me.

Here's a patch you can try.  It will add a _lot_ of debugging
information to the system log.  Maybe it will help pin down the source
of the problem.

Alan Stern



Index: 2.6.31/drivers/usb/host/ohci-hcd.c
===
--- 2.6.31.orig/drivers/usb/host/ohci-hcd.c
+++ 2.6.31/drivers/usb/host/ohci-hcd.c
@@ -197,7 +197,7 @@ static int ohci_urb_enqueue (
 
/* allocate the TDs (deferring hash chain updates) */
for (i = 0; i  size; i++) {
-   urb_priv-td [i] = td_alloc (ohci, mem_flags);
+   urb_priv-td [i] = td_alloc (ohci, mem_flags, urb-dev, 
urb-ep);
if (!urb_priv-td [i]) {
urb_priv-length = i;
urb_free_priv (ohci, urb_priv);
Index: 2.6.31/drivers/usb/host/ohci-mem.c
===
--- 2.6.31.orig/drivers/usb/host/ohci-mem.c
+++ 2.6.31/drivers/usb/host/ohci-mem.c
@@ -82,7 +82,8 @@ dma_to_td (struct ohci_hcd *hc, dma_addr
 
 /* TDs ... */
 static struct td *
-td_alloc (struct ohci_hcd *hc, gfp_t mem_flags)
+td_alloc (struct ohci_hcd *hc, gfp_t mem_flags, struct usb_device *udev,
+   struct usb_host_endpoint *ep)
 {
dma_addr_t  dma;
struct td   *td;
@@ -94,6 +95,8 @@ td_alloc (struct ohci_hcd *hc, gfp_t mem
td-hwNextTD = cpu_to_hc32 (hc, dma);
td-td_dma = dma;
/* hashed in td_fill */
+   ohci_info(hc, td alloc for %s ep%x: %p\n,
+   udev-devpath, ep-desc.bEndpointAddress, td);
}
return td;
 }
@@ -103,8 +106,14 @@ td_free (struct ohci_hcd *hc, struct td 
 {
struct td   **prev = hc-td_hash [TD_HASH_FUNC (td-td_dma)];
 
-   while (*prev  *prev != td)
+   ohci_info(hc, td free %p\n, td);
+   while (*prev  *prev != td) {
+   if ((unsigned long) *prev == 0xa7a7a7a7) {
+   ohci_info(hc, poisoned hash at %p\n, prev);
+   return;
+   }
prev = (*prev)-td_hash;
+   }
if (*prev)
*prev = td-td_hash;
else if ((td-hwINFO  cpu_to_hc32(hc, TD_DONE)) != 0)
Index: 2.6.31/drivers/usb/host/ohci-q.c
===
--- 2.6.31.orig/drivers/usb/host/ohci-q.c
+++ 2.6.31/drivers/usb/host/ohci-q.c
@@ -403,7 +403,7 @@ static struct ed *ed_get (
}
 
/* dummy td; end of td list for ed */
-   td = td_alloc (ohci, GFP_ATOMIC);
+   td = td_alloc (ohci, GFP_ATOMIC, udev, ep);
if (!td) {
/* out of memory */
ed_free (ohci, ed);

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

test

2009-12-03 Thread desmono

test

--
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: Replace Mercurial with GIT as SCM

2009-12-03 Thread Guennadi Liakhovetski

On Thu, 3 Dec 2009, Hans Verkuil wrote:

 On Wednesday 02 December 2009 04:55:00 Andy Walls wrote:
  On Tue, 2009-12-01 at 15:59 +0100, Patrick Boettcher wrote:
   Hi all,
  
   I would like to start a discussion which ideally results in either
   changing the SCM of v4l-dvb to git _or_ leaving everything as it is today
   with mercurial.
  
  
   I'm waiting for comments.
 
  I only have one requirement: reduce bandwidth usage between the server
  and my home.
 
  The less I have to clone out 65 M of history to start a new series of
  patches the better.  I suppose that would include a rebase...
 
 Unfortunately, one reason for moving to git would be to finally be able to 
 make changes to the arch directory tree. The fact that that part is 
 unavailable in v4l-dvb is a big problem when working with SoCs. And these 
 will 
 become much more important in the near future.

FWIW, tomorrow (or a day or two later) I'll have to spend time again 
back-porting arch changes from git to hg, to be able to push my current 
patches...

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: af9015: tuner id:179 not supported, please report!

2009-12-03 Thread Bert Massop

Hi Jan,

The datasheet for the TDA18218 can be obtained from NXP:
http://www.nxp.com/documents/data_sheet/TDA18218HN.pdf

That's all the information I have at the moment, maybe Mike has some
other information (like the Application Note mentioned in the
datasheet, that claims to contain information on writing drivers, but
cannot be found anywhere).

Best regards,

Bert

On Thu, Dec 3, 2009 at 22:15, Jan Sundman jan.sund...@aland.net wrote:

 Hi Bert and Mike,

 The information that you have regarding the TDA18218, where can I get my
 hands on that? It would be interesting to take a shot at writing the
 driver, but I guess I would need some pointers in the right direction.

 Would it be possible to get the information from you, or is such
 information freely available on the internet? Where should I start
 looking?

 Best regards,

 //Jan

 On Wed, 2009-12-02 at 18:08 -0500, Michael Krufky wrote:
  On Wed, Dec 2, 2009 at 5:06 PM, Bert Massop bert.mas...@gmail.com wrote:
   Jan Sundman jan.sundman at aland.net writes:
  
  
   Hi,
  
   I just received a usb DVB-T card and have been trying to get it to work
   under Ubuntu 9.10, but to no avail. dmesg shows the following when
   plugging in the card:
  
   [   35.280024] usb 2-1: new high speed USB device using ehci_hcd and
   address 4
   [   35.435978] usb 2-1: configuration #1 chosen from 1 choice
   [   35.450176] af9015: tuner id:179 not supported, please report!
   [   35.452891] Afatech DVB-T 2: Fixing fullspeed to highspeed interval:
   10 - 7
   [   35.453097] input: Afatech DVB-T 2
   as /devices/pci:00/:00:13.2/usb2/2-1/2-1:1.1/input/input8
   [   35.453141] generic-usb 0003:15A4:9016.0005: input,hidraw3: USB HID
   v1.01 Keyboard [Afatech DVB-T 2] on usb-:00:13.2-1/input1
  
   lsusb shows:
   Bus 002 Device 005: ID 15a4:9016
  
   and finally lsmod | grep dvb
   dvb_usb_af9015         37152  0
   dvb_usb                22892  1 dvb_usb_af9015
   dvb_core              109716  1 dvb_usb
  
   While googling for an answer to my troubles I came across
   http://ubuntuforums.org/showthread.php?t=606487page=5 which hints that
   the card may use the TDA18218HK tuner chip which does not seem to be
   supported currently.
  
   Does anyone have any experience regarding this chip and know what to do
   to get it working.
  
   Best regards,
  
   //Jan
  
  
  
   Hi Jan,
  
   As stated in the Ubuntuforums thread, there doesn't seem to be any 
   support for
   this chip at the moment. I don't know how hard it is to code support for a
   specific tuner, but I'm looking into that right now.
  
   Hopefully some more experienced coders will join in writing something 
   usable, as
   I don't think I will be able to do it myself.
  
   Please drop a message if anyone finds something useful.
  
   Best regards,
  
   Bert
 
  The TDA18218 is not currently supported under Linux.  I have the
  information needed to write a driver to support it, but I do not have
  any devices that use it, nor any interest (as of now) to write the
  driver on my own time.
 
  For me, it would not be very difficult to get this done, as I have
  done work to support a similar family of tuners -- TDA18271 /
  TDA18211.  The TDA18218 tuner is not supported by the current driver.
 
  In the past, I would have gone ahead and written a driver for the
  sheer enjoyment of doing so... but nowadays, I actually have other
  projects of a higher priority that need my attention instead.
 
  If, in the future, any commercial entity has interest in seeing this
  tuner silicon supported under Linux, they should contact me -- perhaps
  my desire to write this driver can be increased ;-)
 
  Regards,
 
  Mike Krufky
  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


 --
 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: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-03 Thread Christoph Bartelmus

Hi Mauro,

on 03 Dec 09 at 19:10, Mauro Carvalho Chehab wrote:
[...]
 So the lirc_imon I submitted supports all device types, with the
 onboard decode devices defaulting to operating as pure input devices,
 but an option to pass hex values out via the lirc interface (which is
 how they've historically been used -- the pure input stuff I hacked
 together just a few weeks ago), to prevent functional setups from
 being broken for those who prefer the lirc way.

 Hmm.  I'd tend to limit the lirc interface to the 'raw samples' case.

 Historically it has also been used to pass decoded data (i.e. rc5) from
 devices with onboard decoding, but for that in-kernel mapping + input
 layer really fits better.

 I agree.

Consider passing the decoded data through lirc_dev.
- there's a large user base already that uses this mode through lirc and  
would be forced to switch to input layer if it disappears.
- that way all IR drivers would consistently use lirc interface and all  
PnP hooks could be implemented there in one place.
- drivers like lirc_imon that have to support both raw and decoded mode,  
currently have to implement both the lirc and the input interface.  
Complexity could be reduced in such cases. But maybe this is necessary  
anyway for lirc_imon that also includes mouse functionality. Jarod?

Christoph
--
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: af9015: tuner id:179 not supported, please report!

2009-12-03 Thread Devin Heitmueller

On Thu, Dec 3, 2009 at 4:47 PM, Bert Massop bert.mas...@gmail.com wrote:
 Hi Jan,

 The datasheet for the TDA18218 can be obtained from NXP:
 http://www.nxp.com/documents/data_sheet/TDA18218HN.pdf

 That's all the information I have at the moment, maybe Mike has some
 other information (like the Application Note mentioned in the
 datasheet, that claims to contain information on writing drivers, but
 cannot be found anywhere).

 Best regards,

 Bert

Took a quick look at that datasheet.  I would guess between that
datasheet and a usbsnoop, there is probably enough there to write a
driver that basically works for your particular hardware if you know
what you are doing.  The register map is abbreviated, but probably
good enough...

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: V4L1 compatibility broken for VIDIOCGTUNER with radio

2009-12-03 Thread hermann pitton

Hi,

Am Donnerstag, den 03.12.2009, 16:56 -0200 schrieb Herton Ronaldo
Krzesinski:
 Hi,
 
 After commit 9bedc7f (V4L/DVB (12429): v4l2-ioctl: fix G_STD and G_PARM 
 default handlers), radio software using V4L1 stopped to work on a saa7134 
 card, a git bisect pointed to this commit introducing the regression. All 
 VIDIOCGTUNER calls on a v4l1 application are returning -EINVAL after this 
 commit.
 
 Investigating the issue, it turns out that v4l1_compat_get_tuner calls 
 VIDIOC_G_STD ioctl, but as it is a radio device (saa7134-radio) it now is 
 returning -EINVAL to user space applications which are being confused about 
 this.
 
 May be VIDIOC_G_STD change in the commit above should be reverted, or 
 v4l1_compat_get_tuner changed to not return error with G_STD, or not call 
 G_STD ioctl for a radio device?
 
 --
 []'s
 Herton

it was fixed here.

http://linuxtv.org/hg/v4l-dvb/rev/58ecda742a70

Maybe it was not ported to stable?

Cheers,
Hermann


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

Endless loop with error messages

2009-12-03 Thread Ivo Steinmann

Hello all

After some uptime, I allways get an endless loop of these messages:

Dec  3 21:55:21 mediaserv kernel: [118604.764577] saa7146:
interrupt_hw(): warning: interrupt enabled, but not handled
properly.(0xe7fcfbb7)
Dec  3 21:55:21 mediaserv kernel: [118604.764580] saa7146:
interrupt_hw(): disabling interrupt source(s)!
Dec  3 21:55:21 mediaserv kernel: [118604.764591] saa7146 (1):
unexpected i2c irq: isr e7fffbb7 psr  ssr 
Dec  3 21:55:21 mediaserv kernel: [118604.764594] saa7146:
interrupt_hw(): warning: interrupt enabled, but not handled
properly.(0xe7fcfbb7)
Dec  3 21:55:21 mediaserv kernel: [118604.764597] saa7146:
interrupt_hw(): disabling interrupt source(s)!
Dec  3 21:55:21 mediaserv kernel: [118604.765299] saa7146 (1):
unexpected i2c irq: isr e7fffbb7 psr  ssr 
Dec  3 21:55:21 mediaserv kernel: [118604.765302] saa7146:
interrupt_hw(): warning: interrupt enabled, but not handled
properly.(0xe7fcfbb7)
Dec  3 21:55:21 mediaserv kernel: [118604.765305] saa7146:
interrupt_hw(): disabling interrupt source(s)!
Dec  3 21:55:21 mediaserv kernel: [118604.767852] saa7146 (3):
unexpected i2c irq: isr e7fffbb7 psr  ssr 
Dec  3 21:55:21 mediaserv kernel: [118604.767855] saa7146:
interrupt_hw(): warning: interrupt enabled, but not handled
properly.(0xe7fcfbb7)
Dec  3 21:55:21 mediaserv kernel: [118604.767858] saa7146:
interrupt_hw(): disabling interrupt source(s)!
Dec  3 21:55:21 mediaserv kernel: [118604.775192] saa7146 (1):
unexpected i2c irq: isr e7fffbb7 psr  ssr 
Dec  3 21:55:21 mediaserv kernel: [118604.775194] saa7146:
interrupt_hw(): warning: interrupt enabled, but not handled
properly.(0xe7fcfbb7)
Dec  3 21:55:21 mediaserv kernel: [118604.775197] saa7146:
interrupt_hw(): disabling interrupt source(s)!
Dec  3 21:55:21 mediaserv kernel: [118604.777377] saa7146 (3):
unexpected i2c irq: isr e7fffbb7 psr  ssr 


The CPU usage is 100% in both cores, and the machine is really locked.
Login in console takes about 5minutes. Each keystroke around 20sec.

I unloaded these modules
budget_av
budget_ci
budget_core
saa7146_vv
saa7146

The the machine is usable again.

Linux x 2.6.31.4 #3 SMP Mon Nov 16 12:29:18 CET 2009 x86_64 GNU/Linux

-Ivo Steinmann

--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-03 Thread Dmitry Torokhov

On Thu, Dec 03, 2009 at 10:51:00PM +0100, Christoph Bartelmus wrote:
 Hi Mauro,
 
 on 03 Dec 09 at 19:10, Mauro Carvalho Chehab wrote:
 [...]
  So the lirc_imon I submitted supports all device types, with the
  onboard decode devices defaulting to operating as pure input devices,
  but an option to pass hex values out via the lirc interface (which is
  how they've historically been used -- the pure input stuff I hacked
  together just a few weeks ago), to prevent functional setups from
  being broken for those who prefer the lirc way.
 
  Hmm.  I'd tend to limit the lirc interface to the 'raw samples' case.
 
  Historically it has also been used to pass decoded data (i.e. rc5) from
  devices with onboard decoding, but for that in-kernel mapping + input
  layer really fits better.
 
  I agree.
 
 Consider passing the decoded data through lirc_dev.
 - there's a large user base already that uses this mode through lirc and  
 would be forced to switch to input layer if it disappears.

I believe it was agreed that lirc-dev should be used mainly for decoding
protocols that are more conveniently decoded in userspace and the
results would be looped back into input layer through evdev which will
be the main interface for consumer applications to use.

-- 
Dmitry
--
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: acks needed for arch/sh parts of the patches

2009-12-03 Thread Paul Mundt

On Thu, Dec 03, 2009 at 10:58:08PM +0100, Guennadi Liakhovetski wrote:
 unfortunately 3 of my V4L patches for 2.6.33 have to touch arch/sh 
 simultaneously with drivers and headers. Therefore I need your acks to 
 them for arch parts. All those patches have already been posted to the 
 list at different times, here are links to them (perhaps, with some minor 
 differences):
 
 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/13307
 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/11492
 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/11504
 
 I will also send patches directly to you without cc-ing the list for 
 easier review. If you have no objections, you can just reply to this mail 
 confirming your 3 acks, if you have any comments, please reply to 
 respective mails, and then, please, add the v4l list back to cc.
 
Looks good to me.

Acked-by: Paul Mundt let...@linux-sh.org
--
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: Replace Mercurial with GIT as SCM