[PATCH] arm: omap: Remove apollon board support

2012-12-25 Thread Kyungmin Park 
From: Kyungmin Park 

As apollon board doesn't used anymore, remove it.

Signed-off-by: Kyungmin Park 
---
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 41b581f..d4e4f95 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -165,12 +165,6 @@ config MACH_OMAP_H4
select OMAP_DEBUG_DEVICES
select OMAP_PACKAGE_ZAF
 
-config MACH_OMAP_APOLLON
-   bool "OMAP 2420 Apollon board"
-   depends on SOC_OMAP2420
-   default y
-   select OMAP_PACKAGE_ZAC
-
 config MACH_OMAP_2430SDP
bool "OMAP 2430 SDP board"
depends on SOC_OMAP2430
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index a8004f3..25ca2a1 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -220,7 +220,6 @@ endif
 obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o
 obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
 obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o
-obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
 obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o
 obj-$(CONFIG_MACH_DEVKIT8000)  += board-devkit8000.o
 obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 65468f6..ca7c5d4 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -783,9 +783,6 @@ static int __devinit gpmc_mem_init(void)
 * even if we didn't boot from ROM.
 */
boot_rom_space = BOOT_ROM_SPACE;
-   /* In apollon the CS0 is mapped as 0x  */
-   if (machine_is_omap_apollon())
-   boot_rom_space = 0;
gpmc_mem_root.start = GPMC_MEM_START + boot_rom_space;
gpmc_mem_root.end = GPMC_MEM_END;
 
