* [PATCH v2] mxcmmc: use dmaengine API
From: Sascha Hauer @ 2011-02-21 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102181437.02943.arnd@arndb.de>
On Fri, Feb 18, 2011 at 02:37:02PM +0100, Arnd Bergmann wrote:
> On Friday 18 February 2011, Sascha Hauer wrote:
> > This switches the mxcmmc driver to use the dmaengine API. Unlike
> > the old one this one is always present in the tree, even if no DMA
> > is implemented, hence we can remove all the #ifdefs in from the driver.
> > The driver automatically switches to PIO mode if no DMA support or no
> > suitable channel is available.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>
> The patch looks good to me, but shouldn't you also add a Kconfig
> dependency or select on CONFIG_DMA_ENGINE? I don't see where that
> gets set.
I was about to answer with a patch adding a select on CONFIG_DMA_ENGINE
but just realized this isn't necessary. Without dmaengine support
dma_request_channel becomes a static inline returning NULL. The mxcmmc
driver falls back to PIO then and still works.
Sascha
--
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 1/2] video: Add i.MX23/28 framebuffer driver
From: Sascha Hauer @ 2011-02-21 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110218122946.GF18085@S2100-06.ap.freescale.net>
On Fri, Feb 18, 2011 at 08:29:47PM +0800, Shawn Guo wrote:
> > +
> > +#include <linux/kernel.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/clk.h>
> > +#include <linux/dma-mapping.h>
> > +#include <linux/io.h>
> > +#include <mach/fb.h>
> > +#include <mach/hardware.h>
> > +#include <mach/mxs.h>
> > +
> > +#define REG_SET 4
> > +#define REG_CLR 8
> > +
> We already have these defined in mxs.h
I know, but as Wolfram realized this makes the driver architecture
specific. So I decided to duplicate this here and to remove
mach/hardware.h and mach/mxs.h (obviously still present in the last
posted version)
Sascha
--
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 2/2] ARM i.MX23/28: Add framebuffer device support
From: Sascha Hauer @ 2011-02-21 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110218093622.GE18085@S2100-06.ap.freescale.net>
On Fri, Feb 18, 2011 at 05:36:23PM +0800, Shawn Guo wrote:
> On Fri, Feb 18, 2011 at 10:26:50AM +0100, Sascha Hauer wrote:
> > On Fri, Feb 18, 2011 at 05:17:18PM +0800, Shawn Guo wrote:
> > > > > I understand that "mxsfb" was picked up for the device name to
> > > > > reflect the driver name. But since this is the device under mach- mxs
> > > > > folder, can we simply call it "fb" just like the way you name fb.h?
> > > > >
> > > > > In this way, we have all mxs platform device naming schema aligned,
> > > > > auart, duart, dma, fb, fec, flexcan, mmc ...
> > > >
> > > > I see it the other way round. mach/fb.h is too generic, I would prefer
> > > > mach/mxsfb.h to be able to add support for a different framebuffer
> > > > later. So I better change fb.h to mxsfb.h.
> > > >
> > > I'm fine with either way, but just wondering what kind of fb later
> > > it is and its naming, relatively to mxsfs.
> >
> > IPU...?
> >
> AFAICT, this is something that never going to happen.
Just the first thing that came to my mind. It could also be the lcd
controller known from i.MX1/2
Sascha
--
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
* Question About Linux Memory Mapping
From: Drasko DRASKOVIC @ 2011-02-21 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110221131325.GP14495@n2100.arm.linux.org.uk>
On Mon, Feb 21, 2011 at 2:13 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Feb 21, 2011 at 01:13:16PM +0100, Drasko DRASKOVIC wrote:
>> Thanks for your answers.
>>
>> I can see now that "mem" parameter is parsed in
>> arch/arm/kernel/setup.c, as Nicolas underlined. However, in my case
>> early_mem() is never called during the Linux boot.
>>
>> Does anybody have an idea why ?
>
> Maybe the command line setting is being ignored by your boot loader
> and the one built-in to the kernel is being used?
>
> Maybe your kernel is configured to ignore the command line supplied
> by your boot loader?
>
> Maybe you're setting it in the kernel build but not realising that
> the boot loader passed one is being used instead?
Turns out that I had badly formatted command line parameters. After
correcting this everything works fine.
Thanks again for the help.
BR,
Drasko
^ permalink raw reply
* [PATCH v4 15/19] ARM: LPAE: use phys_addr_t instead of unsigned long for physical addresses
From: Will Deacon @ 2011-02-21 14:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110219182631.GS29493@n2100.arm.linux.org.uk>
Hi Russell,
On Sat, 2011-02-19 at 18:26 +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 24, 2011 at 05:55:57PM +0000, Catalin Marinas wrote:
> > From: Will Deacon <will.deacon@arm.com>
> >
> > The unsigned long datatype is not sufficient for mapping physical addresses
> > >= 4GB.
> >
> > This patch ensures that the phys_addr_t datatype is used to represent
> > physical addresses which may be beyond the range of an unsigned long.
> > The virt <-> phys macros are updated accordingly to ensure that virtual
> > addresses can remain as they are.
> >
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
>
> This patch needs some more things fixed to prevent warnings:
Ah yes, this is for the non-HIGHMEM case which I hadn't considered for
LPAE. It's a perfectly reasonable configuration I suppose so this needs
fixing.
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index a81355d..6cf76b3 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -809,9 +809,10 @@ static void __init sanity_check_meminfo(void)
> */
> if (__va(bank->start) >= vmalloc_min ||
> __va(bank->start) < (void *)PAGE_OFFSET) {
> - printk(KERN_NOTICE "Ignoring RAM at %.8lx-%.8lx "
> + printk(KERN_NOTICE "Ignoring RAM at %.8llx-%.8llx "
> "(vmalloc region overlap).\n",
> - bank->start, bank->start + bank->size - 1);
> + (unsigned long long)bank->start,
> + (unsigned long long)bank->start + bank->size - 1);
> continue;
> }
>
> @@ -822,10 +823,11 @@ static void __init sanity_check_meminfo(void)
> if (__va(bank->start + bank->size) > vmalloc_min ||
> __va(bank->start + bank->size) < __va(bank->start)) {
> unsigned long newsize = vmalloc_min - __va(bank->start);
> - printk(KERN_NOTICE "Truncating RAM at %.8lx-%.8lx "
> - "to -%.8lx (vmalloc region overlap).\n",
> - bank->start, bank->start + bank->size - 1,
> - bank->start + newsize - 1);
> + printk(KERN_NOTICE "Truncating RAM at %.8llx-%.8llx "
> + "to -%.8llx (vmalloc region overlap).\n",
> + (unsigned long long)bank->start,
> + (unsigned long long)bank->start + bank->size - 1,
> + (unsigned long long)bank->start + newsize - 1);
> bank->size = newsize;
> }
> #endif
Would you like me to submit an additional patch or are you happy merging
this diff in with my ack?
Cheers,
Will
^ permalink raw reply
* [PATCH V4 3/4] ARM: Xilinx: base header files and assembly macros
From: John Linn @ 2011-02-21 14:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102210936.42098.arnd@arndb.de>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Monday, February 21, 2011 1:37 AM
> To: John Linn
> Cc: linux-arm-kernel at lists.infradead.org;
linux-kernel at vger.kernel.org;
> linux at arm.linux.org.uk; catalin.marinas at arm.com; glikely at secretlab.ca;
> jamie at jamieiles.com
> Subject: Re: [PATCH V4 3/4] ARM: Xilinx: base header files and
assembly
> macros
>
> On Monday 21 February 2011, John Linn wrote:
> > > > diff --git a/arch/arm/mach-xilinx/include/mach/timex.h
> > > b/arch/arm/mach-xilinx/include/mach/timex.h
> > > > new file mode 100644
> > > > index 0000000..4ebc0a6
> > > > --- /dev/null
> > > > +++ b/arch/arm/mach-xilinx/include/mach/timex.h
> > > > +#ifndef __MACH_TIMEX_H__
> > > > +#define __MACH_TIMEX_H__
> > > > +
> > > > +#define PERIPHERAL_CLOCK_RATE 2500000
> > > > +
> > > > +#define CLOCK_TICK_RATE (PERIPHERAL_CLOCK_RATE / 32)
> > > > +
> > > > +#endif
> > >
> > > I thought we were at the point where CLOCK_TICK_RATE is no longer
> > used.
> >
> > The timer code in these patches is using it, no other comments on it
> so
> > far.
> >
> > > Did the patches not make it in yet?
> > >
> >
> > I haven't heard they made them in yet, just waiting and hoping for
an
> > ack.
>
> I meant the patches removing CLOCK_TICK_RATE from common code, not
your
> patches, sorry for being vague.
Ahh... understand. No problem, wishful thinking on my part :)
>
> It would be better if you could avoid introducing new uses of
> CLOCK_TICK_RATE, because that will have to be removed before we can
> move to a real multi-platform kernel. For instance, you can put
> PERIPHERAL_CLOCK_RATE in a hardware specific header and put a bogus
> definition for CLOCK_TICK_RATE into timex.h
Hi Arnd,
I can remove the use of it from my timer code, but I still see
CLOCK_TICK_RATE
being used in linux/jiffies.h.
I tried removing it and got build errors. Am I missing something there?
Thanks,
John
>
> Arnd
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Machine ID question
From: John Linn @ 2011-02-21 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110220130420.GD14495@n2100.arm.linux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Sunday, February 20, 2011 6:04 AM
> To: Alexander Stein
> Cc: linux-arm-kernel at lists.infradead.org; John Linn; Uwe Kleine-K?nig
> Subject: Re: Machine ID question
>
> On Mon, Feb 14, 2011 at 04:12:16PM +0100, Alexander Stein wrote:
> > On Thursday 10 February 2011, 09:29:15 Uwe Kleine-K?nig wrote:
> > > On Wed, Feb 09, 2011 at 02:23:07PM -0700, John Linn wrote:
> > > > I used the form to create a new machine ID for the new Xilinx
> platform
> > > > in anticipation of
> > > > the code making it into the mainline sometime in the future.
> > > >
> > > > The proposed patches are using ARCH_XILINX in the Kconfig.
> > >
> > > You should use MACH_XILINX in the patches. There are some ARCH_...
> in
> > > the machine db, but I think nowadays you cannot (and should not)
> create
> > > them there.
> >
> > Uhm, the last entry in the db was created today (14th Feb). Is there
> a reason
> > why there no new entries should be created?
>
> huh?
>
> The machine registry hands out MACH_foo identifiers. It used to hand
> them out as ARCH_foo identifiers, but we decided that was misleading -
> it's dealing with machines, not architectures. So a MACH_ prefix is
> more correct than an ARCH_ prefix.
Thanks Russell, yea I figured that out after I had sent this out.
Appreciate the help,
John
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* [PATCH V4 3/4] ARM: Xilinx: base header files and assembly macros
From: Arnd Bergmann @ 2011-02-21 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c3cdf33d-2163-4417-bc64-7637f5c211e0@VA3EHSMHS021.ehs.local>
On Monday 21 February 2011, John Linn wrote:
> > It would be better if you could avoid introducing new uses of
> > CLOCK_TICK_RATE, because that will have to be removed before we can
> > move to a real multi-platform kernel. For instance, you can put
> > PERIPHERAL_CLOCK_RATE in a hardware specific header and put a bogus
> > definition for CLOCK_TICK_RATE into timex.h
>
> Hi Arnd,
>
> I can remove the use of it from my timer code, but I still see
> CLOCK_TICK_RATE
> being used in linux/jiffies.h.
>
> I tried removing it and got build errors. Am I missing something there?
>
You still need to have some definition for CLOCK_TICK_RATE to make
the jiffies code compile, but the actual value no longer matters.
Traditionally, this was the i386-style PIT timer frequency of 11.93 MHz
for some things and the actual timer frequency for other things.
The timer code tries to correct the jiffies value based on difference
between the intended HZ frequency (100, 250 or 1000) and the actual
on (something very close to that, but not exact).
You can e.g. set it to (100 * HZ) to make something up that won't
hurt in that calculation.
Arnd
^ permalink raw reply
* [PATCH v4 15/19] ARM: LPAE: use phys_addr_t instead of unsigned long for physical addresses
From: Russell King - ARM Linux @ 2011-02-21 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298299008.19814.20.camel@e102144-lin.cambridge.arm.com>
On Mon, Feb 21, 2011 at 02:36:47PM +0000, Will Deacon wrote:
> Would you like me to submit an additional patch or are you happy merging
> this diff in with my ack?
The latter - I've already merged it and if you give an ack I'll add that.
Thanks.
^ permalink raw reply
* [PATCH v4 15/19] ARM: LPAE: use phys_addr_t instead of unsigned long for physical addresses
From: Will Deacon @ 2011-02-21 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110221145818.GQ14495@n2100.arm.linux.org.uk>
On Mon, 2011-02-21 at 14:58 +0000, Russell King - ARM Linux wrote:
> On Mon, Feb 21, 2011 at 02:36:47PM +0000, Will Deacon wrote:
> > Would you like me to submit an additional patch or are you happy merging
> > this diff in with my ack?
>
> The latter - I've already merged it and if you give an ack I'll add that.
>
Acked-by: Will Deacon <will.deacon@arm.com>
Thanks,
Will
^ permalink raw reply
* Machine ID question
From: Alexander Stein @ 2011-02-21 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110220130420.GD14495@n2100.arm.linux.org.uk>
On Sunday 20 February 2011, 14:04:20 Russell King - ARM Linux wrote:
> On Mon, Feb 14, 2011 at 04:12:16PM +0100, Alexander Stein wrote:
> > On Thursday 10 February 2011, 09:29:15 Uwe Kleine-K?nig wrote:
> > > On Wed, Feb 09, 2011 at 02:23:07PM -0700, John Linn wrote:
> > > > I used the form to create a new machine ID for the new Xilinx
> > > > platform in anticipation of
> > > > the code making it into the mainline sometime in the future.
> > > >
> > > > The proposed patches are using ARCH_XILINX in the Kconfig.
> > >
> > > You should use MACH_XILINX in the patches. There are some ARCH_... in
> > > the machine db, but I think nowadays you cannot (and should not) create
> > > them there.
> >
> > Uhm, the last entry in the db was created today (14th Feb). Is there a
> > reason why there no new entries should be created?
>
> huh?
>
> The machine registry hands out MACH_foo identifiers. It used to hand
> them out as ARCH_foo identifiers, but we decided that was misleading -
> it's dealing with machines, not architectures. So a MACH_ prefix is
> more correct than an ARCH_ prefix.
Ah, without that knowledge Uwe's mail was a bit misleading.
Thanks for clarification.
Alexander
^ permalink raw reply
* [PATCH V4 3/4] ARM: Xilinx: base header files and assembly macros
From: John Linn @ 2011-02-21 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102211548.36296.arnd@arndb.de>
> -----Original Message-----
> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm-
> kernel-bounces at lists.infradead.org] On Behalf Of Arnd Bergmann
> Sent: Monday, February 21, 2011 7:49 AM
> To: John Linn
> Cc: linux at arm.linux.org.uk; catalin.marinas at arm.com;
> glikely at secretlab.ca; linux-kernel at vger.kernel.org;
> jamie at jamieiles.com; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH V4 3/4] ARM: Xilinx: base header files and
assembly
> macros
>
> On Monday 21 February 2011, John Linn wrote:
> > > It would be better if you could avoid introducing new uses of
> > > CLOCK_TICK_RATE, because that will have to be removed before we
can
> > > move to a real multi-platform kernel. For instance, you can put
> > > PERIPHERAL_CLOCK_RATE in a hardware specific header and put a
bogus
> > > definition for CLOCK_TICK_RATE into timex.h
> >
> > Hi Arnd,
> >
> > I can remove the use of it from my timer code, but I still see
> > CLOCK_TICK_RATE
> > being used in linux/jiffies.h.
> >
> > I tried removing it and got build errors. Am I missing something
> there?
> >
>
> You still need to have some definition for CLOCK_TICK_RATE to make
> the jiffies code compile, but the actual value no longer matters.
I see. Now that I re-read your last response I get that from it.
>
> Traditionally, this was the i386-style PIT timer frequency of 11.93
MHz
> for some things and the actual timer frequency for other things.
> The timer code tries to correct the jiffies value based on difference
> between the intended HZ frequency (100, 250 or 1000) and the actual
> on (something very close to that, but not exact).
>
> You can e.g. set it to (100 * HZ) to make something up that won't
> hurt in that calculation.
>
Gotcha. I now understand to stay away from using CLOCK_TICK_RATE.
Sounds like it's worth a comment in mach/timex.h that says it's not
really used as it seems a bit misleading for others.
Thanks,
John
> Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* [PATCH V4 3/4] ARM: Xilinx: base header files and assembly macros
From: Russell King - ARM Linux @ 2011-02-21 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102211548.36296.arnd@arndb.de>
On Mon, Feb 21, 2011 at 03:48:36PM +0100, Arnd Bergmann wrote:
> On Monday 21 February 2011, John Linn wrote:
> > > It would be better if you could avoid introducing new uses of
> > > CLOCK_TICK_RATE, because that will have to be removed before we can
> > > move to a real multi-platform kernel. For instance, you can put
> > > PERIPHERAL_CLOCK_RATE in a hardware specific header and put a bogus
> > > definition for CLOCK_TICK_RATE into timex.h
> >
> > Hi Arnd,
> >
> > I can remove the use of it from my timer code, but I still see
> > CLOCK_TICK_RATE
> > being used in linux/jiffies.h.
> >
> > I tried removing it and got build errors. Am I missing something there?
> >
>
> You still need to have some definition for CLOCK_TICK_RATE to make
> the jiffies code compile, but the actual value no longer matters.
This is what I said a while back:
| If you switch to clocksource/clockevents, then I think CLOCK_TICK_RATE
| is irrelevant as time advances according to the interval measured by
| the previous and current clocksource read, rather than 1/HZ intervals.
|
| However, I'm never happy to say "just set CLOCK_TICK_RATE to some random
| value that's a multiple of HZ" because I can't convince myself that these
| don't have any effect when using clocksources. The list of symbols which
| depend on CLOCK_TICK_RATE are:
|
| ACTHZ
| LATCH
| TICK_NSEC
| TICK_USEC_TO_NSEC
| LOW_RES_NSEC
| MONOTONIC_RES_NSEC
| NSEC_PER_JIFFY
| KTIME_LOW_RES
|
| and if you grep for those outside of arch/, you find them being used in
| a fair amount of code under kernel/, as well as the odd driver here and
| there.
Eg, LOW_RES_NSEC is exported to userspace via the posix clocks interface.
NSEC_PER_SEC and TICK_NSEC are used for cmos clock updates, so probably
don't matter too much there. TICK_NSEC is also used by the scheduler,
time conversions (timespec/timeval to/from jiffies) and profiling code.
NSEC_PER_JIFFY is used by the jiffy clocksource code, which only matters
if you don't have your own clocksource.
So, I feel very uneasy about saying that CLOCK_TICK_RATE doesn't matter
anymore given all the places which reference something that's derived
from it.
Here's the result of grepping for the above symbols:
drivers/oprofile/timer_int.c: hrtimer_forward_now(hrtimer, ns_to_ktime(TICK_NSEC));
drivers/oprofile/timer_int.c: hrtimer_start(hrtimer, ns_to_ktime(TICK_NSEC),
include/linux/acct.h:#if (TICK_NSEC % (NSEC_PER_SEC / AHZ)) == 0
include/linux/acct.h: u64 tmp = (u64)x * TICK_NSEC;
include/linux/hrtimer.h:# define MONOTONIC_RES_NSEC HIGH_RES_NSEC
include/linux/hrtimer.h:# define MONOTONIC_RES_NSEC LOW_RES_NSEC
include/linux/hrtimer.h:# define KTIME_MONOTONIC_RES KTIME_LOW_RES
include/linux/jiffies.h:/* TICK_NSEC is the time between ticks in nsec assuming
real ACTHZ */
include/linux/jiffies.h:#define TICK_NSEC (SH_DIV (1000000UL * 1000, ACTHZ, 8))
include/linux/jiffies.h:/* TICK_USEC_TO_NSEC is the time between ticks in nsec assuming real ACTHZ and */
include/linux/jiffies.h:#define TICK_USEC_TO_NSEC(TUSEC) (SH_DIV (TUSEC * USER_HZ * 1000, ACTHZ, 8))
include/linux/jiffies.h: * is: TICK_NSEC (which is defined in timex.h). This
include/linux/jiffies.h:#if !((((NSEC_PER_SEC << 2) / TICK_NSEC) << (SEC_JIFFIE_SC - 2)) & 0x80000000)
include/linux/jiffies.h: TICK_NSEC -1) / (u64)TICK_NSEC))
include/linux/jiffies.h: TICK_NSEC -1) /
(u64)TICK_NSEC))
include/linux/jiffies.h: TICK_NSEC -1) /
(u64)TICK_NSEC))
include/linux/jiffies.h: (long)((u64)((u64)MAX_JIFFY_OFFSET * TICK_NSEC)
/ NSEC_PER_SEC)
include/linux/jiffies.h: (SH_DIV((MAX_JIFFY_OFFSET >> SEC_JIFFIE_SC) * TICK_NSEC, NSEC_PER_SEC, 1) - 1)
include/linux/ktime.h:#define LOW_RES_NSEC TICK_NSEC
include/linux/ktime.h:#define KTIME_LOW_RES (ktime_t){ .tv64 = LOW_RES_NSEC }
kernel/hrtimer.c: .resolution = KTIME_LOW_RES,
kernel/hrtimer.c: .resolution = KTIME_LOW_RES,
kernel/perf_event.c: u64 interval = (u64)cpuctx->jiffies_interval * TICK_NSEC;
kernel/perf_event.c: if (delta > 0 && delta < 2*TICK_NSEC)
kernel/posix-timers.c: *tp = ktime_to_timespec(KTIME_LOW_RES);
kernel/sched.c: * scheduler tick (TICK_NSEC). With tickless idle this will not be called
kernel/sched_clock.c: * scd->tick_gtod + TICK_NSEC);
kernel/sched_clock.c: max_clock = wrap_max(old_clock, scd->tick_gtod + TICK_NSEC);
kernel/time.c: * The TICK_NSEC - 1 rounds up the value to the next resolution.
Note
kernel/time.c: * nsec -= nsec % TICK_NSEC; is NOT a correct resolution rounding.kernel/time.c: long nsec = value->tv_nsec + TICK_NSEC - 1;
kernel/time.c: value->tv_sec = div_u64_rem((u64)jiffies * TICK_NSEC,
kernel/time.c: value->tv_sec = div_u64_rem((u64)jiffies * TICK_NSEC,
kernel/time.c:#if (TICK_NSEC % (NSEC_PER_SEC / USER_HZ)) == 0
kernel/time.c: return div_u64((u64)x * TICK_NSEC, NSEC_PER_SEC / USER_HZ);
kernel/time.c:#if (TICK_NSEC % (NSEC_PER_SEC / USER_HZ)) == 0
kernel/time.c: x = div_u64(x * TICK_NSEC, (NSEC_PER_SEC / USER_HZ));
kernel/time/jiffies.c:#define NSEC_PER_JIFFY ((u32)((((u64)NSEC_PER_SEC)<<8)/ACTHZ))
kernel/time/jiffies.c:/* Since jiffies uses a simple NSEC_PER_JIFFY multiplier
kernel/time/jiffies.c: * larger can result in overflows. NSEC_PER_JIFFY grows askernel/time/jiffies.c: .mult = NSEC_PER_JIFFY << JIFFIES_SHIFT, /* details above */
kernel/time/ntp.c: next.tv_nsec = (NSEC_PER_SEC / 2) - now.tv_nsec - (TICK_NSEC / 2);
^ permalink raw reply
* [PATCH 0/5] Migrate GIC to fasteoi flow control
From: Will Deacon @ 2011-02-21 15:28 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
The following patchset updates the GIC code to use fasteoi as the
method of flow control. This is important because it removes accesses
to the distributor (which are expensive in a virtualised system) from
the critical interrupt path.
Changing the GIC irq_chip structure means updating all of the chained
IRQ handlers which use the GIC as their primary controller. I believe
I've done that in the patches below, but I would appreciate feedback
and/or acked-bys from the platform people to confirm that I've got it
right. It's not easy code to follow and it looks like some of the
chained handlers are designed to work with multiple primary controllers.
Finally, if you think I've missed your platform then please shout!
Thanks,
Will
Will Deacon (5):
ARM: gic: use handle_fasteoi_irq for SPIs
ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip
ARM: tegra: update GPIO chained IRQ handler to use EOI in parent chip
ARM: s5pv310: update IRQ combiner to use EOI in parent chip
ARM: msm: update GPIO chained IRQ handler to use EOI in parent chip
arch/arm/common/gic.c | 23 +++++++++--------------
arch/arm/mach-msm/gpio-v2.c | 2 +-
arch/arm/mach-s5pv310/irq-combiner.c | 7 ++-----
arch/arm/mach-tegra/gpio.c | 17 +----------------
arch/arm/plat-omap/gpio.c | 5 ++++-
5 files changed, 17 insertions(+), 37 deletions(-)
^ permalink raw reply
* [PATCH 1/5] ARM: gic: use handle_fasteoi_irq for SPIs
From: Will Deacon @ 2011-02-21 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298302096-21275-1-git-send-email-will.deacon@arm.com>
Currently, the gic uses handle_level_irq for handling SPIs (Shared
Peripheral Interrupts), requiring active interrupts to be masked at
the distributor level during IRQ handling.
On a virtualised system, only the CPU interfaces are virtualised in
hardware. Accesses to the distributor must be trapped by the hypervisor,
adding latency to the critical interrupt path in Linux.
This patch modifies the GIC code to use handle_fasteoi_irq for handling
interrupts, which only requires us to signal EOI to the CPU interface
when handling is complete. Cascaded IRQ handling is also updated so that
EOI is signalled after handling.
Note that commit 846afbd1 ("GIC: Dont disable INT in ack callback") broke
cascading interrupts by forgetting to add IRQ masking. This is no longer
an issue because the unmask call is now unnecessary.
Tested on Versatile Express and Realview EB (1176 w/ cascaded GICs).
Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/common/gic.c | 23 +++++++++--------------
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 2243772..9def30b 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -71,13 +71,6 @@ static inline unsigned int gic_irq(struct irq_data *d)
/*
* Routines to acknowledge, disable and enable interrupts
*/
-static void gic_ack_irq(struct irq_data *d)
-{
- spin_lock(&irq_controller_lock);
- writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
- spin_unlock(&irq_controller_lock);
-}
-
static void gic_mask_irq(struct irq_data *d)
{
u32 mask = 1 << (d->irq % 32);
@@ -96,6 +89,11 @@ static void gic_unmask_irq(struct irq_data *d)
spin_unlock(&irq_controller_lock);
}
+static void gic_eoi_irq(struct irq_data *d)
+{
+ writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
+}
+
static int gic_set_type(struct irq_data *d, unsigned int type)
{
void __iomem *base = gic_dist_base(d);
@@ -174,9 +172,6 @@ static void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
unsigned int cascade_irq, gic_irq;
unsigned long status;
- /* primary controller ack'ing */
- chip->irq_ack(&desc->irq_data);
-
spin_lock(&irq_controller_lock);
status = readl(chip_data->cpu_base + GIC_CPU_INTACK);
spin_unlock(&irq_controller_lock);
@@ -192,15 +187,15 @@ static void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
generic_handle_irq(cascade_irq);
out:
- /* primary controller unmasking */
- chip->irq_unmask(&desc->irq_data);
+ /* primary controller EOI */
+ chip->irq_eoi(&desc->irq_data);
}
static struct irq_chip gic_chip = {
.name = "GIC",
- .irq_ack = gic_ack_irq,
.irq_mask = gic_mask_irq,
.irq_unmask = gic_unmask_irq,
+ .irq_eoi = gic_eoi_irq,
.irq_set_type = gic_set_type,
#ifdef CONFIG_SMP
.irq_set_affinity = gic_set_cpu,
@@ -275,7 +270,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic,
for (i = irq_start; i < irq_limit; i++) {
set_irq_chip(i, &gic_chip);
set_irq_chip_data(i, gic);
- set_irq_handler(i, handle_level_irq);
+ set_irq_handler(i, handle_fasteoi_irq);
set_irq_flags(i, IRQF_VALID | IRQF_PROBE);
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/5] ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip
From: Will Deacon @ 2011-02-21 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298302096-21275-1-git-send-email-will.deacon@arm.com>
On OMAP4, gpio_irq_handler can be chained to a physical interrupt using
the GIC as the primary IRQ chip. Now that the GIC uses the fasteoi flow
model, the chained handler must invoke ->irq_eoi once handling is
complete.
This patch adds a conditional call to ->irq_eoi in the GPIO IRQ handler
for OMAP platforms. For OMAP implementations using other primary
interrupt controllers, the ->irq_ack call remains and is also made
conditional on the support offered by the controller.
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Colin Cross <ccross@google.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/plat-omap/gpio.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 971d186..1d2d1c7 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1144,7 +1144,8 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
u32 retrigger = 0;
int unmasked = 0;
- desc->irq_data.chip->irq_ack(&desc->irq_data);
+ if (desc->irq_data.chip->irq_ack)
+ desc->irq_data.chip->irq_ack(&desc->irq_data);
bank = get_irq_data(irq);
#ifdef CONFIG_ARCH_OMAP1
@@ -1238,6 +1239,8 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
exit:
if (!unmasked)
desc->irq_data.chip->irq_unmask(&desc->irq_data);
+ if (desc->irq_data.chip->irq_eoi)
+ desc->irq_data.chip->irq_eoi(&desc->irq_data);
}
static void gpio_irq_shutdown(struct irq_data *d)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/5] ARM: tegra: update GPIO chained IRQ handler to use EOI in parent chip
From: Will Deacon @ 2011-02-21 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298302096-21275-1-git-send-email-will.deacon@arm.com>
The chained GPIO IRQ handler on Tegra calls ->irq_ack on the parent
chip prior to handling the interrupt.
This patch updates the code to use ->irq_eoi now that the GIC has moved
to using the fasteoi flow model.
Cc: Colin Cross <ccross@google.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/mach-tegra/gpio.c | 17 +----------------
1 files changed, 1 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-tegra/gpio.c b/arch/arm/mach-tegra/gpio.c
index ad80488..5019b01 100644
--- a/arch/arm/mach-tegra/gpio.c
+++ b/arch/arm/mach-tegra/gpio.c
@@ -219,9 +219,6 @@ static void tegra_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
struct tegra_gpio_bank *bank;
int port;
int pin;
- int unmasked = 0;
-
- desc->irq_data.chip->irq_ack(&desc->irq_data);
bank = get_irq_data(irq);
@@ -233,23 +230,11 @@ static void tegra_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
for_each_set_bit(pin, &sta, 8) {
__raw_writel(1 << pin, GPIO_INT_CLR(gpio));
-
- /* if gpio is edge triggered, clear condition
- * before executing the hander so that we don't
- * miss edges
- */
- if (lvl & (0x100 << pin)) {
- unmasked = 1;
- desc->irq_data.chip->irq_unmask(&desc->irq_data);
- }
-
generic_handle_irq(gpio_to_irq(gpio + pin));
}
}
- if (!unmasked)
- desc->irq_data.chip->irq_unmask(&desc->irq_data);
-
+ desc->irq_data.chip->irq_eoi(&desc->irq_data);
}
#ifdef CONFIG_PM
--
1.7.0.4
^ permalink raw reply related
* [PATCH 4/5] ARM: s5pv310: update IRQ combiner to use EOI in parent chip
From: Will Deacon @ 2011-02-21 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298302096-21275-1-git-send-email-will.deacon@arm.com>
The IRQ combiner code invokes the ->irq_{un}mask routines of the parent
chip.
This patch updates the cascaded handler to use EOI now that the GIC has
moved to using the fasteoi flow model.
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/mach-s5pv310/irq-combiner.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-s5pv310/irq-combiner.c b/arch/arm/mach-s5pv310/irq-combiner.c
index 1ea4a9e..24d5604 100644
--- a/arch/arm/mach-s5pv310/irq-combiner.c
+++ b/arch/arm/mach-s5pv310/irq-combiner.c
@@ -59,9 +59,6 @@ static void combiner_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
unsigned int cascade_irq, combiner_irq;
unsigned long status;
- /* primary controller ack'ing */
- chip->irq_ack(&desc->irq_data);
-
spin_lock(&irq_controller_lock);
status = __raw_readl(chip_data->base + COMBINER_INT_STATUS);
spin_unlock(&irq_controller_lock);
@@ -79,8 +76,8 @@ static void combiner_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
generic_handle_irq(cascade_irq);
out:
- /* primary controller unmasking */
- chip->irq_unmask(&desc->irq_data);
+ /* primary controller EOI */
+ chip->irq_eoi(&desc->irq_data);
}
static struct irq_chip combiner_chip = {
--
1.7.0.4
^ permalink raw reply related
* [PATCH 5/5] ARM: msm: update GPIO chained IRQ handler to use EOI in parent chip
From: Will Deacon @ 2011-02-21 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298302096-21275-1-git-send-email-will.deacon@arm.com>
The chained GPIO IRQ handler on MSM8x60 calls ->ack on the parent chip
after handling the interrupt.
This patch updates the code to use ->irq_eoi now that the GIC has moved
to using the fasteoi flow model.
Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/mach-msm/gpio-v2.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-msm/gpio-v2.c b/arch/arm/mach-msm/gpio-v2.c
index 0de19ec..04fb411 100644
--- a/arch/arm/mach-msm/gpio-v2.c
+++ b/arch/arm/mach-msm/gpio-v2.c
@@ -318,7 +318,7 @@ static void msm_summary_irq_handler(unsigned int irq, struct irq_desc *desc)
generic_handle_irq(msm_gpio_to_irq(&msm_gpio.gpio_chip,
i));
}
- desc->chip->ack(irq);
+ desc->chip->irq_eoi(irq);
}
static int msm_gpio_irq_set_wake(unsigned int irq, unsigned int on)
--
1.7.0.4
^ permalink raw reply related
* dma_declare_coherent_memory() again.
From: Guennadi Liakhovetski @ 2011-02-21 15:37 UTC (permalink / raw)
To: linux-arm-kernel
Hi All
AFAIU, dma_declare_coherent_memory() is still present on the following
platforms:
arch/arm/mach-mx3/mach-pcm037.c
arch/arm/mach-mx3/mach-mx31moboard.c
arch/arm/mach-shmobile/board-ap4evb.c
arch/arm/mach-shmobile/board-mackerel.c (latter 2 via
drivers/media/video/sh_mobile_ceu_camera.c)
and there are no pending patches to fix them for 2.6.38, is this right? If
there are no realistic plans for proper memory reservation on ARM in
2.6.38, shall I just submit patches to disable those calls on the above
platforms and hope, that the user manages to get RAM without boot-time
reservation? Or is a definite failure preferred?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH] arm: imx: Zero entire imxdma structure
From: Sascha Hauer @ 2011-02-21 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110220230458.GA21198@n2100.arm.linux.org.uk>
On Sun, Feb 20, 2011 at 11:04:58PM +0000, Russell King - ARM Linux wrote:
> On Sun, Feb 20, 2011 at 10:59:24PM +0000, Ilia Mirkin wrote:
> > On Sun, Feb 20, 2011 at 10:10 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
> > > The semantic match that finds the problem:
> > > // <smpl>
> > > @@
> > > type T;
> > > identifier x;
> > > @@
> > >
> > > T *x;
> > > ...
> > > * memset(x, ..., ... * sizeof(x) * ...);
> > > // </smpl>
> > >
> > > Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
> > >
> > > ---
> > > ?arch/arm/mach-imx/dma-v1.c | ? ?2 +-
> > > ?1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > Untested, lack of tool chain and hardware. But there's definitely something
> > > odd going on here, and this seemed like the most logical fix.
> >
> > Doing some quick digging (as I've been discovering that a few of the
> > other patches I was planning on sending have already been sent out in
> > the past), I noticed that this same patch was already sent on Dec 9,
> > 2009 by Julia Lawall[1] (back when it was plat-mxc/dma-mx1-mx2.c), and
> > then again by Vasiliy Kulikov[2] on Oct 10, 2010.
> >
> > On each occasion, the response was positive, but patch has yet to make
> > it upstream. Weird.
>
> Sascha, are you going to take this patch?
Yes.
Sascha
--
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 2/5] ARM: imx51/53: add sdhc3/4 clock
From: Sascha Hauer @ 2011-02-21 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298282095-2279-2-git-send-email-richard.zhao@freescale.com>
On Mon, Feb 21, 2011 at 05:54:52PM +0800, Richard Zhao wrote:
> Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
>
> diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c b/arch/arm/mach-mx5/clock-mx51-mx53.c
> index 8164b1d..8ac61d5 100644
> --- a/arch/arm/mach-mx5/clock-mx51-mx53.c
> +++ b/arch/arm/mach-mx5/clock-mx51-mx53.c
> @@ -42,6 +42,7 @@ static struct clk usboh3_clk;
> static struct clk emi_fast_clk;
> static struct clk ipu_clk;
> static struct clk mipi_hsc1_clk;
> +static struct clk esdhc1_clk;
>
> #define MAX_DPLL_WAIT_TRIES 1000 /* 1000 * udelay(1) = 1ms */
>
> @@ -1147,6 +1148,34 @@ CLK_GET_RATE(esdhc2, 1, ESDHC2_MSHC2)
> CLK_SET_PARENT(esdhc2, 1, ESDHC2_MSHC2)
> CLK_SET_RATE(esdhc2, 1, ESDHC2_MSHC2)
>
> +static int clk_esdhc3_set_parent(struct clk *clk, struct clk *parent)
> +{
> + u32 reg;
> +
> + reg = __raw_readl(MXC_CCM_CSCMR1);
> + if (parent == &esdhc1_clk)
> + reg &= ~MXC_CCM_CSCMR1_ESDHC3_CLK_SEL;
> + else
> + reg |= MXC_CCM_CSCMR1_ESDHC3_CLK_SEL;
parent != &esdhc1_clk doesn't mean parent is a valid parent for this
clock. Please do the parameter checking properly.
> + __raw_writel(reg, MXC_CCM_CSCMR1);
> +
> + return 0;
> +}
> +
> +static int clk_esdhc4_set_parent(struct clk *clk, struct clk *parent)
> +{
> + u32 reg;
> +
> + reg = __raw_readl(MXC_CCM_CSCMR1);
> + if (parent == &esdhc1_clk)
> + reg &= ~MXC_CCM_CSCMR1_ESDHC4_CLK_SEL;
> + else
> + reg |= MXC_CCM_CSCMR1_ESDHC4_CLK_SEL;
ditto.
> + __raw_writel(reg, MXC_CCM_CSCMR1);
> +
> + return 0;
> +}
> +
> #define DEFINE_CLOCK_FULL(name, i, er, es, gr, sr, e, d, p, s) \
> static struct clk name = { \
> .id = i, \
> @@ -1253,6 +1282,32 @@ DEFINE_CLOCK_FULL(esdhc2_ipg_clk, 1, MXC_CCM_CCGR3, MXC_CCM_CCGRx_CG2_OFFSET,
> NULL, NULL, _clk_max_enable, _clk_max_disable, &ipg_clk, NULL);
> DEFINE_CLOCK_MAX(esdhc2_clk, 1, MXC_CCM_CCGR3, MXC_CCM_CCGRx_CG3_OFFSET,
> clk_esdhc2, &pll2_sw_clk, &esdhc2_ipg_clk);
> +DEFINE_CLOCK_FULL(esdhc3_ipg_clk, 2, MXC_CCM_CCGR3, MXC_CCM_CCGRx_CG4_OFFSET,
> + NULL, NULL, _clk_max_enable, _clk_max_disable, &ipg_clk, NULL);
> +DEFINE_CLOCK_FULL(esdhc4_ipg_clk, 3, MXC_CCM_CCGR3, MXC_CCM_CCGRx_CG6_OFFSET,
> + NULL, NULL, _clk_max_enable, _clk_max_disable, &ipg_clk, NULL);
> +
> +static struct clk esdhc3_clk = {
> + .id = 2,
> + .parent = &esdhc1_clk,
> + .set_parent = clk_esdhc3_set_parent,
> + .enable_reg = MXC_CCM_CCGR3,
> + .enable_shift = MXC_CCM_CCGRx_CG5_OFFSET,
> + .enable = _clk_max_enable,
> + .disable = _clk_max_disable,
> + .secondary = &esdhc3_ipg_clk,
> +};
> +
> +static struct clk esdhc4_clk = {
> + .id = 3,
> + .parent = &esdhc1_clk,
> + .set_parent = clk_esdhc4_set_parent,
> + .enable_reg = MXC_CCM_CCGR3,
> + .enable_shift = MXC_CCM_CCGRx_CG7_OFFSET,
> + .enable = _clk_max_enable,
> + .disable = _clk_max_disable,
> + .secondary = &esdhc4_ipg_clk,
> +};
>
> DEFINE_CLOCK(mipi_esc_clk, 0, MXC_CCM_CCGR4, MXC_CCM_CCGRx_CG5_OFFSET, NULL, NULL, NULL, &pll2_sw_clk);
> DEFINE_CLOCK(mipi_hsc2_clk, 0, MXC_CCM_CCGR4, MXC_CCM_CCGRx_CG4_OFFSET, NULL, NULL, &mipi_esc_clk, &pll2_sw_clk);
> @@ -1312,6 +1367,8 @@ static struct clk_lookup mx51_lookups[] = {
> _REGISTER_CLOCK("imx51-cspi.0", NULL, cspi_clk)
> _REGISTER_CLOCK("sdhci-esdhc-imx.0", NULL, esdhc1_clk)
> _REGISTER_CLOCK("sdhci-esdhc-imx.1", NULL, esdhc2_clk)
> + _REGISTER_CLOCK("sdhci-esdhc-imx.2", NULL, esdhc3_clk)
> + _REGISTER_CLOCK("sdhci-esdhc-imx.3", NULL, esdhc4_clk)
> _REGISTER_CLOCK(NULL, "cpu_clk", cpu_clk)
> _REGISTER_CLOCK(NULL, "iim_clk", iim_clk)
> _REGISTER_CLOCK("imx2-wdt.0", NULL, dummy_clk)
> @@ -1333,6 +1390,8 @@ static struct clk_lookup mx53_lookups[] = {
> _REGISTER_CLOCK("imx-i2c.1", NULL, i2c2_clk)
> _REGISTER_CLOCK("sdhci-esdhc-imx.0", NULL, esdhc1_clk)
> _REGISTER_CLOCK("sdhci-esdhc-imx.1", NULL, esdhc2_clk)
> + _REGISTER_CLOCK("sdhci-esdhc-imx.2", NULL, esdhc3_clk)
> + _REGISTER_CLOCK("sdhci-esdhc-imx.3", NULL, esdhc4_clk)
> _REGISTER_CLOCK("imx53-ecspi.0", NULL, ecspi1_clk)
> _REGISTER_CLOCK("imx53-ecspi.1", NULL, ecspi2_clk)
> _REGISTER_CLOCK("imx53-cspi.0", NULL, cspi_clk)
> @@ -1412,6 +1471,14 @@ int __init mx53_clocks_init(unsigned long ckil, unsigned long osc,
> ckih2_reference = ckih2;
> oscillator_reference = osc;
>
> + esdhc2_clk.get_rate = NULL;
> + esdhc2_clk.set_rate = NULL;
> + esdhc2_clk.set_parent = clk_esdhc3_set_parent;
> + esdhc2_clk.parent = &esdhc1_clk;
> + esdhc3_clk.get_rate = clk_esdhc2_get_rate;
> + esdhc3_clk.set_rate = clk_esdhc2_set_rate;
> + esdhc3_clk.set_parent = clk_esdhc2_set_parent;
> +
This is just too confusing and will be hard to cleanup when we get
clkops for i.MX. Please make SoC specific clocks from this and do not
reassign the function pointers.
Sascha
--
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
* OMAP4: IRQ line of CortexA9 performance monitor
From: Ming Lei @ 2011-02-21 16:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
^ permalink raw reply
* [PATCH v2 01/13] mfd: pruss mfd driver.
From: Samuel Ortiz @ 2011-02-21 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297435892-28278-2-git-send-email-subhasish@mistralsolutions.com>
Hi Subhasish,
On Fri, Feb 11, 2011 at 08:21:20PM +0530, Subhasish Ghosh wrote:
> This patch adds the pruss MFD driver and associated include files.
A more detailed changelog would be better. What is this device, why is it an
MFD and what are its potential subdevices ?
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index fd01836..6c437df 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -81,6 +81,16 @@ config MFD_DM355EVM_MSP
> boards. MSP430 firmware manages resets and power sequencing,
> inputs from buttons and the IR remote, LEDs, an RTC, and more.
>
> +config MFD_DA8XX_PRUSS
> + tristate "Texas Instruments DA8XX PRUSS support"
> + depends on ARCH_DAVINCI && ARCH_DAVINCI_DA850
Why are we depending on those ?
> + select MFD_CORE
> + help
> + This driver provides support api's for the programmable
> + realtime unit (PRU) present on TI's da8xx processors. It
> + provides basic read, write, config, enable, disable
> + routines to facilitate devices emulated on it.
Please fix your identation here.
> --- /dev/null
> +++ b/drivers/mfd/da8xx_pru.c
> @@ -0,0 +1,446 @@
> +/*
> + * Copyright (C) 2010 Texas Instruments Incorporated
s/2010/2011/ ?
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any kind,
> + * whether express or implied; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/types.h>
> +#include <linux/module.h>
> +#include <linux/bitops.h>
> +#include <linux/interrupt.h>
> +#include <linux/errno.h>
> +#include <linux/platform_device.h>
> +#include <linux/clk.h>
> +#include <linux/mfd/pruss/da8xx_prucore.h>
> +#include <linux/mfd/pruss/da8xx_pru.h>
> +#include <linux/mfd/core.h>
> +#include <linux/io.h>
> +#include <mach/da8xx.h>
Is that include needed ?
> +struct da8xx_pruss {
What is the "ss" suffix for ?
> +u32 pruss_disable(struct device *dev, u8 pruss_num)
> +{
> + struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
> + da8xx_prusscore_regs h_pruss;
> + u32 temp_reg;
> +
> + if (pruss_num == DA8XX_PRUCORE_0) {
> + /* Disable PRU0 */
> + h_pruss = (da8xx_prusscore_regs)
> + ((u32) pruss->ioaddr + 0x7000);
So it seems you're doing this in several places, and I have a few comments:
- You don't need the da8xx_prusscore_regs at all.
- Define the register map through a set of #define in your header file.
- Use a static routine that takes the core number and returns the register map
offset.
Then routines like this one will look a lot more readable.
> +s16 pruss_writeb(struct device *dev, u32 u32offset,
> + u8 *pu8datatowrite, u16 u16bytestowrite)
^ permalink raw reply
* mc13xxx-core, support for i2c, V4
From: Samuel Ortiz @ 2011-02-21 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102122111.30525.marc@cpdesign.com.au>
Hi Mark,
On Sat, Feb 12, 2011 at 09:11:30PM +1100, Marc Reilly wrote:
> Hi Grant,
>
> Thanks for your comments,
>
> On Saturday, February 12, 2011 07:40:35 pm Grant Likely wrote:
> > On Tue, Jan 04, 2011 at 04:34:55PM +1100, Marc Reilly wrote:
> > > Hi,
> > >
> > > These patches add i2c support for the mc13xxx-core drive. For v4 I've
> > > tried to take in all previous comments, hopefully making it better to
> > > follow, and bisectable.
> >
> > This series looks okay to me. Since this is audio drivers, I expect
> > that it would best be taken via the ASoC tree? Have you sent it to
> > Mark Brown and the ALSA list for review?
> >
> > g.
>
> Actually only the mc13873 has audio support. I think these IC's really fit
> better under the MFD tree, but silly me didn't add Samuel Ortiz (MFD
> maintainer) to this series... so included him now.
>
> Samuel, are you the most appropriate to take this series in and would you like
> me to resend these patches to you? The thread archive is at [1].
Yes, I would be the one taking those patches. Please resend the patch set to
me, and I'll have a look. Has Uwe commented on them yet ?
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ 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