* Réf. : Re: [PATCH] fix 2.6.25-rc2 compilation with CONFIG_SPI_MPC52xx_PSC
From: Eric DUJARDIN @ 2008-02-19 15:47 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Rigby John-R61273
[-- Attachment #1: Type: text/plain, Size: 2035 bytes --]
OK great.
Additionnally, the FIFO_52xx macro probably belongs to mpc52xx_psc.h.
Eric Dujardin
-------------------------------
Sagem DS - DP Combat Terrestre
178 rue de Paris - F-91344 Massy Cedex
(33) 1 69196792 (direct)
(33) 1 69196904 (fax)
-------------------------------
"Grant Likely" <grant.likely@secretlab.ca>
Envoyé par : linuxppc-dev-bounces+eric.dujardin=sagem.com@ozlabs.org
19/02/2008 16:09
Remis le : 19/02/2008 16:09
Pour : EricDuj <eric.dujardin@sagem.com>
cc : linuxppc-dev@ozlabs.org, Rigby John-R61273 <jrigby@freescale.com>
Objet : Re: [PATCH] fix 2.6.25-rc2 compilation with CONFIG_SPI_MPC52xx_PSC
On Feb 19, 2008 7:46 AM, EricDuj <eric.dujardin@sagem.com> wrote:
<snip>
Yes, your right. There were changes made to the psc structures to
support the 5121 but as you've discovered they didn't get propagated
to the spi driver. Your patch is close, but I need to look at it a
bit deeper today to decide if it is the correct fix.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
" Ce courriel et les documents qui y sont attaches peuvent contenir des informations confidentielles. Si vous n'etes pas le destinataire escompte, merci d'en informer l'expediteur immediatement et de detruire ce courriel ainsi que tous les documents attaches de votre systeme informatique. Toute divulgation, distribution ou copie du present courriel et des documents attaches sans autorisation prealable de son emetteur est interdite."
" This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, please advise the sender immediately and delete this e-mail and all attached documents from your computer system. Any unauthorised disclosure, distribution or copying hereof is prohibited."
[-- Attachment #2: Type: text/html, Size: 2971 bytes --]
^ permalink raw reply
* Re: [patch 4/4] RFC: PCI: consolidate several pcibios_enable_resources() implementations
From: Bjorn Helgaas @ 2008-02-19 16:11 UTC (permalink / raw)
To: benh
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-pci, linux-arm-kernel, Russell King
In-Reply-To: <1203402667.6740.94.camel@pasglop>
On Monday 18 February 2008 11:31:07 pm Benjamin Herrenschmidt wrote:
>
> On Mon, 2008-02-18 at 21:39 -0700, Bjorn Helgaas wrote:
> > powerpc: has a different collision check at (5)
>
> I've always found the collision check dodgy. I tend to want to keep
> the way powerpc does it here.
>
> pci_enable_device() should only enable resources that have successfully
> been added to the resource tree (that have passed all the collision
> check etc...). There is a simple & clear indication of that: res->parent
> is non-NULL. I think that is a better check than the test x86 does on
> start and end.
>
> That is, whatever the arch code decides to use to decide whether
> resources are assigned by firmware or by the first pass assignment code
> or not and collide or not, once that phase is finished (which is the
> case when calling pcibios_enable_device(), having the resource in the
> resource-tree or not is, I believe, the proper way to test whether it's
> a useable resource.
So should x86 adopt that collision check? I don't hear anything about
actual architecture differences that are behind this implementation
difference.
Bjorn
^ permalink raw reply
* Unaligned LocalPlus Bus access on MPC5200
From: Yuri Tikhonov @ 2008-02-19 16:21 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Detlev Zundel
Hello,
I've encountered with the problem of unaligned word access to external
devices (Flash memory) connected to Local Plus bus of MPC5200 processor. Any
comments on this would be very appreciated.
And the essence of the issue is as follows:
- when I try to read a data word from LPB-connected Flash using some even
address (0xFF000000, 0xFF000002, 0xFF000004, etc), then everything works fine
(it's not a typo, 2bytes-aligned word accesses pass well too);
- when I try to read a data word from LPB-connected Flash using some odd
address (0xFF000001, 0xFF000003, ...) then LP returns only 1 byte of word
correctly (the 3 bytes remained are filled with zeros).
(a) Here is what I have when I read from LPB using word-aligned accesses with
MPC5200 rev.A and LPB configured in Non_Multiplexed mode + 8-bit data bus:
lwz from 0xc3082000: 0xba476bc7
lwz from 0xc3082004: 0xb95d77de
...
Now I try the unaligned reads:
lwz from 0xc3082000: 0xba476bc7
lwz from 0xc3082001: 0x000000b9
lwz from 0xc3082002: 0x6bc7b95d
lwz from 0xc3082003: 0xc7000000
(b) With MPC5200 rev.B situation is similar, and different only in fact that
unaligned read results to 2-bytes reading for 0x1 addresses cases (LPB again
configured in Non_Multiplexed mode + 8-bit data bus):
lwz from 0xd1082000: 0x2f459eaf
lwz from 0xd1082004: 0x388ff68d
...
lwz from 0xd1082000: 0x2f459eaf
lwz from 0xd1082001: 0x0000af38
lwz from 0xd1082002: 0x9eaf388f
lwz from 0xd1082003: 0xaf000000
(c) When LPB operates in the Multiplexed mode with 32-bit data bus, the
erroneous result is observed for 0x3 addresses cases only (MPC5200 has rev.A
in these tests):
lwz from 0xc3082000: 0x7e9043a6
lwz from 0xc3082004: 0x7eb143a6
...
lwz from 0xc3082000: 0x7e9043a6
lwz from 0xc3082001: 0x9043a67e
lwz from 0xc3082002: 0x43a67eb1
lwz from 0xc3082003: 0xa6000000
I used the following platforms for tests:
- TQM5200 board, which is based on MPC5200rev.A CPU, and has AMD Flash
connected to LPB configured in Multiplexed mode with 32-bit data bus;
- some customed board, which is based on MPC5200rev.A CPU, and has Intel Flash
connected to LPB configured in Non-Multiplexed mode with 8-bit data bus;
- Lite5200B board, which is based on MPC5200rev.B CPU, and has AMD Flash
connected to LPB configured in Non-Multiplexed mode with 8-bit data bus.
The Linux source tree I used is linux-2.6.23.16 (DENX linux-2.6.23-stable
branch). The toolchain is ELDK-4.2.
As an example, these LPB-related issue leads to the incorrect operation of
JFFS2 file-system created on the top of MTD device built on a Flash chip from
Intel/Sharp (drivers/mtd/chips/cfi_cmdset_0001.c).
With these Flash chips implementation of point/unpoint API is possible, so
the cfi_cmdset_0001.c driver exports the corresponding point/unpoint methods
for the MTD device, and JFFS2 then uses these methods to operate with data
directly from Flash (without copying them to RAM memory).
One of these operations is memcpy() in the jffs2_scan_dirent_node() function,
which copies the file name from some address at Flash (aligned) to,
unfortunately, unaligned destination in RAM ("name" field of the
jffs2_full_dirent structure).
The implementation of memcpy() in lib_powerpc first does byte-to-byte
transfers to achieve the aligned destination, and then does word-to-word
transfers, but by this moment the source is unaligned, so memcpy() does lwz-s
from unaligned addresses on LPB.
Just FYI, a simple work-around for the issue with the Intel/Sharp Flash chips
connected to LPB of MPC5200 is to mark your struct map_info as .phys =
NO_XIP, and implement read/write/copy_from/copy_to byte-to-byte functions (in
your drivers/mtd/maps/ board file).
Regards, Yuri
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
^ permalink raw reply
* Re: [PATCH] Convert pfc8563 i2c driver from old style to new style
From: Alessandro Zummo @ 2008-02-19 16:24 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, i2c
In-Reply-To: <20080219161020.61f7ec10@hyperion.delvare>
On Tue, 19 Feb 2008 16:10:20 +0100
Jean Delvare <khali@linux-fr.org> wrote:
> Hi Jon,
>
> On Mon, 21 Jan 2008 15:09:01 -0500, Jon Smirl wrote:
> > Convert pfc8563 i2c driver from old style to new style.
> >
> > Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
> > ---
> >
> > drivers/rtc/rtc-pcf8563.c | 107 +++++++++++----------------------------------
> > 1 files changed, 27 insertions(+), 80 deletions(-)
>
> Preliminary note: this driver belongs to the RTC subsystem, so it will
> be up to Alessandro Zummo (Cc'd) to push this patch upstream... when it
> is ready to go there.
A conversion to new style for this driver has already been
pushed upstream. Adapting platforms to instantiate the device
should be fairly easy, especially when you use the dts.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
^ permalink raw reply
* Re: [PATCH] Convert pfc8563 i2c driver from old style to new style
From: Jean Delvare @ 2008-02-19 16:37 UTC (permalink / raw)
To: Alessandro Zummo; +Cc: linuxppc-dev, i2c
In-Reply-To: <20080219172450.0e4ccc7c@i1501.lan.towertech.it>
On Tue, 19 Feb 2008 17:24:50 +0100, Alessandro Zummo wrote:
> On Tue, 19 Feb 2008 16:10:20 +0100
> Jean Delvare <khali@linux-fr.org> wrote:
>
> > Hi Jon,
> >
> > On Mon, 21 Jan 2008 15:09:01 -0500, Jon Smirl wrote:
> > > Convert pfc8563 i2c driver from old style to new style.
> > >
> > > Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
> > > ---
> > >
> > > drivers/rtc/rtc-pcf8563.c | 107 +++++++++++----------------------------------
> > > 1 files changed, 27 insertions(+), 80 deletions(-)
> >
> > Preliminary note: this driver belongs to the RTC subsystem, so it will
> > be up to Alessandro Zummo (Cc'd) to push this patch upstream... when it
> > is ready to go there.
>
> A conversion to new style for this driver has already been
> pushed upstream. Adapting platforms to instantiate the device
> should be fairly easy, especially when you use the dts.
Ah, excellent. I didn't know, thanks for pointing it out. I'm glad I
added you to Cc :)
--
Jean Delvare
^ permalink raw reply
* Re: 2.6.24 for mpc8458amc
From: maxime louvel @ 2008-02-19 16:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <47BAEE3F.2070209@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]
Hi again,
this time I have tried to compile the kernel, with an embedded compiler on
the board.
here is the result...
....
BOOTAS arch/powerpc/boot/ps3-hvcall.o
BOOTCC arch/powerpc/boot/ps3.o
BOOTCC arch/powerpc/boot/treeboot-bamboo.o
BOOTCC arch/powerpc/boot/cuboot-8xx.o
BOOTCC arch/powerpc/boot/cuboot-pq2.o
BOOTCC arch/powerpc/boot/cuboot-sequoia.o
BOOTCC arch/powerpc/boot/treeboot-walnut.o
Assembler messages:
Error: Internal assembler error for instruction icbt
Internal error, aborting at ../../gas/config/tc-ppc.c line 1300 in
ppc_setup_opcodes
Please report this bug.
make[2]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2
make[1]: *** [uImage] Error 2
make: *** [sub-make] Error 2
any idea ?
cheers,
Maxime
On Feb 19, 2008 2:57 PM, Jon Loeliger <jdl@freescale.com> wrote:
> maxime louvel wrote:
> > Thanks for your answer,
> >
> > I am going to check this ppc / powerpc things.
> > I should use the architecture powerpc, don't I?
>
> ARCH == ppc is scheduled for _removal_ from the
> entire Kernel source base is just about 4 months.
> Feel free to move the deck chairs around. :-)
>
> > I'm not really sure I have understand what do you want to do with a
> > BDI-2000.
>
> Perhaps, for starters, you read "Building Embedded Linux Systems"
> as found here:
> http://www.oreilly.com/catalog/belinuxsys/
>
> > I access the cards through a serial line directly.
>
> Of course. But when you get no information there,
> you might try a different interface.
>
> jdl
>
--
Maxime Louvel
0044 7964 5555 80
43 Allen road
Whitemore reans
WV60AW Wolverhampton
United Kingdom
[-- Attachment #2: Type: text/html, Size: 2261 bytes --]
^ permalink raw reply
* Re: MPC8641D PCI-Express error
From: Marco Stornelli @ 2008-02-19 16:43 UTC (permalink / raw)
To: Jon Loeliger; +Cc: LinuxPPC-Embedded
In-Reply-To: <47BAFE6A.9050801@freescale.com>
Jon Loeliger ha scritto:
> Marco Stornelli wrote:
>>
>> Board: MPC8641D HPCN
>> SoC: MPC8641D rev. 2
>
> OK, this is good.
>
>> Kernel: 2.6.18
>
> And this is really old. Any chance of up-rev'ing
> that to something modern like 2.6.24? You may find
> that your PCI-E issues are Just Fixed there. Dunno.
>
> HTH,
> jdl
>
No, but I can try to backport the PCI-E code from 2.6.24 to 2.6.18 if it
could help. What do you think about it? Do you think this problem could
be not present in 2.6.24?
^ permalink raw reply
* RTC woes
From: Marc LeFevre @ 2008-02-19 16:34 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]
Hi:
I'm new to the list. I have an e500-based embedded Linux system running a
2.6.22 kernel. I have a PCF8563T i2c based RTC chip attached to the PPC i2c
bus. In my kernel config file I have selected CONFIG_RTC_INTF_DEV=y and
CONFIG_RTC_DRV_PCF8563=y. I do a mknod for /dev/rtc as c 10 135 (standard
Linux) and link /dev/rtc0 to it.
When I boot, get the following message:
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
and, of course I cannot access /dev/rtc after booting. I can, however, talk
to the rtc if I use /dev/i2c and a generic i2c read and write utility.
When I look in /proc/devices, I see that rtc has taken major number 254
which puzzles me. RTC should not need a dynamic major number, right? I have
perused the drivers in linux/drivers/rtc and don't find any of them calling
register_chrdev() to get a dynamic major number. So here are my questions:
1) Shouldn't rtc automagically use major/minor 10/135?
2) How can I find where in the source it asks for a dynamic major
number?
3) Does the PPC have some quirks regarding i2c operation that are at
the root of this problem?
BYW, I tried making the rtc device file as c 254 0 to match what's in
/proc/devices and that gives me the same bejavior.
Thanks in advance for any help you can offer.
Marc
[-- Attachment #2: Type: text/html, Size: 6488 bytes --]
^ permalink raw reply
* Re: [PATCH] mpc i2c driver, compare to NO_IRQ instead of zero
From: Jean Delvare @ 2008-02-19 16:42 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, i2c
In-Reply-To: <20080121200740.13800.20524.stgit@terra.home>
Hi Jon,
On Mon, 21 Jan 2008 15:07:40 -0500, Jon Smirl wrote:
> Alter the mpc i2c driver to use the NO_IRQ symbol instead of
> the constant zero when checking for valid interrupts. NO_IRQ=-1
> on ppc and NO_IRQ=0 on powerpc so the checks against zero are
> not correct.
Using NO_IRQ sounds good, just one question:
>
> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
> ---
>
> drivers/i2c/busses/i2c-mpc.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
>
> diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
> index bbe787b..d20959d 100644
> --- a/drivers/i2c/busses/i2c-mpc.c
> +++ b/drivers/i2c/busses/i2c-mpc.c
> @@ -99,7 +99,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
> u32 x;
> int result = 0;
>
> - if (i2c->irq == 0)
> + if (i2c->irq == NO_IRQ)
> {
> while (!(readb(i2c->base + MPC_I2C_SR) & CSR_MIF)) {
> schedule();
> @@ -329,7 +329,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> i2c->irq = platform_get_irq(pdev, 0);
> - if (i2c->irq < 0) {
> + if (i2c->irq < NO_IRQ) {
I am skeptical about this one. Can platform_get_irq() really return
NO_IRQ? I thought that the IRQ resource would be plain missing if the
device has no IRQ, so I would expect:
i2c->irq = platform_get_irq(pdev, 0);
if (i2c->irq < 0)
i2c->irq = NO_IRQ; /* Use polling */
Testing against NO_IRQ suggests that devices with no IRQ would still
have an IRQ resource defined and explicitly set to NO_IRQ. Sounds weird
to me. Can you please clarify this point?
For what it's worth, no other kernel driver checks for irq < NO_IRQ.
They all check for irq < 0 after calling platform_get_irq().
> result = -ENXIO;
> goto fail_get_irq;
> }
> @@ -344,7 +344,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> goto fail_map;
> }
>
> - if (i2c->irq != 0)
> + if (i2c->irq != NO_IRQ)
> if ((result = request_irq(i2c->irq, mpc_i2c_isr,
> IRQF_SHARED, "i2c-mpc", i2c)) < 0) {
> printk(KERN_ERR
> @@ -367,7 +367,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> return result;
>
> fail_add:
> - if (i2c->irq != 0)
> + if (i2c->irq != NO_IRQ)
> free_irq(i2c->irq, i2c);
> fail_irq:
> iounmap(i2c->base);
> @@ -384,7 +384,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
> i2c_del_adapter(&i2c->adap);
> platform_set_drvdata(pdev, NULL);
>
> - if (i2c->irq != 0)
> + if (i2c->irq != NO_IRQ)
> free_irq(i2c->irq, i2c);
>
> iounmap(i2c->base);
The rest looks good.
--
Jean Delvare
^ permalink raw reply
* Re: reg Philips ISP 1562 usb controller support in linux2.6.23.11
From: Clemens Koller @ 2008-02-19 16:53 UTC (permalink / raw)
To: mahendra varman; +Cc: linuxppc-embedded
In-Reply-To: <4ac2955e0802190807s5a19cdfeo6788fc5874424847@mail.gmail.com>
Hello, Magendra!
mahendra varman schrieb:
> Iam using a powerpc processor (7448)
> cat proc/cpu info is
> processor : 0
> cpu : 7448
> revision : 2.2 (pvr 8004 0202)
> bogomips : 995.32
> vendor : Cornet India Ltd
> machine : CTP7448
> PB freq : 133Mhz
> SDC freq : 0Mhz
>
> Sir, Today I noticed that when ever i insert a mp3usb stick it is giving
> Unlink after no-IRQ? "
> "Controller is probably using the wrong IRQ"
Try booting the kernel with "irqpoll". Example:
> linux noapic pci=irqroute pci=noacpi acpi=off irqpoll
Check if that helps.
> but if i insert an usbflash stick(without mp3) It is enumerating and i
> can able to mount the usb and read the content
>
> I wonder why iam getting unlink after no IRQ for some devices and for
> others iam not getting that
Well, I just don't know.
What kernel architecture do you use? ppc or powerpc?
In case you use the former (which is deprecated),
you might want to try the latter.
> Please clear my query sir
(-: Please follow my advices:
1. DO NOT remove the mailing list from CC: (and the chance anybody is
able to help you!)
2. post the output of lspci -vv.
Next step is: contact the guys in the linux-usb mailing list.
Regards,
Clemens
^ permalink raw reply
* Re: MPC8641D PCI-Express error
From: Jon Loeliger @ 2008-02-19 16:59 UTC (permalink / raw)
To: Marco Stornelli; +Cc: LinuxPPC-Embedded
In-Reply-To: <47BB071E.4020204@coritel.it>
Marco Stornelli wrote:
> No, but I can try to backport the PCI-E code from 2.6.24 to 2.6.18 if it
> could help. What do you think about it? Do you think this problem could
> be not present in 2.6.24?
I have no idea there, honestly. Sorry.
jdl
^ permalink raw reply
* Re: 2.6.24 for mpc8458amc
From: Scott Wood @ 2008-02-19 17:53 UTC (permalink / raw)
To: maxime louvel; +Cc: linuxppc-embedded
In-Reply-To: <dda529d0802190838h7c72b590gc6b26ed868bac8e5@mail.gmail.com>
maxime louvel wrote:
> Hi again,
>
> this time I have tried to compile the kernel, with an embedded compiler
> on the board.
> here is the result...
>
> ....
> BOOTAS arch/powerpc/boot/ps3-hvcall.o
> BOOTCC arch/powerpc/boot/ps3.o
> BOOTCC arch/powerpc/boot/treeboot-bamboo.o
> BOOTCC arch/powerpc/boot/cuboot-8xx.o
> BOOTCC arch/powerpc/boot/cuboot-pq2.o
> BOOTCC arch/powerpc/boot/cuboot-sequoia.o
> BOOTCC arch/powerpc/boot/treeboot-walnut.o
> Assembler messages:
> Error: Internal assembler error for instruction icbt
> Internal error, aborting at ../../gas/config/tc-ppc.c line 1300 in
> ppc_setup_opcodes
> Please report this bug.
> make[2]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2
> make[1]: *** [uImage] Error 2
> make: *** [sub-make] Error 2
That's a bug in older toolchains, which is aggravated by a misguided
policy that we build all wrapper platforms, always. Either use a newer
toolchain, or remove treeboot-walnut from arch/powerpc/boot/Makefile.
-Scott
^ permalink raw reply
* Status of I2C on mpc5200
From: Eric DUJARDIN @ 2008-02-19 18:00 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]
Hello all,
I have a question regarding the stability of I2C on mpc52xx.
According to menuconfig's help it isn't still stable as it says:
"The driver may also work on 52xx family processors, though interrupts are
known not to work"
However there has been a patch from Domen Puncer that apparently fixed the
driver in 2.6.23.
commit 254db9b5e7b1b0d38a4f177c2c23a5685c78221a
Author: Domen Puncer <domen.puncer@telargo.com>
Date: Thu Jul 12 14:12:31 2007 +0200
i2c-mpc: work around missing-9th-clock-pulse bug
Work around a problem reported on:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
Without this patch I2C on mpc5200 becomes unusable after a while.
Tested on mpc5200 boards by Matthias Fechner and me.
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
If any kind soul could provide a status I'd be glad to provide the patch
for the help file...
Thanks,
Eric Dujardin
" Ce courriel et les documents qui y sont attaches peuvent contenir des informations confidentielles. Si vous n'etes pas le destinataire escompte, merci d'en informer l'expediteur immediatement et de detruire ce courriel ainsi que tous les documents attaches de votre systeme informatique. Toute divulgation, distribution ou copie du present courriel et des documents attaches sans autorisation prealable de son emetteur est interdite."
" This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, please advise the sender immediately and delete this e-mail and all attached documents from your computer system. Any unauthorised disclosure, distribution or copying hereof is prohibited."
[-- Attachment #2: Type: text/html, Size: 2666 bytes --]
^ permalink raw reply
* RE: Frustrated question with insmod
From: Sugathan, Rupesh @ 2008-02-19 18:04 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-embedded
> Bruce_Leonard@selinc.com wrote:
> > Sorry if this is the wrong place to post this question. I'm
developing a=20
> > NAND flash driver and I need to do some detailed dubugging using GDB
with=20
> > a BDI2K. According to the Denx web site, to find out the address=20
> > that
the=20
> > module is loading at you load it using the -m parameter to insmod
(i.e.,=20
> > "insmod -m mymodule"). However, every version of insmod I've tried=20
> > doesn't recognize ANY options much less -m. Can anyone please point
me in=20
> > the right direction, or give me another way of knowing what the load
> > address of my module is?
>=20
> # cat /sys/module/<name>/sections/.text
>=20
> Do not forget to enable CONFIG_KALLSYMS.
Although this may not solve your problem, I once had to build insmod
with CONFIG_FEATURE_INSMOD_LOAD_MAP (this is not enabled by default)
option in its configuration to enable the -m option.
Thanks
..
Rupesh Sugathan
^ permalink raw reply
* Re: [patch 4/4] RFC: PCI: consolidate several pcibios_enable_resources() implementations
From: Ivan Kokshaysky @ 2008-02-19 17:08 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-pci, linux-arm-kernel, Russell King
In-Reply-To: <200802190911.56901.bjorn.helgaas@hp.com>
On Tue, Feb 19, 2008 at 09:11:55AM -0700, Bjorn Helgaas wrote:
> > That is, whatever the arch code decides to use to decide whether
> > resources are assigned by firmware or by the first pass assignment code
> > or not and collide or not, once that phase is finished (which is the
> > case when calling pcibios_enable_device(), having the resource in the
> > resource-tree or not is, I believe, the proper way to test whether it's
> > a useable resource.
>
> So should x86 adopt that collision check?
Yes, and other arches as well, I believe.
> I don't hear anything about
> actual architecture differences that are behind this implementation
> difference.
On ppc64 "0" can be a valid value for resource start, as far as I know.
Ivan.
^ permalink raw reply
* Re: [patch 0/4] RFC: PCI: consolidate several pcibios_enable_resources() implementations
From: Bjorn Helgaas @ 2008-02-19 18:02 UTC (permalink / raw)
To: benh
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-pci, Russell King, linux-arm-kernel
In-Reply-To: <1203415712.6740.102.camel@pasglop>
On Tuesday 19 February 2008 03:08:32 am Benjamin Herrenschmidt wrote:
> On Tue, 2008-02-19 at 08:09 +0000, Russell King wrote:
> > On Mon, Feb 18, 2008 at 09:39:52PM -0700, Bjorn Helgaas wrote:
> > >
> > > ARM and PA-RISC, in particular, have interesting differences:
> > > - ARM always enables bridge devices, which no other arch does
> >
> > ARM does this because there is nothing else which would do that - which
> > means devices behind bridges would be completely inaccessible.
>
> That's normally done by pci_enable_bridges() called by
> pci_assign_unassigned_resources().
alpha, mips, mn10300, powerpc, and x86 use pci_enable_bridges() via
pci_assign_unassigned_resources(). parisc uses pci_enable_bridges()
directly from lba_driver_probe(). I guess the other arches (except
arm) rely on firmware to enable bridge.
I think pci_assign_unassigned_resources() is a bit of an anachronism --
it's a boot-time thing that does it for all root buses at once. A
more hot-plug oriented scheme would do it like parisc, where every
time we discover a root bridge, we do any necessary resource assignment
and bridge enablement underneath it.
For ARM, maybe that could happen in pcibios_init_hw() or something
similar.
> > > - PA-RISC always turns on SERR and PARITY, which no other arch does
> >
> > ARM also does this, unless pdev_bad_for_parity(dev) is true. See
> > ARMs pcibios_fixup_bus().
>
> While that sounds like a good idea to generalize, I think it should
> remain arch stuff tho, not move to generic code.
>
> On some platforms, weirdo firmwares handle error handling and will be
> unhappy if the kernel mucks around (such as pSeries).
I agree the SERR and PARITY stuff probably needs to remain arch code.
But it would be nice to at least have this and the bridge enable done in
similar places across arches.
Bjorn
^ permalink raw reply
* [PATCH v2][POWERPC] Fix initial lmb add region with a non-zero base
From: Kumar Gala @ 2008-02-19 19:51 UTC (permalink / raw)
To: davem; +Cc: sparclinux, linuxppc-dev, linux-kernel
If we add to an empty lmb region with a non-zero base we will not coalesce
the number of regions down to one. This causes problems on ppc32 for the
memory region as its assumed to only have one region.
We can fix this easily by causing the initial add to replace the dummy
region.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Fix a bug the initial patch introduced if we have a region that gets added
at the beginning of the list we wouldn't actually add it.
Dave can you replace the patch in you tree with this one.
arch/powerpc/mm/lmb.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/lmb.c b/arch/powerpc/mm/lmb.c
index 4ce23bc..4bf8f19 100644
--- a/arch/powerpc/mm/lmb.c
+++ b/arch/powerpc/mm/lmb.c
@@ -141,6 +141,12 @@ static long __init lmb_add_region(struct lmb_region *rgn, unsigned long base,
unsigned long coalesced = 0;
long adjacent, i;
+ if ((rgn->cnt == 1) && (rgn->region[0].size == 0)) {
+ rgn->region[0].base = base;
+ rgn->region[0].size = size;
+ return 0;
+ }
+
/* First try and coalesce this LMB with another. */
for (i=0; i < rgn->cnt; i++) {
unsigned long rgnbase = rgn->region[i].base;
@@ -185,6 +191,12 @@ static long __init lmb_add_region(struct lmb_region *rgn, unsigned long base,
break;
}
}
+
+ if (base < rgn->region[0].base) {
+ rgn->region[0].base = base;
+ rgn->region[0].size = size;
+ }
+
rgn->cnt++;
return 0;
--
1.5.3.8
^ permalink raw reply related
* Re: 2.6.24 for mpc8458amc
From: Josh Boyer @ 2008-02-19 20:17 UTC (permalink / raw)
To: Scott Wood; +Cc: maxime louvel, linuxppc-embedded
In-Reply-To: <47BB177E.1070602@freescale.com>
On Tue, 19 Feb 2008 11:53:02 -0600
Scott Wood <scottwood@freescale.com> wrote:
> maxime louvel wrote:
> > Hi again,
> >
> > this time I have tried to compile the kernel, with an embedded compiler
> > on the board.
> > here is the result...
> >
> > ....
> > BOOTAS arch/powerpc/boot/ps3-hvcall.o
> > BOOTCC arch/powerpc/boot/ps3.o
> > BOOTCC arch/powerpc/boot/treeboot-bamboo.o
> > BOOTCC arch/powerpc/boot/cuboot-8xx.o
> > BOOTCC arch/powerpc/boot/cuboot-pq2.o
> > BOOTCC arch/powerpc/boot/cuboot-sequoia.o
> > BOOTCC arch/powerpc/boot/treeboot-walnut.o
> > Assembler messages:
> > Error: Internal assembler error for instruction icbt
> > Internal error, aborting at ../../gas/config/tc-ppc.c line 1300 in
> > ppc_setup_opcodes
> > Please report this bug.
> > make[2]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2
> > make[1]: *** [uImage] Error 2
> > make: *** [sub-make] Error 2
>
> That's a bug in older toolchains, which is aggravated by a misguided
> policy that we build all wrapper platforms, always. Either use a newer
> toolchain, or remove treeboot-walnut from arch/powerpc/boot/Makefile.
It would be good to know what versions of binutils and gcc are being
used though.
josh
^ permalink raw reply
* Re: MPC8641D PCI-Express error
From: Kumar Gala @ 2008-02-19 20:19 UTC (permalink / raw)
To: Marco Stornelli; +Cc: LinuxPPC-Embedded
In-Reply-To: <47BB0ADE.60501@freescale.com>
On Feb 19, 2008, at 10:59 AM, Jon Loeliger wrote:
> Marco Stornelli wrote:
>
>> No, but I can try to backport the PCI-E code from 2.6.24 to 2.6.18
>> if it
>> could help. What do you think about it? Do you think this problem
>> could
>> be not present in 2.6.24?
>
> I have no idea there, honestly. Sorry.
As Jon said, try 2.6.24 and see if it has an issue, if so we can look
at helping. if not, you know you need to back port the fixes.
- k
^ permalink raw reply
* Re: [patch 4/4] RFC: PCI: consolidate several pcibios_enable_resources() implementations
From: Benjamin Herrenschmidt @ 2008-02-19 20:21 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-pci, linux-arm-kernel, Russell King
In-Reply-To: <200802190911.56901.bjorn.helgaas@hp.com>
> > That is, whatever the arch code decides to use to decide whether
> > resources are assigned by firmware or by the first pass assignment code
> > or not and collide or not, once that phase is finished (which is the
> > case when calling pcibios_enable_device(), having the resource in the
> > resource-tree or not is, I believe, the proper way to test whether it's
> > a useable resource.
>
> So should x86 adopt that collision check? I don't hear anything about
> actual architecture differences that are behind this implementation
> difference.
Well, on powerpc we do allow under some circumstances a 0 start value
in BARs, which is why I wanted to use a different check.
Ben.
^ permalink raw reply
* Re: [PATCH 2/2] i2c-ibm_iic driver
From: Sean MacLennan @ 2008-02-19 21:58 UTC (permalink / raw)
To: Jean Delvare; +Cc: LinuxPPC-dev, i2c
In-Reply-To: <20080219092321.1fed233d@hyperion.delvare>
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
--- for-2.6.25/drivers/i2c/busses/orig-i2c-ibm_iic.c 2008-02-18 16:36:30.000000000 -0500
+++ for-2.6.25/drivers/i2c/busses/i2c-ibm_iic.c 2008-02-19 16:46:35.000000000 -0500
@@ -6,6 +6,9 @@
* Copyright (c) 2003, 2004 Zultys Technologies.
* Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
*
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ *
* Based on original work by
* Ian DaSilva <idasilva@mvista.com>
* Armin Kuster <akuster@mvista.com>
@@ -39,12 +42,17 @@
#include <asm/io.h>
#include <linux/i2c.h>
#include <linux/i2c-id.h>
+
+#ifdef CONFIG_IBM_OCP
#include <asm/ocp.h>
#include <asm/ibm4xx.h>
+#else
+#include <linux/of_platform.h>
+#endif
#include "i2c-ibm_iic.h"
-#define DRIVER_VERSION "2.1"
+#define DRIVER_VERSION "2.2"
MODULE_DESCRIPTION("IBM IIC driver v" DRIVER_VERSION);
MODULE_LICENSE("GPL");
@@ -657,6 +665,7 @@
return (u8)((opb + 9) / 10 - 1);
}
+#ifdef CONFIG_IBM_OCP
/*
* Register single IIC interface
*/
@@ -828,5 +837,181 @@
ocp_unregister_driver(&ibm_iic_driver);
}
+#else /* !CONFIG_IBM_OCP */
+
+static int __devinit iic_request_irq(struct of_device *ofdev,
+ struct ibm_iic_private *dev)
+{
+ struct device_node *np = ofdev->node;
+ int irq;
+
+ if (iic_force_poll)
+ return NO_IRQ;
+
+ irq = irq_of_parse_and_map(np, 0);
+ if (irq == NO_IRQ) {
+ dev_err(&ofdev->dev, "irq_of_parse_and_map failed\n");
+ return NO_IRQ;
+ }
+
+ /* Disable interrupts until we finish initialization, assumes
+ * level-sensitive IRQ setup...
+ */
+ iic_interrupt_mode(dev, 0);
+ if (request_irq(irq, iic_handler, 0, "IBM IIC", dev)) {
+ dev_err(&ofdev->dev, "request_irq %d failed\n", irq);
+ /* Fallback to the polling mode */
+ return NO_IRQ;
+ }
+
+ return irq;
+}
+
+/*
+ * Register single IIC interface
+ */
+static int __devinit iic_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct device_node *np = ofdev->node;
+ struct ibm_iic_private *dev;
+ struct i2c_adapter *adap;
+ const u32 *indexp, *freq;
+ int ret;
+
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev) {
+ dev_err(&ofdev->dev, "failed to allocate device data\n");
+ return -ENOMEM;
+ }
+
+ dev_set_drvdata(&ofdev->dev, dev);
+
+ indexp = of_get_property(np, "index", NULL);
+ if (!indexp) {
+ dev_err(&ofdev->dev, "no index specified\n");
+ ret = -EINVAL;
+ goto error_cleanup;
+ }
+ dev->idx = *indexp;
+
+ dev->vaddr = of_iomap(np, 0);
+ if (dev->vaddr == NULL) {
+ dev_err(&ofdev->dev, "failed to iomap device\n");
+ ret = -ENXIO;
+ goto error_cleanup;
+ }
+
+ init_waitqueue_head(&dev->wq);
+
+ dev->irq = iic_request_irq(ofdev, dev);
+ if (dev->irq == NO_IRQ)
+ dev_warn(&ofdev->dev, "using polling mode\n");
+
+ /* Board specific settings */
+ if (iic_force_fast || of_get_property(np, "fast-mode", NULL))
+ dev->fast_mode = 1;
+
+ freq = of_get_property(np, "clock-frequency", NULL);
+ if (freq == NULL) {
+ freq = of_get_property(np->parent, "clock-frequency", NULL);
+ if (freq == NULL) {
+ dev_err(&ofdev->dev, "Unable to get bus frequency\n");
+ ret = -EINVAL;
+ goto error_cleanup;
+ }
+ }
+
+ dev->clckdiv = iic_clckdiv(*freq);
+ dev_dbg(&ofdev->dev, "clckdiv = %d\n", dev->clckdiv);
+
+ /* Initialize IIC interface */
+ iic_dev_init(dev);
+
+ /* Register it with i2c layer */
+ adap = &dev->adap;
+ adap->dev.parent = &ofdev->dev;
+ strlcpy(adap->name, "IBM IIC", sizeof(adap->name));
+ i2c_set_adapdata(adap, dev);
+ adap->id = I2C_HW_OCP;
+ adap->class = I2C_CLASS_HWMON;
+ adap->algo = &iic_algo;
+ adap->timeout = 1;
+ adap->nr = dev->idx;
+
+ ret = i2c_add_numbered_adapter(adap);
+ if (ret < 0) {
+ dev_err(&ofdev->dev, "failed to register i2c adapter\n");
+ goto error_cleanup;
+ }
+
+ dev_info(&ofdev->dev, "using %s mode\n",
+ dev->fast_mode ? "fast (400 kHz)" : "standard (100 kHz)");
+
+ return 0;
+
+error_cleanup:
+ if (dev->irq != NO_IRQ) {
+ iic_interrupt_mode(dev, 0);
+ free_irq(dev->irq, dev);
+ }
+
+ if (dev->vaddr)
+ iounmap(dev->vaddr);
+
+ dev_set_drvdata(&ofdev->dev, NULL);
+ kfree(dev);
+ return ret;
+}
+
+/*
+ * Cleanup initialized IIC interface
+ */
+static int __devexit iic_remove(struct of_device *ofdev)
+{
+ struct ibm_iic_private *dev = dev_get_drvdata(&ofdev->dev);
+
+ dev_set_drvdata(&ofdev->dev, NULL);
+
+ i2c_del_adapter(&dev->adap);
+
+ if (dev->irq != NO_IRQ) {
+ iic_interrupt_mode(dev, 0);
+ free_irq(dev->irq, dev);
+ }
+
+ iounmap(dev->vaddr);
+ kfree(dev);
+
+ return 0;
+}
+
+static const struct of_device_id ibm_iic_match[] = {
+ { .compatible = "ibm,iic-405ex", },
+ { .compatible = "ibm,iic-405gp", },
+ { .compatible = "ibm,iic-440gp", },
+ { .compatible = "ibm,iic-440gpx", },
+ { .compatible = "ibm,iic-440grx", },
+ {}
+};
+
+static struct of_platform_driver ibm_iic_driver = {
+ .name = "ibm-iic",
+ .match_table = ibm_iic_match,
+ .probe = iic_probe,
+ .remove = __devexit_p(iic_remove),
+};
+
+static int __init iic_init(void)
+{
+ return of_register_platform_driver(&ibm_iic_driver);
+}
+
+static void __exit iic_exit(void)
+{
+ of_unregister_platform_driver(&ibm_iic_driver);
+}
+#endif /* CONFIG_IBM_OCP */
+
module_init(iic_init);
module_exit(iic_exit);
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index b61f56b..bda87a0 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -244,7 +244,7 @@ config I2C_PIIX4
config I2C_IBM_IIC
tristate "IBM PPC 4xx on-chip I2C interface"
- depends on IBM_OCP
+ depends on 4xx
help
Say Y here if you want to use IIC peripheral found on
embedded IBM PPC 4xx based systems.
^ permalink raw reply related
* BUG: scheduling while atomic
From: John Linn @ 2008-02-19 22:22 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]
I'm using 2.6.24-rc8 on a PPC 440 and getting this error. I've also seen
another form of it when doing Telnet.
In this case, I'm doing a copy of a file on an NFS mount.
Any help would be appreciated.
Thanks,
John Linn
# cp ftptest2 ftptest2_copied
BUG: scheduling while atomic: cp/355/0x0ffffefe
Call Trace:
[cfc89ec0] [c000725c] show_stack+0x4c/0x174 (unreliable)
[cfc89ef0] [c0016880] __schedule_bug+0x54/0x68
[cfc89f10] [c01df464] schedule+0x50/0x300
[cfc89f40] [c0002374] recheck+0x0/0x24
BUG: scheduling while atomic: cp/355/0x0ffffefe
Call Trace:
[cfc89c50] [c000725c] show_stack+0x4c/0x174 (unreliable)
[cfc89c80] [c0016880] __schedule_bug+0x54/0x68
[cfc89ca0] [c01df464] schedule+0x50/0x300
[cfc89cd0] [c01df744] io_schedule+0x30/0x54
[cfc89cf0] [c003d79c] sync_page+0x44/0x58
[cfc89d00] [c01dfaf0] __wait_on_bit_lock+0x68/0xc8
[cfc89d20] [c003da28] __lock_page+0x64/0x78
[cfc89d60] [c00402d0] do_generic_mapping_read+0x218/0x418
[cfc89db0] [c00405fc] generic_file_aio_read+0x12c/0x1a8
[cfc89e00] [c00cba0c] nfs_file_read+0xf0/0x104
[cfc89e30] [c005b3d4] do_sync_read+0xb8/0x10c
[cfc89ef0] [c005b840] vfs_read+0xc0/0x154
[cfc89f10] [c005c3bc] sys_read+0x4c/0x8c
[cfc89f40] [c0001960] ret_from_syscall+0x0/0x3c
BUG: scheduling while atomic: cp/355/0x0ffffefe
Call Trace:
[-- Attachment #2: Type: text/html, Size: 11524 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] i2c-ibm_iic driver
From: Sean MacLennan @ 2008-02-19 22:23 UTC (permalink / raw)
To: Stefan Roese; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <200802190959.41253.sr@denx.de>
Stefan Roese wrote:
> How about this:
>
> - depends on IBM_OCP
> + depends on 4xx
>
That's what I did, great minds think alike ;) But the email does not
seem to have come through, so I will repost the patch. If you already
got an email with the above patch, you can ignore this one ;)
Cheers,
Sean
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
--- for-2.6.25/drivers/i2c/busses/orig-i2c-ibm_iic.c 2008-02-18 16:36:30.000000000 -0500
+++ for-2.6.25/drivers/i2c/busses/i2c-ibm_iic.c 2008-02-19 16:46:35.000000000 -0500
@@ -6,6 +6,9 @@
* Copyright (c) 2003, 2004 Zultys Technologies.
* Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
*
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ *
* Based on original work by
* Ian DaSilva <idasilva@mvista.com>
* Armin Kuster <akuster@mvista.com>
@@ -39,12 +42,17 @@
#include <asm/io.h>
#include <linux/i2c.h>
#include <linux/i2c-id.h>
+
+#ifdef CONFIG_IBM_OCP
#include <asm/ocp.h>
#include <asm/ibm4xx.h>
+#else
+#include <linux/of_platform.h>
+#endif
#include "i2c-ibm_iic.h"
-#define DRIVER_VERSION "2.1"
+#define DRIVER_VERSION "2.2"
MODULE_DESCRIPTION("IBM IIC driver v" DRIVER_VERSION);
MODULE_LICENSE("GPL");
@@ -657,6 +665,7 @@
return (u8)((opb + 9) / 10 - 1);
}
+#ifdef CONFIG_IBM_OCP
/*
* Register single IIC interface
*/
@@ -828,5 +837,181 @@
ocp_unregister_driver(&ibm_iic_driver);
}
+#else /* !CONFIG_IBM_OCP */
+
+static int __devinit iic_request_irq(struct of_device *ofdev,
+ struct ibm_iic_private *dev)
+{
+ struct device_node *np = ofdev->node;
+ int irq;
+
+ if (iic_force_poll)
+ return NO_IRQ;
+
+ irq = irq_of_parse_and_map(np, 0);
+ if (irq == NO_IRQ) {
+ dev_err(&ofdev->dev, "irq_of_parse_and_map failed\n");
+ return NO_IRQ;
+ }
+
+ /* Disable interrupts until we finish initialization, assumes
+ * level-sensitive IRQ setup...
+ */
+ iic_interrupt_mode(dev, 0);
+ if (request_irq(irq, iic_handler, 0, "IBM IIC", dev)) {
+ dev_err(&ofdev->dev, "request_irq %d failed\n", irq);
+ /* Fallback to the polling mode */
+ return NO_IRQ;
+ }
+
+ return irq;
+}
+
+/*
+ * Register single IIC interface
+ */
+static int __devinit iic_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct device_node *np = ofdev->node;
+ struct ibm_iic_private *dev;
+ struct i2c_adapter *adap;
+ const u32 *indexp, *freq;
+ int ret;
+
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev) {
+ dev_err(&ofdev->dev, "failed to allocate device data\n");
+ return -ENOMEM;
+ }
+
+ dev_set_drvdata(&ofdev->dev, dev);
+
+ indexp = of_get_property(np, "index", NULL);
+ if (!indexp) {
+ dev_err(&ofdev->dev, "no index specified\n");
+ ret = -EINVAL;
+ goto error_cleanup;
+ }
+ dev->idx = *indexp;
+
+ dev->vaddr = of_iomap(np, 0);
+ if (dev->vaddr == NULL) {
+ dev_err(&ofdev->dev, "failed to iomap device\n");
+ ret = -ENXIO;
+ goto error_cleanup;
+ }
+
+ init_waitqueue_head(&dev->wq);
+
+ dev->irq = iic_request_irq(ofdev, dev);
+ if (dev->irq == NO_IRQ)
+ dev_warn(&ofdev->dev, "using polling mode\n");
+
+ /* Board specific settings */
+ if (iic_force_fast || of_get_property(np, "fast-mode", NULL))
+ dev->fast_mode = 1;
+
+ freq = of_get_property(np, "clock-frequency", NULL);
+ if (freq == NULL) {
+ freq = of_get_property(np->parent, "clock-frequency", NULL);
+ if (freq == NULL) {
+ dev_err(&ofdev->dev, "Unable to get bus frequency\n");
+ ret = -EINVAL;
+ goto error_cleanup;
+ }
+ }
+
+ dev->clckdiv = iic_clckdiv(*freq);
+ dev_dbg(&ofdev->dev, "clckdiv = %d\n", dev->clckdiv);
+
+ /* Initialize IIC interface */
+ iic_dev_init(dev);
+
+ /* Register it with i2c layer */
+ adap = &dev->adap;
+ adap->dev.parent = &ofdev->dev;
+ strlcpy(adap->name, "IBM IIC", sizeof(adap->name));
+ i2c_set_adapdata(adap, dev);
+ adap->id = I2C_HW_OCP;
+ adap->class = I2C_CLASS_HWMON;
+ adap->algo = &iic_algo;
+ adap->timeout = 1;
+ adap->nr = dev->idx;
+
+ ret = i2c_add_numbered_adapter(adap);
+ if (ret < 0) {
+ dev_err(&ofdev->dev, "failed to register i2c adapter\n");
+ goto error_cleanup;
+ }
+
+ dev_info(&ofdev->dev, "using %s mode\n",
+ dev->fast_mode ? "fast (400 kHz)" : "standard (100 kHz)");
+
+ return 0;
+
+error_cleanup:
+ if (dev->irq != NO_IRQ) {
+ iic_interrupt_mode(dev, 0);
+ free_irq(dev->irq, dev);
+ }
+
+ if (dev->vaddr)
+ iounmap(dev->vaddr);
+
+ dev_set_drvdata(&ofdev->dev, NULL);
+ kfree(dev);
+ return ret;
+}
+
+/*
+ * Cleanup initialized IIC interface
+ */
+static int __devexit iic_remove(struct of_device *ofdev)
+{
+ struct ibm_iic_private *dev = dev_get_drvdata(&ofdev->dev);
+
+ dev_set_drvdata(&ofdev->dev, NULL);
+
+ i2c_del_adapter(&dev->adap);
+
+ if (dev->irq != NO_IRQ) {
+ iic_interrupt_mode(dev, 0);
+ free_irq(dev->irq, dev);
+ }
+
+ iounmap(dev->vaddr);
+ kfree(dev);
+
+ return 0;
+}
+
+static const struct of_device_id ibm_iic_match[] = {
+ { .compatible = "ibm,iic-405ex", },
+ { .compatible = "ibm,iic-405gp", },
+ { .compatible = "ibm,iic-440gp", },
+ { .compatible = "ibm,iic-440gpx", },
+ { .compatible = "ibm,iic-440grx", },
+ {}
+};
+
+static struct of_platform_driver ibm_iic_driver = {
+ .name = "ibm-iic",
+ .match_table = ibm_iic_match,
+ .probe = iic_probe,
+ .remove = __devexit_p(iic_remove),
+};
+
+static int __init iic_init(void)
+{
+ return of_register_platform_driver(&ibm_iic_driver);
+}
+
+static void __exit iic_exit(void)
+{
+ of_unregister_platform_driver(&ibm_iic_driver);
+}
+#endif /* CONFIG_IBM_OCP */
+
module_init(iic_init);
module_exit(iic_exit);
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index b61f56b..bda87a0 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -244,7 +244,7 @@ config I2C_PIIX4
config I2C_IBM_IIC
tristate "IBM PPC 4xx on-chip I2C interface"
- depends on IBM_OCP
+ depends on 4xx
help
Say Y here if you want to use IIC peripheral found on
embedded IBM PPC 4xx based systems.
^ permalink raw reply related
* Re: [PATCH 1/3] Fix Unlikely(x) == y
From: Nick Piggin @ 2008-02-19 22:25 UTC (permalink / raw)
To: Andi Kleen
Cc: Roel Kluin, lkml, Willy Tarreau, linuxppc-dev, cbe-oss-dev,
Arjan van de Ven
In-Reply-To: <20080219095702.GA6940@one.firstfloor.org>
On Tuesday 19 February 2008 20:57, Andi Kleen wrote:
> On Tue, Feb 19, 2008 at 08:46:46PM +1100, Nick Piggin wrote:
> > I think it was just a simple context switch benchmark, but not lmbench
> > (which I found to be a bit too variable). But it was a long time ago...
>
> Do you still have it?
>
> I thought about writing my own but ended up being too lazy for that @)
Had a quick look but couldn't find it. It was just two threads running
and switching to each other with a couple of mutexes or yield. If I
find it, then I'll send it over.
> > > > Actually one thing I don't like about gcc is that I think it still
> > > > emits cmovs for likely/unlikely branches,
> > >
> > > That's -Os.
> >
> > And -O2 and -O3, on the gccs that I'm using, AFAIKS.
>
> Well if it still happens on gcc 4.2 with P4 tuning you should
> perhaps open a gcc PR. They tend to ignore these bugs mostly in
> my experience, but sometimes they act on them.
I'm not sure about P4 tuning... But even IMO it should not on
predictable branches too much for any (especially OOOE) CPU.
> > > > which is silly (the gcc developers
> > >
> > > It depends on the CPU. e.g. on K8 and P6 using CMOV if possible
> > > makes sense. P4 doesn't like it though.
> >
> > If the branch is completely predictable (eg. annotated), then I
> > think branches should be used anyway. Even on well predicted
> > branches, cmov is similar speed on microbenchmarks, but it will
> > increase data hazards I think, so it will probably be worse for
> > some real world situations.
>
> At least the respective optimization manuals say they should be used.
> I presume they only made this recommendation after some extensive
> benchmarking.
What I have seen is that they tell you definitely not to use it for
predictable branches. Eg. the Intel optimization manual says
Use the setcc and cmov instructions to eliminate unpredictable
conditional branches where possible. Do not do this for predictable
branches. Do not use these instructions to eliminate all
unpredictable conditional branches, because using these instructions
will incur execution overhead due to executing both paths of a
conditional branch. In addition, converting conditional branches to
cmovs or setcc trades control-flow dependence for data dependence
and restricts the capability of the out-of-order engine.
> > But a likely branch will be _strongly_ predicted to be taken,
> > wheras a lot of the gcc heuristics simply have slightly more or
> > slightly less probability. So it's not just a question of which
> > way is more likely, but also _how_ likely it is to go that way.
>
> Yes, but a lot of the heuristics are pretty strong (>80%) and gcc will
> act on them unless it has a very strong contra cue. And that should
> normally not be the case.
True, but if you know a branch is 99%+, then use of likely/unlikely
can still be a good idea. 80% may not be enough to choose a branch
over a cmov for example.
^ permalink raw reply
* Re: RTC woes
From: Clemens Koller @ 2008-02-19 22:30 UTC (permalink / raw)
To: Marc LeFevre; +Cc: linuxppc-embedded
In-Reply-To: <06cb01c87315$5dad6010$f30213ac@isd.cypress.com>
Marc LeFevre schrieb:
> I’m new to the list.
Welcome! :-)
> I have an e500-based embedded Linux system running
> a 2.6.22 kernel. I have a PCF8563T i2c based RTC chip attached to the
> PPC i2c bus. In my kernel config file I have selected
> CONFIG_RTC_INTF_DEV=y and CONFIG_RTC_DRV_PCF8563=y. I do a mknod for
> /dev/rtc as c 10 135 (standard Linux) and link /dev/rtc0 to it.
>
> When I boot, get the following message:
>
> drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
2.6.22.x and 2.6.23.x i2c rtc code was quite messy around PCF8563.
> 3) Does the PPC have some quirks regarding i2c operation that are
> at the root of this problem?
The RTC subsystem was improved quite a bit lately. Try 2.6.24' powerpc
architecture with a proper device tree instead. It works over here on
mpc8540 / mpc8548 whereas the older ones were just a waste of time.
Regards,
Clemens
^ 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