[PATCH v10 1/8] ARM: edma: Add AM33XX support to the private EDMA API
From: Matt Porter
Adds support for parsing the TI EDMA DT data into the required EDMA
private API platform data. Enables runtime PM support to initialize
the EDMA hwmod. Enables build on OMAP.
Changes by Joel:
* Setup default one-to-one mapping for queue_priority and queue_tc
mapping as discussed in [1].
* Split out xbar stuff to separate patch. [1]
[1] https://patchwork.kernel.org/patch/2226761/
Signed-off-by: Matt Porter
Acked-by: Sekhar Nori
Signed-off-by: Joel A Fernandes
---
arch/arm/common/edma.c | 190 +---
arch/arm/mach-omap2/Kconfig|1 +
include/linux/platform_data/edma.h |4 +-
3 files changed, 181 insertions(+), 14 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index a1db6cd..9823b79 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -24,6 +24,13 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
#include
@@ -1369,31 +1376,173 @@ void edma_clear_event(unsigned channel)
EXPORT_SYMBOL(edma_clear_event);
/*---*/
+static int edma_of_read_u32_to_s8_array(const struct device_node *np,
+const char *propname, s8 *out_values,
+size_t sz)
+{
+ int ret;
+
+ ret = of_property_read_u8_array(np, propname, out_values, sz);
+ if (ret)
+ return ret;
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_of_read_u32_to_s16_array(const struct device_node *np,
+const char *propname, s16 *out_values,
+size_t sz)
+{
+ int ret;
+
+ ret = of_property_read_u16_array(np, propname, out_values, sz);
+ if (ret)
+ return ret;
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
-static int __init edma_probe(struct platform_device *pdev)
+static int edma_of_parse_dt(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata)
+{
+ int ret = 0, i;
+ u32 value;
+ struct property *prop;
+ size_t sz;
+ struct edma_rsv_info *rsv_info;
+ const s16 (*rsv_chans)[2], (*rsv_slots)[2];
+ s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+
+ memset(pdata, 0, sizeof(struct edma_soc_info));
+
+ ret = of_property_read_u32(node, "dma-channels", &value);
+ if (ret < 0)
+ return ret;
+ pdata->n_channel = value;
+
+ ret = of_property_read_u32(node, "ti,edma-regions", &value);
+ if (ret < 0)
+ return ret;
+ pdata->n_region = value;
+
+ ret = of_property_read_u32(node, "ti,edma-slots", &value);
+ if (ret < 0)
+ return ret;
+ pdata->n_slot = value;
+
+ pdata->n_cc = 1;
+ pdata->n_tc = 3;
+
+ rsv_info =
+ devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
+ if (!rsv_info)
+ return -ENOMEM;
+ pdata->rsv = rsv_info;
+
+ queue_tc_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
+ if (!queue_tc_map)
+ return -ENOMEM;
+
+ for (i = 0; i < 3; i++)
+ queue_tc_map[i][0] = queue_tc_map[i][1] = i;
+ queue_tc_map[i][0] = queue_tc_map[i][1] = -1;
+
+ pdata->queue_tc_mapping = queue_tc_map;
+
+ queue_priority_map = devm_kzalloc(dev, 8*sizeof(s8), GFP_KERNEL);
+ if (!queue_priority_map)
+ return -ENOMEM;
+
+ for (i = 0; i < 3; i++)
+ queue_priority_map[i][0] = queue_priority_map[i][1] = i;
+ queue_priority_map[i][0] = queue_priority_map[i][1] = -1;
+
+ pdata->queue_priority_mapping = queue_priority_map;
+
+ pdata->default_queue = 0;
+
+
+ return ret;
+}
+
+static struct of_dma_filter_info edma_filter_info = {
+ .filter_fn = edma_filter_fn,
+};
+
+static int edma_probe(struct platform_device *pdev)
{
struct edma_soc_info**info = pdev->dev.platform_data;
- const s8(*queue_priority_mapping)[2];
- const s8(*queue_tc_mapping)[2];
+ struct edma_soc_info*ninfo[EDMA_MAX_CC] = {NULL, NULL};
+ struct edma_soc_infotmpinfo;
+ s8 (*queue_priority_mapping)[2];
+ s8 (*queue_tc_mapping)[2];
int i, j, off, ln, found = 0;
int status = -1;
const s16 (*rsv_chans)[2];
const s16 (*rsv_slots)[2];
int irq[EDMA_MAX_CC] = {0, 0};
int err_irq[EDMA_MAX_CC] = {0, 0};
- struct resource *r[EDMA_MAX_CC] = {NUL
[PATCH v10 6/8] spi: omap2-mcspi: add generic DMA request support to the DT binding
From: Matt Porter
The binding definition is based on the generic DMA request binding
Signed-off-by: Matt Porter
Signed-off-by: Joel A Fernandes
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..4c85c4c 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -10,7 +10,18 @@ Required properties:
input. The default is D0 as input and
D1 as output.
-Example:
+Optional properties:
+- dmas: List of DMA specifiers with the controller specific format
+ as described in the generic DMA client binding. A tx and rx
+ specifier is required for each chip select.
+- dma-names: List of DMA request names. These strings correspond
+ 1:1 with the DMA specifiers listed in dmas. The string naming
+ is to be "rxN" and "txN" for RX and TX requests,
+ respectively, where N equals the chip select number.
+
+Examples:
+
+[hwmod populated DMA resources]
mcspi1: mcspi@1 {
#address-cells = <1>;
@@ -20,3 +31,17 @@ mcspi1: mcspi@1 {
ti,spi-num-cs = <4>;
};
+[generic DMA request binding]
+
+mcspi1: mcspi@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "ti,omap4-mcspi";
+ti,hwmods = "mcspi1";
+ti,spi-num-cs = <2>;
+dmas = <&edma 42
+ &edma 43
+ &edma 44
+ &edma 45>;
+dma-names = "tx0", "rx0", "tx1", "rx1";
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 4/8] dmaengine: edma: enable build for AM33XX
From: Matt Porter Enable TI EDMA option on OMAP. Signed-off-by: Matt Porter Signed-off-by: Joel A Fernandes --- drivers/dma/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index e992489..3215a3c 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -213,7 +213,7 @@ config SIRF_DMA config TI_EDMA tristate "TI EDMA support" - depends on ARCH_DAVINCI + depends on ARCH_DAVINCI || ARCH_OMAP select DMA_ENGINE select DMA_VIRTUAL_CHANNELS default n -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 7/8] spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
From: Matt Porter
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Signed-off-by: Matt Porter
Acked-by: Mark Brown
Signed-off-by: Joel A Fernandes
---
drivers/spi/spi-omap2-mcspi.c | 64 -
1 file changed, 44 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 86d2158..ca4ab78 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -102,6 +102,9 @@ struct omap2_mcspi_dma {
struct completion dma_tx_completion;
struct completion dma_rx_completion;
+
+ char dma_rx_ch_name[14];
+ char dma_tx_ch_name[14];
};
/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
@@ -830,12 +833,20 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig = mcspi_dma->dma_rx_sync_dev;
- mcspi_dma->dma_rx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+
+ mcspi_dma->dma_rx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&sig, &master->dev,
+mcspi_dma->dma_rx_ch_name);
if (!mcspi_dma->dma_rx)
goto no_dma;
sig = mcspi_dma->dma_tx_sync_dev;
- mcspi_dma->dma_tx = dma_request_channel(mask, omap_dma_filter_fn, &sig);
+ mcspi_dma->dma_tx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+&sig, &master->dev,
+mcspi_dma->dma_tx_ch_name);
+
if (!mcspi_dma->dma_tx) {
dma_release_channel(mcspi_dma->dma_rx);
mcspi_dma->dma_rx = NULL;
@@ -1256,29 +1267,42 @@ static int omap2_mcspi_probe(struct platform_device
*pdev)
goto free_master;
for (i = 0; i < master->num_chipselect; i++) {
- char dma_ch_name[14];
+ char *dma_rx_ch_name = mcspi->dma_channels[i].dma_rx_ch_name;
+ char *dma_tx_ch_name = mcspi->dma_channels[i].dma_tx_ch_name;
struct resource *dma_res;
- sprintf(dma_ch_name, "rx%d", i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(&pdev->dev, "cannot get DMA RX channel\n");
- status = -ENODEV;
- break;
- }
+ sprintf(dma_rx_ch_name, "rx%d", i);
+ if (!pdev->dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_rx_ch_name);
+ if (!dma_res) {
+ dev_dbg(&pdev->dev,
+ "cannot get DMA RX channel\n");
+ status = -ENODEV;
+ break;
+ }
- mcspi->dma_channels[i].dma_rx_sync_dev = dma_res->start;
- sprintf(dma_ch_name, "tx%d", i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(&pdev->dev, "cannot get DMA TX channel\n");
- status = -ENODEV;
- break;
+ mcspi->dma_channels[i].dma_rx_sync_dev =
+ dma_res->start;
}
+ sprintf(dma_tx_ch_name, "tx%d", i);
+ if (!pdev->dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_tx_ch_name);
+ if (!dma_res) {
+ dev_dbg(&pdev->dev,
+ "cannot get DMA TX channel\n");
+ status = -ENODEV;
+ break;
+ }
- mcspi->dma_channels[i].dma_tx_sync_dev = dma_res->start;
+ mcspi->dma_channels[i].dma_tx_sync_dev =
+ dma_res->start;
+ }
}
if (status < 0)
--
1.7.9.5
--
To unsubscribe from this list: send
[PATCH v10 5/8] dmaengine: edma: Add TI EDMA device tree binding
From: Matt Porter
The binding definition is based on the generic DMA controller
binding.
Joel: Droped reserved and queue DT entries from Documentation
for now from the original patch series.
Signed-off-by: Matt Porter
Signed-off-by: Joel A Fernandes
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 26 +
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
new file mode 100644
index 000..ada0018
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,26 @@
+TI EDMA
+
+Required properties:
+- compatible : "ti,edma3"
+- ti,hwmods: Name of the hwmods associated to the EDMA
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+
+Optional properties:
+- ti,edma-xbar-event-map: Crossbar event to channel map
+
+Example:
+
+edma: edma@4900 {
+ reg = <0x4900 0x1>;
+ interrupt-parent = <&intc>;
+ interrupts = <12 13 14>;
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ ti,edma-xbar-event-map = <1 12
+ 2 13>;
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 8/8] ARM: dts: add AM33XX SPI DMA support
From: Matt Porter Adds DMA resources to the AM33XX SPI nodes. Signed-off-by: Matt Porter Signed-off-by: Joel A Fernandes --- arch/arm/boot/dts/am33xx.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index f8a8f19..119f8a9 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -352,6 +352,11 @@ interrupts = <65>; ti,spi-num-cs = <2>; ti,hwmods = "spi0"; + dmas = <&edma 16 + &edma 17 + &edma 18 + &edma 19>; + dma-names = "tx0", "rx0", "tx1", "rx1"; status = "disabled"; }; @@ -363,6 +368,11 @@ interrupts = <125>; ti,spi-num-cs = <2>; ti,hwmods = "spi1"; + dmas = <&edma 42 + &edma 43 + &edma 44 + &edma 45>; + dma-names = "tx0", "rx0", "tx1", "rx1"; status = "disabled"; }; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 2/8] ARM: edma: Add AM33XX EDMA crossbar event mux support
From: Matt Porter
Changes by Joel:
* Split EDMA xbar support out of original EDMA DT parsing patch
to keep it easier for review.
* rewrite shift and offset calculation as per
Suggested-by: Sekhar Nori
Suggested by: Andy Shevchenko
Signed-off-by: Joel A Fernandes
Reference:
[1] https://patchwork.kernel.org/patch/2226991/
---
arch/arm/common/edma.c | 59
include/linux/platform_data/edma.h |1 +
2 files changed, 60 insertions(+)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 9823b79..1c2fb15 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1410,6 +1410,52 @@ static int edma_of_read_u32_to_s16_array(const struct
device_node *np,
return 0;
}
+static int edma_xbar_event_map(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata, int len)
+{
+ int ret = 0;
+ int i;
+ struct resource res;
+ void *xbar;
+ const s16 (*xbar_chans)[2];
+ u32 shift, offset, mux;
+
+ xbar_chans = devm_kzalloc(dev,
+ len/sizeof(s16) + 2*sizeof(s16),
+ GFP_KERNEL);
+ if (!xbar_chans)
+ return -ENOMEM;
+
+ ret = of_address_to_resource(node, 1, &res);
+ if (ret)
+ return -EIO;
+
+ xbar = devm_ioremap(dev, res.start, resource_size(&res));
+ if (!xbar)
+ return -ENOMEM;
+
+ ret = edma_of_read_u32_to_s16_array(node,
+ "ti,edma-xbar-event-map",
+ (s16 *)xbar_chans,
+ len/sizeof(u32));
+ if (ret)
+ return -EIO;
+
+ for (i = 0; xbar_chans[i][0] != -1; i++) {
+ shift = (xbar_chans[i][1] & 0x03) << 3;
+ offset = xbar_chans[i][1] & 0xfffc;
+ mux = readl((void *)((u32)xbar + offset));
+ mux &= ~(0xff << shift);
+ mux |= xbar_chans[i][0] << shift;
+ writel(mux, (void *)((u32)xbar + offset));
+ }
+
+ pdata->xbar_chans = xbar_chans;
+
+ return 0;
+}
+
static int edma_of_parse_dt(struct device *dev,
struct device_node *node,
struct edma_soc_info *pdata)
@@ -1470,6 +1516,9 @@ static int edma_of_parse_dt(struct device *dev,
pdata->default_queue = 0;
+ prop = of_find_property(node, "ti,edma-xbar-event-map", &sz);
+ if (prop)
+ ret = edma_xbar_event_map(dev, node, pdata, sz);
return ret;
}
@@ -1489,6 +1538,7 @@ static int edma_probe(struct platform_device *pdev)
int status = -1;
const s16 (*rsv_chans)[2];
const s16 (*rsv_slots)[2];
+ const s16 (*xbar_chans)[2];
int irq[EDMA_MAX_CC] = {0, 0};
int err_irq[EDMA_MAX_CC] = {0, 0};
struct resource *r[EDMA_MAX_CC] = {NULL, NULL};
@@ -1617,6 +1667,15 @@ static int edma_probe(struct platform_device *pdev)
}
}
+ /* Clear the xbar mapped channels in unused list */
+ xbar_chans = info[j]->xbar_chans;
+ if (xbar_chans) {
+ for (i = 0; xbar_chans[i][1] != -1; i++) {
+ off = xbar_chans[i][1];
+ clear_bits(off, 1,
+ edma_cc[j]->edma_unused);
+ }
+ }
if (node)
irq[j] = irq_of_parse_and_map(node, 0);
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
index 317f2be..57300fd 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -177,6 +177,7 @@ struct edma_soc_info {
s8 (*queue_tc_mapping)[2];
s8 (*queue_priority_mapping)[2];
+ const s16 (*xbar_chans)[2];
};
#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 3/8] ARM: dts: add AM33XX EDMA support
From: Matt Porter
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Joel: Drop DT entries that are non-hardware-description for now as discussed in
[1]
[1] https://patchwork.kernel.org/patch/2226761/
Signed-off-by: Matt Porter
Signed-off-by: Joel A Fernandes
---
arch/arm/boot/dts/am33xx.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 70c86a0..f8a8f19 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -89,6 +89,18 @@
reg = <0x4820 0x1000>;
};
+ edma: edma@4900 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ reg = <0x4900 0x1>,
+ <0x44e10f90 0x10>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ };
+
gpio0: gpio@44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 0/8] DMA Engine support for AM33XX
This series is a repost of Matt Porter's EDMA patches for AM33XX EDMA support with changes for few pending review comments on v9 series. Currently this is required for AM33XX (Beaglebone or EVM) to access MMC and be able mount to rootfs and boot till command prompt over MMC. Unless there are other pending review comments, I hope this series can finally make it into 3.11 merge window though that is probably wishful thinking at this point considering below code movement patches [1] is pending review and Ack. Tested EDMA on AM1808 EVM and AM33XX Beaglebone with MMC. Sekhar Nori has posted a GIT PULL [1] which has 2 patches this series depends on: ARM: davinci: move private EDMA API to arm/common ARM: dts: add AM33XX MMC support [1] http://www.spinics.net/lists/arm-kernel/msg251503.html Changes since v9: - Droped reserved and queue DT entries from Documentation for now from the original patch series. - Drop DT entries that are non-hardware-description - Split EDMA xbar support out of original EDMA DT parsing patch to keep it easier for review. - Rewrite shift and offset calculation xbar event mapping. - Setup default one-to-one mapping for queue_priority and queue_tc mapping as discussed in. - Split out xbar stuff to separate patch. Reference discussion: https://patchwork.kernel.org/patch/2226761/ Changes since v8: - Removed edma node interrupt-parent property, it is inherited Changes since v7: - Dropped dmaengine compat() patch. It is upstream. - Submitted edma_alloc_slot() error checking bug fix separately, now a dependency - Fixed bisect issues due to 3/10 hunks that went into 1/10 - Fixed incorrect IS_ERRVALUE() use in 3/10 Changes since v6: - Converted edma_of_read_*() to wrappers around of_property_read_*() - Fixed wording on the omap-spi generic DMA properties - Added comment/check to clarify that the driver only supports a single EDMA instance when booting from DT Changes since v5: - Dropped mmc portion and moved it to a separate series - Incorporate corrected version of dma_request_slave_channel_compat() - Fix #defines and enablement of TI_PRIV_EDMA option Changes since v4: - Fixed debug section mismatch in private edma api [01/14] - Respun format-patch to catch the platform_data/edma.h rename [01/14] - Removed address/size-cells from the EDMA binding [05/14] Changes since v3: - Rebased on 3.8-rc3 - No longer an RFC - Fixed bugs in DT/pdata parsing reported by Vaibhav Bedia - Restored all the Davinci pdata to const - Removed max_segs hack in favor of using dma_get_channel_caps() - Fixed extra parens, __raw_* accessors and, ioremap error checks in xbar handling - Removed excess license info in platform_data/edma.h - Removed unneeded reserved channels data for AM33xx - Removed test-specific pinmuxing from dts files - Adjusted mmc1 node to be disabled by default in the dtsi Changes since v2: - Rebased on 3.7-rc1 - Fixed bug in DT/pdata parsing first found by Gururaja that turned out to be masked by some toolchains - Dropped unused mach-omap2/devices.c hsmmc patch - Added AM33XX crossbar DMA event mux support - Added am335x-evm support Changes since v1: - Rebased on top of mainline from 12250d8 - Dropped the feature removal schedule patch - Implemented dma_request_slave_channel_compat() and converted the mmc and spi drivers to use it - Dropped unneeded #address-cells and #size-cells from EDMA DT support - Moved private EDMA header to linux/platform_data/ and removed some unneeded definitions - Fixed parsing of optional properties This series adds DMA Engine support for AM33xx, which uses an EDMA DMAC. The EDMA DMAC has been previously supported by only a private API implementation (much like the situation with OMAP DMA) found on the DaVinci family of SoCs. The series applies on top of 3.10-rc4. The approach taken is similar to how OMAP DMA is being converted to DMA Engine support. With the functional EDMA private API already existing in mach-davinci/dma.c, we first move that to an ARM common area so it can be shared. Adding DT and runtime PM support to the private EDMA API implementation allows it to run on AM33xx. AM33xx *only* boots using DT so the upstream generic DT DMA helpers are leveraged to register EDMA DMAC with the of_dma framework. SPI (and MMC in a separate series) are supported using the upstream dma_request_slave_channel_compat() dmaengine call that allows compatibility with !DT platforms. With this series both BeagleBone and the AM335x EVM have working SPI DMA support (and MMC support with the separate MMC series). This is tested on BeagleBone with a SPI framebuffer driver and MMC
Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
Hi, On Fri, Jun 14, 2013 at 02:54:33PM -0500, Joel A Fernandes wrote: > Hi Tony, Vaibhav, > > >> I just doublechecked MMC rootfs on bone and evmsk as it's the standard > >> smoke test. My EVM is intermittent now so trying to coax it to power up > >> to reverify. > >> > > > > Matt, > > > > Your branch is working for me, I tested it on EVM. Not sure what is wrong > > with manual rebasing > > I did yesterday. I will try to nail-down root-cause here. > > > > And you can submit the next version fixing the comments I have given. > > The only comment I could find in the whole discussion was adding of > the interrupts property. I tested I don't have any problem booting > with Matt's patch, without having the interrupts property. might very well be, but we want to figure out why adding "intrrupts" causes issues. Why does it have to come through hwmod ? You might have uncovered a real problem which needs fixing. Besides, at the end of the day, we want to remove the redundant hwmod data if we already have DTS bindings covering the same requirements. -- balbi signature.asc Description: Digital signature
Re: [PATCH RFC 1/3] clk: omap: introduce clock driver
On Mon, 3 Jun 2013 23:39:16 -0700, Mike Turquette
wrote:
> Parses OMAP clock data from DT and registers those clocks with the clock
> framework. dt_omap_clk_init must be called early during boot for timer
> initialization so it is exported and called from the existing clock code
> instead of probing like a real driver.
>
> Cc: Benoit Cousson
> Cc: Rajendra Nayak
> Cc: Joel A Fernandes
> Cc: Nishanth Menon
> Cc: Paul Walmsley
> Cc: Tony Lindgren
> Signed-off-by: Mike Turquette
Hi Mike,
Comments below...
> ---
> This driver simply matches the basic bindings (so far). Eventually it
> would match omap-specific bindings for DPLLs, CLKOUTX2 and strange leaf
> clocks as well. This doesn't scale well since non-OMAP related clock
> data (e.g. a pmic or discrete audio codec) will get grouped into this
> driver if it matches on a basic clock type. Suggestions?
Take a look at the definition of irqchip_init(). It would be possible to
do the same think for clk chips so that merely configuring in the driver
would add the support to a global list of clk chip initializers.
drivers/irqchip/irqchip.c
>
> drivers/clk/Makefile | 1 +
> drivers/clk/omap/Makefile | 1 +
> drivers/clk/omap/clk.c| 55
> +++
> include/linux/clk/omap.h | 24 +
> 4 files changed, 81 insertions(+)
> create mode 100644 drivers/clk/omap/Makefile
> create mode 100644 drivers/clk/omap/clk.c
> create mode 100644 include/linux/clk/omap.h
>
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index f51b52b..efd4f2a 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -31,6 +31,7 @@ obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
> obj-$(CONFIG_ARCH_ZYNQ) += clk-zynq.o
> obj-$(CONFIG_ARCH_TEGRA) += tegra/
> obj-$(CONFIG_PLAT_SAMSUNG) += samsung/
> +obj-$(CONFIG_ARCH_OMAP) += omap/
>
> obj-$(CONFIG_X86)+= x86/
>
> diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
> new file mode 100644
> index 000..8195931
> --- /dev/null
> +++ b/drivers/clk/omap/Makefile
> @@ -0,0 +1 @@
> +obj-y+= clk.o
> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
> new file mode 100644
> index 000..e9e5c95
> --- /dev/null
> +++ b/drivers/clk/omap/clk.c
> @@ -0,0 +1,55 @@
> +/*
> + * OMAP PRCM clock driver
> + *
> + * Copyright (C) 2013 Linaro.org - http://www.linaro.org
> + * Mike Turquette
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* FIXME - should the OMAP PRCM clock driver match generic types? */
> +static const struct of_device_id clk_match[] = {
> + {.compatible = "fixed-clock", .data = of_fixed_clk_setup, },
> + {.compatible = "mux-clock", .data = of_mux_clk_setup, },
> + {.compatible = "fixed-factor-clock",
> + .data = of_fixed_factor_clk_setup, },
> + {},
> +};
> +
> +static int omap_clk_probe(struct platform_device *pdev)
> +{
> + of_clk_init(clk_match);
> + return 0;
> +}
> +
> +static struct platform_driver omap_clk_driver = {
> + .probe = omap_clk_probe,
> + .driver = {
> +.name = "omap_clk",
> +.of_match_table = of_match_ptr(clk_match),
> +},
> +};
> +
> +/* FIXME - need to initialize early; skip real driver registration & probe */
> +int __init dt_omap_clk_init(void)
> +{
> + return omap_clk_probe(NULL);
> +}
Since this isn't remotely a platform_driver, I would drop the pretense
and cut out all the platform_drivers references. omap_clk_driver isn't
even referenced anywhere!
> +
> +MODULE_DESCRIPTION("OMAP Clock driver");
> +MODULE_AUTHOR("Texas Instruments Inc.");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
> new file mode 100644
> index 000..504e838
> --- /dev/null
> +++ b/include/linux/clk/omap.h
> @@ -0,0 +1,24 @@
> +/*
> + * Copyright (C) 2010 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Pub
Re: [GIT PULL 4/6] omap gpmc changes for v3.11 merge window
On Wed, Jun 12, 2013 at 11:24:35AM -0700, Tony Lindgren wrote: > The following changes since commit f722406faae2d073cc1d01063d1123c35425939e: > > Linux 3.10-rc1 (2013-05-11 17:14:08 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v3.11/gpmc-signed > > for you to fetch changes up to b3f5525c55ce5cb67af06f04dbbf28358da23a2c: > > ARM: OMAP2+: gpmc: Converts GPMC driver to pm_runtime capable (2013-06-12 > 09:56:30 -0700) > Pulled. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 6/6] omap5 data for v3.11 merge window
On Wed, Jun 12, 2013 at 11:24:35AM -0700, Tony Lindgren wrote: > The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10: > > Linux 3.10-rc5 (2013-06-08 17:41:04 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v3.11/omap5-signed > > for you to fetch changes up to 6503a8e109a639760408f874c1251060d563942e: > > ARM: OMAP5: Remove unused include for ocp2scp (2013-06-09 21:17:15 -0700) Pulled. > 25 files changed, 8982 insertions(+), 55 deletions(-) Owwie. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 3/6] omap pm changes for v3.11 merge window
On Wed, Jun 12, 2013 at 11:24:34AM -0700, Tony Lindgren wrote: > The following changes since commit f722406faae2d073cc1d01063d1123c35425939e: > > Linux 3.10-rc1 (2013-05-11 17:14:08 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v3.11/pm-signed > > for you to fetch changes up to 49a34fd5380d249ae8a2173399c62fc5a1fddd70: > > Merge tag 'omap-pm-v3.10/cleanup/pm' of > git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into > omap-for-v3.11/pm (2013-05-16 08:27:49 -0700) Pulled, thanks. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 5/6] omap soc changes for v3.11 merge window
On Wed, Jun 12, 2013 at 11:24:35AM -0700, Tony Lindgren wrote: > The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10: > > Linux 3.10-rc5 (2013-06-08 17:41:04 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v3.11/soc-signed > > for you to fetch changes up to 4f288f081bb67813d35c10d1b2fa68e863c4b188: > > ARM: OMAP2+: AM43x: SRAM base and size (2013-06-12 08:07:23 -0700) Pulled, thanks. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 2/6] omap cleanup for v3.11 merge window
On Wed, Jun 12, 2013 at 11:24:33AM -0700, Tony Lindgren wrote: > The following changes since commit d683b96b072dc4680fc74964eca77e6a23d1fa6e: > > Linux 3.10-rc4 (2013-06-02 17:11:17 +0900) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v3.11/cleanup-signed > > for you to fetch changes up to 09182ab11b49b67d04598b19eb89cf0bbd672a60: > > ARM: OMAP4: hwmod data: Remove irq entries from mcspi, mmc hwmods > (2013-06-12 09:41:46 -0700) > > > Move omap4 over to device tree based booting. This allows us to get rid > a big pile of platform init code for things that are already handled by > device tree related code. As am33xx is already device tree based, we > can also remove the same data for am33xx. Hm. This one has a somewhat silly conflict with the am33xx hwmod fix for uart2. I.e. the fix is reverted since the code is no longer needed -- data comes from device tree. Please double-check my merge resolution on it though. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 1/6] non-critical omap fixes for v3.11 merge window
On Wed, Jun 12, 2013 at 11:24:33AM -0700, Tony Lindgren wrote: > The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10: > > Linux 3.10-rc5 (2013-06-08 17:41:04 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v3.11/fixes-non-critical-signed Pulled. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: add AM33XX MMC support
Hi Tony, Vaibhav, >> I just doublechecked MMC rootfs on bone and evmsk as it's the standard >> smoke test. My EVM is intermittent now so trying to coax it to power up >> to reverify. >> > > Matt, > > Your branch is working for me, I tested it on EVM. Not sure what is wrong > with manual rebasing > I did yesterday. I will try to nail-down root-cause here. > > And you can submit the next version fixing the comments I have given. The only comment I could find in the whole discussion was adding of the interrupts property. I tested I don't have any problem booting with Matt's patch, without having the interrupts property. Can this patch be pulled in for 3.11? Tested-by: Joel A Fernandes Thanks, Joel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: OMAP5: Fix omap5 standalone build break
On Friday 14 June 2013 05:11 AM, Rajendra Nayak wrote: > Building omap5 standalone results in the below errors.. > > arch/arm/mach-omap2/built-in.o: In function `scu_gp_set': > arch/arm/mach-omap2/sleep44xx.S:132: undefined reference to `scu_power_mode' > arch/arm/mach-omap2/built-in.o: In function `scu_gp_clear': > arch/arm/mach-omap2/sleep44xx.S:229: undefined reference to `scu_power_mode' > arch/arm/mach-omap2/built-in.o: In function `omap4_smp_prepare_cpus': > arch/arm/mach-omap2/omap-smp.c:211: undefined reference to `scu_enable' > arch/arm/mach-omap2/built-in.o: In function `omap4_smp_init_cpus': > arch/arm/mach-omap2/omap-smp.c:185: undefined reference to > `scu_get_core_count' > > Fix this by adding the missing select for HAVE_ARM_SCU for SOC_OMAP5 > > Reported-by: Pekon Gupta > Signed-off-by: Rajendra Nayak > --- NAK. Similar patch [1] was posted by Vincent a while back. The right fix to remove the scu related dependency with OMAP5 code. Regards, Santosh [1] https://patchwork.kernel.org/patch/2568091/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] omap_hsmmc DT DMA Client support
Hi, On Wed, Mar 6, 2013 at 7:37 AM, Matt Porter wrote: > On Tue, Mar 05, 2013 at 09:26:01PM +, Arnd Bergmann wrote: >> On Tuesday 05 March 2013, Matt Porter wrote: >> > Changes since v1: >> > - rebase to 3.9-rc1, previous dependencies upstream >> > >> > This series adds DT DMA Engine Client support to the omap_hsmmc. >> > It leverages the generic DMA OF helpers in -next and the >> > dma_request_slave_channel_compat() wrapper introduced in the >> > AM33XX DMA Engine series to support DMA in omap_hsmmc on platforms >> > booting via DT. These platforms include omap2/3/4/5 and am33xx. >> > >> > These patches were split out from the v5 version of the AM33XX DMA >> > series and split from the EDMA-specific omap_hsmmc changes. >> > >> >> The description seems stale, but the patches all look good to me. >> >> I guess they can now get merged in any order. >> >> Acked-by: Arnd Bergmann > > Yes, missed updating that to indicating that those are now in > 3.9-rc1. If there are no more changes, could this patch please be merged in for 3.10 or if not, could Matt please update the description as requested and repost? Thanks, Joel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] omap_hsmmc DT DMA Client support
Resending on Matt's new email, thanks. On Fri, Jun 14, 2013 at 1:10 PM, Joel A Fernandes wrote: > Hi, > > On Wed, Mar 6, 2013 at 7:37 AM, Matt Porter wrote: >> On Tue, Mar 05, 2013 at 09:26:01PM +, Arnd Bergmann wrote: >>> On Tuesday 05 March 2013, Matt Porter wrote: >>> > Changes since v1: >>> > - rebase to 3.9-rc1, previous dependencies upstream >>> > >>> > This series adds DT DMA Engine Client support to the omap_hsmmc. >>> > It leverages the generic DMA OF helpers in -next and the >>> > dma_request_slave_channel_compat() wrapper introduced in the >>> > AM33XX DMA Engine series to support DMA in omap_hsmmc on platforms >>> > booting via DT. These platforms include omap2/3/4/5 and am33xx. >>> > >>> > These patches were split out from the v5 version of the AM33XX DMA >>> > series and split from the EDMA-specific omap_hsmmc changes. >>> > >>> >>> The description seems stale, but the patches all look good to me. >>> >>> I guess they can now get merged in any order. >>> >>> Acked-by: Arnd Bergmann >> >> Yes, missed updating that to indicating that those are now in >> 3.9-rc1. > > If there are no more changes, could this patch please be merged in for > 3.10 or if not, could Matt please update the description as requested > and repost? > > Thanks, > Joel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] spi: omap2-mcspi: Add FIFO buffer support
On 06/12/2013 06:47 PM, Mark Brown wrote: On Tue, Jun 11, 2013 at 08:09:15PM +0300, Illia Smyrnov wrote: The MCSPI controller has a built-in FIFO buffer to unload the DMA or interrupt handler and improve data throughput. This patch adds FIFO buffer support for SPI transfers in DMA mode. The FIFO could be enabled for SPI module by setting up the "ti,spi-fifo-enabled" configuration parameter in DT. If FIFO enabled, the largest possible FIFO buffer size will be calculated and setup for each SPI transfer. Even if the FIFO is enabled in DT, it won't be used for the SPI transfers when: calculated FIFO buffer size is less then 2 bytes or the FIFO buffer size isn't multiple of the SPI word length. Why is the default to disable the FIFO? I have changed this and sent v3 patches of the MCSPI FIFO support implementation. In this version driver set up the FIFO (if possible) for all the SPI transfers in DMA mode. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] spi: omap2-mcspi: Add FIFO buffer support
The MCSPI controller has a built-in FIFO buffer to unload the DMA or interrupt
handler and improve data throughput. This patch adds FIFO buffer support for SPI
transfers in DMA mode.
For SPI transfers in DMA mode, the largest possible FIFO buffer size will be
calculated and set up. The FIFO won't be used for the SPI transfers in DMA mode
if: calculated FIFO buffer size is less then 2 bytes or the FIFO buffer size
isn't multiple of the SPI word length.
Signed-off-by: Illia Smyrnov
---
drivers/spi/spi-omap2-mcspi.c | 147 -
1 files changed, 130 insertions(+), 17 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 707f1db..90bdf67 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -39,12 +39,15 @@
#include
#include
#include
+#include
#include
#include
#define OMAP2_MCSPI_MAX_FREQ 4800
+#define OMAP2_MCSPI_MAX_FIFODEPTH 64
+#define OMAP2_MCSPI_MAX_FIFOWCNT 0x
#define SPI_AUTOSUSPEND_TIMEOUT2000
#define OMAP2_MCSPI_REVISION 0x00
@@ -54,6 +57,7 @@
#define OMAP2_MCSPI_WAKEUPENABLE 0x20
#define OMAP2_MCSPI_SYST 0x24
#define OMAP2_MCSPI_MODULCTRL 0x28
+#define OMAP2_MCSPI_XFERLEVEL 0x7c
/* per-channel banks, 0x14 bytes each, first is: */
#define OMAP2_MCSPI_CHCONF00x2c
@@ -63,6 +67,7 @@
#define OMAP2_MCSPI_RX00x3c
/* per-register bitmasks: */
+#define OMAP2_MCSPI_IRQSTATUS_EOW BIT(17)
#define OMAP2_MCSPI_MODULCTRL_SINGLE BIT(0)
#define OMAP2_MCSPI_MODULCTRL_MS BIT(2)
@@ -83,10 +88,13 @@
#define OMAP2_MCSPI_CHCONF_IS BIT(18)
#define OMAP2_MCSPI_CHCONF_TURBO BIT(19)
#define OMAP2_MCSPI_CHCONF_FORCE BIT(20)
+#define OMAP2_MCSPI_CHCONF_FFETBIT(27)
+#define OMAP2_MCSPI_CHCONF_FFERBIT(28)
#define OMAP2_MCSPI_CHSTAT_RXS BIT(0)
#define OMAP2_MCSPI_CHSTAT_TXS BIT(1)
#define OMAP2_MCSPI_CHSTAT_EOT BIT(2)
+#define OMAP2_MCSPI_CHSTAT_TXFFE BIT(3)
#define OMAP2_MCSPI_CHCTRL_EN BIT(0)
@@ -129,6 +137,7 @@ struct omap2_mcspi {
struct omap2_mcspi_dma *dma_channels;
struct device *dev;
struct omap2_mcspi_regs ctx;
+ int fifo_depth;
unsigned intpin_dir:1;
};
@@ -258,6 +267,58 @@ static void omap2_mcspi_set_master_mode(struct spi_master
*master)
ctx->modulctrl = l;
}
+static void omap2_mcspi_set_fifo(const struct spi_device *spi,
+ struct spi_transfer *t, int enable)
+{
+ struct spi_master *master = spi->master;
+ struct omap2_mcspi_cs *cs = spi->controller_state;
+ struct omap2_mcspi *mcspi;
+ unsigned int wcnt;
+ int fifo_depth, bytes_per_word;
+ u32 chconf, xferlevel;
+
+ mcspi = spi_master_get_devdata(master);
+
+ chconf = mcspi_cached_chconf0(spi);
+ if (enable) {
+ bytes_per_word = mcspi_bytes_per_word(cs->word_len);
+ if (t->len % bytes_per_word != 0)
+ goto disable_fifo;
+
+ fifo_depth = gcd(t->len, OMAP2_MCSPI_MAX_FIFODEPTH);
+ if (fifo_depth < 2 || fifo_depth % bytes_per_word != 0)
+ goto disable_fifo;
+
+ wcnt = t->len / bytes_per_word;
+ if (wcnt > OMAP2_MCSPI_MAX_FIFOWCNT)
+ goto disable_fifo;
+
+ xferlevel = wcnt << 16;
+ if (t->rx_buf != NULL) {
+ chconf |= OMAP2_MCSPI_CHCONF_FFER;
+ xferlevel |= (fifo_depth - 1) << 8;
+ } else {
+ chconf |= OMAP2_MCSPI_CHCONF_FFET;
+ xferlevel |= fifo_depth - 1;
+ }
+
+ mcspi_write_reg(master, OMAP2_MCSPI_XFERLEVEL, xferlevel);
+ mcspi_write_chconf0(spi, chconf);
+ mcspi->fifo_depth = fifo_depth;
+
+ return;
+ }
+
+disable_fifo:
+ if (t->rx_buf != NULL)
+ chconf &= ~OMAP2_MCSPI_CHCONF_FFER;
+ else
+ chconf &= ~OMAP2_MCSPI_CHCONF_FFET;
+
+ mcspi_write_chconf0(spi, chconf);
+ mcspi->fifo_depth = 0;
+}
+
static void omap2_mcspi_restore_ctx(struct omap2_mcspi *mcspi)
{
struct spi_master *spi_cntrl = mcspi->master;
@@ -374,7 +435,7 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct
spi_transfer *xfer,
{
struct omap2_mcspi *mcspi;
struct omap2_mcspi_dma *mcspi_dma;
- unsigned intcount;
+ unsigned intcount, dma_count;
u32 l;
int elements = 0;
int word_len, element_count;
@@ -382,6 +443,11 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct
spi_transfer *xfer,
[PATCH v3 0/2] spi: omap2-mcspi: add FIFO buffer support
These patches introduce FIFO support for TI OMAP4/OMAP5 MCSPI controller. Using FIFO unload the DMA and improve data throughput. On Blaze (OMAP 4460) ethernet throughput with MTU 1500 was increased: * for TX from 6.9476 Mbps (FIFO disabled) to 8.1046 Mbps (FIFO enabled), * for RX from 6.5120 Mbps (FIFO disabled) to 7.6091 Mbps (FIFO enabled). The FIFO sanity test on OMAP5 Panda board also has been done. The FIFO is enabled for SPI transfers in DMA mode. The largest possible FIFO buffer size will be calculated and set up. The FIFO won't be used for the SPI transfers in DMA mode if: calculated FIFO buffer size is less then 2 bytes or the FIFO buffer size isn't multiple of the SPI word length. The MCSPI FIFO constraints are: * FIFO depth size defined as a multiple of the SPI word length; * transfer's data size is a multiple of FIFO depth; * transfer's words count less or equal 65535. Also FIFO buffer with 1 byte size is insignificant, so driver will setup FIFO if calculated size is within the 2 to 64 bytes range. v3: * FIFO enadled for all SPI transfers in DMA mode. v2: * driver calculate and setup optimal FIFO size for each SPI transfer; * "ti,spi-fifo-enabled" parameter in MCSPI DT node to enable FIFO; * no FIFO settings in SPI slaves nodes in DT; * Matthias Brugger patch was excluded from patch set. Illia Smyrnov (2): spi: omap2-mcspi: Move bytes per word calculation to the function spi: omap2-mcspi: Add FIFO buffer support drivers/spi/spi-omap2-mcspi.c | 166 +++-- 1 files changed, 143 insertions(+), 23 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] spi: omap2-mcspi: Move bytes per word calculation to the function
Introduce mcspi_bytes_per_word function as replacement for the next code
fragment:
int c = (word_len <= 8) ? 1 :
(word_len <= 16) ? 2 :
/* word_len <= 32 */ 4;
This code used 2 times in current driver code and will be used 2 times in
the next FIFO buffer support patch. Replace it with inline function with clear
name to improve code legibility.
Signed-off-by: Illia Smyrnov
---
drivers/spi/spi-omap2-mcspi.c | 19 +--
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 86d2158..707f1db 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -187,6 +187,16 @@ static inline void mcspi_write_chconf0(const struct
spi_device *spi, u32 val)
mcspi_read_cs_reg(spi, OMAP2_MCSPI_CHCONF0);
}
+static inline int mcspi_bytes_per_word(int word_len)
+{
+ if (word_len <= 8)
+ return 1;
+ else if (word_len <= 16)
+ return 2;
+ else /* word_len <= 32 */
+ return 4;
+}
+
static void omap2_mcspi_set_dma_req(const struct spi_device *spi,
int is_read, int enable)
{
@@ -433,10 +443,9 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct
spi_transfer *xfer,
else /* word_len <= 32 */
((u32 *)xfer->rx_buf)[elements++] = w;
} else {
+ int bytes_per_word = mcspi_bytes_per_word(word_len);
dev_err(&spi->dev, "DMA RX penultimate word empty");
- count -= (word_len <= 8) ? 2 :
- (word_len <= 16) ? 4 :
- /* word_len <= 32 */ 8;
+ count -= (bytes_per_word << 1);
omap2_mcspi_set_enable(spi, 1);
return count;
}
@@ -454,9 +463,7 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct
spi_transfer *xfer,
((u32 *)xfer->rx_buf)[elements] = w;
} else {
dev_err(&spi->dev, "DMA RX last word empty");
- count -= (word_len <= 8) ? 1 :
-(word_len <= 16) ? 2 :
- /* word_len <= 32 */ 4;
+ count -= mcspi_bytes_per_word(word_len);
}
omap2_mcspi_set_enable(spi, 1);
return count;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: AM43x EPOS EVM support
Add AM43x ePOS EVM minimal DT source - this is a minimal one to get
it booting. Also include it in omap2plus dtbs and document bindings.
The hardware is under development.
Signed-off-by: Afzal Mohammed
---
Hi Benoit,
This is based on your for_3.11/dts branch.
Ideally I wanted to split this into 3 patches - first doc, second dts
and last adding build support. As changes in total is trivial, it was
made a single one.
Regards
Afzal
Documentation/devicetree/bindings/arm/omap/omap.txt | 3 +++
arch/arm/boot/dts/Makefile | 3 ++-
arch/arm/boot/dts/am43x-epos-evm.dts| 18 ++
3 files changed, 23 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am43x-epos-evm.dts
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index f8288ea..6d498c7 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -56,3 +56,6 @@ Boards:
- OMAP5 EVM : Evaluation Module
compatible = "ti,omap5-evm", "ti,omap5"
+
+- AM43x EPOS EVM
+ compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8e50761..05da469 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -155,7 +155,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-evmsk.dtb \
am335x-bone.dtb \
am3517-evm.dtb \
- am3517_mt_ventoux.dtb
+ am3517_mt_ventoux.dtb \
+ am43x-epos-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
new file mode 100644
index 000..74174d4
--- /dev/null
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* AM43x EPOS EVM */
+
+/dts-v1/;
+
+#include "am4372.dtsi"
+
+/ {
+ model = "TI AM43x EPOS EVM";
+ compatible = "ti,am43x-epos-evm","ti,am4372","ti,am43";
+};
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Remove unused voltagedomain data for AM33xx
Paul Walmsley writes: > cc Kevin, Vaibhav > > On Thu, 13 Jun 2013, Rajendra Nayak wrote: > >> The powerdomain framework today expects to always have a voltagedomain >> associated with a given powerdomain. We already have AM33xx which >> has no Voltage Controller/Voltage Processor as part of PRCM. >> There are more SoCs' to follow starting with AM437x and DRA7xx >> which do not have VC/VP. >> >> Instead of adding dummy voltage domain data files, make the powerdomain >> framework aware of the fact that some SoCs' might not really have >> scalable voltage domains. > > Fine with me in principle if AM335x doesn't support voltage scaling. > Vaibhav, if this is okay for you, please ack it. > > Then, in terms of merging, probably Kevin would be the right person for > this since he's done much of the voltagedomain work. Yeah, I'll take this series after the minor issues I commented on are fixed, and Vaivhav ack's the AM33xx parts. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2+: Powerdomain: Remove the need to always have a voltdm associated to a pwrdm
Rajendra Nayak writes:
> The powerdomain framework expects all powerdomains to be associated with
s/expects/currently expects/
> a corresponding voltagedomain. For some SoCs' (like the already existing
> AM33xx
> family, or for the upcoming AM437x and DRA7 SoCs') which
> do not have a Voltage controller/Voltage Processor (neither the SR I2C
> bus to communicate with the PMIC) there is no need for a Powerdomain to have
> a voltage domain association (since they are really non scaleable, even
> though the voltage domains exist in place).
This last phrase inside the parentheses doesn't make sense to me.
Reading that makes me think that the lack of an on-chip voltage domain
means that evn an external regulators can't scale the voltage, which I
don't believe is the case.
> Extend the arch operations to add an api which the powerdomain core can
> then use to identify if a voltdm lookup and association for a powerdomain
> is really needed.
Yes, this idea looks right to me.
In addition to the wording above, a minor nit below...
[...]
> diff --git a/arch/arm/mach-omap2/powerdomain.h
> b/arch/arm/mach-omap2/powerdomain.h
> index 140c360..8ed89de 100644
> --- a/arch/arm/mach-omap2/powerdomain.h
> +++ b/arch/arm/mach-omap2/powerdomain.h
> @@ -166,6 +166,7 @@ struct powerdomain {
> * @pwrdm_disable_hdwr_sar: Disable Hardware Save-Restore feature for a pd
> * @pwrdm_set_lowpwrstchange: Enable pd transitions from a shallow to deep
> sleep
> * @pwrdm_wait_transition: Wait for a pd state transition to complete
> + * @pwrdm_has_voltdmi: Check if a voltdm association is needed
s/voltdmi/voltdm/
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: am335x: TSC & ADC reworking including DT pieces, take 4
On Tue, Jun 11, 2013 at 05:29:22PM +0200, Sebastian Andrzej Siewior wrote: > On 06/11/2013 04:23 PM, Samuel Ortiz wrote: > > Please fix your commit logs, and your subject lines. It should be e.g. > > mfd: input: ti_am335x_adc: Blablabla > > if it's mostly an mfd patch that also touches an input driver. > I usually do "subsystem / driver: short description" but if you want > the ":" as delimiter I can do this. You should always aim to be consistent with the style used by the code you're updating - do a git log and make sure your patches don't have changelogs that are obivously using a different style. signature.asc Description: Digital signature
Re: [PATCH 2/6] ARM: OMAP2+: Remove board-omap4panda.c
On Fri, Jun 14, 2013 at 9:31 PM, Ming Lei wrote: > On Thu, Jun 13, 2013 at 6:12 PM, Sricharan R wrote: >> On Thursday 13 June 2013 02:51 PM, Sricharan R wrote: >>> Hi Tony, >>> On Wednesday 12 June 2013 10:44 PM, Tony Lindgren wrote: * Tony Lindgren [130612 09:37]: > * Ming Lei [130603 08:34]: >> Hi, >> >> On Sat, May 18, 2013 at 3:17 AM, Tony Lindgren wrote: >>> We can now boot with device tree. If you don't want to update u-boot, >>> you can boot with appended DTB with the following instructions: >>> >>> 1. Make sure you have the appended DTB support in .config >>> >>>CONFIG_ARM_APPENDED_DTB=y >>>CONFIG_ARM_ATAG_DTB_COMPAT=y >>>CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y >>> >>> 2. Build the zImage >>> >>>$ ARCH=arm CROSS_COMPILE=... make zImage >>> >>> 3. Build the device tree blobs >>> >>>$ ARCH=arm CROSS_COMPILE=... make dtbs >>> >>> 4. Append the correct panda dtb to zImage >>> >>>Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb >>>or omap4-panda-es.dtb. >>> >>>$ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb > >>> /tmp/appended >>> >>> 5. Use mkimage to produce the appended device tree uImage >>> >>>$ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e >>> 0x80008000 \ >>> -n "Linux" -d /tmp/appended /tmp/uImage >> I followed the above steps and tried devicetree on Pandaboard against >> 3.10.0-rc3-next-20130528, and the board will hang during boot, but works >> well with legacy mode. >> >> Hardware: Pandaboard A1 >> dtb: omap4-panda.dtb >> >> See 'dmesg' on below link: >> >> http://kernel.ubuntu.com/~ming/up/panda-dts.dmesg >> > Hmm looks like it boots to init. Maybe add initcall_debug to the cmdline > in > case there's some late_initcall that causes the issue. It's probably some > trivial issue causing it. Sricharan, maybe give this a quick try if you have the original pandaboard? I only have pandaboard es. Regards, Tony >>> >>> I tried your cleanup branch omap-for-v3.11/cleanup on panda board and it >>> booted >>> to prompt fine. >>> Hardware: Pandaboard A1 dtb: omap4-panda.dtb >>> >>> git pull on linux-next branch was not working though. >>> >> Ok, tested in linux-next as well and it booted fine with DTB. >> HW: OMAP4430ES2.1 PANDA A1 version DTB: OMAP4-PANDA.DTB >> >> Booted with ramdisk and mmc FS >> >> commit c04efed734409f5a44715b54a6ca1b54b0ccf215 >> Author: Stephen Rothwell >> Date: Fri Jun 7 16:40:02 2013 +1000 >> >> Add linux-next specific files for 20130607 > > Looks linux-next-20130607 is broken, see below: > > LD [M] drivers/usb/gadget/g_ncm.o > drivers/usb/musb/omap2430.c: In function 'omap2430_probe': > drivers/usb/musb/omap2430.c:571:2: error: 'musb_resources' undeclared > (first use in this function) > drivers/usb/musb/omap2430.c:571:2: note: each undeclared identifier is > reported only once for each function it appears in > drivers/usb/musb/omap2430.c:571:2: error: bit-field '' > width not an integer constant > drivers/usb/musb/omap2430.c:585:4: error: bit-field '' > width not an integer constant > make[3]: *** [drivers/usb/musb/omap2430.o] Error 1 > make[3]: *** Waiting for unfinished jobs > make[2]: *** [drivers/usb/musb] Error 2 > make[2]: *** Waiting for unfinished jobs > make[1]: *** [drivers/usb] Error 2 > make: *** [drivers] Error 2 > install kernel and modules > > DEPMOD 3.10.0-rc4-next-20130607+ Even I disable musb so that kernel building is OK, but the kernel with dtb still can't boot, see attachment 'dmesg' and config. Thanks, -- Ming Lei U-Boot SPL 2012.04 (Apr 24 2012 - 17:50:07) OMAP4430 ES2.1 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2012.04 (Apr 24 2012 - 17:50:07) CPU : OMAP4430 ES2.1 Board: OMAP4 Panda I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0 Using default environment In:serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 3 2 1 0 SD/MMC found on device 0 reading uEnv.txt 619 bytes read Loaded environment from uEnv.txt Importing environment from mmc ... reading uImage-omap 4239591 bytes read reading uInitrd-omap 8464252 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 8030 ... Image Name: omap4-panda-dtb-test Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4239527 Bytes = 4 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 8160 ... Image Name: initramfs Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size:8464188 Bytes = 8.1 MiB Load Address: Entry Point: Verifying Checksum ... OK Loading
Re: [PATCH 01/22] mfd/ti_am335x_tscadc: remove regmap
On Tue, Jun 11, 2013 at 04:34:53PM +0200, Sebastian Andrzej Siewior wrote: > >> Therefore this patch removes regmap part of the driver. > > NAK. Using regmap is better than open coding your register accesses, and > > the children not using this API is not a reason for the MFD driver to do > > the same. > There is no advantage over using regmap in the first place. It goes > through a few layers, uses no caching because almost all registers are > volatile and this is a direct bus. In the end it complicates more than > it helps. It does give you tracepoints and debugfs. If it's making things at all complicated we need to look at why that is and figure out how to fix that since it's probably an issue for other users. signature.asc Description: Digital signature
OMAP4 Panda DVI problem
Hi Tony, Roger, I recently raised the i2c issue with reading EDID from a DVI monitor on Panda, when booting with DT. I just couldn't get reading EDID work at all reliably. I now see problems with non-DT also. Booting with 3.10-rc5, with DSS compiled into the kernel, reading EDID fails during the boot. I can later read the EDID fine from userspace. With help from Roger, we found the issue. DVI cable has a +5V line, that the source (i.e. Panda) has to provide. This +5V is required to read EDID, but according to the documentation I think it's actually required to show video also (although I guess this could depend on the monitor). I think for OMAP3 boards the +5V is always-on (I haven't looked at OMAP3 boards yet, though). For Panda, the +5V comes from DC_HST_5V, controlled with a GPIO, which is used for USB and currently managed by USB in arch/arm/mach-omap2/usb-host.c, which creates a fixed voltage hsusbX_vcc regulator. So, basically, if USB is disabled, DVI doesn't work. This is why I see problems with DT (no USB), and non-DT (USB enabled after DVI is enabled). To fix this properly I need to add regulator handling to the DVI driver, and we need to share the same supply with USB and DVI. However, while the above shouldn't be particularly difficult, it's still not simple. And additional complications come with DT boot, as DSS doesn't support DT yet. We have the hack that enables DSS for Panda and SDP board when booting with DT, but I don't think it's possible to manage the shared regulator easily in that setup (ie. USB and the regulator being described in DT, DSS and DVI added the old way in dss-common.c). So I think the simplest solution is to make DC_HST_5V always-on. This should be fixed for 3.10 also. Any idea if DC_HST_5V is a big power sink if it's always enabled? If it's a big one, I could look at how to hack the DVI driver so that it would find the regulator. I'm quite sure I won't be neat, though. Tomi signature.asc Description: OpenPGP digital signature
[PATCH] USB: ehci-omap: Tweak PHY initialization sequence
For PHY mode, the PHYs must be brought out of reset
before the EHCI controller is started.
This patch fixes the issue where USB devices are not found
on Beagleboard/Beagle-xm if USB has been started previously
by the bootloader. (e.g. by "usb start" command in u-boot)
Tested on Beagleboard, Beagleboard-xm and Pandaboard.
Issue present on 3.10 onwards.
Reported-by: Tomi Valkeinen
Tested-by: Tomi Valkeinen
Signed-off-by: Roger Quadros
---
drivers/usb/host/ehci-omap.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 16d7150..dda408f 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -187,6 +187,12 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
}
omap->phy[i] = phy;
+
+ if (pdata->port_mode[i] == OMAP_EHCI_PORT_MODE_PHY) {
+ usb_phy_init(omap->phy[i]);
+ /* bring PHY out of suspend */
+ usb_phy_set_suspend(omap->phy[i], 0);
+ }
}
pm_runtime_enable(dev);
@@ -211,13 +217,14 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
}
/*
-* Bring PHYs out of reset.
+* Bring PHYs out of reset for non PHY modes.
* Even though HSIC mode is a PHY-less mode, the reset
* line exists between the chips and can be modelled
* as a PHY device for reset control.
*/
for (i = 0; i < omap->nports; i++) {
- if (!omap->phy[i])
+ if (!omap->phy[i] ||
+pdata->port_mode[i] == OMAP_EHCI_PORT_MODE_PHY)
continue;
usb_phy_init(omap->phy[i]);
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] ARM: OMAP2+: Remove board-omap4panda.c
On Thu, Jun 13, 2013 at 6:12 PM, Sricharan R wrote: > On Thursday 13 June 2013 02:51 PM, Sricharan R wrote: >> Hi Tony, >> On Wednesday 12 June 2013 10:44 PM, Tony Lindgren wrote: >>> * Tony Lindgren [130612 09:37]: * Ming Lei [130603 08:34]: > Hi, > > On Sat, May 18, 2013 at 3:17 AM, Tony Lindgren wrote: >> We can now boot with device tree. If you don't want to update u-boot, >> you can boot with appended DTB with the following instructions: >> >> 1. Make sure you have the appended DTB support in .config >> >>CONFIG_ARM_APPENDED_DTB=y >>CONFIG_ARM_ATAG_DTB_COMPAT=y >>CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y >> >> 2. Build the zImage >> >>$ ARCH=arm CROSS_COMPILE=... make zImage >> >> 3. Build the device tree blobs >> >>$ ARCH=arm CROSS_COMPILE=... make dtbs >> >> 4. Append the correct panda dtb to zImage >> >>Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb >>or omap4-panda-es.dtb. >> >>$ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb > >> /tmp/appended >> >> 5. Use mkimage to produce the appended device tree uImage >> >>$ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e >> 0x80008000 \ >> -n "Linux" -d /tmp/appended /tmp/uImage > I followed the above steps and tried devicetree on Pandaboard against > 3.10.0-rc3-next-20130528, and the board will hang during boot, but works > well with legacy mode. > > Hardware: Pandaboard A1 > dtb: omap4-panda.dtb > > See 'dmesg' on below link: > > http://kernel.ubuntu.com/~ming/up/panda-dts.dmesg > Hmm looks like it boots to init. Maybe add initcall_debug to the cmdline in case there's some late_initcall that causes the issue. It's probably some trivial issue causing it. >>> Sricharan, maybe give this a quick try if you have the original pandaboard? >>> I only have pandaboard es. >>> >>> Regards, >>> >>> Tony >> >> I tried your cleanup branch omap-for-v3.11/cleanup on panda board and it >> booted >> to prompt fine. >> Hardware: Pandaboard A1 dtb: omap4-panda.dtb >> >> git pull on linux-next branch was not working though. >> > Ok, tested in linux-next as well and it booted fine with DTB. > HW: OMAP4430ES2.1 PANDA A1 version DTB: OMAP4-PANDA.DTB > > Booted with ramdisk and mmc FS > > commit c04efed734409f5a44715b54a6ca1b54b0ccf215 > Author: Stephen Rothwell > Date: Fri Jun 7 16:40:02 2013 +1000 > > Add linux-next specific files for 20130607 Looks linux-next-20130607 is broken, see below: LD [M] drivers/usb/gadget/g_ncm.o drivers/usb/musb/omap2430.c: In function 'omap2430_probe': drivers/usb/musb/omap2430.c:571:2: error: 'musb_resources' undeclared (first use in this function) drivers/usb/musb/omap2430.c:571:2: note: each undeclared identifier is reported only once for each function it appears in drivers/usb/musb/omap2430.c:571:2: error: bit-field '' width not an integer constant drivers/usb/musb/omap2430.c:585:4: error: bit-field '' width not an integer constant make[3]: *** [drivers/usb/musb/omap2430.o] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [drivers/usb/musb] Error 2 make[2]: *** Waiting for unfinished jobs make[1]: *** [drivers/usb] Error 2 make: *** [drivers] Error 2 install kernel and modules DEPMOD 3.10.0-rc4-next-20130607+ Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Remove unused voltagedomain data for AM33xx
On 02:46-20130614, Paul Walmsley wrote: > cc Kevin, Vaibhav > > On Thu, 13 Jun 2013, Rajendra Nayak wrote: > > > The powerdomain framework today expects to always have a voltagedomain > > associated with a given powerdomain. We already have AM33xx which > > has no Voltage Controller/Voltage Processor as part of PRCM. > > There are more SoCs' to follow starting with AM437x and DRA7xx > > which do not have VC/VP. > > > > Instead of adding dummy voltage domain data files, make the powerdomain > > framework aware of the fact that some SoCs' might not really have > > scalable voltage domains. > > Fine with me in principle if AM335x doesn't support voltage scaling. > Vaibhav, if this is okay for you, please ack it. just a nitpick :) There is no VFSM auto scaling to retention voltage, nor is VC-VP IP available here, but that does not mean DVFS voltage scaling does not exist - it is done with traditional regulator framework using regular shared I2C. We now seem to be moving to a generation of SoCs where VC-VP has been dumped in favor of allowing integration with PMIC which may talk SPI/I2C over standard interfaces - this allows us to reach better product options, but gives up on extreme low power scenarios we had seen in the past on OMAP. Overall, I love this idea. Acked-by: Nishanth Menon > > Then, in terms of merging, probably Kevin would be the right person for > this since he's done much of the voltagedomain work. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] usb: dwc3: use extcon fwrk to receive connect/disconnect
Modified dwc3-omap to receive connect and disconnect notification using
extcon framework. Also did the necessary cleanups required after
adapting to extcon framework.
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Felipe Balbi
---
This patch depends on
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git commit:f7ae906
It should also be applied on top of
usb: dwc3: omap: improve error handling of dwc3_omap_probe patch which is
merged in Felipe's tree.
So I'm not sure on whose tree this patch should go in.
Changes from v3:
* did #include of of_extcon.h after Chanwoo resent the patch separating
extcon-class.c from of_extcon.c
Changes from v2:
* updated the Documentation with dwc3 dt binding information.
* used of_extcon_get_extcon_dev to get extcon device from device tree data.
Changes from v1:
* regulator enable/disable is now done here instead of palmas-usb as some users
of palmas-usb wont need regulator.
Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
drivers/usb/dwc3/dwc3-omap.c | 119
include/linux/usb/dwc3-omap.h | 30 -
3 files changed, 105 insertions(+), 49 deletions(-)
delete mode 100644 include/linux/usb/dwc3-omap.h
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index d4769f3..f1c15f3 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -53,6 +53,11 @@ OMAP DWC3 GLUE
It should be set to "1" for HW mode and "2" for SW mode.
- ranges: the child address space are mapped 1:1 onto the parent address space
+Optional Properties:
+ - extcon : phandle for the extcon device omap dwc3 uses to detect
+ connect/disconnect events.
+ - vbus-supply : phandle to the regulator device tree node if needed.
+
Sub-nodes:
The dwc3 core should be added as subnode to omap dwc3 glue.
- dwc3 :
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index f8f76e6..14c1f1b 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -43,13 +43,15 @@
#include
#include
#include
-#include
#include
#include
#include
#include
#include
#include
+#include
+#include
+#include
#include
@@ -124,9 +126,21 @@ struct dwc3_omap {
u32 utmi_otg_status;
u32 dma_status:1;
+
+ struct extcon_specific_cable_nb extcon_vbus_dev;
+ struct extcon_specific_cable_nb extcon_id_dev;
+ struct notifier_block vbus_nb;
+ struct notifier_block id_nb;
+
+ struct regulator*vbus_reg;
};
-static struct dwc3_omap*_omap;
+enum omap_dwc3_vbus_id_status {
+ OMAP_DWC3_ID_FLOAT,
+ OMAP_DWC3_ID_GROUND,
+ OMAP_DWC3_VBUS_OFF,
+ OMAP_DWC3_VBUS_VALID,
+};
static inline u32 dwc3_omap_readl(void __iomem *base, u32 offset)
{
@@ -138,18 +152,23 @@ static inline void dwc3_omap_writel(void __iomem *base,
u32 offset, u32 value)
writel(value, base + offset);
}
-int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
+static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
+ enum omap_dwc3_vbus_id_status status)
{
- u32 val;
- struct dwc3_omap*omap = _omap;
-
- if (!omap)
- return -EPROBE_DEFER;
+ int ret;
+ u32 val;
switch (status) {
case OMAP_DWC3_ID_GROUND:
dev_dbg(omap->dev, "ID GND\n");
+ if (omap->vbus_reg) {
+ ret = regulator_enable(omap->vbus_reg);
+ if (ret) {
+ dev_dbg(omap->dev, "regulator enable failed\n");
+ return;
+ }
+ }
val = dwc3_omap_readl(omap->base, USBOTGSS_UTMI_OTG_STATUS);
val &= ~(USBOTGSS_UTMI_OTG_STATUS_IDDIG
| USBOTGSS_UTMI_OTG_STATUS_VBUSVALID
@@ -172,6 +191,9 @@ int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
break;
case OMAP_DWC3_ID_FLOAT:
+ if (omap->vbus_reg)
+ regulator_disable(omap->vbus_reg);
+
case OMAP_DWC3_VBUS_OFF:
dev_dbg(omap->dev, "VBUS Disconnect\n");
@@ -185,12 +207,9 @@ int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
break;
default:
- dev_dbg(omap->dev, "ID float\n");
+ dev_dbg(omap->dev, "invalid state\n");
}
-
- return 0;
}
-EXPORT_SYMBOL_GPL(dwc3_omap_mailbox);
static irqreturn_t dwc3_omap_interrupt(int irq, void *_omap)
{
@@ -282,6 +301,32 @@ static void dwc3_omap_disable_irqs(struct dwc3_omap *omap)
static u64 dwc3_omap_dma_mask = DMA_BIT_MASK(32);
+static int dwc3_omap_id_notifier(struct notifier_block *nb,
+ unsigned long e
Re: OMAP v3.10-rc regressions that no one's fixed
Hi Paul,
On Monday 10 June 2013 12:52 PM, Paul Walmsley wrote:
Hi folks -- particularly TIers working on mainline,
There are several regressions that started with v3.10-rc that no one's
fixed for over a month. Some of them should be quite easy:
* 37xx EVM: boot fails
- as of v3.10-rc1
- Cause unknown
* 2420N800, 2430sdp: failed to get counter_32k resource
- "omap2_sync32k_clocksource_init: failed to get counter_32k resource"
- Cause unknown
* 2430SDP, 3730 Beagle XM, 3530 Beagle, 3517EVM, CM-T3517: {dmic,mcpdm} lookup
failure
- Cause unknown
- These IP blocks don't exist on OMAP3xxx/AM35xx chips
* 3730 Beagle XM, am335xbone, CM-T3517: uart4_rx.uart4_rx mux failure
- Cause unknown
I am able to reproduce this issue on 37xx EVM using non-dt boot (dt boot
doesn't throw this error). But this is not started with v3.10-rc, it has
been present on older kernels also( I verified on 3.9 kernel).
This is because that for all instances of uart, serial driver expects a
pad with default
mode which is not the case for uart4 in 37xx EVM.
Correct me if I am wrong.
Thanks and regards,
Lokesh
(For more details, see the logs at the link below.)
It would be good if people could step up to fix these before v3.10 comes
out.
- Paul
-- Forwarded message --
Date: Mon, 10 Jun 2013 02:00:50 + (UTC)
From: Paul Walmsley
To: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Subject: OMAP baseline test results for v3.10-rc5
Here are some basic OMAP test results for Linux v3.10-rc5.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.10-rc5/20130609031534/
Test summary
Build: uImage:
Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a,
omap1_defconfig, omap1_defconfig_1510innovator_only,
omap1_defconfig_5912osk_only, omap2plus_defconfig,
omap2plus_defconfig_2430sdp_only
omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
rmk_omap3430_ldp_allnoconfig,
rmk_omap3430_ldp_oldconfig,
rmk_omap4430_sdp_allnoconfig,
rmk_omap4430_sdp_oldconfig
Build: zImage:
Pass ( 1/ 1): omap2plus_defconfig
Boot to userspace:
FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt
Pass ( 9/12): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 4430es2panda, 4460pandaes, 5912osk,
cmt3517
PM: chip retention via suspend:
FAIL ( 3/ 6): 2430sdp, 37xxevm, 4430es2panda
Pass ( 3/ 6): 3530es3beagle, 3730beaglexm, 4460pandaes
PM: chip retention via dynamic idle:
FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
PM: chip off except CORE via suspend:
Pass ( 1/ 1): 3730beaglexm
PM: chip off except CORE via dynamic idle:
Pass ( 1/ 1): 3730beaglexm
PM: chip off via suspend:
FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 1/ 4): 3530es3beagle
PM: chip off via dynamic idle:
FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 1/ 4): 3530es3beagle
Failing tests: fixed by posted patches
--
(none)
Failing tests: needing investigation
Boot tests:
* 3517EVM & CM-T3517: boot hangs with NFS root
- Likely some Kconfig, board file, and PM issues with EMAC
- Longstanding bug
- Not currently part of the automated test suite
* 37xx EVM: boot fails
- as of v3.10-rc1
- Cause unknown
Boot warnings:
* 2420N800, 2430sdp: failed to get counter_32k resource
- "omap2_sync32k_clocksource_init: failed to get counter_32k resource"
- Cause unknown
* CM-T3517: L3 in-band error with IPSS during boot
- Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2
- Longstanding issue; does not occur on the 3517EVM
* 2430SDP, 3730 Beagle XM, 3530 Beagle, 3517EVM, CM-T3517: {dmic,mcpdm} lookup
failure
- Cause unknown
- These IP blocks don't exist on OMAP3xxx/AM35xx chips
* 3730 Beagle XM, am335xbone, CM-T3517: uart4_rx.uart4_rx mux failure
- Cause unknown
PM tests:
* 2430sdp: power domains not entering retention
- Cause unknown
* 3730 Beagle XM: does not serial wake from off-idle suspend when console
UART doesn't clock-gate ("debug ignore_loglevel")
- Cause unknown
- Not yet part of the automated test suite
- Re-tested at v3.7; still failing:
http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt
* 4430es2panda: pwrdm state mismatch on CAM, DSS
* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
- Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
per discussion with Tero Kristo
- Likely dependent on the bootloader version
Re: [PATCH 2/4] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode
On 7 June 2013 23:49, Tony Lindgren wrote:
> From: Andreas Fenkart
>
> Without functional clock the omap_hsmmc module can't forward SDIO IRQs to
> the system. This patch reconfigures dat1 line as a gpio while the fclk is
> off. When the fclk is present it uses the standard SDIO IRQ detection of
> the module.
>
> The gpio irq is managed via the 'disable_depth' ref counter of the irq
> subsystem, this driver simply calls enable_irq/disable_irq when needed.
>
> sdio irqsdio irq
> unmasked masked
>-
> runtime default |1 | 2
> runtime suspend |0 | 1
>
> irq disable depth
>
>
> only when sdio irq is enabled AND the module is idle, the reference
> count drops to zero and the gpio irq is effectively armed.
>
> Patch was tested on AM335x/Stream800. Test setup was two modules
> with sdio wifi cards. Modules where connected to a dual-band AP, each
> module using a different band. One of module was running iperf as server
> the other as client connecting to the server in a while true loop. Test
> was running for 4+ weeks. There were about 60 Mio. suspend/resume
> transitions. Test was shut down regularly.
>
> Cc: Andreas Fenkart
> Cc: Balaji T K
> Signed-off-by: Andreas Fenkart
> Reviewed-by: Grant Likely
> [t...@atomide.com: updated and separated out pin muxing]
> Signed-off-by: Tony Lindgren
> ---
> .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 42
> drivers/mmc/host/omap_hsmmc.c | 206
> +++-
> include/linux/platform_data/mmc-omap.h |4
> 3 files changed, 239 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> index ed271fc..5a3df37 100644
> --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> @@ -20,6 +20,29 @@ ti,dual-volt: boolean, supports dual voltage cards
> ti,non-removable: non-removable slot (like eMMC)
> ti,needs-special-reset: Requires a special softreset sequence
> ti,needs-special-hs-handling: HSMMC IP needs special setting for handling
> High Speed
> +ti,cirq-gpio: When omap_hsmmc module is suspended, its functional
> +clock is turned off. Without fclk it can't forward SDIO IRQs to the
> +system. For that to happen, it needs to tell the PRCM to restore
> +its fclk, which is done through the swakeup line.
> +
> + --
> + | PRCM |
> + --
> +| ^
> + fclk | | swakeup
> +v |
> + --- --
> + <-- IRQ -- | hsmmc | <-- CIRQ -- | card |
> + --- --
> +
> +The problem is, that on the AM335x family the swakeup line is
> +missing, it has not been routed from the module to the PRCM.
> +The way to work around this, is to reconfigure the dat1 line as a
> +GPIO upon suspend. Beyond this option you also need to set named
> +states "default" and "idle "in the .dts file for the pins, using
> +pinctrl-single.c. The MMC driver will then then toggle between
> +default and idle during the runtime.
> +
>
> Example:
> mmc1: mmc@0x4809c000 {
> @@ -31,3 +54,22 @@ Example:
> vmmc-supply = <&vmmc>; /* phandle to regulator node */
> ti,non-removable;
> };
> +
> +[am335x with with gpio for sdio irq]
> +
> + mmc1_cirq_pin: pinmux_cirq_pin {
> + pinctrl-single,pins = <
> + 0x0f8 0x3f /* MMC0_DAT1 as GPIO2_28 */
> + >;
> + };
> +
> + mmc1: mmc@4806 {
> + pinctrl-names = "default", "idle";
> + pinctrl-0 = <&mmc1_pins>;
> + pinctrl-1 = <&mmc1_cirq_pin>;
> + ti,cirq-gpio = <&gpio3 28 0>;
> + ti,non-removable;
> + bus-width = <4>;
> + vmmc-supply = <&ldo2_reg>;
> + vmmc_aux-supply = <&vmmc>;
> + };
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 478849b..7e28501 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -102,6 +103,7 @@
> #define TC_EN (1 << 1)
> #define BWR_EN (1 << 4)
> #define BRR_EN (1 << 5)
> +#define CIRQ_EN(1 << 8)
> #define ERR_EN (1 << 15)
> #define CTO_EN (1 << 16)
> #define CCRC_EN(1 << 17)
> @@ -182,9 +184,19 @@ struct omap_hsmmc_host {
> int use_reg;
> int req_in_progress;
> struct omap_hsmmc_next next_
Re: [PATCH] mfd: Palmas: Introduce features to select the appropriate modules present in the palmas variant
On Fri, Jun 14, 2013 at 10:22:04AM +, J, KEERTHY wrote:
> Graeme/Laxman,
>
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Laxman Dewangan
> > Sent: Friday, June 14, 2013 3:32 PM
> > To: Graeme Gregory
> > Cc: J, KEERTHY; linux-omap@vger.kernel.org;
> > broo...@opensource.wolfsonmicro.com; sa...@linux.intel.com
> > Subject: Re: [PATCH] mfd: Palmas: Introduce features to select the
> > appropriate modules present in the palmas variant
> >
> > On Friday 14 June 2013 03:25 PM, Graeme Gregory wrote:
> > > On Fri, Jun 14, 2013 at 02:51:58PM +0530, J Keerthy wrote:
> > >> -children[PALMAS_PMIC_ID].platform_data = pdata->pmic_pdata;
> > >> -children[PALMAS_PMIC_ID].pdata_size =
> > >> sizeof(*pdata->pmic_pdata);
> > >> +if (PALMAS_PMIC_HAS(palmas, REGULATORS)) {
> > >> +children[PALMAS_PMIC_ID].platform_data =
> > >> pdata->pmic_pdata;
> > >> +children[PALMAS_PMIC_ID].pdata_size =
> > >> +sizeof(*pdata->pmic_pdata);
> > >> +}
> > >>
> > > I think a lot of complexity here could actually be removed by
> > removing
> > > the old board file style probing for palmas. I do not beleive either
> > > major user of palmas requires that anymore? I always had in my mind
> > > that this bit was temporary.
> >
> > Completely agree, we should not have this. Also this is not valid much
> > in DT context and so we can remove it.
>
> So shall I completely knock off the pdata assignments?
>
> BTW having features flag would still be handy for PMICs which might
> Not have all the features as TWL6035/Palmas. So I still want to retain
> That. Is it Okay?
>
Everything from the line
children = kmemdup(palmas_children, sizeof(palmas_children), GFP_KERNEL)
until error handling can go. As well as the palmas_children/palmas_ids
array at the top.
The features variable is I think superceded by DT, a feature not in chip
should not be in the DT. But if you have other technical reasons to keep
it I have no real strong opinion.
Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mfd: Palmas: Introduce features to select the appropriate modules present in the palmas variant
Graeme/Laxman,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Laxman Dewangan
> Sent: Friday, June 14, 2013 3:32 PM
> To: Graeme Gregory
> Cc: J, KEERTHY; linux-omap@vger.kernel.org;
> broo...@opensource.wolfsonmicro.com; sa...@linux.intel.com
> Subject: Re: [PATCH] mfd: Palmas: Introduce features to select the
> appropriate modules present in the palmas variant
>
> On Friday 14 June 2013 03:25 PM, Graeme Gregory wrote:
> > On Fri, Jun 14, 2013 at 02:51:58PM +0530, J Keerthy wrote:
> >> - children[PALMAS_PMIC_ID].platform_data = pdata->pmic_pdata;
> >> - children[PALMAS_PMIC_ID].pdata_size = sizeof(*pdata->pmic_pdata);
> >> + if (PALMAS_PMIC_HAS(palmas, REGULATORS)) {
> >> + children[PALMAS_PMIC_ID].platform_data = pdata->pmic_pdata;
> >> + children[PALMAS_PMIC_ID].pdata_size =
> >> + sizeof(*pdata->pmic_pdata);
> >> + }
> >>
> > I think a lot of complexity here could actually be removed by
> removing
> > the old board file style probing for palmas. I do not beleive either
> > major user of palmas requires that anymore? I always had in my mind
> > that this bit was temporary.
>
> Completely agree, we should not have this. Also this is not valid much
> in DT context and so we can remove it.
So shall I completely knock off the pdata assignments?
BTW having features flag would still be handy for PMICs which might
Not have all the features as TWL6035/Palmas. So I still want to retain
That. Is it Okay?
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap"
> in the body of a message to majord...@vger.kernel.org More majordomo
> info at http://vger.kernel.org/majordomo-info.html
Regards,
Keerthy
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: Palmas: Introduce features to select the appropriate modules present in the palmas variant
On Friday 14 June 2013 03:25 PM, Graeme Gregory wrote:
On Fri, Jun 14, 2013 at 02:51:58PM +0530, J Keerthy wrote:
- children[PALMAS_PMIC_ID].platform_data = pdata->pmic_pdata;
- children[PALMAS_PMIC_ID].pdata_size = sizeof(*pdata->pmic_pdata);
+ if (PALMAS_PMIC_HAS(palmas, REGULATORS)) {
+ children[PALMAS_PMIC_ID].platform_data = pdata->pmic_pdata;
+ children[PALMAS_PMIC_ID].pdata_size =
+ sizeof(*pdata->pmic_pdata);
+ }
I think a lot of complexity here could actually be removed by removing the
old board file style probing for palmas. I do not beleive either major user
of palmas requires that anymore? I always had in my mind that this bit
was temporary.
Completely agree, we should not have this. Also this is not valid much
in DT context and so we can remove it.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: Palmas: Introduce features to select the appropriate modules present in the palmas variant
On Fri, Jun 14, 2013 at 02:51:58PM +0530, J Keerthy wrote:
> Introduce features to select the appropriate sub-modules present in the palmas
> variants. This adds the major features present in palmas family of PMICs.
>
> Boot tested on OMAP5 uevm board.
> Signed-off-by: J Keerthy
> ---
> drivers/mfd/palmas.c | 83
> ++--
> include/linux/mfd/palmas.h | 55 +
> 2 files changed, 119 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
> index 53e9fe6..0ca5854 100644
> --- a/drivers/mfd/palmas.c
> +++ b/drivers/mfd/palmas.c
> @@ -302,6 +302,27 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
> palmas_set_pdata_irq_flag(i2c, pdata);
> }
>
> +static unsigned int palmas_features = PALMAS_PMIC_FEATURE_WATCHDOG |
> + PALMAS_PMIC_FEATURE_REGULATORS |
> + PALMAS_PMIC_FEATURE_BACKUP_BATTERY |
> + PALMAS_PMIC_FEATURE_32K_CLK |
> + PALMAS_PMIC_FEATURE_RTC |
> + PALMAS_PMIC_FEATURE_GPADC |
> + PALMAS_PMIC_FEATURE_USB_OTG |
> + PALMAS_PMIC_FEATURE_CHARGER_DETECT |
> + PALMAS_PMIC_FEATURE_GPIO |
> + PALMAS_PMIC_FEATURE_PWM_LED |
> + PALMAS_PMIC_FEATURE_INTERRUPT |
> + PALMAS_PMIC_FEATURE_SMPS10_BOOST;
> +
> +static const struct of_device_id of_palmas_match_tbl[] = {
> + {
> + .compatible = "ti,palmas",
> + .data = &palmas_features,
> + },
> + { },
> +};
> +
> static int palmas_i2c_probe(struct i2c_client *i2c,
> const struct i2c_device_id *id)
> {
> @@ -309,9 +330,10 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
> struct palmas_platform_data *pdata;
> struct device_node *node = i2c->dev.of_node;
> int ret = 0, i;
> - unsigned int reg, addr;
> + unsigned int reg, addr, *features;
> int slave;
> struct mfd_cell *children;
> + const struct of_device_id *match;
>
> pdata = dev_get_platdata(&i2c->dev);
>
> @@ -333,9 +355,17 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
>
> i2c_set_clientdata(i2c, palmas);
> palmas->dev = &i2c->dev;
> - palmas->id = id->driver_data;
> palmas->irq = i2c->irq;
>
> + match = of_match_device(of_match_ptr(of_palmas_match_tbl), &i2c->dev);
> +
> + if (match) {
> + features = (unsigned int *)match->data;
> + palmas->features = *features;
> + } else {
> + return -ENODATA;
> + }
> +
> for (i = 0; i < PALMAS_NUM_CLIENTS; i++) {
> if (i == 0)
> palmas->i2c_clients[i] = i2c;
> @@ -362,6 +392,9 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
> }
> }
>
> + if (!PALMAS_PMIC_HAS(palmas, INTERRUPT))
> + goto no_int;
> +
> /* Change interrupt line output polarity */
> if (pdata->irq_flags & IRQ_TYPE_LEVEL_HIGH)
> reg = PALMAS_POLARITY_CTRL_INT_POLARITY;
> @@ -388,6 +421,10 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
> if (ret < 0)
> goto err;
>
> +no_int:
> + if (!PALMAS_PMIC_HAS(palmas, GPIO))
> + goto no_gpio;
> +
> slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
> addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
> PALMAS_PRIMARY_SECONDARY_PAD1);
> @@ -459,7 +496,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
> ret = regmap_write(palmas->regmap[slave], addr, reg);
> if (ret)
> goto err_irq;
> -
> +no_gpio:
> /*
>* If we are probing with DT do this the DT way and return here
>* otherwise continue and add devices using mfd helpers.
> @@ -479,21 +516,34 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
> goto err_irq;
> }
>
> - children[PALMAS_PMIC_ID].platform_data = pdata->pmic_pdata;
> - children[PALMAS_PMIC_ID].pdata_size = sizeof(*pdata->pmic_pdata);
> + if (PALMAS_PMIC_HAS(palmas, REGULATORS)) {
> + children[PALMAS_PMIC_ID].platform_data = pdata->pmic_pdata;
> + children[PALMAS_PMIC_ID].pdata_size =
> + sizeof(*pdata->pmic_pdata);
> + }
>
I think a lot of complexity here could actually be removed by removing the
old board file style probing for palmas. I do not beleive either major user
of palmas requires that anymore? I always had in my mind that this bit
was temporary.
> - children[PALMAS_GPADC_ID].platform_data = pdata->gpadc_pdata;
> - children[PALMAS_GPADC_ID].pdata_size = sizeof(*pdata->gpadc_pdata);
> +
[PATCH v3 2/2] USB: ehci-omap: select NOP_USB_XCEIV PHY driver
ehci-omap needs NOP_USB_XCEIV PHY driver to function properly, so select it. As the USB PHY drivers no longer depend on USB_PHY, it is safe to select the PHY drivers. Signed-off-by: Roger Quadros Tested-by: Adrien Vergé --- drivers/usb/host/Kconfig |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 7ded784..48e1b70 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -150,13 +150,11 @@ config USB_EHCI_MXC config USB_EHCI_HCD_OMAP tristate "EHCI support for OMAP3 and later chips" depends on ARCH_OMAP + select NOP_USB_XCEIV default y ---help--- Enables support for the on-chip EHCI controller on OMAP3 and later chips. - If your system uses a PHY on the USB port, you will need to - enable USB_PHY and the appropriate PHY driver as well. Most - boards need the NOP_USB_XCEIV PHY driver. config USB_EHCI_HCD_ORION tristate "Support for Marvell EBU on-chip EHCI USB controller" -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/2] USB: PHY: Improve PHY selection logic
Hi, Improve Kconfig so that the relevant PHY driver can be explicitely selected by the controller driver instead of relying on the user to do so. Detailed description in patch 1. v3: - Fix linking problem when CONFIG_USB is m v2: - Merge patches 3-5 into the first patch to prevent circular dependency between the Kconfig options during bisection. cheers, -roger Roger Quadros (2): USB: PHY: Make PHY driver selection possible by controller drivers USB: ehci-omap: select NOP_USB_XCEIV PHY driver drivers/usb/Makefile |2 +- drivers/usb/gadget/Kconfig |2 -- drivers/usb/host/Kconfig |5 + drivers/usb/phy/Kconfig| 31 +-- 4 files changed, 23 insertions(+), 17 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] USB: PHY: Make PHY driver selection possible by controller drivers
Convert PHY Drivers from menuconfig to menu so that the PHY drivers can be explicitely selected by the controller drivers. USB_PHY is no longer a user visible option. It is upto to the PHY drivers to select it if needed. This patch does so for the existing PHY drivers that use the USB_PHY library. Doing so moves the USB_PHY and PHY driver selection problem from the end user to the PHY and controller driver developer. e.g. Earlier, a controller driver (e.g. EHCI_OMAP) that needs to select a PHY driver (e.g. NOP_PHY) couldn't do so because the PHY driver depended on USB_PHY. Making the controller driver depend on USB_PHY has a negative effect i.e. it becomes invisible to the user till USB_PHY is enabled. Most end users will not familiar with this. With this patch, the end user just needs to select the controller driver needed for his/her platform without worrying about which PHY driver to select. Also update USB_EHCI_MSM, USB_LPC32XX and USB_OMAP to not depend on USB_PHY any more. They can safely select the necessary PHY drivers. CC: Pavankumar Kondeti CC: Roland Stigge Signed-off-by: Roger Quadros [USB_LPC32XX part] Acked-by: Roland Stigge Signed-off-by: Roger Quadros --- drivers/usb/Makefile |2 +- drivers/usb/gadget/Kconfig |2 -- drivers/usb/host/Kconfig |1 - drivers/usb/phy/Kconfig| 31 +-- 4 files changed, 22 insertions(+), 14 deletions(-) diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index c41feba..b9bb845 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -44,7 +44,7 @@ obj-$(CONFIG_USB_MICROTEK)+= image/ obj-$(CONFIG_USB_SERIAL) += serial/ obj-$(CONFIG_USB) += misc/ -obj-$(CONFIG_USB_PHY) += phy/ +obj-$(CONFIG_USB_SUPPORT) += phy/ obj-$(CONFIG_EARLY_PRINTK_DBGP)+= early/ obj-$(CONFIG_USB_ATM) += atm/ diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index f41aa0d..86d5d80 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -144,7 +144,6 @@ config USB_AT91 config USB_LPC32XX tristate "LPC32XX USB Peripheral Controller" depends on ARCH_LPC32XX - depends on USB_PHY select USB_ISP1301 help This option selects the USB device controller in the LPC32xx SoC. @@ -195,7 +194,6 @@ config USB_FUSB300 config USB_OMAP tristate "OMAP USB Device Controller" depends on ARCH_OMAP1 - depends on USB_PHY select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 || MACH_OMAP_H4_OTG help Many Texas Instruments OMAP processors have flexible full diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 344d5e2..7ded784 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -188,7 +188,6 @@ config USB_EHCI_HCD_AT91 config USB_EHCI_MSM tristate "Support for Qualcomm QSD/MSM on-chip EHCI USB controller" depends on ARCH_MSM - depends on USB_PHY select USB_EHCI_ROOT_HUB_TT select USB_MSM_OTG ---help--- diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 7ef3eb8..b57f7f0 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -1,16 +1,11 @@ # # Physical Layer USB driver configuration # -menuconfig USB_PHY - bool "USB Physical Layer drivers" - help - USB controllers (those which are host, device or DRD) need a - device to handle the physical layer signalling, commonly called - a PHY. - - The following drivers add support for such PHY devices. +menu "USB Physical Layer drivers" -if USB_PHY +config USB_PHY + bool + default n # # USB Transceiver Drivers @@ -18,6 +13,7 @@ if USB_PHY config AB8500_USB tristate "AB8500 USB Transceiver Driver" depends on AB8500_CORE + select USB_PHY help Enable this to support the USB OTG transceiver in AB8500 chip. This transceiver supports high and full speed devices plus, @@ -27,12 +23,14 @@ config FSL_USB2_OTG bool "Freescale USB OTG Transceiver Driver" depends on USB_EHCI_FSL && USB_FSL_USB2 && PM_RUNTIME select USB_OTG + select USB_PHY help Enable this to support Freescale USB OTG transceiver. config ISP1301_OMAP tristate "Philips ISP1301 with OMAP OTG" depends on I2C && ARCH_OMAP_OTG + select USB_PHY help If you say yes here you get support for the Philips ISP1301 USB-On-The-Go transceiver working with the OMAP OTG controller. @@ -46,12 +44,14 @@ config ISP1301_OMAP config MV_U3D_PHY bool "Marvell USB 3.0 PHY controller Driver" depends on CPU_MMP3 + select USB_PHY help Enable this to support Marvell USB 3.0 phy controller for Marvell SoC. config NOP_USB_XCEIV tristate "NOP USB Transceiver Driver" + select USB_PHY he
[PATCH] mfd: Palmas: Introduce features to select the appropriate modules present in the palmas variant
Introduce features to select the appropriate sub-modules present in the palmas
variants. This adds the major features present in palmas family of PMICs.
Boot tested on OMAP5 uevm board.
Signed-off-by: J Keerthy
---
drivers/mfd/palmas.c | 83 ++--
include/linux/mfd/palmas.h | 55 +
2 files changed, 119 insertions(+), 19 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 53e9fe6..0ca5854 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -302,6 +302,27 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
palmas_set_pdata_irq_flag(i2c, pdata);
}
+static unsigned int palmas_features = PALMAS_PMIC_FEATURE_WATCHDOG |
+ PALMAS_PMIC_FEATURE_REGULATORS |
+ PALMAS_PMIC_FEATURE_BACKUP_BATTERY |
+ PALMAS_PMIC_FEATURE_32K_CLK |
+ PALMAS_PMIC_FEATURE_RTC |
+ PALMAS_PMIC_FEATURE_GPADC |
+ PALMAS_PMIC_FEATURE_USB_OTG |
+ PALMAS_PMIC_FEATURE_CHARGER_DETECT |
+ PALMAS_PMIC_FEATURE_GPIO |
+ PALMAS_PMIC_FEATURE_PWM_LED |
+ PALMAS_PMIC_FEATURE_INTERRUPT |
+ PALMAS_PMIC_FEATURE_SMPS10_BOOST;
+
+static const struct of_device_id of_palmas_match_tbl[] = {
+ {
+ .compatible = "ti,palmas",
+ .data = &palmas_features,
+ },
+ { },
+};
+
static int palmas_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
@@ -309,9 +330,10 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
struct palmas_platform_data *pdata;
struct device_node *node = i2c->dev.of_node;
int ret = 0, i;
- unsigned int reg, addr;
+ unsigned int reg, addr, *features;
int slave;
struct mfd_cell *children;
+ const struct of_device_id *match;
pdata = dev_get_platdata(&i2c->dev);
@@ -333,9 +355,17 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
i2c_set_clientdata(i2c, palmas);
palmas->dev = &i2c->dev;
- palmas->id = id->driver_data;
palmas->irq = i2c->irq;
+ match = of_match_device(of_match_ptr(of_palmas_match_tbl), &i2c->dev);
+
+ if (match) {
+ features = (unsigned int *)match->data;
+ palmas->features = *features;
+ } else {
+ return -ENODATA;
+ }
+
for (i = 0; i < PALMAS_NUM_CLIENTS; i++) {
if (i == 0)
palmas->i2c_clients[i] = i2c;
@@ -362,6 +392,9 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
}
}
+ if (!PALMAS_PMIC_HAS(palmas, INTERRUPT))
+ goto no_int;
+
/* Change interrupt line output polarity */
if (pdata->irq_flags & IRQ_TYPE_LEVEL_HIGH)
reg = PALMAS_POLARITY_CTRL_INT_POLARITY;
@@ -388,6 +421,10 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
if (ret < 0)
goto err;
+no_int:
+ if (!PALMAS_PMIC_HAS(palmas, GPIO))
+ goto no_gpio;
+
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
PALMAS_PRIMARY_SECONDARY_PAD1);
@@ -459,7 +496,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
ret = regmap_write(palmas->regmap[slave], addr, reg);
if (ret)
goto err_irq;
-
+no_gpio:
/*
* If we are probing with DT do this the DT way and return here
* otherwise continue and add devices using mfd helpers.
@@ -479,21 +516,34 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
goto err_irq;
}
- children[PALMAS_PMIC_ID].platform_data = pdata->pmic_pdata;
- children[PALMAS_PMIC_ID].pdata_size = sizeof(*pdata->pmic_pdata);
+ if (PALMAS_PMIC_HAS(palmas, REGULATORS)) {
+ children[PALMAS_PMIC_ID].platform_data = pdata->pmic_pdata;
+ children[PALMAS_PMIC_ID].pdata_size =
+ sizeof(*pdata->pmic_pdata);
+ }
- children[PALMAS_GPADC_ID].platform_data = pdata->gpadc_pdata;
- children[PALMAS_GPADC_ID].pdata_size = sizeof(*pdata->gpadc_pdata);
+ if (PALMAS_PMIC_HAS(palmas, GPADC)) {
+ children[PALMAS_GPADC_ID].platform_data = pdata->gpadc_pdata;
+ children[PALMAS_GPADC_ID].pdata_size =
+ sizeof(*pdata->gpadc_pdata);
+ }
- children[PALMAS_RESOURCE_ID].platform_data = pdata->resource_pdata;
- children[PALMAS_RESOURCE_ID].pdata_size =
-
Re: [RFC PATCH 1/4] arm: omap: Add phy binding info for musb in plat data
Hi, On Friday 14 June 2013 01:47 PM, Tomi Valkeinen wrote: On 14/06/13 10:33, Tony Lindgren wrote: If we want to fix something this late in the merge window, the patches must have a clear description what caused the regression and what happens without the patches. These patches don't have that. And they are marked RFC also. So actually I'm not applying any of them before the regression descriptions are there and the patches have been reposted without RFC and have sufficient acks from people. I posted this as RFC since this series uses _label_ and initially Felipe din't want to find PHYs by _label_. After the device names are created using PLATFORM_DEVID_AUTO, our original method of binding by device names doesn't work reliable (since the device name changes). And I couldn't think of any other way to find the PHY other than using _label_. So I just wanted to know if it's ok to use _label_ or if there is any other better way to find PHYs. No disagreement there. Kishon, I tested the patches on top of v3.10-rc5, booting with nfs root via usb gadget eth: Overo: works Beagle: works, but I need to reconnect the usb cable after kernel is up Beagle-xm: doesn't work. The cable is detected correctly, though Panda: works The problems with Beagles are there even without these patches, so they do make things better (fix Overo). Thanks for testing this. I'll post a new version removing RFC after Felipe ACKs it. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP5: Fix omap5 standalone build break
Building omap5 standalone results in the below errors.. arch/arm/mach-omap2/built-in.o: In function `scu_gp_set': arch/arm/mach-omap2/sleep44xx.S:132: undefined reference to `scu_power_mode' arch/arm/mach-omap2/built-in.o: In function `scu_gp_clear': arch/arm/mach-omap2/sleep44xx.S:229: undefined reference to `scu_power_mode' arch/arm/mach-omap2/built-in.o: In function `omap4_smp_prepare_cpus': arch/arm/mach-omap2/omap-smp.c:211: undefined reference to `scu_enable' arch/arm/mach-omap2/built-in.o: In function `omap4_smp_init_cpus': arch/arm/mach-omap2/omap-smp.c:185: undefined reference to `scu_get_core_count' Fix this by adding the missing select for HAVE_ARM_SCU for SOC_OMAP5 Reported-by: Pekon Gupta Signed-off-by: Rajendra Nayak --- arch/arm/mach-omap2/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f49cd51..81690a2 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -109,6 +109,7 @@ config SOC_OMAP5 select ARM_CPU_SUSPEND if PM select ARM_GIC select CPU_V7 + select HAVE_ARM_SCU if SMP select HAVE_SMP select COMMON_CLK select HAVE_ARM_ARCH_TIMER -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] extcon: Add an API to get extcon device from dt node
On 06/14/2013 05:36 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Friday 14 June 2013 12:45 PM, Chanwoo Choi wrote:
>> From: Kishon Vijay Abraham I
>>
>> Added an API of_extcon_get_extcon_dev() to be used by drivers to get
>> extcon device in the case of dt boot (this can be used instead of
>> extcon_get_extcon_dev()).
>>
>> Signed-off-by: Kishon Vijay Abraham I
>> Signed-off-by: Chanwoo Choi
>> Signed-off-by: Myungjoo Ham
>> ---
>> Changes since v1:
>> - If edev->name is NULL, dev_name(dev) is used as edev->name.
>> - Change filename from of-extcon.* to of_extcon.*
>> - Fix build error when CONFIG_OF is not set
>> - Add header file(linux/err.h) to of_extcon.c
>>
>> drivers/extcon/Makefile | 2 ++
>> drivers/extcon/extcon-class.c| 3 +-
>> drivers/extcon/of_extcon.c | 64
>>
>> include/linux/extcon/of_extcon.h | 30 +++
>> 4 files changed, 98 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/extcon/of_extcon.c
>> create mode 100644 include/linux/extcon/of_extcon.h
>>
>> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
>> index 540e2c3..83468f7 100644
>> --- a/drivers/extcon/Makefile
>> +++ b/drivers/extcon/Makefile
>> @@ -2,6 +2,8 @@
>> # Makefile for external connector class (extcon) devices
>> #
>>
>> +obj-$(CONFIG_OF)+= of_extcon.o
>> +
>> obj-$(CONFIG_EXTCON)+= extcon-class.o
>> obj-$(CONFIG_EXTCON_GPIO)+= extcon-gpio.o
>> obj-$(CONFIG_EXTCON_ADC_JACK)+= extcon-adc-jack.o
>> diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
>> index 23f11ea..08509ea 100644
>> --- a/drivers/extcon/extcon-class.c
>> +++ b/drivers/extcon/extcon-class.c
>> @@ -602,7 +602,8 @@ int extcon_dev_register(struct extcon_dev *edev, struct
>> device *dev)
>> edev->dev->class = extcon_class;
>> edev->dev->release = extcon_dev_release;
>>
>> -dev_set_name(edev->dev, edev->name ? edev->name : dev_name(dev));
>> +edev->name = edev->name ? edev->name : dev_name(dev);
>> +dev_set_name(edev->dev, edev->name);
>>
>> if (edev->max_supported) {
>> char buf[10];
>> diff --git a/drivers/extcon/of_extcon.c b/drivers/extcon/of_extcon.c
>> new file mode 100644
>> index 000..72173ec
>> --- /dev/null
>> +++ b/drivers/extcon/of_extcon.c
>> @@ -0,0 +1,64 @@
>> +/*
>> + * OF helpers for External connector (extcon) framework
>> + *
>> + * Copyright (C) 2013 Texas Instruments, Inc.
>> + * Kishon Vijay Abraham I
>> + *
>> + * Copyright (C) 2013 Samsung Electronics
>> + * Chanwoo Choi
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +/*
>> + * of_extcon_get_extcon_dev - Get the name of extcon device from devicetree
>> + * @dev - instance to the given device
>> + * @index - index into list of extcon_dev
>> + *
>> + * return the instance of extcon device
>> + */
>> +struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev, int index)
>> +{
>> +struct device_node *node;
>> +struct extcon_dev *edev;
>> +struct platform_device *extcon_parent_dev;
>> +
>> +if (!dev->of_node) {
>> +dev_dbg(dev, "device does not have a device node entry\n");
>> +return ERR_PTR(-EINVAL);
>> +}
>> +
>> +node = of_parse_phandle(dev->of_node, "extcon", index);
>> +if (!node) {
>> +dev_dbg(dev, "failed to get phandle in %s node\n",
>> +dev->of_node->full_name);
>> +return ERR_PTR(-ENODEV);
>> +}
>> +
>> +extcon_parent_dev = of_find_device_by_node(node);
>> +if (!extcon_parent_dev) {
>> +dev_dbg(dev, "unable to find device by node\n");
>> +return ERR_PTR(-EPROBE_DEFER);
>> +}
>> +
>> +edev = extcon_get_extcon_dev(dev_name(&extcon_parent_dev->dev));
>> +if (!edev) {
>> +dev_dbg(dev, "unable to get extcon device : %s\n",
>> +dev_name(&extcon_parent_dev->dev));
>> +return ERR_PTR(-ENODEV);
>> +}
>> +
>> +return edev;
>> +}
>> +EXPORT_SYMBOL_GPL(of_extcon_get_extcon_dev);
>> diff --git a/include/linux/extcon/of_extcon.h
>> b/include/linux/extcon/of_extcon.h
>> new file mode 100644
>> index 000..462f071
>> --- /dev/null
>> +++ b/include/linux/extcon/of_extcon.h
>> @@ -0,0 +1,30 @@
>> +/*
>> + * OF helpers for External connector (extcon) framework
>> + *
>> + * Copyright (C) 2013 Texas Instruments, Inc.
>> + * Kishon Vijay Abraham I
>> + *
>> + * Copyright (C) 2013 Samsung Electronics
>> + * Chanwoo Choi
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the
Re: [PATCH v2] extcon: Add an API to get extcon device from dt node
Hi,
On Friday 14 June 2013 12:45 PM, Chanwoo Choi wrote:
From: Kishon Vijay Abraham I
Added an API of_extcon_get_extcon_dev() to be used by drivers to get
extcon device in the case of dt boot (this can be used instead of
extcon_get_extcon_dev()).
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Chanwoo Choi
Signed-off-by: Myungjoo Ham
---
Changes since v1:
- If edev->name is NULL, dev_name(dev) is used as edev->name.
- Change filename from of-extcon.* to of_extcon.*
- Fix build error when CONFIG_OF is not set
- Add header file(linux/err.h) to of_extcon.c
drivers/extcon/Makefile | 2 ++
drivers/extcon/extcon-class.c| 3 +-
drivers/extcon/of_extcon.c | 64
include/linux/extcon/of_extcon.h | 30 +++
4 files changed, 98 insertions(+), 1 deletion(-)
create mode 100644 drivers/extcon/of_extcon.c
create mode 100644 include/linux/extcon/of_extcon.h
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 540e2c3..83468f7 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -2,6 +2,8 @@
# Makefile for external connector class (extcon) devices
#
+obj-$(CONFIG_OF) += of_extcon.o
+
obj-$(CONFIG_EXTCON) += extcon-class.o
obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 23f11ea..08509ea 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -602,7 +602,8 @@ int extcon_dev_register(struct extcon_dev *edev, struct
device *dev)
edev->dev->class = extcon_class;
edev->dev->release = extcon_dev_release;
- dev_set_name(edev->dev, edev->name ? edev->name : dev_name(dev));
+ edev->name = edev->name ? edev->name : dev_name(dev);
+ dev_set_name(edev->dev, edev->name);
if (edev->max_supported) {
char buf[10];
diff --git a/drivers/extcon/of_extcon.c b/drivers/extcon/of_extcon.c
new file mode 100644
index 000..72173ec
--- /dev/null
+++ b/drivers/extcon/of_extcon.c
@@ -0,0 +1,64 @@
+/*
+ * OF helpers for External connector (extcon) framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Kishon Vijay Abraham I
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * of_extcon_get_extcon_dev - Get the name of extcon device from devicetree
+ * @dev - instance to the given device
+ * @index - index into list of extcon_dev
+ *
+ * return the instance of extcon device
+ */
+struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev, int index)
+{
+ struct device_node *node;
+ struct extcon_dev *edev;
+ struct platform_device *extcon_parent_dev;
+
+ if (!dev->of_node) {
+ dev_dbg(dev, "device does not have a device node entry\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev->of_node, "extcon", index);
+ if (!node) {
+ dev_dbg(dev, "failed to get phandle in %s node\n",
+ dev->of_node->full_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ extcon_parent_dev = of_find_device_by_node(node);
+ if (!extcon_parent_dev) {
+ dev_dbg(dev, "unable to find device by node\n");
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ edev = extcon_get_extcon_dev(dev_name(&extcon_parent_dev->dev));
+ if (!edev) {
+ dev_dbg(dev, "unable to get extcon device : %s\n",
+ dev_name(&extcon_parent_dev->dev));
+ return ERR_PTR(-ENODEV);
+ }
+
+ return edev;
+}
+EXPORT_SYMBOL_GPL(of_extcon_get_extcon_dev);
diff --git a/include/linux/extcon/of_extcon.h b/include/linux/extcon/of_extcon.h
new file mode 100644
index 000..462f071
--- /dev/null
+++ b/include/linux/extcon/of_extcon.h
@@ -0,0 +1,30 @@
+/*
+ * OF helpers for External connector (extcon) framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Kishon Vijay Abraham I
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __LINUX_OF_EXTCON_H
+#define __LINUX_OF_EXTCON_H
+
+#if defined(CONFIG_OF) && defined(CONFIG_EXTCON)
+extern struct extcon_dev
+ *of_extcon_get_extcon_dev(struct device *dev, int index);
+#else
+stati
Re: [RFC PATCH 1/4] arm: omap: Add phy binding info for musb in plat data
On 14/06/13 10:33, Tony Lindgren wrote: > If we want to fix something this late in the merge window, the patches > must have a clear description what caused the regression and what happens > without the patches. These patches don't have that. And they are marked > RFC also. So actually I'm not applying any of them before the regression > descriptions are there and the patches have been reposted without RFC > and have sufficient acks from people. No disagreement there. Kishon, I tested the patches on top of v3.10-rc5, booting with nfs root via usb gadget eth: Overo: works Beagle: works, but I need to reconnect the usb cable after kernel is up Beagle-xm: doesn't work. The cable is detected correctly, though Panda: works The problems with Beagles are there even without these patches, so they do make things better (fix Overo). Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt and PM runtime
* Tony Lindgren [130612 06:27]:
> * Linus Walleij [130611 01:00]:
> > If we can agree on this I will add the active state to the
> > state table and add a container in the core for this as well
> > as pinctrl_pm_select_active_state() so we can skip all the
> > pointless boilerplate also in the OMAP drivers, plus increase
> > the readability and portability quite a bit.
>
> Sounds good to me as long as we don't always need to select
> the default pins over and over in PM runtime_resume.
Here's this patch updated for pinctrl next with the active state
added. This patch should be merged separately towards the end
of the merge window once pinctrl code has been merged. The other
three patches can be merged independently.
Regards,
Tony
From: Tony Lindgren
Date: Thu, 13 Jun 2013 23:19:09 -0700
Subject: [PATCH] mmc: omap_hsmmc: Remux pins to support SDIO interrupt and PM
runtime
On some omaps we need to remux MMC pins for PM, and for some omaps
we need to remux the SDIO IRQ pin.
Based on an earlier patch by Andreas Fenkart .
Cc: Andreas Fenkart
Cc: Balaji T K
Cc: Linus Walleij
Signed-off-by: Tony Lindgren
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6377836..7029d34 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -475,6 +475,39 @@ static void omap_hsmmc_gpio_free(struct
omap_mmc_platform_data *pdata)
gpio_free(pdata->slots[0].gpio_cirq);
}
+static int omap_hsmmc_pinctrl_init(struct omap_hsmmc_host *host)
+{
+ struct device *dev = mmc_dev(host->mmc);
+ int res, found = 0;
+
+ if (!dev->pins)
+ return 0;
+
+ /*
+* The active and idle pins are optional, and used for
+* SDIO interrupt, or eMMC pulls for off-idle.
+*/
+ if (IS_ERR(dev->pins->active_state) ||
+ IS_ERR(dev->pins->idle_state)) {
+ return 0;
+ }
+
+ /* Let's make sure the idle and active states work */
+ res = pinctrl_pm_select_idle_state(dev);
+ if (res < 0)
+ return -ENODEV;
+ found++;
+
+ res = pinctrl_pm_select_active_state(dev);
+ if (res < 0)
+ return -ENODEV;
+ found++;
+
+ dev_info(mmc_dev(dev), "pins configured for dynamic remuxing\n");
+
+ return found;
+}
+
/*
* Start clock to the card
*/
@@ -1868,7 +1901,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
const struct of_device_id *match;
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
- struct pinctrl *pinctrl;
match = of_match_device(of_match_ptr(omap_mmc_of_match), &pdev->dev);
if (match) {
@@ -2101,21 +2133,19 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
omap_hsmmc_disable_irq(host);
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl))
- dev_warn(&pdev->dev,
- "pins are not configured from the driver\n");
-
/*
-* For now, only support SDIO interrupt if we are doing
-* muxing of dat1 when booted with DT. This is because the
+* For now, only support SDIO interrupt if we are doing dynamic
+* remuxing of dat1 when booted with DT. This is because the
* supposedly the wake-up events for CTPL don't work from deeper
* idle states. And we don't want to add new legacy mux platform
* init code callbacks any longer as we are moving to DT based
* booting anyways.
*/
if (match) {
- if (!IS_ERR(pinctrl) && mmc_slot(host).sdio_irq)
+ ret = omap_hsmmc_pinctrl_init(host);
+ if (ret < 0)
+ goto err_pinctrl_state;
+ else if (ret > 1 && mmc_slot(host).sdio_irq)
mmc->caps |= MMC_CAP_SDIO_IRQ;
}
@@ -2143,6 +2173,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
err_slot_name:
mmc_remove_host(mmc);
+err_pinctrl_state:
if ((mmc_slot(host).sdio_irq))
free_irq(mmc_slot(host).sdio_irq, host);
err_irq_sdio:
@@ -2337,6 +2368,10 @@ static int omap_hsmmc_runtime_suspend(struct device *dev)
OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
spin_unlock_irqrestore(&host->irq_lock, flags);
+ ret = pinctrl_pm_select_idle_state(dev);
+ if (ret < 0)
+ dev_err(dev, "Unable to select idle pinmux\n");
+
if (mmc_slot(host).sdio_irq)
enable_irq(mmc_slot(host).sdio_irq);
}
@@ -2360,6 +2395,10 @@ static int omap_hsmmc_runtime_resume(struct device *dev)
if (mmc_slot(host).sdio_irq)
disable_irq(mmc_slot(host).sdio_irq);
+ ret = pinctrl_pm_select_active_state(dev);
+ if (ret < 0)
+ dev_err(dev, "Unable to select active pinmux\
Re: [PATCH 2/4] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode
* Tony Lindgren [130607 14:56]:
> From: Andreas Fenkart
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
> {
> - OMAP_HSMMC_WRITE(host->base, ISE, 0);
> - OMAP_HSMMC_WRITE(host->base, IE, 0);
> + u32 irq_mask = 0;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&host->irq_lock, flags);
> +
> + /* no transfer running, need to signal cirq if */
> + if (host->sdio_irq_en)
> + irq_mask |= CIRQ_EN;
> +
> + OMAP_HSMMC_WRITE(host->base, ISE, irq_mask);
> + OMAP_HSMMC_WRITE(host->base, IE, irq_mask);
> OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
> +
> + spin_unlock_irqrestore(&host->irq_lock, flags);
> }
Found one bug in Andreas' patch. Keeping the CIRQ_EN enabled here
is wrong. I've noticed that it causes eternal sdio interrupt loops
for example when running iw dev wlan0 scan when omap is hitting
idle states.
As we already have a separate GPIO interrupt muxed for the
idle states, there's no reason to keep CIRQ_EN set.
Updated patch below without the CIRQ_EN set.
Regards,
Tony
From: Andreas Fenkart
Date: Thu, 13 Jun 2013 23:19:09 -0700
Subject: [PATCH] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode
Without functional clock the omap_hsmmc module can't forward SDIO IRQs to
the system. This patch reconfigures dat1 line as a gpio while the fclk is
off. When the fclk is present it uses the standard SDIO IRQ detection of
the module.
The gpio irq is managed via the 'disable_depth' ref counter of the irq
subsystem, this driver simply calls enable_irq/disable_irq when needed.
sdio irqsdio irq
unmasked masked
-
runtime default |1 | 2
runtime suspend |0 | 1
irq disable depth
only when sdio irq is enabled AND the module is idle, the reference
count drops to zero and the gpio irq is effectively armed.
Patch was tested on AM335x/Stream800. Test setup was two modules
with sdio wifi cards. Modules where connected to a dual-band AP, each
module using a different band. One of module was running iperf as server
the other as client connecting to the server in a while true loop. Test
was running for 4+ weeks. There were about 60 Mio. suspend/resume
transitions. Test was shut down regularly.
Cc: Andreas Fenkart
Cc: Balaji T K
Signed-off-by: Andreas Fenkart
Reviewed-by: Grant Likely
[t...@atomide.com: updated and separated out pin muxing]
Signed-off-by: Tony Lindgren
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ed271fc..5a3df37 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,6 +20,29 @@ ti,dual-volt: boolean, supports dual voltage cards
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
+ti,cirq-gpio: When omap_hsmmc module is suspended, its functional
+clock is turned off. Without fclk it can't forward SDIO IRQs to the
+system. For that to happen, it needs to tell the PRCM to restore
+its fclk, which is done through the swakeup line.
+
+ --
+ | PRCM |
+ --
+| ^
+ fclk | | swakeup
+v |
+ --- --
+ <-- IRQ -- | hsmmc | <-- CIRQ -- | card |
+ --- --
+
+The problem is, that on the AM335x family the swakeup line is
+missing, it has not been routed from the module to the PRCM.
+The way to work around this, is to reconfigure the dat1 line as a
+GPIO upon suspend. Beyond this option you also need to set named
+states "default" and "idle "in the .dts file for the pins, using
+pinctrl-single.c. The MMC driver will then then toggle between
+default and idle during the runtime.
+
Example:
mmc1: mmc@0x4809c000 {
@@ -31,3 +54,22 @@ Example:
vmmc-supply = <&vmmc>; /* phandle to regulator node */
ti,non-removable;
};
+
+[am335x with with gpio for sdio irq]
+
+ mmc1_cirq_pin: pinmux_cirq_pin {
+ pinctrl-single,pins = <
+ 0x0f8 0x3f /* MMC0_DAT1 as GPIO2_28 */
+ >;
+ };
+
+ mmc1: mmc@4806 {
+ pinctrl-names = "default", "idle";
+ pinctrl-0 = <&mmc1_pins>;
+ pinctrl-1 = <&mmc1_cirq_pin>;
+ ti,cirq-gpio = <&gpio3 28 0>;
+ ti,non-removable;
+ bus-width = <4>;
+ vmmc-supply = <&ldo2_reg>;
+ vmmc_aux-supply = <&vmmc>;
+ };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/d
Re: [RFC PATCH 1/4] arm: omap: Add phy binding info for musb in plat data
* Tomi Valkeinen [130613 23:42]: > On 14/06/13 08:47, Tony Lindgren wrote: > > * Kishon Vijay Abraham I [130613 22:41]: > >> Hi, > >> > >> On Thursday 13 June 2013 06:35 PM, Tomi Valkeinen wrote: > >>> Hi, > >>> > >>> On 28/05/13 08:18, Kishon Vijay Abraham I wrote: > Hi Tony, > > On Friday 17 May 2013 06:52 PM, Kishon Vijay Abraham I wrote: > > In order for controllers to get PHY in case of non dt boot, the phy > > binding information (phy label) should be added in the platform > > data of the controller. > > This series would be needed to get MUSB working in OMAP3 boards for > non-dt boot case. Do you think this is good enough to go in this rc > cycle? > >>> > >>> Did this or some other solution go forward? I'm still unable to boot > >>> with usb-gadget-ethernet with v3.10-rc5. > >> > >> No. I think Tony is ok to take this only during next merge window. > > > > Yes I'll apply them to omap-for-v3.11/fixes-non-critical. We really > > should have basic functionaly tested and working always before the > > merge window so we only need to do minimal fixes during the -rc cycle. > > I'm mostly interested in the USB gadget ethernet for the boards I have, > but if I'm not mistaken, all USB gadget support for many OMAP boards is > broken in v3.10. Shouldn't that be fixed, no matter if it's a minimal > fix or not? Or is there some other, more minimal, way to fix this? Yes it's unfortunate it's broken. But frankly I'm pretty tired of this constant fixing up of basic things for omaps after every merge window. If some patches are not tested properly, then everybody, _do_not_try_to_merge_broken_patches_upstream_. Let them float on the mailing lists until they get fixed or forgotten. Simple as that. If we want to fix something this late in the merge window, the patches must have a clear description what caused the regression and what happens without the patches. These patches don't have that. And they are marked RFC also. So actually I'm not applying any of them before the regression descriptions are there and the patches have been reposted without RFC and have sufficient acks from people. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] extcon: Add an API to get extcon device from dt node
From: Kishon Vijay Abraham I
Added an API of_extcon_get_extcon_dev() to be used by drivers to get
extcon device in the case of dt boot (this can be used instead of
extcon_get_extcon_dev()).
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Chanwoo Choi
Signed-off-by: Myungjoo Ham
---
Changes since v1:
- If edev->name is NULL, dev_name(dev) is used as edev->name.
- Change filename from of-extcon.* to of_extcon.*
- Fix build error when CONFIG_OF is not set
- Add header file(linux/err.h) to of_extcon.c
drivers/extcon/Makefile | 2 ++
drivers/extcon/extcon-class.c| 3 +-
drivers/extcon/of_extcon.c | 64
include/linux/extcon/of_extcon.h | 30 +++
4 files changed, 98 insertions(+), 1 deletion(-)
create mode 100644 drivers/extcon/of_extcon.c
create mode 100644 include/linux/extcon/of_extcon.h
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 540e2c3..83468f7 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -2,6 +2,8 @@
# Makefile for external connector class (extcon) devices
#
+obj-$(CONFIG_OF) += of_extcon.o
+
obj-$(CONFIG_EXTCON) += extcon-class.o
obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 23f11ea..08509ea 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -602,7 +602,8 @@ int extcon_dev_register(struct extcon_dev *edev, struct
device *dev)
edev->dev->class = extcon_class;
edev->dev->release = extcon_dev_release;
- dev_set_name(edev->dev, edev->name ? edev->name : dev_name(dev));
+ edev->name = edev->name ? edev->name : dev_name(dev);
+ dev_set_name(edev->dev, edev->name);
if (edev->max_supported) {
char buf[10];
diff --git a/drivers/extcon/of_extcon.c b/drivers/extcon/of_extcon.c
new file mode 100644
index 000..72173ec
--- /dev/null
+++ b/drivers/extcon/of_extcon.c
@@ -0,0 +1,64 @@
+/*
+ * OF helpers for External connector (extcon) framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Kishon Vijay Abraham I
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * of_extcon_get_extcon_dev - Get the name of extcon device from devicetree
+ * @dev - instance to the given device
+ * @index - index into list of extcon_dev
+ *
+ * return the instance of extcon device
+ */
+struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev, int index)
+{
+ struct device_node *node;
+ struct extcon_dev *edev;
+ struct platform_device *extcon_parent_dev;
+
+ if (!dev->of_node) {
+ dev_dbg(dev, "device does not have a device node entry\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev->of_node, "extcon", index);
+ if (!node) {
+ dev_dbg(dev, "failed to get phandle in %s node\n",
+ dev->of_node->full_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ extcon_parent_dev = of_find_device_by_node(node);
+ if (!extcon_parent_dev) {
+ dev_dbg(dev, "unable to find device by node\n");
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ edev = extcon_get_extcon_dev(dev_name(&extcon_parent_dev->dev));
+ if (!edev) {
+ dev_dbg(dev, "unable to get extcon device : %s\n",
+ dev_name(&extcon_parent_dev->dev));
+ return ERR_PTR(-ENODEV);
+ }
+
+ return edev;
+}
+EXPORT_SYMBOL_GPL(of_extcon_get_extcon_dev);
diff --git a/include/linux/extcon/of_extcon.h b/include/linux/extcon/of_extcon.h
new file mode 100644
index 000..462f071
--- /dev/null
+++ b/include/linux/extcon/of_extcon.h
@@ -0,0 +1,30 @@
+/*
+ * OF helpers for External connector (extcon) framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Kishon Vijay Abraham I
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __LINUX_OF_EXTCON_H
+#define __LINUX_OF_EXTCON_H
+
+#if defined(CONFIG_OF) && defined(CONFIG_EXTCON)
+extern struct extcon_dev
+ *of_extcon_get_extcon_dev(struct device *dev, int index);
+#else
+static inline struct extcon_dev
+ *of_extcon_get_extcon_dev(struc
