Re: [PATCH RESEND V4] mmc: core: HS200 mode support for eMMC 4.5
Hi Girish,
On 10/26/2011 10:29 AM, Girish K S wrote:
This patch adds the support of the HS200 bus speed for eMMC 4.5 devices.
The eMMC 4.5 devices have support for 200MHz bus speed.The mmc core and
host modules have been touched to add support for this module.
It is necessary to know the card type in the sdhci.c file to add support
for eMMC tuning function. So card.h file is included to import the card
data structure.
cc: Chris Ballc...@laptop.org
Signed-off-by: Girish K Sgirish.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 | EXT_CSD_CARD_TYPE_DDR_1_8V |
+EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ case EXT_CSD_CARD_TYPE_SDR_1_2V | EXT_CSD_CARD_TYPE_DDR_1_2V |
+EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ case EXT_CSD_CARD_TYPE_SDR_1_2V | 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_1_2V;
+ break;
+ case EXT_CSD_CARD_TYPE_SDR_1_8V |
+EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ case EXT_CSD_CARD_TYPE_SDR_1_8V | EXT_CSD_CARD_TYPE_DDR_1_8V |
+EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ case EXT_CSD_CARD_TYPE_SDR_1_8V | EXT_CSD_CARD_TYPE_DDR_1_2V |
+EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
+ case EXT_CSD_CARD_TYPE_SDR_1_8V | 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_1_8V;
+ break;
case EXT_CSD_CARD_TYPE_DDR_52 | EXT_CSD_CARD_TYPE_52 |
Re: [PATCH V9] mmc: core: Add Power Off Notify Feature eMMC 4.5
Hi Girish,
On 10/18/2011 10:35 AM, Girish K S wrote:
This patch adds the support for power off notify feature, available in
eMMC 4.5 devices. If the the host has support for this feature, then the
mmc core will notify it to the device by setting the POWER_OFF_NOTIFICATION
byte in the extended csd register with a value 1(POWER_ON).
For suspend mode short timeout is used, whereas for the normal poweroff long
timeout is used.
cc: Chris Ballc...@laptop.org
Signed-off-by: Girish K Sgirish.shivananja...@linaro.org
Signed-off-by: Jaehoon Chungjh80.ch...@samsung.com
---
Changes in V9:
Removed the macros not related with the PowerOff notify feature.
The previous patch with commit id
bd3151f6c55c553bed2c0df72792841457b75bb5 should be deleted before
applying this patch.
Changes in V8:
Updated with review comments of Chris Ball and rebased to
chris-mmc/mmc-next branch.
Changes in V7:
Rebased to chris-mmc/mmc-next branch. merged to patches to single
patch.
Changes in V6:
Fixes checkpatch errors. The patches are generated after rebasing to
chris's mmc-next branch.
Changes in V5:
This patch version fixes the problem with power off notify function,
when called for the first time and card is not yet initialised.
Changes in V4:
Updated with review comments of Jeon
Changes in V2:
Adds poweroff notification handling in suspend/normal.
drivers/mmc/core/core.c | 34 ++
drivers/mmc/core/mmc.c | 23 +--
drivers/mmc/host/sdhci.c |9 +
include/linux/mmc/card.h |6 ++
include/linux/mmc/host.h |5 +
include/linux/mmc/mmc.h |6 ++
6 files changed, 81 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 61d7730..b1eca96 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1212,11 +1212,43 @@ static void mmc_power_up(struct mmc_host *host)
void mmc_power_off(struct mmc_host *host)
{
+ struct mmc_card *card;
+ unsigned int notify_type;
+ unsigned int timeout;
+ int err;
+
mmc_host_clk_hold(host);
+ card = host-card;
host-ios.clock = 0;
host-ios.vdd = 0;
+ if (card mmc_card_mmc(card)
+ card-poweroff_notify_state == MMC_POWERED_ON) {
+
+ if (host-power_notify_type == MMC_HOST_PW_NOTIFY_SHORT) {
+ notify_type = EXT_CSD_POWER_OFF_SHORT;
+ timeout = card-ext_csd.generic_cmd6_time;
+ card-poweroff_notify_state = MMC_POWEROFF_SHORT;
+ } else {
+ notify_type = EXT_CSD_POWER_OFF_LONG;
+ timeout = card-ext_csd.power_off_longtime;
+ card-poweroff_notify_state = MMC_POWEROFF_LONG;
+ }
+
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_POWER_OFF_NOTIFICATION,
+notify_type, timeout);
During suspend, the device can already be in sleep state (CMD5) before
mmc_power_off()
is called from mmc_suspend_host(). As per eMMC specification, when the
device is in sleep state,
it can only respond to RESET commands (CMD0 with argument of either
0x or
0xF0F0F0F0 or H/W reset) and awake command (CMD5). So, how does this
switch going
to happen (CMD6) if it is in sleep state?
Thanks,
Sahitya.
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
--
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 5/6] mmc: Add OF bindings support for mmc host controller capabilities
Hi Grant, On 8 November 2011 02:45, Grant Likely grant.lik...@secretlab.ca wrote: On Mon, Nov 07, 2011 at 07:51:26PM +0530, Thomas Abraham wrote: On 5 November 2011 01:27, Olof Johansson o...@lixom.net wrote: On Thu, Nov 03, 2011 at 02:06:02AM +0530, Thomas Abraham wrote: Device nodes representing sd/mmc controllers in a device tree would include mmc host controller capabilities. Add support for parsing of mmc host controller capabilities included in device nodes. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- .../devicetree/bindings/mmc/linux-mmc-host.txt | 13 drivers/mmc/core/host.c | 31 include/linux/mmc/host.h | 1 + 3 files changed, 45 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/linux-mmc-host.txt diff --git a/Documentation/devicetree/bindings/mmc/linux-mmc-host.txt b/Documentation/devicetree/bindings/mmc/linux-mmc-host.txt new file mode 100644 index 000..714b2b1 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/linux-mmc-host.txt @@ -0,0 +1,13 @@ +* Linux MMC Host Controller Capabilities + +The following bindings can be used in a device node to specify any board +specific mmc host controller capabilities. + +- linux,mmc_cap_4_bit_data - Host can do 4-bit transfers +- linux,mmc_cap_mmc_highspeed - Host can do MMC high-speed timing +- linux,mmc_cap_sd_highspeed - Host can do SD high-speed timing +- linux,mmc_cap_needs_poll - Host needs polling for card detection +- linux,mmc_cap_8_bit_data - Host can do 8-bit transfer +- linux,mmc_cap_disable - Host can be disabled and re-enabled to save power +- linux,mmc_cap_nonremovable - Host is connected to nonremovable media +- linux,mmc_cap_erase - Host allows erase/trim commands linux-prefixed properties are a big red flag. The device tree should describe the hardware, not what linux does with the hardware. The vendor-prefixes documentation for device tree bindings includes 'linux' as an option. And I was trying to encode the linux specific host controller capabilities using the above bindings. See previous comments about support-8bit for encoding exactly the same hardware capability in a linux-agnostic way. What the sdhci driver chooses to do with it is up to the driver, and in some cases it means it will set the capabilities flag. Same goes for the other properties. It should not go in as it is implemented in this patch, it needs to be fixed up. Ok. I will remove all these linux specific bindings and replace with a more generic ones. Bindings will be defined for all the linux defined host capabilities. Non-linux platforms can add additional bindings as required. A function to parse such properties from a controller device node could actually be shared among all the mmc/sd host controller drivers in linux. I will redo this patch and submit again. Thanks Olof for your review and comments. This patch appears to be conceptually wrong. Many of these properties are merely static capabilities of each individual device which the driver should already have knowledge of, and be setting the capability bits appropriately on its own. So, you /don't/ want to simply create a 1:1 list between the current linux capability bits (which are subject to change) and the device tree properties (which ideally must not be changed after they are defined). okay. What you need to do is figure out which properties are required to describe the hardware about things that the driver wouldn't already know. For example, 'polling' is something the driver would already know because it is an aspect of the specific device, but 'nonremovable' is a physical characteristic of some boards. 'disable' and the speed timings are also something I would expect the driver to know about and what to set itself. The host capability 'polling' seems to be more of board dependent property than controller property. This property changes the way the host stack detects the presence of the card. Some boards might have broken card detection logic. So 'polling' cannot be generalized as a controller property. Each host controller instance in a SoC would have to be told if its card detection is broken. This is done currently using the platform data. Similarly, the host property 'disable' depends on the board. The controller would be capable of handling the 'disable' feature but on some boards, disabling to save power during idle times might not work since the device connected to that host might have issues by doing so. On a SoC with multiple host controllers, some controllers would want to use 'disable' feature and others might not. So, 'disable' would have to be board specific. So, only define properties for things that the device-specific driver cannot know for itself; or are the sort of parameters that a
Re: [PATCH 6/6] mmc: sdhci-s3c: Add device tree support
Hi Grant,
On 8 November 2011 02:47, Grant Likely grant.lik...@secretlab.ca wrote:
On Thu, Nov 03, 2011 at 02:06:03AM +0530, Thomas Abraham wrote:
Add device tree based discovery support for Samsung's sdhci controller
Cc: Ben Dooks ben-li...@fluff.org
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
+Example:
+ sdhci@1253 {
+ compatible = samsung,exynos4210-sdhci;
+ reg = 0x1253 0x100;
+ interrupts = 139;
+ samsung,sdhci-bus-width = 4;
+ linux,mmc_cap_4_bit_data;
Following on from my reply on patch 5, this is an example of exactly
what I'm talking about. This node both sets bus-width to '4', and
sets the 4_bit_data flag. Don't you think that the driver would be
smart enough to set the 4_bit_data flag when the bus width was set to
4?
Yes, that is true. I will modify the driver based on your comments and
resubmit this patch.
Thanks for your comments.
Regards,
Thomas.
g.
--
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] ARM: S3C6410: Use device names for both I2C clocks
On 8 November 2011 21:39, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
When the S3C64xx CPUs were converted to clkdev mappings were added for the
I2C controllers on them. On S3C6410 a device name is specified for I2C
controller 1 but not for controller 0 which makes the code less robust as
we'll falsely return the clock for controller 0 if there's an error in the
request for controller 1.
Improve things by registering a device name for controller 0 as well. Due
to the fact that we change the numbering for controller 0 depending on if
we've registered controller 1 this requires an ifdef to choose the name.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
arch/arm/mach-s3c64xx/clock.c | 5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/clock.c b/arch/arm/mach-s3c64xx/clock.c
index 39c238d..52b264e 100644
--- a/arch/arm/mach-s3c64xx/clock.c
+++ b/arch/arm/mach-s3c64xx/clock.c
@@ -138,6 +138,11 @@ static struct clk init_clocks_off[] = {
.ctrlbit = S3C_CLKCON_PCLK_TSADC,
}, {
.name = i2c,
+#ifdef CONFIG_S3C_DEV_I2C1
+ .devname = s3c2440-i2c.0,
+#else
+ .devname = s3c2440-i2c,
+#endif
.parent = clk_p,
.enable = s3c64xx_pclk_ctrl,
.ctrlbit = S3C_CLKCON_PCLK_IIC,
The #ifdef around the id of the s3c_device_i2c0 structure in
arch/arm/plat-samsung/devs.c file can be removed and id can be fixed
as 0. And devname s3c2440-i2c.0 can be assigned above without the
#ifdef. Will there be any issues in using .id as 0 even if there is
only one instance of i2c?
Thanks,
Thomas.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: S3C6410: Use device names for both I2C clocks
On Tue, Nov 08, 2011 at 09:57:56PM +0530, Thomas Abraham wrote: On 8 November 2011 21:39, Mark Brown +#ifdef CONFIG_S3C_DEV_I2C1 + .devname = s3c2440-i2c.0, +#else + .devname = s3c2440-i2c, +#endif The #ifdef around the id of the s3c_device_i2c0 structure in arch/arm/plat-samsung/devs.c file can be removed and id can be fixed as 0. And devname s3c2440-i2c.0 can be assigned above without the #ifdef. Will there be any issues in using .id as 0 even if there is only one instance of i2c? That would be much nicer from my point of view but it's much more invasive as this device is used by a whole raft of other SoCs, not all of which have more than one I2C controller and I don't really feel like changing the idiom over the entire Samsung SoC family right now. -- 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: S5PV210: Set 1000ns as PWM backlight period on SMDKV210
The SMDK board uses LT3591 as backlight LED driver of LTE480WV LCD.
According to the LT3591 datasheet, the switching frequency should
be 1MHz. So, PWM period is calculated by following formula:
PWM period = 1/switching frequency
= 1/1MHz
= 1000ns
Thus, the PWM backlight period should be 1000ns.
Signed-off-by: Jingoo Han jg1@samsung.com
---
arch/arm/mach-s5pv210/mach-smdkv210.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv210/mach-smdkv210.c
b/arch/arm/mach-s5pv210/mach-smdkv210.c
index a9106c3..8662ef6 100644
--- a/arch/arm/mach-s5pv210/mach-smdkv210.c
+++ b/arch/arm/mach-s5pv210/mach-smdkv210.c
@@ -273,6 +273,7 @@ static struct samsung_bl_gpio_info smdkv210_bl_gpio_info = {
static struct platform_pwm_backlight_data smdkv210_bl_data = {
.pwm_id = 3,
+ .pwm_period_ns = 1000,
};
static void __init smdkv210_map_io(void)
--
1.7.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: S5P: Fix export.h inclusion
Commit 32aaeffbd4a7 (Merge branch 'modsplit-Oct31_2011'...) breaks build like following and this fixes it to add inclusion linux/export.h. arch/arm/plat-s5p/sysmmu.c:302: error: 'THIS_MODULE' undeclared here (not in a function) Signed-off-by: Kukjin Kim kgene@samsung.com --- arch/arm/plat-s5p/sysmmu.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-s5p/sysmmu.c b/arch/arm/plat-s5p/sysmmu.c index e1cbc72..c8bec9c 100644 --- a/arch/arm/plat-s5p/sysmmu.c +++ b/arch/arm/plat-s5p/sysmmu.c @@ -11,6 +11,7 @@ #include linux/io.h #include linux/interrupt.h #include linux/platform_device.h +#include linux/export.h #include asm/pgtable.h -- 1.7.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
