Re: [PATCH V2] mmc: core: Add host capability check for power class
On 28 March 2012 16:39, Subhash Jadavani subha...@codeaurora.org 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 girish.shivananja...@linaro.org
wrote:
On 15 December 2011 15:34, Saugata Das saugata@linaro.org wrote:
On 15 December 2011 09:28, Girish K S girish.shivananja...@linaro.org
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 c...@laptop.org
Signed-off-by: Girish K S girish.shivananja...@linaro.org
---
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 doesn't mean if you want the
card to work in 8-bit HS200 mode, its POWER_CLASS value must be 14 (800mA).
If host's VDD regulator is only capable of say 600mA then it may still set
the POWER_CLASS to 12 (600 mA) which should be the indication
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 subha...@codeaurora.org
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
girish.shivananja...@linaro.org
wrote:
On 15 December 2011 15:34, Saugata Das saugata@linaro.org
wrote:
On 15 December 2011 09:28, Girish K S
girish.shivananja...@linaro.org
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 c...@laptop.org
Signed-off-by: Girish K S girish.shivananja...@linaro.org
---
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
[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 broo...@opensource.wolfsonmicro.com
---
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
[PATCH] mach-exynos: fix ISO C90 warning.
ISO C90 forbids mixed declarations and code.
Fix it.
Signed-off-by: Il Han corone.il@gmail.com
---
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
Re: [PATCH] mach-exynos: fix ISO C90 warning.
Il Han wrote:
ISO C90 forbids mixed declarations and code.
Fix it.
Signed-off-by: Il Hancorone.il@gmail.com
---
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 kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: 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 Brownbroo...@opensource.wolfsonmicro.com
---
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 kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 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 kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: EXYNOS: convert irq combiner to generic irq chip
From: Colin Cross ccr...@android.com
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 ccr...@android.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
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: use chip_id reg in uncompress to select uart base phys
From: Dima Zavin d...@android.com
Signed-off-by: Dima Zavin d...@android.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
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 plat/uncompress.h
+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
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
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 he...@sntech.de
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 linux/ioport.h
#include linux/device.h
#include linux/io.h
+#include linux/syscore_ops.h
#include mach/hardware.h
#include asm/irq.h
@@ -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,
struct subsys_interface *sif)
{
@@ -232,6 +306,8 @@ static
Re: [PATCH] ARM: EXYNOS: autodetect enabled serial port in uncompress
Hi,
On Tue, Apr 3, 2012 at 4:17 AM, Kukjin Kim kgene@samsung.com wrote:
From: Colin Cross ccr...@android.com
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 ccr...@android.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
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 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 Stuebnerhe...@sntech.de
---
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 kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: 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
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 Stuebnerhe...@sntech.de
---
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
