Re: [PATCH 0/9] staging: vc04_services: Clean up vchiq driver

2017-01-13 Thread Greg Kroah-Hartman 
On Fri, Jan 13, 2017 at 10:16:32PM -0800, Eric Anholt wrote:
> Greg Kroah-Hartman  writes:
> 
> > On Sun, Jan 08, 2017 at 06:15:09PM +, Stefan Wahren wrote:
> >> This is a loose bunch of clean up patches for the bcm2835 vchiq driver.
> >
> > All now applied, thanks.
> 
> Thanks!  I've been off on vacation and wasn't reviewing anything.
> 
> In general, do you want to see R-Bs from me before applying?  I was
> assuming you did, but I can prioritize reviewing other code if you don't
> need my reviews for vchi.

I'll gladly take them, but if you are busy with other things, don't
worry about it, I'll review them on my own when I go through the stable
patch queue (happens every week or so.)

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/9] staging: vc04_services: Clean up vchiq driver

2017-01-13 Thread Eric Anholt 
Greg Kroah-Hartman  writes:

> On Sun, Jan 08, 2017 at 06:15:09PM +, Stefan Wahren wrote:
>> This is a loose bunch of clean up patches for the bcm2835 vchiq driver.
>
> All now applied, thanks.

Thanks!  I've been off on vacation and wasn't reviewing anything.

In general, do you want to see R-Bs from me before applying?  I was
assuming you did, but I can prioritize reviewing other code if you don't
need my reviews for vchi.


signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 15/24] media: Add userspace header file for i.MX

2017-01-13 Thread Steve Longerbeam 



On 01/13/2017 04:05 AM, Philipp Zabel wrote:

Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:

This adds a header file for use by userspace programs wanting to interact
with the i.MX media driver. It defines custom v4l2 controls and events
generated by the i.MX v4l2 subdevices.

Signed-off-by: Steve Longerbeam 
---
  include/uapi/media/Kbuild |  1 +
  include/uapi/media/imx.h  | 30 ++
  2 files changed, 31 insertions(+)
  create mode 100644 include/uapi/media/imx.h

diff --git a/include/uapi/media/Kbuild b/include/uapi/media/Kbuild
index aafaa5a..fa78958 100644
--- a/include/uapi/media/Kbuild
+++ b/include/uapi/media/Kbuild
@@ -1 +1,2 @@
  # UAPI Header export list
+header-y += imx.h
diff --git a/include/uapi/media/imx.h b/include/uapi/media/imx.h
new file mode 100644
index 000..2421d9c
--- /dev/null
+++ b/include/uapi/media/imx.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright (c) 2014-2015 Mentor Graphics Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version
+ */
+
+#ifndef __UAPI_MEDIA_IMX_H__
+#define __UAPI_MEDIA_IMX_H__
+
+/*
+ * events from the subdevs
+ */
+#define V4L2_EVENT_IMX_CLASS  V4L2_EVENT_PRIVATE_START
+#define V4L2_EVENT_IMX_NFB4EOF(V4L2_EVENT_IMX_CLASS + 1)
+#define V4L2_EVENT_IMX_EOF_TIMEOUT(V4L2_EVENT_IMX_CLASS + 2)
+#define V4L2_EVENT_IMX_FRAME_INTERVAL (V4L2_EVENT_IMX_CLASS + 3)

Aren't these generic enough to warrant common events? I would think
there have to be other capture IP cores that can signal aborted frames
or frame timeouts.


Yes, agreed. A frame capture timeout, or frame interval error, are
both generic concepts. At some point it would be great to make the
Frame Interval Monitor generally available under v4l2-core. As for the
EOF timeout event, I'll look into moving that into a generic V4L2 event.

Steve


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 06/24] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

2017-01-13 Thread Steve Longerbeam 



On 01/13/2017 04:03 AM, Philipp Zabel wrote:

Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:

Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
Both hang off the same i2c2 bus, so they require different (and non-
default) i2c slave addresses.

The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.

The OV5640 connects to the input port on the MIPI CSI-2 receiver on
mipi_csi. It is set to transmit over MIPI virtual channel 1.

Signed-off-by: Steve Longerbeam 
---
  arch/arm/boot/dts/imx6dl-sabrelite.dts   |   5 ++
  arch/arm/boot/dts/imx6q-sabrelite.dts|   6 ++
  arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 118 +++
  3 files changed, 129 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl-sabrelite.dts 
b/arch/arm/boot/dts/imx6dl-sabrelite.dts
index 0f06ca5..fec2524 100644
--- a/arch/arm/boot/dts/imx6dl-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6dl-sabrelite.dts
@@ -48,3 +48,8 @@
model = "Freescale i.MX6 DualLite SABRE Lite Board";
compatible = "fsl,imx6dl-sabrelite", "fsl,imx6dl";
  };
+
+_csi1_from_ipu1_csi1_mux {
+   data-lanes = <0 1>;
+   clock-lanes = <2>;
+};
diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts 
b/arch/arm/boot/dts/imx6q-sabrelite.dts
index 66d10d8..9e2d26d 100644
--- a/arch/arm/boot/dts/imx6q-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
@@ -52,3 +52,9 @@
   {
status = "okay";
  };
+
+_csi1_from_mipi_vc1 {
+   data-lanes = <0 1>;
+   clock-lanes = <2>;
+};
+
diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
index 795b5a5..bca9fed 100644
--- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
@@ -39,6 +39,8 @@
   * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
   * OTHER DEALINGS IN THE SOFTWARE.
   */
+
+#include 
  #include 
  #include 
  
@@ -96,6 +98,15 @@

};
};
  
+	mipi_xclk: mipi_xclk {

+   compatible = "pwm-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2200>;
+   clock-output-names = "mipi_pwm3";
+   pwms = < 0 45>; /* 1 / 45 ns = 22 MHz */
+   status = "okay";
+   };
+
gpio-keys {
compatible = "gpio-keys";
pinctrl-names = "default";
@@ -220,6 +231,22 @@
};
  };
  
