Re: DVBv5 frontend library

[Rémi Denis-Courmont]

   Hello kernel-space friends,



On Wed, 09 Nov 2011 17:01:59 -0200, Mauro Carvalho Chehab

 wrote:

> As I've commented with some at the KS, I started writing a new DVB

> library, based on DVBv5.

> It is currently at very early stages. Help and suggestions are welcome.

> 

> It is at:

>


http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/shortlog/refs/heads/dvb-utils

> 

> It currently doesn't do much, but the hole idea is to offer a library

that

> can easily upgraded to support new standards, and based on DVBv5.



IMHO, adding new standards with DVBv5 is already fairly easy, as opposed

to with DVBv3.



The only issue I've had (while porting VLC to DVBv5) lied in determining

which parameters needed to be set and what values they would accept.



(...)

> The frontend library is inside:

>   dvb-fe.c  

>   dvb-fe.h 

> 

> And the pertinent parameters needed by each delivery system is provided

> into a separate header:

>   dvb-v5-std.h  



As a documentation, it's nice to have. It should also enumerate the legal

values, a bit like V4L2 user controls.



However, I'm not sure how useful it can really be used to abstract away

tuning standards. There are a number of problems remaining:



1) User-space may need localization of parameters names and enumeration

value names. For frequency, we also need a unit, since it depends on the

delivery system. In VLC, we have to replicate and keep the list of

well-known V4L2 controls parameters just so gettext sees them. The same

problem would affect DVB if you carry on with this.



And unfortunately, even if v4l-utils had its own gettext domain, I doubt

it would get as good visibility among translators as end-user applications

have (e.g. VLC has 78 locales as of today).



2) Some user-space are cross-platform, say across Linux DVB and Windows

BDA. Since Windows BDA does not abstract delivery subsystems, such software

cannot leverage dvb-v5-std.h.



3) Some settings are absolutely required (e.g. frequency), some may be

required depending on hardware and/or driver, some are not normally

required to tune. When writing a UI, you need to know that.



4) Systems like DVB-H (R.I.P.) or ATSC-M/H cannot be abstracted

meaningfully as they don't provide a TS feed, so the user-space can't use

them.



5) Unless/Until the library implements scanning and some kind of channel

or transponder abstraction (e.g. unique ID per transponder), it is dubious

that it can really abstract new delivery systems. I mean, the tuning

parameters need to come from somewhere, so the application will have to

know about the delivery systems.





So hmm, that's a lot of problems before I could use that library. Maybe

some other user-space guys are less demanding bitches though :-)



-- 

Rémi Denis-Courmont

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

Re: [RFC 2/2] tda18218: use generic dvb_wr_regs()

[Antti Palosaari]

Hello
After today discussion I think at least following configuration options 
could be possible:


address len, for format msg
register value len, for format msg
max write len, for splitting
max read len, for splitting
option for repeated start, for splitting
conditional error logging
callback for I2C-mux (I2C-gate)
general functions implemented: wr_regs, rd_regs, wr_reg, rd_reg, 
wr_reg_mask, wr_reg_bits, rd_reg_bits

support for register banks?

That's full list of ideas I have as now. At least in first phase I think 
only basic register reads and writes are enough.


I wonder if Jean could be as main leader of development since he has 
surely best knowledge about I2C and all possible users. Otherwise, I 
think I could do it only as linux-media common functionality, because I 
don't have enough knowledge about other users.


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

Re: Hauppauge HVR900H don't work with kernel 3.*

[Lars Schotte]

i dont know about digital, but to me it crashes the USB probe after
connect-disconnect-reconnect. after that, it doesnt notice any changes
in connected USB devices and need to restart.

it may be possible, that there is some module hanging in there, because
i get the same problem when i have femon running and then disconnect
the dvb device (no matter which one - volarHD in my case), because it
is stuck as femon "uses" the driver. when i kill femon, everything
runns again.

so my theory is, that there is somewhat stuck in there. and it doesnt
help to remove the DVB driver. so it is definitely something with the
analogue part (and analog is what i need, because there are not many
devices that do analog any more).

On Wed, 9 Nov 2011 21:08:59 + (GMT)
Norret Thierry  wrote:

> Hello,
> I have this card
> http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-900H and
> use gentoo Since I upgrade my kernel from 2.6.38 to 3.* scan for
> channel doesn't work and channels can't be lock
> 
> The modules (tm6000) are load, the firmware (xc3028L-v36.fw) is
> copied to /lib/firmware, the signal is good but no channels found
> with w_scan/vlc/mplayer/kaffeineI don't see any error in dmesg.
> 
> I've try last distros (ubuntu 11.10, fedora 16) with kernel 3.* and
> same results. The last git sources from v4l/dvb don't resolve the
> problem.
> 
> Thanks
> 
> 
> # dmesg
> [   81.132653] IR NEC protocol handler initialized
> [   81.158229] tm6000: module is from the staging directory, the
> quality is unknown, you have been warned.
> [   81.158801] tm6000 v4l2 driver version 0.0.2 loaded
> [   81.160885] tm6000: alt 0, interface 0, class 255
> [   81.160890] tm6000: alt 0, interface 0, class 255
> [   81.160895] tm6000: Bulk IN endpoint: 0x82 (max size=512 bytes)
> [   81.160899] tm6000: alt 0, interface 0, class 255
> [   81.160903] tm6000: alt 1, interface 0, class 255
> [   81.160907] tm6000: ISOC IN endpoint: 0x81 (max size=3072 bytes)
> [   81.160911] tm6000: alt 1, interface 0, class 255
> [   81.160914] tm6000: alt 1, interface 0, class 255
> [   81.160918] tm6000: INT IN endpoint: 0x83 (max size=4 bytes)
> [   81.160922] tm6000: alt 2, interface 0, class 255
> [   81.160925] tm6000: alt 2, interface 0, class 255
> [   81.160929] tm6000: alt 2, interface 0, class 255
> [   81.160932] tm6000: alt 3, interface 0, class 255
> [   81.160936] tm6000: alt 3, interface 0, class 255
> [   81.160939] tm6000: alt 3, interface 0, class 255
> [   81.160943] tm6000: New video device @ 480 Mbps (2040:6600, ifnum
> 0) [   81.160947] tm6000: Found Hauppauge WinTV HVR-900H / WinTV
> USB2-Stick [   81.167856] Found tm6010
> [   81.176973] IR RC5(x) protocol handler initialized
> [   81.183409] IR RC6 protocol handler initialized
> [   81.185159] IR JVC protocol handler initialized
> [   81.187524] IR Sony protocol handler initialized
> [   81.201304] lirc_dev: IR Remote Control driver registered, major
> 250 [   81.206121] IR LIRC bridge handler initialized
> [   81.964984] tm6000 #0: i2c eeprom 00: 01 59 54 45 12 01 00 02 00
> 00 00 40 40 20 00 66  .YTE...@@ .f
> [   82.076933] tm6000 #0: i2c eeprom 10: 69 00 10 20 40 01 02 03 48
> 00 79 00 62 00 72 00  i.. @...H.y.b.r.
> [   82.188834] tm6000 #0: i2c eeprom 20: ff 00 64 ff ff ff ff ff ff
> ff ff ff ff ff ff ff  ..d.
> [   82.300725] tm6000 #0: i2c eeprom 30: ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff  
> [   82.412622] tm6000 #0: i2c eeprom 40: 10 03 48 00 56 00 52 00 39
> 00 30 00 30 00 48 00  ..H.V.R.9.0.0.H.
> [   82.524561] tm6000 #0: i2c eeprom 50: ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff  
> [   82.636402] tm6000 #0: i2c eeprom 60: 30 ff ff ff 0f ff ff ff ff
> ff 0a 03 32 00 2e 00  0...2...
> [   82.748303] tm6000 #0: i2c eeprom 70: 3f 00 ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff  ?...
> [   82.860197] tm6000 #0: i2c eeprom 80: ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff  
> [   82.972092] tm6000 #0: i2c eeprom 90: 32 ff ff ff 16 03 34 00 30
> 00 33 00 32 00 31 00  2.4.0.3.2.1.
> [   83.083977] tm6000 #0: i2c eeprom a0: 33 00 34 00 39 00 30 00 32
> 00 00 00 00 00 ff ff  3.4.9.0.2...
> [   83.195871] tm6000 #0: i2c eeprom b0: ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff  
> [   83.307773] tm6000 #0: i2c eeprom c0: ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff  
> [   83.419666] tm6000 #0: i2c eeprom d0: ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff  
> [   83.531535] tm6000 #0: i2c eeprom e0: ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff  
> [   83.643448] tm6000 #0: i2c eeprom f0: ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff  
> [   83.801012] i2c-core: driver [tuner] using legacy suspend method
> [   83.801017] i2c-core: driver [tuner] using legacy resume method
> [   83.801303] tuner 1-0061: Tuner -1 found with type(s) Radio TV.
> [   83.801309] xc2028 1

Re: [RFC 2/2] tda18218: use generic dvb_wr_regs()

[Antti Palosaari]

On 11/10/2011 12:06 AM, tvboxspy wrote:

The only thing I am not sure is whether devices such as af9013 are
keeping their gate control continuously open through the write
operations and not timing out.

This applies to tda18218, mxl5005s and other tuners, which have
multipliable writes with no gate control between the writes, only at the
start and end of the sequence.

Afatech seem to imply that full gate control is required on all I2C
read/write operations.

With other devices such as stv0288 do close their gate after a stop
condition.


You mean AF9013 demod will close it gate automatically after the I2C 
STOP ? Answer is no.


There are some demods which closes it automatically, like RTL2830, and 
some may have configuration if close automatically or not. But most 
common is that gate needs to be opened and closed manually.


In case of automatic gate close it is easiest way to implement own 
I2C-adapter for demod. There is few such demods drivers already 
(implementing their own I2C-adapter).


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

Re: [RFC 2/2] tda18218: use generic dvb_wr_regs()

[tvboxspy]

On 08/11/11 23:59, Antti Palosaari wrote:

Signed-off-by: Antti Palosaari 
---
drivers/media/common/tuners/tda18218.c | 69 +-
drivers/media/common/tuners/tda18218_priv.h | 3 +
2 files changed, 17 insertions(+), 55 deletions(-)

diff --git a/drivers/media/common/tuners/tda18218.c
b/drivers/media/common/tuners/tda18218.c
index aacfe23..fef5560f 100644
--- a/drivers/media/common/tuners/tda18218.c
+++ b/drivers/media/common/tuners/tda18218.c
@@ -25,46 +25,6 @@ static int debug;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Turn on/off debugging (default:off).");

-/* write multiple registers */
-static int tda18218_wr_regs(struct tda18218_priv *priv, u8 reg, u8
*val, u8 len)
-{
- int ret = 0;
- u8 buf[1+len], quotient, remainder, i, msg_len, msg_len_max;
- struct i2c_msg msg[1] = {
- {
- .addr = priv->cfg->i2c_address,
- .flags = 0,
- .buf = buf,
- }
- };
-
- msg_len_max = priv->cfg->i2c_wr_max - 1;
- quotient = len / msg_len_max;
- remainder = len % msg_len_max;
- msg_len = msg_len_max;
- for (i = 0; (i <= quotient && remainder); i++) {
- if (i == quotient) /* set len of the last msg */
- msg_len = remainder;
-
- msg[0].len = msg_len + 1;
- buf[0] = reg + i * msg_len_max;
- memcpy(&buf[1], &val[i * msg_len_max], msg_len);
-
- ret = i2c_transfer(priv->i2c, msg, 1);
- if (ret != 1)
- break;
- }


The only thing I am not sure is whether devices such as af9013 are 
keeping their gate control continuously open through the write 
operations and not timing out.


This applies to tda18218, mxl5005s and other tuners, which have 
multipliable writes with no gate control between the writes, only at the 
start and end of the sequence.


Afatech seem to imply that full gate control is required on all I2C 
read/write operations.


With other devices such as stv0288 do close their gate after a stop 
condition.


Regards


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

DAB+ prague and terratec noxon dab stick support

[Lars Schotte]

well, i see that there has been some v4l workshop in prague.

there are two things in prague that are relevant:
1.) they have a testing DVB-T2 mux running
2.) they have DAB/DAB+ mux running

