Forcing PIO mode instead of DMA via DT property

[Aggrwal Poonam-B10812]

> -----Original Message-----
> From: Marek Vasut [mailto:marex at denx.de]
> Sent: Tuesday, July 24, 2012 9:48 AM
> To: Aggrwal Poonam-B10812
> Cc: Wolfgang Denk; devicetree-discuss at lists.ozlabs.org; pavel at denx.de
> Subject: Re: Forcing PIO mode instead of DMA via DT property
> 
> Dear Aggrwal Poonam-B10812,
> 
> > > -----Original Message-----
> > > From: Wolfgang Denk [mailto:wd at denx.de]
> > > Sent: Monday, July 23, 2012 11:18 AM
> > > To: Aggrwal Poonam-B10812
> > > Cc: Marek Vasut; devicetree-discuss at lists.ozlabs.org; pavel at denx.de
> > > Subject: Re: Forcing PIO mode instead of DMA via DT property
> > >
> > > Dear Poonam,
> > >
> > > In message <ACB6D0C0104CFF42A45A5D82A0DD4F3D079B4DAE at 039-SN2MPN1-
> > >
> > > 013.039d.mgd.msft.net> you wrote:
> > > > > I'm trying to implement a driver that can do both DMA and PIO,
> > > > > and it would be nice if the user was able to select the mode (on
> > > > > a per-bus
> > > > > basis) using the DT.
> > > > > The PIO mode can reduce the overhead in some cases and therefore
> > > > > be better choice than the DMA (for example when most transfers
> > > > > move only very few data, or when board-specific hardware
> > > > > properties kick
> > >
> > > in).
> > >
> > > > > I was thinking about using some "manf,use-pio" DT property, but
> > > > > I haven't found any such example yet, so I wonder if this is a
> > > > > good
> > >
> > > idea.
> > >
> > > > Not sure, but as far as I understand device tree is to publish the
> > > > hardware  capabilities, not the user choice/configuration.
> > > > One option would be to put a compile time flag in the driver,
> > > > which prefers  PIO than DMA.
> > > > I believe by default DMA is the first preference.
> > >
> > > We just had such a situation, where PIO had to be used on a specific
> > > bus, because due to a hardware problem (board design error) DMA
> > > would crash the system.  Yet the same driver/kernel would work fine
> > > with DMA on other buses / boards.  OK, this was on x86, so DT would
> > > not have helped, but I think a bus-specific property of being able
> > > to do DMA (or not) might indeed make sense for the DT.
> >
> > In that case probably we can use QUIRKS like broken-dma. I see this in
> > the sdhc driver in Linux. On P2020 chip(rev 1.0) of FSL DMA was broken
> > so we used this to force PIO.
> 
> Do you please happen to have any sample of such DT binding for reference?
Sorry cannot find the DT bindings in upstream, probably this issue was not there in P2020 Rev2.0 hence so.
I can cite a node from FSL old SDK
sdhci at 2e000 {
			compatible = "fsl,p2020-esdhc", "fsl,esdhc";
			reg = <0x2e000 0x1000>;
			interrupts = <72 0x2>;
			interrupt-parent = <&mpic>;
			fsl,sdhci-adjust-timeout;
			/* Filled in by U-Boot */
			clock-frequency = <0>;
		};



You can look at drivers/mmc/host/sdhci-of-esdhc.c which handles various quirks.

Regards
Poonam
> 
> Best regards,
> Marek Vasut