Re: [PATCH v3 08/13] mmc: mmci: add 8bit bus support in variant data
Hi Linus W,
On 26/05/14 11:07, Ulf Hansson wrote:
unsigned intfifosize;
unsigned intfifohalfsize;
@@ -116,6 +118,7 @@ static struct variant_data variant_u300 = {
.fifosize = 16 * 4,
.fifohalfsize = 8 * 4,
.clkreg_enable = MCI_ST_U300_HWFCEN,
+ .clkreg_8bit_bus_enable = MCI_ST_8BIT_BUS,
Linus, will have to confirm this. I don't know if the u300 variant
support 8-bit.
Do you know if u300 supports 8BIT bus?
thanks,
srini
Kind regards
Ulf Hansson
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 08/13] mmc: mmci: add 8bit bus support in variant data
On Wed, May 28, 2014 at 9:27 AM, Srinivas Kandagatla
srinivas.kandaga...@linaro.org wrote:
Hi Linus W,
On 26/05/14 11:07, Ulf Hansson wrote:
unsigned intfifosize;
unsigned intfifohalfsize;
@@ -116,6 +118,7 @@ static struct variant_data variant_u300 = {
.fifosize = 16 * 4,
.fifohalfsize = 8 * 4,
.clkreg_enable = MCI_ST_U300_HWFCEN,
+ .clkreg_8bit_bus_enable = MCI_ST_8BIT_BUS,
Linus, will have to confirm this. I don't know if the u300 variant
support 8-bit.
Do you know if u300 supports 8BIT bus?
Yes it does actually.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 12/13] mmc: mmci: add explicit clk control
On Tue, May 27, 2014 at 12:39 AM, Srinivas Kandagatla srinivas.kandaga...@linaro.org wrote: On 26/05/14 15:21, Ulf Hansson wrote: On 23 May 2014 14:52, srinivas.kandaga...@linaro.org wrote: + boolexplicit_mclk_control; + boolcclk_is_mclk; I can't see why you need to have both these new configurations. Aren't cclk_is_mclk just a fact when you use explicit_mclk_control. I also believe I would prefer something like qcom_clkdiv instead. There is a subtle difference between both the flags. Am happy to change it to qcom_clkdiv. I think this was due to me wanting the variant variables to be more about the actual technical difference they indicate rather than pointing to a certain vendor or variant where that difference occurs. It's a very minor thing though, if you prefer it this way, go for it. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 13/13] mmc: mmci: Add Qcom specific pio_read function.
On Fri, May 23, 2014 at 2:53 PM, srinivas.kandaga...@linaro.org wrote:
+ if (unlikely(bytes)) {
+ unsigned char buf[4];
(...)
Please think twice about this.
http://lwn.net/Articles/70473/
http://lwn.net/Articles/420019/
http://lwn.net/Articles/182369/
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 12/13] mmc: mmci: add explicit clk control
On 28/05/14 09:02, Linus Walleij wrote: On Tue, May 27, 2014 at 12:39 AM, Srinivas Kandagatla srinivas.kandaga...@linaro.org wrote: On 26/05/14 15:21, Ulf Hansson wrote: On 23 May 2014 14:52, srinivas.kandaga...@linaro.org wrote: + boolexplicit_mclk_control; + boolcclk_is_mclk; I can't see why you need to have both these new configurations. Aren't cclk_is_mclk just a fact when you use explicit_mclk_control. I also believe I would prefer something like qcom_clkdiv instead. There is a subtle difference between both the flags. Am happy to change it to qcom_clkdiv. I think this was due to me wanting the variant variables to be more about the actual technical difference they indicate rather than pointing to a certain vendor or variant where that difference occurs. Yes, that's correct, I think having these two variables seems to be more generic than qcom_clkdiv. I will keep it as it is and fix other comments from Ulf in next version. It's a very minor thing though, if you prefer it this way, go for it. Thanks, sirni Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 13/13] mmc: mmci: Add Qcom specific pio_read function.
On 28/05/14 09:08, Linus Walleij wrote:
On Fri, May 23, 2014 at 2:53 PM, srinivas.kandaga...@linaro.org wrote:
+ if (unlikely(bytes)) {
+ unsigned char buf[4];
(...)
Please think twice about this.
http://lwn.net/Articles/70473/
http://lwn.net/Articles/420019/
http://lwn.net/Articles/182369/
Thanks for the warning.
You are right. I think having likely/unlikely is not always right here.
thanks,
srini
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] pinctrl: msm: Add missing sdc1 and sdc3 groups
On Tue, May 27, 2014 at 10:47 PM, Bjorn Andersson bjorn.anders...@sonymobile.com wrote: Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com --- Thought I already sent you parts of this previously, sorry about that. This should apply on your devel branch. OK thanks, patch applied. The APQ8060 that I have in my Dragon is very similar, right? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/13] mmc: mmci: add Qcom specifics of clk and datactrl registers.
Hi Ulf,
On 26/05/14 22:38, Srinivas Kandagatla wrote:
2 files changed, 28 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 17e7f6a..6434f5b1 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -185,6 +185,10 @@ static struct variant_data variant_qcom = {
.fifosize = 16 * 4,
.fifohalfsize = 8 * 4,
.clkreg = MCI_CLK_ENABLE,
+ .clkreg_enable = MCI_QCOM_CLK_FLOWENA |
+ MCI_QCOM_CLK_FEEDBACK_CLK,
Obviously I don't have the in-depth knowledge about the Qcom variant,
but comparing the ST variant here made me think.
Using the feeback clock internal logic in the ST variant, requires the
corresponding feedback clock pin signal on the board, to be
routed/connected. Typically we used this for SD cards, which involved
using an external level shifter circuit.
Is it correct to enable this bit for all cases, including eMMC?
You are correct, FBCLK should specific to the board, and I will try to
do something on the same lines as ST variant in next version.
I get lot of I/O errors when I remove this flag for test.
I rechecked schematics and datasheet, the feedback clk that we refer
here is the the feedback clk from CLK pad, there is no separate input
pad for fbclk. So I think this is internally feedbacked clk.
This selection is configuring bits to latch data and command coming in
using feedback clock from CLK pad.
I will make sure that the macro is named more appropriately to reflect
the same.
thanks,
srini
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] devicetree: bindings: Properly document micrel ks8851 SPI chips
On Tue, May 27, 2014 at 02:40:15PM -0700, Stephen Boyd wrote:
On 05/24/14 05:48, Mark Brown wrote:
That said it looks like this is intended to be a supply for an external
PHY rather than the device itself, but even so my original question
about it being able to operate without power still applies. Looking at
the code it's certainly not doing any of the handling of a missing
supply that I would associate with using _optional().
I agree, both supplies don't look optional. Unfortunately
efm32gg-dk3750.dts doesn't look to be listing any supply, and this
driver only recently got support for the VDD_A3.3 supply that the omap
board uses (adding Uwe for any comments on efm setup). I presume on
these boards VDD_IO is tied to some always on power source that software
doesn't want to deal with. Nishant, what's VDD_IO connected to on omap?
What's the proper solution here? Should we use regulator_get() and check
for EPROBE_DEFER and ignore other errors?
As an implementation extension if no supply is specified at all the
regulator API will happily substitute in a dummy if the board is using
DT or ACPI, or if it has specified full constraints.
Should the get_optional() variant just drop the Other consumers will
be... part and should the get_exclusive() variant say obtain this
regulator while this reference is held ?
Yes.
From: Stephen Boyd sb...@codeaurora.org
Subject: [PATCH] regulator: Fix regulator_get_{optional,exclusive}()
documentation
Documentation/SubmittingPatches.
signature.asc
Description: Digital signature
Re: [PATCH v3 10/13] mmc: mmci: add Qcom specifics of clk and datactrl registers.
On 28 May 2014 11:41, Srinivas Kandagatla
srinivas.kandaga...@linaro.org wrote:
Hi Ulf,
On 26/05/14 22:38, Srinivas Kandagatla wrote:
2 files changed, 28 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 17e7f6a..6434f5b1 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -185,6 +185,10 @@ static struct variant_data variant_qcom = {
.fifosize = 16 * 4,
.fifohalfsize = 8 * 4,
.clkreg = MCI_CLK_ENABLE,
+ .clkreg_enable = MCI_QCOM_CLK_FLOWENA |
+ MCI_QCOM_CLK_FEEDBACK_CLK,
Obviously I don't have the in-depth knowledge about the Qcom variant,
but comparing the ST variant here made me think.
Using the feeback clock internal logic in the ST variant, requires the
corresponding feedback clock pin signal on the board, to be
routed/connected. Typically we used this for SD cards, which involved
using an external level shifter circuit.
Is it correct to enable this bit for all cases, including eMMC?
You are correct, FBCLK should specific to the board, and I will try to
do something on the same lines as ST variant in next version.
I get lot of I/O errors when I remove this flag for test.
Running eMMC I suppose?
I rechecked schematics and datasheet, the feedback clk that we refer here is
the the feedback clk from CLK pad, there is no separate input pad for fbclk.
So I think this is internally feedbacked clk.
This selection is configuring bits to latch data and command coming in using
feedback clock from CLK pad.
Seems like it's strange to have this bit configurable then. I guess it
would be hard to tell under what circumstances you don't want this
bit set.
Anyway, it's not a big deal to me - let's keep it as is for now.
Kind regards
Ulf Hansson
I will make sure that the macro is named more appropriately to reflect the
same.
thanks,
srini
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 12/13] mmc: mmci: add explicit clk control
On 28 May 2014 10:28, Srinivas Kandagatla srinivas.kandaga...@linaro.org wrote: On 28/05/14 09:02, Linus Walleij wrote: On Tue, May 27, 2014 at 12:39 AM, Srinivas Kandagatla srinivas.kandaga...@linaro.org wrote: On 26/05/14 15:21, Ulf Hansson wrote: On 23 May 2014 14:52, srinivas.kandaga...@linaro.org wrote: + boolexplicit_mclk_control; + boolcclk_is_mclk; I can't see why you need to have both these new configurations. Aren't cclk_is_mclk just a fact when you use explicit_mclk_control. I also believe I would prefer something like qcom_clkdiv instead. There is a subtle difference between both the flags. Am happy to change it to qcom_clkdiv. I think this was due to me wanting the variant variables to be more about the actual technical difference they indicate rather than pointing to a certain vendor or variant where that difference occurs. Yes, that's correct, I think having these two variables seems to be more generic than qcom_clkdiv. I will keep it as it is and fix other comments from Ulf in next version. I think this relates to the discussion we had around fetching the f_min and f_max in -probe(). It, just seems silly to have to check for an extra flag there as well, because that is in principle what this would mean, right? So, please adjust to my proposal, I strongly think this should be only one flag. You might want a more generic name of the flag in favour of qcom_clkdiv, feel free to change to whatever you think make sense. Kind regards Ulf Hansson It's a very minor thing though, if you prefer it this way, go for it. Thanks, sirni Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 00/13] Add Qualcomm SD Card Controller support
From: Srinivas Kandagatla srinivas.kandaga...@linaro.org Thankyou Linus W, Ulf H and everyone for reviewing RFC to v3 patches. This patch series adds Qualcomm SD Card Controller support in pl180 mmci driver. QCom SDCC is basically a pl180, but bit more customized, some of the register layouts and offsets are different to the ones mentioned in pl180 datasheet. The plan is to totally remove the standalone SDCC driver drivers/mmc/host/msm_sdcc.* and start using generic mmci driver for all Qualcomm parts, as we get chance to test on other Qcom boards. To start using the existing mmci driver, a fake amba id for Qualcomm is added in patches: mmc: mmci: Add Qualcomm Id to amba id table. Second change is, adding a 3 clock cycle delay in between writes to CLKCTRL/POWER/DATACTRL/COMMAND registers. Most of the delays are taken care with the existing driver except delay for the COMMAND register was too small. This patch fixes it. mmc: mmci: Add enough delay between writes to CMD register. Third change is to accommodate CLK, DATCTRL and MMCICLK register layout changes in Qcom SDCC and provide more flexibity in driver to specify these changes via variant datastructure. Which are done in patches: mmc: mmci: Add Qcom datactrl register variant mmc: mmci: add ddrmode mask to variant data mmc: mmci: add 8bit bus support in variant data mmc: mmci: add edge support to data and command out in variant data. mmc: mmci: add Qcom specifics of clk and datactrl registers. mmc: mmci: Add support to data commands via variant structure. mmc: mmci: add f_max to variant structure mmc: mmci: add explicit clk control Fourth major change was to add qcom specfic pio read function, the need for this is because the way MCIFIFOCNT register behaved in QCOM SDCC is very different to the one in pl180. This change is done in patch: mmc: mmci: Add Qcom specific pio_read function. Last some Qcom unrelated changes/cleanup to driver are done in patches: mmc: mmci: use NSEC_PER_SEC macro mmc: mmci: convert register bits to use BIT() macro. This patches are tested in PIO mode on IFC8064 board with both eMMC and external SD card. I would like to get this support in v3.16. Bjorn also confirmed that there are no more CRC errors seen on sony platform. Changes from v3: - moved pio_read to a function pointer so as to reduce additional cycles in hot-path, suggested by Ulf. - simplify the flags used for explicit mclk control, suggested by Ulf. - fixed issues in cacluating f_max and f_min pointed and suggested by Ulf. - removed unessary DDR flags on un-supported STE variants. - used BIT macros as suggested by Ulf. - removed the read/write wrappers with delays, and used most optimal way to introduce the delays to the only registers that require delays. Changes from v2: - merged fbclk latch patch with clkreg_enable patch as suggested by Linus W. - remove qcom prefix for explicit clk control pointed by Linus W. - cleaned up mmci_qcom_pio_read and consider SDIO as suggested by Linus W. Changes from v1: - moved most of the SOC specifics to variant parameters as suggested by Linus W. - renamed registers as suggested by Linus W. - Added comments in the code as suggested by Linus W. - moved out AMBA ID addition patch from this series. - rebased the patches to git://git.linaro.org/people/ulf.hansson/mmc.git next as suggested by Ulf H. Changes from RFC: - moved out clk setup out of spinlock as pointed by Stephen B. If its not too late, Am hoping to get this for v3.16. All these patches are tested on IF6410 board on both eMMC and external SD card. Thanks, srini Srinivas Kandagatla (13): mmc: mmci: use NSEC_PER_SEC macro mmc: mmci: convert register bits to use BIT() macro. mmc: mmci: Add Qualcomm Id to amba id table mmc: mmci: Add enough delay between writes to CMD register. mmc: mmci: Add Qcom datactrl register variant mmc: mmci: add ddrmode mask to variant data mmc: mmci: add 8bit bus support in variant data mmc: mmci: add edge support to data and command out in variant data. mmc: mmci: add Qcom specifics of clk and datactrl registers. mmc: mmci: Add support to data commands via variant structure. mmc: mmci: add f_max to variant structure mmc: mmci: add explicit clk control mmc: mmci: Add Qcom specific pio_read function. drivers/mmc/host/mmci.c | 203 +- drivers/mmc/host/mmci.h | 228 ++-- 2 files changed, 288 insertions(+), 143 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 01/13] mmc: mmci: use NSEC_PER_SEC macro
From: Srinivas Kandagatla srinivas.kandaga...@linaro.org This patch replaces a constant used in calculating timeout with a proper macro. This is make code more readable. Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org Reviewed-by: Linus Walleij linus.wall...@linaro.org --- drivers/mmc/host/mmci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c index a084edd..a38e714 100644 --- a/drivers/mmc/host/mmci.c +++ b/drivers/mmc/host/mmci.c @@ -718,7 +718,7 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data) data-bytes_xfered = 0; clks = (unsigned long long)data-timeout_ns * host-cclk; - do_div(clks, 10UL); + do_div(clks, NSEC_PER_SEC); timeout = data-timeout_clks + (unsigned int)clks; -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 05/13] mmc: mmci: Add Qcom datactrl register variant
From: Srinivas Kandagatla srinivas.kandaga...@linaro.org
Instance of this IP on Qualcomm's SOCs has bit different layout for datactrl
register. Bit position datactrl[16:4] hold the true block size instead of power
of 2.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
Reviewed-by: Linus Walleij linus.wall...@linaro.org
---
drivers/mmc/host/mmci.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index aa2d381..23401b0 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -60,6 +60,8 @@ static unsigned int fmax = 515633;
* @sdio: variant supports SDIO
* @st_clkdiv: true if using a ST-specific clock divider algorithm
* @blksz_datactrl16: true if Block size is at b16..b30 position in datactrl
register
+ * @blksz_datactrl4: true if Block size is at b4..b16 position in datactrl
+ * register
* @pwrreg_powerup: power up value for MMCIPOWER register
* @signal_direction: input/out direction of bus signals can be indicated
* @pwrreg_clkgate: MMCIPOWER register must be used to gate the clock
@@ -75,6 +77,7 @@ struct variant_data {
boolsdio;
boolst_clkdiv;
boolblksz_datactrl16;
+ boolblksz_datactrl4;
u32 pwrreg_powerup;
boolsignal_direction;
boolpwrreg_clkgate;
@@ -164,6 +167,7 @@ static struct variant_data variant_qcom = {
.fifosize = 16 * 4,
.fifohalfsize = 8 * 4,
.clkreg = MCI_CLK_ENABLE,
+ .blksz_datactrl4= true,
.datalength_bits= 24,
.pwrreg_powerup = MCI_PWR_UP,
};
@@ -739,6 +743,8 @@ static void mmci_start_data(struct mmci_host *host, struct
mmc_data *data)
if (variant-blksz_datactrl16)
datactrl = MCI_DPSM_ENABLE | (data-blksz 16);
+ else if (variant-blksz_datactrl4)
+ datactrl = MCI_DPSM_ENABLE | (data-blksz 4);
else
datactrl = MCI_DPSM_ENABLE | blksz_bits 4;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 12/13] mmc: mmci: add explicit clk control
From: Srinivas Kandagatla srinivas.kandaga...@linaro.org
On Controllers like Qcom SD card controller where cclk is mclk and mclk should
be directly controlled by the driver.
This patch adds support to control mclk directly in the driver, and also
adds explicit_mclk_control flag in variant structure giving more flexibility
to the driver.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
drivers/mmc/host/mmci.c | 96 -
drivers/mmc/host/mmci.h | 2 ++
2 files changed, 65 insertions(+), 33 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 202f2d5..6eb0a29 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -72,6 +72,7 @@ static unsigned int fmax = 515633;
* @pwrreg_clkgate: MMCIPOWER register must be used to gate the clock
* @busy_detect: true if busy detection on dat0 is supported
* @pwrreg_nopower: bits in MMCIPOWER don't controls ext. power supply
+ * @explicit_mclk_control: enable explicit mclk control in driver.
*/
struct variant_data {
unsigned intclkreg;
@@ -93,6 +94,7 @@ struct variant_data {
boolpwrreg_clkgate;
boolbusy_detect;
boolpwrreg_nopower;
+ boolexplicit_mclk_control;
};
static struct variant_data variant_arm = {
@@ -199,6 +201,7 @@ static struct variant_data variant_qcom = {
.datalength_bits= 24,
.pwrreg_powerup = MCI_PWR_UP,
.f_max = 20800,
+ .explicit_mclk_control = true,
};
static int mmci_card_busy(struct mmc_host *mmc)
@@ -301,7 +304,9 @@ static void mmci_set_clkreg(struct mmci_host *host,
unsigned int desired)
host-cclk = 0;
if (desired) {
- if (desired = host-mclk) {
+ if (variant-explicit_mclk_control) {
+ host-cclk = host-mclk;
+ } else if (desired = host-mclk) {
clk = MCI_CLK_BYPASS;
if (variant-st_clkdiv)
clk |= MCI_ST_UX500_NEG_EDGE;
@@ -1340,6 +1345,18 @@ static void mmci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
if (!ios-clock variant-pwrreg_clkgate)
pwr = ~MCI_PWR_ON;
+ if ((host-variant-explicit_mclk_control)
+ (ios-clock != host-mclk_req)) {
+ int rc = clk_set_rate(host-clk, ios-clock);
+ if (rc 0) {
+ dev_err(mmc_dev(host-mmc),
+ Error setting clock rate (%d)\n, rc);
+ } else {
+ host-mclk = clk_get_rate(host-clk);
+ host-mclk_req = ios-clock;
+ }
+ }
+
spin_lock_irqsave(host-lock, flags);
mmci_set_clkreg(host, ios-clock);
@@ -1490,19 +1507,6 @@ static int mmci_probe(struct amba_device *dev,
host-plat = plat;
host-variant = variant;
host-mclk = clk_get_rate(host-clk);
- /*
-* According to the spec, mclk is max 100 MHz,
-* so we try to adjust the clock down to this,
-* (if possible).
-*/
- if (host-mclk host-variant-f_max) {
- ret = clk_set_rate(host-clk, host-variant-f_max);
- if (ret 0)
- goto clk_disable;
- host-mclk = clk_get_rate(host-clk);
- dev_dbg(mmc_dev(mmc), eventual mclk rate: %u Hz\n,
- host-mclk);
- }
host-phybase = dev-res.start;
host-base = devm_ioremap_resource(dev-dev, dev-res);
@@ -1511,25 +1515,51 @@ static int mmci_probe(struct amba_device *dev,
goto clk_disable;
}
- /*
-* The ARM and ST versions of the block have slightly different
-* clock divider equations which means that the minimum divider
-* differs too.
-*/
- if (variant-st_clkdiv)
- mmc-f_min = DIV_ROUND_UP(host-mclk, 257);
- else
- mmc-f_min = DIV_ROUND_UP(host-mclk, 512);
- /*
-* If no maximum operating frequency is supplied, fall back to use
-* the module parameter, which has a (low) default value in case it
-* is not specified. Either value must not exceed the clock rate into
-* the block, of course.
-*/
- if (mmc-f_max)
- mmc-f_max = min(host-mclk, mmc-f_max);
- else
- mmc-f_max = min(host-mclk, fmax);
+ if (variant-explicit_mclk_control) {
+ /* get the nearest minimum clock to 100Khz */
+ mmc-f_min = clk_round_rate(host-clk, 10);
+
+ if (mmc-f_max)
+ mmc-f_max = min(host-variant-f_max, mmc-f_max);
+ else
+ mmc-f_max = min(host-variant-f_max, fmax);
+
+ } else {
+ /*
[PATCH v4 11/13] mmc: mmci: add f_max to variant structure
From: Srinivas Kandagatla srinivas.kandaga...@linaro.org
Some of the controller have maximum supported frequency, This patch adds
support in variant data structure to specify such restrictions. This
gives more flexibility in calculating the f_max before passing it to
mmc-core.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
drivers/mmc/host/mmci.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index fd40f9a..202f2d5 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -67,6 +67,7 @@ static unsigned int fmax = 515633;
* @blksz_datactrl4: true if Block size is at b4..b16 position in datactrl
* register
* @pwrreg_powerup: power up value for MMCIPOWER register
+ * @f_max: maximum clk frequency supported by the controller.
* @signal_direction: input/out direction of bus signals can be indicated
* @pwrreg_clkgate: MMCIPOWER register must be used to gate the clock
* @busy_detect: true if busy detection on dat0 is supported
@@ -87,6 +88,7 @@ struct variant_data {
boolblksz_datactrl16;
boolblksz_datactrl4;
u32 pwrreg_powerup;
+ u32 f_max;
boolsignal_direction;
boolpwrreg_clkgate;
boolbusy_detect;
@@ -98,6 +100,7 @@ static struct variant_data variant_arm = {
.fifohalfsize = 8 * 4,
.datalength_bits= 16,
.pwrreg_powerup = MCI_PWR_UP,
+ .f_max = 1,
};
static struct variant_data variant_arm_extended_fifo = {
@@ -105,6 +108,7 @@ static struct variant_data variant_arm_extended_fifo = {
.fifohalfsize = 64 * 4,
.datalength_bits= 16,
.pwrreg_powerup = MCI_PWR_UP,
+ .f_max = 1,
};
static struct variant_data variant_arm_extended_fifo_hwfc = {
@@ -113,6 +117,7 @@ static struct variant_data variant_arm_extended_fifo_hwfc =
{
.clkreg_enable = MCI_ARM_HWFCEN,
.datalength_bits= 16,
.pwrreg_powerup = MCI_PWR_UP,
+ .f_max = 1,
};
static struct variant_data variant_u300 = {
@@ -123,6 +128,7 @@ static struct variant_data variant_u300 = {
.datalength_bits= 16,
.sdio = true,
.pwrreg_powerup = MCI_PWR_ON,
+ .f_max = 1,
.signal_direction = true,
.pwrreg_clkgate = true,
.pwrreg_nopower = true,
@@ -136,6 +142,7 @@ static struct variant_data variant_nomadik = {
.sdio = true,
.st_clkdiv = true,
.pwrreg_powerup = MCI_PWR_ON,
+ .f_max = 1,
.signal_direction = true,
.pwrreg_clkgate = true,
.pwrreg_nopower = true,
@@ -152,6 +159,7 @@ static struct variant_data variant_ux500 = {
.sdio = true,
.st_clkdiv = true,
.pwrreg_powerup = MCI_PWR_ON,
+ .f_max = 1,
.signal_direction = true,
.pwrreg_clkgate = true,
.busy_detect= true,
@@ -171,6 +179,7 @@ static struct variant_data variant_ux500v2 = {
.st_clkdiv = true,
.blksz_datactrl16 = true,
.pwrreg_powerup = MCI_PWR_ON,
+ .f_max = 1,
.signal_direction = true,
.pwrreg_clkgate = true,
.busy_detect= true,
@@ -189,6 +198,7 @@ static struct variant_data variant_qcom = {
.blksz_datactrl4= true,
.datalength_bits= 24,
.pwrreg_powerup = MCI_PWR_UP,
+ .f_max = 20800,
};
static int mmci_card_busy(struct mmc_host *mmc)
@@ -1485,8 +1495,8 @@ static int mmci_probe(struct amba_device *dev,
* so we try to adjust the clock down to this,
* (if possible).
*/
- if (host-mclk 1) {
- ret = clk_set_rate(host-clk, 1);
+ if (host-mclk host-variant-f_max) {
+ ret = clk_set_rate(host-clk, host-variant-f_max);
if (ret 0)
goto clk_disable;
host-mclk = clk_get_rate(host-clk);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 08/13] mmc: mmci: add edge support to data and command out in variant data.
From: Srinivas Kandagatla srinivas.kandaga...@linaro.org
This patch adds edge support for data and command out to variant structure
giving more flexibility to the driver to support more SOCs which have
different clock register layout.
Without this patch other new SOCs like Qcom will have to add more code to
special case them
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
Reviewed-by: Linus Walleij linus.wall...@linaro.org
---
drivers/mmc/host/mmci.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 2f4cdf3..8deea4a 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -53,6 +53,7 @@ static unsigned int fmax = 515633;
* @clkreg: default value for MCICLOCK register
* @clkreg_enable: enable value for MMCICLOCK register
* @clkreg_8bit_bus_enable: enable value for 8 bit bus
+ * @clkreg_neg_edge_enable: enable value for inverted data/cmd output
* @datalength_bits: number of bits in the MMCIDATALENGTH register
* @fifosize: number of bytes that can be written when MMCI_TXFIFOEMPTY
* is asserted (likewise for RX)
@@ -74,6 +75,7 @@ struct variant_data {
unsigned intclkreg;
unsigned intclkreg_enable;
unsigned intclkreg_8bit_bus_enable;
+ unsigned intclkreg_neg_edge_enable;
unsigned intdatalength_bits;
unsigned intfifosize;
unsigned intfifohalfsize;
@@ -143,6 +145,7 @@ static struct variant_data variant_ux500 = {
.clkreg = MCI_CLK_ENABLE,
.clkreg_enable = MCI_ST_UX500_HWFCEN,
.clkreg_8bit_bus_enable = MCI_ST_8BIT_BUS,
+ .clkreg_neg_edge_enable = MCI_ST_UX500_NEG_EDGE,
.datalength_bits= 24,
.sdio = true,
.st_clkdiv = true,
@@ -159,6 +162,7 @@ static struct variant_data variant_ux500v2 = {
.clkreg = MCI_CLK_ENABLE,
.clkreg_enable = MCI_ST_UX500_HWFCEN,
.clkreg_8bit_bus_enable = MCI_ST_8BIT_BUS,
+ .clkreg_neg_edge_enable = MCI_ST_UX500_NEG_EDGE,
.datactrl_mask_ddrmode = MCI_ST_DPSM_DDRMODE,
.datalength_bits= 24,
.sdio = true,
@@ -322,7 +326,7 @@ static void mmci_set_clkreg(struct mmci_host *host,
unsigned int desired)
clk |= variant-clkreg_8bit_bus_enable;
if (host-mmc-ios.timing == MMC_TIMING_UHS_DDR50)
- clk |= MCI_ST_UX500_NEG_EDGE;
+ clk |= variant-clkreg_neg_edge_enable;
mmci_write_clkreg(host, clk);
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 09/13] mmc: mmci: add Qcom specifics of clk and datactrl registers.
From: Srinivas Kandagatla srinivas.kandaga...@linaro.org
This patch adds specifics of clk and datactrl register on Qualcomm SD
Card controller. This patch also populates the Qcom variant data with
these new values specific to Qualcomm SD Card Controller.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
Reviewed-by: Linus Walleij linus.wall...@linaro.org
---
drivers/mmc/host/mmci.c | 4
drivers/mmc/host/mmci.h | 17 +
2 files changed, 21 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 8deea4a..dbcb952 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -179,6 +179,10 @@ static struct variant_data variant_qcom = {
.fifosize = 16 * 4,
.fifohalfsize = 8 * 4,
.clkreg = MCI_CLK_ENABLE,
+ .clkreg_enable = MCI_QCOM_CLK_FLOWENA |
+ MCI_QCOM_CLK_SELECT_IN_FBCLK,
+ .clkreg_8bit_bus_enable = MCI_QCOM_CLK_WIDEBUS_8,
+ .datactrl_mask_ddrmode = MCI_QCOM_CLK_SELECT_IN_DDR_MODE,
.blksz_datactrl4= true,
.datalength_bits= 24,
.pwrreg_powerup = MCI_PWR_UP,
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index cd83ca3..706eb513 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -41,6 +41,15 @@
/* Modified PL180 on Versatile Express platform */
#define MCI_ARM_HWFCEN BIT(12)
+/* Modified on Qualcomm Integrations */
+#define MCI_QCOM_CLK_WIDEBUS_8 (BIT(10) | BIT(11))
+#define MCI_QCOM_CLK_FLOWENA BIT(12)
+#define MCI_QCOM_CLK_INVERTOUT BIT(13)
+
+/* select in latch data and command in */
+#define MCI_QCOM_CLK_SELECT_IN_FBCLK BIT(15)
+#define MCI_QCOM_CLK_SELECT_IN_DDR_MODE(BIT(14) | BIT(15))
+
#define MMCIARGUMENT 0x008
#define MMCICOMMAND0x00c
#define MCI_CPSM_RESPONSE BIT(6)
@@ -54,6 +63,14 @@
#define MCI_ST_NIENBIT(13)
#define MCI_ST_CE_ATACMD BIT(14)
+/* Modified on Qualcomm Integrations */
+#define MCI_QCOM_CSPM_DATCMD BIT(12)
+#define MCI_QCOM_CSPM_MCIABORT BIT(13)
+#define MCI_QCOM_CSPM_CCSENABLEBIT(14)
+#define MCI_QCOM_CSPM_CCSDISABLE BIT(15)
+#define MCI_QCOM_CSPM_AUTO_CMD19 BIT(16)
+#define MCI_QCOM_CSPM_AUTO_CMD21 BIT(21)
+
#define MMCIRESPCMD0x010
#define MMCIRESPONSE0 0x014
#define MMCIRESPONSE1 0x018
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 10/13] mmc: mmci: Add support to data commands via variant structure.
From: Srinivas Kandagatla srinivas.kandaga...@linaro.org
On some SOCs like Qcom there are explicit bits in the command register
to specify if its a data transfer command or not. So this patch adds
support to such bits in variant data, giving more flexibility to the
driver.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
Reviewed-by: Linus Walleij linus.wall...@linaro.org
---
drivers/mmc/host/mmci.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index dbcb952..fd40f9a 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -59,6 +59,7 @@ static unsigned int fmax = 515633;
* is asserted (likewise for RX)
* @fifohalfsize: number of bytes that can be written when MCI_TXFIFOHALFEMPTY
* is asserted (likewise for RX)
+ * @data_cmd_enable: enable value for data commands.
* @sdio: variant supports SDIO
* @st_clkdiv: true if using a ST-specific clock divider algorithm
* @datactrl_mask_ddrmode: ddr mode mask in datactrl register.
@@ -79,6 +80,7 @@ struct variant_data {
unsigned intdatalength_bits;
unsigned intfifosize;
unsigned intfifohalfsize;
+ unsigned intdata_cmd_enable;
unsigned intdatactrl_mask_ddrmode;
boolsdio;
boolst_clkdiv;
@@ -183,6 +185,7 @@ static struct variant_data variant_qcom = {
MCI_QCOM_CLK_SELECT_IN_FBCLK,
.clkreg_8bit_bus_enable = MCI_QCOM_CLK_WIDEBUS_8,
.datactrl_mask_ddrmode = MCI_QCOM_CLK_SELECT_IN_DDR_MODE,
+ .data_cmd_enable= MCI_QCOM_CSPM_DATCMD,
.blksz_datactrl4= true,
.datalength_bits= 24,
.pwrreg_powerup = MCI_PWR_UP,
@@ -852,6 +855,9 @@ mmci_start_command(struct mmci_host *host, struct
mmc_command *cmd, u32 c)
if (/*interrupt*/0)
c |= MCI_CPSM_INTERRUPT;
+ if (mmc_cmd_type(cmd) == MMC_CMD_ADTC)
+ c |= host-variant-data_cmd_enable;
+
host-cmd = cmd;
writel(cmd-arg, base + MMCIARGUMENT);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 07/13] mmc: mmci: add 8bit bus support in variant data
From: Srinivas Kandagatla srinivas.kandaga...@linaro.org
This patch adds 8bit bus enable to variant structure giving more flexibility
to the driver to support more SOCs which have different clock register layout.
Without this patch other new SOCs like Qcom will have to add more code
to special case them.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
Reviewed-by: Linus Walleij linus.wall...@linaro.org
---
drivers/mmc/host/mmci.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 729105b..2f4cdf3 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -52,6 +52,7 @@ static unsigned int fmax = 515633;
* struct variant_data - MMCI variant-specific quirks
* @clkreg: default value for MCICLOCK register
* @clkreg_enable: enable value for MMCICLOCK register
+ * @clkreg_8bit_bus_enable: enable value for 8 bit bus
* @datalength_bits: number of bits in the MMCIDATALENGTH register
* @fifosize: number of bytes that can be written when MMCI_TXFIFOEMPTY
* is asserted (likewise for RX)
@@ -72,6 +73,7 @@ static unsigned int fmax = 515633;
struct variant_data {
unsigned intclkreg;
unsigned intclkreg_enable;
+ unsigned intclkreg_8bit_bus_enable;
unsigned intdatalength_bits;
unsigned intfifosize;
unsigned intfifohalfsize;
@@ -113,6 +115,7 @@ static struct variant_data variant_u300 = {
.fifosize = 16 * 4,
.fifohalfsize = 8 * 4,
.clkreg_enable = MCI_ST_U300_HWFCEN,
+ .clkreg_8bit_bus_enable = MCI_ST_8BIT_BUS,
.datalength_bits= 16,
.sdio = true,
.pwrreg_powerup = MCI_PWR_ON,
@@ -139,6 +142,7 @@ static struct variant_data variant_ux500 = {
.fifohalfsize = 8 * 4,
.clkreg = MCI_CLK_ENABLE,
.clkreg_enable = MCI_ST_UX500_HWFCEN,
+ .clkreg_8bit_bus_enable = MCI_ST_8BIT_BUS,
.datalength_bits= 24,
.sdio = true,
.st_clkdiv = true,
@@ -154,6 +158,7 @@ static struct variant_data variant_ux500v2 = {
.fifohalfsize = 8 * 4,
.clkreg = MCI_CLK_ENABLE,
.clkreg_enable = MCI_ST_UX500_HWFCEN,
+ .clkreg_8bit_bus_enable = MCI_ST_8BIT_BUS,
.datactrl_mask_ddrmode = MCI_ST_DPSM_DDRMODE,
.datalength_bits= 24,
.sdio = true,
@@ -314,7 +319,7 @@ static void mmci_set_clkreg(struct mmci_host *host,
unsigned int desired)
if (host-mmc-ios.bus_width == MMC_BUS_WIDTH_4)
clk |= MCI_4BIT_BUS;
if (host-mmc-ios.bus_width == MMC_BUS_WIDTH_8)
- clk |= MCI_ST_8BIT_BUS;
+ clk |= variant-clkreg_8bit_bus_enable;
if (host-mmc-ios.timing == MMC_TIMING_UHS_DDR50)
clk |= MCI_ST_UX500_NEG_EDGE;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 03/13] mmc: mmci: Add Qualcomm Id to amba id table
From: Srinivas Kandagatla srinivas.kandaga...@linaro.org
This patch adds a fake Qualcomm ID 0x00051180 to the amba_ids, as Qualcomm
SDCC controller is pl180, but amba id registers read 0x0's.
The plan is to remove SDCC driver totally and use mmci as the main SD
controller driver for Qualcomm SOCs.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
Reviewed-by: Linus Walleij linus.wall...@linaro.org
---
drivers/mmc/host/mmci.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index a38e714..86f25a9 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -160,6 +160,14 @@ static struct variant_data variant_ux500v2 = {
.pwrreg_nopower = true,
};
+static struct variant_data variant_qcom = {
+ .fifosize = 16 * 4,
+ .fifohalfsize = 8 * 4,
+ .clkreg = MCI_CLK_ENABLE,
+ .datalength_bits= 24,
+ .pwrreg_powerup = MCI_PWR_UP,
+};
+
static int mmci_card_busy(struct mmc_host *mmc)
{
struct mmci_host *host = mmc_priv(mmc);
@@ -1750,6 +1758,12 @@ static struct amba_id mmci_ids[] = {
.mask = 0xf0ff,
.data = variant_ux500v2,
},
+ /* Qualcomm variants */
+ {
+ .id = 0x00051180,
+ .mask = 0x000f,
+ .data = variant_qcom,
+ },
{ 0, 0 },
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 02/13] mmc: mmci: convert register bits to use BIT() macro.
From: Srinivas Kandagatla srinivas.kandaga...@linaro.org This patch converts the register bits in the header file to use BIT(() macro, which looks much neater. No functional changes done. Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org --- drivers/mmc/host/mmci.h | 208 1 file changed, 104 insertions(+), 104 deletions(-) diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h index 347d942..cd83ca3 100644 --- a/drivers/mmc/host/mmci.h +++ b/drivers/mmc/host/mmci.h @@ -11,48 +11,48 @@ #define MCI_PWR_OFF0x00 #define MCI_PWR_UP 0x02 #define MCI_PWR_ON 0x03 -#define MCI_OD (1 6) -#define MCI_ROD(1 7) +#define MCI_OD BIT(6) +#define MCI_RODBIT(7) /* * The ST Micro version does not have ROD and reuse the voltage registers for * direction settings. */ -#define MCI_ST_DATA2DIREN (1 2) -#define MCI_ST_CMDDIREN(1 3) -#define MCI_ST_DATA0DIREN (1 4) -#define MCI_ST_DATA31DIREN (1 5) -#define MCI_ST_FBCLKEN (1 7) -#define MCI_ST_DATA74DIREN (1 8) +#define MCI_ST_DATA2DIREN BIT(2) +#define MCI_ST_CMDDIRENBIT(3) +#define MCI_ST_DATA0DIREN BIT(4) +#define MCI_ST_DATA31DIREN BIT(5) +#define MCI_ST_FBCLKEN BIT(7) +#define MCI_ST_DATA74DIREN BIT(8) #define MMCICLOCK 0x004 -#define MCI_CLK_ENABLE (1 8) -#define MCI_CLK_PWRSAVE(1 9) -#define MCI_CLK_BYPASS (1 10) -#define MCI_4BIT_BUS (1 11) +#define MCI_CLK_ENABLE BIT(8) +#define MCI_CLK_PWRSAVEBIT(9) +#define MCI_CLK_BYPASS BIT(10) +#define MCI_4BIT_BUS BIT(11) /* * 8bit wide buses, hardware flow contronl, negative edges and clock inversion * supported in ST Micro U300 and Ux500 versions */ -#define MCI_ST_8BIT_BUS(1 12) -#define MCI_ST_U300_HWFCEN (1 13) -#define MCI_ST_UX500_NEG_EDGE (1 13) -#define MCI_ST_UX500_HWFCEN(1 14) -#define MCI_ST_UX500_CLK_INV (1 15) +#define MCI_ST_8BIT_BUSBIT(12) +#define MCI_ST_U300_HWFCEN BIT(13) +#define MCI_ST_UX500_NEG_EDGE BIT(13) +#define MCI_ST_UX500_HWFCENBIT(14) +#define MCI_ST_UX500_CLK_INV BIT(15) /* Modified PL180 on Versatile Express platform */ -#define MCI_ARM_HWFCEN (1 12) +#define MCI_ARM_HWFCEN BIT(12) #define MMCIARGUMENT 0x008 #define MMCICOMMAND0x00c -#define MCI_CPSM_RESPONSE (1 6) -#define MCI_CPSM_LONGRSP (1 7) -#define MCI_CPSM_INTERRUPT (1 8) -#define MCI_CPSM_PENDING (1 9) -#define MCI_CPSM_ENABLE(1 10) +#define MCI_CPSM_RESPONSE BIT(6) +#define MCI_CPSM_LONGRSP BIT(7) +#define MCI_CPSM_INTERRUPT BIT(8) +#define MCI_CPSM_PENDING BIT(9) +#define MCI_CPSM_ENABLEBIT(10) /* Argument flag extenstions in the ST Micro versions */ -#define MCI_ST_SDIO_SUSP (1 11) -#define MCI_ST_ENCMD_COMPL (1 12) -#define MCI_ST_NIEN(1 13) -#define MCI_ST_CE_ATACMD (1 14) +#define MCI_ST_SDIO_SUSP BIT(11) +#define MCI_ST_ENCMD_COMPL BIT(12) +#define MCI_ST_NIENBIT(13) +#define MCI_ST_CE_ATACMD BIT(14) #define MMCIRESPCMD0x010 #define MMCIRESPONSE0 0x014 @@ -62,95 +62,95 @@ #define MMCIDATATIMER 0x024 #define MMCIDATALENGTH 0x028 #define MMCIDATACTRL 0x02c -#define MCI_DPSM_ENABLE(1 0) -#define MCI_DPSM_DIRECTION (1 1) -#define MCI_DPSM_MODE (1 2) -#define MCI_DPSM_DMAENABLE (1 3) -#define MCI_DPSM_BLOCKSIZE (1 4) +#define MCI_DPSM_ENABLEBIT(0) +#define MCI_DPSM_DIRECTION BIT(1) +#define MCI_DPSM_MODE BIT(2) +#define MCI_DPSM_DMAENABLE BIT(3) +#define MCI_DPSM_BLOCKSIZE BIT(4) /* Control register extensions in the ST Micro U300 and Ux500 versions */ -#define MCI_ST_DPSM_RWSTART(1 8) -#define MCI_ST_DPSM_RWSTOP (1 9) -#define MCI_ST_DPSM_RWMOD (1 10) -#define MCI_ST_DPSM_SDIOEN (1 11) +#define MCI_ST_DPSM_RWSTARTBIT(8) +#define MCI_ST_DPSM_RWSTOP BIT(9) +#define MCI_ST_DPSM_RWMOD BIT(10) +#define MCI_ST_DPSM_SDIOEN BIT(11) /* Control register extensions in the ST Micro Ux500 versions */ -#define MCI_ST_DPSM_DMAREQCTL (1 12) -#define MCI_ST_DPSM_DBOOTMODEEN(1 13) -#define MCI_ST_DPSM_BUSYMODE (1 14) -#define MCI_ST_DPSM_DDRMODE(1 15) +#define MCI_ST_DPSM_DMAREQCTL BIT(12) +#define MCI_ST_DPSM_DBOOTMODEENBIT(13) +#define MCI_ST_DPSM_BUSYMODE BIT(14) +#define MCI_ST_DPSM_DDRMODEBIT(15) #define MMCIDATACNT0x030 #define MMCISTATUS 0x034 -#define MCI_CMDCRCFAIL (1 0) -#define MCI_DATACRCFAIL(1 1) -#define MCI_CMDTIMEOUT (1 2) -#define
[PATCH v4 06/13] mmc: mmci: add ddrmode mask to variant data
From: Srinivas Kandagatla srinivas.kandaga...@linaro.org
This patch adds ddrmode mask to variant structure giving more flexibility
to the driver to support more SOCs which have different datactrl register
layout.
Without this patch datactrl register is updated with wrong ddrmode mask on non
ST SOCs, resulting in card detection failures.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
Reviewed-by: Linus Walleij linus.wall...@linaro.org
---
drivers/mmc/host/mmci.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 23401b0..729105b 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -59,6 +59,7 @@ static unsigned int fmax = 515633;
* is asserted (likewise for RX)
* @sdio: variant supports SDIO
* @st_clkdiv: true if using a ST-specific clock divider algorithm
+ * @datactrl_mask_ddrmode: ddr mode mask in datactrl register.
* @blksz_datactrl16: true if Block size is at b16..b30 position in datactrl
register
* @blksz_datactrl4: true if Block size is at b4..b16 position in datactrl
* register
@@ -74,6 +75,7 @@ struct variant_data {
unsigned intdatalength_bits;
unsigned intfifosize;
unsigned intfifohalfsize;
+ unsigned intdatactrl_mask_ddrmode;
boolsdio;
boolst_clkdiv;
boolblksz_datactrl16;
@@ -152,6 +154,7 @@ static struct variant_data variant_ux500v2 = {
.fifohalfsize = 8 * 4,
.clkreg = MCI_CLK_ENABLE,
.clkreg_enable = MCI_ST_UX500_HWFCEN,
+ .datactrl_mask_ddrmode = MCI_ST_DPSM_DDRMODE,
.datalength_bits= 24,
.sdio = true,
.st_clkdiv = true,
@@ -779,7 +782,7 @@ static void mmci_start_data(struct mmci_host *host, struct
mmc_data *data)
}
if (host-mmc-ios.timing == MMC_TIMING_UHS_DDR50)
- datactrl |= MCI_ST_DPSM_DDRMODE;
+ datactrl |= variant-datactrl_mask_ddrmode;
/*
* Attempt to use DMA operation mode, if this
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 04/13] mmc: mmci: Add enough delay between writes to CMD register.
From: Srinivas Kandagatla srinivas.kandaga...@linaro.org
On Qcom SD Card controller POWER, CLKCTRL, DATACTRL and COMMAND registers
should be updated in MCLK domain, and writes to these registers must be
separated by three MCLK cycles. This resitriction is not applicable for
other registers. Any subsequent writes to these register will be ignored
until 3 MCLK have passed.
One usec delay between two CMD register writes is not sufficient in the
card identification phase where the CCLK is very low. This patch replaces
a static 1 usec delay to use mmci_reg_delay function which can provide
correct delay depending on the cclk frequency.
Without this patch the card is not detected.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
drivers/mmc/host/mmci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 86f25a9..aa2d381 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -818,7 +818,7 @@ mmci_start_command(struct mmci_host *host, struct
mmc_command *cmd, u32 c)
if (readl(base + MMCICOMMAND) MCI_CPSM_ENABLE) {
writel(0, base + MMCICOMMAND);
- udelay(1);
+ mmci_reg_delay(host);
}
c |= cmd-opcode | MCI_CPSM_ENABLE;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 13/13] mmc: mmci: Add Qcom specific pio_read function.
From: Srinivas Kandagatla srinivas.kandaga...@linaro.org
MCIFIFOCNT register behaviour on Qcom chips is very different than the other
pl180 integrations. MCIFIFOCNT register contains the number of
words that are still waiting to be transferred through the FIFO. It keeps
decrementing once the host CPU reads the MCIFIFO. With the existing logic and
the MCIFIFOCNT behaviour, mmci_pio_read will loop forever, as the FIFOCNT
register will always return transfer size before reading the FIFO.
Also the data sheet states that This register is only useful for debug
purposes and should not be used for normal operation since it does not reflect
data which may or may not be in the pipeline.
This patch implements qcom_pio_read function so as existing mmci_pio_read is
not suitable for Qcom SOCs. qcom_pio_read function is only selected
based on qcom_fifo flag in variant data structure.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
drivers/mmc/host/mmci.c | 45 -
drivers/mmc/host/mmci.h | 1 +
2 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 6eb0a29..b68223a 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -73,6 +73,7 @@ static unsigned int fmax = 515633;
* @busy_detect: true if busy detection on dat0 is supported
* @pwrreg_nopower: bits in MMCIPOWER don't controls ext. power supply
* @explicit_mclk_control: enable explicit mclk control in driver.
+ * @qcom_fifo: enables qcom specific fifo pio read function.
*/
struct variant_data {
unsigned intclkreg;
@@ -95,6 +96,7 @@ struct variant_data {
boolbusy_detect;
boolpwrreg_nopower;
boolexplicit_mclk_control;
+ boolqcom_fifo;
};
static struct variant_data variant_arm = {
@@ -202,6 +204,7 @@ static struct variant_data variant_qcom = {
.pwrreg_powerup = MCI_PWR_UP,
.f_max = 20800,
.explicit_mclk_control = true,
+ .qcom_fifo = true,
};
static int mmci_card_busy(struct mmc_host *mmc)
@@ -1006,6 +1009,40 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command
*cmd,
}
}
+static int mmci_qcom_pio_read(struct mmci_host *host, char *buffer,
+ unsigned int remain)
+{
+ u32 *ptr = (u32 *) buffer;
+ unsigned int count = 0;
+ unsigned int words, bytes;
+ unsigned int fsize = host-variant-fifosize;
+
+ words = remain 2;
+ bytes = remain % 4;
+ /* read full words followed by leftover bytes */
+ if (words) {
+ while (readl(host-base + MMCISTATUS) MCI_RXDATAAVLBL) {
+ *ptr = readl(host-base + MMCIFIFO + (count % fsize));
+ ptr++;
+ count += 4;
+ words--;
+ if (!words)
+ break;
+ }
+ }
+
+ if (bytes) {
+ unsigned char buf[4];
+ if (readl(host-base + MMCISTATUS) MCI_RXDATAAVLBL) {
+ *buf = readl(host-base + MMCIFIFO + (count % fsize));
+ memcpy(ptr, buf, bytes);
+ count += bytes;
+ }
+ }
+
+ return count;
+}
+
static int mmci_pio_read(struct mmci_host *host, char *buffer, unsigned int
remain)
{
void __iomem *base = host-base;
@@ -1129,7 +1166,8 @@ static irqreturn_t mmci_pio_irq(int irq, void *dev_id)
len = 0;
if (status MCI_RXACTIVE)
- len = mmci_pio_read(host, buffer, remain);
+ len = host-pio_read(host, buffer, remain);
+
if (status MCI_TXACTIVE)
len = mmci_pio_write(host, buffer, remain, status);
@@ -1504,6 +1542,11 @@ static int mmci_probe(struct amba_device *dev,
if (ret)
goto host_free;
+ if (variant-qcom_fifo)
+ host-pio_read = mmci_qcom_pio_read;
+ else
+ host-pio_read = mmci_pio_read;
+
host-plat = plat;
host-variant = variant;
host-mclk = clk_get_rate(host-clk);
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 1882e20..dc9fe0a 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -229,6 +229,7 @@ struct mmci_host {
/* pio stuff */
struct sg_mapping_iter sg_miter;
unsigned intsize;
+ int (*pio_read)(struct mmci_host *h, char *buf, unsigned int remain);
#ifdef CONFIG_DMA_ENGINE
/* DMA stuff */
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 13/13] mmc: mmci: Add Qcom specific pio_read function.
Sorry Stephen for late reply,
Some reason this mail was filtered in other folders.
On 24/05/14 00:28, Stephen Boyd wrote:
On 05/23/14 05:53, srinivas.kandaga...@linaro.org wrote:
@@ -1022,6 +1025,40 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command
*cmd,
}
}
+static int mmci_qcom_pio_read(struct mmci_host *host, char *buffer,
+ unsigned int remain)
+{
+ u32 *ptr = (u32 *) buffer;
+ unsigned int count = 0;
+ unsigned int words, bytes;
+ unsigned int fsize = host-variant-fifosize;
+
+ words = remain 2;
+ bytes = remain % 4;
+ /* read full words followed by leftover bytes */
+ if (words) {
+ while (readl(host-base + MMCISTATUS) MCI_RXDATAAVLBL) {
+ *ptr = readl(host-base + MMCIFIFO + (count % fsize));
This doesn't look endianness agnostic. Shouldn't we use ioread32_rep()
to read this fifo?
Is'nt readl endianess aware?
we can not use ioread32_rep because as we can not reliably know how many
words we should read? FIFOCNT would have helped but its not advised to
be use as per the datasheet.
Thanks,
srini
+ ptr++;
+ count += 4;
+ words--;
+ if (!words)
+ break;
+ }
+ }
+
+ if (unlikely(bytes)) {
+ unsigned char buf[4];
+ if (readl(host-base + MMCISTATUS) MCI_RXDATAAVLBL) {
+ *buf = readl(host-base + MMCIFIFO + (count % fsize));
+ memcpy(ptr, buf, bytes);
+ count += bytes;
+ }
+ }
+
+ return count;
+}
+
static int mmci_pio_read(struct mmci_host *host, char *buffer, unsigned int
remain)
{
void __iomem *base = host-base;
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] devicetree: bindings: Properly document micrel ks8851 SPI chips
Hello Stephen, On Tue, May 27, 2014 at 02:40:15PM -0700, Stephen Boyd wrote: On 05/24/14 05:48, Mark Brown wrote: On Fri, May 23, 2014 at 12:57:17PM -0700, Stephen Boyd wrote: Optional properties: -- vdd-supply: supply for Ethernet mac +- vdd-supply: analog 3.3V supply for Ethernet mac +- vdd-io-supply: digital 1.8V IO supply for Ethernet mac So, according to the datasheet I managed to find this device has a supply VDD_IO (so normally written vdd-io-supply here), some other supplies which are tied to VDD_IO (so can probably be omitted) and a supply VDD_A3.3 none of which are optional. There is an internal regulator which can be used to drop a higher voltage VDD_IO down for some of the supplies tied to it but that's essentially a noop from software as far as I can tell. None of these supplies are obviously optional, though I've not read the datasheet in detail so I may have missed something here. There is a difference between the supply being optional for the hardware to work and the need to specify it in the device tree, isn't it? My expectation is that when it's not specified there is just nothing the the software needs to care for. That said it looks like this is intended to be a supply for an external PHY rather than the device itself, but even so my original question about it being able to operate without power still applies. Looking at the code it's certainly not doing any of the handling of a missing supply that I would associate with using _optional(). I agree, both supplies don't look optional. Unfortunately efm32gg-dk3750.dts doesn't look to be listing any supply, and this driver only recently got support for the VDD_A3.3 supply that the omap board uses (adding Uwe for any comments on efm setup). I presume on If I read the schematic correctly there is nothing to regulate on the efm32 dev board. If you want to take a look on the schematic yourself, it's contained in the documentation package available at http://www.silabs.com/products/mcu/lowpower/pages/efm32gg-dk3750.aspx . BDR3201A_A02_sch.pdf, page 3 of 22. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ping a few qcom related pinctrl patches
Linus, Just wondering were we stood on: https://patchwork.kernel.org/patch/4144631/ https://patchwork.kernel.org/patch/4161061/ thanks - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] devicetree: bindings: Document micrel vendor prefix
On Thu, May 22, 2014 at 4:00 PM, Stephen Boyd sb...@codeaurora.org wrote: There's one existing use of 'micrel' in the documentation so use 'micrel' instead of the company's ticker symbol 'mcrl'. Cc: devicet...@vger.kernel.org Signed-off-by: Stephen Boyd sb...@codeaurora.org Applied for 3.16. Rob --- This is mostly here as the first patch to make checkpatch quiet. I expect DT maintainers to pick this one up. Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1bc2174e1a05..2fe06ad1d248 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -76,6 +76,7 @@ linux Linux-specific binding lsiLSI Corp. (LSI Logic) marvellMarvell Technology Group Ltd. maxim Maxim Integrated Products +micrel Micrel Inc. microchip Microchip Technology Inc. mosaixtech Mosaix Technologies, Inc. moxa Moxa -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Qualcomm Resource Power Manager driver
On May 27, 2014, at 12:28 PM, Bjorn Andersson bjorn.anders...@sonymobile.com wrote: This series adds a regulator driver for the Resource Power Manager found in Qualcomm 8660, 8960 and 8064 based devices. The RPM driver exposes resources to its child devices, that can be accessed to implement drivers for the regulators, clocks and bus frequency control that's owned by the RPM in these devices. Rather than adding yet another mfd driver, how about we put this in drivers/soc/qcom as a much better location for the low level rpm code. Some code already merged in arm-soc for creation of drivers/soc/qcom/ Bjorn Andersson (3): mfd: devicetree: bindings: Add Qualcomm RPM DT binding mfd: qcom-rpm: Driver for the Qualcomm RPM regulator: qcom-rpm: Regulator driver for the Qualcomm RPM Documentation/devicetree/bindings/mfd/qcom,rpm.txt | 283 +++ drivers/mfd/Kconfig| 15 + drivers/mfd/Makefile | 1 + drivers/mfd/qcom_rpm.c | 554 ++ drivers/regulator/Kconfig | 12 + drivers/regulator/Makefile | 1 + drivers/regulator/qcom_rpm-regulator.c | 852 + include/dt-bindings/mfd/qcom_rpm.h | 148 include/linux/mfd/qcom_rpm.h | 13 + 9 files changed, 1879 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/qcom,rpm.txt create mode 100644 drivers/mfd/qcom_rpm.c create mode 100644 drivers/regulator/qcom_rpm-regulator.c create mode 100644 include/dt-bindings/mfd/qcom_rpm.h create mode 100644 include/linux/mfd/qcom_rpm.h - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mfd: devicetree: bindings: Add Qualcomm RPM DT binding
On May 27, 2014, at 12:28 PM, Bjorn Andersson bjorn.anders...@sonymobile.com wrote: Add binding for the Qualcomm Resource Power Manager (RPM) found in 8660, 8960 and 8064 based devices. The binding currently describes the rpm itself and the regulator subnodes. Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com --- Documentation/devicetree/bindings/mfd/qcom,rpm.txt | 284 + include/dt-bindings/mfd/qcom_rpm.h | 142 +++ 2 files changed, 426 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/qcom,rpm.txt create mode 100644 include/dt-bindings/mfd/qcom_rpm.h diff --git a/Documentation/devicetree/bindings/mfd/qcom,rpm.txt b/Documentation/devicetree/bindings/mfd/qcom,rpm.txt new file mode 100644 index 000..3908a5d --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/qcom,rpm.txt @@ -0,0 +1,284 @@ +Qualcomm Resource Power Manager (RPM) + +This driver is used to interface with the Resource Power Manager (RPM) found in +various Qualcomm platforms. The RPM allows each component in the system to vote +for state of the system resources, such as clocks, regulators and bus +frequencies. + +- compatible: + Usage: required + Value type: string + Definition: must be one of: + qcom,rpm-apq8064 + qcom,rpm-msm8660 + qcom,rpm-msm8960 + +- reg: + Usage: required + Value type: prop-encoded-array + Definition: two entries specifying the RPM's message ram and ipc register + +- reg-names: + Usage: required + Value type: string-array + Definition: must contain the following, in order: + msg_ram + “ipc If order maters, it should be on reg not reg-names. If order doesn’t mater than this should say the names should match the reg + +- interrupts: + Usage: required + Value type: prop-encoded-array + Definition: three entries specifying the RPM's: + 1. acknowledgement interrupt + 2. error interrupt + 3. wakeup interrupt + +- interrupt-names: + Usage: required + Value type: string-array + Definition: must be the three strings ack, err and wakeup, in order again, if order maters it should be with the interrupts prop, not the name. + +- #address-cells: + Usage: required + Value type: u32 + Definition: must be 1 + +- #size-cells: + Usage: required + Value type: u32 + Definition: must be 0 + + += SUBDEVICES + +The RPM exposes resources to its subnodes. The below bindings specify the set +of valid subnodes that can operate on these resources. + +== Switch-mode Power Supply regulator + +- compatible: + Usage: required + Value type: string + Definition: must be one of: + qcom,rpm-pm8058-smps + qcom,rpm-pm8901-ftsmps + qcom,rpm-pm8921-smps + qcom,rpm-pm8921-ftsmps + +- reg: + Usage: required + Value type: u32 + Definition: resource as defined in dt-bindings/mfd/qcom_rpm.h Can we provide a bit more description about what “namespace” this reg is work in. + +- qcom,switch-mode-frequency: + Usage: required + Value type: u32 + Definition: Frequency (Hz) of the switch-mode power supply; + must be one of: + 1920, 960, 640, 480, 384, 320, + 274, 240, 213, 192, 175, 160, + 148, 137, 128, 120 + +- qcom,hpm-threshold: + Usage: optional + Value type: u32 + Definition: indicates the breaking point at which the regulator should + switch to high power mode in what units? + +- qcom,load-bias: + Usage: optional + Value type: u32 + Definition: specifies a base load on the specific regulator in what units? + +- qcom,boot-load: + Usage: optional + Value type: u32 + Definition: specifies the configured load on boot for the specific + regulator in what units? + +- qcom,force-mode-none: + Usage: optional (default if no other qcom,force-mode is specified) + Value type: empty + Defintion: indicates that the regulator should not be forced to any +particular mode + +- qcom,force-mode-lpm: + Usage: optional + Value type: empty + Definition: indicates that the regulator should be forced to operate in + low-power-mode + +- qcom,force-mode-auto: + Usage: optional (only available for 8960/8064) + Value type: empty + Definition: indicates that the regulator should be automatically pick + operating mode + +- qcom,force-mode-hpm: + Usage: optional (only available for 8960/8064) + Value type: empty + Definition: indicates that the regulator
Re: [PATCH v2 1/4] devicetree: bindings: Properly document micrel ks8851 SPI chips
On Wed, May 28, 2014 at 10:16 AM, Uwe Kleine-König u.kleine-koe...@pengutronix.de wrote: Hello Stephen, On Tue, May 27, 2014 at 02:40:15PM -0700, Stephen Boyd wrote: On 05/24/14 05:48, Mark Brown wrote: On Fri, May 23, 2014 at 12:57:17PM -0700, Stephen Boyd wrote: Optional properties: -- vdd-supply: supply for Ethernet mac +- vdd-supply: analog 3.3V supply for Ethernet mac +- vdd-io-supply: digital 1.8V IO supply for Ethernet mac So, according to the datasheet I managed to find this device has a supply VDD_IO (so normally written vdd-io-supply here), some other supplies which are tied to VDD_IO (so can probably be omitted) and a supply VDD_A3.3 none of which are optional. There is an internal regulator which can be used to drop a higher voltage VDD_IO down for some of the supplies tied to it but that's essentially a noop from software as far as I can tell. None of these supplies are obviously optional, though I've not read the datasheet in detail so I may have missed something here. There is a difference between the supply being optional for the hardware to work and the need to specify it in the device tree, isn't it? My expectation is that when it's not specified there is just nothing the the software needs to care for. Yes, agreed. Of course you could have cases where a supply at the h/w level is optional like if a supply can be powered externally or via an internal regulator. Those cases will have to be made clear in the binding, but a heading Optional properties in a binding doc means properties which are optional to specify in DT. Rob -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] regulator: qcom-rpm: Regulator driver for the Qualcomm RPM
On Tue, May 27, 2014 at 10:28:41AM -0700, Bjorn Andersson wrote:
+static int rpm_reg_set_voltage(struct regulator_dev *rdev,
+int min_uV, int max_uV,
+unsigned *selector)
+{
+ struct qcom_rpm_reg *vreg = rdev_get_drvdata(rdev);
+ const struct rpm_reg_parts *parts = vreg-parts;
+ const struct request_member *req;
+ int ret = 0;
+ int sel;
+ int val;
+ int uV;
+
+ dev_dbg(vreg-dev, set_voltage(%d, %d)\n, min_uV, max_uV);
+
+ if (parts-uV.mask == 0 parts-mV.mask == 0)
+ return -EINVAL;
+
+ /*
+ * Snap to the voltage to a supported level.
+ */
What is snapping a voltage?
+ sel = regulator_map_voltage_linear_range(rdev, min_uV, max_uV);
Don't open code mapping the voltage, just implement set_voltage_sel().
+ mutex_lock(vreg-lock);
+ if (parts-uV.mask)
+ req = parts-uV;
+ else if (parts-mV.mask)
+ req = parts-mV;
+ else
+ req = parts-enable_state;
Just implement separate operations for the regulators with different
register definitions. It's going to simplify the code.
+static int rpm_reg_set_mode(struct regulator_dev *rdev, unsigned int mode)
+{
+ struct qcom_rpm_reg *vreg = rdev_get_drvdata(rdev);
+ const struct rpm_reg_parts *parts = vreg-parts;
+ int max_mA = parts-ip.mask parts-ip.shift;
+ int load_mA;
+ int ret;
+
+ if (mode == REGULATOR_MODE_IDLE)
+ load_mA = vreg-idle_uA / 1000;
+ else
+ load_mA = vreg-normal_uA / 1000;
+
+ if (load_mA max_mA)
+ load_mA = max_mA;
+
+ mutex_lock(vreg-lock);
+ ret = rpm_reg_write(vreg, parts-ip, load_mA);
+ if (!ret)
+ vreg-mode = mode;
+ mutex_unlock(vreg-lock);
I'm not entirely sure what this is intended to do. It looks like it's
doing something to do with current limits but it's a set_mode(). Some
documentation might help. It should also be implementing only specific
modes and rejecting unsupported modes, if we do the same operation to
the device for two different modes that seems wrong.
+static unsigned int rpm_reg_get_optimum_mode(struct regulator_dev *rdev,
+ int input_uV,
+ int output_uV,
+ int load_uA)
+{
+ struct qcom_rpm_reg *vreg = rdev_get_drvdata(rdev);
+
+ load_uA += vreg-load_bias_uA;
+
+ if (load_uA vreg-hpm_threshold_uA) {
+ vreg-idle_uA = load_uA;
+ return REGULATOR_MODE_IDLE;
+ } else {
+ vreg-normal_uA = load_uA;
+ return REGULATOR_MODE_NORMAL;
+ }
+}
This looks very broken - why are we storing anything here? What is the
stored value supposed to do?
+ if (vreg-parts-ip.mask) {
+ initdata-constraints.valid_ops_mask |= REGULATOR_CHANGE_DRMS;
+ initdata-constraints.valid_ops_mask |= REGULATOR_CHANGE_MODE;
+ initdata-constraints.valid_modes_mask |= REGULATOR_MODE_NORMAL;
+ initdata-constraints.valid_modes_mask |= REGULATOR_MODE_IDLE;
No, this is just plain broken. Constraints are set by the *board*, you
don't know if these settings are safe on any given board.
+static int __init rpm_reg_init(void)
+{
+ return platform_driver_register(rpm_reg_driver);
+}
+arch_initcall(rpm_reg_init);
+
+static void __exit rpm_reg_exit(void)
+{
+ platform_driver_unregister(rpm_reg_driver);
+}
+module_exit(rpm_reg_exit)
module_platform_driver() or if you must bodge the init order at least
use subsys_initcall() like everyone else.
signature.asc
Description: Digital signature
Re: [PATCH 0/3] Qualcomm Resource Power Manager driver
On Wed, May 28, 2014 at 9:23 AM, Kumar Gala ga...@codeaurora.org wrote: On May 27, 2014, at 12:28 PM, Bjorn Andersson bjorn.anders...@sonymobile.com wrote: This series adds a regulator driver for the Resource Power Manager found in Qualcomm 8660, 8960 and 8064 based devices. The RPM driver exposes resources to its child devices, that can be accessed to implement drivers for the regulators, clocks and bus frequency control that's owned by the RPM in these devices. Rather than adding yet another mfd driver, how about we put this in drivers/soc/qcom as a much better location for the low level rpm code. Some code already merged in arm-soc for creation of drivers/soc/qcom/ Hi Kumar, I do see rpm as somewhat equivalent to a pmic and that was why I followed suite and put it in mfd, but I can of course move it if you prefer. Lately I've been working on rpm, rpm-smd, smem, smd, smsm, smp2p patches for mainline. It could be argued that smd is a bus and should go in drivers/bus, but for the rest I fear that we just created drivers/soc/qcom as another dumping ground for things; a Qualcomm specific drivers/mfd. But maybe that is the purpose of it ;) If I move the rpm driver, are there any conclusion to where I should move the dt binding documentation? Regards, Bjorn -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Qualcomm Resource Power Manager driver
On May 28, 2014, at 11:59 AM, Bjorn Andersson bj...@kryo.se wrote: On Wed, May 28, 2014 at 9:23 AM, Kumar Gala ga...@codeaurora.org wrote: On May 27, 2014, at 12:28 PM, Bjorn Andersson bjorn.anders...@sonymobile.com wrote: This series adds a regulator driver for the Resource Power Manager found in Qualcomm 8660, 8960 and 8064 based devices. The RPM driver exposes resources to its child devices, that can be accessed to implement drivers for the regulators, clocks and bus frequency control that's owned by the RPM in these devices. Rather than adding yet another mfd driver, how about we put this in drivers/soc/qcom as a much better location for the low level rpm code. Some code already merged in arm-soc for creation of drivers/soc/qcom/ Hi Kumar, I do see rpm as somewhat equivalent to a pmic and that was why I followed suite and put it in mfd, but I can of course move it if you prefer. Lately I've been working on rpm, rpm-smd, smem, smd, smsm, smp2p patches for mainline. It could be argued that smd is a bus and should go in drivers/bus, but for the rest I fear that we just created drivers/soc/qcom as another dumping ground for things; a Qualcomm specific drivers/mfd. But maybe that is the purpose of it ;) It is the purpose so that as we see common patterns between either drivers/soc/VENDOR we can refactor in the future. However, we need to all a little time for those patterns to emerge rather than shoe horning in drivers into places that don’t make sense. If I move the rpm driver, are there any conclusion to where I should move the dt binding documentation? devicetree/bindings/soc/qcom include/dt-bindings/soc Regards, Bjorn - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] devicetree: bindings: Properly document micrel ks8851 SPI chips
On Wed, May 28, 2014 at 05:16:46PM +0200, Uwe Kleine-König wrote: On Tue, May 27, 2014 at 02:40:15PM -0700, Stephen Boyd wrote: On 05/24/14 05:48, Mark Brown wrote: So, according to the datasheet I managed to find this device has a supply VDD_IO (so normally written vdd-io-supply here), some other supplies which are tied to VDD_IO (so can probably be omitted) and a supply VDD_A3.3 none of which are optional. There is an internal regulator which can be used to drop a higher voltage VDD_IO down for some of the supplies tied to it but that's essentially a noop from software as far as I can tell. None of these supplies are obviously optional, though I've not read the datasheet in detail so I may have missed something here. There is a difference between the supply being optional for the hardware to work and the need to specify it in the device tree, isn't it? My expectation is that when it's not specified there is just nothing the the software needs to care for. If the supply must always be physically present the bindings should be specified as it being mandatory and the code written in that fashion; as an extension Linux will put a dummy in but this is attempting to handle incorrect DTs. This means we have functional error handling in cases where there is something to worry about and simplifies the code using the regulator. regulator_get_optional() should *only* be used if the supply may be omitted from the physical design and should generally always be accompanied by code which does something substantially different such as using an internal regulator or changing the source for a reference voltage instead. That said it looks like this is intended to be a supply for an external PHY rather than the device itself, but even so my original question about it being able to operate without power still applies. Looking at the code it's certainly not doing any of the handling of a missing supply that I would associate with using _optional(). I agree, both supplies don't look optional. Unfortunately efm32gg-dk3750.dts doesn't look to be listing any supply, and this driver only recently got support for the VDD_A3.3 supply that the omap board uses (adding Uwe for any comments on efm setup). I presume on If I read the schematic correctly there is nothing to regulate on the efm32 dev board. If you want to take a look on the schematic yourself, it's contained in the documentation package available at http://www.silabs.com/products/mcu/lowpower/pages/efm32gg-dk3750.aspx . BDR3201A_A02_sch.pdf, page 3 of 22. That shows all the supplies connected to fixed voltage regulators (including the internal 1.8V LDO); the device tree should represent this accurately though the internal 1.8V regulator could be omitted for simplicity. It would be a remarkable device that was able to operate without power. signature.asc Description: Digital signature
[PATCH v3] ARM: qcom: Add initial APQ8064 SoC and IFC6410 board device trees
Add basic APQ8064 SoC include device tree and support for basic booting on
the IFC6410 board. Also, keep dtb build list and qcom_dt_match in sorted
order.
Signed-off-by: Kumar Gala ga...@codeaurora.org
---
v3:
* Cleanup cpu node to have compatible enable-method per node and
not in the container
* Dropped l2-cache interrupt prop as its not part of any binding
* Cleanup reg whitespace
v2:
* created a v2.0 apq8064.dtsi to handle differences in Si rev in future
* changed /include/ to #include
* added PMU node
* dropped interrupts from cpus node, not currently part of binding
arch/arm/boot/dts/Makefile | 8 +-
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 16 +++
arch/arm/boot/dts/qcom-apq8064-v2.0.dtsi | 1 +
arch/arm/boot/dts/qcom-apq8064.dtsi| 170 +
arch/arm/mach-qcom/board.c | 3 +-
5 files changed, 194 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
create mode 100644 arch/arm/boot/dts/qcom-apq8064-v2.0.dtsi
create mode 100644 arch/arm/boot/dts/qcom-apq8064.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 35c146f..c58624f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -291,9 +291,11 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
dra7-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
-dtb-$(CONFIG_ARCH_QCOM) += qcom-msm8660-surf.dtb \
- qcom-msm8960-cdp.dtb \
- qcom-apq8074-dragonboard.dtb
+dtb-$(CONFIG_ARCH_QCOM) += \
+ qcom-apq8064-ifc6410.dtb \
+ qcom-apq8074-dragonboard.dtb \
+ qcom-msm8660-surf.dtb \
+ qcom-msm8960-cdp.dtb
dtb-$(CONFIG_ARCH_U8500) += ste-snowball.dtb \
ste-hrefprev60-stuib.dtb \
ste-hrefprev60-tvk.dtb \
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
new file mode 100644
index 000..7c2441d
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -0,0 +1,16 @@
+#include qcom-apq8064-v2.0.dtsi
+
+/ {
+ model = Qualcomm APQ8064/IFC6410;
+ compatible = qcom,apq8064-ifc6410, qcom,apq8064;
+
+ soc {
+ gsbi@1660 {
+ status = ok;
+ qcom,mode = GSBI_PROT_I2C_UART;
+ serial@1664 {
+ status = ok;
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/qcom-apq8064-v2.0.dtsi
b/arch/arm/boot/dts/qcom-apq8064-v2.0.dtsi
new file mode 100644
index 000..935c394
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8064-v2.0.dtsi
@@ -0,0 +1 @@
+#include qcom-apq8064.dtsi
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
new file mode 100644
index 000..e8a3423
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -0,0 +1,170 @@
+/dts-v1/;
+
+#include skeleton.dtsi
+#include dt-bindings/clock/qcom,gcc-msm8960.h
+#include dt-bindings/soc/qcom,gsbi.h
+
+/ {
+ model = Qualcomm APQ8064;
+ compatible = qcom,apq8064;
+ interrupt-parent = intc;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ compatible = qcom,krait;
+ enable-method = qcom,kpss-acc-v1;
+ device_type = cpu;
+ reg = 0;
+ next-level-cache = L2;
+ qcom,acc = acc0;
+ qcom,saw = saw0;
+ };
+
+ cpu@1 {
+ compatible = qcom,krait;
+ enable-method = qcom,kpss-acc-v1;
+ device_type = cpu;
+ reg = 1;
+ next-level-cache = L2;
+ qcom,acc = acc1;
+ qcom,saw = saw1;
+ };
+
+ cpu@2 {
+ compatible = qcom,krait;
+ enable-method = qcom,kpss-acc-v1;
+ device_type = cpu;
+ reg = 2;
+ next-level-cache = L2;
+ qcom,acc = acc2;
+ qcom,saw = saw2;
+ };
+
+ cpu@3 {
+ compatible = qcom,krait;
+ enable-method = qcom,kpss-acc-v1;
+ device_type = cpu;
+ reg = 3;
+ next-level-cache = L2;
+ qcom,acc = acc3;
+ qcom,saw = saw3;
+ };
+
+ L2: l2-cache {
+ compatible = cache;
+ cache-level = 2;
+ };
+ };
+
+ cpu-pmu {
+ compatible = qcom,krait-pmu;
+ interrupts = 1 10 0x304;
+ };
[PATCH] ARM: dts: qcom: Update msm8974/apq8074 device trees
* Move SoC peripherals into an SoC container node
* Move serial enabling into board file (qcom-apq8074-dragonboard.dts)
* Move spi pinctrl into board file
* Cleanup cpu node to match binding spec, enable-method and compatible
should be per cpu, not part of the container
* Drop interrupts property from l2-cache node as its not part of the
binding spec
Signed-off-by: Kumar Gala ga...@codeaurora.org
---
arch/arm/boot/dts/qcom-apq8074-dragonboard.dts | 28 ++-
arch/arm/boot/dts/qcom-msm8974.dtsi| 31 --
2 files changed, 36 insertions(+), 23 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
index 92320c4..b4dfb01 100644
--- a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
@@ -4,7 +4,11 @@
model = Qualcomm APQ8074 Dragonboard;
compatible = qcom,apq8074-dragonboard, qcom,apq8074;
- soc: soc {
+ soc {
+ serial@f991e000 {
+ status = ok;
+ };
+
sdhci@f9824900 {
bus-width = 8;
non-removable;
@@ -15,5 +19,27 @@
cd-gpios = msmgpio 62 0x1;
bus-width = 4;
};
+
+
+ pinctrl@fd51 {
+ spi8_default: spi8_default {
+ mosi {
+ pins = gpio45;
+ function = blsp_spi8;
+ };
+ miso {
+ pins = gpio46;
+ function = blsp_spi8;
+ };
+ cs {
+ pins = gpio47;
+ function = blsp_spi8;
+ };
+ clk {
+ pins = gpio48;
+ function = blsp_spi8;
+ };
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index c530a33..b0716c1 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -13,10 +13,10 @@
#address-cells = 1;
#size-cells = 0;
interrupts = 1 9 0xf04;
- compatible = qcom,krait;
- enable-method = qcom,kpss-acc-v2;
cpu@0 {
+ compatible = qcom,krait;
+ enable-method = qcom,kpss-acc-v2;
device_type = cpu;
reg = 0;
next-level-cache = L2;
@@ -24,6 +24,8 @@
};
cpu@1 {
+ compatible = qcom,krait;
+ enable-method = qcom,kpss-acc-v2;
device_type = cpu;
reg = 1;
next-level-cache = L2;
@@ -31,6 +33,8 @@
};
cpu@2 {
+ compatible = qcom,krait;
+ enable-method = qcom,kpss-acc-v2;
device_type = cpu;
reg = 2;
next-level-cache = L2;
@@ -38,6 +42,8 @@
};
cpu@3 {
+ compatible = qcom,krait;
+ enable-method = qcom,kpss-acc-v2;
device_type = cpu;
reg = 3;
next-level-cache = L2;
@@ -47,7 +53,6 @@
L2: l2-cache {
compatible = cache;
cache-level = 2;
- interrupts = 0 2 0x4;
qcom,saw = saw_l2;
};
};
@@ -190,6 +195,7 @@
interrupts = 0 108 0x0;
clocks = gcc GCC_BLSP1_UART2_APPS_CLK, gcc
GCC_BLSP1_AHB_CLK;
clock-names = core, iface;
+ status = disabled;
};
sdhci@f9824900 {
@@ -229,25 +235,6 @@
interrupt-controller;
#interrupt-cells = 2;
interrupts = 0 208 0;
-
- spi8_default: spi8_default {
- mosi {
- pins = gpio45;
- function = blsp_spi8;
- };
- miso {
- pins = gpio46;
- function = blsp_spi8;
- };
-
[PATCH] ARM: dts: qcom: Update msm8660 device trees
* Move SoC peripherals into an SoC container node
* Move serial enabling into board file (qcom-msm8660-surf.dts)
* Cleanup cpu node to match binding spec, enable-method and compatible
should be per cpu, not part of the container
Signed-off-by: Kumar Gala ga...@codeaurora.org
---
arch/arm/boot/dts/qcom-msm8660-surf.dts | 6 ++
arch/arm/boot/dts/qcom-msm8660.dtsi | 104 +---
2 files changed, 63 insertions(+), 47 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8660-surf.dts
b/arch/arm/boot/dts/qcom-msm8660-surf.dts
index 169bad9..13f5a78 100644
--- a/arch/arm/boot/dts/qcom-msm8660-surf.dts
+++ b/arch/arm/boot/dts/qcom-msm8660-surf.dts
@@ -3,4 +3,10 @@
/ {
model = Qualcomm MSM8660 SURF;
compatible = qcom,msm8660-surf, qcom,msm8660;
+
+ soc {
+ serial@19c4 {
+ status = ok;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/qcom-msm8660.dtsi
b/arch/arm/boot/dts/qcom-msm8660.dtsi
index c52a9e9..41bc38b 100644
--- a/arch/arm/boot/dts/qcom-msm8660.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8660.dtsi
@@ -12,16 +12,18 @@
cpus {
#address-cells = 1;
#size-cells = 0;
- compatible = qcom,scorpion;
- enable-method = qcom,gcc-msm8660;
cpu@0 {
+ compatible = qcom,scorpion;
+ enable-method = qcom,gcc-msm8660;
device_type = cpu;
reg = 0;
next-level-cache = L2;
};
cpu@1 {
+ compatible = qcom,scorpion;
+ enable-method = qcom,gcc-msm8660;
device_type = cpu;
reg = 1;
next-level-cache = L2;
@@ -33,55 +35,63 @@
};
};
- intc: interrupt-controller@208 {
- compatible = qcom,msm-8660-qgic;
- interrupt-controller;
- #interrupt-cells = 3;
- reg = 0x0208 0x1000 ,
- 0x02081000 0x1000 ;
- };
+ soc: soc {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ compatible = simple-bus;
- timer@200 {
- compatible = qcom,scss-timer, qcom,msm-timer;
- interrupts = 1 0 0x301,
-1 1 0x301,
-1 2 0x301;
- reg = 0x0200 0x100;
- clock-frequency = 2700,
- 32768;
- cpu-offset = 0x4;
- };
+ intc: interrupt-controller@208 {
+ compatible = qcom,msm-8660-qgic;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x0208 0x1000 ,
+ 0x02081000 0x1000 ;
+ };
- msmgpio: gpio@80 {
- compatible = qcom,msm-gpio;
- reg = 0x0080 0x4000;
- gpio-controller;
- #gpio-cells = 2;
- ngpio = 173;
- interrupts = 0 16 0x4;
- interrupt-controller;
- #interrupt-cells = 2;
- };
+ timer@200 {
+ compatible = qcom,scss-timer, qcom,msm-timer;
+ interrupts = 1 0 0x301,
+1 1 0x301,
+1 2 0x301;
+ reg = 0x0200 0x100;
+ clock-frequency = 2700,
+ 32768;
+ cpu-offset = 0x4;
+ };
- gcc: clock-controller@90 {
- compatible = qcom,gcc-msm8660;
- #clock-cells = 1;
- #reset-cells = 1;
- reg = 0x90 0x4000;
- };
+ msmgpio: gpio@80 {
+ compatible = qcom,msm-gpio;
+ reg = 0x0080 0x4000;
+ gpio-controller;
+ #gpio-cells = 2;
+ ngpio = 173;
+ interrupts = 0 16 0x4;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
- serial@19c4 {
- compatible = qcom,msm-uartdm-v1.3, qcom,msm-uartdm;
- reg = 0x19c4 0x1000,
- 0x19c0 0x1000;
- interrupts = 0 195 0x0;
- clocks = gcc GSBI12_UART_CLK, gcc GSBI12_H_CLK;
- clock-names = core, iface;
- };
+ gcc: clock-controller@90 {
+ compatible = qcom,gcc-msm8660;
+ #clock-cells = 1;
+ #reset-cells = 1;
+
[PATCH] ARM: dts: qcom: Update msm8960 device trees
* Move SoC peripherals into an SoC container node
* Move serial enabling into board file (qcom-msm8960-cdp.dts)
* Cleanup cpu node to match binding spec, enable-method and compatible
should be per cpu, not part of the container
* Drop interrupts property from l2-cache node as its not part of the
binding spec
Signed-off-by: Kumar Gala ga...@codeaurora.org
---
arch/arm/boot/dts/qcom-msm8960-cdp.dts | 6 ++
arch/arm/boot/dts/qcom-msm8960.dtsi| 165 +
2 files changed, 93 insertions(+), 78 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8960-cdp.dts
b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
index a58fb88..8e77ed7 100644
--- a/arch/arm/boot/dts/qcom-msm8960-cdp.dts
+++ b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
@@ -3,4 +3,10 @@
/ {
model = Qualcomm MSM8960 CDP;
compatible = qcom,msm8960-cdp, qcom,msm8960;
+
+ soc {
+ serial@1644 {
+ status = ok;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/qcom-msm8960.dtsi
b/arch/arm/boot/dts/qcom-msm8960.dtsi
index 997b7b9..c38e54c 100644
--- a/arch/arm/boot/dts/qcom-msm8960.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8960.dtsi
@@ -13,10 +13,10 @@
#address-cells = 1;
#size-cells = 0;
interrupts = 1 14 0x304;
- compatible = qcom,krait;
- enable-method = qcom,kpss-acc-v1;
cpu@0 {
+ compatible = qcom,krait;
+ enable-method = qcom,kpss-acc-v1;
device_type = cpu;
reg = 0;
next-level-cache = L2;
@@ -25,6 +25,8 @@
};
cpu@1 {
+ compatible = qcom,krait;
+ enable-method = qcom,kpss-acc-v1;
device_type = cpu;
reg = 1;
next-level-cache = L2;
@@ -35,7 +37,6 @@
L2: l2-cache {
compatible = cache;
cache-level = 2;
- interrupts = 0 2 0x4;
};
};
@@ -45,91 +46,99 @@
qcom,no-pc-write;
};
- intc: interrupt-controller@200 {
- compatible = qcom,msm-qgic2;
- interrupt-controller;
- #interrupt-cells = 3;
- reg = 0x0200 0x1000 ,
- 0x02002000 0x1000 ;
- };
+ soc: soc {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ compatible = simple-bus;
+
+ intc: interrupt-controller@200 {
+ compatible = qcom,msm-qgic2;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x0200 0x1000,
+ 0x02002000 0x1000;
+ };
- timer@200a000 {
- compatible = qcom,kpss-timer, qcom,msm-timer;
- interrupts = 1 1 0x301,
-1 2 0x301,
-1 3 0x301;
- reg = 0x0200a000 0x100;
- clock-frequency = 2700,
- 32768;
- cpu-offset = 0x8;
- };
+ timer@200a000 {
+ compatible = qcom,kpss-timer, qcom,msm-timer;
+ interrupts = 1 1 0x301,
+1 2 0x301,
+1 3 0x301;
+ reg = 0x0200a000 0x100;
+ clock-frequency = 2700,
+ 32768;
+ cpu-offset = 0x8;
+ };
- msmgpio: gpio@80 {
- compatible = qcom,msm-gpio;
- gpio-controller;
- #gpio-cells = 2;
- ngpio = 150;
- interrupts = 0 16 0x4;
- interrupt-controller;
- #interrupt-cells = 2;
- reg = 0x80 0x4000;
- };
+ msmgpio: gpio@80 {
+ compatible = qcom,msm-gpio;
+ gpio-controller;
+ #gpio-cells = 2;
+ ngpio = 150;
+ interrupts = 0 16 0x4;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ reg = 0x80 0x4000;
+ };
- gcc: clock-controller@90 {
- compatible = qcom,gcc-msm8960;
- #clock-cells = 1;
- #reset-cells = 1;
- reg = 0x90 0x4000;
- };
+ gcc: clock-controller@90 {
+ compatible = qcom,gcc-msm8960;
+ #clock-cells = 1;
+ #reset-cells = 1;
+ reg =
[PATCH v2] ARM: dts: qcom: Update msm8974/apq8074 device trees
* Move SoC peripherals into an SoC container node
* Move serial enabling into board file (qcom-apq8074-dragonboard.dts)
* Move spi pinctrl into board file
* Cleanup cpu node to match binding spec, enable-method and compatible
should be per cpu, not part of the container
* Drop interrupts property from l2-cache node as its not part of the
binding spec
* Move timer node out of SoC container
Signed-off-by: Kumar Gala ga...@codeaurora.org
---
v2:
* Move timer node out of SoC container
arch/arm/boot/dts/qcom-apq8074-dragonboard.dts | 28 ++-
arch/arm/boot/dts/qcom-msm8974.dtsi| 49 ++
2 files changed, 45 insertions(+), 32 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
index 92320c4..b4dfb01 100644
--- a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
@@ -4,7 +4,11 @@
model = Qualcomm APQ8074 Dragonboard;
compatible = qcom,apq8074-dragonboard, qcom,apq8074;
- soc: soc {
+ soc {
+ serial@f991e000 {
+ status = ok;
+ };
+
sdhci@f9824900 {
bus-width = 8;
non-removable;
@@ -15,5 +19,27 @@
cd-gpios = msmgpio 62 0x1;
bus-width = 4;
};
+
+
+ pinctrl@fd51 {
+ spi8_default: spi8_default {
+ mosi {
+ pins = gpio45;
+ function = blsp_spi8;
+ };
+ miso {
+ pins = gpio46;
+ function = blsp_spi8;
+ };
+ cs {
+ pins = gpio47;
+ function = blsp_spi8;
+ };
+ clk {
+ pins = gpio48;
+ function = blsp_spi8;
+ };
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index c530a33..69dca2a 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -13,10 +13,10 @@
#address-cells = 1;
#size-cells = 0;
interrupts = 1 9 0xf04;
- compatible = qcom,krait;
- enable-method = qcom,kpss-acc-v2;
cpu@0 {
+ compatible = qcom,krait;
+ enable-method = qcom,kpss-acc-v2;
device_type = cpu;
reg = 0;
next-level-cache = L2;
@@ -24,6 +24,8 @@
};
cpu@1 {
+ compatible = qcom,krait;
+ enable-method = qcom,kpss-acc-v2;
device_type = cpu;
reg = 1;
next-level-cache = L2;
@@ -31,6 +33,8 @@
};
cpu@2 {
+ compatible = qcom,krait;
+ enable-method = qcom,kpss-acc-v2;
device_type = cpu;
reg = 2;
next-level-cache = L2;
@@ -38,6 +42,8 @@
};
cpu@3 {
+ compatible = qcom,krait;
+ enable-method = qcom,kpss-acc-v2;
device_type = cpu;
reg = 3;
next-level-cache = L2;
@@ -47,7 +53,6 @@
L2: l2-cache {
compatible = cache;
cache-level = 2;
- interrupts = 0 2 0x4;
qcom,saw = saw_l2;
};
};
@@ -57,6 +62,15 @@
interrupts = 1 7 0xf04;
};
+ timer {
+ compatible = arm,armv7-timer;
+ interrupts = 1 2 0xf08,
+1 3 0xf08,
+1 4 0xf08,
+1 1 0xf08;
+ clock-frequency = 1920;
+ };
+
soc: soc {
#address-cells = 1;
#size-cells = 1;
@@ -71,15 +85,6 @@
0xf9002000 0x1000;
};
- timer {
- compatible = arm,armv7-timer;
- interrupts = 1 2 0xf08,
-1 3 0xf08,
-1 4 0xf08,
-1 1 0xf08;
- clock-frequency =
Re: ping a few qcom related pinctrl patches
On Wed, May 28, 2014 at 6:18 PM, Kumar Gala ga...@codeaurora.org wrote: Just wondering were we stood on: https://patchwork.kernel.org/patch/4144631/ https://patchwork.kernel.org/patch/4161061/ I have never seen them before in my life :-D I don't pick patches from linux-arm-msm as I'm not even subscribed. Send them to linux-ker...@vger.kernel.org with me on the To: line and include Björn Andersson on CC as maintainer. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ping a few qcom related pinctrl patches
On May 28, 2014, at 2:05 PM, Linus Walleij linus.wall...@linaro.org wrote: On Wed, May 28, 2014 at 6:18 PM, Kumar Gala ga...@codeaurora.org wrote: Just wondering were we stood on: https://patchwork.kernel.org/patch/4144631/ https://patchwork.kernel.org/patch/4161061/ I have never seen them before in my life :-D I don't pick patches from linux-arm-msm as I'm not even subscribed. Send them to linux-ker...@vger.kernel.org with me on the To: line and include Björn Andersson on CC as maintainer. Yours, Linus Walleij Odd, they where sent to you and CC to lkml, The 8x74 was even ack’d by Bjorn. https://lkml.org/lkml/2014/5/9/461 https://lkml.org/lkml/2014/5/12/598 - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] devicetree: bindings: Properly document micrel ks8851 SPI chips
On 05/28/14 10:12, Mark Brown wrote: On Wed, May 28, 2014 at 05:16:46PM +0200, Uwe Kleine-König wrote: On Tue, May 27, 2014 at 02:40:15PM -0700, Stephen Boyd wrote: On 05/24/14 05:48, Mark Brown wrote: So, according to the datasheet I managed to find this device has a supply VDD_IO (so normally written vdd-io-supply here), some other supplies which are tied to VDD_IO (so can probably be omitted) and a supply VDD_A3.3 none of which are optional. There is an internal regulator which can be used to drop a higher voltage VDD_IO down for some of the supplies tied to it but that's essentially a noop from software as far as I can tell. None of these supplies are obviously optional, though I've not read the datasheet in detail so I may have missed something here. There is a difference between the supply being optional for the hardware to work and the need to specify it in the device tree, isn't it? My expectation is that when it's not specified there is just nothing the the software needs to care for. If the supply must always be physically present the bindings should be specified as it being mandatory and the code written in that fashion; as an extension Linux will put a dummy in but this is attempting to handle incorrect DTs. This means we have functional error handling in cases where there is something to worry about and simplifies the code using the regulator. Ok, you're saying the opposite of Rob. Should it be required or optional in the DT binding? regulator_get_optional() should *only* be used if the supply may be omitted from the physical design and should generally always be accompanied by code which does something substantially different such as using an internal regulator or changing the source for a reference voltage instead. Ok. Dave M has already picked up all these patches so I'll send a patch to replace regulator_get_optional() with regulator_get() and fix up the error handling unless I hear otherwise. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] devicetree: bindings: Properly document micrel ks8851 SPI chips
On Wed, May 28, 2014 at 12:44:35PM -0700, Stephen Boyd wrote: On 05/28/14 10:12, Mark Brown wrote: If the supply must always be physically present the bindings should be specified as it being mandatory and the code written in that fashion; as an extension Linux will put a dummy in but this is attempting to handle incorrect DTs. This means we have functional error handling in cases where there is something to worry about and simplifies the code using the regulator. Ok, you're saying the opposite of Rob. Should it be required or optional in the DT binding? I'm saying it should be required. The implementation accepts it as an extension (a recent extension at that). Ok. Dave M has already picked up all these patches so I'll send a patch to replace regulator_get_optional() with regulator_get() and fix up the error handling unless I hear otherwise. Yes, please. I'm much more worried about the abuse of regulator_get_optional() than the binding. signature.asc Description: Digital signature
[PATCH] net: ks8851: Don't use regulator_get_optional()
We shouldn't be using regulator_get_optional() here. These
regulators are always present as part of the physical design and
there isn't any way to use an internal regulator or change the
source of the reference voltage via software. Given that the only
users of this driver in the kernel are DT based, this change
should be transparent to them even if they don't specify any
supplies because the regulator framework will insert dummy
supplies as needed.
Cc: Nishanth Menon n...@ti.com
Cc: Mark Brown broo...@kernel.org
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
drivers/net/ethernet/micrel/ks8851.c | 50
1 file changed, 22 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ks8851.c
b/drivers/net/ethernet/micrel/ks8851.c
index e72918970a58..66d4ab703f45 100644
--- a/drivers/net/ethernet/micrel/ks8851.c
+++ b/drivers/net/ethernet/micrel/ks8851.c
@@ -1441,32 +1441,30 @@ static int ks8851_probe(struct spi_device *spi)
}
}
- ks-vdd_io = devm_regulator_get_optional(spi-dev, vdd-io);
+ ks-vdd_io = devm_regulator_get(spi-dev, vdd-io);
if (IS_ERR(ks-vdd_io)) {
ret = PTR_ERR(ks-vdd_io);
- if (ret == -EPROBE_DEFER)
- goto err_reg_io;
- } else {
- ret = regulator_enable(ks-vdd_io);
- if (ret) {
- dev_err(spi-dev, regulator vdd_io enable fail: %d\n,
- ret);
- goto err_reg_io;
- }
+ goto err_reg_io;
+ }
+
+ ret = regulator_enable(ks-vdd_io);
+ if (ret) {
+ dev_err(spi-dev, regulator vdd_io enable fail: %d\n,
+ ret);
+ goto err_reg_io;
}
- ks-vdd_reg = devm_regulator_get_optional(spi-dev, vdd);
+ ks-vdd_reg = devm_regulator_get(spi-dev, vdd);
if (IS_ERR(ks-vdd_reg)) {
ret = PTR_ERR(ks-vdd_reg);
- if (ret == -EPROBE_DEFER)
- goto err_reg;
- } else {
- ret = regulator_enable(ks-vdd_reg);
- if (ret) {
- dev_err(spi-dev, regulator vdd enable fail: %d\n,
- ret);
- goto err_reg;
- }
+ goto err_reg;
+ }
+
+ ret = regulator_enable(ks-vdd_reg);
+ if (ret) {
+ dev_err(spi-dev, regulator vdd enable fail: %d\n,
+ ret);
+ goto err_reg;
}
if (gpio_is_valid(gpio)) {
@@ -1572,11 +1570,9 @@ err_irq:
if (gpio_is_valid(gpio))
gpio_set_value(gpio, 0);
err_id:
- if (!IS_ERR(ks-vdd_reg))
- regulator_disable(ks-vdd_reg);
+ regulator_disable(ks-vdd_reg);
err_reg:
- if (!IS_ERR(ks-vdd_io))
- regulator_disable(ks-vdd_io);
+ regulator_disable(ks-vdd_io);
err_reg_io:
err_gpio:
free_netdev(ndev);
@@ -1594,10 +1590,8 @@ static int ks8851_remove(struct spi_device *spi)
free_irq(spi-irq, priv);
if (gpio_is_valid(priv-gpio))
gpio_set_value(priv-gpio, 0);
- if (!IS_ERR(priv-vdd_reg))
- regulator_disable(priv-vdd_reg);
- if (!IS_ERR(priv-vdd_io))
- regulator_disable(priv-vdd_io);
+ regulator_disable(priv-vdd_reg);
+ regulator_disable(priv-vdd_io);
free_netdev(priv-netdev);
return 0;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: qcom: Update msm8960 device trees
On Wed, May 28, 2014 at 01:27:23PM -0500, Kumar Gala wrote:
* Move SoC peripherals into an SoC container node
* Move serial enabling into board file (qcom-msm8960-cdp.dts)
* Cleanup cpu node to match binding spec, enable-method and compatible
should be per cpu, not part of the container
* Drop interrupts property from l2-cache node as its not part of the
binding spec
Signed-off-by: Kumar Gala ga...@codeaurora.org
---
arch/arm/boot/dts/qcom-msm8960-cdp.dts | 6 ++
arch/arm/boot/dts/qcom-msm8960.dtsi| 165
+
2 files changed, 93 insertions(+), 78 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8960-cdp.dts
b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
index a58fb88..8e77ed7 100644
--- a/arch/arm/boot/dts/qcom-msm8960-cdp.dts
+++ b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
@@ -3,4 +3,10 @@
/ {
model = Qualcomm MSM8960 CDP;
compatible = qcom,msm8960-cdp, qcom,msm8960;
+
+ soc {
+ serial@1644 {
+ status = ok;
+ };
+ };
};
Is now the time put these serial nodes under a GSBI parent node?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: qcom: Update msm8960 device trees
On May 28, 2014, at 3:09 PM, Josh Cartwright jo...@codeaurora.org wrote:
On Wed, May 28, 2014 at 01:27:23PM -0500, Kumar Gala wrote:
* Move SoC peripherals into an SoC container node
* Move serial enabling into board file (qcom-msm8960-cdp.dts)
* Cleanup cpu node to match binding spec, enable-method and compatible
should be per cpu, not part of the container
* Drop interrupts property from l2-cache node as its not part of the
binding spec
Signed-off-by: Kumar Gala ga...@codeaurora.org
---
arch/arm/boot/dts/qcom-msm8960-cdp.dts | 6 ++
arch/arm/boot/dts/qcom-msm8960.dtsi| 165
+
2 files changed, 93 insertions(+), 78 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8960-cdp.dts
b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
index a58fb88..8e77ed7 100644
--- a/arch/arm/boot/dts/qcom-msm8960-cdp.dts
+++ b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
@@ -3,4 +3,10 @@
/ {
model = Qualcomm MSM8960 CDP;
compatible = qcom,msm8960-cdp, qcom,msm8960;
+
+soc {
+serial@1644 {
+status = ok;
+};
+};
};
Is now the time put these serial nodes under a GSBI parent node?
Yeah, I’ll make the change to the 8960 8660 dts
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: ks8851: Don't use regulator_get_optional()
On Wed, May 28, 2014 at 01:11:12PM -0700, Stephen Boyd wrote: We shouldn't be using regulator_get_optional() here. These regulators are always present as part of the physical design and there isn't any way to use an internal regulator or change the source of the reference voltage via software. Given that the only users of this driver in the kernel are DT based, this change should be transparent to them even if they don't specify any supplies because the regulator framework will insert dummy supplies as needed. Reviewed-by: Mark Brown broo...@linaro.org signature.asc Description: Digital signature
