Re: [RFC] HDMI-CEC proposal

[Daniel Glöckner]

On Tue, Mar 01, 2011 at 10:59:07AM +0100, Martin Bugge (marbugge) wrote:
> CEC is a protocol that provides high-level control functions between
> various audiovisual products.
> It is an optional supplement to the High-Definition Multimedia
> Interface Specification (HDMI).
> Physical layer is a one-wire bidirectional serial bus that uses the
> industry-standard AV.link protocol.

Apart from CEC being twice as fast as AV.link and using 3.6V
instead of 5V, CEC does look like an extension to the frame format
defined in EN 50157-2-2 for multiple data bytes.

So, how about adding support for EN 50157-2-* messages as well?
SCART isn't dead yet.

EN 50157-2-1 is tricky in that it requires devices to override
data bits like it is done for ack bits to announce their status.
There is a single message type with 21 bits.

For EN 50157-2-2 the only change necessary would be to tell the
application that it has to use AV.link commands instead of CEC
commands. In theory one could mix AV.link and CEC on a single
wire as they can be distinguished by their start bits.

EN 50157-2-3 allows 7 vendors to register their own applications
with up to 100 data bits per message. I doubt we can support
these if they require bits on the wire to be modified.
As they still didn't make use of the reserved value to extend the
application number space beyond 7, chances are no vendor ever
applied for a number.

Just my 2 cents.

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

[cron job] v4l-dvb daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of v4l-dvb:

date:Tue Mar  1 19:00:29 CET 2011
git master:   1b59be2a6cdcb5a12e18d8315c07c94a624de48f
git media-master: gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: WARNINGS
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: ERRORS
linux-2.6.33-i686: ERRORS
linux-2.6.34-i686: ERRORS
linux-2.6.35.3-i686: ERRORS
linux-2.6.36-i686: ERRORS
linux-2.6.37-i686: ERRORS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: ERRORS
linux-2.6.33-x86_64: ERRORS
linux-2.6.34-x86_64: ERRORS
linux-2.6.35.3-x86_64: ERRORS
linux-2.6.36-x86_64: ERRORS
linux-2.6.37-x86_64: ERRORS
spec-git: ERRORS
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The V4L-DVB specification failed to build, but the last compiled spec 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: Remote control not working for Terratec Cinergy C (2.6.37 Mantis driver)

[Marko Ristola]

28.02.2011 19:26, Jonas Hanschke kirjoitti:

Hi,

despite lots of time spent tinkering around and looking for help on
the web, I've had no success in getting to work the remote control of
my DVB-C card.

It is a Terratec Cinergy C:
http://linuxtv.org/wiki/index.php/TerraTec_Cinergy_C_DVB-C

and am using the Mantis driver. Since it was merged into the kernel
tree in 2.6.33, watching TV works without patches, but the remote
control does not, although it is supposed to be supported, according
to the link above.

Kernel is a vanilla 2.6.37.2 with custom configuration on an old AMD
Athlon XP machine, running debian Squeeze.


When I modprobe the Mantis driver, the following IR-modules are pulled
in automagically:
ir_lirc_codec
lirc_dev
ir_core

However, no input device is created during module loading. dmesg output:
Mantis :01:0a.0: PCI INT A ->  Link[APC1] ->  GSI 16 (level, high) ->  IRQ 
16
DVB: registering new adapter (Mantis DVB adapter)
IR LIRC bridge handler initialized
DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)...

Am I missing some additional modules? Are there any dependencies on
other kernel config options that are not handled automatically by make
menuconf?

If additional information is needed, I will be happy to provide it.
However, I am not sure what is useful and what is not and did not want
to bloat this message.


Before merging into v4l-dvb, doing modprobe mantis was enough.
I don't know how it should work with recent kernels.
I haven't seen remote control working lately.

Turning mantis module debug options on gives some information
what is happening into /var/log/messages.

Regards,
Marko Ristola



Thanks in advance,

Jonas
--
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] HDMI-CEC proposal

[Alex Deucher]

On Tue, Mar 1, 2011 at 4:59 AM, Martin Bugge (marbugge)
 wrote:
> Author: Martin Bugge 
> Date:  Tue, 1 March 2010
> ==
>
> This is a proposal for adding a Consumer Electronic Control (CEC) API to
> V4L2.
> This document describes the changes and new ioctls needed.
>
> Version 1.0 (This is first version)
>
> Background
> ==
> CEC is a protocol that provides high-level control functions between various
> audiovisual products.
> It is an optional supplement to the High-Definition Multimedia Interface
> Specification (HDMI).
> Physical layer is a one-wire bidirectional serial bus that uses the
> industry-standard AV.link protocol.
>
> In short: CEC uses pin 13 on the HDMI connector to transmit and receive
> small data-packets
>          (maximum 16 bytes including a 1 byte header) at low data rates
> (~400 bits/s).
>
> A CEC device may have any of 15 logical addresses (0 - 14).
> (address 15 is broadcast and some addresses are reserved)
>

It would be nice if this was not tied to v4l as we'll start seeing CEC
support show in GPUs soon as well.

Alex

>
> References
> ==
> [1] High-Definition Multimedia Interface Specification version 1.3a,
>    Supplement 1 Consumer Electronic Control (CEC).
>    http://www.hdmi.org/manufacturer/specification.aspx
>
> [2]
> http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
>
>
> Proposed solution
> =
>
> Two new ioctls:
>    VIDIOC_CEC_CAP (read)
>    VIDIOC_CEC_CMD (read/write)
>
> VIDIOC_CEC_CAP:
> ---
>
> struct vl2_cec_cap {
>       __u32 logicaldevices;
>       __u32 reserved[7];
> };
>
> The capability ioctl will return the number of logical devices/addresses
> which can be
> simultaneously supported on this HW.
>    0:       This HW don't support CEC.
>    1 -> 14: This HW supports n logical devices simultaneously.
>
> VIDIOC_CEC_CMD:
> ---
>
> struct v4l2_cec_cmd {
>    __u32 cmd;
>    __u32 reserved[7];
>    union {
>        struct {
>            __u32 index;
>            __u32 enable;
>            __u32 addr;
>        } conf;
>        struct {
>            __u32 len;
>            __u8  msg[16];
>            __u32 status;
>        } data;
>        __u32 raw[8];
>    };
> };
>
> Alternatively the data struct could be:
>        struct {
>            __u8  initiator;
>            __u8  destination;
>            __u8  len;
>            __u8  msg[15];
>            __u32 status;
>        } data;
>
> Commands:
>
> #define V4L2_CEC_CMD_CONF  (1)
> #define V4L2_CEC_CMD_TX    (2)
> #define V4L2_CEC_CMD_RX    (3)
>
> Tx status field:
>
> #define V4L2_CEC_STAT_TX_OK            (0)
> #define V4L2_CEC_STAT_TX_ARB_LOST      (1)
> #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
>
> The command ioctl is used both for configuration and to receive/transmit
> data.
>
> * The configuration command must be done for each logical device address
>  which is to be enabled on this HW. Maximum number of logical devices
>  is found with the capability ioctl.
>    conf:
>         index:  0 -> number_of_logical_devices-1
>         enable: true/false
>         addr:   logical address
>
>  By default all logical devices are disabled.
>
> * Tx/Rx command
>    data:
>         len:    length of message (data + header)
>         msg:    the raw CEC message received/transmitted
>         status: when the driver is in blocking mode it gives the result for
> transmit.
>
> Events
> --
>
> In the case of non-blocking mode the driver will issue the following events:
>
> V4L2_EVENT_CEC_TX
> V4L2_EVENT_CEC_RX
>
> V4L2_EVENT_CEC_TX
> -
>  * transmit is complete with the following status:
> Add an additional struct to the struct v4l2_event
>
> struct v4l2_event_cec_tx {
>       __u32 status;
> }
>
> V4L2_EVENT_CEC_RX
> -
>  * received a complete message
>
>
> Comments ?
>
>           Martin Bugge
>
> --
> Martin Bugge - Tandberg (now a part of Cisco)
> --
>
> --
> 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] HDMI-CEC proposal

[Hans Verkuil]

On Tuesday, March 01, 2011 15:59:21 Martin Bugge (marbugge) wrote:
> On 03/01/2011 02:47 PM, Andy Walls wrote:
> > On Tue, 2011-03-01 at 10:59 +0100, Martin Bugge (marbugge) wrote:
> >
> >> Author: Martin Bugge
> >> Date:  Tue, 1 March 2010
> >> ==
> >>
> >> This is a proposal for adding a Consumer Electronic Control (CEC) API to
> >> V4L2.
> >> This document describes the changes and new ioctls needed.
> >>
> >> Version 1.0 (This is first version)
> >>
> >> Background
> >> ==
> >> CEC is a protocol that provides high-level control functions between
> >> various audiovisual products.
> >> It is an optional supplement to the High-Definition Multimedia Interface
> >> Specification (HDMI).
> >> Physical layer is a one-wire bidirectional serial bus that uses the
> >> industry-standard AV.link protocol.
> >>
> >> In short: CEC uses pin 13 on the HDMI connector to transmit and receive
> >> small data-packets
> >> (maximum 16 bytes including a 1 byte header) at low data
> >> rates (~400 bits/s).
> >>
> >> A CEC device may have any of 15 logical addresses (0 - 14).
> >> (address 15 is broadcast and some addresses are reserved)
> >>
> >>
> >> References
> >> ==
> >> [1] High-Definition Multimedia Interface Specification version 1.3a,
> >>   Supplement 1 Consumer Electronic Control (CEC).
> >>   http://www.hdmi.org/manufacturer/specification.aspx
> >>
> >> [2]
> >> http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
> >>  
> >
> > Hi Martin,
> >
> > After reading the whitepaper, and the the general purpose nature of your
> > proposed API calls, I'm wondering if a socket interface wouldn't be
> > appropriate.
> >
> > The CEC bus seems to be designed as a network.  A broadcast medium, with
> > multiport devices (switches), physical (MAC) addresses in dotted decimal
> > notation (1.0.0.0), dynamic logical address assignment, arbitration
> > (Media Access Control), etc.  The whitepaper even suggests OSI layers,
> > using the term PHY in a few places.
> >
> >
> > A network interface could be implemented something like what is done for
> > SLIP in figure 2 here (compare with figure 1):
> >
> > http://www.linux.it/~rubini/docs/serial/serial.html
> >
> >
> > Using that diagram as a guide, a socket interface would need a CEC tty
> > line discipline, CEC network device, and code to hook the CEC serial
> > device to the tty layer.  Multiple CEC serial devices would show up as
> > multiple network interfaces.
> >
> > Once a network device is available, user-space could then use AF_PACKET
> > sockets.  If CEC's layers are standardized enough, a new address family
> > could be added to the kernel, I guess.
> >
> > Of course, all that is a lot of work.  Since Cisco should have some
> > networking experts hanging around, maybe it wouldn't be too hard. ;)
> >
> >
> > Regards,
> > Andy
> >
> 
> Hi Andy and thank you.
> 
> I agree its always nice to strive for a generic solution, but I don't 
> think I'm able to
> get hold of the resources required.
> 
> In CEC the physical address is determined by the edid information from 
> the HDMI sink,
> or for the HDMI sink its HDMI port number.
> 
> While the logical address describes the type of device, TV, Recorder, 
> Tuner, etc.
> 
>  From that point of view I do think that the CEC protocol is closly 
> connected to the HDMI connector,
> such that it belongs together with a video device.
> 
> But I will ask my "mentor" for advice.

Yes, CEC has a physical address which obtained from the EDID. It is generated
via the EDID. It has nothing to do with network addresses. Instead it is a
generated unique identifier. CEC also has logical addresses which is a really
a 'Device Type Identifier' for want of a better name. See CEC Table 5 in the
1.3a HDMI spec.

When I read through it I couldn't help wondering what to do if I have more than
three playback devices or recording devices. Or more than one TV, for that 
matter.

It also seems that the tree of connected devices can't be more than 4 or 5 
levels,
if I understand section 8.7.2 (Physical Address Discovery) correctly.

As I mentioned in my reply to Mauro, CEC most closely resembles RDS in that the
hardware/kernel part is trivial, but parsing and correctly handling it is a lot
more complicated and ideal for a userspace library.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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] HDMI-CEC proposal

[Hans Verkuil]

On Tuesday, March 01, 2011 17:19:21 Mauro Carvalho Chehab wrote:
> Em 01-03-2011 12:49, Hans Verkuil escreveu:
> > On Tuesday, March 01, 2011 16:20:25 Mauro Carvalho Chehab wrote:
> >> Em 01-03-2011 11:38, Hans Verkuil escreveu:



> >>> Again, CEC != IR. All you need is a simple API to be able to send and 
> > receive 
> >>> CEC packets and a libcec that you can use to do the topology discovery 
> >>> and 
> >>> send/receive the commands. You don't want nor need that in the kernel.
> >>>
> >>> The only place where routing things to the IR core is useful is when 
> > someone 
> >>> points a remote at a TV (for example), which then passes it over CEC to 
> > your 
> >>> device which is not a repeater but can actually handle the remote command.
> >>>
> >>> This is a future extension, though.
> >>
> >> There are two separate things when dealing with CEC: the low-level kernel
> >> implementation of a bus for connecting with CEC devices, and userspace APIs
> >> for using its features.
> >>
> >> If you were needing it only internally inside the kernel, there's no need 
> > for 
> >> new ioctl's. So, your proposal seems to add a raw interface for it, and do 
> >> all the work in userspace.
> >>
> >> An alternative approach, that it is the way most Kernel API's do is to 
> > write/use
> >> higher userspace APIs, abstracting the hardware internals. V4L, DVB and 
> >> RC, 
> > input/event,
> >> vfs, tty, etc are good examples of how we do APIs in Linux. We should only 
> > go 
> >> to a raw API if the high-level ones won't work. 
> > 
> > What high-level API? There isn't much high-level about CEC. It's a very 
> > simplistic standard. Each packet has a source and destination address (0-14 
> > which you can choose yourself), an optional command with an optional 
> > payload. 
> > You can put in pretty much what you want since you can make custom commands 
> > as 
> > well.
> 
> I2C is even simpler in theory (1 TX wire, 1 RX wire, low speed, 7 bits for 
> address), 
> but a hole subsystem and several API's are needed in order to handle with I2C 
> device complexity.

Nope, CEC is simpler: just one line and 400 bits per second. I win :-)

More to the point: i2c is a generic protocol to communicate with hardware 
devices.
Emphasis on 'generic'. CEC is far from generic: it is full of assumptions and
specific use-cases. In that respect it closely resembles RDS: this too is a low
bandwidth, application-specific protocol. For RDS the API is also at the packet
level, requiring a library to make use of it.

>  
> > You also assume that you can handle packets at a high level. But you can't, 
> > because what you want to do with packets depends very much on what device 
> > you 
> > are: TV, recorder, set-top, CEC switch, etc.
> 
> Again, it sounds similar to I2C.

No. The difference is that I2C is a generic protocol. For CEC these roles are
hardwired in the protocol.

> 
> >> Also, a raw-level implementation of CEC may/will interfere on higher level
> >> interfaces. For example, assuming that we have both raw and RC interfaces 
> > using 
> >> HDMI-CIC, a raw access on one process during a RC reception or transmit 
> > could 
> >> interfere on another process using the high-level interface for RC (as a 
> >> raw
> >> access to a block device may actually corrupt data). So, raw interfaces are
> >> evil, and generally require CAP_SYS_ADMIN.
> > 
> > ??? If we add a flag that causes the IR commands to go to the IR core, then 
> > they will obviously not appear on the normal CEC interface.
> > 
> >> So, I think we should first discuss what are the needs, and then discuss 
> >> how
> >> to implement them.
> > 
> > Well, the need is to receive and transmit CEC packets. And this is a 
> > possible 
> > implementation.
> > 
> > Don't give CEC too much status: CEC is a very simplistic, stupid and very 
> > low 
> > bandwidth protocol. It is even simpler than RDS.
> 
> We should look what usage you have in mind for CEC, and then write an API for 
> it,
> not the opposite.
> 
> Usage of CEC for remote-controlling devices is one application whose usage is 
> clear
> to me, and that we have already Kernel APIs for them. As usual, the current 
> API's may 
> need additions in order to support some features.
> 
> What are the other use-cases?

Please read the CEC standard. In particular look at the CEC 13 chapter, which is
basically a list of the common use-cases. This proposed API basically handles 
the
protocol up to section CEC 9. CEC 15 is also useful to look at.

All this is highly specific to consumer electronics (and very restrictive as 
well:
something like video conferencing equipment doesn't really fit well in this
protocol).

All this screams 'userspace CEC protocol library' to me, with just the hardware
part of the protocol in the kernel. For exactly the same reason why RDS parsing
is done in userspace.

The only exception I see is the "Remote Control Pass Through" (CEC 13.13). This
can optionally be routed via the IR core.

Reg

omap3isp cache error when unloading

[Michael Jones]

Hi all,

I get a warning about a cache error with the following steps:

0. load omap3-isp
1. set up media broken media pipeline. (e.g. set different formats on
opposite ends of a link, as will be the case for using the lane shifter)
2. try to capture images.  isp_video_streamon() returns -EPIPE from the
failed isp_video_validate_pipeline() call.
3. unload omap3-isp module

then I get the following from kmem_cache_destroy():

