Re: [linux-sunxi] [PATCH 14/15] ARM: dts: sun8i: h3: Enable HDMI output on H3 boards

2018-02-26 Thread Julian Calaby
Hi Jernej,

On Tue, Feb 27, 2018 at 3:27 AM, Jernej Škrabec  wrote:
> Hi,
>
> Dne ponedeljek, 26. februar 2018 ob 17:21:05 CET je Icenowy Zheng napisal(a):
>> 于 2018年2月27日 GMT+08:00 上午12:16:44, "Jernej Škrabec"
>  写到:
>> >Hi Julian,
>> >
>> >Dne nedelja, 25. februar 2018 ob 09:11:34 CET je Julian Calaby
>> >
>> >napisal(a):
>> >> Hi Jernej,
>> >>
>> >> On Sun, Feb 25, 2018 at 8:45 AM, Jernej Skrabec
>> >
>> >
>> >
>> >wrote:
>> >> > Enable HDMI output on all boards which have HDMI connector.
>> >> >
>> >> > Signed-off-by: Jernej Skrabec 
>> >> > ---
>> >> >
>> >> >  arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 25
>> >> >  ++ arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
>> >> >
>> >> >   | 25 ++
>> >> >
>> >> >  arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 25
>> >> >  ++ arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
>> >> >
>> >> >   | 25 ++
>> >
>> >arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
>> >
>> >> > | 25 ++
>> >> >
>> >> >  arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts   | 25
>> >> >  ++ arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> >> >
>> >> >   | 24 +
>> >
>> >arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
>> >
>> >> >| 25 ++ 8 files changed, 199
>> >
>> >insertions(+)
>> >
>> >> As I understand it, the H2+ is just a slightly trimmed down H3. In
>> >> terms of HDMI support, the difference is that the H2+ can't output
>> >
>> >4k.
>> >
>> >> If this code is compatible with the H2+, could you please add the
>> >> necessary bits and pieces to the h2-plus DTSs too?
>> >
>> >There are only 3 H2+ boards in kernel and none of them has HDMI
>> >connector, so
>>
>> BPi M2 Zero has miniHDMI connector.
>
> Ah, sorry, I missed that one. Since I don't have it (or any other board with
> H2+) I'm not really comfortable including such patch. If anyone will test it,
> I can include it in next revision.

I have one of those (this is why I'm interested in this patchset) so
I'm willing to test, however I can't guarantee I'll get to it quickly.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 12/15] drm/sun4i: Allow building on arm64

2018-02-26 Thread kbuild test robot
Hi Jernej,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20180226]
[cannot apply to robh/for-next v4.16-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jernej-Skrabec/Implement-H3-H5-HDMI-driver/20180227-054135
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All warnings (new ones prefixed by >>):

   In file included from drivers/gpu//drm/sun4i/sun8i_dw_hdmi.h:12:0,
from drivers/gpu//drm/sun4i/sun8i_hdmi_phy.c:9:
   drivers/gpu//drm/sun4i/sun8i_hdmi_phy.c: In function 
'sun8i_hdmi_phy_config_h3':
>> drivers/gpu//drm/sun4i/sun8i_hdmi_phy.c:188:7: warning: large integer 
>> implicitly truncated to unsigned type [-Woverflow]
  ~SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK, pll_cfg2_init);
  ^
   include/linux/regmap.h:75:36: note: in definition of macro 
'regmap_update_bits'
 regmap_update_bits_base(map, reg, mask, val, NULL, false, false)
   ^~~~

vim +188 drivers/gpu//drm/sun4i/sun8i_hdmi_phy.c

