* [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
* 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
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