Re: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan-22fix

2010-01-14 Thread Abylai Ospan
Hello Oliver,

 There is no reason why we have to use the set_tone routine of the
 stv0900. You can combine
 - set_tone of LNBH24 with
 - stv090x_send_diseqc_msg of stv0900
 without losing anything.
 Before a DiSEqC message will be sent, the tone will be disabled.
 Then the stv090x_send_diseqc_msg of the stv0900 can control the 22kHz
 tone generator of the LNBH24 using EXTM or DSQIN.
yes, you right.

  I think lnbp21_set_tone will be used if set_tone is not defined
  previously (set_tone == NULL). Is this correct ?
 No, sorry. set_tone had to be added, because the stv0900 can also
 operate in DiSEqC envelope mode (connected to DSQIN of the LNBH24).
 In this mode set_tone of the LNBH24 has to be used.
ok, you right.
But seems like fe-ops.set_tone = lnbp21_set_tone; override .set_tone
= stv090x_set_tone, and stv090x_set_tone never used. Is this right ?

Also please check our logic. We set override_clear=LNBH24_TEN in
cx23885-dvb.c i.e. we disabling 22kHz logic in LNBH24 and all 22kHz
logic driven from one place ( stv0900 ). This more clear for debugging
(hardware and software ).
This problem is reported by one of our customer. Your changeset
13673:75331e740f61 is broke 22khz tone functionality on our cards.

We need to find compromise. Reverting the patch is not a problem ( in
this case we need to remove override_clear=LNBH24_TEN).

-- 
Abylai Ospan aos...@netup.ru
NetUP Inc.

--
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: About driver architecture

2010-01-14 Thread Hans Verkuil
Hi Michael,

 Hi guys,
   I'm going to write drivers for a new soc which designed for dvb-s set
 top box.
 It will support these features:
 1. Multi-layer display with alpha blending feature, including
 video(YUV), OSDs(2 same RGB layers), background(with fixed YUV color)
 and still picture(YUV color for still image)
 2. DVB-S tuner and demod
 3. HW MPEG2/4 decoder
 4. HW accelerated JPEG decoder engine.

Interesting device. Which SoC is this?


 My targets are:
 1. Fit all the drivers in proper framework so they can be easily used
 by applications in open source community.
 2. As flexible as I can to add new software features in the future.

 My questions are:
 How many drivers should I implement, and how should I divide all the
 features?
 As far as I know:
 A) a frame buffer driver for 2 OSDs, maybe also the control point for
 whole display module?
 B) video output device for video layer, which will output video program.
 C) drivers for tuner and demo (or just a driver which will export 2
 devices files for each?)
 D) driver for jpeg accelerate interface, or should it be a part of
 MPEG2/4 decoder driver?
 E) driver for MPEG2/4 decoder which will control the behave of H/W
 decoder.

 Actually I think all the display functions are relative, some
 functions i listed upper are operating one HW module, for instance:
 OSD and video layer are implemented by display module in H/W level.
 What's the right way to implement these functions in driver level,
 united or separated?
 And, I've read some documents for V4L2, but I still cannot figure out
 where should I implement my driver in the framework.

 In a word, I'm totally confused. Can you guys show me the right way or
 just kick me to a existing example with similar features?

The driver that comes closest to this in terms of functionality is the
ivtv driver. That driver supports MPEG2 encoding and decoding, an OSD and
raw YUV input and output.

There are several ways you can design devices like this, but the way ivtv
is designed is that there is one master driver (ivtv) that handles all the
encoding and decoding, and the framebuffer driver that you need for the
OSD is just an 'add-on' module that provides the FB API but internally
talks to the master driver.

The tuner/demod part is usually integrated in the master driver. See the
cx18 driver for example. But it is probably also possible to implement it
as a separate driver in a similar manner as a framebuffer driver.

Generally the key criteria on how to design drivers like this is the
hardware design: for example, if the tuner/demod part is completely
independent from the decoder part, then it is possible to write completely
independent drivers as well, but if they share hardware components (e.g.
the interrupt handling hardware), then you usually have to combine
functions in one driver.

Note that some features that you probably need (such as memory-to-memory
decoding) are not yet implemented in V4L2 (although work is in progress on
this).

Regards,

Hans



 Best regards
 Michael Qiu
 --
 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



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
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: About driver architecture

2010-01-14 Thread Manu Abraham
Hi,


On Thu, Jan 14, 2010 at 11:35 AM, Michael Qiu fallw...@gmail.com wrote:
 Hi guys,
  I'm going to write drivers for a new soc which designed for dvb-s set top 
 box.
 It will support these features:
 1. Multi-layer display with alpha blending feature, including
 video(YUV), OSDs(2 same RGB layers), background(with fixed YUV color)
 and still picture(YUV color for still image)
 2. DVB-S tuner and demod
 3. HW MPEG2/4 decoder
 4. HW accelerated JPEG decoder engine.

 My targets are:
 1. Fit all the drivers in proper framework so they can be easily used
 by applications in open source community.
 2. As flexible as I can to add new software features in the future.

 My questions are:
 How many drivers should I implement, and how should I divide all the features?
 As far as I know:
 A) a frame buffer driver for 2 OSDs, maybe also the control point for
 whole display module?
 B) video output device for video layer, which will output video program.
 C) drivers for tuner and demo (or just a driver which will export 2
 devices files for each?)
 D) driver for jpeg accelerate interface, or should it be a part of
 MPEG2/4 decoder driver?
 E) driver for MPEG2/4 decoder which will control the behave of H/W decoder.

 Actually I think all the display functions are relative, some
 functions i listed upper are operating one HW module, for instance:
 OSD and video layer are implemented by display module in H/W level.
 What's the right way to implement these functions in driver level,
 united or separated?
 And, I've read some documents for V4L2, but I still cannot figure out
 where should I implement my driver in the framework.

 In a word, I'm totally confused. Can you guys show me the right way or
 just kick me to a existing example with similar features?


Currently, there are 2 drivers which have exactly the functionality
that you have mentioned. The first one is an AV7110 based device and
the other one is a STi7109 SOC based device.

With regards to the AV7110 based hardware, you can have a look at
linux/drivers/media/dvb/ttpci/ *

And with regards to the STi7109 SOC based, you can have a look at
http://jusst.de/hg/saa716x/
linux/drivers/media/common/saa716x/ *
specifically you will need to look at saa716x_ff.c/h for the STi7109
related stuff


Both the AV7110 and STi7109 SOC feature a OSD interface, in addition
to the audio and video layers. which you can see from the drivers,
themselves. Additionally the STi7109 SOC features HDMI outputs. The
AV7110 based cards, they incorporate DVB-S/C/T frontends for different
products. The STi7109 product that we have currently features only a
DVB-S/S2 system only, though that doesn't make any difference at all.

The only application that does handle the complete use of the decoder,
is VDR and some other command line applications in the dvb-apps tree,
that I am aware of. But there could be other applications as well.

I guess, you've been confused, since you have been looking in the
wrong place, ie in V4L, rather than with DVB.

Regards,
Manu
--
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: About driver architecture

2010-01-14 Thread Hans Verkuil

 Hi,


 On Thu, Jan 14, 2010 at 11:35 AM, Michael Qiu fallw...@gmail.com wrote:
 Hi guys,
  I'm going to write drivers for a new soc which designed for dvb-s set
 top box.
 It will support these features:
 1. Multi-layer display with alpha blending feature, including
 video(YUV), OSDs(2 same RGB layers), background(with fixed YUV color)
 and still picture(YUV color for still image)
 2. DVB-S tuner and demod
 3. HW MPEG2/4 decoder
 4. HW accelerated JPEG decoder engine.

 My targets are:
 1. Fit all the drivers in proper framework so they can be easily used
 by applications in open source community.
 2. As flexible as I can to add new software features in the future.

 My questions are:
 How many drivers should I implement, and how should I divide all the
 features?
 As far as I know:
 A) a frame buffer driver for 2 OSDs, maybe also the control point for
 whole display module?
 B) video output device for video layer, which will output video program.
 C) drivers for tuner and demo (or just a driver which will export 2
 devices files for each?)
 D) driver for jpeg accelerate interface, or should it be a part of
 MPEG2/4 decoder driver?
 E) driver for MPEG2/4 decoder which will control the behave of H/W
 decoder.

 Actually I think all the display functions are relative, some
 functions i listed upper are operating one HW module, for instance:
 OSD and video layer are implemented by display module in H/W level.
 What's the right way to implement these functions in driver level,
 united or separated?
 And, I've read some documents for V4L2, but I still cannot figure out
 where should I implement my driver in the framework.

 In a word, I'm totally confused. Can you guys show me the right way or
 just kick me to a existing example with similar features?


 Currently, there are 2 drivers which have exactly the functionality
 that you have mentioned. The first one is an AV7110 based device and
 the other one is a STi7109 SOC based device.

 With regards to the AV7110 based hardware, you can have a look at
 linux/drivers/media/dvb/ttpci/ *

 And with regards to the STi7109 SOC based, you can have a look at
 http://jusst.de/hg/saa716x/
 linux/drivers/media/common/saa716x/ *
 specifically you will need to look at saa716x_ff.c/h for the STi7109
 related stuff


 Both the AV7110 and STi7109 SOC feature a OSD interface, in addition
 to the audio and video layers. which you can see from the drivers,
 themselves. Additionally the STi7109 SOC features HDMI outputs. The
 AV7110 based cards, they incorporate DVB-S/C/T frontends for different
 products. The STi7109 product that we have currently features only a
 DVB-S/S2 system only, though that doesn't make any difference at all.

The AV7110 OSD is not framebuffer based AFAIK. So probably not a good
place to look.

The saa716x driver doesn't have a framebuffer either. Manu, is this driver
just passing the captured video to the OSD? Or does it use some custom OSD
commands? Just curious.

Regards,

Hans


 The only application that does handle the complete use of the decoder,
 is VDR and some other command line applications in the dvb-apps tree,
 that I am aware of. But there could be other applications as well.

 I guess, you've been confused, since you have been looking in the
 wrong place, ie in V4L, rather than with DVB.

 Regards,
 Manu
 --
 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



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
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: About driver architecture

2010-01-14 Thread Michael Qiu
Thanks for you reply.

The SOC is still under development stage, it's not a product yet. And
a small mistake I've made, the tuner will not integrated into the SOC.
The demod might be.

Some more questions:
As far as I know, relationship between demod and decoder is the buffer
used as demod output(also the input for a/v decoder), and maybe a
shared interrupt used to catch some misc event from tuner/demo/av
decoder(a interrupt status register will be used to determine who
cause it). Do you think this will be a problem if I write individual
drivers?

And would you please tell me that is the memory-to-memory decoding for?

Best regards
Michael Qiu

2010/1/14 Hans Verkuil hverk...@xs4all.nl:
 Hi Michael,

 Hi guys,
   I'm going to write drivers for a new soc which designed for dvb-s set
 top box.
 It will support these features:
 1. Multi-layer display with alpha blending feature, including
 video(YUV), OSDs(2 same RGB layers), background(with fixed YUV color)
 and still picture(YUV color for still image)
 2. DVB-S tuner and demod
 3. HW MPEG2/4 decoder
 4. HW accelerated JPEG decoder engine.

 Interesting device. Which SoC is this?


 My targets are:
 1. Fit all the drivers in proper framework so they can be easily used
 by applications in open source community.
 2. As flexible as I can to add new software features in the future.

 My questions are:
 How many drivers should I implement, and how should I divide all the
 features?
 As far as I know:
 A) a frame buffer driver for 2 OSDs, maybe also the control point for
 whole display module?
 B) video output device for video layer, which will output video program.
 C) drivers for tuner and demo (or just a driver which will export 2
 devices files for each?)
 D) driver for jpeg accelerate interface, or should it be a part of
 MPEG2/4 decoder driver?
 E) driver for MPEG2/4 decoder which will control the behave of H/W
 decoder.

 Actually I think all the display functions are relative, some
 functions i listed upper are operating one HW module, for instance:
 OSD and video layer are implemented by display module in H/W level.
 What's the right way to implement these functions in driver level,
 united or separated?
 And, I've read some documents for V4L2, but I still cannot figure out
 where should I implement my driver in the framework.

 In a word, I'm totally confused. Can you guys show me the right way or
 just kick me to a existing example with similar features?

 The driver that comes closest to this in terms of functionality is the
 ivtv driver. That driver supports MPEG2 encoding and decoding, an OSD and
 raw YUV input and output.

 There are several ways you can design devices like this, but the way ivtv
 is designed is that there is one master driver (ivtv) that handles all the
 encoding and decoding, and the framebuffer driver that you need for the
 OSD is just an 'add-on' module that provides the FB API but internally
 talks to the master driver.

 The tuner/demod part is usually integrated in the master driver. See the
 cx18 driver for example. But it is probably also possible to implement it
 as a separate driver in a similar manner as a framebuffer driver.

 Generally the key criteria on how to design drivers like this is the
 hardware design: for example, if the tuner/demod part is completely
 independent from the decoder part, then it is possible to write completely
 independent drivers as well, but if they share hardware components (e.g.
 the interrupt handling hardware), then you usually have to combine
 functions in one driver.

 Note that some features that you probably need (such as memory-to-memory
 decoding) are not yet implemented in V4L2 (although work is in progress on
 this).

 Regards,

        Hans



 Best regards
 Michael Qiu
 --
 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



 --
 Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom


--
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: About driver architecture

2010-01-14 Thread Manu Abraham
On Thu, Jan 14, 2010 at 1:47 PM, Michael Qiu fallw...@gmail.com wrote:
 Thanks for you reply.

 The SOC is still under development stage, it's not a product yet. And
 a small mistake I've made, the tuner will not integrated into the SOC.
 The demod might be.


You mean a similar scheme as in the STi7111.
http://www.st.com/stonline/products/literature/bd/14287.pdf

It is a standard approach used in DVB STB's. Recently the decoders are
being builtin with the DVB demodulators to have more control as well
as to reduce the complexity of the hardware and software and
eventually the cost.

Regards,
Manu
--
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: About driver architecture

2010-01-14 Thread HoP
Hi Manu,

2010/1/14 Manu Abraham abraham.m...@gmail.com:
 Well, the SAA716x is only the PCI Express interface. There is no video
 capture involved in there with the STi7109. It is a full fledged DVB
 STB SOC.

 OSD is handled by the STi7109 on that STB.
 http://www.st.com/stonline/products/literature/bd/11660/sti7109.pdf

 Though it is not complete, that driver, it still does handle it,
 through the firmware interface. These are the kind of devices that you
 find on a DVB STB, i must say.

 On a DVB STB, what happens is that you load a vendor specific firmware
 on the SOC. The SOC is just issued the firmware commands, that's how a
 STB works in principle. A DVB STB can be considered to have 2 outputs,
 ie if you use it as a PC card, you can output the whole thing to your
 PC monitor, or output it to a TV set. But in the case of the STB, you
 have a TV output alone.


I never know about use of stb7109 in any PCI card. It is surprise
to me. Interesting what firmware is loaded to stb7109. Is it STM's
proprietary os21 or even linux?

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


Re: About driver architecture

2010-01-14 Thread Manu Abraham
On Thu, Jan 14, 2010 at 2:06 PM, HoP jpetr...@gmail.com wrote:
 Hi Manu,

 2010/1/14 Manu Abraham abraham.m...@gmail.com:
 Well, the SAA716x is only the PCI Express interface. There is no video
 capture involved in there with the STi7109. It is a full fledged DVB
 STB SOC.

 OSD is handled by the STi7109 on that STB.
 http://www.st.com/stonline/products/literature/bd/11660/sti7109.pdf

 Though it is not complete, that driver, it still does handle it,
 through the firmware interface. These are the kind of devices that you
 find on a DVB STB, i must say.

 On a DVB STB, what happens is that you load a vendor specific firmware
 on the SOC. The SOC is just issued the firmware commands, that's how a
 STB works in principle. A DVB STB can be considered to have 2 outputs,
 ie if you use it as a PC card, you can output the whole thing to your
 PC monitor, or output it to a TV set. But in the case of the STB, you
 have a TV output alone.


 I never know about use of stb7109 in any PCI card. It is surprise
 to me. Interesting what firmware is loaded to stb7109. Is it STM's
 proprietary os21 or even linux?


I don't know what is loaded exactly, right now. It is something
proprietary from Technotrend.

I guess it could be OS21 at the moment, couldn't be WinCE. Although
this could change any time, as we can load Linux also on it some time
in the future ;-)

The card is a Technotrend TT S2-6400 Premium Full Fledged card, with a
STi7109, STV0900 Dual DVB-S2 demodulator, HDMI outputs, SPDIF etc. The
STi7109 SOC being so large and with so many features, it's a shame to
call it a card, maybe it should be called a STB or a PC.  A neat and
well built device though, even though the hardware is very much in
it's initial stages.

Regards,
Manu
--
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: About driver architecture

2010-01-14 Thread Hans Verkuil

 Hi Hans,

 On Thu, Jan 14, 2010 at 1:25 PM, Hans Verkuil hverk...@xs4all.nl wrote:

 Hi,


 On Thu, Jan 14, 2010 at 11:35 AM, Michael Qiu fallw...@gmail.com
 wrote:
 Hi guys,
  I'm going to write drivers for a new soc which designed for dvb-s set
 top box.
 It will support these features:
 1. Multi-layer display with alpha blending feature, including
 video(YUV), OSDs(2 same RGB layers), background(with fixed YUV color)
 and still picture(YUV color for still image)
 2. DVB-S tuner and demod
 3. HW MPEG2/4 decoder
 4. HW accelerated JPEG decoder engine.

 My targets are:
 1. Fit all the drivers in proper framework so they can be easily used
 by applications in open source community.
 2. As flexible as I can to add new software features in the future.

 My questions are:
 How many drivers should I implement, and how should I divide all the
 features?
 As far as I know:
 A) a frame buffer driver for 2 OSDs, maybe also the control point for
 whole display module?
 B) video output device for video layer, which will output video
 program.
 C) drivers for tuner and demo (or just a driver which will export 2
 devices files for each?)
 D) driver for jpeg accelerate interface, or should it be a part of
 MPEG2/4 decoder driver?
 E) driver for MPEG2/4 decoder which will control the behave of H/W
 decoder.

 Actually I think all the display functions are relative, some
 functions i listed upper are operating one HW module, for instance:
 OSD and video layer are implemented by display module in H/W level.
 What's the right way to implement these functions in driver level,
 united or separated?
 And, I've read some documents for V4L2, but I still cannot figure out
 where should I implement my driver in the framework.

 In a word, I'm totally confused. Can you guys show me the right way or
 just kick me to a existing example with similar features?


 Currently, there are 2 drivers which have exactly the functionality
 that you have mentioned. The first one is an AV7110 based device and
 the other one is a STi7109 SOC based device.

 With regards to the AV7110 based hardware, you can have a look at
 linux/drivers/media/dvb/ttpci/ *

 And with regards to the STi7109 SOC based, you can have a look at
 http://jusst.de/hg/saa716x/
 linux/drivers/media/common/saa716x/ *
 specifically you will need to look at saa716x_ff.c/h for the STi7109
 related stuff


 Both the AV7110 and STi7109 SOC feature a OSD interface, in addition
 to the audio and video layers. which you can see from the drivers,
 themselves. Additionally the STi7109 SOC features HDMI outputs. The
 AV7110 based cards, they incorporate DVB-S/C/T frontends for different
 products. The STi7109 product that we have currently features only a
 DVB-S/S2 system only, though that doesn't make any difference at all.

 The AV7110 OSD is not framebuffer based AFAIK. So probably not a good
 place to look.


 It doesn't support OSD ?

I didn't say that. Of course it supports an OSD. Just not through a
traditional /dev/fbX device which allows you to put Qt or whatever on top
of it. Instead it requires custom commands to use it. I'm assuming that
the SoC Michael is talking about is framebuffer based in which case ivtv
is the closest match.

Regards,

   Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
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: About driver architecture

2010-01-14 Thread Michael Qiu
Thanks a lot for you advise.

Before I read the source code you mentioned, I guess I should write a
driver modules which provide /dev/dvb/adapter/audio, video, frontend,
ca,  and also provide a /dev/fbx for OSD layer. But in source
level, all display HW relative functions would probably in a same
module, because they are operation on same block of H/W.
But I still don't know where to put my global display control
interface, for instance, the function to control which layer open and
close, the alpha values used for each layer...

And I investigated DirectFB, it seems if I provide a /dev/fb0 device
the DirectFB can play around it and it will the base for upper GUI
system.
I also found DirectFB support V4L as it's surface source. So it will
need some kernel module to control layer blending. It seems the thing
I am looking for which implement the global display control.



2010/1/14 Manu Abraham abraham.m...@gmail.com:
 Hi,


 On Thu, Jan 14, 2010 at 11:35 AM, Michael Qiu fallw...@gmail.com wrote:
 Hi guys,
  I'm going to write drivers for a new soc which designed for dvb-s set top 
 box.
 It will support these features:
 1. Multi-layer display with alpha blending feature, including
 video(YUV), OSDs(2 same RGB layers), background(with fixed YUV color)
 and still picture(YUV color for still image)
 2. DVB-S tuner and demod
 3. HW MPEG2/4 decoder
 4. HW accelerated JPEG decoder engine.

 My targets are:
 1. Fit all the drivers in proper framework so they can be easily used
 by applications in open source community.
 2. As flexible as I can to add new software features in the future.

 My questions are:
 How many drivers should I implement, and how should I divide all the 
 features?
 As far as I know:
 A) a frame buffer driver for 2 OSDs, maybe also the control point for
 whole display module?
 B) video output device for video layer, which will output video program.
 C) drivers for tuner and demo (or just a driver which will export 2
 devices files for each?)
 D) driver for jpeg accelerate interface, or should it be a part of
 MPEG2/4 decoder driver?
 E) driver for MPEG2/4 decoder which will control the behave of H/W decoder.

 Actually I think all the display functions are relative, some
 functions i listed upper are operating one HW module, for instance:
 OSD and video layer are implemented by display module in H/W level.
 What's the right way to implement these functions in driver level,
 united or separated?
 And, I've read some documents for V4L2, but I still cannot figure out
 where should I implement my driver in the framework.

 In a word, I'm totally confused. Can you guys show me the right way or
 just kick me to a existing example with similar features?


 Currently, there are 2 drivers which have exactly the functionality
 that you have mentioned. The first one is an AV7110 based device and
 the other one is a STi7109 SOC based device.

 With regards to the AV7110 based hardware, you can have a look at
 linux/drivers/media/dvb/ttpci/ *

 And with regards to the STi7109 SOC based, you can have a look at
 http://jusst.de/hg/saa716x/
 linux/drivers/media/common/saa716x/ *
 specifically you will need to look at saa716x_ff.c/h for the STi7109
 related stuff


 Both the AV7110 and STi7109 SOC feature a OSD interface, in addition
 to the audio and video layers. which you can see from the drivers,
 themselves. Additionally the STi7109 SOC features HDMI outputs. The
 AV7110 based cards, they incorporate DVB-S/C/T frontends for different
 products. The STi7109 product that we have currently features only a
 DVB-S/S2 system only, though that doesn't make any difference at all.

 The only application that does handle the complete use of the decoder,
 is VDR and some other command line applications in the dvb-apps tree,
 that I am aware of. But there could be other applications as well.

 I guess, you've been confused, since you have been looking in the
 wrong place, ie in V4L, rather than with DVB.

 Regards,
 Manu

--
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: About driver architecture

2010-01-14 Thread Hans Verkuil

 Thanks for you reply.

 The SOC is still under development stage, it's not a product yet. And
 a small mistake I've made, the tuner will not integrated into the SOC.
 The demod might be.

 Some more questions:
 As far as I know, relationship between demod and decoder is the buffer
 used as demod output(also the input for a/v decoder), and maybe a
 shared interrupt used to catch some misc event from tuner/demo/av
 decoder(a interrupt status register will be used to determine who
 cause it). Do you think this will be a problem if I write individual
 drivers?

I would probably start by writing it as one driver, and check later how
much work it is to split it up. Writing it as one driver will certainly
work, splitting it up may or may not be a problem.

 And would you please tell me that is the memory-to-memory decoding for?

That's when you give the hardware a JPEG image (for example) and you get
the decoded raw image back from the hardware. As opposed to sending a JPEG
image to the hardware which is then sent on to e.g. HDMI out.

