Re: Re: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
2012-04-28 10:57:19 nibble@gmail.com >Antti, Mauro, > >i believe we're all on the same page here and i just want to summarize >based on all the discussion so far and if we all agree: > >1) ds3000 and ts2020 code split, there are already several strong >arguments about it and most of all that it turned out there is >reference design with 3rd party tuner that works both with ds3000 and >stv090x demodulators. i will take care of this task > Montage demodulator has worked with Sharp 6306 CAN tuner for several years. I suggest to put the dvb-s/s2 initialize constant data of ds3000 to the seperate files. As i patch ds3103, it has also dvb-s/s2 initialize datas. It will make ds3000 file too long and ugly to review. As i do in the try patch placing them into ds3000_priv.h. >2) the result of 1) would be that the following DVB-S2 tuner and >demodulator drivers will be able to work in any combination of each >other (assuming there is such hardware design available): stb0899*, >stv090x*, ds3000, stv6110x*, stb6100* and ts2020. that's good, because >it starts to put order, because those are significant part of the >DVB-S2 drivers in the kernel > >3) not only, because of 2), but in general it's not clear why there is >stv6110.* driver, which is for the exact same silicone as stv6110x*, >as well stv0900*, which is for the same family of chips as stv090x*. i >can help a little here to the degree that i can make all bridge >drivers depend on stv6110x* and stv090x* except the driver for one >card made by NetUP - there i can just do it in theory, but i can't >test and probably break support for it > >4) after 1), 2) and if 3) is resolved the only DVB-S2 drivers that >will continue to be married to one particular tuner (CX24118A) that >will left are cx24116 and tda10071, which for the time being will be >left that way until basically there is someone that volunteers to make >separate CX24118A driver based on the LG, SHARP and Comtech datasheets >that are available in the public domain, for which i gave details in a >previous email, and which in my opinion contain sufficient information >that task to be made > >5) ds3103 and ts2022 support, done in form of a patch respectively to >ds3000 driver and ts2020 driver or if ts2022 happens to be very >different than ts2020 then ts2022 support be made as separate driver, >i guess Max will take this > FYI,We have approval from Montage to let us use its reference code under GPLv2 lincense. But to their surprise, they review ds3000.c and find the tuner and demod config part almost same as their reference code. They have not agree anybody to public their code under GPLv2 before. They doubt that ds3000.c public is breaking their NDA without their permission. >6) if it's necessary bug fixes, improvements, etc to the shared code >between ds3000 and ds3103, but only after review, discussion and >argumentation why those changes are actually needed > >On Fri, Apr 27, 2012 at 11:42 PM, Antti Palosaari wrote: >> On 27.04.2012 23:21, Konstantin Dimitrov wrote: >>> >>> On Fri, Apr 27, 2012 at 10:55 PM, Antti Palosaari wrote: On 27.04.2012 22:01, Konstantin Dimitrov wrote: > > > Mauro, your reasoning makes sense to me. so, let's split them and at > least settle this part of the discussion - i will do as far as my > spare time allows, as well make sure there are no some problems > introduced after the split. > > also, in one email i've just sent in answer to Antti there is enough > argument why such split, i.e. tuner-pass-through-mode is subject to > discussion about CX24116 and TDA10071 drivers too. currently, majority > of DVB-S2 demodulator drivers in the kernel are married to particular > tuners and there is no split. I read the mail and as it was long study, I comment only that CX24116+CX24118A and TDA10071+CX24118A demod+tuner combos versus Montage demod+tuner combos. As you may see, CX24116 and TDA10071 are so much different than both needs own driver. But as you said those are married always as a demod+tuner. So if I use your logic, what happens if CX24118A tuner is not driven by CX24116 or TDA10071 firmware? ==> it happens we have two drivers, CX24116 and TDA10071 *both* having similar CX24118A tuner driver code inside! Same tuner driver code inside two demods drivers. Could you now understand why we want it split? The reason which saves us having CX24118A tuner driver is that it is inside both CX24116 and TDA10071 firmware. There is mainly two different controlling situation. Most commonly driver controls chip but in some cases it is firmware which is controlling. And I don't see it very important trying always to by-pass firmware control and use driver for that. >>> >>> i got that point, but what happens if tomorrow their is CX24116 or >>> TDA10071 design with tuner different than CX
Re: [PATCH v3] [media] s5p-g2d: Add support for FIMG2D v4.1 H/W logic
Hi Kamil,
Any comments on the below patch?
Regards
Sachin
On 24 April 2012 16:08, Sachin Kamat wrote:
> From: Ajay Kumar
>
> Modify the G2D driver(which initially supported only FIMG2D v3 style H/W)
> to support FIMG2D v4.1 style hardware present on Exynos4x12 and Exynos52x0
> SOC.
>
> -- Set the SRC and DST type to 'memory' instead of using reset values.
> -- FIMG2D v4.1 H/W uses different logic for stretching(scaling).
> -- Use CACHECTL_REG only with FIMG2D v3.
>
> Signed-off-by: Ajay Kumar
> Signed-off-by: Sachin Kamat
> ---
> drivers/media/video/s5p-g2d/g2d-hw.c | 17 +
> drivers/media/video/s5p-g2d/g2d-regs.h | 6 ++
> drivers/media/video/s5p-g2d/g2d.c | 23 +--
> drivers/media/video/s5p-g2d/g2d.h | 9 -
> 4 files changed, 48 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/video/s5p-g2d/g2d-hw.c
> b/drivers/media/video/s5p-g2d/g2d-hw.c
> index 5b86cbe..8c8bf71 100644
> --- a/drivers/media/video/s5p-g2d/g2d-hw.c
> +++ b/drivers/media/video/s5p-g2d/g2d-hw.c
> @@ -28,6 +28,8 @@ void g2d_set_src_size(struct g2d_dev *d, struct g2d_frame
> *f)
> {
> u32 n;
>
> + w(0, SRC_SELECT_REG);
> +
> w(f->stride & 0x, SRC_STRIDE_REG);
>
> n = f->o_height & 0xFFF;
> @@ -52,6 +54,8 @@ void g2d_set_dst_size(struct g2d_dev *d, struct g2d_frame
> *f)
> {
> u32 n;
>
> + w(0, DST_SELECT_REG);
> +
> w(f->stride & 0x, DST_STRIDE_REG);
>
> n = f->o_height & 0xFFF;
> @@ -82,10 +86,14 @@ void g2d_set_flip(struct g2d_dev *d, u32 r)
> w(r, SRC_MSK_DIRECT_REG);
> }
>
> -u32 g2d_cmd_stretch(u32 e)
> +void g2d_set_v41_stretch(struct g2d_dev *d, struct g2d_frame *src,
> + struct g2d_frame *dst)
> {
> - e &= 1;
> - return e << 4;
> + w(DEFAULT_SCALE_MODE, SRC_SCALE_CTRL_REG);
> +
> + /* inversed scaling factor: src is numerator */
> + w((src->c_width << 16) / dst->c_width, SRC_XSCALE_REG);
> + w((src->c_height << 16) / dst->c_height, SRC_YSCALE_REG);
> }
>
> void g2d_set_cmd(struct g2d_dev *d, u32 c)
> @@ -96,7 +104,8 @@ void g2d_set_cmd(struct g2d_dev *d, u32 c)
> void g2d_start(struct g2d_dev *d)
> {
> /* Clear cache */
> - w(0x7, CACHECTL_REG);
> + if (d->device_type == TYPE_G2D_3X)
> + w(0x7, CACHECTL_REG);
> /* Enable interrupt */
> w(1, INTEN_REG);
> /* Start G2D engine */
> diff --git a/drivers/media/video/s5p-g2d/g2d-regs.h
> b/drivers/media/video/s5p-g2d/g2d-regs.h
> index 02e1cf5..14c681f 100644
> --- a/drivers/media/video/s5p-g2d/g2d-regs.h
> +++ b/drivers/media/video/s5p-g2d/g2d-regs.h
> @@ -35,6 +35,9 @@
> #define SRC_COLOR_MODE_REG 0x030C /* Src Image Color Mode reg */
> #define SRC_LEFT_TOP_REG 0x0310 /* Src Left Top Coordinate reg */
> #define SRC_RIGHT_BOTTOM_REG 0x0314 /* Src Right Bottom Coordinate reg */
> +#define SRC_SCALE_CTRL_REG 0x0328 /* Src Scaling type select */
> +#define SRC_XSCALE_REG 0x032c /* Src X Scaling ratio */
> +#define SRC_YSCALE_REG 0x0330 /* Src Y Scaling ratio */
>
> /* Parameter Setting Registers (Dest) */
> #define DST_SELECT_REG 0x0400 /* Dest Image Selection reg */
> @@ -112,4 +115,7 @@
>
> #define DEFAULT_WIDTH 100
> #define DEFAULT_HEIGHT 100
> +#define DEFAULT_SCALE_MODE (2 << 0)
>
> +/* Command mode register values */
> +#define CMD_V3_ENABLE_STRETCH (1 << 4)
> diff --git a/drivers/media/video/s5p-g2d/g2d.c
> b/drivers/media/video/s5p-g2d/g2d.c
> index 789de74..8924f7e 100644
> --- a/drivers/media/video/s5p-g2d/g2d.c
> +++ b/drivers/media/video/s5p-g2d/g2d.c
> @@ -582,8 +582,13 @@ static void device_run(void *prv)
> g2d_set_flip(dev, ctx->flip);
>
> if (ctx->in.c_width != ctx->out.c_width ||
> - ctx->in.c_height != ctx->out.c_height)
> - cmd |= g2d_cmd_stretch(1);
> + ctx->in.c_height != ctx->out.c_height) {
> + if (dev->device_type == TYPE_G2D_3X)
> + cmd |= CMD_V3_ENABLE_STRETCH;
> + else
> + g2d_set_v41_stretch(dev, &ctx->in, &ctx->out);
> + }
> +
> g2d_set_cmd(dev, cmd);
> g2d_start(dev);
>
> @@ -783,6 +788,8 @@ static int g2d_probe(struct platform_device *pdev)
>
> def_frame.stride = (def_frame.width * def_frame.fmt->depth) >> 3;
>
> + dev->device_type = platform_get_device_id(pdev)->driver_data;
> +
> return 0;
>
> unreg_video_dev:
> @@ -832,9 +839,21 @@ static int g2d_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static struct platform_device_id g2d_driver_ids[] = {
> + {
> + .name = "s5p-g2d",
> + .driver_data = TYPE_G2D_3X,
> + }, {
> + .name = "s5p-g2d41x",
> + .driver_data = TYPE_G2D_41X,
> + }, { },
>
[GIT PULL FOR v3.5] radio-mr800: complete update to the latest frameworks
This patch series makes the radio-mr800 compliant with the latest V4L2 frameworks and adds stereo/signalstrength detection and hw seek support. Tested fairly thoroughly, including whether suspend/resume works. Regards, Hans The following changes since commit bcb2cf6e0bf033d79821c89e5ccb328bfbd44907: [media] ngene: remove an unneeded condition (2012-04-26 15:29:23 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git mr800 for you to fetch changes up to 0719a2b4b3bd29579fc4c62de0d995eadb74af79: radio-mr800: add hardware seek support. (2012-04-27 23:39:37 +0200) Hans Verkuil (3): radio-mr800: cleanup and have it comply to the V4L2 API. radio-mr800: add support for stereo and signal detection. radio-mr800: add hardware seek support. drivers/media/radio/radio-mr800.c | 524 +- 1 file changed, 234 insertions(+), 290 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
Antti, Mauro, i believe we're all on the same page here and i just want to summarize based on all the discussion so far and if we all agree: 1) ds3000 and ts2020 code split, there are already several strong arguments about it and most of all that it turned out there is reference design with 3rd party tuner that works both with ds3000 and stv090x demodulators. i will take care of this task 2) the result of 1) would be that the following DVB-S2 tuner and demodulator drivers will be able to work in any combination of each other (assuming there is such hardware design available): stb0899*, stv090x*, ds3000, stv6110x*, stb6100* and ts2020. that's good, because it starts to put order, because those are significant part of the DVB-S2 drivers in the kernel 3) not only, because of 2), but in general it's not clear why there is stv6110.* driver, which is for the exact same silicone as stv6110x*, as well stv0900*, which is for the same family of chips as stv090x*. i can help a little here to the degree that i can make all bridge drivers depend on stv6110x* and stv090x* except the driver for one card made by NetUP - there i can just do it in theory, but i can't test and probably break support for it 4) after 1), 2) and if 3) is resolved the only DVB-S2 drivers that will continue to be married to one particular tuner (CX24118A) that will left are cx24116 and tda10071, which for the time being will be left that way until basically there is someone that volunteers to make separate CX24118A driver based on the LG, SHARP and Comtech datasheets that are available in the public domain, for which i gave details in a previous email, and which in my opinion contain sufficient information that task to be made 5) ds3103 and ts2022 support, done in form of a patch respectively to ds3000 driver and ts2020 driver or if ts2022 happens to be very different than ts2020 then ts2022 support be made as separate driver, i guess Max will take this 6) if it's necessary bug fixes, improvements, etc to the shared code between ds3000 and ds3103, but only after review, discussion and argumentation why those changes are actually needed On Fri, Apr 27, 2012 at 11:42 PM, Antti Palosaari wrote: > On 27.04.2012 23:21, Konstantin Dimitrov wrote: >> >> On Fri, Apr 27, 2012 at 10:55 PM, Antti Palosaari wrote: >>> >>> On 27.04.2012 22:01, Konstantin Dimitrov wrote: Mauro, your reasoning makes sense to me. so, let's split them and at least settle this part of the discussion - i will do as far as my spare time allows, as well make sure there are no some problems introduced after the split. also, in one email i've just sent in answer to Antti there is enough argument why such split, i.e. tuner-pass-through-mode is subject to discussion about CX24116 and TDA10071 drivers too. currently, majority of DVB-S2 demodulator drivers in the kernel are married to particular tuners and there is no split. >>> >>> >>> >>> I read the mail and as it was long study, I comment only that >>> CX24116+CX24118A and TDA10071+CX24118A demod+tuner combos versus Montage >>> demod+tuner combos. As you may see, CX24116 and TDA10071 are so much >>> different than both needs own driver. But as you said those are married >>> always as a demod+tuner. >>> >>> So if I use your logic, what happens if CX24118A tuner is not driven by >>> CX24116 or TDA10071 firmware? ==> it happens we have two drivers, >>> CX24116 >>> and TDA10071 *both* having similar CX24118A tuner driver code inside! >>> Same >>> tuner driver code inside two demods drivers. Could you now understand why >>> we >>> want it split? >>> The reason which saves us having CX24118A tuner driver is that it is >>> inside >>> both CX24116 and TDA10071 firmware. >>> >>> There is mainly two different controlling situation. Most commonly driver >>> controls chip but in some cases it is firmware which is controlling. And >>> I >>> don't see it very important trying always to by-pass firmware control and >>> use driver for that. >>> >> >> i got that point, but what happens if tomorrow their is CX24116 or >> TDA10071 design with tuner different than CX14118A? in fact the LG >> datasheet i pointed out to you clearly states that for example there >> is actually such design - case when CX24116 is used with CX24128 tuner >> instead CX24118A in which case the only way is to bypass the firmware >> and control the tuner directly. also, isn't it even double bad the >> current state of CX24116 or TDA10071 drivers - from one side they use >> 2 firmwares, part of which is doing the same, i.e control the CX24118A >> and from the other side they depend on proprietary firmware to do >> something that can be done in open-source code? i don't know, but at >> least from my point of view if that's not worse than the current >> status of ds3000 driver, it's at least as wrong as it, i.e. there >> isn't not only separation of tuner and demodulator code in CX24116 or >> TDA10071 drivers, but t
Re: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
On Fri, Apr 27, 2012 at 11:54 PM, Antti Palosaari wrote: > On 27.04.2012 23:40, Konstantin Dimitrov wrote: >> >> On Fri, Apr 27, 2012 at 11:37 PM, Konstantin Dimitrov >>> >>> however, i want to pointed out few other problems - they are off-topic >>> >>> as not related to drivers for Montage chips, but related as far as >>> we're putting some order and making things in a proper way and those >>> those things are out of that order: >>> >>> - there are 2 drivers for the same DVB-S2 tuner: ST 6110, respectively >>> "stv6110.c" and "stv6110x.c" >>> >>> - there are 2 drivers for the same DVB-S2 demodulator family: >>> respectively stv090x* and stv0900* >>> >>> the above couldn't be more wrong - in fact i can submit patches to >>> make all drivers that relies on stv090x* and "stv6110.c" to use >>> stv090x* and "stv6110x.c" instead except the NetUP board, for which in >> >> >>> my opinion someone should submit patches using stv090x* and >>> "stv6110x.c" and subsequently stv090x* and "stv6110.c" be removed - >> >> >> to correct a typo: and subsequently stv0900* and "stv6110.c" be removed >> >>> unless someone have some real argument why stv090x* and "stv6110.c" >> >> >> the same: unless someone have some real argument why stv0900* and >> "stv6110.c" >> >>> should stay or even if for why they should replace stv090x* and >>> "stv6110x.c" and subsequently stv090x* and "stv6110x.c" be removed >>> instead. so, the case with ST 6110 and STV090x support is the most >>> frustrating and out of order thing that i can indicate regarding the >>> support of DVB-S2 chips in the kernel and i hope you will take care as >>> maintainer to be resolved or at least someone to explain why the >>> current state is like that - or point me out to explanation if such >>> was already made to the mailing list. so, what i'm suggesting is >>> "spring cleaning" of all DVB-S2 tuner/demodulator drivers in the >>> kernel - if it's not done now in the future the mess will only >>> increase. > > > That stv090x stuff is discussed many times earlier too. It is mistake done > for the some reasons. In theory there should be only one driver per > chip/logical entity but for the non-technical reason it was failed. And as > it is failed at the very first try it is hard to correct later. > OK, what about i commit to correct it to the degree i can? that degree is : patch all bridge drivers to use stv090x* and stv6110x* except the driver for the NetUP card since i don't have any similar hardware, which i can use for testing and remove the less mature and less versatile drivers involved in the mess, i.e. stv6110.* and stv0900*. until the NetUP don't submit patch to utilize stv090x* and stv6110x* their card will be left in unsupported stage - at least that way 99% of the mess will be cleaned and subsequently the whole mess, because i guess someone with NetUP hardware will contribute what i can't do. > > regards > Antti > -- > http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
On 27.04.2012 23:40, Konstantin Dimitrov wrote: On Fri, Apr 27, 2012 at 11:37 PM, Konstantin Dimitrov however, i want to pointed out few other problems - they are off-topic as not related to drivers for Montage chips, but related as far as we're putting some order and making things in a proper way and those those things are out of that order: - there are 2 drivers for the same DVB-S2 tuner: ST 6110, respectively "stv6110.c" and "stv6110x.c" - there are 2 drivers for the same DVB-S2 demodulator family: respectively stv090x* and stv0900* the above couldn't be more wrong - in fact i can submit patches to make all drivers that relies on stv090x* and "stv6110.c" to use stv090x* and "stv6110x.c" instead except the NetUP board, for which in my opinion someone should submit patches using stv090x* and "stv6110x.c" and subsequently stv090x* and "stv6110.c" be removed - to correct a typo: and subsequently stv0900* and "stv6110.c" be removed unless someone have some real argument why stv090x* and "stv6110.c" the same: unless someone have some real argument why stv0900* and "stv6110.c" should stay or even if for why they should replace stv090x* and "stv6110x.c" and subsequently stv090x* and "stv6110x.c" be removed instead. so, the case with ST 6110 and STV090x support is the most frustrating and out of order thing that i can indicate regarding the support of DVB-S2 chips in the kernel and i hope you will take care as maintainer to be resolved or at least someone to explain why the current state is like that - or point me out to explanation if such was already made to the mailing list. so, what i'm suggesting is "spring cleaning" of all DVB-S2 tuner/demodulator drivers in the kernel - if it's not done now in the future the mess will only increase. That stv090x stuff is discussed many times earlier too. It is mistake done for the some reasons. In theory there should be only one driver per chip/logical entity but for the non-technical reason it was failed. And as it is failed at the very first try it is hard to correct later. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
On 27.04.2012 23:21, Konstantin Dimitrov wrote: On Fri, Apr 27, 2012 at 10:55 PM, Antti Palosaari wrote: On 27.04.2012 22:01, Konstantin Dimitrov wrote: Mauro, your reasoning makes sense to me. so, let's split them and at least settle this part of the discussion - i will do as far as my spare time allows, as well make sure there are no some problems introduced after the split. also, in one email i've just sent in answer to Antti there is enough argument why such split, i.e. tuner-pass-through-mode is subject to discussion about CX24116 and TDA10071 drivers too. currently, majority of DVB-S2 demodulator drivers in the kernel are married to particular tuners and there is no split. I read the mail and as it was long study, I comment only that CX24116+CX24118A and TDA10071+CX24118A demod+tuner combos versus Montage demod+tuner combos. As you may see, CX24116 and TDA10071 are so much different than both needs own driver. But as you said those are married always as a demod+tuner. So if I use your logic, what happens if CX24118A tuner is not driven by CX24116 or TDA10071 firmware? ==> it happens we have two drivers, CX24116 and TDA10071 *both* having similar CX24118A tuner driver code inside! Same tuner driver code inside two demods drivers. Could you now understand why we want it split? The reason which saves us having CX24118A tuner driver is that it is inside both CX24116 and TDA10071 firmware. There is mainly two different controlling situation. Most commonly driver controls chip but in some cases it is firmware which is controlling. And I don't see it very important trying always to by-pass firmware control and use driver for that. i got that point, but what happens if tomorrow their is CX24116 or TDA10071 design with tuner different than CX14118A? in fact the LG datasheet i pointed out to you clearly states that for example there is actually such design - case when CX24116 is used with CX24128 tuner instead CX24118A in which case the only way is to bypass the firmware and control the tuner directly. also, isn't it even double bad the current state of CX24116 or TDA10071 drivers - from one side they use 2 firmwares, part of which is doing the same, i.e control the CX24118A and from the other side they depend on proprietary firmware to do something that can be done in open-source code? i don't know, but at least from my point of view if that's not worse than the current status of ds3000 driver, it's at least as wrong as it, i.e. there isn't not only separation of tuner and demodulator code in CX24116 or TDA10071 drivers, but there is not even a code that can allow they to be separated easily, because making CX14118A driver from scratch is task that will need some effort. anyway, maybe, it's just me, but i prefer to depend as less as possible on proprietary firmwares done is such way. however, there is no any doubt current CX24116 or TDA10071 drivers don't allow any other tuner that is not supported by the proprietary firmware to be used and thus they break the rule of tuner and demodulator code separation. so, i really don't understand what makes CX24116 or TDA10071 drivers different than the others, i.e. why they are developed in such way and there is no discussion about them to be changed in way that allow use of other tuner like CX24128, which is not supported by the proprietary firmwares. so, the only explanation from my perspective is lack of such need in real-life, but it's the same for ds3000. In case of new device having CX24116 or TDA10071, but different tuner than firmware controlled CX14118A, driver must be changed to support new configuration. Or even make new driver if differences are too big. I suspect implementing new .set_frontend() callback is almost everything what is needed. Then add configuration option .tuner_controlled_by_firmware or something like that. There is likely rather similar existing cases. IIRC someone mentioned AF9035/AF9033 firmwares have different versions for different tuners. Also AF9015 uploads firmware to AF9013 demod, external or internal. Still AF9013 driver could upload firmware independently. There is many kind of cases chip/firmware can control other chips. And if you look AF9015/AF9013 and AF9035/AF9033 drivers you can see some examples of splitting drivers even those are many times integrated together. OK, that AF90xx stuff goes to DVB-T side but it is good example of splitting drivers and supporting very wide set of demod/tuner combinations. And it is nice you found CX24116 is sold by two different tuners :) If those tuners are controlled by the driver we can see similar mess than ds3000 + ts2020 or ts2022. At the some point handling different tuner drivers inside one demod driver goes difficult - errors can be done easily and maintaining goes hard. 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 maj
Re: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
On Fri, Apr 27, 2012 at 11:37 PM, Konstantin Dimitrov wrote: > hi Mauro, > > in the mean time i was actually pointed out that there is 3rd party > tuner that is proved to work in practice with both Montage ds3k > demodulator family, as well ST STV090x demods, i.e. there are such > reference designs. so, the split further makes sense and in fact that > should be make in way that both drivers for STV090x and Montage ds3k > demodulator family can share tuners with each other. so, that's just > note for the upcoming review of the patches i will submit - in short > the split of Montage tuner and demodulator code i will make it in the > same fashion as how the driver code for ST 6100/6110 tuner are split > from STV090x driver, because that now, as i've just mentioned, makes > sense from practical point of view since of the 3rd party tuner for > which there is reference designs with both STV090x and Montage > demodulator. also, that way STB0899, STV090x and Montage demodulator > drivers can be used together with any other of the DVB-S2 tuners > available in the kernel - ST 6100 and 6110 and soon TS2020. > > however, i want to pointed out few other problems - they are off-topic > as not related to drivers for Montage chips, but related as far as > we're putting some order and making things in a proper way and those > those things are out of that order: > > - there are 2 drivers for the same DVB-S2 tuner: ST 6110, respectively > "stv6110.c" and "stv6110x.c" > > - there are 2 drivers for the same DVB-S2 demodulator family: > respectively stv090x* and stv0900* > > the above couldn't be more wrong - in fact i can submit patches to > make all drivers that relies on stv090x* and "stv6110.c" to use > stv090x* and "stv6110x.c" instead except the NetUP board, for which in > my opinion someone should submit patches using stv090x* and > "stv6110x.c" and subsequently stv090x* and "stv6110.c" be removed - to correct a typo: and subsequently stv0900* and "stv6110.c" be removed > unless someone have some real argument why stv090x* and "stv6110.c" the same: unless someone have some real argument why stv0900* and "stv6110.c" > should stay or even if for why they should replace stv090x* and > "stv6110x.c" and subsequently stv090x* and "stv6110x.c" be removed > instead. so, the case with ST 6110 and STV090x support is the most > frustrating and out of order thing that i can indicate regarding the > support of DVB-S2 chips in the kernel and i hope you will take care as > maintainer to be resolved or at least someone to explain why the > current state is like that - or point me out to explanation if such > was already made to the mailing list. so, what i'm suggesting is > "spring cleaning" of all DVB-S2 tuner/demodulator drivers in the > kernel - if it's not done now in the future the mess will only > increase. > > thank you, > konstantin > > On Fri, Apr 27, 2012 at 10:36 PM, Mauro Carvalho Chehab > wrote: >> Hi Konstantin, >> >> Em 27-04-2012 16:01, Konstantin Dimitrov escreveu: >>> Mauro, your reasoning makes sense to me. so, let's split them and at >>> least settle this part of the discussion - i will do as far as my >>> spare time allows, as well make sure there are no some problems >>> introduced after the split. >> >> Thank you! >> >>> also, in one email i've just sent in answer to Antti there is enough >>> argument why such split, i.e. tuner-pass-through-mode is subject to >>> discussion about CX24116 and TDA10071 drivers too. currently, majority >>> of DVB-S2 demodulator drivers in the kernel are married to particular >>> tuners and there is no split. >> >> Besides the reasoning I gave you, having the tuner and the demod on separate >> drivers help a lot code reviewers to check what's happening inside the code, >> because the code on each driver becomes more coincide and the two different >> functions become more decoupled, with reduces the code complexity. So, bugs >> tend to be reduced and they're easier to fix, especially when someone need >> to fix bad things at the dvb core. >> >> Also, as almost all drivers are like that, it is easier to identify driver >> patterns, especially when newer patches are adding extra functionality there. >> >> Thanks! >> 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: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
hi Mauro, in the mean time i was actually pointed out that there is 3rd party tuner that is proved to work in practice with both Montage ds3k demodulator family, as well ST STV090x demods, i.e. there are such reference designs. so, the split further makes sense and in fact that should be make in way that both drivers for STV090x and Montage ds3k demodulator family can share tuners with each other. so, that's just note for the upcoming review of the patches i will submit - in short the split of Montage tuner and demodulator code i will make it in the same fashion as how the driver code for ST 6100/6110 tuner are split from STV090x driver, because that now, as i've just mentioned, makes sense from practical point of view since of the 3rd party tuner for which there is reference designs with both STV090x and Montage demodulator. also, that way STB0899, STV090x and Montage demodulator drivers can be used together with any other of the DVB-S2 tuners available in the kernel - ST 6100 and 6110 and soon TS2020. however, i want to pointed out few other problems - they are off-topic as not related to drivers for Montage chips, but related as far as we're putting some order and making things in a proper way and those those things are out of that order: - there are 2 drivers for the same DVB-S2 tuner: ST 6110, respectively "stv6110.c" and "stv6110x.c" - there are 2 drivers for the same DVB-S2 demodulator family: respectively stv090x* and stv0900* the above couldn't be more wrong - in fact i can submit patches to make all drivers that relies on stv090x* and "stv6110.c" to use stv090x* and "stv6110x.c" instead except the NetUP board, for which in my opinion someone should submit patches using stv090x* and "stv6110x.c" and subsequently stv090x* and "stv6110.c" be removed - unless someone have some real argument why stv090x* and "stv6110.c" should stay or even if for why they should replace stv090x* and "stv6110x.c" and subsequently stv090x* and "stv6110x.c" be removed instead. so, the case with ST 6110 and STV090x support is the most frustrating and out of order thing that i can indicate regarding the support of DVB-S2 chips in the kernel and i hope you will take care as maintainer to be resolved or at least someone to explain why the current state is like that - or point me out to explanation if such was already made to the mailing list. so, what i'm suggesting is "spring cleaning" of all DVB-S2 tuner/demodulator drivers in the kernel - if it's not done now in the future the mess will only increase. thank you, konstantin On Fri, Apr 27, 2012 at 10:36 PM, Mauro Carvalho Chehab wrote: > Hi Konstantin, > > Em 27-04-2012 16:01, Konstantin Dimitrov escreveu: >> Mauro, your reasoning makes sense to me. so, let's split them and at >> least settle this part of the discussion - i will do as far as my >> spare time allows, as well make sure there are no some problems >> introduced after the split. > > Thank you! > >> also, in one email i've just sent in answer to Antti there is enough >> argument why such split, i.e. tuner-pass-through-mode is subject to >> discussion about CX24116 and TDA10071 drivers too. currently, majority >> of DVB-S2 demodulator drivers in the kernel are married to particular >> tuners and there is no split. > > Besides the reasoning I gave you, having the tuner and the demod on separate > drivers help a lot code reviewers to check what's happening inside the code, > because the code on each driver becomes more coincide and the two different > functions become more decoupled, with reduces the code complexity. So, bugs > tend to be reduced and they're easier to fix, especially when someone need > to fix bad things at the dvb core. > > Also, as almost all drivers are like that, it is easier to identify driver > patterns, especially when newer patches are adding extra functionality there. > > Thanks! > 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: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
On Fri, Apr 27, 2012 at 10:55 PM, Antti Palosaari wrote: > On 27.04.2012 22:01, Konstantin Dimitrov wrote: >> >> Mauro, your reasoning makes sense to me. so, let's split them and at >> least settle this part of the discussion - i will do as far as my >> spare time allows, as well make sure there are no some problems >> introduced after the split. >> >> also, in one email i've just sent in answer to Antti there is enough >> argument why such split, i.e. tuner-pass-through-mode is subject to >> discussion about CX24116 and TDA10071 drivers too. currently, majority >> of DVB-S2 demodulator drivers in the kernel are married to particular >> tuners and there is no split. > > > I read the mail and as it was long study, I comment only that > CX24116+CX24118A and TDA10071+CX24118A demod+tuner combos versus Montage > demod+tuner combos. As you may see, CX24116 and TDA10071 are so much > different than both needs own driver. But as you said those are married > always as a demod+tuner. > > So if I use your logic, what happens if CX24118A tuner is not driven by > CX24116 or TDA10071 firmware? ==> it happens we have two drivers, CX24116 > and TDA10071 *both* having similar CX24118A tuner driver code inside! Same > tuner driver code inside two demods drivers. Could you now understand why we > want it split? > The reason which saves us having CX24118A tuner driver is that it is inside > both CX24116 and TDA10071 firmware. > > There is mainly two different controlling situation. Most commonly driver > controls chip but in some cases it is firmware which is controlling. And I > don't see it very important trying always to by-pass firmware control and > use driver for that. > i got that point, but what happens if tomorrow their is CX24116 or TDA10071 design with tuner different than CX14118A? in fact the LG datasheet i pointed out to you clearly states that for example there is actually such design - case when CX24116 is used with CX24128 tuner instead CX24118A in which case the only way is to bypass the firmware and control the tuner directly. also, isn't it even double bad the current state of CX24116 or TDA10071 drivers - from one side they use 2 firmwares, part of which is doing the same, i.e control the CX24118A and from the other side they depend on proprietary firmware to do something that can be done in open-source code? i don't know, but at least from my point of view if that's not worse than the current status of ds3000 driver, it's at least as wrong as it, i.e. there isn't not only separation of tuner and demodulator code in CX24116 or TDA10071 drivers, but there is not even a code that can allow they to be separated easily, because making CX14118A driver from scratch is task that will need some effort. anyway, maybe, it's just me, but i prefer to depend as less as possible on proprietary firmwares done is such way. however, there is no any doubt current CX24116 or TDA10071 drivers don't allow any other tuner that is not supported by the proprietary firmware to be used and thus they break the rule of tuner and demodulator code separation. so, i really don't understand what makes CX24116 or TDA10071 drivers different than the others, i.e. why they are developed in such way and there is no discussion about them to be changed in way that allow use of other tuner like CX24128, which is not supported by the proprietary firmwares. so, the only explanation from my perspective is lack of such need in real-life, but it's the same for ds3000. > Patrick explained those few days back in the mailing list: > http://www.mail-archive.com/linux-media@vger.kernel.org/msg44814.html > > You said also we cannot know if Montage demod does some tweaking for the > tuner too. Yes true, at that point we don't know. But I think it is rather > small probability whilst driver clearly controls it. > > > regards > Antti > -- > http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
On 27.04.2012 22:01, Konstantin Dimitrov wrote: Mauro, your reasoning makes sense to me. so, let's split them and at least settle this part of the discussion - i will do as far as my spare time allows, as well make sure there are no some problems introduced after the split. also, in one email i've just sent in answer to Antti there is enough argument why such split, i.e. tuner-pass-through-mode is subject to discussion about CX24116 and TDA10071 drivers too. currently, majority of DVB-S2 demodulator drivers in the kernel are married to particular tuners and there is no split. I read the mail and as it was long study, I comment only that CX24116+CX24118A and TDA10071+CX24118A demod+tuner combos versus Montage demod+tuner combos. As you may see, CX24116 and TDA10071 are so much different than both needs own driver. But as you said those are married always as a demod+tuner. So if I use your logic, what happens if CX24118A tuner is not driven by CX24116 or TDA10071 firmware? ==> it happens we have two drivers, CX24116 and TDA10071 *both* having similar CX24118A tuner driver code inside! Same tuner driver code inside two demods drivers. Could you now understand why we want it split? The reason which saves us having CX24118A tuner driver is that it is inside both CX24116 and TDA10071 firmware. There is mainly two different controlling situation. Most commonly driver controls chip but in some cases it is firmware which is controlling. And I don't see it very important trying always to by-pass firmware control and use driver for that. Patrick explained those few days back in the mailing list: http://www.mail-archive.com/linux-media@vger.kernel.org/msg44814.html You said also we cannot know if Montage demod does some tweaking for the tuner too. Yes true, at that point we don't know. But I think it is rather small probability whilst driver clearly controls it. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
Hi Konstantin, Em 27-04-2012 16:01, Konstantin Dimitrov escreveu: > Mauro, your reasoning makes sense to me. so, let's split them and at > least settle this part of the discussion - i will do as far as my > spare time allows, as well make sure there are no some problems > introduced after the split. Thank you! > also, in one email i've just sent in answer to Antti there is enough > argument why such split, i.e. tuner-pass-through-mode is subject to > discussion about CX24116 and TDA10071 drivers too. currently, majority > of DVB-S2 demodulator drivers in the kernel are married to particular > tuners and there is no split. Besides the reasoning I gave you, having the tuner and the demod on separate drivers help a lot code reviewers to check what's happening inside the code, because the code on each driver becomes more coincide and the two different functions become more decoupled, with reduces the code complexity. So, bugs tend to be reduced and they're easier to fix, especially when someone need to fix bad things at the dvb core. Also, as almost all drivers are like that, it is easier to identify driver patterns, especially when newer patches are adding extra functionality there. Thanks! 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: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
Mauro, your reasoning makes sense to me. so, let's split them and at least settle this part of the discussion - i will do as far as my spare time allows, as well make sure there are no some problems introduced after the split. also, in one email i've just sent in answer to Antti there is enough argument why such split, i.e. tuner-pass-through-mode is subject to discussion about CX24116 and TDA10071 drivers too. currently, majority of DVB-S2 demodulator drivers in the kernel are married to particular tuners and there is no split. On Tue, Apr 24, 2012 at 12:49 AM, Mauro Carvalho Chehab wrote: > Em 23-04-2012 19:51, Konstantin Dimitrov escreveu: >> Antti, i already commented about ds3103 drivers months ago: > >> also, why Montage tuner code should be spitted from the demodulator >> code? is there any evidence that any Montage tuner (ts2020 or ts2022) >> can work with 3rd party demodulator different than ds3000 or ds3103? > > This has nothing to do with Montage devices, but with the way we write > those drivers in Kernel. > > There are _several_ examples where the driver for a single silicon were > turned into more than one driver. The biggest examples are the SoC chips, > that are transformed into a large series of drivers. > > Another example is the cx88 driver: due to technical reasons, it was splitted > into 4 drivers, one for each different PCI ID exported by it. > > The cx2341x driver is also an interesting example: while it used to be for a > separate chip, the cx2341x functions are now part of IP blocks on newer > Conexant chipsets. Those single chips require two drivers to work (cx2341x > and the associated media PCI bridge driver). > > Looking into tuners, there are the tda18271 family of devices, with are > supported by several drivers: tda827x, tda8290 and tda18271-fe, depending > on how the actual device is mounted. Eventually, the actual tuner may > also have a tda9887 inside it. > > So, there's nothing wrong on splitting it on separate drivers. In a matter of > fact, we strongly prefer to have tuners separate from demods. Having them > together can only be justified technically, if there are really strong reasons > why they should be at the same driver. > > I probably missed this at my review for ds3000 (that's why it ended by being > merged), but, on the review I did on it (accidentally due to m88ds3103 > patchset > review), it is clear that the tuner has actually a different I2C address > (0x60) > than the demod, and it is indeed a separate device. Sorry for slipping into > it. > > Anyway, now that this is noticed, tuner and demod drivers should be split, > especially since there are some patches floating around to add support for > ds3103. > > As I said before, the right thing to do is: > > 1) split ds3000 from ts2020 at the existing driver; > 2) add support for the newer chips (ds3103/ts2022) to the ds3000 and > ds3103 > drivers. > 3) test if the patches adding support for the newer chips didn't break > the > support for existing hardware. > > My proposal is that tasks (1) and (3) should be handled by you. As Max wants > to > add support for some devices based on ds3103/ts2022, IMO, he can do the > patches > for (2) in a way that they would be acceptable by you, as the driver > maintainer > for ds3000/ts2020, testing with their devices. > > Regards, > Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] m88ds3103, montage dvb-s/s2 demodulator driver
hello Antti, sorry that i wasn't able to get back to you earlier. On Tue, Apr 24, 2012 at 12:04 AM, Antti Palosaari wrote: > Hello Konstantin, > > Good to heard you and finally got your reply to thread. > > > On 23.04.2012 22:51, Konstantin Dimitrov wrote: >> >> Antti, i already commented about ds3103 drivers months ago: >> >> http://www.mail-archive.com/linux-media@vger.kernel.org/msg41135.html >> >> and from my point of view nothing have changed - ds3103 chip is almost >> the same as ds3000 and the driver i made for ds3000 from scratch is >> what was used ds3103 drivers to be created. so, what you actually is >> suggesting - my driver to be removed from the kernel and driver that >> was made based on my hard work to be included and that driver author >> even refuses to acknowledge my work?! such practices are really good >> for the open-source community, don't you think? also, we already have >> one case for example, where to satisfy someone's interests two drivers >> for the same demodulators (STV090x family of chips) were accepted in >> the kernel - i doubt anyone actually can tell why there are 2 drivers >> for STV090x in the kernel and instead the community to support the >> driver for STV090x that was made with more open-source ideas in mind, >> i.e. the one that can work with any STV090x design and which relies >> less on code copyrighted by ST - anyway, those details about STV090x >> drivers are off-topic here, but i'm still giving them as example, >> because the fact is that already once such mess was created having >> multiple drivers for the same generation of chips in the kernel and >> apparently those practices will continue if someone don't raise those >> questions out loud. >> >> also, why Montage tuner code should be spitted from the demodulator >> code? is there any evidence that any Montage tuner (ts2020 or ts2022) >> can work with 3rd party demodulator different than ds3000 or ds3103? > > > I don't know what is situation of these Montage chips and what are possible > combinations. *But* there is many existing cases from the DVB-T I am aware. > Things are done wrongly and all is implemented as a one big blob. After that > new device is arrived and we cannot support it since existing drivers are > not split. And it is not single case... > i understand your point, but i believe with DVB-T is quite different than with DVB-S2, i.e. it's very rare to mix DVB-S2 tuners and demodulators in such way how it's done with DVB-T. in fact, i'm not aware of any such mixes in real-life. also, below i will give a lot of technical details, i.e. facts about CX24116 or TDA10071 and CX24118A and then i'm sure you will understand my point why the same discussion can be made for CX24116 and TDA10071 drivers. > It may happen or it may not happen. You never known. But still it is nice to > split drivers correctly to avoid such problems that could be possible in > some day. And I don't even know how much those tuners and demods differs - I > only saw that patch and it looked there was some differences, even so much > that two tuner drivers could be good choice. > > >> are there such designs in real-life, e.g. either Montage demodulator >> with 3rd party tuner or actually more importantly for what you're >> suggesting Montage tuner (ts2020 or ts2022) with third party >> demodulator? it's more or less the same case as with cx24116 (and >> tda10071) demodulator, where the tuner (cx24118a) is controlled by the >> firmware and thus it's solely part of the demodulator driver, even >> that it's possible to control the cx24118a tuner that is used with >> cx24116 (and tda10071) designs directly bypassing the firmware. so, >> why we don't change in that way the cx24116 (and tda10071) drivers >> too? > > > CX24116 and TDA10071 (I made TDA10071) are somehow different as tuner is > driven by demodulator firmware. There is no tuner that needs to be driven by > driver at least for now. it's off-topic, but anyway i think it would be useful information to you and most of it is in the public domains anyway and thus i won't break any rules. so, you can google for: * "s2TDQR-C005F" and get the datasheet of LG NIM that consists of CX24118A + CX24116, read page 14 of it, there is figure diagram about it : in short it gives you all the details how CX24118A is connected to the CX24116 and explains that when there is no support for the tuner in CX24116 firmware then "tuner pass-through" can be used and that CX24118A also can be used with "tuner pass-through", i.e. direct control no matter that it's supported tuner in the CX24116 firmware * now google for BS2F7HZ0165 datasheet in PDF (not the product brief, the datasheet is scanned and ugly looking), which is SHARP NIM that consists of CX24118A + CX24116 and on page 6 you can get even more information and even how to program the "tuner pass-through" mode * further more you can google for MDVBS2-24116, which is NIM made by Comtech with CX24118A + CX24116 and get all CX24118A con
Re: [PATCH 1/6 v2] dvbsky, montage dvb-s/s2 TS202x tuner and M88DS3103demodulator driver
On Fri, Apr 27, 2012 at 5:35 PM, Mauro Carvalho Chehab wrote: > Em 27-04-2012 11:17, nibble.max escreveu: >> 2012-04-27 22:03:20 nibble@gmail.com >>> Em 27-04-2012 04:06, nibble.max escreveu: --- drivers/media/dvb/frontends/Kconfig | 14 + drivers/media/dvb/frontends/Makefile | 3 + drivers/media/dvb/frontends/m88ds3103.c | 1153 ++ drivers/media/dvb/frontends/m88ds3103.h | 67 ++ drivers/media/dvb/frontends/m88ds3103_priv.h | 413 + drivers/media/dvb/frontends/m88ts202x.c | 590 + drivers/media/dvb/frontends/m88ts202x.h | 63 ++ 7 files changed, 2303 insertions(+) create mode 100644 drivers/media/dvb/frontends/m88ds3103.c create mode 100644 drivers/media/dvb/frontends/m88ds3103.h create mode 100644 drivers/media/dvb/frontends/m88ds3103_priv.h create mode 100644 drivers/media/dvb/frontends/m88ts202x.c create mode 100644 drivers/media/dvb/frontends/m88ts202x.h >>> >>> No, this is not what we've agreed. You should, instead, take Konstantin's >>> driver, >>> breaking it into two separate ones, without touching the copyrights. Then, >>> apply >>> what else is needed for ds3103/ts2123. >> Hello Mauro, >> >> Should I need Konstantin's agreement to do that? > > While the driver is GPLv2, he is the author of the driver. GPL is not > copyleft. You can't simply > decide to change the copyrights. > Mauro, well said and thanks for standing up and defending the open-source. so, "m88ds3103" in it's current version is just combination of using shuffling of my "ds3000" code plus using copyrighted code by Montage Technologies - the last is even another reason why "m88ds3103" can't be accepted, because then actually Montage Technologies should be listed in the copyright and wait for their approval. let me give example what i mean - let's take ToneBurst function as example - m88ds3103_diseqc_send_burst() - at the current version of "m88ds3103" it's exactly the same code as the one from the reference code copyrighted by Montage Technologies and provided by them under NDA (i have access to that code), in the previous versions of "m88ds3103" it was the same function as mine in ds3000_diseqc_send_burs() in ds3000.c - in both cases "m88ds3103" can't be accepted. also, if you look at mine ToneBurst function ds3000_diseqc_send_burs() in ds3000.c you will see it's quite different than the one copyrighted by Montage Technologies, e.g. some of the register settings are different, etc, because i made it really from scratch - it could be even it's not better than the original settings used by the code copyrighted by Montage Technologies, but it's at least something genuine to which i came up - of course, the chip limits you in the ways how you can control it. last, but not least, just changing the condition of if-else statements (swapping it) and using do-while-loop instead for-loop is nothing more then shuffling the code. so, what i would accept: - patch against "ds3000.c" that adds ds3103 support: copyright is unchanged and instead credit for the ds3103 support is get by "history" note, example what i mean and how is the right way to be done in my opinion: === Montage Technology DS3000/TS2020 - DVBS/S2 Demodulator/Tuner driver Copyright (C) 2009 Konstantin Dimitrov Copyright (C) 2009 TurboSight.com History: April 2012: Add support for the new silicone revision ds3103 Max nibble === - any changes that don't involved ds3103 support are subject to review and argumentation why they are done, i.e. they are bug, the setting is wrong, etc. >> Using the seperate tuner and demod, I need to change the codes which use the >> ds3000 frontend. >> How can I test the code to confirm that these codes are right without these >> hardwards? > > Well, at the split patch, you shouldn't do anything but to split tuner and > demod. This will > make easier for others to test, if you don't have the hardware for testing. i haven't had time to read the emails and i'm still not sure what is the motivation to split them, because Montage tuner and demodulator are like "married couple". however, if there is really motivation about that then let's do it - i will help as far as my spare time allows and even with the testing, i.e. that nothing got broken as result of that. > > Regards, > Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How do I detect if disconnect is called due to module removal?
On Fri, Apr 27, 2012 at 07:43:50PM +0200, Hans Verkuil wrote: > Hi all, > > I'm cleaning up some USB FM radio drivers and I realized that I need to know > in the disconnect callback whether I'm called due to a module unload or due > to an unplug event. You shouldn't care. > In the first case I need to first mute the audio output of the device, in the > second case I can skip that. Why? The "mute" operation would just fail if the device isn't present, no problem. > I can just try and always mute the device but that results in a error message > in the case the device is unplugged. Then don't display that error message :) > Is there a field I can test somewhere to detect what caused the disconnect? No, sorry, you shouldn't really do anything different here the driver does not know the difference, nor should it. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Fri Apr 27 19:00:18 CEST 2012 git hash:bcb2cf6e0bf033d79821c89e5ccb328bfbd44907 gcc version: i686-linux-gcc (GCC) 4.6.3 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: OK linux-3.1-i686: OK linux-3.2.1-i686: OK linux-3.3-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] V4L: Extend V4L2_CID_COLORFX with more image effects
Hi Hans, thanks for the review! On 04/27/2012 12:12 PM, Hans Verkuil wrote: > Hi Sylwester! > > On Friday, April 27, 2012 11:52:54 Sylwester Nawrocki wrote: >> This patch adds definition of additional color effects: >> - V4L2_COLORFX_AQUA, >> - V4L2_COLORFX_ART_FREEZE, >> - V4L2_COLORFX_SILHOUETTE, >> - V4L2_COLORFX_SOLARIZATION, >> - V4L2_COLORFX_ANTIQUE, >> - V4L2_COLORFX_ARBITRARY_CBCR. >> >> The control's type in the documentation is changed from 'enum' to 'menu' >> - V4L2_CID_COLORFX has always been a menu, not an integer type control. >> >> The V4L2_COLORFX_ARBITRARY_CBCR option enables custom color effects, >> which are impossible or impractical to define as menu items. The >> V4L2_CID_BLUE_BALANCE and V4L2_CID_RED_BALANCE controls allow in this >> case to configure the Cb, Cr coefficients. > > So this just hijacks the RED/BLUE_BALANCE controls for a different purpose? Uh, the meaning is indeed a bit different. Probably not a good idea to reuse the controls like this in the standard API. > If I understand this 'effect' correctly it just replaces the Cb and Cr > coefficients with fixed values, basically giving you a B&W picture (the Y > coefficient), except that it is really a 'Black&FixedColor' picture. Yes, this is also my understanding. The TRMs are not very verbose about it, but I think it is exactly how it works. The effect is similar to looking through a coloured glass, where colour changes from green through red to violet when changing the (CR, CB) coefficients gradually from (0, 0) -> (0, 255) -> (255, 255). > I think you should add a new control for setting this. V4L2_CID_COLORFX_COLOR > or something. Do you mean something similar to V4L2_CID_BG_COLOR ? When a different colour space is used then the range for those Cb, Cr components changes. It can be 0...255 or 16...240. So best would be to have 2 controls, for reporting min/max to the user. Maybe it would be better to add a V4L2_COLORFX_COLOR menu entry and V4L2_CID_COLORFX_CB, V4L2_CID_COLORFX_CR controls ? -- Regards, Sylwester -- 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
How do I detect if disconnect is called due to module removal?
Hi all, I'm cleaning up some USB FM radio drivers and I realized that I need to know in the disconnect callback whether I'm called due to a module unload or due to an unplug event. In the first case I need to first mute the audio output of the device, in the second case I can skip that. I can just try and always mute the device but that results in a error message in the case the device is unplugged. Is there a field I can test somewhere to detect what caused the disconnect? 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: [PATCH 2/2] marvell-cam: Build fix: missing "select VIDEOBUF2_VMALLOC"
On Thu, 26 Apr 2012 16:07:51 -0400 Chris Ball wrote: > drivers/built-in.o: In function `mcam_v4l_open': > /drivers/media/video/marvell-ccic/mcam-core.c:1565: undefined reference to > `vb2_vmalloc_memops' This one is very strange. If you look at mcam-core.h, you'll see it shouldn't be trying to do anything with vmalloc unless the videobuf2 option is already configured in. I don't get this particular error, and I can't quite see how you do...? jon -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR 3.4] videobuf2 and s5p-fimc driver fixes
Hi Mauro, The following changes since commit aa6d5f29534a6d1459f9768c591a7a72aadc5941: [media] pluto2: remove some dead code (2012-04-19 17:15:32 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung v4l_fixes_for_v3.4 for you to fetch changes up to 2b083782a9ba9828488c98ce090e48b73691d07e: media: videobuf2-dma-contig: include header for exported symbols (2012-04-27 07:52:58 +0200) These are videobuf2 and s5p-fimc driver fixes. Please pull for v3.4. It would be nice to also, if possible, have this patch http://git.linuxtv.org/media_tree.git/commit/aa333122c9c7d11d7d8486db09869517995af0a8 in 3.4-rc, it's is now in branch staging/for_v3.5. H Hartley Sweeten (2): media: videobuf2-dma-contig: quiet sparse noise about plain integer as NULL pointer media: videobuf2-dma-contig: include header for exported symbols Laurent Pinchart (1): media: vb2-memops: Export vb2_get_vma symbol Sylwester Nawrocki (2): s5p-fimc: Fix locking in subdev set_crop op s5p-fimc: Correct memory allocation for VIDIOC_CREATE_BUFS drivers/media/video/s5p-fimc/fimc-capture.c | 33 + drivers/media/video/s5p-fimc/fimc-core.c|4 ++-- drivers/media/video/s5p-fimc/fimc-core.h|2 +- drivers/media/video/videobuf2-dma-contig.c |3 ++- drivers/media/video/videobuf2-memops.c |1 + 5 files changed, 27 insertions(+), 16 deletions(-) -- Regards, Sylwester -- 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 1/6 v2] dvbsky, montage dvb-s/s2 TS202x tuner and M88DS3103demodulator driver
Em 27-04-2012 11:17, nibble.max escreveu: > 2012-04-27 22:03:20 nibble@gmail.com >> Em 27-04-2012 04:06, nibble.max escreveu: >>> --- >>> drivers/media/dvb/frontends/Kconfig | 14 + >>> drivers/media/dvb/frontends/Makefile |3 + >>> drivers/media/dvb/frontends/m88ds3103.c | 1153 >>> ++ >>> drivers/media/dvb/frontends/m88ds3103.h | 67 ++ >>> drivers/media/dvb/frontends/m88ds3103_priv.h | 413 + >>> drivers/media/dvb/frontends/m88ts202x.c | 590 + >>> drivers/media/dvb/frontends/m88ts202x.h | 63 ++ >>> 7 files changed, 2303 insertions(+) >>> create mode 100644 drivers/media/dvb/frontends/m88ds3103.c >>> create mode 100644 drivers/media/dvb/frontends/m88ds3103.h >>> create mode 100644 drivers/media/dvb/frontends/m88ds3103_priv.h >>> create mode 100644 drivers/media/dvb/frontends/m88ts202x.c >>> create mode 100644 drivers/media/dvb/frontends/m88ts202x.h >> >> No, this is not what we've agreed. You should, instead, take Konstantin's >> driver, >> breaking it into two separate ones, without touching the copyrights. Then, >> apply >> what else is needed for ds3103/ts2123. > Hello Mauro, > > Should I need Konstantin's agreement to do that? While the driver is GPLv2, he is the author of the driver. GPL is not copyleft. You can't simply decide to change the copyrights. > Using the seperate tuner and demod, I need to change the codes which use the > ds3000 frontend. > How can I test the code to confirm that these codes are right without these > hardwards? Well, at the split patch, you shouldn't do anything but to split tuner and demod. This will make easier for others to test, if you don't have the hardware for testing. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v3 03/14] V4L: Add an extended camera white balance control
Hi,
Looks good!
Acked-by: Hans de Goede
Regards,
Hans
On 04/27/2012 04:23 PM, Sylwester Nawrocki wrote:
This patch adds V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE control which is
an extended version of the V4L2_CID_AUTO_WHITE_BALANCE control,
including white balance presets. The following presets are defined:
- V4L2_WHITE_BALANCE_INCANDESCENT,
- V4L2_WHITE_BALANCE_FLUORESCENT,
- V4L2_WHITE_BALANCE_FLUORESCENT_H,
- V4L2_WHITE_BALANCE_HORIZON,
- V4L2_WHITE_BALANCE_DAYLIGHT,
- V4L2_WHITE_BALANCE_FLASH,
- V4L2_WHITE_BALANCE_CLOUDY,
- V4L2_WHITE_BALANCE_SHADE.
Signed-off-by: HeungJun Kim
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/media/v4l/controls.xml | 70 ++
drivers/media/video/v4l2-ctrls.c | 17 +++
include/linux/videodev2.h| 14 ++
3 files changed, 101 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 56a53a8..b671a70 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -2948,6 +2948,76 @@ camera sensor on or off, or specify its strength. Such
band-stop filters can
be used, for example, to filter out the fluorescent light component.
+
+
+ V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE
+ enum v4l2_auto_n_preset_white_balance_type
+ Sets white balance to automatic,
+manual or a preset. The presets determine color temperature of the light as
+a hint to the camera for white balance adjustments resulting in most accurate
+color representation. The following white balance presets are listed in order
+of increasing color temperature.
+
+
+
+
+
+
V4L2_WHITE_BALANCE_MANUAL
+ Manual white balance.
+
+
+
V4L2_WHITE_BALANCE_AUTO
+ Automatic white balance adjustments.
+
+
+
V4L2_WHITE_BALANCE_INCANDESCENT
+ White balance setting for incandescent (tungsten)
lighting.
+It generally cools down the colors and corresponds approximately to
2500...3500 K
+color temperature range.
+
+
+
V4L2_WHITE_BALANCE_FLUORESCENT
+ White balance preset for fluorescent lighting.
+It corresponds approximately to 4000...5000 K color temperature.
+
+
+
V4L2_WHITE_BALANCE_FLUORESCENT_H
+ With this setting the camera will compensate for
+fluorescent H lighting.
+
+
+
V4L2_WHITE_BALANCE_HORIZON
+ White balance setting for horizon daylight.
+It corresponds approximately to 5000 K color temperature.
+
+
+
V4L2_WHITE_BALANCE_DAYLIGHT
+ White balance preset for daylight (with clear sky).
+It corresponds approximately to 5000...6500 K color temperature.
+
+
+
V4L2_WHITE_BALANCE_FLASH
+ With this setting the camera will compensate for the
flash
+light. It slightly warms up the colors and corresponds roughly to 5000...5500 K
+color temperature.
+
+
+
V4L2_WHITE_BALANCE_CLOUDY
+ White balance preset for moderately overcast sky.
+This option corresponds approximately to 6500...8000 K color temperature
+range.
+
+
+
V4L2_WHITE_BALANCE_SHADE
+ White balance preset for shade or heavily overcast
+sky. It corresponds approximately to 9000...1 K color temperature.
+
+
+
+
+
+
+
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 1d7091f..02fa9b0 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -243,6 +243,19 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Vivid",
NULL
};
+ static const char * const auto_n_preset_white_balance[] = {
+ "Manual",
+ "Auto",
+ "Incandescent",
+ "Fluorescent",
+ "Fluorescent H",
+ "Horizon",
+ "Daylight",
+ "Flash",
+ "Cloudy",
+ "Shade",
+ NULL,
+ };
static const char * const tune_preemphasis[] = {
"No Preemphasis",
"50 Microseconds",
@@ -412,6 +425,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_exposure_auto;
case V4L2_CID_COLORFX:
return colorfx;
+ case V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE:
+ return auto_n_preset_white_balance;
case V4L2_CID_TU
[PATCH/RFC v3 06/14] V4L: Add camera ISO sensitivity controls
Add ISO sensitivity and ISO auto/manual controls. The sensitivity
values are related to level of amplification of the analog signal
between image sensor and ADC. These controls allow to support sensors
exposing an interface to accept the ISO values directly.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/media/v4l/biblio.xml | 11
Documentation/DocBook/media/v4l/controls.xml | 38 ++
drivers/media/video/v4l2-ctrls.c | 10 +++
include/linux/videodev2.h|7 +
4 files changed, 66 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/biblio.xml
b/Documentation/DocBook/media/v4l/biblio.xml
index 7dc65c5..66a0ef2 100644
--- a/Documentation/DocBook/media/v4l/biblio.xml
+++ b/Documentation/DocBook/media/v4l/biblio.xml
@@ -197,4 +197,15 @@ in the frequency range from 87,5 to 108,0 MHz
NTSC-4: United States RBDS Standard
+
+ ISO 12232:2006
+
+ International Organization for Standardization
+(http://www.iso.org";>http://www.iso.org)
+
+ Photography — Digital still cameras — Determination
+ of exposure index, ISO speed ratings, standard output sensitivity, and
+ recommended exposure index
+
+
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index ac27444..557daae 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -3069,6 +3069,44 @@ times.
+
+ V4L2_CID_ISO_SENSITIVITY
+ integer menu
+ Determines ISO equivalent of an
+image sensor indicating the sensor's sensitivity to light. The numbers are
+expressed in arithmetic scale, as per standard,
+where doubling the sensor sensitivity is represented by doubling the numerical
+ISO value. Applications should interpret the values as standard ISO values
+multiplied by 1000, e.g. control value 800 stands for ISO 0.8. Drivers will
+usually support only a subset of standard ISO values. The effect of setting
+this control while the V4L2_CID_ISO_SENSITIVITY_AUTO
+control is set to a value other than V4L2_CID_ISO_SENSITIVITY_MANUAL
+ is undefined, drivers should ignore such requests.
+
+
+
+
+ V4L2_CID_ISO_SENSITIVITY_AUTO
+ enum v4l2_iso_sensitivity_type
+ Enables or disables automatic ISO
+sensitivity adjustments.
+
+
+
+
+
+
V4L2_CID_ISO_SENSITIVITY_MANUAL
+ Manual ISO sensitivity.
+
+
+
V4L2_CID_ISO_SENSITIVITY_AUTO
+ Automatic ISO sensititivity adjustments.
+
+
+
+
+
+
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 305a203..3d8af91 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -264,6 +264,10 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
static const char * const camera_image_stabilization[] = {
"Disabled",
"Enabled",
+ };
+ static const char * const camera_iso_sensitivity_auto[] = {
+ "Manual",
+ "Auto",
NULL
};
static const char * const tune_preemphasis[] = {
@@ -441,6 +445,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_wide_dynamic_range;
case V4L2_CID_IMAGE_STABILIZATION:
return camera_image_stabilization;
+ case V4L2_CID_ISO_SENSITIVITY_AUTO:
+ return camera_iso_sensitivity_auto;
case V4L2_CID_TUNE_PREEMPHASIS:
return tune_preemphasis;
case V4L2_CID_FLASH_LED_MODE:
@@ -630,6 +636,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE: return "White Balance, Auto
& Preset";
case V4L2_CID_WIDE_DYNAMIC_RANGE: return "Wide Dynamic Range";
case V4L2_CID_IMAGE_STABILIZATION: return "Image Stabilization";
+ case V4L2_CID_ISO_SENSITIVITY: return "ISO Sensitivity";
+ case V4L2_CID_ISO_SENSITIVITY_AUTO: return "ISO Sensitivity, Auto";
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -769,12 +777,14 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
case V4L2_CID_WIDE_DYNAMIC_RANGE:
case V4L2_CID_IMAGE_STABILIZATION:
+ case V4L2_CID_ISO_SENSITIVITY_AUTO:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_RDS_TX_PS_NAME:
case V4L2_CID_RDS_TX_RADIO_TEXT:
*type = V4L2_CTRL_TYPE_STRING;
break;
+
[PATCH/RFC v3 02/14] V4L: Add camera exposure bias control
The camera may in some conditions incorrectly determine the exposure,
and a manual automatic exposure correction may be needed. This patch
adds V4L2_CID_AUTO_EXPOSURE_BIAS control which allows to add some
offset in the automatic exposure control loop, to compensate for
frame under- or over-exposure.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/media/v4l/controls.xml | 16
drivers/media/video/v4l2-ctrls.c |4
include/linux/videodev2.h|2 ++
3 files changed, 22 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 5038a3a..56a53a8 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -2775,6 +2775,22 @@ remain constant.
+ V4L2_CID_EXPOSURE_BIAS
+ integer menu
+ Determines the automatic
+exposure compensation, it is effective only when
V4L2_CID_EXPOSURE_AUTO
+control is set to AUTO, SHUTTER_PRIORITY
+or APERTURE_PRIORITY.
+It is expressed in terms of EV, drivers should interpret the values as 0.001 EV
+units, where the value 1000 stands for +1 EV.
+Increasing the exposure compensation value is equivalent to decreasing
+the exposure value (EV) and will increase the amount of light at the image
+sensor. The camera performs the exposure compensation by adjusting absolute
+exposure time and/or aperture.
+
+
+
+
V4L2_CID_PAN_RELATIVE
integer
This control turns the
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index e0725b5..1d7091f 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -597,6 +597,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_PRIVACY: return "Privacy";
case V4L2_CID_IRIS_ABSOLUTE:return "Iris, Absolute";
case V4L2_CID_IRIS_RELATIVE:return "Iris, Relative";
+ case V4L2_CID_AUTO_EXPOSURE_BIAS: return "Auto Exposure, Bias";
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -739,6 +740,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_RDS_TX_RADIO_TEXT:
*type = V4L2_CTRL_TYPE_STRING;
break;
+ case V4L2_CID_AUTO_EXPOSURE_BIAS:
+ *type = V4L2_CTRL_TYPE_INTEGER_MENU;
+ break;
case V4L2_CID_USER_CLASS:
case V4L2_CID_CAMERA_CLASS:
case V4L2_CID_MPEG_CLASS:
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 5a09ac3..da60cbb 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1693,6 +1693,8 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
#define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
+#define V4L2_CID_AUTO_EXPOSURE_BIAS(V4L2_CID_CAMERA_CLASS_BASE+19)
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v3 05/14] V4L: Add camera image stabilization control
The V4L2_CID_IMAGE_STABILIZATION control allows to control the
camera's image stabilization feature. It can be used to enable/disable
image stabilization. It can be extended with new menu items if the image
stabilization technique selection is needed.
Signed-off-by: HeungJun Kim
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/media/v4l/controls.xml | 23 +++
drivers/media/video/v4l2-ctrls.c |9 +
include/linux/videodev2.h|5 +
3 files changed, 37 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 487b7b5..ac27444 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -3046,6 +3046,29 @@ times.
+
+ V4L2_CID_IMAGE_STABILIZATION
+ enum v4l2_image_stabilization_type
+
+
+ Enables or disables image
stabilization.
+
+
+
+
+
+
V4L2_IMAGE_STABILIZATION_DISABLED
+ Image stabilization is disabled.
+
+
+
V4L2_IMAGE_STABILIZATION_ENABLED
+ Image stabilization is enabled.
+
+
+
+
+
+
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index ad2f035..305a203 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -261,6 +261,11 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Enabled",
NULL
};
+ static const char * const camera_image_stabilization[] = {
+ "Disabled",
+ "Enabled",
+ NULL
+ };
static const char * const tune_preemphasis[] = {
"No Preemphasis",
"50 Microseconds",
@@ -434,6 +439,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return auto_n_preset_white_balance;
case V4L2_CID_WIDE_DYNAMIC_RANGE:
return camera_wide_dynamic_range;
+ case V4L2_CID_IMAGE_STABILIZATION:
+ return camera_image_stabilization;
case V4L2_CID_TUNE_PREEMPHASIS:
return tune_preemphasis;
case V4L2_CID_FLASH_LED_MODE:
@@ -622,6 +629,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_AUTO_EXPOSURE_BIAS: return "Auto Exposure, Bias";
case V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE: return "White Balance, Auto
& Preset";
case V4L2_CID_WIDE_DYNAMIC_RANGE: return "Wide Dynamic Range";
+ case V4L2_CID_IMAGE_STABILIZATION: return "Image Stabilization";
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -760,6 +768,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
case V4L2_CID_WIDE_DYNAMIC_RANGE:
+ case V4L2_CID_IMAGE_STABILIZATION:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_RDS_TX_PS_NAME:
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 3ca9b10..62d1d66 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1714,6 +1714,11 @@ enum v4l2_wide_dynamic_range_type {
V4L2_WIDE_DYNAMIC_RANGE_DISABLED= 0,
V4L2_WIDE_DYNAMIC_RANGE_ENABLED = 1,
};
+#define V4L2_CID_IMAGE_STABILIZATION (V4L2_CID_CAMERA_CLASS_BASE+22)
+enum v4l2_image_stabilization_type {
+ V4L2_IMAGE_STABILIZATION_DISABLED = 0,
+ V4L2_IMAGE_STABILIZATION_ENABLED= 1,
+};
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v3 01/14] V4L: Add helper function for standard integer menu controls
This patch adds v4l2_ctrl_new_std_int_menu() helper function which can
be used in drivers for creating standard integer menu control. It is
similar to v4l2_ctrl_new_std_menu(), except it doesn't have a mask
parameter and an additional qmenu parameter allows passing an array
of signed 64-bit integers constituting the menu items.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/v4l2-ctrls.c | 21 +
include/media/v4l2-ctrls.h | 17 +
2 files changed, 38 insertions(+)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index c93a979..e0725b5 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -1517,6 +1517,27 @@ struct v4l2_ctrl *v4l2_ctrl_new_std_menu(struct
v4l2_ctrl_handler *hdl,
}
EXPORT_SYMBOL(v4l2_ctrl_new_std_menu);
+/* Helper function for standard integer menu controls */
+struct v4l2_ctrl *v4l2_ctrl_new_std_int_menu(struct v4l2_ctrl_handler *hdl,
+ const struct v4l2_ctrl_ops *ops,
+ u32 id, s32 max, s32 def, const s64 *qmenu_int)
+{
+ const char *name;
+ enum v4l2_ctrl_type type;
+ s32 min;
+ s32 step;
+ u32 flags;
+
+ v4l2_ctrl_fill(id, &name, &type, &min, &max, &step, &def, &flags);
+ if (type != V4L2_CTRL_TYPE_INTEGER_MENU) {
+ handler_set_err(hdl, -EINVAL);
+ return NULL;
+ }
+ return v4l2_ctrl_new(hdl, ops, id, name, type,
+0, max, 0, def, flags, NULL, qmenu_int, NULL);
+}
+EXPORT_SYMBOL(v4l2_ctrl_new_std_int_menu);
+
/* Add a control from another handler to this handler */
struct v4l2_ctrl *v4l2_ctrl_add_ctrl(struct v4l2_ctrl_handler *hdl,
struct v4l2_ctrl *ctrl)
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 8920f82..15116d2 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -347,6 +347,23 @@ struct v4l2_ctrl *v4l2_ctrl_new_std_menu(struct
v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops,
u32 id, s32 max, s32 mask, s32 def);
+/** v4l2_ctrl_new_std_int_menu() - Create a new standard V4L2 integer menu
control.
+ * @hdl: The control handler.
+ * @ops: The control ops.
+ * @id: The control ID.
+ * @max: The control's maximum value.
+ * @def: The control's default value.
+ * @qmenu_int:The control's menu entries.
+ *
+ * Same as v4l2_ctrl_new_std_menu(), but @mask is set to 0 and it additionaly
+ * needs an array of integers determining the menu entries.
+ *
+ * If @id refers to a non-integer-menu control, then this function will
return NULL.
+ */
+struct v4l2_ctrl *v4l2_ctrl_new_std_int_menu(struct v4l2_ctrl_handler *hdl,
+ const struct v4l2_ctrl_ops *ops,
+ u32 id, s32 max, s32 def, const s64 *qmenu_int);
+
/** v4l2_ctrl_add_ctrl() - Add a control from another handler to this handler.
* @hdl: The control handler.
* @ctrl: The control to add.
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v3 03/14] V4L: Add an extended camera white balance control
This patch adds V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE control which is
an extended version of the V4L2_CID_AUTO_WHITE_BALANCE control,
including white balance presets. The following presets are defined:
- V4L2_WHITE_BALANCE_INCANDESCENT,
- V4L2_WHITE_BALANCE_FLUORESCENT,
- V4L2_WHITE_BALANCE_FLUORESCENT_H,
- V4L2_WHITE_BALANCE_HORIZON,
- V4L2_WHITE_BALANCE_DAYLIGHT,
- V4L2_WHITE_BALANCE_FLASH,
- V4L2_WHITE_BALANCE_CLOUDY,
- V4L2_WHITE_BALANCE_SHADE.
Signed-off-by: HeungJun Kim
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/media/v4l/controls.xml | 70 ++
drivers/media/video/v4l2-ctrls.c | 17 +++
include/linux/videodev2.h| 14 ++
3 files changed, 101 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 56a53a8..b671a70 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -2948,6 +2948,76 @@ camera sensor on or off, or specify its strength. Such
band-stop filters can
be used, for example, to filter out the fluorescent light component.
+
+
+ V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE
+ enum v4l2_auto_n_preset_white_balance_type
+ Sets white balance to automatic,
+manual or a preset. The presets determine color temperature of the light as
+a hint to the camera for white balance adjustments resulting in most accurate
+color representation. The following white balance presets are listed in order
+of increasing color temperature.
+
+
+
+
+
+
V4L2_WHITE_BALANCE_MANUAL
+ Manual white balance.
+
+
+
V4L2_WHITE_BALANCE_AUTO
+ Automatic white balance adjustments.
+
+
+
V4L2_WHITE_BALANCE_INCANDESCENT
+ White balance setting for incandescent (tungsten)
lighting.
+It generally cools down the colors and corresponds approximately to
2500...3500 K
+color temperature range.
+
+
+
V4L2_WHITE_BALANCE_FLUORESCENT
+ White balance preset for fluorescent lighting.
+It corresponds approximately to 4000...5000 K color temperature.
+
+
+
V4L2_WHITE_BALANCE_FLUORESCENT_H
+ With this setting the camera will compensate for
+fluorescent H lighting.
+
+
+
V4L2_WHITE_BALANCE_HORIZON
+ White balance setting for horizon daylight.
+It corresponds approximately to 5000 K color temperature.
+
+
+
V4L2_WHITE_BALANCE_DAYLIGHT
+ White balance preset for daylight (with clear sky).
+It corresponds approximately to 5000...6500 K color temperature.
+
+
+
V4L2_WHITE_BALANCE_FLASH
+ With this setting the camera will compensate for the
flash
+light. It slightly warms up the colors and corresponds roughly to 5000...5500 K
+color temperature.
+
+
+
V4L2_WHITE_BALANCE_CLOUDY
+ White balance preset for moderately overcast sky.
+This option corresponds approximately to 6500...8000 K color temperature
+range.
+
+
+
V4L2_WHITE_BALANCE_SHADE
+ White balance preset for shade or heavily overcast
+sky. It corresponds approximately to 9000...1 K color temperature.
+
+
+
+
+
+
+
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 1d7091f..02fa9b0 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -243,6 +243,19 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Vivid",
NULL
};
+ static const char * const auto_n_preset_white_balance[] = {
+ "Manual",
+ "Auto",
+ "Incandescent",
+ "Fluorescent",
+ "Fluorescent H",
+ "Horizon",
+ "Daylight",
+ "Flash",
+ "Cloudy",
+ "Shade",
+ NULL,
+ };
static const char * const tune_preemphasis[] = {
"No Preemphasis",
"50 Microseconds",
@@ -412,6 +425,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_exposure_auto;
case V4L2_CID_COLORFX:
return colorfx;
+ case V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE:
+ return auto_n_preset_white_balance;
case V4L2_CID_TUNE_PREEMPHASIS:
return tu
[PATCH/RFC v3 11/14] V4L: Add auto focus targets to the subdev selections API
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/media/v4l/dev-subdev.xml | 27 +++-
.../media/v4l/vidioc-subdev-g-selection.xml| 14 --
include/linux/v4l2-subdev.h|4 +++
3 files changed, 42 insertions(+), 3 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/dev-subdev.xml
b/Documentation/DocBook/media/v4l/dev-subdev.xml
index 4afcbbe..8a212c4 100644
--- a/Documentation/DocBook/media/v4l/dev-subdev.xml
+++ b/Documentation/DocBook/media/v4l/dev-subdev.xml
@@ -277,7 +277,7 @@
- Selections: cropping, scaling and composition
+ Selections - cropping, scaling and composition
Many sub-devices support cropping frames on their input or output
pads (or possible even on both). Cropping is used to select the area of
@@ -330,6 +330,31 @@
+ Selections - regions of interest
+
+ Automatic focus
+
+ The camera automatic focus algorithms may require configuration
+ of a region or multiple regions of interest in form of rectangle or spot
+ coordinates.
+
+ A single rectangle of interest is represented in &v4l2-rect;
+ by the coordinates of the top left corner and the rectangle size. Both
+ the coordinates and sizes are expressed in pixels. When the
+ width and height fields of
+ &v4l2-rect; are set to 0 the selection determines spot coordinates,
+ rather than a rectangle.
+
+ Auto focus rectangles are reset to their default values when the
+ output image format is modified. Drivers should use the output image size
+ as the auto focus rectangle default value, but hardware requirements may
+ prevent this.
+
+ The auto focus selections on input pads are not defined.
+
+
+
+
Types of selection targets
diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml
b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml
index 208e9f0..c4ccae5 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml
@@ -57,8 +57,8 @@
The selections are used to configure various image
processing functionality performed by the subdevs which affect the
-image size. This currently includes cropping, scaling and
-composition.
+image size. This currently includes cropping, scaling, composition
+and automatic focus regions of interest.
The selection API replaces the old subdev crop API. All
@@ -114,6 +114,16 @@
0x0102
Bounds of the compose rectangle.
+
+
V4L2_SUBDEV_SEL_TGT_AUTO_FOCUS_BOUNDS
+ 0x1000
+ Bounds of the automatic focus region of interest.
+
+
+
V4L2_SUBDEV_SEL_TGT_AUTO_FOCUS_ACTUAL
+ 0x1001
+ Actual automatic focus rectangle or spot coordinates.
+
diff --git a/include/linux/v4l2-subdev.h b/include/linux/v4l2-subdev.h
index 812019e..49b1f14 100644
--- a/include/linux/v4l2-subdev.h
+++ b/include/linux/v4l2-subdev.h
@@ -136,6 +136,10 @@ struct v4l2_subdev_frame_interval_enum {
/* composing bounds */
#define V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS 0x0102
+/* auto focus region of interest */
+#define V4L2_SUBDEV_SEL_TGT_AUTO_FOCUS_ACTUAL 0x1000
+/* auto focus region (spot coordinates) bounds */
+#define V4L2_SUBDEV_SEL_TGT_AUTO_FOCUS_BOUNDS 0x1001
/**
* struct v4l2_subdev_selection - selection info
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v3 07/14] V4L: Add camera exposure metering control
The V4L2_CID_EXPOSURE_METERING control allows to determine
a method used by the camera for measuring the amount of light
available for automatic exposure.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/media/v4l/controls.xml | 29 ++
drivers/media/video/v4l2-ctrls.c | 14 +
include/linux/videodev2.h|7 +++
3 files changed, 50 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 557daae..8f4fdf8 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -2790,6 +2790,35 @@ exposure time and/or aperture.
+
+ V4L2_CID_EXPOSURE_METERING
+ enum v4l2_exposure_metering_type
+ Determines how the camera measures
+the amount of light available for the frame exposure. Possible values
are:
+
+
+
+
+
+
V4L2_EXPOSURE_METERING_AVERAGE
+ Use the light information coming from the entire frame
+and average giving no weighting to any particular portion of the metered area.
+
+
+
+
V4L2_EXPOSURE_METERING_CENTER_WEIGHTED
+ Average the light information coming from the entire
frame
+giving priority to the center of the metered area.
+
+
+
V4L2_EXPOSURE_METERING_SPOT
+ Measure only very small area at the center of the
frame.
+
+
+
+
+
+
V4L2_CID_PAN_RELATIVE
integer
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 3d8af91..dcf6b2b 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -230,6 +230,12 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Aperture Priority Mode",
NULL
};
+ static const char * const camera_exposure_metering[] = {
+ "Average",
+ "Center Weighted",
+ "Spot",
+ NULL
+ };
static const char * const colorfx[] = {
"None",
"Black & White",
@@ -437,6 +443,12 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_power_line_frequency;
case V4L2_CID_EXPOSURE_AUTO:
return camera_exposure_auto;
+ case V4L2_CID_EXPOSURE_METERING:
+ return camera_exposure_metering;
+ case V4L2_CID_AUTO_FOCUS_AREA:
+ return camera_auto_focus_area;
+ case V4L2_CID_AUTO_FOCUS_DISTANCE:
+ return camera_auto_focus_distance;
case V4L2_CID_COLORFX:
return colorfx;
case V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE:
@@ -638,6 +650,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_IMAGE_STABILIZATION: return "Image Stabilization";
case V4L2_CID_ISO_SENSITIVITY: return "ISO Sensitivity";
case V4L2_CID_ISO_SENSITIVITY_AUTO: return "ISO Sensitivity, Auto";
+ case V4L2_CID_EXPOSURE_METERING:return "Exposure, Metering
Mode";
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -778,6 +791,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_WIDE_DYNAMIC_RANGE:
case V4L2_CID_IMAGE_STABILIZATION:
case V4L2_CID_ISO_SENSITIVITY_AUTO:
+ case V4L2_CID_EXPOSURE_METERING:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_RDS_TX_PS_NAME:
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 12cc16d..a8588fc 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1727,6 +1727,13 @@ enum v4l2_iso_sensitivity_auto_type {
V4L2_ISO_SENSITIVITY_AUTO = 1,
};
+#define V4L2_CID_EXPOSURE_METERING (V4L2_CID_CAMERA_CLASS_BASE+25)
+enum v4l2_exposure_metering_mode {
+ V4L2_EXPOSURE_METERING_AVERAGE = 0,
+ V4L2_EXPOSURE_METERING_CENTER_WEIGHTED = 1,
+ V4L2_EXPOSURE_METERING_SPOT = 2,
+};
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v3 08/14] V4L: Add camera scene mode control
Add control for the scene mode feature available in image sensor with more advanced ISP firmware. The V4L2_CID_SCENE_MODE menu control allows to select a set of parameters or a specific image processing and capture control algorithm optimized for common image capture conditions. Signed-off-by: HeungJun Kim Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- Documentation/DocBook/media/v4l/controls.xml | 117 ++ drivers/media/video/v4l2-ctrls.c | 21 + include/linux/videodev2.h| 18 3 files changed, 156 insertions(+) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 8f4fdf8..bf481d4 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -3136,6 +3136,123 @@ sensitivity adjustments. + + V4L2_CID_SCENE_MODE + enum v4l2_scene_mode + This control allows to select +scene programs as the camera automatic modes optimized for common shooting +scenes. Within these modes the camera determines best exposure, aperture, +focusing, light metering, white balance and equivalent sensitivity. The +controls of those parameters are influenced by the scene mode control. +An exact behaviour in each mode is subject to the camera specification. + +When the scene mode feature is not used, this control should be set to +V4L2_SCENE_MODE_NONE to make sure the other possibly +related controls are accessible. The following scene programs are defined: + + + + + + + + V4L2_SCENE_MODE_NONE + The scene mode feature is disabled. + + + V4L2_SCENE_MODE_BACKLIGHT + Backlight. Compensates for dark shadows when light is + coming from behind a subject, also by automatically turning + on the flash. + + + V4L2_SCENE_MODE_BEACH_SNOW + Beach and snow. This mode compensates for all-white or +bright scenes, which tend to look gray and low contrast, when camera's automatic +exposure is based on an average scene brightness. To compensate, this mode +automatically slightly overexposes the frames. The white balance may also be +adjusted to compensate for the fact that reflected snow looks bluish rather +than white. + + + V4L2_SCENE_MODE_CANDLELIGHT + Candle light. The camera generally raises the ISO +sensitivity and lowers the shutter speed. This mode compensates for relatively +close subject in the scene. The flash is disabled in order to preserve the +ambiance of the light. + + + V4L2_SCENE_MODE_DAWN_DUSK + Dawn and dusk. Preserves the colours seen in low +natural light before dusk and after down. The camera may turn off the flash, +and automatically focus at inifinity. It will usually boost saturation and +lower the shutter speed. + + + V4L2_SCENE_MODE_FALL_COLORS + Fall colors. Increases saturation and adjusts white +balance for color enhancement. Pictures of autumn leaves get saturated reds +and yellows. + + + V4L2_SCENE_MODE_FIREWORKS + Fireworks. Long exposure times are used to capture +the expanding burst of light from a firework. The camera may invoke image +stabilization. + + + V4L2_SCENE_MODE_LANDSCAPE + Landscape. The camera may choose a small aperture to +provide deep depth of field and long exposure duration to help capture detail +in dim light conditions. The focus is fixed at infinity. Suitable for distant +and wide scenery. + + + V4L2_SCENE_MODE_NIGHT + Night, also known as Night Landscape. Designed for low +light conditions, it preserves detail in the dark areas without blowing out bright +objects. The camera generally sets itself to a medium-to-high ISO sensitivity, +with a relatively long exposure time, and turns flash off. As such, there will be +increased image noise and the possibility of blurred image. + + + V4L2_SCENE_MODE_PARTY_INDOOR + Party and indoor. Designed to capture indoor scenes +that are lit by indoor background lighting as well as the flash. The camera +usually increases ISO sensitivity, and adjusts exposure for the low light +conditions. + + + V4L2_SCENE_MODE_PORTRAIT + Portrait. The camera adjusts the aperture so that the +depth of field is reduced, which helps to isolate the subject against a smooth +
[PATCH/RFC v3 14/14] vivi: Add controls
This patch is just for testing the new controls, it is NOT
intended for merging upstream.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/vivi.c | 111 +++-
1 file changed, 110 insertions(+), 1 deletion(-)
diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
index d64d482..cbe103e 100644
--- a/drivers/media/video/vivi.c
+++ b/drivers/media/video/vivi.c
@@ -179,6 +179,29 @@ struct vivi_dev {
struct v4l2_ctrl *bitmask;
struct v4l2_ctrl *int_menu;
+ struct v4l2_ctrl *exposure_bias;
+ struct v4l2_ctrl *metering;
+ struct v4l2_ctrl *wb_preset;
+ struct {
+ /* iso/auto iso cluster */
+ struct v4l2_ctrl *auto_iso;
+ struct v4l2_ctrl *iso;
+ };
+ struct {
+ /* continuous auto focus/auto focus cluster */
+ struct v4l2_ctrl *focus_auto;
+ struct v4l2_ctrl *af_start;
+ struct v4l2_ctrl *af_stop;
+ struct v4l2_ctrl *af_status;
+ struct v4l2_ctrl *af_distance;
+ struct v4l2_ctrl *af_area;
+ };
+ struct v4l2_ctrl *scene_mode;
+ struct v4l2_ctrl *lock_3a;
+ struct v4l2_ctrl *colorfx;
+ struct v4l2_ctrl *wdr;
+ struct v4l2_ctrl *stabilization;
+
spinlock_t slock;
struct mutex mutex;
@@ -208,6 +231,14 @@ struct vivi_dev {
u8 line[MAX_WIDTH * 4];
};
+static const s64 vivi_iso_qmenu[] = {
+ 50, 100, 200, 400, 800, 1600
+};
+
+static const s64 vivi_ev_bias_qmenu[] = {
+ -1500, -1000, -500, 0, 500, 1000, 1500
+};
+
/* --
DMA and thread functions
--*/
@@ -516,6 +547,10 @@ static void vivi_fillbuff(struct vivi_dev *dev, struct
vivi_buffer *buf)
gen_text(dev, vbuf, line++ * 16, 16, str);
}
+ snprintf(str, sizeof(str), " auto iso: %s, iso: %lld ",
+dev->auto_iso->cur.val ? "on" : "off",
+vivi_iso_qmenu[dev->iso->cur.val]);
+
dev->mv_count += 2;
buf->vb.v4l2_buf.field = dev->field;
@@ -1023,6 +1058,13 @@ static int vivi_s_ctrl(struct v4l2_ctrl *ctrl)
if (ctrl == dev->button)
dev->button_pressed = 30;
+
+ if (ctrl->type == V4L2_CTRL_TYPE_STRING)
+ return 0;
+
+ dprintk(dev, 1, "%s: control: %s, val: %d, val64: %lld",
+ __func__, ctrl->name, ctrl->val, ctrl->val64);
+
return 0;
}
@@ -1267,7 +1309,8 @@ static int __init vivi_create_instance(int inst)
dev->width = 640;
dev->height = 480;
hdl = &dev->ctrl_handler;
- v4l2_ctrl_handler_init(hdl, 11);
+ v4l2_ctrl_handler_init(hdl, 26);
+
dev->volume = v4l2_ctrl_new_std(hdl, &vivi_ctrl_ops,
V4L2_CID_AUDIO_VOLUME, 0, 255, 1, 200);
dev->brightness = v4l2_ctrl_new_std(hdl, &vivi_ctrl_ops,
@@ -1290,11 +1333,77 @@ static int __init vivi_create_instance(int inst)
dev->string = v4l2_ctrl_new_custom(hdl, &vivi_ctrl_string, NULL);
dev->bitmask = v4l2_ctrl_new_custom(hdl, &vivi_ctrl_bitmask, NULL);
dev->int_menu = v4l2_ctrl_new_custom(hdl, &vivi_ctrl_int_menu, NULL);
+
+ dev->wb_preset = v4l2_ctrl_new_std_menu(hdl,
+ &vivi_ctrl_ops, V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE,
+ 9, ~0x3ff, V4L2_WHITE_BALANCE_AUTO);
+
+ dev->exposure_bias = v4l2_ctrl_new_std_int_menu(hdl,
+ &vivi_ctrl_ops, V4L2_CID_AUTO_EXPOSURE_BIAS,
+ ARRAY_SIZE(vivi_ev_bias_qmenu) - 1,
+ ARRAY_SIZE(vivi_ev_bias_qmenu)/2 - 1,
+ vivi_ev_bias_qmenu);
+
+ dev->metering = v4l2_ctrl_new_std_menu(hdl,
+ &vivi_ctrl_ops, V4L2_CID_EXPOSURE_METERING,
+ 2, ~0x7, V4L2_EXPOSURE_METERING_AVERAGE);
+
+ /* ISO cluster */
+ dev->auto_iso = v4l2_ctrl_new_std(hdl, &vivi_ctrl_ops,
+ V4L2_CID_ISO_SENSITIVITY_AUTO, 0, 1, 1, 1);
+
+ dev->iso = v4l2_ctrl_new_std_int_menu(hdl, &vivi_ctrl_ops,
+ V4L2_CID_ISO_SENSITIVITY, ARRAY_SIZE(vivi_iso_qmenu) -
1,
+ ARRAY_SIZE(vivi_iso_qmenu)/2 - 1, vivi_iso_qmenu);
+
+ /* Auto focus cluster */
+ dev->focus_auto = v4l2_ctrl_new_std(hdl, &vivi_ctrl_ops,
+ V4L2_CID_FOCUS_AUTO, 0, 1, 1, 0);
+
+ dev->af_start = v4l2_ctrl_new_std(hdl, &vivi_ctrl_ops,
+ V4L2_CID_AUTO_FOCUS_START, 0, 1, 1, 0);
+
+ dev->af_stop = v4l2_ctrl_new_std(hdl, &vivi_ctrl_ops,
+ V4L2_CI
[PATCH/RFC v3 12/14] V4L: Add camera auto focus controls
Add following auto focus controls: - V4L2_CID_AUTO_FOCUS_START - single-shot auto focus start - V4L2_CID_AUTO_FOCUS_STOP - single-shot auto focus stop - V4L2_CID_AUTO_FOCUS_STATUS - automatic focus status - V4L2_CID_AUTO_FOCUS_AREA - automatic focus area selection - V4L2_CID_AUTO_FOCUS_DISTANCE - automatic focus scan range selection Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- Documentation/DocBook/media/v4l/controls.xml | 140 +- drivers/media/video/v4l2-ctrls.c | 26 - include/linux/videodev2.h| 23 + 3 files changed, 186 insertions(+), 3 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 51509f4..e974a03 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -2902,13 +2902,149 @@ negative values towards infinity. This is a write-only control. V4L2_CID_FOCUS_AUTO boolean - Enables automatic focus -adjustments. The effect of manual focus adjustments while this feature + Enables continuous automatic +focus adjustments. The effect of manual focus adjustments while this feature is enabled is undefined, drivers should ignore such requests. + V4L2_CID_AUTO_FOCUS_START + button + Starts single auto focus process. +The effect of setting this control when V4L2_CID_FOCUS_AUTO +is set to TRUE (1) is undefined, drivers should ignore +such requests. + + + + + V4L2_CID_AUTO_FOCUS_STOP + button + Aborts automatic focusing +started with V4L2_CID_AUTO_FOCUS_START control. It is +effective only when the continuous autofocus is disabled, that is when +V4L2_CID_FOCUS_AUTO control is set to FALSE + (0). + + + + + + V4L2_CID_AUTO_FOCUS_STATUS + bitmask + + The automatic focus status. This is a read-only + control. + + + + + + V4L2_AUTO_FOCUS_STATUS_IDLE + Automatic focus is inactive. + + + V4L2_AUTO_FOCUS_STATUS_BUSY + Automatic focusing is in progress and the focus is changing. + + + V4L2_AUTO_FOCUS_STATUS_SUCCESS + Automatic focus has completed or is continued successfully. + + + V4L2_AUTO_FOCUS_STATUS_FAIL + Automatic focus has failed, the driver will not transition + from this state until another action is performed by an + application. + + + + + + + + + V4L2_CID_AUTO_FOCUS_DISTANCE + enum v4l2_auto_focus_distance + + Determines auto focus distance range +for which lens may be adjusted. + + + + + + V4L2_AUTO_FOCUS_DISTANCE_NORMAL + The auto focus normal distance range. It is limited +for best auto focus algorithm performance. + + + V4L2_AUTO_FOCUS_DISTANCE_MACRO + Macro (close-up) auto focus. The camera will +use minimum possible distance that it is capable of for auto focus. + + + V4L2_AUTO_FOCUS_DISTANCE_INFINITY + The camera is focused permanently at its farthest +possible distance. + + + + + + + + + V4L2_CID_AUTO_FOCUS_AREA + enum v4l2_auto_focus_area + + Determines the area of the frame that +the camera uses for automatic focus. The corresponding coordinates of the +focusing spot or rectangle can be specified and queried using the selection API. +To change the auto focus region of interest applications first select required +mode of this control and then set the rectangle or spot coordinates by means +of the &VIDIOC-SUBDEV-S-SELECTION; or &VIDIOC-S-SELECTION; ioctl. In order to +trigger again an auto focus process with same coordinates applications should +use the V4L2_CID_AUTO_FOCUS_START control. Or alternatively +invoke a &VIDIOC-SUBDEV-S-SELECTION; or a &VIDIOC-S-SELECTION; ioctl again. +In the latter case the new pixel coordinates are applied to hardware only when +the focus area control is set to a value other than +V4L2_AUTO_FOCUS_AREA_ALL. + + + + + + V4L2_AUTO_FOCUS_AREA_ALL + Normal auto focus, the focusing area extends over the +entire frame. + +
[PATCH/RFC v3 04/14] V4L: Add camera wide dynamic range control
Add V4L2_CID_WIDE_DYNAMIC_RANGE camera class control for camera wide
dynamic range (WDR, HDR) feature. This control has now only menu entries
for enabling and disabling WDR. It can be extended when the wide dynamic
range technique selection is needed.
Signed-off-by: HeungJun Kim
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/media/v4l/controls.xml | 28 ++
drivers/media/video/v4l2-ctrls.c |9 +
include/linux/videodev2.h|6 ++
3 files changed, 43 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index b671a70..487b7b5 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -3018,6 +3018,34 @@ sky. It corresponds approximately to 9000...1 K
color temperature.
+
+ V4L2_CID_WIDE_DYNAMIC_RANGE
+ enum v4l2_wide_dynamic_range_type
+
+
+ Enables or disables the camera's wide
dynamic
+range feature. This feature allows to obtain clear images in situations where
+intensity of the illumination varies significantly throughout the scene, i.e.
+there are simultaneously very dark and very bright areas. It is most commonly
+realized in cameras by combining two subsequent frames with different exposure
+times.
+
+
+
+
+
+
V4L2_WIDE_DYNAMIC_RANGE_DISABLED
+ Wide dynamic range is disabled.
+
+
+
V4L2_WIDE_DYNAMIC_RANGE_ENABLED
+ Wide dynamic range is enabled.
+
+
+
+
+
+
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 02fa9b0..ad2f035 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -256,6 +256,11 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Shade",
NULL,
};
+ static const char * const camera_wide_dynamic_range[] = {
+ "Disabled",
+ "Enabled",
+ NULL
+ };
static const char * const tune_preemphasis[] = {
"No Preemphasis",
"50 Microseconds",
@@ -427,6 +432,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return colorfx;
case V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE:
return auto_n_preset_white_balance;
+ case V4L2_CID_WIDE_DYNAMIC_RANGE:
+ return camera_wide_dynamic_range;
case V4L2_CID_TUNE_PREEMPHASIS:
return tune_preemphasis;
case V4L2_CID_FLASH_LED_MODE:
@@ -614,6 +621,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_IRIS_RELATIVE:return "Iris, Relative";
case V4L2_CID_AUTO_EXPOSURE_BIAS: return "Auto Exposure, Bias";
case V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE: return "White Balance, Auto
& Preset";
+ case V4L2_CID_WIDE_DYNAMIC_RANGE: return "Wide Dynamic Range";
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -751,6 +759,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
+ case V4L2_CID_WIDE_DYNAMIC_RANGE:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_RDS_TX_PS_NAME:
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 08891e6..3ca9b10 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1709,6 +1709,12 @@ enum v4l2_auto_n_preset_white_balance_type {
V4L2_WHITE_BALANCE_SHADE= 9,
};
+#define V4L2_CID_WIDE_DYNAMIC_RANGE(V4L2_CID_CAMERA_CLASS_BASE+21)
+enum v4l2_wide_dynamic_range_type {
+ V4L2_WIDE_DYNAMIC_RANGE_DISABLED= 0,
+ V4L2_WIDE_DYNAMIC_RANGE_ENABLED = 1,
+};
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v3 10/14] V4L: Add auto focus targets to the selections API
The camera automatic focus algorithms may require setting up
a spot or rectangle coordinates or multiple such parameters.
The automatic focus selection targets are introduced in order
to allow applications to query and set such coordinates. Those
selections are intended to be used together with the automatic
focus controls available in the camera control class.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/media/v4l/selection-api.xml | 33 +++-
.../DocBook/media/v4l/vidioc-g-selection.xml | 11 +++
include/linux/videodev2.h |5 +++
3 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/Documentation/DocBook/media/v4l/selection-api.xml
b/Documentation/DocBook/media/v4l/selection-api.xml
index b299e47..490d29a 100644
--- a/Documentation/DocBook/media/v4l/selection-api.xml
+++ b/Documentation/DocBook/media/v4l/selection-api.xml
@@ -1,6 +1,6 @@
- Experimental API for cropping, composing and scaling
+ Experimental selections API
Experimental
@@ -9,6 +9,10 @@
interface and may change in the future.
+
+
+ Image cropping, composing and scaling
+
Introduction
@@ -321,5 +325,32 @@ V4L2_BUF_TYPE_VIDEO_OUTPUT for other
devices
+
+
+
+ Automatic focus regions of interest
+
+ The camera automatic focus algorithms may require configuration of
+regions of interest in form of rectangle or spot coordinates. The automatic
+focus selection targets allow applications to query and set such coordinates.
+Those selections are intended to be used together with the
+V4L2_CID_AUTO_FOCUS_AREA
+camera class control. The V4L2_SEL_TGT_AUTO_FOCUS_ACTUAL
+ target is used for querying or setting actual spot or rectangle
+coordinates, while V4L2_SEL_TGT_AUTO_FOCUS_BOUNDS target
+determines bounds for a single spot or rectangle.
+These selections are only effective when the V4L2_CID_AUTO_FOCUS_AREA
+control is set to V4L2_AUTO_FOCUS_AREA_SPOT or
+V4L2_AUTO_FOCUS_AREA_RECTANGLE. The new coordinates shall
+be accepted and applied to hardware when the focus area control value is
+changed and also during a &VIDIOC-S-SELECTION; ioctl call, only when the focus
+area control is already set to required value.
+
+ For the V4L2_AUTO_FOCUS_AREA_SPOT case, the
selection
+rectangle width and
height
+are not used, i.e. shall be set to 0 by applications and ignored by drivers for
+the &VIDIOC-S-SELECTION; ioctl and shall be ignored by applications for the
+&VIDIOC-G-SELECTION; ioctl.
+
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-selection.xml
b/Documentation/DocBook/media/v4l/vidioc-g-selection.xml
index bb04eff..87df4da 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-selection.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-selection.xml
@@ -195,6 +195,17 @@ exist no rectangle that satisfies the
constraints.
0x0103
The active area and all padding pixels that are inserted or
modified by hardware.
+
+V4L2_SEL_TGT_AUTO_FOCUS_ACTUAL
+0x1000
+ Actual automatic focus rectangle or spot coordinates.
+
+
+V4L2_SEL_TGT_AUTO_FOCUS_BOUNDS
+0x1002
+Bounds of the automatic focus region of interest.
+
+
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 7c30d54..29b84ae 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -777,6 +777,11 @@ struct v4l2_crop {
/* Current composing area plus all padding pixels */
#define V4L2_SEL_TGT_COMPOSE_PADDED0x0103
+/* Auto focus region of interest */
+#define V4L2_SEL_TGT_AUTO_FOCUS_ACTUAL 0x1000
+/* Auto focus region (spot coordinates) bounds */
+#define V4L2_SEL_TGT_AUTO_FOCUS_BOUNDS 0x1001
+
/**
* struct v4l2_selection - selection info
* @type: buffer type (do not use *_MPLANE types)
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v3 09/14] V4L: Add camera 3A lock control
The V4L2_CID_3A_LOCK bitmask control allows applications to pause
or resume the automatic exposure, focus and wite balance adjustments.
It can be used, for example, to lock the 3A adjustments right before
a still image is captured, for pre-focus, etc.
The applications can control each of the algorithms independently,
through a corresponding control bit, if driver allows that.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/media/v4l/controls.xml | 40 ++
drivers/media/video/v4l2-ctrls.c |2 ++
include/linux/videodev2.h|5
3 files changed, 47 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index bf481d4..51509f4 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -3253,6 +3253,46 @@ lens-distortion correction.
+
+ V4L2_CID_3A_LOCK
+ bitmask
+
+
+ This control locks or unlocks the automatic
+exposure, white balance and focus. The automatic adjustments can be paused
+independently by setting the coresponding lock bit to 1. The camera then
retains
+the corresponding 3A settings, until the lock bit is cleared. The value of this
+control may be changed by other, exposure, white balance or focus controls. The
+following control bits are defined :
+
+
+
+
+
+
+ V4L2_3A_LOCK_EXPOSURE
+ Automatic exposure adjustments lock.
+
+
+ V4L2_3A_LOCK_WHITE_BALANCE
+ Automatic white balance adjustments lock.
+
+
+ V4L2_3A_LOCK_FOCUS
+ Automatic focus adjustments lock.
+
+
+
+
+
+When a particular algorithm is not enabled, drivers should ignore requests
+to lock it and should return no error. An example might be an application
+setting bit V4L2_3A_LOCK_WHITE_BALANCE when the
+V4L2_CID_AUTO_WHITE_BALANCE control is set to
+FALSE.
+
+
+
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 8b48893..d45f00c 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -671,6 +671,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_ISO_SENSITIVITY_AUTO: return "ISO Sensitivity, Auto";
case V4L2_CID_EXPOSURE_METERING:return "Exposure, Metering
Mode";
case V4L2_CID_SCENE_MODE: return "Scene Mode";
+ case V4L2_CID_3A_LOCK: return "3A Lock";
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -843,6 +844,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
break;
case V4L2_CID_FLASH_FAULT:
case V4L2_CID_JPEG_ACTIVE_MARKER:
+ case V4L2_CID_3A_LOCK:
*type = V4L2_CTRL_TYPE_BITMASK;
break;
case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE:
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 2c82fd9..7c30d54 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1752,6 +1752,11 @@ enum v4l2_scene_mode {
V4L2_SCENE_MODE_TEXT= 13,
};
+#define V4L2_CID_3A_LOCK (V4L2_CID_CAMERA_CLASS_BASE+27)
+#define V4L2_3A_LOCK_EXPOSURE (1 << 0)
+#define V4L2_3A_LOCK_WHITE_BALANCE (1 << 1)
+#define V4L2_3A_LOCK_FOCUS (1 << 2)
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v3 00/14] V4L camera control enhancements
Here is one more update of the camera class controls change set. The changes since v2 are: - V4L2_CID_WHITE_BALANCE_PRESET replaced with V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE according to suggestions from Hans de Goede; - added Flurescent H white balance preset; - V4L2_CID_IMAGE_STABILIZATION and V4L2_CID_WIDE_DYNAMIC_RANGE controls type changed from boolean to menu, to make any further extensions of these controls easier; I'm just not 100% sure if V4L2_WIDE_DYNAMIC_RANGE_ENABLED and V4L2_IMAGE_STABILIZATION_ENABLED are good names for cases where the camera doesn't support wide dynamic range or image stabilization technique selection and only allows to enable or disable those algorithms; - V4L2_CID_ISO_SENSITIVITY_AUTO control type changed from boolean to menu in order to support ISO presets; currently enum v4l2_iso_sensitivity_auto_type does not contain any presets though; - V4L2_CID_COLORFX patch removed from this series; - updated vivi and s5c73m3 driver patches. Changes since v1 (implicit): - the V4L2_CID_AUTO_FOCUS_FACE_PRIORITY control merged with V4L2_CID_AUTO_FOCUS_FACE_AREA, - many minor documentation corrections, - removed "08/23 V4L: camera control class..." patch, which got accidentally added at v1, - added V4L2_CID_SCENE_MODE and V4L2_CID_3A_LOCK controls, - added vivi patch for testing. The patches are also available in a git repository at: http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/v4l-controls-s5c73m3 Thanks, Sylwester Sylwester Nawrocki (14): V4L: Add helper function for standard integer menu controls V4L: Add camera exposure bias control V4L: Add an extended camera white balance control V4L: Add camera wide dynamic range control V4L: Add camera image stabilization control V4L: Add camera ISO sensitivity controls V4L: Add camera exposure metering control V4L: Add camera scene mode control V4L: Add camera 3A lock control V4L: Add auto focus targets to the selections API V4L: Add auto focus targets to the subdev selections API V4L: Add camera auto focus controls V4L: Add S5C73M3 sensor sub-device driver vivi: Add controls Documentation/DocBook/media/v4l/biblio.xml | 11 + Documentation/DocBook/media/v4l/controls.xml | 501 +++- Documentation/DocBook/media/v4l/dev-subdev.xml | 27 +- Documentation/DocBook/media/v4l/selection-api.xml | 33 +- .../DocBook/media/v4l/vidioc-g-selection.xml | 11 + .../media/v4l/vidioc-subdev-g-selection.xml| 14 +- drivers/media/video/Kconfig|8 + drivers/media/video/Makefile |1 + drivers/media/video/s5c73m3/Makefile |3 + drivers/media/video/s5c73m3/s5c73m3-ctrls.c| 705 +++ drivers/media/video/s5c73m3/s5c73m3-spi.c | 126 ++ drivers/media/video/s5c73m3/s5c73m3.c | 1243 drivers/media/video/s5c73m3/s5c73m3.h | 442 +++ drivers/media/video/v4l2-ctrls.c | 133 ++- drivers/media/video/vivi.c | 111 +- include/linux/v4l2-subdev.h|4 + include/linux/videodev2.h | 92 ++ include/media/s5c73m3.h| 62 + include/media/v4l2-ctrls.h | 17 + 19 files changed, 3536 insertions(+), 8 deletions(-) create mode 100644 drivers/media/video/s5c73m3/Makefile create mode 100644 drivers/media/video/s5c73m3/s5c73m3-ctrls.c create mode 100644 drivers/media/video/s5c73m3/s5c73m3-spi.c create mode 100644 drivers/media/video/s5c73m3/s5c73m3.c create mode 100644 drivers/media/video/s5c73m3/s5c73m3.h create mode 100644 include/media/s5c73m3.h -- 1.7.10 -- 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: Re: [PATCH 1/6 v2] dvbsky, montage dvb-s/s2 TS202x tuner and M88DS3103demodulator driver
2012-04-27 22:03:20 nibble@gmail.com >Em 27-04-2012 04:06, nibble.max escreveu: >> --- >> drivers/media/dvb/frontends/Kconfig | 14 + >> drivers/media/dvb/frontends/Makefile |3 + >> drivers/media/dvb/frontends/m88ds3103.c | 1153 >> ++ >> drivers/media/dvb/frontends/m88ds3103.h | 67 ++ >> drivers/media/dvb/frontends/m88ds3103_priv.h | 413 + >> drivers/media/dvb/frontends/m88ts202x.c | 590 + >> drivers/media/dvb/frontends/m88ts202x.h | 63 ++ >> 7 files changed, 2303 insertions(+) >> create mode 100644 drivers/media/dvb/frontends/m88ds3103.c >> create mode 100644 drivers/media/dvb/frontends/m88ds3103.h >> create mode 100644 drivers/media/dvb/frontends/m88ds3103_priv.h >> create mode 100644 drivers/media/dvb/frontends/m88ts202x.c >> create mode 100644 drivers/media/dvb/frontends/m88ts202x.h > >No, this is not what we've agreed. You should, instead, take Konstantin's >driver, >breaking it into two separate ones, without touching the copyrights. Then, >apply >what else is needed for ds3103/ts2123. Hello Mauro, Should I need Konstantin's agreement to do that? Using the seperate tuner and demod, I need to change the codes which use the ds3000 frontend. How can I test the code to confirm that these codes are right without these hardwards? If I can not do this work, the new m88ds3103 and m88ts2022 code can not be patched in the upstream. It seems i go to a dead lock, doesn't it? Br, Max > >> diff --git a/drivers/media/dvb/frontends/m88ds3103.c >> b/drivers/media/dvb/frontends/m88ds3103.c >> new file mode 100644 >> index 000..392cada >> --- /dev/null >> +++ b/drivers/media/dvb/frontends/m88ds3103.c >> @@ -0,0 +1,1153 @@ >> +/* >> +Montage Technology M88DS3103/3000 - DVBS/S2 Satellite demod driver >> + >> +Copyright (C) 2011 Max nibble > >Adding your copyright like that only justifies if you make significant >contributions >to the code. Adding support for a new card or a new chip within the same chip >family >in general don't fit on that. > >If Konstantin is ok, you may, instead, add, at the bottom of the copyright >list, something like: > >Copyright (C) 2011 Max nibble > - Add support for ds3103 > >> +Copyright (C) 2010 Montage Technology >> +Fix some bug and add M88DS3103 code, M88DS3000 code based on DS3000.c. >> + >> +Copyright (C) 2009 Konstantin Dimitrov >> + >> +Copyright (C) 2009 TurboSight.com > >Regards, >Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] tinyjpeg: Dynamic luminance quantization table for Pixart JPEG
Hi, On 04/25/2012 06:09 PM, Jean-Francois Moine wrote: Hi Hans, On Wed, 25 Apr 2012 16:19:57 +0200 Hans de Goede wrote: You say that the marker cannot be in the range 0..31 (index 0..7), but I have never seen a value lower than 68 (index 17). If you change register 0x80 in bank/page 1 to> 42 on pac7311 or larger then circa 100 on pac7302, you will get markers with bit 8 set. When this happens you will initially get markers 0xa0 - 0xa4 ... 0xbc and the stream tends to stabilize on 0xbc. Likewise if you remove the artificial limiting of the pac7302 to 15 fps from the driver you will get markers 0x44 - 0x48 ... 0x7c. The images look a lot better with bit 8 set, so I plan to run some tests wrt what framerates can safely handle that (it uses more bandwidth) and set bit 8 on lower framerates. I carefully looked at the ms-windows pac7302 traces I have. The register 1-80 stays always in the range 0d..11, except sometimes 19 at start time. Right, that can mean one of 2 things: 1) The traces were made during daylight, so low exposure / high framerate, and enabling the lower compression modes (which cause bit 7 of the marker to get set) is a bad idea at high framerates 2) The windows driver never enables the low compression mode. I seriously doubt that this is the case, ie older versions of the pac7311 driver have (commented) writes to page 1 register 80 with high enough values to enable it and I'm pretty sure those writes come from windows traces. In these traces, the images with marker 44 (dec 68) look really better with all 08's as the quantization table. After having played with the quantization tables you've found I agree. [snip] Yeah short of someone disassembling and reverse-engineering the windows driver we will probably never figure out the exact correct tables. Well, I got the SPC230NC.SYS of the ms-windows pac7302 driver, but it is not easy to disassemble because it has no symbol table. But, inside, I found this tables just before the Huffman table: - 0006C888 10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 - 0006C908 10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 - 0006C988 08 08 08 08 08 08 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 - 0006CA08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 08 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 20 - 0006CA88 10 10 10 10 10 10 20 20 20 20 20 20 20 20 20 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 - 0006CB08 08 0b 0b 0b 0b 0b 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 20 20 20 20 20 20 20 40 40 40 40 40 40 40 40 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 - 0006CB88 11 12 12 18 15 18 2f 1a 1a 2f 63 42 38 42 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 - 0006CC08 10 0b 0c 0e 0c 0b 10 0e 0d 0e 12 11 10 13 18 28 1a 18 16 16 18 31 23 25 1d 28 3a 33 3d 3c 39 33 38 37 40 48 5c 4e 40 44 57 45 37 38 50 6D 51 57 5F 62 67 68 67 3E 4D 71 78 70 64 78 5C 65 67 63 Don't they look like quantization tables? Yes they do, good find! I've done yet more testing / trial and error with these tables and I've just pushed another Pixart JPEG patch to v4l-utils git switching to these new tables. Thanks! Also with these tables the quality difference between high/low compression mode becomes significantly less. So much less that I've decided to not further pursue enabling low compression mode in the gspca drivers, esp. since this will cause pain for people with an older libv4l. BTW, I don't think the exposure and gain controls use the right registers as they are coded in the actual gspca pac7302 subdriver. The ms-windows driver uses the registers (3-80 / 3-03), (3-05 / 3-04), (3-12) and (1-80) for autogain/exposure. The gspca test tarball of my web site includes a new AGC using these registers, but it does not work well. Maybe you could tell me what is wrong with it... Let me get back on that in a separate mail. 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
Re: gspca V4L2_CID_EXPOSURE_AUTO and VIDIOC_G/S/TRY_EXT_CTRLS
On Friday, April 27, 2012 14:04:16 Antonio Ospite wrote: > On Fri, 27 Apr 2012 09:53:09 +0200 > Jean-Francois Moine wrote: > > > On Wed, 18 Apr 2012 15:37:20 +0200 > > Antonio Ospite wrote: > > > > > I noticed that AEC (Automatic Exposure Control, or > > > V4L2_CID_EXPOSURE_AUTO) does not work in the ov534 gspca driver, either > > > from guvcview or qv4l2. > > [snip] > > > So in ov534, but I think in m5602 too, V4L2_CID_EXPOSURE_AUTO does not > > > work from guvcview, qv4l2, or v4l2-ctrl, for instance the latter fails > > > with the message: > > > > > > error 25 getting ext_ctrl Auto Exposure > > > > > > I tried adding an hackish implementation of vidioc_g_ext_ctrls and > > > vidioc_s_ext_ctrls to gspca, and with these V4L2_CID_EXPOSURE_AUTO seems > > > to work, but I need to learn more about this kind of controls before > > > I can propose a decent implementation for mainline inclusion myself, so > > > if anyone wants to anticipate me I'd be glad to test :) > > > > > > Unrelated, but maybe worth mentioning is that V4L2_CID_EXPOSURE_AUTO is > > > of type MENU, while some drivers are treating it as a boolean, I think > > > I can fix this one if needed. > > > > Hi Antonio, > > > > Yes, V4L2_CID_EXPOSURE_AUTO is of class V4L2_CTRL_CLASS_CAMERA, and, as > > the associated menu shows, it is not suitable for webcams. > > > > Where is that menu you refer to? Maybe camera_exposure_auto in > drivers/media/video/v4l2-ctrls.c which mentions also "Shutter Priority > Mode" and "Aperture Priority Mode"? > > Naively one would expect that a web _camera_ could use some controls of > type V4L2_CTRL_CLASS_CAMERA. > > > In the webcam world, the autoexposure is often the same as the > > autogain: in the knee algorithm > > (http://81.209.78.62:8080/docs/LowLightOptimization.html - also look at > > gspca/sonixb.c), both exposure and gain are concerned. > > From the document you point at I still understand that from a user point > of view autoexposure and autogain are _independent_ parameters (Table > 1), it's just that for such algorithm to work well they should be _both_ > enabled. > > > The cases where > > a user wants only autoexposure (fixed gain) or autogain (fixed > > exposure) are rare. > > > > If you want people to be able to do that, you > > should add a new webcam control, V4L2_CID_AUTOEXPOSURE, and also add it > > to each driver which implements the knee algorithm, and handle the three > > cases, autogain only, autoexposure only and knee. > > The real problem here is that _manual_ exposure does not work in ov534 > because the user cannot turn off what we are currently calling auto > exposure. > > > Then, looking about your implementation of vidioc_s_ext_ctrls, I found > > it was a bit simple: setting many controls is atomic, i.e., if any > > error occurs at some point, the previous controls should be reset to > > their original values. Same about vidioc_g_ext_ctrls: the mutex must be > > taken only once for the values do not change. You also do not check if > > the controls are in a same control class. > > I see, it was my first shot and I just wanted to start the discussion > with a "works here" implementation. I think that using some v4l2 > infrastructure like the control-framework like Hans proposes could be > better in the long run. IIUC this could also prevent drivers having to > handle menu entries themselves like we are doing now in sd_querymenu(), > right? Correct. > If you two reach an agreement and he gets to do it I'll surely port > over drivers using V4L2_CID_EXPOSURE_AUTO. > > > Anyway, are these ioctl's needed? > > > > Whether they are really needed or not, that depends on the definition of > webcam, the definition of "camera" in V4L2, and the relationship > between the two. > > If a webcam IS-A v4l2 camera, then I'd expect it to be able to use > V4L2_CTRL_CLASS_CAMERA controls, and then EXT controls should be made > accessible by gspca somehow. The UVC driver definitely uses the camera class controls. So they are really meant for webcam use :-) Note that for technical reasons the UVC driver is the only driver that will not use the control framework (partially due to design of the datastructures and partially due to the complex control handling/mapping and the support of dynamic controls in UVC). Perhaps in the future we might try to get it into UVC anyway, but not before all other drivers have been converted. Regards, Hans > > Thanks, >Antonio > > -- 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: gspca V4L2_CID_EXPOSURE_AUTO and VIDIOC_G/S/TRY_EXT_CTRLS
On Fri, 27 Apr 2012 09:53:09 +0200 Jean-Francois Moine wrote: > On Wed, 18 Apr 2012 15:37:20 +0200 > Antonio Ospite wrote: > > > I noticed that AEC (Automatic Exposure Control, or > > V4L2_CID_EXPOSURE_AUTO) does not work in the ov534 gspca driver, either > > from guvcview or qv4l2. > [snip] > > So in ov534, but I think in m5602 too, V4L2_CID_EXPOSURE_AUTO does not > > work from guvcview, qv4l2, or v4l2-ctrl, for instance the latter fails > > with the message: > > > > error 25 getting ext_ctrl Auto Exposure > > > > I tried adding an hackish implementation of vidioc_g_ext_ctrls and > > vidioc_s_ext_ctrls to gspca, and with these V4L2_CID_EXPOSURE_AUTO seems > > to work, but I need to learn more about this kind of controls before > > I can propose a decent implementation for mainline inclusion myself, so > > if anyone wants to anticipate me I'd be glad to test :) > > > > Unrelated, but maybe worth mentioning is that V4L2_CID_EXPOSURE_AUTO is > > of type MENU, while some drivers are treating it as a boolean, I think > > I can fix this one if needed. > > Hi Antonio, > > Yes, V4L2_CID_EXPOSURE_AUTO is of class V4L2_CTRL_CLASS_CAMERA, and, as > the associated menu shows, it is not suitable for webcams. > Where is that menu you refer to? Maybe camera_exposure_auto in drivers/media/video/v4l2-ctrls.c which mentions also "Shutter Priority Mode" and "Aperture Priority Mode"? Naively one would expect that a web _camera_ could use some controls of type V4L2_CTRL_CLASS_CAMERA. > In the webcam world, the autoexposure is often the same as the > autogain: in the knee algorithm > (http://81.209.78.62:8080/docs/LowLightOptimization.html - also look at > gspca/sonixb.c), both exposure and gain are concerned. From the document you point at I still understand that from a user point of view autoexposure and autogain are _independent_ parameters (Table 1), it's just that for such algorithm to work well they should be _both_ enabled. > The cases where > a user wants only autoexposure (fixed gain) or autogain (fixed > exposure) are rare. > > If you want people to be able to do that, you > should add a new webcam control, V4L2_CID_AUTOEXPOSURE, and also add it > to each driver which implements the knee algorithm, and handle the three > cases, autogain only, autoexposure only and knee. The real problem here is that _manual_ exposure does not work in ov534 because the user cannot turn off what we are currently calling auto exposure. > Then, looking about your implementation of vidioc_s_ext_ctrls, I found > it was a bit simple: setting many controls is atomic, i.e., if any > error occurs at some point, the previous controls should be reset to > their original values. Same about vidioc_g_ext_ctrls: the mutex must be > taken only once for the values do not change. You also do not check if > the controls are in a same control class. I see, it was my first shot and I just wanted to start the discussion with a "works here" implementation. I think that using some v4l2 infrastructure like the control-framework like Hans proposes could be better in the long run. IIUC this could also prevent drivers having to handle menu entries themselves like we are doing now in sd_querymenu(), right? If you two reach an agreement and he gets to do it I'll surely port over drivers using V4L2_CID_EXPOSURE_AUTO. > Anyway, are these ioctl's needed? > Whether they are really needed or not, that depends on the definition of webcam, the definition of "camera" in V4L2, and the relationship between the two. If a webcam IS-A v4l2 camera, then I'd expect it to be able to use V4L2_CTRL_CLASS_CAMERA controls, and then EXT controls should be made accessible by gspca somehow. Thanks, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgpk1xnKsnfTC.pgp Description: PGP signature
[GIT PULL FOR v3.5] An ivtv fix and support suspend/resume in radio-keene
Hi Mauro, One small trivial ivtv fix and a patch that adds support for suspend/resume to the radio-keene driver. Regards, Hans The following changes since commit bcb2cf6e0bf033d79821c89e5ccb328bfbd44907: [media] ngene: remove an unneeded condition (2012-04-26 15:29:23 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git fixes for you to fetch changes up to 71ea18d3e92d834926751f8460cf6893424b3852: radio-keene: support suspend/resume. (2012-04-27 09:57:02 +0200) Hans Verkuil (2): ivtv: set max/step to 0 for PTS and FRAME controls. radio-keene: support suspend/resume. drivers/media/radio/radio-keene.c | 20 drivers/media/video/ivtv/ivtv-driver.c |4 ++-- 2 files changed, 22 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.5] Clean up and fix dsbr100
Next in my quest to get old drivers cleaned up and V4L2 compliant is the dsbr100 driver. Changes: - converted to the control framework + control events - overall cleanup - thorough testing using the radio-keene transmitter and v4l2-compliance. - also tested suspend/resume Regards, Hans The following changes since commit bcb2cf6e0bf033d79821c89e5ccb328bfbd44907: [media] ngene: remove an unneeded condition (2012-04-26 15:29:23 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git dsbr100 for you to fetch changes up to 53b0945ea60f5e781004d71f35a458e4d02063da: dsbr100: clean up and update to the latest v4l2 framework (2012-04-27 13:13:26 +0200) Hans Verkuil (1): dsbr100: clean up and update to the latest v4l2 framework drivers/media/radio/dsbr100.c | 527 +- 1 file changed, 165 insertions(+), 362 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/3] [media] gspca - main: implement vidioc_g_ext_ctrls and vidioc_s_ext_ctrls
Hi, On 04/27/2012 11:24 AM, Jean-Francois Moine wrote: On Fri, 27 Apr 2012 10:20:23 +0200 Hans Verkuil wrote: I might have some time (no guarantees yet) to help with this. It would certainly be interesting to add support for the control framework in the gspca core. Hmm, perhaps that's a job for the weekend... Hi Hans, I hope you will not do it! The way gspca treats the controls is static, quick and very small. The controls in the subdrivers ask only for the declaration of the controls and functions to send the values to the webcams. Actually, not all subdrivers have been converted to the new gspca control handling, but, when done, it will save more memory. Actually I've moving gspca over to the control framework on my to-do list. This will allows us to remove hacks like we have in sonixb.c for coarse exposure / fine exposure controls. More in general it will allow (in an easy way) to have per sensor control min/max/step values. But the most important reason for me to want to use the control framework in gspca is to get support for control events. Which allow a control-panel app to dynamically update its display when settings are changed to some other way (ie another control app, or software autogain). I do plan to do this in way so that we can do this one subdriver at a time. I've no idea when I'll get around to doing the first driver though :) Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6 v2] dvbsky, montage dvb-s/s2 TS202x tuner and M88DS3103 demodulator driver
Em 27-04-2012 04:06, nibble.max escreveu: > --- > drivers/media/dvb/frontends/Kconfig | 14 + > drivers/media/dvb/frontends/Makefile |3 + > drivers/media/dvb/frontends/m88ds3103.c | 1153 > ++ > drivers/media/dvb/frontends/m88ds3103.h | 67 ++ > drivers/media/dvb/frontends/m88ds3103_priv.h | 413 + > drivers/media/dvb/frontends/m88ts202x.c | 590 + > drivers/media/dvb/frontends/m88ts202x.h | 63 ++ > 7 files changed, 2303 insertions(+) > create mode 100644 drivers/media/dvb/frontends/m88ds3103.c > create mode 100644 drivers/media/dvb/frontends/m88ds3103.h > create mode 100644 drivers/media/dvb/frontends/m88ds3103_priv.h > create mode 100644 drivers/media/dvb/frontends/m88ts202x.c > create mode 100644 drivers/media/dvb/frontends/m88ts202x.h No, this is not what we've agreed. You should, instead, take Konstantin's driver, breaking it into two separate ones, without touching the copyrights. Then, apply what else is needed for ds3103/ts2123. > diff --git a/drivers/media/dvb/frontends/m88ds3103.c > b/drivers/media/dvb/frontends/m88ds3103.c > new file mode 100644 > index 000..392cada > --- /dev/null > +++ b/drivers/media/dvb/frontends/m88ds3103.c > @@ -0,0 +1,1153 @@ > +/* > +Montage Technology M88DS3103/3000 - DVBS/S2 Satellite demod driver > + > +Copyright (C) 2011 Max nibble Adding your copyright like that only justifies if you make significant contributions to the code. Adding support for a new card or a new chip within the same chip family in general don't fit on that. If Konstantin is ok, you may, instead, add, at the bottom of the copyright list, something like: Copyright (C) 2011 Max nibble - Add support for ds3103 > +Copyright (C) 2010 Montage Technology > +Fix some bug and add M88DS3103 code, M88DS3000 code based on DS3000.c. > + > +Copyright (C) 2009 Konstantin Dimitrov > + > +Copyright (C) 2009 TurboSight.com Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] V4L: Extend V4L2_CID_COLORFX with more image effects
Hi Sylwester! On Friday, April 27, 2012 11:52:54 Sylwester Nawrocki wrote: > This patch adds definition of additional color effects: > - V4L2_COLORFX_AQUA, > - V4L2_COLORFX_ART_FREEZE, > - V4L2_COLORFX_SILHOUETTE, > - V4L2_COLORFX_SOLARIZATION, > - V4L2_COLORFX_ANTIQUE, > - V4L2_COLORFX_ARBITRARY_CBCR. > > The control's type in the documentation is changed from 'enum' to 'menu' > - V4L2_CID_COLORFX has always been a menu, not an integer type control. > > The V4L2_COLORFX_ARBITRARY_CBCR option enables custom color effects, > which are impossible or impractical to define as menu items. The > V4L2_CID_BLUE_BALANCE and V4L2_CID_RED_BALANCE controls allow in this > case to configure the Cb, Cr coefficients. So this just hijacks the RED/BLUE_BALANCE controls for a different purpose? If I understand this 'effect' correctly it just replaces the Cb and Cr coefficients with fixed values, basically giving you a B&W picture (the Y coefficient), except that it is really a 'Black&FixedColor' picture. I think you should add a new control for setting this. V4L2_CID_COLORFX_COLOR or something. Regards, Hans > > Signed-off-by: Sylwester Nawrocki > Signed-off-by: Kyungmin Park > --- > Documentation/DocBook/media/v4l/compat.xml | 10 +++ > Documentation/DocBook/media/v4l/controls.xml | 92 > ++ > Documentation/DocBook/media/v4l/v4l2.xml |5 +- > drivers/media/video/v4l2-ctrls.c |6 ++ > include/linux/videodev2.h| 26 +--- > 5 files changed, 114 insertions(+), 25 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/compat.xml > b/Documentation/DocBook/media/v4l/compat.xml > index 87339b2..a6a9c5c 100644 > --- a/Documentation/DocBook/media/v4l/compat.xml > +++ b/Documentation/DocBook/media/v4l/compat.xml > @@ -2422,6 +2422,16 @@ details. > &VIDIOC-SUBDEV-G-SELECTION; and > &VIDIOC-SUBDEV-S-SELECTION;. > > + > +Added V4L2_COLORFX_ANTIQUE, > + V4L2_COLORFX_ART_FREEZE, > + V4L2_COLORFX_AQUA, > + V4L2_COLORFX_SILHOUETTE, > + V4L2_COLORFX_SOLARIZATION, > + V4L2_COLORFX_VIVID and > + V4L2_COLORFX_ARBITRARY_CBCR menu items > +to the V4L2_CID_COLORFX control. > + > > > > diff --git a/Documentation/DocBook/media/v4l/controls.xml > b/Documentation/DocBook/media/v4l/controls.xml > index 5038a3a..8b604b0 100644 > --- a/Documentation/DocBook/media/v4l/controls.xml > +++ b/Documentation/DocBook/media/v4l/controls.xml > @@ -284,19 +284,85 @@ minimum value disables backlight compensation. > > > V4L2_CID_COLORFX > - enum > - Selects a color effect. Possible values for > -enum v4l2_colorfx are: > -V4L2_COLORFX_NONE (0), > -V4L2_COLORFX_BW (1), > -V4L2_COLORFX_SEPIA (2), > -V4L2_COLORFX_NEGATIVE (3), > -V4L2_COLORFX_EMBOSS (4), > -V4L2_COLORFX_SKETCH (5), > -V4L2_COLORFX_SKY_BLUE (6), > -V4L2_COLORFX_GRASS_GREEN (7), > -V4L2_COLORFX_SKIN_WHITEN (8) and > -V4L2_COLORFX_VIVID (9). > + menu > + Selects a color effect. The following values are defined: > + > + > + > + > + > + > + > + V4L2_COLORFX_NONE > + Color effect is disabled. > + > + > + V4L2_COLORFX_ANTIQUE > + An aging (old photo) effect. > + > + > + > V4L2_COLORFX_ART_FREEZE > + Frost color effect. > + > + > + V4L2_COLORFX_AQUA > + Water color, cool tone. > + > + > + V4L2_COLORFX_BW > + Black and white. > + > + > + V4L2_COLORFX_EMBOSS > + Emboss, the highlights and shadows replace light/dark > boundaries > + and low contrast areas are set to a gray background. > + > + > + > V4L2_COLORFX_GRASS_GREEN > + Grass green. > + > + > + > V4L2_COLORFX_NEGATIVE > + Negative. > + > + > + V4L2_COLORFX_SEPIA > + Sepia tone. > + > + > + V4L2_COLORFX_SKETCH > + Sketch. > + > + > + > V4L2_COLORFX_SKIN_WHITEN > + Skin whiten. > + > + > + > V4L2_COLORFX_SKY_BLUE > + Sky blue. > + > + > + > V4L2_COLORFX_SOLARIZATION > + Solarization, the image is partially reversed in tone, > + only color values above or below a certain threshold are > inverted. > + > + > + > + > V4L2_COLORFX_SILHOUETTE > + Sil
[PATCH 06/13] s5p-fimc: Add FIMC-LITE register definitions
Add register definitions and register API for FIMC-LITE devices.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-lite-reg.c | 301 ++
drivers/media/video/s5p-fimc/fimc-lite-reg.h | 153 +
drivers/media/video/s5p-fimc/fimc-lite.h | 212 ++
3 files changed, 666 insertions(+)
create mode 100644 drivers/media/video/s5p-fimc/fimc-lite-reg.c
create mode 100644 drivers/media/video/s5p-fimc/fimc-lite-reg.h
create mode 100644 drivers/media/video/s5p-fimc/fimc-lite.h
diff --git a/drivers/media/video/s5p-fimc/fimc-lite-reg.c
b/drivers/media/video/s5p-fimc/fimc-lite-reg.c
new file mode 100644
index 000..7a20c45
--- /dev/null
+++ b/drivers/media/video/s5p-fimc/fimc-lite-reg.c
@@ -0,0 +1,301 @@
+/*
+ * Register interface file for EXYNOS FIMC-LITE (camera interface) driver
+ *
+ * Copyright (C) 2012 Samsung Electronics Co., Ltd.
+ * Sylwester Nawrocki
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include
+#include
+#include
+
+#include "fimc-lite-reg.h"
+#include "fimc-lite.h"
+#include "fimc-core.h"
+
+#define FLITE_RESET_TIMEOUT 50 /* in ms FIXME: */
+
+void flite_hw_reset(struct fimc_lite *dev)
+{
+ unsigned long end = jiffies + msecs_to_jiffies(FLITE_RESET_TIMEOUT);
+ u32 cfg;
+
+ cfg = readl(dev->regs + FLITE_REG_CIGCTRL);
+ cfg |= FLITE_REG_CIGCTRL_SWRST_REQ;
+ writel(cfg, dev->regs + FLITE_REG_CIGCTRL);
+
+ while (time_is_after_jiffies(end)) {
+ cfg = readl(dev->regs + FLITE_REG_CIGCTRL);
+ if (cfg & FLITE_REG_CIGCTRL_SWRST_RDY)
+ break;
+ usleep_range(1000, 5000);
+ }
+
+ cfg |= FLITE_REG_CIGCTRL_SWRST;
+ writel(cfg, dev->regs + FLITE_REG_CIGCTRL);
+}
+
+void flite_hw_clear_pending_irq(struct fimc_lite *dev)
+{
+ u32 cfg = readl(dev->regs + FLITE_REG_CISTATUS);
+ cfg &= ~FLITE_REG_CISTATUS_IRQ_CAM;
+ writel(cfg, dev->regs + FLITE_REG_CISTATUS);
+}
+
+u32 flite_hw_get_interrupt_source(struct fimc_lite *dev)
+{
+ u32 intsrc = readl(dev->regs + FLITE_REG_CISTATUS);
+ return intsrc & FLITE_REG_CISTATUS_IRQ_MASK;
+}
+
+void flite_hw_clear_last_capture_end(struct fimc_lite *dev)
+{
+
+ u32 cfg = readl(dev->regs + FLITE_REG_CISTATUS2);
+ cfg &= ~FLITE_REG_CISTATUS2_LASTCAPEND;
+ writel(cfg, dev->regs + FLITE_REG_CISTATUS2);
+}
+
+void flite_hw_set_interrupt_mask(struct fimc_lite *dev)
+{
+ u32 cfg, intsrc;
+
+ /* Select interrupts to be enabled for each output mode */
+ if (dev->out_path == FIMC_IO_DMA) {
+ intsrc = FLITE_REG_CIGCTRL_IRQ_OVFEN |
+FLITE_REG_CIGCTRL_IRQ_LASTEN |
+/* FLITE_REG_CIGCTRL_IRQ_ENDEN0 | */
+ FLITE_REG_CIGCTRL_IRQ_STARTEN;
+ } else {
+ /* An output to the FIMC-IS */
+ intsrc = FLITE_REG_CIGCTRL_IRQ_OVFEN |
+FLITE_REG_CIGCTRL_IRQ_LASTEN;
+ }
+
+ cfg = readl(dev->regs + FLITE_REG_CIGCTRL);
+ cfg |= FLITE_REG_CIGCTRL_IRQ_DISABLE_MASK;
+ cfg &= ~intsrc;
+ writel(cfg, dev->regs + FLITE_REG_CIGCTRL);
+}
+
+void flite_hw_capture_start(struct fimc_lite *dev)
+{
+ u32 cfg = readl(dev->regs + FLITE_REG_CIIMGCPT);
+ cfg |= FLITE_REG_CIIMGCPT_IMGCPTEN;
+ writel(cfg, dev->regs + FLITE_REG_CIIMGCPT);
+}
+
+void flite_hw_capture_stop(struct fimc_lite *dev)
+{
+ u32 cfg = readl(dev->regs + FLITE_REG_CIIMGCPT);
+ cfg &= ~FLITE_REG_CIIMGCPT_IMGCPTEN;
+ writel(cfg, dev->regs + FLITE_REG_CIIMGCPT);
+}
+
+/*
+ * Test pattern (color bars) enable/disable. External sensor
+ * pixel clock must be active for the test pattern to work.
+ */
+void flite_hw_set_test_pattern(struct fimc_lite *dev, bool on)
+{
+ u32 cfg = readl(dev->regs + FLITE_REG_CIGCTRL);
+ if (on)
+ cfg |= FLITE_REG_CIGCTRL_TEST_PATTERN_COLORBAR;
+ else
+ cfg &= ~FLITE_REG_CIGCTRL_TEST_PATTERN_COLORBAR;
+ writel(cfg, dev->regs + FLITE_REG_CIGCTRL);
+}
+
+static const u32 src_pixfmt_map[8][3] = {
+ { V4L2_MBUS_FMT_YUYV8_2X8, FLITE_REG_CISRCSIZE_ORDER422_IN_YCBYCR,
+ FLITE_REG_CIGCTRL_YUV422_1P },
+ { V4L2_MBUS_FMT_YVYU8_2X8, FLITE_REG_CISRCSIZE_ORDER422_IN_YCRYCB,
+ FLITE_REG_CIGCTRL_YUV422_1P },
+ { V4L2_MBUS_FMT_UYVY8_2X8, FLITE_REG_CISRCSIZE_ORDER422_IN_CBYCRY,
+ FLITE_REG_CIGCTRL_YUV422_1P },
+ { V4L2_MBUS_FMT_VYUY8_2X8, FLITE_REG_CISRCSIZE_ORDER422_IN_CRYCBY,
+ FLITE_REG_CIGCTRL_YUV422_1P },
+ { V4L2_PIX_FMT_SGRBG8, 0, FLITE_REG_CIGCTRL_RAW8 },
+ { V4L2_PIX_FMT_SGRBG10, 0, FLITE_REG_CIGCTRL_RAW10 },
+ { V4L2_PIX_FMT_SGRBG12, 0, FLITE_REG_CIGCTRL_RAW12 },
+ {
[PATCH 11/13] s5p-fimc: Add support for Exynos4x12 FIMC-LITE
This patch adds driver for FIMC-LITE camera host interface. This new IP differs from the regular FIMC IP in that it doesn't have input DMA, scaler and color space conversion support. So it just plain camera host interface for MIPI-CSI2 and ITU-R interfaces. For the serial bus support it interworks with MIPI-CSIS and the exisiting s5p-csis driver. The FIMC-LITE and MIPI-CSIS drivers can also be reused in the Exynos5 SoC series. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- drivers/media/video/Kconfig | 24 +- drivers/media/video/s5p-fimc/Kconfig| 47 + drivers/media/video/s5p-fimc/Makefile |4 +- drivers/media/video/s5p-fimc/fimc-core.h|1 + drivers/media/video/s5p-fimc/fimc-lite.c| 1589 +++ drivers/media/video/s5p-fimc/fimc-mdevice.c | 152 ++- drivers/media/video/s5p-fimc/fimc-mdevice.h |5 +- 7 files changed, 1778 insertions(+), 44 deletions(-) create mode 100644 drivers/media/video/s5p-fimc/Kconfig create mode 100644 drivers/media/video/s5p-fimc/fimc-lite.c diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index f2479c5..2885516 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -1127,19 +1127,6 @@ config VIDEO_MX2 This is a v4l2 driver for the i.MX27 and the i.MX25 Camera Sensor Interface -config VIDEO_SAMSUNG_S5P_FIMC - tristate "Samsung S5P and EXYNOS4 camera interface driver (EXPERIMENTAL)" - depends on VIDEO_V4L2 && I2C && PLAT_S5P && PM_RUNTIME && \ - VIDEO_V4L2_SUBDEV_API && EXPERIMENTAL - select VIDEOBUF2_DMA_CONTIG - select V4L2_MEM2MEM_DEV - ---help--- - This is a v4l2 driver for Samsung S5P and EXYNOS4 camera - host interface and video postprocessor. - - To compile this driver as a module, choose M here: the - module will be called s5p-fimc. - config VIDEO_ATMEL_ISI tristate "ATMEL Image Sensor Interface (ISI) support" depends on VIDEO_DEV && SOC_CAMERA && ARCH_AT91 @@ -1148,16 +1135,7 @@ config VIDEO_ATMEL_ISI This module makes the ATMEL Image Sensor Interface available as a v4l2 device. -config VIDEO_S5P_MIPI_CSIS - tristate "Samsung S5P and EXYNOS4 MIPI CSI receiver driver" - depends on VIDEO_V4L2 && PM_RUNTIME && PLAT_S5P - depends on VIDEO_V4L2_SUBDEV_API && REGULATOR - ---help--- - This is a v4l2 driver for Samsung S5P/EXYNOS4 MIPI-CSI receiver. - - To compile this driver as a module, choose M here: the - module will be called s5p-csis. - +source "drivers/media/video/s5p-fimc/Kconfig" source "drivers/media/video/s5p-tv/Kconfig" endif # V4L_PLATFORM_DRIVERS diff --git a/drivers/media/video/s5p-fimc/Kconfig b/drivers/media/video/s5p-fimc/Kconfig new file mode 100644 index 000..383458f --- /dev/null +++ b/drivers/media/video/s5p-fimc/Kconfig @@ -0,0 +1,47 @@ + +config VIDEO_SAMSUNG_S5P_FIMC + bool "Samsung S5P/EXYNOS SoC camera interface driver (experimental)" + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && PLAT_S5P && PM_RUNTIME + depends on EXPERIMENTAL + help + Say Y here to enable camera host interface devices for + Samsung S5P and EXYNOS SoC series. + +if VIDEO_SAMSUNG_S5P_FIMC + +config VIDEO_S5P_FIMC + tristate "S5P/EXYNOS4 FIMC/CAMIF camera interface driver" + depends on I2C + select VIDEOBUF2_DMA_CONTIG + select V4L2_MEM2MEM_DEV + help + This is a V4L2 driver for Samsung S5P and EXYNOS4 SoC camera host + interface and video postprocessor (FIMC and FIMC-LITE) devices. + + To compile this driver as a module, choose M here: the + module will be called s5p-fimc. + +config VIDEO_S5P_MIPI_CSIS + tristate "S5P/EXYNOS MIPI-CSI2 receiver (MIPI-CSIS) driver" + depends on REGULATOR + help + This is a V4L2 driver for Samsung S5P and EXYNOS4 SoC MIPI-CSI2 + receiver (MIPI-CSIS) devices. + + To compile this driver as a module, choose M here: the + module will be called s5p-csis. + +if ARCH_EXYNOS + +config VIDEO_EXYNOS_FIMC_LITE + tristate "EXYNOS FIMC-LITE camera interface driver" + depends on I2C + help + This is a V4L2 driver for Samsung EXYNOS4/5 SoC FIMC-LITE camera + host interface. + + To compile this driver as a module, choose M here: the + module will be called exynos-fimc-lite. +endif + +endif # VIDEO_SAMSUNG_S5P_FIMC diff --git a/drivers/media/video/s5p-fimc/Makefile b/drivers/media/video/s5p-fimc/Makefile index 1da3c6a..4648514 100644 --- a/drivers/media/video/s5p-fimc/Makefile +++ b/drivers/media/video/s5p-fimc/Makefile @@ -1,5 +1,7 @@ s5p-fimc-objs := fimc-core.o fimc-reg.o fimc-m2m.o fimc-capture.o fimc-mdevice.o +exynos-fimc-lite-objs += fimc-lite-reg.o fimc-lite.o s5p-csis-objs := mipi-csis.o obj-$(CONFIG_VIDEO_S5P_MIPI_CSI
[PATCH 10/13] s5p-fimc: Minor cleanups
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c | 31 ---
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 18f686a1..fde7033 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -31,7 +31,7 @@
#include "fimc-core.h"
#include "fimc-reg.h"
-static int fimc_init_capture(struct fimc_dev *fimc)
+static int fimc_capture_hw_init(struct fimc_dev *fimc)
{
struct fimc_ctx *ctx = fimc->vid_cap.ctx;
struct fimc_pipeline *p = &fimc->pipeline;
@@ -73,7 +73,15 @@ static int fimc_init_capture(struct fimc_dev *fimc)
return ret;
}
-static int fimc_capture_state_cleanup(struct fimc_dev *fimc, bool suspend)
+/*
+ * Reinitialize the driver so it is ready to start the streaming again.
+ * Set fimc->state to indicate stream off and the hardware shut down state.
+ * If not suspending (@suspend is false), return any buffers to videobuf2.
+ * Otherwise put any owned buffers onto the pending buffers queue, so they
+ * can be re-spun when the device is being resumed. Also perform FIMC
+ * software reset and disable streaming on the whole pipeline if required.
+ */
+static int fimc_capture_reinit(struct fimc_dev *fimc, bool suspend)
{
struct fimc_vid_cap *cap = &fimc->vid_cap;
struct fimc_vid_buffer *buf;
@@ -146,9 +154,6 @@ static int fimc_capture_config_update(struct fimc_ctx *ctx)
struct fimc_dev *fimc = ctx->fimc_dev;
int ret;
- if (!test_bit(ST_CAPT_APPLY_CFG, &fimc->state))
- return 0;
-
fimc_hw_set_camera_offset(fimc, &ctx->s_frame);
ret = fimc_set_scaler_info(ctx);
@@ -224,7 +229,8 @@ void fimc_capture_irq_handler(struct fimc_dev *fimc)
set_bit(ST_CAPT_RUN, &fimc->state);
}
- fimc_capture_config_update(cap->ctx);
+ if (test_bit(ST_CAPT_APPLY_CFG, &fimc->state))
+ fimc_capture_config_update(cap->ctx);
done:
if (cap->active_buf_cnt == 1) {
fimc_deactivate_capture(fimc);
@@ -246,9 +252,11 @@ static int start_streaming(struct vb2_queue *q, unsigned
int count)
vid_cap->frame_count = 0;
- ret = fimc_init_capture(fimc);
- if (ret)
- goto error;
+ ret = fimc_capture_hw_init(fimc);
+ if (ret) {
+ fimc_capture_reinit(fimc, false);
+ return ret;
+ }
set_bit(ST_CAPT_PEND, &fimc->state);
@@ -263,9 +271,6 @@ static int start_streaming(struct vb2_queue *q, unsigned
int count)
}
return 0;
-error:
- fimc_capture_state_cleanup(fimc, false);
- return ret;
}
static int stop_streaming(struct vb2_queue *q)
@@ -304,7 +309,7 @@ int fimc_capture_resume(struct fimc_dev *fimc)
vid_cap->buf_index = 0;
fimc_pipeline_initialize(&fimc->pipeline, &vid_cap->vfd->entity,
false);
- fimc_init_capture(fimc);
+ fimc_capture_hw_init(fimc);
clear_bit(ST_CAPT_SUSPENDED, &fimc->state);
--
1.7.10
--
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 13/13] s5p-fimc: Add color effect control
Add support for V4L2_CID_COLORFX control at the mem-to-mem and capture
video nodes.
Signed-off-by: Sylwester Nawrocki
---
drivers/media/video/s5p-fimc/fimc-capture.c | 11 +--
drivers/media/video/s5p-fimc/fimc-core.c| 127 +--
drivers/media/video/s5p-fimc/fimc-core.h| 39 +---
drivers/media/video/s5p-fimc/fimc-m2m.c |4 +-
drivers/media/video/s5p-fimc/fimc-reg.c |4 +-
drivers/media/video/s5p-fimc/fimc-reg.h |2 +-
6 files changed, 137 insertions(+), 50 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 9a6224f..0d675a5 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -62,7 +62,7 @@ static int fimc_capture_hw_init(struct fimc_dev *fimc)
fimc_hw_set_mainscaler(ctx);
fimc_hw_set_target_format(ctx);
fimc_hw_set_rotation(ctx);
- fimc_hw_set_effect(ctx, false);
+ fimc_hw_set_effect(ctx);
fimc_hw_set_output_path(ctx);
fimc_hw_set_out_dma(ctx);
if (fimc->variant->has_alpha)
@@ -164,6 +164,7 @@ static int fimc_capture_config_update(struct fimc_ctx *ctx)
fimc_hw_set_mainscaler(ctx);
fimc_hw_set_target_format(ctx);
fimc_hw_set_rotation(ctx);
+ fimc_hw_set_effect(ctx);
fimc_prepare_dma_offset(ctx, &ctx->d_frame);
fimc_hw_set_out_dma(ctx);
if (fimc->variant->has_alpha)
@@ -457,14 +458,14 @@ int fimc_capture_ctrls_create(struct fimc_dev *fimc)
if (WARN_ON(vid_cap->ctx == NULL))
return -ENXIO;
- if (vid_cap->ctx->ctrls_rdy)
+ if (vid_cap->ctx->ctrls.ready)
return 0;
ret = fimc_ctrls_create(vid_cap->ctx);
- if (ret || vid_cap->user_subdev_api)
+ if (ret || vid_cap->user_subdev_api || !vid_cap->ctx->ctrls.ready)
return ret;
- return v4l2_ctrl_add_handler(&vid_cap->ctx->ctrl_handler,
+ return v4l2_ctrl_add_handler(&vid_cap->ctx->ctrls.handler,
fimc->pipeline.subdevs[IDX_SENSOR]->ctrl_handler);
}
@@ -1579,7 +1580,7 @@ static int fimc_register_capture_device(struct fimc_dev
*fimc,
v4l2_info(v4l2_dev, "Registered %s as /dev/%s\n",
vfd->name, video_device_node_name(vfd));
- vfd->ctrl_handler = &ctx->ctrl_handler;
+ vfd->ctrl_handler = &ctx->ctrls.handler;
return 0;
err_vd:
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index d5872e6..2540243 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -461,11 +461,53 @@ void fimc_prepare_dma_offset(struct fimc_ctx *ctx, struct
fimc_frame *f)
f->fmt->color, f->dma_offset.y_h, f->dma_offset.y_v);
}
+int fimc_set_color_effect(struct fimc_ctx *ctx, enum v4l2_colorfx colorfx)
+{
+ struct fimc_effect *effect = &ctx->effect;
+
+ switch (colorfx) {
+ case V4L2_COLORFX_NONE:
+ effect->type = FIMC_REG_CIIMGEFF_FIN_BYPASS;
+ break;
+ case V4L2_COLORFX_BW:
+ effect->type = FIMC_REG_CIIMGEFF_FIN_ARBITRARY;
+ effect->pat_cb = 128;
+ effect->pat_cr = 128;
+ break;
+ case V4L2_COLORFX_SEPIA:
+ effect->type = FIMC_REG_CIIMGEFF_FIN_ARBITRARY;
+ effect->pat_cb = 115;
+ effect->pat_cr = 145;
+ break;
+ case V4L2_COLORFX_NEGATIVE:
+ effect->type = FIMC_REG_CIIMGEFF_FIN_NEGATIVE;
+ break;
+ case V4L2_COLORFX_EMBOSS:
+ effect->type = FIMC_REG_CIIMGEFF_FIN_EMBOSSING;
+ break;
+ case V4L2_COLORFX_ART_FREEZE:
+ effect->type = FIMC_REG_CIIMGEFF_FIN_ARTFREEZE;
+ break;
+ case V4L2_COLORFX_SILHOUETTE:
+ effect->type = FIMC_REG_CIIMGEFF_FIN_SILHOUETTE;
+ break;
+ case V4L2_COLORFX_ARBITRARY_CBCR:
+ effect->type = FIMC_REG_CIIMGEFF_FIN_ARBITRARY;
+ effect->pat_cb = ctx->ctrls.colorfx_cb->val;
+ effect->pat_cr = ctx->ctrls.colorfx_cr->val;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
/*
* V4L2 controls handling
*/
#define ctrl_to_ctx(__ctrl) \
- container_of((__ctrl)->handler, struct fimc_ctx, ctrl_handler)
+ container_of((__ctrl)->handler, struct fimc_ctx, ctrls.handler)
static int __fimc_s_ctrl(struct fimc_ctx *ctx, struct v4l2_ctrl *ctrl)
{
@@ -505,7 +547,14 @@ static int __fimc_s_ctrl(struct fimc_ctx *ctx, struct
v4l2_ctrl *ctrl)
case V4L2_CID_ALPHA_COMPONENT:
ctx->d_frame.alpha = ctrl->val;
break;
+
+ case V4L2_CID_COLORFX:
+ ret = fimc_set_color_effect(ct
[PATCH 07/13] s5p-fimc: Rework the video pipeline control functions
There is getting more entities to manage within single video pipeline
in newer SoCs. To simplify code put subdevs' pointer into an array
rather than adding new member in struct fimc_pipeline for each subdev.
This allows to easier handle subdev operations in proper order.
Additionally walk graph in one direction only in fimc_pipeline_prepare()
function to make sure we properly gather only media entities that below
to single data pipeline. This avoids wrong initialization in case where,
for example there are multiple active links from s5p-mipi-csis subdev
output pad.
struct fimc_pipeline declaration is moved to the driver's public header
to allow other drivers to reuse the fimc-lite driver added in subsequent
patches.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c | 34 +++---
drivers/media/video/s5p-fimc/fimc-core.h|5 -
drivers/media/video/s5p-fimc/fimc-mdevice.c | 164 +--
drivers/media/video/s5p-fimc/fimc-mdevice.h | 10 +-
include/media/s5p_fimc.h| 16 +++
5 files changed, 140 insertions(+), 89 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index fca8c4b..e6e5496 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -34,16 +34,17 @@
static int fimc_init_capture(struct fimc_dev *fimc)
{
struct fimc_ctx *ctx = fimc->vid_cap.ctx;
+ struct fimc_pipeline *p = &fimc->pipeline;
struct fimc_sensor_info *sensor;
unsigned long flags;
int ret = 0;
- if (fimc->pipeline.sensor == NULL || ctx == NULL)
+ if (p->subdevs[IDX_SENSOR] == NULL || ctx == NULL)
return -ENXIO;
if (ctx->s_frame.fmt == NULL)
return -EINVAL;
- sensor = v4l2_get_subdev_hostdata(fimc->pipeline.sensor);
+ sensor = v4l2_get_subdev_hostdata(p->subdevs[IDX_SENSOR]);
spin_lock_irqsave(&fimc->slock, flags);
fimc_prepare_dma_offset(ctx, &ctx->d_frame);
@@ -109,7 +110,7 @@ static int fimc_capture_state_cleanup(struct fimc_dev
*fimc, bool suspend)
spin_unlock_irqrestore(&fimc->slock, flags);
if (streaming)
- return fimc_pipeline_s_stream(fimc, 0);
+ return fimc_pipeline_s_stream(&fimc->pipeline, 0);
else
return 0;
}
@@ -130,7 +131,7 @@ static int fimc_stop_capture(struct fimc_dev *fimc, bool
suspend)
!test_bit(ST_CAPT_SHUT, &fimc->state),
(2*HZ/10)); /* 200 ms */
- return fimc_capture_state_cleanup(fimc, suspend);
+ return fimc_capture_reinit(fimc, suspend);
}
/**
@@ -258,7 +259,7 @@ static int start_streaming(struct vb2_queue *q, unsigned
int count)
fimc_activate_capture(ctx);
if (!test_and_set_bit(ST_CAPT_ISP_STREAM, &fimc->state))
- fimc_pipeline_s_stream(fimc, 1);
+ fimc_pipeline_s_stream(&fimc->pipeline, 1);
}
return 0;
@@ -285,7 +286,7 @@ int fimc_capture_suspend(struct fimc_dev *fimc)
int ret = fimc_stop_capture(fimc, suspend);
if (ret)
return ret;
- return fimc_pipeline_shutdown(fimc);
+ return fimc_pipeline_shutdown(&fimc->pipeline);
}
static void buffer_queue(struct vb2_buffer *vb);
@@ -301,7 +302,7 @@ int fimc_capture_resume(struct fimc_dev *fimc)
INIT_LIST_HEAD(&fimc->vid_cap.active_buf_q);
vid_cap->buf_index = 0;
- fimc_pipeline_initialize(fimc, &fimc->vid_cap.vfd->entity,
+ fimc_pipeline_initialize(&fimc->pipeline, &vid_cap->vfd->entity,
false);
fimc_init_capture(fimc);
@@ -409,7 +410,7 @@ static void buffer_queue(struct vb2_buffer *vb)
spin_unlock_irqrestore(&fimc->slock, flags);
if (!test_and_set_bit(ST_CAPT_ISP_STREAM, &fimc->state))
- fimc_pipeline_s_stream(fimc, 1);
+ fimc_pipeline_s_stream(&fimc->pipeline, 1);
return;
}
spin_unlock_irqrestore(&fimc->slock, flags);
@@ -459,7 +460,7 @@ int fimc_capture_ctrls_create(struct fimc_dev *fimc)
return ret;
return v4l2_ctrl_add_handler(&vid_cap->ctx->ctrl_handler,
- fimc->pipeline.sensor->ctrl_handler);
+ fimc->pipeline.subdevs[IDX_SENSOR]->ctrl_handler);
}
static int fimc_capture_set_default_format(struct fimc_dev *fimc);
@@ -482,7 +483,7 @@ static int fimc_capture_open(struct file *file)
pm_runtime_get_sync(&fimc->pdev->dev);
if (++fimc->vid_cap.refcnt == 1) {
- ret = fimc_pipeline_initialize(fimc,
+ ret = fimc_pipeline_initialize(&fimc->pipeline,
&fimc->vid_cap.vfd->entity, true);
if
[PATCH 09/13] s5p-fimc: Make sure the interrupt is properly requested
Use dev_name() for requesting an interrupt so we don't get an interrupt
requested with same name for multiple device instances.
While at it, tidy up the driver data handling.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-core.c |9 +++--
drivers/media/video/s5p-fimc/fimc-core.h |2 ++
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 2da6638..f67c3b6 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -792,15 +792,12 @@ static int fimc_m2m_resume(struct fimc_dev *fimc)
static int fimc_probe(struct platform_device *pdev)
{
+ struct fimc_drvdata *drv_data = fimc_get_drvdata(pdev);
+ struct s5p_platform_fimc *pdata;
struct fimc_dev *fimc;
struct resource *res;
- struct fimc_drvdata *drv_data;
- struct s5p_platform_fimc *pdata;
int ret = 0;
- drv_data = (struct fimc_drvdata *)
- platform_get_device_id(pdev)->driver_data;
-
if (pdev->id >= ARRAY_SIZE(drv_data->variant)) {
dev_err(&pdev->dev, "Invalid platform device id: %d\n",
pdev->id);
@@ -844,7 +841,7 @@ static int fimc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, fimc);
ret = devm_request_irq(&pdev->dev, res->start, fimc_irq_handler,
- 0, pdev->name, fimc);
+ 0, dev_name(&pdev->dev), fimc);
if (ret) {
dev_err(&pdev->dev, "failed to install irq (%d)\n", ret);
goto err_clk;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index e3078d3..cbd1137 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -401,6 +401,8 @@ struct fimc_drvdata {
unsigned long lclk_frequency;
};
+#define fimc_get_drvdata(_pdev) \
+ ((struct fimc_drvdata *) platform_get_device_id(_pdev)->driver_data)
struct fimc_ctx;
--
1.7.10
--
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 08/13] s5p-fimc: Prefix format enumerations with FIMC_FMT_
Prefix the pixel format enumerations with FIMC_FMT_ to make it more clear,
especially when used in new IP drivers, like fimc-lite, etc. Also add IO_
prefix in the input/output enumeration.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c |4 +-
drivers/media/video/s5p-fimc/fimc-core.c| 56 +--
drivers/media/video/s5p-fimc/fimc-core.h| 45 +++--
drivers/media/video/s5p-fimc/fimc-m2m.c |4 +-
drivers/media/video/s5p-fimc/fimc-reg.c | 48 +++
5 files changed, 81 insertions(+), 76 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index e6e5496..18f686a1 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -1519,8 +1519,8 @@ static int fimc_register_capture_device(struct fimc_dev
*fimc,
return -ENOMEM;
ctx->fimc_dev= fimc;
- ctx->in_path = FIMC_CAMERA;
- ctx->out_path= FIMC_DMA;
+ ctx->in_path = FIMC_IO_CAMERA;
+ ctx->out_path= FIMC_IO_DMA;
ctx->state = FIMC_CTX_CAP;
ctx->s_frame.fmt = fimc_find_format(NULL, NULL, FMT_FLAGS_CAM, 0);
ctx->d_frame.fmt = ctx->s_frame.fmt;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index e4c58e9..2da6638 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -40,7 +40,7 @@ static struct fimc_fmt fimc_formats[] = {
.name = "RGB565",
.fourcc = V4L2_PIX_FMT_RGB565,
.depth = { 16 },
- .color = S5P_FIMC_RGB565,
+ .color = FIMC_FMT_RGB565,
.memplanes = 1,
.colplanes = 1,
.flags = FMT_FLAGS_M2M,
@@ -48,7 +48,7 @@ static struct fimc_fmt fimc_formats[] = {
.name = "BGR666",
.fourcc = V4L2_PIX_FMT_BGR666,
.depth = { 32 },
- .color = S5P_FIMC_RGB666,
+ .color = FIMC_FMT_RGB666,
.memplanes = 1,
.colplanes = 1,
.flags = FMT_FLAGS_M2M,
@@ -56,7 +56,7 @@ static struct fimc_fmt fimc_formats[] = {
.name = "ARGB, 32 bpp",
.fourcc = V4L2_PIX_FMT_RGB32,
.depth = { 32 },
- .color = S5P_FIMC_RGB888,
+ .color = FIMC_FMT_RGB888,
.memplanes = 1,
.colplanes = 1,
.flags = FMT_FLAGS_M2M | FMT_HAS_ALPHA,
@@ -64,7 +64,7 @@ static struct fimc_fmt fimc_formats[] = {
.name = "ARGB1555",
.fourcc = V4L2_PIX_FMT_RGB555,
.depth = { 16 },
- .color = S5P_FIMC_RGB555,
+ .color = FIMC_FMT_RGB555,
.memplanes = 1,
.colplanes = 1,
.flags = FMT_FLAGS_M2M_OUT | FMT_HAS_ALPHA,
@@ -72,7 +72,7 @@ static struct fimc_fmt fimc_formats[] = {
.name = "ARGB",
.fourcc = V4L2_PIX_FMT_RGB444,
.depth = { 16 },
- .color = S5P_FIMC_RGB444,
+ .color = FIMC_FMT_RGB444,
.memplanes = 1,
.colplanes = 1,
.flags = FMT_FLAGS_M2M_OUT | FMT_HAS_ALPHA,
@@ -80,7 +80,7 @@ static struct fimc_fmt fimc_formats[] = {
.name = "YUV 4:2:2 packed, YCbYCr",
.fourcc = V4L2_PIX_FMT_YUYV,
.depth = { 16 },
- .color = S5P_FIMC_YCBYCR422,
+ .color = FIMC_FMT_YCBYCR422,
.memplanes = 1,
.colplanes = 1,
.mbus_code = V4L2_MBUS_FMT_YUYV8_2X8,
@@ -89,7 +89,7 @@ static struct fimc_fmt fimc_formats[] = {
.name = "YUV 4:2:2 packed, CbYCrY",
.fourcc = V4L2_PIX_FMT_UYVY,
.depth = { 16 },
- .color = S5P_FIMC_CBYCRY422,
+ .color = FIMC_FMT_CBYCRY422,
.memplanes = 1,
.colplanes = 1,
.mbus_code = V4L2_MBUS_FMT_UYVY8_2X8,
@@ -98,7 +98,7 @@ static struct fimc_fmt fimc_formats[] = {
.name = "YUV 4:2:2 packed, CrYCbY",
.fourcc = V4L2_PIX_FMT_VYUY,
.depth = { 16 },
- .color = S5P_FIMC_CRYCBY422,
+ .color
[PATCH 04/13] s5p-fimc: Use v4l2_subdev internal ops to register video nodes
In order to be able to select only FIMC-LITE support, which is added
with subsequent patches, the regular FIMC support is now contained
only in fimc-core.c, fimc-m2m.c and fimc-capture.c files. The graph
and pipeline management is now solely handled in fimc-mdevice.[ch].
This means the FIMC driver can now be excluded with Kconfig option,
leaving only FIMC-LITE and allowing this driver to be reused in SoCs
that have only FIMC-LITE and no regular FIMC IP.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c | 142 +++
drivers/media/video/s5p-fimc/fimc-core.c|8 +-
drivers/media/video/s5p-fimc/fimc-core.h|7 +-
drivers/media/video/s5p-fimc/fimc-m2m.c | 17 +++-
drivers/media/video/s5p-fimc/fimc-mdevice.c | 89 +++--
drivers/media/video/s5p-fimc/fimc-mdevice.h |1 +
6 files changed, 136 insertions(+), 128 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 8488089..121f101 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -988,7 +988,7 @@ static int fimc_pipeline_validate(struct fimc_dev *fimc)
if (!(pad->flags & MEDIA_PAD_FL_SINK))
break;
/* Don't call FIMC subdev operation to avoid nested locking */
- if (sd == fimc->vid_cap.subdev) {
+ if (sd == &fimc->vid_cap.subdev) {
struct fimc_frame *ff = &vid_cap->ctx->s_frame;
sink_fmt.format.width = ff->f_width;
sink_fmt.format.height = ff->f_height;
@@ -1484,53 +1484,6 @@ static struct v4l2_subdev_ops fimc_subdev_ops = {
.pad = &fimc_subdev_pad_ops,
};
-static int fimc_create_capture_subdev(struct fimc_dev *fimc,
- struct v4l2_device *v4l2_dev)
-{
- struct v4l2_subdev *sd;
- int ret;
-
- sd = kzalloc(sizeof(*sd), GFP_KERNEL);
- if (!sd)
- return -ENOMEM;
-
- v4l2_subdev_init(sd, &fimc_subdev_ops);
- sd->flags = V4L2_SUBDEV_FL_HAS_DEVNODE;
- snprintf(sd->name, sizeof(sd->name), "FIMC.%d", fimc->pdev->id);
-
- fimc->vid_cap.sd_pads[FIMC_SD_PAD_SINK].flags = MEDIA_PAD_FL_SINK;
- fimc->vid_cap.sd_pads[FIMC_SD_PAD_SOURCE].flags = MEDIA_PAD_FL_SOURCE;
- ret = media_entity_init(&sd->entity, FIMC_SD_PADS_NUM,
- fimc->vid_cap.sd_pads, 0);
- if (ret)
- goto me_err;
- ret = v4l2_device_register_subdev(v4l2_dev, sd);
- if (ret)
- goto sd_err;
-
- fimc->vid_cap.subdev = sd;
- v4l2_set_subdevdata(sd, fimc);
- sd->entity.ops = &fimc_sd_media_ops;
- return 0;
-sd_err:
- media_entity_cleanup(&sd->entity);
-me_err:
- kfree(sd);
- return ret;
-}
-
-static void fimc_destroy_capture_subdev(struct fimc_dev *fimc)
-{
- struct v4l2_subdev *sd = fimc->vid_cap.subdev;
-
- if (!sd)
- return;
- media_entity_cleanup(&sd->entity);
- v4l2_device_unregister_subdev(sd);
- kfree(sd);
- fimc->vid_cap.subdev = NULL;
-}
-
/* Set default format at the sensor and host interface */
static int fimc_capture_set_default_format(struct fimc_dev *fimc)
{
@@ -1549,7 +1502,7 @@ static int fimc_capture_set_default_format(struct
fimc_dev *fimc)
}
/* fimc->lock must be already initialized */
-int fimc_register_capture_device(struct fimc_dev *fimc,
+static int fimc_register_capture_device(struct fimc_dev *fimc,
struct v4l2_device *v4l2_dev)
{
struct video_device *vfd;
@@ -1567,7 +1520,7 @@ int fimc_register_capture_device(struct fimc_dev *fimc,
ctx->out_path= FIMC_DMA;
ctx->state = FIMC_CTX_CAP;
ctx->s_frame.fmt = fimc_find_format(NULL, NULL, FMT_FLAGS_CAM, 0);
- ctx->d_frame.fmt = fimc_find_format(NULL, NULL, FMT_FLAGS_CAM, 0);
+ ctx->d_frame.fmt = ctx->s_frame.fmt;
vfd = video_device_alloc();
if (!vfd) {
@@ -1575,8 +1528,7 @@ int fimc_register_capture_device(struct fimc_dev *fimc,
goto err_vd_alloc;
}
- snprintf(vfd->name, sizeof(vfd->name), "%s.capture",
-dev_name(&fimc->pdev->dev));
+ snprintf(vfd->name, sizeof(vfd->name), "fimc.%d.capture", fimc->id);
vfd->fops = &fimc_capture_fops;
vfd->ioctl_ops = &fimc_capture_ioctl_ops;
@@ -1607,18 +1559,22 @@ int fimc_register_capture_device(struct fimc_dev *fimc,
vb2_queue_init(q);
- fimc->vid_cap.vd_pad.flags = MEDIA_PAD_FL_SINK;
- ret = media_entity_init(&vfd->entity, 1, &fimc->vid_cap.vd_pad, 0);
+ vid_cap->vd_pad.flags = MEDIA_PAD_FL_SINK;
+ ret = media_entity_init(&vfd->entity, 1, &vid_cap->vd_pad, 0);
if (ret)
goto err_ent;
-
[PATCH 12/13] s5p-fimc: Update copyright notices
Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- drivers/media/video/s5p-fimc/fimc-capture.c |4 ++-- drivers/media/video/s5p-fimc/fimc-core.c|4 ++-- drivers/media/video/s5p-fimc/fimc-core.h|2 +- drivers/media/video/s5p-fimc/fimc-mdevice.h |2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c b/drivers/media/video/s5p-fimc/fimc-capture.c index fde7033..9a6224f 100644 --- a/drivers/media/video/s5p-fimc/fimc-capture.c +++ b/drivers/media/video/s5p-fimc/fimc-capture.c @@ -1,8 +1,8 @@ /* * Samsung S5P/EXYNOS4 SoC series camera interface (camera capture) driver * - * Copyright (C) 2010 - 2011 Samsung Electronics Co., Ltd. - * Author: Sylwester Nawrocki, + * Copyright (C) 2010 - 2012 Samsung Electronics Co., Ltd. + * Sylwester Nawrocki, * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as diff --git a/drivers/media/video/s5p-fimc/fimc-core.c b/drivers/media/video/s5p-fimc/fimc-core.c index f67c3b6..d5872e6 100644 --- a/drivers/media/video/s5p-fimc/fimc-core.c +++ b/drivers/media/video/s5p-fimc/fimc-core.c @@ -1,8 +1,8 @@ /* * Samsung S5P/EXYNOS4 SoC series FIMC (CAMIF) driver * - * Copyright (C) 2010-2011 Samsung Electronics Co., Ltd. - * Contact: Sylwester Nawrocki, + * Copyright (C) 2010-2012 Samsung Electronics Co., Ltd. + * Sylwester Nawrocki, * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published diff --git a/drivers/media/video/s5p-fimc/fimc-core.h b/drivers/media/video/s5p-fimc/fimc-core.h index c42bbc9..a4fe52c 100644 --- a/drivers/media/video/s5p-fimc/fimc-core.h +++ b/drivers/media/video/s5p-fimc/fimc-core.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2010 - 2011 Samsung Electronics Co., Ltd. + * Copyright (C) 2010 - 2012 Samsung Electronics Co., Ltd. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as diff --git a/drivers/media/video/s5p-fimc/fimc-mdevice.h b/drivers/media/video/s5p-fimc/fimc-mdevice.h index 3524c19..3b8a349 100644 --- a/drivers/media/video/s5p-fimc/fimc-mdevice.h +++ b/drivers/media/video/s5p-fimc/fimc-mdevice.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2011 Samsung Electronics Co., Ltd. + * Copyright (C) 2011 - 2012 Samsung Electronics Co., Ltd. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as -- 1.7.10 -- 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 03/13] s5p-fimc: Simplify the variant data structure
Remove num_entities from the driver data structure as this information
is already there as the variant array's length. Remove the 'samsung_'
prefix from some data structures since it doesn't really carry any
useful information and makes the names unnecessarily long.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c |4 +--
drivers/media/video/s5p-fimc/fimc-core.c| 41 +--
drivers/media/video/s5p-fimc/fimc-core.h| 22 ++
drivers/media/video/s5p-fimc/fimc-reg.c |2 +-
4 files changed, 31 insertions(+), 38 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 513ffbc..8488089 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -556,7 +556,7 @@ static struct fimc_fmt *fimc_capture_try_format(struct
fimc_ctx *ctx,
{
bool rotation = ctx->rotation == 90 || ctx->rotation == 270;
struct fimc_dev *fimc = ctx->fimc_dev;
- struct samsung_fimc_variant *var = fimc->variant;
+ struct fimc_variant *var = fimc->variant;
struct fimc_pix_limit *pl = var->pix_limit;
struct fimc_frame *dst = &ctx->d_frame;
u32 depth, min_w, max_w, min_h, align_h = 3;
@@ -622,7 +622,7 @@ static void fimc_capture_try_crop(struct fimc_ctx *ctx,
struct v4l2_rect *r,
{
bool rotate = ctx->rotation == 90 || ctx->rotation == 270;
struct fimc_dev *fimc = ctx->fimc_dev;
- struct samsung_fimc_variant *var = fimc->variant;
+ struct fimc_variant *var = fimc->variant;
struct fimc_pix_limit *pl = var->pix_limit;
struct fimc_frame *sink = &ctx->s_frame;
u32 max_w, max_h, min_w = 0, min_h = 0, min_sz;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 55858c5..b35c0a6 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -230,7 +230,7 @@ static int fimc_get_scaler_factor(u32 src, u32 tar, u32
*ratio, u32 *shift)
int fimc_set_scaler_info(struct fimc_ctx *ctx)
{
- struct samsung_fimc_variant *variant = ctx->fimc_dev->variant;
+ struct fimc_variant *variant = ctx->fimc_dev->variant;
struct device *dev = &ctx->fimc_dev->pdev->dev;
struct fimc_scaler *sc = &ctx->scaler;
struct fimc_frame *s_frame = &ctx->s_frame;
@@ -427,7 +427,7 @@ void fimc_set_yuv_order(struct fimc_ctx *ctx)
void fimc_prepare_dma_offset(struct fimc_ctx *ctx, struct fimc_frame *f)
{
- struct samsung_fimc_variant *variant = ctx->fimc_dev->variant;
+ struct fimc_variant *variant = ctx->fimc_dev->variant;
u32 i, depth = 0;
for (i = 0; i < f->fmt->colplanes; i++)
@@ -469,7 +469,7 @@ void fimc_prepare_dma_offset(struct fimc_ctx *ctx, struct
fimc_frame *f)
static int __fimc_s_ctrl(struct fimc_ctx *ctx, struct v4l2_ctrl *ctrl)
{
struct fimc_dev *fimc = ctx->fimc_dev;
- struct samsung_fimc_variant *variant = fimc->variant;
+ struct fimc_variant *variant = fimc->variant;
unsigned int flags = FIMC_DST_FMT | FIMC_SRC_FMT;
int ret = 0;
@@ -529,7 +529,7 @@ static const struct v4l2_ctrl_ops fimc_ctrl_ops = {
int fimc_ctrls_create(struct fimc_ctx *ctx)
{
- struct samsung_fimc_variant *variant = ctx->fimc_dev->variant;
+ struct fimc_variant *variant = ctx->fimc_dev->variant;
unsigned int max_alpha = fimc_get_alpha_mask(ctx->d_frame.fmt);
if (ctx->ctrls_rdy)
@@ -793,14 +793,14 @@ static int fimc_probe(struct platform_device *pdev)
{
struct fimc_dev *fimc;
struct resource *res;
- struct samsung_fimc_driverdata *drv_data;
+ struct fimc_drvdata *drv_data;
struct s5p_platform_fimc *pdata;
int ret = 0;
- drv_data = (struct samsung_fimc_driverdata *)
+ drv_data = (struct fimc_drvdata *)
platform_get_device_id(pdev)->driver_data;
- if (pdev->id >= drv_data->num_entities) {
+ if (pdev->id >= ARRAY_SIZE(drv_data->variant)) {
dev_err(&pdev->dev, "Invalid platform device id: %d\n",
pdev->id);
return -EINVAL;
@@ -996,7 +996,7 @@ static struct fimc_pix_limit s5p_pix_limit[4] = {
},
};
-static struct samsung_fimc_variant fimc0_variant_s5p = {
+static struct fimc_variant fimc0_variant_s5p = {
.has_inp_rot = 1,
.has_out_rot = 1,
.has_cam_if = 1,
@@ -1008,17 +1008,17 @@ static struct samsung_fimc_variant fimc0_variant_s5p = {
.pix_limit = &s5p_pix_limit[0],
};
-static struct samsung_fimc_variant fimc2_variant_s5p = {
+static struct fimc_variant fimc2_variant_s5p = {
.has_cam_if = 1,
.min_inp_pixsize = 16,
.min_out_pixsize = 16,
.hor_offs_align = 8,
.min_vsize_align = 16,
[PATCH 01/13] V4L: Extend V4L2_CID_COLORFX with more image effects
This patch adds definition of additional color effects: - V4L2_COLORFX_AQUA, - V4L2_COLORFX_ART_FREEZE, - V4L2_COLORFX_SILHOUETTE, - V4L2_COLORFX_SOLARIZATION, - V4L2_COLORFX_ANTIQUE, - V4L2_COLORFX_ARBITRARY_CBCR. The control's type in the documentation is changed from 'enum' to 'menu' - V4L2_CID_COLORFX has always been a menu, not an integer type control. The V4L2_COLORFX_ARBITRARY_CBCR option enables custom color effects, which are impossible or impractical to define as menu items. The V4L2_CID_BLUE_BALANCE and V4L2_CID_RED_BALANCE controls allow in this case to configure the Cb, Cr coefficients. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- Documentation/DocBook/media/v4l/compat.xml | 10 +++ Documentation/DocBook/media/v4l/controls.xml | 92 ++ Documentation/DocBook/media/v4l/v4l2.xml |5 +- drivers/media/video/v4l2-ctrls.c |6 ++ include/linux/videodev2.h| 26 +--- 5 files changed, 114 insertions(+), 25 deletions(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 87339b2..a6a9c5c 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2422,6 +2422,16 @@ details. &VIDIOC-SUBDEV-G-SELECTION; and &VIDIOC-SUBDEV-S-SELECTION;. + + Added V4L2_COLORFX_ANTIQUE, + V4L2_COLORFX_ART_FREEZE, + V4L2_COLORFX_AQUA, + V4L2_COLORFX_SILHOUETTE, + V4L2_COLORFX_SOLARIZATION, + V4L2_COLORFX_VIVID and + V4L2_COLORFX_ARBITRARY_CBCR menu items +to the V4L2_CID_COLORFX control. + diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 5038a3a..8b604b0 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -284,19 +284,85 @@ minimum value disables backlight compensation. V4L2_CID_COLORFX - enum - Selects a color effect. Possible values for -enum v4l2_colorfx are: -V4L2_COLORFX_NONE (0), -V4L2_COLORFX_BW (1), -V4L2_COLORFX_SEPIA (2), -V4L2_COLORFX_NEGATIVE (3), -V4L2_COLORFX_EMBOSS (4), -V4L2_COLORFX_SKETCH (5), -V4L2_COLORFX_SKY_BLUE (6), -V4L2_COLORFX_GRASS_GREEN (7), -V4L2_COLORFX_SKIN_WHITEN (8) and -V4L2_COLORFX_VIVID (9). + menu + Selects a color effect. The following values are defined: + + + + + + + + V4L2_COLORFX_NONE + Color effect is disabled. + + + V4L2_COLORFX_ANTIQUE + An aging (old photo) effect. + + + V4L2_COLORFX_ART_FREEZE + Frost color effect. + + + V4L2_COLORFX_AQUA + Water color, cool tone. + + + V4L2_COLORFX_BW + Black and white. + + + V4L2_COLORFX_EMBOSS + Emboss, the highlights and shadows replace light/dark boundaries + and low contrast areas are set to a gray background. + + + V4L2_COLORFX_GRASS_GREEN + Grass green. + + + V4L2_COLORFX_NEGATIVE + Negative. + + + V4L2_COLORFX_SEPIA + Sepia tone. + + + V4L2_COLORFX_SKETCH + Sketch. + + + V4L2_COLORFX_SKIN_WHITEN + Skin whiten. + + + V4L2_COLORFX_SKY_BLUE + Sky blue. + + + V4L2_COLORFX_SOLARIZATION + Solarization, the image is partially reversed in tone, + only color values above or below a certain threshold are inverted. + + + + V4L2_COLORFX_SILHOUETTE + Silhouette (outline). + + + V4L2_COLORFX_VIVID + Vivid colors. + + + V4L2_COLORFX_ARBITRARY_CBCR + Arbitrary chroma components. The Cb, Cr coefficients +are determined by V4L2_CID_BLUE_BALANCE and +V4L2_CID_RED_BALANCE control respectively. + + + V4L2_CID_ROTATE diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index fbf808d..e4e65d0 100644 --- a/Documentation/DocBook/m
[PATCH 00/13] V4L: Exynos 4x12 camera host interface (FIMC-LITE) driver
This change set adds support for FIMC-LITE devices, available in Exynos4x12 (and Exynos5) SoCs, to the existing s5p-fimc driver. I have tested only DMA output operation (through a corresponding video node). The FIMC-LITE differs from regular FIMC in that it doesn't have a scaler, rotator and color converter and a DMA input. So it's just basic camera host interface, with additional internal FIFO data output to other SoC sub-modules. Cropping at the host interface input is exposed on a subdev sink pad through the selection API, and composition performed by the output DMA engine can be controlled through selection compose targets on the video node. I tried to make the exynos-fimc-lite module as much independent as possible, to allow its reuse on any other SoCs that have same IP block. This change set also includes small enhancement of V4L2_CID_COLORFX and a patch adding support for this control at the s5p-fimc driver. Regards, -- Sylwester Nawrocki Samsung Poland R&D Center Sylwester Nawrocki (13): V4L: Extend V4L2_CID_COLORFX with more image effects s5p-fimc: Move m2m node driver into separate file s5p-fimc: Simplify the variant data structure s5p-fimc: Use v4l2_subdev internal ops to register video nodes s5p-fimc: Refactor the register interface functions s5p-fimc: Add FIMC-LITE register definitions s5p-fimc: Rework the video pipeline control functions s5p-fimc: Prefix format enumerations with FIMC_FMT_ s5p-fimc: Make sure the interrupt is properly requested s5p-fimc: Minor cleanups s5p-fimc: Add support for Exynos4x12 FIMC-LITE s5p-fimc: Update copyright notices s5p-fimc: Add color effect control Documentation/DocBook/media/v4l/compat.xml | 10 + Documentation/DocBook/media/v4l/controls.xml | 92 +- Documentation/DocBook/media/v4l/v4l2.xml |5 +- drivers/media/video/Kconfig | 24 +- drivers/media/video/s5p-fimc/Kconfig | 47 + drivers/media/video/s5p-fimc/Makefile|6 +- drivers/media/video/s5p-fimc/fimc-capture.c | 301 +++-- drivers/media/video/s5p-fimc/fimc-core.c | 1099 +++--- drivers/media/video/s5p-fimc/fimc-core.h | 251 ++-- drivers/media/video/s5p-fimc/fimc-lite-reg.c | 301 + drivers/media/video/s5p-fimc/fimc-lite-reg.h | 153 +++ drivers/media/video/s5p-fimc/fimc-lite.c | 1589 ++ drivers/media/video/s5p-fimc/fimc-lite.h | 212 drivers/media/video/s5p-fimc/fimc-m2m.c | 820 + drivers/media/video/s5p-fimc/fimc-mdevice.c | 405 --- drivers/media/video/s5p-fimc/fimc-mdevice.h | 18 +- drivers/media/video/s5p-fimc/fimc-reg.c | 613 +- drivers/media/video/s5p-fimc/fimc-reg.h | 326 ++ drivers/media/video/s5p-fimc/regs-fimc.h | 301 - drivers/media/video/v4l2-ctrls.c |6 + include/linux/videodev2.h| 26 +- include/media/s5p_fimc.h | 16 + 22 files changed, 4628 insertions(+), 1993 deletions(-) create mode 100644 drivers/media/video/s5p-fimc/Kconfig create mode 100644 drivers/media/video/s5p-fimc/fimc-lite-reg.c create mode 100644 drivers/media/video/s5p-fimc/fimc-lite-reg.h create mode 100644 drivers/media/video/s5p-fimc/fimc-lite.c create mode 100644 drivers/media/video/s5p-fimc/fimc-lite.h create mode 100644 drivers/media/video/s5p-fimc/fimc-m2m.c create mode 100644 drivers/media/video/s5p-fimc/fimc-reg.h delete mode 100644 drivers/media/video/s5p-fimc/regs-fimc.h -- 1.7.10 -- 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 02/13] s5p-fimc: Move m2m node driver into separate file
Virtually no functional changes, just code reordering. This let us to
clearly separate all logical functions available in the driver: fimc
capture, mem-to-mem, and later fimc-lite capture, ISP features, etc.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/Makefile |2 +-
drivers/media/video/s5p-fimc/fimc-capture.c | 72 ++-
drivers/media/video/s5p-fimc/fimc-core.c| 853 +--
drivers/media/video/s5p-fimc/fimc-core.h| 10 +-
drivers/media/video/s5p-fimc/fimc-m2m.c | 808 +
5 files changed, 892 insertions(+), 853 deletions(-)
create mode 100644 drivers/media/video/s5p-fimc/fimc-m2m.c
diff --git a/drivers/media/video/s5p-fimc/Makefile
b/drivers/media/video/s5p-fimc/Makefile
index 33dec7f..1da3c6a 100644
--- a/drivers/media/video/s5p-fimc/Makefile
+++ b/drivers/media/video/s5p-fimc/Makefile
@@ -1,4 +1,4 @@
-s5p-fimc-objs := fimc-core.o fimc-reg.o fimc-capture.o fimc-mdevice.o
+s5p-fimc-objs := fimc-core.o fimc-reg.o fimc-m2m.o fimc-capture.o
fimc-mdevice.o
s5p-csis-objs := mipi-csis.o
obj-$(CONFIG_VIDEO_S5P_MIPI_CSIS) += s5p-csis.o
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index dc18ba5..513ffbc 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -139,7 +139,7 @@ static int fimc_stop_capture(struct fimc_dev *fimc, bool
suspend)
* spinlock held. It updates the camera pixel crop, rotation and
* image flip in H/W.
*/
-int fimc_capture_config_update(struct fimc_ctx *ctx)
+static int fimc_capture_config_update(struct fimc_ctx *ctx)
{
struct fimc_dev *fimc = ctx->fimc_dev;
int ret;
@@ -166,6 +166,74 @@ int fimc_capture_config_update(struct fimc_ctx *ctx)
return ret;
}
+void fimc_capture_irq_handler(struct fimc_dev *fimc)
+{
+ struct fimc_vid_cap *cap = &fimc->vid_cap;
+ struct fimc_vid_buffer *v_buf;
+ bool capture_stop;
+ struct timeval *tv;
+ struct timespec ts;
+
+ if (test_and_clear_bit(ST_CAPT_SHUT, &fimc->state)) {
+ wake_up(&fimc->irq_queue);
+ goto done;
+ }
+
+ capture_stop = !test_bit(ST_CAPT_JPEG, &fimc->state) ||
+ (cap->reqbufs_count == 1);
+
+ if (!list_empty(&cap->active_buf_q) &&
+ test_bit(ST_CAPT_RUN, &fimc->state) && capture_stop) {
+ ktime_get_real_ts(&ts);
+
+ v_buf = fimc_active_queue_pop(cap);
+
+ tv = &v_buf->vb.v4l2_buf.timestamp;
+ tv->tv_sec = ts.tv_sec;
+ tv->tv_usec = ts.tv_nsec / NSEC_PER_USEC;
+ v_buf->vb.v4l2_buf.sequence = cap->frame_count++;
+
+ vb2_buffer_done(&v_buf->vb, VB2_BUF_STATE_DONE);
+ }
+
+ if (!list_empty(&cap->pending_buf_q)) {
+
+ v_buf = fimc_pending_queue_pop(cap);
+ fimc_hw_set_output_addr(fimc, &v_buf->paddr, cap->buf_index);
+ v_buf->index = cap->buf_index;
+
+ /* Move the buffer to the capture active queue */
+ fimc_active_queue_add(cap, v_buf);
+
+ dbg("next frame: %d, done frame: %d",
+ fimc_hw_get_frame_index(fimc), v_buf->index);
+
+ if (++cap->buf_index >= FIMC_MAX_OUT_BUFS)
+ cap->buf_index = 0;
+ }
+
+ if (cap->active_buf_cnt == 0) {
+ if (capture_stop)
+ clear_bit(ST_CAPT_RUN, &fimc->state);
+
+ if (++cap->buf_index >= FIMC_MAX_OUT_BUFS)
+ cap->buf_index = 0;
+ } else {
+ set_bit(ST_CAPT_RUN, &fimc->state);
+ }
+
+ fimc_capture_config_update(cap->ctx);
+done:
+ if (cap->active_buf_cnt == 1) {
+ fimc_deactivate_capture(fimc);
+ clear_bit(ST_CAPT_STREAM, &fimc->state);
+ }
+
+ dbg("frame: %d, active_buf_cnt: %d",
+ fimc_hw_get_frame_index(fimc), cap->active_buf_cnt);
+}
+
+
static int start_streaming(struct vb2_queue *q, unsigned int count)
{
struct fimc_ctx *ctx = q->drv_priv;
@@ -1236,7 +1304,7 @@ void fimc_sensor_notify(struct v4l2_subdev *sd, unsigned
int notification,
struct fimc_vid_buffer, list);
vb2_set_plane_payload(&buf->vb, 0, *((u32 *)arg));
}
- fimc_capture_irq_handler(fimc, true);
+ fimc_capture_irq_handler(fimc);
fimc_deactivate_capture(fimc);
spin_unlock_irqrestore(&fimc->slock, irq_flags);
}
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 7b90a89..55858c5 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -1,5 +1,5 @@
/*
- * Samsung S5P/EXYNOS4 SoC series camera i
Re: [RFC PATCH 3/3] [media] gspca - main: implement vidioc_g_ext_ctrls and vidioc_s_ext_ctrls
On Friday, April 27, 2012 11:24:43 Jean-Francois Moine wrote: > On Fri, 27 Apr 2012 10:20:23 +0200 > Hans Verkuil wrote: > > > I might have some time (no guarantees yet) to help with this. It would > > certainly be interesting to add support for the control framework in the > > gspca core. Hmm, perhaps that's a job for the weekend... > > Hi Hans, > > I hope you will not do it! The way gspca treats the controls is static, > quick and very small. The controls in the subdrivers ask only for the > declaration of the controls and functions to send the values to the > webcams. Actually, not all subdrivers have been converted to the new > gspca control handling, but, when done, it will save more memory. And that is exactly what the control framework also does for you. Drivers only have to declare the controls and have a function to set their value. Everything else is handled by the control framework. And you get support for the extended control API for free and also support for control events, plus any future changes/enhancements to how controls are done will be automatically added. Not to mention that it ensures consistent and correct behavior of the control API towards applications. Note that the control code is already part of videodev.ko, so you have that code in memory anyway. So why not use it? 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: [RFC PATCH 3/3] [media] gspca - main: implement vidioc_g_ext_ctrls and vidioc_s_ext_ctrls
On Fri, 27 Apr 2012 10:20:23 +0200 Hans Verkuil wrote: > I might have some time (no guarantees yet) to help with this. It would > certainly be interesting to add support for the control framework in the > gspca core. Hmm, perhaps that's a job for the weekend... Hi Hans, I hope you will not do it! The way gspca treats the controls is static, quick and very small. The controls in the subdrivers ask only for the declaration of the controls and functions to send the values to the webcams. Actually, not all subdrivers have been converted to the new gspca control handling, but, when done, it will save more memory. Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] b2c2_flexcop_pci: Add suspend/resume support
On 19.04.2012 19:51, Mauro Carvalho Chehab wrote: Hi Stefan, Em 15-04-2012 11:18, Stefan Bauer escreveu: Dear linux-dvb developers, dear Matthias, proper suspend and resume support for the b2c2_flexcop_pci driver is still missing as pointed out by these two bug reports: https://bugs.gentoo.org/show_bug.cgi?id=288267 https://bugzilla.kernel.org/show_bug.cgi?id=14394 The first report contains a proposed patch to add suspend/resume support written by Matthias Schwarzott. I and some others (see first bug report) confirm that it's actually working. Behaviour without the patch: b2c2_flexcop_pci must be unloaded before suspending (means TV applications must be closed), and reloaded after resuming. Behaviour with the patch: No module unloading/reloading necessary any more. Known issues: TV application still needs to be closed before suspend. Otherwise the device is not functional (kaffeine shows only black screen) after resume. Reloading the module revives the device in that case. I'd kindly ask you to review the attached patch by Matthias and consider its upstream inclusion after the issues are sorted out. I'm more than willing to assist and test as I can. I don't have any b2c2 device, so I can't actually test it. on a quick lock, it seems sane on my eyes. In order for us to merge, we need the patch author's Signed-off-by. Hi! I do not remember exactly what were the open issues with this patch or how they could be solved, but if you want to merge the patch as it is, I am fine with this. So here is my Signed-off-by: Signed-off-by: Matthias Schwarzott Regards Matthias -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: mem2mem: use available list manipulation API
On 04/27/2012 10:13 AM, Guennadi Liakhovetski wrote: > Use an available standard list_first_entry() function instead of > open-coding. > > Signed-off-by: Guennadi Liakhovetski Acked-and-tested-by: Sylwester Nawrocki Thanks, -- Sylwester Nawrocki Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/1] v4l: Implement compat handlers for ioctls containing enums
Quite a few V4L2 IOCTLs contained enum types in IOCTL definitions which are
considered bad. To get rid of these types, the enum types are replaced with
integer types with fixed size. This causes the actual IOCTL commands to
change, which requires special handling during the transition period to new
IOCTL commands.
Signed-off-by: Sakari Ailus
---
Hi all,
I'm sending this as RFC and this what it really means: I haven't tested the
patch, not even compiled it. What I'd like to ask is how do you like the
approach. Handling for only one IOCTL is implemented.
The compat IOCTLs are recognised and special handling for them is performed
in place of copy_from_user() and copy_to_user(). I do not handle array
IOCTLs yet.
I thought of the option of copying everything to kernel space first and then
performing the conversion there, but doing it at the same time does not seem
to cause much additional complications. The expense is likely more CPU time
usage but less stack usage / memory allocation which also can consume
noteworthy amounts of CPU time.
This patch goes on top of Mauro's earlier patch.
drivers/media/video/v4l2-ioctl.c | 207 --
1 files changed, 198 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 5b2ec1f..cb2ed57 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -2303,6 +2303,177 @@ static long __video_do_ioctl(struct file *file,
return ret;
}
+static long copy_compat_from_user(unsigned int cmd, void *parg,
+ void __user *arg)
+{
+ union {
+ struct v4l2_fmtdesc_enum *fmtdesc;
+ struct v4l2_format_enum *fmt;
+ struct v4l2_requestbuffers_enum *reqbufs;
+ struct v4l2_framebuffer_enum *fb;
+ struct v4l2_buffer_enum *buf;
+ struct v4l2_streamparm_enum *sparm;
+ struct v4l2_tuner_enum *tuner;
+ struct v4l2_queryctrl_enum *qc;
+ struct v4l2_frequency_enum *freq;
+ struct v4l2_crop_enumcap_enum *cropcap;
+ struct v4l2_crop_enum *crop;
+ struct v4l2_sliced_vbi_cap_enum *vbi_cap;
+ struct v4l2_hw_freq_seek_enum *hw_freq_seek;
+ struct v4l2_create_buffers_enum *create_bufs;
+ } __user cu = arg;
+ union {
+ struct v4l2_fmtdesc fmtdesc;
+ struct v4l2_format fmt;
+ struct v4l2_requestbuffers reqbufs;
+ struct v4l2_framebuffer fb;
+ struct v4l2_buffer buf;
+ struct v4l2_streamparm sparm;
+ struct v4l2_tuner tuner;
+ struct v4l2_queryctrl qc;
+ struct v4l2_frequency freq;
+ struct v4l2_crop_enumcap cropcap;
+ struct v4l2_crop crop;
+ struct v4l2_sliced_vbi_cap vbi_cap;
+ struct v4l2_hw_freq_seek hw_freq_seek;
+ struct v4l2_create_buffers create_bufs;
+ } k = parg;
+
+ switch (cmd) {
+ case VIDIOC_ENUM_FMT_ENUM:
+ if (!access_ok(VERIFY_READ, cu, sizeof(*cu->fmtdesc))
+ || get_user(k->fmtdesc.index, cu->fmtdesc->index)
+ || get_user(k->fmtdesc.type, cu->fmtdesc->type)
+ || get_user(k->fmtdesc.flags, cu->fmtdesc->flags)
+ || copy_from_user(k->fmtdesc.description,
+ cu->fmtdesc->description,
+ sizeof(k->fmtdesc.description))
+ || get_user(k->fmtdesc.pixelformat,
+ u->fmtdesc->pixelformat)
+ || copy_from_user(k->fmtdesc.reserved,
+ cu->fmtdesc->reserved,
+ sizeof(k->fmtdesc.reserved)))
+ return -EFAULT;
+ return 0;
+ default:
+ WARN();
+ return -EINVAL;
+ }
+}
+
+static long copy_compat_to_user(unsigned int cmd, void __user *arg,
+ void *parg)
+{
+ union {
+ struct v4l2_fmtdesc_enum *fmtdesc;
+ struct v4l2_format_enum *fmt;
+ struct v4l2_requestbuffers_enum *reqbufs;
+ struct v4l2_framebuffer_enum *fb;
+ struct v4l2_buffer_enum *buf;
+ struct v4l2_streamparm_enum *sparm;
+ struct v4l2_tuner_enum *tuner;
+ struct v4l2_queryctrl_enum *qc;
+ struct v4l2_frequency_enum *freq;
+ struct v4l2_crop_enumcap_enum *cropcap;
+ struct v4l2_crop_enum *crop;
+ struct v4l2_sliced_vbi_cap_enum *vbi_cap;
+ struct v4l2_hw_freq_seek_enum *hw_freq_seek;
+ struct v4l2_create_buffers_enum *create_bufs;
+ } __user cu = arg;
+ union {
+
Re: [RFC PATCH 3/3] [media] gspca - main: implement vidioc_g_ext_ctrls and vidioc_s_ext_ctrls
Hi Antonio,
My apologies for the late review, I missed this the first time around.
Since I am the 'control guy' :-) I thought I should give my view on this.
And that is the real long-term approach to implementing extended controls
in gspca is to add support in gspca for the control framework (see
Documentation/video4linux/v4l2-controls.txt). That will probably simplify
control handling in gspca anyway. The main problem is how to do it in such
a manner that we can convert gspca drivers to the control framework one by
one.
I am inclined to NACK code that adds a driver-specific extended control
implementation instead of going to the control framework because I know
from painful personal experience that it is very hard to get it right.
I might have some time (no guarantees yet) to help with this. It would
certainly be interesting to add support for the control framework in the
gspca core. Hmm, perhaps that's a job for the weekend...
Regards,
Hans
On Friday, April 20, 2012 17:19:11 Antonio Ospite wrote:
> This makes it possible for applications to handle controls with a class
> different than V4L2_CTRL_CLASS_USER for gspca subdevices, like for
> instance V4L2_CID_EXPOSURE_AUTO which some subdrivers use and which
> can't be controlled right now.
>
> See
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/47010
> for an example of a problem fixed by this change.
>
> NOTE: gspca currently won't handle control types like
> V4L2_CTRL_TYPE_INTEGER64 or V4L2_CTRL_TYPE_STRING, so just the
> __s32 field 'value' of 'struct v4l2_ext_control' is handled for now.
>
> Signed-off-by: Antonio Ospite
> ---
> drivers/media/video/gspca/gspca.c | 42
> +
> 1 file changed, 42 insertions(+)
>
> diff --git a/drivers/media/video/gspca/gspca.c
> b/drivers/media/video/gspca/gspca.c
> index ba1bda9..7906093 100644
> --- a/drivers/media/video/gspca/gspca.c
> +++ b/drivers/media/video/gspca/gspca.c
> @@ -1567,6 +1567,46 @@ static int vidioc_g_ctrl(struct file *file, void *priv,
> return gspca_get_ctrl(gspca_dev, ctrl->id, &ctrl->value);
> }
>
> +static int vidioc_s_ext_ctrls(struct file *file, void *priv,
> + struct v4l2_ext_controls *ext_ctrls)
> +{
> + struct gspca_dev *gspca_dev = priv;
> + int ret = 0;
> + int i;
> +
> + for (i = 0; i < ext_ctrls->count; i++) {
> + struct v4l2_ext_control *ctrl;
> +
> + ctrl = ext_ctrls->controls + i;
> + ret = gspca_set_ctrl(gspca_dev, ctrl->id, ctrl->value);
> + if (ret < 0) {
> + ext_ctrls->error_idx = i;
> + return ret;
> + }
> + }
> + return ret;
> +}
> +
> +static int vidioc_g_ext_ctrls(struct file *file, void *priv,
> + struct v4l2_ext_controls *ext_ctrls)
> +{
> + struct gspca_dev *gspca_dev = priv;
> + int i;
> + int ret = 0;
> +
> + for (i = 0; i < ext_ctrls->count; i++) {
> + struct v4l2_ext_control *ctrl;
> +
> + ctrl = ext_ctrls->controls + i;
> + ret = gspca_get_ctrl(gspca_dev, ctrl->id, &ctrl->value);
> + if (ret < 0) {
> + ext_ctrls->error_idx = i;
> + return ret;
> + }
> + }
> + return ret;
> +}
> +
> static int vidioc_querymenu(struct file *file, void *priv,
> struct v4l2_querymenu *qmenu)
> {
> @@ -2260,6 +2300,8 @@ static const struct v4l2_ioctl_ops dev_ioctl_ops = {
> .vidioc_queryctrl = vidioc_queryctrl,
> .vidioc_g_ctrl = vidioc_g_ctrl,
> .vidioc_s_ctrl = vidioc_s_ctrl,
> + .vidioc_g_ext_ctrls = vidioc_g_ext_ctrls,
> + .vidioc_s_ext_ctrls = vidioc_s_ext_ctrls,
> .vidioc_querymenu = vidioc_querymenu,
> .vidioc_enum_input = vidioc_enum_input,
> .vidioc_g_input = vidioc_g_input,
>
--
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] V4L: mem2mem: fix alignment in mem2mem-testdev
Fix a trivial alignment calculation issue.
Signed-off-by: Guennadi Liakhovetski
---
diff --git a/drivers/media/video/mem2mem_testdev.c
b/drivers/media/video/mem2mem_testdev.c
index 12897e8..82f86ca 100644
--- a/drivers/media/video/mem2mem_testdev.c
+++ b/drivers/media/video/mem2mem_testdev.c
@@ -40,7 +40,7 @@ MODULE_VERSION("0.1.1");
#define MIN_H 32
#define MAX_W 640
#define MAX_H 480
-#define DIM_ALIGN_MASK 0x08 /* 8-alignment for dimensions */
+#define DIM_ALIGN_MASK 7 /* 8-byte alignment for line length */
/* Flags that indicate a format can be used for capture/output */
#define MEM2MEM_CAPTURE(1 << 0)
--
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] V4L: mem2mem: use available list manipulation API
Use an available standard list_first_entry() function instead of open-coding. Signed-off-by: Guennadi Liakhovetski --- diff --git a/drivers/media/video/v4l2-mem2mem.c b/drivers/media/video/v4l2-mem2mem.c index 975d0fa..aaa67d3 100644 --- a/drivers/media/video/v4l2-mem2mem.c +++ b/drivers/media/video/v4l2-mem2mem.c @@ -102,7 +102,7 @@ void *v4l2_m2m_next_buf(struct v4l2_m2m_queue_ctx *q_ctx) return NULL; } - b = list_entry(q_ctx->rdy_queue.next, struct v4l2_m2m_buffer, list); + b = list_first_entry(&q_ctx->rdy_queue, struct v4l2_m2m_buffer, list); spin_unlock_irqrestore(&q_ctx->rdy_spinlock, flags); return &b->vb; } @@ -122,7 +122,7 @@ void *v4l2_m2m_buf_remove(struct v4l2_m2m_queue_ctx *q_ctx) spin_unlock_irqrestore(&q_ctx->rdy_spinlock, flags); return NULL; } - b = list_entry(q_ctx->rdy_queue.next, struct v4l2_m2m_buffer, list); + b = list_first_entry(&q_ctx->rdy_queue, struct v4l2_m2m_buffer, list); list_del(&b->list); q_ctx->num_rdy--; spin_unlock_irqrestore(&q_ctx->rdy_spinlock, flags); @@ -175,7 +175,7 @@ static void v4l2_m2m_try_run(struct v4l2_m2m_dev *m2m_dev) return; } - m2m_dev->curr_ctx = list_entry(m2m_dev->job_queue.next, + m2m_dev->curr_ctx = list_first_entry(&m2m_dev->job_queue, struct v4l2_m2m_ctx, queue); m2m_dev->curr_ctx->job_flags |= TRANS_RUNNING; spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags); -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.5] Fix for a DocBook typo
On 04/26/2012 01:03 PM, Hans Verkuil wrote: > The following changes since commit aa6d5f29534a6d1459f9768c591a7a72aadc5941: > > [media] pluto2: remove some dead code (2012-04-19 17:15:32 -0300) > > are available in the git repository at: > > git://linuxtv.org/hverkuil/media_tree.git docfix > > for you to fetch changes up to fada845c248be56ddba1f58a0ca69d335a22712e: > > V4L2 Spec: fix typo. (2012-04-26 12:39:14 +0200) > > > Hans Verkuil (1): > V4L2 Spec: fix typo. > > Documentation/DocBook/media/v4l/controls.xml |6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Oops, mu fault. Thanks for spotting this. Would be nice to have it in 3.4-rc, this way there wouldn't be those typos in any final kernel release. Regards, Sylwester -- 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: gspca V4L2_CID_EXPOSURE_AUTO and VIDIOC_G/S/TRY_EXT_CTRLS
On Wed, 18 Apr 2012 15:37:20 +0200 Antonio Ospite wrote: > I noticed that AEC (Automatic Exposure Control, or > V4L2_CID_EXPOSURE_AUTO) does not work in the ov534 gspca driver, either > from guvcview or qv4l2. [snip] > So in ov534, but I think in m5602 too, V4L2_CID_EXPOSURE_AUTO does not > work from guvcview, qv4l2, or v4l2-ctrl, for instance the latter fails > with the message: > > error 25 getting ext_ctrl Auto Exposure > > I tried adding an hackish implementation of vidioc_g_ext_ctrls and > vidioc_s_ext_ctrls to gspca, and with these V4L2_CID_EXPOSURE_AUTO seems > to work, but I need to learn more about this kind of controls before > I can propose a decent implementation for mainline inclusion myself, so > if anyone wants to anticipate me I'd be glad to test :) > > Unrelated, but maybe worth mentioning is that V4L2_CID_EXPOSURE_AUTO is > of type MENU, while some drivers are treating it as a boolean, I think > I can fix this one if needed. Hi Antonio, Yes, V4L2_CID_EXPOSURE_AUTO is of class V4L2_CTRL_CLASS_CAMERA, and, as the associated menu shows, it is not suitable for webcams. In the webcam world, the autoexposure is often the same as the autogain: in the knee algorithm (http://81.209.78.62:8080/docs/LowLightOptimization.html - also look at gspca/sonixb.c), both exposure and gain are concerned. The cases where a user wants only autoexposure (fixed gain) or autogain (fixed exposure) are rare. If you want people to be able to do that, you should add a new webcam control, V4L2_CID_AUTOEXPOSURE, and also add it to each driver which implements the knee algorithm, and handle the three cases, autogain only, autoexposure only and knee. Then, looking about your implementation of vidioc_s_ext_ctrls, I found it was a bit simple: setting many controls is atomic, i.e., if any error occurs at some point, the previous controls should be reset to their original values. Same about vidioc_g_ext_ctrls: the mutex must be taken only once for the values do not change. You also do not check if the controls are in a same control class. Anyway, are these ioctl's needed? Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.5] Fix compiler warnings
This patch series fixes most of the compiler warnings in the daily build. Right now there are way too many, so new warnings aren't noticed. Once this is merged I will work on the remaining warnings. Regards, Hans The following changes since commit bcb2cf6e0bf033d79821c89e5ccb328bfbd44907: [media] ngene: remove an unneeded condition (2012-04-26 15:29:23 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git warnings for you to fetch changes up to d0c5b940ee666868f1d01eb6a916fc03767b3251: v4l/dvb: fix compiler warnings (2012-04-27 09:29:03 +0200) Hans Verkuil (8): dw2102: fix compile warnings cx231xx: fix compiler warnings ivtv/cx18: fix compiler warnings cx25821: fix compiler warnings. v4l: fix compiler warnings. v4l: fix compiler warnings. v4l/dvb: fix compiler warnings. v4l/dvb: fix compiler warnings drivers/media/dvb/bt8xx/dst_ca.c |2 - drivers/media/dvb/dvb-usb/dw2102.c | 76 +-- drivers/media/dvb/dvb-usb/lmedm04.c |3 +- drivers/media/dvb/frontends/af9013.c | 13 ++--- drivers/media/dvb/frontends/cx24110.c|7 ++- drivers/media/dvb/frontends/dib9000.c|3 +- drivers/media/dvb/frontends/drxk_hard.c |9 ++-- drivers/media/dvb/frontends/it913x-fe.c | 26 +- drivers/media/dvb/frontends/lgs8gxx.c|3 +- drivers/media/dvb/frontends/m88rs2000.c |3 +- drivers/media/dvb/frontends/stb0899_drv.c|8 +-- drivers/media/dvb/frontends/stb6100.c|3 +- drivers/media/dvb/frontends/stv0297.c|2 - drivers/media/dvb/frontends/stv0900_sw.c |2 - drivers/media/dvb/frontends/stv090x.c|2 - drivers/media/dvb/frontends/zl10353.c|3 +- drivers/media/dvb/mantis/hopper_cards.c |3 +- drivers/media/dvb/mantis/mantis_cards.c |3 +- drivers/media/dvb/mantis/mantis_dma.c|4 -- drivers/media/dvb/mantis/mantis_evm.c|3 +- drivers/media/dvb/siano/smssdio.c|4 +- drivers/media/rc/ir-sanyo-decoder.c |4 +- drivers/media/rc/mceusb.c|4 +- drivers/media/video/adv7343.c|4 +- drivers/media/video/au0828/au0828-video.c|4 +- drivers/media/video/c-qcam.c |3 +- drivers/media/video/cx18/cx18-alsa-main.c|1 + drivers/media/video/cx18/cx18-alsa-pcm.c | 10 ++-- drivers/media/video/cx18/cx18-mailbox.c |6 +-- drivers/media/video/cx18/cx18-streams.c |3 -- drivers/media/video/cx231xx/cx231xx-417.c| 16 +++--- drivers/media/video/cx231xx/cx231xx-audio.c | 17 +++--- drivers/media/video/cx231xx/cx231xx-avcore.c | 144 +++ drivers/media/video/cx231xx/cx231xx-core.c | 76 +-- drivers/media/video/cx231xx/cx231xx-vbi.c|6 +-- drivers/media/video/cx231xx/cx231xx-video.c | 16 -- drivers/media/video/cx23885/cx23888-ir.c |4 +- drivers/media/video/cx25821/cx25821-alsa.c |2 - drivers/media/video/cx25821/cx25821-audio-upstream.c |3 +- drivers/media/video/cx25821/cx25821-core.c | 14 + drivers/media/video/cx25821/cx25821-i2c.c|3 +- drivers/media/video/cx25821/cx25821-medusa-video.c | 13 ++--- drivers/media/video/cx25821/cx25821-video-upstream-ch2.c |3 +- drivers/media/video/cx25821/cx25821-video-upstream.c |3 +- drivers/media/video/cx25821/cx25821-video.c | 25 + drivers/media/video/cx25821/cx25821-video.h |2 - drivers/media/video/cx25840/cx25840-ir.c |6 +-- drivers/media/video/em28xx/em28xx-audio.c|9 ++-- drivers/media/video/et61x251/et61x251_core.c | 11 ++-- drivers/media/video/hdpvr/hdpvr-control.c|2 + drivers/media/video/hdpvr/hdpvr-video.c |2 +- drivers/media/video/ivtv/ivtv-ioctl.c|3 -- drivers/media/video/ivtv/ivtvfb.c|2 + drivers/media/video/pms.c|4 +- drivers/media/video/s2255drv.c |4 -- drivers/media/video/saa7134/saa7134-video.c |2 +- drivers/media/video/sn9c102/sn9c102_core.c |4
[PATCH 6/6 v2] dvbsky, remote control include header file
--- include/media/rc-map.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/media/rc-map.h b/include/media/rc-map.h index 8db6741..7176dac 100644 --- a/include/media/rc-map.h +++ b/include/media/rc-map.h @@ -85,6 +85,7 @@ void rc_map_init(void); #define RC_MAP_DM1105_NEC"rc-dm1105-nec" #define RC_MAP_DNTV_LIVE_DVBT_PRO"rc-dntv-live-dvbt-pro" #define RC_MAP_DNTV_LIVE_DVB_T "rc-dntv-live-dvb-t" +#define RC_MAP_DVBSKY"rc-dvbsky" #define RC_MAP_EMPTY "rc-empty" #define RC_MAP_EM_TERRATEC "rc-em-terratec" #define RC_MAP_ENCORE_ENLTV2 "rc-encore-enltv2" -- 1.7.9.5 -- 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 5/6 v2] dvbsky, remote control key map
---
drivers/media/rc/keymaps/Makefile|1 +
drivers/media/rc/keymaps/rc-dvbsky.c | 77 ++
2 files changed, 78 insertions(+)
create mode 100644 drivers/media/rc/keymaps/rc-dvbsky.c
diff --git a/drivers/media/rc/keymaps/Makefile
b/drivers/media/rc/keymaps/Makefile
index 49ce266..e6a882b 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-dm1105-nec.o \
rc-dntv-live-dvb-t.o \
rc-dntv-live-dvbt-pro.o \
+ rc-dvbsky.o \
rc-em-terratec.o \
rc-encore-enltv2.o \
rc-encore-enltv.o \
diff --git a/drivers/media/rc/keymaps/rc-dvbsky.c
b/drivers/media/rc/keymaps/rc-dvbsky.c
new file mode 100644
index 000..25a531c
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-dvbsky.c
@@ -0,0 +1,77 @@
+/* rc-dvbsky.c - Keytable for Dvbsky Remote Controllers
+ *
+ *
+ *
+ * Copyright (C) 2011 Max nibble
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+/*
+ * This table contains the complete RC5 code, instead of just the data part
+ */
+
+static struct rc_map_table rc5_dvbsky[] = {
+ { 0x, KEY_0 },
+ { 0x0001, KEY_1 },
+ { 0x0002, KEY_2 },
+ { 0x0003, KEY_3 },
+ { 0x0004, KEY_4 },
+ { 0x0005, KEY_5 },
+ { 0x0006, KEY_6 },
+ { 0x0007, KEY_7 },
+ { 0x0008, KEY_8 },
+ { 0x0009, KEY_9 },
+ { 0x000a, KEY_MUTE },
+ { 0x000d, KEY_OK },
+ { 0x000b, KEY_STOP },
+ { 0x000c, KEY_EXIT },
+ { 0x000e, KEY_CAMERA }, /*Snap shot*/
+ { 0x000f, KEY_SUBTITLE }, /*PIP*/
+ { 0x0010, KEY_VOLUMEUP },
+ { 0x0011, KEY_VOLUMEDOWN },
+ { 0x0012, KEY_FAVORITES },
+ { 0x0013, KEY_LIST }, /*Info*/
+ { 0x0016, KEY_PAUSE },
+ { 0x0017, KEY_PLAY },
+ { 0x001f, KEY_RECORD },
+ { 0x0020, KEY_CHANNELDOWN },
+ { 0x0021, KEY_CHANNELUP },
+ { 0x0025, KEY_POWER2 },
+ { 0x0026, KEY_REWIND },
+ { 0x0027, KEY_FASTFORWARD },
+ { 0x0029, KEY_LAST },
+ { 0x002b, KEY_MENU },
+ { 0x002c, KEY_EPG },
+ { 0x002d, KEY_ZOOM },
+};
+
+static struct rc_map_list rc5_dvbsky_map = {
+ .map = {
+ .scan= rc5_dvbsky,
+ .size= ARRAY_SIZE(rc5_dvbsky),
+ .rc_type = RC_TYPE_RC5,
+ .name= RC_MAP_DVBSKY,
+ }
+};
+
+static int __init init_rc_map_rc5_dvbsky(void)
+{
+ return rc_map_register(&rc5_dvbsky_map);
+}
+
+static void __exit exit_rc_map_rc5_dvbsky(void)
+{
+ rc_map_unregister(&rc5_dvbsky_map);
+}
+
+module_init(init_rc_map_rc5_dvbsky)
+module_exit(exit_rc_map_rc5_dvbsky)
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Max nibble ");
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6 v2] dvbsky, dvb-s/s2 PCIe card
Also fix some code sytle errors checked by checkpatch.pl.
---
drivers/media/video/cx23885/Kconfig |2 +
drivers/media/video/cx23885/cx23885-cards.c | 106 +++
drivers/media/video/cx23885/cx23885-dvb.c | 90 ++-
drivers/media/video/cx23885/cx23885-f300.c | 51 +
drivers/media/video/cx23885/cx23885-f300.h |6 ++
drivers/media/video/cx23885/cx23885-input.c | 15
drivers/media/video/cx23885/cx23885.h |6 +-
7 files changed, 273 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/cx23885/Kconfig
b/drivers/media/video/cx23885/Kconfig
index b391e9b..33325f4 100644
--- a/drivers/media/video/cx23885/Kconfig
+++ b/drivers/media/video/cx23885/Kconfig
@@ -20,6 +20,8 @@ config VIDEO_CX23885
select DVB_LNBP21 if !DVB_FE_CUSTOMISE
select DVB_STV6110 if !DVB_FE_CUSTOMISE
select DVB_CX24116 if !DVB_FE_CUSTOMISE
+ select DVB_M88TS202X if !DVB_FE_CUSTOMISE
+ select DVB_M88DS3103 if !DVB_FE_CUSTOMISE
select DVB_STV0900 if !DVB_FE_CUSTOMISE
select DVB_DS3000 if !DVB_FE_CUSTOMISE
select DVB_STV0367 if !DVB_FE_CUSTOMISE
diff --git a/drivers/media/video/cx23885/cx23885-cards.c
b/drivers/media/video/cx23885/cx23885-cards.c
index 19b5499..8f13990 100644
--- a/drivers/media/video/cx23885/cx23885-cards.c
+++ b/drivers/media/video/cx23885/cx23885-cards.c
@@ -497,7 +497,22 @@ struct cx23885_board cx23885_boards[] = {
.name = "TerraTec Cinergy T PCIe Dual",
.portb = CX23885_MPEG_DVB,
.portc = CX23885_MPEG_DVB,
+ },
+
+ [CX23885_BOARD_BST_PS8512] = {
+ .name = "Bestunar PS8512",
+ .portb = CX23885_MPEG_DVB,
+ },
+ [CX23885_BOARD_DVBSKY_S950] = {
+ .name = "DVBSKY S950",
+ .portb = CX23885_MPEG_DVB,
+ },
+ [CX23885_BOARD_DVBSKY_S952] = {
+ .name = "DVBSKY S952",
+ .portb = CX23885_MPEG_DVB,
+ .portc = CX23885_MPEG_DVB,
}
+
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
@@ -705,6 +720,18 @@ struct cx23885_subid cx23885_subids[] = {
.subvendor = 0x153b,
.subdevice = 0x117e,
.card = CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL,
+ }, {
+ .subvendor = 0x14f1,
+ .subdevice = 0x8512,
+ .card = CX23885_BOARD_BST_PS8512,
+ }, {
+ .subvendor = 0x4254,
+ .subdevice = 0x0950,
+ .card = CX23885_BOARD_DVBSKY_S950,
+ }, {
+ .subvendor = 0x4254,
+ .subdevice = 0x0952,
+ .card = CX23885_BOARD_DVBSKY_S952,
},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -1216,9 +1243,55 @@ void cx23885_gpio_setup(struct cx23885_dev *dev)
/* enable irq */
cx_write(GPIO_ISM, 0x);/* INTERRUPTS active low*/
break;
+ case CX23885_BOARD_DVBSKY_S950:
+ case CX23885_BOARD_BST_PS8512:
+ cx23885_gpio_enable(dev, GPIO_2, 1);
+ cx23885_gpio_clear(dev, GPIO_2);
+ msleep(100);
+ cx23885_gpio_set(dev, GPIO_2);
+ break;
+ case CX23885_BOARD_DVBSKY_S952:
+ cx_write(MC417_CTL, 0x0037);/* enable GPIO3-18 pins */
+
+ cx23885_gpio_enable(dev, GPIO_2, 1);
+ cx23885_gpio_enable(dev, GPIO_11, 1);
+ cx23885_gpio_clear(dev, GPIO_2);
+ cx23885_gpio_clear(dev, GPIO_11);
+ msleep(100);
+ cx23885_gpio_set(dev, GPIO_2);
+ cx23885_gpio_set(dev, GPIO_11);
+ break;
}
}
+static int cx23885_ir_patch(struct i2c_adapter *i2c, u8 reg, u8 mask)
+{
+ struct i2c_msg msgs[2];
+ u8 tx_buf[2], rx_buf[1];
+ /* Write register address */
+ tx_buf[0] = reg;
+ msgs[0].addr = 0x4c;
+ msgs[0].flags = 0;
+ msgs[0].len = 1;
+ msgs[0].buf = (char *) tx_buf;
+ /* Read data from register */
+ msgs[1].addr = 0x4c;
+ msgs[1].flags = I2C_M_RD;
+ msgs[1].len = 1;
+ msgs[1].buf = (char *) rx_buf;
+
+ i2c_transfer(i2c, msgs, 2);
+
+ tx_buf[0] = reg;
+ tx_buf[1] = rx_buf[0] | mask;
+ msgs[0].addr = 0x4c;
+ msgs[0].flags = 0;
+ msgs[0].len = 2;
+ msgs[0].buf = (char *) tx_buf;
+
+ return i2c_transfer(i2c, msgs, 1);
+}
+
int cx23885_ir_init(struct cx23885_dev *dev)
{
static struct v4l2_subdev_io_pin_config ir_rxtx_pin_cfg[] = {
@@ -1301,6 +1374,20 @@ int cx23885_ir_init(struct cx23885_dev *dev)
v4l2_subdev_call(dev->sd_cx25840, core, s_io_pin_config,
ir_rx_pin_cfg
[PATCH 2/6 v2] dvbsky, dvb-s/s2 usb box
Also fix some code sytle errors checked by checkpatch.pl.
---
drivers/media/dvb/dvb-usb/Kconfig |2 +
drivers/media/dvb/dvb-usb/dw2102.c | 337
2 files changed, 305 insertions(+), 34 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/Kconfig
b/drivers/media/dvb/dvb-usb/Kconfig
index be1db75..93c9381 100644
--- a/drivers/media/dvb/dvb-usb/Kconfig
+++ b/drivers/media/dvb/dvb-usb/Kconfig
@@ -279,6 +279,8 @@ config DVB_USB_DW2102
select DVB_STV0288 if !DVB_FE_CUSTOMISE
select DVB_STB6000 if !DVB_FE_CUSTOMISE
select DVB_CX24116 if !DVB_FE_CUSTOMISE
+ select DVB_M88TS202X if !DVB_FE_CUSTOMISE
+ select DVB_M88DS3103 if !DVB_FE_CUSTOMISE
select DVB_SI21XX if !DVB_FE_CUSTOMISE
select DVB_TDA10023 if !DVB_FE_CUSTOMISE
select DVB_MT312 if !DVB_FE_CUSTOMISE
diff --git a/drivers/media/dvb/dvb-usb/dw2102.c
b/drivers/media/dvb/dvb-usb/dw2102.c
index 451c5a7..1cf62fb 100644
--- a/drivers/media/dvb/dvb-usb/dw2102.c
+++ b/drivers/media/dvb/dvb-usb/dw2102.c
@@ -19,6 +19,8 @@
#include "stb6000.h"
#include "eds1547.h"
#include "cx24116.h"
+#include "m88ts202x.h"
+#include "m88ds3103.h"
#include "tda1002x.h"
#include "mt312.h"
#include "zl10039.h"
@@ -118,12 +120,12 @@ MODULE_PARM_DESC(demod, "demod to probe (1=cx24116
2=stv0903+stv6110 "
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
static int dw210x_op_rw(struct usb_device *dev, u8 request, u16 value,
- u16 index, u8 * data, u16 len, int flags)
+ u16 index, u8 *data, u16 len, int flags)
{
int ret;
u8 *u8buf;
unsigned int pipe = (flags == DW210X_READ_MSG) ?
- usb_rcvctrlpipe(dev, 0) : usb_sndctrlpipe(dev,
0);
+ usb_rcvctrlpipe(dev, 0) : usb_sndctrlpipe(dev, 0);
u8 request_type = (flags == DW210X_READ_MSG) ? USB_DIR_IN : USB_DIR_OUT;
u8buf = kmalloc(len, GFP_KERNEL);
@@ -133,7 +135,8 @@ static int dw210x_op_rw(struct usb_device *dev, u8 request,
u16 value,
if (flags == DW210X_WRITE_MSG)
memcpy(u8buf, data, len);
- ret = usb_control_msg(dev, pipe, request, request_type |
USB_TYPE_VENDOR,
+ ret = usb_control_msg(dev, pipe,
+ request, request_type | USB_TYPE_VENDOR,
value, index , u8buf, len, 2000);
if (flags == DW210X_READ_MSG)
@@ -179,7 +182,7 @@ static int dw2102_i2c_transfer(struct i2c_adapter *adap,
struct i2c_msg msg[],
break;
case 0x60:
if (msg[0].flags == 0) {
- /* write to tuner pll */
+ /* write to tuner pll */
buf6[0] = 0x2c;
buf6[1] = 5;
buf6[2] = 0xc0;
@@ -190,7 +193,7 @@ static int dw2102_i2c_transfer(struct i2c_adapter *adap,
struct i2c_msg msg[],
ret = dw210x_op_rw(d->udev, 0xb2, 0, 0,
buf6, 7, DW210X_WRITE_MSG);
} else {
- /* read from tuner */
+ /* read from tuner */
ret = dw210x_op_rw(d->udev, 0xb5, 0, 0,
buf6, 1, DW210X_READ_MSG);
msg[0].buf[0] = buf6[0];
@@ -273,7 +276,8 @@ static int dw2102_serit_i2c_transfer(struct i2c_adapter
*adap,
return num;
}
-static int dw2102_earda_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg
msg[], int num)
+static int dw2102_earda_i2c_transfer(struct i2c_adapter *adap,
+ struct i2c_msg msg[], int num)
{
struct dvb_usb_device *d = i2c_get_adapdata(adap);
int ret = 0;
@@ -346,7 +350,8 @@ static int dw2102_earda_i2c_transfer(struct i2c_adapter
*adap, struct i2c_msg ms
return num;
}
-static int dw2104_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],
int num)
+static int dw2104_i2c_transfer(struct i2c_adapter *adap,
+ struct i2c_msg msg[], int num)
{
struct dvb_usb_device *d = i2c_get_adapdata(adap);
int ret = 0;
@@ -712,7 +717,8 @@ static int dw210x_read_mac_address(struct dvb_usb_device
*d, u8 mac[6])
u8 eeprom[256], eepromline[16];
for (i = 0; i < 256; i++) {
- if (dw210x_op_rw(d->udev, 0xb6, 0xa0 , i, ibuf, 2,
DW210X_READ_MSG) < 0) {
+ if (dw210x_op_rw(d->udev, 0xb6, 0xa0 , i, ibuf, 2,
+ DW210X_READ_MSG) < 0) {
err("read eeprom failed.");
return -1;
} else {
@@ -882,6 +888,41 @@ static int s660_set_voltage(struct dvb_frontend *fe,
fe_sec_voltage_t voltage)
return 0;
}
+static int bstusb_set_voltage(struct dvb_frontend *fe, fe_