b7c7436a Jernej Skrabec 2018-02-148  
b7c7436a Jernej Skrabec 2018-02-14   @9  #include "sun8i_dw_hdmi.h"
b7c7436a Jernej Skrabec 2018-02-14   10  
b7c7436a Jernej Skrabec 2018-02-14   11  /*
b7c7436a Jernej Skrabec 2018-02-14   12   * Address can be actually any value. 
Here is set to same value as
b7c7436a Jernej Skrabec 2018-02-14   13   * it is set in BSP driver.
b7c7436a Jernej Skrabec 2018-02-14   14   */
b7c7436a Jernej Skrabec 2018-02-14   15  #define I2C_ADDR   0x69
b7c7436a Jernej Skrabec 2018-02-14   16  
322900e8 Jernej Skrabec 2018-02-24   17  static int 
sun8i_hdmi_phy_config_a83t(struct dw_hdmi *hdmi,
322900e8 Jernej Skrabec 2018-02-24   18   
struct sun8i_hdmi_phy *phy,
322900e8 Jernej Skrabec 2018-02-24   19   
unsigned int clk_rate)
b7c7436a Jernej Skrabec 2018-02-14   20  {
b7c7436a Jernej Skrabec 2018-02-14   21 regmap_update_bits(phy->regs, 
SUN8I_HDMI_PHY_REXT_CTRL_REG,
b7c7436a Jernej Skrabec 2018-02-14   22
SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN,
b7c7436a Jernej Skrabec 2018-02-14   23
SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN);
b7c7436a Jernej Skrabec 2018-02-14   24  
b7c7436a Jernej Skrabec 2018-02-14   25 /* power down */
b7c7436a Jernej Skrabec 2018-02-14   26 dw_hdmi_phy_gen2_txpwron(hdmi, 
0);
b7c7436a Jernej Skrabec 2018-02-14   27 dw_hdmi_phy_gen2_pddq(hdmi, 1);
b7c7436a Jernej Skrabec 2018-02-14   28  
b7c7436a Jernej Skrabec 2018-02-14   29 dw_hdmi_phy_reset(hdmi);
b7c7436a Jernej Skrabec 2018-02-14   30  
b7c7436a Jernej Skrabec 2018-02-14   31 dw_hdmi_phy_gen2_pddq(hdmi, 0);
b7c7436a Jernej Skrabec 2018-02-14   32  
b7c7436a Jernej Skrabec 2018-02-14   33 dw_hdmi_phy_i2c_set_addr(hdmi, 
I2C_ADDR);
b7c7436a Jernej Skrabec 2018-02-14   34  
b7c7436a Jernej Skrabec 2018-02-14   35 /*
b7c7436a Jernej Skrabec 2018-02-14   36  * Values are taken from BSP 
HDMI driver. Although AW didn't
b7c7436a Jernej Skrabec 2018-02-14   37  * release any documentation, 
explanation of this values can
b7c7436a Jernej Skrabec 2018-02-14   38  * be found in i.MX 6Dual/6Quad 
Reference Manual.
b7c7436a Jernej Skrabec 2018-02-14   39  */
322900e8 Jernej Skrabec 2018-02-24   40 if (clk_rate <= 2700) {
b7c7436a Jernej Skrabec 2018-02-14   41 
dw_hdmi_phy_i2c_write(hdmi, 0x01e0, 0x06);
b7c7436a Jernej Skrabec 2018-02-14   42 
dw_hdmi_phy_i2c_write(hdmi, 0x, 0x15);
b7c7436a Jernej Skrabec 2018-02-14   43 
dw_hdmi_phy_i2c_write(hdmi, 0x08da, 0x10);
b7c7436a Jernej Skrabec 2018-02-14   44 
dw_hdmi_phy_i2c_write(hdmi, 0x0007, 0x19);
b7c7436a Jernej Skrabec 2018-02-14   45 
dw_hdmi_phy_i2c_write(hdmi, 0x0318, 0x0e);
b7c7436a Jernej Skrabec 2018-02-14   46 
dw_hdmi_phy_i2c_write(hdmi, 0x8009, 0x09);
322900e8 Jernej Skrabec 2018-02-24   47 } else if (clk_rate <= 
7425) {
b7c7436a Jernej Skrabec 2018-02-14   48 
dw_hdmi_phy_i2c_write(hdmi, 0x0540, 0x06);
b7c7436a Jernej Skrabec 2018-02-14   49 
dw_hdmi_phy_i2c_write(hdmi, 0x0005, 0x15);
b7c7436a Jernej Skrabec 2018-02-14   50 
dw_hdmi_phy_i2c_write(hdmi, 0x, 0x10);
b7c7436a Jernej Skrabec 2018-02-14 

[linux-sunxi] [PATCH v8 2/2] media: V3s: Add support for Allwinner CSI.

2018-02-26 Thread Yong Deng
Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
interface and CSI1 is used for parallel interface. This is not
documented in datasheet but by test and guess.

This patch implement a v4l2 framework driver for it.

Currently, the driver only support the parallel interface. MIPI-CSI2,
ISP's support are not included in this patch.

Tested-by: Maxime Ripard 
Signed-off-by: Yong Deng 
---
 MAINTAINERS|   8 +
 drivers/media/platform/Kconfig |   1 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/sunxi/sun6i-csi/Kconfig |   9 +
 drivers/media/platform/sunxi/sun6i-csi/Makefile|   3 +
 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 911 +
 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 143 
 .../media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h | 196 +
 .../media/platform/sunxi/sun6i-csi/sun6i_video.c   | 753 +
 .../media/platform/sunxi/sun6i-csi/sun6i_video.h   |  53 ++
 10 files changed, 2079 insertions(+)
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Kconfig
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Makefile
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
 create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 91ed6adfa4a6..b4a331ad35b5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3793,6 +3793,14 @@ M:   Jaya Kumar 
 S: Maintained
 F: sound/pci/cs5535audio/
 
+CSI DRIVERS FOR ALLWINNER V3s
+M: Yong Deng 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/platform/sunxi/sun6i-csi/
+F: Documentation/devicetree/bindings/media/sun6i-csi.txt
+
 CW1200 WLAN driver
 M: Solomon Peachy 
 S: Maintained
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index f9cc0582c8a9..7f1ee46c3258 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -159,6 +159,7 @@ source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"
 source "drivers/media/platform/rcar-vin/Kconfig"
 source "drivers/media/platform/atmel/Kconfig"
+source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
 
 config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 85e112122f32..143d8a473b0a 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -96,3 +96,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+= 
qcom/camss-8x16/
 obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
 
 obj-y  += meson/
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI)  += sunxi/sun6i-csi/
diff --git a/drivers/media/platform/sunxi/sun6i-csi/Kconfig 
b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
new file mode 100644
index ..314188aae2c2
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
@@ -0,0 +1,9 @@
+config VIDEO_SUN6I_CSI
+   tristate "Allwinner V3s Camera Sensor Interface driver"
+   depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
+   depends on ARCH_SUNXI || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select REGMAP_MMIO
+   select V4L2_FWNODE
+   ---help---
+  Support for the Allwinner Camera Sensor Interface Controller on V3s.
diff --git a/drivers/media/platform/sunxi/sun6i-csi/Makefile 
b/drivers/media/platform/sunxi/sun6i-csi/Makefile
new file mode 100644
index ..213cb6be9e9c
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-csi/Makefile
@@ -0,0 +1,3 @@
+sun6i-csi-y += sun6i_video.o sun6i_csi.o
+
+obj-$(CONFIG_VIDEO_SUN6I_CSI) += sun6i-csi.o
diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
new file mode 100644
index ..1e238d57
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -0,0 +1,911 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2011-2018 Magewell Electronics Co., Ltd. (Nanjing)
+ * All rights reserved.
+ * Author: Yong Deng 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sun6i_csi.h"
+#include "sun6i_csi_reg.h"
+
+#define MODULE_NAME"sun6i-csi"
+
+struct sun6i_csi_dev {
+   struct sun6i_csicsi;
+   struct device   *dev;
+
+   struct regmap   *regmap;
+   struct clk 

[linux-sunxi] [PATCH v8 1/2] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)

2018-02-26 Thread Yong Deng
Add binding documentation for Allwinner V3s CSI.

Acked-by: Maxime Ripard 
Acked-by: Sakari Ailus 
Reviewed-by: Rob Herring 
Signed-off-by: Yong Deng 
---
 .../devicetree/bindings/media/sun6i-csi.txt| 59 ++
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt

diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt 
b/Documentation/devicetree/bindings/media/sun6i-csi.txt
new file mode 100644
index ..2ff47a9507a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
@@ -0,0 +1,59 @@
+Allwinner V3s Camera Sensor Interface
+-
+
+Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
+interface and CSI1 is used for parallel interface.
+
+Required properties:
+  - compatible: value must be "allwinner,sun8i-v3s-csi"
+  - reg: base address and size of the memory-mapped region.
+  - interrupts: interrupt associated to this IP
+  - clocks: phandles to the clocks feeding the CSI
+* bus: the CSI interface clock
+* mod: the CSI module clock
+* ram: the CSI DRAM clock
+  - clock-names: the clock names mentioned above
+  - resets: phandles to the reset line driving the CSI
+
+Each CSI node should contain one 'port' child node with one child 'endpoint'
+node, according to the bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. As mentioned
+above, the endpoint's bus type should be MIPI CSI-2 for CSI0 and parallel or
+Bt656 for CSI1.
+
+Endpoint node properties for CSI1
+-
+
+- remote-endpoint  : (required) a phandle to the bus receiver's endpoint
+  node
+- bus-width:   : (required) must be 8, 10, 12 or 16
+- pclk-sample  : (optional) (default: sample on falling edge)
+- hsync-active : (only required for parallel)
+- vsync-active : (only required for parallel)
+
+Example:
+
+csi1: csi@1cb4000 {
+   compatible = "allwinner,sun8i-v3s-csi";
+   reg = <0x01cb4000 0x1000>;
+   interrupts = ;
+   clocks = <&ccu CLK_BUS_CSI>,
+<&ccu CLK_CSI1_SCLK>,
+<&ccu CLK_DRAM_CSI>;
+   clock-names = "bus", "mod", "ram";
+   resets = <&ccu RST_BUS_CSI>;
+
+   port {
+   /* Parallel bus endpoint */
+   csi1_ep: endpoint {
+   remote-endpoint = <&adv7611_ep>;
+   bus-width = <16>;
+
+   /* If hsync-active/vsync-active are missing,
+  embedded BT.656 sync is used */
+   hsync-active = <0>; /* Active low */
+   vsync-active = <0>; /* Active low */
+   pclk-sample = <1>;  /* Rising */
+   };
+   };
+};
-- 
1.8.3.1

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH v8 0/2] Initial Allwinner V3s CSI Support

