[RESEND PATCH 2/2] s5p-tv: Add PM_RUNTIME dependency

[Hatim Ali]

The TVOUT driver requires PM_RUNTIME support for proper clock
enabling.

Signed-off-by: Hatim Ali 
---
 drivers/media/video/s5p-tv/Kconfig |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/s5p-tv/Kconfig 
b/drivers/media/video/s5p-tv/Kconfig
index 9c37dee..f2a0977 100644
--- a/drivers/media/video/s5p-tv/Kconfig
+++ b/drivers/media/video/s5p-tv/Kconfig
@@ -8,7 +8,7 @@
 
 config VIDEO_SAMSUNG_S5P_TV
bool "Samsung TV driver for S5P platform (experimental)"
-   depends on PLAT_S5P
+   depends on PLAT_S5P && PM_RUNTIME
depends on EXPERIMENTAL
default n
---help---
-- 
1.7.2.3

--
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 1/2] ARM: EXYNOS4: Add TVOUT support for SMDKV310

[Hatim Ali]

Add support for TVOUT on SMDKV310 board.

Signed-off-by: Hatim Ali 
---
Changes since v2:
Incorporated review comments by Tomasz Stanislawski & Sylwester Nawrocki.
- Used gpio_request_one to request for gpio line.
- Added WARN_ON to check gpio_request is successful.

Changes since v1:
Incorporated changes as suggested by Tomasz Stanislawski
- Added  GPIO settings for hot-plug detection.
- Added setting hdmi and mixer's parent for TV power domain.

 arch/arm/mach-exynos4/Kconfig |2 ++
 arch/arm/mach-exynos4/mach-smdkv310.c |   18 ++
 2 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 690bf6f..2857ab0 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -139,7 +139,9 @@ config MACH_SMDKV310
select S3C_DEV_RTC
select S3C_DEV_WDT
select S3C_DEV_I2C1
+   select S5P_DEV_I2C_HDMIPHY
select S5P_DEV_MFC
+   select S5P_DEV_TV
select S3C_DEV_HSMMC
select S3C_DEV_HSMMC1
select S3C_DEV_HSMMC2
diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c 
b/arch/arm/mach-exynos4/mach-smdkv310.c
index 5f62b2b..fa3f9d7 100644
--- a/arch/arm/mach-exynos4/mach-smdkv310.c
+++ b/arch/arm/mach-exynos4/mach-smdkv310.c
@@ -173,6 +173,7 @@ static struct platform_device *smdkv310_devices[] 
__initdata = {
&s3c_device_hsmmc2,
&s3c_device_hsmmc3,
&s3c_device_i2c1,
+   &s5p_device_i2c_hdmiphy,
&s3c_device_rtc,
&s3c_device_wdt,
&exynos4_device_ac97,
@@ -194,6 +195,8 @@ static struct platform_device *smdkv310_devices[] 
__initdata = {
&samsung_asoc_idma,
&smdkv310_smsc911x,
&exynos4_device_ahci,
+   &s5p_device_hdmi,
+   &s5p_device_mixer,
 };
 
 static void __init smdkv310_smsc911x_init(void)
@@ -230,6 +233,18 @@ static struct platform_pwm_backlight_data smdkv310_bl_data 
= {
.pwm_period_ns  = 1000,
 };
 
+static void s5p_tv_setup(void)
+{
+   /* direct HPD to HDMI chip */
+   WARN_ON(gpio_request_one(EXYNOS4_GPX3(7),GPIOF_IN, "hpd-plug"));
+   s3c_gpio_cfgpin(EXYNOS4_GPX3(7), S3C_GPIO_SFN(0x3));
+   s3c_gpio_setpull(EXYNOS4_GPX3(7), S3C_GPIO_PULL_NONE);
+
+   /* setup dependencies between TV devices */
+   s5p_device_hdmi.dev.parent = &exynos4_device_pd[PD_TV].dev;
+   s5p_device_mixer.dev.parent = &exynos4_device_pd[PD_TV].dev;
+}
+
 static void __init smdkv310_map_io(void)
 {
s5p_init_io(NULL, 0, S5P_VA_CHIPID);
@@ -254,6 +269,9 @@ static void __init smdkv310_machine_init(void)
s3c_sdhci2_set_platdata(&smdkv310_hsmmc2_pdata);
s3c_sdhci3_set_platdata(&smdkv310_hsmmc3_pdata);
 
+   s5p_tv_setup();
+   s5p_i2c_hdmiphy_set_platdata(NULL);
+
samsung_keypad_set_platdata(&smdkv310_keypad_data);
 
samsung_bl_set(&smdkv310_bl_gpio_info, &smdkv310_bl_data);
-- 
1.7.2.3

--
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 0/2] Add TVOUT support for SMDKV310

[Hatim Ali]

This is v3 of the TVOUT patch set for SMDKV310.
v1 is available at below link.
(http://www.spinics.net/lists/arm-kernel/msg138054.html)

Patch 1 has been modified according to the comments received from
Tomasz Stanislawski and Sylwester Nawrocki.

Patch 2 is a resend.

NOTE: This patch set has a dependency on "Setup consistent dma size at boot
time" by Tushar Behera.
(http://www.spinics.net/lists/linux-samsung-soc/msg06627.html)

Hatim Ali (2):
  ARM: EXYNOS4: Add TVOUT support for SMDKV310
  s5p-tv: Add PM_RUNTIME dependency

 arch/arm/mach-exynos4/Kconfig |2 ++
 arch/arm/mach-exynos4/mach-smdkv310.c |   18 ++
 drivers/media/video/s5p-tv/Kconfig|2 +-
 3 files changed, 21 insertions(+), 1 deletions(-)

-- 
1.7.2.3

--
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] mmc: core: eMMC 4.5 Power Class Selection Feature

[Girish K S]

Hi chris,

On 21 September 2011 23:36, Chris Ball  wrote:
> Hi Girish,
>
> On Tue, Sep 13 2011, Girish K S wrote:
>> 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 
>> ---
>>  drivers/mmc/core/mmc.c  |   77 
>> +++
>>  include/linux/mmc/mmc.h |   13 
>>  2 files changed, 90 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>> index 63cc77b..a4004da 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;
>> +     unsigned int pwrclass_val;
>> +     unsigned int index = 0;
>> +     struct mmc_host *host = card->host;
>> +
>> +     BUG_ON(!card);
>> +     BUG_ON(!host);
>> +
>> +     /* 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*/
>
> Spaces between /* */ and the comment itself, please.
OK
>
>> +     if (bus_width == EXT_CSD_BUS_WIDTH_1)
>> +             return 0;
>> +
>> +     switch ((1 << host->ios.vdd)) {
>
> Extra parens unnecessary.
OK
>
>> +     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();
>
> BUG() is a huge deal -- it will take out the entire MMC stack, so it's
> not appropriate here.  How about just a pr_error() that notes an
> unexpected VDD and then returns an error value?
Will change it
>
>> +             break;
>> +     }
>> +
>> +     err = mmc_get_ext_csd(card, &ext_csd);
>> +     if (err)
>> +             goto ret;
>> +
>> +     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;
>> +
>> +     err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>> +                     EXT_CSD_POWER_CLASS,
>> +                     pwrclass_val,
>> +                     0);
>> +ret:
>> +     mmc_free_ext_csd(ext_csd);
>> +     return err;
>> +}
>> +
>> +/*
>>   * Handle the detection and initialisation of a card.
>>   *
>>   * In the case of a resume, "oldcard" will contain the card
>> @@ -802,6 +877,7 @@ 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 */
>> +                     mmc_select_powerclass(card, ext_csd_bits[idx][0]);
>
> Since you're returning a meaningful error value above, we should do
> something with it here -- if you don't expect the error cases to be
> hit, you could pr_warning() the return value here so that we can
> investigate.

This patch is the first version. If you check the V2 its already handled.
>
> Thanks,
>
> - Chris.
> --
> Chris Ball      

RE: [PATCH v3] mmc: core: Add default timeout value for CMD6.

[Seungwon Jeon]

Hi Chris Ball,

