Re: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan-22fix
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 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
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
Hi, On Thu, Jan 14, 2010 at 11:35 AM, Michael Qiu 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
> Hi, > > > On Thu, Jan 14, 2010 at 11:35 AM, Michael Qiu 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
Hi Hans,
On Thu, Jan 14, 2010 at 1:25 PM, Hans Verkuil wrote:
>
>> Hi,
>>
>>
>> On Thu, Jan 14, 2010 at 11:35 AM, Michael Qiu 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 ?
static inline int DestroyOSDWindow(struct av7110 *av7110, u8 windownr)
{
return av7110_fw_cmd(av7110, COMTYPE_OSD, WDestroy, 1, windownr);
}
static inline int CreateOSDWindow(struct av7110 *av7110, u8 windownr,
osd_raw_window_t disptype,
u16 width, u16 height)
{
return av7110_fw_cmd(av7110, COMTYPE_OSD, WCreate, 4,
windownr, disptype, width, height);
}
static enum av7110_osd_palette_type bpp2pal[8] = {
Pal1Bit, Pal2Bit, 0, Pal4Bit, 0, 0, 0, Pal8Bit
};
static osd_raw_window_t bpp2bit[8] = {
OSD_BITMAP1, OSD_BITMAP2, 0, OSD_BITMAP4, 0, 0, 0, OSD_BITMAP8
};
static inline int WaitUntilBmpLoaded(struct av7110 *av7110)
{
int ret = wait_event_timeout(av7110->bmpq,
av7110->bmp_state != BMP_LOADING, 10*HZ);
if (ret == 0) {
printk("dvb-ttpci: warning: timeout waiting in LoadBitmap: %d,
%d\n",
ret, av7110->bmp_state);
av7110->bmp_state = BMP_NONE;
return -ETIMEDOUT;
}
return 0;
}
static inline int LoadBitmap(struct av7110 *av7110,
u16 dx, u16 dy, int inc, u8 __user * data)
{
u16 format;
int bpp;
int i;
int d, delta;
u8 c;
int ret;
dprintk(4, "%p\n", av7110);
format = bpp2bit[av7110->osdbpp[av7110->osdwin]];
av7110->bmp_state = BMP_LOADING;
if (format == OSD_BITMAP8) {
bpp=8; delta = 1;
} else if (format == OSD_BITMAP4) {
bpp=4; delta = 2;
} else if (format == OSD_BITMAP2) {
bpp=2; delta = 4;
} else if (format == OSD_BITMAP1) {
bpp=1; delta = 8;
} else {
av7110->bmp_state = BMP_NONE;
return -EINVAL;
}
av71
Re: About driver architecture
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 : > 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
On Thu, Jan 14, 2010 at 1:47 PM, Michael Qiu 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
Hi Manu, 2010/1/14 Manu Abraham : > 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
On Thu, Jan 14, 2010 at 2:06 PM, HoP wrote: > Hi Manu, > > 2010/1/14 Manu Abraham : >> 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
> Hi Hans, > > On Thu, Jan 14, 2010 at 1:25 PM, Hans Verkuil wrote: >> >>> Hi, >>> >>> >>> On Thu, Jan 14, 2010 at 11:35 AM, Michael Qiu >>> 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
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 : > Hi, > > > On Thu, Jan 14, 2010 at 11:35 AM, Michael Qiu 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
> 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 : >> 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 develope
Re: About driver architecture
> 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. This is the same problem that also affects e.g. the Texas Instruments omap3 SoC. What is missing is a high-level controller device. To start with, take a look at this presentation: http://www.xs4all.nl/~hverkuil/presentations/jls2009-v4l2.pdf The key concept is that of a media controller. Work is in progress to prototype it for omap3. RFCs have been posted on this as well. Regards, Hans > > > > 2010/1/14 Manu Abraham : >> Hi, >> >> >> On Thu, Jan 14, 2010 at 11:35 AM, Michael Qiu >> 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 > -- 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.o
Re: About driver architecture
On Thu, Jan 14, 2010 at 2:19 PM, Michael Qiu 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
On Thu, Jan 14, 2010 at 2:17 PM, Hans Verkuil wrote: > >> Hi Hans, >> >> On Thu, Jan 14, 2010 at 1:25 PM, Hans Verkuil wrote: >>> Hi, On Thu, Jan 14, 2010 at 11:35 AM, Michael Qiu 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
> 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
On Thu, Jan 14, 2010 at 2:44 PM, HoP wrote: >> 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. Yes, I am aware of it. > 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. Yes indeed, it will sometime soon. Have been expecting things to move for around > 18 months now. 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
On Thu, Jan 14, 2010 at 2:19 PM, Michael Qiu 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
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?
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
Hi Javier, On 1/14/10, javier Martin 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
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
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 NetUP Inc. signature.asc Description: This is a digitally signed message part
Re: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan-22fix
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 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()
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 --- 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
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
On Thu, Jan 14, 2010 at 10:35 AM, Andreas Besse 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
Devin Heitmueller wrote: > On Thu, Jan 14, 2010 at 10:35 AM, Andreas Besse 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
On Thu, Jan 14, 2010 at 11:01 AM, Andreas Besse 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
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 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?
> -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
On Thu, Jan 14, 2010 at 11:09 AM, Devin Heitmueller wrote: > On Thu, Jan 14, 2010 at 11:01 AM, Andreas Besse 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?
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
Devin Heitmueller a écrit : > On Wed, Jan 13, 2010 at 3:32 AM, xof wrote: > >> Are you sure? (it is an Ubuntu-only issue) >> >> I can see several >> >>> #include >>> >> in the v4l tree that compile fine on Ubuntu >> but only linux/drivers/media/dvb/firewire/firedtv-1394.c contains >> >>> #include >>> >> 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?
> -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?
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
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?
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 wrote:
> From: Mauro Carvalho Chehab
> Subject: Re: Kworld 315U and SAA7113?
> To: "Franklin Meng"
> 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},
>
>
> > };
>
>
>
>
>
> >
>
Re: Kworld 315U and SAA7113?
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
This patch fix try_pix_parm loop that try to find a suitable format for the isp engine Signed-off-by: Michael Trimarchi Cc: akari Ailus Cc: Sergio Aguirre --- 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
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
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?
On Thu, Jan 14, 2010 at 1:54 PM, Franklin Meng 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
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
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
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
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
"Karicheri, Muralidharan" 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
>>
>>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
>>Reviewed-by: Kevin Hilman
>>Reviewed-by: Hans Verkuil
>>
>>Signed-off-by: Hans Verkuil
>>Signed-off-by: Muralidharan Karicheri
>>---
>>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");
>>-
RE: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform code
>-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" 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
>>>
>>>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
>>>Reviewed-by: Kevin Hilman
>>>Reviewed-by: Hans Verkuil
>>>
>>>Signed-off-by: Hans Verkuil
>>>Signed-off-by: Muralidharan Karicheri
>>>---
>>>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_con
RE: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform code
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" 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
>>>
>>>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
>>>Reviewed-by: Kevin Hilman
>>>Reviewed-by: Hans Verkuil
>>>
>>>Signed-off-by: Hans Verkuil
>>>Signed-off-by: Muralidharan Karicheri
>>>---
>>>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);
>>>-
Re: Kworld 315U and SAA7113?
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?
On Thu, Jan 14, 2010 at 5:00 PM, CityK 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?
> -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
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
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
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?
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 wrote: > From: Devin Heitmueller > Subject: Re: Kworld 315U and SAA7113? > To: "CityK" > Cc: "Franklin Meng" , linux-media@vger.kernel.org > Date: Thursday, January 14, 2010, 2:09 PM > On Thu, Jan 14, 2010 at 5:00 PM, > CityK > 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
