* [RFC] MMC: error handling improvements
From: Linus Walleij @ 2011-02-21 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTin7UaKPgvmPC0+cJf5nBWuUmuUreAjDZxQGNB2j@mail.gmail.com>
Out of sheer curiosity, Qualcomm/CodeAurora guys:
if you dump out the registers at offset 0xfe0-0xfff on the
SDCC, does it contain a valid PrimeCell ID? Anyone who
can make a hexdump of it?
It is possible to hardcode an AMBA ID to use this driver
even if this area is just 0x0000... but I'm just curious
about how different silicon vendors treat these registers,
e.g. if they contain something sensible.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/2] DM9000B: Fix PHY power for network down/up
From: Henry Nestler @ 2011-02-21 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D62491F.4050602@ru.mvista.com>
On 21.02.2011 12:14, Sergei Shtylyov wrote:
> On 21-02-2011 0:45, Henry Nestler wrote:
>
>> DM9000 revision B needs 1 ms delay after PHY power on (see spec), and PHY
>> power must on in register
>
> Couldn't parse that.
This can read in manual DM900B-12-DS-F02 from September 2 2010, Page 14:
"If this Register 1FH bit 0 is updated from '1' to '0', the all
Registers can not be accessed within 1ms."
The example driver code waits 2 ms.
>> diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
>> index 2d4c4fc..5925569 100644
>> --- a/drivers/net/dm9000.c
>> +++ b/drivers/net/dm9000.c
> [...]
>> @@ -1194,6 +1191,10 @@ dm9000_open(struct net_device *dev)
>> if (request_irq(dev->irq, dm9000_interrupt, irqflags, dev->name, dev))
>> return -EAGAIN;
>>
>> + /* GPIO0 on pre-activate PHY, Reg 1F is not set by reset */
>> + iow(db, DM9000_GPR, 0); /* REG_1F bit0 activate phyxcer */
>> + udelay(1000); /* delay needs by DM9000B */
>
> Why not mdelay(1)?
Because udelay is the base of mdelay.
See include/linux/delay.h:31
#define mdelay(n) ... udelay((n)*1000)
--
Henry N.
^ permalink raw reply
* CLOCK_TICK_RATE, was: Re: [PATCH V4 3/4] ARM: Xilinx: base header files and assembly macros
From: Arnd Bergmann @ 2011-02-21 21:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110221151752.GR14495@n2100.arm.linux.org.uk>
On Monday 21 February 2011, Russell King - ARM Linux wrote:
> 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.
All the calculations based off of CLOCK_TICK_RATE are derived from ACTHZ,
which is either the correct value based on the underlying HW timer tick,
or slightly off, when either the HW tick or the value of CLOCK_TICK_RATE
is not a true multiple of HZ.
In fact, I'm pretty sure that it's off on a lot of machines:
arch/frv/include/asm/timex.h:#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
arch/m68k/include/asm/timex.h:#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
arch/mips/include/asm/timex.h:#define CLOCK_TICK_RATE 1193182
arch/parisc/include/asm/timex.h:#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
arch/s390/include/asm/timex.h:#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
arch/sh/include/asm/timex.h:#define CLOCK_TICK_RATE 1193180
arch/x86/include/asm/timex.h:#define CLOCK_TICK_RATE PIT_TICK_RATE
arch/xtensa/include/asm/timex.h:#define CLOCK_TICK_RATE 1193180 /* (everyone is using this value) */
None of these is actually using a PC-style PIT these days, the just copied the
definition blindly from old i386. I think a simple
#define ACTHZ (HZ << 8)
would fix more than it can break, and most likely nobody would ever notice
the difference. If we do that, CLOCK_TICK_RATE becomes unused.
Arnd
^ permalink raw reply
* [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
From: David Cohen @ 2011-02-21 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikbjZ7GH7+bx94r6saYuGzCt9aito-Y8NS94SoQ@mail.gmail.com>
On Mon, Feb 21, 2011 at 8:43 PM, Ramirez Luna, Omar <omar.ramirez@ti.com> wrote:
> Hi,
Hi,
Thanks for the comments.
>
> On Wed, Feb 16, 2011 at 1:35 PM, David Cohen <dacohen@gmail.com> wrote:
>> diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
>> index 49a1e5e..adb083e 100644
>> --- a/arch/arm/mach-omap2/iommu2.c
>> +++ b/arch/arm/mach-omap2/iommu2.c
> ...
>>
>> ? ? ? ?da = iommu_read_reg(obj, MMU_FAULT_AD);
>> ? ? ? ?*ra = da;
>>
>> + ? ? ? if (stat & MMU_IRQ_TLBMISS)
>> + ? ? ? ? ? ? ? errs |= OMAP_IOMMU_ERR_TLB_MISS;
>> + ? ? ? if (stat & MMU_IRQ_TRANSLATIONFAULT)
>> + ? ? ? ? ? ? ? errs |= OMAP_IOMMU_ERR_TRANS_FAULT;
>> + ? ? ? if (stat & MMU_IRQ_EMUMISS)
>> + ? ? ? ? ? ? ? errs |= OMAP_IOMMU_ERR_EMU_MISS;
>> + ? ? ? if (stat & MMU_IRQ_TABLEWALKFAULT)
>> + ? ? ? ? ? ? ? errs |= OMAP_IOMMU_ERR_TBLWALK_FAULT;
>> + ? ? ? if (stat & MMU_IRQ_MULTIHITFAULT)
>> + ? ? ? ? ? ? ? errs |= OMAP_IOMMU_ERR_MULTIHIT_FAULT;
>
> I still don't think this adds any value, "generic layer" and omap
> errors are the same thing in this case... OTOH OMAP 1710 (not
> supported by iommu yet) has the following bits:
>
> 3 Prefetch_err
> 2 Perm_fault
> 1 Tlb_miss
> 0 Trans_fault
>
> They don't match any of your "generic layer errors" masks for reading,
Have you noticed:
0 = OMAP_IOMMU_ERR_TRANS_FAULT
1 = OMAP_IOMMU_ERR_TLB_MISS
2 and 3 could be added.
> hence more generic errors will need to be defined, and then more OMAP#
> masks... I think we just need to stick with the mach specific errors,
> and let mach code handle its specifics when reporting.
How many are we talking about? I don't think every new OMAP version it
would completely re-invent IOMMU faults.
Generic errors codes make easier to threat possible IOMMU users which
have (partially or totally) common drivers for different OMAP
versions.
Unless it's really an out-of-control number of generic faults, I don't
see it as a real problem.
>
> But anyway it is just me...
>
>> diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
>> index f55f458..b0e0efc 100644
>> --- a/arch/arm/plat-omap/iommu.c
>> +++ b/arch/arm/plat-omap/iommu.c
>> @@ -780,25 +780,19 @@ static void iopgtable_clear_entry_all(struct iommu *obj)
>> ?*/
>> ?static irqreturn_t iommu_fault_handler(int irq, void *data)
>> ?{
>> - ? ? ? u32 stat, da;
>> + ? ? ? u32 da, errs;
>> ? ? ? ?u32 *iopgd, *iopte;
>> - ? ? ? int err = -EIO;
>> ? ? ? ?struct iommu *obj = data;
>>
>> ? ? ? ?if (!obj->refcount)
>> ? ? ? ? ? ? ? ?return IRQ_NONE;
>>
>> - ? ? ? /* Dynamic loading TLB or PTE */
>> - ? ? ? if (obj->isr)
>> - ? ? ? ? ? ? ? err = obj->isr(obj);
>> -
>> - ? ? ? if (!err)
>> - ? ? ? ? ? ? ? return IRQ_HANDLED;
>> -
>> ? ? ? ?clk_enable(obj->clk);
>> - ? ? ? stat = iommu_report_fault(obj, &da);
>> + ? ? ? errs = iommu_report_fault(obj, &da);
>> ? ? ? ?clk_disable(obj->clk);
>> - ? ? ? if (!stat)
>> +
>> + ? ? ? /* Fault callback or TLB/PTE Dynamic loading */
>> + ? ? ? if (obj->isr && !obj->isr(obj, da, errs, obj->isr_priv))
>> ? ? ? ? ? ? ? ?return IRQ_HANDLED;
>
> BTW, why not changing the name isr for cb, it is confusing since there
> is another fault_isr called by mmu, AFAIK nobody uses obj->isr
The main purpose of this function is to be an ISR, not only callback.
But as you noticed, nobody is using it yet, but OMAP3 ISP should start
to use it soon.
>
>> ? ? ? ?iommu_disable(obj);
>> @@ -806,15 +800,16 @@ static irqreturn_t iommu_fault_handler(int irq, void *data)
>> ? ? ? ?iopgd = iopgd_offset(obj, da);
>>
>> ? ? ? ?if (!iopgd_is_table(*iopgd)) {
>> - ? ? ? ? ? ? ? dev_err(obj->dev, "%s: da:%08x pgd:%p *pgd:%08x\n", obj->name,
>> - ? ? ? ? ? ? ? ? ? ? ? da, iopgd, *iopgd);
>> + ? ? ? ? ? ? ? dev_err(obj->dev, "%s: errs:0x%08x da:0x%08x pgd:0x%p "
>> + ? ? ? ? ? ? ? ? ? ? ? "*pgd:px%08x\n", obj->name, errs, da, iopgd, *iopgd);
>> ? ? ? ? ? ? ? ?return IRQ_NONE;
>> ? ? ? ?}
>>
>> ? ? ? ?iopte = iopte_offset(iopgd, da);
>>
>> - ? ? ? dev_err(obj->dev, "%s: da:%08x pgd:%p *pgd:%08x pte:%p *pte:%08x\n",
>> - ? ? ? ? ? ? ? obj->name, da, iopgd, *iopgd, iopte, *iopte);
>> + ? ? ? dev_err(obj->dev, "%s: errs:0x%08x da:0x%08x pgd:0x%p *pgd:0x%08x "
>> + ? ? ? ? ? ? ? "pte:0x%p *pte:0x%08x\n", obj->name, errs, da, iopgd, *iopgd,
>> + ? ? ? ? ? ? ? iopte, *iopte);
>>
>> ? ? ? ?return IRQ_NONE;
>> ?}
>> @@ -917,6 +912,33 @@ void iommu_put(struct iommu *obj)
>> ?}
>> ?EXPORT_SYMBOL_GPL(iommu_put);
>>
>> +int iommu_set_isr(const char *name,
>> + ? ? ? ? ? ? ? ? int (*isr)(struct iommu *obj, u32 da, u32 iommu_errs,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?void *priv),
>> + ? ? ? ? ? ? ? ? void *isr_priv)
>
> So I think the following will be bad practice:
>
> ? ? ? ?mmu = iommu_get("iva2");
> ? ? ? ?if (!IS_ERR(mmu))
> ? ? ? ? ? ? ? ?mmu->isr = mmu_fault_callback;
>
> Shall we think anything to prevent such mis-usage?
Well, the IOMMU user has access to IOMMU obj, so it can not only
change the (*isr)() but to mess with a lot of other stuff. The only
way to prevent it is to avoid user to have obj. But then, this fix (or
issue) does not belong to this patch.
Br,
David
>
> Regards,
>
> Omar
>
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Cousson, Benoit @ 2011-02-21 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110221182213.GD15225@atomide.com>
On 2/21/2011 7:22 PM, Tony Lindgren wrote:
> * Cousson, Benoit<b-cousson@ti.com> [110218 08:49]:
>> ---
>> From b2190f0d339c9d843eb5e370d0db8b7090fbcfab Mon Sep 17 00:00:00 2001
>> From: Benoit Cousson<b-cousson@ti.com>
>> Date: Fri, 18 Feb 2011 14:01:06 +0100
>> Subject: [PATCH] OMAP4: hwmod data: Add rev and dev_attr fields in McSPI
>>
>> - Add a rev attribute to identify various McSPI IP version.
>> - Add a dev_attr structure to provide the number of chipselect
>> supported by the instance.
>
> Looks like one seems to be wrapped and does not apply even after unwapping..
#$*%&!@ Thunderbird...
Here is the same one without the "enable word wrap" and attached as well just in case.
It should apply on your omap-for-linus branch at commit df7ffd3.
Regards,
Benoit
---
^ permalink raw reply
* CLOCK_TICK_RATE, was: Re: [PATCH V4 3/4] ARM: Xilinx: base header files and assembly macros
From: Thomas Gleixner @ 2011-02-21 21:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102212208.10231.arnd@arndb.de>
On Mon, 21 Feb 2011, Arnd Bergmann wrote:
> On Monday 21 February 2011, Russell King - ARM Linux wrote:
> > 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.
>
> All the calculations based off of CLOCK_TICK_RATE are derived from ACTHZ,
> which is either the correct value based on the underlying HW timer tick,
> or slightly off, when either the HW tick or the value of CLOCK_TICK_RATE
> is not a true multiple of HZ.
>
> In fact, I'm pretty sure that it's off on a lot of machines:
>
> arch/frv/include/asm/timex.h:#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
> arch/m68k/include/asm/timex.h:#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
> arch/mips/include/asm/timex.h:#define CLOCK_TICK_RATE 1193182
> arch/parisc/include/asm/timex.h:#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
> arch/s390/include/asm/timex.h:#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
> arch/sh/include/asm/timex.h:#define CLOCK_TICK_RATE 1193180
> arch/x86/include/asm/timex.h:#define CLOCK_TICK_RATE PIT_TICK_RATE
> arch/xtensa/include/asm/timex.h:#define CLOCK_TICK_RATE 1193180 /* (everyone is using this value) */
>
> None of these is actually using a PC-style PIT these days, the just copied the
> definition blindly from old i386. I think a simple
>
> #define ACTHZ (HZ << 8)
>
> would fix more than it can break, and most likely nobody would ever notice
> the difference. If we do that, CLOCK_TICK_RATE becomes unused.
Indeed.
tglx
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Tony Lindgren @ 2011-02-21 22:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D62DAF0.9050301@ti.com>
* Cousson, Benoit <b-cousson@ti.com> [110221 13:35]:
> On 2/21/2011 7:22 PM, Tony Lindgren wrote:
> >* Cousson, Benoit<b-cousson@ti.com> [110218 08:49]:
> >>---
> >> From b2190f0d339c9d843eb5e370d0db8b7090fbcfab Mon Sep 17 00:00:00 2001
> >>From: Benoit Cousson<b-cousson@ti.com>
> >>Date: Fri, 18 Feb 2011 14:01:06 +0100
> >>Subject: [PATCH] OMAP4: hwmod data: Add rev and dev_attr fields in McSPI
> >>
> >>- Add a rev attribute to identify various McSPI IP version.
> >>- Add a dev_attr structure to provide the number of chipselect
> >> supported by the instance.
> >
> >Looks like one seems to be wrapped and does not apply even after unwapping..
>
> #$*%&!@ Thunderbird...
:) The earlier one had double spaces in the beginning of each line in
addition to the line wrapping..
> Here is the same one without the "enable word wrap" and attached as well just in case.
>
> It should apply on your omap-for-linus branch at commit df7ffd3.
Thanks, I'll apply it to omap-for-linus. The omap4 hang seems to be
caused by the timer patch, the following fixes it. How do you want
to deal with fixing this issue?
Tony
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5094,7 +5094,7 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
&omap44xx_spinlock_hwmod,
/* timer class */
- &omap44xx_timer1_hwmod,
+/* &omap44xx_timer1_hwmod, */
&omap44xx_timer2_hwmod,
&omap44xx_timer3_hwmod,
&omap44xx_timer4_hwmod,
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Cousson, Benoit @ 2011-02-21 22:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110221220815.GG15225@atomide.com>
On 2/21/2011 11:08 PM, Tony Lindgren wrote:
> * Cousson, Benoit<b-cousson@ti.com> [110221 13:35]:
>> On 2/21/2011 7:22 PM, Tony Lindgren wrote:
>>> * Cousson, Benoit<b-cousson@ti.com> [110218 08:49]:
>>>> ---
>>>> From b2190f0d339c9d843eb5e370d0db8b7090fbcfab Mon Sep 17 00:00:00 2001
>>>> From: Benoit Cousson<b-cousson@ti.com>
>>>> Date: Fri, 18 Feb 2011 14:01:06 +0100
>>>> Subject: [PATCH] OMAP4: hwmod data: Add rev and dev_attr fields in McSPI
>>>>
>>>> - Add a rev attribute to identify various McSPI IP version.
>>>> - Add a dev_attr structure to provide the number of chipselect
>>>> supported by the instance.
>>>
>>> Looks like one seems to be wrapped and does not apply even after unwapping..
>>
>> #$*%&!@ Thunderbird...
>
> :) The earlier one had double spaces in the beginning of each line in
> addition to the line wrapping..
...The Thunderbird wrapping option is more powerful than expected...
>> Here is the same one without the "enable word wrap" and attached as well just in case.
>>
>> It should apply on your omap-for-linus branch at commit df7ffd3.
>
> Thanks, I'll apply it to omap-for-linus. The omap4 hang seems to be
> caused by the timer patch, the following fixes it. How do you want
> to deal with fixing this issue?
I guess it is due to the early_init change?
I have some concern bypassing hwmod to handle system timer. The idea,
before the introduction of the early_init, was to use hwmod for early
initialization as well including timers. It will become a little bit
harder now :-(
I still didn't fully understand the rational behind that early_init for
timer BTW.
Meanwhile, the following will just prevent the fmwk to reset and idle
the timer during hwmod_init.
Regards,
Benoit
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -3989,6 +3989,7 @@ static struct omap_hwmod_ocp_if
*omap44xx_timer1_slaves[] = {
static struct omap_hwmod omap44xx_timer1_hwmod = {
.name = "timer1",
.class = &omap44xx_timer_1ms_hwmod_class,
+ .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
.mpu_irqs = omap44xx_timer1_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_timer1_irqs),
.main_clk = "timer1_fck",
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Tony Lindgren @ 2011-02-21 23:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D62ECCC.3040208@ti.com>
* Cousson, Benoit <b-cousson@ti.com> [110221 14:51]:
> On 2/21/2011 11:08 PM, Tony Lindgren wrote:
> >
> >Thanks, I'll apply it to omap-for-linus. The omap4 hang seems to be
> >caused by the timer patch, the following fixes it. How do you want
> >to deal with fixing this issue?
>
> I guess it is due to the early_init change?
Yes that seems to be the case.
> I have some concern bypassing hwmod to handle system timer. The
> idea, before the introduction of the early_init, was to use hwmod
> for early initialization as well including timers. It will become a
> little bit harder now :-(
If we get rid of the system timer dependency to hwmod we can
pretty much initialize everything later on and don't need to
use early_init stuff at all.
> I still didn't fully understand the rational behind that early_init
> for timer BTW.
I'm currently thinking that we should just have omap[234]_init_timer
functions that do not depend on hwmod at all.
> Meanwhile, the following will just prevent the fmwk to reset and
> idle the timer during hwmod_init.
That seems like a good to fix for now until the hwmod timer
changes are sorted out.
Tony
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -3989,6 +3989,7 @@ static struct omap_hwmod_ocp_if
> *omap44xx_timer1_slaves[] = {
> static struct omap_hwmod omap44xx_timer1_hwmod = {
> .name = "timer1",
> .class = &omap44xx_timer_1ms_hwmod_class,
> + .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
> .mpu_irqs = omap44xx_timer1_irqs,
> .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_timer1_irqs),
> .main_clk = "timer1_fck",
>
^ permalink raw reply
* [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
From: Ramirez Luna, Omar @ 2011-02-21 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=rJZo2KwryYznFp6Qq25Oh0+F44OKV-khuQyte@mail.gmail.com>
Hi,
On Mon, Feb 21, 2011 at 3:12 PM, David Cohen <dacohen@gmail.com> wrote:
> Generic errors codes make easier to threat possible IOMMU users which
> have (partially or totally) common drivers for different OMAP
> versions.
Agree then.
>>> + ? ? ? /* Fault callback or TLB/PTE Dynamic loading */
>>> + ? ? ? if (obj->isr && !obj->isr(obj, da, errs, obj->isr_priv))
>>> ? ? ? ? ? ? ? ?return IRQ_HANDLED;
>>
>> BTW, why not changing the name isr for cb, it is confusing since there
>> is another fault_isr called by mmu, AFAIK nobody uses obj->isr
>
> The main purpose of this function is to be an ISR, not only callback.
Yep, I just thought it was a bit too much of:
(1) The real isr: iommu_fault_handler, set on request_irq
(2) A plugged fault_isr for mach specific code: omap2_iommu_fault_isr,
for error reporting.
(3) And then a plugged custom isr, to be set by the user.
Feel free to ignore.
>> So I think the following will be bad practice:
>>
>> ? ? ? ?mmu = iommu_get("iva2");
>> ? ? ? ?if (!IS_ERR(mmu))
>> ? ? ? ? ? ? ? ?mmu->isr = mmu_fault_callback;
>>
>> Shall we think anything to prevent such mis-usage?
>
> Well, the IOMMU user has access to IOMMU obj, so it can not only
> change the (*isr)() but to mess with a lot of other stuff. The only
> way to prevent it is to avoid user to have obj. But then, this fix (or
> issue) does not belong to this patch.
Agree, just pointing out.
Regards,
Omar
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Russell King - ARM Linux @ 2011-02-21 23:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D62ECCC.3040208@ti.com>
On Mon, Feb 21, 2011 at 11:53:00PM +0100, Cousson, Benoit wrote:
> I still didn't fully understand the rational behind that early_init for
> timer BTW.
To ensure that sched_clock() is setup and running before its first use.
^ permalink raw reply
* [PATCH 2/2] clk: Generic support for fixed-rate clocks
From: Jeremy Kerr @ 2011-02-21 23:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D62C237.1020803@bluewatersys.com>
Hi Ryan,
> If we never need to dynamically create fixed clocks (which seems
> unlikely) then rate can be const.
There's been a few cases where I've needed to set the rate of a fixed clock
during boot - for example when a clock rate varies between boards, it may be
defined in a platform-wide file, but have the rate modified early (ie,
clk_foo.rate = 32678) in a board file.
Also, if we're parsing clocks from the device tree (or any other discovery
mechanism), we'll need to modify rate.
Cheers,
Jeremy
^ permalink raw reply
* [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
From: David Cohen @ 2011-02-21 23:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=ETUza9vYLxucB4hs-7x9+tDTY8mxUPziWvnig@mail.gmail.com>
On Tue, Feb 22, 2011 at 1:25 AM, Ramirez Luna, Omar <omar.ramirez@ti.com> wrote:
> Hi,
>
> On Mon, Feb 21, 2011 at 3:12 PM, David Cohen <dacohen@gmail.com> wrote:
>> Generic errors codes make easier to threat possible IOMMU users which
>> have (partially or totally) common drivers for different OMAP
>> versions.
>
> Agree then.
Good we agreed on that.
>
>>>> + ? ? ? /* Fault callback or TLB/PTE Dynamic loading */
>>>> + ? ? ? if (obj->isr && !obj->isr(obj, da, errs, obj->isr_priv))
>>>> ? ? ? ? ? ? ? ?return IRQ_HANDLED;
>>>
>>> BTW, why not changing the name isr for cb, it is confusing since there
>>> is another fault_isr called by mmu, AFAIK nobody uses obj->isr
>>
>> The main purpose of this function is to be an ISR, not only callback.
>
> Yep, I just thought it was a bit too much of:
> (1) The real isr: iommu_fault_handler, set on request_irq
> (2) A plugged fault_isr for mach specific code: omap2_iommu_fault_isr,
> for error reporting.
> (3) And then a plugged custom isr, to be set by the user.
>
> Feel free to ignore.
(1) does nothing but to call (2) and then (3) if it exists and print
error message.
(2) as you said, it's mach specific and necessary for the generic upper layer.
(3) does what the IOMMU user wants and may replace (1) if it returns 0.
They belong to different layers and should coexist.
>
>>> So I think the following will be bad practice:
>>>
>>> ? ? ? ?mmu = iommu_get("iva2");
>>> ? ? ? ?if (!IS_ERR(mmu))
>>> ? ? ? ? ? ? ? ?mmu->isr = mmu_fault_callback;
>>>
>>> Shall we think anything to prevent such mis-usage?
>>
>> Well, the IOMMU user has access to IOMMU obj, so it can not only
>> change the (*isr)() but to mess with a lot of other stuff. The only
>> way to prevent it is to avoid user to have obj. But then, this fix (or
>> issue) does not belong to this patch.
>
> Agree, just pointing out.
That's a valid point, but it requires an intrusive approach to prevent
such mis-usage. For now we must trust the user won't mess with obj.
Br,
David
>
> Regards,
>
> Omar
>
^ permalink raw reply
* Help - Getting started
From: Bjørn Forsman @ 2011-02-21 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinkuOmh8dw=+Y_a-eK48rVqYBgcFEyxdprJxXnE@mail.gmail.com>
Hi,
On 12 February 2011 11:27, Daniel F. Pigatto <dhannyel@gmail.com> wrote:
> Hi everybody,
>
> I am very beginner in embedded systems, and I really need your help. I guess
> it will not be too difficult for you, who already work with ARM processors.
>
> I have bought the following kit which includes an ARM processor with a video
> module and some other peripherals:
>
> http://www.gumstix.com/store/catalog/product_info.php?products_id=253
>
> Then, obviously, I need to install an operating system in order to be able
> to run some cryptographic algorithms and evaluate some behaviours of this
> hardware. I chose Linux ARM, because Linux is a very well-known system,
> which is also very trustable.
>
> My doubts are about how to get started installing the OS. Is there any
> tutorial or something that I could read to start installing? Is it a
> difficult way that I will probably face?
>
> I do need a help to get started. Just this.
>
> Thank you very much!
I think this is a good starting point for the Overo:
http://www.gumstix.net/Setup-and-Programming/cat/Overo-Setup-and-Programming/111.html
Best regards,
Bj?rn Forsman
^ permalink raw reply
* DreamPlug
From: Alexander Clouter @ 2011-02-21 23:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C838F4BE-BF4D-43BE-BF1C-137526C4BDC2@kimandjk.com>
JK Scheinberg <jk@kimandjk.com> wrote:
>
> I received my DreamPlug a few days ago. It's up running what it came
> with and I'd like to help get full Squeeze running on it.
>
<shameless-self-promo>
http://www.digriz.org.uk/kirkwood
</shameless-self-promo>
Does not answer the 'kernel' question though.
> * JK Scheinberg <jk@kimandjk.com> [2011-02-11 11:47]:
>
>>> also, i see they both have exactly the same processor or SOC if it's
>>> called that. if this is merely a repackaging then unless some of
>>> the devices (enet etc) have changed won't the exact same debian
>>> kirkwood dist install and work on this?
>>
>> It's the same SoC, but it probably has different devices and maybe
>> some of the GPIOs are different.
>>
>> I don't know anything about the DreamPlug. Do you know if technical
>> specs are available online?
>>
The Globalscale website implies that the NAND is a bit larger
and uboot boots off some separate NOR flash.
http://www.globalscaletechnologies.com/t-dreamplugdetails.aspx
>> What needs to be done is to write a support file for the DreamPlug,
>> look at sheevaplug-setup.c and guruplug-setup.c here for an example:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=arch/arm/mach-kirkwood;h=222c4a61519a225b2444678a72a6d66edbd1727a;hb=HEAD
>
Boot the DreamPlug and take a copy of the full kernel booting log. Copy
the sheevaplug-setup.c code, strip out *everything* except for the
Serial, NAND[1] and Ethernet ports sections and start from there.
Do prod me off list if you need help.
Cheers
[1] match up the size and partition table to whatever the layout looks
like for the existing installation
--
Alexander Clouter
.sigmonster says: You will win success in whatever calling you adopt.
^ permalink raw reply
* [PATCH] ARM: pxa: support 806MHz operating points for PXA31x processors A2 stepping
From: Axel Lin @ 2011-02-22 1:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D5AB09C.9000106@compulab.co.il>
Hi Igor,
> Also, there is one thing that is not related to this patch, but
> if you have the hardware, you need to be concerned with,
> is that the vcc_core voltage has to be 1.4V, otherwise your
> hardware will be unstable.
I don't see any unstable issue on my device.
But it seems the vcc_core and vcc_sram fields of pxa3xx_freq_info
are not used now.
Regards,
Axel
^ permalink raw reply
* [PATCH 2/5] ARM: imx51/53: add sdhc3/4 clock
From: Richard Zhao @ 2011-02-22 2:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110221162154.GR24426@pengutronix.de>
Hi Sascha,
On Mon, Feb 21, 2011 at 05:21:54PM +0100, Sascha Hauer wrote:
> 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.
I can add a check here, but it will not share the same function between mx51
and mx53. for mx51, partents can be sdhc1_clk and sdhc2_clk, but for mx53, it
can be sdhc1_clk and sdhc3_clk.
>
> > + __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.
ok.
Thanks
Richard
>
> 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 5/5] mmc: sdhci: add quirk SDHCI_QUIRK_FIX_NO_INT_IN_MULTI_BLK_IO
From: Zhu Richard-R65037 @ 2011-02-22 2:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110221111557.GG2616@pengutronix.de>
Hi Wolfsang:
Maybe I don't describe my thoughts clearly and exactly.
I feel it's not easy to add the the IO-accessors in every cmd execution procedure, to make
a double check why a IO-accessor is needed or not.
Best Regards
Richard Zhu
> -----Original Message-----
> From: Wolfram Sang [mailto:w.sang at pengutronix.de]
> Sent: Monday, February 21, 2011 7:16 PM
> To: Russell King - ARM Linux
> Cc: Zhu Richard-R65037; Zhao Richard-B20223; cjb at laptop.org;
> eric at eukrea.com; linux-mmc at vger.kernel.org; kernel at pengutronix.de;
> avorontsov at ru.mvista.com; linux-arm-kernel at lists.infradead.org;
> linuxzsc at gmail.com
> Subject: Re: [PATCH 5/5] mmc: sdhci: add quirk
> SDHCI_QUIRK_FIX_NO_INT_IN_MULTI_BLK_IO
>
> On Mon, Feb 21, 2011 at 11:09:05AM +0000, Russell King - ARM Linux wrote:
> > On Mon, Feb 21, 2011 at 11:46:08AM +0100, Wolfram Sang wrote:
> > > > > > - if (cpu_is_mx35() || cpu_is_mx51())
> > > > > > + if (cpu_is_mx53())
> > > > > > + host->quirks |=
> > > > > > + SDHCI_QUIRK_FIX_NO_INT_IN_MULTI_BLK_IO;
> > > > >
> > > > > Have you tried it doing it via IO-accessors?
> > > > Richard Zhu: This quirk is used to fix a mechanism problem in the
> MMC CMDs execution procedure.
> > > > It would be very abrupt and ugly, if the IO-accessors are added
> into these original procedures.
> > >
> > > Please don't get it personal, but IMHO it is pretty ugly the way it
> > > is now. This quirk is very imx-specific and calling something like
> > > SDHCI_VENDOR_SPEC in sdhci.c looks clearly wrong to me. By the way,
> > > what does this bit do, the description doesn't say so?
> >
> > SDHCI_QUIRK_FIX_NO_INT_IN_MULTI_BLK_IO is rather too verbose. Isn't
> > there a shorter version which could be used?
> > SDHCI_QUIRK_SDIO_MULTIBLK_INT maybe?
>
> As I understand, the non-SDIO part is handled here:
Yes, it is. The following codes are used to solve non-sdio part.
That bit is introduced by imx53 latest spec.
I think so too that the SDHCI_VENDOR_SPEC shouldn't be used in sdhci.c file, but
I don't have better idea to fix the issue in this situation.
Option:
Make a double check when issue every MMC CMD, to figure out whether a IO-accessor is needed or not?
Two checkpoints would be needed, one is in the sdhci_send_command function, the other should be in sdhci_data_finish func.
How do you think this method?
>
> + /*Set the CMD_TYPE of the CMD12, fix no INT in MULTI_BLK IO */
> + if (host->quirks & SDHCI_QUIRK_FIX_NO_INT_IN_MULTI_BLK_IO) {
> + if (cmd->opcode == 12)
> + flags |= SDHCI_CMD_ABORTCMD;
> + }
>
> But I'd really like to avoid the quirk bit. Maybe we'll get a better idea
> once we understand what that magic bit actually does. For a start, we
> might simply set SDHCI_QUIRK_NO_MULTIBLOCK for mx53 like we do for other
> imx.
As I know that, this bit is used to make the machine stat of the eSDHC IC to be a correct stat after SDIO Multi-Read.
>
> Regards,
>
> Wolfram
>
> --
> Pengutronix e.K. | Wolfram Sang
> |
> Industrial Linux Solutions | http://www.pengutronix.de/
> |
^ permalink raw reply
* [PATCH 5/5] mmc: sdhci: add quirk SDHCI_QUIRK_FIX_NO_INT_IN_MULTI_BLK_IO
From: Zhu Richard-R65037 @ 2011-02-22 2:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110221110905.GL14495@n2100.arm.linux.org.uk>
Hi Russell King:
Thanks for your comments firstly.
Best Regards
Richard Zhu
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Monday, February 21, 2011 7:09 PM
> To: Wolfram Sang
> Cc: Zhu Richard-R65037; Zhao Richard-B20223; cjb at laptop.org;
> eric at eukrea.com; linux-mmc at vger.kernel.org; kernel at pengutronix.de;
> avorontsov at ru.mvista.com; linux-arm-kernel at lists.infradead.org;
> linuxzsc at gmail.com
> Subject: Re: [PATCH 5/5] mmc: sdhci: add quirk
> SDHCI_QUIRK_FIX_NO_INT_IN_MULTI_BLK_IO
>
> On Mon, Feb 21, 2011 at 11:46:08AM +0100, Wolfram Sang wrote:
> > > > > - if (cpu_is_mx35() || cpu_is_mx51())
> > > > > + if (cpu_is_mx53())
> > > > > + host->quirks |=
> > > > > + SDHCI_QUIRK_FIX_NO_INT_IN_MULTI_BLK_IO;
> > > >
> > > > Have you tried it doing it via IO-accessors?
> > > Richard Zhu: This quirk is used to fix a mechanism problem in the MMC
> CMDs execution procedure.
> > > It would be very abrupt and ugly, if the IO-accessors are added into
> these original procedures.
> >
> > Please don't get it personal, but IMHO it is pretty ugly the way it is
> > now. This quirk is very imx-specific and calling something like
> > SDHCI_VENDOR_SPEC in sdhci.c looks clearly wrong to me. By the way,
> > what does this bit do, the description doesn't say so?
>
> SDHCI_QUIRK_FIX_NO_INT_IN_MULTI_BLK_IO is rather too verbose. Isn't
> there a shorter version which could be used?
> SDHCI_QUIRK_SDIO_MULTIBLK_INT maybe?
Yeah, I agree, the clear and shorter is better.
I'm discussing with WolfSang that this quirk should be added or not.
First of all, we should make a decision that this quirk is needed or not.
Then we can refine it.
^ permalink raw reply
* [PATCH 0/7] Second batch of Tegra clock updates for 2.6.39
From: Colin Cross @ 2011-02-22 2:39 UTC (permalink / raw)
To: linux-arm-kernel
This patch series contains two small patches out of the previous
series that needed fixes, as well as some new ones to disable
unused clocks during boot and related bug fixes.
Patch 4 converts the Harmony and Trimslice boards to use the new
init_early machine handler. Any boards that go in after this
patch will need to be updated to match, and this patch will need
to be updated if any boards go in before this patch.
Tested-bys on Harmony and Trimslice would be appreciated.
^ permalink raw reply
* [PATCH 1/7] ARM: tegra: clock: Refcount periph clock enables
From: Colin Cross @ 2011-02-22 2:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298342392-21236-1-git-send-email-ccross@android.com>
Some peripheral clocks share enable bits. Refcount the enables so
that calling clk_disable on one clock will not turn off another
clock.
Signed-off-by: Colin Cross <ccross@android.com>
---
arch/arm/mach-tegra/tegra2_clocks.c | 37 +++++++++++++++++++++++++++++-----
1 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-tegra/tegra2_clocks.c b/arch/arm/mach-tegra/tegra2_clocks.c
index 59e77ba..2ca8b74 100644
--- a/arch/arm/mach-tegra/tegra2_clocks.c
+++ b/arch/arm/mach-tegra/tegra2_clocks.c
@@ -159,6 +159,12 @@ static void __iomem *reg_pmc_base = IO_ADDRESS(TEGRA_PMC_BASE);
*/
static DEFINE_SPINLOCK(clock_register_lock);
+/*
+ * Some peripheral clocks share an enable bit, so refcount the enable bits
+ * in registers CLK_ENABLE_L, CLK_ENABLE_H, and CLK_ENABLE_U
+ */
+static int tegra_periph_clk_enable_refcount[3 * 32];
+
#define clk_writel(value, reg) \
__raw_writel(value, (u32)reg_clk_base + (reg))
#define clk_readl(reg) \
@@ -952,8 +958,17 @@ static void tegra2_periph_clk_init(struct clk *c)
static int tegra2_periph_clk_enable(struct clk *c)
{
u32 val;
+ unsigned long flags;
+ int refcount;
pr_debug("%s on clock %s\n", __func__, c->name);
+ spin_lock_irqsave(&clock_register_lock, flags);
+
+ refcount = tegra_periph_clk_enable_refcount[c->u.periph.clk_num]++;
+
+ if (refcount > 1)
+ goto out;
+
clk_writel(PERIPH_CLK_TO_ENB_BIT(c),
CLK_OUT_ENB_SET + PERIPH_CLK_TO_ENB_SET_REG(c));
if (!(c->flags & PERIPH_NO_RESET) && !(c->flags & PERIPH_MANUAL_RESET))
@@ -966,15 +981,29 @@ static int tegra2_periph_clk_enable(struct clk *c)
val |= 0x3 << 24;
clk_writel(val, c->reg);
}
+
+out:
+ spin_unlock_irqrestore(&clock_register_lock, flags);
+
return 0;
}
static void tegra2_periph_clk_disable(struct clk *c)
{
+ unsigned long flags;
+
pr_debug("%s on clock %s\n", __func__, c->name);
- clk_writel(PERIPH_CLK_TO_ENB_BIT(c),
- CLK_OUT_ENB_CLR + PERIPH_CLK_TO_ENB_SET_REG(c));
+ spin_lock_irqsave(&clock_register_lock, flags);
+
+ if (c->refcnt)
+ tegra_periph_clk_enable_refcount[c->u.periph.clk_num]--;
+
+ if (tegra_periph_clk_enable_refcount[c->u.periph.clk_num] == 0)
+ clk_writel(PERIPH_CLK_TO_ENB_BIT(c),
+ CLK_OUT_ENB_CLR + PERIPH_CLK_TO_ENB_SET_REG(c));
+
+ spin_unlock_irqrestore(&clock_register_lock, flags);
}
static void tegra2_periph_clk_reset(struct clk *c, bool assert)
@@ -2076,7 +2105,6 @@ struct clk tegra_list_clks[] = {
PERIPH_CLK("timer", "timer", NULL, 5, 0, 26000000, mux_clk_m, 0),
PERIPH_CLK("i2s1", "i2s.0", NULL, 11, 0x100, 26000000, mux_pllaout0_audio2x_pllp_clkm, MUX | DIV_U71),
PERIPH_CLK("i2s2", "i2s.1", NULL, 18, 0x104, 26000000, mux_pllaout0_audio2x_pllp_clkm, MUX | DIV_U71),
- /* FIXME: spdif has 2 clocks but 1 enable */
PERIPH_CLK("spdif_out", "spdif_out", NULL, 10, 0x108, 100000000, mux_pllaout0_audio2x_pllp_clkm, MUX | DIV_U71),
PERIPH_CLK("spdif_in", "spdif_in", NULL, 10, 0x10c, 100000000, mux_pllp_pllc_pllm, MUX | DIV_U71),
PERIPH_CLK("pwm", "pwm", NULL, 17, 0x110, 432000000, mux_pllp_pllc_audio_clkm_clk32, MUX | DIV_U71),
@@ -2089,7 +2117,6 @@ struct clk tegra_list_clks[] = {
PERIPH_CLK("sbc4", "spi_tegra.3", NULL, 68, 0x1b4, 160000000, mux_pllp_pllc_pllm_clkm, MUX | DIV_U71),
PERIPH_CLK("ide", "ide", NULL, 25, 0x144, 100000000, mux_pllp_pllc_pllm_clkm, MUX | DIV_U71), /* requires min voltage */
PERIPH_CLK("ndflash", "tegra_nand", NULL, 13, 0x160, 164000000, mux_pllp_pllc_pllm_clkm, MUX | DIV_U71), /* scales with voltage */
- /* FIXME: vfir shares an enable with uartb */
PERIPH_CLK("vfir", "vfir", NULL, 7, 0x168, 72000000, mux_pllp_pllc_pllm_clkm, MUX | DIV_U71),
PERIPH_CLK("sdmmc1", "sdhci-tegra.0", NULL, 14, 0x150, 52000000, mux_pllp_pllc_pllm_clkm, MUX | DIV_U71), /* scales with voltage */
PERIPH_CLK("sdmmc2", "sdhci-tegra.1", NULL, 9, 0x154, 52000000, mux_pllp_pllc_pllm_clkm, MUX | DIV_U71), /* scales with voltage */
@@ -2120,13 +2147,11 @@ struct clk tegra_list_clks[] = {
PERIPH_CLK("uarte", "uart.4", NULL, 66, 0x1c4, 600000000, mux_pllp_pllc_pllm_clkm, MUX),
PERIPH_CLK("3d", "3d", NULL, 24, 0x158, 300000000, mux_pllm_pllc_pllp_plla, MUX | DIV_U71 | PERIPH_MANUAL_RESET), /* scales with voltage and process_id */
PERIPH_CLK("2d", "2d", NULL, 21, 0x15c, 300000000, mux_pllm_pllc_pllp_plla, MUX | DIV_U71), /* scales with voltage and process_id */
- /* FIXME: vi and vi_sensor share an enable */
PERIPH_CLK("vi", "tegra_camera", "vi", 20, 0x148, 150000000, mux_pllm_pllc_pllp_plla, MUX | DIV_U71), /* scales with voltage and process_id */
PERIPH_CLK("vi_sensor", "tegra_camera", "vi_sensor", 20, 0x1a8, 150000000, mux_pllm_pllc_pllp_plla, MUX | DIV_U71 | PERIPH_NO_RESET), /* scales with voltage and process_id */
PERIPH_CLK("epp", "epp", NULL, 19, 0x16c, 300000000, mux_pllm_pllc_pllp_plla, MUX | DIV_U71), /* scales with voltage and process_id */
PERIPH_CLK("mpe", "mpe", NULL, 60, 0x170, 250000000, mux_pllm_pllc_pllp_plla, MUX | DIV_U71), /* scales with voltage and process_id */
PERIPH_CLK("host1x", "host1x", NULL, 28, 0x180, 166000000, mux_pllm_pllc_pllp_plla, MUX | DIV_U71), /* scales with voltage and process_id */
- /* FIXME: cve and tvo share an enable */
PERIPH_CLK("cve", "cve", NULL, 49, 0x140, 250000000, mux_pllp_plld_pllc_clkm, MUX | DIV_U71), /* requires min voltage */
PERIPH_CLK("tvo", "tvo", NULL, 49, 0x188, 250000000, mux_pllp_plld_pllc_clkm, MUX | DIV_U71), /* requires min voltage */
PERIPH_CLK("hdmi", "hdmi", NULL, 51, 0x18c, 600000000, mux_pllp_plld_pllc_clkm, MUX | DIV_U71), /* requires min voltage */
--
1.7.3.1
^ permalink raw reply related
* [PATCH 2/7] ARM: tegra: clock: Round rate before setting rate
From: Colin Cross @ 2011-02-22 2:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298342392-21236-1-git-send-email-ccross@android.com>
Call the clock's round_rate op, if it exists, before calling
the set_rate op. This will help later when dvfs is added,
dvfs needs to know what the final rate will be before the
frequency changes.
Also requires fixes to the round rate functions to ensure
calling round rate and then set rate will not cause the
frequency to be rounded down twice. When picking clock
divider values, the clock framework picks the closest
frequency that is lower than the requested frequency. If
the new frequency calculated from the divider value is
rounded down, and then passed to set_rate, it will get
rounded down again, possibly resulting in a frequency two
steps lower than the original requested frequency.
Fix the problem by rounding up when calculating the frequency
coming out of a clock divider, so if that frequency is
requested again, the same divider value will be picked.
Signed-off-by: Colin Cross <ccross@android.com>
---
arch/arm/mach-tegra/clock.c | 12 ++++++++++++
arch/arm/mach-tegra/tegra2_clocks.c | 8 ++++----
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-tegra/clock.c b/arch/arm/mach-tegra/clock.c
index 165aa9c..e028320 100644
--- a/arch/arm/mach-tegra/clock.c
+++ b/arch/arm/mach-tegra/clock.c
@@ -86,6 +86,7 @@ static unsigned long clk_predict_rate_from_parent(struct clk *c, struct clk *p)
if (c->mul != 0 && c->div != 0) {
rate *= c->mul;
+ rate += c->div - 1; /* round up */
do_div(rate, c->div);
}
@@ -240,12 +241,23 @@ EXPORT_SYMBOL(clk_get_parent);
int clk_set_rate_locked(struct clk *c, unsigned long rate)
{
+ long new_rate;
+
if (!c->ops || !c->ops->set_rate)
return -ENOSYS;
if (rate > c->max_rate)
rate = c->max_rate;
+ if (c->ops && c->ops->round_rate) {
+ new_rate = c->ops->round_rate(c, rate);
+
+ if (new_rate < 0)
+ return new_rate;
+
+ rate = new_rate;
+ }
+
return c->ops->set_rate(c, rate);
}
diff --git a/arch/arm/mach-tegra/tegra2_clocks.c b/arch/arm/mach-tegra/tegra2_clocks.c
index 2ca8b74..73e112f 100644
--- a/arch/arm/mach-tegra/tegra2_clocks.c
+++ b/arch/arm/mach-tegra/tegra2_clocks.c
@@ -898,9 +898,9 @@ static long tegra2_pll_div_clk_round_rate(struct clk *c, unsigned long rate)
divider = clk_div71_get_divider(parent_rate, rate);
if (divider < 0)
return divider;
- return parent_rate * 2 / (divider + 2);
+ return DIV_ROUND_UP(parent_rate * 2, divider + 2);
} else if (c->flags & DIV_2) {
- return parent_rate / 2;
+ return DIV_ROUND_UP(parent_rate, 2);
}
return -EINVAL;
}
@@ -1092,12 +1092,12 @@ static long tegra2_periph_clk_round_rate(struct clk *c,
if (divider < 0)
return divider;
- return parent_rate * 2 / (divider + 2);
+ return DIV_ROUND_UP(parent_rate * 2, divider + 2);
} else if (c->flags & DIV_U16) {
divider = clk_div16_get_divider(parent_rate, rate);
if (divider < 0)
return divider;
- return parent_rate / (divider + 1);
+ return DIV_ROUND_UP(parent_rate, divider + 1);
}
return -EINVAL;
}
--
1.7.3.1
^ permalink raw reply related
* [PATCH 3/7] ARM: tegra: clock: Check for clk_num == 0
From: Colin Cross @ 2011-02-22 2:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298342392-21236-1-git-send-email-ccross@android.com>
Peripheral clocks that have no clock enable bit in the
enable registers have their clk_num set to 0. Bit 0
in the clock enable registers is the CPU clock.
Prevent disables on these peripheral clocks from
accidentally disabling the CPU clock.
Signed-off-by: Colin Cross <ccross@android.com>
---
arch/arm/mach-tegra/tegra2_clocks.c | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-tegra/tegra2_clocks.c b/arch/arm/mach-tegra/tegra2_clocks.c
index 73e112f..3015a2c 100644
--- a/arch/arm/mach-tegra/tegra2_clocks.c
+++ b/arch/arm/mach-tegra/tegra2_clocks.c
@@ -946,9 +946,14 @@ static void tegra2_periph_clk_init(struct clk *c)
}
c->state = ON;
+
+ if (!c->u.periph.clk_num)
+ return;
+
if (!(clk_readl(CLK_OUT_ENB + PERIPH_CLK_TO_ENB_REG(c)) &
PERIPH_CLK_TO_ENB_BIT(c)))
c->state = OFF;
+
if (!(c->flags & PERIPH_NO_RESET))
if (clk_readl(RST_DEVICES + PERIPH_CLK_TO_ENB_REG(c)) &
PERIPH_CLK_TO_ENB_BIT(c))
@@ -962,6 +967,9 @@ static int tegra2_periph_clk_enable(struct clk *c)
int refcount;
pr_debug("%s on clock %s\n", __func__, c->name);
+ if (!c->u.periph.clk_num)
+ return 0;
+
spin_lock_irqsave(&clock_register_lock, flags);
refcount = tegra_periph_clk_enable_refcount[c->u.periph.clk_num]++;
@@ -994,6 +1002,9 @@ static void tegra2_periph_clk_disable(struct clk *c)
pr_debug("%s on clock %s\n", __func__, c->name);
+ if (!c->u.periph.clk_num)
+ return;
+
spin_lock_irqsave(&clock_register_lock, flags);
if (c->refcnt)
@@ -1012,6 +1023,9 @@ static void tegra2_periph_clk_reset(struct clk *c, bool assert)
pr_debug("%s %s on clock %s\n", __func__,
assert ? "assert" : "deassert", c->name);
+
+ BUG_ON(!c->u.periph.clk_num);
+
if (!(c->flags & PERIPH_NO_RESET))
clk_writel(PERIPH_CLK_TO_ENB_BIT(c),
base + PERIPH_CLK_TO_ENB_SET_REG(c));
@@ -1182,6 +1196,10 @@ static void tegra2_clk_double_init(struct clk *c)
c->mul = 2;
c->div = 1;
c->state = ON;
+
+ if (!c->u.periph.clk_num)
+ return;
+
if (!(clk_readl(CLK_OUT_ENB + PERIPH_CLK_TO_ENB_REG(c)) &
PERIPH_CLK_TO_ENB_BIT(c)))
c->state = OFF;
@@ -1269,6 +1287,9 @@ static void tegra2_cdev_clk_init(struct clk *c)
/* We could un-tristate the cdev1 or cdev2 pingroup here; this is
* currently done in the pinmux code. */
c->state = ON;
+
+ BUG_ON(!c->u.periph.clk_num);
+
if (!(clk_readl(CLK_OUT_ENB + PERIPH_CLK_TO_ENB_REG(c)) &
PERIPH_CLK_TO_ENB_BIT(c)))
c->state = OFF;
@@ -1276,6 +1297,8 @@ static void tegra2_cdev_clk_init(struct clk *c)
static int tegra2_cdev_clk_enable(struct clk *c)
{
+ BUG_ON(!c->u.periph.clk_num);
+
clk_writel(PERIPH_CLK_TO_ENB_BIT(c),
CLK_OUT_ENB_SET + PERIPH_CLK_TO_ENB_SET_REG(c));
return 0;
@@ -1283,6 +1306,8 @@ static int tegra2_cdev_clk_enable(struct clk *c)
static void tegra2_cdev_clk_disable(struct clk *c)
{
+ BUG_ON(!c->u.periph.clk_num);
+
clk_writel(PERIPH_CLK_TO_ENB_BIT(c),
CLK_OUT_ENB_CLR + PERIPH_CLK_TO_ENB_SET_REG(c));
}
--
1.7.3.1
^ permalink raw reply related
* [PATCH 4/7] ARM: tegra: Move tegra_common_init to tegra_init_early
From: Colin Cross @ 2011-02-22 2:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298342392-21236-1-git-send-email-ccross@android.com>
Move tegra_common_init to tegra_init_early, and set it
as the init_early entry in the machine struct.
Initializes the clocks earlier so that timers can enable
their clocks.
Also reorders the members in the Harmony and Trimslice
boards' machine structs to match the order they are
called in.
Signed-off-by: Colin Cross <ccross@android.com>
---
arch/arm/mach-tegra/board-harmony.c | 7 +++----
arch/arm/mach-tegra/board-trimslice.c | 7 +++----
arch/arm/mach-tegra/board.h | 2 +-
arch/arm/mach-tegra/common.c | 2 +-
4 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-tegra/board-harmony.c b/arch/arm/mach-tegra/board-harmony.c
index b9dbdb1..368ddff 100644
--- a/arch/arm/mach-tegra/board-harmony.c
+++ b/arch/arm/mach-tegra/board-harmony.c
@@ -104,8 +104,6 @@ static __initdata struct tegra_clk_init_table harmony_clk_init_table[] = {
static void __init tegra_harmony_init(void)
{
- tegra_common_init();
-
tegra_clk_init_from_table(harmony_clk_init_table);
harmony_pinmux_init();
@@ -116,8 +114,9 @@ static void __init tegra_harmony_init(void)
MACHINE_START(HARMONY, "harmony")
.boot_params = 0x00000100,
.fixup = tegra_harmony_fixup,
- .init_irq = tegra_init_irq,
- .init_machine = tegra_harmony_init,
.map_io = tegra_map_common_io,
+ .init_early = tegra_init_early,
+ .init_irq = tegra_init_irq,
.timer = &tegra_timer,
+ .init_machine = tegra_harmony_init,
MACHINE_END
diff --git a/arch/arm/mach-tegra/board-trimslice.c b/arch/arm/mach-tegra/board-trimslice.c
index ef233b2..0f3081a 100644
--- a/arch/arm/mach-tegra/board-trimslice.c
+++ b/arch/arm/mach-tegra/board-trimslice.c
@@ -85,8 +85,6 @@ subsys_initcall(tegra_trimslice_pci_init);
static void __init tegra_trimslice_init(void)
{
- tegra_common_init();
-
tegra_clk_init_from_table(trimslice_clk_init_table);
trimslice_pinmux_init();
@@ -97,8 +95,9 @@ static void __init tegra_trimslice_init(void)
MACHINE_START(TRIMSLICE, "trimslice")
.boot_params = 0x00000100,
.fixup = tegra_trimslice_fixup,
- .init_irq = tegra_init_irq,
- .init_machine = tegra_trimslice_init,
.map_io = tegra_map_common_io,
+ .init_early = tegra_init_early,
+ .init_irq = tegra_init_irq,
.timer = &tegra_timer,
+ .init_machine = tegra_trimslice_init,
MACHINE_END
diff --git a/arch/arm/mach-tegra/board.h b/arch/arm/mach-tegra/board.h
index b3f9c94..1d14df7 100644
--- a/arch/arm/mach-tegra/board.h
+++ b/arch/arm/mach-tegra/board.h
@@ -25,7 +25,7 @@
void tegra_assert_system_reset(char mode, const char *cmd);
-void __init tegra_common_init(void);
+void __init tegra_init_early(void);
void __init tegra_map_common_io(void);
void __init tegra_init_irq(void);
void __init tegra_init_clock(void);
diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index 54826b8..14fa533 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@ -72,7 +72,7 @@ void __init tegra_init_cache(void)
}
-void __init tegra_common_init(void)
+void __init tegra_init_early(void)
{
tegra_init_fuse();
tegra_init_clock();
--
1.7.3.1
^ permalink raw reply related
* [PATCH 5/7] ARM: tegra: timer: Enable timer and rtc clocks
From: Colin Cross @ 2011-02-22 2:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298342392-21236-1-git-send-email-ccross@android.com>
Enable the timer and rtc clocks to prevent them being
turned off by the bootloader clock disabling code.
Signed-off-by: Colin Cross <ccross@android.com>
---
arch/arm/mach-tegra/timer.c | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-tegra/timer.c b/arch/arm/mach-tegra/timer.c
index ffa6a68..31b4f56 100644
--- a/arch/arm/mach-tegra/timer.c
+++ b/arch/arm/mach-tegra/timer.c
@@ -18,6 +18,7 @@
*/
#include <linux/init.h>
+#include <linux/err.h>
#include <linux/sched.h>
#include <linux/time.h>
#include <linux/interrupt.h>
@@ -193,9 +194,20 @@ static struct irqaction tegra_timer_irq = {
static void __init tegra_init_timer(void)
{
+ struct clk *clk;
unsigned long rate = clk_measure_input_freq();
int ret;
+ clk = clk_get_sys("timer", NULL);
+ BUG_ON(IS_ERR(clk));
+ clk_enable(clk);
+ clk_put(clk);
+
+ clk = clk_get_sys("rtc-tegra", NULL);
+ BUG_ON(IS_ERR(clk));
+ clk_enable(clk);
+ clk_put(clk);
+
#ifdef CONFIG_HAVE_ARM_TWD
twd_base = IO_ADDRESS(TEGRA_ARM_PERIF_BASE + 0x600);
#endif
@@ -239,8 +251,6 @@ static void __init tegra_init_timer(void)
tegra_clockevent.cpumask = cpu_all_mask;
tegra_clockevent.irq = tegra_timer_irq.irq;
clockevents_register_device(&tegra_clockevent);
-
- return;
}
struct sys_timer tegra_timer = {
--
1.7.3.1
^ permalink raw reply related
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