| Message ID | 20170828211918.11573-14-tony@atomide.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Tony, Thank you for the patch. On Tuesday, 29 August 2017 00:19:14 EEST Tony Lindgren wrote: > 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. > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> > Cc: Mauro Carvalho Chehab <mchehab@kernel.org> > Cc: Sakari Ailus <sakari.ailus@iki.fi> > Signed-off-by: Tony Lindgren <tony@atomide.com> > --- > .../devicetree/bindings/media/ti-fdif.txt | 37 +++++++++++++++++++ > arch/arm/boot/dts/omap4.dtsi | 7 ++++ > 2 files changed, 44 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/ti-fdif.txt > > diff --git a/Documentation/devicetree/bindings/media/ti-fdif.txt > b/Documentation/devicetree/bindings/media/ti-fdif.txt new file mode 100644 > --- /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/ ? > +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. > +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. > +ti,hwmods: Shall contain the TI interconnect module name if needed > + by the SoC Are there SoCs that don't need this ? > +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. > + interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>; > + ti,hwmods = "fdif"; > + }; > + > timer1: timer@4a318000 { > compatible = "ti,omap3430-timer"; > reg = <0x4a318000 0x80>;
* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [170829 05:48]: > On Tuesday, 29 August 2017 00:19:14 EEST Tony Lindgren wrote: > > 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. ... > > --- /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. > > +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. > > +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. > > +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.. > > +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, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Tony, On Tuesday, 29 August 2017 17:29:42 EEST Tony Lindgren wrote: > * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [170829 05:48]: > > On Tuesday, 29 August 2017 00:19:14 EEST Tony Lindgren wrote: > >> 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. > > ... > > >> --- /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. > > >> +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. > > >> +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. > > >> +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 :-) > >> +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.
* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [170829 10:13]: > On Tuesday, 29 August 2017 17:29:42 EEST Tony Lindgren wrote: > > > 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 linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/media/ti-fdif.txt b/Documentation/devicetree/bindings/media/ti-fdif.txt new file mode 100644 --- /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. + +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. + + +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 + +ti,hwmods: Shall contain the TI interconnect module name if needed + by the SoC + + +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>; + interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>; + ti,hwmods = "fdif"; + }; + timer1: timer@4a318000 { compatible = "ti,omap3430-timer"; reg = <0x4a318000 0x80>;
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. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Sakari Ailus <sakari.ailus@iki.fi> Signed-off-by: Tony Lindgren <tony@atomide.com> --- .../devicetree/bindings/media/ti-fdif.txt | 37 ++++++++++++++++++++++ arch/arm/boot/dts/omap4.dtsi | 7 ++++ 2 files changed, 44 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/ti-fdif.txt