Re: [PATCH 0/8] ARM; OMAP2+: hwmod and SERIAL: Remove sysc handling from driver

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

 



On Wednesday 20 February 2013 05:21 PM, Russell King - ARM Linux wrote:
On Wed, Feb 20, 2013 at 03:53:22PM +0530, Santosh Shilimkar wrote:
Actually the clean-up will remove the serial driver dependency with
idle handling. Infact DMA support need not care about idle handling
anymore.

How is that so?  Looking back at the driver source when it did have full
DMA support shows that the handling of force idle state is different
between PIO and DMA modes.

For example, for transmit (which is the only case I had taken the time
to properly understand before the DMA code was unceremoniously ripped
out):

- On DMA transmit, the noidle setting is cleared.  runtime PM status is put.
- If we switch from DMA to PIO transmit, the noidle setting it set.
   runtime PM status is still put.
- When stopping transmit, if we aren't using DMA, idle is forced.
- In the runtime suspend, if we're using DMA and the i291 errata is in effect,
   then idle state is forced
- In the runtime resume, if we're using DMA and the i291 errata is in effect,
   idle state is cleared.

See - that information has been lost through ripping out the DMA code and
then subsequently cleaning up the code to make these things "invisible".
And now that you've lifted the forceidle/noidle functions out of the driver,
there's now even less clue about how to preserve the above behaviour.

I looked at the history based on above and indeed the i291 DMA
information got lost as part of cleanup. The UART DMA had a different requirement though the DMA errata is applicable to only OMAP3 devices and got fixed in subsequent OMAP based devices.

So perhaps we can make dma use conditional based on devices
*when* we add the tx DMA support. And the errata information
flag can be passed from DT files.

Therefore, tonight I am dropping and discarding what I have left over
from my work on getting DMA support working with the OMAP serial driver
again from the nightly test builds and my git tree, and I intend no
further involvement with this.

Please please don't do that. We were at a point where we are unable
to use UART has just simple console with DT without the $subject
series. We can help you if some re-basing is needed for your
patches because of the $subject series.

Actually, I've already dropped the TX DMA stuff out a while back when it
became (a) just too painful to keep porting the thing forward and (b) it
doesn't work properly anyway.  It's last update was back in October, and
was based on v3.6 because it already became impossible to bring it
forward across the utter buggeration of the OMAP serial driver.

(That explains why I only ever pulled forward two patches - those which
add the hooks into the serial core layer and into the OMAP serial driver
to cleanly allocate a DMA-able transmit buffer, leaving the rest of the
transmit DMA code to rot.)

Thanks for the information.

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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux