* [PATCH 09/26] ARM: pxa: export symbols from pxa3xx-ulpi
From: Eric Miao @ 2011-10-07 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317499438-14058-10-git-send-email-arnd@arndb.de>
On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The pxa3xx_u2d_start_hc/pxa3xx_u2d_stop_hc symbols are used by the
> ohci-pxa27x driver, which can be a module.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied. Cc'ed Igor Grinberg <grinberg@compulab.co.il>.
> ---
> ?arch/arm/mach-pxa/pxa3xx-ulpi.c | ? ?2 ++
> ?1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/pxa3xx-ulpi.c b/arch/arm/mach-pxa/pxa3xx-ulpi.c
> index ce7168b..e28dfb8 100644
> --- a/arch/arm/mach-pxa/pxa3xx-ulpi.c
> +++ b/arch/arm/mach-pxa/pxa3xx-ulpi.c
> @@ -265,6 +265,7 @@ int pxa3xx_u2d_start_hc(struct usb_bus *host)
>
> ? ? ? ?return err;
> ?}
> +EXPORT_SYMBOL_GPL(pxa3xx_u2d_start_hc);
>
> ?void pxa3xx_u2d_stop_hc(struct usb_bus *host)
> ?{
> @@ -277,6 +278,7 @@ void pxa3xx_u2d_stop_hc(struct usb_bus *host)
>
> ? ? ? ?clk_disable(u2d->clk);
> ?}
> +EXPORT_SYMBOL_GPL(pxa3xx_u2d_stop_hc);
>
> ?static int pxa3xx_u2d_probe(struct platform_device *pdev)
> ?{
> --
> 1.7.5.4
>
>
^ permalink raw reply
* [PATCH 10/26] ARM: pxa: allow selecting just one of TREO680/CENTRO
From: Eric Miao @ 2011-10-07 6:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317499438-14058-11-git-send-email-arnd@arndb.de>
On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> There are two variants of the palmtreo machine, the 680 and the
> centro, and Kconfig allows selecting one or both of them.
> This changes the board file so that it's actually possible
> to build all configurations that are allowed.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Looks good to me. Applied.
Cc'ed Marek Vasut.
> ---
> ?arch/arm/mach-pxa/palmtreo.c | ? ?8 ++++++++
> ?1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/palmtreo.c b/arch/arm/mach-pxa/palmtreo.c
> index bb27d4b..30364b0 100644
> --- a/arch/arm/mach-pxa/palmtreo.c
> +++ b/arch/arm/mach-pxa/palmtreo.c
> @@ -423,6 +423,7 @@ static void __init palmphone_common_init(void)
> ? ? ? ?palmtreo_leds_init();
> ?}
>
> +#ifdef CONFIG_MACH_TREO680
> ?static void __init treo680_init(void)
> ?{
> ? ? ? ?pxa2xx_mfp_config(ARRAY_AND_SIZE(treo680_pin_config));
> @@ -430,7 +431,9 @@ static void __init treo680_init(void)
> ? ? ? ?palm27x_mmc_init(GPIO_NR_TREO_SD_DETECT_N, GPIO_NR_TREO680_SD_READONLY,
> ? ? ? ? ? ? ? ? ? ? ? ?GPIO_NR_TREO680_SD_POWER, 0);
> ?}
> +#endif
>
> +#ifdef CONFIG_MACH_CENTRO
> ?static void __init centro_init(void)
> ?{
> ? ? ? ?pxa2xx_mfp_config(ARRAY_AND_SIZE(centro685_pin_config));
> @@ -438,7 +441,9 @@ static void __init centro_init(void)
> ? ? ? ?palm27x_mmc_init(GPIO_NR_TREO_SD_DETECT_N, -1,
> ? ? ? ? ? ? ? ? ? ? ? ?GPIO_NR_CENTRO_SD_POWER, 1);
> ?}
> +#endif
>
> +#ifdef CONFIG_MACH_TREO680
> ?MACHINE_START(TREO680, "Palm Treo 680")
> ? ? ? ?.boot_params ? ?= 0xa0000100,
> ? ? ? ?.map_io ? ? ? ? = pxa27x_map_io,
> @@ -448,7 +453,9 @@ MACHINE_START(TREO680, "Palm Treo 680")
> ? ? ? ?.timer ? ? ? ? ?= &pxa_timer,
> ? ? ? ?.init_machine ? = treo680_init,
> ?MACHINE_END
> +#endif
>
> +#ifdef CONFIG_MACH_CENTRO
> ?MACHINE_START(CENTRO, "Palm Centro 685")
> ? ? ? ?.boot_params ? ?= 0xa0000100,
> ? ? ? ?.map_io ? ? ? ? = pxa27x_map_io,
> @@ -458,3 +465,4 @@ MACHINE_START(CENTRO, "Palm Centro 685")
> ? ? ? ?.timer ? ? ? ? ?= &pxa_timer,
> ? ? ? ?.init_machine ? = centro_init,
> ?MACHINE_END
> +#endif
> --
> 1.7.5.4
>
>
^ permalink raw reply
* [PATCH 11/26] ARM: pxa: allow building palm27x without pxafb
From: Eric Miao @ 2011-10-07 6:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317499438-14058-12-git-send-email-arnd@arndb.de>
On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> The frame buffer device is defined conditionally on whether the
> driver is configured. However, the #ifdef guard around the
> declaration of palm27x_lcd_init also removes the visibility
> of the lcd mode declarations, which need to be available in
> order to build correctly, even if they are not defined in the
> end.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ?arch/arm/mach-pxa/include/mach/palm27x.h | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/include/mach/palm27x.h b/arch/arm/mach-pxa/include/mach/palm27x.h
> index 0a5e5ea..030a916 100644
> --- a/arch/arm/mach-pxa/include/mach/palm27x.h
> +++ b/arch/arm/mach-pxa/include/mach/palm27x.h
> @@ -27,10 +27,10 @@ extern void __init palm27x_pm_init(unsigned long str_base);
> ?static inline void palm27x_pm_init(unsigned long str_base) {}
> ?#endif
>
> -#if defined(CONFIG_FB_PXA) || defined(CONFIG_FB_PXA_MODULE)
> ?extern struct pxafb_mode_info palm_320x480_lcd_mode;
> ?extern struct pxafb_mode_info palm_320x320_lcd_mode;
> ?extern struct pxafb_mode_info palm_320x320_new_lcd_mode;
> +#if defined(CONFIG_FB_PXA) || defined(CONFIG_FB_PXA_MODULE)
> ?extern void __init palm27x_lcd_init(int power,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct pxafb_mode_info *mode);
> ?#else
> --
> 1.7.5.4
Marek and I actually came up with a patch to fix this as below, this
way to cover the declarations of those modes in the CONFIG_FB_PXA
as well.
commit e227e88ae46e921f608b056e27e1d8704b7d12fa
Author: Eric Miao <eric.y.miao@gmail.com>
Date: Sun Sep 11 16:56:58 2011 +0800
ARM: pxa: fix building error by palm27x_lcd_init() when FB_PXA not defined
Cc: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
diff --git a/arch/arm/mach-pxa/include/mach/palm27x.h
b/arch/arm/mach-pxa/include/mach/palm27x.h
index 0a5e5ea..f80bbe2 100644
--- a/arch/arm/mach-pxa/include/mach/palm27x.h
+++ b/arch/arm/mach-pxa/include/mach/palm27x.h
@@ -34,7 +34,7 @@ extern struct pxafb_mode_info palm_320x320_new_lcd_mode;
extern void __init palm27x_lcd_init(int power,
struct pxafb_mode_info *mode);
#else
-static inline void palm27x_lcd_init(int power, struct pxafb_mode_info *mode) {}
+#define palm27x_lcd_init(power, mode) do {} while (0)
#endif
#if defined(CONFIG_USB_GADGET_PXA27X) || \
>
>
^ permalink raw reply related
* [PATCH 0/1] A trio of IXP425 boards
From: Richard Cochran @ 2011-10-07 6:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m3obxv7fvy.fsf@intrepid.localdomain>
On Wed, Oct 05, 2011 at 03:00:01PM +0200, Krzysztof Halasa wrote:
> Richard Cochran <richardcochran@gmail.com> writes:
>
> > This patch adds support for three boards using the ixp425. Since they
> > are are almost identical to each other, they can share one setup file.
> >
> > The three machine types are slated for removal due to the fact that
> > the board support has not been merged. My polite request is to merge
> > this patch and restore the machine types.
>
> This is a good idea, IMHO.
> Acked-by: Krzysztof Ha?asa <khc@pm.waw.pl>
>
> Unfortunately ATM I don't have access to kernel.org and being a bit
> busy with unrelated things, I'd rather avoid "processing" this patch
> personally if possible. Can you send it upstream yourself, please?
> Let me know of any problem.
Okay, then, Arnd? Russell?
Will one of you please take this patch?
Thanks,
Richard
^ permalink raw reply
* [PATCH 1/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
From: Santosh Shilimkar @ 2011-10-07 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111005220619.GC6324@atomide.com>
On Thursday 06 October 2011 03:36 AM, Tony Lindgren wrote:
> * Nicolas Pitre <nico@fluxnic.net> [111004 17:26]:
>> On Tue, 4 Oct 2011, Tony Lindgren wrote:
>>
>>> This allows mapping external memory such as SRAM for use.
>>>
>>> This is needed for some small chunks of code, such as reprogramming
>>> SDRAM memory source clocks that can't be executed in SDRAM. Other
>>> use cases include some PM related code.
>>>
>>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>>
>> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
>>
>> As mentioned, you might consider dropping the export until needed.
>
> Here's this one updated to drop the export.
>
> Tony
>
>
> From: Tony Lindgren <tony@atomide.com>
> Date: Tue, 4 Oct 2011 18:26:27 -0700
> Subject: [PATCH] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
>
> This allows mapping external memory such as SRAM for use.
>
> This is needed for some small chunks of code, such as reprogramming
> SDRAM memory source clocks that can't be executed in SDRAM. Other
> use cases include some PM related code.
>
> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
> index d66605d..4ff152e 100644
> --- a/arch/arm/include/asm/io.h
> +++ b/arch/arm/include/asm/io.h
> @@ -80,6 +80,7 @@ extern void __iomem *__arm_ioremap_caller(unsigned long, size_t, unsigned int,
>
> extern void __iomem *__arm_ioremap_pfn(unsigned long, unsigned long, size_t, unsigned int);
> extern void __iomem *__arm_ioremap(unsigned long, size_t, unsigned int);
> +extern void __iomem *__arm_ioremap_exec(unsigned long, size_t, int cached);
> extern void __iounmap(volatile void __iomem *addr);
>
> /*
> diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
> index ab50627..a2d94ac 100644
> --- a/arch/arm/mm/ioremap.c
> +++ b/arch/arm/mm/ioremap.c
> @@ -289,6 +289,27 @@ __arm_ioremap(unsigned long phys_addr, size_t size, unsigned int mtype)
> }
> EXPORT_SYMBOL(__arm_ioremap);
>
> +/*
> + * Remap an arbitrary physical address space into the kernel virtual
> + * address space as memory. Needed when the kernel wants to execute
> + * code in external memory. This is needed for reprogramming source
> + * clocks that would affect normal memory for example. Please see
> + * CONFIG_GENERIC_ALLOCATOR for allocating external memory.
> + */
> +void __iomem *
> +__arm_ioremap_exec(unsigned long phys_addr, size_t size, int cached)
> +{
> + unsigned int mtype;
> +
> + if (cached)
> + mtype = MT_MEMORY;
> + else
> + mtype = MT_MEMORY_NONCACHED;
> +
Why don't we allow user to pass the mtype here ?
We do have a need also to map a page of DDR and SRAM as
strongly ordered for errata fix and this interface can be
used for that.
Ofcourse, SO memory type is not executable memories, so the
API name might be miss-leading.
Regards
Santosh
^ permalink raw reply
* [PATCH RESEND] ARM: smp_twd: Reconfigure clockevents after cpufreq change
From: Linus Walleij @ 2011-10-07 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1110061922440.3240@ionos>
On Thu, Oct 6, 2011 at 7:25 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Thu, 6 Oct 2011, Linus Walleij wrote:
>> Here is the entire patch i Russells tracker:
>> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6956/2
>
> The only thing what puzzles me is:
>
>> + ? ? if (!IS_ERR_OR_NULL(twd_clk))
>> + ? ? ? ? ? ? twd_timer_rate = clk_get_rate(twd_clk);
>> + ? ? else
>> + ? ? ? ? ? ? twd_calibrate_rate();
>
> How is made sure that the cpu freq update thing is not called when
> twd_clk is not available or am I missing something ?
The CPUfreq transition notifier is only registered if twd_clk is
not error or NULL in this #ifdef CONFIG_CPU_FREQ snippet
above that code, but executed later:
+static int twd_cpufreq_init(void)
+{
+ if (!IS_ERR_OR_NULL(twd_clk))
+ return cpufreq_register_notifier(&twd_cpufreq_nb,
+ CPUFREQ_TRANSITION_NOTIFIER);
+
+ return 0;
+}
+core_initcall(twd_cpufreq_init);
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/5] drivercore: add new error value for deferred probe
From: Greg KH @ 2011-10-07 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317963790-29426-2-git-send-email-manjugk@ti.com>
On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote:
>
> Add new error value so that drivers can request deferred probe
> from drivercore.
>
> Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
> Reported-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> Cc: linux-omap at vger.kernel.org
> Cc: linux-mmc at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Greg Kroah-Hartman <greg@kroah.com>
> Cc: Dilan Lee <dilee@nvidia.com>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Cc: Manjunath GKondaiah <manjunath.gkondaiah@linaro.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
>
> include/linux/errno.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/errno.h b/include/linux/errno.h
> index 4668583..83d8fcf 100644
> --- a/include/linux/errno.h
> +++ b/include/linux/errno.h
> @@ -16,6 +16,7 @@
> #define ERESTARTNOHAND 514 /* restart if no handler.. */
> #define ENOIOCTLCMD 515 /* No ioctl command */
> #define ERESTART_RESTARTBLOCK 516 /* restart by calling sys_restart_syscall */
> +#define EPROBE_DEFER 517 /* restart probe again after some time */
Can we really do this? Isn't this some user/kernel api here?
What's wrong with just "overloading" on top of an existing error code?
Surely one of the other 516 types could be used here, right?
greg k-h
^ permalink raw reply
* [PATCH 2/4] ARM: OMAP: Avoid cpu_is_omapxxxx usage until map_io is done
From: Santosh Shilimkar @ 2011-10-07 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111005004542.26980.98554.stgit@kaulin.local>
On Wednesday 05 October 2011 06:15 AM, Tony Lindgren wrote:
> This way we don't need to initialize SoC detection early
> and can start using generic map_io.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
^ permalink raw reply
* [PATCH 2/5] drivercore: Add driver probe deferral mechanism
From: Greg KH @ 2011-10-07 6:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317963790-29426-3-git-send-email-manjugk@ti.com>
On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
>
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Allow drivers to report at probe time that they cannot get all the
> resources required by the device, and should be retried at a
> later time.
>
> This should completely solve the problem of getting devices
> initialized in the right order. Right now this is mostly handled by
> mucking about with initcall ordering which is a complete hack, and
> doesn't even remotely handle the case where device drivers are in
> modules. This approach completely sidesteps the issues by allowing
> driver registration to occur in any order, and any driver can request
> to be retried after a few more other drivers get probed.
>
> Original patch posted by Grant Likely <grant.likely@secretlab.ca> at:
> http://lwn.net/Articles/460522/
>
> Enhancements to original patch by G, Manjunath Kondaiah <manjugk@ti.com>
> - checkpatch warning fixes
> - added Kconfig symbol CONFIG_PROBE_DEFER
> - replacing normal workqueue with singlethread_workqueue
> - handling -EPROBE_DEFER error
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
> ---
> Cc: linux-omap at vger.kernel.org
> Cc: linux-mmc at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Greg Kroah-Hartman <greg@kroah.com>
> Cc: Dilan Lee <dilee@nvidia.com>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Cc: Manjunath GKondaiah <manjunath.gkondaiah@linaro.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
>
> drivers/base/Kconfig | 11 ++++
> drivers/base/base.h | 3 +
> drivers/base/core.c | 6 ++
> drivers/base/dd.c | 145 ++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/device.h | 7 ++
> 5 files changed, 172 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 21cf46f..b412a71 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -172,6 +172,17 @@ config SYS_HYPERVISOR
> bool
> default n
>
> +config PROBE_DEFER
> + bool "Deferred Driver Probe"
> + default y
> + help
> + This option provides deferring driver probe if it has dependency on
> + other driver. Without this feature, initcall ordering should be done
> + manually to resolve driver dependencies. This feature completely side
> + steps the issues by allowing driver registration to occur in any
> + order, and any driver can request to be retried after a few more other
> + drivers get probed.
Why is this even an option? Why would you ever want it disabled? Why
does it need to be selected?
If you are going to default something to 'y' then just make it so it
can't be turned off any other way by just not making it an option at
all.
It also cleans up this diff a lot, as you really don't want #ifdef in .c
files.
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -28,6 +28,136 @@
> #include "base.h"
> #include "power/power.h"
>
> +#if defined CONFIG_PROBE_DEFER
> +/*
> + * Deferred Probe infrastructure.
Why not use kerneldoc?
> + *
> + * Sometimes driver probe order matters, but the kernel doesn't always have
> + * dependency information which means some drivers will get probed before a
> + * resource it depends on is available. For example, an SDHCI driver may
> + * first need a GPIO line from an i2c GPIO controller before it can be
> + * initialized. If a required resource is not available yet, a driver can
> + * request probing to be deferred by returning -EPROBE_DEFER from its probe hook
> + *
> + * Deferred probe maintains two lists of devices, a pending list and an active
> + * list. A driver returning -EPROBE_DEFER causes the device to be added to the
> + * pending list.
> + *
> + * The deferred_probe_mutex *must* be held any time the deferred_probe_*_list
> + * of the (struct device*)->deferred_probe pointers are manipulated
> + */
> +static DEFINE_MUTEX(deferred_probe_mutex);
> +static LIST_HEAD(deferred_probe_pending_list);
> +static LIST_HEAD(deferred_probe_active_list);
> +static struct workqueue_struct *deferred_wq;
> +
> +/**
> + * deferred_probe_work_func() - Retry probing devices in the active list.
> + */
> +static void deferred_probe_work_func(struct work_struct *work)
> +{
> + struct device *dev;
> + /*
Extra blank line please.
> + * This bit is tricky. We want to process every device in the
> + * deferred list, but devices can be removed from the list at any
> + * time while inside this for-each loop. There are two things that
> + * need to be protected against:
That's what the klist structure is supposed to make easier, why not use
that here?
> + * - if the device is removed from the deferred_probe_list, then we
> + * loose our place in the loop. Since any device can be removed
> + * asynchronously, list_for_each_entry_safe() wouldn't make things
> + * much better. Simplest solution is to restart walking the list
> + * whenever the current device gets removed. Not the most efficient,
> + * but is simple to implement and easy to audit for correctness.
> + * - if the device is unregistered, and freed, then there is a risk
> + * of a null pointer dereference. This code uses get/put_device()
> + * to ensure the device cannot disappear from under our feet.
Ick, use a klist, it was created to handle this exact problem in the
driver core, so to not use it would be wrong, right?
> + */
> + mutex_lock(&deferred_probe_mutex);
> + while (!list_empty(&deferred_probe_active_list)) {
> + dev = list_first_entry(&deferred_probe_active_list,
> + typeof(*dev), deferred_probe);
> + list_del_init(&dev->deferred_probe);
> +
> + get_device(dev);
> +
> + /* Drop the mutex while probing each device; the probe path
> + * may manipulate the deferred list */
Use proper kernel multi-line comment format. This needs to be done in a
number of places in this patch, please fix them all.
thanks,
greg k-h
^ permalink raw reply
* [PATCH 0/5] Driver Probe Deferral Mechanism
From: Greg KH @ 2011-10-07 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317963790-29426-1-git-send-email-manjugk@ti.com>
On Fri, Oct 07, 2011 at 10:33:05AM +0500, G, Manjunath Kondaiah wrote:
Why did you send this series of patches out twice? Were they different?
confused,
greg k-h
^ permalink raw reply
* [PATCH 4/4] ARM: OMAP: Map SRAM later on with ioremap_exec()
From: Santosh Shilimkar @ 2011-10-07 6:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111005221320.GE6324@atomide.com>
On Thursday 06 October 2011 03:43 AM, Tony Lindgren wrote:
> * Nicolas Pitre <nico@fluxnic.net> [111004 17:34]:
>> On Tue, 4 Oct 2011, Tony Lindgren wrote:
>>
>>> This allows us to remove omap hacks for map_io.
>>>
>>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>>
>> Nice cleanup.
>>
>> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
>
> This one needed minor changes for the omap1 omap_sram_init
> call. Updated patch below, still assuming I have your ack
> for this one too.
>
> Tony
>
>
> From: Tony Lindgren <tony@atomide.com>
> Date: Tue, 4 Oct 2011 13:52:57 -0700
> Subject: [PATCH] ARM: OMAP: Map SRAM later on with ioremap_exec()
>
> This allows us to remove omap hacks for map_io.
>
> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
Are you considering this change for 3.2?
OMAP4 errata WA would have a conflict with the
change is sram code and hence the question ?
O.w patch looks fine to me.
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
^ permalink raw reply
* [PATCH 5/4] ARM: OMAP: Move set_globals initialization to happen in init_early
From: Santosh Shilimkar @ 2011-10-07 6:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111006013656.GG6324@atomide.com>
On Thursday 06 October 2011 07:06 AM, Tony Lindgren wrote:
> * Nicolas Pitre <nico@fluxnic.net> [111004 18:17]:
>> On Tue, 4 Oct 2011, Tony Lindgren wrote:
>>
>>> Otherwise we can't do generic map_io as we currently rely on
>>> static mappings that work only because of arch_ioremap.
>>>
>>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>>
>> That's great.
>>
>> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
>
> Here's an updated version with all the early ioremap
> access converted to use L3/L4_IO_ADDRESS macros. Some
> of this may not be needed after generic map_io, but until
> then we can't use ioremap until in init_early after the
> SoC detection is done.
>
> Regards,
>
> Tony
>
>
> From: Tony Lindgren <tony@atomide.com>
> Date: Tue, 4 Oct 2011 18:17:41 -0700
> Subject: [PATCH] ARM: OMAP: Move set_globals initialization to happen in init_early
>
> Otherwise we can't do generic map_io as we currently rely on
> static mappings that work only because of arch_ioremap.
>
> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
The changes looks fine to me. Though the ugly hard-coding
is back with it, it's a step towards generic_io, so hopefully
it won't have to stay for long time.
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
considering it's commin
^ permalink raw reply
* [PATCH 0/4] initialize omap SRAM later on with __arm_ioremap_exec()
From: Santosh Shilimkar @ 2011-10-07 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111006014219.GH6324@atomide.com>
On Thursday 06 October 2011 07:12 AM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [111004 23:29]:
>>
>> Will look at this series in next couple of days and do some testing.
>
> Thanks, turns out there were a few issues with early ioremap
> that I fixed. Care to check the L4_IO_ADDRESS changes?
>
They look ok to me.
> It's all pushed now into sram-map-io branch at:
>
> https://github.com/tmlind/linux/tree/sram-map-io
>
> It seems it's booting now on all omaps I've tried, so will merge
> it into linux-omap master branch as well for testing.
>
I have reviewed and tested this series. No problems seen.
As asked on other thread, if you are targeting this one for
3.2, then sram changes would have a small conflict with
OMAP4 errata patch. If it is for 3.3, we should be able to
sort out that conflict easily.
Regards
Santosh
^ permalink raw reply
* [PATCH] OMAP2+: clock: use clock's recalc in DPLL handling
From: Paul Walmsley @ 2011-10-07 7:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317343888-30892-1-git-send-email-mturquette@ti.com>
On Thu, 29 Sep 2011, Mike Turquette wrote:
> Not all DPLLs are identical; some require special consideration such as
> OMAP4's ABE DPLL, which can have an additional 4x multiplier added to
> it's clock rate based on programming the REGM4XEN bit in it's CLKMODE
> register.
>
> Unfortunately the clock framework makes a few assumptions that all DPLLs
> can have their rates calculated the same way which has led to incorrect
> rates for OMAP4's DPLL_ABE in some cases. This patch fixes the same by
> replacing explicit calls to omap2_dpll_get_rate with clk->recalc if
> .recalc is populated for a clock. If .recalc is NULL then fall back to
> omap2_dpll_get_rate.
>
> Reported-by: Misael Lopez Cruz <misael.lopez@ti.com>
> Signed-off-by: Mike Turquette <mturquette@ti.com>
I've merged this patch with Jon's "ARM: OMAP3+: dpll: use DPLLs recalc
function instead of omap2_get_dpll_rate" patch, which does almost exactly
the same thing, just without the conditionals on clk->recalc. Updated
patch below. Please let me know if you think I should change anything
about the changelog.
- Paul
From: Jon Hunter <jon-hunter@ti.com>
Date: Fri, 7 Oct 2011 00:53:01 -0600
Subject: [PATCH] ARM: OMAP3+: dpll: use DPLLs recalc function instead of
omap2_get_dpll_rate
This is a continuation of Mike Turquette's patch "OMAP3+: use
DPLL's round_rate when setting rate".
omap3_noncore_dpll_set_rate() and omap3_noncore_dpll_enable() call
omap2_get_dpll_rate() explicitly. It may be necessary for some
DPLLs to use a different function and so use the DPLLs recalc()
function pointer instead.
An example is the DPLL_ABE on OMAP4 which can have a 4X multiplier
in addition to the usual MN multipler and dividers and therefore
uses a different round_rate and recalc function.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Cc: Mike Turquette <mturquette@ti.com>
Cc: Misael Lopez Cruz <misael.lopez@ti.com>
[paul at pwsan.com: merged this patch with Mike's "use clock's recalc in DPLL
handling" patch; also reported by Misael]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/dpll3xxx.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 73a1595..fc56745 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -390,7 +390,8 @@ int omap3_noncore_dpll_enable(struct clk *clk)
* propagating?
*/
if (!r)
- clk->rate = omap2_get_dpll_rate(clk);
+ clk->rate = (clk->recalc) ? clk->recalc(clk) :
+ omap2_get_dpll_rate(clk);
return r;
}
@@ -424,6 +425,7 @@ void omap3_noncore_dpll_disable(struct clk *clk)
int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate)
{
struct clk *new_parent = NULL;
+ unsigned long hw_rate;
u16 freqsel = 0;
struct dpll_data *dd;
int ret;
@@ -435,7 +437,8 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate)
if (!dd)
return -EINVAL;
- if (rate == omap2_get_dpll_rate(clk))
+ hw_rate = (clk->recalc) ? clk->recalc(clk) : omap2_get_dpll_rate(clk);
+ if (rate == hw_rate)
return 0;
/*
--
1.7.6.3
^ permalink raw reply related
* [PATCH 12/26] ARM: pxa: pxa95x/saarb depends on pxa3xx code
From: Eric Miao @ 2011-10-07 7:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317499438-14058-13-git-send-email-arnd@arndb.de>
On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> saarb uses pxa3xx_map_io and pxa3xx_handle_irq, which are part
> of the pxa3xx code. This makes sure the necessary header and
> implementation is used when building the board file.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ?arch/arm/mach-pxa/Makefile | ? ?2 +-
> ?arch/arm/mach-pxa/saarb.c ?| ? ?2 ++
> ?2 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/Makefile b/arch/arm/mach-pxa/Makefile
> index cc39d17..be0f7df 100644
> --- a/arch/arm/mach-pxa/Makefile
> +++ b/arch/arm/mach-pxa/Makefile
> @@ -19,7 +19,7 @@ endif
> ?obj-$(CONFIG_PXA25x) ? ? ? ? ? += mfp-pxa2xx.o clock-pxa2xx.o pxa2xx.o pxa25x.o
> ?obj-$(CONFIG_PXA27x) ? ? ? ? ? += mfp-pxa2xx.o clock-pxa2xx.o pxa2xx.o pxa27x.o
> ?obj-$(CONFIG_PXA3xx) ? ? ? ? ? += mfp-pxa3xx.o clock-pxa3xx.o pxa3xx.o smemc.o pxa3xx-ulpi.o
> -obj-$(CONFIG_PXA95x) ? ? ? ? ? += mfp-pxa3xx.o clock-pxa3xx.o pxa95x.o smemc.o
> +obj-$(CONFIG_PXA95x) ? ? ? ? ? += mfp-pxa3xx.o clock-pxa3xx.o pxa3xx.o pxa95x.o smemc.o
> ?obj-$(CONFIG_CPU_PXA300) ? ? ? += pxa300.o
> ?obj-$(CONFIG_CPU_PXA320) ? ? ? += pxa320.o
> ?obj-$(CONFIG_CPU_PXA930) ? ? ? += pxa930.o
> diff --git a/arch/arm/mach-pxa/saarb.c b/arch/arm/mach-pxa/saarb.c
> index ebd6379..829c514 100644
> --- a/arch/arm/mach-pxa/saarb.c
> +++ b/arch/arm/mach-pxa/saarb.c
> @@ -25,6 +25,8 @@
> ?#include <mach/mfp-pxa930.h>
> ?#include <mach/gpio.h>
>
> +#include <mach/pxa930.h>
> +
> ?#include "generic.h"
>
> ?#define SAARB_NR_IRQS ?(IRQ_BOARD_START + 40)
> --
> 1.7.5.4
>
>
PXA95x is actually PJ4 based, which is ARMv7/v6 compatible, not
like it's predecessor PXA93x. Although they are currently sharing
some code, I expect a fork in the near future. To cause less confusion
here, I'd propose to further introduce pxa95x.h, and to remove
the unnecessary #include of <mach/mfp.h> and <mach/mfp-pxa930.h>
diff --git a/arch/arm/mach-pxa/Makefile b/arch/arm/mach-pxa/Makefile
index cc39d17..be0f7df 100644
--- a/arch/arm/mach-pxa/Makefile
+++ b/arch/arm/mach-pxa/Makefile
@@ -19,7 +19,7 @@ endif
obj-$(CONFIG_PXA25x) += mfp-pxa2xx.o clock-pxa2xx.o pxa2xx.o pxa25x.o
obj-$(CONFIG_PXA27x) += mfp-pxa2xx.o clock-pxa2xx.o pxa2xx.o pxa27x.o
obj-$(CONFIG_PXA3xx) += mfp-pxa3xx.o clock-pxa3xx.o pxa3xx.o smemc.o
pxa3xx-ulpi.o
-obj-$(CONFIG_PXA95x) += mfp-pxa3xx.o clock-pxa3xx.o pxa95x.o smemc.o
+obj-$(CONFIG_PXA95x) += mfp-pxa3xx.o clock-pxa3xx.o pxa3xx.o pxa95x.o smemc.o
obj-$(CONFIG_CPU_PXA300) += pxa300.o
obj-$(CONFIG_CPU_PXA320) += pxa320.o
obj-$(CONFIG_CPU_PXA930) += pxa930.o
diff --git a/arch/arm/mach-pxa/include/mach/pxa95x.h
b/arch/arm/mach-pxa/include/mach/pxa95x.h
new file mode 100644
index 0000000..cbb097c
--- /dev/null
+++ b/arch/arm/mach-pxa/include/mach/pxa95x.h
@@ -0,0 +1,7 @@
+#ifndef __MACH_PXA95X_H
+#define __MACH_PXA95X_H
+
+#include <mach/pxa3xx.h>
+#include <mach/mfp-pxa930.h>
+
+#endif /* __MACH_PXA95X_H */
diff --git a/arch/arm/mach-pxa/saarb.c b/arch/arm/mach-pxa/saarb.c
index ebd6379..aebd5d9 100644
--- a/arch/arm/mach-pxa/saarb.c
+++ b/arch/arm/mach-pxa/saarb.c
@@ -21,9 +21,8 @@
#include <mach/irqs.h>
#include <mach/hardware.h>
-#include <mach/mfp.h>
-#include <mach/mfp-pxa930.h>
#include <mach/gpio.h>
+#include <mach/pxa95x.h>
#include "generic.h"
^ permalink raw reply related
* [PATCH 0/5] Driver Probe Deferral Mechanism
From: G, Manjunath Kondaiah @ 2011-10-07 7:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111007065042.GF27508@kroah.com>
Hi Greg,
On Thu, Oct 06, 2011 at 11:50:42PM -0700, Greg KH wrote:
> On Fri, Oct 07, 2011 at 10:33:05AM +0500, G, Manjunath Kondaiah wrote:
>
> Why did you send this series of patches out twice? Were they different?
>
> confused,
Looks like this patch series has reached only individual recepients and
not the mailing lists hence it was posted once again.
Sorry for the spam.
-Manjunath
^ permalink raw reply
* [RFC/PATCH 2/7] ARM: ARM11 MPCore: pte_alloc_one{,_kernel} are not preempt safe
From: Russell King - ARM Linux @ 2011-10-07 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317955121-28047-3-git-send-email-gdavis@mvista.com>
On Thu, Oct 06, 2011 at 10:38:36PM -0400, gdavis at mvista.com wrote:
> -#define PGALLOC_GFP (GFP_KERNEL | __GFP_NOTRACK | __GFP_REPEAT | __GFP_ZERO)
> +#define PGALLOC_GFP (GFP_KERNEL | __GFP_NOTRACK | __GFP_REPEAT)
> @@ -81,8 +88,14 @@ pte_alloc_one(struct mm_struct *mm, unsigned long addr)
> pte = alloc_pages(PGALLOC_GFP, 0);
> #endif
> if (pte) {
> + void *p = page_address(pte);
> + if (cache_ops_need_broadcast())
> + preempt_disable();
> + memset(p, 0, PAGE_SIZE);
> if (!PageHighMem(pte))
> - clean_pte_table(page_address(pte));
> + clean_pte_table(p);
> + if (cache_ops_need_broadcast())
> + preempt_enable();
This won't work - page_address(pte) will be NULL for highmem pages, and
so will cause an oops, and removing the __GFP_ZERO will mean that highmem
pages will not be zeroed, meaning that such page tables will not have been
initialized.
^ permalink raw reply
* [GIT PULL] ARM: OMAP3+: clock fixes for 3.2
From: Paul Walmsley @ 2011-10-07 7:53 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tony,
The following changes since commit be73246058737beec52ae232bcab7776332a9e06:
ARM: OMAP2+: Remove custom init_irq for remaining boards (2011-09-26 17:50:37 -0700)
are available in the git repository at:
git://git.pwsan.com/linux-2.6 omap_clock_fixes_3.2
Jon Hunter (3):
ARM: OMAP3+: dpll: use DPLLs recalc function instead of omap2_get_dpll_rate
ARM: OMAP4: clock: Add missing clock divider for OCP_ABE_ICLK
OMAP3+: Update DPLL Fint range for OMAP36xx and OMAP4xxx devices
Mike Turquette (3):
ARM: OMAP4: clock: round_rate and recalc functions for DPLL_ABE
ARM: OMAP3+: dpll: use DPLL's round_rate when setting rate
ARM: OMAP3+: dpll: assign clk rate from rounded rate during rate set
Paul Walmsley (1):
ARM: OMAP4460: Clock: Adding support for 4460 specific clocks
arch/arm/mach-omap2/clkt_dpll.c | 51 +++++++++++++++++--------
arch/arm/mach-omap2/clock.h | 2 +
arch/arm/mach-omap2/clock44xx.h | 7 +++
arch/arm/mach-omap2/clock44xx_data.c | 32 +++++++++++----
arch/arm/mach-omap2/dpll3xxx.c | 9 +++-
arch/arm/mach-omap2/dpll44xx.c | 69 ++++++++++++++++++++++++++++++++++
6 files changed, 142 insertions(+), 28 deletions(-)
- Paul
^ permalink raw reply
* [GIT PULL] ARM: OMAP3+: clock fixes for 3.2
From: Paul Walmsley @ 2011-10-07 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1110070141450.4611@utopia.booyaka.com>
On Fri, 7 Oct 2011, Paul Walmsley wrote:
> The following changes since commit be73246058737beec52ae232bcab7776332a9e06:
>
> ARM: OMAP2+: Remove custom init_irq for remaining boards (2011-09-26 17:50:37 -0700)
>
> are available in the git repository at:
> git://git.pwsan.com/linux-2.6 omap_clock_fixes_3.2
>
> Jon Hunter (3):
> ARM: OMAP3+: dpll: use DPLLs recalc function instead of omap2_get_dpll_rate
> ARM: OMAP4: clock: Add missing clock divider for OCP_ABE_ICLK
> OMAP3+: Update DPLL Fint range for OMAP36xx and OMAP4xxx devices
By the way, the subject line for this patch has been updated in the git
branch to be prefixed with "ARM: ".
- Paul
^ permalink raw reply
* [PATCH 13/26] ARM: pxa: use correct __iomem annotations
From: Eric Miao @ 2011-10-07 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317499438-14058-14-git-send-email-arnd@arndb.de>
On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> This tries to clear up the confusion between integers and iomem pointers
> in the marvell pxa platform. MMIO addresses are supposed to be __iomem*
> values, in order to let the Linux type checking work correctly. This
> patch moves the cast to __iomem as far back as possible, to the place
> where the MMIO virtual address windows are defined.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ?arch/arm/include/asm/hardware/it8152.h ? ?| ? ?2 +-
> ?arch/arm/mach-mmp/clock.h ? ? ? ? ? ? ? ? | ? ?8 ++++----
> ?arch/arm/mach-mmp/common.c ? ? ? ? ? ? ? ?| ? ?4 ++--
> ?arch/arm/mach-mmp/include/mach/addr-map.h | ? 10 ++++++++--
> ?arch/arm/mach-mmp/mmp2.c ? ? ? ? ? ? ? ? ?| ? ?3 ++-
> ?arch/arm/mach-pxa/balloon3.c ? ? ? ? ? ? ?| ? 10 +++++-----
> ?arch/arm/mach-pxa/cm-x2xx-pci.c ? ? ? ? ? | ? ?2 +-
> ?arch/arm/mach-pxa/cm-x2xx.c ? ? ? ? ? ? ? | ? ?4 ++--
> ?arch/arm/mach-pxa/include/mach/addr-map.h | ? ?8 ++++----
> ?arch/arm/mach-pxa/include/mach/balloon3.h | ? ?2 +-
> ?arch/arm/mach-pxa/include/mach/hardware.h | ? ?9 +++++----
> ?arch/arm/mach-pxa/include/mach/lpd270.h ? | ? ?4 ++--
> ?arch/arm/mach-pxa/include/mach/mtd-xip.h ?| ? ?1 -
> ?arch/arm/mach-pxa/include/mach/palmtx.h ? | ? ?6 +++---
> ?arch/arm/mach-pxa/include/mach/smemc.h ? ?| ? ?2 +-
> ?arch/arm/mach-pxa/include/mach/zeus.h ? ? | ? ?4 ++--
> ?arch/arm/mach-pxa/irq.c ? ? ? ? ? ? ? ? ? | ? ?4 ++--
> ?arch/arm/mach-pxa/lpd270.c ? ? ? ? ? ? ? ?| ? ?2 +-
> ?arch/arm/mach-pxa/palmtx.c ? ? ? ? ? ? ? ?| ? ?8 ++++----
> ?arch/arm/mach-pxa/pxa25x.c ? ? ? ? ? ? ? ?| ? ?2 +-
> ?arch/arm/mach-pxa/pxa27x.c ? ? ? ? ? ? ? ?| ? ?2 +-
> ?arch/arm/mach-pxa/pxa3xx.c ? ? ? ? ? ? ? ?| ? ?2 +-
> ?arch/arm/mach-pxa/zeus.c ? ? ? ? ? ? ? ? ?| ? ?8 ++++----
> ?arch/arm/plat-pxa/gpio.c ? ? ? ? ? ? ? ? ?| ? ?2 +-
> ?arch/arm/plat-pxa/include/plat/mfp.h ? ? ?| ? ?2 +-
> ?arch/arm/plat-pxa/mfp.c ? ? ? ? ? ? ? ? ? | ? ?4 ++--
> ?drivers/pcmcia/pxa2xx_balloon3.c ? ? ? ? ?| ? ?2 +-
> ?drivers/video/mbx/mbxfb.c ? ? ? ? ? ? ? ? | ? ?6 +++---
> ?28 files changed, 65 insertions(+), 58 deletions(-)
>
> diff --git a/arch/arm/include/asm/hardware/it8152.h b/arch/arm/include/asm/hardware/it8152.h
> index b3fea38..43cab49 100644
> --- a/arch/arm/include/asm/hardware/it8152.h
> +++ b/arch/arm/include/asm/hardware/it8152.h
> @@ -9,7 +9,7 @@
>
> ?#ifndef __ASM_HARDWARE_IT8152_H
> ?#define __ASM_HARDWARE_IT8152_H
> -extern unsigned long it8152_base_address;
> +extern void __iomem *it8152_base_address;
>
> ?#define IT8152_IO_BASE ? ? ? ? ? ? ? ? (it8152_base_address + 0x03e00000)
> ?#define IT8152_CFGREG_BASE ? ? ? ? ? ? (it8152_base_address + 0x03f00000)
> diff --git a/arch/arm/mach-mmp/clock.h b/arch/arm/mach-mmp/clock.h
> index 3143e99..149b30c 100644
> --- a/arch/arm/mach-mmp/clock.h
> +++ b/arch/arm/mach-mmp/clock.h
> @@ -30,7 +30,7 @@ extern struct clkops apmu_clk_ops;
>
> ?#define APBC_CLK(_name, _reg, _fnclksel, _rate) ? ? ? ? ? ? ? ? ? ? ? ?\
> ?struct clk clk_##_name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> - ? ? ? ? ? ? ? .clk_rst ? ? ? ?= (void __iomem *)APBC_##_reg, ?\
> + ? ? ? ? ? ? ? .clk_rst ? ? ? ?= APBC_##_reg, ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.fnclksel ? ? ? = _fnclksel, ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.rate ? ? ? ? ? = _rate, ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.ops ? ? ? ? ? ?= &apbc_clk_ops, ? ? ? ? ? ? ? ?\
> @@ -38,7 +38,7 @@ struct clk clk_##_name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
>
> ?#define APBC_CLK_OPS(_name, _reg, _fnclksel, _rate, _ops) ? ? ?\
> ?struct clk clk_##_name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> - ? ? ? ? ? ? ? .clk_rst ? ? ? ?= (void __iomem *)APBC_##_reg, ?\
> + ? ? ? ? ? ? ? .clk_rst ? ? ? ?= APBC_##_reg, ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.fnclksel ? ? ? = _fnclksel, ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.rate ? ? ? ? ? = _rate, ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.ops ? ? ? ? ? ?= _ops, ? ? ? ? ? ? ? ? ? ? ? ? \
> @@ -46,7 +46,7 @@ struct clk clk_##_name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
>
> ?#define APMU_CLK(_name, _reg, _eval, _rate) ? ? ? ? ? ? ? ? ? ?\
> ?struct clk clk_##_name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> - ? ? ? ? ? ? ? .clk_rst ? ? ? ?= (void __iomem *)APMU_##_reg, ?\
> + ? ? ? ? ? ? ? .clk_rst ? ? ? ?= APMU_##_reg, ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.enable_val ? ? = _eval, ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.rate ? ? ? ? ? = _rate, ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.ops ? ? ? ? ? ?= &apmu_clk_ops, ? ? ? ? ? ? ? ?\
> @@ -54,7 +54,7 @@ struct clk clk_##_name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
>
> ?#define APMU_CLK_OPS(_name, _reg, _eval, _rate, _ops) ? ? ? ? ?\
> ?struct clk clk_##_name = { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> - ? ? ? ? ? ? ? .clk_rst ? ? ? ?= (void __iomem *)APMU_##_reg, ?\
> + ? ? ? ? ? ? ? .clk_rst ? ? ? ?= APMU_##_reg, ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.enable_val ? ? = _eval, ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.rate ? ? ? ? ? = _rate, ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ? ? ? ? ?.ops ? ? ? ? ? ?= _ops, ? ? ? ? ? ? ? ? ? ? ? ? \
> diff --git a/arch/arm/mach-mmp/common.c b/arch/arm/mach-mmp/common.c
> index 0ec0ca8..5720674 100644
> --- a/arch/arm/mach-mmp/common.c
> +++ b/arch/arm/mach-mmp/common.c
> @@ -27,12 +27,12 @@ EXPORT_SYMBOL(mmp_chip_id);
> ?static struct map_desc standard_io_desc[] __initdata = {
> ? ? ? ?{
> ? ? ? ? ? ? ? ?.pfn ? ? ? ? ? ?= __phys_to_pfn(APB_PHYS_BASE),
> - ? ? ? ? ? ? ? .virtual ? ? ? ?= APB_VIRT_BASE,
> + ? ? ? ? ? ? ? .virtual ? ? ? ?= (unsigned long)APB_VIRT_BASE,
> ? ? ? ? ? ? ? ?.length ? ? ? ? = APB_PHYS_SIZE,
> ? ? ? ? ? ? ? ?.type ? ? ? ? ? = MT_DEVICE,
> ? ? ? ?}, {
> ? ? ? ? ? ? ? ?.pfn ? ? ? ? ? ?= __phys_to_pfn(AXI_PHYS_BASE),
> - ? ? ? ? ? ? ? .virtual ? ? ? ?= AXI_VIRT_BASE,
> + ? ? ? ? ? ? ? .virtual ? ? ? ?= (unsigned long)AXI_VIRT_BASE,
> ? ? ? ? ? ? ? ?.length ? ? ? ? = AXI_PHYS_SIZE,
> ? ? ? ? ? ? ? ?.type ? ? ? ? ? = MT_DEVICE,
> ? ? ? ?},
> diff --git a/arch/arm/mach-mmp/include/mach/addr-map.h b/arch/arm/mach-mmp/include/mach/addr-map.h
> index 3254089..3e404ac 100644
> --- a/arch/arm/mach-mmp/include/mach/addr-map.h
> +++ b/arch/arm/mach-mmp/include/mach/addr-map.h
> @@ -11,6 +11,12 @@
> ?#ifndef __ASM_MACH_ADDR_MAP_H
> ?#define __ASM_MACH_ADDR_MAP_H
>
> +#ifndef __ASSEMBLER__
> +#define IOMEM(x) ? ? ? ((void __iomem *)(x))
> +#else
> +#define IOMEM(x) ? ? ? (x)
> +#endif
> +
> ?/* APB - Application Subsystem Peripheral Bus
> ?*
> ?* NOTE: the DMA controller registers are actually on the AXI fabric #1
> @@ -18,11 +24,11 @@
> ?* peripherals on APB, let's count it into the ABP mapping area.
> ?*/
> ?#define APB_PHYS_BASE ? ? ? ? ?0xd4000000
> -#define APB_VIRT_BASE ? ? ? ? ?0xfe000000
> +#define APB_VIRT_BASE ? ? ? ? ?IOMEM(0xfe000000)
To be honest, I'd really like to keep the *_VIRT_BASE definitions to be
type independent.
And have the actual register definitions to be casted to void __iomem *
when being defined, e.g.
#define APBC_REG(x) IOMEM(APBC_VIRT_BASE + (x))
#define APBC_UART1 APBC_REG(0x000)
Arnd, do we have some standard guidelines on this for all SoCs
to follow? As I know, it's currently still being a mess.
^ permalink raw reply
* [PATCH 2/4] ARM: OMAP4 PM: Add IO Daisychain support
From: Paul Walmsley @ 2011-10-07 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317750724-32553-3-git-send-email-vishwanath.bs@ti.com>
Hi
some comments:
On Tue, 4 Oct 2011, Vishwanath BS wrote:
> From: Rajendra Nayak <rnayak@ti.com>
>
> patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in OMAP4430
> Public TRM.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
> ---
> arch/arm/mach-omap2/pm.h | 1 +
> arch/arm/mach-omap2/pm44xx.c | 36 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 37 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index 9a36a7c..2e09d72 100644
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -22,6 +22,7 @@ extern int omap3_can_sleep(void);
> extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
> extern int omap3_idle_init(void);
> extern void omap3_enable_io_chain(void);
> +extern void omap4_trigger_wuclk_ctrl(void);
>
> #if defined(CONFIG_PM_OPP)
> extern int omap3_opp_init(void);
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> index 59a870b..aa7cff4 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm44xx.c
> @@ -16,8 +16,17 @@
> #include <linux/err.h>
> #include <linux/slab.h>
>
> +#include <plat/common.h>
> +
> #include "powerdomain.h"
> #include <mach/omap4-common.h>
> +#include "pm.h"
> +#include "cm-regbits-44xx.h"
> +#include "cminst44xx.h"
> +#include "prm-regbits-44xx.h"
> +#include "prcm44xx.h"
> +#include "prm44xx.h"
> +#include "prminst44xx.h"
>
> struct power_state {
> struct powerdomain *pwrdm;
> @@ -30,6 +39,33 @@ struct power_state {
>
> static LIST_HEAD(pwrst_list);
>
> +#define MAX_IOPAD_LATCH_TIME 1000
This macro is missing a comment, which should precede it, describing what
this value is.
> +
> +void omap4_trigger_wuclk_ctrl(void)
> +{
> + int i = 0;
> +
> + /* Enable GLOBAL_WUEN */
> + if (!omap4_cminst_read_inst_reg_bits(OMAP4430_PRM_PARTITION,
> + OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET,
> + OMAP4430_GLOBAL_WUEN_MASK))
The above line doesn't look right. It's accessing a PRM instance register
with omap4_cminst_*()? Shouldn't that be omap4_prminst_*()?
> + omap4_prminst_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
> + OMAP4430_GLOBAL_WUEN_MASK, OMAP4430_PRM_PARTITION,
> + OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
> +
> + /* Trigger WUCLKIN enable */
> + omap4_prminst_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, OMAP4430_WUCLK_CTRL_MASK,
> + OMAP4430_PRM_PARTITION, OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
> + omap_test_timeout(
> + ((omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION, OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET)
> + >> OMAP4430_WUCLK_STATUS_SHIFT) == 1),
> + MAX_IOPAD_LATCH_TIME, i);
> + /* Trigger WUCLKIN disable */
> + omap4_prminst_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
> + OMAP4430_PRM_PARTITION, OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
> + return;
> +}
This function belongs in mach-omap2/prminst44xx.c. I still think it would
be good if we moved all PRM/CM direct register accesses into prm*.c or
cm*.c files in mach-omap2/. Then none of those prm*.h includes would be
needed in pm44xx.c either.
> +
> #ifdef CONFIG_SUSPEND
> static int omap4_pm_suspend(void)
> {
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
- Paul
^ permalink raw reply
* [PATCH 1/4] ARM: OMAP3 PM: Fix IO Daisychain sequence
From: Paul Walmsley @ 2011-10-07 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317750724-32553-2-git-send-email-vishwanath.bs@ti.com>
Hi
a few comments:
On Tue, 4 Oct 2011, Vishwanath BS wrote:
> As per OMAP3630 TRM Section 3.5.7.2.2, the right sequence for enabling IO Daisy
> chain is "The I/O wake-up scheme is enabled by triggering the I/O daisy chain
> control (Wu clock) by programming a dedicated register
> (PRCM.PM_WKEN_WKUP[16] EN_IO_CHAIN) in the PRCM module.Software must wait for
> the I/O daisy chain to complete before it transitions the PER domain to a
> nonfunctional state. This is done by polling a dedicated status bit in the PRCM
> module (PRCM.PM_WKST_WKUP[16] ST_IO_CHAIN). This status bit must be cleared by
> software when the bit is read to 1".
>
> The original code was polling on a wrong register which is fixed in this patch.
> Also omap3_enable_io_chain is made non static as it's going to be used in
> subsequent patches.
This patch should be split into a fix (for the WKEN/WKST bug) and then a
new patch that drops the 'static'. The new patch should also move this
function to prm2xxx_3xxx.c for the same reason that the OMAP4 version of
this function should be in prminst44xx.c.
In the medium-term, a bunch of the functions from prm2xxx_3xxx.c,
prminst44xx.c, etc. that are only used by the mach-omap2/pm*.c code should
be moved into the PRM driver that Tero is working on that will live in
drivers/.
>
> Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
> ---
> arch/arm/mach-omap2/pm.h | 1 +
> arch/arm/mach-omap2/pm34xx.c | 6 +++---
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index 4e166ad..9a36a7c 100644
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -21,6 +21,7 @@ extern void omap_sram_idle(void);
> extern int omap3_can_sleep(void);
> extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
> extern int omap3_idle_init(void);
> +extern void omap3_enable_io_chain(void);
>
> #if defined(CONFIG_PM_OPP)
> extern int omap3_opp_init(void);
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 7255d9b..61f1a5b 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -95,7 +95,7 @@ static inline void omap3_per_restore_context(void)
> omap_gpio_restore_context();
> }
>
> -static void omap3_enable_io_chain(void)
> +void omap3_enable_io_chain(void)
> {
> int timeout = 0;
>
> @@ -105,7 +105,7 @@ static void omap3_enable_io_chain(void)
> /* Do a readback to assure write has been done */
> omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
>
> - while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN) &
> + while (!(omap2_prm_read_mod_reg(WKUP_MOD, PM_WKST) &
> OMAP3430_ST_IO_CHAIN_MASK)) {
> timeout++;
> if (timeout > 1000) {
> @@ -114,7 +114,7 @@ static void omap3_enable_io_chain(void)
> return;
> }
> omap2_prm_set_mod_reg_bits(OMAP3430_ST_IO_CHAIN_MASK,
> - WKUP_MOD, PM_WKEN);
> + WKUP_MOD, PM_WKST);
> }
> }
> }
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
- Paul
^ permalink raw reply
* [PATCH 14/26] mtd: nand_h1900 never worked
From: Eric Miao @ 2011-10-07 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317499438-14058-15-git-send-email-arnd@arndb.de>
On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> This driver has been broken through all of git history and
> cannot even be built. Better mark it as broken. Next stop is
> removing from the tree.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Artem Bityutskiy <dedekind1@gmail.com>
> Cc: Jamie Iles <jamie@jamieiles.com>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
> ---
> ?drivers/mtd/nand/Kconfig | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 4c342523..f85af18 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -92,7 +92,7 @@ config MTD_NAND_EDB7312
>
> ?config MTD_NAND_H1900
> ? ? ? ?tristate "iPAQ H1900 flash"
> - ? ? ? depends on ARCH_PXA
> + ? ? ? depends on ARCH_PXA && BROKEN
> ? ? ? ?help
> ? ? ? ? ?This enables the driver for the iPAQ h1900 flash.
>
> --
> 1.7.5.4
>
>
^ permalink raw reply
* [PATCH 15/26] irda/ficp: only works on some pxa models
From: Eric Miao @ 2011-10-07 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317499438-14058-16-git-send-email-arnd@arndb.de>
On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> This driver can only be built for pxa25x and pxa27x at the moment,
> so encode that in Kconfig.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Samuel Ortiz <samuel@sortiz.org>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
> ---
> ?drivers/net/irda/Kconfig | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/irda/Kconfig b/drivers/net/irda/Kconfig
> index 25bb2a0..8cffd38 100644
> --- a/drivers/net/irda/Kconfig
> +++ b/drivers/net/irda/Kconfig
> @@ -373,7 +373,7 @@ config VIA_FIR
>
> ?config PXA_FICP
> ? ? ? ?tristate "Intel PXA2xx Internal FICP"
> - ? ? ? depends on ARCH_PXA && IRDA
> + ? ? ? depends on ARCH_PXA && IRDA && (PXA25x || PXA27x)
> ? ? ? ?help
> ? ? ? ? ?Say Y or M here if you want to build support for the PXA2xx
> ? ? ? ? ?built-in IRDA interface which can support both SIR and FIR.
> --
> 1.7.5.4
>
>
^ permalink raw reply
* [PATCH v2 6/6] OMAP4: Clock: Correct the name of SLIMBUS interface clocks
From: Cousson, Benoit @ 2011-10-07 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1110061941100.4611@utopia.booyaka.com>
Hi Paul & Jon,
On 10/7/2011 3:42 AM, Paul Walmsley wrote:
> + Beno?t
>
> On Fri, 16 Sep 2011, Jon Hunter wrote:
>
>> From: Jon Hunter<jon-hunter@ti.com>
>>
>> Currently the interface clocks for the two SLIMBUS peripherals are
>> named slimbus1_fck and slimbus2_fck. Rename these clocks to be
>> slimbus1_ick and slimbus2_ick so it is clear that these are
>> interface clocks and not functional clocks.
>>
>> Signed-off-by: Jon Hunter<jon-hunter@ti.com>
>
> This one, I don't quite understand. We should probably be removing these
> MODULEMODE-only clocks from the OMAP4 tree, and using their parent clock
> as the main_clk. That would be a good cleanup for 3.3...
Yes, but in order to remove that from the clock data we must ensure that
the hwmod entry is there.
I kept a lot of legacy MODULEMODE clocks just because of missing hwmod /
runtime_pm adaptation on some drivers.
In the case of slimbus, there is no main_clk but a bunch of optional
clocks. It looks similar to the DSS case. So we should not use the
parent clock as a main_clk.
We should probably promote one of the opt_clk as the main_clk. The
slimbus_clk seems to be the good candidate for both instances.
static struct omap_hwmod_opt_clk slimbus1_opt_clks[] = {
{ .role = "fclk_1", .clk = "slimbus1_fclk_1" },
{ .role = "fclk_0", .clk = "slimbus1_fclk_0" },
{ .role = "fclk_2", .clk = "slimbus1_fclk_2" },
{ .role = "slimbus_clk", .clk = "slimbus1_slimbus_clk" },
};
static struct omap_hwmod_opt_clk slimbus2_opt_clks[] = {
{ .role = "fclk_1", .clk = "slimbus2_fclk_1" },
{ .role = "fclk_0", .clk = "slimbus2_fclk_0" },
{ .role = "slimbus_clk", .clk = "slimbus2_slimbus_clk" },
};
Jon,
Do you know if that one is indeed mandatory to use the slimbus IP?
Thanks,
Benoit
^ 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