+_csi0_from_ipu1_csi0_mux {

+   bus-width = <8>;
+   data-shift = <12>; /* Lines 19:12 used */
+   hsync-active = <1>;
+   vync-active = <1>;
+};
+
+_csi0_mux_from_parallel_sensor {
+   remote-endpoint = <_to_ipu1_csi0_mux>;
+};
+
+_csi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ipu1_csi0>;
+};
+
   {
pinctrl-names = "default";
pinctrl-0 = <_audmux>;
@@ -299,6 +326,52 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c2>;
status = "okay";
+
+   ov5640: camera@40 {
+   compatible = "ovti,ov5640";
+   pinctrl-names = "default";
+   pinctrl-0 = <_ov5640>;
+   clocks = <_xclk>;
+   clock-names = "xclk";
+   reg = <0x40>;
+   xclk = <2200>;

This is superfluous, you can use clk_get_rate on mipi_xclk.


This property is actually there to tell the driver what to set the
rate to, with clk_set_rate(). So you are saying it would be better
to set the rate in the device tree and the driver should only
retrieve the rate?

Steve

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 02/24] ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node

2017-01-13 Thread Steve Longerbeam 



On 01/13/2017 03:57 AM, Philipp Zabel wrote:

Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:

Add to the MIPI CSI2 receiver node: compatible string, interrupt sources,
clocks.

Signed-off-by: Steve Longerbeam 
---
  arch/arm/boot/dts/imx6qdl.dtsi | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 53e6e63..42926e9 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1125,7 +1125,14 @@
};
  
  			mipi_csi: mipi@021dc000 {

+   compatible = "fsl,imx6-mipi-csi2";
reg = <0x021dc000 0x4000>;
+   interrupts = <0 100 0x04>, <0 101 0x04>;
+   clocks = < IMX6QDL_CLK_HSI_TX>,
+< IMX6QDL_CLK_VIDEO_27M>,
+< IMX6QDL_CLK_EIM_SEL>;

I think the latter should be EIM_PODF


done.




+   clock-names = "dphy", "cfg", "pix";

and I'm not sure dphy is the right name for this one. Is that the pll
ref input?


I believe this naming came from FSL's mipi csi-2 driver. It is the "hsi_tx"
clock (presumably for the MIPI HSI controller) whose parents are selected
by the CDCDR register as PLL3_120M or PLL2_PFD2. I have no clue whether
this is indeed also used as the clock for the MIPI CSI-2 D-PHY, but 
according

to FSL naming convention it might be.


Steve

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: greybus: fix checkpatch unsigned warnings

2017-01-13 Thread Roman Sommer 
Fix checkpatch warnings for parameter type unsigned in greybus.
Note that this patch does not fix all checkpatch warnings for the
affected files.

Signed-off-by: Christian Bewermeyer 
Signed-off-by: Roman Sommer 
---
 drivers/staging/greybus/gpio.c | 24 
 drivers/staging/greybus/loopback.c |  2 +-
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/greybus/gpio.c b/drivers/staging/greybus/gpio.c
index 250caa0..558550c 100644
--- a/drivers/staging/greybus/gpio.c
+++ b/drivers/staging/greybus/gpio.c
@@ -410,21 +410,21 @@ static int gb_gpio_request_handler(struct gb_operation 
*op)
return 0;
 }
 
-static int gb_gpio_request(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_request(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
return gb_gpio_activate_operation(ggc, (u8)offset);
 }
 
-static void gb_gpio_free(struct gpio_chip *chip, unsigned offset)
+static void gb_gpio_free(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
gb_gpio_deactivate_operation(ggc, (u8)offset);
 }
 
-static int gb_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_get_direction(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
u8 which;
@@ -438,22 +438,22 @@ static int gb_gpio_get_direction(struct gpio_chip *chip, 
unsigned offset)
return ggc->lines[which].direction ? 1 : 0;
 }
 
-static int gb_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_direction_input(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
return gb_gpio_direction_in_operation(ggc, (u8)offset);
 }
 
-static int gb_gpio_direction_output(struct gpio_chip *chip, unsigned offset,
-   int value)
+static int gb_gpio_direction_output(struct gpio_chip *chip, unsigned int 
offset,
+   int value)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
return gb_gpio_direction_out_operation(ggc, (u8)offset, !!value);
 }
 
-static int gb_gpio_get(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_get(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
u8 which;
@@ -467,15 +467,15 @@ static int gb_gpio_get(struct gpio_chip *chip, unsigned 
offset)
return ggc->lines[which].value;
 }
 
-static void gb_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
+static void gb_gpio_set(struct gpio_chip *chip, unsigned int offset, int value)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
gb_gpio_set_value_operation(ggc, (u8)offset, !!value);
 }
 