i have a terratec noxon dab stick. it doesnt run on windows well, but
it is a terratec device and terratec devices are usually supported on
linux, but this one is not and not even a DAB/DAB+ support i ve seen in
the kernel, so the question is, what now?

there are a lot of countries in europe that jumped on DAB+, like
Germany, czech republic, austria, and in the future also slovakia.
and not to forget the non-eu ones, like Swizerland and the eu-"experts"
in united kingdom.

one reason why i bought that terratec noxon dab stick is, that i surely
know that it will be supported on linux someday, the question only is
when. the sooner, the better. and i got it for 20 eur.

that device seems to be (co-)developed with Frauenhofer Institut, or
what they call themselves (you can check on the website by yourself, if
interested). that means that there should be some technical
documentation on that device (or at least its chipset). if there is
none, that would be rude, because that instutute is like a state
university, but without the teaching part, so they only do research
for ... ehm ... it should be for the people.

i will take a closer look at that device by myself, i already tried it
to get to work with windows (wasnt much success, it works but after
unpluging it says, that there is no signal and have to replug again ...
in short - their driver is not of the smartest genere).

so i just wanted to announce it here. i am not a developer, so i dont
have the capability to write the driver by myself, at least not in
reasonable timeframe. maybe in the future.
but i can help with testing, if someone already tampers with it.

-- 
Lars Schotte
@ Hana (F16)
--
To unsubscribe from this list: send the line "unsubscribe 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: [KS workshop follow-up] multiple sensor contexts

[Guennadi Liakhovetski]

On Wed, 9 Nov 2011, Sylwester Nawrocki wrote:

> Hi Guennadi,
> 
> On 11/07/2011 05:17 PM, Guennadi Liakhovetski wrote:
> > Hi all
> > 
> > At the V4L/DVB workshop in Prague a couple of weeks ago possible merits of
> > supporting multiple camera sensor contexts have been discussed. Such
> > contexts are often promoted by camera manufacturers as a hardware
> > optimization to support fast switching to the snapshot mode. Such a switch
> > is often accompanied by a change of the frame format. Typically, a smaller
> > frame is used for the preview mode and a larger frame is used for photo
> > shooting. Those sensors provide 2 (or more) sets of frame size and data
> > format registers and a single command to switch between them. The
> > decision, whether or not to support these multiple camera contexts has
> > been postponed until some measurements become available, how much time
> > such a "fast switching" implementation would save us.
> > 
> > I took the mt9m111 driver, that supports mt9m111, mt9m131, and mt9m112
> > camera sensors from Aptina. They do indeed implement two contexts,
> > however, the driver first had to be somewhat reorganised to make use of
> > them. I pushed my (highly!) experimental tree to
> > 
> > git://linuxtv.org/gliakhovetski/v4l-dvb.git staging-3.3
> > 
> > with the addition of the below debugging diff, that pre-programs a fixed
> > format into the second context registers and switches to it, once a
> > matching S_FMT is called. On the i.MX31 based pcm037 board, that I've got,
> > this sensor is attached to the I2C bus #2, running at 20kHz. The explicit
> > programming of the new format parameters measures to take around 27ms,
> > which is also about what we win, when using the second context.
> 
> I was expecting the re-programming time being not significant like this.
> I'll try to reserve some time next week to measure how long the sensor
> re-programming takes in case of m5mols device. It has quite a few registers
> to write but its I2C bus clock frequency is 400 kHz so perhaps the results 
> will be similar to yours. 
> 
> > 
> > As for interpretation: firstly 20kHz is not much, I expect many other set
> > ups to run much faster. But even if we accept, that on some hardware>
> > 20kHz doesn't work and we really lose 27ms when not using multiple
> > register contexts, is it a lot? Thinking about my personal photographing
> > experiences with cameras and camera-phones, I don't think, I'd notice a
> > 27ms latency;-) I don't think anything below 200ms really makes a
> > difference and, I think, the major contributor to the snapshot latency is
> > the need to synchronise on a frame, and, possibly skip or shoot several
> > frames, instead of just one.
> > 
> > So, my conclusion would be: when working with "sane" camera sensors, i.e.,
> > those, where you don't have to reprogram 100s of registers from some magic
> > tables to configure a different frame format (;-)), supporting several
> > register contexts doesn't bring a huge advantage in terms of snapshot
> > latency. OTOH, it can well happen, that at some point we anyway will have
> > to support those multiple register contexts for some other reason.
> 
> Hmm, I'm wondering what should the drivers do in case of devices that require 
> explicit setting of some control registers for still capture. Guessing on 
> pixel
> format basis is rather a poor men's solution. This is what M-5MOLS mainline 
> driver
> doeas - if JPEG format is set it switches to snaphot mode. This way YUV format
> cannot be used in snaphot mode.
> There are also distinct resolutions supported for snaphot mode, and it can't 
> be
> currently properly enumerated.
> 
> Hence my question is, should such (whatsoever rare) devices stick with 
> _private_ 
> controls ?
> 
> If we have used VIDIOC_STREAMON for triggering capture, something like 
> boolean 
> SNAPSHOT control is needed, for instance, to tell the sensor controller it 
> should
> fire the flash. 

Yes, I think, that was one of the conclusions of the workshop on this 
topic: we need a new control (a common one, not a private one) to switch 
to snapshot mode. I think, it has been agreed, that someone, (who first 
hits a valid practical use-case?;-)) submits an RFC / patch for such a 
control with a sufficiently detailed description of its semantics...

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

Re: [KS workshop follow-up] multiple sensor contexts

[Sylwester Nawrocki]

Hi Guennadi,

On 11/07/2011 05:17 PM, Guennadi Liakhovetski wrote:
> Hi all
> 
> At the V4L/DVB workshop in Prague a couple of weeks ago possible merits of
> supporting multiple camera sensor contexts have been discussed. Such
> contexts are often promoted by camera manufacturers as a hardware
> optimization to support fast switching to the snapshot mode. Such a switch
> is often accompanied by a change of the frame format. Typically, a smaller
> frame is used for the preview mode and a larger frame is used for photo
> shooting. Those sensors provide 2 (or more) sets of frame size and data
> format registers and a single command to switch between them. The
> decision, whether or not to support these multiple camera contexts has
> been postponed until some measurements become available, how much time
> such a "fast switching" implementation would save us.
> 
> I took the mt9m111 driver, that supports mt9m111, mt9m131, and mt9m112
> camera sensors from Aptina. They do indeed implement two contexts,
> however, the driver first had to be somewhat reorganised to make use of
> them. I pushed my (highly!) experimental tree to
> 
> git://linuxtv.org/gliakhovetski/v4l-dvb.git staging-3.3
> 
> with the addition of the below debugging diff, that pre-programs a fixed
> format into the second context registers and switches to it, once a
> matching S_FMT is called. On the i.MX31 based pcm037 board, that I've got,
> this sensor is attached to the I2C bus #2, running at 20kHz. The explicit
> programming of the new format parameters measures to take around 27ms,
> which is also about what we win, when using the second context.

I was expecting the re-programming time being not significant like this.
I'll try to reserve some time next week to measure how long the sensor
re-programming takes in case of m5mols device. It has quite a few registers
to write but its I2C bus clock frequency is 400 kHz so perhaps the results 
will be similar to yours. 

> 
> As for interpretation: firstly 20kHz is not much, I expect many other set
> ups to run much faster. But even if we accept, that on some hardware>
> 20kHz doesn't work and we really lose 27ms when not using multiple
> register contexts, is it a lot? Thinking about my personal photographing
> experiences with cameras and camera-phones, I don't think, I'd notice a
> 27ms latency;-) I don't think anything below 200ms really makes a
> difference and, I think, the major contributor to the snapshot latency is
> the need to synchronise on a frame, and, possibly skip or shoot several
> frames, instead of just one.
> 
> So, my conclusion would be: when working with "sane" camera sensors, i.e.,
> those, where you don't have to reprogram 100s of registers from some magic
> tables to configure a different frame format (;-)), supporting several
> register contexts doesn't bring a huge advantage in terms of snapshot
> latency. OTOH, it can well happen, that at some point we anyway will have
> to support those multiple register contexts for some other reason.

Hmm, I'm wondering what should the drivers do in case of devices that require 
explicit setting of some control registers for still capture. Guessing on pixel
format basis is rather a poor men's solution. This is what M-5MOLS mainline 
driver
doeas - if JPEG format is set it switches to snaphot mode. This way YUV format
cannot be used in snaphot mode.
There are also distinct resolutions supported for snaphot mode, and it can't be
currently properly enumerated.

Hence my question is, should such (whatsoever rare) devices stick with 
_private_ 
controls ?

If we have used VIDIOC_STREAMON for triggering capture, something like boolean 
SNAPSHOT control is needed, for instance, to tell the sensor controller it 
should
fire the flash. 

--
Regards,
Sylwester

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

Hauppauge HVR900H don't work with kernel 3.*

[Norret Thierry]

Hello,
I have this card http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-900H 
and use gentoo
Since I upgrade my kernel from 2.6.38 to 3.* scan for channel doesn't work and 
channels can't be lock

The modules (tm6000) are load, the firmware (xc3028L-v36.fw) is copied to 
/lib/firmware, the signal is good but no channels found with 
w_scan/vlc/mplayer/kaffeineI don't see any error in dmesg.

I've try last distros (ubuntu 11.10, fedora 16) with kernel 3.* and same 
results.
The last git sources from v4l/dvb don't resolve the problem.

Thanks


# dmesg
[   81.132653] IR NEC protocol handler initialized
[   81.158229] tm6000: module is from the staging directory, the quality is
unknown, you have been warned.
[   81.158801] tm6000 v4l2 driver version 0.0.2 loaded
[   81.160885] tm6000: alt 0, interface 0, class 255
[   81.160890] tm6000: alt 0, interface 0, class 255
[   81.160895] tm6000: Bulk IN endpoint: 0x82 (max size=512 bytes)
[   81.160899] tm6000: alt 0, interface 0, class 255
[   81.160903] tm6000: alt 1, interface 0, class 255
[   81.160907] tm6000: ISOC IN endpoint: 0x81 (max size=3072 bytes)
[   81.160911] tm6000: alt 1, interface 0, class 255
[   81.160914] tm6000: alt 1, interface 0, class 255
[   81.160918] tm6000: INT IN endpoint: 0x83 (max size=4 bytes)
[   81.160922] tm6000: alt 2, interface 0, class 255
[   81.160925] tm6000: alt 2, interface 0, class 255
[   81.160929] tm6000: alt 2, interface 0, class 255
[   81.160932] tm6000: alt 3, interface 0, class 255
[   81.160936] tm6000: alt 3, interface 0, class 255
[   81.160939] tm6000: alt 3, interface 0, class 255
[   81.160943] tm6000: New video device @ 480 Mbps (2040:6600, ifnum 0)
[   81.160947] tm6000: Found Hauppauge WinTV HVR-900H / WinTV USB2-Stick
[   81.167856] Found tm6010
[   81.176973] IR RC5(x) protocol handler initialized
[   81.183409] IR RC6 protocol handler initialized
[   81.185159] IR JVC protocol handler initialized
[   81.187524] IR Sony protocol handler initialized
[   81.201304] lirc_dev: IR Remote Control driver registered, major 250 
[   81.206121] IR LIRC bridge handler initialized
[   81.964984] tm6000 #0: i2c eeprom 00: 01 59 54 45 12 01 00 02 00 00 00 40 40
20 00 66  .YTE...@@ .f
[   82.076933] tm6000 #0: i2c eeprom 10: 69 00 10 20 40 01 02 03 48 00 79 00 62
00 72 00  i.. @...H.y.b.r.
[   82.188834] tm6000 #0: i2c eeprom 20: ff 00 64 ff ff ff ff ff ff ff ff ff ff
ff ff ff  ..d.
[   82.300725] tm6000 #0: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff  
[   82.412622] tm6000 #0: i2c eeprom 40: 10 03 48 00 56 00 52 00 39 00 30 00 30
00 48 00  ..H.V.R.9.0.0.H.
[   82.524561] tm6000 #0: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff  
[   82.636402] tm6000 #0: i2c eeprom 60: 30 ff ff ff 0f ff ff ff ff ff 0a 03 32
00 2e 00  0...2...
[   82.748303] tm6000 #0: i2c eeprom 70: 3f 00 ff ff ff ff ff ff ff ff ff ff ff
ff ff ff  ?...
[   82.860197] tm6000 #0: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff  
[   82.972092] tm6000 #0: i2c eeprom 90: 32 ff ff ff 16 03 34 00 30 00 33 00 32
00 31 00  2.4.0.3.2.1.
[   83.083977] tm6000 #0: i2c eeprom a0: 33 00 34 00 39 00 30 00 32 00 00 00 00
00 ff ff  3.4.9.0.2...
[   83.195871] tm6000 #0: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff  
[   83.307773] tm6000 #0: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff  
[   83.419666] tm6000 #0: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff  
[   83.531535] tm6000 #0: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff  
[   83.643448] tm6000 #0: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff  
[   83.801012] i2c-core: driver [tuner] using legacy suspend method
[   83.801017] i2c-core: driver [tuner] using legacy resume method
[   83.801303] tuner 1-0061: Tuner -1 found with type(s) Radio TV.
[   83.801309] xc2028 1-0061: creating new instance
[   83.801311] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner
[   83.801313] Setting firmware parameters for xc2028
[   83.804849] xc2028 1-0061: Loading 81 firmware images from xc3028L-v36.fw,
type: xc2028 firmware, ver 3.6
[   84.021087] xc2028 1-0061: Loading firmware for type=BASE (1), id
.
[  109.684698] xc2028 1-0061: Loading firmware for type=(0), id
b700.
[  110.118322] SCODE (2000), id b700:
[  110.118331] xc2028 1-0061: Loading SCODE for type=MONO SCODE HAS_IF_4320
(60008000), id 8000.
[  110.733824] tm6000 #0: registered device video1
[  110.733831] Trident TVMaster TM5600/TM6000/TM6010 USB2 board (Load status:
0)
[  110.733865] usbcore: registered new interface driver tm6000
[  110.735587] tm6000: open called (dev=video1)
[  110.812501] tm6000_dvb: module is from the staging directory, the quality is
unknown, you have been warne

