* 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
* Re: 2.6.22-rc6-mm1
From: Paul Mackerras @ 2007-07-02 23:21 UTC (permalink / raw)
To: Jason Wessel
Cc: kgdb-bugreport, linux-kernel, linuxppc-dev, Mariusz Kozlowski,
Andrew Morton
In-Reply-To: <46890F8D.3080807@windriver.com>
Jason Wessel writes:
> I suppose the argument could be made to remove the check in the compiled
> file, but it does serve as a way to protect kgdb for now if someone
> tries to hard compile in xmon and kgdb. Completely unpredictable
> results will occur with the debugger unless some pieces are fixed. I
> would rather make sure until that happens there is no way head down the
> rat hole.
It should all work provided kgdb plays nicely. We used to be able to
compile in both xmon and kdb and select at runtime which one gets
used.
> That issue aside would it be useful to have xmon+kgdb? After having
> looked at the hook points for xmon, if a command was added to xmon to
> provide an "detach" it would be easy enough to have kgdb and xmon in the
> same kernel. Obviously only one or the other can be used at any given time.
Well, xmon_init(0) will do a detach. However, I don't see that it is
needed; there is plenty of flexibility to choose to have xmon or not
using the CONFIG_XMON_DEFAULT config option and the xmon= boot command
line option.
Paul.
^ permalink raw reply
* Re: [PATCH v2.1 ] Fix VDSO gettimeofday() when called with NULL struct timeval.
From: Tony Breeds @ 2007-07-02 23:20 UTC (permalink / raw)
To: Will Schmidt; +Cc: LinuxPPC-dev
In-Reply-To: <1183150190.22547.62.camel@farscape.rchland.ibm.com>
On Fri, Jun 29, 2007 at 03:49:50PM -0500, Will Schmidt wrote:
>
> The vdso64 portion of patch 74609f4536f2b8fd6a48381bbbe3cd37da20a527 for
> fixing problems with NULL gettimeofday input mistakenly checks for a
> null tz field twice, when it should be checking for null tz once, and
> null tv once; by way of a r10/r11 typo.
>
> Any application calling gettimeofday(&tv,NULL) will "fail".
>
> This corrects that typo, and makes my G5 happy.
Ooops thanks Will!
The /really/ sad thing is I got it right in the first version of the
patch :(
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Segher Boessenkool @ 2007-07-02 23:10 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras, Guennadi Liakhovetski
In-Reply-To: <20070702224643.GA21539@ld0162-tx32.am.freescale.net>
>> AFAIK, i2c is not specified by OF standard. So, we are free to chose
>> any
>> "compatible" fields for our dts. Which we then would need to match
>> against
>> drivers. So, why not make this a 1-to-1 match? I.e.,
>> [OF] [I2C]
>> compatible <-> driver_name
>> model <-> type
>
> If we do this, then the compatible field should probably be preceded
> with
> "linux,", which would get stripped by of_register_i2c_devices(). This
> would only be an interim measure until we can figure out some sort of
> name registry via power.org. Once that happens, non-"linux,"
> compatible
> fields could be looked up in an OF-to-linux table, or there could be a
> way for i2c devices to specify OF matches in addition to driver name.
Why even think of doing this? Just put the bloody name of
the device in the "compatible" property and match on that.
What is so hard about this?
If the answer is "the Linux I2C stuff is badly structured",
well, you know what to do :-)
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Segher Boessenkool @ 2007-07-02 23:06 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0707022114020.3339@poirot.grange>
>> of_for_each_child_node() or whatever it is called?
>
> Sure, would be nice, only I cannot find anything like that. I seem to
> remember seeing a patch like that, but maybe I'me mistaken... Do you
> remember details / can you find it?
Not right now, sorry. Use grep? :-)
>>> + name = of_get_property(node, "compatible", NULL);
>>> + if (!name)
>>> + name = node->name;
>>> + if (!name)
>>> + continue;
>>
>> Look at "name" first, then look at "compatible", not
>> the other way around.
>
> ok
Which btw is what the "is_compatible()" stuff does
(or, ought to do).
>>> + /* FIXME: the i2c code should allow drivers to specify
>>> + * multiple match names; board code shouldn't need to
>>> + * know what driver will handle a given type.
>>> + */
>>
>> This should be handled by the OF matching stuff, there
>> is no direct connection between device tree naming and
>> Linux driver naming. I don't want to see this patch
>> going in without this problem being fixed first.
>
> Right, this one is interesting. But this time I cannot even vaguely
> remember seeing any "OF matching" code. I can only remember each driver
> (or OF glue to a generic driver) parsing compatible of entries, like
> legacy_serial.c. Or you mean we need to write such a matching layer?
The OF glue parsing stuff and setting up the data structures
the generic drivers want to see. I say make it work for your
board first, then when later more boards need it we have a
better idea about what is needed from a more generic I2C glue
layer.
> AFAIK, i2c is not specified by OF standard.
Yes.
> So, we are free to chose any "compatible" fields for our dts.
Within bounds. What goes into "compatible" properties is
well-defined for _any_ device.
> Which we then would need to match against
> drivers. So, why not make this a 1-to-1 match?
Because the device tree describes the hardware, not what
Linux (or anything else) is going to do with it. Let me
give you an example of why this is a good thing for _you_:
say a future version of Linux drops the I2C driver for a
device you have, since some other driver should be used
preferably instead (maybe it is just a better driver for
the same device, maybe it supports more devices, whatever).
Suddenly boards with your old device tree cannot run that
new Linux version anymore. Ouch.
Just use "compatible" exactly the way it is meant to be
used and your life will be so much simpler. And don't
even think about using a very generic property like "model"
for a purpose totally different from its intended purpose.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Scott Wood @ 2007-07-02 22:46 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0707022114020.3339@poirot.grange>
On Mon, Jul 02, 2007 at 10:11:04PM +0200, Guennadi Liakhovetski wrote:
> AFAIK, i2c is not specified by OF standard. So, we are free to chose any
> "compatible" fields for our dts. Which we then would need to match against
> drivers. So, why not make this a 1-to-1 match? I.e.,
> [OF] [I2C]
> compatible <-> driver_name
> model <-> type
If we do this, then the compatible field should probably be preceded with
"linux,", which would get stripped by of_register_i2c_devices(). This
would only be an interim measure until we can figure out some sort of
name registry via power.org. Once that happens, non-"linux," compatible
fields could be looked up in an OF-to-linux table, or there could be a
way for i2c devices to specify OF matches in addition to driver name.
-Scott
^ 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