Re: [PATCH V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file
On 10/06/13 17:14, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@iki.fi [130610 03:44]:
DSS does not have DT bindings, and removing DSS from hwmod data will
break DSS for omap4.
Ah that's right. Care to post a patch reverting the minimal parts that
you need for omap4 against omap-for-v3.11/cleanup?
This one adds back the DSS data.
Tomi
From e23a18fe14cbfebf9b08e3004aec92e05a86a117 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Tue, 11 Jun 2013 10:37:19 +0300
Subject: [PATCH] ARM: OMAP4: hwmod data: add DSS data back
Commit 3b9b10151c6838af52244cec4af41a938bb5b7ec (ARM: OMAP4: hwmod data:
Clean up the data file) removes hwmod data for omap4, including DSS
data. DSS has not yet been converted to DT, so the hwmod data is still
needed.
This patch adds back the DSS parts of the hwmod data.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 54 ++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 5f5d631..c8d4957 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -619,6 +619,16 @@ static struct omap_hwmod_class omap44xx_dispc_hwmod_class
= {
};
/* dss_dispc */
+static struct omap_hwmod_irq_info omap44xx_dss_dispc_irqs[] = {
+ { .irq = 25 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_dss_dispc_sdma_reqs[] = {
+ { .dma_req = 5 + OMAP44XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+
static struct omap_dss_dispc_dev_attr omap44xx_dss_dispc_dev_attr = {
.manager_count = 3,
.has_framedonetv_irq= 1
@@ -628,6 +638,8 @@ static struct omap_hwmod omap44xx_dss_dispc_hwmod = {
.name = dss_dispc,
.class = omap44xx_dispc_hwmod_class,
.clkdm_name = l3_dss_clkdm,
+ .mpu_irqs = omap44xx_dss_dispc_irqs,
+ .sdma_reqs = omap44xx_dss_dispc_sdma_reqs,
.main_clk = dss_dss_clk,
.prcm = {
.omap4 = {
@@ -660,6 +672,16 @@ static struct omap_hwmod_class omap44xx_dsi_hwmod_class = {
};
/* dss_dsi1 */
+static struct omap_hwmod_irq_info omap44xx_dss_dsi1_irqs[] = {
+ { .irq = 53 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_dss_dsi1_sdma_reqs[] = {
+ { .dma_req = 74 + OMAP44XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+
static struct omap_hwmod_opt_clk dss_dsi1_opt_clks[] = {
{ .role = sys_clk, .clk = dss_sys_clk },
};
@@ -668,6 +690,8 @@ static struct omap_hwmod omap44xx_dss_dsi1_hwmod = {
.name = dss_dsi1,
.class = omap44xx_dsi_hwmod_class,
.clkdm_name = l3_dss_clkdm,
+ .mpu_irqs = omap44xx_dss_dsi1_irqs,
+ .sdma_reqs = omap44xx_dss_dsi1_sdma_reqs,
.main_clk = dss_dss_clk,
.prcm = {
.omap4 = {
@@ -680,6 +704,16 @@ static struct omap_hwmod omap44xx_dss_dsi1_hwmod = {
};
/* dss_dsi2 */
+static struct omap_hwmod_irq_info omap44xx_dss_dsi2_irqs[] = {
+ { .irq = 84 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_dss_dsi2_sdma_reqs[] = {
+ { .dma_req = 83 + OMAP44XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+
static struct omap_hwmod_opt_clk dss_dsi2_opt_clks[] = {
{ .role = sys_clk, .clk = dss_sys_clk },
};
@@ -688,6 +722,8 @@ static struct omap_hwmod omap44xx_dss_dsi2_hwmod = {
.name = dss_dsi2,
.class = omap44xx_dsi_hwmod_class,
.clkdm_name = l3_dss_clkdm,
+ .mpu_irqs = omap44xx_dss_dsi2_irqs,
+ .sdma_reqs = omap44xx_dss_dsi2_sdma_reqs,
.main_clk = dss_dss_clk,
.prcm = {
.omap4 = {
@@ -720,6 +756,16 @@ static struct omap_hwmod_class omap44xx_hdmi_hwmod_class =
{
};
/* dss_hdmi */
+static struct omap_hwmod_irq_info omap44xx_dss_hdmi_irqs[] = {
+ { .irq = 101 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_dss_hdmi_sdma_reqs[] = {
+ { .dma_req = 75 + OMAP44XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+
static struct omap_hwmod_opt_clk dss_hdmi_opt_clks[] = {
{ .role = sys_clk, .clk = dss_sys_clk },
};
@@ -733,6 +779,8 @@ static struct omap_hwmod omap44xx_dss_hdmi_hwmod = {
* set idle mode by software.
*/
.flags = HWMOD_SWSUP_SIDLE,
+ .mpu_irqs = omap44xx_dss_hdmi_irqs,
+ .sdma_reqs = omap44xx_dss_hdmi_sdma_reqs,
.main_clk = dss_48mhz_clk,
.prcm = {
.omap4 = {
@@ -765,6 +813,11 @@ static struct omap_hwmod_class omap44xx_rfbi_hwmod_class =
{
};
/* dss_rfbi */
+static struct omap_hwmod_dma_info
Re: OMAP v3.10-rc regressions that no one's fixed
Hi Paul,
On 06/10/2013 09:22 AM, 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:
* 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
I will send a patch soon to fix these. Need to test the patch(es) first. I
think they surfaced because I have enabled the audio support in
omap2plus_defconfig for OMAP4 and 5 - which require McPDM and DMIC.
Just couple of minutes, and I'll have the fix.
--
Péter
--
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 3/4] mmc: omap_hsmmc: Remux pins to support SDIO interrupt and PM runtime
On Mon, Jun 10, 2013 at 6:23 PM, Tony Lindgren t...@atomide.com wrote: We only should remux the pins that need remuxing as that's done every time hitting idle. So I think we should have the following default groups: default Static pins that don't change, no need to remux configured in consumer driver probe like we already do active Optional dynamic pins remuxed for runtime, can be configured and selected in consumer driver probe. The consumer driver may also want to select this state in PM runtime resume. idleOptional dynamic pins remuxed for idle. The consumer driver may also want to select this state in PM runtime suspend depending on device_can_wakeup() and driver specific needs. The one thing I don't understand is why a driver would select the active state in probe(), unless it's a driver that does not support runtime PM. (But maybe that's what you mean.) Compare this to linus/pinctrl/pinctrl-state.h: /** * @PINCTRL_STATE_DEFAULT: the state the pinctrl handle shall be put * into as default, usually this means the pins are up and ready to * be used by the device driver. This state is commonly used by * hogs to configure muxing and pins at boot, and also as a state * to go into when returning from sleep and idle in * .pm_runtime_resume() or ordinary .resume() for example. * @PINCTRL_STATE_IDLE: the state the pinctrl handle shall be put into * when the pins are idle. This is a state where the system is relaxed * but not fully sleeping - some power may be on but clocks gated for * example. Could typically be set from a pm_runtime_suspend() or * pm_runtime_idle() operation. * @PINCTRL_STATE_SLEEP: the state the pinctrl handle shall be put into * when the pins are sleeping. This is a state where the system is in * its lowest sleep state. Could typically be set from an * ordinary .suspend() function. */ #define PINCTRL_STATE_DEFAULT default #define PINCTRL_STATE_IDLE idle #define PINCTRL_STATE_SLEEP sleep The way I currently use these in e.g. drivers/spi/spi-pl022 is: probe: - default runtime_suspend: - idle runtime_resume: - default suspend: - sleep resume: - default - idle Notice that we go to default then idle on probe and runtime resume. This is because the idle state is optional (as is the sleep state). So I guess if we should extend this terminology to match what you are using for the OMAP it would rather be like this: probe: - default runtime_suspend: - idle runtime_resume: - default - active suspend: - sleep resume: - default - idle Just one more optional active state in runtime resume. Correct? 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. However in this case I *suspect* that what you really want to do it to rename the state called default to sleep (it appears the default state is sleepy) and then rename the active state to default (as this is the defined semantic meaning of default from linux/pinctrl/pinctrl-state.h. The idle state above could also be called sleep instead of idle if you prefer that. No I think we should reserve that name for the pin state associated with suspend(). Let's leave it like this. I think the confusion is caused by the fact that we need three mux groups, not just two :) The toggling between active and idle is the hotpath as that can potentially happen for multiple drivers every time we enter and exit idle. Actually we have the same thing, it's just that our default and active are the same thing. But it seems we need to add your granularity to this. Yours, Linus Walleij -- 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 2/3] ARM: OMAP2+: devices: Do not print error when DMIC hwmod lookup fails
It means that the SoC does not have DMIC IP
.
Reported-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/devices.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index b82538d..8f268b4 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -393,10 +393,8 @@ static void __init omap_init_dmic(void)
struct platform_device *pdev;
oh = omap_hwmod_lookup(dmic);
- if (!oh) {
- pr_err(Could not look up dmic hw_mod\n);
+ if (!oh)
return;
- }
pdev = omap_device_build(omap-dmic, -1, oh, NULL, 0);
WARN(IS_ERR(pdev), Can't build omap_device for omap-dmic.\n);
--
1.8.2.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 1/3] ARM: OMAP2+: devices: Do not print error when McPDM hwmod lookup fails
It means that the SoC does not have McPDM IP.
Reported-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/devices.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 4269fc1..b82538d 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -374,10 +374,8 @@ static void __init omap_init_mcpdm(void)
struct platform_device *pdev;
oh = omap_hwmod_lookup(mcpdm);
- if (!oh) {
- printk(KERN_ERR Could not look up mcpdm hw_mod\n);
+ if (!oh)
return;
- }
pdev = omap_device_build(omap-mcpdm, -1, oh, NULL, 0);
WARN(IS_ERR(pdev), Can't build omap_device for omap-mcpdm.\n);
--
1.8.2.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 3/3] ARM: OMAP2+: devices: Do not print error when dss_hdmi hwmod lookup fails
The dss_hdmi hwmod is used to create the HDMI audio device for OMAP4+
When we boot the kernel we can silently ignore the failure since the IP
does not exist on them.
Reported-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/devices.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 8f268b4..daa0ff6 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -417,10 +417,8 @@ static void __init omap_init_hdmi_audio(void)
struct platform_device *pdev;
oh = omap_hwmod_lookup(dss_hdmi);
- if (!oh) {
- printk(KERN_ERR Could not look up dss_hdmi hw_mod\n);
+ if (!oh)
return;
- }
pdev = omap_device_build(omap-hdmi-audio-dai, -1, oh, NULL, 0);
WARN(IS_ERR(pdev),
--
1.8.2.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 0/3] ARM: OMAP2+: devices: Silence hwmod lookup failures (dmic/mcpdm)
Hi, Small patches to silence the hwmod lookup failures in case when we boot the kernel on boards where the IPs are not present (OMAP2/3 vs McPDM, DMIC, HDMI audio). Regards, Peter --- Peter Ujfalusi (3): ARM: OMAP2+: devices: Do not print error when McPDM hwmod lookup fails ARM: OMAP2+: devices: Do not print error when DMIC hwmod lookup fails ARM: OMAP2+: devices: Do not print error when dss_hdmi hwmod lookup fails arch/arm/mach-omap2/devices.c | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) -- 1.8.2.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 4/4] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap
On 06/10/2013 05:25 PM, Tony Lindgren wrote: * Quadros, Roger rog...@ti.com [130610 05:37]: Hi Tony, (sorry, on Outlook web) - compatible = ti,omap4-padconf, pinctrl-single; + compatible = ti,omap4-padconf; This change is not necessary if we make sure the pinctrl-single-omap driver gets registered early enough, before the pinctrl devices are probed. (e.g. subsys_initcall()) I'd rather make everything just module_init, there should not be any need to tinker with the init call ordering any longer with deferred probe. And by making everything into regular device drivers we actually see real error messages without DEBUG_LL and earlyprintk if something goes wrong. Note that there are patches queued to make twl-core.c just regular module_init as well, so that should fix any issues you might be related it probing before pinctrl. OK. I've commented about this in the other patch. Sorry can you clarify, which other patch? The other message I saw in this thread was empty. Or at least I have not seen it yet. Sorry about that. Outlook web sucks. I see that you have found it :). cheers, -roger -- 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
[net PATCH 0/2] Fixes for davinci MDIO on suspend/resume
This patch series fixes the following issues with Davinci MDIO * Bring up MDIO driver earlier than Ethernet driver so that ethernet driver can communicate with the phy as soon as it is resumed. * On suspend/resume cycle the MDIO divider will be set to reset value so this has to be programmed after resume. Mugunthan V N (2): drivers: net: davinci_mdio: moving mdio resume earlier than cpsw ethernet driver drivers: net: davinci_mdio: restore mdio clk divider in mdio resume drivers/net/ethernet/ti/davinci_mdio.c |9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) -- 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
[net PATCH 1/2] drivers: net: davinci_mdio: moving mdio resume earlier than cpsw ethernet driver
MDIO driver should resume before CPSW ethernet driver so that CPSW connect
to the phy and start tx/rx ethernet packets, changing the suspend/resume
apis with suspend_late/resume_early.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/ethernet/ti/davinci_mdio.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c
b/drivers/net/ethernet/ti/davinci_mdio.c
index b2275d1..74e56b3 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -476,8 +476,8 @@ static int davinci_mdio_resume(struct device *dev)
}
static const struct dev_pm_ops davinci_mdio_pm_ops = {
- .suspend= davinci_mdio_suspend,
- .resume = davinci_mdio_resume,
+ .suspend_late = davinci_mdio_suspend,
+ .resume_early = davinci_mdio_resume,
};
static const struct of_device_id davinci_mdio_of_mtable[] = {
--
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
[net PATCH 2/2] drivers: net: davinci_mdio: restore mdio clk divider in mdio resume
During suspend resume cycle all the register data is lost, so MDIO
clock divier value gets reset. This patch restores the clock divider
value.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/ethernet/ti/davinci_mdio.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c
b/drivers/net/ethernet/ti/davinci_mdio.c
index 74e56b3..c47f0db 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -459,15 +459,12 @@ static int davinci_mdio_suspend(struct device *dev)
static int davinci_mdio_resume(struct device *dev)
{
struct davinci_mdio_data *data = dev_get_drvdata(dev);
- u32 ctrl;
pm_runtime_get_sync(data-dev);
spin_lock(data-lock);
/* restart the scan state machine */
- ctrl = __raw_readl(data-regs-control);
- ctrl |= CONTROL_ENABLE;
- __raw_writel(ctrl, data-regs-control);
+ __davinci_mdio_reset(data);
data-suspended = false;
spin_unlock(data-lock);
--
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 01/22] mfd/ti_am335x_tscadc: remove regmap
The MFD part uses regmap without caching and is the only user of the
regmap. The child drivers, that is input(touch) and iio(adc), use direct
reg access.
There is a patch which converts them to use regmap as well but I see no
benefit at all doing this. There is a direct MMIO bus access with no
need to cache values like for I2C or SPI devices. Furthermore, most (if
not all) of the access done by the touch ADC driver read volatile
register.
Therefore this patch removes regmap part of the driver.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/mfd/ti_am335x_tscadc.c | 23 ++-
include/linux/mfd/ti_am335x_tscadc.h |1 -
2 files changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index e9f3fb5..804e61e 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -19,7 +19,6 @@
#include linux/err.h
#include linux/io.h
#include linux/clk.h
-#include linux/regmap.h
#include linux/mfd/core.h
#include linux/pm_runtime.h
@@ -29,25 +28,15 @@
static unsigned int tscadc_readl(struct ti_tscadc_dev *tsadc, unsigned int reg)
{
- unsigned int val;
-
- regmap_read(tsadc-regmap_tscadc, reg, val);
- return val;
+ return readl(tsadc-tscadc_base + reg);
}
static void tscadc_writel(struct ti_tscadc_dev *tsadc, unsigned int reg,
unsigned int val)
{
- regmap_write(tsadc-regmap_tscadc, reg, val);
+ writel(val, tsadc-tscadc_base + reg);
}
-static const struct regmap_config tscadc_regmap_config = {
- .name = ti_tscadc,
- .reg_bits = 32,
- .reg_stride = 4,
- .val_bits = 32,
-};
-
static void tscadc_idle_config(struct ti_tscadc_dev *config)
{
unsigned int idleconfig;
@@ -121,14 +110,6 @@ static int ti_tscadc_probe(struct platform_device
*pdev)
return -ENOMEM;
}
- tscadc-regmap_tscadc = devm_regmap_init_mmio(pdev-dev,
- tscadc-tscadc_base, tscadc_regmap_config);
- if (IS_ERR(tscadc-regmap_tscadc)) {
- dev_err(pdev-dev, regmap init failed\n);
- err = PTR_ERR(tscadc-regmap_tscadc);
- goto ret;
- }
-
pm_runtime_enable(pdev-dev);
pm_runtime_get_sync(pdev-dev);
diff --git a/include/linux/mfd/ti_am335x_tscadc.h
b/include/linux/mfd/ti_am335x_tscadc.h
index c79ad5d..dc75c34 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -137,7 +137,6 @@ struct mfd_tscadc_board {
struct ti_tscadc_dev {
struct device *dev;
- struct regmap *regmap_tscadc;
void __iomem *tscadc_base;
int irq;
struct mfd_cell cells[TSCADC_CELLS];
--
1.7.10.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 06/22] input/ti_am33x_tsc: Add DT support
From: Patil, Rachna rac...@ti.com
Add DT support for client touchscreen driver
[ pa...@antoniou-consulting.com : use of_get_child_by_name
instead of of_find_node_by_name ]
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Signed-off-by: Patil, Rachna rac...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
[ bigeasy: shift the code to the left, shirnk titsc_parse_dt() by not
using temp value, change a binding and document them in
ti-tsc-adc.txt which also contains ADC binding which will be
used later, addd DT binding to mfd driver so we our DT node
without of_get_child_by_name(), rename steps_to_configure to
coordinate_readouts because this is what it really does,
don't overrire err after calling titsc_parse_dt() or
titsc_parse_pdata()]
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
.../bindings/input/touchscreen/ti-tsc-adc.txt | 44
drivers/input/touchscreen/ti_am335x_tsc.c | 105 +++-
drivers/mfd/ti_am335x_tscadc.c |1 +
3 files changed, 127 insertions(+), 23 deletions(-)
create mode 100644
Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
new file mode 100644
index 000..491c97b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
@@ -0,0 +1,44 @@
+* TI - TSC ADC (Touschscreen and analog digital converter)
+~~
+
+Required properties:
+- child tsc
+ ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen
+ support on the platform.
+ ti,x-plate-resistance: X plate resistance
+ ti,coordiante-readouts: The sequencer supports a total of 16
+ programmable steps each step is used to
+ read a single coordinate. A single
+readout is enough but multiple reads can
+ increase the quality.
+ A value of 5 means, 5 reads for X, 5 for
+ Y and 2 for Z (always). This utilises 12
+ of the 16 software steps available. The
+ remaining 4 can be used by the ADC.
+ ti,wire-config: Different boards could have a different order for
+ connecting wires on touchscreen. We need to provide an
+ 8 bit number where in the 1st four bits represent the
+ analog lines and the next 4 bits represent positive/
+ negative terminal on that input line. Notations to
+ represent the input lines and terminals resoectively
+ is as follows:
+ AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
+ XP = 0, XN = 1, YP = 2, YN = 3.
+- child adc
+ ti,adc-channels: List of analog inputs available for ADC.
+AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
+
+Example:
+ tscadc: tscadc@44e0d000 {
+ compatible = ti,am3359-tscadc;
+ tsc {
+ ti,wires = 4;
+ ti,x-plate-resistance = 200;
+ ti,coordiante-readouts = 5;
+ ti,wire-config = 0x00 0x11 0x22 0x33;
+ };
+
+ adc {
+ ti,adc-channels = 4 5 6 7;
+ };
+ }
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index b2f8a46..a44d2c4 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -26,6 +26,8 @@
#include linux/io.h
#include linux/input/ti_am335x_tsc.h
#include linux/delay.h
+#include linux/of.h
+#include linux/of_device.h
#include linux/mfd/ti_am335x_tscadc.h
@@ -47,7 +49,7 @@ struct titsc {
unsigned intwires;
unsigned intx_plate_resistance;
boolpen_down;
- int steps_to_configure;
+ int coordinate_readouts;
u32 config_inp[4];
u32 bit_xp, bit_xn, bit_yp, bit_yn;
u32 inp_xp, inp_xn, inp_yp, inp_yn;
@@ -123,7 +125,7 @@ static void titsc_step_config(struct titsc *ts_dev)
int i, total_steps;
/* Configure the Step registers */
- total_steps = 2 * ts_dev-steps_to_configure;
+ total_steps = 2 * ts_dev-coordinate_readouts;
config = STEPCONFIG_MODE_HWSYNC |
STEPCONFIG_AVG_16 | ts_dev-bit_xp;
@@ -141,7 +143,7 @@ static void
[PATCH 08/22] iio/ti_am335x_adc: Add DT support
From: Patil, Rachna rac...@ti.com
Add DT support for client ADC driver.
[ pa...@antoniou-consulting.com : use of_get_child_by_name
instead of of_find_node_by_name ]
Acked-by: Jonathan Cameron ji...@kernel.org
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Signed-off-by: Patil, Rachna rac...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
[bigeasy: shift the code to the left, fix clean up on
of_get_child_by_name() failer, provide OF binding in mfd, use
own of node, get rid of of_get_child_by_name()]
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/iio/adc/ti_am335x_adc.c | 29 -
drivers/mfd/ti_am335x_tscadc.c |1 +
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 543b9c4..b24402c 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -22,6 +22,8 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/iio/iio.h
+#include linux/of.h
+#include linux/of_device.h
#include linux/mfd/ti_am335x_tscadc.h
#include linux/platform_data/ti_am335x_adc.h
@@ -152,11 +154,12 @@ static int tiadc_probe(struct platform_device *pdev)
struct iio_dev *indio_dev;
struct tiadc_device *adc_dev;
struct ti_tscadc_dev*tscadc_dev = ti_tscadc_dev_get(pdev);
- struct mfd_tscadc_board *pdata;
+ struct mfd_tscadc_board *pdata = tscadc_dev-dev-platform_data;
+ struct device_node *node = pdev-dev.of_node;
int err;
+ u32 val32;
- pdata = tscadc_dev-dev-platform_data;
- if (!pdata || !pdata-adc_init) {
+ if (!pdata !node) {
dev_err(pdev-dev, Could not find platform data\n);
return -EINVAL;
}
@@ -169,8 +172,17 @@ static int tiadc_probe(struct platform_device *pdev)
}
adc_dev = iio_priv(indio_dev);
- adc_dev-mfd_tscadc = tscadc_dev;
- adc_dev-channels = pdata-adc_init-adc_channels;
+ adc_dev-mfd_tscadc = ti_tscadc_dev_get(pdev);
+
+ if (pdata)
+ adc_dev-channels = pdata-adc_init-adc_channels;
+ else {
+ err = of_property_read_u32(node,
+ ti,adc-channels, val32);
+ if (err 0)
+ goto err_free_device;
+ adc_dev-channels = val32;
+ }
indio_dev-dev.parent = pdev-dev;
indio_dev-name = dev_name(pdev-dev);
@@ -260,11 +272,18 @@ static const struct dev_pm_ops tiadc_pm_ops = {
#define TIADC_PM_OPS NULL
#endif
+static const struct of_device_id ti_adc_dt_ids[] = {
+ { .compatible = ti,am3359-adc, },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ti_adc_dt_ids);
+
static struct platform_driver tiadc_driver = {
.driver = {
.name = tiadc,
.owner = THIS_MODULE,
.pm = TIADC_PM_OPS,
+ .of_match_table = of_match_ptr(ti_adc_dt_ids),
},
.probe = tiadc_probe,
.remove = tiadc_remove,
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index 15a01f6..eaaa253 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -191,6 +191,7 @@ static int ti_tscadc_probe(struct platform_device
*pdev)
/* ADC Cell */
cell = tscadc-cells[ADC_CELL];
cell-name = tiadc;
+ cell-of_compatible = ti,am3359-adc;
cell-platform_data = tscadc;
cell-pdata_size = sizeof(tscadc);
--
1.7.10.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 07/22] input/ti_am33x_tsc: remove platform_data support
This patch removes access to platform data mfd_tscadc_board because the
platform is DT only.
Acked-by: Dmitry Torokhov dmitry.torok...@gmail.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/input/touchscreen/ti_am335x_tsc.c | 25 +
1 file changed, 1 insertion(+), 24 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index a44d2c4..66c5a26 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -24,7 +24,6 @@
#include linux/clk.h
#include linux/platform_device.h
#include linux/io.h
-#include linux/input/ti_am335x_tsc.h
#include linux/delay.h
#include linux/of.h
#include linux/of_device.h
@@ -347,24 +346,6 @@ static int titsc_parse_dt(struct platform_device *pdev,
ts_dev-config_inp, ARRAY_SIZE(ts_dev-config_inp));
}
-static int titsc_parse_pdata(struct ti_tscadc_dev *tscadc_dev,
- struct titsc *ts_dev)
-{
- struct mfd_tscadc_board *pdata = tscadc_dev-dev-platform_data;
-
- if (!pdata)
- return -EINVAL;
-
- ts_dev-wires = pdata-tsc_init-wires;
- ts_dev-x_plate_resistance =
- pdata-tsc_init-x_plate_resistance;
- ts_dev-steps_to_configure =
- pdata-tsc_init-steps_to_configure;
- memcpy(ts_dev-config_inp, pdata-tsc_init-wire_config,
- sizeof(pdata-tsc_init-wire_config));
- return 0;
-}
-
/*
* The functions for inserting/removing driver as a module.
*/
@@ -390,11 +371,7 @@ static int titsc_probe(struct platform_device *pdev)
ts_dev-input = input_dev;
ts_dev-irq = tscadc_dev-irq;
- if (tscadc_dev-dev-platform_data)
- err = titsc_parse_pdata(tscadc_dev, ts_dev);
- else
- err = titsc_parse_dt(pdev, ts_dev);
-
+ err = titsc_parse_dt(pdev, ts_dev);
if (err) {
dev_err(pdev-dev, Could not find valid DT data.\n);
goto err_free_mem;
--
1.7.10.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
Re: [PATCH v3] ARM: DTS: TWL4030: fix mux and wakeup for SYS_NIRQ line
On 6/10/2013 6:40 PM, Kevin Hilman wrote: Benoit Cousson b-cous...@ti.com writes: Hi Kevin, On 06/07/2013 09:31 PM, Nishanth Menon wrote: On 11:31-20130607, Kevin Hilman wrote: On most OMAP3 platforms, the twl4030 IRQ line is connected to the SYS_NIRQ line on OMAP. Add another DTS include file (twl4030_omap3.dtsi) for boards that hook up the twl4030 this way to include. This allows RTC wake from off-mode to work again on OMAP3-based platforms with twl4030. Tested on 3530/Beagle, 3730/Beagle-xM, 3530/Overo, 3730/Overo-STORM. Special thanks to Florian Vaussard for suggesting use of preprocessor feature. Cc: Florian Vaussard florian.vauss...@epfl.ch Cc: Benoit Cousson b-cous...@ti.com Cc: Nishanth Menon n...@ti.com Signed-off-by: Kevin Hilman khil...@linaro.org Thanks, Reviewed-by: Nishanth Menon n...@ti.com Thanks, I've just applied it in for_3.11/dts. Thanks, Will you apply the first 2 from the series too? ARM: DTS: OMAP3: beagle/overo: mux console UART, enable wakeup ARM: DTS: OMAP3: beagle: enable user button via gpio_keys, enable wakeup Thanks for the reminder, I kind of forgot these ones :-) Benoit -- 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 09/22] iio/ti_am335x_adc: remove platform_data support
This patch removes access to platform data mfd_tscadc_board because the
platform is DT only.
Acked-by: Jonathan Cameron ji...@kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/iio/adc/ti_am335x_adc.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index b24402c..2868c0c 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -26,7 +26,6 @@
#include linux/of_device.h
#include linux/mfd/ti_am335x_tscadc.h
-#include linux/platform_data/ti_am335x_adc.h
struct tiadc_device {
struct ti_tscadc_dev *mfd_tscadc;
@@ -153,14 +152,12 @@ static int tiadc_probe(struct platform_device *pdev)
{
struct iio_dev *indio_dev;
struct tiadc_device *adc_dev;
- struct ti_tscadc_dev*tscadc_dev = ti_tscadc_dev_get(pdev);
- struct mfd_tscadc_board *pdata = tscadc_dev-dev-platform_data;
struct device_node *node = pdev-dev.of_node;
int err;
u32 val32;
- if (!pdata !node) {
- dev_err(pdev-dev, Could not find platform data\n);
+ if (!node) {
+ dev_err(pdev-dev, Could not find valid DT data.\n);
return -EINVAL;
}
@@ -174,15 +171,11 @@ static int tiadc_probe(struct platform_device *pdev)
adc_dev-mfd_tscadc = ti_tscadc_dev_get(pdev);
- if (pdata)
- adc_dev-channels = pdata-adc_init-adc_channels;
- else {
- err = of_property_read_u32(node,
- ti,adc-channels, val32);
- if (err 0)
- goto err_free_device;
- adc_dev-channels = val32;
- }
+ err = of_property_read_u32(node,
+ ti,adc-channels, val32);
+ if (err 0)
+ goto err_free_device;
+ adc_dev-channels = val32;
indio_dev-dev.parent = pdev-dev;
indio_dev-name = dev_name(pdev-dev);
--
1.7.10.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 05/22] input/ti_am33x_tsc: remove unwanted fifo flush
From: Patil, Rachna rac...@ti.com
When touchscreen and ADC are used together, this
unwanted fifo flush leads to loss of ADC data.
Signed-off-by: Patil, Rachna rac...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/input/touchscreen/ti_am335x_tsc.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 56c6220..b2f8a46 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -252,8 +252,6 @@ static irqreturn_t titsc_irq(int irq, void *dev)
unsigned int x = 0, y = 0;
unsigned int z1, z2, z;
unsigned int fsm;
- unsigned int fifo1count, fifo0count;
- int i;
status = titsc_readl(ts_dev, REG_IRQSTATUS);
if (status IRQENB_FIFO0THRES) {
@@ -262,14 +260,6 @@ static irqreturn_t titsc_irq(int irq, void *dev)
z1 = titsc_readl(ts_dev, REG_FIFO0) 0xfff;
z2 = titsc_readl(ts_dev, REG_FIFO1) 0xfff;
- fifo1count = titsc_readl(ts_dev, REG_FIFO1CNT);
- for (i = 0; i fifo1count; i++)
- titsc_readl(ts_dev, REG_FIFO1);
-
- fifo0count = titsc_readl(ts_dev, REG_FIFO0CNT);
- for (i = 0; i fifo0count; i++)
- titsc_readl(ts_dev, REG_FIFO0);
-
if (ts_dev-pen_down z1 != 0 z2 != 0) {
/*
* Calculate pressure using formula
--
1.7.10.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 02/22] mfd input iio/ti_am335x_adc: use one structure for ti_tscadc_dev
The mfd driver creates platform data for the child devices and it is the
ti_tscadc_dev struct. This struct is copied for the two devices.
The copy of the structure makes a common lock in this structure a little
less usefull. Therefore the platform data is not a pointer to the
structure and the same structure is used.
While doing the change I noticed that the suspend/resume code assumes
the wrong pointer for ti_tscadc_dev and this has been fixed as well.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/iio/adc/ti_am335x_adc.c |5 +++--
drivers/input/touchscreen/ti_am335x_tsc.c | 16 +---
drivers/mfd/ti_am335x_tscadc.c|8
include/linux/mfd/ti_am335x_tscadc.h |7 +++
4 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 5f9a7e7..9db352e 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -140,7 +140,7 @@ static int tiadc_probe(struct platform_device *pdev)
{
struct iio_dev *indio_dev;
struct tiadc_device *adc_dev;
- struct ti_tscadc_dev*tscadc_dev = pdev-dev.platform_data;
+ struct ti_tscadc_dev*tscadc_dev = ti_tscadc_dev_get(pdev);
struct mfd_tscadc_board *pdata;
int err;
@@ -205,9 +205,10 @@ static int tiadc_suspend(struct device *dev)
{
struct iio_dev *indio_dev = dev_get_drvdata(dev);
struct tiadc_device *adc_dev = iio_priv(indio_dev);
- struct ti_tscadc_dev *tscadc_dev = dev-platform_data;
+ struct ti_tscadc_dev *tscadc_dev;
unsigned int idle;
+ tscadc_dev = ti_tscadc_dev_get(to_platform_device(dev));
if (!device_may_wakeup(tscadc_dev-dev)) {
idle = tiadc_readl(adc_dev, REG_CTRL);
idle = ~(CNTRLREG_TSCSSENB);
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 51e7b87..16077d3 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -262,7 +262,7 @@ static int titsc_probe(struct platform_device *pdev)
{
struct titsc *ts_dev;
struct input_dev *input_dev;
- struct ti_tscadc_dev *tscadc_dev = pdev-dev.platform_data;
+ struct ti_tscadc_dev *tscadc_dev = ti_tscadc_dev_get(pdev);
struct mfd_tscadc_board *pdata;
int err;
@@ -329,8 +329,8 @@ static int titsc_probe(struct platform_device *pdev)
static int titsc_remove(struct platform_device *pdev)
{
- struct ti_tscadc_dev *tscadc_dev = pdev-dev.platform_data;
- struct titsc *ts_dev = tscadc_dev-tsc;
+ struct titsc *ts_dev = platform_get_drvdata(pdev);
+ u32 steps;
free_irq(ts_dev-irq, ts_dev);
@@ -344,10 +344,11 @@ static int titsc_remove(struct platform_device *pdev)
#ifdef CONFIG_PM
static int titsc_suspend(struct device *dev)
{
- struct ti_tscadc_dev *tscadc_dev = dev-platform_data;
- struct titsc *ts_dev = tscadc_dev-tsc;
+ struct titsc *ts_dev = dev_get_drvdata(dev);
+ struct ti_tscadc_dev *tscadc_dev;
unsigned int idle;
+ tscadc_dev = ti_tscadc_dev_get(to_platform_device(dev));
if (device_may_wakeup(tscadc_dev-dev)) {
idle = titsc_readl(ts_dev, REG_IRQENABLE);
titsc_writel(ts_dev, REG_IRQENABLE,
@@ -359,9 +360,10 @@ static int titsc_suspend(struct device *dev)
static int titsc_resume(struct device *dev)
{
- struct ti_tscadc_dev *tscadc_dev = dev-platform_data;
- struct titsc *ts_dev = tscadc_dev-tsc;
+ struct titsc *ts_dev = dev_get_drvdata(dev);
+ struct ti_tscadc_dev *tscadc_dev;
+ tscadc_dev = ti_tscadc_dev_get(to_platform_device(dev));
if (device_may_wakeup(tscadc_dev-dev)) {
titsc_writel(ts_dev, REG_IRQWAKEUP,
0x00);
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index 804e61e..490b2bd 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -157,14 +157,14 @@ staticint ti_tscadc_probe(struct platform_device
*pdev)
/* TSC Cell */
cell = tscadc-cells[TSC_CELL];
cell-name = tsc;
- cell-platform_data = tscadc;
- cell-pdata_size = sizeof(*tscadc);
+ cell-platform_data = tscadc;
+ cell-pdata_size = sizeof(tscadc);
/* ADC Cell */
cell = tscadc-cells[ADC_CELL];
cell-name = tiadc;
- cell-platform_data = tscadc;
- cell-pdata_size = sizeof(*tscadc);
+ cell-platform_data = tscadc;
+ cell-pdata_size = sizeof(tscadc);
err = mfd_add_devices(pdev-dev, pdev-id, tscadc-cells,
TSCADC_CELLS, NULL, 0, NULL);
diff --git a/include/linux/mfd/ti_am335x_tscadc.h
b/include/linux/mfd/ti_am335x_tscadc.h
index dc75c34..5e430fe 100644
---
[PATCH 04/22] input/ti_am33x_tsc: Order of TSC wires, made configurable
From: Patil, Rachna rac...@ti.com
The current driver expected touchscreen input
wires(XP,XN,YP,YN) to be connected in a particular order.
Making changes to accept this as platform data.
Signed-off-by: Patil, Rachna rac...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
[bigeasy: larger rework of the patch, no config[4][4] array, smaller
sized config_inp, no regbit_map(), shrinked
titsc_config_wires(), no config redo on resume, config_inp and
friends are now u32]
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/input/touchscreen/ti_am335x_tsc.c | 102 -
include/linux/input/ti_am335x_tsc.h | 12
include/linux/mfd/ti_am335x_tscadc.h | 10 ++-
3 files changed, 105 insertions(+), 19 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 23d6a4d..56c6220 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -33,6 +33,13 @@
#define SEQ_SETTLE 275
#define MAX_12BIT ((1 12) - 1)
+static const int config_pins[] = {
+ XPP,
+ XNN,
+ YPP,
+ YNN,
+};
+
struct titsc {
struct input_dev*input;
struct ti_tscadc_dev*mfd_tscadc;
@@ -41,6 +48,9 @@ struct titsc {
unsigned intx_plate_resistance;
boolpen_down;
int steps_to_configure;
+ u32 config_inp[4];
+ u32 bit_xp, bit_xn, bit_yp, bit_yn;
+ u32 inp_xp, inp_xn, inp_yp, inp_yn;
};
static unsigned int titsc_readl(struct titsc *ts, unsigned int reg)
@@ -54,6 +64,58 @@ static void titsc_writel(struct titsc *tsc, unsigned int reg,
writel(val, tsc-mfd_tscadc-tscadc_base + reg);
}
+static int titsc_config_wires(struct titsc *ts_dev)
+{
+ u32 analog_line[4];
+ u32 wire_order[4];
+ int i, bit_cfg;
+
+ for (i = 0; i 4; i++) {
+ /*
+* Get the order in which TSC wires are attached
+* w.r.t. each of the analog input lines on the EVM.
+*/
+ analog_line[i] = (ts_dev-config_inp[i] 0xF0) 4;
+ wire_order[i] = ts_dev-config_inp[i] 0x0F;
+ if (WARN_ON(analog_line[i] 7))
+ return -EINVAL;
+ if (WARN_ON(wire_order[i] ARRAY_SIZE(config_pins)))
+ return -EINVAL;
+ }
+
+ for (i = 0; i 4; i++) {
+ int an_line;
+ int wi_order;
+
+ an_line = analog_line[i];
+ wi_order = wire_order[i];
+ bit_cfg = config_pins[wi_order];
+ if (bit_cfg == 0)
+ return -EINVAL;
+ switch (wi_order) {
+ case 0:
+ ts_dev-bit_xp = bit_cfg;
+ ts_dev-inp_xp = an_line;
+ break;
+
+ case 1:
+ ts_dev-bit_xn = bit_cfg;
+ ts_dev-inp_xn = an_line;
+ break;
+
+ case 2:
+ ts_dev-bit_yp = bit_cfg;
+ ts_dev-inp_yp = an_line;
+ break;
+ case 3:
+ ts_dev-bit_yn = bit_cfg;
+ ts_dev-inp_yn = an_line;
+ break;
+ }
+ }
+ return 0;
+}
+
static void titsc_step_config(struct titsc *ts_dev)
{
unsigned intconfig;
@@ -64,18 +126,18 @@ static void titsc_step_config(struct titsc *ts_dev)
total_steps = 2 * ts_dev-steps_to_configure;
config = STEPCONFIG_MODE_HWSYNC |
- STEPCONFIG_AVG_16 | STEPCONFIG_XPP;
+ STEPCONFIG_AVG_16 | ts_dev-bit_xp;
switch (ts_dev-wires) {
case 4:
- config |= STEPCONFIG_INP_AN2 | STEPCONFIG_XNN;
+ config |= STEPCONFIG_INP(ts_dev-inp_yp) | ts_dev-bit_xn;
break;
case 5:
- config |= STEPCONFIG_YNN |
- STEPCONFIG_INP_AN4 | STEPCONFIG_XNN |
- STEPCONFIG_YPP;
+ config |= ts_dev-bit_yn |
+ STEPCONFIG_INP_AN4 | ts_dev-bit_xn |
+ ts_dev-bit_yp;
break;
case 8:
- config |= STEPCONFIG_INP_AN2 | STEPCONFIG_XNN;
+ config |= STEPCONFIG_INP(ts_dev-inp_yp) | ts_dev-bit_xn;
break;
}
@@ -86,18 +148,18 @@ static void titsc_step_config(struct titsc *ts_dev)
config = 0;
config = STEPCONFIG_MODE_HWSYNC |
- STEPCONFIG_AVG_16 | STEPCONFIG_YNN |
+ STEPCONFIG_AVG_16 | ts_dev-bit_yn |
[PATCH 03/22] input/ti_am33x_tsc: Step enable bits made configurable
From: Patil, Rachna rac...@ti.com
Current code has hard coded value written to
step enable bits. Now the bits are updated based
on how many steps are needed to be configured got
from platform data.
The user needs to take care not to exceed
the count more than 16. While using ADC and TSC
one should take care to set this parameter correctly.
Signed-off-by: Patil, Rachna rac...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
[bigeasy: add lock, move to MFD, use in TSC ADC]
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/iio/adc/ti_am335x_adc.c | 20 ++--
drivers/input/touchscreen/ti_am335x_tsc.c | 12 ++--
drivers/mfd/ti_am335x_tscadc.c| 29 -
include/linux/mfd/ti_am335x_tscadc.h |8 ++--
4 files changed, 62 insertions(+), 7 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 9db352e..543b9c4 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -42,10 +42,20 @@ static void tiadc_writel(struct tiadc_device *adc, unsigned
int reg,
writel(val, adc-mfd_tscadc-tscadc_base + reg);
}
+static u32 get_adc_step_mask(struct tiadc_device *adc_dev)
+{
+ u32 step_en;
+
+ step_en = ((1 adc_dev-channels) - 1);
+ step_en = TOTAL_STEPS - adc_dev-channels + 1;
+ return step_en;
+}
+
static void tiadc_step_config(struct tiadc_device *adc_dev)
{
unsigned int stepconfig;
int i, channels = 0, steps;
+ u32 step_en;
/*
* There are 16 configurable steps and 8 analog input
@@ -69,7 +79,8 @@ static void tiadc_step_config(struct tiadc_device *adc_dev)
STEPCONFIG_OPENDLY);
channels++;
}
- tiadc_writel(adc_dev, REG_SE, STPENB_STEPENB);
+ step_en = get_adc_step_mask(adc_dev);
+ am335x_tsc_se_set(adc_dev-mfd_tscadc, step_en);
}
static int tiadc_channel_init(struct iio_dev *indio_dev, int channels)
@@ -127,7 +138,7 @@ static int tiadc_read_raw(struct iio_dev *indio_dev,
if (i == chan-channel)
*val = readx1 0xfff;
}
- tiadc_writel(adc_dev, REG_SE, STPENB_STEPENB);
+ am335x_tsc_se_update(adc_dev-mfd_tscadc);
return IIO_VAL_INT;
}
@@ -191,10 +202,15 @@ static int tiadc_probe(struct platform_device *pdev)
static int tiadc_remove(struct platform_device *pdev)
{
struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+ struct tiadc_device *adc_dev = iio_priv(indio_dev);
+ u32 step_en;
iio_device_unregister(indio_dev);
tiadc_channels_remove(indio_dev);
+ step_en = get_adc_step_mask(adc_dev);
+ am335x_tsc_se_clr(adc_dev-mfd_tscadc, step_en);
+
iio_device_free(indio_dev);
return 0;
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 16077d3..23d6a4d 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -57,6 +57,7 @@ static void titsc_writel(struct titsc *tsc, unsigned int reg,
static void titsc_step_config(struct titsc *ts_dev)
{
unsigned intconfig;
+ unsigned intstepenable = 0;
int i, total_steps;
/* Configure the Step registers */
@@ -128,7 +129,9 @@ static void titsc_step_config(struct titsc *ts_dev)
titsc_writel(ts_dev, REG_STEPDELAY(total_steps + 2),
STEPCONFIG_OPENDLY);
- titsc_writel(ts_dev, REG_SE, STPENB_STEPENB_TC);
+ /* The steps1 … end and bit 0 for TS_Charge */
+ stepenable = (1 (total_steps + 2)) - 1;
+ am335x_tsc_se_set(ts_dev-mfd_tscadc, stepenable);
}
static void titsc_read_coordinates(struct titsc *ts_dev,
@@ -250,7 +253,7 @@ static irqreturn_t titsc_irq(int irq, void *dev)
titsc_writel(ts_dev, REG_IRQSTATUS, irqclr);
- titsc_writel(ts_dev, REG_SE, STPENB_STEPENB_TC);
+ am335x_tsc_se_update(ts_dev-mfd_tscadc);
return IRQ_HANDLED;
}
@@ -334,6 +337,11 @@ static int titsc_remove(struct platform_device *pdev)
free_irq(ts_dev-irq, ts_dev);
+ /* total steps followed by the enable mask */
+ steps = 2 * ts_dev-steps_to_configure + 2;
+ steps = (1 steps) - 1;
+ am335x_tsc_se_clr(ts_dev-mfd_tscadc, steps);
+
input_unregister_device(ts_dev-input);
platform_set_drvdata(pdev, NULL);
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index 490b2bd..7b091c4 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -37,6 +37,32 @@ static void tscadc_writel(struct ti_tscadc_dev *tsadc,
unsigned int reg,
writel(val, tsadc-tscadc_base + reg);
}
+void am335x_tsc_se_update(struct ti_tscadc_dev *tsadc)
+{
+ tscadc_writel(tsadc, REG_SE, tsadc-reg_se_cache);
+}
am335x: TSC ADC reworking including DT pieces, take 4
I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. I added Lee Jones because I hear no sign of life from Samuel. 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://breakpoint.cc/bigeasy/linux tags/am335x_tsc-adc for you to fetch changes up to fe12425dd7e93db2dfdfa4eb9289036100cb0338: iio/ti_am335x_adc: check if we found the value (2013-06-11 13:11:35 +0200) A complete refurbished series inclunding: - DT support for the MFD, TSC and ADC driver platform device support, which has no users, has been killed. - iio_map from last series is gone and replaced by proper nodes in the device tree. - suspend fixes which means correct data structs are taken and no interrupt storm - fifo split which should problem with TSC ADC beeing used at the same time - The ADC channels are now checked before blindly applied. That means the touch part reads X, Y and Z coordinates and does not mix them up. Same goes for the IIO ADC driver. - The IIO ADC driver now creates files named in_voltageX_raw where X represents the ADC line instead of a number starting at 0. A read from this file can return -EBUSY in case touch is busy and the ADC didn't collect a value. Pantelis Antoniou (2): iio/ti_tscadc: provide datasheet_name and scan_type mfd/ti_tscadc: deal with partial activation Patil, Rachna (7): input/ti_am33x_tsc: Step enable bits made configurable input/ti_am33x_tsc: Order of TSC wires, made configurable input/ti_am33x_tsc: remove unwanted fifo flush input/ti_am33x_tsc: Add DT support iio/ti_am335x_adc: Add DT support mfd/ti_am335x_tscadc: Add DT support arm/am33xx: add TSC/ADC mfd device support Sebastian Andrzej Siewior (13): mfd/ti_am335x_tscadc: remove regmap mfd input iio/ti_am335x_adc: use one structure for ti_tscadc_dev input/ti_am33x_tsc: remove platform_data support iio/ti_am335x_adc: remove platform_data support mfd/ti_am335x_tscadc: remove platform_data support input mfd: ti_am335x_tsc remove remaining platform data pieces mfd input/ti_am335x_tsc: rename device from tsc to TI-am335x-tsc mfd iio/ti_am335x_adc: rename device from tiadc to TI-am335x-adc input/ti_am335x_adc: use only FIFO0 and clean up a little input/ti_am335x_tsc: ACK the HW_PEN irq in ISR input/ti_am335x_tsc: return IRQ_NONE if there was no IRQ for us iio/ti_am335x_adc: Allow to specify input line iio/ti_am335x_adc: check if we found the value .../bindings/input/touchscreen/ti-tsc-adc.txt | 44 +++ arch/arm/boot/dts/am335x-evm.dts | 14 + arch/arm/boot/dts/am33xx.dtsi | 18 ++ drivers/iio/adc/ti_am335x_adc.c| 132 ++--- drivers/input/touchscreen/ti_am335x_tsc.c | 288 ++-- drivers/mfd/ti_am335x_tscadc.c | 133 ++--- include/linux/input/ti_am335x_tsc.h| 23 -- include/linux/mfd/ti_am335x_tscadc.h | 43 +-- include/linux/platform_data/ti_am335x_adc.h| 14 - 9 files changed, 494 insertions(+), 215 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt delete mode 100644 include/linux/input/ti_am335x_tsc.h delete mode 100644 include/linux/platform_data/ti_am335x_adc.h Sebastian -- 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 22/22] iio/ti_am335x_adc: check if we found the value
Usually we get all the values we wanted but it is possible, that te ADC
unit is busy performing the conversation for the HW events. In that case
-EBUSY is returned and the user may re-call the function.
Acked-by: Jonathan Cameron ji...@kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/iio/adc/ti_am335x_adc.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 8ffe52d..4427e8e 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -145,6 +145,7 @@ static int tiadc_read_raw(struct iio_dev *indio_dev,
int i;
unsigned int fifo1count, read;
u32 step = UINT_MAX;
+ bool found = false;
/*
* When the sub-system is first enabled,
@@ -169,11 +170,14 @@ static int tiadc_read_raw(struct iio_dev *indio_dev,
fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
for (i = 0; i fifo1count; i++) {
read = tiadc_readl(adc_dev, REG_FIFO1);
- if (read 16 == step)
+ if (read 16 == step) {
*val = read 0xfff;
+ found = true;
+ }
}
am335x_tsc_se_update(adc_dev-mfd_tscadc);
-
+ if (found == false)
+ return -EBUSY;
return IIO_VAL_INT;
}
--
1.7.10.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 17/22] mfd iio/ti_am335x_adc: rename device from tiadc to TI-am335x-adc
TI-adc reads a little better compared to tiadc. And if we add am335x to
it then we have the same naming scheme as the tsc side.
Acked-by: Jonathan Cameron ji...@kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/iio/adc/ti_am335x_adc.c |3 +--
drivers/mfd/ti_am335x_tscadc.c |2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 9939810..4bec91e 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -292,7 +292,7 @@ MODULE_DEVICE_TABLE(of, ti_adc_dt_ids);
static struct platform_driver tiadc_driver = {
.driver = {
- .name = tiadc,
+ .name = TI-am335x-adc,
.owner = THIS_MODULE,
.pm = TIADC_PM_OPS,
.of_match_table = of_match_ptr(ti_adc_dt_ids),
@@ -300,7 +300,6 @@ static struct platform_driver tiadc_driver = {
.probe = tiadc_probe,
.remove = tiadc_remove,
};
-
module_platform_driver(tiadc_driver);
MODULE_DESCRIPTION(TI ADC controller driver);
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index bf33134..d3f48d2 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -204,7 +204,7 @@ static int ti_tscadc_probe(struct platform_device
*pdev)
if (adc_channels 0) {
tscadc-adc_cell = tscadc-used_cells;
cell = tscadc-cells[tscadc-used_cells++];
- cell-name = tiadc;
+ cell-name = TI-am335x-adc;
cell-of_compatible = ti,am3359-adc;
cell-platform_data = tscadc;
cell-pdata_size = sizeof(tscadc);
--
1.7.10.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 14/22] arm/am33xx: add TSC/ADC mfd device support
From: Patil, Rachna rac...@ti.com
Add support for core multifunctional device along
with its clients touchscreen and ADC.
[ pa...@antoniou-consulting.com : make sure status is
set to 'disabled' in dtsi file. ]
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Signed-off-by: Patil, Rachna rac...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
[bigeasy: add 'status = okay']
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
arch/arm/boot/dts/am335x-evm.dts | 14 ++
arch/arm/boot/dts/am33xx.dtsi| 18 ++
2 files changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 0423298..26fea97 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -244,3 +244,17 @@
cpsw_emac1 {
phy_id = davinci_mdio, 1;
};
+
+tscadc {
+ status = okay;
+ tsc {
+ ti,wires = 4;
+ ti,x-plate-resistance = 200;
+ ti,coordiante-readouts = 5;
+ ti,wire-config = 0x00 0x11 0x22 0x33;
+ };
+
+ adc {
+ ti,adc-channels = 4;
+ };
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 1460d9b..4ad7797 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -404,6 +404,24 @@
ti,hwmods = wkup_m3;
};
+ tscadc: tscadc@44e0d000 {
+ compatible = ti,am3359-tscadc;
+ reg = 0x44e0d000 0x1000;
+ interrupt-parent = intc;
+ interrupts = 16;
+ ti,hwmods = adc_tsc;
+ status = disabled;
+
+ tsc {
+ compatible = ti,am3359-tsc;
+ };
+ am335x_adc: adc {
+ #io-channel-cells = 1;
+ compatible = ti,am3359-adc;
+ };
+
+ };
+
gpmc: gpmc@5000 {
compatible = ti,am3352-gpmc;
ti,hwmods = gpmc;
--
1.7.10.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 11/22] mfd/ti_am335x_tscadc: remove platform_data support
This patch removes access to platform data mfd_tscadc_board because the
platform is DT only.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/mfd/ti_am335x_tscadc.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index aae5e55..f9ad26f 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -25,8 +25,6 @@
#include linux/of_device.h
#include linux/mfd/ti_am335x_tscadc.h
-#include linux/input/ti_am335x_tsc.h
-#include linux/platform_data/ti_am335x_adc.h
static unsigned int tscadc_readl(struct ti_tscadc_dev *tsadc, unsigned int reg)
{
@@ -80,31 +78,22 @@ static int ti_tscadc_probe(struct platform_device
*pdev)
struct ti_tscadc_dev*tscadc;
struct resource *res;
struct clk *clk;
- struct mfd_tscadc_board *pdata = pdev-dev.platform_data;
struct device_node *node = pdev-dev.of_node;
struct mfd_cell *cell;
int err, ctrl;
int clk_value, clock_rate;
int tsc_wires = 0, adc_channels = 0, total_channels;
- if (!pdata !pdev-dev.of_node) {
- dev_err(pdev-dev, Could not find platform data\n);
+ if (!pdev-dev.of_node) {
+ dev_err(pdev-dev, Could not find valid DT data.\n);
return -EINVAL;
}
- if (pdev-dev.platform_data) {
- if (pdata-tsc_init)
- tsc_wires = pdata-tsc_init-wires;
+ node = of_get_child_by_name(pdev-dev.of_node, tsc);
+ of_property_read_u32(node, ti,wires, tsc_wires);
- if (pdata-adc_init)
- adc_channels = pdata-adc_init-adc_channels;
- } else {
- node = of_get_child_by_name(pdev-dev.of_node, tsc);
- of_property_read_u32(node, ti,wires, tsc_wires);
-
- node = of_get_child_by_name(pdev-dev.of_node, adc);
- of_property_read_u32(node, ti,adc-channels, adc_channels);
- }
+ node = of_get_child_by_name(pdev-dev.of_node, adc);
+ of_property_read_u32(node, ti,adc-channels, adc_channels);
total_channels = tsc_wires + adc_channels;
--
1.7.10.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
Re: [PATCH v3] ARM: DTS: TWL4030: fix mux and wakeup for SYS_NIRQ line
On 06/11/2013 01:33 PM, Cousson, Benoit wrote: On 6/10/2013 6:40 PM, Kevin Hilman wrote: Benoit Cousson b-cous...@ti.com writes: Hi Kevin, On 06/07/2013 09:31 PM, Nishanth Menon wrote: On 11:31-20130607, Kevin Hilman wrote: On most OMAP3 platforms, the twl4030 IRQ line is connected to the SYS_NIRQ line on OMAP. Add another DTS include file (twl4030_omap3.dtsi) for boards that hook up the twl4030 this way to include. This allows RTC wake from off-mode to work again on OMAP3-based platforms with twl4030. Tested on 3530/Beagle, 3730/Beagle-xM, 3530/Overo, 3730/Overo-STORM. Special thanks to Florian Vaussard for suggesting use of preprocessor feature. Cc: Florian Vaussard florian.vauss...@epfl.ch Cc: Benoit Cousson b-cous...@ti.com Cc: Nishanth Menon n...@ti.com Signed-off-by: Kevin Hilman khil...@linaro.org Thanks, Reviewed-by: Nishanth Menon n...@ti.com Thanks, I've just applied it in for_3.11/dts. Thanks, Will you apply the first 2 from the series too? ARM: DTS: OMAP3: beagle/overo: mux console UART, enable wakeup ARM: DTS: OMAP3: beagle: enable user button via gpio_keys, enable wakeup Thanks for the reminder, I kind of forgot these ones :-) BTW, do you have any v2 for these ones? This version does not use the macros. Moreover I cannot apply them on top of Florian's series :-( Regards, Benoit -- 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 12/22] iio/ti_tscadc: provide datasheet_name and scan_type
From: Pantelis Antoniou pa...@antoniou-consulting.com
This patch provides the members datasheet_name and scan_type. This is
the remaining part of the earlier patch where I (bigeasy) removed iio_map
because it is now supplied by the device tree.
Acked-by: Jonathan Cameron ji...@kernel.org
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Signed-off-by: Felipe Balbi ba...@ti.com
[bigeasy: use static AIN[0-8] names, use kcalloc(), removed iio_map,
patch description]
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/iio/adc/ti_am335x_adc.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 2868c0c..9939810 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -24,6 +24,8 @@
#include linux/iio/iio.h
#include linux/of.h
#include linux/of_device.h
+#include linux/iio/machine.h
+#include linux/iio/driver.h
#include linux/mfd/ti_am335x_tscadc.h
@@ -84,29 +86,46 @@ static void tiadc_step_config(struct tiadc_device *adc_dev)
am335x_tsc_se_set(adc_dev-mfd_tscadc, step_en);
}
+static const char * const chan_name_ain[] = {
+ AIN0,
+ AIN1,
+ AIN2,
+ AIN3,
+ AIN4,
+ AIN5,
+ AIN6,
+ AIN7,
+};
+
static int tiadc_channel_init(struct iio_dev *indio_dev, int channels)
{
+ struct tiadc_device *adc_dev = iio_priv(indio_dev);
struct iio_chan_spec *chan_array;
+ struct iio_chan_spec *chan;
int i;
indio_dev-num_channels = channels;
- chan_array = kcalloc(indio_dev-num_channels,
+ chan_array = kcalloc(channels,
sizeof(struct iio_chan_spec), GFP_KERNEL);
-
if (chan_array == NULL)
return -ENOMEM;
- for (i = 0; i (indio_dev-num_channels); i++) {
- struct iio_chan_spec *chan = chan_array + i;
+ chan = chan_array;
+ for (i = 0; i channels; i++, chan++) {
+
chan-type = IIO_VOLTAGE;
chan-indexed = 1;
chan-channel = i;
chan-info_mask_separate = BIT(IIO_CHAN_INFO_RAW);
+ chan-datasheet_name = chan_name_ain[i];
+ chan-scan_type.sign = 'u';
+ chan-scan_type.realbits = 12;
+ chan-scan_type.storagebits = 32;
}
indio_dev-channels = chan_array;
- return indio_dev-num_channels;
+ return 0;
}
static void tiadc_channels_remove(struct iio_dev *indio_dev)
--
1.7.10.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 13/22] mfd/ti_tscadc: deal with partial activation
From: Pantelis Antoniou pa...@antoniou-consulting.com
Fix the mfd device in the case where a subdevice might not be activated.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Signed-off-by: Felipe Balbi ba...@ti.com
[bigeasy: split out this chunk from the orignal patch, check for neither
ADC nor TSC channels]
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/mfd/ti_am335x_tscadc.c | 38 ++
include/linux/mfd/ti_am335x_tscadc.h |8 +++
2 files changed, 28 insertions(+), 18 deletions(-)
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index f9ad26f..74e4694 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -96,11 +96,14 @@ static int ti_tscadc_probe(struct platform_device
*pdev)
of_property_read_u32(node, ti,adc-channels, adc_channels);
total_channels = tsc_wires + adc_channels;
-
if (total_channels 8) {
dev_err(pdev-dev, Number of i/p channels more than 8\n);
return -EINVAL;
}
+ if (total_channels == 0) {
+ dev_err(pdev-dev, Need atleast one channel.\n);
+ return -EINVAL;
+ }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
@@ -183,28 +186,37 @@ staticint ti_tscadc_probe(struct platform_device
*pdev)
ctrl |= CNTRLREG_TSCSSENB;
tscadc_writel(tscadc, REG_CTRL, ctrl);
+ tscadc-used_cells = 0;
+ tscadc-tsc_cell = -1;
+ tscadc-adc_cell = -1;
+
/* TSC Cell */
- cell = tscadc-cells[TSC_CELL];
- cell-name = tsc;
- cell-of_compatible = ti,am3359-tsc;
- cell-platform_data = tscadc;
- cell-pdata_size = sizeof(tscadc);
+ if (tsc_wires 0) {
+ tscadc-tsc_cell = tscadc-used_cells;
+ cell = tscadc-cells[tscadc-used_cells++];
+ cell-name = tsc;
+ cell-of_compatible = ti,am3359-tsc;
+ cell-platform_data = tscadc;
+ cell-pdata_size = sizeof(tscadc);
+ }
/* ADC Cell */
- cell = tscadc-cells[ADC_CELL];
- cell-name = tiadc;
- cell-of_compatible = ti,am3359-adc;
- cell-platform_data = tscadc;
- cell-pdata_size = sizeof(tscadc);
+ if (adc_channels 0) {
+ tscadc-adc_cell = tscadc-used_cells;
+ cell = tscadc-cells[tscadc-used_cells++];
+ cell-name = tiadc;
+ cell-of_compatible = ti,am3359-adc;
+ cell-platform_data = tscadc;
+ cell-pdata_size = sizeof(tscadc);
+ }
err = mfd_add_devices(pdev-dev, pdev-id, tscadc-cells,
- TSCADC_CELLS, NULL, 0, NULL);
+ tscadc-used_cells, NULL, 0, NULL);
if (err 0)
goto err_disable_clk;
device_init_wakeup(pdev-dev, true);
platform_set_drvdata(pdev, tscadc);
-
return 0;
err_disable_clk:
diff --git a/include/linux/mfd/ti_am335x_tscadc.h
b/include/linux/mfd/ti_am335x_tscadc.h
index 2d78af8..b6e7ac6 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -127,11 +127,6 @@
#define TSCADC_CELLS 2
-enum tscadc_cells {
- TSC_CELL,
- ADC_CELL,
-};
-
struct mfd_tscadc_board {
struct tsc_data *tsc_init;
struct adc_data *adc_init;
@@ -141,6 +136,9 @@ struct ti_tscadc_dev {
struct device *dev;
void __iomem *tscadc_base;
int irq;
+ int used_cells; /* 1-2 */
+ int tsc_cell; /* -1 if not used */
+ int adc_cell; /* -1 if not used */
struct mfd_cell cells[TSCADC_CELLS];
u32 reg_se_cache;
spinlock_t reg_lock;
--
1.7.10.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 20/22] input/ti_am335x_tsc: return IRQ_NONE if there was no IRQ for us
The previous patch (input/ti_am335x_tsc: ACK the HW_PEN irq in ISR)
acked the interrupt so we don't freeze if we don't handle an enabled
interrupt source. The interrupt core has a mechanism for this and to get
it work one should only say that it handled an interrupt if it is
actually the case.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/input/touchscreen/ti_am335x_tsc.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 84859da..6327169 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -314,10 +314,12 @@ static irqreturn_t titsc_irq(int irq, void *dev)
titsc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN);
}
- titsc_writel(ts_dev, REG_IRQSTATUS, irqclr);
-
- am335x_tsc_se_update(ts_dev-mfd_tscadc);
- return IRQ_HANDLED;
+ if (irqclr) {
+ titsc_writel(ts_dev, REG_IRQSTATUS, irqclr);
+ am335x_tsc_se_update(ts_dev-mfd_tscadc);
+ return IRQ_HANDLED;
+ }
+ return IRQ_NONE;
}
static int titsc_parse_dt(struct platform_device *pdev,
--
1.7.10.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 10/22] mfd/ti_am335x_tscadc: Add DT support
From: Patil, Rachna rac...@ti.com
Make changes to add DT support in the MFD core driver.
[ pa...@antoniou-consulting.com : use of_get_child_by_name
instead of of_find_node_by_name ]
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Signed-off-by: Patil, Rachna rac...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
[bigeasy: module alias, rename to ti,am3359-tscadc as it was tested on
AM3359]
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/mfd/ti_am335x_tscadc.c | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index eaaa253..aae5e55 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -21,6 +21,8 @@
#include linux/clk.h
#include linux/mfd/core.h
#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_device.h
#include linux/mfd/ti_am335x_tscadc.h
#include linux/input/ti_am335x_tsc.h
@@ -79,20 +81,31 @@ static int ti_tscadc_probe(struct platform_device
*pdev)
struct resource *res;
struct clk *clk;
struct mfd_tscadc_board *pdata = pdev-dev.platform_data;
+ struct device_node *node = pdev-dev.of_node;
struct mfd_cell *cell;
int err, ctrl;
int clk_value, clock_rate;
- int tsc_wires, adc_channels = 0, total_channels;
+ int tsc_wires = 0, adc_channels = 0, total_channels;
- if (!pdata) {
+ if (!pdata !pdev-dev.of_node) {
dev_err(pdev-dev, Could not find platform data\n);
return -EINVAL;
}
- if (pdata-adc_init)
- adc_channels = pdata-adc_init-adc_channels;
+ if (pdev-dev.platform_data) {
+ if (pdata-tsc_init)
+ tsc_wires = pdata-tsc_init-wires;
+
+ if (pdata-adc_init)
+ adc_channels = pdata-adc_init-adc_channels;
+ } else {
+ node = of_get_child_by_name(pdev-dev.of_node, tsc);
+ of_property_read_u32(node, ti,wires, tsc_wires);
+
+ node = of_get_child_by_name(pdev-dev.of_node, adc);
+ of_property_read_u32(node, ti,adc-channels, adc_channels);
+ }
- tsc_wires = pdata-tsc_init-wires;
total_channels = tsc_wires + adc_channels;
if (total_channels 8) {
@@ -266,11 +279,18 @@ static const struct dev_pm_ops tscadc_pm_ops = {
#define TSCADC_PM_OPS NULL
#endif
+static const struct of_device_id ti_tscadc_dt_ids[] = {
+ { .compatible = ti,am3359-tscadc, },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ti_tscadc_dt_ids);
+
static struct platform_driver ti_tscadc_driver = {
.driver = {
- .name = ti_tscadc,
+ .name = ti_am3359-tscadc,
.owner = THIS_MODULE,
.pm = TSCADC_PM_OPS,
+ .of_match_table = of_match_ptr(ti_tscadc_dt_ids),
},
.probe = ti_tscadc_probe,
.remove = ti_tscadc_remove,
--
1.7.10.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 21/22] iio/ti_am335x_adc: Allow to specify input line
The TSC part allows to specify the input lines. The IIO part assumes
that it usues always the last few, that means if IIO has adc-channels
set to 2 it will use channel 6 and 7. However it might make sense to use
only 6.
This patch changes the device property (which was introduced recently
and was never in an official release) in a way that the user can specify
which of the AIN lines should be used. In Addition to this, the name is
now AINx where x is the channel number i.e. for AIN6 we would have 6.
Prior this, it always started counting at 0 which is confusing. In
addition to this, it also checks for correct step number during reading
and does not rely on proper FIFO depth.
Acked-by: Jonathan Cameron ji...@kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/boot/dts/am335x-evm.dts |2 +-
drivers/iio/adc/ti_am335x_adc.c | 57 +-
drivers/mfd/ti_am335x_tscadc.c | 20 +++--
3 files changed, 56 insertions(+), 23 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 26fea97..0fa4c7f 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -255,6 +255,6 @@
};
adc {
- ti,adc-channels = 4;
+ ti,adc-channels = 4 5 6 7;
};
};
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 307a7c0..8ffe52d 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -32,6 +32,8 @@
struct tiadc_device {
struct ti_tscadc_dev *mfd_tscadc;
int channels;
+ u8 channel_line[8];
+ u8 channel_step[8];
};
static unsigned int tiadc_readl(struct tiadc_device *adc, unsigned int reg)
@@ -57,7 +59,7 @@ static u32 get_adc_step_mask(struct tiadc_device *adc_dev)
static void tiadc_step_config(struct tiadc_device *adc_dev)
{
unsigned int stepconfig;
- int i, channels = 0, steps;
+ int i, steps;
u32 step_en;
/*
@@ -71,16 +73,18 @@ static void tiadc_step_config(struct tiadc_device *adc_dev)
*/
steps = TOTAL_STEPS - adc_dev-channels;
- channels = TOTAL_CHANNELS - adc_dev-channels;
-
stepconfig = STEPCONFIG_AVG_16 | STEPCONFIG_FIFO1;
- for (i = steps; i TOTAL_STEPS; i++) {
- tiadc_writel(adc_dev, REG_STEPCONFIG(i),
- stepconfig | STEPCONFIG_INP(channels));
- tiadc_writel(adc_dev, REG_STEPDELAY(i),
+ for (i = 0; i adc_dev-channels; i++) {
+ int chan;
+
+ chan = adc_dev-channel_line[i];
+ tiadc_writel(adc_dev, REG_STEPCONFIG(steps),
+ stepconfig | STEPCONFIG_INP(chan));
+ tiadc_writel(adc_dev, REG_STEPDELAY(steps),
STEPCONFIG_OPENDLY);
- channels++;
+ adc_dev-channel_step[i] = steps;
+ steps++;
}
step_en = get_adc_step_mask(adc_dev);
am335x_tsc_se_set(adc_dev-mfd_tscadc, step_en);
@@ -115,9 +119,9 @@ static int tiadc_channel_init(struct iio_dev *indio_dev,
int channels)
chan-type = IIO_VOLTAGE;
chan-indexed = 1;
- chan-channel = i;
+ chan-channel = adc_dev-channel_line[i];
chan-info_mask_separate = BIT(IIO_CHAN_INFO_RAW);
- chan-datasheet_name = chan_name_ain[i];
+ chan-datasheet_name = chan_name_ain[chan-channel];
chan-scan_type.sign = 'u';
chan-scan_type.realbits = 12;
chan-scan_type.storagebits = 32;
@@ -139,7 +143,8 @@ static int tiadc_read_raw(struct iio_dev *indio_dev,
{
struct tiadc_device *adc_dev = iio_priv(indio_dev);
int i;
- unsigned int fifo1count, readx1;
+ unsigned int fifo1count, read;
+ u32 step = UINT_MAX;
/*
* When the sub-system is first enabled,
@@ -152,11 +157,20 @@ static int tiadc_read_raw(struct iio_dev *indio_dev,
* Hence we need to flush out this data.
*/
+ for (i = 0; i ARRAY_SIZE(adc_dev-channel_step); i++) {
+ if (chan-channel == adc_dev-channel_line[i]) {
+ step = adc_dev-channel_step[i];
+ break;
+ }
+ }
+ if (WARN_ON_ONCE(step == UINT_MAX))
+ return -EINVAL;
+
fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
for (i = 0; i fifo1count; i++) {
- readx1 = tiadc_readl(adc_dev, REG_FIFO1);
- if (i == chan-channel)
- *val = readx1 0xfff;
+ read = tiadc_readl(adc_dev, REG_FIFO1);
+ if (read 16 == step)
+ *val = read 0xfff;
}
am335x_tsc_se_update(adc_dev-mfd_tscadc);
@@ -172,8 +186,11 @@ static int tiadc_probe(struct
[PATCH 18/22] input/ti_am335x_adc: use only FIFO0 and clean up a little
The driver programs a threshold of coordinate_readouts say 5. The
REG_FIFO0THR registers says it should it be programmed to threshold
minus one. The driver does not expect just 5 coordinates but 5 * 2 + 2.
Multiplied by two because 5 for X and 5 for Y and plus 2 because we have
two Z.
The whole thing kind of works because It reads the 5 coordinates for X
and Y from FIFO0 and FIFO1 and the last element in each FIFO is ignored
within the loop and read later.
Nothing guaranties that FIFO1 is ready by the time it is read. In fact I
could see that that FIFO1 reaturns for Y channels 8,9, 10, 12, 6 and for
Y channel 7 for Z. The problem is that channel 7 and channel 12 got
somehow mixed up.
The other Problem is that FIFO1 is also used by the IIO part leading to
wrong results if both (tsc adc) are used.
The patch tries to clean up the whole thing a little:
- Remove the +1 and -1 in REG_STEPCONFIG, REG_STEPDELAY and its counter
part in the for loop. This is just confusing.
- Use only FIFO0 in TSC. The fifo has space for 64 entries so should be
fine.
- Read the whole FIFO in one function and check the channel.
- in case we dawdle around, make sure we only read a multiple of our
coordinate set. On the second interrupt we will cleanup the remaining
enties.
Acked-by: Dmitry Torokhov dmitry.torok...@gmail.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/iio/adc/ti_am335x_adc.c |2 +-
drivers/input/touchscreen/ti_am335x_tsc.c | 78 +++--
include/linux/mfd/ti_am335x_tscadc.h |4 +-
3 files changed, 44 insertions(+), 40 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 4bec91e..307a7c0 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -75,7 +75,7 @@ static void tiadc_step_config(struct tiadc_device *adc_dev)
stepconfig = STEPCONFIG_AVG_16 | STEPCONFIG_FIFO1;
- for (i = (steps + 1); i = TOTAL_STEPS; i++) {
+ for (i = steps; i TOTAL_STEPS; i++) {
tiadc_writel(adc_dev, REG_STEPCONFIG(i),
stepconfig | STEPCONFIG_INP(channels));
tiadc_writel(adc_dev, REG_STEPDELAY(i),
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index d6643cb..29febe9 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -120,11 +120,9 @@ static int titsc_config_wires(struct titsc *ts_dev)
static void titsc_step_config(struct titsc *ts_dev)
{
unsigned intconfig;
- unsigned intstepenable = 0;
- int i, total_steps;
-
- /* Configure the Step registers */
- total_steps = 2 * ts_dev-coordinate_readouts;
+ int i;
+ int end_step;
+ u32 stepenable;
config = STEPCONFIG_MODE_HWSYNC |
STEPCONFIG_AVG_16 | ts_dev-bit_xp;
@@ -142,7 +140,9 @@ static void titsc_step_config(struct titsc *ts_dev)
break;
}
- for (i = 1; i = ts_dev-coordinate_readouts; i++) {
+ /* 1 … coordinate_readouts is for X */
+ end_step = ts_dev-coordinate_readouts;
+ for (i = 0; i end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
@@ -150,7 +150,7 @@ static void titsc_step_config(struct titsc *ts_dev)
config = 0;
config = STEPCONFIG_MODE_HWSYNC |
STEPCONFIG_AVG_16 | ts_dev-bit_yn |
- STEPCONFIG_INM_ADCREFM | STEPCONFIG_FIFO1;
+ STEPCONFIG_INM_ADCREFM;
switch (ts_dev-wires) {
case 4:
config |= ts_dev-bit_yp | STEPCONFIG_INP(ts_dev-inp_xp);
@@ -164,12 +164,13 @@ static void titsc_step_config(struct titsc *ts_dev)
break;
}
- for (i = (ts_dev-coordinate_readouts + 1); i = total_steps; i++) {
+ /* coordinate_readouts … coordinate_readouts * 2 is for Y */
+ end_step = ts_dev-coordinate_readouts * 2;
+ for (i = ts_dev-coordinate_readouts; i end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
- config = 0;
/* Charge step configuration */
config = ts_dev-bit_xp | ts_dev-bit_yn |
STEPCHARGE_RFP_XPUL | STEPCHARGE_RFM_XNUR |
@@ -178,35 +179,39 @@ static void titsc_step_config(struct titsc *ts_dev)
titsc_writel(ts_dev, REG_CHARGECONFIG, config);
titsc_writel(ts_dev, REG_CHARGEDELAY, CHARGEDLY_OPENDLY);
- config = 0;
- /* Configure to calculate pressure */
+ /* coordinate_readouts * 2 … coordinate_readouts * 2 + 2 is for Z */
config = STEPCONFIG_MODE_HWSYNC |
STEPCONFIG_AVG_16 | ts_dev-bit_yp |
[PATCH 15/22] input mfd: ti_am335x_tsc remove remaining platform data pieces
The two header files removed here are unused and have no users as this
platform was never used with platform devices.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
include/linux/input/ti_am335x_tsc.h | 35 ---
include/linux/mfd/ti_am335x_tscadc.h|5
include/linux/platform_data/ti_am335x_adc.h | 14 ---
3 files changed, 54 deletions(-)
delete mode 100644 include/linux/input/ti_am335x_tsc.h
delete mode 100644 include/linux/platform_data/ti_am335x_adc.h
diff --git a/include/linux/input/ti_am335x_tsc.h
b/include/linux/input/ti_am335x_tsc.h
deleted file mode 100644
index 6a66b4d..000
--- a/include/linux/input/ti_am335x_tsc.h
+++ /dev/null
@@ -1,35 +0,0 @@
-#ifndef __LINUX_TI_AM335X_TSC_H
-#define __LINUX_TI_AM335X_TSC_H
-
-/**
- * struct tsc_data Touchscreen wire configuration
- * @wires: Wires refer to application modes
- * i.e. 4/5/8 wire touchscreen support
- * on the platform.
- * @x_plate_resistance:X plate resistance.
- * @steps_to_configure:The sequencer supports a total of
- * 16 programmable steps.
- * A step configured to read a single
- * co-ordinate value, can be applied
- * more number of times for better results.
- * @wire_config: Different EVM's could have a different order
- * for connecting wires on touchscreen.
- * We need to provide an 8 bit number where in
- * the 1st four bits represent the analog lines
- * and the next 4 bits represent positive/
- * negative terminal on that input line.
- * Notations to represent the input lines and
- * terminals resoectively is as follows:
- * AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
- * XP = 0, XN = 1, YP = 2, YN = 3.
- *
- */
-
-struct tsc_data {
- int wires;
- int x_plate_resistance;
- int steps_to_configure;
- int wire_config[10];
-};
-
-#endif
diff --git a/include/linux/mfd/ti_am335x_tscadc.h
b/include/linux/mfd/ti_am335x_tscadc.h
index b6e7ac6..cd8686b 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -127,11 +127,6 @@
#define TSCADC_CELLS 2
-struct mfd_tscadc_board {
- struct tsc_data *tsc_init;
- struct adc_data *adc_init;
-};
-
struct ti_tscadc_dev {
struct device *dev;
void __iomem *tscadc_base;
diff --git a/include/linux/platform_data/ti_am335x_adc.h
b/include/linux/platform_data/ti_am335x_adc.h
deleted file mode 100644
index e41d583..000
--- a/include/linux/platform_data/ti_am335x_adc.h
+++ /dev/null
@@ -1,14 +0,0 @@
-#ifndef __LINUX_TI_AM335X_ADC_H
-#define __LINUX_TI_AM335X_ADC_H
-
-/**
- * struct adc_data ADC Input information
- * @adc_channels: Number of analog inputs
- * available for ADC.
- */
-
-struct adc_data {
- unsigned int adc_channels;
-};
-
-#endif
--
1.7.10.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 19/22] input/ti_am335x_tsc: ACK the HW_PEN irq in ISR
The interrupt source IRQENB_HW_PEN is enabled in suspend and suposed to
be used as a wake up source. Once this interrupt source is unmaksed, the
devices ends up in ISR and never continues.
This change ACKs the interrupt and disables it so the system does not
freeze.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/input/touchscreen/ti_am335x_tsc.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 29febe9..84859da 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -308,6 +308,12 @@ static irqreturn_t titsc_irq(int irq, void *dev)
irqclr |= IRQENB_PENUP;
}
+ if (status IRQENB_HW_PEN) {
+
+ titsc_writel(ts_dev, REG_IRQWAKEUP, 0x00);
+ titsc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN);
+ }
+
titsc_writel(ts_dev, REG_IRQSTATUS, irqclr);
am335x_tsc_se_update(ts_dev-mfd_tscadc);
--
1.7.10.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 16/22] mfd input/ti_am335x_tsc: rename device from tsc to TI-am335x-tsc
tsc is a very generic name. This patch adds a TI and HW prefix to it
less generic.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/input/touchscreen/ti_am335x_tsc.c |2 +-
drivers/mfd/ti_am335x_tscadc.c|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 66c5a26..d6643cb 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -491,7 +491,7 @@ static struct platform_driver ti_tsc_driver = {
.probe = titsc_probe,
.remove = titsc_remove,
.driver = {
- .name = tsc,
+ .name = TI-am335x-tsc,
.owner = THIS_MODULE,
.pm = TITSC_PM_OPS,
.of_match_table = of_match_ptr(ti_tsc_dt_ids),
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index 74e4694..bf33134 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -194,7 +194,7 @@ static int ti_tscadc_probe(struct platform_device
*pdev)
if (tsc_wires 0) {
tscadc-tsc_cell = tscadc-used_cells;
cell = tscadc-cells[tscadc-used_cells++];
- cell-name = tsc;
+ cell-name = TI-am335x-tsc;
cell-of_compatible = ti,am3359-tsc;
cell-platform_data = tscadc;
cell-pdata_size = sizeof(tscadc);
--
1.7.10.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
Re: am335x: TSC ADC reworking including DT pieces, take 4
I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. I added Lee Jones because I hear no sign of life from Samuel. Unfortunately I can't be of any added help here, as I also send my pull-requests though Sam. Sorry I couldn't be of any more use Sebastian. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 3/4] pinctrl: single: omap: Add SoC specific module for wake-up events
On 06/10/2013 06:21 PM, Tony Lindgren wrote:
* Quadros, Roger rog...@ti.com [130610 03:09]:
+
+static int __init pcs_omap_init(void)
+{
+ platform_driver_register(pcs_omap_soc_driver);
+ platform_driver_register(pcs_omap_driver);
+
+ return 0;
+}
+module_init(pcs_omap_init);
It seems this has to be moved to an earlier place (e.g. subsys_initcall)
else the pinctrl core fails to find the pinctrl device at the device creation
time and bails out with -EPROBE_DEFER. Also, that device is never
created again, so -EPROBE_DEFER doesn't seem to work there.
Ah here, found your other comment :)
That's not needed, the real fix is to make twl-core.c and friends to
be regular module_init. There are already patches queued for that.
OK. I was testing with USB host driver and it seems to be loaded as
fs_initcall() which
is the root of the problem. I will fix up the usb host driver to be loaded as
module_init()
cheers,
-roger
--
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 06/11/2013 02:05 PM, Lee Jones wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. I added Lee Jones because I hear no sign of life from Samuel. Unfortunately I can't be of any added help here, as I also send my pull-requests though Sam. Sorry I couldn't be of any more use Sebastian. It sometimes takes him a week or two to respond, but Samuel is pretty reliable when it comes to merging patches, so I wouldn't worry about it. - Lars -- 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 04/22] input/ti_am33x_tsc: Order of TSC wires, made configurable
Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:50PM +0200, Sebastian Andrzej Siewior wrote: diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h index eeead15..2d78af8 100644 --- a/include/linux/mfd/ti_am335x_tscadc.h +++ b/include/linux/mfd/ti_am335x_tscadc.h @@ -71,8 +71,6 @@ #define STEPCONFIG_INM_ADCREFM STEPCONFIG_INM(8) #define STEPCONFIG_INP_MASK (0xF 19) #define STEPCONFIG_INP(val) ((val) 19) -#define STEPCONFIG_INP_AN2 STEPCONFIG_INP(2) -#define STEPCONFIG_INP_AN3 STEPCONFIG_INP(3) #define STEPCONFIG_INP_AN4 STEPCONFIG_INP(4) #define STEPCONFIG_INP_ADCREFM STEPCONFIG_INP(8) #define STEPCONFIG_FIFO1 BIT(26) @@ -94,7 +92,6 @@ #define STEPCHARGE_INM_AN1 STEPCHARGE_INM(1) #define STEPCHARGE_INP_MASK (0xF 19) #define STEPCHARGE_INP(val) ((val) 19) -#define STEPCHARGE_INP_AN1 STEPCHARGE_INP(1) #define STEPCHARGE_RFM_MASK (3 23) #define STEPCHARGE_RFM(val) ((val) 23) #define STEPCHARGE_RFM_XNUR STEPCHARGE_RFM(1) @@ -116,6 +113,13 @@ #define CNTRLREG_8WIRE CNTRLREG_AFE_CTRL(3) #define CNTRLREG_TSCENB BIT(7) +#define XPP STEPCONFIG_XPP +#define XNP STEPCONFIG_XNP +#define XNN STEPCONFIG_XNN +#define YPP STEPCONFIG_YPP +#define YPN STEPCONFIG_YPN +#define YNN STEPCONFIG_YNN What is that for ? Isn't STEPCONFIG_XPP explicit enough ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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 01/22] mfd/ti_am335x_tscadc: remove regmap
Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:47PM +0200, Sebastian Andrzej Siewior wrote: The MFD part uses regmap without caching and is the only user of the regmap. The child drivers, that is input(touch) and iio(adc), use direct reg access. There is a patch which converts them to use regmap as well but I see no benefit at all doing this. There is a direct MMIO bus access with no need to cache values like for I2C or SPI devices. Furthermore, most (if not all) of the access done by the touch ADC driver read volatile register. 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. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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
Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. 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. Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. From what I can see from it, and please correct me if I'm wrong, the iio and input changes depend on the mfd ones, and not the other way around. If that's so, I'm going to ask you to reshuffle your patch set and separate the MFD changes from the iio and input ones. I'll take the MFD ones and will create an immutable branch for Jonathan and Dmitry to pull from and apply the iio and input changes on top of it. Merge conflicts should be mostly avoided that way. AFAICT, only patch #2 should be kept with input and iio bits mixed together with MFD as otherwise this would introduce functional breakage. Otherwise, all MFD bits from the other patches could be either separated or merged together (e.g. MFD bits from patches #6 and #8, and #16 and #17). Does that sound doable to you ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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 10/22] mfd/ti_am335x_tscadc: Add DT support
Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:56PM +0200, Sebastian Andrzej Siewior wrote: From: Patil, Rachna rac...@ti.com Make changes to add DT support in the MFD core driver. Which changes ? [ pa...@antoniou-consulting.com : use of_get_child_by_name instead of of_find_node_by_name ] I have no idea where that is coming from. Please remove this kind of stuff and build a proper commit log instead. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com Signed-off-by: Patil, Rachna rac...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com [bigeasy: module alias, rename to ti,am3359-tscadc as it was tested on AM3359] I honestly can't tell if this is a change from the last version of your patchset or a description of this patch changes in general. This is cluttering your commit logs, please remove this as well. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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 v3] ARM: DTS: TWL4030: fix mux and wakeup for SYS_NIRQ line
Benoit Cousson b-cous...@ti.com writes: On 06/11/2013 01:33 PM, Cousson, Benoit wrote: On 6/10/2013 6:40 PM, Kevin Hilman wrote: Benoit Cousson b-cous...@ti.com writes: Hi Kevin, On 06/07/2013 09:31 PM, Nishanth Menon wrote: On 11:31-20130607, Kevin Hilman wrote: On most OMAP3 platforms, the twl4030 IRQ line is connected to the SYS_NIRQ line on OMAP. Add another DTS include file (twl4030_omap3.dtsi) for boards that hook up the twl4030 this way to include. This allows RTC wake from off-mode to work again on OMAP3-based platforms with twl4030. Tested on 3530/Beagle, 3730/Beagle-xM, 3530/Overo, 3730/Overo-STORM. Special thanks to Florian Vaussard for suggesting use of preprocessor feature. Cc: Florian Vaussard florian.vauss...@epfl.ch Cc: Benoit Cousson b-cous...@ti.com Cc: Nishanth Menon n...@ti.com Signed-off-by: Kevin Hilman khil...@linaro.org Thanks, Reviewed-by: Nishanth Menon n...@ti.com Thanks, I've just applied it in for_3.11/dts. Thanks, Will you apply the first 2 from the series too? ARM: DTS: OMAP3: beagle/overo: mux console UART, enable wakeup ARM: DTS: OMAP3: beagle: enable user button via gpio_keys, enable wakeup Thanks for the reminder, I kind of forgot these ones :-) BTW, do you have any v2 for these ones? This version does not use the macros. Moreover I cannot apply them on top of Florian's series :-( Oops, I thought I reposted those too. All three are here: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.11/dt which is based on top of your for_3.11/dts branch. 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 01/22] mfd/ti_am335x_tscadc: remove regmap
On 06/11/2013 04:23 PM, Samuel Ortiz wrote: Hi Sebastian, Hi Samuel, 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. Cheers, Samuel. Sebastian -- 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 04/22] input/ti_am33x_tsc: Order of TSC wires, made configurable
On 06/11/2013 04:23 PM, Samuel Ortiz wrote: Hi Sebastian, Hi Samuel, On Tue, Jun 11, 2013 at 01:30:50PM +0200, Sebastian Andrzej Siewior wrote: diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h index eeead15..2d78af8 100644 --- a/include/linux/mfd/ti_am335x_tscadc.h +++ b/include/linux/mfd/ti_am335x_tscadc.h @@ -116,6 +113,13 @@ #define CNTRLREG_8WIRE CNTRLREG_AFE_CTRL(3) #define CNTRLREG_TSCENB BIT(7) +#define XPP STEPCONFIG_XPP +#define XNP STEPCONFIG_XNP +#define XNN STEPCONFIG_XNN +#define YPP STEPCONFIG_YPP +#define YPN STEPCONFIG_YPN +#define YNN STEPCONFIG_YNN What is that for ? Isn't STEPCONFIG_XPP explicit enough ? Yeah :P It was added by the original author of the patch, I have no problem getting rid of it. Cheers, Samuel. Sebastian -- 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 10/22] mfd/ti_am335x_tscadc: Add DT support
On 06/11/2013 04:23 PM, Samuel Ortiz wrote: Hi Sebastian, Hi Samuel, On Tue, Jun 11, 2013 at 01:30:56PM +0200, Sebastian Andrzej Siewior wrote: From: Patil, Rachna rac...@ti.com Make changes to add DT support in the MFD core driver. Which changes ? So rewrite the commit log… [ pa...@antoniou-consulting.com : use of_get_child_by_name instead of of_find_node_by_name ] I have no idea where that is coming from. Please remove this kind of stuff and build a proper commit log instead. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com Signed-off-by: Patil, Rachna rac...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com [bigeasy: module alias, rename to ti,am3359-tscadc as it was tested on AM3359] I honestly can't tell if this is a change from the last version of your patchset or a description of this patch changes in general. This is cluttering your commit logs, please remove this as well. I took the original patch. Every change I made to it because people asked to merge changes into the patch where the problem occurred I added it here before my sign-off. In the end I would like not to post a patch with From: != me and don't make change which the original author did not do. Also dropping their authorship isn't nice. What could we agree on? Cheers, Samuel. Sebastian -- 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 2/3] ARM: dts: Add omap3-overo NAND flash memory binding
Add device-tree node for the on-board NAND memory.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3-overo.dtsi | 50
arch/arm/boot/dts/omap3.dtsi |2 +
2 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index e112a42..811b74c 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -33,6 +33,56 @@
};
};
+gpmc {
+ ranges = 0 0 0x3000 0x0004; /* CS0: NAND */
+
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
+ nand-bus-width = 16;
+
+ ti,nand-ecc-opt = sw;
+
+ gpmc,device-nand;
+ gpmc,sync-clk-ps = 0;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 36;
+ gpmc,cs-wr-off-ns = 36;
+ gpmc,adv-on-ns = 6;
+ gpmc,adv-rd-off-ns = 24;
+ gpmc,adv-wr-off-ns = 36;
+ gpmc,we-off-ns = 30;
+ gpmc,oe-off-ns = 48;
+ gpmc,access-ns = 54;
+ gpmc,rd-cycle-ns = 72;
+ gpmc,wr-cycle-ns = 72;
+ gpmc,wr-access-ns = 30;
+ gpmc,wr-data-mux-bus-ns = 0;
+
+ #address-cells = 1;
+ #size-cells = 1;
+
+ xloader@0 {
+ reg = (0 * SZ_128K) (4 * SZ_128K);
+ };
+
+ uboot@8 {
+ reg = (4 * SZ_128K) (14 * SZ_128K);
+ };
+
+ ubootenv@24 {
+ reg = (18 * SZ_128K) (2 * SZ_128K);
+ };
+
+ linux@28 {
+ reg = (20 * SZ_128K) (32 * SZ_128K);
+ };
+
+ rootfs@68 {
+ reg = (52 * SZ_128K) MTDPART_SIZ_FULL;
+ };
+ };
+};
+
i2c1 {
clock-frequency = 260;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 6d05ee0..65a9390 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -9,7 +9,9 @@
*/
#include dt-bindings/gpio/gpio.h
+#include dt-bindings/mtd/partitions.h
#include dt-bindings/pinctrl/omap.h
+#include dt-bindings/sizes.h
#include skeleton.dtsi
--
1.7.5.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 0/3] ARM: dts: OMAP3: Use constants with MTD devices
Hello, Legacy board files use constants from sizes.h and mtd/partitions.h to declare MTD partitions. This series performs the same with DT. Necessary headers are added (patch 1), a NAND node is added to omap3-overo (patch 2), and remaining DTS are converted (patch 3). Patch 2 was tested on the real hardware. For patch 3, the resulting DTB were diff'ed. The MTDPART_SIZ_FULL constant was used in DTS, when it was the case in legacy board files. The size cell is thus changed inside the binary output, so testing on the hardware is welcome, even if it should work transparently. Note that inside omap3430-sdp.dts (nor@0,0), it appears with this series that partitions 'kernel-nor' and 'filesystem-nor' overlaps by (2*SZ_128K), which is probably not desired. Regards, Florian Florian Vaussard (3): ARM: dts: Add headers with constants for MTD partitions ARM: dts: Add omap3-overo NAND flash memory binding ARM: dts: OMAP3: Use MTD constants for OMAP3 boards arch/arm/boot/dts/omap3-devkit8000.dts | 10 +++--- arch/arm/boot/dts/omap3-igep0020.dts | 10 +++--- arch/arm/boot/dts/omap3-igep0030.dts | 10 +++--- arch/arm/boot/dts/omap3-overo.dtsi | 50 ++ arch/arm/boot/dts/omap3.dtsi |2 + arch/arm/boot/dts/omap3430-sdp.dts | 28 include/dt-bindings/mtd/partitions.h | 12 +++ include/dt-bindings/sizes.h| 52 8 files changed, 145 insertions(+), 29 deletions(-) create mode 100644 include/dt-bindings/mtd/partitions.h create mode 100644 include/dt-bindings/sizes.h -- 1.7.5.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 3/3] ARM: dts: OMAP3: Use MTD constants for OMAP3 boards
Use the MTD constants for NAND and OneNAND nodes used in OMAP3
DTS.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3-devkit8000.dts | 10 +-
arch/arm/boot/dts/omap3-igep0020.dts | 10 +-
arch/arm/boot/dts/omap3-igep0030.dts | 10 +-
arch/arm/boot/dts/omap3430-sdp.dts | 28 ++--
4 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts
b/arch/arm/boot/dts/omap3-devkit8000.dts
index 5be71b1..08699cb 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -143,27 +143,27 @@
x-loader@0 {
label = X-Loader;
- reg = 0 0x8;
+ reg = (0 * SZ_128K) (4 * SZ_128K);
};
bootloaders@8 {
label = U-Boot;
- reg = 0x8 0x1e;
+ reg = (4 * SZ_128K) (15 * SZ_128K);
};
bootloaders_env@26 {
label = U-Boot Env;
- reg = 0x26 0x2;
+ reg = (19 * SZ_128K) (1 * SZ_128K);
};
kernel@28 {
label = Kernel;
- reg = 0x28 0x40;
+ reg = (20 * SZ_128K) (32 * SZ_128K);
};
filesystem@68 {
label = File System;
- reg = 0x68 0xf98;
+ reg = (52 * SZ_128K) MTDPART_SIZ_FULL;
};
};
};
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e8c4828..3476b3c 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -97,23 +97,23 @@
partition@0 {
label = SPL;
- reg = 0 0x10;
+ reg = (0 * SZ_256K) (4 * SZ_256K);
};
partition@0x8 {
label = U-Boot;
- reg = 0x10 0x18;
+ reg = (4 * SZ_256K) (6 * SZ_256K);
};
partition@0x1c {
label = Environment;
- reg = 0x28 0x10;
+ reg = (10 * SZ_256K) (4 * SZ_256K);
};
partition@0x28 {
label = Kernel;
- reg = 0x38 0x30;
+ reg = (14 * SZ_256K) (12 * SZ_256K);
};
partition@0x78 {
label = Filesystem;
- reg = 0x68 0x1f98;
+ reg = (26 * SZ_256K) MTDPART_SIZ_FULL;
};
};
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts
b/arch/arm/boot/dts/omap3-igep0030.dts
index 644d053..e4f078c 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -72,23 +72,23 @@
partition@0 {
label = SPL;
- reg = 0 0x10;
+ reg = (0 * SZ_256K) (4 * SZ_256K);
};
partition@0x8 {
label = U-Boot;
- reg = 0x10 0x18;
+ reg = (4 * SZ_256K) (6 * SZ_256K);
};
partition@0x1c {
label = Environment;
- reg = 0x28 0x10;
+ reg = (10 * SZ_256K) (4 * SZ_256K);
};
partition@0x28 {
label = Kernel;
- reg = 0x38 0x30;
+ reg = (14 * SZ_256K) (12 * SZ_256K);
};
partition@0x78 {
label = Filesystem;
- reg = 0x68 0x1f98;
+ reg = (26 * SZ_256K) MTDPART_SIZ_FULL;
};
};
};
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts/omap3430-sdp.dts
index 2a725a0..dd69ee0 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -81,19 +81,19 @@
partition@0 {
label = bootloader-nor;
- reg = 0 0x4;
+ reg = (0 * SZ_128K) (2 * SZ_128K);
};
partition@0x4 {
label = params-nor;
- reg = 0x4 0x4;
+ reg = (2 * SZ_128K) (2 * SZ_128K);
};
partition@0x8 {
label = kernel-nor;
- reg = 0x8 0x20;
+
[PATCH 1/3] ARM: dts: Add headers with constants for MTD partitions
These constants can be used to easily declare MTD partitions inside DTS. The constants MTDPART_OFS_* are purposely not included. Indeed, parse_ofpart_partitions() is expecting u64, but a DT cell is u32. Negative constants, as defined by MTDPART_OFS_*, would be wrongly interpreted by parse_ofpart_partitions(). Two cells should be used to correctly encode the negative constants, but this breaks current usage. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch --- include/dt-bindings/mtd/partitions.h | 12 include/dt-bindings/sizes.h | 52 ++ 2 files changed, 64 insertions(+), 0 deletions(-) create mode 100644 include/dt-bindings/mtd/partitions.h create mode 100644 include/dt-bindings/sizes.h diff --git a/include/dt-bindings/mtd/partitions.h b/include/dt-bindings/mtd/partitions.h new file mode 100644 index 000..7dfa676 --- /dev/null +++ b/include/dt-bindings/mtd/partitions.h @@ -0,0 +1,12 @@ +/* + * This header provides constants used with MTD partitions. + */ + +#ifndef _DT_BINDINGS_MTD_PARTITIONS_H +#define _DT_BINDINGS_MTD_PARTITIONS_H + +/* Partition size */ +#define MTDPART_SIZ_FULL 0 + +#endif + diff --git a/include/dt-bindings/sizes.h b/include/dt-bindings/sizes.h new file mode 100644 index 000..995f2de --- /dev/null +++ b/include/dt-bindings/sizes.h @@ -0,0 +1,52 @@ +/* + * This header provides size constants. + * + * Original version: + * include/linux/sizes.h + * + * 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. + */ + +#ifndef _DT_BINDINGS_SIZES_H +#define _DT_BINDINGS_SIZES_H + +#define SZ_1 0x0001 +#define SZ_2 0x0002 +#define SZ_4 0x0004 +#define SZ_8 0x0008 +#define SZ_16 0x0010 +#define SZ_32 0x0020 +#define SZ_64 0x0040 +#define SZ_128 0x0080 +#define SZ_256 0x0100 +#define SZ_512 0x0200 + +#define SZ_1K 0x0400 +#define SZ_2K 0x0800 +#define SZ_4K 0x1000 +#define SZ_8K 0x2000 +#define SZ_16K 0x4000 +#define SZ_32K 0x8000 +#define SZ_64K 0x0001 +#define SZ_128K0x0002 +#define SZ_256K0x0004 +#define SZ_512K0x0008 + +#define SZ_1M 0x0010 +#define SZ_2M 0x0020 +#define SZ_4M 0x0040 +#define SZ_8M 0x0080 +#define SZ_16M 0x0100 +#define SZ_32M 0x0200 +#define SZ_64M 0x0400 +#define SZ_128M0x0800 +#define SZ_256M0x1000 +#define SZ_512M0x2000 + +#define SZ_1G 0x4000 +#define SZ_2G 0x8000 + +#endif + -- 1.7.5.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 0/4] ARM: dts: OMAP3: Updates for Overo
Hello, This series performs several updates to omap3-overo and omap3-tobi. Patch 1 is necessary to patch 2 for the IRQ constant. The SMSC911X is largely taken from omap3-igep. Regards, Florian Florian Vaussard (4): ARM: dts: OMAP3: Include IRQ header ARM: dts: omap3-tobi: Add SMSC911X node ARM: dts: omap3-tobi: Correct polarity for GPIO LED ARM: dts: omap3-overo: Add default trigger for TWL4030 LED arch/arm/boot/dts/omap3-overo.dtsi |1 + arch/arm/boot/dts/omap3-tobi.dts | 50 +++- arch/arm/boot/dts/omap3.dtsi |1 + 3 files changed, 51 insertions(+), 1 deletions(-) -- 1.7.5.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 1/4] ARM: dts: OMAP3: Include IRQ header
Some nodes in OMAP3 DTS now use edge or level sensitive interrupts. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch --- arch/arm/boot/dts/omap3.dtsi |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi index 6d05ee0..8e1a87f 100644 --- a/arch/arm/boot/dts/omap3.dtsi +++ b/arch/arm/boot/dts/omap3.dtsi @@ -9,6 +9,7 @@ */ #include dt-bindings/gpio/gpio.h +#include dt-bindings/interrupt-controller/irq.h #include dt-bindings/pinctrl/omap.h #include skeleton.dtsi -- 1.7.5.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 2/4] ARM: dts: omap3-tobi: Add SMSC911X node
The Tobi expansion boards embeds a SMSC LAN8700 PHY. Add the
corresponding node into the DT. The regulators are not designed
to be turned off.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3-tobi.dts | 48 ++
1 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-tobi.dts b/arch/arm/boot/dts/omap3-tobi.dts
index c7eebbf..dea726f 100644
--- a/arch/arm/boot/dts/omap3-tobi.dts
+++ b/arch/arm/boot/dts/omap3-tobi.dts
@@ -24,6 +24,54 @@
linux,default-trigger = heartbeat;
};
};
+
+ vddvario: regulator-vddvario {
+ compatible = regulator-fixed;
+ regulator-name = vddvario;
+ regulator-always-on;
+ };
+
+ vdd33a: regulator-vdd33a {
+ compatible = regulator-fixed;
+ regulator-name = vdd33a;
+ regulator-always-on;
+ };
+};
+
+gpmc {
+ ranges = 5 0 0x2c00 0x100;/* CS5 */
+
+ ethernet@5,0 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 5 0 0xff;
+ bank-width = 2;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 42;
+ gpmc,cs-wr-off-ns = 36;
+ gpmc,adv-on-ns = 6;
+ gpmc,adv-rd-off-ns = 12;
+ gpmc,adv-wr-off-ns = 12;
+ gpmc,oe-on-ns = 0;
+ gpmc,oe-off-ns = 42;
+ gpmc,we-on-ns = 0;
+ gpmc,we-off-ns = 36;
+ gpmc,rd-cycle-ns = 60;
+ gpmc,wr-cycle-ns = 54;
+ gpmc,access-ns = 36;
+ gpmc,page-burst-access-ns = 0;
+ gpmc,bus-turnaround-ns = 0;
+ gpmc,cycle2cycle-delay-ns = 0;
+ gpmc,wr-data-mux-bus-ns = 18;
+ gpmc,wr-access-ns = 42;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+
+ interrupt-parent = gpio6;
+ interrupts = 16 IRQ_TYPE_LEVEL_LOW; /* GPIO 176*/
+ reg-io-width = 4;
+ };
};
i2c3 {
--
1.7.5.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 3/4] ARM: dts: omap3-tobi: Correct polarity for GPIO LED
The LED is active low, not active high.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3-tobi.dts |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-tobi.dts b/arch/arm/boot/dts/omap3-tobi.dts
index dea726f..1458591 100644
--- a/arch/arm/boot/dts/omap3-tobi.dts
+++ b/arch/arm/boot/dts/omap3-tobi.dts
@@ -20,7 +20,7 @@
compatible = gpio-leds;
heartbeat {
label = overo:red:gpio21;
- gpios = gpio1 21 GPIO_ACTIVE_HIGH;
+ gpios = gpio1 21 GPIO_ACTIVE_LOW;
linux,default-trigger = heartbeat;
};
};
--
1.7.5.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: Protect pinctrl headers against multiple inclusions
Pinctrl headers were not protected with #ifndef. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch --- include/dt-bindings/pinctrl/am33xx.h |5 + include/dt-bindings/pinctrl/omap.h |5 + 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/include/dt-bindings/pinctrl/am33xx.h b/include/dt-bindings/pinctrl/am33xx.h index a3fddd4..469e032 100644 --- a/include/dt-bindings/pinctrl/am33xx.h +++ b/include/dt-bindings/pinctrl/am33xx.h @@ -2,6 +2,9 @@ * This header provides constants specific to AM33XX pinctrl bindings. */ +#ifndef _DT_BINDINGS_PINCTRL_AM33XX_H +#define _DT_BINDINGS_PINCTRL_AM33XX_H + #include include/dt-bindings/pinctrl/omap.h /* am33xx specific mux bit defines */ @@ -35,3 +38,5 @@ #undef PIN_OFF_INPUT_PULLDOWN #undef PIN_OFF_WAKEUPENABLE +#endif + diff --git a/include/dt-bindings/pinctrl/omap.h b/include/dt-bindings/pinctrl/omap.h index 370df3f..edbd250 100644 --- a/include/dt-bindings/pinctrl/omap.h +++ b/include/dt-bindings/pinctrl/omap.h @@ -5,6 +5,9 @@ * Copyright (C) 2009-2010 Texas Instruments */ +#ifndef _DT_BINDINGS_PINCTRL_OMAP_H +#define _DT_BINDINGS_PINCTRL_OMAP_H + /* 34xx mux mode options for each pin. See TRM for options */ #define MUX_MODE0 0 #define MUX_MODE1 1 @@ -48,3 +51,5 @@ #define PIN_OFF_INPUT_PULLDOWN (OFF_EN | OFF_PULL_EN) #define PIN_OFF_WAKEUPENABLE WAKEUP_EN +#endif + -- 1.7.5.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
Re: [PATCH] ARM: dts: omap3-devkit8000: fix NAND memory binding
Hello, On 05/31/2013 03:49 PM, Florian Vaussard wrote: Hello, Gentle ping. Does someone has any comments on this fix? Can someone tests on the real hardware? Nobody has this hardware somewhere in a drawer? :-) Regards, Florian Regards, Florian On 05/23/2013 10:11 AM, Florian Vaussard wrote: Commit d36b4cd 'ARM: OMAP2+: Add additional GPMC timing parameters' updated GPMC binding, but omap3-devkit8000 was not updated accordingly, resulting in a broken configuration. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch --- arch/arm/boot/dts/omap3-devkit8000.dts | 29 +++-- 1 files changed, 15 insertions(+), 14 deletions(-) diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts b/arch/arm/boot/dts/omap3-devkit8000.dts index 8a5cdcc..e5b35f5 100644 --- a/arch/arm/boot/dts/omap3-devkit8000.dts +++ b/arch/arm/boot/dts/omap3-devkit8000.dts @@ -123,20 +123,21 @@ reg = 0 0 0; /* CS0, offset 0 */ nand-bus-width = 16; -gpmc,sync-clk = 0; -gpmc,cs-on = 0; -gpmc,cs-rd-off = 44; -gpmc,cs-wr-off = 44; -gpmc,adv-on = 6; -gpmc,adv-rd-off = 34; -gpmc,adv-wr-off = 44; -gpmc,we-off = 40; -gpmc,oe-off = 54; -gpmc,access = 64; -gpmc,rd-cycle = 82; -gpmc,wr-cycle = 82; -gpmc,wr-access = 40; -gpmc,wr-data-mux-bus = 0; +gpmc,device-nand; +gpmc,sync-clki-ps = 0; +gpmc,cs-on-ns = 0; +gpmc,cs-rd-off-ns = 44; +gpmc,cs-wr-off-ns = 44; +gpmc,adv-on-ns = 6; +gpmc,adv-rd-off-ns = 34; +gpmc,adv-wr-off-ns = 44; +gpmc,we-off-ns = 40; +gpmc,oe-off-ns = 54; +gpmc,access-ns = 64; +gpmc,rd-cycle-ns = 82; +gpmc,wr-cycle-ns = 82; +gpmc,wr-access-ns = 40; +gpmc,wr-data-mux-bus-ns = 0; #address-cells = 1; #size-cells = 1; -- Florian Vaussard EPFL - STI - IMT - LSRO1 MEB330 - Station 9 1015 Lausanne / Switzerland tel: +41 21 693 78 39 fax: +41 21 693 78 07 http://lsro.epfl.ch -- 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 10/22] mfd/ti_am335x_tscadc: Add DT support
Hi Sebastian, On Tue, Jun 11, 2013 at 04:42:30PM +0200, Sebastian Andrzej Siewior wrote: In the end I would like not to post a patch with From: != me and don't make change which the original author did not do. Also dropping their authorship isn't nice. What could we agree on? You probably don't want to change authorship unless the final patch is really far from the original one. In which case you can change it and mention the original author name in the commit log. If you have only made a few changes on top of the original patch, please say so explicitely in the commit log. Don't bother if we're talking about small changes or cosmetic ones. But your commit log has to be readable and clear. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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 06/11/2013 04:23 PM, Samuel Ortiz wrote: Hi Sebastian, Hi Samuel, On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. 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. Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. They somehow depend on each other. Otherwise I would have sent three series, one per subsystem. From what I can see from it, and please correct me if I'm wrong, the iio and input changes depend on the mfd ones, and not the other way around. If that's so, I'm going to ask you to reshuffle your patch set and separate the MFD changes from the iio and input ones. I'll take the MFD ones and will create an immutable branch for Jonathan and Dmitry to pull from and apply the iio and input changes on top of it. Merge conflicts should be mostly avoided that way. AFAICT, only patch #2 should be kept with input and iio bits mixed together with MFD as otherwise this would introduce functional breakage. Otherwise, all MFD bits from the other patches could be either separated or merged together (e.g. MFD bits from patches #6 and #8, and #16 and #17). Does that sound doable to you ? The device renaming shouldn't matter since I added DT nodes for the mfd child devices earlier. But then the of_compatible assignments should go hand in hand. However if I split this then the driver won't work but then it does not now as well (because there is no platform_data provider in tree). Still. There is #18 which reworks the step addressing and involves changes in both (iio input) at the same time. There is #21. Adding this to the initial DT support patch would be bad I think because it requires some changes on the iio side which have nothing to do with DT. Putting the iio changes before DT would require to make some change to platform-data part which will go away anyway. So I started collecting ACKs from input and iio to avoid this split. If you really want the split then I will start doing so… Cheers, Samuel. Sebastian -- 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 3/3] ARM: dts: OMAP3: Use MTD constants for OMAP3 boards
On 06/11/2013 04:48 PM, Florian Vaussard wrote:
Use the MTD constants for NAND and OneNAND nodes used in OMAP3
DTS.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3-devkit8000.dts | 10 +-
arch/arm/boot/dts/omap3-igep0020.dts | 10 +-
arch/arm/boot/dts/omap3-igep0030.dts | 10 +-
arch/arm/boot/dts/omap3430-sdp.dts | 28 ++--
4 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts
b/arch/arm/boot/dts/omap3-devkit8000.dts
index 5be71b1..08699cb 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -143,27 +143,27 @@
x-loader@0 {
label = X-Loader;
- reg = 0 0x8;
+ reg = (0 * SZ_128K) (4 * SZ_128K);
};
bootloaders@8 {
label = U-Boot;
- reg = 0x8 0x1e;
+ reg = (4 * SZ_128K) (15 * SZ_128K);
};
bootloaders_env@26 {
label = U-Boot Env;
- reg = 0x26 0x2;
+ reg = (19 * SZ_128K) (1 * SZ_128K);
};
kernel@28 {
label = Kernel;
- reg = 0x28 0x40;
+ reg = (20 * SZ_128K) (32 * SZ_128K);
};
filesystem@68 {
label = File System;
- reg = 0x68 0xf98;
+ reg = (52 * SZ_128K) MTDPART_SIZ_FULL;
};
};
};
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e8c4828..3476b3c 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -97,23 +97,23 @@
partition@0 {
label = SPL;
- reg = 0 0x10;
+ reg = (0 * SZ_256K) (4 * SZ_256K);
};
partition@0x8 {
label = U-Boot;
- reg = 0x10 0x18;
+ reg = (4 * SZ_256K) (6 * SZ_256K);
};
partition@0x1c {
label = Environment;
- reg = 0x28 0x10;
+ reg = (10 * SZ_256K) (4 * SZ_256K);
};
partition@0x28 {
label = Kernel;
- reg = 0x38 0x30;
+ reg = (14 * SZ_256K) (12 * SZ_256K);
};
partition@0x78 {
label = Filesystem;
- reg = 0x68 0x1f98;
+ reg = (26 * SZ_256K) MTDPART_SIZ_FULL;
};
};
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts
b/arch/arm/boot/dts/omap3-igep0030.dts
index 644d053..e4f078c 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -72,23 +72,23 @@
partition@0 {
label = SPL;
- reg = 0 0x10;
+ reg = (0 * SZ_256K) (4 * SZ_256K);
};
partition@0x8 {
label = U-Boot;
- reg = 0x10 0x18;
+ reg = (4 * SZ_256K) (6 * SZ_256K);
};
partition@0x1c {
label = Environment;
- reg = 0x28 0x10;
+ reg = (10 * SZ_256K) (4 * SZ_256K);
};
partition@0x28 {
label = Kernel;
- reg = 0x38 0x30;
+ reg = (14 * SZ_256K) (12 * SZ_256K);
};
partition@0x78 {
label = Filesystem;
- reg = 0x68 0x1f98;
+ reg = (26 * SZ_256K) MTDPART_SIZ_FULL;
};
};
};
Hi Florian,
I don't have access to my IGEP board so I can test it right now but the patch
looks good to me.
In fact I wanted to use MTDPART_SIZ_FULL when added the NAND nodes since not all
IGEP boards have 512MB flash but I didn't know that a value of 0 meant that.
So thanks a lot for doing this!
Acked-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
--
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/4] ARM: dts: omap3-tobi: Add SMSC911X node
On 06/11/2013 04:49 PM, Florian Vaussard wrote:
The Tobi expansion boards embeds a SMSC LAN8700 PHY. Add the
corresponding node into the DT. The regulators are not designed
to be turned off.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3-tobi.dts | 48
++
1 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-tobi.dts
b/arch/arm/boot/dts/omap3-tobi.dts
index c7eebbf..dea726f 100644
--- a/arch/arm/boot/dts/omap3-tobi.dts
+++ b/arch/arm/boot/dts/omap3-tobi.dts
@@ -24,6 +24,54 @@
linux,default-trigger = heartbeat;
};
};
+
+ vddvario: regulator-vddvario {
+ compatible = regulator-fixed;
+ regulator-name = vddvario;
+ regulator-always-on;
+ };
+
+ vdd33a: regulator-vdd33a {
+ compatible = regulator-fixed;
+ regulator-name = vdd33a;
+ regulator-always-on;
+ };
+};
+
+gpmc {
+ ranges = 5 0 0x2c00 0x100;/* CS5 */
+
+ ethernet@5,0 {
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 5 0 0xff;
+ bank-width = 2;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 42;
+ gpmc,cs-wr-off-ns = 36;
+ gpmc,adv-on-ns = 6;
+ gpmc,adv-rd-off-ns = 12;
+ gpmc,adv-wr-off-ns = 12;
+ gpmc,oe-on-ns = 0;
+ gpmc,oe-off-ns = 42;
+ gpmc,we-on-ns = 0;
+ gpmc,we-off-ns = 36;
+ gpmc,rd-cycle-ns = 60;
+ gpmc,wr-cycle-ns = 54;
+ gpmc,access-ns = 36;
+ gpmc,page-burst-access-ns = 0;
+ gpmc,bus-turnaround-ns = 0;
+ gpmc,cycle2cycle-delay-ns = 0;
+ gpmc,wr-data-mux-bus-ns = 18;
+ gpmc,wr-access-ns = 42;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+
+ interrupt-parent = gpio6;
+ interrupts = 16 IRQ_TYPE_LEVEL_LOW; /* GPIO 176*/
+ reg-io-width = 4;
+ };
};
i2c3 {
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
--
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 10/22] mfd/ti_am335x_tscadc: Add DT support
On 06/11/2013 05:05 PM, Samuel Ortiz wrote: Hi Sebastian, Hi Samuel, On Tue, Jun 11, 2013 at 04:42:30PM +0200, Sebastian Andrzej Siewior wrote: In the end I would like not to post a patch with From: != me and don't make change which the original author did not do. Also dropping their authorship isn't nice. What could we agree on? You probably don't want to change authorship unless the final patch is really far from the original one. In which case you can change it and mention the original author name in the commit log. If you have only made a few changes on top of the original patch, please say so explicitely in the commit log. Don't bother if we're talking about small changes or cosmetic ones. But your commit log has to be readable and clear. Commit 06c9494 on of many examples where cosmetic are recorded. But to make some progress I rewrite the commit log to resolve this and don't add anything to the sign-off area. Cheers, Samuel. Sebastian -- 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 v3] ARM: dts: OMAP5: Add palmas MFD node and regulator nodes
On 06/10/2013 11:30 PM, J Keerthy wrote:
This patch adds Palmas MFD node and the regulator nodes for OMAP5.
The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
Boot tested on omap5-uevm board.
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
+ palmas: palmas@48 {
+ reg = 0x48;
+ interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N */
+ interrupt-parent = gic;
+ };
+};
+
+palmas {
+ compatible = ti,palmas;
+ interrupt-controller;
+ #interrupt-cells = 2;
I don't really see the point of splitting the node into two parts if
it's all going into a single file. It made sense if part of the node
came from a common .dtsi file, but not so much when it doesn't.
--
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
Hi Samuel, On Tue, Jun 11, 2013 at 04:23:58PM +0200, Samuel Ortiz wrote: Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. 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. Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. From what I can see from it, and please correct me if I'm wrong, the iio and input changes depend on the mfd ones, and not the other way around. If that's so, I'm going to ask you to reshuffle your patch set and separate the MFD changes from the iio and input ones. I'll take the MFD ones and will create an immutable branch for Jonathan and Dmitry to pull from and apply the iio and input changes on top of it. Merge conflicts should be mostly avoided that way. I purposely left this driver alone as I expected it would be merged through MFD tree, so there should not be any merging issues on my side. Thanks. -- Dmitry -- 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
Hi Sebastian, On Tue, Jun 11, 2013 at 05:29:22PM +0200, Sebastian Andrzej Siewior wrote: Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. They somehow depend on each other. Otherwise I would have sent three series, one per subsystem. Of course they depend on each other, but the dependency is mostly for iio and input to depend on the MFD changes. From what I can see from it, and please correct me if I'm wrong, the iio and input changes depend on the mfd ones, and not the other way around. If that's so, I'm going to ask you to reshuffle your patch set and separate the MFD changes from the iio and input ones. I'll take the MFD ones and will create an immutable branch for Jonathan and Dmitry to pull from and apply the iio and input changes on top of it. Merge conflicts should be mostly avoided that way. AFAICT, only patch #2 should be kept with input and iio bits mixed together with MFD as otherwise this would introduce functional breakage. Otherwise, all MFD bits from the other patches could be either separated or merged together (e.g. MFD bits from patches #6 and #8, and #16 and #17). Does that sound doable to you ? The device renaming shouldn't matter since I added DT nodes for the mfd child devices earlier. But then the of_compatible assignments should go hand in hand. However if I split this then the driver won't work but then it does not now as well (because there is no platform_data provider in tree). Still. There is #18 which reworks the step addressing and involves changes in both (iio input) at the same time. Would splitting iio and input break anything there ? There is #21. Adding this to the initial DT support patch would be bad I think because it requires some changes on the iio side which have nothing to do with DT. Putting the iio changes before DT would require to make some change to platform-data part which will go away anyway. Wouldn't it workif you split this one into an MFD+dts file changes and another one for the iio changes ? So I started collecting ACKs from input and iio to avoid this split. If you really want the split then I will start doing so… I think it would be nicer, yes. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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
Hi Dmitry, On Tue, Jun 11, 2013 at 09:04:16AM -0700, Dmitry Torokhov wrote: On Tue, Jun 11, 2013 at 04:23:58PM +0200, Samuel Ortiz wrote: Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. 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. Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. From what I can see from it, and please correct me if I'm wrong, the iio and input changes depend on the mfd ones, and not the other way around. If that's so, I'm going to ask you to reshuffle your patch set and separate the MFD changes from the iio and input ones. I'll take the MFD ones and will create an immutable branch for Jonathan and Dmitry to pull from and apply the iio and input changes on top of it. Merge conflicts should be mostly avoided that way. I purposely left this driver alone as I expected it would be merged through MFD tree, so there should not be any merging issues on my side. Thanks for the notice. Jonathan, can you guarantee the same for the iio parts ? Sabastian, hold on before reworking your patchset. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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 06/11/2013 06:10 PM, Samuel Ortiz wrote: Hi Sebastian, Hi Samuel, On Tue, Jun 11, 2013 at 05:29:22PM +0200, Sebastian Andrzej Siewior wrote: Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. They somehow depend on each other. Otherwise I would have sent three series, one per subsystem. Of course they depend on each other, but the dependency is mostly for iio and input to depend on the MFD changes. Except for the one #18 as mentioned below. Still. There is #18 which reworks the step addressing and involves changes in both (iio input) at the same time. Would splitting iio and input break anything there ? Yes. Once the header files is modified without the two .c files the driver is not working. To fix this I need another patch making sure input + iio does not the header files and another to user it (once everything is merged). There is #21. Adding this to the initial DT support patch would be bad I think because it requires some changes on the iio side which have nothing to do with DT. Putting the iio changes before DT would require to make some change to platform-data part which will go away anyway. Wouldn't it workif you split this one into an MFD+dts file changes and another one for the iio changes ? It would work in general. The first few DT-iio patches wouldn't make sense but then why not. So I started collecting ACKs from input and iio to avoid this split. If you really want the split then I will start doing so… I think it would be nicer, yes. Nicer. I see. Please tell me what you think about #1 because I really would like to drop regmap and then I can start reshuffle the series :) Cheers, Samuel. Sebastian -- 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/3] ARM: dts: Add headers with constants for MTD partitions
On 06/11/2013 08:48 AM, Florian Vaussard wrote: These constants can be used to easily declare MTD partitions inside DTS. The constants MTDPART_OFS_* are purposely not included. Indeed, parse_ofpart_partitions() is expecting u64, but a DT cell is u32. Negative constants, as defined by MTDPART_OFS_*, would be wrongly interpreted by parse_ofpart_partitions(). Two cells should be used to correctly encode the negative constants, but this breaks current usage. I think addition of common headers like this needs an ack from Grant/Rob. I CC'd them here. diff --git a/include/dt-bindings/mtd/partitions.h b/include/dt-bindings/mtd/partitions.h + * This header provides constants used with MTD partitions. ... +/* Partition size */ +#define MTDPART_SIZ_FULL 0 Which binding document in Documentation/devicetree/bindings is this definition associated with? The comment above should really mention this. Documentation/devicetree/bindings/mtd/partition.txt doesn't seem to mention this value. diff --git a/include/dt-bindings/sizes.h b/include/dt-bindings/sizes.h ... +#define SZ_1G0x4000 +#define SZ_2G0x8000 + +#endif For MTD partitions specifically, SZ_4G and onwards would be useful in theory, although that would end up putting two cell values into a single macro. and then the values couldn't be added/or'd together. So, I'm not really sure if we want to add those larger values, but food for thought... -- 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 3/3] ARM: dts: OMAP3: Use MTD constants for OMAP3 boards
On 06/11/2013 08:48 AM, Florian Vaussard wrote: Use the MTD constants for NAND and OneNAND nodes used in OMAP3 DTS. I don't quite understand the split between patches 2/3 and 3/3; isn't the edit to omap3-overo.dtsi (part of) a board file, and hence logically part of this patch? I'd be tempted just to squash the two together. But, this is a nit; not a big deal. -- 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
Samuel Ortiz sa...@linux.intel.com wrote: Hi Dmitry, On Tue, Jun 11, 2013 at 09:04:16AM -0700, Dmitry Torokhov wrote: On Tue, Jun 11, 2013 at 04:23:58PM +0200, Samuel Ortiz wrote: Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. 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. Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. From what I can see from it, and please correct me if I'm wrong, the iio and input changes depend on the mfd ones, and not the other way around. If that's so, I'm going to ask you to reshuffle your patch set and separate the MFD changes from the iio and input ones. I'll take the MFD ones and will create an immutable branch for Jonathan and Dmitry to pull from and apply the iio and input changes on top of it. Merge conflicts should be mostly avoided that way. I purposely left this driver alone as I expected it would be merged through MFD tree, so there should not be any merging issues on my side. Thanks for the notice. Jonathan, can you guarantee the same for the iio parts ? I have also been avoiding taking any of these and there are unlikely to be any iio wide changes merging at this stage in cycle. Hence these going through MFD is best plan. Lars raised a couple of issues so would be best to wait for his ack if he hasn't already looked at this revision. Thanks Jonathan. Sabastian, hold on before reworking your patchset. Cheers, Samuel. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- 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 06/11/2013 06:27 PM, Jonathan Cameron wrote: Samuel Ortiz sa...@linux.intel.com wrote: Hi Dmitry, On Tue, Jun 11, 2013 at 09:04:16AM -0700, Dmitry Torokhov wrote: On Tue, Jun 11, 2013 at 04:23:58PM +0200, Samuel Ortiz wrote: Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. 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. Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. From what I can see from it, and please correct me if I'm wrong, the iio and input changes depend on the mfd ones, and not the other way around. If that's so, I'm going to ask you to reshuffle your patch set and separate the MFD changes from the iio and input ones. I'll take the MFD ones and will create an immutable branch for Jonathan and Dmitry to pull from and apply the iio and input changes on top of it. Merge conflicts should be mostly avoided that way. I purposely left this driver alone as I expected it would be merged through MFD tree, so there should not be any merging issues on my side. Thanks for the notice. Jonathan, can you guarantee the same for the iio parts ? I have also been avoiding taking any of these and there are unlikely to be any iio wide changes merging at this stage in cycle. Hence these going through MFD is best plan. Lars raised a couple of issues so would be best to wait for his ack if he hasn't already looked at this revision. The IIO bits look fine to me in this version. - Lars -- 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 1/6] omap: mailbox: check iomem resource before dereferencing it
Add a NULL check for iomem resource in mailbox probe functions. Signed-off-by: Fernando Guzman Lugo lugo.ferna...@gmail.com Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/mach-omap1/mailbox.c | 3 +++ arch/arm/mach-omap2/mailbox.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c index efc8f20..a343d5f 100644 --- a/arch/arm/mach-omap1/mailbox.c +++ b/arch/arm/mach-omap1/mailbox.c @@ -152,6 +152,9 @@ static int omap1_mbox_probe(struct platform_device *pdev) list[0]-irq = platform_get_irq_byname(pdev, dsp); mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (!mem) + return -ENOENT; + mbox_base = ioremap(mem-start, resource_size(mem)); if (!mbox_base) return -ENOMEM; diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 0b08026..9fe0bf2 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -382,6 +382,9 @@ static int omap2_mbox_probe(struct platform_device *pdev) } mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (!mem) + return -ENOENT; + mbox_base = ioremap(mem-start, resource_size(mem)); if (!mbox_base) return -ENOMEM; -- 1.8.2 -- 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 0/6] move omap mailbox to drivers minor fixes
Hi, This is an updated series addressing review comments from Russ Dill. Main changes in v2: === - Dropped the patch omap: mailbox: check for NULL nb in mailbox_put - Removed the mailbox device attr data addition to OMAP4 hwmod files, the hwmod cleanup of irqlines for 3.11 would cause the mailbox probe to fail anyway when enabled. The data would have to be removed when DT node for mailbox is added anyway, and there are no current active users within the tree. - Other minor comments and patch description changes as per review comments. I have tested this series on Panda 4 (using the removed OMAP4 hwmod changes on top of the series) and on Beagle-XM. v1: == The series moves the OMAP mailbox code to drivers/mailbox folder and includes other minor fixes. The OMAP mailbox code is disabled for couple of releases now because of multi-platform support, and the move enables the driver to be built again and be functional. These also serve as the base preparatory patches for adapting the OMAP mailbox code to the upcoming mailbox framework, and for device-tree conversion. http://marc.info/?l=linux-omapm=137065697924665w=2 Suman Anna (6): omap: mailbox: check iomem resource before dereferencing it omap: mailbox: call request_irq after mbox queues are allocated omap: mailbox: correct the argument type for irq ops ARM: OMAP2+: mbox: remove dependencies with soc.h ARM: OMAP2+: add user and fifo info to mailbox platform data mailbox/omap: move the OMAP mailbox framework to drivers arch/arm/configs/omap1_defconfig | 3 +- arch/arm/mach-omap1/Makefile | 4 - arch/arm/mach-omap2/Makefile | 3 - arch/arm/mach-omap2/devices.c | 13 +- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 14 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 13 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 + arch/arm/plat-omap/Kconfig | 16 -- arch/arm/plat-omap/Makefile| 3 - drivers/mailbox/Kconfig| 34 +++ drivers/mailbox/Makefile | 6 + .../mailbox.c = drivers/mailbox/mailbox-omap1.c | 12 +- .../mailbox.c = drivers/mailbox/mailbox-omap2.c | 276 - .../mailbox.c = drivers/mailbox/omap-mailbox.c| 54 +++- .../plat/mailbox.h = drivers/mailbox/omap-mbox.h | 70 ++ drivers/remoteproc/Kconfig | 3 +- drivers/remoteproc/omap_remoteproc.c | 2 +- drivers/staging/tidspbridge/Kconfig| 3 +- .../tidspbridge/include/dspbridge/host_os.h| 2 +- include/linux/omap-mailbox.h | 29 +++ include/linux/platform_data/mailbox-omap.h | 58 + 21 files changed, 355 insertions(+), 276 deletions(-) rename arch/arm/mach-omap1/mailbox.c = drivers/mailbox/mailbox-omap1.c (94%) rename arch/arm/mach-omap2/mailbox.c = drivers/mailbox/mailbox-omap2.c (59%) rename arch/arm/plat-omap/mailbox.c = drivers/mailbox/omap-mailbox.c (92%) rename arch/arm/plat-omap/include/plat/mailbox.h = drivers/mailbox/omap-mbox.h (54%) create mode 100644 include/linux/omap-mailbox.h create mode 100644 include/linux/platform_data/mailbox-omap.h -- 1.8.2 -- 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 5/6] ARM: OMAP2+: add user and fifo info to mailbox platform data
The different generations of OMAP2+ SoCs have almost the same
mailbox IP, but the IP has configurable parameters for number
of users (interrupts it can generate out towards processors)
and number of fifos (the base unidirectional h/w communication
channel). This data cannot be read from any registers, and so
has been added to the platform data.
This data together with the interrupt-type configuration can be
used in properly figuring out the number of registers to save
and restore in the OMAP mailbox driver code.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 2 ++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 2 ++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 2 ++
include/linux/platform_data/mailbox-omap.h | 5 +
4 files changed, 11 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index dbcb928..d8b9d60 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -173,6 +173,8 @@ static struct omap_mbox_dev_info omap2420_mailbox_info[] = {
};
static struct omap_mbox_pdata omap2420_mailbox_attrs = {
+ .num_users = 4,
+ .num_fifos = 6,
.info_cnt = ARRAY_SIZE(omap2420_mailbox_info),
.info = omap2420_mailbox_info,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index df2f874..5b90834 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -176,6 +176,8 @@ static struct omap_mbox_dev_info omap2430_mailbox_info[] = {
};
static struct omap_mbox_pdata omap2430_mailbox_attrs = {
+ .num_users = 4,
+ .num_fifos = 6,
.info_cnt = ARRAY_SIZE(omap2430_mailbox_info),
.info = omap2430_mailbox_info,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 9ac5122..8e4cbc9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1511,6 +1511,8 @@ static struct omap_mbox_dev_info omap3xxx_mailbox_info[]
= {
};
static struct omap_mbox_pdata omap3xxx_mailbox_attrs = {
+ .num_users = 2,
+ .num_fifos = 2,
.info_cnt = ARRAY_SIZE(omap3xxx_mailbox_info),
.info = omap3xxx_mailbox_info,
};
diff --git a/include/linux/platform_data/mailbox-omap.h
b/include/linux/platform_data/mailbox-omap.h
index 676cd64..4631dbb 100644
--- a/include/linux/platform_data/mailbox-omap.h
+++ b/include/linux/platform_data/mailbox-omap.h
@@ -41,11 +41,16 @@ struct omap_mbox_dev_info {
* struct omap_mbox_pdata - OMAP mailbox platform data
* @intr_type: type of interrupt configuration registers used
while programming mailbox queue interrupts
+ * @num_users: number of users (processor devices) that the mailbox
+ * h/w block can interrupt
+ * @num_fifos: number of h/w fifos within the mailbox h/w block
* @info_cnt: number of mailbox devices for the platform
* @info: array of mailbox device attributes
*/
struct omap_mbox_pdata {
u32 intr_type;
+ u32 num_users;
+ u32 num_fifos;
u32 info_cnt;
struct omap_mbox_dev_info *info;
};
--
1.8.2
--
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 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 7.7982 Mbps (FIFO enabled), * for RX from 6.5120 Mbps (FIFO disabled) to 7.5461 Mbps (FIFO enabled). The FIFO sanity test on OMAP5 Panda board also has been done. The FIFO could be enabled for MCSPI by ti,spi-fifo-enabled in DT. If enabled, driver will calculate the largest possible FIFO buffer size taking into account MCSPI FIFO constraints for each SPI transfer. 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. 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 Documentation/devicetree/bindings/spi/omap-spi.txt |8 + drivers/spi/spi-omap2-mcspi.c | 173 +--- 2 files changed, 158 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 v2 6/6] mailbox/omap: move the OMAP mailbox framework to drivers
The mailbox hardware (in OMAP) uses a queued mailbox interrupt
mechanism that provides a communication channel between processors
through a set of registers and their associated interrupt signals
by sending and receiving messages.
The OMAP mailbox framework/driver code is moved to be under
drivers/mailbox, in preparation for adapting to a common mailbox
driver framework. This allows the build for OMAP mailbox to be
enabled (it was disabled during the multi-platform support).
As part of the migration from plat and mach code:
- Kconfig symbols have been renamed to build OMAP1 or OMAP2+ drivers.
- mailbox.h under plat-omap/plat/include has been split into a public
and private header files. The public header has only the API related
functions and types.
- The module name mailbox.ko from plat-omap is changed to
omap-mailbox.ko
- The module name mailbox_mach.ko from mach-omapX is changed as
mailbox_omap1.ko for OMAP1
mailbox_omap2.ko for OMAP2+
Cc: Tony Lindgren t...@atomide.com
[gre...@linuxfoundation.org: ack for staging part]
Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Omar Ramirez Luna omar.rami...@copitl.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/configs/omap1_defconfig | 3 +-
arch/arm/mach-omap1/Makefile | 4 --
arch/arm/mach-omap2/Makefile | 3 -
arch/arm/mach-omap2/devices.c | 4 +-
arch/arm/plat-omap/Kconfig | 16 -
arch/arm/plat-omap/Makefile| 3 -
drivers/mailbox/Kconfig| 34 +++
drivers/mailbox/Makefile | 6 ++
.../mailbox.c = drivers/mailbox/mailbox-omap1.c | 3 +-
.../mailbox.c = drivers/mailbox/mailbox-omap2.c | 8 +--
.../mailbox.c = drivers/mailbox/omap-mailbox.c| 36 +++-
.../plat/mailbox.h = drivers/mailbox/omap-mbox.h | 68 +-
drivers/remoteproc/Kconfig | 3 +-
drivers/remoteproc/omap_remoteproc.c | 2 +-
drivers/staging/tidspbridge/Kconfig| 3 +-
.../tidspbridge/include/dspbridge/host_os.h| 2 +-
include/linux/omap-mailbox.h | 29 +
17 files changed, 135 insertions(+), 92 deletions(-)
rename arch/arm/mach-omap1/mailbox.c = drivers/mailbox/mailbox-omap1.c (99%)
rename arch/arm/mach-omap2/mailbox.c = drivers/mailbox/mailbox-omap2.c (98%)
rename arch/arm/plat-omap/mailbox.c = drivers/mailbox/omap-mailbox.c (92%)
rename arch/arm/plat-omap/include/plat/mailbox.h =
drivers/mailbox/omap-mbox.h (55%)
create mode 100644 include/linux/omap-mailbox.h
diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/omap1_defconfig
index 9940f7b..d74edba 100644
--- a/arch/arm/configs/omap1_defconfig
+++ b/arch/arm/configs/omap1_defconfig
@@ -26,7 +26,8 @@ CONFIG_ARCH_OMAP=y
CONFIG_ARCH_OMAP1=y
CONFIG_OMAP_RESET_CLOCKS=y
# CONFIG_OMAP_MUX is not set
-CONFIG_OMAP_MBOX_FWK=y
+CONFIG_MAILBOX=y
+CONFIG_OMAP1_MBOX=y
CONFIG_OMAP_32K_TIMER=y
CONFIG_OMAP_DM_TIMER=y
CONFIG_ARCH_OMAP730=y
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 222d58c..3889b6c 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -19,10 +19,6 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
# Power Management
obj-$(CONFIG_PM) += pm.o sleep.o
-# DSP
-obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o
-mailbox_mach-objs := mailbox.o
-
i2c-omap-$(CONFIG_I2C_OMAP):= i2c.o
obj-y += $(i2c-omap-m) $(i2c-omap-y)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 55a9d67..f2d19af 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -203,9 +203,6 @@ obj-$(CONFIG_ARCH_OMAP4)+=
omap_hwmod_44xx_data.o
obj-$(CONFIG_OMAP3_EMU)+= emu.o
obj-$(CONFIG_HW_PERF_EVENTS) += pmu.o
-obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o
-mailbox_mach-objs := mailbox.o
-
iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o
obj-y += $(iommu-m) $(iommu-y)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 4c97a86..73762ac 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -328,7 +328,7 @@ int __init omap4_keyboard_init(struct
omap4_keypad_platform_data
return 0;
}
-#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
+#if defined(CONFIG_OMAP2PLUS_MBOX) || defined(CONFIG_OMAP2PLUS_MBOX_MODULE)
static inline void __init omap_init_mbox(void)
{
struct omap_hwmod *oh;
@@ -352,7 +352,7 @@ static inline void __init omap_init_mbox(void)
}
#else
static inline void omap_init_mbox(void) { }
-#endif /* CONFIG_OMAP_MBOX_FWK */
+#endif /* CONFIG_OMAP2PLUS_MBOX */
static inline void
[PATCH v2 3/6] omap: mailbox: correct the argument type for irq ops
The argument type used in the actual individual omap_mbox_ops
for irqs should be omap_mbox_irq_t instead of omap_mbox_type_t.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap1/mailbox.c | 6 +++---
arch/arm/mach-omap2/mailbox.c | 15 ---
2 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index a343d5f..7246a52 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -86,21 +86,21 @@ static int omap1_mbox_fifo_full(struct omap_mbox *mbox)
/* irq */
static void
-omap1_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_type_t irq)
+omap1_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
if (irq == IRQ_RX)
enable_irq(mbox-irq);
}
static void
-omap1_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_type_t irq)
+omap1_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
if (irq == IRQ_RX)
disable_irq(mbox-irq);
}
static int
-omap1_mbox_is_irq(struct omap_mbox *mbox, omap_mbox_type_t irq)
+omap1_mbox_is_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
if (irq == IRQ_TX)
return 0;
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 9fe0bf2..b01aae6 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -61,9 +61,6 @@ struct omap_mbox2_priv {
unsigned long irqdisable;
};
-static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
- omap_mbox_type_t irq);
-
static inline unsigned int mbox_read_reg(size_t ofs)
{
return __raw_readl(mbox_base + ofs);
@@ -124,8 +121,7 @@ static int omap2_mbox_fifo_full(struct omap_mbox *mbox)
}
/* Mailbox IRQ handle functions */
-static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
- omap_mbox_type_t irq)
+static void omap2_mbox_enable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
struct omap_mbox2_priv *p = mbox-priv;
u32 l, bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit;
@@ -135,8 +131,7 @@ static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
mbox_write_reg(l, p-irqenable);
}
-static void omap2_mbox_disable_irq(struct omap_mbox *mbox,
- omap_mbox_type_t irq)
+static void omap2_mbox_disable_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
struct omap_mbox2_priv *p = mbox-priv;
u32 bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit;
@@ -147,8 +142,7 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox,
mbox_write_reg(bit, p-irqdisable);
}
-static void omap2_mbox_ack_irq(struct omap_mbox *mbox,
- omap_mbox_type_t irq)
+static void omap2_mbox_ack_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
struct omap_mbox2_priv *p = mbox-priv;
u32 bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit;
@@ -159,8 +153,7 @@ static void omap2_mbox_ack_irq(struct omap_mbox *mbox,
mbox_read_reg(p-irqstatus);
}
-static int omap2_mbox_is_irq(struct omap_mbox *mbox,
- omap_mbox_type_t irq)
+static int omap2_mbox_is_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
{
struct omap_mbox2_priv *p = mbox-priv;
u32 bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit;
--
1.8.2
--
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 2/6] omap: mailbox: call request_irq after mbox queues are allocated
The OMAP mailbox startup code is enabling the interrupt before any
of the associated mailbox queues are allocated. Move this code so
that the interrupt configuration for a mailbox is together.
Signed-off-by: Fernando Guzman Lugo lugo.ferna...@gmail.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/plat-omap/mailbox.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 42377ef..f65eaf0 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -261,13 +261,6 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
}
if (!mbox-use_count++) {
- ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
- mbox-name, mbox);
- if (unlikely(ret)) {
- pr_err(failed to register mailbox interrupt:%d\n,
- ret);
- goto fail_request_irq;
- }
mq = mbox_queue_alloc(mbox, NULL, mbox_tx_tasklet);
if (!mq) {
ret = -ENOMEM;
@@ -282,17 +275,24 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
}
mbox-rxq = mq;
mq-mbox = mbox;
+ ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
+ mbox-name, mbox);
+ if (unlikely(ret)) {
+ pr_err(failed to register mailbox interrupt:%d\n,
+ ret);
+ goto fail_request_irq;
+ }
omap_mbox_enable_irq(mbox, IRQ_RX);
}
mutex_unlock(mbox_configured_lock);
return 0;
+fail_request_irq:
+ mbox_queue_free(mbox-rxq);
fail_alloc_rxq:
mbox_queue_free(mbox-txq);
fail_alloc_txq:
- free_irq(mbox-irq, mbox);
-fail_request_irq:
if (mbox-ops-shutdown)
mbox-ops-shutdown(mbox);
mbox-use_count--;
--
1.8.2
--
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 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.
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.
Signed-off-by: Illia Smyrnov illia.smyr...@ti.com
---
Documentation/devicetree/bindings/spi/omap-spi.txt |8 +
drivers/spi/spi-omap2-mcspi.c | 154 +--
2 files changed, 145 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c..636c1dc 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -9,6 +9,14 @@ Required properties:
- ti,pindir-d0-out-d1-in: Select the D0 pin as output and D1 as
input. The default is D0 as input and
D1 as output.
+- ti,spi-fifo-enabled: Enable use of the FIFO buffer. If enabled,
+ the largest possible FIFO buffer size will
+ be calculated and setup for each SPI transfer.
+ Even if the FIFO is enabled, 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. The FIFO buffer is disabled by default.
Example:
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 707f1db..220152a 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -39,12 +39,15 @@
#include linux/of.h
#include linux/of_device.h
#include linux/pinctrl/consumer.h
+#include linux/gcd.h
#include linux/spi/spi.h
#include linux/platform_data/spi-omap2-mcspi.h
#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,8 @@ struct omap2_mcspi {
struct omap2_mcspi_dma *dma_channels;
struct device *dev;
struct omap2_mcspi_regs ctx;
+ int fifo_depth;
+ unsigned intfifo_enabled:1;
unsigned intpin_dir:1;
};
@@ -258,6 +268,60 @@ 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);
+ if (!mcspi-fifo_enabled)
+ return;
+
+ 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)
+
[PATCH v2 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 illia.smyr...@ti.com
---
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 v2 4/6] ARM: OMAP2+: mbox: remove dependencies with soc.h
The OMAP mailbox platform driver code has been cleaned up to
remove the dependencies with soc.h in preparation for moving
the mailbox code to drivers folder.
The code relied on cpu_is_xxx/soc_is_xxx macros previously to
pick the the right set of mailbox devices and register with the
mailbox driver. This data is now represented in a concise format
and moved to the respective omap_hwmod data files and published
to the driver through the platform data.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/devices.c | 9 +-
arch/arm/mach-omap2/mailbox.c | 254 +++--
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 12 ++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 11 ++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 11 ++
arch/arm/plat-omap/include/plat/mailbox.h | 2 +-
include/linux/platform_data/mailbox-omap.h | 53 ++
7 files changed, 189 insertions(+), 163 deletions(-)
create mode 100644 include/linux/platform_data/mailbox-omap.h
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 4269fc1..4c97a86 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -20,6 +20,7 @@
#include linux/pinctrl/machine.h
#include linux/platform_data/omap4-keypad.h
#include linux/platform_data/omap_ocp2scp.h
+#include linux/platform_data/mailbox-omap.h
#include linux/usb/omap_control_usb.h
#include asm/mach-types.h
@@ -332,14 +333,20 @@ static inline void __init omap_init_mbox(void)
{
struct omap_hwmod *oh;
struct platform_device *pdev;
+ struct omap_mbox_pdata *pdata;
oh = omap_hwmod_lookup(mailbox);
if (!oh) {
pr_err(%s: unable to find hwmod\n, __func__);
return;
}
+ if (!oh-dev_attr) {
+ pr_err(%s: hwmod doesn't have valid attrs\n, __func__);
+ return;
+ }
- pdev = omap_device_build(omap-mailbox, -1, oh, NULL, 0);
+ pdata = (struct omap_mbox_pdata *)oh-dev_attr;
+ pdev = omap_device_build(omap-mailbox, -1, oh, pdata, sizeof(*pdata));
WARN(IS_ERR(pdev), %s: could not build device, err %ld\n,
__func__, PTR_ERR(pdev));
}
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index b01aae6..de21198 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -11,16 +11,16 @@
*/
#include linux/module.h
+#include linux/slab.h
#include linux/clk.h
#include linux/err.h
#include linux/platform_device.h
#include linux/io.h
#include linux/pm_runtime.h
+#include linux/platform_data/mailbox-omap.h
#include plat/mailbox.h
-#include soc.h
-
#define MAILBOX_REVISION 0x000
#define MAILBOX_MESSAGE(m) (0x040 + 4 * (m))
#define MAILBOX_FIFOSTATUS(m) (0x080 + 4 * (m))
@@ -59,6 +59,7 @@ struct omap_mbox2_priv {
u32 notfull_bit;
u32 ctx[OMAP4_MBOX_NR_REGS];
unsigned long irqdisable;
+ u32 intr_type;
};
static inline unsigned int mbox_read_reg(size_t ofs)
@@ -136,7 +137,11 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
struct omap_mbox2_priv *p = mbox-priv;
u32 bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit;
- if (!cpu_is_omap44xx())
+ /*
+* Read and update the interrupt configuration register for pre-OMAP4.
+* OMAP4 and later SoCs have a dedicated interrupt disabling register.
+*/
+ if (!p-intr_type)
bit = mbox_read_reg(p-irqdisable) ~bit;
mbox_write_reg(bit, p-irqdisable);
@@ -168,7 +173,8 @@ static void omap2_mbox_save_ctx(struct omap_mbox *mbox)
int i;
struct omap_mbox2_priv *p = mbox-priv;
int nr_regs;
- if (cpu_is_omap44xx())
+
+ if (p-intr_type)
nr_regs = OMAP4_MBOX_NR_REGS;
else
nr_regs = MBOX_NR_REGS;
@@ -185,7 +191,8 @@ static void omap2_mbox_restore_ctx(struct omap_mbox *mbox)
int i;
struct omap_mbox2_priv *p = mbox-priv;
int nr_regs;
- if (cpu_is_omap44xx())
+
+ if (p-intr_type)
nr_regs = OMAP4_MBOX_NR_REGS;
else
nr_regs = MBOX_NR_REGS;
@@ -213,188 +220,113 @@ static struct omap_mbox_ops omap2_mbox_ops = {
.restore_ctx= omap2_mbox_restore_ctx,
};
-/*
- * MAILBOX 0: ARM - DSP,
- * MAILBOX 1: ARM - DSP.
- * MAILBOX 2: ARM - IVA,
- * MAILBOX 3: ARM - IVA.
- */
-
-/* FIXME: the following structs should be filled automatically by the user id
*/
-
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP2)
-/* DSP */
-static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
- .tx_fifo = {
- .msg= MAILBOX_MESSAGE(0),
- .fifo_stat = MAILBOX_FIFOSTATUS(0),
- },
- .rx_fifo = {
- .msg
Re: [PATCH 10/22] mfd/ti_am335x_tscadc: Add DT support
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com Signed-off-by: Patil, Rachna rac...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com [bigeasy: module alias, rename to ti,am3359-tscadc as it was tested on AM3359] I honestly can't tell if this is a change from the last version of your patchset or a description of this patch changes in general. This is cluttering your commit logs, please remove this as well. I took the original patch. Every change I made to it because people asked to merge changes into the patch where the problem occurred I added it here before my sign-off. In the end I would like not to post a patch with From: != me and don't make change which the original author did not do. Also dropping their authorship isn't nice. What could we agree on? Generally speaking, if it is necessary to merge various author's patches into one, then you can the merger will tend to take authorship of the commit. Note that just because you are the author of the commit, it doesn't mean you authored the patch. I also use the rule of thumb that if you make significant changes to a patch, then you can also assume authorship too. I'll leave the 'how much is significant' to your own good judgement. If you're just making a few fixups, then just add your SOB in the normal way. That should be enough reward for a mere few patch fixes. Adding little 'I-did-this' notes to the commit log should mostly be avoided IMO. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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/3] ARM: dts: Add headers with constants for MTD partitions
Hello Stephen, On 06/11/2013 06:24 PM, Stephen Warren wrote: On 06/11/2013 08:48 AM, Florian Vaussard wrote: These constants can be used to easily declare MTD partitions inside DTS. The constants MTDPART_OFS_* are purposely not included. Indeed, parse_ofpart_partitions() is expecting u64, but a DT cell is u32. Negative constants, as defined by MTDPART_OFS_*, would be wrongly interpreted by parse_ofpart_partitions(). Two cells should be used to correctly encode the negative constants, but this breaks current usage. I think addition of common headers like this needs an ack from Grant/Rob. I CC'd them here. Indeed. Thank you. diff --git a/include/dt-bindings/mtd/partitions.h b/include/dt-bindings/mtd/partitions.h + * This header provides constants used with MTD partitions. ... +/* Partition size */ +#define MTDPART_SIZ_FULL 0 Which binding document in Documentation/devicetree/bindings is this definition associated with? The comment above should really mention this. Documentation/devicetree/bindings/mtd/partition.txt doesn't seem to mention this value. Mmmh I was not seeing this as a DT binding, strictly speaking. It was already used with legacy board files. Otherwise we should also update the binding for constants related to GPIO, IRQ,... But I agree that a line inside the documentation never killed someone. diff --git a/include/dt-bindings/sizes.h b/include/dt-bindings/sizes.h ... +#define SZ_1G 0x4000 +#define SZ_2G 0x8000 + +#endif For MTD partitions specifically, SZ_4G and onwards would be useful in theory, although that would end up putting two cell values into a single macro. and then the values couldn't be added/or'd together. So, I'm not really sure if we want to add those larger values, but food for thought... It is maybe feasible to define a macro splitting the u64 into two u32 cells? But this can be done afterwards when need arises. Best regards, Florian -- 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 3/3] ARM: dts: OMAP3: Use MTD constants for OMAP3 boards
Hello Javier,
On 06/11/2013 05:29 PM, Javier Martinez Canillas wrote:
On 06/11/2013 04:48 PM, Florian Vaussard wrote:
Use the MTD constants for NAND and OneNAND nodes used in OMAP3
DTS.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/omap3-devkit8000.dts | 10 +-
arch/arm/boot/dts/omap3-igep0020.dts | 10 +-
arch/arm/boot/dts/omap3-igep0030.dts | 10 +-
arch/arm/boot/dts/omap3430-sdp.dts | 28 ++--
4 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts
b/arch/arm/boot/dts/omap3-devkit8000.dts
index 5be71b1..08699cb 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -143,27 +143,27 @@
x-loader@0 {
label = X-Loader;
- reg = 0 0x8;
+ reg = (0 * SZ_128K) (4 * SZ_128K);
};
bootloaders@8 {
label = U-Boot;
- reg = 0x8 0x1e;
+ reg = (4 * SZ_128K) (15 * SZ_128K);
};
bootloaders_env@26 {
label = U-Boot Env;
- reg = 0x26 0x2;
+ reg = (19 * SZ_128K) (1 * SZ_128K);
};
kernel@28 {
label = Kernel;
- reg = 0x28 0x40;
+ reg = (20 * SZ_128K) (32 * SZ_128K);
};
filesystem@68 {
label = File System;
- reg = 0x68 0xf98;
+ reg = (52 * SZ_128K) MTDPART_SIZ_FULL;
};
};
};
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e8c4828..3476b3c 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -97,23 +97,23 @@
partition@0 {
label = SPL;
- reg = 0 0x10;
+ reg = (0 * SZ_256K) (4 * SZ_256K);
};
partition@0x8 {
label = U-Boot;
- reg = 0x10 0x18;
+ reg = (4 * SZ_256K) (6 * SZ_256K);
};
partition@0x1c {
label = Environment;
- reg = 0x28 0x10;
+ reg = (10 * SZ_256K) (4 * SZ_256K);
};
partition@0x28 {
label = Kernel;
- reg = 0x38 0x30;
+ reg = (14 * SZ_256K) (12 * SZ_256K);
};
partition@0x78 {
label = Filesystem;
- reg = 0x68 0x1f98;
+ reg = (26 * SZ_256K) MTDPART_SIZ_FULL;
};
};
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts
b/arch/arm/boot/dts/omap3-igep0030.dts
index 644d053..e4f078c 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -72,23 +72,23 @@
partition@0 {
label = SPL;
- reg = 0 0x10;
+ reg = (0 * SZ_256K) (4 * SZ_256K);
};
partition@0x8 {
label = U-Boot;
- reg = 0x10 0x18;
+ reg = (4 * SZ_256K) (6 * SZ_256K);
};
partition@0x1c {
label = Environment;
- reg = 0x28 0x10;
+ reg = (10 * SZ_256K) (4 * SZ_256K);
};
partition@0x28 {
label = Kernel;
- reg = 0x38 0x30;
+ reg = (14 * SZ_256K) (12 * SZ_256K);
};
partition@0x78 {
label = Filesystem;
- reg = 0x68 0x1f98;
+ reg = (26 * SZ_256K) MTDPART_SIZ_FULL;
};
};
};
Hi Florian,
I don't have access to my IGEP board so I can test it right now but the patch
looks good to me.
In fact I wanted to use MTDPART_SIZ_FULL when added the NAND nodes since not all
IGEP boards have 512MB flash but I didn't know that a value of 0 meant that.
I had the same problem, and found that 0 was correctly parsed and later
expanded to
the correct value when probing the NAND.
So thanks a lot for doing this!
Acked-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Thank you.
Florian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: [PATCH 3/3] ARM: dts: OMAP3: Use MTD constants for OMAP3 boards
Hello, On 06/11/2013 06:27 PM, Stephen Warren wrote: On 06/11/2013 08:48 AM, Florian Vaussard wrote: Use the MTD constants for NAND and OneNAND nodes used in OMAP3 DTS. I don't quite understand the split between patches 2/3 and 3/3; isn't the edit to omap3-overo.dtsi (part of) a board file, and hence logically part of this patch? I'd be tempted just to squash the two together. But, this is a nit; not a big deal. Patch 2/3 was adding a new node, whereas patch 3/3 was converting existing nodes. But your point is perfectly valid. Regards, Florian -- 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
Hi Jonathan, On Tue, Jun 11, 2013 at 05:27:48PM +0100, Jonathan Cameron wrote: Samuel Ortiz sa...@linux.intel.com wrote: On Tue, Jun 11, 2013 at 09:04:16AM -0700, Dmitry Torokhov wrote: On Tue, Jun 11, 2013 at 04:23:58PM +0200, Samuel Ortiz wrote: Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. 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. Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. From what I can see from it, and please correct me if I'm wrong, the iio and input changes depend on the mfd ones, and not the other way around. If that's so, I'm going to ask you to reshuffle your patch set and separate the MFD changes from the iio and input ones. I'll take the MFD ones and will create an immutable branch for Jonathan and Dmitry to pull from and apply the iio and input changes on top of it. Merge conflicts should be mostly avoided that way. I purposely left this driver alone as I expected it would be merged through MFD tree, so there should not be any merging issues on my side. Thanks for the notice. Jonathan, can you guarantee the same for the iio parts ? I have also been avoiding taking any of these and there are unlikely to be any iio wide changes merging at this stage in cycle. Hence these going through MFD is best plan. Thanks. Then I'm willing to try and see if linux-next does not complain too hard about that. Sebastian, please address the commit log and cosmetic issues I pointed out, keep the regmap code and I'll pull this patchset in. If further down the road we get some nasty merge conflicts from linux-next, I might ask you to re-work it. Let's see. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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 06/11/2013 03:23 PM, Samuel Ortiz wrote: Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. 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. Then, this is a pretty big patchset, with iio, input and mfd all mixed together and it is likely to create merge conflicts. From what I can see from it, and please correct me if I'm wrong, the iio and input changes depend on the mfd ones, and not the other way around. If that's so, I'm going to ask you to reshuffle your patch set and separate the MFD changes from the iio and input ones. I'll take the MFD ones and will create an immutable branch for Jonathan and Dmitry to pull from and apply the iio and input changes on top of it. Merge conflicts should be mostly avoided that way. I'd just like to note for future reference that I would prefer Samuels approach of such a branch for future cases where things touch on iio and another subsystem. Now as I've expressed I am happy with this set going through mfd but there is never anything wrong with agreeing how things 'should' be done ;) AFAICT, only patch #2 should be kept with input and iio bits mixed together with MFD as otherwise this would introduce functional breakage. Otherwise, all MFD bits from the other patches could be either separated or merged together (e.g. MFD bits from patches #6 and #8, and #16 and #17). Does that sound doable to you ? Cheers, Samuel. -- 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 10/22] mfd/ti_am335x_tscadc: Add DT support
On Tue, 11 Jun 2013, Sebastian Andrzej Siewior wrote: On 06/11/2013 05:05 PM, Samuel Ortiz wrote: Hi Sebastian, Hi Samuel, On Tue, Jun 11, 2013 at 04:42:30PM +0200, Sebastian Andrzej Siewior wrote: In the end I would like not to post a patch with From: != me and don't make change which the original author did not do. Also dropping their authorship isn't nice. What could we agree on? You probably don't want to change authorship unless the final patch is really far from the original one. In which case you can change it and mention the original author name in the commit log. If you have only made a few changes on top of the original patch, please say so explicitely in the commit log. Don't bother if we're talking about small changes or cosmetic ones. But your commit log has to be readable and clear. Commit 06c9494 on of many examples where cosmetic are recorded. But to make some progress I rewrite the commit log to resolve this and don't add anything to the sign-off area. If you are submitting the patch, you still have to add your own SOB. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 3/5] gpio/omap: Add DT support to GPIO driver
On Fri, 26 Apr 2013 16:31:24 -0500, Jon Hunter jon-hun...@ti.com wrote:
On 04/26/2013 02:31 AM, Linus Walleij wrote:
On Wed, Apr 17, 2013 at 2:41 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
So:
+static int omap_gpio_irq_domain_xlate(struct irq_domain *d,
+ struct device_node *ctrlr,
+ const u32 *intspec, unsigned int
intsize,
+ irq_hw_number_t *out_hwirq,
+ unsigned int *out_type)
+{
+ int ret;
+ struct gpio_bank *bank = d-host_data;
+ int gpio = bank-chip.base + intspec[0];
+
+ if (WARN_ON(intsize 2))
+ return -EINVAL;
+
+ ret = gpio_request_one(gpio, GPIOF_IN, ctrlr-full_name);
+ if (ret)
+ return ret;
So how to figure out if a device is already requesting this GPIO
on some orthogonal axis?
I really don't think that is necessary. Hopefully, my other email [1]
elaborates on why. Let me know if this makes sense.
I would agree here. If the irq specified happens to be a GPIO; then the
onus is on the GPIO/IRQ controller driver to make sure that GPIO is
actually set up to work as an IRQ.
g.
--
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: dts: omap3-devkit8000: fix NAND memory binding
On Tue, 11 Jun 2013 16:53:19 +0200, Florian Vaussard florian.vauss...@epfl.ch wrote: Hello, On 05/31/2013 03:49 PM, Florian Vaussard wrote: Hello, Gentle ping. Does someone has any comments on this fix? Can someone tests on the real hardware? Nobody has this hardware somewhere in a drawer? :-) I've just gone ahead and applied it. As you say it's broken anyway, so if this is also broken, then at least it is /less/ broken. :) g. Regards, Florian Regards, Florian On 05/23/2013 10:11 AM, Florian Vaussard wrote: Commit d36b4cd 'ARM: OMAP2+: Add additional GPMC timing parameters' updated GPMC binding, but omap3-devkit8000 was not updated accordingly, resulting in a broken configuration. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch --- arch/arm/boot/dts/omap3-devkit8000.dts | 29 +++-- 1 files changed, 15 insertions(+), 14 deletions(-) diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts b/arch/arm/boot/dts/omap3-devkit8000.dts index 8a5cdcc..e5b35f5 100644 --- a/arch/arm/boot/dts/omap3-devkit8000.dts +++ b/arch/arm/boot/dts/omap3-devkit8000.dts @@ -123,20 +123,21 @@ reg = 0 0 0; /* CS0, offset 0 */ nand-bus-width = 16; -gpmc,sync-clk = 0; -gpmc,cs-on = 0; -gpmc,cs-rd-off = 44; -gpmc,cs-wr-off = 44; -gpmc,adv-on = 6; -gpmc,adv-rd-off = 34; -gpmc,adv-wr-off = 44; -gpmc,we-off = 40; -gpmc,oe-off = 54; -gpmc,access = 64; -gpmc,rd-cycle = 82; -gpmc,wr-cycle = 82; -gpmc,wr-access = 40; -gpmc,wr-data-mux-bus = 0; +gpmc,device-nand; +gpmc,sync-clki-ps = 0; +gpmc,cs-on-ns = 0; +gpmc,cs-rd-off-ns = 44; +gpmc,cs-wr-off-ns = 44; +gpmc,adv-on-ns = 6; +gpmc,adv-rd-off-ns = 34; +gpmc,adv-wr-off-ns = 44; +gpmc,we-off-ns = 40; +gpmc,oe-off-ns = 54; +gpmc,access-ns = 64; +gpmc,rd-cycle-ns = 82; +gpmc,wr-cycle-ns = 82; +gpmc,wr-access-ns = 40; +gpmc,wr-data-mux-bus-ns = 0; #address-cells = 1; #size-cells = 1; -- Florian Vaussard EPFL - STI - IMT - LSRO1 MEB330 - Station 9 1015 Lausanne / Switzerland tel: +41 21 693 78 39 fax: +41 21 693 78 07 http://lsro.epfl.ch ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- 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: dts: Protect pinctrl headers against multiple inclusions
On Tue, 11 Jun 2013 16:50:50 +0200, Florian Vaussard florian.vauss...@epfl.ch wrote: Pinctrl headers were not protected with #ifndef. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch Obviously this needs to go in via whatever tree added the modified header files. Acked-by: Grant Likely grant.lik...@secretlab.ca --- include/dt-bindings/pinctrl/am33xx.h |5 + include/dt-bindings/pinctrl/omap.h |5 + 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/include/dt-bindings/pinctrl/am33xx.h b/include/dt-bindings/pinctrl/am33xx.h index a3fddd4..469e032 100644 --- a/include/dt-bindings/pinctrl/am33xx.h +++ b/include/dt-bindings/pinctrl/am33xx.h @@ -2,6 +2,9 @@ * This header provides constants specific to AM33XX pinctrl bindings. */ +#ifndef _DT_BINDINGS_PINCTRL_AM33XX_H +#define _DT_BINDINGS_PINCTRL_AM33XX_H + #include include/dt-bindings/pinctrl/omap.h /* am33xx specific mux bit defines */ @@ -35,3 +38,5 @@ #undef PIN_OFF_INPUT_PULLDOWN #undef PIN_OFF_WAKEUPENABLE +#endif + diff --git a/include/dt-bindings/pinctrl/omap.h b/include/dt-bindings/pinctrl/omap.h index 370df3f..edbd250 100644 --- a/include/dt-bindings/pinctrl/omap.h +++ b/include/dt-bindings/pinctrl/omap.h @@ -5,6 +5,9 @@ * Copyright (C) 2009-2010 Texas Instruments */ +#ifndef _DT_BINDINGS_PINCTRL_OMAP_H +#define _DT_BINDINGS_PINCTRL_OMAP_H + /* 34xx mux mode options for each pin. See TRM for options */ #define MUX_MODE00 #define MUX_MODE11 @@ -48,3 +51,5 @@ #define PIN_OFF_INPUT_PULLDOWN (OFF_EN | OFF_PULL_EN) #define PIN_OFF_WAKEUPENABLE WAKEUP_EN +#endif + -- 1.7.5.4 ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- 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/5] dwc3: omap: adapt dwc3 to use extcon framework
Hi Kishon, Sorry for late reply. I applied patch1,2 on extcon-linus branch. - http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/log/?h=extcon-linus But, I have comment of patch 3 about dt API. I send comment on patch 3 mailing thread. Thanks, Chanwoo Choi On 06/04/2013 01:13 AM, Kishon Vijay Abraham I wrote: The first three patches deals with cleanup of extcon inorder to get through compilation without any issues. It also adds an API to get extcon device from dt node which I felt was missing. The next two patches deals with adapt dwc3 to use extcon framework. The 4th patch (usb: dwc3: omap: improve error handling of dwc3_omap_probe) should have ideally been sent to Felipe, however since there will be merge conflicts with the 5th patch (usb: dwc3: use extcon fwrk to receive connect/disconnect) in this series, I've sent in the same series. Once this patch series get merged, dwc3 in omap would be functional in device mode. However there is still some discussion on modelling SMPS10 regulator. Once that gets finalized, dwc3 should be functional in host mode as well. Kishon Vijay Abraham I (5): extcon: Add an API to get extcon device from dt node extcon: Kconfig: Make extcon config type as bool extcon: add EXPORT_SYMBOL_GPL for exported functions usb: dwc3: omap: improve error handling of dwc3_omap_probe usb: dwc3: use extcon fwrk to receive connect/disconnect Documentation/devicetree/bindings/usb/omap-usb.txt |5 + drivers/extcon/Kconfig |2 +- drivers/extcon/extcon-class.c | 42 +++ drivers/usb/dwc3/dwc3-omap.c | 133 include/linux/extcon.h |8 ++ include/linux/usb/dwc3-omap.h | 30 - 6 files changed, 168 insertions(+), 52 deletions(-) delete mode 100644 include/linux/usb/dwc3-omap.h -- 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/5] dwc3: omap: adapt dwc3 to use extcon framework
Hi Kishon, I confused patch number. I applied patch2,3 on extcon-linus branch. extcon: Kconfig: Make extcon config type as bool extcon: add EXPORT_SYMBOL_GPL for exported functions And I will reply comment about patch1 soon. extcon: Add an API to get extcon device from dt node Thanks, Chanwoo Choi On 06/04/2013 01:13 AM, Kishon Vijay Abraham I wrote: The first three patches deals with cleanup of extcon inorder to get through compilation without any issues. It also adds an API to get extcon device from dt node which I felt was missing. The next two patches deals with adapt dwc3 to use extcon framework. The 4th patch (usb: dwc3: omap: improve error handling of dwc3_omap_probe) should have ideally been sent to Felipe, however since there will be merge conflicts with the 5th patch (usb: dwc3: use extcon fwrk to receive connect/disconnect) in this series, I've sent in the same series. Once this patch series get merged, dwc3 in omap would be functional in device mode. However there is still some discussion on modelling SMPS10 regulator. Once that gets finalized, dwc3 should be functional in host mode as well. Kishon Vijay Abraham I (5): extcon: Add an API to get extcon device from dt node extcon: Kconfig: Make extcon config type as bool extcon: add EXPORT_SYMBOL_GPL for exported functions usb: dwc3: omap: improve error handling of dwc3_omap_probe usb: dwc3: use extcon fwrk to receive connect/disconnect Documentation/devicetree/bindings/usb/omap-usb.txt |5 + drivers/extcon/Kconfig |2 +- drivers/extcon/extcon-class.c | 42 +++ drivers/usb/dwc3/dwc3-omap.c | 133 include/linux/extcon.h |8 ++ include/linux/usb/dwc3-omap.h | 30 - 6 files changed, 168 insertions(+), 52 deletions(-) delete mode 100644 include/linux/usb/dwc3-omap.h -- 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/5] extcon: Add an API to get extcon device from dt node
Hi Kishon,
On 06/04/2013 01:13 AM, Kishon Vijay Abraham I wrote:
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 kis...@ti.com
---
drivers/extcon/extcon-class.c | 40
include/linux/extcon.h|8
2 files changed, 48 insertions(+)
I don't prefer that add of helper API in extcon core. I want to add
new of helper file as drivers/extcon/of-extcon.c.
So, I add drivers/extcon/of-extcon.c and include/linux/extcon/of-extcon.h
based on your this patch. I will send modified patch at once.
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 60adc04..265d549 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -31,6 +31,7 @@
#include linux/extcon.h
#include linux/slab.h
#include linux/sysfs.h
+#include linux/of_platform.h
/*
* extcon_cable_name suggests the standard cable names for commonly used
@@ -392,6 +393,45 @@ int extcon_set_cable_state(struct extcon_dev *edev,
}
EXPORT_SYMBOL_GPL(extcon_set_cable_state);
+struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev, int index)
+{
+ struct class_dev_iter iter;
+ struct device *extcon_dev;
+ struct device_node *node;
+ 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);
+ }
+
+ class_dev_iter_init(iter, extcon_class, NULL, NULL);
+ while ((extcon_dev = class_dev_iter_next(iter))) {
+ if (extcon_dev-parent != extcon_parent_dev-dev)
+ continue;
+
+ class_dev_iter_exit(iter);
+ return dev_get_drvdata(extcon_dev);
+ }
+
+ class_dev_iter_exit(iter);
Use extcon_get_extcon_dev() instead of using class_dev_iter_init/exit()
+ return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(of_extcon_get_extcon_dev);
+
/**
* extcon_get_extcon_dev() - Get the extcon device instance from the name
* @extcon_name: The extcon name provided with extcon_dev_register()
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index fcb51c8..3858bb9 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -182,6 +182,8 @@ struct extcon_specific_cable_nb {
*/
extern int extcon_dev_register(struct extcon_dev *edev, struct device *dev);
extern void extcon_dev_unregister(struct extcon_dev *edev);
+extern struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev,
+ int index);
extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
/*
@@ -292,6 +294,12 @@ static inline int extcon_set_cable_state(struct
extcon_dev *edev,
return 0;
}
+static inline struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev,
+ int index)
+{
+ return NULL;
+}
+
static inline struct extcon_dev *extcon_get_extcon_dev(const char
*extcon_name)
{
return NULL;
Thanks,
Chanwoo Choi
--
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] extcon: Add an API to get extcon device from dt node
From: Kishon Vijay Abraham I kis...@ti.com
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 kis...@ti.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
---
drivers/extcon/Makefile | 3 +++
drivers/extcon/of-extcon.c | 56
include/linux/extcon/of-extcon.h | 30 +
3 files changed, 89 insertions(+)
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..39cdf95 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -2,9 +2,12 @@
# 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
+
obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
diff --git a/drivers/extcon/of-extcon.c b/drivers/extcon/of-extcon.c
new file mode 100644
index 000..29f82b4
--- /dev/null
+++ b/drivers/extcon/of-extcon.c
@@ -0,0 +1,56 @@
+/*
+ * OF helpers for External connector (extcon) framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Kishon Vijay Abraham I kis...@ti.com
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi cw00.c...@samsung.com
+ *
+ * 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 linux/module.h
+#include linux/slab.h
+#include linux/extcon.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/extcon/of-extcon.h
+
+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..77d01ba
--- /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 kis...@ti.com
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi cw00.c...@samsung.com
+ *
+ * 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)
+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(struct device *dev, int index);
+{
+ return NULL;
+}
+#endif /* CONFIG_OF */
+
+#endif /* __LINUX_OF_EXTCON_H */
--
1.8.0
--
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: Block layer / MMC: Order of segments in SG-list
Hi Jens, Thanks for your email. On Mon, Jun 10, 2013 at 2:15 AM, Jens Axboe ax...@kernel.dk wrote: On Sun, Jun 09 2013, Joel A Fernandes wrote: Hi, So I tried dumping addresses of an SG list in omap_hsmmc driver before it is passed to DMA. I found some interesting traces occasionally such as the below SG list of length 4. [6.758716] (0) length=4096, sg virt addr=c1318000, sg phy addr=81318000 [6.765863] (1) length=4096, sg virt addr=c1317000, sg phy addr=81317000 [6.773011] (2) length=4096, sg virt addr=c1316000, sg phy addr=81316000 [6.780087] (3) length=4096, sg virt addr=c1315000, sg phy addr=81315000 What is interesting is these chunks are really physically contiguous but in reverse order in the list. I think a smarter ordering can actually improve through put considerably and save precious DMA resources by not having to allocate slots for parts of contiguous chunk of physical memory. Is there any particular reason why this might be the case? I traced to find that the SG list is actually prepared by mmc_queue_map_sg - blk_rq_map_sg mmc or the block layer can't do much about the memory it is handed. The sg mappings just reflect the fact that they happened to be in reverse, so to speak. You are right in that having those pages in the right order and being able to merge the segments is a win. Unless you are heavily SG entry starved or your DMA controller has a high per-sg-entry overhead, it's usually not a big deal. We have currently set limits in DMA for maximum of 16 slots, some times I noticed all 16 allocated to contiguous pages but in reverse. :) That said, you should investigate WHY they are in that order :-) Sure , I am thinking of tracing this soon to root cause the page allocations. I am wondering if we can just reorder the SG and write in the reverse order for such detected cases, but yeah like you said no match to allocating them in the right order in the first place. I appreciate your response to my post, thanks! Regards, 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] extcon: Add an API to get extcon device from dt node
On Wed, Jun 12, 2013 at 7:09 AM, Chanwoo Choi cw00.c...@samsung.com wrote:
From: Kishon Vijay Abraham I kis...@ti.com
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 kis...@ti.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
---
drivers/extcon/Makefile | 3 +++
drivers/extcon/of-extcon.c | 56
include/linux/extcon/of-extcon.h | 30 +
3 files changed, 89 insertions(+)
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..39cdf95 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -2,9 +2,12 @@
# 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
+
obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
diff --git a/drivers/extcon/of-extcon.c b/drivers/extcon/of-extcon.c
new file mode 100644
index 000..29f82b4
--- /dev/null
+++ b/drivers/extcon/of-extcon.c
@@ -0,0 +1,56 @@
+/*
+ * OF helpers for External connector (extcon) framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Kishon Vijay Abraham I kis...@ti.com
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi cw00.c...@samsung.com
+ *
+ * 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 linux/module.h
+#include linux/slab.h
+#include linux/extcon.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/extcon/of-extcon.h
+
+struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev, int index)
Can this be simpler name? of_extcon_get_dev or something like that?
+{
+ 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..77d01ba
--- /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 kis...@ti.com
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi cw00.c...@samsung.com
+ *
+ * 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)
+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(struct device *dev, int index);
+{
+ return NULL;
+}
+#endif /* CONFIG_OF */
+
+#endif /* __LINUX_OF_EXTCON_H */
--
1.8.0
--
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