2018-02-26 Thread Yong Deng
This patchset add initial support for Allwinner V3s CSI.

Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
interface and CSI1 is used for parallel interface. This is not
documented in datasheet but by test and guess.

This patchset implement a v4l2 framework driver and add a binding 
documentation for it. 

Currently, the driver only support the parallel interface. And has been
tested with a BT1120 signal which generating from FPGA. The following
fetures are not support with this patchset:
  - ISP 
  - MIPI-CSI2
  - Master clock for camera sensor
  - Power regulator for the front end IC

Changes in v8:
  * Revert to v6 and add 'hack' for PHYS_OFFSET.

Changes in v7:
  * Add 'depends on ARM' in Kconfig to avoid built with non-ARM arch.

Changes in v6:
  * Add Rob Herring's review tag.
  * Fix a NULL pointer dereference by picking Maxime Ripard's patch.
  * Add Maxime Ripard's test tag.

Changes in v5:
  * Using the new SPDX tags.
  * Fix MODULE_LICENSE.
  * Add many default cases and warning messages.
  * Detail the parallel bus properties
  * Fix some spelling and syntax mistakes.

Changes in v4:
  * Deal with the CSI 'INNER QUEUE'.
CSI will lookup the next dma buffer for next frame before the
the current frame done IRQ triggered. This is not documented
but reported by Ondřej Jirman.
The BSP code has workaround for this too. It skip to mark the
first buffer as frame done for VB2 and pass the second buffer
to CSI in the first frame done ISR call. Then in second frame
done ISR call, it mark the first buffer as frame done for VB2
and pass the third buffer to CSI. And so on. The bad thing is
that the first buffer will be written twice and the first frame
is dropped even the queued buffer is sufficient.
So, I make some improvement here. Pass the next buffer to CSI
just follow starting the CSI. In this case, the first frame
will be stored in first buffer, second frame in second buffer.
This mothed is used to avoid dropping the first frame, it
would also drop frame when lacking of queued buffer.
  * Fix: using a wrong mbus_code when getting the supported formats
  * Change all fourcc to pixformat
  * Change some function names

Changes in v3:
  * Get rid of struct sun6i_csi_ops
  * Move sun6i-csi to new directory drivers/media/platform/sunxi
  * Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
  * Use generic fwnode endpoints parser
  * Only support a single subdev to make things simple
  * Many complaintion fix

Changes in v2: 
  * Change sunxi-csi to sun6i-csi
  * Rebase to media_tree master branch 

Following is the 'v4l2-compliance -s -f' output, I have test this
with both interlaced and progressive signal:

# ./v4l2-compliance -s -f
v4l2-compliance SHA   : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1

Driver Info:
Driver name   : sun6i-video
Card type : sun6i-csi
Bus info  : platform:csi
Driver version: 4.15.0
Capabilities  : 0x8421
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0421
Video Capture
Streaming
Extended Pix Format

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

Required ioctls:
test VIDIOC_QUERYCAP: OK

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

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

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

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

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

Test input 0:

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK

[linux-sunxi] Re: [PATCH v7 2/2] media: V3s: Add support for Allwinner CSI.

2018-02-26 Thread Yong
Hi,

On Mon, 26 Feb 2018 12:06:37 +0100
Hans Verkuil  wrote:

> Hi all,
> 
> On 01/30/2018 03:48 AM, Yong wrote:
> > Hi,
> > 
> > On Mon, 29 Jan 2018 13:49:14 -0800
> > Randy Dunlap  wrote:
> > 
> >> On 01/29/2018 01:21 AM, Yong Deng wrote:
> >>> Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
> >>> interface and CSI1 is used for parallel interface. This is not
> >>> documented in datasheet but by test and guess.
> >>>
> >>> This patch implement a v4l2 framework driver for it.
> >>>
> >>> Currently, the driver only support the parallel interface. MIPI-CSI2,
> >>> ISP's support are not included in this patch.
> >>>
> >>> Tested-by: Maxime Ripard 
> >>> Signed-off-by: Yong Deng 
> >>> ---
> >>
> >>
> >> A previous version (I think v6) had a build error with the use of
> >> PHYS_OFFSET, so Kconfig was modified to depend on ARM and ARCH_SUNXI
> >> (one of which seems to be overkill).  As is here, the COMPILE_TEST piece is
> >> meaningless for all arches except ARM.  If you care enough for COMPILE_TEST
> >> (and I would), then you could make COMPILE_TEST useful on any arch by
> >> removing the "depends on ARM" (the ARCH_SUNXI takes care of that) and by
> >> having an alternate value for PHYS_OFFSET, like so:
> >>
> >> +#if defined(CONFIG_COMPILE_TEST) && !defined(PHYS_OFFSET)
> >> +#define PHYS_OFFSET   0
> >> +#endif
> >>
> >> With those 2 changes, the driver builds for me on x86_64.
> > 
> > I have considered this method.
> > But it's so sick to put these code in dirver (for my own). I mean 
> > this is meaningless for the driver itself and make people confused.
> > 
> > I grepped the driver/ code and I found many drivers writing Kconfig
> > like this. For example:
> > ARM && COMPILE_TEST
> > MIPS && COMPILE_TEST
> > PPC64 && COMPILE_TEST
> > 
> > BTW, for my own, I do not care about COMPILE_TEST.
> 
> There was a discussion about this in the v6 patch, but it petered out.
> 
> I want to merge this driver, but I would very much prefer that this
> compiles with COMPILE_TEST. So unless someone has a better solution, then
> adding 'hack' that defines PHYS_OFFSET to 0 for COMPILE_TEST would be 
> required.

If so, I will take the advice of Randy.

> 
> Otherwise this driver looks good, so it is just this issue blocking it.
> 
> Regards,
> 
>   Hans
> 
> > 
> >>
> >>> diff --git a/drivers/media/platform/sunxi/sun6i-csi/Kconfig 
> >>> b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
> >>> new file mode 100644
> >>> index 000..f80c965
> >>> --- /dev/null
> >>> +++ b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
> >>> @@ -0,0 +1,10 @@
> >>> +config VIDEO_SUN6I_CSI
> >>> + tristate "Allwinner V3s Camera Sensor Interface driver"
> >>> + depends on ARM
> >>> + depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
> >>> + depends on ARCH_SUNXI || COMPILE_TEST
> >>> + select VIDEOBUF2_DMA_CONTIG
> >>> + select REGMAP_MMIO
> >>> + select V4L2_FWNODE
> >>> + ---help---
> >>> +Support for the Allwinner Camera Sensor Interface Controller on V3s.
> >>
> >> thanks,
> >> -- 
> >> ~Randy
> > 
> > 
> > Thanks,
> > Yong
> > 


Thanks,
Yong

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [RFC PATCH] ARM: configs: sunxi: Set ondemand govenor as default

2018-02-26 Thread Philipp Rossak



On 19.02.2018 09:10, Maxime Ripard wrote:

On Sat, Feb 17, 2018 at 03:22:35PM +0100, Philipp Rossak wrote:

Right now the performance govenor is the default frequency govenor on
sunxi devices. This causes some general problems.
When the cpu is idle the cpu runs with its maximum frequency.
This causes a higher cpu temperature in the idle state. When the cpu is
now under load the cpu gets with that higher idle temperature now faster
to its thermal limits.
An other big problem of the performace govenor is the missing
thermal throttling. Some tests with cpuburn resulted in a system crash
when the soc reached its thermal limits since no thermal throttling
occurred.


This won't change anything with cpuburn. While cpuburn will be
running, ondemand will increase the frequency of the cores to the
maximum frequency, putting yourself in the exact same situation.


I see here a totally different behavior on the hardware (Bananapi M2, A31s).
First ondemand increases the cpu frequency, when the maximum temperature 
is reached, then it throttles down the cpu step by step to its minimum.

And the cpu doesn't get killed, like with the performance govenor.

I can record some "logs" with RPi-Monitor if this is requiered.


The only difference is going to be when you're idle or have a rather
small CPU load. But then, you won't heat much in that case either.


With this patch we set the default frequency govenor to ondemand mode
and reduce the temperature when the cpu is idle and activate the thermal
throtteling.


This patch doesn't activate the thermal throttling.

Maxime



Sorry for my late reply!
Philipp

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] [PATCH v4] rtc: ac100: Fix ac100 determine rate bug

2018-02-26 Thread Philipp Rossak
This patch fixes a bug, that prevents the Allwinner A83T and the A80
from a successful boot.

The bug is there since v4.16-rc1 and appeared after the clk branch was
merged.

You can find the shortend trace below:

Unable to handle kernel NULL pointer dereference at virtual address

pgd = (ptrval)
[] *pgd=
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 49 Comm: kworker/0:1 Not tainted 4.15.0-10190-gb89e32ccd1be #2
Hardware name: Allwinner sun8i Family
Workqueue: events deferred_probe_work_func
PC is at clk_hw_get_rate+0x0/0x34
LR is at ac100_clkout_determine_rate+0x48/0x19c

[ ... ]

(clk_hw_get_rate) from (ac100_clkout_determine_rate+0x48/0x19c)
(ac100_clkout_determine_rate) from  (clk_core_set_rate_nolock+0x3c/0x1a0)
(clk_core_set_rate_nolock) from (clk_set_rate+0x30/0x88)
(clk_set_rate) from (of_clk_set_defaults+0x200/0x364)
(of_clk_set_defaults) from (platform_drv_probe+0x18/0xb0)

To fix that bug, we first check if the return of the
clk_hw_get_parent_by_index is non zero. If it is zero we skip that
clock parent.

The BUG report could be found here: https://lkml.org/lkml/2018/2/10/198

Fixes: 04940631b8d2 ("rtc: ac100: Add clk output support")

