From: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH 03/11] mmc: Add support for Qualcomm SDHCI controller
Date: Wed, 16 Dec 2015 23:46:48 +0100 [thread overview]
Message-ID: <5671E9D8.8050009@gmail.com> (raw)
In-Reply-To: <CAPnjgZ2y5BMPArwTTjV13T=Otd9uz3=qKd0ASGGCDUULvU0SFg@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Simon,
On 15.12.2015 19:58, Simon Glass wrote:
> Hi Mateusz,
>
> On 10 December 2015 at 14:41, Mateusz Kulikowski
> <mateusz.kulikowski@gmail.com> wrote:
[...]
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +static int msm_sdc_clk_init(struct udevice *dev)
>> +{
>> + uint clk_rate = fdtdec_get_uint(gd->fdt_blob, dev->of_offset,
>> + "clock-frequency", 400000);
>> + uint clkd[2]; /* clk_id and clk_no */
>> + fdtdec_get_int_array(gd->fdt_blob, dev->of_offset, "clock", clkd, 2);
>> + clkd[0] = fdt_node_offset_by_phandle(gd->fdt_blob, clkd[0]);
>> +
>> + struct udevice *clk = NULL;
>> + uclass_get_device_by_of_offset(UCLASS_CLK, clkd[0], &clk);
>> + if (clk)
>> + clk_set_periph_rate(clk, clkd[1], clk_rate);
>> +
>
> See comments on the previous patch. Also you could move the DT decode
> code all into your ofdata_to_platdata function (if you like).
But requesting clock must be handled in probe (i.e. when clock is
already bound) right?
>
>> + return 0;
>> +}
>> +
>> +static int msm_sdc_probe(struct udevice *dev)
>> +{
>> + struct msm_sdhc *prv = dev_get_priv(dev);
>> + struct sdhci_host *host = &prv->host;
>> + u32 core_version, core_minor, core_major;
>> +
>> + host->quirks = SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_BROKEN_R1B;
>> +
>> + /* Init clocks */
>> + if (msm_sdc_clk_init(dev))
>> + return -EIO;
>> +
>> + /* Reset the core and Enable SDHC mode */
>> + writel(readl(prv->base + SDCC_MCI_POWER) | SDCC_MCI_POWER_SW_RST,
>> + prv->base + SDCC_MCI_POWER);
>> +
>> + /* SW reset can take upto 10HCLK + 15MCLK cycles. (min 40us) */
>> + mdelay(2);
>
> So why such a long delay? Perhaps you should put the code immediately
> below int a timeout loop?
>
> start = get_timer(0);
> while (readl...) {
> if (get_timer(start) > 2)
> return -ETIMEDOUT;
> }
>
I'm not sure if I can do that - I can test it, perhaps it will even work on
my board, but it was put explicitly in Linux driver (1-5ms delay).
Documentation says:
"SW should wait until bit 0 (MCLK_REG_WR_ACTIVE) of MCI_STATUS2 register
is 0, after writing to MCI_POWER register and before accessing this
register again."
But this applies to all writes, not to reset request - I'm not sure
how MCI_STATUS2 will behave during reset (it may get zeroed earlier).
Do you really think I should try to decrease this delay?
[...]
>> +}
>> +
>> +static int msm_ofdata_to_platdata(struct udevice *dev)
>> +{
>> + struct msm_sdhc *priv = dev_get_priv(dev);
>> + struct sdhci_host *host = &priv->host;
>> +
>> + host->name = strdup(dev->name);
>> + host->ioaddr = (void *)dev_get_addr(dev);
>> + host->bus_width = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
>> + "bus-width", 4);
>> + host->index = fdtdec_get_uint(gd->fdt_blob, dev->of_offset, "index", 0);
>> + priv->base = fdtdec_get_addr_size_auto_parent(gd->fdt_blob,
>> + dev->parent->of_offset,
>> + dev->of_offset, "reg",
>> + 1, NULL);
>
> Odd that you are reading the second cell. How come?
I tried to use as much parts of original qcom Linux dts as possible.
For mmc controller, there are 2 addresses needed:
- - SDCC base (i.e. base of IP block with vendor-specific regs etc.)
- - SDHCI base (i.e. place where SDHCI "standard" registers start)
My assumption is that SDHCI offset may be different on different
SoCs, and wanted to have generic driver.
[...]
Regards,
Mateusz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWcenTAAoJELvtohmVtQzBddYH+waGw+OePJ8MdeMgI8BYJ295
3l+Op/2FGquWNIIoJRlO59JOeZqVkJJWOph19DQWpmybIra1HoRRmVTVqY2l2Fon
vTdzZ+cZ3jY2bzLGzYARXCEJ4jNxUILkPS/r/SrRfhDVC4vxSROSA7Jh6EmnssDm
kktzR98/o834uDQc0niGWYi9K1hpUnwQ3m8b1e8LmwdH3LcuHH7+UWntTnEesBai
Ox3ES6y5S9VtCBnyZ/LSilqe30AVB4ccKlk69G41AQYPI5u5CZEfm1OP8AGjpkfV
0D4WrErh/CGmYpG0b4G14CYe39GekCmD9IAnMC4zxjRwwZCmp1kGoeunNwpiLjk=
=scwU
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2015-12-16 22:46 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-10 21:41 [U-Boot] [RFC PATCH 00/11] Add support for 96boards Dragonboard410C board Mateusz Kulikowski
2015-12-10 21:41 ` [U-Boot] [RFC PATCH 01/11] serial: Add support for Qualcomm serial port Mateusz Kulikowski
2015-12-15 18:58 ` Simon Glass
2015-12-16 22:19 ` Mateusz Kulikowski
2015-12-21 6:50 ` Masahiro Yamada
2015-12-22 20:23 ` Simon Glass
2015-12-23 3:52 ` Masahiro Yamada
2015-12-27 16:51 ` Mateusz Kulikowski
2015-12-28 17:09 ` Masahiro Yamada
2015-12-28 4:29 ` Simon Glass
2015-12-28 17:13 ` Masahiro Yamada
2015-12-10 21:41 ` [U-Boot] [RFC PATCH 02/11] gpio: Add support for Qualcomm gpio controller Mateusz Kulikowski
2015-12-15 18:58 ` Simon Glass
2015-12-10 21:41 ` [U-Boot] [RFC PATCH 03/11] mmc: Add support for Qualcomm SDHCI controller Mateusz Kulikowski
2015-12-15 18:58 ` Simon Glass
2015-12-16 22:46 ` Mateusz Kulikowski [this message]
2015-12-18 22:41 ` Simon Glass
2015-12-19 11:21 ` Mateusz Kulikowski
2015-12-10 21:41 ` [U-Boot] [RFC PATCH 04/11] ehci-hcd: Add init_after_reset Mateusz Kulikowski
2015-12-10 23:14 ` Marek Vasut
2015-12-16 22:30 ` Tom Rini
2015-12-10 21:41 ` [U-Boot] [RFC PATCH 05/11] ehci: Add support for Qualcomm EHCI Mateusz Kulikowski
2015-12-10 23:22 ` Marek Vasut
2015-12-13 12:38 ` Mateusz Kulikowski
2015-12-13 15:48 ` Marek Vasut
2015-12-16 22:51 ` Mateusz Kulikowski
2015-12-10 21:41 ` [U-Boot] [RFC PATCH 06/11] drivers: Add SPMI bus uclass Mateusz Kulikowski
2015-12-15 18:58 ` Simon Glass
2015-12-16 23:09 ` Mateusz Kulikowski
2015-12-10 21:41 ` [U-Boot] [RFC PATCH 07/11] drivers: spmi: Add support for Qualcomm SPMI bus driver Mateusz Kulikowski
2015-12-10 21:41 ` [U-Boot] [RFC PATCH 08/11] pmic: Add support for Qualcomm PM8916 PMIC Mateusz Kulikowski
2015-12-15 18:58 ` Simon Glass
2015-12-10 21:41 ` [U-Boot] [RFC PATCH 09/11] gpio: Add support for Qualcomm PM8916 gpios Mateusz Kulikowski
2015-12-15 18:58 ` Simon Glass
2015-12-10 21:41 ` [U-Boot] [RFC PATCH 10/11] arm: Add support for Qualcomm Snapdragon family Mateusz Kulikowski
2015-12-16 22:29 ` Simon Glass
2015-12-19 12:12 ` Mateusz Kulikowski
2015-12-10 21:41 ` [U-Boot] [RFC PATCH 11/11] board: Add Qualcomm Dragonboard 410C support Mateusz Kulikowski
2015-12-16 22:29 ` Simon Glass
2015-12-19 12:24 ` Mateusz Kulikowski
2015-12-19 20:29 ` Simon Glass
2015-12-15 18:57 ` [U-Boot] [RFC PATCH 00/11] Add support for 96boards Dragonboard410C board sk.syed2
2015-12-15 21:25 ` Mateusz Kulikowski
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=5671E9D8.8050009@gmail.com \
--to=mateusz.kulikowski@gmail.com \
--cc=u-boot@lists.denx.de \
/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