* Re: [PATCH] Bug fix in commit 178db7d3 triggered a bug in the SPI driver for MPC83XX (pdata is NULL).
From: Joakim Tjernlund @ 2012-03-30 15:16 UTC (permalink / raw)
To: Kenth Eriksson; +Cc: spi-devel-general, linuxppc-dev
In-Reply-To: <1333119930-21129-1-git-send-email-kenth.eriksson@transmode.com>
Kenth Eriksson <kenth.eriksson@transmode.com> wrote on 2012/03/30 17:05:30:
>
> After commit 178db7d3 devices are initialized as children of the bus master, not children of the bus masters parent device. The pdata pointer used in fsl_spi_chipselect must updated to reflect the changed initialization.
>
> Signed-off-by: Kenth Eriksson <kenth.eriksson@transmode.com>
Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
^ permalink raw reply
* [PATCH] Bug fix in commit 178db7d3 triggered a bug in the SPI driver for MPC83XX (pdata is NULL).
From: Kenth Eriksson @ 2012-03-30 15:05 UTC (permalink / raw)
To: spi-devel-general, linuxppc-dev, joakim.tjernlund; +Cc: Kenth Eriksson
After commit 178db7d3 devices are initialized as children of the bus master, not children of the bus masters parent device. The pdata pointer used in fsl_spi_chipselect must updated to reflect the changed initialization.
Signed-off-by: Kenth Eriksson <kenth.eriksson@transmode.com>
---
drivers/spi/spi-fsl-spi.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/spi-fsl-spi.c b/drivers/spi/spi-fsl-spi.c
index 7d6ca68..dc747a0 100644
--- a/drivers/spi/spi-fsl-spi.c
+++ b/drivers/spi/spi-fsl-spi.c
@@ -139,10 +139,12 @@ static void fsl_spi_change_mode(struct spi_device *spi)
static void fsl_spi_chipselect(struct spi_device *spi, int value)
{
struct mpc8xxx_spi *mpc8xxx_spi = spi_master_get_devdata(spi->master);
- struct fsl_spi_platform_data *pdata = spi->dev.parent->platform_data;
+ struct fsl_spi_platform_data *pdata;
bool pol = spi->mode & SPI_CS_HIGH;
struct spi_mpc8xxx_cs *cs = spi->controller_state;
+ pdata = spi->dev.parent->parent->platform_data;
+
if (value == BITBANG_CS_INACTIVE) {
if (pdata->cs_control)
pdata->cs_control(spi, !pol);
--
1.7.3.4
^ permalink raw reply related
* Re: powerpc/85xx: p2020rdb - move the NAND address.
From: Sebastian Andrzej Siewior @ 2012-03-30 14:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: Bryan Hundven, linuxppc-dev
In-Reply-To: <9460468D-281C-4960-839A-F8435638DE4B@kernel.crashing.org>
On 03/29/2012 03:10 PM, Kumar Gala wrote:
>> - include/configs/P1_P2_RDB.h
>>
>> #ifndef CONFIG_NAND_SPL
>> #define CONFIG_SYS_NAND_BASE 0xffa00000
>> #ifdef CONFIG_PHYS_64BIT
>> #define CONFIG_SYS_NAND_BASE_PHYS 0xfffa00000ull
>> #else
>> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
>> #endif
>> #else
>> #define CONFIG_SYS_NAND_BASE 0xfff00000
>> #ifdef CONFIG_PHYS_64BIT
>> #define CONFIG_SYS_NAND_BASE_PHYS 0xffff00000ull
>> #else
>> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
>> #endif
>> #endif
>>
>> - include/configs/p1_p2_rdb_pc.h
>>
>> #ifdef CONFIG_NAND_FSL_ELBC
>> #define CONFIG_SYS_NAND_BASE 0xff800000
>> #ifdef CONFIG_PHYS_64BIT
>> #define CONFIG_SYS_NAND_BASE_PHYS 0xfff800000ull
>> #else
>> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
>> #endif
>>
>
> There are two (well 3 since rdb-pc has both 32b& 36b) in the tree now:
>
> arch/powerpc/boot/dts/p2020rdb.dts
> arch/powerpc/boot/dts/p2020rdb-pc_32b.dts
> arch/powerpc/boot/dts/p2020rdb-pc_36b.dts
Okay. So I assume that one has the proper NAND address and my patch
should be reverted then. Do want a patch from me for that?
>> Since both system have the same SoC and the NAND_SPL is always linked
>> against 0xfff00000 I don't see anything wrong to relocate the NAND CS
>> later to 0xff800000 (or to 0xffa00000) and having it consistent among
>> both configs.
what about this thing? Should leave it as it or move to the same
location? Since I have no HW *I* would prefer not to touch it :)
>
> - k
Sebastian
^ permalink raw reply
* Re: [PATCH 00/17] mark const init data with __initconst instead of __initdata
From: Uwe Kleine-König @ 2012-03-30 9:59 UTC (permalink / raw)
To: linux-kernel, Andrew Morton
Cc: Andrew Lunn, Christoph Lameter, linux-mips, Tony Lindgren,
Linus Walleij, Nicolas Ferre, Matthew Garrett,
platform-driver-x86, ibm-acpi-devel, Randy Dunlap, linux-mtd,
Sekhar Nori, Daniel Walker, lm-sensors, Klaus Kudielka,
Guenter Roeck, Kevin Hilman, linux-ia64, Kukjin Kim, Russell King,
Samuel Ortiz, Yoshinori Sato, Lennert Buytenhek, Kyungmin Park,
David Brown, Anatolij Gustschin, Jean-Christophe Plagniol-Villard,
Alexey Dobriyan, Joerg Reuter, linux-media, cbe-oss-dev,
Fenghua Yu, Arnd Bergmann, Tony Luck, Lucas De Marchi,
linux-arm-msm, Andreas Koensgen, Henrique de Moraes Holschuh,
Haojian Zhuang, Mauro Carvalho Chehab, Tejun Heo,
linux-samsung-soc, linux-mm, Barry Song, linux-hams, linux-omap,
Andrew Victor, linux-arm-kernel, David Howells,
davinci-linux-open-source, Jean-Paul Roubelat, Eric Miao,
Linus Walleij, linux-ide, linuxppc-dev, Nicolas Pitre,
Ralf Baechle, Tomasz Stanislawski, Bryan Huntsman, Sascha Hauer,
netdev, Jean Delvare, Paul Mackerras, Shawn Guo, David Woodhouse,
David S. Miller
In-Reply-To: <20120329211131.GA31250@pengutronix.de>
On Thu, Mar 29, 2012 at 11:11:31PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> this series fixes a common error to use __initdata to mark const
> variables. Most of the time this works well enough to go unnoticed
> (though I wonder why the linker doesn't warn about that).
> Just try adding something like
>
> int something __initdata;
>
> to one of the patched files and compile to see the error.
>
> While touching these annotations I also corrected the position where it
> was wrong to go between the variable name and the =.
>
> Note this series is not compile tested.
After a question by Shawn Guo I noticed that my command to do the changes
was to lax and changed things that must not be changed (at least not
with further care). Affected are lines like:
static const char *at91_dt_board_compat[] __initconst = {
While at91_dt_board_compat[0] is const, at91_dt_board_compat is not.
I will send a fixed series later today.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] powerpc: select PPC_CLOCK unconditionally for FSL_SOC
From: Shawn Guo @ 2012-03-30 5:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: alsa-devel, Shawn Guo, Timur Tabi
Freescale PowerPC SoCs share a number of IP blocks with Freescale
ARM/IMX SoCs, FlexCAN, SSI, FEC, eSDHC, USB, etc. There are some
effort consolidating those drivers to make them work for both
architectures.
One outstanding difference between two architectures is ARM/IMX will
turn off module clocks during platform initialization for power saving
and expects drivers manage clocks using clk API, while PowerPC
mostly does not do that, and thus does not always build in clk API.
Listing all those driver Kconfig options in "select PPC_CLOCK if" seems
not scalable for long term maintenance, and could easily introduce
Kconfig recursive dependency. This patch chooses to select PPC_CLOCK
unconditionally for FSL_SOC to always build clk API for PowerPC in.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
arch/powerpc/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index feab3ba..63fa7fb 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -661,7 +661,7 @@ config SBUS
config FSL_SOC
bool
select HAVE_CAN_FLEXCAN if NET && CAN
- select PPC_CLOCK if CAN_FLEXCAN
+ select PPC_CLOCK
config FSL_PCI
bool
--
1.7.5.4
^ permalink raw reply related
* RE: powerpc/85xx: p2020rdb - move the NAND address.
From: Bryan Hundven @ 2012-03-29 23:17 UTC (permalink / raw)
To: Kumar Gala, Sebastian Andrzej Siewior; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <5cfxnrfxtgpc584nns33030w.1333045723838@email.android.com>
[-- Attachment #1: Type: text/plain, Size: 3355 bytes --]
One final question on this change is: If the nand base address was wrong in the kernel, but right in u-boot, how did this work before this change and what kinds of problems would I see with the old base address value in the kernel.
Thanks for your time in advance,
-Bryan
________________________________
From: Bryan Hundven
Sent: Thursday, March 29, 2012 11:28 AM
To: Kumar Gala; Sebastian Andrzej Siewior
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: powerpc/85xx: p2020rdb - move the NAND address.
Kumar,
Sorry, i should have posted to the ml.
Thank you, I was looking in the wrong spot.
Cheers,
-Bryan
Kumar Gala <galak@kernel.crashing.org> wrote:
On Mar 29, 2012, at 2:26 AM, Sebastian Andrzej Siewior wrote:
> On 03/28/2012 10:30 PM, Bryan Hundven wrote:
>> > It is not at 0xffa00000. According to current u-boot source the NAND
>> > controller is always at 0xff800000 and it is either at CS0 or CS1
>> > depending on NAND or NAND+NOR mode. In 36bit mode it is shifted to
>> > 0xfff800000 but it has always an eight there and never an A.
>> >
>> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>
>> I am having a hard time verifying this change. I don't think you are
>> wrong, I'm just having a hard time following.
>>
>> I do not see where this has always been 0xff800000 in u-boot.
>
> <cut>
>
>> But while I was checking changes in arch/powerpc/, I found this change
>> and wanted to understand why 0xffa00000 has worked for us for so long?
>
> Kumar, I wasn't wrong entirely I just missed one detail. U-Boot
> provides two different configs, not just one define like its for
> SPL/SPI/...:
>
> - include/configs/P1_P2_RDB.h
>
> #ifndef CONFIG_NAND_SPL
> #define CONFIG_SYS_NAND_BASE 0xffa00000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS 0xfffa00000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
> #endif
> #else
> #define CONFIG_SYS_NAND_BASE 0xfff00000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS 0xffff00000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
> #endif
> #endif
>
> - include/configs/p1_p2_rdb_pc.h
>
> #ifdef CONFIG_NAND_FSL_ELBC
> #define CONFIG_SYS_NAND_BASE 0xff800000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS 0xfff800000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
> #endif
>
> and for kernel they use both the same device tree. So with the change,
> the _pc variant finds its flash. Before that it worked for the non-pc
> variant only if NAND_SPL wasn't used.
> Any suggestion on fixing that? Providing a new dt for _pc would "fix"
> it but the non pc variant won't find it in the case of NAND_SPL.
There are two (well 3 since rdb-pc has both 32b & 36b) in the tree now:
arch/powerpc/boot/dts/p2020rdb.dts
arch/powerpc/boot/dts/p2020rdb-pc_32b.dts
arch/powerpc/boot/dts/p2020rdb-pc_36b.dts
>
> Since both system have the same SoC and the NAND_SPL is always linked
> against 0xfff00000 I don't see anything wrong to relocate the NAND CS
> later to 0xff800000 (or to 0xffa00000) and having it consistent among
> both configs.
- k
[-- Attachment #2: Type: text/html, Size: 5272 bytes --]
^ permalink raw reply
* Re: [GIT PULL] Disintegrate and kill asm/system.h
From: Grant Likely @ 2012-03-29 22:16 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-arch, Stephen Rothwell, Michael Neuling, arnd, ppc-dev,
linux-kernel, David Howells, paul.gortmaker, hpa, akpm,
Linus Torvalds
In-Reply-To: <alpine.LFD.2.02.1203292344140.2542@ionos>
On Thu, Mar 29, 2012 at 3:48 PM, Thomas Gleixner <tglx@linutronix.de> wrote=
:
> On Thu, 29 Mar 2012, Grant Likely wrote:
>> On Thu, Mar 29, 2012 at 2:11 AM, Benjamin Herrenschmidt
>> The rightmost fields of /proc/interrupts are a weird set of
>> conditional outputs that don't really have any parsable formatting to
>> them. =A0It may be safe to apply my patch because it adds another field
>> in the middle of a section of conditional outputs* anyway so tools
>> already won't know what those fields mean. =A0But, regardless, I'm not
>> going to take responsibility for applying that patch unless encouraged
>> by several other maintainers to do so.
>
> Go ahead. We changed that output several times in the last years
> without causing the end of the universe.
Okay, RFC patch sent. I'm okay to wait for v3.5 for this, but it can
go into v3.4 if anyone really wants it faster.
g.
^ permalink raw reply
* Re: [GIT PULL] Disintegrate and kill asm/system.h
From: Thomas Gleixner @ 2012-03-29 21:48 UTC (permalink / raw)
To: Grant Likely
Cc: linux-arch, Stephen Rothwell, Michael Neuling, arnd, ppc-dev,
linux-kernel, David Howells, paul.gortmaker, hpa, akpm,
Linus Torvalds
In-Reply-To: <CACxGe6v+nMMuEM+bBMdYf_OeuaXb+NsS0qz-+puRtdzHLPH2hA@mail.gmail.com>
On Thu, 29 Mar 2012, Grant Likely wrote:
> On Thu, Mar 29, 2012 at 2:11 AM, Benjamin Herrenschmidt
> The rightmost fields of /proc/interrupts are a weird set of
> conditional outputs that don't really have any parsable formatting to
> them. It may be safe to apply my patch because it adds another field
> in the middle of a section of conditional outputs* anyway so tools
> already won't know what those fields mean. But, regardless, I'm not
> going to take responsibility for applying that patch unless encouraged
> by several other maintainers to do so.
Go ahead. We changed that output several times in the last years
without causing the end of the universe.
Thanks,
tglx
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git next branch
From: Tabi Timur-B04825 @ 2012-03-29 21:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <alpine.LFD.2.02.1203291544170.14273@spiff>
On Thu, Mar 29, 2012 at 3:44 PM, Kumar Gala <galak@kernel.crashing.org> wro=
te:
>
> A few minor bug fixes and missing dts updates for 3.4. =A0There got lost =
in
> the mix. =A0Sorry for the delay
What about my "don't call of_platform_bus_probe() twice" patch?
That's still an important fix for the P1022DS.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [GIT PULL] Disintegrate and kill asm/system.h
From: Grant Likely @ 2012-03-29 21:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-arch, Stephen Rothwell, Michael Neuling, arnd, ppc-dev,
linux-kernel, David Howells, paul.gortmaker, hpa, akpm,
Linus Torvalds
In-Reply-To: <1333008684.3010.9.camel@pasglop>
On Thu, Mar 29, 2012 at 2:11 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2012-03-28 at 22:02 -0700, Linus Torvalds wrote:
>> On Wed, Mar 28, 2012 at 9:42 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> >
>> > How about this (build tested on powerpc allyesconfig):
>>
>> Looks better.
>>
>> Grant - what's the plan about that CONFIG_VIRQ_DEBUG thing? In theory
>> something like it could be useful as a generic thing, but at least
>> right now it is clearly powerpc-specific (not just that the config
>> option only exists for powerpc: it has that whole
>> 'powerpc_debugfs_root' thing in it)?
>>
>> Stephen's patch very much looks like the right thing, but if there was
>> some plan to actually make this generic ...
>
> Yes, as I said earlier I think Grant should make it generic, there's
> no reason to keep that powerpc specific, it's fairly useful and nothing
> in userspace relies on the existing location of the debugfs file that I
> know about.
>
> Another option is to put the mapping information in /proc/interrupts but
> worry that changing anything in there (like adding a column) will break
> countless userspace tools.
I posted an RFC patch that does exactly that, but I'm similarly
nervous for the same reason:
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg56368.html
The rightmost fields of /proc/interrupts are a weird set of
conditional outputs that don't really have any parsable formatting to
them. It may be safe to apply my patch because it adds another field
in the middle of a section of conditional outputs* anyway so tools
already won't know what those fields mean. But, regardless, I'm not
going to take responsibility for applying that patch unless encouraged
by several other maintainers to do so.
*It's added to the middle instead of the end purely for aesthetic
reasons. The rightmost field is a freeform string without a field
width, so if put at the end they would never line up. Suggestions for
a better layout are welcome.
g.
^ permalink raw reply
* [PATCH 11/17] powerpc: mark const init data with __initconst instead of __initdata
From: Uwe Kleine-König @ 2012-03-29 21:12 UTC (permalink / raw)
To: linux-kernel, Andrew Morton
Cc: cbe-oss-dev, Arnd Bergmann, Paul Mackerras, kernel,
Anatolij Gustschin, linuxppc-dev
In-Reply-To: <20120329211131.GA31250@pengutronix.de>
As long as there is no other non-const variable marked __initdata in the
same compilation unit it doesn't hurt. If there were one however
compilation would fail with
error: $variablename causes a section type conflict
because a section containing const variables is marked read only and so
cannot contain non-const variables.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Josh Boyer <jwboyer@gmail.com>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: cbe-oss-dev@lists.ozlabs.org
---
arch/powerpc/platforms/40x/ppc40x_simple.c | 2 +-
arch/powerpc/platforms/512x/mpc5121_generic.c | 2 +-
arch/powerpc/platforms/52xx/lite5200.c | 2 +-
arch/powerpc/platforms/52xx/media5200.c | 2 +-
arch/powerpc/platforms/52xx/mpc5200_simple.c | 2 +-
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 2 +-
arch/powerpc/platforms/83xx/mpc830x_rdb.c | 2 +-
arch/powerpc/platforms/83xx/mpc831x_rdb.c | 2 +-
arch/powerpc/platforms/83xx/mpc837x_rdb.c | 2 +-
arch/powerpc/platforms/85xx/tqm85xx.c | 2 +-
arch/powerpc/platforms/cell/qpace_setup.c | 2 +-
arch/powerpc/platforms/cell/setup.c | 2 +-
12 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/40x/ppc40x_simple.c b/arch/powerpc/platforms/40x/ppc40x_simple.c
index 9761206..2efba25 100644
--- a/arch/powerpc/platforms/40x/ppc40x_simple.c
+++ b/arch/powerpc/platforms/40x/ppc40x_simple.c
@@ -50,7 +50,7 @@ machine_device_initcall(ppc40x_simple, ppc40x_device_probe);
* Again, if your board needs to do things differently then create a
* board.c file for it rather than adding it to this list.
*/
-static const char *board[] __initdata = {
+static const char *board[] __initconst = {
"amcc,acadia",
"amcc,haleakala",
"amcc,kilauea",
diff --git a/arch/powerpc/platforms/512x/mpc5121_generic.c b/arch/powerpc/platforms/512x/mpc5121_generic.c
index 926731f..b1b558c 100644
--- a/arch/powerpc/platforms/512x/mpc5121_generic.c
+++ b/arch/powerpc/platforms/512x/mpc5121_generic.c
@@ -26,7 +26,7 @@
/*
* list of supported boards
*/
-static const char *board[] __initdata = {
+static const char *board[] __initconst = {
"prt,prtlvt",
NULL
};
diff --git a/arch/powerpc/platforms/52xx/lite5200.c b/arch/powerpc/platforms/52xx/lite5200.c
index 01ffa64..86bd6f2 100644
--- a/arch/powerpc/platforms/52xx/lite5200.c
+++ b/arch/powerpc/platforms/52xx/lite5200.c
@@ -172,7 +172,7 @@ static void __init lite5200_setup_arch(void)
mpc52xx_setup_pci();
}
-static const char *board[] __initdata = {
+static const char *board[] __initconst = {
"fsl,lite5200",
"fsl,lite5200b",
NULL,
diff --git a/arch/powerpc/platforms/52xx/media5200.c b/arch/powerpc/platforms/52xx/media5200.c
index 17d91b7..df4d53a 100644
--- a/arch/powerpc/platforms/52xx/media5200.c
+++ b/arch/powerpc/platforms/52xx/media5200.c
@@ -232,7 +232,7 @@ static void __init media5200_setup_arch(void)
}
/* list of the supported boards */
-static const char *board[] __initdata = {
+static const char *board[] __initconst = {
"fsl,media5200",
NULL
};
diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c b/arch/powerpc/platforms/52xx/mpc5200_simple.c
index c0aa040..2622361 100644
--- a/arch/powerpc/platforms/52xx/mpc5200_simple.c
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
@@ -49,7 +49,7 @@ static void __init mpc5200_simple_setup_arch(void)
}
/* list of the supported boards */
-static const char *board[] __initdata = {
+static const char *board[] __initconst = {
"anonymous,a4m072",
"anon,charon",
"intercontrol,digsy-mtc",
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pci.c b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
index bfb11e0..e2d401a 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pci.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pci.c
@@ -93,7 +93,7 @@ struct mpc52xx_pci {
};
/* MPC5200 device tree match tables */
-const struct of_device_id mpc52xx_pci_ids[] __initdata = {
+const struct of_device_id mpc52xx_pci_ids[] __initconst = {
{ .type = "pci", .compatible = "fsl,mpc5200-pci", },
{ .type = "pci", .compatible = "mpc5200-pci", },
{}
diff --git a/arch/powerpc/platforms/83xx/mpc830x_rdb.c b/arch/powerpc/platforms/83xx/mpc830x_rdb.c
index 4f2d9fe..3327ab9 100644
--- a/arch/powerpc/platforms/83xx/mpc830x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc830x_rdb.c
@@ -34,7 +34,7 @@ static void __init mpc830x_rdb_setup_arch(void)
mpc831x_usb_cfg();
}
-static const char *board[] __initdata = {
+static const char *board[] __initconst = {
"MPC8308RDB",
"fsl,mpc8308rdb",
"denx,mpc8308_p1m",
diff --git a/arch/powerpc/platforms/83xx/mpc831x_rdb.c b/arch/powerpc/platforms/83xx/mpc831x_rdb.c
index fa25977..067d3f0 100644
--- a/arch/powerpc/platforms/83xx/mpc831x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc831x_rdb.c
@@ -35,7 +35,7 @@ static void __init mpc831x_rdb_setup_arch(void)
mpc831x_usb_cfg();
}
-static const char *board[] __initdata = {
+static const char *board[] __initconst = {
"MPC8313ERDB",
"fsl,mpc8315erdb",
NULL
diff --git a/arch/powerpc/platforms/83xx/mpc837x_rdb.c b/arch/powerpc/platforms/83xx/mpc837x_rdb.c
index 16c9c9c..a9a15bb 100644
--- a/arch/powerpc/platforms/83xx/mpc837x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc837x_rdb.c
@@ -60,7 +60,7 @@ static void __init mpc837x_rdb_setup_arch(void)
machine_device_initcall(mpc837x_rdb, mpc83xx_declare_of_platform_devices);
-static const char *board[] __initdata = {
+static const char *board[] __initconst = {
"fsl,mpc8377rdb",
"fsl,mpc8378rdb",
"fsl,mpc8379rdb",
diff --git a/arch/powerpc/platforms/85xx/tqm85xx.c b/arch/powerpc/platforms/85xx/tqm85xx.c
index 4d786c2..c182de0 100644
--- a/arch/powerpc/platforms/85xx/tqm85xx.c
+++ b/arch/powerpc/platforms/85xx/tqm85xx.c
@@ -125,7 +125,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_1520,
machine_device_initcall(tqm85xx, mpc85xx_common_publish_devices);
-static const char *board[] __initdata = {
+static const char *board[] __initconst = {
"tqc,tqm8540",
"tqc,tqm8541",
"tqc,tqm8548",
diff --git a/arch/powerpc/platforms/cell/qpace_setup.c b/arch/powerpc/platforms/cell/qpace_setup.c
index 7f9b674..6e3409d 100644
--- a/arch/powerpc/platforms/cell/qpace_setup.c
+++ b/arch/powerpc/platforms/cell/qpace_setup.c
@@ -61,7 +61,7 @@ static void qpace_progress(char *s, unsigned short hex)
printk("*** %04x : %s\n", hex, s ? s : "");
}
-static const struct of_device_id qpace_bus_ids[] __initdata = {
+static const struct of_device_id qpace_bus_ids[] __initconst = {
{ .type = "soc", },
{ .compatible = "soc", },
{ .type = "spider", },
diff --git a/arch/powerpc/platforms/cell/setup.c b/arch/powerpc/platforms/cell/setup.c
index fa3e294..4ab0876 100644
--- a/arch/powerpc/platforms/cell/setup.c
+++ b/arch/powerpc/platforms/cell/setup.c
@@ -140,7 +140,7 @@ static int __devinit cell_setup_phb(struct pci_controller *phb)
return 0;
}
-static const struct of_device_id cell_bus_ids[] __initdata = {
+static const struct of_device_id cell_bus_ids[] __initconst = {
{ .type = "soc", },
{ .compatible = "soc", },
{ .type = "spider", },
--
1.7.9.1
^ permalink raw reply related
* [PATCH 00/17] mark const init data with __initconst instead of __initdata
From: Uwe Kleine-König @ 2012-03-29 21:11 UTC (permalink / raw)
To: linux-kernel, Andrew Morton
Cc: Andrew Lunn, Christoph Lameter, linux-mips, Tony Lindgren,
Linus Walleij, Nicolas Ferre, Matthew Garrett,
platform-driver-x86, ibm-acpi-devel, Randy Dunlap, linux-mtd,
Sekhar Nori, Daniel Walker, lm-sensors, Klaus Kudielka,
Guenter Roeck, Kevin Hilman, linux-ia64, Kukjin Kim, Russell King,
Samuel Ortiz, Yoshinori Sato, Lennert Buytenhek, Kyungmin Park,
David Brown, Anatolij Gustschin, Jean-Christophe Plagniol-Villard,
Alexey Dobriyan, Joerg Reuter, linux-media, cbe-oss-dev,
Fenghua Yu, Arnd Bergmann, Tony Luck, Lucas De Marchi,
linux-arm-msm, Andreas Koensgen, Henrique de Moraes Holschuh,
Haojian Zhuang, Mauro Carvalho Chehab, Tejun Heo,
linux-samsung-soc, linux-mm, Barry Song, linux-hams, linux-omap,
Andrew Victor, linux-arm-kernel, David Howells,
davinci-linux-open-source, Jean-Paul Roubelat, Eric Miao,
Linus Walleij, linux-ide, linuxppc-dev, Nicolas Pitre,
Ralf Baechle, Tomasz Stanislawski, Bryan Huntsman, Sascha Hauer,
netdev, Jean Delvare, Paul Mackerras, Shawn Guo, David Woodhouse,
David S. Miller
Hello,
this series fixes a common error to use __initdata to mark const
variables. Most of the time this works well enough to go unnoticed
(though I wonder why the linker doesn't warn about that).
Just try adding something like
int something __initdata;
to one of the patched files and compile to see the error.
While touching these annotations I also corrected the position where it
was wrong to go between the variable name and the =.
Note this series is not compile tested.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [git pull] Please pull powerpc.git next branch
From: Kumar Gala @ 2012-03-29 20:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Ben,
A few minor bug fixes and missing dts updates for 3.4. There got lost in
the mix. Sorry for the delay
- k
The following changes since commit 1ce447b90f3e71c81ae59e0062bc305ef267668b:
powerpc/perf: Fix instruction address sampling on 970 and Power4 (2012-03-28 11:33:24 +1100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git next
Dave Liu (1):
powerpc/qe: Update the SNUM table for MPC8569 Rev2.0
Diana CRACIUN (1):
powerpc/dts: Removed fsl,msi property from dts.
Jerry Huang (2):
powerpc/85xx: add the P1020MBG-PC DTS support
powerpc/85xx: add the P1020UTM-PC DTS support
Shaveta Leekha (1):
powerpc/85xx: Enable I2C_CHARDEV and I2C_MPC options in defconfigs
Timur Tabi (2):
powerpc/8xxx: remove 85xx/86xx restrictions from fsl_guts.h
powerpc/epapr: add "memory" as a clobber to all hypercalls
arch/powerpc/boot/dts/p1020mbg-pc.dtsi | 151 ++++++++++++++++++++++++++
arch/powerpc/boot/dts/p1020mbg-pc_32b.dts | 89 +++++++++++++++
arch/powerpc/boot/dts/p1020mbg-pc_36b.dts | 89 +++++++++++++++
arch/powerpc/boot/dts/p1020utm-pc.dtsi | 140 ++++++++++++++++++++++++
arch/powerpc/boot/dts/p1020utm-pc_32b.dts | 89 +++++++++++++++
arch/powerpc/boot/dts/p1020utm-pc_36b.dts | 89 +++++++++++++++
arch/powerpc/boot/dts/p2041rdb.dts | 3 -
arch/powerpc/boot/dts/p3041ds.dts | 4 -
arch/powerpc/boot/dts/p3060qds.dts | 2 -
arch/powerpc/boot/dts/p4080ds.dts | 3 -
arch/powerpc/boot/dts/p5020ds.dts | 4 -
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
arch/powerpc/configs/corenet64_smp_defconfig | 2 +
arch/powerpc/configs/mpc85xx_defconfig | 1 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
arch/powerpc/include/asm/epapr_hcalls.h | 7 +-
arch/powerpc/include/asm/fsl_guts.h | 26 +----
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 2 +-
arch/powerpc/platforms/85xx/p1022_ds.c | 4 +-
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 2 +-
arch/powerpc/sysdev/qe_lib/qe.c | 22 ++++-
drivers/net/ethernet/freescale/ucc_geth.c | 6 +-
sound/soc/fsl/mpc8610_hpcd.c | 8 +-
sound/soc/fsl/p1022_ds.c | 10 +-
25 files changed, 701 insertions(+), 56 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p1020mbg-pc.dtsi
create mode 100644 arch/powerpc/boot/dts/p1020mbg-pc_32b.dts
create mode 100644 arch/powerpc/boot/dts/p1020mbg-pc_36b.dts
create mode 100644 arch/powerpc/boot/dts/p1020utm-pc.dtsi
create mode 100644 arch/powerpc/boot/dts/p1020utm-pc_32b.dts
create mode 100644 arch/powerpc/boot/dts/p1020utm-pc_36b.dts
^ permalink raw reply
* Re: Help initialize phy-less ethernet in 2.6.38
From: Scott Wood @ 2012-03-29 20:30 UTC (permalink / raw)
To: Fabio; +Cc: Andy Fleming, linuxppc-dev
In-Reply-To: <CAP-cLV5hAT8sp7uxy5o3_NOw5xoAvoz-rV04zB4pmULSp3pXcg@mail.gmail.com>
On 03/29/2012 02:56 PM, Fabio wrote:
>> Which old kernel driver? Why do you need to mess with fs_platform_info?
> I have to port a custom platform driver written for 2.6.10 to support
> this custom board.
So it's old arch/ppc stuff. Now fs_platform_info is driver-internal and
info comes from the device tree. You shouldn't touch the struct directly.
>> Why do you think the interrupt is misconfigured?
> Because I don't get any error during boot or when I run ifconfig, but
> I don't see
> any interrupt if I run 'cat /proc/interrupts':
That could mean that something else is failing, such that you don't
have the activity that would cause an interrupt.
>> Looking at the code, though, I'm not sure if this stuff still works --
>> e.g. I don't see where any fields of fixed-link but the ID are used, or
>> what's supposed to happen when of_phy_connect_fixed_link() calls
>> phy_connect().
> If it isn't so, do you have any suggestion about how to re-add this
> functionality to the existing code?
Andy, do you know what the state of this stuff is?
-Scott
^ permalink raw reply
* Re: Help initialize phy-less ethernet in 2.6.38
From: Fabio @ 2012-03-29 19:56 UTC (permalink / raw)
To: Scott Wood; +Cc: Andy Fleming, linuxppc-dev
In-Reply-To: <4F74AB70.7070209@freescale.com>
> Which old kernel driver? =C2=A0Why do you need to mess with fs_platform_i=
nfo?
I have to port a custom platform driver written for 2.6.10 to support
this custom board.
That driver directly initializes the fs_platform_info data structure,
so after some failed attempts I thought to directly assign some values
to the fs_platform_info structure to see reuse part of the old code,
just to get the device to work.
> Why do you think the interrupt is misconfigured?
Because I don't get any error during boot or when I run ifconfig, but
I don't see
any interrupt if I run 'cat /proc/interrupts':
---
CPU0
16: 136 CPM2 SIU Level cpm_uart
32: 0 CPM2 SIU Level fs_enet-mac
LOC: 1219 Local timer interrupts
SPU: 0 Spurious interrupts
CNT: 0 Performance monitoring interrupts
MCE: 0 Machine check exceptions
----
>Looking at the code, though, I'm not sure if this stuff still works --
>e.g. I don't see where any fields of fixed-link but the ID are used, or
>what's supposed to happen when of_phy_connect_fixed_link() calls
>phy_connect().
If it isn't so, do you have any suggestion about how to re-add this
functionality to the existing code?
I will make some other tests taking as an example the mgcoge.dts which
seems the most similar to my custom board.
Thanks in advance,
--=20
Fabio Pozzi
^ permalink raw reply
* Re: Help initialize phy-less ethernet in 2.6.38
From: Scott Wood @ 2012-03-29 18:35 UTC (permalink / raw)
To: Fabio; +Cc: Andy Fleming, linuxppc-dev
In-Reply-To: <CAP-cLV5pF-j_izadBSVD7p4hQte96O_g2udCxi=9tkaPwxEsaw@mail.gmail.com>
On 03/28/2012 11:13 AM, Fabio wrote:
> Hi all,
> I am a newbie trying to get the FCC1 ethernet interface to work on a
> custom board.
> The hardware used is based on mpc8270 which is connected via FCC1 to a
> phy-less interface linked to another microcontroller.
> FCC1 should be recognized as eth0 by the linux kernel and it should
> receive data when set up in promiscuous mode.
> Currently during the boot it seems that the device initialization goes
> ok but I can't understand why I can't receive data when I put the
> interface in promiscuous mode.
Is the problem only with promiscuous mode, or do you have problems with
normal operation as well (receiving broadcast packets and packets
addressed to you, sending pakcets, etc)?
> Going into details I can see that the fs_enet probe function gets called.
> I customized it to setup the fs_platform_info structure using the
> values taken from the old kernel driver for now.
Which old kernel driver? Why do you need to mess with fs_platform_info?
> The only fields I cannot setup are the bus_id,phy_irq,phy_addr because
> they are not part of the fs_platform_info data structure anymore.
All this stuff comes from the device tree.
> I can't see any errors during the initialization, but I can't receive
> data on the interface.
>
> I think the problem can be in an interrupt misconfiguration but I
> haven't figured out how to configure the ethernet dts part in the
> right way or how to handle the phy-less situation correctly.
Why do you think the interrupt is misconfigured?
For phy-less you should have a fixed-link property. For some reason
this property is documented only in
Documentation/devicetree/bindings/net/fsl-tsec-phy.txt, but it is
applicable here as well.
Looking at the code, though, I'm not sure if this stuff still works --
e.g. I don't see where any fields of fixed-link but the ID are used, or
what's supposed to happen when of_phy_connect_fixed_link() calls
phy_connect().
> --- dts snippet ---
> eth0: ethernet@11300 {
> device_type = "network";
> compatible = "fsl,cpm2-fcc-enet";
> reg = <0x11300 0x20 0x8400 0x100 0x11390 0x1>;
> local-mac-address = [ 00 01 02 03 04 05 ];
> interrupts = <32 8>;
> interrupt-parent = <&PIC>;
> linux,network-index = <0>;
> fsl,cpm-command = <0x12000300>;
> };
Some of this stuff shouldn't be needed anymore (device-type,
linux,network-index), and you should use a real MAC address, but
otherwise this looks right.
-Scott
^ permalink raw reply
* Re: powerpc/85xx: p2020rdb - move the NAND address.
From: Bryan Hundven @ 2012-03-29 18:28 UTC (permalink / raw)
To: Kumar Gala, Sebastian Andrzej Siewior; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <9460468D-281C-4960-839A-F8435638DE4B@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2838 bytes --]
Kumar,
Sorry, i should have posted to the ml.
Thank you, I was looking in the wrong spot.
Cheers,
-Bryan
Kumar Gala <galak@kernel.crashing.org> wrote:
On Mar 29, 2012, at 2:26 AM, Sebastian Andrzej Siewior wrote:
> On 03/28/2012 10:30 PM, Bryan Hundven wrote:
>> > It is not at 0xffa00000. According to current u-boot source the NAND
>> > controller is always at 0xff800000 and it is either at CS0 or CS1
>> > depending on NAND or NAND+NOR mode. In 36bit mode it is shifted to
>> > 0xfff800000 but it has always an eight there and never an A.
>> >
>> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>
>> I am having a hard time verifying this change. I don't think you are
>> wrong, I'm just having a hard time following.
>>
>> I do not see where this has always been 0xff800000 in u-boot.
>
> <cut>
>
>> But while I was checking changes in arch/powerpc/, I found this change
>> and wanted to understand why 0xffa00000 has worked for us for so long?
>
> Kumar, I wasn't wrong entirely I just missed one detail. U-Boot
> provides two different configs, not just one define like its for
> SPL/SPI/...:
>
> - include/configs/P1_P2_RDB.h
>
> #ifndef CONFIG_NAND_SPL
> #define CONFIG_SYS_NAND_BASE 0xffa00000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS 0xfffa00000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
> #endif
> #else
> #define CONFIG_SYS_NAND_BASE 0xfff00000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS 0xffff00000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
> #endif
> #endif
>
> - include/configs/p1_p2_rdb_pc.h
>
> #ifdef CONFIG_NAND_FSL_ELBC
> #define CONFIG_SYS_NAND_BASE 0xff800000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS 0xfff800000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
> #endif
>
> and for kernel they use both the same device tree. So with the change,
> the _pc variant finds its flash. Before that it worked for the non-pc
> variant only if NAND_SPL wasn't used.
> Any suggestion on fixing that? Providing a new dt for _pc would "fix"
> it but the non pc variant won't find it in the case of NAND_SPL.
There are two (well 3 since rdb-pc has both 32b & 36b) in the tree now:
arch/powerpc/boot/dts/p2020rdb.dts
arch/powerpc/boot/dts/p2020rdb-pc_32b.dts
arch/powerpc/boot/dts/p2020rdb-pc_36b.dts
>
> Since both system have the same SoC and the NAND_SPL is always linked
> against 0xfff00000 I don't see anything wrong to relocate the NAND CS
> later to 0xff800000 (or to 0xffa00000) and having it consistent among
> both configs.
- k
[-- Attachment #2: Type: text/html, Size: 4345 bytes --]
^ permalink raw reply
* Re: why use 'raw_spin_lock_irqsave' inf function 'of_find_node_with_property'
From: Tabi Timur-B04825 @ 2012-03-29 15:48 UTC (permalink / raw)
To: Huang Changming-R66093; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <110EED8CC96DFC488B7E717A2027A27C05F5BA@039-SN1MPN1-003.039d.mgd.msft.net>
On Thu, Mar 29, 2012 at 5:01 AM, Huang Changming-R66093
<r66093@freescale.com> wrote:
> Hi, all
>
> In function =93of_find_node_with_property=94, why use =93raw_spin_lock_ir=
qsave=94 to
> disable preemption and disable interrupt?
Where do you see raw_spin_lock_irqsave?
struct device_node *of_find_node_with_property(struct device_node *from,
const char *prop_name)
{
struct device_node *np;
struct property *pp;
read_lock(&devtree_lock);
np =3D from ? from->allnext : allnodes;
for (; np; np =3D np->allnext) {
for (pp =3D np->properties; pp !=3D 0; pp =3D pp->next) {
if (of_prop_cmp(pp->name, prop_name) =3D=3D 0) {
of_node_get(np);
goto out;
}
}
}
out:
of_node_put(from);
read_unlock(&devtree_lock);
return np;
}
We need a lock so that we don't parse the tree while it's being
modified. That would cause the for-loop to fail in strange ways.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCHv2 02/14] X86 & IA64: adapt for dma_map_ops changes
From: Thomas Gleixner @ 2012-03-29 13:51 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-mips, Kevin Cernekee, linux-ia64, linux-sh, linux-mm,
sparclinux, Guan Xuetao, linux-arch, Stephen Rothwell,
Jonathan Corbet, x86, Matt Turner, Dezhong Diao, Fenghua Yu,
Arnd Bergmann, microblaze-uclinux, linaro-mm-sig, Ivan Kokshaysky,
Andrzej Pietrasiewicz, linux-arm-kernel, Richard Henderson,
discuss, Michal Simek, Tony Luck, linux-kernel, Richard Kuo,
FUJITA Tomonori, Kyungmin Park, Paul Mundt, linux-alpha,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <1332855768-32583-3-git-send-email-m.szyprowski@samsung.com>
On Tue, 27 Mar 2012, Marek Szyprowski wrote:
> From: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
> -static inline void *dma_alloc_coherent(struct device *dev, size_t size,
> - dma_addr_t *daddr, gfp_t gfp)
> +#define dma_alloc_coherent(d,s,h,f) dma_alloc_attrs(d,s,h,f,NULL)
Please make this an inline function.
>
> +#define dma_alloc_coherent(d,s,h,f) dma_alloc_attrs(d,s,h,f,NULL)
Inline please.
> -static inline void dma_free_coherent(struct device *dev, size_t size,
> - void *vaddr, dma_addr_t bus)
> +#define dma_free_coherent(d,s,c,h) dma_free_attrs(d,s,c,h,NULL)
Ditto
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Thanks,
tglx
^ permalink raw reply
* Re: powerpc/85xx: p2020rdb - move the NAND address.
From: Kumar Gala @ 2012-03-29 13:10 UTC (permalink / raw)
To: Sebastian Andrzej Siewior; +Cc: Bryan Hundven, linuxppc-dev
In-Reply-To: <4F740E98.50104@linutronix.de>
On Mar 29, 2012, at 2:26 AM, Sebastian Andrzej Siewior wrote:
> On 03/28/2012 10:30 PM, Bryan Hundven wrote:
>> > It is not at 0xffa00000. According to current u-boot source the NAND
>> > controller is always at 0xff800000 and it is either at CS0 or CS1
>> > depending on NAND or NAND+NOR mode. In 36bit mode it is shifted to
>> > 0xfff800000 but it has always an eight there and never an A.
>> >
>> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>
>> I am having a hard time verifying this change. I don't think you are
>> wrong, I'm just having a hard time following.
>>
>> I do not see where this has always been 0xff800000 in u-boot.
>
> <cut>
>
>> But while I was checking changes in arch/powerpc/, I found this change
>> and wanted to understand why 0xffa00000 has worked for us for so long?
>
> Kumar, I wasn't wrong entirely I just missed one detail. U-Boot
> provides two different configs, not just one define like its for
> SPL/SPI/...:
>
> - include/configs/P1_P2_RDB.h
>
> #ifndef CONFIG_NAND_SPL
> #define CONFIG_SYS_NAND_BASE 0xffa00000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS 0xfffa00000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
> #endif
> #else
> #define CONFIG_SYS_NAND_BASE 0xfff00000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS 0xffff00000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
> #endif
> #endif
>
> - include/configs/p1_p2_rdb_pc.h
>
> #ifdef CONFIG_NAND_FSL_ELBC
> #define CONFIG_SYS_NAND_BASE 0xff800000
> #ifdef CONFIG_PHYS_64BIT
> #define CONFIG_SYS_NAND_BASE_PHYS 0xfff800000ull
> #else
> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
> #endif
>
> and for kernel they use both the same device tree. So with the change,
> the _pc variant finds its flash. Before that it worked for the non-pc
> variant only if NAND_SPL wasn't used.
> Any suggestion on fixing that? Providing a new dt for _pc would "fix"
> it but the non pc variant won't find it in the case of NAND_SPL.
There are two (well 3 since rdb-pc has both 32b & 36b) in the tree now:
arch/powerpc/boot/dts/p2020rdb.dts
arch/powerpc/boot/dts/p2020rdb-pc_32b.dts
arch/powerpc/boot/dts/p2020rdb-pc_36b.dts
>
> Since both system have the same SoC and the NAND_SPL is always linked
> against 0xfff00000 I don't see anything wrong to relocate the NAND CS
> later to 0xff800000 (or to 0xffa00000) and having it consistent among
> both configs.
- k
^ permalink raw reply
* why use 'raw_spin_lock_irqsave' inf function 'of_find_node_with_property'
From: Huang Changming-R66093 @ 2012-03-29 10:01 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 480 bytes --]
Hi, all
In function "of_find_node_with_property", why use "raw_spin_lock_irqsave" to disable preemption and disable interrupt?
If enable them, what impact will be observed?
This function just finds the node from the DTS file, it can't be interrupted or preempted?
I have done one test: remove "raw_spin_lock_irqsave" and "raw_spin_unlock_irqrestore" from this function,
It seems there is no any bad result, the Linux kernel still work well.
Best Regards
Jerry Huang
[-- Attachment #2: Type: text/html, Size: 2660 bytes --]
^ permalink raw reply
* Re: [GIT PULL] Disintegrate and kill asm/system.h
From: Benjamin Herrenschmidt @ 2012-03-29 8:11 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-arch, Stephen Rothwell, Michael Neuling, arnd, linux-kernel,
David Howells, paul.gortmaker, hpa, akpm, ppc-dev
In-Reply-To: <CA+55aFzjQ7qb=bPAj_gGoGLPXOGweTaqtmOBZH4mUt8E_KQwsg@mail.gmail.com>
On Wed, 2012-03-28 at 22:02 -0700, Linus Torvalds wrote:
> On Wed, Mar 28, 2012 at 9:42 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > How about this (build tested on powerpc allyesconfig):
>
> Looks better.
>
> Grant - what's the plan about that CONFIG_VIRQ_DEBUG thing? In theory
> something like it could be useful as a generic thing, but at least
> right now it is clearly powerpc-specific (not just that the config
> option only exists for powerpc: it has that whole
> 'powerpc_debugfs_root' thing in it)?
>
> Stephen's patch very much looks like the right thing, but if there was
> some plan to actually make this generic ...
Yes, as I said earlier I think Grant should make it generic, there's
no reason to keep that powerpc specific, it's fairly useful and nothing
in userspace relies on the existing location of the debugfs file that I
know about.
Another option is to put the mapping information in /proc/interrupts but
worry that changing anything in there (like adding a column) will break
countless userspace tools.
Cheers,
Ben.
^ permalink raw reply
* Re: powerpc/85xx: p2020rdb - move the NAND address.
From: Sebastian Andrzej Siewior @ 2012-03-29 7:26 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev; +Cc: Bryan Hundven
In-Reply-To: <E9CCADB024EDCD44A9C1083605680C42B9053302@ES05CO.wgti.net>
On 03/28/2012 10:30 PM, Bryan Hundven wrote:
> > It is not at 0xffa00000. According to current u-boot source the NAND
> > controller is always at 0xff800000 and it is either at CS0 or CS1
> > depending on NAND or NAND+NOR mode. In 36bit mode it is shifted to
> > 0xfff800000 but it has always an eight there and never an A.
> >
> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> I am having a hard time verifying this change. I don't think you are
> wrong, I'm just having a hard time following.
>
> I do not see where this has always been 0xff800000 in u-boot.
<cut>
> But while I was checking changes in arch/powerpc/, I found this change
> and wanted to understand why 0xffa00000 has worked for us for so long?
Kumar, I wasn't wrong entirely I just missed one detail. U-Boot
provides two different configs, not just one define like its for
SPL/SPI/...:
- include/configs/P1_P2_RDB.h
#ifndef CONFIG_NAND_SPL
#define CONFIG_SYS_NAND_BASE 0xffa00000
#ifdef CONFIG_PHYS_64BIT
#define CONFIG_SYS_NAND_BASE_PHYS 0xfffa00000ull
#else
#define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
#endif
#else
#define CONFIG_SYS_NAND_BASE 0xfff00000
#ifdef CONFIG_PHYS_64BIT
#define CONFIG_SYS_NAND_BASE_PHYS 0xffff00000ull
#else
#define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
#endif
#endif
- include/configs/p1_p2_rdb_pc.h
#ifdef CONFIG_NAND_FSL_ELBC
#define CONFIG_SYS_NAND_BASE 0xff800000
#ifdef CONFIG_PHYS_64BIT
#define CONFIG_SYS_NAND_BASE_PHYS 0xfff800000ull
#else
#define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE
#endif
and for kernel they use both the same device tree. So with the change,
the _pc variant finds its flash. Before that it worked for the non-pc
variant only if NAND_SPL wasn't used.
Any suggestion on fixing that? Providing a new dt for _pc would "fix"
it but the non pc variant won't find it in the case of NAND_SPL.
Since both system have the same SoC and the NAND_SPL is always linked
against 0xfff00000 I don't see anything wrong to relocate the NAND CS
later to 0xff800000 (or to 0xffa00000) and having it consistent among
both configs.
> -Bryan
Sebastian
^ permalink raw reply
* Re: [GIT PULL] Disintegrate and kill asm/system.h
From: Linus Torvalds @ 2012-03-29 5:02 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-arch, Michael Neuling, arnd, linux-kernel, David Howells,
paul.gortmaker, hpa, akpm, ppc-dev
In-Reply-To: <20120329154238.1ce219f7c998da45452af4b2@canb.auug.org.au>
On Wed, Mar 28, 2012 at 9:42 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> How about this (build tested on powerpc allyesconfig):
Looks better.
Grant - what's the plan about that CONFIG_VIRQ_DEBUG thing? In theory
something like it could be useful as a generic thing, but at least
right now it is clearly powerpc-specific (not just that the config
option only exists for powerpc: it has that whole
'powerpc_debugfs_root' thing in it)?
Stephen's patch very much looks like the right thing, but if there was
some plan to actually make this generic ...
Linus
^ permalink raw reply
* Re: [GIT PULL] Disintegrate and kill asm/system.h
From: Michael Neuling @ 2012-03-29 4:55 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-arch, arnd, ppc-dev, linux-kernel, David Howells,
paul.gortmaker, hpa, akpm, Linus Torvalds
In-Reply-To: <20120329154238.1ce219f7c998da45452af4b2@canb.auug.org.au>
> > Can we please move that abortion into arch/powerpc/? Instead of making
> > generic code even uglier..
>
> How about this (build tested on powerpc allyesconfig):
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 29 Mar 2012 14:58:10 +1100
> Subject: [PATCH] powerpc: fix fallout from system.h split up
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
FWIW.. this works for me too..
Acked-by: Michael Neuling <mikey@neuling.org>
Mikey
> ---
> arch/powerpc/kernel/fadump.c | 2 +
> arch/powerpc/kernel/irq.c | 72 ++++++++++++++++++++++++++++++++++++++=
> ++++
> arch/powerpc/kernel/kgdb.c | 1 +
> kernel/irq/irqdomain.c | 72 --------------------------------------=
> ----
> 4 files changed, 75 insertions(+), 72 deletions(-)
>
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index cfe7a38..18bdf74 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -40,6 +40,8 @@
> #include <asm/prom.h>
> #include <asm/rtas.h>
> #include <asm/fadump.h>
> +#include <asm/debug.h>
> +#include <asm/setup.h>
> =20
> static struct fw_dump fw_dump;
> static struct fadump_mem_struct fdm;
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index 243dbab..ff165f5 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -623,3 +623,75 @@ static int __init setup_noirqdistrib(char *str)
> =20
> __setup("noirqdistrib", setup_noirqdistrib);
> #endif /* CONFIG_PPC64 */
> +
> +#ifdef CONFIG_VIRQ_DEBUG
> +static int virq_debug_show(struct seq_file *m, void *private)
> +{
> + unsigned long flags;
> + struct irq_desc *desc;
> + const char *p;
> + static const char none[] =3D "none";
> + void *data;
> + int i;
> +
> + seq_printf(m, "%-5s %-7s %-15s %-18s %s\n", "virq", "hwirq",
> + "chip name", "chip data", "domain name");
> +
> + for (i =3D 1; i < nr_irqs; i++) {
> + desc =3D irq_to_desc(i);
> + if (!desc)
> + continue;
> +
> + raw_spin_lock_irqsave(&desc->lock, flags);
> +
> + if (desc->action && desc->action->handler) {
> + struct irq_chip *chip;
> +
> + seq_printf(m, "%5d ", i);
> + seq_printf(m, "0x%05lx ", desc->irq_data.hwirq);
> +
> + chip =3D irq_desc_get_chip(desc);
> + if (chip && chip->name)
> + p =3D chip->name;
> + else
> + p =3D none;
> + seq_printf(m, "%-15s ", p);
> +
> + data =3D irq_desc_get_chip_data(desc);
> + seq_printf(m, "0x%16p ", data);
> +
> + if (desc->irq_data.domain->of_node)
> + p =3D desc->irq_data.domain->of_node->full_name
;
> + else
> + p =3D none;
> + seq_printf(m, "%s\n", p);
> + }
> +
> + raw_spin_unlock_irqrestore(&desc->lock, flags);
> + }
> +
> + return 0;
> +}
> +
> +static int virq_debug_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, virq_debug_show, inode->i_private);
> +}
> +
> +static const struct file_operations virq_debug_fops =3D {
> + .open =3D virq_debug_open,
> + .read =3D seq_read,
> + .llseek =3D seq_lseek,
> + .release =3D single_release,
> +};
> +
> +static int __init irq_debugfs_init(void)
> +{
> + if (debugfs_create_file("virq_mapping", S_IRUGO, powerpc_debugfs_root,
> + NULL, &virq_debug_fops) =3D=3D NULL)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +__initcall(irq_debugfs_init);
> +#endif /* CONFIG_VIRQ_DEBUG */
> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> index 76a6e40..782bd0a 100644
> --- a/arch/powerpc/kernel/kgdb.c
> +++ b/arch/powerpc/kernel/kgdb.c
> @@ -24,6 +24,7 @@
> #include <asm/current.h>
> #include <asm/processor.h>
> #include <asm/machdep.h>
> +#include <asm/debug.h>
> =20
> /*
> * This table contains the mapping between PowerPC hardware trap types, and
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index af48e59..ae645ab 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -632,78 +632,6 @@ unsigned int irq_linear_revmap(struct irq_domain *doma=
> in,
> return revmap[hwirq];
> }
> =20
> -#ifdef CONFIG_VIRQ_DEBUG
> -static int virq_debug_show(struct seq_file *m, void *private)
> -{
> - unsigned long flags;
> - struct irq_desc *desc;
> - const char *p;
> - static const char none[] =3D "none";
> - void *data;
> - int i;
> -
> - seq_printf(m, "%-5s %-7s %-15s %-18s %s\n", "virq", "hwirq",
> - "chip name", "chip data", "domain name");
> -
> - for (i =3D 1; i < nr_irqs; i++) {
> - desc =3D irq_to_desc(i);
> - if (!desc)
> - continue;
> -
> - raw_spin_lock_irqsave(&desc->lock, flags);
> -
> - if (desc->action && desc->action->handler) {
> - struct irq_chip *chip;
> -
> - seq_printf(m, "%5d ", i);
> - seq_printf(m, "0x%05lx ", desc->irq_data.hwirq);
> -
> - chip =3D irq_desc_get_chip(desc);
> - if (chip && chip->name)
> - p =3D chip->name;
> - else
> - p =3D none;
> - seq_printf(m, "%-15s ", p);
> -
> - data =3D irq_desc_get_chip_data(desc);
> - seq_printf(m, "0x%16p ", data);
> -
> - if (desc->irq_data.domain->of_node)
> - p =3D desc->irq_data.domain->of_node->full_name
;
> - else
> - p =3D none;
> - seq_printf(m, "%s\n", p);
> - }
> -
> - raw_spin_unlock_irqrestore(&desc->lock, flags);
> - }
> -
> - return 0;
> -}
> -
> -static int virq_debug_open(struct inode *inode, struct file *file)
> -{
> - return single_open(file, virq_debug_show, inode->i_private);
> -}
> -
> -static const struct file_operations virq_debug_fops =3D {
> - .open =3D virq_debug_open,
> - .read =3D seq_read,
> - .llseek =3D seq_lseek,
> - .release =3D single_release,
> -};
> -
> -static int __init irq_debugfs_init(void)
> -{
> - if (debugfs_create_file("virq_mapping", S_IRUGO, powerpc_debugfs_root,
> - NULL, &virq_debug_fops) =3D=3D NULL)
> - return -ENOMEM;
> -
> - return 0;
> -}
> -__initcall(irq_debugfs_init);
> -#endif /* CONFIG_VIRQ_DEBUG */
> -
> int irq_domain_simple_map(struct irq_domain *d, unsigned int irq,
> irq_hw_number_t hwirq)
> {
> --=20
> 1.7.9.1
>
>
> --=20
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
^ 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