[PATCH v2 0/2] Move sdhci-s3c platform helper into driver

2011-09-14 Thread Thomas Abraham
Changes since v1:
- Rebased with 'for-next' branch of
  http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
  (tested with commit id a08b7e19811181309da2306338027fe1d3f8001d at the
  tip of the for-next branch, not sure if there have been further
  commits after that).

The platform helper that sets up the default sdhci-s3c controller
configuration can be removed and moved into the sdhci-s3c driver.
This platform helper is removed for s3c2416, s3c64xx, s5pc100,
s5pv210 and Exynos4 platforms.

Since the platform helper function pointer was being passed in the
platform data of sdhci-s3c driver, the removal of this pointer from
the platform data is step closer to complete device tree support for
sdhci-s3c driver.

This patchset has been tested on the following platforms.
SMDK2416, SMDK6410, SMDKC100, SMDKV210 and SMDKV310.

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 2/2] arm: samsung: remove sdhci default configuration setup platform helper

2011-09-14 Thread Thomas Abraham
The sdhci platform helper function that sets up the default controller
configuration is removed for all Samsung platforms since such default
controller configuration can be handled by the driver.

Cc: Ben Dooks ben-li...@fluff.org
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
 arch/arm/mach-exynos4/setup-sdhci.c|   47 ---
 arch/arm/mach-s3c2416/setup-sdhci.c|   37 --
 arch/arm/mach-s3c64xx/setup-sdhci.c|   48 ---
 arch/arm/mach-s5pc100/setup-sdhci.c|   42 
 arch/arm/mach-s5pv210/setup-sdhci.c|   41 
 arch/arm/plat-samsung/include/plat/sdhci.h |   57 
 arch/arm/plat-samsung/platformdata.c   |2 -
 7 files changed, 0 insertions(+), 274 deletions(-)

diff --git a/arch/arm/mach-exynos4/setup-sdhci.c 
b/arch/arm/mach-exynos4/setup-sdhci.c
index 1e83f8c..92937b4 100644
--- a/arch/arm/mach-exynos4/setup-sdhci.c
+++ b/arch/arm/mach-exynos4/setup-sdhci.c
@@ -10,16 +10,7 @@
  * published by the Free Software Foundation.
 */
 
-#include linux/kernel.h
 #include linux/types.h
-#include linux/interrupt.h
-#include linux/platform_device.h
-#include linux/io.h
-
-#include linux/mmc/card.h
-#include linux/mmc/host.h
-
-#include plat/regs-sdhci.h
 
 /* clock sources for the mmc bus clock, order as for the ctrl2[5..4] */
 
@@ -29,41 +20,3 @@ char *exynos4_hsmmc_clksrcs[4] = {
[2] = sclk_mmc,   /* mmc_bus */
[3] = NULL,
 };
-
-void exynos4_setup_sdhci_cfg_card(struct platform_device *dev, void __iomem *r,
- struct mmc_ios *ios, struct mmc_card *card)
-{
-   u32 ctrl2, ctrl3;
-
-   /* don't need to alter anything according to card-type */
-
-   ctrl2 = readl(r + S3C_SDHCI_CONTROL2);
-
-   /* select base clock source to HCLK */
-
-   ctrl2 = S3C_SDHCI_CTRL2_SELBASECLK_MASK;
-
-   /*
-* clear async mode, enable conflict mask, rx feedback ctrl, SD
-* clk hold and no use debounce count
-*/
-
-   ctrl2 |= (S3C64XX_SDHCI_CTRL2_ENSTAASYNCCLR |
- S3C64XX_SDHCI_CTRL2_ENCMDCNFMSK |
- S3C_SDHCI_CTRL2_ENFBCLKRX |
- S3C_SDHCI_CTRL2_DFCNT_NONE |
- S3C_SDHCI_CTRL2_ENCLKOUTHOLD);
-
-   /* Tx and Rx feedback clock delay control */
-
-   if (ios-clock  25 * 100)
-   ctrl3 = (S3C_SDHCI_CTRL3_FCSEL3 |
-S3C_SDHCI_CTRL3_FCSEL2 |
-S3C_SDHCI_CTRL3_FCSEL1 |
-S3C_SDHCI_CTRL3_FCSEL0);
-   else
-   ctrl3 = (S3C_SDHCI_CTRL3_FCSEL1 | S3C_SDHCI_CTRL3_FCSEL0);
-
-   writel(ctrl2, r + S3C_SDHCI_CONTROL2);
-   writel(ctrl3, r + S3C_SDHCI_CONTROL3);
-}
diff --git a/arch/arm/mach-s3c2416/setup-sdhci.c 
b/arch/arm/mach-s3c2416/setup-sdhci.c
index ed34fad..cee5395 100644
--- a/arch/arm/mach-s3c2416/setup-sdhci.c
+++ b/arch/arm/mach-s3c2416/setup-sdhci.c
@@ -12,17 +12,7 @@
  * published by the Free Software Foundation.
 */
 
-#include linux/kernel.h
 #include linux/types.h
-#include linux/interrupt.h
-#include linux/platform_device.h
-#include linux/io.h
-
-#include linux/mmc/card.h
-#include linux/mmc/host.h
-
-#include plat/regs-sdhci.h
-#include plat/sdhci.h
 
 /* clock sources for the mmc bus clock, order as for the ctrl2[5..4] */
 
@@ -32,30 +22,3 @@ char *s3c2416_hsmmc_clksrcs[4] = {
[2] = hsmmc-if,
/* [3] = 48m, - note not successfully used yet */
 };
-
-void s3c2416_setup_sdhci_cfg_card(struct platform_device *dev,
- void __iomem *r,
- struct mmc_ios *ios,
- struct mmc_card *card)
-{
-   u32 ctrl2, ctrl3;
-
-   ctrl2 = __raw_readl(r + S3C_SDHCI_CONTROL2);
-   ctrl2 = S3C_SDHCI_CTRL2_SELBASECLK_MASK;
-   ctrl2 |= (S3C64XX_SDHCI_CTRL2_ENSTAASYNCCLR |
- S3C64XX_SDHCI_CTRL2_ENCMDCNFMSK |
- S3C_SDHCI_CTRL2_ENFBCLKRX |
- S3C_SDHCI_CTRL2_DFCNT_NONE |
- S3C_SDHCI_CTRL2_ENCLKOUTHOLD);
-
-   if (ios-clock  25 * 100)
-   ctrl3 = (S3C_SDHCI_CTRL3_FCSEL3 |
-S3C_SDHCI_CTRL3_FCSEL2 |
-S3C_SDHCI_CTRL3_FCSEL1 |
-S3C_SDHCI_CTRL3_FCSEL0);
-   else
-   ctrl3 = (S3C_SDHCI_CTRL3_FCSEL1 | S3C_SDHCI_CTRL3_FCSEL0);
-
-   __raw_writel(ctrl2, r + S3C_SDHCI_CONTROL2);
-   __raw_writel(ctrl3, r + S3C_SDHCI_CONTROL3);
-}
diff --git a/arch/arm/mach-s3c64xx/setup-sdhci.c 
b/arch/arm/mach-s3c64xx/setup-sdhci.c
index f344a22..c75a71b 100644
--- a/arch/arm/mach-s3c64xx/setup-sdhci.c
+++ b/arch/arm/mach-s3c64xx/setup-sdhci.c
@@ -12,17 +12,7 @@
  * published by the Free Software Foundation.
 */
 
-#include linux/kernel.h
 #include linux/types.h
-#include linux/interrupt.h
-#include linux/platform_device.h
-#include linux/io.h

[PATCH V1] mmc: core: eMMC 4.5 Power Class Selection Feature

2011-09-14 Thread Girish K S
This patch adds the power class selection feature available
for mmc versions 4.0 and above.
During the enumeration stage before switching to the lower
data bus, check if the power class is supported for the
current bus width. If the power class is available then
switch to the power class and use the higher data bus. If
power class is not supported then switch to the lower data
bus in a worst case.

