devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).