date:20171121

Re: [PATCH] media: mtk-vcodec: add missing MODULE_LICENSE/DESCRIPTION

2017-11-21 Thread Randy Dunlap

On 11/21/17 23:41, kbuild test robot wrote:
> Hi Jesse,
> 
> Thank you for the patch! Yet something to improve:

missing
#include 

Jesse, did you build all of these driver changes?


> [auto build test ERROR on linuxtv-media/master]
> [also build test ERROR on v4.14 next-20171121]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Jesse-Chan/media-mtk-vcodec-add-missing-MODULE_LICENSE-DESCRIPTION/20171122-124620
> base:   git://linuxtv.org/media_tree.git master
> config: xtensa-allmodconfig (attached as .config)
> compiler: xtensa-linux-gcc (GCC) 4.9.0
> reproduce:
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=xtensa 
> 
> All errors (new ones prefixed by >>):
> 
>>> drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c:55:16: error: expected 
>>> declaration specifiers or '...' before string constant
> MODULE_LICENSE("GPL v2");
>^
>drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c:56:20: error: expected 
> declaration specifiers or '...' before string constant
> MODULE_DESCRIPTION("Mediatek video codec driver");
>^
> 
> vim +55 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c
> 
> 54
>   > 55MODULE_LICENSE("GPL v2");
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> 


-- 
~Randy

Re: [PATCH] media: mtk-vcodec: add missing MODULE_LICENSE/DESCRIPTION

2017-11-21 Thread kbuild test robot

Hi Jesse,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.14 next-20171121]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jesse-Chan/media-mtk-vcodec-add-missing-MODULE_LICENSE-DESCRIPTION/20171122-124620
base:   git://linuxtv.org/media_tree.git master
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

>> drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c:55:16: error: expected 
>> declaration specifiers or '...' before string constant
MODULE_LICENSE("GPL v2");
   ^
   drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c:56:20: error: expected 
declaration specifiers or '...' before string constant
MODULE_DESCRIPTION("Mediatek video codec driver");
   ^

vim +55 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c

54  
  > 55  MODULE_LICENSE("GPL v2");

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 2/5] media: dt-bindings: Add bindings for TDA1997X

2017-11-21 Thread Sakari Ailus

Hi Tim,

On Thu, Nov 09, 2017 at 10:45:33AM -0800, Tim Harvey wrote:
> Cc: Rob Herring 
> Signed-off-by: Tim Harvey 
> ---
> v3:
>  - fix typo
> 
> v2:
>  - add vendor prefix and remove _ from vidout-portcfg
>  - remove _ from labels
>  - remove max-pixel-rate property
>  - describe and provide example for single output port
>  - update to new audio port bindings
> ---
>  .../devicetree/bindings/media/i2c/tda1997x.txt | 179 
> +
>  1 file changed, 179 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/tda1997x.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/tda1997x.txt 
> b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
> new file mode 100644
> index 000..dd37f14
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/tda1997x.txt
> @@ -0,0 +1,179 @@
> +Device-Tree bindings for the NXP TDA1997x HDMI receiver
> +
> +The TDA19971/73 are HDMI video receivers.
> +
> +The TDA19971 Video port output pins can be used as follows:
> + - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4]
> + - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4]
> + - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4]
> + - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2]
> + - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] 
> CbCr[11:0]
> + - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles)
> + - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles)
> + - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
> +
> +The TDA19973 Video port output pins can be used as follows:
> + - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0]
> + - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0]
> + - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0]
> + - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles)
> +
> +The Video port output pins are mapped via 4-bit 'pin groups' allowing
> +for a variety of connection possibilities including swapping pin order within
> +pin groups. The video_portcfg device-tree property consists of register 
> mapping
> +pairs which map a chip-specific VP output register to a 4-bit pin group. If
> +the pin group needs to be bit-swapped you can use the *_S pin-group defines.
> +
> +Required Properties:
> + - compatible  :
> +  - "nxp,tda19971" for the TDA19971
> +  - "nxp,tda19973" for the TDA19973
> + - reg : I2C slave address
> + - interrupts  : The interrupt number
> + - DOVDD-supply: Digital I/O supply
> + - DVDD-supply : Digital Core supply
> + - AVDD-supply : Analog supply
> + - nxp,vidout-portcfg  : array of pairs mapping VP output pins to pin groups.
> +
> +Optional Properties:
> + - nxp,audout-format   : DAI bus format: "i2s" or "spdif".
> + - nxp,audout-width: width of audio output data bus (1-4).
> + - nxp,audout-layout   : data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used).
> + - nxp,audout-mclk-fs  : Multiplication factor between stream rate and codec
> + mclk.
> +
> +The device node must contain one 'port' child node for its digital output
> +video port, in accordance with the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt.

Could you add that this port has one endpoint node as well? (Unless you
support multiple, that is.)

> +
> +Optional Endpoint Properties:
> +  The following three properties are defined in video-interfaces.txt and
> +  are valid for source endpoints only:

Transmitters? Don't you have an endpoint only in the port representing the
transmitter?

