cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Sun Jul 17 04:00:10 CEST 2016
git branch: test
git hash:   e05b1872f29a85532c2b34e3a4974a27158f1463
gcc version:i686-linux-gcc (GCC) 5.3.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3428-gdfe27cf
host hardware:  x86_64
host os:4.6.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: ERRORS
linux-git-blackfin-bf561: OK
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: WARNINGS
linux-2.6.36.4-i686: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-3.0.60-i686: ERRORS
linux-3.1.10-i686: ERRORS
linux-3.2.37-i686: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.7.4-i686: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.23-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0-i686: ERRORS
linux-4.1.1-i686: ERRORS
linux-4.2-i686: ERRORS
linux-4.3-i686: ERRORS
linux-4.4-i686: ERRORS
linux-4.5-i686: ERRORS
linux-4.6-i686: ERRORS
linux-4.7-rc1-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.60-x86_64: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.37-x86_64: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.4-x86_64: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.23-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0-x86_64: ERRORS
linux-4.1.1-x86_64: ERRORS
linux-4.2-x86_64: ERRORS
linux-4.3-x86_64: ERRORS
linux-4.4-x86_64: ERRORS
linux-4.5-x86_64: ERRORS
linux-4.6-x86_64: ERRORS
linux-4.7-rc1-x86_64: ERRORS
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API 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 2/4] dt-bindings: Add a binding for Mediatek MDP

[Rob Herring]

On Thu, Jul 14, 2016 at 08:17:59PM +0800, Minghsiu Tsai wrote:
> Add a DT binding documentation of MDP for the MT8173 SoC
> from Mediatek
> 
> Signed-off-by: Minghsiu Tsai 
> ---
>  .../devicetree/bindings/media/mediatek-mdp.txt |   92 
> 
>  1 file changed, 92 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/mediatek-mdp.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt 
> b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> new file mode 100644
> index 000..ef570c3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> @@ -0,0 +1,92 @@
> +* Mediatek Media Data Path
> +
> +Media Data Path is used for scaling and color space conversion.
> +
> +Required properties:
> +  - compatible : should contain them as below:
> +"mediatek,mt8173-mdp"
> +"mediatek,mt8173-mdp-rdma"
> +"mediatek,mt8173-mdp-rsz"
> +"mediatek,mt8173-mdp-wdma"
> +"mediatek,mt8173-mdp-wrot"
> +  - clocks : device clocks
> +  - power-domains : a phandle to the power domain.
> +  - mediatek,larb : should contain the larbes of current platform
> +  - iommus : Mediatek IOMMU H/W has designed the fixed associations with
> +the multimedia H/W. and there is only one multimedia iommu domain.
> +"iommus = < portid>" the "portid" is from
> +dt-bindings\iommu\mt8173-iommu-port.h, it means that this portid will
> +enable iommu. The portid default is disable iommu if "< 
> portid>"
> +don't be added.
> +  - mediatek,vpu : the node of video processor unit

These properties don't apply to all the nodes. I think you need a 
section for each IP block.
--
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] af9035: fix dual tuner detection with PCTV 79e

[Stefan Pöschel]

Am 15.07.2016 um 08:21 schrieb Antti Palosaari:
> Applied and PULL requested for 4.7.

Great, thanks!

> Anyhow, it does not apply for 4.6. You must backport that patch to 4.6
> stable also!

I have never done backporting before, so I need some advice I think:
Am I right that I have to create the patch, now just based on tag "v4.6"
of the media_tree repo?
And then move that patch (properly named) to the backports subdir of the
media_build repo, with regarding modification of the backports.txt:
Using an "add" entry under "[4.6.255]" and an "delete" entry under
"[4.5.255]" (so that it just gets applied to 4.6.x) ?

BTW I wonder about the status update of
https://patchwork.linuxtv.org/patch/35337/ from "New" to "Superseeded"
(instead of "Accepted")...why is this?

Regards,
Stefan


> On 07/11/2016 08:31 PM, Stefan Pöschel wrote:
>> The value 5 of the EEPROM_TS_MODE register (meaning dual tuner
>> presence) is
>> only valid for AF9035 devices. For IT9135 devices it is invalid and
>> led to a
>> false positive dual tuner mode detection with PCTV 79e.
>> Therefore on non-AF9035 devices and with value 5 the driver now
>> defaults to
>> single tuner mode and outputs a regarding info message to log.
>>
>> This fixes Bugzilla bug #118561.
>>
>> Reported-by: Marc Duponcheel 
>> Signed-off-by: Stefan Pöschel 
>> ---
>>  drivers/media/usb/dvb-usb-v2/af9035.c | 50
>> +++
>>  drivers/media/usb/dvb-usb-v2/af9035.h |  2 +-
>>  2 files changed, 34 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c
>> b/drivers/media/usb/dvb-usb-v2/af9035.c
>> index eabede4..ca018cd 100644
>> --- a/drivers/media/usb/dvb-usb-v2/af9035.c
>> +++ b/drivers/media/usb/dvb-usb-v2/af9035.c
>> @@ -496,7 +496,8 @@ static int af9035_identify_state(struct
>> dvb_usb_device *d, const char **name)
>>  {
>>  struct state *state = d_to_priv(d);
>>  struct usb_interface *intf = d->intf;
>> -int ret;
>> +int ret, ts_mode_invalid;
>> +u8 tmp;
>>  u8 wbuf[1] = { 1 };
>>  u8 rbuf[4];
>>  struct usb_req req = { CMD_FW_QUERYINFO, 0, sizeof(wbuf), wbuf,
>> @@ -530,6 +531,36 @@ static int af9035_identify_state(struct
>> dvb_usb_device *d, const char **name)
>>  state->eeprom_addr = EEPROM_BASE_AF9035;
>>  }
>>
>> +
>> +/* check for dual tuner mode */
>> +ret = af9035_rd_reg(d, state->eeprom_addr + EEPROM_TS_MODE, );
>> +if (ret < 0)
>> +goto err;
>> +
>> +ts_mode_invalid = 0;
>> +switch (tmp) {
>> +case 0:
>> +break;
>> +case 1:
>> +case 3:
>> +state->dual_mode = true;
>> +break;
>> +case 5:
>> +if (state->chip_type != 0x9135 && state->chip_type != 0x9306)
>> +state->dual_mode = true;/* AF9035 */
>> +else
>> +ts_mode_invalid = 1;
>> +break;
>> +default:
>> +ts_mode_invalid = 1;
>> +}
>> +
>> +dev_dbg(>dev, "ts mode=%d dual mode=%d\n", tmp,
>> state->dual_mode);
>> +
>> +if (ts_mode_invalid)
>> +dev_info(>dev, "ts mode=%d not supported, defaulting to
>> single tuner mode!", tmp);
>> +
>> +
>>  ret = af9035_ctrl_msg(d, );
>>  if (ret < 0)
>>  goto err;
>> @@ -698,11 +729,7 @@ static int af9035_download_firmware(struct
>> dvb_usb_device *d,
>>   * which is done by master demod.
>>   * Master feeds also clock and controls power via GPIO.
>>   */
>> -ret = af9035_rd_reg(d, state->eeprom_addr + EEPROM_TS_MODE, );
>> -if (ret < 0)
>> -goto err;
>> -
>> -if (tmp == 1 || tmp == 3 || tmp == 5) {
>> +if (state->dual_mode) {
>>  /* configure gpioh1, reset & power slave demod */
>>  ret = af9035_wr_reg_mask(d, 0x00d8b0, 0x01, 0x01);
>>  if (ret < 0)
>> @@ -835,17 +862,6 @@ static int af9035_read_config(struct
>> dvb_usb_device *d)
>>  }
>>
>>
>> -
>> -/* check if there is dual tuners */
>> -ret = af9035_rd_reg(d, state->eeprom_addr + EEPROM_TS_MODE, );
>> -if (ret < 0)
>> -goto err;
>> -
>> -if (tmp == 1 || tmp == 3 || tmp == 5)
>> -state->dual_mode = true;
>> -
>> -dev_dbg(>dev, "ts mode=%d dual mode=%d\n", tmp,
>> state->dual_mode);
>> -
>>  if (state->dual_mode) {
>>  /* read 2nd demodulator I2C address */
>>  ret = af9035_rd_reg(d,
>> diff --git a/drivers/media/usb/dvb-usb-v2/af9035.h
>> b/drivers/media/usb/dvb-usb-v2/af9035.h
>> index c91d1a3..1f83c92 100644
>> --- a/drivers/media/usb/dvb-usb-v2/af9035.h
>> +++ b/drivers/media/usb/dvb-usb-v2/af9035.h
>> @@ -113,7 +113,7 @@ static const u32 clock_lut_it9135[] = {
>>   * 0  TS
>>   * 1  DCA + PIP
>>   * 3  PIP
>> - * 5  DCA + PIP
>> + * 5  DCA + PIP (AF9035 only)
>>   * n  DCA
>>   *
>>   * Values 0, 3 and 5 are seen to this day. 0 for single TS and 3/5
>> for dual TS.
>>
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to 

Re: [PATCH] [media] dw2102: Add support for Terratec Cinergy S2 USB BOX

[Mauro Carvalho Chehab]

Em Sat, 16 Jul 2016 18:26:35 +0200
Olli Salonen  escreveu:

> Hi guys,
> 
> It seems Philipp added the support for this device in dw2102 driver
> and Benjamin did that for the dvbsky driver a bit earlier.
> 
> # grep -i 0ccdp0105 /lib/modules/$(uname -r)/modules.alias
> alias usb:v0CCDp0105d*dc*dsc*dp*ic*isc*ip*in* dvb_usb_dvbsky
> alias usb:v0CCDp0105d*dc*dsc*dp*ic*isc*ip*in* dvb_usb_dw2102
> 
> Any suggestions on how to resolve this conflict?

Let me understand something: the same chipset is supported by both
modules? Or the device at dvbsky uses a different hardware than
the one at dw2102? In the latter case, sometimes it is possible
to distinguish the hardware based on the USB release info. We have
a few cases like that. One that comes on my mind is a pixelview
device, that uses the same ID for two different devices:

cx231xx:

{USB_DEVICE_VER(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD, 0x4000, 0x4001),
 .driver_info = CX231XX_BOARD_PV_PLAYTV_USB_HYBRID},

dib0700:

{ USB_DEVICE_VER(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD, 0x000, 0x3f00) 
},

Regards,
Mauro



> 
> Cheers,
> -olli
> 
> On 4 January 2016 at 20:32, Philipp Zabel  wrote:
> > The Terratec Cinergy S2 USB BOX uses a Montage M88TS2022 tuner
> > and a M88DS3103 demodulator, same as Technotrend TT-connect S2-4600.
> > This patch adds the missing USB Product ID to make it work.
> >
> > Signed-off-by: Philipp Zabel 
> > ---
> >  drivers/media/usb/dvb-usb/dw2102.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/usb/dvb-usb/dw2102.c 
> > b/drivers/media/usb/dvb-usb/dw2102.c
> > index 14ef25d..9d18801 100644
> > --- a/drivers/media/usb/dvb-usb/dw2102.c
> > +++ b/drivers/media/usb/dvb-usb/dw2102.c
> > @@ -1688,6 +1688,7 @@ enum dw2102_table_entry {
> > TECHNOTREND_S2_4600,
> > TEVII_S482_1,
> > TEVII_S482_2,
> > +   TERRATEC_CINERGY_S2_BOX,
> >  };
> >
> >  static struct usb_device_id dw2102_table[] = {
> > @@ -1715,6 +1716,7 @@ static struct usb_device_id dw2102_table[] = {
> > USB_PID_TECHNOTREND_CONNECT_S2_4600)},
> > [TEVII_S482_1] = {USB_DEVICE(0x9022, 0xd483)},
> > [TEVII_S482_2] = {USB_DEVICE(0x9022, 0xd484)},
> > +   [TERRATEC_CINERGY_S2_BOX] = {USB_DEVICE(USB_VID_TERRATEC, 0x0105)},
> > { }
> >  };
> >
> > @@ -2232,7 +2234,7 @@ static struct dvb_usb_device_properties 
> > tt_s2_4600_properties = {
> > } },
> > }
> > },
> > -   .num_device_descs = 3,
> > +   .num_device_descs = 4,
> > .devices = {
> > { "TechnoTrend TT-connect S2-4600",
> > { _table[TECHNOTREND_S2_4600], NULL },
> > @@ -2246,6 +2248,10 @@ static struct dvb_usb_device_properties 
> > tt_s2_4600_properties = {
> > { _table[TEVII_S482_2], NULL },
> > { NULL },
> > },
> > +   { "Terratec Cinergy S2 USB BOX",
> > +   { _table[TERRATEC_CINERGY_S2_BOX], NULL },
> > +   { NULL },
> > +   },
> > }
> >  };
> >
> > --
> > 2.6.2
> >  


-- 
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] [media] dw2102: Add support for Terratec Cinergy S2 USB BOX

[Olli Salonen]

Hi guys,

It seems Philipp added the support for this device in dw2102 driver
and Benjamin did that for the dvbsky driver a bit earlier.

# grep -i 0ccdp0105 /lib/modules/$(uname -r)/modules.alias
alias usb:v0CCDp0105d*dc*dsc*dp*ic*isc*ip*in* dvb_usb_dvbsky
alias usb:v0CCDp0105d*dc*dsc*dp*ic*isc*ip*in* dvb_usb_dw2102

Any suggestions on how to resolve this conflict?

Cheers,
-olli

On 4 January 2016 at 20:32, Philipp Zabel  wrote:
> The Terratec Cinergy S2 USB BOX uses a Montage M88TS2022 tuner
> and a M88DS3103 demodulator, same as Technotrend TT-connect S2-4600.
> This patch adds the missing USB Product ID to make it work.
>
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/media/usb/dvb-usb/dw2102.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/dvb-usb/dw2102.c 
> b/drivers/media/usb/dvb-usb/dw2102.c
> index 14ef25d..9d18801 100644
> --- a/drivers/media/usb/dvb-usb/dw2102.c
> +++ b/drivers/media/usb/dvb-usb/dw2102.c
> @@ -1688,6 +1688,7 @@ enum dw2102_table_entry {
> TECHNOTREND_S2_4600,
> TEVII_S482_1,
> TEVII_S482_2,
> +   TERRATEC_CINERGY_S2_BOX,
>  };
>
>  static struct usb_device_id dw2102_table[] = {
> @@ -1715,6 +1716,7 @@ static struct usb_device_id dw2102_table[] = {
> USB_PID_TECHNOTREND_CONNECT_S2_4600)},
> [TEVII_S482_1] = {USB_DEVICE(0x9022, 0xd483)},
> [TEVII_S482_2] = {USB_DEVICE(0x9022, 0xd484)},
> +   [TERRATEC_CINERGY_S2_BOX] = {USB_DEVICE(USB_VID_TERRATEC, 0x0105)},
> { }
>  };
>
> @@ -2232,7 +2234,7 @@ static struct dvb_usb_device_properties 
> tt_s2_4600_properties = {
> } },
> }
> },
> -   .num_device_descs = 3,
> +   .num_device_descs = 4,
> .devices = {
> { "TechnoTrend TT-connect S2-4600",
> { _table[TECHNOTREND_S2_4600], NULL },
> @@ -2246,6 +2248,10 @@ static struct dvb_usb_device_properties 
> tt_s2_4600_properties = {
> { _table[TEVII_S482_2], NULL },
> { NULL },
> },
> +   { "Terratec Cinergy S2 USB BOX",
> +   { _table[TERRATEC_CINERGY_S2_BOX], NULL },
> +   { NULL },
> +   },
> }
>  };
>
> --
> 2.6.2
>
--
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 2/6] [media] Documentation: Add HSV format

