aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
diff options
context:
space:
mode:
authorJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>2012-05-07 16:51:37 -0400
committerDavid Woodhouse <David.Woodhouse@intel.com>2012-05-08 17:24:33 -0400
commitb027274d2e3a332683b73f15e5cea79c240bc9a3 (patch)
tree5aa284f1f43b2532e21695e11e7350435180773c /drivers
parent226bb7df3d22bcf4a1c0fe8206c80cc427498eae (diff)
mtd: ams-delta: fix request_mem_region() failure
A call to request_mem_region() has been introduced in the omap-gpio driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40, "gpio/omap: Use devm_ API and add request_mem_region"). This change prevented the Amstrad Delta NAND driver, which was doing the same in order to take control over OMAP MPU I/O lines that the NAND device hangs off, from loading successfully. The I/O lines and corresponding registers used by the NAND driver are a subset of those used for the GPIO function. Then, to avoid run time collisions, all MPUIO GPIO lines should be marked as requested while initializing the NAND driver, and vice versa, a single MPUIO GPIO line already requested before the NAND driver initialization is attempted should prevent the NAND device from being started successfully. There is another driver, omap-keypad, which also manipulates MPUIO registers, but has never been calling request_mem_region() on startup, so it's not affected by the change in the gpio-omap and works correctly. It uses the depreciated omap_read/write functions for accessing MPUIO registers. Unlike the NAND driver, these I/O lines and registers are separate from those used by the GPIO driver. However, both register sets are non-contiguous and overlapping, so it would be impractical to request the two sets separately, one from the gpio-omap, the other form the omap-keypad driver. In order to solve all these issues correctly, a solution first suggested by Artem Bityutskiy, then closer specified by Tony Lindgren while they commented the initial version of this fix, should be implemented. The gpio-omap driver should export a few functions which would allow the other two drivers to access MPUIO registers in a safe manner instead of trying to manage them in parallel to the GPIO driver. However, such a big change, affecting 3 drivers all together, is not suitable for the rc cycle, and should be prepared for the merge window. Then, an alternative solution is proposed as a regression fix. For the ams-delta NAND driver to initialize correctly in coexistence with the changed GPIO driver, drop the request_mem_region() call from the former, especially as this call is going to be removed while the long-term solution is implemented. Tested on Amstrad Delta. Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Diffstat (limited to 'drivers')
-rw-r--r--drivers/mtd/nand/ams-delta.c17
1 files changed, 6 insertions, 11 deletions
diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 73416951f4c1..861ca8f7e47d 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -212,18 +212,17 @@ static int __devinit ams_delta_init(struct platform_device *pdev)
212 /* Link the private data with the MTD structure */ 212 /* Link the private data with the MTD structure */
213 ams_delta_mtd->priv = this; 213 ams_delta_mtd->priv = this;
214 214
215 if (!request_mem_region(res->start, resource_size(res), 215 /*
216 dev_name(&pdev->dev))) { 216 * Don't try to request the memory region from here,
217 dev_err(&pdev->dev, "request_mem_region failed\n"); 217 * it should have been already requested from the
218 err = -EBUSY; 218 * gpio-omap driver and requesting it again would fail.
219 goto out_free; 219 */
220 }
221 220
222 io_base = ioremap(res->start, resource_size(res)); 221 io_base = ioremap(res->start, resource_size(res));
223 if (io_base == NULL) { 222 if (io_base == NULL) {
224 dev_err(&pdev->dev, "ioremap failed\n"); 223 dev_err(&pdev->dev, "ioremap failed\n");
225 err = -EIO; 224 err = -EIO;
226 goto out_release_io; 225 goto out_free;
227 } 226 }
228 227
229 this->priv = io_base; 228 this->priv = io_base;
@@ -271,8 +270,6 @@ out_gpio:
271 platform_set_drvdata(pdev, NULL); 270 platform_set_drvdata(pdev, NULL);
272 gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB); 271 gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB);
273 iounmap(io_base); 272 iounmap(io_base);
274out_release_io:
275 release_mem_region(res->start, resource_size(res));
276out_free: 273out_free:
277 kfree(ams_delta_mtd); 274 kfree(ams_delta_mtd);
278 out: 275 out:
@@ -285,7 +282,6 @@ out_free:
285static int __devexit ams_delta_cleanup(struct platform_device *pdev) 282static int __devexit ams_delta_cleanup(struct platform_device *pdev)
286{ 283{
287 void __iomem *io_base = platform_get_drvdata(pdev); 284 void __iomem *io_base = platform_get_drvdata(pdev);
288 struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
289 285
290 /* Release resources, unregister device */ 286 /* Release resources, unregister device */
291 nand_release(ams_delta_mtd); 287 nand_release(ams_delta_mtd);
@@ -293,7 +289,6 @@ static int __devexit ams_delta_cleanup(struct platform_device *pdev)
293 gpio_free_array(_mandatory_gpio, ARRAY_SIZE(_mandatory_gpio)); 289 gpio_free_array(_mandatory_gpio, ARRAY_SIZE(_mandatory_gpio));
294 gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB); 290 gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB);
295 iounmap(io_base); 291 iounmap(io_base);
296 release_mem_region(res->start, resource_size(res));
297 292
298 /* Free the MTD device structure */ 293 /* Free the MTD device structure */
299 kfree(ams_delta_mtd); 294 kfree(ams_delta_mtd);