headers
Pavel Machek | 1 Feb 11:03
Picon

Re: [PATCH v2 11/13] ARM: only include mach/irqs.h for !SPARSE_IRQ

On Mon 2012-01-30 11:44:28, Cyril Hrubis wrote:
> Hi!
> > > > As a side-note, you may be pleased to know that I have SA11x0 stuff
> > > > converted to (and tested) with sparse IRQ.  That's with SA1111, the
> > > > UCB1x00 and Neponset expansion board for the Assabet all dynamically
> > > > allocating their IRQs.  The only fixed-numbered IRQs in SA11x0 in my
> > > > tree at the time of writing are the on-SoC IRQs, and the LoCoMo IRQs
> > > > (which I don't have the hardware to test for, so I'm not touching.)
> > > 
> > > That's really cool.
> > > 
> > > Not that there are many people who might still benefit from running that
> > > code, but like I said this should serve as a real and relatively simple
> > > example that might benefit more complex platforms.
> > > 
> > > 
> > > Nicolas
> > 
> > Indeed, that's good going. I'm CCing a guy who might have a SA11xx board with 
> > LoCoMo chip (that's old zaurus sl55xx, right?).
> 
> I think I still do have old zaurus in some box somewhere (I stopped playing
> with it once I got the newer one). And I think that Pavel Machek (CC) has one
> too (I think that he wanted to give away to anybody who is wishing to maintain
> the particular kernel parts and I think that in the end nobody took it).

Yep, I still have old collie (sl5500) machine. I don't really use
it...

									Pavel
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mr. David M Lee | 1 Feb 12:51
Picon

Hello This is Mr. David M Lee from Bank of America I have by information you that we receiver an ATM card on your name so you have to get back to this office as soon as you receiver this mail today so that we will let you know what to do next okay?

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Guennadi Liakhovetski | 1 Feb 13:48
Picon
Picon

Re: [REGRESSION] current Linus tree doesn't suspend on sh7372 (mackerel)

Hi Rafael

On Wed, 1 Feb 2012, Rafael J. Wysocki wrote:

> Hi,
> 
> On Tuesday, January 31, 2012, Guennadi Liakhovetski wrote:
> > Hi
> > 
> > Current Linus' tree doesn't suspend on mackerel for me (will send .config 
> > and the command line off-list).
> 
> You seem to have MTD enabled in your .config and there's a known suspend
> regression in MTD.  Can you please check if the attached patch helps?

Yes, it does, thanks! Or it does at least partially - if MERAM is enabled 
the fb content is destroyed after resume, which is a separate problem, 
apparently.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vinod Koul | 1 Feb 18:02
Picon
Favicon

Re: [PATCH 1/2] dma: sh_dma: not all SH DMAC implementations support MEMCPY

On Wed, 2012-01-18 at 10:14 +0100, Guennadi Liakhovetski wrote:
> Add a flag to allow platforms to specify, whether a DMAC instance supports
> the MEMCPY operation. To avoid regressions, preserve the current default.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski <at> gmx.de>
Applied both, Thanks
> ---
>  drivers/dma/shdma.c    |    3 ++-
>  include/linux/sh_dma.h |    1 +
>  2 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/dma/shdma.c b/drivers/dma/shdma.c
> index cabcfe8..e4ed4da 100644
> --- a/drivers/dma/shdma.c
> +++ b/drivers/dma/shdma.c
> @@ -1267,7 +1267,8 @@ static int __init sh_dmae_probe(struct platform_device *pdev)
>  
>  	INIT_LIST_HEAD(&shdev->common.channels);
>  
> -	dma_cap_set(DMA_MEMCPY, shdev->common.cap_mask);
> +	if (!pdata->slave_only)
> +		dma_cap_set(DMA_MEMCPY, shdev->common.cap_mask);
>  	if (pdata->slave && pdata->slave_num)
>  		dma_cap_set(DMA_SLAVE, shdev->common.cap_mask);
>  
> diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> index e11e171..db637b9 100644
> --- a/include/linux/sh_dma.h
> +++ b/include/linux/sh_dma.h
> @@ -70,6 +70,7 @@ struct sh_dmae_pdata {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rafael J. Wysocki | 1 Feb 22:14
Picon
Gravatar

Re: [PATCH 0/2] mmc: use PM QoS instead of delayed clock gating

On Wednesday, February 01, 2012, Guennadi Liakhovetski wrote:
> On Sat, 28 Jan 2012, Rafael J. Wysocki wrote:
> 
> > Hi,
> > 
> > On Thursday, January 19, 2012, Guennadi Liakhovetski wrote:
> > > Hi all
> > > 
> > > I've already sent one of these two patches yesterday, but I forgot to 
> > > include Rafael on the CC list and forgot to mention, that the patch should 
> > > be treated as a regression fix and should go into 3.3. The reason why the 
> > > commit
> > > 
> > > commit 7e09bedba1b87f9c7b34ba895b57baf0c36ccdc8
> > 
> > I think that should be 597dd9d79cfbbb1636d00a7fd0880355d9b20c41, right?
> > 
> > > Author: Sujit Reddy Thumma <sthumma <at> codeaurora.org>
> > > Date:   Mon Nov 14 13:53:29 2011 +0530
> > > 
> > >     mmc: core: Use delayed work in clock gating framework
> > > 
> > > can be considered a regression is, that it extends the powered-on time of 
> > > the controller(s) and, possibly, of respective power domains by 200ms (by 
> > > default), which is an essential change in behaviour in the negative 
> > > direction.
> > > 
> > > However, if this is indeed the desired change, maybe the better approach 
> > > now would be to modify this behaviour in individual drivers, which is 
> > > exactly what the two patches in this series are doing.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul E. McKenney | 2 Feb 01:43
Picon

[PATCH RFC idle 3/3] sh: Avoid invoking RCU when CPU is idle

From: "Paul E. McKenney" <paul.mckenney <at> linaro.org>

The idle loop is a quiscent state for RCU, which means that RCU ignores
CPUs that have told RCU that they are idle via rcu_idle_enter().
There are nevertheless quite a few places where idle CPUs use RCU, most
commonly indirectly via tracing.  This patch fixes these problems for SH.

Many of these bugs have been in the kernel for quite some time, but
Frederic's recent change now gives warnings.

This patch takes the straightforward approach of pushing the
rcu_idle_enter()/rcu_idle_exit() pair further down into the core of the
idle loop.

Signed-off-by: Paul E. McKenney <paul.mckenney <at> linaro.org>
Signed-off-by: Paul E. McKenney <paulmck <at> linux.vnet.ibm.com>
Cc: Paul Mundt <lethal <at> linux-sh.org>
Cc: Mike Frysinger <vapier <at> gentoo.org>
Cc: linux-sh <at> vger.kernel.org
---
 arch/sh/kernel/idle.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/sh/kernel/idle.c b/arch/sh/kernel/idle.c
index 406508d..d125668 100644
--- a/arch/sh/kernel/idle.c
+++ b/arch/sh/kernel/idle.c
@@ -53,8 +53,10 @@ static inline int hlt_works(void)
 static void poll_idle(void)
 {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Guennadi Liakhovetski | 2 Feb 23:12
Picon
Picon

[PATCH] PM: provide a dummy dev_gpd_data() when generic domains are not used

dev_gpd_data() is a generic macro, also useful for drivers. Hence it should
be available also when CONFIG_PM_GENERIC_DOMAINS is not selected. OTOH,
to_gpd_data() is so far unused outside of the generic PM domain code and
does not seem to be very useful without CONFIG_PM_GENERIC_DOMAINS.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski <at> gmx.de>
---
 include/linux/pm_domain.h |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index a03a0ad..f1a5f8b 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -99,12 +99,12 @@ struct generic_pm_domain_data {
 	bool need_restore;
 };

+#ifdef CONFIG_PM_GENERIC_DOMAINS
 static inline struct generic_pm_domain_data *to_gpd_data(struct pm_domain_data *pdd)
 {
 	return container_of(pdd, struct generic_pm_domain_data, base);
 }

-#ifdef CONFIG_PM_GENERIC_DOMAINS
 static inline struct generic_pm_domain_data *dev_gpd_data(struct device *dev)
 {
 	return to_gpd_data(dev->power.subsys_data->domain_data);
@@ -195,6 +195,10 @@ static inline bool default_stop_ok(struct device *dev)
 	return false;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Guennadi Liakhovetski | 2 Feb 23:16
Picon
Picon

[PATCH v2] mmc: tmio_mmc, sdhi: update input clock frequency after resume

After a runtime or system-wide suspend the clock frequency can change,
therefore it must be re-read.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski <at> gmx.de>
---

v2: move updating the clock frequency from .runtime_resume() to .start(), 
since the former is not called, when power domains are used and when the 
domain is not powered off and on - thanks to Magnus for pointing out. This 
version requires my patch from several minutes ago "PM: provide a dummy 
dev_gpd_data() when generic domains are not used."

http://article.gmane.org/gmane.linux.ports.sh.devel/13487

 drivers/mmc/host/sh_mobile_sdhi.c |   20 ++++++++++++++++++++
 drivers/mmc/host/tmio_mmc.h       |    1 +
 drivers/mmc/host/tmio_mmc_pio.c   |   26 +++++++++++++++++++++-----
 include/linux/mfd/tmio.h          |    1 +
 4 files changed, 43 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/sh_mobile_sdhi.c b/drivers/mmc/host/sh_mobile_sdhi.c
index 2c3a9d3..2842ab9 100644
--- a/drivers/mmc/host/sh_mobile_sdhi.c
+++ b/drivers/mmc/host/sh_mobile_sdhi.c
@@ -23,6 +23,7 @@
 #include <linux/slab.h>
 #include <linux/module.h>
 #include <linux/platform_device.h>
+#include <linux/pm_domain.h>
 #include <linux/mmc/host.h>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Guennadi Liakhovetski | 3 Feb 16:43
Picon
Picon

[PATCH/RFC] usb: fix renesas_usbhs to not schedule in atomic context

The current renesas_usbhs driver triggers

BUG: scheduling while atomic: ksoftirqd/0/3/0x00000102

with enabled CONFIG_DEBUG_ATOMIC_SLEEP, by submitting DMA transfers from 
an atomic (tasklet) context, which is not supported by the shdma dmaengine 
driver. Fix it by switching to a work. Also simplify some list 
manipulations.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski <at> gmx.de>
---

Shimoda-san, this is the problem, that you were observing. However, it 
exists with the present version of shdma just as well as with the new one 
- on top of the simple DMA library. I marked it an RFC because (1) I only 
lightly tested it with the gadget device on mackerel with the mass storage 
gadget, and (2) I am somewhat concerned about races. Currently the work 
function runs with no locking and there are no usual cancel_work_sync() 
points in the patch. However, it has also been like this before with the 
tasklet implementation, which is not much better, and it looks like there 
are no asynchronous operations on the same packets like timeouts. Only 
asynchronous events, that I can think about are things like unloading the 
driver or unplugging the cable, but these have been there before too. It 
would become worse on SMP, I think. Comments welcome.

diff --git a/drivers/usb/renesas_usbhs/fifo.c b/drivers/usb/renesas_usbhs/fifo.c
index 72339bd..4d739ec 100644
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -75,8 +75,7 @@ void usbhs_pkt_push(struct usbhs_pipe *pipe, struct usbhs_pkt *pkt,
(Continue reading)

Permalink | Reply | 4 comments |
headers
Rafael J. Wysocki | 3 Feb 20:25
Picon
Gravatar

Re: [PATCH 0/2] mmc: use PM QoS instead of delayed clock gating

On Friday, February 03, 2012, Guennadi Liakhovetski wrote:
> On Wed, 1 Feb 2012, Rafael J. Wysocki wrote:
[...]
> > > > As for the patches, I'll reply to each of them separately.
> > > 
> > > Right, thanks for the review. Basically your comments are the same for 
> > > both:
> > > 
> > > 1. you'd like not just to change the default initial delay to 0, but to 
> > > prohibit changing it from the userspace completely.
> > 
> > No, I haven't said that. :-)
> > 
> > I said that setting the delay to 0 initially in the driver wasn't sufficient
> > to prevent the delay from being used.
> 
> Yes, sure, I realise that.
> 
> > If your intention was to use the PM QoS
> > _along_ with the delay, then you shouldn't advertise that as a regression fix
> > and I don't see a point setting the delay to 0 initially in the driver in that
> > case.
> 
> Hmm, I'm not sure to follow here. Firstly, I'm not sure why using both 
> cannot classify as a fix, secondly, do you mean, that when using QoS we 
> don't have to set the delay to 0? But with the delay left at 200ms PM QoS 
> doesn't have much left to say?
> 
> > > For that we need Chris' opinion and that cannot be done in MMC host drivers
> > > so far, AFAICS.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane