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 6 05:00:12 CEST 2018 media-tree git hash:f10379aad39e9da8bc7d1822e251b5f0673067ef media_build git hash: 97c1228540bbbf1593bbdca1fdc2dafc990a6081 v4l-utils git hash: 03e763fd4b361b2082019032fc315b7606669335 gcc version:i686-linux-gcc (GCC) 7.3.0 sparse version: 0.5.2-RC1 smatch version: 0.5.1 host hardware: x86_64 host os:4.15.0-3-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: WARNINGS 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: ERRORS linux-4.8.17-x86_64: ERRORS linux-4.9.91-i686: ERRORS linux-4.9.91-x86_64: ERRORS linux-4.14.31-i686: OK linux-4.14.31-x86_64: OK linux-4.15.14-i686: OK linux-4.15.14-x86_64: OK linux-4.16-i686: OK linux-4.16-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
Re: [PATCH 0/2] media: imx: add capture support for RGB565_2X8 on parallel bus
Hi Jan, Philipp,
I reviewed this patch series, and while I don't have any
objections to the code-level changes, but my question
is more specifically about how the IPU/CSI deals with
receiving RGB565 over a parallel bus.
My understanding was that if the CSI receives RGB565
over a parallel 8-bit sensor bus, the CSI_SENS_DATA_FORMAT
register field is programmed to RGB565, and the CSI outputs
ARGB. Then IDMAC component packing can be setup to
write pixels to memory as RGB565. Does that not work?
Assuming that above does not work (and indeed parallel RGB565
must be handled as pass-through), then I think support for capturing
parallel RGB555 as pass-through should be added to this series as
well.
Also what about RGB565 over a 16-bit parallel sensor bus? The
reference manual hints that perhaps this could be treated as
non-passthrough ("on the fly processing"), e.g. could be passed
on to the IC pre-processor:
16 bit RGB565
This is the only mode that allows on the fly processing of 16
bit data. In this mode the
CSI is programmed to receive 16 bit generic data. In this mode
the interface is
restricted to be in "non-gated mode" and the CSI#_DATA_SOURCE
bit has to be set
If the external device is 24bit - the user can connect a 16 bit
sample of it (RGB565
format). The IPU has to be configured in the same way as the
case of
CSI#_SENS_DATA_FORMAT=RGB565
Thanks,
Steve
On 05/03/2018 09:41 AM, Jan Luebbe wrote:
The IPU can only capture RGB565 with two 8-bit cycles in bayer/generic
mode on the parallel bus, compared to a specific mode on MIPI CSI-2.
To handle this, we extend imx_media_pixfmt with a cycles per pixel
field, which is used for generic formats on the parallel bus.
Before actually adding RGB565_2X8 support for the parallel bus, this
series simplifies handing of the the different configurations for RGB565
between parallel and MIPI CSI-2 in imx-media-capture. This avoids having
to explicitly pass on the format in the second patch.
Jan Luebbe (2):
media: imx: capture: refactor enum_/try_fmt
media: imx: add support for RGB565_2X8 on parallel bus
drivers/staging/media/imx/imx-media-capture.c | 38 +++
drivers/staging/media/imx/imx-media-csi.c | 47 +--
drivers/staging/media/imx/imx-media-utils.c | 1 +
drivers/staging/media/imx/imx-media.h | 2 +
4 files changed, 63 insertions(+), 25 deletions(-)
Re: [PATCH] media: include/video/omapfb_dss.h: use IS_ENABLED()
Em Sat, 5 May 2018 10:59:23 -0700
Randy Dunlap escreveu:
> On 05/04/2018 01:49 PM, Mauro Carvalho Chehab wrote:
> > Just checking for ifdefs cause build issues as reported by
> > kernel test:
> >
> > config: openrisc-allmodconfig (attached as .config)
> > compiler: or1k-linux-gcc (GCC) 6.0.0 20160327 (experimental)
> >
> > All errors (new ones prefixed by >>):
> >
> >drivers/video/fbdev/omap2/omapfb/omapfb-main.c: In function
> > 'omapfb_init_connections':
> >>> drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2396:8: error: implicit
> >>> declaration of function 'omapdss_find_mgr_from_display'
> >>> [-Werror=implicit-function-declaration]
> > mgr = omapdss_find_mgr_from_display(def_dssdev);
> >^
> >drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2396:6: warning:
> > assignment makes pointer from integer without a cast [-Wint-conversion]
> > mgr = omapdss_find_mgr_from_display(def_dssdev);
> > ^
> >drivers/video/fbdev/omap2/omapfb/omapfb-main.c: In function
> > 'omapfb_find_default_display':
> >>> drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2430:13: error: implicit
> >>> declaration of function 'omapdss_get_default_display_name'
> >>> [-Werror=implicit-function-declaration]
> > def_name = omapdss_get_default_display_name();
> > ^~~~
> >drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2430:11: warning:
> > assignment makes pointer from integer without a cast [-Wint-conversion]
> > def_name = omapdss_get_default_display_name();
> > ^
> >
> > So, use IS_ENABLED() instead.
>
> Hi,
>
> I would like to test this (the change doesn't make much sense to me),
> but I cannot find the kernel config file nor the kernel test robot's
> email of this report.
>
> Please include an lkml.kernel.org/r/ reference to such emails
> so that interested parties can join the party.
The message was not c/c to lkml. You can see the original here:
https://www.mail-archive.com/linux-media@vger.kernel.org/msg130809.html
>
> Does this patch apply only to your media tree? so hopefully I can see it in
> linux-next on Monday.
Yes, as it is over another two patches applied there.
If you want to test it earlier, it is in the top of the master branch:
https://git.linuxtv.org/media_tree.git
>
> Thanks.
>
> > Cc: Bartlomiej Zolnierkiewicz
> > Cc: Randy Dunlap
> > Cc: tomi.valkei...@ti.com
> > Cc: linux-o...@vger.kernel.org
> > Cc: linux-fb...@vger.kernel.org
> > Fixes: 771f7be87ff9 ("media: omapfb: omapfb_dss.h: add stubs to build with
> > COMPILE_TEST && DRM_OMAP")
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> > include/video/omapfb_dss.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/video/omapfb_dss.h b/include/video/omapfb_dss.h
> > index e9775144ff3b..12755d8d9b4f 100644
> > --- a/include/video/omapfb_dss.h
> > +++ b/include/video/omapfb_dss.h
> > @@ -778,7 +778,7 @@ struct omap_dss_driver {
> >
> > typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
> >
> > -#ifdef CONFIG_FB_OMAP2
> > +#if IS_ENABLED(CONFIG_FB_OMAP2)
> >
> > enum omapdss_version omapdss_get_version(void);
> > bool omapdss_is_initialized(void);
> >
>
>
Thanks,
Mauro
.config.gz
Description: application/gzip
Re: [PATCH] media: pt1: use #ifdef CONFIG_PM_SLEEP instead of #if
On Sat, May 5, 2018 at 4:24 PM, Mauro Carvalho Chehab
wrote:
> As pointed by ktest:
>
>>> drivers/media//pci/pt1/pt1.c:1433:5: warning: "CONFIG_PM_SLEEP" is not
>>> defined, evaluates to 0 [-Wundef]
> #if CONFIG_PM_SLEEP
> ^~~
>
Why not to go further and drop this ugly #if(def) in favour of __maybe_unused?
> Reported-by: kbuild test robot
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/pci/pt1/pt1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/pci/pt1/pt1.c b/drivers/media/pci/pt1/pt1.c
> index 3b7e08a4639a..55a89ea13f2a 100644
> --- a/drivers/media/pci/pt1/pt1.c
> +++ b/drivers/media/pci/pt1/pt1.c
> @@ -1443,7 +1443,7 @@ static struct pci_driver pt1_driver = {
> .probe = pt1_probe,
> .remove = pt1_remove,
> .id_table = pt1_id_table,
> -#if CONFIG_PM_SLEEP
> +#ifdef CONFIG_PM_SLEEP
> .driver.pm = &pt1_pm_ops,
> #endif
> };
> --
> 2.17.0
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] media: imx-csi: fix burst size for 16 bit
Acked-by: Steve Longerbeam
On 05/03/2018 09:40 AM, Philipp Zabel wrote:
On Thu, 2018-05-03 at 18:32 +0200, Jan Luebbe wrote:
A burst_size of 4 does not work for the 16 bit passthrough formats, so
we use 8 instead.
Signed-off-by: Jan Luebbe
---
drivers/staging/media/imx/imx-media-csi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/imx/imx-media-csi.c
b/drivers/staging/media/imx/imx-media-csi.c
index 1112d8f67a18..08b636084286 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -410,7 +410,7 @@ static int csi_idmac_setup_channel(struct csi_priv *priv)
case V4L2_PIX_FMT_SGRBG16:
case V4L2_PIX_FMT_SRGGB16:
case V4L2_PIX_FMT_Y16:
- burst_size = 4;
+ burst_size = 8;
This seems to be the equivalent to commit 37ea9830139b3 ("media: imx-
csi: fix burst size"), but for 16-bit formats.
Acked-by: Philipp Zabel
regards
Philipp
Re: [PATCH] media: imx: add 16-bit grayscale support
Acked-by: Steve Longerbeam
On 05/03/2018 08:06 AM, Philipp Zabel wrote:
Since commit 50b0f0aee839 ("gpu: ipu-csi: add 10/12-bit grayscale
support to mbus_code_to_bus_cfg") the IPU CSI can be configured to
capture 10-bit and 12-bit grayscale formats, expanded to 16-bit
grayscale, in bayer/generic data mode.
This patch adds support for V4L2_PIX_FMT_Y16 captured from sensors
that provide MEDIA_BUS_FMT_Y10_1X10 or MEDIA_BUS_FMT_Y12_1X12 data.
Cc: Jan Luebbe
Signed-off-by: Philipp Zabel
---
drivers/staging/media/imx/imx-media-csi.c | 1 +
drivers/staging/media/imx/imx-media-utils.c | 9 +
2 files changed, 10 insertions(+)
diff --git a/drivers/staging/media/imx/imx-media-csi.c
b/drivers/staging/media/imx/imx-media-csi.c
index 16cab40156ca..1112d8f67a18 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -409,6 +409,7 @@ static int csi_idmac_setup_channel(struct csi_priv *priv)
case V4L2_PIX_FMT_SGBRG16:
case V4L2_PIX_FMT_SGRBG16:
case V4L2_PIX_FMT_SRGGB16:
+ case V4L2_PIX_FMT_Y16:
burst_size = 4;
passthrough = true;
passthrough_bits = 16;
diff --git a/drivers/staging/media/imx/imx-media-utils.c
b/drivers/staging/media/imx/imx-media-utils.c
index fab98fc0d6a0..7ec2db84451c 100644
--- a/drivers/staging/media/imx/imx-media-utils.c
+++ b/drivers/staging/media/imx/imx-media-utils.c
@@ -168,6 +168,15 @@ static const struct imx_media_pixfmt rgb_formats[] = {
.cs = IPUV3_COLORSPACE_RGB,
.bpp= 8,
.bayer = true,
+ }, {
+ .fourcc = V4L2_PIX_FMT_Y16,
+ .codes = {
+ MEDIA_BUS_FMT_Y10_1X10,
+ MEDIA_BUS_FMT_Y12_1X12,
+ },
+ .cs = IPUV3_COLORSPACE_RGB,
+ .bpp= 16,
+ .bayer = true,
},
/***
* non-mbus RGB formats start here. NOTE! when adding non-mbus
Re: [PATCH] media: include/video/omapfb_dss.h: use IS_ENABLED()
On 05/04/2018 01:49 PM, Mauro Carvalho Chehab wrote:
> Just checking for ifdefs cause build issues as reported by
> kernel test:
>
> config: openrisc-allmodconfig (attached as .config)
> compiler: or1k-linux-gcc (GCC) 6.0.0 20160327 (experimental)
>
> All errors (new ones prefixed by >>):
>
>drivers/video/fbdev/omap2/omapfb/omapfb-main.c: In function
> 'omapfb_init_connections':
>>> drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2396:8: error: implicit
>>> declaration of function 'omapdss_find_mgr_from_display'
>>> [-Werror=implicit-function-declaration]
> mgr = omapdss_find_mgr_from_display(def_dssdev);
>^
>drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2396:6: warning: assignment
> makes pointer from integer without a cast [-Wint-conversion]
> mgr = omapdss_find_mgr_from_display(def_dssdev);
> ^
>drivers/video/fbdev/omap2/omapfb/omapfb-main.c: In function
> 'omapfb_find_default_display':
>>> drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2430:13: error: implicit
>>> declaration of function 'omapdss_get_default_display_name'
>>> [-Werror=implicit-function-declaration]
> def_name = omapdss_get_default_display_name();
> ^~~~
>drivers/video/fbdev/omap2/omapfb/omapfb-main.c:2430:11: warning:
> assignment makes pointer from integer without a cast [-Wint-conversion]
> def_name = omapdss_get_default_display_name();
> ^
>
> So, use IS_ENABLED() instead.
Hi,
I would like to test this (the change doesn't make much sense to me),
but I cannot find the kernel config file nor the kernel test robot's
email of this report.
Please include an lkml.kernel.org/r/ reference to such emails
so that interested parties can join the party.
Does this patch apply only to your media tree? so hopefully I can see it in
linux-next on Monday.
Thanks.
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Randy Dunlap
> Cc: tomi.valkei...@ti.com
> Cc: linux-o...@vger.kernel.org
> Cc: linux-fb...@vger.kernel.org
> Fixes: 771f7be87ff9 ("media: omapfb: omapfb_dss.h: add stubs to build with
> COMPILE_TEST && DRM_OMAP")
> Signed-off-by: Mauro Carvalho Chehab
> ---
> include/video/omapfb_dss.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/video/omapfb_dss.h b/include/video/omapfb_dss.h
> index e9775144ff3b..12755d8d9b4f 100644
> --- a/include/video/omapfb_dss.h
> +++ b/include/video/omapfb_dss.h
> @@ -778,7 +778,7 @@ struct omap_dss_driver {
>
> typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
>
> -#ifdef CONFIG_FB_OMAP2
> +#if IS_ENABLED(CONFIG_FB_OMAP2)
>
> enum omapdss_version omapdss_get_version(void);
> bool omapdss_is_initialized(void);
>
--
~Randy
[PATCH 1/2] media: siano: don't use GFP_DMA
I can't think on a single reason why this driver would be using
GFP_DMA. The typical usage is as an USB driver. Any DMA restrictions
should be handled inside the HCI driver, if any.
Cc: "Luis R. Rodriguez"
Cc: linux...@kvack.org
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/common/siano/smscoreapi.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/media/common/siano/smscoreapi.c
b/drivers/media/common/siano/smscoreapi.c
index 1c93258a2d47..a5f0db0810d4 100644
--- a/drivers/media/common/siano/smscoreapi.c
+++ b/drivers/media/common/siano/smscoreapi.c
@@ -697,7 +697,7 @@ int smscore_register_device(struct smsdevice_params_t
*params,
buffer = dma_alloc_coherent(params->device,
dev->common_buffer_size,
&dev->common_buffer_phys,
- GFP_KERNEL | GFP_DMA);
+ GFP_KERNEL);
if (!buffer) {
smscore_unregister_device(dev);
return -ENOMEM;
@@ -792,7 +792,7 @@ static int smscore_init_ir(struct smscore_device_t *coredev)
else {
buffer = kmalloc(sizeof(struct sms_msg_data2) +
SMS_DMA_ALIGNMENT,
- GFP_KERNEL | GFP_DMA);
+ GFP_KERNEL);
if (buffer) {
struct sms_msg_data2 *msg =
(struct sms_msg_data2 *)
@@ -933,7 +933,7 @@ static int smscore_load_firmware_family2(struct
smscore_device_t *coredev,
}
/* PAGE_SIZE buffer shall be enough and dma aligned */
- msg = kmalloc(PAGE_SIZE, GFP_KERNEL | GFP_DMA);
+ msg = kmalloc(PAGE_SIZE, GFP_KERNEL);
if (!msg)
return -ENOMEM;
@@ -1168,7 +1168,7 @@ static int smscore_load_firmware_from_file(struct
smscore_device_t *coredev,
}
pr_debug("read fw %s, buffer size=0x%zx\n", fw_filename, fw->size);
fw_buf = kmalloc(ALIGN(fw->size + sizeof(struct sms_firmware),
-SMS_ALLOC_ALIGNMENT), GFP_KERNEL | GFP_DMA);
+SMS_ALLOC_ALIGNMENT), GFP_KERNEL);
if (!fw_buf) {
pr_err("failed to allocate firmware buffer\n");
rc = -ENOMEM;
@@ -1260,7 +1260,7 @@ EXPORT_SYMBOL_GPL(smscore_unregister_device);
static int smscore_detect_mode(struct smscore_device_t *coredev)
{
void *buffer = kmalloc(sizeof(struct sms_msg_hdr) + SMS_DMA_ALIGNMENT,
- GFP_KERNEL | GFP_DMA);
+ GFP_KERNEL);
struct sms_msg_hdr *msg =
(struct sms_msg_hdr *) SMS_ALIGN_ADDRESS(buffer);
int rc;
@@ -1309,7 +1309,7 @@ static int smscore_init_device(struct smscore_device_t
*coredev, int mode)
int rc = 0;
buffer = kmalloc(sizeof(struct sms_msg_data) +
- SMS_DMA_ALIGNMENT, GFP_KERNEL | GFP_DMA);
+ SMS_DMA_ALIGNMENT, GFP_KERNEL);
if (!buffer)
return -ENOMEM;
@@ -1398,7 +1398,7 @@ int smscore_set_device_mode(struct smscore_device_t
*coredev, int mode)
coredev->device_flags &= ~SMS_DEVICE_NOT_READY;
buffer = kmalloc(sizeof(struct sms_msg_data) +
-SMS_DMA_ALIGNMENT, GFP_KERNEL | GFP_DMA);
+SMS_DMA_ALIGNMENT, GFP_KERNEL);
if (buffer) {
struct sms_msg_data *msg = (struct sms_msg_data *)
SMS_ALIGN_ADDRESS(buffer);
@@ -1971,7 +1971,7 @@ int smscore_gpio_configure(struct smscore_device_t
*coredev, u8 pin_num,
total_len = sizeof(struct sms_msg_hdr) + (sizeof(u32) * 6);
buffer = kmalloc(total_len + SMS_DMA_ALIGNMENT,
- GFP_KERNEL | GFP_DMA);
+ GFP_KERNEL);
if (!buffer)
return -ENOMEM;
@@ -2043,7 +2043,7 @@ int smscore_gpio_set_level(struct smscore_device_t
*coredev, u8 pin_num,
(3 * sizeof(u32)); /* keep it 3 ! */
buffer = kmalloc(total_len + SMS_DMA_ALIGNMENT,
- GFP_KERNEL | GFP_DMA);
+ GFP_KERNEL);
if (!buffer)
return -ENOMEM;
@@ -2091,7 +2091,7 @@ int smscore_gpio_get_level(struct smscore_device_t
*coredev, u8 pin_num,
total_len = sizeof(struct sms_msg_hdr) + (2 * sizeof(u32));
buffer = kmalloc(total_len + SMS_DMA_ALIGNMENT,
- GFP_KERNEL | GFP_DMA);
+ GFP_KERNEL);
if (!buffer)
return -ENOMEM;
--
2.17.0
[PATCH 2/2] media: gp8psk: don't abuse of GFP_DMA
There's s no reason why it should be using GFP_DMA there.
This is an USB driver. Any restriction should be, instead,
at HCI core, if any.
Cc: "Luis R. Rodriguez"
Cc: linux...@kvack.org
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/usb/dvb-usb/gp8psk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb/gp8psk.c
b/drivers/media/usb/dvb-usb/gp8psk.c
index 37f062225ed2..334b9fb98112 100644
--- a/drivers/media/usb/dvb-usb/gp8psk.c
+++ b/drivers/media/usb/dvb-usb/gp8psk.c
@@ -148,7 +148,7 @@ static int gp8psk_load_bcm4500fw(struct dvb_usb_device *d)
info("downloading bcm4500 firmware from file '%s'",bcm4500_firmware);
ptr = fw->data;
- buf = kmalloc(64, GFP_KERNEL | GFP_DMA);
+ buf = kmalloc(64, GFP_KERNEL);
if (!buf) {
ret = -ENOMEM;
goto out_rel_fw;
--
2.17.0
Are media drivers abusing of GFP_DMA? - was: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love
There was a recent discussion about the use/abuse of GFP_DMA flag when
allocating memories at LSF/MM 2018 (see Luis notes enclosed).
The idea seems to be to remove it, using CMA instead. Before doing that,
better to check if what we have on media is are valid use cases for it, or
if it is there just due to some misunderstanding (or because it was
copied from some other code).
Hans de Goede sent us today a patch stopping abuse at gspca, and I'm
also posting today two other patches meant to stop abuse of it on USB
drivers. Still, there are 4 platform drivers using it:
$ git grep -l -E "GFP_DMA\\b" drivers/media/
drivers/media/platform/omap3isp/ispstat.c
drivers/media/platform/sti/bdisp/bdisp-hw.c
drivers/media/platform/sti/hva/hva-mem.c
drivers/media/spi/cxd2880-spi.c
Could you please check if GFP_DMA is really needed there, or if it is
just because of some cut-and-paste from some other place?
Thanks!
Mauro
Em Thu, 26 Apr 2018 21:54:06 +
"Luis R. Rodriguez" escreveu:
> Below are my notes on the ZONE_DMA discussion at LSF/MM 2018. There were some
> earlier discussion prior to my arrival to the session about moving around
> ZOME_DMA around, if someone has notes on that please share too :)
>
> PS. I'm not subscribed to linux-mm
>
> Luis
>
> Determining you don't need to support ZONE_DMA on x86 at run time
> =
>
> In practice if you don't have a floppy device on x86, you don't need ZONE_DMA,
> in that case you dont need to support ZONE_DMA, however currently disabling it
> is only possible at compile time, and we won't know for sure until boot time
> if
> you have such a device. If you don't need ZONE_DMA though means we would not
> have to deal with slab allocators for them and special casings for it in a
> slew
> of places. In particular even kmalloc() has a branch which is always run if
> CONFIG_ZONE_DMA is enabled.
>
> ZONE_DMA is needed for old devices that requires lower addresses since it
> allows
> allocations more reliably. There should be more devices that require this,
> not just floppy though.
>
> Christoph Lameter added CONFIG_ZONE_DMA to disable ZONE_DMA at build time but
> most distributions enable this. If we could disable ZONE_DMA at run time once
> we know we don't have any device present requiring it we could get the same
> benefit of compiling without CONFIG_ZONE_DMA at run time.
>
> It used to be that disabling CONFIG_ZONE_DMA could help with performance, we
> don't seem to have modern benchmarks over possible gains on removing it.
> Are the gains no longer expected to be significant? Very likely there are
> no performance gains. The assumption then is that the main advantage over
> being able to disable ZONE_DMA on x86 these days would be pure aesthetics, and
> having x86 work more like other architectures with allocations. Use of
> ZONE_DMA
> on drivers are also good signs these drivers are old, or may be deprecated.
> Perhaps some of these on x86 should be moved to staging.
>
> Note that some architectures rely on ZONE_DMA as well, the above notes
> only applies to x86.
>
> We can use certain kernel mechanisms to disable usage of x86 certain features
> at run time. Below are a few options:
>
> * x86 binary patching
> * ACPI_SIG_FADT
> * static keys
> * compiler multiverse (at least the R&D gcc proof of concept is now
> complete)
>
> Detecting legacy x86 devices with ACPI ACPI_SIG_FADT
>
>
> We could expand on ACPI_SIG_FADT with more legacy devices. This mechanism was
> used to help determine if certain legacy x86 devices are present or not with
> paravirtualization. For instance:
>
> * ACPI_FADT_NO_VGA
> * ACPI_FADT_NO_CMOS_RTC
>
> CONFIG_ZONE_DMA
> ---
>
> Christoph Lameter added CONFIG_ZONE_DMA through commit 4b51d66989218
> ("[PATCH] optional ZONE_DMA: optional ZONE_DMA in the VM") merged on
> v2.6.21.
>
> On x86 ZONE_DMA is defined as follows:
>
> config ZONE_DMA
> bool "DMA memory allocation support" if EXPERT
> default y
> help
> DMA memory allocation support allows devices with less than 32-bit
> addressing to allocate within the first 16MB of address space.
> Disable if no such devices will be used.
>
>
> If unsure, say Y.
>
> Most distributions enable CONFIG_ZONE_DMA.
>
> Immediate impact of CONFIG_ZONE_DMA
> ---
>
> CONFIG_ZONE_DMA implicaates kmalloc() as follows:
>
> struct kmem_cache *kmalloc_slab(size_t size, gfp_t flags)
> {
> ...
> #ifdef CONFIG_ZONE_DMA
> if (unlikely((flags & GFP_DMA)))
> return kmalloc_dma_caches[index];
> #endif
> ...
> }
>
> ZONE_DMA users
> ==
>
> Turns out there are much more users of ZONE_DMA than expected eve
[PATCH] media: siano: don't use GFP_DMA
I can't think on a single reason why this driver would be using
GFP_DMA. The typical usage is as an USB driver. Any DMA restrictions
should be handled inside the HCI driver, if any.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/common/siano/smscoreapi.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/media/common/siano/smscoreapi.c
b/drivers/media/common/siano/smscoreapi.c
index 1c93258a2d47..a5f0db0810d4 100644
--- a/drivers/media/common/siano/smscoreapi.c
+++ b/drivers/media/common/siano/smscoreapi.c
@@ -697,7 +697,7 @@ int smscore_register_device(struct smsdevice_params_t
*params,
buffer = dma_alloc_coherent(params->device,
dev->common_buffer_size,
&dev->common_buffer_phys,
- GFP_KERNEL | GFP_DMA);
+ GFP_KERNEL);
if (!buffer) {
smscore_unregister_device(dev);
return -ENOMEM;
@@ -792,7 +792,7 @@ static int smscore_init_ir(struct smscore_device_t *coredev)
else {
buffer = kmalloc(sizeof(struct sms_msg_data2) +
SMS_DMA_ALIGNMENT,
- GFP_KERNEL | GFP_DMA);
+ GFP_KERNEL);
if (buffer) {
struct sms_msg_data2 *msg =
(struct sms_msg_data2 *)
@@ -933,7 +933,7 @@ static int smscore_load_firmware_family2(struct
smscore_device_t *coredev,
}
/* PAGE_SIZE buffer shall be enough and dma aligned */
- msg = kmalloc(PAGE_SIZE, GFP_KERNEL | GFP_DMA);
+ msg = kmalloc(PAGE_SIZE, GFP_KERNEL);
if (!msg)
return -ENOMEM;
@@ -1168,7 +1168,7 @@ static int smscore_load_firmware_from_file(struct
smscore_device_t *coredev,
}
pr_debug("read fw %s, buffer size=0x%zx\n", fw_filename, fw->size);
fw_buf = kmalloc(ALIGN(fw->size + sizeof(struct sms_firmware),
-SMS_ALLOC_ALIGNMENT), GFP_KERNEL | GFP_DMA);
+SMS_ALLOC_ALIGNMENT), GFP_KERNEL);
if (!fw_buf) {
pr_err("failed to allocate firmware buffer\n");
rc = -ENOMEM;
@@ -1260,7 +1260,7 @@ EXPORT_SYMBOL_GPL(smscore_unregister_device);
static int smscore_detect_mode(struct smscore_device_t *coredev)
{
void *buffer = kmalloc(sizeof(struct sms_msg_hdr) + SMS_DMA_ALIGNMENT,
- GFP_KERNEL | GFP_DMA);
+ GFP_KERNEL);
struct sms_msg_hdr *msg =
(struct sms_msg_hdr *) SMS_ALIGN_ADDRESS(buffer);
int rc;
@@ -1309,7 +1309,7 @@ static int smscore_init_device(struct smscore_device_t
*coredev, int mode)
int rc = 0;
buffer = kmalloc(sizeof(struct sms_msg_data) +
- SMS_DMA_ALIGNMENT, GFP_KERNEL | GFP_DMA);
+ SMS_DMA_ALIGNMENT, GFP_KERNEL);
if (!buffer)
return -ENOMEM;
@@ -1398,7 +1398,7 @@ int smscore_set_device_mode(struct smscore_device_t
*coredev, int mode)
coredev->device_flags &= ~SMS_DEVICE_NOT_READY;
buffer = kmalloc(sizeof(struct sms_msg_data) +
-SMS_DMA_ALIGNMENT, GFP_KERNEL | GFP_DMA);
+SMS_DMA_ALIGNMENT, GFP_KERNEL);
if (buffer) {
struct sms_msg_data *msg = (struct sms_msg_data *)
SMS_ALIGN_ADDRESS(buffer);
@@ -1971,7 +1971,7 @@ int smscore_gpio_configure(struct smscore_device_t
*coredev, u8 pin_num,
total_len = sizeof(struct sms_msg_hdr) + (sizeof(u32) * 6);
buffer = kmalloc(total_len + SMS_DMA_ALIGNMENT,
- GFP_KERNEL | GFP_DMA);
+ GFP_KERNEL);
if (!buffer)
return -ENOMEM;
@@ -2043,7 +2043,7 @@ int smscore_gpio_set_level(struct smscore_device_t
*coredev, u8 pin_num,
(3 * sizeof(u32)); /* keep it 3 ! */
buffer = kmalloc(total_len + SMS_DMA_ALIGNMENT,
- GFP_KERNEL | GFP_DMA);
+ GFP_KERNEL);
if (!buffer)
return -ENOMEM;
@@ -2091,7 +2091,7 @@ int smscore_gpio_get_level(struct smscore_device_t
*coredev, u8 pin_num,
total_len = sizeof(struct sms_msg_hdr) + (2 * sizeof(u32));
buffer = kmalloc(total_len + SMS_DMA_ALIGNMENT,
- GFP_KERNEL | GFP_DMA);
+ GFP_KERNEL);
if (!buffer)
return -ENOMEM;
--
2.17.0
[linuxtv-media:master] BUILD REGRESSION 8d718e5376c602dfd41b599dcc2a7b1be07c7b6b
tree/branch: git://linuxtv.org/media_tree.git master branch HEAD: 8d718e5376c602dfd41b599dcc2a7b1be07c7b6b media: frontends: fix ops get_algo()'s return type Regressions in current branch: drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c:183:21: error: 'omapdss_default_get_resolution' undeclared here (not in a function); did you mean 'omapdss_get_version'? drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c:197:7: error: implicit declaration of function 'omap_dss_find_output'; did you mean 'omap_dss_get_overlay'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c:219:7: error: implicit declaration of function 'omapdss_of_find_source_for_first_ep' [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c:264:6: error: implicit declaration of function 'omapdss_register_display'; did you mean 'omap_dispc_register_isr'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c:282:2: error: implicit declaration of function 'omapdss_unregister_display'; did you mean 'omap_dispc_unregister_isr'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c:57:6: error: implicit declaration of function 'omapdss_device_is_connected' [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c:91:6: error: implicit declaration of function 'omapdss_device_is_enabled'; did you mean 'movable_node_is_enabled'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c:232:20: error: 'omapdss_default_get_resolution' undeclared here (not in a function); did you mean 'omapdss_get_version'? drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c:246:7: error: implicit declaration of function 'omapdss_of_find_source_for_first_ep' [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c:297:6: error: implicit declaration of function 'omapdss_register_display'; did you mean 'omap_dispc_register_isr'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c:319:2: error: implicit declaration of function 'omapdss_unregister_display'; did you mean 'omap_dispc_unregister_isr'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c:59:6: error: implicit declaration of function 'omapdss_device_is_connected' [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c:89:6: error: implicit declaration of function 'omapdss_device_is_enabled'; did you mean 'movable_node_is_enabled'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c:200:21: error: 'omapdss_default_get_resolution' undeclared here (not in a function); did you mean 'omapdss_get_version'? drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c:222:7: error: implicit declaration of function 'omapdss_of_find_source_for_first_ep' [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c:269:6: error: implicit declaration of function 'omapdss_register_display'; did you mean 'omap_dispc_register_isr'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c:287:2: error: implicit declaration of function 'omapdss_unregister_display'; did you mean 'omap_dispc_unregister_isr'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c:60:6: error: implicit declaration of function 'omapdss_device_is_connected' [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c:94:6: error: implicit declaration of function 'omapdss_device_is_enabled'; did you mean 'movable_node_is_enabled'? [-Werror=implicit-function-declaration] 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] 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] 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] drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:45:6: error: implicit declaration of function 'omapdss_device_is_connected' [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:91:6: error: implicit declaration of function 'omapdss_device_is_enabled'; did you mean 'movable_node_is_enabled'? [-W
[PATCH] [bug] cx231xx: Fix recursive dependency
0day build bot reported an unnoticed recursive dependency, fix it
by removing the select statement.
fixes: c66d4d99a8fb ("cx231xx: Add I2C_MUX dependency")
Signed-off-by: Brad Love
---
drivers/media/usb/cx231xx/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/usb/cx231xx/Kconfig
b/drivers/media/usb/cx231xx/Kconfig
index 98890a3..1b11ae1 100644
--- a/drivers/media/usb/cx231xx/Kconfig
+++ b/drivers/media/usb/cx231xx/Kconfig
@@ -6,7 +6,6 @@ config VIDEO_CX231XX
select VIDEOBUF_VMALLOC
select VIDEO_CX25840
select VIDEO_CX2341X
- select I2C_MUX
---help---
This is a video4linux driver for Conexant 231xx USB based TV cards.
--
2.7.4
Re: [PATCH v3 0/8] R-Car DU: Support CRC calculation
Em Sat, 05 May 2018 17:06:50 +0300 Laurent Pinchart escreveu: > Hi Daniel, > > (CC'ing Mauro) > > On Thursday, 3 May 2018 16:45:36 EEST Daniel Vetter wrote: > > On Thu, May 3, 2018 at 2:06 PM, Laurent Pinchart wrote: > > > Hi Dave, > > > > > > Ping ? > > > > Not aware of any crc core work going on in drm, so has my ack. > > Thank you. > > > Worst case we do a topic branch or something like that (since I guess you'll > > do a pull request anyway on the v4l side). > > That would unfortunately not be possible, as Mauro cherry-picks patches > instead of merging pull requests. In rare cases I can ask for a pull-request > to be merged as-is, but it's too late in this case as the previous pull > request that this series is based on has been cherry-picked, not merged. I probably missed something, but I fail to see what's the problem. If DRM needs a patch that was already merged on our tree, I can gladly create a stable branch/tag for it - well, media master branch is stable, but I can add a tag there just after the patch DRM needs, in order to avoid them to merge from us at some random point. If otherwise we need a patch applied at DRM, they can do the same: create a branch/tag, and I can pull from it. Thanks, Mauro
Re: [RFC PATCH] media: i2c: add SCCB helpers
Em Fri, 27 Apr 2018 01:13:32 +0900
Akinobu Mita escreveu:
> (This patch is in prototype stage)
>
> This adds SCCB helper functions (sccb_read_byte and sccb_write_byte) that
> are intended to be used by some of Omnivision sensor drivers.
What do you mean by "SCCB"?
>
> The ov772x driver is going to use these functions in order to make it work
> with most i2c controllers.
>
> As the ov772x device doesn't support repeated starts, this driver currently
> requires I2C_FUNC_PROTOCOL_MANGLING that is not supported by many i2c
> controller drivers.
>
> With the sccb_read_byte() that issues two separated requests in order to
> avoid repeated start, the driver doesn't require I2C_FUNC_PROTOCOL_MANGLING.
>
> Cc: Wolfram Sang
> Cc: Jacopo Mondi
> Cc: Laurent Pinchart
> Cc: Hans Verkuil
> Cc: Sakari Ailus
> Cc: Mauro Carvalho Chehab
> Signed-off-by: Akinobu Mita
> ---
> drivers/media/i2c/Kconfig | 4
> drivers/media/i2c/Makefile | 1 +
> drivers/media/i2c/sccb.c | 35 +++
> drivers/media/i2c/sccb.h | 14 ++
> 4 files changed, 54 insertions(+)
> create mode 100644 drivers/media/i2c/sccb.c
> create mode 100644 drivers/media/i2c/sccb.h
>
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 541f0d28..19e5601 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -569,6 +569,9 @@ config VIDEO_THS8200
>
> comment "Camera sensor devices"
>
> +config SCCB
> + bool
> +
> config VIDEO_APTINA_PLL
> tristate
>
> @@ -692,6 +695,7 @@ config VIDEO_OV772X
> tristate "OmniVision OV772x sensor support"
> depends on I2C && VIDEO_V4L2
> depends on MEDIA_CAMERA_SUPPORT
> + select SCCB
> ---help---
> This is a Video4Linux2 sensor-level driver for the OmniVision
> OV772x camera.
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index ea34aee..82fbd78 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -62,6 +62,7 @@ obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
> obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
> obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
> obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
> +obj-$(CONFIG_SCCB) += sccb.o
> obj-$(CONFIG_VIDEO_OV2640) += ov2640.o
> obj-$(CONFIG_VIDEO_OV2685) += ov2685.o
> obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
> diff --git a/drivers/media/i2c/sccb.c b/drivers/media/i2c/sccb.c
> new file mode 100644
> index 000..80a3fb7
> --- /dev/null
> +++ b/drivers/media/i2c/sccb.c
> @@ -0,0 +1,35 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include
> +
> +int sccb_read_byte(struct i2c_client *client, u8 addr)
> +{
> + int ret;
> + u8 val;
> +
> + /* Issue two separated requests in order to avoid repeated start */
> +
> + ret = i2c_master_send(client, &addr, 1);
> + if (ret < 0)
> + return ret;
> +
> + ret = i2c_master_recv(client, &val, 1);
> + if (ret < 0)
> + return ret;
Handling it this way is a very bad idea, as you may have an operation
between those two, as you're locking/unlocking for each i2c_master
call, e. g. the code should be, instead:
i2c_lock_adapter();
__i2c_transfer(); /* Send */
__i2c_transfer(); /* Receive */
i2c_unlock_adapter();
Also, if the problem is just due to I2C not supporting REPEAT, IMHO,
the best would be to add some IRC flag to indicate that.
Btw, this is not the first device that doesn't support repeats.
A good hint of drivers with similar issues is:
$ git grep i2c_lock_adapter drivers/media/
drivers/media/dvb-frontends/af9013.c:
i2c_lock_adapter(client->adapter);
drivers/media/dvb-frontends/af9013.c:
i2c_lock_adapter(client->adapter);
drivers/media/dvb-frontends/drxk_hard.c:i2c_lock_adapter(state->i2c);
drivers/media/dvb-frontends/rtl2830.c: i2c_lock_adapter(client->adapter);
drivers/media/dvb-frontends/rtl2830.c: i2c_lock_adapter(client->adapter);
drivers/media/dvb-frontends/rtl2830.c: i2c_lock_adapter(client->adapter);
drivers/media/dvb-frontends/tda1004x.c: i2c_lock_adapter(state->i2c);
drivers/media/tuners/tda18271-common.c:
i2c_lock_adapter(priv->i2c_props.adap);
drivers/media/tuners/tda18271-common.c: i2c_lock_adapter(priv->i2c_props.adap);
Regards,
Mauro
Charity Gift !!!
-- This is the second time i am sending you this mail. I, Mavis Wanczyk donates $ 5 Million Dollars from part of my Powerball Jackpot Lottery of $ 758 Million Dollars, respond with your details for claims. I await your earliest response and God Bless you Good luck. Mavis Wanczyk
[linuxtv-media:master 167/254] drivers/video/fbdev//omap2/omapfb/dss/overlay.c:41:5: error: redefinition of 'omap_dss_get_num_overlays'
tree: git://linuxtv.org/media_tree.git master
head: 8d718e5376c602dfd41b599dcc2a7b1be07c7b6b
commit: 771f7be87ff921e9a3d744febd606af39a150e14 [167/254] media: omapfb:
omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP
config: sh-allmodconfig (attached as .config)
compiler: sh4-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=sh
All errors (new ones prefixed by >>):
>> drivers/video/fbdev//omap2/omapfb/dss/overlay.c:41:5: error: redefinition of
>> 'omap_dss_get_num_overlays'
int omap_dss_get_num_overlays(void)
^
In file included from drivers/video/fbdev//omap2/omapfb/dss/overlay.c:33:0:
include/video/omapfb_dss.h:900:19: note: previous definition of
'omap_dss_get_num_overlays' was here
static inline int omap_dss_get_num_overlays(void)
^
>> drivers/video/fbdev//omap2/omapfb/dss/overlay.c:47:22: error: redefinition
>> of 'omap_dss_get_overlay'
struct omap_overlay *omap_dss_get_overlay(int num)
^~~~
In file included from drivers/video/fbdev//omap2/omapfb/dss/overlay.c:33:0:
include/video/omapfb_dss.h:903:36: note: previous definition of
'omap_dss_get_overlay' was here
static inline struct omap_overlay *omap_dss_get_overlay(int num)
^~~~
drivers/video/fbdev//omap2/omapfb/dss/overlay.c: In function
'dss_init_overlays':
>> drivers/video/fbdev//omap2/omapfb/dss/overlay.c:60:17: error: implicit
>> declaration of function 'dss_feat_get_num_ovls'; did you mean
>> 'dss_feat_get_reg_field'? [-Werror=implicit-function-declaration]
num_overlays = dss_feat_get_num_ovls();
^
dss_feat_get_reg_field
drivers/video/fbdev//omap2/omapfb/dss/overlay.c:91:4: error: implicit
declaration of function 'dss_feat_get_supported_color_modes'; did you mean
'dss_feat_get_supported_outputs'? [-Werror=implicit-function-declaration]
dss_feat_get_supported_color_modes(ovl->id);
^~
dss_feat_get_supported_outputs
cc1: some warnings being treated as errors
--
drivers/video/fbdev//omap2/omapfb/dss/apply.c: In function 'apply_init_priv':
>> drivers/video/fbdev//omap2/omapfb/dss/apply.c:141:23: error: implicit
>> declaration of function 'dss_feat_get_num_ovls'; did you mean
>> 'dss_feat_get_reg_field'? [-Werror=implicit-function-declaration]
const int num_ovls = dss_feat_get_num_ovls();
^
dss_feat_get_reg_field
drivers/video/fbdev//omap2/omapfb/dss/apply.c: In function 'need_isr':
>> drivers/video/fbdev//omap2/omapfb/dss/apply.c:264:23: error: implicit
>> declaration of function 'dss_feat_get_num_mgrs'; did you mean
>> 'dss_feat_get_param_max'? [-Werror=implicit-function-declaration]
const int num_mgrs = dss_feat_get_num_mgrs();
^
dss_feat_get_param_max
drivers/video/fbdev//omap2/omapfb/dss/apply.c: At top level:
drivers/video/fbdev//omap2/omapfb/dss/apply.c:1598:5: error: redefinition of
'omapdss_compat_init'
int omapdss_compat_init(void)
^~~
In file included from drivers/video/fbdev//omap2/omapfb/dss/apply.c:26:0:
include/video/omapfb_dss.h:889:19: note: previous definition of
'omapdss_compat_init' was here
static inline int omapdss_compat_init(void)
^~~
drivers/video/fbdev//omap2/omapfb/dss/apply.c:1682:6: error: redefinition of
'omapdss_compat_uninit'
void omapdss_compat_uninit(void)
^
In file included from drivers/video/fbdev//omap2/omapfb/dss/apply.c:26:0:
include/video/omapfb_dss.h:892:20: note: previous definition of
'omapdss_compat_uninit' was here
static inline void omapdss_compat_uninit(void) {};
^
cc1: some warnings being treated as errors
--
drivers/video/fbdev//omap2/omapfb/dss/dpi.c: In function 'dpi_connect':
drivers/video/fbdev//omap2/omapfb/dss/dpi.c:680:6: error: implicit
declaration of function 'omapdss_output_set_device'; did you mean
'omap_dss_put_device'? [-Werror=implicit-function-declaration]
r = omapdss_output_set_device(dssdev, dst);
^
omap_dss_put_device
drivers/video/fbdev//omap2/omapfb/dss/dpi.c: In function 'dpi_disconnect':
drivers/video/fbdev//omap2/omapfb/dss/dpi.c:699:2: error: implicit
declaration of function 'omapdss_output_unset_device'; did you mean
'omap_dss_get_next_device'? [-Werror
Re: [PATCH v3 0/8] R-Car DU: Support CRC calculation
Hi Daniel, (CC'ing Mauro) On Thursday, 3 May 2018 16:45:36 EEST Daniel Vetter wrote: > On Thu, May 3, 2018 at 2:06 PM, Laurent Pinchart wrote: > > Hi Dave, > > > > Ping ? > > Not aware of any crc core work going on in drm, so has my ack. Thank you. > Worst case we do a topic branch or something like that (since I guess you'll > do a pull request anyway on the v4l side). That would unfortunately not be possible, as Mauro cherry-picks patches instead of merging pull requests. In rare cases I can ask for a pull-request to be merged as-is, but it's too late in this case as the previous pull request that this series is based on has been cherry-picked, not merged. > Acked-by: me. > > > On Saturday, 28 April 2018 23:50:19 EEST Laurent Pinchart wrote: > >> Hello, > >> > >> (Dave, there's a request for you below) > >> > >> This patch series adds support for CRC calculation to the rcar-du-drm > >> driver. > >> > >> CRC calculation is supported starting at the Renesas R-Car Gen3 SoCs, as > >> earlier versions don't have the necessary hardware. On Gen3 SoCs, the CRC > >> is computed by the DISCOM module part of the VSP-D and VSP-DL. > >> > >> The DISCOM is interfaced to the VSP through the UIF glue and appears as a > >> VSP entity with a sink pad and a source pad. > >> > >> The series starts with a switch to SPDX license headers in patch 1/8, > >> prompted by a checkpatch.pl warning for a later patch that complained > >> about missing SPDX license headers. It then continues with cleanup and > >> refactoring. Patches 2/8 and 3/8 prepare for DISCOM and UIF support by > >> extending generic code to make it usable for the UIF. Patch 4/8 documents > >> a structure that will receive new fields. > >> > >> Patch 5/8 then extends the API exposed by the VSP driver to the DU driver > >> to support CRC computation configuration and reporting. The patch > >> unfortunately needs to touch both the VSP and DU drivers, so the whole > >> series will need to be merged through a single tree. > >> > >> Patch 5/8 adds support for the DISCOM and UIF in the VSP driver, patch > >> 7/8 integrates it in the DRM pipeline, and patch 8/8 finally implements > >> the CRC API in the DU driver to expose CRC computation to userspace. > >> > >> The hardware supports computing the CRC at any arbitrary point in the > >> pipeline on a configurable window of the frame. This patch series > >> supports CRC computation on input planes or pipeline output, but on the > >> full frame only. Support for CRC window configuration can be added later > >> if needed but will require extending the userspace API, as the DRM/KMS > >> CRC API doesn't support this feature. > >> > >> Compared to v1, the CRC source names for plane inputs are now constructed > >> from plane IDs instead of plane indices. This allows userspace to match > >> CRC sources with planes. > >> > >> Compared to v2, various small issues reported by reviewers have been > >> fixed. I believe the series to now be ready for upstream merge. > >> > >> Note that exposing the DISCOM and UIF though the V4L2 API isn't supported > >> as the module is only found in VSP-D and VSP-DL instances that are not > >> exposed through V4L2. It is possible to expose those instances through > >> V4L2 with a small modification to the driver for testing purpose. If the > >> need arises to test DISCOM and UIF with such an out-of-tree patch, > >> support for CRC reporting through a V4L2 control can be added later > >> without affecting how CRC is exposed through the DRM/KMS API. > >> > >> The patches are based on top of the "[PATCH v2 00/15] R-Car VSP1: > >> Dynamically assign blend units to display pipelines" patch series, itself > >> based on top of the Linux media master branch and scheduled for merge in > >> v4.18. The new base caused heavy conflicts, requiring this series to be > >> merged through the V4L2 tree. > >> > >> Dave, I have verified that this series merges cleanly with your drm-next > >> and drm-fixes branches, with the drm-misc-next and drm-misc-fixes > >> branches, and with the R-Car DU patches I would like to get merged in > >> v4.18 through your tree. Could I get your ack to merge this through the > >> V4L2 tree ? > >> > >> For convenience the patches are available at > >> > >> git://linuxtv.org/pinchartl/media.git vsp1-discom-v3-20180428 > >> > >> The code has been tested through the kms-test-crc.py script part of the > >> DU test suite available at > >> > >> git://git.ideasonboard.com/renesas/kms-tests.git discom > >> > >> Laurent Pinchart (8): > >> v4l: vsp1: Use SPDX license headers > >> v4l: vsp1: Share the CLU, LIF and LUT set_fmt pad operation code > >> v4l: vsp1: Reset the crop and compose rectangles in the set_fmt helper > >> v4l: vsp1: Document the vsp1_du_atomic_config structure > >> v4l: vsp1: Extend the DU API to support CRC computation > >> v4l: vsp1: Add support for the DISCOM entity > >> v4l: vsp1: Integrate DISCOM in display pipeline > >
[GIT PULL FOR v4.18] VSP1 & DU CRC calculation support
Hi Mauro, The following changes since commit f2bea20ec56234a8ca8ec4a3481b744b3e0e8813: media: cx231xx: remove a now unused var (2018-05-05 08:55:29 -0400) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git v4l2/vsp1/discom for you to fetch changes up to dcdd25c0d98f19fffc7099b3a09f7f47c2125296: drm: rcar-du: Add support for CRC computation (2018-05-05 16:56:55 +0300) Please note that the series contains changes for the DRM tree in patch 8/8. I have checked that they don't conflict with anything queued in the drm or drm- misc trees for v4.18. Given that the series depends on the VSP BRU-BRS series that you have merged recently for v4.18, the easiest course of action is to get this merged through your tree. Daniel Vetter and Dave Airlie (both CC'ed) have given their ack for this (see [1] and [2]). [1] https://www.spinics.net/lists/dri-devel/msg175198.html [2] https://www.spinics.net/lists/dri-devel/msg175259.html Laurent Pinchart (8): v4l: vsp1: Use SPDX license headers v4l: vsp1: Share the CLU, LIF and LUT set_fmt pad operation code v4l: vsp1: Reset the crop and compose rectangles in the set_fmt helper v4l: vsp1: Document the vsp1_du_atomic_config structure v4l: vsp1: Extend the DU API to support CRC computation v4l: vsp1: Add support for the DISCOM entity v4l: vsp1: Integrate DISCOM in display pipeline drm: rcar-du: Add support for CRC computation drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 156 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 15 +++ drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 12 +- drivers/media/platform/vsp1/Makefile | 2 +- drivers/media/platform/vsp1/vsp1.h| 10 +- drivers/media/platform/vsp1/vsp1_brx.c| 6 +- drivers/media/platform/vsp1/vsp1_brx.h| 6 +- drivers/media/platform/vsp1/vsp1_clu.c| 71 ++ drivers/media/platform/vsp1/vsp1_clu.h| 6 +- drivers/media/platform/vsp1/vsp1_dl.c | 8 +- drivers/media/platform/vsp1/vsp1_dl.h | 6 +- drivers/media/platform/vsp1/vsp1_drm.c| 127 -- drivers/media/platform/vsp1/vsp1_drm.h| 15 ++- drivers/media/platform/vsp1/vsp1_drv.c| 26 +++- drivers/media/platform/vsp1/vsp1_entity.c | 103 ++- drivers/media/platform/vsp1/vsp1_entity.h | 13 +- drivers/media/platform/vsp1/vsp1_hgo.c| 6 +- drivers/media/platform/vsp1/vsp1_hgo.h| 6 +- drivers/media/platform/vsp1/vsp1_hgt.c| 6 +- drivers/media/platform/vsp1/vsp1_hgt.h| 6 +- drivers/media/platform/vsp1/vsp1_histo.c | 65 + drivers/media/platform/vsp1/vsp1_histo.h | 6 +- drivers/media/platform/vsp1/vsp1_hsit.c | 6 +- drivers/media/platform/vsp1/vsp1_hsit.h | 6 +- drivers/media/platform/vsp1/vsp1_lif.c| 71 ++ drivers/media/platform/vsp1/vsp1_lif.h| 6 +- drivers/media/platform/vsp1/vsp1_lut.c| 71 ++ drivers/media/platform/vsp1/vsp1_lut.h| 6 +- drivers/media/platform/vsp1/vsp1_pipe.c | 6 +- drivers/media/platform/vsp1/vsp1_pipe.h | 6 +- drivers/media/platform/vsp1/vsp1_regs.h | 46 ++- drivers/media/platform/vsp1/vsp1_rpf.c| 6 +- drivers/media/platform/vsp1/vsp1_rwpf.c | 6 +- drivers/media/platform/vsp1/vsp1_rwpf.h | 6 +- drivers/media/platform/vsp1/vsp1_sru.c| 6 +- drivers/media/platform/vsp1/vsp1_sru.h| 6 +- drivers/media/platform/vsp1/vsp1_uds.c| 6 +- drivers/media/platform/vsp1/vsp1_uds.h| 6 +- drivers/media/platform/vsp1/vsp1_uif.c| 271 + drivers/media/platform/vsp1/vsp1_uif.h| 32 + drivers/media/platform/vsp1/vsp1_video.c | 6 +- drivers/media/platform/vsp1/vsp1_video.h | 6 +- drivers/media/platform/vsp1/vsp1_wpf.c| 6 +- include/media/vsp1.h | 45 ++- 44 files changed, 892 insertions(+), 417 deletions(-) create mode 100644 drivers/media/platform/vsp1/vsp1_uif.c create mode 100644 drivers/media/platform/vsp1/vsp1_uif.h -- Regards, Laurent Pinchart
Re: [GIT FIXES FOR v4.17] UVC fixes
Hi Mauro, On Saturday, 5 May 2018 13:35:38 EEST Mauro Carvalho Chehab wrote: > Em Wed, 25 Apr 2018 03:37:00 +0300 Laurent Pinchart escreveu: > > Hi Mauro, > > > > The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: > > Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) > > > > are available in the Git repository at: > > git://linuxtv.org/pinchartl/media.git uvc/fixes > > > > for you to fetch changes up to 3f22b63e8a488156467da43cdf9a3a7bd683f161: > > media: uvcvideo: Prevent setting unavailable flags (2018-04-25 03:16:42 > > > > +0300) > > Not sure what happened here, but this e-mail is completely mangled. > This way, patchwork won't parse it. > > I manually applied it, but next time please check if your emailer > is not messing with pull requests. I really don't know what happened, I've used the same mailer as usual, nothing changed in my workflow :-/ I'll keep an eye on that when submitting the next pull request. Thank you for applying the patch. > > > > > > Kieran Bingham (1): > > media: uvcvideo: Prevent setting unavailable flags > > > > drivers/media/usb/uvc/uvc_ctrl.c | 17 + > > 1 file changed, 9 insertions(+), 8 deletions(-) -- Regards, Laurent Pinchart
Re: [PATCH 1/7] i2c: i2c-gpio: move header to platform_data
Em Thu, 19 Apr 2018 22:00:07 +0200
Wolfram Sang escreveu:
> This header only contains platform_data. Move it to the proper directory.
>
> Signed-off-by: Wolfram Sang
> ---
> MAINTAINERS | 2 +-
> arch/arm/mach-ks8695/board-acs5k.c | 2 +-
> arch/arm/mach-omap1/board-htcherald.c| 2 +-
> arch/arm/mach-pxa/palmz72.c | 2 +-
> arch/arm/mach-pxa/viper.c| 2 +-
> arch/arm/mach-sa1100/simpad.c| 2 +-
> arch/mips/alchemy/board-gpr.c| 2 +-
> drivers/i2c/busses/i2c-gpio.c| 2 +-
> drivers/media/platform/marvell-ccic/mmp-driver.c | 2 +-
Acked-by: Mauro Carvalho Chehab
> drivers/mfd/sm501.c | 2 +-
> include/linux/{ => platform_data}/i2c-gpio.h | 0
> 11 files changed, 10 insertions(+), 10 deletions(-)
> rename include/linux/{ => platform_data}/i2c-gpio.h (100%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0a1410d5a621..7aad64b62102 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5872,7 +5872,7 @@ GENERIC GPIO I2C DRIVER
> M: Haavard Skinnemoen
> S: Supported
> F: drivers/i2c/busses/i2c-gpio.c
> -F: include/linux/i2c-gpio.h
> +F: include/linux/platform_data/i2c-gpio.h
>
> GENERIC GPIO I2C MULTIPLEXER DRIVER
> M: Peter Korsgaard
> diff --git a/arch/arm/mach-ks8695/board-acs5k.c
> b/arch/arm/mach-ks8695/board-acs5k.c
> index 937eb1d47e7b..ef835d82cdb9 100644
> --- a/arch/arm/mach-ks8695/board-acs5k.c
> +++ b/arch/arm/mach-ks8695/board-acs5k.c
> @@ -19,7 +19,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
>
> #include
> diff --git a/arch/arm/mach-omap1/board-htcherald.c
> b/arch/arm/mach-omap1/board-htcherald.c
> index 67d46690a56e..da8f3fc3180f 100644
> --- a/arch/arm/mach-omap1/board-htcherald.c
> +++ b/arch/arm/mach-omap1/board-htcherald.c
> @@ -31,7 +31,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> diff --git a/arch/arm/mach-pxa/palmz72.c b/arch/arm/mach-pxa/palmz72.c
> index 5877e547cecd..c053c8ce1586 100644
> --- a/arch/arm/mach-pxa/palmz72.c
> +++ b/arch/arm/mach-pxa/palmz72.c
> @@ -30,7 +30,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
>
> #include
> diff --git a/arch/arm/mach-pxa/viper.c b/arch/arm/mach-pxa/viper.c
> index 90d0f277de55..39e05b7008d8 100644
> --- a/arch/arm/mach-pxa/viper.c
> +++ b/arch/arm/mach-pxa/viper.c
> @@ -35,7 +35,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> diff --git a/arch/arm/mach-sa1100/simpad.c b/arch/arm/mach-sa1100/simpad.c
> index ace010479eb6..49a61e6f3c5f 100644
> --- a/arch/arm/mach-sa1100/simpad.c
> +++ b/arch/arm/mach-sa1100/simpad.c
> @@ -37,7 +37,7 @@
> #include
> #include
> #include
> -#include
> +#include
>
> #include "generic.h"
>
> diff --git a/arch/mips/alchemy/board-gpr.c b/arch/mips/alchemy/board-gpr.c
> index 4e79dbd54a33..fa75d75b5ba9 100644
> --- a/arch/mips/alchemy/board-gpr.c
> +++ b/arch/mips/alchemy/board-gpr.c
> @@ -29,7 +29,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
> index 58abb3eced58..005e6e0330c2 100644
> --- a/drivers/i2c/busses/i2c-gpio.c
> +++ b/drivers/i2c/busses/i2c-gpio.c
> @@ -11,7 +11,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
> b/drivers/media/platform/marvell-ccic/mmp-driver.c
> index 816f4b6a7b8e..d9f0dd0d3525 100644
> --- a/drivers/media/platform/marvell-ccic/mmp-driver.c
> +++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
> @@ -12,7 +12,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c
> index ad774161a22d..66af659b01b2 100644
> --- a/drivers/mfd/sm501.c
> +++ b/drivers/mfd/sm501.c
> @@ -19,7 +19,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
>
> diff --git a/include/linux/i2c-gpio.h b/include/linux/platform_data/i2c-gpio.h
> similarity index 100%
> rename from include/linux/i2c-gpio.h
> rename to include/linux/platform_data/i2c-gpio.h
Thanks,
Mauro
[PATCH] media: pt1: use #ifdef CONFIG_PM_SLEEP instead of #if
As pointed by ktest:
>> drivers/media//pci/pt1/pt1.c:1433:5: warning: "CONFIG_PM_SLEEP" is not
>> defined, evaluates to 0 [-Wundef]
#if CONFIG_PM_SLEEP
^~~
Reported-by: kbuild test robot
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/pci/pt1/pt1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/pci/pt1/pt1.c b/drivers/media/pci/pt1/pt1.c
index 3b7e08a4639a..55a89ea13f2a 100644
--- a/drivers/media/pci/pt1/pt1.c
+++ b/drivers/media/pci/pt1/pt1.c
@@ -1443,7 +1443,7 @@ static struct pci_driver pt1_driver = {
.probe = pt1_probe,
.remove = pt1_remove,
.id_table = pt1_id_table,
-#if CONFIG_PM_SLEEP
+#ifdef CONFIG_PM_SLEEP
.driver.pm = &pt1_pm_ops,
#endif
};
--
2.17.0
[linuxtv-media:master 235/238] drivers/media//pci/pt1/pt1.c:1433:5: warning: "CONFIG_PM_SLEEP" is not defined, evaluates to 0
tree: git://linuxtv.org/media_tree.git master
head: fbfb3a75bd52249fe6e91b420cf2ae135ad5
commit: 41cb54e20543d436ee6331cd66dd0413a7452804 [235/238] media: dvb:
earth-pt1: add support for suspend/resume
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 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 41cb54e20543d436ee6331cd66dd0413a7452804
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All warnings (new ones prefixed by >>):
>> drivers/media//pci/pt1/pt1.c:1433:5: warning: "CONFIG_PM_SLEEP" is not
>> defined, evaluates to 0 [-Wundef]
#if CONFIG_PM_SLEEP
^~~
vim +/CONFIG_PM_SLEEP +1433 drivers/media//pci/pt1/pt1.c
1427
1428 static struct pci_driver pt1_driver = {
1429 .name = DRIVER_NAME,
1430 .probe = pt1_probe,
1431 .remove = pt1_remove,
1432 .id_table = pt1_id_table,
> 1433 #if CONFIG_PM_SLEEP
1434 .driver.pm = &pt1_pm_ops,
1435 #endif
1436 };
1437
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: compile error media-build on 4.15 because of 'device_get_match_data'
Hello! I just pushed a fix to media-build. But I had to disable the driver for Kernels older than 4.16. -> VIDEO_I2C requires device_get_match_data which requires the function pointer device_get_match_data in fwnode_operations. The latter has been added first in Kernel 4.16. If someone wants to have VIDEO_I2C in Kernels older than 4.16, please provide patch. BR, Jasmin
compile error media-build on 4.15 because of 'device_get_match_data'
I tried to compile media-build on Ubuntu 18.04. (gcc 7.3.0) with Kernel 4.15 and get this error: /home/martin/media_build/v4l/video-i2c.c: In function 'video_i2c_probe': /home/martin/media_build/v4l/video-i2c.c:456:16: error: implicit declaration of function 'device_get_match_data'; did you mean 'of_device_get_match_data'? [-Werror=implicit-function-declaration] data->chip = device_get_match_data(&client->dev); ^ of_device_get_match_data /home/martin/media_build/v4l/video-i2c.c:456:14: warning: assignment makes pointer from integer without a cast [-Wint-conversion] data->chip = device_get_match_data(&client->dev); ^ cc1: some warnings being treated as errors scripts/Makefile.build:339: recipe for target '/home/martin/media_build/v4l/video-i2c.o' failed make[3]: *** [/home/martin/media_build/v4l/video-i2c.o] Error 1 Makefile:1552: recipe for target '_module_/home/martin/media_build/v4l' failed make[2]: *** [_module_/home/martin/media_build/v4l] Error 2 make[2]: Leaving directory '/usr/src/linux-headers-4.15.0-20-generic' Makefile:51: recipe for target 'default' failed make[1]: *** [default] Error 2 make[1]: Verzeichnis „/home/martin/media_build/v4l“ wird verlassen Makefile:26: recipe for target 'all' failed make: *** [all] Error 2 build failed at ./build line 526 I hope it is possible to integrate a patch for Kernel 4.15
Re: [PATCH] media: pt1: fix strncmp() size warning
On Sat, May 5, 2018 at 2:33 PM, Mauro Carvalho Chehab wrote: > As warned by smatch: > drivers/media/pci/pt1/pt1.c:213 config_demod() error: strncmp() > '"tc90522sat"' too small (11 vs 20) > > Use the same strncmp() syntax as pt1_init_frontends() does. > + is_sat = !strncmp(cl->name, TC90522_I2C_DEV_SAT, > + strlen(TC90522_I2C_DEV_SAT)); In this case I don't see a point to use strNcmp(). Plain strcmp() would work. -- With Best Regards, Andy Shevchenko
[PATCH] media: pt1: fix strncmp() size warning
As warned by smatch:
drivers/media/pci/pt1/pt1.c:213 config_demod() error: strncmp()
'"tc90522sat"' too small (11 vs 20)
Use the same strncmp() syntax as pt1_init_frontends() does.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/pci/pt1/pt1.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/pci/pt1/pt1.c b/drivers/media/pci/pt1/pt1.c
index a3126d7caac7..3b7e08a4639a 100644
--- a/drivers/media/pci/pt1/pt1.c
+++ b/drivers/media/pci/pt1/pt1.c
@@ -210,7 +210,8 @@ static int config_demod(struct i2c_client *cl, enum
pt1_fe_clk clk)
return ret;
usleep_range(3, 5);
- is_sat = !strncmp(cl->name, TC90522_I2C_DEV_SAT, I2C_NAME_SIZE);
+ is_sat = !strncmp(cl->name, TC90522_I2C_DEV_SAT,
+ strlen(TC90522_I2C_DEV_SAT));
if (is_sat) {
struct i2c_msg msg[2];
u8 wbuf, rbuf;
--
2.17.0
Re: [PATCH v3 2/5] tuners: add new i2c driver for Sharp qm1d1b0004 ISDB-S tuner
Em Mon, 9 Apr 2018 02:39:50 +0900
tsk...@gmail.com escreveu:
> From: Akihiro Tsukada
>
> The tuner is used in Earthsoft PT1/PT2 DVB boards,
> and the driver was extraced from (the former) va1j5jf8007s.c of PT1.
> it might contain PT1 specific configs.
>
> Signed-off-by: Akihiro Tsukada
Please add yourself to MAINTAINERS file for this driver
(and for other drivers you wrote).
> ---
> Changes since v2:
> - none
>
> Changes since v1:
> - none
>
> drivers/media/tuners/Kconfig | 7 +
> drivers/media/tuners/Makefile | 1 +
> drivers/media/tuners/qm1d1b0004.c | 264 ++
> drivers/media/tuners/qm1d1b0004.h | 24 +++
> 4 files changed, 296 insertions(+)
> create mode 100644 drivers/media/tuners/qm1d1b0004.c
> create mode 100644 drivers/media/tuners/qm1d1b0004.h
>
> diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig
> index 6687514df97..147f3cd0bb9 100644
> --- a/drivers/media/tuners/Kconfig
> +++ b/drivers/media/tuners/Kconfig
> @@ -284,4 +284,11 @@ config MEDIA_TUNER_QM1D1C0042
> default m if !MEDIA_SUBDRV_AUTOSELECT
> help
> Sharp QM1D1C0042 trellis coded 8PSK tuner driver.
> +
> +config MEDIA_TUNER_QM1D1B0004
> + tristate "Sharp QM1D1B0004 tuner"
> + depends on MEDIA_SUPPORT && I2C
> + default m if !MEDIA_SUBDRV_AUTOSELECT
> + help
> + Sharp QM1D1B0004 ISDB-S tuner driver.
> endmenu
> diff --git a/drivers/media/tuners/Makefile b/drivers/media/tuners/Makefile
> index 0ff21f1c7ee..7b4f8423501 100644
> --- a/drivers/media/tuners/Makefile
> +++ b/drivers/media/tuners/Makefile
> @@ -41,6 +41,7 @@ obj-$(CONFIG_MEDIA_TUNER_IT913X) += it913x.o
> obj-$(CONFIG_MEDIA_TUNER_R820T) += r820t.o
> obj-$(CONFIG_MEDIA_TUNER_MXL301RF) += mxl301rf.o
> obj-$(CONFIG_MEDIA_TUNER_QM1D1C0042) += qm1d1c0042.o
> +obj-$(CONFIG_MEDIA_TUNER_QM1D1B0004) += qm1d1b0004.o
> obj-$(CONFIG_MEDIA_TUNER_M88RS6000T) += m88rs6000t.o
> obj-$(CONFIG_MEDIA_TUNER_TDA18250) += tda18250.o
>
> diff --git a/drivers/media/tuners/qm1d1b0004.c
> b/drivers/media/tuners/qm1d1b0004.c
> new file mode 100644
> index 000..9dac1b875c1
> --- /dev/null
> +++ b/drivers/media/tuners/qm1d1b0004.c
> @@ -0,0 +1,264 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Sharp QM1D1B0004 satellite tuner
> + *
> + * Copyright (C) 2014 Akihiro Tsukada
> + *
> + * based on (former) drivers/media/pci/pt1/va1j5jf8007s.c.
> + */
> +
> +/*
> + * Note:
> + * Since the data-sheet of this tuner chip is not available,
> + * this driver lacks some tuner_ops and config options.
> + * In addition, the implementation might be dependent on the specific use
> + * in the FE module: VA1J5JF8007S and/or in the product: Earthsoft PT1/PT2.
> + */
> +
> +#include
> +#include
> +#include
> +#include "qm1d1b0004.h"
> +
> +/*
> + * Tuner I/F (copied from the former va1j5jf8007s.c)
> + * b[0] I2C addr
> + * b[1] "0":1, BG:2, divider_quotient[7:3]:5
> + * b[2] divider_quotient[2:0]:3, divider_remainder:5
> + * b[3] "111":3, LPF[3:2]:2, TM:1, "0":1, REF:1
> + * b[4] BANDX, PSC:1, LPF[1:0]:2, DIV:1, "0":1
> + *
> + * PLL frequency step :=
> + *REF == 0 -> PLL XTL frequency(4MHz) / 8
> + *REF == 1 -> PLL XTL frequency(4MHz) / 4
> + *
> + * PreScaler :=
> + *PSC == 0 -> x32
> + *PSC == 1 -> x16
> + *
> + * divider_quotient := (frequency / PLL frequency step) / PreScaler
> + * divider_remainder := (frequency / PLL frequency step) % PreScaler
> + *
> + * LPF := LPF Frequency / 1000 / 2 - 2
> + * LPF Frequency @ baudrate=28.86Mbps = 3
> + *
> + * band (1..9)
> + * band 1 (freq < 986000) -> DIV:1, BANDX:5, PSC:1
> + * band 2 (freq < 1072000) -> DIV:1, BANDX:6, PSC:1
> + * band 3 (freq < 1154000) -> DIV:1, BANDX:7, PSC:0
> + * band 4 (freq < 1291000) -> DIV:0, BANDX:1, PSC:0
> + * band 5 (freq < 1447000) -> DIV:0, BANDX:2, PSC:0
> + * band 6 (freq < 1615000) -> DIV:0, BANDX:3, PSC:0
> + * band 7 (freq < 1791000) -> DIV:0, BANDX:4, PSC:0
> + * band 8 (freq < 1972000) -> DIV:0, BANDX:5, PSC:0
> + * band 9 (freq < 215) -> DIV:0, BANDX:6, PSC:0
> + */
> +
> +#define QM1D1B0004_PSC_MASK (1 << 4)
> +
> +#define QM1D1B0004_XTL_FREQ 4000
> +#define QM1D1B0004_LPF_FALLBACK 3
> +
> +static const struct qm1d1b0004_config default_cfg = {
> + .lpf_freq = QM1D1B0004_CFG_LPF_DFLT,
> + .half_step = false,
> +};
> +
> +struct qm1d1b0004_state {
> + struct qm1d1b0004_config cfg;
> + struct i2c_client *i2c;
> +};
> +
> +
> +struct qm1d1b0004_cb_map {
> + u32 frequency;
> + u8 cb;
> +};
> +
> +static const struct qm1d1b0004_cb_map cb_maps[] = {
> + { 986000, 0xb2 },
> + { 1072000, 0xd2 },
> + { 1154000, 0xe2 },
> + { 1291000, 0x20 },
> + { 1447000, 0x40 },
> + { 1615000, 0x60 },
> + { 1791000, 0x80 },
> + { 1972000, 0xa0 },
> +};
> +
> +static u8 lookup_cb(u32 frequency)
> +{
> + int i;
> + const struct qm1d1b0004_cb_map *map;
> +
> + for (i = 0; i < ARRAY_SIZE(cb_maps); i++) {
> +
Re: [PATCH] media: i2c: adv748x: Fix pixel rate values
Hi Laurent,
On 2018-05-05 12:48:58 +0300, Laurent Pinchart wrote:
> Hi Niklas,
>
> On Saturday, 5 May 2018 01:58:10 EEST Niklas Söderlund wrote:
> > On 2018-04-25 01:36:42 +0200, Niklas Söderlund wrote:
> > > On 2018-04-21 15:44:44 +0300, Laurent Pinchart wrote:
> > >> The pixel rate, as reported by the V4L2_CID_PIXEL_RATE control, must
> > >> include both horizontal and vertical blanking. Both the AFE and HDMI
> > >> receiver program it incorrectly:
> > >>
> > >> - The HDMI receiver goes to the trouble of removing blanking to compute
> > >> the rate of active pixels. This is easy to fix by removing the
> > >> computation and returning the incoming pixel clock rate directly.
> > >>
> > >> - The AFE performs similar calculation, while it should simply return
> > >> the fixed pixel rate for analog sources, mandated by the ADV748x to be
> > >> 28.63636 MHz.
> > >>
> > >> Signed-off-by: Laurent Pinchart
> > >>
> > >
> > > Reviewed-by: Niklas Söderlund
> >
> > I'm afraid I would like to revoke this review tag, please see bellow.
> >
> > > This patch uncovered a calculation error in rcar-csi2 which compensated
> > > for the removing of the blanking in the adv748x, thanks for that! Good
> > > thing that it's not merged yet, will include the fix in the next version
> > > of the CSI-2 driver.
> > >
> > >> ---
> > >>
> > >> drivers/media/i2c/adv748x/adv748x-afe.c | 11 +--
> > >> drivers/media/i2c/adv748x/adv748x-hdmi.c | 8 +---
> > >> 2 files changed, 6 insertions(+), 13 deletions(-)
> > >>
> > >> diff --git a/drivers/media/i2c/adv748x/adv748x-afe.c
> > >> b/drivers/media/i2c/adv748x/adv748x-afe.c index
> > >> 61514bae7e5c..3e18d5ae813b 100644
> > >> --- a/drivers/media/i2c/adv748x/adv748x-afe.c
> > >> +++ b/drivers/media/i2c/adv748x/adv748x-afe.c
> > >> @@ -321,17 +321,16 @@ static const struct v4l2_subdev_video_ops
> > >> adv748x_afe_video_ops = {> >
> > >> static int adv748x_afe_propagate_pixelrate(struct adv748x_afe *afe)
> > >> {
> > >> struct v4l2_subdev *tx;
> > >> -unsigned int width, height, fps;
> > >>
> > >> tx = adv748x_get_remote_sd(&afe->pads[ADV748X_AFE_SOURCE]);
> > >> if (!tx)
> > >> return -ENOLINK;
> > >>
> > >> -width = 720;
> > >> -height = afe->curr_norm & V4L2_STD_525_60 ? 480 : 576;
> > >> -fps = afe->curr_norm & V4L2_STD_525_60 ? 30 : 25;
> > >> -
> > >> -return adv748x_csi2_set_pixelrate(tx, width * height * fps);
> > >> +/*
> > >> + * The ADV748x samples analog video signals using an externally
> > >> supplied
> > >> + * clock whose frequency is required to be 28.63636 MHz.
> > >> + */
> > >> +return adv748x_csi2_set_pixelrate(tx, 28636360);
> >
> > I believe this is wrong. The sampling rate of the AFE is 28.63636 MHz
> > but the pixelrate output on the CSI-TXB might not be right?
>
> There are only two ways that would allow the pixel rate output of the CSI-TXB
> to be different than the sampling frequency. The SD core or TXB would need to
> either resample or buffer the signal. Resampling would change the resolution
> so that's out of question. Buffering would require a memory buffer large
> enough to hold one line of data, which would be quite expensive in terms of
> silicon, and is thus unlikely.
I'm the first to admit I have much to learn here :-) I tried reading up
and with my limited understanding it seems possible that different
components are sampled at different rates, and normal pixel clock for
PAL and NTSC which kept popping up in my research was:
Digital video is a sampled form of analog video. The most common
sampling schemes in use today are:
Pixel Clock HorizHorizVert
Rate TotalActive
NTSC square pixel 12.27 MHz780 640 525
NTSC CCIR-601 13.5 MHz858 720 525
NTSC 4FSc 14.32 MHz910 768 525
PAL square pixel 14.75 MHz944 768 625
PAL CCIR-601 13.5 MHz864 720 625
PAL 4FSc 17.72 MHz 1135 948 625
For the CCIR-601 standards, the sampling is based on a static
orthogonal sampling grid. The luminance component (Y) is sampled at
13.5 MHz, while the two color difference signals, Cr and Cb are
sampled at half that, or 6.75 MHz. The Cr and Cb samples are
colocated with alternate Y samples, and they are taken at the same
position on each line, such that one sample is coincident with the
50% point of the falling edge of analog sync. The samples are coded
to either 8 or 10 bits per component.
ftp://ftp.sgi.com/sgi/video/rld/vidpage/sampling.html
Looking at timing diagrams it seems the VSYNC pulse is quiet long and
that is AFIK represented by a short package on the CSI-2 bus so I feel
the sampling clock can't be 1:1 mapped to the pixel rate of the CSI-2
bus.
Also
Re: [PATCH v5 5/5] dvb-usb-v2/gl861: ensure USB message buffers DMA'able
Em Mon, 9 Apr 2018 02:21:38 +0900
tsk...@gmail.com escreveu:
> From: Akihiro Tsukada
>
> i2c message buf might be on stack.
That patch also applied without changes. So, just patch 3/5 was not applied.
>
> Signed-off-by: Akihiro Tsukada
> ---
> Changes since v4:
> - none
>
> drivers/media/usb/dvb-usb-v2/gl861.c | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/usb/dvb-usb-v2/gl861.c
> b/drivers/media/usb/dvb-usb-v2/gl861.c
> index cdd7bfcb883..47b614da807 100644
> --- a/drivers/media/usb/dvb-usb-v2/gl861.c
> +++ b/drivers/media/usb/dvb-usb-v2/gl861.c
> @@ -22,6 +22,8 @@ static int gl861_i2c_msg(struct dvb_usb_device *d, u8 addr,
> u16 value = addr << (8 + 1);
> int wo = (rbuf == NULL || rlen == 0); /* write-only */
> u8 req, type;
> + u8 *buf;
> + int ret;
>
> if (wo) {
> req = GL861_REQ_I2C_WRITE;
> @@ -44,11 +46,23 @@ static int gl861_i2c_msg(struct dvb_usb_device *d, u8
> addr,
> KBUILD_MODNAME, wlen);
> return -EINVAL;
> }
> -
> + buf = NULL;
> + if (rlen > 0) {
> + buf = kmalloc(rlen, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> + }
> usleep_range(1000, 2000); /* avoid I2C errors */
>
> - return usb_control_msg(d->udev, usb_rcvctrlpipe(d->udev, 0), req, type,
> -value, index, rbuf, rlen, 2000);
> + ret = usb_control_msg(d->udev, usb_rcvctrlpipe(d->udev, 0), req, type,
> + value, index, buf, rlen, 2000);
> + if (rlen > 0) {
> + if (ret > 0)
> + memcpy(rbuf, buf, rlen);
> + kfree(buf);
> + }
> +
> + return ret;
> }
>
> /* Friio specific I2C read/write */
Thanks,
Mauro
Re: [PATCH v5 4/5] dvb-usb-v2/gl861: use usleep_range() for short delay
Em Mon, 9 Apr 2018 02:21:37 +0900 tsk...@gmail.com escreveu: > From: Akihiro Tsukada > > As the kernel doc "timers-howto.txt" reads, > short delay with msleep() can take much longer. > In a case of raspbery-pi platform where CONFIG_HZ_100 was set, > it actually affected the init of Friio devices > since it issues lots of i2c transactions with short delay. > > Signed-off-by: Akihiro Tsukada > --- > Changes since v4: > - none > > drivers/media/usb/dvb-usb-v2/gl861.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/usb/dvb-usb-v2/gl861.c > b/drivers/media/usb/dvb-usb-v2/gl861.c > index ecff0062bfb..cdd7bfcb883 100644 > --- a/drivers/media/usb/dvb-usb-v2/gl861.c > +++ b/drivers/media/usb/dvb-usb-v2/gl861.c > @@ -45,7 +45,7 @@ static int gl861_i2c_msg(struct dvb_usb_device *d, u8 addr, > return -EINVAL; > } > > - msleep(1); /* avoid I2C errors */ > + usleep_range(1000, 2000); /* avoid I2C errors */ Actually, this change is puntual and applies even without patch 3/5. So, I'll apply this one too. So, next time, just patches 3 and 5 will be needed. > > return usb_control_msg(d->udev, usb_rcvctrlpipe(d->udev, 0), req, type, > value, index, rbuf, rlen, 2000); Thanks, Mauro
Re: [PATCH v6 3/5] dvb-usb/friio, dvb-usb-v2/gl861: decompose friio and merge with gl861
Em Mon, 9 Apr 2018 02:21:36 +0900
tsk...@gmail.com escreveu:
> From: Akihiro Tsukada
>
> Friio device contains "gl861" bridge and "tc90522" demod,
> for which the separate drivers are already in the kernel.
> But friio driver was monolithic and did not use them,
> practically copying those features.
> This patch decomposes friio driver into sub drivers and
> re-uses existing ones, thus reduces some code.
>
> It adds some features to gl861,
> to support the friio-specific init/config of the devices
> and implement i2c communications to the tuner via demod
> with USB vendor requests.
Hi Akihiro-san,
Patches 1 and 2 looked OK on my eyes. I'll be applying them.
I have comments to this one. See below. I won't apply the
remaining patches on this series, as they likely depend on it.
>
> Signed-off-by: Akihiro Tsukada
> ---
> Changes since v5:
> - specify chip name literally
> - i2c algo of gl861 is not (yet?) changed as proposed by Antti,
> (which is to move the special case handling to demod driver),
> since I do not yet understand
> whether it should/can be really moved or not.
>
> Changes since v4:
> - use new style of specifying pll_desc id of the tuner driver
>
> Changes since v3:
> - make dvb_usb_device_properties static
>
> Changes since v2:
> (patch #27928, dvb-usb-friio: split and merge into dvb-usbv2-gl861)
> - used the new i2c binding helpers instead of my own one
> - merged gl861-friio.c with gl861.c
>
> drivers/media/usb/dvb-usb-v2/Kconfig | 5 +-
> drivers/media/usb/dvb-usb-v2/gl861.c | 465 +++-
> drivers/media/usb/dvb-usb-v2/gl861.h | 1 +
> drivers/media/usb/dvb-usb/Kconfig| 6 -
> drivers/media/usb/dvb-usb/Makefile | 3 -
> drivers/media/usb/dvb-usb/friio-fe.c | 441 --
> drivers/media/usb/dvb-usb/friio.c| 522 ---
> drivers/media/usb/dvb-usb/friio.h| 99 -
> 8 files changed, 462 insertions(+), 1080 deletions(-)
> delete mode 100644 drivers/media/usb/dvb-usb/friio-fe.c
> delete mode 100644 drivers/media/usb/dvb-usb/friio.c
> delete mode 100644 drivers/media/usb/dvb-usb/friio.h
>
> diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig
> b/drivers/media/usb/dvb-usb-v2/Kconfig
> index 0e4944b2b0f..e0a1f377295 100644
> --- a/drivers/media/usb/dvb-usb-v2/Kconfig
> +++ b/drivers/media/usb/dvb-usb-v2/Kconfig
> @@ -95,10 +95,13 @@ config DVB_USB_GL861
> tristate "Genesys Logic GL861 USB2.0 support"
> depends on DVB_USB_V2
> select DVB_ZL10353 if MEDIA_SUBDRV_AUTOSELECT
> + select DVB_TC90522 if MEDIA_SUBDRV_AUTOSELECT
> select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT
> + select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
> help
> Say Y here to support the MSI Megasky 580 (55801) DVB-T USB2.0
> - receiver with USB ID 0db0:5581.
> + receiver with USB ID 0db0:5581, Friio White ISDB-T receiver
> + with USB ID 0x7a69:0001.
>
> config DVB_USB_LME2510
> tristate "LME DM04/QQBOX DVB-S USB2.0 support"
> diff --git a/drivers/media/usb/dvb-usb-v2/gl861.c
> b/drivers/media/usb/dvb-usb-v2/gl861.c
> index b1b09c54786..ecff0062bfb 100644
> --- a/drivers/media/usb/dvb-usb-v2/gl861.c
> +++ b/drivers/media/usb/dvb-usb-v2/gl861.c
> @@ -10,6 +10,8 @@
>
> #include "zl10353.h"
> #include "qt1010.h"
> +#include "tc90522.h"
> +#include "dvb-pll.h"
>
> DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>
> @@ -49,6 +51,80 @@ static int gl861_i2c_msg(struct dvb_usb_device *d, u8 addr,
> value, index, rbuf, rlen, 2000);
> }
>
> +/* Friio specific I2C read/write */
> +/* special USB request is used in Friio's init/config */
> +static int
> +gl861_i2c_rawwrite(struct dvb_usb_device *d, u8 addr, u8 *wbuf, u16 wlen)
> +{
> + u8 *buf;
> + int ret;
> +
> + buf = kmalloc(wlen, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + usleep_range(1000, 2000); /* avoid I2C errors */
I guess this is probably also at the original code, but it seems really
weird to sleep here just after kmalloc().
I would move any need for sleeps to the i2c xfer function, where it
makes clearer why it is needed and where. Same applies to other
usleep_range() calls at the functions below.
> + memcpy(buf, wbuf, wlen);
> + ret = usb_control_msg(d->udev, usb_sndctrlpipe(d->udev, 0),
> + GL861_REQ_I2C_RAW, GL861_WRITE,
> + addr << (8 + 1), 0x0100, buf, wlen, 2000);
> + kfree(buf);
> + return ret;
> +}
> +
> +/*
> + * In Friio,
> + * I2C commnucations to the tuner are relay'ed via the demod (via the
> bridge),
> + * so its encapsulation to USB message is different from the one to the
> demod.
This is quite common. I guess the rationale of using the demod's I2C mux
is to avoid noise at the tuner when there are I2C traffic that aren't related
to it.
You should probably implement it via I2C_MUX support.
There are several examples about how to
Re: [GIT FIXES FOR v4.17] UVC fixes
Em Wed, 25 Apr 2018 03:37:00 +0300 Laurent Pinchart escreveu: > Hi Mauro, > > The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: > > > > > > Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) > > > > > > are available in the Git repository at: > > > > > > git://linuxtv.org/pinchartl/media.git uvc/fixes > > > > > > for you to fetch changes up to 3f22b63e8a488156467da43cdf9a3a7bd683f161: > > > > > > media: uvcvideo: Prevent setting unavailable flags (2018-04-25 03:16:42 > +0300) > > > Not sure what happened here, but this e-mail is completely mangled. This way, patchwork won't parse it. I manually applied it, but next time please check if your emailer is not messing with pull requests. Thanks, Mauro > > > > Kieran Bingham (1): > > > media: uvcvideo: Prevent setting unavailable flags > > > > > > drivers/media/usb/uvc/uvc_ctrl.c | 17 + > > > 1 file changed, 9 insertions(+), 8 deletions(-) > Thanks, Mauro
Re: 4.17-rc3 regression in UVC driver
Hi Kieran, Em Sat, 5 May 2018 08:46:50 +0100 Kieran Bingham escreveu: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hello again, > > On 05/05/18 08:34, Kieran Bingham wrote: > > Hi Sebastian, > > > > On 04/05/18 19:45, Sebastian Reichel wrote: > >> Hi, > >> > >> I just got the following error message every ms with 4.17-rc3 after > >> upgrading to for first ~192 seconds after system start (Debian > >> 4.17~rc3-1~exp1 kernel) on my Thinkpad X250: > >> > >>> uvcvideo: Failed to query (GET_MIN) UVC control 2 on unit 1: -32 (exp. > >>> 1). > > > > I have submitted a patch to fix this ... (and I thought it would have got > > in by now ... so I'll chase this up) > > > Mauro - I just saw Laurent sent a pull-request for this last week, so I guess > maybe it's on it's way: > > [GIT FIXES FOR v4.17] UVC fixes (25/04/2018) > > But perhaps it got missed ? - I don't see this patch in media/v4.17-4: > > git log media/v4.17-4 --grep="media: uvcvideo: Prevent setting unavailable > flags > " > > > Anyway, I'll leave this in your hands. Yes, it got missed. Looking a the e-mail he sent, whitespaces completely destroyed the pull request, causing it to not be caught by patchwork. I manually pull from git://linuxtv.org/pinchartl/media.git uvc/fixes and picked the patch. It should be at media_tree.git at the fixes branch. > > - -- > Regards > > Kieran > > > > Please see : https://patchwork.linuxtv.org/patch/48043/ and apply the > > patch to bring your system logs back to a reasonable state :D > > > > Laurent, Mauro, > > > > This is the second bug report I've had on this topic. Can we aim to get > > this patch merged please? > > > >> I see /dev/video0 and /dev/video1. The first one seems to be functional. > >> The second one does not work and does not make sense to me (the system > >> has only one webcam). I did not try to bisect anything. Here is some > >> more information, that might be useful: > > > > There are two device nodes now, as one is provided to output meta-data or > > such. > > > > > >>> sre@earth ~ % mpv /dev/video1 Playing: /dev/video1 [ffmpeg/demuxer] > >>> video4linux2,v4l2: ioctl(VIDIOC_G_INPUT): Inappropriate ioctl for > >>> device [lavf] avformat_open_input() failed Failed to recognize file > >>> format. sre@earth ~ % udevadm info /dev/video0 P: > >>> /devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/video4linux/video0 > >>> N: video0 E: DEVNAME=/dev/video0 E: > >>> DEVPATH=/devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/video4linux/video0 > >>> > >>> > >>> > E: MAJOR=81 > >>> E: MINOR=0 E: SUBSYSTEM=video4linux sre@earth ~ % udevadm info > >>> /dev/video1 P: > >>> /devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/video4linux/video1 > >>> N: video1 E: DEVNAME=/dev/video1 E: > >>> DEVPATH=/devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/video4linux/video1 > >>> > >>> > >>> > E: MAJOR=81 > >>> E: MINOR=1 E: SUBSYSTEM=video4linux sre@earth ~ % lsusb -d 04ca:703c > >>> Bus 001 Device 004: ID 04ca:703c Lite-On Technology Corp. > >> > >> -- Sebastian > > > > > > Regards > > > > Kieran > > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEkC3XmD+9KP3jctR6oR5GchCkYf0FAlrtYWoACgkQoR5GchCk > Yf3tQg/7BgBFIj9more5vTaCFEU2L+tapdOBItO+mgzHI9fFXVHAmaVUlSjVAiMX > PlyRx1NsSnCRSZ4b6R/ydjEuNG5dLr2B8LfS5QP/6ABmUCONdCBIbx/2mDk+DtoX > XZeI65MMr3nZG7f6ZNq2EoVPIcFF4WLY4CsfixBOye3ps4e91IkTDFA/EVG0qkD8 > XLRHACYSe/7lMS2TcAyOlmzWecYLYqnFBxfjlBD80NfdWITsDZdooZ3KUdHTCqN4 > ooWjyifkeh79D8M9PGhnNGoB4gbHjTMhbZEH4RaABdv/jO/L4kPExX+2Wjc4LnRj > QlWmLm9svIisXJaPO6sPg+rIUr6xLTs5Dv5yYU+UpR9AVfVusHy7FfFoYkcHpThZ > h0rc1yi6eU4/Nnz1BvQbLCdjab2yEF5nD05PQs22r4ZJy04ymiz+y3SZvlr8vYfu > 2ZRJzjkvFHtWV3yd/LfjxmuzmYXH4Yn+yN8jMGu8sY4JtJEsSF8qPbjDpicOhXvI > pv4V9xvDGscsZdKFaNv0IES+NHNRsgPvx0sR0DOb3MC8T9p+aEJPfQEBly1XBPG0 > 4GkvuA//DKpBASFdlSpKt4YW6OX56X+g8BPOcaBJV8BlBRzumDk4cAZ/T2t4DLm5 > w3GnEwWLu0BiWl1LKqgh4xVgOg45IqcJJmDgupM3WzjCrYwVCbo= > =B80a > -END PGP SIGNATURE- Thanks, Mauro
[PATCH 2/2] dvbsky: Add support for MyGica T230C v2
Support for newer revisions of the MyGica T230C, shipping with a
different USB pid. Although sometimes referred to as T230C2, the device
is sold under its original name T230C.
Besides a slightly different PCB layout and some different minor
components, it utilizes the same bridge, demodulator and tuner as the
older revision. However, it requires a fixed TS clock frequency of 10
MHz to tune to some muxes.
Tested with various DVB-T2 HEVC and DVB-C channels.
Signed-off-by: Thomas Hollstegge
Cc: Stefan Brüns
---
drivers/media/usb/dvb-usb-v2/dvbsky.c | 90 +++
include/media/dvb-usb-ids.h | 1 +
2 files changed, 91 insertions(+)
diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c
b/drivers/media/usb/dvb-usb-v2/dvbsky.c
index 43eb828..49db69f 100644
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -719,6 +719,66 @@ static int dvbsky_mygica_t230c_attach(struct
dvb_usb_adapter *adap)
return -ENODEV;
}
+static int dvbsky_mygica_t230c_v2_attach(struct dvb_usb_adapter *adap)
+{
+ struct dvbsky_state *state = adap_to_priv(adap);
+ struct dvb_usb_device *d = adap_to_d(adap);
+ struct i2c_adapter *i2c_adapter;
+ struct i2c_client *client_demod, *client_tuner;
+ struct i2c_board_info info;
+ struct si2168_config si2168_config;
+ struct si2157_config si2157_config;
+
+ /* attach demod */
+ memset(&si2168_config, 0, sizeof(si2168_config));
+ si2168_config.i2c_adapter = &i2c_adapter;
+ si2168_config.fe = &adap->fe[0];
+ si2168_config.ts_mode = SI2168_TS_PARALLEL;
+ si2168_config.ts_clock_inv = 1;
+ si2168_config.ts_clock_mode = SI2168_TS_CLOCK_MODE_MANUAL;
+ si2168_config.ts_clock_freq = 1000;
+ memset(&info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, "si2168", sizeof(info.type));
+ info.addr = 0x64;
+ info.platform_data = &si2168_config;
+
+ request_module("si2168");
+ client_demod = i2c_new_device(&d->i2c_adap, &info);
+ if (!client_demod || !client_demod->dev.driver)
+ goto fail_demod_device;
+ if (!try_module_get(client_demod->dev.driver->owner))
+ goto fail_demod_module;
+
+ /* attach tuner */
+ memset(&si2157_config, 0, sizeof(si2157_config));
+ si2157_config.fe = adap->fe[0];
+ si2157_config.if_port = 0;
+ memset(&info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, "si2141", sizeof(info.type));
+ info.addr = 0x60;
+ info.platform_data = &si2157_config;
+
+ request_module("si2157");
+ client_tuner = i2c_new_device(i2c_adapter, &info);
+ if (!client_tuner || !client_tuner->dev.driver)
+ goto fail_tuner_device;
+ if (!try_module_get(client_tuner->dev.driver->owner))
+ goto fail_tuner_module;
+
+ state->i2c_client_demod = client_demod;
+ state->i2c_client_tuner = client_tuner;
+ return 0;
+
+fail_tuner_module:
+ i2c_unregister_device(client_tuner);
+fail_tuner_device:
+ module_put(client_demod->dev.driver->owner);
+fail_demod_module:
+ i2c_unregister_device(client_demod);
+fail_demod_device:
+ return -ENODEV;
+}
+
static int dvbsky_identify_state(struct dvb_usb_device *d, const char **name)
{
@@ -911,6 +971,33 @@ static struct dvb_usb_device_properties mygica_t230c_props
= {
}
};
+static struct dvb_usb_device_properties mygica_t230c_v2_props = {
+ .driver_name = KBUILD_MODNAME,
+ .owner = THIS_MODULE,
+ .adapter_nr = adapter_nr,
+ .size_of_priv = sizeof(struct dvbsky_state),
+
+ .generic_bulk_ctrl_endpoint = 0x01,
+ .generic_bulk_ctrl_endpoint_response = 0x81,
+ .generic_bulk_ctrl_delay = DVBSKY_MSG_DELAY,
+
+ .i2c_algo = &dvbsky_i2c_algo,
+ .frontend_attach = dvbsky_mygica_t230c_v2_attach,
+ .init = dvbsky_init,
+ .get_rc_config= dvbsky_get_rc_config,
+ .streaming_ctrl = dvbsky_streaming_ctrl,
+ .identify_state = dvbsky_identify_state,
+ .exit = dvbsky_exit,
+
+ .num_adapters = 1,
+ .adapter = {
+ {
+ .stream = DVB_USB_STREAM_BULK(0x82, 8, 4096),
+ }
+ }
+};
+
+
static const struct usb_device_id dvbsky_id_table[] = {
{ DVB_USB_DEVICE(0x0572, 0x6831,
&dvbsky_s960_props, "DVBSky S960/S860", RC_MAP_DVBSKY) },
@@ -946,6 +1033,9 @@ static const struct usb_device_id dvbsky_id_table[] = {
{ DVB_USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230C,
&mygica_t230c_props, "MyGica Mini DVB-T2 USB Stick T230C",
RC_MAP_TOTAL_MEDIA_IN_HAND_02) },
+ { DVB_USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230C_V2,
+ &mygica_t230c_v2_props, "MyGica Mini DVB-T2 USB Stick T230C v2",
+ RC_MAP_TOTAL_MEDIA_IN_HAND_02)
[PATCH 0/2] dvbsky: Add support for MyGica T230C v2
Add support for newer revisions of the USB DVB-C/DVB-T/DVB-T2 stick MyGica T230C, sometimes referred to as MyGica T230C2. The device needs a fixed TS clock frequency of 10MHz to be able to demod some channels. This is done by adding two new optional configuration options for the Si2168 demod (ts_clock_mode and ts_clock_freq). Although there is a third TS clock mode available (AUTO_FIXED = 0x00), I chose not to implement it yet as I don't have a device that uses this mode. Tested with all available DVB-T2 HEVC and DVB-C muxes in my region (Germany). Thomas Hollstegge (2): si2168: Set TS clock mode and frequency dvbsky: Add support for MyGica T230C v2 drivers/media/dvb-frontends/si2168.c | 20 ++- drivers/media/dvb-frontends/si2168.h | 8 +++ drivers/media/dvb-frontends/si2168_priv.h | 2 + drivers/media/usb/dvb-usb-v2/dvbsky.c | 90 +++ include/media/dvb-usb-ids.h | 1 + 5 files changed, 120 insertions(+), 1 deletion(-) -- 2.7.4
[PATCH 1/2] si2168: Set TS clock mode and frequency
Some devices require a higher TS clock frequency to demodulate some
muxes. This adds two optional parameters to control the TS clock
frequency mode as well as the frequency.
Signed-off-by: Thomas Hollstegge
---
drivers/media/dvb-frontends/si2168.c | 20 +++-
drivers/media/dvb-frontends/si2168.h | 8
drivers/media/dvb-frontends/si2168_priv.h | 2 ++
3 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index 324493e..80740db 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -92,13 +92,15 @@ static int si2168_ts_bus_ctrl(struct dvb_frontend *fe, int
acquire)
dev_dbg(&client->dev, "%s acquire: %d\n", __func__, acquire);
/* set TS_MODE property */
- memcpy(cmd.args, "\x14\x00\x01\x10\x10\x00", 6);
+ memcpy(cmd.args, "\x14\x00\x01\x10\x00\x00", 6);
if (acquire)
cmd.args[4] |= dev->ts_mode;
else
cmd.args[4] |= SI2168_TS_TRISTATE;
if (dev->ts_clock_gapped)
cmd.args[4] |= 0x40;
+ cmd.args[4] |= (dev->ts_clock_mode & 0x03) << 4;
+
cmd.wlen = 6;
cmd.rlen = 4;
ret = si2168_cmd_execute(client, &cmd);
@@ -398,6 +400,18 @@ static int si2168_set_frontend(struct dvb_frontend *fe)
if (ret)
goto err;
+ /* set TS frequency */
+ if (dev->ts_clock_freq) {
+ memcpy(cmd.args, "\x14\x00\x0d\x10", 4);
+ cmd.args[4] = ((dev->ts_clock_freq / 1) >> 0) & 0xff;
+ cmd.args[5] = ((dev->ts_clock_freq / 1) >> 8) & 0xff;
+ cmd.wlen = 6;
+ cmd.rlen = 4;
+ ret = si2168_cmd_execute(client, &cmd);
+ if (ret)
+ goto err;
+ }
+
memcpy(cmd.args, "\x14\x00\x08\x10\xd7\x05", 6);
cmd.args[5] |= dev->ts_clock_inv ? 0x00 : 0x10;
cmd.wlen = 6;
@@ -806,6 +820,10 @@ static int si2168_probe(struct i2c_client *client,
dev->ts_mode = config->ts_mode;
dev->ts_clock_inv = config->ts_clock_inv;
dev->ts_clock_gapped = config->ts_clock_gapped;
+ dev->ts_clock_mode = config->ts_clock_mode;
+ if (!dev->ts_clock_mode)
+ dev->ts_clock_mode = SI2168_TS_CLOCK_MODE_AUTO_ADAPT;
+ dev->ts_clock_freq = config->ts_clock_freq;
dev->spectral_inversion = config->spectral_inversion;
dev_info(&client->dev, "Silicon Labs Si2168-%c%d%d successfully
identified\n",
diff --git a/drivers/media/dvb-frontends/si2168.h
b/drivers/media/dvb-frontends/si2168.h
index d519edd..3f52ee8 100644
--- a/drivers/media/dvb-frontends/si2168.h
+++ b/drivers/media/dvb-frontends/si2168.h
@@ -47,6 +47,14 @@ struct si2168_config {
/* TS clock gapped */
bool ts_clock_gapped;
+ /* TS clock mode */
+#define SI2168_TS_CLOCK_MODE_AUTO_ADAPT0x01
+#define SI2168_TS_CLOCK_MODE_MANUAL0x02
+ u8 ts_clock_mode;
+
+ /* TS clock frequency (for manual mode) */
+ u32 ts_clock_freq;
+
/* Inverted spectrum */
bool spectral_inversion;
};
diff --git a/drivers/media/dvb-frontends/si2168_priv.h
b/drivers/media/dvb-frontends/si2168_priv.h
index 2d362e1..8173d6c 100644
--- a/drivers/media/dvb-frontends/si2168_priv.h
+++ b/drivers/media/dvb-frontends/si2168_priv.h
@@ -48,6 +48,8 @@ struct si2168_dev {
u8 ts_mode;
bool ts_clock_inv;
bool ts_clock_gapped;
+ u8 ts_clock_mode;
+ u32 ts_clock_freq;
bool spectral_inversion;
};
--
2.7.4
Re: [PATCH] media: i2c: adv748x: Fix pixel rate values
Hi Niklas,
On Saturday, 5 May 2018 01:58:10 EEST Niklas Söderlund wrote:
> On 2018-04-25 01:36:42 +0200, Niklas Söderlund wrote:
> > On 2018-04-21 15:44:44 +0300, Laurent Pinchart wrote:
> >> The pixel rate, as reported by the V4L2_CID_PIXEL_RATE control, must
> >> include both horizontal and vertical blanking. Both the AFE and HDMI
> >> receiver program it incorrectly:
> >>
> >> - The HDMI receiver goes to the trouble of removing blanking to compute
> >> the rate of active pixels. This is easy to fix by removing the
> >> computation and returning the incoming pixel clock rate directly.
> >>
> >> - The AFE performs similar calculation, while it should simply return
> >> the fixed pixel rate for analog sources, mandated by the ADV748x to be
> >> 28.63636 MHz.
> >>
> >> Signed-off-by: Laurent Pinchart
> >>
> >
> > Reviewed-by: Niklas Söderlund
>
> I'm afraid I would like to revoke this review tag, please see bellow.
>
> > This patch uncovered a calculation error in rcar-csi2 which compensated
> > for the removing of the blanking in the adv748x, thanks for that! Good
> > thing that it's not merged yet, will include the fix in the next version
> > of the CSI-2 driver.
> >
> >> ---
> >>
> >> drivers/media/i2c/adv748x/adv748x-afe.c | 11 +--
> >> drivers/media/i2c/adv748x/adv748x-hdmi.c | 8 +---
> >> 2 files changed, 6 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/drivers/media/i2c/adv748x/adv748x-afe.c
> >> b/drivers/media/i2c/adv748x/adv748x-afe.c index
> >> 61514bae7e5c..3e18d5ae813b 100644
> >> --- a/drivers/media/i2c/adv748x/adv748x-afe.c
> >> +++ b/drivers/media/i2c/adv748x/adv748x-afe.c
> >> @@ -321,17 +321,16 @@ static const struct v4l2_subdev_video_ops
> >> adv748x_afe_video_ops = {> >
> >> static int adv748x_afe_propagate_pixelrate(struct adv748x_afe *afe)
> >> {
> >>struct v4l2_subdev *tx;
> >> - unsigned int width, height, fps;
> >>
> >>tx = adv748x_get_remote_sd(&afe->pads[ADV748X_AFE_SOURCE]);
> >>if (!tx)
> >>return -ENOLINK;
> >>
> >> - width = 720;
> >> - height = afe->curr_norm & V4L2_STD_525_60 ? 480 : 576;
> >> - fps = afe->curr_norm & V4L2_STD_525_60 ? 30 : 25;
> >> -
> >> - return adv748x_csi2_set_pixelrate(tx, width * height * fps);
> >> + /*
> >> + * The ADV748x samples analog video signals using an externally
> >> supplied
> >> + * clock whose frequency is required to be 28.63636 MHz.
> >> + */
> >> + return adv748x_csi2_set_pixelrate(tx, 28636360);
>
> I believe this is wrong. The sampling rate of the AFE is 28.63636 MHz
> but the pixelrate output on the CSI-TXB might not be right?
There are only two ways that would allow the pixel rate output of the CSI-TXB
to be different than the sampling frequency. The SD core or TXB would need to
either resample or buffer the signal. Resampling would change the resolution
so that's out of question. Buffering would require a memory buffer large
enough to hold one line of data, which would be quite expensive in terms of
silicon, and is thus unlikely.
> The adv7482 is a complex and badly documented thing. But it's internal
> plumbing shows that the CVBS signal sampled by the AFE is passed to the SD
> core and then to the TXB CSI-2 transmitter.
>
> Reading the documentation we have such registers as LTA[1:0] which
> controls the delay between the chroma and luma samples. I do believe the
> adv748x is running with the default of AUTO_PDC_EN which indicates that
> the timings are automatically controlled by the adv748x hardware. And
> there are other registers in the SD core which to me looks like it can
> be configured to make use of the samples so that it won't correlate 1:1
> with the pixel rate.
>
> Looking at the CSI-TXA and CSI-TXB cores which are particularly badly
> documented and the driver contains a lot of undocumented register
> writes. One that is documented and I find interesting in this context is
> EN_AUTOCALC_DPHY_PARAMS which is set 'yes' for the adv748x driver. This
> leads me to believe that the pixel rate output on the CSI-2 bus is not
> correlated with the AFE sampling clock. There are lots of holes in the
> documentation here but some stand out, the undocumented hole around 0xda
> which contains the few documented bits in that area, MIPI_PLL_LOCK_FLAG,
> MIPI_PLL_CLK_DET and MIPI_PLL_EN. Maybe the true link_freq or pixel_rate
> could be read from a undocumented register in that darkness :-)
>
> The real reason I started to dig into this is that after you corrected
> my assumption about how to setup the R-Car CSI-2 receiver link freq this
> change breaks capture of CVBS for me. Looking at how I on your
> suggestion calculate link speed.
>
> link_freq = (pixel_rate * bits_per_sample) / (2 * nr_of_lanes)
>
> pixel_rate = 28636360 (from the adv748x V4L2_CID_PIXEL_RATE)
> bits_per_sample = 16 (adv748x reports MEDIA_BUS_FMT_UYVY8_2X8)
> nr_of_lanes = 1 (Using TXB of the adv748x)
>
> Gives a link_freq of 229Mhz or as the R-Car CSI-2 deals with in M
[PATCH] [media] gspca: Stop using GFP_DMA for buffers for USB bulk transfers
The recent "x86 ZONE_DMA love" discussion at LSF/MM pointed out that some
gspca sub-drivvers are using GFP_DMA to allocate buffers which are used
for USB bulk transfers, there is absolutely no need for this, drop it.
Cc: "Luis R. Rodriguez"
Signed-off-by: Hans de Goede
---
drivers/media/usb/gspca/jl2005bcd.c | 2 +-
drivers/media/usb/gspca/sq905.c | 2 +-
drivers/media/usb/gspca/sq905c.c| 2 +-
drivers/media/usb/gspca/vicam.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/gspca/jl2005bcd.c
b/drivers/media/usb/gspca/jl2005bcd.c
index d668589598d6..c40245950553 100644
--- a/drivers/media/usb/gspca/jl2005bcd.c
+++ b/drivers/media/usb/gspca/jl2005bcd.c
@@ -321,7 +321,7 @@ static void jl2005c_dostream(struct work_struct *work)
int ret;
u8 *buffer;
- buffer = kmalloc(JL2005C_MAX_TRANSFER, GFP_KERNEL | GFP_DMA);
+ buffer = kmalloc(JL2005C_MAX_TRANSFER, GFP_KERNEL);
if (!buffer) {
pr_err("Couldn't allocate USB buffer\n");
goto quit_stream;
diff --git a/drivers/media/usb/gspca/sq905.c b/drivers/media/usb/gspca/sq905.c
index cc8ff41b8ab3..ffea9c35b0a0 100644
--- a/drivers/media/usb/gspca/sq905.c
+++ b/drivers/media/usb/gspca/sq905.c
@@ -217,7 +217,7 @@ static void sq905_dostream(struct work_struct *work)
u8 *data;
u8 *buffer;
- buffer = kmalloc(SQ905_MAX_TRANSFER, GFP_KERNEL | GFP_DMA);
+ buffer = kmalloc(SQ905_MAX_TRANSFER, GFP_KERNEL);
if (!buffer) {
pr_err("Couldn't allocate USB buffer\n");
goto quit_stream;
diff --git a/drivers/media/usb/gspca/sq905c.c b/drivers/media/usb/gspca/sq905c.c
index 5e1269eb7c50..274921c0bb46 100644
--- a/drivers/media/usb/gspca/sq905c.c
+++ b/drivers/media/usb/gspca/sq905c.c
@@ -138,7 +138,7 @@ static void sq905c_dostream(struct work_struct *work)
int ret;
u8 *buffer;
- buffer = kmalloc(SQ905C_MAX_TRANSFER, GFP_KERNEL | GFP_DMA);
+ buffer = kmalloc(SQ905C_MAX_TRANSFER, GFP_KERNEL);
if (!buffer) {
pr_err("Couldn't allocate USB buffer\n");
goto quit_stream;
diff --git a/drivers/media/usb/gspca/vicam.c b/drivers/media/usb/gspca/vicam.c
index 554b90ef2200..8562bda0ef88 100644
--- a/drivers/media/usb/gspca/vicam.c
+++ b/drivers/media/usb/gspca/vicam.c
@@ -182,7 +182,7 @@ static void vicam_dostream(struct work_struct *work)
frame_sz = gspca_dev->cam.cam_mode[gspca_dev->curr_mode].sizeimage +
HEADER_SIZE;
- buffer = kmalloc(frame_sz, GFP_KERNEL | GFP_DMA);
+ buffer = kmalloc(frame_sz, GFP_KERNEL);
if (!buffer) {
pr_err("Couldn't allocate USB buffer\n");
goto exit;
--
2.17.0
Re: [v3] [media] Use common error handling code in 19 functions
> @@ -656,18 +656,18 @@ static int dvb_dmxdev_start_feed(struct dmxdev *dmxdev,
> tsfeed->priv = filter;
>
> ret = tsfeed->set(tsfeed, feed->pid, ts_type, ts_pes, timeout);
> - if (ret < 0) {
> - dmxdev->demux->release_ts_feed(dmxdev->demux, tsfeed);
> - return ret;
> - }
> + if (ret < 0)
> + goto release_feed;
>
> ret = tsfeed->start_filtering(tsfeed);
> - if (ret < 0) {
> - dmxdev->demux->release_ts_feed(dmxdev->demux, tsfeed);
> - return ret;
> - }
> + if (ret < 0)
> + goto release_feed;
>
> return 0;
> +
> +release_feed:
> + dmxdev->demux->release_ts_feed(dmxdev->demux, tsfeed);
> + return ret;
> }
>
> There's *nothing* wrong with the above. It works fine,
I can agree to this view in principle according to the required control flow.
> avoids goto
How does this wording fit to information from the section
“7) Centralized exiting of functions” in the document “coding-style.rst”?
> and probably even produce the same code, as gcc will likely optimize it.
Would you like to clarify the current situation around supported
software optimisations any more?
> It is also easier to review, as the error handling is closer
> to the code.
Do we stumble on different coding style preferences once more?
> On the other hand, there's nothing wrong on taking the approach
> you're proposing.
Thanks for another bit of positive feedback.
> In the end, using goto or not on error handling like the above is
> a matter of personal taste - and taste changes with time
Do Linux guidelines need any adjustments?
> and with developer. I really don't have time to keep reviewing patches
> that are just churning the code just due to someone's personal taste.
I tried to apply another general source code transformation pattern.
> I'm pretty sure if I start accepting things like that,
> someone else would be on some future doing patches just reverting it,
> and I would be likely having to apply them too.
Why?
I hope also that the source code can be kept consistent to some degree.
> So, except if the patch is really fixing something - e.g. a broken
> error handling code, I'll just ignore such patches and mark as
> rejected without further notice/comments from now on.
I would find such a communication style questionable.
Do you distinguish between bug fixes and possible corrections for
other error categories (or software weaknesses)?
Regards,
Markus
Re: 4.17-rc3 regression in UVC driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello again, On 05/05/18 08:34, Kieran Bingham wrote: > Hi Sebastian, > > On 04/05/18 19:45, Sebastian Reichel wrote: >> Hi, >> >> I just got the following error message every ms with 4.17-rc3 after >> upgrading to for first ~192 seconds after system start (Debian >> 4.17~rc3-1~exp1 kernel) on my Thinkpad X250: >> >>> uvcvideo: Failed to query (GET_MIN) UVC control 2 on unit 1: -32 (exp. >>> 1). > > I have submitted a patch to fix this ... (and I thought it would have got > in by now ... so I'll chase this up) Mauro - I just saw Laurent sent a pull-request for this last week, so I guess maybe it's on it's way: [GIT FIXES FOR v4.17] UVC fixes (25/04/2018) But perhaps it got missed ? - I don't see this patch in media/v4.17-4: git log media/v4.17-4 --grep="media: uvcvideo: Prevent setting unavailable flags " Anyway, I'll leave this in your hands. - -- Regards Kieran > Please see : https://patchwork.linuxtv.org/patch/48043/ and apply the > patch to bring your system logs back to a reasonable state :D > > Laurent, Mauro, > > This is the second bug report I've had on this topic. Can we aim to get > this patch merged please? > >> I see /dev/video0 and /dev/video1. The first one seems to be functional. >> The second one does not work and does not make sense to me (the system >> has only one webcam). I did not try to bisect anything. Here is some >> more information, that might be useful: > > There are two device nodes now, as one is provided to output meta-data or > such. > > >>> sre@earth ~ % mpv /dev/video1 Playing: /dev/video1 [ffmpeg/demuxer] >>> video4linux2,v4l2: ioctl(VIDIOC_G_INPUT): Inappropriate ioctl for >>> device [lavf] avformat_open_input() failed Failed to recognize file >>> format. sre@earth ~ % udevadm info /dev/video0 P: >>> /devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/video4linux/video0 >>> N: video0 E: DEVNAME=/dev/video0 E: >>> DEVPATH=/devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/video4linux/video0 >>> >>> >>> E: MAJOR=81 >>> E: MINOR=0 E: SUBSYSTEM=video4linux sre@earth ~ % udevadm info >>> /dev/video1 P: >>> /devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/video4linux/video1 >>> N: video1 E: DEVNAME=/dev/video1 E: >>> DEVPATH=/devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/video4linux/video1 >>> >>> >>> E: MAJOR=81 >>> E: MINOR=1 E: SUBSYSTEM=video4linux sre@earth ~ % lsusb -d 04ca:703c >>> Bus 001 Device 004: ID 04ca:703c Lite-On Technology Corp. >> >> -- Sebastian > > > Regards > > Kieran > -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEkC3XmD+9KP3jctR6oR5GchCkYf0FAlrtYWoACgkQoR5GchCk Yf3tQg/7BgBFIj9more5vTaCFEU2L+tapdOBItO+mgzHI9fFXVHAmaVUlSjVAiMX PlyRx1NsSnCRSZ4b6R/ydjEuNG5dLr2B8LfS5QP/6ABmUCONdCBIbx/2mDk+DtoX XZeI65MMr3nZG7f6ZNq2EoVPIcFF4WLY4CsfixBOye3ps4e91IkTDFA/EVG0qkD8 XLRHACYSe/7lMS2TcAyOlmzWecYLYqnFBxfjlBD80NfdWITsDZdooZ3KUdHTCqN4 ooWjyifkeh79D8M9PGhnNGoB4gbHjTMhbZEH4RaABdv/jO/L4kPExX+2Wjc4LnRj QlWmLm9svIisXJaPO6sPg+rIUr6xLTs5Dv5yYU+UpR9AVfVusHy7FfFoYkcHpThZ h0rc1yi6eU4/Nnz1BvQbLCdjab2yEF5nD05PQs22r4ZJy04ymiz+y3SZvlr8vYfu 2ZRJzjkvFHtWV3yd/LfjxmuzmYXH4Yn+yN8jMGu8sY4JtJEsSF8qPbjDpicOhXvI pv4V9xvDGscsZdKFaNv0IES+NHNRsgPvx0sR0DOb3MC8T9p+aEJPfQEBly1XBPG0 4GkvuA//DKpBASFdlSpKt4YW6OX56X+g8BPOcaBJV8BlBRzumDk4cAZ/T2t4DLm5 w3GnEwWLu0BiWl1LKqgh4xVgOg45IqcJJmDgupM3WzjCrYwVCbo= =B80a -END PGP SIGNATURE-
Re: 4.17-rc3 regression in UVC driver
Hi Sebastian, On 04/05/18 19:45, Sebastian Reichel wrote: > Hi, > > I just got the following error message every ms with 4.17-rc3 after > upgrading to for first ~192 seconds after system start (Debian > 4.17~rc3-1~exp1 kernel) on my Thinkpad X250: > >> uvcvideo: Failed to query (GET_MIN) UVC control 2 on unit 1: -32 (exp. 1). I have submitted a patch to fix this ... (and I thought it would have got in by now ... so I'll chase this up) Please see : https://patchwork.linuxtv.org/patch/48043/ and apply the patch to bring your system logs back to a reasonable state :D Laurent, Mauro, This is the second bug report I've had on this topic. Can we aim to get this patch merged please? > I see /dev/video0 and /dev/video1. The first one seems to be > functional. The second one does not work and does not make > sense to me (the system has only one webcam). I did not try to > bisect anything. Here is some more information, that might > be useful: There are two device nodes now, as one is provided to output meta-data or such. >> sre@earth ~ % mpv /dev/video1 >> Playing: /dev/video1 >> [ffmpeg/demuxer] video4linux2,v4l2: ioctl(VIDIOC_G_INPUT): Inappropriate >> ioctl for device >> [lavf] avformat_open_input() failed >> Failed to recognize file format. >> sre@earth ~ % udevadm info /dev/video0 >> P: /devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/video4linux/video0 >> N: video0 >> E: DEVNAME=/dev/video0 >> E: >> DEVPATH=/devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/video4linux/video0 >> E: MAJOR=81 >> E: MINOR=0 >> E: SUBSYSTEM=video4linux >> sre@earth ~ % udevadm info /dev/video1 >> P: /devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/video4linux/video1 >> N: video1 >> E: DEVNAME=/dev/video1 >> E: >> DEVPATH=/devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/video4linux/video1 >> E: MAJOR=81 >> E: MINOR=1 >> E: SUBSYSTEM=video4linux >> sre@earth ~ % lsusb -d 04ca:703c >> Bus 001 Device 004: ID 04ca:703c Lite-On Technology Corp. > > -- Sebastian Regards Kieran signature.asc Description: OpenPGP digital signature