Signed-off-by: Girish K S girish.shivananja...@linaro.org
---
 drivers/mmc/core/mmc.c  |   90 +++
 include/linux/mmc/mmc.h |   13 +++
 2 files changed, 103 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 63cc77b..bc3d942 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -536,6 +536,81 @@ static struct device_type mmc_type = {
 };
 
 /*
+ * Select the PowerClass for the current bus width
+ * If power class is defined for 4/8 bit bus in the
+ * extended CSD register, select it by executing the
+ * mmc_switch command.
+ */
+static int mmc_select_powerclass(struct mmc_card *card,
+   unsigned int bus_width, u8 *ext_csd)
+{
+   int err = 0;
+   unsigned int pwrclass_val;
+   unsigned int index = 0;
+   struct mmc_host *host = card-host;
+
+   BUG_ON(!card);
+   BUG_ON(!host);
+
+   if (ext_csd == NULL)
+   return 0;
+   /* Power class selection is supported for versions = 4.0 */
+   if (card-csd.mmca_vsn  CSD_SPEC_VER_4)
+   return 0;
+   /*Power class values are defined only for 4/8 bit bus*/
+   if (bus_width == EXT_CSD_BUS_WIDTH_1)
+   return 0;
+
+   switch ((1  host-ios.vdd)) {
+   case MMC_VDD_165_195:
+   if (host-ios.clock = 2600)
+   index = EXT_CSD_PWR_CL_26_195;
+   else if (host-ios.clock = 5200)
+   index = (bus_width = EXT_CSD_BUS_WIDTH_8) ?
+   EXT_CSD_PWR_CL_52_195 :
+   EXT_CSD_PWR_CL_DDR_52_195;
+   else if (host-ios.clock = 2)
+   index = EXT_CSD_PWR_CL_200_195;
+   break;
+   case MMC_VDD_32_33:
+   case MMC_VDD_33_34:
+   case MMC_VDD_34_35:
+   case MMC_VDD_35_36:
+   if (host-ios.clock = 2600)
+   index = EXT_CSD_PWR_CL_26_360;
+   else if (host-ios.clock = 5200)
+   index = (bus_width = EXT_CSD_BUS_WIDTH_8) ?
+   EXT_CSD_PWR_CL_52_360 :
+   EXT_CSD_PWR_CL_DDR_52_360;
+   else if (host-ios.clock = 2)
+   index = EXT_CSD_PWR_CL_200_360;
+   break;
+   default:
+   BUG();
+   break;
+   }
+
+   pwrclass_val = ext_csd[index];
+
+   if (bus_width  (EXT_CSD_BUS_WIDTH_8 | EXT_CSD_DDR_BUS_WIDTH_8))
+   pwrclass_val = (pwrclass_val  EXT_CSD_PWR_CL_8BIT_MASK) 
+   EXT_CSD_PWR_CL_8BIT_SHIFT;
+   else
+   pwrclass_val = (pwrclass_val  EXT_CSD_PWR_CL_4BIT_MASK) 
+   EXT_CSD_PWR_CL_4BIT_SHIFT;
+
+   /*If the power class is different from the default value*/
+   if (pwrclass_val  0) {
+   err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+   EXT_CSD_POWER_CLASS,
+   pwrclass_val,
+   0);
+   }
+
+   return err;
+}
+
+/*
  * Handle the detection and initialisation of a card.
  *
  * In the case of a resume, oldcard will contain the card
@@ -802,6 +877,13 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
bus_width = bus_widths[idx];
if (bus_width == MMC_BUS_WIDTH_1)
ddr = 0; /* no DDR for 1-bit width */
+   err = mmc_select_powerclass(card, ext_csd_bits[idx][0],
+   ext_csd);
+   if (err)
+   printk(KERN_ERR %s: power class selection to 
+   bus width %d 
failed\n,mmc_hostname(card-host),
+   1  bus_width);
+
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
 EXT_CSD_BUS_WIDTH,
 ext_csd_bits[idx][0],
@@ -825,6 +907,14 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
}
 
if (!err  ddr) {
+   err = mmc_select_powerclass(card, ext_csd_bits[idx][1],
+   ext_csd);
+   if (err)
+   printk(KERN_ERR %s: power class selection to 
+

[PATCH V1] Power Class Selection Feature

2011-09-14 Thread Girish K S
This patch version modifies the power_class_select function prototype.

During device enumeration, when the host tries to read the extended
csd register after switching to higher bus width, the read fails at
higher bus width. So the power_class_select function is modified to
reuse the extended csd register values read with 1 bit bus width. 

Girish K S (1):
  mmc: core: eMMC 4.5 Power Class Selection Feature

 drivers/mmc/core/mmc.c  |   90 +++
 include/linux/mmc/mmc.h |   13 +++
 2 files changed, 103 insertions(+), 0 deletions(-)

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v8 00/16] To use DMA generic APIs for Samsung DMA

2011-09-14 Thread Vinod Koul
On Wed, 2011-09-14 at 12:00 +0530, Jassi Brar wrote:
 On Wed, Sep 14, 2011 at 11:31 AM, Vinod Koul vinod.k...@intel.com wrote:
  On Fri, 2011-09-02 at 09:44 +0900, Boojin Kim wrote:
  This patchset adds support DMA generic APIs for samsung DMA.
 
  The changes from V7 is following:
  - Divides patch file.
: The 03 patch on V7 patchset is divided into the 03 and 04 patch on V8 
  patchset.
  The O3 patch is only for DMA_SLAVE_CONFIG command.
  The 04 patch is only for DMA_TERMINATE_ALL command.
  - Code clean-up
: Remove unnecessary code on 05 patch.
 
  [PATCH v8 01/16] DMA: PL330: Add support runtime PM for PL330 DMAC
  [PATCH v8 02/16] DMA: PL330: Update PL330 DMA API driver
  [PATCH v8 03/16] DMA: PL330: Support DMA_SLAVE_CONFIG command
  [PATCH v8 04/16] DMA: PL330: Remove the start operation for handling 
  DMA_TERMINATE_ALL command
  [PATCH v8 05/16] DMA: PL330: Add DMA_CYCLIC capability
  [PATCH v8 06/16] ARM: SAMSUNG: Update to use PL330-DMA driver
  [PATCH v8 07/16] ARM: SAMSUNG: Add common DMA operations
  [PATCH v8 08/16] ARM: EXYNOS4: Use generic DMA PL330 driver
  [PATCH v8 09/16] ARM: S5PV210: Use generic DMA PL330 driver
  [PATCH v8 10/16] ARM: S5PC100: Use generic DMA PL330 driver
  [PATCH v8 11/16] ARM: S5P64X0: Use generic DMA PL330 driver
  [PATCH v8 12/16] ARM: SAMSUNG: Remove S3C-PL330-DMA driver
  [PATCH v8 13/16] spi/s3c64xx: Add support DMA engine API
  [PATCH v8 14/16] spi/s3c64xx: Merge dma control code
  [PATCH v8 15/16] ASoC: Samsung: Update DMA interface
  [PATCH v8 16/16] ARM: SAMSUNG: Remove Samsung specific enum type for dma 
  direction
  Thanks,
 
  I have pushed these into my samsung-dma branch, Fixed the typos in the
  changelog of patch 4.
 
  Please check and let me know if all are fine, I will push them to my
  next tomorrow
 
  If anyone has concerns on this series please let me know by tomorrow
 
 
 I have no concern about patches modifying samsung specific code.
 
 Of the patches touching common pl330 code, I had acked Patch-1,2,3  5
 in previous revisions already. So for them, you may add my
  Acked-by: Jassi Brar jassisinghb...@gmail.com
Ok
 
 The changelog for [PATCH v8 04/16] is misleading - we don't need any
 modification for the reason mentioned in changelog. But the modification
 has positive side-effect of preventing callbacks during terminate_all which
 is no way understood from the changelog. So I would like to changelog
 corrected.
I thought change log was correct in depicting what patch does and Boojin
had replied I will check again...

-- 
~Vinod

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH v8 00/16] To use DMA generic APIs for Samsung DMA

2011-09-14 Thread Kukjin Kim
Vinod Koul wrote:
 
 On Fri, 2011-09-02 at 09:44 +0900, Boojin Kim wrote:
  This patchset adds support DMA generic APIs for samsung DMA.
 
  The changes from V7 is following:
  - Divides patch file.
: The 03 patch on V7 patchset is divided into the 03 and 04 patch on V8
 patchset.
  The O3 patch is only for DMA_SLAVE_CONFIG command.
  The 04 patch is only for DMA_TERMINATE_ALL command.
  - Code clean-up
: Remove unnecessary code on 05 patch.
 
  [PATCH v8 01/16] DMA: PL330: Add support runtime PM for PL330 DMAC
  [PATCH v8 02/16] DMA: PL330: Update PL330 DMA API driver
  [PATCH v8 03/16] DMA: PL330: Support DMA_SLAVE_CONFIG command
  [PATCH v8 04/16] DMA: PL330: Remove the start operation for handling
 DMA_TERMINATE_ALL command
  [PATCH v8 05/16] DMA: PL330: Add DMA_CYCLIC capability
  [PATCH v8 06/16] ARM: SAMSUNG: Update to use PL330-DMA driver
  [PATCH v8 07/16] ARM: SAMSUNG: Add common DMA operations
  [PATCH v8 08/16] ARM: EXYNOS4: Use generic DMA PL330 driver
  [PATCH v8 09/16] ARM: S5PV210: Use generic DMA PL330 driver
  [PATCH v8 10/16] ARM: S5PC100: Use generic DMA PL330 driver
  [PATCH v8 11/16] ARM: S5P64X0: Use generic DMA PL330 driver
  [PATCH v8 12/16] ARM: SAMSUNG: Remove S3C-PL330-DMA driver
  [PATCH v8 13/16] spi/s3c64xx: Add support DMA engine API
  [PATCH v8 14/16] spi/s3c64xx: Merge dma control code
  [PATCH v8 15/16] ASoC: Samsung: Update DMA interface
  [PATCH v8 16/16] ARM: SAMSUNG: Remove Samsung specific enum type for
 dma direction
 Thanks,
 
 I have pushed these into my samsung-dma branch, Fixed the typos in the
 changelog of patch 4.
 
 Please check and let me know if all are fine, I will push them to my
 next tomorrow
 
Hi Vinod,

