Re: [PATCH 13/17] ARM: dts: Add missing fdif node and binding for omap4

Hi Tony,

On Tuesday, 29 August 2017 17:29:42 EEST Tony Lindgren wrote:

* Laurent Pinchart [off-list ref] [170829 05:48]:

quoted

On Tuesday, 29 August 2017 00:19:14 EEST Tony Lindgren wrote:

quoted

On omap4 we're missing the fdif node with it's related "ti,hwmods"
property that the SoC interconnect code needs.

Note that this will only show up as a bug with "doesn't have
mpu register target base" boot errors when the legacy platform
data is removed.

...

quoted

quoted

--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti-fdif.txt

@@ -0,0 +1,37 @@
+Texas Instruments Face Detect (FDIF) binding
+
+FDD can be used for face detection on Texas Instruments SoCs.

Did you mean s/FDD/FDIF/ ?

Oops thanks for spotting that.

quoted

quoted

+Note that the fdif binding is currently only used by the SoC
interconnect
+code to idle the module on init and no open source driver is available
+for fdif. Please update this documentation if that changes.

Device tree bindings should be driver-agnostic. I don't think this
paragraph is needed.

OK will drop.

quoted

quoted

+Required properties:
+
+compatible: Shall be one of the following:
+	    "ti,omap4-fdif"
+
+reg: Shall contain the device instance IO range
+
+interrupts: Shall contain the device instance interrupt
+
+
+Optional properties:
+
+reg-names: Shall contain the IO range names if multiple IO
+	   ranges are used by the SoC

Is this ever the case on OMAP4 ? If not you can drop this property.

Oh right, that's only for audio related devices in the abe l4
instance. Will drop.

quoted

quoted

+ti,hwmods: Shall contain the TI interconnect module name if needed
+	   by the SoC

Are there SoCs that don't need this ?

DaVinci or Keystone maybe? And I do have patches coming that will
remove the need for "ti,hwmods" but that's still maybe 200 patches
away or something..

That would be amazing :-)

quoted

quoted

+Example:
+
+	fdif: fdif@4a10a000 {
+		compatible = "ti,omap4-fdif";
+		reg = <0x4a10a000 0x200>;
+		interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
+		ti,hwmods = "fdif";
+	};
+

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi

@@ -864,6 +864,13 @@
 			};
 		};

+		fdif: fdif@4a10a000 {
+			compatible = "ti,omap4-fdif";
+			reg = <0x4a10a000 0x200>;

According to the OMAP4460 datasheet the register range is 0x390 bytes
long.

OK we have it wrong in the legacy platform data then. And the module
size is 0x1000 in the hardware, so I'll use that.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

* Laurent Pinchart [off-list ref] [170829 10:13]:

On Tuesday, 29 August 2017 17:29:42 EEST Tony Lindgren wrote:

quoted

quoted

Are there SoCs that don't need this ?

DaVinci or Keystone maybe? And I do have patches coming that will
remove the need for "ti,hwmods" but that's still maybe 200 patches
away or something..

That would be amazing :-)

Yeah.. FYI, the way to get there is to have a generic interonnect
target agent driver for the module, then have the device ip
instance(s) just be children of the interconnect target. But
it will be a while until I can start posting those patches.

Until that's available, we can have minimal device specific
interconnect target module drivers just like we have
drivers/usb/musb/musb_am335x.c. That's the parent for two
musb instances and one cppi41 dma instance. See also the
related "usb@47400000" node in am33xx.dtsi and it's children.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html