Regards,

  Hans


 Best regards
 Michael Qiu

 2010/1/14 Hans Verkuil hverk...@xs4all.nl:
 Hi Michael,

 Hi guys,
   I'm going to write drivers for a new soc which designed for dvb-s set
 top box.
 It will support these features:
 1. Multi-layer display with alpha blending feature, including
 video(YUV), OSDs(2 same RGB layers), background(with fixed YUV color)
 and still picture(YUV color for still image)
 2. DVB-S tuner and demod
 3. HW MPEG2/4 decoder
 4. HW accelerated JPEG decoder engine.

 Interesting device. Which SoC is this?


 My targets are:
 1. Fit all the drivers in proper framework so they can be easily used
 by applications in open source community.
 2. As flexible as I can to add new software features in the future.

 My questions are:
 How many drivers should I implement, and how should I divide all the
 features?
 As far as I know:
 A) a frame buffer driver for 2 OSDs, maybe also the control point for
 whole display module?
 B) video output device for video layer, which will output video
 program.
 C) drivers for tuner and demo (or just a driver which will export 2
 devices files for each?)
 D) driver for jpeg accelerate interface, or should it be a part of
 MPEG2/4 decoder driver?
 E) driver for MPEG2/4 decoder which will control the behave of H/W
 decoder.

 Actually I think all the display functions are relative, some
 functions i listed upper are operating one HW module, for instance:
 OSD and video layer are implemented by display module in H/W level.
 What's the right way to implement these functions in driver level,
 united or separated?
 And, I've read some documents for V4L2, but I still cannot figure out
 where should I implement my driver in the framework.

 In a word, I'm totally confused. Can you guys show me the right way or
 just kick me to a existing example with similar features?

 The driver that comes closest to this in terms of functionality is the
 ivtv driver. That driver supports MPEG2 encoding and decoding, an OSD
 and
 raw YUV input and output.

 There are several ways you can design devices like this, but the way
 ivtv
 is designed is that there is one master driver (ivtv) that handles all
 the
 encoding and decoding, and the framebuffer driver that you need for the
 OSD is just an 'add-on' module that provides the FB API but internally
 talks to the master driver.

 The tuner/demod part is usually integrated in the master driver. See the
 cx18 driver for example. But it is probably also possible to implement
 it
 as a separate driver in a similar manner as a framebuffer driver.

 Generally the key criteria on how to design drivers like this is the
 hardware design: for example, if the tuner/demod part is completely
 independent from the decoder part, then it is possible to write
 completely
 independent drivers as well, but if they share hardware components (e.g.
 the interrupt handling hardware), then you usually have to combine
 functions in one driver.

 Note that some features that you probably need (such as memory-to-memory
 decoding) are not yet implemented in V4L2 (although work is in progress
 on
 this).

 Regards,

Hans



 Best regards
 Michael Qiu
 --
 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



 --
 Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom


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



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
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: About driver architecture

2010-01-14 Thread Manu Abraham
On Thu, Jan 14, 2010 at 2:19 PM, Michael Qiu fallw...@gmail.com wrote:
 Thanks a lot for you advise.

 Before I read the source code you mentioned, I guess I should write a
 driver modules which provide /dev/dvb/adapter/audio, video, frontend,
 ca,  and also provide a /dev/fbx for OSD layer. But in source
 level, all display HW relative functions would probably in a same
 module, because they are operation on same block of H/W.
 But I still don't know where to put my global display control
 interface, for instance, the function to control which layer open and
 close, the alpha values used for each layer...


Yes, in which case you will need a frame buffer to handle your global display.


 And I investigated DirectFB, it seems if I provide a /dev/fb0 device
 the DirectFB can play around it and it will the base for upper GUI
 system.
 I also found DirectFB support V4L as it's surface source. So it will
 need some kernel module to control layer blending. It seems the thing
 I am looking for which implement the global display control.


Direct FB has it's own drivers, at a userspace level,
http://directfb.org/index.php?path=Support%2FGraphics
http://directfb.org/index.php?path=Support%2FMedia

Directfb and linuxtv parted ways a long time back, where the original
goal was to make a x86 based DVB STB at the parent organization at
that time then Convergence.

Regards,
Manu
--
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: About driver architecture

2010-01-14 Thread Manu Abraham
On Thu, Jan 14, 2010 at 2:17 PM, Hans Verkuil hverk...@xs4all.nl wrote:

 Hi Hans,

 On Thu, Jan 14, 2010 at 1:25 PM, Hans Verkuil hverk...@xs4all.nl wrote:

 Hi,


 On Thu, Jan 14, 2010 at 11:35 AM, Michael Qiu fallw...@gmail.com
 wrote:
 Hi guys,
  I'm going to write drivers for a new soc which designed for dvb-s set
 top box.
 It will support these features:
 1. Multi-layer display with alpha blending feature, including
 video(YUV), OSDs(2 same RGB layers), background(with fixed YUV color)
 and still picture(YUV color for still image)
 2. DVB-S tuner and demod
 3. HW MPEG2/4 decoder
 4. HW accelerated JPEG decoder engine.

 My targets are:
 1. Fit all the drivers in proper framework so they can be easily used
 by applications in open source community.
 2. As flexible as I can to add new software features in the future.

 My questions are:
 How many drivers should I implement, and how should I divide all the
 features?
 As far as I know:
 A) a frame buffer driver for 2 OSDs, maybe also the control point for
 whole display module?
 B) video output device for video layer, which will output video
 program.
 C) drivers for tuner and demo (or just a driver which will export 2
 devices files for each?)
 D) driver for jpeg accelerate interface, or should it be a part of
 MPEG2/4 decoder driver?
 E) driver for MPEG2/4 decoder which will control the behave of H/W
 decoder.

 Actually I think all the display functions are relative, some
 functions i listed upper are operating one HW module, for instance:
 OSD and video layer are implemented by display module in H/W level.
 What's the right way to implement these functions in driver level,
 united or separated?
 And, I've read some documents for V4L2, but I still cannot figure out
 where should I implement my driver in the framework.

 In a word, I'm totally confused. Can you guys show me the right way or
 just kick me to a existing example with similar features?


 Currently, there are 2 drivers which have exactly the functionality
 that you have mentioned. The first one is an AV7110 based device and
 the other one is a STi7109 SOC based device.

 With regards to the AV7110 based hardware, you can have a look at
 linux/drivers/media/dvb/ttpci/ *

 And with regards to the STi7109 SOC based, you can have a look at
 http://jusst.de/hg/saa716x/
 linux/drivers/media/common/saa716x/ *
 specifically you will need to look at saa716x_ff.c/h for the STi7109
 related stuff


 Both the AV7110 and STi7109 SOC feature a OSD interface, in addition
 to the audio and video layers. which you can see from the drivers,
 themselves. Additionally the STi7109 SOC features HDMI outputs. The
 AV7110 based cards, they incorporate DVB-S/C/T frontends for different
 products. The STi7109 product that we have currently features only a
 DVB-S/S2 system only, though that doesn't make any difference at all.

 The AV7110 OSD is not framebuffer based AFAIK. So probably not a good
 place to look.


 It doesn't support OSD ?

 I didn't say that. Of course it supports an OSD. Just not through a
 traditional /dev/fbX device which allows you to put Qt or whatever on top
 of it. Instead it requires custom commands to use it. I'm assuming that
 the SoC Michael is talking about is framebuffer based in which case ivtv
 is the closest match.

The STi7109 also has a frame buffer approach, currently the
framebuffer is not implemented in this specific case.
http://osdir.com/ml/linux.fbdev.user/2008-07/msg4.html

Regards,
Manu
--
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: About driver architecture

2010-01-14 Thread HoP
 The STi7109 also has a frame buffer approach, currently the
 framebuffer is not implemented in this specific case.
 http://osdir.com/ml/linux.fbdev.user/2008-07/msg4.html


When you use stb7109 as main cpu for system (like is done
for many linux or os21-based set-top-boxes already), then
you can use FB driver from stlinux, what is STM's port
of linux for theirs STB7xxx SOCs. See more on www.stlinux.com.

Even more, there is already flying around full source code
for such SOCs, which allows you to make full-featured box.

I have a dream that sometimes those drivers come to mainline
similar like TI chips are comming these days.

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


Re: About driver architecture

2010-01-14 Thread Manu Abraham
On Thu, Jan 14, 2010 at 2:19 PM, Michael Qiu fallw...@gmail.com wrote:
 Thanks a lot for you advise.

 Before I read the source code you mentioned, I guess I should write a
 driver modules which provide /dev/dvb/adapter/audio, video, frontend,
 ca,  and also provide a /dev/fbx for OSD layer. But in source
 level, all display HW relative functions would probably in a same
 module, because they are operation on same block of H/W.
 But I still don't know where to put my global display control
 interface, for instance, the function to control which layer open and
 close, the alpha values used for each layer...

 And I investigated DirectFB, it seems if I provide a /dev/fb0 device
 the DirectFB can play around it and it will the base for upper GUI
 system.
 I also found DirectFB support V4L as it's surface source. So it will
 need some kernel module to control layer blending. It seems the thing
 I am looking for which implement the global display control.

With regards to the 7109 framebuffer. There is a DirectFB driver for
it in the STLinux distribution. (If you use the SOC as a STB) DirectFB
acts as a whole application/framework on the STB.

http://www.stlinux.com/download/updates.php?r=2.3;u=stlinux23-target-directfb14-multi-1.4.3.STM2009.12.11-2.src.rpm

Regards,
Manu
--
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


SoC Realtek RTD 12xx devices

2010-01-14 Thread Theunis Potgieter
Hi, is there anyone that has started to work on Realtek RTD 1261
(http://rtd1261.wikidot.com/internals), 1283 etc type systems?

Here is the kernel of RTD 1283
http://gator884.hostgator.com/~xtreamer/Xtreamer_GPL/xtr_kernel.tar.bz2

I would like to know if what they gave is enough to use
encoder/decoder/osd capabilities. Or would this be the wrong mailing
list to ask, if so please direct me to where I should ask.

Thanks,
Theunis
--
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


omap34xxcam question?

2010-01-14 Thread Michael Trimarchi

Hi

Is ok that it try only the first format and size? why does it not continue and 
find a matching?

@@ -470,7 +471,7 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev,
   pix_tmp_out = *wanted_pix_out;
   rval = isp_try_fmt_cap(isp, pix_tmp_in, pix_tmp_out);
   if (rval)
-   return rval;
+   continue;

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


Re: [PATCH] RFC: mx27: Add soc_camera support

2010-01-14 Thread Alan Carvalho de Assis
Hi Javier,

On 1/14/10, javier Martin javier.mar...@vista-silicon.com wrote:
 No idea what can be causing this. Maybe I2C address is bad in board specific
 code?


I don't know, I will check carefully.

 Linux video capture interface: v2.00
 write: -5
 MT9T31 Read register 0xFF = -5
 Forcing mt9t031_video_probe to return OK!
 mx27-camera mx27-camera.0: initialising
 mx27-camera: probe of mx27-camera.0 failed with error -2


 As far as I know, video buffers are allocated in probe() function. Maybe you
 have a memory fragmentation problem and you need to move buffer allocation
 to init().
 We have faced this problem many times in the past.


Hmm, great Javier, in fact it could be the issue!

Thank you very much.

Best Regards,

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


Re: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan-22fix

2010-01-14 Thread Oliver Endriss
Hi,

Abylai Ospan wrote:
 Hello Oliver,
 
  There is no reason why we have to use the set_tone routine of the
  stv0900. You can combine
  - set_tone of LNBH24 with
  - stv090x_send_diseqc_msg of stv0900
  without losing anything.
  Before a DiSEqC message will be sent, the tone will be disabled.
  Then the stv090x_send_diseqc_msg of the stv0900 can control the 22kHz
  tone generator of the LNBH24 using EXTM or DSQIN.
 yes, you right.
 
   I think lnbp21_set_tone will be used if set_tone is not defined
   previously (set_tone == NULL). Is this correct ?
  No, sorry. set_tone had to be added, because the stv0900 can also
  operate in DiSEqC envelope mode (connected to DSQIN of the LNBH24).
  In this mode set_tone of the LNBH24 has to be used.
 ok, you right.
 But seems like fe-ops.set_tone = lnbp21_set_tone; override .set_tone
 = stv090x_set_tone, and stv090x_set_tone never used. Is this right ?

Correct.

 Also please check our logic. We set override_clear=LNBH24_TEN in
 cx23885-dvb.c i.e. we disabling 22kHz logic in LNBH24 and all 22kHz
 logic driven from one place ( stv0900 ).

Well, if you specify override_clear=LNBH24_TEN then we have a problem.

Possible solutions:
a) Do not set LNBH24_TEN in override_clear, or
b) Modify your patch to something like that:
   if (!(override_clear  LNBH24_TEN))
   fe-ops.set_tone = lnbp21_set_tone;

Both will fix the issue.

 This more clear for debugging 
 (hardware and software ).
 This problem is reported by one of our customer. Your changeset
 13673:75331e740f61 is broke 22khz tone functionality on our cards.

Ok, I did not expect that someone would set LNBH24_TEN in
override_clear. ;-)

 We need to find compromise. Reverting the patch is not a problem ( in
 this case we need to remove override_clear=LNBH24_TEN).

No problem. Both solutions above are ok for me. Maybe b) is more robust,
because it allows override_clear=LNBH24_TEN to be used.
I leaveit to you: Choose the one you like.

Regards,
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/

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


[PULL] http://udev.netup.ru/hg/v4l-dvb-aospan-22fix

2010-01-14 Thread Abylai Ospan
Mauro,

Please pulll change:

http://udev.netup.ru/cgi-bin/hgwebdir.cgi/v4l-dvb-aospan-22fix/rev/fc3e44f30da3

22-kHz set_tone fix for NetUP Dual DVB-S2-CI card. 22kHz logic controlled by 
demod.

This patch modified after discussion with Oliver. This version is acceptable 
for both side ... 

Thanks.

-- 
Abylai Ospan aos...@netup.ru
NetUP Inc.


signature.asc
Description: This is a digitally signed message part


Re: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan-22fix

2010-01-14 Thread Abylai Ospan
Hello,

On Thu, 2010-01-14 at 14:44 +0100, Oliver Endriss wrote:
  This more clear for debugging 
  (hardware and software ).
  This problem is reported by one of our customer. Your changeset
  13673:75331e740f61 is broke 22khz tone functionality on our cards.
 Ok, I did not expect that someone would set LNBH24_TEN in
 override_clear. ;-)
yes, this not trivial to trace all override definitions :)

  We need to find compromise. Reverting the patch is not a problem ( in
  this case we need to remove override_clear=LNBH24_TEN).
 
 No problem. Both solutions above are ok for me. Maybe b) is more robust,
 because it allows override_clear=LNBH24_TEN to be used.
 I leaveit to you: Choose the one you like.
ok. second is choosen - it's no broke yours and our logic.

-- 
Abylai Ospan aos...@netup.ru
NetUP Inc.

--
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] saa7134-empress: remove unlock_kernel() without lock_kernel()

2010-01-14 Thread Will Tate
Call to unlock_kernel() made without previous call to lock_kernel() in
ts_open() function of saa7134-empress.c.

Signed-off-by: William J. Tate willyt...@gmail.com

--- a//drivers/media/video/saa7134/saa7134-empress.c2010-01-14
10:18:51.0 -0500
+++ b//drivers/media/video/saa7134/saa7134-empress.c2010-01-14
10:19:36.0 -0500
@@ -108,7 +108,6 @@
 done_up:
mutex_unlock(dev-empress_tsq.vb_lock);
 done:
-   unlock_kernel();
return err;
 }
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Order of dvb devices

2010-01-14 Thread Andreas Besse
if a system contains multiple DVB cards of the same type, how is the
order of devices determined by the driver/kernel?

I use 2 Technotrend S2-3200 cards in a system and observerd that if I
load the driver driver budget_ci manually as follows:

modprobe budget_ci adapter_nr=0,1

the device with the lower pci ID :08:00.0 is assigned to adapter0 and the 
device with the higher pci ID :08:01.0
is assigned to adapter1:


udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter0/frontend0)
[...]
  looking at parent device '/devices/pci:00/:00:1e.0/:08:00.0':
KERNELS==:08:00.0
SUBSYSTEMS==pci


udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter1/frontend0)
[...]
  looking at parent device '/devices/pci:00/:00:1e.0/:08:01.0':
KERNELS==:08:01.0
SUBSYSTEMS==pci


Is it true for all DVB drives that the device with the lower PCI id gets the 
lower adapter name?








--
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: Order of dvb devices

2010-01-14 Thread Devin Heitmueller
On Thu, Jan 14, 2010 at 10:35 AM, Andreas Besse be...@motama.com wrote:
 if a system contains multiple DVB cards of the same type, how is the
 order of devices determined by the driver/kernel?

 I use 2 Technotrend S2-3200 cards in a system and observerd that if I
 load the driver driver budget_ci manually as follows:

 modprobe budget_ci adapter_nr=0,1

 the device with the lower pci ID :08:00.0 is assigned to adapter0 and the 
 device with the higher pci ID :08:01.0
 is assigned to adapter1:


 udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter0/frontend0)
 [...]
  looking at parent device '/devices/pci:00/:00:1e.0/:08:00.0':
    KERNELS==:08:00.0
    SUBSYSTEMS==pci


 udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter1/frontend0)
 [...]
  looking at parent device '/devices/pci:00/:00:1e.0/:08:01.0':
    KERNELS==:08:01.0
    SUBSYSTEMS==pci


 Is it true for all DVB drives that the device with the lower PCI id gets the 
 lower adapter name?

No, you cannot really make this assumption.  In fact, there are users
who see behavior where uses have two of the same card and the cards
get flipped around randomly just by rebooting.  The ordering is based
on the timing of the device driver loading, so it is not
deterministic.

I believe you can use udev rules though to force a particular driver
to get a specific adapter number (although admittedly I do not know
the specifics of how it is done, and am not confident it *can* be done
if both cards are the same vendor/model).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Order of dvb devices

2010-01-14 Thread Andreas Besse
Devin Heitmueller wrote:
 On Thu, Jan 14, 2010 at 10:35 AM, Andreas Besse be...@motama.com wrote:
   
 if a system contains multiple DVB cards of the same type, how is the
 order of devices determined by the driver/kernel?

 I use 2 Technotrend S2-3200 cards in a system and observerd that if I
 load the driver driver budget_ci manually as follows:

 modprobe budget_ci adapter_nr=0,1

 the device with the lower pci ID :08:00.0 is assigned to adapter0 and 
 the device with the higher pci ID :08:01.0
 is assigned to adapter1:


 udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter0/frontend0)
 [...]
  looking at parent device '/devices/pci:00/:00:1e.0/:08:00.0':
KERNELS==:08:00.0
SUBSYSTEMS==pci


 udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter1/frontend0)
 [...]
  looking at parent device '/devices/pci:00/:00:1e.0/:08:01.0':
KERNELS==:08:01.0
SUBSYSTEMS==pci


 Is it true for all DVB drives that the device with the lower PCI id gets the 
 lower adapter name?
 

 No, you cannot really make this assumption.  In fact, there are users
 who see behavior where uses have two of the same card and the cards
 get flipped around randomly just by rebooting.  The ordering is based
 on the timing of the device driver loading, so it is not
 deterministic.
   
yes if there are different drivers I already observed the behaviour that
the ordering gets flipped after reboot.

But if I assume, that there is only *one* driver that is loaded (e.g.
budget_av) for all dvb cards in the system, how is the ordering of these
devices determined? How does the driver search for available dvb cards?
--
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: Order of dvb devices

2010-01-14 Thread Devin Heitmueller
On Thu, Jan 14, 2010 at 11:01 AM, Andreas Besse be...@motama.com wrote:
 yes if there are different drivers I already observed the behaviour that
 the ordering gets flipped after reboot.

 But if I assume, that there is only *one* driver that is loaded (e.g.
 budget_av) for all dvb cards in the system, how is the ordering of these
 devices determined? How does the driver search for available dvb cards?

I believe your assumption is incorrect.  I believe the enumeration
order is not deterministic even for multiple instances of the same
driver.  It is not uncommon to hear mythtv users complain that I have
two PVR-150 cards installed in my PC and the order sometimes get
reversed on reboot.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Problem with gspca and zc3xx

2010-01-14 Thread Jose Alberto Reguero
El Miércoles, 13 de Enero de 2010, Jose Alberto Reguero escribió:
 El Martes, 12 de Enero de 2010, Jose Alberto Reguero escribió:
  El Martes, 12 de Enero de 2010, Jean-Francois Moine escribió:
   On Mon, 11 Jan 2010 15:49:55 +0100
  
   Jose Alberto Reguero jaregu...@telefonica.net wrote:
I take another image with 640x480 and the bad bottom lines are 8. The
right side look right this time. The good sizes are:
320x240-320x232
640x480-640x472
  
   Hi Jose Alberto and Hans,
  
   Hans, I modified a bit your patch to handle the 2 resolutions (also,
   the problem with pas202b does not exist anymore). May you sign or ack
   it?
  
   Jose Alberto, the attached patch is to be applied to the last version
   of the gspca in my test repository at LinuxTv.org
 http://linuxtv.org/hg/~jfrancois/gspca
   May you try it?
  
   Regards.
 
   The patch works well.
  There is another problem. When autogain is on(default), the image is bad.
   It is possible to put autogain off by default?
 
  Thanks.
  Jose Alberto
 
 Autogain works well again. I can't reproduce the problem. Perhaps the debug
 messages. (Now I have debug off).
 
 Thanks.
 Jose Alberto

I found the problem. Autogain don't work well if brightness is de default 
value(128). if brightness is less(64) autogain work well. There is a problem 
when setting the brightness. It is safe to remove the brightness control?
Patch attached.

Jose Alberto
diff -r d490d84a64ac linux/drivers/media/video/gspca/zc3xx.c
--- a/linux/drivers/media/video/gspca/zc3xx.c	Wed Jan 13 12:11:34 2010 -0200
+++ b/linux/drivers/media/video/gspca/zc3xx.c	Thu Jan 14 17:03:10 2010 +0100
@@ -6028,6 +6041,7 @@
 	case SENSOR_OV7620:
 	case SENSOR_PAS202B:
 	case SENSOR_PO2030:
+	case SENSOR_MC501CB:
 		return;
 	}
 /*fixme: is it really write to 011d and 018d for all other sensors? */
@@ -6796,6 +6837,7 @@
 	case SENSOR_OV7620:
 	case SENSOR_PAS202B:
 	case SENSOR_PO2030:
+	case SENSOR_MC501CB:
 		gspca_dev-ctrl_dis = (1  BRIGHTNESS_IDX);
 		break;
 	case SENSOR_HV7131B:


RE: omap34xxcam question?

2010-01-14 Thread Aguirre, Sergio


 -Original Message-
 From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org]
 Sent: Thursday, January 14, 2010 6:01 AM
 To: linux-media@vger.kernel.org
 Cc: Aguirre, Sergio
 Subject: omap34xxcam question?
 
 Hi
 
 Is ok that it try only the first format and size? why does it not continue
 and find a matching?

Actually, that was the intention, but I guess it was badly implemented.

Thanks for the catch, and the contribution!

Regards,
Sergio
 
 @@ -470,7 +471,7 @@ static int try_pix_parm(struct omap34xxcam_videodev
 *vdev,
 pix_tmp_out = *wanted_pix_out;
 rval = isp_try_fmt_cap(isp, pix_tmp_in,
 pix_tmp_out);
 if (rval)
 -   return rval;
 +   continue;
 
 Michael
--
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: Order of dvb devices

2010-01-14 Thread Michael Krufky
On Thu, Jan 14, 2010 at 11:09 AM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 On Thu, Jan 14, 2010 at 11:01 AM, Andreas Besse be...@motama.com wrote:
 yes if there are different drivers I already observed the behaviour that
 the ordering gets flipped after reboot.

 But if I assume, that there is only *one* driver that is loaded (e.g.
 budget_av) for all dvb cards in the system, how is the ordering of these
 devices determined? How does the driver search for available dvb cards?

 I believe your assumption is incorrect.  I believe the enumeration
 order is not deterministic even for multiple instances of the same
 driver.  It is not uncommon to hear mythtv users complain that I have
 two PVR-150 cards installed in my PC and the order sometimes get
 reversed on reboot.

 Devin

 --
 Devin J. Heitmueller - Kernel Labs
 http://www.kernellabs.com
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


If you modinfo dvb_adapter_driver_foo  you will see an adapter_nr
module option -- you can use this to force your DVB adapter device
minor ordering.

Regards,

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


Re: omap34xxcam question?

2010-01-14 Thread Michael Trimarchi

Hi,

Aguirre, Sergio wrote:



-Original Message-
From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org]
Sent: Thursday, January 14, 2010 6:01 AM
To: linux-media@vger.kernel.org
Cc: Aguirre, Sergio
Subject: omap34xxcam question?

Hi

Is ok that it try only the first format and size? why does it not continue
and find a matching?


Actually, that was the intention, but I guess it was badly implemented.

Thanks for the catch, and the contribution!

Regards,
Sergio

@@ -470,7 +471,7 @@ static int try_pix_parm(struct omap34xxcam_videodev
*vdev,
pix_tmp_out = *wanted_pix_out;
rval = isp_try_fmt_cap(isp, pix_tmp_in,
pix_tmp_out);
if (rval)
-   return rval;
+   continue;



Is the patch good? or you are going to provide a better fix

Michael


Michael

--
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: VL4-DVB compilation issue not covered by Daily Automated

2010-01-14 Thread xof
Devin Heitmueller a écrit :
 On Wed, Jan 13, 2010 at 3:32 AM, xof x...@skynet.be wrote:
   
 Are you sure? (it is an Ubuntu-only issue)

 I can see several
 
 #include asm/asm.h
   
 in the v4l tree that compile fine on Ubuntu
 but only linux/drivers/media/dvb/firewire/firedtv-1394.c contains
 
 #include asm.h
   
 and doesn't compile.

 Unfortunately the asm.h asm/asm.h is not the only issue with
 firedtv-1394.c (on Ubuntu/Karmic Koala?).
 The /drivers/ieee1394/*.h seem to be in the linux-sources tree and not
 in the linux-headers one (?)

 Everywhere I look, I read don't bother, just disable firedtv-1394.c
 until they fix it.
 

 I think perhaps you meant to write dma.h and not asm.h.

 All of the missing includes in the error log (including dma.h) are
 for files that are found in the iee1394 source directory, which are
 not provided in the Ubuntu linux-headers package.

 Devin

   
Oups!  You are right...

Thank you.


xof
-
PS: I signaled the problem to the Ubuntu community
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/507154
I hope this was the right thing to do... I did not find any mention of
the problem there.
There is no reaction yet, it is just one of 5000 other things to look at...

--
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: omap34xxcam question?

2010-01-14 Thread Aguirre, Sergio


 -Original Message-
 From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org]
 Sent: Thursday, January 14, 2010 11:25 AM
 To: Aguirre, Sergio
 Cc: linux-media@vger.kernel.org
 Subject: Re: omap34xxcam question?
 
 Hi,
 
 Aguirre, Sergio wrote:
 
  -Original Message-
  From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org]
  Sent: Thursday, January 14, 2010 6:01 AM
  To: linux-media@vger.kernel.org
  Cc: Aguirre, Sergio
  Subject: omap34xxcam question?
 
  Hi
 
  Is ok that it try only the first format and size? why does it not
 continue
  and find a matching?
 
  Actually, that was the intention, but I guess it was badly implemented.
 
  Thanks for the catch, and the contribution!
 
  Regards,
  Sergio
  @@ -470,7 +471,7 @@ static int try_pix_parm(struct omap34xxcam_videodev
  *vdev,
  pix_tmp_out = *wanted_pix_out;
  rval = isp_try_fmt_cap(isp, pix_tmp_in,
  pix_tmp_out);
  if (rval)
  -   return rval;
  +   continue;
 
 
 Is the patch good? or you are going to provide a better fix

Yes. Sorry if I wasn't clear enough.

Looks good to me, and I don't have a better fix on top of my head for the 
moment...

I'm assuming you tested it in your environment, right?

If yes, then I'll take the patch in my queue for submission to Sakari's tree.

Thanks for your time.

Regards,
Sergio

 
 Michael
 
  Michael
  --
  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: omap34xxcam question?

2010-01-14 Thread Michael Trimarchi

Aguirre, Sergio wrote:



-Original Message-
From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org]
Sent: Thursday, January 14, 2010 11:25 AM
To: Aguirre, Sergio
Cc: linux-media@vger.kernel.org
Subject: Re: omap34xxcam question?

Hi,

Aguirre, Sergio wrote:

-Original Message-
From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org]
Sent: Thursday, January 14, 2010 6:01 AM
To: linux-media@vger.kernel.org
Cc: Aguirre, Sergio
Subject: omap34xxcam question?

Hi

Is ok that it try only the first format and size? why does it not

continue

and find a matching?

Actually, that was the intention, but I guess it was badly implemented.

Thanks for the catch, and the contribution!

Regards,
Sergio

@@ -470,7 +471,7 @@ static int try_pix_parm(struct omap34xxcam_videodev
*vdev,
pix_tmp_out = *wanted_pix_out;
rval = isp_try_fmt_cap(isp, pix_tmp_in,
pix_tmp_out);
if (rval)
-   return rval;
+   continue;


Is the patch good? or you are going to provide a better fix


Yes. Sorry if I wasn't clear enough.

Looks good to me, and I don't have a better fix on top of my head for the 
moment...

I'm assuming you tested it in your environment, right?


Ok, my enviroment is not pretty stable but for sure this is required. There is 
one problem:

Suppose that the camera support this format:

YUV and RAW10

The video4linux enumeration is done in this order. 
We know that if you want to use resizer and previewer we can't use the YUV (go straight to memory)
but it is selected because is the first. So maybe the best thing is to find the one that is suggest in the csi 
configuration first. Hope that is clear.


Michael



If yes, then I'll take the patch in my queue for submission to Sakari's tree.

Thanks for your time.

Regards,
Sergio


Michael


Michael

--
To unsubscribe from this list: send the line unsubscribe linux-media

in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



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



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


Re: pull request: http://linuxtv.org/hg/~hgoede/gspca

2010-01-14 Thread Hans de Goede

Hi,

On 01/13/2010 02:35 PM, Mauro Carvalho Chehab wrote:

Hans,

It seems that you didn't properly set your mercurial environment. All patches 
has
a wrong user:

# HG changeset patch
# User h...@rhel5-devel.localdomain
# Date 1261728910 -3600
# Node ID 47d5a57b018343b02a0ea9de83380c1341867694
# Parent  a7036c23ed813eb1051ce7b598fb742c08d2394f

This will produce a wrong log if I merge from your tree. Please correct and 
re-submit.
README.patches contain instructions on how to set it.




Oops, sorry (again).

This time I should have got it right, and there are 4 new commits,
1 of which is marked high prio

Summary of the changes:
gspca_sn9c2028:  New driver
gspca_cpia1: New driver
gspca_mr97310a:  Fix streaming on UHCI controllers (high prio)
gspca_ov519: Several fixes related to ov519 + ov7648 (high prio)
gscpa_stv0680:   Fix cam not streaming on hotplug (high prio)
gscpa_stv0680:   Fix VGA cams not streaming (high prio)
gscpa_sonixb:Fix hstart of tas5110d sensor (high prio)
gspca-docs:  Some updates
Kconfig: Set default of deprecated cams to n
Kconfig: Mark sn9c102, zc0301 and et61x251 as deprecated

For the last one see:
http://linuxtv.org/hg/~hgoede/gspca/rev/fac8a03f44a0

For rationale.

Thanks  Regards,

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


Re: Kworld 315U and SAA7113?

2010-01-14 Thread Franklin Meng
Mario, 

Thank you for taking a look at this..  I'll resubmit the patches.  

Thanks,
Franklin Meng

--- On Wed, 1/13/10, Mauro Carvalho Chehab mche...@redhat.com wrote:

 From: Mauro Carvalho Chehab mche...@redhat.com
 Subject: Re: Kworld 315U and SAA7113?
 To: Franklin Meng fmeng2...@yahoo.com
 Cc: linux-media@vger.kernel.org
 Date: Wednesday, January 13, 2010, 1:10 PM
 Hi Franklin,
 
 I have no Kworld 315U here for testing, but your patch
 looked sane on my eyes.
 In order to merge this upstream, it would be better if you
 could submit it as two
 separate patches: the first one with the saa7115 changes to
 support re-energizing
 the device, and the second one with the em28xx changes.
 
 Please send your Signed-off-by: on the patches.
 
 Cheers,
 Mauro.
 
 Franklin Meng wrote:
  I tweaked the GPIO's a bit more for the Kworld 315U
 and switching between analog and digital signals is more
 reliable now.  Attached is an updated diff.  
  
  diff -r b6b82258cf5e
 linux/drivers/media/video/em28xx/em28xx-cards.c
  ---
 a/linux/drivers/media/video/em28xx/em28xx-cards.c   Thu
 Dec 31 19:14:54 2009 -0200
  +++
 b/linux/drivers/media/video/em28xx/em28xx-cards.c   Sat
 Jan 09 11:29:27 2010 -0800
  @@ -122,13 +122,31 @@       
                
                
                
          
   };           
                
                
                
                
        
   #endif           
                
                
                
                
    
                
                
                
                
                
        
  +/* Kworld 315U         
                
                
                
              
  +   GPIO0 - Enable digital power
 (lgdt3303) - low to enable         
              
    
  +   GPIO1 - Enable analog power
 (saa7113/emp202) - low to enable       
               
  +   GPIO7 - enables something ? 
                
                
                
      
  +   GOP2  - ?? some sort of reset
 ?               
                
                
    
  +   GOP3  - lgdt3303 reset 
                
                
                
           
  + */             
                
                
                
                
     
   /* Board - EM2882 Kworld 315U digital */ 
                
                
            
   static struct em28xx_reg_seq
 em2882_kworld_315u_digital[] = {       
                 
  -   
    {EM28XX_R08_GPIO,   
    0xff,   0xff,   
        10},     
                
     
  -   
    {EM28XX_R08_GPIO,   
    0xfe,   0xff,   
        10},     
                
     
  +   
    {EM28XX_R08_GPIO,   
    0x7e,   0xff,   
        10},     
                
     
      
    {EM2880_R04_GPO,     
   0x04,   0xff,     
      10},       
                
   
      
    {EM2880_R04_GPO,     
   0x0c,   0xff,     
      10},       
                
   
  -   
    {EM28XX_R08_GPIO,   
    0x7e,   0xff,   
        10},     
                
     
  +       {  -1, 
                
 -1,     -1,       
      -1},       
                
   
  +};             
                
                
                
                
      
  +             
                
                
                
                
        
  +/* Board - EM2882 Kworld 315U analog1 analog tv
 */               
                
    
  +static struct em28xx_reg_seq
 em2882_kworld_315u_analog1[] = {       
                 
  +   
    {EM28XX_R08_GPIO,   
    0xfd,   0xff,   
        10},     
                
     
  +   
    {EM28XX_R08_GPIO,   
    0x7d,   0xff,   
        10},     
                
     
  +       {  -1, 
                
 -1,     -1,       
      -1},       
                
   
  +};             
                
                
                
                
      
  +             
                
                
                
                
        
  +/* Board - EM2882 Kworld 315U analog2
 component/svideo */           
                 
  +static struct em28xx_reg_seq
 em2882_kworld_315u_analog2[] = {       
                 
  +   
    {EM28XX_R08_GPIO,   
    0xfd,   0xff,   
        10},     
                
     
          { 
 -1,               
   -1,     -1,     
        -1},     
                
     
   };           
                
                
                
                
        
                
                
                
                
                
        
  @@ -140,6 +158,14 @@         
                
                
                
         
          { 
 -1,               
   -1,     -1,     
        -1},     
                
     
   };           
                
                
                
                
        
                
                
                
                
                
        
  +/* Board - EM2882 Kworld 315U suspend */   
                
                
          
  +static struct em28xx_reg_seq
 em2882_kworld_315u_suspend[] 

Re: Kworld 315U and SAA7113?

2010-01-14 Thread Franklin Meng
Devin, 


 
 This is pretty good stuff.  A few questions/comments
 about your patch:
 
 The code has different GPIO configurations for the two
 analog modes.
 This is a bit unusual for an em28xx design.  Do you
 know what the
 difference is in terms of what GPIO7 controls?

Unfortunately, I do not know the difference.  I thought it might be to do 
something to the tuner but I am not quite sure.  If I remember correctly, the 
traces that I obtained also showed a difference between the analog modes.  I do 
know that if I leave the bit on it does not cause any adverse affects (other 
than maybe more power is being drawn)..

 
 The digital GPIO block strobes GPO3 to reset the
 lgdt3303.  While I
 generally believe that it's good to explicitly strobe the
 reset low,
 this could cause problems with em28xx devices.  This
 is because the
 em28xx calls the digital GPIO whenever starting
 streaming.  Hence, you
 could end up with the chip being reset without the demod
 driver's
 init() routine being called, resulting in the chip's
 register state
 not being in sync with the driver's state info.  In
 fact, we have this
 issue with one of the Terratec boards where the zl10353
 driver state
 gets out of sync with the hardware (I still need to submit
 a patch
 upstream for that case).  Your code at this point
 should probably only
 ensure the 3303 is not in reset (by setting the GPIO pin
 high).
 

