Re: [PATCH 3/4] [media] s5p-jpeg: don't return a random width/height
W dniu 18.05.2017 o 16:06, Mauro Carvalho Chehab pisze:
Gcc 7.1 complains about:
drivers/media/platform/s5p-jpeg/jpeg-core.c: In function
's5p_jpeg_parse_hdr.isra.9':
drivers/media/platform/s5p-jpeg/jpeg-core.c:1207:12: warning: 'width' may be
used uninitialized in this function [-Wmaybe-uninitialized]
result->w = width;
~~^~~
drivers/media/platform/s5p-jpeg/jpeg-core.c:1208:12: warning: 'height' may be
used uninitialized in this function [-Wmaybe-uninitialized]
result->h = height;
~~^~~~
Indeed the code would allow it to return a random value (although
it shouldn't happen, in practice). So, explicitly set both to zero,
just in case.
Signed-off-by: Mauro Carvalho Chehab
Acked-by: Andrzej Pietrasiewicz
---
drivers/media/platform/s5p-jpeg/jpeg-core.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 52dc7941db65..1da2c94e1dca 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -1099,10 +1099,10 @@ static bool s5p_jpeg_parse_hdr(struct s5p_jpeg_q_data
*result,
struct s5p_jpeg_ctx *ctx)
{
int c, components = 0, notfound, n_dht = 0, n_dqt = 0;
- unsigned int height, width, word, subsampling = 0, sos = 0, sof = 0,
-sof_len = 0;
- unsigned int dht[S5P_JPEG_MAX_MARKER], dht_len[S5P_JPEG_MAX_MARKER],
-dqt[S5P_JPEG_MAX_MARKER], dqt_len[S5P_JPEG_MAX_MARKER];
+ unsigned int height = 0, width = 0, word, subsampling = 0;
+ unsigned int sos = 0, sof = 0, sof_len = 0;
+ unsigned int dht[S5P_JPEG_MAX_MARKER], dht_len[S5P_JPEG_MAX_MARKER];
+ unsigned int dqt[S5P_JPEG_MAX_MARKER], dqt_len[S5P_JPEG_MAX_MARKER];
long length;
struct s5p_jpeg_buffer jpeg_buffer;
Re: [RFC] V4L2 unified low-level decoder API
Hi all,
Here is the latest st-delta MPEG2 code:
[PATCH v6 0/3] Add support for MPEG-2 in DELTA video decoder
http://www.mail-archive.com/linux-media@vger.kernel.org/msg112067.html
[PATCH v2 0/3] Add a libv4l plugin for video bitstream parsing
http://www.mail-archive.com/linux-media@vger.kernel.org/msg112076.html
Before merging this work Hans would like to have feedback from peers, in
order to be sure that this is inline with other SoC vendors drivers
expectations.
Thomasz, Pawel, could you give your view regarding ChromeOS and Rockchip
driver ?
Laurent, could you give your view regarding Renesas driver ?
I have also added in appendice [7] the materials presented by Laurent at
ELC 2017 in Portland to introduce stateless video codecs and V4L2
request API, thanks for this presentation Laurent.
Best regards,
Hugues.
> On 02/07/2017 08:21 AM, Hugues FRUCHET wrote:
> Hi,
>
> Here is an update regarding MPEG-2 implementation based on ST video decoder:
> * MPEG-2 API + DELTA kernel driver:
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg107405.html
> * libv4l-codecparsers plugin including MPEG-2 back-end:
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg107812.html
>
> Please note that this is implemented & functional using currently available
> V4L2 control framework (no Request API), assuming that user side keeps
> unicity of S_EXT_CTRL() / QBUF(OUTPUT) pair.
> Request API will remove this constraint, but the point here is to define
> control interface, as far as I have understood code, Request API will not
> affect those control definitions.
>
> Some updates inline thereafter regarding activities on this subject; me for
> MPEG-2 on ST platform and Randy Li, Nicolas Dufresne, Ayaka for H264 on
> Rockchip platform:
>
>
> On 11/14/2016 10:55 AM, Hans Verkuil wrote:
>> On 10/27/2016 09:42 AM, Hugues FRUCHET wrote:
>>> Hi,
>>>
>>> This RFC aims to start discussions in order to define the codec
>>> specific controls structures to fulfill the low-level decoder API
>>> needed by non "Stream API" based decoders ("stateless" or "Frame API" based
>>> decoders).
>>
>> Let's refer to this as 'stateful' decoders and 'stateless' decoders.
>> This is the preferred terminology (and much more descriptive than
>> 'Stream' vs 'Frame'). It's also not really a new API, although it does
>> rely on the Request API.
>>
>>> Several implementation exists now which runs on several SoC and
>>> various software frameworks.
>>> The idea is to find the communalities between all those
>>> implementations and SoC to define a single unified interface in V4L2
>>> includes.
>>> Even if "Request API" is needed to pass those codec specific controls
>>> from userspace down to kernel on a per-buffer basis, we can start
>>> discussions and define the controls in parallel of its development.
>>> We can even propose some implementations based on existing V4L2
>>> control framework (which doesn't support "per-frame" basis) by
>>> ensuring atomicity of sequence S_EXT_CTRL(header[i])/QBUF(stream[i]).
>>> Constraint can then be relaxed when "Request API" is merged.
>>>
>>> I would like to propose to work on a "per-codec" basis, having at
>>> least
>>> 2 different SoC and 2 different frameworks to test and validate controls.
>>> To do so, I have tried to identify some people that have worked on
>>> this subject and have proposed some implementations, feel free to
>>> correct me and enhance the list if needed:
>>> * MPEG2/MPEG4
>>> - Florent Revest for Allwinner A13 CedarX support [1] tested with
>>> VLC -> libVA + sunxi-cedrus-drv-video -> V4L2
>>> - Myself for STMicroelectronics Delta support [2] tested with
>>> GStreamer V4L2 -> libv4l2 + libv4l-delta plugin -> V4L2
> Available on ST platform with [2] & [2.1] patchset series.
>
>>>
>>> * VP8
>>> - Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [3] tested
>>> with Chromium -> V4L2
>>> - Jung Zhao for Rockchip RK3288 VPU support [4] >> framework used>
>>>
>>> * H264
>>> - Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [5] tested
>>> with Chromium -> V4L2
>>> - Randy Li for Rockchip RK3288 VPU support [6] tested with VLC? ->
>>> libVA + rockchip-va-driver -> V4L2 VLC? -> libVDPAU +
>>> rockchip-va-driver -> V4L2
> Tested with Gstreamer -> VA-API element -> Rockchip VA-API driver -> V4L2
> https://github.com/rockchip-linux/libvdpau-rockchip
>
> Study on-going for H264 userland/kernel partitioning in this thread:
> Request API: stateless VPU: the buffer mechanism and DPB management:
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg107165.html
>
>>>
>>> I can work to define MPEG2/MPEG4 controls and propose functional
>>> implementations for those codecs, and will be glad to co-work with
>>> you Florent.
>>> I can help on H264 on a code review basis based on the functional
>>> H264 setup I have in-house and codec knowledge, but I cannot provide
>>> implementation in a reasonable timeframe, same for VP8.
>>>
>>> Apart of ve
Re: [RFC] V4L2 unified low-level decoder API
On 05/19/2017 04:08 PM, Hugues FRUCHET wrote:
Hi all,
Here is the latest st-delta MPEG2 code:
[PATCH v6 0/3] Add support for MPEG-2 in DELTA video decoder
http://www.mail-archive.com/linux-media@vger.kernel.org/msg112067.html
[PATCH v2 0/3] Add a libv4l plugin for video bitstream parsing
http://www.mail-archive.com/linux-media@vger.kernel.org/msg112076.html
I would review it.
Before merging this work Hans would like to have feedback from peers, in
order to be sure that this is inline with other SoC vendors drivers
expectations.
Thomasz, Pawel, could you give your view regarding ChromeOS and Rockchip
driver ?
The work of the rockchip just re-start a few weeks age, I have just
finished the driver probing type as I decide to make a clean beginning.
The video IP of the rockchip is too complext with a different combine.
The pixel format will begin in JPEG then AVC. I am now more familiar
with those codec now.
Laurent, could you give your view regarding Renesas driver ?
I have also added in appendice [7] the materials presented by Laurent at
ELC 2017 in Portland to introduce stateless video codecs and V4L2
request API, thanks for this presentation Laurent.
Best regards,
Hugues.
On 02/07/2017 08:21 AM, Hugues FRUCHET wrote:
Hi,
Here is an update regarding MPEG-2 implementation based on ST video decoder:
* MPEG-2 API + DELTA kernel driver:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg107405.html
* libv4l-codecparsers plugin including MPEG-2 back-end:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg107812.html
Please note that this is implemented & functional using currently available
V4L2 control framework (no Request API), assuming that user side keeps unicity of
S_EXT_CTRL() / QBUF(OUTPUT) pair.
Request API will remove this constraint, but the point here is to define
control interface, as far as I have understood code, Request API will not
affect those control definitions.
Some updates inline thereafter regarding activities on this subject; me for
MPEG-2 on ST platform and Randy Li, Nicolas Dufresne, Ayaka for H264 on
Rockchip platform:
On 11/14/2016 10:55 AM, Hans Verkuil wrote:
On 10/27/2016 09:42 AM, Hugues FRUCHET wrote:
Hi,
This RFC aims to start discussions in order to define the codec
specific controls structures to fulfill the low-level decoder API
needed by non "Stream API" based decoders ("stateless" or "Frame API" based
decoders).
Let's refer to this as 'stateful' decoders and 'stateless' decoders.
This is the preferred terminology (and much more descriptive than
'Stream' vs 'Frame'). It's also not really a new API, although it does
rely on the Request API.
Several implementation exists now which runs on several SoC and
various software frameworks.
The idea is to find the communalities between all those
implementations and SoC to define a single unified interface in V4L2 includes.
Even if "Request API" is needed to pass those codec specific controls
from userspace down to kernel on a per-buffer basis, we can start
discussions and define the controls in parallel of its development.
We can even propose some implementations based on existing V4L2
control framework (which doesn't support "per-frame" basis) by
ensuring atomicity of sequence S_EXT_CTRL(header[i])/QBUF(stream[i]).
Constraint can then be relaxed when "Request API" is merged.
I would like to propose to work on a "per-codec" basis, having at
least
2 different SoC and 2 different frameworks to test and validate controls.
To do so, I have tried to identify some people that have worked on
this subject and have proposed some implementations, feel free to
correct me and enhance the list if needed:
* MPEG2/MPEG4
- Florent Revest for Allwinner A13 CedarX support [1] tested with
VLC -> libVA + sunxi-cedrus-drv-video -> V4L2
- Myself for STMicroelectronics Delta support [2] tested with
GStreamer V4L2 -> libv4l2 + libv4l-delta plugin -> V4L2
Available on ST platform with [2] & [2.1] patchset series.
* VP8
- Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [3] tested
with Chromium -> V4L2
- Jung Zhao for Rockchip RK3288 VPU support [4]
* H264
- Pawel Osciak for Rockchip RK3288, RK3399? VPU Support [5] tested
with Chromium -> V4L2
- Randy Li for Rockchip RK3288 VPU support [6] tested with VLC? ->
libVA + rockchip-va-driver -> V4L2 VLC? -> libVDPAU +
rockchip-va-driver -> V4L2
Tested with Gstreamer -> VA-API element -> Rockchip VA-API driver -> V4L2
https://github.com/rockchip-linux/libvdpau-rockchip
Study on-going for H264 userland/kernel partitioning in this thread:
Request API: stateless VPU: the buffer mechanism and DPB management:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg107165.html
I can work to define MPEG2/MPEG4 controls and propose functional
implementations for those codecs, and will be glad to co-work with
you Florent.
I can help on H264 on a code review basis based on the functional
H264 setup I have in-house and codec knowledge, but
[libv4l]: How to do 10-bit support? Stand-alone conversions?
Hi!
> I much rather do this as part of a longer series that actually adds 10 bit
> support.
> The problem is that adding support for 10 bit doesn't mean you can just use
> LSIZE
> all the time since you still need support for 8 bit as well.
Heh. I was afraid to hear that. I can probably support 10-bits for
white balance somehow.
How would complete support for 10-bits work? Introduce RGB48 and
modify processing to work in 16-bits?
And the big question: is it possible to do processing with
libv4lconvert, without actually have v4l device available?
For example... I do have a simple camera application. In a viewfinder
mode, it has to work at GRBG10 format, because any conversion is just
too slow. We'd also want to save raw GRBG10 image to disk for raw
processing. So far so good. But we'd also want to save jpeg, which
means converting existing buffer to RGB24, applying white balance (and
maybe bad-pixel, lens shading, vignetting compensation) and saving
jpeg.
I'm trying to use this for conversion:
static void convert_rgb(struct dev_info *dev, struct v4l2_format sfmt, void
*buf, struct v4l2_f\
ormat dfmt, void *buf2, int wb)
{
struct v4lconvert_data *data = v4lconvert_create(dev->fd);
int res;
printf("Converting first.");
if (wb) {
struct v4l2_control ctrl;
ctrl.id = V4L2_CID_AUTO_WHITE_BALANCE;
ctrl.value = 1;
v4lconvert_vidioc_s_ctrl(data, &ctrl);
}
res = v4lconvert_convert(data, &sfmt, &dfmt, buf, SIZE, buf2, SIZE);
printf("Converting: %d\n", res);
v4lconvert_destroy(data);
}
but
1) it feels like improper use of internal functions.
2) it crashes when I attempt to do white balance processing.
Is there an interface I could use? Should I create interface for
v4lconvert_ for this kind of processing? Any preferences how it should
look like?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
[PATCH v1] ATMEL ISI code cleanup
Here is a bunch of small fixes found when upstreaming the ST DCMI driver based on ATMEL ISI driver. Review remarks can be found here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg112338.html: - Ensure that ISI is clocked before starting sensor sub device. - Remove un-needed type check in try_fmt(). - Use clamp() macro for ISC hardware capabilities. - Fix wrong tabulation to space. Please note that this was not tested on a real hardware, only compiled in x86 environment to check build. Hugues Fruchet (1): [media] atmel-isi: code cleanup drivers/media/platform/atmel/atmel-isi.c | 24 ++-- 1 file changed, 10 insertions(+), 14 deletions(-) -- 1.9.1
[PATCH v1] [media] atmel-isi: code cleanup
Ensure that ISI is clocked before starting sensor sub device.
Remove un-needed type check in try_fmt().
Use clamp() macro for hardware capabilities.
Fix wrong tabulation to space.
Signed-off-by: Hugues Fruchet
---
drivers/media/platform/atmel/atmel-isi.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/media/platform/atmel/atmel-isi.c
b/drivers/media/platform/atmel/atmel-isi.c
index e4867f8..7bf9f7d 100644
--- a/drivers/media/platform/atmel/atmel-isi.c
+++ b/drivers/media/platform/atmel/atmel-isi.c
@@ -36,8 +36,8 @@
#include "atmel-isi.h"
-#define MAX_SUPPORT_WIDTH 2048
-#define MAX_SUPPORT_HEIGHT 2048
+#define MAX_SUPPORT_WIDTH 2048U
+#define MAX_SUPPORT_HEIGHT 2048U
#define MIN_FRAME_RATE 15
#define FRAME_INTERVAL_MILLI_SEC (1000 / MIN_FRAME_RATE)
@@ -424,6 +424,8 @@ static int start_streaming(struct vb2_queue *vq, unsigned
int count)
struct frame_buffer *buf, *node;
int ret;
+ pm_runtime_get_sync(isi->dev);
+
/* Enable stream on the sub device */
ret = v4l2_subdev_call(isi->entity.subdev, video, s_stream, 1);
if (ret && ret != -ENOIOCTLCMD) {
@@ -431,8 +433,6 @@ static int start_streaming(struct vb2_queue *vq, unsigned
int count)
goto err_start_stream;
}
- pm_runtime_get_sync(isi->dev);
-
/* Reset ISI */
ret = atmel_isi_wait_status(isi, WAIT_ISI_RESET);
if (ret < 0) {
@@ -455,10 +455,11 @@ static int start_streaming(struct vb2_queue *vq, unsigned
int count)
return 0;
err_reset:
- pm_runtime_put(isi->dev);
v4l2_subdev_call(isi->entity.subdev, video, s_stream, 0);
err_start_stream:
+ pm_runtime_put(isi->dev);
+
spin_lock_irq(&isi->irqlock);
isi->active = NULL;
/* Release all active buffers */
@@ -566,20 +567,15 @@ static int isi_try_fmt(struct atmel_isi *isi, struct
v4l2_format *f,
};
int ret;
- if (f->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
- return -EINVAL;
-
isi_fmt = find_format_by_fourcc(isi, pixfmt->pixelformat);
if (!isi_fmt) {
isi_fmt = isi->user_formats[isi->num_user_formats - 1];
pixfmt->pixelformat = isi_fmt->fourcc;
}
- /* Limit to Atmel ISC hardware capabilities */
- if (pixfmt->width > MAX_SUPPORT_WIDTH)
- pixfmt->width = MAX_SUPPORT_WIDTH;
- if (pixfmt->height > MAX_SUPPORT_HEIGHT)
- pixfmt->height = MAX_SUPPORT_HEIGHT;
+ /* Limit to Atmel ISI hardware capabilities */
+ pixfmt->width = clamp(pixfmt->width, 0U, MAX_SUPPORT_WIDTH);
+ pixfmt->height = clamp(pixfmt->height, 0U, MAX_SUPPORT_HEIGHT);
v4l2_fill_mbus_format(&format.format, pixfmt, isi_fmt->mbus_code);
ret = v4l2_subdev_call(isi->entity.subdev, pad, set_fmt,
@@ -1058,7 +1054,7 @@ static int isi_graph_notify_complete(struct
v4l2_async_notifier *notifier)
struct atmel_isi *isi = notifier_to_isi(notifier);
int ret;
- isi->vdev->ctrl_handler = isi->entity.subdev->ctrl_handler;
+ isi->vdev->ctrl_handler = isi->entity.subdev->ctrl_handler;
ret = isi_formats_init(isi);
if (ret) {
dev_err(isi->dev, "No supported mediabus format found\n");
--
1.9.1
[PATCH] [media] atomisp: disable several warnings when W=1
The atomisp currently produce hundreds of warnings when W=1. It is a known fact that this driver is currently in bad shape, and there are lot of things to be done here. We don't want to be bothered by those "minor" stuff for now, while the driver doesn't receive a major cleanup. So, disable those warnings. Signed-off-by: Mauro Carvalho Chehab --- drivers/staging/media/atomisp/i2c/Makefile | 4 drivers/staging/media/atomisp/i2c/imx/Makefile | 5 + drivers/staging/media/atomisp/i2c/ov5693/Makefile | 5 + drivers/staging/media/atomisp/pci/atomisp2/Makefile | 5 + 4 files changed, 19 insertions(+) diff --git a/drivers/staging/media/atomisp/i2c/Makefile b/drivers/staging/media/atomisp/i2c/Makefile index 466517c7c8e6..a1afca6ec31f 100644 --- a/drivers/staging/media/atomisp/i2c/Makefile +++ b/drivers/staging/media/atomisp/i2c/Makefile @@ -19,3 +19,7 @@ obj-$(CONFIG_VIDEO_AP1302) += ap1302.o obj-$(CONFIG_VIDEO_LM3554) += lm3554.o +# HACK! While this driver is in bad shape, don't enable several warnings +# that would be otherwise enabled with W=1 +ccflags-y += -Wno-unused-but-set-variable -Wno-missing-prototypes \ +-Wno-unused-const-variable -Wno-missing-declarations diff --git a/drivers/staging/media/atomisp/i2c/imx/Makefile b/drivers/staging/media/atomisp/i2c/imx/Makefile index 6b13a3a66e49..0eceb7374bec 100644 --- a/drivers/staging/media/atomisp/i2c/imx/Makefile +++ b/drivers/staging/media/atomisp/i2c/imx/Makefile @@ -4,3 +4,8 @@ imx1x5-objs := imx.o drv201.o ad5816g.o dw9714.o dw9719.o dw9718.o vcm.o otp.o o ov8858_driver-objs := ../ov8858.o dw9718.o vcm.o obj-$(CONFIG_VIDEO_OV8858) += ov8858_driver.o + +# HACK! While this driver is in bad shape, don't enable several warnings +# that would be otherwise enabled with W=1 +ccflags-y += -Wno-unused-but-set-variable -Wno-missing-prototypes \ + -Wno-unused-const-variable -Wno-missing-declarations diff --git a/drivers/staging/media/atomisp/i2c/ov5693/Makefile b/drivers/staging/media/atomisp/i2c/ov5693/Makefile index c9c0e1245858..fd2ef2e3c31e 100644 --- a/drivers/staging/media/atomisp/i2c/ov5693/Makefile +++ b/drivers/staging/media/atomisp/i2c/ov5693/Makefile @@ -1 +1,6 @@ obj-$(CONFIG_VIDEO_OV5693) += ov5693.o + +# HACK! While this driver is in bad shape, don't enable several warnings +# that would be otherwise enabled with W=1 +ccflags-y += -Wno-unused-but-set-variable -Wno-missing-prototypes \ + -Wno-unused-const-variable -Wno-missing-declarations diff --git a/drivers/staging/media/atomisp/pci/atomisp2/Makefile b/drivers/staging/media/atomisp/pci/atomisp2/Makefile index f126a89a08e9..8ccb5f29f2c1 100644 --- a/drivers/staging/media/atomisp/pci/atomisp2/Makefile +++ b/drivers/staging/media/atomisp/pci/atomisp2/Makefile @@ -353,3 +353,8 @@ DEFINES += -DSYSTEM_hive_isp_css_2400_system -DISP2400 ccflags-y += $(INCLUDES) $(DEFINES) -fno-common +# HACK! While this driver is in bad shape, don't enable several warnings +# that would be otherwise enabled with W=1 +ccflags-y += -Wno-unused-const-variable -Wno-missing-prototypes \ +-Wno-unused-but-set-variable -Wno-missing-declarations \ +-Wno-suggest-attribute=format -Wno-missing-prototypes -- 2.9.3
Re: [PATCH 00/13] staging: media: atomisp queued up patches
Em Thu, 18 May 2017 17:40:27 +0100 Alan Cox escreveu: > On Thu, 2017-05-18 at 11:10 -0300, Mauro Carvalho Chehab wrote: > > Em Thu, 18 May 2017 15:50:09 +0200 > > Greg Kroah-Hartman escreveu: > > > > > > > > Hi Mauro, > > > > > > Here's the set of accumulated atomisp staging patches that I had in > > > my > > > to-review mailbox. After this, my queue is empty, the driver is > > > all > > > yours! > > > > Thanks! > > > > Alan, please let me know if you prefer if I don't apply any of > > such patches, otherwise I should be merging them tomorrow ;) > > I will assume you've merged them and resync the internal patch queue I > have here to that. Merged, thanks! I'll also merge a patch I just sent with disables several warnings that W=1 would otherwise turn on. They indicate real issues there, but, as you pointed, there are much more important tasks to to than to try fixing those warnings. > At the moment I'm still slowly trying to unthread > some of the fascinating layers of indirection without actually breaking > anything. I don't envy you trying to get some sense out of it ;-) Good luck! Thanks, Mauro
Re: [PATCH v1] ATMEL ISI code cleanup
Adding Songjun and Ludovic as Atmel maintainers, sorry for inconvenience. On 05/19/2017 12:04 PM, Hugues Fruchet wrote: > Here is a bunch of small fixes found when upstreaming > the ST DCMI driver based on ATMEL ISI driver. > > Review remarks can be found here: > http://www.mail-archive.com/linux-media@vger.kernel.org/msg112338.html: > - Ensure that ISI is clocked before starting sensor sub device. > - Remove un-needed type check in try_fmt(). > - Use clamp() macro for ISC hardware capabilities. > - Fix wrong tabulation to space. > > Please note that this was not tested on a real hardware, > only compiled in x86 environment to check build. > > Hugues Fruchet (1): >[media] atmel-isi: code cleanup > > drivers/media/platform/atmel/atmel-isi.c | 24 ++-- > 1 file changed, 10 insertions(+), 14 deletions(-) >
Re: [PATCH v1] [media] atmel-isi: code cleanup
Adding Songjun and Ludovic as Atmel maintainers, sorry for inconvenience.
On 05/19/2017 12:04 PM, Hugues Fruchet wrote:
> Ensure that ISI is clocked before starting sensor sub device.
> Remove un-needed type check in try_fmt().
> Use clamp() macro for hardware capabilities.
> Fix wrong tabulation to space.
>
> Signed-off-by: Hugues Fruchet
> ---
> drivers/media/platform/atmel/atmel-isi.c | 24 ++--
> 1 file changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/media/platform/atmel/atmel-isi.c
> b/drivers/media/platform/atmel/atmel-isi.c
> index e4867f8..7bf9f7d 100644
> --- a/drivers/media/platform/atmel/atmel-isi.c
> +++ b/drivers/media/platform/atmel/atmel-isi.c
> @@ -36,8 +36,8 @@
>
> #include "atmel-isi.h"
>
> -#define MAX_SUPPORT_WIDTH2048
> -#define MAX_SUPPORT_HEIGHT 2048
> +#define MAX_SUPPORT_WIDTH2048U
> +#define MAX_SUPPORT_HEIGHT 2048U
> #define MIN_FRAME_RATE 15
> #define FRAME_INTERVAL_MILLI_SEC(1000 / MIN_FRAME_RATE)
>
> @@ -424,6 +424,8 @@ static int start_streaming(struct vb2_queue *vq, unsigned
> int count)
> struct frame_buffer *buf, *node;
> int ret;
>
> + pm_runtime_get_sync(isi->dev);
> +
> /* Enable stream on the sub device */
> ret = v4l2_subdev_call(isi->entity.subdev, video, s_stream, 1);
> if (ret && ret != -ENOIOCTLCMD) {
> @@ -431,8 +433,6 @@ static int start_streaming(struct vb2_queue *vq, unsigned
> int count)
> goto err_start_stream;
> }
>
> - pm_runtime_get_sync(isi->dev);
> -
> /* Reset ISI */
> ret = atmel_isi_wait_status(isi, WAIT_ISI_RESET);
> if (ret < 0) {
> @@ -455,10 +455,11 @@ static int start_streaming(struct vb2_queue *vq,
> unsigned int count)
> return 0;
>
> err_reset:
> - pm_runtime_put(isi->dev);
> v4l2_subdev_call(isi->entity.subdev, video, s_stream, 0);
>
> err_start_stream:
> + pm_runtime_put(isi->dev);
> +
> spin_lock_irq(&isi->irqlock);
> isi->active = NULL;
> /* Release all active buffers */
> @@ -566,20 +567,15 @@ static int isi_try_fmt(struct atmel_isi *isi, struct
> v4l2_format *f,
> };
> int ret;
>
> - if (f->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
> - return -EINVAL;
> -
> isi_fmt = find_format_by_fourcc(isi, pixfmt->pixelformat);
> if (!isi_fmt) {
> isi_fmt = isi->user_formats[isi->num_user_formats - 1];
> pixfmt->pixelformat = isi_fmt->fourcc;
> }
>
> - /* Limit to Atmel ISC hardware capabilities */
> - if (pixfmt->width > MAX_SUPPORT_WIDTH)
> - pixfmt->width = MAX_SUPPORT_WIDTH;
> - if (pixfmt->height > MAX_SUPPORT_HEIGHT)
> - pixfmt->height = MAX_SUPPORT_HEIGHT;
> + /* Limit to Atmel ISI hardware capabilities */
> + pixfmt->width = clamp(pixfmt->width, 0U, MAX_SUPPORT_WIDTH);
> + pixfmt->height = clamp(pixfmt->height, 0U, MAX_SUPPORT_HEIGHT);
>
> v4l2_fill_mbus_format(&format.format, pixfmt, isi_fmt->mbus_code);
> ret = v4l2_subdev_call(isi->entity.subdev, pad, set_fmt,
> @@ -1058,7 +1054,7 @@ static int isi_graph_notify_complete(struct
> v4l2_async_notifier *notifier)
> struct atmel_isi *isi = notifier_to_isi(notifier);
> int ret;
>
> - isi->vdev->ctrl_handler = isi->entity.subdev->ctrl_handler;
> + isi->vdev->ctrl_handler = isi->entity.subdev->ctrl_handler;
> ret = isi_formats_init(isi);
> if (ret) {
> dev_err(isi->dev, "No supported mediabus format found\n");
>
[PATCH 6/6] [media] uvcvideo: annotate a switch fall through
Without annotations, gcc 7.1 will complain. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/usb/uvc/uvc_video.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c index a29f39d4e05b..fb86d6af398d 100644 --- a/drivers/media/usb/uvc/uvc_video.c +++ b/drivers/media/usb/uvc/uvc_video.c @@ -1323,7 +1323,7 @@ static void uvc_video_complete(struct urb *urb) default: uvc_printk(KERN_WARNING, "Non-zero status (%d) in video " "completion handler.\n", urb->status); - + /* fall through */ case -ENOENT: /* usb_kill_urb() called. */ if (stream->frozen) return; -- 2.9.3
[PATCH 4/6] [media] soc_camera: annotate a switch fall through
Clearly, hsync and vsinc bool vars are part of the return logic on the second case of the switch. Annotate that, in order to shut up gcc warnings. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/platform/soc_camera/soc_mediabus.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/soc_camera/soc_mediabus.c b/drivers/media/platform/soc_camera/soc_mediabus.c index e3e665e1c503..57581f626f4c 100644 --- a/drivers/media/platform/soc_camera/soc_mediabus.c +++ b/drivers/media/platform/soc_camera/soc_mediabus.c @@ -494,6 +494,7 @@ unsigned int soc_mbus_config_compatible(const struct v4l2_mbus_config *cfg, V4L2_MBUS_HSYNC_ACTIVE_LOW); vsync = common_flags & (V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_VSYNC_ACTIVE_LOW); + /* fall through */ case V4L2_MBUS_BT656: pclk = common_flags & (V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_PCLK_SAMPLE_FALLING); -- 2.9.3
[PATCH 5/6] [media] s2255drv: avoid a switch fall through
On this driver, it can fall through a switch. I tried to
annotate it, in order to shut up a gcc warning, but that
didn't work, as the logic there is somewhat complex.
So, instead, let's just repeat the code. gcc should likely
optimize it anyway, and this makes the code better readable,
IMHO.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/usb/s2255/s2255drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/usb/s2255/s2255drv.c
b/drivers/media/usb/s2255/s2255drv.c
index a9d4484f7626..6a88b1dbb3a0 100644
--- a/drivers/media/usb/s2255/s2255drv.c
+++ b/drivers/media/usb/s2255/s2255drv.c
@@ -1803,6 +1803,8 @@ static int save_frame(struct s2255_dev *dev, struct
s2255_pipeinfo *pipe_info)
default:
pr_info("s2255 unknown resp\n");
}
+ pdata++;
+ break;
default:
pdata++;
break;
--
2.9.3
[PATCH 3/6] [media] zoran: annotate switch fall through
There are two cases here that it does a switch fall through. Annotate it, in order to shut up gcc warnings. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/pci/zoran/zoran_driver.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/pci/zoran/zoran_driver.c b/drivers/media/pci/zoran/zoran_driver.c index 180f3d7af3e1..a11cb501c550 100644 --- a/drivers/media/pci/zoran/zoran_driver.c +++ b/drivers/media/pci/zoran/zoran_driver.c @@ -534,6 +534,7 @@ static int zoran_v4l_queue_frame(struct zoran_fh *fh, int num) KERN_WARNING "%s: %s - queueing buffer %d in state DONE!?\n", ZR_DEVNAME(zr), __func__, num); + /* fall through */ case BUZ_STATE_USER: /* since there is at least one unused buffer there's room for at least * one more pend[] entry */ @@ -693,6 +694,7 @@ static int zoran_jpg_queue_frame(struct zoran_fh *fh, int num, KERN_WARNING "%s: %s - queing frame in BUZ_STATE_DONE state!?\n", ZR_DEVNAME(zr), __func__); + /* fall through */ case BUZ_STATE_USER: /* since there is at least one unused buffer there's room for at *least one more pend[] entry */ -- 2.9.3
[PATCH v2 1/6] [media] atomisp: disable several warnings when W=1
The atomisp currently produce hundreds of warnings when W=1. It is a known fact that this driver is currently in bad shape, and there are lot of things to be done here. We don't want to be bothered by those "minor" stuff for now, while the driver doesn't receive a major cleanup. So, disable those warnings. Signed-off-by: Mauro Carvalho Chehab --- drivers/staging/media/atomisp/i2c/Makefile | 4 drivers/staging/media/atomisp/i2c/imx/Makefile | 5 + drivers/staging/media/atomisp/i2c/ov5693/Makefile | 5 + drivers/staging/media/atomisp/pci/atomisp2/Makefile | 6 ++ 4 files changed, 20 insertions(+) diff --git a/drivers/staging/media/atomisp/i2c/Makefile b/drivers/staging/media/atomisp/i2c/Makefile index 466517c7c8e6..a1afca6ec31f 100644 --- a/drivers/staging/media/atomisp/i2c/Makefile +++ b/drivers/staging/media/atomisp/i2c/Makefile @@ -19,3 +19,7 @@ obj-$(CONFIG_VIDEO_AP1302) += ap1302.o obj-$(CONFIG_VIDEO_LM3554) += lm3554.o +# HACK! While this driver is in bad shape, don't enable several warnings +# that would be otherwise enabled with W=1 +ccflags-y += -Wno-unused-but-set-variable -Wno-missing-prototypes \ +-Wno-unused-const-variable -Wno-missing-declarations diff --git a/drivers/staging/media/atomisp/i2c/imx/Makefile b/drivers/staging/media/atomisp/i2c/imx/Makefile index 6b13a3a66e49..0eceb7374bec 100644 --- a/drivers/staging/media/atomisp/i2c/imx/Makefile +++ b/drivers/staging/media/atomisp/i2c/imx/Makefile @@ -4,3 +4,8 @@ imx1x5-objs := imx.o drv201.o ad5816g.o dw9714.o dw9719.o dw9718.o vcm.o otp.o o ov8858_driver-objs := ../ov8858.o dw9718.o vcm.o obj-$(CONFIG_VIDEO_OV8858) += ov8858_driver.o + +# HACK! While this driver is in bad shape, don't enable several warnings +# that would be otherwise enabled with W=1 +ccflags-y += -Wno-unused-but-set-variable -Wno-missing-prototypes \ + -Wno-unused-const-variable -Wno-missing-declarations diff --git a/drivers/staging/media/atomisp/i2c/ov5693/Makefile b/drivers/staging/media/atomisp/i2c/ov5693/Makefile index c9c0e1245858..fd2ef2e3c31e 100644 --- a/drivers/staging/media/atomisp/i2c/ov5693/Makefile +++ b/drivers/staging/media/atomisp/i2c/ov5693/Makefile @@ -1 +1,6 @@ obj-$(CONFIG_VIDEO_OV5693) += ov5693.o + +# HACK! While this driver is in bad shape, don't enable several warnings +# that would be otherwise enabled with W=1 +ccflags-y += -Wno-unused-but-set-variable -Wno-missing-prototypes \ + -Wno-unused-const-variable -Wno-missing-declarations diff --git a/drivers/staging/media/atomisp/pci/atomisp2/Makefile b/drivers/staging/media/atomisp/pci/atomisp2/Makefile index f126a89a08e9..68a9ab1c3b61 100644 --- a/drivers/staging/media/atomisp/pci/atomisp2/Makefile +++ b/drivers/staging/media/atomisp/pci/atomisp2/Makefile @@ -353,3 +353,9 @@ DEFINES += -DSYSTEM_hive_isp_css_2400_system -DISP2400 ccflags-y += $(INCLUDES) $(DEFINES) -fno-common +# HACK! While this driver is in bad shape, don't enable several warnings +# that would be otherwise enabled with W=1 +ccflags-y += -Wno-unused-const-variable -Wno-missing-prototypes \ +-Wno-unused-but-set-variable -Wno-missing-declarations \ +-Wno-suggest-attribute=format -Wno-missing-prototypes \ +-Wno-implicit-fallthrough -- 2.9.3
[PATCH 2/6] [media] av7110: avoid switch fall through
On two switches, this driver have unannotated switch fall through. in the first case, it falls through a return. On the second one, it prints undesired log messages on fall through. Solve that by copying the commands that it should be running. Gcc will very likely optimize it anyway, so this sholdn't be causing any harm, and shuts up gcc warnings. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/pci/ttpci/av7110.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/media/pci/ttpci/av7110.c b/drivers/media/pci/ttpci/av7110.c index df9395c87178..f2905bd80366 100644 --- a/drivers/media/pci/ttpci/av7110.c +++ b/drivers/media/pci/ttpci/av7110.c @@ -336,6 +336,7 @@ static int DvbDmxFilterCallback(u8 *buffer1, size_t buffer1_len, av7110_p2t_write(buffer1, buffer1_len, dvbdmxfilter->feed->pid, &av7110->p2t_filter[dvbdmxfilter->index]); + return 0; default: return 0; } @@ -451,8 +452,12 @@ static void debiirq(unsigned long cookie) case DATA_CI_PUT: dprintk(4, "debi DATA_CI_PUT\n"); + xfer = TX_BUFF; + break; case DATA_MPEG_PLAY: dprintk(4, "debi DATA_MPEG_PLAY\n"); + xfer = TX_BUFF; + break; case DATA_BMP_LOAD: dprintk(4, "debi DATA_BMP_LOAD\n"); xfer = TX_BUFF; -- 2.9.3
[PATCH v3 0/4] r8a7793 Gose video input support
Hi! This is a by-the-datasheet implementation of analog and digital video input on the Gose board. This revision adds new bindings that distinguish between ADV7180 variants with three and six input ports. There are numerous variants of this chip, but since all that have "CP" in their names have three inputs, and all that have "ST" have six, I have limited myself to two new compatible strings, "adv7180cp" and "adv7180st". The digital input patch has received minor tweaks of the port names for consistency, and the Gose analog input patch has been modified to use the new bindings, and a composite video connector has been added. CU Uli Changes since v2: - hdmi: port hdmi_con renamed to hdmi_con_out - adv7180: added new compatibility strings and bindings - composite: added connector, use new bindings Changes since v1: - r8a7793.dtsi: added VIN2 - modeled HDMI decoder input/output and connector - added "renesas,rcar-gen2-vin" compat strings - removed unnecessary "remote" node and aliases - set ADV7612 interrupt to GP4_2 Ulrich Hecht (4): ARM: dts: gose: add HDMI input media: adv7180: add adv7180cp, adv7180st compatible strings media: adv7180: Add adv7180cp, adv7180st bindings ARM: dts: gose: add composite video input .../devicetree/bindings/media/i2c/adv7180.txt | 15 +++ arch/arm/boot/dts/r8a7793-gose.dts | 127 - drivers/media/i2c/adv7180.c| 2 + 3 files changed, 142 insertions(+), 2 deletions(-) -- 2.7.4
[PATCH v3 4/4] ARM: dts: gose: add composite video input
Adds VIN, decoder and connector.
Signed-off-by: Ulrich Hecht
---
arch/arm/boot/dts/r8a7793-gose.dts | 59 ++
1 file changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7793-gose.dts
b/arch/arm/boot/dts/r8a7793-gose.dts
index 30f0835..76e3aca 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -275,6 +275,16 @@
};
};
+ composite-in {
+ compatible = "composite-video-connector";
+
+ port {
+ composite_con_in: endpoint {
+ remote-endpoint = <&adv7180_in>;
+ };
+ };
+ };
+
x2_clk: x2-clock {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -411,6 +421,11 @@
groups = "vin0_data24", "vin0_sync", "vin0_clkenb", "vin0_clk";
function = "vin0";
};
+
+ vin1_pins: vin1 {
+ groups = "vin1_data8", "vin1_clk";
+ function = "vin1";
+ };
};
ðer {
@@ -542,6 +557,32 @@
reg = <0x12>;
};
+ composite-in@20 {
+ compatible = "adi,adv7180cp";
+ reg = <0x20>;
+ remote = <&vin1>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ adv7180_in: endpoint {
+ remote-endpoint = <&composite_con_in>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+ adv7180_out: endpoint {
+ bus-width = <8>;
+ remote-endpoint = <&vin1ep>;
+ };
+ };
+ };
+ };
+
hdmi@39 {
compatible = "adi,adv7511w";
reg = <0x39>;
@@ -670,3 +711,21 @@
};
};
};
+
+/* composite video input */
+&vin1 {
+ pinctrl-0 = <&vin1_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vin1ep: endpoint {
+ remote-endpoint = <&adv7180_out>;
+ bus-width = <8>;
+ };
+ };
+};
--
2.7.4
[PATCH v3 2/4] media: adv7180: add adv7180cp, adv7180st compatible strings
Used to differentiate between models with 3 and 6 inputs.
Signed-off-by: Ulrich Hecht
---
drivers/media/i2c/adv7180.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index bdbbf8c..78de7dd 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -1452,6 +1452,8 @@ static SIMPLE_DEV_PM_OPS(adv7180_pm_ops, adv7180_suspend,
adv7180_resume);
#ifdef CONFIG_OF
static const struct of_device_id adv7180_of_id[] = {
{ .compatible = "adi,adv7180", },
+ { .compatible = "adi,adv7180cp", },
+ { .compatible = "adi,adv7180st", },
{ .compatible = "adi,adv7182", },
{ .compatible = "adi,adv7280", },
{ .compatible = "adi,adv7280-m", },
--
2.7.4
[PATCH v3 3/4] media: adv7180: Add adv7180cp, adv7180st bindings
To differentiate between two classes of chip packages that have different numbers of input ports. Signed-off-by: Ulrich Hecht --- Documentation/devicetree/bindings/media/i2c/adv7180.txt | 15 +++ 1 file changed, 15 insertions(+) diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.txt b/Documentation/devicetree/bindings/media/i2c/adv7180.txt index 4da486f..552b6a8 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7180.txt +++ b/Documentation/devicetree/bindings/media/i2c/adv7180.txt @@ -6,6 +6,8 @@ digital interfaces like MIPI CSI-2 or parallel video. Required Properties : - compatible : value must be one of "adi,adv7180" + "adi,adv7180cp" + "adi,adv7180st" "adi,adv7182" "adi,adv7280" "adi,adv7280-m" @@ -15,6 +17,19 @@ Required Properties : "adi,adv7282" "adi,adv7282-m" +Device nodes of "adi,adv7180cp" and "adi,adv7180st" must contain one +'port' child node per device input and output port, in accordance with the +video interface bindings defined in +Documentation/devicetree/bindings/media/video-interfaces.txt. The port +nodes are numbered as follows. + + Port adv7180cp adv7180st +--- + Input0-2 0-5 + Output 3 6 + +The digital output port node must contain at least one endpoint. + Optional Properties : - powerdown-gpios: reference to the GPIO connected to the powerdown pin, if any. -- 2.7.4
[PATCH v3 1/4] ARM: dts: gose: add HDMI input
Identical to the setup on Koelsch.
Signed-off-by: Ulrich Hecht
Reviewed-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7793-gose.dts | 68 --
1 file changed, 66 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7793-gose.dts
b/arch/arm/boot/dts/r8a7793-gose.dts
index 95e51b7..30f0835 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -253,12 +253,23 @@
};
};
+ hdmi-in {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&adv7612_in>;
+ };
+ };
+ };
+
hdmi-out {
compatible = "hdmi-connector";
type = "a";
port {
- hdmi_con: endpoint {
+ hdmi_con_out: endpoint {
remote-endpoint = <&adv7511_out>;
};
};
@@ -395,6 +406,11 @@
groups = "audio_clk_a";
function = "audio_clk";
};
+
+ vin0_pins: vin0 {
+ groups = "vin0_data24", "vin0_sync", "vin0_clkenb", "vin0_clk";
+ function = "vin0";
+ };
};
ðer {
@@ -552,7 +568,34 @@
port@1 {
reg = <1>;
adv7511_out: endpoint {
- remote-endpoint = <&hdmi_con>;
+ remote-endpoint = <&hdmi_con_out>;
+ };
+ };
+ };
+ };
+
+ hdmi-in@4c {
+ compatible = "adi,adv7612";
+ reg = <0x4c>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+ default-input = <0>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ adv7612_in: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ adv7612_out: endpoint {
+ remote-endpoint = <&vin0ep2>;
};
};
};
@@ -606,3 +649,24 @@
&ssi1 {
shared-pin;
};
+
+/* HDMI video input */
+&vin0 {
+ status = "okay";
+ pinctrl-0 = <&vin0_pins>;
+ pinctrl-names = "default";
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vin0ep2: endpoint {
+ remote-endpoint = <&adv7612_out>;
+ bus-width = <24>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ pclk-sample = <1>;
+ data-active = <1>;
+ };
+ };
+};
--
2.7.4
Re: [PATCH v1 2/3] device property: Add fwnode_graph_get_port_parent
Hi Laurent,
On 18/05/17 14:36, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Wednesday 17 May 2017 16:03:38 Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> V4L2 async notifiers can pass the endpoint fwnode rather than the device
>> fwnode.
>
> I'm not sure I would mention V4L2 in the commit message, as this is generic.
Good point
>> Provide a helper to obtain the parent device fwnode without first
>> parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent.
>>
>> Signed-off-by: Kieran Bingham
>> ---
>> drivers/base/property.c | 25 +
>> include/linux/property.h | 2 ++
>> 2 files changed, 27 insertions(+)
>>
>> diff --git a/drivers/base/property.c b/drivers/base/property.c
>> index 627ebc9b570d..caf4316fe565 100644
>> --- a/drivers/base/property.c
>> +++ b/drivers/base/property.c
>> @@ -1245,6 +1245,31 @@ fwnode_graph_get_next_endpoint(struct fwnode_handle
>> *fwnode, EXPORT_SYMBOL_GPL(fwnode_graph_get_next_endpoint);
>>
>> /**
>> + * fwnode_graph_get_port_parent - Return device node of a port endpoint
>> + * @fwnode: Endpoint firmware node pointing of the port
>> + *
>> + * Extracts firmware node of the device the @fwnode belongs to.
>
> I'm not too familiar with the fwnode API, but I know it's written in C, where
> functions don't extract something but return a value :-) How about
>
> Return: the firmware node of the device the @endpoint belongs to.
>
I'm not averse to the reword - but it is different to the other functions in the
same context:
fwnode_graph_get_remote_endpoint(struct fwnode_handle *fwnode)
* Extracts firmware node of a remote endpoint the @fwnode points to.
struct fwnode_handle *fwnode_graph_get_remote_port(struct fwnode_handle *fwnode)
* Extracts firmware node of a remote port the @fwnode points to.
fwnode_graph_get_remote_port_parent(struct fwnode_handle *fwnode)
* Extracts firmware node of a remote device the @fwnode points to.
Then with this function becoming:
fwnode_graph_get_port_parent(struct fwnode_handle *endpoint)
* Returns firmware node of the device the @endpoint belongs to.
I guess those could be changed too ...
>> + */
>> +struct fwnode_handle *
>> +fwnode_graph_get_port_parent(struct fwnode_handle *fwnode)
>
> This is akin to writing (unsigned int integer)
Yes, good point there - I was thinking of the fwnode as an object itself, but
really it's representing the endpoint, and the fwnode is the class type :)
>
> How about calling the variable endpoint ? That would also make the
> documentation clearer in my opinion, with "the @fwnode belongs to" replaced
> with "the @endpoint belongs to".
Agreed
>
>> +{
>> +struct fwnode_handle *parent = NULL;
>> +
>> +if (is_of_node(fwnode)) {
>> +struct device_node *node;
>> +
>> +node = of_graph_get_port_parent(to_of_node(fwnode));
>> +if (node)
>> +parent = &node->fwnode;
>
> This part looks good to me, with the above small change,
>
> Reviewed-by: Laurent Pinchart
Thanks,
I'll add this if the code doesn't change drastically based on Sakari's
suggestion.
>
>> +} else if (is_acpi_node(fwnode)) {
>> +parent = acpi_node_get_parent(fwnode);
>
> I can't comment on this one though.
>
>> +}
>> +
>> +return parent;
>> +}
>> +EXPORT_SYMBOL_GPL(fwnode_graph_get_port_parent);
>> +
>> +/**
>> * fwnode_graph_get_remote_port_parent - Return fwnode of a remote device
>> * @fwnode: Endpoint firmware node pointing to the remote endpoint
>> *
>> diff --git a/include/linux/property.h b/include/linux/property.h
>> index 2f482616a2f2..624129b86c82 100644
>> --- a/include/linux/property.h
>> +++ b/include/linux/property.h
>> @@ -274,6 +274,8 @@ void *device_get_mac_address(struct device *dev, char
>> *addr, int alen);
>>
>> struct fwnode_handle *fwnode_graph_get_next_endpoint(
>> struct fwnode_handle *fwnode, struct fwnode_handle *prev);
>> +struct fwnode_handle *fwnode_graph_get_port_parent(
>> +struct fwnode_handle *fwnode);
>> struct fwnode_handle *fwnode_graph_get_remote_port_parent(
>> struct fwnode_handle *fwnode);
>> struct fwnode_handle *fwnode_graph_get_remote_port(
>
Re: [PATCH v1 2/3] device property: Add fwnode_graph_get_port_parent
Hi Kieran,
On Friday 19 May 2017 14:34:33 Kieran Bingham wrote:
> On 18/05/17 14:36, Laurent Pinchart wrote:
> > On Wednesday 17 May 2017 16:03:38 Kieran Bingham wrote:
> >> From: Kieran Bingham
> >>
> >> V4L2 async notifiers can pass the endpoint fwnode rather than the device
> >> fwnode.
> >
> > I'm not sure I would mention V4L2 in the commit message, as this is
> > generic.
>
> Good point
>
> >> Provide a helper to obtain the parent device fwnode without first
> >> parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent.
> >>
> >> Signed-off-by: Kieran Bingham
> >> ---
> >>
> >> drivers/base/property.c | 25 +
> >> include/linux/property.h | 2 ++
> >> 2 files changed, 27 insertions(+)
> >>
> >> diff --git a/drivers/base/property.c b/drivers/base/property.c
> >> index 627ebc9b570d..caf4316fe565 100644
> >> --- a/drivers/base/property.c
> >> +++ b/drivers/base/property.c
> >> @@ -1245,6 +1245,31 @@ fwnode_graph_get_next_endpoint(struct
> >> fwnode_handle
> >> *fwnode, EXPORT_SYMBOL_GPL(fwnode_graph_get_next_endpoint);
> >>
> >> /**
> >>
> >> + * fwnode_graph_get_port_parent - Return device node of a port endpoint
> >> + * @fwnode: Endpoint firmware node pointing of the port
> >> + *
> >> + * Extracts firmware node of the device the @fwnode belongs to.
> >
> > I'm not too familiar with the fwnode API, but I know it's written in C,
> > where functions don't extract something but return a value :-) How about
> >
> > Return: the firmware node of the device the @endpoint belongs to.
>
> I'm not averse to the reword - but it is different to the other functions in
> the same context:
>
> fwnode_graph_get_remote_endpoint(struct fwnode_handle *fwnode)
> * Extracts firmware node of a remote endpoint the @fwnode points to.
>
> struct fwnode_handle *fwnode_graph_get_remote_port(struct fwnode_handle
> *fwnode)
> * Extracts firmware node of a remote port the @fwnode points to.
>
> fwnode_graph_get_remote_port_parent(struct fwnode_handle *fwnode)
> * Extracts firmware node of a remote device the @fwnode points to.
>
> Then with this function becoming:
>
> fwnode_graph_get_port_parent(struct fwnode_handle *endpoint)
> * Returns firmware node of the device the @endpoint belongs to.
>
>
> I guess those could be changed too ...
My point is that the kerneldoc format documents return values with a "Return:"
tag. The documentation for the function can still provide extra information.
> >> + */
> >> +struct fwnode_handle *
> >> +fwnode_graph_get_port_parent(struct fwnode_handle *fwnode)
> >
> > This is akin to writing (unsigned int integer)
>
> Yes, good point there - I was thinking of the fwnode as an object itself,
> but really it's representing the endpoint, and the fwnode is the class type
> :)
>
> > How about calling the variable endpoint ? That would also make the
> > documentation clearer in my opinion, with "the @fwnode belongs to"
> > replaced with "the @endpoint belongs to".
>
> Agreed
>
> >> +{
> >> + struct fwnode_handle *parent = NULL;
> >> +
> >> + if (is_of_node(fwnode)) {
> >> + struct device_node *node;
> >> +
> >> + node = of_graph_get_port_parent(to_of_node(fwnode));
> >> + if (node)
> >> + parent = &node->fwnode;
> >
> > This part looks good to me, with the above small change,
> >
> > Reviewed-by: Laurent Pinchart
>
> Thanks,
>
> I'll add this if the code doesn't change drastically based on Sakari's
> suggestion.
>
> >> + } else if (is_acpi_node(fwnode)) {
> >> + parent = acpi_node_get_parent(fwnode);
> >
> > I can't comment on this one though.
> >
> >> + }
> >> +
> >> + return parent;
> >> +}
> >> +EXPORT_SYMBOL_GPL(fwnode_graph_get_port_parent);
> >> +
> >> +/**
> >>
> >> * fwnode_graph_get_remote_port_parent - Return fwnode of a remote
> >> device
> >> * @fwnode: Endpoint firmware node pointing to the remote endpoint
> >> *
> >>
> >> diff --git a/include/linux/property.h b/include/linux/property.h
> >> index 2f482616a2f2..624129b86c82 100644
> >> --- a/include/linux/property.h
> >> +++ b/include/linux/property.h
> >> @@ -274,6 +274,8 @@ void *device_get_mac_address(struct device *dev, char
> >> *addr, int alen);
> >>
> >> struct fwnode_handle *fwnode_graph_get_next_endpoint(
> >>
> >>struct fwnode_handle *fwnode, struct fwnode_handle *prev);
> >>
> >> +struct fwnode_handle *fwnode_graph_get_port_parent(
> >> + struct fwnode_handle *fwnode);
> >>
> >> struct fwnode_handle *fwnode_graph_get_remote_port_parent(
> >>
> >>struct fwnode_handle *fwnode);
> >>
> >> struct fwnode_handle *fwnode_graph_get_remote_port(
--
Regards,
Laurent Pinchart
Re: [RFC PATCH v2 1/4] media: i2c: adv748x: add adv748x driver
Hi Sakari, >> >> Finding and matching the parent of the SD would allow a driver to register a >> notifier ASD with a dev node, and expect to match a subdevice that has >> registered it's subdev with an EP node. This would erroneously allow drivers >> to >> register a notifier that would match against *both* of the ADV748x CSI2 >> entities. > > You'd first have to have a board that has the two devices, and then ignore > what the drivers are doing. :-) I guess an error would be encountered at > some point in driver initialisation. Ah yes of course - I see it now... The only erroneous case is a scenario that should be fixed by whomever wants to use that. Where as the rest of the "ep - dev" matches become a master driver which has not converted to endpoint matching, during the phase of which subdevices have. Adding this in for v3, along with the rebase to your acpi-graph-cleaned. > > Anyway, I don't think this situation should be a lasting one, and that > endpoint matching is the way to go. Yes, of course hopefully we'll make a full transition along the way. -- Regards Kieran
[PATCH v2 0/2] v4l: async: Match parent devices
From: Kieran Bingham As devices become more complicated, it becomes necessary (and more accurate) to match devices based on their endpoint, as devices may have multiple subdevices. To support using endpoints in the V4L2 async subdev framework, while some devices still use their device fwnode, we need to be able to parse a fwnode for the device from the endpoint. By providing a helper fwnode_graph_get_port_parent(), we can use it in the match_fwnode to support matches during the transition to endpoint matching. This series is dependant upon Sakari's v4l2-acpi and acpi-graph-cleaned branch v2: - Rebased on top of git.linuxtv.org/sailus/media_tree.git #acpi-graph-cleaned Kieran Bingham (2): device property: Add fwnode_graph_get_port_parent v4l: async: Match parent devices drivers/base/property.c | 13 +++- drivers/media/v4l2-core/v4l2-async.c | 33 - include/linux/property.h | 2 ++- 3 files changed, 43 insertions(+), 5 deletions(-) base-commit: d043978c7c919c727fb76b6593c71d0e697a5d66 -- git-series 0.9.1
[PATCH v2 1/2] device property: Add fwnode_graph_get_port_parent
From: Kieran Bingham
Provide a helper to obtain the parent device fwnode without first
parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent.
Signed-off-by: Kieran Bingham
---
v2:
- Rebase on top of Sakari's acpi-graph-clean branch and simplify
drivers/base/property.c | 13 +
include/linux/property.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index b311a6fa7d0c..310c53b6b7fc 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -1169,6 +1169,19 @@ fwnode_graph_get_next_endpoint(struct fwnode_handle
*fwnode,
EXPORT_SYMBOL_GPL(fwnode_graph_get_next_endpoint);
/**
+ * fwnode_graph_get_port_parent - Return the device fwnode of a port endpoint
+ * @endpoint: Endpoint firmware node of the port
+ *
+ * Returns firmware node of the device the @endpoint belongs to.
+ */
+struct fwnode_handle *
+fwnode_graph_get_port_parent(struct fwnode_handle *endpoint)
+{
+ return fwnode_call_ptr_op(endpoint, graph_get_port_parent);
+}
+EXPORT_SYMBOL_GPL(fwnode_graph_get_port_parent);
+
+/**
* fwnode_graph_get_remote_port_parent - Return fwnode of a remote device
* @fwnode: Endpoint firmware node pointing to the remote endpoint
*
diff --git a/include/linux/property.h b/include/linux/property.h
index b9f4838d9882..af95d5d84192 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -275,6 +275,8 @@ void *device_get_mac_address(struct device *dev, char
*addr, int alen);
struct fwnode_handle *fwnode_graph_get_next_endpoint(
struct fwnode_handle *fwnode, struct fwnode_handle *prev);
+struct fwnode_handle *fwnode_graph_get_port_parent(
+ struct fwnode_handle *fwnode);
struct fwnode_handle *fwnode_graph_get_remote_port_parent(
struct fwnode_handle *fwnode);
struct fwnode_handle *fwnode_graph_get_remote_port(
--
git-series 0.9.1
[PATCH v2 2/2] v4l: async: Match parent devices
From: Kieran Bingham
Devices supporting multiple endpoints on a single device node must set
their subdevice fwnode to the endpoint to allow distinct comparisons.
Adapt the match_fwnode call to compare against the provided fwnodes
first, but also to search for a comparison against the parent fwnode.
This allows notifiers to pass the endpoint for comparison and still
support existing subdevices which store their default parent device
node.
Signed-off-by: Kieran Bingham
---
v2:
- Added documentation comments
- simplified the OF match by adding match_fwnode_of()
drivers/media/v4l2-core/v4l2-async.c | 33 -
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-async.c
b/drivers/media/v4l2-core/v4l2-async.c
index cbd919d4edd2..2473c0a1f7a8 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -41,14 +41,37 @@ static bool match_devname(struct v4l2_subdev *sd,
return !strcmp(asd->match.device_name.name, dev_name(sd->dev));
}
+static bool match_fwnode_of(struct fwnode_handle *a, struct fwnode_handle *b)
+{
+ return !of_node_cmp(of_node_full_name(to_of_node(a)),
+ of_node_full_name(to_of_node(b)));
+}
+
+/*
+ * Compare the sd with the notifier.
+ *
+ * As a measure to support drivers which have not been converted to use
+ * endpoint matching, we also find the parent device of the node in the
+ * notifier, and compare the sd against that device.
+ */
static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
{
- if (!is_of_node(sd->fwnode) || !is_of_node(asd->match.fwnode.fwnode))
- return sd->fwnode == asd->match.fwnode.fwnode;
+ struct fwnode_handle *asd_fwnode = asd->match.fwnode.fwnode;
+ struct fwnode_handle *sd_parent, *asd_parent;
+
+ asd_parent = fwnode_graph_get_port_parent(asd_fwnode);
+
+ if (!is_of_node(sd->fwnode) || !is_of_node(asd_fwnode))
+ return sd->fwnode == asd_fwnode ||
+ sd_parent == asd_fwnode ||
+ sd->fwnode == asd_parent;
- return !of_node_cmp(of_node_full_name(to_of_node(sd->fwnode)),
- of_node_full_name(
- to_of_node(asd->match.fwnode.fwnode)));
+ /*
+* Compare OF nodes with a full match to support removable dt snippets.
+*/
+ return match_fwnode_of(sd->fwnode, asd_fwnode) ||
+ match_fwnode_of(sd_parent, asd_fwnode) ||
+ match_fwnode_of(sd->fwnode, asd_parent);
}
static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
--
git-series 0.9.1
Re: [PATCH 1/4] [media] tw5864, fc0011: better handle WARN_ON()
ok, I'll check this patch on tw5864 hardware bit later and report results here
On Thu, May 18, 2017 at 10:48 PM, Andrey Utkin
wrote:
> On Thu, May 18, 2017 at 11:06:43AM -0300, Mauro Carvalho Chehab wrote:
>> As such macro will check if the expression is true, it may fall through, as
>> warned:
>
>> On both cases, it means an error, so, let's return an error
>> code, to make gcc happy.
>>
>> Signed-off-by: Mauro Carvalho Chehab
>> ---
>> drivers/media/pci/tw5864/tw5864-video.c | 1 +
>> drivers/media/tuners/fc0011.c | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/drivers/media/pci/tw5864/tw5864-video.c
>> b/drivers/media/pci/tw5864/tw5864-video.c
>> index 2a044be729da..e7bd2b8484e3 100644
>> --- a/drivers/media/pci/tw5864/tw5864-video.c
>> +++ b/drivers/media/pci/tw5864/tw5864-video.c
>> @@ -545,6 +545,7 @@ static int tw5864_fmt_vid_cap(struct file *file, void
>> *priv,
>> switch (input->std) {
>> default:
>> WARN_ON_ONCE(1);
>> + return -EINVAL;
>> case STD_NTSC:
>> f->fmt.pix.height = 480;
>> break;
>
> Hi Mauro,
>
> Thanks for the patch.
>
> I actually meant it to fall through, but I agree this is not how it
> should be.
> I'm fine with this patch. Unfortunately I don't possess tw5864 hardware
> now. CCing Anton Sviridenko whom I've handed it (I guess he's on
> Bluecherry Maintainers groupmail as well).
>
> Anton, just in case, could you please ensure the driver with this patch
> works well in runtime?
[PATCH] [media] rainshadow-cec: ensure exit_loop is initialized
From: Colin Ian King
exit_loop is not being initialized, so it contains garbage. Ensure it is
initialized to false.
Detected by CoverityScan, CID#1436409 ("Uninitialzed scalar variable")
Fixes: ea6a69defd3311 ("[media] rainshadow-cec: avoid -Wmaybe-uninitialized
warning")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/vc4/vc4_v3d.c | 2 +-
drivers/media/usb/rainshadow-cec/rainshadow-cec.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
index c53afec34586..c42210203f6e 100644
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -218,7 +218,7 @@ int vc4_v3d_get_bin_slot(struct vc4_dev *vc4)
* overall CMA pool before they make scenes complicated enough to run
* out of bin space.
*/
-int
+static int
vc4_allocate_bin_bo(struct drm_device *drm)
{
struct vc4_dev *vc4 = to_vc4_dev(drm);
diff --git a/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
b/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
index 8d3ca2c8b20f..ad468efc4399 100644
--- a/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
+++ b/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
@@ -119,7 +119,7 @@ static void rain_irq_work_handler(struct work_struct *work)
while (true) {
unsigned long flags;
- bool exit_loop;
+ bool exit_loop = false;
char data;
spin_lock_irqsave(&rain->buf_lock, flags);
--
2.11.0
NACK: [PATCH] [media] rainshadow-cec: ensure exit_loop is initialized
On 19/05/17 18:39, Colin King wrote:
> From: Colin Ian King
>
> exit_loop is not being initialized, so it contains garbage. Ensure it is
> initialized to false.
>
> Detected by CoverityScan, CID#1436409 ("Uninitialzed scalar variable")
>
> Fixes: ea6a69defd3311 ("[media] rainshadow-cec: avoid -Wmaybe-uninitialized
> warning")
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/vc4/vc4_v3d.c | 2 +-
> drivers/media/usb/rainshadow-cec/rainshadow-cec.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
> index c53afec34586..c42210203f6e 100644
> --- a/drivers/gpu/drm/vc4/vc4_v3d.c
> +++ b/drivers/gpu/drm/vc4/vc4_v3d.c
> @@ -218,7 +218,7 @@ int vc4_v3d_get_bin_slot(struct vc4_dev *vc4)
> * overall CMA pool before they make scenes complicated enough to run
> * out of bin space.
> */
> -int
> +static int
> vc4_allocate_bin_bo(struct drm_device *drm)
> {
> struct vc4_dev *vc4 = to_vc4_dev(drm);
> diff --git a/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
> b/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
> index 8d3ca2c8b20f..ad468efc4399 100644
> --- a/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
> +++ b/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
> @@ -119,7 +119,7 @@ static void rain_irq_work_handler(struct work_struct
> *work)
>
> while (true) {
> unsigned long flags;
> - bool exit_loop;
> + bool exit_loop = false;
> char data;
>
> spin_lock_irqsave(&rain->buf_lock, flags);
>
Sorry, got another fix included into that. I'll re-submit
[PATCH][V2] [media] rainshadow-cec: ensure exit_loop is intialized
From: Colin Ian King
exit_loop is not being initialized, so it contains garbage. Ensure it is
initialized to false.
Detected by CoverityScan, CID#1436409 ("Uninitialized scalar variable")
Fixes: ea6a69defd3311 ("[media] rainshadow-cec: avoid -Wmaybe-uninitialized
warning")
Signed-off-by: Colin Ian King
---
drivers/media/usb/rainshadow-cec/rainshadow-cec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
b/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
index 8d3ca2c8b20f..ad468efc4399 100644
--- a/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
+++ b/drivers/media/usb/rainshadow-cec/rainshadow-cec.c
@@ -119,7 +119,7 @@ static void rain_irq_work_handler(struct work_struct *work)
while (true) {
unsigned long flags;
- bool exit_loop;
+ bool exit_loop = false;
char data;
spin_lock_irqsave(&rain->buf_lock, flags);
--
2.11.0
Re: [PATCH 14/16] lirc_dev: cleanup includes
On Mon, May 01, 2017 at 06:04:47PM +0200, David Härdeman wrote: > Remove superfluous includes and defines. > > Signed-off-by: David Härdeman > --- > drivers/media/rc/lirc_dev.c | 12 +--- > 1 file changed, 1 insertion(+), 11 deletions(-) > > diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c > index 7db7d4c57991..4ba6c7e2d41b 100644 > --- a/drivers/media/rc/lirc_dev.c > +++ b/drivers/media/rc/lirc_dev.c > @@ -15,20 +15,11 @@ > * > */ > > -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > - > #include > -#include > #include > -#include > #include > -#include > #include > -#include > #include > -#include > -#include > -#include > #include > #include > #include > @@ -37,7 +28,6 @@ > #include > #include > > -#define IRCTL_DEV_NAME "BaseRemoteCtl" > #define LOGHEAD "lirc_dev (%s[%d]): " > > static dev_t lirc_base_dev; > @@ -545,7 +535,7 @@ static int __init lirc_dev_init(void) > } > > retval = alloc_chrdev_region(&lirc_base_dev, 0, LIRC_MAX_DEVICES, > - IRCTL_DEV_NAME); > + "BaseRemoteCtl"); This has always surprised/annoyed me. Why is this called BaseRemoteCtl? As far as I know, this is only used for /proc/devices, where it says: $ grep 239 /proc/devices 239 BaseRemoteCtl And not lirc, as you would expect. Sean
Re: [PATCH v2 1/2] device property: Add fwnode_graph_get_port_parent
Hi Kieran,
On Fri, May 19, 2017 at 05:16:02PM +0100, Kieran Bingham wrote:
> +struct fwnode_handle *
> +fwnode_graph_get_port_parent(struct fwnode_handle *endpoint)
> +{
> + return fwnode_call_ptr_op(endpoint, graph_get_port_parent);
graph_get_port_parent op will actually get the parent of the port. But it
expects a port node, not an endpoint node. This is implemented so in order
to center the ops around primitives rather than end user APIs that may
change over time.
I think you'll need:
return fwnode_call_ptr_op(fwnode_graph_get_next_parent(endpoint),
graph_get_port_parent);
Or something like that.
--
Regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: [PATCH] ARM64: defconfig: enable IR core, decoders and Meson IR device
Neil Armstrong writes: > This patch enables the MEDIA Infrared RC Decoders and Meson Infrared > decoder for ARM64 defconfig. > These drivers are selected as modules by default. > > Signed-off-by: Neil Armstrong > --- > arch/arm64/configs/defconfig | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index c021aefa..59c400f 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -321,6 +321,11 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y > CONFIG_MEDIA_ANALOG_TV_SUPPORT=y > CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y > CONFIG_MEDIA_CONTROLLER=y > +CONFIG_MEDIA_RC_SUPPORT=y > +CONFIG_RC_CORE=y This one should be a module too. With that fixed, applied to v4.13/defconfig Kevin > +CONFIG_RC_DEVICES=y > +CONFIG_RC_DECODERS=y > +CONFIG_IR_MESON=m > CONFIG_VIDEO_V4L2_SUBDEV_API=y > # CONFIG_DVB_NET is not set > CONFIG_V4L_MEM2MEM_DRIVERS=y
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: Sat May 20 05:00:19 CEST 2017 media-tree git hash:36bcba973ad478042d1ffc6e89afd92e8bd17030 media_build git hash: ab988a3d089232ce9e1aec2f259e947c06983dbc v4l-utils git hash: d16a17abd1d8d7885ca2f44fb295035278baa89c gcc version:i686-linux-gcc (GCC) 7.1.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.9.0-164 linux-git-arm-at91: ERRORS linux-git-arm-davinci: ERRORS linux-git-arm-multi: ERRORS linux-git-arm-pxa: ERRORS linux-git-blackfin-bf561: ERRORS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: ERRORS 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.67-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.9-i686: ERRORS linux-4.1.33-i686: ERRORS linux-4.2.8-i686: ERRORS linux-4.3.6-i686: ERRORS linux-4.4.22-i686: ERRORS linux-4.5.7-i686: ERRORS linux-4.6.7-i686: ERRORS linux-4.7.5-i686: ERRORS linux-4.8-i686: ERRORS linux-4.9.26-i686: ERRORS linux-4.10.14-i686: ERRORS linux-4.11-i686: ERRORS linux-4.12-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.67-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.9-x86_64: ERRORS linux-4.1.33-x86_64: ERRORS linux-4.2.8-x86_64: ERRORS linux-4.3.6-x86_64: ERRORS linux-4.4.22-x86_64: ERRORS linux-4.5.7-x86_64: ERRORS linux-4.6.7-x86_64: ERRORS linux-4.7.5-x86_64: ERRORS linux-4.8-x86_64: ERRORS linux-4.9.26-x86_64: ERRORS linux-4.10.14-x86_64: ERRORS linux-4.11-x86_64: ERRORS linux-4.12-rc1-x86_64: ERRORS apps: WARNINGS spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