Signed-off-by: Philipp Rossak 
---

Changes in v4:
* add more information to the comment
Changes in v3:
* add information when the bug appeared 
* make the comment more clear
Changes in v2:
* add tag Fixes: ... to commit message
* add comment to if statement why we are doing this check

 drivers/rtc/rtc-ac100.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-ac100.c b/drivers/rtc/rtc-ac100.c
index 8ff9dc3fe5bf..08ca8c46a8ff 100644
--- a/drivers/rtc/rtc-ac100.c
+++ b/drivers/rtc/rtc-ac100.c
@@ -183,7 +183,29 @@ static int ac100_clkout_determine_rate(struct clk_hw *hw,
 
for (i = 0; i < num_parents; i++) {
struct clk_hw *parent = clk_hw_get_parent_by_index(hw, i);
-   unsigned long tmp, prate = clk_hw_get_rate(parent);
+   unsigned long tmp, prate;
+
+   /*
+* The clock has two parents, one is a fixed clock which is
+* internally registered by the ac100 driver. The other parent
+* is a clock from the codec side of the chip, which we
+* properly declare and reference in the devicetree and is
+* not implemented in any driver right now.
+* If the clock core looks for the parent of that second
+* missing clock, it can't find one that is registered and
+* returns NULL.
+* So we end up in a situation where clk_hw_get_num_parents
+* returns the amount of clocks we can be parented to, but
+* clk_hw_get_parent_by_index will not return the orphan
+* clocks.
+* Thus we need to check if the parent exists before
+* we get the parent rate, so we could use the RTC
+* without waiting for the codec to be supported.
+*/
+   if (!parent)
+   continue;
+
+   prate = clk_hw_get_rate(parent);
 
tmp = ac100_clkout_round_rate(hw, req->rate, prate);
 
-- 
2.11.0

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [linux-sunxi] [PATCH 14/15] ARM: dts: sun8i: h3: Enable HDMI output on H3 boards

2018-02-26 Thread Jernej Škrabec
Hi,

Dne ponedeljek, 26. februar 2018 ob 17:21:05 CET je Icenowy Zheng napisal(a):
> 于 2018年2月27日 GMT+08:00 上午12:16:44, "Jernej Škrabec" 
 写到:
> >Hi Julian,
> >
> >Dne nedelja, 25. februar 2018 ob 09:11:34 CET je Julian Calaby
> >
> >napisal(a):
> >> Hi Jernej,
> >> 
> >> On Sun, Feb 25, 2018 at 8:45 AM, Jernej Skrabec
> >
> >
> >
> >wrote:
> >> > Enable HDMI output on all boards which have HDMI connector.
> >> > 
> >> > Signed-off-by: Jernej Skrabec 
> >> > ---
> >> > 
> >> >  arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 25
> >> >  ++ arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
> >> >  
> >> >   | 25 ++
> >> >  
> >> >  arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 25
> >> >  ++ arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
> >> >  
> >> >   | 25 ++
> >
> >arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
> >
> >> > | 25 ++
> >> >  
> >> >  arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts   | 25
> >> >  ++ arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> >> >  
> >> >   | 24 +
> >
> >arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
> >
> >> >| 25 ++ 8 files changed, 199
> >
> >insertions(+)
> >
> >> As I understand it, the H2+ is just a slightly trimmed down H3. In
> >> terms of HDMI support, the difference is that the H2+ can't output
> >
> >4k.
> >
> >> If this code is compatible with the H2+, could you please add the
> >> necessary bits and pieces to the h2-plus DTSs too?
> >
> >There are only 3 H2+ boards in kernel and none of them has HDMI
> >connector, so
> 
> BPi M2 Zero has miniHDMI connector.

Ah, sorry, I missed that one. Since I don't have it (or any other board with 
H2+) I'm not really comfortable including such patch. If anyone will test it, 
I can include it in next revision.

Best regards,
Jernej

> 
> >there's nothing to do actually. But if such board is added to kernel,
> >it would
> >be trivially add proper nodes, since all H2+ boards include H3 DTSI.
> >
> >Best regards,
> >Jernej
> 
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group. To unsubscribe from this group and stop receiving
> emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.




-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 11/15] drm/sun4i: Add support for H3 HDMI PHY variant

2018-02-26 Thread Jernej Škrabec
Hi all,

