Re: TQM8349 and ARCH = powerpc
Hi Kim, u-boot assigns the IMMR to 0xff40 in TQM834x.h, whereas the device tree you picked has it at 0xe000 (it's defined in the soc node). Don't forget to match up the PCI addresses too. patches welcome, of course (we don't have tqm boards). Thanks for this important information! I'll do my best to get this kind of hardware running. Just copying the dts was a too naive approach ;-) Maybe I ask TQ if they want to contribute something. It would be a pity if this module line would not be supported anymore. Thanks and bye, -- Dipl. Ing. Oliver Rutsch EMail: [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
IDE
Hello I would like to setup my IDE controller. It uses a generic mapping. And he is located at the adress 0x20003000. How can I specifie this adress to the ide driver ? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: IDE
Hello. Sébastien Chrétien wrote: I would like to setup my IDE controller. It uses a generic mapping. And he is located at the adress 0x20003000. What kin of controller, and what do you mean by generic mapping? How can I specifie this adress to the ide driver ? The usual ways is via the platform device. MBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: IDE
Have I to rewrite a IDE driver ? 2008/9/10, Sergei Shtylyov [EMAIL PROTECTED]: Hello. Sébastien Chrétien wrote: I would like to setup my IDE controller. It uses a generic mapping. And he is located at the adress 0x20003000. What kin of controller, and what do you mean by generic mapping? How can I specifie this adress to the ide driver ? The usual ways is via the platform device. MBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: IDE
It is a common ide controller : offset 0x0 Data offset 0x1 error offset 0x2 Sector count offset 0x3 sector No offset 0x4 Cylinder low offset 0x5 Cylinder High offset 0x6 Head offset 0x7 status 2008/9/10, Sergei Shtylyov [EMAIL PROTECTED]: Hello. Sébastien Chrétien wrote: I would like to setup my IDE controller. It uses a generic mapping. And he is located at the adress 0x20003000. What kin of controller, and what do you mean by generic mapping? How can I specifie this adress to the ide driver ? The usual ways is via the platform device. MBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: IDE
Hello. Sébastien Chrétien wrote: Have I to rewrite a IDE driver ? Most probably you can use the existing platform drivers: drivers/ide/egacy/ide_platform.c or drivers/ata/pata_platform.c. Create/register a platform device named pata_platform with 2 memory and 1 IRQ resource, and enable one of those drivers. 2008/9/10, Sergei Shtylyov [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hello. Sébastien Chrétien wrote: I would like to setup my IDE controller. It uses a generic mapping. And he is located at the adress 0x20003000. What kin of controller, and what do you mean by generic mapping? How can I specifie this adress to the ide driver ? The usual ways is via the platform device. MBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: IDE
On Wednesday 10 September 2008, Sergei Shtylyov wrote: Most probably you can use the existing platform drivers: drivers/ide/egacy/ide_platform.c or drivers/ata/pata_platform.c. Create/register a platform device named pata_platform with 2 memory and 1 IRQ resource, and enable one of those drivers. For new boards using a flattened device tree, it should be enough to add a device node for the pata_of_platform driver. If you need a device specific setup, you should add a new compatible value in the tree and make the driver handle that in whatever way you need. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: IDE
I looked falconide.c, it uses hw_regs_t hw; and ide_hwif_t *hwif. Is it a good way ? 2008/9/10, Arnd Bergmann [EMAIL PROTECTED]: On Wednesday 10 September 2008, Sergei Shtylyov wrote: Most probably you can use the existing platform drivers: drivers/ide/egacy/ide_platform.c or drivers/ata/pata_platform.c. Create/register a platform device named pata_platform with 2 memory and 1 IRQ resource, and enable one of those drivers. For new boards using a flattened device tree, it should be enough to add a device node for the pata_of_platform driver. If you need a device specific setup, you should add a new compatible value in the tree and make the driver handle that in whatever way you need. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: IDE
On Wednesday 10 September 2008, Sébastien Chrétien wrote: I looked falconide.c, it uses hw_regs_t hw; and ide_hwif_t *hwif. Is it a good way ? No, that uses the legacy IDE drivers, not the current ATA drivers, and it is not based on the device tree information. Just use drivers/ata/pata_of_platform.c, you probably don't even need to change the code, just your device tree. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: IDE
Arnd Bergmann wrote: Most probably you can use the existing platform drivers: drivers/ide/egacy/ide_platform.c or drivers/ata/pata_platform.c. Create/register a platform device named pata_platform with 2 memory and 1 IRQ resource, and enable one of those drivers. For new boards using a flattened device tree, it should be enough to add a device node for the pata_of_platform driver. Oops, forgot about this one. No wonder, after being knee deep in ARM for several months. :-) MBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: TQM8349 and ARCH = powerpc
Hi again,
u-boot assigns the IMMR to 0xff40 in TQM834x.h, whereas the device
tree you picked has it at 0xe000 (it's defined in the soc node).
Don't forget to match up the PCI addresses too. patches welcome, of
course (we don't have tqm boards).
So I modified the dts to match the IMMRMBAR and the pci section at
0xff40. In U-Boot I disabled the PCI_CONFIG because I don't need the
PCI bus. But the result is always the same. It looks like the kernel
stops booting at an earlier stage.
I hope it's OK to post my current tqm8349.dts here:
Any suggestions are welcome.
Thanks and bye,
/dts-v1/;
/ {
model = tqc,tqm834x;
compatible = tqc,tqm834x;
#address-cells = 1;
#size-cells = 1;
aliases {
ethernet0 = enet0;
ethernet1 = enet1;
serial0 = serial0;
serial1 = serial1;
pci0 = pci0;
/*pci1 = pci1;*/
};
cpus {
#address-cells = 1;
#size-cells = 0;
PowerPC,[EMAIL PROTECTED] {
device_type = cpu;
reg = 0x0;
d-cache-line-size = 32;
i-cache-line-size = 32;
d-cache-size = 32768;
i-cache-size = 32768;
timebase-frequency = 0; // from bootloader
bus-frequency = 0; // from bootloader
clock-frequency = 0;// from bootloader
};
};
memory {
device_type = memory;
reg = 0x 0x1000;
};
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
device_type = soc;
compatible = simple-bus;
ranges = 0x0 0xff40 0x0010;
reg = 0xff40 0x0200;
bus-frequency = 0;// from bootloader
[EMAIL PROTECTED] {
device_type = watchdog;
compatible = mpc83xx_wdt;
reg = 0x200 0x100;
};
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
compatible = fsl-i2c;
reg = 0x3000 0x100;
interrupts = 14 0x8;
interrupt-parent = ipic;
dfsrr;
};
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
cell-index = 1;
compatible = fsl-i2c;
reg = 0x3100 0x100;
interrupts = 15 0x8;
interrupt-parent = ipic;
dfsrr;
};
[EMAIL PROTECTED] {
cell-index = 0;
compatible = fsl,spi;
reg = 0x7000 0x1000;
interrupts = 16 0x8;
interrupt-parent = ipic;
mode = cpu;
};
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
compatible = fsl,mpc8349-dma, fsl,elo-dma;
reg = 0x82a8 4;
ranges = 0 0x8100 0x1a8;
interrupt-parent = ipic;
interrupts = 71 8;
cell-index = 0;
[EMAIL PROTECTED] {
compatible = fsl,mpc8349-dma-channel, fsl,elo-dma-channel;
reg = 0 0x80;
interrupt-parent = ipic;
interrupts = 71 8;
};
[EMAIL PROTECTED] {
compatible = fsl,mpc8349-dma-channel, fsl,elo-dma-channel;
reg = 0x80 0x80;
interrupt-parent = ipic;
interrupts = 71 8;
};
[EMAIL PROTECTED] {
compatible = fsl,mpc8349-dma-channel, fsl,elo-dma-channel;
reg = 0x100 0x80;
interrupt-parent = ipic;
interrupts = 71 8;
};
[EMAIL PROTECTED] {
compatible = fsl,mpc8349-dma-channel, fsl,elo-dma-channel;
reg = 0x180 0x28;
interrupt-parent = ipic;
interrupts = 71 8;
};
};
[EMAIL PROTECTED] {
compatible = fsl-usb2-mph;
reg = 0x22000 0x1000;
#address-cells = 1;
#size-cells = 0;
interrupt-parent = ipic;
interrupts = 39 0x8;
phy_type = ulpi;
port1;
};
[EMAIL PROTECTED] {
compatible = fsl-usb2-dr;
reg = 0x23000 0x1000;
#address-cells = 1;
#size-cells = 0;
interrupt-parent = ipic;
interrupts = 38 0x8;
dr_mode = peripheral;
phy_type = ulpi;
};
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
compatible = fsl,gianfar-mdio;
reg = 0x24520 0x20;
phy0: [EMAIL PROTECTED] {
interrupt-parent = ipic;
interrupts = 17 0x8;
reg = 0x0;
device_type = ethernet-phy;
};
phy1: [EMAIL PROTECTED] {
interrupt-parent = ipic;
interrupts = 18 0x8;
reg = 0x1;
device_type = ethernet-phy;
};
};
enet0: [EMAIL PROTECTED] {
cell-index = 0;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 0x24000 0x1000;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 32 0x8 33 0x8 34 0x8;
interrupt-parent = ipic;
phy-handle = phy0;
linux,network-index = 0;
};
enet1: [EMAIL PROTECTED] {
cell-index = 1;
device_type = network;
model = TSEC;
compatible = gianfar;
reg = 0x25000 0x1000;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 35 0x8 36 0x8 37 0x8;
interrupt-parent = ipic;
phy-handle = phy1;
linux,network-index = 1;
};
[PATCH] ib/ehca: add flush CQE generation
When a QP goes into error state, it is required that flush CQEs are
delivered to the application for any outstanding work requests. eHCA does not
do this in hardware, so this patch adds software flush CQE generation to the
ehca driver.
Whenever a QP gets into error state, it is added to the QP error list of its
respective CQ. If the error QP list of a CQ is not empty, poll_cq()
generates flush CQEs before polling the actual CQ.
Signed-off-by: Alexander Schmidt [EMAIL PROTECTED]
---
Applies on top of 2.6.27-rc3, please consider this for 2.6.28.
drivers/infiniband/hw/ehca/ehca_classes.h | 14 +
drivers/infiniband/hw/ehca/ehca_cq.c |3
drivers/infiniband/hw/ehca/ehca_iverbs.h |2
drivers/infiniband/hw/ehca/ehca_qp.c | 225 --
drivers/infiniband/hw/ehca/ehca_reqs.c| 211
5 files changed, 412 insertions(+), 43 deletions(-)
--- infiniband.git.orig/drivers/infiniband/hw/ehca/ehca_classes.h
+++ infiniband.git/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -164,6 +164,13 @@ struct ehca_qmap_entry {
u16 reported;
};
+struct ehca_queue_map {
+ struct ehca_qmap_entry *map;
+ unsigned int entries;
+ unsigned int tail;
+ unsigned int left_to_poll;
+};
+
struct ehca_qp {
union {
struct ib_qp ib_qp;
@@ -173,8 +180,9 @@ struct ehca_qp {
enum ehca_ext_qp_type ext_type;
enum ib_qp_state state;
struct ipz_queue ipz_squeue;
- struct ehca_qmap_entry *sq_map;
+ struct ehca_queue_map sq_map;
struct ipz_queue ipz_rqueue;
+ struct ehca_queue_map rq_map;
struct h_galpas galpas;
u32 qkey;
u32 real_qp_num;
@@ -204,6 +212,8 @@ struct ehca_qp {
atomic_t nr_events; /* events seen */
wait_queue_head_t wait_completion;
int mig_armed;
+ struct list_head sq_err_node;
+ struct list_head rq_err_node;
};
#define IS_SRQ(qp) (qp-ext_type == EQPT_SRQ)
@@ -233,6 +243,8 @@ struct ehca_cq {
/* mmap counter for resources mapped into user space */
u32 mm_count_queue;
u32 mm_count_galpa;
+ struct list_head sqp_err_list;
+ struct list_head rqp_err_list;
};
enum ehca_mr_flag {
--- infiniband.git.orig/drivers/infiniband/hw/ehca/ehca_reqs.c
+++ infiniband.git/drivers/infiniband/hw/ehca/ehca_reqs.c
@@ -53,9 +53,25 @@
/* in RC traffic, insert an empty RDMA READ every this many packets */
#define ACK_CIRC_THRESHOLD 200
+static u64 replace_wr_id(u64 wr_id, u16 idx)
+{
+ u64 ret;
+
+ ret = wr_id ~QMAP_IDX_MASK;
+ ret |= idx QMAP_IDX_MASK;
+
+ return ret;
+}
+
+static u16 get_app_wr_id(u64 wr_id)
+{
+ return wr_id QMAP_IDX_MASK;
+}
+
static inline int ehca_write_rwqe(struct ipz_queue *ipz_rqueue,
struct ehca_wqe *wqe_p,
- struct ib_recv_wr *recv_wr)
+ struct ib_recv_wr *recv_wr,
+ u32 rq_map_idx)
{
u8 cnt_ds;
if (unlikely((recv_wr-num_sge 0) ||
@@ -69,7 +85,7 @@ static inline int ehca_write_rwqe(struct
/* clear wqe header until sglist */
memset(wqe_p, 0, offsetof(struct ehca_wqe, u.ud_av.sg_list));
- wqe_p-work_request_id = recv_wr-wr_id;
+ wqe_p-work_request_id = replace_wr_id(recv_wr-wr_id, rq_map_idx);
wqe_p-nr_of_data_seg = recv_wr-num_sge;
for (cnt_ds = 0; cnt_ds recv_wr-num_sge; cnt_ds++) {
@@ -146,6 +162,7 @@ static inline int ehca_write_swqe(struct
u64 dma_length;
struct ehca_av *my_av;
u32 remote_qkey = send_wr-wr.ud.remote_qkey;
+ struct ehca_qmap_entry *qmap_entry = qp-sq_map.map[sq_map_idx];
if (unlikely((send_wr-num_sge 0) ||
(send_wr-num_sge qp-ipz_squeue.act_nr_of_sg))) {
@@ -158,11 +175,10 @@ static inline int ehca_write_swqe(struct
/* clear wqe header until sglist */
memset(wqe_p, 0, offsetof(struct ehca_wqe, u.ud_av.sg_list));
- wqe_p-work_request_id = send_wr-wr_id ~QMAP_IDX_MASK;
- wqe_p-work_request_id |= sq_map_idx QMAP_IDX_MASK;
+ wqe_p-work_request_id = replace_wr_id(send_wr-wr_id, sq_map_idx);
- qp-sq_map[sq_map_idx].app_wr_id = send_wr-wr_id QMAP_IDX_MASK;
- qp-sq_map[sq_map_idx].reported = 0;
+ qmap_entry-app_wr_id = get_app_wr_id(send_wr-wr_id);
+ qmap_entry-reported = 0;
switch (send_wr-opcode) {
case IB_WR_SEND:
@@ -496,7 +512,9 @@ static int internal_post_recv(struct ehc
struct ehca_wqe *wqe_p;
int wqe_cnt = 0;
int ret = 0;
+ u32 rq_map_idx;
unsigned long flags;
+ struct ehca_qmap_entry *qmap_entry;
if (unlikely(!HAS_RQ(my_qp))) {
ehca_err(dev, QP has no RQ ehca_qp=%p qp_num=%x ext_type=%d,
@@ -524,8 +542,15 @@ static int internal_post_recv(struct ehc
}
Re: [PATCH] fix compile failure with non modular builds
On Wed, 10 Sep 2008 10:46:39 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: I must admit that none of my test configs I think has module support turned off (even if I tend to have all the stuff I need built-in). And our allnoconfig turns off CONFIG_64BIT, so we didn't see it in any of our automated builds. :-( -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpFkx6rpqPRk.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: IDE
ok I will use the flat device tree. Do you utils in order to use ata and check ata link ? For example, to read some information of my compact flash 2008/9/10, Sergei Shtylyov [EMAIL PROTECTED]: Arnd Bergmann wrote: Most probably you can use the existing platform drivers: drivers/ide/egacy/ide_platform.c or drivers/ata/pata_platform.c. Create/register a platform device named pata_platform with 2 memory and 1 IRQ resource, and enable one of those drivers. For new boards using a flattened device tree, it should be enough to add a device node for the pata_of_platform driver. Oops, forgot about this one. No wonder, after being knee deep in ARM for several months. :-) MBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ppc4xx: Allow 4xx PCI bridge to be disabled via device tree
This patch allows the 4xx (conventional) PCI bridge to be disabled
via the device tree. This is needed for 4xx PCI adapter hardware.
Use the PCI node's status property to disable the PCI bridge.
Signed-off-by: Matthias Fuchs [EMAIL PROTECTED]
---
arch/powerpc/sysdev/ppc4xx_pci.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index fb368df..8c13d4f 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -277,9 +277,16 @@ static void __init ppc4xx_probe_pci_bridge(struct
device_node *np)
const int *bus_range;
int primary = 0;
+ /* Check if device is enabled */
+ if (!of_device_is_available(np)) {
+ printk(KERN_INFO %s: Port disabled via device-tree\n,
+ np-full_name);
+ return;
+ }
+
/* Fetch config space registers address */
if (of_address_to_resource(np, 0, rsrc_cfg)) {
- printk(KERN_ERR %s:Can't get PCI config register base !,
+ printk(KERN_ERR %s: Can't get PCI config register base !,
np-full_name);
return;
}
--
1.5.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
interrupt cells on mpc5200
mpc5200 interrupts have three cells in the device tree. How are these
interpreted?
Middle one is the interrupt number. Last one seems to always be zero.
What does the first one do, edge/level?
I searched through /Documentation and could find anything about three
cells for interrupts.
I understand the first one for gpio_wkup on interrupt 8. How does a
gpio_wkup generate an interrupt on interrupt 3?
gpio_wkup: [EMAIL PROTECTED] {
compatible =
fsl,mpc5200b-gpio-wkup,fsl,mpc5200-gpio-wkup;
reg = 0xc00 0x40;
interrupts = 0x1 0x8 0x0 0x0 0x3 0x0;
interrupt-parent = mpc5200_pic;
gpio-controller;
#gpio-cells = 2;
};
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: interrupt cells on mpc5200
Jon Smirl wrote:
mpc5200 interrupts have three cells in the device tree. How are these
interpreted?
Middle one is the interrupt number. Last one seems to always be zero.
What does the first one do, edge/level?
I searched through /Documentation and could find anything about three
cells for interrupts.
I understand the first one for gpio_wkup on interrupt 8. How does a
gpio_wkup generate an interrupt on interrupt 3?
gpio_wkup: [EMAIL PROTECTED] {
compatible =
fsl,mpc5200b-gpio-wkup,fsl,mpc5200-gpio-wkup;
reg = 0xc00 0x40;
interrupts = 0x1 0x8 0x0 0x0 0x3 0x0;
interrupt-parent = mpc5200_pic;
gpio-controller;
#gpio-cells = 2;
};
See
http://lxr.linux.no/linux+v2.6.26.5/Documentation/powerpc/mpc52xx-device-tree-bindings.txt#L263
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: TQM8349 and ARCH = powerpc
On Wed, 10 Sep 2008 16:12:22 +0200 Oliver Rutsch [EMAIL PROTECTED] wrote: model = tqc,tqm834x; compatible = tqc,tqm834x; you need a arch/powerpc/platforms/83xx/tqm834x.c file that matches this. Kim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: interrupt cells on mpc5200
On Wed, Sep 10, 2008 at 12:54 PM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
mpc5200 interrupts have three cells in the device tree. How are these
interpreted?
Middle one is the interrupt number. Last one seems to always be zero.
What does the first one do, edge/level?
I searched through /Documentation and could find anything about three
cells for interrupts.
I understand the first one for gpio_wkup on interrupt 8. How does a
gpio_wkup generate an interrupt on interrupt 3?
gpio_wkup: [EMAIL PROTECTED] {
compatible =
fsl,mpc5200b-gpio-wkup,fsl,mpc5200-gpio-wkup;
reg = 0xc00 0x40;
interrupts = 0x1 0x8 0x0 0x0 0x3 0x0;
interrupt-parent = mpc5200_pic;
gpio-controller;
#gpio-cells = 2;
};
See
http://lxr.linux.no/linux+v2.6.26.5/Documentation/powerpc/mpc52xx-device-tree-bindings.txt#L263
Why was I too blind to see that file? So there must be someway to turn
a gpio_wkup into a critical interrupt which causes the interrupt 3
which is a feature I don't need.
Any hints on a good way to measure the length of pulses? They are
between 500us and 2ms long. I was thinking of using an interrupt on
the leading edge, starting a timer, and then flipping the gpio to
cause an interrupt on the trailing edge. I don't need extreme
accuracy.
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH/RFC] 64 bit csum_partial_copy_generic
The current 64 bit csum_partial_copy_generic function is based on the 32 bit version and never was optimized for 64 bit. This patch takes the 64 bit memcpy and adapts it to also do the sum. It has been tested on a variety of input sizes and alignments on Power5 and Power6 processors. It gives correct output for all cases tested. It also runs 20-55% faster than the implemention it replaces depending on size, alignment, and processor. I think there is still some room for improvement in the unaligned case, but given that it is much faster than what we have now I figured I'd send it out. Signed-off-by: Joel Schopp[EMAIL PROTECTED] Index: 2.6.26/arch/powerpc/lib/checksum_64.S === --- 2.6.26.orig/arch/powerpc/lib/checksum_64.S +++ 2.6.26/arch/powerpc/lib/checksum_64.S @@ -22,8 +22,7 @@ * len is in words and is always = 5. * * In practice len == 5, but this is not guaranteed. So this code does not - * attempt to use doubleword instructions. - */ + * attempt to use doubleword instructions. */ _GLOBAL(ip_fast_csum) lwz r0,0(r3) lwzur5,4(r3) @@ -122,108 +121,286 @@ _GLOBAL(csum_partial) * to *src_err or *dst_err respectively, and (for an error on * src) zeroes the rest of dst. * - * This code needs to be reworked to take advantage of 64 bit sum+copy. - * However, due to tokenring halfword alignment problems this will be very - * tricky. For now we'll leave it until we instrument it somehow. + * This returns a 32 bit 1s complement sum that can be folded to 16 bits and + * notted to produce a 16bit tcp/ip checksum. * * csum_partial_copy_generic(r3=src, r4=dst, r5=len, r6=sum, r7=src_err, r8=dst_err) */ _GLOBAL(csum_partial_copy_generic) - addic r0,r6,0 - subir3,r3,4 - subir4,r4,4 - srwi. r6,r5,2 - beq 3f /* if we're doing 4 bytes */ - andi. r9,r4,2 /* Align dst to longword boundary */ - beq+1f -81:lhz r6,4(r3)/* do 2 bytes to get aligned */ - addir3,r3,2 - subir5,r5,2 -91:sth r6,4(r4) - addir4,r4,2 - addcr0,r0,r6 - srwi. r6,r5,2 /* # words to do */ + std r7,48(r1) /* we need to save the error pointers ...*/ + std r8,56(r1) /* we need to save the error pointers ...*/ + PPC_MTOCRF 0x01,r5 + cmpldi cr1,r5,16 + neg r11,r4 # LS 3 bits = # bytes to 8-byte dest bdry + andi. r11,r11,7 + dcbt0,r3 + blt cr1,.Lshort_copy + bne .Ldst_unaligned +.Ldst_aligned: + andi. r0,r3,7 + addir4,r4,-16 + bne .Lsrc_unaligned + srdir10,r5,4/* src and dst aligned */ +80:ld r9,0(r3) + addir3,r3,-8 + mtctr r10 + andi. r5,r5,7 + bf cr7*4+0,2f + addir4,r4,8 + addir3,r3,8 + mr r12,r9 + blt cr1,3f +1: +81:ld r9,8(r3) +82:std r12,8(r4) + adder6,r6,r12 /* add to checksum */ +2: +83:ldu r12,16(r3) +84:stdur9,16(r4) + adder6,r6,r9/* add to checksum */ + bdnz1b +3: +85:std r12,8(r4) + adder6,r6,r12 /* add to checksum */ beq 3f -1: mtctr r6 -82:lwzur6,4(r3)/* the bdnz has zero overhead, so it should */ -92:stwur6,4(r4)/* be unnecessary to unroll this loop */ - adder0,r0,r6 - bdnz82b - andi. r5,r5,3 -3: cmpwi 0,r5,2 - blt+4f -83:lhz r6,4(r3) + addir4,r4,16 + ld r9,8(r3) +.Ldo_tail: + bf cr7*4+1,1f + rotldi r9,r9,32 +86:stw r9,0(r4) + adder6,r6,r9/* add to checksum */ + addir4,r4,4 +1: bf cr7*4+2,2f + rotldi r9,r9,16 +87:sth r9,0(r4) + adder6,r6,r9/* add to checksum */ + addir4,r4,2 +2: bf cr7*4+3,3f + rotldi r9,r9,8 +88:stb r9,0(r4) + adder6,r6,r9/* add to checksum */ +3: addze r6,r6 /* add in final carry (unlikely with 64-bit regs) */ +rldicl r9,r6,32,0/* fold 64 bit value */ +add r3,r9,r6 +srdir3,r3,32 + blr /* return sum */ + +.Lsrc_unaligned: + srdir11,r5,3 + addir5,r5,-16 + subfr3,r0,r3 + srdir7,r5,4 + sldir10,r0,3 + cmpdi cr6,r11,3 + andi. r5,r5,7 + mtctr r7 + subfic r12,r10,64 + add r5,r5,r0 + + bt cr7*4+0,0f + +115: ld r9,0(r3)# 3+2n loads, 2+2n stores +116: ld r0,8(r3) + sld r11,r9,r10 +117: ldu r9,16(r3) + srd r7,r0,r12 + sld r8,r0,r10 + or r7,r7,r11 + blt cr6,4f +118: ld r0,8(r3) +
arch/powerpc/boot/.gitignore questions
Hi, I was looking at the arch/powerpc/boot/.gitignore file. Why are all of those non-local-directory files listed there? E.g., empty.c, inf*.c, inf*.h, zconf.h, zlib.h, zutil.h, etc. And what is dtc? I see a dtc-src directory, but dtc is MIA. Same for kernel-vmlinux.strip.* Thanks, ~Randy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: arch/powerpc/boot/.gitignore questions
On Wed, 10 Sep 2008 12:24:05 -0700 Randy Dunlap [EMAIL PROTECTED] wrote: Hi, I was looking at the arch/powerpc/boot/.gitignore file. Why are all of those non-local-directory files listed there? E.g., empty.c, inf*.c, inf*.h, zconf.h, zlib.h, zutil.h, etc. And what is dtc? I see a dtc-src directory, but dtc is MIA. ./arch/powerpc/boot/dtc I believe if the dts is built into u-boot, the dtc is not built. Same for kernel-vmlinux.strip.* I don't see a vmlinux.strip.* rule. I ignore vmlinux.strip. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: arch/powerpc/boot/.gitignore questions
Dear Sean MacLennan, In message [EMAIL PROTECTED] you wrote: I believe if the dts is built into u-boot, the dtc is not built. This is never the case. The device tree is considered to be part of and provided to the boot loader by the kernel. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Mr. Cole's Axiom: The sum of the intelligence on the planet is a constant; the population is growing. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: arch/powerpc/boot/.gitignore questions
Wolfgang Denk wrote: Dear Sean MacLennan, In message [EMAIL PROTECTED] you wrote: I believe if the dts is built into u-boot, the dtc is not built. This is never the case. The device tree is considered to be part of and provided to the boot loader by the kernel. No, it's provided to the kernel by the firmware. That the repository for the files that the user provides to u-boot for this purpose happens to live in the Linux source tree is irrelevant. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: arch/powerpc/boot/.gitignore questions
Randy Dunlap wrote: I was looking at the arch/powerpc/boot/.gitignore file. Why are all of those non-local-directory files listed there? E.g., empty.c, inf*.c, inf*.h, zconf.h, zlib.h, zutil.h, etc. Why would these files be listed in arch/powerpc/boot/.gitignore ?? Because they're created when building a bootwrapper? And what is dtc? I see a dtc-src directory, but dtc is MIA. ./arch/powerpc/boot/dtc Where do you see that? That's not in 2.6.27-rc6 nor in the current powerpc.git tree. They both have: Of course not -- it wouldn't be in gitignore if it weren't a generated file. pwd /var/linsrc/lin2627-rc6/arch/powerpc/boot ls -ld dt* drwxr-xr-x 2 rdunlap users 4096 Jul 13 14:51 dtc-src/ drwxr-xr-x 2 rdunlap users 4096 Sep 9 19:33 dts/ which leads me to believe that the .gitignore entry should be either dts or dtc-src or both, but not dtc. Why would we want to ignore source directories? dtc is the binary that is built from dtc-src. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC PATCH] Support for big page sizes on 44x
This adds support for selecting page size on PPC 44x. However there are still number of problems: 1. We can't use default PKMAP_BASE definition with 64KB/256KB pages so we change it. Not sure that it's optimal. Then redefined PKMAP_BASE is not aligned on (1PMD_SHIFT), don't know if it is really bad. 2. with 16KB/64KB/256KB pages WARN_ON(!pmd_none(*pmd)) is triggered inside dma_alloc_init() function. Not sure if it is really bad. 3. with 256KB pages ENTRIES_PER_PAGEPAGE in mm/shem.c become zero. Second patch tries to address this issue. 4. Ugly ppc_page_asm.h file. I'd prefer to see these defines calculated instead of being hardcoded but PTE_SHIFT and PMD_SHIFT are declared inside #ifndef __ASSEMBLY__. Don't know why. We would appreciate any comment. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for
This patch adds support for page sizes bigger than 4KB (16KB/64KB/256KB) on
PPC 44x.
Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED]
Signed-off-by: Ilya Yanok [EMAIL PROTECTED]
---
arch/powerpc/Kconfig| 23 +
arch/powerpc/include/asm/highmem.h |8 +++-
arch/powerpc/include/asm/page.h | 26 +-
arch/powerpc/include/asm/page_32.h |4 ++
arch/powerpc/include/asm/ppc_page_asm.h | 75 +++
arch/powerpc/include/asm/thread_info.h |4 ++
arch/powerpc/kernel/head_44x.S | 21 +---
arch/powerpc/kernel/head_booke.h|7 ++-
arch/powerpc/kernel/misc_32.S | 13 +++---
arch/powerpc/mm/pgtable_32.c|2 +-
10 files changed, 162 insertions(+), 21 deletions(-)
create mode 100644 arch/powerpc/include/asm/ppc_page_asm.h
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 587da5e..ca93157 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -413,6 +413,29 @@ config PPC_64K_PAGES
while on hardware with such support, it will be used to map
normal application pages.
+choice
+ prompt Page size
+ depends on 44x PPC32
+ default PPC32_4K_PAGES
+ help
+ The PAGE_SIZE definition. Increasing the page size may
+ improve the system performance in some dedicated cases.
+ If unsure, set it to 4 KB.
+
+config PPC32_4K_PAGES
+ bool 4k page size
+
+config PPC32_16K_PAGES
+ bool 16k page size
+
+config PPC32_64K_PAGES
+ bool 64k page size
+
+config PPC32_256K_PAGES
+ bool 256k page size
+
+endchoice
+
config FORCE_MAX_ZONEORDER
int Maximum zone order
default 9 if PPC_64K_PAGES
diff --git a/arch/powerpc/include/asm/highmem.h
b/arch/powerpc/include/asm/highmem.h
index 5d99b64..1aec96d 100644
--- a/arch/powerpc/include/asm/highmem.h
+++ b/arch/powerpc/include/asm/highmem.h
@@ -38,9 +38,15 @@ extern pte_t *pkmap_page_table;
* easily, subsequent pte tables have to be allocated in one physical
* chunk of RAM.
*/
+#if defined(CONFIG_PPC32_64K_PAGES) || defined(CONFIG_PPC32_256K_PAGES)
+#define PKMAP_ORDER(27 - PAGE_SHIFT)
+#define LAST_PKMAP (1 PKMAP_ORDER)
+#define PKMAP_BASE (FIXADDR_START - PAGE_SIZE*(LAST_PKMAP + 1))
+#else
#define LAST_PKMAP (1 PTE_SHIFT)
-#define LAST_PKMAP_MASK (LAST_PKMAP-1)
#define PKMAP_BASE ((FIXADDR_START - PAGE_SIZE*(LAST_PKMAP + 1))
PMD_MASK)
+#endif
+#define LAST_PKMAP_MASK(LAST_PKMAP-1)
#define PKMAP_NR(virt) ((virt-PKMAP_BASE) PAGE_SHIFT)
#define PKMAP_ADDR(nr) (PKMAP_BASE + ((nr) PAGE_SHIFT))
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index e088545..1de90b4 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -15,12 +15,17 @@
#include asm/types.h
/*
- * On PPC32 page size is 4K. For PPC64 we support either 4K or 64K software
+ * On regular PPC32 page size is 4K (but we support 4K/16K/64K/256K pages
+ * on PPC44x). For PPC64 we support either 4K or 64K software
* page size. When using 64K pages however, whether we are really supporting
* 64K pages in HW or not is irrelevant to those definitions.
*/
-#ifdef CONFIG_PPC_64K_PAGES
+#if defined(CONFIG_PPC32_256K_PAGES)
+#define PAGE_SHIFT 18
+#elif defined(CONFIG_PPC32_64K_PAGES) || defined(CONFIG_PPC_64K_PAGES)
#define PAGE_SHIFT 16
+#elif defined(CONFIG_PPC32_16K_PAGES)
+#define PAGE_SHIFT 14
#else
#define PAGE_SHIFT 12
#endif
@@ -140,11 +145,19 @@ typedef struct { pte_basic_t pte; } pte_t;
/* 64k pages additionally define a bigger real PTE type that gathers
* the second half part of the PTE for pseudo 64k pages
*/
+#ifdef CONFIG_PPC64
#ifdef CONFIG_PPC_64K_PAGES
typedef struct { pte_t pte; unsigned long hidx; } real_pte_t;
#else
typedef struct { pte_t pte; } real_pte_t;
#endif
+#else
+#ifdef CONFIG_PPC32_4K_PAGES
+typedef struct { pte_t pte; } real_pte_t;
+#else
+typedef struct { pte_t pte; unsigned long hidx; } real_pte_t;
+#endif
+#endif /* !CONFIG_PPC64 */
/* PMD level */
#ifdef CONFIG_PPC64
@@ -180,12 +193,19 @@ typedef pte_basic_t pte_t;
#define pte_val(x) (x)
#define __pte(x) (x)
+#ifdef CONFIG_PPC64
#ifdef CONFIG_PPC_64K_PAGES
typedef struct { pte_t pte; unsigned long hidx; } real_pte_t;
#else
typedef unsigned long real_pte_t;
#endif
-
+#else
+#ifdef CONFIG_PPC32_4K_PAGES
+typedef unsigned long real_pte_t;
+#else
+typedef struct { pte_t pte; unsigned long hidx; } real_pte_t;
+#endif
+#endif /* !PPC64 */
#ifdef CONFIG_PPC64
typedef unsigned long pmd_t;
diff --git a/arch/powerpc/include/asm/page_32.h
b/arch/powerpc/include/asm/page_32.h
index ebfae53..d176270 100644
--- a/arch/powerpc/include/asm/page_32.h
+++ b/arch/powerpc/include/asm/page_32.h
@@ -20,7 +20,11 @@
*/
#ifdef CONFIG_PTE_64BIT
typedef unsigned long long pte_basic_t;
+#ifdef CONFIG_PPC32_256K_PAGES
[PATCH] mm: fix ENTRIES_PER_PAGEPAGE overflow with 256KB pages
ENTRIES_PER_PAGEPAGE define in mm/shmem.c becomes zero if page size is 256KB. This patch fixes this. Signed-off-by: Ilya Yanok [EMAIL PROTECTED] --- mm/shmem.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/mm/shmem.c b/mm/shmem.c index 04fb4f1..c603427 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -59,7 +59,7 @@ #define TMPFS_MAGIC0x01021994 #define ENTRIES_PER_PAGE (PAGE_CACHE_SIZE/sizeof(unsigned long)) -#define ENTRIES_PER_PAGEPAGE (ENTRIES_PER_PAGE*ENTRIES_PER_PAGE) +#define ENTRIES_PER_PAGEPAGE ((unsigned long long)ENTRIES_PER_PAGE*ENTRIES_PER_PAGE) #define BLOCKS_PER_PAGE (PAGE_CACHE_SIZE/512) #define SHMEM_MAX_INDEX (SHMEM_NR_DIRECT + (ENTRIES_PER_PAGEPAGE/2) * (ENTRIES_PER_PAGE+1)) @@ -519,7 +519,7 @@ static void shmem_truncate_range(struct inode *inode, loff_t start, loff_t end) struct shmem_inode_info *info = SHMEM_I(inode); unsigned long idx; unsigned long size; - unsigned long limit; + unsigned long long limit; unsigned long stage; unsigned long diroff; struct page **dir; @@ -535,7 +535,7 @@ static void shmem_truncate_range(struct inode *inode, loff_t start, loff_t end) int punch_hole; spinlock_t *needs_lock; spinlock_t *punch_lock; - unsigned long upper_limit; + unsigned long long upper_limit; inode-i_ctime = inode-i_mtime = CURRENT_TIME; idx = (start + PAGE_CACHE_SIZE - 1) PAGE_CACHE_SHIFT; -- 1.5.6.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: arch/powerpc/boot/.gitignore questions
Scott Wood wrote: Randy Dunlap wrote: I was looking at the arch/powerpc/boot/.gitignore file. Why are all of those non-local-directory files listed there? E.g., empty.c, inf*.c, inf*.h, zconf.h, zlib.h, zutil.h, etc. Why would these files be listed in arch/powerpc/boot/.gitignore ?? Because they're created when building a bootwrapper? And what is dtc? I see a dtc-src directory, but dtc is MIA. ./arch/powerpc/boot/dtc Where do you see that? That's not in 2.6.27-rc6 nor in the current powerpc.git tree. They both have: Of course not -- it wouldn't be in gitignore if it weren't a generated file. pwd /var/linsrc/lin2627-rc6/arch/powerpc/boot ls -ld dt* drwxr-xr-x 2 rdunlap users 4096 Jul 13 14:51 dtc-src/ drwxr-xr-x 2 rdunlap users 4096 Sep 9 19:33 dts/ which leads me to believe that the .gitignore entry should be either dts or dtc-src or both, but not dtc. Why would we want to ignore source directories? dtc is the binary that is built from dtc-src. Thanks. Got it. ~Randy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Question on 4xx GIT tree
Hi Josh, I have few questions. Should I base my patch from your master branch or your 'next' branch? The 'next' branch would be best. I saw that both your master and next branches have removed the 4xx dma and USB drivers. The dma drivers for 4xx used to under: drivers/dma/ppc440spe-adma.c The usb driver for 4xx used to be under: drivers/usb/gadget/dwc_otg/* The whole dwc_otg directory got removed. Do you know the reason why these drivers were removed? Also, are there plans to get these drivers back? Please let me know. Regards, Prodyut Hazarika ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Question on 4xx GIT tree
On Wed, 10 Sep 2008 16:47:48 -0700 Prodyut Hazarika [EMAIL PROTECTED] wrote: Hi Josh, I have few questions. Should I base my patch from your master branch or your 'next' branch? The 'next' branch would be best. I saw that both your master and next branches have removed the 4xx dma and USB drivers. The dma drivers for 4xx used to under: drivers/dma/ppc440spe-adma.c The usb driver for 4xx used to be under: drivers/usb/gadget/dwc_otg/* The whole dwc_otg directory got removed. Those drivers were never in any version of the upstream kernel according to git. [EMAIL PROTECTED] linux-2.6]$ git checkout master Switched to branch master [EMAIL PROTECTED] linux-2.6]$ git log -- drivers/dma/ppc440spe-adma.c [EMAIL PROTECTED] linux-2.6]$ git log -- drivers/usb/gadget/dwc_otg [EMAIL PROTECTED] linux-2.6]$ Do you know the reason why these drivers were removed? Also, are there plans to get these drivers back? Please let me know. Perhaps they are in the DENX kernel? If so, someone would need to submit them for inclusion. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Question on 4xx GIT tree
Hi Josh, Do you know the reason why these drivers were removed? Also, are there plans to get these drivers back? Please let me know. Perhaps they are in the DENX kernel? If so, someone would need to submit them for inclusion. Yes those drivers were in the Denx kernel. I was in the impression that they were in the mainline Linux tree too. I will try to get those drivers submitted to the main Linux tree. Thanks for your clarifications. Regards, Prodyut Hazarika ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Get USE_STRICT_MM_TYPECHECKS working again
On Tue, Sep 09, 2008 at 02:09:56PM +0200, Christoph Hellwig wrote: On Tue, Sep 09, 2008 at 03:04:47PM +1000, David Gibson wrote: The typesafe version of the powerpc pagetable handling (with USE_STRICT_MM_TYPECHECKS defined) has bitrotted again. This patch makes a bunch of small fixes to get it building again. It might be a better idea to mark these types __bitwise and use sparse to do the stricter checking.. Uh.. I don't think that would do quite the same thing. In particular it wouldn't catch assignments between (say) pmd_t and pte_t. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3 v2] ibm_newemac: Various fixes and additions for PPC405EZ
On Mon, 8 Sep 2008 08:44:59 -0400 Josh Boyer [EMAIL PROTECTED] wrote: The following patch series adds things needed to support the PowerPC 405EZ SoC. I've incorporated the suggestions and fixes from the previous round of patches and barring any further comments these should be ready to go. josh Josh Boyer (3): ibm_newemac: Allow the no flow control EMAC feature to work ibm_newemac: Introduce mal_has_feature ibm_newemac: MAL support for PowerPC 405EZ I should mention that I have a platform support patch series that depends on these for working ethernet. I can bring this set in through my tree at the same time if the patches look fine and Jeff acks that. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Getting Debian to release the PowerPC port
Dear Paul, I would like to ask you a few things: * which is the official dtc git repository? I ask it here because dtc.ozlabs.org doesn't seem to work, but this is what is linked to from the page http://ozlabs.org/ and the device-tree-compiler package on Debian has an outdated page (it seems). I already filed a bugreport to that package (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497605). * where can I find the people responsible for glibc and gcc/g++ so that I can fill in the empty fields at http://wiki.debian.org/powerpcLennyReleaseRecertification, so that powerpc does not become at risk of not being released? Is the powerpc port cared by some team in special or is it just a unified upstream? Thanks in advance, Rogério Brito. -- Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc4xx: Allow 4xx PCI bridge to be disabled via device tree
On Wednesday 10 September 2008, Matthias Fuchs wrote: This patch allows the 4xx (conventional) PCI bridge to be disabled via the device tree. This is needed for 4xx PCI adapter hardware. Use the PCI node's status property to disable the PCI bridge. Signed-off-by: Matthias Fuchs [EMAIL PROTECTED] Acked-by: Stefan Roese [EMAIL PROTECTED] Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Question on 4xx GIT tree
On Thursday 11 September 2008, Prodyut Hazarika wrote: Do you know the reason why these drivers were removed? Also, are there plans to get these drivers back? Please let me know. Perhaps they are in the DENX kernel? If so, someone would need to submit them for inclusion. Yes those drivers were in the Denx kernel. Correct. I was in the impression that they were in the mainline Linux tree too. I will try to get those drivers submitted to the main Linux tree. Great. But prepare for a lot of work to get the USB OTG driver into shape for upstream acceptance. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
