* RE: fpga driver on custom PPC target platform (P4080) ...
From: Robert Sciuk @ 2011-11-03 22:12 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: devicetree-discuss, linuxppc-dev
> -----Original Message-----
> From: Segher Boessenkool [mailto:segher@kernel.crashing.org]
> Sent: Thursday, November 03, 2011 5:22 PM
> To: Robert Sciuk
> Cc: devicetree-discuss@lists.ozlabs.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: fpga driver on custom PPC target platform (P4080) ...
>=20
> > - How does one specify in the device tree an FPGA which uses
> > both I2c bus and localbus for programming?
>=20
> You have two device nodes, one on the localbus and one on the IIC bus.
> One of the nodes points to the other, or both do; you point to another
> node by having a property containing the phandle of that other node.
>=20
> It's probably easiest to make the IIC node point to the localbus node,
> because you will most likely always have exactly one of those, and you
> could have multiple IIC nodes on your FPGA, or none at all. But this
> is something you'll have to put in the device binding for your device,
> and it doesn't really matter what you choose -- it will work either
> way,
> some choices are more convenient than others though.
>=20
>=20
> Segher
Segher,
Actually, I'm just now re-configuring my device-tree i2c nodes to =
accurately reflect reality. As the open() will be doing the i2c bit =
banging, I agree completely with your assessment, and I will access the =
FPGA's via the I2c bus, and locate the localbus port via the phandle =
8-).
dmesg | grep pca
[ 2.699342] pca953x 2-00e8: failed reading register
[ 2.708444] pca953x: probe of 2-00e8 failed with error -5
[ 2.719097] pca953x 2-00e9: failed reading register
[ 2.728192] pca953x: probe of 2-00e9 failed with error -5 =09
i2c@119000 {
#address-cells =3D <1>;
#size-cells =3D <0>;
cell-index =3D <2>;
compatible =3D "fsl-i2c";
reg =3D <0x119000 0x100>;
interrupts =3D <39 2 0 0>;
interrupt-parent =3D <&mpic>;
dfsrr;
lim_r: gpio@e8 {
compatible =3D "nxp,pca9539";
reg =3D <0xe8>;
#gpio-cells =3D <2>;
gpio-controller;
polarity =3D <0x00>;
};
lim_w: gpio@e9 {
compatible =3D "nxp,pca9539";
reg =3D <0xe9>;
#gpio-cells =3D <2>;
gpio-controller;
polarity =3D <0x00>;
};
};
It appears that I'm not correctly creating the pca9539 nodes as of yet =
(I'll be adding the phandles shortly). Any pointers for pca9539 driver =
nodes would be appreciated, as I took these from a similar tree, but not =
the 95xx driver. I'll match them up with the code in the morning ...
Thanks for your feedback, it was as timely as it was welcomed!
Cheers,
Rob
^ permalink raw reply
* Re: [PATCH] powerpc/usb: use unsigned long to type cast an address of ioremap
From: Segher Boessenkool @ 2011-11-03 22:08 UTC (permalink / raw)
To: David Laight
Cc: linuxppc-dev, linux-usb, Tabi Timur-B04825, Xie Shaohui-B21989
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AEA4@saturn3.aculab.com>
> Arithmetic on 'void *' should not be done. I know some versions of
> gcc allow it (provided some warning level/option is enabled) but
> that doesn't mean it is valid.
All relevant GCC versions support it (going back to 2.x at least).
It is _always_ allowed, whatever compiler options you use; -pedantic
or -Wpointer-arith will warn (which you can upgrade to an error).
The Linux kernel is not built with these warnings enabled.
>> A char* is incorrect because a char could be more
>> than one byte, in theory.
>
> It is somewhat difficult to untangle the standard, but
> sizeof (char) is defined to be one.
A char takes exactly one byte. A byte could be more than eight bits,
of course.
In GCC, sizeof(void) is 1 as well.
> Of course, the C language doesn't actually require that
> you can converts between pointers to different types in
> any well-defined manner.
It does actually, see 6.3.2.3/7. You can convert any pointer to object
to a pointer to a different object type, as long as it is properly
aligned.
You cannot in general access the object as that new type of course, but
it is perfectly well-defined; in particular, you can convert it back to
the original type and get the same value again, and you can walk
consecutive
bytes of the object by using a pointer to character type.
Segher
^ permalink raw reply
* Re: fpga driver on custom PPC target platform (P4080) ...
From: Segher Boessenkool @ 2011-11-03 21:22 UTC (permalink / raw)
To: Robert Sciuk; +Cc: devicetree-discuss, linuxppc-dev
In-Reply-To: <2DD52030B5146141BEB762A11AE97C4C0100C4AA@SPQCEXC05.exfo.com>
> - How does one specify in the device tree an FPGA which uses
> both I2c bus and localbus for programming?
You have two device nodes, one on the localbus and one on the IIC bus.
One of the nodes points to the other, or both do; you point to another
node by having a property containing the phandle of that other node.
It's probably easiest to make the IIC node point to the localbus node,
because you will most likely always have exactly one of those, and you
could have multiple IIC nodes on your FPGA, or none at all. But this
is something you'll have to put in the device binding for your device,
and it doesn't really matter what you choose -- it will work either way,
some choices are more convenient than others though.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: do not force PHYS_64BIT on Freescale reference boards
From: Kumar Gala @ 2011-11-03 20:40 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <4EB2E4F0.8040108@freescale.com>
On Nov 3, 2011, at 2:01 PM, Timur Tabi wrote:
> Kumar Gala wrote:
>> Nak. For certain boards like P204x-P50xx we only support a 36-bit =
address map.
>=20
> I understand that we don't supply a 32-bit U-boot or device tree, but =
is
> there any hard requirement that we force 36-bit kernels? If it's =
really a
> requirement, then adding to the Kconfig of each board doesn't sound =
like
> the best way to enforce this.
Yes, there is a requirement. Why would we allow you to build support =
for a board and not have it boot? The Kconfig is exactly how to enforce =
this.
- k=
^ permalink raw reply
* [PATCH] powerpc/85xx: do not force PHYS_64BIT on the P1022DS
From: Timur Tabi @ 2011-11-03 19:38 UTC (permalink / raw)
To: kumar.gala, linuxppc-dev
Kconfig option PHYS_64BIT sets the size of phys_addr_t to 64 bits, which
allows support for a 36-bit physical address space. With this option, the
kernel can support more than 2GB of RAM, but the larger address size
impacts performance slightly.
By including "select PHYS_64BIT" in the Kconfig for a particular board,
that option is forced enabled, and it becomes impossible to create a 32-bit
kernel. Instead, we should depend on the defconfig to enable this option.
We still build a 36-bit kernel by default, and we also allow users to build
32-bit kernels if they really want.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/platforms/85xx/Kconfig | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 12f5932..dddada4 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -80,7 +80,6 @@ config P1010_RDB
config P1022_DS
bool "Freescale P1022 DS"
select DEFAULT_UIMAGE
- select PHYS_64BIT # The DTS has 36-bit addresses
select SWIOTLB
help
This option enables support for the Freescale P1022DS reference board.
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] powerpc/85xx: do not force PHYS_64BIT on Freescale reference boards
From: Timur Tabi @ 2011-11-03 19:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <C957F668-1C3A-40CB-9505-27B4D6966751@freescale.com>
Kumar Gala wrote:
> Nak. For certain boards like P204x-P50xx we only support a 36-bit address map.
I understand that we don't supply a 32-bit U-boot or device tree, but is
there any hard requirement that we force 36-bit kernels? If it's really a
requirement, then adding to the Kconfig of each board doesn't sound like
the best way to enforce this.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: do not force PHYS_64BIT on Freescale reference boards
From: Kumar Gala @ 2011-11-03 18:58 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <1320346215-21024-1-git-send-email-timur@freescale.com>
On Nov 3, 2011, at 1:50 PM, Timur Tabi wrote:
> Kconfig option PHYS_64BIT sets the size of phys_addr_t to 64 bits, =
which
> allows support for a 36-bit physical address space. With this option, =
the
> kernel can support more than 2GB of RAM, but the larger address size
> impacts performance slightly.
>=20
> By including "select PHYS_64BIT" in the Kconfig for a particular =
board,
> that option is forced enabled, and it becomes impossible to create a =
32-bit
> kernel. Instead, we should depend on the defconfig to enable this =
option.
> We still build a 36-bit kernel by default, and we also allow users to =
build
> 32-bit kernels if they really want.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> arch/powerpc/configs/corenet32_smp_defconfig | 1 +
> arch/powerpc/platforms/85xx/Kconfig | 5 -----
> 2 files changed, 1 insertions(+), 5 deletions(-)
Nak. For certain boards like P204x-P50xx we only support a 36-bit =
address map.
- k=
^ permalink raw reply
* [PATCH] powerpc/85xx: do not force PHYS_64BIT on Freescale reference boards
From: Timur Tabi @ 2011-11-03 18:50 UTC (permalink / raw)
To: kumar.gala, linuxppc-dev
Kconfig option PHYS_64BIT sets the size of phys_addr_t to 64 bits, which
allows support for a 36-bit physical address space. With this option, the
kernel can support more than 2GB of RAM, but the larger address size
impacts performance slightly.
By including "select PHYS_64BIT" in the Kconfig for a particular board,
that option is forced enabled, and it becomes impossible to create a 32-bit
kernel. Instead, we should depend on the defconfig to enable this option.
We still build a 36-bit kernel by default, and we also allow users to build
32-bit kernels if they really want.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
arch/powerpc/platforms/85xx/Kconfig | 5 -----
2 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig
index 4311d02..819c06e 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -1,4 +1,5 @@
CONFIG_PPC_85xx=y
+CONFIG_PHYS_64BIT=y
CONFIG_SMP=y
CONFIG_NR_CPUS=8
CONFIG_EXPERIMENTAL=y
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 12f5932..6dba779 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -80,7 +80,6 @@ config P1010_RDB
config P1022_DS
bool "Freescale P1022 DS"
select DEFAULT_UIMAGE
- select PHYS_64BIT # The DTS has 36-bit addresses
select SWIOTLB
help
This option enables support for the Freescale P1022DS reference board.
@@ -175,7 +174,6 @@ config P2040_RDB
bool "Freescale P2040 RDB"
select DEFAULT_UIMAGE
select PPC_E500MC
- select PHYS_64BIT
select SWIOTLB
select MPC8xxx_GPIO
select HAS_RAPIDIO
@@ -187,7 +185,6 @@ config P3041_DS
bool "Freescale P3041 DS"
select DEFAULT_UIMAGE
select PPC_E500MC
- select PHYS_64BIT
select SWIOTLB
select MPC8xxx_GPIO
select HAS_RAPIDIO
@@ -199,7 +196,6 @@ config P4080_DS
bool "Freescale P4080 DS"
select DEFAULT_UIMAGE
select PPC_E500MC
- select PHYS_64BIT
select SWIOTLB
select MPC8xxx_GPIO
select HAS_RAPIDIO
@@ -214,7 +210,6 @@ config P5020_DS
select DEFAULT_UIMAGE
select E500
select PPC_E500MC
- select PHYS_64BIT
select SWIOTLB
select MPC8xxx_GPIO
select HAS_RAPIDIO
--
1.7.3.4
^ permalink raw reply related
* [git pull] Please pull powerpc.git next branch
From: Kumar Gala @ 2011-11-03 18:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
The following changes since commit 7680057cc4c7d9caada12767831bfd9738dd7b43:
powerpc: Don't try OPAL takeover on old 970 blades (2011-09-29 17:04:59 +1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git next
Anatolij Gustschin (1):
powerpc/85xx: fix PHYS_64BIT selection for P1022DS
Becky Bruce (3):
powerpc: Update mpc85xx/corenet 32-bit defconfigs
powerpc: Update corenet64_smp_defconfig
powerpc/fsl-booke: Fix settlbcam for 64-bit
Bharat Bhushan (1):
powerpc: e500mc: Fix: use CONFIG_PPC_E500MC in idle_e500.S
Dmitry Eremin-Solenikov (4):
powerpc/85xx: sbc8560 - correct compilation if CONFIG_PHYS_ADDR_T_64BIT is set
powerpc/85xx: ksi8560 - declare that localbus is compatbile with simple-bus
powerpc/85xx: sbc8560 - declare that localbus is compatbile with simple-bus
powerpc/mpc8349emitx: mark localbus as compatible with simple-bus
Fabio Baltieri (1):
powerpc/83xx: Add shutdown request support to MCU handling on MPC8349 MITX
Felix Radensky (1):
powerpc/8xxx: Fix interrupt handling in MPC8xxx GPIO driver
Holger Brunck (1):
powerpc/82xx: updates for mgcoge
Hongjun Chen (1):
powerpc/cpm: Clear muram before it is in use.
Kumar Gala (6):
powerpc/85xx: Rename PowerPC core nodes to match other e500mc based .dts
powerpc/fsl-booke: Handle L1 D-cache parity error correctly on e500mc
powerpc: respect mem= setting for early memory limit setup
powerpc/fsl-booke: Fix setup_initial_memory_limit to not blindly map
powerpc/85xx: Setup secondary cores PIR with hard SMP id
powerpc/85xx: Add 'fsl,pq3-gpio' compatiable for GPIO driver
Liu Yu (3):
powerpc/math_emu/efp: Use pr_debug instead of printk
powerpc/math_emu/efp: No need to round if the result is exact
powerpc/math_emu/efp: Look for errata handler when type mismatches
Martyn Welch (1):
powerpc/86xx: Correct Gianfar support for GE boards
Matthew McClintock (4):
powerpc/85xx: Fix support for enabling doorbells for IPIs
powerpc/85xx: issue 15 EOI after core reset for FSL CoreNet devices
powerpc/fsl_booke: Fix comment in head_fsl_booke.S
powerpc/85xx: Make kexec to interate over online cpus
Mihai Caraman (1):
drivers/virt: add ioctl for 32-bit compat on 64-bit to fsl-hv-manager
Mingkai Hu (1):
powerpc/85xx: Rename p2040_rdb.c to p2041_rdb.c
Shengzhou Liu (1):
powerpc/p3060qds: Add support for P3060QDS board
Stephen George (1):
powerpc/85xx: Adding DCSR node to dtsi device trees
Timur Tabi (3):
powerpc/fsl_msi: fix support for multiple MSI ranges
powerpc/85xx: clean up FPGA device tree nodes for Freecsale QorIQ boards
powerpc/fsl_msi: add support for "msi-address-64" property
.../devicetree/bindings/powerpc/fsl/board.txt | 30 +-
.../devicetree/bindings/powerpc/fsl/dcsr.txt | 395 ++++++++++++++++++++
.../devicetree/bindings/powerpc/fsl/msi-pic.txt | 42 ++
arch/powerpc/boot/dts/gef_ppc9a.dts | 33 ++-
arch/powerpc/boot/dts/gef_sbc310.dts | 33 ++-
arch/powerpc/boot/dts/gef_sbc610.dts | 33 ++-
arch/powerpc/boot/dts/ksi8560.dts | 2 +-
arch/powerpc/boot/dts/mgcoge.dts | 9 +
arch/powerpc/boot/dts/mpc8349emitx.dts | 3 +-
arch/powerpc/boot/dts/p1022ds.dts | 2 +-
arch/powerpc/boot/dts/p2020ds.dts | 5 +
.../boot/dts/{p2040rdb.dts => p2041rdb.dts} | 17 +-
.../boot/dts/{p2040si.dtsi => p2041si.dtsi} | 135 +++++--
arch/powerpc/boot/dts/p3041ds.dts | 8 +-
arch/powerpc/boot/dts/p3041si.dtsi | 71 ++++-
.../boot/dts/{p2040rdb.dts => p3060qds.dts} | 142 ++++++--
.../boot/dts/{p2040si.dtsi => p3060si.dtsi} | 314 ++++++++++------
arch/powerpc/boot/dts/p4080ds.dts | 12 +-
arch/powerpc/boot/dts/p4080si.dtsi | 114 +++++-
arch/powerpc/boot/dts/p5020ds.dts | 8 +-
arch/powerpc/boot/dts/p5020si.dtsi | 68 ++++-
arch/powerpc/boot/dts/sbc8560.dts | 2 +-
arch/powerpc/configs/corenet32_smp_defconfig | 11 +-
arch/powerpc/configs/corenet64_smp_defconfig | 5 -
arch/powerpc/configs/mgcoge_defconfig | 27 +-
arch/powerpc/configs/mpc85xx_defconfig | 5 +-
arch/powerpc/configs/mpc85xx_smp_defconfig | 6 +-
arch/powerpc/include/asm/reg_booke.h | 3 +
arch/powerpc/kernel/head_fsl_booke.S | 4 +-
arch/powerpc/kernel/idle_e500.S | 2 +-
arch/powerpc/kernel/prom.c | 5 +-
arch/powerpc/kernel/traps.c | 9 +-
arch/powerpc/math-emu/math_efp.c | 100 +++---
arch/powerpc/mm/fsl_booke_mmu.c | 43 ++-
arch/powerpc/mm/mmu_decl.h | 2 +
arch/powerpc/mm/tlb_nohash.c | 21 +-
arch/powerpc/platforms/82xx/km82xx.c | 4 +
arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 58 +++-
arch/powerpc/platforms/85xx/Kconfig | 20 +-
arch/powerpc/platforms/85xx/Makefile | 3 +-
arch/powerpc/platforms/85xx/p1022_ds.c | 11 +-
.../platforms/85xx/{p2040_rdb.c => p2041_rdb.c} | 18 +-
.../platforms/85xx/{p2040_rdb.c => p3060_qds.c} | 31 +-
arch/powerpc/platforms/85xx/sbc8560.c | 2 +-
arch/powerpc/platforms/85xx/smp.c | 12 +-
arch/powerpc/platforms/Kconfig | 2 +-
arch/powerpc/sysdev/cpm_common.c | 3 +-
arch/powerpc/sysdev/fsl_msi.c | 28 +-
arch/powerpc/sysdev/fsl_msi.h | 3 +-
arch/powerpc/sysdev/mpic.c | 10 +
drivers/gpio/gpio-mpc8xxx.c | 3 +
drivers/virt/fsl_hypervisor.c | 1 +
52 files changed, 1527 insertions(+), 403 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt
copy arch/powerpc/boot/dts/{p2040rdb.dts => p2041rdb.dts} (95%)
copy arch/powerpc/boot/dts/{p2040si.dtsi => p2041si.dtsi} (80%)
rename arch/powerpc/boot/dts/{p2040rdb.dts => p3060qds.dts} (62%)
rename arch/powerpc/boot/dts/{p2040si.dtsi => p3060si.dtsi} (65%)
copy arch/powerpc/platforms/85xx/{p2040_rdb.c => p2041_rdb.c} (82%)
rename arch/powerpc/platforms/85xx/{p2040_rdb.c => p3060_qds.c} (73%)
^ permalink raw reply
* Re: [PATCH] Fix interrupt handling in MPC8xxx GPIO driver
From: Kumar Gala @ 2011-11-03 17:59 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev list
In-Reply-To: <1318321461-3066-1-git-send-email-felix@embedded-sol.com>
On Oct 11, 2011, at 3:24 AM, Felix Radensky wrote:
> Interrupt handler in MPC8xxx GPIO driver is missing the call
> to PIC EOI (end of interrupt) handler. As a result, at least
> on 85XX systems, GPIO interrupt is delivered only once. This
> patch adds the missing EOI call. Tested on custom P1022 board.
>
> Signed-off-by: Felix Radensky <felix@embedded-sol.com>
> ---
> arch/powerpc/sysdev/mpc8xxx_gpio.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
applied. fixed to apply to new location of gpio driver
- k
^ permalink raw reply
* Re: [PATCH] mcu_mpc8349emitx.c: add shutdown request support
From: Kumar Gala @ 2011-11-03 18:07 UTC (permalink / raw)
To: Fabio Baltieri; +Cc: Anton Vorontsov, linuxppc-dev, linux-kernel
In-Reply-To: <1313417970-28098-1-git-send-email-fabio.baltieri@gmail.com>
On Aug 15, 2011, at 9:19 AM, Fabio Baltieri wrote:
> This patch add support for calling ctrl_alt_del() when the power =
button is
> pressed for more than about 2 seconds on some freescale MPC83xx
> evaluation boards and reference design.
>=20
> The code uses a kthread to poll the CTRL_BTN bit each second.
>=20
> Also change Kconfig entry of the driver to bool, as device's gpio
> registration is broken when loading as module.
>=20
> Tested on an MPC8315E RDB board.
>=20
> Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
> ---
> arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 58 =
+++++++++++++++++++++++-
> arch/powerpc/platforms/Kconfig | 2 +-
> 2 files changed, 58 insertions(+), 2 deletions(-)
applied
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Setup secondary cores PIR with hard SMP id
From: Kumar Gala @ 2011-11-03 18:02 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1318578771-16865-1-git-send-email-galak@kernel.crashing.org>
On Oct 14, 2011, at 2:52 AM, Kumar Gala wrote:
> Normally logical and hard cpu ID are the same, however in same cases like
> on the P3060 they may differ. Where the logical is 0..5, the hard id
> goes 0,1,4..7. This can causes issues for places we utilize PIR to index
> into array like in debug exception handlers for finding the exception
> stack.
>
> Move to setting up PIR with hard_smp_processor_id fixes the issue.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/platforms/85xx/smp.c | 9 +++++----
> 1 files changed, 5 insertions(+), 4 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH] powerpc/cpm: Clear muram before it is in use.
From: Kumar Gala @ 2011-11-03 18:01 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Hongjun Chen
In-Reply-To: <1319008732-8057-1-git-send-email-galak@kernel.crashing.org>
On Oct 19, 2011, at 2:18 AM, Kumar Gala wrote:
> From: Hongjun Chen <Hong-jun.Chen@freescale.com>
>
> We need to ensure that MURAM is in a known and cleared out state before
> using it as the bootloader could have utilized it from its own purposes
> and left it in an unknown state.
>
> If we don't clear it out we've seen issues with UCC ethernet:
> * Multi ethernet interfaces can't work simultanously.
> * Multi up/down Ethernet interfaces will halt these ports.
> * UCC1 RGMII can't work when kernel boots from some hosts.
>
> Signed-off-by: Kai.Jiang <Kai.Jiang@freescale.com>
> Signed-off-by: Hongjun Chen <Hong-jun.Chen@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/sysdev/cpm_common.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH 3/5] powerpc/85xx: Make kexec to interate over online cpus
From: Kumar Gala @ 2011-11-03 18:00 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1319583246-6120-3-git-send-email-msm@freescale.com>
On Oct 25, 2011, at 5:54 PM, Matthew McClintock wrote:
> This is not strictly required, because this iterates over logical
> cpus and they are not (currently) discontigous. But, it's cleaner
> code and more obvious what is going on
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/platforms/85xx/smp.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH 2/5] powerpc/fsl_booke: Fix comment in head_fsl_booke.S
From: Kumar Gala @ 2011-11-03 18:00 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1319583246-6120-2-git-send-email-msm@freescale.com>
On Oct 25, 2011, at 5:54 PM, Matthew McClintock wrote:
> Fix typo in comments introduced by:
>
> commit 6dece0eb69b2a28e18d104bc5d707f1cb673f5e0
> Author: Scott Wood <scottwood@freescale.com>
> Date: Mon Jul 25 11:29:33 2011 +0000
>
> powerpc/32: Pass device tree address as u64 to machine_init
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> cc: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/kernel/head_fsl_booke.S | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH v4 1/5] powerpc/85xx: issue 15 EOI after core reset for FSL CoreNet devices
From: Kumar Gala @ 2011-11-03 18:00 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1319654817-14087-1-git-send-email-msm@freescale.com>
On Oct 26, 2011, at 1:46 PM, Matthew McClintock wrote:
> This is listed as a requirement for Freescale CoreNet based devices =
(e.g
> p4080ds with MPIC v4.x) after issuing a core reset to properly clear =
pending
> interrupts.
>=20
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> v2: Updated commit message
> v3: Added detail in code comment as well
> v4: Check for MPIC_FSL in mpic->flags to determine if we need 15 EOIs
>=20
> arch/powerpc/sysdev/mpic.c | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
applied
- k=
^ permalink raw reply
* Re: [PATCH 01/11] powerpc/85xx: Add 'fsl, pq3-gpio' compatiable for GPIO driver
From: Kumar Gala @ 2011-11-03 17:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1319318452-27036-1-git-send-email-galak@kernel.crashing.org>
On Oct 22, 2011, at 4:20 PM, Kumar Gala wrote:
> Support MPC85xx platforms outside of MPC8572/MPC8536. The
> MPC8572/MPC8536 have an erratum that is worked around based on having
> "fsl,mpc8572-gpio" in the compatiable list. All other MPC85xx SoCs
> don't require this workaround and thus utilize the 'fsl,pq3-gpio'
> compatiable.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> drivers/gpio/gpio-mpc8xxx.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
applied
- k
^ permalink raw reply
* Re: [PATCH] powerpc/86xx: Correct Gianfar support for GE boards
From: Kumar Gala @ 2011-11-03 17:59 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev
In-Reply-To: <20111103173726.23924.83647.stgit@ES-BJ21R4J>
On Nov 3, 2011, at 12:37 PM, Martyn Welch wrote:
> The GE DTBs were not updated when the Gianfar driver was converted to =
an
> of_platform_driver in commit b31a1d8b41513b96e9c7ec2f68c5734cef0b26a4. =
Update
> the DTBs, adding the required TBI entries.
>=20
> Signed-off-by: Martyn Welch <martyn.welch@ge.com>
> ---
>=20
> arch/powerpc/boot/dts/gef_ppc9a.dts | 33 =
+++++++++++++++++++++++++++++----
> arch/powerpc/boot/dts/gef_sbc310.dts | 33 =
+++++++++++++++++++++++++++++----
> arch/powerpc/boot/dts/gef_sbc610.dts | 33 =
+++++++++++++++++++++++++++++----
> 3 files changed, 87 insertions(+), 12 deletions(-)
>=20
applied
- k=
^ permalink raw reply
* [PATCH] powerpc/86xx: Correct Gianfar support for GE boards
From: Martyn Welch @ 2011-11-03 17:37 UTC (permalink / raw)
To: linuxppc-dev, galak
The GE DTBs were not updated when the Gianfar driver was converted to an
of_platform_driver in commit b31a1d8b41513b96e9c7ec2f68c5734cef0b26a4. Update
the DTBs, adding the required TBI entries.
Signed-off-by: Martyn Welch <martyn.welch@ge.com>
---
arch/powerpc/boot/dts/gef_ppc9a.dts | 33 +++++++++++++++++++++++++++++----
arch/powerpc/boot/dts/gef_sbc310.dts | 33 +++++++++++++++++++++++++++++----
arch/powerpc/boot/dts/gef_sbc610.dts | 33 +++++++++++++++++++++++++++++----
3 files changed, 87 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_ppc9a.dts b/arch/powerpc/boot/dts/gef_ppc9a.dts
index 83f4b79..2266bbb 100644
--- a/arch/powerpc/boot/dts/gef_ppc9a.dts
+++ b/arch/powerpc/boot/dts/gef_ppc9a.dts
@@ -269,14 +269,16 @@
enet0: ethernet@24000 {
#address-cells = <1>;
#size-cells = <1>;
+ cell-index = <0>;
device_type = "network";
- model = "eTSEC";
+ model = "TSEC";
compatible = "gianfar";
reg = <0x24000 0x1000>;
ranges = <0x0 0x24000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
- interrupts = <0x1d 0x2 0x1e 0x2 0x22 0x2>;
+ interrupts = <29 2 30 2 34 2>;
interrupt-parent = <&mpic>;
+ tbi-handle = <&tbi0>;
phy-handle = <&phy0>;
phy-connection-type = "gmii";
@@ -290,25 +292,48 @@
interrupt-parent = <&gef_pic>;
interrupts = <0x9 0x4>;
reg = <1>;
+ device_type = "ethernet-phy";
};
phy2: ethernet-phy@2 {
interrupt-parent = <&gef_pic>;
interrupts = <0x8 0x4>;
reg = <3>;
+ device_type = "ethernet-phy";
+ };
+ tbi0: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
};
};
};
enet1: ethernet@26000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cell-index = <2>;
device_type = "network";
- model = "eTSEC";
+ model = "TSEC";
compatible = "gianfar";
reg = <0x26000 0x1000>;
+ ranges = <0x0 0x26000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
- interrupts = <0x1f 0x2 0x20 0x2 0x21 0x2>;
+ interrupts = <31 2 32 2 33 2>;
interrupt-parent = <&mpic>;
+ tbi-handle = <&tbi2>;
phy-handle = <&phy2>;
phy-connection-type = "gmii";
+
+ mdio@520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-tbi";
+ reg = <0x520 0x20>;
+
+ tbi2: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
};
serial0: serial@4500 {
diff --git a/arch/powerpc/boot/dts/gef_sbc310.dts b/arch/powerpc/boot/dts/gef_sbc310.dts
index fc3a331..429e87d 100644
--- a/arch/powerpc/boot/dts/gef_sbc310.dts
+++ b/arch/powerpc/boot/dts/gef_sbc310.dts
@@ -267,14 +267,16 @@
enet0: ethernet@24000 {
#address-cells = <1>;
#size-cells = <1>;
+ cell-index = <0>;
device_type = "network";
- model = "eTSEC";
+ model = "TSEC";
compatible = "gianfar";
reg = <0x24000 0x1000>;
ranges = <0x0 0x24000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
- interrupts = <0x1d 0x2 0x1e 0x2 0x22 0x2>;
+ interrupts = <29 2 30 2 34 2>;
interrupt-parent = <&mpic>;
+ tbi-handle = <&tbi0>;
phy-handle = <&phy0>;
phy-connection-type = "gmii";
@@ -288,25 +290,48 @@
interrupt-parent = <&gef_pic>;
interrupts = <0x9 0x4>;
reg = <1>;
+ device_type = "ethernet-phy";
};
phy2: ethernet-phy@2 {
interrupt-parent = <&gef_pic>;
interrupts = <0x8 0x4>;
reg = <3>;
+ device_type = "ethernet-phy";
+ };
+ tbi0: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
};
};
};
enet1: ethernet@26000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cell-index = <2>;
device_type = "network";
- model = "eTSEC";
+ model = "TSEC";
compatible = "gianfar";
reg = <0x26000 0x1000>;
+ ranges = <0x0 0x26000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
- interrupts = <0x1f 0x2 0x20 0x2 0x21 0x2>;
+ interrupts = <31 2 32 2 33 2>;
interrupt-parent = <&mpic>;
+ tbi-handle = <&tbi2>;
phy-handle = <&phy2>;
phy-connection-type = "gmii";
+
+ mdio@520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-tbi";
+ reg = <0x520 0x20>;
+
+ tbi2: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
};
serial0: serial@4500 {
diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts b/arch/powerpc/boot/dts/gef_sbc610.dts
index c0671cc..d81201a 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -267,14 +267,16 @@
enet0: ethernet@24000 {
#address-cells = <1>;
#size-cells = <1>;
+ cell-index = <0>;
device_type = "network";
- model = "eTSEC";
+ model = "TSEC";
compatible = "gianfar";
reg = <0x24000 0x1000>;
ranges = <0x0 0x24000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
- interrupts = <0x1d 0x2 0x1e 0x2 0x22 0x2>;
+ interrupts = <29 2 30 2 34 2>;
interrupt-parent = <&mpic>;
+ tbi-handle = <&tbi0>;
phy-handle = <&phy0>;
phy-connection-type = "gmii";
@@ -288,25 +290,48 @@
interrupt-parent = <&gef_pic>;
interrupts = <0x9 0x4>;
reg = <1>;
+ device_type = "ethernet-phy";
};
phy2: ethernet-phy@2 {
interrupt-parent = <&gef_pic>;
interrupts = <0x8 0x4>;
reg = <3>;
+ device_type = "ethernet-phy";
+ };
+ tbi0: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
};
};
};
enet1: ethernet@26000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cell-index = <2>;
device_type = "network";
- model = "eTSEC";
+ model = "TSEC";
compatible = "gianfar";
reg = <0x26000 0x1000>;
+ ranges = <0x0 0x26000 0x1000>;
local-mac-address = [ 00 00 00 00 00 00 ];
- interrupts = <0x1f 0x2 0x20 0x2 0x21 0x2>;
+ interrupts = <31 2 32 2 33 2>;
interrupt-parent = <&mpic>;
+ tbi-handle = <&tbi2>;
phy-handle = <&phy2>;
phy-connection-type = "gmii";
+
+ mdio@520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-tbi";
+ reg = <0x520 0x20>;
+
+ tbi2: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
};
serial0: serial@4500 {
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch@ge.com | M2 3AB VAT:GB 927559189
^ permalink raw reply related
* Re: [PATCH] powerpc/usb: use unsigned long to type cast an address of ioremap
From: Timur Tabi @ 2011-11-03 14:12 UTC (permalink / raw)
To: David Laight
Cc: <linux-usb@vger.kernel.org>,
<linuxppc-dev@lists.ozlabs.org>, Xie Shaohui-B21989
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AEA4@saturn3.aculab.com>
On Nov 3, 2011, at 7:16 AM, David Laight <David.Laight@ACULAB.COM> wrote:
> Arithmetic on 'void *' should not be done. I know some versions of
> gcc allow it (provided some warning level/option is enabled) but
> that doesn't mean it is valid.
> My suspicions are that is was allowed due to the way 'void *'
> was originally bodged into gcc.
Well, I don't know what else to say. Arithmetic on void* is done all over t=
he kernel. You're a little late to the party if you're going to advocate it=
s avoidance. =20
^ permalink raw reply
* Re: [PATCH 2/4] powerpc/time: Use clocksource_register_hz
From: John Stultz @ 2011-11-03 13:14 UTC (permalink / raw)
To: Anton Blanchard; +Cc: paulus, linuxppc-dev
In-Reply-To: <20111103010111.951358660@samba.org>
On Thu, 2011-11-03 at 11:59 +1100, Anton Blanchard wrote:
> plain text document attachment (clock3)
> Use clocksource_register_hz which calculates the shift/mult
> factors for us.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
>
> Index: linux-build/arch/powerpc/kernel/time.c
> ===================================================================
> --- linux-build.orig/arch/powerpc/kernel/time.c 2011-11-03 10:19:59.493679032 +1100
> +++ linux-build/arch/powerpc/kernel/time.c 2011-11-03 10:20:00.965704053 +1100
> @@ -86,8 +86,6 @@ static struct clocksource clocksource_rt
> .rating = 400,
> .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> .mask = CLOCKSOURCE_MASK(64),
> - .shift = 22,
> - .mult = 0, /* To be filled in */
> .read = rtc_read,
> };
>
> @@ -97,8 +95,6 @@ static struct clocksource clocksource_ti
> .rating = 400,
> .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> .mask = CLOCKSOURCE_MASK(64),
> - .shift = 22,
> - .mult = 0, /* To be filled in */
> .read = timebase_read,
> };
So I've held off on ppc conversion to clocksource_register_hz due to the
fact that the ppc vdso gettimeofday at least used to make assumptions
that shift was 22.
Is that no longer the case?
thanks
-john
^ permalink raw reply
* RE: Support for multiple MSI interrupts on MPC8377
From: Giffel, Brad @ 2011-11-03 12:19 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1320292282.3852.33.camel@concordia>
A single MSI interrupt it is then.
Thanks,
- Brad
-----Original Message-----
From: Michael Ellerman [mailto:michael@ellerman.id.au]=20
Sent: Wednesday, November 02, 2011 10:51 PM
To: Giffel, Brad
Cc: linuxppc-dev@lists.ozlabs.org; Matthew Wilcox
Subject: Re: Support for multiple MSI interrupts on MPC8377
On Wed, 2011-11-02 at 16:02 -0500, Giffel, Brad wrote:
> I'm working a project using a Spartan 6 FPGA with a PCIe interface and
> MSI interrupts. I want to use multiple MSI interrupts (MSI-X is not
> supported in the FPGA PCIe core) but the current Linux distribution
> (3.0.8) prevents that (lines 23 to 25 in arch/powerpc/kernel/msi.c).
>=20
> =20
>=20
> What's the story here? Is the code in place but not tested? I tried
> commenting out those lines but a request_irq() called failed for the
> second interrupt requested. Am I wasting my time here? Should I
> re-architect to use a single MSI interrupt?
The short and easy answer is you should use a single MSI interrupt.
There is some code in place to support multiple MSI, but only in the
generic code (drivers/pci/msi.c), and I'm not sure if it's complete.
There is no arch support, for any arch AFAIK, and certainly not for
powerpc.
cheers
^ permalink raw reply
* RE: [PATCH] powerpc/usb: use unsigned long to type cast an address of ioremap
From: David Laight @ 2011-11-03 12:16 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: linux-usb, linuxppc-dev, Xie Shaohui-B21989
In-Reply-To: <4EB283F5.6000202@freescale.com>
> >> > usb_sys_regs =3D (void *)dr_regs + USB_DR_SYS_OFFSET;
>=20
> > But that is invalid C.
>=20
> What's invalid about it? I haven't tried compiling this=20
> specific line of code, but I've done stuff like it in the past many
times.
>=20
> Are you talking about adding an integer to a void pointer? =20
> If so, then that's something that gcc supports and that the kernel
uses=20
> all over the place.
Arithmetic on 'void *' should not be done. I know some versions of
gcc allow it (provided some warning level/option is enabled) but
that doesn't mean it is valid.
My suspicions are that is was allowed due to the way 'void *'
was originally bodged into gcc.
> A char* is incorrect because a char could be more=20
> than one byte, in theory.
It is somewhat difficult to untangle the standard, but
sizeof (char) is defined to be one.
Of course, the C language doesn't actually require that
you can converts between pointers to different types in
any well-defined manner. But most of the low level device
access assumes an adequately linear address space.
David
^ permalink raw reply
* Re: [PATCH] powerpc/usb: use unsigned long to type cast an address of ioremap
From: Tabi Timur-B04825 @ 2011-11-03 12:07 UTC (permalink / raw)
To: David Laight
Cc: linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Xie Shaohui-B21989
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AEA3@saturn3.aculab.com>
David Laight wrote:
>> > usb_sys_regs =3D (void *)dr_regs + USB_DR_SYS_OFFSET;
> But that is invalid C.
What's invalid about it? I haven't tried compiling this specific line of=20
code, but I've done stuff like it in the past many times.
Are you talking about adding an integer to a void pointer? If so, then=20
that's something that gcc supports and that the kernel uses all over the=20
place. A char* is incorrect because a char could be more than one byte,=20
in theory.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* RE: [PATCH] powerpc/usb: use unsigned long to type cast an address of ioremap
From: David Laight @ 2011-11-03 11:38 UTC (permalink / raw)
To: Tabi Timur-B04825, Xie Shaohui-B21989; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <CAOZdJXW16RbPkMfmoNu4t1c5mqCuZsztPMk1=hNc7NaYXOsx7A@mail.gmail.com>
=20
> On Thu, Nov 3, 2011 at 4:58 AM, Shaohui Xie =
<Shaohui.Xie@freescale.com> wrote:
> >
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0usb_sys_regs =3D (struct =
usb_sys_interface *)
> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
((u32)dr_regs + USB_DR_SYS_OFFSET);
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
((unsigned long)dr_regs + USB_DR_SYS_OFFSET);
>=20
> This makes more sense:
>=20
> usb_sys_regs =3D (void *)dr_regs + USB_DR_SYS_OFFSET;
But that is invalid C.
David
^ 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