DaVinci NAND writing utility release, was: RE: [RFC] Change ECC algorithm from userspace
Adding davinci linux open source ML to CC as folk there might find this utility useful. Javier Martinez Canillas wrote: > On Fri, Oct 28, 2011 at 12:33 PM, Jon Povey > wrote: >> linux-mtd-boun...@lists.infradead.org wrote: >> DM355 and DM365 has similar issues as the RBL expects a different >> OOB/ECC layout to Linux. >> >> What I have done is write a utility that calculates ECC and writes to >> the mtd device in RAW mode. So to rewrite the bootloader I take care >> of the ECC and layout at application level without changing the >> kernel. > Is your utility publicly available? It would be great if I can use it > as an starting point. Management have given the thumbs-up, this is now released under GPL v2 at https://github.com/jonpovey/flashtool Supports DM355 and DM365 RBL layouts, ECC generation, UBI image writing, and various bad block / range handling. Enjoy! -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network -- 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 v5 2/7] arm: pmu: allow platform specific irq enable/disable handling
Hi,
Attach the patch [PATCH v5 2/7] which is rebased on 3.1 -next.
BTW: The [PATCH v5 3/7] should be dropped as commented before, other patches
are OK against 3.1 -next.
thanks,
--
Ming Lei
--
>From 6125bef1aeee84ef22efdf743077f27f5274b6da Mon Sep 17 00:00:00 2001
From: Ming Lei
Date: Wed, 2 Mar 2011 15:00:08 +0800
Subject: [PATCH v6 2/6] arm: pmu: allow platform specific irq enable/disable
handling
This patch introduces .enable_irq and .disable_irq into
struct arm_pmu_platdata, so platform specific irq enablement
can be handled after request_irq, and platform specific irq
disablement can be handled before free_irq.
This patch is for support of pmu irq routed from CTI on omap4.
Acked-by: Jean Pihet
Reviewed-by: Will Deacon
Signed-off-by: Ming Lei
---
arch/arm/include/asm/pmu.h | 15 ---
arch/arm/kernel/perf_event.c | 10 --
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index 71d99b8..46a96a8 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -27,13 +27,22 @@ enum arm_pmu_type {
/*
* struct arm_pmu_platdata - ARM PMU platform data
*
- * @handle_irq: an optional handler which will be called from the interrupt and
- * passed the address of the low level handler, and can be used to implement
- * any platform specific handling before or after calling it.
+ * @handle_irq: an optional handler which will be called from the
+ * interrupt and passed the address of the low level handler,
+ * and can be used to implement any platform specific handling
+ * before or after calling it.
+ * @enable_irq: an optional handler which will be called after
+ * request_irq and be used to handle some platform specific
+ * irq enablement
+ * @disable_irq: an optional handler which will be called before
+ * free_irq and be used to handle some platform specific
+ * irq disablement
*/
struct arm_pmu_platdata {
irqreturn_t (*handle_irq)(int irq, void *dev,
irq_handler_t pmu_handler);
+ void (*enable_irq)(int irq);
+ void (*disable_irq)(int irq);
};
#ifdef CONFIG_CPU_HAS_PMU
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index e6e5d7c..4c4aa83 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -374,6 +374,8 @@ armpmu_release_hardware(struct arm_pmu *armpmu)
{
int i, irq, irqs;
struct platform_device *pmu_device = armpmu->plat_device;
+ struct arm_pmu_platdata *plat =
+ dev_get_platdata(&pmu_device->dev);
irqs = min(pmu_device->num_resources, num_possible_cpus());
@@ -381,8 +383,11 @@ armpmu_release_hardware(struct arm_pmu *armpmu)
if (!cpumask_test_and_clear_cpu(i, &armpmu->active_irqs))
continue;
irq = platform_get_irq(pmu_device, i);
- if (irq >= 0)
+ if (irq >= 0) {
+ if (plat && plat->disable_irq)
+ plat->disable_irq(irq);
free_irq(irq, armpmu);
+ }
}
release_pmu(armpmu->type);
@@ -439,7 +444,8 @@ armpmu_reserve_hardware(struct arm_pmu *armpmu)
irq);
armpmu_release_hardware(armpmu);
return err;
- }
+ } else if (plat && plat->enable_irq)
+ plat->enable_irq(irq);
cpumask_set_cpu(i, &armpmu->active_irqs);
}
--
1.7.5.4
--
Ming Lei
--
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 v4] net/smsc911x: Add regulator support
On Monday 31 October 2011 08:38:39 Robert Marklund wrote: > ChangeLog v3->v4: > - Remove dual prints and old comment on Mike's request. > - Split the request_free fucntion on Mike and Sascha request. would be nice if the enable/disable were split as well ... > iounmap(pdata->ioaddr); > > + (void)smsc911x_enable_disable_resources(pdev, false); i don't think the (void) cast is necessary otherwise looks fine -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3
On Fri, 28 Oct 2011 15:03:36 +0300, Tero Kristo said: > Hi Again, > I created a new version of the patch which should be better than this > hack, I'll send it as an RFC to the l-o list in a bit. > On Thu, 2011-10-13 at 13:49 +0200, Munegowda, Keshava wrote: > > On Thu, Oct 13, 2011 at 4:58 PM, Tero Kristo wrote: > > > On Thu, 2011-10-13 at 09:12 +0200, Munegowda, Keshava wrote: > > >> On Tue, Sep 27, 2011 at 6:48 PM, Munegowda, Keshava > > >> wrote: > > >> > On Tue, Sep 27, 2011 at 6:12 PM, Tero Kristo wrote: > > >> >> On Tue, 2011-09-27 at 08:04 +0200, Basak, Partha wrote: > > >> >> Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: > > >> >> 0115040-6. Kotipaikka: Helsinki > > > Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business > > > ID: 0115040-6. Domicile: Helsinki > Texas Instruments Oy, Porkkalankatu 22, 00180 Helsinki, Finland. Business ID: > 0115040-6. Domicile: Helsinki Moral: Just leave current street addresses out of it. :) And can we *please* trim irrelevant stuff? You top-posted a 2 line reply, followed by the entire note, which a bunch of kernel developers got to scroll through and wonder if they missed an in-line comment. *Especially* after the top part had one line that it wasn't clear if it was a top-posted sig line gone wrong, or 3 attempts to get an address right for inclusion in a patch. pgpPuwI7FKr6i.pgp Description: PGP signature
[PATCH 2/2] OMAP2+: DMA: Workaround for invalid destination position
If the DMA destination position has been asked before the
first actual data transfer has been done, the CDAC
register still contains 0 (it is initialized to 0 at
omsp_dma_start).
If CDAC == 0, return the programmed start address.
Signed-off-by: Peter Ujfalusi
---
arch/arm/plat-omap/dma.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 38b0d44..9186491 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1066,8 +1066,16 @@ dma_addr_t omap_get_dma_dst_pos(int lch)
if (cpu_is_omap15xx())
offset = p->dma_read(CPC, lch);
- else
+ else {
offset = p->dma_read(CDAC, lch);
+ /*
+* CDAC == 0 indicates that the DMA transfer on the channel has
+* not been started (no data has been transferred so far).
+* Return the programmed destination start address in this case.
+*/
+ if (unlikely(!offset))
+ offset = p->dma_read(CDSA, lch);
+ }
/*
* omap 3.2/3.3 erratum: sometimes 0 is returned if CSAC/CDAC is
--
1.7.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
[PATCH 1/2] OMAP2+: DMA: Workaround for invalid source position
If the DMA source position has been asked before the
first actual data transfer has been done, the CSAC
register does not contain valid information.
We can identify this situation by checking the CDAC
register:
CDAC != 0 indicates that the DMA transfer on the channel has
been started already.
When CDAC == 0 we can not trust the CSAC value since it has
not been updated, and can contain random number.
Return the start address in case the DMA has not jet started.
Note: The CDAC register has been initialized to 0 at dma_start
time.
Signed-off-by: Peter Ujfalusi
---
arch/arm/plat-omap/dma.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index c22217c..38b0d44 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1024,12 +1024,23 @@ EXPORT_SYMBOL(omap_set_dma_callback);
*/
dma_addr_t omap_get_dma_src_pos(int lch)
{
+ u32 cdac;
dma_addr_t offset = 0;
if (cpu_is_omap15xx())
offset = p->dma_read(CPC, lch);
- else
- offset = p->dma_read(CSAC, lch);
+ else {
+ /*
+* CDAC == 0 indicates that the DMA transfer on the channel has
+* not been started (no data has been transferred so far).
+* Return the programmed source start address in this case.
+*/
+ cdac = p->dma_read(CDAC, lch);
+ if (likely(cdac))
+ offset = p->dma_read(CSAC, lch);
+ else
+ offset = p->dma_read(CSSA, lch);
+ }
if (IS_DMA_ERRATA(DMA_ERRATA_3_3) && offset == 0)
offset = p->dma_read(CSAC, lch);
--
1.7.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
[PATCH 0/2] OMAP2+: DMA: fix src/dst position reporting
Hello, If the user asks for the sDMA current position before the first data has been transmitted (before the first DMA request has been generated), the reported position is not valid: src position: CSAC is uninitialized dst position: CDAC is 0 The return values in both case considered invalid. This sitation can be identified by checking if the CDAC register is 0 (it is initialized to 0 in omap_dam_start call). In this case return the programmed source/destination address. The affected omap_get_dma_src_pos/omap_get_dma_dst_pos functions are used by the audio stack mainly for checking the current position of the audio stream. Regards, Peter --- Peter Ujfalusi (2): OMAP2+: DMA: Workaround for invalid source position OMAP2+: DMA: Workaround for invalid destination position arch/arm/plat-omap/dma.c | 25 ++--- 1 files changed, 22 insertions(+), 3 deletions(-) -- 1.7.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
Re: [PATCH v3] usb: ehci: report Data Buffer Error in debug mode
On Sun, 30 Oct 2011, Vikram Pandita wrote:
> From: Vikram Pandita
>
> Data Buffer Error as per spec section 4.15.1.1.2
> results when there is Underrun or Overrun condition.
>
> This error is considered non-fatal and never gets reported.
> Its a very good indication on things going wrong at system level,
> like running memory at much slower speed.
>
> This is a good error to flag allowing system level corrections.
>
> An issue was found with OMAP4460 board where DDR had to be run
> at full speed and this logging helped.
>
> Signed-off-by: Vikram Pandita
> Reviewed-by: Marek Vasut
> Signed-off-by: Vikram Pandita
> ---
> v1: original patch
>
> v2: fix review comments from Alan Stern
> * use usb_endpoint_num, usb_endpoint_dir_in
>
> v3: More comments from Alan Stern
> * indent, use qh
>
> drivers/usb/host/ehci-q.c | 11 +++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
> index 4e4066c..f136f7f1 100644
> --- a/drivers/usb/host/ehci-q.c
> +++ b/drivers/usb/host/ehci-q.c
> @@ -373,6 +373,17 @@ qh_completions (struct ehci_hcd *ehci, struct ehci_qh
> *qh)
> retry_xacterr:
> if ((token & QTD_STS_ACTIVE) == 0) {
>
> + /* Report Data Buffer Error: non-fatal but useful */
> + if (token & QTD_STS_DBE)
> + ehci_dbg(ehci,
> + "detected DataBufferErr for urb %p
> ep%d%s len %d, qtd %p [qh %p]\n",
> + urb,
> + usb_endpoint_num(&urb->ep->desc),
> + usb_endpoint_dir_in(&urb->ep->desc) ?
> "in" : "out",
> + urb->transfer_buffer_length,
> + qtd,
> + qh);
> +
> /* on STALL, error, and short reads this urb must
>* complete and all its qtds must be recycled.
>*/
Signed-off-by: Alan Stern
--
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 v4] net/smsc911x: Add regulator support
Add some basic regulator support for the power pins, as needed
by the ST-Ericsson Snowball platform that powers up the SMSC911
chip using an external regulator.
Platforms that use regulators and the smsc911x and have no defined
regulator for the smsc911x and claim complete regulator
constraints with no dummy regulators will need to provide it, for
example using a fixed voltage regulator. It appears that this may
affect (apart from Ux500 Snowball) possibly these archs/machines
that from some grep:s appear to define both CONFIG_SMSC911X and
CONFIG_REGULATOR:
- ARM Freescale mx3 and OMAP 2 plus, Raumfeld machines
- Blackfin
- Super-H
Cc: Paul Mundt
Cc: linux...@vger.kernel.org
Cc: Sascha Hauer
Cc: Tony Lindgren
Cc: linux-omap@vger.kernel.org
Cc: Mike Frysinger
Cc: uclinux-dist-de...@blackfin.uclinux.org
Reviewed-by: Mark Brown
Signed-off-by: Robert Marklund
Signed-off-by: Linus Walleij
---
ChangeLog v3->v4:
- Remove dual prints and old comment on Mike's request.
- Split the request_free fucntion on Mike and Sascha request.
ChangeLog v2->v3:
- Use bulk regulators on Mark's request.
- Add Cc-fileds to some possibly affected platforms.
ChangeLog v1->v2:
- Don't check for NULL regulators and error out properly if the
regulators can't be found. All platforms using the smsc911x
and the regulator framework simultaneously need to provide some
kind of regulator for it.
---
drivers/net/ethernet/smsc/smsc911x.c | 103 ++
1 files changed, 92 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index 8843071..9a2e792 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -88,6 +89,8 @@ struct smsc911x_ops {
unsigned int *buf, unsigned int wordcount);
};
+#define SMSC911X_NUM_SUPPLIES 2
+
struct smsc911x_data {
void __iomem *ioaddr;
@@ -138,6 +141,9 @@ struct smsc911x_data {
/* register access functions */
const struct smsc911x_ops *ops;
+
+ /* regulators */
+ struct regulator_bulk_data supplies[SMSC911X_NUM_SUPPLIES];
};
/* Easy access to information */
@@ -362,6 +368,68 @@ out:
spin_unlock_irqrestore(&pdata->dev_lock, flags);
}
+/*
+ * Enable or disable resources, currently just regulators.
+ */
+static int smsc911x_enable_disable_resources(struct platform_device *pdev,
+bool enable)
+{
+ struct net_device *ndev = platform_get_drvdata(pdev);
+ struct smsc911x_data *pdata = netdev_priv(ndev);
+ int ret = 0;
+
+ /* enable/disable regulators */
+ if (enable) {
+ ret = regulator_bulk_enable(ARRAY_SIZE(pdata->supplies),
+ pdata->supplies);
+ if (ret)
+ netdev_err(ndev, "failed to enable regulators %d\n",
+ ret);
+ } else
+ ret = regulator_bulk_disable(ARRAY_SIZE(pdata->supplies),
+ pdata->supplies);
+ return ret;
+}
+
+/*
+ * Request resources, currently just regulators.
+ *
+ * The SMSC911x has two power pins: vddvario and vdd33a, in designs where
+ * these are not always-on we need to request regulators to be turned on
+ * before we can try to access the device registers.
+ */
+static int smsc911x_request_resources(struct platform_device *pdev)
+{
+ struct net_device *ndev = platform_get_drvdata(pdev);
+ struct smsc911x_data *pdata = netdev_priv(ndev);
+ int ret = 0;
+
+ /* Request regulators */
+ pdata->supplies[0].supply = "vdd33a";
+ pdata->supplies[1].supply = "vddvario";
+ ret = regulator_bulk_get(&pdev->dev,
+ ARRAY_SIZE(pdata->supplies),
+ pdata->supplies);
+ if (ret)
+ netdev_err(ndev, "couldn't get regulators %d\n",
+ ret);
+ return ret;
+}
+
+/*
+ * Free resources, currently just regulators.
+ *
+ */
+static void smsc911x_free_resources(struct platform_device *pdev)
+{
+ struct net_device *ndev = platform_get_drvdata(pdev);
+ struct smsc911x_data *pdata = netdev_priv(ndev);
+
+ /* Free regulators */
+ regulator_bulk_free(ARRAY_SIZE(pdata->supplies),
+ pdata->supplies);
+}
+
/* waits for MAC not busy, with timeout. Only called by smsc911x_mac_read
* and smsc911x_mac_write, so assumes mac_lock is held */
static int smsc911x_mac_complete(struct smsc911x_data *pdata)
@@ -2092,6 +2160,9 @@ static int __devexit smsc911x_drv_remove(struct
platform_device *pdev)
iounmap(pdata->ioaddr);
+ (void)smsc911x_enable_disable_resources(pdev, false);
+ smsc911x_free_resources(pdev);
+
free_netdev(dev);
return 0;
@@ -2
Re: [RFC] Change ECC algorithm from userspace
Hi, On Friday 28 October 2011 12:30:51 Matthieu CASTET wrote: > Hi, > > Javier Martinez Canillas a écrit : > > Hello, > > > > I want to be able to use 1-bit ECC for the first partition where I > > save the loader binary and has to be accessed by the ROM boot but use > > a 4-bit ECC for my rootfs partition. > > > > Does anyone have this same issue? > > We use raw programming and compute the ecc in software. We are doing something similar here as well. Our bootloader also requires the data to be layed out differently (data + ecc interleaved inside a page + oob). > > > What is the best approach to store data in a NAND device using > > different ECC techniques? > > > > I've think of two approaches: > > > > 1- Adding an ioctl to mtdchar (something like ECCSETBITS) to change > > the ECC technique used. > > But this won't work if there is concurrent acess to mtd. One program may > want 1 bit ecc other want 4 bits ecc. > > > 2- Use a platform data field to notify the omap2 nand driver that the > > ROM boot only supports 1-bit ECC. So it can use a 1-bit ECC to write > > and read the first 4 sectors but a 4-bit ECC for the rest. > > This may be better. Would not it better to add infrastructure for allowing per-partition ECC scheme? This should allow the kernel to also be able to properly handle the bootloader partitions (bad-block scanning ...). > > Matthieu > > PS : note that some OMAP ROM support a better protection than Hamming (but > the details are not public AFAIK) > > From OMAP34xx Multimedia Device, Silicon Revision 3.1.x, public version : > > Pages can contain errors caused by memory alteration. To correct these > errors, the ROM code uses ECC, > based on Hamming codes for SLC NAND and BCH (Bose, Ray-Chaudhuri, > Hocquenghem) code for > multilevel cell (MLC) devices. The computed ECC is compared to ECC stored in > the spare area of the > corresponding page. If there are uncorrectable errors, the ROM code returns > with FAIL. -- Florian -- 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 17/51] ARM: OMAP: convert reset to use arm_arch_reset (fwd)
Hello Paul, hello Will,
On Fri, Oct 28, 2011 at 5:47 PM, Paul Walmsley wrote:
>
> fyi
>
>
>
> - Paul
>
> -- Forwarded message --
> Date: Fri, 28 Oct 2011 15:43:45 +0100
> From: Will Deacon
> To: linux-arm-ker...@lists.infradead.org
> Cc: Paul Walmsley , Will Deacon
> Subject: [PATCH 17/51] ARM: OMAP: convert reset to use arm_arch_reset
>
> From: Paul Walmsley
>
> Align the OMAP reset code with Will Deacon's "ARM: reset: introduce
> arm_arch_reset function pointer" cleanup patch.
>
> Signed-off-by: Paul Walmsley
> Signed-off-by: Will Deacon
> ---
> arch/arm/mach-omap1/board-voiceblue.c | 2 +-
> arch/arm/mach-omap1/io.c | 4
> arch/arm/mach-omap1/reset.c | 2 --
> arch/arm/mach-omap2/io.c | 7 ++-
> arch/arm/mach-omap2/prcm.c | 4 +---
> arch/arm/plat-omap/include/plat/system.h | 6 +-
> 6 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
> index 2e40a5c..ad3ac5c 100644
> --- a/arch/arm/mach-omap2/prcm.c
> +++ b/arch/arm/mach-omap2/prcm.c
> @@ -58,7 +58,7 @@ u32 omap_prcm_get_reset_sources(void)
> EXPORT_SYMBOL(omap_prcm_get_reset_sources);
>
> /* Resets clock rates and reboots the system. Only called from system.h */
I think it is no longer called from system.h only, isn't?
> -static void omap_prcm_arch_reset(char mode, const char *cmd)
> +void omap_prcm_arch_reset(char mode, const char *cmd)
> {
> s16 prcm_offs = 0;
>
Thomas
--
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: [RFC] Change ECC algorithm from userspace
On Fri, 28 Oct 2011, Jon Povey wrote: linux-mtd-boun...@lists.infradead.org wrote: I want to be able to use 1-bit ECC for the first partition where I save the loader binary and has to be accessed by the ROM boot but use a 4-bit ECC for my rootfs partition. Does anyone have this same issue? DM355 and DM365 has similar issues as the RBL expects a different OOB/ECC layout to Linux. Slightly off-topic, but in the 355/365 (etc) case it's possible to modify the Linux driver so it uses the RBL ECC layout. For us, it seemed the easiest thing to do, as having different ECC layouts in different parts of the flash proved to be a pain. If you need different ECC algorithms in different parts of the flash this wouldn't work of course. /Ricard -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Swedenwww.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30 -- 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 v9 2/4] cpuidle: Remove CPUIDLE_FLAG_IGNORE and dev->prepare()
On Friday 28 October 2011 07:54 PM, Arjan van de Ven wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 10/28/2011 3:50 AM, Deepthi Dharwar wrote: >> The cpuidle_device->prepare() mechanism causes updates to the >> cpuidle_state[].flags, setting and clearing CPUIDLE_FLAG_IGNORE >> to tell the governor not to chose a state on a per-cpu basis at >> run-time. State demotion is now handled by the driver and it returns >> the actual state entered. Hence, this mechanism is not required. >> Also this removes per-cpu flags from cpuidle_state enabling >> it to be made global. >> > > having worked on some newer platforms > this one is really still needed. doing this inside the actual states > does not work, > because if the deepest 3 states are invalid, the same (somewhat > expensive) test would have to be done 3 times, > and each of the states would have to fail before the 4th one gets chosen. > that's just not going to work > > (in the state handler you can't know what other state to fall back to, > and especially not how to enter such a fallback state) > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.17 (MingW32) > > iQEcBAEBAgAGBQJOqrsGAAoJEEHdSxh4DVnEu7EH/i5lEJctBAIubJOcZz/tvBFp > XYmAe/HqNtSXeHOVsJkTf8y4ppE8487exF7xxMik4GRN0CZNCtkyMezqDVu+eDim > O/UUbScsAc5cSY6mkjOFXLFup+mi1nkRUnAbxXEyTMhWwcbfr2OvcuO7l7TmATML > hu87P3PVEafEop3q2+uWMc57fFxnNFfEDqRx6N9V+OJKV5dHrRYL4G4E01fYGFLo > xTR0IW7nB15L0C29zk9uk/Dqow8SoJZA83c7p7AieP5zdntb6p7noIf03qmdp19f > fulwMwembCHivo+pLO+jAMhKD1T6VYoCyiYW0LHrQ2E07fayBhFJCxlazgKFcl0= > =FL6o > -END PGP SIGNATURE- > Hi Arjan, Thanks for the review. We retain the dev->prepare() routine and CPUIDLE_FLAG_IGNORE but still allow the dev->enter() to return index ? So by retaining it, transition to the idle states would be much quicker in case one more states are invalid. Also to note is that in the newer design, we have split the cpuidle_state structure. One global struct, cpuidle_states[] that contains all the state related information including flags, and the other cpuidle_device that contain statistics and other data that are per-cpu basis. So the flags are not per cpu per state basis but maintained globally as per state basis. So if we have to enable CPUIDLE_FLAG_IGNORE flag in this current new design, then I am thinking if we needed to have this on a per-cpu basis. If so, then flags have to be moved into cpuidle_device struct rather than cpuidle_state struct. Is it a good idea to retain these flags as global (part of cpuidle_states) or make it per-cpu basis ? -Thanks Deepthi -- 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
