* booting single uImage on platforms with different base addresses for SDRAM
From: Nicolas Pitre @ 2011-09-22 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110922111523.GM17169@n2100.arm.linux.org.uk>
On Thu, 22 Sep 2011, Russell King - ARM Linux wrote:
> On Thu, Sep 22, 2011 at 02:04:12PM +0300, Peter De Schrijver wrote:
> > Currently uImages have the load address hardcoded. As we now try to support
> > as many ARM platforms as possible with a single binary, this becomes a
> > problem. On tegra20 SDRAM starts at physical address 0, but on tegra30 SDRAM
> > starts at 0x80000000. It's possible to build a kernel image which can deal
> > with this, but the uImage still uses a hardcoded address. This results
> > in requiring 2 different uImages even though the zImage is the same.
>
> This is a problem with the uImage format. It can only be fixed in uboot
> - it's not a kernel problem.
>
> > Has anyone thought of a solution to this problem?
>
> There was talk about making '0' or something a special address, and
> fixing uboot to place it appropriately (in much the same way that the
> other boot loaders such as blob's offset from the start of RAM, or
> redboot's scripted loading which takes the load address.)
... or make u-Boot support plain zImage on ARM (like it apparently does
for MIPS). The u-Boot load command can accept a destination memory
address just fine, but u-Boot always insists on relocating it when it is
a uImage.
Nicolas
^ permalink raw reply
* [GIT PULL] ux500-fixes for v3.1
From: Linus Walleij @ 2011-09-22 12:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
As requested, here is a git branch with the ux500 fixes
elegible for v3.1. The only changes to the patches already
floated on the mailing list is the addition of the ARM:
prefix at nicos request, and rebased to v3.1-rc7.
As noted they have also been resubmitted with
Cc: stable at kernel.org.
The following changes since commit d93dc5c4478c1fd5de85a3e8aece9aad7bbae044:
Linux 3.1-rc7 (2011-09-21 16:58:15 -0700)
are available in the git repository at:
git://git.linaro.org/people/triad/linux-stericsson.git fixes-for-arnd
Linus Walleij (1):
ARM: mach-ux500: unlock I&D l2x0 caches before init
srinidhi kasagar (1):
ARM: mach-ux500: enable fix for ARM errata 754322
arch/arm/mach-ux500/Kconfig | 1 +
arch/arm/mach-ux500/cpu.c | 25 ++++++++++++++++++++++++-
2 files changed, 25 insertions(+), 1 deletions(-)
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 5/5] regulator: map consumer regulator based on device tree
From: Rajendra Nayak @ 2011-09-22 12:21 UTC (permalink / raw)
To: linux-arm-kernel
Device nodes in DT can associate themselves with one or more
regulators/supply by providing a list of phandles (to regulator nodes)
and corresponding supply names.
For Example:
devicenode: node at 0x0 {
...
...
vmmc-supply =3D <®ulator1>;
vpll-supply =3D <®ulator1>;
};
The driver would then do a regulator_get(dev, "vmmc"); to get
regulator1 and do a regulator_get(dev, "vpll"); to get
regulator2.
of_get_regulator() extracts the regulator node for a given
device, based on the supply name.
Use it to look up the regulator for a given consumer from device tree, duri=
ng
a regulator_get(). If not found fallback and lookup through
the regulator_map_list instead.
Also, since the regulator dt nodes can use the same binding to
associate with a parent regulator/supply, allow the drivers to
specify a supply_name, which can then be used to lookup dt
to find the parent phandle.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
drivers/regulator/core.c | 91 +++++++++++++++++++++++++++++++---=
---
include/linux/regulator/driver.h | 2 +
2 files changed, 78 insertions(+), 15 deletions(-)
Index: linux/drivers/regulator/core.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- linux.orig/drivers/regulator/core.c 2011-10-11 11:43:27.944140106 +0530
+++ linux/drivers/regulator/core.c 2011-10-11 12:25:53.540418748 +0530
@@ -25,9 +25,11 @@
#include <linux/mutex.h>
#include <linux/suspend.h>
#include <linux/delay.h>
+#include <linux/of.h>
#include <linux/regulator/consumer.h>
#include <linux/regulator/driver.h>
#include <linux/regulator/machine.h>
+#include <linux/regulator/of_regulator.h>
#define CREATE_TRACE_POINTS
#include <trace/events/regulator.h>
@@ -131,6 +133,33 @@
return NULL;
}
+/**
+ * of_get_regulator - get a regulator device node based on supply name
+ * @dev: Device pointer for the consumer (of regulator) device
+ * @supply: regulator supply name
+ *
+ * Extract the regulator device node corresponding to the supply name.
+ * retruns the device node corresponding to the regulator if found, else
+ * returns NULL.
+ */
+static struct device_node *of_get_regulator(struct device *dev, const
char *supply)
+{
+ struct device_node *regnode =3D NULL;
+ char prop_name[32]; /* 32 is max size of property name */
+
+ dev_dbg(dev, "Looking up %s-supply from device tree\n", supply);
+
+ snprintf(prop_name, 32, "%s-supply", supply);
+ regnode =3D of_parse_phandle(dev->of_node, prop_name, 0);
+
+ if (!regnode) {
+ pr_warn("%s: %s property in node %s references invalid phandle",
+ __func__, prop_name, dev->of_node->full_name);
+ return NULL;
+ }
+ return regnode;
+}
+
/* Platform voltage constraint check */
static int regulator_check_voltage(struct regulator_dev *rdev,
int *min_uV, int *max_uV)
@@ -1147,6 +1176,28 @@
return rdev->desc->ops->enable_time(rdev);
}
+static struct regulator_dev *regulator_dev_lookup(struct device *dev,
+ const char *supply)
+{
+ struct regulator_dev *r;
+ struct device_node *node;
+
+ /* first do a dt based lookup */
+ if (dev && dev->of_node)
+ node =3D of_get_regulator(dev, supply);
+ if (node)
+ list_for_each_entry(r, ®ulator_list, list)
+ if (node =3D=3D r->dev.parent->of_node)
+ return r;
+
+ /* if not found, try doing it non-dt way */
+ list_for_each_entry(r, ®ulator_list, list)
+ if (strcmp(rdev_get_name(r), supply) =3D=3D 0)
+ return r;
+
+ return NULL;
+}
+
/* Internal regulator request function */
static struct regulator *_regulator_get(struct device *dev, const char *id=
,
int exclusive)
@@ -1155,6 +1206,7 @@
struct regulator_map *map;
struct regulator *regulator =3D ERR_PTR(-ENODEV);
const char *devname =3D NULL;
+ struct device_node *node;
int ret;
if (id =3D=3D NULL) {
@@ -1167,6 +1219,10 @@
mutex_lock(®ulator_list_mutex);
+ rdev =3D regulator_dev_lookup(dev, id);
+ if (rdev)
+ goto found;
+
list_for_each_entry(map, ®ulator_map_list, list) {
/* If the mapping has a device set up it must match */
if (map->dev_name &&
@@ -2579,6 +2635,7 @@
static atomic_t regulator_no =3D ATOMIC_INIT(0);
struct regulator_dev *rdev;
int ret, i;
+ const char *supply;
if (regulator_desc =3D=3D NULL)
return ERR_PTR(-EINVAL);
@@ -2653,21 +2710,18 @@
if (ret < 0)
goto scrub;
- if (init_data->supply_regulator) {
+ if (init_data->supply_regulator)
+ supply =3D init_data->supply_regulator;
+ else if (regulator_desc->supply_name);
+ supply =3D regulator_desc->supply_name;
+
+ if (supply) {
struct regulator_dev *r;
- int found =3D 0;
- list_for_each_entry(r, ®ulator_list, list) {
- if (strcmp(rdev_get_name(r),
- init_data->supply_regulator) =3D=3D 0) {
- found =3D 1;
- break;
- }
- }
+ r =3D regulator_dev_lookup(dev, supply);
- if (!found) {
- dev_err(dev, "Failed to find supply %s\n",
- init_data->supply_regulator);
+ if (!r) {
+ dev_err(dev, "Failed to find supply %s\n", supply);
ret =3D -ENODEV;
goto scrub;
}
Index: linux/include/linux/regulator/driver.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- linux.orig/include/linux/regulator/driver.h 2011-10-11
11:43:27.936139476 +0530
+++ linux/include/linux/regulator/driver.h 2011-10-11 11:43:43.485351850 +0=
530
@@ -153,6 +153,7 @@
* this type.
*
* @name: Identifying name for the regulator.
+ * @supply_name: Identifying the regulator supply
* @id: Numerical identifier for the regulator.
* @n_voltages: Number of selectors available for ops.list_voltage().
* @ops: Regulator operations table.
@@ -162,6 +163,7 @@
*/
struct regulator_desc {
const char *name;
+ const char *supply_name;
int id;
unsigned n_voltages;
struct regulator_ops *ops;
^ permalink raw reply
* [PATCH] ARM: vexpress: initial device tree support
From: Dave Martin @ 2011-09-22 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E7A2334.7020904@firmworks.com>
On Wed, Sep 21, 2011 at 07:47:32AM -1000, Mitch Bradley wrote:
> On 9/21/2011 7:15 AM, Dave Martin wrote:
> >On Wed, Sep 21, 2011 at 11:37:54AM -0500, Rob Herring wrote:
> >>On 09/21/2011 09:57 AM, Grant Likely wrote:
> >>>On Wed, Sep 21, 2011 at 7:24 AM, Rob Herring<robherring2@gmail.com> wrote:
> >>>>On 09/21/2011 04:19 AM, Dave Martin wrote:
> >>>>> * arm,amba-bus -- widely used by other boards and patchsets, but
> >>>>> seems not to be documented.
> >>>>>
> >>>>
> >>>>This should be dropped. There's not really any bus component to an amba
> >>>>bus. All the probing info is within the primecell peripherals.
> >>>
> >>>No, if it is an AMBA bus, then it is entirely appropriate to declare
> >>>it as an amba bus, but to also be compatible with "simple-bus". In
> >>>fact, it would be better to use a compatible string that specifies the
> >>>specific implementation of AMBA bus since there are several versions
> >>>of the spec.
> >>
> >>And type of AMBA bus as the spec includes AXI, AHB, and APB. None of
> >>which have any sort of programmability or software view.
> >>
> >>If this is required, then the policy should be simple-bus should never
> >>be allowed alone as every bus has some underlying type. Seems like
> >>overkill for buses like this.
> >
> >The key question is _where_ to draw the line between generic and specific.
> >By definition, the DT can never be a comprehensive description of the
> >hardware -- rather a good DT is a description of those details of the hardware
> >which could relevant to any hypothetical OS.
> >
> >The flipside is that details which were thought to be irrelevant at
> >design/implementation time can turn out to be relevant in practice, due
> >to errata and implementation issues etc. So taking the description slightly
> >beyond what the OS needs to know can still have some merit.
> >
> >
> >I still don't know how to say where the line should be drawn in this particular
> >case though.
>
> Here are some criteria:
>
> If the controller for the bus itself has registers, include the bus node
>
> If it is possible to plug new stuff into the bus, include the bus node
>
> If the base address for the bus can be changed, thereby changing all
> the addresses of its subordinates by the same offset, include the
> bus node (this usually goes along with "has registers".)
>
> ARM buses typically don't have any of those attributes, but there
> are some weaker criteria that can be used to justify including a bus
> node. The SoC on which I'm currently working has some peripherals on
> AXI and others on APB. That doesn't matter from that addressing
> standpoint - the individual peripherals can each be viewed as having
> an address, end of story - but it does matter from a power
> management standpoint. The clock tree is quite related to the bus
> layout. Including bus nodes in the device tree might provide useful
> place-holders for properties describing power or clock domains.
>
> So, on the whole, I'm in favor of including bus nodes for ARM
> standard buses. There is little down side to doing so, and a fair
> chance that it might come in handy in the future.
I'm guessing that that would motivate describing most of the bus layout,
with the possible exception of bus adaptors which exist solely for the
purpose of integrating a single slave with the parent bus -- providing
such adaptors are transparent to software.
I'll have a think about what we would need to add...
Cheers
---Dave
^ permalink raw reply
* [PATCH V7 1/5] AHCI Add the AHCI SATA feature on the MX53 platforms
From: Eric Miao @ 2011-09-22 12:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAODfWeFPwUa++=Bz6503KJS9dNhmkjNuWF_g==MaFKydqRRX3A@mail.gmail.com>
On Thu, Sep 22, 2011 at 5:30 PM, Hector Oron <hector.oron@gmail.com> wrote:
> Hello,
>
> ?Apologies for late reply.
>
> 2011/9/6 Eric Miao <eric.miao@linaro.org>:
>> On Tue, Sep 6, 2011 at 1:46 AM, Hector Oron <hector.oron@gmail.com> wrote:
>>> 2011/9/1 Richard Zhu <richard.zhu@linaro.org>:
>
>>> Here is my complete dmesg. The system seems to work fine, it is a
>>> 1.0TB WD10TPVT SATA disk in a case which provides eSATA and connected
>>> to mx53 LOCO with eSATA-to-SATA cable.
>
>> Is it possible that it's caused by this converter? Do you have a separate
>> SATA power supply that could help test the disk directly connected to
>> mx53loco?
>
> I think I had a bad configuration setup for my kernel. I have rebuilt
> 3.1.0-rc6 from Sascha's master git with this patches and now SATA is
> working properly I do not see any issue as I did. So, from my side all
> is OK now, and I assume I had some missing or conflicting module
> setup.
>
> Kind regards and apologies for inconveniences,
That's great, Herton. Can we take it as a Tested-by?
> --
> ?H?ctor Or?n ?-.. . -... .. .- -. ? -.. . ...- . .-.. --- .--. . .-.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 2/2] ARM: mach-ux500: unlock I&D l2x0 caches before init
From: Linus Walleij @ 2011-09-22 12:16 UTC (permalink / raw)
To: linux-arm-kernel
From: Linus Walleij <linus.walleij@linaro.org>
Apparently U8500 U-Boot versions may leave the l2x0 locked down
before executing the kernel. Make sure we unlock it before we
initialize the l2x0. This fixes a performance problem reported
by Jan Rinze.
The l2x0 core has been modified to unlock the l2x0 by default,
but it will not touch the locking registers if the l2x0 was
already enabled, as on the ux500, so we need this quirk to
make sure it is properly turned off.
Cc: stable at kernel.org
Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Cc: Rabin Vincent <rabin.vincent@stericsson.com>
Cc: Adrian Bunk <adrian.bunk@movial.com>
Reported-by: Jan Rinze <janrinze@gmail.com>
Tested-by: Robert Marklund <robert.marklund@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-ux500/cpu.c | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-ux500/cpu.c b/arch/arm/mach-ux500/cpu.c
index 1da23bb..8aa104a 100644
--- a/arch/arm/mach-ux500/cpu.c
+++ b/arch/arm/mach-ux500/cpu.c
@@ -99,7 +99,27 @@ static void ux500_l2x0_inv_all(void)
ux500_cache_sync();
}
-static int ux500_l2x0_init(void)
+static int __init ux500_l2x0_unlock(void)
+{
+ int i;
+
+ /*
+ * Unlock Data and Instruction Lock if locked. Ux500 U-Boot versions
+ * apparently locks both caches before jumping to the kernel. The
+ * l2x0 core will not touch the unlock registers if the l2x0 is
+ * already enabled, so we do it right here instead. The PL310 has
+ * 8 sets of registers, one per possible CPU.
+ */
+ for (i = 0; i < 8; i++) {
+ writel_relaxed(0x0, l2x0_base + L2X0_LOCKDOWN_WAY_D_BASE +
+ i * L2X0_LOCKDOWN_STRIDE);
+ writel_relaxed(0x0, l2x0_base + L2X0_LOCKDOWN_WAY_I_BASE +
+ i * L2X0_LOCKDOWN_STRIDE);
+ }
+ return 0;
+}
+
+static int __init ux500_l2x0_init(void)
{
if (cpu_is_u5500())
l2x0_base = __io_address(U5500_L2CC_BASE);
@@ -108,6 +128,9 @@ static int ux500_l2x0_init(void)
else
ux500_unknown_soc();
+ /* Unlock before init */
+ ux500_l2x0_unlock();
+
/* 64KB way size, 8 way associativity, force WA */
l2x0_init(l2x0_base, 0x3e060000, 0xc0000fff);
--
1.7.3.2
^ permalink raw reply related
* [PATCH 1/2] ARM: mach-ux500: enable fix for ARM errata 754322
From: Linus Walleij @ 2011-09-22 12:16 UTC (permalink / raw)
To: linux-arm-kernel
From: srinidhi kasagar <srinidhi.kasagar@stericsson.com>
This applies ARM errata fix 754322 for all ux500 platforms.
Cc: stable at kernel.org
Signed-off-by: srinidhi kasagar <srinidhi.kasagar@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
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.3.2
^ permalink raw reply related
* [PATCH] arm: Add unwinding annotations for 64bit division functions
From: Jon Medhurst (Tixy) @ 2011-09-22 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110922115713.GJ12025@e102109-lin.cambridge.arm.com>
On Thu, 2011-09-22 at 12:57 +0100, Catalin Marinas wrote:
> On Thu, Sep 22, 2011 at 12:06:46PM +0100, Jon Medhurst (Tixy) wrote:
> > On Thu, 2011-09-22 at 10:48 +0100, Catalin Marinas wrote:
> > > We could improve things a bit in the unwinder and assume
> > > that if the fault address is the same as the .fnstart address, the
> > > return value is always in LR and the SP not affected (that's unwinding
> > > bytecode 0xb0). For a few instructions into the function prologue we
> > > can't reliably get the unwinding information.
> >
> > That would help make it possible to unwind out of kprobes handlers to
> > the probed function. The kprobes code itself would need work as well,
> > and possibly the undef handler. Do we think it is worthwhile to do
> > this?
>
> Does kprobes need to trace beyond the probed function? If not, you get
> the address of the probed function via pt_regs anyway, so no need for
> unwinding beyond that.
To be honest, I'm not very sure how kprobes get used in the real world.
Though, if stack unwinding from their handlers currently doesn't work
and people had a usecase for it, we would expect them to complain.
--
Tixy
^ permalink raw reply
* [PATCH] arm: Add unwinding annotations for 64bit division functions
From: Catalin Marinas @ 2011-09-22 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316689606.2053.29.camel@linaro1>
On Thu, Sep 22, 2011 at 12:06:46PM +0100, Jon Medhurst (Tixy) wrote:
> On Thu, 2011-09-22 at 10:48 +0100, Catalin Marinas wrote:
> > We could improve things a bit in the unwinder and assume
> > that if the fault address is the same as the .fnstart address, the
> > return value is always in LR and the SP not affected (that's unwinding
> > bytecode 0xb0). For a few instructions into the function prologue we
> > can't reliably get the unwinding information.
>
> That would help make it possible to unwind out of kprobes handlers to
> the probed function. The kprobes code itself would need work as well,
> and possibly the undef handler. Do we think it is worthwhile to do
> this?
Does kprobes need to trace beyond the probed function? If not, you get
the address of the probed function via pt_regs anyway, so no need for
unwinding beyond that.
--
Catalin
^ permalink raw reply
* [V8 PATCH 5/5] MX53 Enable the AHCI SATA on MX53 SMD board
From: Sergei Shtylyov @ 2011-09-22 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316686488-4684-6-git-send-email-richard.zhu@linaro.org>
Hello.
On 22-09-2011 14:14, Richard Zhu wrote:
> Signed-off-by: Richard Zhu<richard.zhu@linaro.org>
> ---
> arch/arm/mach-mx5/board-mx53_smd.c | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
> diff --git a/arch/arm/mach-mx5/board-mx53_smd.c b/arch/arm/mach-mx5/board-mx53_smd.c
> index bc02894..9d06fbe 100644
> --- a/arch/arm/mach-mx5/board-mx53_smd.c
> +++ b/arch/arm/mach-mx5/board-mx53_smd.c
[...]
> @@ -111,6 +112,19 @@ static const struct imxi2c_platform_data mx53_smd_i2c_data __initconst = {
> .bitrate = 100000,
> };
>
> +static inline void mx53_smd_ahci_pwr_on(void)
> +{
> + int ret;
> +
> + /* Enable SATA PWR */
> + ret = gpio_request(MX53_SMD_SATA_PWR_EN, "ahci-sata-pwr");
> + if (ret) {
> + printk(KERN_ERR "failed to get SATA_PWR_EN: %d\n", ret);
> + return;
> + }
> + gpio_direction_output(MX53_SMD_SATA_PWR_EN, 1);
You can use gpio_request_one() instead of gpio_request()/gpio_direction_*().
WBR, Sergei
^ permalink raw reply
* [GIT PULL] ux500-core for 3.2
From: Arnd Bergmann @ 2011-09-22 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdakwQMaqJ4TwXxPJYjayMjO5iN68RQSZODGfhGCEjXnZA@mail.gmail.com>
On Thursday 22 September 2011, Linus Walleij wrote:
> On Tue, Sep 20, 2011 at 10:48 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 20 September 2011, Linus Walleij wrote:
> >> 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 would really like to see this split into logical branches, even
> > if there are just a few patches for each of them.
>
> No problem. So the preferred scheme is to have three topics
> for a SoC: fixes, cleanup and "new stuff" or something like that?
Roughly, yes. For new stuff, you can have multiple sub-categories,
depending on how many patches you have.
Some platforms have separated board-specific updates from overall
platform changes, which I find very useful.
Also, if you add (or remove) a major feature, that can be a branch
by itself for this feature.
> > It's also not clear if the two bug fix patches should be applied
> > to 3.1 and -stable as well as 3.2. My feeling is that they should.
>
> Depends. For Srinidhi's
> "mach-ux500: enable fix for ARM errata 754322"
> yes, definately.
>
> For:
> "mach-ux500: unlock I&D l2x0 caches before init"
> it's a performance regression, nothing like a crash or so.
>
> (I guess you're referring to these two?)
Right, thanks for the explanation. If the latter is a regression,
I'd still treat it as a bug fix. For a general (non-regression)
performance improvement, I'd put it into a development branch.
> > If you want bug fixes to be backported, please add a 'Cc: stable at kernel.org'
> > line after your Signed-off-by. If not, add an explanation to the
> > pull request why they are not relevant for backporting.
> (...)
> > Please submit the two bug fixes again, rebased to an -rc release.
>
> I'll fix.
>
> Since it's just two patches I guess you can just pick these
> two in plaintext? But I can make a pull request if you prefer...
In general, I prefer pull requests, but if you have no other patches
for 3.2, I can just cherry-pick them from the branch I already pulled.
I would put the first patch into fixes for 3.1 and mark it as 'Cc:stable'
and the other one into fixes for 3.2 then.
Arnd
^ permalink raw reply
* [GIT PULL] ux500-core for 3.2
From: Linus Walleij @ 2011-09-22 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109202248.01993.arnd@arndb.de>
On Tue, Sep 20, 2011 at 10:48 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 20 September 2011, Linus Walleij wrote:
>> 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 would really like to see this split into logical branches, even
> if there are just a few patches for each of them.
No problem. So the preferred scheme is to have three topics
for a SoC: fixes, cleanup and "new stuff" or something like that?
> It's also not clear if the two bug fix patches should be applied
> to 3.1 and -stable as well as 3.2. My feeling is that they should.
Depends. For Srinidhi's
"mach-ux500: enable fix for ARM errata 754322"
yes, definately.
For:
"mach-ux500: unlock I&D l2x0 caches before init"
it's a performance regression, nothing like a crash or so.
(I guess you're referring to these two?)
> If you want bug fixes to be backported, please add a 'Cc: stable at kernel.org'
> line after your Signed-off-by. If not, add an explanation to the
> pull request why they are not relevant for backporting.
(...)
> Please submit the two bug fixes again, rebased to an -rc release.
I'll fix.
Since it's just two patches I guess you can just pick these
two in plaintext? But I can make a pull request if you prefer...
Thanks,
Linus Walleij
^ permalink raw reply
* booting single uImage on platforms with different base addresses for SDRAM
From: Russell King - ARM Linux @ 2011-09-22 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110922110411.GD20444@tbergstrom-lnx.Nvidia.com>
On Thu, Sep 22, 2011 at 02:04:12PM +0300, Peter De Schrijver wrote:
> Currently uImages have the load address hardcoded. As we now try to support
> as many ARM platforms as possible with a single binary, this becomes a
> problem. On tegra20 SDRAM starts at physical address 0, but on tegra30 SDRAM
> starts at 0x80000000. It's possible to build a kernel image which can deal
> with this, but the uImage still uses a hardcoded address. This results
> in requiring 2 different uImages even though the zImage is the same.
This is a problem with the uImage format. It can only be fixed in uboot
- it's not a kernel problem.
> Has anyone thought of a solution to this problem?
There was talk about making '0' or something a special address, and
fixing uboot to place it appropriately (in much the same way that the
other boot loaders such as blob's offset from the start of RAM, or
redboot's scripted loading which takes the load address.)
^ permalink raw reply
* [PATCH] arm: Add unwinding annotations for 64bit division functions
From: Jon Medhurst (Tixy) @ 2011-09-22 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHkRjk7B4Bmt2g6ptHO3TudXgrkr5rv4b--Hbx-mw7=MO9Q+BQ@mail.gmail.com>
On Thu, 2011-09-22 at 10:48 +0100, Catalin Marinas wrote:
> On 22 September 2011 08:28, Jon Medhurst (Tixy) <jon.medhurst@linaro.org> wrote:
> > On Wed, 2011-09-21 at 12:55 +0100, Russell King - ARM Linux wrote:
> >> Instructions such as VFP, kprobes tracing, etc are expected fault
> >> locations, and those are fairly well controlled where they can be placed.
> >> With things like ftrace, it certainly is the case that the unwinder can
> >> theoretically be called from almost anywhere in a function.
> >
> > Actually, kprobes can be places on any instruction in the kernel that
> > isn't in the section .kprobes.text.
> >
> > I also strongly suspect that stack unwinding won't happen correctly
> > across the boundary between the kprobes handling code and the function
> > which was probed - there's an awful lot of stack jiggery pokery going on
> > there.
>
> Are people most likely to place kprobes on the first instruction of a
> function?
I believe that is the usual case.
> We could improve things a bit in the unwinder and assume
> that if the fault address is the same as the .fnstart address, the
> return value is always in LR and the SP not affected (that's unwinding
> bytecode 0xb0). For a few instructions into the function prologue we
> can't reliably get the unwinding information.
That would help make it possible to unwind out of kprobes handlers to
the probed function. The kprobes code itself would need work as well,
and possibly the undef handler. Do we think it is worthwhile to do
this?
--
Tixy
^ permalink raw reply
* booting single uImage on platforms with different base addresses for SDRAM
From: Peter De Schrijver @ 2011-09-22 11:04 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Currently uImages have the load address hardcoded. As we now try to support
as many ARM platforms as possible with a single binary, this becomes a
problem. On tegra20 SDRAM starts at physical address 0, but on tegra30 SDRAM
starts at 0x80000000. It's possible to build a kernel image which can deal
with this, but the uImage still uses a hardcoded address. This results
in requiring 2 different uImages even though the zImage is the same.
Has anyone thought of a solution to this problem?
Thanks,
Peter.
^ permalink raw reply
* [V8 PATCH 5/5] MX53 Enable the AHCI SATA on MX53 SMD board
From: Fabio Estevam @ 2011-09-22 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316686488-4684-6-git-send-email-richard.zhu@linaro.org>
On Thu, Sep 22, 2011 at 7:14 AM, Richard Zhu <richard.zhu@linaro.org> wrote:
> Signed-off-by: Richard Zhu <richard.zhu@linaro.org>
> ---
> ?arch/arm/mach-mx5/board-mx53_smd.c | ? 16 ++++++++++++++++
> ?1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-mx5/board-mx53_smd.c b/arch/arm/mach-mx5/board-mx53_smd.c
> index bc02894..9d06fbe 100644
> --- a/arch/arm/mach-mx5/board-mx53_smd.c
> +++ b/arch/arm/mach-mx5/board-mx53_smd.c
> @@ -35,6 +35,7 @@
> ?#include "devices-imx53.h"
>
> ?#define SMD_FEC_PHY_RST ? ? ? ? ? ? ? ?IMX_GPIO_NR(7, 6)
> +#define MX53_SMD_SATA_PWR_EN ? ?IMX_GPIO_NR(3, 3)
>
> ?static iomux_v3_cfg_t mx53_smd_pads[] = {
> ? ? ? ?MX53_PAD_CSI0_DAT10__UART1_TXD_MUX,
> @@ -111,6 +112,19 @@ static const struct imxi2c_platform_data mx53_smd_i2c_data __initconst = {
> ? ? ? ?.bitrate = 100000,
> ?};
>
> +static inline void mx53_smd_ahci_pwr_on(void)
> +{
> + ? ? ? int ret;
> +
> + ? ? ? /* Enable SATA PWR */
> + ? ? ? ret = gpio_request(MX53_SMD_SATA_PWR_EN, "ahci-sata-pwr");
Please use gpio_request_one.
> + ? ? ? if (ret) {
> + ? ? ? ? ? ? ? printk(KERN_ERR "failed to get SATA_PWR_EN: %d\n", ret);
You can use pr_err instead.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH] ARM: pxa/cm-x300: properly set bt_reset pin
From: Igor Grinberg @ 2011-09-22 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316268934.16763.2.camel@phoenix>
Hi Axel,
On 09/17/11 17:15, Axel Lin wrote:
> Fix below build warning and properly set bt_reset pin.
>
> CC arch/arm/mach-pxa/cm-x300.o
> arch/arm/mach-pxa/cm-x300.c: In function 'cm_x300_init_wi2wi':
> arch/arm/mach-pxa/cm-x300.c:779: warning: unused variable 'wlan_en'
> arch/arm/mach-pxa/cm-x300.c:795: warning: 'bt_reset' may be used uninitialized in this function
What a shame...
My patch 5a009df1f200efa49658b0e9c7ad056d59fbefe4
(ARM: pxa/cm-x300: GPIO cleanup) was f*cked up, sorry...
I should have not send it in a rush and I admit,
I had no possibility to test it. Sorry again...
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
Thanks for spotting this.
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Also, this patch fixes a real regression since
5a009df1f200efa49658b0e9c7ad056d59fbefe4 (ARM: pxa/cm-x300: GPIO cleanup)
- Wifi and Bluetooth do not work without it, so please:
Cc: <stable@kernel.org> [3.0.x]
> ---
> arch/arm/mach-pxa/cm-x300.c | 8 +++-----
> 1 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/cm-x300.c b/arch/arm/mach-pxa/cm-x300.c
> index 0f00e01..0e18eb9 100644
> --- a/arch/arm/mach-pxa/cm-x300.c
> +++ b/arch/arm/mach-pxa/cm-x300.c
> @@ -776,7 +776,6 @@ static struct gpio cm_x300_wi2wi_gpios[] __initdata = {
>
> static void __init cm_x300_init_wi2wi(void)
> {
> - int bt_reset, wlan_en;
> int err;
>
> if (system_rev < 130) {
> @@ -792,12 +791,11 @@ static void __init cm_x300_init_wi2wi(void)
> }
>
> udelay(10);
> - gpio_set_value(bt_reset, 0);
> + gpio_set_value(cm_x300_wi2wi_gpios[1].gpio, 0);
> udelay(10);
> - gpio_set_value(bt_reset, 1);
> + gpio_set_value(cm_x300_wi2wi_gpios[1].gpio, 1);
>
> - gpio_free(wlan_en);
> - gpio_free(bt_reset);
> + gpio_free_array(ARRAY_AND_SIZE(cm_x300_wi2wi_gpios));
> }
>
> /* MFP */
--
Regards,
Igor.
^ permalink raw reply
* [V8 PATCH 5/5] MX53 Enable the AHCI SATA on MX53 SMD board
From: Richard Zhu @ 2011-09-22 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316686488-4684-1-git-send-email-richard.zhu@linaro.org>
Signed-off-by: Richard Zhu <richard.zhu@linaro.org>
---
arch/arm/mach-mx5/board-mx53_smd.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx5/board-mx53_smd.c b/arch/arm/mach-mx5/board-mx53_smd.c
index bc02894..9d06fbe 100644
--- a/arch/arm/mach-mx5/board-mx53_smd.c
+++ b/arch/arm/mach-mx5/board-mx53_smd.c
@@ -35,6 +35,7 @@
#include "devices-imx53.h"
#define SMD_FEC_PHY_RST IMX_GPIO_NR(7, 6)
+#define MX53_SMD_SATA_PWR_EN IMX_GPIO_NR(3, 3)
static iomux_v3_cfg_t mx53_smd_pads[] = {
MX53_PAD_CSI0_DAT10__UART1_TXD_MUX,
@@ -111,6 +112,19 @@ static const struct imxi2c_platform_data mx53_smd_i2c_data __initconst = {
.bitrate = 100000,
};
+static inline void mx53_smd_ahci_pwr_on(void)
+{
+ int ret;
+
+ /* Enable SATA PWR */
+ ret = gpio_request(MX53_SMD_SATA_PWR_EN, "ahci-sata-pwr");
+ if (ret) {
+ printk(KERN_ERR "failed to get SATA_PWR_EN: %d\n", ret);
+ return;
+ }
+ gpio_direction_output(MX53_SMD_SATA_PWR_EN, 1);
+}
+
static void __init mx53_smd_board_init(void)
{
imx53_soc_init();
@@ -125,6 +139,8 @@ static void __init mx53_smd_board_init(void)
imx53_add_sdhci_esdhc_imx(0, NULL);
imx53_add_sdhci_esdhc_imx(1, NULL);
imx53_add_sdhci_esdhc_imx(2, NULL);
+ mx53_smd_ahci_pwr_on();
+ imx53_add_ahci_imx();
}
static void __init mx53_smd_timer_init(void)
--
1.7.1
^ permalink raw reply related
* [V8 PATCH 4/5] MX53 Enable the AHCI SATA on MX53 LOCO board
From: Richard Zhu @ 2011-09-22 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316686488-4684-1-git-send-email-richard.zhu@linaro.org>
Signed-off-by: Richard Zhu <richard.zhu@linaro.org>
---
arch/arm/mach-mx5/board-mx53_loco.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx5/board-mx53_loco.c b/arch/arm/mach-mx5/board-mx53_loco.c
index 4e1d51d..940aac9 100644
--- a/arch/arm/mach-mx5/board-mx53_loco.c
+++ b/arch/arm/mach-mx5/board-mx53_loco.c
@@ -273,6 +273,7 @@ static void __init mx53_loco_board_init(void)
imx53_add_sdhci_esdhc_imx(2, &mx53_loco_sd3_data);
imx_add_gpio_keys(&loco_button_data);
gpio_led_register_device(-1, &mx53loco_leds_data);
+ imx53_add_ahci_imx();
}
static void __init mx53_loco_timer_init(void)
--
1.7.1
^ permalink raw reply related
* [V8 PATCH 3/5] MX53 Enable the AHCI SATA on MX53 ARD board
From: Richard Zhu @ 2011-09-22 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316686488-4684-1-git-send-email-richard.zhu@linaro.org>
Signed-off-by: Richard Zhu <richard.zhu@linaro.org>
---
arch/arm/mach-mx5/board-mx53_ard.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx5/board-mx53_ard.c b/arch/arm/mach-mx5/board-mx53_ard.c
index 76a67c4..ef2039e 100644
--- a/arch/arm/mach-mx5/board-mx53_ard.c
+++ b/arch/arm/mach-mx5/board-mx53_ard.c
@@ -234,6 +234,7 @@ static void __init mx53_ard_board_init(void)
imx53_add_imx_i2c(1, &mx53_ard_i2c2_data);
imx53_add_imx_i2c(2, &mx53_ard_i2c3_data);
imx_add_gpio_keys(&ard_button_data);
+ imx53_add_ahci_imx();
}
static void __init mx53_ard_timer_init(void)
--
1.7.1
^ permalink raw reply related
* [V8 PATCH 2/5] ahci_plt Add the board_ids and pi refer to different features
From: Richard Zhu @ 2011-09-22 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316686488-4684-1-git-send-email-richard.zhu@linaro.org>
On imx53 AHCI, soft reset fails with IPMS set when PMP
is enabled but SATA HDD/ODD is connected to SATA port,
do soft reset again to port 0.
So the 'ahci_pmp_retry_srst_ops' is required when imx53
ahci is present.
Signed-off-by: Richard Zhu <richard.zhu@linaro.org>
Acked-by: Eric Miao <eric.miao@linaro.org>
---
drivers/ata/ahci_platform.c | 44 +++++++++++++++++++++++++++++++++++++-----
1 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 6fef1fa..c03277d 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -23,6 +23,41 @@
#include <linux/ahci_platform.h>
#include "ahci.h"
+enum ahci_type {
+ AHCI, /* standard platform ahci */
+ IMX53_AHCI, /* ahci on i.mx53 */
+};
+
+static struct platform_device_id ahci_devtype[] = {
+ {
+ .name = "ahci",
+ .driver_data = AHCI,
+ }, {
+ .name = "imx53-ahci",
+ .driver_data = IMX53_AHCI,
+ }, {
+ /* sentinel */
+ }
+};
+MODULE_DEVICE_TABLE(platform, ahci_devtype);
+
+
+static const struct ata_port_info ahci_port_info[] = {
+ /* by features */
+ [AHCI] = {
+ .flags = AHCI_FLAG_COMMON,
+ .pio_mask = ATA_PIO4,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = &ahci_ops,
+ },
+ [IMX53_AHCI] = {
+ .flags = AHCI_FLAG_COMMON,
+ .pio_mask = ATA_PIO4,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = &ahci_pmp_retry_srst_ops,
+ },
+};
+
static struct scsi_host_template ahci_platform_sht = {
AHCI_SHT("ahci_platform"),
};
@@ -31,12 +66,8 @@ static int __init ahci_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct ahci_platform_data *pdata = dev->platform_data;
- struct ata_port_info pi = {
- .flags = AHCI_FLAG_COMMON,
- .pio_mask = ATA_PIO4,
- .udma_mask = ATA_UDMA6,
- .port_ops = &ahci_ops,
- };
+ const struct platform_device_id *id = platform_get_device_id(pdev);
+ struct ata_port_info pi = ahci_port_info[id->driver_data];
const struct ata_port_info *ppi[] = { &pi, NULL };
struct ahci_host_priv *hpriv;
struct ata_host *host;
@@ -177,6 +208,7 @@ static struct platform_driver ahci_driver = {
.name = "ahci",
.owner = THIS_MODULE,
},
+ .id_table = ahci_devtype,
};
static int __init ahci_init(void)
--
1.7.1
^ permalink raw reply related
* [V8 PATCH 1/5] AHCI Add the AHCI SATA feature on the MX53 platforms
From: Richard Zhu @ 2011-09-22 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316686488-4684-1-git-send-email-richard.zhu@linaro.org>
Signed-off-by: Richard Zhu <richard.zhu@linaro.org>
Tested-by: Hector Oron Martinez <hector.oron@gmail.com>
---
arch/arm/mach-mx5/clock-mx51-mx53.c | 19 +++
arch/arm/mach-mx5/devices-imx53.h | 2 +
arch/arm/plat-mxc/devices/Kconfig | 4 +
arch/arm/plat-mxc/devices/Makefile | 1 +
arch/arm/plat-mxc/devices/platform-ahci-imx.c | 156 +++++++++++++++++++++++
arch/arm/plat-mxc/include/mach/devices-common.h | 10 ++
6 files changed, 192 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-mxc/devices/platform-ahci-imx.c
diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c b/arch/arm/mach-mx5/clock-mx51-mx53.c
index 7f20308..e1fadaf 100644
--- a/arch/arm/mach-mx5/clock-mx51-mx53.c
+++ b/arch/arm/mach-mx5/clock-mx51-mx53.c
@@ -1397,6 +1397,22 @@ static struct clk esdhc4_mx53_clk = {
.secondary = &esdhc4_ipg_clk,
};
+static struct clk sata_clk = {
+ .parent = &ipg_clk,
+ .enable = _clk_max_enable,
+ .enable_reg = MXC_CCM_CCGR4,
+ .enable_shift = MXC_CCM_CCGRx_CG1_OFFSET,
+ .disable = _clk_max_disable,
+};
+
+static struct clk ahci_phy_clk = {
+ .parent = &usb_phy1_clk,
+};
+
+static struct clk ahci_dma_clk = {
+ .parent = &ahb_clk,
+};
+
DEFINE_CLOCK(mipi_esc_clk, 0, MXC_CCM_CCGR4, MXC_CCM_CCGRx_CG5_OFFSET, NULL, NULL, NULL, &pll2_sw_clk);
DEFINE_CLOCK(mipi_hsc2_clk, 0, MXC_CCM_CCGR4, MXC_CCM_CCGRx_CG4_OFFSET, NULL, NULL, &mipi_esc_clk, &pll2_sw_clk);
DEFINE_CLOCK(mipi_hsc1_clk, 0, MXC_CCM_CCGR4, MXC_CCM_CCGRx_CG3_OFFSET, NULL, NULL, &mipi_hsc2_clk, &pll2_sw_clk);
@@ -1503,6 +1519,9 @@ static struct clk_lookup mx53_lookups[] = {
_REGISTER_CLOCK("imx-ssi.1", NULL, ssi2_clk)
_REGISTER_CLOCK("imx-ssi.2", NULL, ssi3_clk)
_REGISTER_CLOCK("imx-keypad", NULL, dummy_clk)
+ _REGISTER_CLOCK("imx53-ahci.0", "ahci", sata_clk)
+ _REGISTER_CLOCK("imx53-ahci.0", "ahci_phy", ahci_phy_clk)
+ _REGISTER_CLOCK("imx53-ahci.0", "ahci_dma", ahci_dma_clk)
};
static void clk_tree_init(void)
diff --git a/arch/arm/mach-mx5/devices-imx53.h b/arch/arm/mach-mx5/devices-imx53.h
index c27fe8b..1ab399e 100644
--- a/arch/arm/mach-mx5/devices-imx53.h
+++ b/arch/arm/mach-mx5/devices-imx53.h
@@ -40,3 +40,5 @@ extern const struct imx_imx_ssi_data imx53_imx_ssi_data[];
extern const struct imx_imx_keypad_data imx53_imx_keypad_data;
#define imx53_add_imx_keypad(pdata) \
imx_add_imx_keypad(&imx53_imx_keypad_data, pdata)
+
+extern struct platform_device *__init imx53_add_ahci_imx(void);
diff --git a/arch/arm/plat-mxc/devices/Kconfig b/arch/arm/plat-mxc/devices/Kconfig
index bd294ad..f63887b 100644
--- a/arch/arm/plat-mxc/devices/Kconfig
+++ b/arch/arm/plat-mxc/devices/Kconfig
@@ -76,3 +76,7 @@ config IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
config IMX_HAVE_PLATFORM_SPI_IMX
bool
+
+config IMX_HAVE_PLATFORM_AHCI
+ bool
+ default y if ARCH_MX53
diff --git a/arch/arm/plat-mxc/devices/Makefile b/arch/arm/plat-mxc/devices/Makefile
index b41bf97..e858ad9 100644
--- a/arch/arm/plat-mxc/devices/Makefile
+++ b/arch/arm/plat-mxc/devices/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_RTC) += platform-mxc_rtc.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_W1) += platform-mxc_w1.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX) += platform-sdhci-esdhc-imx.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_SPI_IMX) += platform-spi_imx.o
+obj-$(CONFIG_IMX_HAVE_PLATFORM_AHCI) += platform-ahci-imx.o
diff --git a/arch/arm/plat-mxc/devices/platform-ahci-imx.c b/arch/arm/plat-mxc/devices/platform-ahci-imx.c
new file mode 100644
index 0000000..d8a56ae
--- /dev/null
+++ b/arch/arm/plat-mxc/devices/platform-ahci-imx.c
@@ -0,0 +1,156 @@
+/*
+ * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/device.h>
+#include <linux/dma-mapping.h>
+#include <asm/sizes.h>
+#include <mach/hardware.h>
+#include <mach/devices-common.h>
+
+#define imx_ahci_imx_data_entry_single(soc, _devid) \
+ { \
+ .devid = _devid, \
+ .iobase = soc ## _SATA_BASE_ADDR, \
+ .irq = soc ## _INT_SATA, \
+ }
+
+#ifdef CONFIG_SOC_IMX53
+const struct imx_ahci_imx_data imx53_ahci_imx_data __initconst =
+ imx_ahci_imx_data_entry_single(MX53, "imx53-ahci");
+#endif
+
+enum {
+ HOST_CAP = 0x00,
+ HOST_CAP_SSS = (1 << 27), /* Staggered Spin-up */
+ HOST_PORTS_IMPL = 0x0c,
+ HOST_TIMER1MS = 0xe0, /* Timer 1-ms */
+};
+
+static struct clk *sata_clk, *sata_ref_clk;
+
+/* AHCI module Initialization, if return 0, initialization is successful. */
+static int imx_sata_init(struct device *dev, void __iomem *addr)
+{
+ u32 tmpdata;
+ int ret = 0;
+ struct clk *clk;
+
+ sata_clk = clk_get(dev, "ahci");
+ if (IS_ERR(sata_clk)) {
+ dev_err(dev, "no sata clock.\n");
+ return PTR_ERR(sata_clk);
+ }
+ ret = clk_enable(sata_clk);
+ if (ret) {
+ dev_err(dev, "can't enable sata clock.\n");
+ goto put_sata_clk;
+ }
+
+ /* Get the AHCI SATA PHY CLK */
+ sata_ref_clk = clk_get(dev, "ahci_phy");
+ if (IS_ERR(sata_ref_clk)) {
+ dev_err(dev, "no sata ref clock.\n");
+ ret = PTR_ERR(sata_ref_clk);
+ goto release_sata_clk;
+ }
+ ret = clk_enable(sata_ref_clk);
+ if (ret) {
+ dev_err(dev, "can't enable sata ref clock.\n");
+ goto put_sata_ref_clk;
+ }
+
+ /* Get the AHB clock rate, and configure the TIMER1MS reg later */
+ clk = clk_get(dev, "ahci_dma");
+ if (IS_ERR(clk)) {
+ dev_err(dev, "no dma clock.\n");
+ ret = PTR_ERR(clk);
+ goto release_sata_ref_clk;
+ }
+ tmpdata = clk_get_rate(clk) / 1000;
+ clk_put(clk);
+
+ writel(tmpdata, addr + HOST_TIMER1MS);
+
+ tmpdata = readl(addr + HOST_CAP);
+ if (!(tmpdata & HOST_CAP_SSS)) {
+ tmpdata |= HOST_CAP_SSS;
+ writel(tmpdata, addr + HOST_CAP);
+ }
+
+ if (!(readl(addr + HOST_PORTS_IMPL) & 0x1))
+ writel((readl(addr + HOST_PORTS_IMPL) | 0x1),
+ addr + HOST_PORTS_IMPL);
+
+ return 0;
+
+release_sata_ref_clk:
+ clk_disable(sata_ref_clk);
+put_sata_ref_clk:
+ clk_put(sata_ref_clk);
+release_sata_clk:
+ clk_disable(sata_clk);
+put_sata_clk:
+ clk_put(sata_clk);
+
+ return ret;
+}
+
+static void imx_sata_exit(struct device *dev)
+{
+ clk_disable(sata_ref_clk);
+ clk_put(sata_ref_clk);
+
+ clk_disable(sata_clk);
+ clk_put(sata_clk);
+
+}
+struct platform_device *__init imx_add_ahci_imx(
+ const struct imx_ahci_imx_data *data,
+ const struct ahci_platform_data *pdata)
+{
+ struct resource res[] = {
+ {
+ .start = data->iobase,
+ .end = data->iobase + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = data->irq,
+ .end = data->irq,
+ .flags = IORESOURCE_IRQ,
+ },
+ };
+
+ return imx_add_platform_device_dmamask(data->devid, 0,
+ res, ARRAY_SIZE(res),
+ pdata, sizeof(*pdata), DMA_BIT_MASK(32));
+}
+
+struct platform_device *__init imx53_add_ahci_imx(void)
+{
+ struct ahci_platform_data pdata = {
+ .init = imx_sata_init,
+ .exit = imx_sata_exit,
+ };
+
+ return imx_add_ahci_imx(&imx53_ahci_imx_data, &pdata);
+}
diff --git a/arch/arm/plat-mxc/include/mach/devices-common.h b/arch/arm/plat-mxc/include/mach/devices-common.h
index 524538a..f04e063 100644
--- a/arch/arm/plat-mxc/include/mach/devices-common.h
+++ b/arch/arm/plat-mxc/include/mach/devices-common.h
@@ -301,3 +301,13 @@ struct platform_device *__init imx_add_spi_imx(
struct platform_device *imx_add_imx_dma(void);
struct platform_device *imx_add_imx_sdma(char *name,
resource_size_t iobase, int irq, struct sdma_platform_data *pdata);
+
+#include <linux/ahci_platform.h>
+struct imx_ahci_imx_data {
+ const char *devid;
+ resource_size_t iobase;
+ resource_size_t irq;
+};
+struct platform_device *__init imx_add_ahci_imx(
+ const struct imx_ahci_imx_data *data,
+ const struct ahci_platform_data *pdata);
--
1.7.1
^ permalink raw reply related
* [V8 PATCH 0/5] imx53 ahci driver v8
From: Richard Zhu @ 2011-09-22 10:14 UTC (permalink / raw)
To: linux-arm-kernel
*** BLURB HERE ***
This is the seventh iteration of the imx53 ahci patch. Changes between
v5 and v7 are described in the following description.
ChangeLog v5->v6:
- Move the most ahci initialization codes from the board related files
to the common ahci_sata file.
- Add the imx53 ahci's own ata_port_info definition in ahci_platform
driver, since the 'ahci_pmp_retry_srst_ops' is required when imx53
ahci is present.
ChangeLog v6->v7:
- Define the default imx53 ahci platform data, reduce the modificatons
on the board related files.
- Handle the sata_pwr_en pin obviously on smd board.
ChangeLog V7->V8
- Accept Sascha's suggestions.
* Rename sata_init/sata_exit to imx_sata_init/imx_sata_exit.
* move the init/exit as static functions to platform-ahci-imx.c file.
Make a wrapper on these functions, and avoid to pass the function
hooks by platform data.
Richard Zhu (5):
AHCI Add the AHCI SATA feature on the MX53 platforms
ahci_plt Add the board_ids and pi refer to different features
MX53 Enable the AHCI SATA on MX53 ARD board
MX53 Enable the AHCI SATA on MX53 LOCO board
MX53 Enable the AHCI SATA on MX53 SMD board
arch/arm/mach-mx5/board-mx53_ard.c | 1 +
arch/arm/mach-mx5/board-mx53_loco.c | 1 +
arch/arm/mach-mx5/board-mx53_smd.c | 16 +++
arch/arm/mach-mx5/clock-mx51-mx53.c | 19 +++
arch/arm/mach-mx5/devices-imx53.h | 2 +
arch/arm/plat-mxc/devices/Kconfig | 4 +
arch/arm/plat-mxc/devices/Makefile | 1 +
arch/arm/plat-mxc/devices/platform-ahci-imx.c | 156 +++++++++++++++++++++++
arch/arm/plat-mxc/include/mach/devices-common.h | 10 ++
drivers/ata/ahci_platform.c | 44 ++++++-
10 files changed, 248 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/plat-mxc/devices/platform-ahci-imx.c
^ permalink raw reply
* [PATCH 3/3] arm/tegra: device tree support for ventana board
From: Peter De Schrijver @ 2011-09-22 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316686384-20236-1-git-send-email-pdeschrijver@nvidia.com>
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
---
arch/arm/boot/dts/tegra-ventana.dts | 32 ++++++++++++++++++++++++++++++++
arch/arm/mach-tegra/Kconfig | 6 ++++++
arch/arm/mach-tegra/Makefile.boot | 1 +
arch/arm/mach-tegra/board-dt.c | 5 ++++-
4 files changed, 43 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/boot/dts/tegra-ventana.dts
diff --git a/arch/arm/boot/dts/tegra-ventana.dts b/arch/arm/boot/dts/tegra-ventana.dts
new file mode 100644
index 0000000..9b29a62
--- /dev/null
+++ b/arch/arm/boot/dts/tegra-ventana.dts
@@ -0,0 +1,32 @@
+/dts-v1/;
+
+/memreserve/ 0x1c000000 0x04000000;
+/include/ "tegra20.dtsi"
+
+/ {
+ model = "NVIDIA Tegra2 Ventana evaluation board";
+ compatible = "nvidia,ventana", "nvidia,tegra20";
+
+ chosen {
+ bootargs = "vmalloc=192M video=tegrafb console=ttyS0,115200n8 root=/dev/ram rdinit=/sbin/init";
+ };
+
+ memory {
+ reg = < 0x00000000 0x40000000 >;
+ };
+
+ serial at 70006300 {
+ clock-frequency = < 216000000 >;
+ };
+
+ sdhci at c8000400 {
+ cd-gpios = <&gpio 69 0>; /* gpio PI5 */
+ wp-gpios = <&gpio 57 0>; /* gpio PH1 */
+ power-gpios = <&gpio 155 0>; /* gpio PT3 */
+ };
+
+ sdhci at c8000600 {
+ power-gpios = <&gpio 70 0>; /* gpio PI6 */
+ support-8bit;
+ };
+};
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index d82ebab..91aff7c 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -69,6 +69,12 @@ config MACH_WARIO
help
Support for the Wario version of Seaboard
+config MACH_VENTANA
+ bool "Ventana board"
+ select MACH_TEGRA_DT
+ help
+ Support for the nVidia Ventana development platform
+
choice
prompt "Low-level debug console UART"
default TEGRA_DEBUG_UART_NONE
diff --git a/arch/arm/mach-tegra/Makefile.boot b/arch/arm/mach-tegra/Makefile.boot
index 5e870d2..bd12c9f 100644
--- a/arch/arm/mach-tegra/Makefile.boot
+++ b/arch/arm/mach-tegra/Makefile.boot
@@ -4,3 +4,4 @@ initrd_phys-$(CONFIG_ARCH_TEGRA_2x_SOC) := 0x00800000
dtb-$(CONFIG_MACH_HARMONY) += tegra-harmony.dtb
dtb-$(CONFIG_MACH_SEABOARD) += tegra-seaboard.dtb
+dtb-$(CONFIG_MACH_VENTANA) += tegra-ventana.dtb
diff --git a/arch/arm/mach-tegra/board-dt.c b/arch/arm/mach-tegra/board-dt.c
index 9f47e04..5885102 100644
--- a/arch/arm/mach-tegra/board-dt.c
+++ b/arch/arm/mach-tegra/board-dt.c
@@ -47,7 +47,7 @@
void harmony_pinmux_init(void);
void seaboard_pinmux_init(void);
-
+void ventana_pinmux_init(void);
struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("nvidia,tegra20-sdhci", TEGRA_SDMMC1_BASE, "sdhci-tegra.0", NULL),
@@ -95,6 +95,8 @@ static void __init tegra_dt_init(void)
harmony_pinmux_init();
else if (of_machine_is_compatible("nvidia,seaboard"))
seaboard_pinmux_init();
+ else if (of_machine_is_compatible("nvidia,ventana"))
+ ventana_pinmux_init();
/*
* Finished with the static registrations now; fill in the missing
@@ -106,6 +108,7 @@ static void __init tegra_dt_init(void)
static const char * tegra_dt_board_compat[] = {
"nvidia,harmony",
"nvidia,seaboard",
+ "nvidia,ventana",
NULL
};
--
1.7.1
^ permalink raw reply related
* [PATCH 2/3] arm/tegra: add support for ventana pinmuxing
From: Peter De Schrijver @ 2011-09-22 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316686384-20236-1-git-send-email-pdeschrijver@nvidia.com>
Add support for ventana pinmuxing as a seaboard derivative. This is a cut down
version of chromeos kernel commit 772f1b56e713be7a55759c2d5eadb9eb11d078db
by Jong Kim <jongk@nvidia.com>.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
---
arch/arm/mach-tegra/board-seaboard-pinmux.c | 49 +++++++++++++++++++++++++-
1 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-tegra/board-seaboard-pinmux.c b/arch/arm/mach-tegra/board-seaboard-pinmux.c
index b31c765..89bb774 100644
--- a/arch/arm/mach-tegra/board-seaboard-pinmux.c
+++ b/arch/arm/mach-tegra/board-seaboard-pinmux.c
@@ -158,8 +158,26 @@ static __initdata struct tegra_pingroup_config seaboard_pinmux[] = {
{TEGRA_PINGROUP_XM2D, TEGRA_MUX_NONE, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
};
-
-
+static __initdata struct tegra_pingroup_config ventana_pinmux[] = {
+ {TEGRA_PINGROUP_DAP3, TEGRA_MUX_DAP3, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_DDC, TEGRA_MUX_RSVD2, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_DTA, TEGRA_MUX_VI, TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_DTB, TEGRA_MUX_VI, TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_DTC, TEGRA_MUX_VI, TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_DTD, TEGRA_MUX_VI, TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_GMD, TEGRA_MUX_SFLASH, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_LPW0, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_LPW2, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_LSC1, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_LSCK, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_LSDA, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_PTA, TEGRA_MUX_RSVD2, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_SLXC, TEGRA_MUX_SDIO3, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_SLXK, TEGRA_MUX_SDIO3, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_SPIA, TEGRA_MUX_GMI, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_SPIC, TEGRA_MUX_GMI, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_SPIG, TEGRA_MUX_SPI2_ALT, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+};
static struct tegra_gpio_table common_gpio_table[] = {
{ .gpio = TEGRA_GPIO_SD2_CD, .enable = true },
@@ -172,6 +190,26 @@ static struct tegra_gpio_table common_gpio_table[] = {
{ .gpio = TEGRA_GPIO_USB1, .enable = true },
};
+static void __init update_pinmux(struct tegra_pingroup_config *newtbl, int size)
+{
+ int i, j;
+ struct tegra_pingroup_config *new_pingroup, *base_pingroup;
+
+ /* Update base seaboard pinmux table with secondary board
+ * specific pinmux table table.
+ */
+ for (i = 0; i < size; i++) {
+ new_pingroup = &newtbl[i];
+ for (j = 0; j < ARRAY_SIZE(seaboard_pinmux); j++) {
+ base_pingroup = &seaboard_pinmux[j];
+ if (new_pingroup->pingroup == base_pingroup->pingroup) {
+ *base_pingroup = *new_pingroup;
+ break;
+ }
+ }
+ }
+}
+
static void __init seaboard_common_pinmux_init(void)
{
tegra_pinmux_config_table(seaboard_pinmux, ARRAY_SIZE(seaboard_pinmux));
@@ -186,3 +224,10 @@ void __init seaboard_pinmux_init(void)
{
seaboard_common_pinmux_init();
}
+
+void __init ventana_pinmux_init(void)
+{
+ update_pinmux(ventana_pinmux, ARRAY_SIZE(ventana_pinmux));
+ seaboard_common_pinmux_init();
+}
+
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox