* Re: [PATCH] mmc_spi: Fix unterminated of_match_table
From: Grant Likely @ 2010-08-08 15:02 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <20100808141422.GA9670@oksana.dev.rtsoft.ru>
On Sun, Aug 8, 2010 at 8:14 AM, Anton Vorontsov <avorontsov@mvista.com> wro=
te:
> commit 2ffe8c5f323c3b9749bf7bc2375d909d20bdbb15 ("of: refactor
> of_modalias_node() and remove explicit match table"), introduced
> an unterminated of_match_table, which may cause kernel to oops.
>
> This patch fixes the issue by adding an empty device ID.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Thanks Anton. Merged into my next-devicetree branch.
g.
> ---
> =A0drivers/mmc/host/mmc_spi.c | =A0 =A01 +
> =A01 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
> index 7b0f3ef..1145ea0 100644
> --- a/drivers/mmc/host/mmc_spi.c
> +++ b/drivers/mmc/host/mmc_spi.c
> @@ -1536,6 +1536,7 @@ static int __devexit mmc_spi_remove(struct spi_devi=
ce *spi)
> =A0#if defined(CONFIG_OF)
> =A0static struct of_device_id mmc_spi_of_match_table[] __devinitdata =3D =
{
> =A0 =A0 =A0 =A0{ .compatible =3D "mmc-spi-slot", },
> + =A0 =A0 =A0 {},
> =A0};
> =A0#endif
>
> --
> 1.7.0.5
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc/fsl-pci: Fix MSI support on 83xx platforms
From: Ilya Yanok @ 2010-08-08 21:52 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,
On 05.08.2010 12:02, Kumar Gala wrote:
> 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.
>
Thanks, your patch really does help on MPC8308 board I use.
Regards, Ilya.
^ permalink raw reply
* Re: [PATCH] powerpc: inline ppc64_runlatch_off
From: Olof Johansson @ 2010-08-09 2:44 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20100806132819.GU29316@kryten>
On Fri, Aug 06, 2010 at 11:28:19PM +1000, Anton Blanchard wrote:
>
> Hi Olof,
>
> > No semicolon here.
>
> Nice catch!
>
> Anton
>
> I'm sick of seeing ppc64_runlatch_off in our profiles, so inline it
> into the callers. To avoid a mess of circular includes I didn't add
> it as an inline function.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Olof Johansson <olof@lixom.net>
-Olof
^ permalink raw reply
* [git pull] Please pull powerpc.git next branch
From: Benjamin Herrenschmidt @ 2010-08-09 4:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here's a few misc things for .36. The big bit is that I trimmed all the
defconfigs using make savedefconfig.
Then there's a revert for a change to the appletouch driver that went
in .34 but broke quite a few powerbooks around. Since the original
problem this was trying to address is fairly minor and the "fix"
completely breaks a number of devices, I decided to send you a revert
for now until we sort it out.
Finally, a couple of 52xx embedded bits from Grant that he forgot
last time around and a build fix.
Cheers,
Ben.
The following changes since commit 45d7f32c7a43cbb9592886d38190e379e2eb2226:
Linus Torvalds (1):
Merge git://git.kernel.org/.../cmetcalf/linux-tile
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Benjamin Herrenschmidt (4):
powerpc: Trim defconfigs
memblock: Fix memblock_is_region_reserved() to return a boolean
Merge remote branch 'gcl/next' into next
Revert "Input: appletouch - fix integer overflow issue"
Eric Millbrandt (2):
powerpc/5200: add mpc5200_psc_ac97_gpio_reset
sound/soc: mpc5200_psc_ac97: Use gpio pins for cold reset
Grant Likely (1):
powerpc: fix i8042 module build error
arch/powerpc/configs/40x/acadia_defconfig | 1003 +----------
arch/powerpc/configs/40x/ep405_defconfig | 1212 +------------
arch/powerpc/configs/40x/hcu4_defconfig | 1065 +----------
arch/powerpc/configs/40x/kilauea_defconfig | 1198 +-----------
arch/powerpc/configs/40x/makalu_defconfig | 1006 +----------
arch/powerpc/configs/40x/virtex_defconfig | 1107 +-----------
arch/powerpc/configs/40x/walnut_defconfig | 1090 +----------
arch/powerpc/configs/44x/arches_defconfig | 1060 +----------
arch/powerpc/configs/44x/bamboo_defconfig | 1021 +----------
arch/powerpc/configs/44x/canyonlands_defconfig | 1264 +------------
arch/powerpc/configs/44x/ebony_defconfig | 1104 +-----------
arch/powerpc/configs/44x/eiger_defconfig | 1176 +-----------
arch/powerpc/configs/44x/icon_defconfig | 1334 +-------------
arch/powerpc/configs/44x/iss476-smp_defconfig | 938 +---------
arch/powerpc/configs/44x/katmai_defconfig | 1089 +----------
arch/powerpc/configs/44x/rainier_defconfig | 1091 +----------
arch/powerpc/configs/44x/redwood_defconfig | 1167 +-----------
arch/powerpc/configs/44x/sam440ep_defconfig | 1320 +-------------
arch/powerpc/configs/44x/sequoia_defconfig | 1112 +-----------
arch/powerpc/configs/44x/taishan_defconfig | 1098 +-----------
arch/powerpc/configs/44x/virtex5_defconfig | 1113 +-----------
arch/powerpc/configs/44x/warp_defconfig | 1389 +-------------
arch/powerpc/configs/52xx/cm5200_defconfig | 1232 +------------
arch/powerpc/configs/52xx/lite5200b_defconfig | 1257 +------------
arch/powerpc/configs/52xx/motionpro_defconfig | 1265 +------------
arch/powerpc/configs/52xx/pcm030_defconfig | 1220 +------------
arch/powerpc/configs/52xx/tqm5200_defconfig | 1367 +-------------
arch/powerpc/configs/83xx/asp8347_defconfig | 1433 +--------------
arch/powerpc/configs/83xx/kmeter1_defconfig | 929 +---------
arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 1729 +----------------
arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 1798 +-----------------
arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 1329 +-------------
arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 1476 +--------------
arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 1568 +---------------
arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 1454 +--------------
arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 1263 +------------
arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 1404 +-------------
arch/powerpc/configs/83xx/mpc836x_rdk_defconfig | 1305 +------------
arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 1334 +-------------
arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 1472 +--------------
arch/powerpc/configs/83xx/sbc834x_defconfig | 1398 +-------------
arch/powerpc/configs/85xx/ksi8560_defconfig | 1117 -----------
arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 992 +----------
arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 1137 -----------
arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 1155 +-----------
arch/powerpc/configs/85xx/sbc8548_defconfig | 1003 +----------
arch/powerpc/configs/85xx/sbc8560_defconfig | 1029 +----------
arch/powerpc/configs/85xx/socrates_defconfig | 1643 ----------------
arch/powerpc/configs/85xx/stx_gp3_defconfig | 1528 +--------------
arch/powerpc/configs/85xx/tqm8540_defconfig | 1317 -------------
arch/powerpc/configs/85xx/tqm8541_defconfig | 1363 -------------
arch/powerpc/configs/85xx/tqm8548_defconfig | 1355 +-------------
arch/powerpc/configs/85xx/tqm8555_defconfig | 1363 -------------
arch/powerpc/configs/85xx/tqm8560_defconfig | 1363 -------------
arch/powerpc/configs/85xx/xes_mpc85xx_defconfig | 1784 +-----------------
arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 1733 ----------------
arch/powerpc/configs/86xx/gef_sbc310_defconfig | 1622 ---------------
arch/powerpc/configs/86xx/gef_sbc610_defconfig | 1815 -----------------
arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig | 1632 +---------------
arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig | 1639 +---------------
arch/powerpc/configs/86xx/sbc8641d_defconfig | 1428 --------------
arch/powerpc/configs/adder875_defconfig | 912 ---------
arch/powerpc/configs/amigaone_defconfig | 1492 +--------------
arch/powerpc/configs/c2k_defconfig | 1622 ---------------
arch/powerpc/configs/cell_defconfig | 1317 +------------
arch/powerpc/configs/celleb_defconfig | 1197 +-----------
arch/powerpc/configs/chrp32_defconfig | 1471 +--------------
arch/powerpc/configs/ep8248e_defconfig | 1120 +-----------
arch/powerpc/configs/ep88xc_defconfig | 859 +--------
arch/powerpc/configs/g5_defconfig | 1551 +---------------
arch/powerpc/configs/gamecube_defconfig | 948 +---------
arch/powerpc/configs/holly_defconfig | 881 +---------
arch/powerpc/configs/iseries_defconfig | 1058 +----------
arch/powerpc/configs/linkstation_defconfig | 1782 +-----------------
arch/powerpc/configs/maple_defconfig | 1373 +-------------
arch/powerpc/configs/mgcoge_defconfig | 1160 +-----------
arch/powerpc/configs/mgsuvd_defconfig | 936 ---------
arch/powerpc/configs/mpc512x_defconfig | 1559 +---------------
arch/powerpc/configs/mpc5200_defconfig | 1849 +-----------------
arch/powerpc/configs/mpc7448_hpc2_defconfig | 1195 +-----------
arch/powerpc/configs/mpc8272_ads_defconfig | 1185 +-----------
arch/powerpc/configs/mpc83xx_defconfig | 1663 +----------------
arch/powerpc/configs/mpc85xx_defconfig | 1689 +----------------
arch/powerpc/configs/mpc85xx_smp_defconfig | 1693 +----------------
arch/powerpc/configs/mpc866_ads_defconfig | 949 ---------
arch/powerpc/configs/mpc86xx_defconfig | 1679 +----------------
arch/powerpc/configs/mpc885_ads_defconfig | 864 +--------
arch/powerpc/configs/pasemi_defconfig | 1931 +------------------
arch/powerpc/configs/pmac32_defconfig | 1886 +------------------
arch/powerpc/configs/ppc40x_defconfig | 1332 +-------------
arch/powerpc/configs/ppc44x_defconfig | 1471 +--------------
arch/powerpc/configs/ppc64_defconfig | 1726 +----------------
arch/powerpc/configs/ppc64e_defconfig | 1803 +-----------------
arch/powerpc/configs/ppc6xx_defconfig | 2189 +--------------------
arch/powerpc/configs/pq2fads_defconfig | 1304 +------------
arch/powerpc/configs/prpmc2800_defconfig | 1675 +----------------
arch/powerpc/configs/ps3_defconfig | 1334 +-------------
arch/powerpc/configs/pseries_defconfig | 1456 +--------------
arch/powerpc/configs/storcenter_defconfig | 1305 +------------
arch/powerpc/configs/tqm8xx_defconfig | 850 +--------
arch/powerpc/configs/wii_defconfig | 1265 +------------
arch/powerpc/include/asm/mpc52xx.h | 1 +
arch/powerpc/include/asm/mpc52xx_psc.h | 1 +
arch/powerpc/kernel/setup-common.c | 2 +
arch/powerpc/platforms/52xx/mpc52xx_common.c | 106 +
drivers/input/mouse/appletouch.c | 6 +-
mm/memblock.c | 2 +-
sound/soc/fsl/mpc5200_psc_ac97.c | 22 +-
108 files changed, 270 insertions(+), 134609 deletions(-)
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git next branch
From: Benjamin Herrenschmidt @ 2010-08-09 4:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
In-Reply-To: <1281327087.2168.67.camel@pasglop>
On Mon, 2010-08-09 at 14:11 +1000, Benjamin Herrenschmidt wrote:
> Hi Linus !
>
> Here's a few misc things for .36. The big bit is that I trimmed all the
> defconfigs using make savedefconfig.
>
> Then there's a revert for a change to the appletouch driver that went
> in .34 but broke quite a few powerbooks around. Since the original
> problem this was trying to address is fairly minor and the "fix"
> completely breaks a number of devices, I decided to send you a revert
> for now until we sort it out.
>
> Finally, a couple of 52xx embedded bits from Grant that he forgot
> last time around and a build fix.
Just added one more commit:
Sam Ravnborg (1):
powerpc: fix build with make 3.82
Which adds:
arch/powerpc/Makefile | 16 +-
And changes:
109 files changed, 282 insertions(+), 134613 deletions(-)
Cheers,
Ben.
> Cheers,
> Ben.
>
> The following changes since commit 45d7f32c7a43cbb9592886d38190e379e2eb2226:
> Linus Torvalds (1):
> Merge git://git.kernel.org/.../cmetcalf/linux-tile
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
>
> Benjamin Herrenschmidt (4):
> powerpc: Trim defconfigs
> memblock: Fix memblock_is_region_reserved() to return a boolean
> Merge remote branch 'gcl/next' into next
> Revert "Input: appletouch - fix integer overflow issue"
>
> Eric Millbrandt (2):
> powerpc/5200: add mpc5200_psc_ac97_gpio_reset
> sound/soc: mpc5200_psc_ac97: Use gpio pins for cold reset
>
> Grant Likely (1):
> powerpc: fix i8042 module build error
>
> arch/powerpc/configs/40x/acadia_defconfig | 1003 +----------
> arch/powerpc/configs/40x/ep405_defconfig | 1212 +------------
> arch/powerpc/configs/40x/hcu4_defconfig | 1065 +----------
> arch/powerpc/configs/40x/kilauea_defconfig | 1198 +-----------
> arch/powerpc/configs/40x/makalu_defconfig | 1006 +----------
> arch/powerpc/configs/40x/virtex_defconfig | 1107 +-----------
> arch/powerpc/configs/40x/walnut_defconfig | 1090 +----------
> arch/powerpc/configs/44x/arches_defconfig | 1060 +----------
> arch/powerpc/configs/44x/bamboo_defconfig | 1021 +----------
> arch/powerpc/configs/44x/canyonlands_defconfig | 1264 +------------
> arch/powerpc/configs/44x/ebony_defconfig | 1104 +-----------
> arch/powerpc/configs/44x/eiger_defconfig | 1176 +-----------
> arch/powerpc/configs/44x/icon_defconfig | 1334 +-------------
> arch/powerpc/configs/44x/iss476-smp_defconfig | 938 +---------
> arch/powerpc/configs/44x/katmai_defconfig | 1089 +----------
> arch/powerpc/configs/44x/rainier_defconfig | 1091 +----------
> arch/powerpc/configs/44x/redwood_defconfig | 1167 +-----------
> arch/powerpc/configs/44x/sam440ep_defconfig | 1320 +-------------
> arch/powerpc/configs/44x/sequoia_defconfig | 1112 +-----------
> arch/powerpc/configs/44x/taishan_defconfig | 1098 +-----------
> arch/powerpc/configs/44x/virtex5_defconfig | 1113 +-----------
> arch/powerpc/configs/44x/warp_defconfig | 1389 +-------------
> arch/powerpc/configs/52xx/cm5200_defconfig | 1232 +------------
> arch/powerpc/configs/52xx/lite5200b_defconfig | 1257 +------------
> arch/powerpc/configs/52xx/motionpro_defconfig | 1265 +------------
> arch/powerpc/configs/52xx/pcm030_defconfig | 1220 +------------
> arch/powerpc/configs/52xx/tqm5200_defconfig | 1367 +-------------
> arch/powerpc/configs/83xx/asp8347_defconfig | 1433 +--------------
> arch/powerpc/configs/83xx/kmeter1_defconfig | 929 +---------
> arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 1729 +----------------
> arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 1798 +-----------------
> arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 1329 +-------------
> arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 1476 +--------------
> arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 1568 +---------------
> arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 1454 +--------------
> arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 1263 +------------
> arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 1404 +-------------
> arch/powerpc/configs/83xx/mpc836x_rdk_defconfig | 1305 +------------
> arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 1334 +-------------
> arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 1472 +--------------
> arch/powerpc/configs/83xx/sbc834x_defconfig | 1398 +-------------
> arch/powerpc/configs/85xx/ksi8560_defconfig | 1117 -----------
> arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 992 +----------
> arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 1137 -----------
> arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 1155 +-----------
> arch/powerpc/configs/85xx/sbc8548_defconfig | 1003 +----------
> arch/powerpc/configs/85xx/sbc8560_defconfig | 1029 +----------
> arch/powerpc/configs/85xx/socrates_defconfig | 1643 ----------------
> arch/powerpc/configs/85xx/stx_gp3_defconfig | 1528 +--------------
> arch/powerpc/configs/85xx/tqm8540_defconfig | 1317 -------------
> arch/powerpc/configs/85xx/tqm8541_defconfig | 1363 -------------
> arch/powerpc/configs/85xx/tqm8548_defconfig | 1355 +-------------
> arch/powerpc/configs/85xx/tqm8555_defconfig | 1363 -------------
> arch/powerpc/configs/85xx/tqm8560_defconfig | 1363 -------------
> arch/powerpc/configs/85xx/xes_mpc85xx_defconfig | 1784 +-----------------
> arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 1733 ----------------
> arch/powerpc/configs/86xx/gef_sbc310_defconfig | 1622 ---------------
> arch/powerpc/configs/86xx/gef_sbc610_defconfig | 1815 -----------------
> arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig | 1632 +---------------
> arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig | 1639 +---------------
> arch/powerpc/configs/86xx/sbc8641d_defconfig | 1428 --------------
> arch/powerpc/configs/adder875_defconfig | 912 ---------
> arch/powerpc/configs/amigaone_defconfig | 1492 +--------------
> arch/powerpc/configs/c2k_defconfig | 1622 ---------------
> arch/powerpc/configs/cell_defconfig | 1317 +------------
> arch/powerpc/configs/celleb_defconfig | 1197 +-----------
> arch/powerpc/configs/chrp32_defconfig | 1471 +--------------
> arch/powerpc/configs/ep8248e_defconfig | 1120 +-----------
> arch/powerpc/configs/ep88xc_defconfig | 859 +--------
> arch/powerpc/configs/g5_defconfig | 1551 +---------------
> arch/powerpc/configs/gamecube_defconfig | 948 +---------
> arch/powerpc/configs/holly_defconfig | 881 +---------
> arch/powerpc/configs/iseries_defconfig | 1058 +----------
> arch/powerpc/configs/linkstation_defconfig | 1782 +-----------------
> arch/powerpc/configs/maple_defconfig | 1373 +-------------
> arch/powerpc/configs/mgcoge_defconfig | 1160 +-----------
> arch/powerpc/configs/mgsuvd_defconfig | 936 ---------
> arch/powerpc/configs/mpc512x_defconfig | 1559 +---------------
> arch/powerpc/configs/mpc5200_defconfig | 1849 +-----------------
> arch/powerpc/configs/mpc7448_hpc2_defconfig | 1195 +-----------
> arch/powerpc/configs/mpc8272_ads_defconfig | 1185 +-----------
> arch/powerpc/configs/mpc83xx_defconfig | 1663 +----------------
> arch/powerpc/configs/mpc85xx_defconfig | 1689 +----------------
> arch/powerpc/configs/mpc85xx_smp_defconfig | 1693 +----------------
> arch/powerpc/configs/mpc866_ads_defconfig | 949 ---------
> arch/powerpc/configs/mpc86xx_defconfig | 1679 +----------------
> arch/powerpc/configs/mpc885_ads_defconfig | 864 +--------
> arch/powerpc/configs/pasemi_defconfig | 1931 +------------------
> arch/powerpc/configs/pmac32_defconfig | 1886 +------------------
> arch/powerpc/configs/ppc40x_defconfig | 1332 +-------------
> arch/powerpc/configs/ppc44x_defconfig | 1471 +--------------
> arch/powerpc/configs/ppc64_defconfig | 1726 +----------------
> arch/powerpc/configs/ppc64e_defconfig | 1803 +-----------------
> arch/powerpc/configs/ppc6xx_defconfig | 2189 +--------------------
> arch/powerpc/configs/pq2fads_defconfig | 1304 +------------
> arch/powerpc/configs/prpmc2800_defconfig | 1675 +----------------
> arch/powerpc/configs/ps3_defconfig | 1334 +-------------
> arch/powerpc/configs/pseries_defconfig | 1456 +--------------
> arch/powerpc/configs/storcenter_defconfig | 1305 +------------
> arch/powerpc/configs/tqm8xx_defconfig | 850 +--------
> arch/powerpc/configs/wii_defconfig | 1265 +------------
> arch/powerpc/include/asm/mpc52xx.h | 1 +
> arch/powerpc/include/asm/mpc52xx_psc.h | 1 +
> arch/powerpc/kernel/setup-common.c | 2 +
> arch/powerpc/platforms/52xx/mpc52xx_common.c | 106 +
> drivers/input/mouse/appletouch.c | 6 +-
> mm/memblock.c | 2 +-
> sound/soc/fsl/mpc5200_psc_ac97.c | 22 +-
> 108 files changed, 270 insertions(+), 134609 deletions(-)
>
^ permalink raw reply
* RE: Review Request: New proposal for device tree clock binding.
From: Li Yang-R58472 @ 2010-08-09 4:50 UTC (permalink / raw)
To: Grant Likely, devicetree-discuss, Jeremy Kerr,
Benjamin Herrenschmidt
Cc: linuxppc-dev
In-Reply-To: <AANLkTimm7G--LQHYBqPB1YCXQb7fSXPDaYsLq0p30DG1@mail.gmail.com>
It looks like the previous sending didn't hit the mailing list. Resend.
Hi Grant,
I have some comment on this proposal.
>Subject: Review Request: New proposal for device tree clock binding.
>
>Hi Ben (well, hello to everyone, but I'm particularly interested in=20
>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. The link to the=20
>binding is below[1], but I've also copied the full text so that you can =
>reply and comment. The rational for the new binding can be found in=20
>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=20
>[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=20
>outputs from this device.
>
>{|border=3D1
>!property
>!format
>!notes
>|-
>|<tt>clock-outputs</tt>
>|list of strings
>|specifies output clock signal names.
>|}
>
>For example:
>
> oscillator {
> clock-outputs =3D "ckil", "ckih";
> };
>
>- this node defines a device with two clock outputs, the first named=20
>"ckil" and the second named "ckih". Consumer nodes always reference=20
>clocks by name. The 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=20
>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=20
>device, rather than the name of the system-wide clock line. For=20
>example, a UART with two clocks - one for baud-rate clocking, and the=20
>other for register clocking - may have clock input properties named=20
>"baud-clock" and "register-clock". The property value is a tuple=20
>containing the phandle to the clock provider and the name of the clock =
output signal.
>
>For example:
>
> uart {
> baud-clock =3D <&osc>, "ckil";
> register-clock =3D <&ref>, "bus";
> };
>
>
>This represents a device with two clock inputs, named "baud" and=20
>"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=20
>"ref" device.
Instead of having two items to identify a clock, I would suggest to have =
a node for each clock. So that clock can be referenced by one handle. =
Also we can have clock specific information defined in the clock node. =
Here is the example I am planning to use on 85xx PMC.
power@e0070{
compatible =3D "fsl,mpc8548-pmc", =
"fsl,p2020-pmc";
reg =3D <0xe0070 0x20>;
etsec1_clk: soc-clk@24{
fsl,pmcdr-mask =3D <0x00000080>;
};
etsec2_clk: soc-clk@25{
fsl,pmcdr-mask =3D <0x00000040>;
};
etsec3_clk: soc-clk@26{
fsl,pmcdr-mask =3D <0x00000020>;
};
};
enet0: ethernet@24000 {
......
master-clock =3D <&etsec1_clk>;
......
What do you think?
- Leo
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git next branch
From: Grant Likely @ 2010-08-09 5:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Andrew Morton, Linus Torvalds,
Linux Kernel list
In-Reply-To: <1281327087.2168.67.camel@pasglop>
On Sun, Aug 8, 2010 at 10:11 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> Hi Linus !
>
> Here's a few misc things for .36. The big bit is that I trimmed all the
> defconfigs using make savedefconfig.
[...]
> =A0108 files changed, 270 insertions(+), 134609 deletions(-)
And how is anyone else to make it into the kernel statistics top
contributors by lines changed list with stuff like this going in? :-)
g.
^ 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
* 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
* 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: [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: 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
* [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: [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
* 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: 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
* 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: [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: [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] 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: [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 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 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: 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: 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
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