Chris Ball wrote:
> Hi,
> 
> On Thu, Sep 08 2011, Seungwon Jeon wrote:
> > EXT_CSD[248] includes the default maximum timeout for CMD6.
> > This field is added at eMMC4.5 Spec. And it can be used for default
> > timeout except for some operations which don't define the timeout(i.e.
> > background operation, sanitize, flush cache) in eMMC4.5 Spec.
> >
> > Signed-off-by: Seungwon Jeon 
> > ---
> >  drivers/mmc/core/mmc.c   |   19 +++
> >  include/linux/mmc/card.h |1 +
> >  include/linux/mmc/mmc.h  |1 +
> >  3 files changed, 17 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> > index 5700b1c..a72d879 100644
> > --- a/drivers/mmc/core/mmc.c
> > +++ b/drivers/mmc/core/mmc.c
> > @@ -410,6 +410,15 @@ static int mmc_read_ext_csd(struct mmc_card *card,
> u8 *ext_csd)
> > else
> > card->erased_byte = 0x0;
> >
> > +   if (card->ext_csd.rev >= 6)
> > +   card->ext_csd.generic_cmd6_time = 10 *
> > +   ext_csd[EXT_CSD_GENERIC_CMD6_TIME];
> > +   else
> > +   card->ext_csd.generic_cmd6_time = 0;
> > +
> >  out:
> > return err;
> >  }
> > @@ -668,7 +677,8 @@ static int mmc_init_card(struct mmc_host *host, u32
> ocr,
> >  */
> 
> The patch is corrupt at this point:
> 
> patching file drivers/mmc/core/mmc.c
> patch:  malformed patch at line 39: @@ -668,7 +677,8 @@ static int
> mmc_init_card(struct mmc_host *host, u32 ocr,
Oops.
It's mistake. I'll resend.
> 
> - Chris.
> --
> Chris Ball  
> One Laptop Per Child
> --
> 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-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] mmc: card: modify mmc_getgeo function

[Chris Ball]

Hi,

On Tue, Sep 20 2011, Girish K S wrote:
> In the earlier code the cylinder, sector and head are assigned
> independently. Current patch generates the cylinder number
> with the values of sector and head.
> This patch only makes they cylinder value to be dependent on
> the sector and head.
>
> Signed-off-by: Girish K S 
> ---
>  drivers/mmc/card/block.c |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index 1ff5486..bebb13b 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -226,9 +226,10 @@ static int mmc_blk_release(struct gendisk *disk, fmode_t 
> mode)
>  static int
>  mmc_blk_getgeo(struct block_device *bdev, struct hd_geometry *geo)
>  {
> - geo->cylinders = get_capacity(bdev->bd_disk) / (4 * 16);
>   geo->heads = 4;
>   geo->sectors = 16;
> + geo->cylinders = get_capacity(bdev->bd_disk) /
> + (geo->heads * geo->sectors);
>   return 0;
>  }

Thanks, pushed to mmc-next for 3.2 with a reworded commit message:

Author: Girish K S 
Date:   Tue Sep 20 16:38:49 2011 +0530

mmc: card: Remove duplicated constants

Reuse heads/sectors instead of duplicating them in the cylinders
calculation.

Signed-off-by: Girish K S 
Signed-off-by: Chris Ball 

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
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] mmc: core: HS200 mode support for eMMC 4.5

[Chris Ball]

Hi Girish,

On Fri, Sep 16 2011, Girish K S wrote:
> This patch adds the support of the HS200 bus speed for
> eMMC 4.5 devices.
> The eMMC 4.5 devices have support for 200MHz bus speed.
> The mmc core and host modules have been touched to add support
> for this module.
> It is necessary to know the card type in the sdhci.c file to
> add support for eMMC tuning function. So card.h file is included
> to import the card data structure.
>
> Signed-off-by: Girish K S 
> ---
>  drivers/mmc/core/bus.c   |3 +-
>  drivers/mmc/core/mmc.c   |  116 
> ++
>  drivers/mmc/host/sdhci.c |   18 ++-
>  include/linux/mmc/card.h |3 +
>  include/linux/mmc/host.h |8 +++
>  include/linux/mmc/mmc.h  |9 +++-
>  6 files changed, 143 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
> index 393d817..a0aa7ab 100644
> --- a/drivers/mmc/core/bus.c
> +++ b/drivers/mmc/core/bus.c
> @@ -301,10 +301,11 @@ int mmc_add_card(struct mmc_card *card)
>   mmc_card_ddr_mode(card) ? "DDR " : "",
>   type);
>   } else {
> - printk(KERN_INFO "%s: new %s%s%s card at address %04x\n",
> + printk(KERN_INFO "%s: new %s%s%s%s card at address %04x\n",
>   mmc_hostname(card->host),
>   mmc_sd_card_uhs(card) ? "ultra high speed " :
>   (mmc_card_highspeed(card) ? "high speed " : ""),
> + (mmc_card_hs200(card) ? "HS200 " : ""),
>   mmc_card_ddr_mode(card) ? "DDR " : "",
>   type, card->rca);
>   }
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 9cbc113..c50ca42 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -283,6 +283,66 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 
> *ext_csd)
>   }
>   card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
>   switch (ext_csd[EXT_CSD_CARD_TYPE] & EXT_CSD_CARD_TYPE_MASK) {
> + case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_52 |
> +  EXT_CSD_CARD_TYPE_26:
> + card->ext_csd.hs_max_dtr = 2;
> + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_200;
> + break;
> + case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_1_8V |
> +  EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
> + card->ext_csd.hs_max_dtr = 2;
> + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_200;
> + break;

Please try shortening this switch-case by avoiding duplicating sections
that repeat the same action, and having the case fall-through instead.

Thanks,

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
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] mmc: core: eMMC 4.5 Power Class Selection Feature

[Chris Ball]

Hi Girish,

On Tue, Sep 13 2011, Girish K S wrote:
> 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 
> ---
>  drivers/mmc/core/mmc.c  |   77 
> +++
>  include/linux/mmc/mmc.h |   13 
>  2 files changed, 90 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 63cc77b..a4004da 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;
> + unsigned int pwrclass_val;
> + unsigned int index = 0;
> + struct mmc_host *host = card->host;
> +
> + BUG_ON(!card);
> + BUG_ON(!host);
> +
> + /* 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*/

Spaces between /* */ and the comment itself, please.

> + if (bus_width == EXT_CSD_BUS_WIDTH_1)
> + return 0;
> +
> + switch ((1 << host->ios.vdd)) {

Extra parens unnecessary.

> + 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();

BUG() is a huge deal -- it will take out the entire MMC stack, so it's
not appropriate here.  How about just a pr_error() that notes an
unexpected VDD and then returns an error value?

> + break;
> + }
> +
> + err = mmc_get_ext_csd(card, &ext_csd);
> + if (err)
> + goto ret;
> +
> + 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;
> +
> + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> + EXT_CSD_POWER_CLASS,
> + pwrclass_val,
> + 0);
> +ret:
> + mmc_free_ext_csd(ext_csd);
> + return err;
> +}
> +
> +/*
>   * Handle the detection and initialisation of a card.
>   *
>   * In the case of a resume, "oldcard" will contain the card
> @@ -802,6 +877,7 @@ 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 */
> + mmc_select_powerclass(card, ext_csd_bits[idx][0]);

Since you're returning a meaningful error value above, we should do
something with it here -- if you don't expect the error cases to be
hit, you could pr_warning() the return value here so that we can
investigate.

Thanks,

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
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] mmc: core: Add default timeout value for CMD6.

[Chris Ball]

Hi,

On Thu, Sep 08 2011, Seungwon Jeon wrote:
> EXT_CSD[248] includes the default maximum timeout for CMD6.
> This field is added at eMMC4.5 Spec. And it can be used for default
> timeout except for some operations which don't define the timeout(i.e.
> background operation, sanitize, flush cache) in eMMC4.5 Spec.
>
> Signed-off-by: Seungwon Jeon 
> ---
>  drivers/mmc/core/mmc.c   |   19 +++
>  include/linux/mmc/card.h |1 +
>  include/linux/mmc/mmc.h  |1 +
>  3 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 5700b1c..a72d879 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -410,6 +410,15 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 
> *ext_csd)
>   else
>   card->erased_byte = 0x0;
>
> + if (card->ext_csd.rev >= 6)
> + card->ext_csd.generic_cmd6_time = 10 *
> + ext_csd[EXT_CSD_GENERIC_CMD6_TIME];
> + else
> + card->ext_csd.generic_cmd6_time = 0;
> +
>  out:
>   return err;
>  }
> @@ -668,7 +677,8 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
>*/

The patch is corrupt at this point:

patching file drivers/mmc/core/mmc.c
patch:  malformed patch at line 39: @@ -668,7 +677,8 @@ static int 
mmc_init_card(struct mmc_host *host, u32 ocr,

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
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 1/3] ARM: EXYNOS4: Add TVOUT support for SMDKV310

[Hatim R.V.]

Hi Sylwester,

On Wed, Sep 21, 2011 at 6:35 PM, Sylwester Nawrocki
 wrote:
