Re: [PATCH v2 0/9] phy: Add configuration interface for MIPI D-PHY devices

2018-12-06 Thread Kishon Vijay Abraham I
Maxime,

On 06/11/18 8:24 PM, Maxime Ripard wrote:
> Hi,
> 
> Here is a set of patches to allow the phy framework consumers to test and
> apply runtime configurations.
> 
> This is needed to support more phy classes that require tuning based on
> parameters depending on the current use case of the device, in addition to
> the power state management already provided by the current functions.
> 
> A first test bed for that API are the MIPI D-PHY devices. There's a number
> of solutions that have been used so far to support these phy, most of the
> time being an ad-hoc driver in the consumer.
> 
> That approach has a big shortcoming though, which is that this is quite
> difficult to deal with consumers integrated with multiple variants of phy,
> of multiple consumers integrated with the same phy.
> 
> The latter case can be found in the Cadence DSI bridge, and the CSI
> transceiver and receivers. All of them are integrated with the same phy, or
> can be integrated with different phy, depending on the implementation.
> 
> I've looked at all the MIPI DSI drivers I could find, and gathered all the
> parameters I could find. The interface should be complete, and most of the
> drivers can be converted in the future. The current set converts two of
> them: the above mentionned Cadence DSI driver so that the v4l2 drivers can
> use them, and the Allwinner MIPI-DSI driver.

Are you planning to send one more revision of this series after fixing the
comments?

Thanks
Kishon
> 
> Let me know what you think,
> Maxime
> 
> Changes from v1:
>   - Rebased on top of 4.20-rc1
>   - Removed the bus mode and timings parameters from the MIPI D-PHY
> parameters, since that shouldn't have any impact on the PHY itself.
>   - Reworked the Cadence DSI and D-PHY drivers to take this into account.
>   - Remove the mode parameter from phy_configure
>   - Added phy_configure and phy_validate stubs
>   - Return -EOPNOTSUPP in phy_configure and phy_validate when the operation
> is not implemented
> 
> Maxime Ripard (9):
>   phy: Add MIPI D-PHY mode
>   phy: Add configuration interface
>   phy: Add MIPI D-PHY configuration options
>   phy: dphy: Add configuration helpers
>   sun6i: dsi: Convert to generic phy handling
>   phy: Move Allwinner A31 D-PHY driver to drivers/phy/
>   drm/bridge: cdns: Separate DSI and D-PHY configuration
>   phy: Add Cadence D-PHY support
>   drm/bridge: cdns: Convert to phy framework
> 
>  Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt |  21 +-
>  Documentation/devicetree/bindings/phy/cdns,dphy.txt   |  20 +-
>  drivers/gpu/drm/bridge/cdns-dsi.c | 535 +--
>  drivers/gpu/drm/sun4i/Kconfig |   3 +-
>  drivers/gpu/drm/sun4i/Makefile|   5 +-
>  drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c   | 292 +
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c|  31 +-
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h|  17 +-
>  drivers/phy/Kconfig   |   8 +-
>  drivers/phy/Makefile  |   1 +-
>  drivers/phy/allwinner/Kconfig |  12 +-
>  drivers/phy/allwinner/Makefile|   1 +-
>  drivers/phy/allwinner/phy-sun6i-mipi-dphy.c   | 318 -
>  drivers/phy/cadence/Kconfig   |  13 +-
>  drivers/phy/cadence/Makefile  |   1 +-
>  drivers/phy/cadence/cdns-dphy.c   | 459 ++-
>  drivers/phy/phy-core-mipi-dphy.c  | 160 ++-
>  drivers/phy/phy-core.c|  61 +-
>  include/linux/phy/phy-mipi-dphy.h | 238 +++-
>  include/linux/phy/phy.h   |  65 +-
>  20 files changed, 1482 insertions(+), 779 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt
>  delete mode 100644 drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
>  create mode 100644 drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
>  create mode 100644 drivers/phy/cadence/cdns-dphy.c
>  create mode 100644 drivers/phy/phy-core-mipi-dphy.c
>  create mode 100644 include/linux/phy/phy-mipi-dphy.h
> 
> base-commit: 651022382c7f8da46cb4872a545ee1da6d097d2a
> 


cron job: media_tree daily build: ERRORS

2018-12-06 Thread Hans Verkuil
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Fri Dec  7 05:00:15 CET 2018
media-tree git hash:3c28b91380dd1183347d32d87d820818031ebecf
media_build git hash:   4b9237c73e29ea969f6a7b3d00030e14be50
v4l-utils git hash: 7086a1ee8dda5ae34852379410432d259215ff5e
edid-decode git hash:   6def7bc83dfb0338632e06a8b14c93faa6af8879
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: ERRORS
linux-3.10.108-x86_64: ERRORS
linux-3.11.10-i686: ERRORS
linux-3.11.10-x86_64: ERRORS
linux-3.12.74-i686: ERRORS
linux-3.12.74-x86_64: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.79-i686: ERRORS
linux-3.14.79-x86_64: ERRORS
linux-3.15.10-i686: ERRORS
linux-3.15.10-x86_64: ERRORS
linux-3.16.57-i686: ERRORS
linux-3.16.57-x86_64: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.123-i686: ERRORS
linux-3.18.123-x86_64: ERRORS
linux-3.19.8-i686: ERRORS
linux-3.19.8-x86_64: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.52-i686: ERRORS
linux-4.1.52-x86_64: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.159-i686: ERRORS
linux-4.4.159-x86_64: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.10-i686: ERRORS
linux-4.7.10-x86_64: ERRORS
linux-4.8.17-i686: ERRORS
linux-4.8.17-x86_64: ERRORS
linux-4.9.131-i686: ERRORS
linux-4.9.131-x86_64: ERRORS
linux-4.10.17-i686: ERRORS
linux-4.10.17-x86_64: ERRORS
linux-4.11.12-i686: ERRORS
linux-4.11.12-x86_64: ERRORS
linux-4.12.14-i686: ERRORS
linux-4.12.14-x86_64: ERRORS
linux-4.13.16-i686: ERRORS
linux-4.13.16-x86_64: ERRORS
linux-4.14.74-i686: ERRORS
linux-4.14.74-x86_64: ERRORS
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/Friday.log

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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


RE,

2018-12-06 Thread Sharifah Ahmad Mustahfa




--
Hello

  First of all i will like to apologies for my manner of 
communication because you do not know me personally, its due to the fact 
that i have a very important proposal for you.


[PATCH v8 15/17] media: v4l: Add Intel IPU3 meta buffer formats

2018-12-06 Thread Yong Zhi
Add IPU3-specific meta formats for processing parameters and
3A statistics.

  V4L2_META_FMT_IPU3_PARAMS
  V4L2_META_FMT_IPU3_STAT_3A

Signed-off-by: Yong Zhi 
Reviewed-by: Laurent Pinchart 
---
 Documentation/media/uapi/v4l/meta-formats.rst  |   1 +
 .../media/uapi/v4l/pixfmt-meta-intel-ipu3.rst  | 178 +
 drivers/media/v4l2-core/v4l2-ioctl.c   |   2 +
 include/uapi/linux/videodev2.h |   4 +
 4 files changed, 185 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst

diff --git a/Documentation/media/uapi/v4l/meta-formats.rst 
b/Documentation/media/uapi/v4l/meta-formats.rst
index 438bd244bd2f..5f956fa784b7 100644
--- a/Documentation/media/uapi/v4l/meta-formats.rst
+++ b/Documentation/media/uapi/v4l/meta-formats.rst
@@ -19,6 +19,7 @@ These formats are used for the :ref:`metadata` interface only.
 .. toctree::
 :maxdepth: 1
 
+pixfmt-meta-intel-ipu3
 pixfmt-meta-d4xx
 pixfmt-meta-uvc
 pixfmt-meta-vsp1-hgo
diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst 
b/Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
new file mode 100644
index ..8cd30ffbf8b8
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
@@ -0,0 +1,178 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _v4l2-meta-fmt-params:
+.. _v4l2-meta-fmt-stat-3a:
+
+**
+V4L2_META_FMT_IPU3_PARAMS ('ip3p'), V4L2_META_FMT_IPU3_3A ('ip3s')
+**
+
+.. c:type:: ipu3_uapi_stats_3a
+
+3A statistics
+=
+
+For IPU3 ImgU, the 3A statistics accelerators collect different statistics over
+an input bayer frame. Those statistics, defined in data struct 
:c:type:`ipu3_uapi_stats_3a`,
+are obtained from "ipu3-imgu 3a stat" metadata capture video node, which are 
then
+passed to user space for statistics analysis using :c:type:`v4l2_meta_format` 
interface.
+
+The statistics collected are AWB (Auto-white balance) RGBS (Red, Green, Blue 
and
+Saturation measure) cells, AWB filter response, AF (Auto-focus) filter 
response,
+and AE (Auto-exposure) histogram.
+
+struct :c:type:`ipu3_uapi_4a_config` saves configurable parameters for all 
above.
+
+.. code-block:: c
+
+   struct ipu3_uapi_stats_3a {
+   struct ipu3_uapi_awb_raw_buffer awb_raw_buffer;
+   struct ipu3_uapi_ae_raw_buffer_aligned 
ae_raw_buffer[IPU3_UAPI_MAX_STRIPES];
+   struct ipu3_uapi_af_raw_buffer af_raw_buffer;
+   struct ipu3_uapi_awb_fr_raw_buffer awb_fr_raw_buffer;
+   struct ipu3_uapi_4a_config stats_4a_config;
+   __u32 ae_join_buffers;
+   __u8 padding[28];
+   struct ipu3_uapi_stats_3a_bubble_info_per_stripe 
stats_3a_bubble_per_stripe;
+   struct ipu3_uapi_ff_status stats_3a_status;
+   };
+
+.. c:type:: ipu3_uapi_params
+
+Pipeline parameters
+===
+
+IPU3 pipeline has a number of image processing stages, each of which takes a
+set of parameters as input. The major stages of pipelines are shown here:
+
+Raw pixels -> Bayer Downscaling -> Optical Black Correction ->
+
+Linearization -> Lens Shading Correction -> White Balance / Exposure /
+
+Focus Apply -> Bayer Noise Reduction -> ANR -> Demosaicing -> Color
+
+Correction Matrix -> Gamma correction -> Color Space Conversion ->
+
+Chroma Down Scaling -> Chromatic Noise Reduction -> Total Color
+
+Correction -> XNR3 -> TNR -> DDR
+
+The table below presents a description of the above algorithms.
+
+ 
===
+NameDescription
+ 
===
+Optical Black Correction Optical Black Correction block subtracts a pre-defined
+value from the respective pixel values to obtain better
+image quality.
+Defined in :c:type:`ipu3_uapi_obgrid_param`.
+Linearization   This algo block uses linearization parameters to
+address non-linearity sensor effects. The Lookup table
+table is defined in
+:c:type:`ipu3_uapi_isp_lin_vmem_params`.
+SHD Lens shading correction is used to correct spatial
+non-uniformity of the pixel response due to optical
+lens shading. This is done by applying a different gain
+for each pixel. The gain, black level etc are
+configured in :c:type:`ipu3_uapi_shd_config_static`.
+BNR Bayer noise reduction block removes image noise by
+applying a bilateral filter.
+See :c:type:`ipu3_uapi_bnr_static_config` for details.
+ANR   

[PATCH v8 12/17] media: staging/intel-ipu3: Add imgu top level pci device driver

2018-12-06 Thread Yong Zhi
This patch adds support for the Intel IPU v3 as found
on Skylake and Kaby Lake SoCs.

The driver glues v4l2, css(camera sub system) and other
pieces together to perform its functions, it also loads
the IPU3 firmware binary as part of its initialization.

Signed-off-by: Yong Zhi 
Signed-off-by: Tomasz Figa 
---
 drivers/staging/media/Kconfig   |   2 +
 drivers/staging/media/Makefile  |   1 +
 drivers/staging/media/ipu3/Kconfig  |  14 +
 drivers/staging/media/ipu3/Makefile |  11 +
 drivers/staging/media/ipu3/TODO |  23 +
 drivers/staging/media/ipu3/ipu3.c   | 844 
 drivers/staging/media/ipu3/ipu3.h   | 152 +++
 7 files changed, 1047 insertions(+)
 create mode 100644 drivers/staging/media/ipu3/Kconfig
 create mode 100644 drivers/staging/media/ipu3/Makefile
 create mode 100644 drivers/staging/media/ipu3/TODO
 create mode 100644 drivers/staging/media/ipu3/ipu3.c
 create mode 100644 drivers/staging/media/ipu3/ipu3.h

diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig
index c6f3404dea43..19cadd17e542 100644
--- a/drivers/staging/media/Kconfig
+++ b/drivers/staging/media/Kconfig
@@ -39,4 +39,6 @@ source "drivers/staging/media/tegra-vde/Kconfig"
 
 source "drivers/staging/media/zoran/Kconfig"
 
+source "drivers/staging/media/ipu3/Kconfig"
+
 endif
diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile
index 43c7bee1fc8c..edde1960b030 100644
--- a/drivers/staging/media/Makefile
+++ b/drivers/staging/media/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_VIDEO_SUNXI)   += sunxi/
 obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/
 obj-$(CONFIG_VIDEO_ZORAN)  += zoran/
 obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/
