Re: Freescale MPC5554 device tree (was: cross-compiling Linux for PowerPC e200 core?)
Hi,
Grant Likely wrote:
> 2010/3/13 Németh Márton :
[...]
>> + };
>> +
>> + e...@3fc { // Enhanced Time Processing
>> Unit
>> + compatible = "fsl,mpc5554-etpu";
>> + reg = <0x03fc 0x4000>;
>> + interrupts = <67 1 // Global Exception
>> + 68 1 // A Channel 0
>> + 69 1 // A Channel 1
>> + 70 1 // A Channel 2
>> + 71 1 // A Channel 3
>> + 72 1 // A Channel 4
>> + 73 1 // A Channel 5
>> + 74 1 // A Channel 6
>> + 75 1 // A Channel 7
>> + 76 1 // A Channel 8
>> + 77 1 // A Channel 9
>> + 78 1 // A Channel 10
>> + 79 1 // A Channel 11
>> + 80 1 // A Channel 12
>> + 81 1 // A Channel 13
>> + 82 1 // A Channel 14
>> + 83 1 // A Channel 15
>> + 84 1 // A Channel 16
>> + 85 1 // A Channel 17
>> + 86 1 // A Channel 18
>> + 87 1 // A Channel 19
>> + 88 1 // A Channel 20
>> + 89 1 // A Channel 21
>> + 90 1 // A Channel 22
>> + 91 1 // A Channel 23
>> + 92 1 // A Channel 24
>> + 93 1 // A Channel 25
>> + 94 1 // A Channel 26
>> + 95 1 // A Channel 27
>> + 96 1 // A Channel 28
>> + 97 1 // A Channel 29
>> + 98 1 // A Channel 30
>> + 99 1 // A Channel 31
>> + 243 1 // B Channel 0
>> + 244 1 // B Channel 1
>> + 245 1 // B Channel 2
>> + 246 1 // B Channel 3
>> + 247 1 // B Channel 4
>> + 248 1 // B Channel 5
>> + 249 1 // B Channel 6
>> + 250 1 // B Channel 7
>> + 251 1 // B Channel 8
>> + 252 1 // B Channel 9
>> + 253 1 // B Channel 10
>> + 254 1 // B Channel 11
>> + 255 1 // B Channel 12
>> + 256 1 // B Channel 13
>> + 257 1 // B Channel 14
>> + 258 1 // B Channel 15
>> + 259 1 // B Channel 16
>> + 260 1 // B Channel 17
>> + 261 1 // B Channel 18
>> + 262 1 // B Channel 19
>> + 263 1 // B Channel 20
>> + 264 1 // B Channel 21
>> + 265 1 // B Channel 22
>> + 266 1 // B Channel 23
>> + 267 1 // B Channel 24
>> + 268 1 // B Channel 25
>> + 269 1 // B Channel 26
>> + 270 1 // B Channel 27
>> + 271 1 // B Channel 28
>> + 272
Question regarding the DTLB Miss exceptions
I'm tracking a problem that's leading me through DSI and DTLB miss exceptions on an MPC8347 (e300c1 core), and I've come across an oddity that I'm hoping someone can explain. When a DTLB Miss exception can't find a PTE for the virtual address being written/read, it dummies up the SPRs for a DSI exception and then calls directly into the DSI exception code. Just before the DTLB miss code stores a value into DSISR it sets bit 2, which for a DSI exception is a reserved bit and should be cleared. There's no comment on the code (.../arch/powerpc/kernel/head_32.S line 619 of the 2.6.33-rc1 kernel). Can anyone tell me why this bit is getting set? Thanks. Bruce ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC Patch 1/2] PPC64-HWBKPT: Disable interrupts for data breakpoint exceptions
On Tue, 2010-03-30 at 16:24 +1100, Paul Mackerras wrote: > On Tue, Mar 23, 2010 at 07:37:02PM +0530, K.Prasad wrote: > > > Index: linux-2.6.ppc64_test/arch/powerpc/kernel/exceptions-64s.S > > === > > --- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/exceptions-64s.S > > +++ linux-2.6.ppc64_test/arch/powerpc/kernel/exceptions-64s.S > > @@ -735,6 +735,9 @@ _STATIC(do_hash_page) > > std r3,_DAR(r1) > > std r4,_DSISR(r1) > > > > + andis. r0,r4,0x0040/* Data Address Breakpoint match? */ > > Minor comment: why not dsisr_dabrma...@h instead of 0x0040? > > > + bne-handle_dabr_fault > > + > > andis. r0,r4,0xa450/* weird error? */ > > bne-handle_page_fault /* if not, try to insert a HPTE */ > > BEGIN_FTR_SECTION > > @@ -823,6 +826,15 @@ END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISER > > bl .raw_local_irq_restore > > b 11f I would move your new test to the "weird error" case (ie, after the bne- handle_page_fault) to avoid hitting the fast path. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC Patch 1/2] PPC64-HWBKPT: Disable interrupts for data breakpoint exceptions
On Tue, Mar 23, 2010 at 07:37:02PM +0530, K.Prasad wrote: > Index: linux-2.6.ppc64_test/arch/powerpc/kernel/exceptions-64s.S > === > --- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/exceptions-64s.S > +++ linux-2.6.ppc64_test/arch/powerpc/kernel/exceptions-64s.S > @@ -735,6 +735,9 @@ _STATIC(do_hash_page) > std r3,_DAR(r1) > std r4,_DSISR(r1) > > + andis. r0,r4,0x0040/* Data Address Breakpoint match? */ Minor comment: why not dsisr_dabrma...@h instead of 0x0040? > + bne-handle_dabr_fault > + > andis. r0,r4,0xa450/* weird error? */ > bne-handle_page_fault /* if not, try to insert a HPTE */ > BEGIN_FTR_SECTION > @@ -823,6 +826,15 @@ END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISER > bl .raw_local_irq_restore > b 11f > > +/* We have a data breakpoint exception - handle it */ > +handle_dabr_fault: > + /* Populate the pt_regs structure */ Another minor comment: that comment isn't accurate since you're not putting anything in the pt_regs, just getting arguments to do_dabr from it. > + ld r4,_DAR(r1) > + ld r5,_DSISR(r1) > + addir3,r1,STACK_FRAME_OVERHEAD > + bl .do_dabr > + b .ret_from_except_lite > + > /* Here we have a page fault that hash_page can't handle. */ > handle_page_fault: > ENABLE_INTS > Index: linux-2.6.ppc64_test/arch/powerpc/mm/fault.c > === > --- linux-2.6.ppc64_test.orig/arch/powerpc/mm/fault.c > +++ linux-2.6.ppc64_test/arch/powerpc/mm/fault.c > @@ -151,7 +151,7 @@ int __kprobes do_page_fault(struct pt_re > if (!user_mode(regs) && (address >= TASK_SIZE)) > return SIGSEGV; > > -#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE)) > +#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE) || defined(CONFIG_PPC64)) If we added similar code to head_32.S, we could probably remove this whole ifdef block. But that can be done in a later patch. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] 85xx: Enable support for ports 3 and 4 on 8548 CDS
I believe support was disabled due to issues with earlier versions of
the board/processor. At worst, adding the ports back into the device
tree should result in enabling ports that don't work on older systems,
so the default should be to enable them.
Signed-off-by: Andy Fleming
---
arch/powerpc/boot/dts/mpc8548cds.dts |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8548cds.dts
b/arch/powerpc/boot/dts/mpc8548cds.dts
index 4173af3..0f52624 100644
--- a/arch/powerpc/boot/dts/mpc8548cds.dts
+++ b/arch/powerpc/boot/dts/mpc8548cds.dts
@@ -20,10 +20,8 @@
aliases {
ethernet0 = &enet0;
ethernet1 = &enet1;
-/*
ethernet2 = &enet2;
ethernet3 = &enet3;
-*/
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
@@ -254,7 +252,6 @@
};
};
-/* eTSEC 3/4 are currently broken
enet2: ether...@26000 {
#address-cells = <1>;
#size-cells = <1>;
@@ -310,7 +307,6 @@
};
};
};
- */
serial0: ser...@4500 {
cell-index = <0>;
--
1.6.5.2.g6ff9a
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failing to get DMA working with MPC5200 (TQM5200) and CompactFlash
> We tested CF cards for DMA support some time ago, and IIRC this > included the STK5200. Situation was that only very few CF cards > actually support DMA (even if they advertise it on the label). Huh, not nice. Were those consumer cards or also industrial grade cards? Maybe that is the reason? With the latter, I have never seen this, they always told the truth, so far. Although we mostly used MWDMA, no UDMA to avoid the hardware problems. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failing to get DMA working with MPC5200 (TQM5200) and CompactFlash
On Mon, Mar 29, 2010 at 08:42:08PM +0200, Albrecht Dreß wrote: > Am 29.03.10 00:24 schrieb(en) Josh Triplett: > >We have the MPC5200C rev of the board, not the MPC5200B rev which > > Ummm - I didn't know that there is a 5200C available. The Freescale web site > only mentions the 5200 and the 5200B. Do you have any pointers to data > sheets/docs? I don't know the details; just repeating what the hardware team told me. :) We may have the revisions and suffixes mixed up, or we may have run into some terminology difference between the TQM5200 and the MPC5200. - Josh Triplett ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Xilinx MPMC SDMA subsystem
On Mon, Mar 29, 2010 at 1:04 PM, Sergey Temerkhanov wrote: > On Monday 29 March 2010 19:56:15 Grant Likely wrote: >> On Mon, Mar 29, 2010 at 9:42 AM, Steven J. Magnani >> >> wrote: >> > On Fri, 2010-03-26 at 17:53 -0600, Grant Likely wrote: >> >> I've not got time to review this patch right now, but Sergey and >> >> Steven, you both posted MPMC drivers on the same day; Steven on the >> >> microblaze list and Sergey on the powerpc list. Can you two please >> >> coordinate and figure out how to mork toward a single driver that will >> >> meet both your needs? I don't want to have 2 drivers (3 if you count >> >> the ll_temac driver) in mainline for the same hardware interface. >> > >> > I don't think we'll end up with a single driver. A MPMC DMA Engine >> > driver is useful only on "loopback" SDMA ports. Sergey's code looks like >> > a nice generic interface to Xilinx SDMA HW that could be used by the >> > xlldma and ll_temac drivers, for instance. Both of those will get >> > smaller, but won't go away. > > Yes, it's like having IBM EMAC driver and MAL layer or something > >> > >> > For this to be useful to me, it would need to be located somewhere more >> > accessible than arch/powerpc and it would need to have initialization >> > methods that don't depend on OF. In my build I would have platform code >> > that binds to the xlldma platform attachment, which would call Sergey's >> > SDMA code to assign it the proper resources. >> >> That should be fine. > > Well, I'll look at my old code for the platform interface bindings. I remember > it worked well on arch/ppc with my other drivers. Don't get too caught up in this aspect. of_platform_bus_type is being merged with platform_bus_type. One driver can be written to handle both use cases. However, it may not make any sense for the DMA library layer to have a bus binding since it is mostly a set of shared routines. I'm fine if the bindings are only at the SDMA driver and ll_temac driver level. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Xilinx MPMC SDMA subsystem
On Monday 29 March 2010 19:56:15 Grant Likely wrote: > On Mon, Mar 29, 2010 at 9:42 AM, Steven J. Magnani > > wrote: > > On Fri, 2010-03-26 at 17:53 -0600, Grant Likely wrote: > >> I've not got time to review this patch right now, but Sergey and > >> Steven, you both posted MPMC drivers on the same day; Steven on the > >> microblaze list and Sergey on the powerpc list. Can you two please > >> coordinate and figure out how to mork toward a single driver that will > >> meet both your needs? I don't want to have 2 drivers (3 if you count > >> the ll_temac driver) in mainline for the same hardware interface. > > > > I don't think we'll end up with a single driver. A MPMC DMA Engine > > driver is useful only on "loopback" SDMA ports. Sergey's code looks like > > a nice generic interface to Xilinx SDMA HW that could be used by the > > xlldma and ll_temac drivers, for instance. Both of those will get > > smaller, but won't go away. Yes, it's like having IBM EMAC driver and MAL layer or something > > > > For this to be useful to me, it would need to be located somewhere more > > accessible than arch/powerpc and it would need to have initialization > > methods that don't depend on OF. In my build I would have platform code > > that binds to the xlldma platform attachment, which would call Sergey's > > SDMA code to assign it the proper resources. > > That should be fine. Well, I'll look at my old code for the platform interface bindings. I remember it worked well on arch/ppc with my other drivers. > > > Any objections to having Sergey's code live in drivers/dma, and putting > > sdma.h out in include/linux? Might need to tweak the file/function names > > some to head off namespace issues. Or is there some other strategy for > > managing Xilinx-related drivers common to both Microblaze and PowerPC? > > I have no objections. This sounds like a good plan. Or we can put Xilinx-related headers to, i.e., include/linux/xilinx. There might be some other candidates for this. > > g. > Regards, Sergey Temerkhanov, Cifronic ZAO ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC Patch 2/2] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
On Mon, 2010-03-29 at 17:01 +0530, K.Prasad wrote: > On Fri, Mar 26, 2010 at 04:11:45PM -0500, Dave Kleikamp wrote: > > On Tue, 2010-03-23 at 19:37 +0530, K.Prasad wrote: > > > plain text document attachment (ppc64_hbkpt_02) > > > Implement perf-events based hw-breakpoint interfaces for PPC64 processors. > > > These interfaces help arbitrate requests from various users and schedules > > > them as appropriate. > > > > > > Signed-off-by: K.Prasad > > > > SNIP > > > > > Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/cputable.h > > > === > > > --- linux-2.6.ppc64_test.orig/arch/powerpc/include/asm/cputable.h > > > +++ linux-2.6.ppc64_test/arch/powerpc/include/asm/cputable.h > > > @@ -511,6 +511,13 @@ static inline int cpu_has_feature(unsign > > > & feature); > > > } > > > > > > +#define CPU_FTR_HAS_DABR (defined(CONFIG_PPC64) && \ > > > + !defined(CONFIG_PPC_ADV_DEBUG_REGS)) > > > +#ifdef CPU_FTR_HAS_DABR > > > +/* Number of physical HW breakpoint registers */ > > > +#define HBP_NUM 1 > > > +#endif > > > + > > > #endif /* !__ASSEMBLY__ */ > > > > > > #endif /* __KERNEL__ */ > > > > These new defines don't really correlate to the cpu table. One would > > expect cpu_has_feature(CPU_FTR_HAS_DABR) to have meaning, but it would > > have to be defined similar to the other CPU_FTR_ constants, and or-ed > > with CPU_FTRS_ALWAYS (when appropriate). > > > > The code can be changed as below: > > #if (defined(CONFIG_PPC64) && !defined(CONFIG_PPC_ADV_DEBUG_REGS)) > #define CPU_FTR_HAS_DABR 1 > /* Number of physical HW breakpoint registers */ > #define HBP_NUM 1 > #endif > > However, a config option CONFIG_PPC_BOOK3S_64 (I just found) whose scope > includes only 64-bit server processors (having one DABR) to be the most > suitable. > > I think it must be used in lieu of introducing a new CPU_FTR_HAS_DABR > definition in cputable.h > > > > Similarly, I would expect the cpu_spec structure to have a new field, > > hbp_num, which is initialized in cputable.c. Maybe a longer name would > > be better, num_hw_brkpts? > > > > There are a few issues with such an approach: > i) Two such fields would be required in 'struct cpu_spec' - one for > instruction breakpoints and other for data. > ii) As pointed out by you below, hbp_num or num_hw_brkpts would always > be assigned to the compile time constant HBP_NUM (hence a variable is not > required to store it). > iii) HBP_NUM still cannot be entirely removed as it is used by generic > kernel/hw_breakpoint.c code (and is used by x86 code as well). > > I think the simplest approach would be to have the following entry in > cputable.h (and get away with the rest of the additions seen in patch > ver XV) > > #ifdef CONFIG_PPC_BOOK3S_64 > #define HBP_NUM 1 > #endif > > The next version of the patch should contain changes to that effect > (assuming I hear no objections). I just don't think this belongs in cputable.h. Why not put this in hw_breakpoint.h? -- David Kleikamp IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch v.3a] mpc5200b/uart: improve baud rate calculation (reach high baud rates, better accuracy)
On the MPC5200B, make very high baud rates (e.g. 3 MBaud) accessible and
achieve a higher precision for high baud rates in general. This is done by
selecting the appropriate prescaler (/4 or /32). As to keep the code clean,
the getuartclk method has been dropped, and all calculations are done in a
new set_baudrate method.
Notes: only "fsl,mpc5200b-psc-uart" compatible devices benefit from these
improvements.
The 512x may or may not work; the patch keeps the current implementation
(using a /16 prescaler), but according to the data sheet, this is plain
wrong. See the comment in mpc512x_psc_set_baudrate(). Any insight and
testing of the code (maybe Anatolij, when he's back from his vacation)
would be appreciated.
Tested on a custom 5200B based board, from 110 baud up to 3 MBaud, and with
both "fsl,mpc5200b-psc-uart" and "fsl,mpc5200-psc-uart" devices.
Signed-off-by: Albrecht Dreß
---
Change vs. v.3: re-based against Linus' git tree (2.6.34-rc1-dirty)
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index 3119fdd..e349514 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -146,7 +146,9 @@ struct psc_ops {
unsigned char (*read_char)(struct uart_port *port);
void(*cw_disable_ints)(struct uart_port *port);
void(*cw_restore_ints)(struct uart_port *port);
- unsigned long (*getuartclk)(void *p);
+ unsigned int(*set_baudrate)(struct uart_port *port,
+ struct ktermios *new,
+ struct ktermios *old);
int (*clock)(struct uart_port *port, int enable);
int (*fifoc_init)(void);
void(*fifoc_uninit)(void);
@@ -154,6 +156,16 @@ struct psc_ops {
irqreturn_t (*handle_irq)(struct uart_port *port);
};
+/* setting the prescaler and divisor reg is common for all chips */
+static inline void mpc52xx_set_divisor(struct mpc52xx_psc __iomem *psc,
+ u16 prescaler, unsigned int divisor)
+{
+ /* select prescaler */
+ out_be16(&psc->mpc52xx_psc_clock_select, prescaler);
+ out_8(&psc->ctur, divisor >> 8);
+ out_8(&psc->ctlr, divisor & 0xff);
+}
+
#ifdef CONFIG_PPC_MPC52xx
#define FIFO_52xx(port) ((struct mpc52xx_psc_fifo __iomem *)(PSC(port)+1))
static void mpc52xx_psc_fifo_init(struct uart_port *port)
@@ -161,9 +173,6 @@ static void mpc52xx_psc_fifo_init(struct uart_port *port)
struct mpc52xx_psc __iomem *psc = PSC(port);
struct mpc52xx_psc_fifo __iomem *fifo = FIFO_52xx(port);
- /* /32 prescaler */
- out_be16(&psc->mpc52xx_psc_clock_select, 0xdd00);
-
out_8(&fifo->rfcntl, 0x00);
out_be16(&fifo->rfalarm, 0x1ff);
out_8(&fifo->tfcntl, 0x07);
@@ -252,15 +261,47 @@ static void mpc52xx_psc_cw_restore_ints(struct uart_port
*port)
out_be16(&PSC(port)->mpc52xx_psc_imr, port->read_status_mask);
}
-/* Search for bus-frequency property in this node or a parent */
-static unsigned long mpc52xx_getuartclk(void *p)
+static unsigned int mpc5200_psc_set_baudrate(struct uart_port *port,
+struct ktermios *new,
+struct ktermios *old)
{
- /*
-* 5200 UARTs have a / 32 prescaler
-* but the generic serial code assumes 16
-* so return ipb freq / 2
-*/
- return mpc5xxx_get_bus_frequency(p) / 2;
+ unsigned int baud;
+ unsigned int divisor;
+
+ /* The 5200 has a fixed /32 prescaler, uartclk contains the ipb freq */
+ baud = uart_get_baud_rate(port, new, old,
+ port->uartclk / (32 * 0x) + 1,
+ port->uartclk / 32);
+ divisor = (port->uartclk + 16 * baud) / (32 * baud);
+
+ /* enable the /32 prescaler and set the divisor */
+ mpc52xx_set_divisor(PSC(port), 0xdd00, divisor);
+ return baud;
+}
+
+static unsigned int mpc5200b_psc_set_baudrate(struct uart_port *port,
+ struct ktermios *new,
+ struct ktermios *old)
+{
+ unsigned int baud;
+ unsigned int divisor;
+ u16 prescaler;
+
+ /* The 5200B has a selectable /4 or /32 prescaler, uartclk contains the
+* ipb freq */
+ baud = uart_get_baud_rate(port, new, old,
+ port->uartclk / (32 * 0x) + 1,
+ port->uartclk / 4);
+ divisor = (port->uartclk + 2 * baud) / (4 * baud);
+
+ /* select the proper prescaler and set the divisor */
+ if (divisor > 0x) {
+ divisor = (divisor + 4) / 8;
+ prescaler = 0xdd00; /* /32 */
+ } else
+ prescaler = 0xff00; /* /4 */
+ mpc52xx_set_divisor(PSC(port), prescaler, divisor);
+
Re: Failing to get DMA working with MPC5200 (TQM5200) and CompactFlash
Hi Josh: Am 29.03.10 00:24 schrieb(en) Josh Triplett: We have the MPC5200C rev of the board, not the MPC5200B rev which Ummm - I didn't know that there is a 5200C available. The Freescale web site only mentions the 5200 and the 5200B. Do you have any pointers to data sheets/docs? Thanks, Albrecht. pgptFWfkVYLQV.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Xilinx MPMC SDMA subsystem
On Mon, Mar 29, 2010 at 9:42 AM, Steven J. Magnani wrote: > On Fri, 2010-03-26 at 17:53 -0600, Grant Likely wrote: >> I've not got time to review this patch right now, but Sergey and >> Steven, you both posted MPMC drivers on the same day; Steven on the >> microblaze list and Sergey on the powerpc list. Can you two please >> coordinate and figure out how to mork toward a single driver that will >> meet both your needs? I don't want to have 2 drivers (3 if you count >> the ll_temac driver) in mainline for the same hardware interface. >> > > I don't think we'll end up with a single driver. A MPMC DMA Engine > driver is useful only on "loopback" SDMA ports. Sergey's code looks like > a nice generic interface to Xilinx SDMA HW that could be used by the > xlldma and ll_temac drivers, for instance. Both of those will get > smaller, but won't go away. > > For this to be useful to me, it would need to be located somewhere more > accessible than arch/powerpc and it would need to have initialization > methods that don't depend on OF. In my build I would have platform code > that binds to the xlldma platform attachment, which would call Sergey's > SDMA code to assign it the proper resources. That should be fine. > Any objections to having Sergey's code live in drivers/dma, and putting > sdma.h out in include/linux? Might need to tweak the file/function names > some to head off namespace issues. Or is there some other strategy for > managing Xilinx-related drivers common to both Microblaze and PowerPC? I have no objections. This sounds like a good plan. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Xilinx MPMC SDMA subsystem
On Fri, 2010-03-26 at 17:53 -0600, Grant Likely wrote: > I've not got time to review this patch right now, but Sergey and > Steven, you both posted MPMC drivers on the same day; Steven on the > microblaze list and Sergey on the powerpc list. Can you two please > coordinate and figure out how to mork toward a single driver that will > meet both your needs? I don't want to have 2 drivers (3 if you count > the ll_temac driver) in mainline for the same hardware interface. > I don't think we'll end up with a single driver. A MPMC DMA Engine driver is useful only on "loopback" SDMA ports. Sergey's code looks like a nice generic interface to Xilinx SDMA HW that could be used by the xlldma and ll_temac drivers, for instance. Both of those will get smaller, but won't go away. For this to be useful to me, it would need to be located somewhere more accessible than arch/powerpc and it would need to have initialization methods that don't depend on OF. In my build I would have platform code that binds to the xlldma platform attachment, which would call Sergey's SDMA code to assign it the proper resources. Any objections to having Sergey's code live in drivers/dma, and putting sdma.h out in include/linux? Might need to tweak the file/function names some to head off namespace issues. Or is there some other strategy for managing Xilinx-related drivers common to both Microblaze and PowerPC? Steve ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/12] drivers/macintosh: Add missing unlock
From: Julia Lawall
In some error handling cases the lock is not unlocked.
A simplified version of the semantic patch that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@r exists@
expression E1;
identifier f;
@@
f (...) { <+...
* spin_lock_irqsave (E1,...);
... when != E1
* return ...;
...+> }
//
Signed-off-by: Julia Lawall
---
drivers/macintosh/macio-adb.c |1 +
drivers/macintosh/smu.c |4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/macintosh/macio-adb.c b/drivers/macintosh/macio-adb.c
index 79119f5..bd6da7a 100644
--- a/drivers/macintosh/macio-adb.c
+++ b/drivers/macintosh/macio-adb.c
@@ -155,6 +155,7 @@ static int macio_adb_reset_bus(void)
while ((in_8(&adb->ctrl.r) & ADB_RST) != 0) {
if (--timeout == 0) {
out_8(&adb->ctrl.r, in_8(&adb->ctrl.r) & ~ADB_RST);
+ spin_unlock_irqrestore(&macio_lock, flags);
return -1;
}
}
diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
index f96feeb..28f75cf 100644
--- a/drivers/macintosh/smu.c
+++ b/drivers/macintosh/smu.c
@@ -1182,8 +1182,10 @@ static ssize_t smu_read_command(struct file *file,
struct smu_private *pp,
return -EOVERFLOW;
spin_lock_irqsave(&pp->lock, flags);
if (pp->cmd.status == 1) {
- if (file->f_flags & O_NONBLOCK)
+ if (file->f_flags & O_NONBLOCK) {
+ spin_unlock_irqrestore(&pp->lock, flags);
return -EAGAIN;
+ }
add_wait_queue(&pp->wait, &wait);
for (;;) {
set_current_state(TASK_INTERRUPTIBLE);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/12] arch/powerpc/kernel: Add missing unlock
From: Julia Lawall
Add an unlock before exiting the function.
A simplified version of the semantic patch that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@r exists@
expression E1;
identifier f;
@@
f (...) { <+...
* spin_lock_irq (E1,...);
... when != E1
* return ...;
...+> }
//
Signed-off-by: Julia Lawall
---
arch/powerpc/kernel/vio.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 77f6421..2ca69fa 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -644,8 +644,10 @@ void vio_cmo_set_dev_desired(struct vio_dev *viodev,
size_t desired)
found = 1;
break;
}
- if (!found)
+ if (!found) {
+ spin_unlock_irqrestore(&vio_cmo.lock, flags);
return;
+ }
/* Increase/decrease in desired device entitlement */
if (desired >= viodev->cmo.desired) {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] PowerPC/FSL/CPM1: Configure clock correctly for SCC
The board setup functions call cpm1_clk_setup() to configure the clock
source.
If CPM_CLK_RTX has been used for the parameter mode,
the clock has been configured only for TX but not for RX.
Now CPM_CLK_RTX configures the clock for both directions correctly.
Signed-off-by: Wolfgang Ocker
---
arch/powerpc/sysdev/cpm1.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/sysdev/cpm1.c
index a4b41db..786e178 100644
--- a/arch/powerpc/sysdev/cpm1.c
+++ b/arch/powerpc/sysdev/cpm1.c
@@ -485,9 +485,6 @@ int cpm1_clk_setup(enum cpm_clk_target target, int clock,
int mode)
return -EINVAL;
}
- if (reg == &mpc8xx_immr->im_cpm.cp_sicr && mode == CPM_CLK_RX)
- shift += 3;
-
for (i = 0; i < ARRAY_SIZE(clk_map); i++) {
if (clk_map[i][0] == target && clk_map[i][1] == clock) {
bits = clk_map[i][2];
@@ -502,6 +499,17 @@ int cpm1_clk_setup(enum cpm_clk_target target, int clock,
int mode)
bits <<= shift;
mask <<= shift;
+
+ if (reg == &mpc8xx_immr->im_cpm.cp_sicr) {
+ if (mode == CPM_CLK_RTX) {
+ bits |= bits << 3;
+ mask |= mask << 3;
+ } else if (mode == CPM_CLK_RX) {
+ bits <<= 3;
+ mask <<= 3;
+ }
+ }
+
out_be32(reg, (in_be32(reg) & ~mask) | bits);
return 0;
--
1.6.6.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC Patch 2/2] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
On Fri, Mar 26, 2010 at 04:11:45PM -0500, Dave Kleikamp wrote: > On Tue, 2010-03-23 at 19:37 +0530, K.Prasad wrote: > > plain text document attachment (ppc64_hbkpt_02) > > Implement perf-events based hw-breakpoint interfaces for PPC64 processors. > > These interfaces help arbitrate requests from various users and schedules > > them as appropriate. > > > > Signed-off-by: K.Prasad > > SNIP > > > Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/cputable.h > > === > > --- linux-2.6.ppc64_test.orig/arch/powerpc/include/asm/cputable.h > > +++ linux-2.6.ppc64_test/arch/powerpc/include/asm/cputable.h > > @@ -511,6 +511,13 @@ static inline int cpu_has_feature(unsign > > & feature); > > } > > > > +#define CPU_FTR_HAS_DABR (defined(CONFIG_PPC64) && \ > > + !defined(CONFIG_PPC_ADV_DEBUG_REGS)) > > +#ifdef CPU_FTR_HAS_DABR > > +/* Number of physical HW breakpoint registers */ > > +#define HBP_NUM 1 > > +#endif > > + > > #endif /* !__ASSEMBLY__ */ > > > > #endif /* __KERNEL__ */ > > These new defines don't really correlate to the cpu table. One would > expect cpu_has_feature(CPU_FTR_HAS_DABR) to have meaning, but it would > have to be defined similar to the other CPU_FTR_ constants, and or-ed > with CPU_FTRS_ALWAYS (when appropriate). > The code can be changed as below: #if (defined(CONFIG_PPC64) && !defined(CONFIG_PPC_ADV_DEBUG_REGS)) #define CPU_FTR_HAS_DABR 1 /* Number of physical HW breakpoint registers */ #define HBP_NUM 1 #endif However, a config option CONFIG_PPC_BOOK3S_64 (I just found) whose scope includes only 64-bit server processors (having one DABR) to be the most suitable. I think it must be used in lieu of introducing a new CPU_FTR_HAS_DABR definition in cputable.h > Similarly, I would expect the cpu_spec structure to have a new field, > hbp_num, which is initialized in cputable.c. Maybe a longer name would > be better, num_hw_brkpts? > There are a few issues with such an approach: i) Two such fields would be required in 'struct cpu_spec' - one for instruction breakpoints and other for data. ii) As pointed out by you below, hbp_num or num_hw_brkpts would always be assigned to the compile time constant HBP_NUM (hence a variable is not required to store it). iii) HBP_NUM still cannot be entirely removed as it is used by generic kernel/hw_breakpoint.c code (and is used by x86 code as well). I think the simplest approach would be to have the following entry in cputable.h (and get away with the rest of the additions seen in patch ver XV) #ifdef CONFIG_PPC_BOOK3S_64 #define HBP_NUM 1 #endif The next version of the patch should contain changes to that effect (assuming I hear no objections). > When I added the PPC_ADV_DEBUG config options for the bookE features, I > didn't see an immediate need to clutter the cputable since their values > are fixed at compile time. We should be consistent with these, but It is even more true with ppc64-server processors, where the number of debug registers (denoted by HBP_NUM) is fixed to 1 (unlike BookE where the DACs can be used in standalone or as a pair of registers). > unless we are going to determine any of these at run-time, I don't know > that they belong in the cpu table. > > Thanks, > Shaggy > -- Thanks, K.Prasad ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers/macintosh: Correct potential double free
On Mon, 2010-03-29 at 11:39 +0200, Julia Lawall wrote: > From: Julia Lawall > > The conditionals were testing different values, but then all freeing the > same one, which could result in a double free. > > A simplified version of the semantic match that finds this problem is as > follows: (http://coccinelle.lip6.fr/) Thanks. I'll stick that in my -next branch as soon as I open it :-) Cheers, Ben. > // > @@ > expression x,e; > identifier f; > iterator I; > statement S; > @@ > > *kfree(x); > ... when != &x > when != x = e > when != I(x,...) S > *x > // > > Signed-off-by: Julia Lawall > > --- > drivers/macintosh/windfarm_pm91.c |9 +++-- > 1 files changed, 3 insertions(+), 6 deletions(-) > > diff --git a/drivers/macintosh/windfarm_pm91.c > b/drivers/macintosh/windfarm_pm91.c > index bea9916..3442732 100644 > --- a/drivers/macintosh/windfarm_pm91.c > +++ b/drivers/macintosh/windfarm_pm91.c > @@ -687,12 +687,9 @@ static int __devexit wf_smu_remove(struct > platform_device *ddev) > wf_put_control(cpufreq_clamp); > > /* Destroy control loops state structures */ > - if (wf_smu_slots_fans) > - kfree(wf_smu_cpu_fans); > - if (wf_smu_drive_fans) > - kfree(wf_smu_cpu_fans); > - if (wf_smu_cpu_fans) > - kfree(wf_smu_cpu_fans); > + kfree(wf_smu_slots_fans); > + kfree(wf_smu_drive_fans); > + kfree(wf_smu_cpu_fans); > > return 0; > } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] drivers/macintosh: Correct potential double free
From: Julia Lawall The conditionals were testing different values, but then all freeing the same one, which could result in a double free. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression x,e; identifier f; iterator I; statement S; @@ *kfree(x); ... when != &x when != x = e when != I(x,...) S *x // Signed-off-by: Julia Lawall --- drivers/macintosh/windfarm_pm91.c |9 +++-- 1 files changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/macintosh/windfarm_pm91.c b/drivers/macintosh/windfarm_pm91.c index bea9916..3442732 100644 --- a/drivers/macintosh/windfarm_pm91.c +++ b/drivers/macintosh/windfarm_pm91.c @@ -687,12 +687,9 @@ static int __devexit wf_smu_remove(struct platform_device *ddev) wf_put_control(cpufreq_clamp); /* Destroy control loops state structures */ - if (wf_smu_slots_fans) - kfree(wf_smu_cpu_fans); - if (wf_smu_drive_fans) - kfree(wf_smu_cpu_fans); - if (wf_smu_cpu_fans) - kfree(wf_smu_cpu_fans); + kfree(wf_smu_slots_fans); + kfree(wf_smu_drive_fans); + kfree(wf_smu_cpu_fans); return 0; } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with PCI bus rescan on 460EX
Hello Kenji-san, Kenji Kaneshige wrote: Felix, I think assigning hpXXsize at boot time is the simpler solution, if it is acceptable workaround for you. And as Yinghai suggested in the another email, removing slot's parent bridge first should be one of the workaround. But the problem is whether it is acceptable for you, because your hotplug problem seems a regression. Thanks, Kenji Kaneshige Both workarounds work for me, and will use hpXXsize as a short term solution. In the long run I'd like to see the problem fixed properly and I'm willing to test patches on my hardware, as I also think it's a regression. Thanks Kenji-san and Yinghai for your help. Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Help about Freescale p2020ds problem under cpu load test
Hi Benjamin Herrenschmidt,
I use Freescale p2020ds board and kernel linux 2.6.33.
Under cpu load test which test case is in attachment
(#./cpu_load_multi.sh 500),
the follow issues happen after a long time:
===
find: md5sum terminated by signal 6
find: md5sum terminated by signal 11
===
If use kernel linux 2.6.27(porting p2020ds bsp to it), it's easy to
reproduce the issue:
===
find: ../nptl/sysdeps/unix/sysv/linux/powerpc/../i386/../fork.c:138:
__libc_fork: Assertion `((void)(self), (((struct pthread *)
(__thread_register - 0x7000 - (sizeof (struct pthread) + ((sizeof
(tcbhead_t) + __alignof__ (struct pthread) - 1)& ~(__alignof__ (struct
pthread) - 1))->tid) != ppid' failed.
find: md5sum terminated by signal 6
find: md5sum terminated by signal 11
./cpu_load.sh: line 6: 7944 Segmentation fault find /usr -type f
-exec md5sum {} \;>/dev/null
===
If turn off CONFIG_SMP, the issue disappear.
If use Freescale 8572ds board, the issue disappear, too.
I know the two board is same about cpu(e500v2), but their version have a
little difference:
===
fsl_8572ds:
cpu: e500v2
revision: 3.0 (pvr 8021 0030)
fsl_p2020ds:
cpu: e500v2
revision: 4.0 (pvr 8021 1040)
===
Please help me to check the problem.
Thanks,
LiWang.
cpu_load.sh
Description: application/shellscript
cpu_load_multi.sh
Description: application/shellscript
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with PCI bus rescan on 460EX
Yinghai Lu wrote: On Sun, Mar 28, 2010 at 2:13 AM, Felix Radensky wrote: Hello, Kenji-san I've tried Jesse's tree with Yinghai's patches, but they don't seem to help. Memory for bridge is not allocated after insertion of hotplug device and bus rescan. Attached dmesg output in case of success and failure. that patches only take care of pcie hotplug path... and it calls pci_assign_unassigned_bridge_resources(bridge) instead of pci_bus_assign_resources(bus) so it doesn't check pci_is_enabled() maybe We can update rescan path to check if it is safe to skip the pci_is_enabled() too. - no driver for those devices under that bridge are loaded. Yinghai, Felix, Thank you very much for the explanation, Yinghai. The pci_assign_unassigned_bridge_resources() is what I wanted to suggest to Felix. Felix, I think assigning hpXXsize at boot time is the simpler solution, if it is acceptable workaround for you. And as Yinghai suggested in the another email, removing slot's parent bridge first should be one of the workaround. But the problem is whether it is acceptable for you, because your hotplug problem seems a regression. Thanks, Kenji Kaneshige YH -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