slab error in kmem_cache_destroy(): cache `iovm_area_cache': Can't free all 
objects
[] (unwind_backtrace+0x0/0xec) from [] 
(kmem_cache_destroy+0x88/0xf4)
[] (kmem_cache_destroy+0x88/0xf4) from [] 
(sys_delete_module+0x1c4/0x230)
[] (sys_delete_module+0x1c4/0x230) from [] 
(ret_fast_syscall+0x0/0x30)

Then, when reloading the module:
SLAB: cache with size 32 has lost its name

Can somebody else confirm that they also observe this behavior?

-Michael

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
--
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] HDMI-CEC proposal

[Mauro Carvalho Chehab]

Em 01-03-2011 12:49, Hans Verkuil escreveu:
> On Tuesday, March 01, 2011 16:20:25 Mauro Carvalho Chehab wrote:
>> Em 01-03-2011 11:38, Hans Verkuil escreveu:
>>> Hi Mauro,
>>>
>>> On Tuesday, March 01, 2011 13:28:35 Mauro Carvalho Chehab wrote:
 Hi Martin,

 Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu:
> Author: Martin Bugge 
> Date:  Tue, 1 March 2010
> ==
>
> This is a proposal for adding a Consumer Electronic Control (CEC) API to 
>>> V4L2.
> This document describes the changes and new ioctls needed.
>
> Version 1.0 (This is first version)
>
> Background
> ==
> CEC is a protocol that provides high-level control functions between 
>>> various audiovisual products.
> It is an optional supplement to the High-Definition Multimedia Interface 
>>> Specification (HDMI).
> Physical layer is a one-wire bidirectional serial bus that uses the 
>>> industry-standard AV.link protocol.
>
> In short: CEC uses pin 13 on the HDMI connector to transmit and receive 
>>> small data-packets
>   (maximum 16 bytes including a 1 byte header) at low data rates 
>>> (~400 bits/s).
>
> A CEC device may have any of 15 logical addresses (0 - 14).
> (address 15 is broadcast and some addresses are reserved)
>
>
> References
> ==
> [1] High-Definition Multimedia Interface Specification version 1.3a,
> Supplement 1 Consumer Electronic Control (CEC).
> http://www.hdmi.org/manufacturer/specification.aspx
>
> [2] 
>>> http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
>
>
> Proposed solution
> =
>
> Two new ioctls:
> VIDIOC_CEC_CAP (read)
> VIDIOC_CEC_CMD (read/write)

 How this proposal will interact with RC core? The way I see it, HDMI-CEC 
> is 
>>> just a way to get/send
 Remote Controller data, and should be interacting with the proper Kernel 
>>> subsystems, e. g.,
 with Remote Controller and input/event subsystems.
>>>
>>> I knew you were going to mention this :-)
>>>
>>> Actually, while CEC does support IR commands, this is only a very small 
> part 
>>> of the standard. Routing IR commands to the IR core is possible to do, 
>>> although it is not in this initial version. Should this be needed, then a 
> flag 
>>> can be created that tells V4L to route IR commands to the IR core.
>>>
>>> This should be optional, though, because if you are a repeater you do not 
> want 
>>> to pass such IR commands to the IR core, instead you want to retransmit 
> them 
>>> to a CEC output.
>>>

 I don't think we need two ioctls for that, as RC capabilities are already 
>>> exported via
 sysfs, and we have two interfaces already for receiving events 
> (input/event 
>>> and lirc).
 For sending, lirc interface might be used, but it is currently focused 
> only 
>>> on sending
 raw pulse/space sequences. So, we'll need to add some capability there 
> for 
>>> IR/CEC TX.
 I had a few discussions about that with Jarod, but we didn't write yet an 
>>> interface for it.
>>>
>>> Again, CEC != IR. All you need is a simple API to be able to send and 
> receive 
>>> CEC packets and a libcec that you can use to do the topology discovery and 
>>> send/receive the commands. You don't want nor need that in the kernel.
>>>
>>> The only place where routing things to the IR core is useful is when 
> someone 
>>> points a remote at a TV (for example), which then passes it over CEC to 
> your 
>>> device which is not a repeater but can actually handle the remote command.
>>>
>>> This is a future extension, though.
>>
>> There are two separate things when dealing with CEC: the low-level kernel
>> implementation of a bus for connecting with CEC devices, and userspace APIs
>> for using its features.
>>
>> If you were needing it only internally inside the kernel, there's no need 
> for 
>> new ioctl's. So, your proposal seems to add a raw interface for it, and do 
>> all the work in userspace.
>>
>> An alternative approach, that it is the way most Kernel API's do is to 
> write/use
>> higher userspace APIs, abstracting the hardware internals. V4L, DVB and RC, 
> input/event,
>> vfs, tty, etc are good examples of how we do APIs in Linux. We should only 
> go 
>> to a raw API if the high-level ones won't work. 
> 
> What high-level API? There isn't much high-level about CEC. It's a very 
> simplistic standard. Each packet has a source and destination address (0-14 
> which you can choose yourself), an optional command with an optional payload. 
> You can put in pretty much what you want since you can make custom commands 
> as 
> well.

I2C is even simpler in theory (1 TX wire, 1 RX wire, low speed, 7 bits for 
address), 
but a hole subsystem and several API's are needed in order to handle with I2C 
device complexity.
 
> You also assume that you can handle packets at 

Re: MCEUSB: falsly claims mass storage device

[Jarod Wilson]

On Feb 28, 2011, at 5:34 PM, Jarod Wilson wrote:

> On Feb 17, 2011, at 6:46 AM, Lucian Muresan wrote:
> 
>> On 09.02.2011 06:19, Jarod Wilson wrote:
>> [...]
>>> Looks like bInterfaceNumber == 2 on this device. The patch to handle this
>>> similar to the conexant polaris devices should be pretty trivial. I'll
>>> try to get something together tomorrow.
>> 
>> Hi,
>> 
>> any news on this one?
> 
> I suck, but I have a patch in my local tree now. Need to build and
> quickly test it to make sure it doesn't break the devices I've got,
> then I'll get it posted.

Patch is posted.

https://patchwork.kernel.org/patch/599711/

-- 
Jarod Wilson
ja...@wilsonet.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: isp or soc-camera for image co-processors

[Laurent Pinchart]

Hi Bhupesh,

On Tuesday 01 March 2011 12:04:34 Bhupesh SHARMA wrote:
> On Tuesday, March 01, 2011 3:40 PM Laurent Pinchart wrote: > > On Tuesday 01 
March 2011 10:46:36 Bhupesh SHARMA wrote:
> > > On Tuesday, March 01, 2011 3:11 PM Laurent Pinchart wrote:
> > > > On Tuesday 01 March 2011 08:25:12 Bhupesh SHARMA wrote:

[snip]

> > > Unfortunately the data-sheet of the co-processor cannot be made public
> > > as of yet.
> > 
> > Can you publish a block diagram of the co-processor internals ?
> 
> I will check internally to see if I can send a block-diagram of the co-
> processor internals to you. The internals seem similar to OMAP ISP (which I
> can see from the public TRM). However, our co-processor doesn't have the
> circular buffer and MMU that ISP seem to have (and some other features).

The co-processor doesn't write to the system main memory but outputs the data 
on a CSI2 or ITU interface, so that's not really surprising.

> In the meantime I copy the features of the co-processor here for your
> review:
> 
> Input / Output interfaces of co-processor:
> ==
> - Sensor interfaces: 2 x MIPI CSI-2 receivers (1 x dual-lane up to 1.6
> Gbit/s and 1 x single lane up to 800 Mbit/s)
> - Host interface: MIPI CSI-2 dual lane transmitter (up to 1.6 Gbit/s) or
> ITU (8-bit CCIR interface, up to 100 MHz) - all with independent variable
> transmitter clock (PLL)
> - Control interface: CCI (up to 400 kHz) or SPI
> 
> Sensor support:
> ===
> - Supports two MIPI compliant sensors of up to 8 Megapixel resolution
>  (one sensor streaming at a time)
> - Support for auto-focus (AF), extended depth of field (EDOF) and wide
> dynamic range (WDR)sensors
> 
> Internal Features:
> ==
> - Versatile clock manager and internal buffer to accommodate a wide range
> of data rates between sensors and the coprocessor and between the
> coprocessor and the host.
> - Synchronized flash gun control with red-eye reduction (pre-flash and main-
> flash strobes) for high-power LED or Xenon strobe light
> - Low power standby mode
> - Two video pipes (enables concurrent viewfinding and video/stills capture)
> - Face detection and tracking algorithm
> - Video stabilization
> - Adaptive 4-channel lens shading and barrel distortion correction
> - Statistics processor for advanced automatic exposure and white balance
> - Automatic contrast stretch
> - Nine-zone auto-focus with flexible actuator driver
> - Digital zoom: smooth 16x down-scale capability and 4x up-scale capability
> - Advanced noise and defect filtering
> - Color reconstruction
> - Adaptive color correction matrix
> - Sharpness enhancement
> - Programmable gamma correction
> - Lighting frequency detection and automatic flicker reduction
> - Image rotation/mirroring/flip for the viewfinder (up to 480 x 360)
> - Special effects
> 
> Data Formats:
> =
> - Output formats: JPEG, YUV4:2:2, YUV4:2:0, Planar YUV4:2:0 (up to 480 x
> 360), RGB888, RGB565, RGB444
> - JPEG compression with programmable quantization matrix and target file
> size

Given the complexity of the co-processor, I think it would make sense to break 
it in pieces and use the media controller API, especially if data routing is 
configurable inside the co-processor.

-- 
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: [GIT PATCHES FOR 2.6.39] cx23885, altera-ci: remove operator return in void procedure

[Igor M. Liplianin]

The following changes since commit 9e650fdb12171a5a5839152863eaab9426984317:

  [media] drivers:media:radio: Update Kconfig and Makefile for wl128x FM driver 
(2011-02-27 
07:50:42 -0300)

are available in the git repository at:
  git://linuxtv.org/liplianin/media_tree.git dual_dvb_t_c_ci_rf

Abylay Ospan (1):
  stv0900: Update status when LOCK is missed

Igor M. Liplianin (2):
  cx23885, altera-ci: remove operator return  in void procedure
  stv0900: speed up DVB-S searching

 drivers/media/dvb/frontends/stv0900_core.c |6 +-
 drivers/media/video/cx23885/altera-ci.h|2 --
 2 files changed, 5 insertions(+), 3 deletions(-)
--
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] HDMI-CEC proposal

[Hans Verkuil]

On Tuesday, March 01, 2011 16:20:25 Mauro Carvalho Chehab wrote:
> Em 01-03-2011 11:38, Hans Verkuil escreveu:
> > Hi Mauro,
> > 
> > On Tuesday, March 01, 2011 13:28:35 Mauro Carvalho Chehab wrote:
> >> Hi Martin,
> >>
> >> Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu:
> >>> Author: Martin Bugge 
> >>> Date:  Tue, 1 March 2010
> >>> ==
> >>>
> >>> This is a proposal for adding a Consumer Electronic Control (CEC) API to 
> > V4L2.
> >>> This document describes the changes and new ioctls needed.
> >>>
> >>> Version 1.0 (This is first version)
> >>>
> >>> Background
> >>> ==
> >>> CEC is a protocol that provides high-level control functions between 
> > various audiovisual products.
> >>> It is an optional supplement to the High-Definition Multimedia Interface 
> > Specification (HDMI).
> >>> Physical layer is a one-wire bidirectional serial bus that uses the 
> > industry-standard AV.link protocol.
> >>>
> >>> In short: CEC uses pin 13 on the HDMI connector to transmit and receive 
> > small data-packets
> >>>   (maximum 16 bytes including a 1 byte header) at low data rates 
> > (~400 bits/s).
> >>>
> >>> A CEC device may have any of 15 logical addresses (0 - 14).
> >>> (address 15 is broadcast and some addresses are reserved)
> >>>
> >>>
> >>> References
> >>> ==
> >>> [1] High-Definition Multimedia Interface Specification version 1.3a,
> >>> Supplement 1 Consumer Electronic Control (CEC).
> >>> http://www.hdmi.org/manufacturer/specification.aspx
> >>>
> >>> [2] 
> > http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
> >>>
> >>>
> >>> Proposed solution
> >>> =
> >>>
> >>> Two new ioctls:
> >>> VIDIOC_CEC_CAP (read)
> >>> VIDIOC_CEC_CMD (read/write)
> >>
> >> How this proposal will interact with RC core? The way I see it, HDMI-CEC 
is 
> > just a way to get/send
> >> Remote Controller data, and should be interacting with the proper Kernel 
> > subsystems, e. g.,
> >> with Remote Controller and input/event subsystems.
> > 
> > I knew you were going to mention this :-)
> > 
> > Actually, while CEC does support IR commands, this is only a very small 
part 
> > of the standard. Routing IR commands to the IR core is possible to do, 
> > although it is not in this initial version. Should this be needed, then a 
flag 
> > can be created that tells V4L to route IR commands to the IR core.
> > 
> > This should be optional, though, because if you are a repeater you do not 
want 
> > to pass such IR commands to the IR core, instead you want to retransmit 
them 
> > to a CEC output.
> > 
> >>
> >> I don't think we need two ioctls for that, as RC capabilities are already 
> > exported via
> >> sysfs, and we have two interfaces already for receiving events 
(input/event 
> > and lirc).
> >> For sending, lirc interface might be used, but it is currently focused 
only 
> > on sending
> >> raw pulse/space sequences. So, we'll need to add some capability there 
for 
> > IR/CEC TX.
> >> I had a few discussions about that with Jarod, but we didn't write yet an 
> > interface for it.
> > 
> > Again, CEC != IR. All you need is a simple API to be able to send and 
receive 
> > CEC packets and a libcec that you can use to do the topology discovery and 
> > send/receive the commands. You don't want nor need that in the kernel.
> > 
> > The only place where routing things to the IR core is useful is when 
someone 
> > points a remote at a TV (for example), which then passes it over CEC to 
your 
> > device which is not a repeater but can actually handle the remote command.
> > 
> > This is a future extension, though.
> 
> There are two separate things when dealing with CEC: the low-level kernel
> implementation of a bus for connecting with CEC devices, and userspace APIs
> for using its features.
> 
> If you were needing it only internally inside the kernel, there's no need 
for 
> new ioctl's. So, your proposal seems to add a raw interface for it, and do 
> all the work in userspace.
> 
> An alternative approach, that it is the way most Kernel API's do is to 
write/use
> higher userspace APIs, abstracting the hardware internals. V4L, DVB and RC, 
input/event,
> vfs, tty, etc are good examples of how we do APIs in Linux. We should only 
go 
> to a raw API if the high-level ones won't work. 

What high-level API? There isn't much high-level about CEC. It's a very 
simplistic standard. Each packet has a source and destination address (0-14 
which you can choose yourself), an optional command with an optional payload. 
You can put in pretty much what you want since you can make custom commands as 
well.

You also assume that you can handle packets at a high level. But you can't, 
because what you want to do with packets depends very much on what device you 
are: TV, recorder, set-top, CEC switch, etc.

> Also, a raw-level implementation of CEC may/will interfere on higher level
> interfaces. For example, assuming that we have bo

[PATCH] tda829x: fix regression in probe functions

[Jarod Wilson]

In commit 567aba0b7997dad5fe3fb4aeb174ee9018df8c5b, the probe address
for tda8290_probe and tda8295_probe was hard-coded to 0x4b, which is the
default i2c address for those devices, but its possible for the device
to be at an alternate address, 0x42, which is the case for the HVR-1950.
If we probe the wrong address, probe fails and we have a non-working
device. We have the actual address passed into the function by way of
i2c_props, we just need to use it. Also fix up some copy/paste comment
issues and streamline debug spew a touch. Verified to restore my
HVR-1950 to full working order.

Special thanks to Ken Bass for reporting the issue in the first place,
and to both he and Gary Buhrmaster for aiding in debugging and analysis
of the problem.

Reported-by: Ken Bass 
Tested-by: Jarod Wilson 
Signed-off-by: Jarod Wilson 
---
 drivers/media/common/tuners/tda8290.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/media/common/tuners/tda8290.c 
b/drivers/media/common/tuners/tda8290.c
index bc6a677..8c48521 100644
--- a/drivers/media/common/tuners/tda8290.c
+++ b/drivers/media/common/tuners/tda8290.c
@@ -658,13 +658,13 @@ static int tda8290_probe(struct tuner_i2c_props 
*i2c_props)
 #define TDA8290_ID 0x89
u8 reg = 0x1f, id;
struct i2c_msg msg_read[] = {
-   { .addr = 0x4b, .flags = 0, .len = 1, .buf = ® },
-   { .addr = 0x4b, .flags = I2C_M_RD, .len = 1, .buf = &id },
+   { .addr = i2c_props->addr, .flags = 0, .len = 1, .buf = ® },
+   { .addr = i2c_props->addr, .flags = I2C_M_RD, .len = 1, .buf = 
&id },
};
 
/* detect tda8290 */
if (i2c_transfer(i2c_props->adap, msg_read, 2) != 2) {
-   printk(KERN_WARNING "%s: tda8290 couldn't read register 
0x%02x\n",
+   printk(KERN_WARNING "%s: couldn't read register 0x%02x\n",
   __func__, reg);
return -ENODEV;
}
@@ -685,13 +685,13 @@ static int tda8295_probe(struct tuner_i2c_props 
*i2c_props)
 #define TDA8295C2_ID 0x8b
u8 reg = 0x2f, id;
struct i2c_msg msg_read[] = {
-   { .addr = 0x4b, .flags = 0, .len = 1, .buf = ® },
-   { .addr = 0x4b, .flags = I2C_M_RD, .len = 1, .buf = &id },
+   { .addr = i2c_props->addr, .flags = 0, .len = 1, .buf = ® },
+   { .addr = i2c_props->addr, .flags = I2C_M_RD, .len = 1, .buf = 
&id },
};
 
-   /* detect tda8290 */
+   /* detect tda8295 */
if (i2c_transfer(i2c_props->adap, msg_read, 2) != 2) {
-   printk(KERN_WARNING "%s: tda8290 couldn't read register 
0x%02x\n",
+   printk(KERN_WARNING "%s: couldn't read register 0x%02x\n",
   __func__, reg);
return -ENODEV;
}
-- 
1.7.1

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

[PATCH] mceusb: don't claim multifunction device non-IR parts

[Jarod Wilson]

There's a Realtek combo card reader and IR receiver device with multiple
usb interfaces on it. The mceusb driver is incorrectly grabbing all of
them. This change should make it bind to only interface 2 (patch based
on lsusb output on the linux-media list from Lucian Muresan).

Tested regression-free with the six mceusb devices I have myself.

Reported-by: Patrick Boettcher 
Reported-by: Lucian Muresan 
Signed-off-by: Jarod Wilson 
---
 drivers/media/rc/mceusb.c |   27 +++
 1 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 6df0a49..e4f8eac 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -148,6 +148,7 @@ enum mceusb_model_type {
MCE_GEN2_TX_INV,
POLARIS_EVK,
CX_HYBRID_TV,
+   MULTIFUNCTION,
 };
 
 struct mceusb_model {
@@ -155,9 +156,10 @@ struct mceusb_model {
u32 mce_gen2:1;
u32 mce_gen3:1;
u32 tx_mask_normal:1;
-   u32 is_polaris:1;
u32 no_tx:1;
 
+   int ir_intfnum;
+
const char *rc_map; /* Allow specify a per-board map */
const char *name;   /* per-board name */
 };
@@ -179,7 +181,6 @@ static const struct mceusb_model mceusb_model[] = {
.tx_mask_normal = 1,
},
[POLARIS_EVK] = {
-   .is_polaris = 1,
/*
 * In fact, the EVK is shipped without
 * remotes, but we should have something handy,
@@ -189,10 +190,13 @@ static const struct mceusb_model mceusb_model[] = {
.name = "Conexant Hybrid TV (cx231xx) MCE IR",
},
[CX_HYBRID_TV] = {
-   .is_polaris = 1,
.no_tx = 1, /* tx isn't wired up at all */
.name = "Conexant Hybrid TV (cx231xx) MCE IR",
},
+   [MULTIFUNCTION] = {
+   .mce_gen2 = 1,
+   .ir_intfnum = 2,
+   },
 };
 
 static struct usb_device_id mceusb_dev_table[] = {
@@ -216,8 +220,9 @@ static struct usb_device_id mceusb_dev_table[] = {
{ USB_DEVICE(VENDOR_PHILIPS, 0x206c) },
/* Philips/Spinel plus IR transceiver for ASUS */
{ USB_DEVICE(VENDOR_PHILIPS, 0x2088) },
-   /* Realtek MCE IR Receiver */
-   { USB_DEVICE(VENDOR_REALTEK, 0x0161) },
+   /* Realtek MCE IR Receiver and card reader */
+   { USB_DEVICE(VENDOR_REALTEK, 0x0161),
+ .driver_info = MULTIFUNCTION },
/* SMK/Toshiba G83C0004D410 */
{ USB_DEVICE(VENDOR_SMK, 0x031d),
  .driver_info = MCE_GEN2_TX_INV },
@@ -1101,7 +1106,7 @@ static int __devinit mceusb_dev_probe(struct 
usb_interface *intf,
bool is_gen3;
bool is_microsoft_gen1;
bool tx_mask_normal;
-   bool is_polaris;
+   int ir_intfnum;
 
dev_dbg(&intf->dev, "%s called\n", __func__);
 
@@ -1110,13 +1115,11 @@ static int __devinit mceusb_dev_probe(struct 
usb_interface *intf,
is_gen3 = mceusb_model[model].mce_gen3;
is_microsoft_gen1 = mceusb_model[model].mce_gen1;
tx_mask_normal = mceusb_model[model].tx_mask_normal;
-   is_polaris = mceusb_model[model].is_polaris;
+   ir_intfnum = mceusb_model[model].ir_intfnum;
 
-   if (is_polaris) {
-   /* Interface 0 is IR */
-   if (idesc->desc.bInterfaceNumber)
-   return -ENODEV;
-   }
+   /* There are multi-function devices with non-IR interfaces */
+   if (idesc->desc.bInterfaceNumber != ir_intfnum)
+   return -ENODEV;
 
/* step through the endpoints to find first bulk in and out endpoint */
for (i = 0; i < idesc->desc.bNumEndpoints; ++i) {
-- 
1.7.1

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

[PATCH] nuvoton-cir: fix wake from suspend

[Jarod Wilson]

The CIR Wake FIFO is 67 bytes long, but the stock remote appears to only
populate 65 of them. Limit comparison to 65 bytes, and wake from suspend
works a whole lot better (it wasn't working at all for most folks).

Fix based on comparison with the old lirc_wb677 driver from Nuvoton,
debugging and testing done by Dave Treacy by way of the lirc mailing
list.

Reported-by: Dave Treacy 
Signed-off-by: Jarod Wilson 
---
 drivers/media/rc/nuvoton-cir.c |5 +++--
 drivers/media/rc/nuvoton-cir.h |7 +--
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index 273d9d6..d4d6449 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -385,8 +385,9 @@ static void nvt_cir_regs_init(struct nvt_dev *nvt)
 
 static void nvt_cir_wake_regs_init(struct nvt_dev *nvt)
 {
-   /* set number of bytes needed for wake key comparison (default 67) */
-   nvt_cir_wake_reg_write(nvt, CIR_WAKE_FIFO_LEN, CIR_WAKE_FIFO_CMP_DEEP);
+   /* set number of bytes needed for wake from s3 (default 65) */
+   nvt_cir_wake_reg_write(nvt, CIR_WAKE_FIFO_CMP_BYTES,
+  CIR_WAKE_FIFO_CMP_DEEP);
 
/* set tolerance/variance allowed per byte during wake compare */
nvt_cir_wake_reg_write(nvt, CIR_WAKE_CMP_TOLERANCE,
diff --git a/drivers/media/rc/nuvoton-cir.h b/drivers/media/rc/nuvoton-cir.h
index 1df8235..048135e 100644
--- a/drivers/media/rc/nuvoton-cir.h
+++ b/drivers/media/rc/nuvoton-cir.h
@@ -305,8 +305,11 @@ struct nvt_dev {
 #define CIR_WAKE_IRFIFOSTS_RX_EMPTY0x20
 #define CIR_WAKE_IRFIFOSTS_RX_FULL 0x10
 
-/* CIR Wake FIFO buffer is 67 bytes long */
-#define CIR_WAKE_FIFO_LEN  67
+/*
+ * The CIR Wake FIFO buffer is 67 bytes long, but the stock remote wakes
+ * the system comparing only 65 bytes (fails with this set to 67)
+ */
+#define CIR_WAKE_FIFO_CMP_BYTES65
 /* CIR Wake byte comparison tolerance */
 #define CIR_WAKE_CMP_TOLERANCE 5
 
-- 
1.7.1

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

RE: V4L2 'brainstorming' meeting in Warsaw, March 2011

[Marek Szyprowski]

Hello once more,

After some discussion on #v4l irc channel, I would like to inform that the 
meeting
date has been fixed to my initial proposition: 3 days from 16 to 18 March 2011.

Best regards
--
Marek Szyprowski
Samsung Poland R&D 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: [RFC] HDMI-CEC proposal

[Mauro Carvalho Chehab]

Em 01-03-2011 11:38, Hans Verkuil escreveu:
> Hi Mauro,
> 
> On Tuesday, March 01, 2011 13:28:35 Mauro Carvalho Chehab wrote:
>> Hi Martin,
>>
>> Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu:
>>> Author: Martin Bugge 
>>> Date:  Tue, 1 March 2010
>>> ==
>>>
>>> This is a proposal for adding a Consumer Electronic Control (CEC) API to 
> V4L2.
>>> This document describes the changes and new ioctls needed.
>>>
>>> Version 1.0 (This is first version)
>>>
>>> Background
>>> ==
>>> CEC is a protocol that provides high-level control functions between 
> various audiovisual products.
>>> It is an optional supplement to the High-Definition Multimedia Interface 
> Specification (HDMI).
>>> Physical layer is a one-wire bidirectional serial bus that uses the 
> industry-standard AV.link protocol.
>>>
>>> In short: CEC uses pin 13 on the HDMI connector to transmit and receive 
> small data-packets
>>>   (maximum 16 bytes including a 1 byte header) at low data rates 
> (~400 bits/s).
>>>
>>> A CEC device may have any of 15 logical addresses (0 - 14).
>>> (address 15 is broadcast and some addresses are reserved)
>>>
>>>
>>> References
>>> ==
>>> [1] High-Definition Multimedia Interface Specification version 1.3a,
>>> Supplement 1 Consumer Electronic Control (CEC).
>>> http://www.hdmi.org/manufacturer/specification.aspx
>>>
>>> [2] 
> http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
>>>
>>>
>>> Proposed solution
>>> =
>>>
>>> Two new ioctls:
>>> VIDIOC_CEC_CAP (read)
>>> VIDIOC_CEC_CMD (read/write)
>>
>> How this proposal will interact with RC core? The way I see it, HDMI-CEC is 
> just a way to get/send
>> Remote Controller data, and should be interacting with the proper Kernel 
> subsystems, e. g.,
>> with Remote Controller and input/event subsystems.
> 
> I knew you were going to mention this :-)
> 
> Actually, while CEC does support IR commands, this is only a very small part 
> of the standard. Routing IR commands to the IR core is possible to do, 
> although it is not in this initial version. Should this be needed, then a 
> flag 
> can be created that tells V4L to route IR commands to the IR core.
> 
> This should be optional, though, because if you are a repeater you do not 
> want 
> to pass such IR commands to the IR core, instead you want to retransmit them 
> to a CEC output.
> 
>>
>> I don't think we need two ioctls for that, as RC capabilities are already 
> exported via
>> sysfs, and we have two interfaces already for receiving events (input/event 
> and lirc).
>> For sending, lirc interface might be used, but it is currently focused only 
> on sending
>> raw pulse/space sequences. So, we'll need to add some capability there for 
> IR/CEC TX.
>> I had a few discussions about that with Jarod, but we didn't write yet an 
> interface for it.
> 
> Again, CEC != IR. All you need is a simple API to be able to send and receive 
> CEC packets and a libcec that you can use to do the topology discovery and 
> send/receive the commands. You don't want nor need that in the kernel.
> 
> The only place where routing things to the IR core is useful is when someone 
> points a remote at a TV (for example), which then passes it over CEC to your 
> device which is not a repeater but can actually handle the remote command.
> 
> This is a future extension, though.

There are two separate things when dealing with CEC: the low-level kernel
implementation of a bus for connecting with CEC devices, and userspace APIs
for using its features.

If you were needing it only internally inside the kernel, there's no need for 
new ioctl's. So, your proposal seems to add a raw interface for it, and do 
all the work in userspace.

An alternative approach, that it is the way most Kernel API's do is to write/use
higher userspace APIs, abstracting the hardware internals. V4L, DVB and RC, 
input/event,
vfs, tty, etc are good examples of how we do APIs in Linux. We should only go 
to a raw API if the high-level ones won't work. 

Also, a raw-level implementation of CEC may/will interfere on higher level
interfaces. For example, assuming that we have both raw and RC interfaces using 
HDMI-CIC, a raw access on one process during a RC reception or transmit could 
interfere on another process using the high-level interface for RC (as a raw
access to a block device may actually corrupt data). So, raw interfaces are
evil, and generally require CAP_SYS_ADMIN.

So, I think we should first discuss what are the needs, and then discuss how
to implement them.

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] HDMI-CEC proposal

[Martin Bugge (marbugge)]

On 03/01/2011 02:47 PM, Andy Walls wrote:

On Tue, 2011-03-01 at 10:59 +0100, Martin Bugge (marbugge) wrote:
   

Author: Martin Bugge
Date:  Tue, 1 March 2010
==

This is a proposal for adding a Consumer Electronic Control (CEC) API to
V4L2.
This document describes the changes and new ioctls needed.

Version 1.0 (This is first version)

Background
==
CEC is a protocol that provides high-level control functions between
various audiovisual products.
It is an optional supplement to the High-Definition Multimedia Interface
Specification (HDMI).
Physical layer is a one-wire bidirectional serial bus that uses the
industry-standard AV.link protocol.

In short: CEC uses pin 13 on the HDMI connector to transmit and receive
small data-packets
(maximum 16 bytes including a 1 byte header) at low data
rates (~400 bits/s).

A CEC device may have any of 15 logical addresses (0 - 14).
(address 15 is broadcast and some addresses are reserved)


References
==
[1] High-Definition Multimedia Interface Specification version 1.3a,
  Supplement 1 Consumer Electronic Control (CEC).
  http://www.hdmi.org/manufacturer/specification.aspx

[2]
http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
 


Hi Martin,

After reading the whitepaper, and the the general purpose nature of your
proposed API calls, I'm wondering if a socket interface wouldn't be
appropriate.

The CEC bus seems to be designed as a network.  A broadcast medium, with
multiport devices (switches), physical (MAC) addresses in dotted decimal
notation (1.0.0.0), dynamic logical address assignment, arbitration
(Media Access Control), etc.  The whitepaper even suggests OSI layers,
using the term PHY in a few places.


A network interface could be implemented something like what is done for
SLIP in figure 2 here (compare with figure 1):

http://www.linux.it/~rubini/docs/serial/serial.html


Using that diagram as a guide, a socket interface would need a CEC tty
line discipline, CEC network device, and code to hook the CEC serial
device to the tty layer.  Multiple CEC serial devices would show up as
multiple network interfaces.

Once a network device is available, user-space could then use AF_PACKET
sockets.  If CEC's layers are standardized enough, a new address family
could be added to the kernel, I guess.

Of course, all that is a lot of work.  Since Cisco should have some
networking experts hanging around, maybe it wouldn't be too hard. ;)


Regards,
Andy
   


Hi Andy and thank you.

I agree its always nice to strive for a generic solution, but I don't 
think I'm able to

get hold of the resources required.

In CEC the physical address is determined by the edid information from 
the HDMI sink,

or for the HDMI sink its HDMI port number.

While the logical address describes the type of device, TV, Recorder, 
Tuner, etc.


From that point of view I do think that the CEC protocol is closly 
connected to the HDMI connector,

such that it belongs together with a video device.

But I will ask my "mentor" for advice.

Regards,
Martin

   

Proposed solution
=

Two new ioctls:
  VIDIOC_CEC_CAP (read)
  VIDIOC_CEC_CMD (read/write)

VIDIOC_CEC_CAP:
---

struct vl2_cec_cap {
 __u32 logicaldevices;
 __u32 reserved[7];
};

The capability ioctl will return the number of logical devices/addresses
which can be
simultaneously supported on this HW.
  0:   This HW don't support CEC.
  1 ->  14: This HW supports n logical devices simultaneously.

VIDIOC_CEC_CMD:
---

struct v4l2_cec_cmd {
  __u32 cmd;
  __u32 reserved[7];
  union {
  struct {
  __u32 index;
  __u32 enable;
  __u32 addr;
  } conf;
  struct {
  __u32 len;
  __u8  msg[16];
  __u32 status;
  } data;
  __u32 raw[8];
  };
};

Alternatively the data struct could be:
  struct {
  __u8  initiator;
  __u8  destination;
  __u8  len;
  __u8  msg[15];
  __u32 status;
  } data;

Commands:

#define V4L2_CEC_CMD_CONF  (1)
#define V4L2_CEC_CMD_TX(2)
#define V4L2_CEC_CMD_RX(3)

Tx status field:

#define V4L2_CEC_STAT_TX_OK(0)
#define V4L2_CEC_STAT_TX_ARB_LOST  (1)
#define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)

The command ioctl is used both for configuration and to receive/transmit
data.

* The configuration command must be done for each logical device address
which is to be enabled on this HW. Maximum number of logical devices
is found with the capability ioctl.
  conf:
   index:  0 ->  number_of_logical_devices-1
   enable: true/false
   addr:   logical address

By default all logical devices are disabled.

* Tx/Rx command
  data:
   len:length of message (data + header)
   msg:the raw 

Re: omap3-isp: can't register subdev for new sensor driver mt9t001

[Bastian Hecht]

Hi,

when you try to set a format in the pipeline, the sensor gets asked if
he can support this solution.

static int xxx_get_format(struct v4l2_subdev *subdev,
  struct v4l2_subdev_fh *fh,
  struct v4l2_subdev_format *fmt)
{

struct v4l2_mbus_framefmt format;

format.code = V4L2_MBUS_FMT_SGRBG10_1X10;
format.width = MT9P031_MAX_WIDTH;
format.height = MT9P031_MAX_HEIGHT;
format.field = V4L2_FIELD_NONE;
format.colorspace = V4L2_COLORSPACE_SRGB;

fmt->format = format;
}


This is a simplified version of what you might need. Look the
mechanisms up in other code samples.
The function must be registered in
static struct v4l2_subdev_pad_ops framix_subdev_pad_ops = {
.enum_mbus_code = mt9t001_enum_mbus_code,
.enum_frame_size = mt9t001_enum_frame_size,
.get_fmt = xxx_get_format,   <
.set_fmt = mt9t001_set_format,
.get_crop = mt9t001_get_crop,
.set_crop = mt9t001_set_crop,
};


cheers,

 Bastian


2011/2/28 Loïc Akue :
> Hi,
>
> Thank you for your reply,
>
> I finally solved my problem. My saa7113 driver code wasn't fully adapted to
> work with the new media framework.
> I tried to use the media-ctl and yavta programs for testing. Here are my
> logs :
>
> 
> ./media-ctl -r -l '"saa7115 3-0024":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
> CCDC":1->"OMAP3 ISP CCDC output":0[1]'
> Resetting all links to inactive
> Setting up link 16:0 -> 5:0 [1]
> Setting up link 5:1 -> 6:0 [1]
>
> root@cm-t35:~# ./media-ctl -f '"saa7115 3-0024":0[UYVY 720x480], "OMAP3 ISP
> CCDC":2[UYVY 720x480]'
> Setting up format UYVY 720x480 on pad saa7115 3-0024/0
> Unable to set format: Invalid argument (-22)
>
> 
> Could it be due to a lack of information provided by my saa7113 driver, or
> is it due to a bad understanding of the media-ctl app.
>
> Regards
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] HDMI-CEC proposal

[Hans Verkuil]

Hi Mauro,

On Tuesday, March 01, 2011 13:28:35 Mauro Carvalho Chehab wrote:
> Hi Martin,
> 
> Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu:
> > Author: Martin Bugge 
> > Date:  Tue, 1 March 2010
> > ==
> > 
> > This is a proposal for adding a Consumer Electronic Control (CEC) API to 
V4L2.
> > This document describes the changes and new ioctls needed.
> > 
> > Version 1.0 (This is first version)
> > 
> > Background
> > ==
> > CEC is a protocol that provides high-level control functions between 
various audiovisual products.
> > It is an optional supplement to the High-Definition Multimedia Interface 
Specification (HDMI).
> > Physical layer is a one-wire bidirectional serial bus that uses the 
industry-standard AV.link protocol.
> > 
> > In short: CEC uses pin 13 on the HDMI connector to transmit and receive 
small data-packets
> >   (maximum 16 bytes including a 1 byte header) at low data rates 
(~400 bits/s).
> > 
> > A CEC device may have any of 15 logical addresses (0 - 14).
> > (address 15 is broadcast and some addresses are reserved)
> > 
> > 
> > References
> > ==
> > [1] High-Definition Multimedia Interface Specification version 1.3a,
> > Supplement 1 Consumer Electronic Control (CEC).
> > http://www.hdmi.org/manufacturer/specification.aspx
> > 
> > [2] 
http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
> > 
> > 
> > Proposed solution
> > =
> > 
> > Two new ioctls:
> > VIDIOC_CEC_CAP (read)
> > VIDIOC_CEC_CMD (read/write)
> 
> How this proposal will interact with RC core? The way I see it, HDMI-CEC is 
just a way to get/send
> Remote Controller data, and should be interacting with the proper Kernel 
subsystems, e. g.,
> with Remote Controller and input/event subsystems.

I knew you were going to mention this :-)

Actually, while CEC does support IR commands, this is only a very small part 
of the standard. Routing IR commands to the IR core is possible to do, 
although it is not in this initial version. Should this be needed, then a flag 
can be created that tells V4L to route IR commands to the IR core.

This should be optional, though, because if you are a repeater you do not want 
to pass such IR commands to the IR core, instead you want to retransmit them 
to a CEC output.

> 
> I don't think we need two ioctls for that, as RC capabilities are already 
exported via
> sysfs, and we have two interfaces already for receiving events (input/event 
and lirc).
> For sending, lirc interface might be used, but it is currently focused only 
on sending
> raw pulse/space sequences. So, we'll need to add some capability there for 
IR/CEC TX.
> I had a few discussions about that with Jarod, but we didn't write yet an 
interface for it.

Again, CEC != IR. All you need is a simple API to be able to send and receive 
CEC packets and a libcec that you can use to do the topology discovery and 
send/receive the commands. You don't want nor need that in the kernel.

The only place where routing things to the IR core is useful is when someone 
points a remote at a TV (for example), which then passes it over CEC to your 
device which is not a repeater but can actually handle the remote command.

This is a future extension, though.

Regards,

Hans

> 
> 
> > 
> > VIDIOC_CEC_CAP:
> > ---
> > 
> > struct vl2_cec_cap {
> >__u32 logicaldevices;
> >__u32 reserved[7];
> > };
> > 
> > The capability ioctl will return the number of logical devices/addresses 
which can be
> > simultaneously supported on this HW.
> > 0:   This HW don't support CEC.
> > 1 -> 14: This HW supports n logical devices simultaneously.
> > 
> > VIDIOC_CEC_CMD:
> > ---
> > 
> > struct v4l2_cec_cmd {
> > __u32 cmd;
> > __u32 reserved[7];
> > union {
> > struct {
> > __u32 index;
> > __u32 enable;
> > __u32 addr;
> > } conf;
> > struct {
> > __u32 len;
> > __u8  msg[16];
> > __u32 status;
> > } data;
> > __u32 raw[8];
> > };
> > };
> > 
> > Alternatively the data struct could be:
> > struct {
> > __u8  initiator;
> > __u8  destination;
> > __u8  len;
> > __u8  msg[15];
> > __u32 status;
> > } data;
> > 
> > Commands:
> > 
> > #define V4L2_CEC_CMD_CONF  (1)
> > #define V4L2_CEC_CMD_TX(2)
> > #define V4L2_CEC_CMD_RX(3)
> > 
> > Tx status field:
> > 
> > #define V4L2_CEC_STAT_TX_OK(0)
> > #define V4L2_CEC_STAT_TX_ARB_LOST  (1)
> > #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
> > 
> > The command ioctl is used both for configuration and to receive/transmit 
data.
> > 
> > * The configuration command must be done for each logical device address
> >   which is to be enabled on this HW. Maximum number of logical devices
> >   is found with the capability ioctl.
> > conf

Re: [PATCH v22 3/3] ASoC: WL1273 FM radio: Access I2C IO functions through pointers.

[Samuel Ortiz]

On Tue, Mar 01, 2011 at 03:44:45PM +0200, Matti J. Aaltonen wrote:
> On Tue, 2011-03-01 at 13:23 +, ext Mark Brown wrote:
> > On Tue, Mar 01, 2011 at 03:10:37PM +0200, Matti J. Aaltonen wrote:
> > > These changes are needed to keep up with the changes in the
> > > MFD core and V4L2 parts of the wl1273 FM radio driver.
> > > 
> > > Use function pointers instead of exported functions for I2C IO.
> > > Also move all preprocessor constants from the wl1273.h to
> > > include/linux/mfd/wl1273-core.h.
> > > 
> > > Also update the year in the copyright statement.
> > > 
> > > Signed-off-by: Matti J. Aaltonen 
> > 
> > Acked-by: Mark Brown 
> > 
> > *Please* keep acks unless you're making substantial changes to
> > repostings.
> 
> OK, I see, I should have added the ACKs to the relevant driver files
> instead of copying them to the cover letter...
Yes, it makes it easier for the maintainer taking your patches.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.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: [RFC] HDMI-CEC proposal

[Andy Walls]

On Tue, 2011-03-01 at 10:59 +0100, Martin Bugge (marbugge) wrote:
> Author: Martin Bugge 
> Date:  Tue, 1 March 2010
> ==
> 
> This is a proposal for adding a Consumer Electronic Control (CEC) API to 
> V4L2.
> This document describes the changes and new ioctls needed.
> 
> Version 1.0 (This is first version)
> 
> Background
> ==
> CEC is a protocol that provides high-level control functions between 
> various audiovisual products.
> It is an optional supplement to the High-Definition Multimedia Interface 
> Specification (HDMI).
> Physical layer is a one-wire bidirectional serial bus that uses the 
> industry-standard AV.link protocol.
> 
> In short: CEC uses pin 13 on the HDMI connector to transmit and receive 
> small data-packets
>(maximum 16 bytes including a 1 byte header) at low data 
> rates (~400 bits/s).
> 
> A CEC device may have any of 15 logical addresses (0 - 14).
> (address 15 is broadcast and some addresses are reserved)
> 
> 
> References
> ==
> [1] High-Definition Multimedia Interface Specification version 1.3a,
>  Supplement 1 Consumer Electronic Control (CEC).
>  http://www.hdmi.org/manufacturer/specification.aspx
> 
> [2] 
> http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf


Hi Martin,

After reading the whitepaper, and the the general purpose nature of your
proposed API calls, I'm wondering if a socket interface wouldn't be
appropriate.

The CEC bus seems to be designed as a network.  A broadcast medium, with
multiport devices (switches), physical (MAC) addresses in dotted decimal
notation (1.0.0.0), dynamic logical address assignment, arbitration
(Media Access Control), etc.  The whitepaper even suggests OSI layers,
using the term PHY in a few places.


A network interface could be implemented something like what is done for
SLIP in figure 2 here (compare with figure 1):

http://www.linux.it/~rubini/docs/serial/serial.html


Using that diagram as a guide, a socket interface would need a CEC tty
line discipline, CEC network device, and code to hook the CEC serial
device to the tty layer.  Multiple CEC serial devices would show up as
multiple network interfaces.

Once a network device is available, user-space could then use AF_PACKET
sockets.  If CEC's layers are standardized enough, a new address family
could be added to the kernel, I guess.

Of course, all that is a lot of work.  Since Cisco should have some
networking experts hanging around, maybe it wouldn't be too hard. ;)


Regards,
Andy

> Proposed solution
> =
> 
> Two new ioctls:
>  VIDIOC_CEC_CAP (read)
>  VIDIOC_CEC_CMD (read/write)
> 
> VIDIOC_CEC_CAP:
> ---
> 
> struct vl2_cec_cap {
> __u32 logicaldevices;
> __u32 reserved[7];
> };
> 
> The capability ioctl will return the number of logical devices/addresses 
> which can be
> simultaneously supported on this HW.
>  0:   This HW don't support CEC.
>  1 -> 14: This HW supports n logical devices simultaneously.
> 
> VIDIOC_CEC_CMD:
> ---
> 
> struct v4l2_cec_cmd {
>  __u32 cmd;
>  __u32 reserved[7];
>  union {
>  struct {
>  __u32 index;
>  __u32 enable;
>  __u32 addr;
>  } conf;
>  struct {
>  __u32 len;
>  __u8  msg[16];
>  __u32 status;
>  } data;
>  __u32 raw[8];
>  };
> };
> 
> Alternatively the data struct could be:
>  struct {
>  __u8  initiator;
>  __u8  destination;
>  __u8  len;
>  __u8  msg[15];
>  __u32 status;
>  } data;
> 
> Commands:
> 
> #define V4L2_CEC_CMD_CONF  (1)
> #define V4L2_CEC_CMD_TX(2)
> #define V4L2_CEC_CMD_RX(3)
> 
> Tx status field:
> 
> #define V4L2_CEC_STAT_TX_OK(0)
> #define V4L2_CEC_STAT_TX_ARB_LOST  (1)
> #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
> 
> The command ioctl is used both for configuration and to receive/transmit 
> data.
> 
> * The configuration command must be done for each logical device address
>which is to be enabled on this HW. Maximum number of logical devices
>is found with the capability ioctl.
>  conf:
>   index:  0 -> number_of_logical_devices-1
>   enable: true/false
>   addr:   logical address
> 
>By default all logical devices are disabled.
> 
> * Tx/Rx command
>  data:
>   len:length of message (data + header)
>   msg:the raw CEC message received/transmitted
>   status: when the driver is in blocking mode it gives the 
> result for transmit.
> 
> Events
> --
> 
> In the case of non-blocking mode the driver will issue the following events:
> 
> V4L2_EVENT_CEC_TX
> V4L2_EVENT_CEC_RX
> 
> V4L2_EVENT_CEC_TX
> -
>   * transmit is complete with the following status:
> Add an additional struct to the struct v4l2_event
> 
> struct v4l2_event_c

Re: [PATCH v22 3/3] ASoC: WL1273 FM radio: Access I2C IO functions through pointers.

[Matti J. Aaltonen]

On Tue, 2011-03-01 at 13:23 +, ext Mark Brown wrote:
> On Tue, Mar 01, 2011 at 03:10:37PM +0200, Matti J. Aaltonen wrote:
> > These changes are needed to keep up with the changes in the
> > MFD core and V4L2 parts of the wl1273 FM radio driver.
> > 
> > Use function pointers instead of exported functions for I2C IO.
> > Also move all preprocessor constants from the wl1273.h to
> > include/linux/mfd/wl1273-core.h.
> > 
> > Also update the year in the copyright statement.
> > 
> > Signed-off-by: Matti J. Aaltonen 
> 
> Acked-by: Mark Brown 
> 
> *Please* keep acks unless you're making substantial changes to
> repostings.

OK, I see, I should have added the ACKs to the relevant driver files
instead of copying them to the cover letter...

Cheers,
Matti

> --
> 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: [PATCH v22 3/3] ASoC: WL1273 FM radio: Access I2C IO functions through pointers.

[Mark Brown]

On Tue, Mar 01, 2011 at 03:10:37PM +0200, Matti J. Aaltonen wrote:
> These changes are needed to keep up with the changes in the
> MFD core and V4L2 parts of the wl1273 FM radio driver.
> 
> Use function pointers instead of exported functions for I2C IO.
> Also move all preprocessor constants from the wl1273.h to
> include/linux/mfd/wl1273-core.h.
> 
> Also update the year in the copyright statement.
> 
> Signed-off-by: Matti J. Aaltonen 

Acked-by: Mark Brown 

*Please* keep acks unless you're making substantial changes to
repostings.
--
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 0/3] Fix the remaining VIDIOC_*_OLD bits

[Mauro Carvalho Chehab]

The VIDIOC_*_OLD ioctls passed away, but there are still some places
that thinks that they're still alive. Tell them about the death of
those legacy stuff.

Mauro Carvalho Chehab (3):
  matrox: Remove legacy VIDIOC_*_OLD ioctls
  [media] videodev2.h.xml: Update to reflect videodev2.h changes
  [media] DocBook: Document the removal of the old VIDIOC_*_OLD ioctls

 Documentation/DocBook/v4l/compat.xml  |   20 +++--
 Documentation/DocBook/v4l/videodev2.h.xml |  141 ++---
 drivers/video/matrox/matroxfb_base.c  |3 -
 3 files changed, 143 insertions(+), 21 deletions(-)

--
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 3/3] [media] DocBook: Document the removal of the old VIDIOC_*_OLD ioctls

[Mauro Carvalho Chehab]

Those ioctls passed away. Properly documented it.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/v4l/compat.xml 
b/Documentation/DocBook/v4l/compat.xml
index 223c24c..4d74bf2 100644
--- a/Documentation/DocBook/v4l/compat.xml
+++ b/Documentation/DocBook/v4l/compat.xml
@@ -1711,8 +1711,8 @@ ioctl would enumerate the available audio inputs. An 
ioctl to
 determine the current audio input, if more than one combines with the
 current video input, did not exist. So
 VIDIOC_G_AUDIO was renamed to
-VIDIOC_G_AUDIO_OLD, this ioctl will be removed in
-the future. The &VIDIOC-ENUMAUDIO; ioctl was added to enumerate
+VIDIOC_G_AUDIO_OLD, this ioctl was removed on
+Kernel 2.6.39. The &VIDIOC-ENUMAUDIO; ioctl was added to enumerate
 audio inputs, while &VIDIOC-G-AUDIO; now reports the current audio
 input.
  The same changes were made to &VIDIOC-G-AUDOUT; and
@@ -1726,7 +1726,7 @@ must be updated to successfully compile again.
  The &VIDIOC-OVERLAY; ioctl was incorrectly defined with
 write-read parameter. It was changed to write-only, while the write-read
 version was renamed to VIDIOC_OVERLAY_OLD. The old
-ioctl will be removed in the future. Until further the "videodev"
+ioctl was removed on Kernel 2.6.39. Until further the "videodev"
 kernel module will automatically translate to the new version, so drivers
 must be recompiled, but not applications.

@@ -1744,7 +1744,7 @@ surface can be seen.
 defined with write-only parameter, inconsistent with other ioctls
 modifying their argument. They were changed to write-read, while a
 _OLD suffix was added to the write-only versions.
-The old ioctls will be removed in the future. Drivers and
+The old ioctls were removed on Kernel 2.6.39. Drivers and
 applications assuming a constant parameter need an update.

   
@@ -1815,8 +1815,8 @@ yet to be addressed, for details see The &VIDIOC-CROPCAP; ioctl was incorrectly defined
 with read-only parameter. It is now defined as write-read ioctl, while
 the read-only version was renamed to
-VIDIOC_CROPCAP_OLD. The old ioctl will be removed
-in the future.
+VIDIOC_CROPCAP_OLD. The old ioctl was removed
+on Kernel 2.6.39.

   
 
@@ -2364,6 +2364,14 @@ that used it. It was originally scheduled for removal in 
2.6.35.
 
   
 
+
+  V4L2 in Linux 2.6.39
+  
+
+  The old VIDIOC_*_OLD symbols and V4L1 support were 
removed.
+
+  
+
 
 
   Relation of V4L2 to other Linux multimedia APIs
-- 
1.7.1

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

[PATCH 2/3] [media] videodev2.h.xml: Update to reflect videodev2.h changes

[Mauro Carvalho Chehab]

A few changes happened at videodev2.h:
- Addition of multiplane API;
- removal of VIDIOC_*_OLD ioctls;
- a few more video standards.

Update the file to reflect the latest changes.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/v4l/videodev2.h.xml 
b/Documentation/DocBook/v4l/videodev2.h.xml
index 325b23b..2b796a2 100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -71,6 +71,7 @@
  * Moved from videodev.h
  */
 #define VIDEO_MAX_FRAME   32
+#define VIDEO_MAX_PLANES   8
 
 #ifndef __KERNEL__
 
@@ -158,9 +159,23 @@ enum v4l2_buf_type {
 /* Experimental */
 V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
 #endif
+V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 9,
+V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE  = 10,
 V4L2_BUF_TYPE_PRIVATE  = 0x80,
 };
 
+#define V4L2_TYPE_IS_MULTIPLANAR(type)  \
+((type) == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE   \
+ || (type) == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
+
+#define V4L2_TYPE_IS_OUTPUT(type)   \
+((type) == V4L2_BUF_TYPE_VIDEO_OUTPUT   \
+ || (type) == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE \
+ || (type) == V4L2_BUF_TYPE_VIDEO_OVERLAY   \
+ || (type) == V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY\
+ || (type) == V4L2_BUF_TYPE_VBI_OUTPUT  \
+ || (type) == V4L2_BUF_TYPE_SLICED_VBI_OUTPUT)
+
 enum v4l2_tuner_type {
 V4L2_TUNER_RADIO = 1,
 V4L2_TUNER_ANALOG_TV = 2,
@@ -246,6 +261,11 @@ struct v4l2_capability {
 #define V4L2_CAP_HW_FREQ_SEEK   0x0400  /* Can do hardware 
frequency seek  */
 #define V4L2_CAP_RDS_OUTPUT 0x0800  /* Is an RDS encoder */
 
+/* Is a video capture device that supports multiplanar formats */
+#define V4L2_CAP_VIDEO_CAPTURE_MPLANE   0x1000
+/* Is a video output device that supports multiplanar formats */
+#define V4L2_CAP_VIDEO_OUTPUT_MPLANE0x2000
+
 #define V4L2_CAP_TUNER  0x0001  /* has a tuner */
 #define V4L2_CAP_AUDIO  0x0002  /* has audio support */
 #define V4L2_CAP_RADIO  0x0004  /* is a radio device */
@@ -320,6 +340,13 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_NV16
v4l2_fourcc('N', 'V', '1', '6') /* 16  Y/CbCr 4:2:2  */
 #define V4L2_PIX_FMT_NV61
v4l2_fourcc('N', 'V', '6', '1') /* 16  Y/CrCb 4:2:2  */
 
+/* two non contiguous planes - one Y, one Cr + Cb interleaved  */
+#define V4L2_PIX_FMT_NV12M   
v4l2_fourcc('N', 'M', '1', '2') /* 12  Y/CbCr 4:2:0  */
+#define V4L2_PIX_FMT_NV12MT  
v4l2_fourcc('T', 'M', '1', '2') /* 12  Y/CbCr 4:2:0 64x32 macroblocks */
+
+/* three non contiguous planes - Y, Cb, Cr */
+#define V4L2_PIX_FMT_YUV420M 
v4l2_fourcc('Y', 'M', '1', '2') /* 12  YUV420 planar */
+
 /* Bayer formats - see http://www.siliconimaging.com/RGB%20Bayer.htm */
 #define V4L2_PIX_FMT_SBGGR8  
v4l2_fourcc('B', 'A', '8', '1') /*  8  BGBG.. GRGR.. */
 #define V4L2_PIX_FMT_SGBRG8  
v4l2_fourcc('G', 'B', 'R', 'G') /*  8  GBGB.. RGRG.. */
@@ -518,6 +545,62 @@ struct v4l2_requestbuffers {
 __u32   reserved[2];
 };
 
+/**
+ * struct v4l2_plane - plane info for 
multi-planar buffers
+ * @bytesused:  number of bytes occupied by data in the plane (payload)
+ * @length: size of this plane (NOT the payload) in bytes
+ * @mem_offset: when memory in the associated struct v4l2_buffer is
+ *  V4L2_MEMORY_MMAP, equals the offset from the start of
+ *  the device memory for this plane (or is a "cookie" that
+ *  should be passed to mmap() called on the video node)
+ * @userptr:when memory is V4L2_MEMORY_USERPTR, a userspace pointer
+ *  pointing to this plane
+ * @data_offset:offset in the plane to the start of data; usually 0,
+ *  unless there is a header in front of the data
+ *
+ * Multi-planar buffers consist of one or more planes, e.g. an YCbCr buffer
+ * with two planes can have one plane for Y, and another for interleaved CbCr
+ * components. Each plane can reside in a separate memory buffer, or even in
+ * a completely separate memory node (e.g. in embedded devices).
+ */
+struct v4l2_plane {
+__u32   bytesused;
+__u32   length;
+union {
+__u32   mem_offset;
+unsigned long   userptr;
+} m;
+__u32   data_offset;
+__u32   reserved[11];
+};
+
+/**
+ * struct v4l2_buffer - video buffer info
+ * @index:  id number of the buffer
+ * @type:   buffer type (type == *_MPLANE for multiplanar buffers)
+ * @bytesused:  number of bytes occupied by data in the buffer (payload);
+ * 

[PATCH 1/3] matrox: Remove legacy VIDIOC_*_OLD ioctls

[Mauro Carvalho Chehab]

Those ioctls were produced by the wrong arguments for _IO macros,
and were replaced by fixed versions on an early 2.6 kernel.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/video/matrox/matroxfb_base.c 
b/drivers/video/matrox/matroxfb_base.c
index a082deb..8c9dbac 100644
--- a/drivers/video/matrox/matroxfb_base.c
+++ b/drivers/video/matrox/matroxfb_base.c
@@ -101,8 +101,6 @@
 
 #include 
 
-#define __OLD_VIDIOC_
-
 #include "matroxfb_base.h"
 #include "matroxfb_misc.h"
 #include "matroxfb_accel.h"
@@ -1152,7 +1150,6 @@ static int matroxfb_ioctl(struct fb_info *info,
return -EFAULT;
return err;
}
-   case VIDIOC_S_CTRL_OLD:
case VIDIOC_S_CTRL:
{
struct v4l2_control ctrl;
-- 
1.7.1


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

[PATCH v22 2/3] V4L2: WL1273 FM Radio: TI WL1273 FM radio driver

[Matti J. Aaltonen]

This module implements V4L2 controls for the Texas Instruments
WL1273 FM Radio and handles the communication with the chip.

Signed-off-by: Matti J. Aaltonen 
---
 drivers/media/radio/radio-wl1273.c |  360 +++-
 1 files changed, 106 insertions(+), 254 deletions(-)

diff --git a/drivers/media/radio/radio-wl1273.c 
b/drivers/media/radio/radio-wl1273.c
index 7ecc8e6..9e177dc 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -1,7 +1,7 @@
 /*
  * Driver for the Texas Instruments WL1273 FM radio.
  *
- * Copyright (C) 2010 Nokia Corporation
+ * Copyright (C) 2011 Nokia Corporation
  * Author: Matti J. Aaltonen 
  *
  * This program is free software; you can redistribute it and/or
@@ -104,58 +104,6 @@ static unsigned int rds_buf = 100;
 module_param(rds_buf, uint, 0);
 MODULE_PARM_DESC(rds_buf, "Number of RDS buffer entries. Default = 100");
 
-static int wl1273_fm_read_reg(struct wl1273_core *core, u8 reg, u16 *value)
-{
-   struct i2c_client *client = core->client;
-   u8 b[2];
-   int r;
-
-   r = i2c_smbus_read_i2c_block_data(client, reg, sizeof(b), b);
-   if (r != 2) {
-   dev_err(&client->dev, "%s: Read: %d fails.\n", __func__, reg);
-   return -EREMOTEIO;
-   }
-
-   *value = (u16)b[0] << 8 | b[1];
-
-   return 0;
-}
-
-static int wl1273_fm_write_cmd(struct wl1273_core *core, u8 cmd, u16 param)
-{
-   struct i2c_client *client = core->client;
-   u8 buf[] = { (param >> 8) & 0xff, param & 0xff };
-   int r;
-
-   r = i2c_smbus_write_i2c_block_data(client, cmd, sizeof(buf), buf);
-   if (r) {
-   dev_err(&client->dev, "%s: Cmd: %d fails.\n", __func__, cmd);
-   return r;
-   }
-
-   return 0;
-}
-
-static int wl1273_fm_write_data(struct wl1273_core *core, u8 *data, u16 len)
-{
-   struct i2c_client *client = core->client;
-   struct i2c_msg msg;
-   int r;
-
-   msg.addr = client->addr;
-   msg.flags = 0;
-   msg.buf = data;
-   msg.len = len;
-
-   r = i2c_transfer(client->adapter, &msg, 1);
-   if (r != 1) {
-   dev_err(&client->dev, "%s: write error.\n", __func__);
-   return -EREMOTEIO;
-   }
-
-   return 0;
-}
-
 static int wl1273_fm_write_fw(struct wl1273_core *core,
  __u8 *fw, int len)
 {
@@ -188,94 +136,6 @@ static int wl1273_fm_write_fw(struct wl1273_core *core,
return r;
 }
 
-/**
- * wl1273_fm_set_audio() - Set audio mode.
- * @core:  A pointer to the device struct.
- * @new_mode:  The new audio mode.
- *
- * Audio modes are WL1273_AUDIO_DIGITAL and WL1273_AUDIO_ANALOG.
- */
-static int wl1273_fm_set_audio(struct wl1273_core *core, unsigned int new_mode)
-{
-   int r = 0;
-
-   if (core->mode == WL1273_MODE_OFF ||
-   core->mode == WL1273_MODE_SUSPENDED)
-   return -EPERM;
-
-   if (core->mode == WL1273_MODE_RX && new_mode == WL1273_AUDIO_DIGITAL) {
-   r = wl1273_fm_write_cmd(core, WL1273_PCM_MODE_SET,
-   WL1273_PCM_DEF_MODE);
-   if (r)
-   goto out;
-
-   r = wl1273_fm_write_cmd(core, WL1273_I2S_MODE_CONFIG_SET,
-   core->i2s_mode);
-   if (r)
-   goto out;
-
-   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_ENABLE,
-   WL1273_AUDIO_ENABLE_I2S);
-   if (r)
-   goto out;
-
-   } else if (core->mode == WL1273_MODE_RX &&
-  new_mode == WL1273_AUDIO_ANALOG) {
-   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_ENABLE,
-   WL1273_AUDIO_ENABLE_ANALOG);
-   if (r)
-   goto out;
-
-   } else if (core->mode == WL1273_MODE_TX &&
-  new_mode == WL1273_AUDIO_DIGITAL) {
-   r = wl1273_fm_write_cmd(core, WL1273_I2S_MODE_CONFIG_SET,
-   core->i2s_mode);
-   if (r)
-   goto out;
-
-   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_IO_SET,
-   WL1273_AUDIO_IO_SET_I2S);
-   if (r)
-   goto out;
-
-   } else if (core->mode == WL1273_MODE_TX &&
-  new_mode == WL1273_AUDIO_ANALOG) {
-   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_IO_SET,
-   WL1273_AUDIO_IO_SET_ANALOG);
-   if (r)
-   goto out;
-   }
-
-   core->audio_mode = new_mode;
-out:
-   return r;
-}
-
-/**
- * wl1273_fm_set_volume() -Set volume.
- * @core:  A pointer to the device struct.
- * @volume:The new volume value.
- */
-static int wl1273_fm_set_

[PATCH v22 3/3] ASoC: WL1273 FM radio: Access I2C IO functions through pointers.

[Matti J. Aaltonen]

These changes are needed to keep up with the changes in the
MFD core and V4L2 parts of the wl1273 FM radio driver.

Use function pointers instead of exported functions for I2C IO.
Also move all preprocessor constants from the wl1273.h to
include/linux/mfd/wl1273-core.h.

Also update the year in the copyright statement.

Signed-off-by: Matti J. Aaltonen 
---
 sound/soc/codecs/Kconfig  |2 +-
 sound/soc/codecs/wl1273.c |   11 ---
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index c48b23c..9726d6e 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -44,7 +44,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TWL6040 if TWL4030_CORE
select SND_SOC_UDA134X
select SND_SOC_UDA1380 if I2C
-   select SND_SOC_WL1273 if RADIO_WL1273
+   select SND_SOC_WL1273 if MFD_WL1273_CORE
select SND_SOC_WM2000 if I2C
select SND_SOC_WM8350 if MFD_WM8350
select SND_SOC_WM8400 if MFD_WM8400
diff --git a/sound/soc/codecs/wl1273.c b/sound/soc/codecs/wl1273.c
index 861b28f..5836201 100644
--- a/sound/soc/codecs/wl1273.c
+++ b/sound/soc/codecs/wl1273.c
@@ -3,7 +3,7 @@
  *
  * Author:  Matti Aaltonen, 
  *
- * Copyright:   (C) 2010 Nokia Corporation
+ * Copyright:   (C) 2010, 2011 Nokia Corporation
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -179,7 +179,12 @@ static int snd_wl1273_get_audio_route(struct snd_kcontrol 
*kcontrol,
return 0;
 }
 
-static const char *wl1273_audio_route[] = { "Bt", "FmRx", "FmTx" };
+/*
+ * TODO: Implement the audio routing in the driver. Now this control
+ * only indicates the setting that has been done elsewhere (in the user
+ * space).
+ */
+static const char * const wl1273_audio_route[] = { "Bt", "FmRx", "FmTx" };
 
 static int snd_wl1273_set_audio_route(struct snd_kcontrol *kcontrol,
  struct snd_ctl_elem_value *ucontrol)
@@ -239,7 +244,7 @@ static int snd_wl1273_fm_audio_put(struct snd_kcontrol 
*kcontrol,
return 1;
 }
 
-static const char *wl1273_audio_strings[] = { "Digital", "Analog" };
+static const char * const wl1273_audio_strings[] = { "Digital", "Analog" };
 
 static const struct soc_enum wl1273_audio_enum =
SOC_ENUM_SINGLE_EXT(ARRAY_SIZE(wl1273_audio_strings),
-- 
1.6.1.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 v22 1/3] MFD: WL1273 FM Radio: MFD driver for the FM radio.

[Matti J. Aaltonen]

This is the core of the WL1273 FM radio driver, it connects
the two child modules. The two child drivers are
drivers/media/radio/radio-wl1273.c and sound/soc/codecs/wl1273.c.

The radio-wl1273 driver implements the V4L2 interface and communicates
with the device. The ALSA codec offers digital audio, without it only
analog audio is available.

Signed-off-by: Matti J. Aaltonen 
---
 drivers/mfd/Kconfig |2 +-
 drivers/mfd/wl1273-core.c   |  149 ++-
 include/linux/mfd/wl1273-core.h |2 +
 3 files changed, 149 insertions(+), 4 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index fd01836..9db079b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -615,7 +615,7 @@ config MFD_VX855
  and/or vx855_gpio drivers for this to do anything useful.
 
 config MFD_WL1273_CORE
-   tristate
+   tristate "Support for TI WL1273 FM radio."
depends on I2C
select MFD_CORE
default n
diff --git a/drivers/mfd/wl1273-core.c b/drivers/mfd/wl1273-core.c
index d2ecc24..4025a4b 100644
--- a/drivers/mfd/wl1273-core.c
+++ b/drivers/mfd/wl1273-core.c
@@ -1,7 +1,7 @@
 /*
  * MFD driver for wl1273 FM radio and audio codec submodules.
  *
- * Copyright (C) 2010 Nokia Corporation
+ * Copyright (C) 2011 Nokia Corporation
  * Author: Matti Aaltonen 
  *
  * This program is free software; you can redistribute it and/or modify
@@ -31,6 +31,145 @@ static struct i2c_device_id wl1273_driver_id_table[] = {
 };
 MODULE_DEVICE_TABLE(i2c, wl1273_driver_id_table);
 
+static int wl1273_fm_read_reg(struct wl1273_core *core, u8 reg, u16 *value)
+{
+   struct i2c_client *client = core->client;
+   u8 b[2];
+   int r;
+
+   r = i2c_smbus_read_i2c_block_data(client, reg, sizeof(b), b);
+   if (r != 2) {
+   dev_err(&client->dev, "%s: Read: %d fails.\n", __func__, reg);
+   return -EREMOTEIO;
+   }
+
+   *value = (u16)b[0] << 8 | b[1];
+
+   return 0;
+}
+
+static int wl1273_fm_write_cmd(struct wl1273_core *core, u8 cmd, u16 param)
+{
+   struct i2c_client *client = core->client;
+   u8 buf[] = { (param >> 8) & 0xff, param & 0xff };
+   int r;
+
+   r = i2c_smbus_write_i2c_block_data(client, cmd, sizeof(buf), buf);
+   if (r) {
+   dev_err(&client->dev, "%s: Cmd: %d fails.\n", __func__, cmd);
+   return r;
+   }
+
+   return 0;
+}
+
+static int wl1273_fm_write_data(struct wl1273_core *core, u8 *data, u16 len)
+{
+   struct i2c_client *client = core->client;
+   struct i2c_msg msg;
+   int r;
+
+   msg.addr = client->addr;
+   msg.flags = 0;
+   msg.buf = data;
+   msg.len = len;
+
+   r = i2c_transfer(client->adapter, &msg, 1);
+   if (r != 1) {
+   dev_err(&client->dev, "%s: write error.\n", __func__);
+   return -EREMOTEIO;
+   }
+
+   return 0;
+}
+
+/**
+ * wl1273_fm_set_audio() - Set audio mode.
+ * @core:  A pointer to the device struct.
+ * @new_mode:  The new audio mode.
+ *
+ * Audio modes are WL1273_AUDIO_DIGITAL and WL1273_AUDIO_ANALOG.
+ */
+static int wl1273_fm_set_audio(struct wl1273_core *core, unsigned int new_mode)
+{
+   int r = 0;
+
+   if (core->mode == WL1273_MODE_OFF ||
+   core->mode == WL1273_MODE_SUSPENDED)
+   return -EPERM;
+
+   if (core->mode == WL1273_MODE_RX && new_mode == WL1273_AUDIO_DIGITAL) {
+   r = wl1273_fm_write_cmd(core, WL1273_PCM_MODE_SET,
+   WL1273_PCM_DEF_MODE);
+   if (r)
+   goto out;
+
+   r = wl1273_fm_write_cmd(core, WL1273_I2S_MODE_CONFIG_SET,
+   core->i2s_mode);
+   if (r)
+   goto out;
+
+   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_ENABLE,
+   WL1273_AUDIO_ENABLE_I2S);
+   if (r)
+   goto out;
+
+   } else if (core->mode == WL1273_MODE_RX &&
+  new_mode == WL1273_AUDIO_ANALOG) {
+   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_ENABLE,
+   WL1273_AUDIO_ENABLE_ANALOG);
+   if (r)
+   goto out;
+
+   } else if (core->mode == WL1273_MODE_TX &&
+  new_mode == WL1273_AUDIO_DIGITAL) {
+   r = wl1273_fm_write_cmd(core, WL1273_I2S_MODE_CONFIG_SET,
+   core->i2s_mode);
+   if (r)
+   goto out;
+
+   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_IO_SET,
+   WL1273_AUDIO_IO_SET_I2S);
+   if (r)
+   goto out;
+
+   } else if (core->mode == WL1273_MODE_TX &&
+  new_mode == WL1273_AUDIO_ANALOG) {
+   r = wl1273_fm_

[PATCH v22 0/3] ASoC/MFD/V4L2: WL1273 FM Radio Driver

[Matti J. Aaltonen]

Hello.

Thanks for the comment Mark.

On Tue, 2011-03-01 at 11:54 +, ext Mark Brown wrote:
On Tue, Mar 01, 2011 at 10:00:50AM +0200, Matti J. Aaltonen wrote:
> > These changes are needed to keep up with the changes in the
> > MFD core and V4L2 parts of the wl1273 FM radio driver.
> > 
> > Use function pointers instead of exported functions for I2C IO.
> > Also move all preprocessor constants from the wl1273.h to
> > include/linux/mfd/wl1273-core.h.
> > 
> > Also update the year in the copyright statement.
> 
> It's not actually doing that:
> 
> > - * Copyright:   (C) 2010 Nokia Corporation
> > + * Copyright:   (C) 2011 Nokia Corporation
> 
> It's replacing it - portions are still 2010.

Kept also the year 2010 on the copyright line.
 
> Acked-by: Mark Brown 
 

On Tue, 2011-03-01 at 12:43 +0100, ext Samuel Ortiz wrote:
> Acked-by: Samuel Ortiz 

Cheers,
Matti

Matti J. Aaltonen (3):
  MFD: WL1273 FM Radio: MFD driver for the FM radio.
  V4L2: WL1273 FM Radio: TI WL1273 FM radio driver
  ASoC: WL1273 FM radio: Access I2C IO functions through pointers.

 drivers/media/radio/radio-wl1273.c |  360 +++-
 drivers/mfd/Kconfig|2 +-
 drivers/mfd/wl1273-core.c  |  149 +++-
 include/linux/mfd/wl1273-core.h|2 +
 sound/soc/codecs/Kconfig   |2 +-
 sound/soc/codecs/wl1273.c  |   11 +-
 6 files changed, 264 insertions(+), 262 deletions(-)

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

Sony CXD2099AR support

[Ralph Metzler]

Issa Gorissen writes:
 > I have read that this CI chip driver is in staging because some questions on
 > how to handle it are still not answered.
 > 
 > I volunteer to handle this one. I'm a regular java developer, but I'm willing
 > to put effort in learning linux drivers writing.
 > 
 > So Ralph, can you give me some pointers on where the discussion should resume
 > ?
 > 

AFAIR, the only problem was that the old "sec"-Device name was abused. I do
not see a problem in just adding a "cam" or whatever device in
dvb-core and use that. 
Or just rename "sec" since it is no longer used.

Regarding the interface I think it should just remain being like a pipe. 
Using the dvr and demux devices for this just adds overhead. 


-Ralph

--
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] HDMI-CEC proposal

[Mauro Carvalho Chehab]

Hi Martin,

Em 01-03-2011 06:59, Martin Bugge (marbugge) escreveu:
> Author: Martin Bugge 
> Date:  Tue, 1 March 2010
> ==
> 
> This is a proposal for adding a Consumer Electronic Control (CEC) API to V4L2.
> This document describes the changes and new ioctls needed.
> 
> Version 1.0 (This is first version)
> 
> Background
> ==
> CEC is a protocol that provides high-level control functions between various 
> audiovisual products.
> It is an optional supplement to the High-Definition Multimedia Interface 
> Specification (HDMI).
> Physical layer is a one-wire bidirectional serial bus that uses the 
> industry-standard AV.link protocol.
> 
> In short: CEC uses pin 13 on the HDMI connector to transmit and receive small 
> data-packets
>   (maximum 16 bytes including a 1 byte header) at low data rates 
> (~400 bits/s).
> 
> A CEC device may have any of 15 logical addresses (0 - 14).
> (address 15 is broadcast and some addresses are reserved)
> 
> 
> References
> ==
> [1] High-Definition Multimedia Interface Specification version 1.3a,
> Supplement 1 Consumer Electronic Control (CEC).
> http://www.hdmi.org/manufacturer/specification.aspx
> 
> [2] http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
> 
> 
> Proposed solution
> =
> 
> Two new ioctls:
> VIDIOC_CEC_CAP (read)
> VIDIOC_CEC_CMD (read/write)

How this proposal will interact with RC core? The way I see it, HDMI-CEC is 
just a way to get/send
Remote Controller data, and should be interacting with the proper Kernel 
subsystems, e. g.,
with Remote Controller and input/event subsystems.

I don't think we need two ioctls for that, as RC capabilities are already 
exported via
sysfs, and we have two interfaces already for receiving events (input/event and 
lirc).
For sending, lirc interface might be used, but it is currently focused only on 
sending
raw pulse/space sequences. So, we'll need to add some capability there for 
IR/CEC TX.
I had a few discussions about that with Jarod, but we didn't write yet an 
interface for it.


> 
> VIDIOC_CEC_CAP:
> ---
> 
> struct vl2_cec_cap {
>__u32 logicaldevices;
>__u32 reserved[7];
> };
> 
> The capability ioctl will return the number of logical devices/addresses 
> which can be
> simultaneously supported on this HW.
> 0:   This HW don't support CEC.
> 1 -> 14: This HW supports n logical devices simultaneously.
> 
> VIDIOC_CEC_CMD:
> ---
> 
> struct v4l2_cec_cmd {
> __u32 cmd;
> __u32 reserved[7];
> union {
> struct {
> __u32 index;
> __u32 enable;
> __u32 addr;
> } conf;
> struct {
> __u32 len;
> __u8  msg[16];
> __u32 status;
> } data;
> __u32 raw[8];
> };
> };
> 
> Alternatively the data struct could be:
> struct {
> __u8  initiator;
> __u8  destination;
> __u8  len;
> __u8  msg[15];
> __u32 status;
> } data;
> 
> Commands:
> 
> #define V4L2_CEC_CMD_CONF  (1)
> #define V4L2_CEC_CMD_TX(2)
> #define V4L2_CEC_CMD_RX(3)
> 
> Tx status field:
> 
> #define V4L2_CEC_STAT_TX_OK(0)
> #define V4L2_CEC_STAT_TX_ARB_LOST  (1)
> #define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
> 
> The command ioctl is used both for configuration and to receive/transmit data.
> 
> * The configuration command must be done for each logical device address
>   which is to be enabled on this HW. Maximum number of logical devices
>   is found with the capability ioctl.
> conf:
>  index:  0 -> number_of_logical_devices-1
>  enable: true/false
>  addr:   logical address
> 
>   By default all logical devices are disabled.
> 
> * Tx/Rx command
> data:
>  len:length of message (data + header)
>  msg:the raw CEC message received/transmitted
>  status: when the driver is in blocking mode it gives the result for 
> transmit.
> 
> Events
> --
> 
> In the case of non-blocking mode the driver will issue the following events:
> 
> V4L2_EVENT_CEC_TX
> V4L2_EVENT_CEC_RX
> 
> V4L2_EVENT_CEC_TX
> -
>  * transmit is complete with the following status:
> Add an additional struct to the struct v4l2_event
> 
> struct v4l2_event_cec_tx {
>__u32 status;
> }
> 
> V4L2_EVENT_CEC_RX
> -
>  * received a complete message
> 
> 
> Comments ?
> 
>Martin Bugge
> 
> -- 
> Martin Bugge - Tandberg (now a part of Cisco)
> -- 
> 
> -- 
> 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/ma

Re: [PATCH v21 3/3] ASoC: WL1273 FM radio: Access I2C IO functions through pointers.

[Mark Brown]

On Tue, Mar 01, 2011 at 10:00:50AM +0200, Matti J. Aaltonen wrote:
> These changes are needed to keep up with the changes in the
> MFD core and V4L2 parts of the wl1273 FM radio driver.
> 
> Use function pointers instead of exported functions for I2C IO.
> Also move all preprocessor constants from the wl1273.h to
> include/linux/mfd/wl1273-core.h.
> 
> Also update the year in the copyright statement.

It's not actually doing that:

> - * Copyright:   (C) 2010 Nokia Corporation
> + * Copyright:   (C) 2011 Nokia Corporation

It's replacing it - portions are still 2010.

Acked-by: Mark Brown 
--
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 v21 1/3] MFD: WL1273 FM Radio: MFD driver for the FM radio.

[Samuel Ortiz]

Hi Matti,

On Tue, Mar 01, 2011 at 10:00:48AM +0200, Matti J. Aaltonen wrote:
> This is the core of the WL1273 FM radio driver, it connects
> the two child modules. The two child drivers are
> drivers/media/radio/radio-wl1273.c and sound/soc/codecs/wl1273.c.
> 
> The radio-wl1273 driver implements the V4L2 interface and communicates
> with the device. The ALSA codec offers digital audio, without it only
> analog audio is available.

Acked-by: Samuel Ortiz 

Mauro, I suppose you're taking this one ?

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.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: isp or soc-camera for image co-processors

[Bhupesh SHARMA]

Hi Laurent,

> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Tuesday, March 01, 2011 3:40 PM
> To: Bhupesh SHARMA
> Cc: Guennadi Liakhovetski; linux-media@vger.kernel.org
> Subject: Re: isp or soc-camera for image co-processors
> 
> Hi Bhupesh,
> 
> On Tuesday 01 March 2011 10:46:36 Bhupesh SHARMA wrote:
> > On Tuesday, March 01, 2011 3:11 PM Laurent Pinchart wrote:
> > > On Tuesday 01 March 2011 08:25:12 Bhupesh SHARMA wrote:
> > > > Hi Guennadi and Laurent,
> > > >
> > > > We are now evaluating another ST platform that supports a image
> > > > co-processor between the camera sensor and the camera host (SoC).
> > > >
> > > > The simple architecture diagram will be similar to one shown
> below
> > > > (for the sake of simplicity I show only a single sensor. At least
> > >
> > > > two sensors can be supported by the co-processor):
> > > [snip] (as the ascii-art looks more like a Picasso painting with
> the
> > > quote
> > > characters)
> > :
> > :(
> >
> > Despite my efforts to align it properly :)
> 
> Try to configure your mailer to use spaces instead of tabs, or to make
> tabs 8
> spaces wide. It should then look good. Replies will usually mess the
> diagrams
> up though.

Ok, I will try it :)

> > > > The co-processor supports a video progressing logic engine
> capable of
> > > > performing a variety of operations like image recovery, cropping,
> > > > scaling, gamma correction etc.
> > > >
> > > > Now, evaluating the framework available for supporting for the
> camera
> > > > host, sensor and co-processor, I am wondering whether soc-
> camera(v4l2)
> > > > can support this complex design or something similar to the ISP
> driver
> > > > written for OMAP is the way forward.
> > >
> > > I think this can be a good candidate for the media controller API.
> It
> > > depends on how complex the co-processor is and what kind of
> processing it
> > > performs. I suppose there's no public datasheet.
> > >
> > > You will probably need to enhance subdev registration, as I'm not
> aware
> > > of any existing use case such as yours where a chain of subdevs
> unknown to
> > > the host controller is connected to the host controller input.
> >
> > Could you please give me some documentation links for media
> controller API.
> 
> The media controller documentation is part of the V4L2 kernel
> documentation.
> You can find a compiled copy at
> http://www.ideasonboard.org/media/media/

Thanks, I will go through the same.

> The in-kernel API is documented in the kernel sources, in
> Documentation/media-
> framework.txt
> 
> > Are there are reference drivers that I can use for my study?
> 
> The OMAP3 ISP driver.

Thanks, I will go through the same.

> > Unfortunately the data-sheet of the co-processor cannot be made
> public
> > as of yet.
> 
> Can you publish a block diagram of the co-processor internals ?

I will check internally to see if I can send a block-diagram
of the co-processor internals to you. The internals seem similar to 
OMAP ISP (which I can see from the public TRM). However, our
co-processor doesn't have the circular buffer and MMU that ISP seem to
have (and some other features).

In the meantime I copy the features of the co-processor here for your review:

Input / Output interfaces of co-processor:
==
- Sensor interfaces: 2 x MIPI CSI-2 receivers (1 x dual-lane up to 1.6 Gbit/s
 and 1 x single lane up to 800 Mbit/s)
- Host interface: MIPI CSI-2 dual lane transmitter (up to 1.6 Gbit/s) or ITU
 (8-bit CCIR interface, up to 100 MHz) - all with independent variable
 transmitter clock (PLL)
- Control interface: CCI (up to 400 kHz) or SPI

Sensor support:
===
- Supports two MIPI compliant sensors of up to 8 Megapixel resolution
 (one sensor streaming at a time)
- Support for auto-focus (AF), extended depth of field (EDOF) and wide dynamic
 range (WDR)sensors 

Internal Features:
==
- Versatile clock manager and internal buffer to accommodate a wide range of 
data rates
  between sensors and the coprocessor and between the coprocessor and the host.
- Synchronized flash gun control with red-eye reduction (pre-flash and 
main-flash strobes) for
  high-power LED or Xenon strobe light
- Low power standby mode
- Two video pipes (enables concurrent viewfinding and video/stills capture)
- Face detection and tracking algorithm
- Video stabilization
- Adaptive 4-channel lens shading and barrel distortion correction
- Statistics processor for advanced automatic exposure and white balance
- Automatic contrast stretch
- Nine-zone auto-focus with flexible actuator driver
- Digital zoom: smooth 16x down-scale capability and 4x up-scale capability
- Advanced noise and defect filtering
- Color reconstruction
- Adaptive color correction matrix
- Sharpness enhancement
- Programmable gamma correction
- Lighting frequency detection and automatic flicker reduction
- Image rotation/mirroring/flip for the viewf

Re: [RFC/PATCH 1/2] v4l: videobuf2: Handle buf_queue errors

[Laurent Pinchart]

Hi Pawel,

On Monday 28 February 2011 16:44:38 Pawel Osciak wrote:
> Hi Laurent,
> A few questions from me below. I feel we need to talk about this
> change a bit more, it introduces some recovery and consistency
> problems, unless I'm missing something.
> 
> On Sun, Feb 27, 2011 at 10:12, Laurent Pinchart wrote:
> > videobuf2 expects drivers to check buffer in the buf_prepare operation
> > and to return success only if the buffer can queued without any issue.
> > 
> > For hot-pluggable devices, disconnection events need to be handled at
> > buf_queue time. Checking the disconnected flag and adding the buffer to
> > the driver queue need to be performed without releasing the driver
> > spinlock, otherwise race conditions can occur in which the driver could
> > still allow a buffer to be queued after the disconnected flag has been
> > set, resulting in a hang during the next DQBUF operation.
> > 
> > This problem can be solved either in the videobuf2 core or in the device
> > drivers. To avoid adding a spinlock to videobuf2, make buf_queue return
> > an int and handle buf_queue failures in videobuf2. Drivers must not
> > return an error in buf_queue if the condition leading to the error can
> > be caught in buf_prepare.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> >  drivers/media/video/videobuf2-core.c |   32
> > ++-- include/media/videobuf2-core.h   |
> >2 +-
> >  2 files changed, 27 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/media/video/videobuf2-core.c
> > b/drivers/media/video/videobuf2-core.c index cc7ab0a..1d81536 100644
> > --- a/drivers/media/video/videobuf2-core.c
> > +++ b/drivers/media/video/videobuf2-core.c
> > @@ -798,13 +798,22 @@ static int __qbuf_mmap(struct vb2_buffer *vb,
> > struct v4l2_buffer *b) /**
> >  * __enqueue_in_driver() - enqueue a vb2_buffer in driver for processing
> >  */
> > -static void __enqueue_in_driver(struct vb2_buffer *vb)
> > +static int __enqueue_in_driver(struct vb2_buffer *vb)
> >  {
> >struct vb2_queue *q = vb->vb2_queue;
> > +   int ret;
> > 
> >vb->state = VB2_BUF_STATE_ACTIVE;
> >atomic_inc(&q->queued_count);
> > -   q->ops->buf_queue(vb);
> > +   ret = q->ops->buf_queue(vb);
> > +   if (ret == 0)
> > +   return 0;
> > +
> > +   vb->state = VB2_BUF_STATE_ERROR;
> > +   atomic_dec(&q->queued_count);
> > +   wake_up_all(&q->done_wq);
> > +
> > +   return ret;
> 
> Unless I am missing something, when this happens for an n-th buffer,
> we wake up all, but only one buffer will have the ERROR state, all the
> other will be in QUEUED state. This will mess up return values from
> dqbuf (if this happens on streamon) for other buffers, they will have
> their V4L2_BUF_FLAG_QUEUED set after dqbuf. Also, returning 0 from
> DQBUF and the V4L2_BUF_FLAG_ERROR for the failed buffer suggests that
> streaming may continue.

Actually not quite, as the driver is expected to mark all buffers as erroneous 
and wake up userspace when the disconnection event is received. Subsequent 
calls to VIDIOC_QBUF (or VIDIOC_STREAMON) need to return an error. I'm not 
sure if we need to wake up userspace then, as applications shouldn't sleep on 
VIDIOC_DQBUF or select() after VIDIOC_QBUF or VIDIOC_STREAMON returned an 
error.

> So how do we recover from this disconnection event? What is the
> general idea? If buf_queue fails, can we restart from some point (i.e.
> reuse the buffers later) or do we have to clean up completely (i.e.
> deallocate, etc.)? Right now we are staying in an undefined state.
> If we cannot recover, we shouldn't be setting V4L2_BUF_FLAG_ERROR, but
> returning a stronger error instead and maybe clean up the rest, which
> is not waited for somehow. If we can recover on the other hand, we
> shouldn't be probably waking up all sleepers or at least giving them
> meaningful errors.

I think a disconnection is pretty fatal. If the user unplugs the webcam, 
there's not much that can be done anymore. Userspace needs to be woken up with 
all buffers marked as erroneous, and the next QBUF call needs to return an 
error without queuing any buffer. We need to define the expected behaviour in 
the V4L2 spec, so that applications can rely on it and implement it properly. 
I would also like to handle this inside videobuf2 if possible (something like 
vb2_disconnect() ?) to ensure that all drivers behave correctly, but I'm not 
sure if that will be possible without messing locking up.

> >  }
> >  /**
> > @@ -890,8 +899,13 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer
> > *b) * If already streaming, give the buffer to driver for processing. *
> > If not, the buffer will be given to driver on next streamon. */
> > -   if (q->streaming)
> > -   __enqueue_in_driver(vb);
> > +   if (q->streaming) {
> > +   ret = __enqueue_in_driver(vb);
> > +   if (ret < 0) {
> > +   dprintk(1, "qbuf: buffer q

RE: [st-ericsson] v4l2 vs omx for camera

[Marek Szyprowski]

Hello,

On Tuesday, March 01, 2011 11:26 AM Edward Hervey wrote:

> On Mon, 2011-02-28 at 09:50 +0100, Marek Szyprowski wrote:
> > Hello,
> [...]
> >
> > I'm not sure that highmem is the right solution. First, this will force
> > systems with rather small amount of memory (like 256M) to use highmem just
> > to support DMA allocable memory. It also doesn't solve the issue with
> > specific memory requirement for our DMA hardware (multimedia codec needs
> > video memory buffers from 2 physical banks).
> 
>   Could you explain why a codec would require memory buffers from 2
> physical banks ?
> 

Well, this is rather a question to hardware engineer who designed it. 

I suspect that the buffers has been split into 2 regions and placed in 2 
different
memory banks to achieve the performance required to decode/encode full hd h264
movie. Video codec has 2 AXI master interfaces and I expect it is able to 
perform
2 transaction to the memory at once.

Best regards
--
Marek Szyprowski
Samsung Poland R&D 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: V4L2 'brainstorming' meeting in Warsaw, March 2011

[Marek Szyprowski]

Hello again!

As I promised I've prepared some additional travel information.

I would like to recommend Polonia Palace Hotel. It is located in the center of 
Warsaw,
quite near Samsung office. I've checked and they have free rooms for the 13-20 
period
(I've assumed 3 days of 'brainstorming' and weekend for sightseeing). You can 
book
rooms online on their webpage: http://www.poloniapalace.com/

Getting to Warsaw should be quite easy. I assume that everyone will come by 
plane.
There is only one airport in the Warsaw (Warsaw Chopin Airport - 'WAW' airport 
code)
which is located about 10km from the city center. The easiest way to the city 
center
is to take taxi. It should cost about 40-50 PLN (10-12 euro).

To get to the Samsung Office you can make a 10-15 minutes' walk or take a 
subway (it is
only 1 stop from 'Metro Centrum' station to 'Metro Politechnika' station).

I've prepared a map with Samsung Office, Hotel Polonia and Airport: 
http://tinyurl.com/4tubbyu

If you decide to stay a bit longer in Warsaw, I recommend to check sightseeing
information from the Palace Hotel: 
http://www.poloniapalace.com/discover-warsaw-en.html
>From the city center it is quite near to most sightseeing attractions (like 
>Old Town,
Palace of Culture and Science, Nowy Swiat street).

Best regards
--
Marek Szyprowski
Samsung Poland R&D 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] Prof 7301: switching frontend to stv090x, fixing "LOCK FAILED" issue

[Mauro Carvalho Chehab]

Em 28-02-2011 20:17, Igor M. Liplianin escreveu:
> В сообщении от 1 марта 2011 00:24:32 автор Mariusz Bialonczyk написал:
>> On 02/28/2011 09:37 PM, Igor M. Liplianin wrote:
>>> Sorry, I have nothing against you personally.
>>
>> me too :)
>>
>>> I have excuses, but you not intresting, I think.
>>> Peace, friendship, chewing gum, like we use to say in my childhood :)
>>>
>>> Switching to other driver not helps me, so be patient.
>>>
>>> I patched stv0900 and send pull request.
>>
>> I've tested it - and for the first sight it seems that it indeed
>> solves the problem. Thank you :)
>>
>> And about frontend: I think I found a solution which I hope will
>> satisfy all of us. I think it would be great if user have
>> an alternative option to use stv090x frontend anyway. I mean your
>> frontend as default, but a module parameter which enables using
>> stv090x instead of stv0900 (enabling what's is inside my patch).
>> This will be a flexible solution which shouldn't harm anyone,
>> but instead gives an option.
>>
>> Igor, Mauro, do you have objections against this solution?
>> If you agree, then I'll try to prepare an RFC patch for that.
> Well, I didn't change my mind.
> There is not an option, but splitting efforts in two ways.

An option to switch between them will just double maintenance efforts, as
both ways would needed to be tested. So, I don't think this is the
right way.

The proper long-term solution would be to merge stv090x and stv0900.

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: [st-ericsson] v4l2 vs omx for camera

[Edward Hervey]

On Mon, 2011-02-28 at 09:50 +0100, Marek Szyprowski wrote:
> Hello,
[...]
> 
> I'm not sure that highmem is the right solution. First, this will force
> systems with rather small amount of memory (like 256M) to use highmem just
> to support DMA allocable memory. It also doesn't solve the issue with
> specific memory requirement for our DMA hardware (multimedia codec needs
> video memory buffers from 2 physical banks).

  Could you explain why a codec would require memory buffers from 2
physical banks ?

  Thanks,

   Edward

> 
> The relocation issue has been already addressed in the last CMA patch series.
> Michal managed to create a framework that allowed to relocate on demand any
> pages from the CMA area.
> 
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D 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: V4L2 'brainstorming' meeting in Warsaw, March 2011

[Hans Verkuil]

Hi all!

On Monday, February 28, 2011 18:11:47 Marek Szyprowski wrote:
> Hello everyone!
> 
> The idea of v4l2 'brainstorming' session came out after a few discussions on 
#v4l
> IRC channel about various RFCs and proposals that have been posted recently. 
I
> would like to announce that Samsung Poland R&D Center (SPRC) agreed to take 
an
> opportunity to organize this meeting. I've got a reservation for a 
conference
> room for 16-18 March 2011 in our office.
> 
> I would like to invite all of You for this V4L2 'brainstorming' session.
> 
> I hope that this initial meeting date I've selected will fit us. We have 2 
only
> weeks for the preparation, but I hope we will manage. I'm open for another 
date
> and if required I will change the reservation.
> 
> The meeting will last 3 days what gives us a lot of possibility to present 
the
> issues and proposals, discuss them further and work out a solution that will 
be
> accepted by others.
> 
> From SPRC 4 developers will attend this meeting: Sylwester Nawrocki (s5p-
fimc
> author), Kamil Debski (s5p-mfc author), Tomasz Stanislawski (s5p-tv author) 
and me
> (videobuf2 co-author and kernel lead developer in SPRC).
> 
> A quick summary of the above:
> 
> 1. Type of the meeting:
> V4L2 'brainstorming' mini-summit :)
> 
> 2. Place:
> Samsung Poland R&D Center
> Polna 11 Street
> 00-633 Warsaw, Poland
> 
> 3. Date:
> 16-18 March 2011
> 
> 4. Agenda
> TBD, everyone is welcomed to put his items here :)
> 
> I will post some travel information tomorrow. SPRC office is in the center 
of Warsaw,
> there are a few hotels nearby. I will check for a free rooms and I will make 
a
> recommendation soon. I hope we will meet together soon!

Just to let you all know that I will be handling the agenda. I'll prepare a 
first version of it this weekend and the final one next weekend.

The basic outline is the same as during previous meetings: the first day we go 
through all the agenda points and make sure everyone understands the problem. 
Smaller issues will be discussed and decided, more complex issues are just 
discussed.

The second day we go in depth into the complex issues and try to come up with 
ideas that might work. The last day we translate the all agenda items into 
actions.

This approach worked well in the past and it ensures that we end up with 
something concrete. Also note that this is a brainstorm meeting, so the final 
decisions will have to be taken on the mailinglist.

Those who have a vested interest in an agenda item should be prepared to 
explain it and if necessary have a presentation ready.

There is a lot of ground to cover, so we should try to avoid wasting too much 
time :-)

Regards,

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

Re: isp or soc-camera for image co-processors

[Laurent Pinchart]

Hi Bhupesh,

On Tuesday 01 March 2011 10:46:36 Bhupesh SHARMA wrote:
> On Tuesday, March 01, 2011 3:11 PM Laurent Pinchart wrote: 
> > On Tuesday 01 March 2011 08:25:12 Bhupesh SHARMA wrote:
> > > Hi Guennadi and Laurent,
> > > 
> > > We are now evaluating another ST platform that supports a image
> > > co-processor between the camera sensor and the camera host (SoC).
> > > 
> > > The simple architecture diagram will be similar to one shown below
> > > (for the sake of simplicity I show only a single sensor. At least
> > 
> > > two sensors can be supported by the co-processor):
> > [snip] (as the ascii-art looks more like a Picasso painting with the
> > quote
> > characters)
> :
> :(
> 
> Despite my efforts to align it properly :)

Try to configure your mailer to use spaces instead of tabs, or to make tabs 8 
spaces wide. It should then look good. Replies will usually mess the diagrams 
up though.

> > > The co-processor supports a video progressing logic engine capable of
> > > performing a variety of operations like image recovery, cropping,
> > > scaling, gamma correction etc.
> > > 
> > > Now, evaluating the framework available for supporting for the camera
> > > host, sensor and co-processor, I am wondering whether soc-camera(v4l2)
> > > can support this complex design or something similar to the ISP driver
> > > written for OMAP is the way forward.
> > 
> > I think this can be a good candidate for the media controller API. It
> > depends on how complex the co-processor is and what kind of processing it
> > performs. I suppose there's no public datasheet.
> > 
> > You will probably need to enhance subdev registration, as I'm not aware
> > of any existing use case such as yours where a chain of subdevs unknown to
> > the host controller is connected to the host controller input.
> 
> Could you please give me some documentation links for media controller API.

The media controller documentation is part of the V4L2 kernel documentation. 
You can find a compiled copy at http://www.ideasonboard.org/media/media/

The in-kernel API is documented in the kernel sources, in Documentation/media-
framework.txt

> Are there are reference drivers that I can use for my study?

The OMAP3 ISP driver.

> Unfortunately the data-sheet of the co-processor cannot be made public
> as of yet.

Can you publish a block diagram of the co-processor internals ?

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

[RFC] HDMI-CEC proposal

[Martin Bugge (marbugge)]

Author: Martin Bugge 
Date:  Tue, 1 March 2010
==

This is a proposal for adding a Consumer Electronic Control (CEC) API to 
V4L2.

This document describes the changes and new ioctls needed.

Version 1.0 (This is first version)

Background
==
CEC is a protocol that provides high-level control functions between 
various audiovisual products.
It is an optional supplement to the High-Definition Multimedia Interface 
Specification (HDMI).
Physical layer is a one-wire bidirectional serial bus that uses the 
industry-standard AV.link protocol.


In short: CEC uses pin 13 on the HDMI connector to transmit and receive 
small data-packets
  (maximum 16 bytes including a 1 byte header) at low data 
rates (~400 bits/s).


A CEC device may have any of 15 logical addresses (0 - 14).
(address 15 is broadcast and some addresses are reserved)


References
==
[1] High-Definition Multimedia Interface Specification version 1.3a,
Supplement 1 Consumer Electronic Control (CEC).
http://www.hdmi.org/manufacturer/specification.aspx

[2] 
http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf



Proposed solution
=

Two new ioctls:
VIDIOC_CEC_CAP (read)
VIDIOC_CEC_CMD (read/write)

VIDIOC_CEC_CAP:
---

struct vl2_cec_cap {
   __u32 logicaldevices;
   __u32 reserved[7];
};

The capability ioctl will return the number of logical devices/addresses 
which can be

simultaneously supported on this HW.
0:   This HW don't support CEC.
1 -> 14: This HW supports n logical devices simultaneously.

VIDIOC_CEC_CMD:
---

struct v4l2_cec_cmd {
__u32 cmd;
__u32 reserved[7];
union {
struct {
__u32 index;
__u32 enable;
__u32 addr;
} conf;
struct {
__u32 len;
__u8  msg[16];
__u32 status;
} data;
__u32 raw[8];
};
};

Alternatively the data struct could be:
struct {
__u8  initiator;
__u8  destination;
__u8  len;
__u8  msg[15];
__u32 status;
} data;

Commands:

#define V4L2_CEC_CMD_CONF  (1)
#define V4L2_CEC_CMD_TX(2)
#define V4L2_CEC_CMD_RX(3)

Tx status field:

#define V4L2_CEC_STAT_TX_OK(0)
#define V4L2_CEC_STAT_TX_ARB_LOST  (1)
#define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)

The command ioctl is used both for configuration and to receive/transmit 
data.


* The configuration command must be done for each logical device address
  which is to be enabled on this HW. Maximum number of logical devices
  is found with the capability ioctl.
conf:
 index:  0 -> number_of_logical_devices-1
 enable: true/false
 addr:   logical address

  By default all logical devices are disabled.

* Tx/Rx command
data:
 len:length of message (data + header)
 msg:the raw CEC message received/transmitted
 status: when the driver is in blocking mode it gives the 
result for transmit.


Events
--

In the case of non-blocking mode the driver will issue the following events:

V4L2_EVENT_CEC_TX
V4L2_EVENT_CEC_RX

V4L2_EVENT_CEC_TX
-
 * transmit is complete with the following status:
Add an additional struct to the struct v4l2_event

struct v4l2_event_cec_tx {
   __u32 status;
}

V4L2_EVENT_CEC_RX
-
 * received a complete message


Comments ?

   Martin Bugge

--
Martin Bugge - Tandberg (now a part of Cisco)
--

--
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: isp or soc-camera for image co-processors

[Bhupesh SHARMA]

Hi Laurent,

> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Tuesday, March 01, 2011 3:11 PM
> To: Bhupesh SHARMA
> Cc: Guennadi Liakhovetski; linux-media@vger.kernel.org
> Subject: Re: isp or soc-camera for image co-processors
> 
> Hi Bhupesh,
> 
> On Tuesday 01 March 2011 08:25:12 Bhupesh SHARMA wrote:
> > Hi Guennadi and Laurent,
> >
> > We are now evaluating another ST platform that supports a image
> > co-processor between the camera sensor and the camera host (SoC).
> >
> > The simple architecture diagram will be similar to one shown below
> > (for the sake of simplicity I show only a single sensor. At least
> > two sensors can be supported by the co-processor):
> 
> [snip] (as the ascii-art looks more like a Picasso painting with the
> quote
> characters)

:(
Despite my efforts to align it properly :)

> > The co-processor supports a video progressing logic engine capable of
> > performing a variety of operations like image recovery, cropping,
> scaling,
> > gamma correction etc.
> >
> > Now, evaluating the framework available for supporting for the camera
> > host, sensor and co-processor, I am wondering whether soc-
> camera(v4l2) can
> > support this complex design or something similar to the ISP driver
> written
> > for OMAP is the way forward.
> 
> I think this can be a good candidate for the media controller API. It
> depends
> on how complex the co-processor is and what kind of processing it
> performs. I
> suppose there's no public datasheet.
> 
> You will probably need to enhance subdev registration, as I'm not aware
> of any
> existing use case such as yours where a chain of subdevs unknown to the
> host
> controller is connected to the host controller input.

Could you please give me some documentation links for media controller API.
Are there are reference drivers that I can use for my study?
Unfortunately the data-sheet of the co-processor cannot be made public
as of yet.

Regards,
Bhupesh
--
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: isp or soc-camera for image co-processors

[Laurent Pinchart]

Hi Bhupesh,

On Tuesday 01 March 2011 08:25:12 Bhupesh SHARMA wrote:
> Hi Guennadi and Laurent,
> 
> We are now evaluating another ST platform that supports a image
> co-processor between the camera sensor and the camera host (SoC).
> 
> The simple architecture diagram will be similar to one shown below
> (for the sake of simplicity I show only a single sensor. At least
> two sensors can be supported by the co-processor):

[snip] (as the ascii-art looks more like a Picasso painting with the quote 
characters)

> The co-processor supports a video progressing logic engine capable of
> performing a variety of operations like image recovery, cropping, scaling,
> gamma correction etc.
> 
> Now, evaluating the framework available for supporting for the camera
> host, sensor and co-processor, I am wondering whether soc-camera(v4l2) can
> support this complex design or something similar to the ISP driver written
> for OMAP is the way forward.

I think this can be a good candidate for the media controller API. It depends 
on how complex the co-processor is and what kind of processing it performs. I 
suppose there's no public datasheet.

You will probably need to enhance subdev registration, as I'm not aware of any 
existing use case such as yours where a chain of subdevs unknown to the host 
controller is connected to the host controller input.

> Any pointers on the same and reference links to some documentation
> will be highly appreciated.

-- 
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: V4L2 'brainstorming' meeting in Warsaw, March 2011

[Tomasz Stanislawski]

Sakari Ailus wrote:

Laurent Pinchart wrote:

On Monday 28 February 2011 19:03:39 Hans Verkuil wrote:

On Monday, February 28, 2011 18:11:47 Marek Szyprowski wrote:

[snip]


4. Agenda

TBD, everyone is welcomed to put his items here :)

In no particular order:

1) pipeline configuration, cropping and scaling:

http://www.mail-archive.com/linux-media@vger.kernel.org/msg27956.html
http://www.mail-archive.com/linux-media@vger.kernel.org/msg26630.html

2) HDMI API support

Some hotplug/CEC code can be found here:

http://www.mail-archive.com/linux-media@vger.kernel.org/msg28549.html

but Cisco will soon post RFCs on this topic as well.

3) Snapshot functionality.

http://www.mail-archive.com/linux-media@vger.kernel.org/msg28192.html
http://www.mail-archive.com/linux-media@vger.kernel.org/msg28490.html

If we finish quicker than expected, then we can also look at this:

- use of V4L2 as a frontend for SW/DSP codecs

In still no particular order:

 - Muxed formats (H.264 inside MJPEG)
 - H.264
 - Buffers pool
 - Entity information ioctl
 - Userspace drivers (OMX)
 - Sensor blanking/pixel-clock/frame-rate settings (including 
enumeration/discovery)

 - GL/ES in V4L2 devices


Unordered, again:

- Multiple video buffer queues per device (currently implemented in the
OMAP 3 ISP driver in non-standard way).

- Synchronising parameters (e.g. exposure time and gain) on given
frames. Some sensors support this on hardware. There are many use cases
which benefit from this, for example this one:

http://fcam.garage.maemo.org/>

- Flash synchronisation (might fall under the above topic).

- Frame metadata. It is important for the control algorithms (exposure,
white balance, for example), to know which sensor settings have been
used to expose a given frame. Many sensors do support this. Do we want
to parse this in the kernel or does it belong to user space? The
metadata formats are mostly sensor dependent.


The dates are okay for me but I'm not yet certain of my participation
for other reasons.


Best regards,



I propose few topic:

1. Acquiring subdevs from other devices using subdev pool
http://www.mail-archive.com/linux-media@vger.kernel.org/msg21831.html

2. Buffer cropping.
http://www.mail-archive.com/linux-media@vger.kernel.org/msg27956.html

3. Introducing subdev hierarchy. Below there is a link to driver using it:
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/28885/focus=28890

Best regards
Tomasz Stanislawski

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

Re: Kernel configuration for ov9655 on the PXA27x Quick Capture Interface

[Stefan Herbrechtsmeier]

Hi Paolo,

Am 17.02.2011 22:13, schrieb Paolo Santinelli:

Does exist an older kernel version that I can patch (
https://patchwork.kernel.org/patch/16548/) in order to use the ov9655
sensor ?

you can find updated patches in my openembedded overlay.
http://git.berlios.de/cgi-bin/gitweb.cgi?p=openrobotix;a=tree;f=recipes/linux

The ov9655 is part of my linux-bebot.patch.

Regards,
Stefan


Paolo

2011/2/17 Guennadi Liakhovetski:

(replaced the old mailing list address)

On Thu, 17 Feb 2011, Paolo Santinelli wrote:


Hi Guennadi,

thank you for the information.

Can I use or adapt this patch:  https://patchwork.kernel.org/patch/16548/  ?

You'd have to port it to the current kernel, the patch is almost 2 years
old...


I Could  use the code from the patch  to direct control the sensor
register configuration and use the  PXA27x Quick Capture Interface to
capture data by mean "soc_camera" and "pxa_camera" driver modules. But
now when I try to load the soc_camera module i get this error:

insmod soc_camera.ko
insmod: cannot insert 'soc_camera.ko': No such device

Please, could you give mi some tips and indication

No, all the drivers: soc-camera core, camera host driver (pxa_camera) and
a camera sensor driver (ov9655) have to work together. And their mutual
work is configured at the platform level. Sorry, I don't think, I can
guide you in detail through a complete v4l2-subdev / soc-camera driver
architecture. You can try to have a look at one of the multiple examples,
e.g.,

arch/arm/mach-pxa/ezx.c (see a780_camera)
drivers/media/video/mt9m111.c
drivers/media/video/pxa_camera.c

Good luck
Guennadi


Thanks

Paolo

2011/2/17 Guennadi Liakhovetski:

On Wed, 16 Feb 2011, Paolo Santinelli wrote:


Hi all,

I have an embedded smart camera equipped with an XScal-PXA270
processor running Linux 2.6.37 and the OV9655 Image sensor connected
on the PXA27x Quick Capture Interface.

Please, what kernel module I have to select in order to use the Image sensor ?

You need to write a new or adapt an existing driver for your ov9655
sensor, currently, there's no driver available to work with your pxa270.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/




--
--
Paolo Santinelli
ImageLab Computer Vision and Pattern Recognition Lab
Dipartimento di Ingegneria dell'Informazione
Universita' di Modena e Reggio Emilia
via Vignolese 905/B, 41125, Modena, Italy

Cell. +39 3472953357,  Office +39 059 2056270, Fax +39 059 2056129
email:  paolo.santine...@unimore.it
URL:  http://imagelab.ing.unimo.it
--


---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/







--
Dipl.-Ing. Stefan Herbrechtsmeier

Universität Bielefeld
AG Kognitronik&  Sensorik
Exzellenzcluster Cognitive Interaction Technology (CITEC)
Universitätsstraße 21-23
D-33615 Bielefeld (Germany)

office : M6-117
phone  : +49 521-106-67370
fax: +49 521-106-12348
mailto : sherb...@cit-ec.uni-bielefeld.de
www: http://www.ks.cit-ec.uni-bielefeld.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: [PATCH v2 1/1] V4L: videobuf, don't use dma addr as physical

[Jiri Slaby]

On 03/01/2011 09:21 AM, Jiri Slaby wrote:
> mem->dma_handle is a dma address obtained by dma_alloc_coherent which
> needn't be a physical address as a hardware IOMMU can (and most
> likely will) return a bus address where physical != bus address. So
> ensure we are remapping (remap_pfn_range) the right page in
> __videobuf_mmap_mapper by using virt_to_phys(mem->vaddr) and not
> mem->dma_handle.
> 
> While at it, use PFN_DOWN instead of explicit shift to obtain a frame
> number.
> 
> This was discovered by a random review of the code when looking for
> something completely different. I'm not aware of any bug reports for
> this.
> 
> However it is a bug because many v4l drivers use this layer and have
> no idea whether IOMMU is in the system and running or not.
> 
> Signed-off-by: Jiri Slaby 
> Cc: Mauro Carvalho Chehab 
> Cc: Konrad Rzeszutek Wilk 

Ah, this is rather:
Acked-by: Konrad Rzeszutek Wilk 

> ---
> 
> This is a version with updated changelog.
> 
>  drivers/media/video/videobuf-dma-contig.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/media/video/videobuf-dma-contig.c 
> b/drivers/media/video/videobuf-dma-contig.c
> index c969111..19d3e4a 100644
> --- a/drivers/media/video/videobuf-dma-contig.c
> +++ b/drivers/media/video/videobuf-dma-contig.c
> @@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue 
> *q,
>  
>   vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>   retval = remap_pfn_range(vma, vma->vm_start,
> -  mem->dma_handle >> PAGE_SHIFT,
> +  PFN_DOWN(virt_to_phys(mem->vaddr))
>size, vma->vm_page_prot);
>   if (retval) {
>   dev_err(q->dev, "mmap: remap failed with error %d. ", retval);


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

[PATCH v2 1/1] V4L: videobuf, don't use dma addr as physical

[Jiri Slaby]

mem->dma_handle is a dma address obtained by dma_alloc_coherent which
needn't be a physical address as a hardware IOMMU can (and most
likely will) return a bus address where physical != bus address. So
ensure we are remapping (remap_pfn_range) the right page in
__videobuf_mmap_mapper by using virt_to_phys(mem->vaddr) and not
mem->dma_handle.

While at it, use PFN_DOWN instead of explicit shift to obtain a frame
number.

This was discovered by a random review of the code when looking for
something completely different. I'm not aware of any bug reports for
this.

However it is a bug because many v4l drivers use this layer and have
no idea whether IOMMU is in the system and running or not.

Signed-off-by: Jiri Slaby 
Cc: Mauro Carvalho Chehab 
Cc: Konrad Rzeszutek Wilk 
---

This is a version with updated changelog.

 drivers/media/video/videobuf-dma-contig.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/videobuf-dma-contig.c 
b/drivers/media/video/videobuf-dma-contig.c
index c969111..19d3e4a 100644
--- a/drivers/media/video/videobuf-dma-contig.c
+++ b/drivers/media/video/videobuf-dma-contig.c
@@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q,
 
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
retval = remap_pfn_range(vma, vma->vm_start,
-mem->dma_handle >> PAGE_SHIFT,
+PFN_DOWN(virt_to_phys(mem->vaddr))
 size, vma->vm_page_prot);
if (retval) {
dev_err(q->dev, "mmap: remap failed with error %d. ", retval);
-- 
1.7.4.1


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

Re: V4L2 'brainstorming' meeting in Warsaw, March 2011

[Sakari Ailus]

Laurent Pinchart wrote:
> On Monday 28 February 2011 19:03:39 Hans Verkuil wrote:
>> On Monday, February 28, 2011 18:11:47 Marek Szyprowski wrote:
> 
> [snip]
> 
>>> 4. Agenda
>>>
>>> TBD, everyone is welcomed to put his items here :)
>>
>> In no particular order:
>>
>> 1) pipeline configuration, cropping and scaling:
>>
>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg27956.html
>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg26630.html
>>
>> 2) HDMI API support
>>
>> Some hotplug/CEC code can be found here:
>>
>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg28549.html
>>
>> but Cisco will soon post RFCs on this topic as well.
>>
>> 3) Snapshot functionality.
>>
>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg28192.html
>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg28490.html
>>
>> If we finish quicker than expected, then we can also look at this:
>>
>> - use of V4L2 as a frontend for SW/DSP codecs
> 
> In still no particular order:
> 
>  - Muxed formats (H.264 inside MJPEG)
>  - H.264
>  - Buffers pool
>  - Entity information ioctl
>  - Userspace drivers (OMX)
>  - Sensor blanking/pixel-clock/frame-rate settings (including 
> enumeration/discovery)
>  - GL/ES in V4L2 devices

Unordered, again:

- Multiple video buffer queues per device (currently implemented in the
OMAP 3 ISP driver in non-standard way).

- Synchronising parameters (e.g. exposure time and gain) on given
frames. Some sensors support this on hardware. There are many use cases
which benefit from this, for example this one:

http://fcam.garage.maemo.org/>

- Flash synchronisation (might fall under the above topic).

- Frame metadata. It is important for the control algorithms (exposure,
white balance, for example), to know which sensor settings have been
used to expose a given frame. Many sensors do support this. Do we want
to parse this in the kernel or does it belong to user space? The
metadata formats are mostly sensor dependent.


The dates are okay for me but I'm not yet certain of my participation
for other reasons.


Best regards,

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

[PATCH v21 2/3] V4L2: WL1273 FM Radio: TI WL1273 FM radio driver

[Matti J. Aaltonen]

This module implements V4L2 controls for the Texas Instruments
WL1273 FM Radio and handles the communication with the chip.

Signed-off-by: Matti J. Aaltonen 
---
 drivers/media/radio/radio-wl1273.c |  360 +++-
 1 files changed, 106 insertions(+), 254 deletions(-)

diff --git a/drivers/media/radio/radio-wl1273.c 
b/drivers/media/radio/radio-wl1273.c
index 7ecc8e6..9e177dc 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -1,7 +1,7 @@
 /*
  * Driver for the Texas Instruments WL1273 FM radio.
  *
- * Copyright (C) 2010 Nokia Corporation
+ * Copyright (C) 2011 Nokia Corporation
  * Author: Matti J. Aaltonen 
  *
  * This program is free software; you can redistribute it and/or
@@ -104,58 +104,6 @@ static unsigned int rds_buf = 100;
 module_param(rds_buf, uint, 0);
 MODULE_PARM_DESC(rds_buf, "Number of RDS buffer entries. Default = 100");
 
-static int wl1273_fm_read_reg(struct wl1273_core *core, u8 reg, u16 *value)
-{
-   struct i2c_client *client = core->client;
-   u8 b[2];
-   int r;
-
-   r = i2c_smbus_read_i2c_block_data(client, reg, sizeof(b), b);
-   if (r != 2) {
-   dev_err(&client->dev, "%s: Read: %d fails.\n", __func__, reg);
-   return -EREMOTEIO;
-   }
-
-   *value = (u16)b[0] << 8 | b[1];
-
-   return 0;
-}
-
-static int wl1273_fm_write_cmd(struct wl1273_core *core, u8 cmd, u16 param)
-{
-   struct i2c_client *client = core->client;
-   u8 buf[] = { (param >> 8) & 0xff, param & 0xff };
-   int r;
-
-   r = i2c_smbus_write_i2c_block_data(client, cmd, sizeof(buf), buf);
-   if (r) {
-   dev_err(&client->dev, "%s: Cmd: %d fails.\n", __func__, cmd);
-   return r;
-   }
-
-   return 0;
-}
-
-static int wl1273_fm_write_data(struct wl1273_core *core, u8 *data, u16 len)
-{
-   struct i2c_client *client = core->client;
-   struct i2c_msg msg;
-   int r;
-
-   msg.addr = client->addr;
-   msg.flags = 0;
-   msg.buf = data;
-   msg.len = len;
-
-   r = i2c_transfer(client->adapter, &msg, 1);
-   if (r != 1) {
-   dev_err(&client->dev, "%s: write error.\n", __func__);
-   return -EREMOTEIO;
-   }
-
-   return 0;
-}
-
 static int wl1273_fm_write_fw(struct wl1273_core *core,
  __u8 *fw, int len)
 {
@@ -188,94 +136,6 @@ static int wl1273_fm_write_fw(struct wl1273_core *core,
return r;
 }
 
-/**
- * wl1273_fm_set_audio() - Set audio mode.
- * @core:  A pointer to the device struct.
- * @new_mode:  The new audio mode.
- *
- * Audio modes are WL1273_AUDIO_DIGITAL and WL1273_AUDIO_ANALOG.
- */
-static int wl1273_fm_set_audio(struct wl1273_core *core, unsigned int new_mode)
-{
-   int r = 0;
-
-   if (core->mode == WL1273_MODE_OFF ||
-   core->mode == WL1273_MODE_SUSPENDED)
-   return -EPERM;
-
-   if (core->mode == WL1273_MODE_RX && new_mode == WL1273_AUDIO_DIGITAL) {
-   r = wl1273_fm_write_cmd(core, WL1273_PCM_MODE_SET,
-   WL1273_PCM_DEF_MODE);
-   if (r)
-   goto out;
-
-   r = wl1273_fm_write_cmd(core, WL1273_I2S_MODE_CONFIG_SET,
-   core->i2s_mode);
-   if (r)
-   goto out;
-
-   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_ENABLE,
-   WL1273_AUDIO_ENABLE_I2S);
-   if (r)
-   goto out;
-
-   } else if (core->mode == WL1273_MODE_RX &&
-  new_mode == WL1273_AUDIO_ANALOG) {
-   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_ENABLE,
-   WL1273_AUDIO_ENABLE_ANALOG);
-   if (r)
-   goto out;
-
-   } else if (core->mode == WL1273_MODE_TX &&
-  new_mode == WL1273_AUDIO_DIGITAL) {
-   r = wl1273_fm_write_cmd(core, WL1273_I2S_MODE_CONFIG_SET,
-   core->i2s_mode);
-   if (r)
-   goto out;
-
-   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_IO_SET,
-   WL1273_AUDIO_IO_SET_I2S);
-   if (r)
-   goto out;
-
-   } else if (core->mode == WL1273_MODE_TX &&
-  new_mode == WL1273_AUDIO_ANALOG) {
-   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_IO_SET,
-   WL1273_AUDIO_IO_SET_ANALOG);
-   if (r)
-   goto out;
-   }
-
-   core->audio_mode = new_mode;
-out:
-   return r;
-}
-
-/**
- * wl1273_fm_set_volume() -Set volume.
- * @core:  A pointer to the device struct.
- * @volume:The new volume value.
- */
-static int wl1273_fm_set_

[PATCH v21 0/3] ASoC/MFD/V4L2: WL1273 FM Radio Driver

[Matti J. Aaltonen]

Hi.

And thanks for the comment.

Samuel wrote:
>> Remove two unnecessary calls to i2c_set_clientdata.
>Provided that you add a changelog relevant to the patch itself, and not to the
>v1->v2 diff:

Replaced the incremental changelog stuff with the original descriptions.

>Acked-by: Samuel Ortiz 

Cheers,
Matti

Matti J. Aaltonen (3):
  MFD: WL1273 FM Radio: MFD driver for the FM radio.
  V4L2: WL1273 FM Radio: TI WL1273 FM radio driver
  ASoC: WL1273 FM radio: Access I2C IO functions through pointers.

 drivers/media/radio/radio-wl1273.c |  360 +++-
 drivers/mfd/Kconfig|2 +-
 drivers/mfd/wl1273-core.c  |  149 +++-
 include/linux/mfd/wl1273-core.h|2 +
 sound/soc/codecs/Kconfig   |2 +-
 sound/soc/codecs/wl1273.c  |   11 +-
 6 files changed, 264 insertions(+), 262 deletions(-)

--
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 v21 1/3] MFD: WL1273 FM Radio: MFD driver for the FM radio.

[Matti J. Aaltonen]

This is the core of the WL1273 FM radio driver, it connects
the two child modules. The two child drivers are
drivers/media/radio/radio-wl1273.c and sound/soc/codecs/wl1273.c.

The radio-wl1273 driver implements the V4L2 interface and communicates
with the device. The ALSA codec offers digital audio, without it only
analog audio is available.

Signed-off-by: Matti J. Aaltonen 
---
 drivers/mfd/Kconfig |2 +-
 drivers/mfd/wl1273-core.c   |  149 ++-
 include/linux/mfd/wl1273-core.h |2 +
 3 files changed, 149 insertions(+), 4 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index fd01836..9db079b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -615,7 +615,7 @@ config MFD_VX855
  and/or vx855_gpio drivers for this to do anything useful.
 
 config MFD_WL1273_CORE
-   tristate
+   tristate "Support for TI WL1273 FM radio."
depends on I2C
select MFD_CORE
default n
diff --git a/drivers/mfd/wl1273-core.c b/drivers/mfd/wl1273-core.c
index d2ecc24..4025a4b 100644
--- a/drivers/mfd/wl1273-core.c
+++ b/drivers/mfd/wl1273-core.c
@@ -1,7 +1,7 @@
 /*
  * MFD driver for wl1273 FM radio and audio codec submodules.
  *
- * Copyright (C) 2010 Nokia Corporation
+ * Copyright (C) 2011 Nokia Corporation
  * Author: Matti Aaltonen 
  *
  * This program is free software; you can redistribute it and/or modify
@@ -31,6 +31,145 @@ static struct i2c_device_id wl1273_driver_id_table[] = {
 };
 MODULE_DEVICE_TABLE(i2c, wl1273_driver_id_table);
 
+static int wl1273_fm_read_reg(struct wl1273_core *core, u8 reg, u16 *value)
+{
+   struct i2c_client *client = core->client;
+   u8 b[2];
+   int r;
+
+   r = i2c_smbus_read_i2c_block_data(client, reg, sizeof(b), b);
+   if (r != 2) {
+   dev_err(&client->dev, "%s: Read: %d fails.\n", __func__, reg);
+   return -EREMOTEIO;
+   }
+
+   *value = (u16)b[0] << 8 | b[1];
+
+   return 0;
+}
+
+static int wl1273_fm_write_cmd(struct wl1273_core *core, u8 cmd, u16 param)
+{
+   struct i2c_client *client = core->client;
+   u8 buf[] = { (param >> 8) & 0xff, param & 0xff };
+   int r;
+
+   r = i2c_smbus_write_i2c_block_data(client, cmd, sizeof(buf), buf);
+   if (r) {
+   dev_err(&client->dev, "%s: Cmd: %d fails.\n", __func__, cmd);
+   return r;
+   }
+
+   return 0;
+}
+
+static int wl1273_fm_write_data(struct wl1273_core *core, u8 *data, u16 len)
+{
+   struct i2c_client *client = core->client;
+   struct i2c_msg msg;
+   int r;
+
+   msg.addr = client->addr;
+   msg.flags = 0;
+   msg.buf = data;
+   msg.len = len;
+
+   r = i2c_transfer(client->adapter, &msg, 1);
+   if (r != 1) {
+   dev_err(&client->dev, "%s: write error.\n", __func__);
+   return -EREMOTEIO;
+   }
+
+   return 0;
+}
+
+/**
+ * wl1273_fm_set_audio() - Set audio mode.
+ * @core:  A pointer to the device struct.
+ * @new_mode:  The new audio mode.
+ *
+ * Audio modes are WL1273_AUDIO_DIGITAL and WL1273_AUDIO_ANALOG.
+ */
+static int wl1273_fm_set_audio(struct wl1273_core *core, unsigned int new_mode)
+{
+   int r = 0;
+
+   if (core->mode == WL1273_MODE_OFF ||
+   core->mode == WL1273_MODE_SUSPENDED)
+   return -EPERM;
+
+   if (core->mode == WL1273_MODE_RX && new_mode == WL1273_AUDIO_DIGITAL) {
+   r = wl1273_fm_write_cmd(core, WL1273_PCM_MODE_SET,
+   WL1273_PCM_DEF_MODE);
+   if (r)
+   goto out;
+
+   r = wl1273_fm_write_cmd(core, WL1273_I2S_MODE_CONFIG_SET,
+   core->i2s_mode);
+   if (r)
+   goto out;
+
+   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_ENABLE,
+   WL1273_AUDIO_ENABLE_I2S);
+   if (r)
+   goto out;
+
+   } else if (core->mode == WL1273_MODE_RX &&
+  new_mode == WL1273_AUDIO_ANALOG) {
+   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_ENABLE,
+   WL1273_AUDIO_ENABLE_ANALOG);
+   if (r)
+   goto out;
+
+   } else if (core->mode == WL1273_MODE_TX &&
+  new_mode == WL1273_AUDIO_DIGITAL) {
+   r = wl1273_fm_write_cmd(core, WL1273_I2S_MODE_CONFIG_SET,
+   core->i2s_mode);
+   if (r)
+   goto out;
+
+   r = wl1273_fm_write_cmd(core, WL1273_AUDIO_IO_SET,
+   WL1273_AUDIO_IO_SET_I2S);
+   if (r)
+   goto out;
+
+   } else if (core->mode == WL1273_MODE_TX &&
+  new_mode == WL1273_AUDIO_ANALOG) {
+   r = wl1273_fm_

[PATCH v21 3/3] ASoC: WL1273 FM radio: Access I2C IO functions through pointers.

[Matti J. Aaltonen]

These changes are needed to keep up with the changes in the
MFD core and V4L2 parts of the wl1273 FM radio driver.

Use function pointers instead of exported functions for I2C IO.
Also move all preprocessor constants from the wl1273.h to
include/linux/mfd/wl1273-core.h.

Also update the year in the copyright statement.

Signed-off-by: Matti J. Aaltonen 
---
 sound/soc/codecs/Kconfig  |2 +-
 sound/soc/codecs/wl1273.c |   11 ---
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index c48b23c..9726d6e 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -44,7 +44,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TWL6040 if TWL4030_CORE
select SND_SOC_UDA134X
select SND_SOC_UDA1380 if I2C
-   select SND_SOC_WL1273 if RADIO_WL1273
+   select SND_SOC_WL1273 if MFD_WL1273_CORE
select SND_SOC_WM2000 if I2C
select SND_SOC_WM8350 if MFD_WM8350
select SND_SOC_WM8400 if MFD_WM8400
diff --git a/sound/soc/codecs/wl1273.c b/sound/soc/codecs/wl1273.c
index 861b28f..3c27fed 100644
--- a/sound/soc/codecs/wl1273.c
+++ b/sound/soc/codecs/wl1273.c
@@ -3,7 +3,7 @@
  *
  * Author:  Matti Aaltonen, 
  *
- * Copyright:   (C) 2010 Nokia Corporation
+ * Copyright:   (C) 2011 Nokia Corporation
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -179,7 +179,12 @@ static int snd_wl1273_get_audio_route(struct snd_kcontrol 
*kcontrol,
return 0;
 }
 
-static const char *wl1273_audio_route[] = { "Bt", "FmRx", "FmTx" };
+/*
+ * TODO: Implement the audio routing in the driver. Now this control
+ * only indicates the setting that has been done elsewhere (in the user
+ * space).
+ */
+static const char * const wl1273_audio_route[] = { "Bt", "FmRx", "FmTx" };
 
 static int snd_wl1273_set_audio_route(struct snd_kcontrol *kcontrol,
  struct snd_ctl_elem_value *ucontrol)
@@ -239,7 +244,7 @@ static int snd_wl1273_fm_audio_put(struct snd_kcontrol 
*kcontrol,
return 1;
 }
 
-static const char *wl1273_audio_strings[] = { "Digital", "Analog" };
+static const char * const wl1273_audio_strings[] = { "Digital", "Analog" };
 
 static const struct soc_enum wl1273_audio_enum =
SOC_ENUM_SINGLE_EXT(ARRAY_SIZE(wl1273_audio_strings),
-- 
1.6.1.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