Re: [RFC 1/2] dvb-core: add generic helper function for I2C register

[Malcolm Priestley]

On 09/11/11 10:52, Jean Delvare wrote:

On Wed, 09 Nov 2011 12:41:36 +0200, Antti Palosaari wrote:

On 11/09/2011 11:56 AM, Mauro Carvalho Chehab wrote:

Due to the way I2C locks are bound, doing something like the above and 
something like:

  struct i2c_msg msg[2] = {
  {
  .addr = i2c_cfg->addr,
  .flags = 0,
  .buf = buf,
  },
  {
  .addr = i2c_cfg->addr,
  .flags = 0,
  .buf = buf2,
  }

  };

  ret = i2c_transfer(i2c_cfg->adapter, msg, 2);

Produces a different result. In the latter case, I2C core avoids having any 
other
transaction in the middle of the 2 messages.


In my understanding adding more messages than one means those should be
handled as one I2C transaction using REPEATED START.
I see one big problem here, it is our adapters. I think again, for the
experience I have, most of our I2C-adapters can do only 3 different
types of I2C xfers;
* I2C write
* I2C write + I2C read (combined with REPEATED START)
* I2C read (I suspect many adapters does not support that)
That means, I2C REPEATED writes  are not possible.


Also, some adapters _or slaves_ won't support more than one repeated
start in a given transaction, so splitting block reads in continuous
chunks won't always work either. Which makes some sense if you think
about it: if both the slave and the controller supported larger blocks
then there would be no need to split the transfer into multiple
messages in the first place.



Yes, I can immediately think of the stv0288 which can receive up to 108 
bytes continuous write of its register map, but using the lme2510c 
controller won't write more than 16, probably beyond the limit of the 
firmwares buffer.


I think mostly, you are at the mercy of the controller firmware and not 
really the host i2c controller abilities.


Regards

Malcolm
--
To unsubscribe from this list: send the line "unsubscribe 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] Mygica X8507

[Alfredo Jesús Delaiti]

Hi

This patch supports card Mygica X8507 (analog part)

This controller is a copy of driver card Mygica X8506

This patch depends on patch cx23885-alsa 



To do: FM, ISDB-t, remote control, audio for composite1, S-Video and 
componet


kernel version 3.1.0-3; OpenSuSE 11.4 64bit

Signed-off-by: Alfredo J. Delaiti 

My apologies if I have once again committed an error sending the patch

Thanks,

Alfredo


--
Dona tu voz
http://www.voxforge.org/es

diff -up1rN /usr/src/linux-media/drivers/media/video/cx23885/cx23885-cards.c /usr/src/linux/drivers/media/video/cx23885/cx23885-cards.c
--- /usr/src/linux-media/drivers/media/video/cx23885/cx23885-cards.c	2011-10-12 20:19:03.0 -0300
+++ /usr/src/linux/drivers/media/video/cx23885/cx23885-cards.c	2011-11-09 11:34:34.810810514 -0300
@@ -440,2 +440,32 @@ struct cx23885_board cx23885_boards[] =
 	},
+	[CX23885_BOARD_MYGICA_X8507] = {
+		.name		= "Mygica X8507",
+		.tuner_type = TUNER_XC5000,
+		.tuner_addr = 0x61,
+		.tuner_bus	= 1,
+		.porta		= CX23885_ANALOG_VIDEO,
+		.input		= {
+			{
+.type   = CX23885_VMUX_TELEVISION,
+.vmux   = CX25840_COMPOSITE2,
+.amux   = CX25840_AUDIO8,
+			},
+			{
+.type   = CX23885_VMUX_COMPOSITE1,
+.vmux   = CX25840_COMPOSITE8,
+			},
+			{
+.type   = CX23885_VMUX_SVIDEO,
+.vmux   = CX25840_SVIDEO_LUMA3 |
+		CX25840_SVIDEO_CHROMA4,
+			},
+			{
+.type   = CX23885_VMUX_COMPONENT,
+.vmux   = CX25840_COMPONENT_ON |
+	CX25840_VIN1_CH1 |
+	CX25840_VIN6_CH2 |
+	CX25840_VIN7_CH3,
+			},
+		},
+	}
 };
@@ -639,2 +669,6 @@ struct cx23885_subid cx23885_subids[] =
 		.card  = CX23885_BOARD_NETUP_DUAL_DVB_T_C_CI_RF,
+	}, {
+		.subvendor = 0x14f1,
+		.subdevice = 0x8502,
+		.card  = CX23885_BOARD_MYGICA_X8507,
 	},
