Hi, We don't re-initialize the PHY. The code program some registers. Then, start the link training again via a hardreset. It is preferred that we don't goes and re-initialize the PHY. As an workaround, I can try the PHY re-init but from pass experience this doesn't work well. With regard to your comment on top post (and not familiar to your terminology), you don't want me to post something that the PHY framework does support yet? -Loc -Loc On Wed, Nov 13, 2013 at 1:31 AM, Kishon Vijay Abraham I <kishon@xxxxxx> wrote: > 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@xxxxxx> 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@xxxxxx> 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@xxxxxxxx> 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 >>>>> >>> > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
