RE: [PATCH 00/09] OMAP:GPIO:Implement GPIO in HWMOD way
Tony/ Kevin, > -Original Message- > From: Varadarajan, Charulatha > Sent: Thursday, April 22, 2010 9:25 PM > To: linux-omap@vger.kernel.org > Cc: Nayak, Rajendra; p...@pwsan.com; t...@atomide.com; > khil...@deeprootsystems.com; Varadarajan, Charulatha > Subject: [PATCH 00/09] OMAP:GPIO:Implement GPIO in HWMOD way > > This patch series implements GPIO as an early platform driver. > It makes OMAP2PLUS specific GPIO to get adapted to HWMOD FW. > OMAP1 specific GPIO is implemented as early platform device. > > This patch series is created on "origin/pm-wip/hwmods". Planning to send few more patches for adapting some other drivers to HWMOD FW. Which tree should those patches be created on? LO mainline? or hwmods branch? or runtime branch? -V Charulatha -- 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/5] omap iommu: Fix superpage unalignment at allocation of iovm areas
From: Hiroshi DOYU
Superpage addresses should be aligned on mapping size of 4KB, 64KB,
1MB and 16MB respectively both for physical and device virtual
addresses.
Signed-off-by: Hiroshi DOYU
---
arch/arm/plat-omap/iovmm.c | 122 +--
1 files changed, 71 insertions(+), 51 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 65c6d1f..111fbca 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -1,7 +1,7 @@
/*
* omap iommu: simple virtual address space management
*
- * Copyright (C) 2008-2009 Nokia Corporation
+ * Copyright (C) 2008-2010 Nokia Corporation
*
* Written by Hiroshi DOYU
*
@@ -87,33 +87,6 @@ static size_t sgtable_len(const struct sg_table *sgt)
}
#define sgtable_ok(x) (!!sgtable_len(x))
-/*
- * calculate the optimal number sg elements from total bytes based on
- * iommu superpages
- */
-static unsigned int sgtable_nents(size_t bytes)
-{
- int i;
- unsigned int nr_entries;
- const unsigned long pagesize[] = { SZ_16M, SZ_1M, SZ_64K, SZ_4K, };
-
- if (!IS_ALIGNED(bytes, PAGE_SIZE)) {
- pr_err("%s: wrong size %08x\n", __func__, bytes);
- return 0;
- }
-
- nr_entries = 0;
- for (i = 0; i < ARRAY_SIZE(pagesize); i++) {
- if (bytes >= pagesize[i]) {
- nr_entries += (bytes / pagesize[i]);
- bytes %= pagesize[i];
- }
- }
- BUG_ON(bytes);
-
- return nr_entries;
-}
-
/* allocate and initialize sg_table header(a kind of 'superblock') */
static struct sg_table *sgtable_alloc(const size_t bytes, u32 flags)
{
@@ -127,13 +100,8 @@ static struct sg_table *sgtable_alloc(const size_t bytes,
u32 flags)
if (!IS_ALIGNED(bytes, PAGE_SIZE))
return ERR_PTR(-EINVAL);
- /* FIXME: IOVMF_DA_FIXED should support 'superpages' */
- if ((flags & IOVMF_LINEAR) && (flags & IOVMF_DA_ANON)) {
- nr_entries = sgtable_nents(bytes);
- if (!nr_entries)
- return ERR_PTR(-EINVAL);
- } else
- nr_entries = bytes / PAGE_SIZE;
+ /* FIXME: Maximam number of entries are always prepared. */
+ nr_entries = bytes / PAGE_SIZE;
sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
if (!sgt)
@@ -270,7 +238,7 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
*obj, u32 da,
start = da;
alignement = PAGE_SIZE;
- if (flags & IOVMF_DA_ANON) {
+ if ((da == 0) && (flags & IOVMF_DA_ANON)) {
/*
* Reserve the first page for NULL
*/
@@ -404,29 +372,80 @@ static inline void sgtable_drain_vmalloc(struct sg_table
*sgt)
BUG_ON(!sgt);
}
-static void sgtable_fill_kmalloc(struct sg_table *sgt, u32 pa, size_t len)
+static u32 __alloc_area_by_size(u32 start, u32 end, size_t unit,
+ struct scatterlist **_sg)
{
- unsigned int i;
+ u32 e;
struct scatterlist *sg;
- void *va;
- va = phys_to_virt(pa);
+ sg = *_sg;
+ while ((e = start + unit) <= end) {
- for_each_sg(sgt->sgl, sg, sgt->nents, i) {
- size_t bytes;
+ pr_debug("%s: %08x %8d KB\n",
+__func__, start, (e - start) / SZ_1K);
- bytes = iopgsz_max(len);
+ sg_set_buf(sg++, (const void *)start, unit);
+ start += unit;
+ }
+ *_sg = sg;
- BUG_ON(!iopgsz_ok(bytes));
+ return start;
+}
- sg_set_buf(sg, phys_to_virt(pa), bytes);
- /*
-* 'pa' is cotinuous(linear).
-*/
- pa += bytes;
- len -= bytes;
+static void alloc_area_by_size(u32 start, u32 end, u32 unit,
+ struct scatterlist **_sg)
+{
+ u32 addr;
+
+ if (unit == 0)
+ return;
+
+ if (start == end)
+ return;
+
+ addr = ALIGN(start, unit);
+ if (addr > end) {
+ /* retry with smaller granularity */
+ alloc_area_by_size(start, end, iopgsz_max(unit - 1), _sg);
+ return;
+ }
+ /* lower chuck with smaller granularity */
+ alloc_area_by_size(start, addr, iopgsz_max(unit - 1), _sg);
+
+ addr = __alloc_area_by_size(addr, end, unit, _sg);
+ if (addr < end)
+ /* higher chuck with smaller granularity */
+ alloc_area_by_size(addr, end, iopgsz_max(unit - 1), _sg);
+}
+
+#ifdef DEBUG
+static void sgtable_dump_entries(struct sg_table *sgt)
+{
+ unsigned int i;
+ struct scatterlist *sg;
+
+ for_each_sg(sgt->sgl, sg, sgt->nents, i) {
+ pr_debug("%s: %3d %p %6d KB\n",
+__func__, i, sg_virt(sg), sg_dma_len(sg) / SZ_1K);
}
- BUG_ON(len);
+}
+#els
[PATCH 4/5] omap iommu: Insert a gap page between IOVMAs against override
From: Hiroshi DOYU
Inserting a gap page between IOVMAs could detect an override on other
IOVMA with iommu fault. This was originally suggested by Sakari Ailus
and based on the work and comment by David Cohen.
CC: David Cohen
CC: Sakari Ailus
Signed-off-by: Hiroshi DOYU
---
arch/arm/plat-omap/iovmm.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 111fbca..b280766 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -255,16 +255,16 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
*obj, u32 da,
prev_end = 0;
list_for_each_entry(tmp, &obj->mmap, list) {
- if ((prev_end <= start) && (start + bytes < tmp->da_start))
+ if ((prev_end < start) && (start + bytes < tmp->da_start))
goto found;
if (flags & IOVMF_DA_ANON)
- start = roundup(tmp->da_end, alignement);
+ start = roundup(tmp->da_end + 1, alignement);
prev_end = tmp->da_end;
}
- if ((start >= prev_end) && (ULONG_MAX - start >= bytes))
+ if ((start > prev_end) && (ULONG_MAX - start >= bytes))
goto found;
dev_dbg(obj->dev, "%s: no space to fit %08x(%x) flags: %08x\n",
--
1.7.1.rc1
--
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/5] omap iommu: Exit iteration if no possibility of available area
From: Hiroshi DOYU
Searching avaialable spaces should be stopped as soon as it turns out
that there's no possibility with the rest of it.
Signed-off-by: Hiroshi DOYU
---
arch/arm/plat-omap/iovmm.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index b280766..feeb3f4 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -255,7 +255,10 @@ static struct iovm_struct *alloc_iovm_area(struct iommu
*obj, u32 da,
prev_end = 0;
list_for_each_entry(tmp, &obj->mmap, list) {
- if ((prev_end < start) && (start + bytes < tmp->da_start))
+ if (prev_end >= start)
+ break;
+
+ if (start + bytes < tmp->da_start)
goto found;
if (flags & IOVMF_DA_ANON)
--
1.7.1.rc1
--
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 3/5] omap iommu: Make CONFIG_OMAP_IOMMU_DEBUG selectable
From: Hiroshi DOYU This CONFIG_OMAP_IOMMU_DEBUG option cannot be selected because it's not visible on menu. Put this option in "Kernel hacking" menu to make this selectable. Signed-off-by: Hiroshi DOYU --- arch/arm/Kconfig.debug |8 arch/arm/plat-omap/Kconfig |4 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 91344af..43034c2 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -128,4 +128,12 @@ config DEBUG_S3C_UART The uncompressor code port configuration is now handled by CONFIG_S3C_LOWLEVEL_UART_PORT. +config OMAP_IOMMU_DEBUG + tristate "Export OMAP IOMMU internals in DebugFS" + depends on OMAP_IOMMU && DEBUG_FS + help + Select this to see extensive information about + the internal state of OMAP IOMMU in debugfs. + + Say N unless you know you need this. endmenu diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index 6da796e..28069ba 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -109,10 +109,6 @@ config OMAP_MBOX_FWK config OMAP_IOMMU tristate -config OMAP_IOMMU_DEBUG - depends on OMAP_IOMMU - tristate - choice prompt "System timer" default OMAP_MPU_TIMER -- 1.7.1.rc1 -- 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/5] omap iommu: Reject unaligned physical address at setting page table entry
From: Hiroshi DOYU
This rejects unaligned physical address at setting page table entry
and informs error to caller. Otherwise, a wrong address may be used by
IO device.
Signed-off-by: Hiroshi DOYU
---
arch/arm/plat-omap/iommu.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 0e13766..b3591ee 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -503,6 +503,12 @@ static int iopgd_alloc_section(struct iommu *obj, u32 da,
u32 pa, u32 prot)
{
u32 *iopgd = iopgd_offset(obj, da);
+ if (pa & ~IOSECTION_MASK) {
+ dev_err(obj->dev, "%s: pa:%08x should aligned on %08lx\n",
+ __func__, pa, IOSECTION_SIZE);
+ return -EINVAL;
+ }
+
*iopgd = (pa & IOSECTION_MASK) | prot | IOPGD_SECTION;
flush_iopgd_range(iopgd, iopgd);
return 0;
@@ -513,6 +519,12 @@ static int iopgd_alloc_super(struct iommu *obj, u32 da,
u32 pa, u32 prot)
u32 *iopgd = iopgd_offset(obj, da);
int i;
+ if (pa & ~IOSUPER_MASK) {
+ dev_err(obj->dev, "%s: pa:%08x should aligned on %08lx\n",
+ __func__, pa, IOSUPER_SIZE);
+ return -EINVAL;
+ }
+
for (i = 0; i < 16; i++)
*(iopgd + i) = (pa & IOSUPER_MASK) | prot | IOPGD_SUPER;
flush_iopgd_range(iopgd, iopgd + 15);
@@ -542,6 +554,12 @@ static int iopte_alloc_large(struct iommu *obj, u32 da,
u32 pa, u32 prot)
u32 *iopte = iopte_alloc(obj, iopgd, da);
int i;
+ if (pa & ~IOLARGE_MASK) {
+ dev_err(obj->dev, "%s: pa:%08x should aligned on %08lx\n",
+ __func__, pa, IOLARGE_SIZE);
+ return -EINVAL;
+ }
+
if (IS_ERR(iopte))
return PTR_ERR(iopte);
--
1.7.1.rc1
--
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] OMAP:GPIO: Introduce support for OMAP2PLUS chip specific GPIO
> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Thursday, May 06, 2010 4:02 AM
> To: Varadarajan, Charulatha
> Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com;
> khil...@deeprootsystems.com
> Subject: Re: [PATCH 5/9] OMAP:GPIO: Introduce support for OMAP2PLUS chip
> specific
> GPIO
>
> * Charulatha V [100422 08:50]:
> > This patch adds support for handling GPIO as a HWMOD adapted
> > platform device for OMAP2PLUS chips.
>
>
>
> > +int __init gpio_init(void)
> > +{
> > + int i = 0;
> > + static int is_early_device = true;
> > +
> > + do {
> > + struct omap_device *od;
> > + struct omap_hwmod *oh;
> > + int hw_mod_name_len = 16;
> > + int l;
> > + char oh_name[hw_mod_name_len];
> > + struct omap_gpio_platform_data *pdata;
> > + char *name = "omap-gpio";
> > +
> > + l = snprintf(oh_name, hw_mod_name_len, "gpio%d_hwmod", i + 1);
> > + WARN(l >= hw_mod_name_len,
> > + "String buffer overflow in GPIO device setup\n");
> > +
> > + oh = omap_hwmod_lookup(oh_name);
> > + if (!oh) {
> > + pr_err("Could not look up %s\n", oh_name);
> > + i++;
> > + continue;
> > + }
> > +
> > + pdata = kzalloc(sizeof(struct omap_gpio_platform_data),
> > + GFP_KERNEL);
> > + if (!pdata) {
> > + pr_err("Memory allocation failed gpio%d\n", i + 1);
> > + return -ENOMEM;
> > + }
> > + pdata->base = oh->_rt_va;
> > + pdata->irq = oh->mpu_irqs[0].irq;
> > + if (cpu_is_omap24xx() || cpu_is_omap34xx())
> > + pdata->method = METHOD_GPIO_24XX;
> > + if (cpu_is_omap44xx())
> > + pdata->method = METHOD_GPIO_44XX;
> > + pdata->virtual_irq_start = IH_GPIO_BASE + 32 * i;
> > + pdata->device_enable = omap_device_enable;
> > + pdata->device_idle = omap_device_idle;
> > + pdata->device_shutdown = omap_device_shutdown;
> > +
> > + od = omap_device_build(name, i, oh, pdata,
> > + sizeof(*pdata), omap_gpio_latency,
> > + ARRAY_SIZE(omap_gpio_latency),
> > + is_early_device);
> > + WARN(IS_ERR(od), "Cant build omap_device for %s:%s.\n",
> > + name, oh->name);
> > +
> > + i++;
> > + } while (i < gpio_bank_count);
> > + is_early_device = false;
> > +
> > + return 0;
> > +}
> > +arch_initcall(gpio_init);
>
> You can get rid of most of the cpu_is_omap in gpio_init if you pass
> the method as a parameter to gpio_init(int method). We should only need
> to use cpu_is_omap exactly once for every init.
Okay.
>
> > +int __init omap2_gpio_init(void)
> > +{
> > + if (cpu_is_omap242x())
> > + gpio_bank_count = 4;
> > + else if (cpu_is_omap243x())
> > + gpio_bank_count = 5;
> > + else if (cpu_is_omap34xx() || cpu_is_omap44xx())
> > + gpio_bank_count = OMAP34XX_NR_GPIOS;
> > +
> > + if (gpio_init())
> > + return -EINVAL;
> > +
> > + early_platform_driver_register_all("earlygpio");
> > + early_platform_driver_probe("earlygpio", gpio_bank_count, 0);
> > + return 0;
> > +}
>
> Then please replace this init with something like:
Okay.
>
> #ifdef CONFIG_ARCH_OMAP2
> int __init omap242x_gpio_init(void)
> {
> if (!cpu_is_omap2420())
> return -EINVAL;
>
> gpio_bank_count = 4;
>
> return gpio_init(METHOD_GPIO_24XX);
> }
> subsys_initcall(omap242x_gpio_init);
>
> int __init omap243x_gpio_init(void)
> {
> if (!cpu_is_omap2430())
> return -EINVAL;
>
> gpio_bank_count = 5;
>
> return gpio_init(METHOD_GPIO_24XX);
> }
> subsys_initcall(omap243x_gpio_init);
> #endif
>
> #ifdef CONFIG_ARCH_OMAP3
> int __init omap34xx_gpio_init(void)
> {
> if (!cpu_is_omap34xx())
> return -EINVAL;
>
> gpio_bank_count = OMAP34X_NR_GPIOS;
>
> return gpio_init(METHOD_GPIO_34XX);
> }
> subsys_initcall(omap34xx_gpio_init);
> #endif
> ...
>
> This way it will be more future proof when new omaps get added
> and the if else stuff disappears. Also then you'll have an omap
> specific function to initialize the gpio stuff.
>
> Note that then early_platform_driver_register_all and
> early_platform_driver_probe can be moved to gpio_init.
>
> With multi-omap build the subsys_initcall runs for all of the
> selected platforms, but returns early except for the machine
> we're running on. All the code is optimized out for omap
> specific product kernels.
Okay. Will do the needful and send new patch series in 2 weeks.
>
> Regards,
>
> Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
th
RE: [PATCH 9/9] OMAP:GPIO: Implement GPIO as a platform device
> -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Thursday, May 06, 2010 2:30 AM > To: Varadarajan, Charulatha > Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com; > t...@atomide.com > Subject: Re: [PATCH 9/9] OMAP:GPIO: Implement GPIO as a platform device > > "Varadarajan, Charulatha" writes: > > >> -Original Message- > >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > >> Sent: Saturday, May 01, 2010 5:34 AM > >> To: Varadarajan, Charulatha > >> Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com; > t...@atomide.com > >> Subject: Re: [PATCH 9/9] OMAP:GPIO: Implement GPIO as a platform device > >> > >> Charulatha V writes: > >> > >> > This patch implements GPIO as a early platform device. Also it > >> > implements OMAP2PLUS specific GPIO as HWMOD FW adapted driver. > >> > >> Should include a summary explanation of why you're converting to an > >> early platform device as well. > > > > Okay. > > > >> > >> > Inorder to convert GPIO as platform device, modifications are > >> > required in clock_data.c files so that device names can be > >> > used to obtain clock instead of getting clocks by name/NULL ptr. > >> > >> ok > >> > >> > Currently early platform device register does not do device_pm_init. > >> > Hence pm_runtime functions are not used to enable the GPIO device > >> > since gpio is early platform device. > >> > >> OK for now, since this isn't using runtime PM, but maybe we need a > >> late_initcall() here to do the device_pm_init() + pm_runtime_enable() > >> > >> This change log needs more description of the intended init sequence. > >> Right now it seems that there are multiple init paths. Now that GPIO > >> is an early_platform_device, we should be able to at least make > >> omap_gpio_init() static and remove its usage from all the board files. > > > > This was the implementation that I initially did in my previous patch > > series. The following needs to be considered: > > > > 1. omap2_init_devices() might be too late for early_gpio_init() to > > be placed in it. > > > > 2. omap_init_irq() needs to be completed before calling early_gpio_init(). > > So, if early_gpio_init() is called from omap2_init_common_hw(), we need to > > have omap_init_irq() called before omap2_init_common_hw(). But Tony > > objected this approach mentioning that board might not boot up as > > omap2_init_common_hw() has to be done asap. > > > > That's why, I had not moved the omap_gpio_init() usage from board files. > > OK... for now. I'd still like to see GPIO init consolidated as there's > no (good) reason why every board file has to init GPIOs when it's common > for all SoCs, but this doesn't necessarily have to be done in your series. > Although, if you do it for OMAP1 (as proposed below) you should do similar > for OMAP2+. Okay. Will use arch/subsys_initcall for starting the GPIO as per Tony's suggestion. > > >> > >> Also, the driver and device separation and init is totally mixed > >> together and very confusing. The platform_driver is in > > > > Agreed. Please see my comment at the end of this patch in reply to your > > other similar comment. > > > > > >> plat-omap/gpio.c and should be doing the driver init: > >> [early_]platform_driver_register() and _probe(). The platform_device > >> setup is in mach-omapX/gpio*.c and where the device init should be, in > >> this case early_platform_add_devices(). > > > > In early_gpio_init, omap_device_build() (device specific) and > > early_platform_driver_register_all() (driver specific), _probe() are > > done in a sequence. This is because early_gpio_init needs to be called > > asap and if we try to split this device specific and driver specific > > early_inits, we will end up having two init calls for each early drivers. > > > > I feel that multiple function calls for early_init (one for driver probe and > > one for device register) should be avoided as we need to find the right > > place > > to call them. > > But your driver probe is already in a separate init path (via > arch_initcall) from your device init path omap_gpio_init(). > > My problem is that there is a 2nd driver init path: > board file -> [driver]omap_gpio_init() -> [device] _gpio_init() > > The fact that it goes through the driver is what I don't like. > Okay. > >> > >> > >> > Signed-off-by: Charulatha V > >> > Signed-off-by: Rajendra Nayak > >> > --- > >> > arch/arm/mach-omap1/Makefile |6 + > >> > arch/arm/mach-omap1/clock_data.c |2 +- > >> > arch/arm/mach-omap2/Makefile |2 +- > >> > arch/arm/mach-omap2/clock2420_data.c | 10 +- > >> > arch/arm/mach-omap2/clock2430_data.c | 14 +- > >> > arch/arm/mach-omap2/clock3xxx_data.c | 24 +- > >> > arch/arm/mach-omap2/clock44xx_data.c | 24 +- > >> > arch/arm/plat-omap/gpio.c | 405 > >> > -- > -- > >> > arch/arm/plat-omap/include/plat/gpio.h | 21 ++ > >> > 9 files
RE: [PATCH V2]omap: mux.c warning removal
From: Keshava Munegowda This patch removes the below warning arch/arm/mach-omap2/mux.c:52: warning: 'mux_phys' defined but not used The definition of variable mux_phys should be enclosed in the macro CONFIG_ARCH_OMAP3 Signed-off-by: Keshava Munegowda Index: linux-2.6/arch/arm/mach-omap2/mux.c === --- linux-2.6.orig/arch/arm/mach-omap2/mux.c2010-05-05 23:59:19.0 +0530 +++ linux-2.6/arch/arm/mach-omap2/mux.c 2010-05-06 00:00:07.0 +0530 @@ -49,7 +49,7 @@ struct list_headnode; }; -static unsigned long mux_phys; + static void __iomem *mux_base; u16 omap_mux_read(u16 reg) @@ -373,6 +373,7 @@ #ifdef CONFIG_ARCH_OMAP3 static LIST_HEAD(muxmodes); static DEFINE_MUTEX(muxmode_mutex); +static unsigned long mux_phys; #ifdef CONFIG_OMAP_MUX -- 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]i2c-omap: pass scll, sclh through board file for Errata i585
From: Balaji T K Errata ID: i535 - I2C1 to 3 SCL low period is shorter in FS mode Due to IO cell influence, I2C1 to 3 SCL low period can be shorter than expected. As a result, I2C AC timing (SCL minimum low period) in FS mode may not meet the timing configured by software. I2C1 to 3, SCL low period is programmable and proper adjustments to the SCLL/HSSCLL values can avoid the issue. This patch provides flexibility to control tLOW, tHIGH for different boards. scll, sclh values are to be provide in board data for differents modes (standard, fast and high speed mode) as the scl rate (I2C bus speed) can be changed by bootargs. If scll, sclh values are not provided, scll and sclh values will be computed for duty cycle tHIGH:tLOW of 1:2 (for HS, FS) and 1:1 for Standard as before >From TRM table : HS I2C tLOW and thighValues of the I2C Clock F/S, SCCB, or HS first phase I2Ci_INTERNAL_CLK = I2Ci_FCLK / (I2Ci.I2C_PSC[7:0] PSC field + 1) tlow = (I2Ci.I2C_SCLL[7:0]SCLL field value + 7) * I2Ci_INTERNAL_CLK period thigh = (I2Ci.I2C_SCLH[7:0]SCLH field value + 5) * I2Ci_INTERNAL_CLK period HS second phase tlow = (I2Ci.I2C_SCLL[15:8]HSSCLL field value + 7) * I2Ci_FCLK period thigh = (I2Ci.I2C_SCLH[15:8]HSSCLH field value + 5) * I2Ci_FCLK period i2c bus rate = 1/(tlow + thigh) Split tLOW and thigh to meet minimum tLOW and tHIGH I2C spec. Actual tlow and thigh periods may vary depending on board (the load capacitance on the SCL signal). If necessary, any adjustments to the SCLL/SCLH/HSSCLL/HSSCLH values must be determined by measurements of actual SCL signal on the board Tested with omap3_defconfig on 3430 SDP Signed-off-by: Balaji T K --- arch/arm/mach-omap1/board-ams-delta.c|2 +- arch/arm/mach-omap1/board-fsample.c |2 +- arch/arm/mach-omap1/board-generic.c |2 +- arch/arm/mach-omap1/board-h2.c |2 +- arch/arm/mach-omap1/board-h3.c |2 +- arch/arm/mach-omap1/board-innovator.c|2 +- arch/arm/mach-omap1/board-nokia770.c |2 +- arch/arm/mach-omap1/board-osk.c |2 +- arch/arm/mach-omap1/board-palmte.c |2 +- arch/arm/mach-omap1/board-palmtt.c |2 +- arch/arm/mach-omap1/board-palmz71.c |2 +- arch/arm/mach-omap1/board-perseus2.c |2 +- arch/arm/mach-omap1/board-sx1.c |2 +- arch/arm/mach-omap1/board-voiceblue.c|2 +- arch/arm/mach-omap2/board-2430sdp.c |4 +- arch/arm/mach-omap2/board-3430sdp.c | 18 -- arch/arm/mach-omap2/board-am3517evm.c|6 ++-- arch/arm/mach-omap2/board-cm-t35.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |4 +- arch/arm/mach-omap2/board-igep0020.c |4 +- arch/arm/mach-omap2/board-ldp.c |6 ++-- arch/arm/mach-omap2/board-n8x0.c |2 +- arch/arm/mach-omap2/board-omap3beagle.c |4 +- arch/arm/mach-omap2/board-omap3evm.c |6 ++-- arch/arm/mach-omap2/board-omap3pandora.c |4 +- arch/arm/mach-omap2/board-omap3touchbook.c |4 +- arch/arm/mach-omap2/board-overo.c|4 +- arch/arm/mach-omap2/board-rx51-peripherals.c |6 ++-- arch/arm/mach-omap2/board-zoom-peripherals.c |6 ++-- arch/arm/plat-omap/i2c.c | 12 +++ arch/arm/plat-omap/include/plat/i2c.h| 21 drivers/i2c/busses/i2c-omap.c| 46 + include/linux/i2c-omap.h | 10 ++ 33 files changed, 141 insertions(+), 56 deletions(-) diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c index 7fc11c3..fad4205 100644 --- a/arch/arm/mach-omap1/board-ams-delta.c +++ b/arch/arm/mach-omap1/board-ams-delta.c @@ -228,7 +228,7 @@ static void __init ams_delta_init(void) omap_board_config = ams_delta_config; omap_board_config_size = ARRAY_SIZE(ams_delta_config); omap_serial_init(); - omap_register_i2c_bus(1, 100, NULL, 0); + omap_register_i2c_bus(1, 100, NULL, NULL, 0); /* Clear latch2 (NAND, LCD, modem enable) */ ams_delta_latch2_write(~0, 0); diff --git a/arch/arm/mach-omap1/board-fsample.c b/arch/arm/mach-omap1/board-fsample.c index 096f2ed..3eba5ac 100644 --- a/arch/arm/mach-omap1/board-fsample.c +++ b/arch/arm/mach-omap1/board-fsample.c @@ -297,7 +297,7 @@ static void __init omap_fsample_init(void) omap_board_config = fsample_config; omap_board_config_size = ARRAY_SIZE(fsample_config); omap_serial_init(); - omap_register_i2c_bus(1, 100, NULL, 0); + omap_register_i2c_bus(1, 100, NULL, NULL, 0); } static void __init fsample_init_smc91x(void) diff --git a/arch/arm/mach-omap1/board-generic.c b/arch/arm/mach-omap1/board-generic.c index e1195a3..f20a50d 100644 --- a/arch/arm/mach-omap1/board-generic.c +++ b/arch/arm/mach-omap1/board-generic.c @@ -84,7 +84,
linux-next: manual merge of the omap_dss2 tree with the omap tree
Hi Tomi,
Today's linux-next merge of the omap_dss2 tree got a conflict in
arch/arm/mach-omap2/board-rx51-peripherals.c between commit
e87da74e34ad151e6ae75ebb7a7bf447f02c0004 ("omap: rx51: Add supplies for
the tlv320aic3x codec driver") from the omap tree and commit
a693839eab0292aa234d7a6f48d40389389baebb ("OMAP: RX51: Add "vdds_sdi"
supply voltage for SDI") from the omap_dss2 tree.
Just overlapping additions. I fixed it up (see below) and can carry the
fix as necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-omap2/board-rx51-peripherals.c
index 8179d55,020f354..000
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@@ -287,35 -315,19 +315,48 @@@ static struct regulator_consumer_suppl
.dev_name = "mmci-omap-hs.1",
};
+static struct regulator_consumer_supply rx51_vmmc2_supplies[] = {
+ /* tlv320aic3x analog supplies */
+ {
+ .supply = "AVDD",
+ .dev_name = "2-0018",
+ },
+ {
+ .supply = "DRVDD",
+ .dev_name = "2-0018",
+ },
+ /* Keep vmmc as last item. It is not iterated for newer boards */
+ {
+ .supply = "vmmc",
+ .dev_name = "mmci-omap-hs.1",
+ },
+};
+
+static struct regulator_consumer_supply rx51_vio_supplies[] = {
+ /* tlv320aic3x digital supplies */
+ {
+ .supply = "IOVDD",
+ .dev_name = "2-0018"
+ },
+ {
+ .supply = "DVDD",
+ .dev_name = "2-0018"
+ },
+};
+
+ #if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+ extern struct platform_device rx51_display_device;
+ #endif
+
+ static struct regulator_consumer_supply rx51_vaux1_consumers[] = {
+ #if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+ {
+ .supply = "vdds_sdi",
+ .dev= &rx51_display_device.dev,
+ },
+ #endif
+ };
+
static struct regulator_init_data rx51_vaux1 = {
.constraints = {
.name = "V28",
--
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 v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature
> -Original Message- > From: Chikkature Rajashekar, Madhusudhan > Sent: Thursday, May 06, 2010 9:50 PM > To: Shilimkar, Santosh; 'kishore kadiyala' > Cc: S, Venkatraman; linux-omap@vger.kernel.org; linux-...@vger.kernel.org; > linux-arm- > ker...@lists.arm.linux.org.uk; 'Adrian Hunter'; Kadiyala, Kishore; 'Tony > Lindgren' > Subject: RE: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor > autoloading feature > > > > > -Original Message- > > From: Shilimkar, Santosh [mailto:santosh.shilim...@ti.com] > > Sent: Thursday, May 06, 2010 4:39 AM > > To: kishore kadiyala > > Cc: S, Venkatraman; linux-omap@vger.kernel.org; linux-...@vger.kernel.org; > > linux-arm-ker...@lists.arm.linux.org.uk; Chikkature Rajashekar, > > Madhusudhan; Adrian Hunter; Kadiyala, Kishore; Tony Lindgren > > Subject: RE: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor > > autoloading feature > > > > > -Original Message- > > > From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com] > > > Sent: Thursday, May 06, 2010 2:32 PM > > > To: Shilimkar, Santosh > > > Cc: S, Venkatraman; linux-omap@vger.kernel.org; linux- > > m...@vger.kernel.org; linux-arm- > > > ker...@lists.arm.linux.org.uk; Chikkature Rajashekar, Madhusudhan; > > Adrian Hunter; Kadiyala, Kishore; > > > Tony Lindgren > > > Subject: Re: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor > > autoloading feature > > > > > > <> > > > > > > >> I am not clear about the method. The board files export the > > > >> omap_mmc_platform_data. > > > >> Does it imply that all board files have to change and export > > > >> the capability so that it can be queried ? > > > > No. You don't have to modify the board files. This would need > > > > change in devices.c which common for all omap boards. > > > > > > > > I don't have a strong opinion on this point but just put forth an > > > > alternate way to avoid such SOC specific check in drivers. > > > > You can take call on this > > > > > > Agree. How about adding a flag in hsmmc.h & omap_mmc_platform_data, > > > that would take care of SDMA & SDMA_DLAOD in the driver instead going > > > with SOC check . > > > > Good idea Kishore. > > Venkat, > > Can you do what kishore is suggesting. > > > omap_mmc_platform_data is MMC specific platform data. Why add a SDMA > specific feature capability into it? Even though you add it there, you will > still need to have a cpu check before that can be set in a common code. > CPU checks are allowed to be in the platform files. That is where such machine/SOC specific differentiation should be done and not in the device drivers. That way device drivers remains clean and portable. I want to stop this thread here since neither the patch author nor the file maintainer thinks that cpu checks in the device drivers is bad idea. Please decide within yourself and move on. Regards, Santosh -- 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
Optometrists - 63,837 records 2,015 emails
Here's a list package on sale this week only: Business/Consumer List Package US New Business Database - 4.8 million records all with emails American Consumer Database - 1,300,000 records all with emails. American Homeowners - 1 million Full Data Records all with emails All complete lists above: $295 There are more packages and not just for business. we also have healthcare, consumers and more. Contact me here for more info or to get samples: wade.bo...@realresults.co.cc To invoke no further correspondence status please send an email to disapp...@realresults.co.cc -- 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: DSS2: Fix omap_dss_probe() error path
Jani Nikula writes: > From: Jani Nikula > > Perform graceful cleanup on errors instead of just bailing out. > > Signed-off-by: Jani Nikula Tested-by: Kevin Hilman Nice. Much cleaner than my previous one. Tested on my n900, and with failed init, clocks are turned off and doesn't prevent suspend. Thanks, Kevin -- 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 1/2] OMAP: DSS2: omap_dss_probe() conditional compilation cleanup
Jani Nikula writes: > From: Jani Nikula > > Move a number of #ifdefs from code into dss.h and elsewhere, and > conditionally define no-op static inline functions, cleaning up the > code. This style is according to Documentation/SubmittingPatches. > > Signed-off-by: Jani Nikula Indeed, this helps readability greatly. Acked-by: Kevin Hilman -- 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: [PATCHv3 1/5] OMAP: RX51: Add LCD Panel support
Roger Quadros writes:
> From: Roger Quadros
>
> Adds basic support for LCD Panel on Nokia N900
>
> Signed-off-by: Roger Quadros
Just noticed a compile problem here...
[...]
> diff --git a/arch/arm/mach-omap2/board-rx51-video.c
> b/arch/arm/mach-omap2/board-rx51-video.c
[...]
> +void __init rx51_video_mem_init(void)
> +{
> + /*
> + * GFX 864x480x32bpp
> + * VID1/2 1280x720x32bpp double buffered
> + */
> + omap_vram_set_sdram_vram(PAGE_ALIGN(864 * 480 * 4) +
> + 2 * PAGE_ALIGN(1280 * 720 * 4 * 2), 0);
> +}
> +
> +#endif /* defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE) */
This function is available conditionally based on the #ifdefs, but...
> diff --git a/arch/arm/mach-omap2/board-rx51.c
> b/arch/arm/mach-omap2/board-rx51.c
> index b155c36..1b86b5b 100644
> --- a/arch/arm/mach-omap2/board-rx51.c
> +++ b/arch/arm/mach-omap2/board-rx51.c
> @@ -36,6 +36,7 @@
> #define RX51_GPIO_SLEEP_IND 162
>
> struct omap_sdrc_params *rx51_get_sdram_timings(void);
> +extern void rx51_video_mem_init(void);
>
> static struct gpio_led gpio_leds[] = {
> {
> @@ -143,6 +144,7 @@ static void __init rx51_init(void)
> static void __init rx51_map_io(void)
> {
> omap2_set_globals_343x();
> + rx51_video_mem_init();
... here it is always called, giving a compiler error when building
without FB support.
Kevin
--
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 v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature
> -Original Message- > From: Shilimkar, Santosh [mailto:santosh.shilim...@ti.com] > Sent: Thursday, May 06, 2010 4:39 AM > To: kishore kadiyala > Cc: S, Venkatraman; linux-omap@vger.kernel.org; linux-...@vger.kernel.org; > linux-arm-ker...@lists.arm.linux.org.uk; Chikkature Rajashekar, > Madhusudhan; Adrian Hunter; Kadiyala, Kishore; Tony Lindgren > Subject: RE: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor > autoloading feature > > > -Original Message- > > From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com] > > Sent: Thursday, May 06, 2010 2:32 PM > > To: Shilimkar, Santosh > > Cc: S, Venkatraman; linux-omap@vger.kernel.org; linux- > m...@vger.kernel.org; linux-arm- > > ker...@lists.arm.linux.org.uk; Chikkature Rajashekar, Madhusudhan; > Adrian Hunter; Kadiyala, Kishore; > > Tony Lindgren > > Subject: Re: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor > autoloading feature > > > > <> > > > > >> I am not clear about the method. The board files export the > > >> omap_mmc_platform_data. > > >> Does it imply that all board files have to change and export > > >> the capability so that it can be queried ? > > > No. You don't have to modify the board files. This would need > > > change in devices.c which common for all omap boards. > > > > > > I don't have a strong opinion on this point but just put forth an > > > alternate way to avoid such SOC specific check in drivers. > > > You can take call on this > > > > Agree. How about adding a flag in hsmmc.h & omap_mmc_platform_data, > > that would take care of SDMA & SDMA_DLAOD in the driver instead going > > with SOC check . > > Good idea Kishore. > Venkat, > Can you do what kishore is suggesting. > omap_mmc_platform_data is MMC specific platform data. Why add a SDMA specific feature capability into it? Even though you add it there, you will still need to have a cpu check before that can be set in a common code. > Regards, > Santosh -- 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 v2 3/5] OMAP4-HSMMC: Adding MMC-TWL regulator changes
<>
> As I understand it, the PBIAS configuration is required for HSMMC
> irrespective of how the power is supplied, thus it is not TWL related.
> The TWL stuff should not be in hsmmc.c.
>
> Also I would suggest the only change to omap_hsmmc is:
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index e9caf69..f792cff 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -465,8 +465,6 @@ static int omap_hsmmc_gpio_init(struct
> omap_mmc_platform_data *pdata)
> int ret;
>
> if (gpio_is_valid(pdata->slots[0].switch_pin)) {
> - pdata->suspend = omap_hsmmc_suspend_cdirq;
> - pdata->resume = omap_hsmmc_resume_cdirq;
> if (pdata->slots[0].cover)
> pdata->slots[0].get_cover_state =
> omap_hsmmc_get_cover_state;
> @@ -2160,6 +2158,8 @@ static int __init omap_hsmmc_probe(struct
> platform_device *pdev)
> "Unable to grab MMC CD IRQ\n");
> goto err_irq_cd;
> }
> + pdata->suspend = omap_hsmmc_suspend_cdirq;
> + pdata->resume = omap_hsmmc_resume_cdirq;
> }
>
> OMAP_HSMMC_WRITE(host->base, ISE, INT_EN_MASK);
>
>
> And that the late init function is used to do the rest e.g.
> find a home for these 3 functions:
>
> static int omap4_twl6030_hsmmc_late_init(struct device *dev)
> {
> int ret = 0;
> struct platform_device *pdev = container_of(dev,
> struct platform_device, dev);
> struct omap_mmc_platform_data *pdata = dev->platform_data;
>
> /* MMC1 Card detect Configuration */
> if (pdev->id == 0) {
> ret = omap4_hsmmc1_card_detect_config();
> if (ret < 0)
> pr_err("Unable to configure Card detect for MMC1\n");
> pdata->slots[0].card_detect = twl6030_mmc_card_detect;
> pdata->slots[0].card_detect_irq = TWL6030_IRQ_BASE +
> MMCDETECT_INTR_OFFSET;
> }
> return ret;
> }
>
> static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
> {
> struct omap_mmc_platform_data *pdata = dev->platform_data;
>
> pdata->init = omap4_twl6030_hsmmc_late_init;
> }
>
> void __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
> {
> struct omap2_hsmmc_info *c;
>
> omap2_hsmmc_init(controllers);
>
> for (c = controllers; c->mmc; c++)
> omap4_twl6030_hsmmc_set_late_init(c->dev);
> }
>
> And then the board file becomes:
>
> static struct omap2_hsmmc_info mmc[] = {
> {
> .mmc = 1,
> .wires = 8,
> .gpio_cd = -EINVAL,
> .gpio_wp = -EINVAL,
> },
> {
> .mmc = 2,
> .wires = 8,
> .gpio_cd = -EINVAL,
> .gpio_wp = -EINVAL,
> .nonremovable = true,
> },
> {} /* Terminator */
> };
>
> static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
> {
> .supply = "vmmc",
> .dev_name = "mmci-omap-hs.0",
> },
> {
> .supply = "vmmc",
> .dev_name = "mmci-omap-hs.1",
> },
> };
>
> static int __init sdp4430_mmc_init(void)
> {
> omap4_twl6030_hsmmc_init(mmc);
> return 0;
> }
>
Thanks Adrian !
Agree and will move changes to board-4430 file
--
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 v2 1/5] OMAP4-HSMMC: Adding HSMMC support for OMAP4430 Board file
<>
>
> Can do this instead I think:
>
> static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
> {
> .supply = "vmmc",
> .dev_name = "mmci-omap-hs.0",
> },
> {
> .supply = "vmmc",
> .dev_name = "mmci-omap-hs.1",
> },
> };
>
Agree , will make changes in next version
--
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 00/18] omap platform data and board updates for 2.6.35 merge window
* Tomi Valkeinen [100506 00:38]: > On Wed, 2010-05-05 at 23:09 +0200, ext Tony Lindgren wrote: > > * Koen Kooi [100505 13:16]: > > > Tony, > > > > > > Any chance of https://patchwork.kernel.org/patch/94049/ going in as well? > > > Tomi has acked it already. > > > > That one looks good to me, but I thought Tomi is going to > > queue all the DSS board-*.c patches somewhere. > > I thought we agreed that board file changes go through linux-omap after > I've acked them, to reduce the possibility of conflicts. > > But yes, I can add it to my tree. I'll send it back to you if we start > to get conflicts =). Great. It's best that Tomi queues the DSS board file changes. BTW, I have not picked or marked any of the DSS board file changes in patchwork, I think there are several of them sitting there. Tomi, if something conflicts, you can do a git branch for me to pull for the DSS board file changes. Note that the arch/arm/*omap*/ DSS changes still need to be posted to also linux-arm-kernel for review before they can be merged. 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] Disable the non working eMMC on Zoom2/3
* Madhusudhan [100505 18:31]: > > > > -Original Message- > > From: Tony Lindgren [mailto:t...@atomide.com] > > > And what about this "Simulate multi mmc card as one big" patch? > > > Did not get you, what patch are you referring to? Oops sorry forgot the link: https://patchwork.kernel.org/patch/87944/ 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: Possible bug in onenand_base ?
Hi,
2010/5/6 Kyungmin Park :
> Hi,
>
> What's your chip version? maybe some mis-probe it seems to be probed
> at 4KiB pagesize OneNAND.
Is a 4-Gbit DDP OneNAND device from Numonyx composed of two 2-Gbit 2KB
page dice stacked together, the device is equipped with two DataRAMs,
and two-plane NAND Flash memory array,
These two component enables simultaneous program of 4KiB (
CONFIG_MTD_ONENAND_2X_PROGRAM)
Cheers,
Enric
>
> Thank you,
> Kyungmin Park
>
> On Thu, May 6, 2010 at 8:22 PM, Enric Balletbò i Serra
> wrote:
>> Hi,
>>
>> 2010/5/6 Kyungmin Park :
>>> Hi,
>>>
>>> Can you add this statement at below the code?
>>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__, page, (int)
>>> onenand_addr(this, block), ((int) addr >> this->page_shift) &
>>> this->page_mask);
>>
>> Yes,
>>
>> With this code nandtest fails:
>>
>> onenand_base.c
>>
>> 377: default:
>> block = onenand_block(this, addr);
>> /* (line disabled) page = (int) (addr >> this->page_shift); */
>> page = (int) (addr - onenand_addr(this, block)) >>
>> this->page_shift;
>>
>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
>> page, (int)
>> onenand_addr(this, block), ((int) addr >>
>> this->page_shift) &
>> this->page_mask);
>>
>> if (ONENAND_IS_2PLANE(this)) {
>> /* Make the even block number */
>> block &= ~1;
>> /* Is it the odd plane? */
>> if (addr & this->writesize)
>> block++;
>> page >>= 1;
>> }
>> page &= this->page_mask;
>> break;
>>
>>
>> --- start log nandtest fail ---
>> # nandtest -l 262144 /dev/mtd3
>> ECC corrections: 0
>> ECC failures : 0
>> Bad blocks : 0
>> BBT blocks : 0
>> : writing...
>> [ 243.144287] onenand_command[382] page 0, 2621440, 0
>> [ 243.150787] onenand_command[382] page 2, 2621440, 2
>> [ 243.156158] onenand_command[382] page 4, 2621440, 4
>> (...)
>> [ 243.310729] onenand_command[382] page 60, 2621440, 60
>> [ 243.316223] onenand_command[382] page 62, 2621440, 62
>> [ 243.322204] onenand_command[382] page 0, 2752512, 0
>> [ 243.327636] onenand_command[382] page 2, 2752512, 2
>> [ 243.332977] onenand_command[382] page 4, 2752512, 4
>> (...)
>> [ 243.487487] onenand_command[382] page 60, 2752512, 60
>> [ 243.493041] onenand_command[382] page 62, 2752512, 62
>> : reading...
>> [ 243.498535] onenand_command[382] page 0, 2621440, 0
>> [ 243.505249] onenand_wait: ECC error = 0x8488
>> [ 243.509552] onenand_command[382] page 1, 2621440, 1
>> [ 243.514587] onenand_wait: ECC error = 0x8488
>> [ 243.518890] onenand_command[382] page 2, 2621440, 2
>> (...)
>> [ 244.089050] onenand_command[382] page 62, 2621440, 62
>> [ 244.094268] onenand_wait: ECC error = 0x8448
>> [ 244.098602] onenand_command[382] page 63, 2621440, 63
>> [ 244.103790] onenand_wait: ECC error = 0x8488
>> [ 244.109191] onenand_command[382] page 0, 2752512, 0
>> [ 244.114196] onenand_wait: ECC error = 0x8488
>> [ 244.118469] onenand_command[382] page 1, 2752512, 1
>> [ 244.123535] onenand_wait: ECC error = 0x8488
>> [ 244.127838] onenand_command[382] page 2, 2752512, 2
>> (...)
>> [ 244.698150] onenand_command[382] page 62, 2752512, 62
>> [ 244.703369] onenand_wait: ECC error = 0x8448
>> [ 244.707672] onenand_command[382] page 63, 2752512, 63
>> [ 244.712890] onenand_wait: ECC error = 0x8488
>>
>> ECC failed at
>> : checking...
>> compare failed. seed 1804289383
>> Byte 0x1 is 5a should be da
>> Byte 0x3 is 82 should be 92
>> Byte 0x4 is 10 should be 1a
>> Byte 0x5 is 21 should be b7
>>
>> --- end log nandtest fail ---
>>
>>
>> With this other code nandtest pass
>>
>> onenand_base.c
>>
>> 377: default:
>> block = onenand_block(this, addr);
>> page = (int) (addr >> this->page_shift);
>> /* (line disabled) page = (int) (addr - onenand_addr(this, block)) >>
>> this->page_shift; */
>>
>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
>> page, (int)
>> onenand_addr(this, block), ((int) addr >>
>> this->page_shift) &
>> this->page_mask);
>>
>> if (ONENAND_IS_2PLANE(this)) {
>> /* Make the even block number */
>> block &= ~1;
>> /* Is it the odd plane? */
>> if (addr & this->writesize)
>> block++;
>> page >>= 1;
>> }
>> page &= this->page_mask;
>> break;
>>
>> --- start log nandtest pass ---
>> # nandtest -l 262144 /dev/mtd3
>> ECC corrections: 0
>> ECC failures : 33
>> Bad blocks : 0
>> BBT blocks : 0
>> : writing...
>> [ 2024.624664] onenand_command[382]
[PATCH 2/2] OMAP: DSS2: Fix omap_dss_probe() error path
From: Jani Nikula
Perform graceful cleanup on errors instead of just bailing out.
Signed-off-by: Jani Nikula
---
drivers/video/omap2/dss/core.c | 54 ++-
1 files changed, 41 insertions(+), 13 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 92ee067..b3a498f 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -507,7 +507,7 @@ static int omap_dss_probe(struct platform_device *pdev)
r = dss_get_clocks();
if (r)
- goto fail0;
+ goto err_clocks;
dss_clk_enable_all_no_ctx();
@@ -523,57 +523,64 @@ static int omap_dss_probe(struct platform_device *pdev)
r = dss_init(skip_init);
if (r) {
DSSERR("Failed to initialize DSS\n");
- goto fail0;
+ goto err_dss;
}
r = rfbi_init();
if (r) {
DSSERR("Failed to initialize rfbi\n");
- goto fail0;
+ goto err_rfbi;
}
r = dpi_init(pdev);
if (r) {
DSSERR("Failed to initialize dpi\n");
- goto fail0;
+ goto err_dpi;
}
r = dispc_init();
if (r) {
DSSERR("Failed to initialize dispc\n");
- goto fail0;
+ goto err_dispc;
}
r = venc_init(pdev);
if (r) {
DSSERR("Failed to initialize venc\n");
- goto fail0;
+ goto err_venc;
}
if (cpu_is_omap34xx()) {
r = sdi_init(skip_init);
if (r) {
DSSERR("Failed to initialize SDI\n");
- goto fail0;
+ goto err_sdi;
}
r = dsi_init(pdev);
if (r) {
DSSERR("Failed to initialize DSI\n");
- goto fail0;
+ goto err_dsi;
}
}
r = dss_initialize_debugfs();
if (r)
- goto fail0;
+ goto err_debugfs;
for (i = 0; i < pdata->num_devices; ++i) {
struct omap_dss_device *dssdev = pdata->devices[i];
r = omap_dss_register_device(dssdev);
- if (r)
- DSSERR("device reg failed %d\n", i);
+ if (r) {
+ DSSERR("device %d %s register failed %d\n", i,
+ dssdev->name ?: "unnamed", r);
+
+ while (--i >= 0)
+ omap_dss_unregister_device(pdata->devices[i]);
+
+ goto err_register;
+ }
if (def_disp_name && strcmp(def_disp_name, dssdev->name) == 0)
pdata->default_device = dssdev;
@@ -583,8 +590,29 @@ static int omap_dss_probe(struct platform_device *pdev)
return 0;
- /* XXX fail correctly */
-fail0:
+err_register:
+ dss_uninitialize_debugfs();
+err_debugfs:
+ if (cpu_is_omap34xx())
+ dsi_exit();
+err_dsi:
+ if (cpu_is_omap34xx())
+ sdi_exit();
+err_sdi:
+ venc_exit();
+err_venc:
+ dispc_exit();
+err_dispc:
+ dpi_exit();
+err_dpi:
+ rfbi_exit();
+err_rfbi:
+ dss_exit();
+err_dss:
+ dss_clk_disable_all_no_ctx();
+ dss_put_clocks();
+err_clocks:
+
return r;
}
--
1.6.5.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
[PATCH 1/2] OMAP: DSS2: omap_dss_probe() conditional compilation cleanup
From: Jani Nikula
Move a number of #ifdefs from code into dss.h and elsewhere, and
conditionally define no-op static inline functions, cleaning up the
code. This style is according to Documentation/SubmittingPatches.
Signed-off-by: Jani Nikula
---
drivers/video/omap2/dss/core.c | 31 +++
drivers/video/omap2/dss/dss.h | 40
2 files changed, 51 insertions(+), 20 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 7ebe50b..92ee067 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -482,6 +482,14 @@ static void dss_uninitialize_debugfs(void)
if (dss_debugfs_dir)
debugfs_remove_recursive(dss_debugfs_dir);
}
+#else /* CONFIG_DEBUG_FS && CONFIG_OMAP2_DSS_DEBUG_SUPPORT */
+static inline int dss_initialize_debugfs(void)
+{
+ return 0;
+}
+static inline void dss_uninitialize_debugfs(void)
+{
+}
#endif /* CONFIG_DEBUG_FS && CONFIG_OMAP2_DSS_DEBUG_SUPPORT */
/* PLATFORM DEVICE */
@@ -518,13 +526,11 @@ static int omap_dss_probe(struct platform_device *pdev)
goto fail0;
}
-#ifdef CONFIG_OMAP2_DSS_RFBI
r = rfbi_init();
if (r) {
DSSERR("Failed to initialize rfbi\n");
goto fail0;
}
-#endif
r = dpi_init(pdev);
if (r) {
@@ -537,35 +543,30 @@ static int omap_dss_probe(struct platform_device *pdev)
DSSERR("Failed to initialize dispc\n");
goto fail0;
}
-#ifdef CONFIG_OMAP2_DSS_VENC
+
r = venc_init(pdev);
if (r) {
DSSERR("Failed to initialize venc\n");
goto fail0;
}
-#endif
+
if (cpu_is_omap34xx()) {
-#ifdef CONFIG_OMAP2_DSS_SDI
r = sdi_init(skip_init);
if (r) {
DSSERR("Failed to initialize SDI\n");
goto fail0;
}
-#endif
-#ifdef CONFIG_OMAP2_DSS_DSI
+
r = dsi_init(pdev);
if (r) {
DSSERR("Failed to initialize DSI\n");
goto fail0;
}
-#endif
}
-#if defined(CONFIG_DEBUG_FS) && defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT)
r = dss_initialize_debugfs();
if (r)
goto fail0;
-#endif
for (i = 0; i < pdata->num_devices; ++i) {
struct omap_dss_device *dssdev = pdata->devices[i];
@@ -593,25 +594,15 @@ static int omap_dss_remove(struct platform_device *pdev)
int i;
int c;
-#if defined(CONFIG_DEBUG_FS) && defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT)
dss_uninitialize_debugfs();
-#endif
-#ifdef CONFIG_OMAP2_DSS_VENC
venc_exit();
-#endif
dispc_exit();
dpi_exit();
-#ifdef CONFIG_OMAP2_DSS_RFBI
rfbi_exit();
-#endif
if (cpu_is_omap34xx()) {
-#ifdef CONFIG_OMAP2_DSS_DSI
dsi_exit();
-#endif
-#ifdef CONFIG_OMAP2_DSS_SDI
sdi_exit();
-#endif
}
dss_exit();
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 24326a5..65f95ee 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -242,11 +242,22 @@ int dss_calc_clock_div(bool is_tft, unsigned long req_pck,
struct dispc_clock_info *dispc_cinfo);
/* SDI */
+#ifdef CONFIG_OMAP2_DSS_SDI
int sdi_init(bool skip_init);
void sdi_exit(void);
int sdi_init_display(struct omap_dss_device *display);
+#else
+static inline int sdi_init(bool skip_init)
+{
+ return 0;
+}
+static inline void sdi_exit(void)
+{
+}
+#endif
/* DSI */
+#ifdef CONFIG_OMAP2_DSS_DSI
int dsi_init(struct platform_device *pdev);
void dsi_exit(void);
@@ -270,6 +281,15 @@ void dsi_pll_uninit(void);
void dsi_get_overlay_fifo_thresholds(enum omap_plane plane,
u32 fifo_size, enum omap_burst_size *burst_size,
u32 *fifo_low, u32 *fifo_high);
+#else
+static inline int dsi_init(struct platform_device *pdev)
+{
+ return 0;
+}
+static inline void dsi_exit(void)
+{
+}
+#endif
/* DPI */
int dpi_init(struct platform_device *pdev);
@@ -362,12 +382,23 @@ int dispc_get_clock_div(struct dispc_clock_info *cinfo);
/* VENC */
+#ifdef CONFIG_OMAP2_DSS_VENC
int venc_init(struct platform_device *pdev);
void venc_exit(void);
void venc_dump_regs(struct seq_file *s);
int venc_init_display(struct omap_dss_device *display);
+#else
+static inline int venc_init(struct platform_device *pdev)
+{
+ return 0;
+}
+static inline void venc_exit(void)
+{
+}
+#endif
/* RFBI */
+#ifdef CONFIG_OMAP2_DSS_RFBI
int rfbi_init(void);
void rfbi_exit(void);
void rfbi_dump_regs(struct seq_file *s);
@@ -379,6 +410,15 @@ void rfbi_transfer_area(u16 width, u16 height,
void rfbi_set_timings(int rfbi_module, struct rfbi_timings *t);
unsigned long rfbi_get_max_tx_rate(void);
int rfbi_init_display(struct
[PATCH 0/2] OMAP: DSS2: Fix DSS core init fail path
Hi - These patches fix the broken DSS omap_dss_probe() fail path, reported by Kevin Hilman [1]. Kevin, could you please check this with your setup too? It would be much appreciated. [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg27112.html BR, Jani. Jani Nikula (2): OMAP: DSS2: omap_dss_probe() conditional compilation cleanup OMAP: DSS2: Fix omap_dss_probe() error path drivers/video/omap2/dss/core.c | 85 --- drivers/video/omap2/dss/dss.h | 40 +++ 2 files changed, 92 insertions(+), 33 deletions(-) -- 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: Possible bug in onenand_base ?
Hi,
What's your chip version? maybe some mis-probe it seems to be probed
at 4KiB pagesize OneNAND.
Thank you,
Kyungmin Park
On Thu, May 6, 2010 at 8:22 PM, Enric Balletbò i Serra
wrote:
> Hi,
>
> 2010/5/6 Kyungmin Park :
>> Hi,
>>
>> Can you add this statement at below the code?
>> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__, page, (int)
>> onenand_addr(this, block), ((int) addr >> this->page_shift) &
>> this->page_mask);
>
> Yes,
>
> With this code nandtest fails:
>
> onenand_base.c
>
> 377: default:
> block = onenand_block(this, addr);
> /* (line disabled) page = (int) (addr >> this->page_shift); */
> page = (int) (addr - onenand_addr(this, block)) >>
> this->page_shift;
>
> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
> page, (int)
> onenand_addr(this, block), ((int) addr >>
> this->page_shift) &
> this->page_mask);
>
> if (ONENAND_IS_2PLANE(this)) {
> /* Make the even block number */
> block &= ~1;
> /* Is it the odd plane? */
> if (addr & this->writesize)
> block++;
> page >>= 1;
> }
> page &= this->page_mask;
> break;
>
>
> --- start log nandtest fail ---
> # nandtest -l 262144 /dev/mtd3
> ECC corrections: 0
> ECC failures : 0
> Bad blocks : 0
> BBT blocks : 0
> : writing...
> [ 243.144287] onenand_command[382] page 0, 2621440, 0
> [ 243.150787] onenand_command[382] page 2, 2621440, 2
> [ 243.156158] onenand_command[382] page 4, 2621440, 4
> (...)
> [ 243.310729] onenand_command[382] page 60, 2621440, 60
> [ 243.316223] onenand_command[382] page 62, 2621440, 62
> [ 243.322204] onenand_command[382] page 0, 2752512, 0
> [ 243.327636] onenand_command[382] page 2, 2752512, 2
> [ 243.332977] onenand_command[382] page 4, 2752512, 4
> (...)
> [ 243.487487] onenand_command[382] page 60, 2752512, 60
> [ 243.493041] onenand_command[382] page 62, 2752512, 62
> : reading...
> [ 243.498535] onenand_command[382] page 0, 2621440, 0
> [ 243.505249] onenand_wait: ECC error = 0x8488
> [ 243.509552] onenand_command[382] page 1, 2621440, 1
> [ 243.514587] onenand_wait: ECC error = 0x8488
> [ 243.518890] onenand_command[382] page 2, 2621440, 2
> (...)
> [ 244.089050] onenand_command[382] page 62, 2621440, 62
> [ 244.094268] onenand_wait: ECC error = 0x8448
> [ 244.098602] onenand_command[382] page 63, 2621440, 63
> [ 244.103790] onenand_wait: ECC error = 0x8488
> [ 244.109191] onenand_command[382] page 0, 2752512, 0
> [ 244.114196] onenand_wait: ECC error = 0x8488
> [ 244.118469] onenand_command[382] page 1, 2752512, 1
> [ 244.123535] onenand_wait: ECC error = 0x8488
> [ 244.127838] onenand_command[382] page 2, 2752512, 2
> (...)
> [ 244.698150] onenand_command[382] page 62, 2752512, 62
> [ 244.703369] onenand_wait: ECC error = 0x8448
> [ 244.707672] onenand_command[382] page 63, 2752512, 63
> [ 244.712890] onenand_wait: ECC error = 0x8488
>
> ECC failed at
> : checking...
> compare failed. seed 1804289383
> Byte 0x1 is 5a should be da
> Byte 0x3 is 82 should be 92
> Byte 0x4 is 10 should be 1a
> Byte 0x5 is 21 should be b7
>
> --- end log nandtest fail ---
>
>
> With this other code nandtest pass
>
> onenand_base.c
>
> 377: default:
> block = onenand_block(this, addr);
> page = (int) (addr >> this->page_shift);
> /* (line disabled) page = (int) (addr - onenand_addr(this, block)) >>
> this->page_shift; */
>
> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
> page, (int)
> onenand_addr(this, block), ((int) addr >>
> this->page_shift) &
> this->page_mask);
>
> if (ONENAND_IS_2PLANE(this)) {
> /* Make the even block number */
> block &= ~1;
> /* Is it the odd plane? */
> if (addr & this->writesize)
> block++;
> page >>= 1;
> }
> page &= this->page_mask;
> break;
>
> --- start log nandtest pass ---
> # nandtest -l 262144 /dev/mtd3
> ECC corrections: 0
> ECC failures : 33
> Bad blocks : 0
> BBT blocks : 0
> : writing...
> [ 2024.624664] onenand_command[382] page 1280, 2621440, 0
> [ 2024.631530] onenand_command[382] page 1282, 2621440, 2
> [ 2024.637145] onenand_command[382] page 1284, 2621440, 4
> (...)
> [ 2024.796813] onenand_command[382] page 1340, 2621440, 60
> [ 2024.802520] onenand_command[382] page 1342, 2621440, 62
> [ 2024.808593] onenand_command[382] page 1344, 2752512, 0
> [ 2024.814239] onenand_command[382] page 1346, 2752512, 2
> (...)
> [ 2024.979644] onenand_command[382] page 1404, 2752512, 60
>
Re: Possible bug in onenand_base ?
Hi,
2010/5/6 Kyungmin Park :
> Hi,
>
> Can you add this statement at below the code?
> printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__, page, (int)
> onenand_addr(this, block), ((int) addr >> this->page_shift) &
> this->page_mask);
Yes,
With this code nandtest fails:
onenand_base.c
377: default:
block = onenand_block(this, addr);
/* (line disabled) page = (int) (addr >> this->page_shift); */
page = (int) (addr - onenand_addr(this, block)) >>
this->page_shift;
printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
page, (int)
onenand_addr(this, block), ((int) addr >>
this->page_shift) &
this->page_mask);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
block &= ~1;
/* Is it the odd plane? */
if (addr & this->writesize)
block++;
page >>= 1;
}
page &= this->page_mask;
break;
--- start log nandtest fail ---
# nandtest -l 262144 /dev/mtd3
ECC corrections: 0
ECC failures : 0
Bad blocks : 0
BBT blocks : 0
: writing...
[ 243.144287] onenand_command[382] page 0, 2621440, 0
[ 243.150787] onenand_command[382] page 2, 2621440, 2
[ 243.156158] onenand_command[382] page 4, 2621440, 4
(...)
[ 243.310729] onenand_command[382] page 60, 2621440, 60
[ 243.316223] onenand_command[382] page 62, 2621440, 62
[ 243.322204] onenand_command[382] page 0, 2752512, 0
[ 243.327636] onenand_command[382] page 2, 2752512, 2
[ 243.332977] onenand_command[382] page 4, 2752512, 4
(...)
[ 243.487487] onenand_command[382] page 60, 2752512, 60
[ 243.493041] onenand_command[382] page 62, 2752512, 62
: reading...
[ 243.498535] onenand_command[382] page 0, 2621440, 0
[ 243.505249] onenand_wait: ECC error = 0x8488
[ 243.509552] onenand_command[382] page 1, 2621440, 1
[ 243.514587] onenand_wait: ECC error = 0x8488
[ 243.518890] onenand_command[382] page 2, 2621440, 2
(...)
[ 244.089050] onenand_command[382] page 62, 2621440, 62
[ 244.094268] onenand_wait: ECC error = 0x8448
[ 244.098602] onenand_command[382] page 63, 2621440, 63
[ 244.103790] onenand_wait: ECC error = 0x8488
[ 244.109191] onenand_command[382] page 0, 2752512, 0
[ 244.114196] onenand_wait: ECC error = 0x8488
[ 244.118469] onenand_command[382] page 1, 2752512, 1
[ 244.123535] onenand_wait: ECC error = 0x8488
[ 244.127838] onenand_command[382] page 2, 2752512, 2
(...)
[ 244.698150] onenand_command[382] page 62, 2752512, 62
[ 244.703369] onenand_wait: ECC error = 0x8448
[ 244.707672] onenand_command[382] page 63, 2752512, 63
[ 244.712890] onenand_wait: ECC error = 0x8488
ECC failed at
: checking...
compare failed. seed 1804289383
Byte 0x1 is 5a should be da
Byte 0x3 is 82 should be 92
Byte 0x4 is 10 should be 1a
Byte 0x5 is 21 should be b7
--- end log nandtest fail ---
With this other code nandtest pass
onenand_base.c
377: default:
block = onenand_block(this, addr);
page = (int) (addr >> this->page_shift);
/* (line disabled) page = (int) (addr - onenand_addr(this, block)) >>
this->page_shift; */
printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__,
page, (int)
onenand_addr(this, block), ((int) addr >>
this->page_shift) &
this->page_mask);
if (ONENAND_IS_2PLANE(this)) {
/* Make the even block number */
block &= ~1;
/* Is it the odd plane? */
if (addr & this->writesize)
block++;
page >>= 1;
}
page &= this->page_mask;
break;
--- start log nandtest pass ---
# nandtest -l 262144 /dev/mtd3
ECC corrections: 0
ECC failures : 33
Bad blocks : 0
BBT blocks : 0
: writing...
[ 2024.624664] onenand_command[382] page 1280, 2621440, 0
[ 2024.631530] onenand_command[382] page 1282, 2621440, 2
[ 2024.637145] onenand_command[382] page 1284, 2621440, 4
(...)
[ 2024.796813] onenand_command[382] page 1340, 2621440, 60
[ 2024.802520] onenand_command[382] page 1342, 2621440, 62
[ 2024.808593] onenand_command[382] page 1344, 2752512, 0
[ 2024.814239] onenand_command[382] page 1346, 2752512, 2
(...)
[ 2024.979644] onenand_command[382] page 1404, 2752512, 60
[ 2024.985351] onenand_command[382] page 1406, 2752512, 62
: reading...
[ 2024.990997] onenand_command[382] page 1280, 2621440, 0
[ 2024.997985] onenand_command[382] page 1281, 2621440, 1
[ 2025.003295] onenand_command[382] page 1282, 2621440, 2
(...)
[ 2025.326782] onenand_command[382] page 1342, 2621440, 62
[ 2025.332214] onenand_command[382] page 1343, 2621440, 63
[ 2025.338592] onenand_command[
[PATCH] OMAP3: GPIO: Replace CONFIG_ARCH_OMAP34XX with CONFIG_ARCH_OMAP3
CONFIG_ARCH_OMAP34XX is not defined any more. Replace it with
CONFIG_ARCH_OMAP3.
Signed-off-by: Ranjith Lohithakshan
---
This patch is generated against pm branch.
arch/arm/plat-omap/gpio.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 7b2178c..0c84aae 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -2095,7 +2095,7 @@ static int omap_gpio_suspend(struct sys_device *dev,
pm_message_t mesg)
__raw_writel(bank->suspend_wakeup, wake_set);
spin_unlock_irqrestore(&bank->lock, flags);
-#ifdef CONFIG_ARCH_OMAP34XX
+#ifdef CONFIG_ARCH_OMAP3
if (bank->method == METHOD_GPIO_24XX) {
int j;
for (j = 0; j < 32; j++) {
--
1.6.2.4
--
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: [PM][PATCH v3 2/4] OMAP3: Serial: Errata i202: fix for MDR1 access
On Thu, May 6, 2010 at 4:14 PM, Nishanth Menon wrote: > Govindraj had written, on 05/06/2010 04:54 AM, the following: >> >> On Thu, May 6, 2010 at 5:49 AM, Kattungal, Deepak wrote: >>> >>> Hi Kevin, >>> >>> My Comments as below. >>> >>> Regards >>> Deepak >>> >>> -Original Message- >>> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >>> Sent: Wednesday, May 05, 2010 6:55 PM >>> To: Menon, Nishanth >>> Cc: linux-omap; Kattungal, Deepak; Raja, Govindraj; Tero Kristo >>> Subject: Re: [PM][PATCH v3 2/4] OMAP3: Serial: Errata i202: fix for MDR1 >>> access >>> >>> Nishanth Menon writes: >>> From: Deepak K Original patch: http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=42d4a342c009bd9727c100abc8a4bc3063c22f0c Errata i202 (OMAP3430 - 1.12, OMAP3630 - 1.6): >>> >>> This workaround is currently done for all OMAPs. >>> >>> Presumably, this errata will eventually be fixed. So, as with other >>> errata fixes, we need some sort of SoC-rev based flag and the errata >>> workaround done based on that flag. >>> >>> Deepak : This would be a good fix, thanks for the suggestion. >>> >>> Also, shouldn't there be a fix for this in the 8250 and omap-serial >>> drivers too? >>> >>> >>> Deepak : The 8250 is not using the MDR Register. This would be needed >>> only by the omap-serial. The 8250 being a general driver we may not require >>> the access to MDR1 register. Hence the fix not required for 8250. >>> >> >> Why do you say this fix is not necessary for 8250? > > drivers/serial/8250.c does not use mdr register. it does not make sense for > a generic driver like this to have OMAP specific register access. > >> >> Isn't the omap_uart_reset configuring uart for 16x mode? >> >> Context save and restore is an common for whether it is 8250 or >> omap-serial.c > > ack. > >> >> The only difference here wrt to MDR and 8250 is >> -> MDR though not accesed by 8250 currently serial.c sets it to uart16x >> mode. > >> >> In omap-serial.c we configure MDR based on baudrate as we have an uart13x >> mode >> which is ignored in 8250 and thus 8250 may not support 13x baud's >> correctly >> which is taken care in omap-serial. > > given that MDR register deals with mostly IRDA settings, i am curious to see > how omap-serial hits on a shared register here :). MDR is not for only IrDA, MDR ---> Mode Definition register There are two MDR register: MDR1 [2:0] MODE_SELECT: UART-IrDA-CIR mode selection MDR2 ---> IR-IrDA and IR-CIR modes only > >> >> I think this patch is fine and only concern is to make it applicable >> to appropriate socs as kevin said. > > Sure. trivial to do. Could you comment on the proposal i posted earlier? As said in previous mail I have no issue with the function added. Except if taken care to handle the comment from kevin. -- --- Regards, Govindraj.R -- 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: [PM][PATCH v3 2/4] OMAP3: Serial: Errata i202: fix for MDR1 access
Govindraj had written, on 05/06/2010 04:54 AM, the following: On Thu, May 6, 2010 at 5:49 AM, Kattungal, Deepak wrote: Hi Kevin, My Comments as below. Regards Deepak -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, May 05, 2010 6:55 PM To: Menon, Nishanth Cc: linux-omap; Kattungal, Deepak; Raja, Govindraj; Tero Kristo Subject: Re: [PM][PATCH v3 2/4] OMAP3: Serial: Errata i202: fix for MDR1 access Nishanth Menon writes: From: Deepak K Original patch: http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=42d4a342c009bd9727c100abc8a4bc3063c22f0c Errata i202 (OMAP3430 - 1.12, OMAP3630 - 1.6): This workaround is currently done for all OMAPs. Presumably, this errata will eventually be fixed. So, as with other errata fixes, we need some sort of SoC-rev based flag and the errata workaround done based on that flag. Deepak : This would be a good fix, thanks for the suggestion. Also, shouldn't there be a fix for this in the 8250 and omap-serial drivers too? Deepak : The 8250 is not using the MDR Register. This would be needed only by the omap-serial. The 8250 being a general driver we may not require the access to MDR1 register. Hence the fix not required for 8250. Why do you say this fix is not necessary for 8250? drivers/serial/8250.c does not use mdr register. it does not make sense for a generic driver like this to have OMAP specific register access. Isn't the omap_uart_reset configuring uart for 16x mode? Context save and restore is an common for whether it is 8250 or omap-serial.c ack. The only difference here wrt to MDR and 8250 is -> MDR though not accesed by 8250 currently serial.c sets it to uart16x mode. In omap-serial.c we configure MDR based on baudrate as we have an uart13x mode which is ignored in 8250 and thus 8250 may not support 13x baud's correctly which is taken care in omap-serial. given that MDR register deals with mostly IRDA settings, i am curious to see how omap-serial hits on a shared register here :). I think this patch is fine and only concern is to make it applicable to appropriate socs as kevin said. Sure. trivial to do. Could you comment on the proposal i posted earlier? -- Regards, Nishanth Menon -- 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: [PM][PATCH v3 2/4] OMAP3: Serial: Errata i202: fix for MDR1 access
On Thu, May 6, 2010 at 5:49 AM, Kattungal, Deepak wrote: > Hi Kevin, > > My Comments as below. > > Regards > Deepak > > -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Wednesday, May 05, 2010 6:55 PM > To: Menon, Nishanth > Cc: linux-omap; Kattungal, Deepak; Raja, Govindraj; Tero Kristo > Subject: Re: [PM][PATCH v3 2/4] OMAP3: Serial: Errata i202: fix for MDR1 > access > > Nishanth Menon writes: > >> From: Deepak K >> >> Original patch: >> http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=42d4a342c009bd9727c100abc8a4bc3063c22f0c >> >> Errata i202 (OMAP3430 - 1.12, OMAP3630 - 1.6): > > This workaround is currently done for all OMAPs. > > Presumably, this errata will eventually be fixed. So, as with other > errata fixes, we need some sort of SoC-rev based flag and the errata > workaround done based on that flag. > > Deepak : This would be a good fix, thanks for the suggestion. > > Also, shouldn't there be a fix for this in the 8250 and omap-serial > drivers too? > > > Deepak : The 8250 is not using the MDR Register. This would be needed only by > the omap-serial. The 8250 being a general driver we may not require the > access to MDR1 register. Hence the fix not required for 8250. > Why do you say this fix is not necessary for 8250? Isn't the omap_uart_reset configuring uart for 16x mode? Context save and restore is an common for whether it is 8250 or omap-serial.c The only difference here wrt to MDR and 8250 is -> MDR though not accesed by 8250 currently serial.c sets it to uart16x mode. In omap-serial.c we configure MDR based on baudrate as we have an uart13x mode which is ignored in 8250 and thus 8250 may not support 13x baud's correctly which is taken care in omap-serial. I think this patch is fine and only concern is to make it applicable to appropriate socs as kevin said. --- Regards, Govindraj.R -- 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] board-omap3-beagle: add DSS2 support
Op 2 mei 2010, om 17:58 heeft Felipe Contreras het volgende geschreven: > > I also have these changes in one of my trees backported from Tomi > Valkeinen's tree. I'm attaching the diff; some of these are cosmetic, > but I think the gpio changes make sense, although I don't know if > omap_mux_init_gpio is really needed. > > I think the current proposed patch should go in already, I don't know > what we are waiting for. > > --- a/arch/arm/mach-omap2/board-omap3beagle.c > +++ b/arch/arm/mach-omap2/board-omap3beagle.c > > +#if 0 > + /* is this really needed? */ > + omap_mux_init_gpio(beagle_dvi_device.reset_gpio, OMAP_PIN_INPUT); > +#endif > r = gpio_request(beagle_dvi_device.reset_gpio, "DVI reset"); > > - omap_mux_init_gpio(170, OMAP_PIN_INPUT); > - gpio_request(170, "DVI_nPD"); > - /* REVISIT leave DVI powered down until it's needed ... */ > - gpio_direction_output(170, true); > - I have a similar change queued since the new beagle xM moves DVI reset to gpio129, but I'm holding off on sending beagle patches here till the hardware design is finalized. regards, Koen-- 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 v1 2/3] OMAP4: Ethernet: KS8851 Board Support
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of G,
> Manjunath Kondaiah
> Sent: Thursday, May 06, 2010 2:34 PM
> To: Arce, Abraham; Tony Lindgren
> Cc: linux-omap@vger.kernel.org; spi-devel-gene...@lists.sourceforge.net
> Subject: RE: [PATCH v1 2/3] OMAP4: Ethernet: KS8851 Board Support
>
>
>
> > -Original Message-
> > From: Arce, Abraham
> > Sent: Thursday, May 06, 2010 9:49 AM
> > To: G, Manjunath Kondaiah; Tony Lindgren
> > Cc: linux-omap@vger.kernel.org;
> > spi-devel-gene...@lists.sourceforge.net
> > Subject: RE: [PATCH v1 2/3] OMAP4: Ethernet: KS8851 Board Support
> >
> > Manjunath,
> >
> > > > > > > > > +
> > > > > > > > > +static void omap_ethernet_init(void)
> > > > > > > > > +{
> > > > > > > > > +
> > gpio_request(ETHERNET_KS8851_POWER_ENABLE, "ethernet");
> > > > > > > > > +
> > gpio_direction_output(ETHERNET_KS8851_POWER_ENABLE, 1);
> > > > > > > > > + gpio_request(ETHERNET_KS8851_QUART, "quart");
> > > > > > > > > + gpio_direction_output(ETHERNET_KS8851_QUART, 1);
> > > > > > > > > + gpio_request(ETHERNET_KS8851_IRQ, "ks8851");
> > > > > > > >
> > > > > > > > Any reason for not checking return value of
> > gpio_request()?
> > > > > > > >
> >
> > [snip]
> >
> > > Minor changes:
> > > if (gpio_request(x))
> > > return status;
> > > if (gpio_request(y))
> > > goto err1;
> > > if (gpio_request(z))
> > > goto err2;
> > > ...
> > > return 0;
> > >
> > > err2:
> > > free(y);
> > >
> > > err1:
> > > free(x);
> > > return status;
> >
> > How about this patch?
> >
> > Note. I am thinking in spi_register_board_info registration:
> >
> > 1. to be done if ethernet fails, other spi dev can be added in future
>
> No use. Since, for a given board SPI chip select lines are physically
> connected to external slave devices, you can't register another SPI
> slave device for same chip select.
Be careful here Manju. There are 4 channels per SPI controller
with 4 chip selects. You can add more devices on same controller
>
> > 2. not to be done if ethernet fails, no other dev in spi bus 1 for now
> >
> > What is the best approach? Is it to keep #2?
>
> Seems to be ok for chip select #0. If we have another device on bus 1 with
> different chip select number, then registration should succeed. However, this
> may not be the case with omap4 sdp board since it might have only one spi
> device on bus1.
There is a quad-uart on SPI but not being used though.
>
> -Manjunath--
> 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
--
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 v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature
> -Original Message- > From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com] > Sent: Thursday, May 06, 2010 2:32 PM > To: Shilimkar, Santosh > Cc: S, Venkatraman; linux-omap@vger.kernel.org; linux-...@vger.kernel.org; > linux-arm- > ker...@lists.arm.linux.org.uk; Chikkature Rajashekar, Madhusudhan; Adrian > Hunter; Kadiyala, Kishore; > Tony Lindgren > Subject: Re: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor > autoloading feature > > <> > > >> I am not clear about the method. The board files export the > >> omap_mmc_platform_data. > >> Does it imply that all board files have to change and export > >> the capability so that it can be queried ? > > No. You don't have to modify the board files. This would need > > change in devices.c which common for all omap boards. > > > > I don't have a strong opinion on this point but just put forth an > > alternate way to avoid such SOC specific check in drivers. > > You can take call on this > > Agree. How about adding a flag in hsmmc.h & omap_mmc_platform_data, > that would take care of SDMA & SDMA_DLAOD in the driver instead going > with SOC check . Good idea Kishore. Venkat, Can you do what kishore is suggesting. Regards, Santosh -- 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 v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature
> -Original Message- > From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of S, > Venkatraman > Sent: Thursday, May 06, 2010 2:27 PM > To: Shilimkar, Santosh > Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; Chikkature > Rajashekar, Madhusudhan; Adrian > Hunter; Kadiyala, Kishore; Tony Lindgren; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor > autoloading feature > > Shilimkar, Santosh wrote: > >> -Original Message- > >> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of > >> Venkatraman S > >> Sent: Wednesday, May 05, 2010 9:49 PM > >> To: Shilimkar, Santosh > >> Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; linux-arm- > ker...@lists.arm.linux.org.uk; > >> Chikkature Rajashekar, Madhusudhan; Adrian Hunter; Kadiyala, Kishore; Tony > >> Lindgren > >> Subject: Re: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor > >> autoloading feature > >> > >> [Long sections have been trimmed to the context of discussion] > >> Shilimkar, Santosh wrote: > >> > > >> >> -Original Message- > >> >> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of > >> >> Venkatraman S > >> >> Sent: Thursday, April 29, 2010 11:05 PM > >> >> To: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; linux-arm- > ker...@lists.arm.linux.org.uk > >> >> Cc: Chikkature Rajashekar, Madhusudhan; Adrian Hunter; Kadiyala, > >> >> Kishore; Shilimkar, Santosh; > Tony > >> >> Lindgren > >> >> Subject: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor > >> >> autoloading feature > >> >> > >> >> From 1c63dd42fc6c563c931168779ce73401332faa52 Mon Sep 17 00:00:00 2001 > >> >> From: Venkatraman S > >> >> Date: Thu, 29 Apr 2010 22:43:31 +0530 > >> >> Subject: [PATCH 2/2] omap hsmmc: adaptation of sdma descriptor > >> >> autoloading feature > >> >> > >> >> Start to use the sDMA descriptor autoloading feature. > >> >> For large datablocks, the MMC driver has to repeatedly setup, > >> >> program and teardown the dma channel for each element of the > >> >> sglist received in omap_hsmmc_request. > >> >> > >> >> By using descriptor autoloading, transfers from / to each element of > >> >> the sglist is pre programmed into a linked list. The sDMA driver > >> >> completes the entire transaction and provides a single interrupt. > >> >> > >> >> Due to this, number of dma interrupts for a typical 100MB transfer on > >> >> the MMC is > >> >> reduced from 25000 to about 400 (approximate). Transfer speeds are > >> >> improved by ~5%. > >> >> (Though it varies on the size of read / write & improves on huge > >> >> transfers) > >> >> > >> >> Descriptor autoloading is available only in 3630 and 4430 (as of now). > >> >> Hence normal DMA mode is also retained. > >> >> > >> >> Signed-off-by: Venkatraman S > >> >> CC: Adrian Hunter > >> >> CC: Madhusudhan C > >> >> CC: Shilimkar Santosh > >> >> CC: Tony Lindgren > >> >> --- > >> >> Changes since previous version > >> >> * Rebased to Adrian Hunter's interrupt syncronisation patch > >> >> https://patchwork.kernel.org/patch/94670/ > >> >> * Rename ICR name definition > >> >> drivers/mmc/host/omap_hsmmc.c | 148 > >> >> ++-- > >> >> 1 files changed, 125 insertions(+), 23 deletions(-) > >> >> > >> >> diff --git a/drivers/mmc/host/omap_hsmmc.c > >> >> b/drivers/mmc/host/omap_hsmmc.c > >> >> index 65093d4..095fd94 100644 > >> >> --- a/drivers/mmc/host/omap_hsmmc.c > >> >> +++ b/drivers/mmc/host/omap_hsmmc.c > >> >> @@ -102,6 +102,8 @@ > >> >> #define SRD (1 << 26) > >> >> #define SOFTRESET(1 << 1) > >> >> #define RESETDONE(1 << 0) > >> >> +/* End of superblock indicator for sglist transfers */ > >> >> +#define DMA_ICR_SGLIST_END 0x4D00 > >> >> > >> >> /* > >> >> * FIXME: Most likely all the data using these _DEVID defines should > >> >> come > >> >> @@ -118,6 +120,12 @@ > >> >> #define OMAP_MMC_MASTER_CLOCK9600 > >> >> #define DRIVER_NAME "mmci-omap-hs" > >> >> > >> >> +#define DMA_TYPE_NODMA 0 > >> > " DMA_TYPE_NODMA" doesn't make sense > >> >> +#define DMA_TYPE_SDMA1 > >> >> +#define DMA_TYPE_SDMA_DLOAD 2 > >> > > >> > How about ?? > >> > #define TRANSFER_NODMA 0 > >> > #define TRANSFER_SDMA_NORMAL1 > >> > #define TRANSFER_SDMA_DESCRIPTOR2 > >> > I think ADMA is also in pipeline, so it can become then > >> > #define TRANSFER_ADMA_DESCRIPTOR3 > >> > >> Yes I was planning to use 3 for ADMA, but the names don't > >> make a big difference. > >> > > Good. Name does makes the difference when somebody reads the code. > > " DMA_TYPE_NODMA" what you make out from this if somebody has no > > background of what patch is doing. > > How about DMA_TYPE_NONE ? > Better > > > >> >> + > >> >> +#define DMA_CTRL_BUF_SIZE(PAGE_SIZE * 3) > >> >> + > >> >> /* Timeouts for entering p
RE: [PATCH v1 2/3] OMAP4: Ethernet: KS8851 Board Support
> -Original Message-
> From: Arce, Abraham
> Sent: Thursday, May 06, 2010 9:49 AM
> To: G, Manjunath Kondaiah; Tony Lindgren
> Cc: linux-omap@vger.kernel.org;
> spi-devel-gene...@lists.sourceforge.net
> Subject: RE: [PATCH v1 2/3] OMAP4: Ethernet: KS8851 Board Support
>
> Manjunath,
>
> > > > > > > > +
> > > > > > > > +static void omap_ethernet_init(void)
> > > > > > > > +{
> > > > > > > > +
> gpio_request(ETHERNET_KS8851_POWER_ENABLE, "ethernet");
> > > > > > > > +
> gpio_direction_output(ETHERNET_KS8851_POWER_ENABLE, 1);
> > > > > > > > + gpio_request(ETHERNET_KS8851_QUART, "quart");
> > > > > > > > + gpio_direction_output(ETHERNET_KS8851_QUART, 1);
> > > > > > > > + gpio_request(ETHERNET_KS8851_IRQ, "ks8851");
> > > > > > >
> > > > > > > Any reason for not checking return value of
> gpio_request()?
> > > > > > >
>
> [snip]
>
> > Minor changes:
> > if (gpio_request(x))
> > return status;
> > if (gpio_request(y))
> > goto err1;
> > if (gpio_request(z))
> > goto err2;
> > ...
> > return 0;
> >
> > err2:
> > free(y);
> >
> > err1:
> > free(x);
> > return status;
>
> How about this patch?
>
> Note. I am thinking in spi_register_board_info registration:
>
> 1. to be done if ethernet fails, other spi dev can be added in future
No use. Since, for a given board SPI chip select lines are physically
connected to external slave devices, you can't register another SPI
slave device for same chip select.
> 2. not to be done if ethernet fails, no other dev in spi bus 1 for now
>
> What is the best approach? Is it to keep #2?
Seems to be ok for chip select #0. If we have another device on bus 1 with
different chip select number, then registration should succeed. However, this
may not be the case with omap4 sdp board since it might have only one spi
device on bus1.
-Manjunath--
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 v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature
<> >> I am not clear about the method. The board files export the >> omap_mmc_platform_data. >> Does it imply that all board files have to change and export >> the capability so that it can be queried ? > No. You don't have to modify the board files. This would need > change in devices.c which common for all omap boards. > > I don't have a strong opinion on this point but just put forth an > alternate way to avoid such SOC specific check in drivers. > You can take call on this Agree. How about adding a flag in hsmmc.h & omap_mmc_platform_data, that would take care of SDMA & SDMA_DLAOD in the driver instead going with SOC check . -- 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 v8 1/2] sDMA: descriptor autoloading feature
Shilimkar, Santosh wrote:
>> -Original Message-
>> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of
>> Venkatraman S
>> Sent: Wednesday, May 05, 2010 9:56 PM
>> To: Shilimkar, Santosh
>> Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
>> linux-arm-ker...@lists.infradead.org;
>> Chikkature Rajashekar, Madhusudhan; Adrian Hunter; Tony Lindgren
>> Subject: Re: [PATCH v8 1/2] sDMA: descriptor autoloading feature
>>
>> On Wed, May 5, 2010 at 5:31 PM, Shilimkar, Santosh
>> wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of
>> >> Venkatraman S
>> >> Sent: Wednesday, May 05, 2010 5:20 PM
>> >> To: Shilimkar, Santosh
>> >> Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
>> >> linux-arm-ker...@lists.infradead.org;
>> >> Chikkature Rajashekar, Madhusudhan; Adrian Hunter; Tony Lindgren
>> >> Subject: Re: [PATCH v8 1/2] sDMA: descriptor autoloading feature
>> >>
>> >> [Long sections have been trimmed to the context of the discussion]
>> >> On Wed, May 5, 2010 at 3:02 PM, Shilimkar, Santosh
>> >> wrote:
>> >> >> -Original Message-
>> >> >> +static int dma_sglist_set_phy_params(struct omap_dma_sglist_node
>> >> >> *sghead,
>> >> >> + dma_addr_t phyaddr, int nelem)
>> >> >> +{
>> >> >> + struct omap_dma_sglist_node *sgcurr, *sgprev;
>> >> >> + dma_addr_t elem_paddr = phyaddr;
>> >> >> +
>> >> >> + for (sgprev = sghead;
>> >> >> + sgprev < sghead + nelem;
>> >> >> + sgprev++) {
>> >> >> +
>> >> >> + sgcurr = sgprev + 1;
>> >> >> + sgprev->next = sgcurr;
>> >> >> + elem_paddr += (int)sizeof(*sgcurr);
>> >> >> + sgprev->next_desc_add_ptr = elem_paddr;
>> >> >> +
>> >> >> + switch (sgcurr->desc_type) {
>> >> >> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE1:
>> >> >> + omap_dma_list_set_ntype(sgprev, 1);
>> >> >> + break;
>> >> >> +
>> >> >> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE2a:
>> >> >> + /* intentional no break */
>> >> >> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE2b:
>> >> >> + omap_dma_list_set_ntype(sgprev, 2);
>> >> >> + break;
>> >> >> +
>> >> >> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE3a:
>> >> >> + /* intentional no break */
>> >> >> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE3b:
>> >> >> + omap_dma_list_set_ntype(sgprev, 3);
>> >> >> + break;
>> >> >> +
>> >> >> + default:
>> >> >> + return -EINVAL;
>> >> >> +
>> >> >> + }
>> >> > Are we supporting all the descriptor types. I think only type2a is
>> >> > supported. In that case please add FIXME, or WARN message here.
>> >>
>> >> From DMA perspective, all are supported - no restrictions. Only I have
>> >> not figured
>> >> out how to use type 2b and type 3b descriptors. It's not the fault of
>> >> DMA driver or
>> >> specification :-) It's actually upto the client to select the right type.
>> > OK. Then the question which I wanted to ask.
>> > For TX, 2b should have been better choice than 2a isn't it?
>>
>> Not much of a difference (as the space allocation is common), but I
>> couldn't get 2b working correctly.
>> Will try that once I get some clarification from hardware team.
> Add a FIXME then with description in the code so that it's not forgotten once
> the code
> is merged.
OK. I am assuming the FIXME has to be in MMC driver, not here.
--
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 v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature
Shilimkar, Santosh wrote:
>> -Original Message-
>> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of
>> Venkatraman S
>> Sent: Wednesday, May 05, 2010 9:49 PM
>> To: Shilimkar, Santosh
>> Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
>> linux-arm-ker...@lists.arm.linux.org.uk;
>> Chikkature Rajashekar, Madhusudhan; Adrian Hunter; Kadiyala, Kishore; Tony
>> Lindgren
>> Subject: Re: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor
>> autoloading feature
>>
>> [Long sections have been trimmed to the context of discussion]
>> Shilimkar, Santosh wrote:
>> >
>> >> -Original Message-
>> >> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of
>> >> Venkatraman S
>> >> Sent: Thursday, April 29, 2010 11:05 PM
>> >> To: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
>> >> linux-arm-ker...@lists.arm.linux.org.uk
>> >> Cc: Chikkature Rajashekar, Madhusudhan; Adrian Hunter; Kadiyala, Kishore;
>> >> Shilimkar, Santosh; Tony
>> >> Lindgren
>> >> Subject: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor
>> >> autoloading feature
>> >>
>> >> From 1c63dd42fc6c563c931168779ce73401332faa52 Mon Sep 17 00:00:00 2001
>> >> From: Venkatraman S
>> >> Date: Thu, 29 Apr 2010 22:43:31 +0530
>> >> Subject: [PATCH 2/2] omap hsmmc: adaptation of sdma descriptor
>> >> autoloading feature
>> >>
>> >> Start to use the sDMA descriptor autoloading feature.
>> >> For large datablocks, the MMC driver has to repeatedly setup,
>> >> program and teardown the dma channel for each element of the
>> >> sglist received in omap_hsmmc_request.
>> >>
>> >> By using descriptor autoloading, transfers from / to each element of
>> >> the sglist is pre programmed into a linked list. The sDMA driver
>> >> completes the entire transaction and provides a single interrupt.
>> >>
>> >> Due to this, number of dma interrupts for a typical 100MB transfer on the
>> >> MMC is
>> >> reduced from 25000 to about 400 (approximate). Transfer speeds are
>> >> improved by ~5%.
>> >> (Though it varies on the size of read / write & improves on huge
>> >> transfers)
>> >>
>> >> Descriptor autoloading is available only in 3630 and 4430 (as of now).
>> >> Hence normal DMA mode is also retained.
>> >>
>> >> Signed-off-by: Venkatraman S
>> >> CC: Adrian Hunter
>> >> CC: Madhusudhan C
>> >> CC: Shilimkar Santosh
>> >> CC: Tony Lindgren
>> >> ---
>> >> Changes since previous version
>> >> * Rebased to Adrian Hunter's interrupt syncronisation patch
>> >> https://patchwork.kernel.org/patch/94670/
>> >> * Rename ICR name definition
>> >> drivers/mmc/host/omap_hsmmc.c | 148
>> >> ++--
>> >> 1 files changed, 125 insertions(+), 23 deletions(-)
>> >>
>> >> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
>> >> index 65093d4..095fd94 100644
>> >> --- a/drivers/mmc/host/omap_hsmmc.c
>> >> +++ b/drivers/mmc/host/omap_hsmmc.c
>> >> @@ -102,6 +102,8 @@
>> >> #define SRD (1 << 26)
>> >> #define SOFTRESET (1 << 1)
>> >> #define RESETDONE (1 << 0)
>> >> +/* End of superblock indicator for sglist transfers */
>> >> +#define DMA_ICR_SGLIST_END 0x4D00
>> >>
>> >> /*
>> >> * FIXME: Most likely all the data using these _DEVID defines should come
>> >> @@ -118,6 +120,12 @@
>> >> #define OMAP_MMC_MASTER_CLOCK 9600
>> >> #define DRIVER_NAME "mmci-omap-hs"
>> >>
>> >> +#define DMA_TYPE_NODMA 0
>> > " DMA_TYPE_NODMA" doesn't make sense
>> >> +#define DMA_TYPE_SDMA 1
>> >> +#define DMA_TYPE_SDMA_DLOAD 2
>> >
>> > How about ??
>> > #define TRANSFER_NODMA 0
>> > #define TRANSFER_SDMA_NORMAL 1
>> > #define TRANSFER_SDMA_DESCRIPTOR 2
>> > I think ADMA is also in pipeline, so it can become then
>> > #define TRANSFER_ADMA_DESCRIPTOR 3
>>
>> Yes I was planning to use 3 for ADMA, but the names don't
>> make a big difference.
>>
> Good. Name does makes the difference when somebody reads the code.
> " DMA_TYPE_NODMA" what you make out from this if somebody has no
> background of what patch is doing.
How about DMA_TYPE_NONE ?
>
>> >> +
>> >> +#define DMA_CTRL_BUF_SIZE (PAGE_SIZE * 3)
>> >> +
>> >> /* Timeouts for entering power saving states on inactivity, msec */
>> >> #define OMAP_MMC_DISABLED_TIMEOUT 100
>> >> #define OMAP_MMC_SLEEP_TIMEOUT 1000
>> >> @@ -170,7 +178,11 @@ struct omap_hsmmc_host {
>> >> u32 bytesleft;
>> >> int suspended;
>> >> int irq;
>> >> - int use_dma, dma_ch;
>> >> + int dma_caps;
>> >> + int dma_in_use;
>> > This flag isn't necessary. What you are doing is
>> > just renaming it. Can't you avoid that ??
>> > Inudertand the intent behind "dma_in_use " instead
>> > of "use_dma", but you can surely avoid this change.
>>
>> A
Re: [CBUS PATCH 1/1] CBUS: Fix broken compilation
Ok, sorry for the noise. I missed Alexander Shishkin patch which took care of this already. On Wed, 2010-05-05 at 21:00 +0200, Balbi Felipe (Nokia-D/Helsinki) wrote: > hi again, > > > On Wed, May 05, 2010 at 05:05:29PM +0200, Chinea Carlos (Nokia-D/Helsinki) > wrote: > >Include explicitly slab.h in: > > drivers/cbus/cbus.c > > drivers/cbus/retu-headset.c > > drivers/cbus/retu-user.c > > drivers/cbus/retu-wdt.c > > drivers/cbus/tahvo-user.c > > > >Compile tested with n8x0_defconfig > > > >Signed-off-by: Carlos Chinea > > I see now the problem. > > >--- > > drivers/cbus/cbus.c |1 + > > drivers/cbus/retu-headset.c |1 + > > drivers/cbus/retu-user.c|1 + > > drivers/cbus/retu-wdt.c |1 + > > drivers/cbus/tahvo-user.c |1 + > > 5 files changed, 5 insertions(+), 0 deletions(-) > > > >diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c > >index 00c3c32..2c74d6e 100644 > >--- a/drivers/cbus/cbus.c > >+++ b/drivers/cbus/cbus.c > >@@ -30,6 +30,7 @@ > > #include > > #include > > #include > >+#include > > this is already included in line 32 of that file. > > >diff --git a/drivers/cbus/retu-headset.c b/drivers/cbus/retu-headset.c > >index e798bc2..645679c 100644 > >--- a/drivers/cbus/retu-headset.c > >+++ b/drivers/cbus/retu-headset.c > >@@ -25,6 +25,7 @@ > > #include > > #include > > #include > >+#include > > already on line 25, right above #include > > >diff --git a/drivers/cbus/retu-user.c b/drivers/cbus/retu-user.c > >index 0f35dc5..7bc97d4 100644 > >--- a/drivers/cbus/retu-user.c > >+++ b/drivers/cbus/retu-user.c > >@@ -33,6 +33,7 @@ > > #include > > #include > > #include > >+#include > > already on line 26 > > >diff --git a/drivers/cbus/retu-wdt.c b/drivers/cbus/retu-wdt.c > >index 35932dd..fda8b35 100644 > >--- a/drivers/cbus/retu-wdt.c > >+++ b/drivers/cbus/retu-wdt.c > >@@ -35,6 +35,7 @@ > > #include > > #include > > #include > >+#include > > already on line 25 > > >diff --git a/drivers/cbus/tahvo-user.c b/drivers/cbus/tahvo-user.c > >index c0e8daf..b28b015 100644 > >--- a/drivers/cbus/tahvo-user.c > >+++ b/drivers/cbus/tahvo-user.c > >@@ -33,6 +33,7 @@ > > #include > > #include > > #include > >+#include > > already on line 26. > > NAK to this patch. > -- Carlos Chinea -- 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] mmci-omap: Use resource_size
Use the resource_size function instead of manually calculating the resource size. This reduces the chance of introducing off-by-one errors. Signed-off-by: Tobias Klauser --- drivers/mmc/host/omap.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c index 84d2804..a2c8545 100644 --- a/drivers/mmc/host/omap.c +++ b/drivers/mmc/host/omap.c @@ -1415,7 +1415,7 @@ static int __init mmc_omap_probe(struct platform_device *pdev) if (res == NULL || irq < 0) return -ENXIO; - res = request_mem_region(res->start, res->end - res->start + 1, + res = request_mem_region(res->start, resource_size(res), pdev->name); if (res == NULL) return -EBUSY; @@ -1537,7 +1537,7 @@ static int mmc_omap_remove(struct platform_device *pdev) iounmap(host->virt_base); release_mem_region(pdev->resource[0].start, - pdev->resource[0].end - pdev->resource[0].start + 1); + resource_size(&pdev->resource[0])); kfree(host); -- 1.6.3.3 -- 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: Old DSS code broken as module (was "RE: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in omap3_defconfig")
On Wed, 2010-05-05 at 19:32 +0200, ext Aguirre, Sergio wrote: > Tony, > > > -Original Message- > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > ow...@vger.kernel.org] On Behalf Of Tony Lindgren > > Sent: Friday, April 30, 2010 3:34 PM > > To: linux-arm-ker...@lists.infradead.org > > Cc: linux-omap@vger.kernel.org > > Subject: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in > > omap3_defconfig > > > > Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC > > at least on zoom3 for multi-omap. Disable CONFIG_FB until the > > omap FB code is fixed. > > > > This allows booting omap3_defconfig on various omaps. Tested on > > 2420-n8x0, 3430-n900, 3630-zoom3 and 4430-blaze. Note that n8x0 > > still has issues with starting user space because of TLS and > > VFP. > > (Looping Tomi) > > Unfortunately, your patch is uncovering an issue with old DSS code to > compile it as module, which I think is caused by this: > > A single omapfb.ko is attempted to be created in drivers/video/omap/ folder, > but the included source files (DSS code + lcd drivers), results in multiple > module_init entries added in a single module, and therefore giving errors of > duplicate init_module entries between omapfb_main.c and the lcd_*.c files. > > So, either you disable old DSS driver completely, or you have it as > built-in. Ah, yes. I'm not sure if the older omapfb was ever really designed to be used as module... If this is the problem, then my suggestion is to either use it built-in, or use the new DSS2 which works well as modules. I guess the option to compile the older omapfb as a module should be removed? Or if some brave soul wants to start fixing omapfb, that's ok too =). Tomi -- 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 v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature
> -Original Message-
> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of Venkatraman
> S
> Sent: Wednesday, May 05, 2010 9:49 PM
> To: Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.arm.linux.org.uk;
> Chikkature Rajashekar, Madhusudhan; Adrian Hunter; Kadiyala, Kishore; Tony
> Lindgren
> Subject: Re: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor
> autoloading feature
>
> [Long sections have been trimmed to the context of discussion]
> Shilimkar, Santosh wrote:
> >
> >> -Original Message-
> >> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of
> >> Venkatraman S
> >> Sent: Thursday, April 29, 2010 11:05 PM
> >> To: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
> >> linux-arm-ker...@lists.arm.linux.org.uk
> >> Cc: Chikkature Rajashekar, Madhusudhan; Adrian Hunter; Kadiyala, Kishore;
> >> Shilimkar, Santosh; Tony
> >> Lindgren
> >> Subject: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor
> >> autoloading feature
> >>
> >> From 1c63dd42fc6c563c931168779ce73401332faa52 Mon Sep 17 00:00:00 2001
> >> From: Venkatraman S
> >> Date: Thu, 29 Apr 2010 22:43:31 +0530
> >> Subject: [PATCH 2/2] omap hsmmc: adaptation of sdma descriptor
> >> autoloading feature
> >>
> >> Start to use the sDMA descriptor autoloading feature.
> >> For large datablocks, the MMC driver has to repeatedly setup,
> >> program and teardown the dma channel for each element of the
> >> sglist received in omap_hsmmc_request.
> >>
> >> By using descriptor autoloading, transfers from / to each element of
> >> the sglist is pre programmed into a linked list. The sDMA driver
> >> completes the entire transaction and provides a single interrupt.
> >>
> >> Due to this, number of dma interrupts for a typical 100MB transfer on the
> >> MMC is
> >> reduced from 25000 to about 400 (approximate). Transfer speeds are
> >> improved by ~5%.
> >> (Though it varies on the size of read / write & improves on huge transfers)
> >>
> >> Descriptor autoloading is available only in 3630 and 4430 (as of now).
> >> Hence normal DMA mode is also retained.
> >>
> >> Signed-off-by: Venkatraman S
> >> CC: Adrian Hunter
> >> CC: Madhusudhan C
> >> CC: Shilimkar Santosh
> >> CC: Tony Lindgren
> >> ---
> >> Changes since previous version
> >> * Rebased to Adrian Hunter's interrupt syncronisation patch
> >> https://patchwork.kernel.org/patch/94670/
> >> * Rename ICR name definition
> >> drivers/mmc/host/omap_hsmmc.c | 148
> >> ++--
> >> 1 files changed, 125 insertions(+), 23 deletions(-)
> >>
> >> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> >> index 65093d4..095fd94 100644
> >> --- a/drivers/mmc/host/omap_hsmmc.c
> >> +++ b/drivers/mmc/host/omap_hsmmc.c
> >> @@ -102,6 +102,8 @@
> >> #define SRD (1 << 26)
> >> #define SOFTRESET (1 << 1)
> >> #define RESETDONE (1 << 0)
> >> +/* End of superblock indicator for sglist transfers */
> >> +#define DMA_ICR_SGLIST_END 0x4D00
> >>
> >> /*
> >> * FIXME: Most likely all the data using these _DEVID defines should come
> >> @@ -118,6 +120,12 @@
> >> #define OMAP_MMC_MASTER_CLOCK 9600
> >> #define DRIVER_NAME "mmci-omap-hs"
> >>
> >> +#define DMA_TYPE_NODMA 0
> > " DMA_TYPE_NODMA" doesn't make sense
> >> +#define DMA_TYPE_SDMA 1
> >> +#define DMA_TYPE_SDMA_DLOAD 2
> >
> > How about ??
> > #define TRANSFER_NODMA 0
> > #define TRANSFER_SDMA_NORMAL 1
> > #define TRANSFER_SDMA_DESCRIPTOR 2
> > I think ADMA is also in pipeline, so it can become then
> > #define TRANSFER_ADMA_DESCRIPTOR 3
>
> Yes I was planning to use 3 for ADMA, but the names don't
> make a big difference.
>
Good. Name does makes the difference when somebody reads the code.
" DMA_TYPE_NODMA" what you make out from this if somebody has no
background of what patch is doing.
> >> +
> >> +#define DMA_CTRL_BUF_SIZE (PAGE_SIZE * 3)
> >> +
> >> /* Timeouts for entering power saving states on inactivity, msec */
> >> #define OMAP_MMC_DISABLED_TIMEOUT 100
> >> #define OMAP_MMC_SLEEP_TIMEOUT 1000
> >> @@ -170,7 +178,11 @@ struct omap_hsmmc_host {
> >> u32 bytesleft;
> >> int suspended;
> >> int irq;
> >> - int use_dma, dma_ch;
> >> + int dma_caps;
> >> + int dma_in_use;
> > This flag isn't necessary. What you are doing is
> > just renaming it. Can't you avoid that ??
> > Inudertand the intent behind "dma_in_use " instead
> > of "use_dma", but you can surely avoid this change.
>
> Actually there is a shift in the meaning of these variables
> so I believe the change is necessary.
> With my changes, the type of DMA to use (SDMA, SDMA_DESC_LOAD)
> [and in the fut
Re: [PATCH 4/4 v2] ks8851: read/write MAC address on companion eeprom through debugfs
Hi david, On Thursday 06 May 2010 09:25:08 David Miller wrote: > From: Sebastien Jan > Date: Wed, 5 May 2010 20:45:55 +0200 > > > A more elegant alternative to ethtool for updating the ks8851 > > MAC address stored on its companion eeprom. > > Using this debugfs interface does not require any knowledge on the > > ks8851 companion eeprom organization to update the MAC address. > > > > Example to write 01:23:45:67:89:AB MAC address to the companion > > eeprom (assuming debugfs is mounted in /sys/kernel/debug): > > $ echo "01:23:45:67:89:AB" > /sys/kernel/debug/ks8851/mac_eeprom > > > > Signed-off-by: Sebastien Jan > > Elegant? This commit message is the biggest lie ever told. > > What makes your ethernet driver so god-damn special that it deserves > to have a private, completely unique, and obscure interface for > setting the permanent ethernet address of a network device? > > Tell me how damn elegant it is that users have to learn about this > special, unique, and common with no other driver, interface for > performing this task? > > Tell me how damn elegant it is when another driver wants to provide > users with a way to do this too, and they (like you) come up with > their own unique and different interface for doing this. > > No, this is the most inelegant patch ever conceived because it totally > ignores the way in which we handle issues like this. > > There is no way in the world I'm applying this garbage patch, sorry. > > We have an ETHTOOL_GPERMADDR, add a new ETHTOOL_SPERMADDR operation > and then any driver (not just your's) can portably provide this > facility and users will have one, and only one, way of performing this > task. > I agree that my commit message was probably too provocative, sorry for that. Thank you for shedding some light on ETHTOOL_GPERMADDR and ETHTOOL_SPERMADDR. I will look into these interfaces for a proper and generic implementation. -- 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 v8 1/2] sDMA: descriptor autoloading feature
> -Original Message-
> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of Venkatraman
> S
> Sent: Wednesday, May 05, 2010 9:56 PM
> To: Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org;
> Chikkature Rajashekar, Madhusudhan; Adrian Hunter; Tony Lindgren
> Subject: Re: [PATCH v8 1/2] sDMA: descriptor autoloading feature
>
> On Wed, May 5, 2010 at 5:31 PM, Shilimkar, Santosh
> wrote:
> >
> >
> >> -Original Message-
> >> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of
> >> Venkatraman S
> >> Sent: Wednesday, May 05, 2010 5:20 PM
> >> To: Shilimkar, Santosh
> >> Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
> >> linux-arm-ker...@lists.infradead.org;
> >> Chikkature Rajashekar, Madhusudhan; Adrian Hunter; Tony Lindgren
> >> Subject: Re: [PATCH v8 1/2] sDMA: descriptor autoloading feature
> >>
> >> [Long sections have been trimmed to the context of the discussion]
> >> On Wed, May 5, 2010 at 3:02 PM, Shilimkar, Santosh
> >> wrote:
> >> >> -Original Message-
> >> >> +static int dma_sglist_set_phy_params(struct omap_dma_sglist_node
> >> >> *sghead,
> >> >> + dma_addr_t phyaddr, int nelem)
> >> >> +{
> >> >> + struct omap_dma_sglist_node *sgcurr, *sgprev;
> >> >> + dma_addr_t elem_paddr = phyaddr;
> >> >> +
> >> >> + for (sgprev = sghead;
> >> >> + sgprev < sghead + nelem;
> >> >> + sgprev++) {
> >> >> +
> >> >> + sgcurr = sgprev + 1;
> >> >> + sgprev->next = sgcurr;
> >> >> + elem_paddr += (int)sizeof(*sgcurr);
> >> >> + sgprev->next_desc_add_ptr = elem_paddr;
> >> >> +
> >> >> + switch (sgcurr->desc_type) {
> >> >> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE1:
> >> >> + omap_dma_list_set_ntype(sgprev, 1);
> >> >> + break;
> >> >> +
> >> >> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE2a:
> >> >> + /* intentional no break */
> >> >> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE2b:
> >> >> + omap_dma_list_set_ntype(sgprev, 2);
> >> >> + break;
> >> >> +
> >> >> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE3a:
> >> >> + /* intentional no break */
> >> >> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE3b:
> >> >> + omap_dma_list_set_ntype(sgprev, 3);
> >> >> + break;
> >> >> +
> >> >> + default:
> >> >> + return -EINVAL;
> >> >> +
> >> >> + }
> >> > Are we supporting all the descriptor types. I think only type2a is
> >> > supported. In that case please add FIXME, or WARN message here.
> >>
> >> From DMA perspective, all are supported - no restrictions. Only I have
> >> not figured
> >> out how to use type 2b and type 3b descriptors. It's not the fault of
> >> DMA driver or
> >> specification :-) It's actually upto the client to select the right type.
> > OK. Then the question which I wanted to ask.
> > For TX, 2b should have been better choice than 2a isn't it?
>
> Not much of a difference (as the space allocation is common), but I
> couldn't get 2b working correctly.
> Will try that once I get some clarification from hardware team.
Add a FIXME then with description in the code so that it's not forgotten once
the code
is merged.
>
> >>
> >> >> +
> >> >> + lcfg->sghead = sgparams;
> >> >> + lcfg->num_elem = nelem;
> >> >> + lcfg->sgheadphy = padd;
> >> >> + lcfg->pausenode = -1;
> >> >> +
> >> >> +
> >> >> + if (NULL == chparams)
> >> > Minute point really. Better readability "ch_params"
> >> OK
--
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 v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature
> -Original Message-
> From: Chikkature Rajashekar, Madhusudhan
> Sent: Wednesday, May 05, 2010 10:51 PM
> To: S, Venkatraman; Shilimkar, Santosh
> Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.arm.linux.org.uk;
> 'Adrian Hunter'; Kadiyala, Kishore; 'Tony Lindgren'
> Subject: RE: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor
> autoloading feature
>
>
>
> > >> + if (cpu_is_omap44xx() || cpu_is_omap3630()) {
> > > Can we avoid above by passing this part of platform data??
> > > devices.c
> >
> > I am not clear about the method. The board files export the
> > omap_mmc_platform_data.
> > Does it imply that all board files have to change and export
> > the capability so that it can be queried ?
> >
>
> I don’t see why this capability needs to be passed from the platform data.
> As this feature is dependant on omap it is okay to have a cpu check in the
> driver as the patch is doing it.
>
Because Descriptor load feature is not MMC IP capability but SDMA capability.
To make MMC driver portable we should avoid cluttering with CPU specific checks.
This is recommended way unless and until you think otherwise.
Regards,
Santosh
--
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 00/18] omap platform data and board updates for 2.6.35 merge window
On Wed, 2010-05-05 at 23:09 +0200, ext Tony Lindgren wrote: > * Koen Kooi [100505 13:16]: > > Tony, > > > > Any chance of https://patchwork.kernel.org/patch/94049/ going in as well? > > Tomi has acked it already. > > That one looks good to me, but I thought Tomi is going to > queue all the DSS board-*.c patches somewhere. I thought we agreed that board file changes go through linux-omap after I've acked them, to reduce the possibility of conflicts. But yes, I can add it to my tree. I'll send it back to you if we start to get conflicts =). Tomi -- 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 00/18] omap platform data and board updates for 2.6.35 merge window
Op 5 mei 2010, om 23:09 heeft Tony Lindgren het volgende geschreven: > * Koen Kooi [100505 13:16]: >> Tony, >> >> Any chance of https://patchwork.kernel.org/patch/94049/ going in as well? >> Tomi has acked it already. > > That one looks good to me, but I thought Tomi is going to > queue all the DSS board-*.c patches somewhere. Tomi, do you think this can go into the 2.6.35 merge window with other boardfile changes? regards, Koen-- 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 4/4 v2] ks8851: read/write MAC address on companion eeprom through debugfs
From: Sebastien Jan Date: Wed, 5 May 2010 20:45:55 +0200 > A more elegant alternative to ethtool for updating the ks8851 > MAC address stored on its companion eeprom. > Using this debugfs interface does not require any knowledge on the > ks8851 companion eeprom organization to update the MAC address. > > Example to write 01:23:45:67:89:AB MAC address to the companion > eeprom (assuming debugfs is mounted in /sys/kernel/debug): > $ echo "01:23:45:67:89:AB" > /sys/kernel/debug/ks8851/mac_eeprom > > Signed-off-by: Sebastien Jan Elegant? This commit message is the biggest lie ever told. What makes your ethernet driver so god-damn special that it deserves to have a private, completely unique, and obscure interface for setting the permanent ethernet address of a network device? Tell me how damn elegant it is that users have to learn about this special, unique, and common with no other driver, interface for performing this task? Tell me how damn elegant it is when another driver wants to provide users with a way to do this too, and they (like you) come up with their own unique and different interface for doing this. No, this is the most inelegant patch ever conceived because it totally ignores the way in which we handle issues like this. There is no way in the world I'm applying this garbage patch, sorry. We have an ETHTOOL_GPERMADDR, add a new ETHTOOL_SPERMADDR operation and then any driver (not just your's) can portably provide this facility and users will have one, and only one, way of performing this task. -- 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 3/4 v2] ks8851: companion eeprom access through ethtool
From: Sebastien Jan Date: Wed, 5 May 2010 20:45:54 +0200 > Accessing ks8851 companion eeprom permits modifying the ks8851 stored > MAC address. > > Example how to change the MAC address using ethtool, to set the > 01:23:45:67:89:AB MAC address: > $ echo "0:AB8976452301" | xxd -r > mac.bin > $ sudo ethtool -E eth0 magic 0x8870 offset 2 < mac.bin > > Signed-off-by: Sebastien Jan Applied. -- 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/4 v2] ks8851: Low level functions for read/write to companion eeprom
From: Sebastien Jan Date: Wed, 5 May 2010 20:45:53 +0200 > Low-level functions provide 16bits words read and write capability > to ks8851 companion eeprom. > > Signed-off-by: Sebastien Jan Applied. -- 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 1/4 v2] ks8851: Add caching of CCR register
From: Sebastien Jan Date: Wed, 5 May 2010 20:45:52 +0200 > CCR register contains information on companion eeprom availability. > > Signed-off-by: Sebastien Jan APplied. -- 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
