Re: [PATCH v2 1/2] ARM: configs: Enable TI_EDMA in omap2plus_defconfig
* Joel Fernandes jo...@ti.com [130626 20:48]: Build EDMA in by default to avoid fewer people stepping on their toes with broken DMA on drivers needing EDMA. Thanks applying this one into omap-for-v3.11/fixes. Tony -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v12 00/11] DMA Engine support for AM33XX
* Benoit Cousson b-cous...@ti.com [130624 07:42]: Hi Tony, On 06/24/2013 12:19 PM, Tony Lindgren wrote: Hi, For merging this series, I suggest the following sets: * Joel A Fernandes joelag...@ti.com [130620 14:13]: Joel A Fernandes (3): edma: config: Enable config options for EDMA da8xx: config: Enable MMC and FS options ARM: davinci: Fix compiler warnings in devices-da8xx Matt Porter (8): dmaengine: edma: Add TI EDMA device tree binding ARM: edma: Add DT and runtime PM support to the private EDMA API ARM: edma: Add EDMA crossbar event mux support dmaengine: edma: enable build for AM33XX Sekhar should queue the above patches, I've acked the mach-omap2/Kconfig change. spi: omap2-mcspi: add generic DMA request support to the DT binding spi: omap2-mcspi: convert to dma_request_slave_channel_compat() The spi changes should get merged via the driver list. ARM: dts: add AM33XX EDMA support ARM: dts: add AM33XX SPI DMA support Benoit should queue the .dts changes. I'll do that, but do you consider them for 3.11? Yes right after -rc1 if it makes the DMA work. We almost certainly need to send few branches of fixes after -rc1 once we find out what might have broken by the removal of the hwmod data.. But let's stick to minimal changes for the -rc series naturally. Regards, Tony -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v12 04/11] dmaengine: edma: enable build for AM33XX
* Sekhar Nori nsek...@ti.com [130621 03:21]: On 6/21/2013 2:36 AM, Joel A Fernandes wrote: From: Matt Porter mpor...@ti.com Enable TI EDMA option on OMAP and TI_PRIV_EDMA Signed-off-by: Matt Porter mpor...@ti.com Signed-off-by: Joel A Fernandes joelag...@ti.com This will have to be taken by Tony. Sekhar, please go ahead and take this one. I'll reply to the header email of this series how it should be queued. For the mach-omap2/Kconfig change: Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/Kconfig |1 + drivers/dma/Kconfig |2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f49cd51..f91b07f 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -17,6 +17,7 @@ config ARCH_OMAP2PLUS select PROC_DEVICETREE if PROC_FS select SOC_BUS select SPARSE_IRQ + select TI_PRIV_EDMA select USE_OF help Systems based on OMAP2, OMAP3, OMAP4 or OMAP5 diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index e992489..3215a3c 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -213,7 +213,7 @@ config SIRF_DMA config TI_EDMA tristate TI EDMA support - depends on ARCH_DAVINCI + depends on ARCH_DAVINCI || ARCH_OMAP select DMA_ENGINE select DMA_VIRTUAL_CHANNELS default n -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v12 00/11] DMA Engine support for AM33XX
Hi, For merging this series, I suggest the following sets: * Joel A Fernandes joelag...@ti.com [130620 14:13]: Joel A Fernandes (3): edma: config: Enable config options for EDMA da8xx: config: Enable MMC and FS options ARM: davinci: Fix compiler warnings in devices-da8xx Matt Porter (8): dmaengine: edma: Add TI EDMA device tree binding ARM: edma: Add DT and runtime PM support to the private EDMA API ARM: edma: Add EDMA crossbar event mux support dmaengine: edma: enable build for AM33XX Sekhar should queue the above patches, I've acked the mach-omap2/Kconfig change. spi: omap2-mcspi: add generic DMA request support to the DT binding spi: omap2-mcspi: convert to dma_request_slave_channel_compat() The spi changes should get merged via the driver list. ARM: dts: add AM33XX EDMA support ARM: dts: add AM33XX SPI DMA support Benoit should queue the .dts changes. Documentation/devicetree/bindings/dma/ti-edma.txt | 34 +++ Documentation/devicetree/bindings/spi/omap-spi.txt | 27 ++- arch/arm/Kconfig |1 + arch/arm/boot/dts/am33xx.dtsi | 22 ++ arch/arm/common/edma.c | 242 ++-- arch/arm/configs/da8xx_omapl_defconfig |3 + arch/arm/mach-davinci/devices-da8xx.c |8 +- arch/arm/mach-omap2/Kconfig|2 + drivers/dma/Kconfig|4 +- drivers/spi/spi-omap2-mcspi.c | 64 -- include/linux/platform_data/edma.h |5 +- 11 files changed, 369 insertions(+), 43 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt Regards, Tony -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
* Felipe Balbi ba...@ti.com [130204 07:46]: Current DMA abstraction is quite poor, for example there's no way to compile support for multiple DMA engines. Code also makes certain, IMO unnecessary, assumptions about the underlying DMA engine (abstraction is poor, as said above but it we could follow MUSB's programming guide when it comes to programming DMA transfers). Considering all of the above, it's far better to use DMA engine and get rid of all the mess. How about just disable MUSB DMA support if ARCH_MULTIPLATFORM for now? That way MUSB can be fixed up first to support ARCH_MULTIPLATFORM using PIO while sorting out the DMA related issues. Regards, Tony -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
* Matt Porter mpor...@ti.com [130202 11:51]: On Sat, Feb 02, 2013 at 10:16:43AM -0800, Tony Lindgren wrote: * Matt Porter mpor...@ti.com [130202 10:10]: If it doesn't work, work with Vinod to fix the api. It's expected, I'm working on dmaengine API changes right now to deal with a limitation of EDMA that needs to be abstracted. Regarding the DMA API limitations, I'm only aware of lack of capability to configure autoincrement at the device end. And that keeps us from converting all GPMC related devices using omap SDMA to use the DMA API. Are there other limitations currently known with the DMA API? Yes, I called one out when this was first posted as an RFC and was working it in parallel with this support. This one blocks AM33XX support in mmc and is the reason I split all of the mmc support out of the base edma dmaengine for am33xx series. Independent of the blockage, whatever we finally settle on to address this API need will also cleanup the use of magic values in the davinci mmc driver (that's part of the second thread below). RFC posting: https://patchwork.kernel.org/patch/1583531/ Posting with initial attempt at a caps api: http://www.spinics.net/lists/linux-mmc/msg18351.html OK thanks for the links, good to hear at least some work is happening on it. Also, I haven't fully vetted the situation with cyclic transfers and EDMA, however, I'm pretty sure that we'll need some API changes there. The reason is that some Davinci platforms have no FIFO on their McASP implementation (that was a new feature added on DA8xx and also AM33xx). As such they have audio support implemented using ping-pong buffering via an SRAM buffer. There's been a number of patches ahead of all this that myself and others have worked upstream to get the SRAM stuff to be Davinci-independent (genalloc). But, at the end of all of this, there's no notion in a cyclic transfer of doing synchronized ping-pong buffering using two chain channels. This is how it is implemented (and documented in EDMA docs going back to the DSPs this IP first showed up on) using the private API. I'll be looking at this soon, but, I'm more interested in 1) getting the base support in 2) then the mmc stuff blocking DT populated platforms using omap_hsmmc (split out and posted) 3) v3 of the caps api w/ vinod's concerns address (working it not) Normally, I'm not going to bring up the cyclic transfer issue until I have some code to show or reference for discussion...but it's worth being aware. But, in any case, I'm confident that will gate having the mcasp driver that am33xx also uses converted to dmaengine. Except for the gpmc limitation you menationed, that's the last in kernel user of the privat edma api needed to be converted such that we can kill off arch/arm/common/edma.c once it's taken in. And then there's the case of device-to-device DMA that we're not currently doing luckily. And I don't think I've even seen that being used so we probably don't need to worry about that one right now. Regards, Tony -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
* Matt Porter mpor...@ti.com [130201 10:25]: Move mach-davinci/dma.c to common/edma.c so it can be used by OMAP (specifically AM33xx) as well. I think this should rather go to drivers/dma/? Tony -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v4 08/14] mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
* Matt Porter mpor...@ti.com [130110 21:47]:
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Matt Porter mpor...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index bc58078..e79b12d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1915,14 +1915,20 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- host-rx_chan = dma_request_channel(mask, omap_dma_filter_fn, rx_req);
+ host-rx_chan =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+ rx_req, pdev-dev, rx);
+
if (!host-rx_chan) {
dev_err(mmc_dev(host-mmc), unable to obtain RX DMA engine
channel %u\n, rx_req);
ret = -ENXIO;
goto err_irq;
}
- host-tx_chan = dma_request_channel(mask, omap_dma_filter_fn, tx_req);
+ host-tx_chan =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+ tx_req, pdev-dev, tx);
+
if (!host-tx_chan) {
dev_err(mmc_dev(host-mmc), unable to obtain TX DMA engine
channel %u\n, tx_req);
ret = -ENXIO;
--
1.7.9.5
--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v4 07/14] dmaengine: add dma_request_slave_channel_compat()
* Matt Porter mpor...@ti.com [130110 21:47]:
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.
This allows for a much cleaner migration of drivers to the
dmaengine DT API as platforms continue to be mixed between those
that boot using DT and those that do not.
Cool, looks like the driver changes are quite minimal after this:
Acked-by: Tony Lindgren t...@atomide.com
Suggested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Matt Porter mpor...@ti.com
---
include/linux/dmaengine.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 9fd0c5b..64f9f69 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -1047,6 +1047,16 @@ void dma_run_dependencies(struct
dma_async_tx_descriptor *tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y) __dma_request_channel((mask), x, y)
+static inline struct dma_chan
+*dma_request_slave_channel_compat(dma_cap_mask_t mask, dma_filter_fn fn,
+ void *fn_param, struct device *dev,
+ char *name)
+{
+ if (dev-of_node)
+ return dma_request_slave_channel(dev, name);
+ else
+ return dma_request_channel(mask, fn, fn_param);
+}
/* --- Helper iov-locking functions --- */
--
1.7.9.5
--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v4 11/14] ARM: dts: add AM33XX MMC support
* Matt Porter mpor...@ti.com [130110 21:47]:
Adds AM33XX MMC support for am335x-bone, am335x-evm, and
am335x-evmsk..
This one should be queued separately by Benoit:
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |7 +++
arch/arm/boot/dts/am335x-evm.dts |7 +++
arch/arm/boot/dts/am335x-evmsk.dts |7 +++
arch/arm/boot/dts/am33xx.dtsi | 28
4 files changed, 49 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 11b240c..a154ce0 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -120,6 +120,8 @@
};
ldo3_reg: regulator@5 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
@@ -136,3 +138,8 @@
cpsw_emac1 {
phy_id = davinci_mdio, 1;
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = ldo3_reg;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index d649644..2907da6 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -232,6 +232,8 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
};
@@ -244,3 +246,8 @@
cpsw_emac1 {
phy_id = davinci_mdio, 1;
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = vmmc_reg;
+};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index f5a6162..f050c46 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -244,7 +244,14 @@
};
vmmc_reg: regulator@12 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
};
};
+
+mmc1 {
+ status = okay;
+ vmmc-supply = vmmc_reg;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index e711ffb..278b75d 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -235,6 +235,34 @@
status = disabled;
};
+ mmc1: mmc@4806 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ ti,needs-special-reset;
+ dmas = edma 24
+ edma 25;
+ dma-names = tx, rx;
+ status = disabled;
+ };
+
+ mmc2: mmc@481d8000 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc2;
+ ti,needs-special-reset;
+ dmas = edma 2
+ edma 3;
+ dma-names = tx, rx;
+ status = disabled;
+ };
+
+ mmc3: mmc@4781 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc3;
+ ti,needs-special-reset;
+ status = disabled;
+ };
+
wdt2: wdt@44e35000 {
compatible = ti,omap3-wdt;
ti,hwmods = wd_timer2;
--
1.7.9.5
--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v4 10/14] mmc: omap_hsmmc: add generic DMA request support to the DT binding
* Matt Porter mpor...@ti.com [130110 21:47]:
The binding definition is based on the generic DMA request binding.
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Matt Porter mpor...@ti.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25
+++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ed271fc..826cc51 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,8 +20,28 @@ ti,dual-volt: boolean, supports dual voltage cards
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
ti,needs-special-hs-handling: HSMMC IP needs special setting for handling
High Speed
+dmas: DMA controller phandle and DMA request value ordered pair
+One tx and one rx pair is required.
+dma-names: DMA request names. These strings correspond 1:1 with
+the ordered pairs in dmas. The RX request must be rx and the
+TX request must be tx.
+
+Examples:
+
+[hwmod populated DMA resources]
+
+ mmc1: mmc@0x4809c000 {
+ compatible = ti,omap4-hsmmc;
+ reg = 0x4809c000 0x400;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ bus-width = 4;
+ vmmc-supply = vmmc; /* phandle to regulator node */
+ ti,non-removable;
+ };
+
+[generic DMA request binding]
-Example:
mmc1: mmc@0x4809c000 {
compatible = ti,omap4-hsmmc;
reg = 0x4809c000 0x400;
@@ -30,4 +50,7 @@ Example:
bus-width = 4;
vmmc-supply = vmmc; /* phandle to regulator node */
ti,non-removable;
+ dmas = edma 24
+ edma 25;
+ dma-names = tx, rx;
};
--
1.7.9.5
--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v4 09/14] mmc: omap_hsmmc: set max_segs based on dma engine limitations
* Matt Porter mpor...@ti.com [130110 21:47]: The EDMA DMAC has a hardware limitation that prevents supporting scatter gather lists with any number of segments. The DMA Engine API reports the maximum number of segments a channel can support via the optional dma_get_channel_caps() API. If the nr_segs capability is present, the value is used to configure mmc-max_segs appropriately. Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Matt Porter mpor...@ti.com --- drivers/mmc/host/omap_hsmmc.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index e79b12d..f74bd69 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1769,6 +1769,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev) const struct of_device_id *match; dma_cap_mask_t mask; unsigned tx_req, rx_req; + struct dmaengine_chan_caps *dma_chan_caps; struct pinctrl *pinctrl; match = of_match_device(of_match_ptr(omap_mmc_of_match), pdev-dev); @@ -1935,6 +1936,11 @@ static int omap_hsmmc_probe(struct platform_device *pdev) goto err_irq; } + /* Some DMA Engines only handle a limited number of SG segments */ + dma_chan_caps = dma_get_channel_caps(host-rx_chan, DMA_DEV_TO_MEM); + if (dma_chan_caps dma_chan_caps-seg_nr) + mmc-max_segs = dma_chan_caps-seg_nr; + /* Request IRQ for MMC operations */ ret = request_irq(host-irq, omap_hsmmc_irq, 0, mmc_hostname(mmc), host); -- 1.7.9.5 -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [RFC PATCH 10/13] spi: omap2-mcspi: dma_request_slave_channel() support for DT platforms
* Arnd Bergmann a...@arndb.de [120921 02:19]:
On Thursday 20 September 2012, Tony Lindgren wrote:
/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
@@ -798,14 +801,26 @@ static int omap2_mcspi_request_dma(struct
spi_device *spi)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig = mcspi_dma-dma_rx_sync_dev;
- mcspi_dma-dma_rx = dma_request_channel(mask, omap_dma_filter_fn,
sig);
+ if (spi-dev.of_node)
+ mcspi_dma-dma_rx =
+ dma_request_slave_channel(master-dev,
+
mcspi_dma-dma_rx_ch_name);
+ else
+ mcspi_dma-dma_rx =
+ dma_request_channel(mask, omap_dma_filter_fn, sig);
if (!mcspi_dma-dma_rx) {
dev_err(spi-dev, no RX DMA engine channel for McSPI\n);
return -EAGAIN;
}
Hmm this does not look nice.. We should be able to somehow not to care about
the configuration at the mcspi driver level.
I agree, but as far as I understand Vinod's plans, we would actually move
all drivers over to dma_request_slave_channel() when we have an interface
to register the lookup tables from platform code.
I think the above is ok for a transitional phase and we can remove the
fallback path when we have converted all platforms using this driver
to either use DT or move to the new style way of passing the channel
configuration.
Can't we come up with a version of dma_request_slave_channel that works
both ways for now:
mcspi_dma-dma_rx =
dma_request_slave_channel_compat(mask, omap_dma_filter_fn, sig,
master-dev,
mcspi_dma-dma_rx_ch_name);
...
Then it's just question of patching away two lines later on rather than
having to add all this if else to all the drivers first, then patching
it away again.
Regards,
Tony
--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 03/29] ARM: OMAP1: Make plat/mux.h omap1 only
We are moving omap2+ to use the device tree based pinctrl-single.c
and will be removing the old mux framework. This will remove the
omap1 specific parts from plat-omap.
Cc: Felipe Balbi ba...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Richard Purdie rpur...@rpsys.net
Cc: Florian Tobias Schandinat florianschandi...@gmx.de
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-...@vger.kernel.org
Cc: linux-pcm...@lists.infradead.org
Cc: spi-devel-general@lists.sourceforge.net
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/board-ams-delta.c |2 -
arch/arm/mach-omap1/board-fsample.c |2 -
arch/arm/mach-omap1/board-generic.c |2 -
arch/arm/mach-omap1/board-h2.c|2 -
arch/arm/mach-omap1/board-h3.c|2 -
arch/arm/mach-omap1/board-innovator.c |2 -
arch/arm/mach-omap1/board-nokia770.c |2 -
arch/arm/mach-omap1/board-osk.c |2 -
arch/arm/mach-omap1/board-palmte.c|2 -
arch/arm/mach-omap1/board-palmtt.c|2 -
arch/arm/mach-omap1/board-palmz71.c |2 -
arch/arm/mach-omap1/board-perseus2.c |2 -
arch/arm/mach-omap1/board-sx1.c |2 -
arch/arm/mach-omap1/board-voiceblue.c |2 -
arch/arm/mach-omap1/devices.c |2 -
arch/arm/mach-omap1/i2c.c |2 -
arch/arm/mach-omap1/include/mach/mux.h|0
arch/arm/mach-omap1/io.c |2 -
arch/arm/mach-omap1/mcbsp.c |2 -
arch/arm/mach-omap1/mux.c | 58
arch/arm/mach-omap1/pm.c |2 -
arch/arm/mach-omap1/serial.c |2 -
arch/arm/mach-omap1/usb.c |2 -
arch/arm/mach-omap2/common.c |1
arch/arm/mach-omap2/hsmmc.c |1
arch/arm/plat-omap/Makefile |2 -
arch/arm/plat-omap/i2c.c |1
arch/arm/plat-omap/include/plat/omap-serial.h |2 -
arch/arm/plat-omap/mux.c | 90 -
drivers/pcmcia/omap_cf.c |2 -
drivers/spi/spi-omap-uwire.c |2 -
drivers/usb/host/ohci-omap.c |2 -
drivers/usb/musb/tusb6010_omap.c |1
drivers/usb/otg/isp1301_omap.c|2 -
drivers/video/backlight/omap1_bl.c|2 -
drivers/video/omap/lcd_osk.c |2 -
36 files changed, 84 insertions(+), 126 deletions(-)
rename arch/arm/{plat-omap/include/plat/mux.h =
mach-omap1/include/mach/mux.h} (100%)
delete mode 100644 arch/arm/plat-omap/mux.c
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index ab1e51f..05af063 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -37,7 +37,7 @@
#include plat/board-ams-delta.h
#include plat/keypad.h
-#include plat/mux.h
+#include mach/mux.h
#include mach/hardware.h
#include mach/ams-delta-fiq.h
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index 6d98552..4b784f2 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -28,7 +28,7 @@
#include asm/mach/map.h
#include plat/tc.h
-#include plat/mux.h
+#include mach/mux.h
#include plat/flash.h
#include plat/fpga.h
#include plat/keypad.h
diff --git a/arch/arm/mach-omap1/board-generic.c
b/arch/arm/mach-omap1/board-generic.c
index 04b5fda..4ec579f 100644
--- a/arch/arm/mach-omap1/board-generic.c
+++ b/arch/arm/mach-omap1/board-generic.c
@@ -22,7 +22,7 @@
#include asm/mach/arch.h
#include asm/mach/map.h
-#include plat/mux.h
+#include mach/mux.h
#include mach/usb.h
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 5560a40..124db5c 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -38,7 +38,7 @@
#include asm/mach/arch.h
#include asm/mach/map.h
-#include plat/mux.h
+#include mach/mux.h
#include plat/dma.h
#include plat/tc.h
#include plat/irda.h
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index edc2487..a6f28a6 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -40,7 +40,7 @@
#include asm/mach/arch.h
#include asm/mach/map.h
-#include plat/mux.h
+#include mach/mux.h
#include plat/tc.h
#include plat/keypad.h
#include plat/dma.h
diff --git a/arch/arm/mach-omap1/board-innovator.c
b/arch/arm/mach-omap1/board-innovator.c
index f21c296..0eb9881 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -31,7 +31,7 @@
#include asm/mach/arch.h
#include asm/mach/map.h
-#include plat/mux.h
Re: [REPOST PATCH v2 1/2] spi: omap2-mcspi: add pinctrl support
* Shubhrajyoti shubhrajy...@ti.com [120918 05:09]: On Tuesday 18 September 2012 05:31 PM, Matt Porter wrote: Adds pinctrl support to support OMAP platforms that boot from DT and rely on pinctrl support to set pinmuxes. looks good Acked-by: Shubhrajyoti D shubhrajy...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v2 1/2] spi: omap2-mcspi: add pinctrl support
* Matt Porter mpor...@ti.com [120917 10:21]:
Adds pinctrl support to support OMAP platforms that boot from DT
and rely on pinctrl support to set pinmuxes.
Signed-off-by: Matt Porter mpor...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/spi/spi-omap2-mcspi.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index b2fb141..9502566 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -38,6 +38,8 @@
#include linux/pm_runtime.h
#include linux/of.h
#include linux/of_device.h
+#include linux/pinctrl/consumer.h
+#include linux/err.h
#include linux/spi/spi.h
@@ -1124,6 +1126,7 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
static int bus_num = 1;
struct device_node *node = pdev-dev.of_node;
const struct of_device_id *match;
+ struct pinctrl *pinctrl;
master = spi_alloc_master(pdev-dev, sizeof *mcspi);
if (master == NULL) {
@@ -1219,6 +1222,11 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
if (status 0)
goto dma_chnl_free;
+ pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(pinctrl))
+ dev_warn(pdev-dev,
+ pins are not configured from the driver\n);
+
pm_runtime_use_autosuspend(pdev-dev);
pm_runtime_set_autosuspend_delay(pdev-dev, SPI_AUTOSUSPEND_TIMEOUT);
pm_runtime_enable(pdev-dev);
--
1.7.9.5
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v2 2/2] ARM: OMAP2+: Enable pinctrl dummy states
* Matt Porter mpor...@ti.com [120917 10:21]:
Enable pinctrl dummy states for all OMAP platforms that don't
populate DT. This allows drivers to be converted to pinctrl
and not generate new warnings on platforms that do not provide
pinctrl data. These platforms already have pinmuxes configured
before the drivers probe.
Thanks this should do the trick until we've converted to use DT.
I'll queue this for the upcoming merge window.
Regards,
Tony
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/mach-omap2/devices.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1efa984..6ef4010 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -17,6 +17,7 @@
#include linux/err.h
#include linux/slab.h
#include linux/of.h
+#include linux/pinctrl/machine.h
#include linux/platform_data/omap4-keypad.h
#include asm/mach-types.h
@@ -628,6 +629,10 @@ static inline void omap_init_vout(void) {}
static int __init omap2_init_devices(void)
{
+ /* Enable dummy states for those platforms without pinctrl support */
+ if (!of_have_populated_dt())
+ pinctrl_provide_dummies();
+
/*
* please keep these calls, and their implementations above,
* in alphabetical order so they're easier to sort through.
--
1.7.9.5
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/2] spi: omap2-mcspi: add pinctrl support
* Matt Porter mpor...@ti.com [120911 10:46]:
Adds pinctrl support to support OMAP platforms that boot from DT
and rely on pinctrl support to set pinmuxes.
Signed-off-by: Matt Porter mpor...@ti.com
---
drivers/spi/spi-omap2-mcspi.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index b2fb141..6c67cdb 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -38,6 +38,8 @@
#include linux/pm_runtime.h
#include linux/of.h
#include linux/of_device.h
+#include linux/pinctrl/consumer.h
+#include linux/err.h
#include linux/spi/spi.h
@@ -1124,6 +1126,7 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
static int bus_num = 1;
struct device_node *node = pdev-dev.of_node;
const struct of_device_id *match;
+ struct pinctrl *pinctrl;
master = spi_alloc_master(pdev-dev, sizeof *mcspi);
if (master == NULL) {
@@ -1219,6 +1222,12 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
if (status 0)
goto dma_chnl_free;
+ pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(pinctrl)) {
+ status = PTR_ERR(pinctrl);
+ goto dma_chnl_free;
+ }
+
pm_runtime_use_autosuspend(pdev-dev);
pm_runtime_set_autosuspend_delay(pdev-dev, SPI_AUTOSUSPEND_TIMEOUT);
pm_runtime_enable(pdev-dev);
You should just print out a warning here as most boards don't
have pinctrl implemented at this point, or may never have.
Regards,
Tony
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/2] ARM: OMAP2+: Enable pinctrl dummy states
* Matt Porter mpor...@ti.com [120911 10:46]:
Enable pinctrl dummy states for all OMAP platforms. This allows
drivers to be converted to pinctrl while still running on
platforms that do not provide pinctrl data.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/mach-omap2/devices.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c00c689..577cd04 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -17,6 +17,7 @@
#include linux/err.h
#include linux/slab.h
#include linux/of.h
+#include linux/pinctrl/machine.h
#include linux/platform_data/omap4-keypad.h
#include mach/hardware.h
@@ -631,6 +632,9 @@ static inline void omap_init_vout(void) {}
static int __init omap2_init_devices(void)
{
+ /* Enable dummy states for those platforms without pinctrl support */
+ pinctrl_provide_dummies();
+
/*
* please keep these calls, and their implementations above,
* in alphabetical order so they're easier to sort through.
Hmm I think this may need to be board specific. And may need to
be board specific and depend on unpopulated device tree?
For board-generic.c we always want to see the warnings. And some boards
insist on doing all the muxing only in the bootloader.
Regards,
Tony
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/2] ARM: OMAP2+: Enable pinctrl dummy states
Added Linus Walleij to Cc as well.
* Matt Porter mpor...@ti.com [120911 11:24]:
On Tue, Sep 11, 2012 at 11:03:06AM -0700, Tony Lindgren wrote:
* Matt Porter mpor...@ti.com [120911 10:46]:
Enable pinctrl dummy states for all OMAP platforms. This allows
drivers to be converted to pinctrl while still running on
platforms that do not provide pinctrl data.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/mach-omap2/devices.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c00c689..577cd04 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -17,6 +17,7 @@
#include linux/err.h
#include linux/slab.h
#include linux/of.h
+#include linux/pinctrl/machine.h
#include linux/platform_data/omap4-keypad.h
#include mach/hardware.h
@@ -631,6 +632,9 @@ static inline void omap_init_vout(void) {}
static int __init omap2_init_devices(void)
{
+ /* Enable dummy states for those platforms without pinctrl support */
+ pinctrl_provide_dummies();
+
/*
* please keep these calls, and their implementations above,
* in alphabetical order so they're easier to sort through.
Hmm I think this may need to be board specific. And may need to
be board specific and depend on unpopulated device tree?
If I run this on AM33xx with dummy states enabled, I'm able to override
that dummy state just fine with an appropriate pinctl/pinmux entry in my
DT data for spi.
But do you get an error then if the desired pins are not found?
If you do get an error, then sounds like it's OK to do.
Meanwhile on xM booting from board-omap3evm.c/!DT and debug enabled I
get the following:
[1.837829] omap2_mcspi omap2_mcspi.1: no of_node; not parsing
pinctrl DT
[1.845214] omap2_mcspi omap2_mcspi.1: using pinctrl dummy state
(default)
[1.854278] omap2_mcspi omap2_mcspi.2: no of_node; not parsing
pinctrl DT
[1.861572] omap2_mcspi omap2_mcspi.2: using pinctrl dummy state
(default)
[1.870025] omap2_mcspi omap2_mcspi.3: no of_node; not parsing
pinctrl DT
[1.877288] omap2_mcspi omap2_mcspi.3: using pinctrl dummy state
(default)
[1.885681] omap2_mcspi omap2_mcspi.4: no of_node; not parsing
pinctrl DT
[1.892913] omap2_mcspi omap2_mcspi.4: using pinctrl dummy state
(default)
which seems to cover things being informative enough about what is
going on. Are you wanting to see an explicit warning that the pinctrl
dummy state is in use when pinctrl data is not available?
Well I think we should consider at least the following:
1. Always see warnings when device tree is populated with board-generic.
If somebody wants to use bootloader only muxing with DT, they can patch
in pinctrl_provide_dummies() somewhere. But let's assume we always
want to see the warnings with board-generic.c and DT.
2. For legacy booting without DT, we should not see any warnings
from pinctrl-single.c as it's DT based.
3. There may be other non-pinctrl drivers too that are not DT
based, and in those cases we should see the warnings as well
for in the non-DT case.
For board-generic.c we always want to see the warnings. And some boards
insist on doing all the muxing only in the bootloader.
Which warnings are you saying we should see in the board-generic.c
case? Sure, there's plenty of cases where this will be unused due to
somebody setting all the muxes in the bootloader and then not using
pinctrl data. I'll have to doublecheck but I believe that case is also
fine as the -single driver can't override the dummy state if the DT has
no pinctrl data for the spi driver.
Yeah I guess it's the case #1 above for board-generic.c.
Regards,
Tony
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/2] ARM: OMAP2+: Enable pinctrl dummy states
* Matt Porter mpor...@ti.com [120911 12:05]: On Tue, Sep 11, 2012 at 11:35:22AM -0700, Tony Lindgren wrote: Added Linus Walleij to Cc as well. Now I think I really managed to add Linus W to Cc, sent too fast earlier. ... But do you get an error then if the desired pins are not found? If you do get an error, then sounds like it's OK to do. Hrm, no. In that case, it will be completely silent (assuming we took care of the pinmuxing in the bootloader) as it uses the dummy state. Only with debug on will you see the information that mcspi has used the dummy state as is the case with !DT. ... Well I think we should consider at least the following: 1. Always see warnings when device tree is populated with board-generic. If somebody wants to use bootloader only muxing with DT, they can patch in pinctrl_provide_dummies() somewhere. But let's assume we always want to see the warnings with board-generic.c and DT. Ok, this is clear. 2. For legacy booting without DT, we should not see any warnings from pinctrl-single.c as it's DT based. Right, except anything legacy booting without DT will require that dummy states be present otherwise it will fail probe. But I guess we should enable the dummy states only for other board-*.c files, not board-generic.c? 3. There may be other non-pinctrl drivers too that are not DT based, and in those cases we should see the warnings as well for in the non-DT case. I'm not sure what you mean here. non-pinctrl drivers means any driver that is not yet pinctrl or DT enabled? It's unclear to me how this case has a bearing on mcspi and pinctrl enablement across legacy board-foo.c !DT booting platforms. Right, sorry I meant non DT pinctrl drivers.. However, I think if the approach was modified by only calling pinctrl_provide_dummies() when we are booting with DT populated and using board-generic.c then it will satisfy all of your concerns. Thoughts? Hmm but shouldn't it be call pinctrl_provide_dummies() only for other boards except board-generic.c? And that is assuming we don't have any other non DT pinctrl drivers around. i.e. the legacy !DT booting will have dummy states and continue along through mcspi the way it does today, relying on board-foo level pinmux calls (or bootloader pinmuxing). Meanwhile DT booting will now require that a mcspi instance also require pinctrl entry in this dts. Yes agreed, except let's just produce a warning for the pinctrl errors.. The only worrisome thing is the pinctrl requirement on DT booting is now an implicit requirement. ..as otherwise not much will work at this point :) For board-generic.c we always want to see the warnings. And some boards insist on doing all the muxing only in the bootloader. Which warnings are you saying we should see in the board-generic.c case? Sure, there's plenty of cases where this will be unused due to somebody setting all the muxes in the bootloader and then not using pinctrl data. I'll have to doublecheck but I believe that case is also fine as the -single driver can't override the dummy state if the DT has no pinctrl data for the spi driver. I suggest all pinctrl errors should show up as warnings with board-generic.c, but we should not exit out of the driver probe on errors. Regards, Tony -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 17/17] ARM: OMAP1: Move SoC specific headers from plat to mach for omap1
There's no need to have these in plat-omap any longer. Note that these
could eventually be made local to mach-omap1 instead of being in mach.
But to do that, at least various driver access using omap7xxx.h registers
needs to be fixed first.
Cc: spi-devel-general@lists.sourceforge.net
Cc: Grant Likely grant.lik...@secretlab.ca
Acked-by: Afzal Mohammed af...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/board-htcherald.c |2 +-
arch/arm/mach-omap1/devices.c |2 +-
arch/arm/mach-omap1/include/mach/hardware.h |6 +++---
arch/arm/mach-omap1/include/mach/omap1510.h |3 +--
arch/arm/mach-omap1/include/mach/omap16xx.h |3 +--
arch/arm/mach-omap1/include/mach/omap7xx.h |3 +--
drivers/spi/spi-omap-uwire.c|3 ++-
7 files changed, 10 insertions(+), 12 deletions(-)
rename arch/arm/{plat-omap/include/plat/omap1510.h =
mach-omap1/include/mach/omap1510.h} (97%)
rename arch/arm/{plat-omap/include/plat/omap16xx.h =
mach-omap1/include/mach/omap16xx.h} (99%)
rename arch/arm/{plat-omap/include/plat/omap7xx.h =
mach-omap1/include/mach/omap7xx.h} (98%)
diff --git a/arch/arm/mach-omap1/board-htcherald.c
b/arch/arm/mach-omap1/board-htcherald.c
index b9771b5..a5ac352 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -41,7 +41,7 @@
#include asm/mach-types.h
#include asm/mach/arch.h
-#include plat/omap7xx.h
+#include mach/omap7xx.h
#include plat/keypad.h
#include plat/mmc.h
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 1feca35..05fdbd9 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -23,8 +23,8 @@
#include plat/mux.h
#include plat/dma.h
#include plat/mmc.h
-#include plat/omap7xx.h
+#include mach/omap7xx.h
#include mach/camera.h
#include mach/hardware.h
diff --git a/arch/arm/mach-omap1/include/mach/hardware.h
b/arch/arm/mach-omap1/include/mach/hardware.h
index bd3b95e..84248d2 100644
--- a/arch/arm/mach-omap1/include/mach/hardware.h
+++ b/arch/arm/mach-omap1/include/mach/hardware.h
@@ -311,8 +311,8 @@ static inline u32 omap_cs3_phys(void)
* ---
*/
-#include plat/omap7xx.h
-#include plat/omap1510.h
-#include plat/omap16xx.h
+#include omap7xx.h
+#include omap1510.h
+#include omap16xx.h
#endif /* __ASM_ARCH_OMAP_HARDWARE_H */
diff --git a/arch/arm/plat-omap/include/plat/omap1510.h
b/arch/arm/mach-omap1/include/mach/omap1510.h
similarity index 97%
rename from arch/arm/plat-omap/include/plat/omap1510.h
rename to arch/arm/mach-omap1/include/mach/omap1510.h
index d240046..8fe05d6 100644
--- a/arch/arm/plat-omap/include/plat/omap1510.h
+++ b/arch/arm/mach-omap1/include/mach/omap1510.h
@@ -1,5 +1,4 @@
-/* arch/arm/plat-omap/include/mach/omap1510.h
- *
+/*
* Hardware definitions for TI OMAP1510 processor.
*
* Cleanup for Linux-2.6 by Dirk Behme dirk.be...@de.bosch.com
diff --git a/arch/arm/plat-omap/include/plat/omap16xx.h
b/arch/arm/mach-omap1/include/mach/omap16xx.h
similarity index 99%
rename from arch/arm/plat-omap/include/plat/omap16xx.h
rename to arch/arm/mach-omap1/include/mach/omap16xx.h
index e69e1d8..cd1c724 100644
--- a/arch/arm/plat-omap/include/plat/omap16xx.h
+++ b/arch/arm/mach-omap1/include/mach/omap16xx.h
@@ -1,5 +1,4 @@
-/* arch/arm/plat-omap/include/mach/omap16xx.h
- *
+/*
* Hardware definitions for TI OMAP1610/5912/1710 processors.
*
* Cleanup for Linux-2.6 by Dirk Behme dirk.be...@de.bosch.com
diff --git a/arch/arm/plat-omap/include/plat/omap7xx.h
b/arch/arm/mach-omap1/include/mach/omap7xx.h
similarity index 98%
rename from arch/arm/plat-omap/include/plat/omap7xx.h
rename to arch/arm/mach-omap1/include/mach/omap7xx.h
index 48e4757..63da994 100644
--- a/arch/arm/plat-omap/include/plat/omap7xx.h
+++ b/arch/arm/mach-omap1/include/mach/omap7xx.h
@@ -1,5 +1,4 @@
-/* arch/arm/plat-omap/include/mach/omap7xx.h
- *
+/*
* Hardware definitions for TI OMAP7XX processor.
*
* Cleanup for Linux-2.6 by Dirk Behme dirk.be...@de.bosch.com
diff --git a/drivers/spi/spi-omap-uwire.c b/drivers/spi/spi-omap-uwire.c
index 9b0d716..a3996a1 100644
--- a/drivers/spi/spi-omap-uwire.c
+++ b/drivers/spi/spi-omap-uwire.c
@@ -53,7 +53,8 @@
#include asm/mach-types.h
#include plat/mux.h
-#include plat/omap7xx.h /* OMAP7XX_IO_CONF registers */
+
+#include mach/omap7xx.h /* OMAP7XX_IO_CONF registers */
/* FIXME address is now a platform device resource,
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel
[PATCH 4/4] ARM: OMAP1: Move SoC specific headers from plat to mach for omap1
There's no need to have these in plat-omap any longer. Note that these
could eventually be made local to mach-omap1 instead of being in mach.
But to do that, at least various driver access using omap7xxx.h registers
needs to be fixed first.
Cc: spi-devel-general@lists.sourceforge.net
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/board-htcherald.c |4 ++--
arch/arm/mach-omap1/devices.c |2 +-
arch/arm/mach-omap1/include/mach/hardware.h |6 +++---
arch/arm/mach-omap1/include/mach/omap1510.h |3 +--
arch/arm/mach-omap1/include/mach/omap16xx.h |3 +--
arch/arm/mach-omap1/include/mach/omap7xx.h |3 +--
drivers/spi/spi-omap-uwire.c|3 ++-
7 files changed, 11 insertions(+), 13 deletions(-)
rename arch/arm/{plat-omap/include/plat/omap1510.h =
mach-omap1/include/mach/omap1510.h} (97%)
rename arch/arm/{plat-omap/include/plat/omap16xx.h =
mach-omap1/include/mach/omap16xx.h} (99%)
rename arch/arm/{plat-omap/include/plat/omap7xx.h =
mach-omap1/include/mach/omap7xx.h} (98%)
diff --git a/arch/arm/mach-omap1/board-htcherald.c
b/arch/arm/mach-omap1/board-htcherald.c
index bdb94fe..4fe4884 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -37,14 +37,14 @@
#include linux/spi/spi.h
#include linux/spi/ads7846.h
#include linux/omapfb.h
+#include linux/platform_data/keypad-omap.h
#include asm/mach-types.h
#include asm/mach/arch.h
-#include plat/omap7xx.h
-#include linux/platform_data/keypad-omap.h
#include plat/mmc.h
+#include mach/omap7xx.h
#include mach/irqs.h
#include mach/usb.h
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 1feca35..05fdbd9 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -23,8 +23,8 @@
#include plat/mux.h
#include plat/dma.h
#include plat/mmc.h
-#include plat/omap7xx.h
+#include mach/omap7xx.h
#include mach/camera.h
#include mach/hardware.h
diff --git a/arch/arm/mach-omap1/include/mach/hardware.h
b/arch/arm/mach-omap1/include/mach/hardware.h
index bd3b95e..84248d2 100644
--- a/arch/arm/mach-omap1/include/mach/hardware.h
+++ b/arch/arm/mach-omap1/include/mach/hardware.h
@@ -311,8 +311,8 @@ static inline u32 omap_cs3_phys(void)
* ---
*/
-#include plat/omap7xx.h
-#include plat/omap1510.h
-#include plat/omap16xx.h
+#include omap7xx.h
+#include omap1510.h
+#include omap16xx.h
#endif /* __ASM_ARCH_OMAP_HARDWARE_H */
diff --git a/arch/arm/plat-omap/include/plat/omap1510.h
b/arch/arm/mach-omap1/include/mach/omap1510.h
similarity index 97%
rename from arch/arm/plat-omap/include/plat/omap1510.h
rename to arch/arm/mach-omap1/include/mach/omap1510.h
index d240046..8fe05d6 100644
--- a/arch/arm/plat-omap/include/plat/omap1510.h
+++ b/arch/arm/mach-omap1/include/mach/omap1510.h
@@ -1,5 +1,4 @@
-/* arch/arm/plat-omap/include/mach/omap1510.h
- *
+/*
* Hardware definitions for TI OMAP1510 processor.
*
* Cleanup for Linux-2.6 by Dirk Behme dirk.be...@de.bosch.com
diff --git a/arch/arm/plat-omap/include/plat/omap16xx.h
b/arch/arm/mach-omap1/include/mach/omap16xx.h
similarity index 99%
rename from arch/arm/plat-omap/include/plat/omap16xx.h
rename to arch/arm/mach-omap1/include/mach/omap16xx.h
index e69e1d8..cd1c724 100644
--- a/arch/arm/plat-omap/include/plat/omap16xx.h
+++ b/arch/arm/mach-omap1/include/mach/omap16xx.h
@@ -1,5 +1,4 @@
-/* arch/arm/plat-omap/include/mach/omap16xx.h
- *
+/*
* Hardware definitions for TI OMAP1610/5912/1710 processors.
*
* Cleanup for Linux-2.6 by Dirk Behme dirk.be...@de.bosch.com
diff --git a/arch/arm/plat-omap/include/plat/omap7xx.h
b/arch/arm/mach-omap1/include/mach/omap7xx.h
similarity index 98%
rename from arch/arm/plat-omap/include/plat/omap7xx.h
rename to arch/arm/mach-omap1/include/mach/omap7xx.h
index 48e4757..63da994 100644
--- a/arch/arm/plat-omap/include/plat/omap7xx.h
+++ b/arch/arm/mach-omap1/include/mach/omap7xx.h
@@ -1,5 +1,4 @@
-/* arch/arm/plat-omap/include/mach/omap7xx.h
- *
+/*
* Hardware definitions for TI OMAP7XX processor.
*
* Cleanup for Linux-2.6 by Dirk Behme dirk.be...@de.bosch.com
diff --git a/drivers/spi/spi-omap-uwire.c b/drivers/spi/spi-omap-uwire.c
index 9b0d716..a3996a1 100644
--- a/drivers/spi/spi-omap-uwire.c
+++ b/drivers/spi/spi-omap-uwire.c
@@ -53,7 +53,8 @@
#include asm/mach-types.h
#include plat/mux.h
-#include plat/omap7xx.h /* OMAP7XX_IO_CONF registers */
+
+#include mach/omap7xx.h /* OMAP7XX_IO_CONF registers */
/* FIXME address is now a platform device resource,
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile
Re: [PATCH] spi: omap2-mcspi: In case of dma errors fall back to pio
* Shubhrajyoti D shubhrajy...@ti.com [120724 23:26]:
In case there are dma errors currently the driver exits.
Make the spi driver fall back to pio mode in case of dma errors.
If the DMA engine is not selected the driver
exits.This patch makes the spi fall back to pio in that case.
Also adds a field dma_unusable to struct omap2_mcspi.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index bc47781..f243a39 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -129,6 +129,7 @@ struct omap2_mcspi {
struct omap2_mcspi_dma *dma_channels;
struct device *dev;
struct omap2_mcspi_regs ctx;
+ int dma_unusable;
};
Don't you need to check separately for rx and tx dma? There's a slight
chance that you get a channel for one but not for the other..
Tony
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi: omap2-mcspi: In case of dma errors fall back to pio
* Shubhrajyoti shubhrajy...@ti.com [120807 04:21]: On Tuesday 07 August 2012 01:17 PM, Tony Lindgren wrote: }; Don't you need to check separately for rx and tx dma? There's a slight chance that you get a channel for one but not for the other.. In that case I treat it as non usable and fall back to pio. OK that should work too. Are you suggesting that let one channel be dma and only the failed one pio? I guess both are doable. For reduced CPU load using DMA where possible of course is the best way to go. Tony -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v6 0/6] OMAP: McSPI: Hwmod adaptation + runtime conversion
* Kevin Hilman khil...@ti.com [110204 14:27]: Govindraj.R govindraj.r...@ti.com writes: Changes invloves: 1) Addition of hwmod data for omap2/3/4. 2) McSPI driver hwmod adaptation with cleanup of base address macros and using omap-device API's. 3) Runtime Conversion of McSPI driver. Changes from v5: --- Rebased on top of 2.6.38-rc3 as per Kevin's comments. http://www.spinics.net/lists/arm-kernel/msg112112.html Thanks. Reviewed-by: Kevin Hilman khil...@ti.com Thanks everybody, will queue. Tony -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] mcspi: Add support for GPIO chip select lines
* Ben Gamari bgamari.f...@gmail.com [101221 09:56]:
This mechanism is in large part stolen from the s3c64xx-spi module. To
use this functionality, one simply must define a set_level function to
set the CS state and a omap2_mcspi_csinfo struct for each chip select in
the board file.
Each spi_board_info.controller_data should then be set
to point to the appropriate csinfo struct. This will cause the driver to
call the csinfo-set_level function instead of toggling the McSPI chip
select lines.
Signed-off-by: Ben Gamari bgamari.f...@gmail.com
This one should go via the SPI list:
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/include/plat/mcspi.h | 14 ++
drivers/spi/omap2_mcspi.c | 14 +-
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcspi.h
b/arch/arm/plat-omap/include/plat/mcspi.h
index 1254e49..ab84b8d 100644
--- a/arch/arm/plat-omap/include/plat/mcspi.h
+++ b/arch/arm/plat-omap/include/plat/mcspi.h
@@ -1,6 +1,20 @@
#ifndef _OMAP2_MCSPI_H
#define _OMAP2_MCSPI_H
+/**
+ * struct omap2_mcspi_csinfo - Chip Select description
+ * @line: Custom 'identity' of the CS line
+ * @set_level: Function to set the state of a given CS line
+ *
+ * This is to allow use of GPIO lines as CS lines. Allocate and initialize
one
+ * in the machine init code and make spi_board_info.controller_data point to
+ * it.
+ */
+struct omap2_mcspi_csinfo {
+unsigned line;
+void (*set_level)(unsigned line_id, int lvl);
+};
+
struct omap2_mcspi_platform_config {
unsigned short num_cs;
};
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 2a651e6..92ccbd6 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -35,6 +35,7 @@
#include linux/slab.h
#include linux/spi/spi.h
+#include linux/gpio.h
#include plat/dma.h
#include plat/clock.h
@@ -235,11 +236,14 @@ static void omap2_mcspi_set_enable(const struct
spi_device *spi, int enable)
static void omap2_mcspi_force_cs(struct spi_device *spi, int cs_active)
{
- u32 l;
-
- l = mcspi_cached_chconf0(spi);
- MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active);
- mcspi_write_chconf0(spi, l);
+ if (spi-controller_data) {
+ struct omap2_mcspi_csinfo *csinfo = spi-controller_data;
+ (*csinfo-set_level)(csinfo-line, cs_active);
+ } else {
+ u32 l = mcspi_cached_chconf0(spi);
+ MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active);
+ mcspi_write_chconf0(spi, l);
+ }
}
static void omap2_mcspi_set_master_mode(struct spi_master *master)
--
1.7.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
--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi/omap2_mcspi: Verify TX reg is empty after TX only xfer with DMA
* Ilkka Koskinen ilkka.koski...@nokia.com [101019 06:55]:
In case of TX only with DMA, the driver assumes that the data
has been transferred once DMA callback in invoked. However,
SPI's shift register may still contain data. Thus, the driver
is supposed to verify that the register is empty and the end of
the SPI transfer has been reached.
Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com
Tested-by: Tuomas Katila ext-tuomas.2.kat...@nokia.com
Grant, can you please queue this one?
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/spi/omap2_mcspi.c | 39 ++-
1 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index b3a94ca..a2e053c 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -296,6 +296,19 @@ static int omap2_mcspi_enable_clocks(struct omap2_mcspi
*mcspi)
return 0;
}
+static int mcspi_wait_for_reg_bit(void __iomem *reg, unsigned long bit)
+{
+ unsigned long timeout;
+
+ timeout = jiffies + msecs_to_jiffies(1000);
+ while (!(__raw_readl(reg) bit)) {
+ if (time_after(jiffies, timeout))
+ return -1;
+ cpu_relax();
+ }
+ return 0;
+}
+
static unsigned
omap2_mcspi_txrx_dma(struct spi_device *spi, struct spi_transfer *xfer)
{
@@ -309,11 +322,14 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
u32 l;
u8 * rx;
const u8* tx;
+ void __iomem*chstat_reg;
mcspi = spi_master_get_devdata(spi-master);
mcspi_dma = mcspi-dma_channels[spi-chip_select];
l = mcspi_cached_chconf0(spi);
+ chstat_reg = cs-base + OMAP2_MCSPI_CHSTAT0;
+
count = xfer-len;
c = count;
word_len = cs-word_len;
@@ -382,6 +398,16 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
if (tx != NULL) {
wait_for_completion(mcspi_dma-dma_tx_completion);
dma_unmap_single(NULL, xfer-tx_dma, count, DMA_TO_DEVICE);
+
+ /* for TX_ONLY mode, be sure all words have shifted out */
+ if (rx == NULL) {
+ if (mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_TXS) 0)
+ dev_err(spi-dev, TXS timed out\n);
+ else if (mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_EOT) 0)
+ dev_err(spi-dev, EOT timed out\n);
+ }
}
if (rx != NULL) {
@@ -435,19 +461,6 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
return count;
}
-static int mcspi_wait_for_reg_bit(void __iomem *reg, unsigned long bit)
-{
- unsigned long timeout;
-
- timeout = jiffies + msecs_to_jiffies(1000);
- while (!(__raw_readl(reg) bit)) {
- if (time_after(jiffies, timeout))
- return -1;
- cpu_relax();
- }
- return 0;
-}
-
static unsigned
omap2_mcspi_txrx_pio(struct spi_device *spi, struct spi_transfer *xfer)
{
--
1.6.0.4
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[spi-devel-general] [PATCH 05/10] OMAP4: SPI: Fix Driver Kconfig
From: Syed Rafiuddin rafiuddin.s...@ti.com Change dependency to ARCH_OMAP2PLUS to allow systems based on omap24xx, omap34xx or omap44xx Cc: spi-devel-general@lists.sourceforge.net Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com Signed-off-by: Abraham Arce x0066...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- drivers/spi/Kconfig |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index a191fa2..f950b63 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -180,10 +180,10 @@ config SPI_OMAP_UWIRE This hooks up to the MicroWire controller on OMAP1 chips. config SPI_OMAP24XX - tristate McSPI driver for OMAP24xx/OMAP34xx - depends on ARCH_OMAP2 || ARCH_OMAP3 + tristate McSPI driver for OMAP + depends on ARCH_OMAP2PLUS help - SPI master controller for OMAP24xx/OMAP34xx Multichannel SPI + SPI master controller for OMAP24XX and later Multichannel SPI (McSPI) modules. config SPI_OMAP_100K -- ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [PATCH v1 2/3] OMAP4: Ethernet: KS8851 Board Support
* Arce, Abraham x0066...@ti.com [100505 01:06]:
Manjunath,
+
+static void omap_ethernet_init(void)
+{
+ gpio_request(ETHERNET_KS8851_POWER_ENABLE, ethernet);
+ gpio_direction_output(ETHERNET_KS8851_POWER_ENABLE, 1);
+ gpio_request(ETHERNET_KS8851_QUART, quart);
+ gpio_direction_output(ETHERNET_KS8851_QUART, 1);
+ gpio_request(ETHERNET_KS8851_IRQ, ks8851);
Any reason for not checking return value of gpio_request()?
Thought initially about them as dedicated lines for ethernet avoiding
both reasons to check for a gpio's request:
1. invalid gpio
2. already claimed gpio
You still need to check for the result.
Tony
--
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [PATCH v2 1/3] OMAP4: SPI: Fix Driver Kconfig
* Arce, Abraham x0066...@ti.com [100505 00:05]: From: Syed Rafiuddin rafiuddin.s...@ti.com Add OMAP4 data to allow McSPI driver built Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com Signed-off-by: Shubhro a0393...@ti.com Signed-off-by: Santosh Shilimkar santosh shilim...@ti.com Signed-off-by: Abraham Arce x0066...@ti.com --- drivers/spi/Kconfig |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index a191fa2..f950b63 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -180,10 +180,10 @@ config SPI_OMAP_UWIRE This hooks up to the MicroWire controller on OMAP1 chips. config SPI_OMAP24XX - tristate McSPI driver for OMAP24xx/OMAP34xx - depends on ARCH_OMAP2 || ARCH_OMAP3 + tristate McSPI driver for OMAP + depends on ARCH_OMAP2PLUS help - SPI master controller for OMAP24xx/OMAP34xx Multichannel SPI + SPI master controller for OMAP24XX and later Multichannel SPI (McSPI) modules. config SPI_OMAP_100K Planning on merging this via omap tree so we get the omap4 Ethernet working. That is after the related patch has been updated to check the result from gpio_request. Anybody from the spi list care to ack this? Regards, Tony -- ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [PATCH 2/4] OMAP4: SPI: Fix Driver Kconfig
* Arce, Abraham x0066...@ti.com [100422 07:39]: From: Syed Rafiuddin rafiuddin.s...@ti.com Add OMAP4 data to allow McSPI driver built Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com Signed-off-by: Shubhro a0393...@ti.com Signed-off-by: Santosh Shilimkar santosh shilim...@ti.com Signed-off-by: Abraham Arce x0066...@ti.com --- drivers/spi/Kconfig |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index a191fa2..5f54235 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -180,10 +180,10 @@ config SPI_OMAP_UWIRE This hooks up to the MicroWire controller on OMAP1 chips. config SPI_OMAP24XX - tristate McSPI driver for OMAP24xx/OMAP34xx - depends on ARCH_OMAP2 || ARCH_OMAP3 + tristate McSPI driver for OMAP24xx/OMAP34xx/OMAP44xx + depends on ARCH_OMAP24XX || ARCH_OMAP34XX || ARCH_OMAP4 help - SPI master controller for OMAP24xx/OMAP34xx Multichannel SPI + SPI master controller for OMAP24xx/OMAP34xx/OMAP44xx Multichannel SPI (McSPI) modules. config SPI_OMAP_100K You can simplify this and make it more future proof with something like: config SPI_OMAP24XX tristate McSPI driver for OMAP depends on ARCH_OMAP2PLUS help SPI master controller for OMAP24XX and later Regards, Tony -- ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [PATCH 2/6 Revised] SPI omap2_mcspi: Add max_clk_div field to mcspi platform config
* Scott Ellis sc...@jumpnowtek.com [100319 12:43]: Only 3430 and 3630 TRMs says 0xd, 0xe, 0xf = Division not supported. I tested a 3503 with clock divider values of 0x0d, 0x0e and 0x0f. It worked fine. I collected data off the SPI bus successfully at the expected frequencies of 5859 Hz, 2929 Hz and 1464 Hz. But then again, the TRMs can have errors. Looks like this is a case of that. OK, good thing you checked it :) My patches #2 and #3 are unnecessary then and #4 makes use of a new field added in #3. I can resubmit #4, Use transfer speed_hz if provided. That was the original problem I was working on. Should I leave the hard-coded 0x0f in the code or would you prefer a named constant? Named constant in the long run, but a minimal fix is best for the -rc cycle. Regards, Tony -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [PATCH 2/6 Revised] SPI omap2_mcspi: Add max_clk_div field to mcspi platform config
* Scott Ellis sc...@jumpnowtek.com [100314 10:22]:
The McSPI_CHxCONF.CLKD register field has different limits for
the OMAP3 then the OMAP24xx. New max_clk_div field added to
mcspi platform config structure to keep track of this.
Revised patch to not break multi-omap booting.
Signed-off-by: Scott Ellis sc...@jumpnowtek.com
arch/arm/mach-omap2/devices.c | 14 ++
arch/arm/plat-omap/include/plat/mcspi.h |1 +
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 23e4d77..200f382 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -415,6 +415,11 @@ static inline void omap4_mcspi_fixup(void)
defined(CONFIG_ARCH_OMAP4)
static inline void omap2_mcspi3_init(void)
{
+ if (cpu_is_omap343x() || cpu_is_omap44xx())
+ omap2_mcspi3_config.max_clk_div = 0x0c;
+ else
+ omap2_mcspi3_config.max_clk_div = 0x0f;
+
platform_device_register(omap2_mcspi3);
}
#else
Hmm now it looks like you're missing 3630 handling?
If the max_clk_div is 0x0f for 2420 and 2430, then you
can just check for cpu_is_omap24xx(). If it's only
different for 2420, then you can check for cpu_is_omap2420().
That way it should be more future proof, and you don't
need to change it for new processors.
Regards,
Tony
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] SPI troubles
* Ben Gamari bgamari.f...@gmail.com [100314 19:41]: P.P.S. Is it just me or does the omap_pinmux interface need some refinement. Using it has been an exercise in frustration, between extremely sparse documentation, quirky behavior (I still haven't figure out how to get gpio_130 configured. omap_mux_init_gpio fails with multiple paths for gpio130 whereas omap_mux_init_signal fails to even recognize the signal name), and general complexity. The idea behind the interface seems excellent, but it seems it hasn't been used enough not to be a complete pain in the ass to figure out and use. Hopefully incrementally less frustrating now than earlier though :) So far the new mux code has been tested pretty much only with the existing mux settings, so I'm sure quite a some quirks still remain. The problem of omap_mux_init_gpio not recognizing full signal names is known. At least it correctly gives you warnings and refuses to do anything. The real fix probably in the long run is to change everything to use omap_mux_init_signal instead. But what's the issue of omap_mux_init_signal not recognizing the signal name? It should be just mode0_name.desired_mode. Is some entry maybe missing from mux34xx.c? Some of the complexity disappears once I get around to converting the 24xx muxing to the new code so we can get rid of the old code. Some complexity is caused by the need to support bootloader-only muxing while still dynamically muxing the GPIO pins for PM idle. Got some good ideas on how to cut down the complexity further? Regards, Tony -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [PATCH 2/6 Revised] SPI omap2_mcspi: Add max_clk_div field to mcspi platform config
* Scott Ellis sc...@jumpnowtek.com [100315 13:27]: Hmm now it looks like you're missing 3630 handling? If the max_clk_div is 0x0f for 2420 and 2430, then you can just check for cpu_is_omap24xx(). If it's only different for 2420, then you can check for cpu_is_omap2420(). That way it should be more future proof, and you don't need to change it for new processors. Anand Gadiyar gadiyar at ti.com verified 0x0f for the 2430. I think SWPU177D is the correct TRM for the omap3630 and if so then 0x0c is the correct value. I did not verify the omap44xx value and just assumed similar to the omap3's. My bad. Can you or someone point me to links for the omap2420 and the omap44xx TRMs? I'm not having any luck finding them. I don't think those are publicly available yet for 4430 and still for 2420.. But looks like 2420, 2430 and 4430 TRMs says that 0xf = 32768 max divider for CLKD. Only 3430 and 3630 TRMs says 0xd, 0xe, 0xf = Division not supported. But then again, the TRMs can have errors. Then it can be verified whether a cpu_is_omap24xx() check is sufficient. It probably is. Then the 4430 TRM must have an error.. Can somebody from TI confirm the CLKD max value for 4430 please? Or if someone with access to those manuals could do a quick check... It's the max value of the MCSPI_CHxCONF.CLKD register field. Regards, Tony -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] PATCH[V2 1/3]: Update Platform files for SPI
* Grant Likely grant.lik...@secretlab.ca [100218 08:26]: On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren t...@atomide.com wrote: * Hemanth V heman...@ti.com [100203 02:19]: From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001 From: Hemanth V heman...@ti.com Date: Fri, 27 Nov 2009 14:22:30 +0530 Subject: [PATCH] Update platform files This patch updates platform files for fifo, slave support Signed-off-by: Hemanth V heman...@ti.com This should get merged via the spi-devel list with the other patches. Acked-by: Tony Lindgren t...@atomide.com Tony, do you want me to add your acked-by to patches 2 3? No thanks, I've only looked at them briefly. Also, what is your feeling about patch 3/3, spi slave support. spi slave usage model is still a matter under debate, but that patch doesn't touch core spi code, so I'm okay to merge it as a driver-specific feature. However, I'm not convinced that it is actually a useful patch to merge yet, so I'll defer to you on this one. Thoughts? Up to you to decide. But here's my experience so far.. Based on my experience if temporary hacks are merged, then nobody bothers to clean them up properly afterwards and the clean-up task unfairly falls on the maintainer. So IMHO, hacks like that are better floating on the mailing list until they're properly done. It's best to concentrate on getting the core things done right to make long term support easier. Regards, Tony -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] PATCH[V2 1/3]: Update Platform files for SPI
* Tony Lindgren t...@atomide.com [100209 15:03]: * Grant Likely grant.lik...@secretlab.ca [100209 14:38]: On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren t...@atomide.com wrote: * Hemanth V heman...@ti.com [100203 02:19]: From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001 From: Hemanth V heman...@ti.com Date: Fri, 27 Nov 2009 14:22:30 +0530 Subject: [PATCH] Update platform files This patch updates platform files for fifo, slave support Signed-off-by: Hemanth V heman...@ti.com This should get merged via the spi-devel list with the other patches. Acked-by: Tony Lindgren t...@atomide.com Personally, I prefer not to carry arch/* changes in my next-spi branch, since it means that my pull requests are less obvious for Linus and there is greater chance of conflict. But if you still really want me to merge it through my tree, (or if getting the patches out of order will break things) then I'll pick it up. Just let me know. OK, if you ack it, I'll add the header into omap for-next. That might break git bisect for some configurations depending in which order the patches get pulled by Linus.. I guess eventually this header should not live under plat. Hemanth, the patch is missing line breaks so it won't apply: http://patchwork.kernel.org/patch/76675/ Please resend, I'm not editing patches manually any longer thanks. Regards, Tony -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] PATCH[V2 1/3]: Update Platform files for SPI
* Hemanth V heman...@ti.com [100203 02:19]:
From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001
From: Hemanth V heman...@ti.com
Date: Fri, 27 Nov 2009 14:22:30 +0530
Subject: [PATCH] Update platform files
This patch updates platform files for
fifo, slave support
Signed-off-by: Hemanth V heman...@ti.com
This should get merged via the spi-devel list with the other patches.
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/devices.c |5 +
arch/arm/plat-omap/include/plat/mcspi.h | 29 -
2
files changed, 33 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 733d3dc..79b5396 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -282,6 +282,7 @@ static inline void omap_init_sti(void) {}
static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
.num_cs = 4,
+ .force_cs_mode = 1,
};
static struct resource omap2_mcspi1_resources[] = {
@@ -304,6 +305,10 @@ static struct platform_device omap2_mcspi1 = {
static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
.num_cs = 2,
+ .mode = OMAP2_MCSPI_MASTER,
+ .dma_mode = 0,
+ .force_cs_mode = 0,
+ .fifo_depth = 0,
};
static struct resource omap2_mcspi2_resources[] = {
diff --git a/arch/arm/plat-omap/include/plat/mcspi.h
b/arch/arm/plat-omap/include/plat/mcspi.h
index 1254e49..ffda0a1 100644
--- a/arch/arm/plat-omap/include/plat/mcspi.h
+++ b/arch/arm/plat-omap/include/plat/mcspi.h
@@ -1,8 +1,35 @@
#ifndef _OMAP2_MCSPI_H
#define _OMAP2_MCSPI_H
+#define OMAP2_MCSPI_MASTER 0
+#define OMAP2_MCSPI_SLAVE1
+
+/**
+ * struct omap2_mcspi_platform_config - McSPI controller configuration + *
@num_cs: Number of chip selects or channels supported
+ * @mode: SPI is master or slave
+ * @dma_mode: Use only DMA for data transfers
+ * @force_cs_mode: Use force chip select mode or auto chip select mode + *
@fifo_depth: FIFO depth in bytes, max value 64
+ *
+ * @dma_mode when set to 1 uses only dma for data transfers
+ * else the default behaviour is to use PIO mode for transfer
+ * size of 8 bytes or less. This mode is useful when mcspi
+ * is configured as slave
+ *
+ * @force_cs_mode when set to 1 allows continuous transfer of multiple + *
spi
words without toggling the chip select line.
+ *
+ * @fifo_depth when set to non zero values enables FIFO. fifo_depth + *
should
be set as a multiple of buffer size used for read/write. + */
+
struct omap2_mcspi_platform_config {
- unsigned short num_cs;
+ u8 num_cs;
+ u8 mode;
+ u8 dma_mode;
+ u8 force_cs_mode;
+ unsigned short fifo_depth;
};
struct omap2_mcspi_device_config {
--
1.5.6.3
--
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
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] PATCH[V2 1/3]: Update Platform files for SPI
* Grant Likely grant.lik...@secretlab.ca [100209 14:38]: On Tue, Feb 9, 2010 at 3:25 PM, Tony Lindgren t...@atomide.com wrote: * Hemanth V heman...@ti.com [100203 02:19]: From ee48142ddc43129a21676dbb56a83e3e7d8063de Mon Sep 17 00:00:00 2001 From: Hemanth V heman...@ti.com Date: Fri, 27 Nov 2009 14:22:30 +0530 Subject: [PATCH] Update platform files This patch updates platform files for fifo, slave support Signed-off-by: Hemanth V heman...@ti.com This should get merged via the spi-devel list with the other patches. Acked-by: Tony Lindgren t...@atomide.com Personally, I prefer not to carry arch/* changes in my next-spi branch, since it means that my pull requests are less obvious for Linus and there is greater chance of conflict. But if you still really want me to merge it through my tree, (or if getting the patches out of order will break things) then I'll pick it up. Just let me know. OK, if you ack it, I'll add the header into omap for-next. That might break git bisect for some configurations depending in which order the patches get pulled by Linus.. I guess eventually this header should not live under plat. Regards, Tony -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [PATCH v2 2/3] [OMAP] Add spi100k configuration to OMAP1
Hi,
* Cory Maccarrone darkstar6...@gmail.com [091212 17:35]:
This change implements the clocks, platform driver, and register
information necessary to use the spi100k bus with OMAP 7xx systems.
The clocks added are dummy clocks because, although we're pretty
sure there are clocks used for SPI, all current booting methods result
in proper operation without the enabling of any other clocks.
Looks like the driver is in mainline, so let's try to make it working..
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -196,6 +198,37 @@ void __init omap1_init_mmc(struct omap_mmc_platform_data
**mmc_data,
/*-*/
+/* OMAP7xx SPI support */
+#if defined(CONFIG_SPI_OMAP_100K) || defined(CONFIG_SPI_OMAP_100K_MODULE)
+
+struct platform_device omap_spi1 = {
+ .name = omap1_spi100k,
+ .id = 1,
+};
+
+struct platform_device omap_spi2 = {
+ .name = omap1_spi100k,
+ .id = 2,
+};
+
+static void omap_init_spi100k(void)
+{
+ omap_spi1.dev.platform_data = ioremap(OMAP7XX_SPI1_BASE, 0x7ff);
+ BUG_ON(!omap_spi1.dev.platform_data);
+
+ omap_spi2.dev.platform_data = ioremap(OMAP7XX_SPI2_BASE, 0x7ff);
+ BUG_ON(!omap_spi2.dev.platform_data);
+
+ platform_device_register(omap_spi1);
+ platform_device_register(omap_spi2);
+}
I've updated your patch to just check the return value of ioremap instead
of BUG_ON. I've also merged it with the mux patch, see below. Can you
please try it out and make sure everything is OK?
Regards,
Tony
From b6e8076018f8a492c225114d517b2d4a0408ea4c Mon Sep 17 00:00:00 2001
From: Cory Maccarrone darkstar6...@gmail.com
Date: Sun, 13 Dec 2009 01:34:48 +
Subject: [PATCH] omap1: Add 7xx clocks and pin muxes for SPI
Commit 35c9049b27040d09461bc90928ad770be7ddf661 added
drivers/spi/omap_spi_100k.c.
This patch add the related clocks and pin muxing
entries to make the driver work on omap7xx platforms.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index 31fba07..2ac5796 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -658,6 +658,10 @@ static struct omap_clk omap_clks[] = {
CLK(i2c_omap.1, fck, i2c_fck, CK_16XX | CK_1510 | CK_310 | CK_7XX),
CLK(i2c_omap.1, ick, i2c_ick, CK_16XX),
CLK(i2c_omap.1, ick, dummy_ck, CK_1510 | CK_310 | CK_7XX),
+ CLK(omap1_spi100k.1, fck, dummy_ck, CK_7XX),
+ CLK(omap1_spi100k.1, ick, dummy_ck, CK_7XX),
+ CLK(omap1_spi100k.2, fck, dummy_ck, CK_7XX),
+ CLK(omap1_spi100k.2, ick, dummy_ck, CK_7XX),
CLK(omap_uwire, fck, armxor_ck.clk, CK_16XX | CK_1510 | CK_310),
CLK(omap-mcbsp.1, ick, dspper_ck, CK_16XX),
CLK(omap-mcbsp.1, ick, dummy_ck, CK_1510 | CK_310),
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 23ded2d..17ebb47 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -14,6 +14,7 @@
#include linux/init.h
#include linux/platform_device.h
#include linux/io.h
+#include linux/spi/spi.h
#include mach/hardware.h
#include asm/mach/map.h
@@ -23,6 +24,7 @@
#include plat/mux.h
#include mach/gpio.h
#include plat/mmc.h
+#include plat/omap7xx.h
/*-*/
@@ -196,6 +198,38 @@ void __init omap1_init_mmc(struct omap_mmc_platform_data **mmc_data,
/*-*/
+/* OMAP7xx SPI support */
+#if defined(CONFIG_SPI_OMAP_100K) || defined(CONFIG_SPI_OMAP_100K_MODULE)
+
+struct platform_device omap_spi1 = {
+ .name = omap1_spi100k,
+ .id = 1,
+};
+
+struct platform_device omap_spi2 = {
+ .name = omap1_spi100k,
+ .id = 2,
+};
+
+static void omap_init_spi100k(void)
+{
+ omap_spi1.dev.platform_data = ioremap(OMAP7XX_SPI1_BASE, 0x7ff);
+ if (omap_spi1.dev.platform_data)
+ platform_device_register(omap_spi1);
+
+ omap_spi2.dev.platform_data = ioremap(OMAP7XX_SPI2_BASE, 0x7ff);
+ ifi (omap_spi2.dev.platform_data)
+ platform_device_register(omap_spi2);
+}
+
+#else
+static inline void omap_init_spi100k(void)
+{
+}
+#endif
+
+/*-*/
+
#if defined(CONFIG_OMAP_STI)
#define OMAP1_STI_BASE 0xfffea000
@@ -263,6 +297,7 @@ static int __init omap1_init_devices(void)
omap_init_mbox();
omap_init_rtc();
+ omap_init_spi100k();
omap_init_sti();
return 0;
diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c
index 07212cc..8434137 100644
--- a/arch/arm/mach-omap1/mux.c
+++ b/arch/arm/mach-omap1/mux.c
@@ -62,6 +62,14 @@ MUX_CFG_7XX(MMC_7XX_DAT0,2, 17,0, 16, 1, 0)
/* I2C interface */
MUX_CFG_7XX(I2C_7XX_SCL, 5,1,0,0, 1, 0
Re: [spi-devel-general] [PATCH 1/3] [SPI] [OMAP] Add OMAP spi100k driver
Hi,
* Cory Maccarrone darkstar6...@gmail.com [091206 20:48]:
This change adds the OMAP SPI 100k driver created by
Fabrice Crohas fcro...@gmail.com. This SPI bus is found on
OMAP7xx-series smartphones, and for many, the touchscreen is
attached to this bus.
The lion's share of the work was done by Fabrice on this driver --
I am merely porting it from the Linwizard project on his behalf.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
drivers/spi/Kconfig |6 +
drivers/spi/Makefile|1 +
drivers/spi/omap_spi_100k.c | 642
+++
3 files changed, 649 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/omap_spi_100k.c
snip
+static void spi100k_enable_clock(struct spi_master *master)
+{
+ unsigned int val;
+ struct omap1_spi100k *spi100k = spi_master_get_devdata(master);
+
+ /* enable SPI */
+ val = omap_readw(spi100k-base_addr + SPI_SETUP1);
+ val |= SPI_SETUP1_CLOCK_ENABLE;
+ omap_writew(val, spi100k-base_addr + SPI_SETUP1);
+}
Please do not use omap_read/write for the new drivers.
Instead, please use ioremap in the platform init code in
arch/arm/mach-omap1/, and pass the virtual address in
platform_data to the driver. Then you can use readw/writew
in the driver.
We have static mappings in place for ioremap, so there's
no extra overhead.
Regards,
Tony
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [PATCH 2/3] [OMAP] Add spi100k configuration to OMAP1
* Cory Maccarrone darkstar6...@gmail.com [091206 20:48]:
This change implements the clocks, platform driver, and register
information necessary to use the spi100k bus with OMAP 7xx systems.
The clocks added are dummy clocks because, although we're pretty
sure there are clocks used for SPI, all current booting methods result
in proper operation without the enabling of any other clocks.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
arch/arm/mach-omap1/clock.c |4 ++
arch/arm/mach-omap1/devices.c | 70
+
arch/arm/plat-omap/include/plat/omap7xx.h |3 +
arch/arm/plat-omap/include/plat/spi100k.h | 15 ++
4 files changed, 92 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/spi100k.h
diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index dc8ca91..e584c0f 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -135,6 +135,10 @@ static struct omap_clk omap_clks[] = {
CLK(i2c_omap.1, fck,i2c_fck, CK_16XX | CK_1510 |
CK_310 | CK_7XX),
CLK(i2c_omap.1, ick,i2c_ick, CK_16XX),
CLK(i2c_omap.1, ick,dummy_ck, CK_1510 | CK_310 |
CK_7XX),
+ CLK(omap1_spi100k.1, fck, dummy_ck, CK_7XX),
+ CLK(omap1_spi100k.1, ick, dummy_ck, CK_7XX),
+ CLK(omap1_spi100k.2, fck, dummy_ck, CK_7XX),
+ CLK(omap1_spi100k.2, ick, dummy_ck, CK_7XX),
CLK(omap_uwire, fck,armxor_ck.clk, CK_16XX | CK_1510 |
CK_310),
CLK(omap-mcbsp.1, ick, dspper_ck, CK_16XX),
CLK(omap-mcbsp.1, ick, dummy_ck, CK_1510 | CK_310),
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 23ded2d..9f1c1cc 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -24,6 +24,12 @@
#include mach/gpio.h
#include plat/mmc.h
+#if defined(CONFIG_SPI_OMAP_100K)
+#include plat/omap7xx.h
+#include plat/spi100k.h
+#include linux/spi/spi.h
+#endif
+
Please don't ifdef includes, you should be able to include them even
if the driver is not selected.
/*-*/
#if defined(CONFIG_RTC_DRV_OMAP) || defined(CONFIG_RTC_DRV_OMAP_MODULE)
@@ -196,6 +202,69 @@ void __init omap1_init_mmc(struct omap_mmc_platform_data
**mmc_data,
/*-*/
+/* OMAP7xx SPI support */
+#if defined(CONFIG_SPI_OMAP_100K)
+
+#include plat/omap7xx.h
+#include plat/spi100k.h
+#include linux/spi/spi.h
+
+static struct omap_spi100k_platform_config omap_spi1_config = {
+.num_cs = 2,
+};
+
+static struct resource omap_spi1_resources[] = {
+ {
+ .start = OMAP7XX_SPI1_BASE,
+ .end= OMAP7XX_SPI1_BASE + 0x7ff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+struct platform_device omap_spi1 = {
+.name = omap1_spi100k,
+.id = 1,
+.num_resources = ARRAY_SIZE(omap_spi1_resources),
+.resource = omap_spi1_resources,
+.dev= {
+.platform_data = omap_spi1_config,
+},
+};
+
+static struct omap_spi100k_platform_config omap_spi2_config = {
+.num_cs = 2,
+};
+
+static struct resource omap_spi2_resources[] = {
+{
+.start = OMAP7XX_SPI2_BASE,
+.end= OMAP7XX_SPI2_BASE + 0x7ff,
+.flags = IORESOURCE_MEM,
+},
+};
+
+struct platform_device omap_spi2 = {
+.name = omap1_spi100k,
+.id = 2,
+.num_resources = ARRAY_SIZE(omap_spi2_resources),
+.resource = omap_spi2_resources,
+.dev= {
+ .platform_data = omap_spi2_config,
+ },
+};
+
+static void omap_init_spi100k(void)
+{
+platform_device_register(omap_spi1);
+platform_device_register(omap_spi2);
+}
+
+#else
+static inline void omap_init_spi100k(void) {}
+#endif
Here you can do the ioremap I mentioned in the comments for
the driver patch.
Regards,
Tony
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [RESEND][PATCH 2/2] McSPI Slave and DMA, FIFO support
* David Brownell davi...@pacbell.net [090703 03:22]: On Tuesday 23 June 2009, Hemanth V wrote: This patch adds support for McSPI slave and FIFO. DMA and FIFO could be enabled together for better throughput. This has a dependency on patch [RESEND][PATCH 1/2] McSPI Slave and DMA,FIFO support ... in this case I'd think they would better be part of a single patch. However, anything related to SPI slave support should be separated entirely from FIFO support. Ditto anything adding more SPI_DEBUG support. Oh, and use the BIT(n) syntax not (1 n) in the new constants you define... the patch making this driver use that style finally went upstream. I agree with Dave's comments. Maybe repost one more time, then I'd actually prefer these get merged via the SPI list once everybody's happy. Tony -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [PATCH] OMAP: McSPI: Fix RX DMA transfer path
* Kalle Valo kalle.v...@iki.fi [090613 09:45]:
Aaro Koskinen aaro.koski...@nokia.com writes:
From: Eero Nurkkala ext-eero.nurkk...@nokia.com
When data is read through DMA, the last element must be read separately
through the RX register. It cannot be transferred by the DMA. For further
details see e.g. OMAP3430 TRM.
Without the fix the driver causes extra clocks to be clocked to the
bus after DMA RX operations. This can cause interesting behaviour with
some devices.
I was hit by this with stlc45xx and earlier versions of Juuso's patch at
least fixed the problem.
I will test this patch as soon as I get N800 boot with latest
linux-omap, now I only get this:
6JFFS2 version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
6JFFS2 version 2.2. (NAND) (SUMMARY) © 2001-2006 Red H
6msgmni has been set to 247
6io scheduler noop registered (default)
6omapfb: ls041y3 rev 87 LCD detected, 0 data lines d
6serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654
6serial8250.0: ttyS1 at MMIO 0x4806e000 (irq = 74) is a ST16654
óF:5 #!*$Õó¬#05 #!*$Õór%
µ²² æ2Õó$¶ #®*#5##¹'%Õó#62°$¶ ¹)K!¥º¹'Õó¬¹5 K#z 0«²)Ñ%f¡T:6æ0ªÿó¯
ó
%°ö2Õ³#²©T ô#.#É ,#2¬#£µ0V³/5 V§Í#%Ríó00¢F ô- ¹##£$¶ +3Síó
0
·#
# V60±:)¥#
,#µ¥Õ46 V#Õ#
¬é)¶.¹ªÿóµ£É%²:©F%V$®º ¹##£$¶
Í#É¡*ªÿóµ ©#0Á:£µ.#µ¥Õ4#Ô#Kªÿ#ó#Í!Ä)
%
³3{%°ö2±9±SíóÕ {/+#í#ó#Í!Ä)4?+#í#ó#Í!Ä)4ó ö£U4¬¹ ¹)K!)ºªÿóÕ%{/C:³ô
Ù¯s
®Ñ ®®Ò 335#U2,°®!Ä) ô2V#ö/ë¢#4/##®#%!V C%!
Might be related to the omap specific ATAGs now gone, sorry but that
just had to go to get things in sync. And it should not come as a
surprise as it's been discussed over past few years :)
The missing data needs to be initialized in platform_data, cmdline,
ARM generic ATAGs, upcoming device tree.. I suggest using platform_data
where possible. The GPIO values etc coming from nolo can be dumped
with some earlier kernel using CONFIG_ATAGS_PROC.
BTW, I'll move the n8x0 board-*.c files around a bit to have just
board-n800.c, board-n810.c and board-n8x0-peripherals.c.
Regards,
Tony
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
