* [PATCH v8 19/22] ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
From: Paul Walmsley @ 2013-01-18 20:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358511445-26656-20-git-send-email-rogerq@ti.com>
Hi Roger,
On Fri, 18 Jan 2013, Roger Quadros wrote:
> We don't need multiple aliases for the OMAP USB host clocks and neither
> the dummy clocks so remove them.
>
> CC: Paul Walmsley <paul@pwsan.com>
> CC: Rajendra Nayak <rnayak@ti.com>
> CC: Benoit Cousson <b-cousson@ti.com>
> CC: Mike Turquette <mturquette@linaro.com>
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> Reviewed-by: Felipe Balbi <balbi@ti.com>
> Acked-by: Paul Walmsley <paul@pwsan.com>
Per Tony's earlier request, you can drop this patch and patch 20 from your
series now. I've got them queued for 3.10 or late 3.9 merge window.
- Paul
^ permalink raw reply
* Compilation problem with drivers/staging/zsmalloc when !SMP on ARM
From: Matt Sealey @ 2013-01-18 20:24 UTC (permalink / raw)
To: linux-arm-kernel
Hello all,
I wonder if anyone can shed some light on this linking problem I have
right now. If I configure my kernel without SMP support (it is a very
lean config for i.MX51 with device tree support only) I hit this error
on linking:
MODPOST 216 modules
LZMA arch/arm/boot/compressed/piggy.lzma
AS arch/arm/boot/compressed/lib1funcs.o
ERROR: "v7wbi_flush_kern_tlb_range"
[drivers/staging/zsmalloc/zsmalloc.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
make: *** Waiting for unfinished jobs....
I am wondering if someone who is far better versed in the mm code can
tell me exactly what would end up calling this function and why it
would only be in the kernel at all if SMP was enabled - all I can see
right now is that it is PROBABLY something resulting from this code
and comment inside the zsmalloc driver:
/*
* By default, zsmalloc uses a copy-based object mapping method to access
* allocations that span two pages. However, if a particular architecture
* 1) Implements local_flush_tlb_kernel_range() and 2) Performs VM mapping
* faster than copying, then it should be added here so that
* USE_PGTABLE_MAPPING is defined. This causes zsmalloc to use page table
* mapping rather than copying
* for object mapping.
*/
#if defined(CONFIG_ARM)
#define USE_PGTABLE_MAPPING
#endif
And of course, once USE_PGTABLE_MAPPING is enabled,
local_flush_tlb_kernel_range being used is the actual culprit here.
But the question is, for the ARM guys, shouldn't
local_flush_tlb_kernel_range actually be defined in the kernel build,
even without SMP, even if it would be architecturally a no-op on UP
systems, and then CONFIG_SMP_ON_UP would catch this case?
If not, then the fix is obvious, the check inside zsmalloc for
CONFIG_ARM should be fixed to check specifically for
local_flush_tlb_kernel_range definition as well, or for CONFIG_SMP as
well, or the non-presence of CONFIG_SMP_ON_UP or something?
The build cases I have tested are basically CONFIG_SMP +
CONFIG_SMP_ON_UP (since it's a single-core Cortex-A8) and without
CONFIG_SMP (since it's a Cortex-A8..) using imx_v7_defconfig and
imx_v6_v7_defconfig alike and making the appropriate adjustments.
Trying to compile it with CONFIG_SMP without CONFIG_SMP_ON_UP makes no
sense on my target system - but essentially it only links with
CONFIG_SMP.
I got no clue what I am looking at in arch/arm/mm and related, so I am
unsure precisely how I should proceed in patching it with the intent
it goes upstream.. or what the real implication of this kind of memory
management actually is on SMP vs. UP systems, but the intended
functionality of local_flush_tlb_kernel_range seems like it should
exist even on UP, to me.
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply
* [PATCH 2/2] pinctrl: nomadik: Allow prcm_base to be extracted from Device Tree
From: Linus Walleij @ 2013-01-18 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357919129-1928-2-git-send-email-lee.jones@linaro.org>
On Fri, Jan 11, 2013 at 4:45 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The Nomadik Pinctrl driver requires access to some PRCMU registers
> in order to run with full functionality. When Device Tree is
> disabled the required PRCMU base address is passed in via platform
> data, so in order for Device Tree booting to be as functional, we
> need a similar mechanism to fetch it from Device Tree.
>
> The new semantics goes like this: Parse the Device Tree and look
> for the PRCMU node using a provided Phandle. Obtain the ioremaped
> address from that node. If one was supplied via platform data
> over-write it with anything found in Device Tree. Fail if either
> the prcm_base can't be found if we're running on anything other
> than an STN8815 ASIC.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Applied as well, notice I had to add this hunk to the first
patch to have things working:
diff --git a/arch/arm/boot/dts/dbx5x0.dtsi b/arch/arm/boot/dts/dbx5x0.dtsi
index 05d97f6..96f518b 100644
--- a/arch/arm/boot/dts/dbx5x0.dtsi
+++ b/arch/arm/boot/dts/dbx5x0.dtsi
@@ -192,6 +192,7 @@
prcmu: prcmu at 80157000 {
compatible = "stericsson,db8500-prcmu";
reg = <0x80157000 0x1000>;
+ reg-names = "prcmu";
interrupts = <0 47 0x4>;
#address-cells = <1>;
#size-cells = <1>;
Lest the code won't find the prcmu registers.
Yours,
Linus Walleij
^ permalink raw reply related
* [PATCH 3/7] ARM i.MX6q: Add GPU, VPU, IPU, and OpenVG resets to System Reset Controller (SRC)
From: Matt Sealey @ 2013-01-18 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358352787-15441-4-git-send-email-p.zabel@pengutronix.de>
On Wed, Jan 16, 2013 at 10:13 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> The SRC has auto-deasserting reset bits that control reset lines to
> the GPU, VPU, IPU, and OpenVG IP modules. This patch adds a reset
> controller that can be controlled by those devices using the
> reset controller API.
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Hi Philipp,
I'm so glad someone actually sat down and coded this :)
+
+static int imx_src_reset(unsigned long sw_reset_idx)
+{
Having a name like imx_src_reset seems needlessly generic and
confusing. Surely we are performing a reset on an SoC unit and not
having the SRC itself reset, even if it is clearer when we look at the
argument?
+ timeout = jiffies + msecs_to_jiffies(1000);
+ while (readl(src_base + SRC_SCR) & bit) {
+ if (time_after(jiffies, timeout))
+ return -ETIME;
+ cpu_relax();
... I do wonder though, all versions of the very-similar i.MX SRC
(i.MX51, i.MX53, i.MX6) implementing these bits actually have an
interrupt (with the same status-bit positions as the reset-enable
register) which fires when the unit actually resets.
Rather than poll with a timeout shouldn't we be waiting for the
interrupt and doing some completion event? It seems a little overly
involved to me to poll and cpu_relax() when we can just let the kernel
do whatever it likes while the hardware does the job.
It is technically impossible for the unit to "never reset" without
there being something hideously wrong elsewhere (i.e. if you ask the
VPU to reset, and it never fires the interrupt, you have far, far more
problems than just a locked VPU), but we actually should have no idea
without some empirical data (under every scenario at least) how long
it would actually take so having a timeout seems rather odd. Having a
timeout of a full second also *seems* to be far too long under the
same circumstances but I don't think anyone can predict what the real
values might be.
I looked at writing this exact same kind of code a long while back
including support for i.MX51 and i.MX53 as a cleanup for the older
version of Sascha's IPU driver, and simply never got it nice enough to
submit upstream (it is currently stuffed away in a huge backup disk
and I have no idea where the kernel tree is), but the way I handled it
was something like registering a real interrupt handler in the src
initialization function and then simply setting the bit and letting
the completion event do the work. I also did have a timeout for 5000ms
which basically would still capture any reset oddities - if we passed
5 seconds, and the unit did not reset, to start executing WARN_ON or
something to give the kernel developer (or user) a real indication
that something is *actually* hideously wrong with their board
implementation or the stability of their SoC, power rails, heatsink
etc.. or million other possibilities (any warning is at least better
than none).
I could never get the warning code to ever execute except in a
contrived test scenario (I set a reserved bit and faked that it never
fired an interrupt) but in my opinion, ANY warning on this kind of
failure to reset is better than just returning -ETIME to the reset
consumer and hoping the consumer reports a reasonable error to the
kernel log - if the SRC fails to reset a unit then this is not an
error condition so low in seriousness that telling the consumer
something timed out is adequate (based on the intended and functional
implementation of the SRC controller itself). As I said, what I
decided on was that I would return -ETIMEDOUT (the wrong code, but
bear with me, I was hacking) but before return, pr_err the problem
unit, and then WARN_ON inside the SRC driver itself, so that
everything would carry on (no system lockups or panics), but the
driver was not responsible for reporting the problem and the
seriousness was implicated in something a little more noticable than a
single line in a log.
I understand that waiting on an interrupt or completion event is not
available infrastructure in the current reset-controller code... but
maybe it should be a little more advanced than polling implementation
:D
I am not not-acking the code, and I would be overjoyed for it to go in
as-is (maybe with a function rename as above), but I would appreciate
the consideration that a reset-controller with some way of reporting a
successful reset other than polling is something that might come in
handy for other people (and i.MX SRC would be a highly desirable use
case) and at the very least in the case of the i.MX SRC, "this unit
did not reset after [possibly more than] a whole second of waiting" is
not encompassed within if (ret) pr_err("unit did not reset") in the
driver.. nor would this be an immediate and serious indication to the
driver or end-user.
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply
* [PATCH v8 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
From: Ezequiel Garcia @ 2013-01-18 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115180324.GZ14149@atomide.com>
Tony,
On Tue, Jan 15, 2013 at 3:03 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Daniel Mack <zonque@gmail.com> [130114 15:30]:
>> On Jan 15, 2013 2:06 AM, "Tony Lindgren" <tony@atomide.com> wrote:
>> >
>> > * Ezequiel Garcia <elezegarcia@gmail.com> [121223 13:49]:
>> > > On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack <zonque@gmail.com> wrote:
>> > > > +
>> > > > +Example for an AM33xx board:
>> > > > +
>> > > > + gpmc: gpmc at 50000000 {
>> > > > + compatible = "ti,am3352-gpmc";
>> > > > + ti,hwmods = "gpmc";
>> > > > + reg = <0x50000000 0x1000000>;
>> > > > + interrupts = <100>;
>> > > > + gpmc,num-cs = <8>;
>> > > > + gpmc,num-waitpins = <2>;
>> > > > + #address-cells = <2>;
>> > > > + #size-cells = <1>;
>> > > > + ranges = <0 0 0x08000000 0x2000>; /* CS0: NAND
>> */
>> > > > +
>> > > > + nand at 0,0 {
>> > > > + reg = <0 0 0>; /* CS0, offset 0 */
>> > >
>> > > I'm a bit confused by this: what are the other two values in "reg"?
>> > > I see you've only added a binding for CS.
>> > >
>> > > I've extended a bit on your work and added a binding to enable OneNAND
>> > > device on my IGEP board.
>> > >
>> > > I might send some patches in case anyone wants to give it a try.
>> >
>> > Daniel, should this be updated to just pass the CS?
>>
>> No, as Rob pointed out earlier in a thread about this topic, the 'ranges'
>> feature will help doing the math for the offset calculation eventually, so
>> we need to pass all three values.
>
> OK thanks. Applying this set into omap-for-v3.9/gpmc.
>
> Also sounds like Ezequiel needs to update his follow up patches accordingly.
>
The patches for OneNAND that were posted on the ML apply cleanly
on top omap-for-v3.9/gpmc.
What do you want me to update?
--
Ezequiel
^ permalink raw reply
* [PATCH 1/2] ARM: ux500: Provide a link from AB8500 Pinctrl to the PRCMU
From: Linus Walleij @ 2013-01-18 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357919129-1928-1-git-send-email-lee.jones@linaro.org>
On Fri, Jan 11, 2013 at 4:45 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The AB8500 Pinctrl driver uses PRCMU register addresses to
> control Pinctrl related functions. For this to happen, the
> Pinctrl driver needs the PRCMU base to work from. We can do
> that using standard Open Firmware (of_*) function calls, but
> first we need a mechanism to gain access to the PRCMU
> device node. We're going to use a Phandle in this case.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Patch applied to the pinctrl tree (so as to be adjacent to
the patch altering the code).
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/3] pinctrl: exynos: add exynos5250 SoC specific data
From: Linus Walleij @ 2013-01-18 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <00df01cdeed1$f08d73b0$d1a85b10$@samsung.com>
On Thu, Jan 10, 2013 at 2:29 AM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> Linus Walleij wrote:
>> On Thu, Dec 27, 2012 at 5:58 PM, Kukjin Kim <kgene.kim@samsung.com>
>> wrote:
>>
>> > And I think, would be clear if the config could be changed like
> following.
>> >
>> > 8<----------------------------------------------------------------------
>> > From: Kukjin Kim <kgene.kim@samsung.com>
>> > Subject: [PATCH] pinctrl: exynos: change PINCTRL_EXYNOS option
>> >
>> > Since pinctrl-exynos can support exynos4 and exynos5 so changed
>> > the option name to PINCTRL_EXYNOS for more clarity.
>> >
>> > Cc: Thomas Abraham <Thomas.abraham@linaro.org>
>> > Cc: Linus Walleij <linus.walleij@linaro.org>
>> > Cc: Grant Likely <grant.likely@secretlab.ca>
>> > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
>>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>
>> Shall I take this into the pinctrl tree?
>>
> Yes, please :-)
OK I did.
> Just note, regarding Samsung pinctrl changes in the following:
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> next/pinctrl-exynos
Hm. I had to use patch -p1 < ... to apply the patch, which indicates
there may be merge clashes.
Anyway, it's merged now.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] pinctrl: mvebu: Fix compiler warnings
From: Linus Walleij @ 2013-01-18 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357756089-6028-1-git-send-email-andrew@lunn.ch>
On Wed, Jan 9, 2013 at 7:28 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> match->data is const void * where as dev.platform_data is just void *.
> Add a cast to remove the const, which is causing the compiler warning:
>
> drivers/pinctrl/mvebu/pinctrl-kirkwood.c:461:26: warning: assignment
> discards 'const' qualifier from pointer target type
>
> Dove has the exact same warning, so gets the same cast.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Applied with Jason's ACK.
Thanks!
Linus Walleij
^ permalink raw reply
* [PATCH] pinctrl: mvebu: fix MPP6 value for kirkwood driver
From: Linus Walleij @ 2013-01-18 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357681024-4686-1-git-send-email-simon.guinot@sequanux.org>
On Tue, Jan 8, 2013 at 10:37 PM, Simon Guinot <simon.guinot@sequanux.org> wrote:
> Note that I am not sure about the MPP value for the PTP functionality.
> It seems that the PTP references have been removed from the Marvell
> hardware specifications available to me.
>
> Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Applied with Jason's and Andrew's ACKs!
Thanks!
Linus Walleij
^ permalink raw reply
* [PATCH 3/7] ARM: pinctrl: sunxi: Add the pinctrl pin set for sun5i
From: Linus Walleij @ 2013-01-18 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357681398-23956-4-git-send-email-maxime.ripard@free-electrons.com>
On Tue, Jan 8, 2013 at 10:43 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Since the Allwinner SoCs variants don't have the same set of pins to
> handle, we need to declare the pin ranges available.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
(...)
> static struct of_device_id sunxi_pinctrl_match[] __devinitconst = {
I think __devinitconst is also deprecated.
> + { .compatible = "allwinner,sun5i-a13-pinctrl", .data = (void *)&sun5i_a13_pinctrl_data },
> {}
> };
> MODULE_DEVICE_TABLE(of, sunxi_pinctrl_match);
Aha so the match table is in the subdrivers, hm.... OK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCHv3 0/7] Add pinctrl driver for Allwinner A1X SoCs
From: Linus Walleij @ 2013-01-18 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaTFMuN1EteHLTgO7TM8BLr9P_YjuKrwuDGoPtQ57duDw@mail.gmail.com>
On Thu, Jan 17, 2013 at 2:31 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Jan 15, 2013 at 11:19 AM, Maxime Ripard
>> Are you ok with this version or do you have additionnal comments ?
>
> I'm probably OK with it, I've only just now reached this point in my
> mail backlog.
As noted I had more comments, they should be quick to address.
When finished, shall this be applied to the pinctrl tree or some other
subtree, like ARM SoC?
In that case I should probably remove the patch adding the drive
strength parameter from my tree so tell me how to proceed...
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/7] ARM: sunxi: Add pinctrl driver for Allwinner SoCs
From: Linus Walleij @ 2013-01-18 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357681398-23956-3-git-send-email-maxime.ripard@free-electrons.com>
On Tue, Jan 8, 2013 at 10:43 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> +config PINCTRL_SUNXI
> + bool
> + select PINMUX
> + select GENERIC_PINCONF
Very nice that you use generic pinconf!
> +++ b/drivers/pinctrl/pinctrl-sunxi.c
(...)
> + switch (pinconf_to_config_param(config)) {
> + case PIN_CONFIG_DRIVE_STRENGTH:
> + strength = pinconf_to_config_argument(config);
> + /*
> + * We convert from mA to what the register expects:
> + * - 0: 10mA
> + * - 1: 20mA
> + * - 2: 30mA
> + * - 3: 40mA
> + */
Nitpick: remove the "-" (dash), some newcomer will invariably
interpret the numbers as negative :-/
Don't you want some bounds checking here?
if (strength > 40) { bail out }
> + dlevel = strength / 10 - 1;
> + val = readl(pctl->membase + sunxi_dlevel_reg(g->pin));
> + mask = ((1 << DLEVEL_PINS_BITS) - 1) << sunxi_dlevel_offset(g->pin);
Uhhh ... ((1 << DLEVEL_PINS_BITS) - 1) ...
Which in this case is ((1 << 4) - 1). So ...
10000 - 1 = 01111
So this is a way to say "mask four lowest bits".
What about just adding this instead then:
#define DLEVEL_PINS_MASK 0x0f
> + val &= ~mask;
> + val |= dlevel << sunxi_dlevel_offset(g->pin);
> + writel(val, pctl->membase + sunxi_dlevel_reg(g->pin));
> + break;
> + case PIN_CONFIG_BIAS_PULL_UP:
> + val = readl(pctl->membase + sunxi_pull_reg(g->pin));
> + mask = ((1 << PULL_PINS_BITS) - 1) << sunxi_pull_offset(g->pin);
Same. #define a MASK.
> + val &= ~mask;
> + val |= 1 << sunxi_pull_offset(g->pin);
> + writel(val, pctl->membase + sunxi_pull_reg(g->pin));
> + break;
> + case PIN_CONFIG_BIAS_PULL_DOWN:
> + val = readl(pctl->membase + sunxi_pull_reg(g->pin));
> + mask = ((1 << PULL_PINS_BITS) - 1) << sunxi_pull_offset(g->pin);
Dito.
> + val &= ~mask;
> + val |= 2 << sunxi_pull_offset(g->pin);
> + writel(val, pctl->membase + sunxi_pull_reg(g->pin));
> + break;
> + default:
> + break;
> + }
> +
> + /* cache the config value */
> + g->config = config;
> +
> + return 0;
> +}
(...)
> +static void sunxi_pmx_set(struct pinctrl_dev *pctldev,
> + unsigned pin,
> + u8 config)
> +{
> + struct sunxi_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
> +
> + u32 val = readl(pctl->membase + sunxi_mux_reg(pin));
> + u32 mask = ((1 << MUX_PINS_BITS) - 1) << sunxi_mux_offset(pin);
Dito.
> + writel((val & ~mask) | config << sunxi_mux_offset(pin),
> + pctl->membase + sunxi_mux_reg(pin));
> +}
(...)
> +static struct of_device_id sunxi_pinctrl_match[] __devinitconst = {
> + {}
> +};
What is this supposed to match?
Maybe I don't understand DT boilerplate at all times, bear with me.
> +MODULE_DEVICE_TABLE(of, sunxi_pinctrl_match);
(...)
> +static int __devinit sunxi_pinctrl_add_function(struct sunxi_pinctrl *pctl,
> + const char *name)
__devinit is deleted in the kernel so I would get a regression if I
tried to apply this patch. Just remove __devinit.
(...)
> +static int __devinit sunxi_pinctrl_build_state(struct platform_device *pdev)
Dito.
(...)
> +static int __devinit sunxi_pinctrl_probe(struct platform_device *pdev)
Dito.
(...)
> +++ b/drivers/pinctrl/pinctrl-sunxi.h
(...)
> +/*
> + * The sunXi PIO registers are organized as is:
> + * 0x00 - 0x0c Muxing values.
> + * 8 pins per register, each pin having a 4bits value
> + * 0x10 Pin values
> + * 32 bits per register, each pin corresponding to one bit
> + * 0x14 - 0x18 Drive level
> + * 16 pins per register, each pin having a 2bits value
> + * 0x1c - 0x20 Pull-Up values
> + * 16 pins per register, each pin having a 2bits value
> + *
> + * This is for the first bank. Each bank will have the same layout,
> + * with an offset being a multiple of 0x24.
> + *
> + * The following functions calculate from the pin number the register
> + * and the bit offset that we should access.
> + */
Very nice with this documentation!
Yours,
Linus Walleij
^ permalink raw reply
* [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
From: Tony Lindgren @ 2013-01-18 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358536096.6252.121.camel@cumari.coelho.fi>
* Luciano Coelho <coelho@ti.com> [130118 11:12]:
> On Fri, 2013-01-18 at 09:36 -0800, Tony Lindgren wrote:
> > * Luciano Coelho <coelho@ti.com> [130118 01:03]:
> > > On Thu, 2013-01-17 at 15:16 -0800, Tony Lindgren wrote:
> > > > * Luciano Coelho <coelho@ti.com> [130117 10:04]:
> > > > > But this patch is pretty small and simple, so why not include it to at
> > > > > least fix the breakage in 3.7 and 3.8? Whether you take it or not now
> > > > > won't make any difference in the 5k LOC in these kernel versions.
> > > >
> > > > Well we are planning to drop the non-DT support for omap4 as soon as it's
> > > > usable with DT. For omap4 we are only carrying SDP and panda support to
> > > > make this transition easier. The only bindings missing AFAIK are wl12xx and
> > > > USB.
> > >
> > > In my view this is a regression and it should be fixed with as simple a
> > > patch as possible. The alternative to my solution is to revert the
> > > patch that removed the enable/disable from the ti-st driver *and* fix
> > > u-boot, because if it doesn't mux the UART2 pins properly (and it
> > > doesn't) the shared transport still won't work.
> >
> > Fixing the muxing here makes sense naturally as we cannot do that in the driver
> > until we've flipped things over to use DT.
> >
> > But I don't think we should fix the driver regression by adding more platform
> > callbacks as we are getting rid of them anyways.
>
> Okay, you're right. We need at least to pass the GPIO number from the
> board file to the driver so that it knows what to switch. This is also
> something that it will need from DT in the future.
Yes I agree, the GPIO number needs to be passed in the fix.
> > > > If we add this, then it implies we're somehow supporting it, which is not
> > > > the way to go IMHO as we need to get rid of these platform callbacks instead.
> > >
> > > It's a regression fix, not a new feature. I also think these callbacks
> > > are silly, but it's the quickest solution I found for 3.7 and 3.8.
> >
> > Right, so how about let's fix the regression in the driver, and add the
> > muxing to platform init code?
>
> Agreed. I'll cook up a patch to revert the changes in eccf2979 (it
> doesn't revert cleanly) and change the panda board file to do the muxing
> and set the gpio number in the pdata for the driver to use.
OK thanks.
> > > > What's your estimate of having minimal wl12xx WLAN DT binding available?
> > >
> > > To tell you the truth, I haven't even started looking into DT for wl12xx
> > > myself. So I have no idea when it will be ready. Benoit has been
> > > looking into it, but I don't know how far he is.
> >
> > If it's going to take long we should just init the platform data for
> > it temporarily even in the DT boot case until the binding is available.
>
> I'll start looking into this now. It's not going to be that simple, I'm
> sure, but I need to look more into DT in general to be able to say
> something more accurate. I'll let you know as soon as I know more. :)
OK thanks!
Tony
^ permalink raw reply
* [PATCH v4] sdma-imx: Add SDMA firmware for Freescale i.MX SOCs
From: Fabio Estevam @ 2013-01-18 19:22 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@freescale.com>
Add SDMA firmware for Freescale i.MX SOCs.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v3:
- Drop 'q' from imx6 file name
Changes since v2:
- Drop unrecognized chars by replacing double spaces with tabs, which caused
issues on some mail clients
Changes since v1:
- Drop 'to' information from the file name.
LICENCE.fsl_firmware | 140 +++++++++++++++++++++++++++++++++++++++++++
WHENCE | 13 ++++
imx/sdma/sdma-imx25.bin | Bin 0 -> 694 bytes
imx/sdma/sdma-imx31.bin | Bin 0 -> 3762 bytes
imx/sdma/sdma-imx35.bin | Bin 0 -> 1746 bytes
imx/sdma/sdma-imx51.bin | Bin 0 -> 1894 bytes
imx/sdma/sdma-imx53.bin | Bin 0 -> 1406 bytes
imx/sdma/sdma-imx6.bin | Bin 0 -> 1838 bytes
8 files changed, 153 insertions(+)
create mode 100644 LICENCE.fsl_firmware
create mode 100644 imx/sdma/sdma-imx25.bin
create mode 100644 imx/sdma/sdma-imx31.bin
create mode 100644 imx/sdma/sdma-imx35.bin
create mode 100644 imx/sdma/sdma-imx51.bin
create mode 100644 imx/sdma/sdma-imx53.bin
create mode 100644 imx/sdma/sdma-imx6.bin
diff --git a/LICENCE.fsl_firmware b/LICENCE.fsl_firmware
new file mode 100644
index 0000000..a1fef32
--- /dev/null
+++ b/LICENCE.fsl_firmware
@@ -0,0 +1,140 @@
+FREESCALE SEMICONDUCTOR SOFTWARE LICENSE AGREEMENT
+
+This is a legal agreement between you (either as an individual or as an
+authorized representative of your employer) and Freescale
+Semiconductor, Inc. ("Freescale"). It concerns your rights to use this
+file and any accompanying written materials (the "Software"). In
+consideration for Freescale allowing you to access the Software, you
+are agreeing to be bound by the terms of this Agreement. If you do not
+agree to all of the terms of this Agreement, do not download the
+Software. If you change your mind later, stop using the Software and
+delete all copies of the Software in your possession or control. Any
+copies of the Software that you have already distributed, where
+permitted, and do not destroy will continue to be governed by this
+Agreement. Your prior use will also continue to be governed by this
+Agreement.
+
+LICENSE GRANT. Freescale grants to you, free of charge, the
+non-exclusive, non-transferable right (1) to reproduce the Software,
+(2) to distribute the Software, and (3) to sublicense to others the
+right to use the distributed Software. The Software is provided to you
+only in object (machine-readable) form. You may exercise the rights
+above only with respect to such object form. You may not translate,
+reverse engineer, decompile, or disassemble the Software except to the
+extent applicable law specifically prohibits such restriction. In
+addition, you must prohibit your sublicensees from doing the same. If
+you violate any of the terms or restrictions of this Agreement,
+Freescale may immediately terminate this Agreement, and require that
+you stop using and delete all copies of the Software in your possession
+or control.
+
+COPYRIGHT. The Software is licensed to you, not sold. Freescale owns
+the Software, and United States copyright laws and international treaty
+provisions protect the Software. Therefore, you must treat the Software
+like any other copyrighted material (e.g. a book or musical
+recording). You may not use or copy the Software for any other purpose
+than what is described in this Agreement. Except as expressly provided
+herein, Freescale does not grant to you any express or implied rights
+under any Freescale or third-party patents, copyrights, trademarks, or
+trade secrets. Additionally, you must reproduce and apply any copyright
+or other proprietary rights notices included on or embedded in the
+Software to any copies or derivative works made thereof, in whole or in
+part, if any.
+
+SUPPORT. Freescale is NOT obligated to provide any support, upgrades
+or new releases of the Software. If you wish, you may contact Freescale
+and report problems and provide suggestions regarding the
+Software. Freescale has no obligation whatsoever to respond in any way
+to such a problem report or suggestion. Freescale may make changes to
+the Software at any time, without any obligation to notify or provide
+updated versions of the Software to you.
+
+NO WARRANTY. TO THE MAXIMUM EXTENT PERMITTED BY LAW, FREESCALE
+EXPRESSLY DISCLAIMS ANY WARRANTY FOR THE SOFTWARE. THE SOFTWARE IS
+PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
+IMPLIED, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
+NON-INFRINGEMENT. YOU ASSUME THE ENTIRE RISK ARISING OUT OF THE USE OR
+PERFORMANCE OF THE SOFTWARE, OR ANY SYSTEMS YOU DESIGN USING THE
+SOFTWARE (IF ANY). NOTHING IN THIS AGREEMENT MAY BE CONSTRUED AS A
+WARRANTY OR REPRESENTATION BY FREESCALE THAT THE SOFTWARE OR ANY
+DERIVATIVE WORK DEVELOPED WITH OR INCORPORATING THE SOFTWARE WILL BE
+FREE FROM INFRINGEMENT OF THE INTELLECTUAL PROPERTY RIGHTS OF THIRD
+PARTIES.
+
+INDEMNITY. You agree to fully defend and indemnify Freescale from any
+and all claims, liabilities, and costs (including reasonable attorney's
+fees) related to (1) your use (including your sublicensee's use, if
+permitted) of the Software or (2) your violation of the terms and
+conditions of this Agreement.
+
+LIMITATION OF LIABILITY. IN NO EVENT WILL FREESCALE BE LIABLE, WHETHER
+IN CONTRACT, TORT, OR OTHERWISE, FOR ANY INCIDENTAL, SPECIAL, INDIRECT,
+CONSEQUENTIAL OR PUNITIVE DAMAGES, INCLUDING, BUT NOT LIMITED TO,
+DAMAGES FOR ANY LOSS OF USE, LOSS OF TIME, INCONVENIENCE, COMMERCIAL
+LOSS, OR LOST PROFITS, SAVINGS, OR REVENUES TO THE FULL EXTENT SUCH MAY
+BE DISCLAIMED BY LAW.
+
+COMPLIANCE WITH LAWS; EXPORT RESTRICTIONS. This software may be
+subject to the U.S. Export Regulations and/or the regulatory authority
+of the country in which the download takes place. By downloading this
+software you understand and agree to comply with all applicable export
+control regulations when further transferring or exporting the software
+either as downloaded or as integrated into other software or
+commodities.
+
+GOVERNMENT USE. Use of the Software and any corresponding
+documentation, if any, is provided with RESTRICTED RIGHTS. Use,
+duplication or disclosure by the Government is subject to restrictions
+as set forth in subparagraph (c)(1)(ii) of The Rights in Technical Data
+and Computer Software clause at DFARS 252.227-7013 or subparagraphs
+(c)(l) and (2) of the Commercial Computer Software--Restricted Rights
+at 48 CFR 52.227-19, as applicable. Manufacturer is Freescale
+Semiconductor, Inc., 6501 William Cannon Drive West, Austin, TX, 78735.
+
+HIGH RISK ACTIVITIES. You acknowledge that the Software is not fault
+tolerant and is not designed, manufactured or intended by Freescale for
+incorporation into products intended for use or resale in on-line
+control equipment in hazardous, dangerous to life or potentially
+life-threatening environments requiring fail-safe performance, such as
+in the operation of nuclear facilities, aircraft navigation or
+communication systems, air traffic control, direct life support
+machines or weapons systems, in which the failure of products could
+lead directly to death, personal injury or severe physical or
+environmental damage ("High Risk Activities"). You specifically
+represent and warrant that you will not use the Software or any
+derivative work of the Software for High Risk Activities.
+
+CHOICE OF LAW; VENUE; LIMITATIONS. You agree that the statutes and
+laws of the United States and the State of Texas, USA, without regard
+to conflicts of laws principles, will apply to all matters relating to
+this Agreement or the Software, and you agree that any litigation will
+be subject to the exclusive jurisdiction of the state or federal courts
+in Texas, USA. You agree that regardless of any statute or law to the
+contrary, any claim or cause of action arising out of or related to
+this Agreement or the Software must be filed within one (1) year after
+such claim or cause of action arose or be forever barred.
+
+PRODUCT LABELING. You are not authorized to use any Freescale
+trademarks, brand names, or logos.
+
+ENTIRE AGREEMENT. This Agreement constitutes the entire agreement
+between you and Freescale regarding the subject matter of this
+Agreement, and supersedes all prior communications, negotiations,
+understandings, agreements or representations, either written or oral,
+if any. This Agreement may only be amended in written form, executed by
+you and Freescale.
+
+SEVERABILITY. If any provision of this Agreement is held for any
+reason to be invalid or unenforceable, then the remaining provisions of
+this Agreement will be unimpaired and, unless a modification or
+replacement of the invalid or unenforceable provision is further held
+to deprive you or Freescale of a material benefit, in which case the
+Agreement will immediately terminate, the invalid or unenforceable
+provision will be replaced with a provision that is valid and
+enforceable and that comes closest to the intention underlying the
+invalid or unenforceable provision.
+
+NO WAIVER. The waiver by Freescale of any breach of any provision of
+this Agreement will not operate or be construed as a waiver of any
+other or a subsequent breach of the same or a different provision.
diff --git a/WHENCE b/WHENCE
index 96142c2..64892f5 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2046,3 +2046,16 @@ Downloaded from http://linuxwireless.org/en/users/Drivers/carl9170
Licence: GPLv2. Some build scripts use the New BSD (3-clause) licence.
--------------------------------------------------------------------------
+
+Driver: imx-sdma -- Freescale i.MX SDMA driver
+
+File: imx/sdma/sdma-imx25.bin
+File: imx/sdma/sdma-imx31.bin
+File: imx/sdma/sdma-imx35.bin
+File: imx/sdma/sdma-imx51.bin
+File: imx/sdma/sdma-imx53.bin
+File: imx/sdma/sdma-imx6.bin
+
+License: Redistributable. See LICENCE.fsl_firmware for details
+
+--------------------------------------------------------------------------
diff --git a/imx/sdma/sdma-imx25.bin b/imx/sdma/sdma-imx25.bin
new file mode 100644
index 0000000000000000000000000000000000000000..7514e09fea71dc9473121bbe066798d4475ac26f
GIT binary patch
literal 694
zcmZ`#&ubG=5T2dgeTi*}<WLPkO0l@9=2F2^#e?FZAVJ(nl_;`C3h9O{9);%ZUPHuq
z$zcT#1qt-xf8fESn#O~e5`xjPjSx_wB1$1x6xMm03jV->VP?Mfee=He(&tlWB^bpK
zDl?R8lo14YL+Mk9Q&ImHD=~nQ4Ddk#I7e0Ro)Koyd{PC7QH?Qx4eD#uBXJz+JNw+f
z_X25uVd8Ev-;PAtp~Z6j1mDh7;9*@WzPtA2#>eX==7*!;&pv at +y04D&=Y_s3^KSlP
zFX^iJUNd1Icap9|s7feq#OyfDYW_|$WHV=5f1h5fzvg7g4S`}z<c8@AK7z-MyNat^
zR>~~thHxU+FN7pN*EUYk<mYB-5?q>KgqE--%ctctkQ(DkxCU<_&R0=d=`DS>{iRQ~
z5^iIZ!-a#zGRSkU3jO>fOajt5fM@%+wrqL+Wx>mr_puJCHf;v;jjb!Yde{8ESix$1
z-E3u-af(-`239+}lWAoauw%8%s<uO%fz`@dnBXmQ#*vOeO5+uD1I at Z+;8)(xZZ@8}
z1M5CW(_N7GJy=zRB0`EWN1EO%dM0z|w^IlBCA!xUuQP?}D*c3KesgX%itb$FPfw^X
z<6&~d^aW&@s>XB+HQIPI at Q?^Rpl;wU_sp0hw#g5EcOdxxIv5Weya*h4=8r%(axo+q
GP4_1z5*wKS
literal 0
HcmV?d00001
diff --git a/imx/sdma/sdma-imx31.bin b/imx/sdma/sdma-imx31.bin
new file mode 100644
index 0000000000000000000000000000000000000000..7ff9c75f4ca366154b778d677c8af92ce9faecf3
GIT binary patch
literal 3762
zcma)9YitzP6+V0K%<Rif*6SJ@{J>yr20JJfO+^b7S}9Es;KuBFQ(`b#kL$`i&aS9Z
z1*h!H{^*YoV?%yWb>Fy at h&U;tiqwi%)OBg%QClU(PF33!sAE+G;wT`L3W#8P?#w=I
zBGuB&+}V5Q-1B|sJLev|pKkqu35>rQd^F(o7GAc;08Zk>_oy+)a{%drzh5pj-d9%}
z&+pU$bfSUhmgUzS$KU>qzn#D}6}WyJ=YCfO at HAe3s|D!BYX#2#JY%E4d~T at kj_dbX
z%S>fE at 9mvWH7J)lrguL~Ef3D_xzTxhZ`x7 at Y4HLa=I%Z36?mmfXbGBMD)+AlcL_~O
z<xA8*L<ac*?#pS5Y7Wh|Uvf>mOGmFNK)A41po-ah+qEuCy*FIP!3-sGiENh4a*Hg=
z>}|IFS7V2`FxSpChQYEaybpJCw9TiwlvIbd`|jR{sk_e;w6!gKF<|!J>P(lG@#)$N
zJhc8$*=H}KEv|C+SpwU*peSz)0oM^e0{;M$G6cgswK>TJ;=tJ&g>0)=OxqgtZ$5Kt
zQlsjnL~#%&vC7Ls>|UeamxgFPZ2cn0Y?r%Z;R>h#(yvK&If`R8vf+q5tun<u0d|EC
zjEVAtkl}gCr6Ky`y2n7C&Eb(2;CUDE{IdwpGYjyfrA;bue|{t$F@tBRa>dU)Ek>m2
zh%_CMCKn^(BUk*)drjsdSN#SeHfA_Y{ZkSN0;IzG$I{XRwGh#75Yf9~Ag9BL(fO25
z*;i7=eWU#^9fM?M*L{rAeLYHb5wriVyC?Rf(Wi9vd9H$+al?*hm3_7{((G}%hTuHF
zR&($y#;-gm`qpB^o{Sv9y{9;nG6=&Q^XLPQ-M>Z^{dFOLwUPQd!BgKf1YX_}d{Owo
zvqh*@ZGJ}xc2p}<9Ko;Z3%)DG?+AYPN(9x_TjDqOnEfq&(a+w@Fwx%5y&4gHw?h-{
z17O7JAUTHE>LNgvL>zTl{e5>qyao_iq53M7ivdj%)t?YcCT>iHRYBk)5hqD+7=S6B
zsnB7Y3~2Jl)1q7%(lymKKW*$gj=K&Zc0;WnPyZS{cn!V&d#@;)LKDpY;#}!%=YAg<
z<}Gy>0|zPHm{;b1R8jsEF^>ig=?b;V|H5Ccg)B`1-13;EH;Iuof8e5=00-$1p&MY^
zw}ONEvqa%6$Kf)pQif at mBmGusjl4=NkyfglWt=Wm>Met0`G(^#PD$_(&~FY?wsTdl
zQx$tL3Q%vEqF<toaY_|7UlC<qFe at gsA^@BDuX2c^Po1C@sEEfggKyPZEaRLhI0&P=
zhB?}Am-r4-?G1Ib4YRhNciClAttii;b=Yw|*c8o1<rfR0;)zoKWFT7;?sh`!-bGoo
z1+%Cpn&o+zzuZYno%{vf!B67))e33F%FwzjQyILJSFAmas!eK8k3?-!y=v{LQ=Pn%
zKSi>+^m(Q_yd7mYHF+e;RBOwO*w~I^ikWoT(;a0IE$N-~Kr6+)h;k-c36(gLfUi8m
zyk1?a9B_s^g*7lOeOi=tucJmhQ6R1;%R1NBWZg8furTXb#=#CzY4)7QT*Iv9=A)(^
zk1P3H%Vv$eN9Y77QA<NNqqZK4Is{mO;Vu3}LFn8fkdTo%&bD#Poh32$e3=u1%^sG+
z%x+aIn@4{{Z>Q1QOSyPGvmjn;V=M<I1Js|58ML-2EiR*iYtnLz)#g|}R$kzPR{~aP
ziK@wEp$cH{R|7WbF?_d%t_8AO1MsRTv?<28?!|kF+|FszUA4T;@a;YHY;6okb1X5+
zv^1Yuqd3}99r^R+K#cuf=$BIwb-x(KftXzqRG~vaMRJY2GQjr0deY9J6<6u#Wwd_)
z?eEXoe?_-nc!IqXqyDV&#&hQw)9jCp`sjAL&QjRU_WKiZVAPLcex`E*wNs!|jO<O9
zmt=I>-Js6JY~2MqrNVBb=A%w=t<&`|hC1yQc0Y*eI?ar9?r=<lGai8VbVO_?L#6gO
zQ|Sz<^!_518rf(tdl-?wgUC<jkbiptvtpdBHy1>_Cc`YA**-g-0PEv|%c0t3(Z}ih
zmMH7vj9+9p-zn&9i at rM{gYl1WUoj43m2RDN48a9j>yA$b-p}pIc=i_62FCNt at x0cG
z>%tS5tE;ds)G2c>WKP(w7FCnhs9Miz>>a4$G&xPlII9e0WQ4HlP_6e4pJl4U+|KiH
z<D@+o|1fvbo{N8kW8<tfD#XtaYr3F5Xgc$ct`C}Yqo_W-hAea=3*LBE*TF@)yB>f4
zYjoGSNOxZ$AH}-M^YF<FOiedkTGtb**4>Oeh^m(uJgiLUJkSw(3e{JW<v~~9Cp*8N
zKps$OTM`)_^s&K%F=J@(p3X#GgRP1GPlE at Mh3m+|T#kjVMJ&jP;`1B3NA#{alXKbb
z@zq2gKeapQ1?s?z#O`rBo)O!zd(;^a+}J%5>>jC;TKlkj#5;D6c+d4(I`VS~<BS&E
z_P(<?CjEljh9ma0_F?zf2e3bZ-J`F#d;BfpkrP0En#e}gy9m!jVo~>4fQM;&_K{ey
zbJVfuonr<K>N$f(>sx_1w7xq1Zs-|%VI56Fl68)PTkBhyG&)CPoW-aiB7k*QuO;@6
z6;_B7h-L!Oe3(dg_hQfOqhBZj7%S#edlqEv<|NCug}wgf+!-OtPhrJqOCBaimtB-K
z$w#V{qu3E)mnCh*96Z{@`mz97r?9@>)ChRGA0}aa?ZtqX+*U-nJal^OjpSV52$<@#
z|0}R>s_+{=WU9ZX_w_$YzD^E|4VaE4MfrZFcQb0<Nkp_c31lPAe2%t`C3oT3{YEky
zEzhE8jp(R~6}Uc+N$-Qt>6nPiN0uNW!L^kL9Y>o4SAaZ;e%0t$YIQ6GtN$Iu;l#b~
jBnwfn)x{{zWKfV}qOTamX+$xCDBjGVAjcSrJIVh6jpfqk
literal 0
HcmV?d00001
diff --git a/imx/sdma/sdma-imx35.bin b/imx/sdma/sdma-imx35.bin
new file mode 100644
index 0000000000000000000000000000000000000000..cfe72272ae8064c5526aef7ac398dc224cc9f240
GIT binary patch
literal 1746
zcmZ`(U2GIp6h3q3&dj!3+b&RBD_|AfR?tX at Ci0uqm{@~FobI-`bencblVz5!JeauF
zxij%a%NAOat;x&?b`!+#f)Bn)NTAyY6GbeRQlwdGQllm{DrwSSiW$$$bS;TEo3r=c
z at BDo;=bYR2a%(dO{<9XB4Jc<&Hi`g05C8`sSL?3-_Z+DQ7~lbRqR&gXwm$;!Jz|R#
zpc|zQ<s$)LJIWFYL7UGJo5ZygGluqm)L|l&w^2&Co7=@U7q%4^+GjfYsl=X>(h^~p
z)2oeXl-IozhdUuX*Evk9Y1NKgCtn#7o%I*QDUoBx#LtBJ_)>HT6!c3;RK1SqQOMK0
z_?A?`(vrYP#!d*aP3kKK$q2HogmLHNLBt<l#)HaQwMnVh{W#?+ycSRuiDyDAq(=-v
zuGDf7*z=7FFc+DRLTfpDqcGF4#<-G97!}D+Kteouv!_6e`RGYFDmdjK;?$oL^1>JN
zER9eR4kPb}+p}XE+3na6oEQtMKkomt>(|Z!(FugWX*v&!ZL>m<ebqP1^K2?Lesk0i
zQomek)SlKy4GvKO(a_~Otsc)p>cdNtChE84pWDuiO*0_x7!uI#isWM35IF^B3xm|a
zyjgM7kVr*xwol at m<V5!wJUPiGJh`@b0v{b9r+I!mztep)8aNHNpq}Lk_ukFk-!-TA
zH;o1+NQlAiDm4rI=I{DuQ#DWn1oZ$#%{efm@!P)bE2gr`*d%&g(?qYjGaU<ZKNZ=#
zl&F`Kd&XrHP8o(NzzRa%tzdhG?m_)yY7O>VKjoR7*s4{V<%t)yK!D5C5;69?&Ta5D
z&uHsVvuRlqjy0kNcK@XAFkMbH&`-;ln1P_35MvzvhhwWz=ORH52_jOV9u9{1)olQ7
zHA7xC?_o7xH7k-5xJ(COuUQMHz_(KhJ%u}lzds~#>gK{yS5{1UyM?ZqHz)TEbJbkc
z)<MXQZDJQ=_Wl!Njp_h@M4an%9tsK0y7R&=30mveVXU?$l`)1L+a$kl-j!z}=gAdP
zrm7y2MP$-P7|@J42p44=YkUK1oHU)l1<<8O*#KSndc(xoQtinqQj0%l%PMk9AnGpZ
zOY>7wB!s!UE|mGGfnR$;UWzDEnBjY{MKdLJs0Ss=l9-*VoG^3yZeU%8AQ#OGxp-bA
z84{)Obt>!$pdHUhv{oycG`>bZBIfo&3&(7;*{T82vul+|^vU?M_+6T<TEI3_xrQ80
zgaj?Oj+>K*Rx%0JgEHBDRrh5o(^gq_pZIU4zcJHxYg}20()55Rb}x;uM6r9zv==NI
zUy0ISHCsL>=a9>)G}D}V+{~EneEZX at OGM2JQOliYcap2gx#d}Q?<~Ko37b|9Si*hX
zywqOmLW$9g=-xOeRVuUGQxH!<r5x{?fR6WHtK@aw0qg6+2iDa>g!U9VEkE{@veZ6A
zM(W2EJ8_V#XCv$9(i4gKn4M at LlWAKS3D3(@%3Rt`q)8*Ql?^)g6tsrf5HUQT at pL!2
z!zL2f3RkVU^e}J at rH*kuD$%1{=NkS}i;CzmDf5^dv+zbxT(5n2dlZ$sdQTy1mEO0+
ziO2^@Eiw}27M#qHuqdZV7$ZL6acJ~75V at Nyu%c3 at yU{`)-_O9c|1X1}$6(rHP*m=D
Mem;vuWO3d42fN~Kr~m)}
literal 0
HcmV?d00001
diff --git a/imx/sdma/sdma-imx51.bin b/imx/sdma/sdma-imx51.bin
new file mode 100644
index 0000000000000000000000000000000000000000..3569ca052af5ca763bb8aaa9d5a67fcb404c0aff
GIT binary patch
literal 1894
zcmZ`(ZERCj7=G`$AML#z9~%x9!pZ>c3KJNjXmA*bm at JZ_-mV=K!RG3ca%P+P%OUsN
z8`O|x#4RQ>X}dophQx&UQv(T_wGE>`FpQLC!)44^qr at QrX9!wjea~$>N6<F!z2|+-
zdCz&C=bm$d`vQ9f0N}9>V-v>b7~d!W9}s{t{xEgky!~IlubKdMhyeQ~fca`o8L>7Q
z;8Vmh*q6a}ABKwgIUG~Ow~6 at D`A%RB&!PHu+I(@$`<B-$tHT|cE$n7w2o7X?=J$v1
z9=-L(fKqnXL)m{3?g!^&54#kf6Gb-J`|5OCQtmxD-fC^O+mZsJGNR|ko2<2%%e@=M
zU6x|s)PD*d%1kjJV$uatv at Ui(I7B{!aQ3v6l)9urr7h_qb+Ng)ODM-CqEBO1j`=a;
zV=;pYIzY~f;`8Dj2xv@lpM~#WEjvSm6Vp9+ta8t7OL9+;dItMfn1dj;UyaZ8HbNs1
z><5^&%5TkB;_h$bv%P~=tbkS5ECrf;E4_W5dT~{-aPTygj&@{1Y%G#Ld?53>IUq{$
z^0Iol+<Z|kg>#9#@tpNG at vsI`-aSWTa~RIZe3dV!K^jh0M)1BtfKI~B$Yaxf`nY`>
z#`JvftaK=Ioe2_<Q%ScsmmvLl!$VhEe!9vAaQhT+dovEIQW;Tq6?MUtn4b#v4RoT8
z)=|ljXdCrY%wk<Q+lR at A*}q(6{~-LLc`Y#@!lD8QY-ju%Z__Ujctth;)(fwl$ChN4
zjdd1Cza@uZ5<Ki<R8<OJLoTY3rvUZVGW%|_qO=q)AntK+*%A=v{900+TbEQeN>)Yf
zq0HBg)*q5LGR4eH_ku1^KD*$|K7XVX?w9=RxU|~j{tbwl;dTrCYlsqQwrg!)WQ{Fs
zg8lc*io!^Wk8K1A*H<DQ!xwRxcp5?wP}rZiMmuK_Tb0$aTT^_^;+w@s*6o)>T=hw|
z%RDZvH}8aDMO2ZQ+Vhg78GEf$Db0AnQhPeA2Dw50f<#>+D}@U2Pg13j)Le+?>2_OK
zFSbDEkLCr$rs9ntJ1%jjrsC(T7)Lckcq~OZ&b{L?6<1B%^Z1py0v9SMcE5uPuEZ)D
zj- at KjRa9(v#67NK3)_J@S{#4ogQx{hpxW~+YI(-Gjar^UE$xe1h^a(=Px&IPRSmbQ
zzBZ=0rz(1?qNk5x#&ZpGZ885p*Nfd(7hS*NxL(q8bU~LN;#+aOjd_vnPRI39DC#0C
z7vGbXnsf2I(P2du!d8+7qS9S9f9`ai?NzQnoA0Jeq08tu|I5zV;pgXayl)Zbs787G
zi*igwOhrsH{dA_g=D6(anb!1s*)B=TZcNwq=~Cu=mvWysv-QY)n^`>4hquA6A#@tq
zEBa{Kr|-0)a*g>`hw~QaS#$Xpvltq8JmnrLx`+BOE>&GtbPaRO$$77enMze;%6ZOo
zL!iR*qbkpn>B?!Eq^0l>8Cjb{ZO4e0jd+WR31dEzH#$ink*6cRd3}-=@y1G!R+gum
zY~cwA_}CChIyJdOl-y$z#{1c((PCm4gqGUb<Q2=YLbHXIKg?OGAP)$rj$2b{yp1WZ
zI*2#-EPY^W+3SnW)i at FT7+Hgi6ulGA^N3H;6U2uzZge=bIvj`|B at 1kpHraf(!=p<X
b at bQl_@Hh-MjB*CE^e?Bb!s0%%@Q(fiL0+tj
literal 0
HcmV?d00001
diff --git a/imx/sdma/sdma-imx53.bin b/imx/sdma/sdma-imx53.bin
new file mode 100644
index 0000000000000000000000000000000000000000..34933b1a23337d147d8fedacd225ef3e71c8423e
GIT binary patch
literal 1406
zcmZuwPi)&%82|kIY{w4Je^e`IrA450tUxy^hCo%N2 at X5Zft+~R!qP<%MV(heIgyF?
z9Ek&L4Aw(9*pVjXfCLB)E<2S;Yudwn7^i5hx~SSA2oM$9p_+u2L-?NEG_6!yKj(eF
z_ws$epZ$HwcczX@03dJ>@dDyU#3}{&f&jGkxqiYu0Yiy!R0a^(#Pb5b4FJS&UtkG&
zfp(goabMtb<OJIMyLk3vgy2LDaf!Wff%zKMdb)A0k=`;Tdjal(#J`1#vY9PVnO~$Y
z^JDBH9bykoL03*yxIXi?Yvhl+!=90!boH4Dw^!*^u9KW5^QKjEM!lv*2Ww7Xj}@gM
zc^FRo!IH?WIsKp%^n73otU2a3Cs+d+f!(a&<H!lDIXb)VXhqa-!IZ`yR~u>7)8NkR
z6SIBG#<J|KS354A-{YcrD)ModA4MO-Y(Cy2Zzj=;EWEsdUS4;<L@%$Qmm@n~2vajx
zy+meY+r!`C|N4@@di_Arg__axiOeq;iP*r{*og%bM<$Mp#v;vXsQEl<jue072_1dO
zIZa~g)#miq>V<H%HC;bbJG~%vOI>eXfr;uUU&;g at oUD$pOY&v4aklkjkJ1{vsZ44x
zHNfX%J>Y6O=NjRM%s;*V%zEl3xkGfuLgpbdwTR(BH at qvbWCqDI)m0AUcdr$@1x2l&
zU!t9FzCe2MZoPF+A#73`@V_S;gmAH%Mr>Lh_QjUjOxaq3qjqlj7qm1xuTegW6{V-f
z{L<-F?4YYqvMNd`TTw}YSTsAx;A9NX$(&dR+zFp%pDtcjOYg%8iI4adzaP}_+<O|a
zUd)c+yQugF;1m3nhD+8p(BOylM_z5NQ|ZHfD+Ny1u1dQ5sUJA%PNlP0sqC-Voh)DN
zlO>p;*-n;VMt8qMy`3yY%o1s8%?VXFK`GIf5_{xrcw*f$dPwWpqDELnx#3 at fZ<Ix)
zqI8o*dYz`I8ctl(T(P%IWlyh0ojS^&!%iI!C$4Gb@V%}$cYQjz;sp5#H>VQbjo(PO
zj}^spJbWJ6?$f`RUT#{qan{7G6oP!*7P#%ic6h-W$Qrv?!Rg59$QkUAT~D{CO~KBs
zr*HY6EvKllyy!=hwpV$3#$Mt>sQgvd$j)P*{%hfsp?cLEFDJ}#H>b3fzY=Ob96s9<
v_77`V)8$AvEvRPPP9U-&BVq$%BaB6)W2D<UDiu2GX_$(19xO*XpDF(j%k|mP
literal 0
HcmV?d00001
diff --git a/imx/sdma/sdma-imx6.bin b/imx/sdma/sdma-imx6.bin
new file mode 100644
index 0000000000000000000000000000000000000000..f3a1cff11ad262d84da8403f8510e44d175815f9
GIT binary patch
literal 1838
zcmZ`(PfQ$T6#wSi`Li<%@=t`&E?}e!7As0qjY>$W9ymZX1H)2eaUI3Nz%F=lTj!fe
zjM3IA9N;jsgk%p*JecaGCI%bJvWLzA4}?%eLOiTdBT*07M7xLeeKWf(By=Wk=DlCu
zpWplDz3G3o?>vJLqH+=>1ab at H3Xjl-7@<5|V7hOrKkU*PJfA&?`L5p6{jB$1@g0r-
zvXJ+KLwGOv#tZ(a5Kn8-+SFD-9)lYE352rgopAQeY<OR0v^lhi81gwvaeI*j>m!%h
zr^s{qWwuHGYY<gLd5(x<uNabg-e|TYwc8NKx{PYBn!Aakf{)~sjaa*tQ`q1}%+Web
zrpecgdVbOS0o#hzA}%4Sjz(oGCKoV@N`O!~j8Z%R7?rJ<sQ(-jOoa9n)F+S!>1>#{
z1hh6 at HeRzTt@^C(bg7HSk93h6^!hkWo`pV|^_f7GZ?7ME at zGwMhhEMZA44yl(91Ii
zy<nXmp0z^5t%V+bcjIdMzqV=-3tjNTq8b|h3M^_%U`q!!MFM~X01<SLGw*Vq0L~uc
zcP+}JrhiIc^zC$R^izJ))%HhsE^Z9XF_lck3)fLsx}B^HJ8xV_x9V4Y*ZAy6zPyUd
z2XAxT0_v+LGyW=M2qGZ@CT;Ss*1z)3z-_#SMO}B1zX93s5Q5lU>pEJIo&JmIdj#Ph
zti1mYGKE at ll`VbqIb02Q{>7g-tal6b_6 at v?F`?Qh$ev=sT<pua0Zj-I;7$~KQV8o4
z0!zlBBJ)UxJwJ30CTJGTD=BV1lHzd!D{LgFqYHlU^AW7n8C^CTdDOhd&%cg(7}9E|
z>{`UTey<5wX^C{eS)}YbG!1X2d0tsU0{UY6zO^w`s`SpWm7G|`p-Q6hp6$f=gGwV%
zDQRc4QkGAS$>NN$kx~|COf(jNZz+ojSv*epDar~qXn at Woqu;l7Evo0GDx7aH1+1sI
zTlNzAj9cbXTqRy+Z?Xd{?`~X9&S?8GcVt$*No^;MFsWzVjms%fIM+;U(`JL2n4`XA
zM0rdq;TwtCIg>s+-Dh#ve$&NdPPq%aMsF_Rr~!@2-I)IXr>F#|bO@!G2$%?%sJCgw
zUE^SGcfxn<_g4p4X?5B5_UtI{;)Xp*nt=DydNwixQ~IX@I|kf&xicA(&l*v#$oq`T
z__X^h?$;lBR*57%)@*{816l}V#6_qrfi1Z<wM4K)t;lmHjQTvDCz2k|`Xv1uP?ovD
zS-jAYfzBpy3t4E)#5dxO+JhZ!A!HS-Ua+iCCQfZfrCJm=$Wh}EA!>~#a|-pHA|EB&
zw0e_OudIHX%*N-?kDT|Pq<)p)Cz(w1e{ga<{H0J|xqEK$q<~npO#236AGonY at crAg
ze@tn0GFduHk0q8Ta1c21au4Q*DL-EB1<i7`D3)|9#LIE~1XK&UtXjxAWUg~F<HZsu
z>h&;A=>n(xF`T|nGV#D$9Y#PsV+7uAH_FQESb8t9{@@zN=w;>W8mf3%aHe;sPnxr6
z2{Ge=OLfNPB<sfsXS!Ob(gT+&jG`s!yVHJieS)c=5k8Y)5L>+{pgjDy5w2eRA5gZD
ASpWb4
literal 0
HcmV?d00001
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 1/1 net-next] net: fec: enable pause frame to improve rx prefomance for 1G network
From: David Miller @ 2013-01-18 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358391358-27977-1-git-send-email-Frank.Li@freescale.com>
From: Frank Li <Frank.Li@freescale.com>
Date: Thu, 17 Jan 2013 10:55:58 +0800
> The limition of imx6 internal bus cause fec can't achieve 1G perfomance.
> There will be many packages lost because FIFO over run.
>
> This patch enable pause frame flow control.
...
> Signed-off-by: Frank Li <Frank.Li@freescale.com>
> Signed-off-by: Fugang Duan <B38611@freescale.com>
Applied.
^ permalink raw reply
* [PATCH v3] sdma-imx: Add SDMA firmware for Freescale i.MX SOCs
From: Matt Sealey @ 2013-01-18 19:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358437708-18717-1-git-send-email-fabio.estevam@freescale.com>
On Thu, Jan 17, 2013 at 9:48 AM, Fabio Estevam
<fabio.estevam@freescale.com> wrote:
> Add SDMA firmware for Freescale i.MX SOCs.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> Changes since v2:
> - Drop unrecognized chars by replacing double spaces with tabs, which caused
> issues on some mail clients
> Changes since v1:
> - Drop 'to' information from the file name.
>
> LICENCE.fsl_firmware | 140 +++++++++++++++++++++++++++++++++++++++++++
> WHENCE | 13 ++++
> imx/sdma/sdma-imx25.bin | Bin 0 -> 694 bytes
> imx/sdma/sdma-imx31.bin | Bin 0 -> 3762 bytes
> imx/sdma/sdma-imx35.bin | Bin 0 -> 1746 bytes
> imx/sdma/sdma-imx51.bin | Bin 0 -> 1894 bytes
> imx/sdma/sdma-imx53.bin | Bin 0 -> 1406 bytes
> imx/sdma/sdma-imx6q.bin | Bin 0 -> 1838 bytes
Hi Fabio,
You are an absolute star; but I would suggest only that sdma-imx6q.bin
is misnamed here, since this firmware works on *all* i.MX6 models
(Quad, Dual, DualLite, Solo, SoloLite) and not just q for Quad.. is
there any reason why it would have to have this very
SoC-variant-specific naming convention if we also dropped support for
naming tapeouts for each chip?
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply
* [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
From: Luciano Coelho @ 2013-01-18 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130118173635.GE15361@atomide.com>
On Fri, 2013-01-18 at 09:36 -0800, Tony Lindgren wrote:
> * Luciano Coelho <coelho@ti.com> [130118 01:03]:
> > On Thu, 2013-01-17 at 15:16 -0800, Tony Lindgren wrote:
> > > * Luciano Coelho <coelho@ti.com> [130117 10:04]:
> > > > But this patch is pretty small and simple, so why not include it to at
> > > > least fix the breakage in 3.7 and 3.8? Whether you take it or not now
> > > > won't make any difference in the 5k LOC in these kernel versions.
> > >
> > > Well we are planning to drop the non-DT support for omap4 as soon as it's
> > > usable with DT. For omap4 we are only carrying SDP and panda support to
> > > make this transition easier. The only bindings missing AFAIK are wl12xx and
> > > USB.
> >
> > In my view this is a regression and it should be fixed with as simple a
> > patch as possible. The alternative to my solution is to revert the
> > patch that removed the enable/disable from the ti-st driver *and* fix
> > u-boot, because if it doesn't mux the UART2 pins properly (and it
> > doesn't) the shared transport still won't work.
>
> Fixing the muxing here makes sense naturally as we cannot do that in the driver
> until we've flipped things over to use DT.
>
> But I don't think we should fix the driver regression by adding more platform
> callbacks as we are getting rid of them anyways.
Okay, you're right. We need at least to pass the GPIO number from the
board file to the driver so that it knows what to switch. This is also
something that it will need from DT in the future.
> > > If we add this, then it implies we're somehow supporting it, which is not
> > > the way to go IMHO as we need to get rid of these platform callbacks instead.
> >
> > It's a regression fix, not a new feature. I also think these callbacks
> > are silly, but it's the quickest solution I found for 3.7 and 3.8.
>
> Right, so how about let's fix the regression in the driver, and add the
> muxing to platform init code?
Agreed. I'll cook up a patch to revert the changes in eccf2979 (it
doesn't revert cleanly) and change the panda board file to do the muxing
and set the gpio number in the pdata for the driver to use.
> > > What's your estimate of having minimal wl12xx WLAN DT binding available?
> >
> > To tell you the truth, I haven't even started looking into DT for wl12xx
> > myself. So I have no idea when it will be ready. Benoit has been
> > looking into it, but I don't know how far he is.
>
> If it's going to take long we should just init the platform data for
> it temporarily even in the DT boot case until the binding is available.
I'll start looking into this now. It's not going to be that simple, I'm
sure, but I need to look more into DT in general to be able to say
something more accurate. I'll let you know as soon as I know more. :)
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH 5/5] ARM: dts: OMAP5: Specify nonsecure PPI IRQ for arch timer
From: Santosh Shilimkar @ 2013-01-18 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F98176.6070703@arm.com>
On Friday 18 January 2013 10:38 PM, Marc Zyngier wrote:
> On 18/01/13 17:00, Santosh Shilimkar wrote:
>> On Friday 18 January 2013 09:32 PM, Marc Zyngier wrote:
>>> On 18/01/13 15:32, Santosh Shilimkar wrote:
>>>> From: Rajendra Nayak <rnayak@ti.com>
>>>>
>>>> Specify both secure as well as nonsecure PPI IRQ for arch
>>>> timer. This fixes the following errors seen on DT OMAP5 boot..
>>>>
>>>> [ 0.000000] arch_timer: No interrupt available, giving up
>>>>
>>>> Cc: Benoit Cousson <b-cousson@ti.com>
>>>>
>>>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>>>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>> ---
>>>> arch/arm/boot/dts/omap5.dtsi | 16 ++++++++++++----
>>>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
>>>> index 790bb2a..7a78d1b 100644
>>>> --- a/arch/arm/boot/dts/omap5.dtsi
>>>> +++ b/arch/arm/boot/dts/omap5.dtsi
>>>> @@ -35,8 +35,12 @@
>>>> compatible = "arm,cortex-a15";
>>>> timer {
>>>> compatible = "arm,armv7-timer";
>>>> - /* 14th PPI IRQ, active low level-sensitive */
>>>> - interrupts = <1 14 0x308>;
>>>> + /*
>>>> + * PPI secure/nonsecure IRQ,
>>>> + * active low level-sensitive
>>>> + */
>>>> + interrupts = <1 13 0x308>,
>>>> + <1 14 0x308>;
>>>
>>> Care to add the virtual and HYP timer interrupts? So KVM can get a
>>> chance to run on this HW...
>>>
>> Thanks Marc for spotting it. Will take care of it.
>
> I just realised something silly... You have one timer node *per cpu*,
> and this is not really expected.
>
This was discussed on the list here [1]
Benoit suggested to add per CPU node since arch timer is per
CPU and DT should describe the hw the way it is. Did we miss
something ?
> The driver really wants one single node. See
> arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts for an example.
>
I remember adding only one node based on above file and then
updating the patch based on the comment.
> Oh, and your GIC node could do with some updating too (no VGIC regs or
> interrupt).
>
Will have a look at that as well.
Regards
Santosh,
[1] https://patchwork.kernel.org/patch/1312061/
^ permalink raw reply
* [RESEND PATCH v9 0/2] usb: phy: samsung: Introducing usb phy driver for samsung SoCs
From: Felipe Balbi @ 2013-01-18 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358499623-13901-1-git-send-email-p.paneri@samsung.com>
Hi,
On Fri, Jan 18, 2013 at 02:30:21PM +0530, Praveen Paneri wrote:
> Changes from v8:
> Resending this patch series after rebasing to the latest usb-next branch.
> Rewording inline comments for better readability.
> Removed IS_ENABLED(CONFIG_OF) as pdev->dev.of_node is enough to check for dt support.
> Using of_match_ptr to add of_match_table to platform_driver structure.
> Removed unnecessary variables.
>
> Changes from v7:
> Rebased to the latest usb-next branch.
> Separating arch patches from these driver patches.
>
> Changes from v6:
> Modified register definitions according to the existing ones.
> Changed default PHY clk selection for SoCs.
> Improved binding text and rebased to the latest usb-next.
>
> Changes from v5:
> Moved clk_get() to driver's probe function. Now reference clock frequency
> selection value is stored in samsung_usbphy structure for later use. Used
> IS_ENABLED() instead of #ifdef in samsung_usbphy_get_driver_data().
>
> Changes from v4:
> Moved header file contents to driver's source file
> Removed unnecessary print message from driver's probe function
> Dropped the Free Software Foundation address from the header
>
> Changes from v3:
> Replaced susbsys_initcall()/module_exit() by module_platform_driver().
> Accordingly in the hsotg driver returned -EPROBE_DEFER until phy driver
> is registered
> Removed unnecessary devm_usb_put_phy() call from the hsotg driver remove.
>
> Changes from v2:
> Changed the driver filenames to samsung-usbphy
> Rectified coding style related errors
>
> Changes from v1:
> Rebased patches to latest usb-next branch
> Changed the name 'sec_usbphy' to 'samsung_usbphy'
>
> This patch set introduces a phy driver for samsung SoCs. It uses the existing
> transceiver infrastructure to provide phy control functions. Use of this driver
> can be extended for usb host phy as well. Over the period of time all the phy
> related code for most of the samsung SoCs can be integrated here.
> Removing the existing phy code from mach-s3c64xx. Same can be done for other SoCs
> when they start supporting this phy driver.
> This driver is tested with smdk6410 and Exynos4210(with DT).
>
> Praveen Paneri (2):
> usb: phy: samsung: Introducing usb phy driver for hsotg
> usb: s3c-hsotg: Adding phy driver support
Can you check on my xceiv branch if this is applied correctly ?
thanks
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130118/2bfd8ea3/attachment.sig>
^ permalink raw reply
* [PATCH v8 2/3] Cortex-M3: Add base support for Cortex-M3
From: Jonathan Austin @ 2013-01-18 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358413196-5609-3-git-send-email-u.kleine-koenig@pengutronix.de>
Hi Uwe,
I've got a few questions about this patch, as well as some places where
there are changes that I think would increase the quality.
The most obvious thing that applies throughout is that there are quite a
bunch of special constants that could really do with #defines... I've
pulled out a few obvious onese inline below.
On 17/01/13 08:59, Uwe Kleine-K?nig wrote:
> From: Catalin Marinas <catalin.marinas@arm.com>
>
> This patch adds the base support for the Cortex-M3 processor (ARMv7-M
> architecture). It consists of the corresponding arch/arm/mm/ files and
> various #ifdef's around the kernel. Exception handling is implemented by
> a subsequent patch.
>
> [ukleinek: squash in some changes originating from commit
>
> b5717ba (Cortex-M3: Add support for the Microcontroller Prototyping System)
>
> from the v2.6.33-arm1 patch stack, port to post 3.6, drop zImage
> support, drop reorganisation of pt_regs, assert CONFIG_V7M doesn't leak
> into installed headers and a few cosmetic changes]
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
[...]
> -#ifdef CONFIG_THUMB2_KERNEL
> +#if defined(CONFIG_CPU_V7M)
> + .macro setmode, mode, reg
> + .endm
> +#elif defined(CONFIG_THUMB2_KERNEL)
Is it really okay to leave setmode doing nothing? My understanding of
the reason we need it normally is that we can't rely on the bootloader
entering the kernel in the right mode.
As far as M goes, it *looks* to me that it would be possible to enter
the kernel in 'handler' mode, as well as privileged thread mode (which I
presume is the 'right' mode). Is that possible? Likely? Should we
mitigate against?
> .macro setmode, mode, reg
> mov \reg, #\mode
> msr cpsr_c, \reg
> diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
> index cb47d28..5bd8cb6 100644
> --- a/arch/arm/include/asm/cputype.h
> +++ b/arch/arm/include/asm/cputype.h
> @@ -46,6 +46,9 @@ extern unsigned int processor_id;
> : "cc"); \
> __val; \
> })
> +#elif defined(CONFIG_CPU_V7M)
> +#define read_cpuid(reg) (*(unsigned int *)0xe000ed00)
Here's the first example of magic constants that aren't ideal, but I've
said more about magic constants below (I'd much prefer #defines)
> +#define read_cpuid_ext(reg) 0
> #else
> #define read_cpuid(reg) (processor_id)
> #define read_cpuid_ext(reg) 0
> diff --git a/arch/arm/include/asm/glue-cache.h b/arch/arm/include/asm/glue-cache.h
> index cca9f15..ea98658 100644
> --- a/arch/arm/include/asm/glue-cache.h
> +++ b/arch/arm/include/asm/glue-cache.h
> @@ -125,10 +125,35 @@
> # endif
> #endif
>
> +#if defined(CONFIG_CPU_V7M)
> +# ifdef _CACHE
> +# error "Multi-cache not supported on ARMv7-M"
> +# else
> +# define _CACHE nop
> +# endif
> +#endif
> +
What's the difficulty with MULTI_CACHE that's not encountered with
MULTI_CPU? Or the reason that you've got MULTI_CPU supported but not
MULTI_CACHE
I had a look at the mechanisms and couldn't see what would stop your
nop_cache_fns from being listed in the __v7m_proc_info?
It seems sensible to do this right from the start, especially given the
scarcity of eyes for review of NOMMU code...
> #if !defined(_CACHE) && !defined(MULTI_CACHE)
> #error Unknown cache maintenance model
> #endif
>
> +#ifndef __ASSEMBLER__
> +static inline void nop_flush_icache_all(void) { }
> +static inline void nop_flush_kern_cache_all(void) { }
> +static inline void nop_flush_kern_cache_louis(void) { }
> +static inline void nop_flush_user_cache_all(void) { }
> +static inline void nop_flush_user_cache_range(unsigned long a, unsigned long b, unsigned int c) { }
> +
> +static inline void nop_coherent_kern_range(unsigned long a, unsigned long b) { }
> +static inline int nop_coherent_user_range(unsigned long a, unsigned long b) { return 0; }
> +static inline void nop_flush_kern_dcache_area(void *a, size_t s) { }
> +
> +static inline void nop_dma_flush_range(const void *a, const void *b) { }
> +
> +static inline void nop_dma_map_area(const void *s, size_t l, int f) { }
> +static inline void nop_dma_unmap_area(const void *s, size_t l, int f) { }
> +#endif
> +
> #ifndef MULTI_CACHE
> #define __cpuc_flush_icache_all __glue(_CACHE,_flush_icache_all)
> #define __cpuc_flush_kern_all __glue(_CACHE,_flush_kern_cache_all)
> diff --git a/arch/arm/include/asm/glue-df.h b/arch/arm/include/asm/glue-df.h
> index 8cacbcd..1f2339c 100644
> --- a/arch/arm/include/asm/glue-df.h
> +++ b/arch/arm/include/asm/glue-df.h
> @@ -95,6 +95,14 @@
> # endif
> #endif
>
> +#ifdef CONFIG_CPU_ABRT_NOMMU
> +# ifdef CPU_DABORT_HANDLER
> +# define MULTI_DABORT 1
> +# else
> +# define CPU_DABORT_HANDLER nommu_early_abort
> +# endif
> +#endif
> +
You haven't added this to the list of models further up in the file -
looks like until now that list has been maintained so surely we should
keep it up-to-date?
> #ifndef CPU_DABORT_HANDLER
> #error Unknown data abort handler type
> #endif
> diff --git a/arch/arm/include/asm/glue-proc.h b/arch/arm/include/asm/glue-proc.h
> index ac1dd54..f2f39bc 100644
> --- a/arch/arm/include/asm/glue-proc.h
> +++ b/arch/arm/include/asm/glue-proc.h
> @@ -230,6 +230,15 @@
> # endif
> #endif
>
> +#ifdef CONFIG_CPU_V7M
> +# ifdef CPU_NAME
> +# undef MULTI_CPU
> +# define MULTI_CPU
> +# else
> +# define CPU_NAME cpu_v7m
> +# endif
> +#endif
> +
See my question above about MULTI_CPU and not MULTI_CACHE - strikes me
as strange...
> #ifndef MULTI_CPU
> #define cpu_proc_init __glue(CPU_NAME,_proc_init)
> #define cpu_proc_fin __glue(CPU_NAME,_proc_fin)
> diff --git a/arch/arm/include/asm/irqflags.h b/arch/arm/include/asm/irqflags.h
> index 1e6cca5..3b763d6 100644
> --- a/arch/arm/include/asm/irqflags.h
> +++ b/arch/arm/include/asm/irqflags.h
> @@ -8,6 +8,16 @@
> /*
> * CPU interrupt mask handling.
> */
> +#ifdef CONFIG_CPU_V7M
> +#define IRQMASK_REG_NAME_R "primask"
> +#define IRQMASK_REG_NAME_W "primask"
> +#define IRQMASK_I_BIT 1
> +#else
> +#define IRQMASK_REG_NAME_R "cpsr"
> +#define IRQMASK_REG_NAME_W "cpsr_c"
> +#define IRQMASK_I_BIT PSR_I_BIT
> +#endif
> +
> #if __LINUX_ARM_ARCH__ >= 6
>
> static inline unsigned long arch_local_irq_save(void)
> @@ -15,7 +25,7 @@ static inline unsigned long arch_local_irq_save(void)
> unsigned long flags;
>
> asm volatile(
> - " mrs %0, cpsr @ arch_local_irq_save\n"
> + " mrs %0, " IRQMASK_REG_NAME_R " @ arch_local_irq_save\n"
> " cpsid i"
> : "=r" (flags) : : "memory", "cc");
> return flags;
> @@ -129,7 +139,7 @@ static inline unsigned long arch_local_save_flags(void)
> {
> unsigned long flags;
> asm volatile(
> - " mrs %0, cpsr @ local_save_flags"
> + " mrs %0, " IRQMASK_REG_NAME_R " @ local_save_flags"
> : "=r" (flags) : : "memory", "cc");
> return flags;
> }
> @@ -140,7 +150,7 @@ static inline unsigned long arch_local_save_flags(void)
> static inline void arch_local_irq_restore(unsigned long flags)
> {
> asm volatile(
> - " msr cpsr_c, %0 @ local_irq_restore"
> + " msr " IRQMASK_REG_NAME_W ", %0 @ local_irq_restore"
> :
> : "r" (flags)
> : "memory", "cc");
> @@ -148,8 +158,8 @@ static inline void arch_local_irq_restore(unsigned long flags)
>
> static inline int arch_irqs_disabled_flags(unsigned long flags)
> {
> - return flags & PSR_I_BIT;
> + return flags & IRQMASK_I_BIT;
> }
>
> -#endif
> -#endif
> +#endif /* ifdef __KERNEL__ */
> +#endif /* ifndef __ASM_ARM_IRQFLAGS_H */
> diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
> index 06e7d50..5e61b88 100644
> --- a/arch/arm/include/asm/processor.h
> +++ b/arch/arm/include/asm/processor.h
> @@ -49,7 +49,14 @@ struct thread_struct {
> #ifdef CONFIG_MMU
> #define nommu_start_thread(regs) do { } while (0)
> #else
> +#ifndef CONFIG_CPU_V7M
> #define nommu_start_thread(regs) regs->ARM_r10 = current->mm->start_data
> +#else
> +#define nommu_start_thread(regs) do { \
> + regs->ARM_r10 = current->mm->start_data; \
This one isn't really a comment on your patch, because you're
duplicating the normal nommu behaviour, but why don't we do anything
special with r9? Isn't that the PIC offset base regiser exclusively in
uClinux?
Does someone know - is this legacy from before the uClinux stuff was
EABI compliant and used r10, or is this doing something else?
> + regs->ARM_EXC_RET = 0xfffffffdL; \
So, here's another magic constant...
This corresponds to 'Return to thread mode with process stack'
I think it'd be much clearer to #define these somewhere where the FP
versions can be added later..
how about
#define ER_THREAD_PROCESS_BASIC 0xFFFFFFFdL
Which I think gives us scope for adding all the FP options (Table 8.8,
8.9 in V7M ARMARM)
That said, as discussed in the next comment, and on IRC, we should
probably get rid of this particular instance (regs->ARM_EXC_RET) and
derive this value based on other saved information.
> +} while (0)
> +#endif
> #endif
>
> #define start_thread(regs,pc,sp) \
> diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h
> index 3d52ee1..67661e8 100644
> --- a/arch/arm/include/asm/ptrace.h
> +++ b/arch/arm/include/asm/ptrace.h
> @@ -14,7 +14,11 @@
>
> #ifndef __ASSEMBLY__
> struct pt_regs {
> +#ifdef CONFIG_CPU_V7M
> + unsigned long uregs[20];
This increase in pt_regs size is due to the addition of ARM_EXC_RET to
pt_regs (for the kernel only, not userspace)
However, I think we can avoid doing this, which is nicer because we don't
a) Have a register in pt_regs that isn't actually a register
b) Have less #ifdef'd code, and so the chance of NOMMU getting
inadvertently broken is lower.
ARM_EXC_RET can be one of the following (assuming we always use the
basic stack frame)
EXC_RETURN Return to Return stack
0xFFFFFFF1 Handler mode Main
0xFFFFFFF9 Thread mode Main
0xFFFFFFFD Thread mode Process
But we never return to thread mode with the main stack (right?) - so
really to calculate what ARM_EXC_RET should be we just need to know
whether the thread is handler mode or thread mode. We can know this from
the IPSR, and as the xPSR gets saved by both the core at exception time,
and then by us in to the pt_regs struct, we shouldn't need to *also*
store EXC_RET out of the lr. This would, of course, also need
appropriate changes to v7m_exception_entry and v7m_exception_{fast,
slow}_exit and __irq_entry where we also load EXC_RET into lr.
This way, only when some change or new feature for the kernel actually
needs to be storing ARM_EXC_RET do we need to think about storing it
somewhere, be that in the thread_info or pt_regs.
> +#else
> unsigned long uregs[18];
> +#endif
> };
>
> #define user_mode(regs) \
> @@ -45,6 +49,7 @@ struct pt_regs {
> */
> static inline int valid_user_regs(struct pt_regs *regs)
> {
> +#ifndef CONFIG_CPU_V7M
> unsigned long mode = regs->ARM_cpsr & MODE_MASK;
>
> /*
> @@ -67,6 +72,9 @@ static inline int valid_user_regs(struct pt_regs *regs)
> regs->ARM_cpsr |= USR_MODE;
>
> return 0;
> +#else /* ifndef CONFIG_CPU_V7M */
> + return 1;
> +#endif
> }
>
> static inline long regs_return_value(struct pt_regs *regs)
> diff --git a/arch/arm/include/asm/system_info.h b/arch/arm/include/asm/system_info.h
> index dfd386d..720ea03 100644
> --- a/arch/arm/include/asm/system_info.h
> +++ b/arch/arm/include/asm/system_info.h
> @@ -11,6 +11,7 @@
> #define CPU_ARCH_ARMv5TEJ 7
> #define CPU_ARCH_ARMv6 8
> #define CPU_ARCH_ARMv7 9
> +#define CPU_ARCH_ARMv7M 10
>
> #ifndef __ASSEMBLY__
>
> diff --git a/arch/arm/include/uapi/asm/ptrace.h b/arch/arm/include/uapi/asm/ptrace.h
> index 96ee092..d3be66e 100644
> --- a/arch/arm/include/uapi/asm/ptrace.h
> +++ b/arch/arm/include/uapi/asm/ptrace.h
> @@ -34,28 +34,47 @@
>
> /*
> * PSR bits
> + * Note on V7M there is no mode contained in the PSR
> */
> #define USR26_MODE 0x00000000
> #define FIQ26_MODE 0x00000001
> #define IRQ26_MODE 0x00000002
> #define SVC26_MODE 0x00000003
> +#if defined(__KERNEL__) && defined(CONFIG_CPU_V7M)
> +/*
> + * Use 0 here to get code right that creates a userspace
> + * or kernel space thread.
> + */
> +#define USR_MODE 0x00000000
> +#define SVC_MODE 0x00000000
> +#else
> #define USR_MODE 0x00000010
> +#define SVC_MODE 0x00000013
> +#endif
> #define FIQ_MODE 0x00000011
> #define IRQ_MODE 0x00000012
> -#define SVC_MODE 0x00000013
> #define ABT_MODE 0x00000017
> #define HYP_MODE 0x0000001a
> #define UND_MODE 0x0000001b
> #define SYSTEM_MODE 0x0000001f
> #define MODE32_BIT 0x00000010
> #define MODE_MASK 0x0000001f
> -#define PSR_T_BIT 0x00000020
> -#define PSR_F_BIT 0x00000040
> -#define PSR_I_BIT 0x00000080
> -#define PSR_A_BIT 0x00000100
> -#define PSR_E_BIT 0x00000200
> -#define PSR_J_BIT 0x01000000
> -#define PSR_Q_BIT 0x08000000
> +
> +#define V4_PSR_T_BIT 0x00000020 /* >= V4T, but not V7M */
> +#define V7M_PSR_T_BIT 0x01000000
> +#if defined(__KERNEL__) && defined(CONFIG_CPU_V7M)
> +#define PSR_T_BIT V7M_PSR_T_BIT
> +#else
> +/* for compatibility */
> +#define PSR_T_BIT V4_PSR_T_BIT
> +#endif
> +
> +#define PSR_F_BIT 0x00000040 /* >= V4, but not V7M */
> +#define PSR_I_BIT 0x00000080 /* >= V4, but not V7M */
> +#define PSR_A_BIT 0x00000100 /* >= V6, but not V7M */
> +#define PSR_E_BIT 0x00000200 /* >= V6, but not V7M */
> +#define PSR_J_BIT 0x01000000 /* >= V5J, but not V7M */
> +#define PSR_Q_BIT 0x08000000 /* >= V5E, including V7M */
> #define PSR_V_BIT 0x10000000
> #define PSR_C_BIT 0x20000000
> #define PSR_Z_BIT 0x40000000
> @@ -125,6 +144,7 @@ struct pt_regs {
> #define ARM_r1 uregs[1]
> #define ARM_r0 uregs[0]
> #define ARM_ORIG_r0 uregs[17]
> +#define ARM_EXC_RET uregs[18]
>
If we can get rid of the pt_regs change, then this can also go away -
that'd be nice because I'm not sure about it... I don't know what the
implications of having this defined for userspace are, given that you've got
#ifndef __KERNEL__
struct pt_regs {
long uregs[18];
};
#endif /* __KERNEL__ */
Should that last definition for ARM_EXC_RET be #ifdef __KERNEL__ too?
> /*
> * The size of the user-visible VFP state as seen by PTRACE_GET/SETVFPREGS
> diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
> index c985b48..5fe9ace 100644
> --- a/arch/arm/kernel/asm-offsets.c
> +++ b/arch/arm/kernel/asm-offsets.c
> @@ -93,6 +93,9 @@ int main(void)
> DEFINE(S_PC, offsetof(struct pt_regs, ARM_pc));
> DEFINE(S_PSR, offsetof(struct pt_regs, ARM_cpsr));
> DEFINE(S_OLD_R0, offsetof(struct pt_regs, ARM_ORIG_r0));
> +#ifdef CONFIG_CPU_V7M
> + DEFINE(S_EXC_RET, offsetof(struct pt_regs, ARM_EXC_RET));
> +#endif
> DEFINE(S_FRAME_SIZE, sizeof(struct pt_regs));
> BLANK();
> #ifdef CONFIG_CACHE_L2X0
> diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
> index 278cfc1..c391c05 100644
> --- a/arch/arm/kernel/head-nommu.S
> +++ b/arch/arm/kernel/head-nommu.S
> @@ -44,10 +44,13 @@ ENTRY(stext)
>
> setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode
> @ and irqs disabled
> -#ifndef CONFIG_CPU_CP15
> - ldr r9, =CONFIG_PROCESSOR_ID
> -#else
> +#if defined(CONFIG_CPU_CP15)
> mrc p15, 0, r9, c0, c0 @ get processor id
> +#elif defined(CONFIG_CPU_V7M)
> + ldr r9, =0xe000ed00 @ CPUID register address
Another case where the magic constant makes things less clear...
As these things are architecturally defined (ARMARMv7-M) then can we
please #define them with their register names?
ldr r9, =V7M_CPUID
reads much more cleanly.
> + ldr r9, [r9]
> +#else
> + ldr r9, =CONFIG_PROCESSOR_ID
> #endif
> bl __lookup_processor_type @ r5=procinfo r9=cpuid
> movs r10, r5 @ invalid processor (r5=0)?
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index da1d1aa..3cca0c8 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -128,7 +128,9 @@ struct stack {
> u32 und[3];
> } ____cacheline_aligned;
>
> +#ifndef CONFIG_CPU_V7M
> static struct stack stacks[NR_CPUS];
> +#endif
>
> char elf_platform[ELF_PLATFORM_SIZE];
> EXPORT_SYMBOL(elf_platform);
> @@ -207,7 +209,7 @@ static const char *proc_arch[] = {
> "5TEJ",
> "6TEJ",
> "7",
> - "?(11)",
> + "7M",
> "?(12)",
> "?(13)",
> "?(14)",
> @@ -216,6 +218,12 @@ static const char *proc_arch[] = {
> "?(17)",
> };
>
> +#ifdef CONFIG_CPU_V7M
> +static int __get_cpu_architecture(void)
> +{
> + return CPU_ARCH_ARMv7M;
> +}
> +#else
> static int __get_cpu_architecture(void)
> {
> int cpu_arch;
You've wired up read_cpu_id() and a stub read_cpuid_ext() for V7M so it
would be better to get rid of this #ifdef.
I'm guessing the problem that caused you to do this was the inline asm
in __get_cpu_architecture that uses cp15 access.
If you used read_cpu_ext(CPUID_EXT_MMFR0) instead of that asm then you'd
a) clean up the code
b) avoid a possible bug as that asm is not predicated on CONFIG_CPU_CP15
I reckon that could be a separate patch, perhaps?
Then you don't need the #ifdef anymore, right?
> @@ -248,6 +256,7 @@ static int __get_cpu_architecture(void)
>
> return cpu_arch;
> }
> +#endif
>
> int __pure cpu_architecture(void)
> {
> @@ -375,6 +384,7 @@ static void __init feat_v6_fixup(void)
> */
> void cpu_init(void)
> {
> +#ifndef CONFIG_CPU_V7M
What is it in here that we're avoiding? Couldn't the #ifdefs go around
the __asm__ in this function instead of the whole thing? Or at most the
initialisation of stk and the __asm__ block?
cpu_proc_init() is wired (albeit as a stub) for v7m, and I don't see
why smp_processor_id() should hurt (it seems like it is defined away in
the !SMP case in include/linux/smp.h). It could also get quite confusing
to debug now that we've got a function we can't execute.
Yes, we execute a few more instructions, but reducing the 'delta'
between M and A/R seems to be a worthwhile pay-off to me...
If there's something hiding in there that I've missed then apologies...
> unsigned int cpu = smp_processor_id();
> struct stack *stk = &stacks[cpu];
>
> @@ -419,6 +429,7 @@ void cpu_init(void)
> "I" (offsetof(struct stack, und[0])),
> PLC (PSR_F_BIT | PSR_I_BIT | SVC_MODE)
> : "r14");
> +#endif
> }
>
> int __cpu_logical_map[NR_CPUS];
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index b0179b8..12d976b 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -819,6 +819,7 @@ static void __init kuser_get_tls_init(unsigned long vectors)
>
> void __init early_trap_init(void *vectors_base)
> {
> +#ifndef CONFIG_CPU_V7M
> unsigned long vectors = (unsigned long)vectors_base;
> extern char __stubs_start[], __stubs_end[];
> extern char __vectors_start[], __vectors_end[];
> @@ -850,4 +851,5 @@ void __init early_trap_init(void *vectors_base)
>
> flush_icache_range(vectors, vectors + PAGE_SIZE);
> modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
> +#endif
This looks scary enough ("What, we don't install any vectors!?") that it
could probably do with a comment along the lines of 'V7M allows us to
point to a vector table inside the kernel image'
Also helps explain why the kuser helpers aren't going to be around.
> }
> diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
> index d51225f..4bc8ae5 100644
> --- a/arch/arm/mm/nommu.c
> +++ b/arch/arm/mm/nommu.c
> @@ -20,12 +20,14 @@
>
> void __init arm_mm_memblock_reserve(void)
> {
> +#ifndef CONFIG_CPU_V7M
> /*
> * Register the exception vector page.
> * some architectures which the DRAM is the exception vector to trap,
> * alloc_page breaks with error, although it is not NULL, but "0."
> */
> memblock_reserve(CONFIG_VECTORS_BASE, PAGE_SIZE);
> +#endif
> }
>
> void __init sanity_check_meminfo(void)
> diff --git a/arch/arm/mm/proc-v7m.S b/arch/arm/mm/proc-v7m.S
> new file mode 100644
> index 0000000..2b8eb97
> --- /dev/null
> +++ b/arch/arm/mm/proc-v7m.S
> @@ -0,0 +1,161 @@
> +/*
> + * linux/arch/arm/mm/proc-v7m.S
> + *
> + * Copyright (C) 2008 ARM Ltd.
> + * Copyright (C) 2001 Deep Blue Solutions Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This is the "shell" of the ARMv7-M processor support.
> + */
> +#include <linux/linkage.h>
> +#include <asm/assembler.h>
> +
> +ENTRY(cpu_v7m_proc_init)
> + mov pc, lr
> +ENDPROC(cpu_v7m_proc_init)
> +
> +ENTRY(cpu_v7m_proc_fin)
> + mov pc, lr
> +ENDPROC(cpu_v7m_proc_fin)
> +
> +/*
> + * cpu_v7m_reset(loc)
> + *
> + * Perform a soft reset of the system. Put the CPU into the
> + * same state as it would be if it had been reset, and branch
> + * to what would be the reset vector.
> + *
> + * - loc - location to jump to for soft reset
> + */
> + .align 5
> +ENTRY(cpu_v7m_reset)
> + mov pc, r0
> +ENDPROC(cpu_v7m_reset)
> +
> +/*
> + * cpu_v7m_do_idle()
> + *
> + * Idle the processor (eg, wait for interrupt).
> + *
> + * IRQs are already disabled.
> + */
> +ENTRY(cpu_v7m_do_idle)
> + wfi
> + mov pc, lr
> +ENDPROC(cpu_v7m_do_idle)
> +
> +ENTRY(cpu_v7m_dcache_clean_area)
> + mov pc, lr
> +ENDPROC(cpu_v7m_dcache_clean_area)
> +
> +/*
> + * There is no MMU, so here is nothing to do.
> + */
> +ENTRY(cpu_v7m_switch_mm)
> + mov pc, lr
> +ENDPROC(cpu_v7m_switch_mm)
> +
> +cpu_v7m_name:
> + .ascii "ARMv7-M Processor"
> + .align
> +
> + .section ".text.init", #alloc, #execinstr
> +
> +/*
> + * __v7m_setup
> + *
> + * This should be able to cover all ARMv7-M cores.
> + */
> +__v7m_setup:
> + @ Configure the vector table base address
> + ldr r0, =0xe000ed08 @ vector table base address
Here's the next case of using a 'magic constant register'
In this case, using the register name (say V7M_VTOR) also gives us the
joy of being able to trivially search in the ARMARM to understand what's
going on.
I'll stop pointing out the magic registers now, but there are a bunch
more - I think a search of e000 should pick a lot of them up. (though
the SVC and PendSV priorities below don't conform to that).
> + ldr r12, =vector_table
> + str r12, [r0]
> +
> + @ Lower the priority of the SVC and PendSV exceptions
> + ldr r0, =0xe000ed1c
> + mov r5, #0x80000000
> + str r5, [r0] @ set SVC priority
> + ldr r0, =0xe000ed20
> + mov r5, #0x00800000
> + str r5, [r0] @ set PendSV priority
> +
> + @ SVC to run the kernel in this mode
> + adr r0, BSYM(1f)
> + ldr r5, [r12, #11 * 4] @ read the SVC vector entry
> + str r0, [r12, #11 * 4] @ write the temporary SVC vector entry
> + mov r6, lr @ save LR
> + mov r7, sp @ save SP
> + ldr sp, =__v7m_setup_stack_top
> + cpsie i
> + svc #0
> +1: cpsid i
> + str r5, [r12, #11 * 4] @ restore the original SVC vector entry
> + mov lr, r6 @ restore LR
> + mov sp, r7 @ restore SP
> +
> + @ Special-purpose control register
> + mov r0, #1
> + msr control, r0 @ Thread mode has unpriviledged access
> +
> + @ Configure the System Control Register
> + ldr r0, =0xe000ed14 @ system control register
> + ldr r12, [r0]
> + orr r12, #1 << 9 @ STKALIGN
> + str r12, [r0]
> + mov pc, lr
> +ENDPROC(__v7m_setup)
> +
> + .align 2
> + .type v7m_processor_functions, #object
> +ENTRY(v7m_processor_functions)
> + .word nommu_early_abort
> + .word cpu_v7m_proc_init
> + .word cpu_v7m_proc_fin
> + .word cpu_v7m_reset
> + .word cpu_v7m_do_idle
> + .word cpu_v7m_dcache_clean_area
> + .word cpu_v7m_switch_mm
> + .word 0 @ cpu_v7m_set_pte_ext
> + .word legacy_pabort
> + .size v7m_processor_functions, . - v7m_processor_functions
> +
> + .type cpu_arch_name, #object
> +cpu_arch_name:
> + .asciz "armv7m"
> + .size cpu_arch_name, . - cpu_arch_name
> +
> + .type cpu_elf_name, #object
> +cpu_elf_name:
> + .asciz "v7m"
> + .size cpu_elf_name, . - cpu_elf_name
> + .align
> +
> + .section ".proc.info.init", #alloc, #execinstr
> +
> + /*
> + * Match any ARMv7-M processor core.
> + */
> + .type __v7m_proc_info, #object
> +__v7m_proc_info:
> + .long 0x000f0000 @ Required ID value
> + .long 0x000f0000 @ Mask for ID
> + .long 0 @ proc_info_list.__cpu_mm_mmu_flags
> + .long 0 @ proc_info_list.__cpu_io_mmu_flags
> + b __v7m_setup @ proc_info_list.__cpu_flush
> + .long cpu_arch_name
> + .long cpu_elf_name
> + .long HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP
> + .long cpu_v7m_name
> + .long v7m_processor_functions @ proc_info_list.proc
> + .long 0 @ proc_info_list.tlb
> + .long 0 @ proc_info_list.user
> + .long 0 @ proc_info_list.cache
Surely here's where we could specify the nop_cache_fns for MULTI_CACHE?
> + .size __v7m_proc_info, . - __v7m_proc_info
> +
> +__v7m_setup_stack:
> + .space 4 * 8 @ 8 registers
> +__v7m_setup_stack_top:
> --
Hope that's helpful!
Jonny
^ permalink raw reply
* [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
From: Tony Lindgren @ 2013-01-18 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130118175408.GC1035@arwen.pp.htv.fi>
* Felipe Balbi <balbi@ti.com> [130118 09:57]:
> Hi,
>
> On Fri, Jan 18, 2013 at 09:36:35AM -0800, Tony Lindgren wrote:
> > * Luciano Coelho <coelho@ti.com> [130118 01:03]:
> > > On Thu, 2013-01-17 at 15:16 -0800, Tony Lindgren wrote:
> > > > * Luciano Coelho <coelho@ti.com> [130117 10:04]:
> > > > > But this patch is pretty small and simple, so why not include it to at
> > > > > least fix the breakage in 3.7 and 3.8? Whether you take it or not now
> > > > > won't make any difference in the 5k LOC in these kernel versions.
> > > >
> > > > Well we are planning to drop the non-DT support for omap4 as soon as it's
> > > > usable with DT. For omap4 we are only carrying SDP and panda support to
> > > > make this transition easier. The only bindings missing AFAIK are wl12xx and
> > > > USB.
> > >
> > > In my view this is a regression and it should be fixed with as simple a
> > > patch as possible. The alternative to my solution is to revert the
> > > patch that removed the enable/disable from the ti-st driver *and* fix
> > > u-boot, because if it doesn't mux the UART2 pins properly (and it
> > > doesn't) the shared transport still won't work.
> >
> > Fixing the muxing here makes sense naturally as we cannot do that in the driver
> > until we've flipped things over to use DT.
> >
> > But I don't think we should fix the driver regression by adding more platform
> > callbacks as we are getting rid of them anyways.
>
> it's not adding more callbacks, solely implementing them as it should
> have been done on Pavan's original patch.
It certainly is adding new callback functions to board-*.c files looking
at the diffstat :)
IMHO the right fix is to revert eccf2979 that caused the regression and then
adding the muxing to the board-*.c file(s).
It's OK for the driver to call the standard GPIO functions, and those will
be needed in the driver for the DT case anyways.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 2/2] ARM: uncompress debug support for multiplatform build
From: Olof Johansson @ 2013-01-18 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358477120-19673-1-git-send-email-shawn.guo@linaro.org>
On Thu, Jan 17, 2013 at 6:45 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> Instead of giving zero support of uncompress debug for multiplatform
> build, the patch turns uncompress debug into one part of DEBUG_LL
> support. When DEBUG_LL is turned on for a particular platform,
> uncompress debug works too for that platform.
>
> It reuses the platform DEBUG_LL macros by creating a simple
> arch/arm/boot/compressed/debug.S with CONFIG_DEBUG_LL_INCLUDE
> included there, and implements a generic putc() using those macros.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
This looks great, and it's even cleaner than I was hoping it'd be
based on my suggestion. Nice! :)
Russell, do you want to apply this or should we? If the former, for
the patch tracker:
Acked-by: Olof Johansson <olof@lixom.net>
If the latter, let me know and I'll pick it up.
Thanks!
-Olof
^ permalink raw reply
* [PATCH 7/7] clk: vexpress: Use common of_clk_init() function
From: Mike Turquette @ 2013-01-18 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357282858-2112-7-git-send-email-pgaikwad@nvidia.com>
Quoting Prashant Gaikwad (2013-01-03 23:00:58)
> Use common of_clk_init() function for clock initialization.
>
> Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
Pawel or Linus,
Can I get a Tested-by before I take this series into clk-next?
Thanks,
Mike
> ---
> drivers/clk/versatile/clk-vexpress-osc.c | 1 +
> drivers/clk/versatile/clk-vexpress.c | 8 +-------
> 2 files changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/clk/versatile/clk-vexpress-osc.c b/drivers/clk/versatile/clk-vexpress-osc.c
> index dcb6ae0..256c8be 100644
> --- a/drivers/clk/versatile/clk-vexpress-osc.c
> +++ b/drivers/clk/versatile/clk-vexpress-osc.c
> @@ -144,3 +144,4 @@ error:
> vexpress_config_func_put(osc->func);
> kfree(osc);
> }
> +CLK_OF_DECLARE(vexpress_soc, "arm,vexpress-osc", vexpress_osc_of_setup);
> diff --git a/drivers/clk/versatile/clk-vexpress.c b/drivers/clk/versatile/clk-vexpress.c
> index c742ac7..f889f2f 100644
> --- a/drivers/clk/versatile/clk-vexpress.c
> +++ b/drivers/clk/versatile/clk-vexpress.c
> @@ -99,19 +99,13 @@ struct clk *vexpress_sp810_of_get(struct of_phandle_args *clkspec, void *data)
> return vexpress_sp810_timerclken[clkspec->args[0]];
> }
>
> -static const __initconst struct of_device_id vexpress_fixed_clk_match[] = {
> - { .compatible = "fixed-clock", .data = of_fixed_clk_setup, },
> - { .compatible = "arm,vexpress-osc", .data = vexpress_osc_of_setup, },
> - {}
> -};
> -
> void __init vexpress_clk_of_init(void)
> {
> struct device_node *node;
> struct clk *clk;
> struct clk *refclk, *timclk;
>
> - of_clk_init(vexpress_fixed_clk_match);
> + of_clk_init(NULL);
>
> node = of_find_compatible_node(NULL, NULL, "arm,sp810");
> vexpress_sp810_init(of_iomap(node, 0));
> --
> 1.7.4.1
^ permalink raw reply
* [PATCH 5/7] clk: vt8500: Use common of_clk_init() function
From: Mike Turquette @ 2013-01-18 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357282858-2112-5-git-send-email-pgaikwad@nvidia.com>
Quoting Prashant Gaikwad (2013-01-03 23:00:56)
> Use common of_clk_init() function for clock initialization.
>
> Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
Tony,
Can I get a Tested-by from you before I take this in?
Thanks,
Mike
> ---
> drivers/clk/clk-vt8500.c | 15 ++++-----------
> 1 files changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/clk/clk-vt8500.c b/drivers/clk/clk-vt8500.c
> index fe25570..3ce1c3e 100644
> --- a/drivers/clk/clk-vt8500.c
> +++ b/drivers/clk/clk-vt8500.c
> @@ -272,7 +272,7 @@ static __init void vtwm_device_clk_init(struct device_node *node)
> rc = of_clk_add_provider(node, of_clk_src_simple_get, clk);
> clk_register_clkdev(clk, clk_name, NULL);
> }
> -
> +CLK_OF_DECLARE(vt8500_device, "via,vt8500-device-clock", vtwm_device_clk_init);
>
> /* PLL clock related functions */
>
> @@ -502,20 +502,13 @@ static void __init vt8500_pll_init(struct device_node *node)
> {
> vtwm_pll_clk_init(node, PLL_TYPE_VT8500);
> }
> +CLK_OF_DECLARE(vt8500_pll, "via,vt8500-pll-clock", vt8500_pll_init);
>
> static void __init wm8650_pll_init(struct device_node *node)
> {
> vtwm_pll_clk_init(node, PLL_TYPE_WM8650);
> }
> -
> -static const __initconst struct of_device_id clk_match[] = {
> - { .compatible = "fixed-clock", .data = of_fixed_clk_setup, },
> - { .compatible = "via,vt8500-pll-clock", .data = vt8500_pll_init, },
> - { .compatible = "wm,wm8650-pll-clock", .data = wm8650_pll_init, },
> - { .compatible = "via,vt8500-device-clock",
> - .data = vtwm_device_clk_init, },
> - { /* sentinel */ }
> -};
> +CLK_OF_DECLARE(wm8650_pll, "wm,wm8650-pll-clock", wm8650_pll_init);
>
> void __init vtwm_clk_init(void __iomem *base)
> {
> @@ -524,5 +517,5 @@ void __init vtwm_clk_init(void __iomem *base)
>
> pmc_base = base;
>
> - of_clk_init(clk_match);
> + of_clk_init(NULL);
> }
> --
> 1.7.4.1
^ permalink raw reply
* [PATCH 4/7] clk: highbank: Use common of_clk_init() function
From: Mike Turquette @ 2013-01-18 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357282858-2112-4-git-send-email-pgaikwad@nvidia.com>
Quoting Prashant Gaikwad (2013-01-03 23:00:55)
> Use common of_clk_init() function for clocks initialization.
>
> Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
Rob,
Can I get a Tested-by from you before I take this?
Thanks,
Mike
> ---
> arch/arm/mach-highbank/core.h | 1 -
> arch/arm/mach-highbank/highbank.c | 3 ++-
> drivers/clk/clk-highbank.c | 18 ++++--------------
> 3 files changed, 6 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/mach-highbank/core.h b/arch/arm/mach-highbank/core.h
> index 80235b4..3f65206 100644
> --- a/arch/arm/mach-highbank/core.h
> +++ b/arch/arm/mach-highbank/core.h
> @@ -2,7 +2,6 @@
> #define __HIGHBANK_CORE_H
>
> extern void highbank_set_cpu_jump(int cpu, void *jump_addr);
> -extern void highbank_clocks_init(void);
> extern void highbank_restart(char, const char *);
> extern void __iomem *scu_base_addr;
>
> diff --git a/arch/arm/mach-highbank/highbank.c b/arch/arm/mach-highbank/highbank.c
> index f6ca285..fb148da 100644
> --- a/arch/arm/mach-highbank/highbank.c
> +++ b/arch/arm/mach-highbank/highbank.c
> @@ -25,6 +25,7 @@
> #include <linux/of_address.h>
> #include <linux/smp.h>
> #include <linux/amba/bus.h>
> +#include <linux/clk-provider.h>
>
> #include <asm/arch_timer.h>
> #include <asm/cacheflush.h>
> @@ -116,7 +117,7 @@ static void __init highbank_timer_init(void)
> WARN_ON(!timer_base);
> irq = irq_of_parse_and_map(np, 0);
>
> - highbank_clocks_init();
> + of_clk_init(NULL);
> lookup.clk = of_clk_get(np, 0);
> clkdev_add(&lookup);
>
> diff --git a/drivers/clk/clk-highbank.c b/drivers/clk/clk-highbank.c
> index 52fecad..5d1de2e 100644
> --- a/drivers/clk/clk-highbank.c
> +++ b/drivers/clk/clk-highbank.c
> @@ -314,33 +314,23 @@ static void __init hb_pll_init(struct device_node *node)
> {
> hb_clk_init(node, &clk_pll_ops);
> }
> +CLK_OF_DECLARE(hb_pll, "calxeda,hb-pll-clock", hb_pll_init);
>
> static void __init hb_a9periph_init(struct device_node *node)
> {
> hb_clk_init(node, &a9periphclk_ops);
> }
> +CLK_OF_DECLARE(hb_a9periph, "calxeda,hb-a9periph-clock", hb_a9periph_init);
>
> static void __init hb_a9bus_init(struct device_node *node)
> {
> struct clk *clk = hb_clk_init(node, &a9bclk_ops);
> clk_prepare_enable(clk);
> }
> +CLK_OF_DECLARE(hb_a9bus, "calxeda,hb-a9bus-clock", hb_a9bus_init);
>
> static void __init hb_emmc_init(struct device_node *node)
> {
> hb_clk_init(node, &periclk_ops);
> }
> -
> -static const __initconst struct of_device_id clk_match[] = {
> - { .compatible = "fixed-clock", .data = of_fixed_clk_setup, },
> - { .compatible = "calxeda,hb-pll-clock", .data = hb_pll_init, },
> - { .compatible = "calxeda,hb-a9periph-clock", .data = hb_a9periph_init, },
> - { .compatible = "calxeda,hb-a9bus-clock", .data = hb_a9bus_init, },
> - { .compatible = "calxeda,hb-emmc-clock", .data = hb_emmc_init, },
> - {}
> -};
> -
> -void __init highbank_clocks_init(void)
> -{
> - of_clk_init(clk_match);
> -}
> +CLK_OF_DECLARE(hb_emmc, "calxeda,hb-emmc-clock", hb_emmc_init);
> --
> 1.7.4.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox