Re: [PATCH 1/6] ARM: S3C24XX: Add forgotten clock lookup table to S3C2443
Am Montag 02 April 2012, 23:08:10 schrieb Kukjin Kim:
> Heiko Stübner wrote:
> > When the hsmmc clock lookup was changed to be lookup tables based,
> > it seems the S3C2443 was forgotten.
> >
> > As subsequent patches will want to add more lookups to it, this
> > patch adds the base table with the missing hsmmc lookup.
> >
> > Signed-off-by: Heiko Stuebner
> > ---
> >
> > arch/arm/mach-s3c24xx/clock-s3c2443.c |5 +
> > 1 files changed, 5 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-s3c24xx/clock-s3c2443.c
> > b/arch/arm/mach-s3c24xx/clock-s3c2443.c index efb3ac3..bce1cd3 100644
> > --- a/arch/arm/mach-s3c24xx/clock-s3c2443.c
> > +++ b/arch/arm/mach-s3c24xx/clock-s3c2443.c
> > @@ -179,6 +179,10 @@ static struct clk *clks[] __initdata = {
> >
> > &clk_hsmmc,
> >
> > };
> >
> > +static struct clk_lookup s3c2443_clk_lookup[] = {
> > + CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.2",&clk_hsmmc),
> > +};
> > +
> >
> > void __init s3c2443_init_clocks(int xtal)
> > {
> >
> > unsigned long epllcon = __raw_readl(S3C2443_EPLLCON);
> >
> > @@ -210,6 +214,7 @@ void __init s3c2443_init_clocks(int xtal)
> >
> > s3c_register_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
> > s3c_disable_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
> >
> > + clkdev_add_table(s3c2443_clk_lookup, ARRAY_SIZE(s3c2443_clk_lookup));
> >
> > s3c_pwmclk_init();
> >
> > }
>
> Uhm..how about mach-s3c24xx/common-s3c2443.c?
Nope. This clock is really specific to only the s3c2443. There is only one
hsmmc clock that is identical on both the s3c2443 and s3c2416/2450 and this
one already is in common-s3c2443.c .
common-s3c2443.c was meant for stuff common to s3c2443 _and newer_, i.e.
common clocks and so on.
> I think, we need to sort out some files in mach-s3c24xx/ and some
> remained mach-s3c24.. directories, actually, as you know, we didn't have
> much time to do it last time :)
yeah, we did cut it quite close :-), but it also doesn't seem to have produced
much fall-out. I moved my s3c2416 based development code to 3.4-rc1 without
major hickups.
Getting rid of the remaining mach-directories and also the plat-s3c24xx would
be good. But I'm not sure what you would want to change in mach-s3c24xx
directory itself.
I don't know the earlier SoCs, but the s3c2443 and s3c2416/2450 SoCs currently
don't have redundancies and in the current layout it's quite easy to
understand what belongs to which SoC.
Heiko
--
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: S3C64XX: Hook up new style regulator-regulator supplies on Cragganmore
On Mon, Apr 02, 2012 at 12:05:53PM -0700, Kukjin Kim wrote: > Mark, is this needed for v3.4? No. signature.asc Description: Digital signature
Re: [PATCH 1/6] ARM: S3C24XX: Add forgotten clock lookup table to S3C2443
Heiko Stübner wrote:
When the hsmmc clock lookup was changed to be lookup tables based,
it seems the S3C2443 was forgotten.
As subsequent patches will want to add more lookups to it, this
patch adds the base table with the missing hsmmc lookup.
Signed-off-by: Heiko Stuebner
---
arch/arm/mach-s3c24xx/clock-s3c2443.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/clock-s3c2443.c
b/arch/arm/mach-s3c24xx/clock-s3c2443.c
index efb3ac3..bce1cd3 100644
--- a/arch/arm/mach-s3c24xx/clock-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/clock-s3c2443.c
@@ -179,6 +179,10 @@ static struct clk *clks[] __initdata = {
&clk_hsmmc,
};
+static struct clk_lookup s3c2443_clk_lookup[] = {
+ CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.2",&clk_hsmmc),
+};
+
void __init s3c2443_init_clocks(int xtal)
{
unsigned long epllcon = __raw_readl(S3C2443_EPLLCON);
@@ -210,6 +214,7 @@ void __init s3c2443_init_clocks(int xtal)
s3c_register_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
s3c_disable_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
+ clkdev_add_table(s3c2443_clk_lookup, ARRAY_SIZE(s3c2443_clk_lookup));
s3c_pwmclk_init();
}
Uhm..how about mach-s3c24xx/common-s3c2443.c?
I think, we need to sort out some files in mach-s3c24xx/ and some
remained mach-s3c24.. directories, actually, as you know, we didn't have
much time to do it last time :)
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: EXYNOS: autodetect enabled serial port in uncompress
Hi,
On Tue, Apr 3, 2012 at 4:17 AM, Kukjin Kim wrote:
> From: Colin Cross
>
> Check the ULCON register of each serial port to determine if
> it has been enabled by the bootloader. If only one serial port
> is found enabled, use that one. Otherwise, use the value from
> CONFIG_S3C_LOWLEVEL_UART_PORT.
>
> Signed-off-by: Colin Cross
> Signed-off-by: Kukjin Kim
> ---
> arch/arm/mach-exynos/include/mach/uncompress.h | 25 ++-
> 1 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/include/mach/uncompress.h
> b/arch/arm/mach-exynos/include/mach/uncompress.h
> index 2979995..0d17a43 100644
> --- a/arch/arm/mach-exynos/include/mach/uncompress.h
> +++ b/arch/arm/mach-exynos/include/mach/uncompress.h
> @@ -25,6 +25,25 @@ static unsigned int __raw_readl(unsigned int ptr)
> return *((volatile unsigned int *)ptr);
> }
>
> +static volatile u8 *exynos_autodetect_uart(volatile u8 *base)
> +{
> + int i;
> + int found = 0;
> + int port;
> +
> + for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++) {
> + if (__raw_readl((unsigned int)base + S3C_UART_OFFSET * i)) {
1. Even though ULCON has offset 0, it's better to add ULCON_OFFSET.
2. In our case, we disable the unused UART at bootloader except the
debug uart, then does it possible to read this value at kernel?
I think it's hang at here. So read it correctly it should enable the
required uart clock before read it.
3. As similar tegra, how about to read specific value from RX
register. e.g., 'D'?
> + port = i;
> + found++;
To match the description, it should brake at here. if not it detects
the last uart at several detected uarts.
BR,
kmpark
> + }
> + }
> +
> + if (found != 1)
> + port = CONFIG_S3C_LOWLEVEL_UART_PORT;
> +
> + return base + S3C_UART_OFFSET * port;
> +}
> +
> static void arch_detect_cpu(void)
> {
> u32 chip_id = __raw_readl(EXYNOS_PA_CHIPID);
> @@ -38,9 +57,11 @@ static void arch_detect_cpu(void)
> chip_id &= 0xf;
>
> if (chip_id == 0x5)
> - uart_base = (volatile u8 *)EXYNOS5_PA_UART + (S3C_UART_OFFSET
> * CONFIG_S3C_LOWLEVEL_UART_PORT);
> + uart_base = (volatile u8 *)EXYNOS5_PA_UART;
> else
> - uart_base = (volatile u8 *)EXYNOS4_PA_UART + (S3C_UART_OFFSET
> * CONFIG_S3C_LOWLEVEL_UART_PORT);
> + uart_base = (volatile u8 *)EXYNOS4_PA_UART;
> +
> + uart_base = exynos_autodetect_uart(uart_base);
>
> /*
> * For preventing FIFO overrun or infinite loop of UART console,
> --
> 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
--
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/6] S3C24XX: Add support for HSSPI on S3C2416/S3C2443
Heiko Stübner wrote: Am Montag 12 März 2012, 19:59:32 schrieb Heiko Stübner: The S3C2416/S3C2443/S3C2450 SoCs contain HSSPI controllers compatible with the ones in the S3C64xx and later. The second patch modifying the dma selection depends on the series enabling the dma support on the S3C2416, but as the whole s3c64xx-spi driver needs dma support this should be ok. Tested on an Asus DR-900 ebook reader with a Marvell MR8686 using the libertas driver. This is a repost of the series adapted to changes resulting from the other cleanup series. ping :-) Thanks for your reminder ;) Let me review it soon. 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: S3C24XX: add support for second irq set of S3C2416
Am Samstag 03 März 2012, 22:19:45 schrieb Heiko Stübner:
> The S3C2416 has a separate second interrupt register-set to support
> additional irqs. This patch adds the necessary constants and registers
> the irq handlers for it.
>
> Signed-off-by: Heiko Stuebner
and also "ping" :-)
Thanks
Heiko
> ---
> Patch should go on top of the current s3c24xx consolidation
>
> arch/arm/mach-s3c24xx/include/mach/irqs.h| 15 -
> arch/arm/mach-s3c24xx/irq-s3c2416.c | 98
> ++ arch/arm/mach-s3c24xx/s3c2416.c |
> 1 +
> arch/arm/plat-samsung/include/plat/s3c2416.h |3 +
> 4 files changed, 116 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-s3c24xx/include/mach/irqs.h
> b/arch/arm/mach-s3c24xx/include/mach/irqs.h index e53b217..e120576 100644
> --- a/arch/arm/mach-s3c24xx/include/mach/irqs.h
> +++ b/arch/arm/mach-s3c24xx/include/mach/irqs.h
> @@ -134,6 +134,17 @@
> #define IRQ_S32416_WDT S3C2410_IRQSUB(27)
> #define IRQ_S32416_AC97 S3C2410_IRQSUB(28)
>
> +/* second interrupt-register of s3c2416/s3c2450 */
> +
> +#define S3C2416_IRQ(x) S3C2410_IRQ((x)+54+29)
> +#define IRQ_S3C2416_2D S3C2416_IRQ(0)
> +#define IRQ_S3C2416_IIC1 S3C2416_IRQ(1)
> +#define IRQ_S3C2416_RESERVED2S3C2416_IRQ(2)
> +#define IRQ_S3C2416_RESERVED3S3C2416_IRQ(3)
> +#define IRQ_S3C2416_PCM0 S3C2416_IRQ(4)
> +#define IRQ_S3C2416_PCM1 S3C2416_IRQ(5)
> +#define IRQ_S3C2416_I2S0 S3C2416_IRQ(6)
> +#define IRQ_S3C2416_I2S1 S3C2416_IRQ(7)
>
> /* extra irqs for s3c2440 */
>
> @@ -175,7 +186,9 @@
> #define IRQ_S3C2443_WDT S3C2410_IRQSUB(27)
> #define IRQ_S3C2443_AC97 S3C2410_IRQSUB(28)
>
> -#if defined(CONFIG_CPU_S3C2443) || defined(CONFIG_CPU_S3C2416)
> +#if defined(CONFIG_CPU_S3C2416)
> +#define NR_IRQS (IRQ_S3C2416_I2S1+1)
> +#elif defined(CONFIG_CPU_S3C2443)
> #define NR_IRQS (IRQ_S3C2443_AC97+1)
> #else
> #define NR_IRQS (IRQ_S3C2440_AC97+1)
> diff --git a/arch/arm/mach-s3c24xx/irq-s3c2416.c
> b/arch/arm/mach-s3c24xx/irq-s3c2416.c index fd49f35..d92f879 100644
> --- a/arch/arm/mach-s3c24xx/irq-s3c2416.c
> +++ b/arch/arm/mach-s3c24xx/irq-s3c2416.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -192,6 +193,43 @@ static struct irq_chip s3c2416_irq_uart3 = {
> .irq_ack= s3c2416_irq_uart3_ack,
> };
>
> +/* second interrupt register */
> +
> +static inline void s3c2416_irq_ack_second(struct irq_data *data)
> +{
> + unsigned long bitval = 1UL << (data->irq - IRQ_S3C2416_2D);
> +
> + __raw_writel(bitval, S3C2416_SRCPND2);
> + __raw_writel(bitval, S3C2416_INTPND2);
> +}
> +
> +static void s3c2416_irq_mask_second(struct irq_data *data)
> +{
> + unsigned long bitval = 1UL << (data->irq - IRQ_S3C2416_2D);
> + unsigned long mask;
> +
> + mask = __raw_readl(S3C2416_INTMSK2);
> + mask |= bitval;
> + __raw_writel(mask, S3C2416_INTMSK2);
> +}
> +
> +static void s3c2416_irq_unmask_second(struct irq_data *data)
> +{
> + unsigned long bitval = 1UL << (data->irq - IRQ_S3C2416_2D);
> + unsigned long mask;
> +
> + mask = __raw_readl(S3C2416_INTMSK2);
> + mask &= ~bitval;
> + __raw_writel(mask, S3C2416_INTMSK2);
> +}
> +
> +struct irq_chip s3c2416_irq_second = {
> + .irq_ack= s3c2416_irq_ack_second,
> + .irq_mask = s3c2416_irq_mask_second,
> + .irq_unmask = s3c2416_irq_unmask_second,
> +};
> +
> +
> /* IRQ initialisation code */
>
> static int __init s3c2416_add_sub(unsigned int base,
> @@ -213,6 +251,42 @@ static int __init s3c2416_add_sub(unsigned int base,
> return 0;
> }
>
> +static void __init s3c2416_add_second(void)
> +{
> + unsigned long pend;
> + unsigned long last;
> + int irqno;
> + int i;
> +
> + /* first, clear all interrupts pending... */
> + last = 0;
> + for (i = 0; i < 4; i++) {
> + pend = __raw_readl(S3C2416_INTPND2);
> +
> + if (pend == 0 || pend == last)
> + break;
> +
> + __raw_writel(pend, S3C2416_SRCPND2);
> + __raw_writel(pend, S3C2416_INTPND2);
> + printk(KERN_INFO "irq: clearing pending status %08x\n",
> +(int)pend);
> + last = pend;
> + }
> +
> + for (irqno = IRQ_S3C2416_2D; irqno <= IRQ_S3C2416_I2S1; irqno++) {
> + switch (irqno) {
> + case IRQ_S3C2416_RESERVED2:
> + case IRQ_S3C2416_RESERVED3:
> + /* no IRQ here */
> + break;
> + default:
> + irq_set_chip_and_handler(irqno, &s3c2416_irq_second,
> + handle_edge_irq);
> + set_irq_flags(irqno, IRQF_VALID);
> + }
> + }
> +}
> +
> static int __init s3c2416_irq_add(struct device *dev,
>
Re: [PATCH 0/6] S3C24XX: Add support for HSSPI on S3C2416/S3C2443
Am Montag 12 März 2012, 19:59:32 schrieb Heiko Stübner: > The S3C2416/S3C2443/S3C2450 SoCs contain HSSPI controllers compatible > with the ones in the S3C64xx and later. > > The second patch modifying the dma selection depends on the series > enabling the dma support on the S3C2416, but as the whole s3c64xx-spi > driver needs dma support this should be ok. > > Tested on an Asus DR-900 ebook reader with a Marvell MR8686 using the > libertas driver. > > > This is a repost of the series adapted to changes resulting from the > other cleanup series. ping :-) Thanks Heiko > > Heiko Stuebner (6): > ARM: S3C24XX: Add forgotten clock lookup table to S3C2443 > ARM: S3C24XX: claim spi channels for hsspi in dma-s3c2443 > ARM: S3C24XX: Add map entries needed by the s3c64xx-spi devices > ARM: S3C24XX: Add clock-lookup entries required by s3c64xx-spi > ARM: S3C24XX: Add HSSPI setup callback for s3c64xx-spi driver > spi/s3c64xx: Allow usage for ARCH_S3C24XX > > arch/arm/mach-s3c24xx/Kconfig|5 > arch/arm/mach-s3c24xx/Makefile |1 + > arch/arm/mach-s3c24xx/clock-s3c2416.c|1 + > arch/arm/mach-s3c24xx/clock-s3c2443.c|6 > arch/arm/mach-s3c24xx/common-s3c2443.c | 15 +++ > arch/arm/mach-s3c24xx/dma-s3c2443.c | 16 +--- > arch/arm/mach-s3c24xx/include/mach/dma.h |4 +++ > arch/arm/mach-s3c24xx/include/mach/map.h |5 > arch/arm/mach-s3c24xx/setup-spi.c| 39 > ++ drivers/spi/Kconfig | > 2 +- > 10 files changed, 84 insertions(+), 10 deletions(-) > create mode 100644 arch/arm/mach-s3c24xx/setup-spi.c -- 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: EXYNOS: use chip_id reg in uncompress to select uart base phys
From: Dima Zavin
Signed-off-by: Dima Zavin
Signed-off-by: Kukjin Kim
---
arch/arm/mach-exynos/include/mach/uncompress.h | 17 -
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/uncompress.h
b/arch/arm/mach-exynos/include/mach/uncompress.h
index 493f4f3..2979995 100644
--- a/arch/arm/mach-exynos/include/mach/uncompress.h
+++ b/arch/arm/mach-exynos/include/mach/uncompress.h
@@ -20,9 +20,24 @@ volatile u8 *uart_base;
#include
+static unsigned int __raw_readl(unsigned int ptr)
+{
+ return *((volatile unsigned int *)ptr);
+}
+
static void arch_detect_cpu(void)
{
- if (machine_is_smdk5250())
+ u32 chip_id = __raw_readl(EXYNOS_PA_CHIPID);
+
+ /*
+* product_id is bits 31:12
+*bits 23:20 describe the exynosX family
+*
+*/
+ chip_id >>= 20;
+ chip_id &= 0xf;
+
+ if (chip_id == 0x5)
uart_base = (volatile u8 *)EXYNOS5_PA_UART + (S3C_UART_OFFSET *
CONFIG_S3C_LOWLEVEL_UART_PORT);
else
uart_base = (volatile u8 *)EXYNOS4_PA_UART + (S3C_UART_OFFSET *
CONFIG_S3C_LOWLEVEL_UART_PORT);
--
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] ARM: EXYNOS: autodetect enabled serial port in uncompress
From: Colin Cross
Check the ULCON register of each serial port to determine if
it has been enabled by the bootloader. If only one serial port
is found enabled, use that one. Otherwise, use the value from
CONFIG_S3C_LOWLEVEL_UART_PORT.
Signed-off-by: Colin Cross
Signed-off-by: Kukjin Kim
---
arch/arm/mach-exynos/include/mach/uncompress.h | 25 ++-
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/uncompress.h
b/arch/arm/mach-exynos/include/mach/uncompress.h
index 2979995..0d17a43 100644
--- a/arch/arm/mach-exynos/include/mach/uncompress.h
+++ b/arch/arm/mach-exynos/include/mach/uncompress.h
@@ -25,6 +25,25 @@ static unsigned int __raw_readl(unsigned int ptr)
return *((volatile unsigned int *)ptr);
}
+static volatile u8 *exynos_autodetect_uart(volatile u8 *base)
+{
+ int i;
+ int found = 0;
+ int port;
+
+ for (i = 0; i < CONFIG_SERIAL_SAMSUNG_UARTS; i++) {
+ if (__raw_readl((unsigned int)base + S3C_UART_OFFSET * i)) {
+ port = i;
+ found++;
+ }
+ }
+
+ if (found != 1)
+ port = CONFIG_S3C_LOWLEVEL_UART_PORT;
+
+ return base + S3C_UART_OFFSET * port;
+}
+
static void arch_detect_cpu(void)
{
u32 chip_id = __raw_readl(EXYNOS_PA_CHIPID);
@@ -38,9 +57,11 @@ static void arch_detect_cpu(void)
chip_id &= 0xf;
if (chip_id == 0x5)
- uart_base = (volatile u8 *)EXYNOS5_PA_UART + (S3C_UART_OFFSET *
CONFIG_S3C_LOWLEVEL_UART_PORT);
+ uart_base = (volatile u8 *)EXYNOS5_PA_UART;
else
- uart_base = (volatile u8 *)EXYNOS4_PA_UART + (S3C_UART_OFFSET *
CONFIG_S3C_LOWLEVEL_UART_PORT);
+ uart_base = (volatile u8 *)EXYNOS4_PA_UART;
+
+ uart_base = exynos_autodetect_uart(uart_base);
/*
* For preventing FIFO overrun or infinite loop of UART console,
--
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] ARM: EXYNOS: convert irq combiner to generic irq chip
From: Colin Cross
The irq combiner is very simple, convert it to a generic irq chip.
Also adds a resume handler to restore the masks after suspend.
Signed-off-by: Colin Cross
Signed-off-by: Kukjin Kim
---
arch/arm/mach-exynos/common.c | 71 +---
1 files changed, 30 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index e6cc50e..ec7680c 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -391,28 +391,6 @@ struct combiner_chip_data {
static struct combiner_chip_data combiner_data[MAX_COMBINER_NR];
-static inline void __iomem *combiner_base(struct irq_data *data)
-{
- struct combiner_chip_data *combiner_data =
- irq_data_get_irq_chip_data(data);
-
- return combiner_data->base;
-}
-
-static void combiner_mask_irq(struct irq_data *data)
-{
- u32 mask = 1 << (data->irq % 32);
-
- __raw_writel(mask, combiner_base(data) + COMBINER_ENABLE_CLEAR);
-}
-
-static void combiner_unmask_irq(struct irq_data *data)
-{
- u32 mask = 1 << (data->irq % 32);
-
- __raw_writel(mask, combiner_base(data) + COMBINER_ENABLE_SET);
-}
-
static void combiner_handle_cascade_irq(unsigned int irq, struct irq_desc
*desc)
{
struct combiner_chip_data *chip_data = irq_get_handler_data(irq);
@@ -442,12 +420,6 @@ static void combiner_handle_cascade_irq(unsigned int irq,
struct irq_desc *desc)
chained_irq_exit(chip, desc);
}
-static struct irq_chip combiner_chip = {
- .name = "COMBINER",
- .irq_mask = combiner_mask_irq,
- .irq_unmask = combiner_unmask_irq,
-};
-
static void __init combiner_cascade_irq(unsigned int combiner_nr, unsigned int
irq)
{
unsigned int max_nr;
@@ -464,11 +436,20 @@ static void __init combiner_cascade_irq(unsigned int
combiner_nr, unsigned int i
irq_set_chained_handler(irq, combiner_handle_cascade_irq);
}
+static void combiner_resume(struct irq_data *data)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+
+ __raw_writel(~gc->mask_cache, gc->reg_base + COMBINER_ENABLE_CLEAR);
+ __raw_writel(gc->mask_cache, gc->reg_base + COMBINER_ENABLE_SET);
+}
+
static void __init combiner_init(unsigned int combiner_nr, void __iomem *base,
unsigned int irq_start)
{
- unsigned int i;
unsigned int max_nr;
+ struct irq_chip_generic *gc;
+ struct irq_chip_type *ct;
if (soc_is_exynos5250())
max_nr = EXYNOS5_MAX_COMBINER_NR;
@@ -482,18 +463,26 @@ static void __init combiner_init(unsigned int
combiner_nr, void __iomem *base,
combiner_data[combiner_nr].irq_offset = irq_start;
combiner_data[combiner_nr].irq_mask = 0xff << ((combiner_nr % 4) << 3);
- /* Disable all interrupts */
+ if ((combiner_nr % 4) == 0) {
+ /* Disable all interrupts */
- __raw_writel(combiner_data[combiner_nr].irq_mask,
-base + COMBINER_ENABLE_CLEAR);
+ __raw_writel(IRQ_MSK(32), base + COMBINER_ENABLE_CLEAR);
- /* Setup the Linux IRQ subsystem */
+ gc = irq_alloc_generic_chip("combiner", 1, irq_start,
+ base, handle_level_irq);
+ if (!gc) {
+ pr_err("Failed to allocate combiner irq chip\n");
+ return;
+ }
- for (i = irq_start; i < combiner_data[combiner_nr].irq_offset
- + MAX_IRQ_IN_COMBINER; i++) {
- irq_set_chip_and_handler(i, &combiner_chip, handle_level_irq);
- irq_set_chip_data(i, &combiner_data[combiner_nr]);
- set_irq_flags(i, IRQF_VALID | IRQF_PROBE);
+ ct = gc->chip_types;
+ ct->chip.irq_mask = irq_gc_mask_disable_reg;
+ ct->chip.irq_unmask = irq_gc_unmask_enable_reg;
+ ct->chip.irq_resume = combiner_resume;
+ ct->regs.enable = COMBINER_ENABLE_SET;
+ ct->regs.disable = COMBINER_ENABLE_CLEAR;
+ irq_setup_generic_chip(gc, IRQ_MSK(32), 0,
+ IRQ_NOREQUEST | IRQ_NOPROBE, 0);
}
}
--
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] ARM: EXYNOS: fix CONFIG_DEBUG_LL
From: Colin Cross addruart cannot read from the physical address of the chipid register, that will fail as soon as the mmu is turned on. Fixing it to read from the physical or virtual address depending on the mmu state also does not work, because there is a period between head.S and exynos_map_io where the mmu is on, the uart is mapped and used, but the chipid mapping is not yet present. Fix addruart to use the ARM Main ID cp15 register to determine if the core is Cortex A15 (EXYNOS5) or not (EXYNOS4). Signed-off-by: Colin Cross Signed-off-by: Kukjin Kim --- arch/arm/mach-exynos/include/mach/debug-macro.S |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-exynos/include/mach/debug-macro.S b/arch/arm/mach-exynos/include/mach/debug-macro.S index 6c857ff..e0c86ea 100644 --- a/arch/arm/mach-exynos/include/mach/debug-macro.S +++ b/arch/arm/mach-exynos/include/mach/debug-macro.S @@ -21,10 +21,9 @@ */ .macro addruart, rp, rv, tmp - mov \rp, #0x1000 - ldr \rp, [\rp, #0x0] - and \rp, \rp, #0xf0 - teq \rp, #0x50 @@ EXYNOS5 + mrc p15, 0, \tmp, c0, c0, 0 + and \tmp, \tmp, #0xf0 + teq \tmp, #0xf0 @@ A15 ldreq \rp, =EXYNOS5_PA_UART movne \rp, #EXYNOS4_PA_UART @@ EXYNOS4 ldr \rv, =S3C_VA_UART -- 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 v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support
Chris Ball wrote: Hi Kukjin, Hi, Sorry for late response. [...] I can't send the tree as it is to Linus now, because Arnd has asked us to hold off on these device tree bindings and work with the unified bindings he's proposing instead. (Rebasing to drop that patch will introduce new conflicts.) OK, I see. I'm going to send Mark Brown's two patches to Linus now, even though it will cause a conflict in -next. The rest (other than the device tree bindings) are mergable after -rc1, because they're fixes, so we'll eventually get everything except DT in to 3.4. I think you should just drop this patchset from your tree in linux-next entirely now. Yep, I dropped it in my -next. 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: S3C64XX: Hook up new style regulator-regulator supplies on Cragganmore
Mark Brown wrote:
> The regulator API now allows supplies used by regulators to be specified
> as normal supplies - provide the hookup for that mechanism on Cragganmore.
>
> Signed-off-by: Mark Brown
> ---
> arch/arm/mach-s3c64xx/mach-crag6410.c | 18 ++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
> b/arch/arm/mach-s3c64xx/mach-crag6410.c
> index 02fd009..4ee0249 100644
> --- a/arch/arm/mach-s3c64xx/mach-crag6410.c
> +++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
> @@ -306,6 +306,24 @@ static struct regulator_consumer_supply
> wallvdd_consumers[] = {
> REGULATOR_SUPPLY("SPKVDD2", "1-001a"),
> REGULATOR_SUPPLY("SPKVDDL", "1-001a"),
> REGULATOR_SUPPLY("SPKVDDR", "1-001a"),
> +
> + REGULATOR_SUPPLY("DC1VDD", "0-0034"),
> + REGULATOR_SUPPLY("DC2VDD", "0-0034"),
> + REGULATOR_SUPPLY("DC3VDD", "0-0034"),
> + REGULATOR_SUPPLY("LDO1VDD", "0-0034"),
> + REGULATOR_SUPPLY("LDO2VDD", "0-0034"),
> + REGULATOR_SUPPLY("LDO4VDD", "0-0034"),
> + REGULATOR_SUPPLY("LDO5VDD", "0-0034"),
> + REGULATOR_SUPPLY("LDO6VDD", "0-0034"),
> + REGULATOR_SUPPLY("LDO7VDD", "0-0034"),
> + REGULATOR_SUPPLY("LDO8VDD", "0-0034"),
> + REGULATOR_SUPPLY("LDO9VDD", "0-0034"),
> + REGULATOR_SUPPLY("LDO10VDD", "0-0034"),
> + REGULATOR_SUPPLY("LDO11VDD", "0-0034"),
> +
> + REGULATOR_SUPPLY("DC1VDD", "1-0034"),
> + REGULATOR_SUPPLY("DC2VDD", "1-0034"),
> + REGULATOR_SUPPLY("DC3VDD", "1-0034"),
> };
>
> static struct regulator_init_data wallvdd_data = {
Looks ok to me, will apply.
Mark, is this needed for v3.4?
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] mach-exynos: fix ISO C90 warning.
Il Han wrote:
> ISO C90 forbids mixed declarations and code.
> Fix it.
>
> Signed-off-by: Il Han
> ---
> arch/arm/mach-exynos/common.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
> index e6cc50e..8614aab 100644
> --- a/arch/arm/mach-exynos/common.c
> +++ b/arch/arm/mach-exynos/common.c
> @@ -583,10 +583,11 @@ core_initcall(exynos_core_init);
> #ifdef CONFIG_CACHE_L2X0
> static int __init exynos4_l2x0_cache_init(void)
> {
> + int ret;
> +
> if (soc_is_exynos5250())
> return 0;
>
> - int ret;
> ret = l2x0_of_init(L2_AUX_VAL, L2_AUX_MASK);
> if (!ret) {
> l2x0_regs_phys = virt_to_phys(&l2x0_saved_regs);
Yeah, seems happened wehn merge confilcts resolved.
OK, will apply and if possible, please use following subject form in
next time like others. Every ARM platfomrs use that.
'ARM: EXYNOS: ...'
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
[PATCH] mach-exynos: fix ISO C90 warning.
ISO C90 forbids mixed declarations and code.
Fix it.
Signed-off-by: Il Han
---
arch/arm/mach-exynos/common.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index e6cc50e..8614aab 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -583,10 +583,11 @@ core_initcall(exynos_core_init);
#ifdef CONFIG_CACHE_L2X0
static int __init exynos4_l2x0_cache_init(void)
{
+ int ret;
+
if (soc_is_exynos5250())
return 0;
- int ret;
ret = l2x0_of_init(L2_AUX_VAL, L2_AUX_MASK);
if (!ret) {
l2x0_regs_phys = virt_to_phys(&l2x0_saved_regs);
--
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] ARM: S3C64XX: Hook up new style regulator-regulator supplies on Cragganmore
The regulator API now allows supplies used by regulators to be specified
as normal supplies - provide the hookup for that mechanism on Cragganmore.
Signed-off-by: Mark Brown
---
arch/arm/mach-s3c64xx/mach-crag6410.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 02fd009..4ee0249 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -306,6 +306,24 @@ static struct regulator_consumer_supply
wallvdd_consumers[] = {
REGULATOR_SUPPLY("SPKVDD2", "1-001a"),
REGULATOR_SUPPLY("SPKVDDL", "1-001a"),
REGULATOR_SUPPLY("SPKVDDR", "1-001a"),
+
+ REGULATOR_SUPPLY("DC1VDD", "0-0034"),
+ REGULATOR_SUPPLY("DC2VDD", "0-0034"),
+ REGULATOR_SUPPLY("DC3VDD", "0-0034"),
+ REGULATOR_SUPPLY("LDO1VDD", "0-0034"),
+ REGULATOR_SUPPLY("LDO2VDD", "0-0034"),
+ REGULATOR_SUPPLY("LDO4VDD", "0-0034"),
+ REGULATOR_SUPPLY("LDO5VDD", "0-0034"),
+ REGULATOR_SUPPLY("LDO6VDD", "0-0034"),
+ REGULATOR_SUPPLY("LDO7VDD", "0-0034"),
+ REGULATOR_SUPPLY("LDO8VDD", "0-0034"),
+ REGULATOR_SUPPLY("LDO9VDD", "0-0034"),
+ REGULATOR_SUPPLY("LDO10VDD", "0-0034"),
+ REGULATOR_SUPPLY("LDO11VDD", "0-0034"),
+
+ REGULATOR_SUPPLY("DC1VDD", "1-0034"),
+ REGULATOR_SUPPLY("DC2VDD", "1-0034"),
+ REGULATOR_SUPPLY("DC3VDD", "1-0034"),
};
static struct regulator_init_data wallvdd_data = {
--
1.7.9.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] mmc: core: Add host capability check for power class
> -Original Message-
> From: Saugata Das [mailto:saugata@linaro.org]
> Sent: Monday, April 02, 2012 1:20 PM
> To: Subhash Jadavani
> Cc: Girish K S; linux-...@vger.kernel.org; patc...@linaro.org; linux-
> samsung-...@vger.kernel.org; Chris Ball
> Subject: Re: [PATCH V2] mmc: core: Add host capability check for power
class
>
> On 28 March 2012 16:39, Subhash Jadavani
> wrote:
> >
> >
> >> -Original Message-
> >> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> >> ow...@vger.kernel.org] On Behalf Of Saugata Das
> >> Sent: Thursday, December 15, 2011 6:35 PM
> >> To: Girish K S
> >> Cc: linux-...@vger.kernel.org; patc...@linaro.org; linux-samsung-
> >> s...@vger.kernel.org; subha...@codeaurora.org; Chris Ball
> >> Subject: Re: [PATCH V2] mmc: core: Add host capability check for
> >> power
> > class
> >>
> >> On 15 December 2011 16:22, Girish K S
> >>
> >> wrote:
> >> > On 15 December 2011 15:34, Saugata Das
> wrote:
> >> >> On 15 December 2011 09:28, Girish K S
> >> >>
> >> wrote:
> >> >>> This patch adds a check whether the host supports maximum current
> >> >>> value obtained from the device's extended csd register for a
> >> >>> selected interface voltage and frequency.
> >> >>>
> >> >>> cc: Chris Ball
> >> >>> Signed-off-by: Girish K S
> >> >>> ---
> >> >>> Changes in v2:
> >> >>> deleted a unnecessary if else condition identified by
> >> >>> subhash J Changes in v1:
> >> >>> reduced the number of comparisons as per Hein's suggestion
> >> >>>
> >> >>> drivers/mmc/core/mmc.c | 19 +++
> >> >>> include/linux/mmc/card.h | 4
> >> >>> 2 files changed, 23 insertions(+), 0 deletions(-)
> >> >>>
> >> >>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> >> >>> index
> >> >>> 006e932..b9ef777 100644
> >> >>> --- a/drivers/mmc/core/mmc.c
> >> >>> +++ b/drivers/mmc/core/mmc.c
> >> >>> @@ -688,6 +688,25 @@ static int mmc_select_powerclass(struct
> >> >>> mmc_card *card,
> >> >>> pwrclass_val = (pwrclass_val &
> >> >>> EXT_CSD_PWR_CL_4BIT_MASK) >>
> >> >>> EXT_CSD_PWR_CL_4BIT_SHIFT;
> >> >>>
> >> >>> + if (pwrclass_val >= MMC_MAX_CURRENT_800)
> >> >>> + pwrclass_val = MMC_MAX_CURRENT_800;
> >> >>> + else if (pwrclass_val >= MMC_MAX_CURRENT_600)
> >> >>> + pwrclass_val = MMC_MAX_CURRENT_600;
> >> >>> + else if (pwrclass_val >= MMC_MAX_CURRENT_400)
> >> >>> + pwrclass_val = MMC_MAX_CURRENT_400;
> >> >>> + else
> >> >>> + pwrclass_val = MMC_MAX_CURRENT_200;
> >> >>> +
> >> >>> + if ((pwrclass_val == MMC_MAX_CURRENT_800) &&
> >> >>> + !(card->host->caps & MMC_CAP_MAX_CURRENT_800))
> >> >>> + pwrclass_val = MMC_MAX_CURRENT_600;
> >> >>> + if ((pwrclass_val == MMC_MAX_CURRENT_600) &&
> >> >>> + !(card->host->caps & MMC_CAP_MAX_CURRENT_600))
> >> >>> + pwrclass_val = MMC_MAX_CURRENT_400;
> >> >>> + if ((pwrclass_val == MMC_MAX_CURRENT_400) &&
> >> >>> + !(card->host->caps & MMC_CAP_MAX_CURRENT_400))
> >> >>> + pwrclass_val = MMC_MAX_CURRENT_200;
> >> >>> +
> >> >>> /* If the power class is different from the default value
> >> >>> */
> >> >>> if (pwrclass_val > 0) {
> >> >>> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> >> >>
> >> >> It is not allowed to set the POWER_CLASS with any value other than
> >> >> what is mentioned in the PWR_CL_ff_vvv or PWR_CL_DDR_ff_vvv for
> >> the
> >> >> corresponding frequency, voltage. That is, if PWR_CL_200_195 is 14
> >> >> and we want to operate at HS200 then the only value allowed for
> >> >> POWER_CLASS is 14. So, we need to check the PWR_CL numbers and
> >> choose
> >> >> the operating mode (HS200/DDR50/..) based on the platform
> >> >> capability to support the current consumption and set the
> >> >> corresponding POWER_CLASS value.
> >> >>
> >> >> Please refer to section 6.6.5 of the 4.5 spec.
> >> >
> >> > The upstreamed code reads the extended csd value based on the
> >> > already set voltage level and frequency of host. So it will get the
> >> > required power class value which can be set directly. Is my
> >> > understanding correct?
> >> >
> >>
> >> It is not enough to just check the voltage level and frequency.
> >> Consider this example, host has capability to support
> >> MMC_CAP_MAX_CURRENT_400, the PWR_CL_DDR_52_360 has the value
> 9
> >> (400mA) and PWR_CL_200_360 has the value 14 (800mA). Then even
> though
> >> the host might be capable to run 200MHz clock and 3.6V, it can only
> >> enable DDR at 52MHz and set 9 in POWER_CLASS.
> >>
> >> I think, in mmc_select_powerclass, we need to loop through the power
> >> classes of all supported modes of transfer (HS200, DDR52, ... ) and
> >> choose
> > the
> >> mode which gives maximum bandwidth but falls within host capability
> >> of current consumption. Then set this to POWER_CLASS byte and
Re: [PATCH V2] mmc: core: Add host capability check for power class
On 28 March 2012 16:39, Subhash Jadavani wrote:
>
>
>> -Original Message-
>> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
>> ow...@vger.kernel.org] On Behalf Of Saugata Das
>> Sent: Thursday, December 15, 2011 6:35 PM
>> To: Girish K S
>> Cc: linux-...@vger.kernel.org; patc...@linaro.org; linux-samsung-
>> s...@vger.kernel.org; subha...@codeaurora.org; Chris Ball
>> Subject: Re: [PATCH V2] mmc: core: Add host capability check for power
> class
>>
>> On 15 December 2011 16:22, Girish K S
>> wrote:
>> > On 15 December 2011 15:34, Saugata Das wrote:
>> >> On 15 December 2011 09:28, Girish K S
>> wrote:
>> >>> This patch adds a check whether the host supports maximum current
>> >>> value obtained from the device's extended csd register for a
>> >>> selected interface voltage and frequency.
>> >>>
>> >>> cc: Chris Ball
>> >>> Signed-off-by: Girish K S
>> >>> ---
>> >>> Changes in v2:
>> >>> deleted a unnecessary if else condition identified by subhash
>> >>> J Changes in v1:
>> >>> reduced the number of comparisons as per Hein's suggestion
>> >>>
>> >>> drivers/mmc/core/mmc.c | 19 +++
>> >>> include/linux/mmc/card.h | 4
>> >>> 2 files changed, 23 insertions(+), 0 deletions(-)
>> >>>
>> >>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index
>> >>> 006e932..b9ef777 100644
>> >>> --- a/drivers/mmc/core/mmc.c
>> >>> +++ b/drivers/mmc/core/mmc.c
>> >>> @@ -688,6 +688,25 @@ static int mmc_select_powerclass(struct
>> >>> mmc_card *card,
>> >>> pwrclass_val = (pwrclass_val &
>> >>> EXT_CSD_PWR_CL_4BIT_MASK) >>
>> >>> EXT_CSD_PWR_CL_4BIT_SHIFT;
>> >>>
>> >>> + if (pwrclass_val >= MMC_MAX_CURRENT_800)
>> >>> + pwrclass_val = MMC_MAX_CURRENT_800;
>> >>> + else if (pwrclass_val >= MMC_MAX_CURRENT_600)
>> >>> + pwrclass_val = MMC_MAX_CURRENT_600;
>> >>> + else if (pwrclass_val >= MMC_MAX_CURRENT_400)
>> >>> + pwrclass_val = MMC_MAX_CURRENT_400;
>> >>> + else
>> >>> + pwrclass_val = MMC_MAX_CURRENT_200;
>> >>> +
>> >>> + if ((pwrclass_val == MMC_MAX_CURRENT_800) &&
>> >>> + !(card->host->caps & MMC_CAP_MAX_CURRENT_800))
>> >>> + pwrclass_val = MMC_MAX_CURRENT_600;
>> >>> + if ((pwrclass_val == MMC_MAX_CURRENT_600) &&
>> >>> + !(card->host->caps & MMC_CAP_MAX_CURRENT_600))
>> >>> + pwrclass_val = MMC_MAX_CURRENT_400;
>> >>> + if ((pwrclass_val == MMC_MAX_CURRENT_400) &&
>> >>> + !(card->host->caps & MMC_CAP_MAX_CURRENT_400))
>> >>> + pwrclass_val = MMC_MAX_CURRENT_200;
>> >>> +
>> >>> /* If the power class is different from the default value */
>> >>> if (pwrclass_val > 0) {
>> >>> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>> >>
>> >> It is not allowed to set the POWER_CLASS with any value other than
>> >> what is mentioned in the PWR_CL_ff_vvv or PWR_CL_DDR_ff_vvv for
>> the
>> >> corresponding frequency, voltage. That is, if PWR_CL_200_195 is 14
>> >> and we want to operate at HS200 then the only value allowed for
>> >> POWER_CLASS is 14. So, we need to check the PWR_CL numbers and
>> choose
>> >> the operating mode (HS200/DDR50/..) based on the platform capability
>> >> to support the current consumption and set the corresponding
>> >> POWER_CLASS value.
>> >>
>> >> Please refer to section 6.6.5 of the 4.5 spec.
>> >
>> > The upstreamed code reads the extended csd value based on the already
>> > set voltage level and frequency of host. So it will get the required
>> > power class value which can be set directly. Is my understanding
>> > correct?
>> >
>>
>> It is not enough to just check the voltage level and frequency.
>> Consider this example, host has capability to support
>> MMC_CAP_MAX_CURRENT_400, the PWR_CL_DDR_52_360 has the value 9
>> (400mA) and PWR_CL_200_360 has the value 14 (800mA). Then even though
>> the host might be capable to run 200MHz clock and 3.6V, it can only enable
>> DDR at 52MHz and set 9 in POWER_CLASS.
>>
>> I think, in mmc_select_powerclass, we need to loop through the power
>> classes of all supported modes of transfer (HS200, DDR52, ... ) and choose
> the
>> mode which gives maximum bandwidth but falls within host capability of
>> current consumption. Then set this to POWER_CLASS byte and also use the
>> same information when setting HS_TIMING in mmc_init_card.
>
> Hi Saugata,
>
> Does the spec mandates you to set the power class to what is needed by
> frequency/voltage combination? I can't see that mentioned anywhere
> explicitly in eMMC4.5 spec (if it is mentioned in spec, please let me know
> section and line number). It may be still possible to set the power class
> lower than what is needed by frequency/voltage combination. Say for example,
> 8-bit HS200 (200MHz) with high voltage cards may specify power class
> (PWR_CL_200_3_6) value of 14 (800 mA) but that
