Re: [PATCH v7 00/16] Intel IPU3 ImgU patchset

[Sakari Ailus]

Hi Laurent,

On Fri, Nov 30, 2018 at 01:09:37AM +0200, Laurent Pinchart wrote:
> Hi Sakari,
> 
> 
> On Friday, 9 November 2018 12:09:54 EET Sakari Ailus wrote:
> > On Wed, Nov 07, 2018 at 12:16:47PM +0800, Bing Bu Cao wrote:
> > > On 11/01/2018 08:03 PM, Sakari Ailus wrote:
> > >> On Mon, Oct 29, 2018 at 03:22:54PM -0700, Yong Zhi wrote:
> 
> [snip]
> 
> > >>> ImgU media topology print:
> > >>> 
> > >>> # media-ctl -d /dev/media0 -p
> > >>> Media controller API version 4.19.0
> > >>> 
> > >>> Media device information
> > >>> 
> > >>> driver  ipu3-imgu
> > >>> model   ipu3-imgu
> > >>> serial
> > >>> bus infoPCI::00:05.0
> > >>> hw revision 0x80862015
> > >>> driver version  4.19.0
> > >>> 
> > >>> Device topology
> > >>> - entity 1: ipu3-imgu 0 (5 pads, 5 links)
> > >>> type V4L2 subdev subtype Unknown flags 0
> > >>> device node name /dev/v4l-subdev0
> > >>> pad0: Sink
> > >>> [fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown
> > >> 
> > >> This doesn't seem right. Which formats can be enumerated from the pad?
> > 
> > Looking at the code, the OUTPUT video nodes have 10-bit GRBG (or a variant)
> > format whereas the CAPTURE video nodes always have NV12. Can you confirm?
> > 
> > If the OUTPUT video node format selection has no effect on the rest of the
> > pipeline (device capabilities, which processing blocks are in use, CAPTURE
> > video nodes formats etc.), I think you could simply use the FIXED media bus
> > code for each pad. That would actually make sense: this device always works
> > from memory to memory, and thus does not really have a pixel data bus
> > external to the device which is what the media bus codes really are for.
> 
> Isn't the Bayer variant useful information to configure debayering ? I would 
> expect it to be passed through the format on pad 0.

That's already configured on the video node. The FIXED media bus code is
intended for links where there's nothing to configure --- which is the case
here.

-- 
Regards,

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

Re: [PATCH 2/3] media: stkwebcam: Bugfix for not correctly initialized camera

[Andreas Pape]

Hi Kieran,

thanks for the review.

On Mon, 26 Nov 2018 12:48:08 +
Kieran Bingham  wrote:

> This one worries me a little... (but hopefully not too much)
>

As mentioned, I don't have any experience concerning video drivers;-). I found
this patch more or less experimentally
 
> 
> > Signed-off-by: Andreas Pape 
> > ---
> >  drivers/media/usb/stkwebcam/stk-webcam.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c 
> > b/drivers/media/usb/stkwebcam/stk-webcam.c
> > index e61427e50525..c64928e36a5a 100644
> > --- a/drivers/media/usb/stkwebcam/stk-webcam.c
> > +++ b/drivers/media/usb/stkwebcam/stk-webcam.c
> > @@ -1155,6 +1155,8 @@ static int stk_vidioc_streamon(struct file *filp,
> > if (dev->sio_bufs == NULL)
> > return -EINVAL;
> > dev->sequence = 0;
> > +   stk_initialise(dev);
> > +   stk_setup_format(dev);
> 
> Glancing through the code base - this seems to imply to me that s_fmt
> was not set/called (presumably by cheese) as stk_setup_format() is
> called only by stk_vidioc_s_fmt_vid_cap() and stk_camera_resume().
> 
> Is this an issue?
> 
> I presume that this means the camera will just operate in a default
> configuration until cheese chooses something more specific.
>

Could be. I had a video but colours, sensitivity and possibly other things
were crap or at least very "psychedelic". Therefore the idea came up that
some kind of initialisation was missing here. 

> Actually - looking further this seems to be the case, as the mode is
> simply stored in dev->vsettings.mode, and so this last setup stage will
> just ensure the configuration of the hardware matches the driver.
> 
> So it seems reasonable to me - but should it be set any earlier?
> Perhaps not.
> 
> 
> Are there any complaints when running v4l2-compliance on this device node?
> 

Here is the output of v4l2-compliance:

v4l2-compliance SHA   : not available

Driver Info:
Driver name   : stk
Card type : stk
Bus info  : usb-:00:1d.7-5
Driver version: 4.15.18
Capabilities  : 0x8521
Video Capture
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0521
Video Capture
Read/Write
Streaming
Extended Pix Format

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Test input 0:

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 4 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
warn: v4l2-test-formats.cpp(732): TRY_FMT cannot handle an 
invalid pixelformat.
warn: v4l2-test-formats.cpp(733): This may or may not be a 
problem. For more information see:
warn: v4l2-test-formats.cpp(734): 
http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html
test VIDIOC_TRY_FMT: OK
warn: v4l2-test-formats.cpp(997): S_FMT cannot handle an 
invalid pixelformat.
warn: v4l2-test-formats.cpp(998): This may or may not be a 
problem. For more information see:
  

Re: [PATCH 1/3] media: stkwebcam: Support for ASUS A6VM notebook added.

[Andreas Pape]

Hi Keiran,

thanks for the review.

On Mon, 26 Nov 2018 12:48:53 +
Kieran Bingham  wrote:

> 
> I guess these strings match the strings produced by dmi-decode on your
> laptop?
>

I didn't use dmidecode but I read the values from /sys/class/dmi/sys_vendor and
/sys/class/dmi/product_name accordingly.

Kind regards,
Andreas

[PATCH] media: venus: Add support for H265 controls required by gstreamer V4L2 H265 module

[Kelvin Lawson]

Add support for V4L2_CID_MPEG_VIDEO_HEVC_PROFILE and
V4L2_CID_MPEG_VIDEO_HEVC_LEVEL controls required by gstreamer V4L2 H265
encoder module.

Signed-off-by: Kelvin Lawson 
---
 drivers/media/platform/qcom/venus/venc_ctrls.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c 
b/drivers/media/platform/qcom/venus/venc_ctrls.c
index 45910172..ad1a4d8 100644
--- a/drivers/media/platform/qcom/venus/venc_ctrls.c
+++ b/drivers/media/platform/qcom/venus/venc_ctrls.c
@@ -101,6 +101,9 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
ctr->profile.h264 = ctrl->val;
break;
+   case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
+   ctr->profile.hevc = ctrl->val;
+   break;
case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
ctr->profile.vpx = ctrl->val;
break;
@@ -110,6 +113,9 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_H264_LEVEL:
ctr->level.h264 = ctrl->val;
break;
+   case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
+   ctr->level.hevc = ctrl->val;
+   break;
case V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP:
ctr->h264_i_qp = ctrl->val;
break;
@@ -217,6 +223,19 @@ int venc_ctrl_init(struct venus_inst *inst)
0, V4L2_MPEG_VIDEO_MPEG4_LEVEL_0);
 
v4l2_ctrl_new_std_menu(&inst->ctrl_handler, &venc_ctrl_ops,
+   V4L2_CID_MPEG_VIDEO_HEVC_PROFILE,
+   V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_10,
+   ~((1 << V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN) |
+ (1 << V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE) |
+ (1 << V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_10)),
+   V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN);
+
+   v4l2_ctrl_new_std_menu(&inst->ctrl_handler, &venc_ctrl_ops,
+   V4L2_CID_MPEG_VIDEO_HEVC_LEVEL,
+   V4L2_MPEG_VIDEO_HEVC_LEVEL_6_2,
+   0, V4L2_MPEG_VIDEO_HEVC_LEVEL_1);
+
+   v4l2_ctrl_new_std_menu(&inst->ctrl_handler, &venc_ctrl_ops,
V4L2_CID_MPEG_VIDEO_H264_PROFILE,
V4L2_MPEG_VIDEO_H264_PROFILE_MULTIVIEW_HIGH,
~((1 << V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE) |
-- 
2.7.4

[PATCH v11 1/4] media: dt-bindings: Document the Rockchip VPU bindings

[Ezequiel Garcia]

Add devicetree binding documentation for Rockchip Video Processing
Unit IP.

Reviewed-by: Rob Herring 
Signed-off-by: Ezequiel Garcia 
---
 .../bindings/media/rockchip-vpu.txt   | 29 +++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rockchip-vpu.txt

diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.txt 
b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
new file mode 100644
index ..35dc464ad7c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
@@ -0,0 +1,29 @@
+device-tree bindings for rockchip VPU codec
+
+Rockchip (Video Processing Unit) present in various Rockchip platforms,
+such as RK3288 and RK3399.
+
+Required properties:
+- compatible: value should be one of the following
+   "rockchip,rk3288-vpu";
+   "rockchip,rk3399-vpu";
+- interrupts: encoding and decoding interrupt specifiers
+- interrupt-names: should be "vepu" and "vdpu"
+- clocks: phandle to VPU aclk, hclk clocks
+- clock-names: should be "aclk" and "hclk"
+- power-domains: phandle to power domain node
+- iommus: phandle to a iommu node
+
+Example:
+SoC-specific DT entry:
+   vpu: video-codec@ff9a {
+   compatible = "rockchip,rk3288-vpu";
+   reg = <0x0 0xff9a 0x0 0x800>;
+   interrupts = ,
+;
+   interrupt-names = "vepu", "vdpu";
+   clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>;
+   clock-names = "aclk", "hclk";
+   power-domains = <&power RK3288_PD_VIDEO>;
+   iommus = <&vpu_mmu>;
+   };
-- 
2.20.0.rc1

[PATCH v11 0/4] Add Rockchip VPU JPEG encoder

[Ezequiel Garcia]

Nothing like sending a new round on a Friday,
so people can test and review during the weekend! ;-)

As before, this series is based on Mauro's master branch,
with the following patch applied:

https://patchwork.kernel.org/patch/10676149/

On this new round, I've addressed all the feedback
provided by Tomasz on v10.

As always, any additional feedback is well received.

This patchset has been tested on RK3288 and RK3399
using bleeding-edge Gstreamer, with these pipelines:

function gst_kms {
gst-launch-1.0 -v videotestsrc num-buffers=${4} ! 
video/x-raw,width=${1},height=${2},format=${3}! v4l2jpegenc 
extra-controls="c,compression_quality=100" ! jpegdec ! videoconvert ! 
video/x-raw,format=BGRx ! queue leaky=1 ! kmssink sync=0
}

gst_kms 640 480 YUY2 30
gst_kms 640 480 NV12 30
gst_kms 640 480 I420 30
(and more sizes)

There are a few warnings after running check_patch.pl --strict,
but I've chosen not to address them, as it would reducely
readability.

Also, v4l2-compliance -s passes on both platforms, as has
been the case for the past submissions.

v11:
 * Update TODO file
 * Make macroblock alignment codec specific
 * Rename VEPU_REG_ADDR_IN_LUMA,CR,CB to
   VEPU_REG_ADDR_IN_PLANE_0,12,
 * Only write plane address (VEPU_REG_ADDR_IN_PLANE_0,1,2)
   when needed.
 * s/rockchip_vpu_jpeg_render/rockchip_vpu_jpeg_header_assemble
 * Drop wmb() and use a writel, which has an implicit barrier.
 * Added missing documentation for all structs.
 * Removed unused struct fields.
 * Simplified xfer_func et al usage.
 * Reworked vepu_debug for i/o
 * Explicitly enabled/disabled clocks before/after work,
   instead of via the PM runtime infra.
 * Copy buffer timecode only when required 
 * Bound check the amount of bytes transferred by the hardware.
 * Remove useless void * cast.
 * Fix race condition between top half and watchdog .
 * Drop redundant check for v4l2_ctrl errors.
 * Add rounding up in fill_fmt helpers.
 * Remove unneeded DMA alignment implementation (needed only for
 * USERPTR).
 * Add check for different width and height in CAPTURE S_FMT.
 * Remove check for peer busy queue in OUTPUT S_FMT.
 * Remove double whitespace.
 * Multi-line comments fixed.
 * Google copyright fixed.
 * Typos fixed.

v10:
 * Fix SPDX syntax
 * Add missing patch with binding documentation
 * Remove white line in Kconfig

v9:
 * Address some style comments from Hans.
 * Fix TODO file

v8:
 * Drop new JPEG_RAW format.
 * Drop quantization table user controls.
 * Add JPEG headers to produce JPEG frames.

Ezequiel Garcia (4):
  media: dt-bindings: Document the Rockchip VPU bindings
  ARM: dts: rockchip: add VPU device node for RK3288
  arm64: dts: rockchip: add VPU device node for RK3399
  media: add Rockchip VPU JPEG encoder driver

 .../bindings/media/rockchip-vpu.txt   |  29 +
 MAINTAINERS   |   7 +
 arch/arm/boot/dts/rk3288.dtsi |  14 +-
 arch/arm64/boot/dts/rockchip/rk3399.dtsi  |  14 +-
 drivers/staging/media/Kconfig |   2 +
 drivers/staging/media/Makefile|   1 +
 drivers/staging/media/rockchip/vpu/Kconfig|  13 +
 drivers/staging/media/rockchip/vpu/Makefile   |  10 +
 drivers/staging/media/rockchip/vpu/TODO   |  13 +
 .../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++
 .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 130 
 .../media/rockchip/vpu/rk3288_vpu_regs.h  | 442 
 .../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++
 .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 164 +
 .../media/rockchip/vpu/rk3399_vpu_regs.h  | 600 
 .../staging/media/rockchip/vpu/rockchip_vpu.h | 232 ++
 .../media/rockchip/vpu/rockchip_vpu_common.h  |  29 +
 .../media/rockchip/vpu/rockchip_vpu_drv.c | 531 ++
 .../media/rockchip/vpu/rockchip_vpu_enc.c | 676 ++
 .../media/rockchip/vpu/rockchip_vpu_hw.h  |  58 ++
 .../media/rockchip/vpu/rockchip_vpu_jpeg.c| 290 
 .../media/rockchip/vpu/rockchip_vpu_jpeg.h|  14 +
 22 files changed, 3503 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/rockchip-vpu.txt
 create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig
 create mode 100644 drivers/staging/media/rockchip/vpu/Makefile
 create mode 100644 drivers/staging/media/rockchip/vpu/TODO
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h
 create mode 100644 drivers/stagin

[PATCH v11 3/4] arm64: dts: rockchip: add VPU device node for RK3399

[Ezequiel Garcia]

Add the Video Processing Unit node for the RK3399 SoC.

Also, fix the VPU IOMMU node, which was disabled and lacking
its power domain property.

Reviewed-by: Tomasz Figa 
Signed-off-by: Ezequiel Garcia 
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 99e7f65c1779..040d3080565f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1226,6 +1226,18 @@
status = "disabled";
};
 
+   vpu: video-codec@ff65 {
+   compatible = "rockchip,rk3399-vpu";
+   reg = <0x0 0xff65 0x0 0x800>;
+   interrupts = ,
+;
+   interrupt-names = "vepu", "vdpu";
+   clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>;
+   clock-names = "aclk", "hclk";
+   power-domains = <&power RK3399_PD_VCODEC>;
+   iommus = <&vpu_mmu>;
+   };
+
vpu_mmu: iommu@ff650800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff650800 0x0 0x40>;
@@ -1233,8 +1245,8 @@
interrupt-names = "vpu_mmu";
clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>;
clock-names = "aclk", "iface";
+   power-domains = <&power RK3399_PD_VCODEC>;
#iommu-cells = <0>;
-   status = "disabled";
};
 
