* Re: 'make ARCH=ppc defconfig' failing for cross-compile
From: Judith Lebzelter @ 2006-09-15 19:22 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Judith Lebzelter
In-Reply-To: <1158203522.7305.14.camel@localhost.localdomain>
On Thu, Sep 14, 2006 at 01:12:01PM +1000, Michael Ellerman wrote:
> On Tue, 2006-09-12 at 10:48 -0700, Judith Lebzelter wrote:
> > On Tue, Sep 12, 2006 at 10:21:46AM -0700, Christian wrote:
> > > On Fri, 8 Sep 2006, Judith Lebzelter wrote:
> > > > I have been doing cross-compiles for ppc and powerpc on my i686 system.
> > > > In order to do this I generate the .config file like this:
> > > >
> > > > make ARCH=ppc defconfig
> > > > (or make ARCH=powerpc defconfig)
> > >
> > > Seems like defconfig has been removed, because there are so many
> > > sub-platforms for ppc:
> >
> > I build these in OSDL's cross compile build farm (PLM) as a code check.
> > Our scripts are generalized to work for various architectures, so it is
> > disappointing that 'defconfig' no longer works for ppc the way it does
> > in other achitectures. Are there plans to make plain 'defconfig' work
> > again, at least in the new 'powerpc' directory? (The 'ppc64_defconfig'
> > target looks good to me.:)
>
> Perhaps you need to rework the scripts to cope for the fact that there
> are different platforms under the architecture? There will never be a
> defconfig for powerpc that builds all the code for all platforms, so to
> get full test coverage you'll need to build more than one config anyway.
>
Yes, I do not get full code coverage, which would be the ideal.
However, I do run defconfig, allmodconfig, allyesconfig and allnoconfig
and have found issues doing this. There is value in running for a
few representative ppc architectures, which I do. That is why 'defconfig'
is (was) handy for me.
I additionally compile other architectures such as i386, ia64, x86_64,
arm, sparc64. People can submit their kernel patches to see how
their code compiles, and usually this is more platforms than they would
do at home.:)
Thanks,
Judith
> cheers
>
> --
> Michael Ellerman
> OzLabs, IBM Australia Development Lab
>
> wwweb: http://michael.ellerman.id.au
> phone: +61 2 6212 1183 (tie line 70 21183)
>
> We do not inherit the earth from our ancestors,
> we borrow it from our children. - S.M.A.R.T Person
^ permalink raw reply
* RE: Ethernet driver for Linux kernel 2.6 running on ML403
From: John Bonesio @ 2006-09-15 19:13 UTC (permalink / raw)
To: Keith J Outwater, linuxppc-embedded
Hi Keith,
I know that on the surface it seems like a simple thing. Some of our
parts are big, yet some are small. We are always getting pressure to
make our IP as small as possible.
Though, this may be something we can revisit again, for now this
information just isn't going to be available.
Perhaps the problem can be solved in a different way.
- John
-----Original Message-----
From: linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org] On
Behalf Of Keith J Outwater
Sent: Thursday, September 14, 2006 5:09 PM
To: linuxppc-embedded@ozlabs.org
Subject: RE: Ethernet driver for Linux kernel 2.6 running on ML403
"John Bonesio" <john.bonesio@xilinx.com> wrote on 09/14/2006 10:52:16
AM:
<snip>
>=20
> I don't think that there are any "version" registers in the Xilinx=20
> IP cores that a driver could check to determine compatibility. That
> would be very cheap to implement in hardware and you could then
> develop more universal drivers.
>=20
> [John]
> We've examined doing this in the past, and gotten some push back due
to
> the use of bram or other resources. Conceptually, it's a great idea, I
> just don't know if this is likely to happen any time soon.
>=20
John,
I thinking in terms of something like a 32 bit register
(i.e. like a processor's PVR register) that has a hard-coded magic
number
which a driver can read and decode to determine driver compatibility.
That does not sound resource-intensive given the size FPGAs we are
talking
about. Probably don't even need 32 bits.
Keith
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] PPC: Fix xmon stack frame address in backtrace
From: Josh Boyer @ 2006-09-15 19:53 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
The stack frame address was being printed incorrectly in the backtrace
option of XMON on PPC. This patch fixes it to print the actual stack
address instead of the address of the local variable that contains it.
Patch is against current powerpc.git tree.
Signed-off-by: Josh Boyer <jdub@us.ibm.com>
---
arch/ppc/xmon/xmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.orig/arch/ppc/xmon/xmon.c
+++ linux-2.6/arch/ppc/xmon/xmon.c
@@ -806,7 +806,7 @@ backtrace(struct pt_regs *excp)
for (; sp != 0; sp = stack[0]) {
if (mread(sp, stack, sizeof(stack)) != sizeof(stack))
break;
- printf("[%.8lx] ", stack);
+ printf("[%.8lx] ", stack[0]);
xmon_print_symbol(stack[1], " ", "\n");
if (stack[1] == (unsigned) &ret_from_except
|| stack[1] == (unsigned) &ret_from_except_full
^ permalink raw reply
* Kernel Blocked
From: wei.li4 @ 2006-09-15 19:51 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
First, if anyone wants to use linux 2.6.18-rc2-g73a589b5 with ppc, he
should patch inflate.c from linux 2.6.18-rc7 to fix Uncompressing
failure problem. But new problem is: when relocate and gunzip functions
are finished, and 'Now booting the kernel' is shown, the system is
halted. My bootloader is working fine with linux 2.6.13, could anyone
tell me what the next function executes and how to check this kind of
problem, thanks.
Wei
^ permalink raw reply
* Re: Please pull powerpc.git 'merge' branch
From: Linus Torvalds @ 2006-09-15 19:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0609141633310.4388@g5.osdl.org>
On Thu, 14 Sep 2006, Linus Torvalds wrote:
>
> Ok, maybe the debian brokenness exists in FC5 too, and a "yum upgrade"
> broke it for me rather than any kernel work.
That does seem to be the case. The printer is back up, apparently after a
"cups-lpr" update. Sorry about the noise, although the strace thing still
bothers me. Not enough to pursue it any more, though ;)
Linus
^ permalink raw reply
* Kernel module insertion issue with kernel 2.6.15
From: Prakash Jain @ 2006-09-15 19:56 UTC (permalink / raw)
To: Linux PPC List
Hi,
I am relatively new to this list/area, not sure if this is right forum
for my query (please point me to right list in that case).
I am porting my software from 2.4 kernel to 2.6.15 on a board similar to
ppc 82xx sandpoint architecture. I am able to make the board functional
except the following issue. One of my kernel module (inserted thru
insmod) takes almost 6-7 minutes to load with 2.6 kernel while it used
to take only few seconds with 2.4 kernel. Yet, after the long wait
module is inserted correctly with 2.6 kernel as board software works
fine after that. When I halt the processor (using BDI2000) during the
long wait, it always halts in function get_plt_size() in kernel's
arch/ppc/kernel/module.c. Single stepping does not take to any error or
suspicious place. Looks like it is going thru the long for() loop in the
function. Only suspicion I got is while compiling the module, it
generates tons of undefined symbols. I ignored them as it was a third
party software and module inserts correctly at the end.
Can someone give few pointers on what could be the reasons and where to
look to resolve this? Will appreciate your time,
Thanks,
Prakash
^ permalink raw reply
* RE: JTAG Flash programmer for MPC8248
From: jbahr @ 2006-09-15 20:20 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1628E43D99629C46988BE46087A3FBB96F60ED@ep-01.EmbeddedPlanet.local>
We've used the Macraigor Wiggler on an 8548 board. It's MUCH slower than the
BDI, but it does work. We've also tried their Raven and USB products (about
$750) but they didn't work or were no faster than the Wriggler.
J
Steven Blakeslee wrote:
>
>>
>> I know the BDI2000 is able to program the target flash
>> memory, but I'm looking for a less expensive solution (I
>> don't need debugging capabilities, just a plain flash programmer).
>>
>
> Macraigor is cost effective.
> http://www.macraigor.com/
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/JTAG-Flash-programmer-for-MPC8248-tf2264010.html#a6332541
Sent from the linuxppc-embedded forum at Nabble.com.
^ permalink raw reply
* Discontiguous Memory
From: jbahr @ 2006-09-15 20:22 UTC (permalink / raw)
To: linuxppc-dev
We have a client building a PPC8548-based product who insists that we
allocate DRAM real address space in two large chunks at 0-2GB and 4-6GB in
the 36-bit address space. It doesn't look like U-Boot's bd_info structure
allows for that, and it doesn't look like the Linux init routines (which
accesses the passed table) knows how to handle discontiguous memory either
(as opposed to X86 Linux, which can accept an E820 table).
It looks like Linux cleans out the TLB's pretty quickly, so it wouldn't know
the VA-to-RA mapping.
I've seen papers on some PPC Linuxes that handle large discontiguous real
DRAM memory spaces, but it doesn't look like the Linux in ELDK does. Is
that correct?
This is just the start of a headache between the architects and we poor
implementers. It's not clear to us that, even with ATMU support, how normal
drivers are going to know how to create real addresses for buffers and such
to use when programming DMA controllers or external PCI devices.
Are this really a problem or is there kernel provision for the PPC for
discontiguous real memory DRAM space?
Any comments would be VERY appreciated.
Regards,
J
--
View this message in context: http://www.nabble.com/Discontiguous-Memory-tf2279691.html#a6332580
Sent from the linuxppc-dev forum at Nabble.com.
^ permalink raw reply
* Re: ARCH=ppc or ARCH=powerpc
From: Shawn Jin @ 2006-09-15 23:06 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20060824132338.GA27468@gate.crashing.org>
Hi Matt,
> The goal is to have the new 4xx arch/powerpc support not break 4xx
> arch/ppc support. So as boards are merged and verified working,
> we'll remove the equivalent support from arch/ppc...
>
> Some boards/chips may just die if no maintainer step up to port
> them over...but all the important stuff should get an interested
> party once we get the initial 4xx support in arch/powerpc working.
When can we expect this done? I have a 440 based SoC project ongoing
and am thinking when I should start moving to arch/powerpc.
THanks,
-Shawn.
^ permalink raw reply
* Re: ARCH=ppc or ARCH=powerpc
From: Josh Boyer @ 2006-09-15 23:23 UTC (permalink / raw)
To: Shawn Jin; +Cc: Matt Porter, linuxppc-embedded
In-Reply-To: <c3d0340b0609151606i2d01b963h4c7cd6a182d8c80@mail.gmail.com>
On Fri, 2006-09-15 at 16:06 -0700, Shawn Jin wrote:
> Hi Matt,
>
> > The goal is to have the new 4xx arch/powerpc support not break 4xx
> > arch/ppc support. So as boards are merged and verified working,
> > we'll remove the equivalent support from arch/ppc...
> >
> > Some boards/chips may just die if no maintainer step up to port
> > them over...but all the important stuff should get an interested
> > party once we get the initial 4xx support in arch/powerpc working.
>
> When can we expect this done? I have a 440 based SoC project ongoing
> and am thinking when I should start moving to arch/powerpc.
There is no set date or kernel release where this will be done. In
other words "when it gets done, it gets done". :)
josh
^ permalink raw reply
* Re: Discontiguous Memory
From: Arnd Bergmann @ 2006-09-15 23:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: jbahr
In-Reply-To: <6332580.post@talk.nabble.com>
Am Friday 15 September 2006 22:22 schrieb jbahr:
> Are this really a problem or is there kernel provision for the PPC for
> discontiguous real memory DRAM space?
>
> Any comments would be VERY appreciated.
You probably want to enable the CONFIG_ARCH_SPARSEMEM_ENABLE
option, which is currently dependant on CONFIG_PPC64.
Look in the early_init_dt_scan_memory function (arch/powerpc/kernel/prom.c)
for how to layout the "memory" nodes in your device tree.
Arnd <><
^ permalink raw reply
* RE: Discontiguous Memory
From: Jeffery Bahr @ 2006-09-15 23:31 UTC (permalink / raw)
To: 'Arnd Bergmann', linuxppc-dev
In-Reply-To: <200609160124.57280.arnd@arndb.de>
Thanks, Arnd. As we're running a 32-bit 8548, looks like we might not be
able to enable sparse memory maps.
Good thought, though.
J
-----Original Message-----
From: Arnd Bergmann [mailto:arnd@arndb.de]
Sent: Friday, September 15, 2006 5:25 PM
To: linuxppc-dev@ozlabs.org
Cc: jbahr
Subject: Re: Discontiguous Memory
Am Friday 15 September 2006 22:22 schrieb jbahr:
> Are this really a problem or is there kernel provision for the PPC for
> discontiguous real memory DRAM space?
>
> Any comments would be VERY appreciated.
You probably want to enable the CONFIG_ARCH_SPARSEMEM_ENABLE option, which
is currently dependant on CONFIG_PPC64.
Look in the early_init_dt_scan_memory function (arch/powerpc/kernel/prom.c)
for how to layout the "memory" nodes in your device tree.
Arnd <><
^ permalink raw reply
* [PATCH 0/4]: PowerPC: EEH: Add support for MMIO enabled recovery step
From: Linas Vepstas @ 2006-09-15 23:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel, anton
Paul,
Please apply and submit upstream. These patches are not urgent,
and are mostly harmless.
The following set of patches add support for the MMIO-enabled
EEH recovery path, that is, for the path through te PCI error
recovery code where the device driver claims it can recover
on its own, and just wants MMIO enabled.
Actually, the first two patches are misc EEH cleanup,
the last two implement this function.
--linas
^ permalink raw reply
* [PATCH 1/4]: PowerPC: EEH: balance pcidev_get/put calls
From: Linas Vepstas @ 2006-09-15 23:55 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel, anton
In-Reply-To: <20060915235025.GQ29167@austin.ibm.com>
This patch corrects a pci_dev get/put imbalance that can occur
only in highly unlikely situations (kmalloc failures, pci devices
with overlapping resource addresses). No actual failures seen,
this was spotted during code review.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh_cache.c | 17 ++---------------
1 file changed, 2 insertions(+), 15 deletions(-)
Index: linux-2.6.18-rc7-git1/arch/powerpc/platforms/pseries/eeh_cache.c
===================================================================
--- linux-2.6.18-rc7-git1.orig/arch/powerpc/platforms/pseries/eeh_cache.c 2006-09-14 13:13:57.000000000 -0500
+++ linux-2.6.18-rc7-git1/arch/powerpc/platforms/pseries/eeh_cache.c 2006-09-14 13:52:34.000000000 -0500
@@ -157,6 +157,7 @@ pci_addr_cache_insert(struct pci_dev *de
if (!piar)
return NULL;
+ pci_dev_get(dev);
piar->addr_lo = alo;
piar->addr_hi = ahi;
piar->pcidev = dev;
@@ -178,7 +179,6 @@ static void __pci_addr_cache_insert_devi
struct device_node *dn;
struct pci_dn *pdn;
int i;
- int inserted = 0;
dn = pci_device_to_OF_node(dev);
if (!dn) {
@@ -197,9 +197,6 @@ static void __pci_addr_cache_insert_devi
return;
}
- /* The cache holds a reference to the device... */
- pci_dev_get(dev);
-
/* Walk resources on this device, poke them into the tree */
for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
unsigned long start = pci_resource_start(dev,i);
@@ -212,12 +209,7 @@ static void __pci_addr_cache_insert_devi
if (start == 0 || ~start == 0 || end == 0 || ~end == 0)
continue;
pci_addr_cache_insert(dev, start, end, flags);
- inserted = 1;
}
-
- /* If there was nothing to add, the cache has no reference... */
- if (!inserted)
- pci_dev_put(dev);
}
/**
@@ -240,7 +232,6 @@ void pci_addr_cache_insert_device(struct
static inline void __pci_addr_cache_remove_device(struct pci_dev *dev)
{
struct rb_node *n;
- int removed = 0;
restart:
n = rb_first(&pci_io_addr_cache_root.rb_root);
@@ -250,16 +241,12 @@ restart:
if (piar->pcidev == dev) {
rb_erase(n, &pci_io_addr_cache_root.rb_root);
- removed = 1;
+ pci_dev_put(piar->pcidev);
kfree(piar);
goto restart;
}
n = rb_next(n);
}
-
- /* The cache no longer holds its reference to this device... */
- if (removed)
- pci_dev_put(dev);
}
/**
^ permalink raw reply
* [PATCH 2/4]: PowerPC: EEH: code comment cleanup
From: Linas Vepstas @ 2006-09-15 23:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel, anton
In-Reply-To: <20060915235025.GQ29167@austin.ibm.com>
Clean up subroutine documentation; mostly formatting
changes, with some new content.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh.c | 19 ++++++++++++++-----
arch/powerpc/platforms/pseries/eeh_driver.c | 27 +++++++++++++++++++++------
2 files changed, 35 insertions(+), 11 deletions(-)
Index: linux-2.6.18-rc7-git1/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-2.6.18-rc7-git1.orig/arch/powerpc/platforms/pseries/eeh.c 2006-09-14 14:07:43.000000000 -0500
+++ linux-2.6.18-rc7-git1/arch/powerpc/platforms/pseries/eeh.c 2006-09-14 14:44:40.000000000 -0500
@@ -449,7 +449,11 @@ EXPORT_SYMBOL(eeh_check_failure);
/* ------------------------------------------------------------- */
/* The code below deals with error recovery */
-/** Return negative value if a permanent error, else return
+/**
+ * eeh_slot_availability - returns error status of slot
+ * @pdn pci device node
+ *
+ * Return negative value if a permanent error, else return
* a number of milliseconds to wait until the PCI slot is
* ready to be used.
*/
@@ -477,8 +481,10 @@ eeh_slot_availability(struct pci_dn *pdn
return -1;
}
-/** rtas_pci_slot_reset raises/lowers the pci #RST line
- * state: 1/0 to raise/lower the #RST
+/**
+ * rtas_pci_slot_reset - raises/lowers the pci #RST line
+ * @pdn pci device node
+ * @state: 1/0 to raise/lower the #RST
*
* Clear the EEH-frozen condition on a slot. This routine
* asserts the PCI #RST line if the 'state' argument is '1',
@@ -518,8 +524,9 @@ rtas_pci_slot_reset(struct pci_dn *pdn,
}
}
-/** rtas_set_slot_reset -- assert the pci #RST line for 1/4 second
- * dn -- device node to be reset.
+/**
+ * rtas_set_slot_reset -- assert the pci #RST line for 1/4 second
+ * @pdn: pci device node to be reset.
*
* Return 0 if success, else a non-zero value.
*/
@@ -582,6 +589,8 @@ rtas_set_slot_reset(struct pci_dn *pdn)
/**
* __restore_bars - Restore the Base Address Registers
+ * @pdn: pci device node
+ *
* Loads the PCI configuration space base address registers,
* the expansion ROM base address, the latency timer, and etc.
* from the saved values in the device node.
Index: linux-2.6.18-rc7-git1/arch/powerpc/platforms/pseries/eeh_driver.c
===================================================================
--- linux-2.6.18-rc7-git1.orig/arch/powerpc/platforms/pseries/eeh_driver.c 2006-09-14 14:34:12.000000000 -0500
+++ linux-2.6.18-rc7-git1/arch/powerpc/platforms/pseries/eeh_driver.c 2006-09-14 14:47:21.000000000 -0500
@@ -77,8 +77,12 @@ static int irq_in_use(unsigned int irq)
}
/* ------------------------------------------------------- */
-/** eeh_report_error - report an EEH error to each device,
- * collect up and merge the device responses.
+/**
+ * eeh_report_error - report pci error to each device driver
+ *
+ * Report an EEH error to each device driver, collect up and
+ * merge the device driver responses. Cumulative response
+ * passed back in "userdata".
*/
static void eeh_report_error(struct pci_dev *dev, void *userdata)
@@ -108,8 +112,8 @@ static void eeh_report_error(struct pci_
rc == PCI_ERS_RESULT_NEED_RESET) *res = rc;
}
-/** eeh_report_reset -- tell this device that the pci slot
- * has been reset.
+/**
+ * eeh_report_reset - tell device that slot has been reset
*/
static void eeh_report_reset(struct pci_dev *dev, void *userdata)
@@ -132,6 +136,10 @@ static void eeh_report_reset(struct pci_
driver->err_handler->slot_reset(dev);
}
+/**
+ * eeh_report_resume - tell device to resume normal operations
+ */
+
static void eeh_report_resume(struct pci_dev *dev, void *userdata)
{
struct pci_driver *driver = dev->driver;
@@ -148,6 +156,13 @@ static void eeh_report_resume(struct pci
driver->err_handler->resume(dev);
}
+/**
+ * eeh_report_failure - tell device driver that device is dead.
+ *
+ * This informs the device driver that the device is permanently
+ * dead, and that no further recovery attempts will be made on it.
+ */
+
static void eeh_report_failure(struct pci_dev *dev, void *userdata)
{
struct pci_driver *driver = dev->driver;
@@ -190,11 +205,11 @@ static void eeh_report_failure(struct pc
/**
* eeh_reset_device() -- perform actual reset of a pci slot
- * Args: bus: pointer to the pci bus structure corresponding
+ * @bus: pointer to the pci bus structure corresponding
* to the isolated slot. A non-null value will
* cause all devices under the bus to be removed
* and then re-added.
- * pe_dn: pointer to a "Partionable Endpoint" device node.
+ * @pe_dn: pointer to a "Partionable Endpoint" device node.
* This is the top-level structure on which pci
* bus resets can be performed.
*/
^ permalink raw reply
* [PATCH 3/4]: PowerPC: EEH: enable MMIO/DMA on frozen slot
From: Linas Vepstas @ 2006-09-15 23:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel, anton
In-Reply-To: <20060915235025.GQ29167@austin.ibm.com>
Add wrapper around the rtas call to enable MMIO or DMA
on a frozen pci slot.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh.c | 29 +++++++++++++++++++++++++++++
include/asm-powerpc/ppc-pci.h | 11 +++++++++++
2 files changed, 40 insertions(+)
Index: linux-2.6.18-rc7-git1/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-2.6.18-rc7-git1.orig/arch/powerpc/platforms/pseries/eeh.c 2006-09-14 14:44:40.000000000 -0500
+++ linux-2.6.18-rc7-git1/arch/powerpc/platforms/pseries/eeh.c 2006-09-14 15:22:23.000000000 -0500
@@ -482,6 +482,35 @@ eeh_slot_availability(struct pci_dn *pdn
}
/**
+ * rtas_pci_enable - enable MMIO or DMA transfers for this slot
+ * @pdn pci device node
+ */
+
+int
+rtas_pci_enable(struct pci_dn *pdn, int function)
+{
+ int config_addr;
+ int rc;
+
+ /* Use PE configuration address, if present */
+ config_addr = pdn->eeh_config_addr;
+ if (pdn->eeh_pe_config_addr)
+ config_addr = pdn->eeh_pe_config_addr;
+
+ rc = rtas_call(ibm_set_eeh_option, 4, 1, NULL,
+ config_addr,
+ BUID_HI(pdn->phb->buid),
+ BUID_LO(pdn->phb->buid),
+ function);
+
+ if (rc)
+ printk(KERN_WARNING "EEH: Cannot enable function %d, err=%d dn=%s\n",
+ function, rc, pdn->node->full_name);
+
+ return rc;
+}
+
+/**
* rtas_pci_slot_reset - raises/lowers the pci #RST line
* @pdn pci device node
* @state: 1/0 to raise/lower the #RST
Index: linux-2.6.18-rc7-git1/include/asm-powerpc/ppc-pci.h
===================================================================
--- linux-2.6.18-rc7-git1.orig/include/asm-powerpc/ppc-pci.h 2006-09-14 14:44:40.000000000 -0500
+++ linux-2.6.18-rc7-git1/include/asm-powerpc/ppc-pci.h 2006-09-14 15:25:14.000000000 -0500
@@ -69,6 +69,17 @@ struct pci_dev *pci_get_device_by_addr(u
void eeh_slot_error_detail (struct pci_dn *pdn, int severity);
/**
+ * rtas_pci_enableo - enable IO transfers for this slot
+ * @pdn: pci device node
+ * @function: either EEH_THAW_MMIO or EEH_THAW_DMA
+ *
+ * Enable I/O transfers to this slot
+ */
+#define EEH_THAW_MMIO 2
+#define EEH_THAW_DMA 3
+int rtas_pci_enable(struct pci_dn *pdn, int function);
+
+/**
* rtas_set_slot_reset -- unfreeze a frozen slot
*
* Clear the EEH-frozen condition on a slot. This routine
^ permalink raw reply
* [PATCH 4/4]: PowerPC: EEH: support MMIO enable recovery step
From: Linas Vepstas @ 2006-09-15 23:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel, anton
In-Reply-To: <20060915235025.GQ29167@austin.ibm.com>
Update to te PowerPC PCI error recovery code.
Add code to enable MMIO if a device driver reports
that it is capable of recovering on its own. One
anticipated use of this having a device driver
enable MMIO so that it can take a register dump,
which might then be followed by the device driver
requesting a full reset.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh_driver.c | 81 ++++++++++++++++++++++------
1 file changed, 64 insertions(+), 17 deletions(-)
Index: linux-2.6.18-rc7-git1/arch/powerpc/platforms/pseries/eeh_driver.c
===================================================================
--- linux-2.6.18-rc7-git1.orig/arch/powerpc/platforms/pseries/eeh_driver.c 2006-09-14 15:17:15.000000000 -0500
+++ linux-2.6.18-rc7-git1/arch/powerpc/platforms/pseries/eeh_driver.c 2006-09-14 17:54:15.000000000 -0500
@@ -100,14 +100,38 @@ static void eeh_report_error(struct pci_
PCI_DN(dn)->eeh_mode |= EEH_MODE_IRQ_DISABLED;
disable_irq_nosync(dev->irq);
}
- if (!driver->err_handler)
- return;
- if (!driver->err_handler->error_detected)
+ if (!driver->err_handler ||
+ !driver->err_handler->error_detected)
return;
rc = driver->err_handler->error_detected (dev, pci_channel_io_frozen);
if (*res == PCI_ERS_RESULT_NONE) *res = rc;
- if (*res == PCI_ERS_RESULT_NEED_RESET) return;
+ if (*res == PCI_ERS_RESULT_DISCONNECT &&
+ rc == PCI_ERS_RESULT_NEED_RESET) *res = rc;
+}
+
+/**
+ * eeh_report_mmio_enabled - tell drivers that MMIO has been enabled
+ *
+ * Report an EEH error to each device driver, collect up and
+ * merge the device driver responses. Cumulative response
+ * passed back in "userdata".
+ */
+
+static void eeh_report_mmio_enabled(struct pci_dev *dev, void *userdata)
+{
+ enum pci_ers_result rc, *res = userdata;
+ struct pci_driver *driver = dev->driver;
+
+ // dev->error_state = pci_channel_mmio_enabled;
+
+ if (!driver ||
+ !driver->err_handler ||
+ !driver->err_handler->mmio_enabled)
+ return;
+
+ rc = driver->err_handler->mmio_enabled (dev);
+ if (*res == PCI_ERS_RESULT_NONE) *res = rc;
if (*res == PCI_ERS_RESULT_DISCONNECT &&
rc == PCI_ERS_RESULT_NEED_RESET) *res = rc;
}
@@ -118,6 +142,7 @@ static void eeh_report_error(struct pci_
static void eeh_report_reset(struct pci_dev *dev, void *userdata)
{
+ enum pci_ers_result rc, *res = userdata;
struct pci_driver *driver = dev->driver;
struct device_node *dn = pci_device_to_OF_node(dev);
@@ -128,12 +153,14 @@ static void eeh_report_reset(struct pci_
PCI_DN(dn)->eeh_mode &= ~EEH_MODE_IRQ_DISABLED;
enable_irq(dev->irq);
}
- if (!driver->err_handler)
- return;
- if (!driver->err_handler->slot_reset)
+ if (!driver->err_handler ||
+ !driver->err_handler->slot_reset)
return;
- driver->err_handler->slot_reset(dev);
+ rc = driver->err_handler->slot_reset(dev);
+ if (*res == PCI_ERS_RESULT_NONE) *res = rc;
+ if (*res == PCI_ERS_RESULT_DISCONNECT &&
+ rc == PCI_ERS_RESULT_NEED_RESET) *res = rc;
}
/**
@@ -362,23 +389,43 @@ struct pci_dn * handle_eeh_events (struc
goto hard_fail;
}
- /* If any device called out for a reset, then reset the slot */
- if (result == PCI_ERS_RESULT_NEED_RESET) {
- rc = eeh_reset_device(frozen_pdn, NULL);
- if (rc)
- goto hard_fail;
- pci_walk_bus(frozen_bus, eeh_report_reset, NULL);
+ /* If all devices reported they can proceed, then re-enable MMIO */
+ if (result == PCI_ERS_RESULT_CAN_RECOVER) {
+ rc = rtas_pci_enable(frozen_pdn, EEH_THAW_MMIO);
+
+ if (rc) {
+ result = PCI_ERS_RESULT_NEED_RESET;
+ } else {
+ result = PCI_ERS_RESULT_NONE;
+ pci_walk_bus(frozen_bus, eeh_report_mmio_enabled, &result);
+ }
}
- /* If all devices reported they can proceed, the re-enable PIO */
+ /* If all devices reported they can proceed, then re-enable DMA */
if (result == PCI_ERS_RESULT_CAN_RECOVER) {
- /* XXX Not supported; we brute-force reset the device */
+ rc = rtas_pci_enable(frozen_pdn, EEH_THAW_DMA);
+
+ if (rc)
+ result = PCI_ERS_RESULT_NEED_RESET;
+ }
+
+ /* If any device has a hard failure, then shut off everything. */
+ if (result == PCI_ERS_RESULT_DISCONNECT)
+ goto hard_fail;
+
+ /* If any device called out for a reset, then reset the slot */
+ if (result == PCI_ERS_RESULT_NEED_RESET) {
rc = eeh_reset_device(frozen_pdn, NULL);
if (rc)
goto hard_fail;
- pci_walk_bus(frozen_bus, eeh_report_reset, NULL);
+ result = PCI_ERS_RESULT_NONE;
+ pci_walk_bus(frozen_bus, eeh_report_reset, &result);
}
+ /* All devices should claim they have recovered by now. */
+ if (result != PCI_ERS_RESULT_RECOVERED)
+ goto hard_fail;
+
/* Tell all device drivers that they can resume operations */
pci_walk_bus(frozen_bus, eeh_report_resume, NULL);
^ permalink raw reply
* Re: Discontiguous Memory
From: Benjamin Herrenschmidt @ 2006-09-16 0:56 UTC (permalink / raw)
To: jbahr; +Cc: linuxppc-dev
In-Reply-To: <6332580.post@talk.nabble.com>
On Fri, 2006-09-15 at 13:22 -0700, jbahr wrote:
> We have a client building a PPC8548-based product who insists that we
> allocate DRAM real address space in two large chunks at 0-2GB and 4-6GB in
> the 36-bit address space. It doesn't look like U-Boot's bd_info structure
> allows for that, and it doesn't look like the Linux init routines (which
> accesses the passed table) knows how to handle discontiguous memory either
> (as opposed to X86 Linux, which can accept an E820 table).
>
> It looks like Linux cleans out the TLB's pretty quickly, so it wouldn't know
> the VA-to-RA mapping.
>
> I've seen papers on some PPC Linuxes that handle large discontiguous real
> DRAM memory spaces, but it doesn't look like the Linux in ELDK does. Is
> that correct?
>
> This is just the start of a headache between the architects and we poor
> implementers. It's not clear to us that, even with ATMU support, how normal
> drivers are going to know how to create real addresses for buffers and such
> to use when programming DMA controllers or external PCI devices.
>
> Are this really a problem or is there kernel provision for the PPC for
> discontiguous real memory DRAM space?
>
> Any comments would be VERY appreciated.
There is no support for any of this in the current PowerPC 32 bits
kernel. It's possible to add it, though, but it's not alrady there.
There are two main issues:
- One is to enable support for sparse memory maps and add the necessary
support to the low mm code. Not terribly hard (see how it's done for 64
bits)
- A more annoying one is support for DMA since a lot of devices cannot
DMA above 32 bits. A lot of 'sane' platforms that provide more memory
than can be DMA'ed in 32 bits also provide an IOMMU that does page
translation of incoming DMAs. This isn't your case however, thus you
would have to implement some of the alternate solutions used on x86_64
(Intel 64 bits platforms also lack an iommu). This essentially consist
of defining a ZONE_DMA32 and possibly also using swiotlb to do bounce
buffering for drivers that don't deal with ZONE_DMA32 yet.
Ben.
^ permalink raw reply
* Re: [PATCH 1/6] bootwrapper: arch/powerpc/boot code reorg
From: Paul Mackerras @ 2006-09-16 4:01 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060915180129.GE1884@mag.az.mvista.com>
Mark A. Greer writes:
> Yes. Whether you pass the NULL or not hinges on whether its flat tree
> or not so I made it a dt_op. What are you thinking?
There's basically only two cases: if we have a builtin flat tree, we
pass that and NULL in r5; if we don't, and we have OF, we pass NULL in
r3 and the OF entry point in r5. I think that could be handled in
main.c.
We also lost the "enforce minimum address only for 64-bit" thing in
the translation, too.
I believe that just patch 1/6 on its own won't give us a working
zImage, so we'll have to split up the changes differently when it
comes time to check this stuff in to git.
Paul.
^ permalink raw reply
* Re: [PATCH 1/7] POWERPC: Add cpm2 stuff support to the fsl_soc.c
From: Stephen Rothwell @ 2006-09-16 8:20 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060915173857.7984.36024.stgit@localhost.localdomain>
Hi Vitaly,
Just a few nits ...
On Fri, 15 Sep 2006 21:38:57 +0400 Vitaly Bordug <vbordug@ru.mvista.com> wrote:
>
> +#ifdef CONFIG_CPM2
> +#include <asm/cpm2.h>
> +#endif
We normally don't do conditional includes, the include file should
protect its contents (if that is necessary - it usually isn't).
> + unsigned int *prop = (unsigned int*)get_property(node, "brg-frequency", &size);
get_property returns "const void *" so no cast is necessary, but prop
should be declated "const unsigned int *".
> + unsigned int *prop = (unsigned int*)get_property(node, "current-speed", &size);
Ditto.
> +static const char *fcc_regs = "fcc_regs";
> +static const char *fcc_regs_c = "fcc_regs_c";
> +static const char *fcc_pram = "fcc_pram";
I think that these could be declared as const char [].
> + model = (char *)get_property(np, "model", NULL);
> + mac_addr = (void *)get_property(np, "mac-address", NULL);
> + ph = (phandle *) get_property(np, "phy-handle", NULL);
> + phy_addr = (u32 *) get_property(phy, "reg", NULL);
> + id = (u32 *) get_property(np, "device-id", NULL);
Same comments about const and void * with respect to get_property. There
are more ...
> +static const char *scc_regs = "regs";
> +static const char *scc_pram = "pram";
const char [] ?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* Board Bootup and message log
From: Sachin Rane @ 2006-09-16 8:19 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <8584FDC94AFF7640B17B8A89B23B19B34F6564@sbsserver.AlphionCorp.local>
[-- Attachment #1.1: Type: text/plain, Size: 1214 bytes --]
Hi,
I want to access 'EEPROM' I2C device present on AMCC PPC440GX Evaluation bard.
I have loaded following drivers:
1. i2c-core.ko
2. i2c-dev.ko
3. eeprom.ko
4. i2c-ibm_iic.ko
The entry in the 'sysfs' got created for drivers and devices.
----------------------------------------------------------------------------------------
-bash-2.05b# cd /sys/bus/i2c/devices
-bash-2.05b# ls -la *
lrwxrwxrwx 1 root root 0 Apr 6 06:42 0-0050 -> ../../../devices/platform/i2c-0/0-0050
lrwxrwxrwx 1 root root 0 Apr 6 06:42 0-0053 -> ../../../devices/platform/i2c-0/0-0053
lrwxrwxrwx 1 root root 0 Apr 6 06:42 0-0054 -> ../../../devices/platform/i2c-0/0-0054
-bash-2.05b# cat ../../../devices/platform/i2c-0/0-0050/name
eeprom
----------------------------------------------------------------------------------------
As per the documentation (/usr/src/linux/Documentation/i2c/dev-interface),
I2C adapter files gets created under "/dev/i2c-X"are with with major device number 89.
But in my case, the device file is not getting created under '/dev/'.
Am I missing anything while loading the driver?
I have attached the board boot up and 'demsg' log file.
Thanks and Regards,
Sachin Rane
[-- Attachment #1.2: Type: text/html, Size: 2426 bytes --]
[-- Attachment #2: bootup_log_i2cDrivers.txt --]
[-- Type: text/plain, Size: 8536 bytes --]
U-Boot 1.1.4 (Aug 7 2006 - 20:36:40)
CPU: AMCC PowerPC 440GX Rev. F at 533.333 MHz (PLB=133, OPB=66, EBC=66 MHz)
I2C boot EEPROM enabled
Internal PCI arbiter enabled
32 kB I-Cache 32 kB D-Cache
Board: Ocotea - AMCC PPC440GX Evaluation Board
I2C: ready
DRAM: 256 MB
FLASH: 5 MB
PCI: Bus Dev VenId DevId Class Int
In: serial
Out: serial
Err: serial
Net: ppc_4xx_eth0, ppc_4xx_eth1, ppc_4xx_eth2, ppc_4xx_eth3
Sachin " ****************Read ReadMeInstructions: Uboot Environment Variable Configuration *************"
Hit any key to stop autoboot: 0
## Booting image at ffc00000 ...
Image Name: Linux-2.6.16.1
Created: 2006-08-02 19:51:26 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 931818 Bytes = 910 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Linux version 2.6.16.1 (root@linux) (gcc version 3.4.1 20040714 (TimeSys 3.4.1-7)) #3 Thu Aug 3 01:21:21 IST 2006
IBM Ocotea port (MontaVista Software, Inc. <source@mvista.com>)
Built 1 zonelists
Kernel command line: root=/dev/nfs rw nfsroot=192.168.0.2:/opt/timesys/linux/6.1/ppc440-std/rfs ip=192.168.0.54:192.168.0.2:192.168.0.1:255.255.255.0:ocotea:eth
0::off console=ttyS0,115200
PID hash table entries: 2048 (order: 11, 32768 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 257664k available (1420k kernel code, 460k data, 112k init, 0k highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
PPC 4xx OCP EMAC driver, version 3.54
mal0: initialized, 4 TX channels, 4 RX channels
zmii0: bridge in SMII mode
eth0: emac0, MAC 00:01:73:01:de:c8
eth0: found Generic MII PHY (0x01)
eth1: emac1, MAC 00:01:73:01:de:c9
eth1: found Generic MII PHY (0x02)
rgmii0: input 0 in RGMII mode
eth2: emac2, MAC 00:01:73:01:de:ca
eth2: found CIS8201 Gigabit Ethernet PHY (0x10)
rgmii0: input 1 in RGMII mode
eth3: emac3, MAC 00:01:73:01:de:cb
eth3: found CIS8201 Gigabit Ethernet PHY (0x18)
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 4, 65536 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
eth0: link is down
IP-Config: Complete:
device=eth0, addr=192.168.0.54, mask=255.255.255.0, gw=192.168.0.1,
host=ocotea, domain=, nis-domain=(none),
bootserver=192.168.0.2, rootserver=192.168.0.2, rootpath=
Looking up port of RPC 100003/2 on 192.168.0.2
eth0: link is up, 100 FDX, pause enabled
Looking up port of RPC 100005/1 on 192.168.0.2
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 112k init
INIT: version 2.84 booting
Welcome to Distribution built using LinuxLink by TimeSys (6.1)
mounting... ramfs at /dev
Creating initial udev device nodes:
making extra nodes
udev startup is finished!
Initializing hardware... storage network audio done[ OK ]
raidautorun: failed to open /dev/md0: 6
Configuring kernel parameters: [ OK ]
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Setting clock : Mon Apr 6 08:19:06 UTC 2015 [ OK ]
Setting hostname timesys-bsp: [ OK ]
Your system appears to have shut down uncleanly
Press Y within 1 seconds to force file system integrity check...
Remounting root filesystem in read-write mode: [ OK ]
Checking filesystems
Checking all file systems.
[ OK ]
chown: changing ownership of `/tmp/.ICE-unix': Operation not permitted
Enabling swap space: [ OK ]
INIT: Entering runlevel: 3
Entering non-interactive startup
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth0: [ OK ]
Starting system logger: [ OK ]
Starting kernel logger: [ OK ]
Starting portmap: [ OK ]
Starting NFS statd: [ OK ]
Starting xinetd: [ OK ]
Starting crond: [ OK ]
Starting atd: [ OK ]
Starting system message bus: [ OK ]
Starting the Alphion Demo App
Starting alphiondemo
************* Alphion Demo APP Started *********************
************* This is a sample Demo to start and stop apps ********
Done
Distribution built using LinuxLink by TimeSys (6.1)
Kernel 2.6.16.1 for ppc
timesys-bsp login: root
Last login: Mon Apr 6 06:33:48 on ttyS0
-bash-2.05b# lsmod
Module Size Used by
-bash-2.05b# **************************************After L Alphion Wake after a minute .....
-bash: ********************: command not found
-bash-2.05b#
-bash-2.05b#
-bash-2.05b# ps -ax | grep alphion
Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html
352 ? S 0:00 /home/AlphionApps//alphiondemo
383 ttyS0 R+ 0:00 grep alphion
-bash-2.05b# kill -9 352
-bash-2.05b# ************************************* output of lsmod *************
-bash: *************************************: command not found
-bash-2.05b# ************************************* output of lsmod *************
-bash-2.05b#
-bash-2.05b#
-bash-2.05b# lsmod
Module Size Used by
-bash-2.05b#
-bash-2.05b#
-bash-2.05b#
-bash-2.05b#
-bash-2.05b#
-bash-2.05b# *************Inserting the Modules *************
-bash: *************Inserting: command not found
-bash-2.05b#
-bash-2.05b# insmod i2c-dev.ko
insmod: can't read 'i2c-dev.ko': No such file or directory
-bash-2.05b# cd /lib/modules/2.6.16.1/kernel/drivers/i2c/
-bash-2.05b# insmod i2c-dev.ko
i2c_dev: Unknown symbol i2c_check_addr
i2c_dev: Unknown symbol i2c_get_adapter
i2c_dev: Unknown symbol i2c_control
i2c_dev: Unknown symbol i2c_master_recv
i2c_dev: Unknown symbol i2c_smbus_xfer
i2c_dev: Unknown symbol i2c_register_driver
i2c_dev: Unknown symbol i2c_put_adapter
i2c_dev: Unknown symbol i2c_transfer
i2c_dev: Unknown symbol i2c_del_driver
i2c_dev: Unknown symbol i2c_master_send
insmod: error inserting 'i2c-dev.ko': -1 Unknown symbol in module
-bash-2.05b# insmod i2c-core.ko
-bash-2.05b# lsmod
Module Size Used by
i2c_core 22384 0
-bash-2.05b# insmod i2c-dev.ko
-bash-2.05b# lsmod
Module Size Used by
i2c_dev 10116 0
i2c_core 22384 1 i2c_dev
-bash-2.05b# ls
algos busses chips i2c-core.ko i2c-dev.ko
-bash-2.05b# cd chips/
-bash-2.05b# insmod
insmod insmod.static insmod_ksymoops_clean
-bash-2.05b# insmod eeprom.ko
-bash-2.05b# lsmod
Module Size Used by
eeprom 6736 0
i2c_dev 10116 0
i2c_core 22384 2 eeprom,i2c_dev
-bash-2.05b# ls
ds1337.ko eeprom.ko max6875.ko pcf8574.ko rtc8564.ko
ds1374.ko m41t00.ko pca9539.ko pcf8591.ko x1205.ko
-bash-2.05b# cd ..
-bash-2.05b# ls
algos busses chips i2c-core.ko i2c-dev.ko
-bash-2.05b# cd busses/
-bash-2.05b# ls
i2c-ali1535.ko i2c-i801.ko i2c-pca-isa.ko i2c-sis96x.ko
i2c-ali1563.ko i2c-i810.ko i2c-piix4.ko i2c-stub.ko
i2c-ali15x3.ko i2c-ibm_iic.ko i2c-prosavage.ko i2c-via.ko
i2c-amd756-s4882.ko i2c-mpc.ko i2c-savage4.ko i2c-viapro.ko
i2c-amd756.ko i2c-nforce2.ko i2c-sis5595.ko i2c-voodoo3.ko
i2c-amd8111.ko i2c-parport-light.ko i2c-sis630.ko scx200_acb.ko
-bash-2.05b# insmod 2c-ibm_iic.ko
insmod: can't read '2c-ibm_iic.ko': No such file or directory
-bash-2.05b# insmod i2c-ibm_iic.ko
-bash-2.05b# lsmod
Module Size Used by
i2c_ibm_iic 7432 0
eeprom 6736 0
i2c_dev 10116 0
i2c_core 22384 3 i2c_ibm_iic,eeprom,i2c_dev
[-- Attachment #3: dmesg_log_i2cDrivers.txt --]
[-- Type: text/plain, Size: 5791 bytes --]
-bash-2.05b# dmesg
Linux version 2.6.16.1 (root@linux) (gcc version 3.4.1 20040714 (TimeSys 3.4.1-7)) #3 Thu Aug 3 01:21:21 IST 2006
IBM Ocotea port (MontaVista Software, Inc. <source@mvista.com>)
On node 0 totalpages: 65536
DMA zone: 65536 pages, LIFO batch:15
DMA32 zone: 0 pages, LIFO batch:0
Normal zone: 0 pages, LIFO batch:0
HighMem zone: 0 pages, LIFO batch:0
Built 1 zonelists
Kernel command line: root=/dev/nfs rw nfsroot=192.168.0.2:/opt/timesys/linux/6.1/ppc440-std/rfs ip=192.168.0.54:192.168.0.2:192.168.0.1:255.255.255.0:ocotea:eth
0::off console=ttyS0,115200
PID hash table entries: 2048 (order: 11, 32768 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 257664k available (1420k kernel code, 460k data, 112k init, 0k highmem)
Calibrating delay loop... 798.72 BogoMIPS (lpj=1597440)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
PPC 4xx OCP EMAC driver, version 3.54
mal0: initialized, 4 TX channels, 4 RX channels
zmii0: bridge in SMII mode
eth0: emac0, MAC 00:01:73:01:de:c8
eth0: found Generic MII PHY (0x01)
eth1: emac1, MAC 00:01:73:01:de:c9
eth1: found Generic MII PHY (0x02)
rgmii0: input 0 in RGMII mode
eth2: emac2, MAC 00:01:73:01:de:ca
eth2: found CIS8201 Gigabit Ethernet PHY (0x10)
rgmii0: input 1 in RGMII mode
eth3: emac3, MAC 00:01:73:01:de:cb
eth3: found CIS8201 Gigabit Ethernet PHY (0x18)
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 4, 65536 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
eth0: link is down
IP-Config: Complete:
device=eth0, addr=192.168.0.54, mask=255.255.255.0, gw=192.168.0.1,
host=ocotea, domain=, nis-domain=(none),
bootserver=192.168.0.2, rootserver=192.168.0.2, rootpath=
Looking up port of RPC 100003/2 on 192.168.0.2
eth0: link is up, 100 FDX, pause enabled
Looking up port of RPC 100005/1 on 192.168.0.2
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 112k init
i2c_dev: Unknown symbol i2c_check_addr
i2c_dev: Unknown symbol i2c_get_adapter
i2c_dev: Unknown symbol i2c_control
i2c_dev: Unknown symbol i2c_master_recv
i2c_dev: Unknown symbol i2c_smbus_xfer
i2c_dev: Unknown symbol i2c_register_driver
i2c_dev: Unknown symbol i2c_put_adapter
i2c_dev: Unknown symbol i2c_transfer
i2c_dev: Unknown symbol i2c_del_driver
i2c_dev: Unknown symbol i2c_master_send
i2c /dev entries driver
i2c-core: driver [dev_driver] registered
i2c-core: driver [eeprom] registered
IBM IIC driver v2.1
i2c_adapter i2c-0: adapter [IBM IIC] registered
i2c-dev: adapter [IBM IIC] registered as minor 0
i2c_adapter i2c-0: found normal entry for adapter 0, addr 0x50
i2c_adapter i2c-0: master_xfer[0] W, addr=0x50, len=0
i2c_adapter i2c-0: master_xfer[0] W, addr=0x50, len=0
i2c_adapter i2c-0: client [eeprom] registered with bus id 0-0050
i2c_adapter i2c-0: found normal entry for adapter 0, addr 0x51
i2c_adapter i2c-0: master_xfer[0] W, addr=0x51, len=0
i2c_adapter i2c-0: found normal entry for adapter 0, addr 0x52
i2c_adapter i2c-0: master_xfer[0] W, addr=0x52, len=0
i2c_adapter i2c-0: found normal entry for adapter 0, addr 0x53
i2c_adapter i2c-0: master_xfer[0] W, addr=0x53, len=0
i2c_adapter i2c-0: master_xfer[0] W, addr=0x53, len=0
i2c_adapter i2c-0: client [eeprom] registered with bus id 0-0053
i2c_adapter i2c-0: found normal entry for adapter 0, addr 0x54
i2c_adapter i2c-0: master_xfer[0] W, addr=0x54, len=0
i2c_adapter i2c-0: master_xfer[0] W, addr=0x54, len=0
i2c_adapter i2c-0: client [eeprom] registered with bus id 0-0054
i2c_adapter i2c-0: found normal entry for adapter 0, addr 0x55
i2c_adapter i2c-0: master_xfer[0] W, addr=0x55, len=0
i2c_adapter i2c-0: found normal entry for adapter 0, addr 0x56
i2c_adapter i2c-0: master_xfer[0] W, addr=0x56, len=0
i2c_adapter i2c-0: found normal entry for adapter 0, addr 0x57
i2c_adapter i2c-0: master_xfer[0] W, addr=0x57, len=0
ibm-iic0: using standard (100 kHz) mode
i2c_adapter i2c-1: adapter [IBM IIC] registered
i2c-dev: adapter [IBM IIC] registered as minor 1
i2c_adapter i2c-1: found normal entry for adapter 1, addr 0x50
i2c_adapter i2c-1: master_xfer[0] W, addr=0x50, len=0
i2c_adapter i2c-1: found normal entry for adapter 1, addr 0x51
i2c_adapter i2c-1: master_xfer[0] W, addr=0x51, len=0
i2c_adapter i2c-1: found normal entry for adapter 1, addr 0x52
i2c_adapter i2c-1: master_xfer[0] W, addr=0x52, len=0
i2c_adapter i2c-1: found normal entry for adapter 1, addr 0x53
i2c_adapter i2c-1: master_xfer[0] W, addr=0x53, len=0
i2c_adapter i2c-1: found normal entry for adapter 1, addr 0x54
i2c_adapter i2c-1: master_xfer[0] W, addr=0x54, len=0
i2c_adapter i2c-1: found normal entry for adapter 1, addr 0x55
i2c_adapter i2c-1: master_xfer[0] W, addr=0x55, len=0
i2c_adapter i2c-1: found normal entry for adapter 1, addr 0x56
i2c_adapter i2c-1: master_xfer[0] W, addr=0x56, len=0
i2c_adapter i2c-1: found normal entry for adapter 1, addr 0x57
i2c_adapter i2c-1: master_xfer[0] W, addr=0x57, len=0
ibm-iic1: using standard (100 kHz) mode
^ permalink raw reply
* I2C adapter device file problem
From: Sachin Rane @ 2006-09-16 8:29 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <8584FDC94AFF7640B17B8A89B23B19B34F6569@sbsserver.AlphionCorp.local>
[-- Attachment #1.1: Type: text/plain, Size: 1219 bytes --]
Hi,
I want to access 'EEPROM' I2C device present on AMCC PPC440GX Evaluation bard.
I have loaded following drivers:
1. i2c-core.ko
2. i2c-dev.ko
3. eeprom.ko
4. i2c-ibm_iic.ko
The entry in the 'sysfs' got created for drivers and devices.
----------------------------------------------------------------------------------------
-bash-2.05b# cd /sys/bus/i2c/devices
-bash-2.05b# ls -la *
lrwxrwxrwx 1 root root 0 Apr 6 06:42 0-0050 -> ../../../devices/platform/i2c-0/0-0050
lrwxrwxrwx 1 root root 0 Apr 6 06:42 0-0053 -> ../../../devices/platform/i2c-0/0-0053
lrwxrwxrwx 1 root root 0 Apr 6 06:42 0-0054 -> ../../../devices/platform/i2c-0/0-0054
-bash-2.05b# cat ../../../devices/platform/i2c-0/0-0050/name
eeprom
----------------------------------------------------------------------------------------
As per the documentation (/usr/src/linux/Documentation/i2c/dev-interface),
I2C adapter files gets created under "/dev/i2c-X"are with with major device number 89.
But in my case, the device file is not getting created under '/dev/'.
Am I missing anything while loading the driver?
I have attached the board boot up and 'demsg' log file.
Thanks and Regards,
Sachin Rane
[-- Attachment #1.2: Type: text/html, Size: 2671 bytes --]
[-- Attachment #2: bootup_log_i2cDrivers.txt --]
[-- Type: text/plain, Size: 8536 bytes --]
U-Boot 1.1.4 (Aug 7 2006 - 20:36:40)
CPU: AMCC PowerPC 440GX Rev. F at 533.333 MHz (PLB=133, OPB=66, EBC=66 MHz)
I2C boot EEPROM enabled
Internal PCI arbiter enabled
32 kB I-Cache 32 kB D-Cache
Board: Ocotea - AMCC PPC440GX Evaluation Board
I2C: ready
DRAM: 256 MB
FLASH: 5 MB
PCI: Bus Dev VenId DevId Class Int
In: serial
Out: serial
Err: serial
Net: ppc_4xx_eth0, ppc_4xx_eth1, ppc_4xx_eth2, ppc_4xx_eth3
Sachin " ****************Read ReadMeInstructions: Uboot Environment Variable Configuration *************"
Hit any key to stop autoboot: 0
## Booting image at ffc00000 ...
Image Name: Linux-2.6.16.1
Created: 2006-08-02 19:51:26 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 931818 Bytes = 910 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Linux version 2.6.16.1 (root@linux) (gcc version 3.4.1 20040714 (TimeSys 3.4.1-7)) #3 Thu Aug 3 01:21:21 IST 2006
IBM Ocotea port (MontaVista Software, Inc. <source@mvista.com>)
Built 1 zonelists
Kernel command line: root=/dev/nfs rw nfsroot=192.168.0.2:/opt/timesys/linux/6.1/ppc440-std/rfs ip=192.168.0.54:192.168.0.2:192.168.0.1:255.255.255.0:ocotea:eth
0::off console=ttyS0,115200
PID hash table entries: 2048 (order: 11, 32768 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 257664k available (1420k kernel code, 460k data, 112k init, 0k highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
PPC 4xx OCP EMAC driver, version 3.54
mal0: initialized, 4 TX channels, 4 RX channels
zmii0: bridge in SMII mode
eth0: emac0, MAC 00:01:73:01:de:c8
eth0: found Generic MII PHY (0x01)
eth1: emac1, MAC 00:01:73:01:de:c9
eth1: found Generic MII PHY (0x02)
rgmii0: input 0 in RGMII mode
eth2: emac2, MAC 00:01:73:01:de:ca
eth2: found CIS8201 Gigabit Ethernet PHY (0x10)
rgmii0: input 1 in RGMII mode
eth3: emac3, MAC 00:01:73:01:de:cb
eth3: found CIS8201 Gigabit Ethernet PHY (0x18)
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 4, 65536 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
eth0: link is down
IP-Config: Complete:
device=eth0, addr=192.168.0.54, mask=255.255.255.0, gw=192.168.0.1,
host=ocotea, domain=, nis-domain=(none),
bootserver=192.168.0.2, rootserver=192.168.0.2, rootpath=
Looking up port of RPC 100003/2 on 192.168.0.2
eth0: link is up, 100 FDX, pause enabled
Looking up port of RPC 100005/1 on 192.168.0.2
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 112k init
INIT: version 2.84 booting
Welcome to Distribution built using LinuxLink by TimeSys (6.1)
mounting... ramfs at /dev
Creating initial udev device nodes:
making extra nodes
udev startup is finished!
Initializing hardware... storage network audio done[ OK ]
raidautorun: failed to open /dev/md0: 6
Configuring kernel parameters: [ OK ]
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Setting clock : Mon Apr 6 08:19:06 UTC 2015 [ OK ]
Setting hostname timesys-bsp: [ OK ]
Your system appears to have shut down uncleanly
Press Y within 1 seconds to force file system integrity check...
Remounting root filesystem in read-write mode: [ OK ]
Checking filesystems
Checking all file systems.
[ OK ]
chown: changing ownership of `/tmp/.ICE-unix': Operation not permitted
Enabling swap space: [ OK ]
INIT: Entering runlevel: 3
Entering non-interactive startup
Setting network parameters: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth0: [ OK ]
Starting system logger: [ OK ]
Starting kernel logger: [ OK ]
Starting portmap: [ OK ]
Starting NFS statd: [ OK ]
Starting xinetd: [ OK ]
Starting crond: [ OK ]
Starting atd: [ OK ]
Starting system message bus: [ OK ]
Starting the Alphion Demo App
Starting alphiondemo
************* Alphion Demo APP Started *********************
************* This is a sample Demo to start and stop apps ********
Done
Distribution built using LinuxLink by TimeSys (6.1)
Kernel 2.6.16.1 for ppc
timesys-bsp login: root
Last login: Mon Apr 6 06:33:48 on ttyS0
-bash-2.05b# lsmod
Module Size Used by
-bash-2.05b# **************************************After L Alphion Wake after a minute .....
-bash: ********************: command not found
-bash-2.05b#
-bash-2.05b#
-bash-2.05b# ps -ax | grep alphion
Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html
352 ? S 0:00 /home/AlphionApps//alphiondemo
383 ttyS0 R+ 0:00 grep alphion
-bash-2.05b# kill -9 352
-bash-2.05b# ************************************* output of lsmod *************
-bash: *************************************: command not found
-bash-2.05b# ************************************* output of lsmod *************
-bash-2.05b#
-bash-2.05b#
-bash-2.05b# lsmod
Module Size Used by
-bash-2.05b#
-bash-2.05b#
-bash-2.05b#
-bash-2.05b#
-bash-2.05b#
-bash-2.05b# *************Inserting the Modules *************
-bash: *************Inserting: command not found
-bash-2.05b#
-bash-2.05b# insmod i2c-dev.ko
insmod: can't read 'i2c-dev.ko': No such file or directory
-bash-2.05b# cd /lib/modules/2.6.16.1/kernel/drivers/i2c/
-bash-2.05b# insmod i2c-dev.ko
i2c_dev: Unknown symbol i2c_check_addr
i2c_dev: Unknown symbol i2c_get_adapter
i2c_dev: Unknown symbol i2c_control
i2c_dev: Unknown symbol i2c_master_recv
i2c_dev: Unknown symbol i2c_smbus_xfer
i2c_dev: Unknown symbol i2c_register_driver
i2c_dev: Unknown symbol i2c_put_adapter
i2c_dev: Unknown symbol i2c_transfer
i2c_dev: Unknown symbol i2c_del_driver
i2c_dev: Unknown symbol i2c_master_send
insmod: error inserting 'i2c-dev.ko': -1 Unknown symbol in module
-bash-2.05b# insmod i2c-core.ko
-bash-2.05b# lsmod
Module Size Used by
i2c_core 22384 0
-bash-2.05b# insmod i2c-dev.ko
-bash-2.05b# lsmod
Module Size Used by
i2c_dev 10116 0
i2c_core 22384 1 i2c_dev
-bash-2.05b# ls
algos busses chips i2c-core.ko i2c-dev.ko
-bash-2.05b# cd chips/
-bash-2.05b# insmod
insmod insmod.static insmod_ksymoops_clean
-bash-2.05b# insmod eeprom.ko
-bash-2.05b# lsmod
Module Size Used by
eeprom 6736 0
i2c_dev 10116 0
i2c_core 22384 2 eeprom,i2c_dev
-bash-2.05b# ls
ds1337.ko eeprom.ko max6875.ko pcf8574.ko rtc8564.ko
ds1374.ko m41t00.ko pca9539.ko pcf8591.ko x1205.ko
-bash-2.05b# cd ..
-bash-2.05b# ls
algos busses chips i2c-core.ko i2c-dev.ko
-bash-2.05b# cd busses/
-bash-2.05b# ls
i2c-ali1535.ko i2c-i801.ko i2c-pca-isa.ko i2c-sis96x.ko
i2c-ali1563.ko i2c-i810.ko i2c-piix4.ko i2c-stub.ko
i2c-ali15x3.ko i2c-ibm_iic.ko i2c-prosavage.ko i2c-via.ko
i2c-amd756-s4882.ko i2c-mpc.ko i2c-savage4.ko i2c-viapro.ko
i2c-amd756.ko i2c-nforce2.ko i2c-sis5595.ko i2c-voodoo3.ko
i2c-amd8111.ko i2c-parport-light.ko i2c-sis630.ko scx200_acb.ko
-bash-2.05b# insmod 2c-ibm_iic.ko
insmod: can't read '2c-ibm_iic.ko': No such file or directory
-bash-2.05b# insmod i2c-ibm_iic.ko
-bash-2.05b# lsmod
Module Size Used by
i2c_ibm_iic 7432 0
eeprom 6736 0
i2c_dev 10116 0
i2c_core 22384 3 i2c_ibm_iic,eeprom,i2c_dev
[-- Attachment #3: dmesg_log_i2cDrivers.txt --]
[-- Type: text/plain, Size: 5791 bytes --]
-bash-2.05b# dmesg
Linux version 2.6.16.1 (root@linux) (gcc version 3.4.1 20040714 (TimeSys 3.4.1-7)) #3 Thu Aug 3 01:21:21 IST 2006
IBM Ocotea port (MontaVista Software, Inc. <source@mvista.com>)
On node 0 totalpages: 65536
DMA zone: 65536 pages, LIFO batch:15
DMA32 zone: 0 pages, LIFO batch:0
Normal zone: 0 pages, LIFO batch:0
HighMem zone: 0 pages, LIFO batch:0
Built 1 zonelists
Kernel command line: root=/dev/nfs rw nfsroot=192.168.0.2:/opt/timesys/linux/6.1/ppc440-std/rfs ip=192.168.0.54:192.168.0.2:192.168.0.1:255.255.255.0:ocotea:eth
0::off console=ttyS0,115200
PID hash table entries: 2048 (order: 11, 32768 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 257664k available (1420k kernel code, 460k data, 112k init, 0k highmem)
Calibrating delay loop... 798.72 BogoMIPS (lpj=1597440)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
PPC 4xx OCP EMAC driver, version 3.54
mal0: initialized, 4 TX channels, 4 RX channels
zmii0: bridge in SMII mode
eth0: emac0, MAC 00:01:73:01:de:c8
eth0: found Generic MII PHY (0x01)
eth1: emac1, MAC 00:01:73:01:de:c9
eth1: found Generic MII PHY (0x02)
rgmii0: input 0 in RGMII mode
eth2: emac2, MAC 00:01:73:01:de:ca
eth2: found CIS8201 Gigabit Ethernet PHY (0x10)
rgmii0: input 1 in RGMII mode
eth3: emac3, MAC 00:01:73:01:de:cb
eth3: found CIS8201 Gigabit Ethernet PHY (0x18)
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 4, 65536 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
eth0: link is down
IP-Config: Complete:
device=eth0, addr=192.168.0.54, mask=255.255.255.0, gw=192.168.0.1,
host=ocotea, domain=, nis-domain=(none),
bootserver=192.168.0.2, rootserver=192.168.0.2, rootpath=
Looking up port of RPC 100003/2 on 192.168.0.2
eth0: link is up, 100 FDX, pause enabled
Looking up port of RPC 100005/1 on 192.168.0.2
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 112k init
i2c_dev: Unknown symbol i2c_check_addr
i2c_dev: Unknown symbol i2c_get_adapter
i2c_dev: Unknown symbol i2c_control
i2c_dev: Unknown symbol i2c_master_recv
i2c_dev: Unknown symbol i2c_smbus_xfer
i2c_dev: Unknown symbol i2c_register_driver
i2c_dev: Unknown symbol i2c_put_adapter
i2c_dev: Unknown symbol i2c_transfer
i2c_dev: Unknown symbol i2c_del_driver
i2c_dev: Unknown symbol i2c_master_send
i2c /dev entries driver
i2c-core: driver [dev_driver] registered
i2c-core: driver [eeprom] registered
IBM IIC driver v2.1
i2c_adapter i2c-0: adapter [IBM IIC] registered
i2c-dev: adapter [IBM IIC] registered as minor 0
i2c_adapter i2c-0: found normal entry for adapter 0, addr 0x50
i2c_adapter i2c-0: master_xfer[0] W, addr=0x50, len=0
i2c_adapter i2c-0: master_xfer[0] W, addr=0x50, len=0
i2c_adapter i2c-0: client [eeprom] registered with bus id 0-0050
i2c_adapter i2c-0: found normal entry for adapter 0, addr 0x51
i2c_adapter i2c-0: master_xfer[0] W, addr=0x51, len=0
i2c_adapter i2c-0: found normal entry for adapter 0, addr 0x52
i2c_adapter i2c-0: master_xfer[0] W, addr=0x52, len=0
i2c_adapter i2c-0: found normal entry for adapter 0, addr 0x53
i2c_adapter i2c-0: master_xfer[0] W, addr=0x53, len=0
i2c_adapter i2c-0: master_xfer[0] W, addr=0x53, len=0
i2c_adapter i2c-0: client [eeprom] registered with bus id 0-0053
i2c_adapter i2c-0: found normal entry for adapter 0, addr 0x54
i2c_adapter i2c-0: master_xfer[0] W, addr=0x54, len=0
i2c_adapter i2c-0: master_xfer[0] W, addr=0x54, len=0
i2c_adapter i2c-0: client [eeprom] registered with bus id 0-0054
i2c_adapter i2c-0: found normal entry for adapter 0, addr 0x55
i2c_adapter i2c-0: master_xfer[0] W, addr=0x55, len=0
i2c_adapter i2c-0: found normal entry for adapter 0, addr 0x56
i2c_adapter i2c-0: master_xfer[0] W, addr=0x56, len=0
i2c_adapter i2c-0: found normal entry for adapter 0, addr 0x57
i2c_adapter i2c-0: master_xfer[0] W, addr=0x57, len=0
ibm-iic0: using standard (100 kHz) mode
i2c_adapter i2c-1: adapter [IBM IIC] registered
i2c-dev: adapter [IBM IIC] registered as minor 1
i2c_adapter i2c-1: found normal entry for adapter 1, addr 0x50
i2c_adapter i2c-1: master_xfer[0] W, addr=0x50, len=0
i2c_adapter i2c-1: found normal entry for adapter 1, addr 0x51
i2c_adapter i2c-1: master_xfer[0] W, addr=0x51, len=0
i2c_adapter i2c-1: found normal entry for adapter 1, addr 0x52
i2c_adapter i2c-1: master_xfer[0] W, addr=0x52, len=0
i2c_adapter i2c-1: found normal entry for adapter 1, addr 0x53
i2c_adapter i2c-1: master_xfer[0] W, addr=0x53, len=0
i2c_adapter i2c-1: found normal entry for adapter 1, addr 0x54
i2c_adapter i2c-1: master_xfer[0] W, addr=0x54, len=0
i2c_adapter i2c-1: found normal entry for adapter 1, addr 0x55
i2c_adapter i2c-1: master_xfer[0] W, addr=0x55, len=0
i2c_adapter i2c-1: found normal entry for adapter 1, addr 0x56
i2c_adapter i2c-1: master_xfer[0] W, addr=0x56, len=0
i2c_adapter i2c-1: found normal entry for adapter 1, addr 0x57
i2c_adapter i2c-1: master_xfer[0] W, addr=0x57, len=0
ibm-iic1: using standard (100 kHz) mode
^ permalink raw reply
* Re: [PATCH 3/7] POWERPC: Move generic cpm2 stuff to powerpc
From: Stephen Rothwell @ 2006-09-16 8:36 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060915173912.7984.40164.stgit@localhost.localdomain>
Hi Vitaly,
Seems I am in nit picking mood tonight ..
On Fri, 15 Sep 2006 21:39:12 +0400 Vitaly Bordug <vbordug@ru.mvista.com> wrote:
>
> +# Temporary hack until we have migrated to asm-powerpc
> +ifeq ($(ARCH),powerpc)
I think we normally use:
ifeq ($(CONFIG_PPC_MERGE),y)
> + if (brg < 4) {
> + bp = (uint *)&cpm2_immr->im_brgc1;
> + }
> + else {
Normally:
if (brg < 4)
bp = (uint *)&cpm2_immr->im_brgc1;
else {
> +static u_char irq_to_siureg[] = {
const ?
> +static u_char irq_to_siubit[] = {
ditto
> +int cpm2_get_irq(struct pt_regs *regs)
> +{
> + int irq;
> + unsigned long bits;
> +
> + /* For CPM2, read the SIVEC register and shift the bits down
> + * to get the irq number. */
> + bits = cpm2_immr->im_intctl.ic_sivec;
> + irq = bits >> 26;
> +
> + if (irq == 0)
> + return(-1);
> + return irq+CPM_IRQ_OFFSET;
> +}
Indentation needs fixing - we use single tab characters to indent.
> +static int cpm2_pic_host_xlate(struct irq_host *h, struct device_node *ct,
> + u32 *intspec, unsigned int intsize,
> + irq_hw_number_t *out_hwirq, unsigned int *out_flags)
> +{
> + static unsigned char map_cpm2_senses[4] = {
const ?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* Re: Discontiguous Memory
From: Arnd Bergmann @ 2006-09-16 9:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: jbahr
In-Reply-To: <1158368179.14473.203.camel@localhost.localdomain>
Am Saturday 16 September 2006 02:56 schrieb Benjamin Herrenschmidt:
> =A0- A more annoying one is support for DMA since a lot of devices cannot
> DMA above 32 bits. A lot of 'sane' platforms that provide more memory
> than can be DMA'ed in 32 bits also provide an IOMMU that does page
> translation of incoming DMAs. This isn't your case however, thus you
> would have to implement some of the alternate solutions used on x86_64
> (Intel 64 bits platforms also lack an iommu). This essentially consist
> of defining a ZONE_DMA32 and possibly also using swiotlb to do bounce
> buffering for drivers that don't deal with ZONE_DMA32 yet.
On 32 bit platforms, you normally have ZONE_NORMAL for up to 4G and
ZONE_HIGHMEM beyond, so you don't need an extra ZONE_DMA32.
Arnd <><
^ permalink raw reply
* Re: [Alsa-devel] oops in snd-powermac due to snd-aoa
From: Olaf Hering @ 2006-09-16 9:56 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <s5h64fzltyg.wl%tiwai@suse.de>
On Thu, Sep 07, Takashi Iwai wrote:
> At Thu, 7 Sep 2006 14:42:56 +0200,
> Olaf Hering wrote:
> >
> > I was playing with snd-aoa, maybe the driver would work on a G4/466.
> > mv /lib/modules/*/kernel/sound/ppc/snd-powermac.ko .
> > reboot
> > $insmod /lib/modules/*/kernel/sound/aoa/*/*.ko
> > alsamixer finds nothing.
> > mv snd-powermac.ko /lib/modules/*/kernel/sound/ppc/
> > $insmod snd-powermac.ko -> oops
> >
> > Using PowerMac machine description
> (snip)
> > ALSA sound/ppc/keywest.c:82: tumbler: cannot attach i2c client
> > read_audio_gpio addr 67 ret 2 av 4
> > headphone: 0, lineout: 0
> > check_audio_gpio addr 70 ret 4 av 4
> > check_audio_gpio addr 6f ret 7 av 4
> > Unable to handle kernel paging request for data at address 0x00000002
>
> Does the patch below work?
Yes, no oops, but also no sound without reboot. Thats ok.
...
ALSA sound/ppc/keywest.c:82: tumbler: cannot attach i2c client
read_audio_gpio addr 67 ret 2 av 4
headphone: 0, lineout: 0
check_audio_gpio addr 70 ret 4 av 4
check_audio_gpio addr 6f ret 7 av 4
date:~ #
date:~ # alsamixer
alsamixer: function snd_ctl_open failed for default: No such device
...
^ 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