* [PATCH] PM / Domains: Make it possible to assign names to generic PM domains
From: Rafael J. Wysocki @ 2011-11-27 20:53 UTC (permalink / raw)
To: Linux PM list; +Cc: LKML, Linux-sh list, Magnus Damm
From: Rafael J. Wysocki <rjw@sisk.pl>
Add a name member pointer to struct generic_pm_domain and use it in
diagnostic messages regarding the domain power-off and power-on
latencies. Update the ARM shmobile SH7372 code to assign names to
the PM domains used by it.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
Hi,
This patch is on top of linux-pm/linux-next.
Thanks,
Rafael
---
arch/arm/mach-shmobile/include/mach/sh7372.h | 1 +
arch/arm/mach-shmobile/pm-sh7372.c | 17 +++++++++++++----
drivers/base/power/domain.c | 14 ++++++++++++--
include/linux/pm_domain.h | 1 +
4 files changed, 27 insertions(+), 6 deletions(-)
Index: linux/drivers/base/power/domain.c
=================================--- linux.orig/drivers/base/power/domain.c
+++ linux/drivers/base/power/domain.c
@@ -209,8 +209,13 @@ int __pm_genpd_poweron(struct generic_pm
goto err;
elapsed_ns = ktime_to_ns(ktime_sub(ktime_get(), time_start));
- if (elapsed_ns > genpd->power_on_latency_ns)
+ if (elapsed_ns > genpd->power_on_latency_ns) {
genpd->power_on_latency_ns = elapsed_ns;
+ if (genpd->name)
+ pr_warning("%s: Power-on latency exceeded, "
+ "new value %lld ns\n", genpd->name,
+ elapsed_ns);
+ }
}
genpd_set_active(genpd);
@@ -428,8 +433,13 @@ static int pm_genpd_poweroff(struct gene
}
elapsed_ns = ktime_to_ns(ktime_sub(ktime_get(), time_start));
- if (elapsed_ns > genpd->power_off_latency_ns)
+ if (elapsed_ns > genpd->power_off_latency_ns) {
genpd->power_off_latency_ns = elapsed_ns;
+ if (genpd->name)
+ pr_warning("%s: Power-off latency exceeded, "
+ "new value %lld ns\n", genpd->name,
+ elapsed_ns);
+ }
}
genpd->status = GPD_STATE_POWER_OFF;
Index: linux/include/linux/pm_domain.h
=================================--- linux.orig/include/linux/pm_domain.h
+++ linux/include/linux/pm_domain.h
@@ -49,6 +49,7 @@ struct generic_pm_domain {
struct mutex lock;
struct dev_power_governor *gov;
struct work_struct power_off_work;
+ char *name;
unsigned int in_progress; /* Number of devices being suspended now */
atomic_t sd_count; /* Number of subdomains with power "on" */
enum gpd_status status; /* Current state of the domain */
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
@@ -101,8 +101,8 @@ static int pd_power_down(struct generic_
}
if (!sh7372_pd->no_debug)
- pr_debug("sh7372 power domain down 0x%08x -> PSTR = 0x%08x\n",
- mask, __raw_readl(PSTR));
+ pr_debug("%s: Power off, 0x%08x -> PSTR = 0x%08x\n",
+ sh7372_pd->name, mask, __raw_readl(PSTR));
return 0;
}
@@ -133,8 +133,8 @@ static int __pd_power_up(struct sh7372_p
ret = -EIO;
if (!sh7372_pd->no_debug)
- pr_debug("sh7372 power domain up 0x%08x -> PSTR = 0x%08x\n",
- mask, __raw_readl(PSTR));
+ pr_debug("%s: Power on, 0x%08x -> PSTR = 0x%08x\n",
+ sh7372_pd->name, mask, __raw_readl(PSTR));
out:
if (ret = 0 && sh7372_pd->resume && do_resume)
@@ -207,6 +207,7 @@ void sh7372_init_pm_domain(struct sh7372
struct dev_power_governor *gov = sh7372_pd->gov;
pm_genpd_init(genpd, gov ? : &simple_qos_governor, false);
+ genpd->name = sh7372_pd->name;
genpd->dev_ops.stop = sh7372_stop_dev;
genpd->dev_ops.start = sh7372_start_dev;
genpd->dev_ops.active_wakeup = pd_active_wakeup;
@@ -233,18 +234,22 @@ void sh7372_pm_add_subdomain(struct sh73
}
struct sh7372_pm_domain sh7372_a4lc = {
+ .name = "A4LC",
.bit_shift = 1,
};
struct sh7372_pm_domain sh7372_a4mp = {
+ .name = "A4MP",
.bit_shift = 2,
};
struct sh7372_pm_domain sh7372_d4 = {
+ .name = "D4",
.bit_shift = 3,
};
struct sh7372_pm_domain sh7372_a4r = {
+ .name = "A4R",
.bit_shift = 5,
.gov = &sh7372_always_on_gov,
.suspend = sh7372_a4r_suspend,
@@ -253,14 +258,17 @@ struct sh7372_pm_domain sh7372_a4r = {
};
struct sh7372_pm_domain sh7372_a3rv = {
+ .name = "A3RV",
.bit_shift = 6,
};
struct sh7372_pm_domain sh7372_a3ri = {
+ .name = "A3RI",
.bit_shift = 8,
};
struct sh7372_pm_domain sh7372_a3sp = {
+ .name = "A3SP",
.bit_shift = 11,
.gov = &sh7372_always_on_gov,
.no_debug = true,
@@ -275,6 +283,7 @@ static void sh7372_a3sp_init(void)
}
struct sh7372_pm_domain sh7372_a3sg = {
+ .name = "A3SG",
.bit_shift = 13,
};
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
@@ -480,6 +480,7 @@ struct platform_device;
struct sh7372_pm_domain {
struct generic_pm_domain genpd;
struct dev_power_governor *gov;
+ char *name;
void (*suspend)(void);
void (*resume)(void);
unsigned int bit_shift;
^ permalink raw reply
* [PATCH 06/62] sh: remove the second argument of k[un]map_atomic()
From: Cong Wang @ 2011-11-27 5:26 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, Cong Wang, Paul Mundt, Stuart Menefy, linux-sh
In-Reply-To: <1322371662-26166-1-git-send-email-amwang@redhat.com>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
arch/sh/mm/cache-sh4.c | 4 ++--
arch/sh/mm/cache.c | 12 ++++++------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/sh/mm/cache-sh4.c b/arch/sh/mm/cache-sh4.c
index 92eb986..112fea1 100644
--- a/arch/sh/mm/cache-sh4.c
+++ b/arch/sh/mm/cache-sh4.c
@@ -244,7 +244,7 @@ static void sh4_flush_cache_page(void *args)
if (map_coherent)
vaddr = kmap_coherent(page, address);
else
- vaddr = kmap_atomic(page, KM_USER0);
+ vaddr = kmap_atomic(page);
address = (unsigned long)vaddr;
}
@@ -259,7 +259,7 @@ static void sh4_flush_cache_page(void *args)
if (map_coherent)
kunmap_coherent(vaddr);
else
- kunmap_atomic(vaddr, KM_USER0);
+ kunmap_atomic(vaddr);
}
}
diff --git a/arch/sh/mm/cache.c b/arch/sh/mm/cache.c
index 5a580ea..616966a 100644
--- a/arch/sh/mm/cache.c
+++ b/arch/sh/mm/cache.c
@@ -95,7 +95,7 @@ void copy_user_highpage(struct page *to, struct page *from,
{
void *vfrom, *vto;
- vto = kmap_atomic(to, KM_USER1);
+ vto = kmap_atomic(to);
if (boot_cpu_data.dcache.n_aliases && page_mapped(from) &&
test_bit(PG_dcache_clean, &from->flags)) {
@@ -103,16 +103,16 @@ void copy_user_highpage(struct page *to, struct page *from,
copy_page(vto, vfrom);
kunmap_coherent(vfrom);
} else {
- vfrom = kmap_atomic(from, KM_USER0);
+ vfrom = kmap_atomic(from);
copy_page(vto, vfrom);
- kunmap_atomic(vfrom, KM_USER0);
+ kunmap_atomic(vfrom);
}
if (pages_do_alias((unsigned long)vto, vaddr & PAGE_MASK) ||
(vma->vm_flags & VM_EXEC))
__flush_purge_region(vto, PAGE_SIZE);
- kunmap_atomic(vto, KM_USER1);
+ kunmap_atomic(vto);
/* Make sure this page is cleared on other CPU's too before using it */
smp_wmb();
}
@@ -120,14 +120,14 @@ EXPORT_SYMBOL(copy_user_highpage);
void clear_user_highpage(struct page *page, unsigned long vaddr)
{
- void *kaddr = kmap_atomic(page, KM_USER0);
+ void *kaddr = kmap_atomic(page);
clear_page(kaddr);
if (pages_do_alias((unsigned long)kaddr, vaddr & PAGE_MASK))
__flush_purge_region(kaddr, PAGE_SIZE);
- kunmap_atomic(kaddr, KM_USER0);
+ kunmap_atomic(kaddr);
}
EXPORT_SYMBOL(clear_user_highpage);
--
1.7.4.4
^ permalink raw reply related
* Re: Dreamcast build broken
From: Paul Cercueil @ 2011-11-25 16:24 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4EC81660.3010109@gmail.com>
Le 24/11/2011 08:29, Paul Mundt a écrit :
> On Tue, Nov 22, 2011 at 01:02:56PM +0100, Paul Cercueil wrote:
>> Hi,
>>
>> The commit which breaks the dreamcast build is the commit
>> 37b7a97884ba64bf7d403351ac2a9476ab4f1bba :
>> sh: machvec IO death.
>>
> It builds fine for me. You will actually have to supply the build error
> you are experiencing if you expect any further assistance, however.
Hi,
I am able to compile the Linux kernel, the problem is not the compilation.
I do get the "vmlinux" binary once the compilation completes.
However, starting from commit 37b7a97884ba64bf7d403351ac2a9476ab4f1bba
and up to the latest vanilla Linux 3.1,
the vmlinux binary won't start on my dreamcast or on the lxdream emulator.
^ permalink raw reply
* Re: sh-sci CTS problem
From: Takashi Yoshii @ 2011-11-25 5:07 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <OFB48B001D.3AA44CAE-ON80257950.0037E14A-80257950.0039B579@eu.necel.com>
Hi,
> I guess the right thing to do is add an extra field to struct
> plat_sci_port to indicate support for RTS/CTS?
Right. I guess each real pin manipulation will be handled like sci_init_pins().
On the other hand, I don't think there is much things to do here for channels
that does *not* support control lines. get_mctrl() does not provide the function
to tell "not supported" condition anyway.
I think that should be implemented in sci_set_termios().
Currently, it sets SCFCR.MCE regardless of the HW function, and does not
fix any bits in c_flags. We can negate CRTSCTS in termios->c_cflag there,
unless (s->cfg->flags & UPF_xx) or something.
Does anyone know good flags or constant definitions?
/yoshii
^ permalink raw reply
* [PATCH 2/2 v5] net/smsc911x: Add regulator support
From: Robert Marklund @ 2011-11-24 11:03 UTC (permalink / raw)
To: netdev, Steve Glendinning
Cc: Mathieu Poirier, Robert Marklund, Paul Mundt, linux-sh,
Sascha Hauer, Tony Lindgren, linux-omap, Mike Frysinger,
uclinux-dist-devel, Linus Walleij
Add some basic regulator support for the power pins, as needed
by the ST-Ericsson Snowball platform that powers up the SMSC911
chip using an external regulator.
Platforms that use regulators and the smsc911x and have no defined
regulator for the smsc911x and claim complete regulator
constraints with no dummy regulators will need to provide it, for
example using a fixed voltage regulator. It appears that this may
affect (apart from Ux500 Snowball) possibly these archs/machines
that from some grep:s appear to define both CONFIG_SMSC911X and
CONFIG_REGULATOR:
- ARM Freescale mx3 and OMAP 2 plus, Raumfeld machines
- Blackfin
- Super-H
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: linux-sh@vger.kernel.org
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Tony Lindgren <tony@atomide.com>
Cc: linux-omap@vger.kernel.org
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: uclinux-dist-devel@blackfin.uclinux.org
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Robert Marklund <robert.marklund@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v4->v5:
- Split the enable_disable method on Mikes request.
ChangeLog v3->v4:
- Remove dual prints and old comment on Mike's request.
- Split the request_free fucntion on Mike and Sascha request.
ChangeLog v2->v3:
- Use bulk regulators on Mark's request.
- Add Cc-fileds to some possibly affected platforms.
ChangeLog v1->v2:
- Don't check for NULL regulators and error out properly if the
regulators can't be found. All platforms using the smsc911x
and the regulator framework simultaneously need to provide some
kind of regulator for it.
---
drivers/net/ethernet/smsc/smsc911x.c | 111 ++++++++++++++++++++++++++++++----
1 files changed, 100 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
index 8843071..06d0df6 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -44,6 +44,7 @@
#include <linux/module.h>
#include <linux/netdevice.h>
#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
#include <linux/sched.h>
#include <linux/timer.h>
#include <linux/bug.h>
@@ -88,6 +89,8 @@ struct smsc911x_ops {
unsigned int *buf, unsigned int wordcount);
};
+#define SMSC911X_NUM_SUPPLIES 2
+
struct smsc911x_data {
void __iomem *ioaddr;
@@ -138,6 +141,9 @@ struct smsc911x_data {
/* register access functions */
const struct smsc911x_ops *ops;
+
+ /* regulators */
+ struct regulator_bulk_data supplies[SMSC911X_NUM_SUPPLIES];
};
/* Easy access to information */
@@ -362,6 +368,76 @@ out:
spin_unlock_irqrestore(&pdata->dev_lock, flags);
}
+/*
+ * enable resources, currently just regulators.
+ */
+static int smsc911x_enable_resources(struct platform_device *pdev)
+{
+ struct net_device *ndev = platform_get_drvdata(pdev);
+ struct smsc911x_data *pdata = netdev_priv(ndev);
+ int ret = 0;
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(pdata->supplies),
+ pdata->supplies);
+ if (ret)
+ netdev_err(ndev, "failed to enable regulators %d\n",
+ ret);
+ return ret;
+}
+
+/*
+ * disable resources, currently just regulators.
+ */
+static int smsc911x_disable_resources(struct platform_device *pdev)
+{
+ struct net_device *ndev = platform_get_drvdata(pdev);
+ struct smsc911x_data *pdata = netdev_priv(ndev);
+ int ret = 0;
+
+ ret = regulator_bulk_disable(ARRAY_SIZE(pdata->supplies),
+ pdata->supplies);
+ return ret;
+}
+
+/*
+ * Request resources, currently just regulators.
+ *
+ * The SMSC911x has two power pins: vddvario and vdd33a, in designs where
+ * these are not always-on we need to request regulators to be turned on
+ * before we can try to access the device registers.
+ */
+static int smsc911x_request_resources(struct platform_device *pdev)
+{
+ struct net_device *ndev = platform_get_drvdata(pdev);
+ struct smsc911x_data *pdata = netdev_priv(ndev);
+ int ret = 0;
+
+ /* Request regulators */
+ pdata->supplies[0].supply = "vdd33a";
+ pdata->supplies[1].supply = "vddvario";
+ ret = regulator_bulk_get(&pdev->dev,
+ ARRAY_SIZE(pdata->supplies),
+ pdata->supplies);
+ if (ret)
+ netdev_err(ndev, "couldn't get regulators %d\n",
+ ret);
+ return ret;
+}
+
+/*
+ * Free resources, currently just regulators.
+ *
+ */
+static void smsc911x_free_resources(struct platform_device *pdev)
+{
+ struct net_device *ndev = platform_get_drvdata(pdev);
+ struct smsc911x_data *pdata = netdev_priv(ndev);
+
+ /* Free regulators */
+ regulator_bulk_free(ARRAY_SIZE(pdata->supplies),
+ pdata->supplies);
+}
+
/* waits for MAC not busy, with timeout. Only called by smsc911x_mac_read
* and smsc911x_mac_write, so assumes mac_lock is held */
static int smsc911x_mac_complete(struct smsc911x_data *pdata)
@@ -2092,6 +2168,9 @@ static int __devexit smsc911x_drv_remove(struct platform_device *pdev)
iounmap(pdata->ioaddr);
+ (void)smsc911x_disable_resources(pdev);
+ smsc911x_free_resources(pdev);
+
free_netdev(dev);
return 0;
@@ -2218,10 +2297,20 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
pdata->dev = dev;
pdata->msg_enable = ((1 << debug) - 1);
+ platform_set_drvdata(pdev, dev);
+
+ retval = smsc911x_request_resources(pdev);
+ if (retval)
+ goto out_return_resources;
+
+ retval = smsc911x_enable_resources(pdev);
+ if (retval)
+ goto out_disable_resources;
+
if (pdata->ioaddr = NULL) {
SMSC_WARN(pdata, probe, "Error smsc911x base address invalid");
retval = -ENOMEM;
- goto out_free_netdev_2;
+ goto out_disable_resources;
}
retval = smsc911x_probe_config_dt(&pdata->config, np);
@@ -2233,7 +2322,7 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
if (retval) {
SMSC_WARN(pdata, probe, "Error smsc911x config not found");
- goto out_unmap_io_3;
+ goto out_disable_resources;
}
/* assume standard, non-shifted, access to HW registers */
@@ -2244,7 +2333,7 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
retval = smsc911x_init(dev);
if (retval < 0)
- goto out_unmap_io_3;
+ goto out_disable_resources;
/* configure irq polarity and type before connecting isr */
if (pdata->config.irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_HIGH)
@@ -2264,15 +2353,13 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
if (retval) {
SMSC_WARN(pdata, probe,
"Unable to claim requested irq: %d", dev->irq);
- goto out_unmap_io_3;
+ goto out_free_irq;
}
- platform_set_drvdata(pdev, dev);
-
retval = register_netdev(dev);
if (retval) {
SMSC_WARN(pdata, probe, "Error %i registering device", retval);
- goto out_unset_drvdata_4;
+ goto out_free_irq;
} else {
SMSC_TRACE(pdata, probe,
"Network interface: \"%s\"", dev->name);
@@ -2321,12 +2408,14 @@ static int __devinit smsc911x_drv_probe(struct platform_device *pdev)
out_unregister_netdev_5:
unregister_netdev(dev);
-out_unset_drvdata_4:
- platform_set_drvdata(pdev, NULL);
+out_free_irq:
free_irq(dev->irq, dev);
-out_unmap_io_3:
+out_disable_resources:
+ (void)smsc911x_disable_resources(pdev);
+out_return_resources:
+ smsc911x_free_resources(pdev);
+ platform_set_drvdata(pdev, NULL);
iounmap(pdata->ioaddr);
-out_free_netdev_2:
free_netdev(dev);
out_release_io_1:
release_mem_region(res->start, resource_size(res));
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] ARM: Kota2 mach-type update fix
From: Russell King - ARM Linux @ 2011-11-24 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zkflg999.wl%kuninori.morimoto.gx@renesas.com>
On Thu, Nov 24, 2011 at 01:28:06AM -0800, Kuninori Morimoto wrote:
>
> Hi Paul
>
> > > >> From: Magnus Damm <damm@opensource.se>
> > > >>
> > > >> This patch adds kota2 to the in-kernel ARM mach-type file.
> > > >>
> > > >> Basic board support is included in 3.2-rc and the mach-type
> > > >> has been registered in the ARM machine repository as
> > > >>
> > > >> 3616 Renesas SH-Mobile kota2.x Board kota2 Yusuke Goda mainlined
> > > >>
> > > >> The file arch/arm/tools/mach-types is however missing Kota2
> > > >> which makes build of sh73a0 based boards fail with:
> > > >>
> > > >> arch/arm/mach-shmobile/platsmp.c: In function 'shmobile_smp_get_core_count':
> > > >> arch/arm/mach-shmobile/platsmp.c:28:2: error: implicit declaration of function 'machine_is_kota2'
> > > >> make[1]: *** [arch/arm/mach-shmobile/platsmp.o] Error 1
> > > >>
> > > >> arch/arm/mach-shmobile/board-kota2.c:448:136: error: 'MACH_TYPE_KOTA2' undeclared here (not in a function)
> > > >> make[1]: *** [arch/arm/mach-shmobile/board-kota2.o] Error 1
> > > >> make: *** [arch/arm/mach-shmobile] Error 2
> > > >>
> > > >> Signed-off-by: Magnus Damm <damm@opensource.se>
> > > >> ---
> (snip)
> > > Russell, do you mind if we update the mach-type file to include Kota2?
> > > It's already registered via the web interface.
> > >
> > I'll add it with Russell's Acked-by, otherwise we'll simply have to wait
> > for the next batch of mach-types updates.
>
> Can I add A1 bonito mach-type too?
> I can not find it either
>
>
> 3623 Renesas R-Mobile A1 EVB bonito Kuninori Morimoto
No, because it's not in the kernel source.
^ permalink raw reply
* Re: SH2a Write-back cache issue
From: Andrea Baldini @ 2011-11-24 9:43 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <201111221415.22367.andrea.baldini@spesonline.com>
> In our setup, the problem seems related to an LCD flickering, when the
> cache is setup in read-back mode we had an heavy flickering on the LCD,
> when in write-through it seems much less present, even though not
> completely absent. We tried many different setup for cache and DRAM, but
> found no solutions for it. Of course the problem is present in 2.6.17,
> 2.6.37-38, 3.0 and 3.1 kernels. We found just one situation where the
> flickering is nearly invisible, while reserving 2Mb of frame buffer - so
> placing the fb and the other kernel/code memory far each other. What is
> your problem and setup?
>
> Federico
Hi Federico,
Currently I'm working with a framebuffer on my custom board but the problem I
described occurs in a basic setup too (without frambuffer support and other not
essential stuff).
I found this problem when I was working with the Renesas demo board rsk7203.
I tried some kernels compiled with the board defconfig and a busybox built with
a basic configuration (using a toolchain which creates flat binaries).
With this setup I found that the timer interrupts were missed when executing
the busybox applets and it was very clear especially in shell loop scripts.
With some debug work I saw that the problem was located in the function i
mentioned in the first mail, that is flush_icache_range (you can find it in
cache-sh2a.c) which caused interrupts to be missed during its execution.
The flush_icache_range is called in some points of the kernel and one of them
is in the load_flat_file() which, in my case, is heavy used (having a flat
busybox).
Hope this helps to better understand the issue.
Andrea
--
Andrea Baldini
Elettronica di Processo
SPES. S.c.p.a
Via Lamberto Corsi, 43
60044 Fabriano (AN)
tel. +39 0732 25291
fax +39 0732 2529441
<mailto:andrea.baldini@spesonline.com> andrea.baldini@spesonline.com
<http://www.spesonline.com> www.spesonline.com
^ permalink raw reply
* Re: [PATCH] ARM: Kota2 mach-type update fix
From: Kuninori Morimoto @ 2011-11-24 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111124082342.GD32112@linux-sh.org>
Hi Paul
> > >> From: Magnus Damm <damm@opensource.se>
> > >>
> > >> This patch adds kota2 to the in-kernel ARM mach-type file.
> > >>
> > >> Basic board support is included in 3.2-rc and the mach-type
> > >> has been registered in the ARM machine repository as
> > >>
> > >> 3616 Renesas SH-Mobile kota2.x Board kota2 Yusuke Goda mainlined
> > >>
> > >> The file arch/arm/tools/mach-types is however missing Kota2
> > >> which makes build of sh73a0 based boards fail with:
> > >>
> > >> arch/arm/mach-shmobile/platsmp.c: In function 'shmobile_smp_get_core_count':
> > >> arch/arm/mach-shmobile/platsmp.c:28:2: error: implicit declaration of function 'machine_is_kota2'
> > >> make[1]: *** [arch/arm/mach-shmobile/platsmp.o] Error 1
> > >>
> > >> arch/arm/mach-shmobile/board-kota2.c:448:136: error: 'MACH_TYPE_KOTA2' undeclared here (not in a function)
> > >> make[1]: *** [arch/arm/mach-shmobile/board-kota2.o] Error 1
> > >> make: *** [arch/arm/mach-shmobile] Error 2
> > >>
> > >> Signed-off-by: Magnus Damm <damm@opensource.se>
> > >> ---
(snip)
> > Russell, do you mind if we update the mach-type file to include Kota2?
> > It's already registered via the web interface.
> >
> I'll add it with Russell's Acked-by, otherwise we'll simply have to wait
> for the next batch of mach-types updates.
Can I add A1 bonito mach-type too?
I can not find it either
3623 Renesas R-Mobile A1 EVB bonito Kuninori Morimoto
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: sh-sci CTS problem
From: phil.edworthy @ 2011-11-24 9:19 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <OFB48B001D.3AA44CAE-ON80257950.0037E14A-80257950.0039B579@eu.necel.com>
Hi Paul,
> > Commit 4480a688 is a problem for some devices. For example, on the
SH7203
> > some serial ports have RTS/CTS, but others don't.
> >
> > I guess the right thing to do is add an extra field to struct
> > plat_sci_port to indicate support for RTS/CTS?
> >
> Looking at the data sheets, I think we're probably going to have to do
> something like that, as well as overhaul sci_get/set_mctrl(). There are
> certainly fewer ports that actually support RTS/CTS in hardware than
> those that don't, so the mctrl information is more often than not
> completely bogus.
>
> Could you elaborate what precisely you are encountering as a result of
> the CTS reporting on SH7203? It was initially added as a correctness
> fix to complement the existing RTS reporting, so it would be interesting
> to know what your use case is or what ill effects fell out as a result.
I am not sure if this actually causing any problems at all, this is
probably a wild goose chase. I suspect that enabling RTS/CTS on ports that
don't have these wired up won't change their behaviour.
I am trying to track down an issue with serial that has been around for a
very long time. Actually this work is on SH7264 but the same issues are on
at least SH7201 and SH7203 devices. Receiving data over serial often fails
with framing and overrun errors. I fixed a few things locally, such as the
multiplexed isr doesn't check that the interrupt source was an overrun,
and the overrun handling needs some tweaking. However these are just
addressing the symptoms, not the cause.
Phil
^ permalink raw reply
* Re: sh-sci CTS problem
From: Paul Mundt @ 2011-11-24 9:03 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <OFB48B001D.3AA44CAE-ON80257950.0037E14A-80257950.0039B579@eu.necel.com>
On Tue, Nov 22, 2011 at 10:32:41AM +0000, phil.edworthy@renesas.com wrote:
> Hi Yoshii-san, Paul,
>
> Commit 4480a688 is a problem for some devices. For example, on the SH7203
> some serial ports have RTS/CTS, but others don't.
>
> I guess the right thing to do is add an extra field to struct
> plat_sci_port to indicate support for RTS/CTS?
>
Looking at the data sheets, I think we're probably going to have to do
something like that, as well as overhaul sci_get/set_mctrl(). There are
certainly fewer ports that actually support RTS/CTS in hardware than
those that don't, so the mctrl information is more often than not
completely bogus.
Could you elaborate what precisely you are encountering as a result of
the CTS reporting on SH7203? It was initially added as a correctness
fix to complement the existing RTS reporting, so it would be interesting
to know what your use case is or what ill effects fell out as a result.
^ permalink raw reply
* Re: [PATCH] ARM: mach-shmobile: Kota2 PINT fix
From: Paul Mundt @ 2011-11-24 8:36 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <20111122061557.30983.75780.sendpatchset@w520>
On Tue, Nov 22, 2011 at 03:15:57PM +0900, Magnus Damm wrote:
> Support PINT on sh73a0 and Kota2 using INTC PINT macros.
>
> With this patch applied the Kota2 ethernet is handled
> through one of the chained sh73a0 PINT interrupt controllers.
>
> sh73a0 PINT support is included in 3.2-rc but the Kota2 board
> code does not make use of this shared code base without this
> patch. Without this patch kota2 on-board ethernet is broken.
On Tue, Nov 22, 2011 at 03:23:17PM +0900, Magnus Damm wrote:
> Keep the ZB clock enabled on sh73a0 to allow the BSC
> to access external peripherals hooked up to CS signals.
>
> This is needed to unbreak Ethernet support on sh73a0 boards
> such as AG5EVM and Kota2 together with the following patch:
>
> 794d78f drivers: sh: late disabling of clocks V2
On Tue, Nov 22, 2011 at 03:29:54PM +0900, Magnus Damm wrote:
> Fix IRQ support on the Kota2 board. The sh73a0 and the Kota2
> board make use of the ARM GIC hardware block as main interrupt
> controller. The following commit changed the default behaviour
> for non-device tree platforms and broke Kota2 irq support:
On Tue, Nov 22, 2011 at 03:31:40PM +0900, Magnus Damm wrote:
> Fix IRQ support on the AG5EVM board. The sh73a0 and the AG5EVM
> board make use of the ARM GIC hardware block as main interrupt
> controller. The following commit changed the default behaviour
> for non-device tree platforms and broke AG5EVM irq support:
On Tue, Nov 22, 2011 at 03:44:58PM +0900, Magnus Damm wrote:
> This patch updates the Kota2 board support code to
> use the recently merged TPU LED driver whenever
> possible.
>
> The sh73a0 SoC has 5 TPU hardware blocks each with
> 4 timer channels which in theory allows a total of
> 20 LEDs to be controlled by "leds-renesas-tpu"
> driver instances. The Kota2 board has 4 LEDs connected
> to GPIO pins that also come with TPU pin functions, so
> this patch ties up these 4 LEDS and leaves the remaining
> 3 LEDS for the GPIO based LED driver.
All applied, thanks.
^ permalink raw reply
* Re: [PATCH] ARM: Kota2 mach-type update fix
From: Paul Mundt @ 2011-11-24 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANqRtoTvMpivHN0tZVTEY6SfkBrNLpu=rkRXUXKJG4J0UNCzhg@mail.gmail.com>
On Tue, Nov 22, 2011 at 08:41:57PM +0900, Magnus Damm wrote:
> On Tue, Nov 22, 2011 at 6:26 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> > On Tue, Nov 22, 2011 at 03:08:57PM +0900, Magnus Damm wrote:
> >> From: Magnus Damm <damm@opensource.se>
> >>
> >> This patch adds kota2 to the in-kernel ARM mach-type file.
> >>
> >> Basic board support is included in 3.2-rc and the mach-type
> >> has been registered in the ARM machine repository as
> >>
> >> 3616 Renesas SH-Mobile kota2.x Board kota2 Yusuke Goda mainlined
> >>
> >> The file arch/arm/tools/mach-types is however missing Kota2
> >> which makes build of sh73a0 based boards fail with:
> >>
> >> arch/arm/mach-shmobile/platsmp.c: In function 'shmobile_smp_get_core_count':
> >> arch/arm/mach-shmobile/platsmp.c:28:2: error: implicit declaration of function 'machine_is_kota2'
> >> make[1]: *** [arch/arm/mach-shmobile/platsmp.o] Error 1
> >>
> >> arch/arm/mach-shmobile/board-kota2.c:448:136: error: 'MACH_TYPE_KOTA2' undeclared here (not in a function)
> >> make[1]: *** [arch/arm/mach-shmobile/board-kota2.o] Error 1
> >> make: *** [arch/arm/mach-shmobile] Error 2
> >>
> >> Signed-off-by: Magnus Damm <damm@opensource.se>
> >> ---
> >>
> >> ?I propose that Paul Mundt merges this patch together with other
> >> ?SH-Mobile ARM related fixes.
> >>
> > Err, no. I'm not patching machine-generated files which precisely say not
> > to patch them at the top of the file. If there is a missing definition
> > for an upstream board then the file needs to be regenerated with the new
> > definitions, plain and simple.
>
> Following the comment sure sounds like a good idea, but according to
> the git logs people seem to update the file:
>
> 1d08fd9 Update Nook Color machine 3284 to common Encore name
>
> Russell, do you mind if we update the mach-type file to include Kota2?
> It's already registered via the web interface.
>
I'll add it with Russell's Acked-by, otherwise we'll simply have to wait
for the next batch of mach-types updates.
^ permalink raw reply
* Re: [RFC][PATCH] sh: setup clock parent from current register value
From: Paul Mundt @ 2011-11-24 7:41 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <87ty5wyb51.wl%kuninori.morimoto.gx@renesas.com>
On Mon, Nov 21, 2011 at 09:33:18PM -0800, Kuninori Morimoto wrote:
> Some clocks can select its parent clock by CPG register.
> But it might have been modified by boot-loader or something.
> This patch removed fixed initial parent clock,
> and setup it from their current register settings.
> It works on div6 reparent clocks for now.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Looks good to me, however..
> @@ -190,6 +222,9 @@ static int __init sh_clk_div6_register_ops(struct clk *clks, int nr,
> clkp->ops = ops;
> clkp->freq_table = freq_table + (k * freq_table_size);
> clkp->freq_table[nr_divs].frequency = CPUFREQ_TABLE_END;
> + ret = sh_clk_init_parent(clkp);
> + if (ret < 0)
> + break;
>
> ret = clk_register(clkp);
We are however suffering from some pretty sad looking error path handling
here, but that's not your fault.
I'll apply it to the clkfwk topic branch and then we can start layering
proper error path fixes on top after that. At the moment, almost anything
that's dealing with batched registration fails to clean up after itself.
^ permalink raw reply
* Re: Dreamcast build broken
From: Paul Mundt @ 2011-11-24 7:29 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4EC81660.3010109@gmail.com>
On Tue, Nov 22, 2011 at 01:02:56PM +0100, Paul Cercueil wrote:
> Hi,
>
> The commit which breaks the dreamcast build is the commit
> 37b7a97884ba64bf7d403351ac2a9476ab4f1bba :
> sh: machvec IO death.
>
It builds fine for me. You will actually have to supply the build error
you are experiencing if you expect any further assistance, however.
^ permalink raw reply
* Re: [PATCH 1/2] sh: sh7724.h: bugfix: remove unused clock index
From: Paul Mundt @ 2011-11-24 7:01 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <87y5v8yi8p.wl%kuninori.morimoto.gx@renesas.com>
On Mon, Nov 21, 2011 at 06:59:54PM -0800, Kuninori Morimoto wrote:
> Current sh clocks are using pm_runtime frame work instead of old hwblk.
> So, HWBLK_UNKNOWN and HWBLK_DBG are not needed for now.
>
> Now mstp32 clocks are registered by sh_clk_mstp32_register(),
> but the clock which isn't defined by SH_CLK_MSTP32() macro
> will be crash. because it doesn't have enable_reg.
On Mon, Nov 21, 2011 at 07:00:04PM -0800, Kuninori Morimoto wrote:
> Current sh clocks are using pm_runtime frame work instead of old hwblk.
> So, HWBLK_UNKNOWN, HWBLK_DBG and HWBLK_SUBC are not needed for now.
>
> Now mstp32 clocks are registered by sh_clk_mstp32_register(),
> but the clock which isn't defined by SH_CLK_MSTP32() macro
> will be crash. because it doesn't have enable_reg.
On Wed, Nov 23, 2011 at 10:53:46PM +0100, Guennadi Liakhovetski wrote:
> Unused indices produce empty entries in the clock array, which then lead to
> Oopses at boot-time.
All applied to sh/hwblk, thanks.
^ permalink raw reply
* Re: [PATCH 6/7] ARM: restart: only perform setup for restart when
From: Lennert Buytenhek @ 2011-11-24 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111117174247.GF9581@n2100.arm.linux.org.uk>
On Thu, Nov 17, 2011 at 05:42:47PM +0000, Russell King - ARM Linux wrote:
> Ack?
>
> (If you're in the To: list I'm expecting a reply because this patch is
> touching something you're responsible for. Thanks.)
>
> On Sun, Nov 06, 2011 at 05:33:35PM +0000, Russell King - ARM Linux wrote:
> > We only need to set the system up for a soft-restart if we're going to
> > be doing a soft-restart. Provide a new function (soft_restart()) which
> > does the setup and final call for this, and make platforms use it.
> > Eliminate the call to setup_restart() from the default handler.
> >
> > This means that platforms arch_reset() function is no longer called with
> > the page tables prepared for a soft-restart, and caches will still be
> > enabled.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
^ permalink raw reply
* [Update 3x][PATCH 3/7] PM / Domains: Rework system suspend callback routines (v2)
From: Rafael J. Wysocki @ 2011-11-24 0:20 UTC (permalink / raw)
To: Linux PM list
Cc: LKML, Linux-sh list, Magnus Damm, Guennadi Liakhovetski,
Kevin Hilman, jean.pihet
In-Reply-To: <201111191459.46620.rjw@sisk.pl>
From: Rafael J. Wysocki <rjw@sisk.pl>
The current generic PM domains code attempts to use the generic
system suspend operations along with the domains' device stop/start
routines, which requires device drivers to assume that their
system suspend/resume (and hibernation/restore) callbacks will always
be used with generic PM domains. However, in theory, the same
hardware may be used in devices that don't belong to any PM domain,
in which case it would be necessary to add "fake" PM domains to
satisfy the above assumption. Also, the domain the hardware belongs
to may not be handled with the help of the generic code.
To allow device drivers that may be used along with the generic PM
domains code of more flexibility, add new device callbacks,
.suspend(), .suspend_late(), .resume_early(), .resume(), .freeze(),
.freeze_late(), .thaw_early(), and .thaw(), that can be supplied by
the drivers in addition to their "standard" system suspend and
hibernation callbacks. These new callbacks, if defined, will be used
by the generic PM domains code for the handling of system suspend and
hibernation instead of the "standard" ones. This will allow drivers
to be designed to work with generic PM domains as well as without
them.
For backwards compatibility, introduce default implementations of the
new callbacks for PM domains that will execute pm_generic_suspend(),
pm_generic_suspend_noirq(), pm_generic_resume_noirq(),
pm_generic_resume(), pm_generic_freeze(), pm_generic_freeze_noirq(),
pm_generic_thaw_noirq(), and pm_generic_thaw(), respectively, for the
given device if its driver doesn't define those callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
When I started to work on documentation updates, I realized that
.freeze()/.thaw() callbacks (and their late/early versions) couldn't
be used as .suspend()/.resume() for two reasons. First, for some
devices .suspend() has to make wakeup preparations, while .freeze()
need not (and even shouldn't) do that. Second, .resume() ususally
has to restore the device's state from memory, while .thaw() need
not (and even shouldn't) do that. Therefore, a complete set of
suspend/resume _and_ freeze/thaw device callbacks for PM domains
is needed.
Thanks,
Rafael
---
drivers/base/power/domain.c | 249 ++++++++++++++++++++++++++------------------
include/linux/pm_domain.h | 8 +
2 files changed, 158 insertions(+), 99 deletions(-)
Index: linux/include/linux/pm_domain.h
=================================--- linux.orig/include/linux/pm_domain.h
+++ linux/include/linux/pm_domain.h
@@ -28,6 +28,14 @@ struct gpd_dev_ops {
int (*stop)(struct device *dev);
int (*save_state)(struct device *dev);
int (*restore_state)(struct device *dev);
+ int (*suspend)(struct device *dev);
+ int (*suspend_late)(struct device *dev);
+ int (*resume_early)(struct device *dev);
+ int (*resume)(struct device *dev);
+ int (*freeze)(struct device *dev);
+ int (*freeze_late)(struct device *dev);
+ int (*thaw_early)(struct device *dev);
+ int (*thaw)(struct device *dev);
bool (*active_wakeup)(struct device *dev);
};
Index: linux/drivers/base/power/domain.c
=================================--- linux.orig/drivers/base/power/domain.c
+++ linux/drivers/base/power/domain.c
@@ -561,6 +561,46 @@ static bool genpd_dev_active_wakeup(stru
return GENPD_DEV_CALLBACK(genpd, bool, active_wakeup, dev);
}
+static int genpd_suspend_dev(struct generic_pm_domain *genpd, struct device *dev)
+{
+ return GENPD_DEV_CALLBACK(genpd, int, suspend, dev);
+}
+
+static int genpd_suspend_late(struct generic_pm_domain *genpd, struct device *dev)
+{
+ return GENPD_DEV_CALLBACK(genpd, int, suspend_late, dev);
+}
+
+static int genpd_resume_early(struct generic_pm_domain *genpd, struct device *dev)
+{
+ return GENPD_DEV_CALLBACK(genpd, int, resume_early, dev);
+}
+
+static int genpd_resume_dev(struct generic_pm_domain *genpd, struct device *dev)
+{
+ return GENPD_DEV_CALLBACK(genpd, int, resume, dev);
+}
+
+static int genpd_freeze_dev(struct generic_pm_domain *genpd, struct device *dev)
+{
+ return GENPD_DEV_CALLBACK(genpd, int, freeze, dev);
+}
+
+static int genpd_freeze_late(struct generic_pm_domain *genpd, struct device *dev)
+{
+ return GENPD_DEV_CALLBACK(genpd, int, freeze_late, dev);
+}
+
+static int genpd_thaw_early(struct generic_pm_domain *genpd, struct device *dev)
+{
+ return GENPD_DEV_CALLBACK(genpd, int, thaw_early, dev);
+}
+
+static int genpd_thaw_dev(struct generic_pm_domain *genpd, struct device *dev)
+{
+ return GENPD_DEV_CALLBACK(genpd, int, thaw, dev);
+}
+
/**
* pm_genpd_sync_poweroff - Synchronously power off a PM domain and its masters.
* @genpd: PM domain to power off, if possible.
@@ -712,7 +752,7 @@ static int pm_genpd_suspend(struct devic
if (IS_ERR(genpd))
return -EINVAL;
- return genpd->suspend_power_off ? 0 : pm_generic_suspend(dev);
+ return genpd->suspend_power_off ? 0 : genpd_suspend_dev(genpd, dev);
}
/**
@@ -737,7 +777,7 @@ static int pm_genpd_suspend_noirq(struct
if (genpd->suspend_power_off)
return 0;
- ret = pm_generic_suspend_noirq(dev);
+ ret = genpd_suspend_late(genpd, dev);
if (ret)
return ret;
@@ -788,7 +828,7 @@ static int pm_genpd_resume_noirq(struct
genpd->suspended_count--;
genpd_start_dev(genpd, dev);
- return pm_generic_resume_noirq(dev);
+ return genpd_resume_early(genpd, dev);
}
/**
@@ -809,7 +849,7 @@ static int pm_genpd_resume(struct device
if (IS_ERR(genpd))
return -EINVAL;
- return genpd->suspend_power_off ? 0 : pm_generic_resume(dev);
+ return genpd->suspend_power_off ? 0 : genpd_resume_dev(genpd, dev);
}
/**
@@ -830,7 +870,7 @@ static int pm_genpd_freeze(struct device
if (IS_ERR(genpd))
return -EINVAL;
- return genpd->suspend_power_off ? 0 : pm_generic_freeze(dev);
+ return genpd->suspend_power_off ? 0 : genpd_freeze_dev(genpd, dev);
}
/**
@@ -856,7 +896,7 @@ static int pm_genpd_freeze_noirq(struct
if (genpd->suspend_power_off)
return 0;
- ret = pm_generic_freeze_noirq(dev);
+ ret = genpd_freeze_late(genpd, dev);
if (ret)
return ret;
@@ -889,7 +929,7 @@ static int pm_genpd_thaw_noirq(struct de
genpd_start_dev(genpd, dev);
- return pm_generic_thaw_noirq(dev);
+ return genpd_thaw_early(genpd, dev);
}
/**
@@ -910,70 +950,7 @@ static int pm_genpd_thaw(struct device *
if (IS_ERR(genpd))
return -EINVAL;
- return genpd->suspend_power_off ? 0 : pm_generic_thaw(dev);
-}
-
-/**
- * pm_genpd_dev_poweroff - Power off a device belonging to an I/O PM domain.
- * @dev: Device to suspend.
- *
- * Power off a device under the assumption that its pm_domain field points to
- * the domain member of an object of type struct generic_pm_domain representing
- * a PM domain consisting of I/O devices.
- */
-static int pm_genpd_dev_poweroff(struct device *dev)
-{
- struct generic_pm_domain *genpd;
-
- dev_dbg(dev, "%s()\n", __func__);
-
- genpd = dev_to_genpd(dev);
- if (IS_ERR(genpd))
- return -EINVAL;
-
- return genpd->suspend_power_off ? 0 : pm_generic_poweroff(dev);
-}
-
-/**
- * pm_genpd_dev_poweroff_noirq - Late power off of a device from a PM domain.
- * @dev: Device to suspend.
- *
- * Carry out a late powering off of a device under the assumption that its
- * pm_domain field points to the domain member of an object of type
- * struct generic_pm_domain representing a PM domain consisting of I/O devices.
- */
-static int pm_genpd_dev_poweroff_noirq(struct device *dev)
-{
- struct generic_pm_domain *genpd;
- int ret;
-
- dev_dbg(dev, "%s()\n", __func__);
-
- genpd = dev_to_genpd(dev);
- if (IS_ERR(genpd))
- return -EINVAL;
-
- if (genpd->suspend_power_off)
- return 0;
-
- ret = pm_generic_poweroff_noirq(dev);
- if (ret)
- return ret;
-
- if (dev->power.wakeup_path && genpd_dev_active_wakeup(genpd, dev))
- return 0;
-
- genpd_stop_dev(genpd, dev);
-
- /*
- * Since all of the "noirq" callbacks are executed sequentially, it is
- * guaranteed that this function will never run twice in parallel for
- * the same PM domain, so it is not necessary to use locking here.
- */
- genpd->suspended_count++;
- pm_genpd_sync_poweroff(genpd);
-
- return 0;
+ return genpd->suspend_power_off ? 0 : genpd_thaw_dev(genpd, dev);
}
/**
@@ -1015,28 +992,7 @@ static int pm_genpd_restore_noirq(struct
genpd->suspended_count--;
genpd_start_dev(genpd, dev);
- return pm_generic_restore_noirq(dev);
-}
-
-/**
- * pm_genpd_restore - Restore a device belonging to an I/O power domain.
- * @dev: Device to resume.
- *
- * Restore a device under the assumption that its pm_domain field points to the
- * domain member of an object of type struct generic_pm_domain representing
- * a power domain consisting of I/O devices.
- */
-static int pm_genpd_restore(struct device *dev)
-{
- struct generic_pm_domain *genpd;
-
- dev_dbg(dev, "%s()\n", __func__);
-
- genpd = dev_to_genpd(dev);
- if (IS_ERR(genpd))
- return -EINVAL;
-
- return genpd->suspend_power_off ? 0 : pm_generic_restore(dev);
+ return genpd_resume_early(genpd, dev);
}
/**
@@ -1086,10 +1042,7 @@ static void pm_genpd_complete(struct dev
#define pm_genpd_freeze_noirq NULL
#define pm_genpd_thaw_noirq NULL
#define pm_genpd_thaw NULL
-#define pm_genpd_dev_poweroff_noirq NULL
-#define pm_genpd_dev_poweroff NULL
#define pm_genpd_restore_noirq NULL
-#define pm_genpd_restore NULL
#define pm_genpd_complete NULL
#endif /* CONFIG_PM_SLEEP */
@@ -1361,6 +1314,8 @@ int pm_genpd_remove_callbacks(struct dev
}
EXPORT_SYMBOL_GPL(pm_genpd_remove_callbacks);
+/* Default device callbacks for generic PM domains. */
+
/**
* pm_genpd_default_save_state - Default "save device state" for PM domians.
* @dev: Device to handle.
@@ -1400,6 +1355,94 @@ static int pm_genpd_default_restore_stat
}
/**
+ * pm_genpd_default_suspend - Default "device suspend" for PM domians.
+ * @dev: Device to handle.
+ */
+static int pm_genpd_default_suspend(struct device *dev)
+{
+ int (*cb)(struct device *__dev) = dev_gpd_data(dev)->ops.freeze;
+
+ return cb ? cb(dev) : pm_generic_suspend(dev);
+}
+
+/**
+ * pm_genpd_default_suspend_late - Default "late device suspend" for PM domians.
+ * @dev: Device to handle.
+ */
+static int pm_genpd_default_suspend_late(struct device *dev)
+{
+ int (*cb)(struct device *__dev) = dev_gpd_data(dev)->ops.freeze_late;
+
+ return cb ? cb(dev) : pm_generic_suspend_noirq(dev);
+}
+
+/**
+ * pm_genpd_default_resume_early - Default "early device resume" for PM domians.
+ * @dev: Device to handle.
+ */
+static int pm_genpd_default_resume_early(struct device *dev)
+{
+ int (*cb)(struct device *__dev) = dev_gpd_data(dev)->ops.thaw_early;
+
+ return cb ? cb(dev) : pm_generic_resume_noirq(dev);
+}
+
+/**
+ * pm_genpd_default_resume - Default "device resume" for PM domians.
+ * @dev: Device to handle.
+ */
+static int pm_genpd_default_resume(struct device *dev)
+{
+ int (*cb)(struct device *__dev) = dev_gpd_data(dev)->ops.thaw;
+
+ return cb ? cb(dev) : pm_generic_resume(dev);
+}
+
+/**
+ * pm_genpd_default_freeze - Default "device freeze" for PM domians.
+ * @dev: Device to handle.
+ */
+static int pm_genpd_default_freeze(struct device *dev)
+{
+ int (*cb)(struct device *__dev) = dev_gpd_data(dev)->ops.freeze;
+
+ return cb ? cb(dev) : pm_generic_freeze(dev);
+}
+
+/**
+ * pm_genpd_default_freeze_late - Default "late device freeze" for PM domians.
+ * @dev: Device to handle.
+ */
+static int pm_genpd_default_freeze_late(struct device *dev)
+{
+ int (*cb)(struct device *__dev) = dev_gpd_data(dev)->ops.freeze_late;
+
+ return cb ? cb(dev) : pm_generic_freeze_noirq(dev);
+}
+
+/**
+ * pm_genpd_default_thaw_early - Default "early device thaw" for PM domians.
+ * @dev: Device to handle.
+ */
+static int pm_genpd_default_thaw_early(struct device *dev)
+{
+ int (*cb)(struct device *__dev) = dev_gpd_data(dev)->ops.thaw_early;
+
+ return cb ? cb(dev) : pm_generic_thaw_noirq(dev);
+}
+
+/**
+ * pm_genpd_default_thaw - Default "device thaw" for PM domians.
+ * @dev: Device to handle.
+ */
+static int pm_genpd_default_thaw(struct device *dev)
+{
+ int (*cb)(struct device *__dev) = dev_gpd_data(dev)->ops.thaw;
+
+ return cb ? cb(dev) : pm_generic_thaw(dev);
+}
+
+/**
* pm_genpd_init - Initialize a generic I/O PM domain object.
* @genpd: PM domain object to initialize.
* @gov: PM domain governor to associate with the domain (may be NULL).
@@ -1437,13 +1480,21 @@ void pm_genpd_init(struct generic_pm_dom
genpd->domain.ops.freeze_noirq = pm_genpd_freeze_noirq;
genpd->domain.ops.thaw_noirq = pm_genpd_thaw_noirq;
genpd->domain.ops.thaw = pm_genpd_thaw;
- genpd->domain.ops.poweroff = pm_genpd_dev_poweroff;
- genpd->domain.ops.poweroff_noirq = pm_genpd_dev_poweroff_noirq;
+ genpd->domain.ops.poweroff = pm_genpd_suspend;
+ genpd->domain.ops.poweroff_noirq = pm_genpd_suspend_noirq;
genpd->domain.ops.restore_noirq = pm_genpd_restore_noirq;
- genpd->domain.ops.restore = pm_genpd_restore;
+ genpd->domain.ops.restore = pm_genpd_resume;
genpd->domain.ops.complete = pm_genpd_complete;
genpd->dev_ops.save_state = pm_genpd_default_save_state;
genpd->dev_ops.restore_state = pm_genpd_default_restore_state;
+ genpd->dev_ops.freeze = pm_genpd_default_suspend;
+ genpd->dev_ops.freeze_late = pm_genpd_default_suspend_late;
+ genpd->dev_ops.thaw_early = pm_genpd_default_resume_early;
+ genpd->dev_ops.thaw = pm_genpd_default_resume;
+ genpd->dev_ops.freeze = pm_genpd_default_freeze;
+ genpd->dev_ops.freeze_late = pm_genpd_default_freeze_late;
+ genpd->dev_ops.thaw_early = pm_genpd_default_thaw_early;
+ genpd->dev_ops.thaw = pm_genpd_default_thaw;
mutex_lock(&gpd_list_lock);
list_add(&genpd->gpd_list_node, &gpd_list);
mutex_unlock(&gpd_list_lock);
^ permalink raw reply
* [PATCH] sh: sh7722: fix Oops: remove empty clock entries
From: Guennadi Liakhovetski @ 2011-11-23 21:53 UTC (permalink / raw)
To: linux-sh
Unused indices produce empty entries in the clock array, which then lead to
Oopses at boot-time.
Reported-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
This is against sh-latest with hwblk patches from sh/hwblk applied on top.
Morimoto-san, you were right, I was able to reproduce a hang on ecovec,
and your patch fixes it - thanks! Here goes a similar one for sh7722 -
tested on migor.
Thanks
Guennadi
arch/sh/include/cpu-sh4/cpu/sh7722.h | 13 +++++--------
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/sh/include/cpu-sh4/cpu/sh7722.h b/arch/sh/include/cpu-sh4/cpu/sh7722.h
index bd06227..3bb74e5 100644
--- a/arch/sh/include/cpu-sh4/cpu/sh7722.h
+++ b/arch/sh/include/cpu-sh4/cpu/sh7722.h
@@ -222,14 +222,11 @@ enum {
};
enum {
- HWBLK_UNKNOWN = 0,
- HWBLK_TLB, HWBLK_IC, HWBLK_OC, HWBLK_URAM, HWBLK_XYMEM,
- HWBLK_INTC, HWBLK_DMAC, HWBLK_SHYWAY, HWBLK_HUDI,
- HWBLK_UBC, HWBLK_TMU, HWBLK_CMT, HWBLK_RWDT, HWBLK_FLCTL,
- HWBLK_SCIF0, HWBLK_SCIF1, HWBLK_SCIF2, HWBLK_SIO,
- HWBLK_SIOF0, HWBLK_SIOF1, HWBLK_IIC, HWBLK_RTC,
- HWBLK_TPU, HWBLK_IRDA, HWBLK_SDHI, HWBLK_SIM, HWBLK_KEYSC,
- HWBLK_TSIF, HWBLK_USBF, HWBLK_2DG, HWBLK_SIU, HWBLK_VOU,
+ HWBLK_URAM, HWBLK_XYMEM,
+ HWBLK_TMU, HWBLK_CMT, HWBLK_RWDT, HWBLK_FLCTL,
+ HWBLK_SCIF0, HWBLK_SCIF1, HWBLK_SCIF2, HWBLK_IIC, HWBLK_RTC,
+ HWBLK_SDHI, HWBLK_KEYSC,
+ HWBLK_USBF, HWBLK_2DG, HWBLK_SIU, HWBLK_VOU,
HWBLK_JPU, HWBLK_BEU, HWBLK_CEU, HWBLK_VEU, HWBLK_VPU,
HWBLK_LCDC,
HWBLK_NR,
--
1.7.2.5
^ permalink raw reply related
* [PATCH] mmc: sh_mmcif: simplify clock divisor calculation
From: Guennadi Liakhovetski @ 2011-11-23 14:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: Andrei Warkentin, linux-mmc, linux-sh, Chris Ball
In-Reply-To: <20111117150549.15528e81.akpm@linux-foundation.org>
Replace ilog2(__rounddown_pow_of_two(x)) with the equivalent but much
simpler fls(x) - 1.
Reported-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
drivers/mmc/host/sh_mmcif.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index c021482..824fee5 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -16,6 +16,7 @@
*
*/
+#include <linux/bitops.h>
#include <linux/clk.h>
#include <linux/completion.h>
#include <linux/delay.h>
@@ -386,7 +387,7 @@ static void sh_mmcif_clock_control(struct sh_mmcif_host *host, unsigned int clk)
sh_mmcif_bitset(host, MMCIF_CE_CLK_CTRL, CLK_SUP_PCLK);
else
sh_mmcif_bitset(host, MMCIF_CE_CLK_CTRL, CLK_CLEAR &
- (ilog2(__rounddown_pow_of_two(host->clk / clk)) << 16));
+ ((fls(host->clk / clk) - 1) << 16));
sh_mmcif_bitset(host, MMCIF_CE_CLK_CTRL, CLK_ENABLE);
}
--
1.7.2.5
^ permalink raw reply related
* Re: SH2a Write-back cache issue
From: Federico Fuga @ 2011-11-23 11:01 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <201111221415.22367.andrea.baldini@spesonline.com>
Hi Andrea,
I've been working with Fabio on a similar issue.
Il giorno 23/nov/2011, alle ore 11.52, Andrea Baldini ha scritto:
> I have just successfully booted the lastest git kernel (thanks to Phil for the
> ioread/iowrite big endian fix) but it seems that the write back cache problem
> occurs in the 3.2.0-rc2 too.
In our setup, the problem seems related to an LCD flickering, when the cache is setup in read-back mode we had an heavy flickering on the LCD, when in write-through it seems much less present, even though not completely absent.
We tried many different setup for cache and DRAM, but found no solutions for it.
Of course the problem is present in 2.6.17, 2.6.37-38, 3.0 and 3.1 kernels.
We found just one situation where the flickering is nearly invisible, while reserving 2Mb of frame buffer - so placing the fb and the other kernel/code memory far each other.
What is your problem and setup?
Federico
^ permalink raw reply
* Re: SH2a Write-back cache issue
From: Andrea Baldini @ 2011-11-23 10:52 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <201111221415.22367.andrea.baldini@spesonline.com>
> Hi Federico, I think you could help Andrea about this issue.
> Regard
>
Thanks Fabio.
I have just successfully booted the lastest git kernel (thanks to Phil for the
ioread/iowrite big endian fix) but it seems that the write back cache problem
occurs in the 3.2.0-rc2 too.
--
Andrea Baldini
Elettronica di Processo
SPES. S.c.p.a
Via Lamberto Corsi, 43
60044 Fabriano (AN)
tel. +39 0732 25291
fax +39 0732 2529441
<mailto:andrea.baldini@spesonline.com> andrea.baldini@spesonline.com
<http://www.spesonline.com> www.spesonline.com
^ permalink raw reply
* Re: [PATCH] PM: fix compile breakage on sh #ifndef CONFIG_PM_RUNTIME
From: Rafael J. Wysocki @ 2011-11-22 23:42 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <Pine.LNX.4.64.1111211642200.10414@axis700.grange>
On Tuesday, November 22, 2011, Guennadi Liakhovetski wrote:
> On Tue, 22 Nov 2011, Rafael J. Wysocki wrote:
>
> > On Monday, November 21, 2011, Guennadi Liakhovetski wrote:
> > > Fix the following compalitaion breakage:
> > >
> > > In file included from linux/drivers/sh/pm_runtime.c:15:
> > > linux/include/linux/pm_domain.h: In function 'dev_to_genpd':
> > > linux/include/linux/pm_domain.h:142: error: implicit declaration of function 'ERR_PTR'
> > > linux/include/linux/pm_domain.h:142: warning: return makes pointer from integer without a cast
> > > In file included from linux/include/linux/sh_clk.h:10,
> > > from linux/drivers/sh/pm_runtime.c:19:
> > > linux/include/linux/err.h: At top level:
> > > linux/include/linux/err.h:22: error: conflicting types for 'ERR_PTR'
> > > linux/include/linux/pm_domain.h:142: note: previous implicit declaration of 'ERR_PTR' was here
> > > make[3]: *** [drivers/sh/pm_runtime.o] Error 1
> > >
> > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > > ---
> > > diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> > > index 765083ad..b931682 100644
> > > --- a/include/linux/pm_domain.h
> > > +++ b/include/linux/pm_domain.h
> > > @@ -10,6 +10,7 @@
> > > #define _LINUX_PM_DOMAIN_H
> > >
> > > #include <linux/device.h>
> > > +#include <linux/err.h>
> > >
> > > enum gpd_status {
> > > GPD_STATE_ACTIVE = 0, /* PM domain is active */
> >
> > That new #include is only necessary if CONFIG_PM_GENERIC_DOMAINS is unset, right?
>
> Yes, I think so.
Can you respin the patch with that in mind, please?
Rafael
^ permalink raw reply
* Re: [PATCH] PM: fix compile breakage on sh #ifndef CONFIG_PM_RUNTIME
From: Guennadi Liakhovetski @ 2011-11-22 22:27 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <Pine.LNX.4.64.1111211642200.10414@axis700.grange>
On Tue, 22 Nov 2011, Rafael J. Wysocki wrote:
> On Monday, November 21, 2011, Guennadi Liakhovetski wrote:
> > Fix the following compalitaion breakage:
> >
> > In file included from linux/drivers/sh/pm_runtime.c:15:
> > linux/include/linux/pm_domain.h: In function 'dev_to_genpd':
> > linux/include/linux/pm_domain.h:142: error: implicit declaration of function 'ERR_PTR'
> > linux/include/linux/pm_domain.h:142: warning: return makes pointer from integer without a cast
> > In file included from linux/include/linux/sh_clk.h:10,
> > from linux/drivers/sh/pm_runtime.c:19:
> > linux/include/linux/err.h: At top level:
> > linux/include/linux/err.h:22: error: conflicting types for 'ERR_PTR'
> > linux/include/linux/pm_domain.h:142: note: previous implicit declaration of 'ERR_PTR' was here
> > make[3]: *** [drivers/sh/pm_runtime.o] Error 1
> >
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > ---
> > diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> > index 765083ad..b931682 100644
> > --- a/include/linux/pm_domain.h
> > +++ b/include/linux/pm_domain.h
> > @@ -10,6 +10,7 @@
> > #define _LINUX_PM_DOMAIN_H
> >
> > #include <linux/device.h>
> > +#include <linux/err.h>
> >
> > enum gpd_status {
> > GPD_STATE_ACTIVE = 0, /* PM domain is active */
>
> That new #include is only necessary if CONFIG_PM_GENERIC_DOMAINS is unset, right?
Yes, I think so.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH] PM: fix compile breakage on sh #ifndef CONFIG_PM_RUNTIME
From: Rafael J. Wysocki @ 2011-11-22 22:25 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <Pine.LNX.4.64.1111211642200.10414@axis700.grange>
On Monday, November 21, 2011, Guennadi Liakhovetski wrote:
> Fix the following compalitaion breakage:
>
> In file included from linux/drivers/sh/pm_runtime.c:15:
> linux/include/linux/pm_domain.h: In function 'dev_to_genpd':
> linux/include/linux/pm_domain.h:142: error: implicit declaration of function 'ERR_PTR'
> linux/include/linux/pm_domain.h:142: warning: return makes pointer from integer without a cast
> In file included from linux/include/linux/sh_clk.h:10,
> from linux/drivers/sh/pm_runtime.c:19:
> linux/include/linux/err.h: At top level:
> linux/include/linux/err.h:22: error: conflicting types for 'ERR_PTR'
> linux/include/linux/pm_domain.h:142: note: previous implicit declaration of 'ERR_PTR' was here
> make[3]: *** [drivers/sh/pm_runtime.o] Error 1
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index 765083ad..b931682 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -10,6 +10,7 @@
> #define _LINUX_PM_DOMAIN_H
>
> #include <linux/device.h>
> +#include <linux/err.h>
>
> enum gpd_status {
> GPD_STATE_ACTIVE = 0, /* PM domain is active */
That new #include is only necessary if CONFIG_PM_GENERIC_DOMAINS is unset, right?
Rafael
^ permalink raw reply
* Re: SH2a Write-back cache issue
From: Fabio Giovagnini @ 2011-11-22 14:21 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <201111221415.22367.andrea.baldini@spesonline.com>
Hi Federico, I think you could help Andrea about this issue.
Regard
Il giorno mar, 22/11/2011 alle 14.15 +0100, Andrea Baldini ha scritto:
> Hi,
>
> I'm working on a sh7203 board and I'm currently using a 2.6.28 kernel with a
> write-back cache mode configuration.
> When this configuration is set I got some issues when the flush_icache_range is
> involved.
>
> /* O-Cache writeback */
> for (way = 0; way < 4; way++) {
> unsigned long data = ctrl_inl(CACHE_OC_ADDRESS_ARRAY | addr | (way << 11));
> if ((data & CACHE_PHYSADDR_MASK) = (v & CACHE_PHYSADDR_MASK)) {
> data &= ~SH_CACHE_UPDATED;
> ctrl_outl(data, CACHE_OC_ADDRESS_ARRAY | addr | (way << 11));
> }
> }
>
> When the O-cache writeback is performed all system interrupts are missed,
> including the timer one.
> This occurs, for instance, when a flat binary is loaded in memory (
> load_flat_file() ) or when a signal is handled ( when setting up a frame ).
>
> This is an unacceptable behaviour for the system.
> A workaround is setting a write-through configuration to the kernel and flushing
> just the instruction cache entries.
>
> I've seen the recent kernel releases but it seems this part hasn't been
> modified yet.
> Anyway i tried a 2.6.35 kernel version some time ago and i got the same
> problems.
>
> Is anybody here working on this issue?
> Is it possible to use the write-back configuration?
>
> Regards
>
> Andrea
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Fabio Giovagnini
Aurion s.r.l.
P.iva 00885711200
cell. +39.335.8350919
Tel. +39 051.082.69.65
Fax. +39 051.082.14.49
skype: aurion.giovagnini
^ 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