Forcing PIO mode instead of DMA via DT property

Forcing PIO mode instead of DMA via DT property

[Marek Vasut]

Hi guys,

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.

What is your suggestion how I shoud address such a problem?

Thanks in advance!

Best regards,
Marek Vasut

RE: Forcing PIO mode instead of DMA via DT property

[Aggrwal Poonam-B10812]

> -----Original Message-----
> From: devicetree-discuss [mailto:devicetree-discuss-
> bounces+poonam.aggrwal=freescale.com-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org] On Behalf Of Marek
> Vasut
> Sent: Monday, July 23, 2012 2:58 AM
> To: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> Cc: pavel-ynQEQJNshbs@public.gmane.org; Wolfgang Denk
> Subject: Forcing PIO mode instead of DMA via DT property
> 
> Hi guys,
> 
> 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.

Regards
Poonam
> 
> What is your suggestion how I shoud address such a problem?
> 
> Thanks in advance!
> 
> Best regards,
> Marek Vasut
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: Forcing PIO mode instead of DMA via DT property

[Marek Vasut]

Dear Aggrwal Poonam-B10812,

> > -----Original Message-----
> > From: devicetree-discuss [mailto:devicetree-discuss-
> > bounces+poonam.aggrwal=freescale.com-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org] On Behalf Of Marek
> > Vasut
> > Sent: Monday, July 23, 2012 2:58 AM
> > To: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> > Cc: pavel-ynQEQJNshbs@public.gmane.org; Wolfgang Denk
> > Subject: Forcing PIO mode instead of DMA via DT property
> > 
> > Hi guys,
> > 
> > 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.

This might actually be one of the things I've been missing about DT, so thanks 
for stating that clearly :-)

> 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.

Certainly, but please consider you might want to use PIO only on selected 
instances of the driver (aka. selected busses, I wasn't probably clear enough, 
this is a bus driver), not degrade performance on all of them. Possibly due to a 
specific hardware wiring of the particular system.

> Regards
> Poonam

Best regards,
Marek Vasut

Re: Forcing PIO mode instead of DMA via DT property

[Varun Wadekar]

>> 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.
> Certainly, but please consider you might want to use PIO only on selected
> instances of the driver (aka. selected busses, I wasn't probably clear enough,
> this is a bus driver), not degrade performance on all of them. Possibly due to a
> specific hardware wiring of the particular system.
>

Device Trees are a replacement for board files. If your board uses PIO 
mode due to some hardware limitations, then you need to specify this in 
the .dt for that board. The driver should then just query this property 
and proceed with its init.

Regards,
Varun

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

RE: Forcing PIO mode instead of DMA via DT property

[Aggrwal Poonam-B10812]

> -----Original Message-----
> From: devicetree-discuss [mailto:devicetree-discuss-
> bounces+poonam.aggrwal=freescale.com-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org] On Behalf Of Marek
> Vasut
> Sent: Monday, July 23, 2012 9:01 AM
> To: Aggrwal Poonam-B10812
> Cc: pavel-ynQEQJNshbs@public.gmane.org; devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; Wolfgang Denk
> Subject: Re: Forcing PIO mode instead of DMA via DT property
> 
> Dear Aggrwal Poonam-B10812,
> 
> > > -----Original Message-----
> > > From: devicetree-discuss [mailto:devicetree-discuss-
> > > bounces+poonam.aggrwal=freescale.com-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org] On Behalf Of
> > > bounces+Marek
> > > Vasut
> > > Sent: Monday, July 23, 2012 2:58 AM
> > > To: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> > > Cc: pavel-ynQEQJNshbs@public.gmane.org; Wolfgang Denk
> > > Subject: Forcing PIO mode instead of DMA via DT property
> > >
> > > Hi guys,
> > >
> > > 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.
> 
> This might actually be one of the things I've been missing about DT, so
> thanks for stating that clearly :-)
> 
> > 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.
> 
> Certainly, but please consider you might want to use PIO only on selected
> instances of the driver (aka. selected busses, I wasn't probably clear
> enough, this is a bus driver), not degrade performance on all of them.
> Possibly due to a specific hardware wiring of the particular system.
Okay, if the choice to use PIO is for a specific controller(bus) because of hardware reasons, may be device tree could be a place.
But if it is simply that the user wants PIO mode for reasons like "less bytes to transfer" then device tree may not be the right place.

Regards
Poonam

> 
> > Regards
> > Poonam
> 
> Best regards,
> Marek Vasut
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: Forcing PIO mode instead of DMA via DT property

[Wolfgang Denk]

Dear Poonam,

In message <ACB6D0C0104CFF42A45A5D82A0DD4F3D079B4DAE-RL0Hj/+nBVDYdknt8GnhQq4g8xLGJsHaLnY5E4hWTkheoWH0uzbU5w@public.gmane.org> 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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd-ynQEQJNshbs@public.gmane.org
"I haven't lost my mind - it's backed up on tape somewhere."

RE: Forcing PIO mode instead of DMA via DT property

[Aggrwal Poonam-B10812]

> -----Original Message-----
> From: Wolfgang Denk [mailto:wd-ynQEQJNshbs@public.gmane.org]
> Sent: Monday, July 23, 2012 11:18 AM
> To: Aggrwal Poonam-B10812
> Cc: Marek Vasut; devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; pavel-ynQEQJNshbs@public.gmane.org
> Subject: Re: Forcing PIO mode instead of DMA via DT property
> 
> Dear Poonam,
> 
> In message <ACB6D0C0104CFF42A45A5D82A0DD4F3D079B4DAE@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.

Regards
Poonam
> 
> Best regards,
> 
> Wolfgang Denk
> 
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd-ynQEQJNshbs@public.gmane.org "I
> haven't lost my mind - it's backed up on tape somewhere."

Re: Forcing PIO mode instead of DMA via DT property

[Marek Vasut]

Dear Aggrwal Poonam-B10812,

> > -----Original Message-----
> > From: Wolfgang Denk [mailto:wd-ynQEQJNshbs@public.gmane.org]
> > Sent: Monday, July 23, 2012 11:18 AM
> > To: Aggrwal Poonam-B10812
> > Cc: Marek Vasut; devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; pavel-ynQEQJNshbs@public.gmane.org
> > Subject: Re: Forcing PIO mode instead of DMA via DT property
> > 
> > Dear Poonam,
> > 
> > In message <ACB6D0C0104CFF42A45A5D82A0DD4F3D079B4DAE@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?

Best regards,
Marek Vasut

Re: Forcing PIO mode instead of DMA via DT property

[Arnd Bergmann]

On Sunday 22 July 2012, Marek Vasut 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.
> 

What kind of device is this? We are currently working on the dmaengine
binding, so an easy way to do this would be (one that binding is complete)
to either provide or not provide the channel description depending on
what you want to do with the device. This is clearly a hack but might
fit your use case without adding any ugly code to the kernel.

Another option would be to make it a runtime configuration option,
e.g. through sysfs, but that again depends a lot on what device you
are talking about.

	Arnd

Re: Forcing PIO mode instead of DMA via DT property

[Wolfgang Denk]

Dear Arnd,

In message <201207241319.45101.arnd-r2nGTMty4D4@public.gmane.org> 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.
> > 
> 
> What kind of device is this? We are currently working on the dmaengine
> binding, so an easy way to do this would be (one that binding is complete)
> to either provide or not provide the channel description depending on
> what you want to do with the device. This is clearly a hack but might
> fit your use case without adding any ugly code to the kernel.
> 
> Another option would be to make it a runtime configuration option,
> e.g. through sysfs, but that again depends a lot on what device you
> are talking about.

At least in my example of the x86 system a sysfs interface would not
help, as the kernel would crash during bootup before I can run user
space code.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd-ynQEQJNshbs@public.gmane.org
Mirrors should reflect a little before throwing back images.
- Jean Cocteau

RE: Forcing PIO mode instead of DMA via DT property

[Aggrwal Poonam-B10812]

> -----Original Message-----
> From: Marek Vasut [mailto:marex-ynQEQJNshbs@public.gmane.org]
> Sent: Tuesday, July 24, 2012 9:48 AM
> To: Aggrwal Poonam-B10812
> Cc: Wolfgang Denk; devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; pavel-ynQEQJNshbs@public.gmane.org
> Subject: Re: Forcing PIO mode instead of DMA via DT property
> 
> Dear Aggrwal Poonam-B10812,
> 
> > > -----Original Message-----
> > > From: Wolfgang Denk [mailto:wd-ynQEQJNshbs@public.gmane.org]
> > > Sent: Monday, July 23, 2012 11:18 AM
> > > To: Aggrwal Poonam-B10812
> > > Cc: Marek Vasut; devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; pavel-ynQEQJNshbs@public.gmane.org
> > > Subject: Re: Forcing PIO mode instead of DMA via DT property
> > >
> > > Dear Poonam,
> > >
> > > In message <ACB6D0C0104CFF42A45A5D82A0DD4F3D079B4DAE@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@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

Re: Forcing PIO mode instead of DMA via DT property

[Mitch Bradley]

On 7/24/2012 7:35 AM, Wolfgang Denk wrote:
> Dear Arnd,
> 
> In message <201207241319.45101.arnd-r2nGTMty4D4@public.gmane.org> 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.

I think it's okay to have such a property, especially in the case where
there are
specific hardware reasons for choosing PIO on that bus.

It would be even better to have a property that describes the specific
hardware
situation that leads to the conclusion.  The conclusion is "use PIO",
whereas the
situation might be "expected transfer length = 4".  Some such
"situations" might
apply to specific slaves, and thus might better be described in a child
node, with
the information processed in the child driver and passed to the bus
driver through
a callback - but that probably has tricky API implications.

The thing to avoid is properties that can't easily be tied to some
objectively-true
aspect of the system.

Write down what it is that causes the choice, then consider describing
that in
a property, letting the driver make the final decision based on that
information.


>>>
>>
>> What kind of device is this? We are currently working on the dmaengine
>> binding, so an easy way to do this would be (one that binding is complete)
>> to either provide or not provide the channel description depending on
>> what you want to do with the device. This is clearly a hack but might
>> fit your use case without adding any ugly code to the kernel.
>>
>> Another option would be to make it a runtime configuration option,
>> e.g. through sysfs, but that again depends a lot on what device you
>> are talking about.
> 
> At least in my example of the x86 system a sysfs interface would not
> help, as the kernel would crash during bootup before I can run user
> space code.
> 
> Best regards,
> 
> Wolfgang Denk
> 

Mis-wrapped text

[Mitch Bradley]

I want to apologize to everybody for my hard-to-read
text that is improperly word-wrapped.  I keep trying
to find Thunderbird settings that will Do The Right Thing,
but so far have been stymied.

Re: Forcing PIO mode instead of DMA via DT property

[Marek Vasut]

Dear Aggrwal Poonam-B10812,

[...]

> > > > 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@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.

Ok, so you suggest we add such a property or what is the conclusion please?

Best regards,
Marek Vasut