All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Dooks <ben-linux@fluff.org>
To: Kukjin Kim <kgene.kim@samsung.com>
Cc: linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org,
	Lee Hyuk <hyuk1.lee@samsung.com>,
	ben-linux@fluff.org
Subject: Re: [PATCH 2/3] ARM: S5PV210: Add support SDMMC WP through EXT_INT on SMDKV210
Date: Tue, 15 Jun 2010 12:59:47 +0100	[thread overview]
Message-ID: <20100615115947.GC7248@trinity.fluff.org> (raw)
In-Reply-To: <1276601268-7226-3-git-send-email-kgene.kim@samsung.com>

On Tue, Jun 15, 2010 at 08:27:47PM +0900, Kukjin Kim wrote:
> From: Lee Hyuk <hyuk1.lee@samsung.com>
> 
> S5PV210 HSMMC host controller doesn't have the Write Protection pin which
> should be connnected with SDMMC card WP pin. So allocated a GPIO in order to
> get the data from SDMMC card WP pin with EXT_INT and implement get_ro and
> cfg_wp function.
> 
> Signed-off-by: Hyuk Lee <hyuk1.lee@samsung.com>
> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
> ---
>  arch/arm/mach-s5pv210/mach-smdkv210.c |    2 +
>  arch/arm/mach-s5pv210/setup-sdhci.c   |   72 +++++++++++++++++++++++++++++++++
>  2 files changed, 74 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-s5pv210/mach-smdkv210.c b/arch/arm/mach-s5pv210/mach-smdkv210.c
> index b08f376..18cdb8c 100644
> --- a/arch/arm/mach-s5pv210/mach-smdkv210.c
> +++ b/arch/arm/mach-s5pv210/mach-smdkv210.c
> @@ -27,6 +27,7 @@
>  #include <plat/cpu.h>
>  #include <plat/adc.h>
>  #include <plat/ts.h>
> +#include <plat/sdhci.h>
>  
>  /* Following are default values for UCON, ULCON and UFCON UART registers */
>  #define S5PV210_UCON_DEFAULT	(S3C2410_UCON_TXILEVEL |	\
> @@ -101,6 +102,7 @@ static void __init smdkv210_map_io(void)
>  static void __init smdkv210_machine_init(void)
>  {
>  	s3c24xx_ts_set_platdata(&s3c_ts_platform);
> +	s3c_sdhci_set_platdata();

hmm, did you really want to call it this? also, no argument specified.

>  	platform_add_devices(smdkv210_devices, ARRAY_SIZE(smdkv210_devices));
>  }
>  
> diff --git a/arch/arm/mach-s5pv210/setup-sdhci.c b/arch/arm/mach-s5pv210/setup-sdhci.c
> index 51815ec..b553b36 100644
> --- a/arch/arm/mach-s5pv210/setup-sdhci.c
> +++ b/arch/arm/mach-s5pv210/setup-sdhci.c
> @@ -15,13 +15,17 @@
>  #include <linux/interrupt.h>
>  #include <linux/platform_device.h>
>  #include <linux/io.h>
> +#include <linux/gpio.h>
>  
>  #include <linux/mmc/card.h>
>  #include <linux/mmc/host.h>
>  
> +#include <plat/gpio-cfg.h>
>  #include <plat/regs-sdhci.h>
>  #include <plat/sdhci.h>
>  
> +#include <mach/map.h>
> +
>  /* clock sources for the mmc bus clock, order as for the ctrl2[5..4] */
>  
>  char *s5pv210_hsmmc_clksrcs[4] = {
> @@ -61,3 +65,71 @@ void s5pv210_setup_sdhci_cfg_card(struct platform_device *dev,
>  	writel(ctrl2, r + S3C_SDHCI_CONTROL2);
>  	writel(ctrl3, r + S3C_SDHCI_CONTROL3);
>  }
> +
> +static int s5pv210_sdhci_get_ro(struct mmc_host *mmc)
> +{
> +	int gpio_dat;
> +
> +	if ((mmc->index == 0 && s3c_hsmmc0_def_platdata.cfg_wp != NULL) ||
> +		(mmc->index == 1 && s3c_hsmmc1_def_platdata.cfg_wp != NULL)) {
> +		gpio_dat = __raw_readl((S5P_VA_GPIO + 0xC00) + 0x04);
> +		return !!(gpio_dat & 0x80);
> +	} else if (mmc->index == 2 && s3c_hsmmc2_def_platdata.cfg_wp != NULL) {
> +		gpio_dat = __raw_readl((S5P_VA_GPIO + 0xC00) + 0x64);
> +		return !!(gpio_dat & 0x2);
> +	} else if (mmc->index == 3 && s3c_hsmmc3_def_platdata.cfg_wp != NULL) {
> +		gpio_dat = __raw_readl((S5P_VA_GPIO + 0xC00) + 0x24);
> +		return !!(gpio_dat & 0x1);
> +	} else
> +		return 0;

Why not use the gpio layer? really, this sort of thing is what it is
there for.

> +}
> +
> +static void s5pv210_setup_sdhci_gpio_wp(int dev_id)
> +{
> +	switch (dev_id) {
> +	case 0:
> +	case 1:
> +		s3c_gpio_cfgpin(S5PV210_GPH0(7), S3C_GPIO_INPUT);
> +		s3c_gpio_setpull(S5PV210_GPH0(7), S3C_GPIO_PULL_UP);
> +		break;
> +	case 2:
> +		s3c_gpio_cfgpin(S5PV210_GPH3(1), S3C_GPIO_INPUT);
> +		s3c_gpio_setpull(S5PV210_GPH3(1), S3C_GPIO_PULL_UP);
> +		break;
> +	case 3:
> +		s3c_gpio_cfgpin(S5PV210_GPH1(0), S3C_GPIO_INPUT);
> +		s3c_gpio_setpull(S5PV210_GPH1(0), S3C_GPIO_PULL_UP);
> +		break;
> +	default:
> +		break;

again, if you'd use the gpio layer, at-lesat the cfgpin() wouldn't
have been necessary.

> +	}
> +}
> +
> +static struct s3c_sdhci_platdata hsmmc0_platdata = {
> +	.cfg_wp         = s5pv210_setup_sdhci_gpio_wp,
> +	.get_ro         = s5pv210_sdhci_get_ro,
> +};
> +
> +static struct s3c_sdhci_platdata hsmmc1_platdata = {
> +	.cfg_wp         = s5pv210_setup_sdhci_gpio_wp,
> +	.get_ro         = s5pv210_sdhci_get_ro,
> +};
> +
> +static struct s3c_sdhci_platdata hsmmc2_platdata = {
> +	.cfg_wp         = s5pv210_setup_sdhci_gpio_wp,
> +	.get_ro         = s5pv210_sdhci_get_ro,
> +};
> +
> +static struct s3c_sdhci_platdata hsmmc3_platdata = {
> +	.cfg_wp         = s5pv210_setup_sdhci_gpio_wp,
> +	.get_ro         = s5pv210_sdhci_get_ro,
> +};
> +
> +void s3c_sdhci_set_platdata(void)
> +{
> +	s3c_sdhci0_set_platdata(&hsmmc0_platdata);
> +	s3c_sdhci1_set_platdata(&hsmmc1_platdata);
> +	s3c_sdhci2_set_platdata(&hsmmc2_platdata);
> +	s3c_sdhci3_set_platdata(&hsmmc3_platdata);
> +}
> +EXPORT_SYMBOL(s3c_sdhci_set_platdata);

There is _NO NEED_ to export these, they really should not be used outside
of the machine initialisation.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

WARNING: multiple messages have this Message-ID (diff)
From: ben-linux@fluff.org (Ben Dooks)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] ARM: S5PV210: Add support SDMMC WP through EXT_INT on SMDKV210
Date: Tue, 15 Jun 2010 12:59:47 +0100	[thread overview]
Message-ID: <20100615115947.GC7248@trinity.fluff.org> (raw)
In-Reply-To: <1276601268-7226-3-git-send-email-kgene.kim@samsung.com>

On Tue, Jun 15, 2010 at 08:27:47PM +0900, Kukjin Kim wrote:
> From: Lee Hyuk <hyuk1.lee@samsung.com>
> 
> S5PV210 HSMMC host controller doesn't have the Write Protection pin which
> should be connnected with SDMMC card WP pin. So allocated a GPIO in order to
> get the data from SDMMC card WP pin with EXT_INT and implement get_ro and
> cfg_wp function.
> 
> Signed-off-by: Hyuk Lee <hyuk1.lee@samsung.com>
> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
> ---
>  arch/arm/mach-s5pv210/mach-smdkv210.c |    2 +
>  arch/arm/mach-s5pv210/setup-sdhci.c   |   72 +++++++++++++++++++++++++++++++++
>  2 files changed, 74 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-s5pv210/mach-smdkv210.c b/arch/arm/mach-s5pv210/mach-smdkv210.c
> index b08f376..18cdb8c 100644
> --- a/arch/arm/mach-s5pv210/mach-smdkv210.c
> +++ b/arch/arm/mach-s5pv210/mach-smdkv210.c
> @@ -27,6 +27,7 @@
>  #include <plat/cpu.h>
>  #include <plat/adc.h>
>  #include <plat/ts.h>
> +#include <plat/sdhci.h>
>  
>  /* Following are default values for UCON, ULCON and UFCON UART registers */
>  #define S5PV210_UCON_DEFAULT	(S3C2410_UCON_TXILEVEL |	\
> @@ -101,6 +102,7 @@ static void __init smdkv210_map_io(void)
>  static void __init smdkv210_machine_init(void)
>  {
>  	s3c24xx_ts_set_platdata(&s3c_ts_platform);
> +	s3c_sdhci_set_platdata();

hmm, did you really want to call it this? also, no argument specified.

>  	platform_add_devices(smdkv210_devices, ARRAY_SIZE(smdkv210_devices));
>  }
>  
> diff --git a/arch/arm/mach-s5pv210/setup-sdhci.c b/arch/arm/mach-s5pv210/setup-sdhci.c
> index 51815ec..b553b36 100644
> --- a/arch/arm/mach-s5pv210/setup-sdhci.c
> +++ b/arch/arm/mach-s5pv210/setup-sdhci.c
> @@ -15,13 +15,17 @@
>  #include <linux/interrupt.h>
>  #include <linux/platform_device.h>
>  #include <linux/io.h>
> +#include <linux/gpio.h>
>  
>  #include <linux/mmc/card.h>
>  #include <linux/mmc/host.h>
>  
> +#include <plat/gpio-cfg.h>
>  #include <plat/regs-sdhci.h>
>  #include <plat/sdhci.h>
>  
> +#include <mach/map.h>
> +
>  /* clock sources for the mmc bus clock, order as for the ctrl2[5..4] */
>  
>  char *s5pv210_hsmmc_clksrcs[4] = {
> @@ -61,3 +65,71 @@ void s5pv210_setup_sdhci_cfg_card(struct platform_device *dev,
>  	writel(ctrl2, r + S3C_SDHCI_CONTROL2);
>  	writel(ctrl3, r + S3C_SDHCI_CONTROL3);
>  }
> +
> +static int s5pv210_sdhci_get_ro(struct mmc_host *mmc)
> +{
> +	int gpio_dat;
> +
> +	if ((mmc->index == 0 && s3c_hsmmc0_def_platdata.cfg_wp != NULL) ||
> +		(mmc->index == 1 && s3c_hsmmc1_def_platdata.cfg_wp != NULL)) {
> +		gpio_dat = __raw_readl((S5P_VA_GPIO + 0xC00) + 0x04);
> +		return !!(gpio_dat & 0x80);
> +	} else if (mmc->index == 2 && s3c_hsmmc2_def_platdata.cfg_wp != NULL) {
> +		gpio_dat = __raw_readl((S5P_VA_GPIO + 0xC00) + 0x64);
> +		return !!(gpio_dat & 0x2);
> +	} else if (mmc->index == 3 && s3c_hsmmc3_def_platdata.cfg_wp != NULL) {
> +		gpio_dat = __raw_readl((S5P_VA_GPIO + 0xC00) + 0x24);
> +		return !!(gpio_dat & 0x1);
> +	} else
> +		return 0;

Why not use the gpio layer? really, this sort of thing is what it is
there for.

> +}
> +
> +static void s5pv210_setup_sdhci_gpio_wp(int dev_id)
> +{
> +	switch (dev_id) {
> +	case 0:
> +	case 1:
> +		s3c_gpio_cfgpin(S5PV210_GPH0(7), S3C_GPIO_INPUT);
> +		s3c_gpio_setpull(S5PV210_GPH0(7), S3C_GPIO_PULL_UP);
> +		break;
> +	case 2:
> +		s3c_gpio_cfgpin(S5PV210_GPH3(1), S3C_GPIO_INPUT);
> +		s3c_gpio_setpull(S5PV210_GPH3(1), S3C_GPIO_PULL_UP);
> +		break;
> +	case 3:
> +		s3c_gpio_cfgpin(S5PV210_GPH1(0), S3C_GPIO_INPUT);
> +		s3c_gpio_setpull(S5PV210_GPH1(0), S3C_GPIO_PULL_UP);
> +		break;
> +	default:
> +		break;

again, if you'd use the gpio layer, at-lesat the cfgpin() wouldn't
have been necessary.

> +	}
> +}
> +
> +static struct s3c_sdhci_platdata hsmmc0_platdata = {
> +	.cfg_wp         = s5pv210_setup_sdhci_gpio_wp,
> +	.get_ro         = s5pv210_sdhci_get_ro,
> +};
> +
> +static struct s3c_sdhci_platdata hsmmc1_platdata = {
> +	.cfg_wp         = s5pv210_setup_sdhci_gpio_wp,
> +	.get_ro         = s5pv210_sdhci_get_ro,
> +};
> +
> +static struct s3c_sdhci_platdata hsmmc2_platdata = {
> +	.cfg_wp         = s5pv210_setup_sdhci_gpio_wp,
> +	.get_ro         = s5pv210_sdhci_get_ro,
> +};
> +
> +static struct s3c_sdhci_platdata hsmmc3_platdata = {
> +	.cfg_wp         = s5pv210_setup_sdhci_gpio_wp,
> +	.get_ro         = s5pv210_sdhci_get_ro,
> +};
> +
> +void s3c_sdhci_set_platdata(void)
> +{
> +	s3c_sdhci0_set_platdata(&hsmmc0_platdata);
> +	s3c_sdhci1_set_platdata(&hsmmc1_platdata);
> +	s3c_sdhci2_set_platdata(&hsmmc2_platdata);
> +	s3c_sdhci3_set_platdata(&hsmmc3_platdata);
> +}
> +EXPORT_SYMBOL(s3c_sdhci_set_platdata);

There is _NO NEED_ to export these, they really should not be used outside
of the machine initialisation.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

  parent reply	other threads:[~2010-06-15 11:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-15 11:27 ARM: S5PV210: Add support SDMMC Write Protection on SMDKV210 Kukjin Kim
2010-06-15 11:27 ` Kukjin Kim
2010-06-15 11:27 ` [PATCH 1/3] ARM: SAMSUNG: Add the member of platdata to implement SDMMC Write Protection Kukjin Kim
2010-06-15 11:27   ` Kukjin Kim
2010-06-15 12:02   ` Ben Dooks
2010-06-15 12:02     ` Ben Dooks
2010-07-03  1:15     ` Kukjin Kim
2010-07-03  1:15       ` Kukjin Kim
2010-06-15 11:27 ` [PATCH 2/3] ARM: S5PV210: Add support SDMMC WP through EXT_INT on SMDKV210 Kukjin Kim
2010-06-15 11:27   ` Kukjin Kim
2010-06-15 11:52   ` Kyungmin Park
2010-06-15 11:52     ` Kyungmin Park
2010-07-03  1:08     ` Kukjin Kim
2010-07-03  1:08       ` Kukjin Kim
2010-06-15 11:53   ` Maurus Cuelenaere
2010-06-15 11:53     ` Maurus Cuelenaere
2010-07-03  1:11     ` Kukjin Kim
2010-07-03  1:11       ` Kukjin Kim
2010-06-15 11:59   ` Ben Dooks [this message]
2010-06-15 11:59     ` Ben Dooks
2010-07-03  1:14     ` Kukjin Kim
2010-07-03  1:14       ` Kukjin Kim
2010-06-15 11:27 ` [PATCH 3/3] sdhci-s3c: Add SDHCI_QUIRK_NO_WP_BIT for Samsung SoC Kukjin Kim
2010-06-15 11:27   ` Kukjin Kim
2010-06-15 12:04   ` Ben Dooks
2010-06-15 12:04     ` Ben Dooks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100615115947.GC7248@trinity.fluff.org \
    --to=ben-linux@fluff.org \
    --cc=hyuk1.lee@samsung.com \
    --cc=kgene.kim@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.