> +  - hsync-active: Horizontal synchronization polarity. Defaults to active 
> high.
> +  - vsync-active: Vertical synchronization polarity. Defaults to active high.
> +  - data-active: Data polarity. Defaults to active high.
> +
> +Examples:
> + - VP[15:0] connected to IMX6 CSI_DATA[19:4] for 16bit YUV422
> +   16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins)
> + hdmi-receiver@48 {
> + compatible = "nxp,tda19971";
> + pinctrl-names = "default";
> + pinctrl-0 = <_tda1997x>;
> + reg = <0x48>;
> + interrupt-parent = <>;
> + interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
> + DOVDD-supply = <_3p3v>;
> + AVDD-supply = <_1p8v>;
> + DVDD-supply = <_1p8v>;
> + /* audio */
> + #sound-dai-cells = <0>;
> + nxp,audout-format = "i2s";
> + nxp,audout-layout = <0>;
> + nxp,audout-width = <16>;
> + nxp,audout-mclk-fs = <128>;
> + /*
> +  * The 8bpp YUV422 semi-planar mode outputs CbCr[11:4]
> +  * and Y[11:4] across 16bits in the same pixclk cycle.
> +

[PATCH 23/30] [media] atomisp: deprecate pci_get_bus_and_slot()

2017-11-21 Thread Sinan Kaya

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.

Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't
extract the domain number. Other places, use the actual domain number from
the device.

Signed-off-by: Sinan Kaya 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c   | 2 +-
 drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index 663aa91..95b9c7a 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -1233,7 +1233,7 @@ static int atomisp_pci_probe(struct pci_dev *dev,
isp->pdev = dev;
isp->dev = >dev;
isp->sw_contex.power_state = ATOM_ISP_POWER_UP;
-   isp->pci_root = pci_get_bus_and_slot(0, 0);
+   isp->pci_root = pci_get_domain_bus_and_slot(0, 0, 0);
if (!isp->pci_root) {
dev_err(>dev, "Unable to find PCI host\n");
return -ENODEV;
diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c 
b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
index 4631b1d..51dcef57 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c
@@ -39,7 +39,7 @@ static inline int platform_is(u8 model)
 
 static int intel_mid_msgbus_init(void)
 {
-   pci_root = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
+   pci_root = pci_get_domain_bus_and_slot(0, 0, PCI_DEVFN(0, 0));
if (!pci_root) {
pr_err("%s: Error: msgbus PCI handle NULL\n", __func__);
return -ENODEV;
-- 
1.9.1

cron job: media_tree daily build: WARNINGS

2017-11-21 Thread Hans Verkuil

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 Nov 22 05:00:16 CET 2017
media-tree git hash:30b4e122d71cbec2944a5f8b558b88936ee42f10
media_build git hash:   097aaf3e4e4bfdeff130db9697dec1befeb3221b
v4l-utils git hash: a8a04d397e929381a2150bee2100fc28ad2cfbec
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: 0.5.1 (Debian: 0.5.1-2)
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.13.0-164

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-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: WARNINGS
linux-3.12.67-i686: WARNINGS
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.26-i686: OK
linux-4.10.14-i686: OK
linux-4.11-i686: OK
linux-4.12.1-i686: OK
linux-4.13-i686: OK
linux-4.14-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: WARNINGS
linux-3.12.67-x86_64: WARNINGS
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: WARNINGS
linux-4.9.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12.1-x86_64: WARNINGS
linux-4.13-x86_64: OK
linux-4.14-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

Re: [PATCH v4 00/12] [dt-bindings] [media] Add document file and driver for Sony CXD2880 DVB-T2/T tuner + demodulator

2017-11-21 Thread Takiguchi, Yasunari

Hi, all

I sent the patch series of Sony CXD2880 DVB-T2/T tuner + demodulator driver 
version 4 on 13th/Oct.
I'd like to get better understanding of current review status for our codes.

Are there any comments, advices and review results for them?

Regards,
Takiguchi

Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

2017-11-21 Thread Yong

On Tue, 21 Nov 2017 16:48:27 +0100
Maxime Ripard  wrote:

> Hi,
> 
> On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote:
> > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > and CSI1 is used for parallel interface. This is not documented in
> > datasheet but by testing and guess.
> > 
> > This patch implement a v4l2 framework driver for it.
> > 
> > Currently, the driver only support the parallel interface. MIPI-CSI2,
> > ISP's support are not included in this patch.
> > 
> > Signed-off-by: Yong Deng 
> 
> Thanks again for this driver.
> 
> It seems like at least this iteration is behaving in a weird way with
> DMA transfers for at least YU12 and NV12 (and I would assume YV12).
> 
> Starting a transfer of multiple frames in either of these formats,
> using either ffmpeg (ffmpeg -f v4l2 -video_size 640x480 -framerate 30
> -i /dev/video0 output.mkv) or yavta (yavta -c80 -p -F --skip 0 -f NV12
> -s 640x480 $(media-c tl -e 'sun6i-csi')) will end up in a panic.
> 
> The panic seems to be generated with random data going into parts of
> the kernel memory, the pattern being in my case something like
> 0x8287868a which is very odd (always around 0x88)
> 
> It turns out that when you cover the sensor, the values change to
> around 0x28, so it really seems like it's pixels that have been copied
> there.
> 
> I've looked quickly at the DMA setup, and it seems reasonable to
> me. Do you have the same issue on your side? Have you been able to
> test those formats using your hardware?

I had tested the following formats with BT1120 input:
V4L2_PIX_FMT_NV12   -> NV12
V4L2_PIX_FMT_NV21   -> NV21
V4L2_PIX_FMT_NV16   -> NV16
V4L2_PIX_FMT_NV61   -> NV61
V4L2_PIX_FMT_YUV420 -> YU12
V4L2_PIX_FMT_YVU420 -> YV12
V4L2_PIX_FMT_YUV422P-> 422P
And they all work fine.

> 
> Given that they all are planar formats and YUYV and the likes work
> just fine, maybe we can leave them aside for now?

V4L2_PIX_FMT_YUV422P and V4L2_PIX_FMT_YUYV is OK, and V4L2_PIX_FMT_NV12
is bad? It's really weird.

What's your input bus code format, type and width?

> 
> Thanks!
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com


Thanks,
Yong

Re: 'LITE-ON USB2.0 DVB-T Tune' driver crash with kernel 4.13 / ubuntu 17.10

2017-11-21 Thread Laurent Caumont

Hi Sean,
Yes, it is working well.
Laurent

2017-11-21 22:03 UTC+01:00, Sean Young :
> Hi Laurent,
>
> On Sun, Nov 12, 2017 at 09:38:47AM +0100, Laurent Caumont wrote:
>> Thank you for the changes, It's better like this, I will test it.
>
> Just wondering if you have had the time to test this patch. It would be
> great if it could be included after being tested.
>
> Thanks,
>
> Sean
>

Hi Dear

2017-11-21 Thread Ronald Bern

hello baby.
Can I will like to know about you. I am a single man searching for a nice 
female friend.

Re: 'LITE-ON USB2.0 DVB-T Tune' driver crash with kernel 4.13 / ubuntu 17.10

2017-11-21 Thread Sean Young

Hi Laurent,

On Sun, Nov 12, 2017 at 09:38:47AM +0100, Laurent Caumont wrote:
> Thank you for the changes, It's better like this, I will test it.

Just wondering if you have had the time to test this patch. It would be
great if it could be included after being tested.

Thanks,

Sean

Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2 receiver

2017-11-21 Thread Eric Anholt

Rob Herring  writes:

> On Tue, Nov 21, 2017 at 1:26 PM, Eric Anholt  wrote:
>> Dave Stevenson  writes:
>>
>>> Hi Rob
>>>
>>> On 27 September 2017 at 22:51, Rob Herring  wrote:
 On Fri, Sep 22, 2017 at 05:07:22PM +0100, Dave Stevenson wrote:
> Hi Stefan
>
> On 22 September 2017 at 07:45, Stefan Wahren  
> wrote:
> > Hi Dave,
> >
> >> Dave Stevenson  hat am 20. September 
> >> 2017 um 18:07 geschrieben:
> >>
> >>
> >> Document the DT bindings for the CSI2/CCP2 receiver peripheral
> >> (known as Unicam) on BCM283x SoCs.
> >>
> >> Signed-off-by: Dave Stevenson 
> >> ---
> >>
> >> Changes since v2
> >> - Removed all references to Linux drivers.
> >> - Reworded section about disabling the firmware driver.
> >> - Renamed clock from "lp_clock" to "lp" in description and example.
> >> - Referred to video-interfaces.txt and stated requirements on 
> >> remote-endpoint
> >>   and data-lanes.
> >> - Corrected typo in example from csi to csi1.
> >> - Removed unnecessary #address-cells and #size-cells in example.
> >> - Removed setting of status from the example.
> >>
> >>  .../devicetree/bindings/media/bcm2835-unicam.txt   | 85 
> >> ++
> >>  1 file changed, 85 insertions(+)
> >>  create mode 100644 
> >> Documentation/devicetree/bindings/media/bcm2835-unicam.txt
> >>
> >> diff --git 
> >> a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt 
> >> b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
> >> new file mode 100644
> >> index 000..7714fb3
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
> >> @@ -0,0 +1,85 @@
> >> +Broadcom BCM283x Camera Interface (Unicam)
> >> +--
> >> +
> >> +The Unicam block on BCM283x SoCs is the receiver for either
> >> +CSI-2 or CCP2 data from image sensors or similar devices.
> >> +
> >> +The main platform using this SoC is the Raspberry Pi family of boards.
> >> +On the Pi the VideoCore firmware can also control this hardware block,
> >> +and driving it from two different processors will cause issues.
> >> +To avoid this, the firmware checks the device tree configuration
> >> +during boot. If it finds device tree nodes called csi0 or csi1 then
> >> +it will stop the firmware accessing the block, and it can then
> >> +safely be used via the device tree binding.
> >> +
> >> +Required properties:
> >> +===
> >> +- compatible : must be "brcm,bcm2835-unicam".
> >> +- reg: physical base address and length of the 
> >> register sets for the
> >> +   device.
> >> +- interrupts : should contain the IRQ line for this Unicam instance.
> >> +- clocks : list of clock specifiers, corresponding to entries in
> >> +   clock-names property.
> >> +- clock-names: must contain an "lp" entry, matching entries 
> >> in the
> >> +   clocks property.
> >> +
> >> +Unicam supports a single port node. It should contain one 'port' 
> >> child node
> >> +with child 'endpoint' node. Please refer to the bindings defined in
> >> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> >> +
> >> +Within the endpoint node the "remote-endpoint" and "data-lanes" 
> >> properties
> >> +are mandatory.
> >> +Data lane reordering is not supported so the data lanes must be in 
> >> order,
> >> +starting at 1. The number of data lanes should represent the number of
> >> +usable lanes for the hardware block. That may be limited by either 
> >> the SoC or
> >> +how the platform presents the interface, and the lower value must be 
> >> used.
> >> +
> >> +Lane reordering is not supported on the clock lane either, so the 
> >> optional
> >> +property "clock-lane" will implicitly be <0>.
> >> +Similarly lane inversion is not supported, therefore 
> >> "lane-polarities" will
> >> +implicitly be <0 0 0 0 0>.
> >> +Neither of these values will be checked.
> >> +
> >> +Example:
> >> + csi1: csi1@7e801000 {
> >> + compatible = "brcm,bcm2835-unicam";
> >> + reg = <0x7e801000 0x800>,
> >> +   <0x7e802004 0x4>;
> >
> > sorry, i didn't noticed this before. I'm afraid this is using a small 
> > range of the CMI. Are there possible other users of this range? Does it 
> > make sense to handle this by a separate clock driver?
>
> CMI (Clock Manager Image) consists of a total of 4 registers.
> 0x7e802000 is CMI_CAM0,

[PATCH] media: imon: auto-config ffdc 30 device

2017-11-21 Thread Sean Young

Another device with the 0xffdc device id, this one with 0x30 in the
config byte. Its an iMON VFD + iMON IR (it does not understand rc6).

Signed-off-by: Sean Young 
---
 drivers/media/rc/imon.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index b25b35b3f6da..bff2d8503504 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -1956,6 +1956,7 @@ static void imon_get_ffdc_type(struct imon_context *ictx)
break;
/* iMON VFD, iMON IR */
case 0x24:
+   case 0x30:
case 0x85:
dev_info(ictx->dev, "0xffdc iMON VFD, iMON IR");
detected_display_type = IMON_DISPLAY_TYPE_VFD;
-- 
2.14.3

Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2 receiver

2017-11-21 Thread Rob Herring

On Tue, Nov 21, 2017 at 1:26 PM, Eric Anholt  wrote:
> Dave Stevenson  writes:
>
>> Hi Rob
>>
>> On 27 September 2017 at 22:51, Rob Herring  wrote:
>>> On Fri, Sep 22, 2017 at 05:07:22PM +0100, Dave Stevenson wrote:
 Hi Stefan

 On 22 September 2017 at 07:45, Stefan Wahren  
 wrote:
 > Hi Dave,
 >
 >> Dave Stevenson  hat am 20. September 
 >> 2017 um 18:07 geschrieben:
 >>
 >>
 >> Document the DT bindings for the CSI2/CCP2 receiver peripheral
 >> (known as Unicam) on BCM283x SoCs.
 >>
 >> Signed-off-by: Dave Stevenson 
 >> ---
 >>
 >> Changes since v2
 >> - Removed all references to Linux drivers.
 >> - Reworded section about disabling the firmware driver.
 >> - Renamed clock from "lp_clock" to "lp" in description and example.
 >> - Referred to video-interfaces.txt and stated requirements on 
 >> remote-endpoint
 >>   and data-lanes.
 >> - Corrected typo in example from csi to csi1.
 >> - Removed unnecessary #address-cells and #size-cells in example.
 >> - Removed setting of status from the example.
 >>
 >>  .../devicetree/bindings/media/bcm2835-unicam.txt   | 85 
 >> ++
 >>  1 file changed, 85 insertions(+)
 >>  create mode 100644 
 >> Documentation/devicetree/bindings/media/bcm2835-unicam.txt
 >>
 >> diff --git a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt 
 >> b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
 >> new file mode 100644
 >> index 000..7714fb3
 >> --- /dev/null
 >> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
 >> @@ -0,0 +1,85 @@
 >> +Broadcom BCM283x Camera Interface (Unicam)
 >> +--
 >> +
 >> +The Unicam block on BCM283x SoCs is the receiver for either
 >> +CSI-2 or CCP2 data from image sensors or similar devices.
 >> +
 >> +The main platform using this SoC is the Raspberry Pi family of boards.
 >> +On the Pi the VideoCore firmware can also control this hardware block,
 >> +and driving it from two different processors will cause issues.
 >> +To avoid this, the firmware checks the device tree configuration
 >> +during boot. If it finds device tree nodes called csi0 or csi1 then
 >> +it will stop the firmware accessing the block, and it can then
 >> +safely be used via the device tree binding.
 >> +
 >> +Required properties:
 >> +===
 >> +- compatible : must be "brcm,bcm2835-unicam".
 >> +- reg: physical base address and length of the 
 >> register sets for the
 >> +   device.
 >> +- interrupts : should contain the IRQ line for this Unicam instance.
 >> +- clocks : list of clock specifiers, corresponding to entries in
 >> +   clock-names property.
 >> +- clock-names: must contain an "lp" entry, matching entries in 
 >> the
 >> +   clocks property.
 >> +
 >> +Unicam supports a single port node. It should contain one 'port' child 
 >> node
 >> +with child 'endpoint' node. Please refer to the bindings defined in
 >> +Documentation/devicetree/bindings/media/video-interfaces.txt.
 >> +
 >> +Within the endpoint node the "remote-endpoint" and "data-lanes" 
 >> properties
 >> +are mandatory.
 >> +Data lane reordering is not supported so the data lanes must be in 
 >> order,
 >> +starting at 1. The number of data lanes should represent the number of
 >> +usable lanes for the hardware block. That may be limited by either the 
 >> SoC or
 >> +how the platform presents the interface, and the lower value must be 
 >> used.
 >> +
 >> +Lane reordering is not supported on the clock lane either, so the 
 >> optional
 >> +property "clock-lane" will implicitly be <0>.
 >> +Similarly lane inversion is not supported, therefore "lane-polarities" 
 >> will
 >> +implicitly be <0 0 0 0 0>.
 >> +Neither of these values will be checked.
 >> +
 >> +Example:
 >> + csi1: csi1@7e801000 {
 >> + compatible = "brcm,bcm2835-unicam";
 >> + reg = <0x7e801000 0x800>,
 >> +   <0x7e802004 0x4>;
 >
 > sorry, i didn't noticed this before. I'm afraid this is using a small 
 > range of the CMI. Are there possible other users of this range? Does it 
 > make sense to handle this by a separate clock driver?

 CMI (Clock Manager Image) consists of a total of 4 registers.
 0x7e802000 is CMI_CAM0, with only bits 0-5 used for gating and
 inversion of the clock and data lanes (2 data lanes available on
 CAM0).
 0x7e802004 is CMI_CAM1, with only

Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2 receiver

2017-11-21 Thread Eric Anholt

Dave Stevenson  writes:

> Hi Rob
>
> On 27 September 2017 at 22:51, Rob Herring  wrote:
>> On Fri, Sep 22, 2017 at 05:07:22PM +0100, Dave Stevenson wrote:
>>> Hi Stefan
>>>
>>> On 22 September 2017 at 07:45, Stefan Wahren  wrote:
>>> > Hi Dave,
>>> >
>>> >> Dave Stevenson  hat am 20. September 
>>> >> 2017 um 18:07 geschrieben:
>>> >>
>>> >>
>>> >> Document the DT bindings for the CSI2/CCP2 receiver peripheral
>>> >> (known as Unicam) on BCM283x SoCs.
>>> >>
>>> >> Signed-off-by: Dave Stevenson 
>>> >> ---
>>> >>
>>> >> Changes since v2
>>> >> - Removed all references to Linux drivers.
>>> >> - Reworded section about disabling the firmware driver.
>>> >> - Renamed clock from "lp_clock" to "lp" in description and example.
>>> >> - Referred to video-interfaces.txt and stated requirements on 
>>> >> remote-endpoint
>>> >>   and data-lanes.
>>> >> - Corrected typo in example from csi to csi1.
>>> >> - Removed unnecessary #address-cells and #size-cells in example.
>>> >> - Removed setting of status from the example.
>>> >>
>>> >>  .../devicetree/bindings/media/bcm2835-unicam.txt   | 85 
>>> >> ++
>>> >>  1 file changed, 85 insertions(+)
>>> >>  create mode 100644 
>>> >> Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>>> >>
>>> >> diff --git a/Documentation/devicetree/bindings/media/bcm2835-unicam.txt 
>>> >> b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>>> >> new file mode 100644
>>> >> index 000..7714fb3
>>> >> --- /dev/null
>>> >> +++ b/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
>>> >> @@ -0,0 +1,85 @@
>>> >> +Broadcom BCM283x Camera Interface (Unicam)
>>> >> +--
>>> >> +
>>> >> +The Unicam block on BCM283x SoCs is the receiver for either
>>> >> +CSI-2 or CCP2 data from image sensors or similar devices.
>>> >> +
>>> >> +The main platform using this SoC is the Raspberry Pi family of boards.
>>> >> +On the Pi the VideoCore firmware can also control this hardware block,
>>> >> +and driving it from two different processors will cause issues.
>>> >> +To avoid this, the firmware checks the device tree configuration
>>> >> +during boot. If it finds device tree nodes called csi0 or csi1 then
>>> >> +it will stop the firmware accessing the block, and it can then
>>> >> +safely be used via the device tree binding.
>>> >> +
>>> >> +Required properties:
>>> >> +===
>>> >> +- compatible : must be "brcm,bcm2835-unicam".
>>> >> +- reg: physical base address and length of the register 
>>> >> sets for the
>>> >> +   device.
>>> >> +- interrupts : should contain the IRQ line for this Unicam instance.
>>> >> +- clocks : list of clock specifiers, corresponding to entries in
>>> >> +   clock-names property.
>>> >> +- clock-names: must contain an "lp" entry, matching entries in 
>>> >> the
>>> >> +   clocks property.
>>> >> +
>>> >> +Unicam supports a single port node. It should contain one 'port' child 
>>> >> node
>>> >> +with child 'endpoint' node. Please refer to the bindings defined in
>>> >> +Documentation/devicetree/bindings/media/video-interfaces.txt.
>>> >> +
>>> >> +Within the endpoint node the "remote-endpoint" and "data-lanes" 
>>> >> properties
>>> >> +are mandatory.
>>> >> +Data lane reordering is not supported so the data lanes must be in 
>>> >> order,
>>> >> +starting at 1. The number of data lanes should represent the number of
>>> >> +usable lanes for the hardware block. That may be limited by either the 
>>> >> SoC or
>>> >> +how the platform presents the interface, and the lower value must be 
>>> >> used.
>>> >> +
>>> >> +Lane reordering is not supported on the clock lane either, so the 
>>> >> optional
>>> >> +property "clock-lane" will implicitly be <0>.
>>> >> +Similarly lane inversion is not supported, therefore "lane-polarities" 
>>> >> will
>>> >> +implicitly be <0 0 0 0 0>.
>>> >> +Neither of these values will be checked.
>>> >> +
>>> >> +Example:
>>> >> + csi1: csi1@7e801000 {
>>> >> + compatible = "brcm,bcm2835-unicam";
>>> >> + reg = <0x7e801000 0x800>,
>>> >> +   <0x7e802004 0x4>;
>>> >
>>> > sorry, i didn't noticed this before. I'm afraid this is using a small 
>>> > range of the CMI. Are there possible other users of this range? Does it 
>>> > make sense to handle this by a separate clock driver?
>>>
>>> CMI (Clock Manager Image) consists of a total of 4 registers.
>>> 0x7e802000 is CMI_CAM0, with only bits 0-5 used for gating and
>>> inversion of the clock and data lanes (2 data lanes available on
>>> CAM0).
>>> 0x7e802004 is CMI_CAM1, with only bits 0-9 used for gating and
>>> inversion of the clock and data lanes (4 data lanes available on
>>> CAM1).
>>> 0x7e802008 is CMI_CAMTEST which I have no documentation or drivers for.

Re: [PATCH] media: rc: double keypresses due to timeout expiring to early

2017-11-21 Thread Matthias Reichl

Hi Sean!

On Sun, Nov 19, 2017 at 09:57:27PM +, Sean Young wrote:
> I think for now the best solution is to revert to 250ms for all protocols
> (except for cec which needs 550ms), and reconsider for another kernel.

Thanks, this sounds like a good idea!

> >>From 2f1135f3f9873778ca5c013d1118710152840cb2 Mon Sep 17 00:00:00 2001
> From: Sean Young 
> Date: Sun, 19 Nov 2017 21:11:17 +
> Subject: [PATCH] media: rc: partial revert of "media: rc: per-protocol repeat
>  period"
> 
> Since commit d57ea877af38 ("media: rc: per-protocol repeat period"), most
> IR protocols have a lower keyup timeout. This causes problems on the
> ite-cir, which has default IR timeout of 200ms.
> 
> Since the IR decoders read the trailing space, with a IR timeout of 200ms,
> the last keydown will have at least a delay of 200ms. This is more than
> the protocol timeout of e.g. rc-6 (which is 164ms). As a result the last
> IR will be interpreted as a new keydown event, and we get two keypresses.
> 
> Revert the protocol timeout to 250ms, except for cec which needs a timeout
> of 550ms.
> 
> Fixes: d57ea877af38 ("media: rc: per-protocol repeat period")
> Cc:  # 4.14
> Signed-off-by: Sean Young 

Tested-by: Matthias Reichl 

I tested this locally with gpio-ir configured to 200ms timeout and
we also received feedback from 2 users that this change fixed the
issue with the ite-cir receiver.

https://forum.kodi.tv/showthread.php?tid=298462=2670637#pid2670637

Thanks a lot for fixing this so quickly!

so long,

Hias
> ---
>  drivers/media/rc/rc-main.c | 32 
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> index 17950e29d4e3..5057b2ba0c10 100644
> --- a/drivers/media/rc/rc-main.c
> +++ b/drivers/media/rc/rc-main.c
> @@ -39,41 +39,41 @@ static const struct {
>   [RC_PROTO_UNKNOWN] = { .name = "unknown", .repeat_period = 250 },
>   [RC_PROTO_OTHER] = { .name = "other", .repeat_period = 250 },
>   [RC_PROTO_RC5] = { .name = "rc-5",
> - .scancode_bits = 0x1f7f, .repeat_period = 164 },
> + .scancode_bits = 0x1f7f, .repeat_period = 250 },
>   [RC_PROTO_RC5X_20] = { .name = "rc-5x-20",
> - .scancode_bits = 0x1f7f3f, .repeat_period = 164 },
> + .scancode_bits = 0x1f7f3f, .repeat_period = 250 },
>   [RC_PROTO_RC5_SZ] = { .name = "rc-5-sz",
> - .scancode_bits = 0x2fff, .repeat_period = 164 },
> + .scancode_bits = 0x2fff, .repeat_period = 250 },
>   [RC_PROTO_JVC] = { .name = "jvc",
>   .scancode_bits = 0x, .repeat_period = 250 },
>   [RC_PROTO_SONY12] = { .name = "sony-12",
> - .scancode_bits = 0x1f007f, .repeat_period = 100 },
> + .scancode_bits = 0x1f007f, .repeat_period = 250 },
>   [RC_PROTO_SONY15] = { .name = "sony-15",
> - .scancode_bits = 0xff007f, .repeat_period = 100 },
> + .scancode_bits = 0xff007f, .repeat_period = 250 },
>   [RC_PROTO_SONY20] = { .name = "sony-20",
> - .scancode_bits = 0x1fff7f, .repeat_period = 100 },
> + .scancode_bits = 0x1fff7f, .repeat_period = 250 },
>   [RC_PROTO_NEC] = { .name = "nec",
> - .scancode_bits = 0x, .repeat_period = 160 },
> + .scancode_bits = 0x, .repeat_period = 250 },
>   [RC_PROTO_NECX] = { .name = "nec-x",
> - .scancode_bits = 0xff, .repeat_period = 160 },
> + .scancode_bits = 0xff, .repeat_period = 250 },
>   [RC_PROTO_NEC32] = { .name = "nec-32",
> - .scancode_bits = 0x, .repeat_period = 160 },
> + .scancode_bits = 0x, .repeat_period = 250 },
>   [RC_PROTO_SANYO] = { .name = "sanyo",
>   .scancode_bits = 0x1f, .repeat_period = 250 },
>   [RC_PROTO_MCIR2_KBD] = { .name = "mcir2-kbd",
> - .scancode_bits = 0x, .repeat_period = 150 },
> + .scancode_bits = 0x, .repeat_period = 250 },
>   [RC_PROTO_MCIR2_MSE] = { .name = "mcir2-mse",
> - .scancode_bits = 0x1f, .repeat_period = 150 },
> + .scancode_bits = 0x1f, .repeat_period = 250 },
>   [RC_PROTO_RC6_0] = { .name = "rc-6-0",
> - .scancode_bits = 0x, .repeat_period = 164 },
> + .scancode_bits = 0x, .repeat_period = 250 },
>   [RC_PROTO_RC6_6A_20] = { .name = "rc-6-6a-20",
> - .scancode_bits = 0xf, .repeat_period = 164 },
> + .scancode_bits = 0xf, .repeat_period = 250 },
>   [RC_PROTO_RC6_6A_24] = { .name = "rc-6-6a-24",
> - .scancode_bits = 0xff, .repeat_period = 164 },
> + .scancode_bits = 0xff, .repeat_period = 250 },
>   [RC_PROTO_RC6_6A_32] = { .name = "rc-6-6a-32",
> - .scancode_bits = 0x, .repeat_period = 164 },
> +