Thanks for your applying.

When you push them to your next, I will merge samsung-dma branch to my -next to 
avoid conflicts.

If any problems, please let me know.

 If anyone has concerns on this series please let me know by tomorrow

Thanks again.

Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v8 00/16] To use DMA generic APIs for Samsung DMA

2011-09-14 Thread Jassi Brar
On 14 September 2011 16:47, Vinod Koul vinod.k...@intel.com wrote:

 The changelog for [PATCH v8 04/16] is misleading - we don't need any
 modification for the reason mentioned in changelog. But the modification
 has positive side-effect of preventing callbacks during terminate_all which
 is no way understood from the changelog. So I would like to changelog
 corrected.
 I thought change log was correct in depicting what patch does and Boojin
 had replied I will check again...

I didn't reply because I ran out of ways to explain the same thing in
different words.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] ARM: EXYNOS4: Add machine support for 7 LCD on ORIGEN

2011-09-14 Thread Fabio Estevam
On Wed, Sep 14, 2011 at 8:01 AM, Tushar Behera tushar.beh...@linaro.org wrote:
...
 +static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, unsigned int 
 power)
 +{
 +       int gpio = EXYNOS4_GPE3(4);
 +
 +       gpio_request(gpio, GPE3_4);
 +       gpio_direction_output(gpio, power);

You should check for returned errors for these functions.

Regards,

Fabio Estevam
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 2/2] ARM: Exynos4: use s5p-timer for UniversalC210 board

2011-09-14 Thread Kukjin Kim
Kyungmin Park wrote:
 
 Hi,
 
 It's required for boot universal c210 w/ EVT0 chip.
 Can you include it at 3.1 fixed branch?
 
Sure, will apply into samsung-fixes for 3.1.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

 Thank you,
 Kyungmin Park
 
 On Tue, Jul 26, 2011 at 2:50 PM, Marek Szyprowski
 m.szyprow...@samsung.com wrote:
  Commit 069d4e743 removed support for local timers and forced to use MCT
as
  event source. However MCT is not operating properly on early revision
(EVT0)
  of Exynos4 SoCs. All UniversalC210 boards are based on Exynos4 EVT0, so
 that
  commit broke support for it. This patch provides a workaround that
enables
  UniversalC210 boards to boot again. s5p-timer is used as an event
source.
 
  Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
  ---
   arch/arm/mach-exynos4/Kconfig               |    3 +++
   arch/arm/mach-exynos4/mach-universal_c210.c |    4 +++-
   2 files changed, 6 insertions(+), 1 deletions(-)
 
  diff --git a/arch/arm/mach-exynos4/Kconfig
b/arch/arm/mach-exynos4/Kconfig
  index 9d62e13..2aad73f 100644
  --- a/arch/arm/mach-exynos4/Kconfig
  +++ b/arch/arm/mach-exynos4/Kconfig
  @@ -173,6 +173,9 @@ config MACH_ARMLEX4210
   config MACH_UNIVERSAL_C210
         bool Mobile UNIVERSAL_C210 Board
         select CPU_EXYNOS4210
  +       select S5P_HRT
  +       select CLKSRC_MMIO
  +       select HAVE_SCHED_CLOCK
         select S5P_GPIO_INT
         select S5P_DEV_FIMC0
         select S5P_DEV_FIMC1
  diff --git a/arch/arm/mach-exynos4/mach-universal_c210.c
b/arch/arm/mach-
 exynos4/mach-universal_c210.c
  index 0e280d1..ca9e7b7 100644
  --- a/arch/arm/mach-exynos4/mach-universal_c210.c
  +++ b/arch/arm/mach-exynos4/mach-universal_c210.c
  @@ -34,6 +34,7 @@
   #include plat/mfc.h
   #include plat/sdhci.h
   #include plat/pd.h
  +#include plat/s5p-time.h
 
   #include mach/map.h
 
  @@ -730,6 +731,7 @@ static void __init universal_map_io(void)
         s5p_init_io(NULL, 0, S5P_VA_CHIPID);
         s3c24xx_init_clocks(2400);
         s3c24xx_init_uarts(universal_uartcfgs,
ARRAY_SIZE(universal_uartcfgs));
  +       s5p_set_timer_source(S5P_PWM2, S5P_PWM4);
   }
 
   static void __init universal_reserve(void)
  @@ -766,6 +768,6 @@ MACHINE_START(UNIVERSAL_C210,
 UNIVERSAL_C210)
         .init_irq       = exynos4_init_irq,
         .map_io         = universal_map_io,
         .init_machine   = universal_machine_init,
  -       .timer          = exynos4_timer,
  +       .timer          = s5p_timer,
         .reserve        = universal_reserve,
   MACHINE_END
  --
  1.7.1.569.g6f426
 
  --
  To unsubscribe from this list: send the line unsubscribe
linux-samsung-soc 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-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] ARM: EXYNOS4: Add machine support for 7 LCD on ORIGEN

2011-09-14 Thread Tushar Behera

Hi Fabio,

On Wednesday 14 September 2011 05:06 PM, Fabio Estevam wrote:

On Wed, Sep 14, 2011 at 8:01 AM, Tushar Beheratushar.beh...@linaro.org  wrote:
...

+static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, unsigned int 
power)
+{
+   int gpio = EXYNOS4_GPE3(4);
+
+   gpio_request(gpio, GPE3_4);
+   gpio_direction_output(gpio, power);


You should check for returned errors for these functions.


Ok.

Will this be better?

static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, \
unsigned int power)
{
int ret;
unsigned long flag = power ? GPIOF_OUT_INIT_HIGH : \
GPIOF_OUT_INIT_LOW;

ret = gpio_request_one(EXYNOS4_GPE3(4), flag, GPE3_4);

if (ret)
printk(KERN_ERR Could not request gpio for LCD power);
}


Regards,

Fabio Estevam



--
Tushar Behera
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH] ARM: EXYNOS4: convert boot_params to atag_offset

2011-09-14 Thread Kukjin Kim
Tushar Behera wrote:
 
 Based on ARM: introduce atag_offset to replace boot_params
 by Nicolas Pitre (2bb9839e312ed55a6d5824ffa6077ce3d7d63b1e).
 
 Since boot_params variable is deleted from machine_desc, the variable
 is modified in the newer board files.
 
 CC: Nicolas Pitre nicolas.pi...@linaro.org
 Signed-off-by: Tushar Behera tushar.beh...@linaro.org
 ---
 This is required when Kukjin's for-next branch is merged with
 Russell's devel-stable branch.
 
 Nicolas's patchset already has changes for other EXYNSO4 based boards.
 
  arch/arm/mach-exynos4/mach-origen.c   |2 +-
  arch/arm/mach-exynos4/mach-smdk4212.c |2 +-
  arch/arm/mach-exynos4/mach-smdkv310.c |2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-
 origen.c
 index ed59f86..b5f6f38 100644
 --- a/arch/arm/mach-exynos4/mach-origen.c
 +++ b/arch/arm/mach-exynos4/mach-origen.c
 @@ -100,7 +100,7 @@ static void __init origen_machine_init(void)
 
  MACHINE_START(ORIGEN, ORIGEN)
   /* Maintainer: JeongHyeon Kim jh...@insignal.co.kr */
 - .boot_params= S5P_PA_SDRAM + 0x100,
 + .atag_offset= 0x100,
   .init_irq   = exynos4_init_irq,
   .map_io = origen_map_io,
   .init_machine   = origen_machine_init,
 diff --git a/arch/arm/mach-exynos4/mach-smdk4212.c b/arch/arm/mach-
 exynos4/mach-smdk4212.c
 index 3479a93..8c41ae1 100644
 --- a/arch/arm/mach-exynos4/mach-smdk4212.c
 +++ b/arch/arm/mach-exynos4/mach-smdk4212.c
 @@ -284,7 +284,7 @@ static void __init smdk4212_machine_init(void)
 
  MACHINE_START(SMDK4212, SMDK4212)
   /* Maintainer: Kukjin Kim kgene@samsung.com */
 - .boot_params= S5P_PA_SDRAM + 0x100,
 + .atag_offset= 0x100,
   .init_irq   = exynos4_init_irq,
   .map_io = smdk4212_map_io,
   .init_machine   = smdk4212_machine_init,
 diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-
 exynos4/mach-smdkv310.c
 index 57cf632..7ce4d8b 100644
 --- a/arch/arm/mach-exynos4/mach-smdkv310.c
 +++ b/arch/arm/mach-exynos4/mach-smdkv310.c
 @@ -344,7 +344,7 @@ MACHINE_END
 
  MACHINE_START(SMDKC210, SMDKC210)
   /* Maintainer: Kukjin Kim kgene@samsung.com */
 - .boot_params= S5P_PA_SDRAM + 0x100,
 + .atag_offset= 0x100,
   .init_irq   = exynos4_init_irq,
   .map_io = smdkv310_map_io,
   .init_machine   = smdkv310_machine_init,
 --
 1.7.4.1

Hi Tushar,

Yes you're right and actually, I received the same information from Stephen
when he merges my -next the end of last month.

Anyway, if above fixing is required on my -next, will apply this.

Thanks :)

Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH V4 5/6] ARM: S5P6440: Add LCD-LTE480 and enable Framebuffer support

2011-09-14 Thread Kukjin Kim
Ajay Kumar wrote:
 
 This patch:
   -- Adds platform device support for LCD-LTE480.
   -- Adds platform data for FB with win_mode and default_bpp.
   -- Enables FB device support and platform-lcd support.
   -- Adds SPCON settings for LCD.
 
 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 ---
  arch/arm/mach-s5p64x0/Kconfig  |2 +
  arch/arm/mach-s5p64x0/include/mach/regs-gpio.h |4 +
  arch/arm/mach-s5p64x0/mach-smdk6440.c  |   75
 
  3 files changed, 81 insertions(+), 0 deletions(-)
 

(snip)

 +#include plat/regs-fb.h

Should be plat/regs-fb-v4.h?

(snip)

 +/* Frame Buffer */
 +static struct s3c_fb_pd_win smdk6440_fb_win0 = {
 + .win_mode = {
 + .left_margin= 8,
 + .right_margin   = 13,
 + .upper_margin   = 7,
 + .lower_margin   = 5,
 + .hsync_len  = 3,
 + .vsync_len  = 1,
 + .xres   = 800,
 + .yres   = 480,
 + .refresh= 60,

if its value is 60, we don't need .refresh here.

(snip)


Thanks.

Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] input: samsung-keypad: Add device tree support

2011-09-14 Thread Grant Likely
On Tue, Sep 13, 2011 at 05:56:19PM +0530, Thomas Abraham wrote:
 Add device tree based discovery support for Samsung's keypad controller.
 
 Cc: Joonyoung Shim jy0922.s...@samsung.com
 Cc: Donghwa Lee dh09@samsung.com
 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 ---
  .../devicetree/bindings/input/samsung-keypad.txt   |   88 ++
  drivers/input/keyboard/samsung-keypad.c|  177 
 ++--
  2 files changed, 253 insertions(+), 12 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/input/samsung-keypad.txt
 
 diff --git a/Documentation/devicetree/bindings/input/samsung-keypad.txt 
 b/Documentation/devicetree/bindings/input/samsung-keypad.txt
 new file mode 100644
 index 000..e1c7237
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/input/samsung-keypad.txt
 @@ -0,0 +1,88 @@
 +* Samsung's Keypad Controller device tree bindings
 +
 +Samsung's Keypad controller is used to interface a SoC with a matrix-type
 +keypad device. The keypad controller supports multiple row and column lines.
 +A key can be placed at each intersection of a unique row and a unique column.
 +The keypad controller can sense a key-press and key-release and report the
 +event using a interrupt to the cpu.
 +
 +Required SoC Specific Properties:
 +- compatible: should be one of the following
 +  - samsung,s3c6410-keypad: For controllers compatible with s3c6410 keypad
 +controller.
 +  - samsung,s5pv210-keypad: For controllers compatible with s5pv210 keypad
 +controller.
 +
 +- reg: physical base address of the controller and length of memory mapped
 +  region.
 +
 +- interrupts: The interrupt number to the cpu.
 +
 +Required Board Specific Properties:
 +- samsung,keypad-num-rows: Number of row lines connected to the keypad
 +  controller.
 +
 +- samsung,keypad-num-columns: Number of column lines connected to the
 +  keypad controller.
 +
 +- row-gpios: List of gpios used as row lines. The gpio specifier for
 +  this property depends on the gpio controller to which these row lines
 +  are connected.
 +
 +- col-gpios: List of gpios used as column lines. The gpio specifier for
 +  this property depends on the gpio controller to which these column
 +  lines are connected.

I know we've got overlapping terminology here.  When you say GPIOs
here, does it refer to the pin multiplexing feature of the samsung
parts, and thus how the keypad controller IO is routed to the pins?
Or does the driver manipulate GPIO lines manually?

If it is pin multiplexing, then using the GPIO binding seems rather
odd. It may be entirely appropriate, but it will need to play well
with the pinmux stuff that linusw is working on.

 +
 +- Keys represented as child nodes: Each key connected to the keypad
 +  controller is represented as a child node to the keypad controller
 +  device node and should include the following properties.
 +  - keypad,row: the row number to which the key is connected.
 +  - keypad,column: the column number to which the key is connected.
 +  - keypad,key-code: the key-code to be reported when the key is pressed
 +and released.

What defines the meanings of the key codes?

 +
 +Optional Properties specific to linux:
 +- linux,keypad-no-autorepeat: do no enable autorepeat feature.
 +- linux,keypad-wakeup: use any event on keypad as wakeup event.

Is this really a linux-specific feature?

 +
 +
 +Example:
 + keypad@100A {
 + compatible = samsung,s5pv210-keypad;
 + reg = 0x100A 0x100;
 + interrupts = 173;
 + samsung,keypad-num-rows = 2;
 + samsung,keypad-num-columns = 8;
 + linux,input-no-autorepeat;
 + linux,input-wakeup;
 +
 + row-gpios = gpx2 0 3 3 0
 +  gpx2 1 3 3 0;
 +
 + col-gpios = gpx1 0 3 0 0
 +  gpx1 1 3 0 0
 +  gpx1 2 3 0 0
 +  gpx1 3 3 0 0
 +  gpx1 4 3 0 0
 +  gpx1 5 3 0 0
 +  gpx1 6 3 0 0
 +  gpx1 7 3 0 0;
 +
 + key_1 {
 + keypad,row = 0;
 + keypad,column = 3;
 + keypad,key-code = 2;
 + };
 +
 + key_2 {
 + keypad,row = 0;
 + keypad,column = 4;
 + keypad,key-code = 3;
 + };
 +
 + key_3 {
 + keypad,row = 0;
 + keypad,column = 5;
 + keypad,key-code = 4;
 + };
 + };
 diff --git a/drivers/input/keyboard/samsung-keypad.c 
 b/drivers/input/keyboard/samsung-keypad.c
 index f689f49..cf01a56 100644
 --- a/drivers/input/keyboard/samsung-keypad.c
 +++ b/drivers/input/keyboard/samsung-keypad.c
 @@ -21,6 +21,8 @@
  #include linux/module.h
  #include linux/platform_device.h
  #include linux/slab.h
 +#include 

Re: [PATCH v3 4/6] DMA: PL330: Add device tree support

2011-09-14 Thread Grant Likely
On Mon, Sep 12, 2011 at 11:59:23PM +0530, Thomas Abraham wrote:
 For PL330 dma controllers instantiated from device tree, the channel
 lookup is based on phandle of the dma controller and dma request id
 specified by the client node. During probe, the private data of each
 channel of the controller is set to point to the device node of the
 dma controller. The 'chan_id' of the each channel is used as the
 dma request id.
 
 Client driver requesting dma channels specify the phandle of the
 dma controller and the request id. The pl330 filter function
 converts the phandle to the device node pointer and matches that
 with channel's private data. If a match is found, the request id
 from the client node and the 'chan_id' of the channel is matched.
 A channel is found if both the values match.
 
 Cc: Jassi Brar jassisinghb...@gmail.com
 Cc: Boojin Kim boojin@samsung.com
 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 Reviewed-by: Rob Herring rob.herr...@calxeda.com
 ---
  .../devicetree/bindings/dma/arm-pl330.txt  |   29 +
  drivers/dma/pl330.c|   33 +--
  2 files changed, 58 insertions(+), 4 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/dma/arm-pl330.txt
 
 diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt 
 b/Documentation/devicetree/bindings/dma/arm-pl330.txt
 new file mode 100644
 index 000..05b007d
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
 @@ -0,0 +1,29 @@
 +* ARM PrimeCell PL330 DMA Controller
 +
 +The ARM PrimeCell PL330 DMA controller can move blocks of memory contents
 +between memory and peripherals or memory to memory.
 +
 +Required properties:
 +  - compatible: should include both arm,pl330 and arm,primecell.
 +  - reg: physical base address of the controller and length of memory mapped
 +region.
 +  - interrupts: interrupt number to the cpu.
 +
 +Example: (from Samsung's Exynos4 processor dtsi file)
 +
 + pdma0: pdma@1268 {
 + compatible = arm,pl330, arm,primecell;
 + reg = 0x1268 0x1000;
 + interrupts = 99;
 + };
 +
 +Client drivers (device nodes requiring dma transfers from dev-to-mem or
 +mem-to-dev) should specify the DMA channel numbers using a two-value pair
 +as shown below.
 +
 +  [property name]  = [phandle of the dma controller] [dma request id];
 +
 +  where 'dma request id' is the dma request number which is connected
 +  to the client controller.
 +
 +  Example:  tx-dma-channel = pdma0 12;

Looks good to me.  You may want to specify that the property name
should be in the form: name-dma-channel just to enforce a bit of
convention on the users.

 diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
 index 992bf82..7a4ebf1 100644
 --- a/drivers/dma/pl330.c
 +++ b/drivers/dma/pl330.c
 @@ -19,6 +19,7 @@
  #include linux/amba/pl330.h
  #include linux/pm_runtime.h
  #include linux/scatterlist.h
 +#include linux/of.h
  
  #define NR_DEFAULT_DESC  16
  
 @@ -277,6 +278,20 @@ bool pl330_filter(struct dma_chan *chan, void *param)
   if (chan-device-dev-driver != pl330_driver.drv)
   return false;
  
 +#ifdef CONFIG_OF
 + if (chan-device-dev-of_node) {
 + const __be32 *prop_value;
 + phandle phandle;
 + struct device_node *node;
 +
 + prop_value = ((struct property *)param)-value;
 + phandle = be32_to_cpup(prop_value++);
 + node = of_find_node_by_phandle(phandle);
 + return ((chan-private == node) 
 + (chan-chan_id == be32_to_cpup(prop_value)));

Don't open code this.  There is already a function to decode a phandle
property.  of_parse_phandle() should do the trick.

Otherwise looks good to me.

g.

 + }
 +#endif
 +
   peri_id = chan-private;
   return *peri_id == (unsigned)param;
  }
 @@ -855,12 +870,17 @@ pl330_probe(struct amba_device *adev, const struct 
 amba_id *id)
   INIT_LIST_HEAD(pd-channels);
  
   /* Initialize channel parameters */
 - num_chan = max(pdat ? pdat-nr_valid_peri : 0, (u8)pi-pcfg.num_chan);
 + num_chan = max(pdat ? pdat-nr_valid_peri : (u8)pi-pcfg.num_peri,
 + (u8)pi-pcfg.num_chan);
   pdmac-peripherals = kzalloc(num_chan * sizeof(*pch), GFP_KERNEL);
  
   for (i = 0; i  num_chan; i++) {
   pch = pdmac-peripherals[i];
 - pch-chan.private = pdat ? pdat-peri_id[i] : NULL;
 + if (!adev-dev.of_node)
 + pch-chan.private = pdat ? pdat-peri_id[i] : NULL;
 + else
 + pch-chan.private = adev-dev.of_node;
 +
   INIT_LIST_HEAD(pch-work_list);
   spin_lock_init(pch-lock);
   pch-pl330_chid = NULL;
 @@ -874,10 +894,15 @@ pl330_probe(struct amba_device *adev, const struct 
 amba_id *id)
   }
  
   pd-dev = adev-dev;
 - if (pdat)
 + if 

Re: [PATCH v3 6/6] ARM: EXYNOS4: Limit usage of pl330 device instance to non-dt build

2011-09-14 Thread Grant Likely
On Mon, Sep 12, 2011 at 11:59:25PM +0530, Thomas Abraham wrote:
 The pl330 device instances and associated platform data is required only
 for non-device-tree builds. With device tree enabled, the data about the
 platform is obtained from the device tree. For images that include both
 dt and non-dt platforms, an addditional check is added to ensure that
 static amba device registrations is applicable to only non-dt platforms.
 
 Cc: Kukjin Kim kgene@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 ---
 diff --git a/arch/arm/mach-exynos4/dma.c b/arch/arm/mach-exynos4/dma.c
 index c3c0d17..3203a31 100644
 --- a/arch/arm/mach-exynos4/dma.c
 +++ b/arch/arm/mach-exynos4/dma.c
 @@ -24,6 +24,7 @@
  #include linux/dma-mapping.h
  #include linux/amba/bus.h
  #include linux/amba/pl330.h
 +#include linux/of.h
  
  #include asm/irq.h
  #include plat/devs.h
 @@ -138,6 +139,11 @@ struct amba_device exynos4_device_pdma1 = {
  
  static int __init exynos4_dma_init(void)
  {
 +#ifdef CONFIG_OF
 + if (of_have_populated_dt())
 + return 0;
 +#endif
 +

Drop the #ifdef.  of_have_populated_dt() has an empty stub for
!CONFIG_OF.  Otherwise looks good to me.  Well done not breaking
non-DT support when CONFIG_OF is enabled.  :-)

The other patches in this series look good to me too.

g.

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] input: samsung-keypad: Add device tree support

2011-09-14 Thread Grant Likely
On Wed, Sep 14, 2011 at 10:19:22PM +0530, Thomas Abraham wrote:
 Hi Grant,
 
 On 14 September 2011 21:41, Grant Likely grant.lik...@secretlab.ca wrote:
  On Tue, Sep 13, 2011 at 05:56:19PM +0530, Thomas Abraham wrote:
  Add device tree based discovery support for Samsung's keypad controller.
 
  Cc: Joonyoung Shim jy0922.s...@samsung.com
  Cc: Donghwa Lee dh09@samsung.com
  Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
  ---
   .../devicetree/bindings/input/samsung-keypad.txt   |   88 ++
   drivers/input/keyboard/samsung-keypad.c            |  177 
  ++--
   2 files changed, 253 insertions(+), 12 deletions(-)
   create mode 100644 
  Documentation/devicetree/bindings/input/samsung-keypad.txt
 
  diff --git a/Documentation/devicetree/bindings/input/samsung-keypad.txt 
  b/Documentation/devicetree/bindings/input/samsung-keypad.txt
  new file mode 100644
  index 000..e1c7237
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/input/samsung-keypad.txt
  @@ -0,0 +1,88 @@
  +* Samsung's Keypad Controller device tree bindings
  +
  +Samsung's Keypad controller is used to interface a SoC with a matrix-type
  +keypad device. The keypad controller supports multiple row and column 
  lines.
  +A key can be placed at each intersection of a unique row and a unique 
  column.
  +The keypad controller can sense a key-press and key-release and report the
  +event using a interrupt to the cpu.
  +
  +Required SoC Specific Properties:
  +- compatible: should be one of the following
  +  - samsung,s3c6410-keypad: For controllers compatible with s3c6410 
  keypad
  +    controller.
  +  - samsung,s5pv210-keypad: For controllers compatible with s5pv210 
  keypad
  +    controller.
  +
  +- reg: physical base address of the controller and length of memory mapped
  +  region.
  +
  +- interrupts: The interrupt number to the cpu.
  +
  +Required Board Specific Properties:
  +- samsung,keypad-num-rows: Number of row lines connected to the keypad
  +  controller.
  +
  +- samsung,keypad-num-columns: Number of column lines connected to the
  +  keypad controller.
  +
  +- row-gpios: List of gpios used as row lines. The gpio specifier for
  +  this property depends on the gpio controller to which these row lines
  +  are connected.
  +
  +- col-gpios: List of gpios used as column lines. The gpio specifier for
  +  this property depends on the gpio controller to which these column
  +  lines are connected.
 
  I know we've got overlapping terminology here.  When you say GPIOs
  here, does it refer to the pin multiplexing feature of the samsung
  parts, and thus how the keypad controller IO is routed to the pins?
  Or does the driver manipulate GPIO lines manually?
 
 It is intended to mean gpio and not the pinmux. But the way the gpio
 specifier is specified in the dts file, it includes information about
 both gpio number and the pin-control details. For instance, if 'gpa0'
 is a gpio controller (which includes pin-control functionality as well
 in the hardware), then the gpio specifier for the keypad would be as
 below.
 
 row-gpios = gpa0 0 3 3 0,
  gpa0 1 3 3 0;
 
 The syntax for the gpio specifier is
 [phandle of gpio controller] [pin number within the gpio controller]
 [mux function] [pull up/down] [drive strength]
 
 The keypad driver does not know or use the mux function, pull up/down
 and drive strength details. The driver would call of_get_gpio to get
 the linux gpio number and then do a gpio_request on that gpio number.
 The gpio dt support manges the pin-mux and other settings
 transparently for the keypad driver. So even though the gpio specifier
 format changes, the dt support code for the driver does not change.
 
 The driver does not manipulate the gpios directly. It just requests
 for the gpio number and makes a note of the number to free it when the
 driver unbinds.
 
 
  If it is pin multiplexing, then using the GPIO binding seems rather
  odd. It may be entirely appropriate, but it will need to play well
  with the pinmux stuff that linusw is working on.
 
 When pinmux/pin-ctrl functionality which linusw is developing is used
 for this driver, it would be a extension to this patch. The driver
 would request for the gpio and then use the pin-ctrl subsystem api to
 setup the pin-control. In that case, the gpio-specifier would change
 but that change would be break anything which this patch does.
 
 
  +
  +- Keys represented as child nodes: Each key connected to the keypad
  +  controller is represented as a child node to the keypad controller
  +  device node and should include the following properties.
  +  - keypad,row: the row number to which the key is connected.
  +  - keypad,column: the column number to which the key is connected.
  +  - keypad,key-code: the key-code to be reported when the key is pressed
  +    and released.
 
  What defines the meanings of the key codes?
 
 The key-code could be any value which the system would want the keypad
 

Re: [PATCH v3 4/6] DMA: PL330: Add device tree support

2011-09-14 Thread Thomas Abraham
Hi Grant,

On 14 September 2011 21:54, Grant Likely grant.lik...@secretlab.ca wrote:
 On Mon, Sep 12, 2011 at 11:59:23PM +0530, Thomas Abraham wrote:
 For PL330 dma controllers instantiated from device tree, the channel
 lookup is based on phandle of the dma controller and dma request id
 specified by the client node. During probe, the private data of each
 channel of the controller is set to point to the device node of the
 dma controller. The 'chan_id' of the each channel is used as the
 dma request id.

 Client driver requesting dma channels specify the phandle of the
 dma controller and the request id. The pl330 filter function
 converts the phandle to the device node pointer and matches that
 with channel's private data. If a match is found, the request id
 from the client node and the 'chan_id' of the channel is matched.
 A channel is found if both the values match.

 Cc: Jassi Brar jassisinghb...@gmail.com
 Cc: Boojin Kim boojin@samsung.com
 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 Reviewed-by: Rob Herring rob.herr...@calxeda.com
 ---
  .../devicetree/bindings/dma/arm-pl330.txt          |   29 +
  drivers/dma/pl330.c                                |   33 
 +--
  2 files changed, 58 insertions(+), 4 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/dma/arm-pl330.txt

 diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt 
 b/Documentation/devicetree/bindings/dma/arm-pl330.txt
 new file mode 100644
 index 000..05b007d
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
 @@ -0,0 +1,29 @@
 +* ARM PrimeCell PL330 DMA Controller
 +
 +The ARM PrimeCell PL330 DMA controller can move blocks of memory contents
 +between memory and peripherals or memory to memory.
 +
 +Required properties:
 +  - compatible: should include both arm,pl330 and arm,primecell.
 +  - reg: physical base address of the controller and length of memory mapped
 +    region.
 +  - interrupts: interrupt number to the cpu.
 +
 +Example: (from Samsung's Exynos4 processor dtsi file)
 +
 +     pdma0: pdma@1268 {
 +             compatible = arm,pl330, arm,primecell;
 +             reg = 0x1268 0x1000;
 +             interrupts = 99;
 +     };
 +
 +Client drivers (device nodes requiring dma transfers from dev-to-mem or
 +mem-to-dev) should specify the DMA channel numbers using a two-value pair
 +as shown below.
 +
 +  [property name]  = [phandle of the dma controller] [dma request id];
 +
 +      where 'dma request id' is the dma request number which is connected
 +      to the client controller.
 +
 +  Example:  tx-dma-channel = pdma0 12;

 Looks good to me.  You may want to specify that the property name
 should be in the form: name-dma-channel just to enforce a bit of
 convention on the users.

Ok. This will be added as a suggestion for property name specifying
the dma channel.


 diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
 index 992bf82..7a4ebf1 100644
 --- a/drivers/dma/pl330.c
 +++ b/drivers/dma/pl330.c
 @@ -19,6 +19,7 @@
  #include linux/amba/pl330.h
  #include linux/pm_runtime.h
  #include linux/scatterlist.h
 +#include linux/of.h

  #define NR_DEFAULT_DESC      16

 @@ -277,6 +278,20 @@ bool pl330_filter(struct dma_chan *chan, void *param)
       if (chan-device-dev-driver != pl330_driver.drv)
               return false;

 +#ifdef CONFIG_OF
 +     if (chan-device-dev-of_node) {
 +             const __be32 *prop_value;
 +             phandle phandle;
 +             struct device_node *node;
 +
 +             prop_value = ((struct property *)param)-value;
 +             phandle = be32_to_cpup(prop_value++);
 +             node = of_find_node_by_phandle(phandle);
 +             return ((chan-private == node) 
 +                             (chan-chan_id == be32_to_cpup(prop_value)));

 Don't open code this.  There is already a function to decode a phandle
 property.  of_parse_phandle() should do the trick.

The parameter to this function 'void *param' is already pointing to a
'struct property'. That 'struct property' has a value of type
[phandle of dma controller] [channel id].

Since the property is already known, the of_get_property() call within
the of_parse_phandle() would complicate the above code. And,
of_parse_phandle requires a 'property name' inside the dma client
device node, which the above code fragment does not know about
(property names are defined by client drivers).

So, I would prefer to continue with the above implementation.


 Otherwise looks good to me.

 g.


Thanks for your review.

Regards,
Thomas.

[...]
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] input: samsung-keypad: Add device tree support

2011-09-14 Thread Thomas Abraham
Hi Grant,

On 14 September 2011 22:43, Grant Likely grant.lik...@secretlab.ca wrote:
 On Wed, Sep 14, 2011 at 10:19:22PM +0530, Thomas Abraham wrote:
 Hi Grant,

 On 14 September 2011 21:41, Grant Likely grant.lik...@secretlab.ca wrote:
  On Tue, Sep 13, 2011 at 05:56:19PM +0530, Thomas Abraham wrote:
  Add device tree based discovery support for Samsung's keypad controller.
 
  Cc: Joonyoung Shim jy0922.s...@samsung.com
  Cc: Donghwa Lee dh09@samsung.com
  Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
  ---
   .../devicetree/bindings/input/samsung-keypad.txt   |   88 ++
   drivers/input/keyboard/samsung-keypad.c            |  177 
  ++--
   2 files changed, 253 insertions(+), 12 deletions(-)
   create mode 100644 
  Documentation/devicetree/bindings/input/samsung-keypad.txt
 

[...]

  +- Keys represented as child nodes: Each key connected to the keypad
  +  controller is represented as a child node to the keypad controller
  +  device node and should include the following properties.
  +  - keypad,row: the row number to which the key is connected.
  +  - keypad,column: the column number to which the key is connected.
  +  - keypad,key-code: the key-code to be reported when the key is pressed
  +    and released.
 
  What defines the meanings of the key codes?

 The key-code could be any value which the system would want the keypad
 driver to report when that key is pressed.

 Are they linux keycodes?  If so, then this property name can
 probably be linux,code.  There is already precedence for that
 usage in Documentation/devicetree/bindings/gpio/gpio-keys.txt.  (I
 would personally prefer linux,key-code, but sometimes it is better
 to go with existing precidence) You could also use linux,input-type as
 specified in that binding.

Ok. For linux, keypad,key-code would mean linux keycodes. The
property name 'keypad,key-code' was chosen since it can be reused on
non-linux platforms as well. I did have a look at
Documentation/devicetree/bindings/gpio/gpio-keys.txt while doing this,
but preferred using 'keypad,key-code' since it would be generic. Given
a choice, I would like to retain this.



 
  +
  +Optional Properties specific to linux:
  +- linux,keypad-no-autorepeat: do no enable autorepeat feature.
  +- linux,keypad-wakeup: use any event on keypad as wakeup event.
 
  Is this really a linux-specific feature?

 Yes, it is a property defined by the linux subsystems. A non-linux
 system might not have such features.

 I was specifically referring to the wakeup property, but okay, I can
 see the argument that it is linux-specific because it is usage-policy
 related.

 g.

Thanks for your review.

Regards,
Thomas.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] input: samsung-keypad: Add device tree support

2011-09-14 Thread Grant Likely
On Wed, Sep 14, 2011 at 12:09 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
 On 14 September 2011 22:43, Grant Likely grant.lik...@secretlab.ca wrote:
 On Wed, Sep 14, 2011 at 10:19:22PM +0530, Thomas Abraham wrote:
 On 14 September 2011 21:41, Grant Likely grant.lik...@secretlab.ca wrote:
  On Tue, Sep 13, 2011 at 05:56:19PM +0530, Thomas Abraham wrote:
  +- Keys represented as child nodes: Each key connected to the keypad
  +  controller is represented as a child node to the keypad controller
  +  device node and should include the following properties.
  +  - keypad,row: the row number to which the key is connected.
  +  - keypad,column: the column number to which the key is connected.
  +  - keypad,key-code: the key-code to be reported when the key is pressed
  +    and released.
 
  What defines the meanings of the key codes?

 The key-code could be any value which the system would want the keypad
 driver to report when that key is pressed.

 Are they linux keycodes?  If so, then this property name can
 probably be linux,code.  There is already precedence for that
 usage in Documentation/devicetree/bindings/gpio/gpio-keys.txt.  (I
 would personally prefer linux,key-code, but sometimes it is better
 to go with existing precidence) You could also use linux,input-type as
 specified in that binding.

 Ok. For linux, keypad,key-code would mean linux keycodes. The
 property name 'keypad,key-code' was chosen since it can be reused on
 non-linux platforms as well. I did have a look at
 Documentation/devicetree/bindings/gpio/gpio-keys.txt while doing this,
 but preferred using 'keypad,key-code' since it would be generic. Given
 a choice, I would like to retain this.

This was debated a bit on the gpio-keys binding.  The binding *must*
specify where it is getting the keycodes from.  For the gpio-keys
binding, it was decided that the Linux keycodes were sufficient since
they are exported to userspace, and therefore part of the stable
kernel ABI (they will never change).  keypad,key-code is completely
useless as a generic binding since it doesn't specify where the
keycode meanings come from.  Besides, linux,code can be reused on
non-linux platforms too, it just means that the authoritative source
of the keycodes is the Linux kernel.

g
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V4 RESEND 1/6] video: s3c-fb: Add S5P64X0 specific s3c_fb_driverdata