@@ -1070,2 +1104,3 @@ void cx23885_gpio_setup(struct cx23885_d
 	case CX23885_BOARD_MAGICPRO_PROHDTVE2:
+	case CX23885_BOARD_MYGICA_X8507:
 		/* GPIO-0 (0)Analog / (1)Digital TV */
@@ -1470,2 +1505,3 @@ void cx23885_card_setup(struct cx23885_d
 	case CX23885_BOARD_MPX885:
+	case CX23885_BOARD_MYGICA_X8507:
 		dev->sd_cx25840 = v4l2_i2c_new_subdev(&dev->v4l2_dev,
diff -up1rN /usr/src/linux-media/drivers/media/video/cx23885/cx23885.h /usr/src/linux/drivers/media/video/cx23885/cx23885.h
--- /usr/src/linux-media/drivers/media/video/cx23885/cx23885.h	2011-10-12 20:20:38.0 -0300
+++ /usr/src/linux/drivers/media/video/cx23885/cx23885.h	2011-11-09 11:20:13.838836142 -0300
@@ -89,2 +89,3 @@
 #define CX23885_BOARD_MPX885   32
+#define CX23885_BOARD_MYGICA_X8507 33
 
diff -up1rN /usr/src/linux-media/drivers/media/video/cx23885/cx23885-video.c /usr/src/linux/drivers/media/video/cx23885/cx23885-video.c
--- /usr/src/linux-media/drivers/media/video/cx23885/cx23885-video.c	2011-10-12 20:20:33.0 -0300
+++ /usr/src/linux/drivers/media/video/cx23885/cx23885-video.c	2011-11-09 11:39:29.458801749 -0300
@@ -494,3 +494,4 @@ static int cx23885_video_mux(struct cx23
 	if (dev->board == CX23885_BOARD_MYGICA_X8506 ||
-		dev->board == CX23885_BOARD_MAGICPRO_PROHDTVE2) {
+		dev->board == CX23885_BOARD_MAGICPRO_PROHDTVE2 ||
+		dev->board == CX23885_BOARD_MYGICA_X8507) {
 		/* Select Analog TV */

DVBv5 frontend library

[Mauro Carvalho Chehab]

Hi,

As I've commented with some at the KS, I started writing a new DVB library, 
based on DVBv5.
It is currently at very early stages. Help and suggestions are welcome.

It is at:

http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/shortlog/refs/heads/dvb-utils

It currently doesn't do much, but the hole idea is to offer a library that can 
easily
upgraded to support new standards, and based on DVBv5.

The new stuff is under utils/dvb dir.

For now, it has only a few files:

gen_dvb_structs.pl: Extracts DVBv5 API information from dvb/frontend.h.
Just as a commodity, for now, the DVB API spec were copied as dvb_frontend.h
inside the tree.

dvb-v5.h: a file, generated from dvb/frontend.h using the perl script.
It basically defines a name for each enum value inside the dvb/frontend.h 
header.

The frontend library is inside:
dvb-fe.c  
dvb-fe.h 

And the pertinent parameters needed by each delivery system is provided into
a separate header:
dvb-v5-std.h  

There's a small test tool that currently just queries the DVB capabilities,
at:
dvb-fe-tool.c  

The test tool currently does nothing but querying the device capabilities, 
identifying
the supported delivery systems.

I hope this could be helpful for the ones working with DVBv5. Patches, 
suggestions, etc
are welcome.

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

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:Wed Nov  9 19:00:17 CET 2011
git hash:e9eb0dadba932940f721f9d27544a7818b2fa1c5
gcc version:  i686-linux-gcc (GCC) 4.6.1
host hardware:x86_64
host os:  3.0-4.slh.7-amd64

linux-git-arm-eabi-enoxys: WARNINGS
linux-git-arm-eabi-omap: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: OK
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: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-3.0-i686: WARNINGS
linux-3.1-i686: WARNINGS
linux-3.2-rc1-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: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
linux-3.0-x86_64: WARNINGS
linux-3.1-x86_64: WARNINGS
linux-3.2-rc1-x86_64: ERRORS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

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

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

[PATCH] [media] video: Drop undue references to i2c-algo-bit

[Jean Delvare]

There's one comment that has been copied from bttv to many other
media/video drivers:

/* init + register i2c algo-bit adapter */

Meanwhile, many drivers use hardware I2C implementations instead of
relying on i2c-algo-bit, so this comment is misleading. Remove the
reference to "algo-bit" from all drivers, to avoid any confusion. This
is the best way to ensure that the comments won't go out of sync
again. Anyone interested in the implementation details would rather
look at the code itself.

Signed-off-by: Jean Delvare 
---
 drivers/media/video/au0828/au0828-i2c.c   |2 +-
 drivers/media/video/bt8xx/bttv-i2c.c  |2 +-
 drivers/media/video/cx18/cx18-i2c.c   |2 +-
 drivers/media/video/cx18/cx18-i2c.h   |2 +-
 drivers/media/video/cx23885/cx23885-i2c.c |2 +-
 drivers/media/video/cx25821/cx25821-i2c.c |2 +-
 drivers/media/video/cx88/cx88-i2c.c   |2 +-
 drivers/media/video/ivtv/ivtv-i2c.h   |2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

--- linux-3.2-rc0.orig/drivers/media/video/au0828/au0828-i2c.c  2011-07-22 
04:17:23.0 +0200
+++ linux-3.2-rc0/drivers/media/video/au0828/au0828-i2c.c   2011-11-07 
18:50:50.0 +0100
@@ -348,7 +348,7 @@ static void do_i2c_scan(char *name, stru
}
 }
 
-/* init + register i2c algo-bit adapter */
+/* init + register i2c adapter */
 int au0828_i2c_register(struct au0828_dev *dev)
 {
dprintk(1, "%s()\n", __func__);
--- linux-3.2-rc0.orig/drivers/media/video/bt8xx/bttv-i2c.c 2011-11-06 
17:44:24.0 +0100
+++ linux-3.2-rc0/drivers/media/video/bt8xx/bttv-i2c.c  2011-11-07 
18:51:13.0 +0100
@@ -346,7 +346,7 @@ static void do_i2c_scan(char *name, stru
}
 }
 
-/* init + register i2c algo-bit adapter */
+/* init + register i2c adapter */
 int __devinit init_bttv_i2c(struct bttv *btv)
 {
strlcpy(btv->i2c_client.name, "bttv internal", I2C_NAME_SIZE);
--- linux-3.2-rc0.orig/drivers/media/video/cx18/cx18-i2c.c  2011-07-22 
04:17:23.0 +0200
+++ linux-3.2-rc0/drivers/media/video/cx18/cx18-i2c.c   2011-11-07 
18:50:44.0 +0100
@@ -232,7 +232,7 @@ static struct i2c_algo_bit_data cx18_i2c
.timeout= CX18_ALGO_BIT_TIMEOUT*HZ /* jiffies */
 };
 
-/* init + register i2c algo-bit adapter */
+/* init + register i2c adapter */
 int init_cx18_i2c(struct cx18 *cx)
 {
int i, err;
--- linux-3.2-rc0.orig/drivers/media/video/cx18/cx18-i2c.h  2011-07-22 
04:17:23.0 +0200
+++ linux-3.2-rc0/drivers/media/video/cx18/cx18-i2c.h   2011-11-07 
18:50:38.0 +0100
@@ -24,6 +24,6 @@
 int cx18_i2c_register(struct cx18 *cx, unsigned idx);
 struct v4l2_subdev *cx18_find_hw(struct cx18 *cx, u32 hw);
 
-/* init + register i2c algo-bit adapter */
+/* init + register i2c adapter */
 int init_cx18_i2c(struct cx18 *cx);
 void exit_cx18_i2c(struct cx18 *cx);
--- linux-3.2-rc0.orig/drivers/media/video/cx23885/cx23885-i2c.c
2011-11-06 17:44:24.0 +0100
+++ linux-3.2-rc0/drivers/media/video/cx23885/cx23885-i2c.c 2011-11-07 
18:51:25.0 +0100
@@ -309,7 +309,7 @@ static void do_i2c_scan(char *name, stru
}
 }
 
-/* init + register i2c algo-bit adapter */
+/* init + register i2c adapter */
 int cx23885_i2c_register(struct cx23885_i2c *bus)
 {
struct cx23885_dev *dev = bus->dev;
--- linux-3.2-rc0.orig/drivers/media/video/cx25821/cx25821-i2c.c
2011-11-06 17:44:24.0 +0100
+++ linux-3.2-rc0/drivers/media/video/cx25821/cx25821-i2c.c 2011-11-07 
18:51:01.0 +0100
@@ -300,7 +300,7 @@ static struct i2c_client cx25821_i2c_cli
.name = "cx25821 internal",
 };
 
-/* init + register i2c algo-bit adapter */
+/* init + register i2c adapter */
 int cx25821_i2c_register(struct cx25821_i2c *bus)
 {
struct cx25821_dev *dev = bus->dev;
--- linux-3.2-rc0.orig/drivers/media/video/cx88/cx88-i2c.c  2011-07-22 
04:17:23.0 +0200
+++ linux-3.2-rc0/drivers/media/video/cx88/cx88-i2c.c   2011-11-07 
18:51:07.0 +0100
@@ -132,7 +132,7 @@ static void do_i2c_scan(const char *name
}
 }
 
-/* init + register i2c algo-bit adapter */
+/* init + register i2c adapter */
 int cx88_i2c_init(struct cx88_core *core, struct pci_dev *pci)
 {
/* Prevents usage of invalid delay values */
--- linux-3.2-rc0.orig/drivers/media/video/ivtv/ivtv-i2c.h  2011-07-22 
04:17:23.0 +0200
+++ linux-3.2-rc0/drivers/media/video/ivtv/ivtv-i2c.h   2011-11-07 
18:50:55.0 +0100
@@ -25,7 +25,7 @@ struct i2c_client *ivtv_i2c_new_ir_legac
 int ivtv_i2c_register(struct ivtv *itv, unsigned idx);
 struct v4l2_subdev *ivtv_find_hw(struct ivtv *itv, u32 hw);
 
-/* init + register i2c algo-bit adapter */
+/* init + register i2c adapter */
 int init_ivtv_i2c(struct ivtv *itv);
 void exit_ivtv_i2c(struct ivtv *itv);
 


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

Re: Using MT9P031 digital sensor

[Gary Thomas]

On 2011-11-09 09:18, Laurent Pinchart wrote:

Hi Gary,

On Wednesday 09 November 2011 12:01:34 Gary Thomas wrote:

On 2011-11-08 17:54, Laurent Pinchart wrote:

On Tuesday 08 November 2011 14:38:55 Gary Thomas wrote:

On 2011-11-08 06:06, Laurent Pinchart wrote:

On Tuesday 08 November 2011 13:52:25 Gary Thomas wrote:

On 2011-11-08 05:30, Javier Martinez Canillas wrote:

On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas wrote:

On 2011-11-04 04:37, Laurent Pinchart wrote:

On Tuesday 01 November 2011 19:52:49 Gary Thomas wrote:

I'm trying to use the MT9P031 digital sensor with the Media
Controller Framework.  media-ctl tells me that the sensor is set
to capture using SGRBG12  2592x1944

Questions:
* What pixel format in ffmpeg does this correspond to?


I don't know if ffmpeg supports Bayer formats. The corresponding
fourcc in V4L2 is BA12.


ffmpeg doesn't seem to support these formats


If your sensor is hooked up to the OMAP3 ISP, you can then
configure the pipeline to include the preview engine and the
resizer, and capture YUV data
at the resizer output.


I am using the OMAP3 ISP, but it's a bit unclear to me how to set up
the pipeline


Hi Gary,

I'm also using another sensor mtv9034 with OMAP3 ISP, so maybe I can
help you.


using media-ctl (I looked for documentation on this tool, but came
up dry - is there any?)

Do you have an example of how to configure this using the OMAP3 ISP?


This is how I configure the pipeline to connect the CCDC with the
Previewer and Resizer:

./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]'
./media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]'
./media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1]'
./media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer
output":0[1]' ./media-ctl -f '"mt9v032 3-005c":0[SGRBG10 752x480]'
./media-ctl -f  '"OMAP3 ISP CCDC":0 [SGRBG10 752x480]'
./media-ctl -f  '"OMAP3 ISP CCDC":1 [SGRBG10 752x480]'
./media-ctl -f  '"OMAP3 ISP preview":0 [SGRBG10 752x479]'
./media-ctl -f  '"OMAP3 ISP resizer":0 [YUYV 734x471]'
./media-ctl -f  '"OMAP3 ISP resizer":1 [YUYV 640x480]'

Hope it helps,


Thanks, I'll give this a try.

I assume that your sensor is probably larger than 752x480 (the mt9p031
is 2592x1944 raw) and that setting the smaller frame size enables some
scaling and/or cropping in the driver?


The mt9v034 is a wide VGA 752x480 sensor if I'm not mistaken. You
should modify the resolutions in the above commands according to your
sensor. Note that the CCDC crops online line when outputting data to
the preview engine, and that the preview engine crops 18 columsn and 8
lines. You can then scale the image by modifying the resizer output
size.


Thanks.  After much trial and error (and some kernel printks to

understand what parameters were failing), I came up with this sequence:
 media-ctl -r
 media-ctl -l '"mt9p031 3-005d":0->"OMAP3 ISP CCDC":0[1]'
 media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]'
 media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1]'
 media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer
 output":0[1]' media-ctl -f '"mt9p031 3-005d":0[SGRBG12 2592x1944]'
 media-ctl -f  '"OMAP3 ISP CCDC":0 [SGRBG12 2592x1944]'
 media-ctl -f  '"OMAP3 ISP CCDC":1 [SGRBG12 2592x1944]'
 media-ctl -f  '"OMAP3 ISP preview":0 [SGRBG12 2592x1943]'
 media-ctl -f  '"OMAP3 ISP resizer":0 [YUYV 2574x1935]'
 media-ctl -f  '"OMAP3 ISP resizer":1 [YUYV 642x483]'

When I tried to grab though, I got this:

# yavta --capture=4 -f YUYV -s 642x483 -F /dev/video6
Device /dev/video6 opened.
Device `OMAP3 ISP resizer output' on `media' is a video capture device.
Video format set: YUYV (56595559) 642x483 buffer size 633696
Video format: YUYV (56595559) 642x483 buffer size 633696
8 buffers requested.
length: 633696 offset: 0
Buffer 0 mapped at address 0x4028c000.
length: 633696 offset: 634880
Buffer 1 mapped at address 0x403d.
length: 633696 offset: 1269760
Buffer 2 mapped at address 0x404b3000.
length: 633696 offset: 1904640
Buffer 3 mapped at address 0x4062b000.
length: 633696 offset: 2539520
Buffer 4 mapped at address 0x406d6000.
length: 633696 offset: 3174400
Buffer 5 mapped at address 0x40821000.
length: 633696 offset: 3809280
Buffer 6 mapped at address 0x4097c000.
length: 633696 offset: 160
Buffer 7 mapped at address 0x40adf000.

Unable to handle kernel NULL pointer dereference at virtual address
0018


