Re: [PATCH 2/3] ARM: mach-shmobile: Use common always on power domain governor
On Friday, December 02, 2011, Mark Brown wrote: > On Thu, Dec 01, 2011 at 09:37:07PM +0100, Rafael J. Wysocki wrote: > > On Thursday, December 01, 2011, Mark Brown wrote: > > > Saves a tiny amount of code. > > > How so? > > It saves source code size when we get the second user, by itself you're > right it doesn't achieve anything (except avoiding redundancy once 1/3 > gets applied I guess). But the patch removed useful code without adding any replacements, as far as I could see it. Thanks, Rafael -- 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 3/3] ARM: S3C64XX: Implement basic power domain support
On Fri, Dec 02, 2011 at 09:10:27PM +0100, Sylwester Nawrocki wrote:
> > + /* Not all domains provide power status readback */
> > + if (pd->pwr_stat) {
> > + while (retry--)
> > + if (__raw_readl(S3C64XX_BLK_PWR_STAT) & pd->pwr_stat)
> > + break;
> How about adding cpu_relax() in this busy wait loop ?
May as well, yes - I didn't actually measure how long it tends to take
to do the spin but it's not going to hurt.
--
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 3/3] ARM: S3C64XX: Implement basic power domain support
Hi Mark,
good to see someone adding a proper power domain support for s3c64xx.
On 12/01/2011 07:48 PM, Mark Brown wrote:
> The S3C64xx SoCs contain a set of gateable power domains which can be
> enabled and disabled at runtime in order to save power. Use the generic
> power domain code to implement support for these in software, enabling
> runtime control of most domains:
>
> - ETM (not supported in mainline).
> - Domain G: 3D acceleration (no mainline support).
> - Domain V: MFC (no mainline support).
> - Domain I: JPEG and camera interface (no mainline support).
> - Domain P: 2D acceleration, TV encoder and scaler (no mainline support)
> - Domain S: Security (no mainline support).
> - Domain F: LCD (driver already uses runtime PM), post processing and
>rotation (no mainline support).
>
> The IROM domain is marked as always enabled as we should arrange for it
> to be enabled when we suspend which will need a bit more work.
>
> Due to all the conditional device registration that the platform does
> wrap s3c_pm_init() with s3c64xx_pm_init() which actually puts the device
> into the power domain after the machines have registered, looking for
> platform data to tell if the device was registered. Since currently only
> Cragganmore actually sets up PM that is the only machine updated.
>
> Signed-off-by: Mark Brown
> ---
...
> +
> +static int s3c64xx_pd_on(struct generic_pm_domain *domain)
> +{
> + struct s3c64xx_pm_domain *pd;
> + u32 val;
> + long retry = 100L;
> +
> + pd = container_of(domain, struct s3c64xx_pm_domain, pd);
> +
> + val = __raw_readl(S3C64XX_NORMAL_CFG);
> + val |= pd->ena;
> + __raw_writel(val, S3C64XX_NORMAL_CFG);
> +
> + /* Not all domains provide power status readback */
> + if (pd->pwr_stat) {
> + while (retry--)
> + if (__raw_readl(S3C64XX_BLK_PWR_STAT) & pd->pwr_stat)
> + break;
How about adding cpu_relax() in this busy wait loop ?
> + if (!retry) {
> + pr_err("Failed to start domain %s\n", pd->name);
> + return -EBUSY;
> + }
> + }
> +
> + return 0;
> +}
--
Regards,
Sylwester
--
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 3/3] ARM: S3C64XX: Implement basic power domain support
On Friday 02 of December 2011 18:57:43 Mark Brown wrote: > On Fri, Dec 02, 2011 at 07:25:01PM +0100, Tomasz Figa wrote: > > Please do not forget that there might be some drivers not yet submited > > to mainline and mainline should not break them with an assumption that > > there are no such drivers. > > > > For example, there is an on-going work on an open source OpenGL > > implementation for the GPU in S3C6410, known as OpenFIMG. Currently it > > uses a little kernel module for low level hardware management > > (interrupts, contexts, locking, power management), involving clock > > gating and runtime power management, but a DRM driver is planned. > > As I said in the commit message for the patch you're following up on > I don't think that's a problem as it's pretty straightforward to add the > requisite hooks as part of adding the actual drivers. The power domain > framework is really easy to use so it's not like it should cause real > effort, if you can figure out how to drive a 3D graphics engine adding a > device to a power domain shouldn't be too hard. > > There will need to be arch/arm changes to add the platform devices and > hook up the clocks anyway so it's not like this is creating a need for > modifications. Indeed I'd suggest adding the arch/arm stuff as it gets > written anyway, even if the actual drivers are still a work in progress. > It's one less thing to carry out of tree and it means that updates like > this or like the clk API reworks that I'd expect to start appearing soon > will happen for free. Yeah, I'm okay with that, I just noted that there is more support for S3C6410 available than just what is present in mainline. Best regards, Tom -- 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 3/3] ARM: S3C64XX: Implement basic power domain support
On Fri, Dec 02, 2011 at 07:25:01PM +0100, Tomasz Figa wrote: > Please do not forget that there might be some drivers not yet submited > to mainline and mainline should not break them with an assumption that > there are no such drivers. > For example, there is an on-going work on an open source OpenGL > implementation for the GPU in S3C6410, known as OpenFIMG. Currently it > uses a little kernel module for low level hardware management > (interrupts, contexts, locking, power management), involving clock > gating and runtime power management, but a DRM driver is planned. As I said in the commit message for the patch you're following up on I don't think that's a problem as it's pretty straightforward to add the requisite hooks as part of adding the actual drivers. The power domain framework is really easy to use so it's not like it should cause real effort, if you can figure out how to drive a 3D graphics engine adding a device to a power domain shouldn't be too hard. There will need to be arch/arm changes to add the platform devices and hook up the clocks anyway so it's not like this is creating a need for modifications. Indeed I'd suggest adding the arch/arm stuff as it gets written anyway, even if the actual drivers are still a work in progress. It's one less thing to carry out of tree and it means that updates like this or like the clk API reworks that I'd expect to start appearing soon will happen for free. -- 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 3/3] ARM: S3C64XX: Implement basic power domain support
Hi, W dniu 2 grudnia 2011 01:56 użytkownik Mark Brown napisał: On Fri, Dec 02, 2011 at 09:35:44AM +0900, Kyungmin Park wrote: I'm not sure what's the next step at s3c64xx for generic power domain. Related with exysno4 series, it's helpful to read following threads. http://68.183.106.108/lists/linux-pm/msg26291.html "I don't think we should control/gate the clocks with regarding power domain" from Mr. Kim I tend to agree with him that gating the clocks automatically using runtime PM would be nice as if nothing else it saves code in drivers. I'm not sure how easy it's going to be to transition to doing that in one jump, though - there's a lot of SoCs sharing IP right back to S3C24xx. Of course it should be fairly easy for most of the domains on s3c64xx right now as there's only one actual driver involved in mainline, we should just be gating almost all of the clocks concerned immediately after we boot (assuming they aren't gated by default, I'd need to check) and never touching them again anyway. It'd only be the framebuffer clocks that'd need some work and for a first pass we could just mark the framebuffer domain as always on and get most of the win. Sometimes lack of driver support is a good thing :) Please do not forget that there might be some drivers not yet submited to mainline and mainline should not break them with an assumption that there are no such drivers. For example, there is an on-going work on an open source OpenGL implementation for the GPU in S3C6410, known as OpenFIMG. Currently it uses a little kernel module for low level hardware management (interrupts, contexts, locking, power management), involving clock gating and runtime power management, but a DRM driver is planned. Best regards, Tom -- 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 V5] mmc: core: HS200 mode support for eMMC 4.5
On 2 December 2011 00:02, Subhash Jadavani wrote:
>
>
>> -Original Message-
>> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
>> ow...@vger.kernel.org] On Behalf Of Girish K S
>> Sent: Thursday, December 01, 2011 7:48 PM
>> To: Subhash Jadavani
>> Cc: linux-...@vger.kernel.org; patc...@linaro.org; linux-samsung-
>> s...@vger.kernel.org; Chris Ball
>> Subject: Re: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5
>>
>> On 1 December 2011 16:27, Subhash Jadavani
>> wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
>> >> ow...@vger.kernel.org] On Behalf Of Girish K S
>> >> Sent: Thursday, December 01, 2011 3:58 PM
>> >> To: Subhash Jadavani
>> >> Cc: linux-...@vger.kernel.org; patc...@linaro.org; linux-samsung-
>> >> s...@vger.kernel.org; Chris Ball
>> >> Subject: Re: [PATCH V5] mmc: core: HS200 mode support for eMMC 4.5
>> >>
>> >> On 1 December 2011 15:33, Subhash Jadavani
>> >> 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, November 30, 2011 2:24 PM
>> >> >> To: linux-...@vger.kernel.org
>> >> >> Cc: patc...@linaro.org; linux-samsung-soc@vger.kernel.org;
>> >> >> subha...@codeaurora.org; Girish K S; Chris Ball
>> >> >> Subject: [PATCH V5] 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.
>> >> >>
>> >> >> cc: Chris Ball
>> >> >> Signed-off-by: Girish K S
>> >> >> ---
>> >> >> Changes in v5:
>> >> >> Reduced the case statements for better code readability.
>> >> Removed
>> >> >> unused macro definitions. Modified the tuning function
>> >> prototype
>> >> >> and definition to support tuning for both SD and eMMC
>> cards.
>> >> >> 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 | 77
>> >> >>
>> >> >> drivers/mmc/core/sd.c | 3 +-
>> >> >> drivers/mmc/core/sdio.c | 4 ++-
>> >> >> drivers/mmc/host/sdhci.c | 38 +-
>> >> >> include/linux/mmc/card.h | 3 ++
>> >> >> include/linux/mmc/host.h | 11 ++-
>> >> >> include/linux/mmc/mmc.h | 66
>> >> >> ++-
>> >> >> include/linux/mmc/sdhci.h | 1 +
>> >> >> 9 files changed, 185 insertions(+), 21 deletions(-)
>> >> >>
>> >> >> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
>> >> >> index 5639fdf..83c9f8d 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_card_uhs(card) ? "ultra high speed " :
>> >> >> (mmc_card_highspeed(card) ? "high speed " :
>> >> ""),
>> >> >> + (mmc_card_hs200(card) ? "HS200 " : ""),
>> >> >> mmc_card_ddr_mode(card) ? "DDR " : "",
>> >> >>
MFC V1.0 questions
Hello I am interested in a couple of questions related to mfv v1.0, used in the s3c6410. 1) Does anyone work on mfc v1.0 driver for mainline? 2) whether there is a newer firmware for MFC processor other than the V137? 3) how much different MFC version 1.0 (6410) and 4.0 (pv210). Should I rely on the driver for MFC v4.0, when writing a driver for V1.0? Thank you! -- 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 v2 1/2] mmc: core: Add packed command feature of eMMC4.5
This patch adds packed command feature of eMMC4.5.
The maximum number for packing read(or write) is offered
and exception event relevant to packed command which is
used for error handling is enabled. If host wants to use
this feature, MMC_CAP2_PACKED_CMD should be set.
Signed-off-by: Seungwon Jeon
---
drivers/mmc/core/mmc.c | 24
include/linux/mmc/card.h |3 +++
include/linux/mmc/host.h |1 +
include/linux/mmc/mmc.h | 15 +++
4 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index e8b6b5d..fc8a4cf 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -487,6 +487,11 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8
*ext_csd)
ext_csd[EXT_CSD_CACHE_SIZE + 1] << 8 |
ext_csd[EXT_CSD_CACHE_SIZE + 2] << 16 |
ext_csd[EXT_CSD_CACHE_SIZE + 3] << 24;
+
+ card->ext_csd.max_packed_writes =
+ ext_csd[EXT_CSD_MAX_PACKED_WRITES];
+ card->ext_csd.max_packed_reads =
+ ext_csd[EXT_CSD_MAX_PACKED_READS];
}
out:
@@ -1076,6 +1081,25 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
card->ext_csd.cache_ctrl = err ? 0 : 1;
}
+ if ((host->caps2 & MMC_CAP2_PACKED_CMD) &&
+ (card->ext_csd.max_packed_writes > 0) &&
+ (card->ext_csd.max_packed_reads > 0)) {
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+ EXT_CSD_EXP_EVENTS_CTRL,
+ EXT_CSD_PACKED_EVENT_EN,
+ card->ext_csd.generic_cmd6_time);
+ if (err && err != -EBADMSG)
+ goto free_card;
+ if (err) {
+ pr_warning("%s: Enabling packed event failed\n",
+ mmc_hostname(card->host));
+ card->ext_csd.packed_event_en = 0;
+ err = 0;
+ } else {
+ card->ext_csd.packed_event_en = 1;
+ }
+ }
+
if (!oldcard)
host->card = card;
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 6402d92..73e8add 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -52,6 +52,9 @@ struct mmc_ext_csd {
u8 part_config;
u8 cache_ctrl;
u8 rst_n_function;
+ u8 max_packed_writes;
+ u8 max_packed_reads;
+ u8 packed_event_en;
unsigned intpart_time; /* Units: ms */
unsigned intsa_timeout; /* Units: 100ns */
unsigned intgeneric_cmd6_time; /* Units: 10ms */
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 9a03d03..5667035 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -242,6 +242,7 @@ struct mmc_host {
#define MMC_CAP2_CACHE_CTRL(1 << 1)/* Allow cache control */
#define MMC_CAP2_POWEROFF_NOTIFY (1 << 2) /* Notify poweroff supported */
#define MMC_CAP2_NO_MULTI_READ (1 << 3)/* Multiblock reads don't work
*/
+#define MMC_CAP2_PACKED_CMD(1 << 4)/* Allow packed command */
mmc_pm_flag_t pm_caps;/* supported pm features */
unsigned intpower_notify_type;
diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
index 0e71356..1b94c4f 100644
--- a/include/linux/mmc/mmc.h
+++ b/include/linux/mmc/mmc.h
@@ -138,6 +138,7 @@ static inline bool mmc_op_multi(u32 opcode)
#define R1_CURRENT_STATE(x)((x & 0x1E00) >> 9) /* sx, b (4 bits) */
#define R1_READY_FOR_DATA (1 << 8)/* sx, a */
#define R1_SWITCH_ERROR(1 << 7)/* sx, c */
+#define R1_EXP_EVENT (1 << 6)/* sr, a */
#define R1_APP_CMD (1 << 5)/* sr, c */
#define R1_STATE_IDLE 0
@@ -273,6 +274,10 @@ struct _mmc_csd {
#define EXT_CSD_FLUSH_CACHE32 /* W */
#define EXT_CSD_CACHE_CTRL 33 /* R/W */
#define EXT_CSD_POWER_OFF_NOTIFICATION 34 /* R/W */
+#define EXT_CSD_PACKED_FAILURE_INDEX 35 /* RO */
+#define EXT_CSD_PACKED_CMD_STATUS 36 /* RO */
+#define EXT_CSD_EXP_EVENTS_STATUS 54 /* RO, 2 bytes */
+#define EXT_CSD_EXP_EVENTS_CTRL56 /* R/W, 2 bytes */
#define EXT_CSD_GP_SIZE_MULT 143 /* R/W */
#define EXT_CSD_PARTITION_ATTRIBUTE156 /* R/W */
#define EXT_CSD_PARTITION_SUPPORT 160 /* RO */
@@ -313,6 +318,8 @@ struct _mmc_csd {
#define EXT_CSD_POWER_OFF_LONG_TIME247 /* RO */
#define EXT_CSD_GENERIC_CMD6_TIME 248 /* RO */
#define EXT_CSD_CACHE_S
[PATCH v2 2/2] mmc: core: Support packed command for eMMC4.5 device
This patch supports packed command of eMMC4.5 device.
Several reads(or writes) can be grouped in packed command
and all data of the individual commands can be sent in a
single transfer on the bus.
Signed-off-by: Seungwon Jeon
---
drivers/mmc/card/block.c | 454 ++--
drivers/mmc/card/queue.c | 48 +-
drivers/mmc/card/queue.h | 13 ++
drivers/mmc/core/mmc_ops.c |1 +
include/linux/mmc/core.h |3 +
5 files changed, 495 insertions(+), 24 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index ad0fb8d..f128df3 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -59,6 +59,13 @@ MODULE_ALIAS("mmc:block");
#define INAND_CMD38_ARG_SECTRIM1 0x81
#define INAND_CMD38_ARG_SECTRIM2 0x88
+#define mmc_req_rel_wr(req)(((req->cmd_flags & REQ_FUA) || \
+ (req->cmd_flags & REQ_META)) && \
+ (rq_data_dir(req) == WRITE))
+#define PACKED_CMD_VER 0x01
+#define PACKED_CMD_RD 0x01
+#define PACKED_CMD_WR 0x02
+
static DEFINE_MUTEX(block_mutex);
/*
@@ -99,6 +106,7 @@ struct mmc_blk_data {
#define MMC_BLK_WRITE BIT(1)
#define MMC_BLK_DISCARDBIT(2)
#define MMC_BLK_SECDISCARD BIT(3)
+#define MMC_BLK_WR_HDR BIT(4)
/*
* Only set in main mmc_blk_data associated
@@ -951,7 +959,8 @@ static int mmc_blk_err_check(struct mmc_card *card,
* kind. If it was a write, we may have transitioned to
* program mode, which we have to wait for it to complete.
*/
- if (!mmc_host_is_spi(card->host) && rq_data_dir(req) != READ) {
+ if ((!mmc_host_is_spi(card->host) && rq_data_dir(req) != READ) ||
+ (mq_mrq->packed_cmd == MMC_PACKED_WR_HDR)) {
u32 status;
do {
int err = get_card_status(card, &status, 5);
@@ -988,12 +997,60 @@ static int mmc_blk_err_check(struct mmc_card *card,
if (!brq->data.bytes_xfered)
return MMC_BLK_RETRY;
+ if (mq_mrq->packed_cmd != MMC_PACKED_NONE) {
+ if (unlikely(brq->data.blocks << 9 != brq->data.bytes_xfered))
+ return MMC_BLK_PARTIAL;
+ else
+ return MMC_BLK_SUCCESS;
+ }
+
if (blk_rq_bytes(req) != brq->data.bytes_xfered)
return MMC_BLK_PARTIAL;
return MMC_BLK_SUCCESS;
}
+static int mmc_blk_packed_err_check(struct mmc_card *card,
+struct mmc_async_req *areq)
+{
+ struct mmc_queue_req *mq_rq = container_of(areq, struct mmc_queue_req,
+ mmc_active);
+ struct request *req = mq_rq->req;
+ int err, check, status;
+ u8 ext_csd[512];
+
+ check = mmc_blk_err_check(card, areq);
+ err = get_card_status(card, &status, 0);
+ if (err) {
+ pr_err("%s: error %d sending status command\n",
+ req->rq_disk->disk_name, err);
+ return MMC_BLK_ABORT;
+ }
+
+ if (status & R1_EXP_EVENT) {
+ err = mmc_send_ext_csd(card, ext_csd);
+ if (err) {
+ pr_err("%s: error %d sending ext_csd\n",
+ req->rq_disk->disk_name, err);
+ return MMC_BLK_ABORT;
+ }
+
+ if ((ext_csd[EXT_CSD_EXP_EVENTS_STATUS] &
+ 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) {
+ mq_rq->packed_fail_idx =
+ ext_csd[EXT_CSD_PACKED_FAILURE_INDEX] -
1;
+ return MMC_BLK_PARTIAL;
+ }
+ }
+ }
+
+ return check;
+}
+
static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
struct mmc_card *card,
int disable_multi,
@@ -1137,10 +1194,238 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req
*mqrq,
mmc_queue_bounce_pre(mqrq);
}
+static u8 mmc_blk_prep_packed_list(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 put_back = 0;
+ u8 max_packed_rw = 0;
+ u8 reqs = 0;
+
+ mq->mqrq_cur->packed_num = 0;
+
+ if (!(md
[PATCH v2 0/2] mmc: core: Support packed command feature of eMMC4.5
This patch-set adds support of packed command feature for eMMC4.5 devices. Changes in v2: - Fixed the packed read sequence and error handling. - Applied checking the exception status for all cases with the comments from Maya Erez and Sahitya Tummala. - Fixed preparing the packed list with the comment from Maya Erez and Venkatraman. Seungwon Jeon (2): mmc: core: Add packed command feature of eMMC4.5 mmc: core: Support packed command for eMMC4.5 device drivers/mmc/card/block.c | 454 ++-- drivers/mmc/card/queue.c | 48 +- drivers/mmc/card/queue.h | 13 ++ drivers/mmc/core/mmc.c | 24 +++ drivers/mmc/core/mmc_ops.c |1 + include/linux/mmc/card.h |3 + include/linux/mmc/core.h |3 + include/linux/mmc/host.h |1 + include/linux/mmc/mmc.h| 15 ++ 9 files changed, 538 insertions(+), 24 deletions(-) Best regards, Seungwon Jeon. -- 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 RESEND V5] 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.
cc: Chris Ball
Signed-off-by: Girish K S
---
Changes in v5:
Reduced the case statements for better code readability. Removed
unused macro definitions. Modified the tuning function prototype
and definition to support tuning for both SD and eMMC cards.
Rebased to the latest chris-mmc branch.
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| 77
drivers/mmc/core/sd.c |3 +-
drivers/mmc/core/sdio.c |4 ++-
drivers/mmc/host/sdhci.c | 38 +-
include/linux/mmc/card.h |3 ++
include/linux/mmc/host.h | 11 ++-
include/linux/mmc/mmc.h | 66 ++-
include/linux/mmc/sdhci.h |1 +
9 files changed, 185 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 5639fdf..83c9f8d 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_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 e8b6b5d..d1e85ba 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -285,6 +285,27 @@ 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_ALL:
+ case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_8V:
+ case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_2V:
+ case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_52:
+ 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_ALL:
+ case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_8V:
+ case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_2V:
+ case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_52:
+ 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_ALL:
+ case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_1_8V:
+ case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_1_2V:
+ case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_52:
+ 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 |
EXT_CSD_CARD_TYPE_26:
card->ext_csd.hs_max_dtr = 5200;
@@ -699,6 +720,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
{
struct mmc_card *card;
int err, ddr = 0;
+ int hs_sdr = 0;
u32 cid[4];
unsigned int max_dtr;
u32 rocr;
@@ -894,11 +916,16 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
/*
* Activate high speed (if supported)
*/
- if ((card->ext_csd.hs_max_dtr != 0) &&
- (host->caps & MMC_CAP_MMC_HIGHSPEED)) {
-
Re: [PATCH 1/2] ARM: exynos4: Fix build error due to 'gic_bank_offset' undeclared
On 02/12/11 08:43, Kukjin Kim wrote:
> Marc Zyngier wrote:
>>
>> On 01/12/11 15:24, Axel Lin wrote:
>>> Fix below build error:
>>> CC arch/arm/mach-exynos/cpu.o
>>> arch/arm/mach-exynos/cpu.c: In function 'exynos4_init_irq':
>>> arch/arm/mach-exynos/cpu.c:245: error: 'gic_bank_offset' undeclared
>> (first use in this function)
>>> arch/arm/mach-exynos/cpu.c:245: error: (Each undeclared identifier is
>> reported only once
>>> arch/arm/mach-exynos/cpu.c:245: error: for each function it appears in.)
>>> arch/arm/mach-exynos/cpu.c:243: warning: unused variable 'bank_offset'
>>> make[1]: *** [arch/arm/mach-exynos/cpu.o] Error 1
>>> make: *** [arch/arm/mach-exynos] Error 2
>>>
>>> Signed-off-by: Axel Lin
>>
>> Arghhh... My bad. Thanks for fixing that.
>>
>> Acked-by: Marc Zyngier
>>
> Hi Marc,
>
> Since the commit 4e44d2cb("ARM: exynos4: convert to
> CONFIG_MULTI_IRQ_HANDLER") is not in my tree, this should be handled in your
> tree and Axel's patch, "ARM: exynos4: Fix build error" is too.
Hi Kukjin,
No problem, I'll take these through my tree and send a pull request to
Russell.
Cheers,
M.
--
Jazz is not dead. It just smells funny...
--
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 3/4] ARM Exynos4210-Nuri: remove compiler errors
On Fri, Dec 2, 2011 at 5:59 PM, Kukjin Kim wrote: > MyungJoo Hamm wrote: >> > What's the 'compiler errors'? > > And I don't know why this patch included in this series, maybe this should > be separated from this series? The error is: arch/arm/mach-exynos/mach-nuri.c: In function ‘nuri_power_init’: arch/arm/mach-exynos/mach-nuri.c:1080:2: error: implicit declaration of function ‘irq_alloc_descs’ It is due to the recent changes in some of the header files (they removed some header inclusion from header fiiles). In this patchset, we are providing a test case (Exynos4210-Nuri) for the device driver and we had to resolve the compiler error first. Cheers! MyungJoo -- 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 1/4] ARM: EXYNOS4: Add DMC1, allow PPMU access for DMC.
On 12/2/11, Kukjin Kim wrote:
> MyungJoo Ham wrote:
>>
>> - Add DMC1
>> - Enlarge address space for DMC from 4k to 64k so that PPMU registers
>> may be accessed.
>>
>> Signed-off-by: MyungJoo Ham
>> Signed-off-by: Kyungmin Park
>> ---
>> arch/arm/mach-exynos/cpu.c |7 ++-
>> arch/arm/mach-exynos/include/mach/map.h |1 +
>> 2 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
>> index 90ec247..8bdcba9 100644
>> --- a/arch/arm/mach-exynos/cpu.c
>> +++ b/arch/arm/mach-exynos/cpu.c
>> @@ -108,7 +108,12 @@ static struct map_desc exynos4_iodesc[] __initdata =
>> {
>> }, {
>> .virtual= (unsigned long)S5P_VA_DMC0,
>> .pfn= __phys_to_pfn(EXYNOS4_PA_DMC0),
>> -.length = SZ_4K,
>> +.length = SZ_64K,
>> +.type = MT_DEVICE,
>> +}, {
>> +.virtual= (unsigned long)S5P_VA_DMC1,
>> +.pfn= __phys_to_pfn(EXYNOS4_PA_DMC1),
>> +.length = SZ_64K,
>> .type = MT_DEVICE,
>> }, {
>> .virtual= (unsigned long)S5P_VA_SROMC,
>> diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-
>> exynos/include/mach/map.h
>> index 058541d..870a980 100644
>> --- a/arch/arm/mach-exynos/include/mach/map.h
>> +++ b/arch/arm/mach-exynos/include/mach/map.h
>> @@ -57,6 +57,7 @@
>> #define EXYNOS4_PA_KEYPAD 0x100A
>>
>> #define EXYNOS4_PA_DMC0 0x1040
>> +#define EXYNOS4_PA_DMC1 0x1041
>
> If required, so just '.length = SZ_128K'?...
Doesn't it more confuse and difficult to use?
Even though there's not much definitions. it defines the offset concept.
"arch/arm/mach-exynos/include/mach/regs-mem.h"
BR,
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim , Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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/3] Moving xusbxti clock setting in clock.c file.
Pankaj Dubey wrote: > Subject: [PATCH 0/3] Moving xusbxti clock setting in clock.c file. > > Since there is code duplication in different mach-board.c file it is > better > to set default clock rate of xusbxti clock in plat-s5p/clock.c file. > > The patches are based on following commit on Kukjin's for-next branch. > > Pankaj (1): > ARM: S5P: Set default rate of xusbxti clock > > Pankaj Dubey (2): > ARM: EXYNOS: Removed code for setting clock rate of xusbxti > ARM: S5PV210: Removed code for setting clock rate of xusbxti > > arch/arm/mach-exynos/mach-nuri.c |1 - > arch/arm/mach-exynos/mach-origen.c |1 - > arch/arm/mach-exynos/mach-smdk4x12.c |2 -- > arch/arm/mach-exynos/mach-smdkv310.c |1 - > arch/arm/mach-s5pv210/mach-goni.c|1 - > arch/arm/plat-s5p/clock.c|1 + > 6 files changed, 1 insertions(+), 6 deletions(-) > > -- > 1.7.4.1 > No, clock rate of xusbxti clock can be changeable according to board. > -- > 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 2/2] mmc: core: Support packed command for eMMC4.5 device
Maya Erez wrote:
> > Maya Erez wrote:
> >> >> >> On Wed, Nov 2, 2011 at 1:33 PM, Seungwon Jeon
> >>
> >> >> wrote:
> >> >> >> > @@ -980,12 +988,67 @@ static int mmc_blk_err_check(struct
> >> mmc_card
> >> >> *card,
> >> >> >> > if (!brq->data.bytes_xfered)
> >> >> >> > return MMC_BLK_RETRY;
> >> >> >> >
> >> >> >> > + if (mq_mrq->packed_cmd != MMC_PACKED_NONE) {
> >> >> >> > + if (unlikely(brq->data.blocks << 9 !=
> >> >> brq->data.bytes_xfered))
> >> >> >> > + return MMC_BLK_PARTIAL;
> >> >> >> > + else
> >> >> >> > + return MMC_BLK_SUCCESS;
> >> >> >> > + }
> >> >> >> > +
> >> >> >> > if (blk_rq_bytes(req) != brq->data.bytes_xfered)
> >> >> >> > return MMC_BLK_PARTIAL;
> >> >> >> >
> >> >> >> > return MMC_BLK_SUCCESS;
> >> >> >> > }
> >> >> >> >
> >> >> >> > +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;
> >> I think we need to check the status for all cases and not only in case
> >> of
> >> MMC_BLK_PARTIAL. For example, in cases where the header was traferred
> >> successfully but had logic errors (wrong number of sectors etc.)
> >> mmc_blk_err_check will return MMC_BLK_SUCCESS although the packed
> >> commands
> >> failed.
> > Similarly, Sahitya Tummala is already mentioned this.
> > Other error case will be checked in next version.
> > The case you suggested is about read or write?
> > Device may detect error and stop transferring the data.
> Sahitya suggested to also check other error cases that mmc_blk_err_check
> returns (such as MMC_BLK_CMD_ERR, MMC_BLK_ECC_ERR and MMC_BLK_DATA_ERR).
> I suggest to also check the exception bit in the status even if
> mmc_blk_err_check returned success, since mmc_blk_err_check might not
> catch all the packed commands failures. One example for such a failure is
> when the header of read packed commands will have logical error.
This part is modified in next version.
Thanks,
Seungwon Jeon.
> Thanks,
> Maya
> --
> Seny by a 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 1/4] ARM: EXYNOS4: Add DMC1, allow PPMU access for DMC.
MyungJoo Ham wrote:
>
> - Add DMC1
> - Enlarge address space for DMC from 4k to 64k so that PPMU registers
> may be accessed.
>
> Signed-off-by: MyungJoo Ham
> Signed-off-by: Kyungmin Park
> ---
> arch/arm/mach-exynos/cpu.c |7 ++-
> arch/arm/mach-exynos/include/mach/map.h |1 +
> 2 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
> index 90ec247..8bdcba9 100644
> --- a/arch/arm/mach-exynos/cpu.c
> +++ b/arch/arm/mach-exynos/cpu.c
> @@ -108,7 +108,12 @@ static struct map_desc exynos4_iodesc[] __initdata =
> {
> }, {
> .virtual= (unsigned long)S5P_VA_DMC0,
> .pfn= __phys_to_pfn(EXYNOS4_PA_DMC0),
> - .length = SZ_4K,
> + .length = SZ_64K,
> + .type = MT_DEVICE,
> + }, {
> + .virtual= (unsigned long)S5P_VA_DMC1,
> + .pfn= __phys_to_pfn(EXYNOS4_PA_DMC1),
> + .length = SZ_64K,
> .type = MT_DEVICE,
> }, {
> .virtual= (unsigned long)S5P_VA_SROMC,
> diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-
> exynos/include/mach/map.h
> index 058541d..870a980 100644
> --- a/arch/arm/mach-exynos/include/mach/map.h
> +++ b/arch/arm/mach-exynos/include/mach/map.h
> @@ -57,6 +57,7 @@
> #define EXYNOS4_PA_KEYPAD0x100A
>
> #define EXYNOS4_PA_DMC0 0x1040
> +#define EXYNOS4_PA_DMC1 0x1041
If required, so just '.length = SZ_128K'?...
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: EXYNOS: Enable MDMA driver
> -Original Message-
> From: Boojin Kim [mailto:boojin@samsung.com]
> Sent: Monday, November 28, 2011 4:51 PM
> To: linux-arm-ker...@lists.infradead.org; linux-samsung-
> s...@vger.kernel.org
> Cc: Kukjin Kim; Boojin Kim
> Subject: [PATCH] ARM: EXYNOS: Enable MDMA driver
>
> This patch adds MDMA platform data and enables MDMA for DMA memcpy
> operation
>
> Signed-off-by: Boojin Kim
> ---
> arch/arm/mach-exynos/clock.c |8 +
> arch/arm/mach-exynos/dma.c | 35
> arch/arm/mach-exynos/include/mach/irqs.h |2 +
> arch/arm/mach-exynos/include/mach/map.h|3 +-
> arch/arm/plat-samsung/include/plat/dma-pl330.h |8 +
> 5 files changed, 55 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/clock.c b/arch/arm/mach-exynos/clock.c
> index 5d8d483..28e2842 100644
> --- a/arch/arm/mach-exynos/clock.c
> +++ b/arch/arm/mach-exynos/clock.c
> @@ -782,6 +782,13 @@ static struct clk clk_pdma1 = {
> .ctrlbit= (1 << 1),
> };
>
> +static struct clk clk_mdma1 = {
> + .name = "dma",
> + .devname= "dma-pl330.2",
> + .enable = exynos4_clk_ip_image_ctrl,
> + .ctrlbit= ((1 << 8) | (1 << 5) | (1 << 2)),
> +};
> +
> struct clk *clkset_group_list[] = {
> [0] = &clk_ext_xtal_mux,
> [1] = &clk_xusbxti,
> @@ -1294,6 +1301,7 @@ static struct clksrc_clk *sysclks[] = {
> static struct clk *clk_cdev[] = {
> &clk_pdma0,
> &clk_pdma1,
> + &clk_mdma1,
> };
>
> static struct clksrc_clk *clksrc_cdev[] = {
> diff --git a/arch/arm/mach-exynos/dma.c b/arch/arm/mach-exynos/dma.c
> index b10fcd2..e89329e 100644
> --- a/arch/arm/mach-exynos/dma.c
> +++ b/arch/arm/mach-exynos/dma.c
> @@ -139,6 +139,38 @@ struct amba_device exynos4_device_pdma1 = {
> .periphid = 0x00041330,
> };
>
> +u8 mdma_peri[] = {
> + DMACH_MTOM_0,
> + DMACH_MTOM_1,
> + DMACH_MTOM_2,
> + DMACH_MTOM_3,
> + DMACH_MTOM_4,
> + DMACH_MTOM_5,
> + DMACH_MTOM_6,
> + DMACH_MTOM_7,
> +};
> +
> +struct dma_pl330_platdata exynos4_mdma_pdata = {
> + .nr_valid_peri = ARRAY_SIZE(mdma_peri),
> + .peri_id = mdma_peri,
> +};
> +
> +struct amba_device exynos4_device_mdma = {
> + .dev = {
> + .init_name = "dma-pl330.2",
> + .dma_mask = &dma_dmamask,
> + .coherent_dma_mask = DMA_BIT_MASK(32),
> + .platform_data = &exynos4_mdma_pdata,
> + },
> + .res = {
> + .start = EXYNOS4_PA_MDMA1,
> + .end = EXYNOS4_PA_MDMA1 + SZ_4K,
> + .flags = IORESOURCE_MEM,
> + },
> + .irq = {IRQ_MDMA1, NO_IRQ},
> + .periphid = 0x00041330,
> +};
> +
> static int __init exynos4_dma_init(void)
> {
> if (of_have_populated_dt())
> @@ -152,6 +184,9 @@ static int __init exynos4_dma_init(void)
> dma_cap_set(DMA_CYCLIC, exynos4_pdma1_pdata.cap_mask);
> amba_device_register(&exynos4_device_pdma1, &iomem_resource);
>
> + dma_cap_set(DMA_MEMCPY, exynos4_mdma_pdata.cap_mask);
> + amba_device_register(&exynos4_device_mdma, &iomem_resource);
> +
> return 0;
> }
> arch_initcall(exynos4_dma_init);
> diff --git a/arch/arm/mach-exynos/include/mach/irqs.h b/arch/arm/mach-
> exynos/include/mach/irqs.h
> index 713dd52..f7d73b1 100644
> --- a/arch/arm/mach-exynos/include/mach/irqs.h
> +++ b/arch/arm/mach-exynos/include/mach/irqs.h
> @@ -43,6 +43,8 @@
> #define IRQ_EINT15 IRQ_SPI(31)
> #define IRQ_EINT16_31IRQ_SPI(32)
>
> +#define IRQ_MDMA0IRQ_SPI(33)
> +#define IRQ_MDMA1IRQ_SPI(34)
> #define IRQ_PDMA0IRQ_SPI(35)
> #define IRQ_PDMA1IRQ_SPI(36)
> #define IRQ_TIMER0_VIC IRQ_SPI(37)
> diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-
> exynos/include/mach/map.h
> index 058541d..03e2c99 100644
> --- a/arch/arm/mach-exynos/include/mach/map.h
> +++ b/arch/arm/mach-exynos/include/mach/map.h
> @@ -67,7 +67,8 @@
> #define EXYNOS4_PA_TWD 0x10500600
> #define EXYNOS4_PA_L2CC 0x10502000
>
> -#define EXYNOS4_PA_MDMA 0x1081
> +#define EXYNOS4_PA_MDMA0 0x1081
> +#define EXYNOS4_PA_MDMA1 0x1284
> #define EXYNOS4_PA_PDMA0 0x1268
> #define EXYNOS4_PA_PDMA1 0x1269
>
> diff --git a/arch/arm/plat-samsung/include/plat/dma-pl330.h
> b/arch/arm/plat-samsung/include/plat/dma-pl330.h
> index c5eaad5..ecf23a8 100644
> --- a/arch/arm/plat-samsung/include/plat/dma-pl330.h
> +++ b/arch/arm/plat-samsung/include/plat/dma-pl330.h
> @@ -82,6 +82,14 @@ enum dma_ch {
> DMACH_SLIMBUS4_TX,
> DMACH_SLIMBUS5_RX,
> DMACH_SLIMBUS5_TX,
> + DMACH_MTOM_0,
> + DMACH_MTOM_1,
> + DMACH_MTOM_2,
> + DMACH_MTOM_3,
> + DMACH_MTOM_4,
> + DMACH_MTOM_5,
> + DMACH_MTOM_6,
> + DMACH_MTOM_7,
>
RE: [PATCH 3/4] ARM Exynos4210-Nuri: remove compiler errors
MyungJoo Hamm wrote: > What's the 'compiler errors'? And I don't know why this patch included in this series, maybe this should be separated from this series? Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > Signed-off-by: MyungJoo Ham > Signed-off-by: Kyungmin Park > --- > arch/arm/mach-exynos/mach-nuri.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach- > nuri.c > index 236bbe1..4cef1fb 100644 > --- a/arch/arm/mach-exynos/mach-nuri.c > +++ b/arch/arm/mach-exynos/mach-nuri.c > @@ -11,6 +11,8 @@ > #include > #include > #include > +#include > +#include > #include > #include > #include > -- > 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 v7 0/2] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos
On Fri, Dec 02, 2011 at 05:43:21PM +0900, Kukjin Kim wrote: > OK, I will merge iommu/exynos into Samsung tree after your creating that. > > I can't look at iommu/exynos branch in your tree, > git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git. That's because I havn't merged any exynos patches yet :) But I will create it soon an merge this driver. 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: [PATCH 0/3] Moving xusbxti clock setting in clock.c file.
Pankaj Dubey wrote: > > Since there is code duplication in different mach-board.c file it is > better > to set default clock rate of xusbxti clock in plat-s5p/clock.c file. > > The patches are based on following commit on Kukjin's for-next branch. > > Pankaj (1): > ARM: S5P: Set default rate of xusbxti clock > > Pankaj Dubey (2): > ARM: EXYNOS: Removed code for setting clock rate of xusbxti > ARM: S5PV210: Removed code for setting clock rate of xusbxti 'Pankaj' and 'Pankaj Dubey'? > > arch/arm/mach-exynos/mach-nuri.c |1 - > arch/arm/mach-exynos/mach-origen.c |1 - > arch/arm/mach-exynos/mach-smdk4x12.c |2 -- > arch/arm/mach-exynos/mach-smdkv310.c |1 - > arch/arm/mach-s5pv210/mach-goni.c|1 - > arch/arm/plat-s5p/clock.c|1 + > 6 files changed, 1 insertions(+), 6 deletions(-) > > -- > 1.7.4.1 No, the clock can be different for each board even though current value is same. So it should being at the each board file. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] ARM: exynos4: Fix build error due to 'gic_bank_offset' undeclared
Marc Zyngier wrote:
>
> On 01/12/11 15:24, Axel Lin wrote:
> > Fix below build error:
> > CC arch/arm/mach-exynos/cpu.o
> > arch/arm/mach-exynos/cpu.c: In function 'exynos4_init_irq':
> > arch/arm/mach-exynos/cpu.c:245: error: 'gic_bank_offset' undeclared
> (first use in this function)
> > arch/arm/mach-exynos/cpu.c:245: error: (Each undeclared identifier is
> reported only once
> > arch/arm/mach-exynos/cpu.c:245: error: for each function it appears in.)
> > arch/arm/mach-exynos/cpu.c:243: warning: unused variable 'bank_offset'
> > make[1]: *** [arch/arm/mach-exynos/cpu.o] Error 1
> > make: *** [arch/arm/mach-exynos] Error 2
> >
> > Signed-off-by: Axel Lin
>
> Arghhh... My bad. Thanks for fixing that.
>
> Acked-by: Marc Zyngier
>
Hi Marc,
Since the commit 4e44d2cb("ARM: exynos4: convert to CONFIG_MULTI_IRQ_HANDLER")
is not in my tree, this should be handled in your tree and Axel's patch, "ARM:
exynos4: Fix build error" is too.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> > ---
> > arch/arm/mach-exynos/cpu.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
> > index fed62f4..c7cb462 100644
> > --- a/arch/arm/mach-exynos/cpu.c
> > +++ b/arch/arm/mach-exynos/cpu.c
> > @@ -240,7 +240,7 @@ static const struct of_device_id
> exynos4_dt_irq_match[] = {
> > void __init exynos4_init_irq(void)
> > {
> > int irq;
> > - unsigned int bank_offset;
> > + unsigned int gic_bank_offset;
> >
> > gic_bank_offset = soc_is_exynos4412() ? 0x4000 : 0x8000;
> >
>
>
> --
> Jazz is not dead. It just smells funny...
--
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
Joerg Roedel wrote: > > On Thu, Dec 01, 2011 at 04:29:17PM +0900, Kukjin Kim wrote: > > Anyway, that touches many Samsung stuff so it would be better if you > could > > create separate topic branch which can be merged into Samsung tree. And > if > > required, please add my ack on them. > > Yes, I use topic-branches a lot :) This will end up in iommu/exynos or > something like that. > Hi Joerg, OK, I will merge iommu/exynos into Samsung tree after your creating that. I can't look at iommu/exynos branch in your tree, git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
