cron job: media_tree daily build: ERRORS
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 May 27 05:00:15 CEST 2018 media-tree git hash:e646e17713eeb3b6484b6d7a24ce34854123fa39 media_build git hash: 6d20e27f483f005477fb480013c40df775483e42 v4l-utils git hash: 2a12796b5c22cd1a549eb8fa25db873ced811ca5 gcc version:i686-linux-gcc (GCC) 8.1.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.16.0-1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-2.6.36.4-i686: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-i686: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.101-i686: ERRORS linux-3.0.101-x86_64: ERRORS linux-3.1.10-i686: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.101-i686: ERRORS linux-3.2.101-x86_64: ERRORS linux-3.3.8-i686: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.113-i686: ERRORS linux-3.4.113-x86_64: ERRORS linux-3.5.7-i686: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-i686: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.10-i686: ERRORS linux-3.7.10-x86_64: ERRORS linux-3.8.13-i686: ERRORS linux-3.8.13-x86_64: ERRORS linux-3.9.11-i686: ERRORS linux-3.9.11-x86_64: ERRORS linux-3.10.108-i686: ERRORS linux-3.10.108-x86_64: ERRORS linux-3.11.10-i686: ERRORS linux-3.11.10-x86_64: ERRORS linux-3.12.74-i686: ERRORS linux-3.12.74-x86_64: ERRORS linux-3.13.11-i686: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.79-i686: ERRORS linux-3.14.79-x86_64: ERRORS linux-3.15.10-i686: ERRORS linux-3.15.10-x86_64: ERRORS linux-3.16.56-i686: ERRORS linux-3.16.56-x86_64: ERRORS linux-3.17.8-i686: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18.102-i686: ERRORS linux-3.18.102-x86_64: ERRORS linux-3.19.8-i686: ERRORS linux-3.19.8-x86_64: ERRORS linux-4.0.9-i686: ERRORS linux-4.0.9-x86_64: ERRORS linux-4.1.51-i686: ERRORS linux-4.1.51-x86_64: ERRORS linux-4.2.8-i686: ERRORS linux-4.2.8-x86_64: ERRORS linux-4.3.6-i686: ERRORS linux-4.3.6-x86_64: ERRORS linux-4.4.109-i686: ERRORS linux-4.4.109-x86_64: ERRORS linux-4.5.7-i686: ERRORS linux-4.5.7-x86_64: ERRORS linux-4.6.7-i686: ERRORS linux-4.6.7-x86_64: ERRORS linux-4.7.10-i686: ERRORS linux-4.7.10-x86_64: ERRORS linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.91-i686: OK linux-4.9.91-x86_64: OK linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK linux-4.12.14-i686: OK linux-4.12.14-x86_64: OK linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.42-i686: OK linux-4.14.42-x86_64: OK linux-4.15.14-i686: OK linux-4.15.14-x86_64: OK linux-4.16.8-i686: OK linux-4.16.8-x86_64: OK linux-4.17-rc4-i686: OK linux-4.17-rc4-x86_64: OK apps: OK spec-git: OK sparse: 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/index.html
[ragnatech:media-tree 167/415] drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:45:6: error: implicit declaration of function 'omapdss_device_is_connected'; did you mean 'pci_device_is_prese
tree: git://git.ragnatech.se/linux media-tree head: e646e17713eeb3b6484b6d7a24ce34854123fa39 commit: 771f7be87ff921e9a3d744febd606af39a150e14 [167/415] media: omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP config: s390-allmodconfig (attached as .config) compiler: s390x-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 771f7be87ff921e9a3d744febd606af39a150e14 # save the attached .config to linux build tree make.cross ARCH=s390 Note: the ragnatech/media-tree HEAD e646e17713eeb3b6484b6d7a24ce34854123fa39 builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c: In function 'opa362_connect': >> drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:45:6: error: >> implicit declaration of function 'omapdss_device_is_connected'; did you mean >> 'pci_device_is_present'? [-Werror=implicit-function-declaration] if (omapdss_device_is_connected(dssdev)) ^~~ pci_device_is_present drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c: In function 'opa362_enable': >> drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:91:6: error: >> implicit declaration of function 'omapdss_device_is_enabled'; did you mean >> 'pci_dev_msi_enabled'? [-Werror=implicit-function-declaration] if (omapdss_device_is_enabled(dssdev)) ^ pci_dev_msi_enabled drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c: In function 'opa362_probe': drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:210:7: error: implicit declaration of function 'omapdss_of_find_source_for_first_ep' [-Werror=implicit-function-declaration] in = omapdss_of_find_source_for_first_ep(node); ^~~ drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:210:5: warning: assignment makes pointer from integer without a cast [-Wint-conversion] in = omapdss_of_find_source_for_first_ep(node); ^ drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:225:6: error: implicit declaration of function 'omapdss_register_output'; did you mean 'omap_dispc_register_isr'? [-Werror=implicit-function-declaration] r = omapdss_register_output(dssdev); ^~~ omap_dispc_register_isr drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c: In function 'opa362_remove': drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:243:2: error: implicit declaration of function 'omapdss_unregister_output'; did you mean 'omap_dispc_unregister_isr'? [-Werror=implicit-function-declaration] omapdss_unregister_output(&ddata->dssdev); ^ omap_dispc_unregister_isr cc1: some warnings being treated as errors -- drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c: In function 'tfp410_connect': >> drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c:39:6: error: >> implicit declaration of function 'omapdss_device_is_connected'; did you mean >> 'pci_device_is_present'? [-Werror=implicit-function-declaration] if (omapdss_device_is_connected(dssdev)) ^~~ pci_device_is_present drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c: In function 'tfp410_enable': >> drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c:81:6: error: >> implicit declaration of function 'omapdss_device_is_enabled'; did you mean >> 'pci_dev_msi_enabled'? [-Werror=implicit-function-declaration] if (omapdss_device_is_enabled(dssdev)) ^ pci_dev_msi_enabled drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c: In function 'tfp410_probe_of': drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c:184:7: error: implicit declaration of function 'omapdss_of_find_source_for_first_ep' [-Werror=implicit-function-declaration] in = omapdss_of_find_source_for_first_ep(node); ^~~ drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c:184:5: warning: assignment makes pointer from integer without a cast [-Wint-conversion] in = omapdss_of_find_source_for_first_ep(node); ^ drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c: In function 'tfp410_probe': drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c:233:6: error: implicit declaration of function 'omapdss_register_output'; did you mean 'omap_dispc_register_isr'? [-Werror=implicit-function-declaration] r = omapdss_register_output(dssdev); ^~~ omap_dispc_register_isr drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c: In function
[ragnatech:media-tree 247/415] drivers/i2c/Kconfig:61: symbol I2C_MUX is selected by VIDEO_CX231XX
tree: git://git.ragnatech.se/linux media-tree head: e646e17713eeb3b6484b6d7a24ce34854123fa39 commit: 7b5e3da52a3058e981c8f9331cea8efea25312d6 [247/415] media: cx231xx: Add I2C_MUX dependency config: sparc-defconfig (attached as .config) compiler: sparc-linux-gcc (GCC) 8.1.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 7b5e3da52a3058e981c8f9331cea8efea25312d6 # save the attached .config to linux build tree make.cross ARCH=sparc Note: the ragnatech/media-tree HEAD e646e17713eeb3b6484b6d7a24ce34854123fa39 builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): >> drivers/i2c/Kconfig:61:error: recursive dependency detected! >> drivers/i2c/Kconfig:61: symbol I2C_MUX is selected by VIDEO_CX231XX >> drivers/media/usb/cx231xx/Kconfig:1: symbol VIDEO_CX231XX depends on I2C_MUX For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" vim +61 drivers/i2c/Kconfig 16538e6b Jan Engelhardt 2007-05-01 37 9c1600ed David Brownell 2007-05-01 38 config I2C_BOARDINFO 6341e62b Christoph Jaeger 2014-12-20 39bool 9c1600ed David Brownell 2007-05-01 40default y 9c1600ed David Brownell 2007-05-01 41 2bb5095a Jean Delvare 2009-09-18 42 config I2C_COMPAT 6341e62b Christoph Jaeger 2014-12-20 43bool "Enable compatibility bits for old user-space" 2bb5095a Jean Delvare 2009-09-18 44default y 2bb5095a Jean Delvare 2009-09-18 45help 2bb5095a Jean Delvare 2009-09-18 46 Say Y here if you intend to run lm-sensors 3.1.1 or older, or any 2bb5095a Jean Delvare 2009-09-18 47 other user-space package which expects i2c adapters to be class 2bb5095a Jean Delvare 2009-09-18 48 devices. If you don't know, say Y. 2bb5095a Jean Delvare 2009-09-18 49 ^1da177e Linus Torvalds 2005-04-16 50 config I2C_CHARDEV ^1da177e Linus Torvalds 2005-04-16 51tristate "I2C device interface" ^1da177e Linus Torvalds 2005-04-16 52help ^1da177e Linus Torvalds 2005-04-16 53 Say Y here to use i2c-* device files, usually found in the /dev ^1da177e Linus Torvalds 2005-04-16 54 directory on your system. They make it possible to have user-space ^1da177e Linus Torvalds 2005-04-16 55 programs use the I2C bus. Information on how to do this is ^1da177e Linus Torvalds 2005-04-16 56 contained in the file . ^1da177e Linus Torvalds 2005-04-16 57 ^1da177e Linus Torvalds 2005-04-16 58 This support is also available as a module. If so, the module ^1da177e Linus Torvalds 2005-04-16 59 will be called i2c-dev. ^1da177e Linus Torvalds 2005-04-16 60 0826374b Michael Lawnick 2010-08-11 @61 config I2C_MUX 0826374b Michael Lawnick 2010-08-11 62tristate "I2C bus multiplexing support" 0826374b Michael Lawnick 2010-08-11 63help 0826374b Michael Lawnick 2010-08-11 64 Say Y here if you want the I2C core to support the ability to 0826374b Michael Lawnick 2010-08-11 65 handle multiplexed I2C bus topologies, by presenting each 0826374b Michael Lawnick 2010-08-11 66 multiplexed segment as a I2C adapter. 0826374b Michael Lawnick 2010-08-11 67 0826374b Michael Lawnick 2010-08-11 68 This support is also available as a module. If so, the module 0826374b Michael Lawnick 2010-08-11 69 will be called i2c-mux. 0826374b Michael Lawnick 2010-08-11 70 :: The code at line 61 was first introduced by commit :: 0826374bff57411d239f2fcb15da3c35af0a93cd i2c: Multiplexed I2C bus core support :: TO: Michael Lawnick :: CC: Jean Delvare --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH 3/6] media: videodev2.h: Add macro V4L2_FIELD_IS_SEQUENTIAL
Hi Nicolas,
On 05/25/2018 06:21 PM, Nicolas Dufresne wrote:
Le vendredi 25 mai 2018 à 21:14 -0400, Nicolas Dufresne a écrit :
Le vendredi 25 mai 2018 à 17:19 -0700, Steve Longerbeam a écrit :
On 05/25/2018 05:10 PM, Nicolas Dufresne wrote:
(in text this time, sorry)
Le vendredi 25 mai 2018 à 16:53 -0700, Steve Longerbeam a écrit :
Add a macro that returns true if the given field type is
'sequential',
that is, the data is transmitted, or exists in memory, as all top
field
lines followed by all bottom field lines, or vice-versa.
Signed-off-by: Steve Longerbeam
---
include/uapi/linux/videodev2.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/uapi/linux/videodev2.h
b/include/uapi/linux/videodev2.h
index 600877b..408ee96 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -126,6 +126,10 @@ enum v4l2_field {
(field) == V4L2_FIELD_INTERLACED_BT ||\
(field) == V4L2_FIELD_SEQ_TB ||\
(field) == V4L2_FIELD_SEQ_BT)
+#define V4L2_FIELD_IS_SEQUENTIAL(field) \
+ ((field) == V4L2_FIELD_SEQ_TB ||\
+(field) == V4L2_FIELD_SEQ_BT ||\
+(field) == V4L2_FIELD_ALTERNATE)
No, alternate has no place here, in alternate mode each buffers have
only one field.
Then I misunderstand what is meant by "alternate". The name implies
to me that a source sends top or bottom field alternately, or top/bottom
fields exist in memory buffers alternately, but with no information about
which field came first. In other words, "alternate" is either seq-tb or
seq-bt,
without any info about field order.
If it is just one field in a memory buffer, why isn't it called
V4L2_FIELD_TOP_OR_BOTTOM, e.g. we don't know which?
I don't see why this could be better then ALTERNATE, were buffers are
only top or bottom fields alternatively. And even if there was another
possible name, this is public API.
V4L2_FIELD_ALTERNATE is a mode, that will only be used with
v4l2_pix_format or v4l2_pix_format_mplane. I should never bet set on
the v4l2_buffer.field, instead the driver indicates the parity of the
field by setting V42_FIELD_TOP/BOTTOM on the v4l2_buffer returned by
DQBUF. This is a very different mode of operation compared to
sequential, hence why I believe it is wrong to make it part of the new
helper. So far, it's the only field value that has this asymmetric
usage and meaning.
I should have put some references. The explanation of the modes, with a
temporal representation of the fields. Small note, in ALTERNATE mode
bottom and top fields will likely not share the same timestamp, it is a
mode used to achieve lower latency.
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/field-order.html#c.v4l2_field
And in this section, you'll see a paragraph that explain the field
values when running in ALTERNATE mode.
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/buffer.html#c.v4l2_buffer
Ok, thanks for clarifying. I suppose it makes sense that this mode
should not
be seen as sequential, since it represents a mode where each userspace
buffer
is a single, self-contained field. I'll remove ALTERNATE from the helper
macro.
Steve
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
On 26.05.2018 19:18, Laurent Pinchart wrote: > On Saturday, 26 May 2018 19:16:54 EEST Laurent Pinchart wrote: >> Hi Dimitri, > > And sorry for the spelling mistake :-/ That's also a kinda correct spelling. No worries ;)
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
On 26.05.2018 19:16, Laurent Pinchart wrote: > Hi Dimitri, > > Thank you for the patch. > > I'll review this in details, but as this patch is based on the "[PATCH/RFC > 1/4] drm: Add colorkey properties" patch I've submitted, please retain the > authorship, both in the Signed-off-by line, and in the patch author in git. Okay. /I think/ I've seen requests to do the other way around for the picked up and re-worked patches, though I don't mind at all to keep your authorship. I'll change the authorship in the next iteration. Waiting for you review comments, thanks.
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
On Saturday, 26 May 2018 19:16:54 EEST Laurent Pinchart wrote:
> Hi Dimitri,
And sorry for the spelling mistake :-/
> Thank you for the patch.
>
> I'll review this in details, but as this patch is based on the "[PATCH/RFC
> 1/4] drm: Add colorkey properties" patch I've submitted, please retain the
> authorship, both in the Signed-off-by line, and in the patch author in git.
>
> On Saturday, 26 May 2018 18:56:22 EEST Dmitry Osipenko wrote:
> > Color keying is the action of replacing pixels matching a given color
> > (or range of colors) with transparent pixels in an overlay when
> > performing blitting. Depending on the hardware capabilities, the
> > matching pixel can either become fully transparent or gain adjustment
> > of the pixels component values.
> >
> > Color keying is found in a large number of devices whose capabilities
> > often differ, but they still have enough common features in range to
> > standardize color key properties. This commit adds nine generic DRM plane
> > properties related to the color keying to cover various HW capabilities.
> >
> > This patch is based on the initial work done by Laurent Pinchart, most of
> > credits for this patch goes to him.
> >
> > Signed-off-by: Dmitry Osipenko
> > ---
> >
> > drivers/gpu/drm/drm_atomic.c | 36 ++
> > drivers/gpu/drm/drm_blend.c | 229 +++
> > include/drm/drm_blend.h | 3 +
> > include/drm/drm_plane.h | 77
> > 4 files changed, 345 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 895741e9cd7d..5b808cb68654 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -799,6 +799,24 @@ static int drm_atomic_plane_set_property(struct
> > drm_plane *plane, state->rotation = val;
> >
> > } else if (property == plane->zpos_property) {
> >
> > state->zpos = val;
> >
> > + } else if (property == plane->colorkey.mode_property) {
> > + state->colorkey.mode = val;
> > + } else if (property == plane->colorkey.min_property) {
> > + state->colorkey.min = val;
> > + } else if (property == plane->colorkey.max_property) {
> > + state->colorkey.max = val;
> > + } else if (property == plane->colorkey.format_property) {
> > + state->colorkey.format = val;
> > + } else if (property == plane->colorkey.mask_property) {
> > + state->colorkey.mask = val;
> > + } else if (property == plane->colorkey.inverted_match_property) {
> > + state->colorkey.inverted_match = val;
> > + } else if (property == plane->colorkey.replacement_mask_property) {
> > + state->colorkey.replacement_mask = val;
> > + } else if (property == plane->colorkey.replacement_value_property) {
> > + state->colorkey.replacement_value = val;
> > + } else if (property == plane->colorkey.replacement_format_property) {
> > + state->colorkey.replacement_format = val;
> >
> > } else if (property == plane->color_encoding_property) {
> >
> > state->color_encoding = val;
> >
> > } else if (property == plane->color_range_property) {
> >
> > @@ -864,6 +882,24 @@ drm_atomic_plane_get_property(struct drm_plane
> > *plane,
> >
> > *val = state->rotation;
> >
> > } else if (property == plane->zpos_property) {
> >
> > *val = state->zpos;
> >
> > + } else if (property == plane->colorkey.mode_property) {
> > + *val = state->colorkey.mode;
> > + } else if (property == plane->colorkey.min_property) {
> > + *val = state->colorkey.min;
> > + } else if (property == plane->colorkey.max_property) {
> > + *val = state->colorkey.max;
> > + } else if (property == plane->colorkey.format_property) {
> > + *val = state->colorkey.format;
> > + } else if (property == plane->colorkey.mask_property) {
> > + *val = state->colorkey.mask;
> > + } else if (property == plane->colorkey.inverted_match_property) {
> > + *val = state->colorkey.inverted_match;
> > + } else if (property == plane->colorkey.replacement_mask_property) {
> > + *val = state->colorkey.replacement_mask;
> > + } else if (property == plane->colorkey.replacement_value_property) {
> > + *val = state->colorkey.replacement_value;
> > + } else if (property == plane->colorkey.replacement_format_property) {
> > + *val = state->colorkey.replacement_format;
> >
> > } else if (property == plane->color_encoding_property) {
> >
> > *val = state->color_encoding;
> >
> > } else if (property == plane->color_range_property) {
> >
> > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > index a16a74d7e15e..05e5632ce375 100644
> > --- a/drivers/gpu/drm/drm_blend.c
> > +++ b/drivers/gpu/drm/drm_blend.c
> > @@ -107,6 +107,11 @@
> >
> > * planes. Without this property th
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
Hi Dimitri,
Thank you for the patch.
I'll review this in details, but as this patch is based on the "[PATCH/RFC
1/4] drm: Add colorkey properties" patch I've submitted, please retain the
authorship, both in the Signed-off-by line, and in the patch author in git.
On Saturday, 26 May 2018 18:56:22 EEST Dmitry Osipenko wrote:
> Color keying is the action of replacing pixels matching a given color
> (or range of colors) with transparent pixels in an overlay when
> performing blitting. Depending on the hardware capabilities, the
> matching pixel can either become fully transparent or gain adjustment
> of the pixels component values.
>
> Color keying is found in a large number of devices whose capabilities
> often differ, but they still have enough common features in range to
> standardize color key properties. This commit adds nine generic DRM plane
> properties related to the color keying to cover various HW capabilities.
>
> This patch is based on the initial work done by Laurent Pinchart, most of
> credits for this patch goes to him.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_atomic.c | 36 ++
> drivers/gpu/drm/drm_blend.c | 229 +++
> include/drm/drm_blend.h | 3 +
> include/drm/drm_plane.h | 77
> 4 files changed, 345 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 895741e9cd7d..5b808cb68654 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -799,6 +799,24 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane, state->rotation = val;
> } else if (property == plane->zpos_property) {
> state->zpos = val;
> + } else if (property == plane->colorkey.mode_property) {
> + state->colorkey.mode = val;
> + } else if (property == plane->colorkey.min_property) {
> + state->colorkey.min = val;
> + } else if (property == plane->colorkey.max_property) {
> + state->colorkey.max = val;
> + } else if (property == plane->colorkey.format_property) {
> + state->colorkey.format = val;
> + } else if (property == plane->colorkey.mask_property) {
> + state->colorkey.mask = val;
> + } else if (property == plane->colorkey.inverted_match_property) {
> + state->colorkey.inverted_match = val;
> + } else if (property == plane->colorkey.replacement_mask_property) {
> + state->colorkey.replacement_mask = val;
> + } else if (property == plane->colorkey.replacement_value_property) {
> + state->colorkey.replacement_value = val;
> + } else if (property == plane->colorkey.replacement_format_property) {
> + state->colorkey.replacement_format = val;
> } else if (property == plane->color_encoding_property) {
> state->color_encoding = val;
> } else if (property == plane->color_range_property) {
> @@ -864,6 +882,24 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> *val = state->rotation;
> } else if (property == plane->zpos_property) {
> *val = state->zpos;
> + } else if (property == plane->colorkey.mode_property) {
> + *val = state->colorkey.mode;
> + } else if (property == plane->colorkey.min_property) {
> + *val = state->colorkey.min;
> + } else if (property == plane->colorkey.max_property) {
> + *val = state->colorkey.max;
> + } else if (property == plane->colorkey.format_property) {
> + *val = state->colorkey.format;
> + } else if (property == plane->colorkey.mask_property) {
> + *val = state->colorkey.mask;
> + } else if (property == plane->colorkey.inverted_match_property) {
> + *val = state->colorkey.inverted_match;
> + } else if (property == plane->colorkey.replacement_mask_property) {
> + *val = state->colorkey.replacement_mask;
> + } else if (property == plane->colorkey.replacement_value_property) {
> + *val = state->colorkey.replacement_value;
> + } else if (property == plane->colorkey.replacement_format_property) {
> + *val = state->colorkey.replacement_format;
> } else if (property == plane->color_encoding_property) {
> *val = state->color_encoding;
> } else if (property == plane->color_range_property) {
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index a16a74d7e15e..05e5632ce375 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -107,6 +107,11 @@
> * planes. Without this property the primary plane is always below the
> cursor * plane, and ordering between all other planes is undefined.
> *
> + * colorkey:
> + * Color keying is set up with drm_plane_create_colorkey_properties().
> + * It adds support for replacing a range of colors with a transparent
> + * color in t
[RFC PATCH v2 1/2] drm: Add generic colorkey properties
Color keying is the action of replacing pixels matching a given color
(or range of colors) with transparent pixels in an overlay when
performing blitting. Depending on the hardware capabilities, the
matching pixel can either become fully transparent or gain adjustment
of the pixels component values.
Color keying is found in a large number of devices whose capabilities
often differ, but they still have enough common features in range to
standardize color key properties. This commit adds nine generic DRM plane
properties related to the color keying to cover various HW capabilities.
This patch is based on the initial work done by Laurent Pinchart, most of
credits for this patch goes to him.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_atomic.c | 36 ++
drivers/gpu/drm/drm_blend.c | 229 +++
include/drm/drm_blend.h | 3 +
include/drm/drm_plane.h | 77
4 files changed, 345 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 895741e9cd7d..5b808cb68654 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -799,6 +799,24 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
state->rotation = val;
} else if (property == plane->zpos_property) {
state->zpos = val;
+ } else if (property == plane->colorkey.mode_property) {
+ state->colorkey.mode = val;
+ } else if (property == plane->colorkey.min_property) {
+ state->colorkey.min = val;
+ } else if (property == plane->colorkey.max_property) {
+ state->colorkey.max = val;
+ } else if (property == plane->colorkey.format_property) {
+ state->colorkey.format = val;
+ } else if (property == plane->colorkey.mask_property) {
+ state->colorkey.mask = val;
+ } else if (property == plane->colorkey.inverted_match_property) {
+ state->colorkey.inverted_match = val;
+ } else if (property == plane->colorkey.replacement_mask_property) {
+ state->colorkey.replacement_mask = val;
+ } else if (property == plane->colorkey.replacement_value_property) {
+ state->colorkey.replacement_value = val;
+ } else if (property == plane->colorkey.replacement_format_property) {
+ state->colorkey.replacement_format = val;
} else if (property == plane->color_encoding_property) {
state->color_encoding = val;
} else if (property == plane->color_range_property) {
@@ -864,6 +882,24 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->rotation;
} else if (property == plane->zpos_property) {
*val = state->zpos;
+ } else if (property == plane->colorkey.mode_property) {
+ *val = state->colorkey.mode;
+ } else if (property == plane->colorkey.min_property) {
+ *val = state->colorkey.min;
+ } else if (property == plane->colorkey.max_property) {
+ *val = state->colorkey.max;
+ } else if (property == plane->colorkey.format_property) {
+ *val = state->colorkey.format;
+ } else if (property == plane->colorkey.mask_property) {
+ *val = state->colorkey.mask;
+ } else if (property == plane->colorkey.inverted_match_property) {
+ *val = state->colorkey.inverted_match;
+ } else if (property == plane->colorkey.replacement_mask_property) {
+ *val = state->colorkey.replacement_mask;
+ } else if (property == plane->colorkey.replacement_value_property) {
+ *val = state->colorkey.replacement_value;
+ } else if (property == plane->colorkey.replacement_format_property) {
+ *val = state->colorkey.replacement_format;
} else if (property == plane->color_encoding_property) {
*val = state->color_encoding;
} else if (property == plane->color_range_property) {
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index a16a74d7e15e..05e5632ce375 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -107,6 +107,11 @@
* planes. Without this property the primary plane is always below the
cursor
* plane, and ordering between all other planes is undefined.
*
+ * colorkey:
+ * Color keying is set up with drm_plane_create_colorkey_properties().
+ * It adds support for replacing a range of colors with a transparent
+ * color in the plane.
+ *
* Note that all the property extensions described here apply either to the
* plane or the CRTC (e.g. for the background color, which currently is not
* exposed and assumed to be black).
@@ -448,3 +453,227 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
return 0;
}
EXPORT_SYMBOL(drm_atomic_normalize_zpos);
+
+static const char * const plane_colo
[RFC PATCH v2 0/2] Implement standard color keying properties for DRM planes
Hello, DRM maintainers! Laurent Pinchart kindly agreed to allow me to pick up his work on the generic colorkey DRM plane property [0]. I've reworked the original patch a tad, hopefully making it flexible enough to cover various HW capabilities. Changes I've made: - Some code clean up and reshuffle. - Took into account some the Ville's Syrjälä review comments to [0]. - The number of common DRM colorkey properties grows from 4 to 9. New properties: - colorkey.mask - colorkey.format - colorkey.inverted-match - colorkey.replacement-mask - colorkey.replacement-format Renamed properties: - colorkey.value -> colorkey.replacement-value - colorkey.mode userspace-property ENUM's got a bit more explicit names, like "src" -> "src-match-src-replace". - No driver-specific modes / properties allowed, all unsupported features are simply rejected by the drivers. This patchset includes initial colorkey property implementation for the older NVIDIA Tegra's. Please review, thanks. [0] https://lists.freedesktop.org/archives/dri-devel/2017-December/160510.html Dmitry Osipenko (2): drm: Add generic colorkey properties drm/tegra: plane: Implement generic colorkey property for older Tegra's drivers/gpu/drm/drm_atomic.c | 36 ++ drivers/gpu/drm/drm_blend.c | 229 ++ drivers/gpu/drm/tegra/dc.c| 31 + drivers/gpu/drm/tegra/dc.h| 7 ++ drivers/gpu/drm/tegra/plane.c | 147 ++ drivers/gpu/drm/tegra/plane.h | 1 + include/drm/drm_blend.h | 3 + include/drm/drm_plane.h | 77 8 files changed, 531 insertions(+) -- 2.17.0
[RFC PATCH v2 2/2] drm/tegra: plane: Implement generic colorkey property for older Tegra's
Color keying allows to draw on top of overlapping planes, like for
example on top of a video plane. Older Tegra's have a limited color
keying capability, such that blending features are reduced when color
keying is enabled. In particular dependent weighting isn't possible,
meaning that cursors plane can't be displayed properly. In most cases
it is more useful to display content on top of video overlay, so
sacrificing mouse cursor in the area of three planes intersection with
colorkey mismatch is a reasonable tradeoff.
This patch implements the generic DRM colorkey property. For the starter
a minimal color keying support is implemented, it is enough to provide
userspace like Opentegra Xorg driver with ability to support color keying
by the XVideo extension.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/dc.c| 31 +++
drivers/gpu/drm/tegra/dc.h| 7 ++
drivers/gpu/drm/tegra/plane.c | 147 ++
drivers/gpu/drm/tegra/plane.h | 1 +
4 files changed, 186 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 31e12a9dfcb8..a5add64e40e2 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -172,6 +172,11 @@ static void tegra_plane_setup_blending_legacy(struct
tegra_plane *plane)
state = to_tegra_plane_state(plane->base.state);
+ if (state->ckey_enabled) {
+ background[0] |= BLEND_COLOR_KEY_0;
+ background[2] |= BLEND_COLOR_KEY_0;
+ }
+
if (state->opaque) {
/*
* Since custom fix-weight blending isn't utilized and weight
@@ -776,6 +781,11 @@ static struct drm_plane *tegra_primary_plane_create(struct
drm_device *drm,
drm_plane_helper_add(&plane->base, &tegra_plane_helper_funcs);
drm_plane_create_zpos_property(&plane->base, plane->index, 0, 255);
+ if (dc->soc->has_legacy_blending)
+ drm_plane_create_colorkey_properties(&plane->base,
+ BIT(DRM_PLANE_COLORKEY_MODE_DISABLED) |
+ BIT(DRM_PLANE_COLORKEY_MODE_DST));
+
return &plane->base;
}
@@ -1053,6 +1063,11 @@ static struct drm_plane
*tegra_dc_overlay_plane_create(struct drm_device *drm,
drm_plane_helper_add(&plane->base, &tegra_plane_helper_funcs);
drm_plane_create_zpos_property(&plane->base, plane->index, 0, 255);
+ if (dc->soc->has_legacy_blending)
+ drm_plane_create_colorkey_properties(&plane->base,
+ BIT(DRM_PLANE_COLORKEY_MODE_DISABLED) |
+ BIT(DRM_PLANE_COLORKEY_MODE_DST));
+
return &plane->base;
}
@@ -1153,6 +1168,7 @@ tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
{
struct tegra_dc_state *state = to_dc_state(crtc->state);
struct tegra_dc_state *copy;
+ unsigned int i;
copy = kmalloc(sizeof(*copy), GFP_KERNEL);
if (!copy)
@@ -1164,6 +1180,9 @@ tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
copy->div = state->div;
copy->planes = state->planes;
+ for (i = 0; i < 2; i++)
+ copy->ckey[i] = state->ckey[i];
+
return ©->base;
}
@@ -1893,6 +1912,18 @@ static void tegra_crtc_atomic_flush(struct drm_crtc
*crtc,
struct tegra_dc *dc = to_tegra_dc(crtc);
u32 value;
+ if (dc->soc->has_legacy_blending) {
+ tegra_dc_writel(dc,
+ state->ckey[0].lower, DC_DISP_COLOR_KEY0_LOWER);
+ tegra_dc_writel(dc,
+ state->ckey[0].upper, DC_DISP_COLOR_KEY0_UPPER);
+
+ tegra_dc_writel(dc,
+ state->ckey[1].lower, DC_DISP_COLOR_KEY1_LOWER);
+ tegra_dc_writel(dc,
+ state->ckey[1].upper, DC_DISP_COLOR_KEY1_UPPER);
+ }
+
value = state->planes << 8 | GENERAL_UPDATE;
tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
value = tegra_dc_readl(dc, DC_CMD_STATE_CONTROL);
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
index e96f582ca692..8209cb7d598a 100644
--- a/drivers/gpu/drm/tegra/dc.h
+++ b/drivers/gpu/drm/tegra/dc.h
@@ -18,6 +18,11 @@
struct tegra_output;
+struct tegra_dc_color_key_state {
+ u32 lower;
+ u32 upper;
+};
+
struct tegra_dc_state {
struct drm_crtc_state base;
@@ -26,6 +31,8 @@ struct tegra_dc_state {
unsigned int div;
u32 planes;
+
+ struct tegra_dc_color_key_state ckey[2];
};
static inline struct tegra_dc_state *to_dc_state(struct drm_crtc_state *state)
diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
index 0406c2ef432c..ba08b66d2499 100644
--- a/drivers/gpu/drm/tegra/plane.c
+++ b/drivers/gpu/drm/tegra/plane.c
@@ -57,6 +57,7 @@ tegra_plane_atomic_duplicate_state(struct drm_plane *plane)
co
Re: [SIL2review] [PATCH] media: tc358743: release device_node in tc358743_probe_of()
On Sat, May 26, 2018 at 12:54:00AM +0300, Alexey Khoroshilov wrote:
> of_graph_get_next_endpoint() returns device_node with refcnt increased,
> but these is no of_node_put() for it.
I think this is correct - but would it not be simpler to do
endpoint = v4l2_fwnode_endpoint_alloc_parse(of_fwnode_handle(ep));
of_node_put(ep);
if (IS_ERR(endpoint)) {
As the of_node_put(np) actually is unconditional anyway I think this
should be semantically equivalent.
>
> The patch adds one on error and normal paths.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
Reviewed-by: Nicholas Mc Guire
> ---
> drivers/media/i2c/tc358743.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
> index 393baad7..44c41933415a 100644
> --- a/drivers/media/i2c/tc358743.c
> +++ b/drivers/media/i2c/tc358743.c
> @@ -1918,7 +1918,8 @@ static int tc358743_probe_of(struct tc358743_state
> *state)
> endpoint = v4l2_fwnode_endpoint_alloc_parse(of_fwnode_handle(ep));
> if (IS_ERR(endpoint)) {
> dev_err(dev, "failed to parse endpoint\n");
> - return PTR_ERR(endpoint);
> + ret = PTR_ERR(endpoint);
> + goto put_node;
> }
>
> if (endpoint->bus_type != V4L2_MBUS_CSI2 ||
> @@ -2013,6 +2014,8 @@ static int tc358743_probe_of(struct tc358743_state
> *state)
> clk_disable_unprepare(refclk);
> free_endpoint:
> v4l2_fwnode_endpoint_free(endpoint);
> +put_node:
> + of_node_put(ep);
> return ret;
> }
> #else
> --
> 2.7.4
>
> ___
> SIL2review mailing list
> sil2rev...@lists.osadl.org
> https://lists.osadl.org/mailman/listinfo/sil2review
[PATCH v1] media: dt: bindings: tegra-vde: Document new optional Memory Client reset property
Recently binding of the Memory Controller has been extended, exposing
the Memory Client reset controls and hence it is now a reset controller.
Tegra video-decoder device is among the Memory Controller reset users,
document the new optional VDE HW reset property.
Signed-off-by: Dmitry Osipenko
---
.../devicetree/bindings/media/nvidia,tegra-vde.txt| 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt
b/Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt
index 470237ed6fe5..7302e949e662 100644
--- a/Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt
+++ b/Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt
@@ -27,9 +27,15 @@ Required properties:
- sxe
- clocks : Must include the following entries:
- vde
-- resets : Must include the following entries:
+- resets : Must contain an entry for each entry in reset-names.
+- reset-names : Should include the following entries:
- vde
+Optional properties:
+- resets : Must contain an entry for each entry in reset-names.
+- reset-names : Must include the following entries:
+ - mc
+
Example:
video-codec@6001a000 {
@@ -51,5 +57,6 @@ video-codec@6001a000 {
; /* SXE interrupt */
interrupt-names = "sync-token", "bsev", "sxe";
clocks = <&tegra_car TEGRA20_CLK_VDE>;
- resets = <&tegra_car 61>;
+ reset-names = "vde", "mc";
+ resets = <&tegra_car 61>, <&mc TEGRA20_MC_RESET_VDE>;
};
--
2.17.0
[PATCH v2] media: staging: tegra-vde: Reset memory client
DMA requests must be blocked before resetting VDE HW, otherwise it is
possible to get a memory corruption or a machine hang. Use the reset
control provided by the Memory Controller to block DMA before resetting
the VDE HW.
Signed-off-by: Dmitry Osipenko
---
Changelog:
v2:
- Reset HW even if Memory Client resetting fails.
drivers/staging/media/tegra-vde/tegra-vde.c | 35 +++--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/tegra-vde/tegra-vde.c
b/drivers/staging/media/tegra-vde/tegra-vde.c
index 90177a59b97c..6f06061a40d9 100644
--- a/drivers/staging/media/tegra-vde/tegra-vde.c
+++ b/drivers/staging/media/tegra-vde/tegra-vde.c
@@ -73,6 +73,7 @@ struct tegra_vde {
struct mutex lock;
struct miscdevice miscdev;
struct reset_control *rst;
+ struct reset_control *rst_mc;
struct gen_pool *iram_pool;
struct completion decode_completion;
struct clk *clk;
@@ -850,9 +851,23 @@ static int tegra_vde_ioctl_decode_h264(struct tegra_vde
*vde,
* We rely on the VDE registers reset value, otherwise VDE
* causes bus lockup.
*/
+ ret = reset_control_assert(vde->rst_mc);
+ if (ret) {
+ dev_err(dev, "DEC start: Failed to assert MC reset: %d\n",
+ ret);
+ goto put_runtime_pm;
+ }
+
ret = reset_control_reset(vde->rst);
if (ret) {
- dev_err(dev, "Failed to reset HW: %d\n", ret);
+ dev_err(dev, "DEC start: Failed to reset HW: %d\n", ret);
+ goto put_runtime_pm;
+ }
+
+ ret = reset_control_deassert(vde->rst_mc);
+ if (ret) {
+ dev_err(dev, "DEC start: Failed to deassert MC reset: %d\n",
+ ret);
goto put_runtime_pm;
}
@@ -880,9 +895,18 @@ static int tegra_vde_ioctl_decode_h264(struct tegra_vde
*vde,
ret = timeout;
}
+ /*
+* At first reset memory client to avoid resetting VDE HW in the
+* middle of DMA which could result into memory corruption or hang
+* the whole system.
+*/
+ err = reset_control_assert(vde->rst_mc);
+ if (err)
+ dev_err(dev, "DEC end: Failed to assert MC reset: %d\n", err);
+
err = reset_control_assert(vde->rst);
if (err)
- dev_err(dev, "Failed to assert HW reset: %d\n", err);
+ dev_err(dev, "DEC end: Failed to assert HW reset: %d\n", err);
put_runtime_pm:
pm_runtime_mark_last_busy(dev);
@@ -1074,6 +1098,13 @@ static int tegra_vde_probe(struct platform_device *pdev)
return err;
}
+ vde->rst_mc = devm_reset_control_get_optional(dev, "mc");
+ if (IS_ERR(vde->rst_mc)) {
+ err = PTR_ERR(vde->rst_mc);
+ dev_err(dev, "Could not get MC reset %d\n", err);
+ return err;
+ }
+
irq = platform_get_irq_byname(pdev, "sync-token");
if (irq < 0)
return irq;
--
2.17.0
[PATCH] media: mtk-vpu: fix spelling mistake: "Prosessor" -> "Processor"
From: Colin Ian King
Trivial fix to spelling mistake in module description text.
Signed-off-by: Colin Ian King
---
drivers/media/platform/mtk-vpu/mtk_vpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c
b/drivers/media/platform/mtk-vpu/mtk_vpu.c
index 1ff6a93262b7..f8d35e3ac1dc 100644
--- a/drivers/media/platform/mtk-vpu/mtk_vpu.c
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
@@ -960,4 +960,4 @@ static struct platform_driver mtk_vpu_driver = {
module_platform_driver(mtk_vpu_driver);
MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("Mediatek Video Prosessor Unit driver");
+MODULE_DESCRIPTION("Mediatek Video Processor Unit driver");
--
2.17.0
Re: [PATCH v4 2/3] media: rc: introduce BPF_PROG_LIRC_MODE2
On Fri, May 25, 2018 at 01:45:11PM -0700, Alexei Starovoitov wrote:
> On Fri, May 18, 2018 at 03:07:29PM +0100, Sean Young wrote:
> > Add support for BPF_PROG_LIRC_MODE2. This type of BPF program can call
> > rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report
> > that the last key should be repeated.
> >
> > The bpf program can be attached to using the bpf(BPF_PROG_ATTACH) syscall;
> > the target_fd must be the /dev/lircN device.
> >
> > Signed-off-by: Sean Young
> ...
> > enum bpf_attach_type {
> > @@ -158,6 +159,7 @@ enum bpf_attach_type {
> > BPF_CGROUP_INET6_CONNECT,
> > BPF_CGROUP_INET4_POST_BIND,
> > BPF_CGROUP_INET6_POST_BIND,
> > + BPF_LIRC_MODE2,
> > __MAX_BPF_ATTACH_TYPE
> > };
> >
> > @@ -1902,6 +1904,53 @@ union bpf_attr {
> > * egress otherwise). This is the only flag supported for now.
> > * Return
> > * **SK_PASS** on success, or **SK_DROP** on error.
> > + *
> > + * int bpf_rc_keydown(void *ctx, u32 protocol, u64 scancode, u32 toggle)
> > + * Description
> > + * This helper is used in programs implementing IR decoding, to
> > + * report a successfully decoded key press with *scancode*,
> > + * *toggle* value in the given *protocol*. The scancode will be
> > + * translated to a keycode using the rc keymap, and reported as
> > + * an input key down event. After a period a key up event is
> > + * generated. This period can be extended by calling either
> > + * **bpf_rc_keydown** () with the same values, or calling
> > + * **bpf_rc_repeat** ().
> > + *
> > + * Some protocols include a toggle bit, in case the button
> > + * was released and pressed again between consecutive scancodes
> > + *
> > + * The *ctx* should point to the lirc sample as passed into
> > + * the program.
> > + *
> > + * The *protocol* is the decoded protocol number (see
> > + * **enum rc_proto** for some predefined values).
> > + *
> > + * This helper is only available is the kernel was compiled with
> > + * the **CONFIG_BPF_LIRC_MODE2** configuration option set to
> > + * "**y**".
> > + *
> > + * Return
> > + * 0
> > + *
> > + * int bpf_rc_repeat(void *ctx)
> > + * Description
> > + * This helper is used in programs implementing IR decoding, to
> > + * report a successfully decoded repeat key message. This delays
> > + * the generation of a key up event for previously generated
> > + * key down event.
> > + *
> > + * Some IR protocols like NEC have a special IR message for
> > + * repeating last button, for when a button is held down.
> > + *
> > + * The *ctx* should point to the lirc sample as passed into
> > + * the program.
> > + *
> > + * This helper is only available is the kernel was compiled with
> > + * the **CONFIG_BPF_LIRC_MODE2** configuration option set to
> > + * "**y**".
>
> Hi Sean,
>
> thank you for working on this. The patch set looks good to me.
> I'd only ask to change above two helper names to something more specific.
> Since BPF_PROG_TYPE_LIRC_MODE2 is the name of new prog type and kconfig.
> May be bpf_lirc2_keydown() and bpf_lirc2_repeat() ?
A little history might help here.
lirc and rc-core have non-obvious meanings. So, lirc was the original project
that dealt with IR. That project was rejected from mainline because it did
not send translated keycodes to input devices (it exposed its own interface
for keypresses).
Then rc-core was written which maps IR scancodes to keycodes (using rc
keymaps) and sends them to the input layer. The original lirc userspace ABI
for receiving and sending raw IR pulses and spaces was retained (mode2 as
it was called in lirc).
Reusing parts of the lirc ABI for BPF decoding raw IR makes sense, however
dispatching decoded scancodes was never part of lirc, only rc-core. In fact,
rc-core is reused in hdmi-cec for cec commands, which does not use lirc
at all. So for example, if we want to process cec messages in bpf, it would
want call rc_keydown().
I don't think this lirc/rc-core duality is particularly great, but I'm
not sure what the right answer to that is.
> > @@ -1576,6 +1577,8 @@ static int bpf_prog_attach(const union bpf_attr *attr)
> > case BPF_SK_SKB_STREAM_PARSER:
> > case BPF_SK_SKB_STREAM_VERDICT:
> > return sockmap_get_from_fd(attr, BPF_PROG_TYPE_SK_SKB, true);
> > + case BPF_LIRC_MODE2:
> > + return rc_dev_prog_attach(attr);
> ...
> > + case BPF_LIRC_MODE2:
> > + return rc_dev_prog_detach(attr);
>
> and similar rename for internal function names that go into bpf core.
I agree with this.
> Please add accumulated acks when you respin.
Good point, will do.
Thanks,
Sean
Re: [GIT PULL FOR v4.18] R-Car VSP1 TLB optimisation
Em Sat, 26 May 2018 03:24:00 +0300
Laurent Pinchart escreveu:
> Hi Mauro,
>
> On Saturday, 26 May 2018 02:39:16 EEST Laurent Pinchart wrote:
> > On Saturday, 26 May 2018 02:10:27 EEST Mauro Carvalho Chehab wrote:
> > > Em Sun, 20 May 2018 15:10:50 +0300 Laurent Pinchart escreveu:
> > >> Hi Mauro,
> > >>
> > >> The following changes since commit
> > >>
> > >> 8ed8bba70b4355b1ba029b151ade84475dd12991:
> > >> media: imx274: remove non-indexed pointers from mode_table (2018-05-17
> > >>
> > >> 06:22:08 -0400)
> > >>
> > >> are available in the Git repository at:
> > >> git://linuxtv.org/pinchartl/media.git v4l2/vsp1/next
> > >>
> > >> for you to fetch changes up to 429f256501652c90a4ed82f2416618f82a77d37c:
> > >> media: vsp1: Move video configuration to a cached dlb (2018-05-20
> > >> 09:46:51 +0300)
> > >>
> > >> The branch passes the VSP and DU test suites, both on its own and when
> > >> merged with the drm-next branch.
> > >
> > > This series added a new warning:
> > >
> > > drivers/media/platform/vsp1/vsp1_dl.c:69: warning: Function parameter or
> > > member 'refcnt' not described in 'vsp1_dl_body'
> >
> > We'll fix that. Kieran, as you authored the code, would you like to give it
> > a go ?
> >
> > > To the already existing one:
> > >
> > > drivers/media/platform/vsp1/vsp1_drm.c:336 vsp1_du_pipeline_setup_brx()
> > > error: we previously assumed 'pipe->brx' could be null (see line 244)
> >
> > That's still on my todo list. I tried to give it a go but received plenty of
> > SQL errors. How do you run smatch ?
>
> Nevermind, I found out what was wrong (had to specify the data directory
> manually).
>
> I've reproduced the issue and created a minimal test case.
>
> 1. struct vsp1_pipeline;
> 2.
> 3. struct vsp1_entity {
> 4. struct vsp1_pipeline *pipe;
> 5. struct vsp1_entity *sink;
> 6. unsigned int source_pad;
> 7. };
> 8.
> 9. struct vsp1_pipeline {
> 10. struct vsp1_entity *brx;
> 11. };
> 12.
> 13. struct vsp1_brx {
> 14. struct vsp1_entity entity;
> 15. };
> 16.
> 17. struct vsp1_device {
> 18. struct vsp1_brx *bru;
> 19. struct vsp1_brx *brs;
> 20. };
> 21.
> 22. unsigned int frob(struct vsp1_device *vsp1, struct vsp1_pipeline *pipe)
> 23. {
> 24. struct vsp1_entity *brx;
> 25.
> 26. if (pipe->brx)
> 27. brx = pipe->brx;
> 28. else if (!vsp1->bru->entity.pipe)
> 29. brx = &vsp1->bru->entity;
> 30. else
> 31. brx = &vsp1->brs->entity;
> 32.
> 33. if (brx != pipe->brx)
> 34. pipe->brx = brx;
> 35.
> 36. return pipe->brx->source_pad;
> 37. }
>
> The reason why smatch complains is that it has no guarantee that vsp1->brs is
> not NULL. It's quite tricky:
>
> - On line 26, smatch assumes that pipe->brx can be NULL
> - On line 27, brx is assigned a non-NULL value (as pipe->brx is not NULL due
> to line 26)
> - On line 28, smatch assumes that vsp1->bru is not NULL
> - On line 29, brx is assigned a non-NULL value (as vsp1->bru is not NULL due
> to line 28)
> - On line 31, brx is assigned a possibly NULL value (as there's no
> information
> regarding vsp1->brs)
> - On line 34, pipe->brx is not assigned a non-NULL value if brx is NULL
> - On line 36 pipe->brx is dereferenced
>
> The problem comes from the fact that smatch assumes that vsp1->brs isn't
> NULL.
> Adding a "(void)vsp1->brs->entity;" statement on line 25 makes the warning
> disappear.
>
> So how do we know that vsp1->brs isn't NULL in the original code ?
>
> if (pipe->num_inputs > 2)
> brx = &vsp1->bru->entity;
> else if (pipe->brx && !drm_pipe->force_brx_release)
> brx = pipe->brx;
> else if (!vsp1->bru->entity.pipe)
> brx = &vsp1->bru->entity;
> else
> brx = &vsp1->brs->entity;
>
> A VSP1 instance can have no brs, so in general vsp1->brs can be NULL.
> However,
> when that's the case, the following conditions are fulfilled.
>
> - drm_pipe->force_brx_release will be false
> - either pipe->brx will be non-NULL, or vsp1->bru->entity.pipe will be NULL
>
> The fourth branch should thus never be taken.
I don't think that adding a forth branch there would solve.
The thing is that Smatch knows that pipe->brx can be NULL, as the function
explicly checks if pipe->brx != NULL.
When Smatch handles this if:
if (brx != pipe->brx) {
It wrongly assumes that this could be false if pipe->brx is NULL.
I don't know why, as Smatch should know that brx can't be NULL.
On such case, the next code to be executed would be:
format.pad = pipe->brx->source_pad;
With would be trying to de-ref a NULL pointer.
There are two ways to fix it:
1) with my patch.
It is based to the fact that, if pipe->brx is null, then brx won't be
NULL. So, the logic that "Switch BRx if needed." will always be called:
diff --git a/driver
Re: [PATCH v1] media: staging: tegra-vde: Reset memory client
On 20.05.2018 16:48, Dmitry Osipenko wrote:
> DMA requests must be blocked before resetting VDE HW, otherwise it is
> possible to get a memory corruption or a machine hang. Use the reset
> control provided by the Memory Controller to block DMA before resetting
> the VDE HW.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/staging/media/tegra-vde/tegra-vde.c | 42 +++--
> 1 file changed, 38 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/media/tegra-vde/tegra-vde.c
> b/drivers/staging/media/tegra-vde/tegra-vde.c
> index 90177a59b97c..6dd3bf4481be 100644
> --- a/drivers/staging/media/tegra-vde/tegra-vde.c
> +++ b/drivers/staging/media/tegra-vde/tegra-vde.c
> @@ -73,6 +73,7 @@ struct tegra_vde {
> struct mutex lock;
> struct miscdevice miscdev;
> struct reset_control *rst;
> + struct reset_control *rst_mc;
> struct gen_pool *iram_pool;
> struct completion decode_completion;
> struct clk *clk;
> @@ -850,9 +851,23 @@ static int tegra_vde_ioctl_decode_h264(struct tegra_vde
> *vde,
>* We rely on the VDE registers reset value, otherwise VDE
>* causes bus lockup.
>*/
> + ret = reset_control_assert(vde->rst_mc);
> + if (ret) {
> + dev_err(dev, "DEC start: Failed to assert MC reset: %d\n",
> + ret);
> + goto put_runtime_pm;
> + }
> +
> ret = reset_control_reset(vde->rst);
> if (ret) {
> - dev_err(dev, "Failed to reset HW: %d\n", ret);
> + dev_err(dev, "DEC start: Failed to reset HW: %d\n", ret);
> + goto put_runtime_pm;
> + }
> +
> + ret = reset_control_deassert(vde->rst_mc);
> + if (ret) {
> + dev_err(dev, "DEC start: Failed to deassert MC reset: %d\n",
> + ret);
> goto put_runtime_pm;
> }
>
> @@ -880,9 +895,21 @@ static int tegra_vde_ioctl_decode_h264(struct tegra_vde
> *vde,
> ret = timeout;
> }
>
> - err = reset_control_assert(vde->rst);
> - if (err)
> - dev_err(dev, "Failed to assert HW reset: %d\n", err);
> + /*
> + * At first reset memory client to avoid resetting VDE HW in the
> + * middle of DMA which could result into memory corruption or hang
> + * the whole system.
> + */
> + err = reset_control_assert(vde->rst_mc);
> + if (!err) {
It occurred to me that there is no need to skip the HW reset if MC resetting
fails. I'll make V2 to change that.
> + err = reset_control_assert(vde->rst);
> + if (err)
> + dev_err(dev,
> + "DEC end: Failed to assert HW reset: %d\n",
> + err);
> + } else {
> + dev_err(dev, "DEC end: Failed to assert MC reset: %d\n", err);
> + }
>
> put_runtime_pm:
> pm_runtime_mark_last_busy(dev);
> @@ -1074,6 +1101,13 @@ static int tegra_vde_probe(struct platform_device
> *pdev)
> return err;
> }
>
> + vde->rst_mc = devm_reset_control_get_optional(dev, "mc");
> + if (IS_ERR(vde->rst_mc)) {
> + err = PTR_ERR(vde->rst_mc);
> + dev_err(dev, "Could not get MC reset %d\n", err);
> + return err;
> + }
> +
> irq = platform_get_irq_byname(pdev, "sync-token");
> if (irq < 0)
> return irq;
>
Re: qcom: add firmware file for Venus on SDM845
Hi Josh, On 2018-05-25 17:34, Josh Boyer wrote: On Fri, May 25, 2018 at 7:03 AM Vikash Garodia wrote: This pull request adds firmware files for Venus h/w codec found on the Qualcomm SDM845 chipset. The following changes since commit 2a9b2cf50fb32e36e4fc1586c2f6f1421913b553: Merge branch 'for-upstreaming-v1.7.2' of https://github.com/felix-cavium/linux-firmware (2018-05-18 08:35:22 -0400) are available in the git repository at: https://github.com/vgarodia/linux-firmware master for you to fetch changes up to d6088b9c9d7f49d3c6c43681190889eca0abdcce: qcom: add venus firmware files for v5.2 (2018-05-25 15:16:43 +0530) Vikash Garodia (1): qcom: add venus firmware files for v5.2 WHENCE | 9 + qcom/venus-5.2/venus.b00 | Bin 0 -> 212 bytes qcom/venus-5.2/venus.b01 | Bin 0 -> 6600 bytes qcom/venus-5.2/venus.b02 | Bin 0 -> 819552 bytes qcom/venus-5.2/venus.b03 | Bin 0 -> 33536 bytes qcom/venus-5.2/venus.b04 | 1 + qcom/venus-5.2/venus.mbn | Bin 0 -> 865408 bytes qcom/venus-5.2/venus.mdt | Bin 0 -> 6812 bytes 8 files changed, 10 insertions(+) create mode 100644 qcom/venus-5.2/venus.b00 create mode 100644 qcom/venus-5.2/venus.b01 create mode 100644 qcom/venus-5.2/venus.b02 create mode 100644 qcom/venus-5.2/venus.b03 create mode 100644 qcom/venus-5.2/venus.b04 create mode 100644 qcom/venus-5.2/venus.mbn create mode 100644 qcom/venus-5.2/venus.mdt The venus.mbn file isn't mentioned in WHENCE: [jwboyer@vader linux-firmware]$ ./check_whence.py E: qcom/venus-5.2/venus.mbn not listed in WHENCE [jwboyer@vader linux-firmware]$ Can you fix that up and let me know when to re-pull? I have fixed the error and is ready to be re-pulled from the same git repository. I have noted the process to run check_whence.py before uploading the firmwares. Do i need to resend the pull request as the end commit is now changed to 7602644358157e4b89960472b6d59ffcc040ca52 ? -Vikash
