[PATCH v2 3/5] ata: Add APM X-Gene SATA driver

[Kishon Vijay Abraham I]

Hi,

On Wednesday 13 November 2013 11:32 AM, Loc Ho wrote:
> Hi,
> 
> I need an method to tell the PHY layer to go to an specific speed -
> Gen2 or Gen1. Consider it is an limitation of our PHY. This is done
> after link up.

After changing the link speed, do you have to go through the entire re-init
sequence? I'm thinking if link speed should be modelled as an attribute of PHY
and allow the controller to set the link speed (phy_set_link_speed). After that
the controller should do the initialization sequence again by calling phy_init?
Open for suggestions though..

Please do not top post :-)

Thanks
Kishon
> 
> -Loc
> 
> On Tue, Nov 12, 2013 at 9:55 PM, Kishon Vijay Abraham I <kishon at ti.com> wrote:
>> Hi,
>>
>> On Wednesday 13 November 2013 11:03 AM, Loc Ho wrote:
>>> Hi,
>>>
>>> If I need to call a function into the PHY driver to say force an
>>> specific speed, how would one do this? I notice the USB have a bunch
>>
>> There are a bunch of *ops* currently available in the PHY framework which you
>> can use like phy_init, phy_exit, phy_power_on, phy_power_off. That should be
>> good enough IMO. If you need any other ops we can have a discussion here.
>>
>> Thanks
>> Kishon
>>> of functions. Would I need to introduce an structure for SATA as well
>>> that have a number of required functions that upper layer can call?
>>>
>>> -Loc
>>>
>>> On Tue, Nov 12, 2013 at 9:20 PM, Kishon Vijay Abraham I <kishon at ti.com> wrote:
>>>> Hi,
>>>>
>>>> On Wednesday 13 November 2013 04:09 AM, Loc Ho wrote:
>>>>> Hi Arnd,
>>>>>
>>>>> I looked at the PHY generic framework and come across this statement
>>>>> below. Our SATA PHY is embedded into the SoC. Should I ignore this
>>>>
>>>> Is your PHY embedded into the SoC or embedded into the SATA controller? If it's
>>>> within the SoC but not embedded into the SATA controller, you can use PHY
>>>> framework as the PHY is in a different IP and has a separate address space for
>>>> itself.
>>>> If it's within the SATA controller, then you might very well implement the PHY
>>>> logic in your SATA controller driver itself.
>>>>> statement below and implement the PHY driver using this framework?
>>>>>
>>>>> +This framework will be of use only to devices that use external PHY (PHY
>>>>> +functionality is not embedded within the controller).
>>>>
>>>> It means for PHYs embedded within the SATA controller and not within the SoC ;-)
>>>>
>>>> Thanks
>>>> Kishon
>>>>>
>>>>> -Loc
>>>>>
>>>>>
>>>>> On Tue, Nov 12, 2013 at 5:11 AM, Arnd Bergmann <arnd at arndb.de> wrote:
>>>>>> On Tuesday 12 November 2013, Loc Ho wrote:
>>>>>>> Hi Arnd/Olof,
>>>>>>>
>>>>>>> I looked over the phy code for USB and NET. There isn't such PHY
>>>>>>> infrastructure for SATA from what I can tell. It seems like I will
>>>>>>> need to put this all together. I am thinking about porting the USB
>>>>>>> version over (with changes for SATA) and put it under
>>>>>>> "./drivers/ata/phy". Any suggestion?
>>>>>>
>>>>>> Please have a look at the patches under the subject "Generic PHY Framework"
>>>>>> posted by Kishon Vijay Abraham. I thought they would have made it in
>>>>>> by now, but I have not followed the recent kernels closely since I am
>>>>>> on parental leave at the moment.
>>>>>>
>>>>>> IIRC they should unify USB, SATA and other PHY codes, but not network.
>>>>>>
>>>>>>         Arnd
>>>>
>>