> Hi Hatim,
>
> On 09/21/2011 07:44 AM, Hatim Ali wrote:
>> Add support for TVOUT on SMDKV310 board.
>>
>> Signed-off-by: Hatim Ali 
>> ---
> ...
>> diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c 
>> b/arch/arm/mach-exynos4/mach-smdkv310.c
>> index 7ce4d8b..50de270 100644
>> --- a/arch/arm/mach-exynos4/mach-smdkv310.c
>> +++ b/arch/arm/mach-exynos4/mach-smdkv310.c
>> @@ -239,6 +239,7 @@ static struct platform_device *smdkv310_devices[] 
>> __initdata = {
>>       &s3c_device_hsmmc2,
>>       &s3c_device_hsmmc3,
>>       &s3c_device_i2c1,
>> +     &s5p_device_i2c_hdmiphy,
>>       &s3c_device_rtc,
>>       &s3c_device_wdt,
>>       &exynos4_device_ac97,
>> @@ -262,6 +263,8 @@ static struct platform_device *smdkv310_devices[] 
>> __initdata = {
>>       &smdkv310_lcd_lte480wv,
>>       &smdkv310_smsc911x,
>>       &exynos4_device_ahci,
>> +     &s5p_device_hdmi,
>> +     &s5p_device_mixer,
>>  };
>>
>>  static void __init smdkv310_smsc911x_init(void)
>> @@ -298,6 +301,25 @@ static struct platform_pwm_backlight_data 
>> smdkv310_bl_data = {
>>       .pwm_period_ns  = 1000,
>>  };
>>
>> +static void s5p_tv_setup(void)
>> +{
>> +     int ret;
>> +
>> +     /* direct HPD to HDMI chip */
>> +     ret = gpio_request(EXYNOS4_GPX3(7), "hpd-plug");
>> +
>> +     if (!ret) {
>> +             gpio_direction_input(EXYNOS4_GPX3(7));
>
> Since you're probably going to be reworking this anyway, I think 
> gpio_request_one
> could be used here for simplicity.

Thanks for your suggestion. Will change accordingly.


>
> --
> Regards,
> Sylwester
> --
> 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 1/3] ARM: EXYNOS4: Add TVOUT support for SMDKV310

[Hatim R.V.]

Hello Tomasz Stanislawski,

On Wed, Sep 21, 2011 at 6:14 PM, Tomasz Stanislawski
 wrote:
> On 09/21/2011 02:06 PM, Kukjin Kim wrote:
>>
>> Hatim Ali wrote:
>>>
>>> Add support for TVOUT on SMDKV310 board.
>>>
>>> Signed-off-by: Hatim Ali
>>> ---
>>> Changes since V1:
>>> Incorporated changes as suggested by Tomasz Stanislawski
>>> - Added  GPIO settings for hot-plug detection.
>>> - Added setting hdmi and mixer's parent for TV power domain.
>>>
>>>  arch/arm/mach-exynos4/Kconfig         |    2 ++
>>>  arch/arm/mach-exynos4/mach-smdkv310.c |   25
>>> +
>>>  2 files changed, 27 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-exynos4/Kconfig
>>> b/arch/arm/mach-exynos4/Kconfig
>>> index 3b594fe..0bf0fe04 100644
>>> --- a/arch/arm/mach-exynos4/Kconfig
>>> +++ b/arch/arm/mach-exynos4/Kconfig
>>> @@ -131,6 +131,7 @@ config MACH_SMDKV310
>>>        select S3C_DEV_RTC
>>>        select S3C_DEV_WDT
>>>        select S3C_DEV_I2C1
>>> +       select S5P_DEV_I2C_HDMIPHY
>>>        select S5P_DEV_MFC
>>>        select S3C_DEV_HSMMC
>>>        select S3C_DEV_HSMMC1
>>> @@ -140,6 +141,7 @@ config MACH_SMDKV310
>>>        select EXYNOS4_DEV_AHCI
>>>        select SAMSUNG_DEV_KEYPAD
>>>        select EXYNOS4_DEV_PD
>>> +       select S5P_DEV_TV
>>>        select SAMSUNG_DEV_PWM
>>>        select EXYNOS4_DEV_SYSMMU
>>>        select EXYNOS4_SETUP_FIMD0
>>> diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-
>>> exynos4/mach-smdkv310.c
>>> index 7ce4d8b..50de270 100644
>>> --- a/arch/arm/mach-exynos4/mach-smdkv310.c
>>> +++ b/arch/arm/mach-exynos4/mach-smdkv310.c
>>> @@ -239,6 +239,7 @@ static struct platform_device *smdkv310_devices[]
>>> __initdata = {
>>>        &s3c_device_hsmmc2,
>>>        &s3c_device_hsmmc3,
>>>        &s3c_device_i2c1,
>>> +       &s5p_device_i2c_hdmiphy,
>>>        &s3c_device_rtc,
>>>        &s3c_device_wdt,
>>>        &exynos4_device_ac97,
>>> @@ -262,6 +263,8 @@ static struct platform_device *smdkv310_devices[]
>>> __initdata = {
>>>        &smdkv310_lcd_lte480wv,
>>>        &smdkv310_smsc911x,
>>>        &exynos4_device_ahci,
>>> +       &s5p_device_hdmi,
>>> +       &s5p_device_mixer,
>>>  };
>>>
>>>  static void __init smdkv310_smsc911x_init(void)
>>> @@ -298,6 +301,25 @@ static struct platform_pwm_backlight_data
>>> smdkv310_bl_data = {
>>>        .pwm_period_ns  = 1000,
>>>  };
>>>
>>> +static void s5p_tv_setup(void)
>>> +{
>>> +       int ret;
>>> +
>>> +       /* direct HPD to HDMI chip */
>>> +       ret = gpio_request(EXYNOS4_GPX3(7), "hpd-plug");
>>> +
>>> +       if (!ret) {
>
> Maybe we should generate WARN_ON(1) here. Failure of gpio request indicate
> that
> board was configued not correctly.

Ok. will add this in my next patch.
>>>
>>> +               gpio_direction_input(EXYNOS4_GPX3(7));
>>> +               s3c_gpio_cfgpin_range(EXYNOS4_GPX3(7),
>>> +                                       1, S3C_GPIO_SFN(3));
>>
>> Why do you use 's3c_gpio_cfgpin_range()' for just one gpio pin not
>> range...?
>>
>>> +       } else
>>> +               pr_err("Failed to request gpio for hpd: %d\n", ret);
>>
>> According to coding style, should be added { and } around above.
>>
>>> +
>>> +       /* setup dependencies between TV devices */
>>> +       s5p_device_hdmi.dev.parent =&exynos4_device_pd[PD_TV].dev;
>>> +       s5p_device_mixer.dev.parent =&exynos4_device_pd[PD_TV].dev;
>>> +}
>>> +
>>>  static void __init smdkv310_map_io(void)
>>>  {
>>>        s5p_init_io(NULL, 0, S5P_VA_CHIPID);
>>> @@ -327,6 +349,9 @@ static void __init smdkv310_machine_init(void)
>>>        samsung_bl_set(&smdkv310_bl_gpio_info,&smdkv310_bl_data);
>>>        s5p_fimd0_set_platdata(&smdkv310_lcd0_pdata);
>>>
>>> +       s5p_tv_setup();
>>> +       s5p_i2c_hdmiphy_set_platdata(NULL);
>>> +
>>>        platform_add_devices(smdkv310_devices,
>>> ARRAY_SIZE(smdkv310_devices));
>>>        s5p_device_mfc.dev.parent =&exynos4_device_pd[PD_MFC].dev;
>>>  }
>>> --
>>> 1.7.2.3
>>
>> Thanks.
>>
>> Best regards,
>> Kgene.
>> --
>> Kukjin Kim, 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
>
--
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 1/3] ARM: EXYNOS4: Add TVOUT support for SMDKV310

[Sylwester Nawrocki]

Hi Hatim,

On 09/21/2011 07:44 AM, Hatim Ali wrote:
> Add support for TVOUT on SMDKV310 board.
> 
> Signed-off-by: Hatim Ali 
> ---
...
> diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c 
> b/arch/arm/mach-exynos4/mach-smdkv310.c
> index 7ce4d8b..50de270 100644
> --- a/arch/arm/mach-exynos4/mach-smdkv310.c
> +++ b/arch/arm/mach-exynos4/mach-smdkv310.c
> @@ -239,6 +239,7 @@ static struct platform_device *smdkv310_devices[] 
> __initdata = {
>   &s3c_device_hsmmc2,
>   &s3c_device_hsmmc3,
>   &s3c_device_i2c1,
> + &s5p_device_i2c_hdmiphy,
>   &s3c_device_rtc,
>   &s3c_device_wdt,
>   &exynos4_device_ac97,
> @@ -262,6 +263,8 @@ static struct platform_device *smdkv310_devices[] 
> __initdata = {
>   &smdkv310_lcd_lte480wv,
>   &smdkv310_smsc911x,
>   &exynos4_device_ahci,
> + &s5p_device_hdmi,
> + &s5p_device_mixer,
>  };
>  
>  static void __init smdkv310_smsc911x_init(void)
> @@ -298,6 +301,25 @@ static struct platform_pwm_backlight_data 
> smdkv310_bl_data = {
>   .pwm_period_ns  = 1000,
>  };
>  
> +static void s5p_tv_setup(void)
> +{
> + int ret;
> +
> + /* direct HPD to HDMI chip */
> + ret = gpio_request(EXYNOS4_GPX3(7), "hpd-plug");
> +
> + if (!ret) {
> + gpio_direction_input(EXYNOS4_GPX3(7));

Since you're probably going to be reworking this anyway, I think 
gpio_request_one
could be used here for simplicity.  

--
Regards,
Sylwester
--
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/7] s3c-adc: describe features via quirk constants

[Heiko Stübner]

Hi,

Am Mittwoch, 21. September 2011, 14:32:14 schrieben Sie:
> Heiko Stübner wrote:
> > The adc blocks of S3C2410 through S5P have a multitude of
> > quirks, i.e. moved bits or whole new registers.
> > 
> > This patch tries to describe these individual features
> > through constants which can be used to describe an adc.
> > 
> > As SoCs sometimes share only some of these quirks defining
> > TYPE_ADCVx values for each one wouldn't scale well when
> > adding more variants.
> 
> Hi Heiko,
> 
> I don't have idea we really need to use QUIRK in this case...as I know, the
> QUIRK is used on other situation...
> 
> In addition, the TYPE_ADCVx can support each Samsung SoCs' ADC...but I need
> to check again.
The current types could not support the features of the 2443 and 2416/2450 - I 
checked the datasheets.

The mux register in base+0x18 does not exist on any of the current platforms.
Also the bit 3 in ADCCON to select the resolution is specific to the 2416/2450 
(see comments above constants and quirk definitions in patches 6 and 7).

So to support these SoCs would require the definition of two new types. 
Including these new types in the existing conditionals would introduce a lot 
of statements like
if ( (TYPE_X || TYPE_Y) && !TYPE_Z)

In my opinion testing for specific features also describes the difference 
between implementations better if one reads the code later on.


I will change the styling of the "<<"s but am wondering why checkpatch did not 
complain, i.e. it complains for all other whitespace mistakes one can make but 
not these.

Heiko

> 
> > Signed-off-by: Heiko Stuebner 
> > ---
> > 
> >  arch/arm/plat-samsung/adc.c |   29 +
> >  1 files changed, 29 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c
> > index ee8deef..b209d58 100644
> > --- a/arch/arm/plat-samsung/adc.c
> > +++ b/arch/arm/plat-samsung/adc.c
> > @@ -45,6 +45,35 @@ enum s3c_cpu_type {
> > 
> > TYPE_ADCV3, /* S5PV210, S5PC110, EXYNOS4210 */
> >  
> >  };
> > 
> > +/*
> > + * Resolution of the ADC - 10 or 12 bit
> > + */
> 
> /* ... */
> 
> > +#define S3C_ADC_QUIRK_10BIT0
> > +#define S3C_ADC_QUIRK_12BIT(1<<0)
> 
> According to coding style, should be added blank around <<.
> 
> > +
> > +/*
> > + * 12bit ADC can switch resolution between 10 bit and 12 bit
> > + * ADCCON bit 03 for S3C2416
> > + * ADCCON bit 16 for S3C64XX and up
> > + */
> > +#define S3C_ADC_QUIRK_RESSEL03 (1<<1)
> > +#define S3C_ADC_QUIRK_RESSEL16 (1<<2)
> 
> Same as above.
> 
> > +
> > +/*
> > + * Input channel select can either be in
> > + * - reg ADCCON, bit for S3C24XX and S3C64XX
> > + * - reg base+0x18 for 2443/2416/2450
> > + * - reg base+0x1C for S5P
> > + */
> > +#define S3C_ADC_QUIRK_MUXADCCON(1<<3)
> > +#define S3C_ADC_QUIRK_MUX18(1<<4)
> > +#define S3C_ADC_QUIRK_MUX1C(1<<5)
> 
> Same.
> 
> > +
> > +/*
> > + * CLRINT register on S3C64xx
> > + */
> 
> /* ... */
> 
> > +#define S3C_ADC_QUIRK_CLRINT   (1<<6)
> 
> Same.
> 
> > +
> > 
> >  struct s3c_adc_client {
> >  
> > struct platform_device  *pdev;
> > struct list_head pend;
> > 
> > --
> > 1.7.2.3
> 
> Thanks.
> 
> Best regards,
> Kgene.
> --
> Kukjin Kim , 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 V5 0/6] ARM: S5P64X0: Add Framebuffer support

[Ajay kumar]

Hi Kukjin,

On Wed, Sep 21, 2011 at 5:43 PM, Kukjin Kim  wrote:
> Ajay Kumar wrote:
>>
>>  The patches are created against "for-next" branch of Kukjin Kim's tree
> at:
>>  git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>>
>>  Changes since V1:
>>       - Remove mach/regs-fb.h, instead use plat/regs-fb.h.
>>       - Add common pdata for FB and LCD in SMDK6440 and SMDK6450.
>>       - Modify names(s5p-->smdk), max_bpp and refresh rate.
>>       - Modify variable name(cfg-->chipid).
>>       - Use __raw_readl, __raw_writel instead of readl and writel.
>>
>>  Changes since V2:
>>       -Change name of the config-COMMON_FB to SMDK64X0_COMMON_FB.
>>       -Change filename common-fb.h to smdk64x0-common-fb.h.
>>       -Change filename common-fb.c to smdk64x0-common-fb.c.
>>
>>  Changes since V3:
>>       -Add FB and LCD plat-data in corresponding machine files
>>        instead of creating common file smdk64x0-common-fb.c.
>>       -Modify name S5P64X0_SETUP_FB to S5P64X0_SETUP_FB_24BPP.
>>       -Modify file name setup-fb.c to setup-fb-24bpp.c.
>>       -Move SPCON settings to machine file.
>>       -Use soc_is_s5p6440()/soc_is_s5p6450() to check CPU ID.
>>
>>  Changes since V4:
>>       -Removed refresh rate from plat data(s3c_fb_pd_win)
>>       -Fixed complation warning:"function declaration isn't a prototype"
>>        for s5p6440_set_lcd_interface() and s5p6450_set_lcd_interface().
>>
>>
>>   These patches have dependency on the patch:
>>   "ARM: S5P64X0: Fix mask value for S5P64X0 CPU IDs",
>>   at http://www.spinics.net/lists/arm-kernel/msg138990.html
>>
>> o To Kukjin,
>>   [PATCH RESEND V5 1/6] video: s3c-fb: Add S5P64X0 specific
>> s3c_fb_driverdata
>>   [PATCH RESEND V5 2/6] ARM: S5P64X0: Add register base and IRQ for
>> Framebuffer
>>   [PATCH RESEND V5 3/6] ARM: S5P64X0: Set s3c_device_fb name
>>   [PATCH RESEND V5 4/6] ARM: S5P64X0: Add GPIO setup for LCD
>>   [PATCH V5 5/6]ARM: S5P6440: Add LCD-LTE480 and enable Framebuffer
>> support
>>   [PATCH V5 6/6]ARM: S5P6450: Add LCD-LTE480 and enable Framebuffer
>> support
>>
>>  arch/arm/mach-s5p64x0/Kconfig                  |   10 +++
>>  arch/arm/mach-s5p64x0/Makefile                 |    1 +
>>  arch/arm/mach-s5p64x0/cpu.c                    |    3 +
>>  arch/arm/mach-s5p64x0/include/mach/irqs.h      |    4 +
>>  arch/arm/mach-s5p64x0/include/mach/map.h       |    3 +
>>  arch/arm/mach-s5p64x0/include/mach/regs-gpio.h |    4 +
>>  arch/arm/mach-s5p64x0/mach-smdk6440.c          |   74
>> +++
>>  arch/arm/mach-s5p64x0/mach-smdk6450.c          |   75
>> 
>>  arch/arm/mach-s5p64x0/setup-fb-24bpp.c         |   29 +
>>  arch/arm/plat-samsung/include/plat/fb.h        |    7 ++
>>  drivers/video/s3c-fb.c                         |   27 +
>>  11 files changed, 237 insertions(+), 0 deletions(-)
>>  create mode 100644 arch/arm/mach-s5p64x0/setup-fb-24bpp.c
>
> Looks ok to me, will apply.
>
> But as I said, the 'video: s3c-fb: Add S5P64X0 specific s3c_fb_driverdata'
> should be sent to Florian's tree.

Yes. This patch was submitted to fbdev mailing list and Florian has
already accepted it. Here is the link:
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/065154.html

> I think, it's enough to re-send it to Florian Tobias Schandina.
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim , 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
>

Ajay
--
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 1/3] ARM: EXYNOS4: Add TVOUT support for SMDKV310

[Tomasz Stanislawski]

On 09/21/2011 02:06 PM, Kukjin Kim wrote:

Hatim Ali wrote:

Add support for TVOUT on SMDKV310 board.

Signed-off-by: Hatim Ali
---
Changes since V1:
Incorporated changes as suggested by Tomasz Stanislawski
- Added  GPIO settings for hot-plug detection.
- Added setting hdmi and mixer's parent for TV power domain.

  arch/arm/mach-exynos4/Kconfig |2 ++
  arch/arm/mach-exynos4/mach-smdkv310.c |   25
+
  2 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 3b594fe..0bf0fe04 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -131,6 +131,7 @@ config MACH_SMDKV310
select S3C_DEV_RTC
select S3C_DEV_WDT
select S3C_DEV_I2C1
+   select S5P_DEV_I2C_HDMIPHY
select S5P_DEV_MFC
select S3C_DEV_HSMMC
select S3C_DEV_HSMMC1
@@ -140,6 +141,7 @@ config MACH_SMDKV310
select EXYNOS4_DEV_AHCI
select SAMSUNG_DEV_KEYPAD
select EXYNOS4_DEV_PD
+   select S5P_DEV_TV
select SAMSUNG_DEV_PWM
select EXYNOS4_DEV_SYSMMU
select EXYNOS4_SETUP_FIMD0
diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-
exynos4/mach-smdkv310.c
index 7ce4d8b..50de270 100644
--- a/arch/arm/mach-exynos4/mach-smdkv310.c
+++ b/arch/arm/mach-exynos4/mach-smdkv310.c
@@ -239,6 +239,7 @@ static struct platform_device *smdkv310_devices[]
__initdata = {
&s3c_device_hsmmc2,
&s3c_device_hsmmc3,
&s3c_device_i2c1,
+   &s5p_device_i2c_hdmiphy,
&s3c_device_rtc,
&s3c_device_wdt,
&exynos4_device_ac97,
@@ -262,6 +263,8 @@ static struct platform_device *smdkv310_devices[]
__initdata = {
&smdkv310_lcd_lte480wv,
&smdkv310_smsc911x,
&exynos4_device_ahci,
+   &s5p_device_hdmi,
+   &s5p_device_mixer,
  };

  static void __init smdkv310_smsc911x_init(void)
@@ -298,6 +301,25 @@ static struct platform_pwm_backlight_data
smdkv310_bl_data = {
.pwm_period_ns  = 1000,
  };

+static void s5p_tv_setup(void)
+{
+   int ret;
+
+   /* direct HPD to HDMI chip */
+   ret = gpio_request(EXYNOS4_GPX3(7), "hpd-plug");
+
+   if (!ret) {
Maybe we should generate WARN_ON(1) here. Failure of gpio request 
indicate that

board was configued not correctly.

+   gpio_direction_input(EXYNOS4_GPX3(7));
+   s3c_gpio_cfgpin_range(EXYNOS4_GPX3(7),
+   1, S3C_GPIO_SFN(3));

Why do you use 's3c_gpio_cfgpin_range()' for just one gpio pin not range...?


+   } else
+   pr_err("Failed to request gpio for hpd: %d\n", ret);

According to coding style, should be added { and } around above.


+
+   /* setup dependencies between TV devices */
+   s5p_device_hdmi.dev.parent =&exynos4_device_pd[PD_TV].dev;
+   s5p_device_mixer.dev.parent =&exynos4_device_pd[PD_TV].dev;
+}
+
  static void __init smdkv310_map_io(void)
  {
s5p_init_io(NULL, 0, S5P_VA_CHIPID);
@@ -327,6 +349,9 @@ static void __init smdkv310_machine_init(void)
samsung_bl_set(&smdkv310_bl_gpio_info,&smdkv310_bl_data);
s5p_fimd0_set_platdata(&smdkv310_lcd0_pdata);

+   s5p_tv_setup();
+   s5p_i2c_hdmiphy_set_platdata(NULL);
+
platform_add_devices(smdkv310_devices,
ARRAY_SIZE(smdkv310_devices));
s5p_device_mfc.dev.parent =&exynos4_device_pd[PD_MFC].dev;
  }
--
1.7.2.3

Thanks.

Best regards,
Kgene.
--
Kukjin Kim, 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 0/5] S5P64X0 PM Support

[Kukjin Kim]

Abhilash Kesavan wrote:
> 
> The patchset adds Power Mangement support for S5P64X0. The first
> four patches lay the groundwork for adding PM support, while the
> final patch adds the SoC specific PM code.
> Tested using external interrupts as wake-up sources on SMDK6440
> and SMDK6450.
> 
> Abhilash Kesavan (5):
>   ARM: S5P: Make the common S5P PM code conditionally compile
>   ARM: SAMSUNG: Make the sleep code common for S3C64XX and newer SoCs
>   ARM: S5P64X0: Add pm save/restore functions for GPIO banks
>   ARM: S5P64X0: Fix incorrect serial clock name
>   ARM: S5P64X0: Add Power Management support
> 
>  arch/arm/Kconfig|2 +-
>  arch/arm/mach-exynos4/Kconfig   |2 +
>  arch/arm/mach-exynos4/Makefile  |2 +-
>  arch/arm/mach-exynos4/sleep.S   |   54 --
>  arch/arm/mach-s3c64xx/Kconfig   |1 +
>  arch/arm/mach-s3c64xx/Makefile  |1 -
>  arch/arm/mach-s3c64xx/sleep.S   |   72 
>  arch/arm/mach-s5p64x0/Kconfig   |4 +
>  arch/arm/mach-s5p64x0/Makefile  |1 +
>  arch/arm/mach-s5p64x0/clock-s5p6440.c   |2 +-
>  arch/arm/mach-s5p64x0/clock-s5p6450.c   |2 +-
>  arch/arm/mach-s5p64x0/gpiolib.c |1 +
>  arch/arm/mach-s5p64x0/include/mach/map.h|1 +
>  arch/arm/mach-s5p64x0/include/mach/pm-core.h|  117 +
>  arch/arm/mach-s5p64x0/include/mach/regs-clock.h |   33 
>  arch/arm/mach-s5p64x0/include/mach/regs-gpio.h  |   19 ++
>  arch/arm/mach-s5p64x0/init.c|2 +-
>  arch/arm/mach-s5p64x0/irq-eint.c|2 +
>  arch/arm/mach-s5p64x0/irq-pm.c  |   92 ++
>  arch/arm/mach-s5p64x0/pm.c  |  204
> +++
>  arch/arm/mach-s5pv210/Kconfig   |2 +
>  arch/arm/mach-s5pv210/Makefile  |2 +-
>  arch/arm/mach-s5pv210/sleep.S   |   52 --
>  arch/arm/plat-s5p/Kconfig   |6 +
>  arch/arm/plat-s5p/Makefile  |3 +-
>  arch/arm/plat-samsung/Kconfig   |7 +
>  arch/arm/plat-samsung/Makefile  |1 +
>  arch/arm/plat-samsung/sleep.S   |   80 +
>  drivers/gpio/gpio-plat-samsung.c|4 +-
>  29 files changed, 583 insertions(+), 188 deletions(-)
>  delete mode 100644 arch/arm/mach-exynos4/sleep.S
>  delete mode 100644 arch/arm/mach-s3c64xx/sleep.S
>  create mode 100644 arch/arm/mach-s5p64x0/include/mach/pm-core.h
>  create mode 100644 arch/arm/mach-s5p64x0/irq-pm.c
>  create mode 100644 arch/arm/mach-s5p64x0/pm.c
>  delete mode 100644 arch/arm/mach-s5pv210/sleep.S
>  create mode 100644 arch/arm/plat-samsung/sleep.S
> 
> --
> 1.7.4.1

Hi Abhilash,

As I know, you need to rebase this series based on latest for-next.

Please re-submit this series...and I agree with Russell's suggestion on
patch 2/5.
But it's enough to use s3c64xx_smdk_leds_resume() firstly not common smdk
now.

Of course, we need to do it later ;)

Thanks.

Best regards,
Kgene.
--
Kukjin Kim , 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/7] s3c-adc: describe features via quirk constants

[Kukjin Kim]

Heiko Stübner wrote:
> 
> The adc blocks of S3C2410 through S5P have a multitude of
> quirks, i.e. moved bits or whole new registers.
> 
> This patch tries to describe these individual features
> through constants which can be used to describe an adc.
> 
> As SoCs sometimes share only some of these quirks defining
> TYPE_ADCVx values for each one wouldn't scale well when
> adding more variants.
> 
Hi Heiko,

I don't have idea we really need to use QUIRK in this case...as I know, the
QUIRK is used on other situation...

In addition, the TYPE_ADCVx can support each Samsung SoCs' ADC...but I need
to check again.

> Signed-off-by: Heiko Stuebner 
> ---
>  arch/arm/plat-samsung/adc.c |   29 +
>  1 files changed, 29 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c
> index ee8deef..b209d58 100644
> --- a/arch/arm/plat-samsung/adc.c
> +++ b/arch/arm/plat-samsung/adc.c
> @@ -45,6 +45,35 @@ enum s3c_cpu_type {
>   TYPE_ADCV3, /* S5PV210, S5PC110, EXYNOS4210 */
>  };
> 
> +/*
> + * Resolution of the ADC - 10 or 12 bit
> + */

/* ... */

> +#define S3C_ADC_QUIRK_10BIT  0
> +#define S3C_ADC_QUIRK_12BIT  (1<<0)

According to coding style, should be added blank around <<.

> +
> +/*
> + * 12bit ADC can switch resolution between 10 bit and 12 bit
> + * ADCCON bit 03 for S3C2416
> + * ADCCON bit 16 for S3C64XX and up
> + */
> +#define S3C_ADC_QUIRK_RESSEL03   (1<<1)
> +#define S3C_ADC_QUIRK_RESSEL16   (1<<2)

Same as above.

> +
> +/*
> + * Input channel select can either be in
> + * - reg ADCCON, bit for S3C24XX and S3C64XX
> + * - reg base+0x18 for 2443/2416/2450
> + * - reg base+0x1C for S5P
> + */
> +#define S3C_ADC_QUIRK_MUXADCCON  (1<<3)
> +#define S3C_ADC_QUIRK_MUX18  (1<<4)
> +#define S3C_ADC_QUIRK_MUX1C  (1<<5)

Same.

> +
> +/*
> + * CLRINT register on S3C64xx
> + */

/* ... */

> +#define S3C_ADC_QUIRK_CLRINT (1<<6)

Same.

> +
>  struct s3c_adc_client {
>   struct platform_device  *pdev;
>   struct list_head pend;
> --
> 1.7.2.3


Thanks.

Best regards,
Kgene.
--
Kukjin Kim , 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 1/2] mmc: sdhci-s3c: add default controller configuration

[Kukjin Kim]

Chris Ball wrote:
> 
> Hi,
> 
> On Wed, Sep 21 2011, Kukjin Kim wrote:
> > Acked-by: Kukjin Kim 
> >
> > Hi Chris,
> >
> > This is ok to me. Could you please pick this up in your tree so that I
can
> > pick 2nd patch up in my tree.
> >
> > As you know, this patch has no dependency with patch2/2 so that you can
> > handle without any conflicts.
> 
> Thanks, pushed to mmc-next for 3.2.
> 
Thanks!

> I've been waiting for kernel.org to come back up, but I think later

Yeah, I know...

> today I'll just move mmc-next to git://dev.laptop.org/users/cjb/mmc,
> so this will be available in linux-next soon.
> 
Yes, I also moved my tree to git://github.com/kgene/linux-samsung.git...

Anyway, thanks for your information.

Best regards,
Kgene.
--
Kukjin Kim , 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 1/2] mmc: sdhci-s3c: add default controller configuration

[Chris Ball]

Hi,

On Wed, Sep 21 2011, Kukjin Kim wrote:
> Acked-by: Kukjin Kim 
>
> Hi Chris,
>
> This is ok to me. Could you please pick this up in your tree so that I can
> pick 2nd patch up in my tree.
>
> As you know, this patch has no dependency with patch2/2 so that you can
> handle without any conflicts.

Thanks, pushed to mmc-next for 3.2.

I've been waiting for kernel.org to come back up, but I think later
today I'll just move mmc-next to git://dev.laptop.org/users/cjb/mmc,
so this will be available in linux-next soon.

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
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 V5 0/6] ARM: S5P64X0: Add Framebuffer support

[Kukjin Kim]

Ajay Kumar wrote:
> 
>  The patches are created against "for-next" branch of Kukjin Kim's tree
at:
>  git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> 
>  Changes since V1:
>   - Remove mach/regs-fb.h, instead use plat/regs-fb.h.
>   - Add common pdata for FB and LCD in SMDK6440 and SMDK6450.
>   - Modify names(s5p-->smdk), max_bpp and refresh rate.
>   - Modify variable name(cfg-->chipid).
>   - Use __raw_readl, __raw_writel instead of readl and writel.
> 
>  Changes since V2:
>   -Change name of the config-COMMON_FB to SMDK64X0_COMMON_FB.
>   -Change filename common-fb.h to smdk64x0-common-fb.h.
>   -Change filename common-fb.c to smdk64x0-common-fb.c.
> 
>  Changes since V3:
>   -Add FB and LCD plat-data in corresponding machine files
>instead of creating common file smdk64x0-common-fb.c.
>   -Modify name S5P64X0_SETUP_FB to S5P64X0_SETUP_FB_24BPP.
>   -Modify file name setup-fb.c to setup-fb-24bpp.c.
>   -Move SPCON settings to machine file.
>   -Use soc_is_s5p6440()/soc_is_s5p6450() to check CPU ID.
> 
>  Changes since V4:
>   -Removed refresh rate from plat data(s3c_fb_pd_win)
>   -Fixed complation warning:"function declaration isn't a prototype"
>for s5p6440_set_lcd_interface() and s5p6450_set_lcd_interface().
> 
> 
>   These patches have dependency on the patch:
>   "ARM: S5P64X0: Fix mask value for S5P64X0 CPU IDs",
>   at http://www.spinics.net/lists/arm-kernel/msg138990.html
> 
> o To Kukjin,
>   [PATCH RESEND V5 1/6] video: s3c-fb: Add S5P64X0 specific
> s3c_fb_driverdata
>   [PATCH RESEND V5 2/6] ARM: S5P64X0: Add register base and IRQ for
> Framebuffer
>   [PATCH RESEND V5 3/6] ARM: S5P64X0: Set s3c_device_fb name
>   [PATCH RESEND V5 4/6] ARM: S5P64X0: Add GPIO setup for LCD
>   [PATCH V5 5/6]ARM: S5P6440: Add LCD-LTE480 and enable Framebuffer
> support
>   [PATCH V5 6/6]ARM: S5P6450: Add LCD-LTE480 and enable Framebuffer
> support
> 
>  arch/arm/mach-s5p64x0/Kconfig  |   10 +++
>  arch/arm/mach-s5p64x0/Makefile |1 +
>  arch/arm/mach-s5p64x0/cpu.c|3 +
>  arch/arm/mach-s5p64x0/include/mach/irqs.h  |4 +
>  arch/arm/mach-s5p64x0/include/mach/map.h   |3 +
>  arch/arm/mach-s5p64x0/include/mach/regs-gpio.h |4 +
>  arch/arm/mach-s5p64x0/mach-smdk6440.c  |   74
> +++
>  arch/arm/mach-s5p64x0/mach-smdk6450.c  |   75
> 
>  arch/arm/mach-s5p64x0/setup-fb-24bpp.c |   29 +
>  arch/arm/plat-samsung/include/plat/fb.h|7 ++
>  drivers/video/s3c-fb.c |   27 +
>  11 files changed, 237 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-s5p64x0/setup-fb-24bpp.c

Looks ok to me, will apply.

But as I said, the 'video: s3c-fb: Add S5P64X0 specific s3c_fb_driverdata'
should be sent to Florian's tree.

I think, it's enough to re-send it to Florian Tobias Schandina.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim , 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 1/3] ARM: EXYNOS4: Add TVOUT support for SMDKV310

[Kukjin Kim]

Hatim Ali wrote:
> 
> Add support for TVOUT on SMDKV310 board.
> 
> Signed-off-by: Hatim Ali 
> ---
> Changes since V1:
> Incorporated changes as suggested by Tomasz Stanislawski
> - Added  GPIO settings for hot-plug detection.
> - Added setting hdmi and mixer's parent for TV power domain.
> 
>  arch/arm/mach-exynos4/Kconfig |2 ++
>  arch/arm/mach-exynos4/mach-smdkv310.c |   25
> +
>  2 files changed, 27 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index 3b594fe..0bf0fe04 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -131,6 +131,7 @@ config MACH_SMDKV310
>   select S3C_DEV_RTC
>   select S3C_DEV_WDT
>   select S3C_DEV_I2C1
> + select S5P_DEV_I2C_HDMIPHY
>   select S5P_DEV_MFC
>   select S3C_DEV_HSMMC
>   select S3C_DEV_HSMMC1
> @@ -140,6 +141,7 @@ config MACH_SMDKV310
>   select EXYNOS4_DEV_AHCI
>   select SAMSUNG_DEV_KEYPAD
>   select EXYNOS4_DEV_PD
> + select S5P_DEV_TV
>   select SAMSUNG_DEV_PWM
>   select EXYNOS4_DEV_SYSMMU
>   select EXYNOS4_SETUP_FIMD0
> diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-
> exynos4/mach-smdkv310.c
> index 7ce4d8b..50de270 100644
> --- a/arch/arm/mach-exynos4/mach-smdkv310.c
> +++ b/arch/arm/mach-exynos4/mach-smdkv310.c
> @@ -239,6 +239,7 @@ static struct platform_device *smdkv310_devices[]
> __initdata = {
>   &s3c_device_hsmmc2,
>   &s3c_device_hsmmc3,
>   &s3c_device_i2c1,
> + &s5p_device_i2c_hdmiphy,
>   &s3c_device_rtc,
>   &s3c_device_wdt,
>   &exynos4_device_ac97,
> @@ -262,6 +263,8 @@ static struct platform_device *smdkv310_devices[]
> __initdata = {
>   &smdkv310_lcd_lte480wv,
>   &smdkv310_smsc911x,
>   &exynos4_device_ahci,
> + &s5p_device_hdmi,
> + &s5p_device_mixer,
>  };
> 
>  static void __init smdkv310_smsc911x_init(void)
> @@ -298,6 +301,25 @@ static struct platform_pwm_backlight_data
> smdkv310_bl_data = {
>   .pwm_period_ns  = 1000,
>  };
> 
> +static void s5p_tv_setup(void)
> +{
> + int ret;
> +
> + /* direct HPD to HDMI chip */
> + ret = gpio_request(EXYNOS4_GPX3(7), "hpd-plug");
> +
> + if (!ret) {
> + gpio_direction_input(EXYNOS4_GPX3(7));
> + s3c_gpio_cfgpin_range(EXYNOS4_GPX3(7),
> + 1, S3C_GPIO_SFN(3));

Why do you use 's3c_gpio_cfgpin_range()' for just one gpio pin not range...?

> + } else
> + pr_err("Failed to request gpio for hpd: %d\n", ret);

According to coding style, should be added { and } around above.

> +
> + /* setup dependencies between TV devices */
> + s5p_device_hdmi.dev.parent = &exynos4_device_pd[PD_TV].dev;
> + s5p_device_mixer.dev.parent = &exynos4_device_pd[PD_TV].dev;
> +}
> +
>  static void __init smdkv310_map_io(void)
>  {
>   s5p_init_io(NULL, 0, S5P_VA_CHIPID);
> @@ -327,6 +349,9 @@ static void __init smdkv310_machine_init(void)
>   samsung_bl_set(&smdkv310_bl_gpio_info, &smdkv310_bl_data);
>   s5p_fimd0_set_platdata(&smdkv310_lcd0_pdata);
> 
> + s5p_tv_setup();
> + s5p_i2c_hdmiphy_set_platdata(NULL);
> +
>   platform_add_devices(smdkv310_devices,
> ARRAY_SIZE(smdkv310_devices));
>   s5p_device_mfc.dev.parent = &exynos4_device_pd[PD_MFC].dev;
>  }
> --
> 1.7.2.3

Thanks.

Best regards,
Kgene.
--
Kukjin Kim , 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: [RESEND PATCH 2/3] ARM: EXYNOS4: Update consistent DMA size to 8MB

[Kukjin Kim]

Hatim Ali wrote:
> 
> Change the consistent DMA allocation to 8MB to support the
> TVOUT driver.
> 
Probably, this conflicts with 'Remove define CONSISTENT_DMA_SIZE'. 

As other guy said, we need to check the progress of it before this.

Thanks.

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


> NOTE: Once CMA support is merged into mainline, we will use it for memory
> allocation.
> 
> Signed-off-by: Hatim Ali 
> ---
>  arch/arm/mach-exynos4/include/mach/memory.h |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos4/include/mach/memory.h b/arch/arm/mach-
> exynos4/include/mach/memory.h
> index 374ef2c..7549742 100644
> --- a/arch/arm/mach-exynos4/include/mach/memory.h
> +++ b/arch/arm/mach-exynos4/include/mach/memory.h
> @@ -15,6 +15,8 @@
> 
>  #define PLAT_PHYS_OFFSET UL(0x4000)
> 
> +#define CONSISTENT_DMA_SIZE  SZ_8M
> +
>  /* Maximum of 256MiB in one bank */
>  #define MAX_PHYSMEM_BITS 32
>  #define SECTION_SIZE_BITS28
> --
> 1.7.2.3

--
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 0/3] ARM: EXYNOS4: Support suspend/resume for EXYNOS4212

