From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Hans de Goede <hdegoede@redhat.com>,
devicetree <devicetree@vger.kernel.org>
Cc: Tejun Heo <tj@kernel.org>,
Maxime Ripard <maxime.ripard@free-electrons.com>,
linux-ide@vger.kernel.org, Oliver Schinagl <oliver@schinagl.nl>,
Richard Zhu <Hong-Xing.Zhu@freescale.com>,
linux-sunxi@googlegroups.com, Lee Jones <lee.jones@linaro.org>,
linux-arm-kernel@lists.infradead.org,
Roger Quadros <rogerq@ti.com>
Subject: Re: [PATCH v7 08/15] ahci-imx: Port to library-ised ahci_platform
Date: Sat, 1 Mar 2014 11:24:24 +0000 [thread overview]
Message-ID: <20140301112424.GB21483@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <5311B8A8.1000501@redhat.com>
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.
next prev parent reply other threads:[~2014-03-01 11:24 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-22 15:53 (unknown), Hans de Goede
[not found] ` <1393084424-31099-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-02-22 15:53 ` [PATCH v7 01/15] libahci: Allow drivers to override start_engine Hans de Goede
2014-02-22 15:53 ` [PATCH v7 02/15] ahci-platform: Add support for devices with more then 1 clock Hans de Goede
2014-03-03 17:40 ` Bartlomiej Zolnierkiewicz
2014-02-22 15:53 ` [PATCH v7 03/15] ahci-platform: Add support for an optional regulator for sata-target power Hans de Goede
2014-02-22 15:53 ` [PATCH v7 04/15] ahci-platform: Add enable_ / disable_resources helper functions Hans de Goede
2014-02-22 15:53 ` [PATCH v7 05/15] ahci-platform: "Library-ise" ahci_probe functionality Hans de Goede
[not found] ` <1393084424-31099-6-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-03-03 18:38 ` Bartlomiej Zolnierkiewicz
2014-02-22 15:53 ` [PATCH v7 06/15] ahci-platform: "Library-ise" suspend / resume functionality Hans de Goede
2014-02-22 15:53 ` [PATCH v7 07/15] ARM: sunxi: Add support for Allwinner SUNXi SoCs sata to ahci_platform Hans de Goede
[not found] ` <1393084424-31099-8-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-02-22 20:40 ` Tejun Heo
2014-02-22 15:53 ` [PATCH v7 08/15] ahci-imx: Port to library-ised ahci_platform Hans de Goede
2014-02-28 21:08 ` Russell King - ARM Linux
[not found] ` <20140228210820.GZ21483-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2014-03-01 10:38 ` Hans de Goede
2014-03-01 11:24 ` Russell King - ARM Linux [this message]
[not found] ` <20140301112424.GB21483-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2014-03-01 12:54 ` Hans de Goede
[not found] ` <1393084424-31099-9-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-03-04 12:04 ` Bartlomiej Zolnierkiewicz
2014-02-22 15:53 ` [PATCH v7 09/15] ata: ahci_platform: Add DT compatible for Synopsis DWC AHCI controller Hans de Goede
2014-02-22 15:53 ` [PATCH v7 10/15] ata: ahci_platform: Update DT compatible list Hans de Goede
2014-02-22 15:53 ` [PATCH v7 11/15] ata: ahci_platform: Manage SATA PHY Hans de Goede
2014-02-22 15:53 ` [PATCH v7 12/15] ata: ahci_platform: runtime resume the device before use Hans de Goede
2014-02-22 15:53 ` [PATCH v7 13/15] ARM: sun4i: dt: Remove grouping + simple-bus compatible for regulators Hans de Goede
[not found] ` <1393084424-31099-14-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-02-22 21:44 ` Maxime Ripard
2014-02-23 8:03 ` Hans de Goede
[not found] ` <5309AB64.7010603-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-02-24 9:14 ` Maxime Ripard
2014-02-22 15:53 ` [PATCH v7 14/15] ARM: sun4i: dt: Add ahci / sata support Hans de Goede
2014-02-22 15:53 ` [PATCH v7 15/15] ARM: sun7i: " Hans de Goede
2014-02-22 16:26 ` [PATCH v7 00/15] ahci: library-ise ahci_platform, add sunxi driver and cleanup imx driver Hans de Goede
[not found] ` <5308CFC8.4020400-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-02-22 20:37 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140301112424.GB21483@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=Hong-Xing.Zhu@freescale.com \
--cc=devicetree@vger.kernel.org \
--cc=hdegoede@redhat.com \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-sunxi@googlegroups.com \
--cc=maxime.ripard@free-electrons.com \
--cc=oliver@schinagl.nl \
--cc=rogerq@ti.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).