[v8,14/34] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
Commit Message
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
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
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
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
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
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
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
@@ -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