* [PATCH] mxcmmc: use dmaengine API
From: Shawn Guo @ 2011-01-12 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294826996-13764-2-git-send-email-s.hauer@pengutronix.de>
It seems all the tabs were turned into spaces.
On Wed, Jan 12, 2011 at 11:09:56AM +0100, 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 implement, 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>
> ---
> drivers/mmc/host/mxcmmc.c | 172 +++++++++++++++++++++++++--------------------
> 1 files changed, 97 insertions(+), 75 deletions(-)
>
[...]
--
Regards,
Shawn
^ permalink raw reply
* [PATCH] mxcmmc: use dmaengine API
From: Shawn Guo @ 2011-01-12 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110112122541.GA6569@freescale.com>
On Wed, Jan 12, 2011 at 8:25 PM, Shawn Guo <shawn.guo@freescale.com> wrote:
> It seems all the tabs were turned into spaces.
>
My problem. Sorry for the noise.
> On Wed, Jan 12, 2011 at 11:09:56AM +0100, 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 implement, 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>
>> ---
>> ?drivers/mmc/host/mxcmmc.c | ?172 +++++++++++++++++++++++++--------------------
>> ?1 files changed, 97 insertions(+), 75 deletions(-)
>>
> [...]
>
> --
> Regards,
> Shawn
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Regards,
Shawn
^ permalink raw reply
* [PATCH] watchdog: add support for the Synopsys DesignWare WDT
From: Jamie Iles @ 2011-01-12 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimtW4GZmjL0ryi1HgOMrCC4gMfGDdEqLJgW_2YA@mail.gmail.com>
On Wed, Jan 12, 2011 at 05:08:42PM +0530, viresh kumar wrote:
> On Wed, Jan 12, 2011 at 5:00 PM, Jamie Iles <jamie@jamieiles.com> wrote:
> > On Wed, Jan 12, 2011 at 02:27:47PM +0530, viresh kumar wrote:
> >> On Wed, Jan 12, 2011 at 1:54 PM, Jamie Iles <jamie@jamieiles.com> wrote:
> >> >> I don't know why, but checkpatch used to give few errors which it is
> >> >> not giving now.
> >> >> Like:
> >> >> - Mixing spaces and tabs
> >> >> - Line over 80 columns.
> >> >>
> > I do need to fix up the register locations (40-45) but the others are ok
> > - they are tab indented to get to a multiple of 8 then spaces to align
> > to the '(' brackets etc.
>
> That's what i said. Checkpatch used to give warning for them earlier.
> I don't know if it is correct or not. Anyway, others will comment if it is
> still a issue. You can keep that as it is.
>
> >> Problem will occur if rate is dynamically changed and we are still believing
> >> on platform code's clk_rate.
> >> Would be better if we switch order. i.e. give priority to clk_get_rate over
> >> pdata->rate.
> >
> > If the platform can change the rate then I don't see why it would define
> > the rate in the platform data though. ?Anyway, I can make the change and
> > issue a warning and fail the probe if we're using the rate from
> > clk_get_rate() and there is a non-zero rate in the platform data.
>
> that's better.
Ok, I'll give Wim chance to have a look over v5 then I'll integrate
these changes.
Thanks again for the review.
Jamie
^ permalink raw reply
* BUG: spinlock recursion (sys_chdir, user_path_at, do_path_lookup ...)
From: Russell King - ARM Linux @ 2011-01-12 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110112120349.GH24920@pengutronix.de>
On Wed, Jan 12, 2011 at 01:03:49PM +0100, Uwe Kleine-K?nig wrote:
> On Wed, Jan 12, 2011 at 11:57:50AM +0100, Thomas Gleixner wrote:
> > On Wed, 12 Jan 2011, Uwe Kleine-K?nig wrote:
> > > > [ 75.280000] r5:be961ee4 r4:00063015
> > > >
> > > > I started to bisect, but already the first test case showed a different
> > > > error (my getty dying every few seconds).
> > > I bisected this one now, the first bad commit is
> > >
> > > 9c0729d (x86: Eliminate bp argument from the stack tracing routines)
> > >
> > > . It made a x86 specific change to include/linux/stacktrace.h.
> >
> > As I said on IRC already, that's complete nonsense. The commit changes
> > a function prototype which is only relevant for x86. So how should
> > that affect ARM ?
> hmm, the conversion that you probably mean is:
>
> 22:26 < ukleinek> hmm, 9c0729dc8062bed96189bd14ac6d4920f3958743 is the first bad commit
> 22:26 < tglx> lol
> 22:26 * ukleinek goes to bed
> 22:27 < ukleinek> then it can only be about include/linux/stacktrace.h
> 22:27 * ukleinek goes to bed anyhow
> 22:28 < rostedt> ukleinek: btw, you could do the bisect automated with ktest.pl :-)
> 22:30 < tglx> ukleinek: right, a change to include/linux/stacktrace.h which is x86 specific
> 22:33 < tglx> makes arm explode
> 22:33 < tglx> rotfl
>
> I admit I didn't look what was changed there and I understood your
> statement as "the change to include/linux/stacktrace.h was x86 specific
> and so broke ARM".
This commit has nothing to do with ARM and couldn't possibly be
responsible for your breakage. The diffstat for that commit is:
arch/x86/include/asm/kdebug.h | 2 +-
arch/x86/include/asm/stacktrace.h | 33 ++++++++++++++++++++++++++++++---
arch/x86/kernel/cpu/perf_event.c | 2 +-
arch/x86/kernel/dumpstack.c | 12 ++++++------
arch/x86/kernel/dumpstack_32.c | 25 +++++++------------------
arch/x86/kernel/dumpstack_64.c | 24 +++++++-----------------
arch/x86/kernel/process.c | 3 +--
arch/x86/kernel/stacktrace.c | 8 ++++----
arch/x86/mm/kmemcheck/error.c | 2 +-
arch/x86/oprofile/backtrace.c | 2 +-
include/linux/stacktrace.h | 4 +++-
11 files changed, 62 insertions(+), 55 deletions(-)
and the only file which could affect ARM is include/linux/stacktrace.h.
That change adds a declaration of struct pt_regs and then does:
-extern void save_stack_trace_bp(struct stack_trace *trace, unsigned long bp);
+extern void save_stack_trace_regs(struct stack_trace *trace,
+ struct pt_regs *regs);
ARM doesn't implement save_stack_trace_regs() nor save_stack_trace_bp()
so if the compiler referenced these, you'd have a kernel which doesn't
link. The only places that this symbol appears is:
arch/x86/kernel/stacktrace.c:void save_stack_trace_regs(struct stack_trace *trac
arch/x86/mm/kmemcheck/error.c: save_stack_trace_regs(&e->trace, regs);
include/linux/stacktrace.h:extern void save_stack_trace_regs(struct stack_trace
So, if this is where your bisect decided was the problem, your bisect
was faulty.
^ permalink raw reply
* [PATCH v2] ARM: Change misleading warning when CONFIG_CMDLINE_FORCE is used
From: Alexander Holler @ 2011-01-12 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110112093246.GA25718@pengutronix.de>
Hello,
Am 12.01.2011 10:32, schrieb Uwe Kleine-K?nig:
> Hello Russell,ah, I thought the effect of CONFIG_CMDLINE_FORCE would be its inverse.
> And ok, this is probably about broken boot loaders that I'm just not
> used to.
>
The real intention of CONFIG_CMD_FORCE was hotplug. Take a device with a
bootloader wich loads the kernel from the first partition of a
changeable media (e.g. usb-hd).
Without that option you would have to use the same command line for all
medias.
But I find it also very handy for rescue-kernels and such.
Regards,
Alexander
^ permalink raw reply
* [PATCH 5/5 v2] ARM: pxa: Fix recursive call of pxa_(un)mask_low_gpio()
From: Sergei Shtylyov @ 2011-01-12 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294699993-4712-5-git-send-email-marek.vasut@gmail.com>
Hello.
On 11-01-2011 1:53, Marek Vasut wrote:
> Signed-off-by: Marek Vasut<marek.vasut@gmail.com>
> ---
> v2: Remove dead code as proposed by Sergei
> arch/arm/mach-pxa/irq.c | 8 ++------
> 1 files changed, 2 insertions(+), 6 deletions(-)
> diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
> index a7deff5..76e69cf 100644
> --- a/arch/arm/mach-pxa/irq.c
> +++ b/arch/arm/mach-pxa/irq.c
> @@ -110,16 +110,12 @@ static void pxa_ack_low_gpio(unsigned int irq)
>
> static void pxa_mask_low_gpio(unsigned int irq)
> {
> - struct irq_desc *desc = irq_to_desc(irq);
> -
> - desc->chip->mask(irq);
> + pxa_mask_irq(irq);
> }
>
> static void pxa_unmask_low_gpio(unsigned int irq)
> {
> - struct irq_desc *desc = irq_to_desc(irq);
> -
> - desc->chip->unmask(irq);
> + pxa_unmask_irq(irq);
> }
>
> static struct irq_chip pxa_low_gpio_chip = {
If the above two functions are the methods of this IRQ chip, shouldn't you
just replace the initializers and remove the functions altogether?
WBR, Sergei
^ permalink raw reply
* BUG: spinlock recursion (sys_chdir, user_path_at, do_path_lookup ...)
From: Russell King - ARM Linux @ 2011-01-12 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110112123508.GZ11039@n2100.arm.linux.org.uk>
On Wed, Jan 12, 2011 at 12:35:08PM +0000, Russell King - ARM Linux wrote:
> ARM doesn't implement save_stack_trace_regs() nor save_stack_trace_bp()
> so if the compiler referenced these, you'd have a kernel which doesn't
> link. The only places that this symbol appears is:
>
> arch/x86/kernel/stacktrace.c:void save_stack_trace_regs(struct stack_trace *trac
> arch/x86/mm/kmemcheck/error.c: save_stack_trace_regs(&e->trace, regs);
> include/linux/stacktrace.h:extern void save_stack_trace_regs(struct stack_trace
>
> So, if this is where your bisect decided was the problem, your bisect
> was faulty.
BTW, a useful thing to do after a bisect is to return to the point in
the history where you first noticed the regression (so Linus' tip,
your tip, or whatever). Then try reverting the commit which git bisect
_thinks_ is the cause of your problem and re-test that.
If the problem is fixed, you have greater confidence that the commit is
the problem.
If it made no difference, then you know that something else (maybe in
combination) is causing the problem.
If you couldn't revert it because of other dependencies then you have
to rely on analysis (such as what I did) and maybe try again with a
slightly different strategy - maybe the problem only _occasionally_
occurs, making the 'git bisect good' points unreliable, so maybe you
need to do more testing when the problem doesn't immediately appear?
Lastly, it is worth bearing in mind that GCC is really finicky with its
optimization. It may be hard to believe, but unrelated function
definitions in headers can (and do) affect the code generation in
completely unrelated functions causing them to be optimized
differently [*]. Maybe this applies to prototypes too?
So it _could_ be that the prototype change in include/linux/stacktrace.h
is tickling a GCC code generation bug.
* - ISTR, this behaviour was raised as a bug with GCC folk, which I
believe was closed down as wontfix as its a result of the way the
optimizer works.
^ permalink raw reply
* BUG: spinlock recursion (sys_chdir, user_path_at, do_path_lookup ...)
From: Thomas Gleixner @ 2011-01-12 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110112124844.GA4415@n2100.arm.linux.org.uk>
On Wed, 12 Jan 2011, Russell King - ARM Linux wrote:
> On Wed, Jan 12, 2011 at 12:35:08PM +0000, Russell King - ARM Linux wrote:
> > ARM doesn't implement save_stack_trace_regs() nor save_stack_trace_bp()
> > so if the compiler referenced these, you'd have a kernel which doesn't
> > link. The only places that this symbol appears is:
> >
> > arch/x86/kernel/stacktrace.c:void save_stack_trace_regs(struct stack_trace *trac
> > arch/x86/mm/kmemcheck/error.c: save_stack_trace_regs(&e->trace, regs);
> > include/linux/stacktrace.h:extern void save_stack_trace_regs(struct stack_trace
> >
> > So, if this is where your bisect decided was the problem, your bisect
> > was faulty.
>
> BTW, a useful thing to do after a bisect is to return to the point in
> the history where you first noticed the regression (so Linus' tip,
> your tip, or whatever). Then try reverting the commit which git bisect
> _thinks_ is the cause of your problem and re-test that.
>
> If the problem is fixed, you have greater confidence that the commit is
> the problem.
>
> If it made no difference, then you know that something else (maybe in
> combination) is causing the problem.
>
> If you couldn't revert it because of other dependencies then you have
> to rely on analysis (such as what I did) and maybe try again with a
> slightly different strategy - maybe the problem only _occasionally_
> occurs, making the 'git bisect good' points unreliable, so maybe you
> need to do more testing when the problem doesn't immediately appear?
>
> Lastly, it is worth bearing in mind that GCC is really finicky with its
> optimization. It may be hard to believe, but unrelated function
> definitions in headers can (and do) affect the code generation in
> completely unrelated functions causing them to be optimized
> differently [*]. Maybe this applies to prototypes too?
Yes, it does. Also adding an inline or define can change the
behaviour.
> So it _could_ be that the prototype change in include/linux/stacktrace.h
> is tickling a GCC code generation bug.
>
> * - ISTR, this behaviour was raised as a bug with GCC folk, which I
> believe was closed down as wontfix as its a result of the way the
> optimizer works.
Right, they just fixed the problem where this effect generated buggy
code on x86 in some cases.
Thanks,
tglx
^ permalink raw reply
* [PATCH] mxcmmc: use dmaengine API
From: Sascha Hauer @ 2011-01-12 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110112102632.GX11039@n2100.arm.linux.org.uk>
On Wed, Jan 12, 2011 at 10:26:32AM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 12, 2011 at 11:09:56AM +0100, Sascha Hauer wrote:
> > + host->dma_nents = dma_map_sg(mmc_dev(host->mmc), data->sg,
> > + data->sg_len, host->dma_dir);
>
> As recently discussed, you don't need to save dma_nents - the value to
> be passed to dma_unmap_sg() is data->sg_len, not host->dma_nents.
>
> You should also do the map/unmap against the DMA engine device (which
> is the device actually doing DMA) rather than the peripheral (which is
> only the recipient of DMA). The reason is - while the peripheral can
> see the DMA controller, the peripheral may be able to see all RAM but
> the DMA controller may have an IOMMU or limited view of RAM.
ok.
>
> > +static int mxcmci_setup_dma(struct mmc_host *mmc)
> > +{
> > + struct mxcmci_host *host = mmc_priv(mmc);
> > + struct dma_slave_config *config = &host->dma_slave_config;
> > +
> > + config->direction = DMA_FROM_DEVICE;
>
> I would like to get some concensus on removing config->direction from
> the slave configuration entirely - and make all the fields below
> refer purely to the peripheral device parameters. At the moment,
> the API allows them to be used ambiguously.
OK, I can remove this as it's unused by the dma driver anyway (and in
fact I wondered what purpose this field has while writing the dma
drivers)
>
> > @@ -794,7 +823,7 @@ static int mxcmci_probe(struct platform_device *pdev)
> > mmc->max_blk_size = 2048;
> > mmc->max_blk_count = 65535;
> > mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
> > - mmc->max_seg_size = mmc->max_req_size;
> > + mmc->max_seg_size = 65535;
>
> You can get this from the DMA parameters for the DMA engine device:
>
> mmc->max_seg_size = dma_get_max_seg_size(dev);
>
> where 'dev' is the DMA engine struct device - chan->dma_device->dev.
I prepared a patch to set the segment size in the i.MX DMA drivers.
>
> Also just spotted this left in your patch:
> > + if (!mxcmci_use_dma(host))
> > + return 0;
> > +
> > for_each_sg(data->sg, sg, data->sg_len, i) {
> > if (sg->offset & 3 || sg->length & 3) {
> > host->do_dma = 0;
>
> Shouldn't this be a decision made by the DMA engine rather than the
> driver? Having looked at the MMCI code also doing this, I think this
> should cause prep_slave_sg() to return NULL if it can't handle the
> scatterlist. On MMCI, we fall back to PIO if prep_slave_sg() returns
> NULL.
I prepared a patch which checks for invalid addresses and lengths in the
DMA drivers.
I'd like to push this patch like it is until the two points above are
solved upstream (with the other points fixed of course).
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] MAINTAINERS: Update Atmel AT91 entry
From: Nicolas Ferre @ 2011-01-12 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294250698-13275-1-git-send-email-nicolas.ferre@atmel.com>
Le 05/01/2011 19:04, Nicolas Ferre :
> Add two co-maintainers and update the entry with new information.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> Acked-by: Andrew Victor <linux@maxim.org.za>
> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Hi Andrew (Morton),
Maybe you can handle this "MAINTAINERS" patch?
Thanks a lot, bye.
> ---
> MAINTAINERS | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7585e9d..cb58500 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -552,11 +552,15 @@ M: Lennert Buytenhek <kernel@wantstofly.org>
> L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> S: Maintained
>
> -ARM/ATMEL AT91RM9200 ARM ARCHITECTURE
> +ARM/ATMEL AT91RM9200 AND AT91SAM ARM ARCHITECTURES
> M: Andrew Victor <linux@maxim.org.za>
> +M: Nicolas Ferre <nicolas.ferre@atmel.com>
> +M: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> W: http://maxim.org.za/at91_26.html
> -S: Maintained
> +W: http://www.linux4sam.org
> +S: Supported
> +F: arch/arm/mach-at91/
>
> ARM/BCMRING ARM ARCHITECTURE
> M: Jiandong Zheng <jdzheng@broadcom.com>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] bitops: remove condition code clobber for CLZ
From: Rabin Vincent @ 2011-01-12 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101111347320.17086@xanadu.home>
On Wed, Jan 12, 2011 at 00:21, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Tue, 11 Jan 2011, Russell King - ARM Linux wrote:
>> On Tue, Jan 11, 2011 at 11:12:05PM +0530, Rabin Vincent wrote:
>> > The CLZ instruction does not alter the condition flags, so remove the
>> > "cc" clobber from the inline asm for fls().
>>
>> Do you have any evidence that this changes anything, or is it just
>> subjective?
>
> This probably doesn't change anything, as gcc has been presuming that
> inline asms do clobber the condition code for years now, in order to
> prevent issues caused by a lack of %? appended to instructions in order
> to conditionally execute them otherwise.
FWIW, note that I am able to see GCC using the condition code clobber
information. For example, for this (artificial) test code:
static inline int fls(int x)
{
int ret;
#ifdef CLOBBER
asm("clz %0,%1" : "=r" (ret) : "r" (x): "cc");
#else
asm("clz %0,%1" : "=r" (ret) : "r" (x));
#endif
return 32 - ret;
}
int f(int b)
{
int x = fls(b);
return b > 100 ? x : x + 10;
}
I get (GCC 4.5.1, at -O2):
--- clobber.s 2011-01-12 19:41:36.000000000 +0530
+++ noclobber.s 2011-01-12 19:41:36.000000000 +0530
@@ -1,12 +1,12 @@
-clobber.o: file format elf32-littlearm
+noclobber.o: file format elf32-littlearm
Disassembly of section .text:
00000000 <f>:
- 0: e16f3f10 clz r3, r0
- 4: e3500064 cmp r0, #100 ; 0x64
- 8: e2630020 rsb r0, r3, #32
+ 0: e3500064 cmp r0, #100 ; 0x64
+ 4: e16f0f10 clz r0, r0
+ 8: e2600020 rsb r0, r0, #32
c: d280000a addle r0, r0, #10
10: e12fff1e bx lr
^ permalink raw reply
* [PATCH] bitops: remove condition code clobber for CLZ
From: Russell King - ARM Linux @ 2011-01-12 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimyjEvKVusSvmdpgcMT=WeP3WwYDDYcWO8XKiY2@mail.gmail.com>
On Wed, Jan 12, 2011 at 07:48:10PM +0530, Rabin Vincent wrote:
> On Wed, Jan 12, 2011 at 00:21, Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Tue, 11 Jan 2011, Russell King - ARM Linux wrote:
> >> On Tue, Jan 11, 2011 at 11:12:05PM +0530, Rabin Vincent wrote:
> >> > The CLZ instruction does not alter the condition flags, so remove the
> >> > "cc" clobber from the inline asm for fls().
> >>
> >> Do you have any evidence that this changes anything, or is it just
> >> subjective?
> >
> > This probably doesn't change anything, as gcc has been presuming that
> > inline asms do clobber the condition code for years now, in order to
> > prevent issues caused by a lack of %? appended to instructions in order
> > to conditionally execute them otherwise.
>
> FWIW, note that I am able to see GCC using the condition code clobber
> information. For example, for this (artificial) test code:
Ok, better code generation is a reason to apply this patch (not that
the example particularly shows that the new order was better - but it
can potentially be if there's loads around.)
^ permalink raw reply
* [PATCH 2/6] dmaengine: at_hdmac: trivial add precision to unmapping comment
From: Nicolas Ferre @ 2011-01-12 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1292435416-16927-1-git-send-email-nicolas.ferre@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
Hi Dan,
I link this patch series to the previous single patch that I sent a few days
ago so that you will have the whole overview of current (little) improvements
on the Atmel at_hdmac driver.
Thanks, best regards,
Nicolas.
drivers/dma/at_hdmac.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index ee7dacd..a4dd4bc 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -253,7 +253,7 @@ atc_chain_complete(struct at_dma_chan *atchan, struct at_desc *desc)
/* move myself to free_list */
list_move(&desc->desc_node, &atchan->free_list);
- /* unmap dma addresses */
+ /* unmap dma addresses (not on slave channels) */
if (!atchan->chan_common.private) {
struct device *parent = chan2parent(&atchan->chan_common);
if (!(txd->flags & DMA_COMPL_SKIP_DEST_UNMAP)) {
--
1.7.3
^ permalink raw reply related
* [PATCH 3/6] dmaengine: at_hdmac: no need set ACK in new descriptor
From: Nicolas Ferre @ 2011-01-12 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1292435416-16927-1-git-send-email-nicolas.ferre@atmel.com>
Following descriptor flow in at_hdmac driver, descriptor comming from
atc_desc_get() as already DMA_CTRL_ACK flag set. No need to set it again.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/dma/at_hdmac.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index a4dd4bc..4f83431 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -583,7 +583,6 @@ atc_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
desc->lli.ctrlb = ctrlb;
desc->txd.cookie = 0;
- async_tx_ack(&desc->txd);
if (!first) {
first = desc;
--
1.7.3
^ permalink raw reply related
* [PATCH 4/6] dmaengine: at_hdmac: use subsys_initcall instead of module_init
From: Nicolas Ferre @ 2011-01-12 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1292435416-16927-1-git-send-email-nicolas.ferre@atmel.com>
From: Eric Xu <hong.xu@atmel.com>
Use subsys_initcall instead of module_init in order to keep DMA engine rolling
before other peripheral drivers.
Signed-off-by: Eric Xu <hong.xu@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/dma/at_hdmac.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 4f83431..a1a0fc6 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -1209,7 +1209,7 @@ static int __init at_dma_init(void)
{
return platform_driver_probe(&at_dma_driver, at_dma_probe);
}
-module_init(at_dma_init);
+subsys_initcall(at_dma_init);
static void __exit at_dma_exit(void)
{
--
1.7.3
^ permalink raw reply related
* [PATCH 5/6] dmaengine: at_hdmac: flags located in first descriptor
From: Nicolas Ferre @ 2011-01-12 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1292435416-16927-1-git-send-email-nicolas.ferre@atmel.com>
Place flags on first descriptor of chain instead of last.
This is the one used by atc_chain_complete() function while unmapping.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/dma/at_hdmac.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index a1a0fc6..99942a5 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -603,7 +603,7 @@ atc_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
/* set end-of-link to the last link descriptor of list*/
set_desc_eol(desc);
- desc->txd.flags = flags; /* client is in control of this ack */
+ first->txd.flags = flags; /* client is in control of this ack */
return &first->txd;
@@ -748,8 +748,8 @@ atc_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
first->txd.cookie = -EBUSY;
first->len = total_len;
- /* last link descriptor of list is responsible of flags */
- prev->txd.flags = flags; /* client is in control of this ack */
+ /* first link descriptor of list is responsible of flags */
+ first->txd.flags = flags; /* client is in control of this ack */
return &first->txd;
--
1.7.3
^ permalink raw reply related
* [PATCH 6/6] dmaengine: at_hdmac: fix race while monitoring channel status
From: Nicolas Ferre @ 2011-01-12 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1292435416-16927-1-git-send-email-nicolas.ferre@atmel.com>
We were reading channel status then taking a lock. This lead to a race because
this lock may delay us and then make this channel not idle anymore.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/dma/at_hdmac.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 99942a5..3d7d705 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -853,11 +853,11 @@ static void atc_issue_pending(struct dma_chan *chan)
dev_vdbg(chan2dev(chan), "issue_pending\n");
+ spin_lock_bh(&atchan->lock);
if (!atc_chan_is_enabled(atchan)) {
- spin_lock_bh(&atchan->lock);
atc_advance_work(atchan);
- spin_unlock_bh(&atchan->lock);
}
+ spin_unlock_bh(&atchan->lock);
}
/**
--
1.7.3
^ permalink raw reply related
* [PATCH v4 08/10] ARM: mxs: add ocotp read function
From: Sascha Hauer @ 2011-01-12 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110112064711.GG2888@freescale.com>
On Wed, Jan 12, 2011 at 02:47:12PM +0800, Shawn Guo wrote:
> Hi Sascha,
>
> On Tue, Jan 11, 2011 at 02:31:37PM +0100, Sascha Hauer wrote:
> > On Thu, Jan 06, 2011 at 03:13:16PM +0800, Shawn Guo wrote:
> > > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > > ---
> > > Changes for v4:
> > > - Call cpu_relax() during polling
> > >
> > > Changes for v2:
> > > - Add mutex locking for mxs_read_ocotp()
> > > - Use type size_t for count and i
> > > - Add comment for clk_enable/disable skipping
> > > - Add ERROR bit clearing and polling step
> > >
> > > arch/arm/mach-mxs/Makefile | 2 +-
> > > arch/arm/mach-mxs/include/mach/common.h | 1 +
> > > arch/arm/mach-mxs/ocotp.c | 79 +++++++++++++++++++++++++++++++
> > > 3 files changed, 81 insertions(+), 1 deletions(-)
> > > create mode 100644 arch/arm/mach-mxs/ocotp.c
> > >
> > > diff --git a/arch/arm/mach-mxs/Makefile b/arch/arm/mach-mxs/Makefile
> > > index 39d3f9c..f23ebbd 100644
> > > --- a/arch/arm/mach-mxs/Makefile
> > > +++ b/arch/arm/mach-mxs/Makefile
> > > @@ -1,5 +1,5 @@
> > > # Common support
> > > -obj-y := clock.o devices.o gpio.o icoll.o iomux.o system.o timer.o
> > > +obj-y := clock.o devices.o gpio.o icoll.o iomux.o ocotp.o system.o timer.o
> > >
> > > obj-$(CONFIG_SOC_IMX23) += clock-mx23.o mm-mx23.o
> > > obj-$(CONFIG_SOC_IMX28) += clock-mx28.o mm-mx28.o
> > > diff --git a/arch/arm/mach-mxs/include/mach/common.h b/arch/arm/mach-mxs/include/mach/common.h
> > > index 59133eb..cf02552 100644
> > > --- a/arch/arm/mach-mxs/include/mach/common.h
> > > +++ b/arch/arm/mach-mxs/include/mach/common.h
> > > @@ -13,6 +13,7 @@
> > >
> > > struct clk;
> > >
> > > +extern int mxs_read_ocotp(int offset, int count, u32 *values);
> > > extern int mxs_reset_block(void __iomem *);
> > > extern void mxs_timer_init(struct clk *, int);
> > >
> > > diff --git a/arch/arm/mach-mxs/ocotp.c b/arch/arm/mach-mxs/ocotp.c
> > > new file mode 100644
> > > index 0000000..e2d39aa
> > > --- /dev/null
> > > +++ b/arch/arm/mach-mxs/ocotp.c
> > > @@ -0,0 +1,79 @@
> > > +/*
> > > + * Copyright 2010 Freescale Semiconductor, Inc. All Rights Reserved.
> > > + *
> > > + * 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; either version 2 of the License, or
> > > + * (at your option) any later version.
> > > + *
> > > + * This program is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > > + * GNU General Public License for more details.
> > > + */
> > > +
> > > +#include <linux/delay.h>
> > > +#include <linux/err.h>
> > > +#include <linux/mutex.h>
> > > +
> > > +#include <mach/mxs.h>
> > > +
> > > +#define BM_OCOTP_CTRL_BUSY (1 << 8)
> > > +#define BM_OCOTP_CTRL_ERROR (1 << 9)
> > > +#define BM_OCOTP_CTRL_RD_BANK_OPEN (1 << 12)
> > > +
> > > +static DEFINE_MUTEX(ocotp_mutex);
> > > +
> > > +int mxs_read_ocotp(unsigned offset, size_t count, u32 *values)
> > > +{
> > > + void __iomem *ocotp_base = MXS_IO_ADDRESS(MXS_OCOTP_BASE_ADDR);
> > > + int timeout = 0x400;
> > > + size_t i;
> > > +
> > > + mutex_lock(&ocotp_mutex);
> > > +
> > > + /*
> > > + * clk_enable(hbus_clk) for ocotp can be skipped
> > > + * as it must be on when system is running.
> > > + */
> > > +
> > > + /* try to clear ERROR bit */
> > > + __mxs_clrl(BM_OCOTP_CTRL_ERROR, ocotp_base);
> >
> > This operation does not try to clear the error bit but actually clears
> > it...
> >
> > > +
> > > + /* check both BUSY and ERROR cleared */
> > > + while ((__raw_readl(ocotp_base) &
> > > + (BM_OCOTP_CTRL_BUSY | BM_OCOTP_CTRL_ERROR)) && --timeout)
> > > + cpu_relax();
> >
> > ...which means you do not have to poll the error bit here...
> >
> > > +
> > > + if (unlikely(!timeout))
> > > + goto error_unlock;
> > > +
> > > + /* open OCOTP banks for read */
> > > + __mxs_setl(BM_OCOTP_CTRL_RD_BANK_OPEN, ocotp_base);
> > > +
> > > + /* approximately wait 32 hclk cycles */
> > > + udelay(1);
> > > +
> > > + /* poll BUSY bit becoming cleared */
> > > + timeout = 0x400;
> > > + while ((__raw_readl(ocotp_base) & BM_OCOTP_CTRL_BUSY) && --timeout)
> > > + cpu_relax();
> >
> > ...which means you can factor out a ocotp_wait_busy function and let the
> > code speak instead of the comments.
> >
> > > +
> > > + if (unlikely(!timeout))
> > > + goto error_unlock;
> > > +
> > > + for (i = 0; i < count; i++, offset += 4)
> > > + *values++ = __raw_readl(ocotp_base + offset);
> >
> > The registers in the ocotp are 16 byte aligned. Does it really make
> > sense to provide a function allowing to read the gaps between the
> > registers?
> >
> Good catch. The count was added to ease the consecutive otp word
> reading, as there is bank open/close cost for otp read. What about
> the following changes?
>
> int mxs_read_ocotp(unsigned offset, size_t otp_word_cnt, u32 *values)
> {
> ......
>
> for (i = 0; i < otp_word_cnt; i++, offset += 0x10)
> *values++ = __raw_readl(ocotp_base + offset);
>
> ......
> }
I would rather make a function like this:
static u32 ocotp[0x27];
const u32 *mxs_get_ocotp(void)
{
static int once = 0;
if (once)
return ocotp
/* bank open */
for (i = 0; i < 0x27; i++)
ocotp[i] = readl(ocotp_base + 0x20 + i * 0x10)
/* bank_close */
once = 1;
return ocotp;
}
--
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] [RFC]ARM:Let GIC to route IRQs to any allowed CPUs
From: Tao Hu @ 2011-01-12 15:10 UTC (permalink / raw)
To: linux-arm-kernel
The current logic will always route IRQs to the first allowed CPU
Following two commands have the same result (all IRQs to CPU0)
cmd1: $ echo 3 > proc/irq/xxx/smp_affinity
cmd2: $ echo 1 > proc/irq/xxx/smp_affinity
While below command will route all IRQs to CPU1
cmd3: $ echo 2 > proc/irq/xxx/smp_affinity
With this patch, cmd1 will route IRQs to both CPU0 and CPU1
Meanwhile, cmd2 and cmd3 will work as before
Change-Id: Ife8e466ded7c18b4b050a4bc64b62346c063a93b
Signed-off-by: Tao Hu <taohu@motorola.com>
---
arch/arm/common/gic.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index bceb9cb..4904988 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -105,7 +105,11 @@ static int gic_set_cpu(unsigned int irq, const
struct cpumask *mask_val)
spin_lock(&irq_controller_lock);
irq_desc[irq].node = cpu;
val = readl(reg) & ~(0xff << shift);
- val |= 1 << (cpu + shift);
+ do {
+ val |= 1 << (cpu + shift);
+ cpu = cpumask_next(cpu, mask_val);
+ } while (cpu < nr_cpu_ids);
+
writel(val, reg);
spin_unlock(&irq_controller_lock);
--
1.7.1
^ permalink raw reply related
* [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
From: Grant Likely @ 2011-01-12 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111154833.GF11039@n2100.arm.linux.org.uk>
On Tue, Jan 11, 2011 at 8:48 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jan 11, 2011 at 08:36:30AM -0700, Grant Likely wrote:
>> On Tue, Jan 11, 2011 at 10:40:51AM +0000, Russell King - ARM Linux wrote:
>> > On Mon, Jan 10, 2011 at 07:15:53PM -0700, Grant Likely wrote:
>> > > diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
>> > > index 6bd82d2..9c0e938 100644
>> > > --- a/arch/arm/kernel/head.S
>> > > +++ b/arch/arm/kernel/head.S
>> > > @@ -87,11 +87,6 @@ ENTRY(stext)
>> > > ? movs ? ?r10, r5 ? ? ? ? ? ? ? ? ? ? ? ? @ invalid processor (r5=0)?
>> > > ? THUMB( it ? ? ? eq ) ? ? ? ? ? ?@ force fixup-able long branch encoding
>> > > ? beq ? ? __error_p ? ? ? ? ? ? ? ? ? ? ? @ yes, error 'p'
>> > > - bl ? ? ?__lookup_machine_type ? ? ? ? ? @ r5=machinfo
>> > > - movs ? ?r8, r5 ? ? ? ? ? ? ? ? ? ? ? ? ?@ invalid machine (r5=0)?
>> > > - THUMB( it ? ? ? eq ) ? ? ? ? ? ?@ force fixup-able long branch encoding
>> > > - beq ? ? __error_a ? ? ? ? ? ? ? ? ? ? ? @ yes, error 'a'
>> > > - bl ? ? ?__vet_atags
>> > > ?#ifdef CONFIG_SMP_ON_UP
>> > > ? bl ? ? ?__fixup_smp
>> > > ?#endif
>> >
>> > Don't forget to update the comments as well - there's two of them.
>>
>> I'm not entirely clear on what you're referring to here. ?Are you
>> talking about the secondary cpu entry point? ?I've fixed up that
>> comment now as well as a s/__lookup_machine_type/__lookup_processor_type/
>> typo right before the call to __enable_mmu.
>
> In the above code, __lookup_machine_type is called, which to be
> consistent with __lookup_processor_type, returns its value in r5. ?This
> is then copied to r8, which is the only point that r8 is initialized.
>
> The remainder of the code used to make use of r8 to load various fields
> from the machine record, and so there's a couple of comments indicating
> that this is the case. ?These comments are left behind after your patch
> and so are misleading.
Ah, right. I'll clean those up.
> Shall I assume that you've already searched the head*.S files to make
> sure that r8 isn't used before you removed its initialization? ;-)
Yup!
Looks like I've hit a hiccup though. When I remove the first call to
__lookup_machine_type, then it is only called after the MMU is turned
on and the kernel is no longer able to output the list of configured
machine ids when it doesn't recognize the value in r1 (tested with
qemu versatile emulation). I'm still investigating, so I'll defer
reposting the patch until I've got this issue solved.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [RFC] arm: Defer lookup of machine_type and vet of atags to setup.c
From: Russell King - ARM Linux @ 2011-01-12 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=29LB66j123ufMHQk=46hGYdmR4nZZQFnN=Tku@mail.gmail.com>
On Wed, Jan 12, 2011 at 08:46:44AM -0700, Grant Likely wrote:
> Looks like I've hit a hiccup though. When I remove the first call to
> __lookup_machine_type, then it is only called after the MMU is turned
> on and the kernel is no longer able to output the list of configured
> machine ids when it doesn't recognize the value in r1 (tested with
> qemu versatile emulation). I'm still investigating, so I'll defer
> reposting the patch until I've got this issue solved.
It only does this when DEBUG_LL is enabled - at which point you have
printascii, printhex8, etc available (although there's no prototype
for them.)
You could use snprintf() to format a message and then use printascii()
(conditional on CONFIG_DEBUG_LL as the existing code does) as well as
printk("%s", buffer). That means if you have a debugger you can dump
the kernel ring buffer and see the message, or see it via the serial
port/debugging channel if DEBUG_LL is enabled.
^ permalink raw reply
* [PATCH 0/0] RFC: ARM: Thumb-2: Symbol manipulation macros for function body copying
From: Dave Martin @ 2011-01-12 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110112093209.GA18833@n2100.arm.linux.org.uk>
Hi,
On Wed, Jan 12, 2011 at 3:32 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jan 11, 2011 at 06:02:30PM -0600, Dave Martin wrote:
>> To make it easier to deal with cases like this, I've had a
>> go at writing some macros to make copying function bodies
>> easier, while being robust for ARM and Thumb-2.
>
> How about instead providing some infrastructure which coes the
> copy too? ?Something like:
>
> #define copy_fn_to_sram(to, fn, size) ({ ? ? ? ? ? ? ? ?\
> ? ? ? ?__typeof__(fn) f; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> ? ? ? ?unsigned long ptr; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> ? ? ? ?__asm__("" : "=r" (ptr) : "0" (fn)); ? ? ? ? ? ?\
> ? ? ? ?memcpy(to, (void *)(ptr & ~1), size); ? ? ? ? ? \
> ? ? ? ?ptr = (ptr & 1) | (unsigned long)to; ? ? ? ? ? ?\
> ? ? ? ?__asm__("" : "=r" (f) : "0" (ptr)); ? ? ? ? ? ? \
> ? ? ? ?f; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> })
omap provides some infrastructure for both allocating SRAM space and
doing the copy, using omap_sram_push() and friends. So I wasn't sure
what the correct level of abstraction was for the new helpers.
Certainly, providing a sort of "function memcpy" macro like your
copy_fn_to_sram makes sense. I think this should still be safe from a
type system perspective: providing the "blind" type casts using asm()
appear somewhere in the execution flow C shouldn't make silly
assumptions even if Linux ends up enabling multifile optimisation
sometime in the future.
Would you agree with that assertion?
>
> Used by:
> extern void my_func(int foo);
> extern int my_func_size;
Potentially, we could define, an extra assembler macro to complement
ENDPROC() which records the size of a function automatically. What do
you think?
>
> void call_my_func(void *to, int arg)
> {
> ? ? ? ?void (*fn)(int);
>
> ? ? ? ?fn = copy_fn_to_sram(to, my_func, my_func_size);
> ? ? ? ?fn(arg);
> }
>
> Then if you need to fix the way the copies are done for some
> architectural reason, there's only one place to do it.
The model used in the omap code is to copy some functions into SRAM
ahead of time and stash the pointers away to be called later: for that
model, it's not so useful to have something like call_my_func
directly. Also, I wasn't sure whether conflating other functionality
such as cache flushing into the new macros would be a good idea -- is
might be cleaner and more maintainable, but might result in less
efficient usage. Any thoughts?
>
> I'm not sure asm/unified.h is the right place - I don't think this has
> anything to do with the unified assembler syntax. ?Please create a new
> header for this.
I suspected unified.h might not be right--- thanks for the feedback.
Cheers
---Dave
^ permalink raw reply
* [PATCH v4 08/10] ARM: mxs: add ocotp read function
From: Uwe Kleine-König @ 2011-01-12 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110112145036.GY12078@pengutronix.de>
Hello Sascha,
On Wed, Jan 12, 2011 at 03:50:36PM +0100, Sascha Hauer wrote:
> On Wed, Jan 12, 2011 at 02:47:12PM +0800, Shawn Guo wrote:
> > On Tue, Jan 11, 2011 at 02:31:37PM +0100, Sascha Hauer wrote:
> > > On Thu, Jan 06, 2011 at 03:13:16PM +0800, Shawn Guo wrote:
> > > > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > > > ---
> > > > Changes for v4:
> > > > - Call cpu_relax() during polling
> > > >
> > > > Changes for v2:
> > > > - Add mutex locking for mxs_read_ocotp()
> > > > - Use type size_t for count and i
> > > > - Add comment for clk_enable/disable skipping
> > > > - Add ERROR bit clearing and polling step
> > > >
> > > > arch/arm/mach-mxs/Makefile | 2 +-
> > > > arch/arm/mach-mxs/include/mach/common.h | 1 +
> > > > arch/arm/mach-mxs/ocotp.c | 79 +++++++++++++++++++++++++++++++
> > > > 3 files changed, 81 insertions(+), 1 deletions(-)
> > > > create mode 100644 arch/arm/mach-mxs/ocotp.c
> > > >
> > > > diff --git a/arch/arm/mach-mxs/Makefile b/arch/arm/mach-mxs/Makefile
> > > > index 39d3f9c..f23ebbd 100644
> > > > --- a/arch/arm/mach-mxs/Makefile
> > > > +++ b/arch/arm/mach-mxs/Makefile
> > > > @@ -1,5 +1,5 @@
> > > > # Common support
> > > > -obj-y := clock.o devices.o gpio.o icoll.o iomux.o system.o timer.o
> > > > +obj-y := clock.o devices.o gpio.o icoll.o iomux.o ocotp.o system.o timer.o
> > > >
> > > > obj-$(CONFIG_SOC_IMX23) += clock-mx23.o mm-mx23.o
> > > > obj-$(CONFIG_SOC_IMX28) += clock-mx28.o mm-mx28.o
> > > > diff --git a/arch/arm/mach-mxs/include/mach/common.h b/arch/arm/mach-mxs/include/mach/common.h
> > > > index 59133eb..cf02552 100644
> > > > --- a/arch/arm/mach-mxs/include/mach/common.h
> > > > +++ b/arch/arm/mach-mxs/include/mach/common.h
> > > > @@ -13,6 +13,7 @@
> > > >
> > > > struct clk;
> > > >
> > > > +extern int mxs_read_ocotp(int offset, int count, u32 *values);
> > > > extern int mxs_reset_block(void __iomem *);
> > > > extern void mxs_timer_init(struct clk *, int);
> > > >
> > > > diff --git a/arch/arm/mach-mxs/ocotp.c b/arch/arm/mach-mxs/ocotp.c
> > > > new file mode 100644
> > > > index 0000000..e2d39aa
> > > > --- /dev/null
> > > > +++ b/arch/arm/mach-mxs/ocotp.c
> > > > @@ -0,0 +1,79 @@
> > > > +/*
> > > > + * Copyright 2010 Freescale Semiconductor, Inc. All Rights Reserved.
> > > > + *
> > > > + * 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; either version 2 of the License, or
> > > > + * (at your option) any later version.
> > > > + *
> > > > + * This program is distributed in the hope that it will be useful,
> > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > > > + * GNU General Public License for more details.
> > > > + */
> > > > +
> > > > +#include <linux/delay.h>
> > > > +#include <linux/err.h>
> > > > +#include <linux/mutex.h>
> > > > +
> > > > +#include <mach/mxs.h>
> > > > +
> > > > +#define BM_OCOTP_CTRL_BUSY (1 << 8)
> > > > +#define BM_OCOTP_CTRL_ERROR (1 << 9)
> > > > +#define BM_OCOTP_CTRL_RD_BANK_OPEN (1 << 12)
> > > > +
> > > > +static DEFINE_MUTEX(ocotp_mutex);
> > > > +
> > > > +int mxs_read_ocotp(unsigned offset, size_t count, u32 *values)
> > > > +{
> > > > + void __iomem *ocotp_base = MXS_IO_ADDRESS(MXS_OCOTP_BASE_ADDR);
> > > > + int timeout = 0x400;
> > > > + size_t i;
> > > > +
> > > > + mutex_lock(&ocotp_mutex);
> > > > +
> > > > + /*
> > > > + * clk_enable(hbus_clk) for ocotp can be skipped
> > > > + * as it must be on when system is running.
> > > > + */
> > > > +
> > > > + /* try to clear ERROR bit */
> > > > + __mxs_clrl(BM_OCOTP_CTRL_ERROR, ocotp_base);
> > >
> > > This operation does not try to clear the error bit but actually clears
> > > it...
> > >
> > > > +
> > > > + /* check both BUSY and ERROR cleared */
> > > > + while ((__raw_readl(ocotp_base) &
> > > > + (BM_OCOTP_CTRL_BUSY | BM_OCOTP_CTRL_ERROR)) && --timeout)
> > > > + cpu_relax();
> > >
> > > ...which means you do not have to poll the error bit here...
> > >
> > > > +
> > > > + if (unlikely(!timeout))
> > > > + goto error_unlock;
> > > > +
> > > > + /* open OCOTP banks for read */
> > > > + __mxs_setl(BM_OCOTP_CTRL_RD_BANK_OPEN, ocotp_base);
> > > > +
> > > > + /* approximately wait 32 hclk cycles */
> > > > + udelay(1);
> > > > +
> > > > + /* poll BUSY bit becoming cleared */
> > > > + timeout = 0x400;
> > > > + while ((__raw_readl(ocotp_base) & BM_OCOTP_CTRL_BUSY) && --timeout)
> > > > + cpu_relax();
> > >
> > > ...which means you can factor out a ocotp_wait_busy function and let the
> > > code speak instead of the comments.
> > >
> > > > +
> > > > + if (unlikely(!timeout))
> > > > + goto error_unlock;
> > > > +
> > > > + for (i = 0; i < count; i++, offset += 4)
> > > > + *values++ = __raw_readl(ocotp_base + offset);
> > >
> > > The registers in the ocotp are 16 byte aligned. Does it really make
> > > sense to provide a function allowing to read the gaps between the
> > > registers?
> > >
> > Good catch. The count was added to ease the consecutive otp word
> > reading, as there is bank open/close cost for otp read. What about
> > the following changes?
> >
> > int mxs_read_ocotp(unsigned offset, size_t otp_word_cnt, u32 *values)
> > {
> > ......
> >
> > for (i = 0; i < otp_word_cnt; i++, offset += 0x10)
> > *values++ = __raw_readl(ocotp_base + offset);
> >
> > ......
> > }
>
> I would rather make a function like this:
>
> static u32 ocotp[0x27];
>
> const u32 *mxs_get_ocotp(void)
> {
> static int once = 0;
>
> if (once)
> return ocotp
>
> /* bank open */
>
> for (i = 0; i < 0x27; i++)
> ocotp[i] = readl(ocotp_base + 0x20 + i * 0x10)
>
> /* bank_close */
>
> once = 1;
>
> return ocotp;
which is save on UP when it's not called from irq context.
Additionally I suggest a #define for 0x27 and 0x20.
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* ARM: relocation out of range (when loading a module)
From: Dave Martin @ 2011-01-12 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D2D1942.4050905@ahsoftware.de>
On Tue, Jan 11, 2011 at 9:00 PM, Alexander Holler <holler@ahsoftware.de> wrote:
> Hello,
[...]
> ? ? ? ? ? ? ? ?INIT_CALLS
> ? ? ? ? ? ? ? ?CON_INITCALL
> ? ? ? ? ? ? ? ?SECURITY_INITCALL
> + ? ? ? ? ? ? ? /*
> + ? ? ? ? ? ? ? ?* TODO: The size of INIT_RAM_FS could easily reach a
> + ? ? ? ? ? ? ? ?* point (~16MB) when loading modules will fail because
> + ? ? ? ? ? ? ? ?* relocations will be out of range. So this place here
> + ? ? ? ? ? ? ? ?* isn't the best one.
> + ? ? ? ? ? ? ? ?*/
> ? ? ? ? ? ? ? ?INIT_RAM_FS
In general, do we expect always to be able to avoid the situation
where branches in the kernel may need to cover too large a range ...
and is there any strategy for working aroung it?
If we have problems branching from the modules area into vmlinux, we
could possibly build modules with -fPIC : this would remove the
restriction on branch range, though there would also be some
performance impact for the modules...
Cheers
---Dave
^ permalink raw reply
* [PATCH 0/0] RFC: ARM: Thumb-2: Symbol manipulation macros for function body copying
From: Russell King - ARM Linux @ 2011-01-12 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimB1dcK=F1bFh6bUtBPY0gk+Y+Y0SQqrSRW0YFa@mail.gmail.com>
On Wed, Jan 12, 2011 at 10:00:25AM -0600, Dave Martin wrote:
> omap provides some infrastructure for both allocating SRAM space and
> doing the copy, using omap_sram_push() and friends. So I wasn't sure
> what the correct level of abstraction was for the new helpers.
> Certainly, providing a sort of "function memcpy" macro like your
> copy_fn_to_sram makes sense.
It'd just be a matter of splitting the copying out of omap_sram_push().
> I think this should still be safe from a type system perspective:
> providing the "blind" type casts using asm() appear somewhere in
> the execution flow C shouldn't make silly assumptions even if Linux
> ends up enabling multifile optimisation sometime in the future.
Yes. The only thing that is missing from my version is the
flush_icache_range() which should also be there.
> > Used by:
> > extern void my_func(int foo);
> > extern int my_func_size;
>
> Potentially, we could define, an extra assembler macro to complement
> ENDPROC() which records the size of a function automatically. What do
> you think?
That would pad the code out with a fair number of additional integers.
That's probably not a good idea.
> The model used in the omap code is to copy some functions into SRAM
> ahead of time and stash the pointers away to be called later: for that
> model, it's not so useful to have something like call_my_func
> directly. Also, I wasn't sure whether conflating other functionality
> such as cache flushing into the new macros would be a good idea -- is
> might be cleaner and more maintainable, but might result in less
> efficient usage. Any thoughts?
My example was only that - an example. You can also use it in the
way you describe too:
to = omap_sram_push(size);
_omap_sram_reprogram_clock = copy_fn_to_sram(to,
omap1_sram_reprogram_clock, size);
and it'll also ensure type-safety between the omap1_sram_reprogram_clock
and _omap_sram_reprogram_clock symbols, which the current code doesn't
do.
^ 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