Re: [PATCH4/4] [POWERPC] Fix cpm_uart driver
On Sep 24, 2007, at 11:22 AM, Scott Wood wrote: cpmp is a physical address on arch/ppc? No, it's a well known ioremaped() address into the IMMR space. The only physical addresses in any of the CPM/CPM2 are those required to by the buffer descriptors. There are DPRAM offsets, but they should be just that, offsets from either a virtual or physical base address as required. Too many people screw around in this CPM support code without fully understanding the original implementation or its intended use with the peripheral drivers. A "better idea" often breaks all drivers except the one that is being changed. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH4/4] [POWERPC] Fix cpm_uart driver
On Sep 24, 2007, at 11:22 AM, Scott Wood wrote: cpmp is a physical address on arch/ppc? No, it's a well known ioremaped() address into the IMMR space. The only physical addresses in any of the CPM/CPM2 are those required to by the buffer descriptors. There are DPRAM offsets, but they should be just that, offsets from either a virtual or physical base address as required. Too many people screw around in this CPM support code without fully understanding the original implementation or its intended use with the peripheral drivers. A better idea often breaks all drivers except the one that is being changed. -- Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC: 2.6 patch] powerpc: remove the unused HTDMSOUND driver
On Mar 26, 2007, at 7:52 PM, Marcelo Tosatti wrote: Shall this driver be removed? May as well. I'm probably the only one in the world with the hardware. If I need a driver I'll just write another one :-) Thanks. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC: 2.6 patch] powerpc: remove the unused HTDMSOUND driver
On Mar 26, 2007, at 7:52 PM, Marcelo Tosatti wrote: Shall this driver be removed? May as well. I'm probably the only one in the world with the hardware. If I need a driver I'll just write another one :-) Thanks. -- Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
Since I'm probably the only one that really uses the driver for custom uses and cares.. On Mar 1, 2007, at 10:55 AM, Timur Tabi wrote: Ok guys, I need a consensus here. Are we going to allocate a second block of 4 minor numbers for the QE/CPM UART or not? not. My driver already has a macro that limits the number of UARTS to 4, perfect. I'll add a second TTY struct... Don't worry about it for now. We'll just keep this in mind when we make a major change someday in the future. We may have a better solution then. Thanks. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 5:08 PM, Segher Boessenkool wrote: Since you say no one has ever used more than 4 UARTs, there are two options: People have used more than 4, but we just allocated the additional /dev entries to cover them. I know of only one time this has happened. It's such a custom case that the other device names didn't matter. - Cap the driver at 4 UARTs; Let's do this, but design the code to allow more by just changing a #define. Just randomly using some extra minors that aren't assigned to you isn't such a great idea. Maybe for a desktop or generic server where you don't know what's going to be configured, but it's not unusual to do so with custom embedded systems. The small experimental or user allocations often don't cover what is needed, so we just grab some allocation from a device that isn't ever going to be used on the system. Thanks. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 5:08 PM, Segher Boessenkool wrote: Since you say no one has ever used more than 4 UARTs, there are two options: People have used more than 4, but we just allocated the additional /dev entries to cover them. I know of only one time this has happened. It's such a custom case that the other device names didn't matter. - Cap the driver at 4 UARTs; Let's do this, but design the code to allow more by just changing a #define. Just randomly using some extra minors that aren't assigned to you isn't such a great idea. Maybe for a desktop or generic server where you don't know what's going to be configured, but it's not unusual to do so with custom embedded systems. The small experimental or user allocations often don't cover what is needed, so we just grab some allocation from a device that isn't ever going to be used on the system. Thanks. -- Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
Since I'm probably the only one that really uses the driver for custom uses and cares.. On Mar 1, 2007, at 10:55 AM, Timur Tabi wrote: Ok guys, I need a consensus here. Are we going to allocate a second block of 4 minor numbers for the QE/CPM UART or not? not. My driver already has a macro that limits the number of UARTS to 4, perfect. I'll add a second TTY struct... Don't worry about it for now. We'll just keep this in mind when we make a major change someday in the future. We may have a better solution then. Thanks. -- Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 2:43 PM, Timur Tabi wrote: What about major number 205? It also has the screwed-up /dev/ ttyCPM entries, but it has more room, and the CPM driver doesn't actually use it. At least, I can't see where it uses it. Please, let's just leave the four we have and let the driver just allocate increasing minor numbers. If anyone has a product with more than 4 UARTs, they will have to figure out what to do with the additional minors. We are making a very complicated problem out of nothing. This hasn't caused any problems in the past, and changing the existing names and minors will cause problems for everyone today. Just leave it alone, fix up the documentation, and have the driver print some warning if it allocates more than 4 UARTs. Thanks. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 12:35 PM, Timur Tabi wrote: An alternative idea, which one person already shot down, was to allow only 4 devices normally, but allow more devices if you use udev, since udev doesn't care about minor number assignments. This eliminates the overlap and encourages people to use udev. I'd shoot that down, too. Using udev in an embedded, reliable environment is very troublesome. Although, products I've developed using more than 4 UARTs had some custom /dev work done to it just to get everything mapped. My only concern is we don't add a new range for QE UARTs, that we use the same minors for both CPM and QE. Thanks. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 12:04 PM, Timur Tabi wrote: ... However, ttyCPM0 is currently assigned to 46, and device 50 is an Altix serial card. The only way to give the CPM 6 or 8 slots without moving it is to overlap the Altix card. Then, this is currently broken in all cases and needs to be fixed since the CPM/CPM2 could have up to six UART ports. Now I don't know anything about the Altix card, so I don't know if it's possible to use that card on a system with a CPM or a QE. If it isn't, then I don't know if overlapping minor numbers is still a problem. I don't think that would be a problem, and I'd like the CPM/QE to share devices because it makes the software distributions common to all Freescale embedded processors. If we move CPM/QE to 192, then I can change the CPM device driver to reflect that, but I don't know what that means for older kernels. That would be bad. It has nothing to do with the kernel, but we have finally survived the distribution updates to ttyCPM, and I don't want to go through that again just because of QE. Thanks. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 9:54 AM, Segher Boessenkool wrote: 46 = /dev/ttyCPM0PPC CPM (SCC or SMC) - port 0 ... - 47 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5 + 49 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5 If CPM0 is 46, then CPM5 is not 47, but not 49 either. Unless it's not CPM5 but CPM3? Honestly, I don't know. I was just correcting the obvious typo (47 instead of 49). It's obvious it shouldn't be 47, but it's not obvious it should be 49 instead. I don't know the origin of this thread, but none of that looks correct. Today, there can be up to 8 CPM UART devices, 6 on CPM/CPM2 and 8 on the QE. If ttyCPM0 starts at minor 46, they should be at least monotonically incrementing up to ttyCPM7 with minor 53. Thanks. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 9:54 AM, Segher Boessenkool wrote: 46 = /dev/ttyCPM0PPC CPM (SCC or SMC) - port 0 ... - 47 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5 + 49 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5 If CPM0 is 46, then CPM5 is not 47, but not 49 either. Unless it's not CPM5 but CPM3? Honestly, I don't know. I was just correcting the obvious typo (47 instead of 49). It's obvious it shouldn't be 47, but it's not obvious it should be 49 instead. I don't know the origin of this thread, but none of that looks correct. Today, there can be up to 8 CPM UART devices, 6 on CPM/CPM2 and 8 on the QE. If ttyCPM0 starts at minor 46, they should be at least monotonically incrementing up to ttyCPM7 with minor 53. Thanks. -- Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 12:04 PM, Timur Tabi wrote: ... However, ttyCPM0 is currently assigned to 46, and device 50 is an Altix serial card. The only way to give the CPM 6 or 8 slots without moving it is to overlap the Altix card. Then, this is currently broken in all cases and needs to be fixed since the CPM/CPM2 could have up to six UART ports. Now I don't know anything about the Altix card, so I don't know if it's possible to use that card on a system with a CPM or a QE. If it isn't, then I don't know if overlapping minor numbers is still a problem. I don't think that would be a problem, and I'd like the CPM/QE to share devices because it makes the software distributions common to all Freescale embedded processors. If we move CPM/QE to 192, then I can change the CPM device driver to reflect that, but I don't know what that means for older kernels. That would be bad. It has nothing to do with the kernel, but we have finally survived the distribution updates to ttyCPM, and I don't want to go through that again just because of QE. Thanks. -- Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 12:35 PM, Timur Tabi wrote: An alternative idea, which one person already shot down, was to allow only 4 devices normally, but allow more devices if you use udev, since udev doesn't care about minor number assignments. This eliminates the overlap and encourages people to use udev. I'd shoot that down, too. Using udev in an embedded, reliable environment is very troublesome. Although, products I've developed using more than 4 UARTs had some custom /dev work done to it just to get everything mapped. My only concern is we don't add a new range for QE UARTs, that we use the same minors for both CPM and QE. Thanks. -- Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lanana: Add major/minor entries for PPC QE UART devices
On Feb 28, 2007, at 2:43 PM, Timur Tabi wrote: What about major number 205? It also has the screwed-up /dev/ ttyCPM entries, but it has more room, and the CPM driver doesn't actually use it. At least, I can't see where it uses it. Please, let's just leave the four we have and let the driver just allocate increasing minor numbers. If anyone has a product with more than 4 UARTs, they will have to figure out what to do with the additional minors. We are making a very complicated problem out of nothing. This hasn't caused any problems in the past, and changing the existing names and minors will cause problems for everyone today. Just leave it alone, fix up the documentation, and have the driver print some warning if it allocates more than 4 UARTs. Thanks. -- Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ppc32 :Added PCI support for MPC83xx
On Aug 29, 2005, at 11:02 PM, Li Tony-r64360 wrote: I think it is OK. The external interrupt can be edged. And it works well in my board. No, it can't. PCI interrupts must be level sensitive because multiple slots can share an interrupt. Thanks. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ppc32 :Added PCI support for MPC83xx
On Aug 29, 2005, at 11:02 PM, Li Tony-r64360 wrote: I think it is OK. The external interrupt can be edged. And it works well in my board. No, it can't. PCI interrupts must be level sensitive because multiple slots can share an interrupt. Thanks. -- Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ppc32 :Added PCI support for MPC83xx
On Aug 29, 2005, at 1:42 PM, Kumar Gala wrote:
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.c
b/arch/ppc/platforms/83xx/mpc834x_sys.c
--- a/arch/ppc/platforms/83xx/mpc834x_sys.c
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.c
@@ -62,9 +62,29 @@ extern unsigned long total_memory; /* in
unsigned char __res[sizeof (bd_t)];
#ifdef CONFIG_PCI
-#error "PCI is not supported"
-/* NEED mpc83xx_map_irq & mpc83xx_exclude_device
- see platforms/85xx/mpc85xx_ads_common.c */
+int
+mpc83xx_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned
char pin)
+{
+ static char pci_irq_table[][4] =
+ /*
+* PCI IDSEL/INTPIN->INTLINE
+* A B C D
+*/
+ {
+ {PIRQA, PIRQB, PIRQC, PIRQD}, /* idsel 0x11 */
+ {PIRQC, PIRQD, PIRQA, PIRQB}, /* idsel 0x12 */
+ {PIRQD, PIRQA, PIRQB, PIRQC} /* idsel 0x13 */
+ };
+
+ const long min_idsel = 0x11, max_idsel = 0x13, irqs_per_slot = 4;
+ return PCI_IRQ_TABLE_LOOKUP;
+}
+
+int
+mpc83xx_exclude_device(u_char bus, u_char devfn)
+{
+ return PCIBIOS_SUCCESSFUL;
+}
#endif /* CONFIG_PCI */
Shouldn't this be in the PQ2FADS board specific file? Not everyone
is going to map IDSELs and IRQs this way.
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.h
b/arch/ppc/platforms/83xx/mpc834x_sys.h
--- a/arch/ppc/platforms/83xx/mpc834x_sys.h
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.h
@@ -26,7 +26,7 @@
#define VIRT_IMMRBAR ((uint)0xfe00)
#define BCSR_PHYS_ADDR ((uint)0xf800)
-#define BCSR_SIZE ((uint)(32 * 1024))
+#define BCSR_SIZE ((uint)(128 * 1024))
#define BCSR_MISC_REG2_OFF 0x07
#define BCSR_MISC_REG2_PORESET 0x01
@@ -34,23 +34,25 @@
#define BCSR_MISC_REG3_OFF 0x08
#define BCSR_MISC_REG3_CNFLOCK 0x80
-#ifdef CONFIG_PCI
-/* PCI interrupt controller */
-#define PIRQAMPC83xx_IRQ_IRQ4
-#define PIRQBMPC83xx_IRQ_IRQ5
-#define PIRQCMPC83xx_IRQ_IRQ6
-#define PIRQDMPC83xx_IRQ_IRQ7
-
-#define MPC834x_SYS_PCI1_LOWER_IO0x
-#define MPC834x_SYS_PCI1_UPPER_IO0x00ff
-
-#define MPC834x_SYS_PCI1_LOWER_MEM 0x8000
-#define MPC834x_SYS_PCI1_UPPER_MEM 0x9fff
-
-#define MPC834x_SYS_PCI1_IO_BASE 0xe200
-#define MPC834x_SYS_PCI1_MEM_OFFSET 0x
-
-#define MPC834x_SYS_PCI1_IO_SIZE 0x0100
-#endif /* CONFIG_PCI */
+#define PIRQA MPC83xx_IRQ_EXT4
+#define PIRQB MPC83xx_IRQ_EXT5
+#define PIRQC MPC83xx_IRQ_EXT6
+#define PIRQD MPC83xx_IRQ_EXT7
The same thing with these BCSRs and IRQ mappings FADS specific.
+
+#define MPC83xx_PCI1_LOWER_IO 0x
+#define MPC83xx_PCI1_UPPER_IO 0x00ff
+#define MPC83xx_PCI1_LOWER_MEM 0x8000
+#define MPC83xx_PCI1_UPPER_MEM 0x9fff
+#define MPC83xx_PCI1_IO_BASE 0xe200
+#define MPC83xx_PCI1_MEM_OFFSET0x
+#define MPC83xx_PCI1_IO_SIZE 0x0100
+
+#define MPC83xx_PCI2_LOWER_IO 0x
+#define MPC83xx_PCI2_UPPER_IO 0x00ff
+#define MPC83xx_PCI2_LOWER_MEM 0xa000
+#define MPC83xx_PCI2_UPPER_MEM 0xbfff
+#define MPC83xx_PCI2_IO_BASE 0xe300
+#define MPC83xx_PCI2_MEM_OFFSET0x
+#define MPC83xx_PCI2_IO_SIZE 0x0100
These should be generic to everyone, and could be
in the ppc83xx_pci.h file. Maybe surround them with
#ifndef so a board specific file could move the addresses
if they wanted? I don't think an #ifndef is needed for each
define, maybe just #fndef MPC83xx_PCI1_LOWER_MEM
and let the board define everything if they want anything different.
Thanks.
-- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ppc32 :Added PCI support for MPC83xx
On Aug 29, 2005, at 1:42 PM, Kumar Gala wrote:
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.c
b/arch/ppc/platforms/83xx/mpc834x_sys.c
--- a/arch/ppc/platforms/83xx/mpc834x_sys.c
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.c
@@ -62,9 +62,29 @@ extern unsigned long total_memory; /* in
unsigned char __res[sizeof (bd_t)];
#ifdef CONFIG_PCI
-#error PCI is not supported
-/* NEED mpc83xx_map_irq mpc83xx_exclude_device
- see platforms/85xx/mpc85xx_ads_common.c */
+int
+mpc83xx_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned
char pin)
+{
+ static char pci_irq_table[][4] =
+ /*
+* PCI IDSEL/INTPIN-INTLINE
+* A B C D
+*/
+ {
+ {PIRQA, PIRQB, PIRQC, PIRQD}, /* idsel 0x11 */
+ {PIRQC, PIRQD, PIRQA, PIRQB}, /* idsel 0x12 */
+ {PIRQD, PIRQA, PIRQB, PIRQC} /* idsel 0x13 */
+ };
+
+ const long min_idsel = 0x11, max_idsel = 0x13, irqs_per_slot = 4;
+ return PCI_IRQ_TABLE_LOOKUP;
+}
+
+int
+mpc83xx_exclude_device(u_char bus, u_char devfn)
+{
+ return PCIBIOS_SUCCESSFUL;
+}
#endif /* CONFIG_PCI */
Shouldn't this be in the PQ2FADS board specific file? Not everyone
is going to map IDSELs and IRQs this way.
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.h
b/arch/ppc/platforms/83xx/mpc834x_sys.h
--- a/arch/ppc/platforms/83xx/mpc834x_sys.h
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.h
@@ -26,7 +26,7 @@
#define VIRT_IMMRBAR ((uint)0xfe00)
#define BCSR_PHYS_ADDR ((uint)0xf800)
-#define BCSR_SIZE ((uint)(32 * 1024))
+#define BCSR_SIZE ((uint)(128 * 1024))
#define BCSR_MISC_REG2_OFF 0x07
#define BCSR_MISC_REG2_PORESET 0x01
@@ -34,23 +34,25 @@
#define BCSR_MISC_REG3_OFF 0x08
#define BCSR_MISC_REG3_CNFLOCK 0x80
-#ifdef CONFIG_PCI
-/* PCI interrupt controller */
-#define PIRQAMPC83xx_IRQ_IRQ4
-#define PIRQBMPC83xx_IRQ_IRQ5
-#define PIRQCMPC83xx_IRQ_IRQ6
-#define PIRQDMPC83xx_IRQ_IRQ7
-
-#define MPC834x_SYS_PCI1_LOWER_IO0x
-#define MPC834x_SYS_PCI1_UPPER_IO0x00ff
-
-#define MPC834x_SYS_PCI1_LOWER_MEM 0x8000
-#define MPC834x_SYS_PCI1_UPPER_MEM 0x9fff
-
-#define MPC834x_SYS_PCI1_IO_BASE 0xe200
-#define MPC834x_SYS_PCI1_MEM_OFFSET 0x
-
-#define MPC834x_SYS_PCI1_IO_SIZE 0x0100
-#endif /* CONFIG_PCI */
+#define PIRQA MPC83xx_IRQ_EXT4
+#define PIRQB MPC83xx_IRQ_EXT5
+#define PIRQC MPC83xx_IRQ_EXT6
+#define PIRQD MPC83xx_IRQ_EXT7
The same thing with these BCSRs and IRQ mappings FADS specific.
+
+#define MPC83xx_PCI1_LOWER_IO 0x
+#define MPC83xx_PCI1_UPPER_IO 0x00ff
+#define MPC83xx_PCI1_LOWER_MEM 0x8000
+#define MPC83xx_PCI1_UPPER_MEM 0x9fff
+#define MPC83xx_PCI1_IO_BASE 0xe200
+#define MPC83xx_PCI1_MEM_OFFSET0x
+#define MPC83xx_PCI1_IO_SIZE 0x0100
+
+#define MPC83xx_PCI2_LOWER_IO 0x
+#define MPC83xx_PCI2_UPPER_IO 0x00ff
+#define MPC83xx_PCI2_LOWER_MEM 0xa000
+#define MPC83xx_PCI2_UPPER_MEM 0xbfff
+#define MPC83xx_PCI2_IO_BASE 0xe300
+#define MPC83xx_PCI2_MEM_OFFSET0x
+#define MPC83xx_PCI2_IO_SIZE 0x0100
These should be generic to everyone, and could be
in the ppc83xx_pci.h file. Maybe surround them with
#ifndef so a board specific file could move the addresses
if they wanted? I don't think an #ifndef is needed for each
define, maybe just #fndef MPC83xx_PCI1_LOWER_MEM
and let the board define everything if they want anything different.
Thanks.
-- Dan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ppc32: CPM2 PIC cleanup irq_to_siubit array
On Mar 29, 2005, at 5:30 PM, Kumar Gala wrote: Cleaned up irq_to_siubit array so we no longer need to do 1 << (31-bit), just 1 << bit. Will you please put a comment in here that indicates this array now has this computation done? When I wrote it, these bit numbers matched the registers and the documentation, so I didn't take the time to explain. :-) Thanks. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ppc32: CPM2 PIC cleanup irq_to_siubit array
On Mar 29, 2005, at 5:30 PM, Kumar Gala wrote: Cleaned up irq_to_siubit array so we no longer need to do 1 (31-bit), just 1 bit. Will you please put a comment in here that indicates this array now has this computation done? When I wrote it, these bit numbers matched the registers and the documentation, so I didn't take the time to explain. :-) Thanks. -- Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question on symbol exports
On Feb 7, 2005, at 4:35 PM, Benjamin Herrenschmidt wrote: Interesting... more than no swap, you must also make sure you have no r/w mmap'ed file (which are technically equivalent to swap). Yeah, I kinda had a similar thought. Just because you aren't swapping doesn't mean the VM subsystem isn't looking at dirty bits, too. It could potentially steal a page that it thinks can be replaced from either a zero-fill or reading again from persistent storage. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: question on symbol exports
On Feb 7, 2005, at 4:35 PM, Benjamin Herrenschmidt wrote: Interesting... more than no swap, you must also make sure you have no r/w mmap'ed file (which are technically equivalent to swap). Yeah, I kinda had a similar thought. Just because you aren't swapping doesn't mean the VM subsystem isn't looking at dirty bits, too. It could potentially steal a page that it thinks can be replaced from either a zero-fill or reading again from persistent storage. -- Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add AMD Geode processor support
On Jan 31, 2005, at 11:01 AM, Alan Cox wrote: Also you might not want to magically force settings like highmem because you want that for multi-target kernels - Geode is a sort of odd case where it almost makes sense but its different enough to make me dubious. I've already taken that out. In fact, I've decided to wait until I get the 2.6 done first, then go back and properly update for 2.4. This was just a patch that has been around for a while, I just wanted to get it off of my plate so I could do a minor update later, but I'll just wait. Apologies for the wasted bandwidth. Thanks. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add AMD Geode processor support
On Jan 31, 2005, at 11:01 AM, Alan Cox wrote: Also you might not want to magically force settings like highmem because you want that for multi-target kernels - Geode is a sort of odd case where it almost makes sense but its different enough to make me dubious. I've already taken that out. In fact, I've decided to wait until I get the 2.6 done first, then go back and properly update for 2.4. This was just a patch that has been around for a while, I just wanted to get it off of my plate so I could do a minor update later, but I'll just wait. Apologies for the wasted bandwidth. Thanks. -- Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add AMD Geode processor support
On Jan 27, 2005, at 9:15 AM, Pavel Machek wrote: We do not disable HIGHMEM_64GB for 486, I do not see why we should add extra code to geode... What about some of the other ones like MTRR and IOAPIC? I was kinda passing this along from someone I thought knew better than I, but I didn't like it either. It seems just setting these booleans to 'n' should do the trick. Thanks. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add AMD NS 5535 support
On Jan 27, 2005, at 1:39 AM, Andi Kleen wrote: How about you first submit all these patches for 2.6? I know. They are on the way. I was passing these patches through (with some minor fixing) from AMD as part of another project we are working on. It doesn't make much sense to add new features to 2.4 that are not in 2.6, especially not at the current state of 2.4 (deep code freeze) I understand. Thanks. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add AMD NS 5535 support
On Jan 27, 2005, at 1:39 AM, Andi Kleen wrote: How about you first submit all these patches for 2.6? I know. They are on the way. I was passing these patches through (with some minor fixing) from AMD as part of another project we are working on. It doesn't make much sense to add new features to 2.4 that are not in 2.6, especially not at the current state of 2.4 (deep code freeze) I understand. Thanks. -- Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add AMD Geode processor support
On Jan 27, 2005, at 9:15 AM, Pavel Machek wrote: We do not disable HIGHMEM_64GB for 486, I do not see why we should add extra code to geode... What about some of the other ones like MTRR and IOAPIC? I was kinda passing this along from someone I thought knew better than I, but I didn't like it either. It seems just setting these booleans to 'n' should do the trick. Thanks. -- Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] add AMD NS 5535 support
Hi Marcelo. This patch for 2.4 adds support for the AMD / National Semiconductor CS5535 chip set. Provided by AMD as part of the Geode support. Signed-off-by: Dan Malek <[EMAIL PROTECTED]> amdns_5535.patch Description: Binary data
[PATCH] add AMD Geode processor support
Hi Marcelo! Here is a patch for 2.4 that adds the basic AMD Geode GX2/GX3 and GX1/SC1200 support. This patch updates configuration scripts, defconfig, and setup files. Signed-off-by: Dan Malek <[EMAIL PROTECTED]> geode_x86.patch Description: Binary data
[PATCH] add AMD Geode processor support
Hi Marcelo! Here is a patch for 2.4 that adds the basic AMD Geode GX2/GX3 and GX1/SC1200 support. This patch updates configuration scripts, defconfig, and setup files. Signed-off-by: Dan Malek [EMAIL PROTECTED] geode_x86.patch Description: Binary data
[PATCH] add AMD NS 5535 support
Hi Marcelo. This patch for 2.4 adds support for the AMD / National Semiconductor CS5535 chip set. Provided by AMD as part of the Geode support. Signed-off-by: Dan Malek [EMAIL PROTECTED] amdns_5535.patch Description: Binary data
Re: The IO problem on multiple PCI busses
"David S. Miller" wrote:
> There is only one sticking point, and that is how to convey to the
> mmap() call whether you want I/O or Memory space.
Isn't I/O space obsolete by now :-)? It actually caused me to think
of something elseI have cards with multiple memory and I/O
spaces (rare, but I have them). What if we did:
/proc/bus/pci/${BUS}/${DEVICE}/mem
/proc/bus/pci/${BUS}/${DEVICE}/io
/proc/bus/pci/${BUS}/${DEVICE}/BARn
The 'mem' or 'io' would map the first instance of these spaces
on the device, and would probably be suitable for nearly all devices.
If you really knew what you were doing (or wanted to make a big mess),
you could use the 'BARn' to specify the area.
You could even do something like map in as much virtually contiguous
space as indicated in the mmap(). For example, if the card has 2M I/O
and 8 M memory (in this order), the first 2M of the mmap()'ed space
would the the I/O and the next 8M would be the memory. I know, some
cards lie about the actual amount of space they have or need, but it
was just another idea that popped in...
Thanks.
-- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The IO problem on multiple PCI busses
"David S. Miller" wrote: > I played around with something akin to this, and some of the necessary > Xfree86-4.0.x hackery needed, some time ago. But I never finished > this. Sounds pretty sweet. How about we finish it? Any complaints (well reasonable ones :-) or concerns that came out of discussions or your testing we need to consider? Thanks. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The IO problem on multiple PCI busses
"David S. Miller" wrote:
There is only one sticking point, and that is how to convey to the
mmap() call whether you want I/O or Memory space.
Isn't I/O space obsolete by now :-)? It actually caused me to think
of something elseI have cards with multiple memory and I/O
spaces (rare, but I have them). What if we did:
/proc/bus/pci/${BUS}/${DEVICE}/mem
/proc/bus/pci/${BUS}/${DEVICE}/io
/proc/bus/pci/${BUS}/${DEVICE}/BARn
The 'mem' or 'io' would map the first instance of these spaces
on the device, and would probably be suitable for nearly all devices.
If you really knew what you were doing (or wanted to make a big mess),
you could use the 'BARn' to specify the area.
You could even do something like map in as much virtually contiguous
space as indicated in the mmap(). For example, if the card has 2M I/O
and 8 M memory (in this order), the first 2M of the mmap()'ed space
would the the I/O and the next 8M would be the memory. I know, some
cards lie about the actual amount of space they have or need, but it
was just another idea that popped in...
Thanks.
-- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The IO problem on multiple PCI busses
"David S. Miller" wrote: I played around with something akin to this, and some of the necessary Xfree86-4.0.x hackery needed, some time ago. But I never finished this. Sounds pretty sweet. How about we finish it? Any complaints (well reasonable ones :-) or concerns that came out of discussions or your testing we need to consider? Thanks. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: sigcontext on Linux-ppc in user space]
[EMAIL PROTECTED] wrote: > .. But I > still can't get at the sigcontext.c on Linux Powerpc. For example, this > simple program gives me a segmentation fault. (Linux ppc, suse 6.4, kernel > 2.2.14 You are not the only one. I recently discovered some inconsistent data structures and function calls (sigaction, old_sigaction, different context structures, etc.). I spent some time trying to sort it out but didn't have enough time. I was fortunate and just bailed out using old signal handler semantics. I was using what I believed were the latest glibc2.1, and also the latest 2.4 kernels (which is what I was really developing and testing). I mentioned this to some folks closer to the glibc action, but haven't followed up. Something is amiss here with PowerPC. Sorry I can't provide a solution. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PowerPC Linux for AS/400 & RS/6000 Hardware
Paul Mackerras wrote: > I don't think this is actually correct; I believe what Cort said is > that he is no longer maintaining the http://www.ppc.linux.org/ web > site. That is the way I read it as well. Of course, I have been reading things differently than others, lately :-). > He is away at the moment though. I met with Cort for a couple of hours on Tuesday. I thought he was going to be back in NM sometime today (Wednesday), and I was hoping he would have responded to the messages of confusion by now. We discussed how to better manage the kernel source trees, and it was pretty clear to me he intended to keep working on this. Like all of us, he has other jobs to do, and sometimes he just can't respond as quickly as we like. This kind of work has a multiplier effect as it moves upstream. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PowerPC Linux for AS/400 RS/6000 Hardware
Paul Mackerras wrote: I don't think this is actually correct; I believe what Cort said is that he is no longer maintaining the http://www.ppc.linux.org/ web site. That is the way I read it as well. Of course, I have been reading things differently than others, lately :-). He is away at the moment though. I met with Cort for a couple of hours on Tuesday. I thought he was going to be back in NM sometime today (Wednesday), and I was hoping he would have responded to the messages of confusion by now. We discussed how to better manage the kernel source trees, and it was pretty clear to me he intended to keep working on this. Like all of us, he has other jobs to do, and sometimes he just can't respond as quickly as we like. This kind of work has a multiplier effect as it moves upstream. -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