Re: [PATCH v4 04/12] intel-ipu3: Add user space ABI definitions

2017-11-21 Thread sakari.ai...@linux.intel.com

Hi Rajmohan,

My apologies for the late reply.

On Sat, Nov 11, 2017 at 04:07:22AM +, Mani, Rajmohan wrote:
> Hi Sakari,
> 
> > -Original Message-
> > From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
> > Sent: Friday, October 20, 2017 2:30 AM
> > To: Zhi, Yong 
> > Cc: linux-media@vger.kernel.org; sakari.ai...@linux.intel.com; Zheng, Jian 
> > Xu
> > ; Mani, Rajmohan ;
> > Toivonen, Tuukka ; Hu, Jerry W
> > 
> > Subject: Re: [PATCH v4 04/12] intel-ipu3: Add user space ABI definitions
> > 
> > Hi Yong,
> > 
> > On Tue, Oct 17, 2017 at 10:54:49PM -0500, Yong Zhi wrote:

...

> > > +struct ipu3_uapi_params {
> > > + __u32 fourcc;   /* V4L2_PIX_FMT_IPU3_PARAMS */
> > > + __u32 version;  /* Must be 0x100 */
> > 
> > These were called padding1 and padding2 in the previous version. What
> > happened?
> > 
> > I'd just call them reserved, and maybe also make the use field the first
> > member of the struct.
> > 
> 
> These fields were repurposed after v3 of this patch series. Please see the 
> user space code that uses these fields.
> https://chromium.googlesource.com/chromiumos/platform/arc-camera/+/master/hal/intel/psl/ipu3/workers/IPU3AicToFwEncoder.cpp

They were fourcc and version in the beginning, and then replaced by
padding1 and padding 2. Is there a particular reason for changing them
back?

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH] reservation: don't wait when timeout=0

