* Re: Wall clock accuracy
From: Eugene Surovegin @ 2005-08-09 16:59 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859417@ismail.innsys.innovsys.com>
On Tue, Aug 09, 2005 at 11:57:04AM -0500, Rune Torgersen wrote:
> > -----Original Message-----
> > From: Eugene Surovegin [mailto:ebs@ebshome.net]
> > Sent: Tuesday, August 09, 2005 11:41
> > Hmm, if I'm correct this clock drift (130ppm) should be
> > handled easily
> > by NTPD without stepping clock but with slewing. This is why NTPD
> > exists in the first place, so I don't see any reason to change
> > the kernel.
>
> NTPD probably handles this correct, but I would like the time to be
> correct anyways. In our case we might not always have access to a ntpd
> server, and our input clock is very accurate to begin with.
Well, NTPD doesn't mean you need to have network connectivity, IIRC if
you have exact frequency source, you can add it to NTPD and it'll use
it to correct drift.
--
Eugene
^ permalink raw reply
* Re: [linuxppc] 2.6.12-3 header <asm/usb.h> missing ?
From: John Otken @ 2005-08-09 16:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: thomas, linuxppc-embedded list
In-Reply-To: <A9E0A66D-CE6F-4A55-80FD-5D9E57BB6035@freescale.com>
My patch to add on-chip OHCI support to the 440EP adds
an asm/usb.h reference to 4xx/ibm440ep.c. Thomas may
also require it for his MPC5200 mods.
I don't like small include files either. Perhaps there
is an existing file where struct usb_hcd_platform_data
can live. Any suggestions?
John
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.
>
> - 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: Wall clock accuracy
From: Rune Torgersen @ 2005-08-09 16:57 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
> -----Original Message-----
> From: Eugene Surovegin [mailto:ebs@ebshome.net]=20
> Sent: Tuesday, August 09, 2005 11:41
> Hmm, if I'm correct this clock drift (130ppm) should be=20
> handled easily=20
> by NTPD without stepping clock but with slewing. This is why NTPD=20
> exists in the first place, so I don't see any reason to change=20
> the kernel.
NTPD probably handles this correct, but I would like the time to be
correct anyways. In our case we might not always have access to a ntpd
server, and our input clock is very accurate to begin with.
^ permalink raw reply
* Re: Volunteers to test i2c-algo-8xx on v2.6?
From: Tom Rini @ 2005-08-09 16:45 UTC (permalink / raw)
To: aris; +Cc: Joakim Tjernlund, linuxppc-embedded
In-Reply-To: <20050809162944.GB13871@oops.ghostprotocols.net>
On Tue, Aug 09, 2005 at 01:29:44PM -0300, aris@conectiva.com.br wrote:
> > I've tested this version with my cheesy sttm reader on an rpxlite, and
> > with the following, things work:
> ah, forgot the most important question: did you tested i2c driver?
Yes, my cheesy sttm reader app was able to print what looked like a
sane temperature (34 C, now up to 36 C).
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* fs_enet on MPC885ADS
From: Schaefer-Hutter, Peter @ 2005-08-09 16:42 UTC (permalink / raw)
To: linuxppc-embedded
Hi there,
Are there any boot options needed to enable the fs_enet driver
on the MPC885ADS? I replaced CONFIG_DUET with CONFIG_MPC885ADS
in drivers/net/fs_enet/mac-fec.c, but only got
fs_enet.c:v0.1 (May 6, 2005)
NET: Registered protocol family 2
IP route cache hash table entries: 128 (order: -3, 512 bytes)
TCP established hash table entries: 512 (order: 0, 4096 bytes)
TCP bind hash table entries: 512 (order: -1, 2048 bytes)
TCP: Hash tables configured (established 512 bind 512)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
IP-Config: Device `eth0' not found.
Reason i'm asking is that the current cpm_uart driver doesn't work
with the SCC3 ethernet driver included in the MPC885 board support
(as soon as ethernet is initialized, console output stops).
Best regards,
Peter
^ permalink raw reply
* Re: Wall clock accuracy
From: Eugene Surovegin @ 2005-08-09 16:41 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859416@ismail.innsys.innovsys.com>
On Tue, Aug 09, 2005 at 10:23:19AM -0500, Rune Torgersen wrote:
> 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)
Hmm, if I'm correct this clock drift (130ppm) should be handled easily
by NTPD without stepping clock but with slewing. This is why NTPD
exists in the first place, so I don't see any reason to change
the kernel.
It's not small drift (I usually have clock accuracy within +-50ppm),
but still is much less than maximum 1024ppm NTPD can deal with.
Maybe it's an OpenNTPD problem? I use original NTPD (ntp.org) which
handles such drifts quite well.
--
Eugene
^ permalink raw reply
* Re: How to disable dcache on MPC82xx platform
From: Dan Malek @ 2005-08-09 16:37 UTC (permalink / raw)
To: Prashant Alange; +Cc: linuxppc-embedded
In-Reply-To: <6d145b42050809075718c70574@mail.gmail.com>
On Aug 9, 2005, at 10:57 AM, Prashant Alange wrote:
> Since the existing UART/ethernet drivers are using cpm_hostalloc() so
> I am also using the same function.
As I have said too many times before, cpm_hostalloc() is only used
to allocate small memory regions that would otherwise be wasteful
with the normal Linux memory allocators. This function does not
do anything special with the memory, aside from allowing us have
multiple drivers share a page for efficiency.
> Then can I use kmalloc() to alloc
> such huge memory.
Yes, and you should.
> If at all I have to configure BATx to just test how
> it behaves.
No, that's not all you have to do. It's not a trivial process
easily described here.
> ..... One more thing is that
> totally I am allocating about 1MB memory in a chunk of 200K.
I can't comprehend a reason why you need to allocate so much
space in a driver, especially for CPM devices. The driver is just
a temporary FIFO for data flowing to/from other consumer/producers
of the data in the system. If the software above a driver needs
that kind of buffering, it should manage that itself.
If you do need so much space, use the beauty of the CPM and
link multiple BDs with reasonable sized buffers more easily
managed by the existing Linux allocators.
The other alternative is just reserve memory using the 'mem='
start parameter so it isn't know to Linux, and manage entirely
yourself.
-- Dan
^ permalink raw reply
* 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
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