Re: [PATCH V3 2/6] ARM: s5p: remove useless churn in sleep.S
On Tue, Nov 22, 2011 at 3:18 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Nov 22, 2011 at 03:05:28PM +0530, Amit Daniel Kachhap wrote: This patch cleans up sleep code in preparation for L2 resume code and hotplug functions I wonder whether anyone read the comments in this file before they changed the section for the code. /* * sleep magic, to allow the bootloader to check for an valid * image to resume to. Must be the first word before the * s3c_cpu_resume entry. */ Ok,This looks like an error. Thanks for pointing this out. Will put the entire section into data. -- 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: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On 16:28 Tue 22 Nov , Stephen Warren wrote:
Tony Lindgren wrote at Tuesday, November 22, 2011 10:54 AM:
* Linus Walleij linus.wall...@linaro.org [22 03:30]:
On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
On 17 November 2011 19:27, Linus Walleij linus.wall...@linaro.org
wrote:
Maybe I'm mistaken about the device tree ambitions, but
I was sort of hoping that it would not contain too much
custom magic numbers that need to be cross-referenced
elsewhere ... or rather - the more understandable the device
tree is, the more we win.
Device tree is expected to describe the hardware. So to
cross-reference the hardware manual to understand device tree should
be fine I guess. For instance, GPIO numbers in dts would be written as
a numeric number and not a enum or other format. And by looking up the
manual, we understand the actual details of the GPIO pin.
If dt-compiler had a option to support #define like in C, the numbers
could have been made more easier to understand. Like, 3 to mean
GPIO_PULL_UP in Exynos dts file.
OK I think I get it now, so DT bindings shall really NOT be read
by any of the pinctrl core, it is *supposed* to be all driver-specific.
Then it makes perfect sense to have it as it is.
Yes the driver nodes should describe in DT which pins to use:
serial@1234 {
compatible = 8250;
reg = 0x1234 0x40;
reg-shift = 2;
interrupts = 10 ;
pins = uart1_rx, uart1_tx;
};
Sorry to jump in late here, but I wasn't aware of this thread.
I don't necessarily agree with that. Describing the HW doesn't necessarily
mean that each device needs to describe what pinmux pins it uses; one
could quite easily have the pinmux describe what settings the various
pins should have and which drivers will use those pins. That would map
very well to the pinctrl subsystem's mapping table, and at least Tegra's
existing pinmux tables, which are both just a big array of settings which
end up getting provided to drivers.
I'll try and track down the rest of this thread and catch up though...
I agreee here
as example on at91 I try to found a good way to let the macb driver to ask the
pin configuration
so in my mind i do not need put all pins in each board but in the dtsi and
then in the drivers just said
pins = mii;
or
pins = rmii;
or if I want to use the alternative config
pins = mii_alt;
or
pins = rmii_alt;
and then in the dtsi I describe the pin used for those configs
which is soc specifific not board
Best Regards,
J.
--
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 v7 0/2] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos
On Fri, Nov 18, 2011 at 06:47:28PM +0900, KyongHo Cho wrote: Changes since v6: - Totally rewrite exynos_iommu_map() and exynos_iommu_unmap() according to the change in iommu_map() and iommu_unmap(). - Change special slab for Lv2 page table to kmalloc(). Okay, the driver looks good to me now. If there are no further objections I am going to merge it for 3.3. Joerg -- 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: [GIT PULL] Samsung fixes for v3.2
On Monday 21 November 2011, Kukjin Kim wrote: Please pull samsung-fixes for v3.2 from: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git samsung-fixes This includes fix of inclusion header. If any problems, please let me know. Pulled, thanks! On Monday 21 November 2011, Kyungmin Park wrote: Don't you fix the mct compiler error if LOCAL_TIMERS are not defined? arch/arm/mach-exynos/mct.c: In function 'exynos4_timer_resources': arch/arm/mach-exynos/mct.c:451: error: 'exynos4_mct_tick_isr' undeclared (first use in this function) arch/arm/mach-exynos/mct.c:451: error: (Each undeclared identifier is reported only once arch/arm/mach-exynos/mct.c:451: error: for each function it appears in.) make[1]: *** [arch/arm/mach-exynos/mct.o] Error 1 Has a patch been posted for this? Arnd -- 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: [GIT PULL] Samsung fixes for v3.2
On Thu, Nov 24, 2011 at 6:15 AM, Arnd Bergmann a...@arndb.de wrote:
On Monday 21 November 2011, Kukjin Kim wrote:
Please pull samsung-fixes for v3.2 from:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
samsung-fixes
This includes fix of inclusion header.
If any problems, please let me know.
Pulled, thanks!
On Monday 21 November 2011, Kyungmin Park wrote:
Don't you fix the mct compiler error if LOCAL_TIMERS are not defined?
arch/arm/mach-exynos/mct.c: In function 'exynos4_timer_resources':
arch/arm/mach-exynos/mct.c:451: error: 'exynos4_mct_tick_isr'
undeclared (first use in this function)
arch/arm/mach-exynos/mct.c:451: error: (Each undeclared identifier is
reported only once
arch/arm/mach-exynos/mct.c:451: error: for each function it appears in.)
make[1]: *** [arch/arm/mach-exynos/mct.o] Error 1
Has a patch been posted for this?
Arnd
There was a discussion about this and a patch seemed to be ready
although I don't know where:
---[quoting: Re: [PATCH 1/2] ARM: EXYNOS4: convert MCT to percpu
interrupt API from linux-arm-ker...@lists.infradead.org]---
On 10/11/11 23:33, MyungJoo Ham wrote:
On Thu, Nov 10, 2011 at 6:43 PM, Marc Zyngier marc.zyng...@arm.com wrote:
On 10/11/11 02:40, MyungJoo Ham wrote:
On Thu, Nov 3, 2011 at 2:30 AM, Marc Zyngier marc.zyng...@arm.com wrote:
MCT recently gained per cpu interrupts, and missed the fact that
ARM has moved to a genirq based implementation.
This patch converts the driver to the new API.
Boot tested on Origen.
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
There is one concern regarding the CONFIG_LOCAL_TIMER.
[]
#endif /* CONFIG_LOCAL_TIMERS */
static void __init exynos4_timer_resources(void)
@@ -438,6 +442,16 @@ static void __init exynos4_timer_resources(void)
mct_clk = clk_get(NULL, xtal);
clk_rate = clk_get_rate(mct_clk);
+
+ if (mct_int_type == MCT_INT_PPI) {
+ int err;
+
+ err = request_percpu_irq(IRQ_MCT_LOCALTIMER,
+exynos4_mct_tick_isr, MCT,
+percpu_mct_tick);
+ WARN(err, MCT: can't request IRQ %d (%d)\n,
+IRQ_MCT_LOCALTIMER, err);
+ }
}
You've added exynos4_mct_tick_isr, which is defined in
CONFIG_LOCAL_TIMER section, in the place that is compiled without
CONFIG_LOCAL_TIMER.
I guess we are going to stop supporting LOCAL_TIMER in Exynos later
and this could be a problem with it.
Yup, this is a problem. It probably means we need to #ifdef that chink
as well. I'm not sure I get your remark about not supporting LOCAL_TIMER
though. Are you planning to move away from the LOCAL_TIMER infrastructure?
Yes, we may need to #ifdef that block.
And yes, for the Exynos series, I'll need to double check; however, I
think we are planning to move away from the LOCAL_TIMER for MCT.
I have patches for this already.
- Hide quoted text -
M.
--
Jazz is not dead. It just smells funny...
--
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
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 1/6] ARM: exynos: Add AFTR mode cpuidle state on EXYNOS4210
Hi Amit,
On 22 November 2011 15:05, Amit Daniel Kachhap amit.kach...@linaro.org wrote:
This patch adds support AFTR(ARM OFF TOP RUNNING) mode in
cpuidle driver. L2 cache keeps their data in this mode.
This patch ports the code to the latest interfaces to
save/restore CPU state inclusive of CPU PM notifiers, l2
resume and cpu_suspend/resume.
Signed-off-by: Jaecheol Lee jc@samsung.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
arch/arm/mach-exynos/cpuidle.c | 152
++-
arch/arm/mach-exynos/include/mach/pmu.h | 2 +
2 files changed, 151 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index 21403c8..89afa93 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -12,15 +12,37 @@
#include linux/module.h
#include linux/init.h
#include linux/cpuidle.h
+#include linux/cpu_pm.h
#include linux/io.h
#include linux/export.h
#include linux/time.h
#include asm/proc-fns.h
+#include asm/smp_scu.h
+#include asm/suspend.h
+#include asm/unified.h
+#include mach/regs-pmu.h
+#include mach/pmu.h
+
+#include plat/exynos4.h
+#include plat/cpu.h
+
+#define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \
+ S5P_INFORM7 : (samsung_rev() == EXYNOS4210_REV_1_0 ? \
+ (S5P_VA_SYSRAM + 0x24) : S5P_INFORM0))
+#define REG_DIRECTGO_FLAG (samsung_rev() == EXYNOS4210_REV_1_1 ? \
+ S5P_INFORM6 : (samsung_rev() == EXYNOS4210_REV_1_0 ? \
+ (S5P_VA_SYSRAM + 0x20) : S5P_INFORM1))
+
+#define S5P_CHECK_AFTR (samsung_rev() == EXYNOS4210_REV_1_0 ? \
+ 0xBAD0 : 0xFCBA0D10)
static int exynos4_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index);
+static int exynos4_enter_lowpower(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index);
static struct cpuidle_state exynos4_cpuidle_set[] = {
[0] = {
@@ -28,9 +50,17 @@ static struct cpuidle_state exynos4_cpuidle_set[] = {
.exit_latency = 1,
.target_residency = 10,
.flags = CPUIDLE_FLAG_TIME_VALID,
- .name = IDLE,
+ .name = C0,
.desc = ARM clock gating(WFI),
},
+ [1] = {
+ .enter = exynos4_enter_lowpower,
+ .exit_latency = 300,
+ .target_residency = 10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = C1,
+ .desc = ARM power down,
+ },
};
static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
@@ -40,9 +70,101 @@ static struct cpuidle_driver exynos4_idle_driver = {
.owner = THIS_MODULE,
};
+/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
+static void exynos4_set_wakeupmask(void)
+{
+ __raw_writel(0xff3e, S5P_WAKEUP_MASK);
+}
+
+static unsigned int g_pwr_ctrl, g_diag_reg;
+
+static void save_cpu_arch_register(void)
+{
+ /*read power control register*/
+ asm(mrc p15, 0, %0, c15, c0, 0 : =r(g_pwr_ctrl) : : cc);
+ /*read diagnostic register*/
+ asm(mrc p15, 0, %0, c15, c0, 1 : =r(g_diag_reg) : : cc);
+ return;
+}
+
+static void restore_cpu_arch_register(void)
+{
+ /*write power control register*/
+ asm(mcr p15, 0, %0, c15, c0, 0 : : r(g_pwr_ctrl) : cc);
+ /*write diagnostic register*/
+ asm(mcr p15, 0, %0, c15, c0, 1 : : r(g_diag_reg) : cc);
+ return;
+}
+
+static int idle_finisher(unsigned long flags)
+{
+ cpu_do_idle();
+ return 1;
+}
+
+static int exynos4_enter_core0_aftr(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ struct timeval before, after;
+ int idle_time;
+ unsigned long tmp;
+
+ local_irq_disable();
+ do_gettimeofday(before);
+
+ exynos4_set_wakeupmask();
+
+ /* Set value of power down register for aftr mode */
+ exynos4_sys_powerdown_conf(SYS_AFTR);
+
+ __raw_writel(BSYM(virt_to_phys(s3c_cpu_resume)),
+ REG_DIRECTGO_ADDR);
+ __raw_writel(S5P_CHECK_AFTR, REG_DIRECTGO_FLAG);
+
+ save_cpu_arch_register();
+
+ /* Setting Central Sequence Register for power down mode */
+ tmp = __raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
+ tmp =
RE: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Koen Kooi
Sent: Wednesday, November 23, 2011 8:51 PM
To: Tony Lindgren
Cc: Linus Walleij; Thomas Abraham; Nayak, Rajendra; linux-
o...@vger.kernel.org; linaro-...@lists.linaro.org;
linus.wall...@stericsson.com; linux-samsung-soc; devicetree-
disc...@lists.ozlabs.org
Subject: Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
Op 22 nov. 2011, om 18:54 heeft Tony Lindgren het volgende geschreven:
* Linus Walleij linus.wall...@linaro.org [22 03:30]:
On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
On 17 November 2011 19:27, Linus Walleij linus.wall...@linaro.org
wrote:
Maybe I'm mistaken about the device tree ambitions, but
I was sort of hoping that it would not contain too much
custom magic numbers that need to be cross-referenced
elsewhere ... or rather - the more understandable the device
tree is, the more we win.
Device tree is expected to describe the hardware. So to
cross-reference the hardware manual to understand device tree should
be fine I guess. For instance, GPIO numbers in dts would be written as
a numeric number and not a enum or other format. And by looking up the
manual, we understand the actual details of the GPIO pin.
If dt-compiler had a option to support #define like in C, the numbers
could have been made more easier to understand. Like, 3 to mean
GPIO_PULL_UP in Exynos dts file.
OK I think I get it now, so DT bindings shall really NOT be read
by any of the pinctrl core, it is *supposed* to be all driver-specific.
Then it makes perfect sense to have it as it is.
Yes the driver nodes should describe in DT which pins to use:
serial@1234 {
compatible = 8250;
reg = 0x1234 0x40;
reg-shift = 2;
interrupts = 10 ;
pins = uart1_rx, uart1_tx;
};
Note that we should use the actual signal names, not package specific
pad names. This way they have a high likelyhood to work for new packages
too by just mapping the signals to the new package.
How would this handle the situation where you can mux a signal to multiple
pins? IIRC omap3 and am335x can do funny stuff with the display pins like
being able to map the blue bits to different pinblocks.
That's quite not true, in case of omap3 pins are labeled as R0-R7, B0-B7 and
G0-G7; what changes is pixel format.
AM335x LCDC is completely different IP altogether and spec doesn't map
Colors to pins. It barely maps bit0 from memory to pinX.
Now you call it as a standard or legacy or may be due to SGX software,
the pixel format we use is BGR (as in memory).
It is completely depends on how you interface the pins to LCD (considering)
Software support/requirement.
Thanks,
Vaibhav
regards,
Koen
--
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 RESEND V4] mmc: core: HS200 mode support for eMMC 4.5
Hi Girish,
-Original Message-
From: Girish K S [mailto:girish.shivananja...@linaro.org]
Sent: Monday, November 21, 2011 4:12 PM
To: Subhash Jadavani
Cc: linux-...@vger.kernel.org; c...@laptop.org; patc...@linaro.org;
linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH RESEND V4] mmc: core: HS200 mode support for eMMC
4.5
On 19 November 2011 00:29, Subhash Jadavani subha...@codeaurora.org
wrote:
Hi Girish,
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Girish K S
Sent: Wednesday, October 26, 2011 10:30 AM
To: linux-...@vger.kernel.org
Cc: c...@laptop.org; patc...@linaro.org; linux-samsung-
s...@vger.kernel.org; Girish K S
Subject: [PATCH RESEND V4] mmc: core: HS200 mode support for eMMC
4.5
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.
We don't need to know the card type in the host controller driver if
we pass
the command opcode as the 2nd argument to execute_tuning() ops.
Command
opcode can have have either CMD19 or CMD21 as it's value depending on
the
card type (whether it's SD3.0 card or eMMC4.5 card).
Can you see if we can implement this?
cc: Chris Ball c...@laptop.org
Signed-off-by: Girish K S girish.shivananja...@linaro.org
---
Changes in v4:
Rebased onto chris-mmc/mmc-next branch. This patch is
successfully
applied on commit with id
de022ed3fdc14808299b2fa66dbb1ed5ab921912.
Changes in v3:
In the previous commits of chris-mmc/mmc-next branch, the
patch
with
commit id (c0f22a2c92e357e7cb3988b0b13034d70b7461f9) defines
caps2 for
more capabilities. This patch version deletes the member
ext_caps(created
in my earlier patch) from struct mmc_host and reuses already
accepted
caps2 member.
Changes in v2:
Rebased to latest chris-mmc/mmc-next branch. Resolved
indentation
problems identified in review. This patch has to be applied
before
the patch released for modifying the printk messages.
Changes in v1:
Case statements in switch that produce same result have
been combined to reduce repeated assignments.
patch recreated after rebase to chris balls mmc-next branch.
drivers/mmc/core/bus.c | 3 +-
drivers/mmc/core/mmc.c | 92
drivers/mmc/host/sdhci.c | 36 +++---
include/linux/mmc/card.h | 3 +
include/linux/mmc/host.h | 6 +++
include/linux/mmc/mmc.h | 8 +++-
include/linux/mmc/sdhci.h | 1 +
7 files changed, 132 insertions(+), 17 deletions(-)
diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 46b6e84..2f82f6b 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,
+ pr_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 3627044..4db248c 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -285,6 +285,39 @@ 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:
+ case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_1_8V |
+ EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_1_2V |
+ EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_52 |
+ 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_1_2V |
+ EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ case EXT_CSD_CARD_TYPE_SDR_1_2V |
Re: [PATCH RESEND V4] mmc: core: HS200 mode support for eMMC 4.5
On 24 November 2011 11:43, Subhash Jadavani subha...@codeaurora.org wrote:
Hi Girish,
-Original Message-
From: Girish K S [mailto:girish.shivananja...@linaro.org]
Sent: Monday, November 21, 2011 4:12 PM
To: Subhash Jadavani
Cc: linux-...@vger.kernel.org; c...@laptop.org; patc...@linaro.org;
linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH RESEND V4] mmc: core: HS200 mode support for eMMC
4.5
On 19 November 2011 00:29, Subhash Jadavani subha...@codeaurora.org
wrote:
Hi Girish,
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Girish K S
Sent: Wednesday, October 26, 2011 10:30 AM
To: linux-...@vger.kernel.org
Cc: c...@laptop.org; patc...@linaro.org; linux-samsung-
s...@vger.kernel.org; Girish K S
Subject: [PATCH RESEND V4] mmc: core: HS200 mode support for eMMC
4.5
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.
We don't need to know the card type in the host controller driver if
we pass
the command opcode as the 2nd argument to execute_tuning() ops.
Command
opcode can have have either CMD19 or CMD21 as it's value depending on
the
card type (whether it's SD3.0 card or eMMC4.5 card).
Can you see if we can implement this?
I have considered this and made the patch
cc: Chris Ball c...@laptop.org
Signed-off-by: Girish K S girish.shivananja...@linaro.org
---
Changes in v4:
Rebased onto chris-mmc/mmc-next branch. This patch is
successfully
applied on commit with id
de022ed3fdc14808299b2fa66dbb1ed5ab921912.
Changes in v3:
In the previous commits of chris-mmc/mmc-next branch, the
patch
with
commit id (c0f22a2c92e357e7cb3988b0b13034d70b7461f9) defines
caps2 for
more capabilities. This patch version deletes the member
ext_caps(created
in my earlier patch) from struct mmc_host and reuses already
accepted
caps2 member.
Changes in v2:
Rebased to latest chris-mmc/mmc-next branch. Resolved
indentation
problems identified in review. This patch has to be applied
before
the patch released for modifying the printk messages.
Changes in v1:
Case statements in switch that produce same result have
been combined to reduce repeated assignments.
patch recreated after rebase to chris balls mmc-next branch.
drivers/mmc/core/bus.c | 3 +-
drivers/mmc/core/mmc.c | 92
drivers/mmc/host/sdhci.c | 36 +++---
include/linux/mmc/card.h | 3 +
include/linux/mmc/host.h | 6 +++
include/linux/mmc/mmc.h | 8 +++-
include/linux/mmc/sdhci.h | 1 +
7 files changed, 132 insertions(+), 17 deletions(-)
diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 46b6e84..2f82f6b 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,
+ pr_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 3627044..4db248c 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -285,6 +285,39 @@ 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:
+ case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_1_8V |
+ EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_1_2V |
+ EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_52 |
+ 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
