[PATCH v2 1/2] ARM: SAMSUNG: Add pm_caps into platform data
Add pm_caps into platform_data. This is power management, usually
for SDIO device such as SDIO WLAN.
Signed-off-by: Sangwook Lee sangwook@samsung.com
---
arch/arm/plat-samsung/include/plat/sdhci.h |2 ++
arch/arm/plat-samsung/platformdata.c |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/sdhci.h
b/arch/arm/plat-samsung/include/plat/sdhci.h
index dcff7dd..fcd02d4 100644
--- a/arch/arm/plat-samsung/include/plat/sdhci.h
+++ b/arch/arm/plat-samsung/include/plat/sdhci.h
@@ -40,6 +40,7 @@ enum clk_types {
* struct s3c_sdhci_platdata() - Platform device data for Samsung SDHCI
* @max_width: The maximum number of data bits supported.
* @host_caps: Standard MMC host capabilities bit field.
+ * @pm_caps: SDIO host PM capabilities bit field.
* @cd_type: Type of Card Detection method (see cd_types enum above)
* @clk_type: Type of clock divider method (see clk_types enum above)
* @ext_cd_init: Initialize external card detect subsystem. Called on
@@ -63,6 +64,7 @@ enum clk_types {
struct s3c_sdhci_platdata {
unsigned intmax_width;
unsigned inthost_caps;
+ unsigned intpm_caps;
enum cd_types cd_type;
enum clk_types clk_type;
diff --git a/arch/arm/plat-samsung/platformdata.c
b/arch/arm/plat-samsung/platformdata.c
index ceb9fa3..0f70718 100644
--- a/arch/arm/plat-samsung/platformdata.c
+++ b/arch/arm/plat-samsung/platformdata.c
@@ -53,6 +53,8 @@ void s3c_sdhci_set_platdata(struct s3c_sdhci_platdata *pd,
set-cfg_gpio = pd-cfg_gpio;
if (pd-host_caps)
set-host_caps |= pd-host_caps;
+ if (pd-pm_caps)
+ set-pm_caps |= pd-pm_caps;
if (pd-clk_type)
set-clk_type = pd-clk_type;
}
--
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] mmc: core: Add packed command for eMMC4.5 device
Hi,
On 10/27/2011 4:24 PM, Seungwon Jeon wrote:
+static int mmc_blk_packed_err_check(struct mmc_card *card,
+struct mmc_async_req *areq)
+{
+ struct mmc_queue_req *mq_mrq = container_of(areq, struct mmc_queue_req,
+ mmc_active);
+ int err, check, status;
+ u8 ext_csd[512];
+
+ check = mmc_blk_err_check(card, areq);
+
+ if (check == MMC_BLK_SUCCESS)
+ return check;
+
+ if (check == MMC_BLK_PARTIAL) {
+ err = get_card_status(card,status, 0);
+ if (err)
+ return MMC_BLK_ABORT;
+
+ if (status R1_EXP_EVENT) {
+ err = mmc_send_ext_csd(card, ext_csd);
+ if (err)
+ return MMC_BLK_ABORT;
+
+ if ((ext_csd[EXT_CSD_EXP_EVENTS_STATUS + 0]
+ EXT_CSD_PACKED_FAILURE)
+ (ext_csd[EXT_CSD_PACKED_CMD_STATUS]
+EXT_CSD_PACKED_GENERIC_ERROR)) {
+ if (ext_csd[EXT_CSD_PACKED_CMD_STATUS]
+ EXT_CSD_PACKED_INDEXED_ERROR) {
+ /* Make be 0-based */
+ mq_mrq-packed_fail_idx =
+
ext_csd[EXT_CSD_PACKED_FAILURE_INDEX] - 1;
+ return MMC_BLK_PARTIAL;
+ } else {
+ return MMC_BLK_RETRY;
+ }
+ }
+ } else {
+ return MMC_BLK_RETRY;
+ }
+ }
+
+ if (check != MMC_BLK_ABORT)
+ return MMC_BLK_RETRY;
+ else
+ return MMC_BLK_ABORT;
The current code does not return other errors (MMC_BLK_CMD_ERR,
MMC_BLK_ECC_ERR and MMC_BLK_DATA_ERR) returned by mmc_blk_err_check().
Why not return check here?
+}
+
static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
struct mmc_card *card,
int disable_multi,
@@ -1126,6 +1187,207 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req
*mqrq,
mmc_queue_bounce_pre(mqrq);
}
+static u8 mmc_blk_chk_packable(struct mmc_queue *mq, struct request *req)
+{
+ struct request_queue *q = mq-queue;
+ struct mmc_card *card = mq-card;
+ struct request *cur = req, *next = NULL;
+ struct mmc_blk_data *md = mq-data;
+ bool en_rel_wr = card-ext_csd.rel_param EXT_CSD_WR_REL_PARAM_EN;
+ unsigned int req_sectors = 0, phys_segments = 0;
+ unsigned int max_blk_count, max_phys_segs;
+ u8 max_packed_rw = 0;
+ u8 reqs = 0;
+
+ if (!(md-flags MMC_BLK_CMD23)
+ !card-ext_csd.packed_event_en)
+ goto no_packed;
+
+ if (rq_data_dir(cur) == READ)
+ max_packed_rw = card-ext_csd.max_packed_reads;
+ else
+ max_packed_rw = card-ext_csd.max_packed_writes;
+
+ if (max_packed_rw == 0)
+ goto no_packed;
+
+ if (mmc_req_rel_wr(cur)
+ (md-flags MMC_BLK_REL_WR)
+ !en_rel_wr) {
+ goto no_packed;
+ }
+
+ max_blk_count = min(card-host-max_blk_count,
+ card-host-max_req_size 9);
+ max_phys_segs = queue_max_segments(q);
+ req_sectors += blk_rq_sectors(cur);
+ phys_segments += req-nr_phys_segments;
+
+ if (rq_data_dir(cur) == WRITE) {
+ req_sectors++;
+ phys_segments++;
+ }
+
+ while (reqs max_packed_rw - 1) {
What if the number of requests exceeds the packed header size defined?
+ next = blk_fetch_request(q);
+ if (!next)
+ break;
+
+ if (rq_data_dir(cur) != rq_data_dir(next)) {
+ blk_requeue_request(q, next);
+ break;
+ }
+
+ if (mmc_req_rel_wr(next)
+ (md-flags MMC_BLK_REL_WR)
+ !en_rel_wr) {
+ blk_requeue_request(q, next);
+ break;
+ }
+
+ req_sectors += blk_rq_sectors(next);
+ if (req_sectors max_blk_count) {
+ blk_requeue_request(q, next);
+ break;
+ }
+
+ phys_segments += next-nr_phys_segments;
+ if (phys_segments max_phys_segs) {
+ blk_requeue_request(q, next);
+ break;
+ }
+
+ list_add_tail(next-queuelist,mq-mqrq_cur-packed_list);
+ cur = next;
+
Re: [PATCH] pinctrl: add a gpio and pinctrl driver for samsung io-pad controllers
On Wed, Nov 16, 2011 at 01:36:40AM +0530, Thomas Abraham wrote:
+/* Note: The pin group list needs to be further populated */
+static unsigned int exynos4210_spi0_pins[] = {
+ EXYNOS4_GPB(0), EXYNOS4_GPB(1), EXYNOS4_GPB(2), EXYNOS4_GPB(3),
+};
Given the large number of SoCs in play here might it not be better to
arrange things so that the data part can go in the SoC directory, or at
least in a file separate to the main driver. Otherwise the file is
going to get enormous but that's mostly going to be data tables.
Also, I'd expect these pin lists to include information on the function
number.
--
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 1/2] ARM: SAMSUNG: Add pm_caps into platform data
Dear Mr. Lee,
On 16 November 2011 15:50, Sangwook Lee sangwook@linaro.org wrote:
Add pm_caps into platform_data. This is power management, usually
for SDIO device such as SDIO WLAN.
Signed-off-by: Sangwook Lee sangwook@samsung.com
---
arch/arm/plat-samsung/include/plat/sdhci.h | 2 ++
arch/arm/plat-samsung/platformdata.c | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/sdhci.h
b/arch/arm/plat-samsung/include/plat/sdhci.h
index dcff7dd..fcd02d4 100644
--- a/arch/arm/plat-samsung/include/plat/sdhci.h
+++ b/arch/arm/plat-samsung/include/plat/sdhci.h
@@ -40,6 +40,7 @@ enum clk_types {
* struct s3c_sdhci_platdata() - Platform device data for Samsung SDHCI
* @max_width: The maximum number of data bits supported.
* @host_caps: Standard MMC host capabilities bit field.
+ * @pm_caps: SDIO host PM capabilities bit field.
* @cd_type: Type of Card Detection method (see cd_types enum above)
* @clk_type: Type of clock divider method (see clk_types enum above)
* @ext_cd_init: Initialize external card detect subsystem. Called on
@@ -63,6 +64,7 @@ enum clk_types {
struct s3c_sdhci_platdata {
unsigned int max_width;
unsigned int host_caps;
+ unsigned int pm_caps;
enum cd_types cd_type;
enum clk_types clk_type;
diff --git a/arch/arm/plat-samsung/platformdata.c
b/arch/arm/plat-samsung/platformdata.c
index ceb9fa3..0f70718 100644
--- a/arch/arm/plat-samsung/platformdata.c
+++ b/arch/arm/plat-samsung/platformdata.c
@@ -53,6 +53,8 @@ void s3c_sdhci_set_platdata(struct s3c_sdhci_platdata *pd,
set-cfg_gpio = pd-cfg_gpio;
if (pd-host_caps)
set-host_caps |= pd-host_caps;
+ if (pd-pm_caps)
+ set-pm_caps |= pd-pm_caps;
Are the 'pm_caps' specific to a (on-board) sdio host attached to the
sdhci controller? If yes, then this change should be fine. If no,
please let me know. I am kind of worried of any new addition to
platform data. Because, if that new addition in platform data is not
board specific data, then it becomes difficult to represent that
information in device tree.
Thanks,
Thomas.
if (pd-clk_type)
set-clk_type = pd-clk_type;
}
--
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
--
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] pinctrl: add a gpio and pinctrl driver for samsung io-pad controllers
On 16 November 2011 16:53, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Wed, Nov 16, 2011 at 01:36:40AM +0530, Thomas Abraham wrote:
+/* Note: The pin group list needs to be further populated */
+static unsigned int exynos4210_spi0_pins[] = {
+ EXYNOS4_GPB(0), EXYNOS4_GPB(1), EXYNOS4_GPB(2), EXYNOS4_GPB(3),
+};
Given the large number of SoCs in play here might it not be better to
arrange things so that the data part can go in the SoC directory, or at
least in a file separate to the main driver. Otherwise the file is
going to get enormous but that's mostly going to be data tables.
I share the same concern here and listed a todo in the driver file to
handle this case. As you said, a separate file to hold this data would
be needed until all the samsung platforms switch to using device tree.
Also, I'd expect these pin lists to include information on the function
number.
Yes, the function number is included for all the pins. It is in
'struct samsung_pin_group' with the member name 'func'. The function
number is expected to be same for all the pins in a group (atleast,
that works for exynos4). If pins in a group need different function
numbers, then I modify this.
Thank you Mark for having a look.
Regards,
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 v2 1/2] ARM: SAMSUNG: Add pm_caps into platform data
Dear Mr. Lee,
On 16 November 2011 17:48, Sangwook Lee sangwook@linaro.org wrote:
Hi Thomas
On 16 November 2011 11:47, Thomas Abraham thomas.abra...@linaro.org wrote:
Dear Mr. Lee,
On 16 November 2011 15:50, Sangwook Lee sangwook@linaro.org wrote:
Add pm_caps into platform_data. This is power management, usually
for SDIO device such as SDIO WLAN.
Signed-off-by: Sangwook Lee sangwook@samsung.com
---
arch/arm/plat-samsung/include/plat/sdhci.h | 2 ++
arch/arm/plat-samsung/platformdata.c | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/sdhci.h
b/arch/arm/plat-samsung/include/plat/sdhci.h
index dcff7dd..fcd02d4 100644
--- a/arch/arm/plat-samsung/include/plat/sdhci.h
+++ b/arch/arm/plat-samsung/include/plat/sdhci.h
@@ -40,6 +40,7 @@ enum clk_types {
* struct s3c_sdhci_platdata() - Platform device data for Samsung SDHCI
* @max_width: The maximum number of data bits supported.
* @host_caps: Standard MMC host capabilities bit field.
+ * @pm_caps: SDIO host PM capabilities bit field.
* @cd_type: Type of Card Detection method (see cd_types enum above)
* @clk_type: Type of clock divider method (see clk_types enum above)
* @ext_cd_init: Initialize external card detect subsystem. Called on
@@ -63,6 +64,7 @@ enum clk_types {
struct s3c_sdhci_platdata {
unsigned int max_width;
unsigned int host_caps;
+ unsigned int pm_caps;
enum cd_types cd_type;
enum clk_types clk_type;
diff --git a/arch/arm/plat-samsung/platformdata.c
b/arch/arm/plat-samsung/platformdata.c
index ceb9fa3..0f70718 100644
--- a/arch/arm/plat-samsung/platformdata.c
+++ b/arch/arm/plat-samsung/platformdata.c
@@ -53,6 +53,8 @@ void s3c_sdhci_set_platdata(struct s3c_sdhci_platdata
*pd,
set-cfg_gpio = pd-cfg_gpio;
if (pd-host_caps)
set-host_caps |= pd-host_caps;
+ if (pd-pm_caps)
+ set-pm_caps |= pd-pm_caps;
Are the 'pm_caps' specific to a (on-board) sdio host attached to the
sdhci controller?
No, this is not specific to a sdio host controller.
Thanks for your confirmation. Looking at the code, there are two flags
for pm_caps - MMC_PM_KEEP_POWER and MMC_PM_WAKE_SDIO_IRQ. Though these
seem to be flags for linux specific behavior, the same could be
supported from device tree as well allowing host system to use and act
on these properties or ignore it. So, adding pm_caps in platform data
should be fine from dt support perspective.
If you prefer, for the both the patches in this series,
Acked-by: Thomas Abraham thomas.abra...@linaro.org
Thanks,
Thomas.
If yes, then this change should be fine. If no,
please let me know. I am kind of worried of any new addition to
platform data. Because, if that new addition in platform data is not
board specific data, then it becomes difficult to represent that
information in device tree.
Thanks,
Thomas.
if (pd-clk_type)
set-clk_type = pd-clk_type;
}
--
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
--
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
s5p tree moved back to kernel.org
Hi Stephen, Could you please change my tree to following? git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next If any problems, please let me know. 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 1/6] ARM: SAMSUNG: Consolidation of SPI platform devices to plat-samsung
Hi Kukjin,
On Tue, Nov 15, 2011 at 12:38 PM, Kukjin Kim kgene@samsung.com wrote:
Padmavathi Venna wrote:
SPI platform device definitions consolidated from respective machine
folder to plat-samsung
Signed-off-by: Padmavathi Venna padm...@samsung.com
---
arch/arm/mach-s3c64xx/Makefile | 1 -
arch/arm/mach-s3c64xx/dev-spi.c | 172 -
arch/arm/mach-s5p64x0/Makefile | 1 -
arch/arm/mach-s5p64x0/dev-spi.c | 218
-
arch/arm/mach-s5pc100/Makefile | 1 -
arch/arm/mach-s5pc100/dev-spi.c | 220
--
arch/arm/mach-s5pv210/Makefile | 1 -
arch/arm/mach-s5pv210/dev-spi.c | 169 -
arch/arm/plat-samsung/Kconfig | 14 ++-
arch/arm/plat-samsung/devs.c | 112 +++
arch/arm/plat-samsung/include/plat/devs.h | 8 +-
arch/arm/plat-samsung/include/plat/s3c64xx-spi.h | 13 +-
12 files changed, 133 insertions(+), 797 deletions(-)
delete mode 100644 arch/arm/mach-s3c64xx/dev-spi.c
delete mode 100644 arch/arm/mach-s5p64x0/dev-spi.c
delete mode 100644 arch/arm/mach-s5pc100/dev-spi.c
delete mode 100644 arch/arm/mach-s5pv210/dev-spi.c
Hi Padma,
Basically, looks good and there are some comments below.
(snip)
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 313eb26..8a2b23a 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -226,7 +226,19 @@ config SAMSUNG_DEV_IDE
help
Compile in platform device definitions for IDE
-config S3C64XX_DEV_SPI
+config S3C64XX_DEV_SPI0
+ bool
+ help
+ Compile in platform device definitions for S3C64XX's type
+ SPI controllers.
+
+config S3C64XX_DEV_SPI1
+ bool
+ help
+ Compile in platform device definitions for S3C64XX's type
+ SPI controllers.
+
+config S3C64XX_DEV_SPI2
Yeah, needs above config to check the channel now...but I'm thinking need to
sort out it anyway.
bool
help
Compile in platform device definitions for S3C64XX's type
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 4ca8b57..76e374d 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -61,6 +61,7 @@
#include plat/regs-iic.h
#include plat/regs-serial.h
#include plat/regs-spi.h
+#include plat/s3c64xx-spi.h
static u64 samsung_device_dma_mask = DMA_BIT_MASK(32);
@@ -1461,3 +1462,114 @@ struct platform_device s3c_device_wdt = {
.resource = s3c_wdt_resource,
};
#endif /* CONFIG_S3C_DEV_WDT */
+
+#ifdef CONFIG_S3C64XX_DEV_SPI0
+static struct resource s3c64xx_spi0_resource[] = {
+ [0] = DEFINE_RES_MEM(S3C_PA_SPI0, SZ_256),
+ [1] = DEFINE_RES_DMA(DMACH_SPI0_TX),
+ [2] = DEFINE_RES_DMA(DMACH_SPI0_RX),
+ [3] = DEFINE_RES_IRQ(IRQ_SPI0),
+};
+
+struct platform_device s3c64xx_device_spi0 = {
+ .name = s3c64xx-spi,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(s3c64xx_spi0_resource),
+ .resource = s3c64xx_spi0_resource,
+ .dev = {
+ .dma_mask = samsung_device_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
+void __init s3c64xx_spi0_set_info(struct s3c64xx_spi_info *pd,
+ int src_clk_nr, int num_cs)
How about 's3c64xx_spi_set_platdata' like others in plat-samsung/devs.c?
+{
+ if (!pd) {
+ pr_err(%s:Need to pass platform data\n, __func__);
+ return;
+ }
Needs empty line here.
Okey.
+ /* Reject invalid configuration */
+ if (!num_cs || src_clk_nr 0) {
+ pr_err(%s: Invalid SPI configuration\n, __func__);
+ return;
+ }
Same as above.
Okey.
+ pd-num_cs = num_cs;
+ pd-src_clk_nr = src_clk_nr;
+ s3c_set_platdata(pd, sizeof(*pd), s3c64xx_device_spi0);
If we know the SPI controller number here, we can merge this function to
just one. So how about to add it to the 'struct s3c64xx_spi_info'?
Yes. It is good to have the controller number in the SPI Controller
defining structure.
So I will rebase the patches based on latest for-next branch and
submit the patches.
ThanksRegards
Padma
+}
(snip)
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 6/6] ARM: S3C64XX: Modified according to SPI consolidation work.
Hi Kukjin,
On Tue, Nov 15, 2011 at 12:39 PM, Kukjin Kim kgene@samsung.com wrote:
padma venkat wrote:
Hi Mark,
On Fri, Nov 4, 2011 at 4:27 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Fri, Nov 04, 2011 at 08:43:54AM -0400, Padmavathi Venna wrote:
+#ifdef CONFIG_S3C64XX_DEV_SPI0
+static struct s3c64xx_spi_info crag6410_spi0_pdata __initdata = {
+ .cfg_gpio = s3c64xx_spi0_cfg_gpio,
+ .fifo_lvl_mask = 0x7f,
+ .rx_lvl_offset = 13,
+ .tx_st_done = 21,
+};
+#endif
It seems like a step backwards to have all this stuff in the individual
machines - most of this (everything except cfg_gpio pretty much) is a
property of the SoC silicon so should be somewhere central for the SoC.
I Will move this stuff to SPI setup files and resend the patches.
Thanks
Padma
Hi Padma,
Please send text-typed e-mail when you reply :)
Okey.
And I agree with Mark, how was going on?
I will send the patches by tomorrow.
ThanksRegards
Padma
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 2/2] mmc: core: Support packed command for eMMC4.5 device
Maya Erez wrote:
+ phys_segments += next-nr_phys_segments;
+ if (phys_segments max_phys_segs) {
+ blk_requeue_request(q, next);
+ break;
+ }
I mentioned this before - if the next request is not packable
and
requeued,
blk_fetch_request will retrieve it again and this while loop
will
never terminate.
If next request is not packable, it is requeued and 'break'
terminates
this loop.
So it not infinite.
Right !! But that doesn't help finding the commands that are
packable.
Ideally, you'd need to pack all neighbouring requests into one packed
command.
The way CFQ works, it is not necessary that the fetch would return
all
outstanding
requests that are packable (unless you invoke a forced dispatch)
It
would be good to see some numbers on the number of pack hits /
misses
that
you would encounter with this logic, on a typical usecase.
Is it considered only for CFQ scheduler? How about other I/O
scheduler?
If all requests are drained from scheduler queue forcedly,
the number of candidate to be packed can be increased.
However we may lose the unique CFQ's strength and MMC D/D may take
the
CFQ's duty.
Basically, this patch accommodates the origin order requests from
I/O
scheduler.
In order to better utilize the packed commands feature and achieve
the
best performance improvements I think that the command packing should
be
done in the block layer, according to the scheduler policy.
That is, the scheduler should be aware of the capability of the
device to
receive a request list and its constrains (such as maximum number of
requests, max number of sectors etc) and use this information as a
factor
to its algorithm.
This way you keep the decision making in the hands of the scheduler
while
the MMC layer will only have to send this list as a packed command.
Yes, it would be another interesting approach.
Command packing you mentioned means gathering request among same
direction(read/write)?
Currently I/O scheduler may know device constrains which MMC driver
informs
with the exception of order information for packed command.
But I think the dependency of I/O scheduler may be able to come up.
How can MMC layer treat packed command with I/O scheduler which
doesn't support this?
The very act of packing presumes some sorting and re-ordering at the
I/O scheduler level.
When no such sorting is done (ex. noop), MMC should resort to
non-packed execution, respecting the system configuration choice.
Looking deeper into this, I think a better approach would be to set
the prep_rq_fn of the request_queue, with a custom mmc function that
decides if the requests are packable or not, and return a
BLKPREP_DEFER for those that can't be packed.
MMC layer anticipates the favorable requests for packing from I/O
scheduler.
Obviously request order from I/O scheduler might be poor for packing and
requests can't be packed.
But that doesn't mean mmc layer need to wait a better pack-case.
BLKPREP_DEFER may give rise to I/O latency. Top of request will be
deferred next time.
If request can't be packed, it'd rather be sent at once than delayed
by returning a BLKPREP_DEFER for better responsiveness.
Thanks.
Seungwon Jeon.
The decision whether a request is packable or not should not be made per
request, therefore I don't see the need for using req_prep_fn. The MMC
layer can peek each request and decide if to pack it or not when preparing
the packed list (as suggested in this patch). The scheduler changes will
improve the probability of getting a list that can be packed.
My suggestion for the scheduler change is:
The block layer will be notified of the packing limits via new queue
limits (in blk-settings). We can make it generic to allow all kinds of
requests lists. Example for the new queue limits can be:
Is_reqs_list_supported
Max_num_of_read_reqs_in_list
Max_num_of_write_reqs_in_list
max_blk_cnt_in_list
Is_list_interleaved (optional - to support read and write requests to be
linked together, not the case for eMMC4.5)
The scheduler, that will have all the required info in the queue limits,
will be able to decide which requests can be in the same list and move all
of them to the dispatch queue (in one elevator_dispatch_fn call).
If probability of packing gets higher, it would be nice.
We need to think more.
I see 2 options for preparing the list:
Option 1. blk_fetch_request will prepare the list and return a list of
requests (will require a change in struct request to include the list but
can be more generic).
Option 2. The MMC layer will prepare the list. After fetching one request
the MMC layer can call blk_peek_request and check if the next request is
packable or not. By keeping
RE: [PATCH] mmc: core: Add packed command for eMMC4.5 device
Maya Erez wrote:
+ if (reqs = 2) {
+ mmc_blk_packed_hdr_wrq_prep(mq-mqrq_cur, card,
mq, reqs);
+ if (rq_data_dir(rqc) == READ) {
+ areq = mq-mqrq_cur-mmc_active;
+ mmc_wait_for_req(card-host, areq-mrq);
Packing read requests requires preparation of two requests. After sending
the header we wait for its completion before sending the next request
(mmc_wait_for_req is used). Therefore, if we try to pack 2 read requests
we might end up with worse performance in comparison to sending each
request by itself (which allows the preparation of one request while the
other is sent).
I suggest to check the size of the packed commands list and in case it is
less than 3 send the requests one by one. If you move mmc_blk_chk_packable
to queue.c after the first fetch this change should be very easy and can
be done by removing the requests from the packed_list and calling issue_fn
for each one of them.
Sending header for packed read which doesn't require nand program
unlike normal data, so it may not spend long time.
Which point you think is the overhead of packed two-requests
in comparison to individual request?
Thanks,
Maya Erez
Consultant for Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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 v3] ARM: gic: allow GIC to support non-banked setups
On 15 November 2011 17:47, Marc Zyngier marc.zyng...@arm.com wrote: The GIC support code is heavily using the fact that hardware implementations are exposing banked registers. Unfortunately, it looks like at least one GIC implementation (EXYNOS) offers both the distributor and the CPU interfaces at different addresses, depending on the CPU. This problem is solved by allowing the distributor and CPU interface addresses to be per-cpu variables for the platforms that require it. The EXYNOS code is updated not to mess with the GIC internals while handling interrupts, and struct gic_chip_data is back to being private. The DT binding for the gic is updated to allow an optional cpu-offset value, which is used to compute the various base addresses. Finally, a new config option (GIC_NON_BANKED) is used to control this feature, so the overhead is only present on kernels compiled with support for EXYNOS. Tested on Origen (EXYNOS4) and Panda (OMAP4). Cc: Kukjin Kim kgene@samsung.com Cc: Rob Herring robherri...@gmail.com Cc: Will Deacon will.dea...@arm.com Cc: Thomas Abraham thomas.abra...@linaro.org Signed-off-by: Marc Zyngier marc.zyng...@arm.com --- This is a minor update on the previous version, simply adding a config option so that normal platforms don't have to pay the price of the get_base() indirection. Any comment is welcome, specially on the DT binding update. Documentation/devicetree/bindings/arm/gic.txt | 4 + arch/arm/common/Kconfig | 3 + arch/arm/common/gic.c | 133 + arch/arm/include/asm/hardware/gic.h | 24 ++--- arch/arm/mach-exynos/cpu.c | 16 +--- arch/arm/mach-exynos/platsmp.c | 28 +- arch/arm/plat-s5p/Kconfig | 1 + 7 files changed, 132 insertions(+), 77 deletions(-) Tested on Exynos4210 based Origen board with 'cpu-offset = 0x8000' property in GIC device node and device tree enabled kernel. Thanks for this patch. Tested-by: Thomas Abraham thomas.abra...@linaro.org -- 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: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Sahitya Tummala
Sent: Tuesday, November 08, 2011 2:10 PM
To: Girish K S
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
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 |
