RE: [GIT PULL] ARM: OMAP2+: Add AM335x and AM3517/05 EVM DT support
On Sat, May 12, 2012 at 01:26:20, Tony Lindgren wrote: Hi, * Cousson, Benoit b-cous...@ti.com [120511 05:51]: Hi Tony, Here are some remaining DT patches I was not able to push at 3.4 due to some missing dependency. It applies now fine on top of lo/dt branch. It seems that there are still patches being discussed for those SoCs and we're pretty much done for this merge window. So unless things drag on to -rc8, I'd say we just need to postpone merging new things and merge them early around -rc2. Oops... It seems like I missed this merge window as well... Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] spi/omap: cleanup probe/remove routines
On 09/05/12 18:37 -0600, Grant Likely wrote:
On Wed, 9 May 2012 15:43:58 +0300, Hannu Heikkinen hann...@iki.fi wrote:
Cleanup probe and remove routines, use devm_* functions for
managing resources.
Also, in under free_master label, change use of kfree() into
spi_master_put().
Patch does not apply to my current spi/next branch[1].
[1]git://git.secretlab.ca/git/linux-2.6 spi/next
While I'm thinking about it; Kevin, how do you want me handling OMAP
spi patches. Do you want to pick them up, test them and send me a git
branch to pull like with gpio? Or can I just pick them up?
g.
hi, I forgot this spi/next brach. devm funcs already applied
(commit 1a77b127ae147f5827043a9896d7f4cb248b402e - Shubhrajyoti).
Please ignore below patch, I'll check if there's something devm related
to do left.
br,
Hannu
CC: grant.lik...@secretlab.ca
CC: t...@atomide.com
Signed-off-by: Hannu Heikkinen hann...@iki.fi
---
drivers/spi/spi-omap2-mcspi.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index bb9274c..392efce 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1166,17 +1166,12 @@ static int __init omap2_mcspi_probe(struct
platform_device *pdev)
r-start += regs_offset;
r-end += regs_offset;
mcspi-phys = r-start;
- if (!request_mem_region(r-start, resource_size(r),
- dev_name(pdev-dev))) {
- status = -EBUSY;
- goto free_master;
- }
- mcspi-base = ioremap(r-start, resource_size(r));
+ mcspi-base = devm_request_and_ioremap(pdev-dev, r);
if (!mcspi-base) {
- dev_dbg(pdev-dev, can't ioremap MCSPI\n);
- status = -ENOMEM;
- goto release_region;
+ dev_dbg(pdev-dev, can't request mem and ioremap MCSPI\n);
+ status = -ENOMEM;
+ goto free_master;
}
mcspi-dev = pdev-dev;
@@ -1191,7 +1186,7 @@ static int __init omap2_mcspi_probe(struct
platform_device *pdev)
GFP_KERNEL);
if (mcspi-dma_channels == NULL)
- goto unmap_io;
+ goto free_master;
for (i = 0; i master-num_chipselect; i++) {
char dma_ch_name[14];
@@ -1241,12 +1236,8 @@ disable_pm:
pm_runtime_disable(pdev-dev);
dma_chnl_free:
kfree(mcspi-dma_channels);
-unmap_io:
- iounmap(mcspi-base);
-release_region:
- release_mem_region(r-start, resource_size(r));
free_master:
- kfree(master);
+ spi_master_put(master);
platform_set_drvdata(pdev, NULL);
return status;
}
@@ -1256,8 +1247,6 @@ static int __exit omap2_mcspi_remove(struct
platform_device *pdev)
struct spi_master *master;
struct omap2_mcspi *mcspi;
struct omap2_mcspi_dma *dma_channels;
- struct resource *r;
- void __iomem *base;
master = dev_get_drvdata(pdev-dev);
mcspi = spi_master_get_devdata(master);
@@ -1265,12 +1254,8 @@ static int __exit omap2_mcspi_remove(struct
platform_device *pdev)
omap2_mcspi_disable_clocks(mcspi);
pm_runtime_disable(pdev-dev);
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(r-start, resource_size(r));
- base = mcspi-base;
spi_unregister_master(master);
- iounmap(base);
kfree(dma_channels);
destroy_workqueue(mcspi-wq);
platform_set_drvdata(pdev, NULL);
--
1.7.10
--
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
-
Hannu Heikkinen
hann...@iki.fi
PGP Key fingerprint FB04 2612 05B5 1CBD 9428 9E4D 2407 2F8C 52C0 A173
-
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
On 12 May 2012 05:21, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/11/2012 03:06 PM, Jassi Brar wrote:
On 12 May 2012 00:58, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/10/2012 01:59 PM, Jassi Brar wrote:
...
client0: i2s {
/* has 2 DMA request output signals: 0, 1 */
};
client1: spdif {
/* has 2 DMA request signals: 0, 1 */
};
Do we also need to somehow tag these signals for the client to
differentiate between TX and RX channel ?
Yes, the client's DT binding would certainly need to describe how many
DMA request signals its HW generates, and give a unique ID to each. The
driver would need to request a DMA channel for a specific one of its DMA
requests.
Did I read give a unique ID to each correctly ?
It'd be unique relative to that individual device or DT node, not at any
larger scope.
OK.
Could you please take some time out to jot down an example of how a
typical client's dma specifier should look.
With this proposal, I'm not sure that the client DT node would need any
DMA information at all, at least nothing that identifies which DMA
controllers, channels, or requests are required to service this
node/device's DMA requests - that routing information is all represented
in the DMA controller itself.
(I think Arnd made the following point earlier in this thread):
If you did need to put any other information in DT, then that probably
would go in the DMA client node, since it'd presumably be the same
irrespective of which DMA controller got used. However, that information
presumably wouldn't be needed in DT at all, since the driver would know
it, since it'd be a facet of the HW.
Note: I'm thinking things like DMA physical address (presumably an
offset from the reg property), DMA access size (presumably a fixed
property of the HW), DMA burst size (presumably a property of the HW,
although at least some HW can be programmed to raise the DMA request
signal with a varying number of FIFO entries free, so not fixed), etc.
Yeah, neither did I think a client node should tell more than IDs of
its channels
- which we now decide to simply mention in its binding.
How do I know if you or someone is interested in reworking the patchset
or want me to give it a try?
Thanks,
Jassi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: Add AM335x and AM3517/05 EVM DT support
* Hiremath, Vaibhav hvaib...@ti.com [120512 01:26]: On Sat, May 12, 2012 at 01:26:20, Tony Lindgren wrote: Hi, * Cousson, Benoit b-cous...@ti.com [120511 05:51]: Hi Tony, Here are some remaining DT patches I was not able to push at 3.4 due to some missing dependency. It applies now fine on top of lo/dt branch. It seems that there are still patches being discussed for those SoCs and we're pretty much done for this merge window. So unless things drag on to -rc8, I'd say we just need to postpone merging new things and merge them early around -rc2. Oops... It seems like I missed this merge window as well... We can still queue these into linux-omap for testing as soon as the patches are ready. In general, for anything more intrusive we want to have the patches sitting in linux-omap master branch and then in linux-next for at least a week. Then merging them into mainline tree is usually safe to do. The reason for this is that mainline kernel is our stable tree, not our development tree. We just need to queue most of things between -rc2 and -rc4 into the arm-soc tree, and have any issues fixed up before the merge window. Trying to cram development branches in around -rc6 just causes us a huge maintenance nightmare trying to fix up things in the mainline tree between -rc1 and -rc4. Cheers, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv9 06/10] I2C: OMAP: Fix the crash in i2c remove
On Wed, May 02, 2012 at 08:02:11PM +0530, Shubhrajyoti D wrote: In omap_i2c_remove we are accessing the I2C_CON register without enabling the clocks. Fix the same by enabling the clocks and disabling it. This fixes the following crash. [ 154.723022] [ cut here ] [ 154.725677] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:112 l3_interrupt_handler+0x1b4/0x1c4() [ 154.725677] L3 custom error: MASTER:MPU TARGET:L4 PER2 [ 154.742614] Modules linked in: i2c_omap(-) [ 154.746948] Backtrace: [ 154.746948] [c0013078] (dump_backtrace+0x0/0x110) from [c026c158] (dump_stack+0x18/0x1c) [ 154.752716] r6:0070 r5:c002c43c r4:df9b9e98 r3:df9b8000 [ 154.764465] [c026c140] (dump_stack+0x0/0x1c) from [c0041a2c] (warn_slowpath_common+0x5c/0x6c) [ 154.768341] [c00419d0] (warn_slowpath_common+0x0/0x6c) from [c0041ae0] (warn_slowpath_fmt+0x38/0x40) [ 154.776153] r8:0180 r7:c0361594 r6:c0379b48 r5:00080003 r4:e0838b00 [ 154.790771] r3:0009 [ 154.791778] [c0041aa8] (warn_slowpath_fmt+0x0/0x40) from [c002c43c] (l3_interrupt_handler+0x1b4/0x1c4) [ 154.803710] r3:c0361598 r2:c02ef74c [ 154.807403] [c002c288] (l3_interrupt_handler+0x0/0x1c4) from [c0085f44] (handle_irq_event_percpu+0x58/0 [ 154.818237] r8:002a r7: r6: r5:df808054 r4:df8893c0 [ 154.825378] [c0085eec] (handle_irq_event_percpu+0x0/0x188) from [c00860b8] (handle_irq_event+0x44/0x64) [ 154.835662] [c0086074] (handle_irq_event+0x0/0x64) from [c0088ec0] (handle_fasteoi_irq+0xa4/0x10c) [ 154.845458] r6:002a r5:df808054 r4:df808000 r3:c034a150 [ 154.846466] [c0088e1c] (handle_fasteoi_irq+0x0/0x10c) from [c0085ed0] (generic_handle_irq+0x30/0x38) [ 154.854278] r5:c034aa48 r4:002a [ 154.862091] [c0085ea0] (generic_handle_irq+0x0/0x38) from [c000fd38] (handle_IRQ+0x60/0xc0) [ 154.874450] r4:c034ea70 r3:01f8 [ 154.878234] [c000fcd8] (handle_IRQ+0x0/0xc0) from [c0008478] (gic_handle_irq+0x20/0x5c) [ 154.887023] r7:ff40 r6:df9b9fb0 r5:c034e2b4 r4:001a [ 154.887054] [c0008458] (gic_handle_irq+0x0/0x5c) from [c000ea80] (__irq_usr+0x40/0x60) [ 154.901153] Exception stack(0xdf9b9fb0 to 0xdf9b9ff8) [ 154.907104] 9fa0: beaf1f04 4006be00 000f 000c [ 154.915710] 9fc0: 4006c000 8034 ff40 0007 0007b8d7 [ 154.916778] 9fe0: beaf1b68 d23c 4005baf0 8010 [ 154.931335] r6: r5:8010 r4:4005baf0 r3:beaf1f04 [ 154.937316] ---[ end trace 1b75b31a2719ed21 ]-- Cc: Kevin Hilman khil...@ti.com Cc: Rajendra Nayak rna...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com I'd really like a comment from the PM experts if each and every driver has to ensure that the clocks are enabled on remove like this? --- drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index fec8d5c..44e8cfa 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1108,7 +1108,9 @@ omap_i2c_remove(struct platform_device *pdev) free_irq(dev-irq, dev); i2c_del_adapter(dev-adapter); + pm_runtime_get_sync(pdev-dev); omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0); + pm_runtime_put(pdev-dev); pm_runtime_disable(pdev-dev); iounmap(dev-base); kfree(dev); -- 1.7.5.4 -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCHv9 00/10] I2C fixes
On Wed, May 02, 2012 at 08:02:05PM +0530, Shubhrajyoti D wrote: The patch series does the following - Warn fixes if CONFIG_PM_RUNTIME is not selected. - In case of i2c remove register access was done without any get_sync fix the same. - Folds a patch from Tasslehoff to prevent any merge conflicts. - Prevents the XDUF flag to be set if the underflow condition is not met. - As per discussion in [1] .Adds a patch to rename the 1p153 errata and use the unique id instead as the section number in the recent errata docs has changed. v9: Fix the comments from Wolfram Sang Patch 2 has my comment not addressed, so I stopped reviewing. It is probably more helpful (and easier for me, too) if you do a changelog per patch (and not of the whole series), then you can immediately see if that specific changelog matches the current patch. 'git send-email --annotate' might be helpful here. Thanks, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
On Thu, May 10, 2012 at 7:05 PM, Stephen Warren swar...@wwwdotorg.org wrote: Also, were you intending pinctrl-simple to actually be the GPIO controller itself? That'd be another case that one might consider fairly simple, but then extends to being gpio-simple as well as pinctrl-simple... We have some pinctrl drivers implementing gpiolib too already, and it's unavoidable I think, as some recent discussion about matcing struct gpio_chip and pinctrl GPIO ranges shows. Maybe -simple isn't such a good name for this thing. Noone thinks any kind of pin control is simple in any sense of the word anyway :-D Tony, would pinctrl-dt-only.c be a better name perhaps? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