[Kukjin Kim]

Jongpill Lee wrote:
> 
> [PATCH V2 1/3] ARM: EXYNOS4: Modify PMU register setting function
> [PATCH V2 2/3] ARM: EXYNOS4: Add PMU register definition for EXYNOS4212
> [PATCH V2 3/3] ARM: EXYNOS4: Support suspend/resume for EXYNOS4212

Would be helpful if you could add changes since previous submitted patches
next time :)

Looks ok to me, will apply.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim , 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 v3 0/4] ARM: Samsung: Add board setup for M-5MOLS and NOON010PC30 camera sensors

[Kukjin Kim]

Sylwester Nawrocki wrote:
> 
> Hello,
> 
> the following change set adds board setup code for NOOON01PC30 sensor on
> GONI
> and M-5MOLS on UNIVERSAL_C210 board.
> Some clocks are modified in line with latest FIMC driver modifications for
v3.2.
> 
> Changes since previous version:
>  - improved error handling, switched to gpio_request_array()
>  - created against git://github.com/kgene/linux-samsung.git for-next
> 
Thanks for your re-submitting :)

> Sylwester Nawrocki (4):
>   ARM: S5PV210: Rename sclk_cam clocks for FIMC media driver
>   ARM: S5PV210: Add support for NOON010PC30 sensor on GONI board
>   ARM: EXYNOS4: Rename sclk_cam clocks for FIMC driver
>   ARM: S5PV210: UNIVERSAL_C210: Add support for M-5MOLS image sensor
> 
>  arch/arm/mach-exynos4/Kconfig   |3 +
>  arch/arm/mach-exynos4/clock.c   |6 +-
>  arch/arm/mach-exynos4/mach-universal_c210.c |  206
> +-
>  arch/arm/mach-s5pv210/Kconfig   |1 +
>  arch/arm/mach-s5pv210/clock.c   |6 +-
>  arch/arm/mach-s5pv210/mach-goni.c   |   53 +++
>  6 files changed, 259 insertions(+), 16 deletions(-)
> --
> 1.7.6.3
> 
> The patches can be pulled from
git://git.infradead.org/users/kmpark/linux-2.6-
> samsung,
> branch samsung-board-camera.
> 
Looks ok to me, will apply.
Thanks.

Best regards,
Kgene.
--
Kukjin Kim , 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: Add header file protection macros

[Kukjin Kim]

Sachin Kamat wrote:
> 
> This patch adds header file protection macros to prevent duplication.
> 
> Signed-off-by: Sachin Kamat 
> ---
>  arch/arm/mach-exynos4/include/mach/pm-core.h |6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos4/include/mach/pm-core.h b/arch/arm/mach-
> exynos4/include/mach/pm-core.h
> index 1df3b81..4c3406b 100644
> --- a/arch/arm/mach-exynos4/include/mach/pm-core.h
> +++ b/arch/arm/mach-exynos4/include/mach/pm-core.h
> @@ -14,6 +14,10 @@
>   * it under the terms of the GNU General Public License version 2 as
>   * published by the Free Software Foundation.
>  */
> +
> +#ifndef __ASM_ARCH_PM_CORE_H
> +#define __ASM_ARCH_PM_CORE_H __FILE__
> +
>  #include 
> 
>  static inline void s3c_pm_debug_init_uart(void)
> @@ -57,3 +61,5 @@ static inline void s3c_pm_saved_gpios(void)
>  {
>   /* nothing here yet */
>  }
> +
> +#endif /* __ASM_ARCH_PM_CORE_H */
> --
> 1.7.4.1

OK, will apply.
Thanks.

Best regards,
Kgene.
--
Kukjin Kim , 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 1/2] mmc: sdhci-s3c: add default controller configuration

[Kukjin Kim]

Thomas Abraham wrote:
> 
> The default controller configuration which was previously setup by
> platform helper functions is moved into the driver.
> 
> Cc: Ben Dooks 
> Signed-off-by: Thomas Abraham 

Acked-by: Kukjin Kim 

Hi Chris,

This is ok to me. Could you please pick this up in your tree so that I can
pick 2nd patch up in my tree.

As you know, this patch has no dependency with patch2/2 so that you can
handle without any conflicts.

Thanks.

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

> ---
>  drivers/mmc/host/sdhci-s3c.c |   28 +---
>  1 files changed, 17 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index 2bd7bf4..d891682 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -203,17 +203,23 @@ static void sdhci_s3c_set_clock(struct sdhci_host
*host,
> unsigned int clock)
>   writel(ctrl, host->ioaddr + S3C_SDHCI_CONTROL2);
>   }
> 
> - /* reconfigure the hardware for new clock rate */
> -
> - {
> - struct mmc_ios ios;
> -
> - ios.clock = clock;
> -
> - if (ourhost->pdata->cfg_card)
> - (ourhost->pdata->cfg_card)(ourhost->pdev, host-
> >ioaddr,
> -&ios, NULL);
> - }
> + /* reprogram default hardware configuration */
> + writel(S3C64XX_SDHCI_CONTROL4_DRIVE_9mA,
> + host->ioaddr + S3C64XX_SDHCI_CONTROL4);
> +
> + ctrl = readl(host->ioaddr + S3C_SDHCI_CONTROL2);
> + ctrl |= (S3C64XX_SDHCI_CTRL2_ENSTAASYNCCLR |
> +   S3C64XX_SDHCI_CTRL2_ENCMDCNFMSK |
> +   S3C_SDHCI_CTRL2_ENFBCLKRX |
> +   S3C_SDHCI_CTRL2_DFCNT_NONE |
> +   S3C_SDHCI_CTRL2_ENCLKOUTHOLD);
> + writel(ctrl, host->ioaddr + S3C_SDHCI_CONTROL2);
> +
> + /* reconfigure the controller for new clock rate */
> + ctrl = (S3C_SDHCI_CTRL3_FCSEL1 | S3C_SDHCI_CTRL3_FCSEL0);
> + if (clock < 25 * 100)
> + ctrl |= (S3C_SDHCI_CTRL3_FCSEL3 |
> S3C_SDHCI_CTRL3_FCSEL2);
> + writel(ctrl, host->ioaddr + S3C_SDHCI_CONTROL3);
>  }
> 
>  /**
> --
> 1.6.6.rc2

--
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 0/2] Move sdhci-s3c platform helper into driver

[Thomas Abraham]

On 21 September 2011 16:21, Kukjin Kim  wrote:
> Thomas Abraham wrote:
>>
>> 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.
>
> Oh, I found :)
> Looks ok to me, will apply.

Thank you Mr. Kim.

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 v2 0/2] Move sdhci-s3c platform helper into driver

[Kukjin Kim]

Thomas Abraham wrote:
> 
> 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.

Oh, I found :)
Looks ok to me, will apply.

As a note, please kindly ignore previous my comments on v.1 patch.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim , 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] arm: samsung: remove sdhci default configuration setup platform helper

[Kukjin Kim]

Thomas Abraham wrote:
> 
> Dear Mr. Kim,
> 
> On 5 September 2011 10:46, Kukjin Kim  wrote:
> > Thomas Abraham wrote:
> >>
> >> 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 
> >> Signed-off-by: Thomas Abraham 
> >> ---
> >>  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/dev-hsmmc.c          |    2 -
> >>  arch/arm/plat-samsung/dev-hsmmc1.c         |    2 -
> >>  arch/arm/plat-samsung/dev-hsmmc2.c         |    2 -
> >>  arch/arm/plat-samsung/dev-hsmmc3.c         |    2 -
> >>  arch/arm/plat-samsung/include/plat/sdhci.h |   57
> > 
> >>  10 files changed, 0 insertions(+), 280 deletions(-)
> >>
> 
> [...]
> 
> >
> > Hi Thomas,
> >
> > The arch/arm/plat-samsung/dev-hsmmcX.c files have been changed due to
> commit
> > 61e62fcb ("ARM: SAMSUNG: Consolidate common function to set SDHCI plat
> > data"). So if possible please make your patch based on latest my
for-next :)
> 
> Sure. I will base these patches on your for-next, test and resubmit.
> 

Hi Thomas,

I missed? I didn't get your updated yet.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim , 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: [RESEND PATCH 2/3] ARM: EXYNOS4: Update consistent DMA size to 8MB

[Tushar Behera]

Hi,

On Wednesday 21 September 2011 12:52 PM, HATIMALI RV wrote:

Hello Mr. Park,

As I mentioned in the cover letter of v1 patch set 
(http://www.spinics.net/lists/arm-kernel/msg138054.html),
this is a temporary patch which is just for testing HDMI on SMDKV310.
Once CMA gets merged, we will be using that to allocate memory.

The macro definition CONSISTENT_DMA_SIZE has been removed and has been 
replaced by a function call. Please refer to this patch.


http://www.spinics.net/lists/linux-samsung-soc/msg06627.html


Thanks for your review.

Regards,
Hatim Ali

--- Original Message ---
Sender : Kyungmin Park
Date   : Sep 21, 2011 11:55 (GMT+05:30)
Title  : Re: [RESEND PATCH 2/3] ARM: EXYNOS4: Update consistent DMA size to 8MB

Hi,

As I know,  CONSISTENT_DMA_SIZE is removed, please use the updated APIs.

Thank you,
Kyungmin Park

On Wed, Sep 21, 2011 at 2:44 PM, Hatim Ali  wrote:

Change the consistent DMA allocation to 8MB to support the
TVOUT driver.

NOTE: Once CMA support is merged into mainline, we will use it for memory
allocation.

Signed-off-by: Hatim Ali
---
  arch/arm/mach-exynos4/include/mach/memory.h |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos4/include/mach/memory.h 
b/arch/arm/mach-exynos4/include/mach/memory.h
index 374ef2c..7549742 100644
--- a/arch/arm/mach-exynos4/include/mach/memory.h
+++ b/arch/arm/mach-exynos4/include/mach/memory.h
@@ -15,6 +15,8 @@

  #define PLAT_PHYS_OFFSET   UL(0x4000)

+#define CONSISTENT_DMA_SIZESZ_8M
+
  /* Maximum of 256MiB in one bank */
  #define MAX_PHYSMEM_BITS   32
  #define SECTION_SIZE_BITS  28