I might try leaving the GPIO pin high..  I had lots of issues switching between 
analog and digital modes so changing this bit may cause one or the other to not 
work.  For example if I leave both pins for the SAA/EM202 and the demod high, 
the analog doesn't seem to work correctly.  I'm guessing that there probably 
isn't enough power to keep both devices operational.  I'll try it out some more 
to see what happens.  

 It's not surprising that you would uncover an issue with
 the suspend
 logic.  Despite the fact that the em28xx driver
 provides a suspend
 method it is not actually used today in any of the board
 profiles.

I saw it was available so I decided to use it.  I actually also implemented a 
suspend state for the AC97 chip (the EM202 I believe) though I wasn't fully 
happy with the code so I didn't include it this time around.

 
 The saa7115 stuff looks pretty reasonable at first glance,
 although I
 am a bit worried about the possibility that it could cause
 a
 regression in other products that use that decoder.

As far as I can tell, the Kworld 315U is the only board that uses this 
combination of parts..  Thomson tuner, LG demod, and SAA7113.  I don't think 
any other device has used the SAA7113 together with a digital demod.  Most 
products seem to only have the SAA711X on an analog only board.  Since I don't 
have any other USB adapters with the SAA chip I was unable to do any further 
testing on the SAA code changes.  

 
 Did you actually do any power analysis to confirm that the
 suspend
 functionality is working properly?

Humm.. I did not actually do this.  Though, maybe I can figure this out by 
seeing how much power draw is on the USB bus.  I don't recall if there is a way 
to figure this out or not from within Linux.  I do remember Windows having such 
a feature..  I probably need to do a comparison between both OS's to make sure 
I get things are correct..  Is there a way to get information on how much power 
draw is happening on the USB bus in Linux?

 
 I agree with Mauro though that this should be split into
 multiple
 patches.  In fact, I would seriously consider three
 patches instead of
 two - the first patch adds the basic functionality to get
 the board
 working, the second adds the saa7115 code, and the third
 adds the
 suspend GPIO changes.  This will make it easier for
 others who have
 problems to isolate whether any problems are a basic issue
 with the
 board not working or whether it is related to the suspend
 and power
 management changes.
 

Well basic functionality of the board is already included (digital only).  
Douglas helped me get those changes in earlier.  I'll see if I can split up the 
patches better.

Last thing is that my responses may be kind of slow since I had a new addition 
to the family not too long ago. :)

Thanks,
Franklin 


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


[RFC PATCH] fix try_pix_parm loop

2010-01-14 Thread Michael Trimarchi


This patch fix try_pix_parm loop that try to find a suitable format for
the isp engine

Signed-off-by: Michael Trimarchi mich...@panicking.kicks-ass.org
Cc: akari Ailus sakari.ai...@maxwell.research.nokia.com
Cc: Sergio Aguirre saagui...@ti.com

---
diff --git a/drivers/media/video/omap34xxcam.c b/drivers/media/video/omap34xxcam.c
index 53b587e..bf7db71 100644
--- a/drivers/media/video/omap34xxcam.c
+++ b/drivers/media/video/omap34xxcam.c
@@ -470,7 +470,7 @@ static int try_pix_parm(struct omap34xxcam_videodev *vdev,
 			pix_tmp_out = *wanted_pix_out;
 			rval = isp_try_fmt_cap(isp, pix_tmp_in, pix_tmp_out);
 			if (rval)
-return rval;
+continue;
 
 			dev_dbg(vdev-vfd-dev, this w %d\th %d\tfmt %8.8x\t
 - w %d\th %d\t fmt %8.8x


Re: [PATCH 1/1] media: dvb-usb/af9015, add IR support for digivox mini II

2010-01-14 Thread Antti Palosaari

On 01/13/2010 10:00 PM, Jiri Slaby wrote:

MSI digivox mini II works even with remote=2 module parameter. Check
for manufacturer and if it is Afatech, use af9015_ir_table_msi and
af9015_rc_keys_msi.

The device itself is 15a4:9016.


NACK

Device ID 15a4:9016 is reference design ID and it is used by vary many 
devices. Also manufacturer string Afatech is chipset default one. This 
leads MSI remote in question configured for many devices using default / 
reference values which I don't like good idea. Strings and other USB 
settings are stored to the device eeprom.


Empia (em28xx) driver uses eeprom hashing for identifying reference ID 
devices. This approach is better because it uses all eeprom bytes. I 
hope you could implement similar eeprom hashing to af9015.


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


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

2010-01-14 Thread Hans Verkuil
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Thu Jan 14 19:00:05 CET 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   13972:725c07a70453
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

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

Detailed results are available here:

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

Full logs are available here:

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

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

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


Re: Kworld 315U and SAA7113?

2010-01-14 Thread Devin Heitmueller
On Thu, Jan 14, 2010 at 1:54 PM, Franklin Meng fmeng2...@yahoo.com wrote:
 Unfortunately, I do not know the difference.  I thought it might be to do 
 something to the tuner but I am not quite sure.  If I remember correctly, the 
 traces that I obtained also showed a difference between the analog modes.  I 
 do know that if I leave the bit on it does not cause any adverse affects 
 (other than maybe more power is being drawn)..

If there is no difference, it might make sense to just pick one.  If
you could measure the power draw though, you might gain some insight
regarding the difference.

 I might try leaving the GPIO pin high..  I had lots of issues switching 
 between analog and digital modes so changing this bit may cause one or the 
 other to not work.  For example if I leave both pins for the SAA/EM202 and 
 the demod high, the analog doesn't seem to work correctly.  I'm guessing that 
 there probably isn't enough power to keep both devices operational.  I'll try 
 it out some more to see what happens.

You would obviously need to retest.  The cases where having the
digital GPIO do an actual reset were exposed when performing multiple
tuning attempts without closing the DVB device in between attempts.

 As far as I can tell, the Kworld 315U is the only board that uses this 
 combination of parts..  Thomson tuner, LG demod, and SAA7113.  I don't think 
 any other device has used the SAA7113 together with a digital demod.  Most 
 products seem to only have the SAA711X on an analog only board.  Since I 
 don't have any other USB adapters with the SAA chip I was unable to do any 
 further testing on the SAA code changes.

I'm more worried about it interfering with other devices that use some
other bridge, regardless of whether that device has a demodulator.
Implementing power management on any chip is likely to expose bugs in
neighboring components like the bridge.


 Did you actually do any power analysis to confirm that the
 suspend
 functionality is working properly?

 Humm.. I did not actually do this.  Though, maybe I can figure this out by 
 seeing how much power draw is on the USB bus.  I don't recall if there is a 
 way to figure this out or not from within Linux.  I do remember Windows 
 having such a feature..  I probably need to do a comparison between both OS's 
 to make sure I get things are correct..  Is there a way to get information on 
 how much power draw is happening on the USB bus in Linux?

I don't trust the operating system when it comes to that sort of
thing.  I cut up an old USB cable and put an ammeter in-line.  Has
helped alot in finding all sorts of power management bugs both in
drivers and in the v4l-dvb core.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: go7007 driver -- which program you use for capture

2010-01-14 Thread TJ

Mauro Carvalho Chehab wrote:
 It should be against -hg or linux-next tree, otherwise, I can't send it 
 upstream.
 If you just want to send a patch for people to test, please mark it as RFC, 
 otherwise
 I'll assume that you're sending a patch for upstream.
 
 Since there are more people working on this driver, the better is to add what 
 you
 have there, to avoid people to do a similar work.

OK my brother. I got a hold of the -hg tree and started working off of it.

Pete, Question: I was looking through the code and noticed that you turned s2250
driver into v4l2_subdev and go7007 driver initializes it as such and passes it
calls via call_all (v4l2_device_call_until_err). How does that affect other
drivers? Does that mean they all need to re-written as v4l2_subdev?

-TJ

--
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: go7007 driver -- which program you use for capture

2010-01-14 Thread Pete Eberlein
On Thu, 2010-01-14 at 15:03 -0500, TJ wrote:

 Pete, Question: I was looking through the code and noticed that you turned 
 s2250
 driver into v4l2_subdev and go7007 driver initializes it as such and passes it
 calls via call_all (v4l2_device_call_until_err). How does that affect other
 drivers? Does that mean they all need to re-written as v4l2_subdev?

That is correct.  The other drivers do not work until they are all
converted to the subdev interface.  I'm working on the other drivers
now.  I've finished ov7640 and have started on saa7113.

Once the subdev driver conversions are completed, we should be able to
move the go7007 driver out of staging.

Pete

--
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: go7007 driver -- which program you use for capture

2010-01-14 Thread TJ


Pete Eberlein wrote:
 On Thu, 2010-01-14 at 15:03 -0500, TJ wrote:
 
 Pete, Question: I was looking through the code and noticed that you turned 
 s2250
 driver into v4l2_subdev and go7007 driver initializes it as such and passes 
 it
 calls via call_all (v4l2_device_call_until_err). How does that affect other
 drivers? Does that mean they all need to re-written as v4l2_subdev?
 
 That is correct.  The other drivers do not work until they are all
 converted to the subdev interface.  I'm working on the other drivers
 now.  I've finished ov7640 and have started on saa7113.
 
 Once the subdev driver conversions are completed, we should be able to
 move the go7007 driver out of staging.
 
 Pete
 

Cool man. I will start working on tw9903 and tw9906, as this is my main area of
interest. Is there a template for subdev driver or should I just use your s2250
as an example? -TJ
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2010-01-14 Thread Németh Márton
Hans Verkuil wrote:
 Detailed results are available here:
 
 http://www.xs4all.nl/~hverkuil/logs/Thursday.log

 linux-2.6.32-i686: ERRORS

 /marune/build/v4l-dvb-master/v4l/cx23888-ir.c: In function 
 'cx23888_ir_irq_handler':  CC [M]  
 /marune/build/v4l-dvb-master/v4l/cx23885-f300.o

 /marune/build/v4l-dvb-master/v4l/cx23888-ir.c:621: error: implicit 
 declaration of function 'kfifo_in_locked'
 /marune/build/v4l-dvb-master/v4l/cx23888-ir.c: In function 
 'cx23888_ir_rx_read':
 /marune/build/v4l-dvb-master/v4l/cx23888-ir.c:688: error: implicit 
 declaration of function 'kfifo_out_locked'
 /marune/build/v4l-dvb-master/v4l/cx23888-ir.c: In function 'cx23888_ir_probe':
 /marune/build/v4l-dvb-master/v4l/cx23888-ir.c:1243: warning: passing argument 
 1 of 'kfifo_alloc' makes integer from pointer without a cast
 include/linux/kfifo.h:37: note: expected 'unsigned int' but argument is of 
 type 'struct kfifo *'
 /marune/build/v4l-dvb-master/v4l/cx23888-ir.c:1243: warning: passing argument 
 3 of 'kfifo_alloc' makes pointer from integer without a cast
 include/linux/kfifo.h:37: note: expected 'struct spinlock_t *' but argument 
 is of type 'unsigned int'
 make[3]: *** [/marune/build/v4l-dvb-master/v4l/cx23888-ir.o] Error 1
 make[3]: *** Waiting for unfinished jobs
 make[2]: *** [_module_/marune/build/v4l-dvb-master/v4l] Error 2
 make[2]: Leaving directory `/marune/build/trees/i686/linux-2.6.32'
 make[1]: *** [default] Error 2
 make[1]: Leaving directory `/marune/build/v4l-dvb-master/v4l'
 make: *** [all] Error 2

As I can see in the include/linux/kfifo.h ( 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=include/linux/kfifo.h
 )
there is renaming of
 - kfifo_put into kfifo_in_locked
 - kfifo_get into kfifo_out_locked

Possible solutions would be:

 a) disable the compiling of cx23888-ir.c before 2.6.33

 b) adding something like this to v4l/compat.h:

#if LINUX_VERSION_CODE  KERNEL_VERSION(2, 6, 33)
#define kfifo_in_locked kfifo_put
#define kfifo_out_locked kfifo_get
#endif

What do you think the best way would be?

Regards,

Márton Németh
--
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 - v4 1/4] V4L - vpfe_capture-remove clock and platform code

2010-01-14 Thread Kevin Hilman
Karicheri, Muralidharan m-kariche...@ti.com writes:

 Mauro,

 Please merge this patches if there are no more comments.

 Kevin,

 Could you work with Mauro to merge the arch part as required?


This version looks good with me.

I'll assume that these are targed for 2.6.34, not 2.6.33-rc fixes window.

These appear to be able at least compile independently, so as soon as
Mauro/Hans sign-off on them, I wi add PATCH 4/4 to davinci-next so
it will be queued for 2.6.34 and be a part of linux-next.  

