From: Mark Rutland <mark.rutland@arm.com>
To: Georgi Djakov <gdjakov@mm-sol.com>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"cjb@laptop.org" <cjb@laptop.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"grant.likely@linaro.org" <grant.likely@linaro.org>,
"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
Pawel Moll <Pawel.Moll@arm.com>,
"swarren@wwwdotorg.org" <swarren@wwwdotorg.org>,
"ijc+devicetree@hellion.org.uk" <ijc+devicetree@hellion.org.uk>,
"galak@codeaurora.org" <galak@codeaurora.org>,
"rob@landley.net" <rob@landley.net>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
"subhashj@codeaurora.org" <subhashj@codeaurora.org>
Subject: Re: [PATCH v7 2/2] mmc: sdhci-msm: Initial support for MSM chipsets
Date: Thu, 5 Dec 2013 10:27:40 +0000 [thread overview]
Message-ID: <20131205102740.GI29200@e106331-lin.cambridge.arm.com> (raw)
In-Reply-To: <1383753405-23631-3-git-send-email-gdjakov@mm-sol.com>
On Wed, Nov 06, 2013 at 03:56:45PM +0000, Georgi Djakov wrote:
> This platform driver adds the initial support of Secure
> Digital Host Controller Interface compliant controller
> found in Qualcomm MSM chipsets.
>
> Signed-off-by: Georgi Djakov <gdjakov@mm-sol.com>
> ---
> drivers/mmc/host/Kconfig | 13 +
> drivers/mmc/host/Makefile | 1 +
> drivers/mmc/host/sdhci-msm.c | 651 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 665 insertions(+)
> create mode 100644 drivers/mmc/host/sdhci-msm.c
[...]
> +static int sdhci_msm_dt_parse_vreg_info(struct device *dev,
> + struct sdhci_msm_reg_data *vreg,
> + const char *vreg_name)
> +{
> + int len;
> + const __be32 *prop;
Seeing raw property handling in drivers worries me. If there's a reason
to touch the raw DTB we should add helpers to do it rather than leaking
binary format issues into drivers.
> + char prop_name[MAX_PROP_SIZE];
> + struct device_node *np = dev->of_node;
> +
> + snprintf(prop_name, MAX_PROP_SIZE, "%s-supply", vreg_name);
> + if (!of_parse_phandle(np, prop_name, 0)) {
> + dev_info(dev, "No vreg data found for %s\n", vreg_name);
> + return -EINVAL;
> + }
> +
> + vreg->name = vreg_name;
> +
> + snprintf(prop_name, MAX_PROP_SIZE, "qcom,%s-lpm-sup", vreg_name);
> + if (of_get_property(np, prop_name, NULL))
> + vreg->lpm_sup = true;
> +
> + snprintf(prop_name, MAX_PROP_SIZE, "qcom,%s-voltage-level", vreg_name);
> + prop = of_get_property(np, prop_name, &len);
> + if (!prop || (len != (2 * sizeof(__be32)))) {
> + dev_warn(dev, "%s %s property\n",
> + prop ? "invalid format" : "no", prop_name);
> + } else {
> + vreg->low_vol_level = be32_to_cpup(&prop[0]);
> + vreg->high_vol_level = be32_to_cpup(&prop[1]);
> + }
You can use of_property_read_u32_array here.
> +
> + snprintf(prop_name, MAX_PROP_SIZE, "qcom,%s-current-level", vreg_name);
> + prop = of_get_property(np, prop_name, &len);
> + if (!prop || (len != (2 * sizeof(__be32)))) {
> + dev_warn(dev, "%s %s property\n",
> + prop ? "invalid format" : "no", prop_name);
> + } else {
> + vreg->lpm_uA = be32_to_cpup(&prop[0]);
> + vreg->hpm_uA = be32_to_cpup(&prop[1]);
> + }
Likewise.
[...]
> + /*
> + * CORE_SW_RST above may trigger power irq if previous status of PWRCTL
> + * was either BUS_ON or IO_HIGH_V. So before we enable the power irq
> + * interrupt in GIC (by registering the interrupt handler), we need to
> + * ensure that any pending power irq interrupt status is acknowledged
> + * otherwise power irq interrupt handler would be fired prematurely.
> + */
> + irq_status = readl_relaxed(msm_host->core_mem + CORE_PWRCTL_STATUS);
> + writel_relaxed(irq_status, (msm_host->core_mem + CORE_PWRCTL_CLEAR));
> + irq_ctl = readl_relaxed(msm_host->core_mem + CORE_PWRCTL_CTL);
> + if (irq_status & (CORE_PWRCTL_BUS_ON | CORE_PWRCTL_BUS_OFF))
> + irq_ctl |= CORE_PWRCTL_BUS_SUCCESS;
> + if (irq_status & (CORE_PWRCTL_IO_HIGH | CORE_PWRCTL_IO_LOW))
> + irq_ctl |= CORE_PWRCTL_IO_SUCCESS;
> + writel_relaxed(irq_ctl, (msm_host->core_mem + CORE_PWRCTL_CTL));
> + /*
> + * Ensure that above writes are propogated before interrupt enablement
> + * in GIC.
> + */
> + mb();
Does this guarantee that the device has finished responding to the write
and deasserted the interrupt line (i.e. does the device only acknowledge
the write once that is true)?
Thanks,
Mark.
next prev parent reply other threads:[~2013-12-05 10:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-06 15:56 [PATCH v7 0/2] mmc: sdhci-msm: Add support for MSM chipsets Georgi Djakov
2013-11-06 15:56 ` [PATCH v7 1/2] mmc: sdhci-msm: Initial SDHCI MSM driver documentation Georgi Djakov
2013-12-05 9:52 ` Mark Rutland
2013-12-06 11:59 ` Georgi Djakov
2013-12-09 9:38 ` Mark Rutland
2014-01-30 17:07 ` Georgi Djakov
2013-11-06 15:56 ` [PATCH v7 2/2] mmc: sdhci-msm: Initial support for MSM chipsets Georgi Djakov
2013-12-05 10:27 ` Mark Rutland [this message]
2013-12-06 12:02 ` Georgi Djakov
2013-12-09 9:46 ` Mark Rutland
2014-01-30 17:13 ` Georgi Djakov
2013-12-09 17:00 ` Courtney Cavin
2014-01-30 17:21 ` Georgi Djakov
2014-01-31 17:31 ` Courtney Cavin
2013-11-14 10:18 ` [PATCH v7 0/2] mmc: sdhci-msm: Add " Ivan T. Ivanov
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=20131205102740.GI29200@e106331-lin.cambridge.arm.com \
--to=mark.rutland@arm.com \
--cc=Pawel.Moll@arm.com \
--cc=cjb@laptop.org \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=gdjakov@mm-sol.com \
--cc=grant.likely@linaro.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=rob.herring@calxeda.com \
--cc=rob@landley.net \
--cc=subhashj@codeaurora.org \
--cc=swarren@wwwdotorg.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).