* HELLO
From: Favour love @ 2011-08-15 12:50 UTC (permalink / raw)
To: linux-sh
hello dear,
How are you? I hope you are fine, my name is miss Favour, I saw your profile today when i was browsing looking for a new friend, that is why i write this mail to you, I will like to know more about you if you don't mind, reply me soon so that i will send you my picture and we be good friends,
Accept my regards,
Hope to hear from you soon,
Favour
^ permalink raw reply
* Re: [RFC 0/4] mmc: tmio, sdhi: provide multiple irq handlers
From: Simon Horman @ 2011-08-15 9:43 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linux-mmc, linux-sh, Chris Ball, Magnus Damm
In-Reply-To: <Pine.LNX.4.64.1108150950330.7851@axis700.grange>
On Mon, Aug 15, 2011 at 10:17:28AM +0200, Guennadi Liakhovetski wrote:
> Hi Simon
>
> On Mon, 15 Aug 2011, Simon Horman wrote:
>
> > The SDHI driver already supports making use of up to three interrupt
> > sources.
> >
> > This series breaks up the existing interrupt handler into three handlers,
> > one for card access, one for card detect interrupts, and one for SDIO
> > interrupts. A cover-all handler, which makes use of these new broken-out
> > handlers is provided for for the case where there is only one interrupt
> > source.
>
> The idea is good, thanks for the patches. Only I'm not sure I find the way
> you split the patches extremely intuitive;-) How about:
>
> [PATCH 1/x] cache IRQ masks
> * in this patch I'd propose to cache SD-card and SDIO IRQ masks in struct
> tmio_mmc_host, instead of reading them every time from the hardware
Sure, that sounds reasonable - though it seems somewhat orthogonal to my series.
I'll check over the code, but it seems that you are implying that
the masks never change.
> [PATCH 2/x] split the ISR
> * in this patch you split the IRQ handler directly into the final form as
> after the first your 3 patches, without intermediate steps, also adding
> them to the header
The current split was intended to make bite-size patches that
are easy to review. I'm happy to combine the patches as you
suggest if that is what you prefer.
> [PATCH 3/x] SDHI: use specialized ISRs when available
> * you know what to do here:-) Also, I'd
> #define SH_MOBILE_SDHI_IRQ_SDCARD 0
> #define SH_MOBILE_SDHI_IRQ_CARD_DETECT 1
> #define SH_MOBILE_SDHI_IRQ_SDIO 2
>
> and use these defines both in platforms
>
> }, [1 + SH_MOBILE_SDHI_IRQ_SDCARD] = {
> ...
I think I see what you are getting at there.
I will try and make it so.
> and in sh_mobile_sdhi.c, instead of going "case 2:" Please, also consider
> unfolding the loop over platform IRQs in probing, it might look better
> flat.
I agree the current loop isn't entirely clean.
I'll unroll it and see how things look.
> "card_access" in function names I would replace with "io" or "data,"
> "card_irq" with "sdcard_irq" because I believe, that "SD card" is a proper
> identification to pure storage card in SD format, as opposed to SDIO
> cards.
Sure, if you would prefer that naming scheme.
> Also, maybe you can double-check, whether you really need all those
> functions with names, beginning with a double underscore, and whether
> better names wouldn't be possible for them.
The motivation behind that aspect of the implementation is
to allow re-use of code while avoiding extra register reads.
I believe the two sdio functions could be collapsed into a single function
while only losing (probably unused) debugging information. I will do that,
though I decided against that option previously for the sake of consistency.
For the card_irq() functions I think it is a bit difficult to collapse things
because the access and detect handlers actually need to read the same
register(s).
^ permalink raw reply
* Re: [RFC 0/4] mmc: tmio, sdhi: provide multiple irq handlers
From: Guennadi Liakhovetski @ 2011-08-15 8:17 UTC (permalink / raw)
To: Simon Horman; +Cc: linux-mmc, linux-sh, Chris Ball, Magnus Damm
In-Reply-To: <1313387488-28175-1-git-send-email-horms@verge.net.au>
Hi Simon
On Mon, 15 Aug 2011, Simon Horman wrote:
> The SDHI driver already supports making use of up to three interrupt
> sources.
>
> This series breaks up the existing interrupt handler into three handlers,
> one for card access, one for card detect interrupts, and one for SDIO
> interrupts. A cover-all handler, which makes use of these new broken-out
> handlers is provided for for the case where there is only one interrupt
> source.
The idea is good, thanks for the patches. Only I'm not sure I find the way
you split the patches extremely intuitive;-) How about:
[PATCH 1/x] cache IRQ masks
* in this patch I'd propose to cache SD-card and SDIO IRQ masks in struct
tmio_mmc_host, instead of reading them every time from the hardware
[PATCH 2/x] split the ISR
* in this patch you split the IRQ handler directly into the final form as
after the first your 3 patches, without intermediate steps, also adding
them to the header
[PATCH 3/x] SDHI: use specialized ISRs when available
* you know what to do here:-) Also, I'd
#define SH_MOBILE_SDHI_IRQ_SDCARD 0
#define SH_MOBILE_SDHI_IRQ_CARD_DETECT 1
#define SH_MOBILE_SDHI_IRQ_SDIO 2
and use these defines both in platforms
}, [1 + SH_MOBILE_SDHI_IRQ_SDCARD] = {
...
and in sh_mobile_sdhi.c, instead of going "case 2:" Please, also consider
unfolding the loop over platform IRQs in probing, it might look better
flat.
"card_access" in function names I would replace with "io" or "data,"
"card_irq" with "sdcard_irq" because I believe, that "SD card" is a proper
identification to pure storage card in SD format, as opposed to SDIO
cards.
Also, maybe you can double-check, whether you really need all those
functions with names, beginning with a double underscore, and whether
better names wouldn't be possible for them.
> This series also wires up the broken-out irq handlers in the SDHI driver
>
> * Card portion tested on AP4/Mackerel
> * SDIO portion yet to be tested. I intend to schedule access to hardware
> to test this if the review of these patches is positive.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH 4/4] mmc: sdhi: Make use of per-source irq handlers
From: Simon Horman @ 2011-08-15 5:51 UTC (permalink / raw)
To: linux-mmc, linux-sh
Cc: Chris Ball, Guennadi Liakhovetski, Magnus Damm, Simon Horman
In-Reply-To: <1313387488-28175-1-git-send-email-horms@verge.net.au>
Make use of per-source irq handles if the
platform (data) has multiple irq sources.
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
drivers/mmc/host/sh_mobile_sdhi.c | 24 ++++++++++++++++++++----
drivers/mmc/host/tmio_mmc_pio.c | 2 +-
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
index 774f643..08c1b3b 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -97,6 +97,7 @@ static int __devinit sh_mobile_sdhi_probe(struct platform_device *pdev)
struct tmio_mmc_host *host;
char clk_name[8];
int i, irq, ret;
+ bool multi_irq = false;
priv = kzalloc(sizeof(struct sh_mobile_sdhi), GFP_KERNEL);
if (priv = NULL) {
@@ -153,7 +154,9 @@ static int __devinit sh_mobile_sdhi_probe(struct platform_device *pdev)
if (ret < 0)
goto eprobe;
- for (i = 0; i < 3; i++) {
+ for (i = 2; i >= 0; i--) {
+ irqreturn_t (*f)(int irq, void *devid);
+
irq = platform_get_irq(pdev, i);
if (irq < 0) {
if (i) {
@@ -163,10 +166,23 @@ static int __devinit sh_mobile_sdhi_probe(struct platform_device *pdev)
goto eirq;
}
}
- ret = request_irq(irq, tmio_mmc_irq, 0,
- dev_name(&pdev->dev), host);
+
+ switch(i) {
+ case 2:
+ multi_irq = true;
+ f = tmio_mmc_sdio_irq;
+ break;
+ case 1:
+ f = tmio_mmc_card_access_irq;
+ break;
+ case 0:
+ f = multi_irq ? tmio_mmc_card_detect_irq : tmio_mmc_irq;
+ break;
+ }
+
+ ret = request_irq(irq, f, 0, dev_name(&pdev->dev), host);
if (ret) {
- while (i--) {
+ while (i++ < 3) {
irq = platform_get_irq(pdev, i);
if (irq >= 0)
free_irq(irq, host);
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 322aa1b..7e01d37 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -613,7 +613,7 @@ irqreturn_t tmio_mmc_card_access_irq(int irq, void *devid)
pr_debug("MMC Card Access IRQ begin\n");
tmio_mmc_card_irq_status(host, &ireg, &irq_mask, &status);
- __tmio_mmc_card_detect_irq(host, ireg, irq_mask, status);
+ __tmio_mmc_card_access_irq(host, ireg, irq_mask, status);
return IRQ_HANDLED;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH 3/4] mmc: tmio, sdhi: Provide separate interrupt hadnlers
From: Simon Horman @ 2011-08-15 5:51 UTC (permalink / raw)
To: linux-mmc, linux-sh
Cc: Chris Ball, Guennadi Liakhovetski, Magnus Damm, Simon Horman
In-Reply-To: <1313387488-28175-1-git-send-email-horms@verge.net.au>
Provide separate interrupt handlers which may be used by platforms where
SDHI has three interrupt sources.
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
drivers/mmc/host/tmio_mmc.h | 3 +++
drivers/mmc/host/tmio_mmc_pio.c | 35 ++++++++++++++++++++++++++++++++++-
2 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index eeaf643..647a24c 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -93,6 +93,9 @@ void tmio_mmc_do_data_irq(struct tmio_mmc_host *host);
void tmio_mmc_enable_mmc_irqs(struct tmio_mmc_host *host, u32 i);
void tmio_mmc_disable_mmc_irqs(struct tmio_mmc_host *host, u32 i);
irqreturn_t tmio_mmc_irq(int irq, void *devid);
+irqreturn_t tmio_mmc_card_access_irq(int irq, void *devid);
+irqreturn_t tmio_mmc_card_detect_irq(int irq, void *devid);
+irqreturn_t tmio_mmc_sdio_irq(int irq, void *devid);
static inline char *tmio_mmc_kmap_atomic(struct scatterlist *sg,
unsigned long *flags)
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 3880750..322aa1b 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -570,6 +570,18 @@ static void __tmio_mmc_card_detect_irq(struct tmio_mmc_host *host,
}
}
+irqreturn_t tmio_mmc_card_detect_irq(int irq, void *devid)
+{
+ unsigned int ireg, irq_mask, status;
+ struct tmio_mmc_host *host = devid;
+
+ pr_debug("MMC Card Detect IRQ begin\n");
+ tmio_mmc_card_irq_status(host, &ireg, &irq_mask, &status);
+ __tmio_mmc_card_detect_irq(host, ireg, irq_mask, status);
+
+ return IRQ_HANDLED;
+}
+
void __tmio_mmc_card_access_irq(struct tmio_mmc_host *host,
int ireg, int irq_mask, int status)
{
@@ -594,12 +606,23 @@ void __tmio_mmc_card_access_irq(struct tmio_mmc_host *host,
}
}
-static void __tmio_mmc_card_irq(struct tmio_mmc_host *host)
+irqreturn_t tmio_mmc_card_access_irq(int irq, void *devid)
{
unsigned int ireg, irq_mask, status;
+ struct tmio_mmc_host *host = devid;
+ pr_debug("MMC Card Access IRQ begin\n");
tmio_mmc_card_irq_status(host, &ireg, &irq_mask, &status);
+ __tmio_mmc_card_detect_irq(host, ireg, irq_mask, status);
+ return IRQ_HANDLED;
+}
+
+static void __tmio_mmc_card_irq(struct tmio_mmc_host *host)
+{
+ unsigned int ireg, irq_mask, status;
+
+ tmio_mmc_card_irq_status(host, &ireg, &irq_mask, &status);
__tmio_mmc_card_detect_irq(host, ireg, irq_mask, status);
__tmio_mmc_card_access_irq(host, ireg, irq_mask, status);
}
@@ -623,6 +646,16 @@ static void __tmio_mmc_sdio_irq(struct tmio_mmc_host *host)
mmc_signal_sdio_irq(mmc);
}
+irqreturn_t tmio_mmc_sdio_irq(int irq, void *devid)
+{
+ struct tmio_mmc_host *host = devid;
+
+ pr_debug("MMC SDIO IRQ begin\n");
+ __tmio_mmc_sdio_irq(host);
+
+ return IRQ_HANDLED;
+}
+
irqreturn_t tmio_mmc_irq(int irq, void *devid)
{
struct tmio_mmc_host *host = devid;
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/4] mmc: tmio, sdhi: Split card interrupts based on source
From: Simon Horman @ 2011-08-15 5:51 UTC (permalink / raw)
To: linux-mmc, linux-sh
Cc: Chris Ball, Guennadi Liakhovetski, Magnus Damm, Simon Horman
In-Reply-To: <1313387488-28175-1-git-send-email-horms@verge.net.au>
SDHI hardware allows for two different card interrupt sources;
one for access and one for detect.
As preparation for wiring the sources up to separate interrupt handlers
this patch splits the card interrupt handler in two.
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
drivers/mmc/host/tmio_mmc_pio.c | 34 ++++++++++++++++++++++++++--------
1 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index e658cb4..3880750 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -543,17 +543,21 @@ out:
spin_unlock(&host->lock);
}
-static void __tmio_mmc_card_irq(struct tmio_mmc_host *host)
+static void tmio_mmc_card_irq_status(struct tmio_mmc_host *host,
+ int *ireg, int *irq_mask, int *status)
{
- struct mmc_host *mmc = host->mmc;
- unsigned int ireg, irq_mask, status;
+ *status = sd_ctrl_read32(host, CTL_STATUS);
+ *irq_mask = sd_ctrl_read32(host, CTL_IRQ_MASK);
+ *ireg = *status & TMIO_MASK_IRQ & ~*irq_mask;
- status = sd_ctrl_read32(host, CTL_STATUS);
- irq_mask = sd_ctrl_read32(host, CTL_IRQ_MASK);
- ireg = status & TMIO_MASK_IRQ & ~irq_mask;
+ pr_debug_status(*status);
+ pr_debug_status(*ireg);
+}
- pr_debug_status(status);
- pr_debug_status(ireg);
+static void __tmio_mmc_card_detect_irq(struct tmio_mmc_host *host,
+ int ireg, int irq_mask, int status)
+{
+ struct mmc_host *mmc = host->mmc;
/* Card insert / remove attempts */
if (ireg & (TMIO_STAT_CARD_INSERT | TMIO_STAT_CARD_REMOVE)) {
@@ -564,7 +568,11 @@ static void __tmio_mmc_card_irq(struct tmio_mmc_host *host)
!work_pending(&mmc->detect.work))
mmc_detect_change(host->mmc, msecs_to_jiffies(100));
}
+}
+void __tmio_mmc_card_access_irq(struct tmio_mmc_host *host,
+ int ireg, int irq_mask, int status)
+{
/* Command completion */
if (ireg & (TMIO_STAT_CMDRESPEND | TMIO_STAT_CMDTIMEOUT)) {
tmio_mmc_ack_mmc_irqs(host,
@@ -586,6 +594,16 @@ static void __tmio_mmc_card_irq(struct tmio_mmc_host *host)
}
}
+static void __tmio_mmc_card_irq(struct tmio_mmc_host *host)
+{
+ unsigned int ireg, irq_mask, status;
+
+ tmio_mmc_card_irq_status(host, &ireg, &irq_mask, &status);
+
+ __tmio_mmc_card_detect_irq(host, ireg, irq_mask, status);
+ __tmio_mmc_card_access_irq(host, ireg, irq_mask, status);
+}
+
static void __tmio_mmc_sdio_irq(struct tmio_mmc_host *host)
{
struct mmc_host *mmc = host->mmc;
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/4] mmc: tmio, sdhi: Split tmio_mmc_irq() based on registers
From: Simon Horman @ 2011-08-15 5:51 UTC (permalink / raw)
To: linux-mmc, linux-sh
Cc: Chris Ball, Guennadi Liakhovetski, Magnus Damm, Simon Horman
In-Reply-To: <1313387488-28175-1-git-send-email-horms@verge.net.au>
This splits tmio_mmc_irq() in two based on the registers
used to handle the interrupts.
This involves two key changes to the logic:
1. Do not assume that only one interrupt has occurred.
In particular because tmio_mmc_irq() handles interrupts
from three sources. Also, because this allows
the logic to be simplified.
2. Just ignore spurious interrupts.
Its not clear to me that they can ever occur.
This patch also removes the commented-out handling of
CRC and other errors.
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
drivers/mmc/host/tmio_mmc_pio.c | 71 +++++++++++++++-----------------------
1 files changed, 28 insertions(+), 43 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 1f16357..e658cb4 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -543,43 +543,15 @@ out:
spin_unlock(&host->lock);
}
-irqreturn_t tmio_mmc_irq(int irq, void *devid)
+static void __tmio_mmc_card_irq(struct tmio_mmc_host *host)
{
- struct tmio_mmc_host *host = devid;
struct mmc_host *mmc = host->mmc;
- struct tmio_mmc_data *pdata = host->pdata;
unsigned int ireg, irq_mask, status;
- unsigned int sdio_ireg, sdio_irq_mask, sdio_status;
-
- pr_debug("MMC IRQ begin\n");
status = sd_ctrl_read32(host, CTL_STATUS);
irq_mask = sd_ctrl_read32(host, CTL_IRQ_MASK);
ireg = status & TMIO_MASK_IRQ & ~irq_mask;
- sdio_ireg = 0;
- if (!ireg && pdata->flags & TMIO_MMC_SDIO_IRQ) {
- sdio_status = sd_ctrl_read16(host, CTL_SDIO_STATUS);
- sdio_irq_mask = sd_ctrl_read16(host, CTL_SDIO_IRQ_MASK);
- sdio_ireg = sdio_status & TMIO_SDIO_MASK_ALL & ~sdio_irq_mask;
-
- sd_ctrl_write16(host, CTL_SDIO_STATUS, sdio_status & ~TMIO_SDIO_MASK_ALL);
-
- if (sdio_ireg && !host->sdio_irq_enabled) {
- pr_warning("tmio_mmc: Spurious SDIO IRQ, disabling! 0x%04x 0x%04x 0x%04x\n",
- sdio_status, sdio_irq_mask, sdio_ireg);
- tmio_mmc_enable_sdio_irq(mmc, 0);
- goto out;
- }
-
- if (mmc->caps & MMC_CAP_SDIO_IRQ &&
- sdio_ireg & TMIO_SDIO_STAT_IOIRQ)
- mmc_signal_sdio_irq(mmc);
-
- if (sdio_ireg)
- goto out;
- }
-
pr_debug_status(status);
pr_debug_status(ireg);
@@ -591,43 +563,56 @@ irqreturn_t tmio_mmc_irq(int irq, void *devid)
((ireg & TMIO_STAT_CARD_INSERT) && !mmc->card)) &&
!work_pending(&mmc->detect.work))
mmc_detect_change(host->mmc, msecs_to_jiffies(100));
- goto out;
}
- /* CRC and other errors */
-/* if (ireg & TMIO_STAT_ERR_IRQ)
- * handled |= tmio_error_irq(host, irq, stat);
- */
-
/* Command completion */
if (ireg & (TMIO_STAT_CMDRESPEND | TMIO_STAT_CMDTIMEOUT)) {
tmio_mmc_ack_mmc_irqs(host,
TMIO_STAT_CMDRESPEND |
TMIO_STAT_CMDTIMEOUT);
tmio_mmc_cmd_irq(host, status);
- goto out;
}
/* Data transfer */
if (ireg & (TMIO_STAT_RXRDY | TMIO_STAT_TXRQ)) {
tmio_mmc_ack_mmc_irqs(host, TMIO_STAT_RXRDY | TMIO_STAT_TXRQ);
tmio_mmc_pio_irq(host);
- goto out;
}
/* Data transfer completion */
if (ireg & TMIO_STAT_DATAEND) {
tmio_mmc_ack_mmc_irqs(host, TMIO_STAT_DATAEND);
tmio_mmc_data_irq(host);
- goto out;
}
+}
- pr_warning("tmio_mmc: Spurious irq, disabling! "
- "0x%08x 0x%08x 0x%08x\n", status, irq_mask, ireg);
- pr_debug_status(status);
- tmio_mmc_disable_mmc_irqs(host, status & ~irq_mask);
+static void __tmio_mmc_sdio_irq(struct tmio_mmc_host *host)
+{
+ struct mmc_host *mmc = host->mmc;
+ struct tmio_mmc_data *pdata = host->pdata;
+ unsigned int ireg, irq_mask, status;
+
+ if (!(pdata->flags & TMIO_MMC_SDIO_IRQ))
+ return;
+
+ status = sd_ctrl_read16(host, CTL_SDIO_STATUS);
+ irq_mask = sd_ctrl_read16(host, CTL_SDIO_IRQ_MASK);
+ ireg = status & TMIO_SDIO_MASK_ALL & ~irq_mask;
+
+ sd_ctrl_write16(host, CTL_SDIO_STATUS, status & ~TMIO_SDIO_MASK_ALL);
+
+ if (mmc->caps & MMC_CAP_SDIO_IRQ && ireg & TMIO_SDIO_STAT_IOIRQ)
+ mmc_signal_sdio_irq(mmc);
+}
+
+irqreturn_t tmio_mmc_irq(int irq, void *devid)
+{
+ struct tmio_mmc_host *host = devid;
+
+ pr_debug("MMC IRQ begin\n");
+ __tmio_mmc_card_irq(host);
+ __tmio_mmc_sdio_irq(host);
-out:
return IRQ_HANDLED;
}
EXPORT_SYMBOL(tmio_mmc_irq);
--
1.7.5.4
^ permalink raw reply related
* [RFC 0/4] mmc: tmio, sdhi: provide multiple irq handlers
From: Simon Horman @ 2011-08-15 5:51 UTC (permalink / raw)
To: linux-mmc, linux-sh
Cc: Chris Ball, Guennadi Liakhovetski, Magnus Damm, Simon Horman
The SDHI driver already supports making use of up to three interrupt
sources.
This series breaks up the existing interrupt handler into three handlers,
one for card access, one for card detect interrupts, and one for SDIO
interrupts. A cover-all handler, which makes use of these new broken-out
handlers is provided for for the case where there is only one interrupt
source.
This series also wires up the broken-out irq handlers in the SDHI driver
* Card portion tested on AP4/Mackerel
* SDIO portion yet to be tested. I intend to schedule access to hardware
to test this if the review of these patches is positive.
^ permalink raw reply
* [Update x2][PATCH 9/9] ARM / shmobile: Make A3RV be a subdomain of A4LC on SH7372
From: Rafael J. Wysocki @ 2011-08-14 14:07 UTC (permalink / raw)
To: Linux PM mailing list; +Cc: LKML, Magnus Damm, linux-sh
In-Reply-To: <201108132143.47649.rjw@sisk.pl>
From: Rafael J. Wysocki <rjw@sisk.pl>
Subject: ARM / shmobile: Make A3RV be a subdomain of A4LC on SH7372
Instead of coding the undocumented dependencies between power domains
A3RV and A4LC on SH7372 directly into the low-level power up/down
routines, make A3RV be a subdomain of A4LC, which will cause the
same dependecies to hold.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
It also needs to build for CONFIG_PM unset.
Thanks,
Rafael
---
arch/arm/mach-shmobile/include/mach/sh7372.h | 3 +
arch/arm/mach-shmobile/pm-sh7372.c | 48 ++++-----------------------
arch/arm/mach-shmobile/setup-sh7372.c | 3 +
3 files changed, 14 insertions(+), 40 deletions(-)
Index: linux/arch/arm/mach-shmobile/pm-sh7372.c
=================================--- linux.orig/arch/arm/mach-shmobile/pm-sh7372.c
+++ linux/arch/arm/mach-shmobile/pm-sh7372.c
@@ -91,35 +91,6 @@ static int pd_power_up(struct generic_pm
return ret;
}
-static int pd_power_up_a3rv(struct generic_pm_domain *genpd)
-{
- int ret = pd_power_up(genpd);
-
- /* force A4LC on after A3RV has been requested on */
- pm_genpd_poweron(&sh7372_a4lc.genpd);
-
- return ret;
-}
-
-static int pd_power_down_a3rv(struct generic_pm_domain *genpd)
-{
- int ret = pd_power_down(genpd);
-
- /* try to power down A4LC after A3RV is requested off */
- genpd_queue_power_off_work(&sh7372_a4lc.genpd);
-
- return ret;
-}
-
-static int pd_power_down_a4lc(struct generic_pm_domain *genpd)
-{
- /* only power down A4LC if A3RV is off */
- if (!(__raw_readl(PSTR) & (1 << sh7372_a3rv.bit_shift)))
- return pd_power_down(genpd);
-
- return -EBUSY;
-}
-
static bool pd_active_wakeup(struct device *dev)
{
return true;
@@ -133,17 +104,8 @@ void sh7372_init_pm_domain(struct sh7372
genpd->stop_device = pm_clk_suspend;
genpd->start_device = pm_clk_resume;
genpd->active_wakeup = pd_active_wakeup;
-
- if (sh7372_pd = &sh7372_a4lc) {
- genpd->power_off = pd_power_down_a4lc;
- genpd->power_on = pd_power_up;
- } else if (sh7372_pd = &sh7372_a3rv) {
- genpd->power_off = pd_power_down_a3rv;
- genpd->power_on = pd_power_up_a3rv;
- } else {
- genpd->power_off = pd_power_down;
- genpd->power_on = pd_power_up;
- }
+ genpd->power_off = pd_power_down;
+ genpd->power_on = pd_power_up;
genpd->power_on(&sh7372_pd->genpd);
}
@@ -159,6 +121,12 @@ void sh7372_add_device_to_domain(struct
pm_genpd_add_device(&sh7372_pd->genpd, dev);
}
+void sh7372_pm_add_subdomain(struct sh7372_pm_domain *sh7372_pd,
+ struct sh7372_pm_domain *sh7372_sd)
+{
+ pm_genpd_add_subdomain(&sh7372_pd->genpd, &sh7372_sd->genpd);
+}
+
struct sh7372_pm_domain sh7372_a4lc = {
.bit_shift = 1,
};
Index: linux/arch/arm/mach-shmobile/setup-sh7372.c
=================================--- linux.orig/arch/arm/mach-shmobile/setup-sh7372.c
+++ linux/arch/arm/mach-shmobile/setup-sh7372.c
@@ -30,6 +30,7 @@
#include <linux/sh_dma.h>
#include <linux/sh_intc.h>
#include <linux/sh_timer.h>
+#include <linux/pm_domain.h>
#include <mach/hardware.h>
#include <mach/sh7372.h>
#include <asm/mach-types.h>
@@ -848,6 +849,8 @@ void __init sh7372_add_standard_devices(
sh7372_init_pm_domain(&sh7372_a3ri);
sh7372_init_pm_domain(&sh7372_a3sg);
+ sh7372_pm_add_subdomain(&sh7372_a4lc, &sh7372_a3rv);
+
platform_add_devices(sh7372_early_devices,
ARRAY_SIZE(sh7372_early_devices));
Index: linux/arch/arm/mach-shmobile/include/mach/sh7372.h
=================================--- linux.orig/arch/arm/mach-shmobile/include/mach/sh7372.h
+++ linux/arch/arm/mach-shmobile/include/mach/sh7372.h
@@ -494,9 +494,12 @@ extern struct sh7372_pm_domain sh7372_a3
extern void sh7372_init_pm_domain(struct sh7372_pm_domain *sh7372_pd);
extern void sh7372_add_device_to_domain(struct sh7372_pm_domain *sh7372_pd,
struct platform_device *pdev);
+extern void sh7372_pm_add_subdomain(struct sh7372_pm_domain *sh7372_pd,
+ struct sh7372_pm_domain *sh7372_sd);
#else
#define sh7372_init_pm_domain(pd) do { } while(0)
#define sh7372_add_device_to_domain(pd, pdev) do { } while(0)
+#define sh7372_pm_add_subdomain(pd, sd) do { } while(0)
#endif /* CONFIG_PM */
#endif /* __ASM_SH7372_H__ */
^ permalink raw reply
* [PATCH] PM / Domains: Fix build for CONFIG_PM_RUNTIME unset
From: Rafael J. Wysocki @ 2011-08-14 14:04 UTC (permalink / raw)
To: Linux PM mailing list; +Cc: LKML, linux-sh
From: Rafael J. Wysocki <rjw@sisk.pl>
Function genpd_queue_power_off_work() is not defined for
CONFIG_PM_RUNTIME, so pm_genpd_poweroff_unused() causes a build
error to happen in that case. Fix the problem by making
pm_genpd_poweroff_unused() depend on CONFIG_PM_RUNTIME too.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
This is 3.1 material if no one objects.
Thanks,
Rafael
---
drivers/base/power/domain.c | 30 +++++++++++++++---------------
include/linux/pm_domain.h | 10 +++++++---
kernel/power/Kconfig | 4 ++++
3 files changed, 26 insertions(+), 18 deletions(-)
Index: linux/include/linux/pm_domain.h
=================================--- linux.orig/include/linux/pm_domain.h
+++ linux/include/linux/pm_domain.h
@@ -72,8 +72,6 @@ extern int pm_genpd_remove_subdomain(str
extern void pm_genpd_init(struct generic_pm_domain *genpd,
struct dev_power_governor *gov, bool is_off);
extern int pm_genpd_poweron(struct generic_pm_domain *genpd);
-extern void pm_genpd_poweroff_unused(void);
-extern void genpd_queue_power_off_work(struct generic_pm_domain *genpd);
#else
static inline int pm_genpd_add_device(struct generic_pm_domain *genpd,
struct device *dev)
@@ -101,8 +99,14 @@ static inline int pm_genpd_poweron(struc
{
return -ENOSYS;
}
-static inline void pm_genpd_poweroff_unused(void) {}
+#endif
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS_RUNTIME
+extern void genpd_queue_power_off_work(struct generic_pm_domain *genpd);
+extern void pm_genpd_poweroff_unused(void);
+#else
static inline void genpd_queue_power_off_work(struct generic_pm_domain *gpd) {}
+static inline void pm_genpd_poweroff_unused(void) {}
#endif
#endif /* _LINUX_PM_DOMAIN_H */
Index: linux/drivers/base/power/domain.c
=================================--- linux.orig/drivers/base/power/domain.c
+++ linux/drivers/base/power/domain.c
@@ -460,6 +460,21 @@ static int pm_genpd_runtime_resume(struc
return 0;
}
+/**
+ * pm_genpd_poweroff_unused - Power off all PM domains with no devices in use.
+ */
+void pm_genpd_poweroff_unused(void)
+{
+ struct generic_pm_domain *genpd;
+
+ mutex_lock(&gpd_list_lock);
+
+ list_for_each_entry(genpd, &gpd_list, gpd_list_node)
+ genpd_queue_power_off_work(genpd);
+
+ mutex_unlock(&gpd_list_lock);
+}
+
#else
static inline void genpd_power_off_work_fn(struct work_struct *work) {}
@@ -1255,18 +1270,3 @@ void pm_genpd_init(struct generic_pm_dom
list_add(&genpd->gpd_list_node, &gpd_list);
mutex_unlock(&gpd_list_lock);
}
-
-/**
- * pm_genpd_poweroff_unused - Power off all PM domains with no devices in use.
- */
-void pm_genpd_poweroff_unused(void)
-{
- struct generic_pm_domain *genpd;
-
- mutex_lock(&gpd_list_lock);
-
- list_for_each_entry(genpd, &gpd_list, gpd_list_node)
- genpd_queue_power_off_work(genpd);
-
- mutex_unlock(&gpd_list_lock);
-}
Index: linux/kernel/power/Kconfig
=================================--- linux.orig/kernel/power/Kconfig
+++ linux/kernel/power/Kconfig
@@ -231,3 +231,7 @@ config PM_CLK
config PM_GENERIC_DOMAINS
bool
depends on PM
+
+config PM_GENERIC_DOMAINS_RUNTIME
+ def_bool y
+ depends on PM_RUNTIME && PM_GENERIC_DOMAINS
^ permalink raw reply
* Re: [PATCH] shmobile/sh7372: Add missing CONFIG_PM guards to fix build failure
From: Rafael J. Wysocki @ 2011-08-13 23:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1313274841-8322-1-git-send-email-peterhuewe@gmx.de>
On Sunday, August 14, 2011, Peter Huewe wrote:
> This patch fixes a build failure with the ap4evb_defconfig by adding the
> missing #ifdef CONFIG_PM.
This is not the right fix. Besides, you seem to be testing linux-next
and the build problem is in the linux-pm tree.
Please check if the appended patch fixes the problem for you.
Rafael
---
arch/arm/mach-shmobile/include/mach/sh7372.h | 3 +++
arch/arm/mach-shmobile/pm-sh7372.c | 6 ++++++
arch/arm/mach-shmobile/setup-sh7372.c | 2 +-
3 files changed, 10 insertions(+), 1 deletion(-)
Index: linux/arch/arm/mach-shmobile/include/mach/sh7372.h
=================================--- linux.orig/arch/arm/mach-shmobile/include/mach/sh7372.h
+++ linux/arch/arm/mach-shmobile/include/mach/sh7372.h
@@ -494,9 +494,12 @@ extern struct sh7372_pm_domain sh7372_a3
extern void sh7372_init_pm_domain(struct sh7372_pm_domain *sh7372_pd);
extern void sh7372_add_device_to_domain(struct sh7372_pm_domain *sh7372_pd,
struct platform_device *pdev);
+extern void sh7372_pm_add_subdomain(struct sh7372_pm_domain *sh7372_pd,
+ struct sh7372_pm_domain *sh7372_sd);
#else
#define sh7372_init_pm_domain(pd) do { } while(0)
#define sh7372_add_device_to_domain(pd, pdev) do { } while(0)
+#define sh7372_pm_add_subdomain(pd, sd) do { } while(0)
#endif /* CONFIG_PM */
#endif /* __ASM_SH7372_H__ */
Index: linux/arch/arm/mach-shmobile/setup-sh7372.c
=================================--- linux.orig/arch/arm/mach-shmobile/setup-sh7372.c
+++ linux/arch/arm/mach-shmobile/setup-sh7372.c
@@ -849,7 +849,7 @@ void __init sh7372_add_standard_devices(
sh7372_init_pm_domain(&sh7372_a3ri);
sh7372_init_pm_domain(&sh7372_a3sg);
- pm_genpd_add_subdomain(&sh7372_a4lc.genpd, &sh7372_a3rv.genpd);
+ sh7372_pm_add_subdomain(&sh7372_a4lc, &sh7372_a3rv);
platform_add_devices(sh7372_early_devices,
ARRAY_SIZE(sh7372_early_devices));
Index: linux/arch/arm/mach-shmobile/pm-sh7372.c
=================================--- linux.orig/arch/arm/mach-shmobile/pm-sh7372.c
+++ linux/arch/arm/mach-shmobile/pm-sh7372.c
@@ -119,6 +119,12 @@ void sh7372_add_device_to_domain(struct
pm_clk_add(dev, NULL);
}
+void sh7372_pm_add_subdomain(struct sh7372_pm_domain *sh7372_pd,
+ struct sh7372_pm_domain *sh7372_sd)
+{
+ pm_genpd_add_subdomain(&sh7372_pd->genpd, &sh7372_sd->genpd);
+}
+
struct sh7372_pm_domain sh7372_a4lc = {
.bit_shift = 1,
};
^ permalink raw reply
* [PATCH] shmobile/sh7372: Add missing CONFIG_PM guards to fix build failure
From: Peter Huewe @ 2011-08-13 22:34 UTC (permalink / raw)
To: linux-arm-kernel
This patch fixes a build failure with the ap4evb_defconfig by adding the
missing #ifdef CONFIG_PM.
The build failure was:
arch/arm/mach-shmobile/setup-sh7372.c:852: error: 'sh7372_a4lc'
undeclared (first use in this function)
arch/arm/mach-shmobile/setup-sh7372.c:852: error: (Each undeclared
identifier is reported only once
arch/arm/mach-shmobile/setup-sh7372.c:852: error: for each function it
appears in.)
sh7372_a4lc is declared in arch/arm/mach-shmobile/pm-sh7372.c within a
#ifdef CONFIG_PM block. Since the defconfig is missing CONFIG_PM this
results in a build failure.
KernelVersion: linux-next 20110812 (cab7d82)
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
---
arch/arm/mach-shmobile/setup-sh7372.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-shmobile/setup-sh7372.c b/arch/arm/mach-shmobile/setup-sh7372.c
index df900bf..8455f0b 100644
--- a/arch/arm/mach-shmobile/setup-sh7372.c
+++ b/arch/arm/mach-shmobile/setup-sh7372.c
@@ -848,9 +848,9 @@ void __init sh7372_add_standard_devices(void)
sh7372_init_pm_domain(&sh7372_a3rv);
sh7372_init_pm_domain(&sh7372_a3ri);
sh7372_init_pm_domain(&sh7372_a3sg);
-
+#ifdef CONFIG_PM
pm_genpd_add_subdomain(&sh7372_a4lc.genpd, &sh7372_a3sg.genpd);
-
+#endif
platform_add_devices(sh7372_early_devices,
ARRAY_SIZE(sh7372_early_devices));
--
1.7.3.4
^ permalink raw reply related
* [Update][PATCH 9/9] ARM / shmobile: Make A3RV be a subdomain of A4LC on SH7372
From: Rafael J. Wysocki @ 2011-08-13 19:43 UTC (permalink / raw)
To: Linux PM mailing list; +Cc: LKML, Magnus Damm, linux-sh
In-Reply-To: <201107311952.51969.rjw@sisk.pl>
From: Rafael J. Wysocki <rjw@sisk.pl>
Instead of coding the undocumented dependencies between power domains
A3RV and A4LC on SH7372 directly into the low-level power up/down
routines, make A3RV be a subdomain of A4LC, which will cause the
same dependecies to hold.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
Well, the patch should actually do what's advertised in the changelog
(ie. make A3RV, _not_ A3SG, a subdomain of A4LC).
---
arch/arm/mach-shmobile/pm-sh7372.c | 42 +---------------------------------
arch/arm/mach-shmobile/setup-sh7372.c | 3 ++
2 files changed, 5 insertions(+), 40 deletions(-)
Index: linux/arch/arm/mach-shmobile/pm-sh7372.c
=================================--- linux.orig/arch/arm/mach-shmobile/pm-sh7372.c
+++ linux/arch/arm/mach-shmobile/pm-sh7372.c
@@ -91,35 +91,6 @@ static int pd_power_up(struct generic_pm
return ret;
}
-static int pd_power_up_a3rv(struct generic_pm_domain *genpd)
-{
- int ret = pd_power_up(genpd);
-
- /* force A4LC on after A3RV has been requested on */
- pm_genpd_poweron(&sh7372_a4lc.genpd);
-
- return ret;
-}
-
-static int pd_power_down_a3rv(struct generic_pm_domain *genpd)
-{
- int ret = pd_power_down(genpd);
-
- /* try to power down A4LC after A3RV is requested off */
- genpd_queue_power_off_work(&sh7372_a4lc.genpd);
-
- return ret;
-}
-
-static int pd_power_down_a4lc(struct generic_pm_domain *genpd)
-{
- /* only power down A4LC if A3RV is off */
- if (!(__raw_readl(PSTR) & (1 << sh7372_a3rv.bit_shift)))
- return pd_power_down(genpd);
-
- return -EBUSY;
-}
-
static bool pd_active_wakeup(struct device *dev)
{
return true;
@@ -133,17 +104,8 @@ void sh7372_init_pm_domain(struct sh7372
genpd->stop_device = pm_clk_suspend;
genpd->start_device = pm_clk_resume;
genpd->active_wakeup = pd_active_wakeup;
-
- if (sh7372_pd = &sh7372_a4lc) {
- genpd->power_off = pd_power_down_a4lc;
- genpd->power_on = pd_power_up;
- } else if (sh7372_pd = &sh7372_a3rv) {
- genpd->power_off = pd_power_down_a3rv;
- genpd->power_on = pd_power_up_a3rv;
- } else {
- genpd->power_off = pd_power_down;
- genpd->power_on = pd_power_up;
- }
+ genpd->power_off = pd_power_down;
+ genpd->power_on = pd_power_up;
genpd->power_on(&sh7372_pd->genpd);
}
Index: linux/arch/arm/mach-shmobile/setup-sh7372.c
=================================--- linux.orig/arch/arm/mach-shmobile/setup-sh7372.c
+++ linux/arch/arm/mach-shmobile/setup-sh7372.c
@@ -30,6 +30,7 @@
#include <linux/sh_dma.h>
#include <linux/sh_intc.h>
#include <linux/sh_timer.h>
+#include <linux/pm_domain.h>
#include <mach/hardware.h>
#include <mach/sh7372.h>
#include <asm/mach-types.h>
@@ -848,6 +849,8 @@ void __init sh7372_add_standard_devices(
sh7372_init_pm_domain(&sh7372_a3ri);
sh7372_init_pm_domain(&sh7372_a3sg);
+ pm_genpd_add_subdomain(&sh7372_a4lc.genpd, &sh7372_a3rv.genpd);
+
platform_add_devices(sh7372_early_devices,
ARRAY_SIZE(sh7372_early_devices));
^ permalink raw reply
* HELLO my 你好，我
From: Rose @ 2011-08-12 18:28 UTC (permalink / raw)
To: linux-sh
HELLO
My name is Rose,i and became intrested in you, i will also like to know you more,and i want you to send an email to my email address so i can give you my picture for you to know whom i am. Here is my email address(william_rose55@yahoo.com)I believe we can move from here!
I am waiting for your mail to my email address above..
(Remeber the distance or colour does not matter but love matters alot in life)
Thanks Rose please contact me now through my email address
(william_rose55@yahoo.com)
^ permalink raw reply
* Re: LCDC problem after commit 794d78fea51504bad3880d14f354a9847f318f25
From: Laurent Pinchart @ 2011-08-12 9:59 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <201108080125.34329.rjw@sisk.pl>
Hi Rafael,
On Thursday 11 August 2011 21:37:04 Rafael J. Wysocki wrote:
> On Thursday, August 11, 2011, Laurent Pinchart wrote:
> > On Tuesday 09 August 2011 12:48:44 Magnus Damm wrote:
> > > On Mon, Aug 8, 2011 at 10:46 AM, Magnus Damm wrote:
> > > > On Mon, Aug 8, 2011 at 8:25 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > > >> Unfortunately, after commit 794d78fea51504bad3880d14f354a9847f318f25
> > > >> (drivers: sh: late disabling of clocks V2) the LCDC screen on my
> > > >> Mackerel board goes off (late) during boot and cannot be turned on
> > > >> by any way AFAICS (the backlight remains on, though).
> > > >>
> > > >> It looks like the late disabling of clocks interacts badly with the
> > > >> clock management done by PM domains.
> > > >
> > > > This is most likely showing a so-far-not-handled clock dependency for
> > > > the LCDC hardware. I'll have a look.
> > >
> > > Further investigation shows that this only triggers when the MERAM is
> > > enabled in the kernel configuration using CONFIG_FB_SH_MOBILE_MERAM=y.
> > > So this seems more related to MERAM power management than LCDC.
> > >
> > > Digging a bit deeper makes it clear that the sh_mobile_meram.c driver
> > > in upstream doesn't seem to include any Runtime PM code. I recall
> > > seeing various versions posted to the mailing list.
> > >
> > > Laurent [CC], can you please provide us with a list of outstanding
> > > LCDC/MERAM patches to make this work as expected? I realize there are
> > > quite a few outstanding LCDC patches, but if possible please provide a
> > > list of the bare minimum to make this work with 3.1-rc.
> >
> > I've pushed my pending patches to
> > http://git.linuxtv.org/pinchartl/fbdev.git in the pm-domains branch. The
> > first 19 patches have been picked from mailing lists. Hopefully they're
> > the latest versions that have been posted. The next 11 patches shouldn't
> > be required to enable runtime PM with the MERAM, but they provide code
> > cleanup and bug fixes.
> >
> > Are Rafael' and Damian's patches ready for mainline ? If so, when will
> > they be pulled ? They're more than one month old, I was expecting them
> > to hit v3.1- rc1. The backlog is growing, which makes collaboration more
> > difficult.
>
> Which of my patches are you referring to in particular?
My bad, your patches are in v3.1-rc1. I had rebased my branch on top of the
wrong tag. We still need to push Damian's MERAM runtime PM patches, as well as
mine.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 11/13] ARM: gpio: consolidate trivial gpiolib
From: Shawn Guo @ 2011-08-12 5:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1QqhM1-0003af-U5@rmk-PC.arm.linux.org.uk>
On Tue, Aug 09, 2011 at 09:08:01AM +0100, Russell King - ARM Linux wrote:
> Consolidate 24 trivial gpiolib implementions out of mach/gpio.h
> into asm/gpio.h. This is basically the include of asm-generic/gpio.h
> and the definition of gpio_get_value, gpio_set_value, and gpio_cansleep
> as described in Documentation/gpio.txt
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> arch/arm/include/asm/gpio.h | 10 ++++++++++
> arch/arm/mach-at91/include/mach/gpio.h | 5 +----
> arch/arm/mach-ep93xx/include/mach/gpio.h | 7 +------
> arch/arm/mach-exynos4/include/mach/gpio.h | 5 +----
> arch/arm/mach-gemini/include/mach/gpio.h | 5 +----
> arch/arm/mach-ks8695/include/mach/gpio.h | 11 ++---------
> arch/arm/mach-lpc32xx/include/mach/gpio.h | 17 +----------------
> arch/arm/mach-msm/include/mach/gpio.h | 5 +----
> arch/arm/mach-mxs/include/mach/gpio.h | 6 +-----
> arch/arm/mach-realview/include/mach/gpio.h | 6 +-----
> arch/arm/mach-s3c2410/include/mach/gpio.h | 5 +----
> arch/arm/mach-s3c64xx/include/mach/gpio.h | 6 +-----
> arch/arm/mach-s5p64x0/include/mach/gpio.h | 6 +-----
> arch/arm/mach-s5pc100/include/mach/gpio.h | 6 +-----
> arch/arm/mach-s5pv210/include/mach/gpio.h | 6 +-----
> arch/arm/mach-shmobile/include/mach/gpio.h | 15 +--------------
> arch/arm/mach-tegra/include/mach/gpio.h | 6 +-----
> arch/arm/mach-versatile/include/mach/gpio.h | 6 +-----
> arch/arm/mach-vt8500/include/mach/gpio.h | 6 +-----
> arch/arm/mach-w90x900/include/mach/gpio.h | 5 +----
> arch/arm/plat-mxc/include/mach/gpio.h | 5 +----
> arch/arm/plat-nomadik/include/plat/gpio.h | 11 +----------
> arch/arm/plat-omap/include/plat/gpio.h | 15 +--------------
> arch/arm/plat-orion/include/plat/gpio.h | 6 ++----
> arch/arm/plat-spear/include/plat/gpio.h | 6 +-----
> 25 files changed, 36 insertions(+), 151 deletions(-)
>
For mxs and mxc:
Tested-by: Shawn Guo <shawn.guo@linaro.org>
--
Regards,
Shawn
^ permalink raw reply
* Re: Renesas EMEV2 Kernel sources
From: Magnus Damm @ 2011-08-12 4:50 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4E12D338.1090508@spesonline.com>
Hi Serg,
On Thu, Aug 11, 2011 at 9:24 PM, Serg <goodnk@gmail.com> wrote:
>
> Magnus Damm <magnus.damm <at> gmail.com> writes:
>
>>
>> Hi Luca,
>>
>> On Tue, Jul 5, 2011 at 6:02 PM, Luca Santini
>> <luca.santini <at> spesonline.com> wrote:
>> > Hi All,
>> > anybody knows where to find NEC EMMA EV/2 (mach-emxx) Kernel Sources / if
>> > these are public domain ?
>>
>> Thanks for your email. So I asked around a bit about the NEC EMMA line
>> and I got to know that you should be able to request sources from the
>> same place as you got the development board.
>>
>> For instance, if you have a board from Kyoto Microcomputer then you
>> should request sources from them. If you happen to have a NEC EMMA
>> EV/2 board that has been distributed by Renesas Electronics then
>> please request sources via your regular business channels.
>>
>> If you still can't get sources for your board then please let me know
>> more details (board make, name and kernel version) and I'll do my best
>> to find more information.
>>
>> Hope this helps!
>>
>
>
> Hi.
>
> I happen to have a NEC EV2 powered android tablet. From whom should I request
> the sources?
Please point give some more information regarding this tablet so I can
forward this issue to people dealing with EV2.
> I thought that anyone , using GPL'd kernel sources has to share sources, but
> Renesas ignored my email asking for the sources...
Renesas is a large company. Of course you should be able to get the
sources if you bought the product.
Thanks,
/ magnus
^ permalink raw reply
* Re: LCDC problem after commit 794d78fea51504bad3880d14f354a9847f318f25
From: Rafael J. Wysocki @ 2011-08-11 19:37 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <201108080125.34329.rjw@sisk.pl>
On Thursday, August 11, 2011, Laurent Pinchart wrote:
> Hi Magnus,
>
> Sorry for the late reply.
>
> On Tuesday 09 August 2011 12:48:44 Magnus Damm wrote:
> > On Mon, Aug 8, 2011 at 10:46 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> > > On Mon, Aug 8, 2011 at 8:25 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > >> Unfortunately, after commit 794d78fea51504bad3880d14f354a9847f318f25
> > >> (drivers: sh: late disabling of clocks V2) the LCDC screen on my
> > >> Mackerel board goes off (late) during boot and cannot be turned on
> > >> by any way AFAICS (the backlight remains on, though).
> > >>
> > >> It looks like the late disabling of clocks interacts badly with the
> > >> clock management done by PM domains.
> > >
> > > This is most likely showing a so-far-not-handled clock dependency for
> > > the LCDC hardware. I'll have a look.
> >
> > Further investigation shows that this only triggers when the MERAM is
> > enabled in the kernel configuration using CONFIG_FB_SH_MOBILE_MERAM=y.
> > So this seems more related to MERAM power management than LCDC.
> >
> > Digging a bit deeper makes it clear that the sh_mobile_meram.c driver
> > in upstream doesn't seem to include any Runtime PM code. I recall
> > seeing various versions posted to the mailing list.
> >
> > Laurent [CC], can you please provide us with a list of outstanding
> > LCDC/MERAM patches to make this work as expected? I realize there are
> > quite a few outstanding LCDC patches, but if possible please provide a
> > list of the bare minimum to make this work with 3.1-rc.
>
> I've pushed my pending patches to http://git.linuxtv.org/pinchartl/fbdev.git
> in the pm-domains branch. The first 19 patches have been picked from mailing
> lists. Hopefully they're the latest versions that have been posted. The next
> 11 patches shouldn't be required to enable runtime PM with the MERAM, but they
> provide code cleanup and bug fixes.
>
> Are Rafael' and Damian's patches ready for mainline ? If so, when will they be
> pulled ? They're more than one month old, I was expecting them to hit v3.1-
> rc1. The backlog is growing, which makes collaboration more difficult.
Which of my patches are you referring to in particular?
Rafael
^ permalink raw reply
* Re: [PATCH 11/13] ARM: gpio: consolidate trivial gpiolib
From: Felipe Balbi @ 2011-08-11 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110811150718.GA4924@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]
Hi,
On Thu, Aug 11, 2011 at 04:07:18PM +0100, Russell King - ARM Linux wrote:
> On Thu, Aug 11, 2011 at 05:15:31PM +0300, Felipe Balbi wrote:
> > On Tue, Aug 09, 2011 at 09:08:01AM +0100, Russell King - ARM Linux wrote:
> > > diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
> > > index 166a7a3..15e8970 100644
> > > --- a/arch/arm/include/asm/gpio.h
> > > +++ b/arch/arm/include/asm/gpio.h
> > > @@ -4,4 +4,14 @@
> > > /* not all ARM platforms necessarily support this API ... */
> > > #include <mach/gpio.h>
> > >
> > > +#ifdef __ARM_GPIOLIB_TRIVIAL
> > > +/* Note: this may rely upon the value of ARCH_NR_GPIOS set in mach/gpio.h */
> > > +#include <asm-generic/gpio.h>
> > > +
> > > +/* The trivial gpiolib dispatchers */
> > > +#define gpio_get_value __gpio_get_value
> > > +#define gpio_set_value __gpio_set_value
> > > +#define gpio_cansleep __gpio_cansleep
> > > +#endif
> >
> > could that be a selectable symbol ? Something like:
> >
> > CONFIG_HAS_ARM_TRIVIAL_GPIO
> >
> > then on Kconfig you just:
> >
> > select HAS_ARM_TIVIAL_GPIO or something ?
>
> That makes things more complicated, because that involves digging through
> a lot of platform code in a couple of places to work out exactly when we
> need this - and it crosses the boundary to arch/sh too.
>
> So I'd prefer to keep this simple.
>
> The long-term goal is to remove that symbol entirely, but in order to do
> that we need to kill of the "optimized" on-board SoC stuff in those (few)
> gpio.h which don't have the symbol selected. This is rather necessary to
> progress towards the consolidated kernel. (Re-inventing gpiolib by moving
> them out of line isn't a good idea...)
Ok, I understand.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 11/13] ARM: gpio: consolidate trivial gpiolib
From: David Brown @ 2011-08-11 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110811150807.GB4924@n2100.arm.linux.org.uk>
On Thu, Aug 11, 2011 at 04:08:07PM +0100, Russell King - ARM Linux wrote:
> > As a note, there were duplicated e-mail address Grant and Nicolas in Cc ;)
> > I just pushed 'reply all' :)
>
> That's not in the original email, and isn't in any one elses replies....
The original patches have a doubled CC line. I think most mailers
eliminate the duplicates, though.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH 11/13] ARM: gpio: consolidate trivial gpiolib
From: Russell King - ARM Linux @ 2011-08-11 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <017101cc581c$6e277530$4a765f90$%kim@samsung.com>
On Thu, Aug 11, 2011 at 08:47:18PM +0900, Kukjin Kim wrote:
> Russell King - ARM Linux wrote:
> >
> > Consolidate 24 trivial gpiolib implementions out of mach/gpio.h
> > into asm/gpio.h. This is basically the include of asm-generic/gpio.h
> > and the definition of gpio_get_value, gpio_set_value, and gpio_cansleep
> > as described in Documentation/gpio.txt
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> on following Samsung stuff...
Thanks.
> As a note, there were duplicated e-mail address Grant and Nicolas in Cc ;)
> I just pushed 'reply all' :)
That's not in the original email, and isn't in any one elses replies....
^ permalink raw reply
* Re: [PATCH 11/13] ARM: gpio: consolidate trivial gpiolib
From: Russell King - ARM Linux @ 2011-08-11 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110811141528.GL28500@legolas.emea.dhcp.ti.com>
On Thu, Aug 11, 2011 at 05:15:31PM +0300, Felipe Balbi wrote:
> On Tue, Aug 09, 2011 at 09:08:01AM +0100, Russell King - ARM Linux wrote:
> > diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
> > index 166a7a3..15e8970 100644
> > --- a/arch/arm/include/asm/gpio.h
> > +++ b/arch/arm/include/asm/gpio.h
> > @@ -4,4 +4,14 @@
> > /* not all ARM platforms necessarily support this API ... */
> > #include <mach/gpio.h>
> >
> > +#ifdef __ARM_GPIOLIB_TRIVIAL
> > +/* Note: this may rely upon the value of ARCH_NR_GPIOS set in mach/gpio.h */
> > +#include <asm-generic/gpio.h>
> > +
> > +/* The trivial gpiolib dispatchers */
> > +#define gpio_get_value __gpio_get_value
> > +#define gpio_set_value __gpio_set_value
> > +#define gpio_cansleep __gpio_cansleep
> > +#endif
>
> could that be a selectable symbol ? Something like:
>
> CONFIG_HAS_ARM_TRIVIAL_GPIO
>
> then on Kconfig you just:
>
> select HAS_ARM_TIVIAL_GPIO or something ?
That makes things more complicated, because that involves digging through
a lot of platform code in a couple of places to work out exactly when we
need this - and it crosses the boundary to arch/sh too.
So I'd prefer to keep this simple.
The long-term goal is to remove that symbol entirely, but in order to do
that we need to kill of the "optimized" on-board SoC stuff in those (few)
gpio.h which don't have the symbol selected. This is rather necessary to
progress towards the consolidated kernel. (Re-inventing gpiolib by moving
them out of line isn't a good idea...)
^ permalink raw reply
* Re: [PATCH 11/13] ARM: gpio: consolidate trivial gpiolib
From: Felipe Balbi @ 2011-08-11 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1QqhM1-0003af-U5@rmk-PC.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2864 bytes --]
On Tue, Aug 09, 2011 at 09:08:01AM +0100, Russell King - ARM Linux wrote:
> Consolidate 24 trivial gpiolib implementions out of mach/gpio.h
> into asm/gpio.h. This is basically the include of asm-generic/gpio.h
> and the definition of gpio_get_value, gpio_set_value, and gpio_cansleep
> as described in Documentation/gpio.txt
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> arch/arm/include/asm/gpio.h | 10 ++++++++++
> arch/arm/mach-at91/include/mach/gpio.h | 5 +----
> arch/arm/mach-ep93xx/include/mach/gpio.h | 7 +------
> arch/arm/mach-exynos4/include/mach/gpio.h | 5 +----
> arch/arm/mach-gemini/include/mach/gpio.h | 5 +----
> arch/arm/mach-ks8695/include/mach/gpio.h | 11 ++---------
> arch/arm/mach-lpc32xx/include/mach/gpio.h | 17 +----------------
> arch/arm/mach-msm/include/mach/gpio.h | 5 +----
> arch/arm/mach-mxs/include/mach/gpio.h | 6 +-----
> arch/arm/mach-realview/include/mach/gpio.h | 6 +-----
> arch/arm/mach-s3c2410/include/mach/gpio.h | 5 +----
> arch/arm/mach-s3c64xx/include/mach/gpio.h | 6 +-----
> arch/arm/mach-s5p64x0/include/mach/gpio.h | 6 +-----
> arch/arm/mach-s5pc100/include/mach/gpio.h | 6 +-----
> arch/arm/mach-s5pv210/include/mach/gpio.h | 6 +-----
> arch/arm/mach-shmobile/include/mach/gpio.h | 15 +--------------
> arch/arm/mach-tegra/include/mach/gpio.h | 6 +-----
> arch/arm/mach-versatile/include/mach/gpio.h | 6 +-----
> arch/arm/mach-vt8500/include/mach/gpio.h | 6 +-----
> arch/arm/mach-w90x900/include/mach/gpio.h | 5 +----
> arch/arm/plat-mxc/include/mach/gpio.h | 5 +----
> arch/arm/plat-nomadik/include/plat/gpio.h | 11 +----------
> arch/arm/plat-omap/include/plat/gpio.h | 15 +--------------
> arch/arm/plat-orion/include/plat/gpio.h | 6 ++----
> arch/arm/plat-spear/include/plat/gpio.h | 6 +-----
> 25 files changed, 36 insertions(+), 151 deletions(-)
>
> diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
> index 166a7a3..15e8970 100644
> --- a/arch/arm/include/asm/gpio.h
> +++ b/arch/arm/include/asm/gpio.h
> @@ -4,4 +4,14 @@
> /* not all ARM platforms necessarily support this API ... */
> #include <mach/gpio.h>
>
> +#ifdef __ARM_GPIOLIB_TRIVIAL
> +/* Note: this may rely upon the value of ARCH_NR_GPIOS set in mach/gpio.h */
> +#include <asm-generic/gpio.h>
> +
> +/* The trivial gpiolib dispatchers */
> +#define gpio_get_value __gpio_get_value
> +#define gpio_set_value __gpio_set_value
> +#define gpio_cansleep __gpio_cansleep
> +#endif
could that be a selectable symbol ? Something like:
CONFIG_HAS_ARM_TRIVIAL_GPIO
then on Kconfig you just:
select HAS_ARM_TIVIAL_GPIO or something ?
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Renesas EMEV2 Kernel sources
From: Serg @ 2011-08-11 12:24 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4E12D338.1090508@spesonline.com>
Magnus Damm <magnus.damm <at> gmail.com> writes:
>
> Hi Luca,
>
> On Tue, Jul 5, 2011 at 6:02 PM, Luca Santini
> <luca.santini <at> spesonline.com> wrote:
> > Hi All,
> > anybody knows where to find NEC EMMA EV/2 (mach-emxx) Kernel Sources / if
> > these are public domain ?
>
> Thanks for your email. So I asked around a bit about the NEC EMMA line
> and I got to know that you should be able to request sources from the
> same place as you got the development board.
>
> For instance, if you have a board from Kyoto Microcomputer then you
> should request sources from them. If you happen to have a NEC EMMA
> EV/2 board that has been distributed by Renesas Electronics then
> please request sources via your regular business channels.
>
> If you still can't get sources for your board then please let me know
> more details (board make, name and kernel version) and I'll do my best
> to find more information.
>
> Hope this helps!
>
Hi.
I happen to have a NEC EV2 powered android tablet. From whom should I request
the sources?
I thought that anyone , using GPL'd kernel sources has to share sources, but
Renesas ignored my email asking for the sources...
^ permalink raw reply
* RE: [PATCH 13/13] ARM: gpio: make trivial GPIOLIB implementation the
From: Kukjin Kim @ 2011-08-11 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1QqhMg-0003an-GW@rmk-PC.arm.linux.org.uk>
Russell King - ARM Linux wrote:
>
> Rather than marking the mach/gpio.h header files which want to use the
> trivial GPIOLIB implementation, mark those which do not want to use it
> instead. This means that by default, you get the trivial implementation
> and only have to do something extra if you need to. This should
> encourage the use of the trivial default implementation.
>
> As an additional bonus, several gpio.h header files become empty.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Looks good to me :)
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
on following Samsung stuff...
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> ---
> arch/arm/include/asm/gpio.h | 2 +-
> arch/arm/mach-exynos4/include/mach/gpio.h | 2 --
> arch/arm/mach-s3c2410/include/mach/gpio.h | 2 --
> arch/arm/mach-s3c64xx/include/mach/gpio.h | 2 --
> arch/arm/mach-s5p64x0/include/mach/gpio.h | 2 --
> arch/arm/mach-s5pc100/include/mach/gpio.h | 2 --
> arch/arm/mach-s5pv210/include/mach/gpio.h | 2 --
>
> diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
> index 5032224..11ad0bf 100644
> --- a/arch/arm/include/asm/gpio.h
> +++ b/arch/arm/include/asm/gpio.h
> @@ -4,7 +4,7 @@
> /* not all ARM platforms necessarily support this API ... */
> #include <mach/gpio.h>
>
> -#ifdef __ARM_GPIOLIB_TRIVIAL
> +#ifndef __ARM_GPIOLIB_COMPLEX
> /* Note: this may rely upon the value of ARCH_NR_GPIOS set in mach/gpio.h
*/
> #include <asm-generic/gpio.h>
>
> diff --git a/arch/arm/mach-exynos4/include/mach/gpio.h b/arch/arm/mach-
> exynos4/include/mach/gpio.h
> index b91e8b2..80523ca 100644
> --- a/arch/arm/mach-exynos4/include/mach/gpio.h
> +++ b/arch/arm/mach-exynos4/include/mach/gpio.h
> @@ -146,6 +146,4 @@ enum s5p_gpio_number {
> #define ARCH_NR_GPIOS
> (EXYNOS4_GPZ(EXYNOS4_GPIO_Z_NR) + \
> CONFIG_SAMSUNG_GPIO_EXTRA + 1)
>
> -#define __ARM_GPIOLIB_TRIVIAL
> -
> #endif /* __ASM_ARCH_GPIO_H */
> diff --git a/arch/arm/mach-s3c2410/include/mach/gpio.h b/arch/arm/mach-
> s3c2410/include/mach/gpio.h
> index d502d17..6fac70f 100644
> --- a/arch/arm/mach-s3c2410/include/mach/gpio.h
> +++ b/arch/arm/mach-s3c2410/include/mach/gpio.h
> @@ -11,8 +11,6 @@
> * published by the Free Software Foundation.
> */
>
> -#define __ARM_GPIOLIB_TRIVIAL
> -
> /* some boards require extra gpio capacity to support external
> * devices that need GPIO.
> */
> diff --git a/arch/arm/mach-s3c64xx/include/mach/gpio.h b/arch/arm/mach-
> s3c64xx/include/mach/gpio.h
> index 3a8857c..6e34c2f 100644
> --- a/arch/arm/mach-s3c64xx/include/mach/gpio.h
> +++ b/arch/arm/mach-s3c64xx/include/mach/gpio.h
> @@ -12,8 +12,6 @@
> * published by the Free Software Foundation.
> */
>
> -#define __ARM_GPIOLIB_TRIVIAL
> -
> /* GPIO bank sizes */
> #define S3C64XX_GPIO_A_NR (8)
> #define S3C64XX_GPIO_B_NR (7)
> diff --git a/arch/arm/mach-s5p64x0/include/mach/gpio.h b/arch/arm/mach-
> s5p64x0/include/mach/gpio.h
> index c3a6aa0..06cd3c9 100644
> --- a/arch/arm/mach-s5p64x0/include/mach/gpio.h
> +++ b/arch/arm/mach-s5p64x0/include/mach/gpio.h
> @@ -13,8 +13,6 @@
> #ifndef __ASM_ARCH_GPIO_H
> #define __ASM_ARCH_GPIO_H __FILE__
>
> -#define __ARM_GPIOLIB_TRIVIAL
> -
> /* GPIO bank sizes */
>
> #define S5P6440_GPIO_A_NR (6)
> diff --git a/arch/arm/mach-s5pc100/include/mach/gpio.h b/arch/arm/mach-
> s5pc100/include/mach/gpio.h
> index 0e75641..5e1a924 100644
> --- a/arch/arm/mach-s5pc100/include/mach/gpio.h
> +++ b/arch/arm/mach-s5pc100/include/mach/gpio.h
> @@ -15,8 +15,6 @@
> #ifndef __ASM_ARCH_GPIO_H
> #define __ASM_ARCH_GPIO_H __FILE__
>
> -#define __ARM_GPIOLIB_TRIVIAL
> -
> /* GPIO bank sizes */
> #define S5PC100_GPIO_A0_NR (8)
> #define S5PC100_GPIO_A1_NR (5)
> diff --git a/arch/arm/mach-s5pv210/include/mach/gpio.h b/arch/arm/mach-
> s5pv210/include/mach/gpio.h
> index d348ee2..6c8b903 100644
> --- a/arch/arm/mach-s5pv210/include/mach/gpio.h
> +++ b/arch/arm/mach-s5pv210/include/mach/gpio.h
> @@ -13,8 +13,6 @@
> #ifndef __ASM_ARCH_GPIO_H
> #define __ASM_ARCH_GPIO_H __FILE__
>
> -#define __ARM_GPIOLIB_TRIVIAL
> -
> /* Practically, GPIO banks up to MP03 are the configurable gpio banks */
>
> /* GPIO bank sizes */
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox