Re: [PATCH 2/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader
Vimal Singh wrote: On Thu, Apr 29, 2010 at 12:23 PM, Mike Rapoport wrote: Vimal Singh wrote: On Wed, Apr 28, 2010 at 9:36 PM, Mike Rapoport wrote: Signed-off-by: Mike Rapoport + if (gpmc_nand_data->keep_timings) { + gpmc_nand_detect_timings(); + gpmc_nand_data->gpmc_t = &gpmc_default_timings; + } + I guess moving this part to omap2_nand_gpmc_retime will be a good idea. As there, once we get old/default timings we can simply skip the rounding part and directly jump to setting the timings. This way it would be the same as to pass 'gpmc_nand_data->gpmc_t = NULL'. If I correctly understood the previous comments ([1]), the problem with skipping retime is that when L3 clock changes, the gpmc timings became wrong. So, if we convert old/default timings to nanoseconds early during startup every time retime is called it will use the timing settings in nanoseconds thus yielding proper gpmc registers configuration. OK. Then I think we can at least put __rounding__ code inside an 'if' case, something like: if (!gpmc_nand_data->keep_timings) { ... do rounding for supplied timings from board file. ... } Sure, no problem. And, if I'm not terribly mistaken retime should be called each time L3 frequency changes, though with current kernel it's not yet the case... Yes. This is still left. -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader
Vimal Singh wrote: On Wed, Apr 28, 2010 at 9:36 PM, Mike Rapoport wrote: Signed-off-by: Mike Rapoport --- arch/arm/mach-omap2/gpmc-nand.c| 19 ++- arch/arm/plat-omap/include/plat/nand.h |1 + 2 files changed, 19 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c index e57fb29..7c6c027 100644 --- a/arch/arm/mach-omap2/gpmc-nand.c +++ b/arch/arm/mach-omap2/gpmc-nand.c @@ -22,6 +22,7 @@ #define WR_RD_PIN_MONITORING 0x0060 static struct omap_nand_platform_data *gpmc_nand_data; +static struct gpmc_timings gpmc_default_timings; static struct resource gpmc_nand_resource = { .flags = IORESOURCE_MEM, @@ -34,13 +35,24 @@ static struct platform_device gpmc_nand_device = { .resource = &gpmc_nand_resource, }; +static void gpmc_nand_detect_timings(void) +{ + struct gpmc_timings t; + + memset(&t, 0, sizeof(t)); + gpmc_cs_get_timings(gpmc_nand_data->cs, &gpmc_default_timings); +} + static int omap2_nand_gpmc_retime(void) { + struct device *dev = &gpmc_nand_device.dev; struct gpmc_timings t; int err; - if (!gpmc_nand_data->gpmc_t) + if (!gpmc_nand_data->gpmc_t) { + dev_warn(dev, "No timings provided, skipping retime\n"); return 0; + } memset(&t, 0, sizeof(t)); t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->sync_clk); @@ -112,6 +124,11 @@ int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data) return err; } + if (gpmc_nand_data->keep_timings) { + gpmc_nand_detect_timings(); + gpmc_nand_data->gpmc_t = &gpmc_default_timings; + } + I guess moving this part to omap2_nand_gpmc_retime will be a good idea. As there, once we get old/default timings we can simply skip the rounding part and directly jump to setting the timings. This way it would be the same as to pass 'gpmc_nand_data->gpmc_t = NULL'. If I correctly understood the previous comments ([1]), the problem with skipping retime is that when L3 clock changes, the gpmc timings became wrong. So, if we convert old/default timings to nanoseconds early during startup every time retime is called it will use the timing settings in nanoseconds thus yielding proper gpmc registers configuration. And, if I'm not terribly mistaken retime should be called each time L3 frequency changes, though with current kernel it's not yet the case... -- [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/34164/focus=34558 Rest looks fine to me. -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader
On Wed, Apr 28, 2010 at 9:36 PM, Mike Rapoport wrote: > Signed-off-by: Mike Rapoport > --- > arch/arm/mach-omap2/gpmc-nand.c | 19 ++- > arch/arm/plat-omap/include/plat/nand.h | 1 + > 2 files changed, 19 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c > index e57fb29..7c6c027 100644 > --- a/arch/arm/mach-omap2/gpmc-nand.c > +++ b/arch/arm/mach-omap2/gpmc-nand.c > @@ -22,6 +22,7 @@ > #define WR_RD_PIN_MONITORING 0x0060 > > static struct omap_nand_platform_data *gpmc_nand_data; > +static struct gpmc_timings gpmc_default_timings; > > static struct resource gpmc_nand_resource = { > .flags = IORESOURCE_MEM, > @@ -34,13 +35,24 @@ static struct platform_device gpmc_nand_device = { > .resource = &gpmc_nand_resource, > }; > > +static void gpmc_nand_detect_timings(void) > +{ > + struct gpmc_timings t; > + > + memset(&t, 0, sizeof(t)); > + gpmc_cs_get_timings(gpmc_nand_data->cs, &gpmc_default_timings); > +} > + > static int omap2_nand_gpmc_retime(void) > { > + struct device *dev = &gpmc_nand_device.dev; > struct gpmc_timings t; > int err; > > - if (!gpmc_nand_data->gpmc_t) > + if (!gpmc_nand_data->gpmc_t) { > + dev_warn(dev, "No timings provided, skipping retime\n"); > return 0; > + } > > memset(&t, 0, sizeof(t)); > t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->sync_clk); > @@ -112,6 +124,11 @@ int __init gpmc_nand_init(struct omap_nand_platform_data > *_nand_data) > return err; > } > > + if (gpmc_nand_data->keep_timings) { > + gpmc_nand_detect_timings(); > + gpmc_nand_data->gpmc_t = &gpmc_default_timings; > + } > + I guess moving this part to omap2_nand_gpmc_retime will be a good idea. As there, once we get old/default timings we can simply skip the rounding part and directly jump to setting the timings. Rest looks fine to me. -- Regards, Vimal Singh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader
On Thu, Apr 29, 2010 at 12:23 PM, Mike Rapoport wrote: > Vimal Singh wrote: >> >> On Wed, Apr 28, 2010 at 9:36 PM, Mike Rapoport >> wrote: >>> >>> Signed-off-by: Mike Rapoport >>> + if (gpmc_nand_data->keep_timings) { >>> + gpmc_nand_detect_timings(); >>> + gpmc_nand_data->gpmc_t = &gpmc_default_timings; >>> + } >>> + >> >> I guess moving this part to omap2_nand_gpmc_retime will be a good idea. >> As there, once we get old/default timings we can simply skip the >> rounding part and directly jump to setting the timings. > > This way it would be the same as to pass 'gpmc_nand_data->gpmc_t = > NULL'. If I correctly understood the previous comments ([1]), the > problem with skipping retime is that when L3 clock changes, the gpmc > timings became wrong. So, if we convert old/default timings to > nanoseconds early during startup every time retime is called it will use > the timing settings in nanoseconds thus yielding proper gpmc registers > configuration. OK. Then I think we can at least put __rounding__ code inside an 'if' case, something like: if (!gpmc_nand_data->keep_timings) { ... do rounding for supplied timings from board file. ... } > And, if I'm not terribly mistaken retime should be called each time L3 > frequency changes, though with current kernel it's not yet the case... Yes. This is still left. -- Regards, Vimal Singh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader
Signed-off-by: Mike Rapoport --- arch/arm/mach-omap2/gpmc-nand.c| 19 ++- arch/arm/plat-omap/include/plat/nand.h |1 + 2 files changed, 19 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c index e57fb29..7c6c027 100644 --- a/arch/arm/mach-omap2/gpmc-nand.c +++ b/arch/arm/mach-omap2/gpmc-nand.c @@ -22,6 +22,7 @@ #define WR_RD_PIN_MONITORING 0x0060 static struct omap_nand_platform_data *gpmc_nand_data; +static struct gpmc_timings gpmc_default_timings; static struct resource gpmc_nand_resource = { .flags = IORESOURCE_MEM, @@ -34,13 +35,24 @@ static struct platform_device gpmc_nand_device = { .resource = &gpmc_nand_resource, }; +static void gpmc_nand_detect_timings(void) +{ + struct gpmc_timings t; + + memset(&t, 0, sizeof(t)); + gpmc_cs_get_timings(gpmc_nand_data->cs, &gpmc_default_timings); +} + static int omap2_nand_gpmc_retime(void) { + struct device *dev = &gpmc_nand_device.dev; struct gpmc_timings t; int err; - if (!gpmc_nand_data->gpmc_t) + if (!gpmc_nand_data->gpmc_t) { + dev_warn(dev, "No timings provided, skipping retime\n"); return 0; + } memset(&t, 0, sizeof(t)); t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->sync_clk); @@ -112,6 +124,11 @@ int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data) return err; } + if (gpmc_nand_data->keep_timings) { + gpmc_nand_detect_timings(); + gpmc_nand_data->gpmc_t = &gpmc_default_timings; + } + err = gpmc_nand_setup(); if (err < 0) { dev_err(dev, "NAND platform setup failed: %d\n", err); diff --git a/arch/arm/plat-omap/include/plat/nand.h b/arch/arm/plat-omap/include/plat/nand.h index f8efd54..0f727ea 100644 --- a/arch/arm/plat-omap/include/plat/nand.h +++ b/arch/arm/plat-omap/include/plat/nand.h @@ -24,6 +24,7 @@ struct omap_nand_platform_data { void __iomem*gpmc_cs_baseaddr; void __iomem*gpmc_baseaddr; int devsize; + boolkeep_timings; }; /* size (4 KiB) for IO mapping */ -- 1.6.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html