Re: [PATCH 11/17] ARM: dts: Add missing mcasp node for omap4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




* Peter Ujfalusi <peter.ujfalusi@xxxxxx> [170830 22:48]:
> On 2017-08-30 18:19, Tony Lindgren wrote:
> > 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
> > @@ -775,6 +775,15 @@
> >  			status = "disabled";
> >  		};
> >  
> > +		mcasp: mcasp@40128000 {
> > +			compatible = "ti,omap4-mcasp-audio";
> > +			reg = <0x40128000 0x400>, /* MPU private access */
> > +			      <0x49028000 0x400>; /* L3 Interconnect */
> > +			reg-names = "mpu", "dma";
> > +			interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
> > +			ti,hwmods = "mcasp";
> > +		};
> 
> I would not do this. We don't support the NcASP on OMAP4 or OMAP5 for
> that matter.
> In theory it is the same IP as found in other SoCs, but in OMAP4 the TX
> path is disabled and (in theory) the i2s support is also a thing which
> is not supported - only DIT mode.
> We do not even have any hardware where it can be tested (Galaxy Nexus
> uses McASP for S/PDIF output when it is docked.
> For Android we have had omap-mcasp driver, but it is not upstream and is
> never will as if we are going to support McASP it should be done via the
> davinci-mcasp driver.

OK

> By adding the node we might give the impression that McASP on OMAP4/5 is
> usable, which is not.

OK. Yeah we need to make sure this is for the interconnect
target module, and not for it's child device(s) mcasp.

> On the other hand, the DT describes the HW, so it should be OK to add
> all peripherals even if there is no driver to support it. In this case
> the status = "disabled"; must be there.

Yeah well this is for the interconnect target module that we are
already accessing during init to idle it. But it's actually the
children of this node that should have the status = "disabled"!

I think we can solve your concernd by adding the generic minimal
binding and compatible properites for the interconnect target
module for which I already posted an RFC a while back.

So we can just use compatibles "ti,sysc-type1", "ti,sysc-type2"
and "ti,sysc-type3" as are going to need those anyways soonish.

So the McASP interconnect target module would just become:

	target_module@40128000 {
		compatible = "ti,sysc-type2";
		reg = <0x40128000 0x400>, /* MPU private access */
		      <0x49028000 0x400>; /* L3 Interconnect */
		reg-names = "mpu", "dma";
		ti,hwmods = "mcasp";
	};

And if there ever is a McASP driver, it can be a child of
this node. And eventually we will just drop ti,hwmods too.

Regards,

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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux