* ppc pci routines howto needed
From: dosilasolfamiredo @ 2005-08-09 17:56 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
Is there somewhere available howto/other_information describing powerpc pci routines in linux kernel? I am especially interested in pci routines for PQII processors (for instance mpc8260), pci bridge initialization, probing issues and pci9 errata.
Thanks in advance,
Peter
^ permalink raw reply
* Re: [PATCH] ppc32: Add usb support to IBM stb04xxx platforms
From: Dale Farnsworth @ 2005-08-09 19:23 UTC (permalink / raw)
To: Dale Farnsworth, linuxppc-embedded
In-Reply-To: <20050809190319.GC30956@gate.ebshome.net>
On Tue, Aug 09, 2005 at 12:03:19PM -0700, Eugene Surovegin wrote:
> On Tue, Aug 09, 2005 at 11:53:27AM -0700, Dale Farnsworth wrote:
> [snip]
>
> > Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
> > ===================================================================
> > --- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
> > +++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
> > @@ -52,8 +52,18 @@
> > void __init
> > redwood5_setup_arch(void)
> > {
> > + u32 mask;
> > +
> > ppc4xx_setup_arch();
> >
> > + /*
> > + * Set up USB interrupt as positive polarity and level-sensitive.
> > + * Firmware should do this, but apparently does not.
> > + */
> > + mask = 1 << (31 - USB0_IRQ);
> > + mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) | mask);
> > + mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) & ~mask);
> > +
>
> Please, DO NOT DO THIS.
>
> There is a way to configure UIC settings without messing with UIC
> registers directly. Refer to asm-ppc/ppc4xx_pic.h and other 4xx board
> ports for more information.
>
> Eugene
Deja vu all over again, eh Eugene? I re-submitted the wrong old patch.
Correct (I hope) patch follows.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
@@ -11,6 +11,7 @@
#include <linux/init.h>
#include <asm/ocp.h>
+#include <asm/ppc4xx_pic.h>
#include <platforms/4xx/ibmstb4.h>
static struct ocp_func_iic_data ibmstb4_iic0_def = {
@@ -72,12 +73,51 @@
.irq = IDE0_IRQ,
.pm = OCP_CPM_NA,
},
- { .vendor = OCP_VENDOR_IBM,
- .function = OCP_FUNC_USB,
- .paddr = USB0_BASE,
- .irq = USB0_IRQ,
- .pm = OCP_CPM_NA,
- },
{ .vendor = OCP_VENDOR_INVALID,
}
};
+
+/* Polarity and triggering settings for internal interrupt sources */
+struct ppc4xx_uic_settings ppc4xx_core_uic_cfg[] __initdata = {
+ { .polarity = 0x7fffff01,
+ .triggering = 0x00000000,
+ .ext_irq_mask = 0x0000007e, /* IRQ0 - IRQ5 */
+ }
+};
+
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = USB0_BASE,
+ .end = USB0_BASE + USB0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = USB0_IRQ,
+ .end = USB0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xffffffffULL;
+
+static struct platform_device ohci_usb_device = {
+ .name = "ppc-soc-ohci",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev = {
+ .dma_mask = &dma_mask,
+ .coherent_dma_mask = 0xffffffffULL,
+ }
+};
+
+static struct platform_device *ibmstb4_devs[] __initdata = {
+ &ohci_usb_device,
+};
+
+static int __init
+ibmstb4_platform_add_devices(void)
+{
+ return platform_add_devices(ibmstb4_devs, ARRAY_SIZE(ibmstb4_devs));
+}
+arch_initcall(ibmstb4_platform_add_devices);
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.h
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
@@ -73,9 +73,9 @@
#define OPB0_BASE 0x40000000
#define GPIO0_BASE 0x40060000
+#define USB0_BASE 0x40010000
+#define USB0_SIZE 0xA0
#define USB0_IRQ 18
-#define USB0_BASE STB04xxx_MAP_IO_ADDR(0x40010000)
-#define USB0_EXTENT 4096
#define IIC_NUMS 2
#define UART_NUMS 3
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -18,6 +18,19 @@
#include <linux/ioport.h>
#include <asm/io.h>
#include <asm/machdep.h>
+#include <asm/ppc4xx_pic.h>
+
+/*
+ * Define external IRQ senses and polarities.
+ */
+unsigned char ppc4xx_uic_ext_irq_cfg[] __initdata = {
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 0 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 1 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 2 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 3 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 4 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 5 */
+};
static struct resource smc91x_resources[] = {
[0] = {
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* make install target implementation
From: Joerg Dorchain @ 2005-08-09 19:11 UTC (permalink / raw)
To: Linux/PPC Development
[-- Attachment #1: Type: text/plain, Size: 2255 bytes --]
Hi,
I noticed that the install target is mentioned in the help, but not
implemented. I tried an implementation that can be used by distributions
and does not break yaboot for me ;-) Patch enclosed, comments welcome.
Bye,
Joerg
Signed-off-by: Joerg Dorchain <joerg@dorchain.net>
--- arch/ppc/boot/install.sh.orig 2005-08-09 20:54:21.000000000 +0200
+++ arch/ppc/boot/install.sh 2005-08-09 21:07:26.000000000 +0200
@@ -0,0 +1,41 @@
+#!/bin/sh
+#
+# arch/ppc/boot/install.sh
+#
+# This file is subject to the terms and conditions of the GNU General Public
+# License. See the file "COPYING" in the main directory of this archive
+# for more details.
+#
+# Copyright (C) 1995 by Linus Torvalds
+#
+# Adapted from code in arch/i386/boot/install.sh by Joerg Dorchain
+#
+# "make install" script for ppc architecture
+#
+# Arguments:
+# $1 - kernel version
+# $2 - kernel image file
+# $3 - kernel map file
+# $4 - default install path (blank if root directory)
+#
+
+# User may have a custom install script
+
+if [ -x ~/bin/installkernel ]; then exec ~/bin/installkernel "$@"; fi
+if [ -x /sbin/installkernel ]; then exec /sbin/installkernel "$@"; fi
+
+# Default install - same as make zlilo
+
+if [ -f $4/vmlinux ]; then
+ mv $4/vmlinux $4/vmlinux.old
+fi
+
+if [ -f $4/System.map ]; then
+ mv $4/System.map $4/System.old
+fi
+
+cat $2 > $4/vmlinux
+cp $3 $4/System.map
+
+# No lilo here
+#if [ -x /sbin/lilo ]; then /sbin/lilo; else /etc/lilo/install; fi
--- arch/ppc/Makefile.orig 2005-08-09 20:44:33.000000000 +0200
+++ arch/ppc/Makefile 2005-08-09 21:08:20.000000000 +0200
@@ -94,7 +94,7 @@
@echo ' install - Install kernel using'
@echo ' (your) ~/bin/installkernel or'
@echo ' (distribution) /sbin/installkernel or'
- @echo ' install to $$(INSTALL_PATH) and run lilo'
+ @echo ' install to $$(INSTALL_PATH)'
@echo ' *_defconfig - Select default config from arch/$(ARCH)/ppc/configs'
endef
@@ -137,3 +137,5 @@
arch/$(ARCH)/kernel/asm-offsets.s \
$(TOUT)
+install: vmlinux
+ sh $(srctree)/$(boot)/install.sh $(KERNELRELEASE) $< System.map "$(INSTALL_PATH)"
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: Wall clock accuracy
From: Rune Torgersen @ 2005-08-09 19:11 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
> -----Original Message-----
> From: Eugene Surovegin [mailto:ebs@ebshome.net]=20
> Sent: Tuesday, August 09, 2005 13:57
> > and it would be much better to just
> > use the clockrate given to the kernel than have to hardcode=20
> it into the
> > kernel.
>=20
> Nothing prevents you from defining this macro as a function call for=20
> example. If this is needed for your CPU/board port. Probably common
> case will be a constant, though.
Problem is that time_nsec is not directly set to CLOCK_TICK_RATE but
goes through some calculations I'd rather not have to lots of times in
runtime (maybe I'm not seeing how it could be done)
Anyways, the #define chain leading to time_nsec is:
unsigned long tick_nsec =3D TICK_NSEC; /* ACTHZ period (nsec)
*/ kernel/time.c:562
#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
asm-ppc/timex.h:14
Include/linux/jiffies.h:45 and out
/* LATCH is used in the interval timer and ftape setup. */
#define LATCH ((CLOCK_TICK_RATE + HZ/2) / HZ) /* For divider */
/* Suppose we want to devide two numbers NOM and DEN: NOM/DEN, the we
can
* improve accuracy by shifting LSH bits, hence calculating:
* (NOM << LSH) / DEN
* This however means trouble for large NOM, because (NOM << LSH) may no
* longer fit in 32 bits. The following way of calculating this gives us
* some slack, under the following conditions:
* - (NOM / DEN) fits in (32 - LSH) bits.
* - (NOM % DEN) fits in (32 - LSH) bits.
*/
#define SH_DIV(NOM,DEN,LSH) ( ((NOM / DEN) << LSH)
\
+ (((NOM % DEN) << LSH) + DEN / 2) / DEN)
/* HZ is the requested value. ACTHZ is actual HZ ("<< 8" is for
accuracy) */
#define ACTHZ (SH_DIV (CLOCK_TICK_RATE, LATCH, 8))
/* TICK_NSEC is the time between ticks in nsec assuming real ACTHZ */
#define TICK_NSEC (SH_DIV (1000000UL * 1000, ACTHZ, 8))
I cannot se a clean easy way of changing time_nsec or TIME_NSEC runtime
without messing with code that probably should not be messed with.
Of course I am probably wrong.
^ permalink raw reply
* Re: [PATH] ppc32: Add usb support to IBM stb04xxx platforms
From: Eugene Surovegin @ 2005-08-09 19:03 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-embedded
In-Reply-To: <20050809185327.GA19340@xyzzy.farnsworth.org>
On Tue, Aug 09, 2005 at 11:53:27AM -0700, Dale Farnsworth wrote:
[snip]
> Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
> ===================================================================
> --- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
> +++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
> @@ -52,8 +52,18 @@
> void __init
> redwood5_setup_arch(void)
> {
> + u32 mask;
> +
> ppc4xx_setup_arch();
>
> + /*
> + * Set up USB interrupt as positive polarity and level-sensitive.
> + * Firmware should do this, but apparently does not.
> + */
> + mask = 1 << (31 - USB0_IRQ);
> + mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) | mask);
> + mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) & ~mask);
> +
Please, DO NOT DO THIS.
There is a way to configure UIC settings without messing with UIC
registers directly. Refer to asm-ppc/ppc4xx_pic.h and other 4xx board
ports for more information.
--
Eugene
^ permalink raw reply
* MPC8260 - memcpy() vs IDMA
From: Jeff Angielski @ 2005-08-09 18:51 UTC (permalink / raw)
To: linuxppc-embedded
Does anybody have any real life numbers of the latency and/or throughput
associated with moving large amounts of data using the IDMA channels
rather than direct memcpy()? Some information online suggests that the
IDMA is noticeably slower than the CPU memcpy() and that it does
significantly impact the other CPM functionality. I guess the MPC860
was really bad in this regard but the MPC82xx was supposed to be much
better. Is anybody using IDMA on their systems (besides the PCI9
workaround?)
FWIW, I am moving around 1 to 4MB/s of data from an FPGA to local memory
on a custom MPC8260 board.
Thanks,
Jeff Angielski
The PTR Group
^ permalink raw reply
* Re: Wall clock accuracy
From: Eugene Surovegin @ 2005-08-09 18:56 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B85941C@ismail.innsys.innovsys.com>
On Tue, Aug 09, 2005 at 01:52:33PM -0500, Rune Torgersen wrote:
>
>
> > -----Original Message-----
> > From: Eugene Surovegin [mailto:ebs@ebshome.net]
> > Sent: Tuesday, August 09, 2005 13:35
> > To: Rune Torgersen
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: Wall clock accuracy
> >
> > On Tue, Aug 09, 2005 at 01:21:09PM -0500, Rune Torgersen wrote:
> > >
> > > A proper fix would be for platfrom code to have a way to
> > set time_nsec
> > > instead of having it set by a constant.
> >
> > Or configure CLOCK_TICK_RATE in board/CPU specific fashion, e.g. like
> > ARM does.
>
> Then it would have to be a constant,
Why?
> and it would be much better to just
> use the clockrate given to the kernel than have to hardcode it into the
> kernel.
Nothing prevents you from defining this macro as a function call for
example. If this is needed for your CPU/board port. Probably common
case will be a constant, though.
--
Eugene
^ permalink raw reply
* [PATH] ppc32: Add usb support to IBM stb04xxx platforms
From: Dale Farnsworth @ 2005-08-09 18:53 UTC (permalink / raw)
To: linuxppc-embedded
[ I previously submitted this on March 31st. Though I received a copy
back from the linuxppc-embedded mailing list, I don't find a copy in
the archive. (The same thing happend to my submission of asm-ppc/usb.h.)
So I'm resending. ]
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
@@ -72,12 +72,43 @@
.irq = IDE0_IRQ,
.pm = OCP_CPM_NA,
},
- { .vendor = OCP_VENDOR_IBM,
- .function = OCP_FUNC_USB,
- .paddr = USB0_BASE,
- .irq = USB0_IRQ,
- .pm = OCP_CPM_NA,
- },
{ .vendor = OCP_VENDOR_INVALID,
}
};
+
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = USB0_BASE,
+ .end = USB0_BASE + USB0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = USB0_IRQ,
+ .end = USB0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xffffffffULL;
+
+static struct platform_device ohci_usb_device = {
+ .name = "ppc-soc-ohci",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev = {
+ .dma_mask = &dma_mask,
+ .coherent_dma_mask = 0xffffffffULL,
+ }
+};
+
+static struct platform_device *ibmstb4_devs[] __initdata = {
+ &ohci_usb_device,
+};
+
+static int __init
+ibmstb4_platform_add_devices(void)
+{
+ return platform_add_devices(ibmstb4_devs, ARRAY_SIZE(ibmstb4_devs));
+}
+arch_initcall(ibmstb4_platform_add_devices);
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.h
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
@@ -73,9 +73,9 @@
#define OPB0_BASE 0x40000000
#define GPIO0_BASE 0x40060000
+#define USB0_BASE 0x40010000
+#define USB0_SIZE 0xA0
#define USB0_IRQ 18
-#define USB0_BASE STB04xxx_MAP_IO_ADDR(0x40010000)
-#define USB0_EXTENT 4096
#define IIC_NUMS 2
#define UART_NUMS 3
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -52,8 +52,18 @@
void __init
redwood5_setup_arch(void)
{
+ u32 mask;
+
ppc4xx_setup_arch();
+ /*
+ * Set up USB interrupt as positive polarity and level-sensitive.
+ * Firmware should do this, but apparently does not.
+ */
+ mask = 1 << (31 - USB0_IRQ);
+ mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) | mask);
+ mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) & ~mask);
+
#ifdef CONFIG_DEBUG_BRINGUP
printk("\n");
printk("machine\t: %s\n", PPC4xx_MACHINE_NAME);
_______________________________________________
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 18:52 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
=20
> -----Original Message-----
> From: Eugene Surovegin [mailto:ebs@ebshome.net]=20
> Sent: Tuesday, August 09, 2005 13:35
> To: Rune Torgersen
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Wall clock accuracy
>=20
> On Tue, Aug 09, 2005 at 01:21:09PM -0500, Rune Torgersen wrote:
> >=20
> > A proper fix would be for platfrom code to have a way to=20
> set time_nsec
> > instead of having it set by a constant.
>=20
> Or configure CLOCK_TICK_RATE in board/CPU specific fashion, e.g. like=20
> ARM does.
Then it would have to be a constant, and it would be much better to just
use the clockrate given to the kernel than have to hardcode it into the
kernel.
^ permalink raw reply
* Re: Merging ppc32 and ppc64
From: Kumar Gala @ 2005-08-09 18:49 UTC (permalink / raw)
To: Tom Rini
Cc: linuxppc64-dev, Geert Uytterhoeven, Arnd Bergmann,
Linux/PPC Development
In-Reply-To: <20050809174717.GO3187@smtp.west.cox.net>
On Aug 9, 2005, at 12:47 PM, Tom Rini wrote:
> On Tue, Aug 09, 2005 at 12:41:54PM -0500, Kumar Gala wrote:
>
>>
>> On Aug 9, 2005, at 11:21 AM, Tom Rini wrote:
>>
> [snip]
>
>>> 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.
>>>
>>
>> I'm not sure I follow. I understand that prom_init.c is part of the
>> kernel in ppc64. I'm saying that such things should NOT be part of
>> the arch/powerpc kernel going forward. They should be handled via
>> bootwrappers.
>>
>
> That's a "cleanup" we can argue about later, but I expect some
> resistance :)
Why argue later? Isn't part of the point of the merge to do cleanup
between ppc32 & ppc64. When would be the point to discuss this?
- kumar
^ permalink raw reply
* Re: [linuxppc] 2.6.12-3 header <asm/usb.h> missing ?
From: Kumar Gala @ 2005-08-09 18:42 UTC (permalink / raw)
To: John Otken; +Cc: thomas, linuxppc-embedded list
In-Reply-To: <42F8E0C9.2050505@softadvances.com>
Well for the 5200 Thomas should be using include/linux/fsl_devices.h
If/when 4xx coverts over to platform devices we could have an
equivalent include file if truly needed.
- kumar
On Aug 9, 2005, at 11:58 AM, John Otken wrote:
> 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: Eugene Surovegin @ 2005-08-09 18:34 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B85941B@ismail.innsys.innovsys.com>
On Tue, Aug 09, 2005 at 01:21:09PM -0500, Rune Torgersen wrote:
>
> A proper fix would be for platfrom code to have a way to set time_nsec
> instead of having it set by a constant.
Or configure CLOCK_TICK_RATE in board/CPU specific fashion, e.g. like
ARM does.
--
Eugene
^ permalink raw reply
* Re: [linuxppc] 2.6.12-3 header <asm/usb.h> missing ?
From: Dale Farnsworth @ 2005-08-09 18:26 UTC (permalink / raw)
To: Linuxppc-embedded
In-Reply-To: <A9E0A66D-CE6F-4A55-80FD-5D9E57BB6035@freescale.com>
On Tue, Aug 09, 2005 at 02:50:50PM +0000, 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
I previously added asm-ppc/usb.h.
It provides platform-specific callback functions for when the usb HC is
probed and removed. I attempted to use them for power management on the
ibmstb4 (redwood5) platform, but that code was bogus so I retracted it.
Also, I saw that there are currently several (non-ppc) usb HC drivers
that differ only in platform-specific code at probe and remove time,
so I wanted to avoid that kind of code duplication in the ppc world.
The callback functions are unused today though. I think we should
remove them. We can always add them back if they are needed later.
No need to add asm-ppc/usb.h
Instead, apply the following patch. I'll submit it to linux-usb-devel
tomorrow if no one here complains.
-Dale
This patch removes the reference to asm/usb.h and to the
usb_hcd_platform_data structure it contains. This structure
is currently unused. If we decide it's needed later, we can
add it back.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
--- linux-2.6/drivers/usb/host/ohci-ppc-soc.c.old 2005-08-09 10:46:37.000000000 -0700
+++ linux-2.6/drivers/usb/host/ohci-ppc-soc.c 2005-08-09 11:03:44.000000000 -0700
@@ -14,8 +14,6 @@
* This file is licenced under the GPL.
*/
-#include <asm/usb.h>
-
/* configure so an HC device and id are always provided */
/* always called with process context; sleeping is OK */
@@ -23,9 +21,7 @@
* usb_hcd_ppc_soc_probe - initialize On-Chip HCDs
* Context: !in_interrupt()
*
- * Allocates basic resources for this USB host controller, and
- * then invokes the start() method for the HCD associated with it
- * through the hotplug entry's driver_data.
+ * Allocates basic resources for this USB host controller.
*
* Store this function in the HCD's struct pci_driver as probe().
*/
@@ -37,7 +33,6 @@
struct ohci_hcd *ohci;
struct resource *res;
int irq;
- struct usb_hcd_platform_data *pd = pdev->dev.platform_data;
pr_debug("initializing PPC-SOC USB Controller\n");
@@ -73,9 +68,6 @@
goto err2;
}
- if (pd->start && (retval = pd->start(pdev)))
- goto err3;
-
ohci = hcd_to_ohci(hcd);
ohci->flags |= OHCI_BIG_ENDIAN;
ohci_hcd_init(ohci);
@@ -85,9 +77,7 @@
return retval;
pr_debug("Removing PPC-SOC USB Controller\n");
- if (pd && pd->stop)
- pd->stop(pdev);
- err3:
+
iounmap(hcd->regs);
err2:
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
@@ -105,21 +95,17 @@
* @pdev: USB Host Controller being removed
* Context: !in_interrupt()
*
- * Reverses the effect of usb_hcd_ppc_soc_probe(), first invoking
- * the HCD's stop() method. It is always called from a thread
+ * Reverses the effect of usb_hcd_ppc_soc_probe().
+ * It is always called from a thread
* context, normally "rmmod", "apmd", or something similar.
*
*/
static void usb_hcd_ppc_soc_remove(struct usb_hcd *hcd,
struct platform_device *pdev)
{
- struct usb_hcd_platform_data *pd = pdev->dev.platform_data;
-
usb_remove_hcd(hcd);
pr_debug("stopping PPC-SOC USB Controller\n");
- if (pd && pd->stop)
- pd->stop(pdev);
iounmap(hcd->regs);
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
^ permalink raw reply
* RE: Wall clock accuracy
From: Rune Torgersen @ 2005-08-09 18:21 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
=20
> -----Original Message-----
> From: Eugene Surovegin [mailto:ebs@ebshome.net]=20
> Sent: Tuesday, August 09, 2005 12:21
> Fair enough, why then instead of fixing the root cause you are making=20
> ugly workarounds :) ?
Probably because I did not want to fiddle with the code that did the
original calculation, and I wanted to see if I could get it totally
accurate (for the case where there is not a whole number of ns in a
jiffy).
A proper fix would be for platfrom code to have a way to set time_nsec
instead of having it set by a constant.
I did say in my original email that thencluded code was not a proper
patch but more something to show on how a fix could look like, and to
start a discussion about it.
^ permalink raw reply
* Re: Merging ppc32 and ppc64
From: Tom Rini @ 2005-08-09 17:47 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc64-dev, Geert Uytterhoeven, Arnd Bergmann,
Linux/PPC Development
In-Reply-To: <B154269E-A429-47B3-B088-68C9BECD9A1C@freescale.com>
On Tue, Aug 09, 2005 at 12:41:54PM -0500, Kumar Gala wrote:
>
> On Aug 9, 2005, at 11:21 AM, Tom Rini wrote:
[snip]
> >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.
>
> I'm not sure I follow. I understand that prom_init.c is part of the
> kernel in ppc64. I'm saying that such things should NOT be part of
> the arch/powerpc kernel going forward. They should be handled via
> bootwrappers.
That's a "cleanup" we can argue about later, but I expect some
resistance :)
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: Merging ppc32 and ppc64
From: Kumar Gala @ 2005-08-09 17:41 UTC (permalink / raw)
To: Tom Rini
Cc: linuxppc64-dev, Geert Uytterhoeven, Arnd Bergmann,
Linux/PPC Development
In-Reply-To: <20050809162133.GL3187@smtp.west.cox.net>
On Aug 9, 2005, at 11:21 AM, Tom Rini wrote:
> 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.
I'm not sure I follow. I understand that prom_init.c is part of the
kernel in ppc64. I'm saying that such things should NOT be part of
the arch/powerpc kernel going forward. They should be handled via
bootwrappers.
- kumar
^ permalink raw reply
* Re: Volunteers to test i2c-algo-8xx on v2.6?
From: aris @ 2005-08-09 16:28 UTC (permalink / raw)
To: Tom Rini; +Cc: Joakim Tjernlund, linuxppc-embedded
In-Reply-To: <20050809161801.GK3187@smtp.west.cox.net>
> I've tested this version with my cheesy sttm reader on an rpxlite, and
> with the following, things work:
I already did that in a separate patch, already sent to Marcelo.
thanks anyway!
--
Aristeu
^ permalink raw reply
* Re: Wall clock accuracy
From: Eugene Surovegin @ 2005-08-09 17:20 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859418@ismail.innsys.innovsys.com>
On Tue, Aug 09, 2005 at 12:04:10PM -0500, Rune Torgersen wrote:
>
> My bigger problem with the walltime is that time_nsec should have been
> 1000000, not 999848 to begin with. If it had been, I would probably
> never even have noticed it.
>
> The thing is that that value is set based on a value I cannot find any
> reference as how was chosen. Looks to be a leftover when porting PPC
> fron i386 once upon a time.
>
> time_nsec basically gets is value (via some macros) from
> CLOCK_TICK_RATE, which is defined in asm-ppc/timex.h to be 1193180
>
> In my opinion, time_nsec should have been calculated based on the actual
> clock input rate to begin with (like in calibrate_decrementer()).
Fair enough, why then instead of fixing the root cause you are making
ugly workarounds :) ?
--
Eugene
^ permalink raw reply
* RE: pci_enable_device fails on MPC8541
From: Bizhan Gholikhamseh (bgholikh) @ 2005-08-09 17:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]
Hi Kumar,
I am using Linux 2.6.11, u-boot 1.1.2.
I see failure in pci_enable_device with message:
"PCI: Device 0000:02:01.0 not available because of resource collisions"
I have attached three files:
lspci_output.txt: out put of the "lspci -v"
proc_pci.txt: output of the "cat /proc/pci"
u-boot.txt: output of the "pci command at u-boot"
Any help greatly appreciated,
Bizhan
-----Original Message-----
From: Kumar Gala [mailto:kumar.gala@freescale.com]
Sent: Monday, August 08, 2005 1:34 PM
To: Bizhan Gholikhamseh (bgholikh)
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: pci_enable_device fails on MPC8541
Bizhan,
A few questions:
1. what kernel version are you using on these boards:
2. can you do an lspci -v on the boards
- kumar
On Aug 8, 2005, at 1:12 PM, Bizhan Gholikhamseh \(((bgholikh\))) wrote:
> Hi All,
> I am using two evaluation board from freescale, 8540ADS and MPC8541.
> The same PCI driver is being compiled and loaded on both platforms.
> The same PCI driver (developed by me) for DSP board compiled and
> loaded on both platforms.
>
> When I type: "insmod C6415.ko" on 8541 board, I get the following
> error:
> "PCI: Device 0000:02:01.0 not available because of resource
> collisions"
> This messages is because of the execution of the generic PCI Linux
> command:
> "pci_enable_device(pdev)"
> The same API has no problem on 8540ADS.
>
>
>> From UBOOT I can see my device is on bus 3:
>>
> => pci 3
> Scanning PCI devices on bus 3
> BusDev FUN VendorID DeviceID Device Class Sub-Class
> ----------------------------------------------------------------------
> --
> --------------------
> 03.01.00 0x104c 0xa106 .........
>
> Any idea why the insmod fails on one board and not on the other one?
>
> Many thanks in advance,
> Bizhan
>
> <ATT2118305.txt>
>
[-- Attachment #2: lspci_output.txt --]
[-- Type: text/plain, Size: 2227 bytes --]
# lspci -v
00:11.0 Class 0604: 10e3:0513
Flags: bus master, 66Mhz, medium devsel, latency 128
Memory at 9ffff000 (32-bit, non-prefetchable)
Bus: primary=00, secondary=01, subordinate=01, sec-latency=255
Memory behind bridge: 9fe00000-9fefffff
Prefetchable memory behind bridge: 000000009fd00000-000000009fd00000
00:15.0 Class 0604: 104c:ac28 (rev 02)
Flags: bus master, medium devsel, latency 128
Bus: primary=00, secondary=02, subordinate=02, sec-latency=226
Memory behind bridge: 9f000000-9fcfffff
Prefetchable memory behind bridge: 000000009ef00000-000000009ef00000
Secondary status: SERR
01:02.0 Class 0601: 1106:0686 (rev 40)
Flags: bus master, stepping, medium devsel, latency 0, IRQ 98
Capabilities: [c0] Power Management version 2
01:02.1 Class 0101: 1106:0571 (rev 06) (prog-if 8a)
Flags: stepping, medium devsel, IRQ 98
I/O ports at cc00
Capabilities: [c0] Power Management version 2
01:02.2 Class 0c03: 1106:3038 (rev 1d)
Subsystem: 0925:1234
Flags: bus master, medium devsel, latency 128, IRQ 97
I/O ports at ffe0
Capabilities: [80] Power Management version 2
01:02.3 Class 0c03: 1106:3038 (rev 1d)
Subsystem: 0925:1234
Flags: bus master, medium devsel, latency 128, IRQ 97
I/O ports at ffc0
Capabilities: [80] Power Management version 2
01:02.4 Class 0000: 1106:3057 (rev 40)
Flags: medium devsel, IRQ 98
Capabilities: [68] Power Management version 2
01:02.5 Class 0401: 1106:3058 (rev 50)
Flags: medium devsel, IRQ 96
I/O ports at fe00
I/O ports at fdfc
I/O ports at fdf8
Capabilities: [c0] Power Management version 2
01:02.6 Class 0780: 1106:3068 (rev 30)
Flags: medium devsel, IRQ 96
I/O ports at fc00
Capabilities: [d0] Power Management version 2
02:01.0 Class 0000: 104c:a106 (rev 01)
Flags: bus master, medium devsel, latency 128, IRQ 96
Memory at 9f800000 (32-bit, prefetchable)
Memory at 9f000000 (32-bit, non-prefetchable)
I/O ports at <ignored>
Capabilities: [40] Power Management version 2
[-- Attachment #3: proc_pci.txt --]
[-- Type: text/plain, Size: 1995 bytes --]
# cat /proc/pci
PCI devices found:
Bus 0, device 17, function 0:
PCI bridge: PCI device 10e3:0513 (Tundra Semiconductor Corp.) (rev 0).
IRQ 96.
Master Capable. Latency=128.
Non-prefetchable 32 bit memory at 0x9ffff000 [0x9fffffff].
Bus 0, device 21, function 0:
PCI bridge: Texas Instruments PCI2050 PCI-to-PCI Bridge (rev 2).
IRQ 99.
Master Capable. Latency=128. Max Lat=4.
Bus 1, device 2, function 0:
ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 64).
IRQ 98.
Bus 1, device 2, function 1:
IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Mast. IRQ 98.
I/O at 0xcc00 [0xcc0f].
Bus 1, device 2, function 2:
USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 29).
IRQ 97.
Master Capable. Latency=128.
I/O at 0xffe0 [0xffff].
Bus 1, device 2, function 3:
USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (#2) (rev 29).
IRQ 97.
Master Capable. Latency=128.
I/O at 0xffc0 [0xffdf].
Bus 1, device 2, function 4:
Non-VGA unclassified device: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 6. IRQ 98.
Bus 1, device 2, function 5:
Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev. IRQ 96.
I/O at 0xfe00 [0xfeff].
I/O at 0xfdfc [0xfdff].
I/O at 0xfdf8 [0xfdfb].
Bus 1, device 2, function 6:
Communication controller: VIA Technologies, Inc. Intel 537 [AC97 Modem] (rev 48).
IRQ 96.
I/O at 0xfc00 [0xfcff].
Bus 2, device 1, function 0:
Non-VGA unclassified device: Texas Instruments TMS320C6205 Fixed Point DSP (rev 1).
IRQ 96.
Master Capable. Latency=128.
Prefetchable 32 bit memory at 0x9f800000 [0x9fbfffff].
Non-prefetchable 32 bit memory at 0x9f000000 [0x9f7fffff].
I/O at 0x0 [0xf].
[-- Attachment #4: u-boot.txt --]
[-- Type: text/plain, Size: 1297 bytes --]
=> pci 3
Scanning PCI devices on bus 3
BusDevFun VendorId DeviceId Device Class Sub-Class
_____________________________________________________________
03.01.00 0x104c 0xa106 Build before PCI Rev2.0 0x00
=> pci header 03.01.00
vendor ID = 0x104c
device ID = 0xa106
command register = 0x0007
status register = 0x0210
revision ID = 0x01
class code = 0x00 (Build before PCI Rev2.0)
sub class code = 0x00
programming interface = 0x00
cache line = 0x08
latency time = 0x80
header type = 0x00
BIST = 0x00
base address 0 = 0x81000008
base address 1 = 0x81800000
base address 2 = 0xe2004001
base address 3 = 0x00000000
base address 4 = 0x00000000
base address 5 = 0x00000000
cardBus CIS pointer = 0x00000000
sub system vendor ID = 0x0000
sub system ID = 0x0000
expansion ROM base address = 0x00000000
interrupt line = 0x60
interrupt pin = 0x01
min Grant = 0x00
max Latency = 0x00
^ permalink raw reply
* Re: Volunteers to test i2c-algo-8xx on v2.6?
From: aris @ 2005-08-09 16:29 UTC (permalink / raw)
To: Tom Rini; +Cc: Joakim Tjernlund, linuxppc-embedded
In-Reply-To: <20050809161801.GK3187@smtp.west.cox.net>
> 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?
--
Aristeu
^ permalink raw reply
* Re: open() returns 0.
From: Josh Boyer @ 2005-08-09 17:19 UTC (permalink / raw)
To: Jayaprakash Shanmugam; +Cc: linuxppc-embedded
In-Reply-To: <17f142e1050809080053187f40@mail.gmail.com>
> 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.
Does your program close all it's file descriptors before opening the i2c
device? 0 is a valid file descriptor. It's just normally used by STDIN.
If a program closes or doesn't inherit STDIN for some reason, 0 becomes
available.
josh
^ permalink raw reply
* FW: Wall clock accuracy
From: Rune Torgersen @ 2005-08-09 17:06 UTC (permalink / raw)
To: linuxppc-embedded
> -----Original Message-----
> From: Eugene Surovegin [mailto:ebs@ebshome.net]=20
> Sent: Tuesday, August 09, 2005 12:03
> > Well, NTPD doesn't mean you need to have network=20
> connectivity, IIRC if=20
> > you have exact frequency source, you can add it to NTPD and=20
> it'll use=20
> > it to correct drift.
Well, my accurate timesource is the busclock to the CPU, so my timer
interrupt is running at a correct rate. xtime is just updated wrong.
^ permalink raw reply
* RE: Wall clock accuracy
From: Rune Torgersen @ 2005-08-09 17:04 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
Sorry for double post...
=20
> -----Original Message-----
> From: Eugene Surovegin [mailto:ebs@ebshome.net]=20
> Sent: Tuesday, August 09, 2005 11:41
> It's not small drift (I usually have clock accuracy within +-50ppm),=20
> but still is much less than maximum 1024ppm NTPD can deal with.
My bigger problem with the walltime is that time_nsec should have been
1000000, not 999848 to begin with. If it had been, I would probably
never even have noticed it.
The thing is that that value is set based on a value I cannot find any
reference as how was chosen. Looks to be a leftover when porting PPC
fron i386 once upon a time.
time_nsec basically gets is value (via some macros) from
CLOCK_TICK_RATE, which is defined in asm-ppc/timex.h to be 1193180
In my opinion, time_nsec should have been calculated based on the actual
clock input rate to begin with (like in calibrate_decrementer()).
^ permalink raw reply
* Re: Wall clock accuracy
From: Eugene Surovegin @ 2005-08-09 17:02 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded
In-Reply-To: <20050809165957.GE22053@gate.ebshome.net>
On Tue, Aug 09, 2005 at 09:59:57AM -0700, Eugene Surovegin wrote:
> 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.
To rephrase this - Linux kernel already has infrastructure for
precision time keeping, just use it (even without NTPD) and don't add
any CPU-specific hacks :).
--
Eugene
^ permalink raw reply
* 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
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