-static int gb_gpio_set_debounce(struct gpio_chip *chip, unsigned offset,
-   unsigned debounce)
+static int gb_gpio_set_debounce(struct gpio_chip *chip, unsigned int offset,
+   unsigned int debounce)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
u16 usec;
@@ -593,7 +593,7 @@ static int gb_gpio_irqchip_add(struct gpio_chip *chip,
 {
struct gb_gpio_controller *ggc;
unsigned int offset;
-   unsigned irq_base;
+   unsigned int irq_base;
 
if (!chip || !irqchip)
return -EINVAL;
@@ -625,7 +625,7 @@ static int gb_gpio_irqchip_add(struct gpio_chip *chip,
return 0;
 }
 
-static int gb_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
+static int gb_gpio_to_irq(struct gpio_chip *chip, unsigned int offset)
 {
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
 
diff --git a/drivers/staging/greybus/loopback.c 
b/drivers/staging/greybus/loopback.c
index 7882306..3ad8c64 100644
--- a/drivers/staging/greybus/loopback.c
+++ b/drivers/staging/greybus/loopback.c
@@ -124,7 +124,7 @@ static DEFINE_IDA(loopback_ida);
 
 #define GB_LOOPBACK_FIFO_DEFAULT   8192
 
-static unsigned kfifo_depth = GB_LOOPBACK_FIFO_DEFAULT;
+static unsigned int kfifo_depth = GB_LOOPBACK_FIFO_DEFAULT;
 module_param(kfifo_depth, uint, 0444);
 
 /* Maximum size of any one send data buffer we support */
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

pull-request: vmbus 2017-01-13

2017-01-13 Thread Stephen Hemminger 
Here is an update with cleanups based on recent changes.

The following changes since commit b0f2d7d546d37697d3f50753904f6f0c549b62bc:

  VME: Remove node entry from vme_driver (2017-01-11 09:21:41 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/vmbus-next 

for you to fetch changes up to c9483ca4fe3b796ff9c1c2d6cc772756b8195fc5:

  vmbus: remove per channel state (2017-01-13 10:18:37 -0800)


Stephen Hemminger (14):
  vmbus: remove useless return's
  vmbus: constify parameters where possible
  vmbus: use kernel bitops for traversing interrupt mask
  vmbus: fix send interrupt for 64 bit
  vmbus: eliminate unnecessary wrapper functions
  vmbus: drop no longer used kick_q argument
  vmbus: remove no longer used signal_policy
  vmbus: remove conditional locking of vmbus_write
  vmbus: remove unused kickq argument to sendpacket
  vmbus: remove unnecessary initialization
  vmbus: remove unused VMBUS_SERVICE_ID
  vmbus: fix spelling errors
  netvsc: remove no longer needed receive staging buffers
  vmbus: remove per channel state

 drivers/hv/channel.c  |  55 +++-
 drivers/hv/channel_mgmt.c |   1 -
 drivers/hv/connection.c   |  62 +--
 drivers/hv/hv_balloon.c   |   2 -
 drivers/hv/hv_fcopy.c |   2 -
 drivers/hv/hv_kvp.c   |  12 ++---
 drivers/hv/hv_snapshot.c  |   2 -
 drivers/hv/hyperv_vmbus.h |  37 +-
 drivers/hv/ring_buffer.c  |  93 ++
 drivers/hv/vmbus_drv.c|   6 +--
 drivers/net/hyperv/hyperv_net.h   |   5 --
 drivers/net/hyperv/netvsc.c   | 104 +-
 drivers/net/hyperv/rndis_filter.c |  11 
 include/linux/hyperv.h|  67 +++-
 14 files changed, 109 insertions(+), 350 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index be34547cdb68..a3c2289af9c3 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -47,12 +47,8 @@ void vmbus_setevent(struct vmbus_channel *channel)
 * For channels marked as in "low latency" mode
 * bypass the monitor page mechanism.
 */
-   if ((channel->offermsg.monitor_allocated) &&
-   (!channel->low_latency)) {
-   /* Each u32 represents 32 channels */
-   sync_set_bit(channel->offermsg.child_relid & 31,
-   (unsigned long *) vmbus_connection.send_int_page +
-   (channel->offermsg.child_relid >> 5));
+   if (channel->offermsg.monitor_allocated && !channel->low_latency) {
+   vmbus_send_interrupt(channel->offermsg.child_relid);
 
/* Get the child to parent monitor page */
monitorpage = vmbus_connection.monitor_pages[1];
@@ -337,7 +333,7 @@ static int create_gpadl_header(void *kbuffer, u32 size,
 * Gpadl is u32 and we are using a pointer which could
 * be 64-bit
 * This is governed by the guest/host protocol and
-* so the hypervisor gurantees that this is ok.
+* so the hypervisor guarantees that this is ok.
 */
for (i = 0; i < pfncurr; i++)
gpadl_body->pfn[i] = slow_virt_to_phys(
@@ -384,7 +380,7 @@ static int create_gpadl_header(void *kbuffer, u32 size,
 }
 
 /*
- * vmbus_establish_gpadl - Estabish a GPADL for the specified buffer
+ * vmbus_establish_gpadl - Establish a GPADL for the specified buffer
  *
  * @channel: a channel
  * @kbuffer: from kmalloc or vmalloc
@@ -547,7 +543,7 @@ static int vmbus_close_internal(struct vmbus_channel 
*channel)
/*
 * In case a device driver's probe() fails (e.g.,
 * util_probe() -> vmbus_open() returns -ENOMEM) and the device is
-* rescinded later (e.g., we dynamically disble an Integrated Service
+* rescinded later (e.g., we dynamically disable an Integrated Service
 * in Hyper-V Manager), the driver's remove() invokes vmbus_close():
 * here we should skip most of the below cleanup work.
 */
@@ -647,15 +643,14 @@ void vmbus_close(struct vmbus_channel *channel)
 EXPORT_SYMBOL_GPL(vmbus_close);
 
 int vmbus_sendpacket_ctl(struct vmbus_channel *channel, void *buffer,
-  u32 bufferlen, u64 requestid,
-  enum vmbus_packet_type type, u32 flags, bool kick_q)
+u32 bufferlen, u64 requestid,
+enum vmbus_packet_type type, u32 flags)
 {
struct vmpacket_descriptor desc;
u32 packetlen = sizeof(struct vmpacket_descriptor) + bufferlen;
u32 packetlen_aligned = ALIGN(packetlen, sizeof(u64));

Re: [PATCH v3 01/24] [media] dt-bindings: Add bindings for i.MX media driver

2017-01-13 Thread Steve Longerbeam 



On 01/13/2017 03:55 AM, Philipp Zabel wrote:

Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:

Add bindings documentation for the i.MX media driver.

Signed-off-by: Steve Longerbeam 
---
  Documentation/devicetree/bindings/media/imx.txt | 57 +
  1 file changed, 57 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/media/imx.txt

diff --git a/Documentation/devicetree/bindings/media/imx.txt 
b/Documentation/devicetree/bindings/media/imx.txt
new file mode 100644
index 000..254b64a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/imx.txt
@@ -0,0 +1,57 @@
+Freescale i.MX Media Video Devices
+
+Video Media Controller node
+---
+
+This is the parent media controller node for video capture support.
+
+Required properties:
+- compatible : "fsl,imx-media";

Would you be opposed to calling this "capture-subsystem" instead of
"imx-media"? We already use "fsl,imx-display-subsystem" and
"fsl,imx-gpu-subsystem" for the display and GPU compound devices.


sure. Some pie-in-the-sky day when DRM and media are unified,
there could be a single device that handles them all, but for now
I'm fine with "fsl,capture-subsystem".


+- ports  : Should contain a list of phandles pointing to camera
+  sensor interface ports of IPU devices
+
+
+fim child node
+--
+
+This is an optional child node of the ipu_csi port nodes. If present and
+available, it enables the Frame Interval Monitor. Its properties can be
+used to modify the method in which the FIM measures frame intervals.
+Refer to Documentation/media/v4l-drivers/imx.rst for more info on the
+Frame Interval Monitor.
+
+Optional properties:
+- fsl,input-capture-channel: an input capture channel and channel flags,
+specified as . The channel number
+must be 0 or 1. The flags can be
+IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, or
+IRQ_TYPE_EDGE_BOTH, and specify which input
+capture signal edge will trigger the input
+capture event. If an input capture channel is
+specified, the FIM will use this method to
+measure frame intervals instead of via the EOF
+interrupt. The input capture method is much
+preferred over EOF as it is not subject to
+interrupt latency errors. However it requires
+routing the VSYNC or FIELD output signals of
+the camera sensor to one of the i.MX input
+capture pads (SD1_DAT0, SD1_DAT1), which also
+gives up support for SD1.

This is a clever method to get better frame timestamps. Too bad about
the routing requirements. Can this be used on Nitrogen6X?


Absolutely, this support just needs use of the input-capture channels in the
imx GPT. I still need to submit the patch to the imx-gpt driver that adds an
input capture API, so at this point fsl,input-capture-channel has no effect,
but it does work (tested on SabreAuto).




+
+mipi_csi2 node
+--
+
+This is the device node for the MIPI CSI-2 Receiver, required for MIPI
+CSI-2 sensors.
+
+Required properties:
+- compatible   : "fsl,imx6-mipi-csi2";

I think this should get an additional "snps,dw-mipi-csi2" compatible,
since the only i.MX6 specific part is the bolted-on IPU2CSI gasket.


right, minus the gasket it's a Synopsys core. I'll add that compatible flag.
Or should wait until the day this subdev is exported for general use, after
pulling out the gasket specifics?





+- reg   : physical base address and length of the register set;
+- clocks   : the MIPI CSI-2 receiver requires three clocks: hsi_tx
+  (the DPHY clock), video_27m, and eim_sel;

Note that hsi_tx is incorrectly named. CCGR3[CG8] just happens to be the
shared gate bit that gates the HSI clocks as well as the MIPI
"ac_clk_125m", "cfg_clk", "ips_clk", and "pll_refclk" inputs to the mipi
csi-2 core, but we are missing shared gate clocks in the clock tree for
these.


Yes, so many clocks for the MIPI core. Why so many? I would think
there would need to be at most three: a clock for the MIPI CSI-2 core
and HSI core, and a clock for the D-PHY (oh and maybe a clock for an
M-PHY if there is one). I have no clue what all these other clocks are.
But anyway, a single gating bit, CCGR3[CG8], seems to enable them all.


Both cfg_clk and pll_refclk are sourced from video_27m, so "cfg" ->
video_27m seems fine.
But I don't get "dphy".


I presume it's the clock for the D-PHY.


  Which input clock would that correspond to?
"pll_refclk?"


the mux at CDCDR says it comes from PLL3_120M, or PLL2_PFD2.



Also the pixel clock input is a gate after

Re: [PATCH RFC] hv_utils: implement Hyper-V PTP source

2017-01-13 Thread Vitaly Kuznetsov 
Richard Cochran  writes:

>> +struct ptp_clock_info ptp_hyperv_info = {
>> +.name   = "hyperv",
>> +.enable = hv_ptp_enable,
>> +.gettime64  = hv_ptp_gettime,
>
> The code in drivers/ptp/ptp_clock.c calls
>
>   .adjfreq (or adjfine)
>   .adjtime
>   .settime64
>
> unconditionally, so you need to implement these returning EOPNOTSUPP.
> (See also Documentation/ptp/ptp.txt)
>

Sure, thanks, will do in non-RFC version.

-- 
  Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH RFC] hv_utils: implement Hyper-V PTP source

2017-01-13 Thread Vitaly Kuznetsov 
Olaf Hering  writes:

> On Fri, Jan 13, Vitaly Kuznetsov wrote:
>
>> +hv_ptp_clock = ptp_clock_register(_hyperv_info, NULL);
>> +if (IS_ERR(hv_ptp_clock)) {
>
> Should that be IS_ERR_OR_NULL to catch "!IS_REACHABLE(CONFIG_PTP_1588_CLOCK)"?
>

Oh, yes. I missed the case when CONFIG_PTP_1588_CLOCK is disabled
completely. I'll also remove the return below to not fail the device
completely. Even if there is no PTP support in kernel the
ICTIMESYNCFLAG_SYNC case which triggers do_settimeofday64() is still
probably useful.

-- 
  Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 16/24] media: Add i.MX media core driver

2017-01-13 Thread Philipp Zabel 
Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
> Add the core media driver for i.MX SOC.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  Documentation/media/v4l-drivers/imx.rst   | 443 ++
>  drivers/staging/media/Kconfig |   2 +
>  drivers/staging/media/Makefile|   1 +
>  drivers/staging/media/imx/Kconfig |   8 +
>  drivers/staging/media/imx/Makefile|   6 +
>  drivers/staging/media/imx/TODO|  22 +
>  drivers/staging/media/imx/imx-media-common.c  | 981 
> ++
>  drivers/staging/media/imx/imx-media-dev.c | 486 +++
>  drivers/staging/media/imx/imx-media-fim.c | 471 +++
>  drivers/staging/media/imx/imx-media-internal-sd.c | 457 ++
>  drivers/staging/media/imx/imx-media-of.c  | 289 +++
>  drivers/staging/media/imx/imx-media.h | 310 +++
>  include/media/imx.h   |  15 +
>  include/uapi/linux/v4l2-controls.h|   4 +
>  14 files changed, 3495 insertions(+)
>  create mode 100644 Documentation/media/v4l-drivers/imx.rst
>  create mode 100644 drivers/staging/media/imx/Kconfig
>  create mode 100644 drivers/staging/media/imx/Makefile
>  create mode 100644 drivers/staging/media/imx/TODO
>  create mode 100644 drivers/staging/media/imx/imx-media-common.c
>  create mode 100644 drivers/staging/media/imx/imx-media-dev.c
>  create mode 100644 drivers/staging/media/imx/imx-media-fim.c
>  create mode 100644 drivers/staging/media/imx/imx-media-internal-sd.c
>  create mode 100644 drivers/staging/media/imx/imx-media-of.c
>  create mode 100644 drivers/staging/media/imx/imx-media.h
>  create mode 100644 include/media/imx.h
> 
> diff --git a/Documentation/media/v4l-drivers/imx.rst 
> b/Documentation/media/v4l-drivers/imx.rst
> new file mode 100644
> index 000..87b37b5
> --- /dev/null
> +++ b/Documentation/media/v4l-drivers/imx.rst
> @@ -0,0 +1,443 @@
> +i.MX Video Capture Driver
> +=
> +
> +Introduction
> +
> +
> +The Freescale i.MX5/6 contains an Image Processing Unit (IPU), which
> +handles the flow of image frames to and from capture devices and
> +display devices.
> +
> +For image capture, the IPU contains the following internal subunits:
> +
> +- Image DMA Controller (IDMAC)
> +- Camera Serial Interface (CSI)
> +- Image Converter (IC)
> +- Sensor Multi-FIFO Controller (SMFC)
> +- Image Rotator (IRT)
> +- Video De-Interlace Controller (VDIC)

Nitpick: Video De-Interlacing or Combining Block (VDIC)

> +
> +The IDMAC is the DMA controller for transfer of image frames to and from
> +memory. Various dedicated DMA channels exist for both video capture and
> +display paths.
> +
> +The CSI is the frontend capture unit that interfaces directly with
> +capture sensors over Parallel, BT.656/1120, and MIPI CSI-2 busses.
> +
> +The IC handles color-space conversion, resizing, and rotation
> +operations. 

And horizontal flipping.

> There are three independent "tasks" within the IC that can
> +carry out conversions concurrently: pre-processing encoding,
> +pre-processing preview, and post-processing.

s/preview/viewfinder/ seems to be the commonly used name.

This paragraph could mention that a single hardware unit is used
transparently time multiplexed by the three tasks at different
granularity for the downsizing, main processing, and rotation sections.
The downscale unit switches between tasks at 8-pixel burst granularity,
the main processing unit at line granularity. The rotation units switch
only at frame granularity.

> +The SMFC is composed of four independent channels that each can transfer
> +captured frames from sensors directly to memory concurrently.
> +
> +The IRT carries out 90 and 270 degree image rotation operations.

... on 8x8 pixel blocks, supported by the IDMAC which handles block
transfers, block reordering, and vertical flipping.

> +The VDIC handles the conversion of interlaced video to progressive, with
> +support for different motion compensation modes (low, medium, and high
> +motion). The deinterlaced output frames from the VDIC can be sent to the
> +IC pre-process preview task for further conversions.
> +
> +In addition to the IPU internal subunits, there are also two units
> +outside the IPU that are also involved in video capture on i.MX:
> +
> +- MIPI CSI-2 Receiver for camera sensors with the MIPI CSI-2 bus
> +  interface. This is a Synopsys DesignWare core.
> +- A video multiplexer for selecting among multiple sensor inputs to
> +  send to a CSI.

Two of them, actually.

> +For more info, refer to the latest versions of the i.MX5/6 reference
> +manuals listed under References.
> +
> +
> +Features
> +
> +
> +Some of the features of this driver include:
> +
> +- Many different pipelines can be configured via media controller API,
> +  that correspond to the hardware video capture

Re: [PATCH RFC] hv_utils: implement Hyper-V PTP source

2017-01-13 Thread Olaf Hering 
On Fri, Jan 13, Vitaly Kuznetsov wrote:

> + hv_ptp_clock = ptp_clock_register(_hyperv_info, NULL);
> + if (IS_ERR(hv_ptp_clock)) {

Should that be IS_ERR_OR_NULL to catch "!IS_REACHABLE(CONFIG_PTP_1588_CLOCK)"?

Olaf


signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH RFC] hv_utils: implement Hyper-V PTP source

2017-01-13 Thread Richard Cochran 
On Fri, Jan 13, 2017 at 02:05:43PM +0100, Vitaly Kuznetsov wrote:
> Instead of doing in-kernel time adjustments offload the work to an
> NTP client by exposing TimeSync messages as a PTP device. Users my now
> decide what they want to use as a source.
> 
> I tested the solution with chrony, the config was:
> 
>  refclock PHC /dev/ptp0 poll 3 precision 1e-9
> 
> The result I'm seeing is accurate enough, the time delta between the guest
> and the host is almost always within [-10us, +10us], the in-kernel solution
> was giving us comparable results.

This approach is much nicer than the previous one.

> +static int hv_ptp_enable(struct ptp_clock_info *info,
> +  struct ptp_clock_request *request, int on)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static int hv_ptp_gettime(struct ptp_clock_info *info, struct timespec64 *ts)
> +{
> + u64 newtime;
> + unsigned long flags;
> +
> + spin_lock_irqsave(_ts.lock, flags);
> + newtime = host_ts.host_time + get_timeadj_latency(host_ts.ref_time);
> + *ts = ns_to_timespec64((newtime - WLTIMEDELTA) * 100);
> + spin_unlock_irqrestore(_ts.lock, flags);
> +
> + return 0;
> +}
> +
> +struct ptp_clock_info ptp_hyperv_info = {
> + .name   = "hyperv",
> + .enable = hv_ptp_enable,
> + .gettime64  = hv_ptp_gettime,

The code in drivers/ptp/ptp_clock.c calls

.adjfreq (or adjfine)
.adjtime
.settime64

unconditionally, so you need to implement these returning EOPNOTSUPP.
(See also Documentation/ptp/ptp.txt)

> + .owner  = THIS_MODULE,
> +};

Thanks,
Richard
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH RFC] hv_utils: implement Hyper-V PTP source

2017-01-13 Thread Vitaly Kuznetsov 
With TimeSync version 4 protocol support we started updating system time
continuously through the whole lifetime of Hyper-V guests. Every 5 seconds
there is a time sample from the host which triggers do_settimeofday[64]().
While the time from the host is very accurate such adjustments may cause
issues:
- Time is jumping forward and backward, some applications may misbehave.
- In case an NTP server runs in parallel and uses something else for time
  sync (network, PTP,...) system time will never converge.
- Systemd starts annoying you by printing "Time has been changed" every 5
  seconds to the system log.

Instead of doing in-kernel time adjustments offload the work to an
NTP client by exposing TimeSync messages as a PTP device. Users my now
decide what they want to use as a source.

I tested the solution with chrony, the config was:

 refclock PHC /dev/ptp0 poll 3 precision 1e-9

The result I'm seeing is accurate enough, the time delta between the guest
and the host is almost always within [-10us, +10us], the in-kernel solution
was giving us comparable results.

I also tried implementing PPS device instead of PTP by using not currently
used Hyper-V synthetic timers (we use only one of four for clockevent) but
with PPS source only chrony wasn't able to give me the required accuracy,
the delta often more that 100us.

Signed-off-by: Vitaly Kuznetsov 
---
 drivers/hv/hv_util.c | 106 +++
 1 file changed, 82 insertions(+), 24 deletions(-)

diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 94719eb..16fb874c3 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "hyperv_vmbus.h"
 
@@ -179,31 +180,35 @@ struct adj_time_work {
u8  flags;
 };
 
+static inline u64 get_timeadj_latency(u64 ref_time)
+{
+   u64 current_tick;
+
+   if (ts_srv_version <= TS_VERSION_3)
+   return 0;
+
+   /*
+* Some latency has been introduced since Hyper-V generated
+* its time sample. Take that latency into account before
+* using TSC reference time sample from Hyper-V.
+*
+* This sample is given by TimeSync v4 and above hosts.
+*/
+
+   rdmsrl(HV_X64_MSR_TIME_REF_COUNT, current_tick);
+   return current_tick - ref_time;
+}
+
 static void hv_set_host_time(struct work_struct *work)
 {
struct adj_time_work*wrk;
-   s64 host_tns;
u64 newtime;
struct timespec64 host_ts;
 
wrk = container_of(work, struct adj_time_work, work);
 
-   newtime = wrk->host_time;
-   if (ts_srv_version > TS_VERSION_3) {
-   /*
-* Some latency has been introduced since Hyper-V generated
-* its time sample. Take that latency into account before
-* using TSC reference time sample from Hyper-V.
-*
-* This sample is given by TimeSync v4 and above hosts.
-*/
-   u64 current_tick;
-
-   rdmsrl(HV_X64_MSR_TIME_REF_COUNT, current_tick);
-   newtime += (current_tick - wrk->ref_time);
-   }
-   host_tns = (newtime - WLTIMEDELTA) * 100;
-   host_ts = ns_to_timespec64(host_tns);
+   newtime = wrk->host_time + get_timeadj_latency(wrk->ref_time);
+   host_ts = ns_to_timespec64((newtime - WLTIMEDELTA) * 100);
 
do_settimeofday64(_ts);
 }
@@ -222,22 +227,39 @@ static void hv_set_host_time(struct work_struct *work)
  * to discipline the clock.
  */
 static struct adj_time_work  wrk;
-static inline void adj_guesttime(u64 hosttime, u64 reftime, u8 flags)
+
+static struct {
+   u64 host_time;
+   u64 ref_time;
+   spinlock_t lock;
+} host_ts;
+
+static inline void adj_guesttime(u64 hosttime, u64 reftime, u8 adj_flags)
 {
+   unsigned long flags;
 
/*
 * This check is safe since we are executing in the
 * interrupt context and time synch messages arre always
 * delivered on the same CPU.
 */
-   if (work_pending())
-   return;
+   if (adj_flags & ICTIMESYNCFLAG_SYNC) {
+   if (work_pending())
+   return;
 
-   wrk.host_time = hosttime;
-   wrk.ref_time = reftime;
-   wrk.flags = flags;
-   if ((flags & (ICTIMESYNCFLAG_SYNC | ICTIMESYNCFLAG_SAMPLE)) != 0) {
+   wrk.host_time = hosttime;
+   wrk.ref_time = reftime;
+   wrk.flags = adj_flags;
schedule_work();
+   } else {
+   spin_lock_irqsave(_ts.lock, flags);
+   host_ts.host_time = hosttime;
+
+   if (ts_srv_version <= TS_VERSION_3)
+   rdmsrl(HV_X64_MSR_TIME_REF_COUNT, host_ts.ref_time);
+   else
+   host_ts.ref_time = reftime;
+   spin_unlock_irqrestore(_ts.lock, flags);
}
 }
 
@@

Re: [PATCH v3 15/24] media: Add userspace header file for i.MX

2017-01-13 Thread Philipp Zabel 
Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
> This adds a header file for use by userspace programs wanting to interact
> with the i.MX media driver. It defines custom v4l2 controls and events
> generated by the i.MX v4l2 subdevices.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  include/uapi/media/Kbuild |  1 +
>  include/uapi/media/imx.h  | 30 ++
>  2 files changed, 31 insertions(+)
>  create mode 100644 include/uapi/media/imx.h
> 
> diff --git a/include/uapi/media/Kbuild b/include/uapi/media/Kbuild
> index aafaa5a..fa78958 100644
> --- a/include/uapi/media/Kbuild
> +++ b/include/uapi/media/Kbuild
> @@ -1 +1,2 @@
>  # UAPI Header export list
> +header-y += imx.h
> diff --git a/include/uapi/media/imx.h b/include/uapi/media/imx.h
> new file mode 100644
> index 000..2421d9c
> --- /dev/null
> +++ b/include/uapi/media/imx.h
> @@ -0,0 +1,30 @@
> +/*
> + * Copyright (c) 2014-2015 Mentor Graphics Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version
> + */
> +
> +#ifndef __UAPI_MEDIA_IMX_H__
> +#define __UAPI_MEDIA_IMX_H__
> +
> +/*
> + * events from the subdevs
> + */
> +#define V4L2_EVENT_IMX_CLASS  V4L2_EVENT_PRIVATE_START
> +#define V4L2_EVENT_IMX_NFB4EOF(V4L2_EVENT_IMX_CLASS + 1)
> +#define V4L2_EVENT_IMX_EOF_TIMEOUT(V4L2_EVENT_IMX_CLASS + 2)
> +#define V4L2_EVENT_IMX_FRAME_INTERVAL (V4L2_EVENT_IMX_CLASS + 3)

Aren't these generic enough to warrant common events? I would think
there have to be other capture IP cores that can signal aborted frames
or frame timeouts.

> +
> +enum imx_ctrl_id {
> + V4L2_CID_IMX_MOTION = (V4L2_CID_USER_IMX_BASE + 0),
> + V4L2_CID_IMX_FIM_ENABLE,
> + V4L2_CID_IMX_FIM_NUM,
> + V4L2_CID_IMX_FIM_TOLERANCE_MIN,
> + V4L2_CID_IMX_FIM_TOLERANCE_MAX,
> + V4L2_CID_IMX_FIM_NUM_SKIP,
> +};
> +
> +#endif

regards
Philipp

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 02/24] ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node

2017-01-13 Thread Philipp Zabel 
Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
> Add to the MIPI CSI2 receiver node: compatible string, interrupt sources,
> clocks.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  arch/arm/boot/dts/imx6qdl.dtsi | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index 53e6e63..42926e9 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -1125,7 +1125,14 @@
>   };
>  
>   mipi_csi: mipi@021dc000 {
> + compatible = "fsl,imx6-mipi-csi2";
>   reg = <0x021dc000 0x4000>;
> + interrupts = <0 100 0x04>, <0 101 0x04>;
> + clocks = < IMX6QDL_CLK_HSI_TX>,
> +  < IMX6QDL_CLK_VIDEO_27M>,
> +  < IMX6QDL_CLK_EIM_SEL>;

I think the latter should be EIM_PODF

> + clock-names = "dphy", "cfg", "pix";

and I'm not sure dphy is the right name for this one. Is that the pll
ref input?

> + status = "disabled";
>   };
>  
>   mipi_dsi: mipi@021e {

regards
Philipp

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 01/24] [media] dt-bindings: Add bindings for i.MX media driver

2017-01-13 Thread Philipp Zabel 
Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
> Add bindings documentation for the i.MX media driver.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  Documentation/devicetree/bindings/media/imx.txt | 57 
> +
>  1 file changed, 57 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/imx.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/imx.txt 
> b/Documentation/devicetree/bindings/media/imx.txt
> new file mode 100644
> index 000..254b64a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/imx.txt
> @@ -0,0 +1,57 @@
> +Freescale i.MX Media Video Devices
> +
> +Video Media Controller node
> +---
> +
> +This is the parent media controller node for video capture support.
> +
> +Required properties:
> +- compatible : "fsl,imx-media";

Would you be opposed to calling this "capture-subsystem" instead of
"imx-media"? We already use "fsl,imx-display-subsystem" and
"fsl,imx-gpu-subsystem" for the display and GPU compound devices.

> +- ports  : Should contain a list of phandles pointing to camera
> +sensor interface ports of IPU devices
> +
> +
> +fim child node
> +--
> +
> +This is an optional child node of the ipu_csi port nodes. If present and
> +available, it enables the Frame Interval Monitor. Its properties can be
> +used to modify the method in which the FIM measures frame intervals.
> +Refer to Documentation/media/v4l-drivers/imx.rst for more info on the
> +Frame Interval Monitor.
> +
> +Optional properties:
> +- fsl,input-capture-channel: an input capture channel and channel flags,
> +  specified as . The channel number
> +  must be 0 or 1. The flags can be
> +  IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, or
> +  IRQ_TYPE_EDGE_BOTH, and specify which input
> +  capture signal edge will trigger the input
> +  capture event. If an input capture channel is
> +  specified, the FIM will use this method to
> +  measure frame intervals instead of via the EOF
> +  interrupt. The input capture method is much
> +  preferred over EOF as it is not subject to
> +  interrupt latency errors. However it requires
> +  routing the VSYNC or FIELD output signals of
> +  the camera sensor to one of the i.MX input
> +  capture pads (SD1_DAT0, SD1_DAT1), which also
> +  gives up support for SD1.

This is a clever method to get better frame timestamps. Too bad about
the routing requirements. Can this be used on Nitrogen6X?

> +
> +mipi_csi2 node
> +--
> +
> +This is the device node for the MIPI CSI-2 Receiver, required for MIPI
> +CSI-2 sensors.
> +
> +Required properties:
> +- compatible : "fsl,imx6-mipi-csi2";

I think this should get an additional "snps,dw-mipi-csi2" compatible,
since the only i.MX6 specific part is the bolted-on IPU2CSI gasket.

> +- reg   : physical base address and length of the register set;
> +- clocks : the MIPI CSI-2 receiver requires three clocks: hsi_tx
> +  (the DPHY clock), video_27m, and eim_sel;

Note that hsi_tx is incorrectly named. CCGR3[CG8] just happens to be the
shared gate bit that gates the HSI clocks as well as the MIPI
"ac_clk_125m", "cfg_clk", "ips_clk", and "pll_refclk" inputs to the mipi
csi-2 core, but we are missing shared gate clocks in the clock tree for
these.
Both cfg_clk and pll_refclk are sourced from video_27m, so "cfg" ->
video_27m seems fine.
But I don't get "dphy". Which input clock would that correspond to?
"pll_refclk?"
Also the pixel clock input is a gate after aclk_podf (which we call
eim_podf), not aclk_sel (eim_sel).

> +- clock-names: must contain "dphy", "cfg", "pix";
> +
> +Optional properties:
> +- interrupts : must contain two level-triggered interrupts,
> +  in order: 100 and 101;

regards
Philipp

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 05/24] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround

2017-01-13 Thread Philipp Zabel 
Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
> There is a pin conflict with GPIO_6. This pin functions as a power
> input pin to the OV5642 camera sensor, but ENET uses it as the h/w
> workaround for erratum ERR006687, to wake-up the ARM cores on normal
> RX and TX packet done events. So we need to remove the h/w workaround
> to support the OV5642. The result is that the CPUidle driver will no
> longer allow entering the deep idle states on the sabrelite.
> 
> This is a partial revert of
> 
> commit 6261c4c8f13e ("ARM: dts: imx6qdl-sabrelite: use GPIO_6 for FEC
>   interrupt.")
> commit a28eeb43ee57 ("ARM: dts: imx6: tag boards that have the HW workaround
>   for ERR006687")
> 
> Signed-off-by: Steve Longerbeam 

Pity this has to be removed for all, Nitrogen6X should really use DT
overlays for the add-on boards / cameras.

regards
Philipp

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 06/24] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

2017-01-13 Thread Philipp Zabel 
Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
> Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
> Both hang off the same i2c2 bus, so they require different (and non-
> default) i2c slave addresses.
> 
> The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.
> 
> The OV5640 connects to the input port on the MIPI CSI-2 receiver on
> mipi_csi. It is set to transmit over MIPI virtual channel 1.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  arch/arm/boot/dts/imx6dl-sabrelite.dts   |   5 ++
>  arch/arm/boot/dts/imx6q-sabrelite.dts|   6 ++
>  arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 118 
> +++
>  3 files changed, 129 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6dl-sabrelite.dts 
> b/arch/arm/boot/dts/imx6dl-sabrelite.dts
> index 0f06ca5..fec2524 100644
> --- a/arch/arm/boot/dts/imx6dl-sabrelite.dts
> +++ b/arch/arm/boot/dts/imx6dl-sabrelite.dts
> @@ -48,3 +48,8 @@
>   model = "Freescale i.MX6 DualLite SABRE Lite Board";
>   compatible = "fsl,imx6dl-sabrelite", "fsl,imx6dl";
>  };
> +
> +_csi1_from_ipu1_csi1_mux {
> + data-lanes = <0 1>;
> + clock-lanes = <2>;
> +};
> diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts 
> b/arch/arm/boot/dts/imx6q-sabrelite.dts
> index 66d10d8..9e2d26d 100644
> --- a/arch/arm/boot/dts/imx6q-sabrelite.dts
> +++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
> @@ -52,3 +52,9 @@
>   {
>   status = "okay";
>  };
> +
> +_csi1_from_mipi_vc1 {
> + data-lanes = <0 1>;
> + clock-lanes = <2>;
> +};
> +
> diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi 
> b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> index 795b5a5..bca9fed 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> @@ -39,6 +39,8 @@
>   * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>   * OTHER DEALINGS IN THE SOFTWARE.
>   */
> +
> +#include 
>  #include 
>  #include 
>  
> @@ -96,6 +98,15 @@
>   };
>   };
>  
> + mipi_xclk: mipi_xclk {
> + compatible = "pwm-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2200>;
> + clock-output-names = "mipi_pwm3";
> + pwms = < 0 45>; /* 1 / 45 ns = 22 MHz */
> + status = "okay";
> + };
> +
>   gpio-keys {
>   compatible = "gpio-keys";
>   pinctrl-names = "default";
> @@ -220,6 +231,22 @@
>   };
>  };
>  
> +_csi0_from_ipu1_csi0_mux {
> + bus-width = <8>;
> + data-shift = <12>; /* Lines 19:12 used */
> + hsync-active = <1>;
> + vync-active = <1>;
> +};
> +
> +_csi0_mux_from_parallel_sensor {
> + remote-endpoint = <_to_ipu1_csi0_mux>;
> +};
> +
> +_csi0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_ipu1_csi0>;
> +};
> +
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_audmux>;
> @@ -299,6 +326,52 @@
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c2>;
>   status = "okay";
> +
> + ov5640: camera@40 {
> + compatible = "ovti,ov5640";
> + pinctrl-names = "default";
> + pinctrl-0 = <_ov5640>;
> + clocks = <_xclk>;
> + clock-names = "xclk";
> + reg = <0x40>;
> + xclk = <2200>;

This is superfluous, you can use clk_get_rate on mipi_xclk.

> + reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* NANDF_D5 */
> + pwdn-gpios = < 9 GPIO_ACTIVE_HIGH>; /* NANDF_WP_B */
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ov5640_to_mipi_csi: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <_csi_from_mipi_sensor>;
> + data-lanes = <0 1>;
> + clock-lanes = <2>;
> + };
> + };
> + };
> +
> + ov5642: camera@42 {
> + compatible = "ovti,ov5642";
> + pinctrl-names = "default";
> + pinctrl-0 = <_ov5642>;
> + clocks = < IMX6QDL_CLK_CKO2>;
> + clock-names = "xclk";
> + reg = <0x42>;
> + xclk = <2400>;

Same here, use assigned-clock-rates on IMX6QDL_CLK_CKO2 if necessary.

> + reset-gpios = < 8 GPIO_ACTIVE_LOW>;
> + pwdn-gpios = < 6 GPIO_ACTIVE_HIGH>;
> + gp-gpios = < 16 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + ov5642_to_ipu1_csi0_mux: endpoint {
> + remote-endpoint = 
> <_csi0_mux_from_parallel_sensor>;
> + bus-width = <8>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + };
> + };
> + };
>  };
>  
>   {
> @@ -412,6 +485,23 @@
>