Dne sobota, 24. februar 2018 ob 22:45:41 CET je Jernej Skrabec napisal(a):
> While A83T HDMI PHY seems to be just customized Synopsys HDMI PHY, H3
> HDMI PHY is completely custom PHY.
> 
> However, they still have many things in common like clock and reset
> setup, setting sync polarity and more.
> 
> Add support for H3 HDMI PHY variant.
> 
> While documentation exists for this PHY variant, it doesn't go in great
> details. Because of that, almost all settings are copied from BSP linux
> 4.4. Interestingly, those settings are slightly different to those found
> in a older BSP with Linux 3.4. For now, no user visible difference was
> found between them.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/gpu/drm/sun4i/Makefile |   1 +
>  drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h  |   6 +
>  drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 263
> - drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c |
> 130 ++
>  4 files changed, 397 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
> 
[...]
> diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
> b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c new file mode 100644
> index ..3c34ec5ff4af
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
> @@ -0,0 +1,130 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018 Jernej Skrabec 
> + */
> +
> +#include 
> +
> +#include "sun8i_dw_hdmi.h"
> +
> +struct sun8i_phy_clk {
> + struct clk_hw   hw;
> + struct sun8i_hdmi_phy   *phy;
> +};
> +
> +static inline struct sun8i_phy_clk *hw_to_phy_clk(struct clk_hw *hw)
> +{
> + return container_of(hw, struct sun8i_phy_clk, hw);
> +}
> +
> +static int sun8i_phy_clk_determine_rate(struct clk_hw *hw,
> + struct clk_rate_request *req)
> +{
> + unsigned long rate = req->rate;
> + unsigned long best_rate = 0;
> + struct clk_hw *parent;
> + int best_div = 1;
> + int i;
> +
> + parent = clk_hw_get_parent(hw);
> +
> + for (i = 1; i <= 16; i++) {
> + unsigned long ideal = rate * i;
> + unsigned long rounded;
> +
> + rounded = clk_hw_round_rate(parent, ideal);
> +
> + if (rounded == ideal) {
> + best_rate = rounded;
> + best_div = i;
> + break;
> + }
> +
> + if (abs(rate - rounded) < abs(rate - best_rate / best_div)) {

Here is a bug. Above line should be:
if (abs(rate - rounded / i) < abs(rate - best_rate / best_div)) {

I guess this could solve the issue described in cover letter.

Best regards,
Jernej

> + best_rate = rounded;
> + best_div = i;
> + }
> + }
> +
> + req->rate = best_rate / best_div;
> + req->best_parent_rate = best_rate;
> + req->best_parent_hw = parent;
> +
> + return 0;
> +}
> +
> +static unsigned long sun8i_phy_clk_recalc_rate(struct clk_hw *hw,
> +unsigned long parent_rate)
> +{
> + struct sun8i_phy_clk *priv = hw_to_phy_clk(hw);
> + u32 reg;
> +
> + regmap_read(priv->phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG, ®);
> + reg = ((reg >> SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_SHIFT) &
> + SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK) + 1;
> +
> + return parent_rate / reg;
> +}
> +
> +static int sun8i_phy_clk_set_rate(struct clk_hw *hw, unsigned long rate,
> +   unsigned long parent_rate)
> +{
> + struct sun8i_phy_clk *priv = hw_to_phy_clk(hw);
> + unsigned long best_rate = 0;
> + u8 best_m = 0, m;
> +
> + for (m = 1; m <= 16; m++) {
> + unsigned long tmp_rate = parent_rate / m;
> +
> + if (tmp_rate > rate)
> + continue;
> +
> + if (!best_rate ||
> + (rate - tmp_rate) < (rate - best_rate)) {
> + best_rate = tmp_rate;
> + best_m = m;
> + }
> + }
> +
> + regmap_update_bits(priv->phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG,
> +SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK,
> +SUN8I_HDMI_PHY_PLL_CFG2_PREDIV(best_m));
> +
> + return 0;
> +}
> +
> +static const struct clk_ops sun8i_phy_clk_ops = {
> + .determine_rate = sun8i_phy_clk_determine_rate,
> + .recalc_rate= sun8i_phy_clk_recalc_rate,
> + .set_rate   = sun8i_phy_clk_set_rate,
> +};
> +
> +int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev)
> +{
> + struct clk_init_data init;
> + struct sun8i_phy_clk *priv;
> + const char *parents[1];
> +
> + parents[0] = __clk_get_name(phy->clk_pll0);
> + if (!parents[0])
> + return -ENODEV;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + init.name = "hdmi-p

Re: [linux-sunxi] [PATCH 14/15] ARM: dts: sun8i: h3: Enable HDMI output on H3 boards

2018-02-26 Thread Icenowy Zheng


于 2018年2月27日 GMT+08:00 上午12:16:44, "Jernej Škrabec"  
写到:
>Hi Julian,
>
>Dne nedelja, 25. februar 2018 ob 09:11:34 CET je Julian Calaby
>napisal(a):
>> Hi Jernej,
>> 
>> On Sun, Feb 25, 2018 at 8:45 AM, Jernej Skrabec
> 
>wrote:
>> > Enable HDMI output on all boards which have HDMI connector.
>> > 
>> > Signed-off-by: Jernej Skrabec 
>> > ---
>> > 
>> >  arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 25
>> >  ++ arch/arm/boot/dts/sun8i-h3-beelink-x2.dts  
> 
>> >   | 25 ++
>> >  arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 25
>> >  ++ arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts   
> 
>> >   | 25 ++
>arch/arm/boot/dts/sun8i-h3-orangepi-2.dts  
>> > | 25 ++
>> >  arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts   | 25
>> >  ++ arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> 
>> >   | 24 +
>arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts  
>> >| 25 ++ 8 files changed, 199
>insertions(+)
>> 
>> As I understand it, the H2+ is just a slightly trimmed down H3. In
>> terms of HDMI support, the difference is that the H2+ can't output
>4k.
>> If this code is compatible with the H2+, could you please add the
>> necessary bits and pieces to the h2-plus DTSs too?
>
>There are only 3 H2+ boards in kernel and none of them has HDMI
>connector, so 

BPi M2 Zero has miniHDMI connector.

>there's nothing to do actually. But if such board is added to kernel,
>it would 
>be trivially add proper nodes, since all H2+ boards include H3 DTSI.
>
>Best regards,
>Jernej

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 08/15] drm/sun4i: Fix polarity configuration for DW HDMI PHY

2018-02-26 Thread Jernej Škrabec
Hi,

Dne ponedeljek, 26. februar 2018 ob 10:39:30 CET je Maxime Ripard napisal(a):
> Hi,
> 
> On Sat, Feb 24, 2018 at 10:45:38PM +0100, Jernej Skrabec wrote:
> > Current polarity configuration code is cleary wrong since it compares
> > same flag two times. However, even if flag name is fixed, it won't work
> > well for resolutions which have one polarity positive and another
> > negative.
> > 
> > Fix that by properly set each bit according to each polarity. Since
> > those two bits are not described in any documentation, relationships
> > were obtained by experimentation.
> > 
> > Fixes: b7c7436a5ff0 ("drm/sun4i: Implement A83T HDMI driver")
> > 
> > Signed-off-by: Jernej Skrabec 
> > ---
> > 
> >  drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 9 +
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> > b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c index e5bfcdd43ec9..f48e8b70fabe
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> > @@ -35,10 +35,11 @@ static int sun8i_hdmi_phy_config(struct dw_hdmi *hdmi,
> > void *data,> 
> > struct sun8i_hdmi_phy *phy = (struct sun8i_hdmi_phy *)data;
> > u32 val = 0;
> > 
> > -   if ((mode->flags & DRM_MODE_FLAG_NHSYNC) &&
> > -   (mode->flags & DRM_MODE_FLAG_NHSYNC)) {
> > -   val = 0x03;
> > -   }
> > +   if (mode->flags & DRM_MODE_FLAG_NHSYNC)
> > +   val |= 0x01;
> > +
> > +   if (mode->flags & DRM_MODE_FLAG_NVSYNC)
> > +   val |= 0x02;
> 
> Can you introduce defines for those?

Of course.

Best regards,
Jernej



-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 01/15] clk: sunxi-ng: Add check for minimal rate to NM PLLs