Mauro can queue patches 1-3 in his queue for 2.6.34.  They will both
be in linux-next for testing.

Also, I can *temporarily* add patches 1-3 to davinci git so davinci git
will have them all while waiting for 2.6.34 merge window.  I will then
drop them when Mauro's tree merges upstream.

Kevin

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

-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, January 13, 2010 6:27 PM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com; mche...@infradead.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Karicheri, Muralidharan
Subject: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform code

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

Following changes are done in this patch:-
  1) removed the platform code and clk configuration. They are now
   part of ccdc driver (part of the ccdc patches and platform
patches 2-4)
  2) Added proper error codes for ccdc register function

Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl

Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Rebased to latest linux-next tree of v4l-dvb
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated comments
against v1 of these patches.

 drivers/media/video/davinci/vpfe_capture.c |  131 +++-

 1 files changed, 13 insertions(+), 118 deletions(-)

diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
  int vpfe_probed;
  /* name of ccdc device */
  char name[32];
- /* for storing mem maps for CCDC */
- int ccdc_addr_size;
- void *__iomem ccdc_addr;
 };

 /* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
  BUG_ON(!dev-hw_ops.set_image_window);
  BUG_ON(!dev-hw_ops.get_image_window);
  BUG_ON(!dev-hw_ops.get_line_length);
- BUG_ON(!dev-hw_ops.setfbaddr);
  BUG_ON(!dev-hw_ops.getfid);

  mutex_lock(ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
   * walk through it during vpfe probe
   */
  printk(KERN_ERR vpfe capture not initialized\n);
- ret = -1;
+ ret = -EFAULT;
  goto unlock;
  }

  if (strcmp(dev-name, ccdc_cfg-name)) {
  /* ignore this ccdc */
- ret = -1;
+ ret = -EINVAL;
  goto unlock;
  }

  if (ccdc_dev) {
  printk(KERN_ERR ccdc already registered\n);
- ret = -1;
+ ret = -EINVAL;
  goto unlock;
  }

  ccdc_dev = dev;
- dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
-   ccdc_cfg-ccdc_addr_size);
 unlock:
  mutex_unlock(ccdc_lock);
  return ret;
@@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
  return vpfe_dev;
 }

-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
- struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
- clk_disable(vpfe_cfg-vpssclk);
- clk_put(vpfe_cfg-vpssclk);
- clk_disable(vpfe_cfg-slaveclk);
- clk_put(vpfe_cfg-slaveclk);
- v4l2_info(vpfe_dev-pdev-driver,
-  vpfe vpss master  slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
- struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
- int ret = -ENOENT;
-
- vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
- if (NULL == vpfe_cfg-vpssclk) {
- v4l2_err(vpfe_dev-pdev-driver, No clock defined for
-  vpss_master\n);
- return ret;
- }
-
- if (clk_enable(vpfe_cfg-vpssclk)) {
- v4l2_err(vpfe_dev-pdev-driver,
- vpfe vpss master clock not enabled\n);
- goto out;
- }
- v4l2_info(vpfe_dev-pdev-driver,
-  vpfe vpss master clock enabled\n);
-
- vpfe_cfg-slaveclk = clk_get(vpfe_dev-pdev, 

RE: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform code

2010-01-14 Thread Karicheri, Muralidharan

-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, January 14, 2010 3:48 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; hverk...@xs4all.nl; mche...@infradead.org;
davinci-linux-open-sou...@linux.davincidsp.com
Subject: Re: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code

Karicheri, Muralidharan m-kariche...@ti.com writes:

 Mauro,

 Please merge this patches if there are no more comments.

 Kevin,

 Could you work with Mauro to merge the arch part as required?


This version looks good with me.

I'll assume that these are targed for 2.6.34, not 2.6.33-rc fixes window.

That is correct.


These appear to be able at least compile independently, so as soon as
Mauro/Hans sign-off on them, I wi add PATCH 4/4 to davinci-next so
it will be queued for 2.6.34 and be a part of linux-next.

Thanks.
Murali
Mauro can queue patches 1-3 in his queue for 2.6.34.  They will both
be in linux-next for testing.

Also, I can *temporarily* add patches 1-3 to davinci git so davinci git
will have them all while waiting for 2.6.34 merge window.  I will then
drop them when Mauro's tree merges upstream.

Kevin

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

-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, January 13, 2010 6:27 PM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com; mche...@infradead.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Karicheri,
Muralidharan
Subject: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code

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

Following changes are done in this patch:-
 1) removed the platform code and clk configuration. They are now
   part of ccdc driver (part of the ccdc patches and platform
patches 2-4)
 2) Added proper error codes for ccdc register function

Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl

Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Rebased to latest linux-next tree of v4l-dvb
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated
comments
against v1 of these patches.

 drivers/media/video/davinci/vpfe_capture.c |  131 +++---
--

 1 files changed, 13 insertions(+), 118 deletions(-)

diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
 int vpfe_probed;
 /* name of ccdc device */
 char name[32];
-/* for storing mem maps for CCDC */
-int ccdc_addr_size;
-void *__iomem ccdc_addr;
 };

 /* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
 BUG_ON(!dev-hw_ops.set_image_window);
 BUG_ON(!dev-hw_ops.get_image_window);
 BUG_ON(!dev-hw_ops.get_line_length);
-BUG_ON(!dev-hw_ops.setfbaddr);
 BUG_ON(!dev-hw_ops.getfid);

 mutex_lock(ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
  * walk through it during vpfe probe
  */
 printk(KERN_ERR vpfe capture not initialized\n);
-ret = -1;
+ret = -EFAULT;
 goto unlock;
 }

 if (strcmp(dev-name, ccdc_cfg-name)) {
 /* ignore this ccdc */
-ret = -1;
+ret = -EINVAL;
 goto unlock;
 }

 if (ccdc_dev) {
 printk(KERN_ERR ccdc already registered\n);
-ret = -1;
+ret = -EINVAL;
 goto unlock;
 }

 ccdc_dev = dev;
-dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
-  ccdc_cfg-ccdc_addr_size);
 unlock:
 mutex_unlock(ccdc_lock);
 return ret;
@@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
 return vpfe_dev;
 }

-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
-clk_disable(vpfe_cfg-vpssclk);
-clk_put(vpfe_cfg-vpssclk);
-clk_disable(vpfe_cfg-slaveclk);
-clk_put(vpfe_cfg-slaveclk);
-v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master  slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-int ret = -ENOENT;
-
-vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
-if (NULL == vpfe_cfg-vpssclk) {
-v4l2_err(vpfe_dev-pdev-driver, No clock defined for
- vpss_master\n);
-

RE: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform code

2010-01-14 Thread Karicheri, Muralidharan
Mauro,

Could you add patches 1-3 to linux-next ASAP?

See the response from Kevin for the arch part.

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

-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, January 14, 2010 3:48 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; hverk...@xs4all.nl; mche...@infradead.org;
davinci-linux-open-sou...@linux.davincidsp.com
Subject: Re: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code

Karicheri, Muralidharan m-kariche...@ti.com writes:

 Mauro,

 Please merge this patches if there are no more comments.

 Kevin,

 Could you work with Mauro to merge the arch part as required?


This version looks good with me.

I'll assume that these are targed for 2.6.34, not 2.6.33-rc fixes window.

These appear to be able at least compile independently, so as soon as
Mauro/Hans sign-off on them, I wi add PATCH 4/4 to davinci-next so
it will be queued for 2.6.34 and be a part of linux-next.

Mauro can queue patches 1-3 in his queue for 2.6.34.  They will both
be in linux-next for testing.

Also, I can *temporarily* add patches 1-3 to davinci git so davinci git
will have them all while waiting for 2.6.34 merge window.  I will then
drop them when Mauro's tree merges upstream.

Kevin

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

-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, January 13, 2010 6:27 PM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com; mche...@infradead.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Karicheri,
Muralidharan
Subject: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code

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

Following changes are done in this patch:-
 1) removed the platform code and clk configuration. They are now
   part of ccdc driver (part of the ccdc patches and platform
patches 2-4)
 2) Added proper error codes for ccdc register function

Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl

Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Rebased to latest linux-next tree of v4l-dvb
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated
comments
against v1 of these patches.

 drivers/media/video/davinci/vpfe_capture.c |  131 +++---
--

 1 files changed, 13 insertions(+), 118 deletions(-)

diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
 int vpfe_probed;
 /* name of ccdc device */
 char name[32];
-/* for storing mem maps for CCDC */
-int ccdc_addr_size;
-void *__iomem ccdc_addr;
 };

 /* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
 BUG_ON(!dev-hw_ops.set_image_window);
 BUG_ON(!dev-hw_ops.get_image_window);
 BUG_ON(!dev-hw_ops.get_line_length);
-BUG_ON(!dev-hw_ops.setfbaddr);
 BUG_ON(!dev-hw_ops.getfid);

 mutex_lock(ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
  * walk through it during vpfe probe
  */
 printk(KERN_ERR vpfe capture not initialized\n);
-ret = -1;
+ret = -EFAULT;
 goto unlock;
 }

 if (strcmp(dev-name, ccdc_cfg-name)) {
 /* ignore this ccdc */
-ret = -1;
+ret = -EINVAL;
 goto unlock;
 }

 if (ccdc_dev) {
 printk(KERN_ERR ccdc already registered\n);
-ret = -1;
+ret = -EINVAL;
 goto unlock;
 }

 ccdc_dev = dev;
-dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
-  ccdc_cfg-ccdc_addr_size);
 unlock:
 mutex_unlock(ccdc_lock);
 return ret;
@@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
 return vpfe_dev;
 }

-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
-clk_disable(vpfe_cfg-vpssclk);
-clk_put(vpfe_cfg-vpssclk);
-clk_disable(vpfe_cfg-slaveclk);
-clk_put(vpfe_cfg-slaveclk);
-v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master  slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-int ret = -ENOENT;
-
-

Re: Kworld 315U and SAA7113?

2010-01-14 Thread CityK
Franklin Meng wrote:
 As far as I can tell, the Kworld 315U is the only board that uses this 
 combination of parts..  Thomson tuner, LG demod, and SAA7113.  I don't think 
 any other device has used the SAA7113 together with a digital demod.  Most 
 products seem to only have the SAA711X on an analog only board.  Since I 
 don't have any other USB adapters with the SAA chip I was unable to do any 
 further testing on the SAA code changes.  
   

IIRC, a couple of the Sasem/OnAir devices use a saa7113 together with a
digital demod. I seem to also recall something else, though maybe I'm
mistaken.
--
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: Kworld 315U and SAA7113?

2010-01-14 Thread Devin Heitmueller
On Thu, Jan 14, 2010 at 5:00 PM, CityK ci...@rogers.com wrote:
 Franklin Meng wrote:
 As far as I can tell, the Kworld 315U is the only board that uses this 
 combination of parts..  Thomson tuner, LG demod, and SAA7113.  I don't think 
 any other device has used the SAA7113 together with a digital demod.  Most 
 products seem to only have the SAA711X on an analog only board.  Since I 
 don't have any other USB adapters with the SAA chip I was unable to do any 
 further testing on the SAA code changes.


 IIRC, a couple of the Sasem/OnAir devices use a saa7113 together with a
 digital demod. I seem to also recall something else, though maybe I'm
 mistaken.

I'm actually not really concerned about it's interaction with a demod.
 I'm more worried about other products that have saa711[345] that use
a bridge other than em28xx.  The introduction of power management
could always expose bugs in those bridges (I had this problem in
several different cases where I had to fix problems in other drivers
because of the introduction of power management).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: omap34xxcam question?