2017-11-21 Thread Christian König


Am 21.11.2017 um 16:58 schrieb Chris Wilson:

Quoting Christian König (2017-11-21 15:49:55)

Am 21.11.2017 um 15:59 schrieb Rob Clark:

On Tue, Nov 21, 2017 at 9:38 AM, Chris Wilson  wrote:

Quoting Rob Clark (2017-11-21 14:08:46)

If we are testing if a reservation object's fences have been
signaled with timeout=0 (non-blocking), we need to pass 0 for
timeout to dma_fence_wait_timeout().

Plus bonus spelling correction.

Signed-off-by: Rob Clark 
---
   drivers/dma-buf/reservation.c | 11 +--
   1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index dec3a815455d..71f51140a9ad 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -420,7 +420,7 @@ EXPORT_SYMBOL_GPL(reservation_object_get_fences_rcu);
*
* RETURNS
* Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
- * greater than zer on success.
+ * greater than zero on success.
*/
   long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
   bool wait_all, bool intr,
@@ -483,7 +483,14 @@ long reservation_object_wait_timeout_rcu(struct 
reservation_object *obj,
  goto retry;
  }

-   ret = dma_fence_wait_timeout(fence, intr, ret);
+   /*
+* Note that dma_fence_wait_timeout() will return 1 if
+* the fence is already signaled, so in the wait_all
+* case when we go through the retry loop again, ret
+* will be greater than 0 and we don't want this to
+* cause _wait_timeout() to block
+*/
+   ret = dma_fence_wait_timeout(fence, intr, timeout ? ret : 0);