2018-02-26 Thread Jernej Škrabec
Hi,

Dne ponedeljek, 26. februar 2018 ob 10:38:00 CET je Maxime Ripard napisal(a):
> Hi,
> 
> On Sat, Feb 24, 2018 at 10:45:31PM +0100, Jernej Skrabec wrote:
> > Some NM PLLs doesn't work well when their output clock rate is set below
> > certain rate.
> > 
> > Add support for that constrain.
> 
> In such a case, you should round the rate to the minimum the clock can
> operate at, and not return an error.

OK.

Best regards,
Jernej


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [linux-sunxi] [PATCH 14/15] ARM: dts: sun8i: h3: Enable HDMI output on H3 boards

2018-02-26 Thread Jernej Škrabec
Hi Julian,

Dne nedelja, 25. februar 2018 ob 09:11:34 CET je Julian Calaby napisal(a):
> Hi Jernej,
> 
> On Sun, Feb 25, 2018 at 8:45 AM, Jernej Skrabec  
wrote:
> > Enable HDMI output on all boards which have HDMI connector.
> > 
> > Signed-off-by: Jernej Skrabec 
> > ---
> > 
> >  arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts| 25
> >  ++ arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
> >   | 25 ++
> >  arch/arm/boot/dts/sun8i-h3-libretech-all-h3-cc.dts | 25
> >  ++ arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts 
> >   | 25 ++ arch/arm/boot/dts/sun8i-h3-orangepi-2.dts  
> > | 25 ++
> >  arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts   | 25
> >  ++ arch/arm/boot/dts/sun8i-h3-orangepi-one.dts  
> >   | 24 + arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts  
> >| 25 ++ 8 files changed, 199 insertions(+)
> 
> As I understand it, the H2+ is just a slightly trimmed down H3. In
> terms of HDMI support, the difference is that the H2+ can't output 4k.
> If this code is compatible with the H2+, could you please add the
> necessary bits and pieces to the h2-plus DTSs too?

There are only 3 H2+ boards in kernel and none of them has HDMI connector, so 
there's nothing to do actually. But if such board is added to kernel, it would 
be trivially add proper nodes, since all H2+ boards include H3 DTSI.

Best regards,
Jernej


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH v3 6/7] arm64: allwinner: h6: add the basical Allwinner H6 DTSI file

2018-02-26 Thread Samuel Holland
On 02/26/18 03:26, Maxime Ripard wrote:
> On Fri, Feb 23, 2018 at 11:22:06PM +0800, Icenowy Zheng wrote:
 +  psci {
 +  compatible = "arm,psci-0.2";
 +  method = "smc";
 +  };
>>>
>>> Is it needed? The bootloader should fill it with whatever version it
>>> has, shouldn't it?
>>
>> But we now use ATF rather than U-Boot PSCI. U-Boot will not fill ATF
>> info.
>>
>> See A64/H5 device trees.
> 
> So if the PSCI version implemented in ATF ever changes, we would have
> to update all the DT everywhere, but only if you're running the new
> version?

Yes but no. PSCI 1.0 is generally backward compatible with PSCI 0.2. In fact,
the Linux driver treats them exactly the same:

{ .compatible = "arm,psci-0.2", .data = psci_0_2_init},
{ .compatible = "arm,psci-1.0", .data = psci_0_2_init},

For the H6, however, the oldest ATF source available (which I believe was the
one in use during bringup) is based on mainline 1.4, and is already at PSCI
version 1.1:

[0.00] psci: probing for conduit method from DT.
[0.00] psci: PSCIv1.1 detected in firmware.
[0.00] psci: Using standard PSCI v0.2 function IDs
[0.00] psci: MIGRATE_INFO_TYPE not supported.

So we could go ahead and bump the compatible to "arm,psci-1.0".

Thanks,
Samuel

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Kernel Crashes when it connected to Windows OS

2018-02-26 Thread Mustafa thamer
Hi there, 

currently I am using Olimex A20-LIME2 board with the OLinuXino-A20 Linux 
and kernel version 3.4.103-00033-g9a1cd03-dirty . I wanted to emulate my 
board as a Keyboard when it connect to a HOST PC and to do so I followed 
theses  instruction here to pass platform_device structure to the gadget 
driver :

https://www.kernel.org/doc/Documentation/usb/gadget_hid.txt


when I modprobe g_hid module my board works fine with Linux host PC but 
with Windows host PC my board kernel crashed . even  Windows couldn't find 
the right driver for my HID gadget .
any suggestion would be appreciated . Thanks

dmesg output > 


[ 207.682916] [sw_udc]: [sw_usb_udc]: binding gadget driver 'g_hid'
[ 207.687750] [sw_udc]: alloc request: ep(0xc07f5d58, ep0, 64), 
req(0xeea241c0)
[ 207.702464] [sw_udc]: alloc request: ep(0xc07f5da4, ep1-bulk, 64), 
req(0xee4f1f80)
[ 207.714056] g_hid gadget: HID Gadget, version: 2010/03/16
[ 207.722503] g_hid gadget: g_hid ready
[ 207.727062] [sw_udc]: usbd_start_work
[ 207.784889] [sw_udc]: IRQ: suspend
[ 207.787022] [sw_udc]: ERR: usb speed is unkown
[ 207.901021] [sw_udc]: IRQ: reset
[ 207.902980] [sw_udc]: irq: reset happen, throw away all urb
[ 207.991123] [sw_udc]:
[ 207.994713] +
[ 207.995604] [sw_udc]: usb enter full speed.
[ 207.998587] [sw_udc]:
[ 208.002161] +
[ 208.008129] retire_capture_urb: 43 callbacks suppressed
[ 208.014357] [sw_udc]: IRQ: reset
[ 208.016303] [sw_udc]: irq: reset happen, throw away all urb
[ 208.094947] [sw_udc]: Set address 24

