[v8,14/34] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder

Message ID 1496860453-6282-15-git-send-email-steve_longerbeam@mentor.com (mailing list archive)
State Not Applicable, archived
Delegated to: Hans Verkuil
Headers

Commit Message

Steve Longerbeam June 7, 2017, 6:33 p.m. UTC
  Enables the ADV7180 decoder sensor. The ADV7180 connects to the
parallel-bus mux input on ipu1_csi0_mux.

The ADV7180 power pin is via max7310_b port expander.

Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>

- Use IRQ_TYPE_LEVEL_LOW instead of 0x8 for interrupt type for clarity.
- For 8-bit parallel IPU1-CSI0 bus connection only data[12-19] are used.

Signed-off-by: Tim Harvey <tharvey@gateworks.com>
---
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 50 ++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)
  

Comments

Tim Harvey June 8, 2017, 8:25 p.m. UTC | #1
On Wed, Jun 7, 2017 at 11:33 AM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
> Enables the ADV7180 decoder sensor. The ADV7180 connects to the
> parallel-bus mux input on ipu1_csi0_mux.
>
> The ADV7180 power pin is via max7310_b port expander.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>
> - Use IRQ_TYPE_LEVEL_LOW instead of 0x8 for interrupt type for clarity.
> - For 8-bit parallel IPU1-CSI0 bus connection only data[12-19] are used.
>
> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
> ---
>  arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 50 ++++++++++++++++++++++++++++++++
>  1 file changed, 50 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> index 1212f82..c24af28 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
> @@ -124,6 +124,21 @@
>                         #size-cells = <0>;
>                         reg = <1>;
>
> +                       adv7180: camera@21 {
> +                               compatible = "adi,adv7180";
> +                               reg = <0x21>;
> +                               powerdown-gpios = <&max7310_b 2 GPIO_ACTIVE_LOW>;
> +                               interrupt-parent = <&gpio1>;
> +                               interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
> +
> +                               port {
> +                                       adv7180_to_ipu1_csi0_mux: endpoint {
> +                                               remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
> +                                               bus-width = <8>;
> +                                       };
> +                               };
> +                       };
> +
>                         max7310_a: gpio@30 {
>                                 compatible = "maxim,max7310";
>                                 reg = <0x30>;
> @@ -151,6 +166,25 @@
>         };
>  };
>
> +&ipu1_csi0_from_ipu1_csi0_mux {
> +       bus-width = <8>;
> +};
> +
> +&ipu1_csi0_mux_from_parallel_sensor {
> +       remote-endpoint = <&adv7180_to_ipu1_csi0_mux>;
> +       bus-width = <8>;
> +};
> +
> +&ipu1_csi0 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_ipu1_csi0>;
> +
> +       /* enable frame interval monitor on this port */
> +       fim {
> +               status = "okay";
> +       };

Steve,

You need to remove the fim node now that you've moved this to V4L2 controls.

Regards,

Tim
  
Steve Longerbeam June 8, 2017, 8:36 p.m. UTC | #2
On 06/08/2017 01:25 PM, Tim Harvey wrote:
> 
> 
> Steve,
> 
> You need to remove the fim node now that you've moved this to V4L2 controls.
> 

Yep, I caught this just after sending the v8 patchset. I'll send
a v9 of this patch.

Steve
  
Pavel Machek June 9, 2017, 9:38 p.m. UTC | #3
On Thu 2017-06-08 13:36:12, Steve Longerbeam wrote:
> 
> 
> On 06/08/2017 01:25 PM, Tim Harvey wrote:
> >
> >
> >Steve,
> >
> >You need to remove the fim node now that you've moved this to V4L2 controls.
> >
> 
> Yep, I caught this just after sending the v8 patchset. I'll send
> a v9 of this patch.

This needs ack from devicetree people, then it can be merged. Can you
be a bit more forceful getting the ack?

I don't think it makes sense to resubmit v9 before that. This is not a
rocket science.

Thanks,
									Pavel
  
Steve Longerbeam June 9, 2017, 10:35 p.m. UTC | #4
On 06/09/2017 02:38 PM, Pavel Machek wrote:
> On Thu 2017-06-08 13:36:12, Steve Longerbeam wrote:
>>
>>
>> On 06/08/2017 01:25 PM, Tim Harvey wrote:
>>>
>>>
>>> Steve,
>>>
>>> You need to remove the fim node now that you've moved this to V4L2 controls.
>>>
>>
>> Yep, I caught this just after sending the v8 patchset. I'll send
>> a v9 of this patch.
> 
> This needs ack from devicetree people, then it can be merged. Can you
> be a bit more forceful getting the ack?

OK, I need an Ack please, he said, in a forceful way. :)

In fact Ack's are needed for all the changes to dts sources,
patches 4-14.


> 
> I don't think it makes sense to resubmit v9 before that. This is not a
> rocket science.

I guess that makes sense, I'll wait for Ack's from all these patches
before submitting the entire patchset as v9.

Steve
  
Pavel Machek June 9, 2017, 11:23 p.m. UTC | #5
Hi!

> >>>Steve,
> >>>
> >>>You need to remove the fim node now that you've moved this to V4L2 controls.
> >>>
> >>
> >>Yep, I caught this just after sending the v8 patchset. I'll send
> >>a v9 of this patch.
> >
> >This needs ack from devicetree people, then it can be merged. Can you
> >be a bit more forceful getting the ack?
> 
> OK, I need an Ack please, he said, in a forceful way. :)