[Hans Verkuil]

On 07/16/2016 05:57 PM, Ricardo Ribalda Delgado wrote:
> Hi Hans
> 
> On Sat, Jul 16, 2016 at 5:28 PM, Hans Verkuil  wrote:
> 
>>
>>> +
>>> +enum v4l2_rgb_encoding {
>>> +   V4L2_RGB_ENC_FULL   = 32,
>>> +   V4L2_HSV_ENC_16_235 = 33,
>>> +};
>>
>> No.
> 
> I was trying to fit also Laurent special 16-235 RGB format. I will
> remove it on future versions.
> 
> 
> Can I make this change as 2 new patches on my vivid-hsv patchset?
> 
> 1) Add hsv_encoding
> 2) Add support for vivid hsv_encoding

Yes. I prefer them last in the series, since I am not quite 100% certain yet.

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 v2 2/6] [media] Documentation: Add HSV format

[Ricardo Ribalda Delgado]

Hi Hans

On Sat, Jul 16, 2016 at 5:28 PM, Hans Verkuil  wrote:

>
>> +
>> +enum v4l2_rgb_encoding {
>> +   V4L2_RGB_ENC_FULL   = 32,
>> +   V4L2_HSV_ENC_16_235 = 33,
>> +};
>
> No.

I was trying to fit also Laurent special 16-235 RGB format. I will
remove it on future versions.


Can I make this change as 2 new patches on my vivid-hsv patchset?

1) Add hsv_encoding
2) Add support for vivid hsv_encoding


?


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

Re: [PATCH v2 2/6] [media] Documentation: Add HSV format

[Hans Verkuil]

On 07/16/2016 04:32 PM, Ricardo Ribalda Delgado wrote:
> Hi
> 
> On Sat, Jul 16, 2016 at 4:12 PM, Laurent Pinchart
>  wrote:
> 
>> I'd still like to know about it for my personal information :-)
> 
> Maybe it is just a very cheap gamma.
> 
>>
>>> Anyway, I am inclined to use ycbcr_enc as well.
>>
>> I'm glad we agree.
>>
> 
> Are you thinking about something like this:
> 
> 
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index c7fb760386cf..3e613fba1b20 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -330,6 +330,16 @@ enum v4l2_ycbcr_encoding {
> V4L2_YCBCR_ENC_SMPTE240M  = 8,
>  };
> 
> +enum v4l2_hsv_encoding {
> +   V4L2_HSV_ENC_180= 16,
> +   V4L2_HSV_ENC_256= 17,
> +};

Yes.

> +
> +enum v4l2_rgb_encoding {
> +   V4L2_RGB_ENC_FULL   = 32,
> +   V4L2_HSV_ENC_16_235 = 33,
> +};

No.

The starting point is RGB, so there is nothing to encode. YCbCr and HSV
are transformations from RGB (or R'G'B' to be precise).

The basic chain is:

XYZ -> colorspace conversion -> RGB -> transfer function -> R'G'B'

and after this there is an optional step that converts R'G'B' to
Y'CbCr or HSV (ycbcr_enc or hsv_enc). The final step is the quantization
step where you end up with the actual color component values.

There doesn't seem to be something like limited range HSV, so I'd say it's
full range only.

Regards,

Hans

> +
>  /*
>   * Determine how YCBCR_ENC_DEFAULT should map to a proper Y'CbCr encoding.
>   * This depends on the colorspace.
> @@ -455,7 +465,11 @@ struct v4l2_pix_format {
> __u32   colorspace; /* enum v4l2_colorspace */
> __u32   priv;   /* private data,
> depends on pixelformat */
> __u32   flags;  /* format flags
> (V4L2_PIX_FMT_FLAG_*) */
> -   __u32   ycbcr_enc;  /* enum v4l2_ycbcr_encoding */
> +   union {
> +   __u32   ycbcr_enc;  /* enum
> v4l2_ycbcr_encoding */
> +   __u32   hsv_enc;/* enum
> v4l2_hsv_encoding */
> +   __u32   rgb_enc;/* enum
> v4l2_rgb_encoding */
> +   };
> __u32   quantization;   /* enum v4l2_quantization */
> __u32   xfer_func;  /* enum v4l2_xfer_func */
>  };
> @@ -1988,7 +2002,11 @@ struct v4l2_pix_format_mplane {
> struct v4l2_plane_pix_formatplane_fmt[VIDEO_MAX_PLANES];
> __u8num_planes;
> __u8flags;
> -   __u8ycbcr_enc;
> +   union {
> +   __u8ycbcr_enc;  /* enum
> v4l2_ycbcr_encoding */
> +   __u8hsv_enc;/* enum
> v4l2_hsv_encoding */
> +   __u8rgb_enc;/* enum
> v4l2_rgb_encoding */
> +   };
> __u8quantization;
> __u8xfer_func;
> __u8reserved[7];
> 
>> --
> 
> 
> Best regards!
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/6] [media] Documentation: Add HSV format

[Hans Verkuil]

On 07/16/2016 04:12 PM, Laurent Pinchart wrote:
>> Limited vs full range quantization is handled by the quantization field.
>> It's there already.
> 
> Right. I wonder how we'll deal with that when someone will come up with more 
> than one limited range quantizations, have you thought about it ?

There is just limited and full range. Limited range is basically a left-over
from analog TV.

>> Limited range RGB is needed for HDMI due to a brain-dead spec when dealing
>> with certain kinds of TVs and configurations. Don't ask, it's horrible.
> 
> I'd still like to know about it for my personal information :-)

RGB video over HDMI is limited range for CE timings (i.e. 720p, 1080p, 4k)
unless signaled otherwise through the AVI InfoFrame. And you can only
signal that if the sink supports it in the EDID (and doesn't lie about it).

Typically TVs follow CE timings, so hooking up a PC to a TV may very well
cause problems (and often does).

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 v2 2/6] [media] Documentation: Add HSV format

[Ricardo Ribalda Delgado]

Hi

On Sat, Jul 16, 2016 at 4:12 PM, Laurent Pinchart
 wrote:

> I'd still like to know about it for my personal information :-)

Maybe it is just a very cheap gamma.

>
>> Anyway, I am inclined to use ycbcr_enc as well.
>
> I'm glad we agree.
>

Are you thinking about something like this:


diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index c7fb760386cf..3e613fba1b20 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -330,6 +330,16 @@ enum v4l2_ycbcr_encoding {
V4L2_YCBCR_ENC_SMPTE240M  = 8,
 };

+enum v4l2_hsv_encoding {
+   V4L2_HSV_ENC_180= 16,
+   V4L2_HSV_ENC_256= 17,
+};
+
+enum v4l2_rgb_encoding {
+   V4L2_RGB_ENC_FULL   = 32,
+   V4L2_HSV_ENC_16_235 = 33,
+};
+
 /*
  * Determine how YCBCR_ENC_DEFAULT should map to a proper Y'CbCr encoding.
  * This depends on the colorspace.
@@ -455,7 +465,11 @@ struct v4l2_pix_format {
__u32   colorspace; /* enum v4l2_colorspace */
__u32   priv;   /* private data,
depends on pixelformat */
__u32   flags;  /* format flags
(V4L2_PIX_FMT_FLAG_*) */
-   __u32   ycbcr_enc;  /* enum v4l2_ycbcr_encoding */
+   union {
+   __u32   ycbcr_enc;  /* enum
v4l2_ycbcr_encoding */
+   __u32   hsv_enc;/* enum
v4l2_hsv_encoding */
+   __u32   rgb_enc;/* enum
v4l2_rgb_encoding */
+   };
__u32   quantization;   /* enum v4l2_quantization */
__u32   xfer_func;  /* enum v4l2_xfer_func */
 };
@@ -1988,7 +2002,11 @@ struct v4l2_pix_format_mplane {
struct v4l2_plane_pix_formatplane_fmt[VIDEO_MAX_PLANES];
__u8num_planes;
__u8flags;
-   __u8ycbcr_enc;
+   union {
+   __u8ycbcr_enc;  /* enum
v4l2_ycbcr_encoding */
+   __u8hsv_enc;/* enum
v4l2_hsv_encoding */
+   __u8rgb_enc;/* enum
v4l2_rgb_encoding */
+   };
__u8quantization;
__u8xfer_func;
__u8reserved[7];

> --


Best regards!

-- 
Ricardo Ribalda
--
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 2/6] [media] Documentation: Add HSV format

[Laurent Pinchart]

Hi Hans,

On Saturday 16 Jul 2016 15:59:08 Hans Verkuil wrote:
> On 07/16/2016 02:38 PM, Laurent Pinchart wrote:
>> On Saturday 16 Jul 2016 10:19:29 Hans Verkuil wrote:
>>> On 07/15/2016 08:11 PM, Laurent Pinchart wrote:
 On Friday 15 Jul 2016 18:13:15 Ricardo Ribalda Delgado wrote:
> Describe the HSV formats
> 
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
> 
>  Documentation/media/uapi/v4l/hsv-formats.rst   |  19 ++
>  Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 253
>  +++
>  Documentation/media/uapi/v4l/pixfmt.rst|   1 +
>  Documentation/media/uapi/v4l/v4l2.rst  |   5 +
>  4 files changed, 278 insertions(+)
>  create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
> 
> diff --git a/Documentation/media/uapi/v4l/hsv-formats.rst
> b/Documentation/media/uapi/v4l/hsv-formats.rst new file mode 100644
> index ..f0f2615eaa95
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/hsv-formats.rst
> @@ -0,0 +1,19 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _hsv-formats:
> +
> +***
> +HSV Formats
> +***
> +
> +These formats store the color information of the image
> +in a geometrical representation. The colors are mapped into a
> +cylinder, where the angle is the HUE, the height is the VALUE
> +and the distance to the center is the SATURATION. This is a very
> +useful format for image segmentation algorithms.
> +
> +
> +.. toctree::
> +:maxdepth: 1
> +
> +pixfmt-packed-hsv
> diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
> b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst new file mode
> 100644
> index ..b297aa4f7ba6
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
> @@ -0,0 +1,253 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _packed-hsv:
> +
> +**
> +Packed HSV formats
> +**
> +
> +*man Packed HSV formats(2)*
> +
> +Packed HSV formats
> +
> +
> +Description
> +===
> +
> +The HUE (h) is meassured in degrees, one LSB represents two degrees.
 
 Is this common ? I have a device that can handle HSV data, I need to
 check how it maps the hue values to binary, but I'm pretty sure they
 cover the full 0-255 range. We would then have to support the two
 formats. Separate 4CCs are an option, but reporting the range separately
 (possibly through the colorspace API) might be better. Any thought on
 that ?
>>> 
>>> It's either a separate 4cc or we do something with the ycbcr_enc field
>>> (reinterpreted as hsv_enc). I'm not sure, I would have to think some more
>>> about that.
>> 
>> I'm inclined to use the ycbcr_enc field, especially given that a similar
>> usage could be useful for RGB as well (don't ask me what it's supposed to
>> be used for, but I have hardware that support limiting the RGB values
>> range to 16-235).
> 
> Limited vs full range quantization is handled by the quantization field.
> It's there already.

Right. I wonder how we'll deal with that when someone will come up with more 
than one limited range quantizations, have you thought about it ?

> Limited range RGB is needed for HDMI due to a brain-dead spec when dealing
> with certain kinds of TVs and configurations. Don't ask, it's horrible.

I'd still like to know about it for my personal information :-)

> Anyway, I am inclined to use ycbcr_enc as well.

I'm glad we agree.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 2/6] [media] Documentation: Add HSV format

[Hans Verkuil]

On 07/16/2016 02:38 PM, Laurent Pinchart wrote:
> Hi Hans,
> 
> On Saturday 16 Jul 2016 10:19:29 Hans Verkuil wrote:
>> On 07/15/2016 08:11 PM, Laurent Pinchart wrote:
>>> On Friday 15 Jul 2016 18:13:15 Ricardo Ribalda Delgado wrote:
 Describe the HSV formats

 Signed-off-by: Ricardo Ribalda Delgado 
 ---

  Documentation/media/uapi/v4l/hsv-formats.rst   |  19 ++
  Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 253 +++
  Documentation/media/uapi/v4l/pixfmt.rst|   1 +
  Documentation/media/uapi/v4l/v4l2.rst  |   5 +
  4 files changed, 278 insertions(+)
  create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
  create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst

 diff --git a/Documentation/media/uapi/v4l/hsv-formats.rst
 b/Documentation/media/uapi/v4l/hsv-formats.rst new file mode 100644
 index ..f0f2615eaa95
 --- /dev/null
 +++ b/Documentation/media/uapi/v4l/hsv-formats.rst
 @@ -0,0 +1,19 @@
 +.. -*- coding: utf-8; mode: rst -*-
 +
 +.. _hsv-formats:
 +
 +***
 +HSV Formats
 +***
 +
 +These formats store the color information of the image
 +in a geometrical representation. The colors are mapped into a
 +cylinder, where the angle is the HUE, the height is the VALUE
 +and the distance to the center is the SATURATION. This is a very
 +useful format for image segmentation algorithms.
 +
 +
 +.. toctree::
 +:maxdepth: 1
 +
 +pixfmt-packed-hsv
 diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
 b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst new file mode 100644
 index ..b297aa4f7ba6
 --- /dev/null
 +++ b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
 @@ -0,0 +1,253 @@
 +.. -*- coding: utf-8; mode: rst -*-
 +
 +.. _packed-hsv:
 +
 +**
 +Packed HSV formats
 +**
 +
 +*man Packed HSV formats(2)*
 +
 +Packed HSV formats
 +
 +
 +Description
 +===
 +
 +The HUE (h) is meassured in degrees, one LSB represents two degrees.
