I've moved the devicetree mailing list to the To: header in case anyone
there wants to comment on this.
On Sat, Mar 01, 2014 at 11:38:32AM +0100, Hans de Goede wrote:
> I'm sure Tejun would welcome patches to add a dts property for
> setting the board-specific phy parameters, but I won't be
> writing it.
Don't worry, I already have something :)
>> I'm in two minds about this - whether to make the existing binding
>> with its compatible string always use these settings, and invent a
>> new compatible string for one which is fully configurable (as it
>> _should_ have been from the very start) or whether to make this
>> the default if the various properties aren't specified.
>
> IMHO this does not warrant doing a new compatibole-string. Simply
> default to the current hardcoded phy settings if no settings are
> specified through devicetree.
The problem is that we need to keep existing setups working - which
means when there's no properties specified, we need to default to the
settings hard-coded into the driver.
That means introducing properties like:
fsl,no-spread-spectrum
so that the hard-coded defaults can be turned off, and also deal with
a whole load of defaults for the other properties. That's not
particularly nice. Doing it this way, what I currently have is this:
struct reg_value {
u32 of_value;
u32 reg_value;
};
struct reg_property {
const char *name;
const struct reg_value *values;
size_t num_values;
u32 def_value;
u32 set_value;
};
static const struct reg_value gpr13_tx_level[] = {
{ 937, IMX6Q_GPR13_SATA_TX_LVL_0_937_V },
{ 947, IMX6Q_GPR13_SATA_TX_LVL_0_947_V },
...
{ 1230, IMX6Q_GPR13_SATA_TX_LVL_1_230_V },
{ 1240, IMX6Q_GPR13_SATA_TX_LVL_1_240_V }
};
static const struct reg_value gpr13_tx_boost[] = {
{ 0, IMX6Q_GPR13_SATA_TX_BOOST_0_00_DB },
{ 370, IMX6Q_GPR13_SATA_TX_BOOST_0_37_DB },
...
{ 528, IMX6Q_GPR13_SATA_TX_BOOST_5_28_DB },
{ 575, IMX6Q_GPR13_SATA_TX_BOOST_5_75_DB }
};
static const struct reg_value gpr13_tx_atten[] = {
{ 8, IMX6Q_GPR13_SATA_TX_ATTEN_8_16 },
{ 9, IMX6Q_GPR13_SATA_TX_ATTEN_9_16 },
...
{ 14, IMX6Q_GPR13_SATA_TX_ATTEN_14_16 },
{ 16, IMX6Q_GPR13_SATA_TX_ATTEN_16_16 },
};
static const struct reg_value gpr13_rx_eq[] = {
{ 500, IMX6Q_GPR13_SATA_RX_EQ_VAL_0_5_DB },
{ 1000, IMX6Q_GPR13_SATA_RX_EQ_VAL_1_0_DB },
...
{ 3500, IMX6Q_GPR13_SATA_RX_EQ_VAL_3_5_DB },
{ 4000, IMX6Q_GPR13_SATA_RX_EQ_VAL_4_0_DB },
};
static const struct reg_property gpr13_props[] = {
{
.name = "fsl,transmit-level-mV",
.values = gpr13_tx_level,
.num_values = ARRAY_SIZE(gpr13_tx_level),
.def_value = IMX6Q_GPR13_SATA_TX_LVL_1_025_V,
}, {
.name = "fsl,transmit-boost-mdB",
.values = gpr13_tx_boost,
.num_values = ARRAY_SIZE(gpr13_tx_boost),
.def_value = IMX6Q_GPR13_SATA_TX_BOOST_3_33_DB,
}, {
.name = "fsl,transmit-atten-16ths",
.values = gpr13_tx_atten,
.num_values = ARRAY_SIZE(gpr13_tx_atten),
.def_value = IMX6Q_GPR13_SATA_TX_ATTEN_9_16,
}, {
.name = "fsl,receive-eq-mdB",
.values = gpr13_rx_eq,
.num_values = ARRAY_SIZE(gpr13_rx_eq),
.def_value = IMX6Q_GPR13_SATA_RX_EQ_VAL_3_0_DB,
}, {
.name = "fsl,no-spread-spectrum",
.def_value = IMX6Q_GPR13_SATA_MPLL_SS_EN,
.set_value = 0,
},
};
and then a bunch of code to read through these tables and work out the
GPR13 register value from it - it doesn't handle everything yet because
I've not worked out a good way to do the last remaining three - I'm
thinking that they want to be strings:
regmap_update_bits(imxpriv->gpr, IOMUXC_GPR13,
IMX6Q_GPR13_SATA_RX_EQ_VAL_MASK |
...
IMX6Q_GPR13_SATA_TX_EDGE_RATE,
IMX6Q_GPR13_SATA_RX_LOS_LVL_SATA2M |
IMX6Q_GPR13_SATA_RX_DPLL_MODE_2P_4F |
IMX6Q_GPR13_SATA_SPD_MODE_3P0G |
reg_value);
RX_LOS_LVL: SATA1I / SATA1M / SATA1X / SATA2I / SATA2M / SATA2X
RX_DPLL_MODE: 1P_1F / 2P_2F / 1P_4F / 2P_4F
SPD_MODE: 3P0G / 1P5G (I do wonder whether this should be changed
when the Linux wants to slow the link speed.)
With a new compatible string, we can use the hard-coded version for
fsl,imx6q-ahci, but require all properties (with values) to be specified
for a different compatible string, thereby eliminating all the defaults,
and making things like "no-spread-spectrum" be a positive property instead
of negative, and this simplifies the parsing code.
There's also the obvious question about which of these properties should
be generic ones for AHCI/SATA interfaces... The only one I see with any
kind of electrical properties specified is sata_highbank:
- calxeda,tx-atten : a u32 array that contains TX attenuation override
codes, one per port. The upper 3 bytes are always
0 and thus ignored.
and that seems to be a register-coded value rather than an actual
attenuation figure.
A simpler solution to this would be to just provide an imx6-specific
property which encodes the GPR13 value directly, and not bother with
trying to provide individual properties.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
