- 17 10月, 2007 3 次提交
-
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
There were no users - and why have a private version anyway. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
It was plain a bad idea ... Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 12 10月, 2007 1 次提交
-
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 07 2月, 2007 2 次提交
-
-
由 Alexander Bigga 提交于
The problem was introduced in 2.6.18.3 with the casting of some 36bit-defines (PCI memory) in au1000.h to resource_size_t which may be u32 or u64 depending on the experimental CONFIG_RESOURCES_64BIT. With unset CONFIG_RESOURCES_64BIT, the pci-memory cannot be accessed because the ioremap in arch/mips/au1000/common/pci.c already used the truncated addresses. With set CONFIG_RESOURCES_64BIT, things get even worse, because PCI-scan aborts, due to resource conflict: request_resource() in arch/mips/pci/pci.c fails because the maximum iomem-address is 0xffffffff (32bit) but the pci-memory-start-address is 0x440000000 (36bit). To get pci working again, I propose the following patch: 1. remove the resource_size_t-casting from au1000.h again 2. make the casting in arch/mips/au1000/common/pci.c (it's allowed and necessary here. The 36bit-handling will be done in __fixup_bigphys_addr). With this patch pci works again like in 2.6.18.2, the gcc-compile warnings in pci.c are gone and it doesn't depend on CONFIG_EXPERIMENTAL. Signed-off-by: NAlexander Bigga <ab@mycable.de> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Ralf Baechle 提交于
CC arch/mips/au1000/common/pci.o arch/mips/au1000/common/pci.c:42: warning: large integer implicitly truncated to unsigned type arch/mips/au1000/common/pci.c:43: warning: large integer implicitly truncated to unsigned type arch/mips/au1000/common/pci.c:49: warning: large integer implicitly truncated to unsigned type arch/mips/au1000/common/pci.c:50: warning: large integer implicitly truncated to unsigned type arch/mips/au1000/common/pci.c: In function ‘au1x_pci_setup’: arch/mips/au1000/common/pci.c:82: warning: ISO C90 forbids mixed declarations and code Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 26 4月, 2006 1 次提交
-
-
由 David Woodhouse 提交于
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
-
- 07 2月, 2006 1 次提交
-
-
由 Sergei Shtylylov 提交于
AMD Au1200 SOC just doesn't have UART3, so KGDB won't even compile for it as is, here's the fix to make KGDB use UART1. Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 10 1月, 2006 1 次提交
-
-
由 Sergei Shtylyov 提交于
USB OpenHCI host controller on Au1550 only decodes memory addresses from 0x14020000 to 0x1407FFFF according to the databook, which gives 0x60000 (on the prior Au1x00 chips the map size was 1MB). Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com> Acked-by: NJordan Crouse <jordan.crouse@amd.com> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 30 10月, 2005 5 次提交
-
-
由 Pete Popov 提交于
generic one. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Pete Popov 提交于
* remove two already unused and commented structures * added an ULL suffix to several address constants that use bits 35-32 Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Pete Popov 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org> Acked-by: NAntonino Daplas <adaplas@pol.net>
-
由 Pete Popov 提交于
Cleaned up a to of warnings in dbdma.c. Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Pete Popov 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 05 9月, 2005 1 次提交
-
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-