[PATCH] arm: omap: Remove apollon board support

2012-12-25 Thread Kyungmin Park 
From: Kyungmin Park kyungmin.p...@samsung.com

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

Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
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 kyungmin.p...@samsung.com
- *
- * 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 linux/kernel.h
-#include linux/init.h
-#include linux/platform_device.h
-#include linux/mtd/mtd.h
-#include linux/mtd/partitions.h
-#include linux/mtd/onenand.h
-#include linux/delay.h
-#include linux/leds.h
-#include linux/err.h
-#include linux/clk.h
-#include linux

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

2012-03-17 Thread Kyungmin Park 
Hi,

On 3/17/12, Aneesh V ane...@ti.com 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 santosh.shilim...@ti.com
 were immensely helpful in shaping up the interfaces. Vibhore Vardhan
 vvard...@gmail.com 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 g...@kroah.com

 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 o...@wizery.com 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/iommu/Kconfig                              |   32 +++
  drivers/iommu/Makefile                             |    5 +
  drivers/{base = iommu}/iommu.c                    |    0
  .../mach-msm/iommu.c = drivers/iommu/msm-iommu.c  |    0
  .../iommu/omap-iommu-debug.c                       |    2 +-
  .../iommu.c = drivers/iommu/omap-iommu.c          |  290 
 +---
  .../iovmm.c = drivers/iommu/omap-iovmm.c

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 a...@arndb.de wrote:
 On Monday 18 April 2011, Kyungmin Park wrote:
 On Mon, Apr 18, 2011 at 8:58 PM, Arnd Bergmann a...@arndb.de 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-19 Thread Kyungmin Park 
On Tue, Apr 19, 2011 at 9:01 PM, Arnd Bergmann a...@arndb.de wrote:
 On Tuesday 19 April 2011, Kyungmin Park wrote:
 On Mon, Apr 18, 2011 at 11:13 PM, Arnd Bergmann a...@arndb.de wrote:
  On Monday 18 April 2011, Kyungmin Park wrote:
  On Mon, Apr 18, 2011 at 8:58 PM, Arnd Bergmann a...@arndb.de 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 zpfef...@codeaurora.org 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-18 Thread Kyungmin Park 
