* [PATCH 3/4] net/fec: set phy_speed to the optimal frequency 2.5 MHz
From: Shawn Guo @ 2011-09-20 2:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E77C4A2.1060802@boundarydevices.com>
On Mon, Sep 19, 2011 at 03:39:30PM -0700, Troy Kisky wrote:
> On 9/18/2011 4:54 AM, Shawn Guo wrote:
> >With the unnecessary 1 bit left-shift on fep->phy_speed during the
> >calculation, the phy_speed always runs at the half frequency of the
> >optimal one 2.5 MHz.
> >
> >The patch removes that 1 bit left-shift to get the optimal phy_speed.
> >
> >Signed-off-by: Shawn Guo<shawn.guo@linaro.org>
> >---
> > drivers/net/fec.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> >diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> >index 5ef0e34..04206e4 100644
> >--- a/drivers/net/fec.c
> >+++ b/drivers/net/fec.c
> >@@ -1007,7 +1007,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
> > /*
> > * Set MII speed to 2.5 MHz (= clk_get_rate() / 2 * phy_speed)
> > */
> >- fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000)<< 1;
> >+ fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000);
> > writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
> >
> > fep->mii_bus = mdiobus_alloc();
> Do you need to round up to an even value? Is the hardware
> documentation wrong?
The round up is something existed, and the patch does not touch that
part.
> Does this need a quirk? What boards has this been verified to fix?
>
I tested this on i.mx28, i.mx53 and i.mx6q. Do you see problem on
your platform?
--
Regards,
Shawn
^ permalink raw reply
* [PATCH 00/11] Add L2 cache cleaning to generic CPU suspend
From: Shawn Guo @ 2011-09-20 3:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919162222.GC16591@n2100.arm.linux.org.uk>
On Mon, Sep 19, 2011 at 05:22:22PM +0100, Russell King - ARM Linux wrote:
> On Sun, Sep 11, 2011 at 12:10:04AM +0800, Shawn Guo wrote:
> > On Thu, Sep 01, 2011 at 11:57:54PM +0800, Shawn Guo wrote:
> > > On Thu, Sep 01, 2011 at 04:34:51PM +0100, Russell King - ARM Linux wrote:
> > > > On Thu, Sep 01, 2011 at 11:33:43PM +0800, Shawn Guo wrote:
> > > > > This is also the case on i.MX6Q, which L2 cache is retained during a
> > > > > suspend/resume cycle. Currently, I have to call into the following
> > > > > before calling generic cpu_suspend() to clean/invalidate the entire
> > > > > L2 cache.
> > > > >
> > > > > outer_flush_all();
> > > > > outer_disable();
> > > > >
> > > > > But there is a wired thing on using generic cpu_resume(). I have to
> > > > > invalidate L1 before calling into cpu_resume() like below.
> > > > >
> > > > > ENTRY(imx6q_cpu_resume)
> > > > > bl v7_invalidate_l1
> > > > > b cpu_resume
> > > > > ENDPROC(imx6q_cpu_resume)
> > > > >
> > > > > ENTRY(imx6q_secondary_startup)
> > > > > bl v7_invalidate_l1
> > > > > b secondary_startup
> > > > > ENDPROC(imx6q_secondary_startup)
> > > > >
> > > > > The v7_invalidate_l1() is the function copied from mach-tegra/headsmp.S,
> > > > > which has to be called before calling secondary_startup to boot
> > > > > secondary cores (same situation between Tegra and i.MX6Q).
> > > >
> > > > Presumably that's because your L1 cache contains randomized data with
> > > > random validity (and presumably random dirtyness) at boot time - something
> > > > which unfortunately the ARM ARM permits. I don't think we can go to the
> > > > extent of dealing with this in the generic code as it would unnecessarily
> > > > perturb those implementations which either the boot loader has already
> > > > sorted out that issue, or which don't have the issue at all.
> > > >
> > > Yes, agreed. It seems that Tegra and i.MX6Q are the only two CA9MP
> > > cases here. But is it possible to maintain this v7_invalidate_l1()
> > > function in cache-v7.S, so that we do not need to duplicate it in
> > > platform codes?
> > >
> > > > > Before applying this patch series, I have something like below actually
> > > > > working.
> > > > >
> > > > >
> > > > > outer_flush_all();
> > > > > outer_disable();
> > > > > imx_set_cpu_jump(0, imx6q_cpu_resume);
> > > > > /* Zzz ... */
> > > > > cpu_suspend(0, imx6q_suspend_finish);
> > > > >
> > > > > I expect with you patches applied, I can still have it work with simply
> > > > > removing those two lines outer cache codes.
> > > >
> > > > That should be the case.
> > > >
> > > > > But unfortunately, I'm
> > > > > running into Oops when resuming back. And I also have Oops with
> > > > > imx_set_cpu_jump(0, cpu_resume) which means skipping the
> > > > > v7_invalidate_l1() and calling generic cpu_resume() only.
> > > >
> > > > Do you have a copy of the oops?
> > > >
> > >
> > Hi Russell,
> >
> > After following your great debugging clue that we need to enable L2
> > before calling into generic cpu_resume(), now this patch series works
> > great for imx6q. Thanks a lot, and here is my tag.
> >
> > Tested-by: Shawn Guo <shawn.guo@linaro.org>
>
> Is that for all these patches?
>
Yes, it is.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v2] dmaengine: add CSR SiRFprimaII DMAC driver
From: Vinod Koul @ 2011-09-20 3:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4y0F7JTwFwesVvbgq1Lupw+a_-EpiTwW9GtXxOauohdVQ@mail.gmail.com>
On Mon, 2011-09-19 at 19:25 +0800, Barry Song wrote:
> 2011/9/19 Vinod Koul <vinod.koul@intel.com>:
> > On Mon, 2011-09-19 at 09:56 +0000, Barry Song wrote:
> >> > > > Not sure why you support this, there seem to be no DMA_SLAVE
> >> support in
> >> > > > this version ate least
> >> > >
> >> > > Not. I support dma_slave. But I have no prep_slave_sg function
> >> since I can
> >> > use the gen xfer to replace it.
> >> > Yes thats okay...
> >> >
> >> > Then I have questions on genxfer function...
> >> > where are you copying either src or dstn_start address, you seem to
> >> > completely ignore them?
> >>
> >> Since I only support memory->device or device ->memory, and channel
> >> number is fixed to every device. Then I actually don't care device
> >> address at all. Either src or dst is fixed to the device's address.
> > peripheral address can be fixed, not the memory, where do you copy the
> > memory address?
>
> +static int sirfsoc_dma_slave_config(struct sirfsoc_dma_chan *schan,
> + struct dma_slave_config *config)
> +{
> + u32 addr, direction;
> + unsigned long flags;
> +
> + switch (config->direction) {
> + case DMA_FROM_DEVICE:
> + direction = 0;
> + addr = config->dst_addr;
> + break;
> +
> + case DMA_TO_DEVICE:
> + direction = 1;
> + addr = config->src_addr;
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> + ...
This is wrong. You are treating addresses passed in dma_slave_config as
memory address. These should be treating this as peripheral address
(destination in DMA_TO_DEVICE....) and take the memory address from your
prepare function.
--
~Vinod
^ permalink raw reply
* [PATCH 0/7] Add L2 cache cleaning to generic CPU suspend
From: Shawn Guo @ 2011-09-20 3:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919163741.GE16591@n2100.arm.linux.org.uk>
On Mon, Sep 19, 2011 at 05:37:41PM +0100, Russell King - ARM Linux wrote:
> This is a re-post of the previous patch series, but with an additional
> TLB flush to ensure that hte global TLB entry in the page tables is
> flushed out. This is a flush of all TLB entries, but it could probably
> be more targetted if we need to.
>
Here is the diff on suspend.c between last post and this series. With
the outer_clean_range() calls added back, the series works fine on
imx6q, otherwise it hangs on resume.
diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index 4c95410..2d60f19 100644
--- a/arch/arm/kernel/suspend.c
+++ b/arch/arm/kernel/suspend.c
@@ -28,9 +28,6 @@ void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32 *save_ptr)
cpu_do_suspend(ptr);
flush_cache_all();
- outer_clean_range(*save_ptr, *save_ptr + ptrsz);
- outer_clean_range(virt_to_phys(save_ptr),
- virt_to_phys(save_ptr) + sizeof(*save_ptr));
}
/*
@@ -52,8 +49,10 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
* back to the correct page tables.
*/
ret = __cpu_suspend(arg, fn);
- if (ret == 0)
+ if (ret == 0) {
cpu_switch_mm(mm->pgd, mm);
+ local_flush_tlb_all();
+ }
return ret;
}
--
Regards,
Shawn
^ permalink raw reply related
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Grant Likely @ 2011-09-20 4:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E77B9E3.40004@gmail.com>
On Mon, Sep 19, 2011 at 04:53:39PM -0500, Rob Herring wrote:
> On 09/19/2011 04:14 PM, Grant Likely wrote:
> > (Alternately, if there is no need for a CPU mask because PPI
> > interrupts will never be wired to more than one CPU, then it would be
> > better to encode the CPU number into the second cell with the SPI
> > number).
> You meant PPI number, right? ^^^
Yes, I meant PPI number. I keep transposing the two; I don't know why.
> The common case at least on the A9 is a PPI is routed to all cores. QC
> is different though. This was discussed previously. Basically, anything
> is possible here, so the mask is needed for sure.
Okay.
g.
^ permalink raw reply
* [PATCH v2] dmaengine: add CSR SiRFprimaII DMAC driver
From: Jassi Brar @ 2011-09-20 4:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4y0F7JTwFwesVvbgq1Lupw+a_-EpiTwW9GtXxOauohdVQ@mail.gmail.com>
On 19 September 2011 16:55, Barry Song <21cnbao@gmail.com> wrote:
> 2011/9/19 Vinod Koul <vinod.koul@intel.com>:
>> On Mon, 2011-09-19 at 09:56 +0000, Barry Song wrote:
>>> > > > Not sure why you support this, there seem to be no DMA_SLAVE
>>> support in
>>> > > > this version ate least
>>> > >
>>> > > Not. I support dma_slave. But I have no prep_slave_sg function
>>> since I can
>>> > use the gen xfer to replace it.
>>> > Yes thats okay...
>>> >
>>> > Then I have questions on genxfer function...
>>> > where are you copying either src or dstn_start address, you seem to
>>> > completely ignore them?
>>>
>>> Since I only support memory->device or device ->memory, and channel
>>> number is fixed to every device. Then I actually don't care device
>>> address at all. Either src or dst is fixed to the device's address.
>> peripheral address can be fixed, not the memory, where do you copy the
>> memory address?
>
> +static int sirfsoc_dma_slave_config(struct sirfsoc_dma_chan *schan,
> + ? ? ? struct dma_slave_config *config)
> +{
> + ? ? ? u32 addr, direction;
> + ? ? ? unsigned long flags;
> +
> + ? ? ? switch (config->direction) {
> + ? ? ? case DMA_FROM_DEVICE:
> + ? ? ? ? ? ? ? direction = 0;
> + ? ? ? ? ? ? ? addr = config->dst_addr;
> + ? ? ? ? ? ? ? break;
> +
> + ? ? ? case DMA_TO_DEVICE:
> + ? ? ? ? ? ? ? direction = 1;
> + ? ? ? ? ? ? ? addr = config->src_addr;
> + ? ? ? ? ? ? ? break;
> +
> + ? ? ? default:
> + ? ? ? ? ? ? ? return -EINVAL;
> + ? ? ? }
> + ?...
I repeat
{
Pass addresses using dmaxfer_template.src_start and dmaxfer_template.dst_start
instead of dma_slave_config.dst_addr and dma_slave_config.src_addr
}
^ permalink raw reply
* [PATCH v2] dmaengine: add CSR SiRFprimaII DMAC driver
From: Barry Song @ 2011-09-20 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJe_ZhdA17cB4WqoARct98NjDu8OhD76r6_S7JHOMdFDZ17wrA@mail.gmail.com>
2011/9/20 Jassi Brar <jaswinder.singh@linaro.org>:
> On 19 September 2011 16:55, Barry Song <21cnbao@gmail.com> wrote:
>> 2011/9/19 Vinod Koul <vinod.koul@intel.com>:
>>> On Mon, 2011-09-19 at 09:56 +0000, Barry Song wrote:
>>>> > > > Not sure why you support this, there seem to be no DMA_SLAVE
>>>> support in
>>>> > > > this version ate least
>>>> > >
>>>> > > Not. I support dma_slave. But I have no prep_slave_sg function
>>>> since I can
>>>> > use the gen xfer to replace it.
>>>> > Yes thats okay...
>>>> >
>>>> > Then I have questions on genxfer function...
>>>> > where are you copying either src or dstn_start address, you seem to
>>>> > completely ignore them?
>>>>
>>>> Since I only support memory->device or device ->memory, and channel
>>>> number is fixed to every device. Then I actually don't care device
>>>> address at all. Either src or dst is fixed to the device's address.
>>> peripheral address can be fixed, not the memory, where do you copy the
>>> memory address?
>>
>> +static int sirfsoc_dma_slave_config(struct sirfsoc_dma_chan *schan,
>> + ? ? ? struct dma_slave_config *config)
>> +{
>> + ? ? ? u32 addr, direction;
>> + ? ? ? unsigned long flags;
>> +
>> + ? ? ? switch (config->direction) {
>> + ? ? ? case DMA_FROM_DEVICE:
>> + ? ? ? ? ? ? ? direction = 0;
>> + ? ? ? ? ? ? ? addr = config->dst_addr;
>> + ? ? ? ? ? ? ? break;
>> +
>> + ? ? ? case DMA_TO_DEVICE:
>> + ? ? ? ? ? ? ? direction = 1;
>> + ? ? ? ? ? ? ? addr = config->src_addr;
>> + ? ? ? ? ? ? ? break;
>> +
>> + ? ? ? default:
>> + ? ? ? ? ? ? ? return -EINVAL;
>> + ? ? ? }
>> + ?...
> I repeat
> {
> Pass addresses using dmaxfer_template.src_start and dmaxfer_template.dst_start
> instead of dma_slave_config.dst_addr and dma_slave_config.src_addr
> }
agree.
-barry
^ permalink raw reply
* [PATCH] mach-ux500: enable fix for ARM errata 754322
From: srinidhi kasagar @ 2011-09-20 5:45 UTC (permalink / raw)
To: linux-arm-kernel
This applies ARM errata fix 754322 for all ux500 platforms.
Signed-off-by: srinidhi kasagar <srinidhi.kasagar@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
---
arch/arm/mach-ux500/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-ux500/Kconfig b/arch/arm/mach-ux500/Kconfig
index 4210cb4..a3e0c86 100644
--- a/arch/arm/mach-ux500/Kconfig
+++ b/arch/arm/mach-ux500/Kconfig
@@ -6,6 +6,7 @@ config UX500_SOC_COMMON
select ARM_GIC
select HAS_MTU
select ARM_ERRATA_753970
+ select ARM_ERRATA_754322
menu "Ux500 SoC"
--
1.7.4.3
^ permalink raw reply related
* [PATCH 16/18] dmaengine/ambhe rest oa-pl08x: Add support for sg len greater than one for slave transfers
From: Vinod Koul @ 2011-09-20 6:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315518873.6638.7.camel@vkoul-mobl4>
On Fri, 2011-09-09 at 03:24 +0530, Vinod Koul wrote:
> On Thu, 2011-09-08 at 12:29 +0200, Linus Walleij wrote:
> > On Thu, Sep 8, 2011 at 5:50 AM, Viresh Kumar <viresh.kumar@st.com> wrote:
> >
> > > If i am getting this clearly, the concern is "why to queue separate transfers for
> > > individual sg's? Better would be to prepare the complete list at once and
> > > start the transfer, so that DMA stops only after finishing all sg's
> > > passed from user." Is this what you are pointing at?
> >
> > Yes.
> >
> > > If yes, then the same is done in this patch too. An array for llis is allocated at
> > > the start, then for each sg i prepare lli list from this array. Last lli from one sg
> > > is followed by first lli from next sg. And so i get a continuous chain of llis.
> >
> > OK so I guess I was lost in the code ...
> >
> > So this is mainy cached as txd->dsg_list so you can quickly retrieve the
> > number of bytes pending in the LLI by traversing that sglist.
> >
> > This is better than what the coh901318 does, because that driver
> > resorts to going into the physical LLIs themselves to retrieve this
> > info.
> >
> > It also seems like this will play nice with Per Forlin's MMC
> > speed-up patches, so that will become effective for your MMC
> > usecases.
> >
> > Now I really like this patch.
> >
> > Sorry for being such a slow learner!
> > Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Okay, great. I will check the rest of the series (i think 3 patches) and
> apply then next week.
Applied the remaining two patches for the series to my next
--
~Vinod
^ permalink raw reply
* [PATCH 16/18] dmaengine/ambhe rest oa-pl08x: Add support for sg len greater than one for slave transfers
From: Viresh Kumar @ 2011-09-20 6:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316499574.31295.3.camel@vkoul-udesk3>
On 9/20/2011 11:49 AM, Vinod Koul wrote:
> Applied the remaining two patches for the series to my next
Probably there were three patches left, 18/20, 19/20, 20/20 in V3 of my patchset.
--
viresh
^ permalink raw reply
* [PATCH] mach-ux500: enable fix for ARM errata 754322
From: Linus Walleij @ 2011-09-20 6:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920054542.GA12962@bnru02>
On Tue, Sep 20, 2011 at 7:45 AM, srinidhi kasagar
<srinidhi.kasagar@stericsson.com> wrote:
> This applies ARM errata fix 754322 for all ux500 platforms.
>
> Signed-off-by: srinidhi kasagar <srinidhi.kasagar@stericsson.com>
> Acked-by: Linus Walleij <linus.walleij@stericsson.com>
Thanks, picked to ux500-core.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 0/6] mc13783 cleanup
From: Philippe Rétornaz @ 2011-09-20 6:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110918163351.GL32263@sortiz-mobl>
Hi !
> On Thu, Sep 15, 2011 at 06:03:21PM +0200, Uwe Kleine-K?nig wrote:
> > Hi Samuel,
> >
> > On Thu, Sep 15, 2011 at 05:12:13PM +0200, Samuel Ortiz wrote:
> > > On Thu, Aug 25, 2011 at 09:05:12AM +0200, Philippe R?tornaz wrote:
> > > > Le mercredi 24 ao?t 2011 15:27:40, Uwe Kleine-K?nig a ?crit :
> > > > > Hello,
> > > > >
> > > > > this series removes the long obsolte mc13783 API after fixing all
> > > > > remaining users.
> > > >
> > > > I posted a patch last month which was touching this MFD too.
> > > > We will need to synchronize both patch.
> > >
> > > I applied Uwe's patchset now.
> >
> > Thanks.
> >
> > > Could you please sync your code and send
> > > me a
> > >
> > > patchset that applies on top of:
> > >
> > > git://git.infradead.org/users/sameo/mfd-2.6.git for-next
> >
> > You can fetch the updated series from
> >
> > git://git.pengutronix.de/git/ukl/linux-2.6.git mc13783
>
> I merged this one on top of my for-next branch. My MFD tree temporary lives
> on infradead:
>
> git://git.infradead.org/users/sameo/mfd-2.6.git
Thank you very much to all of you !
Regards,
Philippe
^ permalink raw reply
* Link failures due to __bug_table in current -next
From: Simon Glass @ 2011-09-20 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919200317.GC16381@n2100.arm.linux.org.uk>
Hi Russell,
On Mon, Sep 19, 2011 at 1:03 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Sep 19, 2011 at 01:09:54PM +0100, Mark Brown wrote:
>> I'm seeing linker failures in -next as of today:
>>
>> `.exit.text' referenced in section `__bug_table' of fs/built-in.o:
>> defined in discarded section `.exit.text' of fs/built-in.o
>> `.exit.text' referenced in section `__bug_table' of crypto/built-in.o:
>> defined in discarded section `.exit.text' of crypto/built-in.o
>> `.exit.text' referenced in section `__bug_table' of net/built-in.o:
>> defined in discarded section `.exit.text' of net/built-in.o
>> `.exit.text' referenced in section `__bug_table' of net/built-in.o:
>> defined in discarded section `.exit.text' of net/built-in.o
>>
>> which appears to be due to the chnage to use generic BUG() introduced in
>> commit 5254a3 (ARM: 7017/1: Use generic BUG() handler), reverting that
>> commit resolves the issue for me.
Gosh this does seem a bit odd. Ordering seems to be clearly implied by
the file syntax and I agree we should seek guidance from binutils
people.
I added the BUG condition to CONFIG_SMP_ON_UP and
CONFIG_DEBUG_SPINLOCK which were already there. If BUG is causing
problems, I wonder why these are not? Have we just been lucky, or have
I crossed a line? Or perhaps there are no spinlocks in exit text?
One option is to keep all exit text around - i.e. never discard it at
link time. From memory it is only 4-8KB. Doubtless many would be upset
with this, but it could be an option until this binutils behaviour is
resolved.
Another is to declare that it is a bug to use BUG in an exit section.
I was thinking about that at the time, but decided it was probably too
radical. There are only a small number of references in the kernel I
think (again from memory - this was back in April I think). Not
trivial to enforce, and the error you get is not exactly informative.
Yes another even stranger might be to ask the linker to leave the
references to discarded sections from the bug table unresolved, and
perhaps make them zero, like a weak reference. Is that even possible?
This would work since the bug scanning code can skip over these
entries. Even better if the linker could remove them but this is going
far beyond the job of a humble linker script.
While a bug-fix or feature change in binutils might get us there, I
worry that it would be years before it became widespread enough that
we could turn it on.
>
> This might solve the problem - could you check please?
Hope so. Thanks for your efforts on this. It would be nice not to have
to dump generic BUG due to this technicality.
Regards,
Simon
>
> ?arch/arm/kernel/vmlinux.lds.S | ? 15 ++++++++++++---
> ?1 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index 7b2541e..20b3041 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -24,8 +24,10 @@
> ?#if (defined(CONFIG_SMP_ON_UP) && !defined(CONFIG_DEBUG_SPINLOCK)) || \
> ? ? ? ?defined(CONFIG_GENERIC_BUG)
> ?#define ARM_EXIT_KEEP(x) ? ? ? x
> +#define ARM_EXIT_DISCARD(x)
> ?#else
> ?#define ARM_EXIT_KEEP(x)
> +#define ARM_EXIT_DISCARD(x) ? ?x
> ?#endif
>
> ?OUTPUT_ARCH(arm)
> @@ -40,6 +42,11 @@ jiffies = jiffies_64 + 4;
> ?SECTIONS
> ?{
> ? ? ? ?/*
> + ? ? ? ?* XXX: The linker does not define how output sections are
> + ? ? ? ?* assigned to input sections when there are multiple statements
> + ? ? ? ?* matching the same input section name. ?There is no documented
> + ? ? ? ?* order of matching.
> + ? ? ? ?*
> ? ? ? ? * unwind exit sections must be discarded before the rest of the
> ? ? ? ? * unwind sections get included.
> ? ? ? ? */
> @@ -48,6 +55,9 @@ SECTIONS
> ? ? ? ? ? ? ? ?*(.ARM.extab.exit.text)
> ? ? ? ? ? ? ? ?ARM_CPU_DISCARD(*(.ARM.exidx.cpuexit.text))
> ? ? ? ? ? ? ? ?ARM_CPU_DISCARD(*(.ARM.extab.cpuexit.text))
> + ? ? ? ? ? ? ? ARM_EXIT_DISCARD(EXIT_TEXT)
> + ? ? ? ? ? ? ? ARM_EXIT_DISCARD(EXIT_DATA)
> + ? ? ? ? ? ? ? EXIT_CALL
> ?#ifndef CONFIG_HOTPLUG
> ? ? ? ? ? ? ? ?*(.ARM.exidx.devexit.text)
> ? ? ? ? ? ? ? ?*(.ARM.extab.devexit.text)
> @@ -59,6 +69,8 @@ SECTIONS
> ?#ifndef CONFIG_SMP_ON_UP
> ? ? ? ? ? ? ? ?*(.alt.smp.init)
> ?#endif
> + ? ? ? ? ? ? ? *(.discard)
> + ? ? ? ? ? ? ? *(.discard.*)
> ? ? ? ?}
>
> ?#ifdef CONFIG_XIP_KERNEL
> @@ -280,9 +292,6 @@ SECTIONS
>
> ? ? ? ?STABS_DEBUG
> ? ? ? ?.comment 0 : { *(.comment) }
> -
> - ? ? ? /* Default discards */
> - ? ? ? DISCARDS
> ?}
>
> ?/*
>
>
^ permalink raw reply
* [PATCH v2 0/3] ARM: imx: Add cpuidle for imx platforms
From: Sascha Hauer @ 2011-09-20 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316194070-21889-1-git-send-email-rob.lee@linaro.org>
Hi Robert,
On Fri, Sep 16, 2011 at 12:27:47PM -0500, Robert Lee wrote:
> This patch series adds a common imx cpuidle driver, some common
> mach-mx5 level cpuidle functionality, and an i.MX51 instance of
> using this driver.
>
> The patch series is based on v3.1-rc2.
>
> Changes since v1:
> * To address all the problems found during review of v1, a complete
> re-write was needed.
Much better than the last version, thanks.
>
> Robert Lee (3):
> ARM: imx: Add imx cpuidle driver
> ARM: imx: Add cpuidle for mach-mx5
> ARM: imx: Add cpuidle for i.MX51
>
> arch/arm/mach-mx5/Makefile | 3 +-
> arch/arm/mach-mx5/cpu_op-mx51.c | 35 +++++++-
Your additions to this file...
> arch/arm/mach-mx5/cpu_op-mx51.h | 1 +
> arch/arm/mach-mx5/mm.c | 4 +
> arch/arm/mach-mx5/system.c | 35 +++++++
And this one should go to arch/arm/mach-mx5/cpuidle.c, then we have
all i.MX5 specific cpuidle stuff together without ifdeffing the code.
I assume that cpuidle support for i.MX53 will look identically, right?
> arch/arm/plat-mxc/Makefile | 1 +
> arch/arm/plat-mxc/cpuidle.c | 151 ++++++++++++++++++++++++++++++
> arch/arm/plat-mxc/include/mach/cpuidle.h | 56 +++++++++++
> arch/arm/plat-mxc/include/mach/system.h | 3 +
> 9 files changed, 286 insertions(+), 3 deletions(-)
> create mode 100644 arch/arm/plat-mxc/cpuidle.c
> create mode 100644 arch/arm/plat-mxc/include/mach/cpuidle.h
>
>
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
* Link failures due to __bug_table in current -next
From: Uwe Kleine-König @ 2011-09-20 7:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919191617.GB16381@n2100.arm.linux.org.uk>
On Mon, Sep 19, 2011 at 08:16:17PM +0100, Russell King - ARM Linux wrote:
> On Mon, Sep 19, 2011 at 08:06:03PM +0100, Mark Brown wrote:
> > Yeah, it's a shame it doesn't include the disambiguated short ID in the
> > standard git log output (which is what I always grep if I'm trying to
> > search commit messages). I've never seen a way to tell git to use %H
> > instead of %h there by default that doesn't require me to start copying
> > scripts or whatever between machines all the time.
>
> I'm in two minds over this:
>
> [format]
> pretty = %h %s
>
> which I currently have in my ~/.gitconfig file. It means that I always
> get git log output as:
>
> 38c0a0c Merge branches 'apei', 'bz-13195' and 'doc' into acpi
> b6fd41e Linux 3.1-rc6
> 8cb3ed17 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux4c75278 Merge branch 'fixes' of git://git.linaro.org/people/arnd/arm-soc
> 14d01ff ioctl: register LTTng ioctl
>
> rather than the more usual medium-pretty output. I can get that by
> using git log --pretty=medium. The alternative to that is to use
> shell aliases to pass the --pretty= argument for a gitslog alias -
> or I believe you can create git command aliases in the ~/.gitconfig file.
> (Never tried it yet, something I need to look at.)
I did:
git config --global alias.lg "log --pretty=oneline --abbrev-commit"
git config --global alias.one "show -s --pretty='format:%h (%s)"
which results in
[alias]
lg = log --pretty=oneline --abbrev-commit
one = show -s --pretty='format:%h (%s)'
and makes available the commands
git lg
(for summary logging) and
git one
(to format a commit id for use in another commit message).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] ARM: mach-qong: Add watchdog support
From: Sascha Hauer @ 2011-09-20 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316440786-21118-1-git-send-email-fabio.estevam@freescale.com>
On Mon, Sep 19, 2011 at 10:59:46AM -0300, Fabio Estevam wrote:
> Add watchdog support for mach-qong target.
Applied to features branch.
Sascha
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> arch/arm/mach-imx/Kconfig | 1 +
> arch/arm/mach-imx/mach-qong.c | 1 +
> 2 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 0519dd7..8748531 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -485,6 +485,7 @@ config MACH_QONG
> bool "Support Dave/DENX QongEVB-LITE platform"
> select SOC_IMX31
> select IMX_HAVE_PLATFORM_IMX_UART
> + select IMX_HAVE_PLATFORM_IMX2_WDT
> help
> Include support for Dave/DENX QongEVB-LITE platform. This includes
> specific configurations for the board and its peripherals.
> diff --git a/arch/arm/mach-imx/mach-qong.c b/arch/arm/mach-imx/mach-qong.c
> index 3626f48..44462ce 100644
> --- a/arch/arm/mach-imx/mach-qong.c
> +++ b/arch/arm/mach-imx/mach-qong.c
> @@ -249,6 +249,7 @@ static void __init qong_init(void)
> mxc_init_imx_uart();
> qong_init_nor_mtd();
> qong_init_fpga();
> + imx31_add_imx2_wdt(NULL);
> }
>
> static void __init qong_timer_init(void)
> --
> 1.6.0.4
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
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 0/7] Add L2 cache cleaning to generic CPU suspend
From: Russell King - ARM Linux @ 2011-09-20 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920034717.GG28084@S2100-06.ap.freescale.net>
On Tue, Sep 20, 2011 at 11:47:18AM +0800, Shawn Guo wrote:
> On Mon, Sep 19, 2011 at 05:37:41PM +0100, Russell King - ARM Linux wrote:
> > This is a re-post of the previous patch series, but with an additional
> > TLB flush to ensure that hte global TLB entry in the page tables is
> > flushed out. This is a flush of all TLB entries, but it could probably
> > be more targetted if we need to.
> >
>
> Here is the diff on suspend.c between last post and this series. With
> the outer_clean_range() calls added back, the series works fine on
> imx6q, otherwise it hangs on resume.
You seem to be missing patch 7 from the second series.
^ permalink raw reply
* [PATCH 3/4] net/fec: set phy_speed to the optimal frequency 2.5 MHz
From: Lothar Waßmann @ 2011-09-20 7:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316346852-17090-4-git-send-email-shawn.guo@linaro.org>
Hi,
Shawn Guo writes:
> With the unnecessary 1 bit left-shift on fep->phy_speed during the
> calculation, the phy_speed always runs at the half frequency of the
> optimal one 2.5 MHz.
>
> The patch removes that 1 bit left-shift to get the optimal phy_speed.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> drivers/net/fec.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> index 5ef0e34..04206e4 100644
> --- a/drivers/net/fec.c
> +++ b/drivers/net/fec.c
> @@ -1007,7 +1007,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
> /*
> * Set MII speed to 2.5 MHz (= clk_get_rate() / 2 * phy_speed)
> */
> - fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000) << 1;
> + fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000);
> writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
>
> fep->mii_bus = mdiobus_alloc();
>
The left shift accounts for the fact, that the MII_SPEED bitfield
starts at pos 1 in the register. Thus the divider value has to be
shifted left to occupy the correct bit positions in the register.
According to my measurements on the TX28 the original code works
correctly!
Did you measure the actual frequency on the MDC pin after you change?
Lothar Wa?mann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
^ permalink raw reply
* [GIT PULL] ux500-core for 3.2
From: Linus Walleij @ 2011-09-20 7:53 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
could you please pull:
git://git.linaro.org/people/triad/linux-stericsson.git for-arnd
to the ARM SoC tree (ux500 branch or however you prefer to handle it)?
They have all been reviewed on the ARM list recently and are mostly
minor fixes and Lee Jones nice cleanup patch.
I might be stacking up more but this is a good start.
The following changes since commit c6a389f123b9f68d605bb7e0f9b32ec1e3e14132:
Linux 3.1-rc4 (2011-08-28 21:16:01 -0700)
are available in the git repository at:
git://git.linaro.org/people/triad/linux-stericsson.git for-arnd
Barry Song (1):
ARM: mach-ux500: add explicit cpu_relax() for busy wait loop
Fredrik Svensson (1):
mach-ux500: remove pull-pinconfig and add SPI2
Lee Jones (1):
mach-ux500: remove most of the ugly machine_is_*() calls
Linus Walleij (2):
mach-ux500: factor out l2x0 handling code
mach-ux500: unlock I&D l2x0 caches before init
srinidhi kasagar (1):
mach-ux500: enable fix for ARM errata 754322
arch/arm/mach-ux500/Kconfig | 1 +
arch/arm/mach-ux500/Makefile | 1 +
arch/arm/mach-ux500/board-mop500-pins.c | 34 ++++--
arch/arm/mach-ux500/board-mop500-sdi.c | 52 ++++++---
arch/arm/mach-ux500/board-mop500.c | 78 +++++++++++---
arch/arm/mach-ux500/board-mop500.h | 3 +
arch/arm/mach-ux500/cache-l2x0.c | 95 +++++++++++++++++
arch/arm/mach-ux500/cpu.c | 69 ------------
arch/arm/mach-ux500/include/mach/uncompress.h | 10 +--
arch/arm/mach-ux500/pins-db8500.h | 142 +++++++++++++------------
arch/arm/plat-nomadik/include/plat/pincfg.h | 5 -
11 files changed, 294 insertions(+), 196 deletions(-)
create mode 100644 arch/arm/mach-ux500/cache-l2x0.c
^ permalink raw reply
* Link failures due to __bug_table in current -next
From: Russell King - ARM Linux @ 2011-09-20 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPnjgZ3+b=nhApZxV1aBGejxEr7MGN1e8neP-ychtVO2Ego2yQ@mail.gmail.com>
On Tue, Sep 20, 2011 at 12:06:22AM -0700, Simon Glass wrote:
> Hi Russell,
>
> On Mon, Sep 19, 2011 at 1:03 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Sep 19, 2011 at 01:09:54PM +0100, Mark Brown wrote:
> >> I'm seeing linker failures in -next as of today:
> >>
> >> `.exit.text' referenced in section `__bug_table' of fs/built-in.o:
> >> defined in discarded section `.exit.text' of fs/built-in.o
> >> `.exit.text' referenced in section `__bug_table' of crypto/built-in.o:
> >> defined in discarded section `.exit.text' of crypto/built-in.o
> >> `.exit.text' referenced in section `__bug_table' of net/built-in.o:
> >> defined in discarded section `.exit.text' of net/built-in.o
> >> `.exit.text' referenced in section `__bug_table' of net/built-in.o:
> >> defined in discarded section `.exit.text' of net/built-in.o
> >>
> >> which appears to be due to the chnage to use generic BUG() introduced in
> >> commit 5254a3 (ARM: 7017/1: Use generic BUG() handler), reverting that
> >> commit resolves the issue for me.
>
> Gosh this does seem a bit odd. Ordering seems to be clearly implied by
> the file syntax and I agree we should seek guidance from binutils
> people.
I'm not sure that there's any value in seeking guidance from the linker
folk - we can see what's going on with a few experiments. That's fine
to find out what current linker behaviour is, but unless the manual
documents it, its something that shouldn't be relied upon.
Here's where I researched what the manual says and what practically happens
with the linker:
http://lists.arm.linux.org.uk/lurker/message/20110808.195805.a073e07d.en.html
> I added the BUG condition to CONFIG_SMP_ON_UP and
> CONFIG_DEBUG_SPINLOCK which were already there. If BUG is causing
> problems, I wonder why these are not? Have we just been lucky, or have
> I crossed a line? Or perhaps there are no spinlocks in exit text?
The other stuff is also having problems. Rob Herring's report was about
the SMP alternatives causing the same problem:
http://lists.arm.linux.org.uk/lurker/message/20110808.184931.a38e1c4e.en.html
> One option is to keep all exit text around - i.e. never discard it at
> link time. From memory it is only 4-8KB. Doubtless many would be upset
> with this, but it could be an option until this binutils behaviour is
> resolved.
We are trying to keep .exit.text around (when certain config options are
set - and they are set - but the linker is deciding to discard it for us
anyway, because asm-generic/vmlinux.lds.S always lists .exit.text in its
discard section.
As we have a discard section at the beginning of the file to discard the
unwinder information for other sections, the one from the generic file
gets merged at the _start_ of the linker file, which results in .exit.text
first appearance to be in the discard section.
It's not that simple though - if you read the quote from the linker manual,
the implication is that the linker would be entirely free to discard an
input section as a priority if it appears in a discard section anywhere
in the linker script. There's nothing to say future linkers won't do
this. It would still be conformant to the linker manual.
> Another is to declare that it is a bug to use BUG in an exit section.
> I was thinking about that at the time, but decided it was probably too
> radical. There are only a small number of references in the kernel I
> think (again from memory - this was back in April I think). Not
> trivial to enforce, and the error you get is not exactly informative.
When a BUG() is inside an inline function which is used in an exit path,
it becomes non-trivial to eliminate. That means there will be hidden
BUG() instances and we really can't ask people to avoid inline functions.
^ permalink raw reply
* [PATCH v2 0/3] ARM: imx: Add cpuidle for imx platforms
From: Amit Kucheria @ 2011-09-20 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920071633.GR31404@pengutronix.de>
On 11 Sep 20, Sascha Hauer wrote:
> Hi Robert,
>
> On Fri, Sep 16, 2011 at 12:27:47PM -0500, Robert Lee wrote:
> > This patch series adds a common imx cpuidle driver, some common
> > mach-mx5 level cpuidle functionality, and an i.MX51 instance of
> > using this driver.
> >
> > The patch series is based on v3.1-rc2.
> >
> > Changes since v1:
> > * To address all the problems found during review of v1, a complete
> > re-write was needed.
>
> Much better than the last version, thanks.
>
> >
> > Robert Lee (3):
> > ARM: imx: Add imx cpuidle driver
> > ARM: imx: Add cpuidle for mach-mx5
> > ARM: imx: Add cpuidle for i.MX51
> >
> > arch/arm/mach-mx5/Makefile | 3 +-
> > arch/arm/mach-mx5/cpu_op-mx51.c | 35 +++++++-
>
> Your additions to this file...
>
> > arch/arm/mach-mx5/cpu_op-mx51.h | 1 +
> > arch/arm/mach-mx5/mm.c | 4 +
> > arch/arm/mach-mx5/system.c | 35 +++++++
>
> And this one should go to arch/arm/mach-mx5/cpuidle.c, then we have
> all i.MX5 specific cpuidle stuff together without ifdeffing the code.
> I assume that cpuidle support for i.MX53 will look identically, right?
Yes, let's not separate only for i.MX51. i.MX53 and even i.MX6 might look
similar. They can always tune the exit latency criteria if needed.
^ permalink raw reply
* [PATCH 0/7] Add L2 cache cleaning to generic CPU suspend
From: Shawn Guo @ 2011-09-20 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920074624.GF16591@n2100.arm.linux.org.uk>
On Tue, Sep 20, 2011 at 08:46:25AM +0100, Russell King - ARM Linux wrote:
> On Tue, Sep 20, 2011 at 11:47:18AM +0800, Shawn Guo wrote:
> > On Mon, Sep 19, 2011 at 05:37:41PM +0100, Russell King - ARM Linux wrote:
> > > This is a re-post of the previous patch series, but with an additional
> > > TLB flush to ensure that hte global TLB entry in the page tables is
> > > flushed out. This is a flush of all TLB entries, but it could probably
> > > be more targetted if we need to.
> > >
> >
> > Here is the diff on suspend.c between last post and this series. With
> > the outer_clean_range() calls added back, the series works fine on
> > imx6q, otherwise it hangs on resume.
>
> You seem to be missing patch 7 from the second series.
>
Oops, indeed. So on imx6q for all the series:
Tested-by: Shawn Guo <shawn.guo@linaro.org>
--
Regards,
Shawn
^ permalink raw reply
* [PATCH 16/18] dmaengine/ambhe rest oa-pl08x: Add support for sg len greater than one for slave transfers
From: Vinod Koul @ 2011-09-20 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E783243.5000404@st.com>
On Tue, 2011-09-20 at 11:57 +0530, Viresh Kumar wrote:
> On 9/20/2011 11:49 AM, Vinod Koul wrote:
> > Applied the remaining two patches for the series to my next
>
> Probably there were three patches left, 18/20, 19/20, 20/20 in V3 of my patchset.
Looks like I had applied patch 20 earlier...
--
~Vinod
^ permalink raw reply
* [PATCH 3/4] net/fec: set phy_speed to the optimal frequency 2.5 MHz
From: Shawn Guo @ 2011-09-20 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20088.17849.987651.196256@ipc1.ka-ro>
On Tue, Sep 20, 2011 at 09:50:17AM +0200, Lothar Wa?mann wrote:
> Hi,
>
> Shawn Guo writes:
> > With the unnecessary 1 bit left-shift on fep->phy_speed during the
> > calculation, the phy_speed always runs at the half frequency of the
> > optimal one 2.5 MHz.
> >
> > The patch removes that 1 bit left-shift to get the optimal phy_speed.
> >
> > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > ---
> > drivers/net/fec.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> > index 5ef0e34..04206e4 100644
> > --- a/drivers/net/fec.c
> > +++ b/drivers/net/fec.c
> > @@ -1007,7 +1007,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
> > /*
> > * Set MII speed to 2.5 MHz (= clk_get_rate() / 2 * phy_speed)
> > */
> > - fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000) << 1;
> > + fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000);
> > writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
> >
> > fep->mii_bus = mdiobus_alloc();
> >
> The left shift accounts for the fact, that the MII_SPEED bitfield
> starts at pos 1 in the register. Thus the divider value has to be
> shifted left to occupy the correct bit positions in the register.
>
Oops, I missed that.
> According to my measurements on the TX28 the original code works
> correctly!
> Did you measure the actual frequency on the MDC pin after you change?
>
I should have done that before sending this patch. I'm working home
these days and have not got the chance get into the lab. Yes, I
should have sent this patch as an RFC at least. Sorry about this,
and thank you for pointing this out.
Will drop this patch from the v2 of the series.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v2] mach-ep93xx: break out GPIO driver specifics
From: Linus Walleij @ 2011-09-20 8:42 UTC (permalink / raw)
To: linux-arm-kernel
From: Linus Walleij <linus.walleij@linaro.org>
The <mach/gpio.h> file is included from upper directories
and deal with generic GPIO and gpiolib stuff. Break out the
platform and driver specific defines and functions into its own
header file.
Cc: Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ryan Mallon <rmallon@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Move the irq_to_gpio() into the driver since it was the only
thing actually using it, as a result the ep93xx gpio.h
is trivial and becomes empty.
- Putting this into the patch tracker as 7042/2 soon-ish.
---
arch/arm/mach-ep93xx/core.c | 1 +
arch/arm/mach-ep93xx/edb93xx.c | 1 +
arch/arm/mach-ep93xx/include/mach/gpio-ep93xx.h | 100 +++++++++++++++++++++
arch/arm/mach-ep93xx/include/mach/gpio.h | 105 -----------------------
arch/arm/mach-ep93xx/simone.c | 2 +-
arch/arm/mach-ep93xx/snappercl15.c | 2 +-
drivers/gpio/gpio-ep93xx.c | 3 +
7 files changed, 107 insertions(+), 107 deletions(-)
create mode 100644 arch/arm/mach-ep93xx/include/mach/gpio-ep93xx.h
diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index a82265b..2432a6b 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -39,6 +39,7 @@
#include <mach/fb.h>
#include <mach/ep93xx_keypad.h>
#include <mach/ep93xx_spi.h>
+#include <mach/gpio-ep93xx.h>
#include <asm/mach/map.h>
#include <asm/mach/time.h>
diff --git a/arch/arm/mach-ep93xx/edb93xx.c b/arch/arm/mach-ep93xx/edb93xx.c
index ace49ee..70ef8c5 100644
--- a/arch/arm/mach-ep93xx/edb93xx.c
+++ b/arch/arm/mach-ep93xx/edb93xx.c
@@ -37,6 +37,7 @@
#include <mach/hardware.h>
#include <mach/fb.h>
#include <mach/ep93xx_spi.h>
+#include <mach/gpio-ep93xx.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
diff --git a/arch/arm/mach-ep93xx/include/mach/gpio-ep93xx.h b/arch/arm/mach-ep93xx/include/mach/gpio-ep93xx.h
new file mode 100644
index 0000000..8aff2ea
--- /dev/null
+++ b/arch/arm/mach-ep93xx/include/mach/gpio-ep93xx.h
@@ -0,0 +1,100 @@
+/* Include file for the EP93XX GPIO controller machine specifics */
+
+#ifndef __GPIO_EP93XX_H
+#define __GPIO_EP93XX_H
+
+/* GPIO port A. */
+#define EP93XX_GPIO_LINE_A(x) ((x) + 0)
+#define EP93XX_GPIO_LINE_EGPIO0 EP93XX_GPIO_LINE_A(0)
+#define EP93XX_GPIO_LINE_EGPIO1 EP93XX_GPIO_LINE_A(1)
+#define EP93XX_GPIO_LINE_EGPIO2 EP93XX_GPIO_LINE_A(2)
+#define EP93XX_GPIO_LINE_EGPIO3 EP93XX_GPIO_LINE_A(3)
+#define EP93XX_GPIO_LINE_EGPIO4 EP93XX_GPIO_LINE_A(4)
+#define EP93XX_GPIO_LINE_EGPIO5 EP93XX_GPIO_LINE_A(5)
+#define EP93XX_GPIO_LINE_EGPIO6 EP93XX_GPIO_LINE_A(6)
+#define EP93XX_GPIO_LINE_EGPIO7 EP93XX_GPIO_LINE_A(7)
+
+/* GPIO port B. */
+#define EP93XX_GPIO_LINE_B(x) ((x) + 8)
+#define EP93XX_GPIO_LINE_EGPIO8 EP93XX_GPIO_LINE_B(0)
+#define EP93XX_GPIO_LINE_EGPIO9 EP93XX_GPIO_LINE_B(1)
+#define EP93XX_GPIO_LINE_EGPIO10 EP93XX_GPIO_LINE_B(2)
+#define EP93XX_GPIO_LINE_EGPIO11 EP93XX_GPIO_LINE_B(3)
+#define EP93XX_GPIO_LINE_EGPIO12 EP93XX_GPIO_LINE_B(4)
+#define EP93XX_GPIO_LINE_EGPIO13 EP93XX_GPIO_LINE_B(5)
+#define EP93XX_GPIO_LINE_EGPIO14 EP93XX_GPIO_LINE_B(6)
+#define EP93XX_GPIO_LINE_EGPIO15 EP93XX_GPIO_LINE_B(7)
+
+/* GPIO port C. */
+#define EP93XX_GPIO_LINE_C(x) ((x) + 40)
+#define EP93XX_GPIO_LINE_ROW0 EP93XX_GPIO_LINE_C(0)
+#define EP93XX_GPIO_LINE_ROW1 EP93XX_GPIO_LINE_C(1)
+#define EP93XX_GPIO_LINE_ROW2 EP93XX_GPIO_LINE_C(2)
+#define EP93XX_GPIO_LINE_ROW3 EP93XX_GPIO_LINE_C(3)
+#define EP93XX_GPIO_LINE_ROW4 EP93XX_GPIO_LINE_C(4)
+#define EP93XX_GPIO_LINE_ROW5 EP93XX_GPIO_LINE_C(5)
+#define EP93XX_GPIO_LINE_ROW6 EP93XX_GPIO_LINE_C(6)
+#define EP93XX_GPIO_LINE_ROW7 EP93XX_GPIO_LINE_C(7)
+
+/* GPIO port D. */
+#define EP93XX_GPIO_LINE_D(x) ((x) + 24)
+#define EP93XX_GPIO_LINE_COL0 EP93XX_GPIO_LINE_D(0)
+#define EP93XX_GPIO_LINE_COL1 EP93XX_GPIO_LINE_D(1)
+#define EP93XX_GPIO_LINE_COL2 EP93XX_GPIO_LINE_D(2)
+#define EP93XX_GPIO_LINE_COL3 EP93XX_GPIO_LINE_D(3)
+#define EP93XX_GPIO_LINE_COL4 EP93XX_GPIO_LINE_D(4)
+#define EP93XX_GPIO_LINE_COL5 EP93XX_GPIO_LINE_D(5)
+#define EP93XX_GPIO_LINE_COL6 EP93XX_GPIO_LINE_D(6)
+#define EP93XX_GPIO_LINE_COL7 EP93XX_GPIO_LINE_D(7)
+
+/* GPIO port E. */
+#define EP93XX_GPIO_LINE_E(x) ((x) + 32)
+#define EP93XX_GPIO_LINE_GRLED EP93XX_GPIO_LINE_E(0)
+#define EP93XX_GPIO_LINE_RDLED EP93XX_GPIO_LINE_E(1)
+#define EP93XX_GPIO_LINE_DIORn EP93XX_GPIO_LINE_E(2)
+#define EP93XX_GPIO_LINE_IDECS1n EP93XX_GPIO_LINE_E(3)
+#define EP93XX_GPIO_LINE_IDECS2n EP93XX_GPIO_LINE_E(4)
+#define EP93XX_GPIO_LINE_IDEDA0 EP93XX_GPIO_LINE_E(5)
+#define EP93XX_GPIO_LINE_IDEDA1 EP93XX_GPIO_LINE_E(6)
+#define EP93XX_GPIO_LINE_IDEDA2 EP93XX_GPIO_LINE_E(7)
+
+/* GPIO port F. */
+#define EP93XX_GPIO_LINE_F(x) ((x) + 16)
+#define EP93XX_GPIO_LINE_WP EP93XX_GPIO_LINE_F(0)
+#define EP93XX_GPIO_LINE_MCCD1 EP93XX_GPIO_LINE_F(1)
+#define EP93XX_GPIO_LINE_MCCD2 EP93XX_GPIO_LINE_F(2)
+#define EP93XX_GPIO_LINE_MCBVD1 EP93XX_GPIO_LINE_F(3)
+#define EP93XX_GPIO_LINE_MCBVD2 EP93XX_GPIO_LINE_F(4)
+#define EP93XX_GPIO_LINE_VS1 EP93XX_GPIO_LINE_F(5)
+#define EP93XX_GPIO_LINE_READY EP93XX_GPIO_LINE_F(6)
+#define EP93XX_GPIO_LINE_VS2 EP93XX_GPIO_LINE_F(7)
+
+/* GPIO port G. */
+#define EP93XX_GPIO_LINE_G(x) ((x) + 48)
+#define EP93XX_GPIO_LINE_EECLK EP93XX_GPIO_LINE_G(0)
+#define EP93XX_GPIO_LINE_EEDAT EP93XX_GPIO_LINE_G(1)
+#define EP93XX_GPIO_LINE_SLA0 EP93XX_GPIO_LINE_G(2)
+#define EP93XX_GPIO_LINE_SLA1 EP93XX_GPIO_LINE_G(3)
+#define EP93XX_GPIO_LINE_DD12 EP93XX_GPIO_LINE_G(4)
+#define EP93XX_GPIO_LINE_DD13 EP93XX_GPIO_LINE_G(5)
+#define EP93XX_GPIO_LINE_DD14 EP93XX_GPIO_LINE_G(6)
+#define EP93XX_GPIO_LINE_DD15 EP93XX_GPIO_LINE_G(7)
+
+/* GPIO port H. */
+#define EP93XX_GPIO_LINE_H(x) ((x) + 56)
+#define EP93XX_GPIO_LINE_DD0 EP93XX_GPIO_LINE_H(0)
+#define EP93XX_GPIO_LINE_DD1 EP93XX_GPIO_LINE_H(1)
+#define EP93XX_GPIO_LINE_DD2 EP93XX_GPIO_LINE_H(2)
+#define EP93XX_GPIO_LINE_DD3 EP93XX_GPIO_LINE_H(3)
+#define EP93XX_GPIO_LINE_DD4 EP93XX_GPIO_LINE_H(4)
+#define EP93XX_GPIO_LINE_DD5 EP93XX_GPIO_LINE_H(5)
+#define EP93XX_GPIO_LINE_DD6 EP93XX_GPIO_LINE_H(6)
+#define EP93XX_GPIO_LINE_DD7 EP93XX_GPIO_LINE_H(7)
+
+/* maximum value for gpio line identifiers */
+#define EP93XX_GPIO_LINE_MAX EP93XX_GPIO_LINE_H(7)
+
+/* maximum value for irq capable line identifiers */
+#define EP93XX_GPIO_LINE_MAX_IRQ EP93XX_GPIO_LINE_F(7)
+
+#endif /* __GPIO_EP93XX_H */
diff --git a/arch/arm/mach-ep93xx/include/mach/gpio.h b/arch/arm/mach-ep93xx/include/mach/gpio.h
index 76c68fa..e69de29 100644
--- a/arch/arm/mach-ep93xx/include/mach/gpio.h
+++ b/arch/arm/mach-ep93xx/include/mach/gpio.h
@@ -1,105 +0,0 @@
-/*
- * arch/arm/mach-ep93xx/include/mach/gpio.h
- */
-
-#ifndef __ASM_ARCH_GPIO_H
-#define __ASM_ARCH_GPIO_H
-
-/* GPIO port A. */
-#define EP93XX_GPIO_LINE_A(x) ((x) + 0)
-#define EP93XX_GPIO_LINE_EGPIO0 EP93XX_GPIO_LINE_A(0)
-#define EP93XX_GPIO_LINE_EGPIO1 EP93XX_GPIO_LINE_A(1)
-#define EP93XX_GPIO_LINE_EGPIO2 EP93XX_GPIO_LINE_A(2)
-#define EP93XX_GPIO_LINE_EGPIO3 EP93XX_GPIO_LINE_A(3)
-#define EP93XX_GPIO_LINE_EGPIO4 EP93XX_GPIO_LINE_A(4)
-#define EP93XX_GPIO_LINE_EGPIO5 EP93XX_GPIO_LINE_A(5)
-#define EP93XX_GPIO_LINE_EGPIO6 EP93XX_GPIO_LINE_A(6)
-#define EP93XX_GPIO_LINE_EGPIO7 EP93XX_GPIO_LINE_A(7)
-
-/* GPIO port B. */
-#define EP93XX_GPIO_LINE_B(x) ((x) + 8)
-#define EP93XX_GPIO_LINE_EGPIO8 EP93XX_GPIO_LINE_B(0)
-#define EP93XX_GPIO_LINE_EGPIO9 EP93XX_GPIO_LINE_B(1)
-#define EP93XX_GPIO_LINE_EGPIO10 EP93XX_GPIO_LINE_B(2)
-#define EP93XX_GPIO_LINE_EGPIO11 EP93XX_GPIO_LINE_B(3)
-#define EP93XX_GPIO_LINE_EGPIO12 EP93XX_GPIO_LINE_B(4)
-#define EP93XX_GPIO_LINE_EGPIO13 EP93XX_GPIO_LINE_B(5)
-#define EP93XX_GPIO_LINE_EGPIO14 EP93XX_GPIO_LINE_B(6)
-#define EP93XX_GPIO_LINE_EGPIO15 EP93XX_GPIO_LINE_B(7)
-
-/* GPIO port C. */
-#define EP93XX_GPIO_LINE_C(x) ((x) + 40)
-#define EP93XX_GPIO_LINE_ROW0 EP93XX_GPIO_LINE_C(0)
-#define EP93XX_GPIO_LINE_ROW1 EP93XX_GPIO_LINE_C(1)
-#define EP93XX_GPIO_LINE_ROW2 EP93XX_GPIO_LINE_C(2)
-#define EP93XX_GPIO_LINE_ROW3 EP93XX_GPIO_LINE_C(3)
-#define EP93XX_GPIO_LINE_ROW4 EP93XX_GPIO_LINE_C(4)
-#define EP93XX_GPIO_LINE_ROW5 EP93XX_GPIO_LINE_C(5)
-#define EP93XX_GPIO_LINE_ROW6 EP93XX_GPIO_LINE_C(6)
-#define EP93XX_GPIO_LINE_ROW7 EP93XX_GPIO_LINE_C(7)
-
-/* GPIO port D. */
-#define EP93XX_GPIO_LINE_D(x) ((x) + 24)
-#define EP93XX_GPIO_LINE_COL0 EP93XX_GPIO_LINE_D(0)
-#define EP93XX_GPIO_LINE_COL1 EP93XX_GPIO_LINE_D(1)
-#define EP93XX_GPIO_LINE_COL2 EP93XX_GPIO_LINE_D(2)
-#define EP93XX_GPIO_LINE_COL3 EP93XX_GPIO_LINE_D(3)
-#define EP93XX_GPIO_LINE_COL4 EP93XX_GPIO_LINE_D(4)
-#define EP93XX_GPIO_LINE_COL5 EP93XX_GPIO_LINE_D(5)
-#define EP93XX_GPIO_LINE_COL6 EP93XX_GPIO_LINE_D(6)
-#define EP93XX_GPIO_LINE_COL7 EP93XX_GPIO_LINE_D(7)
-
-/* GPIO port E. */
-#define EP93XX_GPIO_LINE_E(x) ((x) + 32)
-#define EP93XX_GPIO_LINE_GRLED EP93XX_GPIO_LINE_E(0)
-#define EP93XX_GPIO_LINE_RDLED EP93XX_GPIO_LINE_E(1)
-#define EP93XX_GPIO_LINE_DIORn EP93XX_GPIO_LINE_E(2)
-#define EP93XX_GPIO_LINE_IDECS1n EP93XX_GPIO_LINE_E(3)
-#define EP93XX_GPIO_LINE_IDECS2n EP93XX_GPIO_LINE_E(4)
-#define EP93XX_GPIO_LINE_IDEDA0 EP93XX_GPIO_LINE_E(5)
-#define EP93XX_GPIO_LINE_IDEDA1 EP93XX_GPIO_LINE_E(6)
-#define EP93XX_GPIO_LINE_IDEDA2 EP93XX_GPIO_LINE_E(7)
-
-/* GPIO port F. */
-#define EP93XX_GPIO_LINE_F(x) ((x) + 16)
-#define EP93XX_GPIO_LINE_WP EP93XX_GPIO_LINE_F(0)
-#define EP93XX_GPIO_LINE_MCCD1 EP93XX_GPIO_LINE_F(1)
-#define EP93XX_GPIO_LINE_MCCD2 EP93XX_GPIO_LINE_F(2)
-#define EP93XX_GPIO_LINE_MCBVD1 EP93XX_GPIO_LINE_F(3)
-#define EP93XX_GPIO_LINE_MCBVD2 EP93XX_GPIO_LINE_F(4)
-#define EP93XX_GPIO_LINE_VS1 EP93XX_GPIO_LINE_F(5)
-#define EP93XX_GPIO_LINE_READY EP93XX_GPIO_LINE_F(6)
-#define EP93XX_GPIO_LINE_VS2 EP93XX_GPIO_LINE_F(7)
-
-/* GPIO port G. */
-#define EP93XX_GPIO_LINE_G(x) ((x) + 48)
-#define EP93XX_GPIO_LINE_EECLK EP93XX_GPIO_LINE_G(0)
-#define EP93XX_GPIO_LINE_EEDAT EP93XX_GPIO_LINE_G(1)
-#define EP93XX_GPIO_LINE_SLA0 EP93XX_GPIO_LINE_G(2)
-#define EP93XX_GPIO_LINE_SLA1 EP93XX_GPIO_LINE_G(3)
-#define EP93XX_GPIO_LINE_DD12 EP93XX_GPIO_LINE_G(4)
-#define EP93XX_GPIO_LINE_DD13 EP93XX_GPIO_LINE_G(5)
-#define EP93XX_GPIO_LINE_DD14 EP93XX_GPIO_LINE_G(6)
-#define EP93XX_GPIO_LINE_DD15 EP93XX_GPIO_LINE_G(7)
-
-/* GPIO port H. */
-#define EP93XX_GPIO_LINE_H(x) ((x) + 56)
-#define EP93XX_GPIO_LINE_DD0 EP93XX_GPIO_LINE_H(0)
-#define EP93XX_GPIO_LINE_DD1 EP93XX_GPIO_LINE_H(1)
-#define EP93XX_GPIO_LINE_DD2 EP93XX_GPIO_LINE_H(2)
-#define EP93XX_GPIO_LINE_DD3 EP93XX_GPIO_LINE_H(3)
-#define EP93XX_GPIO_LINE_DD4 EP93XX_GPIO_LINE_H(4)
-#define EP93XX_GPIO_LINE_DD5 EP93XX_GPIO_LINE_H(5)
-#define EP93XX_GPIO_LINE_DD6 EP93XX_GPIO_LINE_H(6)
-#define EP93XX_GPIO_LINE_DD7 EP93XX_GPIO_LINE_H(7)
-
-/* maximum value for gpio line identifiers */
-#define EP93XX_GPIO_LINE_MAX EP93XX_GPIO_LINE_H(7)
-
-/* maximum value for irq capable line identifiers */
-#define EP93XX_GPIO_LINE_MAX_IRQ EP93XX_GPIO_LINE_F(7)
-
-#define gpio_to_irq __gpio_to_irq
-#define irq_to_gpio(irq) ((irq) - gpio_to_irq(0))
-
-#endif
diff --git a/arch/arm/mach-ep93xx/simone.c b/arch/arm/mach-ep93xx/simone.c
index 9ae4ea1..52e090d 100644
--- a/arch/arm/mach-ep93xx/simone.c
+++ b/arch/arm/mach-ep93xx/simone.c
@@ -18,12 +18,12 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/platform_device.h>
-#include <linux/gpio.h>
#include <linux/i2c.h>
#include <linux/i2c-gpio.h>
#include <mach/hardware.h>
#include <mach/fb.h>
+#include <mach/gpio-ep93xx.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
diff --git a/arch/arm/mach-ep93xx/snappercl15.c b/arch/arm/mach-ep93xx/snappercl15.c
index 3cea81f..8121e3a 100644
--- a/arch/arm/mach-ep93xx/snappercl15.c
+++ b/arch/arm/mach-ep93xx/snappercl15.c
@@ -20,7 +20,6 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/io.h>
-#include <linux/gpio.h>
#include <linux/i2c.h>
#include <linux/i2c-gpio.h>
#include <linux/fb.h>
@@ -30,6 +29,7 @@
#include <mach/hardware.h>
#include <mach/fb.h>
+#include <mach/gpio-ep93xx.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
diff --git a/drivers/gpio/gpio-ep93xx.c b/drivers/gpio/gpio-ep93xx.c
index 6a56895..386d9ff 100644
--- a/drivers/gpio/gpio-ep93xx.c
+++ b/drivers/gpio/gpio-ep93xx.c
@@ -24,6 +24,9 @@
#include <linux/module.h>
#include <mach/hardware.h>
+#include <mach/gpio-ep93xx.h>
+
+#define irq_to_gpio(irq) ((irq) - gpio_to_irq(0))
struct ep93xx_gpio {
void __iomem *mmio_base;
--
1.7.3.2
^ 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