+obj-$(CONFIG_VIDEO_IPU3_IMGU)  += ipu3/
diff --git a/drivers/staging/media/ipu3/Kconfig 
b/drivers/staging/media/ipu3/Kconfig
new file mode 100644
index ..75cd889f18f7
--- /dev/null
+++ b/drivers/staging/media/ipu3/Kconfig
@@ -0,0 +1,14 @@
+config VIDEO_IPU3_IMGU
+   tristate "Intel ipu3-imgu driver"
+   depends on PCI && VIDEO_V4L2
+   depends on MEDIA_CONTROLLER && VIDEO_V4L2_SUBDEV_API
+   depends on X86
+   select IOMMU_IOVA
+   select VIDEOBUF2_DMA_SG
+   ---help---
+ This is the Video4Linux2 driver for Intel IPU3 image processing unit,
+ found in Intel Skylake and Kaby Lake SoCs and used for processing
+ images and video.
+
+ Say Y or M here if you have a Skylake/Kaby Lake SoC with a MIPI
+ camera. The module will be called ipu3-imgu.
diff --git a/drivers/staging/media/ipu3/Makefile 
b/drivers/staging/media/ipu3/Makefile
new file mode 100644
index ..fb146d178bd4
--- /dev/null
+++ b/drivers/staging/media/ipu3/Makefile
@@ -0,0 +1,11 @@
+#
+# Makefile for the IPU3 ImgU drivers
+#
+
+ipu3-imgu-objs += \
+   ipu3-mmu.o ipu3-dmamap.o \
+   ipu3-tables.o ipu3-css-pool.o \
+   ipu3-css-fw.o ipu3-css-params.o \
+   ipu3-css.o ipu3-v4l2.o ipu3.o
+
+obj-$(CONFIG_VIDEO_IPU3_IMGU) += ipu3-imgu.o
diff --git a/drivers/staging/media/ipu3/TODO b/drivers/staging/media/ipu3/TODO
new file mode 100644
index ..922b885f10a7
--- /dev/null
+++ b/drivers/staging/media/ipu3/TODO
@@ -0,0 +1,23 @@
+This is a list of things that need to be done to get this driver out of the
+staging directory.
+
+- Request API conversion. Remove of the dual pipeline and associate buffers
+  as well as formats and the binary used to a request. Remove the
+  opportunistic buffer management. (Sakari)
+
+- Using ENABLED and IMMUTABLE link flags for the links where those are
+  relevant. (Sakari)
+
+- Prefix imgu for all public APIs, i.e. change ipu3_v4l2_register() to
+  imgu_v4l2_register(). (Sakari)
+
+- Use V4L2_CTRL_TYPE_MENU for dual-pipe mode control. (Sakari)
+
+- IPU3 driver documentation (Laurent)
+  Add diagram in driver rst to describe output capability.
+  Comments on configuring v4l2 subdevs for CIO2 and ImgU.
+
+- uAPI documentation:
+  Further clarification on some ambiguities such as data type conversion of
+  IEFD CU inputs. (Sakari)
+  Move acronyms to doc-rst file. (Mauro)
diff --git a/drivers/staging/media/ipu3/ipu3.c 
b/drivers/staging/media/ipu3/ipu3.c
new file mode 100644
index ..3d0a34b86ff4
--- /dev/null
+++ b/drivers/staging/media/ipu3/ipu3.c
@@ -0,0 +1,844 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 - 2018 Intel Corporation
+ * Copyright 2017 Google LLC
+ *
+ * Based on Intel IPU4 driver.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "ipu3.h"
+#include "ipu3-dmamap.h"
+#include "ipu3-mmu.h"
+
+#define IMGU_PCI_ID0x1919
+#define IMGU_PCI_BAR   0
+#define IMGU_DMA_MASK  DMA_BIT_MASK(39)
+#define IMGU_MAX_QUEUE_DEPTH   (2 + 2)
+
+/*
+ * pre-allocated buffer size for IMGU dummy buffers. Those
+ * values should be tuned to big enough to avoid buffer
+ * re-allocation 

[PATCH v8 08/17] media: staging/intel-ipu3: css: Compute and program ccs

2018-12-06 Thread Yong Zhi
A collection of routines that are mainly used
to calculate the parameters for accelerator cluster.

Signed-off-by: Yong Zhi 
---
 drivers/staging/media/ipu3/ipu3-css-params.c | 2915 ++
 drivers/staging/media/ipu3/ipu3-css-params.h |   25 +
 2 files changed, 2940 insertions(+)
 create mode 100644 drivers/staging/media/ipu3/ipu3-css-params.c
 create mode 100644 drivers/staging/media/ipu3/ipu3-css-params.h

diff --git a/drivers/staging/media/ipu3/ipu3-css-params.c 
b/drivers/staging/media/ipu3/ipu3-css-params.c
new file mode 100644
index ..747352c089dd
--- /dev/null
+++ b/drivers/staging/media/ipu3/ipu3-css-params.c
@@ -0,0 +1,2915 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Intel Corporation
+
+#include 
+
+#include "ipu3-css.h"
+#include "ipu3-css-fw.h"
+#include "ipu3-tables.h"
+
+#define DIV_ROUND_CLOSEST_DOWN(a, b)   (((a) + ((b) / 2) - 1) / (b))
+#define roundclosest_down(a, b)(DIV_ROUND_CLOSEST_DOWN(a, b) * 
(b))
+
+#define IPU3_UAPI_ANR_MAX_RESET((1 << 12) - 1)
+#define IPU3_UAPI_ANR_MIN_RESET(((-1) << 12) + 1)
+
+struct ipu3_css_scaler_info {
+   unsigned int phase_step;/* Same for luma/chroma */
+   int exp_shift;
+
+   unsigned int phase_init;/* luma/chroma dependent */
+   int pad_left;
+   int pad_right;
+   int crop_left;
+   int crop_top;
+};
+
+static unsigned int ipu3_css_scaler_get_exp(unsigned int counter,
+   unsigned int divider)
+{
+   int i = fls(divider) - fls(counter);
+
+   if (i <= 0)
+   return 0;
+
+   if (divider >> i < counter)
+   i = i - 1;
+
+   return i;
+}
+
+/* Set up the CSS scaler look up table */
+static void
+ipu3_css_scaler_setup_lut(unsigned int taps, unsigned int input_width,
+ unsigned int output_width, int phase_step_correction,
+ const int *coeffs, unsigned int coeffs_size,
+ s8 coeff_lut[], struct ipu3_css_scaler_info *info)
+{
+   int tap, phase, phase_sum_left, phase_sum_right;
+   int exponent = ipu3_css_scaler_get_exp(output_width, input_width);
+   int mantissa = (1 << exponent) * output_width;
+   unsigned int phase_step;
+
+   if (input_width == output_width) {
+   for (phase = 0; phase < IMGU_SCALER_PHASES; phase++) {
+   for (tap = 0; tap < taps; tap++) {
+   coeff_lut[phase * IMGU_SCALER_FILTER_TAPS + tap]
+   = 0;
+   }
+   }
+
+   info->phase_step = IMGU_SCALER_PHASES *
+   (1 << IMGU_SCALER_PHASE_COUNTER_PREC_REF);
+   info->exp_shift = 0;
+   info->pad_left = 0;
+   info->pad_right = 0;
+   info->phase_init = 0;
+   info->crop_left = 0;
+   info->crop_top = 0;
+   return;
+   }
+
+   for (phase = 0; phase < IMGU_SCALER_PHASES; phase++) {
+   for (tap = 0; tap < taps; tap++) {
+   /* flip table to for convolution reverse indexing */
+   s64 coeff = coeffs[coeffs_size -
+   ((tap * (coeffs_size / taps)) + phase) - 1];
+   coeff *= mantissa;
+   coeff = div64_long(coeff, input_width);
+
+   /* Add +"0.5" */
+   coeff += 1 << (IMGU_SCALER_COEFF_BITS - 1);
+   coeff >>= IMGU_SCALER_COEFF_BITS;
+
+   coeff_lut[phase * IMGU_SCALER_FILTER_TAPS + tap] =
+   coeff;
+   }
+   }
+
+   phase_step = IMGU_SCALER_PHASES *
+   (1 << IMGU_SCALER_PHASE_COUNTER_PREC_REF) *
+   output_width / input_width;
+   phase_step += phase_step_correction;
+   phase_sum_left = (taps / 2 * IMGU_SCALER_PHASES *
+   (1 << IMGU_SCALER_PHASE_COUNTER_PREC_REF)) -
+   (1 << (IMGU_SCALER_PHASE_COUNTER_PREC_REF - 1));
+   phase_sum_right = (taps / 2 * IMGU_SCALER_PHASES *
+   (1 << IMGU_SCALER_PHASE_COUNTER_PREC_REF)) +
+   (1 << (IMGU_SCALER_PHASE_COUNTER_PREC_REF - 1));
+
+   info->exp_shift = IMGU_SCALER_MAX_EXPONENT_SHIFT - exponent;
+   info->pad_left = (phase_sum_left % phase_step == 0) ?
+   phase_sum_left / phase_step - 1 : phase_sum_left / phase_step;
+   info->pad_right = (phase_sum_right % phase_step == 0) ?
+   phase_sum_right / phase_step - 1 : phase_sum_right / phase_step;
+   info->phase_init = phase_sum_left - phase_step * info->pad_left;
+   info->phase_step = phase_step;
+   info->crop_left = taps - 1;
+   info->crop_top = taps - 1;
+}
+
+/*
+ * Calculates the exact output image width/he

[PATCH v8 06/17] media: staging/intel-ipu3: css: Add support for firmware management

2018-12-06 Thread Yong Zhi
Introduce functions to load and install ImgU FW blobs.

Signed-off-by: Yong Zhi 
---
 drivers/staging/media/ipu3/ipu3-css-fw.c | 264 +++
 drivers/staging/media/ipu3/ipu3-css-fw.h | 188 ++
 2 files changed, 452 insertions(+)
 create mode 100644 drivers/staging/media/ipu3/ipu3-css-fw.c
 create mode 100644 drivers/staging/media/ipu3/ipu3-css-fw.h

diff --git a/drivers/staging/media/ipu3/ipu3-css-fw.c 
b/drivers/staging/media/ipu3/ipu3-css-fw.c
new file mode 100644
index ..ba459e98d77d
--- /dev/null
+++ b/drivers/staging/media/ipu3/ipu3-css-fw.c
@@ -0,0 +1,264 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Intel Corporation
+
+#include 
+#include 
+#include 
+#include 
+
+#include "ipu3-css.h"
+#include "ipu3-css-fw.h"
+#include "ipu3-dmamap.h"
+
+static void ipu3_css_fw_show_binary(struct device *dev, struct imgu_fw_info 
*bi,
+   const char *name)
+{
+   unsigned int i;
+
+   dev_dbg(dev, "found firmware binary type %i size %i name %s\n",
+   bi->type, bi->blob.size, name);
+   if (bi->type != IMGU_FW_ISP_FIRMWARE)
+   return;
+
+   dev_dbg(dev, "id %i mode %i bds 0x%x veceven %i/%i out_pins %i\n",
+   bi->info.isp.sp.id, bi->info.isp.sp.pipeline.mode,
+   bi->info.isp.sp.bds.supported_bds_factors,
+   bi->info.isp.sp.enable.vf_veceven,
+   bi->info.isp.sp.vf_dec.is_variable,
+   bi->info.isp.num_output_pins);
+
+   dev_dbg(dev, "input (%i,%i)-(%i,%i) formats %s%s%s\n",
+   bi->info.isp.sp.input.min_width,
+   bi->info.isp.sp.input.min_height,
+   bi->info.isp.sp.input.max_width,
+   bi->info.isp.sp.input.max_height,
+   bi->info.isp.sp.enable.input_yuv ? "yuv420 " : "",
+   bi->info.isp.sp.enable.input_feeder ||
+   bi->info.isp.sp.enable.input_raw ? "raw8 raw10 " : "",
+   bi->info.isp.sp.enable.input_raw ? "raw12" : "");
+
+   dev_dbg(dev, "internal (%i,%i)\n",
+   bi->info.isp.sp.internal.max_width,
+   bi->info.isp.sp.internal.max_height);
+
+   dev_dbg(dev, "output (%i,%i)-(%i,%i) formats",
+   bi->info.isp.sp.output.min_width,
+   bi->info.isp.sp.output.min_height,
+   bi->info.isp.sp.output.max_width,
+   bi->info.isp.sp.output.max_height);
+   for (i = 0; i < bi->info.isp.num_output_formats; i++)
+   dev_dbg(dev, " %i", bi->info.isp.output_formats[i]);
+   dev_dbg(dev, " vf");
+   for (i = 0; i < bi->info.isp.num_vf_formats; i++)
+   dev_dbg(dev, " %i", bi->info.isp.vf_formats[i]);
+   dev_dbg(dev, "\n");
+}
+
+unsigned int ipu3_css_fw_obgrid_size(const struct imgu_fw_info *bi)
+{
+   unsigned int width = DIV_ROUND_UP(bi->info.isp.sp.internal.max_width,
+ IMGU_OBGRID_TILE_SIZE * 2) + 1;
+   unsigned int height = DIV_ROUND_UP(bi->info.isp.sp.internal.max_height,
+  IMGU_OBGRID_TILE_SIZE * 2) + 1;
+   unsigned int obgrid_size;
+
+   width = ALIGN(width, IPU3_UAPI_ISP_VEC_ELEMS / 4);
+   obgrid_size = PAGE_ALIGN(width * height *
+sizeof(struct ipu3_uapi_obgrid_param)) *
+bi->info.isp.sp.iterator.num_stripes;
+   return obgrid_size;
+}
+
+void *ipu3_css_fw_pipeline_params(struct ipu3_css *css,
+ enum imgu_abi_param_class c,
+ enum imgu_abi_memories m,
+ struct imgu_fw_isp_parameter *par,
+ size_t par_size, void *binary_params)
+{
+   struct imgu_fw_info *bi = &css->fwp->binary_header[css->current_binary];
+
+   if (par->offset + par->size >
+   bi->info.isp.sp.mem_initializers.params[c][m].size)
+   return NULL;
+
+   if (par->size != par_size)
+   pr_warn("parameter size doesn't match defined size\n");
+
+   if (par->size < par_size)
+   return NULL;
+
+   return binary_params + par->offset;
+}
+
+void ipu3_css_fw_cleanup(struct ipu3_css *css)
+{
+   struct imgu_device *imgu = dev_get_drvdata(css->dev);
+
+   if (css->binary) {
+   unsigned int i;
+
+   for (i = 0; i < css->fwp->file_header.binary_nr; i++)
+   ipu3_dmamap_free(imgu, &css->binary[i]);
+   kfree(css->binary);
+   }
+   if (css->fw)
+   release_firmware(css->fw);
+
+   css->binary = NULL;
+   css->fw = NULL;
+}
+
+int ipu3_css_fw_init(struct ipu3_css *css)
+{
+   static const u32 BLOCK_MAX = 65536;
+   struct imgu_device *imgu = dev_get_drvdata(css->dev);
+   struct device *dev = css->dev;
+   unsigned int i, j, binary_nr;
+   int r;
+
+   

[PATCH v8 10/17] media: staging/intel-ipu3: Add css pipeline programming

2018-12-06 Thread Yong Zhi
This provides helper library to be used by v4l2 level to program
imaging pipelines and control the streaming.

Signed-off-by: Yong Zhi 
---
 drivers/staging/media/ipu3/ipu3-css.c | 1740 +
 1 file changed, 1740 insertions(+)

diff --git a/drivers/staging/media/ipu3/ipu3-css.c 
b/drivers/staging/media/ipu3/ipu3-css.c
index 164830fc91ad..3811ad752e8d 100644
--- a/drivers/staging/media/ipu3/ipu3-css.c
+++ b/drivers/staging/media/ipu3/ipu3-css.c
@@ -16,6 +16,173 @@
 IMGU_IRQCTRL_IRQ_SW_PIN(0) | \
 IMGU_IRQCTRL_IRQ_SW_PIN(1))
 
+#define IPU3_CSS_FORMAT_BPP_DEN50  /* Denominator */
+
+/* Some sane limits for resolutions */
+#define IPU3_CSS_MIN_RES   32
+#define IPU3_CSS_MAX_H 3136
+#define IPU3_CSS_MAX_W 4224
+
+/* filter size from graph settings is fixed as 4 */
+#define FILTER_SIZE 4
+#define MIN_ENVELOPE8
+
+/*
+ * pre-allocated buffer size for CSS ABI, auxiliary frames
+ * after BDS and before GDC. Those values should be tuned
+ * to big enough to avoid buffer re-allocation when
+ * streaming to lower streaming latency.
+ */
+#define CSS_ABI_SIZE136
+#define CSS_BDS_SIZE(4480 * 3200 * 3)
+#define CSS_GDC_SIZE(4224 * 3200 * 12 / 8)
+
+#define IPU3_CSS_QUEUE_TO_FLAGS(q) (1 << (q))
+#define IPU3_CSS_FORMAT_FL_IN  \
+   IPU3_CSS_QUEUE_TO_FLAGS(IPU3_CSS_QUEUE_IN)
+#define IPU3_CSS_FORMAT_FL_OUT \
+   IPU3_CSS_QUEUE_TO_FLAGS(IPU3_CSS_QUEUE_OUT)
+#define IPU3_CSS_FORMAT_FL_VF  \
+   IPU3_CSS_QUEUE_TO_FLAGS(IPU3_CSS_QUEUE_VF)
+
+/* Formats supported by IPU3 Camera Sub System */
+static const struct ipu3_css_format ipu3_css_formats[] = {
+   {
+   .pixelformat = V4L2_PIX_FMT_NV12,
+   .colorspace = V4L2_COLORSPACE_SRGB,
+   .frame_format = IMGU_ABI_FRAME_FORMAT_NV12,
+   .osys_format = IMGU_ABI_OSYS_FORMAT_NV12,
+   .osys_tiling = IMGU_ABI_OSYS_TILING_NONE,
+   .bytesperpixel_num = 1 * IPU3_CSS_FORMAT_BPP_DEN,
+   .chroma_decim = 4,
+   .width_align = IPU3_UAPI_ISP_VEC_ELEMS,
+   .flags = IPU3_CSS_FORMAT_FL_OUT | IPU3_CSS_FORMAT_FL_VF,
+   }, {
+   /* Each 32 bytes contains 25 10-bit pixels */
+   .pixelformat = V4L2_PIX_FMT_IPU3_SBGGR10,
+   .colorspace = V4L2_COLORSPACE_RAW,
+   .frame_format = IMGU_ABI_FRAME_FORMAT_RAW_PACKED,
+   .bayer_order = IMGU_ABI_BAYER_ORDER_BGGR,
+   .bit_depth = 10,
+   .bytesperpixel_num = 64,
+   .width_align = 2 * IPU3_UAPI_ISP_VEC_ELEMS,
+   .flags = IPU3_CSS_FORMAT_FL_IN,
+   }, {
+   .pixelformat = V4L2_PIX_FMT_IPU3_SGBRG10,
+   .colorspace = V4L2_COLORSPACE_RAW,
+   .frame_format = IMGU_ABI_FRAME_FORMAT_RAW_PACKED,
+   .bayer_order = IMGU_ABI_BAYER_ORDER_GBRG,
+   .bit_depth = 10,
+   .bytesperpixel_num = 64,
+   .width_align = 2 * IPU3_UAPI_ISP_VEC_ELEMS,
+   .flags = IPU3_CSS_FORMAT_FL_IN,
+   }, {
+   .pixelformat = V4L2_PIX_FMT_IPU3_SGRBG10,
+   .colorspace = V4L2_COLORSPACE_RAW,
+   .frame_format = IMGU_ABI_FRAME_FORMAT_RAW_PACKED,
+   .bayer_order = IMGU_ABI_BAYER_ORDER_GRBG,
+   .bit_depth = 10,
+   .bytesperpixel_num = 64,
+   .width_align = 2 * IPU3_UAPI_ISP_VEC_ELEMS,
+   .flags = IPU3_CSS_FORMAT_FL_IN,
+   }, {
+   .pixelformat = V4L2_PIX_FMT_IPU3_SRGGB10,
+   .colorspace = V4L2_COLORSPACE_RAW,
+   .frame_format = IMGU_ABI_FRAME_FORMAT_RAW_PACKED,
+   .bayer_order = IMGU_ABI_BAYER_ORDER_RGGB,
+   .bit_depth = 10,
+   .bytesperpixel_num = 64,
+   .width_align = 2 * IPU3_UAPI_ISP_VEC_ELEMS,
+   .flags = IPU3_CSS_FORMAT_FL_IN,
+   },
+};
+
+static const struct {
+   enum imgu_abi_queue_id qid;
+   size_t ptr_ofs;
+} ipu3_css_queues[IPU3_CSS_QUEUES] = {
+   [IPU3_CSS_QUEUE_IN] = {
+   IMGU_ABI_QUEUE_C_ID,
+   offsetof(struct imgu_abi_buffer, payload.frame.frame_data)
+   },
+   [IPU3_CSS_QUEUE_OUT] = {
+   IMGU_ABI_QUEUE_D_ID,
+   offsetof(struct imgu_abi_buffer, payload.frame.frame_data)
+   },
+   [IPU3_CSS_QUEUE_VF] = {
+   IMGU_ABI_QUEUE_E_ID,
+   offsetof(struct imgu_abi_buffer, payload.frame.frame_data)
+   },
+   [IPU3_CSS_QUEUE_STAT_3A] = {
+   IMGU_ABI_QUEUE_F_ID,
+   offsetof(struct imgu_abi_buffer, payload.s3a.data_ptr)
+   },
+};
+
+/* Initialize queue based on given format, adjust format as needed */
+static int ipu3_css_queue_init(struct ipu3_css_queue *queue,
+

[PATCH v8 01/17] media: staging/intel-ipu3: abi: Add register definitions and enum

2018-12-06 Thread Yong Zhi
Add macros and enums used for IPU3 firmware interface.

Signed-off-by: Yong Zhi 
Signed-off-by: Rajmohan Mani 
Reviewed-by: Laurent Pinchart 
---
 drivers/staging/media/ipu3/ipu3-abi.h | 661 ++
 1 file changed, 661 insertions(+)
 create mode 100644 drivers/staging/media/ipu3/ipu3-abi.h

diff --git a/drivers/staging/media/ipu3/ipu3-abi.h 
b/drivers/staging/media/ipu3/ipu3-abi.h
new file mode 100644
index ..e754ff5836c2
--- /dev/null
+++ b/drivers/staging/media/ipu3/ipu3-abi.h
@@ -0,0 +1,661 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2018 Intel Corporation */
+
+#ifndef __IPU3_ABI_H
+#define __IPU3_ABI_H
+
+#include "include/intel-ipu3.h"
+
+/*** IMGU Hardware information ***/
+
+typedef u32 imgu_addr_t;
+
+#define IMGU_ISP_VMEM_ALIGN128
+#define IMGU_DVS_BLOCK_W   64
+#define IMGU_DVS_BLOCK_H   32
+#define IMGU_GDC_BUF_X (2 * IMGU_DVS_BLOCK_W)
+#define IMGU_GDC_BUF_Y IMGU_DVS_BLOCK_H
+/* n = 0..1 */
+#define IMGU_SP_PMEM_BASE(n)   (0x2 + (n) * 0x4000)
+#define IMGU_MAX_BQ_GRID_WIDTH 80
+#define IMGU_MAX_BQ_GRID_HEIGHT60
+#define IMGU_OBGRID_TILE_SIZE  16
+#define IMGU_PIXELS_PER_WORD   50
+#define IMGU_BYTES_PER_WORD64
+#define IMGU_STRIPE_FIXED_HALF_OVERLAP 2
+#define IMGU_SHD_SETS  3
+#define IMGU_BDS_MIN_CLIP_VAL  0
+#define IMGU_BDS_MAX_CLIP_VAL  2
+
+#define IMGU_ABI_AWB_MAX_CELLS_PER_SET 160
+#define IMGU_ABI_AF_MAX_CELLS_PER_SET  32
+#define IMGU_ABI_AWB_FR_MAX_CELLS_PER_SET  32
+
+#define IMGU_ABI_ACC_OP_IDLE   0
+#define IMGU_ABI_ACC_OP_END_OF_ACK 1
+#define IMGU_ABI_ACC_OP_END_OF_OPS 2
+#define IMGU_ABI_ACC_OP_NO_OPS 3
+
+#define IMGU_ABI_ACC_OPTYPE_PROCESS_LINES  0
+#define IMGU_ABI_ACC_OPTYPE_TRANSFER_DATA  1
+
+/* Register definitions */
+
+/* PM_CTRL_0_5_0_IMGHMMADR */
+#define IMGU_REG_PM_CTRL   0x0
+#define IMGU_PM_CTRL_START BIT(0)
+#define IMGU_PM_CTRL_CFG_DONE  BIT(1)
+#define IMGU_PM_CTRL_RACE_TO_HALT  BIT(2)
+#define IMGU_PM_CTRL_NACK_ALL  BIT(3)
+#define IMGU_PM_CTRL_CSS_PWRDN BIT(4)
+#define IMGU_PM_CTRL_RST_AT_EOFBIT(5)
+#define IMGU_PM_CTRL_FORCE_HALTBIT(6)
+#define IMGU_PM_CTRL_FORCE_UNHALT  BIT(7)
+#define IMGU_PM_CTRL_FORCE_PWRDN   BIT(8)
+#define IMGU_PM_CTRL_FORCE_RESET   BIT(9)
+
+/* SYSTEM_REQ_0_5_0_IMGHMMADR */
+#define IMGU_REG_SYSTEM_REQ0x18
+#define IMGU_SYSTEM_REQ_FREQ_MASK  0x3f
+#define IMGU_SYSTEM_REQ_FREQ_DIVIDER   25
+#define IMGU_REG_INT_STATUS0x30
+#define IMGU_REG_INT_ENABLE0x34
+#define IMGU_REG_INT_CSS_IRQ   BIT(31)
+/* STATE_0_5_0_IMGHMMADR */
+#define IMGU_REG_STATE 0x130
+#define IMGU_STATE_HALT_STSBIT(0)
+#define IMGU_STATE_IDLE_STSBIT(1)
+#define IMGU_STATE_POWER_UPBIT(2)
+#define IMGU_STATE_POWER_DOWN  BIT(3)
+#define IMGU_STATE_CSS_BUSY_MASK   0xc0
+#define IMGU_STATE_PM_FSM_MASK 0x180
+#define IMGU_STATE_PWRDNM_FSM_MASK 0x1E0
+/* PM_STS_0_5_0_IMGHMMADR */
+#define IMGU_REG_PM_STS0x140
+
+#define IMGU_REG_BASE  0x4000
+
+#define IMGU_REG_ISP_CTRL  (IMGU_REG_BASE + 0x00)
+#define IMGU_CTRL_RST  BIT(0)
+#define IMGU_CTRL_STARTBIT(1)
+#define IMGU_CTRL_BREAKBIT(2)
+#define IMGU_CTRL_RUN  BIT(3)
+#define IMGU_CTRL_BROKEN   BIT(4)
+#define IMGU_CTRL_IDLE BIT(5)
+#define IMGU_CTRL_SLEEPING BIT(6)
+#define IMGU_CTRL_STALLING BIT(7)
+#define IMGU_CTRL_IRQ_CLEARBIT(8)
+#define IMGU_CTRL_IRQ_READYBIT(10)
+#define IMGU_CTRL_IRQ_SLEEPING BIT(11)
+#define IMGU_CTRL_ICACHE_INV   BIT(12)
+#define IMGU_CTRL_IPREFETCH_EN BIT(13)
+#define IMGU_REG_ISP_START_ADDR(IMGU_REG_BASE + 0x04)
+#define IMGU_REG_ISP_ICACHE_ADDR   (IMGU_REG_BASE + 0x10)
+#define IMGU_REG_ISP_PC(IMGU_REG_BASE + 0x1c)
+
+/* SP Registers, sp = 0:SP0; 1:SP1 */
+#define IMGU_REG_SP_CTRL(sp)   (IMGU_REG_BASE + (sp) * 0x100 + 0x100)
+   /* For bits in IMGU_REG_SP_CTRL, see IMGU_CTRL_* */
+#define IMGU_REG_S

[PATCH v8 00/17] Intel IPU3 ImgU patchset

2018-12-06 Thread Yong Zhi
Hi,

This series adds support for the Intel IPU3 (Image Processing Unit)
ImgU which is essentially a modern memory-to-memory ISP. It implements
raw Bayer to YUV image format conversion as well as a large number of
other pixel processing algorithms for improving the image quality.

Meta data formats are defined for image statistics (3A, i.e. automatic
white balance, exposure and focus, histogram and local area contrast
enhancement) as well as for the pixel processing algorithm parameters.
The documentation for these formats is currently not included in the
patchset but will be added in a future version of this set.

The algorithm parameters need to be considered specific to a given frame
and typically a large number of these parameters change on frame to frame
basis. Additionally, the parameters are highly structured (and not a flat
space of independent configuration primitives). They also reflect the
data structures used by the firmware and the hardware. On top of that,
the algorithms require highly specialized user space to make meaningful
use of them. For these reasons it has been chosen video buffers to pass
the parameters to the device.

On individual patches:

The heart of ImgU is the CSS, or Camera Subsystem, which contains the
image processors and HW accelerators.

The 3A statistics and other firmware parameter computation related
functions are implemented in patch 8.

All IPU3 pipeline default settings can be found in patch 7.

To access DDR via ImgU's own memory space, IPU3 is also equipped with
its own MMU unit, the driver is implemented in patch 3.

Patch 4 uses above driver for DMA mapping operation.

The communication between IPU3 firmware and driver is implemented with circular
queues in patch 5.

Patch 6 provide some utility functions and manage IPU3 fw download and
install.

The firmware which is called ipu3-fw.bin can be downloaded from:

git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
(commit 2c27b0cb02f18c022d8378e0e1abaf8b7ae8188f)

Firmware ABI is defined in patches 1 and 2.

Patches 9 and 10 are of the same file, the former contains all h/w programming
related code, the latter implements interface functions for access fw & hw
capabilities.

Patch 11 implements a v4l2 media framework driver.

Patch 12 represents the top level that glues all of the other components 
together,
passing arguments between the components.

Patch 14 is a recent effort to extend v6 for advanced camera features like
Continuous View Finder (CVF) and Snapshot During Video(SDV) support.

The whole series has a dependency on Sakari's work:

https://git.linuxtv.org/sailus/media_tree.git/log/?h=meta-output>

Patches not to be merged with staging:

Patch 15 Add v4l IPU3 meta formats.
Patch 16 Reserve v4l2 controls for IPU3 ImgU driver.
Patch 17 Documentation of ImgU driver.

Link to user space implementation:

git clone https://chromium.googlesource.com/chromiumos/platform/arc-camera

ImgU media topology print:

# media-ctl -d /dev/media0 -p
Media controller API version 4.20.0

Media device information

driver  ipu3-imgu
model   ipu3-imgu
serial  
bus infoPCI::00:05.0
hw revision 0x80862015
driver version  4.20.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:FIXED/1920x1080 field:none colorspace:raw
 crop:(0,0)/1920x1080
 compose:(0,0)/1920x1080]
<- "ipu3-imgu 0 input":0 []
pad1: Sink
[fmt:FIXED/1920x1080 field:none colorspace:raw]
<- "ipu3-imgu 0 parameters":0 []
pad2: Source
[fmt:FIXED/1920x1080 field:none colorspace:raw]
-> "ipu3-imgu 0 output":0 []
pad3: Source
[fmt:FIXED/1920x1080 field:none colorspace:raw]
-> "ipu3-imgu 0 viewfinder":0 []
pad4: Source
[fmt:FIXED/1920x1080 field:none colorspace:raw]
-> "ipu3-imgu 0 3a stat":0 []

