Re: [PATCH v2 4/4] ARM: debug: qcom: add UART addresses to Kconfig help
On Thu, 2014-05-29 at 17:26 +0200, Matthias Brugger wrote: IMHO the dependancy is that DEBUG_LL uses the uart device, and this is added when you add the dts. AFAIK there can arise problems with multi-platform kernels if the uart is not present. Once DEBUG_LL is enabled you don't have multi-platform kernel anymore, so this should not be an issue here. Regards, Ivan -- 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 30, 2014 at 3:30 AM, Stephen Boyd sb...@codeaurora.org wrote: Hm... that doesn't sound right. Please see this thread on lkml[1], and also this video from Ben H.[2] But Benji is talking about the *PCI BUS*, and this is raw register access. He just says that This is how a BE CPU is normally wired to a LE bus we have no idea whether that is actually the case on any existing system with this peripheral. Such things have to be tested. My understanding is that this is a fifo so I would think we want to use the ioread32_rep() function here (or other string io functionality). Otherwise we're going to byteswap the data that we're trying to interpret as a buffer and big endian CPUs won't work. You don't know that until you have tested on real BE ARM hardware with this PrimeCell. How do you know the SoC designers will have been smart enough to insert byte swap logic? You are right. readsl() or ioread32_rep() isn't used for this reason. We could always use a size of 1 right? What do you mean? Do you mean using: ioread32_rep(io, buf, 1)? Notice this is totally equivalent to readsl() in arm/include/asm/io.h: #define readsl(p,d,l) __raw_readsl(p,d,l) #define ioread32_rep(p,d,c) __raw_readsl(p,d,c) The semantic effect is switching from readl() - readsl() or conversely ioread32 - ioread32_rep() which will use __raw accessors in native endianness rather than LE access. Which is what you want if the bus will do byte swapping. Which we don't know if it does, because noone has such a system and can verify. If the native bus is not byte swapping this will just force you to use cpu_to_le32() on the result. That is not helpful at all. We need to experiment with real BE hardware with this PrimeCell to determine whether to do this, and until that is done just don't try to outsmart the hardware by thinking ahead and designing for the unknown, that will just fail. 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 v4 06/13] mmc: mmci: add ddrmode mask to variant data
On 28 May 2014 15:46, srinivas.kandaga...@linaro.org wrote:
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.
The above statement seems not correct. We don't have any issues
currently, right. :-)
Kind regards
Ulf Hansson
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
Re: [PATCH v4 03/13] mmc: mmci: Add Qualcomm Id to amba id table
On 28 May 2014 15:46, srinivas.kandaga...@linaro.org wrote:
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 },
};
Shouldn't this patch be moved to very end of this patchset?
If we would apply this patch on it's own - the Qcom variant wouldn't
work, right?
Kind regards
Ulf Hansson
--
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 v4 03/13] mmc: mmci: Add Qualcomm Id to amba id table
On 30/05/14 10:39, Ulf Hansson wrote:
On 28 May 2014 15:46, srinivas.kandaga...@linaro.org wrote:
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 },
};
Shouldn't this patch be moved to very end of this patchset?
If we would apply this patch on it's own - the Qcom variant wouldn't
work, right?
Yes, I would not work. I will move it to the end of the patchset.
Thanks,
srini
Kind regards
Ulf Hansson
--
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 v4 06/13] mmc: mmci: add ddrmode mask to variant data
On 30/05/14 10:35, Ulf Hansson wrote:
On 28 May 2014 15:46, srinivas.kandaga...@linaro.org wrote:
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.
The above statement seems not correct. We don't have any issues
currently, right. :-)
I should have said Qualcomm instead of generalizing it to non-ST SOCs.
Will fix this in next version.
Thanks,
srini
Kind regards
Ulf Hansson
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
Re: [PATCH v4 09/13] mmc: mmci: add Qcom specifics of clk and datactrl registers.
On 28 May 2014 15:47, srinivas.kandaga...@linaro.org wrote:
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,
This stuff should go in patch3.
.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)
+
Maybe you should have one patch in the beginning of the patchset, that
adds all the new QCOM bits in the header file? Instead of splitting
them up?
#define MMCIRESPCMD0x010
#define MMCIRESPONSE0 0x014
#define MMCIRESPONSE1 0x018
--
1.9.1
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 v4 09/13] mmc: mmci: add Qcom specifics of clk and datactrl registers.
On 30/05/14 10:55, Ulf Hansson wrote:
On 28 May 2014 15:47, srinivas.kandaga...@linaro.org wrote:
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,
This stuff should go in patch3.
Yes, I will merge patch3 and this change-set in next version.
.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)
+
Maybe you should have one patch in the beginning of the patchset, that
adds all the new QCOM bits in the header file? Instead of splitting
them up?
Ok, I will do that in next version.
Thanks,
srini
#define MMCIRESPCMD0x010
#define MMCIRESPONSE0 0x014
#define MMCIRESPONSE1 0x018
--
1.9.1
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 v4 12/13] mmc: mmci: add explicit clk control
On 28 May 2014 15:47, srinivas.kandaga...@linaro.org wrote:
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,
This should go in patch3 instead.
};
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);
- }
The above code is relevant for Qcom as well, I don't think you need
change/move it.
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);
I think you could simplify the change of fixing with f_min and f_max.
Start by, just add another statement here else if
(variant-explicit_mclk_control) and do the clk_round_rate()
- 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,
Re: [PATCH v4 11/13] mmc: mmci: add f_max to variant structure
On 28 May 2014 15:47, srinivas.kandaga...@linaro.org wrote:
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) {
You can use the local variant pointer directly, instead of host-variant.
+ 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
Looks good otherwise!
Kind regards
Ulf Hansson
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to
Re: [PATCH v4 11/13] mmc: mmci: add f_max to variant structure
Thanks Ulf,
On 30/05/14 11:28, Ulf Hansson wrote:
*/
- if (host-mclk 1) {
- ret = clk_set_rate(host-clk, 1);
+ if (host-mclk host-variant-f_max) {
You can use the local variant pointer directly, instead of host-variant.
yes, Will do that in next version.
Thanks,
srini
+ ret = clk_set_rate(host-clk, host-variant-f_max);
if (ret 0)
goto clk_disable;
host-mclk = clk_get_rate(host-clk);
--
--
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 v4 12/13] mmc: mmci: add explicit clk control
Thanks Ulf for reviewing.
On 30/05/14 11:25, Ulf Hansson wrote:
On 28 May 2014 15:47, srinivas.kandaga...@linaro.org wrote:
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,
This should go in patch3 instead.
yes.. will get this in to the patch3 too.
};
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);
- }
The above code is relevant for Qcom as well, I don't think you need
change/move it.
Yes, you are right. I will fix it in next version.
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);
I think you could simplify the change of fixing with f_min and f_max.
Start by, just add another statement here else if
(variant-explicit_mclk_control) and do the clk_round_rate()
- 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
Re: [PATCH v4 13/13] mmc: mmci: Add Qcom specific pio_read function.
On 28 May 2014 15:48, srinivas.kandaga...@linaro.org wrote:
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;
Instead of u32 ptr above, I suggest to use a char *ptr. You need it
anyway further down below where you move in step of bytes instead of
words.
+ 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) {
How about while (words (readl(host-base + MMCISTATUS) MCI_RXDATAAVLBL)
That would make it possible the remove the if, both above and below.
+ *ptr = readl(host-base + MMCIFIFO + (count % fsize));
This looks strange. :-) Depending on the count you will read an offset
into the FIFO? Seems like a very awkward implementation of a FIFO in
the HW. :-)
BTW, what does MCI_RXDATAAVLBL actually mean for the Qcom variant?
How much data could you expect in the FIFO when this status is
triggered?
Are there no option of reading a number of words, depending on what
type FIFO IRQ that was raised?
+ 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 =
Re: [PATCH v4 13/13] mmc: mmci: Add Qcom specific pio_read function.
Hi Ulf,
On 30/05/14 12:27, Ulf Hansson wrote:
On 28 May 2014 15:48, srinivas.kandaga...@linaro.org wrote:
...
.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;
Instead of u32 ptr above, I suggest to use a char *ptr. You need it
anyway further down below where you move in step of bytes instead of
words.
+ 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) {
How about while (words (readl(host-base + MMCISTATUS) MCI_RXDATAAVLBL)
That would make it possible the remove the if, both above and below.
That sounds sensible.. I will try it.
+ *ptr = readl(host-base + MMCIFIFO + (count % fsize));
This looks strange. :-) Depending on the count you will read an offset
into the FIFO? Seems like a very awkward implementation of a FIFO in
the HW. :-)
I got into weird issues when I tried using the mmci_pio_read, the fifo
implementation seems to be different. I dont have full details on the
fifo behaviour.
Most of this logic is inherited from 3.4 qcom andriod kernel.
BTW, what does MCI_RXDATAAVLBL actually mean for the Qcom variant?
It means, At least 1 word in the RX FIFO. SW can read 1 word only from
the FIFO.
How much data could you expect in the FIFO when this status is
triggered?
Are there no option of reading a number of words, depending on what
type FIFO IRQ that was raised?
There are RXFIFO_HALF_FULL and RXFIFO_FULL bits in status register, but
I never tried to use them. Might be worth a try before I send next
version patches.
I will give a try and keep you posted.
Thanks,
srini
+ 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;
+}
+
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 v4 13/13] mmc: mmci: Add Qcom specific pio_read function.
Hi Ulf,
Managed to reuse the existing mmci_pio_read function with some minor
modifications, Issue was with reading full fifo sizes which was creating
the issue.
On 30/05/14 12:44, Srinivas Kandagatla wrote:
That sounds sensible.. I will try it.
+ *ptr = readl(host-base + MMCIFIFO + (count %
fsize));
This looks strange. :-) Depending on the count you will read an offset
into the FIFO? Seems like a very awkward implementation of a FIFO in
the HW. :-)
I got into weird issues when I tried using the mmci_pio_read, the fifo
implementation seems to be different. I dont have full details on the
fifo behaviour.
Most of this logic is inherited from 3.4 qcom andriod kernel.
BTW, what does MCI_RXDATAAVLBL actually mean for the Qcom variant?
It means, At least 1 word in the RX FIFO. SW can read 1 word only from
the FIFO.
How much data could you expect in the FIFO when this status is
triggered?
Are there no option of reading a number of words, depending on what
type FIFO IRQ that was raised?
There are RXFIFO_HALF_FULL and RXFIFO_FULL bits in status register, but
I never tried to use them. Might be worth a try before I send next
version patches.
--- 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 logic.
*/
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 = {
@@ -990,15 +992,33 @@ mmci_cmd_irq(struct mmci_host *host, struct
mmc_command *cmd,
}
}
+static int mmci_get_rx_fifocnt(struct mmci_host *host, u32 status, int
remain)
+{
+ return remain - (readl(host-base + MMCIFIFOCNT) 2);
+}
+
+static int mmci_qcom_get_rx_fifocnt(struct mmci_host *host, u32 status,
int r)
+{
+ /*
+* on qcom SDCC4 only 8 words are used in each burst so only 8
addresses
+* from the fifo range should be used
+*/
+ if (status MCI_RXFIFOHALFFULL)
+ return host-variant-fifohalfsize;
+ else
+ return 4;
+}
+
static int mmci_pio_read(struct mmci_host *host, char *buffer,
unsigned int remain)
{
void __iomem *base = host-base;
char *ptr = buffer;
- u32 status;
+ int hf = host-variant-fifohalfsize;
int host_remain = host-size;
+ u32 status = readl(host-base + MMCISTATUS);
do {
- int count = host_remain - (readl(base + MMCIFIFOCNT) 2);
+ int count = host-get_rx_fifocnt(host, status, host_remain);
if (count remain)
count = remain;
@@ -1488,6 +1508,11 @@ static int mmci_probe(struct amba_device *dev,
if (ret)
goto host_free;
+ if (variant-qcom_fifo)
+ host-get_rx_fifocnt = mmci_qcom_get_rx_fifocnt;
+ else
+ host-get_rx_fifocnt = mmci_get_rx_fifocnt;
+
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 b5f0810..5f76670 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 (*get_rx_fifocnt)(struct mmci_host *h, u32 status, int remain);
#ifdef CONFIG_DMA_ENGINE
--
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
[GIT PULL] qcom DT changes for v3.16-2
The following changes since commit 08f9234ad6b0b8bc51046346eabf5b92e631e62a: soc: qcom: Add device tree binding for GSBI (2014-05-23 11:38:53 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-dt-for-3.16-2 for you to fetch changes up to f46d23f6f3676720de2a3f195413a5e69f202238: ARM: dts: qcom: Add APQ8084-MTP board support (2014-05-29 11:16:45 -0500) Qualcomm ARM Based Device Tree Updates for v3.16-2 * Updated MSM8660/MSM8960/MSM8974 dts for various updates or conformitity to binding specs * Added APQ8064 SoC and IFC6410 board device tree support * Added APQ8084 SoC and APQ8084-MTP board device tree support Georgi Djakov (2): ARM: dts: qcom: Add APQ8084 SoC support ARM: dts: qcom: Add APQ8084-MTP board support Kumar Gala (4): ARM: dts: qcom: Update msm8974/apq8074 device trees ARM: dts: qcom: Update msm8960 device trees ARM: dts: qcom: Update msm8660 device trees ARM: dts: qcom: Add initial APQ8064 SoC and IFC6410 board device trees arch/arm/boot/dts/Makefile | 9 +- 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/boot/dts/qcom-apq8074-dragonboard.dts | 28 +++- arch/arm/boot/dts/qcom-apq8084-mtp.dts | 6 + arch/arm/boot/dts/qcom-apq8084.dtsi| 179 + arch/arm/boot/dts/qcom-msm8660-surf.dts| 10 ++ arch/arm/boot/dts/qcom-msm8660.dtsi| 115 +--- arch/arm/boot/dts/qcom-msm8960-cdp.dts | 10 ++ arch/arm/boot/dts/qcom-msm8960.dtsi| 176 +--- arch/arm/boot/dts/qcom-msm8974.dtsi| 49 +++ arch/arm/mach-qcom/board.c | 4 +- 13 files changed, 612 insertions(+), 161 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 create mode 100644 arch/arm/boot/dts/qcom-apq8084-mtp.dts create mode 100644 arch/arm/boot/dts/qcom-apq8084.dtsi -- 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
[GIT PULL] qcom driver changes for v3.16-2
The following changes since commit 5d144e36b7c51612922fa05d37ff3a869261cc82: soc: qcom: Add GSBI driver (2014-05-23 11:38:04 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-drivers-for-3.16-2 for you to fetch changes up to 31964ffebbb958c6cf289c7c12edd7530d6221b9: tty: serial: msm: Remove direct access to GSBI (2014-05-29 11:06:20 -0500) Qualcomm ARM Based driver Updates for v3.16-2 * Updated MSM uart driver to not access GSBI control registers Andy Gross (1): tty: serial: msm: Remove direct access to GSBI drivers/tty/serial/msm_serial.c | 48 ++--- drivers/tty/serial/msm_serial.h | 5 - 2 files changed, 2 insertions(+), 51 deletions(-) -- 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
[GIT PULL] qcom defconfig changes for v3.16-2
The following changes since commit f604759ec025e21d0c29a6d0addd53bbc60eb12e: ARM: config: Update msm_defconfig (2014-05-22 11:18:56 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-defconfig-for-3.16-2 for you to fetch changes up to 15ce39ade232bdac9fb788c66da9bcc7eb1a46a9: ARM: qcom: Enable GSBI driver in defconfig (2014-05-29 11:27:03 -0500) Qualcomm ARM Based defconfig Updates for v3.16-2 * Enable qcom GSBI driver Kumar Gala (1): ARM: qcom: Enable GSBI driver in defconfig arch/arm/configs/qcom_defconfig | 1 + 1 file changed, 1 insertion(+) -- 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
[GIT PULL] qcom SoC changes for v3.16-2
The following changes since commit 87cfb00d666cca3abf36f755279cde1b27b9c377: ARM: qcom: Select PINCTRL by default for ARCH_QCOM (2014-05-22 11:50:42 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-soc-for-3.16-2 for you to fetch changes up to 2f528dd3b30c4351c0ece73b8bdc39753c02003b: ARM: debug: qcom: add UART addresses to Kconfig help for APQ8084 (2014-05-29 11:14:28 -0500) Qualcomm ARM Based SoC Updates for v3.16-2 * Updated Kconfig DEBUG_QCOM_UARTDM help to include APQ8084 info Georgi Djakov (1): ARM: debug: qcom: add UART addresses to Kconfig help for APQ8084 arch/arm/Kconfig.debug | 1 + 1 file changed, 1 insertion(+) -- 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
[PATCH v5 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 v4 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 specific register defines. 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 change was to add qcom specfic fifocnt logic, 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 rx_fifocnt logic. 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. Changes from v4: - moved the amba id table addition to the end of the patchset as suggested by Ulf. - reused the mmci_pio_read function after experimenting with the fifo behaviour. - simplify f_max/f_min calculation logic as suggested by Ulf. - created a new patch for the register defination as suggested by Ulf. 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. 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 specific register defines. 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 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 rx_fifocnt logic. mmc: mmci: Add Qualcomm Id to amba id table drivers/mmc/host/mmci.c | 129 --- drivers/mmc/host/mmci.h | 228 ++-- 2 files changed, 241 insertions(+), 116 deletions(-) -- 1.9.1 -- To unsubscribe from this list:
[PATCH v5 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 v5 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 a38e714..ed20bf5 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -810,7 +810,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 v5 10/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 | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 8534c29..55d39d2 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,
@@ -1471,8 +1480,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 variant-f_max) {
+ ret = clk_set_rate(host-clk, 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 v5 12/13] mmc: mmci: Add Qcom specific rx_fifocnt logic.
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 a qcom specific get_rx_fifocnt function which is
implemented based on status register flags. Based on qcom_fifo flag in
variant data structure, the corresponding get_rx_fifocnt function is selected.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
drivers/mmc/host/mmci.c | 30 --
drivers/mmc/host/mmci.h | 1 +
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 8b23368..7a11522 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 logic.
*/
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 = {
@@ -990,15 +992,34 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command
*cmd,
}
}
+static int mmci_get_rx_fifocnt(struct mmci_host *host, u32 status, int remain)
+{
+ return remain - (readl(host-base + MMCIFIFOCNT) 2);
+}
+
+static int mmci_qcom_get_rx_fifocnt(struct mmci_host *host, u32 status, int r)
+{
+ /*
+* on qcom SDCC4 only 8 words are used in each burst so only 8 addresses
+* from the fifo range should be used
+*/
+ if (status MCI_RXFIFOHALFFULL)
+ return host-variant-fifohalfsize;
+ else if (status MCI_RXDATAAVLBL)
+ return 4;
+
+ return 0;
+}
+
static int mmci_pio_read(struct mmci_host *host, char *buffer, unsigned int
remain)
{
void __iomem *base = host-base;
char *ptr = buffer;
- u32 status;
+ u32 status = readl(host-base + MMCISTATUS);
int host_remain = host-size;
do {
- int count = host_remain - (readl(base + MMCIFIFOCNT) 2);
+ int count = host-get_rx_fifocnt(host, status, host_remain);
if (count remain)
count = remain;
@@ -1488,6 +1509,11 @@ static int mmci_probe(struct amba_device *dev,
if (ret)
goto host_free;
+ if (variant-qcom_fifo)
+ host-get_rx_fifocnt = mmci_qcom_get_rx_fifocnt;
+ else
+ host-get_rx_fifocnt = mmci_get_rx_fifocnt;
+
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 b5f0810..5f76670 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 (*get_rx_fifocnt)(struct mmci_host *h, u32 status, 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
[PATCH v5 11/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 | 31 ---
drivers/mmc/host/mmci.h | 2 ++
2 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 55d39d2..8b23368 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 = {
@@ -286,7 +288,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;
@@ -1325,6 +1329,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-clock_cache)) {
+ 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-clock_cache = ios-clock;
+ }
+ }
+
spin_lock_irqsave(host-lock, flags);
mmci_set_clkreg(host, ios-clock);
@@ -1500,9 +1516,12 @@ static int mmci_probe(struct amba_device *dev,
* The ARM and ST versions of the block have slightly different
* clock divider equations which means that the minimum divider
* differs too.
+* on Qualcomm like controllers get the nearest minimum clock to 100Khz
*/
if (variant-st_clkdiv)
mmc-f_min = DIV_ROUND_UP(host-mclk, 257);
+ else if (variant-explicit_mclk_control)
+ mmc-f_min = clk_round_rate(host-clk, 10);
else
mmc-f_min = DIV_ROUND_UP(host-mclk, 512);
/*
@@ -1512,9 +1531,15 @@ static int mmci_probe(struct amba_device *dev,
* the block, of course.
*/
if (mmc-f_max)
- mmc-f_max = min(host-mclk, mmc-f_max);
+ mmc-f_max = variant-explicit_mclk_control ?
+ min(variant-f_max, mmc-f_max) :
+ min(host-mclk, mmc-f_max);
else
- mmc-f_max = min(host-mclk, fmax);
+ mmc-f_max = variant-explicit_mclk_control ?
+ min(variant-f_max, fmax) :
+ min(host-mclk, fmax);
+
+
dev_dbg(mmc_dev(mmc), clocking block at %u Hz\n, mmc-f_max);
/* Get regulators and the supported OCR mask */
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 706eb513..b5f0810 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -208,6 +208,8 @@ struct mmci_host {
spinlock_t lock;
unsigned intmclk;
+ /* cached value of requested clk in set_ios */
+ unsigned intclock_cache;
unsigned intcclk;
u32 pwr_reg;
u32 pwr_reg_add;
--
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 v5 13/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
---
drivers/mmc/host/mmci.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 7a11522..b07c3c3 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -190,6 +190,23 @@ 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,
+ .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,
+ .data_cmd_enable= MCI_QCOM_CSPM_DATCMD,
+ .blksz_datactrl4= true,
+ .datalength_bits= 24,
+ .pwrreg_powerup = MCI_PWR_UP,
+ .f_max = 20800,
+ .explicit_mclk_control = true,
+ .qcom_fifo = true,
+};
+
static int mmci_card_busy(struct mmc_host *mmc)
{
struct mmci_host *host = mmc_priv(mmc);
@@ -1832,6 +1849,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 v5 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 ad7e538..fa3ad83 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,
@@ -305,7 +310,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 v5 09/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 | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 4c95a9b..8534c29 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;
@@ -839,6 +841,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 v5 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 fa3ad83..4c95a9b 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,
@@ -313,7 +317,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 v5 03/13] mmc: mmci: Add Qualcomm specific register defines.
From: Srinivas Kandagatla srinivas.kandaga...@linaro.org This patch adds a Qualcomm SD Card controller specific register variations to header file. Qualcomm SDCC controller is pl180, with slight changes in the register layout from standard pl180 register set. Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org --- drivers/mmc/host/mmci.h | 17 + 1 file changed, 17 insertions(+) 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 v5 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 v5 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 incorrect ddrmode mask,
resulting in failures on 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 | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 72981f6..ad7e538 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,
@@ -770,7 +773,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 v5 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 | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index ed20bf5..72981f6 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;
@@ -731,6 +734,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
Re: [PATCH] ARM: qcom: Enable GSBI driver in defconfig
On 05/29/14 09:26, Kumar Gala wrote: Signed-off-by: Kumar Gala ga...@codeaurora.org --- arch/arm/configs/qcom_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig index bfed753..42ebd72 100644 --- a/arch/arm/configs/qcom_defconfig +++ b/arch/arm/configs/qcom_defconfig @@ -131,6 +131,7 @@ CONFIG_RTC_CLASS=y CONFIG_DMADEVICES=y CONFIG_QCOM_BAM_DMA=y CONFIG_STAGING=y +CONFIG_QCOM_GSBI=y CONFIG_COMMON_CLK_QCOM=y CONFIG_MSM_GCC_8660=y CONFIG_MSM_MMCC_8960=y It would be good to do this in the multi-platform defconfig as well. Otherwise users of that defconfig (i.e. khilman's boot tester) will start failing to boot once the DT changes land. -- 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: qcom: Enable GSBI driver in defconfig
On May 30, 2014, at 12:28 PM, Stephen Boyd sb...@codeaurora.org wrote: On 05/29/14 09:26, Kumar Gala wrote: Signed-off-by: Kumar Gala ga...@codeaurora.org --- arch/arm/configs/qcom_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig index bfed753..42ebd72 100644 --- a/arch/arm/configs/qcom_defconfig +++ b/arch/arm/configs/qcom_defconfig @@ -131,6 +131,7 @@ CONFIG_RTC_CLASS=y CONFIG_DMADEVICES=y CONFIG_QCOM_BAM_DMA=y CONFIG_STAGING=y +CONFIG_QCOM_GSBI=y CONFIG_COMMON_CLK_QCOM=y CONFIG_MSM_GCC_8660=y CONFIG_MSM_MMCC_8960=y It would be good to do this in the multi-platform defconfig as well. Otherwise users of that defconfig (i.e. khilman's boot tester) will start failing to boot once the DT changes land. — Will do after 3.16-rc1, as nothing Kevin is booting uses the GSBI. Trying to decide if we should have some Kconfig dependency here. - 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] of: treat PCI config space as IORESOURCE_MEM type
On Fri, May 30, 2014 at 02:41:17AM +0100, Liviu Dudau wrote: Agree, I'm only concerned that if this ECAM config space gets added to the list of pci_host_bridge windows it will be indistinguishable from IORESOURCE_MEM resources and pci_create_root_bus() will add it to the bus and allow devices present on that bus to be assigned addresses from that range. Which might not be what one wants for certain BARs. I wouldn't worry about supporting config in ranges. ECAM is the logical use for config ranges, but it isn't specified and probably will never be. Will's driver the is the only driver I've seen to support ECAM and it didn't use ranges. Jason -- 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] of: treat PCI config space as IORESOURCE_MEM type
On May 30, 2014, at 3:37 PM, Jason Gunthorpe jguntho...@obsidianresearch.com wrote: On Fri, May 30, 2014 at 02:41:17AM +0100, Liviu Dudau wrote: Agree, I'm only concerned that if this ECAM config space gets added to the list of pci_host_bridge windows it will be indistinguishable from IORESOURCE_MEM resources and pci_create_root_bus() will add it to the bus and allow devices present on that bus to be assigned addresses from that range. Which might not be what one wants for certain BARs. I wouldn't worry about supporting config in ranges. ECAM is the logical use for config ranges, but it isn't specified and probably will never be. Will's driver the is the only driver I've seen to support ECAM and it didn't use ranges. I expect with 64-bit parts we will see more use of ECAM, I think the reason its not used much is because of the address space it chews up, but that becomes less of an issue with LPAE or 64-bit parts with larger physical address spaces. - 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] of: treat PCI config space as IORESOURCE_MEM type
On May 29, 2014, at 8:41 PM, Liviu Dudau li...@dudau.co.uk wrote:
On Thu, May 29, 2014 at 07:29:31PM -0600, Bjorn Helgaas wrote:
On Thu, May 29, 2014 at 6:56 PM, Liviu Dudau li...@dudau.co.uk wrote:
On Thu, May 29, 2014 at 03:51:28PM -0500, Kumar Gala wrote:
On May 29, 2014, at 3:44 PM, Rob Herring robherri...@gmail.com wrote:
On Thu, May 29, 2014 at 11:03 AM, Kumar Gala ga...@codeaurora.org wrote:
If we have a PCI config space specified in something like a ranges
property we should treat it as memory type resource.
Config space should not be in ranges[1]. We have some cases that are,
but we don't want new ones.
For the cases we have I agree, however an ECAM based cfg seems completely
legit.
Signed-off-by: Kumar Gala ga...@codeaurora.org
---
drivers/of/address.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index cb4242a..4e7ee59 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -122,6 +122,9 @@ static unsigned int of_bus_pci_get_flags(const
__be32 *addr)
u32 w = be32_to_cpup(addr);
switch((w 24) 0x03) {
+ case 0x00: /* cfg space */
+ flags |= IORESOURCE_MEM;
+ break;
How would you then distinguish actual memory ranges?
One assumes you are still looking at pci_space as part of of_pci_range
That doesn't happen when you start scanning the bus. The existing code will
use the IORESOURCE_MEM for allocating memory space for devices, which is
not what you want. Did you test your patch on any PCI system? I'm pretty
sure that with my patch series that tries to make a generic framework for
host controllers this will fail.
We really need a IORESOURCE_CFG flag for this space.
Maybe, but I'm not convinced yet. The existing IORESOURCE_TYPE_BITS
types are for things that are mutually exclusive address spaces. I
think this discussion is about ECAM, where the CPU side is definitely
in the same address space (IORESOURCE_MEM) as RAM, APICs, host bridge
apertures, device MMIO, etc. The ECAM area must appear in the
iomem_resource tree so we avoid it when allocating other areas.
Agree, I'm only concerned that if this ECAM config space gets added to
the list of pci_host_bridge windows it will be indistinguishable from
IORESOURCE_MEM resources and pci_create_root_bus() will add it to the
bus and allow devices present on that bus to be assigned addresses from
that range. Which might not be what one wants for certain BARs.
I've had an aborted attempt to parse ECAM ranges in one version of my
series (granted, I was trying to hack the IORESOURCE_TYPE_BITS as well)
and things got horribly wrong quickly. I could give this patch a go with
my series tomorrow when I'm in the office and report back.
We need to fix the parsing code to be smarter about this case.
- 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
[PATCH] dmaengine: qcom_bam_dma: Add descriptor flags
This patch adds support for end of transaction (EOT) and notify when done (NWD)
hardware descriptor flags.
The EOT flag requests that the peripheral assert an end of transaction interrupt
when that descriptor is complete. It also results in special signaling protocol
that is used between the attached peripheral and the core using the DMA
controller. Clients will specify DMA_PREP_INTERRUPT to enable this flag.
The NWD flag requests that the peripheral wait until the data has been fully
processed by the peripheral before moving on to the next descriptor. Clients
will specify DMA_PREP_FENCE to enable this flag.
Signed-off-by: Andy Gross agr...@codeaurora.org
---
drivers/dma/qcom_bam_dma.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
index e01c2d106..4635224 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom_bam_dma.c
@@ -61,12 +61,17 @@ struct bam_desc_hw {
#define DESC_FLAG_INT BIT(15)
#define DESC_FLAG_EOT BIT(14)
#define DESC_FLAG_EOB BIT(13)
+#define DESC_FLAG_NWD BIT(12)
struct bam_async_desc {
struct virt_dma_desc vd;
u32 num_desc;
u32 xfer_len;
+
+ /* transaction flags, EOT|EOB|NWD */
+ u16 flags;
+
struct bam_desc_hw *curr_desc;
enum dma_transfer_direction dir;
@@ -490,6 +495,14 @@ static struct dma_async_tx_descriptor
*bam_prep_slave_sg(struct dma_chan *chan,
if (!async_desc)
goto err_out;
+ if (flags DMA_PREP_FENCE)
+ async_desc-flags |= DESC_FLAG_NWD;
+
+ if (flags DMA_PREP_INTERRUPT)
+ async_desc-flags |= DESC_FLAG_EOT;
+ else
+ async_desc-flags |= DESC_FLAG_INT;
+
async_desc-num_desc = num_alloc;
async_desc-curr_desc = async_desc-desc;
async_desc-dir = direction;
@@ -795,8 +808,11 @@ static void bam_start_dma(struct bam_chan *bchan)
else
async_desc-xfer_len = async_desc-num_desc;
- /* set INT on last descriptor */
- desc[async_desc-xfer_len - 1].flags |= DESC_FLAG_INT;
+ /* set any special flags on the last descriptor */
+ if (async_desc-num_desc == async_desc-xfer_len)
+ desc[async_desc-xfer_len - 1].flags = async_desc-flags;
+ else
+ desc[async_desc-xfer_len - 1].flags |= DESC_FLAG_INT;
if (bchan-tail + async_desc-xfer_len MAX_DESCRIPTORS) {
u32 partial = MAX_DESCRIPTORS - bchan-tail;
--
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] of: treat PCI config space as IORESOURCE_MEM type
On Fri, May 30, 2014 at 03:45:05PM -0500, Kumar Gala wrote:
On May 29, 2014, at 8:41 PM, Liviu Dudau li...@dudau.co.uk wrote:
On Thu, May 29, 2014 at 07:29:31PM -0600, Bjorn Helgaas wrote:
On Thu, May 29, 2014 at 6:56 PM, Liviu Dudau li...@dudau.co.uk wrote:
On Thu, May 29, 2014 at 03:51:28PM -0500, Kumar Gala wrote:
On May 29, 2014, at 3:44 PM, Rob Herring robherri...@gmail.com wrote:
On Thu, May 29, 2014 at 11:03 AM, Kumar Gala ga...@codeaurora.org
wrote:
If we have a PCI config space specified in something like a ranges
property we should treat it as memory type resource.
Config space should not be in ranges[1]. We have some cases that are,
but we don't want new ones.
For the cases we have I agree, however an ECAM based cfg seems
completely legit.
Signed-off-by: Kumar Gala ga...@codeaurora.org
---
drivers/of/address.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index cb4242a..4e7ee59 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -122,6 +122,9 @@ static unsigned int of_bus_pci_get_flags(const
__be32 *addr)
u32 w = be32_to_cpup(addr);
switch((w 24) 0x03) {
+ case 0x00: /* cfg space */
+ flags |= IORESOURCE_MEM;
+ break;
How would you then distinguish actual memory ranges?
One assumes you are still looking at pci_space as part of of_pci_range
That doesn't happen when you start scanning the bus. The existing code
will
use the IORESOURCE_MEM for allocating memory space for devices, which is
not what you want. Did you test your patch on any PCI system? I'm pretty
sure that with my patch series that tries to make a generic framework for
host controllers this will fail.
We really need a IORESOURCE_CFG flag for this space.
Maybe, but I'm not convinced yet. The existing IORESOURCE_TYPE_BITS
types are for things that are mutually exclusive address spaces. I
think this discussion is about ECAM, where the CPU side is definitely
in the same address space (IORESOURCE_MEM) as RAM, APICs, host bridge
apertures, device MMIO, etc. The ECAM area must appear in the
iomem_resource tree so we avoid it when allocating other areas.
Agree, I'm only concerned that if this ECAM config space gets added to
the list of pci_host_bridge windows it will be indistinguishable from
IORESOURCE_MEM resources and pci_create_root_bus() will add it to the
bus and allow devices present on that bus to be assigned addresses from
that range. Which might not be what one wants for certain BARs.
I've had an aborted attempt to parse ECAM ranges in one version of my
series (granted, I was trying to hack the IORESOURCE_TYPE_BITS as well)
and things got horribly wrong quickly. I could give this patch a go with
my series tomorrow when I'm in the office and report back.
We need to fix the parsing code to be smarter about this case.
Wow, what a sweeping statement! Did you not understand that the issue is not
the parsing code but the way the rest of the core code uses an IORESOURCE_MEM
once you have parsed it into a resource structure and added it to the list
of pci_host_bridge_windows?
Best regards,
Liviu
- 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-pci in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
---
.oooO
( )
\ ( Oooo.
\_) ( )
) /
(_/
One small step
for me ...
--
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] of: treat PCI config space as IORESOURCE_MEM type
On Fri, May 30, 2014 at 5:11 PM, Liviu Dudau li...@dudau.co.uk wrote:
On Fri, May 30, 2014 at 03:45:05PM -0500, Kumar Gala wrote:
On May 29, 2014, at 8:41 PM, Liviu Dudau li...@dudau.co.uk wrote:
On Thu, May 29, 2014 at 07:29:31PM -0600, Bjorn Helgaas wrote:
On Thu, May 29, 2014 at 6:56 PM, Liviu Dudau li...@dudau.co.uk wrote:
On Thu, May 29, 2014 at 03:51:28PM -0500, Kumar Gala wrote:
On May 29, 2014, at 3:44 PM, Rob Herring robherri...@gmail.com wrote:
On Thu, May 29, 2014 at 11:03 AM, Kumar Gala ga...@codeaurora.org
wrote:
If we have a PCI config space specified in something like a ranges
property we should treat it as memory type resource.
Config space should not be in ranges[1]. We have some cases that are,
but we don't want new ones.
For the cases we have I agree, however an ECAM based cfg seems
completely legit.
Signed-off-by: Kumar Gala ga...@codeaurora.org
---
drivers/of/address.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index cb4242a..4e7ee59 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -122,6 +122,9 @@ static unsigned int of_bus_pci_get_flags(const
__be32 *addr)
u32 w = be32_to_cpup(addr);
switch((w 24) 0x03) {
+ case 0x00: /* cfg space */
+ flags |= IORESOURCE_MEM;
+ break;
How would you then distinguish actual memory ranges?
One assumes you are still looking at pci_space as part of of_pci_range
That doesn't happen when you start scanning the bus. The existing code
will
use the IORESOURCE_MEM for allocating memory space for devices, which is
not what you want. Did you test your patch on any PCI system? I'm pretty
sure that with my patch series that tries to make a generic framework for
host controllers this will fail.
We really need a IORESOURCE_CFG flag for this space.
Maybe, but I'm not convinced yet. The existing IORESOURCE_TYPE_BITS
types are for things that are mutually exclusive address spaces. I
think this discussion is about ECAM, where the CPU side is definitely
in the same address space (IORESOURCE_MEM) as RAM, APICs, host bridge
apertures, device MMIO, etc. The ECAM area must appear in the
iomem_resource tree so we avoid it when allocating other areas.
Agree, I'm only concerned that if this ECAM config space gets added to
the list of pci_host_bridge windows it will be indistinguishable from
IORESOURCE_MEM resources and pci_create_root_bus() will add it to the
bus and allow devices present on that bus to be assigned addresses from
that range. Which might not be what one wants for certain BARs.
I've had an aborted attempt to parse ECAM ranges in one version of my
series (granted, I was trying to hack the IORESOURCE_TYPE_BITS as well)
and things got horribly wrong quickly. I could give this patch a go with
my series tomorrow when I'm in the office and report back.
We need to fix the parsing code to be smarter about this case.
Wow, what a sweeping statement! Did you not understand that the issue is not
the parsing code but the way the rest of the core code uses an IORESOURCE_MEM
once you have parsed it into a resource structure and added it to the list
of pci_host_bridge_windows?
Why do you want to add the ECAM area to the list of host bridge
windows? My intent was that the windows tell the core what resources
are available for devices behind the bridge.
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] of: treat PCI config space as IORESOURCE_MEM type
On Fri, May 30, 2014 at 05:16:52PM -0600, Bjorn Helgaas wrote:
On Fri, May 30, 2014 at 5:11 PM, Liviu Dudau li...@dudau.co.uk wrote:
On Fri, May 30, 2014 at 03:45:05PM -0500, Kumar Gala wrote:
On May 29, 2014, at 8:41 PM, Liviu Dudau li...@dudau.co.uk wrote:
On Thu, May 29, 2014 at 07:29:31PM -0600, Bjorn Helgaas wrote:
On Thu, May 29, 2014 at 6:56 PM, Liviu Dudau li...@dudau.co.uk wrote:
On Thu, May 29, 2014 at 03:51:28PM -0500, Kumar Gala wrote:
On May 29, 2014, at 3:44 PM, Rob Herring robherri...@gmail.com
wrote:
On Thu, May 29, 2014 at 11:03 AM, Kumar Gala ga...@codeaurora.org
wrote:
If we have a PCI config space specified in something like a ranges
property we should treat it as memory type resource.
Config space should not be in ranges[1]. We have some cases that are,
but we don't want new ones.
For the cases we have I agree, however an ECAM based cfg seems
completely legit.
Signed-off-by: Kumar Gala ga...@codeaurora.org
---
drivers/of/address.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index cb4242a..4e7ee59 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -122,6 +122,9 @@ static unsigned int of_bus_pci_get_flags(const
__be32 *addr)
u32 w = be32_to_cpup(addr);
switch((w 24) 0x03) {
+ case 0x00: /* cfg space */
+ flags |= IORESOURCE_MEM;
+ break;
How would you then distinguish actual memory ranges?
One assumes you are still looking at pci_space as part of of_pci_range
That doesn't happen when you start scanning the bus. The existing code
will
use the IORESOURCE_MEM for allocating memory space for devices, which
is
not what you want. Did you test your patch on any PCI system? I'm
pretty
sure that with my patch series that tries to make a generic framework
for
host controllers this will fail.
We really need a IORESOURCE_CFG flag for this space.
Maybe, but I'm not convinced yet. The existing IORESOURCE_TYPE_BITS
types are for things that are mutually exclusive address spaces. I
think this discussion is about ECAM, where the CPU side is definitely
in the same address space (IORESOURCE_MEM) as RAM, APICs, host bridge
apertures, device MMIO, etc. The ECAM area must appear in the
iomem_resource tree so we avoid it when allocating other areas.
Agree, I'm only concerned that if this ECAM config space gets added to
the list of pci_host_bridge windows it will be indistinguishable from
IORESOURCE_MEM resources and pci_create_root_bus() will add it to the
bus and allow devices present on that bus to be assigned addresses from
that range. Which might not be what one wants for certain BARs.
I've had an aborted attempt to parse ECAM ranges in one version of my
series (granted, I was trying to hack the IORESOURCE_TYPE_BITS as well)
and things got horribly wrong quickly. I could give this patch a go with
my series tomorrow when I'm in the office and report back.
We need to fix the parsing code to be smarter about this case.
Wow, what a sweeping statement! Did you not understand that the issue is not
the parsing code but the way the rest of the core code uses an
IORESOURCE_MEM
once you have parsed it into a resource structure and added it to the list
of pci_host_bridge_windows?
Why do you want to add the ECAM area to the list of host bridge
windows? My intent was that the windows tell the core what resources
are available for devices behind the bridge.
I don't *want*, it is just that with my series that enhances Andrew's
parses of the ranges they all come together as host bridge windows. And it is
quite natural to put them all together when creating the root bus as the
space needs to be added to the iomem_resource tree anyway and that will happen
without special casing.
But maybe I'm wrong with that idea. What I know for sure is that wherever you
are going to pass the ECAM range converted to an IORESOURCE_MEM, the existing
code will not be able to distinguish it from a normal IORESOURCE_MEM and it
will treat it as a non-prefetcheable memory area. Is that how we want to treat
the ECFG space or do we want to special case it?
Best regards,
Liviu
Bjorn
--
To unsubscribe from this list: send the line unsubscribe linux-pci in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
---
.oooO
( )
\ ( Oooo.
\_) ( )
) /
(_/
One small step
for me ...
--
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 2/2] of: treat PCI config space as IORESOURCE_MEM type with special flags.
If we have a PCI config space specified in something like a ranges
property we should treat it as memory type resource. Use the
IORESOURCE_ECFG bit to distinguish the config space from standard
IORESOURCE_MEM resources.
Signed-off-by: Kumar Gama ga...@codeaurora.org
[Updated commit log and added IORESOURCE_ECFG bit]
Signed-off-by: Liviu Dudau liviu.du...@arm.com
---
drivers/of/address.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 2fcfbae..877e9e5 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -123,6 +123,9 @@ static unsigned int of_bus_pci_get_flags(const __be32 *addr)
u32 w = be32_to_cpup(addr);
switch((w 24) 0x03) {
+ case 0x00: /* cfg space */
+ flags |= IORESOURCE_MEM | IORESOURCE_PCI_ECFG;
+ break;
case 0x01:
flags |= IORESOURCE_IO;
break;
--
1.9.2
--
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 1/2] pci: Add IORESOURCE_BIT entry for PCIe ECAM resources.
We would like to be able to describe PCIe ECAM resources as
IORESOURCE_MEM blocks while distinguish them from standard
memory resources. Add an IORESOURCE_BIT entry for this case.
Signed-off-by: Liviu Dudau liviu.du...@arm.com
---
include/linux/ioport.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 5e3a906..9672533 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -103,6 +103,7 @@ struct resource {
/* PCI control bits. Shares IORESOURCE_BITS with above PCI ROM. */
#define IORESOURCE_PCI_FIXED (14) /* Do not move resource */
+#define IORESOURCE_PCI_ECFG(15) /* ECAM config resource */
/* helpers to define resources */
--
1.9.2
--
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] of: treat PCI config space as IORESOURCE_MEM type
On Sat, May 31, 2014 at 12:30:34AM +0100, Liviu Dudau wrote:
On Fri, May 30, 2014 at 05:16:52PM -0600, Bjorn Helgaas wrote:
On Fri, May 30, 2014 at 5:11 PM, Liviu Dudau li...@dudau.co.uk wrote:
On Fri, May 30, 2014 at 03:45:05PM -0500, Kumar Gala wrote:
On May 29, 2014, at 8:41 PM, Liviu Dudau li...@dudau.co.uk wrote:
On Thu, May 29, 2014 at 07:29:31PM -0600, Bjorn Helgaas wrote:
On Thu, May 29, 2014 at 6:56 PM, Liviu Dudau li...@dudau.co.uk
wrote:
On Thu, May 29, 2014 at 03:51:28PM -0500, Kumar Gala wrote:
On May 29, 2014, at 3:44 PM, Rob Herring robherri...@gmail.com
wrote:
On Thu, May 29, 2014 at 11:03 AM, Kumar Gala
ga...@codeaurora.org wrote:
If we have a PCI config space specified in something like a ranges
property we should treat it as memory type resource.
Config space should not be in ranges[1]. We have some cases that
are,
but we don't want new ones.
For the cases we have I agree, however an ECAM based cfg seems
completely legit.
Signed-off-by: Kumar Gala ga...@codeaurora.org
---
drivers/of/address.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index cb4242a..4e7ee59 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -122,6 +122,9 @@ static unsigned int
of_bus_pci_get_flags(const __be32 *addr)
u32 w = be32_to_cpup(addr);
switch((w 24) 0x03) {
+ case 0x00: /* cfg space */
+ flags |= IORESOURCE_MEM;
+ break;
How would you then distinguish actual memory ranges?
One assumes you are still looking at pci_space as part of
of_pci_range
That doesn't happen when you start scanning the bus. The existing
code will
use the IORESOURCE_MEM for allocating memory space for devices,
which is
not what you want. Did you test your patch on any PCI system? I'm
pretty
sure that with my patch series that tries to make a generic
framework for
host controllers this will fail.
We really need a IORESOURCE_CFG flag for this space.
Maybe, but I'm not convinced yet. The existing IORESOURCE_TYPE_BITS
types are for things that are mutually exclusive address spaces. I
think this discussion is about ECAM, where the CPU side is definitely
in the same address space (IORESOURCE_MEM) as RAM, APICs, host bridge
apertures, device MMIO, etc. The ECAM area must appear in the
iomem_resource tree so we avoid it when allocating other areas.
Agree, I'm only concerned that if this ECAM config space gets added to
the list of pci_host_bridge windows it will be indistinguishable from
IORESOURCE_MEM resources and pci_create_root_bus() will add it to the
bus and allow devices present on that bus to be assigned addresses from
that range. Which might not be what one wants for certain BARs.
I've had an aborted attempt to parse ECAM ranges in one version of my
series (granted, I was trying to hack the IORESOURCE_TYPE_BITS as well)
and things got horribly wrong quickly. I could give this patch a go
with
my series tomorrow when I'm in the office and report back.
We need to fix the parsing code to be smarter about this case.
Wow, what a sweeping statement! Did you not understand that the issue is
not
the parsing code but the way the rest of the core code uses an
IORESOURCE_MEM
once you have parsed it into a resource structure and added it to the list
of pci_host_bridge_windows?
Why do you want to add the ECAM area to the list of host bridge
windows? My intent was that the windows tell the core what resources
are available for devices behind the bridge.
I don't *want*, it is just that with my series that enhances Andrew's
parses of the ranges they all come together as host bridge windows. And it is
quite natural to put them all together when creating the root bus as the
space needs to be added to the iomem_resource tree anyway and that will happen
without special casing.
But maybe I'm wrong with that idea. What I know for sure is that wherever you
are going to pass the ECAM range converted to an IORESOURCE_MEM, the existing
code will not be able to distinguish it from a normal IORESOURCE_MEM and it
will treat it as a non-prefetcheable memory area. Is that how we want to treat
the ECFG space or do we want to special case it?
OK, how about these patches? They should allow one to be able to distinguish
between standard IORESOURCE_MEM and ECFG one.
Best regards,
Liviu
--
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: [GIT PULL] qcom driver changes for v3.16-2
On Fri, May 30, 2014 at 11:41:01AM -0500, Kumar Gala wrote: The following changes since commit 5d144e36b7c51612922fa05d37ff3a869261cc82: soc: qcom: Add GSBI driver (2014-05-23 11:38:04 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-drivers-for-3.16-2 for you to fetch changes up to 31964ffebbb958c6cf289c7c12edd7530d6221b9: tty: serial: msm: Remove direct access to GSBI (2014-05-29 11:06:20 -0500) Qualcomm ARM Based driver Updates for v3.16-2 * Updated MSM uart driver to not access GSBI control registers Andy Gross (1): tty: serial: msm: Remove direct access to GSBI drivers/tty/serial/msm_serial.c | 48 ++--- drivers/tty/serial/msm_serial.h | 5 - 2 files changed, 2 insertions(+), 51 deletions(-) Do you want me to take these in the tty tree? Or are they going to go through the arm tree(s) for other reasons (dependancies)? thanks, greg k-h -- 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: [GIT PULL] qcom driver changes for v3.16-2
On Fri, May 30, 2014 at 4:57 PM, Greg KH gre...@linuxfoundation.org wrote: On Fri, May 30, 2014 at 11:41:01AM -0500, Kumar Gala wrote: The following changes since commit 5d144e36b7c51612922fa05d37ff3a869261cc82: soc: qcom: Add GSBI driver (2014-05-23 11:38:04 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-drivers-for-3.16-2 for you to fetch changes up to 31964ffebbb958c6cf289c7c12edd7530d6221b9: tty: serial: msm: Remove direct access to GSBI (2014-05-29 11:06:20 -0500) Qualcomm ARM Based driver Updates for v3.16-2 * Updated MSM uart driver to not access GSBI control registers Andy Gross (1): tty: serial: msm: Remove direct access to GSBI drivers/tty/serial/msm_serial.c | 48 ++--- drivers/tty/serial/msm_serial.h | 5 - 2 files changed, 2 insertions(+), 51 deletions(-) Do you want me to take these in the tty tree? Or are they going to go through the arm tree(s) for other reasons (dependancies)? In the other thread about this patch (http://marc.info/?l=linux-kernelm=140137951814522w=2), he claimed: I’ll send it via arm-soc as the related patches are going via that path. I'm not fussed either way. I haven't touched these branches yet. -Olof -- 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: [GIT PULL] qcom DT changes for v3.16-2
On Fri, May 30, 2014 at 11:38:13AM -0500, Kumar Gala wrote: The following changes since commit 08f9234ad6b0b8bc51046346eabf5b92e631e62a: soc: qcom: Add device tree binding for GSBI (2014-05-23 11:38:53 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-dt-for-3.16-2 for you to fetch changes up to f46d23f6f3676720de2a3f195413a5e69f202238: ARM: dts: qcom: Add APQ8084-MTP board support (2014-05-29 11:16:45 -0500) Qualcomm ARM Based Device Tree Updates for v3.16-2 * Updated MSM8660/MSM8960/MSM8974 dts for various updates or conformitity to binding specs * Added APQ8064 SoC and IFC6410 board device tree support * Added APQ8084 SoC and APQ8084-MTP board device tree support Merged, thanks. -Olof -- 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: [GIT PULL] qcom defconfig changes for v3.16-2
On Fri, May 30, 2014 at 11:42:25AM -0500, Kumar Gala wrote: The following changes since commit f604759ec025e21d0c29a6d0addd53bbc60eb12e: ARM: config: Update msm_defconfig (2014-05-22 11:18:56 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-defconfig-for-3.16-2 Merged, thanks. -Olof -- 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: [GIT PULL] qcom SoC changes for v3.16-2
On Fri, May 30, 2014 at 11:43:13AM -0500, Kumar Gala wrote: The following changes since commit 87cfb00d666cca3abf36f755279cde1b27b9c377: ARM: qcom: Select PINCTRL by default for ARCH_QCOM (2014-05-22 11:50:42 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-soc-for-3.16-2 for you to fetch changes up to 2f528dd3b30c4351c0ece73b8bdc39753c02003b: ARM: debug: qcom: add UART addresses to Kconfig help for APQ8084 (2014-05-29 11:14:28 -0500) Qualcomm ARM Based SoC Updates for v3.16-2 * Updated Kconfig DEBUG_QCOM_UARTDM help to include APQ8084 info Merged, thanks. -Olof -- 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: [GIT PULL] qcom driver changes for v3.16-2
On Fri, May 30, 2014 at 11:41:01AM -0500, Kumar Gala wrote: The following changes since commit 5d144e36b7c51612922fa05d37ff3a869261cc82: soc: qcom: Add GSBI driver (2014-05-23 11:38:04 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git tags/qcom-drivers-for-3.16-2 for you to fetch changes up to 31964ffebbb958c6cf289c7c12edd7530d6221b9: tty: serial: msm: Remove direct access to GSBI (2014-05-29 11:06:20 -0500) Qualcomm ARM Based driver Updates for v3.16-2 * Updated MSM uart driver to not access GSBI control registers Ok, merged. -Olof -- 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
