* [PATCH 2/8] v5 Add new phys_index properties
From: Nathan Fontenot @ 2010-08-09 18:36 UTC (permalink / raw)
To: linux-kernel, linux-mm, linuxppc-dev
Cc: Greg KH, KAMEZAWA Hiroyuki, Dave Hansen
In-Reply-To: <4C60407C.2080608@austin.ibm.com>
Update the 'phys_index' properties of a memory block to include a
'start_phys_index' which is the same as the current 'phys_index' property.
The property still appears as 'phys_index' in sysfs but the memory_block
struct name is updated to indicate the start and end values.
This also adds an 'end_phys_index' property to indicate the id of the
last section in th memory block.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
---
drivers/base/memory.c | 28 ++++++++++++++++++++--------
include/linux/memory.h | 3 ++-
2 files changed, 22 insertions(+), 9 deletions(-)
Index: linux-2.6/drivers/base/memory.c
===================================================================
--- linux-2.6.orig/drivers/base/memory.c 2010-08-09 07:44:21.000000000 -0500
+++ linux-2.6/drivers/base/memory.c 2010-08-09 07:44:31.000000000 -0500
@@ -109,12 +109,20 @@ unregister_memory(struct memory_block *m
* uses.
*/
-static ssize_t show_mem_phys_index(struct sys_device *dev,
+static ssize_t show_mem_start_phys_index(struct sys_device *dev,
struct sysdev_attribute *attr, char *buf)
{
struct memory_block *mem =
container_of(dev, struct memory_block, sysdev);
- return sprintf(buf, "%08lx\n", mem->phys_index);
+ return sprintf(buf, "%08lx\n", mem->start_phys_index);
+}
+
+static ssize_t show_mem_end_phys_index(struct sys_device *dev,
+ struct sysdev_attribute *attr, char *buf)
+{
+ struct memory_block *mem =
+ container_of(dev, struct memory_block, sysdev);
+ return sprintf(buf, "%08lx\n", mem->end_phys_index);
}
/*
@@ -128,7 +136,7 @@ static ssize_t show_mem_removable(struct
struct memory_block *mem =
container_of(dev, struct memory_block, sysdev);
- start_pfn = section_nr_to_pfn(mem->phys_index);
+ start_pfn = section_nr_to_pfn(mem->start_phys_index);
ret = is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
return sprintf(buf, "%d\n", ret);
}
@@ -191,7 +199,7 @@ memory_block_action(struct memory_block
int ret;
int old_state = mem->state;
- psection = mem->phys_index;
+ psection = mem->start_phys_index;
first_page = pfn_to_page(psection << PFN_SECTION_SHIFT);
/*
@@ -264,7 +272,7 @@ store_mem_state(struct sys_device *dev,
int ret = -EINVAL;
mem = container_of(dev, struct memory_block, sysdev);
- phys_section_nr = mem->phys_index;
+ phys_section_nr = mem->start_phys_index;
if (!present_section_nr(phys_section_nr))
goto out;
@@ -296,7 +304,8 @@ static ssize_t show_phys_device(struct s
return sprintf(buf, "%d\n", mem->phys_device);
}
-static SYSDEV_ATTR(phys_index, 0444, show_mem_phys_index, NULL);
+static SYSDEV_ATTR(phys_index, 0444, show_mem_start_phys_index, NULL);
+static SYSDEV_ATTR(end_phys_index, 0444, show_mem_end_phys_index, NULL);
static SYSDEV_ATTR(state, 0644, show_mem_state, store_mem_state);
static SYSDEV_ATTR(phys_device, 0444, show_phys_device, NULL);
static SYSDEV_ATTR(removable, 0444, show_mem_removable, NULL);
@@ -476,16 +485,18 @@ static int add_memory_block(int nid, str
if (!mem)
return -ENOMEM;
- mem->phys_index = __section_nr(section);
+ mem->start_phys_index = __section_nr(section);
mem->state = state;
mutex_init(&mem->state_mutex);
- start_pfn = section_nr_to_pfn(mem->phys_index);
+ start_pfn = section_nr_to_pfn(mem->start_phys_index);
mem->phys_device = arch_get_memory_phys_device(start_pfn);
ret = register_memory(mem, section);
if (!ret)
ret = mem_create_simple_file(mem, phys_index);
if (!ret)
+ ret = mem_create_simple_file(mem, end_phys_index);
+ if (!ret)
ret = mem_create_simple_file(mem, state);
if (!ret)
ret = mem_create_simple_file(mem, phys_device);
@@ -507,6 +518,7 @@ int remove_memory_block(unsigned long no
mem = find_memory_block(section);
unregister_mem_sect_under_nodes(mem);
mem_remove_simple_file(mem, phys_index);
+ mem_remove_simple_file(mem, end_phys_index);
mem_remove_simple_file(mem, state);
mem_remove_simple_file(mem, phys_device);
mem_remove_simple_file(mem, removable);
Index: linux-2.6/include/linux/memory.h
===================================================================
--- linux-2.6.orig/include/linux/memory.h 2010-08-09 07:36:55.000000000 -0500
+++ linux-2.6/include/linux/memory.h 2010-08-09 07:44:31.000000000 -0500
@@ -21,7 +21,8 @@
#include <linux/mutex.h>
struct memory_block {
- unsigned long phys_index;
+ unsigned long start_phys_index;
+ unsigned long end_phys_index;
unsigned long state;
/*
* This serializes all state change requests. It isn't
^ permalink raw reply
* [PATCH 1/8] v5 Move the find_memory_block() routine up
From: Nathan Fontenot @ 2010-08-09 18:35 UTC (permalink / raw)
To: linux-kernel, linux-mm, linuxppc-dev
Cc: Greg KH, KAMEZAWA Hiroyuki, Dave Hansen
In-Reply-To: <4C60407C.2080608@austin.ibm.com>
Move the find_me mory_block() routine up to avoid needing a forward
declaration in subsequent patches.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
---
drivers/base/memory.c | 62 +++++++++++++++++++++++++-------------------------
1 file changed, 31 insertions(+), 31 deletions(-)
Index: linux-2.6/drivers/base/memory.c
===================================================================
--- linux-2.6.orig/drivers/base/memory.c 2010-08-09 07:36:55.000000000 -0500
+++ linux-2.6/drivers/base/memory.c 2010-08-09 07:44:21.000000000 -0500
@@ -435,6 +435,37 @@ int __weak arch_get_memory_phys_device(u
return 0;
}
+/*
+ * For now, we have a linear search to go find the appropriate
+ * memory_block corresponding to a particular phys_index. If
+ * this gets to be a real problem, we can always use a radix
+ * tree or something here.
+ *
+ * This could be made generic for all sysdev classes.
+ */
+struct memory_block *find_memory_block(struct mem_section *section)
+{
+ struct kobject *kobj;
+ struct sys_device *sysdev;
+ struct memory_block *mem;
+ char name[sizeof(MEMORY_CLASS_NAME) + 9 + 1];
+
+ /*
+ * This only works because we know that section == sysdev->id
+ * slightly redundant with sysdev_register()
+ */
+ sprintf(&name[0], "%s%d", MEMORY_CLASS_NAME, __section_nr(section));
+
+ kobj = kset_find_obj(&memory_sysdev_class.kset, name);
+ if (!kobj)
+ return NULL;
+
+ sysdev = container_of(kobj, struct sys_device, kobj);
+ mem = container_of(sysdev, struct memory_block, sysdev);
+
+ return mem;
+}
+
static int add_memory_block(int nid, struct mem_section *section,
unsigned long state, enum mem_add_context context)
{
@@ -468,37 +499,6 @@ static int add_memory_block(int nid, str
return ret;
}
-/*
- * For now, we have a linear search to go find the appropriate
- * memory_block corresponding to a particular phys_index. If
- * this gets to be a real problem, we can always use a radix
- * tree or something here.
- *
- * This could be made generic for all sysdev classes.
- */
-struct memory_block *find_memory_block(struct mem_section *section)
-{
- struct kobject *kobj;
- struct sys_device *sysdev;
- struct memory_block *mem;
- char name[sizeof(MEMORY_CLASS_NAME) + 9 + 1];
-
- /*
- * This only works because we know that section == sysdev->id
- * slightly redundant with sysdev_register()
- */
- sprintf(&name[0], "%s%d", MEMORY_CLASS_NAME, __section_nr(section));
-
- kobj = kset_find_obj(&memory_sysdev_class.kset, name);
- if (!kobj)
- return NULL;
-
- sysdev = container_of(kobj, struct sys_device, kobj);
- mem = container_of(sysdev, struct memory_block, sysdev);
-
- return mem;
-}
-
int remove_memory_block(unsigned long node_id, struct mem_section *section,
int phys_device)
{
^ permalink raw reply
* Re: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for eSDHC driver
From: Michał Mirosław @ 2010-08-09 18:24 UTC (permalink / raw)
To: Roy Zang; +Cc: linuxppc-dev, akpm, linux-mmc
In-Reply-To: <1280805072-26112-1-git-send-email-tie-fei.zang@freescale.com>
2010/8/3 Roy Zang <tie-fei.zang@freescale.com>:
[...]
> @@ -240,6 +240,8 @@ struct sdhci_host {
> =A0#define SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN =A0 =A0 =A0 =A0 =A0 =A0 =A0(=
1<<25)
> =A0/* Controller cannot support End Attribute in NOP ADMA descriptor */
> =A0#define SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC =A0 =A0 =A0 =A0 =A0 =A0 =A0(=
1<<26)
> +/* Controller uses Auto CMD12 command to stop the transfer */
> +#define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 =A0 =A0 =A0 =A0 =A0 =A0 (1<<2=
7)
>
> =A0 =A0 =A0 =A0int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 irq; =A0 =A0 =
=A0 =A0 =A0 =A0/* Device IRQ */
> =A0 =A0 =A0 =A0void __iomem * =A0 =A0 =A0 =A0 =A0ioaddr; =A0 =A0 =A0 =A0 =
/* Mapped address */
Just a cosmetic hint: I suggest SDHCI_QUIRK_MULTIBLOCK_READ_AUTO_CMD12
or something for the quirk name, because ACMD12 part might be confused
with MMC/SD App CMD 12 (CMD55+CMD12 combo) if/whenever that gets used.
Best Regards,
Micha=B3 Miros=B3aw
^ permalink raw reply
* [PATCH 0/8] v5 De-couple sysfs memory directories from memory sections
From: Nathan Fontenot @ 2010-08-09 17:53 UTC (permalink / raw)
To: linux-kernel, linux-mm, linuxppc-dev
Cc: Greg KH, KAMEZAWA Hiroyuki, Dave Hansen
This set of patches de-couples the idea that there is a single
directory in sysfs for each memory section. The intent of the
patches is to reduce the number of sysfs directories created to
resolve a boot-time performance issue. On very large systems
boot time are getting very long (as seen on powerpc hardware)
due to the enormous number of sysfs directories being created.
On a system with 1 TB of memory we create ~63,000 directories.
For even larger systems boot times are being measured in hours.
This set of patches allows for each directory created in sysfs
to cover more than one memory section. The default behavior for
sysfs directory creation is the same, in that each directory
represents a single memory section. A new file 'end_phys_index'
in each directory contains the physical_id of the last memory
section covered by the directory so that users can easily
determine the memory section range of a directory.
Updates for version 5 of the patchset include the following:
Patch 4/8 Add mutex for add/remove of memory blocks
- Define the mutex using DEFINE_MUTEX macro.
Patch 8/8 Update memory-hotplug documentation
- Add information concerning memory holes in phys_index..end_phys_index.
Thanks,
Nathan Fontenot
^ permalink raw reply
* Re: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for eSDHC driver
From: Anton Vorontsov @ 2010-08-09 17:43 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-mmc, linuxppc-dev, akpm
In-Reply-To: <AANLkTinJKO3-iXOXuL7CMWCj5qMMHyMrtnadwPpqTeBu@mail.gmail.com>
On Wed, Aug 04, 2010 at 07:02:56PM -0600, Grant Likely wrote:
> On Mon, Aug 2, 2010 at 9:11 PM, Roy Zang <tie-fei.zang@freescale.com> wrote:
> > From: Jerry Huang <Chang-Ming.Huang@freescale.com>
> >
> > Add auto CMD12 command support for eSDHC driver.
> > This is needed by P4080 and P1022 for block read/write.
> > Manual asynchronous CMD12 abort operation causes protocol violations on
> > these silicons.
> >
> > Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> > Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> > ---
> > drivers/mmc/host/sdhci-of-core.c | 4 ++++
> > drivers/mmc/host/sdhci.c | 14 ++++++++++++--
> > drivers/mmc/host/sdhci.h | 2 ++
> > 3 files changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > index c6d1bd8..a92566e 100644
> > --- a/drivers/mmc/host/sdhci.c
> > +++ b/drivers/mmc/host/sdhci.c
> > @@ -817,8 +817,12 @@ static void sdhci_set_transfer_mode(struct sdhci_host *host,
> > WARN_ON(!host->data);
> >
> > mode = SDHCI_TRNS_BLK_CNT_EN;
> > - if (data->blocks > 1)
> > - mode |= SDHCI_TRNS_MULTI;
> > + if (data->blocks > 1) {
> > + if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
> > + mode |= SDHCI_TRNS_MULTI | SDHCI_TRNS_ACMD12;
> > + else
> > + mode |= SDHCI_TRNS_MULTI;
>
> nit:
> + mode |= SDHCI_TRNS_MULTI;
> + if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
> + mode |= SDHCI_TRNS_ACMD12;
>
> Clearer, no?
Much clearer. I would prefer the nit incorporated.
Another nit:
> @@ -154,6 +154,10 @@ static int __devinit sdhci_of_probe(struct of_device *ofdev,
> host->ops = &sdhci_of_data->ops;
> }
>
> + if (of_get_property(np, "sdhci,auto-cmd12", NULL))
> + host->quirks |= SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;
> +
> +
^^ No need for the two empty lines.
> if (of_get_property(np, "sdhci,1-bit-only", NULL))
Though, technically the patch looks OK, feel free to add my
Acked-by: Anton Vorontsov <cbouatmailru@gmail.com>
on the next resend (if any).
Thanks Roy!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 2/3 v2] dts: Add sdhci,auto-cmd12 field for p4080 device tree
From: Anton Vorontsov @ 2010-08-09 17:36 UTC (permalink / raw)
To: Roy Zang; +Cc: linuxppc-dev, akpm, linux-mmc
In-Reply-To: <1280805072-26112-2-git-send-email-tie-fei.zang@freescale.com>
On Tue, Aug 03, 2010 at 11:11:11AM +0800, Roy Zang wrote:
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
> Documentation/powerpc/dts-bindings/fsl/esdhc.txt | 2 ++
> arch/powerpc/boot/dts/p4080ds.dts | 1 +
> 2 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
> index 8a00407..64bcb8b 100644
> --- a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
> +++ b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
> @@ -14,6 +14,8 @@ Required properties:
> reports inverted write-protect state;
> - sdhci,1-bit-only : (optional) specifies that a controller can
> only handle 1-bit data transfers.
> + - sdhci,auto-cmd12: (optional) specifies that a controller can
> + only handle auto CMD12.
Acked-by: Anton Vorontsov <cbouatmailru@gmail.com>
> Example:
>
> diff --git a/arch/powerpc/boot/dts/p4080ds.dts b/arch/powerpc/boot/dts/p4080ds.dts
> index 6b29eab..efa0091 100644
> --- a/arch/powerpc/boot/dts/p4080ds.dts
> +++ b/arch/powerpc/boot/dts/p4080ds.dts
> @@ -280,6 +280,7 @@
> reg = <0x114000 0x1000>;
> interrupts = <48 2>;
> interrupt-parent = <&mpic>;
> + sdhci,auto-cmd12;
> };
>
> i2c@118000 {
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 3/3 v2] dts: Add ESDHC weird voltage bits workaround
From: Anton Vorontsov @ 2010-08-09 17:33 UTC (permalink / raw)
To: Roy Zang; +Cc: linuxppc-dev, akpm, linux-mmc
In-Reply-To: <1280805072-26112-3-git-send-email-tie-fei.zang@freescale.com>
On Tue, Aug 03, 2010 at 11:11:12AM +0800, Roy Zang wrote:
> P4080 ESDHC controller does not support 1.8V and 3.0V voltage. but the
> host controller capabilities register wrongly set the bits.
> This patch adds the workaround to correct the weird voltage setting bits.
> Only 3.3V voltage is supported for P4080 ESDHC controller.
>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Acked-by: Anton Vorontsov <cbouatmailru@gmail.com>
Btw, where is implementation for the voltage-ranges handling?
> ---
> arch/powerpc/boot/dts/p4080ds.dts | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/p4080ds.dts b/arch/powerpc/boot/dts/p4080ds.dts
> index efa0091..2f0de24 100644
> --- a/arch/powerpc/boot/dts/p4080ds.dts
> +++ b/arch/powerpc/boot/dts/p4080ds.dts
> @@ -280,6 +280,7 @@
> reg = <0x114000 0x1000>;
> interrupts = <48 2>;
> interrupt-parent = <&mpic>;
> + voltage-ranges = <3300 3300>;
> sdhci,auto-cmd12;
> };
>
> --
> 1.5.6.5
^ permalink raw reply
* Re: mpc870: hctosys.c unable to open rtc device rtc0
From: Scott Wood @ 2010-08-09 17:29 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev
In-Reply-To: <AANLkTinjLBPG9YfpoDnSoKeGvUO2OEjdTXrYLTZ9c8LB@mail.gmail.com>
On Sun, 8 Aug 2010 23:37:00 -0700
Shawn Jin <shawnxjin@gmail.com> wrote:
> Reading the fsl i2c bindings in the documentation, I found an example
> as follows.
> 27 i2c@860 {
> 28 compatible = "fsl,mpc823-i2c",
> 29 "fsl,cpm1-i2c";
> 30 reg = <0x860 0x20 0x3c80 0x30>;
> 31 interrupts = <16>;
> 32 interrupt-parent = <&CPM_PIC>;
> 33 fsl,cpm-command = <0x10>;
> 34 #address-cells = <1>;
> 35 #size-cells = <0>;
> 36
> 37 rtc@68 {
> 38 compatible = "dallas,ds1307";
> 39 reg = <0x68>;
> 40 };
> 41 };
> 42
>
> In the above example the rtc was explicitly declared as a subnode of
> the i2c node. Is this the way to connect (or bind) a RTC to the I2C
> driver?
Yes.
> What is the reg (0x68) under rtc node?
It's the 7-bit I2C address (without the low-order direction bit).
> I set breakpoint at ds1037_probe() and was hoping that it might be hit
> during the driver registration. But it didn't. Would the
> ds1037_probe() be called during when the ds1037_driver was registered
> as an I2C driver?
The probe function is called only if the device is declared. There is
no autodetection.
-Scott
^ permalink raw reply
* Re: 2.6.35-stable/ppc64/p7: suspicious rcu_dereference_check() usage detected during 2.6.35-stable boot
From: Paul E. McKenney @ 2010-08-09 16:12 UTC (permalink / raw)
To: Subrata Modak
Cc: sachinp, Peter Zijlstra, Li Zefan, linux-kernel, Linuxppc-dev,
DIVYA PRAKASH
In-Reply-To: <1280739132.15317.9.camel@subratamodak.linux.ibm.com>
On Mon, Aug 02, 2010 at 02:22:12PM +0530, Subrata Modak wrote:
> Hi,
>
> The following suspicious rcu_dereference_check() usage is detected
> during 2.6.35-stable boot on my ppc64/p7 machine:
>
> ==================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> kernel/sched.c:616 invoked rcu_dereference_check() without protection!
> other info that might help us debug this:
>
> rcu_scheduler_active = 1, debug_locks = 0
> 1 lock held by swapper/1:
> #0: (&rq->lock){-.....}, at: [<c0000000007ca2f8>] .init_idle+0x78/0x4a8
> stack backtrace:
> Call Trace:
> [c000000f392bf990] [c000000000014f04] .show_stack+0xb0/0x1a0 (unreliable)
> [c000000f392bfa50] [c0000000007c87b4] .dump_stack+0x28/0x3c
> [c000000f392bfad0] [c000000000103e1c] .lockdep_rcu_dereference+0xbc/0xe4
> [c000000f392bfb70] [c0000000007ca434] .init_idle+0x1b4/0x4a8
> [c000000f392bfc30] [c0000000007cad04] .fork_idle+0xa4/0xd0
> [c000000f392bfe30] [c000000000aefaac] .smp_prepare_cpus+0x23c/0x2f4
> [c000000f392bfed0] [c000000000ae1424] .kernel_init+0xec/0x32c
> [c000000f392bff90] [c000000000033f40] .kernel_thread+0x54/0x70
> ==================================================
>
> Please note that this was reported earlier on 2.6.34-rc6:
> http://marc.info/?l=linux-kernel&m=127313031922395&w=2,
> The issue was fixed with:
> commit 1ce7e4ff24fe338438bc7837e02780f202bf202b
> Author: Li Zefan <lizf@cn.fujitsu.com>
> Date: Fri Apr 23 10:35:52 2010 +0800
> cgroup: Check task_lock in task_subsys_state()
>
> According to:
> http://lkml.org/lkml/2010/7/1/883,
> commit dc61b1d65e353d638b2445f71fb8e5b5630f2415
> Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date: Tue Jun 8 11:40:42 2010 +0200
> sched: Fix PROVE_RCU vs cpu_cgroup
> should have fixed this. But this is reproducible on 2.6.35-stable.
>
> Please also see the config file attached.
Hello, Subrata,
Thank you for locating this one! This looks like the same issue that
Ilia Mirkin located. Please see below for my analysis -- no fix yet,
as I need confirmation from cgroups experts. I can easily create a
patch that suppresses the warning, but I don't yet know whether this is
the right thing to do.
Thanx, Paul
------------------------------------------------------------------------
On Thu, Aug 05, 2010 at 01:31:10PM -0400, Ilia Mirkin wrote:
> On Thu, Jul 1, 2010 at 6:18 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> > On Thu, Jul 01, 2010 at 08:21:43AM -0400, Miles Lane wrote:
> >> [ INFO: suspicious rcu_dereference_check() usage. ]
> >> ---------------------------------------------------
> >> kernel/sched.c:616 invoked rcu_dereference_check() without protection!
> >>
> >> other info that might help us debug this:
> >>
> >> rcu_scheduler_active = 1, debug_locks = 1
> >> 3 locks held by swapper/1:
> >> #0: (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff81042914>]
> >> cpu_maps_update_begin+0x12/0x14
> >> #1: (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff8104294f>]
> >> cpu_hotplug_begin+0x27/0x4e
> >> #2: (&rq->lock){-.-...}, at: [<ffffffff812f8502>] init_idle+0x2b/0x114
> >
> > Hello, Miles!
> >
> > I believe that this one is fixed by commit dc61b1d6 in -tip.
>
> Hi Paul,
>
> Looks like that commit made it into 2.6.35:
>
> git tag -l --contains dc61b1d65e353d638b2445f71fb8e5b5630f2415 v2.6.35*
> v2.6.35
> v2.6.35-rc4
> v2.6.35-rc5
> v2.6.35-rc6
>
> However I still get:
>
> [ 0.051203] CPU0: AMD QEMU Virtual CPU version 0.12.4 stepping 03
> [ 0.052999] lockdep: fixing up alternatives.
> [ 0.054105]
> [ 0.054106] ===================================================
> [ 0.054999] [ INFO: suspicious rcu_dereference_check() usage. ]
> [ 0.054999] ---------------------------------------------------
> [ 0.054999] kernel/sched.c:616 invoked rcu_dereference_check()
> without protection
> !
> [ 0.054999]
> [ 0.054999] other info that might help us debug this:
> [ 0.054999]
> [ 0.054999]
> [ 0.054999] rcu_scheduler_active = 1, debug_locks = 1
> [ 0.054999] 3 locks held by swapper/1:
> [ 0.054999] #0: (cpu_add_remove_lock){+.+.+.}, at:
> [<ffffffff814be933>] cpu_up+
> 0x42/0x6a
> [ 0.054999] #1: (cpu_hotplug.lock){+.+.+.}, at:
> [<ffffffff810400d8>] cpu_hotplu
> g_begin+0x2a/0x51
> [ 0.054999] #2: (&rq->lock){-.-...}, at: [<ffffffff814be2f7>]
> init_idle+0x2f/0x
> 113
> [ 0.054999]
> [ 0.054999] stack backtrace:
> [ 0.054999] Pid: 1, comm: swapper Not tainted 2.6.35 #1
> [ 0.054999] Call Trace:
> [ 0.054999] [<ffffffff81068054>] lockdep_rcu_dereference+0x9b/0xa3
> [ 0.054999] [<ffffffff810325c3>] task_group+0x7b/0x8a
> [ 0.054999] [<ffffffff810325e5>] set_task_rq+0x13/0x40
> [ 0.054999] [<ffffffff814be39a>] init_idle+0xd2/0x113
> [ 0.054999] [<ffffffff814be78a>] fork_idle+0xb8/0xc7
> [ 0.054999] [<ffffffff81068717>] ? mark_held_locks+0x4d/0x6b
> [ 0.054999] [<ffffffff814bcebd>] do_fork_idle+0x17/0x2b
> [ 0.054999] [<ffffffff814bc89b>] native_cpu_up+0x1c1/0x724
> [ 0.054999] [<ffffffff814bcea6>] ? do_fork_idle+0x0/0x2b
> [ 0.054999] [<ffffffff814be876>] _cpu_up+0xac/0x127
> [ 0.054999] [<ffffffff814be946>] cpu_up+0x55/0x6a
> [ 0.054999] [<ffffffff81ab562a>] kernel_init+0xe1/0x1ff
> [ 0.054999] [<ffffffff81003854>] kernel_thread_helper+0x4/0x10
> [ 0.054999] [<ffffffff814c353c>] ? restore_args+0x0/0x30
> [ 0.054999] [<ffffffff81ab5549>] ? kernel_init+0x0/0x1ff
> [ 0.054999] [<ffffffff81003850>] ? kernel_thread_helper+0x0/0x10
> [ 0.056074] Booting Node 0, Processors #1lockdep: fixing up alternatives.
> [ 0.130045] #2lockdep: fixing up alternatives.
> [ 0.203089] #3 Ok.
> [ 0.275286] Brought up 4 CPUs
> [ 0.276005] Total of 4 processors activated (16017.17 BogoMIPS).
This does look like a new one, thank you for reporting it!
Here is my analysis, which should at least provide some humor value to
those who understand the code better than I do. ;-)
So the corresponding rcu_dereference_check() is in
task_subsys_state_check(), and is fetching the cpu_cgroup_subsys_id
element of the newly created task's task->cgroups->subsys[] array.
The "git grep" command finds only three uses of cpu_cgroup_subsys_id,
but no definition.
Now, fork_idle() invokes copy_process(), which invokes cgroup_fork(),
which sets the child process's ->cgroups pointer to that of the parent,
also invoking get_css_set(), which increments the corresponding reference
count, doing both operations under task_lock() protection (->alloc_lock).
Because fork_idle() does not specify any of CLONE_NEWNS, CLONE_NEWUTS,
CLONE_NEWIPC, CLONE_NEWPID, or CLONE_NEWNET, copy_namespaces() should
not create a new namespace, and so there should be no ns_cgroup_clone().
We should thus retain the parent's ->cgroups pointer. And copy_process()
installs the new task in the various lists, so that the task is externally
accessible upon return.
After a non-error return from copy_process(), fork_init() invokes
init_idle_pid(), which does not appear to affect the task's cgroup
state. Next fork_init() invokes init_idle(), which in turn invokes
__set_task_cpu(), which invokes set_task_rq(), which calls task_group()
several times, which calls task_subsys_state_check(), which calls the
rcu_dereference_check() that complained above.
However, the result returns by rcu_dereference_check() is stored into
the task structure:
p->se.cfs_rq = task_group(p)->cfs_rq[cpu];
p->se.parent = task_group(p)->se[cpu];
This means that the corresponding structure must have been tied down with
a reference count or some such. If such a reference has been taken, then
this complaint is a false positive, and could be suppressed by putting
rcu_read_lock() and rcu_read_unlock() around the call to init_idle()
from fork_idle(). However, although, reference to the enclosing ->cgroups
struct css_set is held, it is not clear to me that this reference applies
to the structures pointed to by the ->subsys[] array, especially given
that the cgroup_subsys_state structures referenced by this array have
their own reference count, which does not appear to me to be acquired
by this code path.
Or are the cgroup_subsys_state structures referenced by idle tasks
never freed or some such?
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 6/9] v4 Update the find_memory_block declaration
From: Nathan Fontenot @ 2010-08-09 13:56 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: linux-mm, Dave Hansen, Greg KH, linux-kernel, linuxppc-dev
In-Reply-To: <20100805135944.97ecbaa4.kamezawa.hiroyu@jp.fujitsu.com>
On 08/04/2010 11:59 PM, KAMEZAWA Hiroyuki wrote:
> On Tue, 03 Aug 2010 08:41:45 -0500
> Nathan Fontenot <nfont@austin.ibm.com> wrote:
>
>> Update the find_memory_block declaration to to take a struct mem_section *
>> so that it matches the definition.
>>
>> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
>
> Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>
> Hmm...my mmotm-0727 has this definition in memory.h...
>
> extern struct memory_block *find_memory_block(struct mem_section *);
>
> What patch makes it unsigned long ?
>
I was basing the patches on the latest mainline tree. Looks like can drop
this patch in the next version of the patchset.
-Nathan
^ permalink raw reply
* Re: [PATCH 4/9] v4 Add mutex for add/remove of memory blocks
From: Nathan Fontenot @ 2010-08-09 13:55 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: linux-mm, Dave Hansen, Greg KH, linux-kernel, linuxppc-dev
In-Reply-To: <20100805135314.7229d07c.kamezawa.hiroyu@jp.fujitsu.com>
On 08/04/2010 11:53 PM, KAMEZAWA Hiroyuki wrote:
> On Tue, 03 Aug 2010 08:39:50 -0500
> Nathan Fontenot <nfont@austin.ibm.com> wrote:
>
>> Add a new mutex for use in adding and removing of memory blocks. This
>> is needed to avoid any race conditions in which the same memory block could
>> be added and removed at the same time.
>>
>> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
>
> Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>
> But a nitpick (see below)
>
>> ---
>> drivers/base/memory.c | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> Index: linux-2.6/drivers/base/memory.c
>> ===================================================================
>> --- linux-2.6.orig/drivers/base/memory.c 2010-08-02 13:35:00.000000000 -0500
>> +++ linux-2.6/drivers/base/memory.c 2010-08-02 13:45:34.000000000 -0500
>> @@ -27,6 +27,8 @@
>> #include <asm/atomic.h>
>> #include <asm/uaccess.h>
>>
>> +static struct mutex mem_sysfs_mutex;
>> +
>
> For static symbol of mutex, we usually do
> static DEFINE_MUTEX(mem_sysfs_mutex);
>
> Then, extra calls of mutex_init() is not required.
>
ok, fixed in the next version of the patches.
-Nathan
^ permalink raw reply
* Re: [PATCH] powerpc/fsl-pci: Fix MSI support on 83xx platforms
From: Ilya Yanok @ 2010-08-09 12:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, wd
In-Reply-To: <1280995347-6550-1-git-send-email-galak@kernel.crashing.org>
Hi Kumar,
05.08.2010 12:02, Kumar Gala wrote:
> The following commit broke 83xx because it assumed the 83xx platforms
> exposed the "IMMR" address in BAR0 like the 85xx/86xx/QoriQ devices do:
>
> commit 3da34aae03d498ee62f75aa7467de93cce3030fd
> Author: Kumar Gala<galak@kernel.crashing.org>
> Date: Tue May 12 15:51:56 2009 -0500
>
> powerpc/fsl: Support unique MSI addresses per PCIe Root Complex
>
> However that is not true, so we have to search through the inbound
> window settings on 83xx to find which one matches the IMMR address to
> determine its PCI address.
As I've already told you my testing on the MPC8308RDB board was
successful. As for 85xx boards, Wolfgang told me that DENX doesn't have
any 85xx boards that support MSI at the moment, so I can't do complete
testing. I'm sorry. I've tested that TQM8560 board is able to boot and
PCI is working as expected though (with your patch applied). I fear I
can't do anything else here.
Thanks.
Regards, Ilya.
^ permalink raw reply
* Re: [PATCH] powerpc/fsl-pci: Fix MSI support on 83xx platforms
From: Ilya Yanok @ 2010-08-09 12:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, wd
In-Reply-To: <1280995347-6550-1-git-send-email-galak@kernel.crashing.org>
Hi Kumar,
05.08.2010 12:02, Kumar Gala wrote:
> The following commit broke 83xx because it assumed the 83xx platforms
> exposed the "IMMR" address in BAR0 like the 85xx/86xx/QoriQ devices do:
>
> commit 3da34aae03d498ee62f75aa7467de93cce3030fd
> Author: Kumar Gala<galak@kernel.crashing.org>
> Date: Tue May 12 15:51:56 2009 -0500
>
> powerpc/fsl: Support unique MSI addresses per PCIe Root Complex
>
> However that is not true, so we have to search through the inbound
> window settings on 83xx to find which one matches the IMMR address to
> determine its PCI address.
As I've already told you my testing on the MPC8308RDB board was
successful. As for 85xx boards, Wolfgang told me that DENX doesn't have
any 85xx boards that support MSI at the moment, so I can't do complete
testing. I'm sorry. I've tested that TQM8560 boards is able to boot and
PCI is working as expected though (with your patch applied). I fear I
can't do anything else here.
Thanks.
Regards, Ilya.
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git next branch
From: Benjamin Herrenschmidt @ 2010-08-09 11:25 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc-dev list, Andrew Morton, Linus Torvalds,
Linux Kernel list
In-Reply-To: <AANLkTin0dkWPkU3C47HjnxZ2e_ujCUfNUp4xm_xSX3yK@mail.gmail.com>
On Sun, 2010-08-08 at 23:18 -0600, Grant Likely wrote:
> And how is anyone else to make it into the kernel statistics top
> contributors by lines changed list with stuff like this going in? :-)
lindent ? :-)
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH 1/3][MTD] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Zang Roy-R61911 @ 2010-08-09 7:33 UTC (permalink / raw)
To: Zang Roy-R61911, linux-mtd
Cc: Lan Chunhe-B25806, linuxppc-dev, akpm, Gala Kumar-B11780
In-Reply-To: <1281063096-26598-1-git-send-email-tie-fei.zang@freescale.com>
=20
> -----Original Message-----
> From: Zang Roy-R61911=20
> Sent: Friday, August 06, 2010 10:52 AM
> To: linux-mtd@lists.infradead.org
> Cc: linuxppc-dev@ozlabs.org; akpm@linux-foundation.org; Gala=20
> Kumar-B11780; Lan Chunhe-B25806
> Subject: [PATCH 1/3][MTD] P4080/eLBC: Make Freescale elbc=20
> interrupt common to elbc devices
>=20
> From: Lan Chunhe-B25806 <b25806@freescale.com>
>=20
> Move Freescale elbc interrupt from nand dirver to elbc driver.
> Then all elbc devices can use the interrupt instead of ONLY nand.
>=20
> Signed-off-by: Lan Chunhe-B25806 <b25806@freescale.com>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
> send the patch to linux-mtd@lists.infradead.org
> it has been posted to linuxppc-dev@ozlabs.org and do not get=20
> any comment.
Any comment about this serial patches?
If none, I'd ask Andrew to merge to his mm tree.
Thanks.
Roy
^ permalink raw reply
* RE: Review Request: New proposal for device tree clock binding.
From: Li Yang-R58472 @ 2010-08-09 7:05 UTC (permalink / raw)
To: Grant Likely; +Cc: devicetree-discuss, linuxppc-dev, Jeremy Kerr
In-Reply-To: <AANLkTi=3MQBSd_phbSZnRA-wFB7cfa4U_PKND+BgZVhd@mail.gmail.com>
>>><tt>*-clock</tt> is named for the signal name for the ''clock input''
>>>of the device. it should describe the function of the signal for that
>>>device, rather than the name of the system-wide clock line. For
>>>example, a UART with two clocks - one for baud-rate clocking, and the
>>>other for register clocking - may have clock input properties named
>>>"baud-clock" and "register-clock". =A0The property value is a tuple
>>>containing the phandle to the clock provider and the name of the =
clock
>output signal.
>>>
>>>For example:
>>>
>>> =A0 =A0uart {
>>> =A0 =A0 =A0 =A0baud-clock =3D <&osc>, "ckil";
>>> =A0 =A0 =A0 =A0register-clock =3D <&ref>, "bus";
>>> =A0 =A0};
>>>
>>>
>>>This represents a device with two clock inputs, named "baud" and
>>>"register". The baud clock is connected to the "ckil" output of the
>"osc"
>>>device, and the register clock is connected to the "bus" output of =
the
>>>"ref" device.
>>
>>
>> Instead of having two items to identify a clock, I would suggest to =
have
>a node for each clock. =A0So that clock can be referenced by one
>handle. =A0Also we can have clock specific information defined in the =
clock
>node. =A0Here is the example I am planning to use on 85xx PMC.
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0power@e0070{
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D =
"fsl,mpc8548-pmc",
>> "fsl,p2020-pmc";
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0xe0070 =
0x20>;
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0etsec1_clk: =
soc-clk@24{
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0fsl,pmcdr-mask =3D <0x00000080>;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0etsec2_clk: =
soc-clk@25{
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0fsl,pmcdr-mask =3D <0x00000040>;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0etsec3_clk: =
soc-clk@26{
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0fsl,pmcdr-mask =3D <0x00000020>;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enet0: ethernet@24000 {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0......
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0master-clock =3D =
<&etsec1_clk>;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0......
>>
>>
>> What do you think?
Quoting your reply:
> I've avoided requiring clock nodes to have a separate sub node for
> each output because it is more verbose and it prevents clock providers
> from having child nodes for other purposes. Are you concerned that
I don't see why there should be child nodes for other purposes under =
clock node.
> having the <phandle>+output name pair will be difficult to manage?
That's part of my concern. But my main concern is the inability of =
describing the properties of each clock in the device tree. The clock =
stuff is much SoC related, which means it could be variable among chips =
even in a same family. Having clock properties defined in device tree =
will make it easier to have an abstracted driver to handle clock =
operations. That's why device trees are used in the first place, right?
- Leo
^ permalink raw reply
* Re: Review Request: New proposal for device tree clock binding.
From: Grant Likely @ 2010-08-09 7:12 UTC (permalink / raw)
To: Li Yang-R58472; +Cc: devicetree-discuss, linuxppc-dev, Jeremy Kerr
In-Reply-To: <F9BD3E0A8083BE4ABAA94D7EDD7E3F6310925F@zch01exm26.fsl.freescale.net>
On Mon, Aug 9, 2010 at 1:05 AM, Li Yang-R58472 <r58472@freescale.com> wrote=
:
>>>><tt>*-clock</tt> is named for the signal name for the ''clock input''
>>>>of the device. it should describe the function of the signal for that
>>>>device, rather than the name of the system-wide clock line. For
>>>>example, a UART with two clocks - one for baud-rate clocking, and the
>>>>other for register clocking - may have clock input properties named
>>>>"baud-clock" and "register-clock". =A0The property value is a tuple
>>>>containing the phandle to the clock provider and the name of the clock
>>output signal.
>>>>
>>>>For example:
>>>>
>>>> =A0 =A0uart {
>>>> =A0 =A0 =A0 =A0baud-clock =3D <&osc>, "ckil";
>>>> =A0 =A0 =A0 =A0register-clock =3D <&ref>, "bus";
>>>> =A0 =A0};
>>>>
>>>>
>>>>This represents a device with two clock inputs, named "baud" and
>>>>"register". The baud clock is connected to the "ckil" output of the
>>"osc"
>>>>device, and the register clock is connected to the "bus" output of the
>>>>"ref" device.
>>>
>>>
>>> Instead of having two items to identify a clock, I would suggest to hav=
e
>>a node for each clock. =A0So that clock can be referenced by one
>>handle. =A0Also we can have clock specific information defined in the clo=
ck
>>node. =A0Here is the example I am planning to use on 85xx PMC.
>>>
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0power@e0070{
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "fsl,mpc8=
548-pmc",
>>> "fsl,p2020-pmc";
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0xe0070 0x20>;
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0etsec1_clk: soc-clk@24{
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fsl,pmcd=
r-mask =3D <0x00000080>;
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0etsec2_clk: soc-clk@25{
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fsl,pmcd=
r-mask =3D <0x00000040>;
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0etsec3_clk: soc-clk@26{
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fsl,pmcd=
r-mask =3D <0x00000020>;
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enet0: ethernet@24000 {
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0......
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0master-clock =3D <&etsec=
1_clk>;
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0......
>>>
>>>
>>> What do you think?
>
> Quoting your reply:
>
>> I've avoided requiring clock nodes to have a separate sub node for
>> each output because it is more verbose and it prevents clock providers
>> from having child nodes for other purposes. =A0Are you concerned that
>
> I don't see why there should be child nodes for other purposes under cloc=
k node.
>
>> having the <phandle>+output name pair will be difficult to manage?
>
> That's part of my concern.
I was concerned about this too until I found precedence for doing the
exact same thing in the pci binding (and ePAPR). Mixing phandle and a
string in this way doesn't bother me anymore.
> =A0But my main concern is the inability of describing the properties of e=
ach clock in the device tree. =A0The clock stuff is much SoC related, which=
means it could be variable among chips even in a same family. =A0Having cl=
ock properties defined in device tree will make it easier to have an abstra=
cted driver to handle clock operations. =A0That's why device trees are used=
in the first place, right?
You can do whatever you like for your specific clock source driver.
All the clock binding provides is a connection from a clock consumer
node to a specific named output from a clock provider node. You can
add whatever properties (or subnodes) you need for the hardware you
are writing a binding for. This binding doesn't prevent you from
doing anything.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* mpc870: hctosys.c unable to open rtc device rtc0
From: Shawn Jin @ 2010-08-09 6:37 UTC (permalink / raw)
To: ppcdev
A DS1339 RTC is connected to the I2C bus (i2c-cpm in mpc870). The
dmesg below shows that the ds1037 driver was registered. But the
hctosys.c was not able to open the rtc device rtc0. The rtc doesn't
seem to be connected with I2C driver properly.
i2c-core: driver [rtc-ds1307] registered
i2c /dev entries driver
i2c-core: driver [dev_driver] registered
fsl-i2c-cpm fa200860.i2c: cpm_i2c_setup()
alloc irq_desc for 21 on node 0
alloc kstat_irqs on node 0
irq: irq 16 on host /soc@fa200000/cpm@9c0/interrupt-controller@930
mapped to virtual irq 21
fsl-i2c-cpm fa200860.i2c: i2c_ram 0xfddfbc80, i2c_addr 0x1c80, freq 60000
fsl-i2c-cpm fa200860.i2c: tbase 0x0340, rbase 0x0360
i2c i2c-0: adapter [i2c-cpm] registered
i2c-dev: adapter [i2c-cpm] registered as minor 0
fsl-i2c-cpm fa200860.i2c: hw routines for i2c-cpm registered.
i2c-core: driver [lm75] registered
TCP cubic registered
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
My I2C settings in the dts is as follows, same as the mpc885ads.
i2c@860 {
compatible = "fsl,mpc885-i2c",
"fsl,cpm1-i2c";
reg = <0x860 0x20 0x3c80 0x30>;
interrupts = <16>;
interrupt-parent = <&CPM_PIC>;
fsl,cpm-command = <0x10>;
#address-cells = <1>;
#size-cells = <0>;
};
Reading the fsl i2c bindings in the documentation, I found an example
as follows.
27 i2c@860 {
28 compatible = "fsl,mpc823-i2c",
29 "fsl,cpm1-i2c";
30 reg = <0x860 0x20 0x3c80 0x30>;
31 interrupts = <16>;
32 interrupt-parent = <&CPM_PIC>;
33 fsl,cpm-command = <0x10>;
34 #address-cells = <1>;
35 #size-cells = <0>;
36
37 rtc@68 {
38 compatible = "dallas,ds1307";
39 reg = <0x68>;
40 };
41 };
42
In the above example the rtc was explicitly declared as a subnode of
the i2c node. Is this the way to connect (or bind) a RTC to the I2C
driver? If not how is an RTC driver (or hwmon driver) bound to the I2C
driver? What is the reg (0x68) under rtc node?
I set breakpoint at ds1037_probe() and was hoping that it might be hit
during the driver registration. But it didn't. Would the
ds1037_probe() be called during when the ds1037_driver was registered
as an I2C driver?
Thanks,
-Shawn.
^ permalink raw reply
* Re: [PATCH v4] powerpc/mpc8xxx_gpio.c: extend the driver to support mpc512x gpios
From: Grant Likely @ 2010-08-09 6:20 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev, Wolfgang Denk, Detlev Zundel
In-Reply-To: <1281333528-20694-1-git-send-email-agust@denx.de>
On Sun, Aug 8, 2010 at 11:58 PM, Anatolij Gustschin <agust@denx.de> wrote:
> The GPIO controller of MPC512x is slightly different from
> 8xxx GPIO controllers. The register interface is the same
> except the external interrupt control register. The MPC512x
> GPIO controller differentiates between four interrupt event
> types and therefore provides two interrupt control registers,
> GPICR1 and GPICR2. GPIO[0:15] interrupt event types are
> configured in GPICR1 register, GPIO[16:31] - in GPICR2 register.
>
> This patch adds MPC512x speciffic set_type() callback and
> updates config file and comments. Additionally the gpio chip
> registration function is changed to use for_each_matching_node()
> preventing multiple registration if a node claimes compatibility
> with another gpio controller type.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> ---
> v4:
> =A0- undo function merging as it was wrong
> =A0- fix commit message
Looks good, thanks. I'll pick it up after the merge window closes in
prep for 2.6.27
g.
>
> v3:
> =A0- merge mpc8xxx_add_controller() into mpc8xxx_add_gpiochips()
> =A0- do not use of_node's data field for set type hook,
> =A0 =A0use added void data pointer in the gpio chip struct
> =A0 =A0instead.
>
> v2:
> =A0- add patch description
> =A0- use match table data to set irq set_type hook as
> =A0 recommended
> =A0- refactor to use for_each_matching_node() in
> =A0 mpc8xxx_add_gpiochips() as suggested by Grant
>
> =A0arch/powerpc/platforms/Kconfig =A0 =A0 | =A0 =A07 ++-
> =A0arch/powerpc/sysdev/mpc8xxx_gpio.c | =A0 75 ++++++++++++++++++++++++++=
++++++----
> =A02 files changed, 71 insertions(+), 11 deletions(-)
>
> diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kcon=
fig
> index d1663db..471115a 100644
> --- a/arch/powerpc/platforms/Kconfig
> +++ b/arch/powerpc/platforms/Kconfig
> @@ -304,13 +304,14 @@ config OF_RTC
> =A0source "arch/powerpc/sysdev/bestcomm/Kconfig"
>
> =A0config MPC8xxx_GPIO
> - =A0 =A0 =A0 bool "MPC8xxx GPIO support"
> - =A0 =A0 =A0 depends on PPC_MPC831x || PPC_MPC834x || PPC_MPC837x || FSL=
_SOC_BOOKE || PPC_86xx
> + =A0 =A0 =A0 bool "MPC512x/MPC8xxx GPIO support"
> + =A0 =A0 =A0 depends on PPC_MPC512x || PPC_MPC831x || PPC_MPC834x || PPC=
_MPC837x || \
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0FSL_SOC_BOOKE || PPC_86xx
> =A0 =A0 =A0 =A0select GENERIC_GPIO
> =A0 =A0 =A0 =A0select ARCH_REQUIRE_GPIOLIB
> =A0 =A0 =A0 =A0help
> =A0 =A0 =A0 =A0 =A0Say Y here if you're going to use hardware that connec=
ts to the
> - =A0 =A0 =A0 =A0 MPC831x/834x/837x/8572/8610 GPIOs.
> + =A0 =A0 =A0 =A0 MPC512x/831x/834x/837x/8572/8610 GPIOs.
>
> =A0config SIMPLE_GPIO
> =A0 =A0 =A0 =A0bool "Support for simple, memory-mapped GPIO controllers"
> diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/sysdev/mpc=
8xxx_gpio.c
> index 2b69084..3649939 100644
> --- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
> +++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
> @@ -1,5 +1,5 @@
> =A0/*
> - * GPIOs on MPC8349/8572/8610 and compatible
> + * GPIOs on MPC512x/8349/8572/8610 and compatible
> =A0*
> =A0* Copyright (C) 2008 Peter Korsgaard <jacmet@sunsite.dk>
> =A0*
> @@ -26,6 +26,7 @@
> =A0#define GPIO_IER =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x0c
> =A0#define GPIO_IMR =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x10
> =A0#define GPIO_ICR =A0 =A0 =A0 =A0 =A0 =A0 =A0 0x14
> +#define GPIO_ICR2 =A0 =A0 =A0 =A0 =A0 =A0 =A00x18
>
> =A0struct mpc8xxx_gpio_chip {
> =A0 =A0 =A0 =A0struct of_mm_gpio_chip mm_gc;
> @@ -37,6 +38,7 @@ struct mpc8xxx_gpio_chip {
> =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0u32 data;
> =A0 =A0 =A0 =A0struct irq_host *irq;
> + =A0 =A0 =A0 void *of_dev_id_data;
> =A0};
>
> =A0static inline u32 mpc8xxx_gpio2mask(unsigned int gpio)
> @@ -215,6 +217,51 @@ static int mpc8xxx_irq_set_type(unsigned int virq, u=
nsigned int flow_type)
> =A0 =A0 =A0 =A0return 0;
> =A0}
>
> +static int mpc512x_irq_set_type(unsigned int virq, unsigned int flow_typ=
e)
> +{
> + =A0 =A0 =A0 struct mpc8xxx_gpio_chip *mpc8xxx_gc =3D get_irq_chip_data(=
virq);
> + =A0 =A0 =A0 struct of_mm_gpio_chip *mm =3D &mpc8xxx_gc->mm_gc;
> + =A0 =A0 =A0 unsigned long gpio =3D virq_to_hw(virq);
> + =A0 =A0 =A0 void __iomem *reg;
> + =A0 =A0 =A0 unsigned int shift;
> + =A0 =A0 =A0 unsigned long flags;
> +
> + =A0 =A0 =A0 if (gpio < 16) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D mm->regs + GPIO_ICR;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 shift =3D (15 - gpio) * 2;
> + =A0 =A0 =A0 } else {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D mm->regs + GPIO_ICR2;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 shift =3D (15 - (gpio % 16)) * 2;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 switch (flow_type) {
> + =A0 =A0 =A0 case IRQ_TYPE_EDGE_FALLING:
> + =A0 =A0 =A0 case IRQ_TYPE_LEVEL_LOW:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_lock_irqsave(&mpc8xxx_gc->lock, flags)=
;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 clrsetbits_be32(reg, 3 << shift, 2 << shift=
);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_unlock_irqrestore(&mpc8xxx_gc->lock, f=
lags);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> +
> + =A0 =A0 =A0 case IRQ_TYPE_EDGE_RISING:
> + =A0 =A0 =A0 case IRQ_TYPE_LEVEL_HIGH:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_lock_irqsave(&mpc8xxx_gc->lock, flags)=
;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 clrsetbits_be32(reg, 3 << shift, 1 << shift=
);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_unlock_irqrestore(&mpc8xxx_gc->lock, f=
lags);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> +
> + =A0 =A0 =A0 case IRQ_TYPE_EDGE_BOTH:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_lock_irqsave(&mpc8xxx_gc->lock, flags)=
;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 clrbits32(reg, 3 << shift);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 spin_unlock_irqrestore(&mpc8xxx_gc->lock, f=
lags);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
> +
> + =A0 =A0 =A0 default:
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 return 0;
> +}
> +
> =A0static struct irq_chip mpc8xxx_irq_chip =3D {
> =A0 =A0 =A0 =A0.name =A0 =A0 =A0 =A0 =A0 =3D "mpc8xxx-gpio",
> =A0 =A0 =A0 =A0.unmask =A0 =A0 =A0 =A0 =3D mpc8xxx_irq_unmask,
> @@ -226,6 +273,11 @@ static struct irq_chip mpc8xxx_irq_chip =3D {
> =A0static int mpc8xxx_gpio_irq_map(struct irq_host *h, unsigned int virq,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0irq_hw_num=
ber_t hw)
> =A0{
> + =A0 =A0 =A0 struct mpc8xxx_gpio_chip *mpc8xxx_gc =3D h->host_data;
> +
> + =A0 =A0 =A0 if (mpc8xxx_gc->of_dev_id_data)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpc8xxx_irq_chip.set_type =3D mpc8xxx_gc->o=
f_dev_id_data;
> +
> =A0 =A0 =A0 =A0set_irq_chip_data(virq, h->host_data);
> =A0 =A0 =A0 =A0set_irq_chip_and_handler(virq, &mpc8xxx_irq_chip, handle_l=
evel_irq);
> =A0 =A0 =A0 =A0set_irq_type(virq, IRQ_TYPE_NONE);
> @@ -253,11 +305,20 @@ static struct irq_host_ops mpc8xxx_gpio_irq_ops =3D=
{
> =A0 =A0 =A0 =A0.xlate =A0=3D mpc8xxx_gpio_irq_xlate,
> =A0};
>
> +static struct of_device_id mpc8xxx_gpio_ids[] __initdata =3D {
> + =A0 =A0 =A0 { .compatible =3D "fsl,mpc8349-gpio", },
> + =A0 =A0 =A0 { .compatible =3D "fsl,mpc8572-gpio", },
> + =A0 =A0 =A0 { .compatible =3D "fsl,mpc8610-gpio", },
> + =A0 =A0 =A0 { .compatible =3D "fsl,mpc5121-gpio", .data =3D mpc512x_irq=
_set_type, },
> + =A0 =A0 =A0 {}
> +};
> +
> =A0static void __init mpc8xxx_add_controller(struct device_node *np)
> =A0{
> =A0 =A0 =A0 =A0struct mpc8xxx_gpio_chip *mpc8xxx_gc;
> =A0 =A0 =A0 =A0struct of_mm_gpio_chip *mm_gc;
> =A0 =A0 =A0 =A0struct gpio_chip *gc;
> + =A0 =A0 =A0 const struct of_device_id *id;
> =A0 =A0 =A0 =A0unsigned hwirq;
> =A0 =A0 =A0 =A0int ret;
>
> @@ -297,6 +358,10 @@ static void __init mpc8xxx_add_controller(struct dev=
ice_node *np)
> =A0 =A0 =A0 =A0if (!mpc8xxx_gc->irq)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto skip_irq;
>
> + =A0 =A0 =A0 id =3D of_match_node(mpc8xxx_gpio_ids, np);
> + =A0 =A0 =A0 if (id)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpc8xxx_gc->of_dev_id_data =3D id->data;
> +
> =A0 =A0 =A0 =A0mpc8xxx_gc->irq->host_data =3D mpc8xxx_gc;
>
> =A0 =A0 =A0 =A0/* ack and mask all irqs */
> @@ -321,13 +386,7 @@ static int __init mpc8xxx_add_gpiochips(void)
> =A0{
> =A0 =A0 =A0 =A0struct device_node *np;
>
> - =A0 =A0 =A0 for_each_compatible_node(np, NULL, "fsl,mpc8349-gpio")
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpc8xxx_add_controller(np);
> -
> - =A0 =A0 =A0 for_each_compatible_node(np, NULL, "fsl,mpc8572-gpio")
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpc8xxx_add_controller(np);
> -
> - =A0 =A0 =A0 for_each_compatible_node(np, NULL, "fsl,mpc8610-gpio")
> + =A0 =A0 =A0 for_each_matching_node(np, mpc8xxx_gpio_ids)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mpc8xxx_add_controller(np);
>
> =A0 =A0 =A0 =A0return 0;
> --
> 1.7.0.4
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH v4] powerpc/mpc8xxx_gpio.c: extend the driver to support mpc512x gpios
From: Anatolij Gustschin @ 2010-08-09 5:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Anatolij Gustschin, Wolfgang Denk, Detlev Zundel
In-Reply-To: <1281331211-17878-1-git-send-email-agust@denx.de>
The GPIO controller of MPC512x is slightly different from
8xxx GPIO controllers. The register interface is the same
except the external interrupt control register. The MPC512x
GPIO controller differentiates between four interrupt event
types and therefore provides two interrupt control registers,
GPICR1 and GPICR2. GPIO[0:15] interrupt event types are
configured in GPICR1 register, GPIO[16:31] - in GPICR2 register.
This patch adds MPC512x speciffic set_type() callback and
updates config file and comments. Additionally the gpio chip
registration function is changed to use for_each_matching_node()
preventing multiple registration if a node claimes compatibility
with another gpio controller type.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
v4:
- undo function merging as it was wrong
- fix commit message
v3:
- merge mpc8xxx_add_controller() into mpc8xxx_add_gpiochips()
- do not use of_node's data field for set type hook,
use added void data pointer in the gpio chip struct
instead.
v2:
- add patch description
- use match table data to set irq set_type hook as
recommended
- refactor to use for_each_matching_node() in
mpc8xxx_add_gpiochips() as suggested by Grant
arch/powerpc/platforms/Kconfig | 7 ++-
arch/powerpc/sysdev/mpc8xxx_gpio.c | 75 ++++++++++++++++++++++++++++++++----
2 files changed, 71 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index d1663db..471115a 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -304,13 +304,14 @@ config OF_RTC
source "arch/powerpc/sysdev/bestcomm/Kconfig"
config MPC8xxx_GPIO
- bool "MPC8xxx GPIO support"
- depends on PPC_MPC831x || PPC_MPC834x || PPC_MPC837x || FSL_SOC_BOOKE || PPC_86xx
+ bool "MPC512x/MPC8xxx GPIO support"
+ depends on PPC_MPC512x || PPC_MPC831x || PPC_MPC834x || PPC_MPC837x || \
+ FSL_SOC_BOOKE || PPC_86xx
select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
help
Say Y here if you're going to use hardware that connects to the
- MPC831x/834x/837x/8572/8610 GPIOs.
+ MPC512x/831x/834x/837x/8572/8610 GPIOs.
config SIMPLE_GPIO
bool "Support for simple, memory-mapped GPIO controllers"
diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/sysdev/mpc8xxx_gpio.c
index 2b69084..3649939 100644
--- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
+++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
@@ -1,5 +1,5 @@
/*
- * GPIOs on MPC8349/8572/8610 and compatible
+ * GPIOs on MPC512x/8349/8572/8610 and compatible
*
* Copyright (C) 2008 Peter Korsgaard <jacmet@sunsite.dk>
*
@@ -26,6 +26,7 @@
#define GPIO_IER 0x0c
#define GPIO_IMR 0x10
#define GPIO_ICR 0x14
+#define GPIO_ICR2 0x18
struct mpc8xxx_gpio_chip {
struct of_mm_gpio_chip mm_gc;
@@ -37,6 +38,7 @@ struct mpc8xxx_gpio_chip {
*/
u32 data;
struct irq_host *irq;
+ void *of_dev_id_data;
};
static inline u32 mpc8xxx_gpio2mask(unsigned int gpio)
@@ -215,6 +217,51 @@ static int mpc8xxx_irq_set_type(unsigned int virq, unsigned int flow_type)
return 0;
}
+static int mpc512x_irq_set_type(unsigned int virq, unsigned int flow_type)
+{
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
+ struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
+ unsigned long gpio = virq_to_hw(virq);
+ void __iomem *reg;
+ unsigned int shift;
+ unsigned long flags;
+
+ if (gpio < 16) {
+ reg = mm->regs + GPIO_ICR;
+ shift = (15 - gpio) * 2;
+ } else {
+ reg = mm->regs + GPIO_ICR2;
+ shift = (15 - (gpio % 16)) * 2;
+ }
+
+ switch (flow_type) {
+ case IRQ_TYPE_EDGE_FALLING:
+ case IRQ_TYPE_LEVEL_LOW:
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+ clrsetbits_be32(reg, 3 << shift, 2 << shift);
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+ break;
+
+ case IRQ_TYPE_EDGE_RISING:
+ case IRQ_TYPE_LEVEL_HIGH:
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+ clrsetbits_be32(reg, 3 << shift, 1 << shift);
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+ break;
+
+ case IRQ_TYPE_EDGE_BOTH:
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+ clrbits32(reg, 3 << shift);
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static struct irq_chip mpc8xxx_irq_chip = {
.name = "mpc8xxx-gpio",
.unmask = mpc8xxx_irq_unmask,
@@ -226,6 +273,11 @@ static struct irq_chip mpc8xxx_irq_chip = {
static int mpc8xxx_gpio_irq_map(struct irq_host *h, unsigned int virq,
irq_hw_number_t hw)
{
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = h->host_data;
+
+ if (mpc8xxx_gc->of_dev_id_data)
+ mpc8xxx_irq_chip.set_type = mpc8xxx_gc->of_dev_id_data;
+
set_irq_chip_data(virq, h->host_data);
set_irq_chip_and_handler(virq, &mpc8xxx_irq_chip, handle_level_irq);
set_irq_type(virq, IRQ_TYPE_NONE);
@@ -253,11 +305,20 @@ static struct irq_host_ops mpc8xxx_gpio_irq_ops = {
.xlate = mpc8xxx_gpio_irq_xlate,
};
+static struct of_device_id mpc8xxx_gpio_ids[] __initdata = {
+ { .compatible = "fsl,mpc8349-gpio", },
+ { .compatible = "fsl,mpc8572-gpio", },
+ { .compatible = "fsl,mpc8610-gpio", },
+ { .compatible = "fsl,mpc5121-gpio", .data = mpc512x_irq_set_type, },
+ {}
+};
+
static void __init mpc8xxx_add_controller(struct device_node *np)
{
struct mpc8xxx_gpio_chip *mpc8xxx_gc;
struct of_mm_gpio_chip *mm_gc;
struct gpio_chip *gc;
+ const struct of_device_id *id;
unsigned hwirq;
int ret;
@@ -297,6 +358,10 @@ static void __init mpc8xxx_add_controller(struct device_node *np)
if (!mpc8xxx_gc->irq)
goto skip_irq;
+ id = of_match_node(mpc8xxx_gpio_ids, np);
+ if (id)
+ mpc8xxx_gc->of_dev_id_data = id->data;
+
mpc8xxx_gc->irq->host_data = mpc8xxx_gc;
/* ack and mask all irqs */
@@ -321,13 +386,7 @@ static int __init mpc8xxx_add_gpiochips(void)
{
struct device_node *np;
- for_each_compatible_node(np, NULL, "fsl,mpc8349-gpio")
- mpc8xxx_add_controller(np);
-
- for_each_compatible_node(np, NULL, "fsl,mpc8572-gpio")
- mpc8xxx_add_controller(np);
-
- for_each_compatible_node(np, NULL, "fsl,mpc8610-gpio")
+ for_each_matching_node(np, mpc8xxx_gpio_ids)
mpc8xxx_add_controller(np);
return 0;
--
1.7.0.4
^ permalink raw reply related
* Re: Relocating bootwrapper causes kernel panic
From: Shawn Jin @ 2010-08-09 5:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, ppcdev
In-Reply-To: <1281134958.2168.39.camel@pasglop>
>> > >> I think the cause is clear now. But how to fix it? Two questions:
>> > >> 2. If the DTLB miss exception handler is not the right guy to load =
a
>> > >> proper TLB entry, how can I set one entry based on the link_address
>> > >> and the address of the flat dt blob?
>> > >
>> > > Given how early in the boot process it is, it's probably going to ne=
ed
>> > > to be handled specially.
>> >
>> > What APIs can I use to set up DTLBs?
>>
>> I don't think there is one that works on 8xx. =A0You'll could hack up
>> initial_mmu, or else write some C code to insert an 8xx TLB entry.
>
> Yup, I think he just ends up getting out of the initial mapping which is
> smallish on 8xx, no ? Might be worth sticking in one more entry during
> boot...
If CONFIG_PIN_TLB is on, two more entries are pinned down, which gives
16MB mappings. Just curious. Why is there only one entry by default?
what's the trade-off to pin down all 4 entries?
THanks,
-Shawn.
^ permalink raw reply
* Re: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for eSDHC driver
From: Grant Likely @ 2010-08-09 5:50 UTC (permalink / raw)
To: Zang Roy-R61911; +Cc: linuxppc-dev, akpm, linux-mmc
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60AEA19@zch01exm23.fsl.freescale.net>
On Wed, Aug 4, 2010 at 8:14 PM, Zang Roy-R61911 <r61911@freescale.com> wrot=
e:
>> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> > index c6d1bd8..a92566e 100644
>> > --- a/drivers/mmc/host/sdhci.c
>> > +++ b/drivers/mmc/host/sdhci.c
>> > @@ -817,8 +817,12 @@ static void
>> sdhci_set_transfer_mode(struct sdhci_host *host,
>> > =A0 =A0 =A0 =A0WARN_ON(!host->data);
>> >
>> > =A0 =A0 =A0 =A0mode =3D SDHCI_TRNS_BLK_CNT_EN;
>> > - =A0 =A0 =A0 if (data->blocks > 1)
>> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode |=3D SDHCI_TRNS_MULTI;
>> > + =A0 =A0 =A0 if (data->blocks > 1) {
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (host->quirks &
>> SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode |=3D SDHCI_TRNS_MUL=
TI |
>> SDHCI_TRNS_ACMD12;
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode |=3D SDHCI_TRNS_MUL=
TI;
>>
>> nit:
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode |=3D SDHCI_TRNS_MULTI;
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_=
READ_ACMD12)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mode |=3D SDHCI_TRNS_ACMD1=
2;
>>
>> Clearer, no?
> why?
Shorter lines, fewer lines, and the SDHCI_TRNS_MULTI is more obviously
unconditional. But as I said, it is a nitpick.
g.
^ permalink raw reply
* Re: [PATCH v2] powerpc/mpc8xxx_gpio.c: extend the driver to support mpc512x gpios
From: Grant Likely @ 2010-08-09 5:31 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Anatolij Gustschin, Wolfgang Denk, Detlev Zundel
In-Reply-To: <20100808074035.GA26199@oksana.dev.rtsoft.ru>
On Sun, Aug 8, 2010 at 1:40 AM, Anton Vorontsov <cbouatmailru@gmail.com> wr=
ote:
> On Sat, Aug 07, 2010 at 06:40:22PM -0600, Grant Likely wrote:
> [...]
>> > static int __init mpc8xxx_add_gpiochips(void)
>> > {
>> >+ =A0 =A0const struct of_device_id *id;
>> > =A0 =A0 struct device_node *np;
>> >
>> >- =A0 =A0for_each_compatible_node(np, NULL, "fsl,mpc8349-gpio")
>> >- =A0 =A0 =A0 =A0 =A0 =A0mpc8xxx_add_controller(np);
>> >-
>> >- =A0 =A0for_each_compatible_node(np, NULL, "fsl,mpc8572-gpio")
>> >- =A0 =A0 =A0 =A0 =A0 =A0mpc8xxx_add_controller(np);
>> >-
>> >- =A0 =A0for_each_compatible_node(np, NULL, "fsl,mpc8610-gpio")
>> >+ =A0 =A0for_each_matching_node(np, mpc8xxx_gpio_ids) {
>> >+ =A0 =A0 =A0 =A0 =A0 =A0id =3D of_match_node(mpc8xxx_gpio_ids, np);
>> >+ =A0 =A0 =A0 =A0 =A0 =A0if (id)
>> >+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0np->data =3D id->data;
>> > =A0 =A0 =A0 =A0 =A0 =A0 mpc8xxx_add_controller(np);
>> >+ =A0 =A0}
> [...]
>> Actually, there is absolutely no reason to keep mpc8xxx_add_gpiochip()
>> as a separate function with the simplification of
>> mpc8xxx_add_gpiochips(). =A0I'd simplify the whole thing by merging the
>> two functions together.
>
> You mean mpc8xxx_add_controller()? Putting 65-line function
> on a second indentation level, inside the for loop... sounds
> like a bad idea.
That's a good point. I was thinking about it from the wrong way
around (that the function could bail at the top on a non-match; which
obviously isn't the case). Anatolij, I was wrong on this point.
Sorry I didn't reply sooner before you respun the patch. :-(
g.
^ permalink raw reply
* Re: Review Request: New proposal for device tree clock binding.
From: Grant Likely @ 2010-08-09 5:28 UTC (permalink / raw)
To: Li Yang-R58472; +Cc: devicetree-discuss, linuxppc-dev, Jeremy Kerr
In-Reply-To: <F9BD3E0A8083BE4ABAA94D7EDD7E3F63109216@zch01exm26.fsl.freescale.net>
On Sun, Aug 8, 2010 at 10:50 PM, Li Yang-R58472 <r58472@freescale.com> wrot=
e:
> It looks like the previous sending didn't hit the mailing list. =A0Resend=
.
>
> Hi Grant,
>
> I have some comment on this proposal.
The email addr you're using isn't subscribed, so mailman held the
message for moderation. I've approved it now and added you address to
the accept list.
Anyway, I received it and here is my reply:
http://lists.ozlabs.org/pipermail/devicetree-discuss/2010-August/002706.htm=
l
Cheers,
g.
>
>>Subject: Review Request: New proposal for device tree clock binding.
>>
>>Hi Ben (well, hello to everyone, but I'm particularly interested in
>>Ben's feedback),
>>
>>Jeremy and I have been kicking around the clock binding, and we've come
>>up with a new proposal that doesn't feel quite as forced to me.
>>Please take a look and let me know what you think. =A0The link to the
>>binding is below[1], but I've also copied the full text so that you can
>>reply and comment. =A0The rational for the new binding can be found in
>>talk page[2].
>>
>>[1] http://www.devicetree.org/ClockBindings
>>[2] http://www.devicetree.org/Talk:ClockBindings
>>
>>---
>>
>>This page descibes the proposed OF clock bindings. These are a work-in-
>>progress, and are based on some
>>[http://patchwork.ozlabs.org/patch/31551/
>>experimental work by benh].
>>
>>=3D=3DClock providers=3D=3D
>>
>>Sources of clock signal can be represented by any node in the device tree=
.
>>A mandatory "<tt>clock-outputs</tt>" property describes the clock
>>outputs from this device.
>>
>>{|border=3D1
>>!property
>>!format
>>!notes
>>|-
>>|<tt>clock-outputs</tt>
>>|list of strings
>>|specifies output clock signal names.
>>|}
>>
>>For example:
>>
>> =A0 =A0oscillator {
>> =A0 =A0 =A0 =A0clock-outputs =3D "ckil", "ckih";
>> =A0 =A0};
>>
>>- this node defines a device with two clock outputs, the first named
>>"ckil" and the second named "ckih". =A0Consumer nodes always reference
>>clocks by name. =A0The names should reflect the clock output signal names
>>for the device.
>>
>>=3D=3DClock consumers=3D=3D
>>
>>A device connected to a clock signal needs a *-clock property for each
>>clock that it is connected to.
>>
>>{|border=3D1
>>!property
>>!format
>>!notes
>>|-
>>|<tt>*-clock</tt>
>>|1 cell phandle to the clock provider, followed by a string containing
>>the clock output name.
>>|The name of this property should be the name of the clock input
>>signal with a "-clock" suffix.
>>|}
>>
>><tt>*-clock</tt> is named for the signal name for the ''clock input''
>>of the device. it should describe the function of the signal for that
>>device, rather than the name of the system-wide clock line. For
>>example, a UART with two clocks - one for baud-rate clocking, and the
>>other for register clocking - may have clock input properties named
>>"baud-clock" and "register-clock". =A0The property value is a tuple
>>containing the phandle to the clock provider and the name of the clock ou=
tput signal.
>>
>>For example:
>>
>> =A0 =A0uart {
>> =A0 =A0 =A0 =A0baud-clock =3D <&osc>, "ckil";
>> =A0 =A0 =A0 =A0register-clock =3D <&ref>, "bus";
>> =A0 =A0};
>>
>>
>>This represents a device with two clock inputs, named "baud" and
>>"register". The baud clock is connected to the "ckil" output of the "osc"
>>device, and the register clock is connected to the "bus" output of the
>>"ref" device.
>
>
> Instead of having two items to identify a clock, I would suggest to have =
a node for each clock. =A0So that clock can be referenced by one handle. =
=A0Also we can have clock specific information defined in the clock node. =
=A0Here is the example I am planning to use on 85xx PMC.
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0power@e0070{
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "fsl,mpc854=
8-pmc", "fsl,p2020-pmc";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0xe0070 0x20>;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0etsec1_clk: soc-clk@24{
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fsl,pmcdr-=
mask =3D <0x00000080>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0etsec2_clk: soc-clk@25{
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fsl,pmcdr-=
mask =3D <0x00000040>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0etsec3_clk: soc-clk@26{
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fsl,pmcdr-=
mask =3D <0x00000020>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0enet0: ethernet@24000 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0......
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0master-clock =3D <&etsec1_=
clk>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0......
>
>
> What do you think?
>
> - Leo
>
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH v3] powerpc/mpc8xxx_gpio.c: extend the driver to support mpc512x gpios
From: Anatolij Gustschin @ 2010-08-09 5:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Anatolij Gustschin, Wolfgang Denk, Detlev Zundel
In-Reply-To: <1281207816-31807-1-git-send-email-agust@denx.de>
The GPIO controller of MPC512x is slightly different from
8xxx GPIO controllers. The register interface is the same
except the external interrupt control register. The MPC512x
GPIO controller differentiates between four interrupt event
types and therefore provides two interrupt control registers,
GPICR1 and GPICR2. GPIO[0:15] interrupt event types are
configured in GPICR1 register, GPIO[16:31] - in GPICR2 register.
This patch adds MPC512x speciffic set_type() callback and
updates config file and comments. Additionally the gpio chip
registration function is changed to use for_each_matching_node()
preventing multiple registration if a node claimes compatibility
with another gpio controller type. Also merge two chip
registration functions into one.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
v3:
- merge mpc8xxx_add_controller() into mpc8xxx_add_gpiochips()
- do not use of_node's data field for set type hook,
use added void data pointer in the gpio chip struct
instead.
v2:
- add patch description
- use match table data to set irq set_type hook as
recommended
- refactor to use for_each_matching_node() in
mpc8xxx_add_gpiochips() as suggested by Grant
arch/powerpc/platforms/Kconfig | 7 +-
arch/powerpc/sysdev/mpc8xxx_gpio.c | 196 +++++++++++++++++++++++-------------
2 files changed, 129 insertions(+), 74 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index d1663db..471115a 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -304,13 +304,14 @@ config OF_RTC
source "arch/powerpc/sysdev/bestcomm/Kconfig"
config MPC8xxx_GPIO
- bool "MPC8xxx GPIO support"
- depends on PPC_MPC831x || PPC_MPC834x || PPC_MPC837x || FSL_SOC_BOOKE || PPC_86xx
+ bool "MPC512x/MPC8xxx GPIO support"
+ depends on PPC_MPC512x || PPC_MPC831x || PPC_MPC834x || PPC_MPC837x || \
+ FSL_SOC_BOOKE || PPC_86xx
select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
help
Say Y here if you're going to use hardware that connects to the
- MPC831x/834x/837x/8572/8610 GPIOs.
+ MPC512x/831x/834x/837x/8572/8610 GPIOs.
config SIMPLE_GPIO
bool "Support for simple, memory-mapped GPIO controllers"
diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/sysdev/mpc8xxx_gpio.c
index 2b69084..072f490 100644
--- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
+++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
@@ -1,5 +1,5 @@
/*
- * GPIOs on MPC8349/8572/8610 and compatible
+ * GPIOs on MPC512x/8349/8572/8610 and compatible
*
* Copyright (C) 2008 Peter Korsgaard <jacmet@sunsite.dk>
*
@@ -26,6 +26,7 @@
#define GPIO_IER 0x0c
#define GPIO_IMR 0x10
#define GPIO_ICR 0x14
+#define GPIO_ICR2 0x18
struct mpc8xxx_gpio_chip {
struct of_mm_gpio_chip mm_gc;
@@ -37,6 +38,7 @@ struct mpc8xxx_gpio_chip {
*/
u32 data;
struct irq_host *irq;
+ void *of_dev_id_data;
};
static inline u32 mpc8xxx_gpio2mask(unsigned int gpio)
@@ -215,6 +217,51 @@ static int mpc8xxx_irq_set_type(unsigned int virq, unsigned int flow_type)
return 0;
}
+static int mpc512x_irq_set_type(unsigned int virq, unsigned int flow_type)
+{
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = get_irq_chip_data(virq);
+ struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
+ unsigned long gpio = virq_to_hw(virq);
+ void __iomem *reg;
+ unsigned int shift;
+ unsigned long flags;
+
+ if (gpio < 16) {
+ reg = mm->regs + GPIO_ICR;
+ shift = (15 - gpio) * 2;
+ } else {
+ reg = mm->regs + GPIO_ICR2;
+ shift = (15 - (gpio % 16)) * 2;
+ }
+
+ switch (flow_type) {
+ case IRQ_TYPE_EDGE_FALLING:
+ case IRQ_TYPE_LEVEL_LOW:
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+ clrsetbits_be32(reg, 3 << shift, 2 << shift);
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+ break;
+
+ case IRQ_TYPE_EDGE_RISING:
+ case IRQ_TYPE_LEVEL_HIGH:
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+ clrsetbits_be32(reg, 3 << shift, 1 << shift);
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+ break;
+
+ case IRQ_TYPE_EDGE_BOTH:
+ spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
+ clrbits32(reg, 3 << shift);
+ spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static struct irq_chip mpc8xxx_irq_chip = {
.name = "mpc8xxx-gpio",
.unmask = mpc8xxx_irq_unmask,
@@ -226,6 +273,11 @@ static struct irq_chip mpc8xxx_irq_chip = {
static int mpc8xxx_gpio_irq_map(struct irq_host *h, unsigned int virq,
irq_hw_number_t hw)
{
+ struct mpc8xxx_gpio_chip *mpc8xxx_gc = h->host_data;
+
+ if (mpc8xxx_gc->of_dev_id_data)
+ mpc8xxx_irq_chip.set_type = mpc8xxx_gc->of_dev_id_data;
+
set_irq_chip_data(virq, h->host_data);
set_irq_chip_and_handler(virq, &mpc8xxx_irq_chip, handle_level_irq);
set_irq_type(virq, IRQ_TYPE_NONE);
@@ -253,83 +305,85 @@ static struct irq_host_ops mpc8xxx_gpio_irq_ops = {
.xlate = mpc8xxx_gpio_irq_xlate,
};
-static void __init mpc8xxx_add_controller(struct device_node *np)
+static struct of_device_id mpc8xxx_gpio_ids[] __initdata = {
+ { .compatible = "fsl,mpc8349-gpio", },
+ { .compatible = "fsl,mpc8572-gpio", },
+ { .compatible = "fsl,mpc8610-gpio", },
+ { .compatible = "fsl,mpc5121-gpio", .data = mpc512x_irq_set_type, },
+ {}
+};
+
+static int __init mpc8xxx_add_gpiochips(void)
{
struct mpc8xxx_gpio_chip *mpc8xxx_gc;
struct of_mm_gpio_chip *mm_gc;
struct gpio_chip *gc;
+ struct device_node *np;
+ const struct of_device_id *id;
unsigned hwirq;
- int ret;
-
- mpc8xxx_gc = kzalloc(sizeof(*mpc8xxx_gc), GFP_KERNEL);
- if (!mpc8xxx_gc) {
- ret = -ENOMEM;
- goto err;
- }
-
- spin_lock_init(&mpc8xxx_gc->lock);
-
- mm_gc = &mpc8xxx_gc->mm_gc;
- gc = &mm_gc->gc;
-
- mm_gc->save_regs = mpc8xxx_gpio_save_regs;
- gc->ngpio = MPC8XXX_GPIO_PINS;
- gc->direction_input = mpc8xxx_gpio_dir_in;
- gc->direction_output = mpc8xxx_gpio_dir_out;
- if (of_device_is_compatible(np, "fsl,mpc8572-gpio"))
- gc->get = mpc8572_gpio_get;
- else
- gc->get = mpc8xxx_gpio_get;
- gc->set = mpc8xxx_gpio_set;
- gc->to_irq = mpc8xxx_gpio_to_irq;
-
- ret = of_mm_gpiochip_add(np, mm_gc);
- if (ret)
- goto err;
-
- hwirq = irq_of_parse_and_map(np, 0);
- if (hwirq == NO_IRQ)
- goto skip_irq;
-
- mpc8xxx_gc->irq =
- irq_alloc_host(np, IRQ_HOST_MAP_LINEAR, MPC8XXX_GPIO_PINS,
- &mpc8xxx_gpio_irq_ops, MPC8XXX_GPIO_PINS);
- if (!mpc8xxx_gc->irq)
- goto skip_irq;
-
- mpc8xxx_gc->irq->host_data = mpc8xxx_gc;
-
- /* ack and mask all irqs */
- out_be32(mm_gc->regs + GPIO_IER, 0xffffffff);
- out_be32(mm_gc->regs + GPIO_IMR, 0);
-
- set_irq_data(hwirq, mpc8xxx_gc);
- set_irq_chained_handler(hwirq, mpc8xxx_gpio_irq_cascade);
-
-skip_irq:
- return;
-
+ int ret = 0;
+
+ for_each_matching_node(np, mpc8xxx_gpio_ids) {
+ mpc8xxx_gc = kzalloc(sizeof(*mpc8xxx_gc), GFP_KERNEL);
+ if (!mpc8xxx_gc) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ spin_lock_init(&mpc8xxx_gc->lock);
+
+ mm_gc = &mpc8xxx_gc->mm_gc;
+ gc = &mm_gc->gc;
+
+ mm_gc->save_regs = mpc8xxx_gpio_save_regs;
+ gc->ngpio = MPC8XXX_GPIO_PINS;
+ gc->direction_input = mpc8xxx_gpio_dir_in;
+ gc->direction_output = mpc8xxx_gpio_dir_out;
+ if (of_device_is_compatible(np, "fsl,mpc8572-gpio"))
+ gc->get = mpc8572_gpio_get;
+ else
+ gc->get = mpc8xxx_gpio_get;
+ gc->set = mpc8xxx_gpio_set;
+ gc->to_irq = mpc8xxx_gpio_to_irq;
+
+ ret = of_mm_gpiochip_add(np, mm_gc);
+ if (ret)
+ goto err;
+
+ hwirq = irq_of_parse_and_map(np, 0);
+ if (hwirq == NO_IRQ)
+ continue;
+
+ mpc8xxx_gc->irq =
+ irq_alloc_host(np, IRQ_HOST_MAP_LINEAR,
+ MPC8XXX_GPIO_PINS,
+ &mpc8xxx_gpio_irq_ops,
+ MPC8XXX_GPIO_PINS);
+ if (!mpc8xxx_gc->irq)
+ continue;
+
+ id = of_match_node(mpc8xxx_gpio_ids, np);
+ if (id)
+ mpc8xxx_gc->of_dev_id_data = id->data;
+
+ mpc8xxx_gc->irq->host_data = mpc8xxx_gc;
+
+ /* ack and mask all irqs */
+ out_be32(mm_gc->regs + GPIO_IER, 0xffffffff);
+ out_be32(mm_gc->regs + GPIO_IMR, 0);
+
+ set_irq_data(hwirq, mpc8xxx_gc);
+ set_irq_chained_handler(hwirq, mpc8xxx_gpio_irq_cascade);
+
+ continue;
err:
- pr_err("%s: registration failed with status %d\n",
- np->full_name, ret);
- kfree(mpc8xxx_gc);
-
- return;
-}
-
-static int __init mpc8xxx_add_gpiochips(void)
-{
- struct device_node *np;
-
- for_each_compatible_node(np, NULL, "fsl,mpc8349-gpio")
- mpc8xxx_add_controller(np);
+ pr_err("%s: registration failed with status %d\n",
+ np->full_name, ret);
+ kfree(mpc8xxx_gc);
- for_each_compatible_node(np, NULL, "fsl,mpc8572-gpio")
- mpc8xxx_add_controller(np);
-
- for_each_compatible_node(np, NULL, "fsl,mpc8610-gpio")
- mpc8xxx_add_controller(np);
+ continue;
+ }
- return 0;
+ return ret;
}
arch_initcall(mpc8xxx_add_gpiochips);
--
1.7.0.4
^ 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