On Mon, Apr 18, 2011 at 8:58 PM, Arnd Bergmann a...@arndb.de wrote:
 On Monday 18 April 2011, Tony Lindgren wrote:
 * Arnd Bergmann a...@arndb.de [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 grgu...@ti.com
   
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
artem.bityuts...@nokia.com 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 eballe...@gmail.com

 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 s-gho...@ti.com 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 s-gho...@ti.com
  ---
   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 
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 kyungmin.p...@samsung.com
  Cc: Tomi Valkeinen tomi.valkei...@nokia.com
  Signed-off-by: Tony Lindgren t...@atomide.com
  ---
   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: [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 t...@atomide.com wrote:
 * Kyungmin Park kyungmin.p...@samsung.com [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: 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
eballe...@gmail.com wrote:
 Hi,

 2010/5/6 Kyungmin Park kyungmin.p...@samsung.com:
 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

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 Dammmagnus.d...@gmail.com wrote:
 From: Magnus Damm d...@igel.co.jp

 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 d...@igel.co.jp
 ---

  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 linux/mtd/mtd.h
  #include linux/mtd/onenand.h
  #include linux/mtd/partitions.h
 -
  #include asm/io.h
 -#include asm/mach/flash.h
 -
 -#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);
        if (err  0)
                add_mtd_partitions(info-mtd, info-parts, err);
 -       else if (err = 0  pdata-parts)
 +       else if (err = 0  pdata  pdata-parts)
                add_mtd_partitions(info-mtd, pdata-parts, pdata-nr_parts);
        else
  #endif
 @@ -99,7 +103,7 @@ static int __devexit generic_onenand_rem
  {
        struct onenand_info *info = platform_get_drvdata(pdev);
        struct resource *res = pdev-resource;
 -       unsigned long size = res-end - res-start + 1;
 +       unsigned long size = resource_size

Re: Embedded Linux Conference

2009-03-16 Thread Kyungmin Park 
Hi,

On Tue, Mar 17, 2009 at 7:56 AM, Tony Lindgren t...@atomide.com wrote:
 * Kevin Hilman khil...@deeprootsystems.com [090316 15:52]:
 Hans Verkuil hverk...@xs4all.nl 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
ext-adrian.hun...@nokia.com wrote:
 ext Kim Kyuwon wrote:
 Hi,

 On Sat, Feb 21, 2009 at 6:11 AM, David Brownell davi...@pacbell.net 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 davi...@pacbell.net 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 kyungmin.p...@samsung.com
---
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 t...@atomide.com wrote:
 * Russell King - ARM Linux li...@arm.linux.org.uk [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 davi...@pacbell.net wrote:
 On Tuesday 27 January 2009, Tony Lindgren wrote:
 * Russell King - ARM Linux li...@arm.linux.org.uk [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 kyungmin.p...@samsung.com
---
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.
 [c00309e8] (dump_stack+0x0/0x14) from [c0170c40] (kobject_init+0x40/0x78)
 [c0170c00] (kobject_init+0x0/0x78) from [c017116c]
 (kobject_init_and_add+0x20/0x44)
  r5:c795b20c r4:c7b9c4b8
 [c0171150] (kobject_init_and_add+0x4/0x44) from [c0167e10]
 (blk_register_filter+0x48/0x60)
  r5:c7926400 r4:c795ada0
 [c0167dc8] (blk_register_filter+0x0/0x60) from [c0166d3c]
 (add_disk+0x60/0xb8)
  r4:c7b9c400
 [c0166cdc] (add_disk+0x0/0xb8) from [c01f9bf4]
 (add_mtd_blktrans_dev+0x24c/0x284)
  r5:c7926400 r4:0001
 [c01f99a8] (add_mtd_blktrans_dev+0x0/0x284) from [c01fa1c4]
 (mtdblock_add_mtd+0x58/0x60)
  r8:0008 r7:c0432a44 r6:001e r5:c0448588 r4:c7bea300
 [c01fa16c] (mtdblock_add_mtd+0x0/0x60) from [c01f97a4]
 (blktrans_notify_add+0x30/0x60)
  r5:c7bea300 r4:c0448588
 [c01f9774] (blktrans_notify_add+0x0/0x60) from [c01f5be8]
 (add_mtd_device+0xb0/0x110)
  r5:c7bea300 r4:c0448550
 [c01f5b38] (add_mtd_device+0x0/0x110) from [c01f6fd4]
 (add_mtd_partitions+0x480/0x52c)
  r5:c7bdaa10 r4:c7bea300
 [c01f6b54] (add_mtd_partitions+0x0/0x52c) from [c03390e0]
 (omap2_onenand_probe+0x360/0x438)
 [c0338d80] (omap2_onenand_probe+0x0/0x438) from [c01b738c]
 (platform_drv_probe+0x20/0x24)
  r8:c0445d20 r7:c04488d4 r6:c04488d4 r5:c0432754 r4:c04326a8
 [c01b736c] (platform_drv_probe+0x0/0x24) from [c01b662c]
 (driver_probe_device+0xd0/0x17c)
 [c01b655c] (driver_probe_device+0x0/0x17c) from [c01b6724]
 (__driver_attach+0x4c/0x70)
  r7:c04488d4 r6:c04488d4 r5:c0432754 r4:c04326a8
 [c01b66d8] (__driver_attach+0x0/0x70) from [c01b5cac]
 (bus_for_each_dev+0x4c/0x84)
  r7:c04488d4 r6:c01b66d8 r5:c7825eb4 r4:
 [c01b5c60] (bus_for_each_dev+0x0/0x84) from [c01b6474]
 (driver_attach+0x20/0x28)
  r7:c7927de0 r6: r5:c04488d4 r4:
 [c01b6454] (driver_attach+0x0/0x28) from [c01b6130]
 (bus_add_driver+0xa4/0x210)
 [c01b608c] (bus_add_driver+0x0/0x210) from [c01b6918]
 (driver_register+0x98/0x120)
  r8: r7: r6: r5:c04488d4 r4:c0455e80
 [c01b6880] (driver_register+0x0/0x120) from [c01b7724]
 (platform_driver_register+0x78/0x94)
 [c01b76ac] (platform_driver_register+0x0/0x94) from [c001de5c]
 (omap2_onenand_init+0x1c/0x28)
 [c001de40] (omap2_onenand_init+0x0/0x28) from [c002c298]
 (__exception_text_end+0x50/0x17c)
 [c002c248] (__exception_text_end+0x0/0x17c) from [c0008734]
 (kernel_init+0x70/0xdc)
 [c00086c4] (kernel_init+0x0/0xdc) from [c004ecec] (do_exit+0x0/0x6e8)
  r5: r4:
 0x0026-0x0028 : params
 kobject (c795b20c): tried to init an initialized object, something is
 seriously wrong.
 [c00309e8] (dump_stack+0x0/0x14) from [c0170c40] (kobject_init+0x40/0x78)
 [c0170c00] (kobject_init+0x0/0x78) from [c017116c]
 (kobject_init_and_add+0x20/0x44)
  r5:c795b20c r4:c7b9ccb8
 [c0171150] (kobject_init_and_add+0x4/0x44) from [c0167e10]
 (blk_register_filter+0x48/0x60)
  r5:c7926b40 r4:c795ada0
 [c0167dc8] (blk_register_filter+0x0/0x60) from [c0166d3c]
 (add_disk+0x60/0xb8)
  r4:c7b9cc00
 [c0166cdc] (add_disk+0x0/0xb8) from [c01f9bf4]
 (add_mtd_blktrans_dev+0x24c/0x284)
  r5:c7926b40 r4:0002
 [c01f99a8] (add_mtd_blktrans_dev+0x0/0x284) from [c01fa1c4]
 (mtdblock_add_mtd+0x58/0x60)
  r8:0026 r7:c0432a5c r6:0002 r5:c0448588 r4:c7bea400
 [c01fa16c] (mtdblock_add_mtd+0x0/0x60) from [c01f97a4]
 (blktrans_notify_add+0x30/0x60)
  r5:c7bea400 r4:c0448588
 [c01f9774] (blktrans_notify_add+0x0/0x60) from [c01f5be8]
 (add_mtd_device+0xb0/0x110)
  r5:c7bea400 r4:c0448550
 [c01f5b38] (add_mtd_device+0x0/0x110) from [c01f6fd4]
 (add_mtd_partitions+0x480/0x52c)
  r5:c7bdaa10 r4:c7bea400
 [c01f6b54] (add_mtd_partitions+0x0/0x52c) from [c03390e0]
 (omap2_onenand_probe+0x360/0x438)
 [c0338d80] (omap2_onenand_probe+0x0/0x438) from [c01b738c]
 (platform_drv_probe+0x20/0x24)
  r8:c0445d20 r7:c04488d4 r6:c04488d4 r5:c0432754 r4:c04326a8
 [c01b736c] (platform_drv_probe+0x0/0x24) from [c01b662c]
 (driver_probe_device+0xd0/0x17c)
 [c01b655c] (driver_probe_device+0x0/0x17c) from [c01b6724]
 (__driver_attach+0x4c/0x70)
  r7:c04488d4 r6:c04488d4 r5:c0432754 r4:c04326a8
 [c01b66d8] (__driver_attach+0x0/0x70) from [c01b5cac]
 (bus_for_each_dev+0x4c/0x84)
  r7

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

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: 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

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

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