* [PATCH 1/3][POWERPC][V2] of_serial: Fix possible null dereference.
From: John Linn @ 2008-04-02 16:52 UTC (permalink / raw)
To: linuxppc-dev, grant.likely; +Cc: John Linn
From: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
The of_serial driver queries the current-speed property and attempts
to use it to register the custom_divisor property of the uart_port.
However, if current-speed is not set, then this code will dereference
a bad pointer. The fix is to only set custom_divisor when a
current-speed property appears in the device tree.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Signed-off-by: John Linn <john.linn@xilinx.com>
---
drivers/serial/of_serial.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index a64d858..2efb892 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -56,7 +56,9 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
| UPF_FIXED_PORT;
port->dev = &ofdev->dev;
- port->custom_divisor = *clk / (16 * (*spd));
+ /* If current-speed was set, then try not to change it. */
+ if (spd)
+ port->custom_divisor = *clk / (16 * (*spd));
return 0;
}
--
1.5.2.1
^ permalink raw reply related
* [PATCH 0/3] [POWERPC] [V2][RFC] of_serial and boot patches introduction
From: John Linn @ 2008-04-02 16:50 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 768 bytes --]
I am sending V2 series of patches that fix the OF serial driver and add
support to it and the boot for the Xilinx UART 16550.
The ePAPR, although not a formal spec yet, proposes allowing reg-shift
for ns16550. We believe this is a reasonable approach and have
implemented it in this patch series.
We've tried to integrate the consensus from the previous comments also.
[v1]
I am sending a series of patches that fix the OF serial driver and add
support to it and the boot for the Xilinx UART 16550.
I think we have tried to satisfy previous concerns about UARTs which are
non-standard as the Xilinx 16550 is (register spacing and offset).
We would like to have these pulled into 2.6.26.
Thanks,
John
[-- Attachment #2: Type: text/html, Size: 9080 bytes --]
^ permalink raw reply
* [PATCH 0/3] [POWERPC] [V2][RFC] of_serial and boot patches introduction
From: John Linn @ 2008-04-02 16:45 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 768 bytes --]
I am sending V2 series of patches that fix the OF serial driver and add
support to it and the boot for the Xilinx UART 16550.
The ePAPR, although not a formal spec yet, proposes allowing reg-shift
for ns16550. We believe this is a reasonable approach and have
implemented it in this patch series.
We've tried to integrate the consensus from the previous comments also.
[v1]
I am sending a series of patches that fix the OF serial driver and add
support to it and the boot for the Xilinx UART 16550.
I think we have tried to satisfy previous concerns about UARTs which are
non-standard as the Xilinx 16550 is (register spacing and offset).
We would like to have these pulled into 2.6.26.
Thanks,
John
[-- Attachment #2: Type: text/html, Size: 9079 bytes --]
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] Cell OProfile: SPU mutex lock fix
From: Carl Love @ 2008-04-02 16:42 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, cel, cbe-oss-dev, linux-kernel
In-Reply-To: <200804020721.15861.arnd@arndb.de>
On Wed, 2008-04-02 at 07:21 +0200, Arnd Bergmann wrote:
> On Tuesday 25 March 2008, Carl Love wrote:
> > This patch fixes a bug in the code that records the SPU data and
> > context switches. The buffer_mutex lock must be held when the
> > kernel is adding data to the buffer between the kernel and the
> > OProfile daemon. The lock is not being held in the current code
> > base. This patch fixes the bug using work queues. The data to
> > be passed to the daemon is caputured by the interrupt handler.
> > The workqueue function is invoked to grab the buffer_mutex lock
> > and add the data to the buffer.
>
> So what was the exact bug you're fixing with this? There was no
> buffer_mutex before, so why do you need it now? Can't this be a
> spinlock so you can get it from interrupt context instead of
> using a workqueue?
The generic OProfile code defines a mutex lock, called buffer_mutex, to
protect the kernel/daemon data buffer from being writen by the kernal
and simultaneously read by the Daemon. When adding a PPU sample the
oprofile routine oprofile_add_ext_sample(pc, regs, i, is_kernel) is
called from the interrupt context to request the sample be stored. The
generic oprofile code takes care of passing the data to a non interrupt
context where the mutex lock is held and the necessary sequence of data
is written into the kernel/daemon data buffer. However, OProfile does
not have any built in functions for handling the SPU. Hence, we have to
implement the code to capture the data in the interrupt context, pass it
to a non interrupt context and put it into the buffer. This was not
done correctly in the original implementation. Specifically, the mutex
lock was not being held.
Writing data to the OProfile buffer consists of a sequence of items.
For example when writing an SPU entry, first comes the escape code so
the daemon knows this is a new entry. The next item is the SPU context
switch code which says the data which will follow is the information
about a new context. There is a different code to identify the data as
an address sample. Finally the data about the SPU context switch is
entered into the buffer. The issue is the OProfile daemon is read all
of the entire sequence of items then process the data. Without the
mutex lock, the daemon may read part of the sequence try to process it
before everything is written into the buffer. When the daemon reads
again, it doesn't see the escape code as the first item and isn't smart
enough to realize it is part of a previous sequence. The generic
OProfile code defines the mutex lock and calls it buffer_mutex. The
OProfile kernel/daemon API uses the mutex lock. The mutex lock can only
be held in a non interrupt context. The current implementation uses a
spin lock to make sure the kernel writes each sequence if items into the
buffer but since the API does not use a spin lock we have no way to
prevent the daemon from reading the buffer until the entire sequence of
items has been written to the buffer. Hence the need to hold the
buffer_mutex lock which prevents the daemon from accessing the buffer.
>
> > Index: linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_profiler.c
> > ===================================================================
> > --- linux-2.6.25-rc4.orig/arch/powerpc/oprofile/cell/spu_profiler.c
> > +++ linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_profiler.c
> > @@ -16,6 +16,7 @@
> > #include <linux/smp.h>
> > #include <linux/slab.h>
> > #include <asm/cell-pmu.h>
> > +#include <linux/workqueue.h>
> > #include "pr_util.h"
> >
>
> Please keep #include statements in alphabetical order, with all linux/ files
> before the asm/ files.
>
> > #define TRACE_ARRAY_SIZE 1024
> > @@ -32,9 +33,19 @@ static unsigned int profiling_interval;
> >
> > #define SPU_PC_MASK 0xFFFF
> >
> > +/* The generic OProfile code uses the buffer_mutex to protect the buffer
> > + * between the kernel and the daemon. The SPU code needs to use the buffer
> > + * to ensure that the kernel SPU writes complete as a single block before
> > + * being consumed by the daemon.
> > + */
> > +extern struct mutex buffer_mutex;
> > +
> > static DEFINE_SPINLOCK(sample_array_lock);
> > unsigned long sample_array_lock_flags;
> >
> > +struct work_struct spu_record_wq;
> > +extern struct workqueue_struct *oprofile_spu_wq;
> > +
> > void set_spu_profiling_frequency(unsigned int freq_khz, unsigned int cycles_reset)
> > {
> > unsigned long ns_per_cyc;
>
> Never put extern statements in the implementation, they describe the
> interface between two parts of the code and should be inside of a
> common header.
>
> Why do you want to have your own workqueue instead of using the
> global one?
>
> > @@ -123,14 +134,14 @@ static int cell_spu_pc_collection(int cp
> > return entry;
> > }
> >
> > -
> > -static enum hrtimer_restart profile_spus(struct hrtimer *timer)
> > -{
> > - ktime_t kt;
> > +static void profile_spus_record_samples (struct work_struct *ws) {
> > + /* This routine is called via schedule_work() to record the
> > + * spu data. It must be run in a normal kernel mode to
> > + * grab the OProfile mutex lock.
> > + */
> > int cpu, node, k, num_samples, spu_num;
> >
> > - if (!spu_prof_running)
> > - goto stop;
> > + mutex_lock(&buffer_mutex);
> >
> > for_each_online_cpu(cpu) {
> > if (cbe_get_hw_thread_id(cpu))
> > @@ -170,6 +181,20 @@ static enum hrtimer_restart profile_spus
> > smp_wmb(); /* insure spu event buffer updates are written */
> > /* don't want events intermingled... */
> >
> > + mutex_unlock(&buffer_mutex);
> > +}
> > +
> > +static enum hrtimer_restart profile_spus(struct hrtimer *timer)
> > +{
> > + ktime_t kt;
> > +
> > +
> > + if (!spu_prof_running)
> > + goto stop;
> > +
> > + /* schedule the funtion to record the data */
> > + schedule_work(&spu_record_wq);
> > +
> > kt = ktime_set(0, profiling_interval);
> > if (!spu_prof_running)
> > goto stop;
>
> This looks like you want to use a delayed_work rather than building your
> own out of hrtimer and work. Is there any point why you want to use
> an hrtimer?
The current implementation uses the hrtimer to schedule when to read the
trace buffer the next time. This patch does not change how the
scheduling of the buffer reads is done. Yes, you could change the
implementation to use workqueues instead. If you feel that it is better
to use the workqueue then we could make that change. Not sure that
making that change in this bug fix patch is appropriate. I would need
to create a second patch for that change.
>
> > -static DEFINE_SPINLOCK(buffer_lock);
> > +extern struct mutex buffer_mutex;
> > +extern struct workqueue_struct *oprofile_spu_wq;
> > +extern int calls_to_record_switch;
> > +
>
> Again, public interfaces need to go to a header file, and should
> have a name that identifies the interface. "buffer_mutex" is
> certainly not a suitable name for a kernel-wide global variable!
As stated earlier, the generic OProfile code defines the variable
"buffer_mutex". Changing the name in the generic OProfile code is
beyond the scope of this patch.
>
> > static DEFINE_SPINLOCK(cache_lock);
> > static int num_spu_nodes;
> > +
> > int spu_prof_num_nodes;
> > int last_guard_val[MAX_NUMNODES * 8];
> > +int cnt_swtch_processed_flag[MAX_NUMNODES * 8];
> > +
> > +struct spus_profiling_code_data_s {
> > + int num_spu_nodes;
> > + struct work_struct spu_prof_code_wq;
> > +} spus_profiling_code_data;
> > +
> > +struct spu_context_switch_data_s {
> > + struct spu *spu;
> > + unsigned long spu_cookie;
> > + unsigned long app_dcookie;
> > + unsigned int offset;
> > + unsigned long objectId;
> > + int valid_entry;
> > +} spu_context_switch_data;
>
> I don't understand what these variables are really doing, but
> having e.g. just one spu_context_switch_data for all the SPUs
> doesn't seem to make much sense. What happens when two SPUs do
> a context switch at the same time?
This is the data same data that was being put into the event buffer
directly from the interrupt context. We need to store the data that is
only available in the interrupt context so the same data can be put into
the buffer by the work queue function in the non interrupt context.
This is the declaration of the data needed per SPU. Below in the
spu_cntx_sw_data structure, we declare an array of entries so we can
store the switch
>
> > +int calls_to_record_switch = 0;
> > +int record_spu_start_flag = 0;
> > +
> > +struct spus_cntxt_sw_data_s {
> > + int num_spu_nodes;
> > + struct spu_context_switch_data_s spu_data[MAX_NUMNODES * 8];
> > + struct work_struct spu_cntxt_work;
> > +} spus_cntxt_sw_data;
>
> Something is very wrong if you need so many global variables!
>
> > /* Container for caching information about an active SPU task. */
> > struct cached_info {
> > @@ -44,6 +73,8 @@ struct cached_info {
> > struct kref cache_ref;
> > };
> >
> > +struct workqueue_struct *oprofile_spu_wq;
> > +
> > static struct cached_info *spu_info[MAX_NUMNODES * 8];
>
> While you're cleaning this up, I guess the cached_info should
> be moved into a pointer from struct spu as well, instead of
> having this global variable here.
>
> > @@ -375,16 +457,30 @@ int spu_sync_start(void)
> > int k;
> > int ret = SKIP_GENERIC_SYNC;
> > int register_ret;
> > - unsigned long flags = 0;
> >
> > spu_prof_num_nodes = number_of_online_nodes();
> > num_spu_nodes = spu_prof_num_nodes * 8;
> >
> > - spin_lock_irqsave(&buffer_lock, flags);
> > - add_event_entry(ESCAPE_CODE);
> > - add_event_entry(SPU_PROFILING_CODE);
> > - add_event_entry(num_spu_nodes);
> > - spin_unlock_irqrestore(&buffer_lock, flags);
> > + /* create private work queue, execution of work is time critical */
> > + oprofile_spu_wq = create_workqueue("spu_oprofile");
> > +
> > + /* due to a race when the spu is already running stuff, need to
> > + * set a flag to tell the spu context switch to record the start
> > + * before recording the context switches.
> > + */
> > + record_spu_start_flag = 1;
> > +
> > + spus_profiling_code_data.num_spu_nodes = num_spu_nodes;
> > +
> > + /* setup work queue functiion for recording context switch info */
> > + spus_cntxt_sw_data.num_spu_nodes = num_spu_nodes;
> > + for (k = 0; k<(MAX_NUMNODES * 8); k++) {
> > + spus_cntxt_sw_data.spu_data[k].valid_entry = 0;
> > + cnt_swtch_processed_flag[k] = 0;
> > + }
> > +
> > + INIT_WORK(&spus_cntxt_sw_data.spu_cntxt_work,
> > + record_spu_process_switch);
>
> I would guess that you need one work struct per SPU instead of a global
> one, if you want to pass the SPU pointer as an argument.
>
> Arnd <><
^ permalink raw reply
* RE: Virtex V5FX PPC 440 Support In Xilinx Git Tree
From: Stephen Neuendorffer @ 2008-04-02 16:34 UTC (permalink / raw)
To: John Linn, Peter Korsgaard, Grant Likely; +Cc: git, linuxppc-embedded
In-Reply-To: <689CB232690D8D4E97DA6C76DA098E6C05FC43ED@XCO-EXCHVS1.xlnx.xilinx.com>
I've just pushed support for generating device trees for the ppc440 in
V5FXT up to git.xilinx.com.
The most obvious difference is that the PPC440 block contains not only
the PPC440 core, but also an interconnect block, subsuming part of the
'multi-ported' functionality of the MPMC. In order to have a relatively
straightforward mapping between blocks in the EDK design and nodes in
the dts, I've represented this as shown below. Note that unlike the
MPMC, the dma ports are controlled through DCR (which is part of the
point of the recent dcr patches). I've done some preliminary testing
using some hacked together platform support code and we'll update this
based on the 405 code soon.
Steve
/ {
#address-cells =3D <1>;
#size-cells =3D <1>;
compatible =3D "xlnx,virtex";
dcr-parent =3D <&ppc440_virtex5_0>;
model =3D "testing";
chosen {
bootargs =3D "root=3D/dev/xsysace/disc0/part2";
} ;
cpus {
#address-cells =3D <1>;
#cpus =3D <1>;
#size-cells =3D <0>;
ppc440_virtex5_0: cpu@0 {
#address-cells =3D <1>;
#size-cells =3D <1>;
clock-frequency =3D <17d78400>;
compatible =3D "PowerPC,440", "ibm,ppc440";
d-cache-line-size =3D <20>;
d-cache-line-size =3D <20>;
d-cache-size =3D <8000>;
dcr-access-method =3D "native";
dcr-controller ;
device_type =3D "cpu";
i-cache-line-size =3D <20>;
i-cache-size =3D <8000>;
model =3D "PowerPC,440";
reg =3D <0>;
timebase-frequency =3D <17d78400>;
DMA0: sdma@1010000 {
compatible =3D "xlnx,ll-dma-1.00.a";
dcr-reg =3D < 1010000 11 >;
interrupt-parent =3D <&opb_intc_0>;
interrupts =3D < 5 2 6 2 >;
} ;
DMA1: sdma@1010000 {
compatible =3D "xlnx,ll-dma-1.00.a";
dcr-reg =3D < 1010000 11 >;
} ;
DMA2: sdma@1010000 {
compatible =3D "xlnx,ll-dma-1.00.a";
dcr-reg =3D < 1010000 11 >;
} ;
DMA3: sdma@1010000 {
compatible =3D "xlnx,ll-dma-1.00.a";
dcr-reg =3D < 1010000 11 >;
} ;
} ;
} ;
plb_v46_cfb_0: plb@0 {
#address-cells =3D <1>;
#size-cells =3D <1>;
compatible =3D "xlnx,plb-v46-1.00.a";
ranges ;
iic_bus: i2c@d0020000 {
compatible =3D "xlnx,xps-iic-1.00.a";
interrupt-parent =3D <&opb_intc_0>;
interrupts =3D < 7 2 >;
reg =3D < d0020000 200 >;
xlnx,clk-freq =3D <5f5e100>;
xlnx,family =3D "virtex5";
xlnx,gpo-width =3D <1>;
xlnx,iic-freq =3D <186a0>;
xlnx,ten-bit-adr =3D <0>;
} ;
leds_8bit: gpio@d0010200 {
compatible =3D "xlnx,xps-gpio-1.00.a";
interrupt-parent =3D <&opb_intc_0>;
interrupts =3D < 1 2 >;
reg =3D < d0010200 200 >;
xlnx,all-inputs =3D <0>;
xlnx,all-inputs-2 =3D <0>;
xlnx,dout-default =3D <0>;
xlnx,dout-default-2 =3D <0>;
xlnx,family =3D "virtex5";
xlnx,gpio-width =3D <8>;
xlnx,interrupt-present =3D <1>;
xlnx,is-bidir =3D <1>;
xlnx,is-bidir-2 =3D <1>;
xlnx,is-dual =3D <0>;
xlnx,tri-default =3D <ffffffff>;
xlnx,tri-default-2 =3D <ffffffff>;
} ;
ll_temac_0: xps-ll-temac@91200000 {
#address-cells =3D <1>;
#size-cells =3D <1>;
compatible =3D "xlnx,compound";
ethernet@91200000 {
compatible =3D "xlnx,xps-ll-temac-1.00.b";
device_type =3D "network";
interrupt-parent =3D <&opb_intc_0>;
interrupts =3D < 4 2 >;
llink-connected =3D <&DMA0>;
local-mac-address =3D [ 00 00 00 00 00 00
];
reg =3D < 91200000 40 >;
xlnx,bus2core-clk-ratio =3D <1>;
xlnx,phy-type =3D <1>;
xlnx,phyaddr =3D <1>;
xlnx,rxcsum =3D <0>;
xlnx,rxfifo =3D <4000>;
xlnx,temac-type =3D <0>;
xlnx,txcsum =3D <0>;
xlnx,txfifo =3D <4000>;
} ;
} ;
opb_intc_0: interrupt-controller@d0020200 {
#interrupt-cells =3D <2>;
compatible =3D "xlnx,xps-intc-1.00.a";
interrupt-controller ;
reg =3D < d0020200 20 >;
xlnx,num-intr-inputs =3D <8>;
} ;
plb_bram_if_cntlr_0: xps-bram-if-cntlr@ffff0000 {
compatible =3D "xlnx,xps-bram-if-cntlr-1.00.a";
reg =3D < ffff0000 10000 >;
xlnx,family =3D "virtex5";
} ;
plb_bram_if_cntlr_1: xps-bram-if-cntlr@eee00000 {
compatible =3D "xlnx,xps-bram-if-cntlr-1.00.a";
reg =3D < eee00000 2000 >;
xlnx,family =3D "virtex5";
} ;
rs232_uart_0: serial@d0000000 {
clock-frequency =3D "";
compatible =3D "xlnx,xps-uart16550-1.00.a";
current-speed =3D <2580>;
device_type =3D "serial";
interrupt-parent =3D <&opb_intc_0>;
interrupts =3D < 0 2 >;
reg =3D < d0000000 2000 >;
reg-offset =3D <3>;
reg-shift =3D <2>;
xlnx,family =3D "virtex5";
xlnx,has-external-rclk =3D <0>;
xlnx,has-external-xin =3D <1>;
xlnx,is-a-16550 =3D <1>;
} ;
sysace_compactflash: sysace@d0030100 {
compatible =3D "xlnx,xps-sysace-1.00.a";
reg =3D < d0030100 80 >;
xlnx,family =3D "virtex5";
xlnx,mem-width =3D <10>;
} ;
} ;
ppc440mc_ddr2_0: memory@0 {
device_type =3D "memory";
reg =3D < 0 20000000 >;
} ;
} ;
> -----Original Message-----
> From: John Linn
> Sent: Wednesday, April 02, 2008 8:24 AM
> To: Peter Korsgaard
> Cc: linuxppc-embedded@ozlabs.org; git
> Subject: RE: Virtex V5FX PPC 440 Support In Xilinx Git Tree
>=20
> Hi Peter,
>=20
> We added arch/ppc support because it was the easiest path for us. We
realize it's going away soon in
> the mainline.
>=20
> We are working on getting arch/powerpc more mature for both the 405
and the 440 as we do believe this
> is the future for powerpc.
>=20
> Thanks,
> John
>=20
>=20
>=20
> -----Original Message-----
> From: Peter Korsgaard [mailto:jacmet@gmail.com] On Behalf Of Peter
Korsgaard
> Sent: Wednesday, April 02, 2008 3:51 AM
> To: John Linn
> Cc: linuxppc-embedded@ozlabs.org; git
> Subject: Re: Virtex V5FX PPC 440 Support In Xilinx Git Tree
>=20
> >>>>> "John" =3D=3D John Linn <John.Linn@xilinx.com> writes:
>=20
> John> I pushed PowerPC 440 support to the Xilinx Git server with
> John> support for ppc arch and with powerpc arch support coming in
> John> the near future.
>=20
> Neat, but why have you added arch/ppc support? It's supposed to go
> away pretty much by the time the hardware gets in the hand of
> developers.
>=20
> --
> Bye, Peter Korsgaard
^ permalink raw reply
* RE: Virtex V5FX PPC 440 Support In Xilinx Git Tree
From: John Linn @ 2008-04-02 15:23 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: git, linuxppc-embedded
In-Reply-To: <87lk3w8u00.fsf@macbook.be.48ers.dk>
Hi Peter,
We added arch/ppc support because it was the easiest path for us. We
realize it's going away soon in the mainline.
We are working on getting arch/powerpc more mature for both the 405 and
the 440 as we do believe this is the future for powerpc.
Thanks,
John
-----Original Message-----
From: Peter Korsgaard [mailto:jacmet@gmail.com] On Behalf Of Peter
Korsgaard
Sent: Wednesday, April 02, 2008 3:51 AM
To: John Linn
Cc: linuxppc-embedded@ozlabs.org; git
Subject: Re: Virtex V5FX PPC 440 Support In Xilinx Git Tree
>>>>> "John" =3D=3D John Linn <John.Linn@xilinx.com> writes:
John> I pushed PowerPC 440 support to the Xilinx Git server with
John> support for ppc arch and with powerpc arch support coming in
John> the near future.
Neat, but why have you added arch/ppc support? It's supposed to go
away pretty much by the time the hardware gets in the hand of
developers.
--=20
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
From: Stefan Roese @ 2008-04-02 15:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1207149149-17107-1-git-send-email-sr@denx.de>
On Wednesday 02 April 2008, Stefan Roese wrote:
> This patch adds basic endpoint support to the 4xx PCIe driver.
This should have been an RFC. Sorry I missed adding it to the subject.
Best regards,
Stefan
^ permalink raw reply
* [PATCH] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
From: Stefan Roese @ 2008-04-02 15:12 UTC (permalink / raw)
To: linuxppc-dev
This patch adds basic endpoint support to the 4xx PCIe driver.
This is done by checking whether the PCIe port is already configured as
root-complex or as endpoint. This has been done previously in U-Boot and
can be configured there dynamically by setting the "pcie_mode"
environment variable (reboot necessary of course). Here an example:
pcie_mode = 'RP:RP:EP'
Port 0 & 1 are configured as root-complex and port 2 as endpoint.
This mode will now be used in the Linux driver too.
Note: Currently we map a fixed 64MByte window to PLB address 0 (SDRAM).
This should probably be configurable via a dts property.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/sysdev/ppc4xx_pci.c | 133 +++++++++++++++++++++++++++-----------
1 files changed, 96 insertions(+), 37 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index d183b83..013fd05 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -563,6 +563,18 @@ struct ppc4xx_pciex_hwops
static struct ppc4xx_pciex_hwops *ppc4xx_pciex_hwops;
+static int is_endpoint(struct ppc4xx_pciex_port *port)
+{
+ u32 val;
+
+ val = mfdcri(SDR0, port->sdr_base + PESDRn_DLPSET);
+
+ if (((val >> 20) & 0xf) == PTYPE_LEGACY_ENDPOINT)
+ return 1;
+ else
+ return 0;
+}
+
#ifdef CONFIG_44x
/* Check various reset bits of the 440SPe PCIe core */
@@ -1400,28 +1412,59 @@ static void __init ppc4xx_configure_pciex_PIMs(struct ppc4xx_pciex_port *port,
resource_size_t size = res->end - res->start + 1;
u64 sa;
- /* Calculate window size */
- sa = (0xffffffffffffffffull << ilog2(size));;
- if (res->flags & IORESOURCE_PREFETCH)
- sa |= 0x8;
+ if (port->endpoint) {
+ resource_size_t ep_addr = 0;
+ resource_size_t ep_size = 32 << 20;
- out_le32(mbase + PECFG_BAR0HMPA, RES_TO_U32_HIGH(sa));
- out_le32(mbase + PECFG_BAR0LMPA, RES_TO_U32_LOW(sa));
+ /* Currently we map a fixed 64MByte window to PLB address
+ * 0 (SDRAM). This should probably be configurable via a dts
+ * property.
+ */
+
+ /* Calculate window size */
+ sa = (0xffffffffffffffffull << ilog2(ep_size));;
+
+ /* Setup BAR0 */
+ out_le32(mbase + PECFG_BAR0HMPA, RES_TO_U32_HIGH(sa));
+ out_le32(mbase + PECFG_BAR0LMPA, RES_TO_U32_LOW(sa) |
+ PCI_BASE_ADDRESS_MEM_TYPE_64);
- /* The setup of the split looks weird to me ... let's see if it works */
- out_le32(mbase + PECFG_PIM0LAL, 0x00000000);
- out_le32(mbase + PECFG_PIM0LAH, 0x00000000);
- out_le32(mbase + PECFG_PIM1LAL, 0x00000000);
- out_le32(mbase + PECFG_PIM1LAH, 0x00000000);
- out_le32(mbase + PECFG_PIM01SAH, 0xffff0000);
- out_le32(mbase + PECFG_PIM01SAL, 0x00000000);
+ /* Disable BAR1 & BAR2 */
+ out_le32(mbase + PECFG_BAR1MPA, 0);
+ out_le32(mbase + PECFG_BAR2HMPA, 0);
+ out_le32(mbase + PECFG_BAR2LMPA, 0);
+
+ out_le32(mbase + PECFG_PIM01SAH, RES_TO_U32_HIGH(sa));
+ out_le32(mbase + PECFG_PIM01SAL, RES_TO_U32_LOW(sa));
+
+ out_le32(mbase + PCI_BASE_ADDRESS_0, RES_TO_U32_LOW(ep_addr));
+ out_le32(mbase + PCI_BASE_ADDRESS_1, RES_TO_U32_HIGH(ep_addr));
+ } else {
+ /* Calculate window size */
+ sa = (0xffffffffffffffffull << ilog2(size));;
+ if (res->flags & IORESOURCE_PREFETCH)
+ sa |= 0x8;
+
+ out_le32(mbase + PECFG_BAR0HMPA, RES_TO_U32_HIGH(sa));
+ out_le32(mbase + PECFG_BAR0LMPA, RES_TO_U32_LOW(sa));
+
+ /* The setup of the split looks weird to me ... let's see
+ * if it works
+ */
+ out_le32(mbase + PECFG_PIM0LAL, 0x00000000);
+ out_le32(mbase + PECFG_PIM0LAH, 0x00000000);
+ out_le32(mbase + PECFG_PIM1LAL, 0x00000000);
+ out_le32(mbase + PECFG_PIM1LAH, 0x00000000);
+ out_le32(mbase + PECFG_PIM01SAH, 0xffff0000);
+ out_le32(mbase + PECFG_PIM01SAL, 0x00000000);
+
+ out_le32(mbase + PCI_BASE_ADDRESS_0, RES_TO_U32_LOW(res->start));
+ out_le32(mbase + PCI_BASE_ADDRESS_1, RES_TO_U32_HIGH(res->start));
+ }
/* Enable inbound mapping */
out_le32(mbase + PECFG_PIMEN, 0x1);
- out_le32(mbase + PCI_BASE_ADDRESS_0, RES_TO_U32_LOW(res->start));
- out_le32(mbase + PCI_BASE_ADDRESS_1, RES_TO_U32_HIGH(res->start));
-
/* Enable I/O, Mem, and Busmaster cycles */
out_le16(mbase + PCI_COMMAND,
in_le16(mbase + PCI_COMMAND) |
@@ -1436,13 +1479,6 @@ static void __init ppc4xx_pciex_port_setup_hose(struct ppc4xx_pciex_port *port)
int primary = 0, busses;
void __iomem *mbase = NULL, *cfg_data = NULL;
- /* XXX FIXME: Handle endpoint mode properly */
- if (port->endpoint) {
- printk(KERN_WARNING "PCIE%d: Port in endpoint mode !\n",
- port->index);
- return;
- }
-
/* Check if primary bridge */
if (of_get_property(port->node, "primary", NULL))
primary = 1;
@@ -1502,12 +1538,14 @@ static void __init ppc4xx_pciex_port_setup_hose(struct ppc4xx_pciex_port *port)
port->hose = hose;
mbase = (void __iomem *)hose->cfg_addr;
- /*
- * Set bus numbers on our root port
- */
- out_8(mbase + PCI_PRIMARY_BUS, hose->first_busno);
- out_8(mbase + PCI_SECONDARY_BUS, hose->first_busno + 1);
- out_8(mbase + PCI_SUBORDINATE_BUS, hose->last_busno);
+ if (!port->endpoint) {
+ /*
+ * Set bus numbers on our root port
+ */
+ out_8(mbase + PCI_PRIMARY_BUS, hose->first_busno);
+ out_8(mbase + PCI_SECONDARY_BUS, hose->first_busno + 1);
+ out_8(mbase + PCI_SUBORDINATE_BUS, hose->last_busno);
+ }
/*
* OMRs are already reset, also disable PIMs
@@ -1531,14 +1569,26 @@ static void __init ppc4xx_pciex_port_setup_hose(struct ppc4xx_pciex_port *port)
* and device IDs into it. Those are the same bogus one that the
* initial code in arch/ppc add. We might want to change that.
*/
- out_le16(mbase + 0x200, 0xaaa0 + port->index);
- out_le16(mbase + 0x202, 0xbed0 + port->index);
+ if (!port->endpoint) {
+ out_le16(mbase + 0x200, 0xaaa0 + port->index);
+ out_le16(mbase + 0x202, 0xbed0 + port->index);
- /* Set Class Code to PCI-PCI bridge and Revision Id to 1 */
- out_le32(mbase + 0x208, 0x06040001);
+ /* Set Class Code to PCI-PCI bridge and Revision Id to 1 */
+ out_le32(mbase + 0x208, 0x06040001);
+
+ printk(KERN_INFO "PCIE%d: successfully set as root-complex\n",
+ port->index);
+ } else {
+ out_le16(mbase + 0x200, 0xeee0 + port->index);
+ out_le16(mbase + 0x202, 0xfed0 + port->index);
+
+ /* Set Class Code to Processor/PPC */
+ out_le32(mbase + 0x208, 0x0b200001);
+
+ printk(KERN_INFO "PCIE%d: successfully set as endpoint\n",
+ port->index);
+ }
- printk(KERN_INFO "PCIE%d: successfully set as root-complex\n",
- port->index);
return;
fail:
if (hose)
@@ -1586,8 +1636,17 @@ static void __init ppc4xx_probe_pciex_bridge(struct device_node *np)
}
port->sdr_base = *pval;
- /* XXX Currently, we only support root complex mode */
- port->endpoint = 0;
+ /* Check whether the PCIe port is already configured as root-complex
+ * or as endpoint. This has been done previously in U-Boot and can
+ * be configured there dynamically by setting the "pcie_mode"
+ * environment variable (reboot necessary of course). Here an example:
+ *
+ * pcie_mode = 'RP:RP:EP'
+ *
+ * Port 0 & 1 are configured as root-complex and port 2 as endpoint.
+ * This mode will now be used in the Linux driver too.
+ */
+ port->endpoint = is_endpoint(port);
/* Fetch config space registers address */
if (of_address_to_resource(np, 0, &port->cfg_space)) {
--
1.5.4.5
^ permalink raw reply related
* Re: ARCH=ppc vs powerpc
From: Guillaume Dargaud @ 2008-04-02 14:59 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <0cf501c894cb$c73dfee0$f52f9e86@LPSC0173W>
Sorry, although it's related to linuxppc, I intended to post this question
to the buildroot mailing list.
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* [PATCH] powerpc: Fix CPM2 SCC1 clock initialization.
From: Laurent Pinchart @ 2008-04-02 14:46 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 854 bytes --]
A missing break statement in a switch caused cpm2_clk_setup() to initialize
SCC2 instead of SCC1. This patch fixes the bug.
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
---
arch/powerpc/sysdev/cpm2.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c
index 57ed1a4..7478e81 100644
--- a/arch/powerpc/sysdev/cpm2.c
+++ b/arch/powerpc/sysdev/cpm2.c
@@ -246,6 +246,7 @@ int cpm2_clk_setup(enum cpm_clk_target target, int clock, int mode)
case CPM_CLK_SCC1:
reg = &im_cpmux->cmx_scr;
shift = 24;
+ break;
case CPM_CLK_SCC2:
reg = &im_cpmux->cmx_scr;
shift = 16;
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: Please pull powerpc.git merge branch
From: Bartlomiej Sieka @ 2008-04-02 14:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18418.49494.457893.866627@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Bartlomiej Sieka writes:
>
>> What about http://patchwork.ozlabs.org/linuxppc/patch?id=17525 ? I don't
>> see it in the merge branch of your repository, and it would be nice to
>> get it upstream as it fixes boot problems on some MPC5200-based boards.
>
> It needs a proper stand-alone commit message and an acked-by from
> Grant. The commit message should explain why you are making the
> changes you are making rather than just saying "the bulk of this patch
> is taken from http://...".
Paul,
Just re-sent the patch, please see
http://patchwork.ozlabs.org/linuxppc/patch?id=17678; hopefully
everything is OK now.
(Note that I've dropped torvalds@linux-foundation.org,
akpm@linux-foundation.org and linux-kernel@vger.kernel.org from the CC:)
Regards,
Bartlomiej
^ permalink raw reply
* [RESEND3 PATCH] [POWERPC] mpc5200: Amalgamated DTS fixes and updates
From: Bartlomiej Sieka @ 2008-04-02 14:26 UTC (permalink / raw)
To: linuxppc-dev
DTS updates that fix booting problems:
- change to ethernet reg property
- addition of mdio and phy nodes
- removal of pci node (Motion-Pro board)
Other DTS updates:
- update i2c device tree nodes
- add lpb bus node and flash device (without partitions defined)
- add rtc i2c nodes
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
Changes since previous submission:
- added patch description
- added a space between "phy0:" and "ethernet-phy" per David Gibson's
suggestion.
arch/powerpc/boot/dts/cm5200.dts | 37 ++++++++++++++++++++-
arch/powerpc/boot/dts/motionpro.dts | 63 +++++++++++++++++++----------------
arch/powerpc/boot/dts/tqm5200.dts | 42 +++++++++++++++++++++++
3 files changed, 112 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/boot/dts/cm5200.dts b/arch/powerpc/boot/dts/cm5200.dts
index 30737ea..c6ca631 100644
--- a/arch/powerpc/boot/dts/cm5200.dts
+++ b/arch/powerpc/boot/dts/cm5200.dts
@@ -212,13 +212,30 @@
ethernet@3000 {
device_type = "network";
compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
- reg = <3000 800>;
+ reg = <3000 400>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <2 5 0>;
interrupt-parent = <&mpc5200_pic>;
+ phy-handle = <&phy0>;
+ };
+
+ mdio@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-mdio","fsl,mpc5200-mdio";
+ reg = <3000 400>; // fec range, since we need to setup fec interrupts
+ interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
+ interrupt-parent = <&mpc5200_pic>;
+
+ phy0: ethernet-phy@0 {
+ device_type = "ethernet-phy";
+ reg = <0>;
+ };
};
i2c@3d40 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
reg = <3d40 40>;
interrupts = <2 10 0>;
@@ -231,4 +248,22 @@
reg = <8000 4000>;
};
};
+
+ lpb {
+ model = "fsl,lpb";
+ compatible = "fsl,lpb";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 fc000000 2000000>;
+
+ // 16-bit flash device at LocalPlus Bus CS0
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 2000000>;
+ bank-width = <2>;
+ device-width = <2>;
+ #size-cells = <1>;
+ #address-cells = <1>;
+ };
+ };
};
diff --git a/arch/powerpc/boot/dts/motionpro.dts b/arch/powerpc/boot/dts/motionpro.dts
index 76951ab..2b0dde0 100644
--- a/arch/powerpc/boot/dts/motionpro.dts
+++ b/arch/powerpc/boot/dts/motionpro.dts
@@ -148,7 +148,6 @@
interrupt-parent = <&mpc5200_pic>;
};
-
spi@f00 {
compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
reg = <f00 20>;
@@ -209,10 +208,25 @@
ethernet@3000 {
device_type = "network";
compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
- reg = <3000 800>;
+ reg = <3000 400>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <2 5 0>;
interrupt-parent = <&mpc5200_pic>;
+ phy-handle = <&phy0>;
+ };
+
+ mdio@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-mdio","fsl,mpc5200-mdio";
+ reg = <3000 400>; // fec range, since we need to setup fec interrupts
+ interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
+ interrupt-parent = <&mpc5200_pic>;
+
+ phy0: ethernet-phy@2 {
+ device_type = "ethernet-phy";
+ reg = <2>;
+ };
};
ata@3a00 {
@@ -223,11 +237,19 @@
};
i2c@3d40 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
reg = <3d40 40>;
interrupts = <2 10 0>;
interrupt-parent = <&mpc5200_pic>;
fsl5200-clocking;
+
+ rtc@68 {
+ device_type = "rtc";
+ compatible = "dallas,ds1339";
+ reg = <68>;
+ };
};
sram@8000 {
@@ -240,7 +262,8 @@
compatible = "fsl,lpb";
#address-cells = <2>;
#size-cells = <1>;
- ranges = <1 0 50000000 00010000
+ ranges = <0 0 ff000000 01000000
+ 1 0 50000000 00010000
2 0 50010000 00010000
3 0 50020000 00010000>;
@@ -271,31 +294,15 @@
compatible = "promess,pro_module_dio";
reg = <3 800 2>;
};
- };
- pci@f0000d00 {
- #interrupt-cells = <1>;
- #size-cells = <2>;
- #address-cells = <3>;
- device_type = "pci";
- compatible = "fsl,mpc5200b-pci","fsl,mpc5200-pci";
- reg = <f0000d00 100>;
- interrupt-map-mask = <f800 0 0 7>;
- interrupt-map = <c000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
- c000 0 0 2 &mpc5200_pic 1 1 3
- c000 0 0 3 &mpc5200_pic 1 2 3
- c000 0 0 4 &mpc5200_pic 1 3 3
-
- c800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
- c800 0 0 2 &mpc5200_pic 1 2 3
- c800 0 0 3 &mpc5200_pic 1 3 3
- c800 0 0 4 &mpc5200_pic 0 0 3>;
- clock-frequency = <0>; // From boot loader
- interrupts = <2 8 0 2 9 0 2 a 0>;
- interrupt-parent = <&mpc5200_pic>;
- bus-range = <0 0>;
- ranges = <42000000 0 80000000 80000000 0 20000000
- 02000000 0 a0000000 a0000000 0 10000000
- 01000000 0 00000000 b0000000 0 01000000>;
+ // 16-bit flash device at LocalPlus Bus CS0
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 01000000>;
+ bank-width = <2>;
+ device-width = <2>;
+ #size-cells = <1>;
+ #address-cells = <1>;
+ };
};
};
diff --git a/arch/powerpc/boot/dts/tqm5200.dts b/arch/powerpc/boot/dts/tqm5200.dts
index c86464f..65bcea6 100644
--- a/arch/powerpc/boot/dts/tqm5200.dts
+++ b/arch/powerpc/boot/dts/tqm5200.dts
@@ -127,10 +127,25 @@
ethernet@3000 {
device_type = "network";
compatible = "fsl,mpc5200-fec";
- reg = <3000 800>;
+ reg = <3000 400>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <2 5 0>;
interrupt-parent = <&mpc5200_pic>;
+ phy-handle = <&phy0>;
+ };
+
+ mdio@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-mdio","fsl,mpc5200-mdio";
+ reg = <3000 400>; // fec range, since we need to setup fec interrupts
+ interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
+ interrupt-parent = <&mpc5200_pic>;
+
+ phy0: ethernet-phy@0 {
+ device_type = "ethernet-phy";
+ reg = <0>;
+ };
};
ata@3a00 {
@@ -141,11 +156,19 @@
};
i2c@3d40 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "fsl,mpc5200-i2c","fsl-i2c";
reg = <3d40 40>;
interrupts = <2 10 0>;
interrupt-parent = <&mpc5200_pic>;
fsl5200-clocking;
+
+ rtc@68 {
+ device_type = "rtc";
+ compatible = "dallas,ds1307";
+ reg = <68>;
+ };
};
sram@8000 {
@@ -154,6 +177,23 @@
};
};
+ lpb {
+ model = "fsl,lpb";
+ compatible = "fsl,lpb";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 fc000000 02000000>;
+
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 02000000>;
+ bank-width = <4>;
+ device-width = <2>;
+ #size-cells = <1>;
+ #address-cells = <1>;
+ };
+ };
+
pci@f0000d00 {
#interrupt-cells = <1>;
#size-cells = <2>;
^ permalink raw reply related
* printk time confusion?
From: Johannes Berg @ 2008-04-02 14:23 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: Arnd Bergmann, Benjamin Herrenschmidt
[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]
Hi,
Not sure whether the lockdep patches or something else is causing this
as I haven't checked w/o the patches yet, but I seem to be having some
confusion of printk timestamps:
[...]
[ 176.440255] iwl4965: No space for Tx
[...]
[ 147.983705] ioctl32(gnome-terminal:6361): Unknown cmd fd(25) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/2
[...]
[ 173.589209] BUG kmalloc-2048: Poison overwritten
[...]
[ 208.385226] ioctl32(gnome-terminal:6498): Unknown cmd fd(29) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/6
[...]
[ 139.026724] ioctl32(gnome-terminal:6521): Unknown cmd fd(30) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe8) on /dev/pts/7
[...]
[ 155.982345] ioctl32(gnome-terminal:6543): Unknown cmd fd(31) cmd(0000530b){t:'S';sz:0} arg(0fd7bbe0) on /dev/pts/8
[...]
[ 218.918388] tg3: eth0: Link is down.
[...]
Yes, these entries really were printed in that order. Btw, what's with
the unknown ioctls?
Kernel version is 2.6.25-rc8-wl-04519-g6648ff7-dirty where -wl/-dirty
refers to wireless patches and the lockdep patches and otherwise it's
just -rc8.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Add irqtrace support to 32-bit powerpc
From: Johannes Berg @ 2008-04-02 14:15 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev, Benjamin Herrenschmidt
In-Reply-To: <20080201195040.GA8950@farnsworth.org>
[-- Attachment #1: Type: text/plain, Size: 642 bytes --]
On Fri, 2008-02-01 at 12:50 -0700, Dale Farnsworth wrote:
> This adds the low level irq tracing hooks for 32-bit powerpc.
> This patch applies on top of Benjamin Herrenschmidt's patch that
> provides similar support for 64-bit powerpc. See
> <http://ozlabs.org/pipermail/linuxppc-dev/2007-October/044361.html>
>
> It seems to work on my prpmc2800 board with a ppc7447.
At first it appears to work on my powerbook (with Ben's latest version
of the 64-bit patch), but then it seems to cause random corruption, I've
had a crash in the ext3 code and one in console_callback(), both of
which I cannot otherwise explain.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* ARCH=ppc vs powerpc
From: Guillaume Dargaud @ 2008-04-02 14:13 UTC (permalink / raw)
To: linuxppc-dev
Anyone care to comment on that:
$ make ARCH=ppc linux26-menuconfig
[ -f
/home/guinevere/buildroot/project_build_ppc/genepy/linux-2.6.24/.config ] |
| cp local/genepy/linux-2.6.24.config
/home/guinevere/buildroot/project_build_pp
c/genepy/linux-2.6.24/.config
/usr/bin/make -j1 HOSTCC="/usr/bin/gcc" HOSTCFLAGS="" ARCH=powerpc
[...]
Why does ARCH change ?!?
[...]
.config:132:warning: trying to assign nonexistent symbol XILINX_ML405
[...]
$ find -name Kconfig -exec grep -H XILINX_ML405 {} \;
./toolchain_build_powerpc/linux-2.6.24/arch/ppc/platforms/4xx/Kconfig:config
XILINX_ML405
./project_build_ppc/genepy/linux-2.6.24/arch/ppc/platforms/4xx/Kconfig:config
XILINX_ML405
./toolchain_build_ppc/linux-2.6.24/arch/ppc/platforms/4xx/Kconfig:config
XILINX_ML405
Well, it's no surprise that it won't find them if it looks in the powerpc
branch...
The question is why ?
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* Re: [PATCH 2/2 v5] Add DIU platform code for MPC8610HPCD
From: York Sun @ 2008-04-02 13:27 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-fbdev-devel, a.p.zijlstra, linux-kernel, linuxppc-dev,
scottwood, timur
In-Reply-To: <20080401140029.be918d87.akpm@linux-foundation.org>
On Tue, 2008-04-01 at 14:00 -0700, Andrew Morton wrote:
> On Mon, 31 Mar 2008 11:23:25 -0500
> York Sun <yorksun@freescale.com> wrote:
>
> > Add platform code to support Freescale DIU. The platform code includes
> > framebuffer memory allocation, pixel format, monitor port, etc.
> >
> > Signed-off-by: York Sun <yorksun@freescale.com>
> > Signed-off-by: Timur Tabi <timur@freescale.com>
> > ---
> > This patch addes platform support for Freescale DIU driver, targeting 2.6.26 kernel.
> >
> > arch/powerpc/configs/mpc8610_hpcd_defconfig | 198 +++++++++++++++++++++++----
> > arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 190 ++++++++++++++++++++++++--
> > arch/powerpc/sysdev/fsl_soc.c | 41 ++++++
> > arch/powerpc/sysdev/fsl_soc.h | 23 +++
> > 4 files changed, 413 insertions(+), 39 deletions(-)
>
> The defconfig change gets almost 100% rejects and probably isn't
> appropriate here and isn't very important. I dropped that part of the
> patch.
>
It's OK.
York
^ permalink raw reply
* Re: [PATCH 0/4] [POWERPC] lockdep support for ppc64
From: Johannes Berg @ 2008-04-02 13:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1207134128.10388.254.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 453 bytes --]
> Haven't tested this version on G5 yet btw :-) (though I had a previous
> one working internally). I tested on POWER6 pSeries and old iSeries
> (spent a while fixing the later).
>
> I'll run more tests tomorrow hopefully and add a few patch fixing
> some of the issues that lockdep already starting showing.
Works fine, and on my box I don't see lockdep showing issues.
Thanks for picking this up from me and rewriting it :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: psc and spi
From: S. Fricke @ 2008-04-02 13:06 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40801150651s213a745dwa4d595de5a9d191b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2369 bytes --]
Hello,
> On 1/15/08, S. Fricke <silvio.fricke@googlemail.com> wrote:
> > Hello friends,
> >
> > I have on the psc3 the spi-interface of a fpga connected.
> >
> > psc3-0 - MOSI
> > psc3-1 - MISO
> > psc3-2 - CLK
> > psc3-3 - SlaveSelect
> > psc3-4 - CS-FPGA
> > psc3-5 - CS Another device
> > psc3-6 - SPI-SEL0
> > psc3-7 - SPI-SEL1
> > psc3-8/9 - Not connected
> >
> > Can I use the mpc52xx_psc_spi-driver? And if yes, how I have to use this
> > driver? Or must I write a own spi-master/slave thing? Can anyone point me
> > to a good start-position?
>
> Yes, you should be able to use the mpc52xx_psc_spi driver. You'' need
> to add the activate_cs and deactivate_cs hooks in your platform code
> to activate your SPI CS lines. You'll also need to set port_config to
> have the PSC3 pins in "CODEC3" mode.
OK, I defined a "fsl_spi_platform_data" for my "activate_cs" and
"deactivate_cs". This structure I have insert in a "spi_board_info" with
all other mandatory Informations.
When I load "mpc52xx_psc_spi", then I get a "mpc52xx-psc-spi f0002400.spi:
probe called without platform data, no (de)activate_cs function will be
called"
What is wrong in my setup or did I have forget something?
static void activate_cs(u8 cs, u8 polarity) {/* ... */ }
static void deactivate_cs(u8 cs, u8 polarity) {/* ...*/}
static struct fsl_spi_platform_data my_spi_p_data = {
.bus_num = 0x2400,
.max_chipselect = 3,
.activate_cs = activate_cs,
.deactivate_cs = deactivate_cs,
};
static struct spi_board_info my_spi_boardinfo = {
.bus_num = 0x2400,
.chip_select = 0,
.max_speed_hz = 1000,
.modalias = "my-spi-device",
.platform_data = &my_spi_p_data,
};
static int __init ipek01_spi_init(void) {
int ret;
return fsl_spi_init(&my_spi_boardinfo, 1, activate_cs, deactivate_cs);
}
device_initcall(ipek01_spi_init);
best regards,
Silvio Fricke
--
-- S. Fricke ------------------------------------ silvio.fricke@gmail.com --
Diplom-Informatiker (FH) TEL: (+49)8330-911278
Linux-Entwicklung JABBER: silvio@conversation.port1024.net
----------------------------------------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
From: Kumar Gala @ 2008-04-02 13:14 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18418.55835.338209.611273@cargo.ozlabs.ibm.com>
On Apr 1, 2008, at 7:58 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Hmm, need to think about that. But my initial reaction is two fold.
>> One I don't think this information would be around and two don't we
>> already have this problem with a kdump kernel?
>
> I'm just concerned that we have two things that have to match up - the
> compiled-in physical address that the kernel assumes it is running at,
> and the physical address where it is actually loaded. While those two
> things were both always 0 for embedded processors, there wasn't a
> problem, but now we can have a situation where a kernel binary has to
> be loaded at some nonzero address to work correctly, but there is no
> way to work out what that address is for an existing vmlinux binary.
> Or have I missed something?
Nope, that sums up the situation pretty well.
> For a kdump kernel, at least for 64-bit, the physical address has to
> be 32MB. There is no other choice, so there is no possibility of
> confusion.
But how do you know a vmlinux image is for kdump or not?
> For 85xx, would it be possible to have the kernel figure out what
> physical address it has been loaded at, and use that as the base
> address, rather than having the base address set at compile time?
Yes, that is what CONFIG_RELOCATABLE is all about.
> That would solve my objection since it would mean that there would no
> longer be two things that had to be kept in sync. You could pass any
> value to wrapper/mkimage (subject to constraints such as it has to be
> a multiple of 256M) and it would work. That value could even come
> from a config option in the case where wrapper is invoked as part of
> the kernel build, but that config option shouldn't affect anything at
> all in the vmlinux.
Ok, but I still think the issues exists when we config PHYSICAL_START
to non-zero and CONFIG_RELOCATABLE=n. Ideally we get set the phys
address the PHDR, but I'm not sure how to get the linker to do that.
- k
^ permalink raw reply
* Re: Please pull from 'for-2.6.25' branch
From: Kumar Gala @ 2008-04-02 13:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev list, Linus Torvalds
In-Reply-To: <18419.29305.168659.363143@cargo.ozlabs.ibm.com>
On Apr 2, 2008, at 6:48 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Paul, any comments on sending this onto linus. I was hoping to avoid
>> 2.6.25 coming up not support the proper device bindings for DMA and
>> SATA.
>
> I've pulled it and I'll send it on later (or Linus can pull it
> directly if he wants). There is the iSeries fix from Ben H plus two
> other patches (one from Bartlomiej Sieka and one from Nathan Lynch)
> where I'm waiting for proper patch descriptions and/or signed-off-by
> lines. I was hoping to get those tomorrow and send the lot on to
> Linus.
Ok, just wasn't sure what the status was. A day or two is fine.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Move phys_addr_t definition into asm/types.h
From: Kumar Gala @ 2008-04-02 13:11 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0804021352580.20994@vixen.sonytel.be>
On Apr 2, 2008, at 6:53 AM, Geert Uytterhoeven wrote:
> On Tue, 1 Apr 2008, Kumar Gala wrote:
>> On Mar 31, 2008, at 10:42 PM, Paul Mackerras wrote:
>>> Kumar Gala writes:
>>>> Moved phys_addr_t out of mmu-*.h and into asm/types.h so we can
>>>> use it in
>>>> places that before would have caused recursive includes.
>>>>
>>>> For example to use phys_addr_t in <asm/page.h> we would have
>>>> included
>>>> <asm/mmu.h> which would have possibly included <asm/mmu-hash64.h>
>>>> which
>>>> includes <asm/page.h>. Wheeee recursive include.
>>>
>>> In general this looks fine. I wonder if you should use u64 rather
>>> than unsigned long long. Since CONFIG_PHYS_64BIT=n on 64-bit
>>> machines
>>> (which is itself somewhat counterintuitive) we will actually use
>>> unsigned long on 64-bit machines, so it matters less than I
>>> originally
>>> thought, but it would be worth explaining that in a comment and/or
>>> the
>>> commit message.
>>
>> We could change it to be:
>>
>> /* Physical address used by some IO functions */
>> #if defined(CONFIG_PPC64) || defined(CONFIG_PHYS_64BIT)
>> typedef u64 phys_addr_t;
>> #else
>> typedef u32 phys_addr_t;
>> #endif
>>
>> This seems a bit more self documenting which is always nice (and I
>> can add a
>> comment in the commit message about CONFIG_PHYS_64BIT only making
>> sense on
>> ppc32).
>
> If it's counterintuitive that CONFIG_PHYS_64BIT=n on 64-bit
> machines, why
> not set it to =y in Kconfig?
Its not that it =n, its that its not available. The Kconfig looks like:
config PHYS_64BIT
bool 'Large physical address support' if E500
depends on 44x || E500
select RESOURCES_64BIT
default y if 44x
We could set it to y on PPC64 as there is no harm there, but Paul
would need to say he wants that done.
- k
^ permalink raw reply
* Re: [PATCH 1/4] [POWERPC] Initialize paca->current earlier
From: Stephen Rothwell @ 2008-04-02 12:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20080402075253.8726ADDEDD@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
On Wed, 02 Apr 2008 18:52:09 +1100 Benjamin Herrenschmidt <benh@ozlabs.org> wrote:
>
> This changes it so that all PACAs are statically initialized with
> __current pointing to the init task. For non-0 CPUs, this is fixed
> up before use.
You might want to see how this impacts on Tony Breed's 1024 way patches.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] [POWERPC] lockdep stacktrace support
From: Stephen Rothwell @ 2008-04-02 12:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20080402075254.24539DDEDD@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]
On Wed, 02 Apr 2008 18:52:10 +1100 Benjamin Herrenschmidt <benh@ozlabs.org> wrote:
>
> +++ linux-work/arch/powerpc/kernel/stacktrace.c 2008-04-02 16:46:07.000000000 +1100
> @@ -0,0 +1,52 @@
> +
Copyight and license statement needed.
> +#include <linux/sched.h>
> +#include <linux/stacktrace.h>
You should include <asm/ptrace.h> for STACK_FRAME_OVERHEAD and struct pt_regs.
> +#ifdef CONFIG_PPC64
> +#define MIN_STACK_FRAME 112 /* same as STACK_FRAME_OVERHEAD, in fact */
So use STACK_FRAME_OVERHEAD?
> +#define FRAME_LR_SAVE 2
> +#define INT_FRAME_SIZE (sizeof(struct pt_regs) + STACK_FRAME_OVERHEAD + 288)
^^^^^^^^^^^^^^^^^^^^
Its used here already ...
> +#define REGS_MARKER 0x7265677368657265ul
Maybe we need to put REGS_MARKER into a header file as it already appears
in two assembly files and two C files.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: [PATCH] Add Fixed PHY support for ucc_geth
From: Joakim Tjernlund @ 2008-04-02 12:15 UTC (permalink / raw)
To: Li Yang; +Cc: Netdev, Jeff Garzik, Linuxppc-Embedded@Ozlabs.Org
In-Reply-To: <989B956029373F45A0B8AF029708189001D1954D@zch01exm26.fsl.freescale.net>
On Fri, 2008-03-21 at 16:51 +0800, Li Yang wrote:
> > -----Original Message-----
> > From: Joakim Tjernlund [mailto:Joakim.Tjernlund@transmode.se]
> > Sent: Tuesday, March 18, 2008 5:47 PM
> > To: Netdev; Li Yang; Linuxppc-Embedded@Ozlabs.Org
> > Cc: Joakim Tjernlund
> > Subject: [PATCH] Add Fixed PHY support for ucc_geth
> >
> > The new Fixed PHY method, fixed-link property, isn't
> > impl. for ucc_geth which makes fixed PHYs non functional.
> > Add support for the new method to restore the Fixed PHY
> > functionality.
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
>
> Signed-off-by: Li Yang <leoli@freescale.com>
>
> ---
> Ps: This patch depends on the patch "ucc_geth: use correct thread number
> for 10/100Mbps link" to apply, which hasn't made to Linus' tree for now
> but has already been in Jeff and David's trees.
What happened to this patch? It is not in Linus tree.
Jocke
^ permalink raw reply
* Re: [PATCH] [POWERPC] Move phys_addr_t definition into asm/types.h
From: Geert Uytterhoeven @ 2008-04-02 11:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <451ABD36-3763-4AF0-B24B-AF043393A72C@kernel.crashing.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1929 bytes --]
On Tue, 1 Apr 2008, Kumar Gala wrote:
> On Mar 31, 2008, at 10:42 PM, Paul Mackerras wrote:
> >Kumar Gala writes:
> > >Moved phys_addr_t out of mmu-*.h and into asm/types.h so we can use it in
> > >places that before would have caused recursive includes.
> > >
> > >For example to use phys_addr_t in <asm/page.h> we would have included
> > ><asm/mmu.h> which would have possibly included <asm/mmu-hash64.h> which
> > >includes <asm/page.h>. Wheeee recursive include.
> >
> >In general this looks fine. I wonder if you should use u64 rather
> >than unsigned long long. Since CONFIG_PHYS_64BIT=n on 64-bit machines
> >(which is itself somewhat counterintuitive) we will actually use
> >unsigned long on 64-bit machines, so it matters less than I originally
> >thought, but it would be worth explaining that in a comment and/or the
> >commit message.
>
> We could change it to be:
>
> /* Physical address used by some IO functions */
> #if defined(CONFIG_PPC64) || defined(CONFIG_PHYS_64BIT)
> typedef u64 phys_addr_t;
> #else
> typedef u32 phys_addr_t;
> #endif
>
> This seems a bit more self documenting which is always nice (and I can add a
> comment in the commit message about CONFIG_PHYS_64BIT only making sense on
> ppc32).
If it's counterintuitive that CONFIG_PHYS_64BIT=n on 64-bit machines, why
not set it to =y in Kconfig?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ 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