* [PATCH 0/2] OMAP: Update nr_irqs field in machine descriptors
From: Tony Lindgren @ 2011-10-07 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1110071612380.6390@xanadu.home>
* Nicolas Pitre <nico@fluxnic.net> [111007 12:41]:
> On Thu, 6 Oct 2011, Tony Lindgren wrote:
>
> > * S, Venkatraman <svenkatr@ti.com> [110825 07:23]:
> > > On Thu, Aug 25, 2011 at 5:19 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> > > > Hi Venkat,
> > > >
> > > > On 8/24/2011 9:46 PM, S, Venkatraman wrote:
> > > >>
> > > >> As part of an effort to get single ARM kernel binary [1],
> > > >> multiple ?definitions of NR_IRQS under various platforms
> > > >> have to be reconciled and abstracted away from common code.
> > > >>
> > > >> This patch series takes the small step of populating the
> > > >> machine descriptors with the pre-existing nr_irqs field.
> > > >> Eventually, the common irq handler code will only look at this
> > > >> field and not the compile time constant.
> > > >
> > > > Not related to this patch, but still on that topic. The current NR_IRQS
> > > > depends as well on board stuff, like for example : the Phoenix
> > > > IRQs:TWL6030_IRQ_BASE, TWL6040_CODEC_IRQ_BASE.
> > > > Is there a plan to get rid of this static defines?
> > > >
> > >
> > > Currently, the goal is to get rid of the singleton nature
> > > of NR_IRQS. Then it just becomes a property of the
> > > platform, and the arm common code should not see this define.
> > > This cleanup has to be done across multiple SoCs, not just OMAP.
> > >
> > > After I get to complete some meaningful cleanup of NR_IRQS,
> > > I can look into the static defines that you mention.
> >
> > I suggest we wait on this patch as the NR_IRQS should be the
> > board specific true number of interrupts including chained
> > interrupts from external devices like twl. So just setting
> > it to NR_IRQS does not help much. Also, the board-*.c files
> > will be going aways with device tree at some point.
>
> This is prerequisite to some other cleanup orthogonal to DT being worked
> in parallel. I would prefer if DT wasn't a serialization point for
> this.
I see. How about let's populate the real number of interrupts for the
known boards then while at it.
Tony
^ permalink raw reply
* [PATCH 2/5] drivercore: Add driver probe deferral mechanism
From: Josh Triplett @ 2011-10-07 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111007064928.GE27508@kroah.com>
On Thu, Oct 06, 2011 at 11:49:28PM -0700, Greg KH wrote:
> On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
> > +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.
Given that the drivers which use this mechanism will not necessarily get
built into the kernel, I'd suggest that it should remain optional and
default to n. Those drivers can then add a dependency on PROBE_DEFER.
Let's try to avoid adding more infrastructure to the kernel that takes
up space even when unused; certainly embedded will appreciate not having
this feature unless a driver needs it.
(That said, it still feels to me like an explicit dependency mechanism
would make more sense than this "try again later" mechanism, but
nonetheless "try again later" seems like an improvement over what we
have now.)
> It also cleans up this diff a lot, as you really don't want #ifdef in .c
> files.
Ideally the entire .c file could become conditional on PROBE_DEFER via
kbuild, with the usual compatibility inlines in a .h file for the
!PROBE_DEFER case.
- Josh Triplett
^ permalink raw reply
* [GIT PULL] OMAP: few more PM cleanup/fixes for v3.2
From: Kevin Hilman @ 2011-10-07 21:03 UTC (permalink / raw)
To: linux-arm-kernel
Tony,
Please pull the (hopefully) last few PM fixes/cleanups for v3.2.
Kevin
The following changes since commit 976d167615b64e14bc1491ca51d424e2ba9a5e84:
Linux 3.1-rc9 (2011-10-04 18:11:50 -0700)
are available in the git repository at:
git://github.com/khilman/linux-omap-pm.git for_3.2/pm-cleanup-2
Charulatha V (1):
ARM: OMAP3: PM: fix pwrdm_post_transition call sequence
Paul Walmsley (2):
ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock control detection
ARM: OMAP3: PM: restrict erratum i443 handling to OMAP3430 only
arch/arm/mach-omap2/id.c | 5 ++-
arch/arm/mach-omap2/pm34xx.c | 70 +++++++++++++++++---------------
arch/arm/plat-omap/include/plat/cpu.h | 17 ++++++--
3 files changed, 53 insertions(+), 39 deletions(-)
^ permalink raw reply
* [GIT PULL] ARM: CSR: l2x0 init cleanup for 3.2
From: Arnd Bergmann @ 2011-10-07 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4xNqgDSWs-WQCamE592NB_p4r4+sY8-XSrzbkei1jeB7Q@mail.gmail.com>
On Saturday 01 October 2011, Barry Song wrote:
> Since the l2x0 cleanup of prima2 depends on the following two patches
> in rmk's tree:
>
> [1]Rob Herring
> ARM: 7009/1: l2x0: Add OF based initialization
> http://www.spinics.net/lists/arm-kernel/msg131123.html
> it has been in rmk/for-next
>
> [2]Barry Song
> ARM: 7009/1: CACHE-L2X0: filter start address can be 0 and is often 0
> http://www.spinics.net/lists/arm-kernel/msg140126.html
> it has been in rmk/for-next
>
> I have rebased the l2x0-cleanup branch to "ARM: 7009/1: CACHE-L2X0:
> filter start address can be 0 and is often 0". this might cause some
> issues to you. if that is difficult to you, i guess you can pich the
> commmit and apply it when your tree has been ready.
>
> The following changes since commit 513d47a3d953e44d79c29077f6c428a017f8af62:
> Barry Song (1):
> ARM: 7090/1: CACHE-L2X0: filter start address can be 0 and is often 0
>
> are available in the git repository at:
>
> git://gitorious.org/sirfprima2-kernel/sirfprima2-kernel.git l2x0-cleanup
I think I can keep track of this, but is the commit that you used actually
from a stable branch in Russell's tree? If that gets rebased, I should
not pull your patch in.
Arnd
^ permalink raw reply
* [GIT PULL] ARM: CSR: cleanup some minor coding-style issues for 3.2
From: Arnd Bergmann @ 2011-10-07 21:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4w63t=EBFxJM0uum3FBqp5HY0ufi3v4Z+g4s2Hgmh-CzA@mail.gmail.com>
On Saturday 01 October 2011, Barry Song wrote:
> The following changes since commit d93dc5c4478c1fd5de85a3e8aece9aad7bbae044:
> Linus Torvalds (1):
> Linux 3.1-rc7
>
> are available in the git repository at:
>
> git at gitorious.org:sirfprima2-kernel/sirfprima2-kernel.git fixes
>
> Barry Song (4):
> ARM: CSR: timer: do not initialise statics to 0 or NULL
> ARM: CSR: timer: space required before the open parenthesis '('
> ARM: CSR: prima2: fix trailing whitespace
> ARM: CSR: clock: Fix indentation
Pulled, thanks!
Arnd
^ permalink raw reply
* [PATCH 2/5] drivercore: Add driver probe deferral mechanism
From: Greg KH @ 2011-10-07 21:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111007205715.GC5275@leaf>
On Fri, Oct 07, 2011 at 01:57:15PM -0700, Josh Triplett wrote:
> On Thu, Oct 06, 2011 at 11:49:28PM -0700, Greg KH wrote:
> > On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
> > > +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.
>
> Given that the drivers which use this mechanism will not necessarily get
> built into the kernel, I'd suggest that it should remain optional and
> default to n. Those drivers can then add a dependency on PROBE_DEFER.
> Let's try to avoid adding more infrastructure to the kernel that takes
> up space even when unused; certainly embedded will appreciate not having
> this feature unless a driver needs it.
How much extra space is this "feature" really? I don't see it being
anything larger than the amount of memory increase that just happened as
I typed this email as part of the ongoing memory density changes.
greg k-h
^ permalink raw reply
* [PATCH 2/5] drivercore: Add driver probe deferral mechanism
From: Grant Likely @ 2011-10-07 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111007064928.GE27508@kroah.com>
On Fri, Oct 7, 2011 at 12:49 AM, Greg KH <greg@kroah.com> wrote:
> On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
>> +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.
Okay, we'll drop the kconfig
>> + ? ? ?* 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?
This comment block is stale. I reworked the code before I handed it
off to Manjunath, but I never rewrote the comment. The current code
uses a pair of list to keep deferred devices separate from devices
currently being probed, and the problem described above no longer
exists. However, Manjunath and I will look into switching from the
two list design to using klist.
Thanks for the feedback.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] MAINTAINERS: Update tegra maintainer information
From: Stephen Warren @ 2011-10-07 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318019268-6946-1-git-send-email-olof@lixom.net>
Olof Johansson wrote at Friday, October 07, 2011 2:28 PM:
> A couple of changes to the Tegra maintainership setup:
>
> I'm very glad to bring on Stephen Warren on board as a maintainer. The
> work he has done so far is excellent, and the fact that he works for
> Nvidia means he has long-term interest in the platform.
Thanks for bringing me on board.
Acked-by: Stephen Warren <swarren@nvidia.com>
> Erik Gilling did an astounding amount of work on getting things up and
> running but has been a silent partner on the maintainership side for a
> while, and is stepping down. Thanks for your contributions so far, Erik.
I'd like to echo this, and also extend it to everyone else who's brought
Tegra support to the point where it is today.
--
nvpublic
^ permalink raw reply
* [PATCH 4/5] gpiolib: handle deferral probe error
From: Grant Likely @ 2011-10-07 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111007110615.7638e905@lxorguk.ukuu.org.uk>
On Fri, Oct 7, 2011 at 4:06 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Fri, 07 Oct 2011 10:33:09 +0500
> "G, Manjunath Kondaiah" <manjugk@ti.com> wrote:
>
>>
>> The gpio library should return -EPROBE_DEFER in gpio_request
>> if gpio driver is not ready.
>
> Why not use the perfectly good existing error codes we have for this ?
>
> We have EAGAIN and EUNATCH both of which look sensible.
I want a distinct error code for probe deferral so that a) it doesn't
overlap with something a driver is already doing, and b) so that all
the users can be found again at a later date.
That said, I'm not in agreement with this patch. It is fine for gpio
lib to have a code that means the pin doesn't exist (yet), but the
device driver needs to be the one to decide whether or not it is
appropriate to use probe deferral.
g.
^ permalink raw reply
* [PATCH 1/5] drivercore: add new error value for deferred probe
From: Grant Likely @ 2011-10-07 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111007064349.GD27508@kroah.com>
On Fri, Oct 7, 2011 at 12:43 AM, Greg KH <greg@kroah.com> wrote:
> 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?
According to Arnd, yes this is okay.
> ?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?
overloading makes it really hard to find the users at a later date.
g.
^ permalink raw reply
* [PATCH v2 5/6] OMAP3+: Update DPLL Fint range for OMAP36xx and OMAP4xxx devices
From: Jon Hunter @ 2011-10-07 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1110061938210.4611@utopia.booyaka.com>
Hi Paul,
On 10/6/2011 20:40, Paul Walmsley wrote:
> On Fri, 16 Sep 2011, Jon Hunter wrote:
>
>> From: Jon Hunter<jon-hunter@ti.com>
>>
>> The OMAP36xx and OMAP4xxx DPLLs have a different internal reference
>> clock frequency (fint) operating range than OMAP3430. Update the
>> dpll_test_fint() function to check for the correct frequency ranges
>> for OMAP36xx and OMAP4xxx.
>>
>> For OMAP36xx and OMAP4xxx devices, DPLLs fint range is 0.5MHz to
>> 2.5MHz for j-type DPLLs and otherwise it is 32KHz to 52MHz for all
>> other DPLLs.
>>
>> Signed-off-by: Jon Hunter<jon-hunter@ti.com>
>
> This looks okay to me for now - queued for 3.2. Ideally we would move the
> Fint DPLL data to the struct dpll_data, but this would be a fairly
> significant undertaking, since we don't have a clean way to use different
> dpll_data for different OMAP3 variants. Something good to keep in mind
> for the common clock conversion.
You know at first I was thinking about adding this to the dpll_data
struct, but then I thought these ranges only change for a couple dplls
and so adding a few more members to each dpll struct was bloating the
struct and making this a massive change. So I went the other path and
just added a couple defines to minimise the changes. However, we could
definitely do that if it is preferred and if with next-gen devices (such
as omap5) more dplls have different ranges then this would make more
sense too.
Cheers
Jon
^ permalink raw reply
* [PATCH 0/2] OMAP: Update nr_irqs field in machine descriptors
From: Nicolas Pitre @ 2011-10-07 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111007205145.GA2293@atomide.com>
On Fri, 7 Oct 2011, Tony Lindgren wrote:
> * Nicolas Pitre <nico@fluxnic.net> [111007 12:41]:
> > On Thu, 6 Oct 2011, Tony Lindgren wrote:
> >
> > > * S, Venkatraman <svenkatr@ti.com> [110825 07:23]:
> > > > On Thu, Aug 25, 2011 at 5:19 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> > > > > Hi Venkat,
> > > > >
> > > > > On 8/24/2011 9:46 PM, S, Venkatraman wrote:
> > > > >>
> > > > >> As part of an effort to get single ARM kernel binary [1],
> > > > >> multiple ?definitions of NR_IRQS under various platforms
> > > > >> have to be reconciled and abstracted away from common code.
> > > > >>
> > > > >> This patch series takes the small step of populating the
> > > > >> machine descriptors with the pre-existing nr_irqs field.
> > > > >> Eventually, the common irq handler code will only look at this
> > > > >> field and not the compile time constant.
> > > > >
> > > > > Not related to this patch, but still on that topic. The current NR_IRQS
> > > > > depends as well on board stuff, like for example : the Phoenix
> > > > > IRQs:TWL6030_IRQ_BASE, TWL6040_CODEC_IRQ_BASE.
> > > > > Is there a plan to get rid of this static defines?
> > > > >
> > > >
> > > > Currently, the goal is to get rid of the singleton nature
> > > > of NR_IRQS. Then it just becomes a property of the
> > > > platform, and the arm common code should not see this define.
> > > > This cleanup has to be done across multiple SoCs, not just OMAP.
> > > >
> > > > After I get to complete some meaningful cleanup of NR_IRQS,
> > > > I can look into the static defines that you mention.
> > >
> > > I suggest we wait on this patch as the NR_IRQS should be the
> > > board specific true number of interrupts including chained
> > > interrupts from external devices like twl. So just setting
> > > it to NR_IRQS does not help much. Also, the board-*.c files
> > > will be going aways with device tree at some point.
> >
> > This is prerequisite to some other cleanup orthogonal to DT being worked
> > in parallel. I would prefer if DT wasn't a serialization point for
> > this.
>
> I see. How about let's populate the real number of interrupts for the
> known boards then while at it.
Sure, if you know what you are doing (which I'm sure you do).
Otherwise using NR_IRQS is more or less a functional no-op wrt the
current situation, and therefore what I would have used myself because I
don't know much about the various OMAP boards.
Nicolas
^ permalink raw reply
* [PATCH 5/5] omap: hsmmc: use platform_driver_register
From: Grant Likely @ 2011-10-07 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317962127-29003-6-git-send-email-manjugk@ti.com>
On Thu, Oct 6, 2011 at 11:05 PM, G, Manjunath Kondaiah <manjugk@ti.com> wrote:
>
> Existing omap hsmmc driver uses "platform_driver_probe" in init
> function. Change it to use "platform_driver_register" in order to
> use deferral probe mechanism.
>
> Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
> Reported-by: Grant Likely <grant.likely@secretlab.ca>
Acked-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>
>
> ?drivers/mmc/host/omap_hsmmc.c | ? ?7 ++++---
> ?1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 21e4a79..8dd2e7c 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1862,7 +1862,7 @@ static void omap_hsmmc_debugfs(struct mmc_host *mmc)
>
> ?#endif
>
> -static int __init omap_hsmmc_probe(struct platform_device *pdev)
> +static int __devinit omap_hsmmc_probe(struct platform_device *pdev)
> ?{
> ? ? ? ?struct omap_mmc_platform_data *pdata = pdev->dev.platform_data;
> ? ? ? ?struct mmc_host *mmc;
> @@ -2077,6 +2077,7 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)
> ? ? ? ?pm_runtime_mark_last_busy(host->dev);
> ? ? ? ?pm_runtime_put_autosuspend(host->dev);
>
> + ? ? ? dev_dbg(mmc_dev(host->mmc), "Probe success...\n");
> ? ? ? ?return 0;
>
> ?err_slot_name:
> @@ -2270,6 +2271,7 @@ static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
> ?};
>
> ?static struct platform_driver omap_hsmmc_driver = {
> + ? ? ? .probe ? ? ? ? ?= omap_hsmmc_probe,
> ? ? ? ?.remove ? ? ? ? = omap_hsmmc_remove,
> ? ? ? ?.driver ? ? ? ? = {
> ? ? ? ? ? ? ? ?.name = DRIVER_NAME,
> @@ -2280,8 +2282,7 @@ static struct platform_driver omap_hsmmc_driver = {
>
> ?static int __init omap_hsmmc_init(void)
> ?{
> - ? ? ? /* Register the MMC driver */
> - ? ? ? return platform_driver_probe(&omap_hsmmc_driver, omap_hsmmc_probe);
> + ? ? ? return platform_driver_register(&omap_hsmmc_driver);
> ?}
>
> ?static void __exit omap_hsmmc_cleanup(void)
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] ARM: PM: build sleep/suspend code for idle path also (not only suspend)
From: Kevin Hilman @ 2011-10-07 22:31 UTC (permalink / raw)
To: linux-arm-kernel
Some platforms (e.g. OMAP) use the same common cpu_suspend/cpu_resume
helpers during idle as well as suspend.
Currently, if suspend is disabled (CONFIG_PM_SLEEP=n) and the platform
idle code is using the common cpu_suspend/cpu_resume functions, the
kernel will not link.
Since platform code commonly uses CONFIG_PM=y to build it's idle code,
build the common sleep/suspend code based on CONFIG_PM instead of
CONFIG_PM_SLEEP.
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
Applies on Russell's devel-stable branch, where the new common
suspend/resume code is queued.
arch/arm/kernel/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 8fa83f5..25d3a0c 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -29,7 +29,7 @@ obj-$(CONFIG_MODULES) += armksyms.o module.o
obj-$(CONFIG_ARTHUR) += arthur.o
obj-$(CONFIG_ISA_DMA) += dma-isa.o
obj-$(CONFIG_PCI) += bios32.o isa.o
-obj-$(CONFIG_PM_SLEEP) += sleep.o suspend.o
+obj-$(CONFIG_PM) += sleep.o suspend.o
obj-$(CONFIG_HAVE_SCHED_CLOCK) += sched_clock.o
obj-$(CONFIG_SMP) += smp.o smp_tlb.o
obj-$(CONFIG_HAVE_ARM_SCU) += smp_scu.o
--
1.7.6
^ permalink raw reply related
* [PATCH 00/24 V2] OMAP4: PM: suspend, CPU-hotplug and CPUilde support
From: Kevin Hilman @ 2011-10-07 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316844884-21700-1-git-send-email-santosh.shilimkar@ti.com>
Hi Santosh,
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> The series adds OMAP4 MPUSS (MPU SubSystem) power management support for
> suspend (S2R), CPU hotplug and CPUidle.
Just noticed when doing some final build/sanity testing that there are a
few of compile/link warnings/problems when the kernel is built without
CONFIG_PM
Some warnings:
/work/kernel/omap/pm/arch/arm/mach-omap2/omap-wakeupgen.c:203:13: warning: 'irq_save_context' defined but not used
/work/kernel/omap/pm/arch/arm/mach-omap2/omap-wakeupgen.c:270:13: warning: 'irq_save_secure_context' defined but not used
and some failures (these happen when CONFIG_SUSPEND=n but CONFIG_PM_RUNTIME=y:
arch/arm/mach-omap2/built-in.o: In function `skip_l2en':
/work/kernel/omap/pm/arch/arm/mach-omap2/sleep44xx.S:323: undefined reference to `cpu_resume'
arch/arm/mach-omap2/built-in.o: In function `omap_sram_idle':
/work/kernel/omap/pm/arch/arm/mach-omap2/pm34xx.c:429: undefined reference to `cpu_suspend'
arch/arm/mach-omap2/built-in.o: In function `skipl2reen':
/work/kernel/omap/pm/arch/arm/mach-omap2/sleep34xx.S:534: undefined reference to `cpu_resume'
arch/arm/mach-omap2/built-in.o: In function `omap4_enter_lowpower':
/work/kernel/omap/pm/arch/arm/mach-omap2/omap-mpuss-lowpower.c:281: undefined reference to `cpu_suspend'
Turns out these are not directly related to your series and OMAP3
exhibits the same problems.
I just posted a patch[1] to attempt to address these.
But could you fixup the first problem and test with [1] to see if things
still build/work as expected.
Thanks,
Kevin
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-October/068606.html
^ permalink raw reply
* [PATCH] ARM: PM: build sleep/suspend code for idle path also (not only suspend)
From: Russell King - ARM Linux @ 2011-10-07 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318026686-20191-1-git-send-email-khilman@ti.com>
On Fri, Oct 07, 2011 at 03:31:26PM -0700, Kevin Hilman wrote:
> Some platforms (e.g. OMAP) use the same common cpu_suspend/cpu_resume
> helpers during idle as well as suspend.
>
> Currently, if suspend is disabled (CONFIG_PM_SLEEP=n) and the platform
> idle code is using the common cpu_suspend/cpu_resume functions, the
> kernel will not link.
>
> Since platform code commonly uses CONFIG_PM=y to build it's idle code,
> build the common sleep/suspend code based on CONFIG_PM instead of
> CONFIG_PM_SLEEP.
>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
> Applies on Russell's devel-stable branch, where the new common
> suspend/resume code is queued.
See:
commit 15e0d9e37c7fe9711b60f47221c394d45553ad8c
Author: Arnd Bergmann <arnd@arndb.de>
Date: Sat Oct 1 21:09:39 2011 +0200
ARM: pm: let platforms select cpu_suspend support
Support for the cpu_suspend functions is only built-in
when CONFIG_PM_SLEEP is enabled, but omap3/4, exynos4
and pxa always call cpu_suspend when CONFIG_PM is enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH v2 6/6] OMAP4: Clock: Correct the name of SLIMBUS interface clocks
From: Jon Hunter @ 2011-10-07 22:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8EB6ED.9020605@ti.com>
Hi Benoit,
On 10/7/2011 3:23, Cousson, Benoit wrote:
> 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?
Sorry, are you asking about the clocks I was re-naming or the
slimbus_clk you are referring to above?
Looking at the clock tree tool, the slimbus_clk is the actual external
slimbus clock that can be generated by OMAP or by an external device.
The TRM states ...
"Most of the SLIMbus module runs off two main clocks: the L4 interface
clock for the data input and output registers, and the control and
status control registers; and the SLIMbus clock, taken from the serial
interface (CLK line) for the SLIMbus-side logic.
The SLIMbus controller operates as clock source component (active
framer), which drives the SLIMbus clock line CLK, or as clock receiver
component, which gets its clock from the same CLK line."
So, if you are operating as the clock source component on the bus then
one of the optional clocks to drive the peripheral logic and if you are
the clock receiver then you use slimbus_clk.
Cheers
Jon
^ permalink raw reply
* [PATCH] ARM: PM: build sleep/suspend code for idle path also (not only suspend)
From: Kevin Hilman @ 2011-10-07 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111007223922.GC26805@n2100.arm.linux.org.uk>
Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> On Fri, Oct 07, 2011 at 03:31:26PM -0700, Kevin Hilman wrote:
>> Some platforms (e.g. OMAP) use the same common cpu_suspend/cpu_resume
>> helpers during idle as well as suspend.
>>
>> Currently, if suspend is disabled (CONFIG_PM_SLEEP=n) and the platform
>> idle code is using the common cpu_suspend/cpu_resume functions, the
>> kernel will not link.
>>
>> Since platform code commonly uses CONFIG_PM=y to build it's idle code,
>> build the common sleep/suspend code based on CONFIG_PM instead of
>> CONFIG_PM_SLEEP.
>>
>> Signed-off-by: Kevin Hilman <khilman@ti.com>
>> ---
>> Applies on Russell's devel-stable branch, where the new common
>> suspend/resume code is queued.
>
> See:
>
> commit 15e0d9e37c7fe9711b60f47221c394d45553ad8c
> Author: Arnd Bergmann <arnd@arndb.de>
> Date: Sat Oct 1 21:09:39 2011 +0200
>
> ARM: pm: let platforms select cpu_suspend support
>
> Support for the cpu_suspend functions is only built-in
> when CONFIG_PM_SLEEP is enabled, but omap3/4, exynos4
> and pxa always call cpu_suspend when CONFIG_PM is enabled.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Nice. That will work too.
I see this in Arnd's randconfig/arm branch but not yet in
arm-soc/for-next. Is this being queued for v3.2?
This will also conflict with your devel-stable where the suspend.c is
added.
Kevin
^ permalink raw reply
* [PATCH 00/24 V2] OMAP4: PM: suspend, CPU-hotplug and CPUilde support
From: Kevin Hilman @ 2011-10-07 22:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87d3e8juqm.fsf@ti.com>
Kevin Hilman <khilman@ti.com> writes:
> Hi Santosh,
>
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> The series adds OMAP4 MPUSS (MPU SubSystem) power management support for
>> suspend (S2R), CPU hotplug and CPUidle.
>
> Just noticed when doing some final build/sanity testing that there are a
> few of compile/link warnings/problems when the kernel is built without
> CONFIG_PM
>
> Some warnings:
>
> /work/kernel/omap/pm/arch/arm/mach-omap2/omap-wakeupgen.c:203:13: warning: 'irq_save_context' defined but not used
> /work/kernel/omap/pm/arch/arm/mach-omap2/omap-wakeupgen.c:270:13: warning: 'irq_save_secure_context' defined but not used
>
> and some failures (these happen when CONFIG_SUSPEND=n but CONFIG_PM_RUNTIME=y:
>
> arch/arm/mach-omap2/built-in.o: In function `skip_l2en':
> /work/kernel/omap/pm/arch/arm/mach-omap2/sleep44xx.S:323: undefined reference to `cpu_resume'
> arch/arm/mach-omap2/built-in.o: In function `omap_sram_idle':
> /work/kernel/omap/pm/arch/arm/mach-omap2/pm34xx.c:429: undefined reference to `cpu_suspend'
> arch/arm/mach-omap2/built-in.o: In function `skipl2reen':
> /work/kernel/omap/pm/arch/arm/mach-omap2/sleep34xx.S:534: undefined reference to `cpu_resume'
> arch/arm/mach-omap2/built-in.o: In function `omap4_enter_lowpower':
> /work/kernel/omap/pm/arch/arm/mach-omap2/omap-mpuss-lowpower.c:281: undefined reference to `cpu_suspend'
>
> Turns out these are not directly related to your series and OMAP3
> exhibits the same problems.
>
> I just posted a patch[1] to attempt to address these.
>
> But could you fixup the first problem and test with [1] to see if things
> still build/work as expected.
OK, ignore my patch.
Arnd already has a fix for these link problems in his randconfig/arm
branch.
Please just cleanup the wakeupgen compile warnings and update your
branch.
Kevin
^ permalink raw reply
* [PATCH] ARM: PM: build sleep/suspend code for idle path also (not only suspend)
From: Russell King - ARM Linux @ 2011-10-07 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8739f4ju2m.fsf@ti.com>
On Fri, Oct 07, 2011 at 03:49:37PM -0700, Kevin Hilman wrote:
> I see this in Arnd's randconfig/arm branch but not yet in
> arm-soc/for-next. Is this being queued for v3.2?
Yes.
> This will also conflict with your devel-stable where the suspend.c is
> added.
Already sorted.
^ permalink raw reply
* [PATCH 4/5 v4] Realview PCIX support - add main support module code
From: Russell King - ARM Linux @ 2011-10-07 23:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111007142834.19554.69753.stgit@e102602-lin.cambridge.arm.com>
On Fri, Oct 07, 2011 at 03:28:55PM +0100, Colin Tuckley wrote:
> + /* Upstream port of 8518 device */
> + if (unlikely(dev->device == 0x8518 && dev->bus->primary == 0)) {
> + BUG_ON(pcie_bridge); /* Can't be already assigned */
> + pcie_bridge = dev;
> + }
I thought one of my previous review points on this was that it was
completely unsafe to match only on dev->device, rather than on both
dev->device and dev->vendor. Device IDs are allocated by individual
vendors and are meaningless without also checking the vendor ID.
> +
> + if (pcie_bridge) {
> + if (dev->bus->primary >= pcie_bridge->bus->secondary &&
> + dev->bus->primary <= pcie_bridge->bus->subordinate) {
> + /*
> + * The problem is that in PCIE in different slots a device
> + * could still get the same slot/pin/devslot triplet. Therefore
> + * we check the slot/pin/devslot triplet of an underlying PCIE port.
> + *
> + * pin slot: 0 1 2 3 4
> + * #A(1) 56 55 54 57 56
> + * #B(2) 57 56 55 54 57
> + * #C(3) 54 57 56 55 54
> + * #D(4) 55 54 57 56 55
> + */
> +
> + if (dev->bus->self) {
> + /* We do have a bus above us
> + * Device is right behind a PCIE hub port, and its not a PCIE
> + * hub port itself. */
> + if (dev->bus->self->device == 0x8518 &&
> + dev->device != 0x8518) {
> + /* Depend on devslot of 8518 port we're connected to */
> + devslot = PCI_SLOT(dev->bus->self->devfn);
> + /* These are the two cases for PCIE ports on PB boards.
> + * Any other downstream bus topology (e.g. with further
> + * PCIE bridges) does not scramble, and get the same
> + * irq number as the upstream bus. */
> + irq = irq_gic_start + 54 + ((devslot & 3) + (pin - 1)) % 4;
> + } else if ((dev->bus->self->class & 0xff0000) == 0x060000 &&
> + (dev->class & 0xff0000) != 0x060000) {
> + /* It's a device behind a bridge that isn't an 8518 */
> + irq = irq_gic_start + 54 + ((devslot & 3) + pin +
> + PCI_SLOT(dev->bus->self->bus->self->devfn) - 1) % 4;
> + } else {
> + /* It's another bridge */
> + irq = dev->bus->self->irq;
> + }
> + } else
> + irq = 0;
> +
> + printk(KERN_INFO "PCI Express irq mapping: device: 0x%x, slot %d, pin %d, devslot %d, irq: %d\n",
> + dev->device, slot, pin, devslot, irq);
> +
> + return irq;
> + }
> + }
> +
> + /*
> + * pin slot: 0 1 2 3
> + * #A 53 52 51 50
> + * #B 50 53 52 51
> + * #C 51 50 53 52
> + * #D 52 51 50 53
> + */
> +
> + irq = irq_gic_start + 50 + (((pin - 1) + 3 - (devslot & 3)) & 3);
> +
> + printk(KERN_INFO "PCI map irq: slot %d, pin %d, devslot %d, irq: %d\n",
> + slot, pin, devslot, irq);
> +
> + return irq;
> +
> +}
> +
> +static struct hw_pci realview_pb_pcix __initdata = {
> + .swizzle = NULL,
And I thought we'd got to the point where we had a swizzle here.
This patch looks like a backwards step - and would mean that any card
plugged in which has a PCI-to-PCI bridge on it will not work.
^ permalink raw reply
* [PATCH 0/2] MMC: disable multiblock reads on controllers that don't support them
From: Steve Sakoman @ 2011-10-07 23:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111006205002.7083.94088.stgit@dusk>
On Thu, Oct 6, 2011 at 1:50 PM, Paul Walmsley <paul@pwsan.com> wrote:
> Hello,
>
> Some MMC controller instances integrated on older OMAP34xx/35xx chips
> don't work correctly with multiple-block reads, due to a hardware bug.
> This series fixes the problem by adding an MMC capability flag for this
> case and making the appropriate changes to the MMC core code and OMAP HSMMC
> driver to support this.
>
> Once this series is merged, a subsequent patch will be needed by us OMAP
> folks to pass the appropriate device data via hwmod - this will be posted
> separately.
I tested these patches with my own version of the above mentioned
hwmod patch on:
3503 - ES2.1 and ES3.1
3530 - ES3.1
3703 - ES1.2
3730 - ES1.0
All worked successfully.
Tested-by: Steve Sakoman <steve@sakoman.com>
^ permalink raw reply
* [PATCH 5/4] ARM: OMAP: Move set_globals initialization to happen in init_early
From: Nicolas Pitre @ 2011-10-07 23:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111007145403.GG6324@atomide.com>
On Fri, 7 Oct 2011, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [111006 23:22]:
> > 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.
>
> Nico please correct me if I'm wrong, but I think that with
> generic map_io we have static mappings in place after map_io,
> and then ioremap should work for the static mappings right
> after map_io except without the need for __arch_ioremap.
Yes, that _should_ work.
Nicolas
^ permalink raw reply
* [PATCH 1/5] drivercore: add new error value for deferred probe
From: Valdis.Kletnieks at vt.edu @ 2011-10-07 23:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACxGe6uOmrLwJSPw4JHuOmt5B2wsukdDgVUr01pryq5Z9BFadw@mail.gmail.com>
On Fri, 07 Oct 2011 16:12:45 MDT, Grant Likely said:
> On Fri, Oct 7, 2011 at 12:43 AM, Greg KH <greg@kroah.com> wrote:
> > On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote:
> >> +#define EPROBE_DEFER 517 ? ? /* restart probe again after some time */
> >
> > Can we really do this?
> According to Arnd, yes this is okay.
> > ?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?
> overloading makes it really hard to find the users at a later date.
Would proposing '#define EPROBE_DEFER EAGAIN' be acceptable to everybody? That
would allow overloading EAGAIN, but still make it easy to tell the usages apart
if we need to separate them later...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111007/ed64fb47/attachment.sig>
^ permalink raw reply
* [PATCH 1/5] drivercore: add new error value for deferred probe
From: Greg KH @ 2011-10-08 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <32004.1318030113@turing-police.cc.vt.edu>
On Fri, Oct 07, 2011 at 07:28:33PM -0400, Valdis.Kletnieks at vt.edu wrote:
> On Fri, 07 Oct 2011 16:12:45 MDT, Grant Likely said:
> > On Fri, Oct 7, 2011 at 12:43 AM, Greg KH <greg@kroah.com> wrote:
> > > On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote:
>
> > >> +#define EPROBE_DEFER 517 ? ? /* restart probe again after some time */
> > >
> > > Can we really do this?
>
> > According to Arnd, yes this is okay.
>
> > > ?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?
>
> > overloading makes it really hard to find the users at a later date.
>
> Would proposing '#define EPROBE_DEFER EAGAIN' be acceptable to everybody? That
> would allow overloading EAGAIN, but still make it easy to tell the usages apart
> if we need to separate them later...
Yes, please do that, it is what USB does for it's internal error code
handling.
greg k-h
^ 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