Re: kill off pci_enable_msi_{exact,range}
On Thu, Jan 12, 2017 at 03:29:00PM -0600, Bjorn Helgaas wrote: > Applied all three (with Tom's ack on the amd-xgbe patch) to pci/msi for > v4.11, thanks! Tom had just send me an event better version of the xgbe patch. Tom, maybe you can resend that relative to the PCI tree [1], so that we don't lose it for next merge window? [1] https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/3] media: rc: add support for IR receiver on MT7623 SoC
From: Sean Wang This patchset introduces consumer IR (CIR) support on MT7623 SoC that also works on other similar SoCs and implements raw mode for more compatibility with different protocols. The driver simply reports the duration of pulses and spaces to rc-core logic to decode. Changes since v1: - change compatible string from "mediatek,mt7623-ir" into "mediatek,mt7623-cir" - use KBUILD_MODNAME to provide consistent device name used in driver. - remove unused fields in struct mtk_ir. - use synchronize_irq to give protection between IRQ handler and remove handler. - use devm_rc_allocate_device based on Andi Shyti's work. - simplify error handling patch with devm_rc_register_device and devm_rc_allocate_device. - remove unused spinlock. - add comments about hardware limitation and related workarounds. - enhance the caculation of sampling period for easiler assigned specific value. - refine git description. - fix IR message handling between IR hardware and rc-core. Changes since v2: - remove extra rc_unregister_device to avoid double frees issue since rc_unregister_device was used. - enhance comments description - remove redundant mtk irq disable/enable pair inside the IRQ handler - move keymap table property document into a common place Sean Wang (3): Documentation: devicetree: move shared property used by rc into a common place Documentation: devicetree: Add document bindings for mtk-cir media: rc: add driver for IR remote receiver on MT7623 SoC .../devicetree/bindings/media/gpio-ir-receiver.txt | 3 +- .../devicetree/bindings/media/hix5hd2-ir.txt | 2 +- .../devicetree/bindings/media/mtk-cir.txt | 23 ++ Documentation/devicetree/bindings/media/rc.txt | 116 .../devicetree/bindings/media/sunxi-ir.txt | 2 +- drivers/media/rc/Kconfig | 11 + drivers/media/rc/Makefile | 1 + drivers/media/rc/mtk-cir.c | 330 + 8 files changed, 485 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt create mode 100644 Documentation/devicetree/bindings/media/rc.txt create mode 100644 drivers/media/rc/mtk-cir.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] media: rc: add driver for IR remote receiver on MT7623 SoC
From: Sean Wang
This patch adds driver for IR controller on MT7623 SoC.
and should also work on similar Mediatek SoC. Currently
testing successfully on NEC and SONY remote controller
only but it should work on others (lirc, rc-5 and rc-6).
Signed-off-by: Sean Wang
Reviewed-by: Sean Young
---
drivers/media/rc/Kconfig | 11 ++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/mtk-cir.c | 329 +
3 files changed, 341 insertions(+)
create mode 100644 drivers/media/rc/mtk-cir.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 629e8ca..9228479 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -235,6 +235,17 @@ config IR_MESON
To compile this driver as a module, choose M here: the
module will be called meson-ir.
+config IR_MTK
+ tristate "Mediatek IR remote receiver"
+ depends on RC_CORE
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ ---help---
+ Say Y if you want to use the IR remote receiver available
+ on Mediatek SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mtk-cir.
+
config IR_NUVOTON
tristate "Nuvoton w836x7hg Consumer Infrared Transceiver"
depends on PNP
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 3a984ee..a78570b 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_RC_ST) += st_rc.o
obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
obj-$(CONFIG_IR_IMG) += img-ir/
obj-$(CONFIG_IR_SERIAL) += serial_ir.o
+obj-$(CONFIG_IR_MTK) += mtk-cir.o
diff --git a/drivers/media/rc/mtk-cir.c b/drivers/media/rc/mtk-cir.c
new file mode 100644
index 000..fbe7fd9
--- /dev/null
+++ b/drivers/media/rc/mtk-cir.c
@@ -0,0 +1,329 @@
+/*
+ * Driver for Mediatek IR Receiver Controller
+ *
+ * Copyright (C) 2017 Sean Wang
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MTK_IR_DEV KBUILD_MODNAME
+
+/* Register to enable PWM and IR */
+#define MTK_CONFIG_HIGH_REG 0x0c
+/* Enable IR pulse width detection */
+#define MTK_PWM_EN BIT(13)
+/* Enable IR hardware function */
+#define MTK_IR_ENBIT(0)
+
+/* Register to setting sample period */
+#define MTK_CONFIG_LOW_REG0x10
+/* Field to set sample period */
+#define CHK_PERIOD DIV_ROUND_CLOSEST(MTK_IR_SAMPLE, \
+ MTK_IR_CLK_PERIOD)
+#define MTK_CHK_PERIOD(((CHK_PERIOD) << 8) & (GENMASK(20, 8)))
+#define MTK_CHK_PERIOD_MASK (GENMASK(20, 8))
+
+/* Register to clear state of state machine */
+#define MTK_IRCLR_REG 0x20
+/* Bit to restart IR receiving */
+#define MTK_IRCLRBIT(0)
+
+/* Register containing pulse width data */
+#define MTK_CHKDATA_REG(i)(0x88 + 4 * (i))
+#define MTK_WIDTH_MASK (GENMASK(7, 0))
+
+/* Register to enable IR interrupt */
+#define MTK_IRINT_EN_REG 0xcc
+/* Bit to enable interrupt */
+#define MTK_IRINT_EN BIT(0)
+
+/* Register to ack IR interrupt */
+#define MTK_IRINT_CLR_REG 0xd0
+/* Bit to clear interrupt status */
+#define MTK_IRINT_CLRBIT(0)
+
+/* Maximum count of samples */
+#define MTK_MAX_SAMPLES 0xff
+/* Indicate the end of IR message */
+#define MTK_IR_END(v, p) ((v) == MTK_MAX_SAMPLES && (p) == 0)
+/* Number of registers to record the pulse width */
+#define MTK_CHKDATA_SZ 17
+/* Source clock frequency */
+#define MTK_IR_BASE_CLK 27300
+/* Frequency after IR internal divider */
+#define MTK_IR_CLK_FREQ (MTK_IR_BASE_CLK / 4)
+/* Period for MTK_IR_CLK in ns*/
+#define MTK_IR_CLK_PERIODDIV_ROUND_CLOSEST(10ul, \
+ MTK_IR_CLK_FREQ)
+/* Sample period in ns */
+#define MTK_IR_SAMPLE(MTK_IR_CLK_PERIOD * 0xc00)
+
+/* struct mtk_ir - This is the main datasructure for holding the state
+ * of the driver
+ * @dev: The device pointer
+ * @rc:The rc instrance
+ * @irq: The IRQ that we are using
+ * @base: The mapped register i/o base
+ * @clk: The clock that we are using
+ */
+struct mtk_ir {
+ struct device *dev;
+ struct rc_dev *rc;
+ void __iome
[PATCH v3 1/3] Documentation: devicetree: move shared property used by rc into a common place
From: Sean Wang Most IR drivers uses the same label to identify the scancdoe/key table they used by multiple bindings and lack explanation well. So move the shared property into a common place and give better explanation. Signed-off-by: Sean Wang --- .../devicetree/bindings/media/gpio-ir-receiver.txt | 3 +- .../devicetree/bindings/media/hix5hd2-ir.txt | 2 +- Documentation/devicetree/bindings/media/rc.txt | 116 + .../devicetree/bindings/media/sunxi-ir.txt | 2 +- 4 files changed, 120 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/rc.txt diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt index 56e726e..58261fb 100644 --- a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt +++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt @@ -5,7 +5,8 @@ Required properties: - gpios: specifies GPIO used for IR signal reception. Optional properties: - - linux,rc-map-name: Linux specific remote control map name. + - linux,rc-map-name: see rc.txt file in the same + directory. Example node: diff --git a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt index 54e1bed..13ebc0f 100644 --- a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt +++ b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt @@ -10,7 +10,7 @@ Required properties: - clocks: clock phandle and specifier pair. Optional properties: - - linux,rc-map-name : Remote control map name. + - linux,rc-map-name: see rc.txt file in the same directory. - hisilicon,power-syscon: DEPRECATED. Don't use this in new dts files. Provide correct clocks instead. diff --git a/Documentation/devicetree/bindings/media/rc.txt b/Documentation/devicetree/bindings/media/rc.txt new file mode 100644 index 000..0d16d14 --- /dev/null +++ b/Documentation/devicetree/bindings/media/rc.txt @@ -0,0 +1,116 @@ +The following properties are common to the infrared remote controllers: + +- linux,rc-map-name: string, specifies the scancode/key mapping table + defined in-kernel for the remote controller. Support values are: + * "rc-adstech-dvb-t-pci" + * "rc-alink-dtu-m" + * "rc-anysee" + * "rc-apac-viewcomp" + * "rc-asus-pc39" + * "rc-asus-ps3-100" + * "rc-ati-tv-wonder-hd-600" + * "rc-ati-x10" + * "rc-avermedia-a16d" + * "rc-avermedia-cardbus" + * "rc-avermedia-dvbt" + * "rc-avermedia-m135a" + * "rc-avermedia-m733a-rm-k6" + * "rc-avermedia-rm-ks" + * "rc-avermedia" + * "rc-avertv-303" + * "rc-azurewave-ad-tu700" + * "rc-behold-columbus" + * "rc-behold" + * "rc-budget-ci-old" + * "rc-cec" + * "rc-cinergy-1400" + * "rc-cinergy" + * "rc-delock-61959" + * "rc-dib0700-nec" + * "rc-dib0700-rc5" + * "rc-digitalnow-tinytwin" + * "rc-digittrade" + * "rc-dm1105-nec" + * "rc-dntv-live-dvbt-pro" + * "rc-dntv-live-dvb-t" + * "rc-dtt200u" + * "rc-dvbsky" + * "rc-empty" + * "rc-em-terratec" + * "rc-encore-enltv2" + * "rc-encore-enltv-fm53" + * "rc-encore-enltv" + * "rc-evga-indtube" + * "rc-eztv" + * "rc-flydvb" + * "rc-flyvideo" + * "rc-fusionhdtv-mce" + * "rc-gadmei-rm008z" + * "rc-genius-tvgo-a11mce" + * "rc-gotview7135" + * "rc-hauppauge" + * "rc-imon-mce" + * "rc-imon-pad" + * "rc-iodata-bctv7e" + * "rc-it913x-v1" + * "rc-it913x-v2" + * "rc-kaiomy" + * "rc-kworld-315u" + * "rc-kworld-pc150u" + * "rc-kworld-plus-tv-analog" + * "rc-leadtek-y04g0051" + * "rc-lirc" + * "rc-lme2510" + * "rc-manli" + * "rc-medion-x10" + * "rc-medion-x10-digitainer" + * "rc-medion-x10-or2x" + * "rc-msi-digivox-ii" + * "rc-msi-digivox-iii" + * "rc-msi-tvanywhere-plus" + * "rc-msi-tvanywhere" + * "rc-nebula" + * "rc-nec-terratec-cinergy-xs" + * "rc-norwood" + * "rc-npgtech" + * "rc-pctv-sedna" + * "rc-pinnacle-color" + * "rc-pinnacle-grey" + * "rc-pinnacle-pctv-hd" + * "rc-pixelview-new" + * "rc-pixelview" + * "rc-pixelview-002t" + * "rc-pixelview-mk12" + * "rc-powercolor-real-angel" + * "rc-proteus-2309" + * "rc-purpletv" + * "rc-pv951" + * "rc-hauppauge" + * "rc-rc5-tv" + * "rc-rc6-mce" + * "rc-real-audio-220-32-keys" + * "rc-reddo" + * "rc-snapstream-firefly" + * "rc-streamzap" + * "rc-tbs-nec" + * "rc-technisat-ts35" + * "rc-technisat-usb2" + * "rc-terratec-cinergy-c-pci" + * "rc-terratec-cinergy-s2-hd" + * "rc-terratec-cinergy-xs" + * "rc-terratec-slim" + * "rc-terratec-slim-2" + * "rc-tevii-nec" + * "rc-tivo" + * "rc-total-media-in-hand" + * "rc-total-media-in-hand-02" + * "rc-trekstor" + * "rc-tt-1500" + * "rc-twinhan-dtv-cab-ci" + * "rc-twinhan1027" + * "rc-videomate-k100" + * "rc-videomate-s350" + * "rc-videomate-tv-pvr" + * "rc-winfast" + * "rc-winfast-usbii-deluxe" + * "rc-su3000" diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Document
[PATCH v3 2/3] Documentation: devicetree: Add document bindings for mtk-cir
From: Sean Wang
This patch adds documentation for devicetree bindings for
consumer Mediatek IR controller.
Signed-off-by: Sean Wang
---
.../devicetree/bindings/media/mtk-cir.txt | 24 ++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt
diff --git a/Documentation/devicetree/bindings/media/mtk-cir.txt
b/Documentation/devicetree/bindings/media/mtk-cir.txt
new file mode 100644
index 000..2be2005
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mtk-cir.txt
@@ -0,0 +1,24 @@
+Device-Tree bindings for Mediatek consumer IR controller
+found in Mediatek SoC family
+
+Required properties:
+- compatible : "mediatek,mt7623-cir"
+- clocks : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names : should contain "clk" entries;
+- interrupts : should contain IR IRQ number;
+- reg : should contain IO map address for IR.
+
+Optional properties:
+- linux,rc-map-name : see rc.txt file in the same directory.
+
+Example:
+
+cir: cir@10013000 {
+ compatible = "mediatek,mt7623-cir";
+ reg = <0 0x10013000 0 0x1000>;
+ interrupts = ;
+ clocks = <&infracfg CLK_INFRA_IRRX>;
+ clock-names = "clk";
+ linux,rc-map-name = "rc-rc6-mce";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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: Fri Jan 13 05:00:18 CET 2017 media-tree git hash:40eca140c404505c09773d1c6685d818cb55ab1a media_build git hash: 3c6ce4ff75f19adf45869e34b376c5b9dee4d50a v4l-utils git hash: aded25f433113e022adc375629c8e17eb3a5c64f gcc version:i686-linux-gcc (GCC) 6.2.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.8.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: OK linux-3.12.67-i686: OK linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0.9-i686: WARNINGS linux-4.1.33-i686: WARNINGS linux-4.2.8-i686: WARNINGS linux-4.3.6-i686: WARNINGS linux-4.4.22-i686: WARNINGS linux-4.5.7-i686: WARNINGS linux-4.6.7-i686: WARNINGS linux-4.7.5-i686: WARNINGS linux-4.8-i686: OK linux-4.9-i686: OK linux-4.10-rc3-i686: OK linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: OK linux-3.12.67-x86_64: OK linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0.9-x86_64: WARNINGS linux-4.1.33-x86_64: WARNINGS linux-4.2.8-x86_64: WARNINGS linux-4.3.6-x86_64: WARNINGS linux-4.4.22-x86_64: WARNINGS linux-4.5.7-x86_64: WARNINGS linux-4.6.7-x86_64: WARNINGS linux-4.7.5-x86_64: WARNINGS linux-4.8-x86_64: OK linux-4.9-x86_64: OK linux-4.10-rc3-x86_64: OK apps: WARNINGS spec-git: ERRORS sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] media: video-i2c: add video-i2c driver
On Sun, Jan 8, 2017 at 9:33 PM, Marek Vasut wrote:
> On 01/09/2017 06:17 AM, Matt Ranostay wrote:
>> Gentle ping on this! :)
>
> Just some high-level feedback ... You should use regmap instead. Also,
> calling a driver which is specific to a particular sensor (amg88x) by
> generic name (video_i2c) is probably not a good idea.
There are likely going to variants, and other vendors that will have
parts as well. One example to note is the FLIR Lepton, and that may be
a good reason to use regmap in the future. Also Laurent suggested
the generic naming :)
>
>> Thanks,
>>
>> Matt
>>
>>> On Dec 23, 2016, at 19:04, Matt Ranostay wrote:
>>>
>>> There are several thermal sensors that only have a low-speed bus
>>> interface but output valid video data. This patchset enables support
>>> for the AMG88xx "Grid-Eye" sensor family.
>>>
>>> Cc: Attila Kinali
>>> Cc: Marek Vasut
>>> Cc: Luca Barbato
>>> Cc: Laurent Pinchart
>>> Signed-off-by: Matt Ranostay
>>> ---
>>> Changes from v1:
>>> * correct i2c_polling_remove() operations
>>> * fixed delay calcuation in buffer_queue()
>>> * add include linux/slab.h
>>>
>>> Changes from v2:
>>> * fix build error due to typo in include of slab.h
>>>
>>> Changes from v3:
>>> * switch data transport to a kthread to avoid to .buf_queue that can't sleep
>>> * change naming from i2c-polling to video-i2c
>>> * make the driver for single chipset under another uses the driver
>>>
>>> Changes from v4:
>>> * fix wraparound issue with jiffies and schedule_timeout_interruptible()
>>>
>>> drivers/media/i2c/Kconfig | 9 +
>>> drivers/media/i2c/Makefile| 1 +
>>> drivers/media/i2c/video-i2c.c | 569
>>> ++
>>> 3 files changed, 579 insertions(+)
>>> create mode 100644 drivers/media/i2c/video-i2c.c
>>>
>>> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
>>> index b31fa6fae009..ef84715293a9 100644
>>> --- a/drivers/media/i2c/Kconfig
>>> +++ b/drivers/media/i2c/Kconfig
>>> @@ -768,6 +768,15 @@ config VIDEO_M52790
>>>
>>> To compile this driver as a module, choose M here: the
>>> module will be called m52790.
>>> +
>>> +config VIDEO_I2C
>>> +tristate "I2C transport video support"
>>> +depends on VIDEO_V4L2 && I2C
>>> +select VIDEOBUF2_VMALLOC
>>> +---help---
>>> + Enable the I2C transport video support which supports the
>>> + following:
>>> + * Panasonic AMG88xx Grid-Eye Sensors
>>> endmenu
>>>
>>> menu "Sensors used on soc_camera driver"
>>> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
>>> index 92773b2e6225..7c8eeb213c3b 100644
>>> --- a/drivers/media/i2c/Makefile
>>> +++ b/drivers/media/i2c/Makefile
>>> @@ -79,6 +79,7 @@ obj-$(CONFIG_VIDEO_LM3646)+= lm3646.o
>>> obj-$(CONFIG_VIDEO_SMIAPP_PLL)+= smiapp-pll.o
>>> obj-$(CONFIG_VIDEO_AK881X)+= ak881x.o
>>> obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
>>> +obj-$(CONFIG_VIDEO_I2C)+= video-i2c.o
>>> obj-$(CONFIG_VIDEO_ML86V7667)+= ml86v7667.o
>>> obj-$(CONFIG_VIDEO_OV2659)+= ov2659.o
>>> obj-$(CONFIG_VIDEO_TC358743)+= tc358743.o
>>> diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
>>> new file mode 100644
>>> index ..9390560bd117
>>> --- /dev/null
>>> +++ b/drivers/media/i2c/video-i2c.c
>>> @@ -0,0 +1,569 @@
>>> +/*
>>> + * video-i2c.c - Support for I2C transport video devices
>>> + *
>>> + * Copyright (C) 2016 Matt Ranostay
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * Supported:
>>> + * - Panasonic AMG88xx Grid-Eye Sensors
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#define VIDEO_I2C_DRIVER"video-i2c"
>>> +#define MAX_BUFFER_SIZE128
>>> +
>>> +struct video_i2c_chip;
>>> +
>>> +struct video_i2c_buffer {
>>> +struct vb2_v4l2_buffer vb;
>>> +struct list_head list;
>>> +};
>>> +
>>> +struct video_i2c_data {
>>> +struct i2c_client *client;
>>> +const struct video_i2c_chip *chip;
>>> +struct mutex lock;
>>> +spinlock_t slock;
>>> +struct mutex queue_lock;
>>> +
>>> +struct v4l2_device v4l2_dev;
>>> +struct video_device vdev;
>>> +struct vb2_queue vb_vidq;
>>> +
>>> +struct task_struct *kthread_vid_cap;
>>> +struct list_head vid_cap_active;
>>> +};
>>> +
>>> +
Re: [PATCH v2 00/21] Basic i.MX IPUv3 capture support
On 01/12/2017 03:43 PM, Steve Longerbeam wrote: On 01/12/2017 03:22 PM, Steve Longerbeam wrote: and since my PRPVF entity roles up the VDIC internally, it is actually receiving from the VDIC channel. So unless you think we should have a distinct VDIC entity, I would like to keep this the way it is. Yes, I think VDIC should be separated out of PRPVF. What do you think about splitting the IC PRP into three parts? PRP could have one input pad connected to either CSI0, CSI1, or VDIC, and two output pads connected to PRPVF and PRPENC, respectively. This would even allow to have the PRP describe the downscale and PRPVF and PRPENC describe the bilinear upscale part of the IC. Actually, how about the following: PRP would have one input pad coming from CSI0, CSI1, or VDIC. But instead of another level of indirection with two more PRPENC and PRPVF entities, PRP would instead have two output pads, one for PRPVF output and one for PRPENC output. Both output pads could be activated if the input is connected to CSI0 or CSI1. And only the PRPVF output can be activated if the input is from VDIC. Actually that proved too difficult. I went with your original idea. Branch that implements this is imx-media-staging-md-prp. The media dot graph looks good but I have not tested yet. I'll start testing it tomorrow. Steve -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 7/7] uapi: export all headers under uapi directories
On Thu, Jan 12, 2017 at 05:32:09PM +0100, Nicolas Dichtel wrote: > What I was trying to say is that I export those directories like other are. > Removing those files is not related to that series. Perhaps the correct solution is to only copy files matching "*.h" to reduce the risk of copying files incidentally created by kbuild but which shouldn't be installed as uapi headers. jeff -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/21] Basic i.MX IPUv3 capture support
On 01/12/2017 03:22 PM, Steve Longerbeam wrote: and since my PRPVF entity roles up the VDIC internally, it is actually receiving from the VDIC channel. So unless you think we should have a distinct VDIC entity, I would like to keep this the way it is. Yes, I think VDIC should be separated out of PRPVF. What do you think about splitting the IC PRP into three parts? PRP could have one input pad connected to either CSI0, CSI1, or VDIC, and two output pads connected to PRPVF and PRPENC, respectively. This would even allow to have the PRP describe the downscale and PRPVF and PRPENC describe the bilinear upscale part of the IC. Actually, how about the following: PRP would have one input pad coming from CSI0, CSI1, or VDIC. But instead of another level of indirection with two more PRPENC and PRPVF entities, PRP would instead have two output pads, one for PRPVF output and one for PRPENC output. Both output pads could be activated if the input is connected to CSI0 or CSI1. And only the PRPVF output can be activated if the input is from VDIC. Steve -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/24] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
On 01/12/2017 11:37 AM, Tim Harvey wrote:
On Fri, Jan 6, 2017 at 6:11 PM, Steve Longerbeam wrote:
Add pinctrl groups for both GPT input capture channels.
Signed-off-by: Steve Longerbeam
---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 967c3b8..495709f 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -457,6 +457,18 @@
>;
};
+ pinctrl_gpt_input_capture0: gptinputcapture0grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT0__GPT_CAPTURE1 0x1b0b0
+ >;
+ };
+
+ pinctrl_gpt_input_capture1: gptinputcapture1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT1__GPT_CAPTURE2 0x1b0b0
+ >;
+ };
+
pinctrl_spdif: spdifgrp {
fsl,pins = <
MX6QDL_PAD_KEY_COL3__SPDIF_IN 0x1b0b0
--
Steve,
These are not used anywhere.
Yes, maybe I should just remove this patch for now. I'm only keeping it
because eventually it will be needed to support i.MX6 input capture.
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/21] Basic i.MX IPUv3 capture support
Hi Philipp, JM, First, let me say that you both have convinced me that we need a VDIC entity. I've implemented that in the branch imx-media-staging-md-vdic. At this point it only implements the M/C de-interlacing function, not the plane Combiner. So it has only one input and one output pad. I would imagine it will need two additional inputs and another output to support the Combiner (two pads for each plane to be combined, and a combiner output pad). More below... On 01/11/2017 04:10 AM, Philipp Zabel wrote: Hi Steve, Am Dienstag, den 10.01.2017, 15:52 -0800 schrieb Steve Longerbeam: On 01/09/2017 04:15 PM, Steve Longerbeam wrote: Hi Philipp, On 01/09/2017 11:43 AM, Philipp Zabel wrote: One is the amount and organization of subdevices/media entities visible to userspace. The SMFCs should not be user controllable subdevices, but can be implicitly enabled when a CSI is directly linked to a camif. I agree the SMFC could be folded into the CSI, but I see at least one issue. I don't suggest to fold it into the CSI. The CSI should have one output pad that that can be connected either to the IC PRP input (CSIx_DATA_DEST=1) or to the IDMAC via SMFC (CSIx_DATA_DEST=2). Right, and CSI can connect to VDIC. I don't know if it is documented, but to route to VDIC, set CSIx_DATA_DEST=1, as if to IC PRP. Confusing, but it's as if the VDIC is somehow part of the IC. The SMFC should be considered part of the link between CSI and IDMAC. sure, I can agree with that. The IC PRP input pad should be connected to either the CSI0 output pad (CSI_SEL=0,IC_INPUT=0), the CSI1 output pad (CSI_SEL=1,IC_INPUT=0), or to the VDIC (IC_INPUT=1). correct. From the dot graph you'll see that the PRPVF entity can receive directly from the CSI, or indirectly via the SMFC. And that's one reason why I think representing the mem2mem paths as links in the media controller interface is questionable. The path "via SMFC" is not really a hardware connection between CSI -> SMFC -> IC PRP, but two completely separate paths: CSI -> SMFC -> IDMAC -> mem and mem -> IDMAC -> IC PRP with different IDMAC read/write channels. The only real connection is that one DMA the IC DMA transfers are triggered automatically by the frame synchronisation unit on every CSI frame. There is no way to convey to the user which links are real connections and which are just linked DMA write and read channels somewhere else. Is there even a reason for the user to switch between direct and via memory paths manually, or could this be inferred from other state (formats, active links)? a CSI -> VDIC link doesn't convey whether that is a direct link using the FSU, or whether it is via SMFC and memory buffers. If you'll recall, the VDIC has three motion modes: low, medium, and high. When VDIC receives directly from CSI, it can only operate in high motion mode (it processes a single field F(n-1) sent directly from the CSI using the FSU). The reference manual refers to this as "real time mode". The low and medium motion modes require processing all three fields F(n-1), F(n), and F(n+1). These fields must come from IDMAC channels 8, 9, and 10 respectively. So in order to support low and medium motion modes, there needs to be a pipeline where the VDIC receives F(n-1), F(n), and F(n+1) from memory buffers. How about this: we can do away with SMFC entities by having two output pads from the CSI: a "direct" output pad that can link to PRP and VDIC, and a "IDMAC via SMFC" output pad that links to the entities that require memory buffers (VDIC in low/medium motion mode, camif, and PP). Only one of those output pads can be active at a time. I'm not sure if that allowed by the media framework, do two source pads imply that the entity can activate both of those pads simultaneously, or is allowed that only one source pad of two or more can be activated at a time? It's not clear to me. Let me know if you agree with this proposal. Also I'm not convinced the 1:1 mapping of IC task to subdevices is the best choice. It is true that the three tasks can be enabled separately, but to my understanding, the PRP ENC and PRP VF tasks share a single input channel. Shouldn't this be a single PRP subdevice with one input and two (VF, ENC) outputs? Since the VDIC sends its motion compensated frames to the PRP VF task, I've created the PRPVF entity solely for motion compensated de-interlace support. I don't really see any other use for the PRPVF task except for motion compensated de-interlace. I suppose simultaneous scaling to two different resolutions without going through memory could be one interesting use case: ,--> VF --> IDMAC -> mem -> to display CSI -> IC PRP `--> ENC -> IDMAC -> mem -> to VPU Yes, that is one possibility. So really, the PRPVF entity is a combination of the VDIC and PRPVF subunits. I'd prefer to keep them separate, we could then use a deactivated VDIC -> IC PRP link to mark the VDIC as available to be used for its
Re: Enabling peer to peer device transactions for PCIe devices
On 11/01/17 09:54 PM, Stephen Bates wrote: > The iopmem patchset addressed all the use cases above and while it is not > an in kernel API it could have been modified to be one reasonably easily. > As Logan states the driver can then choose to pass the VMAs to user-space > in a manner that makes sense. Just to clarify: the iopmem patchset had one patch that allowed for slightly more flexible zone device mappings which ought to be useful for everyone. The other patch (which was iopmem proper) was more of an example of how the zone_device memory _could_ be exposed to userspace with "iopmem" hardware that looks similar to nvdimm hardware. Iopmem was not really useful, in itself, for NVMe devices and it was never expected to be useful for GPUs. Logan -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/24] i.MX Media Driver
Hi Tim,
On 01/12/2017 01:13 PM, Tim Harvey wrote:
Now that your driver is hooking into the current media framework, I'm
not at all clear on how to link and configure the media entities.
It's all documented at Documentation/media/v4l-drivers/imx.rst.
Follow the SabreAuto pipeline setup example.
ah yes... it helps to read your patches! You did a great job on the
documentation.
Regarding the The ipu1_csi0_mux/ipu2_csi1_mux entities which have 1
source and 2 sinks (which makes sense for a mux) how do you know which
sink pad you should use (in your adv7180 example you use the 2nd sink
pad vs the first)?
The adv7180 can only go to the parallel input pad (ipu1_csi0_mux:1
on quad). The other input pads select from the mipi csi-2 receiver virtual
channels.
Have you generated a dot graph? It makes it much easier to
visualize:
# media-ctl --print-dot > graph.dot
then on your host:
% dot -Tpng graph.dot > graph.png
As my hardware is the same as the SabreAuto except that my adv7180 is
on i2c-2@0x20 I follow your example from
Documentation/media/v4l-drivers/imx.rst:
# Setup links
media-ctl -l '"adv7180 2-0020":0 -> "ipu1_csi0_mux":1[1]'
media-ctl -l '"ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]'
media-ctl -l '"ipu1_csi0":1 -> "ipu1_smfc0":0[1]'
media-ctl -l '"ipu1_smfc0":1 -> "ipu1_ic_prpvf":0[1]'
media-ctl -l '"ipu1_ic_prpvf":1 -> "camif0":0[1]'
media-ctl -l '"camif0":1 -> "camif0 devnode":0[1]'
# Configure pads
media-ctl -V "\"adv7180 2-0020\":0 [fmt:UYVY2X8/720x480]"
media-ctl -V "\"ipu1_csi0_mux\":1 [fmt:UYVY2X8/720x480]"
media-ctl -V "\"ipu1_csi0_mux\":2 [fmt:UYVY2X8/720x480]"
media-ctl -V "\"ipu1_csi0\":0 [fmt:UYVY2X8/720x480]"
media-ctl -V "\"ipu1_csi0\":1 [fmt:UYVY2X8/720x480]"
media-ctl -V "\"ipu1_smfc0\":0 [fmt:UYVY2X8/720x480]"
media-ctl -V "\"ipu1_smfc0\":1 [fmt:UYVY2X8/720x480]"
media-ctl -V "\"ipu1_ic_prpvf\":0 [fmt:UYVY2X8/720x480]"
# pad field types for camif can be any format prpvf supports
export outputfmt="UYVY2X8/720x480"
media-ctl -V "\"ipu1_ic_prpvf\":1 [fmt:$outputfmt]"
media-ctl -V "\"camif0\":0 [fmt:$outputfmt]"
media-ctl -V "\"camif0\":1 [fmt:$outputfmt]"
# select AIN1
v4l2-ctl -d0 -i0
Video input set to 0 (ADV7180 Composite on Ain1: ok)
v4l2-ctl -d0 --set-fmt-video=width=720,height=480,pixelformat=UYVY
# capture a single raw frame
v4l2-ctl -d0 --stream-mmap --stream-to=/x.raw --stream-count=1
[ 2092.056394] camif0: pipeline_set_stream failed with -32
VIDIOC_STREAMON: failed: Broken pipe
Enabling debug in drivers/media/media-entity.c I see:
[ 38.870087] imx-media soc:media@0: link validation failed for
"ipu1_smfc0":1 -> "ipu1_ic_prpvf":0, error -32
Looking at ipu1_smfc0 and ipu1_ic_prpvf with media-ctl I see:
- entity 12: ipu1_ic_prpvf (2 pads, 8 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev3
pad0: Sink
[fmt:UYVY2X8/720x480 field:alternate]
<- "ipu1_csi0":1 []
<- "ipu1_csi1":1 []
<- "ipu1_smfc0":1 [ENABLED]
<- "ipu1_smfc1":1 []
pad1: Source
[fmt:UYVY2X8/720x480 field:none]
-> "camif0":0 [ENABLED]
-> "camif1":0 []
-> "ipu1_ic_pp0":0 []
-> "ipu1_ic_pp1":0 []
- entity 45: ipu1_smfc0 (2 pads, 5 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev14
pad0: Sink
[fmt:UYVY2X8/720x480]
<- "ipu1_csi0":1 [ENABLED]
pad1: Source
[fmt:UYVY2X8/720x480]
-> "ipu1_ic_prpvf":0 [ENABLED]
-> "ipu1_ic_pp0":0 []
-> "camif0":0 []
-> "camif1":0 []
Any ideas what is going wrong here? Seems like its perhaps a field
type mismatch.
Yes, exactly, you'll need to set the field types on every pad in your
pipeline.
Is my outputfmt incorrect perhaps? I likely have
misunderstood the pad type comments in your documentation.
Attached is an update doc (from branch imx-media-staging-md-v7 on my fork).
I recently upgraded my v4l-utils package and media-ctl now supports
specifying
the field type in the pad format strings. If you don't have the latest
v4l-utils, it's
fairly straightforward to cross-build.
Additionally I've found that on an IMX6S/IMX6DL we crash while
registering the media-ic subdev's:
Yep, I only have quad boards here so I haven't gotten around to
testing on S/DL.
But it looks like I forgot to clear out the csi subdev pointer array before
passing it to imx_media_of_parse(). I think that might explain the OOPS
above. Try this patch:
diff --git a/drivers/staging/media/imx/imx-media-dev.c
b/drivers/staging/media/imx/imx-media-dev.c
index 357654d..0cf2d61 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -379,7 +379,7 @@ static int imx_media_probe(struct platform_device *pdev)
{
Re: kill off pci_enable_msi_{exact,range}
On Mon, Jan 09, 2017 at 09:37:37PM +0100, Christoph Hellwig wrote: > I had hope that we could kill these old interfaces of for 4.10-rc, > but as of today Linus tree still has two users: > > (1) the cobalt media driver, for which I sent a patch long time ago, > it got missed in the merge window. > (2) the new xgbe driver was merged in 4.10-rc but used the old interfaces > anyway > > This series resend the patch for (1) and adds a new one for (2), as well > as having the final removal patch behind it. Maybe we should just queue > up all three together in the PCI tree for 4.11? Applied all three (with Tom's ack on the amd-xgbe patch) to pci/msi for v4.11, thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/24] i.MX Media Driver
On Wed, Jan 11, 2017 at 7:22 PM, Steve Longerbeam wrote: > Hi Tim, > > > On 01/11/2017 03:14 PM, Tim Harvey wrote: >> >> >> >> >> Hi Steve, >> >> I took a stab at testing this today on a gw51xx which has an adv7180 >> hooked up as follows: >> - i2c3@0x20 >> - 8bit data bus from DAT12 to DAT19, HSYNC, VSYNC, PIXCLK on CSI0 pads >> (CSI0_IPU1) >> - PWRDWN# on MX6QDL_PAD_CSI0_DATA_EN__GPIO5_IO20 >> - IRQ# on MX6QDL_PAD_CSI0_DAT5__GPIO5_IO23 >> - all three analog inputs available to off-board connector >> >> My patch to the imx6qdl-gw51xx dtsi is: > > > As long as you used the patch to imx6qdl-sabreauto.dtsti that adds > the adv7180 support as a guide, you should be ok here. yes - fairly straightforward > >> >> >> >> >> On an IMX6Q I'm getting the following when the adv7180 module loads: >> [ 12.862477] adv7180 2-0020: chip found @ 0x20 (21a8000.i2c) >> [ 12.907767] imx-media: Registered subdev adv7180 2-0020 >> [ 12.907793] imx-media soc:media@0: Entity type for entity adv7180 >> 2-0020 was not initialized! >> [ 12.907867] imx-media: imx_media_create_link: adv7180 2-0020:0 -> >> ipu1_csi0_mux:1 >> >> Is the warning that adv7180 was not initialized expected and or an issue? > > > Yeah it's still a bug in the adv7180 driver, needs fixing. > ok - ignoring >> >> Now that your driver is hooking into the current media framework, I'm >> not at all clear on how to link and configure the media entities. > > > It's all documented at Documentation/media/v4l-drivers/imx.rst. > Follow the SabreAuto pipeline setup example. > ah yes... it helps to read your patches! You did a great job on the documentation. Regarding the The ipu1_csi0_mux/ipu2_csi1_mux entities which have 1 source and 2 sinks (which makes sense for a mux) how do you know which sink pad you should use (in your adv7180 example you use the 2nd sink pad vs the first)? As my hardware is the same as the SabreAuto except that my adv7180 is on i2c-2@0x20 I follow your example from Documentation/media/v4l-drivers/imx.rst: # Setup links media-ctl -l '"adv7180 2-0020":0 -> "ipu1_csi0_mux":1[1]' media-ctl -l '"ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]' media-ctl -l '"ipu1_csi0":1 -> "ipu1_smfc0":0[1]' media-ctl -l '"ipu1_smfc0":1 -> "ipu1_ic_prpvf":0[1]' media-ctl -l '"ipu1_ic_prpvf":1 -> "camif0":0[1]' media-ctl -l '"camif0":1 -> "camif0 devnode":0[1]' # Configure pads media-ctl -V "\"adv7180 2-0020\":0 [fmt:UYVY2X8/720x480]" media-ctl -V "\"ipu1_csi0_mux\":1 [fmt:UYVY2X8/720x480]" media-ctl -V "\"ipu1_csi0_mux\":2 [fmt:UYVY2X8/720x480]" media-ctl -V "\"ipu1_csi0\":0 [fmt:UYVY2X8/720x480]" media-ctl -V "\"ipu1_csi0\":1 [fmt:UYVY2X8/720x480]" media-ctl -V "\"ipu1_smfc0\":0 [fmt:UYVY2X8/720x480]" media-ctl -V "\"ipu1_smfc0\":1 [fmt:UYVY2X8/720x480]" media-ctl -V "\"ipu1_ic_prpvf\":0 [fmt:UYVY2X8/720x480]" # pad field types for camif can be any format prpvf supports export outputfmt="UYVY2X8/720x480" media-ctl -V "\"ipu1_ic_prpvf\":1 [fmt:$outputfmt]" media-ctl -V "\"camif0\":0 [fmt:$outputfmt]" media-ctl -V "\"camif0\":1 [fmt:$outputfmt]" # select AIN1 v4l2-ctl -d0 -i0 Video input set to 0 (ADV7180 Composite on Ain1: ok) v4l2-ctl -d0 --set-fmt-video=width=720,height=480,pixelformat=UYVY # capture a single raw frame v4l2-ctl -d0 --stream-mmap --stream-to=/x.raw --stream-count=1 [ 2092.056394] camif0: pipeline_set_stream failed with -32 VIDIOC_STREAMON: failed: Broken pipe Enabling debug in drivers/media/media-entity.c I see: [ 38.870087] imx-media soc:media@0: link validation failed for "ipu1_smfc0":1 -> "ipu1_ic_prpvf":0, error -32 Looking at ipu1_smfc0 and ipu1_ic_prpvf with media-ctl I see: - entity 12: ipu1_ic_prpvf (2 pads, 8 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev3 pad0: Sink [fmt:UYVY2X8/720x480 field:alternate] <- "ipu1_csi0":1 [] <- "ipu1_csi1":1 [] <- "ipu1_smfc0":1 [ENABLED] <- "ipu1_smfc1":1 [] pad1: Source [fmt:UYVY2X8/720x480 field:none] -> "camif0":0 [ENABLED] -> "camif1":0 [] -> "ipu1_ic_pp0":0 [] -> "ipu1_ic_pp1":0 [] - entity 45: ipu1_smfc0 (2 pads, 5 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev14 pad0: Sink [fmt:UYVY2X8/720x480] <- "ipu1_csi0":1 [ENABLED] pad1: Source [fmt:UYVY2X8/720x480] -> "ipu1_ic_prpvf":0 [ENABLED] -> "ipu1_ic_pp0":0 [] -> "camif0":0 [] -> "camif1":0 [] Any ideas what is going wrong here? Seems like its perhaps a field type mismatch. Is my outputfmt incorrect perhaps? I likely have misunderstood the pad type comments in your documentation. > > >> >> >> >> >> Additionally I've found that on an IMX6S/IMX6DL we crash while >> registering the media-ic subdev's: > > Yep, I only have qua
Re: [PATCH v3 10/24] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
On Fri, Jan 6, 2017 at 6:11 PM, Steve Longerbeam wrote:
> Add pinctrl groups for both GPT input capture channels.
>
> Signed-off-by: Steve Longerbeam
> ---
> arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> index 967c3b8..495709f 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> @@ -457,6 +457,18 @@
> >;
> };
>
> + pinctrl_gpt_input_capture0: gptinputcapture0grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_DAT0__GPT_CAPTURE1
> 0x1b0b0
> + >;
> + };
> +
> + pinctrl_gpt_input_capture1: gptinputcapture1grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD1_DAT1__GPT_CAPTURE2
> 0x1b0b0
> + >;
> + };
> +
> pinctrl_spdif: spdifgrp {
> fsl,pins = <
> MX6QDL_PAD_KEY_COL3__SPDIF_IN 0x1b0b0
> --
Steve,
These are not used anywhere.
Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] Support for DW CSI-2 Host IPK
On 01/12/2017 06:43 PM, Ramiro Oliveira wrote:
> Hi Hans,
>
> Thank you for your feedback.
>
> On 1/11/2017 11:54 AM, Hans Verkuil wrote:
>> Hi Ramiro,
>>
>> See my review comments below:
>>
>> On 12/12/16 16:00, Ramiro Oliveira wrote:
>>> Add support for the DesignWare CSI-2 Host IP Prototyping Kit
>>>
>>> Signed-off-by: Ramiro Oliveira
>
> [snip]
>>> +
>>> +static int vid_dev_subdev_s_power(struct v4l2_subdev *sd, int on)
>>> +{
>>> +return 0;
>>> +}
>>
>> Just drop this empty function, shouldn't be needed.
>>
>
> When I start my system I'm hoping all the subdevs have s_power registered. If
> it
> doesn't exist should I change the way I handle it, or will the core handle it
> for me?
If it isn't provided, then it is just skipped. The general rule is that
you only provide these ops if they do something useful.
>
>>> +
>>> +static int vid_dev_subdev_registered(struct v4l2_subdev *sd)
>>> +{
>>> +struct video_device_dev *vid_dev = v4l2_get_subdevdata(sd);
>>> +struct vb2_queue *q = &vid_dev->vb_queue;
>>> +struct video_device *vfd = &vid_dev->ve.vdev;
>>> +int ret;
>>> +
>>> +memset(vfd, 0, sizeof(*vfd));
>>> +
>>> +strlcpy(vfd->name, VIDEO_DEVICE_NAME, sizeof(vfd->name));
>>> +
>>> +vfd->fops = &vid_dev_fops;
>>> +vfd->ioctl_ops = &vid_dev_ioctl_ops;
>>> +vfd->v4l2_dev = sd->v4l2_dev;
>>> +vfd->minor = -1;
>>> +vfd->release = video_device_release_empty;
>>> +vfd->queue = q;
>>> +
>>> +INIT_LIST_HEAD(&vid_dev->vidq.active);
>>> +init_waitqueue_head(&vid_dev->vidq.wq);
>>> +memset(q, 0, sizeof(*q));
>>> +q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>>> +q->io_modes = VB2_MMAP | VB2_USERPTR;
>>
>> Add VB2_DMABUF and VB2_READ.
>>
>
> I'll add them, but I'm not using them, is it standard procedure to add them
> all
> even if they aren't used?
You may not use them, but others might. And it doesn't cost anything to add
them.
>
>>> +q->ops = &vb2_video_qops;
>>> +q->mem_ops = &vb2_vmalloc_memops;
>>
>> Why is vmalloc used? Can't you use dma_contig or dma_sg and avoid having to
>> copy
>> the image data? That's a really bad design given the amount of video data
>> that
>> you have to copy.
>>
>
> When I started development, the arch I was using (ARC) didn't support
> dma_contig, so I was forced to use vmalloc.
>
> Since then things have changed and I'm already using dma_contig, however it
> wasn't included in this patch. I'll add it to the next patch.
Ah, good. If you are switching to dma_contig, then remove VB2_USERPTR.
VB2_DMABUF should be used instead.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] Support for DW CSI-2 Host IPK
Hi Hans,
Thank you for your feedback.
On 1/11/2017 11:54 AM, Hans Verkuil wrote:
> Hi Ramiro,
>
> See my review comments below:
>
> On 12/12/16 16:00, Ramiro Oliveira wrote:
>> Add support for the DesignWare CSI-2 Host IP Prototyping Kit
>>
>> Signed-off-by: Ramiro Oliveira
[snip]
>> +static int
>> +dw_mipi_csi_set_fmt(struct v4l2_subdev *sd, struct v4l2_subdev_pad_config
>> *cfg,
>> +struct v4l2_subdev_format *fmt)
>> +{
>> +struct mipi_csi_dev *dev = sd_to_mipi_csi_dev(sd);
>> +struct mipi_fmt const *dev_fmt;
>> +struct v4l2_mbus_framefmt *mf;
>> +unsigned int i = 0;
>> +const struct v4l2_bt_timings *bt_r = &v4l2_dv_timings_presets[0].bt;
>> +
>> +mf = __dw_mipi_csi_get_format(dev, cfg, fmt->which);
>> +
>> +dev_fmt = dw_mipi_csi_try_format(&fmt->format);
>> +if (dev_fmt) {
>> +*mf = fmt->format;
>> +if (fmt->which == V4L2_SUBDEV_FORMAT_ACTIVE)
>> +dev->fmt = dev_fmt;
>> +dw_mipi_csi_set_ipi_fmt(dev);
>> +}
>> +while (v4l2_dv_timings_presets[i].bt.width) {
>> +const struct v4l2_bt_timings *bt =
>> +&v4l2_dv_timings_presets[i].bt;
>> +if (mf->width == bt->width && mf->height == bt->width) {
>> +__dw_mipi_csi_fill_timings(dev, bt);
>> +return 0;
>> +}
>> +i++;
>> +}
>> +
>> +__dw_mipi_csi_fill_timings(dev, bt_r);
>
> This code is weird. The video source can be either from a sensor or from an
> HDMI input, right?
>
> But if it is from a sensor, then using v4l2_dv_timings_presets since that's
> for
> an HDMI input. Sensors will typically not follow these preset timings.
>
> For HDMI input I expect that this driver supports the s_dv_timings op and will
> just use the timings set there and override the width/height in
> v4l2_subdev_format.
>
> For sensors I am actually not quite certain how this is done. I've CC-ed
> Sakari
> since he'll know. But let us know first whether it is indeed the intention
> that
> this should also work with a sensor.
>
Actually the video source, at the moment, can only be from a sensor. I'm using
v4l2_dv_timings_presets as a reference since we usually use this setup with a
Test Equipment in which we can configure every parameter.
I'll wait for Sakari to answer, and change it to what he recommends.
>> +return 0;
>> +
>> +}
>> +
>> +static int
>> +dw_mipi_csi_get_fmt(struct v4l2_subdev *sd, struct v4l2_subdev_pad_config
>> *cfg,
>> +struct v4l2_subdev_format *fmt)
>> +{
>> +struct mipi_csi_dev *dev = sd_to_mipi_csi_dev(sd);
>> +struct v4l2_mbus_framefmt *mf;
>> +
>> +mf = __dw_mipi_csi_get_format(dev, cfg, fmt->which);
>> +if (!mf)
>> +return -EINVAL;
>> +
>> +mutex_lock(&dev->lock);
>> +fmt->format = *mf;
>> +mutex_unlock(&dev->lock);
>> +return 0;
>> +}
>> +
>> +static int
>> +dw_mipi_csi_s_power(struct v4l2_subdev *sd, int on)
>> +{
>> +struct mipi_csi_dev *dev = sd_to_mipi_csi_dev(sd);
>> +
>> +if (on) {
>> +dw_mipi_csi_hw_stdby(dev);
>> +dw_mipi_csi_start(dev);
>> +} else {
>> +dw_mipi_csi_mask_irq_power_off(dev);
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static int
>> +dw_mipi_csi_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
>> +{
>> +struct v4l2_mbus_framefmt *format =
>> +v4l2_subdev_get_try_format(sd, fh->pad, 0);
>> +
>> +format->colorspace = V4L2_COLORSPACE_SRGB;
>> +format->code = dw_mipi_csi_formats[0].code;
>> +format->width = MIN_WIDTH;
>> +format->height = MIN_HEIGHT;
>> +format->field = V4L2_FIELD_NONE;
>
> Don't do this. Instead implement the init_cfg pad op and initialize this
> there.
>
> You can then drop this function.
>
I'll do that.
>> +
>> +return 0;
>> +}
>> +
>> +static const struct v4l2_subdev_internal_ops dw_mipi_csi_sd_internal_ops = {
>> +.open = dw_mipi_csi_open,
>> +};
>> +
>> +static struct v4l2_subdev_core_ops dw_mipi_csi_core_ops = {
>> +.s_power = dw_mipi_csi_s_power,
>> +};
>> +
>> +static struct v4l2_subdev_pad_ops dw_mipi_csi_pad_ops = {
>> +.enum_mbus_code = dw_mipi_csi_enum_mbus_code,
>> +.get_fmt = dw_mipi_csi_get_fmt,
>> +.set_fmt = dw_mipi_csi_set_fmt,
>> +};
>> +
>> +static struct v4l2_subdev_ops dw_mipi_csi_subdev_ops = {
>> +.core = &dw_mipi_csi_core_ops,
>> +.pad = &dw_mipi_csi_pad_ops,
>> +};
>> +
>> +static irqreturn_t
>> +dw_mipi_csi_irq1(int irq, void *dev_id)
>> +{
>> +struct mipi_csi_dev *csi_dev = dev_id;
>> +u32 global_int_status, i_sts;
>> +unsigned long flags;
>> +struct device *dev = &csi_dev->pdev->dev;
>> +
>> +global_int_status = dw_mipi_csi_read(csi_dev, R_CSI2_INTERRUPT);
>> +spin_lock_irqsave(&csi_dev->slock, flags);
>> +
>> +if (global_int_status & CSI2_INT_PHY_FATAL) {
>> +i_sts = dw_mipi_csi_read(csi_dev, R_CSI2_INT_PHY_FATAL);
>> +dev_dbg_ratelimited(dev, "CSI INT PHY FATAL: %08X\n", i_sts);
>> +}
>> +
>> +i
Re: Enabling peer to peer device transactions for PCIe devices
On Thu, Jan 12, 2017 at 10:11:29AM -0500, Jerome Glisse wrote: > On Wed, Jan 11, 2017 at 10:54:39PM -0600, Stephen Bates wrote: > > > What we want is for RDMA, O_DIRECT, etc to just work with special VMAs > > > (ie. at least those backed with ZONE_DEVICE memory). Then > > > GPU/NVME/DAX/whatever drivers can just hand these VMAs to userspace > > > (using whatever interface is most appropriate) and userspace can do what > > > it pleases with them. This makes _so_ much sense and actually largely > > > already works today (as demonstrated by iopmem). > So i say let solve the IOMMU issue first and let everyone use it in their > own way with their device. I do not think we can share much more than > that. Solve it for the easy ZONE_DIRECT/etc case then. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 7/7] uapi: export all headers under uapi directories
On Thursday 2017-01-12 16:52, Nicolas Dichtel wrote: >Le 09/01/2017 à 13:56, Christoph Hellwig a écrit : >> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote: >>> Regularly, when a new header is created in include/uapi/, the developer >>> forgets to add it in the corresponding Kbuild file. This error is usually >>> detected after the release is out. >>> >>> In fact, all headers under uapi directories should be exported, thus it's >>> useless to have an exhaustive list. >>> >>> After this patch, the following files, which were not exported, are now >>> exported (with make headers_install_all): >> >> ... snip ... >> >>> linux/genwqe/.install >>> linux/genwqe/..install.cmd >>> linux/cifs/.install >>> linux/cifs/..install.cmd >> >> I'm pretty sure these should not be exported! >> >Those files are created in every directory: >$ find usr/include/ -name '\.\.install.cmd' | wc -l >71 That still does not mean they should be exported. Anything but headers (and directories as a skeleton structure) is maximally suspicious. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 7/7] uapi: export all headers under uapi directories
Le 12/01/2017 à 17:28, Jan Engelhardt a écrit : > On Thursday 2017-01-12 16:52, Nicolas Dichtel wrote: > >> Le 09/01/2017 à 13:56, Christoph Hellwig a écrit : >>> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote: Regularly, when a new header is created in include/uapi/, the developer forgets to add it in the corresponding Kbuild file. This error is usually detected after the release is out. In fact, all headers under uapi directories should be exported, thus it's useless to have an exhaustive list. After this patch, the following files, which were not exported, are now exported (with make headers_install_all): >>> >>> ... snip ... >>> linux/genwqe/.install linux/genwqe/..install.cmd linux/cifs/.install linux/cifs/..install.cmd >>> >>> I'm pretty sure these should not be exported! >>> >> Those files are created in every directory: >> $ find usr/include/ -name '\.\.install.cmd' | wc -l >> 71 > > That still does not mean they should be exported. > > Anything but headers (and directories as a skeleton structure) is maximally > suspicious. > What I was trying to say is that I export those directories like other are. Removing those files is not related to that series. Regards, Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 7/7] uapi: export all headers under uapi directories
Le 09/01/2017 à 13:56, Christoph Hellwig a écrit : > On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote: >> Regularly, when a new header is created in include/uapi/, the developer >> forgets to add it in the corresponding Kbuild file. This error is usually >> detected after the release is out. >> >> In fact, all headers under uapi directories should be exported, thus it's >> useless to have an exhaustive list. >> >> After this patch, the following files, which were not exported, are now >> exported (with make headers_install_all): > > ... snip ... > >> linux/genwqe/.install >> linux/genwqe/..install.cmd >> linux/cifs/.install >> linux/cifs/..install.cmd > > I'm pretty sure these should not be exported! > Those files are created in every directory: $ find usr/include/ -name '\.\.install.cmd' | wc -l 71 $ find usr/include/ -name '\.install' | wc -l 71 See also http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/scripts/Makefile.headersinst#n32 Thank you, Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -next] gp8psk: make local symbol gp8psk_fe_ops static
From: Wei Yongjun
Fixes the following sparse warning:
drivers/media/usb/dvb-usb/gp8psk.c:281:28: warning:
symbol 'gp8psk_fe_ops' was not declared. Should it be static?
Signed-off-by: Wei Yongjun
---
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 2360e7e..7dc3bdd 100644
--- a/drivers/media/usb/dvb-usb/gp8psk.c
+++ b/drivers/media/usb/dvb-usb/gp8psk.c
@@ -278,7 +278,7 @@ static int gp8psk_fe_reload(void *priv)
return gp8psk_bcm4500_reload(d);
}
-const struct gp8psk_fe_ops gp8psk_fe_ops = {
+static const struct gp8psk_fe_ops gp8psk_fe_ops = {
.in = gp8psk_fe_in,
.out = gp8psk_fe_out,
.reload = gp8psk_fe_reload,
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enabling peer to peer device transactions for PCIe devices
On Wed, Jan 11, 2017 at 10:54:39PM -0600, Stephen Bates wrote: > On Fri, January 6, 2017 4:10 pm, Logan Gunthorpe wrote: > > > > > > On 06/01/17 11:26 AM, Jason Gunthorpe wrote: > > > > > >> Make a generic API for all of this and you'd have my vote.. > >> > >> > >> IMHO, you must support basic pinning semantics - that is necessary to > >> support generic short lived DMA (eg filesystem, etc). That hardware can > >> clearly do that if it can support ODP. > > > > I agree completely. > > > > > > What we want is for RDMA, O_DIRECT, etc to just work with special VMAs > > (ie. at least those backed with ZONE_DEVICE memory). Then > > GPU/NVME/DAX/whatever drivers can just hand these VMAs to userspace > > (using whatever interface is most appropriate) and userspace can do what > > it pleases with them. This makes _so_ much sense and actually largely > > already works today (as demonstrated by iopmem). > > +1 for iopmem ;-) > > I feel like we are going around and around on this topic. I would like to > see something that is upstream that enables P2P even if it is only the > minimum viable useful functionality to begin. I think aiming for the moon > (which is what HMM and things like it are) are simply going to take more > time if they ever get there. > > There is a use case for in-kernel P2P PCIe transfers between two NVMe > devices and between an NVMe device and an RDMA NIC (using NVMe CMBs or > BARs on the NIC). I am even seeing users who now want to move data P2P > between FPGAs and NVMe SSDs and the upstream kernel should be able to > support these users or they will look elsewhere. > > The iopmem patchset addressed all the use cases above and while it is not > an in kernel API it could have been modified to be one reasonably easily. > As Logan states the driver can then choose to pass the VMAs to user-space > in a manner that makes sense. > > Earlier in the thread someone mentioned LSF/MM. There is already a > proposal to discuss this topic so if you are interested please respond to > the email letting the committee know this topic is of interest to you [1]. > > Also earlier in the thread someone discussed the issues around the IOMMU. > Given the known issues around P2P transfers in certain CPU root complexes > [2] it might just be a case of only allowing P2P when a PCIe switch > connects the two EPs. Another option is just to use CONFIG_EXPERT and make > sure people are aware of the pitfalls if they invoke the P2P option. iopmem is not applicable to GPU what i propose is to split the issue in 2 so that everyone can reuse the part that needs to be common namely the DMA API part where you have to create IOMMU mapping for one device to point to the other device memory. We can have a DMA API that is agnostic to how the device memory is manage (so does not matter if device memory have struct page or not). This what i have been arguing in this thread. To make progress on this issue we need to stop conflicting different use case. So i say let solve the IOMMU issue first and let everyone use it in their own way with their device. I do not think we can share much more than that. Cheers, Jérôme -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -next] [media] media: usb: tm6000: fix typo in parameter description
From: Wei Yongjun Fix typo in parameter description. Signed-off-by: Wei Yongjun --- drivers/media/usb/tm6000/tm6000-input.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/tm6000/tm6000-input.c b/drivers/media/usb/tm6000/tm6000-input.c index 7fe00a5..6856674 100644 --- a/drivers/media/usb/tm6000/tm6000-input.c +++ b/drivers/media/usb/tm6000/tm6000-input.c @@ -39,7 +39,7 @@ MODULE_PARM_DESC(enable_ir, "enable ir (default is enable)"); static unsigned int ir_clock_mhz = 12; module_param(ir_clock_mhz, int, 0644); -MODULE_PARM_DESC(enable_ir, "ir clock, in MHz"); +MODULE_PARM_DESC(ir_clock_mhz, "ir clock, in MHz"); #define URB_SUBMIT_DELAY 100 /* ms - Delay to submit an URB request on retrial and init */ #define URB_INT_LED_DELAY 100 /* ms - Delay to turn led on again on int mode */ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] dt: bindings: Add support for CSI1 bus
Hi Pavel,
On Wed, Jan 11, 2017 at 11:53:35PM +0100, Pavel Machek wrote:
> From: Sakari Ailus
>
> In the vast majority of cases the bus type is known to the driver(s)
> since a receiver or transmitter can only support a single one. There
> are cases however where different options are possible.
>
> The existing V4L2 OF support tries to figure out the bus type and
> parse the bus parameters based on that. This does not scale too well
> as there are multiple serial busses that share common properties.
>
> Some hardware also supports multiple types of busses on the same
> interfaces.
>
> Document the CSI1/CCP2 property strobe. It signifies the clock or
> strobe mode.
>
> Signed-off-by: Sakari Ailus
> Signed-off-by: Ivaylo Dimitrov
> Signed-off-by: Pavel Machek
>
> diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt
> b/Documentation/devicetree/bindings/media/video-interfaces.txt
> index 9cd2a36..08c4498 100644
> --- a/Documentation/devicetree/bindings/media/video-interfaces.txt
> +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
> @@ -76,6 +76,11 @@ Optional endpoint properties
>mode horizontal and vertical synchronization signals are provided to the
>slave device (data source) by the master device (data sink). In the master
>mode the data source device is also the source of the synchronization
> signals.
> +- bus-type: data bus type. Possible values are:
> + 0 - MIPI CSI2
> + 1 - parallel / Bt656
Why not have separate values for parallel and BT.656?
baruch
> + 2 - MIPI CSI1
> + 3 - CCP2
> - bus-width: number of data lines actively used, valid for the parallel
> busses.
> - data-shift: on the parallel data busses, if bus-width is used to specify
> the
>number of data lines, data-shift can be used to specify which data lines
> are
> @@ -112,7 +117,8 @@ Optional endpoint properties
>should be the combined length of data-lanes and clock-lanes properties.
>If the lane-polarities property is omitted, the value must be interpreted
>as 0 (normal). This property is valid for serial busses only.
> -
> +- strobe: Whether the clock signal is used as clock or strobe. Used
> + with CCP2, for instance.
>
> Example
> ---
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: Add video bus switch
On Sat 2016-12-24 16:20:31, Pavel Machek wrote:
>
> N900 contains front and back camera, with a switch between the
> two. This adds support for the switch component, and it is now
> possible to select between front and back cameras during runtime.
>
> Signed-off-by: Sebastian Reichel
> Signed-off-by: Ivaylo Dimitrov
> Signed-off-by: Pavel Machek
Can I get some feedback here? This works for me -- I can use both
cameras during one boot -- can I get it applied?
Thanks,
Pavel
> diff --git a/Documentation/devicetree/bindings/media/video-bus-switch.txt
> b/Documentation/devicetree/bindings/media/video-bus-switch.txt
> new file mode 100644
> index 000..1b9f8e0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/video-bus-switch.txt
> @@ -0,0 +1,63 @@
> +Video Bus Switch Binding
> +
> +
> +This is a binding for a gpio controlled switch for camera interfaces. Such a
> +device is used on some embedded devices to connect two cameras to the same
> +interface of a image signal processor.
> +
> +Required properties
> +===
> +
> +compatible : must contain "video-bus-switch"
> +switch-gpios : GPIO specifier for the gpio, which can toggle the
> + selected camera. The GPIO should be configured, so
> + that a disabled GPIO means, that the first port is
> + selected.
> +
> +Required Port nodes
> +===
> +
> +More documentation on these bindings is available in
> +video-interfaces.txt in the same directory.
> +
> +reg : The interface:
> + 0 - port for image signal processor
> + 1 - port for first camera sensor
> + 2 - port for second camera sensor
> +
> +Example
> +===
> +
> +video-bus-switch {
> + compatible = "video-bus-switch"
> + switch-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + csi_switch_in: endpoint {
> + remote-endpoint = <&csi_isp>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + csi_switch_out1: endpoint {
> + remote-endpoint = <&csi_cam1>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> +
> + csi_switch_out2: endpoint {
> + remote-endpoint = <&csi_cam2>;
> + };
> + };
> + };
> +};
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index ce4a96f..a4b509e 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -91,6 +91,16 @@ config VIDEO_OMAP3_DEBUG
> ---help---
> Enable debug messages on OMAP 3 camera controller driver.
>
> +config VIDEO_BUS_SWITCH
> + tristate "Video Bus switch"
> + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + depends on MEDIA_CONTROLLER
> + depends on OF
> + ---help---
> + Driver for a GPIO controlled video bus switch, which is used to
> + connect two camera sensors to the same port a the image signal
> + processor.
> +
> config VIDEO_PXA27x
> tristate "PXA27x Quick Capture Interface driver"
> depends on VIDEO_DEV && HAS_DMA
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 40b18d1..8eafc27 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -11,6 +11,8 @@ obj-$(CONFIG_VIDEO_MMP_CAMERA) += marvell-ccic/
> obj-$(CONFIG_VIDEO_OMAP3)+= omap3isp/
> obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
>
> +obj-$(CONFIG_VIDEO_BUS_SWITCH) += video-bus-switch.o
> +
> obj-$(CONFIG_VIDEO_VIU) += fsl-viu.o
>
> obj-$(CONFIG_VIDEO_VIVID)+= vivid/
> diff --git a/drivers/media/platform/video-bus-switch.c
> b/drivers/media/platform/video-bus-switch.c
> new file mode 100644
> index 000..6400cfc
> --- /dev/null
> +++ b/drivers/media/platform/video-bus-switch.c
> @@ -0,0 +1,387 @@
> +/*
> + * Generic driver for video bus switches
> + *
> + * Copyright (C) 2015 Sebastian Reichel
> + * Copyright (C) 2016 Pavel Machek
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#define DEBUG
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#
[PATCHv2] v4l: split lane parsing code
From: Sakari Ailus
The function to parse CSI2 bus parameters was called
v4l2_of_parse_csi_bus(), rename it as v4l2_of_parse_csi2_bus() in
anticipation of CSI1/CCP2 support.
Obtain data bus type from bus-type property. Only try parsing bus
specific properties in this case.
Separate lane parsing from CSI-2 bus parameter parsing. The CSI-1 will
need these as well, separate them into a different
function. have_clk_lane and num_data_lanes arguments may be NULL; the
CSI-1 bus will have no use for them.
Signed-off-by: Sakari Ailus
Signed-off-by: Ivaylo Dimitrov
Signed-off-by: Pavel Machek
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index 93b3368..60bbc5f 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -20,53 +20,88 @@
#include
-static int v4l2_of_parse_csi_bus(const struct device_node *node,
-struct v4l2_of_endpoint *endpoint)
+enum v4l2_of_bus_type {
+ V4L2_OF_BUS_TYPE_CSI2 = 0,
+ V4L2_OF_BUS_TYPE_PARALLEL,
+};
+
+static int v4l2_of_parse_lanes(const struct device_node *node,
+ unsigned char *clock_lane,
+ bool *have_clk_lane,
+ unsigned char *data_lanes,
+ bool *lane_polarities,
+ unsigned short *__num_data_lanes,
+ unsigned int max_data_lanes)
{
- struct v4l2_of_bus_mipi_csi2 *bus = &endpoint->bus.mipi_csi2;
struct property *prop;
- bool have_clk_lane = false;
- unsigned int flags = 0;
+ unsigned short num_data_lanes = 0;
u32 v;
prop = of_find_property(node, "data-lanes", NULL);
if (prop) {
const __be32 *lane = NULL;
- unsigned int i;
- for (i = 0; i < ARRAY_SIZE(bus->data_lanes); i++) {
+ for (num_data_lanes = 0; num_data_lanes < max_data_lanes;
+num_data_lanes++) {
lane = of_prop_next_u32(prop, lane, &v);
if (!lane)
break;
- bus->data_lanes[i] = v;
+ data_lanes[num_data_lanes] = v;
}
- bus->num_data_lanes = i;
}
+ if (__num_data_lanes)
+ *__num_data_lanes = num_data_lanes;
prop = of_find_property(node, "lane-polarities", NULL);
if (prop) {
const __be32 *polarity = NULL;
unsigned int i;
- for (i = 0; i < ARRAY_SIZE(bus->lane_polarities); i++) {
+ for (i = 0; i < 1 + max_data_lanes; i++) {
polarity = of_prop_next_u32(prop, polarity, &v);
if (!polarity)
break;
- bus->lane_polarities[i] = v;
+ lane_polarities[i] = v;
}
- if (i < 1 + bus->num_data_lanes /* clock + data */) {
+ if (i < 1 + num_data_lanes /* clock + data */) {
pr_warn("%s: too few lane-polarities entries (need %u,
got %u)\n",
- node->full_name, 1 + bus->num_data_lanes, i);
+ node->full_name, 1 + num_data_lanes, i);
return -EINVAL;
}
}
+ if (have_clk_lane)
+ *have_clk_lane = false;
+
if (!of_property_read_u32(node, "clock-lanes", &v)) {
- bus->clock_lane = v;
- have_clk_lane = true;
+ *clock_lane = v;
+ if (have_clk_lane)
+ *have_clk_lane = true;
}
+ return 0;
+}
+
+static int v4l2_of_parse_csi2_bus(const struct device_node *node,
+struct v4l2_of_endpoint *endpoint)
+{
+ struct v4l2_of_bus_mipi_csi2 *bus = &endpoint->bus.mipi_csi2;
+ bool have_clk_lane = false;
+ unsigned int flags = 0;
+ int rval;
+ u32 v;
+
+ rval = v4l2_of_parse_lanes(node, &bus->clock_lane, &have_clk_lane,
+ bus->data_lanes, bus->lane_polarities,
+ &bus->num_data_lanes,
+ ARRAY_SIZE(bus->data_lanes));
+ if (rval)
+ return rval;
+
+ BUILD_BUG_ON(1 + ARRAY_SIZE(bus->data_lanes)
+ != ARRAY_SIZE(bus->lane_polarities));
+
if (of_get_property(node, "clock-noncontinuous", &v))
flags |= V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK;
else if (have_clk_lane || bus->num_data_lanes > 0)
@@ -151,6 +186,7 @@ static void v4l2_of_parse_parallel_bus(const struct
device_node *node,
int v4l2_of_parse_endpoint(const struct device_node *node,
struct v4l2_of_endpoint *endpoint)
{
+ u32 bus_type;
int rval;
[ANN] Possible media summit in Portland: who will be at the ELC?
Second attempt, this time with the [ANN] prefix in the hope more people will reply... Mauro is on vacation until the 21st, so he asked me to see who will go to the ELC in Portland in February. If there are enough core developers there, then we can organize a summit meeting on the Monday (Feb 20). Please mail me if you can (and want) attend a possible summit meeting on the 20th. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