Ouch :-(

Could you please verify that arch/arm/mach-omap2/board-overo.c includes
the following code, and that CONFIG_OMAP_MUX is enabled ?


I'm not using an Overo board - rather one of our own internal designs.


My bad, sorry.


I have verified that the pull up/down on those pins is disabled.

The failure is coming from this code in ispccdc.c
static void ccdc_hs_vs_isr(struct isp_ccdc_device *ccdc)
{
  struct isp_pipeline *pipe =
to_isp_pipeline(&ccdc->video_out.video.entity);
The value of pipe is NULL which leads to the failure.

Re: Using MT9P031 digital sensor

[Laurent Pinchart]

Hi Gary,

On Wednesday 09 November 2011 12:01:34 Gary Thomas wrote:
> On 2011-11-08 17:54, Laurent Pinchart wrote:
> > On Tuesday 08 November 2011 14:38:55 Gary Thomas wrote:
> >> On 2011-11-08 06:06, Laurent Pinchart wrote:
> >>> On Tuesday 08 November 2011 13:52:25 Gary Thomas wrote:
>  On 2011-11-08 05:30, Javier Martinez Canillas wrote:
> > On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas wrote:
> >> On 2011-11-04 04:37, Laurent Pinchart wrote:
> >>> On Tuesday 01 November 2011 19:52:49 Gary Thomas wrote:
>  I'm trying to use the MT9P031 digital sensor with the Media
>  Controller Framework.  media-ctl tells me that the sensor is set
>  to capture using SGRBG12  2592x1944
>  
>  Questions:
>  * What pixel format in ffmpeg does this correspond to?
> >>> 
> >>> I don't know if ffmpeg supports Bayer formats. The corresponding
> >>> fourcc in V4L2 is BA12.
> >> 
> >> ffmpeg doesn't seem to support these formats
> >> 
> >>> If your sensor is hooked up to the OMAP3 ISP, you can then
> >>> configure the pipeline to include the preview engine and the
> >>> resizer, and capture YUV data
> >>> at the resizer output.
> >> 
> >> I am using the OMAP3 ISP, but it's a bit unclear to me how to set up
> >> the pipeline
> > 
> > Hi Gary,
> > 
> > I'm also using another sensor mtv9034 with OMAP3 ISP, so maybe I can
> > help you.
> > 
> >> using media-ctl (I looked for documentation on this tool, but came
> >> up dry - is there any?)
> >> 
> >> Do you have an example of how to configure this using the OMAP3 ISP?
> > 
> > This is how I configure the pipeline to connect the CCDC with the
> > Previewer and Resizer:
> > 
> > ./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]'
> > ./media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]'
> > ./media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1]'
> > ./media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer
> > output":0[1]' ./media-ctl -f '"mt9v032 3-005c":0[SGRBG10 752x480]'
> > ./media-ctl -f  '"OMAP3 ISP CCDC":0 [SGRBG10 752x480]'
> > ./media-ctl -f  '"OMAP3 ISP CCDC":1 [SGRBG10 752x480]'
> > ./media-ctl -f  '"OMAP3 ISP preview":0 [SGRBG10 752x479]'
> > ./media-ctl -f  '"OMAP3 ISP resizer":0 [YUYV 734x471]'
> > ./media-ctl -f  '"OMAP3 ISP resizer":1 [YUYV 640x480]'
> > 
> > Hope it helps,
>  
>  Thanks, I'll give this a try.
>  
>  I assume that your sensor is probably larger than 752x480 (the mt9p031
>  is 2592x1944 raw) and that setting the smaller frame size enables some
>  scaling and/or cropping in the driver?
> >>> 
> >>> The mt9v034 is a wide VGA 752x480 sensor if I'm not mistaken. You
> >>> should modify the resolutions in the above commands according to your
> >>> sensor. Note that the CCDC crops online line when outputting data to
> >>> the preview engine, and that the preview engine crops 18 columsn and 8
> >>> lines. You can then scale the image by modifying the resizer output
> >>> size.
> >> 
> >> Thanks.  After much trial and error (and some kernel printks to
> >> 
> >> understand what parameters were failing), I came up with this sequence:
> >> media-ctl -r
> >> media-ctl -l '"mt9p031 3-005d":0->"OMAP3 ISP CCDC":0[1]'
> >> media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]'
> >> media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1]'
> >> media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer
> >> output":0[1]' media-ctl -f '"mt9p031 3-005d":0[SGRBG12 2592x1944]'
> >> media-ctl -f  '"OMAP3 ISP CCDC":0 [SGRBG12 2592x1944]'
> >> media-ctl -f  '"OMAP3 ISP CCDC":1 [SGRBG12 2592x1944]'
> >> media-ctl -f  '"OMAP3 ISP preview":0 [SGRBG12 2592x1943]'
> >> media-ctl -f  '"OMAP3 ISP resizer":0 [YUYV 2574x1935]'
> >> media-ctl -f  '"OMAP3 ISP resizer":1 [YUYV 642x483]'
> >> 
> >> When I tried to grab though, I got this:
> >> 
> >> # yavta --capture=4 -f YUYV -s 642x483 -F /dev/video6
> >> Device /dev/video6 opened.
> >> Device `OMAP3 ISP resizer output' on `media' is a video capture device.
> >> Video format set: YUYV (56595559) 642x483 buffer size 633696
> >> Video format: YUYV (56595559) 642x483 buffer size 633696
> >> 8 buffers requested.
> >> length: 633696 offset: 0
> >> Buffer 0 mapped at address 0x4028c000.
> >> length: 633696 offset: 634880
> >> Buffer 1 mapped at address 0x403d.
> >> length: 633696 offset: 1269760
> >> Buffer 2 mapped at address 0x404b3000.
> >> length: 633696 offset: 1904640
> >> Buffer 3 mapped at address 0x4062b000.
> >> length: 633696 offset: 2539520
> >> Buffer 4 mapped at address 0x406d6000.
> >> length: 633696 offset: 3174400
> >> Buffer 5 mapped at address 0x40821000.
> >> length: 633696 offset: 3809280
> >> Buffer 6 mapped at address 0x4097c000.
> >> length: 633696 offset: 160
> >> Buffer 7 mapped at address 0x40

Re: [RFC 1/2] dvb-core: add generic helper function for I2C register

[Antti Palosaari]

Hello,
I compared all I2C-client drivers I have done and here are the results:
name = name of driver module
reg = reg addr len (bytes)
val = reg val len (bytes)
auto = auto increment
other = register banks, etc.

name   reg  val auto   other
qt1010   11?
af9013   21Y
ec10011?
tda18218 11Y
tua9001  12?
tda18212 11Y
cxd2820r 11?   bank
tda10071 11Y
a8293not relevant, only one control byte
rtl2830  11Y   bank
rtl2832  11Y   bank
af9033   3*   1Y   *bank/mailbox
 21Y

As we can see I2C msg structure where is address first ans after that 
payload is quite de Facto. There was only one driver which didn't meet 
that condition, it is LNB-controller which uses only one byte.


tda10071 driver has most typical register read and write routines and 
size of those are 70 LOC, including rd_reg, rd_regs, wr_reg, wr_regs, 
excluding bit based register functions.
12 drivers, ca. 70 LOC per driver makes 840 LOC of less code. And you 
can save even more if generalize bit register access functions too 
(commonly: wr_reg_mask, rd_reg_mask, wr_reg_bits, rd_reg_bits).


More comments below.

On 11/09/2011 12:37 PM, Jean Delvare wrote:

If code is duplicated, then something should indeed be done about it.
But preferably after analyzing properly what the helper functions
should look like, and for this you'll have to look at "all" drivers
that could benefit from it. At the moment only the tda18218 driver was
reported to need it, that's not enough to generalize.

You should take a look at drivers/misc/eeprom/at24.c, it contains
fairly complete transfer functions which cover the various EEPROM
types. Non-EEPROM devices could behave differently, but this would
still seem to be a good start for any I2C device using block transfers.
It was once proposed that these functions could make their way into
i2c-core or a generic i2c helper function.

Both at24 and Antti's proposal share the idea of storing information
about the device capabilities (max block read and write lengths, but we
could also put there alignment requirements or support for repeated
start condition.) in a private structure. If we generalize the
functions then this information would have to be stored in struct
i2c_client and possibly struct i2c_adapter (or struct i2c_algorithm) so
that the function can automatically find out the right sequence of
commands for the adapter/slave combination.

Speaking of struct i2c_client, I seem to remember that the dvb
subsystem doesn't use it much at the moment. This might be an issue if
you intend to get the generic code into i2c-core, as most helper
functions rely on a valid i2c_client structure by design.


As we have now some kind of understanding what is needed, could you 
start direct planning? I am ready to implement some basic stuff that I 
see most benefit (listed below).


The functions I see most important are:
wr_regs
rd_regs
wr_reg
rg_reg
wr_reg_mask
wr_reg_bits
rd_reg_bits


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

重要文件39696779

[ztlgycwgh]

23:43:57你好，我们公 司有发 e票可以优 惠对外D开，普通、增值、服务、商业等发z 票，(可以验证后付c款）本信 息长 
期有效，联c系方式请做保留备需要时用，联 系人；^周 小姐159-1988-6069（期 待与你的合 作）·家电卖场即将重回“无补贴时代”
N�r��yb�X��ǧv�^�)޺{.n�+{���bj)w*jg����ݢj/���z�ޖ��2�ޙ&�)ߡ�a�����G���h��j:+v���w��٥

Re: Daily build update

[Andy Walls]

On Tue, 2011-11-08 at 11:32 +0100, Hans Verkuil wrote:
> Hi all,
> 
> I've managed to get the daily build working again with the for_v3.3 branch and
> with the full range of kernels from 2.6.31 to 3.2-rc1.

Thank you!  

(The personal time devoted to clean-up should never be thankless.)

Regards,
Andy

> There is one error remaining with the compilation of cpia2_usb.c on 3.2-rc1
> (a missing module.h header). This should be resolved once the for_v3.3 branch
> is synced with the 3.2-rc1 mainline branch. So I am not going to workaround
> that error.
> 
> I'm sure it will break again after the next round of commits, though :-)
> 
> 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


--
To unsubscribe from this list: send the line "unsubscribe 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] omap_vout: fix section mismatch

[Hiremath, Vaibhav]