- entity 7: ipu3-imgu 0 input (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Source
-> "ipu3-imgu 0":0 []

- entity 13: ipu3-imgu 0 parameters (1 pad, 1 link)
 type Node subtype V4L flags 0
 device node name /dev/video1
pad0: Source
-> "ipu3-imgu 0":1 []

- entity 19: ipu3-imgu 0 output (1 pad, 1 link)
 type Node subtype V4L flags 0
 device node name /dev/video2
pad0: Sink
<- "ipu3-imgu 0":2 []

- entity 25: ipu3-imgu 0 viewfinder (1 pad, 1 link)
 type Node subtype V4L flags 0
 device node name /dev/video3
pad0: Sink
<- "ipu3-imgu 0":3 []

- entity 31: ipu3-imgu 0 3a stat (1 pad, 1 link)
 type Node subtype V4L fl

[PATCH v8 11/17] media: staging/intel-ipu3: Add v4l2 driver based on media framework

2018-12-06 Thread Yong Zhi
Implement video driver that utilizes v4l2, vb2 queue support
and media controller APIs. The driver exposes single subdevice and
six nodes.

Signed-off-by: Yong Zhi 
---
 drivers/staging/media/ipu3/ipu3-v4l2.c | 1086 
 1 file changed, 1086 insertions(+)
 create mode 100644 drivers/staging/media/ipu3/ipu3-v4l2.c

diff --git a/drivers/staging/media/ipu3/ipu3-v4l2.c 
b/drivers/staging/media/ipu3/ipu3-v4l2.c
new file mode 100644
index ..038ee749cb75
--- /dev/null
+++ b/drivers/staging/media/ipu3/ipu3-v4l2.c
@@ -0,0 +1,1086 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Intel Corporation
+
+#include 
+#include 
+
+#include 
+
+#include "ipu3.h"
+#include "ipu3-dmamap.h"
+
+/ v4l2_subdev_ops /
+
+static int ipu3_subdev_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
+{
+   struct v4l2_rect try_crop = {
+   .top = 0,
+   .left = 0,
+   .width = 1920,
+   .height = 1080,
+   };
+   unsigned int i;
+
+   /* Initialize try_fmt */
+   for (i = 0; i < IMGU_NODE_NUM; i++) {
+   struct v4l2_mbus_framefmt *try_fmt =
+   v4l2_subdev_get_try_format(sd, fh->pad, i);
+
+   try_fmt->width = try_crop.width;
+   try_fmt->height = try_crop.height;
+   try_fmt->code = MEDIA_BUS_FMT_FIXED;
+   try_fmt->colorspace = V4L2_COLORSPACE_RAW;
+   try_fmt->field = V4L2_FIELD_NONE;
+   }
+
+   *v4l2_subdev_get_try_crop(sd, fh->pad, IMGU_NODE_IN) = try_crop;
+   *v4l2_subdev_get_try_compose(sd, fh->pad, IMGU_NODE_IN) = try_crop;
+
+   return 0;
+}
+
+static int ipu3_subdev_s_stream(struct v4l2_subdev *sd, int enable)
+{
+   struct imgu_device *imgu = container_of(sd, struct imgu_device, subdev);
+   int r = 0;
+
+   r = imgu_s_stream(imgu, enable);
+   if (!r)
+   imgu->streaming = enable;
+
+   return r;
+}
+
+static int ipu3_subdev_get_fmt(struct v4l2_subdev *sd,
+  struct v4l2_subdev_pad_config *cfg,
+  struct v4l2_subdev_format *fmt)
+{
+   struct imgu_device *imgu = container_of(sd, struct imgu_device, subdev);
+   struct v4l2_mbus_framefmt *mf;
+   u32 pad = fmt->pad;
+
+   if (fmt->which == V4L2_SUBDEV_FORMAT_ACTIVE) {
+   fmt->format = imgu->nodes[pad].pad_fmt;
+   } else {
+   mf = v4l2_subdev_get_try_format(sd, cfg, pad);
+   fmt->format = *mf;
+   }
+
+   return 0;
+}
+
+static int ipu3_subdev_set_fmt(struct v4l2_subdev *sd,
+  struct v4l2_subdev_pad_config *cfg,
+  struct v4l2_subdev_format *fmt)
+{
+   struct imgu_device *imgu = container_of(sd, struct imgu_device, subdev);
+   struct v4l2_mbus_framefmt *mf;
+   u32 pad = fmt->pad;
+
+   if (fmt->which == V4L2_SUBDEV_FORMAT_TRY)
+   mf = v4l2_subdev_get_try_format(sd, cfg, pad);
+   else
+   mf = &imgu->nodes[pad].pad_fmt;
+
+   fmt->format.code = mf->code;
+   /* Clamp the w and h based on the hardware capabilities */
+   if (imgu->subdev_pads[pad].flags & MEDIA_PAD_FL_SOURCE) {
+   fmt->format.width = clamp(fmt->format.width,
+ IPU3_OUTPUT_MIN_WIDTH,
+ IPU3_OUTPUT_MAX_WIDTH);
+   fmt->format.height = clamp(fmt->format.height,
+  IPU3_OUTPUT_MIN_HEIGHT,
+  IPU3_OUTPUT_MAX_HEIGHT);
+   } else {
+   fmt->format.width = clamp(fmt->format.width,
+ IPU3_INPUT_MIN_WIDTH,
+ IPU3_INPUT_MAX_WIDTH);
+   fmt->format.height = clamp(fmt->format.height,
+  IPU3_INPUT_MIN_HEIGHT,
+  IPU3_INPUT_MAX_HEIGHT);
+   }
+
+   *mf = fmt->format;
+
+   return 0;
+}
+
+static int ipu3_subdev_get_selection(struct v4l2_subdev *sd,
+struct v4l2_subdev_pad_config *cfg,
+struct v4l2_subdev_selection *sel)
+{
+   struct imgu_device *imgu = container_of(sd, struct imgu_device, subdev);
+   struct v4l2_rect *try_sel, *r;
+
+   if (sel->pad != IMGU_NODE_IN)
+   return -EINVAL;
+
+   switch (sel->target) {
+   case V4L2_SEL_TGT_CROP:
+   try_sel = v4l2_subdev_get_try_crop(sd, cfg, sel->pad);
+   r = &imgu->rect.eff;
+   break;
+   case V4L2_SEL_TGT_COMPOSE:
+   try_sel = v4l2_subdev_get_try_compose(sd, cfg, sel->pad);
+   r = &imgu->rect.bds;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   i

[PATCH v8 13/17] media: staging/intel-ipu3: Add Intel IPU3 meta data uAPI

2018-12-06 Thread Yong Zhi
These meta formats are used on Intel IPU3 ImgU video queues
to carry 3A statistics and ISP pipeline parameters.

V4L2_META_FMT_IPU3_3A
V4L2_META_FMT_IPU3_PARAMS

Signed-off-by: Yong Zhi 
Signed-off-by: Chao C Li 
Signed-off-by: Rajmohan Mani 
---
 drivers/staging/media/ipu3/include/intel-ipu3.h | 2775 +++
 1 file changed, 2775 insertions(+)
 create mode 100644 drivers/staging/media/ipu3/include/intel-ipu3.h

diff --git a/drivers/staging/media/ipu3/include/intel-ipu3.h 
b/drivers/staging/media/ipu3/include/intel-ipu3.h
new file mode 100644
index ..07fd66817358
--- /dev/null
+++ b/drivers/staging/media/ipu3/include/intel-ipu3.h
@@ -0,0 +1,2775 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2017 - 2018 Intel Corporation */
+
+#ifndef __IPU3_UAPI_H
+#define __IPU3_UAPI_H
+
+#include 
+
+/* from /drivers/staging/media/ipu3/include/videodev2.h */
+
+/* Vendor specific - used for IPU3 camera sub-system */
+#define V4L2_META_FMT_IPU3_PARAMS  v4l2_fourcc('i', 'p', '3', 'p') /* IPU3 
processing parameters */
+#define V4L2_META_FMT_IPU3_STAT_3A v4l2_fourcc('i', 'p', '3', 's') /* IPU3 
3A statistics */
+
+/*** ipu3_uapi_stats_3a ***/
+
+#define IPU3_UAPI_MAX_STRIPES  2
+#define IPU3_UAPI_MAX_BUBBLE_SIZE  10
+
+#define IPU3_UAPI_GRID_START_MASK  ((1 << 12) - 1)
+#define IPU3_UAPI_GRID_Y_START_EN  (1 << 15)
+
+/* controls generation of meta_data (like FF enable/disable) */
+#define IPU3_UAPI_AWB_RGBS_THR_B_EN(1 << 14)
+#define IPU3_UAPI_AWB_RGBS_THR_B_INCL_SAT  (1 << 15)
+
+/**
+ * struct ipu3_uapi_grid_config - Grid plane config
+ *
+ * @width: Grid horizontal dimensions, in number of grid blocks(cells).
+ * @height:Grid vertical dimensions, in number of grid cells.
+ * @block_width_log2:  Log2 of the width of each cell in pixels.
+ * for (2^3, 2^4, 2^5, 2^6, 2^7), values [3, 7].
+ * @block_height_log2: Log2 of the height of each cell in pixels.
+ * for (2^3, 2^4, 2^5, 2^6, 2^7), values [3, 7].
+ * @height_per_slice:  The number of blocks in vertical axis per slice.
+ * Default 2.
+ * @x_start: X value of top left corner of Region of Interest(ROI).
+ * @y_start: Y value of top left corner of ROI
+ * @x_end: X value of bottom right corner of ROI
+ * @y_end: Y value of bottom right corner of ROI
+ *
+ * Due to the size of total amount of collected data, most statistics
+ * create a grid-based output, and the data is then divided into "slices".
+ */
+struct ipu3_uapi_grid_config {
+   __u8 width;
+   __u8 height;
+   __u16 block_width_log2:3;
+   __u16 block_height_log2:3;
+   __u16 height_per_slice:8;
+   __u16 x_start;
+   __u16 y_start;
+   __u16 x_end;
+   __u16 y_end;
+} __packed;
+
+/*
+ * The grid based data is divided into "slices" called set, each slice of setX
+ * refers to ipu3_uapi_grid_config width * height_per_slice.
+ */
+#define IPU3_UAPI_AWB_MAX_SETS 60
+/* Based on grid size 80 * 60 and cell size 16 x 16 */
+#define IPU3_UAPI_AWB_SET_SIZE 1280
+#define IPU3_UAPI_AWB_MD_ITEM_SIZE 8
+#define IPU3_UAPI_AWB_SPARE_FOR_BUBBLES \
+   (IPU3_UAPI_MAX_BUBBLE_SIZE * IPU3_UAPI_MAX_STRIPES * \
+IPU3_UAPI_AWB_MD_ITEM_SIZE)
+#define IPU3_UAPI_AWB_MAX_BUFFER_SIZE \
+   (IPU3_UAPI_AWB_MAX_SETS * \
+(IPU3_UAPI_AWB_SET_SIZE + IPU3_UAPI_AWB_SPARE_FOR_BUBBLES))
+
+
+/**
+ * struct ipu3_uapi_awb_raw_buffer - AWB raw buffer
+ *
+ * @meta_data: buffer to hold auto white balance meta data which is
+ * the average values for each color channel.
+ */
+struct ipu3_uapi_awb_raw_buffer {
+   __u8 meta_data[IPU3_UAPI_AWB_MAX_BUFFER_SIZE]
+   __attribute__((aligned(32)));
+} __packed;
+
+/**
+ * struct ipu3_uapi_awb_config_s - AWB config
+ *
+ * @rgbs_thr_gr: gr threshold value.
+ * @rgbs_thr_r: Red threshold value.
+ * @rgbs_thr_gb: gb threshold value.
+ * @rgbs_thr_b: Blue threshold value.
+ * @grid: &ipu3_uapi_grid_config, the default grid resolution is 16x16 cells.
+ *
+ * The threshold is a saturation measure range [0, 8191], 8191 is default.
+ * Values over threshold may be optionally rejected for averaging.
+ */
+struct ipu3_uapi_awb_config_s {
+   __u16 rgbs_thr_gr;
+   __u16 rgbs_thr_r;
+   __u16 rgbs_thr_gb;
+   __u16 rgbs_thr_b;
+   struct ipu3_uapi_grid_config grid;
+} __attribute__((aligned(32))) __packed;
+
+/**
+ * struct ipu3_uapi_awb_config - AWB config wrapper
+ *
+ * @config: config for auto white balance as defined by &ipu3_uapi_awb_config_s
+ */
+struct ipu3_uapi_awb_config {
+   struct ipu3_uapi_awb_config_s config __attribute__((aligned(32)));
+} __packed;
+
+#define IPU3_UAPI_AE_COLORS4   /* R, G, B, Y */
+#define IPU3_UAPI_AE_BINS

[PATCH v8 05/17] media: staging/intel-ipu3: css: Add dma buff pool utility functions

2018-12-06 Thread Yong Zhi
The pools are used to store previous parameters set by
user with the parameter queue. Due to pipelining,
there needs to be multiple sets (up to four)
of parameters which are queued in a host-to-sp queue.

Signed-off-by: Yong Zhi 
---
 drivers/staging/media/ipu3/ipu3-css-pool.c | 100 +
 drivers/staging/media/ipu3/ipu3-css-pool.h |  55 
 2 files changed, 155 insertions(+)
 create mode 100644 drivers/staging/media/ipu3/ipu3-css-pool.c
 create mode 100644 drivers/staging/media/ipu3/ipu3-css-pool.h

diff --git a/drivers/staging/media/ipu3/ipu3-css-pool.c 
b/drivers/staging/media/ipu3/ipu3-css-pool.c
new file mode 100644
index ..6f271f81669b
--- /dev/null
+++ b/drivers/staging/media/ipu3/ipu3-css-pool.c
@@ -0,0 +1,100 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Intel Corporation
+
+#include 
+
+#include "ipu3.h"
+#include "ipu3-css-pool.h"
+#include "ipu3-dmamap.h"
+
+int ipu3_css_dma_buffer_resize(struct imgu_device *imgu,
+  struct ipu3_css_map *map, size_t size)
+{
+   if (map->size < size && map->vaddr) {
+   dev_warn(&imgu->pci_dev->dev, "dma buf resized from %zu to %zu",
+map->size, size);
+
+   ipu3_dmamap_free(imgu, map);
+   if (!ipu3_dmamap_alloc(imgu, map, size))
+   return -ENOMEM;
+   }
+
+   return 0;
+}
+
+void ipu3_css_pool_cleanup(struct imgu_device *imgu, struct ipu3_css_pool 
*pool)
+{
+   unsigned int i;
+
+   for (i = 0; i < IPU3_CSS_POOL_SIZE; i++)
+   ipu3_dmamap_free(imgu, &pool->entry[i].param);
+}
+
+int ipu3_css_pool_init(struct imgu_device *imgu, struct ipu3_css_pool *pool,
+  size_t size)
+{
+   unsigned int i;
+
+   for (i = 0; i < IPU3_CSS_POOL_SIZE; i++) {
+   pool->entry[i].valid = false;
+   if (size == 0) {
+   pool->entry[i].param.vaddr = NULL;
+   continue;
+   }
+
+   if (!ipu3_dmamap_alloc(imgu, &pool->entry[i].param, size))
+   goto fail;
+   }
+
+   pool->last = IPU3_CSS_POOL_SIZE;
+
+   return 0;
+
+fail:
+   ipu3_css_pool_cleanup(imgu, pool);
+   return -ENOMEM;
+}
+
+/*
+ * Allocate a new parameter via recycling the oldest entry in the pool.
+ */
+void ipu3_css_pool_get(struct ipu3_css_pool *pool)
+{
+   /* Get the oldest entry */
+   u32 n = (pool->last + 1) % IPU3_CSS_POOL_SIZE;
+
+   pool->entry[n].valid = true;
+   pool->last = n;
+}
+
+/*
+ * Undo, for all practical purposes, the effect of pool_get().
+ */
+void ipu3_css_pool_put(struct ipu3_css_pool *pool)
+{
+   pool->entry[pool->last].valid = false;
+   pool->last = (pool->last + IPU3_CSS_POOL_SIZE - 1) % IPU3_CSS_POOL_SIZE;
+}
+
+/**
+ * ipu3_css_pool_last - Retrieve the nth pool entry from last
+ *
+ * @pool: a pointer to &struct ipu3_css_pool.
+ * @n: the distance to the last index.
+ *
+ * Returns:
+ *  The nth entry from last or null map to indicate no frame stored.
+ */
+const struct ipu3_css_map *
+ipu3_css_pool_last(struct ipu3_css_pool *pool, unsigned int n)
+{
+   static const struct ipu3_css_map null_map = { 0 };
+   int i = (pool->last + IPU3_CSS_POOL_SIZE - n) % IPU3_CSS_POOL_SIZE;
+
+   WARN_ON(n >= IPU3_CSS_POOL_SIZE);
+
+   if (!pool->entry[i].valid)
+   return &null_map;
+
+   return &pool->entry[i].param;
+}
diff --git a/drivers/staging/media/ipu3/ipu3-css-pool.h 
b/drivers/staging/media/ipu3/ipu3-css-pool.h
new file mode 100644
index ..9c895efd2bfa
--- /dev/null
+++ b/drivers/staging/media/ipu3/ipu3-css-pool.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2018 Intel Corporation */
+
+#ifndef __IPU3_UTIL_H
+#define __IPU3_UTIL_H
+
+struct device;
+struct imgu_device;
+
+#define IPU3_CSS_POOL_SIZE 4
+
+/**
+ * ipu3_css_map - store DMA mapping info for buffer
+ *
+ * @size:  size of the buffer in bytes.
+ * @vaddr: kernel virtual address.
+ * @daddr: iova dma address to access IPU3.
+ * @vma:   private, a pointer to &struct vm_struct,
+ * used for ipu3_dmamap_free.
+ */
+struct ipu3_css_map {
+   size_t size;
+   void *vaddr;
+   dma_addr_t daddr;
+   struct vm_struct *vma;
+};
+
+/**
+ * ipu3_css_pool - circular buffer pool definition
+ *
+ * @entry: array with IPU3_CSS_POOL_SIZE elements.
+ * @entry.param:   a &struct ipu3_css_map for storing the mem mapping.
+ * @entry.valid:   used to mark if the entry has vaid data.
+ * @last:  write pointer, initialized to IPU3_CSS_POOL_SIZE.
+ */
+struct ipu3_css_pool {
+   struct {
+   struct ipu3_css_map param;
+   bool valid;
+   } entry[IPU3_CSS_POOL_SIZE];
+   u32 last;
+};
+
+int ipu3_css_dma_buffer_resize(struct imgu_device *img

[PATCH v8 04/17] media: staging/intel-ipu3: Implement DMA mapping functions

2018-12-06 Thread Yong Zhi
From: Tomasz Figa 

This driver uses IOVA space for buffer mapping through IPU3 MMU
to transfer data between imaging pipelines and system DDR.

Signed-off-by: Tomasz Figa 
Signed-off-by: Yong Zhi 
---
 drivers/staging/media/ipu3/ipu3-dmamap.c | 270 +++
 drivers/staging/media/ipu3/ipu3-dmamap.h |  22 +++
 2 files changed, 292 insertions(+)
 create mode 100644 drivers/staging/media/ipu3/ipu3-dmamap.c
 create mode 100644 drivers/staging/media/ipu3/ipu3-dmamap.h

diff --git a/drivers/staging/media/ipu3/ipu3-dmamap.c 
b/drivers/staging/media/ipu3/ipu3-dmamap.c
new file mode 100644
index ..93a393d4e15e
--- /dev/null
+++ b/drivers/staging/media/ipu3/ipu3-dmamap.c
@@ -0,0 +1,270 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Intel Corporation
+ * Copyright 2018 Google LLC.
+ *
+ * Author: Tomasz Figa 
+ * Author: Yong Zhi 
+ */
+
+#include 
+
+#include "ipu3.h"
+#include "ipu3-css-pool.h"
+#include "ipu3-mmu.h"
+
+/*
+ * Free a buffer allocated by ipu3_dmamap_alloc_buffer()
+ */
+static void ipu3_dmamap_free_buffer(struct page **pages,
+   size_t size)
+{
+   int count = size >> PAGE_SHIFT;
+
+   while (count--)
+   __free_page(pages[count]);
+   kvfree(pages);
+}
+
+/*
+ * Based on the implementation of __iommu_dma_alloc_pages()
+ * defined in drivers/iommu/dma-iommu.c
+ */
+static struct page **ipu3_dmamap_alloc_buffer(size_t size,
+ unsigned long order_mask,
+ gfp_t gfp)
+{
+   struct page **pages;
+   unsigned int i = 0, count = size >> PAGE_SHIFT;
+   const gfp_t high_order_gfp = __GFP_NOWARN | __GFP_NORETRY;
+
+   /* Allocate mem for array of page ptrs */
+   pages = kvmalloc_array(count, sizeof(*pages), GFP_KERNEL);
+
+   if (!pages)
+   return NULL;
+
+   order_mask &= (2U << MAX_ORDER) - 1;
+   if (!order_mask)
+   return NULL;
+
+   gfp |= __GFP_HIGHMEM | __GFP_ZERO;
+
+   while (count) {
+   struct page *page = NULL;
+   unsigned int order_size;
+
+   for (order_mask &= (2U << __fls(count)) - 1;
+order_mask; order_mask &= ~order_size) {
+   unsigned int order = __fls(order_mask);
+
+   order_size = 1U << order;
+   page = alloc_pages((order_mask - order_size) ?
+  gfp | high_order_gfp : gfp, order);
+   if (!page)
+   continue;
+   if (!order)
+   break;
+   if (!PageCompound(page)) {
+   split_page(page, order);
+   break;
+   }
+
+   __free_pages(page, order);
+   }
+   if (!page) {
+   ipu3_dmamap_free_buffer(pages, i << PAGE_SHIFT);
+   return NULL;
+   }
+   count -= order_size;
+   while (order_size--)
+   pages[i++] = page++;
+   }
+
+   return pages;
+}
+
+/**
+ * ipu3_dmamap_alloc - allocate and map a buffer into KVA
+ * @imgu: struct device pointer
+ * @map: struct to store mapping variables
+ * @len: size required
+ *
+ * Returns:
+ *  KVA on success
+ *  %NULL on failure
+ */
+void *ipu3_dmamap_alloc(struct imgu_device *imgu, struct ipu3_css_map *map,
+   size_t len)
+{
+   unsigned long shift = iova_shift(&imgu->iova_domain);
+   unsigned int alloc_sizes = imgu->mmu->pgsize_bitmap;
+   struct device *dev = &imgu->pci_dev->dev;
+   size_t size = PAGE_ALIGN(len);
+   struct page **pages;
+   dma_addr_t iovaddr;
+   struct iova *iova;
+   int i, rval;
+
+   dev_dbg(dev, "%s: allocating %zu\n", __func__, size);
+
+   iova = alloc_iova(&imgu->iova_domain, size >> shift,
+ imgu->mmu->aperture_end >> shift, 0);
+   if (!iova)
+   return NULL;
+
+   pages = ipu3_dmamap_alloc_buffer(size, alloc_sizes >> PAGE_SHIFT,
+GFP_KERNEL);
+   if (!pages)
+   goto out_free_iova;
+
+   /* Call IOMMU driver to setup pgt */
+   iovaddr = iova_dma_addr(&imgu->iova_domain, iova);
+   for (i = 0; i < size / PAGE_SIZE; ++i) {
+   rval = ipu3_mmu_map(imgu->mmu, iovaddr,
+   page_to_phys(pages[i]), PAGE_SIZE);
+   if (rval)
+   goto out_unmap;
+
+   iovaddr += PAGE_SIZE;
+   }
+
+   /* Now grab a virtual region */
+   map->vma = __get_vm_area(size, VM_USERMAP, VMALLOC_START, VMALLOC_END);
+   if (!map->vma)
+   goto out_unmap;
+
+   map->vma->pages = pages;
+   /* And map it in K

[PATCH v8 02/17] media: staging/intel-ipu3: abi: Add structs

2018-12-06 Thread Yong Zhi
This add all the structs of IPU3 firmware ABI.

Signed-off-by: Yong Zhi 
Signed-off-by: Rajmohan Mani 
Reviewed-by: Laurent Pinchart 
---
 drivers/staging/media/ipu3/ipu3-abi.h | 1350 +
 1 file changed, 1350 insertions(+)

diff --git a/drivers/staging/media/ipu3/ipu3-abi.h 
b/drivers/staging/media/ipu3/ipu3-abi.h
index e754ff5836c2..25be56ff01c8 100644
--- a/drivers/staging/media/ipu3/ipu3-abi.h
+++ b/drivers/staging/media/ipu3/ipu3-abi.h
@@ -658,4 +658,1354 @@ enum imgu_abi_stage_type {
IMGU_ABI_STAGE_TYPE_ISP,
 };
 
+struct imgu_abi_acc_operation {
+   /*
+* zero means on init,
+* others mean upon receiving an ack signal from the BC acc.
+*/
+   u8 op_indicator;
+   u8 op_type;
+} __packed;
+
+struct imgu_abi_acc_process_lines_cmd_data {
+   u16 lines;
+   u8 cfg_set;
+   u8 reserved;/* Align to 4 bytes */
+} __packed;
+
+/* Bayer shading definitions */
+
+struct imgu_abi_shd_transfer_luts_set_data {
+   u8 set_number;
+   u8 padding[3];
+   imgu_addr_t rg_lut_ddr_addr;
+   imgu_addr_t bg_lut_ddr_addr;
+   u32 align_dummy;
+} __packed;
+
+struct imgu_abi_shd_grid_config {
+   /* reg 0 */
+   u32 grid_width:8;
+   u32 grid_height:8;
+   u32 block_width:3;
+   u32 reserved0:1;
+   u32 block_height:3;
+   u32 reserved1:1;
+   u32 grid_height_per_slice:8;
+   /* reg 1 */
+   s32 x_start:13;
+   s32 reserved2:3;
+   s32 y_start:13;
+   s32 reserved3:3;
+} __packed;
+
+struct imgu_abi_shd_general_config {
+   u32 init_set_vrt_offst_ul:8;
+   u32 shd_enable:1;
+   /* aka 'gf' */
+   u32 gain_factor:2;
+   u32 reserved:21;
+} __packed;
+
+struct imgu_abi_shd_black_level_config {
+   /* reg 0 */
+   s32 bl_r:12;
+   s32 reserved0:4;
+   s32 bl_gr:12;
+   u32 reserved1:1;
+   /* aka 'nf' */
+   u32 normalization_shift:3;
+   /* reg 1 */
+   s32 bl_gb:12;
+   s32 reserved2:4;
+   s32 bl_b:12;
+   s32 reserved3:4;
+} __packed;
+
+struct imgu_abi_shd_intra_frame_operations_data {
+   struct imgu_abi_acc_operation
+   operation_list[IMGU_ABI_SHD_MAX_OPERATIONS] __aligned(32);
+   struct imgu_abi_acc_process_lines_cmd_data
+   process_lines_data[IMGU_ABI_SHD_MAX_PROCESS_LINES] 
__aligned(32);
+   struct imgu_abi_shd_transfer_luts_set_data
+   transfer_data[IMGU_ABI_SHD_MAX_TRANSFERS] __aligned(32);
+} __packed;
+
+struct imgu_abi_shd_config {
+   struct ipu3_uapi_shd_config_static shd __aligned(32);
+   struct imgu_abi_shd_intra_frame_operations_data shd_ops __aligned(32);
+   struct ipu3_uapi_shd_lut shd_lut __aligned(32);
+} __packed;
+
+struct imgu_abi_stripe_input_frame_resolution {
+   u16 width;
+   u16 height;
+   u32 bayer_order;/* enum ipu3_uapi_bayer_order */
+   u32 raw_bit_depth;
+} __packed;
+
+/* Stripe-based processing */
+
+struct imgu_abi_stripes {
+   /* offset from start of frame - measured in pixels */
+   u16 offset;
+   /* stripe width - measured in pixels */
+   u16 width;
+   /* stripe width - measured in pixels */
+   u16 height;
+} __packed;
+
+struct imgu_abi_stripe_data {
+   /*
+* number of stripes for current processing source
+* - VLIW binary parameter we currently support 1 or 2 stripes
+*/
+   u16 num_of_stripes;
+
+   u8 padding[2];
+
+   /*
+* the following data is derived from resolution-related
+* pipe config and from num_of_stripes
+*/
+
+   /*
+*'input-stripes' - before input cropping
+* used by input feeder
+*/
+   struct imgu_abi_stripe_input_frame_resolution input_frame;
+
+   /*'effective-stripes' - after input cropping used dpc, bds */
+   struct imgu_abi_stripes effective_stripes[IPU3_UAPI_MAX_STRIPES];
+
+   /* 'down-scaled-stripes' - after down-scaling ONLY. used by BDS */
+   struct imgu_abi_stripes down_scaled_stripes[IPU3_UAPI_MAX_STRIPES];
+
+   /*
+*'bds-out-stripes' - after bayer down-scaling and padding.
+* used by all algos starting with norm up to the ref-frame for GDC
+* (currently up to the output kernel)
+*/
+   struct imgu_abi_stripes bds_out_stripes[IPU3_UAPI_MAX_STRIPES];
+
+   /* 'bds-out-stripes (no overlap)' - used for ref kernel */
+   struct imgu_abi_stripes
+   bds_out_stripes_no_overlap[IPU3_UAPI_MAX_STRIPES];
+
+   /*
+* input resolution for output system (equal to bds_out - envelope)
+* output-system input frame width as configured by user
+*/
+   u16 output_system_in_frame_width;
+   /* output-system input frame height as configured by user */
+   u16 output_system_in_frame_height;
+
+   /*
+* 'output-stripes' - accounts for stiching on the output (no overlap)
+* 

[PATCH v8 03/17] media: staging/intel-ipu3: mmu: Implement driver

2018-12-06 Thread Yong Zhi
From: Tomasz Figa 

This driver translates IO virtual address to physical
address based on two levels page tables.

Signed-off-by: Tomasz Figa 
Signed-off-by: Yong Zhi 
---
 drivers/staging/media/ipu3/ipu3-mmu.c | 561 ++
 drivers/staging/media/ipu3/ipu3-mmu.h |  35 +++
 2 files changed, 596 insertions(+)
 create mode 100644 drivers/staging/media/ipu3/ipu3-mmu.c
 create mode 100644 drivers/staging/media/ipu3/ipu3-mmu.h

diff --git a/drivers/staging/media/ipu3/ipu3-mmu.c 
b/drivers/staging/media/ipu3/ipu3-mmu.c
new file mode 100644
index ..b9f209541f78
--- /dev/null
+++ b/drivers/staging/media/ipu3/ipu3-mmu.c
@@ -0,0 +1,561 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Intel Corporation.
+ * Copyright 2018 Google LLC.
+ *
+ * Author: Tuukka Toivonen 
+ * Author: Sakari Ailus 
+ * Author: Samu Onkalo 
+ * Author: Tomasz Figa 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "ipu3-mmu.h"
+
+#define IPU3_PAGE_SHIFT12
+#define IPU3_PAGE_SIZE (1UL << IPU3_PAGE_SHIFT)
+
+#define IPU3_PT_BITS   10
+#define IPU3_PT_PTES   (1UL << IPU3_PT_BITS)
+#define IPU3_PT_SIZE   (IPU3_PT_PTES << 2)
+#define IPU3_PT_ORDER  (IPU3_PT_SIZE >> PAGE_SHIFT)
+
+#define IPU3_ADDR2PTE(addr)((addr) >> IPU3_PAGE_SHIFT)
+#define IPU3_PTE2ADDR(pte) ((phys_addr_t)(pte) << IPU3_PAGE_SHIFT)
+
+#define IPU3_L2PT_SHIFTIPU3_PT_BITS
+#define IPU3_L2PT_MASK ((1UL << IPU3_L2PT_SHIFT) - 1)
+
+#define IPU3_L1PT_SHIFTIPU3_PT_BITS
+#define IPU3_L1PT_MASK ((1UL << IPU3_L1PT_SHIFT) - 1)
+
+#define IPU3_MMU_ADDRESS_BITS  (IPU3_PAGE_SHIFT + \
+IPU3_L2PT_SHIFT + \
+IPU3_L1PT_SHIFT)
+
+#define IMGU_REG_BASE  0x4000
+#define REG_TLB_INVALIDATE (IMGU_REG_BASE + 0x300)
+#define TLB_INVALIDATE 1
+#define REG_L1_PHYS(IMGU_REG_BASE + 0x304) /* 27-bit pfn */
+#define REG_GP_HALT(IMGU_REG_BASE + 0x5dc)
+#define REG_GP_HALTED  (IMGU_REG_BASE + 0x5e0)
+
+struct ipu3_mmu {
+   struct device *dev;
+   void __iomem *base;
+   /* protect access to l2pts, l1pt */
+   spinlock_t lock;
+
+   void *dummy_page;
+   u32 dummy_page_pteval;
+
+   u32 *dummy_l2pt;
+   u32 dummy_l2pt_pteval;
+
+   u32 **l2pts;
+   u32 *l1pt;
+
+   struct ipu3_mmu_info geometry;
+};
+
+static inline struct ipu3_mmu *to_ipu3_mmu(struct ipu3_mmu_info *info)
+{
+   return container_of(info, struct ipu3_mmu, geometry);
+}
+
+/**
+ * ipu3_mmu_tlb_invalidate - invalidate translation look-aside buffer
+ * @mmu: MMU to perform the invalidate operation on
+ *
+ * This function invalidates the whole TLB. Must be called when the hardware
+ * is powered on.
+ */
+static void ipu3_mmu_tlb_invalidate(struct ipu3_mmu *mmu)
+{
+   writel(TLB_INVALIDATE, mmu->base + REG_TLB_INVALIDATE);
+}
+
+static void call_if_ipu3_is_powered(struct ipu3_mmu *mmu,
+   void (*func)(struct ipu3_mmu *mmu))
+{
+   if (!pm_runtime_get_if_in_use(mmu->dev))
+   return;
+
+   func(mmu);
+   pm_runtime_put(mmu->dev);
+}
+
+/**
+ * ipu3_mmu_set_halt - set CIO gate halt bit
+ * @mmu: MMU to set the CIO gate bit in.
+ * @halt: Desired state of the gate bit.
+ *
+ * This function sets the CIO gate bit that controls whether external memory
+ * accesses are allowed. Must be called when the hardware is powered on.
+ */
+static void ipu3_mmu_set_halt(struct ipu3_mmu *mmu, bool halt)
+{
+   int ret;
+   u32 val;
+
+   writel(halt, mmu->base + REG_GP_HALT);
+   ret = readl_poll_timeout(mmu->base + REG_GP_HALTED,
+val, (val & 1) == halt, 1000, 10);
+
+   if (ret)
+   dev_err(mmu->dev, "failed to %s CIO gate halt\n",
+   halt ? "set" : "clear");
+}
+
+/**
+ * ipu3_mmu_alloc_page_table - allocate a pre-filled page table
+ * @pteval: Value to initialize for page table entries with.
+ *
+ * Return: Pointer to allocated page table or NULL on failure.
+ */
+static u32 *ipu3_mmu_alloc_page_table(u32 pteval)
+{
+   u32 *pt;
+   int pte;
+
+   pt = (u32 *)__get_free_page(GFP_KERNEL);
+   if (!pt)
+   return NULL;
+
+   for (pte = 0; pte < IPU3_PT_PTES; pte++)
+   pt[pte] = pteval;
+
+   set_memory_uc((unsigned long int)pt, IPU3_PT_ORDER);
+
+   return pt;
+}
+
+/**
+ * ipu3_mmu_free_page_table - free page table
+ * @pt: Page table to free.
+ */
+static void ipu3_mmu_free_page_table(u32 *pt)
+{
+   set_memory_wb((unsigned long int)pt, IPU3_PT_ORDER);
+   free_page((unsigned long)pt);
+}
+
+/**
+ * address_to_pte_idx - split IOVA into L1 and L2 page table indices
+ * @iova: IOVA to split.
+ * @l1pt_idx: Output for the L1 page table index.
+ * @l2pt_idx: Output for the L2 page index.

[PATCH v8 17/17] doc-rst: Add Intel IPU3 documentation

2018-12-06 Thread Yong Zhi
From: Rajmohan Mani 

This patch adds the details about the IPU3 Imaging Unit driver.

Change-Id: I560cecf673df2dcc3ec72767cf8077708d649656
Signed-off-by: Rajmohan Mani 
---
 Documentation/media/v4l-drivers/index.rst |   1 +
 Documentation/media/v4l-drivers/ipu3.rst  | 326 ++
 2 files changed, 327 insertions(+)
 create mode 100644 Documentation/media/v4l-drivers/ipu3.rst

diff --git a/Documentation/media/v4l-drivers/index.rst 
b/Documentation/media/v4l-drivers/index.rst
index 6cdd3bc98202..f28570ec9e42 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -44,6 +44,7 @@ For more details see the file COPYING in the source 
distribution of Linux.
davinci-vpbe
fimc
imx
+   ipu3
ivtv
max2175
meye
diff --git a/Documentation/media/v4l-drivers/ipu3.rst 
b/Documentation/media/v4l-drivers/ipu3.rst
new file mode 100644
index ..045bf4222b1a
--- /dev/null
+++ b/Documentation/media/v4l-drivers/ipu3.rst
@@ -0,0 +1,326 @@
+.. include:: 
+
+===
+Intel Image Processing Unit 3 (IPU3) Imaging Unit (ImgU) driver
+===
+
+Copyright |copy| 2018 Intel Corporation
+
+Introduction
+
+
+This file documents Intel IPU3 (3rd generation Image Processing Unit) Imaging
+Unit driver located under drivers/media/pci/intel/ipu3.
+
+The Intel IPU3 found in certain Kaby Lake (as well as certain Sky Lake)
+platforms (U/Y processor lines) is made up of two parts namely Imaging Unit
+(ImgU) and CIO2 device (MIPI CSI2 receiver).
+
+The CIO2 device receives the raw bayer data from the sensors and outputs the
+frames in a format that is specific to IPU3 (for consumption by IPU3 ImgU).
+CIO2 driver is available as drivers/media/pci/intel/ipu3/ipu3-cio2* and is
+enabled through the CONFIG_VIDEO_IPU3_CIO2 config option.
+
+The Imaging Unit (ImgU) is responsible for processing images captured
+through IPU3 CIO2 device. The ImgU driver sources can be found under
+drivers/media/pci/intel/ipu3 directory. The driver is enabled through the
+CONFIG_VIDEO_IPU3_IMGU config option.
+
+The two driver modules are named ipu3-csi2 and ipu3-imgu, respectively.
+
+The driver has been tested on Kaby Lake platforms (U/Y processor lines).
+
+The driver implements V4L2, Media controller and V4L2 sub-device interfaces.
+Camera sensors that have CSI-2 bus, which are connected to the IPU3 CIO2
+device are supported. Support for lens and flash drivers depends on the
+above sensors.
+
+ImgU device nodes
+=
+
+The ImgU is represented as two V4L2 subdevs, each of which provides a V4L2
+subdev interface to the user space.
+
+Each V4L2 subdev represents a pipe, which can support a maximum of 2
+streams. A private ioctl can be used to configure the mode (video or still)
+of the pipe.
+
+This helps to support advanced camera features like Continuous View Finder
+(CVF) and Snapshot During Video(SDV).
+
+CIO2 device
+===
+
+The CIO2 is represented as a single V4L2 subdev, which provides a V4L2 subdev
+interface to the user space. There is a video node for each CSI-2 receiver,
+with a single media controller interface for the entire device.
+
+Media controller
+
+
+The media device interface allows to configure the ImgU links, which defines
+the behavior of the IPU3 firmware.
+
+Device operation
+
+
+With IPU3, once the input video node ("ipu3-imgu 0/1":0,
+in : format) is queued with buffer (in packed raw bayer
+format), IPU3 ISP starts processing the buffer and produces the video output
+in YUV format and statistics output on respective output nodes. The driver
+is expected to have buffers ready for all of parameter, output and
+statistics nodes, when input video node is queued with buffer.
+
+At a minimum, all of input, main output, 3A statistics and viewfinder
+video nodes should be enabled for IPU3 to start image processing.
+
+Each ImgU V4L2 subdev has the following set of video nodes.
+
+input, output and viewfinder video nodes
+
+
+The frames (in packed raw bayer format specific to IPU3) received by the
+input video node is processed by the IPU3 Imaging Unit and is output to 2
+video nodes, with each targeting different purpose (main output and viewfinder
+output).
+
+Details on raw bayer format specific to IPU3 can be found as below.
+Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
+
+The driver supports V4L2 Video Capture Interface as defined at :ref:`devices`.
+
+Only the multi-planar API is supported. More details can be found at
+:ref:`planar-apis`.
+
+
+parameters video node
+-
+
+The parameter video node receives the ISP algorithm parameters that are used
+to configure how the ISP algorithms process the image.
+
+Details on raw bayer format specific to IPU3 can be found as below.

[PATCH v8 16/17] media: v4l2-ctrls: Reserve controls for IPU3 ImgU

2018-12-06 Thread Yong Zhi
From: "Cao,Bing Bu" 

Add a base to be used for allocation of all the IPU3 specific
controls in the ImgU driver.

Signed-off-by: Yong Zhi 
Signed-off-by: Tian Shu Qiu 
---
 include/uapi/linux/v4l2-controls.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/uapi/linux/v4l2-controls.h 
b/include/uapi/linux/v4l2-controls.h
index 998983a6e6b7..2b52f44d0ba5 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -192,6 +192,10 @@ enum v4l2_colorfx {
  * We reserve 16 controls for this driver. */
 #define V4L2_CID_USER_IMX_BASE (V4L2_CID_USER_BASE + 0x10b0)
 
+/* The base for the ipu3 ImgU driver controls.
+ * We reserve 16 controls for this driver. */
+#define V4L2_CID_INTEL_IPU3_BASE   (V4L2_CID_USER_BASE + 0x10c0)
+
 /* MPEG-class control IDs */
 /* The MPEG controls are applicable to all codec controls
  * and the 'MPEG' part of the define is historical */
-- 
2.7.4



Re: [PATCH v5] media: imx: add mem2mem device

2018-12-06 Thread Steve Longerbeam

Hi Hans,

On 12/6/18 4:32 AM, Hans Verkuil wrote:

On 12/06/18 00:13, Steve Longerbeam wrote:


On 12/5/18 10:50 AM, Hans Verkuil wrote:

On 12/05/2018 02:20 AM, Steve Longerbeam wrote:

Hi Hans, Philipp,

One comment on my side...

On 12/3/18 7:21 AM, Hans Verkuil wrote:



+void imx_media_mem2mem_device_unregister(struct imx_media_video_dev *vdev)
+{
+   struct mem2mem_priv *priv = to_mem2mem_priv(vdev);
+   struct video_device *vfd = priv->vdev.vfd;
+
+   mutex_lock(&priv->mutex);
+
+   if (video_is_registered(vfd)) {
+   video_unregister_device(vfd);
+   media_entity_cleanup(&vfd->entity);

Is this needed?

If this is to be part of the media controller, then I expect to see a call
to v4l2_m2m_register_media_controller() somewhere.


Yes, I agree there should be a call to
v4l2_m2m_register_media_controller(). This driver does not connect with
any of the imx-media entities, but calling it will at least make the
mem2mem output/capture device entities (and processing entity) visible
in the media graph.

Philipp, can you pick/squash the following from my media-tree github fork?

6fa05f5170 ("media: imx: mem2mem: Add missing media-device header")
d355bf8b15 ("media: imx: Add missing unregister and remove of mem2mem
device")
6787a50cdc ("media: imx: mem2mem: Register with media control")

Steve


Why is this driver part of the imx driver? Since it doesn't connect with
any of the imx-media entities, doesn't that mean that this is really a
stand-alone driver?

It is basically a stand-alone m2m driver, but it makes use of some
imx-media utility functions like imx_media_enum_format(). Also making it
a true stand-alone driver would require creating a second /dev/mediaN
device.

If it is standalone, is it reused in newer iMX versions? (7 or 8)


No, this driver makes use of the Image Converter in IPUv3, so it will 
only run on iMX 5/6. The IPU has been dropped in iMX 7 and 8.



And if it is just a regular m2m device, then it doesn't need to create a
media device either (doesn't hurt, but it is not required).


Ok, I'll leave that up to Philipp. I don't mind either way whether it is 
folded into imx-media device, or whether it is made stand-alone with or 
without a new media device.


Steve




Re: [PATCH v2] media: rockchip vpu: remove some unused vars

2018-12-06 Thread Ezequiel Garcia
On Wed, 2018-12-05 at 19:01 -0500, Mauro Carvalho Chehab wrote:
> As complained by gcc:
> 
>   drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c: In 
> function 'rk3288_vpu_jpeg_enc_set_qtable':
>   drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:70:10: 
> warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *chroma_qtable_p;
> ^~~
>   drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:69:10: 
> warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *luma_qtable_p;
> ^
>   drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c: In 
> function 'rk3399_vpu_jpeg_enc_set_qtable':
>   drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:101:10: 
> warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *chroma_qtable_p;
> ^~~
>   drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:100:10: 
> warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *luma_qtable_p;
> ^
>   drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function 
> 'rockchip_vpu_queue_setup':
>   drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:522:33: warning: 
> variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
> const struct rockchip_vpu_fmt *vpu_fmt;
>^~~
>   drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function 
> 'rockchip_vpu_buf_prepare':
>   drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:560:33: warning: 
> variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
> const struct rockchip_vpu_fmt *vpu_fmt;
>^~~
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Ezequiel Garcia 

Thanks!


> ---
>  drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 5 -
>  drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 5 -
>  drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c   | 6 --
>  3 files changed, 16 deletions(-)
> 
> diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c 
> b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> index e27c10855de5..5282236d1bb1 100644
> --- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> +++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> @@ -66,13 +66,8 @@ rk3288_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev 
> *vpu,
>  unsigned char *luma_qtable,
>  unsigned char *chroma_qtable)
>  {
> - __be32 *luma_qtable_p;
> - __be32 *chroma_qtable_p;
>   u32 reg, i;
>  
> - luma_qtable_p = (__be32 *)luma_qtable;
> - chroma_qtable_p = (__be32 *)chroma_qtable;
> -
>   for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
>   reg = get_unaligned_be32(&luma_qtable[i]);
>   vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
> diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c 
> b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> index 5f75e4d11d76..dbc86d95fe3b 100644
> --- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> +++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> @@ -97,13 +97,8 @@ rk3399_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev 
> *vpu,
>  unsigned char *luma_qtable,
>  unsigned char *chroma_qtable)
>  {
> - __be32 *luma_qtable_p;
> - __be32 *chroma_qtable_p;
>   u32 reg, i;
>  
> - luma_qtable_p = (__be32 *)luma_qtable;
> - chroma_qtable_p = (__be32 *)chroma_qtable;
> -
>   for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
>   reg = get_unaligned_be32(&luma_qtable[i]);
>   vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
> diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c 
> b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
> index 038a7136d5d1..ab0fb2053620 100644
> --- a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
> +++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
> @@ -519,17 +519,14 @@ rockchip_vpu_queue_setup(struct vb2_queue *vq,
>struct device *alloc_devs[])
>  {
>   struct rockchip_vpu_ctx *ctx = vb2_get_drv_priv(vq);
> - const struct rockchip_vpu_fmt *vpu_fmt;
>   struct v4l2_pix_format_mplane *pixfmt;
>   int i;
>  
>   switch (vq->type) {
>   case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
> - vpu_fmt = ctx->vpu_dst_fmt;
>   pixfmt = &ctx->dst_fmt;
>   break;
>   case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
> - vpu_fmt = ctx->vpu_src_fmt;
>   

[GIT PULL FOR v4.21] Two DVB patches

2018-12-06 Thread Sean Young
Hi Mauro,

Two small dvb fixes which would be nice to have in 4.21.

Thanks,
Sean

The following changes since commit 3c28b91380dd1183347d32d87d820818031ebecf:

  media: stkwebcam: Bugfix for wrong return values (2018-12-05 14:10:48 -0500)

are available in the Git repository at:

  git://linuxtv.org/syoung/media_tree.git for-v4.21d

for you to fetch changes up to 92ca069d61c96701c8660c114bbf8b772b4a33db:

  media: lmedm04: Move interrupt buffer to priv buffer. (2018-12-06 20:15:14 
+)


Malcolm Priestley (2):
  media: lmedm04: Add missing usb_free_urb to free interrupt urb.
  media: lmedm04: Move interrupt buffer to priv buffer.

 drivers/media/usb/dvb-usb-v2/lmedm04.c | 29 ++---
 1 file changed, 10 insertions(+), 19 deletions(-)


[PATCH v3] v4l2-ioctl: Zero v4l2_plane_pix_format reserved fields

2018-12-06 Thread Ezequiel Garcia
Make the core set the reserved fields to zero in
vv4l2_pix_format_mplane.4l2_plane_pix_format,
for _MPLANE queue types.

Moving this to the core avoids having to do so in each
and every driver.

Suggested-by: Tomasz Figa 
Signed-off-by: Ezequiel Garcia 
Acked-by: Sakari Ailus 
--
v3:
  * s/int/unsigned int, suggested by Sakari

v2:
  * Drop unneeded clear in g_fmt.
The sturct was already being cleared here.
  * Only zero plane_fmt reserved fields.
  * Use CLEAR_FIELD_MACRO.

 drivers/media/v4l2-core/v4l2-ioctl.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index e384142d2826..7e8e7915c041 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1512,6 +1512,7 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
struct v4l2_format *p = arg;
struct video_device *vfd = video_devdata(file);
int ret = check_fmt(file, p->type);
+   unsigned int i;
 
if (ret)
return ret;
@@ -1536,6 +1537,8 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!ops->vidioc_s_fmt_vid_cap_mplane))
break;
CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
+   for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+   CLEAR_AFTER_FIELD(p, 
fmt.pix_mp.plane_fmt[i].bytesperline);
return ops->vidioc_s_fmt_vid_cap_mplane(file, fh, arg);
case V4L2_BUF_TYPE_VIDEO_OVERLAY:
if (unlikely(!ops->vidioc_s_fmt_vid_overlay))
@@ -1564,6 +1567,8 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!ops->vidioc_s_fmt_vid_out_mplane))
break;
CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
+   for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+   CLEAR_AFTER_FIELD(p, 
fmt.pix_mp.plane_fmt[i].bytesperline);
return ops->vidioc_s_fmt_vid_out_mplane(file, fh, arg);
case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
if (unlikely(!ops->vidioc_s_fmt_vid_out_overlay))
@@ -1604,6 +1609,7 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
 {
struct v4l2_format *p = arg;
int ret = check_fmt(file, p->type);
+   unsigned int i;
 
if (ret)
return ret;
@@ -1623,6 +1629,8 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!ops->vidioc_try_fmt_vid_cap_mplane))
break;
CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
+   for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+   CLEAR_AFTER_FIELD(p, 
fmt.pix_mp.plane_fmt[i].bytesperline);
return ops->vidioc_try_fmt_vid_cap_mplane(file, fh, arg);
case V4L2_BUF_TYPE_VIDEO_OVERLAY:
if (unlikely(!ops->vidioc_try_fmt_vid_overlay))
@@ -1651,6 +1659,8 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!ops->vidioc_try_fmt_vid_out_mplane))
break;
CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
+   for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+   CLEAR_AFTER_FIELD(p, 
fmt.pix_mp.plane_fmt[i].bytesperline);
return ops->vidioc_try_fmt_vid_out_mplane(file, fh, arg);
case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
if (unlikely(!ops->vidioc_try_fmt_vid_out_overlay))
-- 
2.20.0.rc1



[PATCH v2] media: Use of_node_name_eq for node name comparisons

2018-12-06 Thread Rob Herring
Convert string compares of DT node names to use of_node_name_eq helper
instead. This removes direct access to the node name pointer.

Cc: Kyungmin Park 
Cc: Sylwester Nawrocki 
Cc: Mauro Carvalho Chehab 
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: Hyun Kwon 
Cc: Michal Simek 
Cc: linux-media@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Reviewed-by: Laurent Pinchart 
Reviewed-by: Benoit Parrot 
Signed-off-by: Rob Herring 
---
v2:
- Also convert tabs to spaces between the 'if' and '('

 drivers/media/platform/exynos4-is/media-dev.c | 12 ++--
 drivers/media/platform/ti-vpe/cal.c   |  4 ++--
 drivers/media/platform/xilinx/xilinx-tpg.c|  2 +-
 drivers/media/v4l2-core/v4l2-fwnode.c |  6 ++
 4 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/media-dev.c 
b/drivers/media/platform/exynos4-is/media-dev.c
index 870501b0f351..463f2d84553e 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -445,7 +445,7 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
 */
np = of_get_parent(rem);
 
-   if (np && !of_node_cmp(np->name, "i2c-isp"))
+   if (of_node_name_eq(np, "i2c-isp"))
pd->fimc_bus_type = FIMC_BUS_TYPE_ISP_WRITEBACK;
else
pd->fimc_bus_type = pd->sensor_bus_type;
@@ -495,7 +495,7 @@ static int fimc_md_register_sensor_entities(struct fimc_md 
*fmd)
for_each_available_child_of_node(parent, node) {
struct device_node *port;
 
-   if (of_node_cmp(node->name, "csis"))
+   if (!of_node_name_eq(node, "csis"))
continue;
/* The csis node can have only port subnode. */
port = of_get_next_child(node, NULL);
@@ -720,13 +720,13 @@ static int fimc_md_register_platform_entities(struct 
fimc_md *fmd,
continue;
 
/* If driver of any entity isn't ready try all again later. */
-   if (!strcmp(node->name, CSIS_OF_NODE_NAME))
+   if (of_node_name_eq(node, CSIS_OF_NODE_NAME))
plat_entity = IDX_CSIS;
-   else if (!strcmp(node->name, FIMC_IS_OF_NODE_NAME))
+   else if (of_node_name_eq(node, FIMC_IS_OF_NODE_NAME))
plat_entity = IDX_IS_ISP;
-   else if (!strcmp(node->name, FIMC_LITE_OF_NODE_NAME))
+   else if (of_node_name_eq(node, FIMC_LITE_OF_NODE_NAME))
plat_entity = IDX_FLITE;
-   else if (!strcmp(node->name, FIMC_OF_NODE_NAME) &&
+   else if (of_node_name_eq(node, FIMC_OF_NODE_NAME) &&
 !of_property_read_bool(node, "samsung,lcd-wb"))
plat_entity = IDX_FIMC;
 
diff --git a/drivers/media/platform/ti-vpe/cal.c 
b/drivers/media/platform/ti-vpe/cal.c
index 95a093f41905..fc3c212b96e1 100644
--- a/drivers/media/platform/ti-vpe/cal.c
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -1615,7 +1615,7 @@ of_get_next_port(const struct device_node *parent,
return NULL;
}
prev = port;
-   } while (of_node_cmp(port->name, "port") != 0);
+   } while (!of_node_name_eq(port, "port"));
}
 
return port;
@@ -1635,7 +1635,7 @@ of_get_next_endpoint(const struct device_node *parent,
if (!ep)
return NULL;
prev = ep;
-   } while (of_node_cmp(ep->name, "endpoint") != 0);
+   } while (!of_node_name_eq(ep, "endpoint"));
 
return ep;
 }
diff --git a/drivers/media/platform/xilinx/xilinx-tpg.c 
b/drivers/media/platform/xilinx/xilinx-tpg.c
index 851d20dcd550..ce686b8d6cff 100644
--- a/drivers/media/platform/xilinx/xilinx-tpg.c
+++ b/drivers/media/platform/xilinx/xilinx-tpg.c
@@ -725,7 +725,7 @@ static int xtpg_parse_of(struct xtpg_device *xtpg)
const struct xvip_video_format *format;
struct device_node *endpoint;
 
-   if (!port->name || of_node_cmp(port->name, "port"))
+   if (!of_node_name_eq(port, "port"))
continue;
 
format = xvip_of_get_format(port);
diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
b/drivers/media/v4l2-core/v4l2-fwnode.c
index 218f0da0ce76..849326241b17 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -564,8 +564,7 @@ int v4l2_fwnode_parse_link(struct fwnode_handle *__fwnode,
fwnode = fwnode_get_parent(__fwnode);
fwnode_property_read_u32(fwnode, port_prop, &link->local_port);
fwnode = fwnode_get_next_parent(fwnode);
-   if (is_of_node(fwnode) &&
-   of_node_cmp(to_of_node(fwnode)->name, "ports") == 0)
+   if (is_of_node(fwnode) && of_node_name_eq(to_of_node(fwnode), "

Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes

2018-12-06 Thread Mauro Carvalho Chehab
Em Thu, 6 Dec 2018 17:07:52 -0200
Mauro Carvalho Chehab  escreveu:

> Em Thu, 6 Dec 2018 13:36:24 -0500
> Alex Deucher  escreveu:
> 
> > On Thu, Dec 6, 2018 at 1:05 PM Mauro Carvalho Chehab  
> > wrote:  
> > >
> > > Em Thu, 06 Dec 2018 18:18:23 +0100
> > > Markus Dobel  escreveu:
> > >
> > > > Hi everyone,
> > > >
> > > > I will try if the hack mentioned fixes the issue for me on the weekend 
> > > > (but I assume, as if effectively removes the function).
> > >
> > > It should, but it keeps a few changes. Just want to be sure that what
> > > would be left won't cause issues. If this works, the logic that would
> > > solve Ryzen DMA fixes will be contained into a single point, making
> > > easier to maintain it.
> > >
> > > >
> > > > Just in case this is of interest, I neither have Ryzen nor Intel, but 
> > > > an HP Microserver G7 with an AMD Turion II Neo  N54L, so the machine is 
> > > > more on the slow side.
> > >
> > > Good to know. It would probably worth to check if this Ryzen
> > > bug occors with all versions of it or with just a subset.
> > > I mean: maybe it is only at the first gen or Ryzen and doesn't
> > > affect Ryzen 2 (or vice versa).
> > 
> > The original commit also mentions some Xeons are affected too.  Seems
> > like this is potentially an issue on the device side rather than the
> > platform.  
> 
> Maybe.
> 
> > >
> > > The PCI quirks logic will likely need to detect the PCI ID of
> > > the memory controllers found at the buggy CPUs, in order to enable
> > > the quirk only for the affected ones.
> > >
> > > It could be worth talking with AMD people in order to be sure about
> > > the differences at the DMA engine side.
> > >
> > 
> > It's not clear to me what the pci or platform quirk would do.  The
> > workaround seems to be in the driver, not on the platform.  
> 
> Yeah, the fix should be at the driver, but pci/quirk.c would be able
> to detect memory controllers that would require a hack inside the
> driver, in a similar way to what the media PCI drivers already do
> for DMA controllers that don't support pci2pci transfers.
> 
> There, basically the PCI core (drivers/pci/pci.c and 
> drivers/pci/quirks.c) sets a flag (pci_pci_problems) indicating
> potential issues.
> 
> Then, the driver compares such flag in order to enable the specific quirk.
> 
> Ok, there would be a different way to handle it. The driver could use a 
> logic similar to the one I wrote for drivers/edac/i7core_edac.c. There,
> the logic seeks for some specific PCI device IDs using pci_get_device(),
> adjusting the code accordingly, depending on the detected PCI devices.
> 
> In other words, running something like this (untested), at probe time should
> produce similar results:
> 
>   /*
>* FIXME: It probably makes sense to also be able to identify specific
>* versions of the same PCI ID, just in case a latter stepping got a
>* fix for the issue.
>*/
>   const static struct {
>   int vendor, dev;
>   } broken_dev_id[] = {
>   PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_foo,
>   PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_bar,
>   },
> 
>   bool cx23885_does_dma_require_reset(void) 
>   {
>   int i;
>   struct pci_dev *pdev = NULL;
> 
>   for (i = 0; i < sizeof(broken_dev_id); i++) {
>   pdev = pci_get_device(broken_dev_id[i].vendor, 
> broken_dev_id[i].dev, NULL);
>   if (pdev) {
>   pci_put_device(pdev);
>   return true;
>   }
>   }
>   return false;
>   }
> 
> Should work. In any case, we need to know what memory controllers 
> have problems, and what are their PCI IDs, and add them (if not there yet)
> at include/linux/pci_ids.h
> 
> Thanks,
> Mauro

To be clearer, I'm thinking on something like the (untested)
code below (untested).

PS.: the PCI ID used there may be wrong. I just added one in
order to have a proof of concept.

Thanks,
Mauro

[PATCH] media: cx23885: only reset DMA on problematic CPUs

It is reported that changeset 95f408bbc4e4 ("media: cx23885:
Ryzen DMA related RiSC engine stall fixes") caused regresssions
with other CPUs.

Ensure that the quirk will be applied only for the CPUs that
are known to cause problems.

Fixes: 95f408bbc4e4 ("media: cx23885: Ryzen DMA related RiSC engine stall 
fixes")
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/pci/cx23885/cx23885-core.c 
b/drivers/media/pci/cx23885/cx23885-core.c
index 39804d830305..48da7d194cc1 100644
--- a/drivers/media/pci/cx23885/cx23885-core.c
+++ b/drivers/media/pci/cx23885/cx23885-core.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -603,8 +604,13 @@ static void cx23885_risc_disasm(struct cx23885_tsport 
*port,
 
 static void cx23885_clear_bridge_error(struct cx23885_dev *dev)
 {
-   uint32_t r

Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes

2018-12-06 Thread Mauro Carvalho Chehab
Em Thu, 6 Dec 2018 13:36:24 -0500
Alex Deucher  escreveu:

> On Thu, Dec 6, 2018 at 1:05 PM Mauro Carvalho Chehab  
> wrote:
> >
> > Em Thu, 06 Dec 2018 18:18:23 +0100
> > Markus Dobel  escreveu:
> >  
> > > Hi everyone,
> > >
> > > I will try if the hack mentioned fixes the issue for me on the weekend 
> > > (but I assume, as if effectively removes the function).  
> >
> > It should, but it keeps a few changes. Just want to be sure that what
> > would be left won't cause issues. If this works, the logic that would
> > solve Ryzen DMA fixes will be contained into a single point, making
> > easier to maintain it.
> >  
> > >
> > > Just in case this is of interest, I neither have Ryzen nor Intel, but an 
> > > HP Microserver G7 with an AMD Turion II Neo  N54L, so the machine is more 
> > > on the slow side.  
> >
> > Good to know. It would probably worth to check if this Ryzen
> > bug occors with all versions of it or with just a subset.
> > I mean: maybe it is only at the first gen or Ryzen and doesn't
> > affect Ryzen 2 (or vice versa).  
> 
> The original commit also mentions some Xeons are affected too.  Seems
> like this is potentially an issue on the device side rather than the
> platform.

Maybe.

> >
> > The PCI quirks logic will likely need to detect the PCI ID of
> > the memory controllers found at the buggy CPUs, in order to enable
> > the quirk only for the affected ones.
> >
> > It could be worth talking with AMD people in order to be sure about
> > the differences at the DMA engine side.
> >  
> 
> It's not clear to me what the pci or platform quirk would do.  The
> workaround seems to be in the driver, not on the platform.

Yeah, the fix should be at the driver, but pci/quirk.c would be able
to detect memory controllers that would require a hack inside the
driver, in a similar way to what the media PCI drivers already do
for DMA controllers that don't support pci2pci transfers.

There, basically the PCI core (drivers/pci/pci.c and 
drivers/pci/quirks.c) sets a flag (pci_pci_problems) indicating
potential issues.

Then, the driver compares such flag in order to enable the specific quirk.

Ok, there would be a different way to handle it. The driver could use a 
logic similar to the one I wrote for drivers/edac/i7core_edac.c. There,
the logic seeks for some specific PCI device IDs using pci_get_device(),
adjusting the code accordingly, depending on the detected PCI devices.

In other words, running something like this (untested), at probe time should
produce similar results:

/*
 * FIXME: It probably makes sense to also be able to identify specific
 * versions of the same PCI ID, just in case a latter stepping got a
 * fix for the issue.
 */
const static struct {
int vendor, dev;
} broken_dev_id[] = {
PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_foo,
PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_bar,
},

bool cx23885_does_dma_require_reset(void) 
{
int i;
struct pci_dev *pdev = NULL;

for (i = 0; i < sizeof(broken_dev_id); i++) {
pdev = pci_get_device(broken_dev_id[i].vendor, 
broken_dev_id[i].dev, NULL);
if (pdev) {
pci_put_device(pdev);
return true;
}
}
return false;
}

Should work. In any case, we need to know what memory controllers 
have problems, and what are their PCI IDs, and add them (if not there yet)
at include/linux/pci_ids.h

Thanks,
Mauro


[PATCH v3 7/9] videobuf2/videobuf2-dma-sg.c: Convert to use vm_insert_range

2018-12-06 Thread Souptick Joarder
Convert to use vm_insert_range to map range of kernel memory
to user vma.

Signed-off-by: Souptick Joarder 
Reviewed-by: Matthew Wilcox 
Acked-by: Marek Szyprowski 
---
 drivers/media/common/videobuf2/videobuf2-dma-sg.c | 23 +++
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c 
b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index 015e737..898adef 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -328,28 +328,19 @@ static unsigned int vb2_dma_sg_num_users(void *buf_priv)
 static int vb2_dma_sg_mmap(void *buf_priv, struct vm_area_struct *vma)
 {
struct vb2_dma_sg_buf *buf = buf_priv;
-   unsigned long uaddr = vma->vm_start;
-   unsigned long usize = vma->vm_end - vma->vm_start;
-   int i = 0;
+   unsigned long page_count = vma_pages(vma);
+   int err;
 
if (!buf) {
printk(KERN_ERR "No memory to map\n");
return -EINVAL;
}
 
-   do {
-   int ret;
-
-   ret = vm_insert_page(vma, uaddr, buf->pages[i++]);
-   if (ret) {
-   printk(KERN_ERR "Remapping memory, error: %d\n", ret);
-   return ret;
-   }
-
-   uaddr += PAGE_SIZE;
-   usize -= PAGE_SIZE;
-   } while (usize > 0);
-
+   err = vm_insert_range(vma, vma->vm_start, buf->pages, page_count);
+   if (err) {
+   printk(KERN_ERR "Remapping memory, error: %d\n", err);
+   return err;
+   }
 
/*
 * Use common vm_area operations to track buffer refcount.
-- 
1.9.1



Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes

2018-12-06 Thread Alex Deucher
On Thu, Dec 6, 2018 at 1:05 PM Mauro Carvalho Chehab  wrote:
>
> Em Thu, 06 Dec 2018 18:18:23 +0100
> Markus Dobel  escreveu:
>
> > Hi everyone,
> >
> > I will try if the hack mentioned fixes the issue for me on the weekend (but 
> > I assume, as if effectively removes the function).
>
> It should, but it keeps a few changes. Just want to be sure that what
> would be left won't cause issues. If this works, the logic that would
> solve Ryzen DMA fixes will be contained into a single point, making
> easier to maintain it.
>
> >
> > Just in case this is of interest, I neither have Ryzen nor Intel, but an HP 
> > Microserver G7 with an AMD Turion II Neo  N54L, so the machine is more on 
> > the slow side.
>
> Good to know. It would probably worth to check if this Ryzen
> bug occors with all versions of it or with just a subset.
> I mean: maybe it is only at the first gen or Ryzen and doesn't
> affect Ryzen 2 (or vice versa).

The original commit also mentions some Xeons are affected too.  Seems
like this is potentially an issue on the device side rather than the
platform.

>
> The PCI quirks logic will likely need to detect the PCI ID of
> the memory controllers found at the buggy CPUs, in order to enable
> the quirk only for the affected ones.
>
> It could be worth talking with AMD people in order to be sure about
> the differences at the DMA engine side.
>

It's not clear to me what the pci or platform quirk would do.  The
workaround seems to be in the driver, not on the platform.

Alex


[PATCH v3 1/9] mm: Introduce new vm_insert_range API

2018-12-06 Thread Souptick Joarder
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.

As this pattern is common across different drivers, it can
be generalized by creating a new function and use it across
the drivers.

vm_insert_range is the new API which will be used to map a
range of kernel memory/pages to user vma.

This API is tested by Heiko for Rockchip drm driver, on rk3188,
rk3288, rk3328 and rk3399 with graphics.

Signed-off-by: Souptick Joarder 
Reviewed-by: Matthew Wilcox 
Reviewed-by: Mike Rapoport 
Tested-by: Heiko Stuebner 
---
 include/linux/mm.h |  2 ++
 mm/memory.c| 38 ++
 mm/nommu.c |  7 +++
 3 files changed, 47 insertions(+)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index fcf9cc9..2bc399f 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2506,6 +2506,8 @@ unsigned long change_prot_numa(struct vm_area_struct *vma,
 int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
unsigned long pfn, unsigned long size, pgprot_t);
 int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct page *);
+int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
+   struct page **pages, unsigned long page_count);
 vm_fault_t vmf_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
unsigned long pfn);
 vm_fault_t vmf_insert_pfn_prot(struct vm_area_struct *vma, unsigned long addr,
diff --git a/mm/memory.c b/mm/memory.c
index 15c417e..84ea46c 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1478,6 +1478,44 @@ static int insert_page(struct vm_area_struct *vma, 
unsigned long addr,
 }
 
 /**
+ * vm_insert_range - insert range of kernel pages into user vma
+ * @vma: user vma to map to
+ * @addr: target user address of this page
+ * @pages: pointer to array of source kernel pages
+ * @page_count: number of pages need to insert into user vma
+ *
+ * This allows drivers to insert range of kernel pages they've allocated
+ * into a user vma. This is a generic function which drivers can use
+ * rather than using their own way of mapping range of kernel pages into
+ * user vma.
+ *
+ * If we fail to insert any page into the vma, the function will return
+ * immediately leaving any previously-inserted pages present.  Callers
+ * from the mmap handler may immediately return the error as their caller
+ * will destroy the vma, removing any successfully-inserted pages. Other
+ * callers should make their own arrangements for calling unmap_region().
+ *
+ * Context: Process context. Called by mmap handlers.
+ * Return: 0 on success and error code otherwise
+ */
+int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
+   struct page **pages, unsigned long page_count)
+{
+   unsigned long uaddr = addr;
+   int ret = 0, i;
+
+   for (i = 0; i < page_count; i++) {
+   ret = vm_insert_page(vma, uaddr, pages[i]);
+   if (ret < 0)
+   return ret;
+   uaddr += PAGE_SIZE;
+   }
+
+   return ret;
+}
+EXPORT_SYMBOL(vm_insert_range);
+
+/**
  * vm_insert_page - insert single page into user vma
  * @vma: user vma to map to
  * @addr: target user address of this page
diff --git a/mm/nommu.c b/mm/nommu.c
index 749276b..d6ef5c7 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -473,6 +473,13 @@ int vm_insert_page(struct vm_area_struct *vma, unsigned 
long addr,
 }
 EXPORT_SYMBOL(vm_insert_page);
 
+int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
+   struct page **pages, unsigned long page_count)
+{
+   return -EINVAL;
+}
+EXPORT_SYMBOL(vm_insert_range);
+
 /*
  *  sys_brk() for the most part doesn't need the global kernel
  *  lock, except when an application is doing something nasty
-- 
1.9.1



[PATCH v3 0/9] Use vm_insert_range

2018-12-06 Thread Souptick Joarder
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.

As this pattern is common across different drivers, it can
be generalized by creating a new function and use it across
the drivers.

vm_insert_range is the new API which will be used to map a
range of kernel memory/pages to user vma.

All the applicable places are converted to use new vm_insert_range
in this patch series.

v1 -> v2:
Address review comment on mm/memory.c. Add EXPORT_SYMBOL
for vm_insert_range and corrected the documentation part
for this API.

In drivers/gpu/drm/xen/xen_drm_front_gem.c, replace err
with ret as suggested.

In drivers/iommu/dma-iommu.c, handle the scenario of partial
mmap() of large buffer by passing *pages + vma->vm_pgoff* to
vm_insert_range().

v2 -> v3:
Declaration of vm_insert_range() moved to include/linux/mm.h

Souptick Joarder (9):
  mm: Introduce new vm_insert_range API
  arch/arm/mm/dma-mapping.c: Convert to use vm_insert_range
  drivers/firewire/core-iso.c: Convert to use vm_insert_range
  drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range
  drm/xen/xen_drm_front_gem.c: Convert to use vm_insert_range
  iommu/dma-iommu.c: Convert to use vm_insert_range
  videobuf2/videobuf2-dma-sg.c: Convert to use vm_insert_range
  xen/gntdev.c: Convert to use vm_insert_range
  xen/privcmd-buf.c: Convert to use vm_insert_range

 arch/arm/mm/dma-mapping.c | 21 +
 drivers/firewire/core-iso.c   | 15 ++---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   | 20 ++--
 drivers/gpu/drm/xen/xen_drm_front_gem.c   | 20 
 drivers/iommu/dma-iommu.c | 13 ++--
 drivers/media/common/videobuf2/videobuf2-dma-sg.c | 23 +-
 drivers/xen/gntdev.c  | 11 +++
 drivers/xen/privcmd-buf.c |  8 ++---
 include/linux/mm.h|  2 ++
 mm/memory.c   | 38 +++
 mm/nommu.c|  7 +
 11 files changed, 80 insertions(+), 98 deletions(-)

-- 
1.9.1



Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping v2

2018-12-06 Thread Koenig, Christian
Am 06.12.18 um 17:58 schrieb Chris Wilson:
> Quoting jgli...@redhat.com (2018-12-06 15:47:04)
>> From: Jérôme Glisse 
>>
>> The debugfs take reference on fence without dropping them. Also the
>> rcu section are not well balance. Fix all that ...
> Wouldn't the code be a lot simpler (and a consistent snapshot) if it used
> reservation_object_get_fences_rcu()?

Yeah, thought about that as well.

Or even better move that code into reservation_object.c as 
reservation_object_show_fences() or something like that.

Christian.

> -Chris



Re: [PATCH] dma-buf: balance refcount inbalance

2018-12-06 Thread Koenig, Christian
Am 06.12.18 um 17:18 schrieb jgli...@redhat.com:
> From: Jérôme Glisse 
>
> The debugfs take reference on fence without dropping them.
>
> Signed-off-by: Jérôme Glisse 
> Cc: Christian König 
> Cc: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: linux-media@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: Stéphane Marchesin 
> Cc: sta...@vger.kernel.org

Reviewed-by: Christian König 

> ---
>   drivers/dma-buf/dma-buf.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 13884474d158..69842145c223 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -1069,6 +1069,7 @@ static int dma_buf_debug_show(struct seq_file *s, void 
> *unused)
>  fence->ops->get_driver_name(fence),
>  fence->ops->get_timeline_name(fence),
>  dma_fence_is_signaled(fence) ? "" : "un");
> + dma_fence_put(fence);
>   }
>   rcu_read_unlock();
>   



Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes

2018-12-06 Thread Mauro Carvalho Chehab
Em Thu, 06 Dec 2018 18:18:23 +0100
Markus Dobel  escreveu:

> Hi everyone,
> 
> I will try if the hack mentioned fixes the issue for me on the weekend (but I 
> assume, as if effectively removes the function).

It should, but it keeps a few changes. Just want to be sure that what
would be left won't cause issues. If this works, the logic that would
solve Ryzen DMA fixes will be contained into a single point, making
easier to maintain it.

> 
> Just in case this is of interest, I neither have Ryzen nor Intel, but an HP 
> Microserver G7 with an AMD Turion II Neo  N54L, so the machine is more on the 
> slow side. 

Good to know. It would probably worth to check if this Ryzen
bug occors with all versions of it or with just a subset.
I mean: maybe it is only at the first gen or Ryzen and doesn't
affect Ryzen 2 (or vice versa).

The PCI quirks logic will likely need to detect the PCI ID of
the memory controllers found at the buggy CPUs, in order to enable
the quirk only for the affected ones.

It could be worth talking with AMD people in order to be sure about
the differences at the DMA engine side.

Thanks,
Mauro


Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes

2018-12-06 Thread Markus Dobel
Hi everyone,

I will try if the hack mentioned fixes the issue for me on the weekend (but I 
assume, as if effectively removes the function).

Just in case this is of interest, I neither have Ryzen nor Intel, but an HP 
Microserver G7 with an AMD Turion II Neo  N54L, so the machine is more on the 
slow side. 

Regards, Markus
-- 
Gesendet mit zwei Streichhölzern, einem Gummiband und etwas Draht.


Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping v2

2018-12-06 Thread Chris Wilson
Quoting jgli...@redhat.com (2018-12-06 15:47:04)
> From: Jérôme Glisse 
> 
> The debugfs take reference on fence without dropping them. Also the
> rcu section are not well balance. Fix all that ...

Wouldn't the code be a lot simpler (and a consistent snapshot) if it used
reservation_object_get_fences_rcu()?
-Chris


Re: [PATCH] Revert 95f408bb Ryzen DMA related RiSC engine stall fixes

2018-12-06 Thread Brad Love
Hi Mauro & Markus,


On 05/12/2018 05.07, Mauro Carvalho Chehab wrote:
> Em Sun, 21 Oct 2018 15:45:39 +0200
> Markus Dobel  escreveu:
>
>> The original commit (the one reverted in this patch) introduced a 
>> regression,
>> making a previously flawless adapter unresponsive after running a few 
>> hours
>> to days. Since I never experienced the problems that the original commit 
>> is
>> supposed to fix, I propose to revert the change until a regression-free
>> variant is found.
>>
>> Before submitting this, I've been running a system 24x7 with this revert 
>> for
>> several weeks now, and it's running stable again.
>>
>> It's not a pure revert, as the original commit does not revert cleanly
>> anymore due to other changes, but content-wise it is.
>>
>> Signed-off-by: Markus Dobel 
>> ---
>>   drivers/media/pci/cx23885/cx23885-core.c | 60 
>>   drivers/media/pci/cx23885/cx23885-reg.h  | 14 --
>>   2 files changed, 74 deletions(-)
>>
>> diff --git a/drivers/media/pci/cx23885/cx23885-core.c 
>> b/drivers/media/pci/cx23885/cx23885-core.c
>> index 39804d830305..606f6fc0e68b 100644
>> --- a/drivers/media/pci/cx23885/cx23885-core.c
>> +++ b/drivers/media/pci/cx23885/cx23885-core.c
>> @@ -601,25 +601,6 @@ static void cx23885_risc_disasm(struct 
>> cx23885_tsport *port,
> Patch was mangled by your e-mailer: it broke longer lines, causing
> it to not apply.
>
> Also, before just reverting the entire thing, could you please check
> if the enclosed hack would solve it?
>
> If so, it should be easy to add a quirk at drivers/pci/quirks.c
> in order to detect the Ryzen models with a bad DMA engine that
> require periodic resets, and then make cx23885 to use it.
>
> We did similar tricks before with some broken DMA engines, at
> the time we had overlay support on drivers and AMD controllers
> didn't support PCI2PCI DMA transfers.
>
> Brad,
>
> Could you please address this issue?


I'll try to address this today or tomorrow. Since the original patch was
applied I have not received any complaints from ryzen users, but we have
accumulated a few reports from Intel users with a variety of
motherboards that do now encounter issue. Strangely system load affects
the repro; low/no load exhibits the error condition, high system load
everything is fine. I'll do my best to send in a ryzen specific patch by
the weekend.

Regards,

Brad



>
>
> diff --git a/drivers/media/pci/cx23885/cx23885-core.c 
> b/drivers/media/pci/cx23885/cx23885-core.c
> index 39804d830305..8b012bee6b32 100644
> --- a/drivers/media/pci/cx23885/cx23885-core.c
> +++ b/drivers/media/pci/cx23885/cx23885-core.c
> @@ -603,8 +603,14 @@ static void cx23885_risc_disasm(struct cx23885_tsport 
> *port,
>  
>  static void cx23885_clear_bridge_error(struct cx23885_dev *dev)
>  {
> - uint32_t reg1_val = cx_read(TC_REQ); /* read-only */
> - uint32_t reg2_val = cx_read(TC_REQ_SET);
> + uint32_t reg1_val, reg2_val;
> +
> + /* TODO: check for Ryzen quirk */
> + if (1)
> + return;
> +
> + reg1_val = cx_read(TC_REQ); /* read-only */
> + reg2_val = cx_read(TC_REQ_SET);
>  
>   if (reg1_val && reg2_val) {
>   cx_write(TC_REQ, reg1_val);
>
>
>
> Thanks,
> Mauro



Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping

2018-12-06 Thread Jerome Glisse
On Thu, Dec 06, 2018 at 04:08:12PM +, Koenig, Christian wrote:
> Am 06.12.18 um 16:21 schrieb Jerome Glisse:
> > On Thu, Dec 06, 2018 at 08:09:28AM +, Koenig, Christian wrote:
> >> Am 06.12.18 um 02:41 schrieb jgli...@redhat.com:
> >>> From: Jérôme Glisse 
> >>>
> >>> The debugfs take reference on fence without dropping them. Also the
> >>> rcu section are not well balance. Fix all that ...
> >>>
> >>> Signed-off-by: Jérôme Glisse 
> >>> Cc: Christian König 
> >>> Cc: Daniel Vetter 
> >>> Cc: Sumit Semwal 
> >>> Cc: linux-media@vger.kernel.org
> >>> Cc: dri-de...@lists.freedesktop.org
> >>> Cc: linaro-mm-...@lists.linaro.org
> >>> Cc: Stéphane Marchesin 
> >>> Cc: sta...@vger.kernel.org
> >> Well NAK, you are now taking the RCU lock twice and dropping the RCU and
> >> still accessing fobj has a huge potential for accessing freed up memory.
> >>
> >> The only correct thing I can see here is to grab a reference to the
> >> fence before printing any info on it,
> >> Christian.
> > Hu ? That is exactly what i am doing, take reference under rcu,
> > rcu_unlock print the fence info, drop the fence reference, rcu
> > lock rinse and repeat ...
> >
> > Note that the fobj in _existing_ code is access outside the rcu
> > end that there is an rcu imbalance in that code ie a lonlely
> > rcu_unlock after the for loop.
> >
> > So that the existing code is broken.
> 
> No, the existing code is perfectly fine.
> 
> Please note the break in the loop before the rcu_unlock();
> > if (!read_seqcount_retry(&robj->seq, seq))
> > break; <- HERE!
> > rcu_read_unlock();
> > }
> 
> So your patch breaks that and take the RCU read lock twice.

Ok missed that, i wonder if the refcount in balance explains
the crash that was reported to me ... i sent a patch just for
that.

Thank you for reviewing and pointing out the code i was
oblivious too :)

Cheers,
Jérôme


Re: [PATCH v6 00/12] media: ov5640: Misc cleanup and improvements

2018-12-06 Thread Jagan Teki
On Mon, Dec 3, 2018 at 2:14 PM Maxime Ripard  wrote:
>
> Hi,
>
> Here is a "small" series that mostly cleans up the ov5640 driver code,
> slowly getting rid of the big data array for more understandable code
> (hopefully).
>
> The biggest addition would be the clock rate computation at runtime,
> instead of relying on those arrays to setup the clock tree
> properly. As a side effect, it fixes the framerate that was off by
> around 10% on the smaller resolutions, and we now support 60fps.
>
> This also introduces a bunch of new features.
>
> Let me know what you think,
> Maxime
>
> Changes from v5:
>   - Squashed Jacopo patches fixing MIPI-CSI
>
> Changes from v4:
>   - Squashed Jacopo patches fixing the MIPI-CSI case
>   - Prefer clock rates superior to the ideal clock rate, even if it
> means having a less precise one.
>   - Fix the JPEG case according to Hugues suggestions
>   - Rebased on 4.20
>
> Changes from v3:
>   - Rebased on current Sakari tree
>   - Fixed an error when changing only the framerate
>
> Changes from v2:
>   - Rebased on latest Sakari PR
>   - Fixed the issues reported by Hugues: improper FPS returned for
> formats, improper rounding of the FPS, some with his suggestions,
> some by simplifying the logic.
>   - Expanded the clock tree comments based on the feedback from Samuel
> Bobrowicz and Loic Poulain
>   - Merged some of the changes made by Samuel Bobrowicz to fix the
> MIPI rate computation, fix the call sites of the
> ov5640_set_timings function, the auto-exposure calculation call,
> etc.
>   - Split the patches into smaller ones in order to make it more
> readable (hopefully)
>
> Changes from v1:
>   - Integrated Hugues' suggestions to fix v4l2-compliance
>   - Fixed the bus width with JPEG
>   - Dropped the clock rate calculation loops for something simpler as
> suggested by Sakari
>   - Cache the exposure value instead of using the control value
>   - Rebased on top of 4.17
>
> Jacopo Mondi (1):
>   media: ov5640: Fix set format regression
>
> Maxime Ripard (11):
>   media: ov5640: Adjust the clock based on the expected rate
>   media: ov5640: Remove the clocks registers initialization
>   media: ov5640: Remove redundant defines
>   media: ov5640: Remove redundant register setup
>   media: ov5640: Compute the clock rate at runtime
>   media: ov5640: Remove pixel clock rates
>   media: ov5640: Enhance FPS handling
>   media: ov5640: Make the return rate type more explicit
>   media: ov5640: Make the FPS clamping / rounding more extendable
>   media: ov5640: Add 60 fps support
>   media: ov5640: Remove duplicate auto-exposure setup

Tested 320x240@30, 640x480@30, 640x480@60, 1280x720@30 with UYVY8_2X8
and YUYV8_2X8 formats.

Tested-by: Jagan Teki  # a64-amarula-relic


[PATCH] dma-buf: balance refcount inbalance

2018-12-06 Thread jglisse
From: Jérôme Glisse 

The debugfs take reference on fence without dropping them.

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: linux-media@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Stéphane Marchesin 
Cc: sta...@vger.kernel.org
---
 drivers/dma-buf/dma-buf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 13884474d158..69842145c223 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1069,6 +1069,7 @@ static int dma_buf_debug_show(struct seq_file *s, void 
*unused)
   fence->ops->get_driver_name(fence),
   fence->ops->get_timeline_name(fence),
   dma_fence_is_signaled(fence) ? "" : "un");
+   dma_fence_put(fence);
}
rcu_read_unlock();
 
-- 
2.17.2



Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping

2018-12-06 Thread Koenig, Christian
Am 06.12.18 um 16:21 schrieb Jerome Glisse:
> On Thu, Dec 06, 2018 at 08:09:28AM +, Koenig, Christian wrote:
>> Am 06.12.18 um 02:41 schrieb jgli...@redhat.com:
>>> From: Jérôme Glisse 
>>>
>>> The debugfs take reference on fence without dropping them. Also the
>>> rcu section are not well balance. Fix all that ...
>>>
>>> Signed-off-by: Jérôme Glisse 
>>> Cc: Christian König 
>>> Cc: Daniel Vetter 
>>> Cc: Sumit Semwal 
>>> Cc: linux-media@vger.kernel.org
>>> Cc: dri-de...@lists.freedesktop.org
>>> Cc: linaro-mm-...@lists.linaro.org
>>> Cc: Stéphane Marchesin 
>>> Cc: sta...@vger.kernel.org
>> Well NAK, you are now taking the RCU lock twice and dropping the RCU and
>> still accessing fobj has a huge potential for accessing freed up memory.
>>
>> The only correct thing I can see here is to grab a reference to the
>> fence before printing any info on it,
>> Christian.
> Hu ? That is exactly what i am doing, take reference under rcu,
> rcu_unlock print the fence info, drop the fence reference, rcu
> lock rinse and repeat ...
>
> Note that the fobj in _existing_ code is access outside the rcu
> end that there is an rcu imbalance in that code ie a lonlely
> rcu_unlock after the for loop.
>
> So that the existing code is broken.

No, the existing code is perfectly fine.

Please note the break in the loop before the rcu_unlock();
>   if (!read_seqcount_retry(&robj->seq, seq))
>   break; <- HERE!
>   rcu_read_unlock();
>   }

So your patch breaks that and take the RCU read lock twice.

Regards,
Christian.

>
>>> ---
>>>drivers/dma-buf/dma-buf.c | 11 +--
>>>1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>>> index 13884474d158..f6f4de42ac49 100644
>>> --- a/drivers/dma-buf/dma-buf.c
>>> +++ b/drivers/dma-buf/dma-buf.c
>>> @@ -1051,24 +1051,31 @@ static int dma_buf_debug_show(struct seq_file *s, 
>>> void *unused)
>>> fobj = rcu_dereference(robj->fence);
>>> shared_count = fobj ? fobj->shared_count : 0;
>>> fence = rcu_dereference(robj->fence_excl);
>>> +   fence = dma_fence_get_rcu(fence);
>>> if (!read_seqcount_retry(&robj->seq, seq))
>>> break;
>>> rcu_read_unlock();
>>> }
>>> -
>>> -   if (fence)
>>> +   if (fence) {
>>> seq_printf(s, "\tExclusive fence: %s %s %ssignalled\n",
>>>fence->ops->get_driver_name(fence),
>>>fence->ops->get_timeline_name(fence),
>>>dma_fence_is_signaled(fence) ? "" : "un");
>>> +   dma_fence_put(fence);
>>> +   }
>>> +
>>> +   rcu_read_lock();
>>> for (i = 0; i < shared_count; i++) {
>>> fence = rcu_dereference(fobj->shared[i]);
>>> if (!dma_fence_get_rcu(fence))
>>> continue;
>>> +   rcu_read_unlock();
>>> seq_printf(s, "\tShared fence: %s %s %ssignalled\n",
>>>fence->ops->get_driver_name(fence),
>>>fence->ops->get_timeline_name(fence),
>>>dma_fence_is_signaled(fence) ? "" : "un");
>>> +   dma_fence_put(fence);
>>> +   rcu_read_lock();
>>> }
>>> rcu_read_unlock();
>>>



[PATCH] dma-buf: fix debugfs versus rcu and fence dumping v2

2018-12-06 Thread jglisse
From: Jérôme Glisse 

The debugfs take reference on fence without dropping them. Also the
rcu section are not well balance. Fix all that ...

Changed since v1:
- moved fobj logic around to be rcu safe

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: linux-media@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Stéphane Marchesin 
Cc: sta...@vger.kernel.org
---
 drivers/dma-buf/dma-buf.c | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 13884474d158..9688d99894d6 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1048,27 +1048,38 @@ static int dma_buf_debug_show(struct seq_file *s, void 
*unused)
while (true) {
seq = read_seqcount_begin(&robj->seq);
rcu_read_lock();
-   fobj = rcu_dereference(robj->fence);
-   shared_count = fobj ? fobj->shared_count : 0;
fence = rcu_dereference(robj->fence_excl);
+   fence = dma_fence_get_rcu(fence);
if (!read_seqcount_retry(&robj->seq, seq))
break;
rcu_read_unlock();
}
-
-   if (fence)
+   if (fence) {
seq_printf(s, "\tExclusive fence: %s %s %ssignalled\n",
   fence->ops->get_driver_name(fence),
   fence->ops->get_timeline_name(fence),
   dma_fence_is_signaled(fence) ? "" : "un");
-   for (i = 0; i < shared_count; i++) {
+   dma_fence_put(fence);
+   }
+
+   rcu_read_lock();
+   fobj = rcu_dereference(robj->fence);
+   shared_count = fobj ? fobj->shared_count : 0;
+   for (i = 0, fence = NULL; i < shared_count; i++) {
fence = rcu_dereference(fobj->shared[i]);
if (!dma_fence_get_rcu(fence))
continue;
+   rcu_read_unlock();
+
seq_printf(s, "\tShared fence: %s %s %ssignalled\n",
   fence->ops->get_driver_name(fence),
   fence->ops->get_timeline_name(fence),
   dma_fence_is_signaled(fence) ? "" : "un");
+   dma_fence_put(fence);
+
+   rcu_read_lock();
+   fobj = rcu_dereference(robj->fence);
+   shared_count = fobj ? fobj->shared_count : 0;
}
rcu_read_unlock();
 
-- 
2.17.2



Re: [RFC PATCH v8 4/4] sound/usb: Use Media Controller API to share media resources

2018-12-06 Thread shuah

Hi Hans,

On 11/20/18 4:54 AM, Hans Verkuil wrote:

On 11/02/2018 01:31 AM, sh...@kernel.org wrote:

From: Shuah Khan 

Change ALSA driver to use Media Controller API to share media resources
with DVB, and V4L2 drivers on a AU0828 media device.

Media Controller specific initialization is done after sound card is
registered. ALSA creates Media interface and entity function graph
nodes for Control, Mixer, PCM Playback, and PCM Capture devices.

snd_usb_hw_params() will call Media Controller enable source handler
interface to request the media resource. If resource request is granted,
it will release it from snd_usb_hw_free(). If resource is busy, -EBUSY is
returned.

Media specific cleanup is done in usb_audio_disconnect().

Signed-off-by: Shuah Khan 


Thanks for the review. Fixing them all in the next revision.

-- Shuah



Re: [RFC PATCH v8 1/4] media: Media Device Allocator API

2018-12-06 Thread shuah

On 11/19/18 1:59 AM, Pavel Machek wrote:

On Thu 2018-11-01 18:31:30, sh...@kernel.org wrote:

From: Shuah Khan 

Media Device Allocator API to allows multiple drivers share a media device.
Using this API, drivers can allocate a media device with the shared struct
device as the key. Once the media device is allocated by a driver, other
drivers can get a reference to it. The media device is released when all
the references are released.


Sounds like a ... bad idea?

That's what new "media control" framework is for, no?

Why do you need this?
Pavel



Media control framework doesn't address this problem of ownership of the 
media device when non-media drivers have to own the pipeline. In this 
case, snd-usb owns the audio pipeline when an audio application is using 
the device. Without this work, media drivers won't be able to tell if 
snd-usb is using the tuner and owns the media pipeline.


I am going to clarify this in the commit log.

thanks,
-- Shuah


Re: [RFC PATCH v8 3/4] media: media.h: Enable ALSA MEDIA_INTF_T* interface types

2018-12-06 Thread shuah

Hi Hans,

On 11/20/18 4:22 AM, Hans Verkuil wrote:

On 11/02/2018 01:31 AM, sh...@kernel.org wrote:

From: Shuah Khan 

Move ALSA MEDIA_INTF_T* interface types back into __KERNEL__ scope
to get ready for adding ALSA support to the media controller.

Signed-off-by: Shuah Khan 
---
  include/uapi/linux/media.h | 25 ++---
  1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 36f76e777ef9..07be07263597 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -262,6 +262,16 @@ struct media_links_enum {
  #define MEDIA_INTF_T_V4L_SWRADIO  (MEDIA_INTF_T_V4L_BASE + 4)
  #define MEDIA_INTF_T_V4L_TOUCH(MEDIA_INTF_T_V4L_BASE 
+ 5)
  
+#define MEDIA_INTF_T_ALSA_BASE			0x0300

+#define MEDIA_INTF_T_ALSA_PCM_CAPTURE  (MEDIA_INTF_T_ALSA_BASE)
+#define MEDIA_INTF_T_ALSA_PCM_PLAYBACK (MEDIA_INTF_T_ALSA_BASE + 1)
+#define MEDIA_INTF_T_ALSA_CONTROL  (MEDIA_INTF_T_ALSA_BASE + 2)
+#define MEDIA_INTF_T_ALSA_COMPRESS (MEDIA_INTF_T_ALSA_BASE + 3)
+#define MEDIA_INTF_T_ALSA_RAWMIDI  (MEDIA_INTF_T_ALSA_BASE + 4)
+#define MEDIA_INTF_T_ALSA_HWDEP(MEDIA_INTF_T_ALSA_BASE 
+ 5)
+#define MEDIA_INTF_T_ALSA_SEQUENCER(MEDIA_INTF_T_ALSA_BASE + 6)
+#define MEDIA_INTF_T_ALSA_TIMER(MEDIA_INTF_T_ALSA_BASE 
+ 7)
+


I would only enable those defines that you need for the next patch.



Good plan. I fixed this to move just the ones I need for this work.

thanks,
-- Shuah


Re: [RFC PATCH v8 1/4] media: Media Device Allocator API

2018-12-06 Thread shuah

Hi Hans,

On 11/20/18 4:20 AM, Hans Verkuil wrote:

On 11/02/2018 01:31 AM, sh...@kernel.org wrote:

From: Shuah Khan 

Media Device Allocator API to allows multiple drivers share a media device.
Using this API, drivers can allocate a media device with the shared struct
device as the key. Once the media device is allocated by a driver, other
drivers can get a reference to it. The media device is released when all
the references are released.

Signed-off-by: Shuah Khan 


Thanks for catching the documentation corrections. Fixed them all and
working on the next revision of the patch.


---
  Documentation/media/kapi/mc-core.rst |  37 
  drivers/media/Makefile   |   3 +-
  drivers/media/media-dev-allocator.c  | 132 +++
  include/media/media-dev-allocator.h  |  53 +++
  4 files changed, 224 insertions(+), 1 deletion(-)
  create mode 100644 drivers/media/media-dev-allocator.c
  create mode 100644 include/media/media-dev-allocator.h

diff --git a/Documentation/media/kapi/mc-core.rst 
b/Documentation/media/kapi/mc-core.rst
index 0c05503eaf1f..d6f409598065 100644
--- a/Documentation/media/kapi/mc-core.rst
+++ b/Documentation/media/kapi/mc-core.rst
@@ -257,8 +257,45 @@ Subsystems should facilitate link validation by providing 
subsystem specific
  helper functions to provide easy access for commonly needed information, and
  in the end provide a way to use driver-specific callbacks.
  
+Media Controller Device Allocator API

+^
+
+When media device belongs to more than one driver, the shared media device


When -> When the


+is allocated with the shared struct device as the key for look ups.
+
+Shared media device should stay in registered state until the last driver


Shared -> The shared


+unregisters it. In addition, media device should be released when all the


media -> the media


+references are released. Each driver gets a reference to the media device
+during probe, when it allocates the media device. If media device is already
+allocated, allocate API bumps up the refcount and return the existing media


allocate -> the allocate
return -> returns


+device. Driver puts the reference back from its disconnect routine when it


Driver -> The driver
from -> in


+calls :c:func:`media_device_delete()`.
+
+Media device is unregistered and cleaned up from the kref put handler to


Media -> The media
from -> in


+ensure that the media device stays in registered state until the last driver
+unregisters the media device.


What happens if an application still has the media device open and you forcibly
remove the last driver? I think it should be OK since the media_devnode struct
isn't freed until the last open filehandle closes. But it is good to test this.


+
+**Driver Usage**
+
+Drivers should use the media-core routines to get register reference and


'get register reference'? Not sure what you meant to say.


+call :c:func:`media_device_delete()` routine to make sure the shared media
+device delete is handled correctly.
+
+**driver probe:**
+Call :c:func:`media_device_usb_allocate()` to allocate or get a reference
+Call :c:func:`media_device_register()`, if media devnode isn't registered
+
+**driver disconnect:**
+Call :c:func:`media_device_delete()` to free the media_device. Free'ing is


Free'ing -> Freeing


+handled by the kref put handler.
+
+API Definitions
+^^^
+
  .. kernel-doc:: include/media/media-device.h
  
  .. kernel-doc:: include/media/media-devnode.h
  
  .. kernel-doc:: include/media/media-entity.h

+
+.. kernel-doc:: include/media/media-dev-allocator.h
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index 594b462ddf0e..8608f0a41dca 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -3,7 +3,8 @@
  # Makefile for the kernel multimedia device drivers.
  #
  
-media-objs	:= media-device.o media-devnode.o media-entity.o

+media-objs := media-device.o media-devnode.o media-entity.o \
+  media-dev-allocator.o


Perhaps only add media-dev-allocator if CONFIG_USB is enabled?

  
  #

  # I2C drivers should come before other drivers, otherwise they'll fail
diff --git a/drivers/media/media-dev-allocator.c 
b/drivers/media/media-dev-allocator.c
new file mode 100644
index ..262d1293dc13
--- /dev/null
+++ b/drivers/media/media-dev-allocator.c
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * media-dev-allocator.c - Media Controller Device Allocator API
+ *
+ * Copyright (c) 2018 Shuah Khan 
+ *
+ * Credits: Suggested by Laurent Pinchart 
+ */
+
+/*
+ * This file adds a global refcounted Media Controller Device Instance API.
+ * A system wide global media device list is managed and each media device
+ * includes a kref count. The last put on the media device releases the media
+ * device instance.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static LIST_HEAD(media_device_list);
+static DEFINE_MUTE

Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping

2018-12-06 Thread Jerome Glisse
On Thu, Dec 06, 2018 at 08:09:28AM +, Koenig, Christian wrote:
> Am 06.12.18 um 02:41 schrieb jgli...@redhat.com:
> > From: Jérôme Glisse 
> >
> > The debugfs take reference on fence without dropping them. Also the
> > rcu section are not well balance. Fix all that ...
> >
> > Signed-off-by: Jérôme Glisse 
> > Cc: Christian König 
> > Cc: Daniel Vetter 
> > Cc: Sumit Semwal 
> > Cc: linux-media@vger.kernel.org
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: linaro-mm-...@lists.linaro.org
> > Cc: Stéphane Marchesin 
> > Cc: sta...@vger.kernel.org
> 
> Well NAK, you are now taking the RCU lock twice and dropping the RCU and 
> still accessing fobj has a huge potential for accessing freed up memory.
> 
> The only correct thing I can see here is to grab a reference to the 
> fence before printing any info on it,
> Christian.

Hu ? That is exactly what i am doing, take reference under rcu,
rcu_unlock print the fence info, drop the fence reference, rcu
lock rinse and repeat ...

Note that the fobj in _existing_ code is access outside the rcu
end that there is an rcu imbalance in that code ie a lonlely
rcu_unlock after the for loop.

So that the existing code is broken.

> 
> > ---
> >   drivers/dma-buf/dma-buf.c | 11 +--
> >   1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index 13884474d158..f6f4de42ac49 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -1051,24 +1051,31 @@ static int dma_buf_debug_show(struct seq_file *s, 
> > void *unused)
> > fobj = rcu_dereference(robj->fence);
> > shared_count = fobj ? fobj->shared_count : 0;
> > fence = rcu_dereference(robj->fence_excl);
> > +   fence = dma_fence_get_rcu(fence);
> > if (!read_seqcount_retry(&robj->seq, seq))
> > break;
> > rcu_read_unlock();
> > }
> > -
> > -   if (fence)
> > +   if (fence) {
> > seq_printf(s, "\tExclusive fence: %s %s %ssignalled\n",
> >fence->ops->get_driver_name(fence),
> >fence->ops->get_timeline_name(fence),
> >dma_fence_is_signaled(fence) ? "" : "un");
> > +   dma_fence_put(fence);
> > +   }
> > +
> > +   rcu_read_lock();
> > for (i = 0; i < shared_count; i++) {
> > fence = rcu_dereference(fobj->shared[i]);
> > if (!dma_fence_get_rcu(fence))
> > continue;
> > +   rcu_read_unlock();
> > seq_printf(s, "\tShared fence: %s %s %ssignalled\n",
> >fence->ops->get_driver_name(fence),
> >fence->ops->get_timeline_name(fence),
> >dma_fence_is_signaled(fence) ? "" : "un");
> > +   dma_fence_put(fence);
> > +   rcu_read_lock();
> > }
> > rcu_read_unlock();
> >   
> 


Invite for IRC meeting: Re: [PATCHv4 01/10] videodev2.h: add tag support

2018-12-06 Thread Hans Verkuil
Mauro raised a number of objections on irc regarding tags:

https://linuxtv.org/irc/irclogger_log/media-maint?date=2018-12-06,Thu

I would like to setup an irc meeting to discuss this and come to a
conclusion, since we need to decide this soon since this is critical
for stateless codec support.

Unfortunately timezone-wise this is a bit of a nightmare. I think
that at least Mauro, myself and Tomasz Figa should be there, so UTC-2,
UTC+1 and UTC+9 (if I got that right).

I propose 9 AM UTC which I think will work for everyone except Nicolas.
Any day next week works for me, and (for now) as well for Mauro. Let's pick
Monday to start with, and if you want to join in, then let me know. If that
day doesn't work for you, let me know what other days next week do work for
you.

Regards,

Hans

On 12/05/18 11:20, hverkuil-ci...@xs4all.nl wrote:
> From: Hans Verkuil 
> 
> Add support for 'tags' to struct v4l2_buffer. These can be used
> by m2m devices so userspace can set a tag for an output buffer and
> this value will then be copied to the capture buffer(s).
> 
> This tag can be used to refer to capture buffers, something that
> is needed by stateless HW codecs.
> 
> The new V4L2_BUF_CAP_SUPPORTS_TAGS capability indicates whether
> or not tags are supported.
> 
> Signed-off-by: Hans Verkuil 
> Reviewed-by: Paul Kocialkowski 
> Reviewed-by: Alexandre Courbot 
> ---
>  include/uapi/linux/videodev2.h | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 2db1635de956..9095d7abe10d 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -881,6 +881,7 @@ struct v4l2_requestbuffers {
>  #define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
>  #define V4L2_BUF_CAP_SUPPORTS_REQUESTS   (1 << 3)
>  #define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
> +#define V4L2_BUF_CAP_SUPPORTS_TAGS   (1 << 5)
>  
>  /**
>   * struct v4l2_plane - plane info for multi-planar buffers
> @@ -940,6 +941,7 @@ struct v4l2_plane {
>   * @length:  size in bytes of the buffer (NOT its payload) for single-plane
>   *   buffers (when type != *_MPLANE); number of elements in the
>   *   planes array for multi-plane buffers
> + * @tag: buffer tag
>   * @request_fd: fd of the request that this buffer should use
>   *
>   * Contains data exchanged by application and driver using one of the 
> Streaming
> @@ -964,7 +966,10 @@ struct v4l2_buffer {
>   __s32   fd;
>   } m;
>   __u32   length;
> - __u32   reserved2;
> + union {
> + __u32   reserved2;
> + __u32   tag;
> + };
>   union {
>   __s32   request_fd;
>   __u32   reserved;
> @@ -990,6 +995,8 @@ struct v4l2_buffer {
>  #define V4L2_BUF_FLAG_IN_REQUEST 0x0080
>  /* timecode field is valid */
>  #define V4L2_BUF_FLAG_TIMECODE   0x0100
> +/* tag field is valid */
> +#define V4L2_BUF_FLAG_TAG0x0200
>  /* Buffer is prepared for queuing */
>  #define V4L2_BUF_FLAG_PREPARED   0x0400
>  /* Cache handling flags */
> 



Re: [PATCH] [PATCHv2] Add ir-rcmm-driver

2018-12-06 Thread Sean Young
On Wed, Dec 05, 2018 at 01:29:33AM +0100, patrick9...@free.fr wrote:
> From: Patrick LERDA 
> 

We need a Signed-off-by: here.

https://www.kernel.org/doc/html/v4.12/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin

> ---
>  drivers/media/rc/Kconfig   |  10 ++
>  drivers/media/rc/Makefile  |   1 +
>  drivers/media/rc/ir-rcmm-decoder.c | 185 +
>  drivers/media/rc/rc-core-priv.h|   5 +
>  drivers/media/rc/rc-main.c |   3 +
>  include/media/rc-map.h |   6 +-
>  include/uapi/linux/lirc.h  |   1 +
>  tools/include/uapi/linux/lirc.h|   1 +
>  8 files changed, 210 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/media/rc/ir-rcmm-decoder.c
> 
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 1021c08a9ba4..b7e08324b874 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -133,6 +133,16 @@ config IR_IMON_DECODER
>  remote control and you would like to use it with a raw IR
>  receiver, or if you wish to use an encoder to transmit this IR.
>  
> +config IR_RCMM_DECODER
> + tristate "Enable IR raw decoder for the RC-MM protocol"
> + depends on RC_CORE
> + select BITREVERSE

You're not using bitreverse, so don't depend on it.

> + default y
> +
> + ---help---
> +Enable this option if you have IR with RC-MM protocol, and
> +if the IR is decoded in software
> +
>  endif #RC_DECODERS
>  
>  menuconfig RC_DEVICES
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index e0340d043fe8..fc4058013234 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_IR_SHARP_DECODER) += ir-sharp-decoder.o
>  obj-$(CONFIG_IR_MCE_KBD_DECODER) += ir-mce_kbd-decoder.o
>  obj-$(CONFIG_IR_XMP_DECODER) += ir-xmp-decoder.o
>  obj-$(CONFIG_IR_IMON_DECODER) += ir-imon-decoder.o
> +obj-$(CONFIG_IR_RCMM_DECODER) += ir-rcmm-decoder.o
>  
>  # stand-alone IR receivers/transmitters
>  obj-$(CONFIG_RC_ATI_REMOTE) += ati_remote.o
> diff --git a/drivers/media/rc/ir-rcmm-decoder.c 
> b/drivers/media/rc/ir-rcmm-decoder.c
> new file mode 100644
> index ..94d5b70f7a0f
> --- /dev/null
> +++ b/drivers/media/rc/ir-rcmm-decoder.c
> @@ -0,0 +1,185 @@
> +/* ir-rcmm-decoder.c - A decoder for the RCMM IR protocol
> + *
> + * Copyright (C) 2016 by Patrick Lerda
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.

Replace this with the SPDX-License-Identifier.

> + */
> +
> +#include "rc-core-priv.h"
> +#include 
> +#include 
> +
> +
> +#define RCMM_UNIT17  /* nanosecs */
> +#define RCMM_0_NBITS 64

Not used.

> +#define RCMM_PREFIX_PULSE41  /* 16.6*2.5 */
> +#define RCMM_PULSE_027  /* 16.6*(1+2/3) */
> +#define RCMM_PULSE_144  /* 16.6*(2+2/3) */
> +#define RCMM_PULSE_261  /* 16.6*(3+2/3) */
> +#define RCMM_PULSE_378  /* 16.6*(4+2/3) */
> +#define RCMM_MODE_MASK  0x

Not used.
> +
> +enum rcmm_state {
> + STATE_INACTIVE,
> + STATE_LOW,
> + STATE_BUMP,
> + STATE_VALUE,
> + STATE_FINISHED,
> +};
> +
> +static bool rcmm_mode(struct rcmm_dec *data)
> +{
> +return !((0x000c & data->bits) == 0x000c);
> +}
> +
> +/**
> + * ir_rcmm_decode() - Decode one RCMM pulse or space
> + * @dev: the struct rc_dev descriptor of the device
> + * @ev:  the struct ir_raw_event descriptor of the pulse/space
> + *
> + * This function returns -EINVAL if the pulse violates the state machine
> + */
> +static int ir_rcmm_decode(struct rc_dev *dev, struct ir_raw_event ev)
> +{
> + struct rcmm_dec *data = &dev->raw->rcmm;
> + u32 scancode;
> + u8 toggle;
> +
> + if (!(dev->enabled_protocols & RC_PROTO_BIT_RCMM))
> + return 0;
> +
> + if (!is_timing_event(ev)) {
> + if (ev.reset)
> + data->state = STATE_INACTIVE;
> + return 0;
> + }
> +
> + if (ev.duration > RCMM_PULSE_3 + RCMM_UNIT)
> + goto out;
> +
> + switch (data->state) {
> +
> + case STATE_INACTIVE:
> + if (!ev.pulse)
> + break;
> +
> + /* Note: larger margin on first pulse since each RCMM_UNIT
> +is quite short and some hardware takes some time to
> +adjust to the signal */

Use:
 /*
  * Note:
  */
Type multiline comments pl

Re: [PATCH] media: Use of_node_name_eq for node name comparisons

2018-12-06 Thread Benoit Parrot
Hi Rob,

For ti-vpe/cal.c,

Reviewed-by: Benoit Parrot 

Regards,
Benoit

Rob Herring  wrote on Wed [2018-Dec-05 13:50:29 -0600]:
> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
> 
> Cc: Kyungmin Park 
> Cc: Sylwester Nawrocki 
> Cc: Mauro Carvalho Chehab 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Benoit Parrot 
> Cc: Hyun Kwon 
> Cc: Laurent Pinchart 
> Cc: Michal Simek 
> Cc: linux-media@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  drivers/media/platform/exynos4-is/media-dev.c | 12 ++--
>  drivers/media/platform/ti-vpe/cal.c   |  4 ++--
>  drivers/media/platform/xilinx/xilinx-tpg.c|  2 +-
>  drivers/media/v4l2-core/v4l2-fwnode.c |  6 ++
>  4 files changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/media/platform/exynos4-is/media-dev.c 
> b/drivers/media/platform/exynos4-is/media-dev.c
> index 870501b0f351..ced14af56606 100644
> --- a/drivers/media/platform/exynos4-is/media-dev.c
> +++ b/drivers/media/platform/exynos4-is/media-dev.c
> @@ -445,7 +445,7 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
>*/
>   np = of_get_parent(rem);
>  
> - if (np && !of_node_cmp(np->name, "i2c-isp"))
> + if (of_node_name_eq(np, "i2c-isp"))
>   pd->fimc_bus_type = FIMC_BUS_TYPE_ISP_WRITEBACK;
>   else
>   pd->fimc_bus_type = pd->sensor_bus_type;
> @@ -495,7 +495,7 @@ static int fimc_md_register_sensor_entities(struct 
> fimc_md *fmd)
>   for_each_available_child_of_node(parent, node) {
>   struct device_node *port;
>  
> - if (of_node_cmp(node->name, "csis"))
> + if (!of_node_name_eq(node, "csis"))
>   continue;
>   /* The csis node can have only port subnode. */
>   port = of_get_next_child(node, NULL);
> @@ -720,13 +720,13 @@ static int fimc_md_register_platform_entities(struct 
> fimc_md *fmd,
>   continue;
>  
>   /* If driver of any entity isn't ready try all again later. */
> - if (!strcmp(node->name, CSIS_OF_NODE_NAME))
> + if (of_node_name_eq(node, CSIS_OF_NODE_NAME))
>   plat_entity = IDX_CSIS;
> - else if (!strcmp(node->name, FIMC_IS_OF_NODE_NAME))
> + else if (of_node_name_eq(node, FIMC_IS_OF_NODE_NAME))
>   plat_entity = IDX_IS_ISP;
> - else if (!strcmp(node->name, FIMC_LITE_OF_NODE_NAME))
> + else if (of_node_name_eq(node, FIMC_LITE_OF_NODE_NAME))
>   plat_entity = IDX_FLITE;
> - else if (!strcmp(node->name, FIMC_OF_NODE_NAME) &&
> + else if (of_node_name_eq(node, FIMC_OF_NODE_NAME) &&
>!of_property_read_bool(node, "samsung,lcd-wb"))
>   plat_entity = IDX_FIMC;
>  
> diff --git a/drivers/media/platform/ti-vpe/cal.c 
> b/drivers/media/platform/ti-vpe/cal.c
> index 95a093f41905..fc3c212b96e1 100644
> --- a/drivers/media/platform/ti-vpe/cal.c
> +++ b/drivers/media/platform/ti-vpe/cal.c
> @@ -1615,7 +1615,7 @@ of_get_next_port(const struct device_node *parent,
>   return NULL;
>   }
>   prev = port;
> - } while (of_node_cmp(port->name, "port") != 0);
> + } while (!of_node_name_eq(port, "port"));
>   }
>  
>   return port;
> @@ -1635,7 +1635,7 @@ of_get_next_endpoint(const struct device_node *parent,
>   if (!ep)
>   return NULL;
>   prev = ep;
> - } while (of_node_cmp(ep->name, "endpoint") != 0);
> + } while (!of_node_name_eq(ep, "endpoint"));
>  
>   return ep;
>  }
> diff --git a/drivers/media/platform/xilinx/xilinx-tpg.c 
> b/drivers/media/platform/xilinx/xilinx-tpg.c
> index 851d20dcd550..ce686b8d6cff 100644
> --- a/drivers/media/platform/xilinx/xilinx-tpg.c
> +++ b/drivers/media/platform/xilinx/xilinx-tpg.c
> @@ -725,7 +725,7 @@ static int xtpg_parse_of(struct xtpg_device *xtpg)
>   const struct xvip_video_format *format;
>   struct device_node *endpoint;
>  
> - if (!port->name || of_node_cmp(port->name, "port"))
> + if (!of_node_name_eq(port, "port"))
>   continue;
>  
>   format = xvip_of_get_format(port);
> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
> b/drivers/media/v4l2-core/v4l2-fwnode.c
> index 218f0da0ce76..849326241b17 100644
> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> @@ -564,8 +564,7 @@ int v4l2_fwnode_parse_link(struct fwnode_handle *__fwnode,
>   fwnode = fwnode_get_parent(__fwnode);
>   fwnode_property_read_u32(fwnode, port_prop, &link->local_port);
>   fwnode = fwnode_get_next_parent(fwnod

[PATCH bpf-next v3] media: bpf: add bpf function to report mouse movement

2018-12-06 Thread Sean Young
Some IR remotes have a directional pad or other pointer-like thing that
can be used as a mouse. Make it possible to decode these types of IR
protocols in BPF.

Cc: net...@vger.kernel.org
Signed-off-by: Sean Young 
---
 drivers/media/rc/bpf-lirc.c   | 24 +++
 include/uapi/linux/bpf.h  | 17 -
 tools/include/uapi/linux/bpf.h| 18 -
 tools/testing/selftests/bpf/bpf_helpers.h |  2 +
 .../testing/selftests/bpf/test_lirc_mode2.sh  |  3 +-
 .../selftests/bpf/test_lirc_mode2_kern.c  |  3 +
 .../selftests/bpf/test_lirc_mode2_user.c  | 65 +--
 7 files changed, 109 insertions(+), 23 deletions(-)

diff --git a/drivers/media/rc/bpf-lirc.c b/drivers/media/rc/bpf-lirc.c
index 8b97fd1f0cea..390a722e6211 100644
--- a/drivers/media/rc/bpf-lirc.c
+++ b/drivers/media/rc/bpf-lirc.c
@@ -59,6 +59,28 @@ static const struct bpf_func_proto rc_keydown_proto = {
.arg4_type = ARG_ANYTHING,
 };
 
+BPF_CALL_3(bpf_rc_pointer_rel, u32*, sample, s32, rel_x, s32, rel_y)
+{
+   struct ir_raw_event_ctrl *ctrl;
+
+   ctrl = container_of(sample, struct ir_raw_event_ctrl, bpf_sample);
+
+   input_report_rel(ctrl->dev->input_dev, REL_X, rel_x);
+   input_report_rel(ctrl->dev->input_dev, REL_Y, rel_y);
+   input_sync(ctrl->dev->input_dev);
+
+   return 0;
+}
+
+static const struct bpf_func_proto rc_pointer_rel_proto = {
+   .func  = bpf_rc_pointer_rel,
+   .gpl_only  = true,
+   .ret_type  = RET_INTEGER,
+   .arg1_type = ARG_PTR_TO_CTX,
+   .arg2_type = ARG_ANYTHING,
+   .arg3_type = ARG_ANYTHING,
+};
+
 static const struct bpf_func_proto *
 lirc_mode2_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
 {
@@ -67,6 +89,8 @@ lirc_mode2_func_proto(enum bpf_func_id func_id, const struct 
bpf_prog *prog)
return &rc_repeat_proto;
case BPF_FUNC_rc_keydown:
return &rc_keydown_proto;
+   case BPF_FUNC_rc_pointer_rel:
+   return &rc_pointer_rel_proto;
case BPF_FUNC_map_lookup_elem:
return &bpf_map_lookup_elem_proto;
case BPF_FUNC_map_update_elem:
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index a84fd232d934..fe3c90cf6484 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -2298,6 +2298,20 @@ union bpf_attr {
  * payload and/or *pop* value being to large.
  * Return
  * 0 on success, or a negative error in case of failure.
+ *
+ * int bpf_rc_pointer_rel(void *ctx, s32 rel_x, s32 rel_y)
+ * Description
+ * This helper is used in programs implementing IR decoding, to
+ * report a successfully decoded pointer movement.
+ *
+ * The *ctx* should point to the lirc sample as passed into
+ * the program.
+ *
+ * This helper is only available is the kernel was compiled with
+ * the **CONFIG_BPF_LIRC_MODE2** configuration option set to
+ * "**y**".
+ * Return
+ * 0
  */
 #define __BPF_FUNC_MAPPER(FN)  \
FN(unspec), \
@@ -2391,7 +2405,8 @@ union bpf_attr {
FN(map_pop_elem),   \
FN(map_peek_elem),  \
FN(msg_push_data),  \
-   FN(msg_pop_data),
+   FN(msg_pop_data),   \
+   FN(rc_pointer_rel),
 
 /* integer value in 'imm' field of BPF_CALL instruction selects which helper
  * function eBPF program intends to call
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 16263e8827fc..9c5bf9be75af 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -2295,9 +2295,22 @@ union bpf_attr {
  * if possible. Other errors can occur if input parameters are
  * invalid either due to *start* byte not being valid part of msg
  * payload and/or *pop* value being to large.
+ * Return
+ * 0 on success, or a negative error in case of failure.
+ *
+ * int bpf_rc_pointer_rel(void *ctx, s32 rel_x, s32 rel_y)
+ * Description
+ * This helper is used in programs implementing IR decoding, to
+ * report a successfully decoded pointer movement.
+ *
+ * The *ctx* should point to the lirc sample as passed into
+ * the program.
  *
+ * This helper is only available is the kernel was compiled with
+ * the **CONFIG_BPF_LIRC_MODE2** configuration option set to
+ * "**y**".
  * Return
- * 0 on success, or a negative erro in case of failure.
+ * 0
  */
 #define __BPF_FUNC_MAPPER(FN)  \
FN(unspec), \
@@ -2391,7 +2404,8 @@ union bpf_attr {
FN(map_pop_elem),   \
FN(map_peek_elem),  \
FN(msg_push_data),  \
-   FN(msg_pop_data),
+   FN(msg_pop_data),

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

2018-12-06 Thread Heiko Stuebner
Am Freitag, 30. November 2018, 18:34:31 CET schrieb 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 

applied for 4.21 after a tiny bit of reordering

Thanks for seeing this through
Heiko




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

2018-12-06 Thread Heiko Stuebner
Am Freitag, 30. November 2018, 18:34:32 CET schrieb 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 

applied for 4.21 after a tiny bit of reordering

Thanks for seeing this through
Heiko




Re: [PATCH v5] media: imx: add mem2mem device

2018-12-06 Thread Hans Verkuil
On 12/06/18 00:13, Steve Longerbeam wrote:
> 
> 
> On 12/5/18 10:50 AM, Hans Verkuil wrote:
>> On 12/05/2018 02:20 AM, Steve Longerbeam wrote:
>>> Hi Hans, Philipp,
>>>
>>> One comment on my side...
>>>
>>> On 12/3/18 7:21 AM, Hans Verkuil wrote:
 
> +void imx_media_mem2mem_device_unregister(struct imx_media_video_dev 
> *vdev)
> +{
> + struct mem2mem_priv *priv = to_mem2mem_priv(vdev);
> + struct video_device *vfd = priv->vdev.vfd;
> +
> + mutex_lock(&priv->mutex);
> +
> + if (video_is_registered(vfd)) {
> + video_unregister_device(vfd);
> + media_entity_cleanup(&vfd->entity);
 Is this needed?

 If this is to be part of the media controller, then I expect to see a call
 to v4l2_m2m_register_media_controller() somewhere.

>>> Yes, I agree there should be a call to
>>> v4l2_m2m_register_media_controller(). This driver does not connect with
>>> any of the imx-media entities, but calling it will at least make the
>>> mem2mem output/capture device entities (and processing entity) visible
>>> in the media graph.
>>>
>>> Philipp, can you pick/squash the following from my media-tree github fork?
>>>
>>> 6fa05f5170 ("media: imx: mem2mem: Add missing media-device header")
>>> d355bf8b15 ("media: imx: Add missing unregister and remove of mem2mem
>>> device")
>>> 6787a50cdc ("media: imx: mem2mem: Register with media control")
>>>
>>> Steve
>>>
>> Why is this driver part of the imx driver? Since it doesn't connect with
>> any of the imx-media entities, doesn't that mean that this is really a
>> stand-alone driver?
> 
> It is basically a stand-alone m2m driver, but it makes use of some 
> imx-media utility functions like imx_media_enum_format(). Also making it 
> a true stand-alone driver would require creating a second /dev/mediaN 
> device.

If it is standalone, is it reused in newer iMX versions? (7 or 8)

And if it is just a regular m2m device, then it doesn't need to create a
media device either (doesn't hurt, but it is not required).

Regards,

Hans

> 
> Steve
> 



[PATCH] media: siano: Use kmemdup instead of duplicating its function

2018-12-06 Thread Wen Yang
kmemdup has implemented the function that kmalloc() + memcpy().
We prefer to kmemdup rather than code opened implementation.

This issue was detected with the help of coccinelle.

Signed-off-by: Wen Yang 
CC: Mauro Carvalho Chehab 
CC: Tomoki Sekiyama 
CC: linux-media@vger.kernel.org
CC: linux-ker...@vger.kernel.org
---
 drivers/media/usb/siano/smsusb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/usb/siano/smsusb.c b/drivers/media/usb/siano/smsusb.c
index be3634407f1f..2ffded08407b 100644
--- a/drivers/media/usb/siano/smsusb.c
+++ b/drivers/media/usb/siano/smsusb.c
@@ -225,10 +225,9 @@ static int smsusb_sendrequest(void *context, void *buffer, 
size_t size)
return -ENOENT;
}
 
-   phdr = kmalloc(size, GFP_KERNEL);
+   phdr = kmemdup(buffer, size, GFP_KERNEL);
if (!phdr)
return -ENOMEM;
-   memcpy(phdr, buffer, size);
 
pr_debug("sending %s(%d) size: %d\n",
  smscore_translate_msg(phdr->msg_type), phdr->msg_type,
-- 
2.19.1



Re: [PATCHv4 00/10] vb2/cedrus: add tag support

2018-12-06 Thread Hans Verkuil
(fix copy and paste error in the cover letter)

As was discussed here (among other places):

https://lkml.org/lkml/2018/10/19/440

using capture queue buffer indices to refer to reference frames is
not a good idea. A better idea is to use a 'tag' where the
application can assign a u32 tag to an output buffer, which is then
copied to the capture buffer(s) derived from the output buffer.

It has been suggested that the timestamp can be used for this. But
there are a number of reasons why this is a bad idea:

1) the struct timeval is converted to a u64 in vb2. So there can be
   all sorts of unexpected conversion issues. In particular, the
   output of ns_to_timeval(timeval_to_ns(tv)) does not necessarily
   match the input.

2) it gets worse with the y2038 code where userspace either deals
   with a 32 bit tv_sec value or a 64 bit value.

In other words, using timestamp for this is not a good idea.

This implementation adds a new tag field in a union with the reserved2
field. The interpretation of that union depends on the flags field, so
it still can be used for other things as well. In addition, in the previous
patches the tag was in a union with the timecode field (again determined
by the flags field), so if we need to cram additional information in this
struct we can always put it in a union with the timecode field as well.
It worked for the tag, it should work for other things.

But we really need to start looking at a struct v4l2_ext_buffer.

The first three patches add core tag support, the next two patches document
the tag support, then a new helper function is added to v4l2-mem2mem.c
to easily copy data from a source to a destination buffer that drivers
can use.

Next a new supports_tags vb2_queue flag is added to indicate that
the driver supports tags. Ideally this should not be necessary, but
that would require that all m2m drivers are converted to using the
new helper function introduced in the previous patch. That takes more
time then I have now.

Finally the vim2m, vicodec and cedrus drivers are converted to support
tags.

I also removed the 'pad' fields from the mpeg2 control structs (it
should never been added in the first place) and aligned the structs
to a u32 boundary.

Note that this might change further (Paul suggested using bitfields).

Also note that the cedrus code doesn't set the sequence counter, that's
something that should still be added before this driver can be moved
out of staging.

Note: if no buffer is found for a certain tag, then the dma address
is just set to 0. That happened before as well with invalid buffer
indices. This should be checked in the driver!

Regards,

Hans

Changes since v3:

- use reserved2 for the tag
- split the documentation in two: one documenting the tag, one
  cleaning up the timecode documentation.

Changes since v2:

- rebased
- added Reviewed-by tags
- fixed a few remaining references in the documentation to the old
  v4l2_buffer_tag struct that was used in early versions of this
  series.

Changes since v1:

- changed to a u32 tag. Using a 64 bit tag was overly complicated due
  to the bad layout of the v4l2_buffer struct, and there is no real
  need for it by applications.

Main changes since the RFC:

- Added new buffer capability flag
- Added m2m helper to copy data between buffers
- Added documentation
- Added tag logging in v4l2-ioctl.c


Hans Verkuil (10):
  videodev2.h: add tag support
  vb2: add tag support
  v4l2-ioctl.c: log v4l2_buffer tag
  buffer.rst: document the new buffer tag feature.
  buffer.rst: clean up timecode documentation
  v4l2-mem2mem: add v4l2_m2m_buf_copy_data helper function
  vb2: add new supports_tags queue flag
  vim2m: add tag support
  vicodec: add tag support
  cedrus: add tag support

 Documentation/media/uapi/v4l/buffer.rst   | 28 +
 .../media/uapi/v4l/vidioc-reqbufs.rst |  4 ++
 .../media/common/videobuf2/videobuf2-v4l2.c   | 41 ---
 drivers/media/platform/vicodec/vicodec-core.c | 14 ++-
 drivers/media/platform/vim2m.c| 14 ++-
 drivers/media/v4l2-core/v4l2-ctrls.c  |  9 
 drivers/media/v4l2-core/v4l2-ioctl.c  |  9 ++--
 drivers/media/v4l2-core/v4l2-mem2mem.c| 23 +++
 drivers/staging/media/sunxi/cedrus/cedrus.h   |  9 ++--
 .../staging/media/sunxi/cedrus/cedrus_dec.c   |  2 +
 .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 21 --
 .../staging/media/sunxi/cedrus/cedrus_video.c |  2 +
 include/media/v4l2-mem2mem.h  | 21 ++
 include/media/videobuf2-core.h|  2 +
 include/media/videobuf2-v4l2.h| 21 +-
 include/uapi/linux/v4l2-controls.h| 14 +++
 include/uapi/linux/videodev2.h|  9 +++-
 17 files changed, 168 insertions(+), 75 deletions(-)

-- 
2.19.1


Re: [PATCH v2] media: remove bdisp_dbg_declare() and hva_dbg_declare()

2018-12-06 Thread Fabien DESSENNE
Hi,

The patch itself is OK, but the commit talks about bdisp & hva while the 
patch is also for fimc-is.
Could you please update the commit header & messages?

BR

Fabien

On 02/12/2018 3:04 AM, Yangtao Li wrote:
> We already have the DEFINE_SHOW_ATTRIBUTE.There is no need to define
> bdisp_dbg_declare and hva_dbg_declare,so remove them.Also use
> DEFINE_SHOW_ATTRIBUTE to simplify some code.
>
> Signed-off-by: Yangtao Li 
> ---
> Changes in v2:
> -delete fimc_is_debugfs_open
> ---
>   drivers/media/platform/exynos4-is/fimc-is.c   | 16 ++---
>   .../media/platform/sti/bdisp/bdisp-debug.c| 34 ++
>   drivers/media/platform/sti/hva/hva-debugfs.c  | 36 +++
>   3 files changed, 26 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/media/platform/exynos4-is/fimc-is.c 
> b/drivers/media/platform/exynos4-is/fimc-is.c
> index f5fc54de19da..02da0b06e56a 100644
> --- a/drivers/media/platform/exynos4-is/fimc-is.c
> +++ b/drivers/media/platform/exynos4-is/fimc-is.c
> @@ -738,7 +738,7 @@ int fimc_is_hw_initialize(struct fimc_is *is)
>   return 0;
>   }
>   
> -static int fimc_is_log_show(struct seq_file *s, void *data)
> +static int fimc_is_show(struct seq_file *s, void *data)
>   {
>   struct fimc_is *is = s->private;
>   const u8 *buf = is->memory.vaddr + FIMC_IS_DEBUG_REGION_OFFSET;
> @@ -752,17 +752,7 @@ static int fimc_is_log_show(struct seq_file *s, void 
> *data)
>   return 0;
>   }
>   
> -static int fimc_is_debugfs_open(struct inode *inode, struct file *file)
> -{
> - return single_open(file, fimc_is_log_show, inode->i_private);
> -}
> -
> -static const struct file_operations fimc_is_debugfs_fops = {
> - .open   = fimc_is_debugfs_open,
> - .read   = seq_read,
> - .llseek = seq_lseek,
> - .release= single_release,
> -};
> +DEFINE_SHOW_ATTRIBUTE(fimc_is);
>   
>   static void fimc_is_debugfs_remove(struct fimc_is *is)
>   {
> @@ -777,7 +767,7 @@ static int fimc_is_debugfs_create(struct fimc_is *is)
>   is->debugfs_entry = debugfs_create_dir("fimc_is", NULL);
>   
>   dentry = debugfs_create_file("fw_log", S_IRUGO, is->debugfs_entry,
> -  is, &fimc_is_debugfs_fops);
> +  is, &fimc_is_fops);
>   if (!dentry)
>   fimc_is_debugfs_remove(is);
>   
> diff --git a/drivers/media/platform/sti/bdisp/bdisp-debug.c 
> b/drivers/media/platform/sti/bdisp/bdisp-debug.c
> index c6a4e2de5c0c..77ca7517fa3e 100644
> --- a/drivers/media/platform/sti/bdisp/bdisp-debug.c
> +++ b/drivers/media/platform/sti/bdisp/bdisp-debug.c
> @@ -315,7 +315,7 @@ static void bdisp_dbg_dump_ivmx(struct seq_file *s,
>   seq_puts(s, "Unknown conversion\n");
>   }
>   
> -static int bdisp_dbg_last_nodes(struct seq_file *s, void *data)
> +static int last_nodes_show(struct seq_file *s, void *data)
>   {
>   /* Not dumping all fields, focusing on significant ones */
>   struct bdisp_dev *bdisp = s->private;
> @@ -388,7 +388,7 @@ static int bdisp_dbg_last_nodes(struct seq_file *s, void 
> *data)
>   return 0;
>   }
>   
> -static int bdisp_dbg_last_nodes_raw(struct seq_file *s, void *data)
> +static int last_nodes_raw_show(struct seq_file *s, void *data)
>   {
>   struct bdisp_dev *bdisp = s->private;
>   struct bdisp_node *node;
> @@ -437,7 +437,7 @@ static const char *bdisp_fmt_to_str(struct bdisp_frame 
> frame)
>   }
>   }
>   
> -static int bdisp_dbg_last_request(struct seq_file *s, void *data)
> +static int last_request_show(struct seq_file *s, void *data)
>   {
>   struct bdisp_dev *bdisp = s->private;
>   struct bdisp_request *request = &bdisp->dbg.copy_request;
> @@ -474,7 +474,7 @@ static int bdisp_dbg_last_request(struct seq_file *s, 
> void *data)
>   
>   #define DUMP(reg) seq_printf(s, #reg " \t0x%08X\n", readl(bdisp->regs + 
> reg))
>   
> -static int bdisp_dbg_regs(struct seq_file *s, void *data)
> +static int regs_show(struct seq_file *s, void *data)
>   {
>   struct bdisp_dev *bdisp = s->private;
>   int ret;
> @@ -582,7 +582,7 @@ static int bdisp_dbg_regs(struct seq_file *s, void *data)
>   
>   #define SECOND 100
>   
> -static int bdisp_dbg_perf(struct seq_file *s, void *data)
> +static int perf_show(struct seq_file *s, void *data)
>   {
>   struct bdisp_dev *bdisp = s->private;
>   struct bdisp_request *request = &bdisp->dbg.copy_request;
> @@ -627,27 +627,15 @@ static int bdisp_dbg_perf(struct seq_file *s, void 
> *data)
>   return 0;
>   }
>   
> -#define bdisp_dbg_declare(name) \
> - static int bdisp_dbg_##name##_open(struct inode *i, struct file *f) \
> - { \
> - return single_open(f, bdisp_dbg_##name, i->i_private); \
> - } \
> - static const struct file_operations bdisp_dbg_##name##_fops = { \
> - .open   = bdisp_dbg_##name##_open, \
> - .read   = seq_read, \
> - .llseek = seq_lseek, \
> -

Re: [PATCH 5/5] arm64: dts: allwinner: a64-amarula-relic: Add OV5640 camera node

2018-12-06 Thread Jagan Teki
On Mon, Dec 3, 2018 at 3:55 PM Chen-Yu Tsai  wrote:
>
> On Mon, Dec 3, 2018 at 6:08 PM Jagan Teki  wrote:
> >
> > Amarula A64-Relic board by default bound with OV5640 camera,
> > so add support for it with below pin information.
> >
> > - PE13, PE12 via i2c-gpio bitbanging
> > - CLK_CSI_MCLK as external clock
> > - PE1 as external clock pin muxing
> > - DLDO3 as vcc-csi supply
> > - DLDO3 as AVDD supply
> > - ALDO1 as DOVDD supply
> > - ELDO3 as DVDD supply
> > - PE14 gpio for reset pin
> > - PE15 gpio for powerdown pin
> >
> > Signed-off-by: Jagan Teki 
> > ---
> >  .../allwinner/sun50i-a64-amarula-relic.dts| 54 +++
> >  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi |  5 ++
> >  2 files changed, 59 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts 
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> > index 6cb2b7f0c817..9ac6d773188b 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
> > @@ -22,6 +22,41 @@
> > stdout-path = "serial0:115200n8";
> > };
> >
> > +   i2c-csi {
> > +   compatible = "i2c-gpio";
> > +   sda-gpios = <&pio 4 13 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
> > +   scl-gpios = <&pio 4 12 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
>
> FYI our hardware doesn't do open drain.

True, but the kernel is enforcing it seems, from the change from [1].
does that mean Linux use open drain even though hardware doens't have?
or did I miss anything?

[3.659235] gpio-141 (sda): enforced open drain please flag it
properly in DT/ACPI DSDT/board file
[3.679954] gpio-140 (scl): enforced open drain please flag it
properly in DT/ACPI DSDT/board file
[3.814878] i2c-gpio i2c-csi: using lines 141 (SDA) and 140 (SCL)

>
> > +   i2c-gpio,delay-us = <5>;
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   ov5640: camera@3c {
> > +   compatible = "ovti,ov5640";
> > +   reg = <0x3c>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <&csi_mclk_pin>;
> > +   clocks = <&ccu CLK_CSI_MCLK>;
> > +   clock-names = "xclk";
> > +
> > +   AVDD-supply = <®_dldo3>;
> > +   DOVDD-supply = <®_aldo1>;
>
> DOVDD is the supply for I/O. You say it is ALDO1 here.
>
> > +   DVDD-supply = <®_eldo3>;
> > +   reset-gpios = <&pio 4 14 GPIO_ACTIVE_LOW>; /* 
> > CSI-RST-R: PE14 */
> > +   powerdown-gpios = <&pio 4 15 GPIO_ACTIVE_HIGH>; /* 
> > CSI-STBY-R: PE15 */
> > +
> > +   port {
> > +   ov5640_ep: endpoint {
> > +   remote-endpoint = <&csi_ep>;
> > +   bus-width = <8>;
> > +   hsync-active = <1>; /* Active high 
> > */
> > +   vsync-active = <0>; /* Active low */
> > +   data-active = <1>;  /* Active high 
> > */
> > +   pclk-sample = <1>;  /* Rising */
> > +   };
> > +   };
> > +   };
> > +   };
> > +
> > wifi_pwrseq: wifi-pwrseq {
> > compatible = "mmc-pwrseq-simple";
> > clocks = <&rtc 1>;
> > @@ -30,6 +65,25 @@
> > };
> >  };
> >
> > +&csi {
> > +   vcc-csi-supply = <®_dldo3>;
>
> But here you say the SoC-side pins are driven from DLDO3.
>
> This is a somewhat odd mismatch.
>
> Regardless, the ov5640 driver enables all three regulators at probe time.
> Shouldn't that be enough to get the I2C bus working? The pin voltage
> supply does not belong here.

It is working w/o supplying PE group, but I think that may be reason
of supplying similar regulator via DOVDD on sensor side. But we need
to make sure the pin-group must be powered right like DSI, HDMI? if
yes may be we do something via power-domain driver like other SoC's
does or do we have any other option.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpio/gpiolib.c?id=f926dfc112bc6cf41d7068ee5e3f261e13a5bec8


Re: [PATCH] media: Use of_node_name_eq for node name comparisons

2018-12-06 Thread Laurent Pinchart
Hi Rob,

Thank you for the patch.

On Wednesday, 5 December 2018 21:50:29 EET Rob Herring wrote:
> Convert string compares of DT node names to use of_node_name_eq helper
> instead. This removes direct access to the node name pointer.
> 
> Cc: Kyungmin Park 
> Cc: Sylwester Nawrocki 
> Cc: Mauro Carvalho Chehab 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Benoit Parrot 
> Cc: Hyun Kwon 
> Cc: Laurent Pinchart 
> Cc: Michal Simek 
> Cc: linux-media@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  drivers/media/platform/exynos4-is/media-dev.c | 12 ++--
>  drivers/media/platform/ti-vpe/cal.c   |  4 ++--
>  drivers/media/platform/xilinx/xilinx-tpg.c|  2 +-
>  drivers/media/v4l2-core/v4l2-fwnode.c |  6 ++
>  4 files changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/media/platform/exynos4-is/media-dev.c
> b/drivers/media/platform/exynos4-is/media-dev.c index
> 870501b0f351..ced14af56606 100644
> --- a/drivers/media/platform/exynos4-is/media-dev.c
> +++ b/drivers/media/platform/exynos4-is/media-dev.c
> @@ -445,7 +445,7 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
>*/
>   np = of_get_parent(rem);
> 
> - if (np && !of_node_cmp(np->name, "i2c-isp"))
> + if (of_node_name_eq(np, "i2c-isp"))
>   pd->fimc_bus_type = FIMC_BUS_TYPE_ISP_WRITEBACK;
>   else
>   pd->fimc_bus_type = pd->sensor_bus_type;
> @@ -495,7 +495,7 @@ static int fimc_md_register_sensor_entities(struct
> fimc_md *fmd) for_each_available_child_of_node(parent, node) {
>   struct device_node *port;
> 
> - if (of_node_cmp(node->name, "csis"))
> + if (!of_node_name_eq(node, "csis"))
>   continue;
>   /* The csis node can have only port subnode. */
>   port = of_get_next_child(node, NULL);
> @@ -720,13 +720,13 @@ static int fimc_md_register_platform_entities(struct
> fimc_md *fmd, continue;
> 
>   /* If driver of any entity isn't ready try all again later. */
> - if (!strcmp(node->name, CSIS_OF_NODE_NAME))
> + if (of_node_name_eq(node, CSIS_OF_NODE_NAME))
>   plat_entity = IDX_CSIS;
> - else if (!strcmp(node->name, FIMC_IS_OF_NODE_NAME))
> + else if (of_node_name_eq(node, FIMC_IS_OF_NODE_NAME))

You might want to s/if\t/if / while at it.

>   plat_entity = IDX_IS_ISP;
> - else if (!strcmp(node->name, FIMC_LITE_OF_NODE_NAME))
> + else if (of_node_name_eq(node, FIMC_LITE_OF_NODE_NAME))
>   plat_entity = IDX_FLITE;
> - else if (!strcmp(node->name, FIMC_OF_NODE_NAME) &&
> + else if (of_node_name_eq(node, FIMC_OF_NODE_NAME) &&

And here too.

Apart from that,

Reviewed-by: Laurent Pinchart 

>!of_property_read_bool(node, "samsung,lcd-wb"))
>   plat_entity = IDX_FIMC;
> 
> diff --git a/drivers/media/platform/ti-vpe/cal.c
> b/drivers/media/platform/ti-vpe/cal.c index 95a093f41905..fc3c212b96e1
> 100644
> --- a/drivers/media/platform/ti-vpe/cal.c
> +++ b/drivers/media/platform/ti-vpe/cal.c
> @@ -1615,7 +1615,7 @@ of_get_next_port(const struct device_node *parent,
>   return NULL;
>   }
>   prev = port;
> - } while (of_node_cmp(port->name, "port") != 0);
> + } while (!of_node_name_eq(port, "port"));
>   }
> 
>   return port;
> @@ -1635,7 +1635,7 @@ of_get_next_endpoint(const struct device_node *parent,
> if (!ep)
>   return NULL;
>   prev = ep;
> - } while (of_node_cmp(ep->name, "endpoint") != 0);
> + } while (!of_node_name_eq(ep, "endpoint"));
> 
>   return ep;
>  }
> diff --git a/drivers/media/platform/xilinx/xilinx-tpg.c
> b/drivers/media/platform/xilinx/xilinx-tpg.c index
> 851d20dcd550..ce686b8d6cff 100644
> --- a/drivers/media/platform/xilinx/xilinx-tpg.c
> +++ b/drivers/media/platform/xilinx/xilinx-tpg.c
> @@ -725,7 +725,7 @@ static int xtpg_parse_of(struct xtpg_device *xtpg)
>   const struct xvip_video_format *format;
>   struct device_node *endpoint;
> 
> - if (!port->name || of_node_cmp(port->name, "port"))
> + if (!of_node_name_eq(port, "port"))
>   continue;
> 
>   format = xvip_of_get_format(port);
> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c
> b/drivers/media/v4l2-core/v4l2-fwnode.c index 218f0da0ce76..849326241b17
> 100644
> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> @@ -564,8 +564,7 @@ int v4l2_fwnode_parse_link(struct fwnode_handle
> *__fwnode, fwnode = fwnode_get_parent(__fwnode);
>   fwnode_property_read_u32(fwnode, port_prop, &link->local_port);
>   fwnode = fwnode_get_next_

Re: [PATCH 1/6] media: v4l2-subdev: stub v4l2_subdev_get_try_format() ??

2018-12-06 Thread jacopo mondi
Hi Lubomir,

On Tue, Dec 04, 2018 at 04:01:43PM +0100, Lubomir Rintel wrote:
> On Mon, 2018-12-03 at 14:48 +0100, jacopo mondi wrote:
> > Hi Lubomir,
> >
> >   thanks for the patches
> >
> > On Wed, Nov 28, 2018 at 06:19:13PM +0100, Lubomir Rintel wrote:
> > > Provide a dummy implementation when configured without
> > > CONFIG_VIDEO_V4L2_SUBDEV_API to avoid ifdef dance in the drivers
> > > that can
> > > be built either with or without the option.
> > >
> > > Suggested-by: Jacopo Mondi 
> > > Signed-off-by: Lubomir Rintel 
> > > ---
> > >  include/media/v4l2-subdev.h | 11 +++
> > >  1 file changed, 11 insertions(+)
> > >
> > > diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-
> > > subdev.h
> > > index 9102d6ca566e..906e28011bb4 100644
> > > --- a/include/media/v4l2-subdev.h
> > > +++ b/include/media/v4l2-subdev.h
> > > @@ -967,6 +967,17 @@ static inline struct v4l2_rect
> > >   pad = 0;
> > >   return &cfg[pad].try_compose;
> > >  }
> > > +
> > > +#else /* !defined(CONFIG_VIDEO_V4L2_SUBDEV_API) */
> > > +
> > > +static inline struct v4l2_mbus_framefmt
> > > +*v4l2_subdev_get_try_format(struct v4l2_subdev *sd,
> > > + struct v4l2_subdev_pad_config *cfg,
> > > + unsigned int pad)
> > > +{
> > > + return ERR_PTR(-ENOTTY);
> > > +}
> > > +
> > >  #endif
> >
> > While at there, what about doing the same for get_try_crop and
> > get_try_compose? At lease provide stubs, I let you figure out if
> > you're willing to fix callers too, it seems there are quite a few of
> > them though
> >
> > $ git grep v4l2_subdev_get_try* drivers/media/ | grep -v '_format' |
> > wc -l
> > 44
>
> I'd be happy to do that. However, the drivers that use those seem to
> depend on CONFIG_VIDEO_V4L2_SUBDEV_API anyway. Should those
> dependencies be eventually done away with?
>

I don't think it is the case to drop the dependencies. If you go down
that path you would need to be very careful. It's enough to add stubs
for those functions like you've done for v4l2_subdev_get_try_format().

Now, looking around a bit in more detail, most sensor drivers return
-ENOTTY if you require V4L2_SUBDEV_FORMAT_TRY format when
CONFIG_VIDEO_V4L2_SUBDEV_API is not defined. I would say all drivers
but mt9v111.c, which is one of the most recent ones, and that deals
with the issue as:

static struct v4l2_mbus_framefmt *__mt9v111_get_pad_format(
struct mt9v111_dev *mt9v111,
struct v4l2_subdev_pad_config *cfg,
unsigned int pad,
enum v4l2_subdev_format_whence which)
{
switch (which) {
case V4L2_SUBDEV_FORMAT_TRY:
#if IS_ENABLED(CONFIG_VIDEO_V4L2_SUBDEV_API)
return v4l2_subdev_get_try_format(&mt9v111->sd, cfg, pad);
#else
return &cfg->try_fmt;
#endif
case V4L2_SUBDEV_FORMAT_ACTIVE:
return &mt9v111->fmt;
default:
return NULL;
}
}

Since I wrote that part, and I recall it had been suggested to me, I
wonder which one of the two approaches it actually correct :/


> Please pardon my ignorance -- I don't actually understand why would
> anyone disable CONFIG_VIDEO_V4L2_SUBDEV_API.

The config options is described as:
Enables the V4L2 sub-device pad-level userspace API used to configure
video format, size and frame rate between hardware blocks.

Some driver simply do not expose a subdev in userspace. It might be
discussed that if selecting MEDIA_CONTROLLER should in facts be enough
and to imply CONFIG_VIDEO_V4L2_SUBDEV_API, but that's a separate
issue.
>
> I'll be following up with a v2 after I get a response from you. It will
> address locking issues found with smatch: one introduced by my patch
> and one that was there before.
>

Yep, ov2659 was b0rken already, thanks for fixing it while at there.

Thanks
   j

> Cheers,
> Lubo
>
> > >  extern const struct v4l2_file_operations v4l2_subdev_fops;
> > > --
> > > 2.19.1
> > >
>


signature.asc
Description: PGP signature


Re: [PATCH] dma-buf: fix debugfs versus rcu and fence dumping

2018-12-06 Thread Koenig, Christian
Am 06.12.18 um 02:41 schrieb jgli...@redhat.com:
> From: Jérôme Glisse 
>
> The debugfs take reference on fence without dropping them. Also the
> rcu section are not well balance. Fix all that ...
>
> Signed-off-by: Jérôme Glisse 
> Cc: Christian König 
> Cc: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: linux-media@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: Stéphane Marchesin 
> Cc: sta...@vger.kernel.org

Well NAK, you are now taking the RCU lock twice and dropping the RCU and 
still accessing fobj has a huge potential for accessing freed up memory.

The only correct thing I can see here is to grab a reference to the 
fence before printing any info on it,
Christian.

> ---
>   drivers/dma-buf/dma-buf.c | 11 +--
>   1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 13884474d158..f6f4de42ac49 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -1051,24 +1051,31 @@ static int dma_buf_debug_show(struct seq_file *s, 
> void *unused)
>   fobj = rcu_dereference(robj->fence);
>   shared_count = fobj ? fobj->shared_count : 0;
>   fence = rcu_dereference(robj->fence_excl);
> + fence = dma_fence_get_rcu(fence);
>   if (!read_seqcount_retry(&robj->seq, seq))
>   break;
>   rcu_read_unlock();
>   }
> -
> - if (fence)
> + if (fence) {
>   seq_printf(s, "\tExclusive fence: %s %s %ssignalled\n",
>  fence->ops->get_driver_name(fence),
>  fence->ops->get_timeline_name(fence),
>  dma_fence_is_signaled(fence) ? "" : "un");
> + dma_fence_put(fence);
> + }
> +
> + rcu_read_lock();
>   for (i = 0; i < shared_count; i++) {
>   fence = rcu_dereference(fobj->shared[i]);
>   if (!dma_fence_get_rcu(fence))
>   continue;
> + rcu_read_unlock();
>   seq_printf(s, "\tShared fence: %s %s %ssignalled\n",
>  fence->ops->get_driver_name(fence),
>  fence->ops->get_timeline_name(fence),
>  dma_fence_is_signaled(fence) ? "" : "un");
> + dma_fence_put(fence);
> + rcu_read_lock();
>   }
>   rcu_read_unlock();
>