2011-09-14 Thread Florian Tobias Schandinat
On 09/09/2011 06:00 PM, Ajay Kumar wrote:
 This patch:
   -- Adds s3c_fb_driverdata for S5P64X0, which supports 3 windows.
   -- Also, register s5p64x0-fb type driver_data.
 
 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 Acked-by: Jingoo Han jg1@samsung.com
 Acked-by: Kukjin Kim kgene@samsung.com

Applied.


Thanks,

Florian Tobias Schandinat

 ---
  drivers/video/s3c-fb.c |   27 +++
  1 files changed, 27 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
 index 4aecf21..0fda252 100644
 --- a/drivers/video/s3c-fb.c
 +++ b/drivers/video/s3c-fb.c
 @@ -1859,6 +1859,30 @@ static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
   },
  };
  
 +static struct s3c_fb_driverdata s3c_fb_data_s5p64x0 = {
 + .variant = {
 + .nr_windows = 3,
 + .vidtcon= VIDTCON0,
 + .wincon = WINCON(0),
 + .winmap = WINxMAP(0),
 + .keycon = WKEYCON,
 + .osd= VIDOSD_BASE,
 + .osd_stride = 16,
 + .buf_start  = VIDW_BUF_START(0),
 + .buf_size   = VIDW_BUF_SIZE(0),
 + .buf_end= VIDW_BUF_END(0),
 +
 + .palette = {
 + [0] = 0x2400,
 + [1] = 0x2800,
 + [2] = 0x2c00,
 + },
 + },
 + .win[0] = s3c_fb_data_s5p_wins[0],
 + .win[1] = s3c_fb_data_s5p_wins[1],
 + .win[2] = s3c_fb_data_s5p_wins[2],
 +};
 +
  static struct platform_device_id s3c_fb_driver_ids[] = {
   {
   .name   = s3c-fb,
 @@ -1872,6 +1896,9 @@ static struct platform_device_id s3c_fb_driver_ids[] = {
   }, {
   .name   = s3c2443-fb,
   .driver_data= (unsigned long)s3c_fb_data_s3c2443,
 + }, {
 + .name   = s5p64x0-fb,
 + .driver_data= (unsigned long)s3c_fb_data_s5p64x0,
   },
   {},
  };

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] input: samsung-keypad: Add device tree support

