* Re: [PATCH] Support 440EP On-Chip OHCI USB Host Controller (v2)
From: Eugene Surovegin @ 2005-08-09 16:30 UTC (permalink / raw)
To: John Otken; +Cc: roffermanns, linuxppc-embedded
In-Reply-To: <42F89B89.2050000@softadvances.com>
On Tue, Aug 09, 2005 at 07:03:21AM -0500, John Otken wrote:
> This updated patch adds support for the AMCC 440EP on-chip
> OHCI USB host controller. I tested it on the Bamboo board
> using the 2.6.13-rc6 kernel.
>
> @@ -194,8 +194,37 @@ static struct resource usb_gadget_resour
> },
> };
>
> +static struct resource ohci_usb_resources[] = {
> + [0] = {
> + .start = 0x0EF601000,
> + .end = 0x0EF60107F,
> + .flags = IORESOURCE_MEM,
> + },
> + [1] = {
> + .start = 40,
> + .end = 40,
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> static u64 dma_mask = 0xffffffffULL;
>
> +#include <asm/usb.h>
Let's place #include directives at the top of the source file.
--
Eugene
^ permalink raw reply
* Re: [linuxppc] 2.6.12-3 header <asm/usb.h> missing ?
From: Eugene Surovegin @ 2005-08-09 16:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: thomas, linuxppc-embedded list
In-Reply-To: <A9E0A66D-CE6F-4A55-80FD-5D9E57BB6035@freescale.com>
On Tue, Aug 09, 2005 at 09:50:50AM -0500, Kumar Gala wrote:
> Why are we bothering with asm-ppc/usb.h anyways?
>
> The structure defn only appears to be used once. If this is true,
> why not just define it in the .c file.
>
Yeah, I think we should stop that unneeded creation of include files
which are used only once.
For some strange reason people like doing this, I wonder why. Maybe
they were taught this "style" in their CS classes :)?
--
Eugene
^ permalink raw reply
* Re: Merging ppc32 and ppc64
From: Tom Rini @ 2005-08-09 16:21 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc64-dev, Geert Uytterhoeven, Arnd Bergmann,
Linux/PPC Development
In-Reply-To: <80BD2461-35F1-4B9D-983E-E2BCFFC08C77@freescale.com>
On Tue, Aug 09, 2005 at 10:01:05AM -0500, Kumar Gala wrote:
> >I think you are both right, just using different terminology. The
> >running kernel uses its own representation of the device tree, which
> >is neither the flattened stuff nor using the OF interfaces. The
> >conversion from OF to the flattened tree is done by the kernel itself.
> >
> > Apple OF \
> > SLOF \
> > pSeries |-1- prom_init------,
> > PIBS / \
> > ... / \
> > \
> > other -----------------------------2--
> >unflatten_device_tree--3--
> > boot loader /
> > /
> > iSeries ----------- early_setup---`
> >
> >All "regular" machines enter in the traditional prom_init path (1)
> >from Open Firmware. The embedded machines that are too memory
> >constraint
> >to use SLOF have a flattened device tree in their boot loader and the
> >legacy iSeries boxes can fake the device tree in their
> >iSeries_early_setup
> >function. The main entry point (2) is entered by all machines when the
> >flattened device tree is there and the kernel builds its tree
> >representation
> >for run time (3).
>
> I guess my point is that in the "new" powerpc arch doing steps 1 & 3
> should no longer be part of the kernel proper. The should be handled
> by boot wrappers of some form. I know Ben tool care to ensure that
> prom_init was isolated from kernel proper and I'm suggesting we move
> it into a boot wrapper going forward.
That's not 100% true because as Segher said, prom_init.c is part of the
kernel (tree, image), but is what does the translation.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: Volunteers to test i2c-algo-8xx on v2.6?
From: Tom Rini @ 2005-08-09 16:18 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho; +Cc: Joakim Tjernlund, linuxppc-embedded
In-Reply-To: <20050808130523.GF5210@cathedrallabs.org>
On Mon, Aug 08, 2005 at 10:05:23AM -0300, Aristeu Sergio Rozanski Filho wrote:
> Hi,
> > I have done this for cpm_iic_read, cpm_iic_write and cpm_iic_try_address.
> > Also note the the addition of "| 0x01" to i2c->i2c_i2com.
> the updated patch is attached, thanks Joakim.
> seems Debora need this too for 2.4 version. Debora, could you please
> generate a diff against latest Wolfgang's development tree and submit to
> him?
I've tested this version with my cheesy sttm reader on an rpxlite, and
with the following, things work:
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
diff --git a/drivers/i2c/busses/i2c-rpx.c b/drivers/i2c/busses/i2c-rpx.c
--- a/drivers/i2c/busses/i2c-rpx.c
+++ b/drivers/i2c/busses/i2c-rpx.c
@@ -55,17 +55,7 @@ rpx_iic_init(struct i2c_algo_8xx_data *d
data->i2c = (i2c8xx_t *)&(((immap_t *)IMAP_ADDR)->im_i2c);
}
-static int rpx_install_isr(int irq, void (*func)(void *, void *), void *data)
-{
- /* install interrupt handler */
- cpm_install_handler(irq, (void (*)(void *, struct pt_regs *)) func, data);
-
- return 0;
-}
-
-static struct i2c_algo_8xx_data rpx_data = {
- .setisr = rpx_install_isr
-};
+static struct i2c_algo_8xx_data rpx_data;
static struct i2c_adapter rpx_ops = {
.owner = THIS_MODULE,
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: MPC8555CDS & CCSRBAR
From: Kim Phillips @ 2005-08-09 16:04 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded, erickampman
In-Reply-To: <42F8D186.1030209@anagramm.de>
or this...
static int sec_probe(struct device *device)
{
struct platform_device *pdev = to_platform_device(device);
struct resource *r;
sec_irq = platform_get_irq(pdev, 0);
rc = request_irq(sc->sc_irq, talitos_intr, 0, "talitos", sc);
if (rc) {
printk("failed to hook irq %d\n", sec_irq);
sec_irq = -1;
goto out;
}
/* we read its hardware registers as memory */
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
sec_base_addr = (ocf_iomem_t) ioremap(r->start, (r->end - r->start));
if (!sec_base_addr) {
printk("failed to ioremap 0x%x-0x%x\n",
(u32)r->start, (u32)r->end - (u32)r->start);
goto out;
}
...
}
Kim
On Tue, 09 Aug 2005 17:53:42 +0200
Clemens Koller <clemens.koller@anagramm.de> wrote:
> Hi!
>
> You might want to try that:
>
> #include <asm/mpc85xx.h>
> #include <immap_85xx.h> /* see mail archives for complete mpc8540 version */
> ...
>
> void foo(void)
> {
> volatile ccsr_t *immap;
> phys_addr_t ccsrbar;
>
> ccsrbar=get_ccsrbar();
> immap=ioremap(ccsrbar,sizeof(ccsr_t)); /* is ioremap_nochache() the same on mpc85xx? */
> if (!immap) {
> printk(KERN_ALERT "Failed to ioremap CCSRBAR!\n");
> err = -EIO;
> goto out;
> }
>
> /* examples */
> printk(KERN_INFO "CCSRBAR addr %.8lx\n",ccsrbar);
> printk(KERN_INFO "IMMAP addr %p\n",immap);
> printk(KERN_INFO "BR0 %.8x\n",immap->im_lbc.br0);
> printk(KERN_INFO "OR0 %.8x\n",immap->im_lbc.or0);
>
> /* unmap the ccsr*/
> iounmap(immap);
> out:
> }
>
> I hope that's all current code.
> Comments are welcome.
>
> Greets,
>
> Clemens Koller
> _______________________________
> R&D Imaging Devices
> Anagramm GmbH
> Rupert-Mayer-Str. 45/1
> 81379 Muenchen
> Germany
>
> http://www.anagramm.de
> Phone: +49-89-741518-50
> Fax: +49-89-741518-19
>
>
> Gerhard Jaeger wrote:
> > On Tuesday 09 August 2005 16:04, Eric Kampman wrote:
> >
> >>Trying to port an SEC driver to Linux/PPC8555. Reading
> >>the default CCSRBAR @ 0xFF700000 I read 0xFFFFFFFF
> >>which is wrong. Looking at Metrowerks init files and
> >>uboot code (1.1.2) I see it's likely been moved to
> >>0xE0000000, but I get a seg fault when I try to read
> >>there.
> >>
> >>So, what am I doing wrong, and even better, how do I
> >>at runtime find out where CCSRBAR is? Thanks in
> >>advance, and please forgive the likely ignorance,
> >>
> >>Eric
> >>
> >
> >
> > use the get_ccsrbar() function to get the address, then ioremap()
> > will be your friend ;)
> >
> > HTH
> > Gerhard
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Kim
^ permalink raw reply
* Re: MPC8555CDS & CCSRBAR
From: Clemens Koller @ 2005-08-09 15:53 UTC (permalink / raw)
To: Gerhard Jaeger; +Cc: Eric Kampman, linuxppc-embedded
In-Reply-To: <200508091615.53736.g.jaeger@sysgo.com>
Hi!
You might want to try that:
#include <asm/mpc85xx.h>
#include <immap_85xx.h> /* see mail archives for complete mpc8540 version */
...
void foo(void)
{
volatile ccsr_t *immap;
phys_addr_t ccsrbar;
ccsrbar=get_ccsrbar();
immap=ioremap(ccsrbar,sizeof(ccsr_t)); /* is ioremap_nochache() the same on mpc85xx? */
if (!immap) {
printk(KERN_ALERT "Failed to ioremap CCSRBAR!\n");
err = -EIO;
goto out;
}
/* examples */
printk(KERN_INFO "CCSRBAR addr %.8lx\n",ccsrbar);
printk(KERN_INFO "IMMAP addr %p\n",immap);
printk(KERN_INFO "BR0 %.8x\n",immap->im_lbc.br0);
printk(KERN_INFO "OR0 %.8x\n",immap->im_lbc.or0);
/* unmap the ccsr*/
iounmap(immap);
out:
}
I hope that's all current code.
Comments are welcome.
Greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
Gerhard Jaeger wrote:
> On Tuesday 09 August 2005 16:04, Eric Kampman wrote:
>
>>Trying to port an SEC driver to Linux/PPC8555. Reading
>>the default CCSRBAR @ 0xFF700000 I read 0xFFFFFFFF
>>which is wrong. Looking at Metrowerks init files and
>>uboot code (1.1.2) I see it's likely been moved to
>>0xE0000000, but I get a seg fault when I try to read
>>there.
>>
>>So, what am I doing wrong, and even better, how do I
>>at runtime find out where CCSRBAR is? Thanks in
>>advance, and please forgive the likely ignorance,
>>
>>Eric
>>
>
>
> use the get_ccsrbar() function to get the address, then ioremap()
> will be your friend ;)
>
> HTH
> Gerhard
^ permalink raw reply
* Wall clock accuracy
From: Rune Torgersen @ 2005-08-09 15:23 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 5176 bytes --]
Hi
I have discovered that the accuracy of the wallclock (xtime) on ppc is
not very good.
I am running a custom telco board based on a 8266, and the main busclock
is derived off of a T1 reference clock.
I was noticing a huge number of logentries fron OpenNTPD about
adjustiing the clock, so I started to check.
The drift of the walltime was a little over 7 seconds in 15 hours (7
seconds slow) (equals about 130us per s)
When I checked around, I found that xtime is updated in kernel/time.c
and is updated by time_nsec nanoseconds per timer interrupt.
This value is hardcoded (through some obscure macros) to be 999848
ns/timertick. Tis is 152ns slow per timertick. This works out to be
152us per second, almos the value I found.
I have tried a few workarounds, and made one that modifies time_nsec
before update_wall_time_one_tick() is called.
With this fix (which is 8260 specific at the time) I have less than 1 ms
drift after 5 days.
The fix works by calculating how many ns and fractions of ns there is in
one timer-tick (one jiffie).
Then, at each timer interrupt, I accumulate the ns fractions, and add
whole ns to the timer when needed.
This is tested on 8266 under 80.00MHz and 82.575360MHz main busclock. It
also works correct if HZ=1024 instead of 1000
It is not meant as a patch to be added to the kernel right now, but more
of a possible solution to a problem that it doesn't seem anybody has
noticed before.
Index: arch/ppc/kernel/time.c
===================================================================
--- arch/ppc/kernel/time.c (revision 20)
+++ arch/ppc/kernel/time.c (working copy)
@@ -119,6 +119,11 @@
EXPORT_SYMBOL(profile_pc);
#endif
+
+#ifdef CONFIG_8260
+extern unsigned long get_ns_delta(void); /*
arch/ppc/syslib/m8260_setup.c */
+extern unsigned long tick_nsec; /* kernel/time.c */
+#endif
/*
* timer_interrupt - gets called when the decrementer overflows,
* with interrupts disabled.
@@ -148,6 +153,10 @@
/* We are in an interrupt, no need to save/restore flags
*/
write_seqlock(&xtime_lock);
tb_last_stamp = jiffy_stamp;
+
+#ifdef CONFIG_8260
+ tick_nsec = get_ns_delta();
+#endif
do_timer(regs);
/*
@@ -179,7 +188,7 @@
write_sequnlock(&xtime_lock);
}
if ( !disarm_decr[smp_processor_id()] )
- set_dec(next_dec);
+ set_dec(next_dec-1);
last_jiffy_stamp(cpu) = jiffy_stamp;
if (ppc_md.heartbeat && !ppc_md.heartbeat_count--)
Index: arch/ppc/syslib/m8260_setup.c
===================================================================
--- arch/ppc/syslib/m8260_setup.c (revision 20)
+++ arch/ppc/syslib/m8260_setup.c (working copy)
@@ -31,6 +31,8 @@
#include "cpm2_pic.h"
+#include <linux/module.h>
+
unsigned char __res[sizeof(bd_t)];
extern void cpm2_reset(void);
@@ -82,16 +84,63 @@
/* The decrementer counts at the system (internal) clock frequency
* divided by four.
*/
+unsigned long tb_time_nsec;
+unsigned long tb_frac_nsec;
+unsigned long tb_frac_limit;
+
+extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
+
static void __init
m8260_calibrate_decr(void)
+{
+ bd_t *binfo = (bd_t *)__res;
+ int freq, divisor, tick_freq;
+ uint64_t tmp;
+ printk("Calibrating Decrementer\n");
+
+ freq = binfo->bi_busfreq;
+ divisor = 4;
+
+ /* get rounded off decrementer frequency */
+ tick_freq = (freq + 3) / 4;
+
+ /* get number of timebase ticks per jiffy (timerint) */
+ tb_ticks_per_jiffy = (tick_freq + (HZ/2)) / HZ;
+ tb_to_us = mulhwu_scale_factor(tick_freq, 1000000);
+
+ /* calculate timer interrupt interval in nano seconds */
+ tmp = 1000000000ULL * (u64)tb_ticks_per_jiffy;
+ __div64_32(&tmp, tick_freq);
+ tb_time_nsec = tmp;
+
+ /* calculate fractions of nanosecons per timer interrupt */
+ tb_frac_limit = 100000UL;
+ tmp = 1000000000ULL * (u64)tb_ticks_per_jiffy * tb_frac_limit;
+ __div64_32(&tmp, tick_freq);
+ tb_frac_nsec = (u32)(tmp - (u64)tb_time_nsec * (u64)tb_frac_limit);
+
+ printk("busfreq = %u\n", freq);
+ printk("tb_ticks_per_jiffy = %u\ntb_to_us = %u\n",
tb_ticks_per_jiffy, tb_to_us);
+ printk("tick_freq = %u\ntime_nsec = %u\ntb_frac_nsec = %u\n",
tick_freq, tb_time_nsec, tb_frac_nsec);
+}
+
+unsigned long get_ns_delta(void)
{
- bd_t *binfo = (bd_t *)__res;
- int freq, divisor;
+ static uint32_t frac = 0;
- freq = binfo->bi_busfreq;
- divisor = 4;
- tb_ticks_per_jiffy = freq / HZ / divisor;
- tb_to_us = mulhwu_scale_factor(freq / divisor, 1000000);
+ unsigned long delta_ns;
+
+ delta_ns = tb_time_nsec;
+
+ /* adjust for inaccuracy in calculation */
+ frac += tb_frac_nsec;
+ if (frac >= tb_frac_limit)
+ {
+ delta_ns += frac / tb_frac_limit;
+ frac %= tb_frac_limit;
+ }
+
+ return delta_ns;
}
/* The 8260 has an internal 1-second timer update register that
Rune Torgersen
System Developer
Innovative Systems LLC
1000 Innovative Drive
Mitchell, SD 57301
Ph: 605-995-6120
www.innovsys.com
[-- Attachment #2: WallClock-fix --]
[-- Type: application/octet-stream, Size: 3451 bytes --]
Index: arch/ppc/kernel/time.c
===================================================================
--- arch/ppc/kernel/time.c (revision 20)
+++ arch/ppc/kernel/time.c (working copy)
@@ -119,6 +119,11 @@
EXPORT_SYMBOL(profile_pc);
#endif
+
+#ifdef CONFIG_8260
+extern unsigned long get_ns_delta(void); /* arch/ppc/syslib/m8260_setup.c */
+extern unsigned long tick_nsec; /* kernel/time.c */
+#endif
/*
* timer_interrupt - gets called when the decrementer overflows,
* with interrupts disabled.
@@ -148,6 +153,10 @@
/* We are in an interrupt, no need to save/restore flags */
write_seqlock(&xtime_lock);
tb_last_stamp = jiffy_stamp;
+
+#ifdef CONFIG_8260
+ tick_nsec = get_ns_delta();
+#endif
do_timer(regs);
/*
@@ -179,7 +188,7 @@
write_sequnlock(&xtime_lock);
}
if ( !disarm_decr[smp_processor_id()] )
- set_dec(next_dec);
+ set_dec(next_dec-1);
last_jiffy_stamp(cpu) = jiffy_stamp;
if (ppc_md.heartbeat && !ppc_md.heartbeat_count--)
Index: arch/ppc/syslib/m8260_setup.c
===================================================================
--- arch/ppc/syslib/m8260_setup.c (revision 20)
+++ arch/ppc/syslib/m8260_setup.c (working copy)
@@ -31,6 +31,8 @@
#include "cpm2_pic.h"
+#include <linux/module.h>
+
unsigned char __res[sizeof(bd_t)];
extern void cpm2_reset(void);
@@ -82,16 +84,63 @@
/* The decrementer counts at the system (internal) clock frequency
* divided by four.
*/
+unsigned long tb_time_nsec;
+unsigned long tb_frac_nsec;
+unsigned long tb_frac_limit;
+
+extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
+
static void __init
m8260_calibrate_decr(void)
+{
+ bd_t *binfo = (bd_t *)__res;
+ int freq, divisor, tick_freq;
+ uint64_t tmp;
+ printk("Calibrating Decrementer\n");
+
+ freq = binfo->bi_busfreq;
+ divisor = 4;
+
+ /* get rounded off decrementer frequency */
+ tick_freq = (freq + 3) / 4;
+
+ /* get number of timebase ticks per jiffy (timerint) */
+ tb_ticks_per_jiffy = (tick_freq + (HZ/2)) / HZ;
+ tb_to_us = mulhwu_scale_factor(tick_freq, 1000000);
+
+ /* calculate timer interrupt interval in nano seconds */
+ tmp = 1000000000ULL * (u64)tb_ticks_per_jiffy;
+ __div64_32(&tmp, tick_freq);
+ tb_time_nsec = tmp;
+
+ /* calculate fractions of nanosecons per timer interrupt */
+ tb_frac_limit = 100000UL;
+ tmp = 1000000000ULL * (u64)tb_ticks_per_jiffy * tb_frac_limit;
+ __div64_32(&tmp, tick_freq);
+ tb_frac_nsec = (u32)(tmp - (u64)tb_time_nsec * (u64)tb_frac_limit);
+
+ printk("busfreq = %u\n", freq);
+ printk("tb_ticks_per_jiffy = %u\ntb_to_us = %u\n", tb_ticks_per_jiffy, tb_to_us);
+ printk("tick_freq = %u\ntime_nsec = %u\ntb_frac_nsec = %u\n", tick_freq, tb_time_nsec, tb_frac_nsec);
+}
+
+unsigned long get_ns_delta(void)
{
- bd_t *binfo = (bd_t *)__res;
- int freq, divisor;
+ static uint32_t frac = 0;
- freq = binfo->bi_busfreq;
- divisor = 4;
- tb_ticks_per_jiffy = freq / HZ / divisor;
- tb_to_us = mulhwu_scale_factor(freq / divisor, 1000000);
+ unsigned long delta_ns;
+
+ delta_ns = tb_time_nsec;
+
+ /* adjust for inaccuracy in calculation */
+ frac += tb_frac_nsec;
+ if (frac >= tb_frac_limit)
+ {
+ delta_ns += frac / tb_frac_limit;
+ frac %= tb_frac_limit;
+ }
+
+ return delta_ns;
}
/* The 8260 has an internal 1-second timer update register that
^ permalink raw reply
* Re: Merging ppc32 and ppc64
From: Segher Boessenkool @ 2005-08-09 15:16 UTC (permalink / raw)
To: Kumar Gala
Cc: Joel Schopp, linuxppc64-dev, Geert Uytterhoeven,
Linux/PPC Development
In-Reply-To: <3F1564F6-3732-403B-BA6B-BFAB28568AEE@freescale.com>
> I was under the impression that ALL platforms regardless if the had a
> OF firmware or not would be using a flattened device tree. Any
> conversion between an OF tree to a flatten tree would end up happening
> in boot wrapper code going forward.
Ah OK -- so part of the problem is indeed terminology
confusion. I view the "boot wrapper code" (prom_init.c)
as being part of the kernel.
Another thing is that I do not want prom_init to kill
OF at all, which means you cannot have a static device
tree. But that is another fight ;-)
Segher
^ permalink raw reply
* Re: mpc8248 SEC -- interrupt handler 'is' invoked
From: Kim Phillips @ 2005-08-09 15:13 UTC (permalink / raw)
To: Vikas Aggarwal; +Cc: linuxppc-embedded
In-Reply-To: <24431.198.22.236.230.1123594721.squirrel@198.22.236.230>
On Tue, 9 Aug 2005 09:38:41 -0400 (EDT)
"Vikas Aggarwal" <va824363@albany.edu> wrote:
> Does that still use the DMA if i bypass channel infrastructure.?
no.
> Do i have to implement channel-infrastructure in software driver.
it depends on what you want the SEC to do. If you only want RNG, then no, but if you want to use all the EU's at the same time, then you're probably better off fixing the channel error.
Have you been able to trace the register writes with a wrapper function? No zero pointers being written to the SEC? Also, on the 82xx, some bus errors get reported in the PQ2 SUI registers, so you might want to check them, too.
--
Kim
^ permalink raw reply
* Re: Merging ppc32 and ppc64
From: Olof Johansson @ 2005-08-09 14:52 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Joel Schopp, linuxppc-dev, linuxppc64-dev
In-Reply-To: <bb9b1e9e1ebdc3ac5b23b3cab327bfd5@kernel.crashing.org>
On Tue, Aug 09, 2005 at 03:09:02PM +0200, Segher Boessenkool wrote:
> _Please_ don't throw the real device tree away; I'm happy with
> the flattened device tree if and only if it is a _minimum_
> requirement, and having a _real_ device tree (or even real
> Open Firmware support) is still an option.
We already do that. prom_init.c will walk the OF device tree and build a
flattened one before booting the kernel.
-Olof
^ permalink raw reply
* open() returns 0.
From: Jayaprakash Shanmugam @ 2005-08-09 15:00 UTC (permalink / raw)
To: linuxppc-embedded
Hello All,
I have a 8270 based board running Linux 2.6. I am using the i2c
available on chip to read / write a i2c mux connected to it. When I
open the i2c device, it returns 0 (which shouldnt be) instead of the
file descriptor. The /proc/devices shows the i2c driver with major
89 is installed.
10:~# ls -l /dev/i2c-0
lrwxrwxrwx 1 root root 5 Jan 1 02:00 /dev/i2c-0 -> i2c/0
10:~# cat /dev/i2c-0
i2c-dev: i2c-0 reading 4096 bytes.
I2C xfer: read from 0xFFFF, flags 0x0001, 4096 bytes
I2C error: 0x3C04
cat: /dev/i2c-0: Input/output error
Any pointers on what could be wrong ?
Regards,
Jayaprakash.
^ permalink raw reply
* Re: Merging ppc32 and ppc64
From: Kumar Gala @ 2005-08-09 15:01 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc64-dev, Geert Uytterhoeven, Linux/PPC Development
In-Reply-To: <200508091647.32925.arnd@arndb.de>
> I think you are both right, just using different terminology. The
> running kernel uses its own representation of the device tree, which
> is neither the flattened stuff nor using the OF interfaces. The
> conversion from OF to the flattened tree is done by the kernel itself.
>
> Apple OF \
> SLOF \
> pSeries |-1- prom_init------,
> PIBS / \
> ... / \
> \
> other -----------------------------2--
> unflatten_device_tree--3--
> boot loader /
> /
> iSeries ----------- early_setup---`
>
> All "regular" machines enter in the traditional prom_init path (1)
> from Open Firmware. The embedded machines that are too memory
> constraint
> to use SLOF have a flattened device tree in their boot loader and the
> legacy iSeries boxes can fake the device tree in their
> iSeries_early_setup
> function. The main entry point (2) is entered by all machines when the
> flattened device tree is there and the kernel builds its tree
> representation
> for run time (3).
I guess my point is that in the "new" powerpc arch doing steps 1 & 3
should no longer be part of the kernel proper. The should be handled
by boot wrappers of some form. I know Ben tool care to ensure that
prom_init was isolated from kernel proper and I'm suggesting we move
it into a boot wrapper going forward.
- kumar
^ permalink raw reply
* Re: How to disable dcache on MPC82xx platform
From: Prashant Alange @ 2005-08-09 14:57 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <5c9191bc3e15d90c966735662c28fa5e@embeddededge.com>
Since the existing UART/ethernet drivers are using cpm_hostalloc() so
I am also using the same function. Then can I use kmalloc() to alloc
such huge memory. If at all I have to configure BATx to just test how
it behaves. How/where to configure BATx. One more thing is that
totally I am allocating about 1MB memory in a chunk of 200K. I really
dont know whether I can do such allocation in driver. But this much is
very much required for my driver. If you have any other idea of
achieving this then please point me in that direction. I need to get
rid of this problme as early as possible to meet my schedule. please
help.
Thanks,
Prashant
On 8/9/05, Dan Malek <dan@embeddededge.com> wrote:
>=20
> On Aug 8, 2005, at 10:30 PM, Prashant Alange wrote:
>=20
> > I am using alloc_bootmem_page() function to allocate memory required
> > in my custom ethernet driver.
>=20
> Why? Just use the normal Linux memory allocators.
>=20
> > So I am thinking this could be because of cache since this
> > driver is working fine on non-os platform. I want to disable the
> > dcache for this memory region.
>=20
> This is a fully cache coherent processor, there is no need to
> disable caching, nor is there any easy way to do this in the
> current Linux implementation. This would require a custom
> kernel, and you couldn't take advantage of the general
> performance gain using BATs.
>=20
> Thanks.
>=20
> -- Dan
>=20
>
^ permalink raw reply
* Re: [linuxppc] 2.6.12-3 header <asm/usb.h> missing ?
From: Kumar Gala @ 2005-08-09 14:50 UTC (permalink / raw)
To: John Otken; +Cc: thomas, linuxppc-embedded list
In-Reply-To: <42F89F49.4000205@softadvances.com>
Why are we bothering with asm-ppc/usb.h anyways?
The structure defn only appears to be used once. If this is true,
why not just define it in the .c file.
- kumar
On Aug 9, 2005, at 7:19 AM, John Otken wrote:
> Google found it for me. It is in my "Support 440EP
> On-Chip OHCI USB Host Controller" patch:
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=1965
>
>
> diff -uprN a/include/asm-ppc/usb.h b/include/asm-ppc/usb.h
> --- a/include/asm-ppc/usb.h 1969-12-31 17:00:00.000000000 -0700
> +++ b/include/asm-ppc/usb.h 2005-08-05 06:13:58.000000000 -0500
> @@ -0,0 +1,13 @@
> +/*
> + * ppc/usb.h:
> + *
> + */
> +#ifndef _PPC_USB_H
> +#define _PPC_USB_H
> +
> +struct usb_hcd_platform_data {
> + int (*start) (struct platform_device *pdev);
> + void (*stop) (struct platform_device *pdev);
> +};
> +
> +#endif /* !(_PPC_USB_H) */
>
>
> Kumar Gala wrote:
>
>>
>>
>> Begin forwarded message:
>>
>>
>>> From: "Thomas S." <thomas@schnuerer-online.de>
>>> Date: August 8, 2005 4:48:03 PM CDT
>>> To: <linux-kernel@vger.kernel.org>
>>> Subject: [linuxppc] 2.6.12-3 header <asm/usb.h> missing ?
>>>
>>>
>>> Hello,
>>>
>>> Im using Kernel PPC on a MPC5200 board and try to use the onChip
>>> USB. In
>>> file /drivers/usb/host/ohci-ppc-soc.c a file <asm/usb.h> is included
>>> which seems to be missing. I cant find it anywhere , any ideas ?
>>>
>>> Thomas
>>>
>>>
>>>
>>>
>>> -
>>> To unsubscribe from this list: send the line "unsubscribe linux-
>>> kernel"
>>> in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>>
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>
^ permalink raw reply
* Re: Merging ppc32 and ppc64
From: Arnd Bergmann @ 2005-08-09 14:47 UTC (permalink / raw)
To: linuxppc64-dev; +Cc: Linux/PPC Development, Geert Uytterhoeven
In-Reply-To: <3F1564F6-3732-403B-BA6B-BFAB28568AEE@freescale.com>
On Dinsdag 09 August 2005 16:12, Kumar Gala wrote:
> > Yes, and that is exactly what I do not want. =A0We are not going
> > to require OF implementations that do not need yaboot or similar
> > to pass a flattened device tree to the kernel, eh? =A0Also, there
> > is no reason why something like yaboot (with an OF still running
> > underneath) should have to care about anything device-tree related
> > at all; the OS can just as easily ask the OF itself.
>=20
> I was under the impression that ALL platforms regardless if the had a =A0
> OF firmware or not would be using a flattened device tree. =A0Any =A0
> conversion between an OF tree to a flatten tree would end up =A0
> happening in boot wrapper code going forward.
I think you are both right, just using different terminology. The=20
running kernel uses its own representation of the device tree, which
is neither the flattened stuff nor using the OF interfaces. The=20
conversion from OF to the flattened tree is done by the kernel itself.
Apple OF \
SLOF \
pSeries |-1- prom_init------,
PIBS / \
... / \
\
other -----------------------------2--unflatten_device_tree--3--
boot loader /
/
iSeries ----------- early_setup---`
All "regular" machines enter in the traditional prom_init path (1)=20
from Open Firmware. The embedded machines that are too memory constraint
to use SLOF have a flattened device tree in their boot loader and the
legacy iSeries boxes can fake the device tree in their iSeries_early_setup
function. The main entry point (2) is entered by all machines when the
flattened device tree is there and the kernel builds its tree representation
for run time (3).
Arnd <><
^ permalink raw reply
* Re: How to disable dcache on MPC82xx platform
From: Dan Malek @ 2005-08-09 14:37 UTC (permalink / raw)
To: Prashant Alange; +Cc: linuxppc-embedded
In-Reply-To: <6d145b42050808193058ee05b4@mail.gmail.com>
On Aug 8, 2005, at 10:30 PM, Prashant Alange wrote:
> I am using alloc_bootmem_page() function to allocate memory required
> in my custom ethernet driver.
Why? Just use the normal Linux memory allocators.
> So I am thinking this could be because of cache since this
> driver is working fine on non-os platform. I want to disable the
> dcache for this memory region.
This is a fully cache coherent processor, there is no need to
disable caching, nor is there any easy way to do this in the
current Linux implementation. This would require a custom
kernel, and you couldn't take advantage of the general
performance gain using BATs.
Thanks.
-- Dan
^ permalink raw reply
* Re: MPC8555CDS & CCSRBAR
From: Kumar Gala @ 2005-08-09 14:33 UTC (permalink / raw)
To: Gerhard Jaeger; +Cc: Eric Kampman, linuxppc-embedded
In-Reply-To: <200508091615.53736.g.jaeger@sysgo.com>
On Aug 9, 2005, at 9:15 AM, Gerhard Jaeger wrote:
> On Tuesday 09 August 2005 16:04, Eric Kampman wrote:
>
>> Trying to port an SEC driver to Linux/PPC8555. Reading
>> the default CCSRBAR @ 0xFF700000 I read 0xFFFFFFFF
>> which is wrong. Looking at Metrowerks init files and
>> uboot code (1.1.2) I see it's likely been moved to
>> 0xE0000000, but I get a seg fault when I try to read
>> there.
>>
>> So, what am I doing wrong, and even better, how do I
>> at runtime find out where CCSRBAR is? Thanks in
>> advance, and please forgive the likely ignorance,
>>
>> Eric
>>
>>
>
> use the get_ccsrbar() function to get the address, then ioremap()
> will be your friend ;)
Depending on the kernel version you might want to use the driver
model instead. There is an entry for the security engine which will
give you the physical address to ioremap and the interrupt number to
use. Doing this will be more portable. However, this is only in
newer 2.6 kernels.
- kumar
^ permalink raw reply
* Re: MPC8555CDS & CCSRBAR
From: Gerhard Jaeger @ 2005-08-09 14:15 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Eric Kampman
In-Reply-To: <20050809140428.13450.qmail@web41211.mail.yahoo.com>
On Tuesday 09 August 2005 16:04, Eric Kampman wrote:
> Trying to port an SEC driver to Linux/PPC8555. Reading
> the default CCSRBAR @ 0xFF700000 I read 0xFFFFFFFF
> which is wrong. Looking at Metrowerks init files and
> uboot code (1.1.2) I see it's likely been moved to
> 0xE0000000, but I get a seg fault when I try to read
> there.
>
> So, what am I doing wrong, and even better, how do I
> at runtime find out where CCSRBAR is? Thanks in
> advance, and please forgive the likely ignorance,
>
> Eric
>
use the get_ccsrbar() function to get the address, then ioremap()
will be your friend ;)
HTH
Gerhard
--
Gerhard Jaeger <gjaeger@sysgo.com>
SYSGO AG Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de
^ permalink raw reply
* Re: Merging ppc32 and ppc64
From: Kumar Gala @ 2005-08-09 14:12 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Joel Schopp, linuxppc64-dev, Geert Uytterhoeven,
Linux/PPC Development
In-Reply-To: <dc3d7701e701266ffe852acf4da127ed@kernel.crashing.org>
On Aug 9, 2005, at 8:30 AM, Segher Boessenkool wrote:
>>>>> I don't see the merge as changing the actual code that gets
>>>>>
> executed
>
>>>>> on any given platform very much, except in one respect: we are
>>>>>
> going
>
>>>>> to standardize on a flattened device tree as the way that
>>>>> information
>>>>> about the platform gets passed from the boot loader to the kernel.
>>>>>
>>
>> ^^^^^^^^^^^^^^^^^^^^^***********^^^^^^^^******^
>>
>
> Yes, and that is exactly what I do not want. We are not going
> to require OF implementations that do not need yaboot or similar
> to pass a flattened device tree to the kernel, eh? Also, there
> is no reason why something like yaboot (with an OF still running
> underneath) should have to care about anything device-tree related
> at all; the OS can just as easily ask the OF itself.
I was under the impression that ALL platforms regardless if the had a
OF firmware or not would be using a flattened device tree. Any
conversion between an OF tree to a flatten tree would end up
happening in boot wrapper code going forward.
- kumar
^ permalink raw reply
* MPC8555CDS & CCSRBAR
From: Eric Kampman @ 2005-08-09 14:04 UTC (permalink / raw)
To: linuxppc-embedded
Trying to port an SEC driver to Linux/PPC8555. Reading
the default CCSRBAR @ 0xFF700000 I read 0xFFFFFFFF
which is wrong. Looking at Metrowerks init files and
uboot code (1.1.2) I see it's likely been moved to
0xE0000000, but I get a seg fault when I try to read
there.
So, what am I doing wrong, and even better, how do I
at runtime find out where CCSRBAR is? Thanks in
advance, and please forgive the likely ignorance,
Eric
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
^ permalink raw reply
* Re: mpc8248 SEC -- interrupt handler 'is' invoked
From: Vikas Aggarwal @ 2005-08-09 13:38 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-embedded
In-Reply-To: <20050803153540.3530e114.kim.phillips@freescale.com>
Does that still use the DMA if i bypass channel infrastructure.?
Do i have to implement channel-infrastructure in software driver.
-vikas
> On Wed, 3 Aug 2005 14:33:26 -0400 (EDT)
> "Vikas Aggarwal" <va824363@albany.edu> wrote:
>
>> I will try the new BSP but meanwhile like to debug my ported driver.
>>
>> Is there a way , like kernel level single-stepping to know why the
>> "interrupt status register" gets a value of "0x0000000000000040" which
>> means TEA , transfer error acknowledge.
>
> afaik, TEA usually means memory was unable to be accessed by the sec
> (somewhat along the same lines as a SIGBUS or SIGSEGV).
>
> It's a long shot, but you may want to increase the 4-byte alignment of the
> rng buffer (0x009ffc5c in your trace?) to at least 8-byte.
>
> as for debugging, you can printk sec status registers every time you write
> one, e.g. in a sec register write wrapper fn. Be sure to check the RNG
> interrupt status register, and the RNG status register, and the RNG
> interrupt control register.
>
> and if all else fails, you can bypass the channel infrastructure
> altogether, and use the RNG EU in slave mode. Reset the SEC, write the
> RNG Reset Control Register SR bit, write <anyvalue> to the RNG Data size
> register, and pull data off the RNG FIFO at will.
>
> Kim
>
^ permalink raw reply
* Re: A configure error for samba3 on ppc
From: Clemens Koller @ 2005-08-09 13:31 UTC (permalink / raw)
To: JohnsonCheng; +Cc: linuxppc-embedded
In-Reply-To: <0MKrQq-1E2Rl01y8u-0004mW@mxeu12.kundenserver.de>
Hi, JohnsonCheng!
you wrote:
> Yes. But how can I pass the testing?
Running it on the target - where it is actually supposed to work.
> For cross-compile environment, the HOST and the TARGET are almost not the
> same, so many utility can configure for cross-compile with host setting
> except samba.
Well, you can tell configure to skip the tests silently if HOST!=TARGET
or give the message you got. But I wouldn't expect configure to guess
how it can get the code from the host to the target.
Yes, it's indeed a bad virus ;-)
> It seems not sense.
I'd like to see the message.
For me I prefer to compile things native - if somehow possible.
Greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
> -----Original Message-----
> From: Clemens Koller [mailto:clemens.koller@anagramm.de]
> Sent: Tuesday, August 09, 2005 6:24 PM
> To: JohnsonCheng
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: A configure error for samba3 on ppc
>
> Hi, JohnsonCheng!
>
> you wrote:
>
>>When I configure samba3.0.10 on ppc as following command:
>>
>>CC=powerpc-linux-gcc AR=powerpc-linux-ar RANLIB=powerpc-linux-ranlib
>>./configure -host=powerpc-linux
>>
>>I got a configure error message as following:
>>Configure: error: cannot run test program while cross compiling
>>See 'config.log' for more details
>>
>>I think this is a samba configure bug, do anybody know how to pass it?
>
>
> No, it's not a bug. It's exactly what the message trys to tell you.
> Samba wants to do some tests. But as it's not a native build,
> it doesn't want to execute itself for the tests. Because
> samba might not run on a different platform as it was built for.
>
> If you want to do the tests, you need to let to do it on the
> target where it was built for and not where it was built on.
>
> Samba works fine over here on ppc embedded systems.
>
> Greets,
>
> Clemens Koller
^ permalink raw reply
* Re: Merging ppc32 and ppc64
From: Segher Boessenkool @ 2005-08-09 13:30 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Joel Schopp, linuxppc64-dev, Linux/PPC Development
In-Reply-To: <Pine.LNX.4.62.0508091510400.28068@numbat.sonytel.be>
>>>> I don't see the merge as changing the actual code that gets executed
>>>> on any given platform very much, except in one respect: we are going
>>>> to standardize on a flattened device tree as the way that
>>>> information
>>>> about the platform gets passed from the boot loader to the kernel.
>
> ^^^^^^^^^^^^^^^^^^^^^***********^^^^^^^^******^
Yes, and that is exactly what I do not want. We are not going
to require OF implementations that do not need yaboot or similar
to pass a flattened device tree to the kernel, eh? Also, there
is no reason why something like yaboot (with an OF still running
underneath) should have to care about anything device-tree related
at all; the OS can just as easily ask the OF itself.
Segher
^ permalink raw reply
* Re: Merging ppc32 and ppc64
From: Geert Uytterhoeven @ 2005-08-09 13:11 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Joel Schopp, Linux/PPC Development, linuxppc64-dev
In-Reply-To: <bb9b1e9e1ebdc3ac5b23b3cab327bfd5@kernel.crashing.org>
On Tue, 9 Aug 2005, Segher Boessenkool wrote:
> > > I don't see the merge as changing the actual code that gets executed
> > > on any given platform very much, except in one respect: we are going
> > > to standardize on a flattened device tree as the way that information
> > > about the platform gets passed from the boot loader to the kernel.
^^^^^^^^^^^^^^^^^^^^^***********^^^^^^^^******^
> > > Comments? Flames? :)
> >
> > There are several userspace applications that parse the non-flat device tree
> > in /proc/device-tree on pSeries. While I like the idea of the flattened
> > device tree I think we need to consider how many apps we are going to break
> > with it.
>
> _Please_ don't throw the real device tree away; I'm happy with
> the flattened device tree if and only if it is a _minimum_
> requirement, and having a _real_ device tree (or even real
> Open Firmware support) is still an option.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Merging ppc32 and ppc64
From: Segher Boessenkool @ 2005-08-09 13:09 UTC (permalink / raw)
To: Joel Schopp; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <42F79D89.3040709@austin.ibm.com>
>> I don't see the merge as changing the actual code that gets executed
>> on any given platform very much, except in one respect: we are going
>> to standardize on a flattened device tree as the way that information
>> about the platform gets passed from the boot loader to the kernel.
>> Comments? Flames? :)
>
> There are several userspace applications that parse the non-flat
> device tree in /proc/device-tree on pSeries. While I like the idea of
> the flattened device tree I think we need to consider how many apps we
> are going to break with it.
_Please_ don't throw the real device tree away; I'm happy with
the flattened device tree if and only if it is a _minimum_
requirement, and having a _real_ device tree (or even real
Open Firmware support) is still an option.
Segher
^ 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