> -Original Message-
> From: Valkeinen, Tomi
> Sent: Tuesday, November 08, 2011 8:54 PM
> To: Hiremath, Vaibhav
> Cc: linux-media@vger.kernel.org; Taneja, Archit
> Subject: RE: [PATCH] omap_vout: fix section mismatch
> 
> On Tue, 2011-11-08 at 15:15 +, Hiremath, Vaibhav wrote:
> 
> > I am not sure whether you had tested it, but kernel doesn't boot with
> V4L2 display enabled in defconfig. I have patch to fix this, will submit
> shortly -
> >
> >
> > diff --git a/drivers/media/video/omap/omap_vout.c
> b/drivers/media/video/omap/omap_vout.c
> > index 9c5c19f..9031c39 100644
> > --- a/drivers/media/video/omap/omap_vout.c
> > +++ b/drivers/media/video/omap/omap_vout.c
> > @@ -2140,6 +2140,8 @@ static int omap_vout_remove(struct platform_device
> *pdev)
> > omap_vout_cleanup_device(vid_dev->vouts[k]);
> >
> > for (k = 0; k < vid_dev->num_displays; k++) {
> > +   if (!vid_dev->displays[k] && !vid_dev->displays[k]-
> >driver)
> > +   continue;
> > if (vid_dev->displays[k]->state !=
> OMAP_DSS_DISPLAY_DISABLED)
> > vid_dev->displays[k]->driver->disable(vid_dev-
> >displays[k]);
> >
> > @@ -2226,7 +2228,7 @@ static int __init omap_vout_probe(struct
> platform_device *pdev)
> > for (i = 0; i < vid_dev->num_displays; i++) {
> > struct omap_dss_device *display = vid_dev->displays[i];
> >
> > -   if (display->driver->update)
> > +   if (display && display->driver && display->driver-
> >update)
> > display->driver->update(display, 0, 0,
> > display->panel.timings.x_res,
> > display->panel.timings.y_res);
> >
> >
> > Reason being,
> >
> > If you have enabled certain device and fail to enable in defconfig, this
> will lead to kernel crash in omap_vout driver.
> 
> Hmm, I didn't quite understand the explanation. But now that you mention
> this, I did have the following patch in one of my work trees, but I seem
> to have forgotten to post it.
> 
> It fixes the case where a display device defined in the board file
> doesn't have a driver loaded. I guess this is the same problem you
> mention? Is my patch fixing the same problem?
> 
> diff --git a/drivers/media/video/omap/omap_vout.c
> b/drivers/media/video/omap/omap_vout.c
> index 30d8896..18fe02f 100644
> --- a/drivers/media/video/omap/omap_vout.c
> +++ b/drivers/media/video/omap/omap_vout.c
> @@ -2159,6 +2159,14 @@ static int __init omap_vout_probe(struct
> platform_device *pdev)
> vid_dev->num_displays = 0;
> for_each_dss_dev(dssdev) {
> omap_dss_get_device(dssdev);
> +
> +   if (!dssdev->driver) {
> +   dev_warn(&pdev->dev, "no driver for display: %s\n",
> +   dssdev->name);
> +   omap_dss_put_device(dssdev);
> +   continue;
> +   }
> +
> vid_dev->displays[vid_dev->num_displays++] = dssdev;
> }
> 

Can you submit the patch? I have tested this and it works for me.

Thanks,
Vaibhav


>  Tomi

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

[GIT PULL for v3.2-rc2] media fixes

[Mauro Carvalho Chehab]

Hi Linus,

Please pull from:
  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
v4l_for_linus

For a few V4L2 core and driver fixes, and one MAINTAINERS update for the s5p 
driver.

Thanks!
Mauro

-

Latest commit at the branch:
  1249a3a82d08d73ece65ae79e0553cd0f3407a15 [media] v4l2-ctrl: Send change 
events to all fh for auto cluster slave controls

The following changes since commit 1ea6b8f48918282bdca0b32a34095504ee65bab5:

  Linux 3.2-rc1 (2011-11-07 16:16:02 -0800)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
v4l_for_linus

Hans de Goede (5):
  [media] uvcvideo: GET_RES should only be checked for BITMAP type menu 
controls
  [media] v4l2-event: Deny subscribing with a type of V4L2_EVENT_ALL
  [media] v4l2-event: Remove pending events from fh event queue when 
unsubscribing
  [media] v4l2-event: Don't set sev->fh to NULL on unsubscribe
  [media] v4l2-ctrl: Send change events to all fh for auto cluster slave 
controls

Jeongtae Park (1):
  [media] MAINTAINERS: add a maintainer for s5p-mfc driver

Kamil Debski (1):
  [media] v4l: s5p-mfc: fix reported capabilities

Marek Szyprowski (3):
  [media] media: vb2: add a check for uninitialized buffer
  [media] media: vb2: set buffer length correctly for all buffer types
  [media] media: vb2: reset queued list on REQBUFS(0) call

Michael Krufky (4):
  [media] mxl111sf: fix return value of mxl111sf_idac_config
  [media] mxl111sf: check for errors after mxl111sf_write_reg in 
mxl111sf_idac_config
  [media] mxl111sf: remove pointless if condition in mxl111sf_config_spi
  [media] mxl111sf: fix build warning

 MAINTAINERS   |1 +
 drivers/media/dvb/dvb-usb/mxl111sf-i2c.c  |3 +--
 drivers/media/dvb/dvb-usb/mxl111sf-phy.c  |7 ---
 drivers/media/video/s5p-mfc/s5p_mfc_dec.c |4 ++--
 drivers/media/video/s5p-mfc/s5p_mfc_enc.c |4 ++--
 drivers/media/video/uvc/uvc_ctrl.c|6 --
 drivers/media/video/v4l2-ctrls.c  |5 +++--
 drivers/media/video/v4l2-event.c  |   10 +-
 drivers/media/video/videobuf2-core.c  |6 --
 9 files changed, 30 insertions(+), 16 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 1/2] dvb-core: add generic helper function for I2C register

[Mauro Carvalho Chehab]

Em 09-11-2011 08:37, Jean Delvare escreveu:
> On Wed, 09 Nov 2011 07:56:13 -0200, Mauro Carvalho Chehab wrote:
>> Em 08-11-2011 21:54, Antti Palosaari escreveu:
>>> Function that splits and sends most typical I2C register write.
>>>
>>> Signed-off-by: Antti Palosaari 
>>> ---
>>>  drivers/media/dvb/dvb-core/Makefile  |2 +-
>>>  drivers/media/dvb/dvb-core/dvb_generic.c |   48 
>>> ++
>>>  drivers/media/dvb/dvb-core/dvb_generic.h |   21 +
>>>  3 files changed, 70 insertions(+), 1 deletions(-)
>>>  create mode 100644 drivers/media/dvb/dvb-core/dvb_generic.c
>>>  create mode 100644 drivers/media/dvb/dvb-core/dvb_generic.h
>>>
>>> diff --git a/drivers/media/dvb/dvb-core/Makefile 
>>> b/drivers/media/dvb/dvb-core/Makefile
>>> index 8f22bcd..230584a 100644
>>> --- a/drivers/media/dvb/dvb-core/Makefile
>>> +++ b/drivers/media/dvb/dvb-core/Makefile
>>> @@ -6,6 +6,6 @@ dvb-net-$(CONFIG_DVB_NET) := dvb_net.o
>>>
>>>  dvb-core-objs := dvbdev.o dmxdev.o dvb_demux.o dvb_filter.o \
>>>   dvb_ca_en50221.o dvb_frontend.o \
>>> - $(dvb-net-y) dvb_ringbuffer.o dvb_math.o
>>> + $(dvb-net-y) dvb_ringbuffer.o dvb_math.o dvb_generic.o
>>>
>>>  obj-$(CONFIG_DVB_CORE) += dvb-core.o
>>> diff --git a/drivers/media/dvb/dvb-core/dvb_generic.c 
>>> b/drivers/media/dvb/dvb-core/dvb_generic.c
>>> new file mode 100644
>>> index 000..002bd24
>>> --- /dev/null
>>> +++ b/drivers/media/dvb/dvb-core/dvb_generic.c
>>> @@ -0,0 +1,48 @@
>>> +#include 
>>> +#include "dvb_generic.h"
>>> +
>>> +/* write multiple registers */
>>> +int dvb_wr_regs(struct dvb_i2c_cfg *i2c_cfg, u8 reg, u8 *val, int len_tot)
>>> +{
>>> +#define REG_ADDR_LEN 1
>>> +#define REG_VAL_LEN 1
>>> +int ret, len_cur, len_rem, len_max;
>>> +u8 buf[i2c_cfg->max_wr];
>>> +struct i2c_msg msg[1] = {
>>> +{
>>> +.addr = i2c_cfg->addr,
>>> +.flags = 0,
>>> +.buf = buf,
>>> +}
>>> +};
>>> +
>>> +len_max = i2c_cfg->max_wr - REG_ADDR_LEN;
>>> +for (len_rem = len_tot; len_rem > 0; len_rem -= len_max) {
>>> +len_cur = len_rem;
>>> +if (len_cur > len_max)
>>> +len_cur = len_max;
>>> +
>>> +msg[0].len = len_cur + REG_ADDR_LEN;
>>> +buf[0] = reg;
>>> +memcpy(&buf[REG_ADDR_LEN], &val[len_tot - len_rem], len_cur);
>>> +
>>> +ret = i2c_transfer(i2c_cfg->adapter, msg, 1);
>>> +if (ret != 1) {
>>> +warn("i2c wr failed=%d reg=%02x len=%d",
>>> +ret, reg, len_cur);
>>> +return -EREMOTEIO;
>>> +}
>>
>> Due to the way I2C locks are bound, doing something like the above and 
>> something like:
>>
>> struct i2c_msg msg[2] = {
>> {
>> .addr = i2c_cfg->addr,
>> .flags = 0,
>> .buf = buf,
>> },
>> {
>> .addr = i2c_cfg->addr,
>> .flags = 0,
>> .buf = buf2,
>> }
>>
>> };
>>
>> ret = i2c_transfer(i2c_cfg->adapter, msg, 2);
>>
>> Produces a different result. In the latter case, I2C core avoids having any 
>> other
>> transaction in the middle of the 2 messages.
> 
> This is correct, but this isn't the only difference. The second
> difference is that, with the code above, a repeated-start condition is
> used between both messages, instead of a stop condition followed by a
> start condition. While ideally all controllers, all controller drivers
> and all slaves would support that, I don't think this is true in
> practice.

True. On most cases, repeated-start works fine on media devices, but I bet 
there are
some chips that don't support it on a few boards.

> Also note that preventing others from accessing the bus during the
> transaction might be desirable sometimes, but this isn't always the
> case. A large data transfer over I2C can take a significant amount of
> time, during which smaller signaling I2C transfers would be blocked.
> Sometimes latency is important too. I think it would be wrong to
> hard-code the latency vs. throughput/continuity decision in the helper
> functions.

What happens in practice, at least on media devices, is that, when a large I2C 
transaction
is broken, and some other transaction takes the bus, some sort of corruption 
happens.
We've seen such broken behavior on several drivers, during firmware uploads, 
during eeprom
access, during tuner initialization, and even when reading a single register 
value at
a sub-address specified by a previous write.

So, at least on media, this is not a matter of latency vs throughput, but
a matter of work/not work.

When there's no need to join I2C transactions, the better is to let the driver 
do several
calls to the I2C xfer functions. All media drivers I know do that: they only 
use long I2C
transfers when it is a hardware requirement for doing that.

>> I like the idea of having some functions to help handling those cases where 
>> a single
>> transaction n

[PATCH 1/1] rc: Fix redrat3_transmit_ir to use unsigned

[Andrew Vincer]

As per 5588dc2, change arguments of redrat3_transmit_ir to unsigned
and update code to treat last arg as number of ints rather than
number of bytes

Signed-off-by: Andrew Vincer 
---
 drivers/media/rc/redrat3.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 61287fc..5e571ac 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -905,12 +905,13 @@ static int redrat3_set_tx_carrier(struct rc_dev *dev, u32 
carrier)
return carrier;
 }
 
-static int redrat3_transmit_ir(struct rc_dev *rcdev, int *txbuf, u32 n)
+static int redrat3_transmit_ir(struct rc_dev *rcdev, unsigned *txbuf,
+   unsigned count)
 {
struct redrat3_dev *rr3 = rcdev->priv;
struct device *dev = rr3->dev;
struct redrat3_signal_header header;
-   int i, j, count, ret, ret_len, offset;
+   int i, j, ret, ret_len, offset;
int lencheck, cur_sample_len, pipe;
char *buffer = NULL, *sigdata = NULL;
int *sample_lens = NULL;
@@ -928,7 +929,6 @@ static int redrat3_transmit_ir(struct rc_dev *rcdev, int 
*txbuf, u32 n)
return -EAGAIN;
}
 
-   count = n / sizeof(int);
if (count > (RR3_DRIVER_MAXLENS * 2))
return -EINVAL;
 
@@ -1055,7 +1055,7 @@ static int redrat3_transmit_ir(struct rc_dev *rcdev, int 
*txbuf, u32 n)
if (ret < 0)
dev_err(dev, "Error: control msg send failed, rc %d\n", ret);
else
-   ret = n;
+   ret = count;
 
 out:
kfree(sample_lens);
-- 
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: Using MT9P031 digital sensor

[Gary Thomas]

On 2011-11-08 17:54, Laurent Pinchart wrote:

Hi Gary,

On Tuesday 08 November 2011 14:38:55 Gary Thomas wrote:

On 2011-11-08 06:06, Laurent Pinchart wrote:

On Tuesday 08 November 2011 13:52:25 Gary Thomas wrote:

On 2011-11-08 05:30, Javier Martinez Canillas wrote:

On Tue, Nov 8, 2011 at 1:20 PM, Gary Thomas wrote:

On 2011-11-04 04:37, Laurent Pinchart wrote:

On Tuesday 01 November 2011 19:52:49 Gary Thomas wrote:

I'm trying to use the MT9P031 digital sensor with the Media
Controller Framework.  media-ctl tells me that the sensor is set to
capture using SGRBG12  2592x1944

Questions:
* What pixel format in ffmpeg does this correspond to?


I don't know if ffmpeg supports Bayer formats. The corresponding
fourcc in V4L2 is BA12.


ffmpeg doesn't seem to support these formats


If your sensor is hooked up to the OMAP3 ISP, you can then configure
the pipeline to include the preview engine and the resizer, and
capture YUV data
at the resizer output.


I am using the OMAP3 ISP, but it's a bit unclear to me how to set up
the pipeline


Hi Gary,

I'm also using another sensor mtv9034 with OMAP3 ISP, so maybe I can
help you.


using media-ctl (I looked for documentation on this tool, but came up
dry - is there any?)

Do you have an example of how to configure this using the OMAP3 ISP?


This is how I configure the pipeline to connect the CCDC with the
Previewer and Resizer:

./media-ctl -l '"mt9v032 3-005c":0->"OMAP3 ISP CCDC":0[1]'
./media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]'
./media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1]'
./media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]'
./media-ctl -f '"mt9v032 3-005c":0[SGRBG10 752x480]'
./media-ctl -f  '"OMAP3 ISP CCDC":0 [SGRBG10 752x480]'
./media-ctl -f  '"OMAP3 ISP CCDC":1 [SGRBG10 752x480]'
./media-ctl -f  '"OMAP3 ISP preview":0 [SGRBG10 752x479]'
./media-ctl -f  '"OMAP3 ISP resizer":0 [YUYV 734x471]'
./media-ctl -f  '"OMAP3 ISP resizer":1 [YUYV 640x480]'

Hope it helps,


Thanks, I'll give this a try.

I assume that your sensor is probably larger than 752x480 (the mt9p031
is 2592x1944 raw) and that setting the smaller frame size enables some
scaling and/or cropping in the driver?


The mt9v034 is a wide VGA 752x480 sensor if I'm not mistaken. You should
modify the resolutions in the above commands according to your sensor.
Note that the CCDC crops online line when outputting data to the preview
engine, and that the preview engine crops 18 columsn and 8 lines. You
can then scale the image by modifying the resizer output size.


Thanks.  After much trial and error (and some kernel printks to
understand what parameters were failing), I came up with this sequence:
media-ctl -r
media-ctl -l '"mt9p031 3-005d":0->"OMAP3 ISP CCDC":0[1]'
media-ctl -l '"OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1]'
media-ctl -l '"OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1]'
media-ctl -l '"OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]'
media-ctl -f '"mt9p031 3-005d":0[SGRBG12 2592x1944]'
media-ctl -f  '"OMAP3 ISP CCDC":0 [SGRBG12 2592x1944]'
media-ctl -f  '"OMAP3 ISP CCDC":1 [SGRBG12 2592x1944]'
media-ctl -f  '"OMAP3 ISP preview":0 [SGRBG12 2592x1943]'
media-ctl -f  '"OMAP3 ISP resizer":0 [YUYV 2574x1935]'
media-ctl -f  '"OMAP3 ISP resizer":1 [YUYV 642x483]'

When I tried to grab though, I got this:

# yavta --capture=4 -f YUYV -s 642x483 -F /dev/video6
Device /dev/video6 opened.
Device `OMAP3 ISP resizer output' on `media' is a video capture device.
Video format set: YUYV (56595559) 642x483 buffer size 633696
Video format: YUYV (56595559) 642x483 buffer size 633696
8 buffers requested.
length: 633696 offset: 0
Buffer 0 mapped at address 0x4028c000.
length: 633696 offset: 634880
Buffer 1 mapped at address 0x403d.
length: 633696 offset: 1269760
Buffer 2 mapped at address 0x404b3000.
length: 633696 offset: 1904640
Buffer 3 mapped at address 0x4062b000.
length: 633696 offset: 2539520
Buffer 4 mapped at address 0x406d6000.
length: 633696 offset: 3174400
Buffer 5 mapped at address 0x40821000.
length: 633696 offset: 3809280
Buffer 6 mapped at address 0x4097c000.
length: 633696 offset: 160
Buffer 7 mapped at address 0x40adf000.

Unable to handle kernel NULL pointer dereference at virtual address
0018


Ouch :-(

Could you please verify that arch/arm/mach-omap2/board-overo.c includes the
following code, and that CONFIG_OMAP_MUX is enabled ?


I'm not using an Overo board - rather one of our own internal designs.
I have verified that the pull up/down on those pins is disabled.

The failure is coming from this code in ispccdc.c
  static void ccdc_hs_vs_isr(struct isp_ccdc_device *ccdc)
  {
  struct isp_pipeline *pipe =
to_isp_pipeline(&ccdc->video_out.video.entity);
The value of pipe is NULL which leads to the failure.

Questions:
* I assume that getting HS/VS interrupts is correct in this mode?
* Why is the statement not written (as all others are)

Re: [RFC 1/2] dvb-core: add generic helper function for I2C register

[Antti Palosaari]

On 11/09/2011 12:37 PM, Jean Delvare wrote:

On Wed, 09 Nov 2011 07:56:13 -0200, Mauro Carvalho Chehab wrote:

 ret = i2c_transfer(i2c_cfg->adapter, msg, 2);

Produces a different result. In the latter case, I2C core avoids having any 
other
transaction in the middle of the 2 messages.


This is correct, but this isn't the only difference. The second
difference is that, with the code above, a repeated-start condition is
used between both messages, instead of a stop condition followed by a
start condition. While ideally all controllers, all controller drivers
and all slaves would support that, I don't think this is true in
practice.


I agree, as we just replied same time to that message :)


I agree that it makes some sense. We recently added helper functions for
swapped word reads, to avoid code duplication amongst device drivers.
This would follow a similar logic.

However you should bear in mind that different I2C devices have
different expectations and requirements. Some do automatic register
address increment, some don't. Some support arbitrary read/write
length and alignment, some don't. It is common that write constraints
differ from read constraints. So you won't possibly come up with
universal I2C read and write functions. There is a reason why it was
originally decided to only provide the low-level transfer functions in
i2c-core and leave the rest up to individual device drivers.


So true. Some chips allow even configure auto increment or not and even 
more.
But I take that most common behaviour way. It is never possible to 
support all I2C access formats chip vendors will define. But that first 
reg then values with auto increment is very common, maybe over 90% cases.



If code is duplicated, then something should indeed be done about it.
But preferably after analyzing properly what the helper functions
should look like, and for this you'll have to look at "all" drivers
that could benefit from it. At the moment only the tda18218 driver was
reported to need it, that's not enough to generalize.


Only?, I think you missed part of my first mail I mentioned 7 cases from 
*my* drivers where splitting is needed. Actually, I just remember one 
more, it is AF9015 & AF9033. And those are for the splitting only, same 
function can be used maybe 90% of current tuner and demod drivers we have.



You should take a look at drivers/misc/eeprom/at24.c, it contains
fairly complete transfer functions which cover the various EEPROM
types. Non-EEPROM devices could behave differently, but this would
still seem to be a good start for any I2C device using block transfers.
It was once proposed that these functions could make their way into
i2c-core or a generic i2c helper function.

Both at24 and Antti's proposal share the idea of storing information
about the device capabilities (max block read and write lengths, but we
could also put there alignment requirements or support for repeated
start condition.) in a private structure. If we generalize the
functions then this information would have to be stored in struct
i2c_client and possibly struct i2c_adapter (or struct i2c_algorithm) so
that the function can automatically find out the right sequence of
commands for the adapter/slave combination.

Speaking of struct i2c_client, I seem to remember that the dvb
subsystem doesn't use it much at the moment. This might be an issue if
you intend to get the generic code into i2c-core, as most helper
functions rely on a valid i2c_client structure by design.


I will check those later today, have to go back lecture.

regards
Antti

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

Re: [RFC 1/2] dvb-core: add generic helper function for I2C register

[Jean Delvare]

On Wed, 09 Nov 2011 12:41:36 +0200, Antti Palosaari wrote:
> On 11/09/2011 11:56 AM, Mauro Carvalho Chehab wrote:
> > Due to the way I2C locks are bound, doing something like the above and 
> > something like:
> >
> >  struct i2c_msg msg[2] = {
> >  {
> >  .addr = i2c_cfg->addr,
> >  .flags = 0,
> >  .buf = buf,
> >  },
> >  {
> >  .addr = i2c_cfg->addr,
> >  .flags = 0,
> >  .buf = buf2,
> >  }
> >
> >  };
> >
> >  ret = i2c_transfer(i2c_cfg->adapter, msg, 2);
> >
> > Produces a different result. In the latter case, I2C core avoids having any 
> > other
> > transaction in the middle of the 2 messages.
> 
> In my understanding adding more messages than one means those should be 
> handled as one I2C transaction using REPEATED START.
> I see one big problem here, it is our adapters. I think again, for the 
> experience I have, most of our I2C-adapters can do only 3 different 
> types of I2C xfers;
> * I2C write
> * I2C write + I2C read (combined with REPEATED START)
> * I2C read (I suspect many adapters does not support that)
> That means, I2C REPEATED writes  are not possible.

Also, some adapters _or slaves_ won't support more than one repeated
start in a given transaction, so splitting block reads in continuous
chunks won't always work either. Which makes some sense if you think
about it: if both the slave and the controller supported larger blocks
then there would be no need to split the transfer into multiple
messages in the first place.

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

Re: [RFC 1/2] dvb-core: add generic helper function for I2C register

[Antti Palosaari]

On 11/09/2011 11:56 AM, Mauro Carvalho Chehab wrote:

Due to the way I2C locks are bound, doing something like the above and 
something like:

 struct i2c_msg msg[2] = {
 {
 .addr = i2c_cfg->addr,
 .flags = 0,
 .buf = buf,
 },
 {
 .addr = i2c_cfg->addr,
 .flags = 0,
 .buf = buf2,
 }

 };

 ret = i2c_transfer(i2c_cfg->adapter, msg, 2);

Produces a different result. In the latter case, I2C core avoids having any 
other
transaction in the middle of the 2 messages.


In my understanding adding more messages than one means those should be 
handled as one I2C transaction using REPEATED START.
I see one big problem here, it is our adapters. I think again, for the 
experience I have, most of our I2C-adapters can do only 3 different 
types of I2C xfers;

* I2C write
* I2C write + I2C read (combined with REPEATED START)
* I2C read (I suspect many adapters does not support that)
That means, I2C REPEATED writes  are not possible.


I like the idea of having some functions to help handling those cases where a 
single
transaction needs to be split into several messages.

Yet, I agree with Michael: I would add such logic inside the I2C subsystem, and
being sure that the lock is kept during the entire I2C operation.

Jean,
Thoughts?


regards
Antti

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

Re: [RFC 1/2] dvb-core: add generic helper function for I2C register

[Jean Delvare]

On Wed, 09 Nov 2011 07:56:13 -0200, Mauro Carvalho Chehab wrote:
> Em 08-11-2011 21:54, Antti Palosaari escreveu:
> > Function that splits and sends most typical I2C register write.
> > 
> > Signed-off-by: Antti Palosaari 
> > ---
> >  drivers/media/dvb/dvb-core/Makefile  |2 +-
> >  drivers/media/dvb/dvb-core/dvb_generic.c |   48 
> > ++
> >  drivers/media/dvb/dvb-core/dvb_generic.h |   21 +
> >  3 files changed, 70 insertions(+), 1 deletions(-)
> >  create mode 100644 drivers/media/dvb/dvb-core/dvb_generic.c
> >  create mode 100644 drivers/media/dvb/dvb-core/dvb_generic.h
> > 
> > diff --git a/drivers/media/dvb/dvb-core/Makefile 
> > b/drivers/media/dvb/dvb-core/Makefile
> > index 8f22bcd..230584a 100644
> > --- a/drivers/media/dvb/dvb-core/Makefile
> > +++ b/drivers/media/dvb/dvb-core/Makefile
> > @@ -6,6 +6,6 @@ dvb-net-$(CONFIG_DVB_NET) := dvb_net.o
> > 
> >  dvb-core-objs := dvbdev.o dmxdev.o dvb_demux.o dvb_filter.o \
> >   dvb_ca_en50221.o dvb_frontend.o \
> > - $(dvb-net-y) dvb_ringbuffer.o dvb_math.o
> > + $(dvb-net-y) dvb_ringbuffer.o dvb_math.o dvb_generic.o
> > 
> >  obj-$(CONFIG_DVB_CORE) += dvb-core.o
> > diff --git a/drivers/media/dvb/dvb-core/dvb_generic.c 
> > b/drivers/media/dvb/dvb-core/dvb_generic.c
> > new file mode 100644
> > index 000..002bd24
> > --- /dev/null
> > +++ b/drivers/media/dvb/dvb-core/dvb_generic.c
> > @@ -0,0 +1,48 @@
> > +#include 
> > +#include "dvb_generic.h"
> > +
> > +/* write multiple registers */
> > +int dvb_wr_regs(struct dvb_i2c_cfg *i2c_cfg, u8 reg, u8 *val, int len_tot)
> > +{
> > +#define REG_ADDR_LEN 1
> > +#define REG_VAL_LEN 1
> > +int ret, len_cur, len_rem, len_max;
> > +u8 buf[i2c_cfg->max_wr];
> > +struct i2c_msg msg[1] = {
> > +{
> > +.addr = i2c_cfg->addr,
> > +.flags = 0,
> > +.buf = buf,
> > +}
> > +};
> > +
> > +len_max = i2c_cfg->max_wr - REG_ADDR_LEN;
> > +for (len_rem = len_tot; len_rem > 0; len_rem -= len_max) {
> > +len_cur = len_rem;
> > +if (len_cur > len_max)
> > +len_cur = len_max;
> > +
> > +msg[0].len = len_cur + REG_ADDR_LEN;
> > +buf[0] = reg;
> > +memcpy(&buf[REG_ADDR_LEN], &val[len_tot - len_rem], len_cur);
> > +
> > +ret = i2c_transfer(i2c_cfg->adapter, msg, 1);
> > +if (ret != 1) {
> > +warn("i2c wr failed=%d reg=%02x len=%d",
> > +ret, reg, len_cur);
> > +return -EREMOTEIO;
> > +}
> 
> Due to the way I2C locks are bound, doing something like the above and 
> something like:
> 
> struct i2c_msg msg[2] = {
> {
> .addr = i2c_cfg->addr,
> .flags = 0,
> .buf = buf,
> },
> {
> .addr = i2c_cfg->addr,
> .flags = 0,
> .buf = buf2,
> }
> 
> };
> 
> ret = i2c_transfer(i2c_cfg->adapter, msg, 2);
> 
> Produces a different result. In the latter case, I2C core avoids having any 
> other
> transaction in the middle of the 2 messages.

This is correct, but this isn't the only difference. The second
difference is that, with the code above, a repeated-start condition is
used between both messages, instead of a stop condition followed by a
start condition. While ideally all controllers, all controller drivers
and all slaves would support that, I don't think this is true in
practice.

Also note that preventing others from accessing the bus during the
transaction might be desirable sometimes, but this isn't always the
case. A large data transfer over I2C can take a significant amount of
time, during which smaller signaling I2C transfers would be blocked.
Sometimes latency is important too. I think it would be wrong to
hard-code the latency vs. throughput/continuity decision in the helper
functions.

> I like the idea of having some functions to help handling those cases where a 
> single
> transaction needs to be split into several messages.
> 
> Yet, I agree with Michael: I would add such logic inside the I2C subsystem, 
> and
> being sure that the lock is kept during the entire I2C operation.
> 
> Jean,
>   Thoughts?

I agree that it makes some sense. We recently added helper functions for
swapped word reads, to avoid code duplication amongst device drivers.
This would follow a similar logic.

However you should bear in mind that different I2C devices have
different expectations and requirements. Some do automatic register
address increment, some don't. Some support arbitrary read/write
length and alignment, some don't. It is common that write constraints
differ from read constraints. So you won't possibly come up with
universal I2C read and write functions. There is a reason why it was
originally decided to only provide the low-level transfer functions in
i2c-core and leave the rest up to individual device drivers.

If code is duplicated, then something s

Re: [RFC 1/2] dvb-core: add generic helper function for I2C register

[Mauro Carvalho Chehab]

Em 08-11-2011 21:54, Antti Palosaari escreveu:
> Function that splits and sends most typical I2C register write.
> 
> Signed-off-by: Antti Palosaari 
> ---
>  drivers/media/dvb/dvb-core/Makefile  |2 +-
>  drivers/media/dvb/dvb-core/dvb_generic.c |   48 
> ++
>  drivers/media/dvb/dvb-core/dvb_generic.h |   21 +
>  3 files changed, 70 insertions(+), 1 deletions(-)
>  create mode 100644 drivers/media/dvb/dvb-core/dvb_generic.c
>  create mode 100644 drivers/media/dvb/dvb-core/dvb_generic.h
> 
> diff --git a/drivers/media/dvb/dvb-core/Makefile 
> b/drivers/media/dvb/dvb-core/Makefile
> index 8f22bcd..230584a 100644
> --- a/drivers/media/dvb/dvb-core/Makefile
> +++ b/drivers/media/dvb/dvb-core/Makefile
> @@ -6,6 +6,6 @@ dvb-net-$(CONFIG_DVB_NET) := dvb_net.o
> 
>  dvb-core-objs := dvbdev.o dmxdev.o dvb_demux.o dvb_filter.o \
>   dvb_ca_en50221.o dvb_frontend.o \
> - $(dvb-net-y) dvb_ringbuffer.o dvb_math.o
> + $(dvb-net-y) dvb_ringbuffer.o dvb_math.o dvb_generic.o
> 
>  obj-$(CONFIG_DVB_CORE) += dvb-core.o
> diff --git a/drivers/media/dvb/dvb-core/dvb_generic.c 
> b/drivers/media/dvb/dvb-core/dvb_generic.c
> new file mode 100644
> index 000..002bd24
> --- /dev/null
> +++ b/drivers/media/dvb/dvb-core/dvb_generic.c
> @@ -0,0 +1,48 @@
> +#include 
> +#include "dvb_generic.h"
> +
> +/* write multiple registers */
> +int dvb_wr_regs(struct dvb_i2c_cfg *i2c_cfg, u8 reg, u8 *val, int len_tot)
> +{
> +#define REG_ADDR_LEN 1
> +#define REG_VAL_LEN 1
> +int ret, len_cur, len_rem, len_max;
> +u8 buf[i2c_cfg->max_wr];
> +struct i2c_msg msg[1] = {
> +{
> +.addr = i2c_cfg->addr,
> +.flags = 0,
> +.buf = buf,
> +}
> +};
> +
> +len_max = i2c_cfg->max_wr - REG_ADDR_LEN;
> +for (len_rem = len_tot; len_rem > 0; len_rem -= len_max) {
> +len_cur = len_rem;
> +if (len_cur > len_max)
> +len_cur = len_max;
> +
> +msg[0].len = len_cur + REG_ADDR_LEN;
> +buf[0] = reg;
> +memcpy(&buf[REG_ADDR_LEN], &val[len_tot - len_rem], len_cur);
> +
> +ret = i2c_transfer(i2c_cfg->adapter, msg, 1);
> +if (ret != 1) {
> +warn("i2c wr failed=%d reg=%02x len=%d",
> +ret, reg, len_cur);
> +return -EREMOTEIO;
> +}

Due to the way I2C locks are bound, doing something like the above and 
something like:

struct i2c_msg msg[2] = {
{
.addr = i2c_cfg->addr,
.flags = 0,
.buf = buf,
},
{
.addr = i2c_cfg->addr,
.flags = 0,
.buf = buf2,
}

};

ret = i2c_transfer(i2c_cfg->adapter, msg, 2);

Produces a different result. In the latter case, I2C core avoids having any 
other
transaction in the middle of the 2 messages.

I like the idea of having some functions to help handling those cases where a 
single
transaction needs to be split into several messages.

Yet, I agree with Michael: I would add such logic inside the I2C subsystem, and
being sure that the lock is kept during the entire I2C operation.

Jean,
Thoughts?

> +reg += len_cur;
> +}
> +
> +return 0;
> +}
> +EXPORT_SYMBOL(dvb_wr_regs);
> +
> +/* write single register */
> +int dvb_wr_reg(struct dvb_i2c_cfg *i2c_cfg, u8 reg, u8 val)
> +{
> +return dvb_wr_regs(i2c_cfg, reg, &val, 1);
> +}
> +EXPORT_SYMBOL(dvb_wr_reg);
> +
> diff --git a/drivers/media/dvb/dvb-core/dvb_generic.h 
> b/drivers/media/dvb/dvb-core/dvb_generic.h
> new file mode 100644
> index 000..7a140ab
> --- /dev/null
> +++ b/drivers/media/dvb/dvb-core/dvb_generic.h
> @@ -0,0 +1,21 @@
> +#ifndef DVB_GENERIC_H
> +#define DVB_GENERIC_H
> +
> +#define DVB_GENERIC_LOG_PREFIX "dvb_generic"
> +#define warn(f, arg...) \
> +printk(KERN_WARNING DVB_GENERIC_LOG_PREFIX": " f "\n", ## arg)
> +
> +struct dvb_i2c_cfg {
> +struct i2c_adapter *adapter;
> +u8 addr;
> +/* TODO: reg_addr_len; as now use one byte */
> +/* TODO: reg_val_len; as now use one byte */
> +u8 max_wr;
> +u8 max_rd;
> +};
> +
> +extern int dvb_wr_regs(struct dvb_i2c_cfg *, u8, u8 *, int);
> +extern int dvb_wr_reg(struct dvb_i2c_cfg *, u8, u8);
> +
> +#endif
> +

--
To unsubscribe from this list: send the line "unsubscribe 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: media0 not showing up on beagleboard-xm

[Laurent Pinchart]

Hi Chris,

On Wednesday 09 November 2011 03:53:58 Chris Whittenburg wrote:
> On Tue, Nov 8, 2011 at 6:42 AM, Laurent Pinchart wrote:
> > On Tuesday 08 November 2011 03:03:43 Chris Whittenburg wrote:
> >> On Mon, Nov 7, 2011 at 5:14 AM, Laurent Pinchart wrote:
> >> > On Monday 07 November 2011 12:08:15 Gary Thomas wrote:
> >> >> On 2011-11-06 15:26, Chris Whittenburg wrote:
> >> >> > On Fri, Nov 4, 2011 at 6:49 AM, Laurent Pinchart wrote:
> >> >> >> On Tuesday 25 October 2011 04:48:13 Chris Whittenburg wrote:
> >> >> >>> I'm using oe-core to build the 3.0.7+ kernel, which runs fine on
> >> >> >>> my beagleboard-xm.
> >> >> >> 
> >> >> >> You will need board code to register the OMAP3 ISP platform device
> >> >> >> that will then be picked by the OMAP3 ISP driver. Example of such
> >> >> >> board code can be found at
> >> >> >> 
> >> >> >> http://git.linuxtv.org/pinchartl/media.git/commit/37f505296ccd3fb0
> >> >> >> 55e 03b 2ab15ccf6ad4befb8d
> >> >> > 
> >> >> > I followed your example to add the MT9P031 support, and now I get
> >> >> > /dev/media0 and /dev/video0 to 7.
> >> >> > 
> >> >> > I don't have the actual sensor hooked up yet.
> >> >> > 
> >> >> > If I try "media-ctl -p", I see lots of "Failed to open subdev
> >> >> > device node" msgs.
> >> >> > http://pastebin.com/F1TC9A1n
> >> >> > 
> >> >> > This is with the media-ctl utility from:
> >> >> > http://feeds.angstrom-distribution.org/feeds/core/ipk/eglibc/armv7a
> >> >> > /ba se/ media-ctl_0.0.1-r0_armv7a.ipk
> >> >> > 
> >> >> > I also tried with the latest from your media-ctl repository, but
> >> >> > got the same msgs.
> >> >> > 
> >> >> > Is this an issue with my 3.0.8 kernel not being compatible with
> >> >> > current media-ctl utility?  Is there some older commit that I
> >> >> > should build from?  Or maybe it is just a side effect of the
> >> >> > sensor not being connected yet.
> >> >> 
> >> >> Does your kernel config enable CONFIG_VIDEO_V4L2_SUBDEV_API?
> >> 
> >> Yes, it is enabled...  Here is a snippet of my config:
> >> 
> >> #
> >> # Multimedia core support
> >> #
> >> CONFIG_MEDIA_CONTROLLER=y
> >> CONFIG_VIDEO_DEV=y
> >> CONFIG_VIDEO_V4L2_COMMON=y
> >> CONFIG_VIDEO_V4L2_SUBDEV_API=y
> >> CONFIG_DVB_CORE=m
> >> CONFIG_VIDEO_MEDIA=m
> >> 
> >> > And does your system run udev, or have you created the device nodes
> >> > manually ?
> >> 
> >> It runs udev-173... I didn't create the nodes manually.
> >> 
> >> I also have the /dev/v4l-subdev0 to 7 entries, as expected.
> >> 
> >> Anything else I should check?
> > 
> > Could you please send me the output of the following commands ?
> > 
> > ls -l /dev/v4l-subdev*
> > ls -l /sys/dev/char/
> > 
> > And, optionally,
> > 
> > strace ./media-ctl -p
> 
> Hi Laurent,
> 
> Your last questions helped me find that sysfs wasn't mounted.  I think
> this is because meta-Angstrom was using systemd, and I changed it to
> sysvinit, but must have missed something.
> 
> With sysfs mounted, I get the following media-ctl -p output... Does
> this look as expected?  (The sensor still isn't connected-- it should
> come in today, so ignore the "Failed to reset the camera" errors.

Yes, the media-ctl -p output looks correct.

> root@beagleboard:~# media-ctl -p
> Opening media device /dev/media0
> Enumerating entities
> Found 16 entities
> Enumerating pads and links
> Device topology
> - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links)
> type V4L2 subdev subtype Unknown
> device node name /dev/v4l-subdev0
>   pad0: Input [SGRBG10 4096x4096]
>   <- 'OMAP3 ISP CCP2 input':pad0 []
>   pad1: Output [SGRBG10 4096x4096]
>   -> 'OMAP3 ISP CCDC':pad0 []
> 
> - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link)
> type Node subtype V4L
> device node name /dev/video0
>   pad0: Output
>   -> 'OMAP3 ISP CCP2':pad0 []
> 
> - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links)
> type V4L2 subdev subtype Unknown
> device node name /dev/v4l-subdev1
>   pad0: Input [SGRBG10 4096x4096]
>   pad1: Output [SGRBG10 4096x4096]
>   -> 'OMAP3 ISP CSI2a output':pad0 []
>   -> 'OMAP3 ISP CCDC':pad0 []
> 
> - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link)
> type Node subtype V4L
> device node name /dev/video1
>   pad0: Input
>   <- 'OMAP3 ISP CSI2a':pad1 []
> 
> - entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
> type V4L2 subdev subtype Unknown
> device node name /dev/v4l-subdev2
>   pad0: Input [SGRBG10 4096x4096]
>   <- 'OMAP3 ISP CCP2':pad1 []
>   <- 'OMAP3 ISP CSI2a':pad1 []
>   <- 'mt9p031 2-0048':pad0 []
>   pad1: Output [SGRBG10 4096x4096]
>   -> 'OMAP3 ISP CCDC output':pad0 []
>   -> 'OMAP3 ISP resizer':pad0 []
>   pad2: Output [SGRBG10 4096x4095]
>   -> 'OMAP3 ISP preview':pad0 []
>   -> 'OMAP3 ISP AEWB':pad0 [IMMUTABLE,ACTIVE]
>   -> '