[PATCH v18 3/4] ata: Add APM X-Gene SoC AHCI SATA host controller driver

Loc Ho lho at apm.com
Sun Mar 16 02:17:59 EDT 2014


Hi,

>> This patch adds support for the APM X-Gene SoC AHCI SATA host controller
>> driver. It requires the corresponding APM X-Gene SoC PHY driver. This
>> initial version only supports Gen3 speed.
>
> This version seems workable, thanks for the quick follow-up.
>
> The comment about Gen3 speed above reminds me that you took some
> shortcuts to get here and you removed support for some features
> as well as some bug workarounds in the process. I'm guessing some
> of them won't be necessary because they are only for prototype
> hardware or for early boot loader versions that don't yet set up
> the hardware right, but others actually need to come back.
>
> That is usually a good approach, but I'd also like to make sure we can
> deal with them nicely when you have to add them back later, and don't
> have to add ugly extensions to the DT binding to support the old dtb
> files.
>
> Can you list (also in the changelog) the parts of the driver that you
> have taken out for now and that you expect to add back at later
> stage? I think that would be helpful for perspective.
>

Here is an list of patches that we will be preparing for once the
basic driver is completed. Do you want me to re-generate the patch
change log with this info?

1. Support for Gen1/Gen2/Gen3
Solution: The simplest solution is to have the PHY framework support
setting the desire speed. I had argued with the TI folks but they are
reluctant to add this function to the framework. They argued that this
is still not generic enough. I will start the discussion again later
on. The other possibility (but not sure if this is doable) is to have
the PHY init function to be smarter and do the necessary operation
assuming the underlying PHY is capable in detecting the link up speed.
I will need to check the spec of this.

2. Retry COMRESET (hardreset) if failed first time
Solution: This code is purely in the host driver hardreset function.
It isn't for sure that we will need this. Given our current initial
board design, this seems to required 1 out of many, many power cycle
boot.

3. Cleaning the receiver line when SER_DISPARITY/SER_10B_8B error
during COMRESET (hardreset function call)
Solution: It is observed that during COMRESET, the receiver line can
report these errors and an clean up is required. For this, the code
will be with in the host driver and an call into the PHY layer. The
solution is the similar to #1 above.

4. IO flush before servicing completed operations (mostly read operations)
Solution: The read IO operations require an flush from the host
controller hardware side. For this, we will need to change the libahci
to call an function that is provided by the host driver if non-NULL.

5. PM (power management) support
Solution: Due to an errata in the host controller, stopping the
controller requires an slightly modified version in the way it detects
the host port completed the requested operation. For this we will have
to introduce an AHCI_HFLAG_XXX to detect the completion of FIS_RX
stopped by the CI register instead the PORT_CMD register or just delay
for 500ms.

> Regarding the support for multiple link speeds, how do you think
> it will be done?
> Can you have a driver-side link speed autoconfiguration,
> or do you have to add DT properties and let the driver know about
> the attached device?
>

See above #1.

-Loc



More information about the linux-arm-kernel mailing list