Re: [PATCH 5/9] ARM: OMAP2+: gpmc-smc91x: Adapt to use gpmc driver
* Afzal Mohammed af...@ti.com [120611 08:19]:
--- a/arch/arm/mach-omap2/gpmc-smc91x.c
+++ b/arch/arm/mach-omap2/gpmc-smc91x.c
@@ -114,7 +136,13 @@ static int smc91c96_gpmc_retime(void)
if (gpmc_cfg-flags GPMC_MUX_ADD_DATA)
return 0;
- return gpmc_cs_set_timings(gpmc_cfg-cs, t);
+ /* gpmc driver interface */
+ if (gpmc_smc91x_cs_data.mem_size == 0x10) {
+ gpmc_smc91x_cs_data.time_ctrl.type = has_period;
+ gpmc_smc91x_cs_data.time_ctrl.timings = t;
+ return 0;
+ } else
+ return gpmc_cs_set_timings(gpmc_cfg-cs, t);
}
/*
Here too we just need to care about the mainline kernel users
and convert them to use the new interface. No need to keep
gpmc_cs_set_timings around. The same applies for other similar
patches.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/9] ARM: OMAP2+: gpmc-smc91x: Adapt to use gpmc driver
Hi Tony, On Wed, Jun 13, 2012 at 17:59:50, Tony Lindgren wrote: Here too we just need to care about the mainline kernel users and convert them to use the new interface. No need to keep gpmc_cs_set_timings around. The same applies for other similar patches. Not sure whether I follow you here. Do you mean for all the gpmc-* helpers existing initialization needs to be modified to use the new interface, the previous version was doing so. But then that will cause all boards using the same gpmc-* helper to be converted at once (tusb6010 is not an issue as only one board uses it), then the problem will be that there would be a few commits where gpmc may not work properly. And for a particular board, either it has to use old interface or either the new interface, it cannot use both. Consider the case of this one, smc91x, all sdp boards use it, that requires nand, onenand, nor gpmc-* helpers to be converted before board migration for say 3430sdp board, that would mean that 2430sdp board would be broken w.r.t gpmc at that commit as board modifications are not yet done for 2430. That in turn means all the boards using nand, onenand would be broken at that point. Regards Afzal -- 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 5/9] ARM: OMAP2+: gpmc-smc91x: Adapt to use gpmc driver
* Mohammed, Afzal af...@ti.com [120613 06:43]: Hi Tony, On Wed, Jun 13, 2012 at 17:59:50, Tony Lindgren wrote: Here too we just need to care about the mainline kernel users and convert them to use the new interface. No need to keep gpmc_cs_set_timings around. The same applies for other similar patches. Not sure whether I follow you here. Do you mean for all the gpmc-* helpers existing initialization needs to be modified to use the new interface, the previous version was doing so. But then that will cause all boards using the same gpmc-* helper to be converted at once (tusb6010 is not an issue as only one board uses it), then the problem will be that there would be a few commits where gpmc may not work properly. And for a particular board, either it has to use old interface or either the new interface, it cannot use both. Consider the case of this one, smc91x, all sdp boards use it, that requires nand, onenand, nor gpmc-* helpers to be converted before board migration for say 3430sdp board, that would mean that 2430sdp board would be broken w.r.t gpmc at that commit as board modifications are not yet done for 2430. That in turn means all the boards using nand, onenand would be broken at that point. What I mean is keep the old interface in gpmc.c, then convert users one at a time to the new interface, and remove the old interface code from the users. But yeah you're right, it may not be immediately doable for the smc91x case before we dump out the register values. But at least tusb6010 should be able to just convert to use the new interface and drop the old code. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] ARM: OMAP2+: gpmc-smc91x: Adapt to use gpmc driver
Currently gpmc is configured in platform for smc91x. As now
gpmc driver is present, populate details needed for the
driver to configure gpmc, gpmc driver would configure based
on this information. Old interface has been left as is so
that platforms can continue configuring gpmc using old
interface too. This is done so that driver conversion can
be done gradually without breaking any.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-smc91x.c | 69 +
arch/arm/plat-omap/include/plat/gpmc-smc91x.h | 12 +++--
2 files changed, 66 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smc91x.c
b/arch/arm/mach-omap2/gpmc-smc91x.c
index ba10c24..06f7e73 100644
--- a/arch/arm/mach-omap2/gpmc-smc91x.c
+++ b/arch/arm/mach-omap2/gpmc-smc91x.c
@@ -48,6 +48,19 @@ static struct platform_device gpmc_smc91x_device = {
.resource = gpmc_smc91x_resources,
};
+static struct gpmc_cs_data gpmc_smc91x_cs_data;
+
+static struct gpmc_device_pdata gpmc_smc91x_data = {
+ .name = smc91x,
+ .id = -1,
+ .pdata = gpmc_smc91x_info,
+ .pdata_size = sizeof(gpmc_smc91x_info),
+ .per_res= gpmc_smc91x_resources + 1,
+ .per_res_cnt= 1,
+ .cs_data= gpmc_smc91x_cs_data,
+ .num_cs = 1,
+};
+
/*
* Set the gpmc timings for smc91c96. The timings are taken
* from the data sheet available at:
@@ -100,9 +113,18 @@ static int smc91c96_gpmc_retime(void)
l |= GPMC_CONFIG1_WAIT_READ_MON;
if (gpmc_cfg-flags GPMC_WRITE_MON)
l |= GPMC_CONFIG1_WAIT_WRITE_MON;
- if (gpmc_cfg-wait_pin)
- l |= GPMC_CONFIG1_WAIT_PIN_SEL(gpmc_cfg-wait_pin);
- gpmc_cs_write_reg(gpmc_cfg-cs, GPMC_CS_CONFIG1, l);
+
+ /* gpmc driver interface */
+ if (gpmc_smc91x_cs_data.mem_size == 0x10) {
+ gpmc_smc91x_cs_data.have_config = true;
+ /* waitpin macro, not waitpin number */
+ gpmc_smc91x_cs_data.config |= l |
+ (gpmc_cfg-wait_pin GPMC_WAITPIN_MASK);
+ } else {
+ if (gpmc_cfg-wait_pin)
+ l |= GPMC_CONFIG1_WAIT_PIN_SEL(gpmc_cfg-wait_pin);
+ gpmc_cs_write_reg(gpmc_cfg-cs, GPMC_CS_CONFIG1, l);
+ }
/*
* FIXME: Calculate the address and data bus muxed timings.
@@ -114,7 +136,13 @@ static int smc91c96_gpmc_retime(void)
if (gpmc_cfg-flags GPMC_MUX_ADD_DATA)
return 0;
- return gpmc_cs_set_timings(gpmc_cfg-cs, t);
+ /* gpmc driver interface */
+ if (gpmc_smc91x_cs_data.mem_size == 0x10) {
+ gpmc_smc91x_cs_data.time_ctrl.type = has_period;
+ gpmc_smc91x_cs_data.time_ctrl.timings = t;
+ return 0;
+ } else
+ return gpmc_cs_set_timings(gpmc_cfg-cs, t);
}
/*
@@ -132,13 +160,17 @@ void __init gpmc_smc91x_init(struct
omap_smc91x_platform_data *board_data)
if (gpmc_cfg-flags GPMC_TIMINGS_SMC91C96)
gpmc_cfg-retime = smc91c96_gpmc_retime;
- if (gpmc_cs_request(gpmc_cfg-cs, SZ_16M, cs_mem_base) 0) {
- printk(KERN_ERR Failed to request GPMC mem for smc91x\n);
- return;
+ /* old interface */
+ if (gpmc_smc91x_cs_data.mem_size != 0x10) {
+ if (gpmc_cs_request(gpmc_cfg-cs, SZ_16M, cs_mem_base) 0) {
+ pr_err(error: gpmc_cs_request on smc91x\n);
+ return;
+ }
+
+ gpmc_smc91x_resources[0].start = cs_mem_base + 0x300;
+ gpmc_smc91x_resources[0].end = cs_mem_base + 0x30f;
}
- gpmc_smc91x_resources[0].start = cs_mem_base + 0x300;
- gpmc_smc91x_resources[0].end = cs_mem_base + 0x30f;
gpmc_smc91x_resources[1].flags |= (gpmc_cfg-flags IRQF_TRIGGER_MASK);
if (gpmc_cfg-retime) {
@@ -170,6 +202,10 @@ void __init gpmc_smc91x_init(struct
omap_smc91x_platform_data *board_data)
gpio_set_value(gpmc_cfg-gpio_reset, 0);
}
+ /* gpmc driver interface */
+ if (gpmc_smc91x_cs_data.mem_size == 0x10)
+ return;
+
if (platform_device_register(gpmc_smc91x_device) 0) {
printk(KERN_ERR Unable to register smc91x device\n);
gpio_free(gpmc_cfg-gpio_reset);
@@ -184,7 +220,20 @@ free3:
free2:
gpio_free(gpmc_cfg-gpio_irq);
free1:
- gpmc_cs_free(gpmc_cfg-cs);
+ if (gpmc_smc91x_cs_data.mem_size != 0x10)
+ gpmc_cs_free(gpmc_cfg-cs);
printk(KERN_ERR Could not initialize smc91x\n);
}
+
+struct gpmc_device_pdata *
+__init gpmc_smc91x_update(struct omap_smc91x_platform_data *board_data)
+{
+ gpmc_smc91x_cs_data.cs = gpmc_cfg-cs;
+ gpmc_smc91x_cs_data.mem_offset = 0x300;
+ gpmc_smc91x_cs_data.mem_size= 0x10;
+
+
