* [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Jon Hunter @ 2012-10-16 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016174835.GV15569@atomide.com>
Hi Tony,
On 10/16/2012 12:48 PM, Tony Lindgren wrote:
> * Richard Cochran <richardcochran@gmail.com> [121015 12:18]:
>> From: hvaibhav at ti.com <hvaibhav@ti.com>
>>
>> With recent changes in omap gpmc driver code, in case of DT
>> boot mode, where bootloader does not configure gpmc cs space
>> will result into kernel BUG() inside gpmc_mem_init() function,
>> as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
>> gpmc_config7[0].baseaddress is set to '0' on reset.
>>
>> This use-case is applicable for any board/EVM which doesn't have
>> any peripheral connected to gpmc cs0, for example BeagleXM and
>> BeagleBone, so DT boot mode fails.
>>
>> This patch adds of_have_populated_dt() check before creating
>> device, so that for DT boot mode, gpmc probe will not be called
>> which is expected behavior, as gpmc is not supported yet from DT.
>
> I'm applying this one into omap-for-v3.7-rc1/fixes-part2.
>
> Next time, please also cc linux-omap at vger.kernel.org for series
> like this. I'm sure the people reading the omap list are interested
> in these.
This patch appears to be masking an underlying issue. How about
something like the following ...
Cheers
Jon
>From 753a4928bf6f7baa4c001bdca3d15a85e999db4c Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter@ti.com>
Date: Tue, 16 Oct 2012 15:22:58 -0500
Subject: [PATCH] ARM: OMAP2+: Allow kernel to boot even if GPMC fails to
reserve memory
Currently, if the GPMC driver fails to reserve memory when probed we will
call BUG() and the kernel will not boot. Instead of calling BUG(), return
an error from probe and allow kernel to boot.
Tested on AM335x beagle bone board.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/mach-omap2/gpmc.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5ac5cf3..8f0d3c8 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -868,9 +868,9 @@ static void __devexit gpmc_mem_exit(void)
}
-static void __devinit gpmc_mem_init(void)
+static int __devinit gpmc_mem_init(void)
{
- int cs;
+ int cs, rc;
unsigned long boot_rom_space = 0;
/* never allocate the first page, to facilitate bug detection;
@@ -890,13 +890,17 @@ static void __devinit gpmc_mem_init(void)
if (!gpmc_cs_mem_enabled(cs))
continue;
gpmc_cs_get_memconf(cs, &base, &size);
- if (gpmc_cs_insert_mem(cs, base, size) < 0)
- BUG();
+ rc = gpmc_cs_insert_mem(cs, base, size);
+ if (IS_ERR_VALUE(rc))
+ return rc;
}
+
+ return 0;
}
static __devinit int gpmc_probe(struct platform_device *pdev)
{
+ int rc;
u32 l;
struct resource *res;
@@ -936,7 +940,11 @@ static __devinit int gpmc_probe(struct platform_device *pdev)
dev_info(gpmc_dev, "GPMC revision %d.%d\n", GPMC_REVISION_MAJOR(l),
GPMC_REVISION_MINOR(l));
- gpmc_mem_init();
+ rc = gpmc_mem_init();
+ if (IS_ERR_VALUE(rc)) {
+ dev_err(gpmc_dev, "failed to reserve memory\n");
+ return rc;
+ }
if (IS_ERR_VALUE(gpmc_setup_irq()))
dev_warn(gpmc_dev, "gpmc_setup_irq failed\n");
--
1.7.9.5
^ permalink raw reply related
* [PATCH 09.5/16] mmc: omap: Remove cpu_is_omap usage from the driver
From: Tony Lindgren @ 2012-10-16 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ipaog4mp.fsf@octavius.laptop.org>
* Chris Ball <cjb@laptop.org> [121005 11:24]:
> On Fri, Oct 05 2012, Tony Lindgren wrote:
> >
> > Chris, I can set up a minimal immutable branch with omap
> > header changes that you can also pull into MMC tree if these
> > two MMC patches look ackable to you.
>
> Thanks, sounds good.
Chris, I've now pushed out branch omap-for-v3.8/cleanup-headers-mmc
based on -rc1. The branch is located at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
It contains two omap MMC related patches that you can also merge
into the MMC tree if needed as now include plat/mmc.h is gone for
omaps.
Regards,
Tony
^ permalink raw reply
* [PATCH RFC 02/11 v4] gpio: Add sysfs support to block GPIO API
From: Linus Walleij @ 2012-10-16 21:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016174038.GA17982@kroah.com>
On Tue, Oct 16, 2012 at 7:40 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Tue, Oct 16, 2012 at 07:27:15PM +0200, Linus Walleij wrote:
>> The thing is, as I've tried to explain but maybe didn't get across,
>> that these devices don't *have* a parent, and are not part of any
>> tree.
>
> You are passing in a parent device to the device_create() call, where
> did that pointer come from?
You mean this:
dev = device_create(&gpio_class, desc->chip->dev, MKDEV(0, 0),
desc, ioname ? ioname : "gpio%u", gpio);
desc->chip->dev is an *optional* pointer to a parent device of
the GPIO chip (not the GPIO chip itself). It is usually NULL.
>> They are parentless mock devices, created on-the-fly just to get
>> sysfs entries.
>
> That's fine, well, not the "parentless" part, but that should be trivial
> to fix, just pass in the correct pointer and you should be fine.
Hm, yeah well, they are orphans mostly.
>> What is needed it to get the device model right in the first
>> place.
>
> I thought it was in the device model already?
GPIO chips are not devices. :-(
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: OMAP2: UART: fix console UART mismatched runtime PM status
From: Tony Lindgren @ 2012-10-16 21:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016102517.GD21801@arwen.pp.htv.fi>
* Felipe Balbi <balbi@ti.com> [121016 03:32]:
> Hi,
>
> On Mon, Oct 15, 2012 at 04:49:58PM -0700, Kevin Hilman wrote:
> > From: Kevin Hilman <khilman@ti.com>
> >
> > The runtime PM framework assumes that the hardware state of devices
> > when initialized is disabled. For all omap_devices, we idle/disable
> > device by default. However, the console uart uses a "no idle" option
> > during omap_device init in order to allow earlyprintk usage to work
> > seamlessly during boot.
> >
> > Because the hardware is left partially enabled after init (whatever
> > the bootloader settings were), the omap_device should later be fully
> > initialized (including mux) and the runtime PM framework should be
> > told that the device is active, and not disabled so that the hardware
> > state is in sync with runtime PM state.
> >
> > To fix, after the device has been created/registered, call
> > omap_device_enable() to finialize init and use pm_runtime_set_active()
> > to tell the runtime PM core the device is enabled.
> >
> > Tested on 2420/n810, 3530/Overo, 3530/Beagle, 3730/OveroSTORM,
> > 3730/Beagle-xM, 4460/PandaES.
> >
> > Reported-by: Paul Walmsley <paul@pwsan.com>
> > Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > Cc: Felipe Balbi <balbi@ti.com>
> > Cc: Sourav Poddar <sourav.poddar@ti.com>
> > Signed-off-by: Kevin Hilman <khilman@ti.com>
> > ---
> > Applies against v3.7-rc1.
> > Fix targetted for v3.7.
> >
> > I'm still not entirely sure why this has worked up to now on OMAP3/4
> > but not on OMAP2. Even so, this fix is needed for all platforms to
> > ensure matching hardware state and runtime PM state.
> >
> > arch/arm/mach-omap2/serial.c | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> > index 0405c81..37b5dbe 100644
> > --- a/arch/arm/mach-omap2/serial.c
> > +++ b/arch/arm/mach-omap2/serial.c
> > @@ -327,6 +327,11 @@ void __init omap_serial_init_port(struct omap_board_data *bdata,
> > if ((console_uart_id == bdata->id) && no_console_suspend)
> > omap_device_disable_idle_on_suspend(pdev);
> >
> > + if (console_uart_id == bdata->id) {
> > + omap_device_enable(pdev);
> > + pm_runtime_set_active(&pdev->dev);
> > + }
> > +
> > oh->mux = omap_hwmod_mux_init(bdata->pads, bdata->pads_cnt);
> >
> > oh->dev_attr = uart;
>
> looks good to me. Even took care of doing that only for the console
> UART.
Applying into omap-for-v3.7-rc1/fixes-take3.
Regards,
Tony
^ permalink raw reply
* [PATCH RFC 02/11 v4] gpio: Add sysfs support to block GPIO API
From: Greg KH @ 2012-10-16 21:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb+hu1Q=P8wBWts1RsMFQYuDMuszS74Z5mmkfwcXdpEpw@mail.gmail.com>
On Tue, Oct 16, 2012 at 11:08:51PM +0200, Linus Walleij wrote:
> On Tue, Oct 16, 2012 at 7:40 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Tue, Oct 16, 2012 at 07:27:15PM +0200, Linus Walleij wrote:
> >> The thing is, as I've tried to explain but maybe didn't get across,
> >> that these devices don't *have* a parent, and are not part of any
> >> tree.
> >
> > You are passing in a parent device to the device_create() call, where
> > did that pointer come from?
>
> You mean this:
>
> dev = device_create(&gpio_class, desc->chip->dev, MKDEV(0, 0),
> desc, ioname ? ioname : "gpio%u", gpio);
Yes.
> desc->chip->dev is an *optional* pointer to a parent device of
> the GPIO chip (not the GPIO chip itself). It is usually NULL.
Ah, I didn't realize that.
Well, then they turn into "virtual" devices, which are still fine, they
show up in the device tree properly, so all is ok.
> >> They are parentless mock devices, created on-the-fly just to get
> >> sysfs entries.
> >
> > That's fine, well, not the "parentless" part, but that should be trivial
> > to fix, just pass in the correct pointer and you should be fine.
>
> Hm, yeah well, they are orphans mostly.
>
> >> What is needed it to get the device model right in the first
> >> place.
> >
> > I thought it was in the device model already?
>
> GPIO chips are not devices. :-(
Point to the device that the GPIO pins are located on. Be it the cpu,
or platform, or something else. If not, making them "virtual" is fine,
that's what it is there for.
greg k-h
^ permalink raw reply
* [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Tony Lindgren @ 2012-10-16 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507DCA8D.7060309@ti.com>
* Jon Hunter <jon-hunter@ti.com> [121016 14:00]:
> Hi Tony,
>
> On 10/16/2012 12:48 PM, Tony Lindgren wrote:
> > * Richard Cochran <richardcochran@gmail.com> [121015 12:18]:
> >> From: hvaibhav at ti.com <hvaibhav@ti.com>
> >>
> >> With recent changes in omap gpmc driver code, in case of DT
> >> boot mode, where bootloader does not configure gpmc cs space
> >> will result into kernel BUG() inside gpmc_mem_init() function,
> >> as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
> >> gpmc_config7[0].baseaddress is set to '0' on reset.
> >>
> >> This use-case is applicable for any board/EVM which doesn't have
> >> any peripheral connected to gpmc cs0, for example BeagleXM and
> >> BeagleBone, so DT boot mode fails.
> >>
> >> This patch adds of_have_populated_dt() check before creating
> >> device, so that for DT boot mode, gpmc probe will not be called
> >> which is expected behavior, as gpmc is not supported yet from DT.
> >
> > I'm applying this one into omap-for-v3.7-rc1/fixes-part2.
> >
> > Next time, please also cc linux-omap at vger.kernel.org for series
> > like this. I'm sure the people reading the omap list are interested
> > in these.
>
> This patch appears to be masking an underlying issue. How about
> something like the following ...
OK that looks good to me. I'll drop the earlier fix and use
yours instead.
Regards,
Tony
^ permalink raw reply
* [PATCH 2/2] ARM: unwind: enable dumping stacks for SMP && ARM_UNWIND
From: Colin Cross @ 2012-10-16 21:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016105504.GD21164@n2100.arm.linux.org.uk>
On Tue, Oct 16, 2012 at 3:55 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Oct 16, 2012 at 11:12:01AM +0100, Dave Martin wrote:
>> On Mon, Oct 15, 2012 at 07:15:31PM -0700, Colin Cross wrote:
>> > About half the callers to unwind_frame end up limiting the number of
>> > frames they will follow before giving up, so I wasn't sure if I should
>> > put an arbitrary limit in unwind_frame or just make sure all callers
>> > are bounded. Your idea of limiting same sp frames instead of total
>> > frames sounds better. I can send a new patch that adds a new field to
>> > struct stackframe (which will need to be initialized everywhere, the
>> > struct is usually on the stack) and limits the recursion. Any
>> > suggestion on the recursion limit? I would never expect to see a real
>> > situation with more than a few, but on the other hand parsing the
>> > frames should be pretty fast so a high number (100?) shouldn't cause
>> > any user visible effect.
>>
>> Talking to some tools guys about this, it sounds like there really
>> shouldn't be any stackless frame except for the leaf frame. If there are
>> stackless functions they will probably not be visible in the frame chain
>> at all. So it might make sense to have a pretty small limit. Maybe it
>> could even be 1. Cartainly a small number.
>>
>> We should also add a check for whether the current and frame and previous
>> frame appear identical and abort if that's the case, if we don't do that
>> already.
>
> The case that actually worries me is not the "end up looping for ever"
> case, but the effects of having the stack change while the unwinder is
> reading from it - for example:
>
> /* pop R4-R15 according to mask */
> load_sp = mask & (1 << (13 - 4));
> while (mask) {
> if (mask & 1)
> ctrl->vrs[reg] = *vsp++;
> mask >>= 1;
> reg++;
> }
>
> Remember that for a running thread, the stack will be changing all the
> time while another CPU tries to read it to do the unwind, and also
> remember that the bottom of stack isn't really known. All you have is
> the snapshot of the registers when the thread was last stopped by the
> scheduler, and that state probably isn't valid.
If the snapshot of the registers when the thread was last stopped
includes an sp that points somewhere in two contiguous pages of low
memory, I don't see a problem. From the sp we can get the bounds of
the stack (see the valid_stack_addr function I added), and we can make
sure the unwinder never dereferences anything outside of that stack,
so it will never fault. We can also make sure that the sp stays
within that stack between frames, and moves in the right direction, so
it will never loop (except for the leaf-node sp issue, which Dave
Martin's idea will address).
> So what you're asking is for the unwinder to produce a backtrace from
> a kernel stack which is possibly changing beneath it from an unknown
> current state.
I don't think the stack changing is relevant. With my modifications,
the unwinder can handle an invalid value at any place in the stack
without looping or crashing, and it doesn't matter if it is invalid
due to changing or permanent stack corruption. The worst it will do
is produce a partial stack trace that ends with an invalid value. For
example:
shell@:/ # dd if=/dev/urandom of=/dev/null bs=1000000 count=1000000 &
[1] 2709
130|shell@:/ # while true; do cat /proc/2709/stack; echo ---; done
[<c00084d4>] gic_handle_irq+0x24/0x58
[<c000e580>] __irq_svc+0x40/0x70
[<ffffffff>] 0xffffffff
---
[<00000099>] 0x99
[<ffffffff>] 0xffffffff
---
[<c0039728>] irq_exit+0x7c/0x98
[<c000f888>] handle_IRQ+0x50/0xac
[<c00084d4>] gic_handle_irq+0x24/0x58
[<00000014>] 0x14
[<ffffffff>] 0xffffffff
---
[<c087ac40>] rcu_preempt_state+0x0/0x140
[<ffffffff>] 0xffffffff
---
[<c00084d4>] gic_handle_irq+0x24/0x58
[<c000e580>] __irq_svc+0x40/0x70
[<ffffffff>] 0xffffffff
---
[<60000013>] 0x60000013
[<ffffffff>] 0xffffffff
---
[<d79ce000>] 0xd79ce000
[<ffffffff>] 0xffffffff
> This doesn't sound like a particularly bright thing to be doing...
As discussed previously, this already happens, has anyone ever
reported it as a problem? Sysrq-t dumps all stacks by calling
dump_backtrace(), which bypasses the check for tsk == current. And
any caller to unwind_backtrace with preemption on can see a changing
stack, even on UP.
^ permalink raw reply
* [PATCH 04/10] ASoC: imx: Don't use {en,dis}able_fiq() calls
From: Sascha Hauer @ 2012-10-16 21:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350337894-9744-4-git-send-email-anton.vorontsov@linaro.org>
On Mon, Oct 15, 2012 at 02:51:28PM -0700, Anton Vorontsov wrote:
> The driver uses platform-specific mxc_set_irq_fiq() with the VIRQ cookie
> passed to it, so it's pretty clear that the driver is absolutely sure
> that the FIQ is routed via platform-specific IC, and that the cookie can
> be used to mask/unmask FIQs. So, let's switch to the genirq routines,
> since we're about to remove FIQ-specific variants.
>
> Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> sound/soc/fsl/imx-pcm-fiq.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/fsl/imx-pcm-fiq.c b/sound/soc/fsl/imx-pcm-fiq.c
> index 22c6130..8f1a4a6 100644
> --- a/sound/soc/fsl/imx-pcm-fiq.c
> +++ b/sound/soc/fsl/imx-pcm-fiq.c
> @@ -139,7 +139,7 @@ static int snd_imx_pcm_trigger(struct snd_pcm_substream *substream, int cmd)
> hrtimer_start(&iprtd->hrt, ns_to_ktime(iprtd->poll_time_ns),
> HRTIMER_MODE_REL);
> if (++fiq_enable == 1)
> - enable_fiq(imx_pcm_fiq);
> + enable_irq(imx_pcm_fiq);
>
> break;
>
> @@ -149,7 +149,7 @@ static int snd_imx_pcm_trigger(struct snd_pcm_substream *substream, int cmd)
> atomic_set(&iprtd->running, 0);
>
> if (--fiq_enable == 0)
> - disable_fiq(imx_pcm_fiq);
> + disable_irq(imx_pcm_fiq);
>
> break;
> default:
> --
> 1.7.12.3
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 03/10] [media] mx1_camera: Don't use {en,dis}able_fiq() calls
From: Sascha Hauer @ 2012-10-16 21:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350337894-9744-3-git-send-email-anton.vorontsov@linaro.org>
On Mon, Oct 15, 2012 at 02:51:27PM -0700, Anton Vorontsov wrote:
> The driver uses platform-specific mxc_set_irq_fiq() with the VIRQ cookie
> passed to it, so it's pretty clear that the driver is absolutely sure
> that the FIQ is routed via platform-specific IC, and that the cookie can
> be used to mask/unmask FIQs. So, let's switch to the genirq routines,
> since we're about to remove FIQ-specific variants.
>
> Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> drivers/media/platform/soc_camera/mx1_camera.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/soc_camera/mx1_camera.c b/drivers/media/platform/soc_camera/mx1_camera.c
> index bbe7099..4855a46 100644
> --- a/drivers/media/platform/soc_camera/mx1_camera.c
> +++ b/drivers/media/platform/soc_camera/mx1_camera.c
> @@ -801,7 +801,7 @@ static int __init mx1_camera_probe(struct platform_device *pdev)
> set_fiq_regs(®s);
>
> mxc_set_irq_fiq(irq, 1);
> - enable_fiq(irq);
> + enable_irq(irq);
>
> pcdev->soc_host.drv_name = DRIVER_NAME;
> pcdev->soc_host.ops = &mx1_soc_camera_host_ops;
> @@ -817,7 +817,7 @@ static int __init mx1_camera_probe(struct platform_device *pdev)
> return 0;
>
> exit_free_irq:
> - disable_fiq(irq);
> + disable_irq(irq);
> mxc_set_irq_fiq(irq, 0);
> release_fiq(&fh);
> exit_free_dma:
> @@ -842,7 +842,7 @@ static int __exit mx1_camera_remove(struct platform_device *pdev)
> struct resource *res;
>
> imx_dma_free(pcdev->dma_chan);
> - disable_fiq(pcdev->irq);
> + disable_irq(pcdev->irq);
> mxc_set_irq_fiq(pcdev->irq, 0);
> release_fiq(&fh);
>
> --
> 1.7.12.3
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* RT throttling and suspend/resume (was Re: [PATCH] i2c: omap: revert "i2c: omap: switch to threaded IRQ support")
From: Kevin Hilman @ 2012-10-16 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016133356.GG21801@arwen.pp.htv.fi>
+ peterz, tglx
Felipe Balbi <balbi@ti.com> writes:
[...]
> The problem I see is that even though we properly return IRQ_WAKE_THREAD
> and wake_up_process() manages to wakeup the IRQ thread (it returns 1),
> the thread is never scheduled. To make things even worse, ouw irq thread
> runs once, but doesn't run on a consecutive call. Here's some (rather
> nasty) debug prints showing the problem:
[...]
>> [ 88.721923] try_to_wake_up 1411
>> [ 88.725189] ===> irq_wake_thread 139: IRQ 72 wake_up_process 0
>> [ 88.731292] [sched_delayed] sched: RT throttling activated
This throttling message is the key one.
With RT throttling activated, the IRQ thread will not be run (it
eventually will be allowed much later on, but by then, the I2C xfers
have timed out.)
As a quick hack, the throttling can be disabled by seeting the
sched_rt_runtime to RUNTIME_INF:
# sysctl -w kernel.sched_rt_runtime_us=-1
and a quick test shows that things go back to working as expected. But
we still need to figure out why the throttling is hapenning...
So I started digging into why the RT runtime was so high, and noticed
that time spent in suspend was being counted as RT runtime!
So spending time in suspend anywhere near sched_rt_runtime (0.95s) will
cause the RT throttling to always be triggered, and thus prevent IRQ
threads from running in the resume path. Ouch.
I think I'm already in over my head in the RT runtime stuff, but
counting the time spent in suspend as RT runtime smells like a bug to
me. no?
Peter? Thomas?
Kevin
^ permalink raw reply
* [RFC PATCH] ARM: kernel: update cpuinfo to print all online CPUs features
From: Russell King - ARM Linux @ 2012-10-16 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507DA08B.502@ti.com>
On Tue, Oct 16, 2012 at 11:29:39PM +0530, Santosh Shilimkar wrote:
> Not exactly related to the $subject patch, but I remember doing a patch
> to have cat /proc/cpuinfo spitting only online CPUs just like x86 using
> for_each_online_cpu(i).
> At that point Russell mentioned about a possibility of read() syscall
> spreading over the hot-plug operation and hence the above may not
> be safe.
>
> is that right Russell ?
That is correct, but you will notice that the code now uses the online
cpus rather than the present, inspite of my objections. I gave up
fighting the case, so now people get to live with the consequences of
this.
This will be fun with dynamic hotplugging with big.LITTLE when people
come to read any of these files which change their output with the
online CPUs. Oh what fun we're in for there.
I guess the only way to convince people is to let them make their
mistakes in the kernel.
^ permalink raw reply
* [RFC][PATCH v4? 0/7] Adaptive Body-Bias for OMAP
From: Kevin Hilman @ 2012-10-16 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016170620.21731.52746@nucleus>
Mike Turquette <mturquette@ti.com> writes:
> Quoting Tony Lindgren (2012-10-16 09:32:25)
>> * Mike Turquette <mturquette@ti.com> [121011 15:27]:
>> > Quoting Nishanth Menon (2012-10-11 06:33:04)
>> > > On 18:26-20121003, Mike Turquette wrote:
>> > > > From: Mike Turquette <mturquette@linaro.org>
>> > > [...]
>> > > >
>> > > > arch/arm/mach-omap2/Makefile | 8 +-
>> > > > arch/arm/mach-omap2/abb.c | 322 +++++++++++++++++++++++++
>> > > > arch/arm/mach-omap2/abb.h | 94 ++++++++
>> > > [...]
>> > > > arch/arm/plat-omap/include/plat/voltage.h | 1 +
>> > > > 18 files changed, 699 insertions(+), 37 deletions(-)
>> > > > create mode 100644 arch/arm/mach-omap2/abb.c
>> > > > create mode 100644 arch/arm/mach-omap2/abb.h
>> > > > create mode 100644 arch/arm/mach-omap2/abb36xx_data.c
>> > > > create mode 100644 arch/arm/mach-omap2/abb44xx_data.c
>> > >
>> > > dumb question: with the request to move everything out of mach-omap2
>> > > directory, do we still want to add more files into mach-omap2?
>> > >
>> >
>> > Not a dumb question at all. I approached this problem by modeling it
>> > after existing voltage layer code (in particular the vp and vc drivers).
>> >
>> > My hope is to get it merged as-is and then bundle the abb code up with
>> > the vp/vc migration to drivers/* when that happens some day. People
>> > using omap36xx and above need this code now, so it seems prudent to take
>> > this approach today.
>>
>> This is needed, but makes moving the vc code to drivers a bit
>> more complex.
>>
>> So we also need a plan to move this all to drivers in the follow
>> up patches. And we need a maintainer for the code. Who is going to
>> be doing all that?
>>
>
> Is there already somebody committed to moving vp/vc code out to drivers?
Yes, VC/VP is part of the bigger PRM/CM move in progress.
For now, I'm ok with adding a little more VC/VP stuff since it's already
well isolated in the prmXXXX.c files (though it might need a rebase on
Paul's recent PRM/CM cleanup stuff.)
> If so then I can take responsibility for moving the abb code and
> coordinate with that person.
Thanks,
Kevin
^ permalink raw reply
* [PATCH 2/2] ARM: unwind: enable dumping stacks for SMP && ARM_UNWIND
From: Colin Cross @ 2012-10-16 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016122658.GB26075@linaro.org>
On Tue, Oct 16, 2012 at 5:26 AM, Dave Martin <dave.martin@linaro.org> wrote:
> On Tue, Oct 16, 2012 at 11:55:04AM +0100, Russell King - ARM Linux wrote:
>> On Tue, Oct 16, 2012 at 11:12:01AM +0100, Dave Martin wrote:
>> > On Mon, Oct 15, 2012 at 07:15:31PM -0700, Colin Cross wrote:
>> > > About half the callers to unwind_frame end up limiting the number of
>> > > frames they will follow before giving up, so I wasn't sure if I should
>> > > put an arbitrary limit in unwind_frame or just make sure all callers
>> > > are bounded. Your idea of limiting same sp frames instead of total
>> > > frames sounds better. I can send a new patch that adds a new field to
>> > > struct stackframe (which will need to be initialized everywhere, the
>> > > struct is usually on the stack) and limits the recursion. Any
>> > > suggestion on the recursion limit? I would never expect to see a real
>> > > situation with more than a few, but on the other hand parsing the
>> > > frames should be pretty fast so a high number (100?) shouldn't cause
>> > > any user visible effect.
>> >
>> > Talking to some tools guys about this, it sounds like there really
>> > shouldn't be any stackless frame except for the leaf frame. If there are
>> > stackless functions they will probably not be visible in the frame chain
>> > at all. So it might make sense to have a pretty small limit. Maybe it
>> > could even be 1. Cartainly a small number.
>> >
>> > We should also add a check for whether the current and frame and previous
>> > frame appear identical and abort if that's the case, if we don't do that
>> > already.
>>
>> The case that actually worries me is not the "end up looping for ever"
>> case, but the effects of having the stack change while the unwinder is
>> reading from it - for example:
>>
>> /* pop R4-R15 according to mask */
>> load_sp = mask & (1 << (13 - 4));
>> while (mask) {
>> if (mask & 1)
>> ctrl->vrs[reg] = *vsp++;
>> mask >>= 1;
>> reg++;
>> }
>>
>> Remember that for a running thread, the stack will be changing all the
>> time while another CPU tries to read it to do the unwind, and also
>> remember that the bottom of stack isn't really known. All you have is
>> the snapshot of the registers when the thread was last stopped by the
>> scheduler, and that state probably isn't valid.
>
> So long as the unwinder enforces continuous progress towards a fixed
> limit, sooner or later the supposed bottom of the stack will be reached,
> or the unwinder will encounter something which is recognised as garbage
> and stop.
>
> This the best we can hope for if trying to print a backtrace for a
> thread without stopping it... which admittedly seems quite a dodgy
> thing to attempt.
>
> Colin, what are the scenarios when we want to backtrace a thread while
> it is actually running?
There is no case where I want a backtrace from a running thread other
than current, but there is no way to guarantee that the thread won't
start running unless we stick it in the freezer, which has other
problems. The main use case is dumping /proc/pid/stack for all
threads in the process when the thread is deadlocked. Most likely
none of them will be running, and if they are running I don't care
about the stack.
If the unwinder is made safe against running tasks,
save_stack_trace_tsk could print an error if the task is running
(because it has no idea when it will stop running), then capture the
stack and test that the thread is still not running and the number of
context switches on the task hasn't increased, otherwise retry. That
way we'll get an error from a running task, but still be able to dump
blocked tasks that are not current. It still relies on being able to
call unwind_frame on a possibly invalid stack.
>> So what you're asking is for the unwinder to produce a backtrace from
>> a kernel stack which is possibly changing beneath it from an unknown
>> current state.
>>
>> This doesn't sound like a particularly bright thing to be doing...
>
> Nonetheless, the changes are relevant to normal stack dumping too, since
> when we take a fault the sp or stack may be corrupted, even if the
> thread in question is stopped. Being more robust against infinte loops
> etc., still seems like a good idea ?
I can split out the unwind_frame hardening from the
save_stack_trace_tsk part if you only want that part, and I'll put the
save_stack_trace_tsk chunk in the Android tree.
^ permalink raw reply
* [GIT PULL] OMAP-GPMC cleanup for common zImage
From: Tony Lindgren @ 2012-10-16 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350303247-13495-1-git-send-email-afzal@ti.com>
* Afzal Mohammed <afzal@ti.com> [121015 05:15]:
> The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
>
> Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
>
> are available in the git repository at:
>
> git at gitorious.org:x0148406-public/linux-kernel.git tags/gpmc-czimage
>
> for you to fetch changes up to 3ef5d0071cf6c8b9a00b559232bb700ad59999d7:
>
> ARM: OMAP2+: gpmc: localize gpmc header (2012-10-15 14:42:15 +0530)
>
> ----------------------------------------------------------------
> gpmc cleanup for common ARM zImage
>
Thanks pulling into omap-for-v3.8/cleanup-headers-gpmc
I ended up using the following url instead:
git://gitorious.org/x0148406-public/linux-kernel tags/gpmc-czimage
Regards,
Tony
> ----------------------------------------------------------------
> Afzal Mohammed (16):
> ARM: OMAP2+: nand: unify init functions
> ARM: OMAP2+: onenand: refactor for clarity
> ARM: OMAP2+: gpmc: remove cs# in sync clk div calc
> mtd: onenand: omap: cleanup gpmc dependency
> mtd: nand: omap: free region as per resource size
> mtd: nand: omap: read nand using register address
> ARM: OMAP2+: onenand: connected soc info in pdata
> mtd: onenand: omap: use pdata info instead of cpu_is
> ARM: OMAP2+: onenand: header cleanup
> ARM: OMAP2+: nand: header cleanup
> mtd: nand: omap: bring in gpmc nand macros
> ARM: OMAP2+: nand: bch capability check
> ARM: OMAP2+: gpmc: nand register helper bch update
> mtd: nand: omap: handle gpmc bch[48]
> ARM: OMAP2+: gpmc: remove exported nand functions
> ARM: OMAP2+: gpmc: localize gpmc header
>
> Jon Hunter (1):
> ARM: OMAP2+: GPMC: Remove unused OneNAND get_freq() platform function
>
> arch/arm/mach-omap2/board-2430sdp.c | 2 +-
> arch/arm/mach-omap2/board-3430sdp.c | 2 +-
> arch/arm/mach-omap2/board-apollon.c | 2 +-
> arch/arm/mach-omap2/board-cm-t35.c | 5 +-
> arch/arm/mach-omap2/board-cm-t3517.c | 5 +-
> arch/arm/mach-omap2/board-devkit8000.c | 10 +-
> arch/arm/mach-omap2/board-flash.c | 50 +--
> arch/arm/mach-omap2/board-flash.h | 8 +-
> arch/arm/mach-omap2/board-h4.c | 2 +-
> arch/arm/mach-omap2/board-igep0020.c | 5 +-
> arch/arm/mach-omap2/board-ldp.c | 6 +-
> arch/arm/mach-omap2/board-n8x0.c | 1 +
> arch/arm/mach-omap2/board-omap3beagle.c | 10 +-
> arch/arm/mach-omap2/board-omap3evm.c | 8 +-
> arch/arm/mach-omap2/board-omap3logic.c | 2 +-
> arch/arm/mach-omap2/board-omap3pandora.c | 3 +-
> arch/arm/mach-omap2/board-omap3stalker.c | 2 +-
> arch/arm/mach-omap2/board-omap3touchbook.c | 10 +-
> arch/arm/mach-omap2/board-overo.c | 9 +-
> arch/arm/mach-omap2/board-rm680.c | 3 +-
> arch/arm/mach-omap2/board-rx51-peripherals.c | 3 +-
> arch/arm/mach-omap2/board-rx51.c | 2 +-
> arch/arm/mach-omap2/board-zoom-debugboard.c | 2 +-
> arch/arm/mach-omap2/board-zoom.c | 5 +-
> arch/arm/mach-omap2/common-board-devices.c | 46 ---
> arch/arm/mach-omap2/common-board-devices.h | 1 -
> arch/arm/mach-omap2/gpmc-nand.c | 85 ++--
> arch/arm/mach-omap2/gpmc-nand.h | 27 ++
> arch/arm/mach-omap2/gpmc-onenand.c | 214 +++++-----
> arch/arm/mach-omap2/gpmc-onenand.h | 24 ++
> arch/arm/mach-omap2/gpmc-smc91x.c | 2 +-
> arch/arm/mach-omap2/gpmc-smsc911x.c | 2 +-
> arch/arm/mach-omap2/gpmc.c | 459 +--------------------
> .../{plat-omap/include/plat => mach-omap2}/gpmc.h | 61 +--
> arch/arm/mach-omap2/pm34xx.c | 2 +-
> arch/arm/mach-omap2/usb-tusb6010.c | 2 +-
> drivers/mtd/nand/omap2.c | 125 +++++-
> drivers/mtd/onenand/omap2.c | 9 +-
> include/linux/platform_data/mtd-nand-omap2.h | 46 ++-
> include/linux/platform_data/mtd-onenand-omap2.h | 28 +-
> 40 files changed, 493 insertions(+), 797 deletions(-)
> create mode 100644 arch/arm/mach-omap2/gpmc-nand.h
> create mode 100644 arch/arm/mach-omap2/gpmc-onenand.h
> rename arch/arm/{plat-omap/include/plat => mach-omap2}/gpmc.h (67%)
^ permalink raw reply
* [RFC][PATCH v4? 0/7] Adaptive Body-Bias for OMAP
From: Tony Lindgren @ 2012-10-16 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87a9vmnl1n.fsf@deeprootsystems.com>
* Kevin Hilman <khilman@deeprootsystems.com> [121016 14:51]:
> Mike Turquette <mturquette@ti.com> writes:
>
> > Quoting Tony Lindgren (2012-10-16 09:32:25)
> >> * Mike Turquette <mturquette@ti.com> [121011 15:27]:
> >> > Quoting Nishanth Menon (2012-10-11 06:33:04)
> >> > > On 18:26-20121003, Mike Turquette wrote:
> >> > > > From: Mike Turquette <mturquette@linaro.org>
> >> > > [...]
> >> > > >
> >> > > > arch/arm/mach-omap2/Makefile | 8 +-
> >> > > > arch/arm/mach-omap2/abb.c | 322 +++++++++++++++++++++++++
> >> > > > arch/arm/mach-omap2/abb.h | 94 ++++++++
> >> > > [...]
> >> > > > arch/arm/plat-omap/include/plat/voltage.h | 1 +
> >> > > > 18 files changed, 699 insertions(+), 37 deletions(-)
> >> > > > create mode 100644 arch/arm/mach-omap2/abb.c
> >> > > > create mode 100644 arch/arm/mach-omap2/abb.h
> >> > > > create mode 100644 arch/arm/mach-omap2/abb36xx_data.c
> >> > > > create mode 100644 arch/arm/mach-omap2/abb44xx_data.c
> >> > >
> >> > > dumb question: with the request to move everything out of mach-omap2
> >> > > directory, do we still want to add more files into mach-omap2?
> >> > >
> >> >
> >> > Not a dumb question at all. I approached this problem by modeling it
> >> > after existing voltage layer code (in particular the vp and vc drivers).
> >> >
> >> > My hope is to get it merged as-is and then bundle the abb code up with
> >> > the vp/vc migration to drivers/* when that happens some day. People
> >> > using omap36xx and above need this code now, so it seems prudent to take
> >> > this approach today.
> >>
> >> This is needed, but makes moving the vc code to drivers a bit
> >> more complex.
> >>
> >> So we also need a plan to move this all to drivers in the follow
> >> up patches. And we need a maintainer for the code. Who is going to
> >> be doing all that?
> >>
> >
> > Is there already somebody committed to moving vp/vc code out to drivers?
>
> Yes, VC/VP is part of the bigger PRM/CM move in progress.
>
> For now, I'm ok with adding a little more VC/VP stuff since it's already
> well isolated in the prmXXXX.c files (though it might need a rebase on
> Paul's recent PRM/CM cleanup stuff.)
>
> > If so then I can take responsibility for moving the abb code and
> > coordinate with that person.
Thanks Mike & Kevin, sounds good to me.
Regards,
Tony
^ permalink raw reply
* [PATCH] genirq: provide means to retrigger parent
From: Kevin Hilman @ 2012-10-16 22:07 UTC (permalink / raw)
To: linux-arm-kernel
From: Thomas Gleixner <tglx@linutronix.de>
Attempts to retrigger nested threaded IRQs currently fail because they
have no primary handler. In order to support retrigger of nested
IRQs, the parent IRQ needs to be retriggered.
To fix, when an IRQ needs to be resent, if the interrupt has a parent
IRQ and runs in the context of the parent IRQ, then resend the parent.
Also, handle_nested_irq() needs to clear the replay flag like the
other handlers, otherwise check_irq_resend() will set it and it will
never be cleared. Without clearing, it results in the first resend
working fine, but check_irq_resend() returning early on subsequent
resends because the replay flag is still set.
Problem discovered on ARM/OMAP platforms where a nested IRQ that's
also a wakeup IRQ happens late in suspend and needed to be retriggered
during the resume process.
Reported-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
[khilman at ti.com: changelog edits, clear IRQS_REPLAY in handle_nested_irq()]
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
Applies on v3.7-rc1
include/linux/irq.h | 9 +++++++++
include/linux/irqdesc.h | 3 +++
kernel/irq/chip.c | 1 +
kernel/irq/manage.c | 16 ++++++++++++++++
kernel/irq/resend.c | 8 ++++++++
5 files changed, 37 insertions(+)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 216b0ba..526f10a 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -392,6 +392,15 @@ static inline void irq_move_masked_irq(struct irq_data *data) { }
extern int no_irq_affinity;
+#ifdef CONFIG_HARDIRQS_SW_RESEND
+int irq_set_parent(int irq, int parent_irq);
+#else
+static inline int irq_set_parent(int irq, int parent_irq)
+{
+ return 0;
+}
+#endif
+
/*
* Built-in IRQ handlers for various IRQ types,
* callable via desc->handle_irq()
diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h
index 0ba014c..623325e 100644
--- a/include/linux/irqdesc.h
+++ b/include/linux/irqdesc.h
@@ -11,6 +11,8 @@
struct irq_affinity_notify;
struct proc_dir_entry;
struct module;
+struct irq_desc;
+
/**
* struct irq_desc - interrupt descriptor
* @irq_data: per irq and chip data passed down to chip functions
@@ -65,6 +67,7 @@ struct irq_desc {
#ifdef CONFIG_PROC_FS
struct proc_dir_entry *dir;
#endif
+ int parent_irq;
struct module *owner;
const char *name;
} ____cacheline_internodealigned_in_smp;
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 57d86d0..3aca9f2 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -272,6 +272,7 @@ void handle_nested_irq(unsigned int irq)
raw_spin_lock_irq(&desc->lock);
+ desc->istate &= ~(IRQS_REPLAY | IRQS_WAITING);
kstat_incr_irqs_this_cpu(irq, desc);
action = desc->action;
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 4c69326..d06a396 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -616,6 +616,22 @@ int __irq_set_trigger(struct irq_desc *desc, unsigned int irq,
return ret;
}
+#ifdef CONFIG_HARDIRQS_SW_RESEND
+int irq_set_parent(int irq, int parent_irq)
+{
+ unsigned long flags;
+ struct irq_desc *desc = irq_get_desc_lock(irq, &flags, 0);
+
+ if (!desc)
+ return -EINVAL;
+
+ desc->parent_irq = parent_irq;
+
+ irq_put_desc_unlock(desc, flags);
+ return 0;
+}
+#endif
+
/*
* Default primary interrupt handler for threaded interrupts. Is
* assigned as primary handler when request_threaded_irq is called
diff --git a/kernel/irq/resend.c b/kernel/irq/resend.c
index 6454db7..9065107 100644
--- a/kernel/irq/resend.c
+++ b/kernel/irq/resend.c
@@ -74,6 +74,14 @@ void check_irq_resend(struct irq_desc *desc, unsigned int irq)
if (!desc->irq_data.chip->irq_retrigger ||
!desc->irq_data.chip->irq_retrigger(&desc->irq_data)) {
#ifdef CONFIG_HARDIRQS_SW_RESEND
+ /*
+ * If the interrupt has a parent irq and runs
+ * in the thread context of the parent irq,
+ * retrigger the parent.
+ */
+ if (desc->parent_irq &&
+ irq_settings_is_nested_thread(desc))
+ irq = desc->parent_irq;
/* Set it pending and activate the softirq: */
set_bit(irq, irqs_resend);
tasklet_schedule(&resend_tasklet);
--
1.7.9.2
^ permalink raw reply related
* [PATCH] genirq: provide means to retrigger parent
From: Russell King - ARM Linux @ 2012-10-16 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350425269-11489-1-git-send-email-khilman@deeprootsystems.com>
On Tue, Oct 16, 2012 at 03:07:49PM -0700, Kevin Hilman wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
>
> Attempts to retrigger nested threaded IRQs currently fail because they
> have no primary handler. In order to support retrigger of nested
> IRQs, the parent IRQ needs to be retriggered.
>
> To fix, when an IRQ needs to be resent, if the interrupt has a parent
> IRQ and runs in the context of the parent IRQ, then resend the parent.
>
> Also, handle_nested_irq() needs to clear the replay flag like the
> other handlers, otherwise check_irq_resend() will set it and it will
> never be cleared. Without clearing, it results in the first resend
> working fine, but check_irq_resend() returning early on subsequent
> resends because the replay flag is still set.
>
> Problem discovered on ARM/OMAP platforms where a nested IRQ that's
> also a wakeup IRQ happens late in suspend and needed to be retriggered
> during the resume process.
>
> Reported-by: Kevin Hilman <khilman@ti.com>
> Tested-by: Kevin Hilman <khilman@ti.com>
> [khilman at ti.com: changelog edits, clear IRQS_REPLAY in handle_nested_irq()]
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Umm, we also have the converse situation. We have platforms where the
resend has to be done from the child IRQ, and the parent must not be
touched. I hope that doesn't break those.
^ permalink raw reply
* [Linaro-mm-sig] [RFC 0/2] DMA-mapping & IOMMU - physically contiguous allocations
From: Inki Dae @ 2012-10-16 22:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016.171338.1300372057637804407.hdoyu@nvidia.com>
Hi Hiroshi,
2012. 10. 16. ?? 11:13 Hiroshi Doyu <hdoyu@nvidia.com> ??:
> Hi Inki,
>
> Inki Dae <inki.dae@samsung.com> wrote @ Tue, 16 Oct 2012 12:12:49 +0200:
>
>> Hi Hiroshi,
>>
>> 2012/10/16 Hiroshi Doyu <hdoyu@nvidia.com>:
>>> Hi Inki/Marek,
>>>
>>> On Tue, 16 Oct 2012 02:50:16 +0200
>>> Inki Dae <inki.dae@samsung.com> wrote:
>>>
>>>> 2012/10/15 Marek Szyprowski <m.szyprowski@samsung.com>:
>>>>> Hello,
>>>>>
>>>>> Some devices, which have IOMMU, for some use cases might require to
>>>>> allocate a buffers for DMA which is contiguous in physical memory. Such
>>>>> use cases appears for example in DRM subsystem when one wants to improve
>>>>> performance or use secure buffer protection.
>>>>>
>>>>> I would like to ask if adding a new attribute, as proposed in this RFC
>>>>> is a good idea? I feel that it might be an attribute just for a single
>>>>> driver, but I would like to know your opinion. Should we look for other
>>>>> solution?
>>>>>
>>>>
>>>> In addition, currently we have worked dma-mapping-based iommu support
>>>> for exynos drm driver with this patch set so this patch set has been
>>>> tested with iommu enabled exynos drm driver and worked fine. actually,
>>>> this feature is needed for secure mode such as TrustZone. in case of
>>>> Exynos SoC, memory region for secure mode should be physically
>>>> contiguous and also maybe OMAP but now dma-mapping framework doesn't
>>>> guarantee physically continuous memory allocation so this patch set
>>>> would make it possible.
>>>
>>> Agree that the contigous memory allocation is necessary for us too.
>>>
>>> In addition to those contiguous/discontiguous page allocation, is
>>> there any way to _import_ anonymous pages allocated by a process to be
>>> used in dma-mapping API later?
>>>
>>> I'm considering the following scenario, an user process allocates a
>>> buffer by malloc() in advance, and then it asks some driver to convert
>>> that buffer into IOMMU'able/DMA'able ones later. In this case, pages
>>> are discouguous and even they may not be yet allocated at
>>> malloc()/mmap().
>>>
>>
>> I'm not sure I understand what you mean but we had already tried this
>> way and for this, you can refer to below link,
>> http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg22555.html
>
> The above patch doesn't seem to have so much platform/SoC specific
> code but rather it could common over other SoC as well. Is there any
> plan to make it more generic, which can be used by other DRM drivers?
>
Right, the above patch has no any platform/SoC specific code but doesn't use dma-mapping API . Anyway we should refrain from using such thing because gem object could still be used and shared with other processes even if user process freed user region allocated by malloc()
And our new patch in progress would resolve this issue and this way is similar to drm-based via driver of mainline kernel. And this patch isn't considered for common use and is specific to platform/SoC so much. The pages backed can be used only by 2d gpu's dma.
Thanks,
Inki Dae
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email at kvack.org </a>
^ permalink raw reply
* [PATCH V2 0/7] support the cpts found on am335x devices
From: N, Mugunthan V @ 2012-10-16 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016171407.GA2176@netboy.at.omicron.at>
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran at gmail.com]
> Sent: Tuesday, October 16, 2012 10:44 PM
> To: N, Mugunthan V
> Cc: netdev at vger.kernel.org; linux-arm-kernel at lists.infradead.org; David
> Miller; Chemparathy, Cyril; Govindarajan, Sriramakrishnan
> Subject: Re: [PATCH V2 0/7] support the cpts found on am335x devices
>
> On Tue, Oct 16, 2012 at 04:33:55PM +0000, N, Mugunthan V wrote:
> > I had seen some issues with the patch series.
>
> Please take another look. Excepting the last, none of your points
> holds water.
>
> > * CPTS will hold only LSB 32 bits of 64 bit Timer and the upper 32
> bit
> > time value has to be taken care by the software, but the time stamp
> > which is passed to skb or PTP clock consist of only 32 bit time
> value
>
> The driver handles this already.
Yes, I do agree that driver handles it. As Half roll over and Full roll
over events are not handled in the driver, I am just curious how will
the misaligned TS would be handled and also in cpts set time, the Lower
32 bit time is written to CPTS counter
>
> > * CPTS interrupts should be utilized to service Half and Full roll
> over
> > events as it is non sync events with respect to get/set time and
> PTP
> > pkt Tx/Rx
>
> Nope, no need for interrupts, since we already have a better way to
> handle this.
Since we poll for the 32bit over flow for every HZ * 8 cycle, won't
there be a system overhead. If the CPTS ref clock is changed according
to the ptp freq adjust api, how will the timecounter take care of change
in frequency
>
> > * CPTS Time which is obtained from hardware is not actually a nano
> > seconds as the CPTS ref clock is tied to 250MHz for AM335x.
>
> Did you even look at the code in my patch?
I had gone through the patch, but the same driver can be used in TI814x
where the user has the option to change the frequency from 250MHz may to
1GHz also, I thought of how it will be handled if we fix the multiplication
factor
>
> > * CPSW register mapping done in this patch series removes the CPSW
> > driver support for previous version found in TI814x
>
> In which Linux version (or commit) did this driver appear?
> I never saw it.
The current driver which is in vanilla kernel doesn't use extended slave
address which are conflict between TI814x CPSW IP version and AM335x CPSW
IP version. I have just posted my version of CPTS implementation. May be
we can work together make the driver compatible with both CPSW versions
>
> > * CPSW Time stamping is done only for port 0 and port 1 is not done
>
> Yes, you are right, and it is strange that the hardware time stamps on
> the external ports of the switch, and not at the host port as it
> should. Of course it does present us with a problem, since we cannot
> reasonably have both ports time stamping at the same time. I propose
> simply using a device tree attribute to tell which port to activate.
Since CPSW is a 3port Switch we should not fix time stamping will be enabled
only for slave 0 or passing slave number through DT. Its better if we
can configure both the slaves. This can be tested with EVM-sk which has
both the slave ports pinned out.
>
> Thanks,
> Richard
^ permalink raw reply
* [PATCHv4 8/8] ARM: OMAP3: do not delete per_clkdm autodeps during idle
From: Kevin Hilman @ 2012-10-17 0:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210160603390.9767@utopia.booyaka.com>
Paul Walmsley <paul@pwsan.com> writes:
> Hi Kevin,
>
> Here's an updated version of this one, with the erratum coverage expanded
> to include OMAP34xx/35xx.
>
> I think this one can replace Tero's "[PATCHv6 06/11] ARM: OMAP:
> clockdomain: add support for preventing autodep delete" and "[PATCHv6
> 07/11] ARM: OMAP3: do not delete per_clkdm autodeps during idle". Tero,
> please let us know if you feel otherwise.
>
> The patch seems to pass testing on 37xx. Was not able to really test it
> on 35xx due to PM regressions in v3.7-rc1.
With workarounds for some of the other regressions, this passes ret/off
idle/suspend tests on 3530/Overo, 3730/OveroSTORM and 3730/Beagle-xM.
Queueing for v3.7-rc.
Thanks,
Kevin
^ permalink raw reply
* [PATCH] ARM: OMAP: move plat-omap/include/plat/sdrc.h into mach-omap2/sdrc.h
From: Paul Walmsley @ 2012-10-17 0:46 UTC (permalink / raw)
To: linux-arm-kernel
Remove arch/arm/plat-omap/include/plat/sdrc.h by folding its contents
into arch/arm/mach-omap2/sdrc.h. The objective is to assist Tony in
cleaning out arch/arm/plat-omap/, as his upstreams request.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
---
This has a dependency on Tomi's "OMAP: VRFB: convert to platform device"
series.
arch/arm/mach-omap2/board-omap3logic.c | 1 -
arch/arm/mach-omap2/clkt2xxx_dpllcore.c | 2 +-
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 2 +-
arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 1 -
arch/arm/mach-omap2/control.c | 4 +-
arch/arm/mach-omap2/gpmc.c | 1 -
arch/arm/mach-omap2/io.c | 2 +-
arch/arm/mach-omap2/pm34xx.c | 1 -
arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h | 2 +-
arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h | 2 +-
arch/arm/mach-omap2/sdram-nokia.c | 2 +-
arch/arm/mach-omap2/sdram-numonyx-m65kxxxxam.h | 2 +-
.../mach-omap2/sdram-qimonda-hyb18m512160af-6.h | 2 +-
arch/arm/mach-omap2/sdrc.c | 1 -
arch/arm/mach-omap2/sdrc.h | 153 +++++++++++++++++-
arch/arm/mach-omap2/sdrc2xxx.c | 1 -
arch/arm/plat-omap/include/plat/sdrc.h | 164 --------------------
17 files changed, 156 insertions(+), 187 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/sdrc.h
diff --git a/arch/arm/mach-omap2/board-omap3logic.c b/arch/arm/mach-omap2/board-omap3logic.c
index 7bd8253..cbcea42 100644
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ b/arch/arm/mach-omap2/board-omap3logic.c
@@ -36,7 +36,6 @@
#include "gpmc-smsc911x.h"
#include <plat/gpmc.h>
-#include <plat/sdrc.h>
#include <plat/usb.h>
#include "common.h"
diff --git a/arch/arm/mach-omap2/clkt2xxx_dpllcore.c b/arch/arm/mach-omap2/clkt2xxx_dpllcore.c
index 4ae4392..3507659 100644
--- a/arch/arm/mach-omap2/clkt2xxx_dpllcore.c
+++ b/arch/arm/mach-omap2/clkt2xxx_dpllcore.c
@@ -27,13 +27,13 @@
#include <plat/clock.h>
#include <plat/sram.h>
-#include <plat/sdrc.h>
#include "clock.h"
#include "clock2xxx.h"
#include "opp2xxx.h"
#include "cm2xxx_3xxx.h"
#include "cm-regbits-24xx.h"
+#include "sdrc.h"
/* #define DOWN_VARIABLE_DPLL 1 */ /* Experimental */
diff --git a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
index 3524f0e..0cf63e7 100644
--- a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
+++ b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
@@ -35,7 +35,6 @@
#include <plat/clock.h>
#include <plat/sram.h>
-#include <plat/sdrc.h>
#include "soc.h"
#include "clock.h"
@@ -43,6 +42,7 @@
#include "opp2xxx.h"
#include "cm2xxx_3xxx.h"
#include "cm-regbits-24xx.h"
+#include "sdrc.h"
const struct prcm_config *curr_prcm_set;
const struct prcm_config *rate_table;
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index 7c6da2f..aff6ca4 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -23,7 +23,6 @@
#include <plat/clock.h>
#include <plat/sram.h>
-#include <plat/sdrc.h>
#include "clock.h"
#include "clock3xxx.h"
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index d1ff839..bf2be5c 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -1,7 +1,7 @@
/*
* OMAP2/3 System Control Module register access
*
- * Copyright (C) 2007 Texas Instruments, Inc.
+ * Copyright (C) 2007, 2012 Texas Instruments, Inc.
* Copyright (C) 2007 Nokia Corporation
*
* Written by Paul Walmsley
@@ -15,8 +15,6 @@
#include <linux/kernel.h>
#include <linux/io.h>
-#include <plat/sdrc.h>
-
#include "soc.h"
#include "iomap.h"
#include "common.h"
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5ac5cf3..e7f2b80 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -31,7 +31,6 @@
#include <plat/cpu.h>
#include <plat/gpmc.h>
-#include <plat/sdrc.h>
#include <plat/omap_device.h>
#include "soc.h"
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4234d28..ab82dbe 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -26,7 +26,6 @@
#include <asm/mach/map.h>
#include <plat/sram.h>
-#include <plat/sdrc.h>
#include <plat/serial.h>
#include <plat/omap-pm.h>
#include <plat/omap_hwmod.h>
@@ -43,6 +42,7 @@
#include "clock2xxx.h"
#include "clock3xxx.h"
#include "clock44xx.h"
+#include "sdrc.h"
/*
* The machine specific code may provide the extra mapping besides the
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index ba670db..ee0bffc 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -38,7 +38,6 @@
#include <plat/sram.h>
#include "clockdomain.h"
#include "powerdomain.h"
-#include <plat/sdrc.h>
#include <plat/prcm.h>
#include <plat/gpmc.h>
#include <plat/dma.h>
diff --git a/arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h b/arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h
index 8bfaf34..1ee58c2 100644
--- a/arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h
+++ b/arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h
@@ -11,7 +11,7 @@
#ifndef __ARCH_ARM_MACH_OMAP2_SDRAM_HYNIX_H8MBX00U0MER0EM
#define __ARCH_ARM_MACH_OMAP2_SDRAM_HYNIX_H8MBX00U0MER0EM
-#include <plat/sdrc.h>
+#include "sdrc.h"
/* Hynix H8MBX00U0MER-0EM */
static struct omap_sdrc_params h8mbx00u0mer0em_sdrc_params[] = {
diff --git a/arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h b/arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h
index a391b49..85cccc0 100644
--- a/arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h
+++ b/arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h
@@ -14,7 +14,7 @@
#ifndef ARCH_ARM_MACH_OMAP2_SDRAM_MICRON_MT46H32M32LF
#define ARCH_ARM_MACH_OMAP2_SDRAM_MICRON_MT46H32M32LF
-#include <plat/sdrc.h>
+#include "sdrc.h"
/* Micron MT46H32M32LF-6 */
/* XXX Using ARE = 0x1 (no autorefresh burst) -- can this be changed? */
diff --git a/arch/arm/mach-omap2/sdram-nokia.c b/arch/arm/mach-omap2/sdram-nokia.c
index 845c4fd..5e5702c 100644
--- a/arch/arm/mach-omap2/sdram-nokia.c
+++ b/arch/arm/mach-omap2/sdram-nokia.c
@@ -19,9 +19,9 @@
#include "common.h"
#include <plat/clock.h>
-#include <plat/sdrc.h>
#include "sdram-nokia.h"
+#include "sdrc.h"
/* In picoseconds, except for tREF (ns), tXP, tCKE, tWTR (clks) */
struct sdram_timings {
diff --git a/arch/arm/mach-omap2/sdram-numonyx-m65kxxxxam.h b/arch/arm/mach-omap2/sdram-numonyx-m65kxxxxam.h
index cd43529..003f7bf 100644
--- a/arch/arm/mach-omap2/sdram-numonyx-m65kxxxxam.h
+++ b/arch/arm/mach-omap2/sdram-numonyx-m65kxxxxam.h
@@ -11,7 +11,7 @@
#ifndef __ARCH_ARM_MACH_OMAP2_SDRAM_NUMONYX_M65KXXXXAM
#define __ARCH_ARM_MACH_OMAP2_SDRAM_NUMONYX_M65KXXXXAM
-#include <plat/sdrc.h>
+#include "sdrc.h"
/* Numonyx M65KXXXXAM */
static struct omap_sdrc_params m65kxxxxam_sdrc_params[] = {
diff --git a/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h b/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
index 0e518a7..8dc3de5 100644
--- a/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
+++ b/arch/arm/mach-omap2/sdram-qimonda-hyb18m512160af-6.h
@@ -14,7 +14,7 @@
#ifndef ARCH_ARM_MACH_OMAP2_SDRAM_QIMONDA_HYB18M512160AF6
#define ARCH_ARM_MACH_OMAP2_SDRAM_QIMONDA_HYB18M512160AF6
-#include <plat/sdrc.h>
+#include "sdrc.h"
/* Qimonda HYB18M512160AF-6 */
static struct omap_sdrc_params hyb18m512160af6_sdrc_params[] = {
diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c
index e3d345f..503d41f9 100644
--- a/arch/arm/mach-omap2/sdrc.c
+++ b/arch/arm/mach-omap2/sdrc.c
@@ -27,7 +27,6 @@
#include <plat/clock.h>
#include <plat/sram.h>
-#include <plat/sdrc.h>
#include "sdrc.h"
static struct omap_sdrc_params *sdrc_init_params_cs0, *sdrc_init_params_cs1;
diff --git a/arch/arm/mach-omap2/sdrc.h b/arch/arm/mach-omap2/sdrc.h
index b3f8379..cdca44f 100644
--- a/arch/arm/mach-omap2/sdrc.h
+++ b/arch/arm/mach-omap2/sdrc.h
@@ -2,12 +2,14 @@
#define __ARCH_ARM_MACH_OMAP2_SDRC_H
/*
- * OMAP2 SDRC register definitions
+ * OMAP2/3 SDRC/SMS macros and prototypes
*
- * Copyright (C) 2007 Texas Instruments, Inc.
- * Copyright (C) 2007 Nokia Corporation
+ * Copyright (C) 2007-2008, 2012 Texas Instruments, Inc.
+ * Copyright (C) 2007-2008 Nokia Corporation
*
- * Written by Paul Walmsley
+ * Paul Walmsley
+ * Tony Lindgren
+ * Richard Woodruff
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -15,8 +17,6 @@
*/
#undef DEBUG
-#include <plat/sdrc.h>
-
#ifndef __ASSEMBLER__
#include <linux/io.h>
@@ -50,6 +50,62 @@ static inline u32 sms_read_reg(u16 reg)
{
return __raw_readl(OMAP_SMS_REGADDR(reg));
}
+
+
+/**
+ * struct omap_sdrc_params - SDRC parameters for a given SDRC clock rate
+ * @rate: SDRC clock rate (in Hz)
+ * @actim_ctrla: Value to program to SDRC_ACTIM_CTRLA for this rate
+ * @actim_ctrlb: Value to program to SDRC_ACTIM_CTRLB for this rate
+ * @rfr_ctrl: Value to program to SDRC_RFR_CTRL for this rate
+ * @mr: Value to program to SDRC_MR for this rate
+ *
+ * This structure holds a pre-computed set of register values for the
+ * SDRC for a given SDRC clock rate and SDRAM chip. These are
+ * intended to be pre-computed and specified in an array in the board-*.c
+ * files. The structure is keyed off the 'rate' field.
+ */
+struct omap_sdrc_params {
+ unsigned long rate;
+ u32 actim_ctrla;
+ u32 actim_ctrlb;
+ u32 rfr_ctrl;
+ u32 mr;
+};
+
+#ifdef CONFIG_SOC_HAS_OMAP2_SDRC
+void omap2_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
+ struct omap_sdrc_params *sdrc_cs1);
+#else
+static inline void __init omap2_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
+ struct omap_sdrc_params *sdrc_cs1) {};
+#endif
+
+int omap2_sdrc_get_params(unsigned long r,
+ struct omap_sdrc_params **sdrc_cs0,
+ struct omap_sdrc_params **sdrc_cs1);
+void omap2_sms_save_context(void);
+void omap2_sms_restore_context(void);
+
+void omap2_sms_write_rot_control(u32 val, unsigned ctx);
+void omap2_sms_write_rot_size(u32 val, unsigned ctx);
+void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx);
+
+struct memory_timings {
+ u32 m_type; /* ddr = 1, sdr = 0 */
+ u32 dll_mode; /* use lock mode = 1, unlock mode = 0 */
+ u32 slow_dll_ctrl; /* unlock mode, dll value for slow speed */
+ u32 fast_dll_ctrl; /* unlock mode, dll value for fast speed */
+ u32 base_cs; /* base chip select to use for calculations */
+};
+
+extern void omap2xxx_sdrc_init_params(u32 force_lock_to_unlock_mode);
+struct omap_sdrc_params *rx51_get_sdram_timings(void);
+
+u32 omap2xxx_sdrc_dll_is_unlocked(void);
+u32 omap2xxx_sdrc_reprogram(u32 level, u32 force);
+
+
#else
#define OMAP242X_SDRC_REGADDR(reg) \
OMAP2_L3_IO_ADDRESS(OMAP2420_SDRC_BASE + (reg))
@@ -57,6 +113,7 @@ static inline u32 sms_read_reg(u16 reg)
OMAP2_L3_IO_ADDRESS(OMAP243X_SDRC_BASE + (reg))
#define OMAP34XX_SDRC_REGADDR(reg) \
OMAP2_L3_IO_ADDRESS(OMAP343X_SDRC_BASE + (reg))
+
#endif /* __ASSEMBLER__ */
/* Minimum frequency that the SDRC DLL can lock at */
@@ -74,4 +131,88 @@ static inline u32 sms_read_reg(u16 reg)
*/
#define SDRC_MPURATE_LOOPS 96
+/* SDRC register offsets - read/write with sdrc_{read,write}_reg() */
+
+#define SDRC_SYSCONFIG 0x010
+#define SDRC_CS_CFG 0x040
+#define SDRC_SHARING 0x044
+#define SDRC_ERR_TYPE 0x04C
+#define SDRC_DLLA_CTRL 0x060
+#define SDRC_DLLA_STATUS 0x064
+#define SDRC_DLLB_CTRL 0x068
+#define SDRC_DLLB_STATUS 0x06C
+#define SDRC_POWER 0x070
+#define SDRC_MCFG_0 0x080
+#define SDRC_MR_0 0x084
+#define SDRC_EMR2_0 0x08c
+#define SDRC_ACTIM_CTRL_A_0 0x09c
+#define SDRC_ACTIM_CTRL_B_0 0x0a0
+#define SDRC_RFR_CTRL_0 0x0a4
+#define SDRC_MANUAL_0 0x0a8
+#define SDRC_MCFG_1 0x0B0
+#define SDRC_MR_1 0x0B4
+#define SDRC_EMR2_1 0x0BC
+#define SDRC_ACTIM_CTRL_A_1 0x0C4
+#define SDRC_ACTIM_CTRL_B_1 0x0C8
+#define SDRC_RFR_CTRL_1 0x0D4
+#define SDRC_MANUAL_1 0x0D8
+
+#define SDRC_POWER_AUTOCOUNT_SHIFT 8
+#define SDRC_POWER_AUTOCOUNT_MASK (0xffff << SDRC_POWER_AUTOCOUNT_SHIFT)
+#define SDRC_POWER_CLKCTRL_SHIFT 4
+#define SDRC_POWER_CLKCTRL_MASK (0x3 << SDRC_POWER_CLKCTRL_SHIFT)
+#define SDRC_SELF_REFRESH_ON_AUTOCOUNT (0x2 << SDRC_POWER_CLKCTRL_SHIFT)
+
+/*
+ * These values represent the number of memory clock cycles between
+ * autorefresh initiation. They assume 1 refresh per 64 ms (JEDEC), 8192
+ * rows per device, and include a subtraction of a 50 cycle window in the
+ * event that the autorefresh command is delayed due to other SDRC activity.
+ * The '| 1' sets the ARE field to send one autorefresh when the autorefresh
+ * counter reaches 0.
+ *
+ * These represent optimal values for common parts, it won't work for all.
+ * As long as you scale down, most parameters are still work, they just
+ * become sub-optimal. The RFR value goes in the opposite direction. If you
+ * don't adjust it down as your clock period increases the refresh interval
+ * will not be met. Setting all parameters for complete worst case may work,
+ * but may cut memory performance by 2x. Due to errata the DLLs need to be
+ * unlocked and their value needs run time calibration. A dynamic call is
+ * need for that as no single right value exists acorss production samples.
+ *
+ * Only the FULL speed values are given. Current code is such that rate
+ * changes must be made@DPLLoutx2. The actual value adjustment for low
+ * frequency operation will be handled by omap_set_performance()
+ *
+ * By having the boot loader boot up in the fastest L4 speed available likely
+ * will result in something which you can switch between.
+ */
+#define SDRC_RFR_CTRL_165MHz (0x00044c00 | 1)
+#define SDRC_RFR_CTRL_133MHz (0x0003de00 | 1)
+#define SDRC_RFR_CTRL_100MHz (0x0002da01 | 1)
+#define SDRC_RFR_CTRL_110MHz (0x0002da01 | 1) /* Need to calc */
+#define SDRC_RFR_CTRL_BYPASS (0x00005000 | 1) /* Need to calc */
+
+
+/*
+ * SMS register access
+ */
+
+#define OMAP242X_SMS_REGADDR(reg) \
+ (void __iomem *)OMAP2_L3_IO_ADDRESS(OMAP2420_SMS_BASE + reg)
+#define OMAP243X_SMS_REGADDR(reg) \
+ (void __iomem *)OMAP2_L3_IO_ADDRESS(OMAP243X_SMS_BASE + reg)
+#define OMAP343X_SMS_REGADDR(reg) \
+ (void __iomem *)OMAP2_L3_IO_ADDRESS(OMAP343X_SMS_BASE + reg)
+
+/* SMS register offsets - read/write with sms_{read,write}_reg() */
+
+#define SMS_SYSCONFIG 0x010
+#define SMS_ROT_CONTROL(context) (0x180 + 0x10 * context)
+#define SMS_ROT_SIZE(context) (0x184 + 0x10 * context)
+#define SMS_ROT_PHYSICAL_BA(context) (0x188 + 0x10 * context)
+/* REVISIT: fill in other SMS registers here */
+
+
+
#endif
diff --git a/arch/arm/mach-omap2/sdrc2xxx.c b/arch/arm/mach-omap2/sdrc2xxx.c
index 73e55e4..f7074ff 100644
--- a/arch/arm/mach-omap2/sdrc2xxx.c
+++ b/arch/arm/mach-omap2/sdrc2xxx.c
@@ -26,7 +26,6 @@
#include <plat/clock.h>
#include <plat/sram.h>
-#include <plat/sdrc.h>
#include "soc.h"
#include "iomap.h"
diff --git a/arch/arm/plat-omap/include/plat/sdrc.h b/arch/arm/plat-omap/include/plat/sdrc.h
deleted file mode 100644
index 36d6a76..0000000
--- a/arch/arm/plat-omap/include/plat/sdrc.h
+++ /dev/null
@@ -1,164 +0,0 @@
-#ifndef ____ASM_ARCH_SDRC_H
-#define ____ASM_ARCH_SDRC_H
-
-/*
- * OMAP2/3 SDRC/SMS register definitions
- *
- * Copyright (C) 2007-2008 Texas Instruments, Inc.
- * Copyright (C) 2007-2008 Nokia Corporation
- *
- * Tony Lindgren
- * Paul Walmsley
- * Richard Woodruff
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-
-/* SDRC register offsets - read/write with sdrc_{read,write}_reg() */
-
-#define SDRC_SYSCONFIG 0x010
-#define SDRC_CS_CFG 0x040
-#define SDRC_SHARING 0x044
-#define SDRC_ERR_TYPE 0x04C
-#define SDRC_DLLA_CTRL 0x060
-#define SDRC_DLLA_STATUS 0x064
-#define SDRC_DLLB_CTRL 0x068
-#define SDRC_DLLB_STATUS 0x06C
-#define SDRC_POWER 0x070
-#define SDRC_MCFG_0 0x080
-#define SDRC_MR_0 0x084
-#define SDRC_EMR2_0 0x08c
-#define SDRC_ACTIM_CTRL_A_0 0x09c
-#define SDRC_ACTIM_CTRL_B_0 0x0a0
-#define SDRC_RFR_CTRL_0 0x0a4
-#define SDRC_MANUAL_0 0x0a8
-#define SDRC_MCFG_1 0x0B0
-#define SDRC_MR_1 0x0B4
-#define SDRC_EMR2_1 0x0BC
-#define SDRC_ACTIM_CTRL_A_1 0x0C4
-#define SDRC_ACTIM_CTRL_B_1 0x0C8
-#define SDRC_RFR_CTRL_1 0x0D4
-#define SDRC_MANUAL_1 0x0D8
-
-#define SDRC_POWER_AUTOCOUNT_SHIFT 8
-#define SDRC_POWER_AUTOCOUNT_MASK (0xffff << SDRC_POWER_AUTOCOUNT_SHIFT)
-#define SDRC_POWER_CLKCTRL_SHIFT 4
-#define SDRC_POWER_CLKCTRL_MASK (0x3 << SDRC_POWER_CLKCTRL_SHIFT)
-#define SDRC_SELF_REFRESH_ON_AUTOCOUNT (0x2 << SDRC_POWER_CLKCTRL_SHIFT)
-
-/*
- * These values represent the number of memory clock cycles between
- * autorefresh initiation. They assume 1 refresh per 64 ms (JEDEC), 8192
- * rows per device, and include a subtraction of a 50 cycle window in the
- * event that the autorefresh command is delayed due to other SDRC activity.
- * The '| 1' sets the ARE field to send one autorefresh when the autorefresh
- * counter reaches 0.
- *
- * These represent optimal values for common parts, it won't work for all.
- * As long as you scale down, most parameters are still work, they just
- * become sub-optimal. The RFR value goes in the opposite direction. If you
- * don't adjust it down as your clock period increases the refresh interval
- * will not be met. Setting all parameters for complete worst case may work,
- * but may cut memory performance by 2x. Due to errata the DLLs need to be
- * unlocked and their value needs run time calibration. A dynamic call is
- * need for that as no single right value exists acorss production samples.
- *
- * Only the FULL speed values are given. Current code is such that rate
- * changes must be made@DPLLoutx2. The actual value adjustment for low
- * frequency operation will be handled by omap_set_performance()
- *
- * By having the boot loader boot up in the fastest L4 speed available likely
- * will result in something which you can switch between.
- */
-#define SDRC_RFR_CTRL_165MHz (0x00044c00 | 1)
-#define SDRC_RFR_CTRL_133MHz (0x0003de00 | 1)
-#define SDRC_RFR_CTRL_100MHz (0x0002da01 | 1)
-#define SDRC_RFR_CTRL_110MHz (0x0002da01 | 1) /* Need to calc */
-#define SDRC_RFR_CTRL_BYPASS (0x00005000 | 1) /* Need to calc */
-
-
-/*
- * SMS register access
- */
-
-#define OMAP242X_SMS_REGADDR(reg) \
- (void __iomem *)OMAP2_L3_IO_ADDRESS(OMAP2420_SMS_BASE + reg)
-#define OMAP243X_SMS_REGADDR(reg) \
- (void __iomem *)OMAP2_L3_IO_ADDRESS(OMAP243X_SMS_BASE + reg)
-#define OMAP343X_SMS_REGADDR(reg) \
- (void __iomem *)OMAP2_L3_IO_ADDRESS(OMAP343X_SMS_BASE + reg)
-
-/* SMS register offsets - read/write with sms_{read,write}_reg() */
-
-#define SMS_SYSCONFIG 0x010
-#define SMS_ROT_CONTROL(context) (0x180 + 0x10 * context)
-#define SMS_ROT_SIZE(context) (0x184 + 0x10 * context)
-#define SMS_ROT_PHYSICAL_BA(context) (0x188 + 0x10 * context)
-/* REVISIT: fill in other SMS registers here */
-
-
-#ifndef __ASSEMBLER__
-
-/**
- * struct omap_sdrc_params - SDRC parameters for a given SDRC clock rate
- * @rate: SDRC clock rate (in Hz)
- * @actim_ctrla: Value to program to SDRC_ACTIM_CTRLA for this rate
- * @actim_ctrlb: Value to program to SDRC_ACTIM_CTRLB for this rate
- * @rfr_ctrl: Value to program to SDRC_RFR_CTRL for this rate
- * @mr: Value to program to SDRC_MR for this rate
- *
- * This structure holds a pre-computed set of register values for the
- * SDRC for a given SDRC clock rate and SDRAM chip. These are
- * intended to be pre-computed and specified in an array in the board-*.c
- * files. The structure is keyed off the 'rate' field.
- */
-struct omap_sdrc_params {
- unsigned long rate;
- u32 actim_ctrla;
- u32 actim_ctrlb;
- u32 rfr_ctrl;
- u32 mr;
-};
-
-#ifdef CONFIG_SOC_HAS_OMAP2_SDRC
-void omap2_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
- struct omap_sdrc_params *sdrc_cs1);
-#else
-static inline void __init omap2_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
- struct omap_sdrc_params *sdrc_cs1) {};
-#endif
-
-int omap2_sdrc_get_params(unsigned long r,
- struct omap_sdrc_params **sdrc_cs0,
- struct omap_sdrc_params **sdrc_cs1);
-void omap2_sms_save_context(void);
-void omap2_sms_restore_context(void);
-
-void omap2_sms_write_rot_control(u32 val, unsigned ctx);
-void omap2_sms_write_rot_size(u32 val, unsigned ctx);
-void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx);
-
-#ifdef CONFIG_ARCH_OMAP2
-
-struct memory_timings {
- u32 m_type; /* ddr = 1, sdr = 0 */
- u32 dll_mode; /* use lock mode = 1, unlock mode = 0 */
- u32 slow_dll_ctrl; /* unlock mode, dll value for slow speed */
- u32 fast_dll_ctrl; /* unlock mode, dll value for fast speed */
- u32 base_cs; /* base chip select to use for calculations */
-};
-
-extern void omap2xxx_sdrc_init_params(u32 force_lock_to_unlock_mode);
-struct omap_sdrc_params *rx51_get_sdram_timings(void);
-
-u32 omap2xxx_sdrc_dll_is_unlocked(void);
-u32 omap2xxx_sdrc_reprogram(u32 level, u32 force);
-
-#endif /* CONFIG_ARCH_OMAP2 */
-
-#endif /* __ASSEMBLER__ */
-
-#endif
--
1.7.10.4
^ permalink raw reply related
* [PATCH] ARM: OMAP2: UART: fix console UART mismatched runtime PM status
From: Kevin Hilman @ 2012-10-17 1:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016211828.GL15569@atomide.com>
Tony Lindgren <tony@atomide.com> writes:
> * Felipe Balbi <balbi@ti.com> [121016 03:32]:
>> Hi,
>>
>> On Mon, Oct 15, 2012 at 04:49:58PM -0700, Kevin Hilman wrote:
>> > From: Kevin Hilman <khilman@ti.com>
>> >
>> > The runtime PM framework assumes that the hardware state of devices
>> > when initialized is disabled. For all omap_devices, we idle/disable
>> > device by default. However, the console uart uses a "no idle" option
>> > during omap_device init in order to allow earlyprintk usage to work
>> > seamlessly during boot.
>> >
>> > Because the hardware is left partially enabled after init (whatever
>> > the bootloader settings were), the omap_device should later be fully
>> > initialized (including mux) and the runtime PM framework should be
>> > told that the device is active, and not disabled so that the hardware
>> > state is in sync with runtime PM state.
>> >
>> > To fix, after the device has been created/registered, call
>> > omap_device_enable() to finialize init and use pm_runtime_set_active()
>> > to tell the runtime PM core the device is enabled.
>> >
>> > Tested on 2420/n810, 3530/Overo, 3530/Beagle, 3730/OveroSTORM,
>> > 3730/Beagle-xM, 4460/PandaES.
>> >
>> > Reported-by: Paul Walmsley <paul@pwsan.com>
>> > Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> > Cc: Felipe Balbi <balbi@ti.com>
>> > Cc: Sourav Poddar <sourav.poddar@ti.com>
>> > Signed-off-by: Kevin Hilman <khilman@ti.com>
>> > ---
>> > Applies against v3.7-rc1.
>> > Fix targetted for v3.7.
>> >
>> > I'm still not entirely sure why this has worked up to now on OMAP3/4
>> > but not on OMAP2. Even so, this fix is needed for all platforms to
>> > ensure matching hardware state and runtime PM state.
>> >
>> > arch/arm/mach-omap2/serial.c | 5 +++++
>> > 1 file changed, 5 insertions(+)
>> >
>> > diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
>> > index 0405c81..37b5dbe 100644
>> > --- a/arch/arm/mach-omap2/serial.c
>> > +++ b/arch/arm/mach-omap2/serial.c
>> > @@ -327,6 +327,11 @@ void __init omap_serial_init_port(struct omap_board_data *bdata,
>> > if ((console_uart_id == bdata->id) && no_console_suspend)
>> > omap_device_disable_idle_on_suspend(pdev);
>> >
>> > + if (console_uart_id == bdata->id) {
>> > + omap_device_enable(pdev);
>> > + pm_runtime_set_active(&pdev->dev);
>> > + }
>> > +
>> > oh->mux = omap_hwmod_mux_init(bdata->pads, bdata->pads_cnt);
>> >
>> > oh->dev_attr = uart;
>>
>> looks good to me. Even took care of doing that only for the console
>> UART.
>
> Applying into omap-for-v3.7-rc1/fixes-take3.
>
Doh, this isn't quite right yet. Some more PM testing shows that UART
wakeups are broken, so this isn't ready for v3.7 yet.
To be continued...
Kevin
^ permalink raw reply
* [PATCH] ARM: OMAP2: UART: fix console UART mismatched runtime PM status
From: Tony Lindgren @ 2012-10-17 2:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87wqyplxjo.fsf@deeprootsystems.com>
* Kevin Hilman <khilman@deeprootsystems.com> [121016 18:04]:
>
> Doh, this isn't quite right yet. Some more PM testing shows that UART
> wakeups are broken, so this isn't ready for v3.7 yet.
OK I'll drop it then.
Tony
^ permalink raw reply
* [PATCH v3 2/2] i2c: change id to let i2c-at91 work
From: Bo Shen @ 2012-10-17 2:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016111027.GE12801@game.jcrosoft.org>
Hi J,
On 10/16/2012 19:10, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 18:25 Tue 16 Oct , Bo Shen wrote:
>> Hi J,
>>
>> On 10/16/2012 16:39, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 11:13 Tue 16 Oct , Bo Shen wrote:
>>>> Hi J,
>>>>
>>>> On 10/15/2012 23:02, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>> On 17:30 Mon 15 Oct , Bo Shen wrote:
>>>>>> The i2c core driver will turn the platform device ID to busnum
>>>>>> When using platfrom device ID as -1, it means dynamically assigned
>>>>>> the busnum. When writing code, we need to make sure the busnum,
>>>>>> and call i2c_register_board_info(int busnum, ...) to register device
>>>>>> if using -1, we do not know the value of busnum
>>>>>>
>>>>>> In order to solve this issue, set the platform device ID as a fix number
>>>>>> Here using 0 to match the busnum used in i2c_regsiter_board_info()
>>>>>>
>>>>>> Signed-off-by: Bo Shen <voice.shen@atmel.com>
>>>>>> ---
>>>>>
>>>>> can you check when this append for the first time to schedule a patch for stable too
>>>>
>>>> OK. I will resend it and add linux stable into the cc list.
>>> no this not how it work
>>>
>>> I ask you to check which patch add the regression and then when this is
>>> applied in the kernel we will request greg to apply it too to the stable
>>
>> The code is using id = -1 appear 4 years ago. And after dig, I don't
>> find which patch cause this the regression.
> so use git bisect to find the commit responsible
Thanks for your information.
Finally, I found the following commit add this:
3267c077e589bc146a0b45e220fcefafbf83fb80
[ARM] 3396/2: AT91RM9200 Platform devices update
BRs,
Bo Shen
> Best Regards,
> J.
>
^ permalink raw reply
* [PATCHv6 01/11] ARM: OMAP: clockdomain: Fix locking on _clkdm_clk_hwmod_enable / disable
From: Paul Walmsley @ 2012-10-17 2:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348589142-11983-2-git-send-email-t-kristo@ti.com>
On Tue, 25 Sep 2012, Tero Kristo wrote:
> Previously the code only acquired spinlock after increasing / decreasing
> the usecount value, which is wrong. This leaves a small window where
> a task switch may occur between the check of the usecount and the actual
> wakeup / sleep of the domain. Fixed by moving the spinlock locking before
> the usecount access. Left the usecount as atomic_t if someone wants an
> easy access to the parameter through atomic_read.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
- Paul
^ 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