--
1.7.2.3

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


N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±±©¬ºx,¡È§¶›¡Ü¨}©ž²Æ 
zÚ&j:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹®w¥¢¸?™¨è­Ú&¢)ߢfl===



--
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: Re: [RESEND PATCH 2/3] ARM: EXYNOS4: Update consistent DMA size to 8MB

[HATIMALI RV]

Hello Mr. Park,

As I mentioned in the cover letter of v1 patch set 
(http://www.spinics.net/lists/arm-kernel/msg138054.html),
this is a temporary patch which is just for testing HDMI on SMDKV310.
Once CMA gets merged, we will be using that to allocate memory.

Thanks for your review.

Regards,
Hatim Ali

--- Original Message ---
Sender : Kyungmin Park 
Date   : Sep 21, 2011 11:55 (GMT+05:30)
Title  : Re: [RESEND PATCH 2/3] ARM: EXYNOS4: Update consistent DMA size to 8MB

Hi,

As I know,  CONSISTENT_DMA_SIZE is removed, please use the updated APIs.

Thank you,
Kyungmin Park

On Wed, Sep 21, 2011 at 2:44 PM, Hatim Ali  wrote:
> Change the consistent DMA allocation to 8MB to support the
> TVOUT driver.
>
> NOTE: Once CMA support is merged into mainline, we will use it for memory
> allocation.
>
> Signed-off-by: Hatim Ali 
> ---
>  arch/arm/mach-exynos4/include/mach/memory.h |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/include/mach/memory.h 
> b/arch/arm/mach-exynos4/include/mach/memory.h
> index 374ef2c..7549742 100644
> --- a/arch/arm/mach-exynos4/include/mach/memory.h
> +++ b/arch/arm/mach-exynos4/include/mach/memory.h
> @@ -15,6 +15,8 @@
>
>  #define PLAT_PHYS_OFFSET               UL(0x4000)
>
> +#define CONSISTENT_DMA_SIZE            SZ_8M
> +
>  /* Maximum of 256MiB in one bank */
>  #define MAX_PHYSMEM_BITS       32
>  #define SECTION_SIZE_BITS      28
> --
> 1.7.2.3
>
> --
> 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 1/3] include: fb: Add definiton for window positioning structure

[Ajay kumar]

On Wed, Sep 21, 2011 at 11:55 AM, Tomi Valkeinen  wrote:
> On Tue, 2011-09-20 at 20:08 +0300, Baruch Siach wrote:
>> Hi Ajay,
>>
>> On Tue, Sep 20, 2011 at 08:56:57PM +0530, Ajay kumar wrote:
>> > Hi Baruch,
>> > On Tue, Sep 20, 2011 at 4:54 PM, Baruch Siach  wrote:
>> > > Hi Ajay,
>> > >
>> > > On Tue, Sep 20, 2011 at 11:30:39AM -0400, Ajay Kumar wrote:
>> > >> This patch adds a data structure definiton to hold framebuffer 
>> > >> windows/planes.
>> > >> An ioctl number is also added to provide user access
>> > >> to change window position dynamically.
>> > >
>> > > [snip]
>> > >
>> > >> +/* Window overlaying */
>> > >> +struct fb_overlay_win_pos {
>> > >> +     __u32 win_pos_x;        /* x-offset from LCD(0,0) where window 
>> > >> starts */
>> > >> +     __u32 win_pos_y;        /* y-offset from LCD(0,0) where window 
>> > >> starts */
>> > >> +};
>> > >
>> > > Why not allow negative offsets where the left or upper part of the 
>> > > framebuffer
>> > > is hidden?
>> >
>> > Thanks for pointing it out. Are there drivers which place the overlay
>> > windows such that some part of the window is hidden from being
>> > displayed on the screen?
>>
>> I don't know. However, since this is new userspace ABI which should stay
>> compatible forever, we should make sure to do it right. Using __s32 instead 
>> of
>> __u32 won't limit us in the future.
>
> OMAP HW doesn't allow "funny" things like overlay being outside the
> visible area, i.e. negative position or size larger than the display.
> And my guess is that hardware rarely allow things like that, as it would
> just complicate the hardware without any gain.
>
> Out-of-display-overlays can of course be emulated by the software. But
> I'm not sure if it's good to add the complexity in the driver layer, as
> it could as well be handled in the userspace.
>
> Then again, a signed value would be future safer ("just in case"), and
> if the driver can just reject values it doesn't want to support, there's
> no real harm there either.

OK. I will consider this and modify it in the next version of patches.

Ajay
--
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 1/3] include: fb: Add definiton for window positioning structure

[Ajay kumar]

Hi Florian,

On Tue, Sep 20, 2011 at 10:25 PM, Florian Tobias Schandinat
 wrote:
> On 09/20/2011 03:39 PM, Tomi Valkeinen wrote:
>> On Tue, 2011-09-20 at 20:16 +0530, Ajay kumar wrote:
>>> Hi Tomi,
>>>
>>> On Tue, Sep 20, 2011 at 4:40 PM, Tomi Valkeinen  
>>> wrote:
 On Tue, 2011-09-20 at 11:30 -0400, Ajay Kumar wrote:
> This patch adds a data structure definiton to hold framebuffer 
> windows/planes.
> An ioctl number is also added to provide user access
> to change window position dynamically.
>
> Ajay, do you need this urgently or can we delay this one merge window? I don't
> think that a week or so is enough to get a consistent API that gets everything
> right. So if you have a pressing need to have it within the 3.2 kernel I'd
> prefer to do it only for your driver now and adjust it when we get the thing
> done, probably in 3.3.

No. I am not in a hurry, and I do not have any issue even if it takes
more time to get a consistent API.

>
> Signed-off-by: Ajay Kumar 
> Signed-off-by: Banajit Goswami 
> Suggested-by: Marek Szyprowski 
> ---
>  include/linux/fb.h |    7 +++
>  1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 1d6836c..2141941 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -39,6 +39,7 @@
>  #define FBIOPUT_MODEINFO        0x4617
>  #define FBIOGET_DISPINFO        0x4618
>  #define FBIO_WAITFORVSYNC    _IOW('F', 0x20, __u32)
> +#define FBIOPOS_OVERLAY_WIN  _IOW('F', 0x21, struct fb_overlay_win_pos)
>
>  #define FB_TYPE_PACKED_PIXELS                0       /* Packed Pixels    
>     */
>  #define FB_TYPE_PLANES                       1       /* Non interleaved 
> planes */
> @@ -366,6 +367,12 @@ struct fb_image {
>       struct fb_cmap cmap;    /* color map info */
>  };
>
> +/* Window overlaying */
> +struct fb_overlay_win_pos {
> +     __u32 win_pos_x;        /* x-offset from LCD(0,0) where window 
> starts */
> +     __u32 win_pos_y;        /* y-offset from LCD(0,0) where window 
> starts */
> +};

 Shouldn't this also include the window size (in case scaling is
 supported)?
>>>
>>> The "xres" and "yres" fields in fb_var_screeninfo are being used to
>>> represent the size of the window (visible resolution). So we have,
>>>
>>> win_pos_x: x-offset from LCD(0,0) where window starts.
>>> win_pos_y: y-offset from LCD(0,0) where window starts.
>>> (win_pos_x + xres) : x-offset from LCD(0,0) where window ends.
>>> (win_pos_y + yres) : y-offset from LCD(0,0) where window ends.
>>
>> Sure, but the xres and yres tell the _input_ resolution, i.e. how many
>> pixels are read from the memory. What is missing is the _output_
>> resolution, which is the size of the window. These are not necessarily
>> the same, if the system supports scaling.
>
> I agree, scaling is an issue that should get solved on the way. So adding
> u32 width, height;
> with an initial/special value of 0 which means just take what the source
> width/height is.

Do you mean to say the "width" and the "height" fields which you are
suggesting, will represent the "output resolution" which OMAP needs?

 This also won't work for setups where the same framebuffer is used by
 multiple overlays. For example, this is the case on OMAP when the same
 content is cloned to, say, LCD and TV, each of which is showing an
 overlay.
>>>
>>> These x and y position are used to configure the display controller
>>> (for LCD only) and not to alter the data in physical buffer
>>> (framebuffer). Could you elaborate the above use case you have
>>> mentioned and how adding the x and y offsets would not meet that
>>> requirement.
>>
>> Nothing wrong with adding x/y offsets, but the problem is in configuring
>> the two overlays. If the framebuffer data is used by two overlays, each
>> overlay should be configured separately. And your ioctl does not have
>> any way to define which overlay is being affected.
>
> Did you have a look at the (existing) API [1] Laurent proposed for discovering
> the internal connections between the framebuffers (or with any other devices)?
> If you agree that it'd be a good idea to use it I feel that we should make the
> windowing API more compatible with it. So basically what we want to have as a
> window is one or more sunk pads so the pad-index should be also part of the
> interface. I'm still confused with how OMAP works when it does not have a 
> "root"
> window/framebuffer. Normally I feel that the window position should be a
> property of the parent window as this is what the position is relative too. 
> But
> if the parent is no framebuffer, should we also include the entity into the
> interface to allow configuring things that are nor even framebuffers?
> Also I think we need a z-index in case overlays overlap (might happen or?) and
> enforcing that all z-indexes