* How to handle patches that cross maintainers?
From: Kumar Gala @ 2007-07-03 9:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list, Paul Mackerras, Linux Kernel Development
Andrew,
I was hoping to get your input on how to handle patches that cross
maintainers. I've got a patch that is pretty PPC specific, but
happens to touch some drivers as well.
Here's the diffstat to get a rough idea:
arch/powerpc/kernel/io.c | 12 ++++++------
arch/powerpc/mm/hash_native_64.c | 2 +-
arch/powerpc/mm/stab.c | 4 ++--
drivers/ide/pci/scc_pata.c | 4 ++--
drivers/media/dvb/bt8xx/bt878.h | 5 ++---
drivers/serial/cpm_uart/cpm_uart_core.c | 2 +-
include/asm-powerpc/system.h | 2 +-
7 files changed, 15 insertions(+), 16 deletions(-)
Now, I've had this issue before w/o any good sense on how to handle it.
Suggestions?
- k
^ permalink raw reply
* Re: Patches added to 2.6.23 branch
From: Zang Roy-r61911 @ 2007-07-03 8:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <D7FB6C3D-BBA4-45A9-84CA-3D671D1FAEB8@kernel.crashing.org>
On Tue, 2007-07-03 at 16:32, Kumar Gala wrote:
> On Jul 3, 2007, at 3:25 AM, Zang Roy-r61911 wrote:
>
> > Paul
> >
> > Could you help to add these patches:
> >
> > 1 add cuboot for 7448hpc2 board
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036834.html
>
> Reviewing this one.
>
It has been stayed in the list for more than one month.
I need it go into 2.6.23.
Roy
^ permalink raw reply
* Re: Patches added to 2.6.23 branch
From: Kumar Gala @ 2007-07-03 8:32 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1183451146.14800.4.camel@localhost.localdomain>
On Jul 3, 2007, at 3:25 AM, Zang Roy-r61911 wrote:
> Paul
>
> Could you help to add these patches:
>
> 1 add cuboot for 7448hpc2 board
> http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036834.html
Reviewing this one.
> 2. Remove redundant pci_read_irq_line() function for 85xx platform
> Acked by Ben
> http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037117.html
>
> 3. Fix e500 v2 core reboot bug
> http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037799.html
>
> 4. Document the global utilities node define and example
>
> http://ozlabs.org/pipermail/linuxppc-dev/2007-June/038136.html
> http://ozlabs.org/pipermail/linuxppc-dev/2007-June/038137.html
I've pulled all these into my tree.
- k
^ permalink raw reply
* RE: Anyone using QE UART mode?
From: Li Yang-r58472 @ 2007-07-03 8:32 UTC (permalink / raw)
To: Ying Lin, Tabi Timur-B04825; +Cc: linuxppc-embedded
In-Reply-To: <8F798BFDA851B943B3A1B2510E9287850350A908@airmail.wirelessworld.airvananet.com>
> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org] On
Behalf
> Of Ying Lin
> Sent: Tuesday, July 03, 2007 12:02 AM
> To: Tabi Timur-B04825
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: Anyone using QE UART mode?
>=20
> OK, the missing piece (UART driver) I am looking for is not available
> yet. I will seek alternative solutions (create a simple UART driver,
or
> just wait).
Which chip are you using? There should be separate 16550 compatible
UART controller on MPC8360. The driver is already there and working
pretty well.
- Leo
^ permalink raw reply
* [PATCH] pata_mpc52xx: suspend/resume support
From: Domen Puncer @ 2007-07-03 8:27 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linux-ide
Implement suspend and resume routines for mpc52xx ata driver.
Tested on Lite5200b with deep-sleep and low-power (not yet in-tree)
modes.
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
---
If anyone cares, I attached ATA_DEBUG messages at the end of patch.
Should it take almost 5 seconds?
drivers/ata/pata_mpc52xx.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
Index: work-powerpc.git/drivers/ata/pata_mpc52xx.c
===================================================================
--- work-powerpc.git.orig/drivers/ata/pata_mpc52xx.c
+++ work-powerpc.git/drivers/ata/pata_mpc52xx.c
@@ -467,13 +467,27 @@ mpc52xx_ata_remove(struct of_device *op)
static int
mpc52xx_ata_suspend(struct of_device *op, pm_message_t state)
{
- return 0; /* FIXME : What to do here ? */
+ struct ata_host *host = dev_get_drvdata(&op->dev);
+
+ return ata_host_suspend(host, state);
}
static int
mpc52xx_ata_resume(struct of_device *op)
{
- return 0; /* FIXME : What to do here ? */
+ struct ata_host *host = dev_get_drvdata(&op->dev);
+ struct mpc52xx_ata_priv *priv = host->private_data;
+ int rv;
+
+ rv = mpc52xx_ata_hw_init(priv);
+ if (rv) {
+ printk(KERN_ERR DRV_NAME ": Error during HW init\n");
+ return rv;
+ }
+
+ ata_host_resume(host);
+
+ return 0;
}
#endif
[ 1039.434045] Stopping tasks ... done.
[ 1039.438193] Suspending console(s)
[ 1039.441662] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 1039.441749] ata_scsi_dump_cdb: CDB (1:0,0,0) 35 00 00 00 00 00 00 00 00
[ 1039.441817] ata_exec_command: ata1: cmd 0xE7
[ 1039.442191] ata_hsm_move: ata1: protocol 1 task_state 3 (dev_stat 0x50)
[ 1039.442208] ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
[ 1039.442310] sd 0:0:0:0: [sda] Stopping disk
[ 1039.442378] ata_scsi_dump_cdb: CDB (1:0,0,0) 1b 00 00 00 00 00 00 00 00
[ 1039.442442] ata_exec_command: ata1: cmd 0xE0
[ 1039.442738] ata_hsm_move: ata1: protocol 1 task_state 3 (dev_stat 0x50)
[ 1039.442754] ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
[ 1039.442881] usb_endpoint usbdev1.1_ep81: PM: suspend 0->2, parent 1-0:1.0 already 2
[ 1039.442903] hub 1-0:1.0: PM: suspend 2->2, parent usb1 already 2
[ 1039.442919] usb_endpoint usbdev1.1_ep00: PM: suspend 0->2, parent usb1 already 2
[ 1039.444022] ata_port_schedule_eh: port EH scheduled
[ 1039.444056] ata_scsi_error: ENTER
[ 1039.444065] ata_port_flush_task: ENTER
[ 1039.444074] ata_port_flush_task: flush #1
[ 1039.444087] ata1: ata_port_flush_task: flush #2
[ 1039.444097] ata1: ata_port_flush_task: EXIT
[ 1039.444116] ata_eh_autopsy: ENTER
[ 1039.444133] ata_eh_autopsy: EXIT
[ 1039.444141] ata_eh_recover: ENTER
[ 1039.444151] ata_eh_revalidate_and_attach: ENTER
[ 1039.444162] ata_eh_recover: EXIT, rc=0
[ 1039.444179] __ata_port_freeze: ata1 port frozen
[ 1039.444198] ata_scsi_error: EXIT
[ 1039.447207] ata_port_schedule_eh: port EH scheduled
[ 1039.447270] eth0: Phy @ 0x0, type LXT971 (0x001378e2)
[ 1039.448257] usb_endpoint usbdev1.1_ep00: PM: resume from 0, parent usb1 still 2
[ 1039.448276] usb_endpoint usbdev1.1_ep81: PM: resume from 0, parent 1-0:1.0 still 2
[ 1039.448306] sd 0:0:0:0: [sda] Starting disk
[ 1039.448384] ata_scsi_error: ENTER
[ 1039.448398] ata_port_flush_task: ENTER
[ 1039.448407] ata_port_flush_task: flush #1
[ 1039.448420] ata1: ata_port_flush_task: flush #2
[ 1039.448430] ata1: ata_port_flush_task: EXIT
[ 1039.448451] ata_eh_autopsy: ENTER
[ 1039.448467] ata_eh_recover: ENTER
[ 1039.448481] __ata_port_freeze: ata1 port frozen
[ 1039.956600] ata_std_softreset: ENTER
[ 1039.956648] ata_std_softreset: about to softreset, devmask=3
[ 1039.956661] ata_bus_softreset: ata1: bus reset via SRST
[ 1040.107612] ata_dev_classify: found ATA device by sig
[ 1040.107643] ata_dev_classify: found ATA device by sig
[ 1040.107656] ata_std_softreset: EXIT, classes[0]=1 [1]=5
[ 1040.107667] ata_std_postreset: ENTER
[ 1040.107680] ata_std_postreset: EXIT
[ 1040.107708] ata_eh_thaw_port: ata1 port thawed
[ 1040.107717] ata_eh_revalidate_and_attach: ENTER
[ 1040.107732] ata1.00: ata_dev_read_id: ENTER
[ 1040.107833] ata_exec_command: ata1: cmd 0xEC
[ 1040.110597] ata_hsm_move: ata1: protocol 2 task_state 2 (dev_stat 0x58)
[ 1040.110616] ata_pio_sector: data read
[ 1040.110852] ata_hsm_move: ata1: protocol 2 task_state 3 (dev_stat 0x50)
[ 1040.110867] ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
[ 1040.110920] ata_port_flush_task: ENTER
[ 1040.110929] ata_port_flush_task: flush #1
[ 1040.110941] ata1: ata_port_flush_task: flush #2
[ 1040.110952] ata1: ata_port_flush_task: EXIT
[ 1040.111032] ata_dev_set_xfermode: set features - xfer mode
[ 1040.111102] ata_exec_command: ata1: cmd 0xEF
[ 1040.111263] ata_hsm_move: ata1: protocol 1 task_state 3 (dev_stat 0x50)
[ 1040.111281] ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
[ 1040.111329] ata_port_flush_task: ENTER
[ 1040.111339] ata_port_flush_task: flush #1
[ 1040.111351] ata1: ata_port_flush_task: flush #2
[ 1040.111361] ata1: ata_port_flush_task: EXIT
[ 1040.111373] ata_dev_set_xfermode: EXIT, err_mask=0
[ 1040.111385] ata1.00: ata_dev_read_id: ENTER
[ 1040.111474] ata_exec_command: ata1: cmd 0xEC
[ 1040.114596] ata_hsm_move: ata1: protocol 2 task_state 2 (dev_stat 0x58)
[ 1040.114615] ata_pio_sector: data read
[ 1040.114713] ata_hsm_move: ata1: protocol 2 task_state 3 (dev_stat 0x50)
[ 1040.114727] ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
[ 1040.114775] ata_port_flush_task: ENTER
[ 1040.114784] ata_port_flush_task: flush #1
[ 1040.114796] ata1: ata_port_flush_task: flush #2
[ 1040.114806] ata1: ata_port_flush_task: EXIT
[ 1040.114861] ata_dev_set_mode: xfer_shift=0, xfer_mode=0xc
[ 1040.114873] ata1.00: configured for PIO4
[ 1040.114883] ata_eh_recover: EXIT, rc=0
[ 1040.114907] ata_scsi_error: EXIT
[ 1040.114957] ata_scsi_dump_cdb: CDB (1:0,0,0) 00 00 00 00 00 00 00 00 00
[ 1040.115051] ata_scsi_dump_cdb: CDB (1:0,0,0) 1b 00 00 00 01 00 00 00 00
[ 1040.115118] ata_exec_command: ata1: cmd 0x40
[ 1043.605018] ata_hsm_move: ata1: protocol 1 task_state 3 (dev_stat 0x50)
[ 1043.605039] ata_hsm_move: ata1: dev 0 command complete, drv_stat 0x50
[ 1043.605128] ata_scsi_dump_cdb: CDB (1:0,0,0) 25 00 00 00 00 00 00 00 00
[ 1043.990208] Restarting tasks ... done.
[ 1043.995913] sd 0:0:0:0: [sda] 8404830 512-byte hardware sectors (4303 MB)
[ 1044.004169] ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 3f 00 00 00 00 00 08
[ 1044.011083] sd 0:0:0:0: [sda] Write Protect is off
[ 1044.016047] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 1044.016134] ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 08
[ 1044.023085] ata_scsi_dump_cdb: CDB (1:0,0,0) 5a 00 08 00 00 00 00 00 24
[ 1044.029978] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
^ permalink raw reply
* Re: Patches added to 2.6.23 branch
From: Zang Roy-r61911 @ 2007-07-03 8:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
In-Reply-To: <18057.57417.999506.887803@cargo.ozlabs.ibm.com>
Paul
Could you help to add these patches:
1 add cuboot for 7448hpc2 board
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036834.html
2. Remove redundant pci_read_irq_line() function for 85xx platform
Acked by Ben
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037117.html
3. Fix e500 v2 core reboot bug
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037799.html
4. Document the global utilities node define and example
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/038136.html
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/038137.html
Roy
On Tue, 2007-07-03 at 13:36, Paul Mackerras wrote:
> The following patches have been added to the for-2.6.23 branch on
> powerpc.git. In addition, the master branch has the merge of the
> for-2.6.23 and merge branches, which means that it is up-to-date with
> Linus' 2.6.22-rc7 plus the patches I recently asked Linus to pull for
> inclusion in 2.6.22.
>
> Paul.
^ permalink raw reply
* RE: [PATCH] ucc_geth.c, make PHY device optional.
From: Li Yang-r58472 @ 2007-07-03 8:22 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: linuxppc-dev Development, Netdev
In-Reply-To: <1183447246.20673.155.camel@gentoo-jocke.transmode.se>
> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> Sent: Tuesday, July 03, 2007 3:21 PM
> To: Li Yang-r58472
> Cc: linuxppc-dev Development; Netdev; Fleming Andy-afleming
> Subject: RE: [PATCH] ucc_geth.c, make PHY device optional.
>=20
> On Tue, 2007-07-03 at 11:42 +0800, Li Yang-r58472 wrote:
> > > -----Original Message-----
> > > From: netdev-owner@vger.kernel.org
> > [mailto:netdev-owner@vger.kernel.org] On
> > > Behalf Of Joakim Tjernlund
> > > Sent: Tuesday, July 03, 2007 8:52 AM
> > > To: 'linuxppc-dev Development'; 'Netdev'; Li Yang-r58472
> > > Subject: [PATCH] ucc_geth.c, make PHY device optional.
> > >
> > > > This patch makes the PHY optional for ucc_geth.c ethernet
driver.
> > > > This is useful to support a direct mii to mii connection to, for
> > example,
> > > > a onboard swicth.
> > > >
> > > > Signed-off-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> > > ----
> > Hi Joakim,
> >
> > I'm wondering if we really need to have the option to disable
phylib.
>=20
> maybe, but it has to be dynamic too. I need to use PHY on UCC2 and mii
> on UCC3 and UCC4.
>=20
> > Actually we have made phylib selected by default for ucc_geth. Many
L2
> > switch chips have the capacity to be controlled. Therefore they can
be
> > managed as a phy device.
>=20
> Yes, they can be but why force a PHY impl. when its is of no use? The
> only thing the eth driver needs from the it is speed and duplex. If
> these are fixed, you don't need to talk with a PHY.
The driver needs to get and set the link speed/status on runtime (such
as for ethtool interface). Currently this is implementation through
phydev interface. IMHO, it will be easier to maintain if we only use
this standard interface, rather than use different interfaces for
different cases.
>=20
> > For the MII interface which is not
> > configurable, shouldn't we use the fixed phy support from Vitaly?
>=20
> Well, I think the the fixed phy is great when your eth driver requires
a
> PHY, but it is a workaround with extra processing overhead. IMHO the
> best impl. is to make the PHY optional in the eth driver and as you
can
> see from the patch, that was really simple.
I agree there is overhead. However, it will have the advantage of
abstracting all the PHY related stuff out of controller driver.
>=20
> An useful extension would be to add a new propety in the DTS to hold
> initial speed and duplex(perhaps extend phy-connection-type). This
> would be useful for the fixed driver too as one could derive speed and
> duplex for the fixed phy from that property instead of creating a
fixed
> phy for each speed and duplex one want to support.
I agree that there should be a device node to configure it. The current
fixed phy driver is a little bit too complex to emulate the register
access. Maybe it's better to have a null phy driver which just reads
PHY capacity and status from device node.
- Leo
^ permalink raw reply
* RE: [PATCH] ucc_geth.c, make PHY device optional.
From: Joakim Tjernlund @ 2007-07-03 7:20 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev Development, Netdev
In-Reply-To: <989B956029373F45A0B8AF0297081890D837CB@zch01exm26.fsl.freescale.net>
On Tue, 2007-07-03 at 11:42 +0800, Li Yang-r58472 wrote:
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org
> [mailto:netdev-owner@vger.kernel.org] On
> > Behalf Of Joakim Tjernlund
> > Sent: Tuesday, July 03, 2007 8:52 AM
> > To: 'linuxppc-dev Development'; 'Netdev'; Li Yang-r58472
> > Subject: [PATCH] ucc_geth.c, make PHY device optional.
> >
> > > This patch makes the PHY optional for ucc_geth.c ethernet driver.
> > > This is useful to support a direct mii to mii connection to, for
> example,
> > > a onboard swicth.
> > >
> > > Signed-off-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> > ----
> Hi Joakim,
>
> I'm wondering if we really need to have the option to disable phylib.
maybe, but it has to be dynamic too. I need to use PHY on UCC2 and mii
on UCC3 and UCC4.
> Actually we have made phylib selected by default for ucc_geth. Many L2
> switch chips have the capacity to be controlled. Therefore they can be
> managed as a phy device.
Yes, they can be but why force a PHY impl. when its is of no use? The
only thing the eth driver needs from the it is speed and duplex. If
these are fixed, you don't need to talk with a PHY.
> For the MII interface which is not
> configurable, shouldn't we use the fixed phy support from Vitaly?
Well, I think the the fixed phy is great when your eth driver requires a
PHY, but it is a workaround with extra processing overhead. IMHO the
best impl. is to make the PHY optional in the eth driver and as you can
see from the patch, that was really simple.
An useful extension would be to add a new propety in the DTS to hold
initial speed and duplex(perhaps extend phy-connection-type). This
would be useful for the fixed driver too as one could derive speed and
duplex for the fixed phy from that property instead of creating a fixed
phy for each speed and duplex one want to support.
Jocke
^ permalink raw reply
* Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: Ulrich Teichert @ 2007-07-03 6:50 UTC (permalink / raw)
To: tgall; +Cc: linuxppc-dev
In-Reply-To: <26d387970707021926p43dc5e4o51d29f17a10813ca@mail.gmail.com>
Hi,
>> On Thu, Jun 28, 2007 at 10:59:35AM +0200, Segher Boessenkool wrote:
>> <snip>
>> > Do all (supported) PReP boards have one CPU only?
>>
>> Not sure, but I don't have any. I believe that there were
>> dual processors MTX boards, and dual 604 MVME boards were
>> offered (but probably not very popular).
>
>
>There were several IBM RS/6000 models that were PReP and were at least dual
>systems. The 240 I recall was a dual 604. There were some Fxx and Exx models
>I think might have gone all the way up to 4 ways but my memory is getting
>fuzzy.
I have a 240 at home and it's definitely a dual PReP box. I think that the H70
is PReP, too - that would be a 4 CPU box.
>One thing for sure ... not alot of this hardware exists anymore.
[del]
Oh, the 43p 140 shows up ebay quite often - for reasonable prices in Germany.
Even the multi CPU boxes are available from time to time.
HTH,
Uli
--
Dipl. Inf. Ulrich Teichert|e-mail: Ulrich.Teichert@gmx.de
Stormweg 24 |listening to: Channel 13 Is Haunted (Hex Dispensers)
24539 Neumuenster, Germany|Adrenalin (Supabond), Ne Me Touch Pas (Opération S)
^ permalink raw reply
* Re: Can anyone help me about ac97 driver
From: Joachim Förster @ 2007-07-03 6:21 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1329478984.2865871183429363889.JavaMail.coremail@bj163app129.163.com>
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]
Hi silicom,
On Tue, 2007-07-03 at 10:22 +0800, silicom wrote:
> I'm writing an ac97 driver with interrupt mode on xilinx ml403 and
> linux 2.6.17.1 platform but encounter a incredible problem,can anyone
> send me a copy of the driver code.
I read your previous mails (about a problem with the interrupt handler).
Mainly in the last few days/week I wrote an (ALSA) driver for the
"Xilinx ML403 AC97 Controller Ref", too (ATM playback part only, no
record).
And I didn't encounter problems such as your problem. The only
difference I see, is, that I don't have an explicit "write process": INT
is thrown => INT handler: loop, copy data to the FIFO until full =>
return from INT handler.
I had serious problems with the "Register Access Finished" bit, which
stops working after (average) ~80 codec register accesses (bit remains
0).
My driver is "working" since yesterday evening ;-) ... so I feel a bit
uncertain about "releasing" it to the public right now. I'm willing to
post/contribute my driver, but that will have to wait some more days/a
week ;-) ...
BTW: Is your driver an ALSA driver, too? Or is it an OSS driver?
Joachim
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Patches added to 2.6.23 branch
From: Paul Mackerras @ 2007-07-03 5:36 UTC (permalink / raw)
To: linuxppc-dev
The following patches have been added to the for-2.6.23 branch on
powerpc.git. In addition, the master branch has the merge of the
for-2.6.23 and merge branches, which means that it is up-to-date with
Linus' 2.6.22-rc7 plus the patches I recently asked Linus to pull for
inclusion in 2.6.22.
Paul.
Arnd Bergmann (6):
[POWERPC] move 82xx/83xx/86xx Kconfig options to platform selection
[POWERPC] rename add_bridge to avoid namespace clashes
[POWERPC] mpc82xx_ads build fix
[POWERPC] kill isa_{io,mem}_base definitions for !PCI
[POWERPC] fix building without PCI
[POWERPC] disallow building powermac and tsi108 without PCI
Christoph Hellwig (12):
[POWERPC] spusched: Switch from workqueues to kthread + timer tick
[POWERPC] spusched: Dynamic timeslicing for SCHED_OTHER
[POWERPC] spusched: Update scheduling paramters on every spu_run
[POWERPC] spusched: fix cpu/node binding
[POWERPC] spusched: Catch nosched contexts in spu_deactivate
[POWERPC] spusched: No preemption for nosched contexts
[POWERPC] spufs: Add tid file
[POWERPC] spufs: Implement /proc/spu_loadavg
[POWERPC] spufs: Add stat file to spufs
[POWERPC] spusched: Disable tick when not needed
[POWERPC] spusched: Fix runqueue corruption
[POWERPC] spufs: Add spu stats in sysfs
Jeremy Kerr (5):
[POWERPC] spusched: Fix timeslice calculations
[POWERPC] spusched: Print out scheduling tunables with DEBUG
[POWERPC] spufs: Remove spufs_dir_inode_operations
[POWERPC] spufs: Trivial whitespace fixes
[POWERPC] spufs: Fix libassist accounting
Kazunori Asayama (2):
[POWERPC] spufs: Fix lost events in poll/epoll on mfc
[POWERPC] spufs: Save dma_tagstatus_R in CSA
Kumar Gala (18):
[POWERPC] Remove set_cfg_type for PCI indirect users that don't need it
[POWERPC] 52xx: Remove support for PCI bus_offset
[POWERPC] Pass the pci_controller into pci_exclude_device
[POWERPC] Remove hack to determine the 2nd PHBs bus number
[POWERPC] Remove bus_offset in places its not really used
[POWERPC] Added self_busno to indicate which bus number the PHB is
[POWERPC] Removed remnants of bus_offset
[POWERPC] Added indirect_type to handle variants of PCI ops
[POWERPC] 86xx: Workaround PCI_PRIMARY_BUS usage
[POWERPC] Merge asm-ppc/pci-bridge.h into asm-power/pci-bridge.h
[POWERPC] Remove local_number from pci_controller
[POWERPC] Removed dead code related to PCI on ppc32
[POWERPC] Use global_number in ppc32 pci_controller
[POWERPC] Merge ppc32 and ppc64 pcibios_alloc_controller() prototypes
[POWERPC] Move pci_bus_to_hose users to pci_bus_to_host
[POWERPC] Move common PCI code out of pci_32/pci_64
[POWERPC] Use ppc64 style list management for pci_controller on ppc32
[POWERPC] Add copyright header to pci-common.c based on pci_{32,64}.c
Sebastian Siewior (2):
[POWERPC] spufs: fix building spufs/spu_save_dump.h
[POWERPC] spufs: Add bit definition
Wade Farnsworth (1):
[POWERPC] 86xx: Add uli1575 pci-bridge sector to MPC8641HPCN dts file.
York Sun (1):
[POWERPC] Let subordinate transparent bridges be transparent.
Zhang Wei (4):
[POWERPC] Remove PCI-e errata for MPC8641 silicon ver 1.0
[POWERPC] 86xx: Avoid system halt if link training isn't at least L0.
[POWERPC] MPC8641HPCN: Set IDE in ULI1575 to not native mode.
[POWERPC] 86xx: Created quirk_fsl_pcie_transparent() to initialize bridge resources.
arch/powerpc/Kconfig | 6
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 99 ++++
arch/powerpc/kernel/Makefile | 2
arch/powerpc/kernel/pci-common.c | 454 ++++++++++++++++++++
arch/powerpc/kernel/pci_32.c | 476 +--------------------
arch/powerpc/kernel/pci_64.c | 391 -----------------
arch/powerpc/kernel/ppc_ksyms.c | 4
arch/powerpc/platforms/52xx/efika.c | 9
arch/powerpc/platforms/52xx/mpc52xx_pci.c | 18 -
arch/powerpc/platforms/82xx/Kconfig | 2
arch/powerpc/platforms/82xx/mpc82xx_ads.c | 17 -
arch/powerpc/platforms/83xx/Kconfig | 2
arch/powerpc/platforms/83xx/mpc8313_rdb.c | 7
arch/powerpc/platforms/83xx/mpc832x_mds.c | 7
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 7
arch/powerpc/platforms/83xx/mpc834x_itx.c | 7
arch/powerpc/platforms/83xx/mpc834x_mds.c | 7
arch/powerpc/platforms/83xx/mpc836x_mds.c | 7
arch/powerpc/platforms/83xx/mpc83xx.h | 6
arch/powerpc/platforms/83xx/pci.c | 18 -
arch/powerpc/platforms/85xx/mpc85xx.h | 2
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 10
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 17 -
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 7
arch/powerpc/platforms/85xx/pci.c | 11
arch/powerpc/platforms/86xx/Kconfig | 2
arch/powerpc/platforms/86xx/mpc86xx.h | 11
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 12 -
arch/powerpc/platforms/86xx/pci.c | 67 ++-
arch/powerpc/platforms/Kconfig | 24 +
arch/powerpc/platforms/Kconfig.cputype | 51 --
arch/powerpc/platforms/cell/spu_base.c | 47 ++
arch/powerpc/platforms/cell/spufs/backing_ops.c | 6
arch/powerpc/platforms/cell/spufs/context.c | 15 -
arch/powerpc/platforms/cell/spufs/fault.c | 29 +
arch/powerpc/platforms/cell/spufs/file.c | 122 +++++
arch/powerpc/platforms/cell/spufs/inode.c | 10
arch/powerpc/platforms/cell/spufs/run.c | 33 +
arch/powerpc/platforms/cell/spufs/sched.c | 476 +++++++++++++++++----
arch/powerpc/platforms/cell/spufs/spu_restore.c | 2
arch/powerpc/platforms/cell/spufs/spu_save.c | 2
arch/powerpc/platforms/cell/spufs/spufs.h | 84 +++-
arch/powerpc/platforms/cell/spufs/switch.c | 18 +
arch/powerpc/platforms/chrp/Kconfig | 1
arch/powerpc/platforms/chrp/Makefile | 3
arch/powerpc/platforms/chrp/pci.c | 7
arch/powerpc/platforms/embedded6xx/Kconfig | 1
arch/powerpc/platforms/embedded6xx/holly.c | 2
arch/powerpc/platforms/embedded6xx/linkstation.c | 10
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c | 9
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.h | 5
arch/powerpc/platforms/iseries/pci.c | 2
arch/powerpc/platforms/maple/pci.c | 6
arch/powerpc/platforms/pasemi/pci.c | 4
arch/powerpc/platforms/powermac/Kconfig | 1
arch/powerpc/platforms/powermac/pci.c | 14 -
arch/powerpc/sysdev/Makefile | 3
arch/powerpc/sysdev/fsl_pcie.c | 171 --------
arch/powerpc/sysdev/indirect_pci.c | 44 ++
arch/powerpc/sysdev/mv64x60_pci.c | 7
arch/powerpc/sysdev/tsi108_pci.c | 10
arch/ppc/syslib/Makefile | 1
arch/ppc/syslib/indirect_pci.c | 134 ++++++
include/asm-powerpc/machdep.h | 2
include/asm-powerpc/mpc86xx.h | 6
include/asm-powerpc/pci-bridge.h | 129 +++++-
include/asm-powerpc/pci.h | 7
include/asm-powerpc/spu.h | 24 +
68 files changed, 1731 insertions(+), 1476 deletions(-)
create mode 100644 arch/powerpc/kernel/pci-common.c
delete mode 100644 arch/powerpc/sysdev/fsl_pcie.c
create mode 100644 arch/ppc/syslib/indirect_pci.c
^ permalink raw reply
* RE: [PATCH] ucc_geth.c, make PHY device optional.
From: Li Yang-r58472 @ 2007-07-03 3:42 UTC (permalink / raw)
To: Joakim Tjernlund, linuxppc-dev Development, Netdev,
Fleming Andy-afleming
In-Reply-To: <012701c7bd0c$64fe67c0$0e67a8c0@Jocke>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org
[mailto:netdev-owner@vger.kernel.org] On
> Behalf Of Joakim Tjernlund
> Sent: Tuesday, July 03, 2007 8:52 AM
> To: 'linuxppc-dev Development'; 'Netdev'; Li Yang-r58472
> Subject: [PATCH] ucc_geth.c, make PHY device optional.
>=20
> > This patch makes the PHY optional for ucc_geth.c ethernet driver.
> > This is useful to support a direct mii to mii connection to, for
example,
> > a onboard swicth.
> >
> > Signed-off-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> ----
Hi Joakim,
I'm wondering if we really need to have the option to disable phylib.
Actually we have made phylib selected by default for ucc_geth. Many L2
switch chips have the capacity to be controlled. Therefore they can be
managed as a phy device. For the MII interface which is not
configurable, shouldn't we use the fixed phy support from Vitaly?
- Leo
^ permalink raw reply
* Re: Can anyone help me about ac97 driver
From: Grant Likely @ 2007-07-03 3:36 UTC (permalink / raw)
To: silicom; +Cc: linuxppc-embedded
In-Reply-To: <1329478984.2865871183429363889.JavaMail.coremail@bj163app129.163.com>
On 7/2/07, silicom <silicom@163.com> wrote:
>
> Hi
> I'm writing an ac97 driver with interrupt mode on xilinx ml403 and linux
> 2.6.17.1 platform but encounter a incredible problem,can anyone send me a
> copy of the driver code.
I think there is a driver in MontaVista's 2.4 tree, but I haven't used
it and don't know how well it works.
http://penguinppc.org/kernel/#historical
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: help on dts compiler please.
From: Josh Boyer @ 2007-07-03 2:32 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641502D1A45A@xmb-sjc-212.amer.cisco.com>
On Mon, 2007-07-02 at 18:49 -0700, Bizhan Gholikhamseh (bgholikh) wrote:
> > > $ dtc -f -I dts -O dtb mpc8541cds.dts
> > > DTC: dts->dtb on file "mpc8541cds.dts"
> > > syntax error at line 15
> > > FATAL ERROR: Couldn't read input tree
> >
> > Where did you get your dtc version from?
> >
> Sorry I answered the question wrong. I downloaded the gzip tar file from
> David Gibson web page.
That is a very out of date dtc. Try using the one found here:
git://www.jdl.com/software/dtc.git
josh
^ permalink raw reply
* Re: help on dts compiler please.
From: Dale Farnsworth @ 2007-07-03 2:31 UTC (permalink / raw)
To: bgholikh, Linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641502D1A45A@xmb-sjc-212.amer.cisco.com>
> > > $ dtc -f -I dts -O dtb mpc8541cds.dts
> > > DTC: dts->dtb on file "mpc8541cds.dts"
> > > syntax error at line 15
> > > FATAL ERROR: Couldn't read input tree
> >
> > Where did you get your dtc version from?
> >
> Sorry I answered the question wrong. I downloaded the gzip tar file from
> David Gibson web page.
That same web page says that the latest version of the web page is
at git://www.jdl.com/software/dtc.git
Try the current version available there.
-Dale Farnsworth
^ permalink raw reply
* Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: Tom Gall @ 2007-07-03 2:26 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev
In-Reply-To: <20070628100020.GA24215@iram.es>
[-- Attachment #1: Type: text/plain, Size: 671 bytes --]
On 6/28/07, Gabriel Paubert <paubert@iram.es> wrote:
>
> On Thu, Jun 28, 2007 at 10:59:35AM +0200, Segher Boessenkool wrote:
> <snip>
> > Do all (supported) PReP boards have one CPU only?
>
> Not sure, but I don't have any. I believe that there were
> dual processors MTX boards, and dual 604 MVME boards were
> offered (but probably not very popular).
There were several IBM RS/6000 models that were PReP and were at least dual
systems. The 240 I recall was a dual 604. There were some Fxx and Exx models
I think might have gone all the way up to 4 ways but my memory is getting
fuzzy.
One thing for sure ... not alot of this hardware exists anymore.
Regards,
Tom
[-- Attachment #2: Type: text/html, Size: 1004 bytes --]
^ permalink raw reply
* Can anyone help me about ac97 driver
From: silicom @ 2007-07-03 2:22 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 199 bytes --]
Hi I'm writing an ac97 driver with interrupt mode on xilinx ml403 and linux 2.6.17.1 platform but encounter a incredible problem,can anyone send me a copy of the driver code. thanks sincerely.
[-- Attachment #2: Type: text/html, Size: 638 bytes --]
^ permalink raw reply
* RE: help on dts compiler please.
From: Bizhan Gholikhamseh (bgholikh) @ 2007-07-03 1:49 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <1183426404.5643.0.camel@vader.jdub.homelinux.org>
=20
> > $ dtc -f -I dts -O dtb mpc8541cds.dts
> > DTC: dts->dtb on file "mpc8541cds.dts"
> > syntax error at line 15
> > FATAL ERROR: Couldn't read input tree
>=20
> Where did you get your dtc version from?
>=20
Sorry I answered the question wrong. I downloaded the gzip tar file from
David Gibson web page.
> josh
>=20
^ permalink raw reply
* RE: help on dts compiler please.
From: Bizhan Gholikhamseh (bgholikh) @ 2007-07-03 1:41 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <1183426404.5643.0.camel@vader.jdub.homelinux.org>
[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]
> -----Original Message-----
> From: Josh Boyer [mailto:jwboyer@jdub.homelinux.org]
> Sent: Monday, July 02, 2007 6:33 PM
> To: Bizhan Gholikhamseh (bgholikh)
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: help on dts compiler please.
>
> On Mon, 2007-07-02 at 17:04 -0700, Bizhan Gholikhamseh
> (bgholikh) wrote:
> > Hi
> > I have downloaded the latest Linux code from the following git tree:
> > git:// git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
> >
> > I have also installed dtc compiler version.
> > I am trying to create dtb file from mpc8541cds.dts.
> > I ran the following command and get error:
> >
> > $ dtc -f -I dts -O dtb mpc8541cds.dts
> > DTC: dts->dtb on file "mpc8541cds.dts"
> > syntax error at line 15
> > FATAL ERROR: Couldn't read input tree
>
> Where did you get your dtc version from?
I got it from the git tree two days ago:git://
git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
I have attached the file.
It appears it complains about "compatibility" property on all the dts
file.
Thanks,
Bizhan
>
> josh
>
[-- Attachment #2: mpc8541cds.dts --]
[-- Type: application/octet-stream, Size: 5798 bytes --]
/*
* MPC8541 CDS Device Tree Source
*
* Copyright 2006 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
/ {
model = "MPC8541CDS";
compatible = "MPC8541CDS", "MPC85xxCDS";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8541@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>; // 32 bytes
i-cache-line-size = <20>; // 32 bytes
d-cache-size = <8000>; // L1, 32K
i-cache-size = <8000>; // L1, 32K
timebase-frequency = <0>; // 33 MHz, from uboot
bus-frequency = <0>; // 166 MHz
clock-frequency = <0>; // 825 MHz, from uboot
32-bit;
};
};
memory {
device_type = "memory";
reg = <00000000 08000000>; // 128M at 0x0
};
soc8541@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "soc";
ranges = <0 e0000000 00100000>;
reg = <e0000000 00100000>; // CCSRBAR 1M
bus-frequency = <0>;
memory-controller@2000 {
compatible = "fsl,8541-memory-controller";
reg = <2000 1000>;
interrupt-parent = <&mpic>;
interrupts = <2 2>;
};
l2-cache-controller@20000 {
compatible = "fsl,8541-l2-cache-controller";
reg = <20000 1000>;
cache-line-size = <20>; // 32 bytes
cache-size = <40000>; // L2, 256K
interrupt-parent = <&mpic>;
interrupts = <0 2>;
};
i2c@3000 {
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3000 100>;
interrupts = <1b 2>;
interrupt-parent = <&mpic>;
dfsrr;
};
mdio@24520 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "mdio";
compatible = "gianfar";
reg = <24520 20>;
phy0: ethernet-phy@0 {
interrupt-parent = <&mpic>;
interrupts = <35 0>;
reg = <0>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
interrupt-parent = <&mpic>;
interrupts = <35 0>;
reg = <1>;
device_type = "ethernet-phy";
};
};
ethernet@24000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <24000 1000>;
local-mac-address = [ 00 E0 0C 00 73 00 ];
interrupts = <d 2 e 2 12 2>;
interrupt-parent = <&mpic>;
phy-handle = <&phy0>;
};
ethernet@25000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <25000 1000>;
local-mac-address = [ 00 E0 0C 00 73 01 ];
interrupts = <13 2 14 2 18 2>;
interrupt-parent = <&mpic>;
phy-handle = <&phy1>;
};
serial@4500 {
device_type = "serial";
compatible = "ns16550";
reg = <4500 100>; // reg base, size
clock-frequency = <0>; // should we fill in in uboot?
interrupts = <1a 2>;
interrupt-parent = <&mpic>;
};
serial@4600 {
device_type = "serial";
compatible = "ns16550";
reg = <4600 100>; // reg base, size
clock-frequency = <0>; // should we fill in in uboot?
interrupts = <1a 2>;
interrupt-parent = <&mpic>;
};
pci1: pci@8000 {
interrupt-map-mask = <1f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x10 */
08000 0 0 1 &mpic 30 1
08000 0 0 2 &mpic 31 1
08000 0 0 3 &mpic 32 1
08000 0 0 4 &mpic 33 1
/* IDSEL 0x11 */
08800 0 0 1 &mpic 30 1
08800 0 0 2 &mpic 31 1
08800 0 0 3 &mpic 32 1
08800 0 0 4 &mpic 33 1
/* IDSEL 0x12 (Slot 1) */
09000 0 0 1 &mpic 30 1
09000 0 0 2 &mpic 31 1
09000 0 0 3 &mpic 32 1
09000 0 0 4 &mpic 33 1
/* IDSEL 0x13 (Slot 2) */
09800 0 0 1 &mpic 31 1
09800 0 0 2 &mpic 32 1
09800 0 0 3 &mpic 33 1
09800 0 0 4 &mpic 30 1
/* IDSEL 0x14 (Slot 3) */
0a000 0 0 1 &mpic 32 1
0a000 0 0 2 &mpic 33 1
0a000 0 0 3 &mpic 30 1
0a000 0 0 4 &mpic 31 1
/* IDSEL 0x15 (Slot 4) */
0a800 0 0 1 &mpic 33 1
0a800 0 0 2 &mpic 30 1
0a800 0 0 3 &mpic 31 1
0a800 0 0 4 &mpic 32 1
/* Bus 1 (Tundra Bridge) */
/* IDSEL 0x12 (ISA bridge) */
19000 0 0 1 &mpic 30 1
19000 0 0 2 &mpic 31 1
19000 0 0 3 &mpic 32 1
19000 0 0 4 &mpic 33 1>;
interrupt-parent = <&mpic>;
interrupts = <08 2>;
bus-range = <0 0>;
ranges = <02000000 0 80000000 80000000 0 20000000
01000000 0 00000000 e2000000 0 00100000>;
clock-frequency = <3f940aa>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <8000 1000>;
compatible = "85xx";
device_type = "pci";
i8259@19000 {
clock-frequency = <0>;
interrupt-controller;
device_type = "interrupt-controller";
reg = <19000 0 0 0 1>;
#address-cells = <0>;
#interrupt-cells = <2>;
built-in;
compatible = "chrp,iic";
big-endian;
interrupts = <1>;
interrupt-parent = <&pci1>;
};
};
pci@9000 {
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x15 */
a800 0 0 1 &mpic 3b 1
a800 0 0 2 &mpic 3b 1
a800 0 0 3 &mpic 3b 1
a800 0 0 4 &mpic 3b 1>;
interrupt-parent = <&mpic>;
interrupts = <09 2>;
bus-range = <0 0>;
ranges = <02000000 0 a0000000 a0000000 0 20000000
01000000 0 00000000 e3000000 0 00100000>;
clock-frequency = <3f940aa>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <9000 1000>;
compatible = "85xx";
device_type = "pci";
};
mpic: pic@40000 {
clock-frequency = <0>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <40000 40000>;
built-in;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
};
};
};
^ permalink raw reply
* Re: help on dts compiler please.
From: Josh Boyer @ 2007-07-03 1:33 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641502D1A454@xmb-sjc-212.amer.cisco.com>
On Mon, 2007-07-02 at 17:04 -0700, Bizhan Gholikhamseh (bgholikh) wrote:
> Hi
> I have downloaded the latest Linux code from the following git tree:
> git:// git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
>
> I have also installed dtc compiler version.
> I am trying to create dtb file from mpc8541cds.dts.
> I ran the following command and get error:
>
> $ dtc -f -I dts -O dtb mpc8541cds.dts
> DTC: dts->dtb on file "mpc8541cds.dts"
> syntax error at line 15
> FATAL ERROR: Couldn't read input tree
Where did you get your dtc version from?
josh
^ permalink raw reply
* [PATCH] ucc_geth.c, make PHY device optional.
From: Joakim Tjernlund @ 2007-07-03 0:52 UTC (permalink / raw)
To: 'linuxppc-dev Development', 'Netdev',
'Li Yang-r58472'
In-Reply-To: <1183142980.20673.89.camel@gentoo-jocke.transmode.se>
> This patch makes the PHY optional for ucc_geth.c ethernet driver.
> This is useful to support a direct mii to mii connection to, for example,
> a onboard swicth.
>
> Signed-off-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
----
[SNIP patch sent last Friday]
Since this is my last week before vacation, I would really like to
get feedback on this patch sooner than later :)
Jocke
^ permalink raw reply
* Re: idr_get_new_above() limitation?
From: Jim Houston @ 2007-07-03 0:31 UTC (permalink / raw)
To: Hoang-Nam Nguyen
Cc: linux-kernel, openib-general, Stefan Roscher, linuxppc-dev,
raisch, Andrew Morton
In-Reply-To: <200707021919.27251.hnguyen@linux.vnet.ibm.com>
On Mon, 2007-07-02 at 19:19 +0200, Hoang-Nam Nguyen wrote:
> i=3fffffff token=3fffffff t=000000003fffffff
> i=40000000 token=40000000 t=0000000000000000
> Invalid object 0000000000000000. Expected 40000000
>
> That means token 0x40000000 seems to be the "upper boundary" of idr_find().
> However the behaviour is not consistent in that it was returned by
> idr_get_new_above().
Hi Nam,
Yes this is a bug. Thanks for the great test module.
The problem is in idr_get_new_above_int() in the loop which
adds new layers to the top of the radix tree. It is failing
the "layers < (MAX_LEVEL - 1)" test. It doesn't allocate the
new layer but still calls sub_alloc() which relies on having
the new layer properly constructed. I believe that it is
allocating the slot which corresponds to id = 0.
I believe this is an off by one error in calculating the
MAX_LEVEL value. I will do a more careful review and post
a fix in the next day or so. I have been in Ottawa for OLS.
I'm flying home tomorrow.
Jim Houston - Concurrent Computer Corp.
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Benjamin Herrenschmidt @ 2007-07-03 0:42 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras, Guennadi Liakhovetski
In-Reply-To: <00a85f152aa3547f0f0b4acd7954468a@kernel.crashing.org>
On Mon, 2007-07-02 at 14:03 +0200, Segher Boessenkool wrote:
> > + while ((node = of_get_next_child(adap_node, node))) {
>
> of_for_each_child_node() or whatever it is called?
>
> > + addr = of_get_property(node, "reg", &len);
> > + if (!addr || len < sizeof(int) || *addr > 0xffff)
> > + continue;
>
> Addresses aren't 16 bit AFAIK?
Some i2c busses support 10 bits addressing...
Ben.
^ permalink raw reply
* insmod - Bad address
From: Siva Prasad @ 2007-07-03 0:13 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded, linux-kernel-digest
Hi,
When I try to do insmod or modprobe, I get "Bad Address". I don't
exactly understand what this is, and how to take care of this.
Any ideas. Appreciate any help.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
modprobe: FATAL: Error inserting binfmt_misc
(/lib/modules/2.6.15-9bvoem50npc3/kernel/fs/binfmt_misc.ko): Bad address
modprobe: FATAL: Error running install command for binfmt_misc
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
Thanks
Siva
^ permalink raw reply
* help on dts compiler please.
From: Bizhan Gholikhamseh (bgholikh) @ 2007-07-03 0:04 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
Hi
I have downloaded the latest Linux code from the following git tree:
git:// git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
I have also installed dtc compiler version.
I am trying to create dtb file from mpc8541cds.dts.
I ran the following command and get error:
$ dtc -f -I dts -O dtb mpc8541cds.dts
DTC: dts->dtb on file "mpc8541cds.dts"
syntax error at line 15
FATAL ERROR: Couldn't read input tree
Many thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 1867 bytes --]
^ 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