>>>
>>> Is this common ? I have a device that can handle HSV data, I need to check
>>> how it maps the hue values to binary, but I'm pretty sure they cover the
>>> full 0-255 range. We would then have to support the two formats. Separate
>>> 4CCs are an option, but reporting the range separately (possibly through
>>> the colorspace API) might be better. Any thought on that ?
>>
>> It's either a separate 4cc or we do something with the ycbcr_enc field
>> (reinterpreted as hsv_enc). I'm not sure, I would have to think some more
>> about that.
> 
> I'm inclined to use the ycbcr_enc field, especially given that a similar 
> usage 
> could be useful for RGB as well (don't ask me what it's supposed to be used 
> for, but I have hardware that support limiting the RGB values range to 
> 16-235).

Limited vs full range quantization is handled by the quantization field. It's
there already.

Limited range RGB is needed for HDMI due to a brain-dead spec when dealing with
certain kinds of TVs and configurations. Don't ask, it's horrible.

Anyway, I am inclined to use ycbcr_enc as well.

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 v2 2/6] [media] Documentation: Add HSV format

[Laurent Pinchart]

Hi Hans,

On Saturday 16 Jul 2016 10:19:29 Hans Verkuil wrote:
> On 07/15/2016 08:11 PM, Laurent Pinchart wrote:
> > On Friday 15 Jul 2016 18:13:15 Ricardo Ribalda Delgado wrote:
> >> Describe the HSV formats
> >> 
> >> Signed-off-by: Ricardo Ribalda Delgado 
> >> ---
> >> 
> >>  Documentation/media/uapi/v4l/hsv-formats.rst   |  19 ++
> >>  Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 253 +++
> >>  Documentation/media/uapi/v4l/pixfmt.rst|   1 +
> >>  Documentation/media/uapi/v4l/v4l2.rst  |   5 +
> >>  4 files changed, 278 insertions(+)
> >>  create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
> >>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
> >> 
> >> diff --git a/Documentation/media/uapi/v4l/hsv-formats.rst
> >> b/Documentation/media/uapi/v4l/hsv-formats.rst new file mode 100644
> >> index ..f0f2615eaa95
> >> --- /dev/null
> >> +++ b/Documentation/media/uapi/v4l/hsv-formats.rst
> >> @@ -0,0 +1,19 @@
> >> +.. -*- coding: utf-8; mode: rst -*-
> >> +
> >> +.. _hsv-formats:
> >> +
> >> +***
> >> +HSV Formats
> >> +***
> >> +
> >> +These formats store the color information of the image
> >> +in a geometrical representation. The colors are mapped into a
> >> +cylinder, where the angle is the HUE, the height is the VALUE
> >> +and the distance to the center is the SATURATION. This is a very
> >> +useful format for image segmentation algorithms.
> >> +
> >> +
> >> +.. toctree::
> >> +:maxdepth: 1
> >> +
> >> +pixfmt-packed-hsv
> >> diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
> >> b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst new file mode 100644
> >> index ..b297aa4f7ba6
> >> --- /dev/null
> >> +++ b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
> >> @@ -0,0 +1,253 @@
> >> +.. -*- coding: utf-8; mode: rst -*-
> >> +
> >> +.. _packed-hsv:
> >> +
> >> +**
> >> +Packed HSV formats
> >> +**
> >> +
> >> +*man Packed HSV formats(2)*
> >> +
> >> +Packed HSV formats
> >> +
> >> +
> >> +Description
> >> +===
> >> +
> >> +The HUE (h) is meassured in degrees, one LSB represents two degrees.
> > 
> > Is this common ? I have a device that can handle HSV data, I need to check
> > how it maps the hue values to binary, but I'm pretty sure they cover the
> > full 0-255 range. We would then have to support the two formats. Separate
> > 4CCs are an option, but reporting the range separately (possibly through
> > the colorspace API) might be better. Any thought on that ?
> 
> It's either a separate 4cc or we do something with the ycbcr_enc field
> (reinterpreted as hsv_enc). I'm not sure, I would have to think some more
> about that.

I'm inclined to use the ycbcr_enc field, especially given that a similar usage 
could be useful for RGB as well (don't ask me what it's supposed to be used 
for, but I have hardware that support limiting the RGB values range to 
16-235).

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] [media] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf

[Luis de Bethencourt]

On 15/07/16 17:26, Javier Martinez Canillas wrote:
> The buffer planes' dma-buf are currently mapped when buffers are queued
> from userspace but it's more appropriate to do the mapping when buffers
> are queued in the driver since that's when the actual DMA operation are
> going to happen.
> 
> Suggested-by: Nicolas Dufresne 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
> Hello,
> 
> A side effect of this change is that if the dmabuf map fails for some
> reasons (i.e: a driver using the DMA contig memory allocator but CMA
> not being enabled), the fail will no longer happen on VIDIOC_QBUF but
> later (i.e: in VIDIOC_STREAMON).
> 
> I don't know if that's an issue though but I think is worth mentioning.
> 
> Best regards,
> Javier
> 

Just run this path on the ODROID using GStreamer and the vivid driver.
It worked nicely.

Tested-by: Luis de Bethencourt 

Thanks Javier,
Luis

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

[PATCH v2] [media] ad9389b: Remove deprecated create_singlethread_workqueue

[Bhaktipriya Shridhar]

The workqueue work_queue is involved in EDID (Extended Display
Identification Data) handling.

It has a single work item(>edid_handler) and hence
doesn't require ordering. It is not being used on a memory reclaim path.
Hence, the singlethreaded workqueue has been replaced with
the use of system_wq.

>edid_handler is a self requeueing work item and it has been
been sync cancelled in ad9389b_remove() to ensure that nothing is
pending when the driver is disconnected.

The unused label err_unreg has also been dropped.

Signed-off-by: Bhaktipriya Shridhar 
---
 Changes in v2:
-Fixes kbuild warning: label 'err_unreg' defined but not used.

 drivers/media/i2c/ad9389b.c | 22 --
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/drivers/media/i2c/ad9389b.c b/drivers/media/i2c/ad9389b.c
index 0462f46..5fd2350 100644
--- a/drivers/media/i2c/ad9389b.c
+++ b/drivers/media/i2c/ad9389b.c
@@ -98,7 +98,6 @@ struct ad9389b_state {
struct ad9389b_state_edid edid;
/* Running counter of the number of detected EDIDs (for debugging) */
unsigned edid_detect_counter;
-   struct workqueue_struct *work_queue;
struct delayed_work edid_handler; /* work entry */
 };

@@ -843,8 +842,7 @@ static void ad9389b_edid_handler(struct work_struct *work)
v4l2_dbg(1, debug, sd, "%s: edid read failed\n", 
__func__);
ad9389b_s_power(sd, false);
ad9389b_s_power(sd, true);
-   queue_delayed_work(state->work_queue,
-  >edid_handler, EDID_DELAY);
+   schedule_delayed_work(>edid_handler, EDID_DELAY);
return;
}
}
@@ -933,8 +931,7 @@ static void ad9389b_update_monitor_present_status(struct 
v4l2_subdev *sd)
ad9389b_setup(sd);
ad9389b_notify_monitor_detect(sd);
state->edid.read_retries = EDID_MAX_RETRIES;
-   queue_delayed_work(state->work_queue,
-  >edid_handler, EDID_DELAY);
+   schedule_delayed_work(>edid_handler, EDID_DELAY);
} else if (!(status & MASK_AD9389B_HPD_DETECT)) {
v4l2_dbg(1, debug, sd, "%s: hotplug not detected\n", __func__);
state->have_monitor = false;
@@ -1065,8 +1062,7 @@ static bool ad9389b_check_edid_status(struct v4l2_subdev 
*sd)
ad9389b_wr(sd, 0xc9, 0xf);
ad9389b_wr(sd, 0xc4, state->edid.segments);
state->edid.read_retries = EDID_MAX_RETRIES;
-   queue_delayed_work(state->work_queue,
-  >edid_handler, EDID_DELAY);
+   schedule_delayed_work(>edid_handler, EDID_DELAY);
return false;
}

@@ -1170,13 +1166,6 @@ static int ad9389b_probe(struct i2c_client *client, 
const struct i2c_device_id *
goto err_entity;
}

-   state->work_queue = create_singlethread_workqueue(sd->name);
-   if (state->work_queue == NULL) {
-   v4l2_err(sd, "could not create workqueue\n");
-   err = -ENOMEM;
-   goto err_unreg;
-   }
-
INIT_DELAYED_WORK(>edid_handler, ad9389b_edid_handler);
state->dv_timings = dv1080p60;

@@ -1187,8 +1176,6 @@ static int ad9389b_probe(struct i2c_client *client, const 
struct i2c_device_id *
  client->addr << 1, client->adapter->name);
return 0;

-err_unreg:
-   i2c_unregister_device(state->edid_i2c_client);
 err_entity:
media_entity_cleanup(>entity);
 err_hdl:
@@ -1211,9 +1198,8 @@ static int ad9389b_remove(struct i2c_client *client)
ad9389b_s_stream(sd, false);
ad9389b_s_audio_stream(sd, false);
ad9389b_init_setup(sd);
-   cancel_delayed_work(>edid_handler);
+   cancel_delayed_work_sync(>edid_handler);
i2c_unregister_device(state->edid_i2c_client);
-   destroy_workqueue(state->work_queue);
v4l2_device_unregister_subdev(sd);
media_entity_cleanup(>entity);
v4l2_ctrl_handler_free(sd->ctrl_handler);
--
2.1.4

--
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 v3 9/9] [media] vivid: Local optimization

[Ricardo Ribalda Delgado]

Hi

On Sat, Jul 16, 2016 at 12:41 PM, Ricardo Ribalda Delgado
 wrote:

> -   cr = clamp(cr, 16 << 4, 240 << 4);
> +   y = clamp(y >> 4, 16, 235);
> +   cb = clamp(cb >> 4, 16, 240);
> +   cr = clamp(cr > 4, 16, 240);
This line is obviously wrong, sorry about that.

I wait for some more comments and add it to v4.

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

Re: [PATCH] [media] ad9389b: Remove deprecated create_singlethread_workqueue

[kbuild test robot]

Hi,

[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.7-rc7 next-20160715]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Bhaktipriya-Shridhar/ad9389b-Remove-deprecated-create_singlethread_workqueue/20160716-174501
base:   git://linuxtv.org/media_tree.git master
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All warnings (new ones prefixed by >>):

   drivers/media/i2c/ad9389b.c: In function 'ad9389b_probe':
>> drivers/media/i2c/ad9389b.c:1179:1: warning: label 'err_unreg' defined but 
>> not used [-Wunused-label]
err_unreg:
^

vim +/err_unreg +1179 drivers/media/i2c/ad9389b.c

117a55b6 Hans Verkuil 2012-07-18  1163  if (state->edid_i2c_client == 
NULL) {
117a55b6 Hans Verkuil 2012-07-18  1164  v4l2_err(sd, "failed to 
register edid i2c client\n");
6ec735df Wei Yongjun  2013-05-13  1165  err = -ENOMEM;
117a55b6 Hans Verkuil 2012-07-18  1166  goto err_entity;
117a55b6 Hans Verkuil 2012-07-18  1167  }
117a55b6 Hans Verkuil 2012-07-18  1168  
117a55b6 Hans Verkuil 2012-07-18  1169  
INIT_DELAYED_WORK(>edid_handler, ad9389b_edid_handler);
117a55b6 Hans Verkuil 2012-07-18  1170  state->dv_timings = dv1080p60;
117a55b6 Hans Verkuil 2012-07-18  1171  
117a55b6 Hans Verkuil 2012-07-18  1172  ad9389b_init_setup(sd);
117a55b6 Hans Verkuil 2012-07-18  1173  ad9389b_set_isr(sd, true);
117a55b6 Hans Verkuil 2012-07-18  1174  
117a55b6 Hans Verkuil 2012-07-18  1175  v4l2_info(sd, "%s found @ 0x%x 
(%s)\n", client->name,
117a55b6 Hans Verkuil 2012-07-18  1176client->addr << 1, 
client->adapter->name);
117a55b6 Hans Verkuil 2012-07-18  1177  return 0;
117a55b6 Hans Verkuil 2012-07-18  1178  
117a55b6 Hans Verkuil 2012-07-18 @1179  err_unreg:
117a55b6 Hans Verkuil 2012-07-18  1180  
i2c_unregister_device(state->edid_i2c_client);
117a55b6 Hans Verkuil 2012-07-18  1181  err_entity:
117a55b6 Hans Verkuil 2012-07-18  1182  
media_entity_cleanup(>entity);
117a55b6 Hans Verkuil 2012-07-18  1183  err_hdl:
117a55b6 Hans Verkuil 2012-07-18  1184  
v4l2_ctrl_handler_free(>hdl);
117a55b6 Hans Verkuil 2012-07-18  1185  return err;
117a55b6 Hans Verkuil 2012-07-18  1186  }
117a55b6 Hans Verkuil 2012-07-18  1187  

:: The code at line 1179 was first introduced by commit
:: 117a55b69d36a19028d1c59a737ad1246a0a75ad [media] ad9389b: driver for the 
Analog Devices AD9389B video encoder

:: TO: Hans Verkuil <hans.verk...@cisco.com>
:: CC: Mauro Carvalho Chehab <mche...@redhat.com>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH v3 8/9] [media] vivid: Fix YUV555 and YUV565 handling

[Ricardo Ribalda Delgado]

precalculate_color() had a optimization that avoided duplicated
conversion for YUV formats. This optimization did not take into
consideration YUV444, YUV555, YUV565 or limited range quantization.

This patch keeps the optimization, but fixes the wrong handling.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index e91bf3cbaab9..1c862465e335 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -797,6 +797,8 @@ static void precalculate_color(struct tpg_data *tpg, int k)
int r = tpg_colors[col].r;
int g = tpg_colors[col].g;
int b = tpg_colors[col].b;
+   int y, cb, cr;
+   bool ycbbr_valid = false;
 
if (k == TPG_COLOR_TEXTBG) {
col = tpg_get_textbg_color(tpg);
@@ -873,7 +875,6 @@ static void precalculate_color(struct tpg_data *tpg, int k)
 tpg->saturation != 128 || tpg->hue) &&
tpg->color_enc != TGP_COLOR_ENC_LUMA) {
/* Implement these operations */
-   int y, cb, cr;
int tmp_cb, tmp_cr;
 
/* First convert to YCbCr */
@@ -890,13 +891,10 @@ static void precalculate_color(struct tpg_data *tpg, int 
k)
 
cb = (128 << 4) + (tmp_cb * tpg->contrast * tpg->saturation) / 
(128 * 128);
cr = (128 << 4) + (tmp_cr * tpg->contrast * tpg->saturation) / 
(128 * 128);
-   if (tpg->color_enc == TGP_COLOR_ENC_YUV) {
-   tpg->colors[k][0] = clamp(y >> 4, 1, 254);
-   tpg->colors[k][1] = clamp(cb >> 4, 1, 254);
-   tpg->colors[k][2] = clamp(cr >> 4, 1, 254);
-   return;
-   }
-   ycbcr_to_color(tpg, y, cb, cr, , , );
+   if (tpg->color_enc == TGP_COLOR_ENC_YUV)
+   ycbbr_valid = true;
+   else
+   ycbcr_to_color(tpg, y, cb, cr, , , );
} else if ((tpg->brightness != 128 || tpg->contrast != 128) &&
   tpg->color_enc == TGP_COLOR_ENC_LUMA) {
r = (16 << 4) + ((r - (16 << 4)) * tpg->contrast) / 128;
@@ -917,9 +915,8 @@ static void precalculate_color(struct tpg_data *tpg, int k)
case TGP_COLOR_ENC_YUV:
{
/* Convert to YCbCr */
-   int y, cb, cr;
-
-   color_to_ycbcr(tpg, r, g, b, , , );
+   if (!ycbbr_valid)
+   color_to_ycbcr(tpg, r, g, b, , , );
 
if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) {
y = clamp(y, 16 << 4, 235 << 4);
-- 
2.8.1

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

[PATCH v3 6/9] [media] vivid: Rename variable

[Ricardo Ribalda Delgado]

r_y and g_u now also contain the H and V components on the HSV formats.
Rename the variables to reflect this.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 209 +-
 1 file changed, 105 insertions(+), 104 deletions(-)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index 53e512f5a6b6..ba3fe65ceb98 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -1014,7 +1014,7 @@ static void gen_twopix(struct tpg_data *tpg,
 {
unsigned offset = odd * tpg->twopixelsize[0] / 2;
u8 alpha = tpg->alpha_component;
-   u8 r_y, g_u, b_v;
+   u8 r_y_h, g_u_s, b_v;
 
if (tpg->alpha_red_only && color != TPG_COLOR_CSC_RED &&
   color != TPG_COLOR_100_RED &&
@@ -1022,161 +1022,161 @@ static void gen_twopix(struct tpg_data *tpg,
alpha = 0;
if (color == TPG_COLOR_RANDOM)
precalculate_color(tpg, color);
-   r_y = tpg->colors[color][0]; /* R or precalculated Y, H */
-   g_u = tpg->colors[color][1]; /* G or precalculated U, V */
+   r_y_h = tpg->colors[color][0]; /* R or precalculated Y, H */
+   g_u_s = tpg->colors[color][1]; /* G or precalculated U, V */
b_v = tpg->colors[color][2]; /* B or precalculated V */
 
switch (tpg->fourcc) {
case V4L2_PIX_FMT_GREY:
-   buf[0][offset] = r_y;
+   buf[0][offset] = r_y_h;
break;
case V4L2_PIX_FMT_Y16:
/*
-* Ideally both bytes should be set to r_y, but then you won't
+* Ideally both bytes should be set to r_y_h, but then you won't
 * be able to detect endian problems. So keep it 0 except for
-* the corner case where r_y is 0xff so white really will be
+* the corner case where r_y_h is 0xff so white really will be
 * white (0x).
 */
-   buf[0][offset] = r_y == 0xff ? r_y : 0;
-   buf[0][offset+1] = r_y;
+   buf[0][offset] = r_y_h == 0xff ? r_y_h : 0;
+   buf[0][offset+1] = r_y_h;
break;
case V4L2_PIX_FMT_Y16_BE:
/* See comment for V4L2_PIX_FMT_Y16 above */
-   buf[0][offset] = r_y;
-   buf[0][offset+1] = r_y == 0xff ? r_y : 0;
+   buf[0][offset] = r_y_h;
+   buf[0][offset+1] = r_y_h == 0xff ? r_y_h : 0;
break;
case V4L2_PIX_FMT_YUV422M:
case V4L2_PIX_FMT_YUV422P:
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YUV420M:
-   buf[0][offset] = r_y;
+   buf[0][offset] = r_y_h;
if (odd) {
-   buf[1][0] = (buf[1][0] + g_u) / 2;
+   buf[1][0] = (buf[1][0] + g_u_s) / 2;
buf[2][0] = (buf[2][0] + b_v) / 2;
buf[1][1] = buf[1][0];
buf[2][1] = buf[2][0];
break;
}
-   buf[1][0] = g_u;
+   buf[1][0] = g_u_s;
buf[2][0] = b_v;
break;
case V4L2_PIX_FMT_YVU422M:
case V4L2_PIX_FMT_YVU420:
case V4L2_PIX_FMT_YVU420M:
-   buf[0][offset] = r_y;
+   buf[0][offset] = r_y_h;
if (odd) {
buf[1][0] = (buf[1][0] + b_v) / 2;
-   buf[2][0] = (buf[2][0] + g_u) / 2;
+   buf[2][0] = (buf[2][0] + g_u_s) / 2;
buf[1][1] = buf[1][0];
buf[2][1] = buf[2][0];
break;
}
buf[1][0] = b_v;
-   buf[2][0] = g_u;
+   buf[2][0] = g_u_s;
break;
 
case V4L2_PIX_FMT_NV12:
case V4L2_PIX_FMT_NV12M:
case V4L2_PIX_FMT_NV16:
case V4L2_PIX_FMT_NV16M:
-   buf[0][offset] = r_y;
+   buf[0][offset] = r_y_h;
if (odd) {
-   buf[1][0] = (buf[1][0] + g_u) / 2;
+   buf[1][0] = (buf[1][0] + g_u_s) / 2;
buf[1][1] = (buf[1][1] + b_v) / 2;
break;
}
-   buf[1][0] = g_u;
+   buf[1][0] = g_u_s;
buf[1][1] = b_v;
break;
case V4L2_PIX_FMT_NV21:
case V4L2_PIX_FMT_NV21M:
case V4L2_PIX_FMT_NV61:
case V4L2_PIX_FMT_NV61M:
-   buf[0][offset] = r_y;
+   buf[0][offset] = r_y_h;
if (odd) {
buf[1][0] = (buf[1][0] + b_v) / 2;
-   buf[1][1] = (buf[1][1] + g_u) / 2;
+   buf[1][1] = (buf[1][1] + g_u_s) / 2;
   

[PATCH v3 2/9] [media] Documentation: Add HSV format

[Ricardo Ribalda Delgado]

Describe the HSV formats

Signed-off-by: Ricardo Ribalda Delgado 
---
 Documentation/media/uapi/v4l/hsv-formats.rst   |  19 +++
 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 158 +
 Documentation/media/uapi/v4l/pixfmt.rst|   1 +
 Documentation/media/uapi/v4l/v4l2.rst  |   5 +
 4 files changed, 183 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst

diff --git a/Documentation/media/uapi/v4l/hsv-formats.rst 
b/Documentation/media/uapi/v4l/hsv-formats.rst
new file mode 100644
index ..f0f2615eaa95
--- /dev/null
+++ b/Documentation/media/uapi/v4l/hsv-formats.rst
@@ -0,0 +1,19 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _hsv-formats:
+
+***
+HSV Formats
+***
+
+These formats store the color information of the image
+in a geometrical representation. The colors are mapped into a
+cylinder, where the angle is the HUE, the height is the VALUE
+and the distance to the center is the SATURATION. This is a very
+useful format for image segmentation algorithms.
+
+
+.. toctree::
+:maxdepth: 1
+
+pixfmt-packed-hsv
diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst 
b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
new file mode 100644
index ..60ac821e309d
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
@@ -0,0 +1,158 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _packed-hsv:
+
+**
+Packed HSV formats
+**
+
+*man Packed HSV formats(2)*
+
+Packed HSV formats
+
+
+Description
+===
+
+The *hue* (h) is measured in degrees, one LSB represents two degrees.
+The *saturation* (s) and the *value* (v) are measured in percentage of the
+cylinder: 0 being the smallest value and 255 the maximum.
+
+
+The values are packed in 24 or 32 bit formats.
+
+
+.. flat-table:: Packed HSV Image Formats
+:header-rows:  2
+:stub-columns: 0
+
+-  .. row 1
+
+   -  Identifier
+   -  Code
+   -
+   -  :cspan:`7` Byte 0 in memory
+   -
+   -  :cspan:`7` Byte 1
+   -
+   -  :cspan:`7` Byte 2
+   -
+   -  :cspan:`7` Byte 3
+
+-  .. row 2
+
+   -
+   -
+   -  Bit
+   -  7
+   -  6
+   -  5
+   -  4
+   -  3
+   -  2
+   -  1
+   -  0
+   -
+   -  7
+   -  6
+   -  5
+   -  4
+   -  3
+   -  2
+   -  1
+   -  0
+   -
+   -  7
+   -  6
+   -  5
+   -  4
+   -  3
+   -  2
+   -  1
+   -  0
+   -
+   -  7
+   -  6
+   -  5
+   -  4
+   -  3
+   -  2
+   -  1
+   -  0
+
+-  .. _V4L2-PIX-FMT-HSV32:
+
+   -  ``V4L2_PIX_FMT_HSV32``
+   -  'HSV4'
+   -
+   -  -
+   -  -
+   -  -
+   -  -
+   -  -
+   -  -
+   -  -
+   -  -
+   -
+   -  h\ :sub:`7`
+   -  h\ :sub:`6`
+   -  h\ :sub:`5`
+   -  h\ :sub:`4`
+   -  h\ :sub:`3`
+   -  h\ :sub:`2`
+   -  h\ :sub:`1`
+   -  h\ :sub:`0`
+   -
+   -  s\ :sub:`7`
+   -  s\ :sub:`6`
+   -  s\ :sub:`5`
+   -  s\ :sub:`4`
+   -  s\ :sub:`3`
+   -  s\ :sub:`2`
+   -  s\ :sub:`1`
+   -  s\ :sub:`0`
+   -
+   -  v\ :sub:`7`
+   -  v\ :sub:`6`
+   -  v\ :sub:`5`
+   -  v\ :sub:`4`
+   -  v\ :sub:`3`
+   -  v\ :sub:`2`
+   -  v\ :sub:`1`
+   -  v\ :sub:`0`
+
+-  .. _V4L2-PIX-FMT-HSV24:
+
+   -  ``V4L2_PIX_FMT_HSV24``
+   -  'HSV3'
+   -
+   -  h\ :sub:`7`
+   -  h\ :sub:`6`
+   -  h\ :sub:`5`
+   -  h\ :sub:`4`
+   -  h\ :sub:`3`
+   -  h\ :sub:`2`
+   -  h\ :sub:`1`
+   -  h\ :sub:`0`
+   -
+   -  s\ :sub:`7`
+   -  s\ :sub:`6`
+   -  s\ :sub:`5`
+   -  s\ :sub:`4`
+   -  s\ :sub:`3`
+   -  s\ :sub:`2`
+   -  s\ :sub:`1`
+   -  s\ :sub:`0`
+   -
+   -  v\ :sub:`7`
+   -  v\ :sub:`6`
+   -  v\ :sub:`5`
+   -  v\ :sub:`4`
+   -  v\ :sub:`3`
+   -  v\ :sub:`2`
+   -  v\ :sub:`1`
+   -  v\ :sub:`0`
+   -
+   -
+
+Bit 7 is the most significant bit.
diff --git a/Documentation/media/uapi/v4l/pixfmt.rst 
b/Documentation/media/uapi/v4l/pixfmt.rst
index 81222a99f7ce..1d2270422345 100644
--- a/Documentation/media/uapi/v4l/pixfmt.rst
+++ b/Documentation/media/uapi/v4l/pixfmt.rst
@@ -29,6 +29,7 @@ see also :ref:`VIDIOC_G_FBUF `.)
 pixfmt-indexed
 pixfmt-rgb
 yuv-formats
+hsv-formats
 depth-formats
 pixfmt-013
 sdr-formats
diff --git a/Documentation/media/uapi/v4l/v4l2.rst 
b/Documentation/media/uapi/v4l/v4l2.rst
index c0859ebc88ee..6d23bc987f51 100644
--- a/Documentation/media/uapi/v4l/v4l2.rst
+++ b/Documentation/media/uapi/v4l/v4l2.rst
@@ -85,6 +85,11 @@ part can be used and distributed without restrictions.
 Revision History
 

[PATCH v3 9/9] [media] vivid: Local optimization

[Ricardo Ribalda Delgado]

Avoid duplicated data shifts when possible.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index 1c862465e335..2c23c458b1a6 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -919,13 +919,14 @@ static void precalculate_color(struct tpg_data *tpg, int 
k)
color_to_ycbcr(tpg, r, g, b, , , );
 
if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) {
-   y = clamp(y, 16 << 4, 235 << 4);
-   cb = clamp(cb, 16 << 4, 240 << 4);
-   cr = clamp(cr, 16 << 4, 240 << 4);
+   y = clamp(y >> 4, 16, 235);
+   cb = clamp(cb >> 4, 16, 240);
+   cr = clamp(cr > 4, 16, 240);
+   } else {
+   y = clamp(y >> 4, 1, 254);
+   cb = clamp(cb >> 4, 1, 254);
+   cr = clamp(cr >> 4, 1, 254);
}
-   y = clamp(y >> 4, 1, 254);
-   cb = clamp(cb >> 4, 1, 254);
-   cr = clamp(cr >> 4, 1, 254);
switch (tpg->fourcc) {
case V4L2_PIX_FMT_YUV444:
y >>= 4;
-- 
2.8.1

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

[PATCH v3 3/9] [media] Documentation: Add Ricardo Ribalda

[Ricardo Ribalda Delgado]

My initials were on the Changelog, but there was no link to my name.

Signed-off-by: Ricardo Ribalda Delgado 
---
 Documentation/media/uapi/v4l/v4l2.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/media/uapi/v4l/v4l2.rst 
b/Documentation/media/uapi/v4l/v4l2.rst
index 6d23bc987f51..330674a0f553 100644
--- a/Documentation/media/uapi/v4l/v4l2.rst
+++ b/Documentation/media/uapi/v4l/v4l2.rst
@@ -64,6 +64,10 @@ Authors, in alphabetical order:
 
   - SDR API.
 
+- Ribalda, Ricardo
+
+  - Introduce HSV formats and other minor changes.
+
 - Rubli, Martin
 
   - Designed and documented the VIDIOC_ENUM_FRAMESIZES and 
VIDIOC_ENUM_FRAMEINTERVALS ioctls.
-- 
2.8.1

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

[PATCH v3 0/9] Add HSV format

[Ricardo Ribalda Delgado]

HSV formats are extremely useful for image segmentation. This set of
patches makes v4l2 aware of this kind of formats.

Vivid changes have been divided to ease the reviewing process.

We are working on patches for Gstreamer and OpenCV that will make use
of these formats.

We still need to decide if and how we will support HUE range 0-255


Changelog:
v3:  Fix wrong handling of some YUV formats when brightness != 128

Suggested by Laurent Pinchart 
-Remove unneeded empty lines on .rst file
Thanks!

Suggested by Hans Verkuil 
-Rebase over master and docs-next
-Introduce TPG_COLOR_ENC_LUMA for gray formats
-CodeStyle
Thanks!

v2: Suggested by Mauro Carvalho Chehab ,
-Rebase on top of docs-next (port documentation to .rst)

Ricardo Ribalda Delgado (9):
  [media] videodev2.h Add HSV formats
  [media] Documentation: Add HSV format
  [media] Documentation: Add Ricardo Ribalda
  [media] vivid: code refactor for color encoding
  [media] vivid: Add support for HSV formats
  [media] vivid: Rename variable
  [media] vivid: Introduce TPG_COLOR_ENC_LUMA
  [media] vivid: Fix YUV555 and YUV565 handling
  [media] vivid: Local optimization

 Documentation/media/uapi/v4l/hsv-formats.rst   |  19 +
 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 158 
 Documentation/media/uapi/v4l/pixfmt.rst|   1 +
 Documentation/media/uapi/v4l/v4l2.rst  |   9 +
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c  | 399 +
 drivers/media/platform/vivid/vivid-core.h  |   2 +-
 drivers/media/platform/vivid/vivid-vid-common.c|  66 ++--
 drivers/media/v4l2-core/v4l2-ioctl.c   |   2 +
 include/media/v4l2-tpg.h   |   9 +-
 include/uapi/linux/videodev2.h |   4 +
 10 files changed, 499 insertions(+), 170 deletions(-)
 create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst

-- 
2.8.1

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

[PATCH v3 7/9] [media] vivid: Introduce TPG_COLOR_ENC_LUMA

[Ricardo Ribalda Delgado]

Simplifies handling of Gray formats.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c   | 26 +++--
 drivers/media/platform/vivid/vivid-vid-common.c |  6 +++---
 include/media/v4l2-tpg.h|  1 +
 3 files changed, 24 insertions(+), 9 deletions(-)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index ba3fe65ceb98..e91bf3cbaab9 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -234,10 +234,12 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_XBGR32:
case V4L2_PIX_FMT_ARGB32:
case V4L2_PIX_FMT_ABGR32:
+   tpg->color_enc = TGP_COLOR_ENC_RGB;
+   break;
case V4L2_PIX_FMT_GREY:
case V4L2_PIX_FMT_Y16:
case V4L2_PIX_FMT_Y16_BE:
-   tpg->color_enc = TGP_COLOR_ENC_RGB;
+   tpg->color_enc = TGP_COLOR_ENC_LUMA;
break;
case V4L2_PIX_FMT_YUV444:
case V4L2_PIX_FMT_YUV555:
@@ -825,9 +827,9 @@ static void precalculate_color(struct tpg_data *tpg, int k)
g <<= 4;
b <<= 4;
}
-   if (tpg->qual == TPG_QUAL_GRAY || tpg->fourcc == V4L2_PIX_FMT_GREY ||
-   tpg->fourcc == V4L2_PIX_FMT_Y16 ||
-   tpg->fourcc == V4L2_PIX_FMT_Y16_BE) {
+
+   if (tpg->qual == TPG_QUAL_GRAY ||
+   tpg->color_enc ==  TGP_COLOR_ENC_LUMA) {
/* Rec. 709 Luma function */
/* (0.2126, 0.7152, 0.0722) * (255 * 256) */
r = g = b = (13879 * r + 46688 * g + 4713 * b) >> 16;
@@ -867,8 +869,9 @@ static void precalculate_color(struct tpg_data *tpg, int k)
b = (b - (16 << 4)) * 255 / 219;
}
 
-   if (tpg->brightness != 128 || tpg->contrast != 128 ||
-   tpg->saturation != 128 || tpg->hue) {
+   if ((tpg->brightness != 128 || tpg->contrast != 128 ||
+tpg->saturation != 128 || tpg->hue) &&
+   tpg->color_enc != TGP_COLOR_ENC_LUMA) {
/* Implement these operations */
int y, cb, cr;
int tmp_cb, tmp_cr;
@@ -894,6 +897,10 @@ static void precalculate_color(struct tpg_data *tpg, int k)
return;
}
ycbcr_to_color(tpg, y, cb, cr, , , );
+   } else if ((tpg->brightness != 128 || tpg->contrast != 128) &&
+  tpg->color_enc == TGP_COLOR_ENC_LUMA) {
+   r = (16 << 4) + ((r - (16 << 4)) * tpg->contrast) / 128;
+   r += (tpg->brightness << 4) - (128 << 4);
}
 
switch (tpg->color_enc) {
@@ -944,6 +951,11 @@ static void precalculate_color(struct tpg_data *tpg, int k)
tpg->colors[k][2] = cr;
break;
}
+   case TGP_COLOR_ENC_LUMA:
+   {
+   tpg->colors[k][0] = r >> 4;
+   break;
+   }
case TGP_COLOR_ENC_RGB:
{
if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) {
@@ -1985,6 +1997,8 @@ static const char *tpg_color_enc_str(enum tgp_color_enc
return "HSV";
case TGP_COLOR_ENC_YUV:
return "YCbCr";
+   case TGP_COLOR_ENC_LUMA:
+   return "Luma";
case TGP_COLOR_ENC_RGB:
default:
return "RGB";
diff --git a/drivers/media/platform/vivid/vivid-vid-common.c 
b/drivers/media/platform/vivid/vivid-vid-common.c
index 869e26ea7cf5..b78bca4c2f16 100644
--- a/drivers/media/platform/vivid/vivid-vid-common.c
+++ b/drivers/media/platform/vivid/vivid-vid-common.c
@@ -184,7 +184,7 @@ struct vivid_fmt vivid_formats[] = {
.fourcc   = V4L2_PIX_FMT_GREY,
.vdownsampling = { 1 },
.bit_depth = { 8 },
-   .color_enc = TGP_COLOR_ENC_YUV,
+   .color_enc = TGP_COLOR_ENC_LUMA,
.planes   = 1,
.buffers = 1,
},
@@ -192,7 +192,7 @@ struct vivid_fmt vivid_formats[] = {
.fourcc   = V4L2_PIX_FMT_Y16,
.vdownsampling = { 1 },
.bit_depth = { 16 },
-   .color_enc = TGP_COLOR_ENC_YUV,
+   .color_enc = TGP_COLOR_ENC_LUMA,
.planes   = 1,
.buffers = 1,
},
@@ -200,7 +200,7 @@ struct vivid_fmt vivid_formats[] = {
.fourcc   = V4L2_PIX_FMT_Y16_BE,
.vdownsampling = { 1 },
.bit_depth = { 16 },
-   .color_enc = TGP_COLOR_ENC_YUV,
+   .color_enc = TGP_COLOR_ENC_LUMA,
.planes   = 1,
.buffers = 1,
},
diff --git a/include/media/v4l2-tpg.h b/include/media/v4l2-tpg.h
index 0f632ec619aa..d2487c12657d 100644
--- a/include/media/v4l2-tpg.h
+++ b/include/media/v4l2-tpg.h
@@ -91,6 +91,7 @@ enum tgp_color_enc {
 

[PATCH v3 1/9] [media] videodev2.h Add HSV formats

[Ricardo Ribalda Delgado]

These formats store the color information of the image
in a geometrical representation. The colors are mapped into a
cylinder, where the angle is the HUE, the height is the VALUE
and the distance to the center is the SATURATION. This is a very
useful format for image segmentation algorithms.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 2 ++
 include/uapi/linux/videodev2.h   | 4 
 2 files changed, 6 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index f899bf1c5fc0..54670cd59212 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1238,6 +1238,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_TM6000:   descr = "A/V + VBI Mux Packet"; break;
case V4L2_PIX_FMT_CIT_YYVYUY:   descr = "GSPCA CIT YYVYUY"; break;
case V4L2_PIX_FMT_KONICA420:descr = "GSPCA KONICA420"; break;
+   case V4L2_PIX_FMT_HSV24:descr = "24-bit HSV 8-8-8"; break;
+   case V4L2_PIX_FMT_HSV32:descr = "32-bit XHSV 8-8-8-8"; break;
case V4L2_SDR_FMT_CU8:  descr = "Complex U8"; break;
case V4L2_SDR_FMT_CU16LE:   descr = "Complex U16LE"; break;
case V4L2_SDR_FMT_CS8:  descr = "Complex S8"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 724f43e69d03..c7fb760386cf 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -580,6 +580,10 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12  RGRG.. 
GBGB.. */
 #define V4L2_PIX_FMT_SBGGR16 v4l2_fourcc('B', 'Y', 'R', '2') /* 16  BGBG.. 
GRGR.. */
 
+/* HSV formats */
+#define V4L2_PIX_FMT_HSV24 v4l2_fourcc('H', 'S', 'V', '3')
+#define V4L2_PIX_FMT_HSV32 v4l2_fourcc('H', 'S', 'V', '4')
+
 /* compressed formats */
 #define V4L2_PIX_FMT_MJPEGv4l2_fourcc('M', 'J', 'P', 'G') /* Motion-JPEG   
*/
 #define V4L2_PIX_FMT_JPEG v4l2_fourcc('J', 'P', 'E', 'G') /* JFIF JPEG 
*/
-- 
2.8.1

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

[PATCH v3 4/9] [media] vivid: code refactor for color encoding

[Ricardo Ribalda Delgado]

Replace is_yuv with color_enc Which can be used by other
color encodings such us HSV.

This change should ease the review of the following patches.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c   | 49 +++
 drivers/media/platform/vivid/vivid-core.h   |  2 +-
 drivers/media/platform/vivid/vivid-vid-common.c | 52 -
 include/media/v4l2-tpg.h|  7 +++-
 4 files changed, 66 insertions(+), 44 deletions(-)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index 3ec3cebe62b9..e8d2bf388597 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -237,13 +237,13 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_GREY:
case V4L2_PIX_FMT_Y16:
case V4L2_PIX_FMT_Y16_BE:
-   tpg->is_yuv = false;
+   tpg->color_enc = TGP_COLOR_ENC_RGB;
break;
case V4L2_PIX_FMT_YUV444:
case V4L2_PIX_FMT_YUV555:
case V4L2_PIX_FMT_YUV565:
case V4L2_PIX_FMT_YUV32:
-   tpg->is_yuv = true;
+   tpg->color_enc = TGP_COLOR_ENC_YUV;
break;
case V4L2_PIX_FMT_YUV420M:
case V4L2_PIX_FMT_YVU420M:
@@ -256,7 +256,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->hdownsampling[1] = 2;
tpg->hdownsampling[2] = 2;
tpg->planes = 3;
-   tpg->is_yuv = true;
+   tpg->color_enc = TGP_COLOR_ENC_YUV;
break;
case V4L2_PIX_FMT_YUV422M:
case V4L2_PIX_FMT_YVU422M:
@@ -268,7 +268,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->hdownsampling[1] = 2;
tpg->hdownsampling[2] = 2;
tpg->planes = 3;
-   tpg->is_yuv = true;
+   tpg->color_enc = TGP_COLOR_ENC_YUV;
break;
case V4L2_PIX_FMT_NV16M:
case V4L2_PIX_FMT_NV61M:
@@ -280,7 +280,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->hdownsampling[1] = 1;
tpg->hmask[1] = ~1;
tpg->planes = 2;
-   tpg->is_yuv = true;
+   tpg->color_enc = TGP_COLOR_ENC_YUV;
break;
case V4L2_PIX_FMT_NV12M:
case V4L2_PIX_FMT_NV21M:
@@ -292,7 +292,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->hdownsampling[1] = 1;
tpg->hmask[1] = ~1;
tpg->planes = 2;
-   tpg->is_yuv = true;
+   tpg->color_enc = TGP_COLOR_ENC_YUV;
break;
case V4L2_PIX_FMT_YUV444M:
case V4L2_PIX_FMT_YVU444M:
@@ -302,21 +302,21 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->vdownsampling[2] = 1;
tpg->hdownsampling[1] = 1;
tpg->hdownsampling[2] = 1;
-   tpg->is_yuv = true;
+   tpg->color_enc = TGP_COLOR_ENC_YUV;
break;
case V4L2_PIX_FMT_NV24:
case V4L2_PIX_FMT_NV42:
tpg->vdownsampling[1] = 1;
tpg->hdownsampling[1] = 1;
tpg->planes = 2;
-   tpg->is_yuv = true;
+   tpg->color_enc = TGP_COLOR_ENC_YUV;
break;
case V4L2_PIX_FMT_YUYV:
case V4L2_PIX_FMT_UYVY:
case V4L2_PIX_FMT_YVYU:
case V4L2_PIX_FMT_VYUY:
tpg->hmask[0] = ~1;
-   tpg->is_yuv = true;
+   tpg->color_enc = TGP_COLOR_ENC_YUV;
break;
default:
return false;
@@ -777,7 +777,8 @@ static void precalculate_color(struct tpg_data *tpg, int k)
 * Remember that r, g and b are still in the 0 - 0xff0 range.
 */
if (tpg->real_rgb_range == V4L2_DV_RGB_RANGE_LIMITED &&
-   tpg->rgb_range == V4L2_DV_RGB_RANGE_FULL && !tpg->is_yuv) {
+   tpg->rgb_range == V4L2_DV_RGB_RANGE_FULL &&
+   tpg->color_enc == TGP_COLOR_ENC_RGB) {
/*
 * Convert from full range (which is what r, g and b are)
 * to limited range (which is the 'real' RGB range), which
@@ -787,7 +788,9 @@ static void precalculate_color(struct tpg_data *tpg, int k)
g = (g * 219) / 255 + (16 << 4);
b = (b * 219) / 255 + (16 << 4);
} else if (tpg->real_rgb_range != V4L2_DV_RGB_RANGE_LIMITED &&
-  tpg->rgb_range == V4L2_DV_RGB_RANGE_LIMITED && !tpg->is_yuv) 
{
+  tpg->rgb_range == V4L2_DV_RGB_RANGE_LIMITED &&
+  tpg->color_enc == TGP_COLOR_ENC_RGB) {
+
/*
 * Clamp r, g and b to the limited range and convert to full
 * range since that's what we deliver.
@@ -820,7 +823,7 @@ 

[PATCH v3 5/9] [media] vivid: Add support for HSV formats

[Ricardo Ribalda Delgado]

This patch adds support for V4L2_PIX_FMT_HSV24 and V4L2_PIX_FMT_HSV32.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c   | 93 +++--
 drivers/media/platform/vivid/vivid-vid-common.c | 14 
 include/media/v4l2-tpg.h|  1 +
 3 files changed, 104 insertions(+), 4 deletions(-)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c 
b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index e8d2bf388597..53e512f5a6b6 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -318,6 +318,10 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg->hmask[0] = ~1;
tpg->color_enc = TGP_COLOR_ENC_YUV;
break;
+   case V4L2_PIX_FMT_HSV24:
+   case V4L2_PIX_FMT_HSV32:
+   tpg->color_enc = TGP_COLOR_ENC_HSV;
+   break;
default:
return false;
}
@@ -351,6 +355,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
break;
case V4L2_PIX_FMT_RGB24:
case V4L2_PIX_FMT_BGR24:
+   case V4L2_PIX_FMT_HSV24:
tpg->twopixelsize[0] = 2 * 3;
break;
case V4L2_PIX_FMT_BGR666:
@@ -361,6 +366,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_ARGB32:
case V4L2_PIX_FMT_ABGR32:
case V4L2_PIX_FMT_YUV32:
+   case V4L2_PIX_FMT_HSV32:
tpg->twopixelsize[0] = 2 * 4;
break;
case V4L2_PIX_FMT_NV12:
@@ -490,6 +496,64 @@ static inline int linear_to_rec709(int v)
return tpg_linear_to_rec709[v];
 }
 
+static void color_to_hsv(struct tpg_data *tpg, int r, int g, int b,
+  int *h, int *s, int *v)
+{
+   int max_rgb, min_rgb, diff_rgb;
+   int aux;
+   int third;
+
+   r >>= 4;
+   g >>= 4;
+   b >>= 4;
+
+   /* Value */
+   max_rgb = max3(r, g, b);
+   *v = max_rgb;
+   if (!max_rgb) {
+   *h = 0;
+   *s = 0;
+   return;
+   }
+
+   /* Saturation */
+   min_rgb = min3(r, g, b);
+   diff_rgb = max_rgb - min_rgb;
+   aux = 255 * diff_rgb;
+   aux += max_rgb / 2;
+   aux /= max_rgb;
+   *s = aux;
+   if (!aux) {
+   *h = 0;
+   return;
+   }
+
+   /* Hue */
+   if (max_rgb == r) {
+   aux =  g - b;
+   third = 0;
+   } else if (max_rgb == g) {
+   aux =  b - r;
+   third = 60;
+   } else {
+   aux =  r - g;
+   third = 120;
+   }
+
+   aux *= 30;
+   aux += diff_rgb / 2;
+   aux /= diff_rgb;
+   aux += third;
+
+   /* Clamp Hue */
+   if (aux < 0)
+   aux += 180;
+   else if (aux > 180)
+   aux -= 180;
+   *h = aux;
+
+}
+
 static void rgb2ycbcr(const int m[3][3], int r, int g, int b,
int y_offset, int *y, int *cb, int *cr)
 {
@@ -832,7 +896,19 @@ static void precalculate_color(struct tpg_data *tpg, int k)
ycbcr_to_color(tpg, y, cb, cr, , , );
}
 
-   if (tpg->color_enc == TGP_COLOR_ENC_YUV) {
+   switch (tpg->color_enc) {
+   case TGP_COLOR_ENC_HSV:
+   {
+   int h, s, v;
+
+   color_to_hsv(tpg, r, g, b, , , );
+   tpg->colors[k][0] = h;
+   tpg->colors[k][1] = s;
+   tpg->colors[k][2] = v;
+   break;
+   }
+   case TGP_COLOR_ENC_YUV:
+   {
/* Convert to YCbCr */
int y, cb, cr;
 
@@ -866,7 +942,10 @@ static void precalculate_color(struct tpg_data *tpg, int k)
tpg->colors[k][0] = y;
tpg->colors[k][1] = cb;
tpg->colors[k][2] = cr;
-   } else {
+   break;
+   }
+   case TGP_COLOR_ENC_RGB:
+   {
if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) {
r = (r * 219) / 255 + (16 << 4);
g = (g * 219) / 255 + (16 << 4);
@@ -916,6 +995,8 @@ static void precalculate_color(struct tpg_data *tpg, int k)
tpg->colors[k][0] = r;
tpg->colors[k][1] = g;
tpg->colors[k][2] = b;
+   break;
+   }
}
 }
 
@@ -941,8 +1022,8 @@ static void gen_twopix(struct tpg_data *tpg,
alpha = 0;
if (color == TPG_COLOR_RANDOM)
precalculate_color(tpg, color);
-   r_y = tpg->colors[color][0]; /* R or precalculated Y */
-   g_u = tpg->colors[color][1]; /* G or precalculated U */
+   r_y = tpg->colors[color][0]; /* R or precalculated Y, H */
+   g_u = tpg->colors[color][1]; /* G or precalculated U, V */
b_v = tpg->colors[color][2]; /* B or precalculated V */
 
switch (tpg->fourcc) 

[PATCH] cec: clear fields before transmit and set sequence only if timeout !=0

[Hans Verkuil]

Clear all status-related fields before transmitting the message.

Also set the sequence counter only for messages with a non-zero timeout (== 
they wait for
a reply) and make sure the sequence counter is never 0.

Signed-off-by: Hans Verkuil 

diff --git a/drivers/staging/media/cec/cec-adap.c 
b/drivers/staging/media/cec/cec-adap.c
index 4d86a6c..fc752de 100644
--- a/drivers/staging/media/cec/cec-adap.c
+++ b/drivers/staging/media/cec/cec-adap.c
@@ -574,6 +574,17 @@ int cec_transmit_msg_fh(struct cec_adapter *adap, struct 
cec_msg *msg,
unsigned int timeout;
int res = 0;

+   msg->rx_ts = 0;
+   msg->tx_ts = 0;
+   msg->rx_status = 0;
+   msg->tx_status = 0;
+   msg->tx_arb_lost_cnt = 0;
+   msg->tx_nack_cnt = 0;
+   msg->tx_low_drive_cnt = 0;
+   msg->tx_error_cnt = 0;
+   msg->sequence = 0;
+   msg->flags = 0;
+
if (msg->reply && msg->timeout == 0) {
/* Make sure the timeout isn't 0. */
msg->timeout = 1000;
@@ -640,14 +651,12 @@ int cec_transmit_msg_fh(struct cec_adapter *adap, struct 
cec_msg *msg,
dprintk(2, "cec_transmit_msg: %*ph%s\n",
msg->len, msg->msg, !block ? " (nb)" : "");

-   msg->rx_ts = 0;
-   msg->tx_ts = 0;
-   msg->rx_status = 0;
-   msg->tx_status = 0;
-   msg->tx_arb_lost_cnt = 0;
-   msg->tx_nack_cnt = 0;
-   msg->tx_low_drive_cnt = 0;
-   msg->tx_error_cnt = 0;
+   if (msg->timeout) {
+   msg->sequence = ++adap->sequence;
+   if (!msg->sequence)
+   msg->sequence = ++adap->sequence;
+   }
+
data->msg = *msg;
data->fh = fh;
data->adap = adap;
@@ -673,7 +682,6 @@ int cec_transmit_msg_fh(struct cec_adapter *adap, struct 
cec_msg *msg,
init_completion(>c);
INIT_DELAYED_WORK(>work, cec_wait_timeout);

-   data->msg.sequence = adap->sequence++;
if (fh)
list_add_tail(>xfer_list, >xfer_list);
list_add_tail(>list, >transmit_queue);
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [media] ad9389b: Remove deprecated create_singlethread_workqueue

[Bhaktipriya Shridhar]

The workqueue work_queue is involved in EDID (Extended Display
Identification Data) handling.

It has a single work item(>edid_handler) and hence
doesn't require ordering. It is not being used on a memory reclaim path.
Hence, the singlethreaded workqueue has been replaced with
the use of system_wq.

>edid_handler is a self requeueing work item and it has been
been sync cancelled in ad9389b_remove() to ensure that nothing is
pending when the driver is disconnected.

Signed-off-by: Bhaktipriya Shridhar 
---
 drivers/media/i2c/ad9389b.c | 20 
 1 file changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/media/i2c/ad9389b.c b/drivers/media/i2c/ad9389b.c
index 0462f46..1ac552d 100644
--- a/drivers/media/i2c/ad9389b.c
+++ b/drivers/media/i2c/ad9389b.c
@@ -98,7 +98,6 @@ struct ad9389b_state {
struct ad9389b_state_edid edid;
/* Running counter of the number of detected EDIDs (for debugging) */
unsigned edid_detect_counter;
-   struct workqueue_struct *work_queue;
struct delayed_work edid_handler; /* work entry */
 };

@@ -843,8 +842,7 @@ static void ad9389b_edid_handler(struct work_struct *work)
v4l2_dbg(1, debug, sd, "%s: edid read failed\n", 
__func__);
ad9389b_s_power(sd, false);
ad9389b_s_power(sd, true);
-   queue_delayed_work(state->work_queue,
-  >edid_handler, EDID_DELAY);
+   schedule_delayed_work(>edid_handler, EDID_DELAY);
return;
}
}
@@ -933,8 +931,7 @@ static void ad9389b_update_monitor_present_status(struct 
v4l2_subdev *sd)
ad9389b_setup(sd);
ad9389b_notify_monitor_detect(sd);
state->edid.read_retries = EDID_MAX_RETRIES;
-   queue_delayed_work(state->work_queue,
-  >edid_handler, EDID_DELAY);
+   schedule_delayed_work(>edid_handler, EDID_DELAY);
} else if (!(status & MASK_AD9389B_HPD_DETECT)) {
v4l2_dbg(1, debug, sd, "%s: hotplug not detected\n", __func__);
state->have_monitor = false;
@@ -1065,8 +1062,7 @@ static bool ad9389b_check_edid_status(struct v4l2_subdev 
*sd)
ad9389b_wr(sd, 0xc9, 0xf);
ad9389b_wr(sd, 0xc4, state->edid.segments);
state->edid.read_retries = EDID_MAX_RETRIES;
-   queue_delayed_work(state->work_queue,
-  >edid_handler, EDID_DELAY);
+   schedule_delayed_work(>edid_handler, EDID_DELAY);
return false;
}

@@ -1170,13 +1166,6 @@ static int ad9389b_probe(struct i2c_client *client, 
const struct i2c_device_id *
goto err_entity;
}

-   state->work_queue = create_singlethread_workqueue(sd->name);
-   if (state->work_queue == NULL) {
-   v4l2_err(sd, "could not create workqueue\n");
-   err = -ENOMEM;
-   goto err_unreg;
-   }
-
INIT_DELAYED_WORK(>edid_handler, ad9389b_edid_handler);
state->dv_timings = dv1080p60;

@@ -1211,9 +1200,8 @@ static int ad9389b_remove(struct i2c_client *client)
ad9389b_s_stream(sd, false);
ad9389b_s_audio_stream(sd, false);
ad9389b_init_setup(sd);
-   cancel_delayed_work(>edid_handler);
+   cancel_delayed_work_sync(>edid_handler);
i2c_unregister_device(state->edid_i2c_client);
-   destroy_workqueue(state->work_queue);
v4l2_device_unregister_subdev(sd);
media_entity_cleanup(>entity);
v4l2_ctrl_handler_free(sd->ctrl_handler);
--
2.1.4

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

[PATCH 2/2] [media] cx25821: Remove deprecated create_singlethread_workqueue

[Bhaktipriya Shridhar]

The workqueue "_irq_audio_queues" runs the audio upstream handler.
It has a single work item(>_audio_work_entry) and hence doesn't
require ordering. Also, it is not being used on a memory reclaim path.
Hence, the singlethreaded workqueue has been replaced with the use of
system_wq.

System workqueues have been able to handle high level of concurrency
for a long time now and hence it's not required to have a singlethreaded
workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
created with create_singlethread_workqueue(), system_wq allows multiple
work items to overlap executions even on the same CPU; however, a
per-cpu workqueue doesn't have any CPU locality or global ordering
guarantee unless the target CPU is explicitly specified and thus the
increase of local concurrency shouldn't make any difference.

Signed-off-by: Bhaktipriya Shridhar 
---
 drivers/media/pci/cx25821/cx25821-audio-upstream.c | 11 +--
 drivers/media/pci/cx25821/cx25821.h|  1 -
 2 files changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/media/pci/cx25821/cx25821-audio-upstream.c 
b/drivers/media/pci/cx25821/cx25821-audio-upstream.c
index 05bd957..1a86dff 100644
--- a/drivers/media/pci/cx25821/cx25821-audio-upstream.c
+++ b/drivers/media/pci/cx25821/cx25821-audio-upstream.c
@@ -446,8 +446,7 @@ static int cx25821_audio_upstream_irq(struct cx25821_dev 
*dev, int chan_num,

dev->_audioframe_index = dev->_last_index_irq;

-   queue_work(dev->_irq_audio_queues,
-  >_audio_work_entry);
+   schedule_work(>_audio_work_entry);
}

if (dev->_is_first_audio_frame) {
@@ -639,14 +638,6 @@ int cx25821_audio_upstream_init(struct cx25821_dev *dev, 
int channel_select)

/* Work queue */
INIT_WORK(>_audio_work_entry, cx25821_audioups_handler);
-   dev->_irq_audio_queues =
-   create_singlethread_workqueue("cx25821_audioworkqueue");
-
-   if (!dev->_irq_audio_queues) {
-   printk(KERN_DEBUG
-   pr_fmt("ERROR: create_singlethread_workqueue() for 
Audio FAILED!\n"));
-   return -ENOMEM;
-   }

dev->_last_index_irq = 0;
dev->_audio_is_running = 0;
diff --git a/drivers/media/pci/cx25821/cx25821.h 
b/drivers/media/pci/cx25821/cx25821.h
index a513b68..c813d88 100644
--- a/drivers/media/pci/cx25821/cx25821.h
+++ b/drivers/media/pci/cx25821/cx25821.h
@@ -294,7 +294,6 @@ struct cx25821_dev {
u32 audio_upstream_riscbuf_size;
u32 audio_upstream_databuf_size;
int _audioframe_index;
-   struct workqueue_struct *_irq_audio_queues;
struct work_struct _audio_work_entry;
char *input_audiofilename;

--
2.1.4

--
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 1/2] [media] cx25821: Drop Freeing of Workqueue

[Bhaktipriya Shridhar]

Workqueues shouldn't be freed. destroy_workqueue should be used instead.
destroy_workqueue safely destroys a workqueue and ensures that all pending
work items are done before destroying the workqueue.

Signed-off-by: Bhaktipriya Shridhar 
---
 drivers/media/pci/cx25821/cx25821-audio-upstream.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/cx25821/cx25821-audio-upstream.c 
b/drivers/media/pci/cx25821/cx25821-audio-upstream.c
index 68dbc2d..05bd957 100644
--- a/drivers/media/pci/cx25821/cx25821-audio-upstream.c
+++ b/drivers/media/pci/cx25821/cx25821-audio-upstream.c
@@ -242,7 +242,7 @@ void cx25821_stop_upstream_audio(struct cx25821_dev *dev)
dev->_audioframe_count = 0;
dev->_audiofile_status = END_OF_FILE;

-   kfree(dev->_irq_audio_queues);
+   destroy_workqueue(dev->_irq_audio_queues);
dev->_irq_audio_queues = NULL;

kfree(dev->_audiofilename);
--
2.1.4

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

[PATCH 0/2] Remove improper workqueue usage

[Bhaktipriya Shridhar]

This patch set fixes the improper usage of the workqueue API.
This includes dropping the freeing of workqueue and removing the deprecated
create_singlethread_workqueue instance.

Bhaktipriya Shridhar (2):
  [media] cx25821: Drop Freeing of Workqueue
  [media] cx25821: Remove deprecated create_singlethread_workqueue

 drivers/media/pci/cx25821/cx25821-audio-upstream.c | 13 ++---
 drivers/media/pci/cx25821/cx25821.h|  1 -
 2 files changed, 2 insertions(+), 12 deletions(-)

--
2.1.4

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

[PATCH] [media] gspca: finepix: Remove deprecated create_singlethread_workqueue

[Bhaktipriya Shridhar]

The workqueue "work_thread" is involved in streaming the camera data.
It has a single work item(>work_struct) and hence doesn't require
ordering. Also, it is not being used on a memory reclaim path.
Hence, the singlethreaded workqueue has been replaced with the use of
system_wq.

System workqueues have been able to handle high level of concurrency
for a long time now and hence it's not required to have a singlethreaded
workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
created with create_singlethread_workqueue(), system_wq allows multiple
work items to overlap executions even on the same CPU; however, a
per-cpu workqueue doesn't have any CPU locality or global ordering
guarantee unless the target CPU is explicitly specified and thus the
increase of local concurrency shouldn't make any difference.

Work item has been flushed in sd_stop0() to ensure that there are no
pending tasks while disconnecting the driver.

Signed-off-by: Bhaktipriya Shridhar 
---
 drivers/media/usb/gspca/finepix.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/gspca/finepix.c 
b/drivers/media/usb/gspca/finepix.c
index 52bdb56..ae9a55d 100644
--- a/drivers/media/usb/gspca/finepix.c
+++ b/drivers/media/usb/gspca/finepix.c
@@ -41,7 +41,6 @@ struct usb_fpix {
struct gspca_dev gspca_dev; /* !! must be the first item */

struct work_struct work_struct;
-   struct workqueue_struct *work_thread;
 };

 /* Delay after which claim the next frame. If the delay is too small,
@@ -226,9 +225,7 @@ static int sd_start(struct gspca_dev *gspca_dev)
/* Again, reset bulk in endpoint */
usb_clear_halt(gspca_dev->dev, gspca_dev->urb[0]->pipe);

-   /* Start the workqueue function to do the streaming */
-   dev->work_thread = create_singlethread_workqueue(MODULE_NAME);
-   queue_work(dev->work_thread, >work_struct);
+   schedule_work(>work_struct);

return 0;
 }
@@ -241,9 +238,8 @@ static void sd_stop0(struct gspca_dev *gspca_dev)

/* wait for the work queue to terminate */
mutex_unlock(_dev->usb_lock);
-   destroy_workqueue(dev->work_thread);
+   flush_work(>work_struct);
mutex_lock(_dev->usb_lock);
-   dev->work_thread = NULL;
 }

 /* Table of supported USB devices */
--
2.1.4

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

[PATCH] [media] gspca: jl2005bcd: Remove deprecated create_singlethread_workqueue

[Bhaktipriya Shridhar]

The workqueue "work_thread" is involved in streaming the camera data.
It has a single work item(>work_struct) and hence doesn't require
ordering. Also, it is not being used on a memory reclaim path.
Hence, the singlethreaded workqueue has been replaced with the use of
system_wq.

System workqueues have been able to handle high level of concurrency
for a long time now and hence it's not required to have a singlethreaded
workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
created with create_singlethread_workqueue(), system_wq allows multiple
work items to overlap executions even on the same CPU; however, a
per-cpu workqueue doesn't have any CPU locality or global ordering
guarantee unless the target CPU is explicitly specified and thus the
increase of local concurrency shouldn't make any difference.

Work item has been flushed in sd_stop0() to ensure that there are no
pending tasks while disconnecting the driver.

Signed-off-by: Bhaktipriya Shridhar 
---
 drivers/media/usb/gspca/jl2005bcd.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/gspca/jl2005bcd.c 
b/drivers/media/usb/gspca/jl2005bcd.c
index 5b481fa..ac295f0 100644
--- a/drivers/media/usb/gspca/jl2005bcd.c
+++ b/drivers/media/usb/gspca/jl2005bcd.c
@@ -45,7 +45,6 @@ struct sd {
const struct v4l2_pix_format *cap_mode;
/* Driver stuff */
struct work_struct work_struct;
-   struct workqueue_struct *work_thread;
u8 frame_brightness;
int block_size; /* block size of camera */
int vga;/* 1 if vga cam, 0 if cif cam */
@@ -477,9 +476,7 @@ static int sd_start(struct gspca_dev *gspca_dev)
return -1;
}

-   /* Start the workqueue function to do the streaming */
-   sd->work_thread = create_singlethread_workqueue(MODULE_NAME);
-   queue_work(sd->work_thread, >work_struct);
+   schedule_work(>work_struct);

return 0;
 }
@@ -493,8 +490,7 @@ static void sd_stop0(struct gspca_dev *gspca_dev)
/* wait for the work queue to terminate */
mutex_unlock(_dev->usb_lock);
/* This waits for sq905c_dostream to finish */
-   destroy_workqueue(dev->work_thread);
-   dev->work_thread = NULL;
+   flush_work(>work_struct);
mutex_lock(_dev->usb_lock);
 }

--
2.1.4

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

[PATCH] [media] gspca: vicam: Remove deprecated create_singlethread_workqueue

[Bhaktipriya Shridhar]

The workqueue "work_thread" is involved in streaming the camera data.
It has a single work item(>work_struct) and hence doesn't require
ordering. Also, it is not being used on a memory reclaim path.
Hence, the singlethreaded workqueue has been replaced with the use of
system_wq.

System workqueues have been able to handle high level of concurrency
for a long time now and hence it's not required to have a singlethreaded
workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
created with create_singlethread_workqueue(), system_wq allows multiple
work items to overlap executions even on the same CPU; however, a
per-cpu workqueue doesn't have any CPU locality or global ordering
guarantee unless the target CPU is explicitly specified and thus the
increase of local concurrency shouldn't make any difference.

Work item has been flushed in sd_stop0() to ensure that there are no
pending tasks while disconnecting the driver.

Signed-off-by: Bhaktipriya Shridhar 
---
 drivers/media/usb/gspca/vicam.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/gspca/vicam.c b/drivers/media/usb/gspca/vicam.c
index 103f6c4..8860510 100644
--- a/drivers/media/usb/gspca/vicam.c
+++ b/drivers/media/usb/gspca/vicam.c
@@ -47,7 +47,6 @@ MODULE_FIRMWARE(VICAM_FIRMWARE);
 struct sd {
struct gspca_dev gspca_dev; /* !! must be the first item */
struct work_struct work_struct;
-   struct workqueue_struct *work_thread;
 };

 /* The vicam sensor has a resolution of 512 x 244, with I believe square
@@ -278,9 +277,7 @@ static int sd_start(struct gspca_dev *gspca_dev)
if (ret < 0)
return ret;

-   /* Start the workqueue function to do the streaming */
-   sd->work_thread = create_singlethread_workqueue(MODULE_NAME);
-   queue_work(sd->work_thread, >work_struct);
+   schedule_work(>work_struct);

return 0;
 }
@@ -294,8 +291,7 @@ static void sd_stop0(struct gspca_dev *gspca_dev)
/* wait for the work queue to terminate */
mutex_unlock(_dev->usb_lock);
/* This waits for vicam_dostream to finish */
-   destroy_workqueue(dev->work_thread);
-   dev->work_thread = NULL;
+   flush_work(>work_struct);
mutex_lock(_dev->usb_lock);

if (gspca_dev->present)
--
2.1.4

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

[PATCH] [media] gspca: sonixj: Remove deprecated create_singlethread_workqueue

[Bhaktipriya Shridhar]

The workqueue "work_thread" is involved in updating the JPEG quality
of the gspca_dev. It has a single work item(>work) and hence doesn't
require ordering. Also, it is not being used on a memory reclaim path.
Hence, the singlethreaded workqueue has been replaced with the use of
system_wq.

System workqueues have been able to handle high level of concurrency
for a long time now and hence it's not required to have a singlethreaded
workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
created with create_singlethread_workqueue(), system_wq allows multiple
work items to overlap executions even on the same CPU; however, a
per-cpu workqueue doesn't have any CPU locality or global ordering
guarantee unless the target CPU is explicitly specified and thus the
increase of local concurrency shouldn't make any difference.

Work item has been flushed in sd_stop0() to ensure that there are no
pending tasks while disconnecting the driver.

Signed-off-by: Bhaktipriya Shridhar 
---
 drivers/media/usb/gspca/sonixj.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/media/usb/gspca/sonixj.c b/drivers/media/usb/gspca/sonixj.c
index fd1c870..d49d76e 100644
--- a/drivers/media/usb/gspca/sonixj.c
+++ b/drivers/media/usb/gspca/sonixj.c
@@ -54,7 +54,6 @@ struct sd {
u32 exposure;

struct work_struct work;
-   struct workqueue_struct *work_thread;

u32 pktsz;  /* (used by pkt_scan) */
u16 npkt;
@@ -2485,7 +2484,6 @@ static int sd_start(struct gspca_dev *gspca_dev)

sd->pktsz = sd->npkt = 0;
sd->nchg = sd->short_mark = 0;
-   sd->work_thread = create_singlethread_workqueue(MODULE_NAME);

return gspca_dev->usb_err;
 }
@@ -2569,12 +2567,9 @@ static void sd_stop0(struct gspca_dev *gspca_dev)
 {
struct sd *sd = (struct sd *) gspca_dev;

-   if (sd->work_thread != NULL) {
-   mutex_unlock(_dev->usb_lock);
-   destroy_workqueue(sd->work_thread);
-   mutex_lock(_dev->usb_lock);
-   sd->work_thread = NULL;
-   }
+   mutex_unlock(_dev->usb_lock);
+   flush_work(>work);
+   mutex_lock(_dev->usb_lock);
 }

 static void do_autogain(struct gspca_dev *gspca_dev)
@@ -2785,7 +2780,7 @@ marker_found:
new_qual = QUALITY_MAX;
if (new_qual != sd->quality) {
sd->quality = new_qual;
-   queue_work(sd->work_thread, >work);
+   schedule_work(>work);
}
}
} else {
--
2.1.4

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

[PATCH] [media] pvrusb2: Remove deprecated create_singlethread_workqueue

[Bhaktipriya Shridhar]

The workqueue "workqueue" is involved in polling the pvrusb2 hardware
(pvr2_hdw).

It has a single work item(>workpoll) and hence doesn't require
ordering. Also, it is not being used on a memory reclaim path.
Hence, the singlethreaded workqueue has been replaced with the use of
system_wq.

System workqueues have been able to handle high level of concurrency
for a long time now and hence it's not required to have a singlethreaded
workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
created with create_singlethread_workqueue(), system_wq allows multiple
work items to overlap executions even on the same CPU; however, a
per-cpu workqueue doesn't have any CPU locality or global ordering
guarantee unless the target CPU is explicitly specified and thus the
increase of local concurrency shouldn't make any difference.

Work item has been flushed in pvr2_hdw_destroy to ensure that there are no
pending tasks while disconnecting the driver.

Signed-off-by: Bhaktipriya Shridhar 
---
 drivers/media/usb/pvrusb2/pvrusb2-hdw-internal.h |  1 -
 drivers/media/usb/pvrusb2/pvrusb2-hdw.c  | 23 +++
 2 files changed, 7 insertions(+), 17 deletions(-)

diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw-internal.h 
b/drivers/media/usb/pvrusb2/pvrusb2-hdw-internal.h
index 60141b1..23473a2 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-hdw-internal.h
+++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw-internal.h
@@ -170,7 +170,6 @@ struct pvr2_hdw {
const struct pvr2_device_desc *hdw_desc;

/* Kernel worker thread handling */
-   struct workqueue_struct *workqueue;
struct work_struct workpoll; /* Update driver state */

/* Video spigot */
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c 
b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
index 83e9a3e..85e39ec 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
@@ -2624,7 +2624,6 @@ struct pvr2_hdw *pvr2_hdw_create(struct usb_interface 
*intf,
if (cnt1 >= sizeof(hdw->name)) cnt1 = sizeof(hdw->name)-1;
hdw->name[cnt1] = 0;

-   hdw->workqueue = create_singlethread_workqueue(hdw->name);
INIT_WORK(>workpoll,pvr2_hdw_worker_poll);

pvr2_trace(PVR2_TRACE_INIT,"Driver unit number is %d, name is %s",
@@ -2651,11 +2650,7 @@ struct pvr2_hdw *pvr2_hdw_create(struct usb_interface 
*intf,
del_timer_sync(>decoder_stabilization_timer);
del_timer_sync(>encoder_run_timer);
del_timer_sync(>encoder_wait_timer);
-   if (hdw->workqueue) {
-   flush_workqueue(hdw->workqueue);
-   destroy_workqueue(hdw->workqueue);
-   hdw->workqueue = NULL;
-   }
+   flush_work(>workpoll);
usb_free_urb(hdw->ctl_read_urb);
usb_free_urb(hdw->ctl_write_urb);
kfree(hdw->ctl_read_buffer);
@@ -2712,11 +2707,7 @@ void pvr2_hdw_destroy(struct pvr2_hdw *hdw)
 {
if (!hdw) return;
pvr2_trace(PVR2_TRACE_INIT,"pvr2_hdw_destroy: hdw=%p",hdw);
-   if (hdw->workqueue) {
-   flush_workqueue(hdw->workqueue);
-   destroy_workqueue(hdw->workqueue);
-   hdw->workqueue = NULL;
-   }
+   flush_work(>workpoll);
del_timer_sync(>quiescent_timer);
del_timer_sync(>decoder_stabilization_timer);
del_timer_sync(>encoder_run_timer);
@@ -4439,7 +4430,7 @@ static void pvr2_hdw_quiescent_timeout(unsigned long data)
hdw->state_decoder_quiescent = !0;
trace_stbit("state_decoder_quiescent",hdw->state_decoder_quiescent);
hdw->state_stale = !0;
-   queue_work(hdw->workqueue,>workpoll);
+   schedule_work(>workpoll);
 }


@@ -4450,7 +4441,7 @@ static void 
pvr2_hdw_decoder_stabilization_timeout(unsigned long data)
hdw->state_decoder_ready = !0;
trace_stbit("state_decoder_ready", hdw->state_decoder_ready);
hdw->state_stale = !0;
-   queue_work(hdw->workqueue, >workpoll);
+   schedule_work(>workpoll);
 }


@@ -4461,7 +4452,7 @@ static void pvr2_hdw_encoder_wait_timeout(unsigned long 
data)
hdw->state_encoder_waitok = !0;
trace_stbit("state_encoder_waitok",hdw->state_encoder_waitok);
hdw->state_stale = !0;
-   queue_work(hdw->workqueue,>workpoll);
+   schedule_work(>workpoll);
 }


@@ -4473,7 +4464,7 @@ static void pvr2_hdw_encoder_run_timeout(unsigned long 
data)
hdw->state_encoder_runok = !0;
trace_stbit("state_encoder_runok",hdw->state_encoder_runok);
hdw->state_stale = !0;
-   queue_work(hdw->workqueue,>workpoll);
+   schedule_work(>workpoll);
}
 }

@@ -4987,7 +4978,7 @@ static void pvr2_hdw_state_sched(struct pvr2_hdw *hdw)
if (hdw->state_stale) return;
hdw->state_stale = !0;

[PATCH] [media] s5p-mfc: Remove deprecated create_singlethread_workqueue

[Bhaktipriya Shridhar]

alloc_workqueue replaces deprecated create_singlethread_workqueue().

The MFC device driver is a v4l2 driver which can encode/decode video
raw/elementary streams and has support for all popular video codecs.

The driver's watchdog_workqueue has been replaced with system_wq since
it queues a single work item, >watchdog_work, which calls for no
ordering requirement. The work item is involved in running the watchdog
timer and is not being used on a memory reclaim path.

Work item has been flushed in s5p_mfc_remove() to ensure
that there are no pending tasks while disconnecting the driver.

Signed-off-by: Bhaktipriya Shridhar 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index b16466f..1bc27ec 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -152,7 +152,7 @@ static void s5p_mfc_watchdog(unsigned long arg)
 * error. Now it is time to kill all instances and
 * reset the MFC. */
mfc_err("Time out during waiting for HW\n");
-   queue_work(dev->watchdog_workqueue, >watchdog_work);
+   schedule_work(>watchdog_work);
}
dev->watchdog_timer.expires = jiffies +
msecs_to_jiffies(MFC_WATCHDOG_INTERVAL);
@@ -1238,7 +1238,6 @@ static int s5p_mfc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dev);

dev->hw_lock = 0;
-   dev->watchdog_workqueue = create_singlethread_workqueue(S5P_MFC_NAME);
INIT_WORK(>watchdog_work, s5p_mfc_watchdog_worker);
atomic_set(>watchdog_cnt, 0);
init_timer(>watchdog_timer);
@@ -1284,8 +1283,7 @@ static int s5p_mfc_remove(struct platform_device *pdev)
v4l2_info(>v4l2_dev, "Removing %s\n", pdev->name);

del_timer_sync(>watchdog_timer);
-   flush_workqueue(dev->watchdog_workqueue);
-   destroy_workqueue(dev->watchdog_workqueue);
+   flush_work(>watchdog_work);

video_unregister_device(dev->vfd_enc);
video_unregister_device(dev->vfd_dec);
--
2.1.4

--
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 2/6] [media] Documentation: Add HSV format

[Ricardo Ribalda Delgado]

Hi Laurent

It is actually a very good comment. :) In our case we have implemented
the format ourselves in the FPGA and we support both 0-255 and 0-179
Hue ranges.

After some weeks of use, only the 0-179 range is used in userpace. The
reasons for this is mainly that it is the format used by OpenCV
http://docs.opencv.org/3.1.0/de/d25/imgproc_color_conversions.html#color_convert_rgb_hsv=0
, but also because it is very efficient to convert from 0-360 to 0-180
and the lose of color resolution (256/180) does not lead to (human)
perceptible differences.

All that said, I would not mind to implement also the 0-255 range, but
I do not know which API should be the best way to do it. quantization?
it looks nice, but it is not really a quantization... a control? a bit
messy fourcc? seems good...

I am open to anything :), but I am not the right guy for making the
decision. Hans, could you help me?


Thanks!

On Fri, Jul 15, 2016 at 8:11 PM, Laurent Pinchart
 wrote:
> Hi Ricardo,
>
> Thank you for the patch.
>
> On Friday 15 Jul 2016 18:13:15 Ricardo Ribalda Delgado wrote:
>> Describe the HSV formats
>>
>> Signed-off-by: Ricardo Ribalda Delgado 
>> ---
>>  Documentation/media/uapi/v4l/hsv-formats.rst   |  19 ++
>>  Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 253 ++
>>  Documentation/media/uapi/v4l/pixfmt.rst|   1 +
>>  Documentation/media/uapi/v4l/v4l2.rst  |   5 +
>>  4 files changed, 278 insertions(+)
>>  create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
>>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
>>
>> diff --git a/Documentation/media/uapi/v4l/hsv-formats.rst
>> b/Documentation/media/uapi/v4l/hsv-formats.rst new file mode 100644
>> index ..f0f2615eaa95
>> --- /dev/null
>> +++ b/Documentation/media/uapi/v4l/hsv-formats.rst
>> @@ -0,0 +1,19 @@
>> +.. -*- coding: utf-8; mode: rst -*-
>> +
>> +.. _hsv-formats:
>> +
>> +***
>> +HSV Formats
>> +***
>> +
>> +These formats store the color information of the image
>> +in a geometrical representation. The colors are mapped into a
>> +cylinder, where the angle is the HUE, the height is the VALUE
>> +and the distance to the center is the SATURATION. This is a very
>> +useful format for image segmentation algorithms.
>> +
>> +
>> +.. toctree::
>> +:maxdepth: 1
>> +
>> +pixfmt-packed-hsv
>> diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
>> b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst new file mode 100644
>> index ..b297aa4f7ba6
>> --- /dev/null
>> +++ b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
>> @@ -0,0 +1,253 @@
>> +.. -*- coding: utf-8; mode: rst -*-
>> +
>> +.. _packed-hsv:
>> +
>> +**
>> +Packed HSV formats
>> +**
>> +
>> +*man Packed HSV formats(2)*
>> +
>> +Packed HSV formats
>> +
>> +
>> +Description
>> +===
>> +
>> +The HUE (h) is meassured in degrees, one LSB represents two degrees.
>
> Is this common ? I have a device that can handle HSV data, I need to check how
> it maps the hue values to binary, but I'm pretty sure they cover the full
> 0-255 range. We would then have to support the two formats. Separate 4CCs are
> an option, but reporting the range separately (possibly through the colorspace
> API) might be better. Any thought on that ?
>
>> +The SATURATION (s) and the VALUE (v) are measured in percentage of the
>> +cylinder: 0 being the smallest value and 255 the maximum.
>> +
>> +
>> +The values are packed in 24 or 32 bit formats.
>> +
>> +
>> +.. flat-table:: Packed HSV Image Formats
>> +:header-rows:  2
>> +:stub-columns: 0
>> +
>> +
>> +-  .. row 1
>> +
>> +   -  Identifier
>> +
>> +   -  Code
>> +
>> +   -
>> +   -  :cspan:`7` Byte 0 in memory
>> +
>
> Do we really need all those blank lines ?
>
> [snip]
>
> --
> Regards,
>
> Laurent Pinchart
>



-- 
Ricardo Ribalda
--
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 2/6] [media] Documentation: Add HSV format

[Hans Verkuil]

On 07/15/2016 08:11 PM, Laurent Pinchart wrote:
> Hi Ricardo,
> 
> Thank you for the patch.
> 
> On Friday 15 Jul 2016 18:13:15 Ricardo Ribalda Delgado wrote:
>> Describe the HSV formats
>>
>> Signed-off-by: Ricardo Ribalda Delgado 
>> ---
>>  Documentation/media/uapi/v4l/hsv-formats.rst   |  19 ++
>>  Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 253 ++
>>  Documentation/media/uapi/v4l/pixfmt.rst|   1 +
>>  Documentation/media/uapi/v4l/v4l2.rst  |   5 +
>>  4 files changed, 278 insertions(+)
>>  create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
>>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
>>
>> diff --git a/Documentation/media/uapi/v4l/hsv-formats.rst
>> b/Documentation/media/uapi/v4l/hsv-formats.rst new file mode 100644
>> index ..f0f2615eaa95
>> --- /dev/null
>> +++ b/Documentation/media/uapi/v4l/hsv-formats.rst
>> @@ -0,0 +1,19 @@
>> +.. -*- coding: utf-8; mode: rst -*-
>> +
>> +.. _hsv-formats:
>> +
>> +***
>> +HSV Formats
>> +***
>> +
>> +These formats store the color information of the image
>> +in a geometrical representation. The colors are mapped into a
>> +cylinder, where the angle is the HUE, the height is the VALUE
>> +and the distance to the center is the SATURATION. This is a very
>> +useful format for image segmentation algorithms.
>> +
>> +
>> +.. toctree::
>> +:maxdepth: 1
>> +
>> +pixfmt-packed-hsv
>> diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
>> b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst new file mode 100644
>> index ..b297aa4f7ba6
>> --- /dev/null
>> +++ b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
>> @@ -0,0 +1,253 @@
>> +.. -*- coding: utf-8; mode: rst -*-
>> +
>> +.. _packed-hsv:
>> +
>> +**
>> +Packed HSV formats
>> +**
>> +
>> +*man Packed HSV formats(2)*
>> +
>> +Packed HSV formats
>> +
>> +
>> +Description
>> +===
>> +
>> +The HUE (h) is meassured in degrees, one LSB represents two degrees.
> 
> Is this common ? I have a device that can handle HSV data, I need to check 
> how 
> it maps the hue values to binary, but I'm pretty sure they cover the full 
> 0-255 range. We would then have to support the two formats. Separate 4CCs are 
> an option, but reporting the range separately (possibly through the 
> colorspace 
> API) might be better. Any thought on that ?

It's either a separate 4cc or we do something with the ycbcr_enc field 
(reinterpreted
as hsv_enc). I'm not sure, I would have to think some more about that.

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