One should ask if we should just fix the interface to stop returning
incorrect results (stop "correcting" a completion with 0 jiffies remaining
as 1). A timeout can be distinguished by -ETIME (or your pick of errno).

perhaps -EBUSY, if we go that route (although maybe it should be a
follow-on patch, this one is suitable for backport to stable/lts if
one should so choose..)

I think current approach was chosen to match schedule_timeout() and
other such functions that take a timeout in jiffies.  Not making a
judgement on whether that is a good or bad reason..

We intentionally switched away from that to be in sync with the
wait_event_* interface.

Returning 1 when a function with a zero timeout succeeds is actually
quite common in the kernel.

We actually had this conversation last time, and outside of that it
isn't. Looking at all the convolution to first return 1, then undo the
damage in the caller, it looks pretty silly.


I don't find that very intuitive either, but you would also have to 
handle the error code in the calling function as well.


And it is what the whole kernel does all over the place with it's 
wait_event_* and scheduler timeouts as well.


Regards,
Christian.


-Chris

Re: [PATCH] reservation: don't wait when timeout=0

2017-11-21 Thread Chris Wilson

Quoting Christian König (2017-11-21 15:49:55)
> Am 21.11.2017 um 15:59 schrieb Rob Clark:
> > On Tue, Nov 21, 2017 at 9:38 AM, Chris Wilson  
> > wrote:
> >> Quoting Rob Clark (2017-11-21 14:08:46)
> >>> If we are testing if a reservation object's fences have been
> >>> signaled with timeout=0 (non-blocking), we need to pass 0 for
> >>> timeout to dma_fence_wait_timeout().
> >>>
> >>> Plus bonus spelling correction.
> >>>
> >>> Signed-off-by: Rob Clark 
> >>> ---
> >>>   drivers/dma-buf/reservation.c | 11 +--
> >>>   1 file changed, 9 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> >>> index dec3a815455d..71f51140a9ad 100644
> >>> --- a/drivers/dma-buf/reservation.c
> >>> +++ b/drivers/dma-buf/reservation.c
> >>> @@ -420,7 +420,7 @@ EXPORT_SYMBOL_GPL(reservation_object_get_fences_rcu);
> >>>*
> >>>* RETURNS
> >>>* Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
> >>> - * greater than zer on success.
> >>> + * greater than zero on success.
> >>>*/
> >>>   long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
> >>>   bool wait_all, bool intr,
> >>> @@ -483,7 +483,14 @@ long reservation_object_wait_timeout_rcu(struct 
> >>> reservation_object *obj,
> >>>  goto retry;
> >>>  }
> >>>
> >>> -   ret = dma_fence_wait_timeout(fence, intr, ret);
> >>> +   /*
> >>> +* Note that dma_fence_wait_timeout() will return 1 if
> >>> +* the fence is already signaled, so in the wait_all
> >>> +* case when we go through the retry loop again, ret
> >>> +* will be greater than 0 and we don't want this to
> >>> +* cause _wait_timeout() to block
> >>> +*/
> >>> +   ret = dma_fence_wait_timeout(fence, intr, timeout ? ret : 
> >>> 0);
> >> One should ask if we should just fix the interface to stop returning
> >> incorrect results (stop "correcting" a completion with 0 jiffies remaining
> >> as 1). A timeout can be distinguished by -ETIME (or your pick of errno).
> > perhaps -EBUSY, if we go that route (although maybe it should be a
> > follow-on patch, this one is suitable for backport to stable/lts if
> > one should so choose..)
> >
> > I think current approach was chosen to match schedule_timeout() and
> > other such functions that take a timeout in jiffies.  Not making a
> > judgement on whether that is a good or bad reason..
> 
> We intentionally switched away from that to be in sync with the 
> wait_event_* interface.
> 
> Returning 1 when a function with a zero timeout succeeds is actually 
> quite common in the kernel.

We actually had this conversation last time, and outside of that it
isn't. Looking at all the convolution to first return 1, then undo the
damage in the caller, it looks pretty silly.
-Chris

Re: [PATCH] reservation: don't wait when timeout=0

2017-11-21 Thread Christian König


Am 21.11.2017 um 15:59 schrieb Rob Clark:

On Tue, Nov 21, 2017 at 9:38 AM, Chris Wilson  wrote:

Quoting Rob Clark (2017-11-21 14:08:46)

If we are testing if a reservation object's fences have been
signaled with timeout=0 (non-blocking), we need to pass 0 for
timeout to dma_fence_wait_timeout().

Plus bonus spelling correction.

Signed-off-by: Rob Clark 
---
  drivers/dma-buf/reservation.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index dec3a815455d..71f51140a9ad 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -420,7 +420,7 @@ EXPORT_SYMBOL_GPL(reservation_object_get_fences_rcu);
   *
   * RETURNS
   * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
- * greater than zer on success.
+ * greater than zero on success.
   */
  long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
  bool wait_all, bool intr,
@@ -483,7 +483,14 @@ long reservation_object_wait_timeout_rcu(struct 
reservation_object *obj,
 goto retry;
 }

-   ret = dma_fence_wait_timeout(fence, intr, ret);
+   /*
+* Note that dma_fence_wait_timeout() will return 1 if
+* the fence is already signaled, so in the wait_all
+* case when we go through the retry loop again, ret
+* will be greater than 0 and we don't want this to
+* cause _wait_timeout() to block
+*/
+   ret = dma_fence_wait_timeout(fence, intr, timeout ? ret : 0);

One should ask if we should just fix the interface to stop returning
incorrect results (stop "correcting" a completion with 0 jiffies remaining
as 1). A timeout can be distinguished by -ETIME (or your pick of errno).

perhaps -EBUSY, if we go that route (although maybe it should be a
follow-on patch, this one is suitable for backport to stable/lts if
one should so choose..)

I think current approach was chosen to match schedule_timeout() and
other such functions that take a timeout in jiffies.  Not making a
judgement on whether that is a good or bad reason..


We intentionally switched away from that to be in sync with the 
wait_event_* interface.


Returning 1 when a function with a zero timeout succeeds is actually 
quite common in the kernel.


Regards,
Christian.


BR,
-R


-Chris

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

2017-11-21 Thread Maxime Ripard

Hi,

On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote:
> Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> and CSI1 is used for parallel interface. This is not documented in
> datasheet but by testing and guess.
> 
> This patch implement a v4l2 framework driver for it.
> 
> Currently, the driver only support the parallel interface. MIPI-CSI2,
> ISP's support are not included in this patch.
> 
> Signed-off-by: Yong Deng 

Thanks again for this driver.

It seems like at least this iteration is behaving in a weird way with
DMA transfers for at least YU12 and NV12 (and I would assume YV12).

Starting a transfer of multiple frames in either of these formats,
using either ffmpeg (ffmpeg -f v4l2 -video_size 640x480 -framerate 30
-i /dev/video0 output.mkv) or yavta (yavta -c80 -p -F --skip 0 -f NV12
-s 640x480 $(media-c tl -e 'sun6i-csi')) will end up in a panic.

The panic seems to be generated with random data going into parts of
the kernel memory, the pattern being in my case something like
0x8287868a which is very odd (always around 0x88)

It turns out that when you cover the sensor, the values change to
around 0x28, so it really seems like it's pixels that have been copied
there.

I've looked quickly at the DMA setup, and it seems reasonable to
me. Do you have the same issue on your side? Have you been able to
test those formats using your hardware?

Given that they all are planar formats and YUYV and the likes work
just fine, maybe we can leave them aside for now?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

signature.asc
Description: PGP signature

Re: [PATCH 1/2] drivers/video/hdmi: allow for larger-than-needed vendor IF

2017-11-21 Thread Ville Syrjälä

On Mon, Nov 20, 2017 at 04:02:14PM +0100, Hans Verkuil wrote:
> On 11/20/2017 03:51 PM, Ville Syrjälä wrote:
> > On Mon, Nov 20, 2017 at 02:41:28PM +0100, Hans Verkuil wrote:
> >> From: Hans Verkuil 
> >>
> >> Some devices (Windows Intel driver!) send a Vendor InfoFrame that
> >> uses a payload length of 0x1b instead of the length of 5 or 6
> >> that the unpack code expects. The InfoFrame is padded with 0 by
> >> the source.
> > 
> > So it doesn't put any 3D_Metadata stuff in there? We don't see to
> > have code to parse/generate any of that.
> 
> I can't remember if it puts any 3D stuff in there. Let me know if you
> want me to check this later this week.

Would be nice to know.

I guess we should really add code to parse/generate that stuff too,
otherwise we're going to be lying when we unpack an infoframe with that
stuff present.

-- 
Ville Syrjälä
Intel OTC

[PATCH] [media] dvb-frontends/stv0367: remove redundant self assignment of temporary

2017-11-21 Thread Colin King

From: Colin Ian King 

The self assignment of temporary is redundant and can be removed.
Detected using coccinelle.

Signed-off-by: Colin Ian King 
---
 drivers/media/dvb-frontends/stv0367.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/stv0367.c 
