On Friday 23 May 2014 13:14:00 Murali Karicheri wrote:Arnd,
On 5/15/2014 12:14 PM, Arnd Bergmann wrote:Ok, good.
On Thursday 15 May 2014 12:01:30 Murali Karicheri wrote:The PCIE name needs to be dropped and as you correctly guessed, this SERDES
+static struct serdes_config ks_100mhz_pcie_5gbps_serdes[] = {It looks like the PHY is generic, but the configuration above is
+ {0x0000, 0x00000800, 0x0000ff00},
+ {0x0060, 0x00041c5c, 0x00ffffff},
+ {0x0064, 0x0343c700, 0xffffff00},
+ {0x006c, 0x00000012, 0x000000ff},
+ {0x0068, 0x00070000, 0x00ff0000},
+ {0x0078, 0x0000c000, 0x0000ff00},
PCI specific. If this is true, you should have #phy-cells=<1>
and document the possible modes, adding a lookup table here to
pick the configuration based on the argument. It's fine to just
implement pcie-5ghz initially, but the binding should list all
the modes that the PHY can support.
is generic.
Can you please check the phy drivers that we already have in linux-nextAlso, please list the exact name of the phy if you can find itUnfortunately there is a NDA restriction that prevents us from using the
out. You mention that you don't know the register descriptions,
but you should at least be able to let us know what phy this
is, in case some other SoC reuses the same thing.
actual Phy name and keystone phy is the name what we can usel at the
moment. I am checking
this with our IP team and if original name can be used, I will update
the driver to reflect the same.
to see if any of those are for the same hardware then?
I guess it's our best hope to catch duplications by inspecting all
other phy drivers as they get merged then.
Arnd