vdec_mmu: iommu@ff660480 {
-- 
2.20.0.rc1

[PATCH v11 2/4] ARM: dts: rockchip: add VPU device node for RK3288

[Ezequiel Garcia]

Add the Video Processing Unit node for RK3288 SoC.

Fix the VPU IOMMU node, which was disabled and lacking
its power domain property.

Reviewed-by: Tomasz Figa 
Signed-off-by: Ezequiel Garcia 
---
 arch/arm/boot/dts/rk3288.dtsi | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 0840ffb3205c..40d203cdca09 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1223,6 +1223,18 @@
};
};
 
+   vpu: video-codec@ff9a {
+   compatible = "rockchip,rk3288-vpu";
+   reg = <0x0 0xff9a 0x0 0x800>;
+   interrupts = ,
+;
+   interrupt-names = "vepu", "vdpu";
+   clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>;
+   clock-names = "aclk", "hclk";
+   power-domains = <&power RK3288_PD_VIDEO>;
+   iommus = <&vpu_mmu>;
+   };
+
vpu_mmu: iommu@ff9a0800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff9a0800 0x0 0x100>;
@@ -1230,8 +1242,8 @@
interrupt-names = "vpu_mmu";
clocks = <&cru ACLK_VCODEC>, <&cru HCLK_VCODEC>;
clock-names = "aclk", "iface";
+   power-domains = <&power RK3288_PD_VIDEO>;
#iommu-cells = <0>;
-   status = "disabled";
};
 
hevc_mmu: iommu@ff9c0440 {
-- 
2.20.0.rc1

[PATCH v11 4/4] media: add Rockchip VPU JPEG encoder driver

[Ezequiel Garcia]

Add a mem2mem driver for the VPU available on Rockchip SoCs.
Currently only JPEG encoding is supported, for RK3399 and RK3288
platforms.

Signed-off-by: Ezequiel Garcia 
---
 MAINTAINERS   |   7 +
 drivers/staging/media/Kconfig |   2 +
 drivers/staging/media/Makefile|   1 +
 drivers/staging/media/rockchip/vpu/Kconfig|  13 +
 drivers/staging/media/rockchip/vpu/Makefile   |  10 +
 drivers/staging/media/rockchip/vpu/TODO   |  13 +
 .../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++
 .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 130 
 .../media/rockchip/vpu/rk3288_vpu_regs.h  | 442 
 .../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++
 .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 164 +
 .../media/rockchip/vpu/rk3399_vpu_regs.h  | 600 
 .../staging/media/rockchip/vpu/rockchip_vpu.h | 232 ++
 .../media/rockchip/vpu/rockchip_vpu_common.h  |  29 +
 .../media/rockchip/vpu/rockchip_vpu_drv.c | 531 ++
 .../media/rockchip/vpu/rockchip_vpu_enc.c | 676 ++
 .../media/rockchip/vpu/rockchip_vpu_hw.h  |  58 ++
 .../media/rockchip/vpu/rockchip_vpu_jpeg.c| 290 
 .../media/rockchip/vpu/rockchip_vpu_jpeg.h|  14 +
 19 files changed, 3448 insertions(+)
 create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig
 create mode 100644 drivers/staging/media/rockchip/vpu/Makefile
 create mode 100644 drivers/staging/media/rockchip/vpu/TODO
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c
 create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 2894fb9893a6..a86a0cd90514 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12748,6 +12748,13 @@ S: Maintained
 F: drivers/media/platform/rockchip/rga/
 F: Documentation/devicetree/bindings/media/rockchip-rga.txt
 
+ROCKCHIP VPU CODEC DRIVER
+M: Ezequiel Garcia 
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/staging/media/platform/rockchip/vpu/
+F: Documentation/devicetree/bindings/media/rockchip-vpu.txt
+
 ROCKER DRIVER
 M: Jiri Pirko 
 L: net...@vger.kernel.org
diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig
index b3620a8f2d9f..c6f3404dea43 100644
--- a/drivers/staging/media/Kconfig
+++ b/drivers/staging/media/Kconfig
@@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig"
 
 source "drivers/staging/media/omap4iss/Kconfig"
 
+source "drivers/staging/media/rockchip/vpu/Kconfig"
+
 source "drivers/staging/media/sunxi/Kconfig"
 
 source "drivers/staging/media/tegra-vde/Kconfig"
diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile
index 42948f805548..43c7bee1fc8c 100644
--- a/drivers/staging/media/Makefile
+++ b/drivers/staging/media/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_VIDEO_OMAP4)   += omap4iss/
 obj-$(CONFIG_VIDEO_SUNXI)  += sunxi/
 obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/
 obj-$(CONFIG_VIDEO_ZORAN)  += zoran/
+obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/
diff --git a/drivers/staging/media/rockchip/vpu/Kconfig 
b/drivers/staging/media/rockchip/vpu/Kconfig
new file mode 100644
index ..9a6fc1378242
--- /dev/null
+++ b/drivers/staging/media/rockchip/vpu/Kconfig
@@ -0,0 +1,13 @@
+config VIDEO_ROCKCHIP_VPU
+   tristate "Rockchip VPU driver"
+   depends on ARCH_ROCKCHIP || COMPILE_TEST
+   depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER
+   select VIDEOBUF2_DMA_CONTIG
+   select VIDEOBUF2_VMALLOC
+   select V4L2_MEM2MEM_DEV
+   default n
+   help
+ Support for the Video Processing Unit present on Rockchip SoC,
+ which accelerates video and image encoding and decoding.
+ To compile this driver as a module, choose M here: the module
+ will be called rockchip-vpu.
diff --git a/drivers/staging/media/rockchip/vpu/Makefile 
b/drivers/staging/media/rockchip/vpu/Makefile
new file mode 100644
index ..e9d733bb7632
--- /dev/null
+++ b/drivers/staging/media/rockchip/vpu/Makefile
@@ -0,0 +1,10 @@
+obj-$(CON

Re: [PATCH] media: unify some sony camera sensors pattern naming

[Tomasz Figa]

Hi Bingbu,

On Mon, Nov 26, 2018 at 7:56 PM  wrote:
>
> From: Bingbu Cao 
>
> Some Sony camera sensors have same test pattern
> definitions, this patch unify the pattern naming
> to make it more clear to the userspace.
>
> Suggested-by: Sakari Ailus 
> Signed-off-by: Bingbu Cao 
> ---
>  drivers/media/i2c/imx258.c | 8 
>  drivers/media/i2c/imx319.c | 8 
>  drivers/media/i2c/imx355.c | 8 
>  3 files changed, 12 insertions(+), 12 deletions(-)
>

Thanks for the patch! One comment inline.

> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> index 31a1e2294843..a8a2880c6b4e 100644
> --- a/drivers/media/i2c/imx258.c
> +++ b/drivers/media/i2c/imx258.c
> @@ -504,10 +504,10 @@ struct imx258_mode {
>
>  static const char * const imx258_test_pattern_menu[] = {
> "Disabled",
> -   "Color Bars",
> -   "Solid Color",
> -   "Grey Color Bars",
> -   "PN9"
> +   "Solid Colour",
> +   "Eight Vertical Colour Bars",

Is it just me or "solid color" and "color bars" are being swapped
here? Did the driver had the names mixed up before or the order of
modes is different between these sensors?

Best regards,
Tomasz

E-mail Contact.

[Lehmann Schulz]

Hello, have you study the project proposal i sent you?

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

cron job: media_tree daily build: OK

[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:   Sat Dec  1 05:00:11 CET 2018
media-tree git hash:708d75fe1c7c6e9abc5381b6fcc32b49830383d0
media_build git hash:   47bf46ff21f75d1fe4ae3275a8692cb6ff77b6e8
v4l-utils git hash: cff58fcfbdf75381d5351f5ea8e7846f59cb7905
edid-decode git hash:   5eeb151a748788666534d6ea3da07f90400d24c2
gcc version:i686-linux-gcc (GCC) 8.2.0
sparse version: 0.5.2
smatch version: 0.5.1
host hardware:  x86_64
host os:4.18.0-2-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: OK
linux-git-i686: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
Check COMPILE_TEST: OK
linux-3.10.108-i686: OK
linux-3.10.108-x86_64: OK
linux-3.11.10-i686: OK
linux-3.11.10-x86_64: OK
linux-3.12.74-i686: OK
linux-3.12.74-x86_64: OK
linux-3.13.11-i686: OK
linux-3.13.11-x86_64: OK
linux-3.14.79-i686: OK
linux-3.14.79-x86_64: OK
linux-3.15.10-i686: OK
linux-3.15.10-x86_64: OK
linux-3.16.57-i686: OK
linux-3.16.57-x86_64: OK
linux-3.17.8-i686: OK
linux-3.17.8-x86_64: OK
linux-3.18.123-i686: OK
linux-3.18.123-x86_64: OK
linux-3.19.8-i686: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.52-i686: OK
linux-4.1.52-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.159-i686: OK
linux-4.4.159-x86_64: OK
linux-4.5.7-i686: OK
linux-4.5.7-x86_64: OK
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: OK
linux-4.7.10-i686: OK
linux-4.7.10-x86_64: OK
linux-4.8.17-i686: OK
linux-4.8.17-x86_64: OK
linux-4.9.131-i686: OK
linux-4.9.131-x86_64: OK
linux-4.10.17-i686: OK
linux-4.10.17-x86_64: OK
linux-4.11.12-i686: OK
linux-4.11.12-x86_64: OK
linux-4.12.14-i686: OK
linux-4.12.14-x86_64: OK
linux-4.13.16-i686: OK
linux-4.13.16-x86_64: OK
linux-4.14.74-i686: OK
linux-4.14.74-x86_64: OK
linux-4.15.18-i686: OK
linux-4.15.18-x86_64: OK
linux-4.16.18-i686: OK
linux-4.16.18-x86_64: OK
linux-4.17.19-i686: OK
linux-4.17.19-x86_64: OK
linux-4.18.12-i686: OK
linux-4.18.12-x86_64: OK
linux-4.19.1-i686: OK
linux-4.19.1-x86_64: OK
linux-4.20-rc1-i686: OK
linux-4.20-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

[PATCH 2/6] media: sun6i: Add H3 compatible

[Chen-Yu Tsai]

The CSI controller found on the H3 (and H5) is a reduced version of the
one found on the A31. It only has 1 channel, instead of 4 channels for
time-multiplexed BT.656. Since the H3 is a reduced version, it cannot
"fallback" to a compatible that implements more features than it
supports.

Add a compatible string entry for the H3.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index 6950585edb5a..ee882b66a5ea 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -893,6 +893,7 @@ static int sun6i_csi_remove(struct platform_device *pdev)
 
 static const struct of_device_id sun6i_csi_of_match[] = {
{ .compatible = "allwinner,sun6i-a31-csi", },
+   { .compatible = "allwinner,sun8i-h3-csi", },
{ .compatible = "allwinner,sun8i-v3s-csi", },
{},
 };
-- 
2.20.0.rc1

[PATCH 5/6] [DO NOT MERGE] ARM: dts: sunxi: bananapi-m2p: Add HDF5640 camera module

[Chen-Yu Tsai]

The Bananapi M2+ comes with an optional sensor based on the ov5640 from
Omnivision. Enable the support for it in the DT.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi | 87 +++
 1 file changed, 87 insertions(+)

diff --git a/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi 
b/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi
index b3283aeb5b7d..d97a98acf378 100644
--- a/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi
+++ b/arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi
@@ -89,6 +89,42 @@
};
};
 
+   reg_cam_avdd: cam-avdd {
+   compatible = "regulator-fixed";
+   regulator-name = "csi-avdd";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   startup-delay-us = <200>; /* 50 us + board delays */
+   enable-active-high;
+   gpio = <&pio 3 14 GPIO_ACTIVE_HIGH>; /* PD14 */
+   };
+
+   reg_cam_dovdd: cam-dovdd {
+   compatible = "regulator-fixed";
+   regulator-name = "csi-dovdd";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   /*
+* This regulator also powers the pull-ups for the I2C bus.
+* For some reason, if this is turned off, subsequent use
+* of the I2C bus, even when turned on, does not work.
+*/
+   startup-delay-us = <200>; /* 50 us + board delays */
+   regulator-always-on;
+   enable-active-high;
+   gpio = <&pio 3 14 GPIO_ACTIVE_HIGH>; /* PD14 */
+   };
+
+   reg_cam_dvdd: cam-dvdd {
+   compatible = "regulator-fixed";
+   regulator-name = "csi-dvdd";
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   startup-delay-us = <200>; /* 50 us + board delays */
+   enable-active-high;
+   gpio = <&pio 3 14 GPIO_ACTIVE_HIGH>; /* PD14 */
+   };
+
reg_gmac_3v3: gmac-3v3 {
  compatible = "regulator-fixed";
  regulator-name = "gmac-3v3";
@@ -106,6 +142,26 @@
};
 };
 
+&csi {
+   status = "okay";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* Parallel bus endpoint */
+   csi_from_ov5640: endpoint {
+   remote-endpoint = <&ov5640_to_csi>;
+   bus-width = <8>;
+   data-shift = <2>;
+   hsync-active = <1>; /* Active high */
+   vsync-active = <0>; /* Active low */
+   data-active = <1>;  /* Active high */
+   pclk-sample = <1>;  /* Rising */
+   };
+   };
+};
+
 &de {
status = "okay";
 };
@@ -149,6 +205,37 @@
};
 };
 
+&i2c2 {
+   status = "okay";
+
+   ov5640: camera@3c {
+   compatible = "ovti,ov5640";
+   reg = <0x3c>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&csi_mclk_pin>;
+   clocks = <&ccu CLK_CSI_MCLK>;
+   clock-names = "xclk";
+
+   reset-gpios = <&pio 4 14 GPIO_ACTIVE_LOW>; /* PE14 */
+   powerdown-gpios = <&pio 4 15 GPIO_ACTIVE_HIGH>; /* PE15 */
+   AVDD-supply = <®_cam_avdd>;
+   DOVDD-supply = <®_cam_dovdd>;
+   DVDD-supply = <®_cam_dvdd>;
+
+   port {
+   ov5640_to_csi: endpoint {
+   remote-endpoint = <&csi_from_ov5640>;
+   bus-width = <8>;
+   data-shift = <2>;
+   hsync-active = <1>; /* Active high */
+   vsync-active = <0>; /* Active low */
+   data-active = <1>;  /* Active high */
+   pclk-sample = <1>;  /* Rising */
+   };
+   };
+   };
+};
+
 &ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
-- 
2.20.0.rc1

[PATCH 4/6] ARM: dts: sunxi: h3-h5: Add pinmux setting for CSI MCLK on PE1

[Chen-Yu Tsai]

Some camera modules have the SoC feeding a master clock to the sensor
instead of having a standalone crystal. This clock signal is generated
from the clock control unit and output from the CSI MCLK function of
pin PE1.

Add a pinmux setting for it for camera sensors to reference.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sunxi-h3-h5.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index c9c9ec71945f..b70899500825 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -400,6 +400,11 @@
function = "csi";
};
 
+   csi_mclk_pin: csi-mclk {
+   pins = "PE1";
+   function = "csi";
+   };
+
emac_rgmii_pins: emac0 {
pins = "PD0", "PD1", "PD2", "PD3", "PD4",
   "PD5", "PD7", "PD8", "PD9", "PD10",
-- 
2.20.0.rc1

[PATCH 3/6] ARM: dts: sunxi: h3/h5: Drop A31 fallback compatible for CSI controller

[Chen-Yu Tsai]

The CSI controller found on the H3 (and H5) is a reduced version of the
one found on the A31. It only has 1 channel, instead of 4 channels for
time-multiplexed BT.656. Since the H3 is a reduced version, it cannot
"fallback" to a compatible that implements more features than it
supports.

Drop the A31 fallback compatible.

Fixes: f89120b6f554 ("ARM: dts: sun8i: Add the H3/H5 CSI controller")
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sunxi-h3-h5.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 0d9e9eac518c..c9c9ec71945f 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -752,8 +752,7 @@
};
 
csi: camera@1cb {
-   compatible = "allwinner,sun8i-h3-csi",
-"allwinner,sun6i-a31-csi";
+   compatible = "allwinner,sun8i-h3-csi";
reg = <0x01cb 0x1000>;
interrupts = ;
clocks = <&ccu CLK_BUS_CSI>,
-- 
2.20.0.rc1

[PATCH 6/6] [DO NOT MERGE] ARM: dts: sunxi: libretech-all-h3-cc: Add HDF5640 camera module

[Chen-Yu Tsai]

The Libretech ALL-H3-CC is compatible with the Orange Pi's camera sensor
module. This module itself features a detachable camera sensor module
ribbon connector, which is populated with a GC2035 sensor by default.
The connector is also compatible with Bananapi's HDF5640 camera module,
which features an OV5640 sensor. The Orange Pi module however does not
activate the auto focus feature of the HDF5640 module.

Enable the camera by enabling the CSI controller, I2C control bus, and
adding needed regulator supplies. As the schematics for the module are
not available, the regulators and GPIO lines controlling them are just
an educated guess.

Signed-off-by: Chen-Yu Tsai 
---
 .../boot/dts/sunxi-libretech-all-h3-cc.dtsi   | 81 +++
 1 file changed, 81 insertions(+)

diff --git a/arch/arm/boot/dts/sunxi-libretech-all-h3-cc.dtsi 
b/arch/arm/boot/dts/sunxi-libretech-all-h3-cc.dtsi
index 1eadc132390c..3252e1af59cd 100644
--- a/arch/arm/boot/dts/sunxi-libretech-all-h3-cc.dtsi
+++ b/arch/arm/boot/dts/sunxi-libretech-all-h3-cc.dtsi
@@ -52,6 +52,36 @@
};
};
 
+   reg_cam_avdd: cam-avdd {
+   compatible = "regulator-fixed";
+   regulator-name = "csi-avdd";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   startup-delay-us = <200>; /* 50 us + board delays */
+   enable-active-high;
+   gpio = <&r_pio 0 0 GPIO_ACTIVE_HIGH>; /* PL0 */
+   };
+
+   reg_cam_dovdd: cam-dovdd {
+   compatible = "regulator-fixed";
+   regulator-name = "csi-dovdd";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   startup-delay-us = <200>; /* 50 us + board delays */
+   enable-active-high;
+   gpio = <&r_pio 0 0 GPIO_ACTIVE_HIGH>; /* PL0 */
+   };
+
+   reg_cam_dvdd: cam-dvdd {
+   compatible = "regulator-fixed";
+   regulator-name = "csi-dvdd";
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   startup-delay-us = <200>; /* 50 us + board delays */
+   enable-active-high;
+   gpio = <&r_pio 0 1 GPIO_ACTIVE_HIGH>; /* PL1 */
+   };
+
reg_vcc1v2: vcc1v2 {
compatible = "regulator-fixed";
regulator-name = "vcc1v2";
@@ -128,6 +158,26 @@
cpu-supply = <®_vdd_cpux>;
 };
 
+&csi {
+   status = "okay";
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* Parallel bus endpoint */
+   csi_from_ov5640: endpoint {
+   remote-endpoint = <&ov5640_to_csi>;
+   bus-width = <8>;
+   data-shift = <2>;
+   hsync-active = <1>; /* Active high */
+   vsync-active = <0>; /* Active low */
+   data-active = <1>;  /* Active high */
+   pclk-sample = <1>;  /* Rising */
+   };
+   };
+};
+
 &de {
status = "okay";
 };
@@ -165,6 +215,37 @@
};
 };
 
