Re: [PATCH v2] staging: media: sunxi: Add bool cast to value
Hi,
On Mon 22 Jul 19, 18:58, Sakari Ailus wrote:
> On Mon, Jul 22, 2019 at 07:14:08PM +0530, Nishka Dasgupta wrote:
> > On 22/07/19 5:54 PM, Paul Kocialkowski wrote:
> > > Hi,
> > >
> > > On Mon 22 Jul 19, 12:12, Jeremy Sowden wrote:
> > > > On 2019-07-22, at 11:36:51 +0530, Nishka Dasgupta wrote:
> > > > > Typecast as bool the return value of cedrus_find_format in
> > > > > cedrus_check_format as the return value of cedrus_check_format is
> > > > > always treated like a boolean value.
> > > > >
> > > > > Signed-off-by: Nishka Dasgupta
> > > > > ---
> > > > > Changes in v2:
> > > > > - Add !! to the returned pointer to ensure that the return value is
> > > > >always either true or false, and never a non-zero value other than
> > > > >true.
> > > > >
> > > > > drivers/staging/media/sunxi/cedrus/cedrus_video.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > > > > b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > > > > index e2b530b1a956..b731745f21f8 100644
> > > > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > > > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > > > > @@ -86,7 +86,7 @@ static struct cedrus_format *cedrus_find_format(u32
> > > > > pixelformat, u32 directions,
> > > > > static bool cedrus_check_format(u32 pixelformat, u32 directions,
> > > > > unsigned int capabilities)
> > > > > {
> > > > > - return cedrus_find_format(pixelformat, directions,
> > > > > capabilities);
> > > > > + return !!(bool)cedrus_find_format(pixelformat, directions,
> > > > > capabilities);
> > > > > }
> > > >
> > > > I think the original was fine. The return value of cedrus_find_format
> > > > will be automatically converted to bool before being returned from
> > > > cedrus_check_format since that is the return-type of the function, and
> > > > the result of converting any non-zero value to bool is 1.
> > >
> > > Okay I was a bit unsure about that and wanted to play it on the safe side
> > > without really looking it up, but that gave me the occasion to verify.
> > >
> > > From what I could find (from my GNU system's
> > > /usr/include/unistring/stdbool.h):
> > >
> > > Limitations of this substitute, when used in a C89 environment:
> > >
> > > - In C99, casts and automatic conversions to '_Bool' or 'bool' are
> > > performed in such a way that every nonzero value gets converted
> > > to 'true', and zero gets converted to 'false'. This doesn't
> > > work
> > > with this substitute. With this substitute, only the values 0
> > > and 1
> > > give the expected result when converted to _Bool' or 'bool'.
> > >
> > > So since the kernel is built for C89 (unless I'm mistaken), I don't think
> > > the
> > > compiler provides any guarantee about bool values being converted to 1
> > > when
> > > they are non-zero. As a result, I think it's best to be careful.
> > >
> > > However, I'm not sure I really see what cocinelle was unhappy about. You
> > > mentionned single-line functions, but I don't see how that can be a
> > > problem.
> >
> > It's not a problem per se. I'm just working on a cleanup project for which I
> > went through all of staging replacing single-line functions with what they
> > were calling. In some cases that makes it easier to figure out what a
> > particular function call does, since the called function actually does
> > something itself instead of just calling a different function?
> > This function was also flagged as one such potentially-removable function by
> > Coccinelle; but in order to do the same replacement that I'd done in other
> > staging drivers, I thought I would do something about the type mismatch
> > first, especially since find_format doesn't appear to be used anywhere else.
> > However, now I won't remove check_format and replace it with find_format as
> > I'd originally planned, since you've said that isn't necessary here. That
> > leaves the return type issue.
> >
> >
> > > So in the end, I think we should keep the !! and drop the (bool) cast if
> > > there's
> > > no particular warning about it.
> >
> > Should I send a version 3 that does this?
>
> bool was introduced in C99. Converting a non-zero value to boolean will
> yield true as a result. Please keep the code as-is; it's much easier to
> read that way.
I was quite doubtful about that given the research and conclusions from
yesterday, but it seems that Linux is built for GNU 89 (not C89) which brings
support for bool "as in C99", so according to what you described.
So tl;dr, I agree with you that we should just keep the code as it is now.
Cheers,
Paul
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
[ragnatech:media-tree] BUILD SUCCESS 66193b24514c91aeda88da744554b2665471aeae
tree/branch: git://git.ragnatech.se/linux media-tree branch HEAD: 66193b24514c91aeda88da744554b2665471aeae media: dvbsky: add support for Mygica T230C v2 elapsed time: 707m configs tested: 109 The following configs have been built successfully. More configs may be tested in the coming days. mips allmodconfig mips malta_kvm_defconfig mips allnoconfig mips fuloong2e_defconfig x86_64 randconfig-g001-201929 x86_64 randconfig-g002-201929 x86_64 randconfig-g003-201929 x86_64 randconfig-g004-201929 i386 randconfig-g001-201929 i386 randconfig-g002-201929 i386 randconfig-g003-201929 i386 randconfig-g004-201929 powerpc allnoconfig powerpc defconfig powerpc ppc64_defconfig riscv tinyconfig i386 tinyconfig x86_64 allmodconfig x86_64 allyesconfig i386 alldefconfig x86_64lkp x86_64 rhel x86_64 rhel-7.6 x86_64 fedora-25 x86_64 kexec pariscallnoconfig parisc b180_defconfig pariscc3000_defconfig parisc defconfig arm at91_dt_defconfig arm64 defconfig armmulti_v5_defconfig sparc defconfig sparc64 allmodconfig sparc64 allnoconfig sparc64 defconfig alpha defconfig nds32 allnoconfig nds32 defconfig riscv allnoconfig riscv defconfig um x86_64_defconfig um i386_defconfig um defconfig x86_64 randconfig-h001-201929 x86_64 randconfig-h002-201929 x86_64 randconfig-h003-201929 x86_64 randconfig-h004-201929 i386 randconfig-h001-201929 i386 randconfig-h002-201929 i386 randconfig-h003-201929 i386 randconfig-h004-201929 mips 32r2_defconfig mips 64r6el_defconfig mips jz4740 mips txx9 x86_64 randconfig-e001-201929 x86_64 randconfig-e002-201929 x86_64 randconfig-e003-201929 x86_64 randconfig-e004-201929 i386 randconfig-e001-201929 i386 randconfig-e002-201929 i386 randconfig-e003-201929 i386 randconfig-e004-201929 i386 allmodconfig arm allmodconfig arm allnoconfig arm efm32_defconfig arm exynos_defconfig armmulti_v7_defconfig armshmobile_defconfig arm sunxi_defconfig arm64allmodconfig arm64 allnoconfig arm64allyesconfig arc allyesconfig arc defconfig microblaze mmu_defconfig microblazenommu_defconfig openriscor1ksim_defconfig nios2 3c120_defconfig c6xevmc6678_defconfig c6x allyesconfig nios2 10m50_defconfig s390 allmodconfig s390 allnoconfig s390 debug_defconfig s390defconfig h8300 edosk2674_defconfig h8300h8300h-sim_defconfig h8300 h8s-sim_defconfig xtensa common_defconfig xtensa iss_defconfig i386 allnoconfig i386defconfig ia64 allmodconfig ia64 allnoconfig ia64defconfig ia64 alldefconfig sh allmodconfig sh rsk7269_defconfig sh sh7785lcr_32bit_defconfig sh
Re: Issues with ov5640 camera on i.MX6Q
On 22.07.2019 19:25, Eric Nelson wrote:
> Hi Laura,
>
> On 7/22/19 8:50 AM, Laura Nao wrote:
>> Thanks Fabio!
>>
>> I tried tweaking the PLL configuration in the driver and did some
>> further tests on 5.2 kernel.
>>
>> I was finally able to capture RAW frames that match the test pattern
>> for 1280x720 and 1920x1080 resolutions. The 2592x1944 frame is still
>> not perfectly aligned, but it looks much closer to the test pattern.
>>
>> I uploaded the images here:
>>
>> https://imgur.com/a/ywHokMf
>>
>> The changes I made in the driver are below. Not sure these changes
>> make much sense, but they seem to fix 1280x720 and 1920x1080 frames.
>>
>> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
>> index 759d60c6..cfa678e 100644
>> --- a/drivers/media/i2c/ov5640.c
>> +++ b/drivers/media/i2c/ov5640.c
>> @@ -795,13 +795,13 @@ static int ov5640_mod_reg(struct ov5640_dev
>> *sensor, u16 reg,
>> * FIXME: to be re-calcualted for 1 data lanes setups
>> */
>> #define OV5640_MIPI_DIV_PCLK 2
>> -#define OV5640_MIPI_DIV_SCLK 1
>> +#define OV5640_MIPI_DIV_SCLK 2
>>
>> /*
>> * This is supposed to be ranging from 1 to 2, but the value is always
>> * set to 2 in the vendor kernels.
>> */
>> -#define OV5640_PLL_ROOT_DIV 2
>> +#define OV5640_PLL_ROOT_DIV 1
>> #define OV5640_PLL_CTRL3_PLL_ROOT_DIV_2 BIT(4)
>>
>> /*
>> @@ -836,8 +836,8 @@ static unsigned long ov5640_compute_sys_clk(struct
>> ov5640_dev *sensor,
>> unsigned long sysclk = sensor->xclk_freq / pll_prediv * pll_mult;
>>
>> /* PLL1 output cannot exceed 1GHz. */
>> - if (sysclk / 100 > 1000)
>> - return 0;
>> + // if (sysclk / 100 > 1000)
>> + // return 0;
>>
>> return sysclk / sysdiv;
>> }
>> @@ -1818,7 +1824,7 @@ static int ov5640_set_mode(struct ov5640_dev
>> *sensor)
>> * All the formats we support have 16 bits per pixel, seems to
>> require
>> * the same rate than YUV, so we can just use 16 bpp all the time.
>> */
>> - rate = mode->vtot * mode->htot * 16;
>> + rate = mode->vtot * mode->htot * 8;
>> rate *= ov5640_framerates[sensor->current_fr];
>> if (sensor->ep.bus_type == V4L2_MBUS_CSI2_DPHY) {
>> rate = rate / sensor->ep.bus.mipi_csi2.num_data_lanes;
>>
>
> How many frames per second are you getting out of this?
>
> If I'm reading this right, the change to ov5640_set_mode is reducing
> the frame rate (to 7.5 fps?), but I don't follow how the changes
> to OV5640_MIPI_DIV_SCLK and OV5640_PLL_ROOT_DIV are affecting things
> and the data sheet isn't very clear.
>
Hello ,
Are you using parallel or csi2 interface for this sensor ?
During my tests with atmel image sensor controller (parallel), I could
not get RAW frames at all. they were all garbled, as you described.
I would be happy to test patches if you fixed the RAW formats for this
sensor.
(currently, it works in YUV422 and RGB565 directly from the sensor for me)
Thanks,
Eugen
Re: [RFC,V2,1/2] media: dt-bindings: media: i2c: Add bindings for OV02A10
Hi Dongchun,
On Thu, Jul 04, 2019 at 04:46:50PM +0800, dongchun@mediatek.com wrote:
> From: Dongchun Zhu
>
> Add device tree binding documentation for the OV02A10 camera sensor.
>
> Signed-off-by: Dongchun Zhu
> ---
> .../devicetree/bindings/media/i2c/ov02a10.txt | 43
> ++
> MAINTAINERS| 7
> 2 files changed, 50 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov02a10.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov02a10.txt
> b/Documentation/devicetree/bindings/media/i2c/ov02a10.txt
> new file mode 100644
> index 000..d40aa87
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov02a10.txt
> @@ -0,0 +1,43 @@
> +* Omnivision OV02A10 MIPI CSI-2 sensor
> +
> +Required Properties:
> +- compatible: shall be "ovti,ov02a10"
> +- clocks: reference to the xvclk input clock
> +- clock-names: shall be "xvclk"
> +- avdd-supply: Analog voltage supply, 2.8 volts
> +- dovdd-supply: Digital I/O voltage supply, 1.8 volts
> +- dvdd-supply: Digital core voltage supply, 1.8 volts
> +- reset-gpios: Low active reset gpio
> +
> +The device node shall contain one 'port' child node with an
> +'endpoint' subnode for its digital output video port,
> +in accordance with the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +The endpoint optional property 'data-lanes' shall be "<1>".
How many lanes does the module (or the sensor) have?
> +
> +Example:
> +&i2c4 {
> + ov02a10: camera-sensor@3d {
> + compatible = "ovti,ov02a10";
> + reg = <0x3d>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&camera_pins_cam1_mclk_on>;
> +
> + clocks = <&topckgen CLK_TOP_MUX_CAMTG2>,
> + <&topckgen CLK_TOP_UNIVP_192M_D8>;
> + clock-names = "xvclk", "freq_mux";
> +
> + avdd-supply = <&mt6358_vcama1_reg>;
> + dvdd-supply = <&mt6358_vcn18_reg>;
> + dovdd-supply = <&mt6358_vcamio_reg>;
> + pwdn-gpios = <&pio 107 1>;
> + reset-gpios = <&pio 109 1>;
> +
> + port {
> +ov02a10_core: endpoint {
> +remote-endpoint = <&ov02a10_0>;
Indentation is still wrong. :-(
> +data-lanes = <1>;
> + };
> + };
> + };
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5cfbea4..62b81ff 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11571,6 +11571,13 @@ T: git git://linuxtv.org/media_tree.git
> S: Maintained
> F: drivers/media/i2c/ov13858.c
>
> +OMNIVISION OV02A10 SENSOR DRIVER
> +M: Dongchun Zhu
> +L: linux-media@vger.kernel.org
> +T: git git://linuxtv.org/media_tree.git
> +S: Maintained
> +F: Documentation/devicetree/bindings/media/i2c/ov02a10.txt
> +
> OMNIVISION OV2680 SENSOR DRIVER
> M: Rui Miguel Silva
> L: linux-media@vger.kernel.org
--
Kind regards,
Sakari Ailus
sakari.ai...@linux.intel.com
[PATCH] v4l2-dev/ioctl: require non-zero device_caps, verify sane querycap results
Now that all V4L2 drivers set device_caps in struct video_device, we can add a check for this to ensure all future drivers fill this in. Also verify that when the querycap ioctl is called the driver didn't mess with the device_caps value and that capabilities is a superset of device_caps. Signed-off-by: Hans Verkuil --- diff --git a/drivers/media/v4l2-core/v4l2-dev.c b/drivers/media/v4l2-core/v4l2-dev.c index cbb74f748555..3af72e3bbd65 100644 --- a/drivers/media/v4l2-core/v4l2-dev.c +++ b/drivers/media/v4l2-core/v4l2-dev.c @@ -859,6 +859,9 @@ int __video_register_device(struct video_device *vdev, /* the v4l2_dev pointer MUST be present */ if (WARN_ON(!vdev->v4l2_dev)) return -EINVAL; + /* the device_caps field MUST be set */ + if (WARN_ON(!vdev->device_caps)) + return -EINVAL; /* v4l2_fh support */ spin_lock_init(&vdev->fh_lock); diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index e36629ae2203..61846c355627 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -1057,14 +1057,18 @@ static int v4l_querycap(const struct v4l2_ioctl_ops *ops, ret = ops->vidioc_querycap(file, fh, cap); - cap->capabilities |= V4L2_CAP_EXT_PIX_FORMAT; /* -* Drivers MUST fill in device_caps, so check for this and -* warn if it was forgotten. +* Drivers must not change device_caps, so check for this and +* warn if this happened. +*/ + WARN_ON(cap->device_caps != vfd->device_caps); + /* +* Check that capabilities is a superset of +* vfd->device_caps | V4L2_CAP_DEVICE_CAPS */ - WARN(!(cap->capabilities & V4L2_CAP_DEVICE_CAPS) || - !cap->device_caps, "Bad caps for driver %s, %x %x", - cap->driver, cap->capabilities, cap->device_caps); + WARN_ON((cap->capabilities & (vfd->device_caps | V4L2_CAP_DEVICE_CAPS)) != + (vfd->device_caps | V4L2_CAP_DEVICE_CAPS)); + cap->capabilities |= V4L2_CAP_EXT_PIX_FORMAT; cap->device_caps |= V4L2_CAP_EXT_PIX_FORMAT; return ret;
[GIT PULL FOR v5.4] Various fixes/enhancements
This is part one of pending fixes/enhancements from my todo list. Once this is merged, I'll prepare a second PR for the remaining patches. Regards, Hans The following changes since commit 66193b24514c91aeda88da744554b2665471aeae: media: dvbsky: add support for Mygica T230C v2 (2019-07-22 15:33:30 -0400) are available in the Git repository at: git://linuxtv.org/hverkuil/media_tree.git tags/br-v5.4c2 for you to fetch changes up to ecc4494e3fdb135995319aee237bb6e383a2c7e0: media: vimc.rst: add vimc-streamer source documentation (2019-07-23 10:28:53 +0200) Tag branch André Almeida (5): media: vimc: stream: remove obsolete function doc media: vimc: stream: fix style of argument description media: vimc: stream: format comments as kernel-doc media: vimc.rst: Add a proper alt attribute to vimc.dot media: vimc.rst: add vimc-streamer source documentation Arnd Bergmann (2): media: davinci-vpbe: remove obsolete includes media: vivid: work around high stack usage with clang Colin Ian King (3): media: vivid: fix potential integer overflow on left shift media: cobalt: remove redundant assignment to variable data saa7134: remove redundant assignment to variable value Frederick Lawler (1): media: cobalt: Prefer pcie_capability_read_word() Hans Verkuil (11): v4l2-ioctl: call v4l_pix_format_touch() for TRY_FMT input/touchscreen/sur40: use COLORSPACE_RAW drivers/media: don't set pix->priv = 0 via-camera: call viafb_pm_unregister in remove() via-camera: use struct v4l2_fh ov7670: don't return ENOTTY if SUBDEV_API is not set via-camera: fix v4l2-compliance fails media/i2c: don't return ENOTTY if SUBDEV_API is not set m2m-deinterlace: use struct v4l2_fh omap_vout: use struct v4l2_fh mx2_emmaprp: use struct v4l2_fh Hariprasad Kelam (1): staging/media/davinci_vpfe: Add null check post kmalloc Joe Perches (2): media: m2m-deinterlace: Fix misuse of strscpy media: go7007: Fix misuse of strscpy Lucas Stach (1): media: vb2-dc: skip CPU sync in map/unmap dma_buf Maxime Ripard (1): MAINTAINERS: Update my email address Michael Tretter (2): media: vb2: reorder checks in vb2_poll() media: v4l2-mem2mem: reorder checks in v4l2_m2m_poll() Neil Armstrong (2): dt-bindings: media: meson-ao-cec: add SM1 compatible media: platform: meson-ao-cec-g12a: add support for SM1 Stephen Rothwell (1): media: vp8-ctrls.h: new file needs types.h Steve Longerbeam (1): media: staging/imx: Fix NULL deref in find_pipeline_entity() Vandana BN (1): media:vivid:add sanity check to avoid divide error and set value to 1 if 0. Wen Yang (2): media: exynos4-is: fix leaked of_node references media: ti-vpe: fix leaked of_node references .mailmap | 2 + Documentation/devicetree/bindings/media/meson-ao-cec.txt | 8 ++- Documentation/media/v4l-drivers/vimc.rst | 13 - MAINTAINERS | 10 ++-- drivers/input/touchscreen/sur40.c| 4 +- drivers/media/common/videobuf2/videobuf2-dma-contig.c| 23 +--- drivers/media/common/videobuf2/videobuf2-v4l2.c | 8 ++- drivers/media/i2c/mt9m111.c | 2 +- drivers/media/i2c/ov2640.c | 2 +- drivers/media/i2c/ov2659.c | 4 +- drivers/media/i2c/ov2680.c | 5 +- drivers/media/i2c/ov5695.c | 5 +- drivers/media/i2c/ov7670.c | 6 +- drivers/media/i2c/ov7740.c | 8 +-- drivers/media/pci/cobalt/cobalt-driver.c | 38 + drivers/media/pci/cobalt/cobalt-flash.c | 2 +- drivers/media/pci/cobalt/cobalt-v4l2.c | 1 - drivers/media/pci/saa7134/saa7134-tvaudio.c | 1 - drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 2 - drivers/media/pci/solo6x10/solo6x10-v4l2.c | 2 - drivers/media/pci/tw68/tw68-video.c | 1 - drivers/media/platform/davinci/vpbe_display.c| 4 -- drivers/media/platform/davinci/vpbe_osd.c| 5 -- drivers/media/platform/davinci/vpbe_venc.c | 5 -- drivers/media/platform/davinci/vpif_capture.c| 1 - drivers/media/platform/exynos4-is/fimc-is.c | 1 + drivers/media/platform/exynos4-is/media-dev.c| 2 + drivers/media/platform/m2m-deinterlace.c | 126 - drivers/media/platform/meson/ao-cec-g12a.c | 36
[RFC] Removal of drivers/staging/media/davinci_vpfe
Hi Prabhakar, This staging driver is now almost 7 years old, but hasn't seen any real development for a long time. I think it is time to remove it, unless you plan to do work on this. What do you think? Regards, Hans
Re: [RFC] Removal of drivers/staging/media/davinci_vpfe
+Laurent Pinchart On 7/23/19 10:46 AM, Hans Verkuil wrote: > Hi Prabhakar, > > This staging driver is now almost 7 years old, but hasn't seen any real > development for a long time. > > I think it is time to remove it, unless you plan to do work on this. > > What do you think? > > Regards, > > Hans >
[RFC] Removal of drivers/staging/media/bcm2048
This staging driver is now almost 6 years old, but hasn't seen any real development for a long time. I think it is time to remove it, unless someone plans to do work on this in the near future. If anyone wants to work on this, please let us know. Regards, Hans
[GIT PULL FOR v5.4] cec: use cec_notifier_cec_adap_(un)register
The following changes since commit 66193b24514c91aeda88da744554b2665471aeae: media: dvbsky: add support for Mygica T230C v2 (2019-07-22 15:33:30 -0400) are available in the Git repository at: git://linuxtv.org/hverkuil/media_tree.git tags/br-cec-conn-media for you to fetch changes up to 64e55689233b75f400d1d3d658f932804da2b369: tegra-cec: use cec_notifier_cec_adap_(un)register (2019-07-23 10:34:37 +0200) Tag branch Hans Verkuil (6): meson/ao-cec: use cec_notifier_cec_adap_(un)register cros-ec-cec: use cec_notifier_cec_adap_(un)register seco-cec: use cec_notifier_cec_adap_(un)register s5p-cec: use cec_notifier_cec_adap_(un)register stih-cec: use cec_notifier_cec_adap_(un)register tegra-cec: use cec_notifier_cec_adap_(un)register drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 69 +--- drivers/media/platform/meson/ao-cec-g12a.c | 48 ++-- drivers/media/platform/meson/ao-cec.c| 44 +++-- drivers/media/platform/s5p-cec/s5p_cec.c | 23 +++--- drivers/media/platform/seco-cec/seco-cec.c | 55 ++--- drivers/media/platform/sti/cec/stih-cec.c| 32 +++- drivers/media/platform/tegra-cec/tegra_cec.c | 35 +- 7 files changed, 163 insertions(+), 143 deletions(-)
Re: [RFC] Removal of drivers/staging/media/davinci_vpfe
Hi Hans, On Tue, Jul 23, 2019 at 9:48 AM Hans Verkuil wrote: > > +Laurent Pinchart > > On 7/23/19 10:46 AM, Hans Verkuil wrote: > > Hi Prabhakar, > > > > This staging driver is now almost 7 years old, but hasn't seen any real > > development for a long time. > > > > I think it is time to remove it, unless you plan to do work on this. > > > > What do you think? > > I don’t have any plans to work on it anytime soon, and also referring to Sekhar's email on Arnd's patch he's OK too drop the driver from staging. shall I create a patch doing this ? Cheers, --Prabhakar
Re: [RFC] Removal of drivers/staging/media/bcm2048
On Tue 2019-07-23 10:51:52, Hans Verkuil wrote: > This staging driver is now almost 6 years old, but hasn't seen any real > development for a long time. > > I think it is time to remove it, unless someone plans to do work on this > in the near future. > > If anyone wants to work on this, please let us know. So... unfortunately this one depends on bluetooth driver, which is quite complex. Unfortunately, that one was removed from staging while it was being worked upon, and seen little progress since that. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [RFC] Removal of drivers/staging/media/davinci_vpfe
On 7/23/19 11:06 AM, Lad, Prabhakar wrote: > Hi Hans, > > On Tue, Jul 23, 2019 at 9:48 AM Hans Verkuil wrote: >> >> +Laurent Pinchart >> >> On 7/23/19 10:46 AM, Hans Verkuil wrote: >>> Hi Prabhakar, >>> >>> This staging driver is now almost 7 years old, but hasn't seen any real >>> development for a long time. >>> >>> I think it is time to remove it, unless you plan to do work on this. >>> >>> What do you think? >>> > I don’t have any plans to work on it anytime soon, and also referring > to Sekhar's email > on Arnd's patch he's OK too drop the driver from staging. > > shall I create a patch doing this ? Arnd mentioned he was going to post a patch for that. Regards, Hans
Re: [RFC] Removal of drivers/staging/media/bcm2048
On Tuesday 23 July 2019 11:09:53 Pavel Machek wrote: > On Tue 2019-07-23 10:51:52, Hans Verkuil wrote: > > This staging driver is now almost 6 years old, but hasn't seen any real > > development for a long time. > > > > I think it is time to remove it, unless someone plans to do work on this > > in the near future. > > > > If anyone wants to work on this, please let us know. > > So... unfortunately this one depends on bluetooth driver, which is > quite complex. Unfortunately, that one was removed from staging while > it was being worked upon, and seen little progress since that. There is already a new bluetooth driver hci_nokia for bcm2048: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/bluetooth/hci_nokia.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-n900.dts -- Pali Rohár pali.ro...@gmail.com
[GIT PULL v2 FOR v5.4] Various fixes/enhancements
This is part one of pending fixes/enhancements from my todo list. Once this is merged, I'll prepare a second PR for the remaining patches. Regards, Hans Changes since v1: - Dropped "MAINTAINERS: Update my email address" since it went in via the sunxi tree. The following changes since commit 66193b24514c91aeda88da744554b2665471aeae: media: dvbsky: add support for Mygica T230C v2 (2019-07-22 15:33:30 -0400) are available in the Git repository at: git://linuxtv.org/hverkuil/media_tree.git tags/br-v5.4c3 for you to fetch changes up to c944e896aa22d7cd1a94053aaa39d2dc0b5f82cf: media: vimc.rst: add vimc-streamer source documentation (2019-07-23 11:28:07 +0200) Tag branch André Almeida (5): media: vimc: stream: remove obsolete function doc media: vimc: stream: fix style of argument description media: vimc: stream: format comments as kernel-doc media: vimc.rst: Add a proper alt attribute to vimc.dot media: vimc.rst: add vimc-streamer source documentation Arnd Bergmann (2): media: davinci-vpbe: remove obsolete includes media: vivid: work around high stack usage with clang Colin Ian King (3): media: vivid: fix potential integer overflow on left shift media: cobalt: remove redundant assignment to variable data saa7134: remove redundant assignment to variable value Frederick Lawler (1): media: cobalt: Prefer pcie_capability_read_word() Hans Verkuil (11): v4l2-ioctl: call v4l_pix_format_touch() for TRY_FMT input/touchscreen/sur40: use COLORSPACE_RAW drivers/media: don't set pix->priv = 0 via-camera: call viafb_pm_unregister in remove() via-camera: use struct v4l2_fh ov7670: don't return ENOTTY if SUBDEV_API is not set via-camera: fix v4l2-compliance fails media/i2c: don't return ENOTTY if SUBDEV_API is not set m2m-deinterlace: use struct v4l2_fh omap_vout: use struct v4l2_fh mx2_emmaprp: use struct v4l2_fh Hariprasad Kelam (1): staging/media/davinci_vpfe: Add null check post kmalloc Joe Perches (2): media: m2m-deinterlace: Fix misuse of strscpy media: go7007: Fix misuse of strscpy Lucas Stach (1): media: vb2-dc: skip CPU sync in map/unmap dma_buf Michael Tretter (2): media: vb2: reorder checks in vb2_poll() media: v4l2-mem2mem: reorder checks in v4l2_m2m_poll() Neil Armstrong (2): dt-bindings: media: meson-ao-cec: add SM1 compatible media: platform: meson-ao-cec-g12a: add support for SM1 Stephen Rothwell (1): media: vp8-ctrls.h: new file needs types.h Steve Longerbeam (1): media: staging/imx: Fix NULL deref in find_pipeline_entity() Vandana BN (1): media:vivid:add sanity check to avoid divide error and set value to 1 if 0. Wen Yang (2): media: exynos4-is: fix leaked of_node references media: ti-vpe: fix leaked of_node references Documentation/devicetree/bindings/media/meson-ao-cec.txt | 8 +++-- Documentation/media/v4l-drivers/vimc.rst | 13 +++- drivers/input/touchscreen/sur40.c| 4 +-- drivers/media/common/videobuf2/videobuf2-dma-contig.c| 23 +- drivers/media/common/videobuf2/videobuf2-v4l2.c | 8 +++-- drivers/media/i2c/mt9m111.c | 2 +- drivers/media/i2c/ov2640.c | 2 +- drivers/media/i2c/ov2659.c | 4 +-- drivers/media/i2c/ov2680.c | 5 +-- drivers/media/i2c/ov5695.c | 5 +-- drivers/media/i2c/ov7670.c | 6 ++-- drivers/media/i2c/ov7740.c | 8 ++--- drivers/media/pci/cobalt/cobalt-driver.c | 38 +- drivers/media/pci/cobalt/cobalt-flash.c | 2 +- drivers/media/pci/cobalt/cobalt-v4l2.c | 1 - drivers/media/pci/saa7134/saa7134-tvaudio.c | 1 - drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 2 -- drivers/media/pci/solo6x10/solo6x10-v4l2.c | 2 -- drivers/media/pci/tw68/tw68-video.c | 1 - drivers/media/platform/davinci/vpbe_display.c| 4 --- drivers/media/platform/davinci/vpbe_osd.c| 5 --- drivers/media/platform/davinci/vpbe_venc.c | 5 --- drivers/media/platform/davinci/vpif_capture.c| 1 - drivers/media/platform/exynos4-is/fimc-is.c | 1 + drivers/media/platform/exynos4-is/media-dev.c| 2 ++ drivers/media/platform/m2m-deinterlace.c | 126 ++--- drivers/media/platform/meson/ao-cec-g12a.c | 36 +++
Re: [RFC] Removal of drivers/staging/media/davinci_vpfe
On Tue, Jul 23, 2019 at 11:25 AM Hans Verkuil wrote: > > On 7/23/19 11:06 AM, Lad, Prabhakar wrote: > > Hi Hans, > > > > On Tue, Jul 23, 2019 at 9:48 AM Hans Verkuil wrote: > >> > >> +Laurent Pinchart > >> > >> On 7/23/19 10:46 AM, Hans Verkuil wrote: > >>> Hi Prabhakar, > >>> > >>> This staging driver is now almost 7 years old, but hasn't seen any real > >>> development for a long time. > >>> > >>> I think it is time to remove it, unless you plan to do work on this. > >>> > >>> What do you think? > >>> > > I don’t have any plans to work on it anytime soon, and also referring > > to Sekhar's email > > on Arnd's patch he's OK too drop the driver from staging. > > > > shall I create a patch doing this ? > > Arnd mentioned he was going to post a patch for that. Sent a patch now, I had not seen this thread before creating that. Arnd
Re: [RFC] Removal of drivers/staging/media/bcm2048
On 7/23/19 11:48 AM, Pali Rohár wrote: > On Tuesday 23 July 2019 11:09:53 Pavel Machek wrote: >> On Tue 2019-07-23 10:51:52, Hans Verkuil wrote: >>> This staging driver is now almost 6 years old, but hasn't seen any real >>> development for a long time. >>> >>> I think it is time to remove it, unless someone plans to do work on this >>> in the near future. >>> >>> If anyone wants to work on this, please let us know. >> >> So... unfortunately this one depends on bluetooth driver, which is >> quite complex. Unfortunately, that one was removed from staging while >> it was being worked upon, and seen little progress since that. > > There is already a new bluetooth driver hci_nokia for bcm2048: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/bluetooth/hci_nokia.c Hmm, this went in two years ago. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-n900.dts > Is there any chance that this bcm2048 driver will be fixed and moved out of staging by the end of this year? If not, then I want to remove it. Regards, Hans
Re: [PATCH] v4l2-dev/ioctl: require non-zero device_caps, verify sane querycap results
Hi Hans, On Tue, Jul 23, 2019 at 10:21:25AM +0200, Hans Verkuil wrote: > Now that all V4L2 drivers set device_caps in struct video_device, we can add > a check for this to ensure all future drivers fill this in. > > Also verify that when the querycap ioctl is called the driver didn't mess > with the device_caps value and that capabilities is a superset of device_caps. > > Signed-off-by: Hans Verkuil > --- > diff --git a/drivers/media/v4l2-core/v4l2-dev.c > b/drivers/media/v4l2-core/v4l2-dev.c > index cbb74f748555..3af72e3bbd65 100644 > --- a/drivers/media/v4l2-core/v4l2-dev.c > +++ b/drivers/media/v4l2-core/v4l2-dev.c > @@ -859,6 +859,9 @@ int __video_register_device(struct video_device *vdev, > /* the v4l2_dev pointer MUST be present */ > if (WARN_ON(!vdev->v4l2_dev)) > return -EINVAL; > + /* the device_caps field MUST be set */ > + if (WARN_ON(!vdev->device_caps)) > + return -EINVAL; > > /* v4l2_fh support */ > spin_lock_init(&vdev->fh_lock); > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c > b/drivers/media/v4l2-core/v4l2-ioctl.c > index e36629ae2203..61846c355627 100644 > --- a/drivers/media/v4l2-core/v4l2-ioctl.c > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c > @@ -1057,14 +1057,18 @@ static int v4l_querycap(const struct v4l2_ioctl_ops > *ops, > > ret = ops->vidioc_querycap(file, fh, cap); > > - cap->capabilities |= V4L2_CAP_EXT_PIX_FORMAT; > /* > - * Drivers MUST fill in device_caps, so check for this and > - * warn if it was forgotten. > + * Drivers must not change device_caps, so check for this and > + * warn if this happened. > + */ > + WARN_ON(cap->device_caps != vfd->device_caps); > + /* > + * Check that capabilities is a superset of > + * vfd->device_caps | V4L2_CAP_DEVICE_CAPS >*/ > - WARN(!(cap->capabilities & V4L2_CAP_DEVICE_CAPS) || > - !cap->device_caps, "Bad caps for driver %s, %x %x", > - cap->driver, cap->capabilities, cap->device_caps); > + WARN_ON((cap->capabilities & (vfd->device_caps | V4L2_CAP_DEVICE_CAPS)) > != This is over 80, it'd be nicer it it was wrapped. Either way, Reviewed-by: Sakari Ailus > + (vfd->device_caps | V4L2_CAP_DEVICE_CAPS)); > + cap->capabilities |= V4L2_CAP_EXT_PIX_FORMAT; > cap->device_caps |= V4L2_CAP_EXT_PIX_FORMAT; > > return ret; -- Kind regards, Sakari Ailus
[PATCH] sh_veu: convert to struct v4l2_fh
This driver didn't use struct v4l2_fh, so add it.
This is a very basic conversion. I can't test this on real hardware,
so I didn't dare to also convert the driver to start using the
v4l2-mem2mem ioctl/fop helpers.
Signed-off-by: Hans Verkuil
---
diff --git a/drivers/media/platform/sh_veu.c b/drivers/media/platform/sh_veu.c
index 4be6efd47d33..2b4c0d9d6928 100644
--- a/drivers/media/platform/sh_veu.c
+++ b/drivers/media/platform/sh_veu.c
@@ -81,6 +81,7 @@
struct sh_veu_dev;
struct sh_veu_file {
+ struct v4l2_fh fh;
struct sh_veu_dev *veu_dev;
bool cfg_needed;
};
@@ -961,12 +962,14 @@ static int sh_veu_open(struct file *file)
if (!veu_file)
return -ENOMEM;
+ v4l2_fh_init(&veu_file->fh, video_devdata(file));
veu_file->veu_dev = veu;
veu_file->cfg_needed = true;
file->private_data = veu_file;
pm_runtime_get_sync(veu->dev);
+ v4l2_fh_add(&veu_file->fh);
dev_dbg(veu->dev, "Created instance %p\n", veu_file);
@@ -996,6 +999,8 @@ static int sh_veu_release(struct file *file)
}
pm_runtime_put(veu->dev);
+ v4l2_fh_del(&veu_file->fh);
+ v4l2_fh_exit(&veu_file->fh);
kfree(veu_file);
[PATCH] davinci/vpfe_capture.c: drop unused format descriptions
Simplify vpfe_pixel_format to just contain the pixelformat and bpp fields.
All others are unused.
Signed-off-by: Hans Verkuil
---
diff --git a/drivers/media/platform/davinci/vpfe_capture.c
b/drivers/media/platform/davinci/vpfe_capture.c
index 852fc357e19d..916ed743d716 100644
--- a/drivers/media/platform/davinci/vpfe_capture.c
+++ b/drivers/media/platform/davinci/vpfe_capture.c
@@ -119,57 +119,27 @@ static const struct vpfe_standard vpfe_standards[] = {
/* Used when raw Bayer image from ccdc is directly captured to SDRAM */
static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
{
- .fmtdesc = {
- .index = 0,
- .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
- .description = "Bayer GrRBGb 8bit A-Law compr.",
- .pixelformat = V4L2_PIX_FMT_SBGGR8,
- },
+ .pixelformat = V4L2_PIX_FMT_SBGGR8,
.bpp = 1,
},
{
- .fmtdesc = {
- .index = 1,
- .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
- .description = "Bayer GrRBGb - 16bit",
- .pixelformat = V4L2_PIX_FMT_SBGGR16,
- },
+ .pixelformat = V4L2_PIX_FMT_SBGGR16,
.bpp = 2,
},
{
- .fmtdesc = {
- .index = 2,
- .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
- .description = "Bayer GrRBGb 8bit DPCM compr.",
- .pixelformat = V4L2_PIX_FMT_SGRBG10DPCM8,
- },
+ .pixelformat = V4L2_PIX_FMT_SGRBG10DPCM8,
.bpp = 1,
},
{
- .fmtdesc = {
- .index = 3,
- .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
- .description = "YCbCr 4:2:2 Interleaved UYVY",
- .pixelformat = V4L2_PIX_FMT_UYVY,
- },
+ .pixelformat = V4L2_PIX_FMT_UYVY,
.bpp = 2,
},
{
- .fmtdesc = {
- .index = 4,
- .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
- .description = "YCbCr 4:2:2 Interleaved YUYV",
- .pixelformat = V4L2_PIX_FMT_YUYV,
- },
+ .pixelformat = V4L2_PIX_FMT_YUYV,
.bpp = 2,
},
{
- .fmtdesc = {
- .index = 5,
- .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
- .description = "Y/CbCr 4:2:0 - Semi planar",
- .pixelformat = V4L2_PIX_FMT_NV12,
- },
+ .pixelformat = V4L2_PIX_FMT_NV12,
.bpp = 1,
},
};
@@ -183,7 +153,7 @@ static const struct vpfe_pixel_format
*vpfe_lookup_pix_format(u32 pix_format)
int i;
for (i = 0; i < ARRAY_SIZE(vpfe_pix_fmts); i++) {
- if (pix_format == vpfe_pix_fmts[i].fmtdesc.pixelformat)
+ if (pix_format == vpfe_pix_fmts[i].pixelformat)
return &vpfe_pix_fmts[i];
}
return NULL;
@@ -782,7 +752,7 @@ static const struct vpfe_pixel_format *
temp = 0;
found = 0;
while (ccdc_dev->hw_ops.enum_pix(&pix, temp) >= 0) {
- if (vpfe_pix_fmt->fmtdesc.pixelformat == pix) {
+ if (vpfe_pix_fmt->pixelformat == pix) {
found = 1;
break;
}
@@ -899,7 +869,6 @@ static int vpfe_enum_fmt_vid_cap(struct file *file, void
*priv,
{
struct vpfe_device *vpfe_dev = video_drvdata(file);
const struct vpfe_pixel_format *pix_fmt;
- int temp_index;
u32 pix;
v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_enum_fmt_vid_cap\n");
@@ -910,9 +879,7 @@ static int vpfe_enum_fmt_vid_cap(struct file *file, void
*priv,
/* Fill in the information about format */
pix_fmt = vpfe_lookup_pix_format(pix);
if (pix_fmt) {
- temp_index = fmt->index;
- *fmt = pix_fmt->fmtdesc;
- fmt->index = temp_index;
+ fmt->pixelformat = fmt->pixelformat;
return 0;
}
return -EINVAL;
diff --git a/include/media/davinci/vpfe_capture.h
b/include/media/davinci/vpfe_capture.h
index 2c5b3eacf527..4ad53031e2f7 100644
--- a/include/media/davinci/vpfe_capture.h
+++ b/include/media/davinci/vpfe_capture.h
@@ -32,7 +32,7 @@
#define CAPTURE_DRV_NAME "vpfe-capture"
struct vpfe_pixel_format {
- struct v4l2_fmtdesc fmtdesc;
+ u32 pixelformat;
/* bytes per pixel */
int bpp;
};
[PATCH] am437x: remove unused struct vpfe_pixel_format
struct vpfe_pixel_format was defined, but never used. Remove it.
Signed-off-by: Hans Verkuil
---
diff --git a/drivers/media/platform/am437x/am437x-vpfe.h
b/drivers/media/platform/am437x/am437x-vpfe.h
index 17d7aa426788..4678285f34c6 100644
--- a/drivers/media/platform/am437x/am437x-vpfe.h
+++ b/drivers/media/platform/am437x/am437x-vpfe.h
@@ -65,12 +65,6 @@ struct vpfe_hw_if_param {
#define VPFE_MAX_SUBDEV1
#define VPFE_MAX_INPUTS1
-struct vpfe_pixel_format {
- struct v4l2_fmtdesc fmtdesc;
- /* bytes per pixel */
- int bpp;
-};
-
struct vpfe_std_info {
int active_pixels;
int active_lines;
Re: kernel Warning when using vivid with contiguous dma
On Mon, 2019-07-22 at 08:38 -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 22 Jul 2019 13:21:00 +0200
> Dafna Hirschfeld escreveu:
>
> > I loaded the vivid module with contiguous DMA and ran streaming
> > with
> > it with large image dimensions
> > [ 306.437327] Call Trace:
> > [ 306.437338] __dma_direct_alloc_pages+0xc9/0x1c0
> > [ 306.437343] dma_direct_alloc_pages+0x24/0xf0
> > [ 306.437348] dma_direct_alloc+0xe/0x10
> > [ 306.437351] dma_alloc_attrs+0x84/0xd0
>
> Hmm... we had a recent regression affecting other media devices,
> reported via Kaffeine mailing list:
>
> https://bugs.kde.org/show_bug.cgi?id=408004#c35
>
> While this one was for S/G, maybe it is somewhat related.
>
Also, I compiled vivid as built-in into the kernel (not as a separate module)
for nitrogen8m device (imx8) and
set it to use contig dma for mem_ops. Then I get a crash when running the above
command.
I use the master branch of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git with this
patch to vivid:
diff --git a/drivers/media/platform/vivid/vivid-core.c
b/drivers/media/platform/vivid/vivid-core.c
index bc2a176937a4..0531f36d7d0a 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -140,7 +140,7 @@ static bool no_error_inj;
module_param(no_error_inj, bool, 0444);
MODULE_PARM_DESC(no_error_inj, " if set disable the error injecting controls");
-static unsigned int allocators[VIVID_MAX_DEVS] = { [0 ... (VIVID_MAX_DEVS -
1)] = 0 };
+static unsigned int allocators[VIVID_MAX_DEVS] = { [0 ... (VIVID_MAX_DEVS -
1)] = 1 };
module_param_array(allocators, uint, NULL, 0444);
MODULE_PARM_DESC(allocators, " memory allocator selection, default is 0.\n"
"\t\t0 == vmalloc\n"
And then on the nitrogen8m device I get the following crash report which seems
to be related to the cma allocation
ubuntu@bionic-dev64:~$ v4l2-ctl -d3 -v
width=2592,height=1944,pixelformat=UYVY,bytesperline=5184 --stream-mmap
--stream-to video.UYVY
[ 70.139006] cma: cma_alloc(cma (ptrval), count 4050, align 8)
[ 70.159829] cma: cma_alloc(cma (ptrval), count 4050, align 8)
[ 70.166292] cma: cma_alloc: alloc failed, req-size: 4050 pages, ret: -12
[ 70.173006] cma: number of available pages: 72@184+3886@4306=> 3958 free of
8192 total pages
[ 70.181471] cma: cma_alloc(): returned (ptrval)
[ 70.192449] cma: cma_alloc(cma (ptrval), count 4050, align 8)
[ 70.198907] cma: cma_alloc: alloc failed, req-size: 4050 pages, ret: -12
[ 70.205625] cma: number of available pages: 72@184+3886@4306=> 3958 free of
8192 total pages
[ 70.205733] systemd-journald[204]:
/var/log/journal/5cca8918401249538eacb5efd5b9b052/system.journal: Journal file
corrupted, rotating.
[ 70.214083] cma: cma_alloc(): returned (ptrval)
[ 70.219867] cma: cma_alloc(cma (ptrval), count 4050, align 8)
[ 70.237878] cma: cma_alloc: alloc failed, req-size: 4050 pages, ret: -12
[ 70.244599] cma: number of available pages: 72@184+3886@4306=> 3958 free of
8192 total pages
[ 70.253066] cma: cma_alloc(): returned (ptrval)
[ 70.264893] cma: cma_release(page (ptrval))
[ 70.272871] cma: cma_release(page (ptrval))
[ 70.277800] BUG: Bad page state in process v4l2-ctl pfn:b5a00
[ 70.283652] page:7e0001d68000 refcount:13 mapcount:0
mapping: index:0x0 compound_mapcount: 0
[ 70.293874] flags: 0x001(head)
[ 70.297999] raw: 0001 dead0100 dead0122
[ 70.305772] raw: 000d
[ 70.313526] page dumped because: nonzero _refcount
[ 70.318327] Modules linked in:
[ 70.321399] CPU: 2 PID: 482 Comm: v4l2-ctl Not tainted 5.3.0-rc1+ #159
[ 70.327927] Hardware name: Boundary Devices i.MX8MQ Nitrogen8M (DT)
[ 70.334196] Call trace:
[ 70.336654] dump_backtrace+0x0/0x148
[ 70.340319] show_stack+0x14/0x20
[ 70.343640] dump_stack+0x9c/0xc4
[ 70.346959] bad_page+0xe4/0x148
[ 70.350188] free_pages_check_bad+0x70/0xa8
[ 70.354375] __free_pages_ok+0x294/0x2b0
[ 70.358301] __free_pages+0x38/0x50
[ 70.361795] dma_free_contiguous+0x90/0x98
[ 70.365892] __dma_direct_free_pages+0x18/0x20
[ 70.370338] arch_dma_free+0x74/0x88
[ 70.373916] dma_direct_free+0x4c/0x58
[ 70.377668] dma_free_attrs+0x88/0xe0
[ 70.381335] vb2_dc_put+0x44/0x60
[ 70.384653] __vb2_buf_mem_free+0x68/0x110
[ 70.388749] __vb2_queue_free+0x398/0x538
[ 70.392763] vb2_core_queue_release+0x34/0x48
[ 70.397122] _vb2_fop_release+0x88/0x98
[ 70.400960] vb2_fop_release+0x28/0x50
[ 70.404712] vivid_fop_release+0x88/0x208
[ 70.408725] v4l2_release+0x6c/0xf0
[ 70.412216] __fput+0x8c/0x1f8
[ 70.415270] fput+0xc/0x18
[ 70.418328] task_work_run+0x94/0xb0
[ 70.421907] do_exit+0x2b0/0x9f8
[ 70.425138] do_group_exit+0x34/0x98
[ 70.428
Re: kernel Warning when using vivid with contiguous dma
On 7/23/19 3:14 PM, Dafna Hirschfeld wrote:
> On Mon, 2019-07-22 at 08:38 -0300, Mauro Carvalho Chehab wrote:
>> Em Mon, 22 Jul 2019 13:21:00 +0200
>> Dafna Hirschfeld escreveu:
>>
>>> I loaded the vivid module with contiguous DMA and ran streaming
>>> with
>>> it with large image dimensions
>>> [ 306.437327] Call Trace:
>>> [ 306.437338] __dma_direct_alloc_pages+0xc9/0x1c0
>>> [ 306.437343] dma_direct_alloc_pages+0x24/0xf0
>>> [ 306.437348] dma_direct_alloc+0xe/0x10
>>> [ 306.437351] dma_alloc_attrs+0x84/0xd0
>>
>> Hmm... we had a recent regression affecting other media devices,
>> reported via Kaffeine mailing list:
>>
>> https://bugs.kde.org/show_bug.cgi?id=408004#c35
>>
>> While this one was for S/G, maybe it is somewhat related.
>>
> Also, I compiled vivid as built-in into the kernel (not as a separate module)
> for nitrogen8m device (imx8) and
> set it to use contig dma for mem_ops. Then I get a crash when running the
> above command.
> I use the master branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git with this
> patch to vivid:
>
> diff --git a/drivers/media/platform/vivid/vivid-core.c
> b/drivers/media/platform/vivid/vivid-core.c
> index bc2a176937a4..0531f36d7d0a 100644
> --- a/drivers/media/platform/vivid/vivid-core.c
> +++ b/drivers/media/platform/vivid/vivid-core.c
> @@ -140,7 +140,7 @@ static bool no_error_inj;
> module_param(no_error_inj, bool, 0444);
> MODULE_PARM_DESC(no_error_inj, " if set disable the error injecting
> controls");
>
> -static unsigned int allocators[VIVID_MAX_DEVS] = { [0 ... (VIVID_MAX_DEVS -
> 1)] = 0 };
> +static unsigned int allocators[VIVID_MAX_DEVS] = { [0 ... (VIVID_MAX_DEVS -
> 1)] = 1 };
> module_param_array(allocators, uint, NULL, 0444);
> MODULE_PARM_DESC(allocators, " memory allocator selection, default is 0.\n"
> "\t\t0 == vmalloc\n"
>
> And then on the nitrogen8m device I get the following crash report which
> seems to be related to the cma allocation
>
> ubuntu@bionic-dev64:~$ v4l2-ctl -d3 -v
> width=2592,height=1944,pixelformat=UYVY,bytesperline=5184 --stream-mmap
> --stream-to video.UYVY
> [ 70.139006] cma: cma_alloc(cma (ptrval), count 4050, align 8)
> [ 70.159829] cma: cma_alloc(cma (ptrval), count 4050, align 8)
> [ 70.166292] cma: cma_alloc: alloc failed, req-size: 4050 pages, ret: -12
> [ 70.173006] cma: number of available pages: 72@184+3886@4306=> 3958 free
> of 8192 total pages
So it looks like the CMA area is too small. Look at the CONFIG_CMA_SIZE_MBYTES
setting.
That explains why it fails.
> [ 70.181471] cma: cma_alloc(): returned (ptrval)
> [ 70.192449] cma: cma_alloc(cma (ptrval), count 4050, align 8)
> [ 70.198907] cma: cma_alloc: alloc failed, req-size: 4050 pages, ret: -12
> [ 70.205625] cma: number of available pages: 72@184+3886@4306=> 3958 free
> of 8192 total pages
> [ 70.205733] systemd-journald[204]:
> /var/log/journal/5cca8918401249538eacb5efd5b9b052/system.journal: Journal
> file corrupted, rotating.
> [ 70.214083] cma: cma_alloc(): returned (ptrval)
> [ 70.219867] cma: cma_alloc(cma (ptrval), count 4050, align 8)
> [ 70.237878] cma: cma_alloc: alloc failed, req-size: 4050 pages, ret: -12
> [ 70.244599] cma: number of available pages: 72@184+3886@4306=> 3958 free
> of 8192 total pages
> [ 70.253066] cma: cma_alloc(): returned (ptrval)
> [ 70.264893] cma: cma_release(page (ptrval))
> [ 70.272871] cma: cma_release(page (ptrval))
> [ 70.277800] BUG: Bad page state in process v4l2-ctl pfn:b5a00
But that shouldn't lead to this.
It could be a bug somewhere.
Does it work fine if you use a smaller resolution? Perhaps there is something
wrong in error handling in vb2. These corner cases are not exactly tested
very often (or at all!).
Regards,
Hans
> [ 70.283652] page:7e0001d68000 refcount:13 mapcount:0
> mapping: index:0x0 compound_mapcount: 0
> [ 70.293874] flags: 0x001(head)
> [ 70.297999] raw: 0001 dead0100 dead0122
>
> [ 70.305772] raw: 000d
>
> [ 70.313526] page dumped because: nonzero _refcount
> [ 70.318327] Modules linked in:
> [ 70.321399] CPU: 2 PID: 482 Comm: v4l2-ctl Not tainted 5.3.0-rc1+ #159
> [ 70.327927] Hardware name: Boundary Devices i.MX8MQ Nitrogen8M (DT)
> [ 70.334196] Call trace:
> [ 70.336654] dump_backtrace+0x0/0x148
> [ 70.340319] show_stack+0x14/0x20
> [ 70.343640] dump_stack+0x9c/0xc4
> [ 70.346959] bad_page+0xe4/0x148
> [ 70.350188] free_pages_check_bad+0x70/0xa8
> [ 70.354375] __free_pages_ok+0x294/0x2b0
> [ 70.358301] __free_pages+0x38/0x50
> [ 70.361795] dma_free_contiguous+0x90/0x98
> [ 70.365892] __dma_direct_free_pages+0x18/0x20
> [ 70.370338] arch_dma_free+0x74/0x88
> [ 70.373916] dma_direct_free
Re: Question about TW686X driver
Hey Mark, I'm glad you are having fun with the driver. On Tue, 23 Jul 2019 at 11:45, Mark Balançian wrote: > > Hello all, > > My name is Mark and I am working on contributing to the open-source Linux > project. > > I would please like to know more about the TW686X driver. In particular, when > running concurrency tests on the driver, it seems like there is no evidence > of interrupt handling/calling before tw686x_memcpy_dma_free(), which could be > problematic. Am I missing something? I would highly appreciate your > explanation for educational purposes. > Not necesarily, as the code explains: /* * We can call this even when alloc_dma failed for the given channel */ static void tw686x_memcpy_dma_free(struct tw686x_video_channel *vc, unsigned int pb) Are you having any specific issue ? Thanks, Ezequiel
Re: Question about TW686X driver
On Tue, 23 Jul 2019 at 12:02, Mark Balançian wrote: > > I see. I guess then my issue would be help in seeing how > tw686x_memcpy_dma_free alone does any required interrupt handling, since > there are also functions tw686x_irq and tw686x_audio_irq for interrupt > handling as well? However, in my analysis, they were called after > tw686x_memcpy_dma_free. > What are you trying to do? and what is exactly not working? PS: Don't drop linux-media from the Cc list, and please don't top-post. Thanks, Eze
tw686x driver (continued)
Hi Ezequiel, I don’t know what top-posting is and I had to delete the continuation as linux-media kept flagging my email as a virus, but I take it that it means I should write my email below the previous? Anyways, I’m working with a linux driver verification team to detect race conditions in the kernel. Using our tool, we detected a possible race condition with the tw686x driver. Even if there’s the slightest thing I’d like to please patch it as I really need this for my enrolled program. In any case, if interrupt handing isn’t given dedicated functions that are called before tw686x_memcpy_dma_free, I wouldn’t mind writing them and including them in a patch. Thank you, Mark
Re: MyGica T230 dvb-t2 data corruption since commit 5fa8815
Hi Jan,
My initial testing of your two patches to move the T230 to the dvbsky
module looks good so far.
I'm testing on an 8th Gen NUC (8i3BEH) 16GB RAM, 2 x MyGica T230 T2
USB tuners, and 2 x DVBSky S960 S2 tuners.
This machine is running Debian stretch with the Debian 4.19.37
backport kernel (incl. your two patches to move the T230 to the dvbsky
module).
I have a test script that performs 200x consecutive tvheadend network scans...
This was executed against the UK Freeview network (6 muxes) =~1,200
tuning requests. This took a couple of hours, but not a single
checksum error.
I moved onto streaming various channels and didn't have any problems
so far. I only noted a couple of minor picture disturbances
(continuity counter errors) when i tried to record two HD channels
whilst watching a 3rd on the same mux. I'm not sure whether this was
pushing things too far, and would like to carry out similar tests on a
known working 4.9.x kernel.
I'll do more testing over the next couple of weeks and report back.
Also adding Thomas who has the same issue with the T230 tuner and
bisected to issue to the same problematic commit as me.
Regards,
James.
On Mon, 22 Jul 2019 at 17:22, Jan Pieter van Woerkom wrote:
>
> remove t230 from cxusb
>
> Signed-off-by: Jan Pieter van Woerkom
> ---
> diff -ru a/drivers/media/usb/dvb-usb/cxusb.c
> b/drivers/media/usb/dvb-usb/cxusb.c
> --- a/drivers/media/usb/dvb-usb/cxusb.c 2019-07-08 00:41:56.0 +0200
> +++ b/drivers/media/usb/dvb-usb/cxusb.c 2019-07-22 17:34:51.550698820 +0200
> @@ -369,26 +369,6 @@
> return 0;
> }
>
> -static int cxusb_read_status(struct dvb_frontend *fe,
> - enum fe_status *status)
> -{
> - struct dvb_usb_adapter *adap = (struct dvb_usb_adapter
> *)fe->dvb->priv;
> - struct cxusb_state *state = (struct cxusb_state *)adap->dev->priv;
> - int ret;
> -
> - ret = state->fe_read_status(fe, status);
> -
> - /* it need resync slave fifo when signal change from unlock to lock.*/
> - if ((*status & FE_HAS_LOCK) && (!state->last_lock)) {
> - mutex_lock(&state->stream_mutex);
> - cxusb_streaming_ctrl(adap, 1);
> - mutex_unlock(&state->stream_mutex);
> - }
> -
> - state->last_lock = (*status & FE_HAS_LOCK) ? 1 : 0;
> - return ret;
> -}
> -
> static void cxusb_d680_dmb_drain_message(struct dvb_usb_device *d)
> {
> int ep = d->props.generic_bulk_ctrl_endpoint;
> @@ -1164,83 +1144,6 @@
> return 0;
> }
>
> -static int cxusb_mygica_t230_frontend_attach(struct dvb_usb_adapter *adap)
> -{
> - struct dvb_usb_device *d = adap->dev;
> - struct cxusb_state *st = d->priv;
> - struct i2c_adapter *adapter;
> - struct i2c_client *client_demod;
> - struct i2c_client *client_tuner;
> - struct i2c_board_info info;
> - struct si2168_config si2168_config;
> - struct si2157_config si2157_config;
> -
> - /* Select required USB configuration */
> - if (usb_set_interface(d->udev, 0, 0) < 0)
> - err("set interface failed");
> -
> - /* Unblock all USB pipes */
> - usb_clear_halt(d->udev,
> - usb_sndbulkpipe(d->udev,
> d->props.generic_bulk_ctrl_endpoint));
> - usb_clear_halt(d->udev,
> - usb_rcvbulkpipe(d->udev,
> d->props.generic_bulk_ctrl_endpoint));
> - usb_clear_halt(d->udev,
> - usb_rcvbulkpipe(d->udev,
> d->props.adapter[0].fe[0].stream.endpoint));
> -
> - /* attach frontend */
> - si2168_config.i2c_adapter = &adapter;
> - si2168_config.fe = &adap->fe_adap[0].fe;
> - si2168_config.ts_mode = SI2168_TS_PARALLEL;
> - si2168_config.ts_clock_inv = 1;
> - memset(&info, 0, sizeof(struct i2c_board_info));
> - strscpy(info.type, "si2168", I2C_NAME_SIZE);
> - info.addr = 0x64;
> - info.platform_data = &si2168_config;
> - request_module(info.type);
> - client_demod = i2c_new_device(&d->i2c_adap, &info);
> - if (client_demod == NULL || client_demod->dev.driver == NULL)
> - return -ENODEV;
> -
> - if (!try_module_get(client_demod->dev.driver->owner)) {
> - i2c_unregister_device(client_demod);
> - return -ENODEV;
> - }
> -
> - st->i2c_client_demod = client_demod;
> -
> - /* attach tuner */
> - memset(&si2157_config, 0, sizeof(si2157_config));
> - si2157_config.fe = adap->fe_adap[0].fe;
> - si2157_config.if_port = 1;
> - memset(&info, 0, sizeof(struct i2c_board_info));
> - strscpy(info.type, "si2157", I2C_NAME_SIZE);
> - info.addr = 0x60;
> - info.platform_data = &si2157_config;
> - request_module(info.type);
> - client_tuner = i2c_new_device(adapter, &info);
> - if (client_tuner == NULL || client_tuner->dev.driver == NULL) {
> - module_put(client_demod->dev.driver->owner);
> -
[PATCH] media: rc: imon: Allow iMON RC protocol for ffdc 7e device
Allow selecting the IR protocol, MCE or iMON, for a device that identifies as follows (with config id 0x7e): 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller As the driver is structured to default to iMON when both RC protocols are supported, existing users of this device (using MCE protocol) will need to manually switch to MCE (RC-6) protocol from userspace (with ir-keytable, sysfs). Signed-off-by: Darius Rad --- The hardware I have (described in the commit) only supports the iMON protocol; whereas the driver only supports the MCE protocol. The unfortunate side effect of this change is that the default setting will cause problems for existing users. Allowing a different default protocol for this device will take more invasive changes. If it will help this patch be accepted, I can propose such changes. drivers/media/rc/imon.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c index 7bee72108b0e..37a850421fbb 100644 --- a/drivers/media/rc/imon.c +++ b/drivers/media/rc/imon.c @@ -1826,12 +1826,17 @@ static void imon_get_ffdc_type(struct imon_context *ictx) break; /* iMON VFD, MCE IR */ case 0x46: - case 0x7e: case 0x9e: dev_info(ictx->dev, "0xffdc iMON VFD, MCE IR"); detected_display_type = IMON_DISPLAY_TYPE_VFD; allowed_protos = RC_PROTO_BIT_RC6_MCE; break; + /* iMON VFD, iMON or MCE IR */ + case 0x7e: + dev_info(ictx->dev, "0xffdc iMON VFD, iMON or MCE IR"); + detected_display_type = IMON_DISPLAY_TYPE_VFD; + allowed_protos |= RC_PROTO_BIT_RC6_MCE; + break; /* iMON LCD, MCE IR */ case 0x9f: dev_info(ictx->dev, "0xffdc iMON LCD, MCE IR"); -- 2.20.1
[PATCH v1] media: v4l2-fwnode: Switch to use fwnode_property_count_uXX()
Use use fwnode_property_count_uXX() directly, that makes code neater.
Signed-off-by: Andy Shevchenko
---
drivers/media/v4l2-core/v4l2-fwnode.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c
b/drivers/media/v4l2-core/v4l2-fwnode.c
index 7e740d332a54..0262f419638d 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -163,7 +163,7 @@ static int v4l2_fwnode_endpoint_parse_csi2_bus(struct
fwnode_handle *fwnode,
pr_debug("no lane mapping given, using defaults\n");
}
- rval = fwnode_property_read_u32_array(fwnode, "data-lanes", NULL, 0);
+ rval = fwnode_property_count_u32(fwnode, "data-lanes");
if (rval > 0) {
num_data_lanes =
min_t(int, V4L2_FWNODE_CSI2_MAX_DATA_LANES, rval);
@@ -191,8 +191,7 @@ static int v4l2_fwnode_endpoint_parse_csi2_bus(struct
fwnode_handle *fwnode,
pr_debug("lane %u position %u\n", i, array[i]);
}
- rval = fwnode_property_read_u32_array(fwnode, "lane-polarities", NULL,
- 0);
+ rval = fwnode_property_count_u32(fwnode, "lane-polarities");
if (rval > 0) {
if (rval != 1 + num_data_lanes /* clock+data */) {
pr_warn("invalid number of lane-polarities entries
(need %u, got %u)\n",
--
2.20.1
[PATCH v2] media: v4l2-fwnode: Switch to use fwnode_property_count_uXX()
Use fwnode_property_count_uXX() directly, that makes code neater.
Signed-off-by: Andy Shevchenko
---
- drop double 'use' in the commit message
- add conversion for u64 array
drivers/media/v4l2-core/v4l2-fwnode.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c
b/drivers/media/v4l2-core/v4l2-fwnode.c
index 7e740d332a54..6972c5af25c6 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -163,7 +163,7 @@ static int v4l2_fwnode_endpoint_parse_csi2_bus(struct
fwnode_handle *fwnode,
pr_debug("no lane mapping given, using defaults\n");
}
- rval = fwnode_property_read_u32_array(fwnode, "data-lanes", NULL, 0);
+ rval = fwnode_property_count_u32(fwnode, "data-lanes");
if (rval > 0) {
num_data_lanes =
min_t(int, V4L2_FWNODE_CSI2_MAX_DATA_LANES, rval);
@@ -191,8 +191,7 @@ static int v4l2_fwnode_endpoint_parse_csi2_bus(struct
fwnode_handle *fwnode,
pr_debug("lane %u position %u\n", i, array[i]);
}
- rval = fwnode_property_read_u32_array(fwnode, "lane-polarities", NULL,
- 0);
+ rval = fwnode_property_count_u32(fwnode, "lane-polarities");
if (rval > 0) {
if (rval != 1 + num_data_lanes /* clock+data */) {
pr_warn("invalid number of lane-polarities entries
(need %u, got %u)\n",
@@ -525,8 +524,7 @@ int v4l2_fwnode_endpoint_alloc_parse(struct fwnode_handle
*fwnode,
if (rval < 0)
return rval;
- rval = fwnode_property_read_u64_array(fwnode, "link-frequencies",
- NULL, 0);
+ rval = fwnode_property_count_u64(fwnode, "link-frequencies");
if (rval > 0) {
unsigned int i;
--
2.20.1
Re: tw686x driver (continued)
On Tue, 23 Jul 2019 at 12:55, Mark Balançian wrote: > > On Jul 23, 2019, at 8:17 AM, Ezequiel Garcia > wrote: > > > On Tue, 23 Jul 2019 at 12:02, Mark Balançian wrote: > > > I see. I guess then my issue would be help in seeing how > tw686x_memcpy_dma_free alone does any required interrupt handling, since > there are also functions tw686x_irq and tw686x_audio_irq for interrupt > handling as well? However, in my analysis, they were called after > tw686x_memcpy_dma_free. > > > What are you trying to do? and what is exactly not working? > > PS: Don't drop linux-media from the Cc list, and please don't top-post. > > Thanks, > Eze > > > I don’t know what top-posting is, but I take it that it means I should write > my email below the previous? Anyways, I’m working with a linux driver > verification team to detect race conditions in the kernel. Using our tool, we > detected a possible race condition with the tw686x driver. Can you describe how is this race condition possible ? E.g. what are the possible code paths and what would be the problem? Also, is the tool open source? > Even if there’s the slightest thing I’d like to please patch it as I really > need this for my enrolled program. > Sure, if there's anything to patch, let's patch it! > In any case, if interrupt handing isn’t given dedicated functions that are > called before tw686x_memcpy_dma_free, I wouldn’t mind writing them and > including them in a patch. > I can't understand what you mean. Can you describe what is the issue you are seeing in the driver? Thanks, Ezequiel
Re: [PATCH 2/2] media: i2c: dw9768: Add DW9768 VCM driver
On 7/8/19 6:06 PM, dongchun@mediatek.com wrote:
> From: Dongchun Zhu
>
> This patch adds a V4L2 sub-device driver for DW9768 lens voice coil,
> and provides control to set the desired focus.
>
> The DW9807 is a 10 bit DAC from Dongwoon, designed for linear
> control of voice coil motor.
>
> Signed-off-by: Dongchun Zhu
> ---
> MAINTAINERS| 1 +
> drivers/media/i2c/Kconfig | 10 +
> drivers/media/i2c/Makefile | 1 +
> drivers/media/i2c/dw9768.c | 458
> +
> 4 files changed, 470 insertions(+)
> create mode 100644 drivers/media/i2c/dw9768.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8f6ac93..17152d7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4877,6 +4877,7 @@ M: Dongchun Zhu
> L: linux-media@vger.kernel.org
> T: git git://linuxtv.org/media_tree.git
> S: Maintained
> +F: drivers/media/i2c/dw9768.c
> F: Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.txt
>
> DONGWOON DW9807 LENS VOICE COIL DRIVER
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 7793358..8ff6c95 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -1014,6 +1014,16 @@ config VIDEO_DW9714
> capability. This is designed for linear control of
> voice coil motors, controlled via I2C serial interface.
>
> +config VIDEO_DW9768
> + tristate "DW9768 lens voice coil support"
> + depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
> + depends on VIDEO_V4L2_SUBDEV_API
> + help
> + This is a driver for the DW9768 camera lens voice coil.
> + DW9768 is a 10 bit DAC with 100mA output current sink
> + capability. This is designed for linear control of
> + voice coil motors, controlled via I2C serial interface.
> +
> config VIDEO_DW9807_VCM
> tristate "DW9807 lens voice coil support"
> depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index d8ad9da..944fbf6 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
> obj-$(CONFIG_VIDEO_AD5820) += ad5820.o
> obj-$(CONFIG_VIDEO_AK7375) += ak7375.o
> obj-$(CONFIG_VIDEO_DW9714) += dw9714.o
> +obj-$(CONFIG_VIDEO_DW9768) += dw9768.o
> obj-$(CONFIG_VIDEO_DW9807_VCM) += dw9807-vcm.o
> obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
> obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
> diff --git a/drivers/media/i2c/dw9768.c b/drivers/media/i2c/dw9768.c
> new file mode 100644
> index 000..f5b5591
> --- /dev/null
> +++ b/drivers/media/i2c/dw9768.c
> @@ -0,0 +1,458 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 MediaTek Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DW9768_VOLTAGE_ANALOG280
> +#define DW9768_NAME "dw9768"
> +#define DW9768_MAX_FOCUS_POS 1023
> +/*
> + * This sets the minimum granularity for the focus positions.
> + * A value of 1 gives maximum accuracy for a desired focus position
> + */
> +#define DW9768_FOCUS_STEPS 1
> +
> +#define DW9768_CTRL_DELAY_US 5000
> +
> +#define DW9768_REG_DAC_MSB 0x03
> +#define DW9768_REG_DAC_LSB 0x04
> +#define DW9768_REG_NULL 0xff
> +
> +#define DW9768_DAC_SHIFT 8
> +
> +#define DW9768_REG_VALUE_16BIT 2
> +
> +/* dw9768 device structure */
> +struct dw9768_device {
> + struct v4l2_ctrl_handler ctrls;
> + struct v4l2_subdev sd;
> + struct regulator *analog_regulator;
> + /*
> + * Serialize control access, get/set format, get selection
> + * and start streaming.
> + */
> + struct mutex power_lock;
> +
> + int power_count;
> + bool standby;
> +};
> +
> +static inline struct dw9768_device *to_dw9768_vcm(struct v4l2_ctrl *ctrl)
> +{
> + return container_of(ctrl->handler, struct dw9768_device, ctrls);
> +}
> +
> +static inline struct dw9768_device *sd_to_dw9768_vcm(struct v4l2_subdev
> *subdev)
> +{
> + return container_of(subdev, struct dw9768_device, sd);
> +}
> +
> +static int dw9768_i2c_write(struct dw9768_device *dw9768_dev, u8 *data,
> + int size)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(&dw9768_dev->sd);
> + struct i2c_msg msg;
> + u8 *w_buf = NULL;
> + u8 retry_cnt = 3;
> + int ret;
> +
> + if (!client->adapter)
> + return -ENODEV;
> +
> + if (size != 1 && size != 2)
> + return -EINVAL;
> +
> + memset(&msg, 0, sizeof(struct i2c_msg));
> +
> + w_buf = kzalloc(size, GFP_KERNEL);
> + if (!w_buf)
> + return -1;
return -ENOMEM;
> +
> + memcpy(w_buf, data, size);
> +
> + msg.addr = cl
Re: [PATCH v3 3/3] media: uapi: h264: Get rid of the p0/b0/b1 ref-lists
Hi Boris, On Wed, Jul 3, 2019 at 9:28 PM Boris Brezillon wrote: > > Those lists can be extracted from the dpb, let's simplify userspace > life and build that list kernel-side (generic helpers will be provided > for drivers that need this list). > > Signed-off-by: Boris Brezillon > --- > Changes in v3: > * None > > Changes in v2: > * None > --- > Documentation/media/uapi/v4l/ext-ctrls-codec.rst | 9 - > 1 file changed, 9 deletions(-) > > diff --git a/Documentation/media/uapi/v4l/ext-ctrls-codec.rst > b/Documentation/media/uapi/v4l/ext-ctrls-codec.rst > index 47ba2d057a92..237c8e8e6bca 100644 > --- a/Documentation/media/uapi/v4l/ext-ctrls-codec.rst > +++ b/Documentation/media/uapi/v4l/ext-ctrls-codec.rst > @@ -1946,15 +1946,6 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - > * - __u16 >- ``nal_ref_idc`` >- NAL reference ID value coming from the NAL Unit header > -* - __u8 > - - ``ref_pic_list_p0[32]`` > - - Backward reference list used by P-frames in the original bitstream > order > -* - __u8 > - - ``ref_pic_list_b0[32]`` > - - Backward reference list used by B-frames in the original bitstream > order > -* - __u8 > - - ``ref_pic_list_b1[32]`` > - - Forward reference list used by B-frames in the original bitstream > order > * - __s32 >- ``top_field_order_cnt`` >- Picture Order Count for the coded top field Thanks for the patch. Don't we also need to remove these fields from the UAPI structs? Best regards, Tomasz
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Jul 24 05:00:10 CEST 2019 media-tree git hash:ebe15c7679680308268b99d911b1db15d514c7b8 media_build git hash: c5884d3b03606ebdbf64417fcdfd274cbcc0b4e4 v4l-utils git hash: 6b63111c71eb2837195962d510c510b83c3821f0 edid-decode git hash: 15df4aebf06da579241c58949493b866139d0e2b gcc version:i686-linux-gcc (GCC) 8.3.0 sparse repo:https://git.linuxtv.org/mchehab/sparse.git sparse version: 0.6.1-rc1 smatch repo:https://git.linuxtv.org/mchehab/smatch.git smatch version: 0.5.1 build-scripts repo: https://git.linuxtv.org/hverkuil/build-scripts.git build-scripts git hash: d35a612cf09e3c21da849f4bfcd894d91ffa00b3 host hardware: x86_64 host os:4.19.0-4-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK Check for strcpy/strncpy/strlcpy: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: OK linux-3.11.10-x86_64: OK linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.63-i686: OK linux-3.16.63-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.136-i686: OK linux-3.18.136-x86_64: OK linux-3.19.8-i686: OK linux-3.19.8-x86_64: OK linux-4.0.9-i686: OK linux-4.0.9-x86_64: OK linux-4.1.52-i686: OK linux-4.1.52-x86_64: OK linux-4.2.8-i686: OK linux-4.2.8-x86_64: OK linux-4.3.6-i686: OK linux-4.3.6-x86_64: OK linux-4.4.167-i686: OK linux-4.4.167-x86_64: OK linux-4.5.7-i686: OK linux-4.5.7-x86_64: OK linux-4.6.7-i686: OK linux-4.6.7-x86_64: OK linux-4.7.10-i686: OK linux-4.7.10-x86_64: OK linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.162-i686: OK linux-4.9.162-x86_64: OK linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK linux-4.12.14-i686: OK linux-4.12.14-x86_64: OK linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.105-i686: OK linux-4.14.105-x86_64: OK linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.20-i686: OK linux-4.18.20-x86_64: OK linux-4.19.28-i686: OK linux-4.19.28-x86_64: OK linux-4.20.15-i686: OK linux-4.20.15-x86_64: OK linux-5.0.15-i686: OK linux-5.0.15-x86_64: OK linux-5.1.1-i686: OK linux-5.1.1-x86_64: OK linux-5.2.1-i686: OK linux-5.2.1-x86_64: OK linux-5.3-rc1-i686: WARNINGS linux-5.3-rc1-x86_64: WARNINGS apps: OK spec-git: OK virtme: OK: Final Summary: 2165, Succeeded: 2165, Failed: 0, Warnings: 0 sparse: OK smatch: OK Logs weren't copied as they are too large (4292 kB) The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: [RFC PATCH 0/5] Add enum_fmt flag for coded formats with dynamic resolution switching
On Fri, Jul 19, 2019 at 5:41 PM Hans Verkuil wrote: > > On 7/19/19 4:45 AM, Tomasz Figa wrote: > > On Mon, Jul 15, 2019 at 9:37 PM Hans Verkuil wrote: > >> > >> On 6/11/19 10:13 AM, Hans Verkuil wrote: > >>> On 6/9/19 4:38 PM, Maxime Jourdan wrote: > Hello, > > This RFC proposes a new format flag - V4L2_FMT_FLAG_DYN_RESOLUTION - used > to tag coded formats for which the device supports dynamic resolution > switching, via V4L2_EVENT_SOURCE_CHANGE. > This includes the initial "source change" where the device is able to > tell userspace about the coded resolution and the DPB size (which > sometimes translates to V4L2_CID_MIN_BUFFERS_FOR_CAPTURE). > >>> > >>> Shouldn't the initial source change still be there? The amlogic decoder > >>> is capable of determining the resolution of the stream, right? It just > >>> can't handle mid-stream changes. > >> > >> I've been thinking about this a bit more: there are three different HW > >> capabilities: > >> > >> 1) The hardware cannot parse the resolution at all and userspace has to > >> tell it > >> via S_FMT. > >> > >> 2) The hardware can parse the initial resolution, but is not able to handle > >> mid-stream resolution changes. > >> > >> 3) The hardware can parse the initial resolution and all following > >> mid-stream > >> resolution changes. > >> > >> We can consider 2 the default situation. > > > > Any particular reason for 2 being the default? I'm especially > > wondering about that as most of the drivers actually provide 3. > > Various reasons: > > 1) I prefer to have a flag indicating what IS supported rather than what >isn't. > 2) An application that checks this flag and doesn't see it (i.e. if a >flag-aware application is used with an older kernel where these flags >aren't set) will still work, but with possibly reduced functionality. >If the flag would indicate that something is NOT supported, then they >would fail when combined with an older kernel and a driver that doesn't >support dynamic resolution changes. > 3) None of the encoders support it, so there too it makes sense to have >'no dynamic resolution change' as the default. It's nicely symmetrical >for encoders and decoders. > 4) Some formats do not support it, so again, having no dynamic res changes >as the default makes sense. Okay, I think you convinced me, thanks! Feel free to add my Acked-by. Best regards, Tomasz
Re: [PATCH v3 3/3] media: uapi: h264: Get rid of the p0/b0/b1 ref-lists
On Wed, 24 Jul 2019 12:39:55 +0900 Tomasz Figa wrote: > Hi Boris, > > On Wed, Jul 3, 2019 at 9:28 PM Boris Brezillon > wrote: > > > > Those lists can be extracted from the dpb, let's simplify userspace > > life and build that list kernel-side (generic helpers will be provided > > for drivers that need this list). > > > > Signed-off-by: Boris Brezillon > > --- > > Changes in v3: > > * None > > > > Changes in v2: > > * None > > --- > > Documentation/media/uapi/v4l/ext-ctrls-codec.rst | 9 - > > 1 file changed, 9 deletions(-) > > > > diff --git a/Documentation/media/uapi/v4l/ext-ctrls-codec.rst > > b/Documentation/media/uapi/v4l/ext-ctrls-codec.rst > > index 47ba2d057a92..237c8e8e6bca 100644 > > --- a/Documentation/media/uapi/v4l/ext-ctrls-codec.rst > > +++ b/Documentation/media/uapi/v4l/ext-ctrls-codec.rst > > @@ -1946,15 +1946,6 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - > > * - __u16 > >- ``nal_ref_idc`` > >- NAL reference ID value coming from the NAL Unit header > > -* - __u8 > > - - ``ref_pic_list_p0[32]`` > > - - Backward reference list used by P-frames in the original bitstream > > order > > -* - __u8 > > - - ``ref_pic_list_b0[32]`` > > - - Backward reference list used by B-frames in the original bitstream > > order > > -* - __u8 > > - - ``ref_pic_list_b1[32]`` > > - - Forward reference list used by B-frames in the original bitstream > > order > > * - __s32 > >- ``top_field_order_cnt`` > >- Picture Order Count for the coded top field > > Thanks for the patch. > > Don't we also need to remove these fields from the UAPI structs? Oops, indeed. I'll drop them in the next version.
Great News: National Heart Center Singapore CT Coronary Calcium Score 18 July 2019
Subject: Great News: National Heart Center Singapore CT Coronary Calcium Score 18 July 2019 Good day from Singapore, This is good news for trillions and trillions of years to come! 1. My weight/mass is 123.5 kg (taken on 23 July 2019). 2. My height is 1.79 meters (taken on 23 July 2019). 3. My Body Mass Index (BMI) is 38.56 kg/m2 (as at 23 July 2019) 4. I have been living with random, intermittent, and chronic mild chest pain for the past 10 years since the year 2009. 5. I have seen countless (lost count) doctors in Singapore over the past 10 years. The diagnoses were always atypical chest pain (ie. nothing to do with the heart). All the doctors I have seen did not think it is angina pectoris. 6. I have done countless (lost count) cardiac tests in Singapore over the past 10 years, including electrocardiogram (ECG), treadmill stress test, MIBI heart perfusion test, and CT coronary angiogram. All the test results were either normal or perfect. 7. I have high cholesterol (hypercholesterolemia) for many years, according to doctors. 8. My pulse rate is consistently around 100 beats per minute for many years. 9. Recently, I went for CT coronary calcium scoring at National Heart Center Singapore (NHCS) on 18 July 2019. The following is a transcript of the CT coronary calcium scoring report obtained on 23 July 2019. -BEGIN NHCS CT Coronary Calcium Scoring Report 18 July 2019- National Heart Centre Singapore Patient Results Requested By: Chan Lihua Laura (Doctor) 23-Jul-2019 05:54 PM TURRITOPSIS DOHRNII TEO EN MING (ZHANG ENMING)Sex: M Age: 41yDOB: * MRN / Visit No.: * / H119042968E0003Locn: NHC-Cardiac Clinic B 18-Jul-2019 11:07 CT Coronary Calcium Scoring HCCT195011991718Final Additional Info Verified Date/Time: 18/07/2019 12:02 Final Verified Person: Dr. Narayan Lath Verified Section: NHC CT Performed at : National Heart Centre Singapore Level 5, 5D, 5 Hospital Drive Singapore 169609 CT Coronary Calcium Final Scoring HISTORY to reassess risk profile TECHNIQUE Calcium Scan was prospectively gated. Images were reconstructed at 3.0 mm slice thickness. Assessment was done using Vitrea Calcium software and Agatston scoring schema. REPORT Calcium Score: Agatston 0 , Volume score 0 mm3, LM 0 , RCA 0 , LAD 0 , LCX 0. The calcium score is between 0 th and 25 th percentile for [men between the ages of 40 and 44. Normal coronary origins. EXTRACARDIAC FINDINGS No incidental significant abnormalities in the included lungs or mediastinum. Report Indicator: Normal Finalised by:Narayan Lath, Senior Consultant, 12598I Finalised Date/Time: 18/07/2019 12:02 Report Link Final Printed from: National Heart Centre SingaporeEnd of Report Page: 1 of 1 -END NHCS CT Coronary Calcium Scoring Report 18 July 2019- For scanned image of the original CT coronary calcium scoring report from National Heart Center Singapore, please visit my RAID 1 mirroring redundant Blogger and Wordpress blogs at https://tdtemcerts.blogspot.sg https://tdtemcerts.wordpress.com On how to interpret CT Coronary Calcium Score, please visit the website of the Radiological Society of North America, Inc. (RSNA) at https://www.radiologyinfo.org/en/info.cfm?pg=ct_calscoring -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -END EMAIL SIGNATURE-
[PATCH v4l-utils] ir-ctl: show user how scancodes should be presented
Currently ir-ctl just says the scancode is invalid, which is not
very clear.
Signed-off-by: Sean Young
---
utils/common/ir-encode.c | 66
utils/common/ir-encode.h | 2 +-
utils/ir-ctl/ir-ctl.c| 10 ++
3 files changed, 56 insertions(+), 22 deletions(-)
diff --git a/utils/common/ir-encode.c b/utils/common/ir-encode.c
index 93c88501..47e294b1 100644
--- a/utils/common/ir-encode.c
+++ b/utils/common/ir-encode.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
@@ -427,22 +428,61 @@ unsigned protocol_scancode_mask(enum rc_proto proto)
return protocols[proto].scancode_mask;
}
-bool protocol_scancode_valid(enum rc_proto p, unsigned s)
+void protocol_scancode_valid(enum rc_proto *p, unsigned *s)
{
- if (s & ~protocols[p].scancode_mask)
- return false;
-
- if (p == RC_PROTO_NECX) {
- return (((s >> 16) ^ ~(s >> 8)) & 0xff) != 0;
- } else if (p == RC_PROTO_NEC32) {
- return (((s >> 24) ^ ~(s >> 16)) & 0xff) != 0;
- } else if (p == RC_PROTO_RC6_MCE) {
- return (s & 0x) == 0x800f;
- } else if (p == RC_PROTO_RC6_6A_32) {
- return (s & 0x) != 0x800f;
+ enum rc_proto p2 = *p;
+ unsigned s2 = *s;
+
+ // rc6_mce is rc6_6a_32 with vendor code 0x800f and
+ if (*p == RC_PROTO_RC6_MCE && (*s & 0x) != 0x800f) {
+ p2 = RC_PROTO_RC6_6A_32;
+ } else if (*p == RC_PROTO_RC6_6A_32 && (*s & 0x) == 0x800f)
{
+ p2 = RC_PROTO_RC6_MCE;
+ } else if (*p == RC_PROTO_NEC || *p == RC_PROTO_NECX || *p ==
RC_PROTO_NEC32) {
+ // nec scancodes may repeat the address and command
+ // in inverted form; the inverted values are not in the
+ // scancode.
+
+ // can 24 bit scancode be represented as 16 bit scancode
+ if (*s > 0x && *s <= 0x00ff) {
+ if *s >> 16) ^ ~(*s >> 8)) & 0xff) != 0) {
+ // is it necx
+ p2 = RC_PROTO_NECX;
+ } else {
+ // or regular nec
+ s2 = ((*s >> 8) & 0xff00) | (*s & 0x00ff);
+ p2 = RC_PROTO_NEC;
+ }
+ // can 32 bit scancode be represented as 24 or 16 bit scancode
+ } else if (*s > 0x00ff) {
+ if (*s >> 24) ^ ~(*s >> 16)) & 0xff) == 0) &&
+ *s >> 8) ^ ~(*s >> 0)) & 0xff) == 0)) {
+ // is it nec
+ s2 = ((*s >> 16) & 0xff00) |
+((*s >> 8) & 0x00ff);
+ p2 = RC_PROTO_NEC;
+ } else if (*s >> 24) ^ ~(*s >> 16)) & 0xff) != 0) &&
+ *s >> 8) ^ ~(*s >> 0)) & 0xff) == 0)) {
+ // is it nec-x
+ s2 = (*s >> 8) & 0xff;
+ p2 = RC_PROTO_NECX;
+ } else {
+ // or it has to be nec32
+ p2 = RC_PROTO_NEC32;
+ }
+ }
}
- return true;
+ s2 &= protocols[p2].scancode_mask;
+
+ if (*p != p2 || *s != s2) {
+ fprintf(stderr,
+ "warning: `%s:0x%x' will be decoded as `%s:0x%x'\n",
+ protocol_name(*p), *s, protocol_name(p2), s2);
+
+ *p = p2;
+ *s = s2;
+ }
}
bool protocol_encoder_available(enum rc_proto proto)
diff --git a/utils/common/ir-encode.h b/utils/common/ir-encode.h
index 7202c2d8..df595354 100644
--- a/utils/common/ir-encode.h
+++ b/utils/common/ir-encode.h
@@ -7,7 +7,7 @@
bool protocol_match(const char *name, enum rc_proto *proto);
unsigned protocol_carrier(enum rc_proto proto);
unsigned protocol_max_size(enum rc_proto proto);
-bool protocol_scancode_valid(enum rc_proto proto, unsigned scancode);
+void protocol_scancode_valid(enum rc_proto *proto, unsigned *scancode);
unsigned protocol_scancode_mask(enum rc_proto proto);
bool protocol_encoder_available(enum rc_proto proto);
unsigned protocol_encode(enum rc_proto proto, unsigned scancode, unsigned
*buf);
diff --git a/utils/ir-ctl/ir-ctl.c b/utils/ir-ctl/ir-ctl.c
index 03c2791d..82ac0dee 100644
--- a/utils/ir-ctl/ir-ctl.c
+++ b/utils/ir-ctl/ir-ctl.c
@@ -265,10 +265,7 @@ static struct file *read_file(struct arguments *args,
const char *fname)
return NULL;
}
- if (!protocol_scancode_valid(proto, scancode)) {
- fprintf(stderr, _("error: %s:%d: invalid
scancode '%s' for protocol '%s'\n"), fname,