diff --git a/arch/arm/mach-omap2/include/mach/uncompress.h 
b/arch/arm/mach-omap2/include/mach/uncompress.h
index 8e3546d..e278451 100644
--- a/arch/arm/mach-omap2/include/mach/uncompress.h
+++ b/arch/arm/mach-omap2/include/mach/uncompress.h
@@ -115,7 +115,6 @@ static inline void arch_decomp_setup(void)
do {
/* omap2 based boards using UART1 */
DEBUG_LL_OMAP2(1, omap_2430sdp);
-   DEBUG_LL_OMAP2(1, omap_apollon);
DEBUG_LL_OMAP2(1, omap_h4);
 
/* omap2 based boards using UART3 */
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c 
b/drivers/video/omap2/displays/panel-generic-dpi.c
index 54ca8ae..c904f42 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -291,30 +291,6 @@ static struct panel_config generic_dpi_panels[] = {
.name   = "h4",
},
 
-   /* Unknown panel used in Samsung OMAP2 Apollon */
-   {
-   {
-   .x_res  = 480,
-   .y_res  = 272,
-
-   .pixel_clock= 6250,
-
-   .hsw= 41,
-   .hfp= 2,
-   .hbp= 2,
-
-   .vsw= 10,
-   .vfp= 2,
-   .vbp= 2,
-
-   .vsync_level= OMAPDSS_SIG_ACTIVE_LOW,
-   .hsync_level= OMAPDSS_SIG_ACTIVE_LOW,
-   .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
-   .de_level   = OMAPDSS_SIG_ACTIVE_HIGH,
-   .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
-   },
-   .name   = "apollon",
-   },
/* FocalTech ETM070003DH6 */
{
{
diff --git a/arch/arm/mach-omap2/board-apollon.c 
b/arch/arm/mach-omap2/board-apollon.c
deleted file mode 100644
index 5d0a61f..000
--- a/arch/arm/mach-omap2/board-apollon.c
+++ /dev/null
@@ -1,342 +0,0 @@
-/*
- * linux/arch/arm/mach-omap2/board-apollon.c
- *
- * Copyright (C) 2005,2006 Samsung Electronics
- * Author: Kyungmin Park 
- *
- * Modified from mach-omap/omap2/board-h4.c
- *
- * Code for apollon OMAP2 board. Should work on many OMAP2 systems where
- * the bootloader passes the board-specific data to the kernel.
- * Do not put any board specific code to this file; create a new machine
- * type if you need custom low-level initializations.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-
-#include "common.h"
-#include "gpmc.h"
-
-#include 
-#include 
-
-#include "mux

Re: [PATCH v4 0/7] Add TI EMIF SDRAM controller driver

2012-03-16 Thread Kyungmin Park 
Hi,

On 3/17/12, Aneesh V  wrote:
> Add a driver for the EMIF SDRAM controller used in TI SoCs
>
> EMIF is an SDRAM controller that supports, based on its revision,
> one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support
> for LPDDR2.
>
> The driver supports the following features:
> - Calculates the DDR AC timing parameters to be set in EMIF
>   registers using data from the device data-sheets and based
>   on the DDR frequency. If data from data-sheets is not available
>   default timing values from the JEDEC spec are used. These
>   will be safe, but not necessarily optimal
> - API for changing timings during DVFS or at boot-up
> - Temperature alert configuration and handling of temperature
>   alerts, if any for LPDDR2 devices
>   * temperature alert is based on periodic polling of MR4 mode
> register in DDR devices automatically performed by hardware
>   * timings are de-rated and brought back to nominal when
> temperature raises and falls respectively
> - Cache of calculated register values to avoid re-calculating
>   them
>
> The driver will need some minor updates when it is eventually
> integrated with Dynamic Voltage and Frequency Scaling (DVFS).
> This can not be done now as DVFS support is not available in
> the mainline yet.
Do you see the devfreq? it's designed for non-cpu device frequency.
It's role is similar with cpufreq.

Now samsung exynos uses devfreq for DRAM bus frequency.

Thank you,
Kyungmin Park
>
> Discussions with Santosh Shilimkar 
> were immensely helpful in shaping up the interfaces. Vibhore Vardhan
>  did the initial code snippet for thermal
> handling.
>
> Testing:
> - The driver is tested on OMAP4430 SDP.
> - The driver in a slightly adapted form is also tested on OMAP5.
> - Since mainline kernel doesn't have DVFS support yet,
>   testing was done using a test module.
> - Temperature alert handling was tested with simulated interrupts
>   and faked temperature values as testing all cases in real-life
>   scenarios is difficult.
> - Tested the driver as a module
>
> Cc: Greg KH 
>
> v4:
> - Converted instances of EXPORT_SYMBOL to EXPORT_SYMBOL_GPL
> - Removed un-necessary "#ifndef __ASSEMBLY__'
> - Minor formatting fix
>
> v2:
> - Fixed a bug found in the implementation of errata i728
>   workaround
> - Fixed the value of frequency printed in debugfs
> - Dropped the hwmod patch as Paul has already posted a
>   a hwmod series [1] that adds hwmod for EMIF
> - Converted instances of __init to __init_or_module
>
> [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/72855
>
> Aneesh V (7):
>   misc: ddr: add LPDDR2 data from JESD209-2
>   misc: emif: add register definitions for EMIF
>   misc: emif: add basic infrastructure for EMIF driver
>   misc: emif: handle frequency and voltage change events
>   misc: emif: add interrupt and temperature handling
>   misc: emif: add one-time settings
>   misc: emif: add debugfs entries for emif
>
>  Documentation/misc-devices/ti-emif.txt  |   58 ++
>  drivers/misc/Kconfig|   12 +
>  drivers/misc/Makefile   |1 +
>  drivers/misc/emif.c | 1670
> +++
>  drivers/misc/emif.h |  589 +++
>  include/linux/platform_data/emif_plat.h |  128 +++
>  include/misc/jedec_ddr.h|  175 
>  lib/Kconfig |8 +
>  lib/Makefile|2 +
>  lib/jedec_ddr_data.c|  135 +++
>  10 files changed, 2778 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/misc-devices/ti-emif.txt
>  create mode 100644 drivers/misc/emif.c
>  create mode 100644 drivers/misc/emif.h
>  create mode 100644 include/linux/platform_data/emif_plat.h
>  create mode 100644 include/misc/jedec_ddr.h
>  create mode 100644 lib/jedec_ddr_data.c
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 0/6] iommu: generic api migration and grouping

2011-06-02 Thread Kyungmin Park 
Hi,

Good approach.
CC'ed the Samsung IOMMU developer. Marek.

BTW, Russell wants to use the DMA based IOMMU?

Please see the RFC patch, ARM: DMA-mapping & IOMMU integration
http://www.spinics.net/lists/linux-mm/msg19856.html

Thank you,
Kyungmin Park

On Fri, Jun 3, 2011 at 7:27 AM, Ohad Ben-Cohen  wrote:
> First stab at iommu consolidation:
>
> - Migrate OMAP's iommu driver to the generic iommu API. With this in hand,
>  users can now start using the generic iommu layer instead of calling
>  omap-specific iommu API.
>
>  New code that requires functionality missing from the generic iommu api,
>  will add that functionality in the generic framework (e.g. adding framework
>  awareness to multi page sizes, supported by the underlying hardware, will
>  avoid the otherwise-inevitable code duplication when mapping a memory
>  region).
>
>  OMAP-specific api that is still exposed in the omap iommu driver can
>  now be either moved to the generic iommu framework, or just removed (if not
>  used).
>
>  This api (and other omap-specific primitives like struct iommu) needs to
>  be omapified (i.e. renamed to include an 'omap_' prefix). At this early
>  point of this patch set this is too much churn though, so I'll do that
>  in the following iteration, after (and if), the general direction is
>  accepted.
>
> - Migrate OMAP's iovmm (virtual memory manager) driver to the generic
>  iommu API. With this in hand, iovmm no longer uses omap-specific api
>  for mapping/unmapping operations. Nevertheless, iovmm is still coupled
>  with omap's iommu even with this change: it assumes omap page sizes,
>  and it uses omap's iommu objects to maintain its internal state.
>
>  Further generalizing of iovmm strongly depends on our broader plans for
>  providing a generic virtual memory manager and allocation framework
>  (which, as discussed, should be separated from a specific mapper).
>
>  iovmm has a mainline user: omap3isp, and therefore must be maintained,
>  but new potential users will either have to generalize it, or come up
>  with a different generic framework that will replace it.
>
> - Migrate OMAP's iommu mainline user, omap3isp, to the generic API as well
>  (so it doesn't break). As with iovmm, omap3isp still depends on
>  omap's iommu, mainly because iovmm depends on it, but also for
>  iommu context saving and restoring.
>
>  It is definitely desirable to completely remove omap3isp's dependency
>  on the omap-specific iommu layer, and that will be possible as the
>  required functionality will be added to generic framework.
>
> - Create a dedicated iommu drivers folder (and put the base iommu code there)
> - Move OMAP's and MSM's iommu drivers to that drivers iommu folder
>
>  Putting all iommu drivers together will ease finding similarities
>  between different platforms, with the intention of solving problems once,
>  in a generic framework which everyone can use.
>
>  I've only moved the omap and msm implementations for now, to demonstrate
>  the idea (and support the ARM diet :), but if this is found desirable,
>  we can bring in intel-iommu.c and amd_iommu.c as well.
>
> Meta:
>
> - This patch set is not bisectable; it was splitted (and ordered) this way
>  to ease its review. Later iterations of this patch set will fix that
>  (most likely by squashing the first three patches)
> - Based on and tested with 3.0-rc1
> - OMAP's iommu code was tested on both OMAP3 and OMAP4
> - omap3isp code was tested with a sensor-less OMAP3 (memory-to-memory only)
>  (thanks Laurent Pinchart for showing me the magic needed to test omap3isp :)
> - MSM code was only compile tested
>
> Ohad Ben-Cohen (6):
>  omap: iommu: generic iommu api migration
>  omap: iovmm: generic iommu api migration
>  media: omap3isp: generic iommu api migration
>  drivers: iommu: move to a dedicated folder
>  omap: iommu/iovmm: move to dedicated iommu folder
>  msm: iommu: move to dedicated iommu drivers folder
>
>  arch/arm/mach-msm/Kconfig                          |   15 -
>  arch/arm/mach-msm/Makefile                         |    2 +-
>  arch/arm/plat-omap/Kconfig                         |   12 -
>  arch/arm/plat-omap/Makefile                        |    2 -
>  arch/arm/plat-omap/include/plat/iommu.h            |    3 +-
>  arch/arm/plat-omap/{ => include/plat}/iopgtable.h  |   18 ++
>  arch/arm/plat-omap/include/plat/iovmm.h            |   27 +-
>  arch/x86/Kconfig                                   |    5 +-
>  drivers/Kconfig                                    |    2 +
>  drivers/Makefile                                   |    1 +
>  drivers/base/Makefile                              |    1 -
>  drivers

Re: [PATCH] OMAP: iommu flush page table entries from L1 and L2 cache

2011-04-19 Thread Kyungmin Park 
On Tue, Apr 19, 2011 at 9:01 PM, Arnd Bergmann  wrote:
> On Tuesday 19 April 2011, Kyungmin Park wrote:
>> On Mon, Apr 18, 2011 at 11:13 PM, Arnd Bergmann  wrote:
>> > On Monday 18 April 2011, Kyungmin Park wrote:
>> >> On Mon, Apr 18, 2011 at 8:58 PM, Arnd Bergmann  wrote:
>> >> >
>> >> > One missing piece is still a way for a platform to provide both
>> >> > the iommu and the dma-mapping API in a unified driver. Right now,
>> >> > you have to export both interface for a generic solution.
>> >>
>> >> Actually MSM and we (Michal, Marek) tried to merge the generic IOMMU
>> >> implementation into mm, but MM did't accept it.
>> >
>> > I'm confused. What do you mean with MM?
>> linux/mm, Memory Management.
>
> I'm still confused. What were you suggesting to merge in there?
> Do you have a link to a mailing list discussion?

First, Zach Pfeffer  sent the patch
https://patchwork.kernel.org/patch/108736/

Second, Michal tried it.
http://lkml.org/lkml/2010/9/6/41

http://lwn.net/Articles/403643/
https://patchwork.kernel.org/patch/157451/

Thank you,
Kyungmin Park

>
>        Arnd
>
--
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] OMAP: iommu flush page table entries from L1 and L2 cache

2011-04-19 Thread Kyungmin Park 
On Mon, Apr 18, 2011 at 11:13 PM, Arnd Bergmann  wrote:
> On Monday 18 April 2011, Kyungmin Park wrote:
>> On Mon, Apr 18, 2011 at 8:58 PM, Arnd Bergmann  wrote:
>> >
>> > One missing piece is still a way for a platform to provide both
>> > the iommu and the dma-mapping API in a unified driver. Right now,
>> > you have to export both interface for a generic solution.
>>
>> Actually MSM and we (Michal, Marek) tried to merge the generic IOMMU
>> implementation into mm, but MM did't accept it.
>
> I'm confused. What do you mean with MM?
linux/mm, Memory Management.

Thank you,
Kyungmin Park
>
>> So now it's implemented at each SoCs. I think it's good chance to make
>> a generic IOMMU feature for ARM consolidation.
>>
>> Before this idea, can you review our implementation at above URL?
>
> I've commented on the main implementation for the IOMMU now.
>
>        Arnd
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
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] OMAP: iommu flush page table entries from L1 and L2 cache

2011-04-18 Thread Kyungmin Park 
On Mon, Apr 18, 2011 at 8:58 PM, Arnd Bergmann  wrote:
> On Monday 18 April 2011, Tony Lindgren wrote:
>> * Arnd Bergmann  [110418 10:26]:
>> > On Friday 15 April 2011, Russell King - ARM Linux wrote:
>> > > On Thu, Apr 14, 2011 at 04:52:48PM -0500, Fernando Guzman Lugo wrote:
>> > > > From: Ramesh Gupta 
>> > > >
>> > > > This patch is to flush the iommu page table entries from L1 and L2
>> > > > caches using dma_map_single. This also simplifies the implementation
>> > > > by removing the functions  flush_iopgd_range/flush_iopte_range.
>> > >
>> > > No.  This usage is just wrong.  If you're going to use the DMA API then
>> > > unmap it, otherwise the DMA API debugging will go awol.
>> >
>> >
>> > It's also completely upside-down: The iommu support should provide 
>> > interfaces
>> > using the dma-mapping API, not use that API to provide a machine specific
>> > version of the generic interface.
>> >
>> > As far as I can tell, nothing actually uses these drivers, maybe we should 
>> > just
>> > remove them before we get any code in the mainline kernel that depends on 
>> > it.
>>
>> There is drivers/media/video/omap3isp/isp.c.
>
> Ah, I didn't see that, was looking at an older version.
>
>> But if we now have a generic replacement for this code we should start
>> using it.
>
> To give some background:
>
> Historically, the dma-mapping API has been used for all IOMMUs on
> architectures that need it. This interface is rather flexible,
> but ARM currently only uses it for managing static mappings.
> One thing that it cannot do is mapping memory to an arbitrary
> (driver-chosen) bus address. The generic iommu API was added in order
> to do that, and is mostly used for virtual machines with KVM.
>
> The MSM platform in ARM also added support for the generic iommu
> API, and now the exynos4 is gaining support for it as well.

You can find a exynos4 patches.
http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/31613

>
> One missing piece is still a way for a platform to provide both
> the iommu and the dma-mapping API in a unified driver. Right now,
> you have to export both interface for a generic solution.

Actually MSM and we (Michal, Marek) tried to merge the generic IOMMU
implementation into mm, but MM did't accept it.
So now it's implemented at each SoCs. I think it's good chance to make
a generic IOMMU feature for ARM consolidation.

>
> On ARM, we don't yet use include/asm-generic/dma-mapping-common.h,
> which allows overriding the dma-mapping API per device. This would
> have to change if you want to export the IOMMU functionality using
> the dma-mapping API, but that would also allow abstracting the
> various ways we currently have (dmabounce, swiotlb, linear map,
> custom __arch_page_to_dma, iommu, coherent or noncoherent DMA)
> in a nicer way per device.

Before this idea, can you review our implementation at above URL?

Thank you,
Kyungmin Park
>
>        Arnd
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
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/1] mtd: OneNAND: fix bufferram management when chip has 2-planes.

2010-10-26 Thread Kyungmin Park 
On Tue, Oct 26, 2010 at 6:36 PM, Artem Bityutskiy
 wrote:
> On Sat, 2010-10-23 at 15:43 +0200, Enric Balletbo i Serra wrote:
>> This patch adds code that I think was lost when it was applied the commit
>>   5988af2319781bc8e0ce418affec4e09cfa77907 - mtd: Flex-OneNAND support
>>
>> Test case:
>>  1. Stress a jffs2 filesystem using
>>     bonnie++ -u 0:0 -s 32 -m 16 -r 16
>>  2. dmesg shows various 'Header CRC failed' errors like:
>>     Header CRC failed on REF_PRISTINE node at 0x1e81315c: Read 0x00e0,
>>     calculated 0x564fc9e8
>>
>> Tested on IGEP v2 board with a Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
>> with 2 planes from Numonyx and CONFIG_MTD_ONENAND_2X_PROGRAM set to y
>>
>> Signed-off-by: Enric Balletbo i Serra 
>
> Kyungmin, would be nice to have your ack/nack.
Sorry for late reply

One more check, it seems to use the invalidate instead of update bufferram.
In case of 2X PROGRAM, it always uses the BUFFERRAM0 so invalidate
another bufferram.

Don't set the bufferram index.

Thank you,
Kyungmin Park
>
> --
> Best Regards,
> Artem Bityutskiy (Артём Битюцкий)
>
> --
> 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] mmc: csd version check updated to support MMC v4.41

2010-07-14 Thread Kyungmin Park 
Hi,

you can find it's already merged at mmc tree.

Try to find this one. [PATCH v2] Recognize CSD structure version 3

Thank you,
Kyungmin Park

On Wed, Jul 14, 2010 at 9:19 PM, Ghorai, Sukumar  wrote:
>
>
>> -Original Message-
>> From: Sripathy, Vishwanath
>> Sent: Wednesday, July 14, 2010 5:23 PM
>> To: Ghorai, Sukumar; linux-...@vger.kernel.org; linux-omap@vger.kernel.org
>> Subject: RE: [PATCH] mmc: csd version check updated to support MMC v4.41
>>
>>
>>
>> > -Original Message-
>> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>> > ow...@vger.kernel.org] On Behalf Of Ghorai, Sukumar
>> > Sent: Wednesday, July 14, 2010 1:51 PM
>> > To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
>> > Cc: Ghorai, Sukumar
>> > Subject: [PATCH] mmc: csd version check updated to support MMC v4.41
>> >
>> >  CSD_STRUCTURE [127:126] describes the version of the CSD structure.
>> >  According to the MMC specificaiton (v4.4.1), 3 is also a valid number.
>> >
>> > Signed-off-by: Sukumar Ghorai 
>> > ---
>> >  Tested on omap4430 ES2.0
>> >
>> >  drivers/mmc/core/mmc.c |    2 +-
>> >  1 files changed, 1 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>> > index 89f7a25..525af33 100644
>> > --- a/drivers/mmc/core/mmc.c
>> > +++ b/drivers/mmc/core/mmc.c
>> > @@ -122,7 +122,7 @@ static int mmc_decode_csd(struct mmc_card *card)
>> >      * v1.2 has extra information in bits 15, 11 and 10.
>> >      */
>> >     csd_struct = UNSTUFF_BITS(resp, 126, 2);
>> > -   if (csd_struct != 1 && csd_struct != 2) {
>> > +   if (csd_struct > 3) {
>>
>> Can't csd_struct be 0? If so then your new check will break right?
> [Ghorai] 0 to 3 are the valid numbers.
>
>>
>> >             printk(KERN_ERR "%s: unrecognised CSD structure version %d\n",
>> >                     mmc_hostname(card->host), csd_struct);
>> >             return -EINVAL;
>> > --
>> > 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-mmc" 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 13/16] omap: mux: Mux Apollon LCD power in board-apollon.c

2010-07-01 Thread Kyungmin Park 
On Thu, Jul 1, 2010 at 7:33 PM, Tony Lindgren  wrote:
> * Kyungmin Park  [100701 11:12]:
>> Hi,
>>
>> This value is set from bootloader, and kernel side only change the mode.
>> Right it runs by luck.
>
> So should we just drop the omap_cfg_reg for now, then add it back
> later with proper gpio_request etc?

I mean the original patch is okay. Now that's find. I'll send a patch
if require.

Thank you,
Kyungmin Park
--
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 13/16] omap: mux: Mux Apollon LCD power in board-apollon.c

2010-07-01 Thread Kyungmin Park 
Hi,

This value is set from bootloader, and kernel side only change the mode.
Right it runs by luck.

Thank you,
Kyungmin Park

> -Original Message-
> From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
> Sent: Thursday, July 01, 2010 4:06 PM
> To: ext Tony Lindgren
> Cc: linux-arm-ker...@lists.infradead.org; Kyungmin Park; linux-
> o...@vger.kernel.org
> Subject: Re: [PATCH 13/16] omap: mux: Mux Apollon LCD power in board-
> apollon.c
> 
> On Wed, 2010-06-30 at 14:07 +0200, ext Tony Lindgren wrote:
> > Use the new mux function for that.
> >
> > Cc: Kyungmin Park 
> > Cc: Tomi Valkeinen 
> > Signed-off-by: Tony Lindgren 
> > ---
> >  arch/arm/mach-omap2/board-apollon.c |3 +++
> >  drivers/video/omap/lcd_apollon.c|3 ---
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-
> omap2/board-apollon.c
> > index b86a879..bc67026 100644
> > --- a/arch/arm/mach-omap2/board-apollon.c
> > +++ b/arch/arm/mach-omap2/board-apollon.c
> > @@ -332,6 +332,9 @@ static void __init omap_apollon_init(void)
> > /* REVISIT: where's the correct place */
> > omap_cfg_reg(W19_24XX_SYS_NIRQ);
> >
> > +   /* LCD PWR_EN */
> > +   omap_mux_init_signal("mcbsp2_dr.gpio_11", OMAP_PULL_ENA |
> OMAP_PULL_UP);
> 
> LCD_PWR_EN sounds like output pin. However, I don't see lcd_apollon.c
> nor board-apollon.c set the gpio.
> 
> I don't know what omap_cfg_reg(M21_242X_GPIO11) does, but if it does the
> same thing as the line above, then does the apollon LCD work by luck?
> OMAP pulling the line up, and by chance the pull is stronger than the
> LCDs (possible) pull down, and thus the LCD is powered up...
> 
>  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: Possible bug in onenand_base ?

2010-05-06 Thread Kyungmin Park 
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

Re: Possible bug in onenand_base ?

2010-05-05 Thread 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);

In my test environment, it displays the correct page number.
(addr - onenand_addr(this, block) >> this->page_shift is same as
'(addr >> this->page_shift) & this->page_mask'.

Thank you,
Kyungmin Park

On Fri, Apr 30, 2010 at 7:05 PM, Enric Balletbò i Serra
 wrote:
> Hello all,
>
> After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
> Flex-OneNAND support) the onenand support for my device is broken.
>
> Before this commit when I run the nandtest program all is ok
> ---
> # nandtest /dev/mtd3
> ECC corrections: 0
> ECC failures   : 0
> Bad blocks     : 0
> BBT blocks     : 0
> 002c: checking...
> Finished pass 1 successfully
> --
>
> Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
> fails with:
> ---
> # nandtest /dev/mtd3
> ECC corrections: 0
> ECC failures   : 0
> Bad blocks     : 0
> BBT blocks     : 0
> : reading...
> [  299.092041] onenand_wait: ECC error = 0x8488
>    ( ... lots of ECC errors ... )
> [  299.092041] 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
>    ( ... )
> ---
>
> Investigating a little I see a significant difference introduced by
> this patch. In line
>
> 347:        page = (int) (addr - onenand_addr(this, block)) >>
> this->page_shift;   (patch applied)
>
> instead of
>
> 347:        page = (int) (addr >> this->page_shift);  (without patch)
>
> I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
> the line 347 and now works again. Fantastic, but I suspect this is not
> the proper solution (probably this breaks other onenands devices, I
> can't test).
>
> I'm just introducing in OneNAND devices so anyone can help me to
> understand and solve the problem ? Note that my device is a Numonyx
> 4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
> page )
>
> Thanks in advance,
>
> ///:~Enric
>
> ---
> diff --git a/drivers/mtd/onenand/onenand_base.c
> b/drivers/mtd/onenand/onenand_base.c
> index 081f97d..b1d50a3 100644
> --- a/drivers/mtd/onenand/onenand_base.c
> +++ b/drivers/mtd/onenand/onenand_base.c
> @@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
> int cmd, loff_t addr, size_t le
>
>        default:
>                block = (int) onenand_block(this, addr);
> -               page = (int) (addr - onenand_addr(this, block)) >> 
> this->page_shift;
> +               page = (int) (addr >> this->page_shift);
>
>                if (ONENAND_IS_2PLANE(this)) {
>                        /* Make the even block number */
> ---
>
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
--
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] mtd: make onenand/generic.c more generic

2009-08-04 Thread Kyungmin Park 
Hi

Good idea add the onenand_platform_data, but dont' agree the renaming
the onenand-flash.
Other boards are use it even though it's not released it

Others are good.

Thank you,
Kyungmin Park

On Tue, Aug 4, 2009 at 6:20 PM, Magnus Damm wrote:
> From: Magnus Damm 
>
> This patch removes the ARM dependency from the generic "onenand"
> platform device driver. This change makes the driver useful for
> other architectures as well. Needed for the SuperH kfr2r09 board.
>
> Apart from the obvious Kconfig bits, the most important change
> is the move away from ARM specific includes and platform data.
> Together with this change the only in-tree board code gets an
> update, and the driver name is also changed gracefully break
> potential out of tree drivers.
>
> The driver is also updated to allow NULL as platform data together
> with a few changes to make use of resource_size() and dev_name().
>
> Signed-off-by: Magnus Damm 
> ---
>
>  Tested on the sh7724 kfr2r09 board with a separate platform data patch.
>
>  arch/arm/mach-omap2/board-apollon.c |    4 ++--
>  drivers/mtd/onenand/Kconfig         |    1 -
>  drivers/mtd/onenand/generic.c       |   24 ++--
>  include/linux/mtd/onenand.h         |    8 
>  4 files changed, 24 insertions(+), 13 deletions(-)
>
> --- 0001/arch/arm/mach-omap2/board-apollon.c
> +++ work/arch/arm/mach-omap2/board-apollon.c    2009-08-04 17:01:18.0 
> +0900
> @@ -87,7 +87,7 @@ static struct mtd_partition apollon_part
>        },
>  };
>
> -static struct flash_platform_data apollon_flash_data = {
> +static struct onenand_platform_data apollon_flash_data = {
>        .parts          = apollon_partitions,
>        .nr_parts       = ARRAY_SIZE(apollon_partitions),
>  };
> @@ -99,7 +99,7 @@ static struct resource apollon_flash_res
>  };
>
>  static struct platform_device apollon_onenand_device = {
> -       .name           = "onenand",
> +       .name           = "onenand-flash",
>        .id             = -1,
>        .dev            = {
>                .platform_data  = &apollon_flash_data,
> --- 0001/drivers/mtd/onenand/Kconfig
> +++ work/drivers/mtd/onenand/Kconfig    2009-08-04 17:01:18.0 +0900
> @@ -23,7 +23,6 @@ config MTD_ONENAND_VERIFY_WRITE
>
>  config MTD_ONENAND_GENERIC
>        tristate "OneNAND Flash device via platform device driver"
> -       depends on ARM
>        help
>          Support for OneNAND flash via platform device driver.
>
> --- 0001/drivers/mtd/onenand/generic.c
> +++ work/drivers/mtd/onenand/generic.c  2009-08-04 17:12:00.0 +0900
> @@ -19,12 +19,16 @@
>  #include 
>  #include 
>  #include 
> -
>  #include 
> -#include 
> -
> -#define DRIVER_NAME    "onenand"
>
> +/*
> + * Note: Driver name and platform data format have been updated!
> + *
> + * This version of the driver is named "onenand-flash" and takes struct
> + * onenand_platform_data as platform data. The old ARM-specific version
> + * with the name "onenand" used to take struct flash_platform_data.
> + */
> +#define DRIVER_NAME    "onenand-flash"
>
>  #ifdef CONFIG_MTD_PARTITIONS
>  static const char *part_probes[] = { "cmdlinepart", NULL,  };
> @@ -39,16 +43,16 @@ struct onenand_info {
>  static int __devinit generic_onenand_probe(struct platform_device *pdev)
>  {
>        struct onenand_info *info;
> -       struct flash_platform_data *pdata = pdev->dev.platform_data;
> +       struct onenand_platform_data *pdata = pdev->dev.platform_data;
>        struct resource *res = pdev->resource;
> -       unsigned long size = res->end - res->start + 1;
> +       unsigned long size = resource_size(res);
>        int err;
>
>        info = kzalloc(sizeof(struct onenand_info), GFP_KERNEL);
>        if (!info)
>                return -ENOMEM;
>
> -       if (!request_mem_region(res->start, size, pdev->dev.driver->name)) {
> +       if (!request_mem_region(res->start, size, dev_name(&pdev->dev))) {
>                err = -EBUSY;
>                goto out_free_info;
>        }
> @@ -59,7 +63,7 @@ static int __devinit generic_onenand_pro
>                goto out_release_mem_region;
>        }
>
> -       info->onenand.mmcontrol = pdata->mmcontrol;
> +       info->onenand.mmcontrol = pdata ? pdata->mmcontrol : 0;
>        info->onenand.irq = platform_get_irq(pdev, 0);
>
>        info->mtd.name = dev_name(&pdev->dev);
> @@ -75,7 +79,7 @@ static int __devinit generic_onenand_pro
>        err = parse_mtd_partitions(&info->mtd, part_probes, &info->parts, 0);
>  

Re: Embedded Linux Conference

2009-03-16 Thread Kyungmin Park 
Hi,

On Tue, Mar 17, 2009 at 7:56 AM, Tony Lindgren  wrote:
> * Kevin Hilman  [090316 15:52]:
>> Hans Verkuil  writes:
>>
>> > Just FYI:
>> >
>> > I'll be attending the Embedded Linux Conference in San Francisco, April
>> > 6th-8th (http://www.embeddedlinuxconference.com/elc_2009).
>> >
>> > This might be a good opportunity to discuss omap and davinci V4L2 issues
>> > face-to-face. Let me know if you are interested.
>> >
>>
>> I will be there as well, and while not directly involved with V4L2,
>> I'm involved in various parts of getting OMAP and DaVinci devices
>> supported in mainline kernels.

I will be there too,
I'm interested in Power Management at OMAP and also interested with
how to work with community
such as how to open our in-house kernel and so on.

>
> Yeah I'll be in town too and will be dropping by at the conf
> here and there.
>
> Maybe let's arrange something to get some beers one night during
> the conf?
>

then see you there.

Thank you,
Kyungmin Park
--
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] OMAP: HSMMC: Initialize hsmmc controller registers when resuming

2009-02-23 Thread Kyungmin Park 
Hi,

On Mon, Feb 23, 2009 at 5:04 PM, Adrian Hunter
 wrote:
> ext Kim Kyuwon wrote:
>> Hi,
>>
>> On Sat, Feb 21, 2009 at 6:11 AM, David Brownell  wrote:
>>> On Friday 20 February 2009, Kim Kyuwon wrote:
>>>> +static void omap_hsmmc_init(struct mmc_omap_host *host)
>>>> +{
>>>> +   u32 hctl, capa, value;
>>>> +
>>>> +   /* Only MMC1 supports 3.0V */
>>>> +   if (host->id == OMAP_MMC1_DEVID) {
>>>> +   hctl = SDVS30;
>>> Shouldn't it be remembering what voltage it was using,
>>> and then restore that, instead of always making MMC1
>>> restart at a 3.0V level?  That's pretty awkward to test
>>> unless you have a 1.8V-capable card in MMC1...
>>
>> You are somewhat right, thank you.
>> But remebering what voltage it was using doesn't feasible to me,
>> because the card can be changed while in 'Sleep' state. I should have
>> inserted a function that detect the right voltage after intializing. I
>> will resend the patch later.
>
> Doesn't it already do that? Can you explain more?
>
> Although I have not tested it, I very much doubt
> dual-voltage cards work.  That is because VMMC1_185V
> is zero, which has the side-effect of turning the
> regulator off (see arch/arm/mach-omap2/mmc-twl4030.c)

It's also to difficult to test in our H/W since it's configured only
support 3.0V.

How about to separate it two phases, first fix the mmc suspend/resume
works again, and then verify dual voltage if there are these hardware

How to you think?

Thank you,
Kyungmin Park
--
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: Hi David Brownell. I have a question for twl4030 driver.

2009-02-13 Thread Kyungmin Park 
Hi,

Since he's in vacation, I reply it instead of him.

On Sat, Feb 14, 2009 at 5:35 AM, David Brownell  wrote:
> On Thursday 12 February 2009, 대인기 wrote:
>> I added "struct regulator_init_data xxx_vpll2" to board-xx.c file to use 
>> VPLL2.
>> but couldn't use it because you annotated codes for VPLL2 like below.
>>
>>   ...
>>
>> So I could use VPLL2 after I get rid of those annotations.
>> I wonder why did you annotate for VPLL2.
>> Does using VPLL2 has some problems?
>
> I didn't have any use case for managing VPLL2 in Linux
> software at runtime, except maybe in conjunction with
> the power management code.
>
> What's your use case?

It's used for graphics power. Without it. we can only see the limited colors.
Yes there's too much example related with it. so we want to know exact usage.
Now workaround we simply enable it at bootloader.

>
> Some of the supported operating points require changes
> to supplies like VDD1 and VDD2 ... I thought that if
> the power management code needed to use the regulator
> framework, we'd hear about it later and be able to deal
> with those issues at that time.

As you know It's not easy work to change hardware. :)

Thank you,
Kyungmin Park
--
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: omap_apollon_2420_defconfig

2009-02-09 Thread Kyungmin Park 
Hi,

In the previous patch, it's only fixed host side. But apollon case, it
only used udc, so udc configuration should select USB_OTG_UTILS also.

Signed-off-by: Kyungmin Park 
---
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 3219d13..b26d6e6 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -191,6 +191,7 @@ config USB_GADGET_OMAP
boolean "OMAP USB Device Controller"
depends on ARCH_OMAP
select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 || MACH_OMAP_H4_OTG
+   select USB_OTG_UTILS if ARCH_OMAP
help
   Many Texas Instruments OMAP processors have flexible full
   speed USB device controllers, with support for up to 30


On Tue, Feb 10, 2009 at 5:53 AM, Tony Lindgren  wrote:
> * Russell King - ARM Linux  [090209 11:27]:
>> It would be nice to get the last OMAP defconfig in mainline working.
>> It's broken since 2.6.29-rc2-git3 due to this persistent problem:
>>
>> drivers/built-in.o: In function `omap_udc_probe':
>> omap.c:(.init.text+0x30cc): undefined reference to `otg_get_transceiver'
>> omap.c:(.init.text+0x38a4): undefined reference to `otg_put_transceiver'
>
> Hmm, looks like 2bf5fa13fc8e34d7b86307b99f64a24cb7a83852 did not fix it.
> Dave, do you already have a patch for this?
>
> 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
>
--
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: 2.6.29-rc: remaining regression: n770_defconfig, omap_apollon_2420_defconfig

2009-01-27 Thread Kyungmin Park 
Hi,

On Wed, Jan 28, 2009 at 8:45 AM, David Brownell  wrote:
> On Tuesday 27 January 2009, Tony Lindgren wrote:
>> * Russell King - ARM Linux  [090127 14:50]:
>> > Now that the usb_port_suspend() build error is fixed in 2.6.29-rc1-git6,
>> > n770_defconfig and omap_apollon_2420_defconfig now suffers from:
>> >
>> > drivers/built-in.o: In function `ohci_omap_init':
>> > hid-quirks.c:(.text+0x6c620): undefined reference to `otg_get_transceiver'
>> > drivers/built-in.o: In function `omap_udc_probe':
>> > hid-quirks.c:(.init.text+0x34c0): undefined reference to 
>> > `otg_get_transceiver'
>> > hid-quirks.c:(.init.text+0x3d40): undefined reference to 
>> > `otg_put_transceiver'
>>
>> Adding linux-usb to the list hoping there's already a fix for this.
>
> Scheduled for 2.6.29-soon:
>
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6
>/gregkh-02-usb.current/usb-omap1-ohci-buildfix.patch
>

Also need following patch in case of usb gadget only.

Signed-off-by: Kyungmin Park 
---
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 3219d13..b26d6e6 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -191,6 +191,7 @@ config USB_GADGET_OMAP
boolean "OMAP USB Device Controller"
depends on ARCH_OMAP
select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 || MACH_OMAP_H4_OTG
+   select USB_OTG_UTILS if ARCH_OMAP
help
   Many Texas Instruments OMAP processors have flexible full
   speed USB device controllers, with support for up to 30
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Provide the set_power at TWL4030 MMC

2008-11-26 Thread Kyungmin Park 
Custom board powered by VAUX2 and VAUX4 for MMC instead of VMMC
Also it uses VMMC for MMC core power not voltage.

MMC1: uses VMMC1(voltage) and VMMC2(Vdd)
MMC2: uses VAUX2(voltage) and VAUX4(Vdd)

To address this issue, platform uses its custom power function.

Signed-off-by: Kyungmin Park <[EMAIL PROTECTED]>
---
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c 
b/arch/arm/mach-omap2/mmc-twl4030.c
index 626d668..571b7b0 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -27,28 +27,6 @@
 
 #if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
 
-#define LDO_CLR0x00
-#define VSEL_S2_CLR0x40
-
-#define VMMC1_DEV_GRP  0x27
-#define VMMC1_CLR  0x00
-#define VMMC1_315V 0x03
-#define VMMC1_300V 0x02
-#define VMMC1_285V 0x01
-#define VMMC1_185V 0x00
-#define VMMC1_DEDICATED0x2A
-
-#define VMMC2_DEV_GRP  0x2B
-#define VMMC2_CLR  0x40
-#define VMMC2_315V 0x0c
-#define VMMC2_300V 0x0b
-#define VMMC2_285V 0x0a
-#define VMMC2_260V 0x08
-#define VMMC2_185V 0x06
-#define VMMC2_DEDICATED0x2E
-
-#define VMMC_DEV_GRP_P10x20
-
 static u16 control_pbias_offset;
 static u16 control_devconf1_offset;
 
@@ -385,14 +363,21 @@ void __init hsmmc_init(struct twl4030_hsmmc_info 
*controllers)
/* NOTE:  we assume OMAP's MMC1 and MMC2 use
 * the TWL4030's VMMC1 and VMMC2, respectively;
 * and that OMAP's MMC3 isn't used.
+* or provided by a platform.
 */
 
switch (c->mmc) {
case 1:
-   mmc->slots[0].set_power = twl_mmc1_set_power;
+   if (c->set_power)
+   mmc->slots[0].set_power = c->set_power;
+   else
+   mmc->slots[0].set_power = twl_mmc1_set_power;
break;
case 2:
-   mmc->slots[0].set_power = twl_mmc2_set_power;
+   if (c->set_power)
+   mmc->slots[0].set_power = c->set_power;
+   else
+   mmc->slots[0].set_power = twl_mmc2_set_power;
break;
default:
pr_err("MMC%d configuration not supported!\n", c->mmc);
diff --git a/arch/arm/mach-omap2/mmc-twl4030.h 
b/arch/arm/mach-omap2/mmc-twl4030.h
index e2d58a2..25a08ed 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.h
+++ b/arch/arm/mach-omap2/mmc-twl4030.h
@@ -6,12 +6,55 @@
  * published by the Free Software Foundation.
  */
 
+#define VAUX2_DEV_GRP  0x1B
+#define VAUX2_315V 0x0C
+#define VAUX2_300V 0x0B
+#define VAUX2_285V 0x0A
+#define VAUX2_260V 0x08
+#define VAUX2_185V 0x06
+#define VAUX2_180V 0x05
+#define VAUX2_DEDICATED0x1E
+
+#define VAUX4_DEV_GRP  0x23
+#define VAUX4_315V 0x0C
+#define VAUX4_300V 0x0B
+#define VAUX4_285V 0x0A
+#define VAUX4_260V 0x08
+#define VAUX4_185V 0x06
+#define VAUX4_DEDICATED0x26
+
+#define VAUX_DEV_GRP_P10x20
+
+#define LDO_CLR0x00
+#define VSEL_S2_CLR0x40
+
+#define VMMC1_DEV_GRP  0x27
+#define VMMC1_CLR  0x00
+#define VMMC1_315V 0x03
+#define VMMC1_300V 0x02
+#define VMMC1_285V 0x01
+#define VMMC1_185V 0x00
+#define VMMC1_DEDICATED0x2A
+
+#define VMMC2_DEV_GRP  0x2B
+#define VMMC2_CLR  0x00
+#define VMMC2_315V 0x0c
+#define VMMC2_300V 0x0b
+#define VMMC2_285V 0x0a
+#define VMMC2_260V 0x08
+#define VMMC2_185V 0x06
+#define VMMC2_DEDICATED0x2E
+
+#define VMMC_DEV_GRP_P10x20
+
 struct twl4030_hsmmc_info {
u8  mmc;/* controller 1/2/3 */
u8  wires;  /* 1/4/8 wires */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
int ext_clock:1;/* use external pin for input clock */
+   int (*set_power)(struct device *dev, int slot,
+   int power_on, int vdd);
 };
 
 #ifdefined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE) || \
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [ONENAND] Add command line partition support on OMAP driver

2008-10-28 Thread Kyungmin Park 
Add command line partition support on OMAP driver

Signed-off-by: Kyungmin Park <[EMAIL PROTECTED]>
---
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index a9885d1..60cf668 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -51,6 +51,10 @@
 #define ONENAND_IO_SIZESZ_128K
 #define ONENAND_BUFRAM_SIZE(1024 * 5)
 
+#ifdef CONFIG_MTD_PARTITIONS
+static const char *part_probes[] = { "cmdlinepart", NULL,  };
+#endif
+
 struct omap2_onenand {
struct platform_device *pdev;
int gpmc_cs;
@@ -685,9 +689,12 @@ static int __devinit omap2_onenand_probe(struct 
platform_device *pdev)
}
 
 #ifdef CONFIG_MTD_PARTITIONS
-   if (pdata->parts != NULL)
+   r = parse_mtd_partitions(&c->mtd, part_probes, &c->parts, 0);
+   if (r > 0)
+   r = add_mtd_partitions(&c->mtd, c->parts, r);
+   else if (pdata->parts != NULL)
r = add_mtd_partitions(&c->mtd, pdata->parts,
-  pdata->nr_parts);
+   pdata->nr_parts);
else
 #endif
r = add_mtd_device(&c->mtd);
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Errors on boot with 2.6.27-rc5 on omap3

2008-09-03 Thread Kyungmin Park 
Hi,

It's already discussed at mtd mailing list and solved (sent to linux)

Please check it at mtd.

Thank you,
Kyungmin Park

On Thu, Sep 4, 2008 at 12:41 PM, Steve Sakoman <[EMAIL PROTECTED]> wrote:
> Anyone else seeing this (error output below)?
>
> I get similar results for both Beagle and Overo, so the error occurs
> for both nand and onenand.  The boot eventually completes, of course
> without nand/onenand support.
>
> Steve
>
> OneNAND driver initializing
> omap2-onenand omap2-onenand: initializing on CS0, phys base
> 0x2000, virtual base c888
> Muxed OneNAND 128MB 1.8V 16-bit (0x30)
> OneNAND version = 0x0221
> Scanning device for bad blocks
> Creating 5 MTD partitions on "omap2-onenand":
> 0x-0x0008 : "xloader"
> 0x0008-0x0026 : "uboot"
> kobject (c795b20c): tried to init an initialized object, something is
> seriously wrong.
> [] (dump_stack+0x0/0x14) from [] (kobject_init+0x40/0x78)
> [] (kobject_init+0x0/0x78) from []
> (kobject_init_and_add+0x20/0x44)
>  r5:c795b20c r4:c7b9c4b8
> [] (kobject_init_and_add+0x4/0x44) from []
> (blk_register_filter+0x48/0x60)
>  r5:c7926400 r4:c795ada0
> [] (blk_register_filter+0x0/0x60) from []
> (add_disk+0x60/0xb8)
>  r4:c7b9c400
> [] (add_disk+0x0/0xb8) from []
> (add_mtd_blktrans_dev+0x24c/0x284)
>  r5:c7926400 r4:0001
> [] (add_mtd_blktrans_dev+0x0/0x284) from []
> (mtdblock_add_mtd+0x58/0x60)
>  r8:0008 r7:c0432a44 r6:001e r5:c0448588 r4:c7bea300
> [] (mtdblock_add_mtd+0x0/0x60) from []
> (blktrans_notify_add+0x30/0x60)
>  r5:c7bea300 r4:c0448588
> [] (blktrans_notify_add+0x0/0x60) from []
> (add_mtd_device+0xb0/0x110)
>  r5:c7bea300 r4:c0448550
> [] (add_mtd_device+0x0/0x110) from []
> (add_mtd_partitions+0x480/0x52c)
>  r5:c7bdaa10 r4:c7bea300
> [] (add_mtd_partitions+0x0/0x52c) from []
> (omap2_onenand_probe+0x360/0x438)
> [] (omap2_onenand_probe+0x0/0x438) from []
> (platform_drv_probe+0x20/0x24)
>  r8:c0445d20 r7:c04488d4 r6:c04488d4 r5:c0432754 r4:c04326a8
> [] (platform_drv_probe+0x0/0x24) from []
> (driver_probe_device+0xd0/0x17c)
> [] (driver_probe_device+0x0/0x17c) from []
> (__driver_attach+0x4c/0x70)
>  r7:c04488d4 r6:c04488d4 r5:c0432754 r4:c04326a8
> [] (__driver_attach+0x0/0x70) from []
> (bus_for_each_dev+0x4c/0x84)
>  r7:c04488d4 r6:c01b66d8 r5:c7825eb4 r4:
> [] (bus_for_each_dev+0x0/0x84) from []
> (driver_attach+0x20/0x28)
>  r7:c7927de0 r6: r5:c04488d4 r4:
> [] (driver_attach+0x0/0x28) from []
> (bus_add_driver+0xa4/0x210)
> [] (bus_add_driver+0x0/0x210) from []
> (driver_register+0x98/0x120)
>  r8: r7: r6: r5:c04488d4 r4:c0455e80
> [] (driver_register+0x0/0x120) from []
> (platform_driver_register+0x78/0x94)
> [] (platform_driver_register+0x0/0x94) from []
> (omap2_onenand_init+0x1c/0x28)
> [] (omap2_onenand_init+0x0/0x28) from []
> (__exception_text_end+0x50/0x17c)
> [] (__exception_text_end+0x0/0x17c) from []
> (kernel_init+0x70/0xdc)
> [] (kernel_init+0x0/0xdc) from [] (do_exit+0x0/0x6e8)
>  r5: r4:
> 0x0026-0x0028 : "params"
> kobject (c795b20c): tried to init an initialized object, something is
> seriously wrong.
> [] (dump_stack+0x0/0x14) from [] (kobject_init+0x40/0x78)
> [] (kobject_init+0x0/0x78) from []
> (kobject_init_and_add+0x20/0x44)
>  r5:c795b20c r4:c7b9ccb8
> [] (kobject_init_and_add+0x4/0x44) from []
> (blk_register_filter+0x48/0x60)
>  r5:c7926b40 r4:c795ada0
> [] (blk_register_filter+0x0/0x60) from []
> (add_disk+0x60/0xb8)
>  r4:c7b9cc00
> [] (add_disk+0x0/0xb8) from []
> (add_mtd_blktrans_dev+0x24c/0x284)
>  r5:c7926b40 r4:0002
> [] (add_mtd_blktrans_dev+0x0/0x284) from []
> (mtdblock_add_mtd+0x58/0x60)
>  r8:0026 r7:c0432a5c r6:0002 r5:c0448588 r4:c7bea400
> [] (mtdblock_add_mtd+0x0/0x60) from []
> (blktrans_notify_add+0x30/0x60)
>  r5:c7bea400 r4:c0448588
> [] (blktrans_notify_add+0x0/0x60) from []
> (add_mtd_device+0xb0/0x110)
>  r5:c7bea400 r4:c0448550
> [] (add_mtd_device+0x0/0x110) from []
> (add_mtd_partitions+0x480/0x52c)
>  r5:c7bdaa10 r4:c7bea400
> [] (add_mtd_partitions+0x0/0x52c) from []
> (omap2_onenand_probe+0x360/0x438)
> [] (omap2_onenand_probe+0x0/0x438) from []
> (platform_drv_probe+0x20/0x24)
>  r8:c0445d20 r7:c04488d4 r6:c04488d4 r5:c0432754 r4:c04326a8
> [] (platform_drv_probe+0x0/0x24) from []
> (driver_probe_device+0xd0/0x17c)
> [] (driver_probe_device+0x0/0x17c) from []
> (__driver_attach+0x4c/0x70)
>  r7:c04488d4 r6:c04488d4 r5:c0432754 r4:c04326a8
> [] (__driver_attach+0x0/0x70) from []
> (bus_for_each_dev+0x4c/0x84)
>  r7:c04488d4 r6:c01b66d8 r5:c7825eb4 r4:
&

Re: [PATCH] MTD: OMAP2-NAND: Fix partition reading from board info

2008-07-01 Thread Kyungmin Park 
Hi,

It's should be sent to MTD list. and we also fix the NOR similar ways.
It's already posted but not committed.

Thank you,
Kyungmin Park

On Tue, Jul 1, 2008 at 11:32 PM, Kamat, Nishant <[EMAIL PROTECTED]> wrote:
>
> From: Nishant Kamat <[EMAIL PROTECTED]>
>
> MTD: OMAP2-NAND: Fix partition reading from board info
>
> The parse_mtd_partitions() function no longer returns
> a negative error in case cmdline is not passed.
> See commit: b0d06afb607
>
> Signed-off-by: Nishant Kamat <[EMAIL PROTECTED]>
> ---
>  drivers/mtd/nand/omap2.c |2 +-
>  1 files changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-omap-ti.ldp/drivers/mtd/nand/omap2.c
> ===
> --- linux-omap-ti.ldp.orig/drivers/mtd/nand/omap2.c 2008-06-30 
> 22:01:50.0 +0530
> +++ linux-omap-ti.ldp/drivers/mtd/nand/omap2.c  2008-06-30 22:03:34.446471469 
> +0530
> @@ -699,7 +699,7 @@
>err = parse_mtd_partitions(&info->mtd, part_probes, &info->parts, 0);
>if (err > 0)
>add_mtd_partitions(&info->mtd, info->parts, err);
> -   else if (err < 0 && pdata->parts)
> +   else if (pdata->parts)
>add_mtd_partitions(&info->mtd, pdata->parts, pdata->nr_parts);
>else
>  #endif
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: OMAP: Fix compiler error at pm-debug

2008-05-20 Thread Kyungmin Park 
Fix compiler error at pm-debug

  CC  arch/arm/mach-omap2/pm-debug.o
In file included from arch/arm/mach-omap2/pm-debug.c:30:
arch/arm/mach-omap2/prm.h: In function `prm_rmw_reg_bits':
arch/arm/mach-omap2/prm.h:107: error: implicit declaration of function 
`__raw_readl'
arch/arm/mach-omap2/prm.h:110: error: implicit declaration of function 
`__raw_writel'
arch/arm/mach-omap2/pm-debug.c: In function `serial_wait_tx':
arch/arm/mach-omap2/pm-debug.c:59: error: implicit declaration of function 
`__raw_readb'
make[1]: *** [arch/arm/mach-omap2/pm-debug.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2

Signed-off-by: Kyungmin Park <[EMAIL PROTECTED]>
---
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 361e52b..8a9f3c4 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -23,6 +23,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] IRQ: simplify OMAP2 mask_irq/unmask_irq code

2008-05-20 Thread Kyungmin Park 
On Wed, May 21, 2008 at 9:39 AM, Philip Balister <[EMAIL PROTECTED]> wrote:
> Paul Walmsley wrote:
>>
>> Hello Kyungmin,
>>
>> On Wed, 21 May 2008, Kyungmin Park wrote:
>>
>>> On Wed, May 21, 2008 at 3:21 AM, Paul Walmsley <[EMAIL PROTECTED]> wrote:
>>>>
>>>>  static void omap_mask_irq(unsigned int irq)
>>>>  {
>>>> -   int offset = (irq >> 5) << 5;
>>>> +   int offset = irq & (~(IRQ_BITS_PER_REG - 1));
>>>>
>>>> -   if (irq >= 64)
>>>> -   irq %= 64;
>>>> -   else if (irq >= 32)
>>>> -   irq %= 32;
>>>> +   irq %= IRQ_BITS_PER_REG;
>>>
>>> Is it the right conversion?
>>> If the irq is greater then 32 and less then or equal to  64 it's
>>> result is different.
>>> E.g, If irq is 63 then original irq is 63, but new code is 31
>>
>> Hmm, in that condition, the result looks the same to me: irq % 32, either
>> way?
>>
>> More practically, if you look at what it does with that irq variable
>> afterwards, it seems to be a bug if irq is ever greater than 31:
>>
>>intc_bank_write_reg(1 << irq, &irq_banks[0], INTC_MIR_CLEAR0 +
>>offset);
>>
>> I think the only case where the new code would work differently than the
>> previous code is if irq > 95.  But that would be a bug, since the shift
>> value would then be > 32, for a 32-bit register.
>>
>>> And if this code is right, how about to use mask instead of modulo op?
>>> irq &= (IRQ_BITS_PER_REG - 1);
>>
>> Hehe, very good point, that would probably save even more cycles!  If you
>> agree with the above, perhaps I can convert the code to use that also, and
>> add your Signed-off-by also?
>
> On some code where I used % to detect a counter passing multiples of a
> certain number, oprofile revealed that the % operator burned a lot of CPU
> cycles. I suspect this had to do with the counter increasing to very large
> numbers, but ever since, I've tried to avoid the % operator in critical
> paths.
>
Yes, In embedded environment, we should avoid the multiple, divide,
and modulo op as much as possible.
It's best to use the bit operations.

Signed-off-by: Kyungmin Park <[EMAIL PROTECTED]>

BR,
Kyungmin Park
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] IRQ: simplify OMAP2 mask_irq/unmask_irq code

2008-05-20 Thread Kyungmin Park 
On Wed, May 21, 2008 at 3:21 AM, Paul Walmsley <[EMAIL PROTECTED]> wrote:
>
> Simplify the IRQ register/IRQ register bit calculations in
> mach-omap2/irq.c.
>
> Test-booted on 3430SDP.
>
> Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
>
> ---
>
> size:
>   textdata bss dec hex filename
> 3341347  170992  109008 3621347  3741e3 vmlinux.3430sdp
> 3341315  170992  109008 3621315  3741c3 vmlinux.3430sdp.patched
>
> ---
>
>  arch/arm/mach-omap2/irq.c |   17 +++--
>  1 files changed, 7 insertions(+), 10 deletions(-)
>
>
> diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
> index ac062ee..f610825 100644
> --- a/arch/arm/mach-omap2/irq.c
> +++ b/arch/arm/mach-omap2/irq.c
> @@ -27,6 +27,9 @@
>  #define INTC_MIR_CLEAR00x0088
>  #define INTC_MIR_SET0  0x008c
>
> +/* Number of IRQ state bits in each MIR register */
> +#define IRQ_BITS_PER_REG   32
> +
>  /*
>  * OMAP2 has a number of different interrupt controllers, each interrupt
>  * controller is identified as its own "bank". Register definitions are
> @@ -67,24 +70,18 @@ static void omap_ack_irq(unsigned int irq)
>
>  static void omap_mask_irq(unsigned int irq)
>  {
> -   int offset = (irq >> 5) << 5;
> +   int offset = irq & (~(IRQ_BITS_PER_REG - 1));
>
> -   if (irq >= 64)
> -   irq %= 64;
> -   else if (irq >= 32)
> -   irq %= 32;
> +   irq %= IRQ_BITS_PER_REG;

Is it the right conversion?
If the irq is greater then 32 and less then or equal to  64 it's
result is different.
E.g, If irq is 63 then original irq is 63, but new code is 31

And if this code is right, how about to use mask instead of modulo op?
irq &= (IRQ_BITS_PER_REG - 1);

Thank you,
Kyungmin Park
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Performance enhancement for MMCSD when feature CONFIG_MMC_BLOCK_BOUNCE is enabled in the MMC core

2008-05-15 Thread Kyungmin Park 
Hi,

On Thu, May 15, 2008 at 10:30 PM, Felipe Balbi
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> this list moved to linux-omap@vger.kernel.org ;-)
>
> On Thu, May 15, 2008 at 4:25 PM, Kumar, Purushotam <[EMAIL PROTECTED]> wrote:
>> This patch will increase performance significantly. In my testing with a SD 
>> Extreme III high speed 2GB SD card using FAT file system on OMAP35X TI EVM, 
>> write speed has improved by 2x whereas read speed has improved by 3 times 
>> for MMCSD when CONFIG_MMC_BLOCK_BOUNCE is enabled.  It is supposed that 
>> larger/bounce buffers will be used by mmc core if CONFIG_MMC_BLOCK_BOUNCE is 
>> defined. But, in the mmc core, size of buffer is set to mmc->max_req_size if 
>> mmc->max_req_size is smaller than MMC_QUEUE_BOUNCESZ i.e. bounce buffer size 
>> (which is 64KB). By default, mmc->max_req_size is set to 4K. So, buffers of 
>> 4K will be used instead of 64K even if CONFIG_MMC_BLOCK_BOUNCE is defined 
>> without this patch. This patches forces mmc core to use bounce buffer of 
>> size MMC_QUEUE_BOUNCESZ and so performance is increased.
>>
>> Signed-off-by: Purushotam Kumar <[EMAIL PROTECTED]>
>> ---
>> Index: linux-omap-2.6/drivers/mmc/host/omap_hsmmc.c
>> ===
>> --- linux-omap-2.6.orig/drivers/mmc/host/omap_hsmmc.c
>> +++ linux-omap-2.6/drivers/mmc/host/omap_hsmmc.c
>> @@ -782,6 +782,15 @@ static int __init omap_mmc_probe(struct
>>else
>>host->dbclk_enabled = 1;
>>
>> +#ifdef CONFIG_MMC_BLOCK_BOUNCE
>> +   mmc->max_phys_segs = 1;
>> +   mmc->max_hw_segs = 1;
>> +#endif
>> +   mmc->max_blk_size = 512;   /* Block Length at max can be 1024 */
>> +   mmc->max_blk_count = 0x;/* No. of Blocks is 16 bits */
>> +   mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
>> +   mmc->max_seg_size = mmc->max_req_size;
>> +
>>mmc->ocr_avail = mmc_slot(host).ocr_mask;
>>mmc->caps |= MMC_CAP_MULTIWRITE | MMC_CAP_MMC_HIGHSPEED |
>>MMC_CAP_SD_HIGHSPEED;
>
> Do you have any measurements results to share :-p
>

similar ways omap.c does, but it's almost same or degraded.
It was tested on apollon (OMAP2420)

Thank you,
Kyungmin Park

# iozone -A -s 128m -q 256k -U /mmc -f /mmc/test -e

% before
131072   430142317 6577 6575
131072   829182702 6577 6568
131072  1628952287 6560 6556
131072  3228392430 6567 6551
131072  6429292688 6548 6545
131072 128   29562534 6572 6565
131072 25628612356 6571 6569

% after
131072   429172784 6383 6379
131072   828062615 6377 6397
131072  1628342953 6383 6379
131072  3228442492 6376 6375
131072  6429762625 6395 6379

Here's patch

diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 549517c..a0c0d38 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -1332,12 +1335,17 @@ static int __init mmc_omap_new_slot(struct mmc_omap_host
mmc->f_max = min(host->pdata->max_freq, mmc->f_max);
mmc->ocr_avail = slot->pdata->ocr_mask;

+#ifdef CONFIG_MMC_BLOCK_BOUNCE
+   mmc->max_phys_segs = 1;
+   mmc->max_hw_segs = 1;
+#else
/* Use scatterlist DMA to reduce per-transfer costs.
 * NOTE max_seg_size assumption that small blocks aren't
 * normally used (except e.g. for reading SD registers).
 */
mmc->max_phys_segs = 32;
mmc->max_hw_segs = 32;
+#endif
mmc->max_blk_size = 2048;   /* BLEN is 11 bits (+1) */
mmc->max_blk_count = 2048;  /* NBLK is 11 bits (+1) */
mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wear-leveling necessary on N810 internal/removable cards?

2008-05-15 Thread Kyungmin Park 
Hi,

On Fri, May 16, 2008 at 8:11 AM, green <[EMAIL PROTECTED]> wrote:
> Okay, I guess this a somewhat off-topic question for this list, but I'm not
> sure where else to ask it, so please forgive me.
>
> Simply: do the controllers for the internal and removeable Flash cards of the
> Nokia N810 do wear-leveling automatically or should I use something like JFFS2
> to handle that?  I suppose that the location of the kernel, initfs, and rootfs
> does not do wear-leveling because the maemo OS does use JFFS2 for the rootfs,
> but I'm not sure about the two Flash cards.
>

It's MMC cards which means it does its own wear-leveling internally.
So you don't need to worry it.

Thank you,
Kyungmin Park
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

vanilla kernel is broken on omap board

2008-05-06 Thread Kyungmin Park 
Hi Tony,

Current vanilla kernel is broken on omap2 boards.
In the previous time you committed some omap2 patches, but some
patches are not missing.
Such as Runtime constants series. [1]

Now "some parts" are already included.
So you just commit the remain parts too such as in [2]
In most cases the board files don't set the their own global variables.

Thank you,
Kyungmin Park

1. Runtime constants: introduce omap2_set_globals_*()
http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=commit;h=2b256e28e8e70592f0c38a862cc4ba0498c9db7b
Runtime constants: use runtime-computed SDRC base
http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=7b5f8cdb222052a7aa02ed38c59e0af1946b1e06
Runtime constants: use runtime-computed SMS base
http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=80ccf4b99eb3892809bbebf7673bdd1a359d56ff

2.
diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apo
index a1e1e67..620fa0f 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -394,6 +394,7 @@ static void __init omap_apollon_init(void)

 static void __init omap_apollon_map_io(void)
 {
+   omap2_set_globals_242x();
omap2_map_common_io();
 }
diff --git a/include/asm-arm/arch-omap/common.h b/include/asm-arm/arch-omap/comm
index 224e009..36a3b62 100644
--- a/include/asm-arm/arch-omap/common.h
+++ b/include/asm-arm/arch-omap/common.h
@@ -47,4 +47,8 @@ static inline int omap_register_i2c_bus(int bus_id, u32 clkrat
 }
 #endif

+void omap2_set_globals_242x(void);
+void omap2_set_globals_243x(void);
+void omap2_set_globals_343x(void);
+
 #endif /* __ARCH_ARM_MACH_OMAP_COMMON_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: source.mvista links are broken

2008-04-09 Thread Kyungmin Park 
On Wed, Apr 9, 2008 at 8:53 PM, Woodruff, Richard <[EMAIL PROTECTED]> wrote:
> > I am not able to find x-loader git tree, maintained by Kyungmin Park
>  > of Samsung on source.mvista.com?
>
>  I see the tree there.  There does seem to be some other junk intermixed
>  in it.
>
>  http://source.mvista.com/gittrees/xloader.git/
>
>  There are a couple additional side points about this tree:
> - Some of his work was folded back into u-boot proper for
>  OneNAND devices.  So there probably is a slow down of usage in this
>  repository.

Yes, I added it to u-boot to make a OneNAND boot image by using one compile.
Of course, you can use the 1KiB boot image separately with other bootloaders.
It has separate directory and can build it.

See reference board, apollon in u-boot tree.

> - TI has versions with 3430 and other board support on our web
>  site.

Do you have a plan to push it to u-boot tree?

> - Along with more boards, there have been some changes
>  we pulled back in from u-boot to support more compilers.  I don't think
>  these ever went back out into this git tree.  It's a matter of who is
>  using it and what its useful for.
>

Thank you,
Kyungmin Park
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html