* 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
* Re: [PATCH] ARM: mach-shmobile: AG5EVM GIC Sparse IRQ fix
From: Rob Herring @ 2011-11-22 14:12 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <20111122063140.31045.57736.sendpatchset@w520>
On 11/22/2011 12:31 AM, Magnus Damm wrote:
> From: Magnus Damm <damm@opensource.se>
>
> 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:
>
> f37a53c ARM: gic: fix irq_alloc_descs handling for sparse irq
>
> Without this fix the following warning triggers at boot:
>
> NR_IRQS:1024 nr_irqs:1024 1024
> ------------[ cut here ]------------
> WARNING: at arch/arm/common/gic.c:607 gic_init+0x90/0x2e4()
> Cannot allocate irq_descs @ IRQ16, assuming pre-allocated
> [<c000c868>] (unwind_backtrace+0x0/0xe0) from [<c001857c>] (warn_slowpath_commo)
> [<c001857c>] (warn_slowpath_common+0x48/0x60) from [<c00185d8>] (warn_slowpath_)
> [<c00185d8>] (warn_slowpath_fmt+0x2c/0x3c) from [<c029ee08>] (gic_init+0x90/0x2)
> [<c029ee08>] (gic_init+0x90/0x2e4) from [<c029f278>] (sh73a0_init_irq+0x30/0x18)
> [<c029f278>] (sh73a0_init_irq+0x30/0x184) from [<c029c0b4>] (init_IRQ+0x14/0x1c)
> [<c029c0b4>] (init_IRQ+0x14/0x1c) from [<c029a5cc>] (start_kernel+0x15c/0x2b8)
> [<c029a5cc>] (start_kernel+0x15c/0x2b8) from [<4000803c>] (0x4000803c)
> ---[ end trace 1b75b31a2719ed1c ]---
>
> With this fix applied interrupts work as expected.
>
They work without the fix as well, right?
> Signed-off-by: Magnus Damm <damm@opensource.se>
> ---
For both patches:
Acked-by: Rob Herring <rob.herring@calxeda.com>
>
> arch/arm/mach-shmobile/board-ag5evm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> --- 0001/arch/arm/mach-shmobile/board-ag5evm.c
> +++ work/arch/arm/mach-shmobile/board-ag5evm.c 2011-11-17 18:35:51.000000000 +0900
> @@ -607,6 +607,7 @@ struct sys_timer ag5evm_timer = {
>
> MACHINE_START(AG5EVM, "ag5evm")
> .map_io = ag5evm_map_io,
> + .nr_irqs = NR_IRQS_LEGACY,
> .init_irq = sh73a0_init_irq,
> .handle_irq = shmobile_handle_irq_gic,
> .init_machine = ag5evm_init,
^ permalink raw reply
* SH2a Write-back cache issue
From: Andrea Baldini @ 2011-11-22 13:15 UTC (permalink / raw)
To: linux-sh
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
^ permalink raw reply
* Re: Dreamcast build broken
From: Paul Cercueil @ 2011-11-22 12:02 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4EC81660.3010109@gmail.com>
Hi,
The commit which breaks the dreamcast build is the commit
37b7a97884ba64bf7d403351ac2a9476ab4f1bba :
sh: machvec IO death.
Regards,
Paul
^ permalink raw reply
* Re: [PATCH] ARM: Kota2 mach-type update fix
From: Magnus Damm @ 2011-11-22 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111122092615.GA26411@linux-sh.org>
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.
Cheers,
/ magnus
^ permalink raw reply
* sh-sci CTS problem
From: phil.edworthy @ 2011-11-22 10:32 UTC (permalink / raw)
To: linux-sh
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?
Phil
^ permalink raw reply
* Re: [PATCH] ARM: Kota2 mach-type update fix
From: Paul Mundt @ 2011-11-22 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111122060857.23951.50598.sendpatchset@w520>
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.
^ permalink raw reply
* Re: [PATCH 0/2] sh: bugfix: sh7724/sh7723 boot on paul/hwblk
From: kuninori.morimoto.gx @ 2011-11-22 9:04 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <87zkfoyi9l.wl%kuninori.morimoto.gx@renesas.com>
[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]
Hi Guennadi
Thank you for your reply
> > Kuninori Morimoto (2):
> > sh: sh7724.h: bugfix: remove unused clock index
> > sh: sh7723.h: bugfix: remove unused clock index
> >
> > Now it doesn't use hwblk, but it still have un-needed HWBLK_xxx index
> > which are not set by SH_CLK_MSTP32() macro.
> > So, sh7724/sh7723 boot will be crash, because clk.enable_reg == NULL on such clocks.
>
> Thanks for the patches! It is certainly good to remove unused code / data,
> but could you please explain a bit what exactly crashes you observed and
> how you triggered them? I tested my patches on ecovec and migor without
> any problems.
>
> As for sh7722 - if you tell me, how to reproduce the problem, I can either
> test your patch, removing those unused HWBLK_* indices, I could prepare
> one myself.
Hmm... strange.
my kernel will deadlock on clk->disable() from clk_late_init().
The reason was above.
# clk->disable() run NULL pointer, but it was under spin lock.
# I guess Oops print will locked by scif spinlock (?), not sure
I can re-produce this issue by below with attached ecovec .config.
---- 8< -------------------
my branch is
# git checkout paul/sh-latest (19d7ca2998e095086869318dd2ad966952f5ac82)
# git merge paul/sh/hwblk (cfc806a7ee38e68a9363584dd2b00421fda6dfed)
sh-latest has some bugfix patches.
--- 8< --------------------
This is my kernel log.
deadlock will happen on clk_late_init().
...
sh_mobile_sdhi sh_mobile_sdhi.1: mmc1 base at 0x04cf0000 clock rate 83 MHz
sh_tmu sh_tmu.0: kept as earlytimer
sh_tmu sh_tmu.1: kept as earlytimer
heartbeat: version 0.1.2 loaded
TCP cubic registered
NET: Registered protocol family 17
rtc-rs5c372 1-0032: setting system clock to 2062-08-02 15:35:09 UTC (2921758509)
--- 8< --------------------
Best regards
---
Kuninori Morimoto
[-- Attachment #2: ecovec-3.2.config.gz --]
[-- Type: application/zip, Size: 10898 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] sh: bugfix: sh7724/sh7723 boot on paul/hwblk
From: Guennadi Liakhovetski @ 2011-11-22 8:26 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <87zkfoyi9l.wl%kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san
On Mon, 21 Nov 2011, Kuninori Morimoto wrote:
>
> Hi Paul
> Cc Guennadi
>
> These are bugfix patches for sh7724/sh7723 boot on paul/hwblk branch
>
> Kuninori Morimoto (2):
> sh: sh7724.h: bugfix: remove unused clock index
> sh: sh7723.h: bugfix: remove unused clock index
>
> Now it doesn't use hwblk, but it still have un-needed HWBLK_xxx index
> which are not set by SH_CLK_MSTP32() macro.
> So, sh7724/sh7723 boot will be crash, because clk.enable_reg = NULL on such clocks.
Thanks for the patches! It is certainly good to remove unused code / data,
but could you please explain a bit what exactly crashes you observed and
how you triggered them? I tested my patches on ecovec and migor without
any problems.
As for sh7722 - if you tell me, how to reproduce the problem, I can either
test your patch, removing those unused HWBLK_* indices, I could prepare
one myself.
Thanks
Guennadi
> I tested it on Ecovec (sh7724) and ALGO (sh7723) board.
> I don't have sh7722 board now.
>
> Best regards
> ---
> Kuninori Morimoto
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH] ARM: mach-shmobile: Kota2 TPU LED platform data
From: Magnus Damm @ 2011-11-22 6:44 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <20110829035011.28202.37748.sendpatchset@rxone.opensource.se>
From: Magnus Damm <damm@opensource.se>
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.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
Based on earlier submitted patch
"[PATCH] ARM: mach-shmobile: Kota2 TPU LED support V2"
arch/arm/mach-shmobile/board-kota2.c | 122 +++++++++++++++++++++++++++++++--
arch/arm/mach-shmobile/clock-sh73a0.c | 16 ++++
2 files changed, 134 insertions(+), 4 deletions(-)
--- 0005/arch/arm/mach-shmobile/board-kota2.c
+++ work/arch/arm/mach-shmobile/board-kota2.c 2011-11-22 15:42:09.000000000 +0900
@@ -33,6 +33,7 @@
#include <linux/input/sh_keysc.h>
#include <linux/gpio_keys.h>
#include <linux/leds.h>
+#include <linux/platform_data/leds-renesas-tpu.h>
#include <linux/mmc/host.h>
#include <linux/mmc/sh_mmcif.h>
#include <linux/mfd/tmio.h>
@@ -157,10 +158,6 @@ static struct platform_device gpio_keys_
#define GPIO_LED(n, g) { .name = n, .gpio = g }
static struct gpio_led gpio_leds[] = {
- GPIO_LED("V2513", GPIO_PORT153), /* PORT153 [TPU1T02] -> V2513 */
- GPIO_LED("V2514", GPIO_PORT199), /* PORT199 [TPU4TO1] -> V2514 */
- GPIO_LED("V2515", GPIO_PORT197), /* PORT197 [TPU2TO1] -> V2515 */
- GPIO_LED("KEYLED", GPIO_PORT163), /* PORT163 [TPU3TO0] -> KEYLED */
GPIO_LED("G", GPIO_PORT20), /* PORT20 [GPO0] -> LED7 -> "G" */
GPIO_LED("H", GPIO_PORT21), /* PORT21 [GPO1] -> LED8 -> "H" */
GPIO_LED("J", GPIO_PORT22), /* PORT22 [GPO2] -> LED9 -> "J" */
@@ -179,6 +176,119 @@ static struct platform_device gpio_leds_
},
};
+/* TPU LED */
+static struct led_renesas_tpu_config led_renesas_tpu12_pdata = {
+ .name = "V2513",
+ .pin_gpio_fn = GPIO_FN_TPU1TO2,
+ .pin_gpio = GPIO_PORT153,
+ .channel_offset = 0x90,
+ .timer_bit = 2,
+ .max_brightness = 1000,
+};
+
+static struct resource tpu12_resources[] = {
+ [0] = {
+ .name = "TPU12",
+ .start = 0xe6610090,
+ .end = 0xe66100b5,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device leds_tpu12_device = {
+ .name = "leds-renesas-tpu",
+ .id = 12,
+ .dev = {
+ .platform_data = &led_renesas_tpu12_pdata,
+ },
+ .num_resources = ARRAY_SIZE(tpu12_resources),
+ .resource = tpu12_resources,
+};
+
+static struct led_renesas_tpu_config led_renesas_tpu41_pdata = {
+ .name = "V2514",
+ .pin_gpio_fn = GPIO_FN_TPU4TO1,
+ .pin_gpio = GPIO_PORT199,
+ .channel_offset = 0x50,
+ .timer_bit = 1,
+ .max_brightness = 1000,
+};
+
+static struct resource tpu41_resources[] = {
+ [0] = {
+ .name = "TPU41",
+ .start = 0xe6640050,
+ .end = 0xe6640075,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device leds_tpu41_device = {
+ .name = "leds-renesas-tpu",
+ .id = 41,
+ .dev = {
+ .platform_data = &led_renesas_tpu41_pdata,
+ },
+ .num_resources = ARRAY_SIZE(tpu41_resources),
+ .resource = tpu41_resources,
+};
+
+static struct led_renesas_tpu_config led_renesas_tpu21_pdata = {
+ .name = "V2515",
+ .pin_gpio_fn = GPIO_FN_TPU2TO1,
+ .pin_gpio = GPIO_PORT197,
+ .channel_offset = 0x50,
+ .timer_bit = 1,
+ .max_brightness = 1000,
+};
+
+static struct resource tpu21_resources[] = {
+ [0] = {
+ .name = "TPU21",
+ .start = 0xe6620050,
+ .end = 0xe6620075,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device leds_tpu21_device = {
+ .name = "leds-renesas-tpu",
+ .id = 21,
+ .dev = {
+ .platform_data = &led_renesas_tpu21_pdata,
+ },
+ .num_resources = ARRAY_SIZE(tpu21_resources),
+ .resource = tpu21_resources,
+};
+
+static struct led_renesas_tpu_config led_renesas_tpu30_pdata = {
+ .name = "KEYLED",
+ .pin_gpio_fn = GPIO_FN_TPU3TO0,
+ .pin_gpio = GPIO_PORT163,
+ .channel_offset = 0x10,
+ .timer_bit = 0,
+ .max_brightness = 1000,
+};
+
+static struct resource tpu30_resources[] = {
+ [0] = {
+ .name = "TPU30",
+ .start = 0xe6630010,
+ .end = 0xe6630035,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device leds_tpu30_device = {
+ .name = "leds-renesas-tpu",
+ .id = 30,
+ .dev = {
+ .platform_data = &led_renesas_tpu30_pdata,
+ },
+ .num_resources = ARRAY_SIZE(tpu30_resources),
+ .resource = tpu30_resources,
+};
+
/* MMCIF */
static struct resource mmcif_resources[] = {
[0] = {
@@ -291,6 +401,10 @@ static struct platform_device *kota2_dev
&keysc_device,
&gpio_keys_device,
&gpio_leds_device,
+ &leds_tpu12_device,
+ &leds_tpu41_device,
+ &leds_tpu21_device,
+ &leds_tpu30_device,
&mmcif_device,
&sdhi0_device,
&sdhi1_device,
--- 0004/arch/arm/mach-shmobile/clock-sh73a0.c
+++ work/arch/arm/mach-shmobile/clock-sh73a0.c 2011-11-22 15:38:14.000000000 +0900
@@ -113,6 +113,12 @@ static struct clk main_clk = {
.ops = &main_clk_ops,
};
+/* Divide Main clock by two */
+static struct clk main_div2_clk = {
+ .ops = &div2_clk_ops,
+ .parent = &main_clk,
+};
+
/* PLL0, PLL1, PLL2, PLL3 */
static unsigned long pll_recalc(struct clk *clk)
{
@@ -181,6 +187,7 @@ static struct clk *main_clks[] = {
&extal1_div2_clk,
&extal2_div2_clk,
&main_clk,
+ &main_div2_clk,
&pll0_clk,
&pll1_clk,
&pll2_clk,
@@ -268,6 +275,7 @@ enum { MSTP001,
MSTP207, MSTP206, MSTP204, MSTP203, MSTP202, MSTP201, MSTP200,
MSTP331, MSTP329, MSTP325, MSTP323, MSTP318,
MSTP314, MSTP313, MSTP312, MSTP311,
+ MSTP303, MSTP302, MSTP301, MSTP300,
MSTP411, MSTP410, MSTP403,
MSTP_NR };
@@ -301,6 +309,10 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP313] = MSTP(&div6_clks[DIV6_SDHI1], SMSTPCR3, 13, 0), /* SDHI1 */
[MSTP312] = MSTP(&div4_clks[DIV4_HP], SMSTPCR3, 12, 0), /* MMCIF0 */
[MSTP311] = MSTP(&div6_clks[DIV6_SDHI2], SMSTPCR3, 11, 0), /* SDHI2 */
+ [MSTP303] = MSTP(&main_div2_clk, SMSTPCR3, 3, 0), /* TPU1 */
+ [MSTP302] = MSTP(&main_div2_clk, SMSTPCR3, 2, 0), /* TPU2 */
+ [MSTP301] = MSTP(&main_div2_clk, SMSTPCR3, 1, 0), /* TPU3 */
+ [MSTP300] = MSTP(&main_div2_clk, SMSTPCR3, 0, 0), /* TPU4 */
[MSTP411] = MSTP(&div4_clks[DIV4_HP], SMSTPCR4, 11, 0), /* IIC3 */
[MSTP410] = MSTP(&div4_clks[DIV4_HP], SMSTPCR4, 10, 0), /* IIC4 */
[MSTP403] = MSTP(&r_clk, SMSTPCR4, 3, 0), /* KEYSC */
@@ -350,6 +362,10 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("sh_mobile_sdhi.1", &mstp_clks[MSTP313]), /* SDHI1 */
CLKDEV_DEV_ID("sh_mmcif.0", &mstp_clks[MSTP312]), /* MMCIF0 */
CLKDEV_DEV_ID("sh_mobile_sdhi.2", &mstp_clks[MSTP311]), /* SDHI2 */
+ CLKDEV_DEV_ID("leds-renesas-tpu.12", &mstp_clks[MSTP303]), /* TPU1 */
+ CLKDEV_DEV_ID("leds-renesas-tpu.21", &mstp_clks[MSTP302]), /* TPU2 */
+ CLKDEV_DEV_ID("leds-renesas-tpu.30", &mstp_clks[MSTP301]), /* TPU3 */
+ CLKDEV_DEV_ID("leds-renesas-tpu.41", &mstp_clks[MSTP300]), /* TPU4 */
CLKDEV_DEV_ID("i2c-sh_mobile.3", &mstp_clks[MSTP411]), /* I2C3 */
CLKDEV_DEV_ID("i2c-sh_mobile.4", &mstp_clks[MSTP410]), /* I2C4 */
CLKDEV_DEV_ID("sh_keysc.0", &mstp_clks[MSTP403]), /* KEYSC */
^ permalink raw reply
* [PATCH] ARM: mach-shmobile: AG5EVM GIC Sparse IRQ fix
From: Magnus Damm @ 2011-11-22 6:31 UTC (permalink / raw)
To: linux-sh
From: Magnus Damm <damm@opensource.se>
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:
f37a53c ARM: gic: fix irq_alloc_descs handling for sparse irq
Without this fix the following warning triggers at boot:
NR_IRQS:1024 nr_irqs:1024 1024
------------[ cut here ]------------
WARNING: at arch/arm/common/gic.c:607 gic_init+0x90/0x2e4()
Cannot allocate irq_descs @ IRQ16, assuming pre-allocated
[<c000c868>] (unwind_backtrace+0x0/0xe0) from [<c001857c>] (warn_slowpath_commo)
[<c001857c>] (warn_slowpath_common+0x48/0x60) from [<c00185d8>] (warn_slowpath_)
[<c00185d8>] (warn_slowpath_fmt+0x2c/0x3c) from [<c029ee08>] (gic_init+0x90/0x2)
[<c029ee08>] (gic_init+0x90/0x2e4) from [<c029f278>] (sh73a0_init_irq+0x30/0x18)
[<c029f278>] (sh73a0_init_irq+0x30/0x184) from [<c029c0b4>] (init_IRQ+0x14/0x1c)
[<c029c0b4>] (init_IRQ+0x14/0x1c) from [<c029a5cc>] (start_kernel+0x15c/0x2b8)
[<c029a5cc>] (start_kernel+0x15c/0x2b8) from [<4000803c>] (0x4000803c)
---[ end trace 1b75b31a2719ed1c ]---
With this fix applied interrupts work as expected.
Signed-off-by: Magnus Damm <damm@opensource.se>
---
arch/arm/mach-shmobile/board-ag5evm.c | 1 +
1 file changed, 1 insertion(+)
--- 0001/arch/arm/mach-shmobile/board-ag5evm.c
+++ work/arch/arm/mach-shmobile/board-ag5evm.c 2011-11-17 18:35:51.000000000 +0900
@@ -607,6 +607,7 @@ struct sys_timer ag5evm_timer = {
MACHINE_START(AG5EVM, "ag5evm")
.map_io = ag5evm_map_io,
+ .nr_irqs = NR_IRQS_LEGACY,
.init_irq = sh73a0_init_irq,
.handle_irq = shmobile_handle_irq_gic,
.init_machine = ag5evm_init,
^ 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