+&i2c2 {
+   status = "okay";
+
+   ov5640: camera@3c {
+   compatible = "ovti,ov5640";
+   reg = <0x3c>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&csi_mclk_pin>;
+   clocks = <&ccu CLK_CSI_MCLK>;
+   clock-names = "xclk";
+
+   powerdown-gpios = <&pio 4 14 GPIO_ACTIVE_HIGH>; /* PE14 */
+   reset-gpios = <&pio 4 15 GPIO_ACTIVE_LOW>; /* PE15 */
+   AVDD-supply = <®_cam_avdd>;
+   DOVDD-supply = <®_cam_dovdd>;
+   DVDD-supply = <®_cam_dvdd>;
+
+   port {
+   ov5640_to_csi: endpoint {
+   remote-endpoint = <&csi_from_ov5640>;
+   bus-width = <8>;
+   data-shift = <2>;
+   hsync-active = <1>; /* Active high */
+   vsync-active = <0>; /* Active low */
+   data-active = <1>;  /* Active high */
+   pclk-sample = <1>;  /* Rising */
+   };
+   };
+   };
+};
+
 &ir {
pinctrl-names = "default";
pinctrl-0 = <&ir_pins_a>;
-- 
2.20.0.rc1

[PATCH 1/6] media: dt-bindings: media: sun6i: Separate H3 compatible from A31

[Chen-Yu Tsai]

The CSI controller found on the H3 (and H5) is a reduced version of the
one found on the A31. It only has 1 channel, instead of 4 channels for
time-multiplexed BT.656. Since the H3 is a reduced version, it cannot
"fallback" to a compatible that implements more features than it
supports.

Split out the H3 compatible as a separate entry, with no fallback.

Fixes: b7eadaa3a02a ("media: dt-bindings: media: sun6i: Add A31 and H3
  compatibles")
Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/media/sun6i-csi.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt 
b/Documentation/devicetree/bindings/media/sun6i-csi.txt
index d4ab34f2240c..cc37cf7fd051 100644
--- a/Documentation/devicetree/bindings/media/sun6i-csi.txt
+++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
@@ -6,7 +6,7 @@ Allwinner V3s SoC features a CSI module(CSI1) with parallel 
interface.
 Required properties:
   - compatible: value must be one of:
 * "allwinner,sun6i-a31-csi"
-* "allwinner,sun8i-h3-csi", "allwinner,sun6i-a31-csi"
+* "allwinner,sun8i-h3-csi"
 * "allwinner,sun8i-v3s-csi"
   - reg: base address and size of the memory-mapped region.
   - interrupts: interrupt associated to this IP
-- 
2.20.0.rc1

[PATCH 0/6] media: sun6i: Separate H3 compatible from A31

[Chen-Yu Tsai]

The CSI (camera sensor interface) controller found on the H3 (and H5)
is a reduced version of the one found on the A31. It only has 1 channel,
instead of 4 channels supporting time-multiplexed BT.656 on the A31.
Since the H3 is a reduced version, it cannot "fallback" to a compatible
that implements more features than it supports.

This series separates support for the H3 variant from the A31 variant.

Patches 1 ~ 3 separate H3 CSI from A31 CSI in the bindings, driver, and
device tree, respectively.

Patch 4 adds a pinmux setting for the MCLK (master clock). Some camera
sensors use the master clock from the SoC instead of a standalone
crystal.

Patches 5 and 6 are examples of using a camera sensor with an SBC.
Since the modules are detachable, these changes should not be merged.
They should be implemented as overlays instead.

Please have a look.

In addition, I found that the first frame captured seems to always be
incomplete, with either parts cropped, out of position, or missing
color components.

Regards
ChenYu


Chen-Yu Tsai (6):
  media: dt-bindings: media: sun6i: Separate H3 compatible from A31
  media: sun6i: Add H3 compatible
  ARM: dts: sunxi: h3/h5: Drop A31 fallback compatible for CSI
controller
  ARM: dts: sunxi: h3-h5: Add pinmux setting for CSI MCLK on PE1
  [DO NOT MERGE] ARM: dts: sunxi: bananapi-m2p: Add HDF5640 camera
module
  [DO NOT MERGE] ARM: dts: sunxi: libretech-all-h3-cc: Add HDF5640
camera module

 .../devicetree/bindings/media/sun6i-csi.txt   |  2 +-
 arch/arm/boot/dts/sunxi-bananapi-m2-plus.dtsi | 87 +++
 arch/arm/boot/dts/sunxi-h3-h5.dtsi|  8 +-
 .../boot/dts/sunxi-libretech-all-h3-cc.dtsi   | 81 +
 .../platform/sunxi/sun6i-csi/sun6i_csi.c  |  1 +
 5 files changed, 176 insertions(+), 3 deletions(-)

-- 
2.20.0.rc1

[PATCH v3] media: cedrus: Remove global IRQ spin lock from the driver

[Paul Kocialkowski]

We initially introduced a spin lock to ensure that the VPU registers
are not accessed concurrently between our setup function and IRQ
handler. The V4L2 M2M API ensures that only one decoding job runs at a
time, so the interrupt signaling the end of decoding will not occur
while the next picture is being configured.

Spurious interrupts are taken care of in the handler, by checking that
we have a valid M2M context and a decoding status available before
marking the buffers as done.

In addition, holding a spin lock could be problematic if non-atomic
operations are required in the setup process for future codec support.

As a result, remove the global IRQ spin lock.

Signed-off-by: Paul Kocialkowski 
Acked-by: Maxime Ripard 
---
Changes since v2:
* Rebased on top of the next media tree.

Changes since v1:
* Reworked commit message as suggested by Maxime.

 drivers/staging/media/sunxi/cedrus/cedrus.c   |  1 -
 drivers/staging/media/sunxi/cedrus/cedrus.h   |  2 --
 drivers/staging/media/sunxi/cedrus/cedrus_dec.c   |  9 -
 drivers/staging/media/sunxi/cedrus/cedrus_hw.c| 13 +
 drivers/staging/media/sunxi/cedrus/cedrus_video.c |  5 -
 5 files changed, 1 insertion(+), 29 deletions(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index da790db450d2..edb04a696d70 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -279,7 +279,6 @@ static int cedrus_probe(struct platform_device *pdev)
dev->dec_ops[CEDRUS_CODEC_MPEG2] = &cedrus_dec_ops_mpeg2;
 
mutex_init(&dev->dev_mutex);
-   spin_lock_init(&dev->irq_lock);
 
ret = v4l2_device_register(&pdev->dev, &dev->v4l2_dev);
if (ret) {
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h 
b/drivers/staging/media/sunxi/cedrus/cedrus.h
index 3f61248c57ac..3acfdcf83691 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
@@ -105,8 +105,6 @@ struct cedrus_dev {
 
/* Device file mutex */
struct mutexdev_mutex;
-   /* Interrupt spinlock */
-   spinlock_t  irq_lock;
 
void __iomem*base;
 
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index e40180a33951..6c5e310a7cf7 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -28,7 +28,6 @@ void cedrus_device_run(void *priv)
struct cedrus_dev *dev = ctx->dev;
struct cedrus_run run = { 0 };
struct media_request *src_req;
-   unsigned long flags;
 
run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
@@ -39,8 +38,6 @@ void cedrus_device_run(void *priv)
if (src_req)
v4l2_ctrl_request_setup(src_req, &ctx->hdl);
 
-   spin_lock_irqsave(&ctx->dev->irq_lock, flags);
-
switch (ctx->src_fmt.pixelformat) {
case V4L2_PIX_FMT_MPEG2_SLICE:
run.mpeg2.slice_params = cedrus_find_control_data(ctx,
@@ -55,16 +52,10 @@ void cedrus_device_run(void *priv)
 
dev->dec_ops[ctx->current_codec]->setup(ctx, &run);
 
-   spin_unlock_irqrestore(&ctx->dev->irq_lock, flags);
-
/* Complete request(s) controls if needed. */
 
if (src_req)
v4l2_ctrl_request_complete(src_req, &ctx->hdl);
 
-   spin_lock_irqsave(&ctx->dev->irq_lock, flags);
-
dev->dec_ops[ctx->current_codec]->trigger(ctx);
-
-   spin_unlock_irqrestore(&ctx->dev->irq_lock, flags);
 }
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
index 493e65b17b30..243592a5425e 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
@@ -105,24 +105,17 @@ static irqreturn_t cedrus_irq(int irq, void *data)
struct vb2_v4l2_buffer *src_buf, *dst_buf;
enum vb2_buffer_state state;
enum cedrus_irq_status status;
-   unsigned long flags;
-
-   spin_lock_irqsave(&dev->irq_lock, flags);
 
ctx = v4l2_m2m_get_curr_priv(dev->m2m_dev);
if (!ctx) {
v4l2_err(&dev->v4l2_dev,
 "Instance released before the end of transaction\n");
-   spin_unlock_irqrestore(&dev->irq_lock, flags);
-
return IRQ_NONE;
}
 
status = dev->dec_ops[ctx->current_codec]->irq_status(ctx);
-   if (status == CEDRUS_IRQ_NONE) {
-   spin_unlock_irqrestore(&dev->irq_lock, flags);
+   if (status == CEDRUS_IRQ_NONE)
return IRQ_NONE;
-   }
 
dev->dec_ops[ctx->current_codec]->irq_disable(ctx);
dev->dec_ops[ctx->current_codec]->irq_clear(ctx);
@@ -133,8 +126,6 @@ static irqreturn_t cedrus_irq(int irq, void *data)
if (!src_buf || 

Re: [PATCH 0/6] media: sun6i: Separate H3 compatible from A31

[Maxime Ripard]

On Fri, Nov 30, 2018 at 03:58:43PM +0800, Chen-Yu Tsai wrote:
> The CSI (camera sensor interface) controller found on the H3 (and H5)
> is a reduced version of the one found on the A31. It only has 1 channel,
> instead of 4 channels supporting time-multiplexed BT.656 on the A31.
> Since the H3 is a reduced version, it cannot "fallback" to a compatible
> that implements more features than it supports.
> 
> This series separates support for the H3 variant from the A31 variant.
> 
> Patches 1 ~ 3 separate H3 CSI from A31 CSI in the bindings, driver, and
> device tree, respectively.
> 
> Patch 4 adds a pinmux setting for the MCLK (master clock). Some camera
> sensors use the master clock from the SoC instead of a standalone
> crystal.
> 
> Patches 5 and 6 are examples of using a camera sensor with an SBC.
> Since the modules are detachable, these changes should not be merged.
> They should be implemented as overlays instead.
> 
> Please have a look.
> 
> In addition, I found that the first frame captured seems to always be
> incomplete, with either parts cropped, out of position, or missing
> color components.

For the first 4 patches,
Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

[PATCH] MAINTAINERS: Change Todor Tomov's email address

[Todor Tomov]

My Linaro email address with be inactive very soon so switch
it to my Gmail address.

Signed-off-by: Todor Tomov 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3f6db87..c4aec8c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12463,7 +12463,7 @@ S:  Supported
 F: drivers/net/wireless/ath/ath9k/
 
 QUALCOMM CAMERA SUBSYSTEM DRIVER
-M: Todor Tomov 
+M: Todor Tomov 
 L: linux-media@vger.kernel.org
 S: Maintained
 F: Documentation/devicetree/bindings/media/qcom,camss.txt
-- 
2.7.4

Re: [PATCH v6 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer

[Matwey V. Kornilov]

ср, 21 нояб. 2018 г. в 21:15, Matwey V. Kornilov :
>
> пт, 9 нояб. 2018 г. в 22:03, Matwey V. Kornilov :
> >
> > DMA cocherency slows the transfer down on systems without hardware
> > coherent DMA.
> > Instead we use noncocherent DMA memory and explicit sync at data receive
> > handler.
> >
> > Based on previous commit the following performance benchmarks have been
> > carried out. Average memcpy() data transfer rate (rate) and handler
> > completion time (time) have been measured when running video stream at
> > 640x480 resolution at 10fps.
> >
> > x86_64 based system (Intel Core i5-3470). This platform has hardware
> > coherent DMA support and proposed change doesn't make big difference here.
> >
> >  * kmalloc:rate = (2.0 +- 0.4) GBps
> >time = (5.0 +- 3.0) usec
> >  * usb_alloc_coherent: rate = (3.4 +- 1.2) GBps
> >time = (3.5 +- 3.0) usec
> >
> > We see that the measurements agree within error ranges in this case.
> > So theoretically predicted performance downgrade cannot be reliably
> > measured here.
> >
> > armv7l based system (TI AM335x BeagleBone Black @ 300MHz). This platform
> > has no hardware coherent DMA support. DMA coherence is implemented via
> > disabled page caching that slows down memcpy() due to memory controller
> > behaviour.
> >
> >  * kmalloc:rate =  ( 94 +- 4) MBps
> >time =  (101 +- 4) usec
> >  * usb_alloc_coherent: rate = (28.1 +- 0.1) MBps
> >time =  (341 +- 2) usec
> >
> > Note, that quantative difference leads (this commit leads to 3.3 times
> > acceleration) to qualitative behavior change in this case. As it was
> > stated before, the video stream cannot be successfully received at AM335x
> > platforms with MUSB based USB host controller due to performance issues
> > [1].
> >
> > [1] https://www.spinics.net/lists/linux-usb/msg165735.html
> >
> > Signed-off-by: Matwey V. Kornilov 
>
> Ping

Ping

>
> > ---
> >  drivers/media/usb/pwc/pwc-if.c | 62 
> > +-
> >  1 file changed, 49 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c
> > index 53c111bd5a22..a81fb319b339 100644
> > --- a/drivers/media/usb/pwc/pwc-if.c
> > +++ b/drivers/media/usb/pwc/pwc-if.c
> > @@ -159,6 +159,32 @@ static const struct video_device pwc_template = {
> >  
> > /***/
> >  /* Private functions */
> >
> > +static void *pwc_alloc_urb_buffer(struct device *dev,
> > + size_t size, dma_addr_t *dma_handle)
> > +{
> > +   void *buffer = kmalloc(size, GFP_KERNEL);
> > +
> > +   if (!buffer)
> > +   return NULL;
> > +
> > +   *dma_handle = dma_map_single(dev, buffer, size, DMA_FROM_DEVICE);
> > +   if (dma_mapping_error(dev, *dma_handle)) {
> > +   kfree(buffer);
> > +   return NULL;
> > +   }
> > +
> > +   return buffer;
> > +}
> > +
> > +static void pwc_free_urb_buffer(struct device *dev,
> > +   size_t size,
> > +   void *buffer,
> > +   dma_addr_t dma_handle)
> > +{
> > +   dma_unmap_single(dev, dma_handle, size, DMA_FROM_DEVICE);
> > +   kfree(buffer);
> > +}
> > +
> >  static struct pwc_frame_buf *pwc_get_next_fill_buf(struct pwc_device *pdev)
> >  {
> > unsigned long flags = 0;
> > @@ -306,6 +332,11 @@ static void pwc_isoc_handler(struct urb *urb)
> > /* Reset ISOC error counter. We did get here, after all. */
> > pdev->visoc_errors = 0;
> >
> > +   dma_sync_single_for_cpu(&urb->dev->dev,
> > +   urb->transfer_dma,
> > +   urb->transfer_buffer_length,
> > +   DMA_FROM_DEVICE);
> > +
> > /* vsync: 0 = don't copy data
> >   1 = sync-hunt
> >   2 = synched
> > @@ -352,6 +383,11 @@ static void pwc_isoc_handler(struct urb *urb)
> > pdev->vlast_packet_size = flen;
> > }
> >
> > +   dma_sync_single_for_device(&urb->dev->dev,
> > +  urb->transfer_dma,
> > +  urb->transfer_buffer_length,
> > +  DMA_FROM_DEVICE);
> > +
> >  handler_end:
> > trace_pwc_handler_exit(urb, pdev);
> >
> > @@ -428,16 +464,15 @@ static int pwc_isoc_init(struct pwc_device *pdev)
> > urb->dev = udev;
> > urb->pipe = usb_rcvisocpipe(udev, pdev->vendpoint);
> > urb->transfer_flags = URB_ISO_ASAP | 
> > URB_NO_TRANSFER_DMA_MAP;
> > -   urb->transfer_buffer = usb_alloc_coherent(udev,
> > - ISO_BUFFER_SIZE,
> > - GFP_KERNEL,

Re: [PATCH v2 2/2] media: cedrus: Add H264 decoding support

[Paul Kocialkowski]

Hi,

On Thu, 2018-11-15 at 15:56 +0100, Maxime Ripard wrote:
> Introduce some basic H264 decoding support in cedrus. So far, only the
> baseline profile videos have been tested, and some more advanced features
> used in higher profiles are not even implemented.

Regarding the preparation of adresses, it seems that subtracting
PHYS_OFFSET does not work with more than 1 GiB of RAM available.

While platformes before the A33 can only map the first 256 MiB of RAM,
newer ones (starting with the A33) do not have this limitation and the
reserved memory can be set anywhere in RAM.

As an attempt to explain the issue, it could be that with 2 GiB
available, the VPU maps 0x0-0x4000 to the second GiB of RAM so that
0x4000-0x8000 matches the first GiB RAM (like it's exposed to
the CPU). With only 1 GiB (or anything else that divides 1 GiB), that
same GiB is mapped from 0x0-0x4000, 0x4000-0x8000 and so on,
so the issue does not occur.

I've discovered the issue while testing the H.265 series where I had
added the PHYS_OFFSET subtraction and found that the issue applied to
H.264 as well.

Cheers,

Paul

> Signed-off-by: Maxime Ripard 
> ---
>  drivers/staging/media/sunxi/cedrus/Makefile   |   3 +-
>  drivers/staging/media/sunxi/cedrus/cedrus.c   |  25 +
>  drivers/staging/media/sunxi/cedrus/cedrus.h   |  35 +-
>  .../staging/media/sunxi/cedrus/cedrus_dec.c   |  11 +
>  .../staging/media/sunxi/cedrus/cedrus_h264.c  | 470 ++
>  .../staging/media/sunxi/cedrus/cedrus_hw.c|   4 +
>  .../staging/media/sunxi/cedrus/cedrus_regs.h  |  63 +++
>  .../staging/media/sunxi/cedrus/cedrus_video.c |   9 +
>  8 files changed, 618 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_h264.c
> 
> diff --git a/drivers/staging/media/sunxi/cedrus/Makefile 
> b/drivers/staging/media/sunxi/cedrus/Makefile
> index e9dc68b7bcb6..aaf141fc58b6 100644
> --- a/drivers/staging/media/sunxi/cedrus/Makefile
> +++ b/drivers/staging/media/sunxi/cedrus/Makefile
> @@ -1,3 +1,4 @@
>  obj-$(CONFIG_VIDEO_SUNXI_CEDRUS) += sunxi-cedrus.o
>  
> -sunxi-cedrus-y = cedrus.o cedrus_video.o cedrus_hw.o cedrus_dec.o 
> cedrus_mpeg2.o
> +sunxi-cedrus-y = cedrus.o cedrus_video.o cedrus_hw.o cedrus_dec.o \
> +  cedrus_mpeg2.o cedrus_h264.o
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
> b/drivers/staging/media/sunxi/cedrus/cedrus.c
> index 82558455384a..627a8c07eb21 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@ -40,6 +40,30 @@ static const struct cedrus_control cedrus_controls[] = {
>   .codec  = CEDRUS_CODEC_MPEG2,
>   .required   = false,
>   },
> + {
> + .id = V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS,
> + .elem_size  = sizeof(struct v4l2_ctrl_h264_decode_param),
> + .codec  = CEDRUS_CODEC_H264,
> + .required   = true,
> + },
> + {
> + .id = V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS,
> + .elem_size  = sizeof(struct v4l2_ctrl_h264_slice_param),
> + .codec  = CEDRUS_CODEC_H264,
> + .required   = true,
> + },
> + {
> + .id = V4L2_CID_MPEG_VIDEO_H264_SPS,
> + .elem_size  = sizeof(struct v4l2_ctrl_h264_sps),
> + .codec  = CEDRUS_CODEC_H264,
> + .required   = true,
> + },
> + {
> + .id = V4L2_CID_MPEG_VIDEO_H264_PPS,
> + .elem_size  = sizeof(struct v4l2_ctrl_h264_pps),
> + .codec  = CEDRUS_CODEC_H264,
> + .required   = true,
> + },
>  };
>  
>  #define CEDRUS_CONTROLS_COUNTARRAY_SIZE(cedrus_controls)
> @@ -277,6 +301,7 @@ static int cedrus_probe(struct platform_device *pdev)
>   }
>  
>   dev->dec_ops[CEDRUS_CODEC_MPEG2] = &cedrus_dec_ops_mpeg2;
> + dev->dec_ops[CEDRUS_CODEC_H264] = &cedrus_dec_ops_h264;
>  
>   mutex_init(&dev->dev_mutex);
>   spin_lock_init(&dev->irq_lock);
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h 
> b/drivers/staging/media/sunxi/cedrus/cedrus.h
> index 781676b55a1b..179c10dcf6a7 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> @@ -30,7 +30,7 @@
>  
>  enum cedrus_codec {
>   CEDRUS_CODEC_MPEG2,
> -
> + CEDRUS_CODEC_H264,
>   CEDRUS_CODEC_LAST,
>  };
>  
> @@ -40,6 +40,12 @@ enum cedrus_irq_status {
>   CEDRUS_IRQ_OK,
>  };
>  
> +enum cedrus_h264_pic_type {
> + CEDRUS_H264_PIC_TYPE_FRAME  = 0,
> + CEDRUS_H264_PIC_TYPE_FIELD,
> + CEDRUS_H264_PIC_TYPE_MBAFF,
> +};
> +
>  struct cedrus_control {
>   u32 id;
>   u32 elem_size;
> @@ -47,6 +53,13 @@ struct cedrus_control {
>   unsigned char   required:1;
>  };
>  
> +struct ce

Re: [linux-sunxi] [PATCH 14/15] arm64: dts: allwinner: h5: Add Video Engine and reserved memory node

[Paul Kocialkowski]

Hi,

On Thu, 2018-11-15 at 23:35 +0800, Chen-Yu Tsai wrote:
> On Thu, Nov 15, 2018 at 10:51 PM Paul Kocialkowski
>  wrote:
> > This adds nodes for the Video Engine and the associated reserved memory
> > for the H5. Up to 96 MiB of memory are dedicated to the CMA pool.
> > 
> > The pool is located at the end of the first 256 MiB of RAM so that the
> > VPU can access it. It is unclear whether this is still a hard
> > requirement for this platform, but it seems safer that way.
> 
> I think we can actually test this. You could move the reserved memory
> pool beyond 256 MiB, and have cedrus decode stuff, and try to display
> the results. If it's gibberish, or the system crashes, it's likely the
> memory access wrapped around at 256 MiB.
> 
> What do you think?

I did the test on various platforms and found that starting with the
A33, the VPU can map any address in RAM! SO we shouldn't need reserved
memory nodes for these devices after all.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: This is a digitally signed message part

Re: [PATCH 07/15] arm64: dts: allwinner: h5: Add system-control node with SRAM C1

[Paul Kocialkowski]

Hi,

On Fri, 2018-11-30 at 11:38 +0800, Chen-Yu Tsai wrote:
> On Fri, Nov 16, 2018 at 12:52 AM Chen-Yu Tsai  wrote:
> > On Thu, Nov 15, 2018 at 10:50 PM Paul Kocialkowski
> >  wrote:
> > > Add the H5-specific system control node description to its device-tree
> > > with support for the SRAM C1 section, that will be used by the video
> > > codec node later on.
> > > 
> > > Signed-off-by: Paul Kocialkowski 
> > > ---
> > >  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 22 
> > >  1 file changed, 22 insertions(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi 
> > > b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > > index b41dc1aab67d..c2d14b22b8c1 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> > > @@ -94,6 +94,28 @@
> > > };
> > > 
> > > soc {
> > > +   system-control@1c0 {
> > > +   compatible = "allwinner,sun50i-h5-system-control";
> > > +   reg = <0x01c0 0x1000>;
> > > +   #address-cells = <1>;
> > > +   #size-cells = <1>;
> > > +   ranges;
> > > +
> > > +   sram_c1: sram@1d0 {
> > > +   compatible = "mmio-sram";
> > > +   reg = <0x01d0 0x8>;
> > 
> > I'll try to check this one tomorrow.
> > 
> > I did find something interesting on the H3: there also seems to be SRAM at
> > 0x01dc to 0x01dcfeff , again mapped by the same bits as SRAM C1.
> > 
> > And on the A33, the SRAM C1 range is 0x01d0 to 0x01d478ff.
> > 
> > This was found by mapping the SRAM to the CPU, then using devmem to poke
> > around the register range. If there's SRAM, the first read would typically
> > return random data, and a subsequent write to it would set some value that
> > would be read back correctly. If there's no SRAM, a read either returns 0x0
> > or some random data that can't be overwritten.
> > 
> > You might want to check the other SoCs.
> 
> This range seems to contain stuff other than SRAM, possibly fixed lookup
> tables. Since this is entirely unknown, lets just stick to the known full
> range instead.

Thanks for investigating all this!

I also conducted some tests and found that the H5 has its SRAM C1
(marked as SRAM C in the manual) at 0x18000. However for the A64, SRAM
C1 gets mapped to 0x1D0. There is also SRAM C at 0x18000 but this
one seems unrelated to the VPU and only used by DE2 (as already
described in the A64 dt).

I share your conclusion that there seems to be more than SRAM in there.
Testing with devmem write/read on the start address was reliable as a
test, but some chunks in the range did not behave like SRAM (not the
same value read).

I agree that we should keep the known full range as there are lots of
unknowns here.

Cheers,

Paul

> ChenYu
> 
> > > +   #address-cells = <1>;
> > > +   #size-cells = <1>;
> > > +   ranges = <0 0x01d0 0x8>;
> > > +
> > > +   ve_sram: sram-section@0 {
> > > +   compatible = 
> > > "allwinner,sun50i-h5-sram-c1",
> > > +
> > > "allwinner,sun4i-a10-sram-c1";
> > > +   reg = <0x00 0x8>;
> > > +   };
> > > +   };
> > > +   };
> > > +
> > > mali: gpu@1e8 {
> > > compatible = "allwinner,sun50i-h5-mali", 
> > > "arm,mali-450";
> > > reg = <0x01e8 0x3>;
> > > --
> > > 2.19.1
> > > 
-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: This is a digitally signed message part

[PATCH] dma-buf: Change to use DEFINE_SHOW_ATTRIBUTE macro

[Yangtao Li]

Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.

Signed-off-by: Yangtao Li 
---
 drivers/dma-buf/dma-buf.c| 12 +---
 drivers/dma-buf/sync_debug.c | 16 +++-
 2 files changed, 4 insertions(+), 24 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 02f7f9a89979..7c858020d14b 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1093,17 +1093,7 @@ static int dma_buf_debug_show(struct seq_file *s, void 
*unused)
return 0;
 }
 
-static int dma_buf_debug_open(struct inode *inode, struct file *file)
-{
-   return single_open(file, dma_buf_debug_show, NULL);
-}
-
-static const struct file_operations dma_buf_debug_fops = {
-   .open   = dma_buf_debug_open,
-   .read   = seq_read,
-   .llseek = seq_lseek,
-   .release= single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(dma_buf_debug);
 
 static struct dentry *dma_buf_debugfs_dir;
 
diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
index c4c8ecb24aa9..c0abf37df88b 100644
--- a/drivers/dma-buf/sync_debug.c
+++ b/drivers/dma-buf/sync_debug.c
@@ -147,7 +147,7 @@ static void sync_print_sync_file(struct seq_file *s,
}
 }
 
-static int sync_debugfs_show(struct seq_file *s, void *unused)
+static int sync_info_debugfs_show(struct seq_file *s, void *unused)
 {
struct list_head *pos;
 
@@ -178,17 +178,7 @@ static int sync_debugfs_show(struct seq_file *s, void 
*unused)
return 0;
 }
 
-static int sync_info_debugfs_open(struct inode *inode, struct file *file)
-{
-   return single_open(file, sync_debugfs_show, inode->i_private);
-}
-
-static const struct file_operations sync_info_debugfs_fops = {
-   .open   = sync_info_debugfs_open,
-   .read   = seq_read,
-   .llseek = seq_lseek,
-   .release= single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(sync_info_debugfs);
 
 static __init int sync_debugfs_init(void)
 {
@@ -218,7 +208,7 @@ void sync_dump(void)
};
int i;
 
-   sync_debugfs_show(&s, NULL);
+   sync_info_debugfs_show(&s, NULL);
 
for (i = 0; i < s.count; i += DUMP_CHUNK) {
if ((s.count - i) > DUMP_CHUNK) {
-- 
2.17.0

[PATCH -next] media: seco-cec: add missing header file to fix build

[Randy Dunlap]

From: Randy Dunlap 

Fix build errors due to missing  header file.
The header file is inserted first because module-related errors
begin showing up in  (when CONFIG_ACPI is not set).

Sample of build errors:

In file included from ../include/linux/acpi.h:27:0,
 from ../drivers/media/platform/seco-cec/seco-cec.c:10:
../include/linux/device.h:1620:1: warning: data definition has no type or 
storage class [enabled by default]
 module_exit(__driver##_exit);
 ^
../include/linux/platform_device.h:229:2: note: in expansion of macro 
'module_driver'
  module_driver(__platform_driver, platform_driver_register, \
  ^
../drivers/media/platform/seco-cec/seco-cec.c:791:1: note: in expansion of 
macro 'module_platform_driver'
 module_platform_driver(secocec_driver);
 ^
../include/linux/device.h:1620:1: error: type defaults to 'int' in declaration 
of 'module_exit' [-Werror=implicit-int]
 module_exit(__driver##_exit);
 ^
../include/linux/platform_device.h:229:2: note: in expansion of macro 
'module_driver'
  module_driver(__platform_driver, platform_driver_register, \
  ^
../drivers/media/platform/seco-cec/seco-cec.c:791:1: note: in expansion of 
macro 'module_platform_driver'
 module_platform_driver(secocec_driver);
 ^
In file included from ../include/linux/linkage.h:7:0,
 from ../include/linux/kernel.h:7,
 from ../include/linux/list.h:9,
 from ../include/linux/resource_ext.h:17,
 from ../include/linux/acpi.h:26,
 from ../drivers/media/platform/seco-cec/seco-cec.c:10:
../include/linux/export.h:18:30: warning: parameter names (without types) in 
function declaration [enabled by default]
 #define THIS_MODULE ((struct module *)0)
  ^
../include/linux/platform_device.h:199:34: note: in expansion of macro 
'THIS_MODULE'
  __platform_driver_register(drv, THIS_MODULE)
  ^
../include/linux/device.h:1613:9: note: in expansion of macro 
'platform_driver_register'
  return __register(&(__driver) , ##__VA_ARGS__); \
 ^
../include/linux/platform_device.h:229:2: note: in expansion of macro 
'module_driver'
  module_driver(__platform_driver, platform_driver_register, \
  ^
../drivers/media/platform/seco-cec/seco-cec.c:791:1: note: in expansion of 
macro 'module_platform_driver'
 module_platform_driver(secocec_driver);
 ^
../drivers/media/platform/seco-cec/seco-cec.c:793:20: error: expected 
declaration specifiers or '...' before string constant
 MODULE_DESCRIPTION("SECO CEC X86 Driver");
^
../drivers/media/platform/seco-cec/seco-cec.c:794:15: error: expected 
declaration specifiers or '...' before string constant
 MODULE_AUTHOR("Ettore Chimenti ");
   ^
../drivers/media/platform/seco-cec/seco-cec.c:795:16: error: expected 
declaration specifiers or '...' before string constant
 MODULE_LICENSE("Dual BSD/GPL");
^
In file included from ../include/linux/acpi.h:27:0,
 from ../drivers/media/platform/seco-cec/seco-cec.c:10:
../drivers/media/platform/seco-cec/seco-cec.c:791:24: warning: 
'secocec_driver_init' defined but not used [-Wunused-function]
 module_platform_driver(secocec_driver);
^
../include/linux/device.h:1611:19: note: in definition of macro 'module_driver'
 static int __init __driver##_init(void) \
   ^
../drivers/media/platform/seco-cec/seco-cec.c:791:1: note: in expansion of 
macro 'module_platform_driver'
 module_platform_driver(secocec_driver);


Signed-off-by: Randy Dunlap 
Cc: Ettore Chimenti 
---
 drivers/media/platform/seco-cec/seco-cec.c |1 +
 1 file changed, 1 insertion(+)

--- linux-next-20181130.orig/drivers/media/platform/seco-cec/seco-cec.c
+++ linux-next-20181130/drivers/media/platform/seco-cec/seco-cec.c
@@ -7,6 +7,7 @@
  * Copyright (C) 2018, Aidilab Srl.
  */
 
+#include 
 #include 
 #include 
 #include 

Re: [linux-sunxi] [PATCH v2 2/2] media: cedrus: Add H264 decoding support

[Jernej Škrabec]

Dne petek, 30. november 2018 ob 08:30:47 CET je Maxime Ripard napisal(a):
> On Tue, Nov 27, 2018 at 05:30:00PM +0100, Jernej Škrabec wrote:
> > > > > +static void _cedrus_write_ref_list(struct cedrus_ctx *ctx,
> > > > > +struct cedrus_run *run,
> > > > > +const u8 *ref_list, u8 num_ref,
> > > > > +enum cedrus_h264_sram_off sram)
> > > > > +{
> > > > > + const struct v4l2_ctrl_h264_decode_param *decode =
> > > > > run->h264.decode_param; + struct vb2_queue *cap_q =
> > > > > &ctx->fh.m2m_ctx->cap_q_ctx.q;
> > > > > + struct cedrus_dev *dev = ctx->dev;
> > > > > + u32 sram_array[CEDRUS_MAX_REF_IDX / sizeof(u32)];
> > > > > + unsigned int size, i;
> > > > > +
> > > > > + memset(sram_array, 0, sizeof(sram_array));
> > > > > +
> > > > > + for (i = 0; i < num_ref; i += 4) {
> > > > > + unsigned int j;
> > > > > +
> > > > > + for (j = 0; j < 4; j++) {
> > > > 
> > > > I don't think you have to complicate with two loops here.
> > > > cedrus_h264_write_sram() takes void* and it aligns to 4 anyway. So as
> > > > long
> > > > input buffer is multiple of 4 (u8[CEDRUS_MAX_REF_IDX] qualifies for
> > > > that),
> > > > you can use single for loop with "u8 sram_array[CEDRUS_MAX_REF_IDX]".
> > > > This should make code much more readable.
> > > 
> > > This wasn't really about the alignment, but in order to get the
> > > offsets in the u32 and the array more easily.
> > > 
> > > Breaking out the loop will make that computation less easy on the eye,
> > > so I guess it's very subjective.
> > 
> > For some strange reason, code below fixes decoding issue from one of my
> > test
> > samples. This is what I actually meant with 1 loop approach:
> Do you have that test sample somewhere accessible?

yes, it's here:
http://jernej.libreelec.tv/videos/h264/Star%20Wars%20Episode%20VII%20-%20The%20Force%20Awakens%20-%20Teaser%20Trailer%202.mp4

It needs also prediction weight tables (your early patch for that should work 
ok) and scaling list (code I sent you in one of the previous comments should 
work).

For me, if this sample worked without issue, every other non-interlaced sample 
worked too.

> 
> > static void _cedrus_write_ref_list(struct cedrus_ctx *ctx,
> > 
> >struct cedrus_run *run,
> >const u8 *ref_list, u8 num_ref,
> >enum cedrus_h264_sram_off sram)
> > 
> > {
> > 
> > const struct v4l2_ctrl_h264_decode_param *decode =
> > run->h264.decode_param;
> > struct vb2_queue *cap_q = &ctx->fh.m2m_ctx->cap_q_ctx.q;
> > struct cedrus_dev *dev = ctx->dev;
> > u8 sram_array[CEDRUS_MAX_REF_IDX];
> > unsigned int i;
> > 
> > memset(sram_array, 0, sizeof(sram_array));
> > num_ref = min(num_ref, (u8)CEDRUS_MAX_REF_IDX);
> > 
> > for (i = 0; i < num_ref; i++) {
> > 
> > const struct v4l2_h264_dpb_entry *dpb;
> > const struct cedrus_buffer *cedrus_buf;
> > const struct vb2_v4l2_buffer *ref_buf;
> > unsigned int position;
> > int buf_idx;
> > u8 dpb_idx;
> > 
> > dpb_idx = ref_list[i];
> > dpb = &decode->dpb[dpb_idx];
> > 
> > if (!(dpb->flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE))
> > 
> > continue;
> > 
> > buf_idx = vb2_find_tag(cap_q, dpb->tag, 0);
> > if (buf_idx < 0)
> > 
> > continue;
> > 
> > ref_buf = to_vb2_v4l2_buffer(ctx->dst_bufs[buf_idx]);
> > cedrus_buf = vb2_v4l2_to_cedrus_buffer(ref_buf);
> > position = cedrus_buf->codec.h264.position;
> > 
> > sram_array[i] |= position << 1;
> > if (ref_buf->field == V4L2_FIELD_BOTTOM)
> > 
> > sram_array[i] |= BIT(0);
> > 
> > }
> > 
> > cedrus_h264_write_sram(dev, sram, &sram_array, num_ref);
> > 
> > }
> > 
> > IMO this code is easier to read.
> 
> INdeed, thanks!
> 
> > > > > + const struct v4l2_h264_dpb_entry *dpb;
> > > > > + const struct cedrus_buffer *cedrus_buf;
> > > > > + const struct vb2_v4l2_buffer *ref_buf;
> > > > > + unsigned int position;
> > > > > + int buf_idx;
> > > > > + u8 ref_idx = i + j;
> > > > > + u8 dpb_idx;
> > > > > +
> > > > > + if (ref_idx >= num_ref)
> > > > > + break;
> > > > > +
> > > > > + dpb_idx = ref_list[ref_idx];
> > > > > + dpb = &decode->dpb[dpb_idx];
> > > > > +
> > > > > + if (!(dpb->flags & 
> > > > > V4L2_H264_DPB_ENTRY_FLAG_ACTIVE))
> > > > > +  

[PATCH RFC 08/15] media: replace **** with a hug

[Jarkko Sakkinen]

In order to comply with the CoC, replace  with a hug. In
addition, fix a coding style issue (lines with over 80 chars).

Signed-off-by: Jarkko Sakkinen 
---
 drivers/media/i2c/bt819.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/media/i2c/bt819.c b/drivers/media/i2c/bt819.c
index 472e37637c8d..c0f198b764f0 100644
--- a/drivers/media/i2c/bt819.c
+++ b/drivers/media/i2c/bt819.c
@@ -165,9 +165,11 @@ static int bt819_init(struct v4l2_subdev *sd)
0x0f, 0x00, /* 0x0f Hue control */
0x12, 0x04, /* 0x12 Output Format */
0x13, 0x20, /* 0x13 Vertial Scaling msb 0x00
-  chroma comb OFF, line drop scaling, 
interlace scaling
-  BUG? Why does turning the chroma 
comb on fuck up color?
-  Bug in the bt819 stepping on my 
board?
+  chroma comb OFF, line drop scaling,
+  interlace scaling BUG? Why does
+  turning the chroma comb on hug up
+  color?  Bug in the bt819 stepping on
+  my board?
*/
0x14, 0x00, /* 0x14 Vertial Scaling lsb */
0x16, 0x07, /* 0x16 Video Timing Polarity
-- 
2.19.1

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Kees Cook]

On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
 wrote:
>
> In order to comply with the CoC, replace  with a hug.

Heh. I support the replacement of the stronger language, but I find
"hug", "hugged", and "hugging" to be very weird replacements. Can we
bikeshed this to "heck", "hecked", and "hecking" (or "heckin" to
follow true Doggo meme style).

"This API is hugged" doesn't make any sense to me. "This API is
hecked" is better, or at least funnier (to me). "Hug this interface"
similarly makes no sense, but "Heck this interface" seems better.
"Don't touch my hecking code", "What the heck were they thinking?"
etc... "hug" is odd.

Better yet, since it's only 17 files, how about doing context-specific
changes? "This API is terrible", "Hateful interface", "Don't touch my
freakin' code", "What in the world were they thinking?" etc?

-Kees

>
> Jarkko Sakkinen (15):
>   MIPS: replace  with a hug
>   Documentation: replace  with a hug
>   drm/nouveau: replace  with a hug
>   m68k: replace  with a hug
>   parisc: replace  with a hug
>   cpufreq: replace  with a hug
>   ide: replace  with a hug
>   media: replace  with a hug
>   mtd: replace  with a hug
>   net/sunhme: replace  with a hug
>   scsi: replace  with a hug
>   inotify: replace  with a hug
>   irq: replace  with a hug
>   lib: replace  with a hug
>   net: replace  with a hug
>
>  Documentation/kernel-hacking/locking.rst  |  2 +-
>  arch/m68k/include/asm/sun3ints.h  |  2 +-
>  arch/mips/pci/ops-bridge.c| 24 +--
>  arch/mips/sgi-ip22/ip22-setup.c   |  2 +-
>  arch/parisc/kernel/sys_parisc.c   |  2 +-
>  drivers/cpufreq/powernow-k7.c |  2 +-
>  .../gpu/drm/nouveau/nvkm/subdev/bios/init.c   |  2 +-
>  .../nouveau/nvkm/subdev/pmu/fuc/macros.fuc|  2 +-
>  drivers/ide/cmd640.c  |  2 +-
>  drivers/media/i2c/bt819.c |  8 ---
>  drivers/mtd/mtd_blkdevs.c |  2 +-
>  drivers/net/ethernet/sun/sunhme.c |  4 ++--
>  drivers/scsi/qlogicpti.h  |  2 +-
>  fs/notify/inotify/inotify_user.c  |  2 +-
>  kernel/irq/timings.c  |  2 +-
>  lib/vsprintf.c|  2 +-
>  net/core/skbuff.c |  2 +-
>  17 files changed, 33 insertions(+), 31 deletions(-)
>
> --
> 2.19.1
>


-- 
Kees Cook

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Davidlohr Bueso]

On Fri, 30 Nov 2018, Kees Cook wrote:


On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
 wrote:


In order to comply with the CoC, replace  with a hug.


I hope this is some kind of joke. How would anyone get offended by reading
technical comments? This is all beyond me...

Thanks,
Davidlohr

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Jens Axboe]

On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
> On Fri, 30 Nov 2018, Kees Cook wrote:
> 
>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
>>  wrote:
>>>
>>> In order to comply with the CoC, replace  with a hug.
> 
> I hope this is some kind of joke. How would anyone get offended by reading
> technical comments? This is all beyond me...

Agree, this is insanity.

-- 
Jens Axboe

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[John Paul Adrian Glaubitz]

On 11/30/18 8:40 PM, Kees Cook wrote:
> Better yet, since it's only 17 files, how about doing context-specific
> changes? "This API is terrible", "Hateful interface", "Don't touch my
> freakin' code", "What in the world were they thinking?" etc?
Or just leave it as is because we're all grown up and don't freak out
when a piece of text contains the word "fuck".

I still don't understand why people think that the word "fuck" is what
would keep certain groups from contributing to the Linux kernel. In all
seriousness, it doesn't.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Matthias Brugger]

On 30/11/2018 20:40, Kees Cook wrote:
> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
>  wrote:
>>
>> In order to comply with the CoC, replace  with a hug.
> 
> Heh. I support the replacement of the stronger language, but I find
> "hug", "hugged", and "hugging" to be very weird replacements. Can we
> bikeshed this to "heck", "hecked", and "hecking" (or "heckin" to
> follow true Doggo meme style).
> 
> "This API is hugged" doesn't make any sense to me. "This API is
> hecked" is better, or at least funnier (to me). "Hug this interface"
> similarly makes no sense, but "Heck this interface" seems better.
> "Don't touch my hecking code", "What the heck were they thinking?"
> etc... "hug" is odd.
> 

Like John I don't think that the word "fuck" is something we have to ban from
the source code, but I don't care too much. Anyway, please don't change it to
something like heck as it might be difficult for non-english speaker to 
understand.

Regards,
Matthias

> Better yet, since it's only 17 files, how about doing context-specific
> changes? "This API is terrible", "Hateful interface", "Don't touch my
> freakin' code", "What in the world were they thinking?" etc?
> 
> -Kees
> 
>>
>> Jarkko Sakkinen (15):
>>   MIPS: replace  with a hug
>>   Documentation: replace  with a hug
>>   drm/nouveau: replace  with a hug
>>   m68k: replace  with a hug
>>   parisc: replace  with a hug
>>   cpufreq: replace  with a hug
>>   ide: replace  with a hug
>>   media: replace  with a hug
>>   mtd: replace  with a hug
>>   net/sunhme: replace  with a hug
>>   scsi: replace  with a hug
>>   inotify: replace  with a hug
>>   irq: replace  with a hug
>>   lib: replace  with a hug
>>   net: replace  with a hug
>>
>>  Documentation/kernel-hacking/locking.rst  |  2 +-
>>  arch/m68k/include/asm/sun3ints.h  |  2 +-
>>  arch/mips/pci/ops-bridge.c| 24 +--
>>  arch/mips/sgi-ip22/ip22-setup.c   |  2 +-
>>  arch/parisc/kernel/sys_parisc.c   |  2 +-
>>  drivers/cpufreq/powernow-k7.c |  2 +-
>>  .../gpu/drm/nouveau/nvkm/subdev/bios/init.c   |  2 +-
>>  .../nouveau/nvkm/subdev/pmu/fuc/macros.fuc|  2 +-
>>  drivers/ide/cmd640.c  |  2 +-
>>  drivers/media/i2c/bt819.c |  8 ---
>>  drivers/mtd/mtd_blkdevs.c |  2 +-
>>  drivers/net/ethernet/sun/sunhme.c |  4 ++--
>>  drivers/scsi/qlogicpti.h  |  2 +-
>>  fs/notify/inotify/inotify_user.c  |  2 +-
>>  kernel/irq/timings.c  |  2 +-
>>  lib/vsprintf.c|  2 +-
>>  net/core/skbuff.c |  2 +-
>>  17 files changed, 33 insertions(+), 31 deletions(-)
>>
>> --
>> 2.19.1
>>
> 
> 

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Michael Schmitz]

Am 01.12.2018 um 09:12 schrieb Jens Axboe:

On 11/30/18 12:56 PM, Davidlohr Bueso wrote:

On Fri, 30 Nov 2018, Kees Cook wrote:


On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
 wrote:


In order to comply with the CoC, replace  with a hug.


I hope this is some kind of joke. How would anyone get offended by reading
technical comments? This is all beyond me...


Agree, this is insanity.


Irony? Parody?

That's what crossed my mind, to be brutally honest. Group hug, anyone?

For the VME vectors case: no need to hug, just don't mess with them.

Cheers,

Michael

(Waiting for Adrian's ticket machines to swoop down and take me out now 
... in 24 hours ...)

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[David Miller]

From: Davidlohr Bueso 
Date: Fri, 30 Nov 2018 11:56:52 -0800

> I hope this is some kind of joke.

Whether or not it is a joke, it is censorship.

And because of that I have no intention to apply any patches like this
to any code I am in charge of.

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[David Miller]

From: Jens Axboe 
Date: Fri, 30 Nov 2018 13:12:26 -0700

> On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
>> On Fri, 30 Nov 2018, Kees Cook wrote:
>> 
>>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
>>>  wrote:

 In order to comply with the CoC, replace  with a hug.
>> 
>> I hope this is some kind of joke. How would anyone get offended by reading
>> technical comments? This is all beyond me...
> 
> Agree, this is insanity.

And even worse it is censorship.

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[David Miller]

From: Abuse 
Date: Fri, 30 Nov 2018 20:39:01 +

> I assume I will now be barred.

Perhaps, but not because you said fuck.  It would be because you're
intentionally creating a disturbance on the list and making it more
difficult for developers to get their work done and intentionally
creating a distraction and a hostile environment for the discussion at
hand.

That would not be censorship.

There is a big difference.

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Steven Rostedt]

On Fri, 30 Nov 2018 20:39:01 +
Abuse  wrote:

> On Friday, 30 November 2018 20:35:07 GMT David Miller wrote:
> > From: Jens Axboe 
> > Date: Fri, 30 Nov 2018 13:12:26 -0700
> >   
> > > On 11/30/18 12:56 PM, Davidlohr Bueso wrote:  
> > >> On Fri, 30 Nov 2018, Kees Cook wrote:
> > >>   
> > >>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> > >>>  wrote:  
> > 
> >  In order to comply with the CoC, replace  with a hug.  
> > >> 
> > >> I hope this is some kind of joke. How would anyone get offended by 
> > >> reading
> > >> technical comments? This is all beyond me...  
> > > 
> > > Agree, this is insanity.  
> > 
> > And even worse it is censorship.
> >   
> 
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> Hug
> 
> I assume I will now be barred.
> 

-- Steve

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Jarkko Sakkinen]

On Fri, Nov 30, 2018 at 11:56:52AM -0800, Davidlohr Bueso wrote:
> On Fri, 30 Nov 2018, Kees Cook wrote:
> 
> > On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> >  wrote:
> > > 
> > > In order to comply with the CoC, replace  with a hug.
> 
> I hope this is some kind of joke. How would anyone get offended by reading
> technical comments? This is all beyond me...

Well... Not a joke really but more like conversation starter :-)

I had 10h flight from Amsterdam to Portland and one of the things that I
did was to read the new CoC properly.

This a direct quote from the CoC:

"Harassment includes the use of abusive, offensive or degrading
language, intimidation, stalking, harassing photography or recording,
inappropriate physical contact, sexual imagery and unwelcome sexual
advances or requests for sexual favors."

Doesn't this fall into this category?

Your argument is not that great because you could say that from any LKML
discussion. If you don't like hugging, please propose something else :-)

/Jarkko

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[James Bottomley]

On Fri, 2018-11-30 at 12:55 -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 11:56:52AM -0800, Davidlohr Bueso wrote:
> > On Fri, 30 Nov 2018, Kees Cook wrote:
> > 
> > > On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> > >  wrote:
> > > > 
> > > > In order to comply with the CoC, replace  with a hug.
> > 
> > I hope this is some kind of joke. How would anyone get offended by
> > reading technical comments? This is all beyond me...
> 
> Well... Not a joke really but more like conversation starter :-)
> 
> I had 10h flight from Amsterdam to Portland and one of the things
> that I did was to read the new CoC properly.
> 
> This a direct quote from the CoC:
> 
> "Harassment includes the use of abusive, offensive or degrading
> language, intimidation, stalking, harassing photography or recording,
> inappropriate physical contact, sexual imagery and unwelcome sexual
> advances or requests for sexual favors."
> 
> Doesn't this fall into this category?

No because use of what some people consider to be bad language isn't
necessarily abusive, offensive or degrading.  Our most heavily censored
medium is TV and "fuck" is now considered acceptable in certain
contexts on most channels in the UK and EU.

> Your argument is not that great because you could say that from any
> LKML discussion. If you don't like hugging, please propose something
> else
> :-)

The interpretation document also says this:

   ontributions submitted for the kernel should use appropriate
   language. Content that already exists predating the Code of Conduct
   will not be addressed now as a violation.

So that definitely means there should be no hunting down of existing
comments in kernel code.

James

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Steven Rostedt]

On Fri, 30 Nov 2018 12:55:21 -0800
Jarkko Sakkinen  wrote:

> On Fri, Nov 30, 2018 at 11:56:52AM -0800, Davidlohr Bueso wrote:
> > On Fri, 30 Nov 2018, Kees Cook wrote:
> >   
> > > On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> > >  wrote:  
> > > > 
> > > > In order to comply with the CoC, replace  with a hug.  
> > 
> > I hope this is some kind of joke. How would anyone get offended by reading
> > technical comments? This is all beyond me...  
> 
> Well... Not a joke really but more like conversation starter :-)
> 
> I had 10h flight from Amsterdam to Portland and one of the things that I
> did was to read the new CoC properly.
> 
> This a direct quote from the CoC:
> 
> "Harassment includes the use of abusive, offensive or degrading
> language, intimidation, stalking, harassing photography or recording,
> inappropriate physical contact, sexual imagery and unwelcome sexual
> advances or requests for sexual favors."
> 
> Doesn't this fall into this category?
>

It has also been discussed that existing code (and past conduct) will
not be covered under the CoC. It's about new code and conduct moving
forward.

-- Steve

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Jonathan Corbet]

On Fri, 30 Nov 2018 12:55:21 -0800
Jarkko Sakkinen  wrote:

> This a direct quote from the CoC:
> 
> "Harassment includes the use of abusive, offensive or degrading
> language, intimidation, stalking, harassing photography or recording,
> inappropriate physical contact, sexual imagery and unwelcome sexual
> advances or requests for sexual favors."

...and this is from the interpretation document:

> Contributions submitted for the kernel should use appropriate language.
> Content that already exists predating the Code of Conduct will not be
> addressed now as a violation.

So existing code is explicitly not a CoC violation and need not be
treated as such.  That said, improvements to the comments are always
welcome, as long as they are actually improvements.

Thanks,

jon

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Jarkko Sakkinen]

On Fri, Nov 30, 2018 at 11:40:17AM -0800, Kees Cook wrote:
> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
>  wrote:
> >
> > In order to comply with the CoC, replace  with a hug.
> 
> Heh. I support the replacement of the stronger language, but I find
> "hug", "hugged", and "hugging" to be very weird replacements. Can we
> bikeshed this to "heck", "hecked", and "hecking" (or "heckin" to
> follow true Doggo meme style).
> 
> "This API is hugged" doesn't make any sense to me. "This API is
> hecked" is better, or at least funnier (to me). "Hug this interface"
> similarly makes no sense, but "Heck this interface" seems better.
> "Don't touch my hecking code", "What the heck were they thinking?"
> etc... "hug" is odd.
> 
> Better yet, since it's only 17 files, how about doing context-specific
> changes? "This API is terrible", "Hateful interface", "Don't touch my
> freakin' code", "What in the world were they thinking?" etc?

I'm happy to refine this (thus the RFC tag)! And depending on the
culture, hugging could fall in the harrasment category. Actually, when I
think about it, in Finland this kind of poking of ones personal bubble
would be such :-)

I'll refine the patch set with more context sensitive replacements,
perhaps removing the comment altogether in some places. Thank you for
the feedback!

/Jarkko

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Jarkko Sakkinen]

On Fri, Nov 30, 2018 at 09:09:48PM +0100, John Paul Adrian Glaubitz wrote:
> Or just leave it as is because we're all grown up and don't freak out
> when a piece of text contains the word "fuck".
> 
> I still don't understand why people think that the word "fuck" is what
> would keep certain groups from contributing to the Linux kernel. In all
> seriousness, it doesn't.

Are you making a claim that your personal experience, and maybe your
mates, is the objective truth, or am I misunderstanding something?

/Jarkko

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Jarkko Sakkinen]

On Fri, Nov 30, 2018 at 09:31:13PM +0100, Matthias Brugger wrote:
> Like John I don't think that the word "fuck" is something we have to ban from
> the source code, but I don't care too much. Anyway, please don't change it to
> something like heck as it might be difficult for non-english speaker to 
> understand.

I make context sensitive better thought updates based on the feedback
that Kees gave. I used RFC tag for a reason.

/Jarkko

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Jarkko Sakkinen]

On Fri, Nov 30, 2018 at 12:35:07PM -0800, David Miller wrote:
> From: Jens Axboe 
> Date: Fri, 30 Nov 2018 13:12:26 -0700
> 
> > On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
> >> On Fri, 30 Nov 2018, Kees Cook wrote:
> >> 
> >>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> >>>  wrote:
> 
>  In order to comply with the CoC, replace  with a hug.
> >> 
> >> I hope this is some kind of joke. How would anyone get offended by reading
> >> technical comments? This is all beyond me...
> > 
> > Agree, this is insanity.
> 
> And even worse it is censorship.

It is not close to a cencorship, especially when I used RFC tag, which
essentially says that I'm not saying "please take this", right?

Can you tell how the CoC should be interpreted then? I read it through
on my plane trip with an eye glass.

Is cursing OK?

/Jarkko

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Jarkko Sakkinen]

On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
> No because use of what some people consider to be bad language isn't
> necessarily abusive, offensive or degrading.  Our most heavily censored
> medium is TV and "fuck" is now considered acceptable in certain
> contexts on most channels in the UK and EU.

This makes following the CoC extremely hard to a non-native speaker as
it is not too explicit on what is OK and what is not. I did through the
whole thing with an eye glass and this what I deduced from it.

/Jarkko

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[David Miller]

From: Jarkko Sakkinen 
Date: Fri, 30 Nov 2018 13:42:33 -0800

> Can you tell how the CoC should be interpreted then?

Regardless of what I think, as others have showen the CoC explicitly
does not apply to existing code.

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[David Miller]

From: Jarkko Sakkinen 
Date: Fri, 30 Nov 2018 13:44:05 -0800

> On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
>> No because use of what some people consider to be bad language isn't
>> necessarily abusive, offensive or degrading.  Our most heavily censored
>> medium is TV and "fuck" is now considered acceptable in certain
>> contexts on most channels in the UK and EU.
> 
> This makes following the CoC extremely hard to a non-native speaker as
> it is not too explicit on what is OK and what is not. I did through the
> whole thing with an eye glass and this what I deduced from it.

It would be helpful if you could explain what part of the language
is unclear wrt. explaining how CoC does not apply to existing code.

That part seems very explicit to me.

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Jens Axboe]

On 11/30/18 2:47 PM, David Miller wrote:
> From: Jarkko Sakkinen 
> Date: Fri, 30 Nov 2018 13:42:33 -0800
> 
>> Can you tell how the CoC should be interpreted then?
> 
> Regardless of what I think, as others have showen the CoC explicitly
> does not apply to existing code.

And with that, can we please put an end to this thread (and patchset)?

-- 
Jens Axboe

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Jarkko Sakkinen]

On Fri, Nov 30, 2018 at 01:48:08PM -0800, David Miller wrote:
> From: Jarkko Sakkinen 
> Date: Fri, 30 Nov 2018 13:44:05 -0800
> 
> > On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
> >> No because use of what some people consider to be bad language isn't
> >> necessarily abusive, offensive or degrading.  Our most heavily censored
> >> medium is TV and "fuck" is now considered acceptable in certain
> >> contexts on most channels in the UK and EU.
> > 
> > This makes following the CoC extremely hard to a non-native speaker as
> > it is not too explicit on what is OK and what is not. I did through the
> > whole thing with an eye glass and this what I deduced from it.
> 
> It would be helpful if you could explain what part of the language
> is unclear wrt. explaining how CoC does not apply to existing code.
> 
> That part seems very explicit to me.

Well, now that I re-read it, it was this part to be exact:

"Maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other
contributions that are not aligned to this Code of Conduct, or to ban
temporarily or permanently any contributor for other behaviors that they
deem inappropriate, threatening, offensive, or harmful."

How this should be interpreted?

I have not really followed the previous CoC discussions as I try to
always use polite language so I'm sorry if this duplicate.

/Jarkko

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[James Bottomley]

On Fri, 2018-11-30 at 13:44 -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
> > No because use of what some people consider to be bad language
> > isn't necessarily abusive, offensive or degrading.  Our most
> > heavily censored medium is TV and "fuck" is now considered
> > acceptable in certain contexts on most channels in the UK and EU.
> 
> This makes following the CoC extremely hard to a non-native speaker
> as it is not too explicit on what is OK and what is not. I did
> through the whole thing with an eye glass and this what I deduced
> from it.

OK, so something that would simply be considered in some quarters as
bad language isn't explicitly banned.  The thing which differentiates
simple bad language from "abusive, offensive or degrading language",
which is called out by the CoC, is the context and the target.

So when it's a simple expletive or the code of the author or even the
hardware is the target, I'd say it's an easy determination it's not a
CoC violation.  If someone else's code is the target or the inventor of
the hardware is targetted by name, I'd say it is.  Even non-native
English speakers should be able to determine target and context,
because that's the essence of meaning.

James

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[James Bottomley]

On Fri, 2018-11-30 at 13:54 -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 01:48:08PM -0800, David Miller wrote:
> > From: Jarkko Sakkinen 
> > Date: Fri, 30 Nov 2018 13:44:05 -0800
> > 
> > > On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
> > > > No because use of what some people consider to be bad language
> > > > isn't
> > > > necessarily abusive, offensive or degrading.  Our most heavily
> > > > censored
> > > > medium is TV and "fuck" is now considered acceptable in certain
> > > > contexts on most channels in the UK and EU.
> > > 
> > > This makes following the CoC extremely hard to a non-native
> > > speaker as
> > > it is not too explicit on what is OK and what is not. I did
> > > through the
> > > whole thing with an eye glass and this what I deduced from it.
> > 
> > It would be helpful if you could explain what part of the language
> > is unclear wrt. explaining how CoC does not apply to existing code.
> > 
> > That part seems very explicit to me.
> 
> Well, now that I re-read it, it was this part to be exact:
> 
> "Maintainers have the right and responsibility to remove, edit, or
> reject comments, commits, code, wiki edits, issues, and other
> contributions that are not aligned to this Code of Conduct, or to ban
> temporarily or permanently any contributor for other behaviors that
> they deem inappropriate, threatening, offensive, or harmful."
> 
> How this should be interpreted?

Firstly, this is *only* about contributions going forward.  The
interpretation document says we don't have to look back into the
repository and we definitely can't remove something from git that's
already been committed.

As a Maintainer, if you feel bad language is inappropriate for your
subsystem then you say so and reject with that reason patches that come
in containing it (suggesting alternative rewordings).  However, your
determination about what is or isn't acceptable in your subsystem isn't
binding on other maintainers, who may have different standards ... this
is identical to what we do with coding, like your insistence on one
line per variable or other subsystem's insistence on reverse christmas
tree for includes ...

James


> I have not really followed the previous CoC discussions as I try to
> always use polite language so I'm sorry if this duplicate.
> 
> /Jarkko
> 

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Jarkko Sakkinen]

On Fri, Nov 30, 2018 at 01:57:49PM -0800, James Bottomley wrote:
> On Fri, 2018-11-30 at 13:44 -0800, Jarkko Sakkinen wrote:
> > On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
> > > No because use of what some people consider to be bad language
> > > isn't necessarily abusive, offensive or degrading.  Our most
> > > heavily censored medium is TV and "fuck" is now considered
> > > acceptable in certain contexts on most channels in the UK and EU.
> > 
> > This makes following the CoC extremely hard to a non-native speaker
> > as it is not too explicit on what is OK and what is not. I did
> > through the whole thing with an eye glass and this what I deduced
> > from it.
> 
> OK, so something that would simply be considered in some quarters as
> bad language isn't explicitly banned.  The thing which differentiates
> simple bad language from "abusive, offensive or degrading language",
> which is called out by the CoC, is the context and the target.
> 
> So when it's a simple expletive or the code of the author or even the
> hardware is the target, I'd say it's an easy determination it's not a
> CoC violation.  If someone else's code is the target or the inventor of
> the hardware is targetted by name, I'd say it is.  Even non-native
> English speakers should be able to determine target and context,
> because that's the essence of meaning.

I pasted this already to another response and this was probably the part
that ignited me to send the patch set (was a few days ago, so had to
revisit to find the exact paragraph):

"Maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other
contributions that are not aligned to this Code of Conduct, or to ban
temporarily or permanently any contributor for other behaviors that they
deem inappropriate, threatening, offensive, or harmful."

The whole patch set is neither a joke/troll nor something I would
necessarily want to be include myself. It does have the RFC tag.

As a maintainer myself (and based on somewhat disturbed feedback from
other maintainers) I can only make the conclusion that nobody knows what
the responsibility part here means.

I would interpret, if I read it like at lawyer at least, that even for
existing code you would need to do the changes postmorterm.

Is this wrong interpretation?  Should I conclude that I made a mistake
by reading the CoC and trying to understand what it *actually* says?
After this discussion, I can say that I understand it less than before.

/Jarkko

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Jonathan Corbet]

On Fri, 30 Nov 2018 14:12:19 -0800
Jarkko Sakkinen  wrote:

> As a maintainer myself (and based on somewhat disturbed feedback from
> other maintainers) I can only make the conclusion that nobody knows what
> the responsibility part here means.
> 
> I would interpret, if I read it like at lawyer at least, that even for
> existing code you would need to do the changes postmorterm.
> 
> Is this wrong interpretation?  Should I conclude that I made a mistake
> by reading the CoC and trying to understand what it *actually* says?
> After this discussion, I can say that I understand it less than before.

Have you read Documentation/process/code-of-conduct-interpretation.rst?
As has been pointed out, it contains a clear answer to how things should
be interpreted here.

Thanks,

jon

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Jarkko Sakkinen]

On Fri, Nov 30, 2018 at 03:14:59PM -0700, Jonathan Corbet wrote:
> On Fri, 30 Nov 2018 14:12:19 -0800
> Jarkko Sakkinen  wrote:
> 
> > As a maintainer myself (and based on somewhat disturbed feedback from
> > other maintainers) I can only make the conclusion that nobody knows what
> > the responsibility part here means.
> > 
> > I would interpret, if I read it like at lawyer at least, that even for
> > existing code you would need to do the changes postmorterm.
> > 
> > Is this wrong interpretation?  Should I conclude that I made a mistake
> > by reading the CoC and trying to understand what it *actually* says?
> > After this discussion, I can say that I understand it less than before.
> 
> Have you read Documentation/process/code-of-conduct-interpretation.rst?
> As has been pointed out, it contains a clear answer to how things should
> be interpreted here.

Ugh, was not aware that there two documents.

Yeah, definitely sheds light. Why the documents could not be merged to
single common sense code of conduct?

/Jarkko

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[James Bottomley]

On Fri, 2018-11-30 at 14:12 -0800, Jarkko Sakkinen wrote:
[...]
> I pasted this already to another response and this was probably the
> part that ignited me to send the patch set (was a few days ago, so
> had to revisit to find the exact paragraph):

I replied in to the other thread.

> "Maintainers have the right and responsibility to remove, edit, or
> reject comments, commits, code, wiki edits, issues, and other
> contributions that are not aligned to this Code of Conduct, or to ban
> temporarily or permanently any contributor for other behaviors that
> they deem inappropriate, threatening, offensive, or harmful."
> 
> The whole patch set is neither a joke/troll nor something I would
> necessarily want to be include myself. It does have the RFC tag.
> 
> As a maintainer myself (and based on somewhat disturbed feedback from
> other maintainers) I can only make the conclusion that nobody knows
> what the responsibility part here means.
> 
> I would interpret, if I read it like at lawyer at least, that even
> for existing code you would need to do the changes postmorterm.

That's wrong in the light of the interpretation document, yes.

> Is this wrong interpretation?  Should I conclude that I made a
> mistake by reading the CoC and trying to understand what it
> *actually* says?

You can't read it in isolation, you need to read it along with the
interpretation document.  The latter was created precisely because
there was a lot of push back on interpretation problems and ambiguities
with the original CoC and it specifically covers this case (and a lot
of others).

James


> After this discussion, I can say that I understand it less than
> before.
> 
> /Jarkko
> 

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[James Bottomley]

On Fri, 2018-11-30 at 14:26 -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 03:14:59PM -0700, Jonathan Corbet wrote:
[...]
> > Have you read Documentation/process/code-of-conduct-
> > interpretation.rst? 
> > As has been pointed out, it contains a clear answer to how things
> > should be interpreted here.
> 
> Ugh, was not aware that there two documents.
> 
> Yeah, definitely sheds light. Why the documents could not be merged
> to single common sense code of conduct?

The fact that we've arrived at essentially an original CoC
reinterpreted to the point where it's effectively a new CoC has been
the source of much debate and recrimination over the last few months
... you can read it in the ksummit-discuss archives, but I really think
we don't want to reopen that can of worms.

James

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Jarkko Sakkinen]

On Fri, Nov 30, 2018 at 02:26:05PM -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 03:14:59PM -0700, Jonathan Corbet wrote:
> > On Fri, 30 Nov 2018 14:12:19 -0800
> > Jarkko Sakkinen  wrote:
> > 
> > > As a maintainer myself (and based on somewhat disturbed feedback from
> > > other maintainers) I can only make the conclusion that nobody knows what
> > > the responsibility part here means.
> > > 
> > > I would interpret, if I read it like at lawyer at least, that even for
> > > existing code you would need to do the changes postmorterm.
> > > 
> > > Is this wrong interpretation?  Should I conclude that I made a mistake
> > > by reading the CoC and trying to understand what it *actually* says?
> > > After this discussion, I can say that I understand it less than before.
> > 
> > Have you read Documentation/process/code-of-conduct-interpretation.rst?
> > As has been pointed out, it contains a clear answer to how things should
> > be interpreted here.
> 
> Ugh, was not aware that there two documents.
> 
> Yeah, definitely sheds light. Why the documents could not be merged to
> single common sense code of conduct?

I.e. if the latter that you pointed out tells you what you actually
should do what value does the former bring?

Just looked up archives and realized that there has been whole alot
of CoC related discussions. No wonder this is seen as waste of time.

/Jarkko

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Jarkko Sakkinen]

On Fri, Nov 30, 2018 at 02:30:45PM -0800, James Bottomley wrote:
> On Fri, 2018-11-30 at 14:26 -0800, Jarkko Sakkinen wrote:
> > On Fri, Nov 30, 2018 at 03:14:59PM -0700, Jonathan Corbet wrote:
> [...]
> > > Have you read Documentation/process/code-of-conduct-
> > > interpretation.rst? 
> > > As has been pointed out, it contains a clear answer to how things
> > > should be interpreted here.
> > 
> > Ugh, was not aware that there two documents.
> > 
> > Yeah, definitely sheds light. Why the documents could not be merged
> > to single common sense code of conduct?
> 
> The fact that we've arrived at essentially an original CoC
> reinterpreted to the point where it's effectively a new CoC has been
> the source of much debate and recrimination over the last few months
> ... you can read it in the ksummit-discuss archives, but I really think
> we don't want to reopen that can of worms.

Got you... Well I now read the 2nd amendment now through, and yeah, kind
of way I work/function anyway.

Thank you for the patience...

/Jarkko

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Jarkko Sakkinen]

On Fri, Nov 30, 2018 at 02:40:19PM -0800, Jarkko Sakkinen wrote:
> Got you... Well I now read the 2nd amendment now through, and yeah, kind
> of way I work/function anyway.

Ugh, looked up the word from dictionary for something that makes
additions to some guidelines because did not know the english word.
Not meant as a political reference of any kind. Just don't know
any better English word.

/Jarkko

Re: Possible regression in v4l2-async

[Sakari Ailus]

Hi Niklas,

On Fri, Nov 30, 2018 at 03:25:29AM +0100, Niklas Söderlund wrote:
> Hi Sakari, Steve,
> 
> Thanks for your quick response.
> 
> On 2018-11-29 22:37:53 +0200, Sakari Ailus wrote:
> > Hi Steve, Niklas,
> > 
> > On Thu, Nov 29, 2018 at 11:41:32AM -0800, Steve Longerbeam wrote:
> > > 
> > > 
> > > On 11/29/18 11:26 AM, Steve Longerbeam wrote:
> > > > Hi Niklas,
> > > > 
> > > > On 11/29/18 10:47 AM, Niklas Söderlund wrote:
> > > > > Hi Steve, Sakari and Hans,
> > > > > 
> > > > > I have been made aware of a possible regression by a few users of
> > > > > rcar-vin and I'm a bit puzzled how to best handle it. Maybe you can 
> > > > > help
> > > > > me out?
> > > > > 
> > > > > The issue is visible when running with LOCKDEP enabled and it prints a
> > > > > warning about a possible circular locking dependency, see end of mail.
> > > > > The warning is triggered because rcar-vin takes a mutex (group->lock) 
> > > > > in
> > > > > its async bound call back while the async framework already holds one
> > > > > (lisk_lock).
> > > > 
> > > > I see two possible solutions to this:
> > > > 
> > > > A. Remove acquiring the list_lock in v4l2_async_notifier_init().
> > > > 
> > > > B. Move the call to v4l2_async_notifier_init()**to the top of
> > > > rvin_mc_parse_of_graph() (before acquiring group->lock).
> > > > 
> > > > It's most likely safe to remove the list_lock from
> > > > v4l2_async_notifier_init(), because all drivers should be calling that
> > > > function at probe start, before it begins to add async subdev
> > > > descriptors to their notifiers. But just the same, I think it would be
> > > > safer to keep list_lock in v4l2_async_notifier_init(), just in case of
> > > > some strange corner case (such as a driver that adds descriptors in a
> > > > separate thread from the thread that calls v4l2_async_notifier_init()).
> > > 
> > > Well, on second thought that's probably a lame example, no driver should 
> > > be
> > > doing that. So removing the list_lock from v4l2_async_notifier_init() is
> > > probably safe. The notifier is not registered with v4l2-async at that 
> > > point.
> > 
> > I agree, apart from "probably". It is safe.
> > 
> > Niklas: would you like to send a patch? :-)
> 
> Thanks for your suggestions, I have sent a patch [1] for Steves 
> alternative A as I agree that is the correct approach to cure the 
> symptom of the problem and have value in its own right. Unfortunately 
> this do not cover the core of the problem.
> 
> As I tried to describe in my first mail, maybe I could have described it 
> better, sorry about that. This problem comes from the adding of 
> subdevices to notifiers using a list instead of a array allocated and 
> handled by the driver. Even with [1] applied a LOCKDEP warning is still 
> trigged (see end of mail) as one thread could be busy adding subdevs to 
> it's notifier using the fwnode helpers who take the list_lock as another 
> thread is busy processing and binding subdevices also holding the 
> list_lock. Then if a async callback implemented by a driver also takes a 
> driver local lock the warning is still triggered as described in my 
> first mail.

A stupid question perhaps... what are you serialising with the group lock?

> 
> 1. [PATCH] v4l2: async: remove locking when initializing async notifier
> 
> >> warning output <<
>  ==
>  WARNING: possible circular locking dependency detected
>  4.20.0-rc1-arm64-renesas-00141-gcadfba6a1339544c #58 Not tainted
>  --
>  swapper/0/1 is trying to acquire lock:
>  (ptrval) (&group->lock){+.+.}, at: rvin_group_notify_bound+0x30/0xa8
>  
>  but task is already holding lock:
>  (ptrval) (list_lock){+.+.}, at: 
> __v4l2_async_notifier_register+0x4c/0x140
>  
>  which lock already depends on the new lock.
>  
>  
>  the existing dependency chain (in reverse order) is:
>  
>  -> #1 (list_lock){+.+.}:
> __mutex_lock+0x70/0x7e0
> mutex_lock_nested+0x1c/0x28
> v4l2_async_notifier_add_subdev+0x2c/0x78
> __v4l2_async_notifier_parse_fwnode_ep+0x17c/0x310
> v4l2_async_notifier_parse_fwnode_endpoints_by_port+0x14/0x20
> rcar_vin_probe+0x174/0x638
> platform_drv_probe+0x50/0xa0
> really_probe+0x1c8/0x2a8
> driver_probe_device+0x54/0xe8
> __driver_attach+0xf0/0xf8
> bus_for_each_dev+0x70/0xc0
> driver_attach+0x20/0x28
> bus_add_driver+0x1d4/0x200
> driver_register+0x60/0x110
> __platform_driver_register+0x44/0x50
> rcar_vin_driver_init+0x18/0x20
> do_one_initcall+0x180/0x35c
> kernel_init_freeable+0x450/0x4f4
> kernel_init+0x10/0xfc
> ret_from_fork+0x10/0x1c
>  
>  -> #0 (&group->lock){+.+.}:
> lock_acquire+0xc8/0x238
> __mutex_lock+0x70/0x7e0
> mutex_lock_nested+0x1c/0x28
> rvin_group_notify_bound+0x30/0xa8
>  

Re: [PATCH RFC 00/15] Zero ****s, hugload of hugs <3

[Jarkko Sakkinen]

On Fri, Nov 30, 2018 at 08:39:01PM +, Abuse wrote:
> On Friday, 30 November 2018 20:35:07 GMT David Miller wrote:
> > From: Jens Axboe 
> > Date: Fri, 30 Nov 2018 13:12:26 -0700
> > 
> > > On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
> > >> On Fri, 30 Nov 2018, Kees Cook wrote:
> > >> 
> > >>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> > >>>  wrote:
> > 
> >  In order to comply with the CoC, replace  with a hug.
> > >> 
> > >> I hope this is some kind of joke. How would anyone get offended by 
> > >> reading
> > >> technical comments? This is all beyond me...
> > > 
> > > Agree, this is insanity.
> > 
> > And even worse it is censorship.
> > 
> 
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> Fuck
> 
> I assume I will now be barred.
> 
> 

Thank you for taking the opportunity to practice free speech in the
always so welcoming and inclusive on-line world :-) Now I'll just have
to find my notebook and write this prose down so that I'll never forget
it. Thanks again.

/Jarkko