2011-09-14 Thread Thomas Abraham
On 15 September 2011 00:40, Grant Likely grant.lik...@secretlab.ca wrote:
 On Wed, Sep 14, 2011 at 12:09 PM, Thomas Abraham
 thomas.abra...@linaro.org wrote:
 On 14 September 2011 22:43, Grant Likely grant.lik...@secretlab.ca wrote:
 On Wed, Sep 14, 2011 at 10:19:22PM +0530, Thomas Abraham wrote:
 On 14 September 2011 21:41, Grant Likely grant.lik...@secretlab.ca wrote:
  On Tue, Sep 13, 2011 at 05:56:19PM +0530, Thomas Abraham wrote:
  +- Keys represented as child nodes: Each key connected to the keypad
  +  controller is represented as a child node to the keypad controller
  +  device node and should include the following properties.
  +  - keypad,row: the row number to which the key is connected.
  +  - keypad,column: the column number to which the key is connected.
  +  - keypad,key-code: the key-code to be reported when the key is 
  pressed
  +    and released.
 
  What defines the meanings of the key codes?

 The key-code could be any value which the system would want the keypad
 driver to report when that key is pressed.

 Are they linux keycodes?  If so, then this property name can
 probably be linux,code.  There is already precedence for that
 usage in Documentation/devicetree/bindings/gpio/gpio-keys.txt.  (I
 would personally prefer linux,key-code, but sometimes it is better
 to go with existing precidence) You could also use linux,input-type as
 specified in that binding.

 Ok. For linux, keypad,key-code would mean linux keycodes. The
 property name 'keypad,key-code' was chosen since it can be reused on
 non-linux platforms as well. I did have a look at
 Documentation/devicetree/bindings/gpio/gpio-keys.txt while doing this,
 but preferred using 'keypad,key-code' since it would be generic. Given
 a choice, I would like to retain this.

 This was debated a bit on the gpio-keys binding.  The binding *must*
 specify where it is getting the keycodes from.  For the gpio-keys
 binding, it was decided that the Linux keycodes were sufficient since
 they are exported to userspace, and therefore part of the stable
 kernel ABI (they will never change).  keypad,key-code is completely
 useless as a generic binding since it doesn't specify where the
 keycode meanings come from.  Besides, linux,code can be reused on
 non-linux platforms too, it just means that the authoritative source
 of the keycodes is the Linux kernel.

 g


Ok. I understand this now. I will change this to linux,code in the
next submission.

Thanks,
Thomas.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 0/2] Add device tree support for Samsung's I2C driver

2011-09-14 Thread Thomas Abraham
Hi Ben,

On 15 September 2011 02:43, Ben Dooks ben-...@fluff.org wrote:
 On Tue, Sep 13, 2011 at 09:46:03AM +0530, Thomas Abraham wrote:
 This patchset adds device tree support for Samsung's I2C driver.

 I've applied these after a brief review. I'll give them a better
 review before the weekend.

Thanks for your review.

Regards,
Thomas.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] ARM: EXYNOS4: Add keypad support for Origen

2011-09-14 Thread Sachin Kamat
This patch adds keypad support for Origen board as GPIO keys.

Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
 arch/arm/mach-exynos4/mach-origen.c |   58 +++
 1 files changed, 58 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos4/mach-origen.c 
b/arch/arm/mach-exynos4/mach-origen.c
index ed59f86..61da36b 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -14,6 +14,7 @@
 #include linux/platform_device.h
 #include linux/io.h
 #include linux/input.h
+#include linux/gpio_keys.h
 
 #include asm/mach/arch.h
 #include asm/mach-types.h
@@ -79,10 +80,67 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata 
__initdata = {
.clk_type   = S3C_SDHCI_CLK_DIV_EXTERNAL,
 };
 
+static struct gpio_keys_button origen_gpio_keys_table[] = {
+   {
+   .code = KEY_MENU,
+   .gpio = EXYNOS4_GPX1(5),
+   .desc = gpio-keys: KEY_MENU,
+   .type = EV_KEY,
+   .active_low = 1,
+   .wakeup = 1,
+   .debounce_interval = 1,
+   }, {
+   .code = KEY_HOME,
+   .gpio = EXYNOS4_GPX1(6),
+   .desc = gpio-keys: KEY_HOME,
+   .type = EV_KEY,
+   .active_low = 1,
+   .wakeup = 1,
+   .debounce_interval = 1,
+   }, {
+   .code = KEY_BACK,
+   .gpio = EXYNOS4_GPX1(7),
+   .desc = gpio-keys: KEY_BACK,
+   .type = EV_KEY,
+   .active_low = 1,
+   .wakeup = 1,
+   .debounce_interval = 1,
+   }, {
+   .code = KEY_UP,
+   .gpio = EXYNOS4_GPX2(0),
+   .desc = gpio-keys: KEY_UP,
+   .type = EV_KEY,
+   .active_low = 1,
+   .wakeup = 1,
+   .debounce_interval = 1,
+   }, {
+   .code = KEY_DOWN,
+   .gpio = EXYNOS4_GPX2(1),
+   .desc = gpio-keys: KEY_DOWN,
+   .type = EV_KEY,
+   .active_low = 1,
+   .wakeup = 1,
+   .debounce_interval = 1,
+   },
+};
+
+static struct gpio_keys_platform_data origen_gpio_keys_data = {
+   .buttons = origen_gpio_keys_table,
+   .nbuttons = ARRAY_SIZE(origen_gpio_keys_table),
+};
+
+static struct platform_device origen_device_gpiokeys = {
+   .name = gpio-keys,
+   .dev = {
+   .platform_data = origen_gpio_keys_data,
+   },
+};
+
 static struct platform_device *origen_devices[] __initdata = {
s3c_device_hsmmc2,
s3c_device_rtc,
s3c_device_wdt,
+   origen_device_gpiokeys,
 };
 
 static void __init origen_map_io(void)
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V3] ARM: EXYNOS4: Add machine support for 7 LCD on ORIGEN

2011-09-14 Thread Tushar Behera
ORIGEN board is fitted with 7 LCD panel HV070WSA. The pixel
resolution of the LCD panel is 1024x600.

Also power domain device for LCD0 is registered.

Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
Changes for V3:
* Added error check for gpio request in LCD power function
Changes for V2:
* Added power domain device registration for LCD0

The patch is rebased on [1]. For proper working of LCD on ORIGEN,
following patches are needed. These patches are already submitted to
the mailing list.

a. ARM: EXYNOS4: Add PWM backlight support on Origen
Author: Giridhar Maruthy
b. ARM: EXYNOS4: Configure MAX8997 PMIC for Origen
Author: Inderpal Singh

[1] git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git 
(for-next)

 arch/arm/mach-exynos4/Kconfig   |3 ++
 arch/arm/mach-exynos4/mach-origen.c |   54 +++
 2 files changed, 57 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 48f18f7..4f28871 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -222,6 +222,9 @@ config MACH_ORIGEN
select S3C_DEV_RTC
select S3C_DEV_WDT
select S3C_DEV_HSMMC2
+   select S5P_DEV_FIMD0
+   select EXYNOS4_DEV_PD
+   select EXYNOS4_SETUP_FIMD0
select EXYNOS4_SETUP_SDHCI
help
  Machine support for ORIGEN based on Samsung EXYNOS4210