b/drivers/media/dvb-frontends/stv0367.c
index f3529df8211d..ebad100d913f 100644
--- a/drivers/media/dvb-frontends/stv0367.c
+++ b/drivers/media/dvb-frontends/stv0367.c
@@ -1547,7 +1547,6 @@ static int stv0367ter_read_ber(struct dvb_frontend *fe, 
u32 *ber)
} else if (abc == 0x7) {
if (Errors <= 4) {
temporary = (Errors * 10) / (8 * (1 << 14));
-   temporary =  temporary;
} else if (Errors <= 42) {
temporary = (Errors * 1) / (8 * (1 << 14));
temporary = temporary * 10;
@@ -1625,7 +1624,6 @@ static u32 stv0367ter_get_per(struct stv0367_state *state)
else if (abc == 0x9) {
if (Errors <= 4) {
temporary = (Errors * 10) / (8 * (1 << 8));
-   temporary =  temporary;
} else if (Errors <= 42) {
temporary = (Errors * 1) / (8 * (1 << 8));
temporary = temporary * 10;
-- 
2.14.1

Re: [PATCH] reservation: don't wait when timeout=0

2017-11-21 Thread Rob Clark

On Tue, Nov 21, 2017 at 9:38 AM, Chris Wilson  wrote:
> Quoting Rob Clark (2017-11-21 14:08:46)
>> If we are testing if a reservation object's fences have been
>> signaled with timeout=0 (non-blocking), we need to pass 0 for
>> timeout to dma_fence_wait_timeout().
>>
>> Plus bonus spelling correction.
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  drivers/dma-buf/reservation.c | 11 +--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
>> index dec3a815455d..71f51140a9ad 100644
>> --- a/drivers/dma-buf/reservation.c
>> +++ b/drivers/dma-buf/reservation.c
>> @@ -420,7 +420,7 @@ EXPORT_SYMBOL_GPL(reservation_object_get_fences_rcu);
>>   *
>>   * RETURNS
>>   * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
>> - * greater than zer on success.
>> + * greater than zero on success.
>>   */
>>  long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
>>  bool wait_all, bool intr,
>> @@ -483,7 +483,14 @@ long reservation_object_wait_timeout_rcu(struct 
>> reservation_object *obj,
>> goto retry;
>> }
>>
>> -   ret = dma_fence_wait_timeout(fence, intr, ret);
>> +   /*
>> +* Note that dma_fence_wait_timeout() will return 1 if
>> +* the fence is already signaled, so in the wait_all
>> +* case when we go through the retry loop again, ret
>> +* will be greater than 0 and we don't want this to
>> +* cause _wait_timeout() to block
>> +*/
>> +   ret = dma_fence_wait_timeout(fence, intr, timeout ? ret : 0);
>
> One should ask if we should just fix the interface to stop returning
> incorrect results (stop "correcting" a completion with 0 jiffies remaining
> as 1). A timeout can be distinguished by -ETIME (or your pick of errno).

perhaps -EBUSY, if we go that route (although maybe it should be a
follow-on patch, this one is suitable for backport to stable/lts if
one should so choose..)

I think current approach was chosen to match schedule_timeout() and
other such functions that take a timeout in jiffies.  Not making a
judgement on whether that is a good or bad reason..

BR,
-R

> -Chris

Re: [PATCH] reservation: don't wait when timeout=0

2017-11-21 Thread Chris Wilson

Quoting Rob Clark (2017-11-21 14:08:46)
> If we are testing if a reservation object's fences have been
> signaled with timeout=0 (non-blocking), we need to pass 0 for
> timeout to dma_fence_wait_timeout().
> 
> Plus bonus spelling correction.
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/dma-buf/reservation.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index dec3a815455d..71f51140a9ad 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -420,7 +420,7 @@ EXPORT_SYMBOL_GPL(reservation_object_get_fences_rcu);
>   *
>   * RETURNS
>   * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
> - * greater than zer on success.
> + * greater than zero on success.
>   */
>  long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
>  bool wait_all, bool intr,
> @@ -483,7 +483,14 @@ long reservation_object_wait_timeout_rcu(struct 
> reservation_object *obj,
> goto retry;
> }
>  
> -   ret = dma_fence_wait_timeout(fence, intr, ret);
> +   /*
> +* Note that dma_fence_wait_timeout() will return 1 if
> +* the fence is already signaled, so in the wait_all
> +* case when we go through the retry loop again, ret
> +* will be greater than 0 and we don't want this to
> +* cause _wait_timeout() to block
> +*/
> +   ret = dma_fence_wait_timeout(fence, intr, timeout ? ret : 0);

One should ask if we should just fix the interface to stop returning
incorrect results (stop "correcting" a completion with 0 jiffies remaining
as 1). A timeout can be distinguished by -ETIME (or your pick of errno).
-Chris

Re: [PATCH] reservation: don't wait when timeout=0

2017-11-21 Thread Christian König


Am 21.11.2017 um 15:08 schrieb Rob Clark:

If we are testing if a reservation object's fences have been
signaled with timeout=0 (non-blocking), we need to pass 0 for
timeout to dma_fence_wait_timeout().

Plus bonus spelling correction.

Signed-off-by: Rob Clark 


Reviewed-by: Christian König 


---
  drivers/dma-buf/reservation.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index dec3a815455d..71f51140a9ad 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -420,7 +420,7 @@ EXPORT_SYMBOL_GPL(reservation_object_get_fences_rcu);
   *
   * RETURNS
   * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
- * greater than zer on success.
+ * greater than zero on success.
   */
  long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
 bool wait_all, bool intr,
@@ -483,7 +483,14 @@ long reservation_object_wait_timeout_rcu(struct 
reservation_object *obj,
goto retry;
}
  
-		ret = dma_fence_wait_timeout(fence, intr, ret);

+   /*
+* Note that dma_fence_wait_timeout() will return 1 if
+* the fence is already signaled, so in the wait_all
+* case when we go through the retry loop again, ret
+* will be greater than 0 and we don't want this to
+* cause _wait_timeout() to block
+*/
+   ret = dma_fence_wait_timeout(fence, intr, timeout ? ret : 0);
dma_fence_put(fence);
if (ret > 0 && wait_all && (i + 1 < shared_count))
goto retry;

[PATCH] reservation: don't wait when timeout=0

2017-11-21 Thread Rob Clark

If we are testing if a reservation object's fences have been
signaled with timeout=0 (non-blocking), we need to pass 0 for
timeout to dma_fence_wait_timeout().

Plus bonus spelling correction.

Signed-off-by: Rob Clark 
---
 drivers/dma-buf/reservation.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index dec3a815455d..71f51140a9ad 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -420,7 +420,7 @@ EXPORT_SYMBOL_GPL(reservation_object_get_fences_rcu);
  *
  * RETURNS
  * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
- * greater than zer on success.
+ * greater than zero on success.
  */
 long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
 bool wait_all, bool intr,
@@ -483,7 +483,14 @@ long reservation_object_wait_timeout_rcu(struct 
reservation_object *obj,
goto retry;
}
 
-   ret = dma_fence_wait_timeout(fence, intr, ret);
+   /*
+* Note that dma_fence_wait_timeout() will return 1 if
+* the fence is already signaled, so in the wait_all
+* case when we go through the retry loop again, ret
+* will be greater than 0 and we don't want this to
+* cause _wait_timeout() to block
+*/
+   ret = dma_fence_wait_timeout(fence, intr, timeout ? ret : 0);
dma_fence_put(fence);
if (ret > 0 && wait_all && (i + 1 < shared_count))
goto retry;
-- 
2.13.6

usb/media/em28xx: use-after-free in dvb_unregister_frontend

2017-11-21 Thread Andrey Konovalov

Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit e1d1ea549b57790a3d8cf6300e6ef86118d692a3 (4.15-rc1).

em28xx 1-1:9.0: Disconnecting
tc90522 1-0015: Toshiba TC90522 attached.
qm1d1c0042 2-0061: Sharp QM1D1C0042 attached.
dvbdev: DVB: registering new adapter (1-1:9.0)
em28xx 1-1:9.0: DVB: registering adapter 0 frontend 0 (Toshiba TC90522
ISDB-S module)...
dvbdev: dvb_create_media_entity: media entity 'Toshiba TC90522 ISDB-S
module' registered.
dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
em28xx 1-1:9.0: DVB extension successfully initialized
em28xx 1-1:9.0: Remote control support is not available for this card.
em28xx 1-1:9.0: Closing DVB extension
==
BUG: KASAN: use-after-free in dvb_unregister_frontend+0x8f/0xa0
Read of size 8 at addr 880067853628 by task kworker/0:3/3182

CPU: 0 PID: 3182 Comm: kworker/0:3 Not tainted 4.14.0-57501-g9284d204d604 #119
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:17
 dump_stack+0xe1/0x157 lib/dump_stack.c:53
 print_address_description+0x71/0x234 mm/kasan/report.c:252
 kasan_report_error mm/kasan/report.c:351
 kasan_report+0x173/0x270 mm/kasan/report.c:409
 __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430
 dvb_unregister_frontend+0x8f/0xa0 drivers/media/dvb-core/dvb_frontend.c:2768
 em28xx_unregister_dvb drivers/media/usb/em28xx/em28xx-dvb.c:1122
 em28xx_dvb_fini+0x62d/0x8e0 drivers/media/usb/em28xx/em28xx-dvb.c:2129
 em28xx_close_extension+0x71/0x220 drivers/media/usb/em28xx/em28xx-core.c:1122
 em28xx_usb_disconnect+0xd7/0x130 drivers/media/usb/em28xx/em28xx-cards.c:3763
 usb_unbind_interface+0x1b6/0x950 drivers/usb/core/driver.c:423
 __device_release_driver drivers/base/dd.c:870
 device_release_driver_internal+0x563/0x630 drivers/base/dd.c:903
 device_release_driver+0x1e/0x30 drivers/base/dd.c:928
 bus_remove_device+0x2fc/0x4b0 drivers/base/bus.c:565
 device_del+0x39f/0xa70 drivers/base/core.c:1984
 usb_disable_device+0x223/0x710 drivers/usb/core/message.c:1205
 usb_disconnect+0x285/0x7f0 drivers/usb/core/hub.c:2205
 hub_port_connect drivers/usb/core/hub.c:4851
 hub_port_connect_change drivers/usb/core/hub.c:5106
 port_event drivers/usb/core/hub.c:5212
 hub_event_impl+0x10f0/0x3440 drivers/usb/core/hub.c:5324
 hub_event+0x38/0x50 drivers/usb/core/hub.c:5222
 process_one_work+0x944/0x15f0 kernel/workqueue.c:2112
 worker_thread+0xef/0x10d0 kernel/workqueue.c:2246
 kthread+0x367/0x420 kernel/kthread.c:238
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:437

Allocated by task 25:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:551
 kmem_cache_alloc_trace+0x11a/0x290 mm/slub.c:2752
 kmalloc ./include/linux/slab.h:499
 kzalloc ./include/linux/slab.h:688
 tc90522_probe+0x3b/0x440 drivers/media/dvb-frontends/tc90522.c:777
 i2c_device_probe+0x5bf/0x7e0 drivers/i2c/i2c-core-base.c:408
 really_probe drivers/base/dd.c:424
 driver_probe_device+0x564/0x820 drivers/base/dd.c:566
 __device_attach_driver+0x25d/0x2d0 drivers/base/dd.c:662
 bus_for_each_drv+0xff/0x160 drivers/base/bus.c:463
 __device_attach+0x1ab/0x2a0 drivers/base/dd.c:719
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:766
 bus_probe_device+0x1fc/0x2a0 drivers/base/bus.c:523
 device_add+0xc27/0x15a0 drivers/base/core.c:1835
 device_register+0x22/0x30 drivers/base/core.c:1905
 i2c_new_device+0x5dd/0xdc0 drivers/i2c/i2c-core-base.c:792
 em28xx_dvb_init.part.4+0x49f4/0x91d0 drivers/media/usb/em28xx/em28xx-dvb.c:1860
 em28xx_dvb_init+0xb8/0xe0 drivers/media/usb/em28xx/em28xx-dvb.c:2062
 em28xx_init_extension+0x11a/0x190 drivers/media/usb/em28xx/em28xx-core.c:1110
 request_module_async+0x6a/0x80 drivers/media/usb/em28xx/em28xx-cards.c:3161
 process_one_work+0x944/0x15f0 kernel/workqueue.c:2112
 worker_thread+0xef/0x10d0 kernel/workqueue.c:2246
 kthread+0x367/0x420 kernel/kthread.c:238
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:437

Freed by task 3182:
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
 slab_free_hook mm/slub.c:1391
 slab_free_freelist_hook mm/slub.c:1412
 slab_free mm/slub.c:2968
 kfree+0xf2/0x2e0 mm/slub.c:3899
 tc90522_remove+0x4b/0x60 drivers/media/dvb-frontends/tc90522.c:814
 i2c_device_remove+0xc8/0x120 drivers/i2c/i2c-core-base.c:438
 __device_release_driver drivers/base/dd.c:868
 device_release_driver_internal+0x34e/0x630 drivers/base/dd.c:903
 device_release_driver+0x1e/0x30 drivers/base/dd.c:928
 bus_remove_device+0x2fc/0x4b0 drivers/base/bus.c:565
 device_del+0x39f/0xa70 drivers/base/core.c:1984
 device_unregister+0x1a/0x40 drivers/base/core.c:2020
 i2c_unregister_device.part.41+0xfd/0x130 drivers/i2c/i2c-core-base.c:828
 i2c_unregister_device+0x24/0x30 drivers/i2c/i2c-core-base.c:822

[PATCH] [media] stb0899: remove redundant self assignment of k_indirect

2017-11-21 Thread Colin King

From: Colin Ian King 

The self assignment of k_indirect is redundant and can be removed.
Detected using coccinelle.

Signed-off-by: Colin Ian King 
---
 drivers/media/dvb-frontends/stb0899_algo.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/stb0899_algo.c 
b/drivers/media/dvb-frontends/stb0899_algo.c
index 3012f196e9bd..222ee51b90ef 100644
--- a/drivers/media/dvb-frontends/stb0899_algo.c
+++ b/drivers/media/dvb-frontends/stb0899_algo.c
@@ -925,8 +925,7 @@ static void stb0899_dvbs2_set_btr_loopbw(struct 
stb0899_state *state)
wn = (4 * zeta * zeta) + 100;
wn = (2 * (loopbw_percent * 1000) * 40 * zeta) /wn;  /*wn =wn 
10^-8*/
 
-   k_indirect = (wn * wn) / K;
-   k_indirect = k_indirect;  /*kindirect = kindirect 
10^-6*/
+   k_indirect = (wn * wn) / K; /*kindirect = kindirect 10^-6*/
k_direct   = (2 * wn * zeta) / K;   /*kDirect = kDirect 
10^-2*/
k_direct  *= 100;
 
-- 
2.14.1

iMX6q/coda encoder failures with ffmpeg/gstreamer m2m encoders

2017-11-21 Thread Neil Armstrong

Hi,

I'm trying to make the coda960 h.264 encoder work on an i.MX6q SoC with Linux 
4.14 and the 3.1.1 firmware.

# dmesg | grep coda
[4.846574] coda 204.vpu: Direct firmware load for vpu_fw_imx6q.bin 
failed with error -2
[4.901351] coda 204.vpu: Using fallback firmware vpu/vpu_fw_imx6q.bin
[4.916039] coda 204.vpu: Firmware code revision: 46072
[4.921641] coda 204.vpu: Initialized CODA960.
[4.926589] coda 204.vpu: Firmware version: 3.1.1
[4.932223] coda 204.vpu: codec registered as /dev/video[8-9]

Using gstreamer-plugins-good and the m2m v4l2 encoder, I have :

# gst-launch-1.0 videotestsrc num-buffers=1000 pattern=snow ! video/x-raw, 
framerate=30/1, width=1280, height=720 ! v4l2h264enc ! h264parse ! mp4mux ! 
filesink location=/dev/null
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
[ 1569.473717] coda 204.vpu: coda_s_fmt queue busy
ERROR: from element /GstPipeline:pipeline0/v4l2h264enc:v4l2h264enc0: Device 
'/dev/video8' is busy
Additional debug info:
../../../gst-plugins-good-1.12.3/sys/v4l2/gstv4l2object.c(3609): 
gst_v4l2_object_set_format_full (): 
/GstPipeline:pipeline0/v4l2h264enc:v4l2h264enc0:
Call to S_FMT failed for YU12 @ 1280x720: Device or resource busy
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

And with ffmpeg :

# ffmpeg -f lavfi -i nullsrc=s=1280x720:d=5 -vf "geq=random(1)*255:128:128" 
-vcodec h264_v4l2m2m -f null -
Input #0, lavfi, from 'nullsrc=s=1280x720:d=5':
  Duration: N/A, start: 0.00, bitrate: N/A
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1280x720 [SAR 
1:1 DAR 16:9], 25 tbr, 25 tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (h264_v4l2m2m))
Press [q] to stop, [?] for help
[h264_v4l2m2m @ 0x146f700] driver 'coda' on card 'CODA960'
Last message repeated 1 times
[h264_v4l2m2m @ 0x146f700] Using device /dev/video8
[h264_v4l2m2m @ 0x146f700] driver 'coda' on card 'CODA960'
[h264_v4l2m2m @ 0x146f700] Failed to set number of B-frames
Last message repeated 1 times
[h264_v4l2m2m @ 0x146f700] Failed to set header mode
[h264_v4l2m2m @ 0x146f700] h264 profile not found
[h264_v4l2m2m[  787.690832] coda 204.vpu: CODA_COMMAND_SEQ_INIT failed
 @ 0x146f700] Encoder adjusted: qmin (0), qmax (51)
[h264_v4l2m2m @ 0x146f700] Failed to set minimum video quantizer scale
Output #0, null, to 'pipe:':
  Metadata:
encoder : Lavf57.71.100
Stream #0:0: Video: h264 (h264_v4l2m2m), yuv420p, 1280x720 [SAR 1:1 DAR 
16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
Metadata:
  encoder : Lavc57.89.100 h264_v4l2m2m
[h264_v4l2m2m @ 0x146f700] output  POLLERR
[h264_v4l2m2m @ 0x146f700] VIDIOC_STREAMON failed on capture context
Video encoding failed

Decoder iws working OK with gstreamer, but fails to allocate memory with ffmpeg 
(unrelated).

Is there missing patches to make encoder work, or some specific parameters  ?

Thanks,
Neil

-- 
Neil Armstrong
Embedded Linux Software Engineer
BayLibre - At the Heart of Embedded Linux
www.baylibre.com

Re: [PATCH] [media] c8sectpfe: Use resource_size function on memory resource

2017-11-21 Thread Patrice CHOTARD

Hi Vasyl

On 11/20/2017 11:46 PM, Vasyl Gomonovych wrote:
> To adapt fei->sram_size calculation via resource_size for memory size
> calculation before, in fei->sram = devm_ioremap_resource(dev, res).
> And make memory initialization range in
> memset_io for fei->sram appropriate
> 
> Signed-off-by: Vasyl Gomonovych 
> ---
>   drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c 
> b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> index 59280ac31937..283f7289aaa1 100644
> --- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> +++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> @@ -691,7 +691,7 @@ static int c8sectpfe_probe(struct platform_device *pdev)
>   if (IS_ERR(fei->sram))
>   return PTR_ERR(fei->sram);
>   
> - fei->sram_size = res->end - res->start;
> + fei->sram_size = resource_size(res);
>   
>   fei->idle_irq = platform_get_irq_byname(pdev, "c8sectpfe-idle-irq");
>   if (fei->idle_irq < 0) {
> 

Acked-by: Patrice Chotard 

Thanks

Re: [PATCH] c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt

2017-11-21 Thread Patrice CHOTARD

Hi Gustavo

On 11/20/2017 03:00 PM, Gustavo A. R. Silva wrote:
> _channel_ is being dereferenced before it is null checked, hence there is a
> potential null pointer dereference. Fix this by moving the pointer dereference
> after _channel_ has been null checked.
> 
> This issue was detected with the help of Coccinelle.
> 
> Fixes: c5f5d0f99794 ("[media] c8sectpfe: STiH407/10 Linux DVB demux support")
> Signed-off-by: Gustavo A. R. Silva 
> ---
>   drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c 
> b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> index 59280ac..23d0ced 100644
> --- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> +++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c
> @@ -83,7 +83,7 @@ static void c8sectpfe_timer_interrupt(unsigned long 
> ac8sectpfei)
>   static void channel_swdemux_tsklet(unsigned long data)
>   {
>   struct channel_info *channel = (struct channel_info *)data;
> - struct c8sectpfei *fei = channel->fei;
> + struct c8sectpfei *fei;
>   unsigned long wp, rp;
>   int pos, num_packets, n, size;
>   u8 *buf;
> @@ -91,6 +91,8 @@ static void channel_swdemux_tsklet(unsigned long data)
>   if (unlikely(!channel || !channel->irec))
>   return;
>   
> + fei = channel->fei;
> +
>   wp = readl(channel->irec + DMA_PRDS_BUSWP_TP(0));
>   rp = readl(channel->irec + DMA_PRDS_BUSRP_TP(0));
>   
> 

Acked-by: Patrice Chotard 

Thanks

Re: [PATCH] media: mtk-vcodec: add missing MODULE_LICENSE/DESCRIPTION

Re: [PATCH] media: mtk-vcodec: add missing MODULE_LICENSE/DESCRIPTION

Re: [PATCH 2/5] media: dt-bindings: Add bindings for TDA1997X

[PATCH 23/30] [media] atomisp: deprecate pci_get_bus_and_slot()

cron job: media_tree daily build: WARNINGS

Re: [PATCH v4 00/12] [dt-bindings] [media] Add document file and driver for Sony CXD2880 DVB-T2/T tuner + demodulator

Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

Re: 'LITE-ON USB2.0 DVB-T Tune' driver crash with kernel 4.13 / ubuntu 17.10

Hi Dear

Re: 'LITE-ON USB2.0 DVB-T Tune' driver crash with kernel 4.13 / ubuntu 17.10

Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2 receiver

[PATCH] media: imon: auto-config ffdc 30 device

Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2 receiver

Re: [PATCH v3 2/4] [media] dt-bindings: Document BCM283x CSI2/CCP2 receiver

Re: [PATCH] media: rc: double keypresses due to timeout expiring to early

Re: [PATCH v4 04/12] intel-ipu3: Add user space ABI definitions

Re: [PATCH] reservation: don't wait when timeout=0

Re: [PATCH] reservation: don't wait when timeout=0

Re: [PATCH] reservation: don't wait when timeout=0

Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

Re: [PATCH 1/2] drivers/video/hdmi: allow for larger-than-needed vendor IF

[PATCH] [media] dvb-frontends/stv0367: remove redundant self assignment of temporary

Re: [PATCH] reservation: don't wait when timeout=0

Re: [PATCH] reservation: don't wait when timeout=0

Re: [PATCH] reservation: don't wait when timeout=0

[PATCH] reservation: don't wait when timeout=0

usb/media/em28xx: use-after-free in dvb_unregister_frontend

[PATCH] [media] stb0899: remove redundant self assignment of k_indirect

iMX6q/coda encoder failures with ffmpeg/gstreamer m2m encoders

Re: [PATCH] [media] c8sectpfe: Use resource_size function on memory resource

Re: [PATCH] c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt

31 matches

Site Navigation

Mail list logo

Footer information