2010-01-14 Thread Aguirre, Sergio


 -Original Message-
 From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org]
 Sent: Thursday, January 14, 2010 11:39 AM
 To: Aguirre, Sergio
 Cc: linux-media@vger.kernel.org
 Subject: Re: omap34xxcam question?
 
 Aguirre, Sergio wrote:
 
  -Original Message-
  From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org]
  Sent: Thursday, January 14, 2010 11:25 AM
  To: Aguirre, Sergio
  Cc: linux-media@vger.kernel.org
  Subject: Re: omap34xxcam question?
 
  Hi,
 
  Aguirre, Sergio wrote:
  -Original Message-
  From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org]
  Sent: Thursday, January 14, 2010 6:01 AM
  To: linux-media@vger.kernel.org
  Cc: Aguirre, Sergio
  Subject: omap34xxcam question?
 
  Hi
 
  Is ok that it try only the first format and size? why does it not
  continue
  and find a matching?
  Actually, that was the intention, but I guess it was badly
 implemented.
 
  Thanks for the catch, and the contribution!
 
  Regards,
  Sergio
  @@ -470,7 +471,7 @@ static int try_pix_parm(struct
 omap34xxcam_videodev
  *vdev,
  pix_tmp_out = *wanted_pix_out;
  rval = isp_try_fmt_cap(isp, pix_tmp_in,
  pix_tmp_out);
  if (rval)
  -   return rval;
  +   continue;
 
  Is the patch good? or you are going to provide a better fix
 
  Yes. Sorry if I wasn't clear enough.
 
  Looks good to me, and I don't have a better fix on top of my head for
 the moment...
 
  I'm assuming you tested it in your environment, right?
 
 Ok, my enviroment is not pretty stable but for sure this is required.
 There is one problem:
 
 Suppose that the camera support this format:
 
 YUV and RAW10
 
 The video4linux enumeration is done in this order.
 We know that if you want to use resizer and previewer we can't use the YUV
 (go straight to memory)
 but it is selected because is the first. So maybe the best thing is to
 find the one that is suggest in the csi
 configuration first. Hope that is clear.

Hmm.. I see.

So, if I got you right, you're saying that, there should be priorities for 
sensor baseformats, depending on the preference specified somewhere in the 
boardfile?

Regards,
Sergio
 
 Michael
 
 
  If yes, then I'll take the patch in my queue for submission to Sakari's
 tree.
 
  Thanks for your time.
 
  Regards,
  Sergio
 
  Michael
 
  Michael
  --
  To unsubscribe from this list: send the line unsubscribe linux-media
  in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 
  --
  To unsubscribe from this list: send the line unsubscribe linux-media
 in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

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


Re: FM radio problem with HVR1120

2010-01-14 Thread ftape-jlc
Hello,
I didn't received any answer.
Did anyone used Hauppauge card with v4l2 in recent kernel to listen FM radio ?

I am not current user of the mailing list. Please confirm if it is right place 
for this problem.

Regards,

ftape-jlc


Le lundi 11 janvier 2010, ftape-jlc a écrit :
 Hello,
 
 I am user of Huappuage HVR1120, and I have problem with radio FM use in
  linux mode.
 
 Distribution OpenSuse11.2
 Kernel 2.6.31.8-0.1-desktop
 Firmware dvb-fe-tda10048-1.0.fw loaded
 
 Analog and Digital Television are OK in both Windows and Linux.
 Windows is using Hauppauge WinTV7 v7.027313
 
 Linux is using Kaffeine v1.0-pre2 for Digital Television
 Linux is using mplayer for analog TV like:
 mplayer tv:// -tv driver=v4l2:freq=495.750:norm=SECAM-
 L:input=0:audiorate=32000:immediatemode=0:alsa:forceaudio:adevice=hw.1,0:wi
 dth=720:height=576:amode=1
 
 The problem is to listen radio.
 One radio station is OK at 91.5MHz stereo using WintTV7 in Windows.
 With Linux, the command used is
 /usr/bin/radio -c /dev/radio0
 in association with
 sox -t ossdsp -r 32000 -c 2 /dev/dsp1 -t ossdsp /dev/dsp
 to listen the sound.
 
 The result is an unstable frecuency. The station is not tuned. Stereo is
 permanently switching to mono.
 The 91.5MHz station is mixed permanently with other stations.
 
 How can I check v4l2 ?
 Do you need dmesg output ?
 Is this mailing list the right place to solve this problem ?
 
 Thank you for your help.
 
 Regards,
 
 ftape-jlc
 
 
 --
 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: [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb-misc

2010-01-14 Thread Andy Walls
On Sun, 2010-01-10 at 11:52 -0200, Mauro Carvalho Chehab wrote:
 Andy Walls wrote:
  On Sun, 2010-01-10 at 09:35 -0200, Mauro Carvalho Chehab wrote:
  Andy Walls wrote:
  Mauro,
 
  If no one has any objections, please pull from
 
   http://linuxtv.org/hg/~awalls/v4l-dvb-misc
 
  for the following 12 changesets.
 
  Of note:
  02-04 are from Jean Delvare and fix up the cx23885 i2c routines
  05-17 and 12 add and use a new v4l2_subdev core op for configuring I/O 
  pin muxes
  08-10 are some minor cx23885 ir fixes noted when trying to get the TeVii 
  S470 working
 
  10/12: cx23885: Convert from struct card_ir to struct cx23885_ir_input 
  for IR Rx
  http://linuxtv.org/hg/~awalls/v4l-dvb-misc?cmd=changeset;node=aa62944baa92
  Hmm... This doesn't sound right:
 
  +struct cx23885_ir_input {
  +   struct input_dev*dev;
  +   struct ir_input_state   ir;
  +   charname[48];
  +   charphys[48];
  +
  +   /* Cooked code processing */
  +   int start;   /* Allowed start symbols */
  +   u32 addr;/* Expected remote address */
  +   u32 last_code;   /* last good cooked code seen 
  */
  +   int key_timeout; /* ms until we force a key up 
  */
  +   struct timer_list   timer_keyup; /* timer for key release */
  +
  +   /* Raw code collection and construction */
  +   int active; /* building code */
  +   int last_bit;   /* last bit seen */
  +   u32 code;   /* code under construction */
  +};
 
  Why are you creating a name[] and phys[] chars here? It should be using 
  the names already
  defined at struct input_dev.
  
  Well two reasons:
  
  1. That's what the previous, common card ir struct did.  (Not a good
  reason of course.)  When I needed to reimplement specific fields (in
  anticipation of NEC decoding for the TeVii S470) I just carried them
  over.
  
  2. The strings in the old card ir struct were too short: the card names
  in cx23885-cards.c are pretty long and would get truncated.
  
  
  I'll reexamine if the strings in input_dev are long enough to do the
  job, and get back to you.
 
 The better is to rely on input_dev stuff, since they can easily be used by 
 ir-core
 sysfs to provide device naming for loading keytables from userspace during 
 udev
 handling.

OK, I don't see struct input_dev providing any storage for name and phys
strings.  From vanilla-2.6.31-rc8/include/linux/input.h:

struct input_dev {
const char *name;
const char *phys;
[...]


and vanilla-2.6.31-rc8/drivers/input/input.c:input_register_device()
doesn't do any allocation.  In fact it spits out useless default strings
like Unspecified device if input_dev-name is NULL.

Also vanilla-2.6.31-rc8/drivers/input/input.c:input_devices_seq_show(),
doesn't print any useful information if they are not set:

seq_printf(seq, N: Name=\%s\\n, dev-name ? dev-name : );
seq_printf(seq, P: Phys=%s\n, dev-phys ? dev-phys : );

So I don't see where the input layer is providing anything: storage
space nor automatic string generation.


Some of the V4L drivers use struct card_ir from
linux/include/media/ir-common.h:

struct card_ir {
struct input_dev*dev;
struct ir_input_state   ir;
charname[32];
charphys[32];
[...]

which has string storage that is too small for the card names in
cx23885-cards.c and also has a group of fields that don't make a lot of
sense for the RC-5 and NEC decoding state machines I've implemented.

In fact linux/drivers/media/video/cx88/cx88-input.c uses it's own struct
cx88_IR instead of card_IR:

struct cx88_IR {
struct cx88_core *core;
struct input_dev *input;
struct ir_input_state ir;
char name[32];
char phys[32];
[...]


So what is it you want me to do with this change?  I don't know what
storage space for strings you want me to reuse. 

Regards,
Andy

 Cheers,
 Mauro.
 

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


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

2010-01-14 Thread Laurent Pinchart
Hi Németh,

On Thursday 14 January 2010 21:22:44 Németh Márton wrote:
 Hans Verkuil wrote:
  Detailed results are available here:
 
  http://www.xs4all.nl/~hverkuil/logs/Thursday.log
 
  linux-2.6.32-i686: ERRORS
 
  /marune/build/v4l-dvb-master/v4l/cx23888-ir.c: In function
  'cx23888_ir_irq_handler':  CC [M] 
  /marune/build/v4l-dvb-master/v4l/cx23885-f300.o
 
  /marune/build/v4l-dvb-master/v4l/cx23888-ir.c:621: error: implicit
  declaration of function 'kfifo_in_locked'
  /marune/build/v4l-dvb-master/v4l/cx23888-ir.c: In function
  'cx23888_ir_rx_read': /marune/build/v4l-dvb-master/v4l/cx23888-ir.c:688:
  error: implicit declaration of function 'kfifo_out_locked'
  /marune/build/v4l-dvb-master/v4l/cx23888-ir.c: In function
  'cx23888_ir_probe': /marune/build/v4l-dvb-master/v4l/cx23888-ir.c:1243:
  warning: passing argument 1 of 'kfifo_alloc' makes integer from pointer
  without a cast include/linux/kfifo.h:37: note: expected 'unsigned int'
  but argument is of type 'struct kfifo *'
  /marune/build/v4l-dvb-master/v4l/cx23888-ir.c:1243: warning: passing
  argument 3 of 'kfifo_alloc' makes pointer from integer without a cast
  include/linux/kfifo.h:37: note: expected 'struct spinlock_t *' but
  argument is of type 'unsigned int' make[3]: ***
  [/marune/build/v4l-dvb-master/v4l/cx23888-ir.o] Error 1 make[3]: ***
  Waiting for unfinished jobs
  make[2]: *** [_module_/marune/build/v4l-dvb-master/v4l] Error 2
  make[2]: Leaving directory `/marune/build/trees/i686/linux-2.6.32'
  make[1]: *** [default] Error 2
  make[1]: Leaving directory `/marune/build/v4l-dvb-master/v4l'
  make: *** [all] Error 2
 
 As I can see in the include/linux/kfifo.h (
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history
 ;f=include/linux/kfifo.h ) there is renaming of
  - kfifo_put into kfifo_in_locked
  - kfifo_get into kfifo_out_locked
 
 Possible solutions would be:
 
  a) disable the compiling of cx23888-ir.c before 2.6.33
 
  b) adding something like this to v4l/compat.h:
 
 #if LINUX_VERSION_CODE  KERNEL_VERSION(2, 6, 33)
 #define kfifo_in_locked kfifo_put
 #define kfifo_out_locked kfifo_get
 #endif

I don't think that would be enough. The kfifo API has changed quite a lot in 
2.6.33. It will be difficult to handle that solely through compat.h. 
Conditional compilation based on the kernel version would probably be needed 
in the cx23888 driver itself.

-- 
Regards,

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


Re: Kworld 315U and SAA7113?

2010-01-14 Thread Franklin Meng
Actually I was a bit short sighted here.  I was referring to devices in the 
em28xx tree.  

In the case of the SAA7113 device, there really is no power saving feature 
unless a hardware pin is pulled down (or up I don't remember).  The pin will 
basically reset the device.  

From my testing it seems like the power on defaults don't fully enable the 
device which is why I added the reinitialization to the s_power routine.  

Thanks,
Franklin Meng

--- On Thu, 1/14/10, Devin Heitmueller dheitmuel...@kernellabs.com wrote:

 From: Devin Heitmueller dheitmuel...@kernellabs.com
 Subject: Re: Kworld 315U and SAA7113?
 To: CityK ci...@rogers.com
 Cc: Franklin Meng fmeng2...@yahoo.com, linux-media@vger.kernel.org
 Date: Thursday, January 14, 2010, 2:09 PM
 On Thu, Jan 14, 2010 at 5:00 PM,
 CityK ci...@rogers.com
 wrote:
  Franklin Meng wrote:
  As far as I can tell, the Kworld 315U is the only
 board that uses this combination of parts..  Thomson tuner,
 LG demod, and SAA7113.  I don't think any other device has
 used the SAA7113 together with a digital demod.  Most
 products seem to only have the SAA711X on an analog only
 board.  Since I don't have any other USB adapters with the
 SAA chip I was unable to do any further testing on the SAA
 code changes.
 
 
  IIRC, a couple of the Sasem/OnAir devices use a
 saa7113 together with a
  digital demod. I seem to also recall something else,
 though maybe I'm
  mistaken.
 
 I'm actually not really concerned about it's interaction
 with a demod.
  I'm more worried about other products that have
 saa711[345] that use
 a bridge other than em28xx.  The introduction of power
 management
 could always expose bugs in those bridges (I had this
 problem in
 several different cases where I had to fix problems in
 other drivers
 because of the introduction of power management).
 
 Devin
 
 -- 
 Devin J. Heitmueller - Kernel Labs
 http://www.kernellabs.com
 --
 To unsubscribe from this list: send the line unsubscribe
 linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 


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