diff --git a/arch/arm/mach-exynos4/mach-origen.c 
b/arch/arm/mach-exynos4/mach-origen.c
index ed59f86..0dcd527 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -14,16 +14,22 @@
 #include linux/platform_device.h
 #include linux/io.h
 #include linux/input.h
+#include linux/lcd.h
+
+#include video/platform_lcd.h
 
 #include asm/mach/arch.h
 #include asm/mach-types.h
 
 #include plat/regs-serial.h
+#include plat/regs-fb-v4.h
 #include plat/exynos4.h
 #include plat/cpu.h
 #include plat/devs.h
 #include plat/sdhci.h
 #include plat/iic.h
+#include plat/pd.h
+#include plat/fb.h
 
 #include mach/map.h
 
@@ -79,10 +85,56 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata 
__initdata = {
.clk_type   = S3C_SDHCI_CLK_DIV_EXTERNAL,
 };
 
+static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, unsigned int 
power)
+{
+   int ret;
+   unsigned long flag = power ? GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;
+
+   ret = gpio_request_one(EXYNOS4_GPE3(4), flag, GPE3_4);
+   if (ret)
+   pr_err(Could not request gpio line for LCD power.\n);
+}
+
+static struct plat_lcd_data origen_lcd_hv070wsa_data = {
+   .set_power = lcd_hv070wsa_set_power,
+};
+
+static struct platform_device origen_lcd_hv070wsa = {
+   .name   = platform-lcd,
+   .dev.parent = s5p_device_fimd0.dev,
+   .dev.platform_data  = origen_lcd_hv070wsa_data,
+};
+
+static struct s3c_fb_pd_win origen_fb_win0 = {
+   .win_mode = {
+   .left_margin= 64,
+   .right_margin   = 16,
+   .upper_margin   = 64,
+   .lower_margin   = 16,
+   .hsync_len  = 48,
+   .vsync_len  = 3,
+   .xres   = 1024,
+   .yres   = 600,
+   .refresh= 60,
+   },
+   .max_bpp= 32,
+   .default_bpp= 24,
+};
+
+static struct s3c_fb_platdata origen_lcd_pdata __initdata = {
+   .win[0] = origen_fb_win0,
+   .vidcon0= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
+   .vidcon1= VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
+   .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
+};
+
 static struct platform_device *origen_devices[] __initdata = {
+   exynos4_device_pd[PD_LCD0],
s3c_device_hsmmc2,
s3c_device_rtc,
s3c_device_wdt,
+   s5p_device_fimd0,
+   origen_lcd_hv070wsa,
 };
 
 static void __init origen_map_io(void)
@@ -95,7 +147,9 @@ static void __init origen_map_io(void)
 static void __init origen_machine_init(void)
 {
s3c_sdhci2_set_platdata(origen_hsmmc2_pdata);
+   s5p_fimd0_set_platdata(origen_lcd_pdata);
platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices));
+   s5p_device_fimd0.dev.parent = exynos4_device_pd[PD_LCD0].dev;
 }
 
 MACHINE_START(ORIGEN, ORIGEN)
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH V2] ARM: EXYNOS4: Add machine support for 7 LCD on ORIGEN

2011-09-14 Thread Kukjin Kim
Tushar Behera wrote:
 
 ORIGEN board is fitted with 7 LCD panel HV070WSA. The pixel
 resolution of the LCD panel is 1024x600.
 
 Also power domain device for LCD0 is registered.
 
 Signed-off-by: Tushar Behera tushar.beh...@linaro.org
 ---
 Changes for V2:
   * Added power domain device registration for LCD0
 
 The patch is rebased on [1]. For proper working of LCD on ORIGEN,
 following patches are needed. These patches are already submitted to
 the mailing list.
 
 a. ARM: EXYNOS4: Add PWM backlight support on Origen
   Author: Giridhar Maruthy

As I said, it is already in my tree.

 b. ARM: EXYNOS4: Configure MAX8997 PMIC for Origen
   Author: Inderpal Singh

Will review it.

(snip)

 +
 +static struct s3c_fb_pd_win origen_fb_win0 = {
 + .win_mode = {
 + .left_margin= 64,
 + .right_margin   = 16,
 + .upper_margin   = 64,
 + .lower_margin   = 16,
 + .hsync_len  = 48,
 + .vsync_len  = 3,
 + .xres   = 1024,
 + .yres   = 600,
 + .refresh= 60,

We don't need to add '.refresh' here because its default value is 60.

 + },
 + .max_bpp= 32,
 + .default_bpp= 24,
 +};

Thanks.

Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH V2] ARM: EXYNOS4: Add machine support for 7 LCD on ORIGEN

2011-09-14 Thread Kukjin Kim
Tushar Behera wrote:
 
 Hi Fabio,
 
 On Wednesday 14 September 2011 05:06 PM, Fabio Estevam wrote:
  On Wed, Sep 14, 2011 at 8:01 AM, Tushar Beheratushar.beh...@linaro.org
 wrote:
  ...
  +static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, unsigned int
 power)
  +{
  +   int gpio = EXYNOS4_GPE3(4);
  +
  +   gpio_request(gpio, GPE3_4);
  +   gpio_direction_output(gpio, power);
 
  You should check for returned errors for these functions.
 
 Ok.
 
 Will this be better?
 
 static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, \

No need '\'

   unsigned int power)
 {
   int ret;
   unsigned long flag = power ? GPIOF_OUT_INIT_HIGH : \

Same as above.

   GPIOF_OUT_INIT_LOW;
 
   ret = gpio_request_one(EXYNOS4_GPE3(4), flag, GPE3_4);
 
   if (ret)
   printk(KERN_ERR Could not request gpio for LCD power);
 }

How about following?

if (power)
ret = gpio_request_one(EXYNOS4_GPE3(4), GPIOF_OUT_INIT_HIGH, 
GPE3_4);
else
ret = gpio_request_one(EXYNOS4_GPE3(4), GPIOF_OUT_INIT_LOW, 
GPE3_4);

if (ret)
pr_err(failed to request gpio for LCD power: %d\n, ret);

Thanks.

Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH] arm: exynos4: fix incorrect pad configuration for keypad row lines

2011-09-14 Thread Kukjin Kim
Thomas Abraham wrote:
 
 The keypad controller requires a external pull-up for all the keypad
 row lines. Fix the incorrect pad configuration for keypad controller
 row lines by enabling the pad pull-up for the all row lines of the
 keypad controller.
 
 Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
 ---
 SMDKV310 board does not have pull-up resistors populated for the keypad
 row lines (unlike the smdk boards for the previous Samsung SoC's). So
 the pad pull-up for all keypad row lines should be enabled for
 smdkv310 board.
 
 The default requirement for the keypad controller is to enable the
 pull-up for all the keypad row lines. If a exynos4 based board has
 on-board pull-up's populated for keypad row lines, this patch would
 cause no harm. And in such cases, if internal pad pull-up is to be
 disabled (to reduce some power consumption), an alternative gpio
 configuration function can be supplied that does not enable the
 internal pad pull-up.
 ---
  arch/arm/mach-exynos4/setup-keypad.c |   11 ++-
  1 files changed, 6 insertions(+), 5 deletions(-)
 
 diff --git a/arch/arm/mach-exynos4/setup-keypad.c b/arch/arm/mach-
 exynos4/setup-keypad.c
 index 1ee0ebf..7862bfb 100644
 --- a/arch/arm/mach-exynos4/setup-keypad.c
 +++ b/arch/arm/mach-exynos4/setup-keypad.c
 @@ -19,15 +19,16 @@ void samsung_keypad_cfg_gpio(unsigned int rows,
 unsigned int cols)
 
   if (rows  8) {
   /* Set all the necessary GPX2 pins: KP_ROW[0~7] */
 - s3c_gpio_cfgrange_nopull(EXYNOS4_GPX2(0), 8,
 S3C_GPIO_SFN(3));
 + s3c_gpio_cfgall_range(EXYNOS4_GPX2(0), 8,
 S3C_GPIO_SFN(3),
 + S3C_GPIO_PULL_UP);
 
   /* Set all the necessary GPX3 pins: KP_ROW[8~] */
 - s3c_gpio_cfgrange_nopull(EXYNOS4_GPX3(0), (rows - 8),
 -  S3C_GPIO_SFN(3));
 + s3c_gpio_cfgall_range(EXYNOS4_GPX3(0), (rows - 8),
 +  S3C_GPIO_SFN(3),
 S3C_GPIO_PULL_UP);
   } else {
   /* Set all the necessary GPX2 pins: KP_ROW[x] */
 - s3c_gpio_cfgrange_nopull(EXYNOS4_GPX2(0), rows,
 -  S3C_GPIO_SFN(3));
 + s3c_gpio_cfgall_range(EXYNOS4_GPX2(0), rows,
 S3C_GPIO_SFN(3),
 + S3C_GPIO_PULL_UP);
   }
 
   /* Set all the necessary GPX1 pins to special-function 3: KP_COL[x]
*/
 --
 1.6.6.rc2

Oops, you're right, applied.
Thanks.

Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html