// after start using the user space test 
application 
/

[ 422.287745] WRN:L2385(drivers/usb/sunxi_usb/udc/sw_udc.c):ERR: 
sw_udc_queue: inval 2
[ 422.295851] g_hid gadget: usb_ep_queue error on int endpoint 4294967274

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH v7 2/2] media: V3s: Add support for Allwinner CSI.

2018-02-26 Thread Hans Verkuil
Hi all,

On 01/30/2018 03:48 AM, Yong wrote:
> Hi,
> 
> On Mon, 29 Jan 2018 13:49:14 -0800
> Randy Dunlap  wrote:
> 
>> On 01/29/2018 01:21 AM, Yong Deng wrote:
>>> Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2
>>> interface and CSI1 is used for parallel interface. This is not
>>> documented in datasheet but by test and guess.
>>>
>>> This patch implement a v4l2 framework driver for it.
>>>
>>> Currently, the driver only support the parallel interface. MIPI-CSI2,
>>> ISP's support are not included in this patch.
>>>
>>> Tested-by: Maxime Ripard 
>>> Signed-off-by: Yong Deng 
>>> ---
>>
>>
>> A previous version (I think v6) had a build error with the use of
>> PHYS_OFFSET, so Kconfig was modified to depend on ARM and ARCH_SUNXI
>> (one of which seems to be overkill).  As is here, the COMPILE_TEST piece is
>> meaningless for all arches except ARM.  If you care enough for COMPILE_TEST
>> (and I would), then you could make COMPILE_TEST useful on any arch by
>> removing the "depends on ARM" (the ARCH_SUNXI takes care of that) and by
>> having an alternate value for PHYS_OFFSET, like so:
>>
>> +#if defined(CONFIG_COMPILE_TEST) && !defined(PHYS_OFFSET)
>> +#define PHYS_OFFSET 0
>> +#endif
>>
>> With those 2 changes, the driver builds for me on x86_64.
> 
> I have considered this method.
> But it's so sick to put these code in dirver (for my own). I mean 
> this is meaningless for the driver itself and make people confused.
> 
> I grepped the driver/ code and I found many drivers writing Kconfig
> like this. For example:
> ARM && COMPILE_TEST
> MIPS && COMPILE_TEST
> PPC64 && COMPILE_TEST
> 
> BTW, for my own, I do not care about COMPILE_TEST.

There was a discussion about this in the v6 patch, but it petered out.

I want to merge this driver, but I would very much prefer that this
compiles with COMPILE_TEST. So unless someone has a better solution, then
adding 'hack' that defines PHYS_OFFSET to 0 for COMPILE_TEST would be required.

Otherwise this driver looks good, so it is just this issue blocking it.

Regards,

Hans

> 
>>
>>> diff --git a/drivers/media/platform/sunxi/sun6i-csi/Kconfig 
>>> b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
>>> new file mode 100644
>>> index 000..f80c965
>>> --- /dev/null
>>> +++ b/drivers/media/platform/sunxi/sun6i-csi/Kconfig
>>> @@ -0,0 +1,10 @@
>>> +config VIDEO_SUN6I_CSI
>>> +   tristate "Allwinner V3s Camera Sensor Interface driver"
>>> +   depends on ARM
>>> +   depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
>>> +   depends on ARCH_SUNXI || COMPILE_TEST
>>> +   select VIDEOBUF2_DMA_CONTIG
>>> +   select REGMAP_MMIO
>>> +   select V4L2_FWNODE
>>> +   ---help---
>>> +  Support for the Allwinner Camera Sensor Interface Controller on V3s.
>>
>> thanks,
>> -- 
>> ~Randy
> 
> 
> Thanks,
> Yong
> 

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 01/15] clk: sunxi-ng: Add check for minimal rate to NM PLLs

2018-02-26 Thread Chen-Yu Tsai
On Mon, Feb 26, 2018 at 6:25 PM, Maxime Ripard
 wrote:
> On Mon, Feb 26, 2018 at 05:43:01PM +0800, Chen-Yu Tsai wrote:
>> On Mon, Feb 26, 2018 at 5:38 PM, Maxime Ripard
>>  wrote:
>> > Hi,
>> >
>> > On Sat, Feb 24, 2018 at 10:45:31PM +0100, Jernej Skrabec wrote:
>> >> Some NM PLLs doesn't work well when their output clock rate is set below
>> >> certain rate.
>> >>
>> >> Add support for that constrain.
>> >
>> > In such a case, you should round the rate to the minimum the clock can
>> > operate at, and not return an error.
>>
>> That's true for round_rate. But what's the expected behavior of set_rate?
>> AFAIK we presume all users call round_rate before set_rate, but that doesn't
>> seem to be true all the time.
>
> One of the first things that happens during a set_rate is a round_rate:
> https://elixir.bootlin.com/linux/v4.16-rc3/source/drivers/clk/clk.c#L1873

Ah! This was added recently in commit ca5e089a32c5 ("clk: use round rate
to bail out early in set_rate").

Thanks for the tip!
ChenYu

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[linux-sunxi] Re: [PATCH 01/15] clk: sunxi-ng: Add check for minimal rate to NM PLLs

2018-02-26 Thread Chen-Yu Tsai
On Mon, Feb 26, 2018 at 5:38 PM, Maxime Ripard
 wrote:
> Hi,
>
> On Sat, Feb 24, 2018 at 10:45:31PM +0100, Jernej Skrabec wrote:
>> Some NM PLLs doesn't work well when their output clock rate is set below
>> certain rate.
>>
>> Add support for that constrain.
>
> In such a case, you should round the rate to the minimum the clock can
> operate at, and not return an error.

That's true for round_rate. But what's the expected behavior of set_rate?
AFAIK we presume all users call round_rate before set_rate, but that doesn't
seem to be true all the time.

ChenYu

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.