I'd tune the force up a tiny bit more. This is not FreeBSD ;-). You
can read some emails from Linus for inspiration. Or drink few beers
and look at Al Viro's emails.

> In fact Ack's are needed for all the changes to dts sources,
> patches 4-14.

Actually, are they? Those should not need acks from device tree
people, just acks from ARM people, and those are easier to get... in
fact they should not need any acks, you should just send them to arm
people and get them merged.

1-4 is just a documentation, and you have acks there. (Except 2?)
That's ready to be merged, probably via the media tree? Just make it
clear you want it merged.

15,16 should be ready to. Media tree, too, I guess.

drivers/staging is greg. Advantage is these do _not_ need to go after
the dts changes. It is a driver. Actually I'd normally add dts support
after the driver. So you can push it now.

> >I don't think it makes sense to resubmit v9 before that. This is not a
> >rocket science.
> 
> I guess that makes sense, I'll wait for Ack's from all these patches
> before submitting the entire patchset as v9.

You may want to split the series, according to mainainters, or just
ask the maintainers to merge the relevant parts. I believe most of it
can be pushed now. 

Good luck,
								Pavel
  
Steve Longerbeam June 10, 2017, 12:19 a.m. UTC | #6
On 06/09/2017 04:23 PM, Pavel Machek wrote:
> Hi!
> 
>>>>> Steve,
>>>>>
>>>>> You need to remove the fim node now that you've moved this to V4L2 controls.
>>>>>
>>>>
>>>> Yep, I caught this just after sending the v8 patchset. I'll send
>>>> a v9 of this patch.
>>>
>>> This needs ack from devicetree people, then it can be merged. Can you
>>> be a bit more forceful getting the ack?
>>
>> OK, I need an Ack please, he said, in a forceful way. :)
> 
> I'd tune the force up a tiny bit more. This is not FreeBSD ;-). You
> can read some emails from Linus for inspiration. Or drink few beers
> and look at Al Viro's emails.
> 
>> In fact Ack's are needed for all the changes to dts sources,
>> patches 4-14.
> 
> Actually, are they? Those should not need acks from device tree
> people, just acks from ARM people, and those are easier to get... in
> fact they should not need any acks, you should just send them to arm
> people and get them merged.


Hans said he prefers to have the dts patches as part of the whole set
rather than submitted separately. But I did add --to's for the ARM
people for 4-14.


> 
> 1-4 is just a documentation, and you have acks there. (Except 2?)
> That's ready to be merged, probably via the media tree? Just make it
> clear you want it merged.

Yes, 1-3 now have Acks (binding docs).

> 
> 15,16 should be ready to. Media tree, too, I guess.

Yes, those have Acks (video-mux entity functions and subdev driver).

> 
> drivers/staging is greg. Advantage is these do _not_ need to go after
> the dts changes. It is a driver. Actually I'd normally add dts support
> after the driver. So you can push it now.

Right, Hans agrees, except that for staging drivers we don't really need
an Ack from Greg.


> 
>>> I don't think it makes sense to resubmit v9 before that. This is not a
>>> rocket science.
>>
>> I guess that makes sense, I'll wait for Ack's from all these patches
>> before submitting the entire patchset as v9.
> 
> You may want to split the series, according to mainainters, or just
> ask the maintainers to merge the relevant parts. I believe most of it
> can be pushed now.
> 
> Good luck,

Thanks!
Steve
  

Patch

diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 1212f82..c24af28 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -124,6 +124,21 @@ 
 			#size-cells = <0>;
 			reg = <1>;
 
+			adv7180: camera@21 {
+				compatible = "adi,adv7180";
+				reg = <0x21>;
+				powerdown-gpios = <&max7310_b 2 GPIO_ACTIVE_LOW>;
+				interrupt-parent = <&gpio1>;
+				interrupts = <27 IRQ_TYPE_LEVEL_LOW>;
+
+				port {
+					adv7180_to_ipu1_csi0_mux: endpoint {
+						remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>;
+						bus-width = <8>;
+					};
+				};
+			};
+
 			max7310_a: gpio@30 {
 				compatible = "maxim,max7310";
 				reg = <0x30>;
@@ -151,6 +166,25 @@ 
 	};
 };
 
+&ipu1_csi0_from_ipu1_csi0_mux {
+	bus-width = <8>;
+};
+
+&ipu1_csi0_mux_from_parallel_sensor {
+	remote-endpoint = <&adv7180_to_ipu1_csi0_mux>;
+	bus-width = <8>;
+};
+
+&ipu1_csi0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ipu1_csi0>;
+
+	/* enable frame interval monitor on this port */
+	fim {
+		status = "okay";
+	};
+};
+
 &clks {
 	assigned-clocks = <&clks IMX6QDL_PLL4_BYPASS_SRC>,
 			  <&clks IMX6QDL_PLL4_BYPASS>,
@@ -444,6 +478,22 @@ 
 			>;
 		};
 
+		pinctrl_ipu1_csi0: ipu1csi0grp {
+			fsl,pins = <
+				MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12  0x1b0b0
+				MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13  0x1b0b0
+				MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14  0x1b0b0
+				MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15  0x1b0b0
+				MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16  0x1b0b0
+				MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17  0x1b0b0
+				MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18  0x1b0b0
+				MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19  0x1b0b0
+				MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x1b0b0
+				MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC    0x1b0b0
+				MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC   0x1b0b0
+			>;
+		};
+
 		pinctrl_max7310: max7310grp {
 			fsl,pins = <
 				MX6QDL_PAD_SD2_DAT0__GPIO1_IO15 0x1b0b0