Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver
Hi Grant, Grant Likely wrote: > Hi Wolfgang, thanks for the quick response. Comments below... > > On Fri, May 22, 2009 at 8:46 AM, Wolfgang Grandegger > wrote: >> +++ net-next-2.6/Documentation/powerpc/dts-bindings/can/sja1000.txt >> @@ -0,0 +1,37 @@ >> +Memory mapped SJA1000 CAN controller from NXP (formerly Philips) >> + >> +Required properties: >> + >> +- compatible : should be "nxp,sja1000". >> +- reg : should specify the chip select, address offset and size used >> + for the chip depending on the bus it is connected to. >> +- interrupts: property with a value describing the interrupt source >> + (number and sensitivity) for that device. The encoding depends >> + on the type of interrupt controller used. > > Hmmm, "reg", "interrupts", and "interrupt-parent" are well understood > properties. I don't think we need to keep boilerplate defining the > meaning every time a new binding is added. (general musing; not an > ack or nack of this patch) OK. > However, what should be defined is *what* the register range is (ie. > one tuple; location of device registers), and what the interrupts are > (ie. single tuple for device's irq line). Granted this is a trivial > case, but in the case of devices with more than one address range or > irq line, the meaning of each tuple is critical information. I think > it would be a good pattern to establish. Sounds reasonable. >> +Optional properties: >> + >> +- interrupt-parent : the phandle for the interrupt controller that >> + services interrupts for that device. > > Thinking further; I wouldn't even mention "interrupt-parent" here. > Anyone working with this stuff must already understand irq routing. OK, I will remove it. >> +- clock-frequency : CAN system clock frequency in Hz, which is normally >> + half of the oscillator clock frequency. If not specified, a >> + default value of 800 (8 MHz) is used. > > A clock-frequency property typically refers to the bus clock > frequency. Something like can-frequency would be better. Ah, right, but I'm also not happy with "can-frequency". The manual speaks about the "internal clock", which is half of the external oscillator frequency. Maybe "internal-clock-frequency" might be better. >> +- cdr-reg : value of the SJA1000 clock divider register according to >> + the SJA1000 data sheet. If not specified, a default value of >> + 0x48 is used. > > Ewh. The driver should be clueful enough to derive the clock divider > value given both the bus and can frequencies. I don't like this > property. The clock divider register controls the CLKOUT frequency for the microcontroller another CAN controller and allows to deactivate the CLKOUT pin. It's not used to configure the CAN bus frequency. > >> +- ocr-reg : value of the SJA1000 output control register according to >> + the SJA1000 data sheet. If not specified, a default value of >> + 0x0a is used. > > Ditto here; the binding should describe the usage mode; not the > register settings to get the usage mode. What sort of settings will > the .dts author be writing here? Unfortunately, there are many: clkout-frequency bypass-comperator tx1-output-on-rx-irq #define OCR_MODE_BIPHASE 0x00 #define OCR_MODE_TEST 0x01 #define OCR_MODE_NORMAL 0x02 #define OCR_MODE_CLOCK0x03 #define OCR_TX0_INVERT0x04 #define OCR_TX0_PULLDOWN 0x08 #define OCR_TX0_PULLUP0x10 #define OCR_TX0_PUSHPULL 0x18 #define OCR_TX1_INVERT0x20 #define OCR_TX1_PULLDOWN 0x40 #define OCR_TX1_PULLUP0x80 #define OCR_TX1_PUSHPULL 0xc0 I think implementing properties for each option is overkill. Wolfgang. > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
PPC405EX based irq flooding with USB-OTG and usbserial device
Hello everyone, This is my first post to the PPC dev list as my company has just started developing a new project based on Linux. The good news is, this post is not debug-related as much as it is an introduction and query while I download the latest DENX kernel(only place I know that has the DWC_OTG driver). I've been working with a Kilauea dev board and have had lots of trouble when I plug in a sierra-wireless modem dev kit on the USB. It goes fine untill I actually try to communicate(pppd or minicom) with the little bugger and then my IRQs go through the roof. And they only calm back down after I shut down my communicaiton channel. I've solved this issue with our board, and was wondering if it has since been fixed (I'm running 2.6.25-DENX). I don't want to waste the board's time with a patch that is no longer necesarry. -- Hunter Cobbs ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
Ian Campbell wrote: On Thu, 2009-05-21 at 14:27 -0400, Becky Bruce wrote: I can work with that, but it's going to be a bit inefficient, as I actually need the dma_addr_t, not the phys_addr_t, so I'll have to convert. In every case, this is a conversion I've already done and that I need in the calling code as well. Does dma_addr_t dma_map_range(struct device *hwdev, phys_addr_t addr, size_t size); work for you? If the range does not need mapping then it returns the dma address, if you needed to calculate the dma address anyway to figure out if mapping is required then this is fine. If the range does need mapping then it returns NULL. My only concern is whether dma_addr_t == 0 is actually equivalent to NULL. That is, can we be sure that address 0 will never be used? Taking dma_alloc_coherent as a model, we could have something like: int dma_map_range(struct device *hwdev, phys_addr_t addr, size_t size, dma_addr_t *dma_addrp); where *dma_addrp is set if the function returns success (bool return type might be clearer). J ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] therm_adt746x: Always clear hardware bit which inverts fan speed range.
This bit would get enabled sometimes (probably after suspend/resume), so the
fan would run at full speed below the temperature thresholds, but slow down and
eventually stop if temperatures rose above the thresholds... not exactly what
you want.
Signed-off-by: Michel Dänzer
---
drivers/macintosh/therm_adt746x.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/macintosh/therm_adt746x.c
b/drivers/macintosh/therm_adt746x.c
index 82607ad..321eaad 100644
--- a/drivers/macintosh/therm_adt746x.c
+++ b/drivers/macintosh/therm_adt746x.c
@@ -37,6 +37,7 @@
#define CONFIG_REG 0x40
#define MANUAL_MASK 0xe0
#define AUTO_MASK0x20
+#define INVERT_MASK 0x10
static u8 TEMP_REG[3]= {0x26, 0x25, 0x27}; /* local, sensor1, sensor2 */
static u8 LIMIT_REG[3] = {0x6b, 0x6a, 0x6c}; /* local, sensor1, sensor2 */
@@ -229,7 +230,8 @@ static void write_fan_speed(struct thermostat *th, int
speed, int fan)
if (speed >= 0) {
manual = read_reg(th, MANUAL_MODE[fan]);
- write_reg(th, MANUAL_MODE[fan], manual|MANUAL_MASK);
+ write_reg(th, MANUAL_MODE[fan],
+ (manual|MANUAL_MASK) & (~INVERT_MASK));
write_reg(th, FAN_SPD_SET[fan], speed);
} else {
/* back to automatic */
--
1.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/virtex: Add ml510 reference design device tree
From: Roderick Colenbrander
As subject says, add dts files for Xilinx ML510 reference design with
the PCI host bridge device
Signed-off-by: Roderick Colenbrander
Signed-off-by: Grant Likely
---
I'm posting this one to the devicetree-discuss list for review before merging.
The dts file was generated using the Xilinx EDK device-tree generation tool
and then modified by hand to add in the non-FPGA bits.
g.
arch/powerpc/boot/dts/virtex440-ml510.dts | 465 +
1 files changed, 465 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
diff --git a/arch/powerpc/boot/dts/virtex440-ml510.dts
b/arch/powerpc/boot/dts/virtex440-ml510.dts
new file mode 100644
index 000..81a8dc2
--- /dev/null
+++ b/arch/powerpc/boot/dts/virtex440-ml510.dts
@@ -0,0 +1,465 @@
+/*
+ * Xilinx ML510 Reference Design support
+ *
+ * This DTS file was created for the ml510_bsb1_pcores_ppc440 reference design.
+ * The reference design contains a bug which prevent PCI DMA from working
+ * properly. A description of the bug is given in the plbv46_pci section. It
+ * needs to be fixed by the user until Xilinx updates their reference design.
+ *
+ * Copyright 2009, Roderick Colenbrander
+ */
+
+/dts-v1/;
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "xlnx,ml510-ref-design", "xlnx,virtex440";
+ dcr-parent = <&ppc440_0>;
+ DDR2_SDRAM_DIMM0: mem...@0 {
+ device_type = "memory";
+ reg = < 0x0 0x2000 >;
+ } ;
+ alias {
+ ethernet0 = &Hard_Ethernet_MAC;
+ serial0 = &RS232_Uart_1;
+ } ;
+ chosen {
+ bootargs = "console=ttyS0 root=/dev/ram";
+ linux,stdout-path = "/p...@0/ser...@83e0";
+ } ;
+ cpus {
+ #address-cells = <1>;
+ #cpus = <0x1>;
+ #size-cells = <0>;
+ ppc440_0: c...@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clock-frequency = <3>;
+ compatible = "PowerPC,440", "ibm,ppc440";
+ d-cache-line-size = <0x20>;
+ d-cache-size = <0x8000>;
+ dcr-access-method = "native";
+ dcr-controller ;
+ device_type = "cpu";
+ i-cache-line-size = <0x20>;
+ i-cache-size = <0x8000>;
+ model = "PowerPC,440";
+ reg = <0>;
+ timebase-frequency = <3>;
+ xlnx,apu-control = <0x2000>;
+ xlnx,apu-udi-0 = <0x0>;
+ xlnx,apu-udi-1 = <0x0>;
+ xlnx,apu-udi-10 = <0x0>;
+ xlnx,apu-udi-11 = <0x0>;
+ xlnx,apu-udi-12 = <0x0>;
+ xlnx,apu-udi-13 = <0x0>;
+ xlnx,apu-udi-14 = <0x0>;
+ xlnx,apu-udi-15 = <0x0>;
+ xlnx,apu-udi-2 = <0x0>;
+ xlnx,apu-udi-3 = <0x0>;
+ xlnx,apu-udi-4 = <0x0>;
+ xlnx,apu-udi-5 = <0x0>;
+ xlnx,apu-udi-6 = <0x0>;
+ xlnx,apu-udi-7 = <0x0>;
+ xlnx,apu-udi-8 = <0x0>;
+ xlnx,apu-udi-9 = <0x0>;
+ xlnx,dcr-autolock-enable = <0x1>;
+ xlnx,dcu-rd-ld-cache-plb-prio = <0x0>;
+ xlnx,dcu-rd-noncache-plb-prio = <0x0>;
+ xlnx,dcu-rd-touch-plb-prio = <0x0>;
+ xlnx,dcu-rd-urgent-plb-prio = <0x0>;
+ xlnx,dcu-wr-flush-plb-prio = <0x0>;
+ xlnx,dcu-wr-store-plb-prio = <0x0>;
+ xlnx,dcu-wr-urgent-plb-prio = <0x0>;
+ xlnx,dma0-control = <0x0>;
+ xlnx,dma0-plb-prio = <0x0>;
+ xlnx,dma0-rxchannelctrl = <0x101>;
+ xlnx,dma0-rxirqtimer = <0x3ff>;
+ xlnx,dma0-txchannelctrl = <0x101>;
+ xlnx,dma0-txirqtimer = <0x3ff>;
+ xlnx,dma1-control = <0x0>;
+ xlnx,dma1-plb-prio = <0x0>;
+ xlnx,dma1-rxchannelctrl = <0x101>;
+ xlnx,dma1-rxirqtimer = <0x3ff>;
+ xlnx,dma1-txchannelctrl = <0x101>;
+ xlnx,dma1-txirqtimer = <0x3ff>;
+ xlnx,dma2-control = <0x0>;
+ xlnx,dma2-plb-prio = <0x0>;
+ xlnx,dma2-rxchannelctrl = <0x101>;
+ xlnx,dma2-rxirqtimer = <0x3ff>;
+ xlnx,dma2-txchannelctrl = <0x101>;
+ xlnx,dma2-txirqtimer = <0x3f
Re: ipr boot failure caused by MSI (2.6.30-rc1+)
On Thu, 2009-05-21 at 14:51 -0500, James Bottomley wrote: > On Thu, 2009-05-21 at 13:47 -0500, Brian King wrote: > > cc'ing linuxppc-dev... > > > > -Brian > > > > > > James Bottomley wrote: > > > Kernels after 2.6.30-rc1 stopped booting on my powerstation. The ipr > > > just times out and refuses to probe devices. If I let it drop into the > > > initramfs system, this is what the interrupts shows: > > > > > > (initramfs) cat /proc/interrupts > > >CPU0 CPU1 CPU2 CPU3 > > > 16: 20 10 13 11 MPIC Level > > > pata_amd > > > 20: 0 0 0 0 MPIC Level > > > ohci_hcd:usb1, ohci_hcd:usb2 > > > 21: 0 0 0 0 MPIC-U3MSI Edge ipr > > > 68: 37 37 48 37 MPIC Edge > > > serial > > > 251: 10 71 69 72 MPIC Edge > > > ipi call function > > > 252: 1555 1779 1372 1155 MPIC Edge > > > ipi reschedule > > > 253: 0 0 0 0 MPIC Edge > > > ipi call function single > > > 254: 0 0 0 0 MPIC Edge > > > ipi debugger > > > BAD:416 > > > > > > So you see the IPR is the only device not receiving them. > > > > > > I can fix the boot hang by reverting > > > > > > commit 5a9ef25b14d39b8413364df12cb8d9bb7a673a32 > > > Author: Wayne Boyer > > > Date: Fri Jan 23 09:17:35 2009 -0800 > > > > > > [SCSI] ipr: add MSI support > > > > > > The system in question is: > > > > > > SYSTEM INFORMATION > > > Processor = PowerPC,970MP @ 2500 MHz > > > I/O Bridge = U4 (4.4) > > > SMP Size = 4 (#0 #1 #2 #3) > > > Boot-Date = 2009-04-21 17:13:36 > > > Memory = 2 GB of RAM @ 666 MHz > > > Board Type = Bimini (7047191/000/1) > > > MFG Date = 1608 > > > Part No. = 10N8748 > > > FRU No.= 10N7182 > > > FRU Serial = YL30W8106038 > > > UUID = > > > Flashside = 1 (temporary) > > > Version= HEAD > > > Build Date = 12-04-2008 16:13 > > OK, so as an update, I booted to the initrd and inserted the network > modules, which are also MSI enabled and this is what I get: > > (initramfs) cat /proc/interrupts >CPU0 CPU1 CPU2 CPU3 > 16: 14 11 11 18 MPIC Level > pata_amd > 20: 0 0 0 0 MPIC Level > ohci_hcd:usb1, ohci_hcd:usb2 > 21: 0 0 0 0 MPIC-U3MSI Edge ipr > 22: 1 0 1 0 MPIC-U3MSI Edge eth0 > 23: 0 2 1 0 MPIC-U3MSI Edge eth1 > 68:193166113177 MPIC Edge serial > 251: 16 65 71 70 MPIC Edge ipi > call function > 252: 1574 1804 1346 1289 MPIC Edge ipi > reschedule > 253: 0 0 0 0 MPIC Edge ipi > call function single > 254: 0 0 0 0 MPIC Edge ipi > debugger > BAD: 1866 > > So clearly the MSI interrupts to the network cards are working and it > looks like just a local problem with the ipr rather than a platform > problem with MSI. I saw the quirk fix for this go by: http://ozlabs.org/pipermail/linuxppc-dev/2009-May/072436.html Is there an easy way to trigger an interrupt on this device? Preferably in ipr_probe_ioa() so we can at least print out if the interrupts are misrouted and fall back from MSI to normal using the PCI infrastructure? James ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add a few more mpc5200 PSC defines
On Fri, May 22, 2009 at 11:33 AM, Grant Likely wrote: > On Fri, May 22, 2009 at 9:25 AM, Jon Smirl wrote: >> Add a few more mpc5200 PSC defines. More bit fields defines for mpc5200 PSC >> registers >> >> Signed-off-by: Jon Smirl > > Thanks Jon, > > What are you adding these defines for (so I can add it to the commit log)? AC97 support > > g. > >> --- >> arch/powerpc/include/asm/mpc52xx_psc.h | 11 +++ >> 1 files changed, 11 insertions(+), 0 deletions(-) >> >> diff --git a/arch/powerpc/include/asm/mpc52xx_psc.h >> b/arch/powerpc/include/asm/mpc52xx_psc.h >> index a218da6..fb84120 100644 >> --- a/arch/powerpc/include/asm/mpc52xx_psc.h >> +++ b/arch/powerpc/include/asm/mpc52xx_psc.h >> @@ -28,6 +28,10 @@ >> #define MPC52xx_PSC_MAXNUM 6 >> >> /* Programmable Serial Controller (PSC) status register bits */ >> +#define MPC52xx_PSC_SR_UNEX_RX 0x0001 >> +#define MPC52xx_PSC_SR_DATA_VAL 0x0002 >> +#define MPC52xx_PSC_SR_DATA_OVR 0x0004 >> +#define MPC52xx_PSC_SR_CMDSEND 0x0008 >> #define MPC52xx_PSC_SR_CDE 0x0080 >> #define MPC52xx_PSC_SR_RXRDY 0x0100 >> #define MPC52xx_PSC_SR_RXFULL 0x0200 >> @@ -61,6 +65,12 @@ >> #define MPC52xx_PSC_RXTX_FIFO_EMPTY 0x0001 >> >> /* PSC interrupt status/mask bits */ >> +#define MPC52xx_PSC_IMR_UNEX_RX_SLOT 0x0001 >> +#define MPC52xx_PSC_IMR_DATA_VALID 0x0002 >> +#define MPC52xx_PSC_IMR_DATA_OVR 0x0004 >> +#define MPC52xx_PSC_IMR_CMD_SEND 0x0008 >> +#define MPC52xx_PSC_IMR_ERROR 0x0040 >> +#define MPC52xx_PSC_IMR_DEOF 0x0080 >> #define MPC52xx_PSC_IMR_TXRDY 0x0100 >> #define MPC52xx_PSC_IMR_RXRDY 0x0200 >> #define MPC52xx_PSC_IMR_DB 0x0400 >> @@ -117,6 +127,7 @@ >> #define MPC52xx_PSC_SICR_SIM_FIR (0x6 << 24) >> #define MPC52xx_PSC_SICR_SIM_CODEC_24 (0x7 << 24) >> #define MPC52xx_PSC_SICR_SIM_CODEC_32 (0xf << 24) >> +#define MPC52xx_PSC_SICR_AWR (1 << 30) >> #define MPC52xx_PSC_SICR_GENCLK (1 << 23) >> #define MPC52xx_PSC_SICR_I2S (1 << 22) >> #define MPC52xx_PSC_SICR_CLKPOL (1 << 21) >> >> > > > > -- > Grant Likely, B.Sc., P.Eng. > Secret Lab Technologies Ltd. > -- Jon Smirl jonsm...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Add a few more mpc5200 PSC defines
Add a few more mpc5200 PSC defines. More bit fields defines for mpc5200 PSC registers Signed-off-by: Jon Smirl --- arch/powerpc/include/asm/mpc52xx_psc.h | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/mpc52xx_psc.h b/arch/powerpc/include/asm/mpc52xx_psc.h index a218da6..fb84120 100644 --- a/arch/powerpc/include/asm/mpc52xx_psc.h +++ b/arch/powerpc/include/asm/mpc52xx_psc.h @@ -28,6 +28,10 @@ #define MPC52xx_PSC_MAXNUM 6 /* Programmable Serial Controller (PSC) status register bits */ +#define MPC52xx_PSC_SR_UNEX_RX 0x0001 +#define MPC52xx_PSC_SR_DATA_VAL0x0002 +#define MPC52xx_PSC_SR_DATA_OVR0x0004 +#define MPC52xx_PSC_SR_CMDSEND 0x0008 #define MPC52xx_PSC_SR_CDE 0x0080 #define MPC52xx_PSC_SR_RXRDY 0x0100 #define MPC52xx_PSC_SR_RXFULL 0x0200 @@ -61,6 +65,12 @@ #define MPC52xx_PSC_RXTX_FIFO_EMPTY0x0001 /* PSC interrupt status/mask bits */ +#define MPC52xx_PSC_IMR_UNEX_RX_SLOT 0x0001 +#define MPC52xx_PSC_IMR_DATA_VALID 0x0002 +#define MPC52xx_PSC_IMR_DATA_OVR 0x0004 +#define MPC52xx_PSC_IMR_CMD_SEND 0x0008 +#define MPC52xx_PSC_IMR_ERROR 0x0040 +#define MPC52xx_PSC_IMR_DEOF 0x0080 #define MPC52xx_PSC_IMR_TXRDY 0x0100 #define MPC52xx_PSC_IMR_RXRDY 0x0200 #define MPC52xx_PSC_IMR_DB 0x0400 @@ -117,6 +127,7 @@ #define MPC52xx_PSC_SICR_SIM_FIR (0x6 << 24) #define MPC52xx_PSC_SICR_SIM_CODEC_24 (0x7 << 24) #define MPC52xx_PSC_SICR_SIM_CODEC_32 (0xf << 24) +#define MPC52xx_PSC_SICR_AWR (1 << 30) #define MPC52xx_PSC_SICR_GENCLK(1 << 23) #define MPC52xx_PSC_SICR_I2S (1 << 22) #define MPC52xx_PSC_SICR_CLKPOL(1 << 21) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add a few more mpc5200 PSC defines
On Fri, May 22, 2009 at 9:25 AM, Jon Smirl wrote: > Add a few more mpc5200 PSC defines. More bit fields defines for mpc5200 PSC > registers > > Signed-off-by: Jon Smirl Thanks Jon, What are you adding these defines for (so I can add it to the commit log)? g. > --- > arch/powerpc/include/asm/mpc52xx_psc.h | 11 +++ > 1 files changed, 11 insertions(+), 0 deletions(-) > > diff --git a/arch/powerpc/include/asm/mpc52xx_psc.h > b/arch/powerpc/include/asm/mpc52xx_psc.h > index a218da6..fb84120 100644 > --- a/arch/powerpc/include/asm/mpc52xx_psc.h > +++ b/arch/powerpc/include/asm/mpc52xx_psc.h > @@ -28,6 +28,10 @@ > #define MPC52xx_PSC_MAXNUM 6 > > /* Programmable Serial Controller (PSC) status register bits */ > +#define MPC52xx_PSC_SR_UNEX_RX 0x0001 > +#define MPC52xx_PSC_SR_DATA_VAL 0x0002 > +#define MPC52xx_PSC_SR_DATA_OVR 0x0004 > +#define MPC52xx_PSC_SR_CMDSEND 0x0008 > #define MPC52xx_PSC_SR_CDE 0x0080 > #define MPC52xx_PSC_SR_RXRDY 0x0100 > #define MPC52xx_PSC_SR_RXFULL 0x0200 > @@ -61,6 +65,12 @@ > #define MPC52xx_PSC_RXTX_FIFO_EMPTY 0x0001 > > /* PSC interrupt status/mask bits */ > +#define MPC52xx_PSC_IMR_UNEX_RX_SLOT 0x0001 > +#define MPC52xx_PSC_IMR_DATA_VALID 0x0002 > +#define MPC52xx_PSC_IMR_DATA_OVR 0x0004 > +#define MPC52xx_PSC_IMR_CMD_SEND 0x0008 > +#define MPC52xx_PSC_IMR_ERROR 0x0040 > +#define MPC52xx_PSC_IMR_DEOF 0x0080 > #define MPC52xx_PSC_IMR_TXRDY 0x0100 > #define MPC52xx_PSC_IMR_RXRDY 0x0200 > #define MPC52xx_PSC_IMR_DB 0x0400 > @@ -117,6 +127,7 @@ > #define MPC52xx_PSC_SICR_SIM_FIR (0x6 << 24) > #define MPC52xx_PSC_SICR_SIM_CODEC_24 (0x7 << 24) > #define MPC52xx_PSC_SICR_SIM_CODEC_32 (0xf << 24) > +#define MPC52xx_PSC_SICR_AWR (1 << 30) > #define MPC52xx_PSC_SICR_GENCLK (1 << 23) > #define MPC52xx_PSC_SICR_I2S (1 << 22) > #define MPC52xx_PSC_SICR_CLKPOL (1 << 21) > > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver
Hi Wolfgang, thanks for the quick response. Comments below... On Fri, May 22, 2009 at 8:46 AM, Wolfgang Grandegger wrote: > +++ net-next-2.6/Documentation/powerpc/dts-bindings/can/sja1000.txt > @@ -0,0 +1,37 @@ > +Memory mapped SJA1000 CAN controller from NXP (formerly Philips) > + > +Required properties: > + > +- compatible : should be "nxp,sja1000". > +- reg : should specify the chip select, address offset and size used > + for the chip depending on the bus it is connected to. > +- interrupts: property with a value describing the interrupt source > + (number and sensitivity) for that device. The encoding depends > + on the type of interrupt controller used. Hmmm, "reg", "interrupts", and "interrupt-parent" are well understood properties. I don't think we need to keep boilerplate defining the meaning every time a new binding is added. (general musing; not an ack or nack of this patch) However, what should be defined is *what* the register range is (ie. one tuple; location of device registers), and what the interrupts are (ie. single tuple for device's irq line). Granted this is a trivial case, but in the case of devices with more than one address range or irq line, the meaning of each tuple is critical information. I think it would be a good pattern to establish. > +Optional properties: > + > +- interrupt-parent : the phandle for the interrupt controller that > + services interrupts for that device. Thinking further; I wouldn't even mention "interrupt-parent" here. Anyone working with this stuff must already understand irq routing. > +- clock-frequency : CAN system clock frequency in Hz, which is normally > + half of the oscillator clock frequency. If not specified, a > + default value of 800 (8 MHz) is used. A clock-frequency property typically refers to the bus clock frequency. Something like can-frequency would be better. > +- cdr-reg : value of the SJA1000 clock divider register according to > + the SJA1000 data sheet. If not specified, a default value of > + 0x48 is used. Ewh. The driver should be clueful enough to derive the clock divider value given both the bus and can frequencies. I don't like this property. > +- ocr-reg : value of the SJA1000 output control register according to > + the SJA1000 data sheet. If not specified, a default value of > + 0x0a is used. Ditto here; the binding should describe the usage mode; not the register settings to get the usage mode. What sort of settings will the .dts author be writing here? Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [net-next-2.6 PATCH] can: SJA1000: generic OF platform bus driver
David Miller wrote:
> From: Grant Likely
> Date: Thu, 21 May 2009 22:42:07 -0600
>
>> On Wed, May 20, 2009 at 11:06 AM, Wolfgang Grandegger
>> wrote:
>>> This patch adds a generic driver for SJA1000 chips on the OpenFirmware
>>> platform bus found on embedded PowerPC systems. You need a SJA1000 node
>>> definition in your flattened device tree source (DTS) file similar to:
>>>
>>> c...@3,100 {
>>> compatible = "philips,sja1000";
>>> reg = <3 0x100 0x80>;
>>> clock-frequency = <800>;
>>> cdr-reg = <0x48>;
>>> ocr-reg = <0x0a>;
>>> interrupts = <2 0>;
>>> interrupt-parent = <&mpic>;
>>> };
>> This new binding must be documented in Documentation/powerpc/dts-bindings
>
> Wolfgang, please add this documentation and resubmit your patch.
> Thanks!
I just sent out v2 incuding the missing documentation.
Thanks,
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver
This patch adds a generic driver for SJA1000 chips on the OpenFirmware
platform bus found on embedded PowerPC systems. You need a SJA1000 node
definition in your flattened device tree source (DTS) file similar to:
c...@3,100 {
compatible = "nxp,sja1000";
reg = <3 0x100 0x80>;
clock-frequency = <800>;
cdr-reg = <0x48>;
ocr-reg = <0x0a>;
interrupts = <2 0>;
interrupt-parent = <&mpic>;
};
See also Documentation/powerpc/dts-bindings/can/sja1000.txt.
Signed-off-by: Wolfgang Grandegger
---
Documentation/powerpc/dts-bindings/can/sja1000.txt | 37 +++
drivers/net/can/Kconfig|9
drivers/net/can/sja1000/Makefile |1
drivers/net/can/sja1000/sja1000_of_platform.c | 215 +
4 files changed, 262 insertions(+)
Index: net-next-2.6/drivers/net/can/Kconfig
===
--- net-next-2.6.orig/drivers/net/can/Kconfig
+++ net-next-2.6/drivers/net/can/Kconfig
@@ -51,6 +51,15 @@ config CAN_SJA1000_PLATFORM
boards from Phytec (http://www.phytec.de) like the PCM027,
PCM038.
+config CAN_SJA1000_OF_PLATFORM
+ depends on CAN_SJA1000 && PPC_OF
+ tristate "Generic OF Platform Bus based SJA1000 driver"
+ ---help---
+ This driver adds support for the SJA1000 chips connected to
+ the OpenFirmware "platform bus" found on embedded systems with
+ OpenFirmware bindings, e.g. if you have a PowerPC based system
+ you may want to enable this option.
+
config CAN_EMS_PCI
tristate "EMS CPC-PCI and CPC-PCIe Card"
depends on PCI && CAN_SJA1000
Index: net-next-2.6/drivers/net/can/sja1000/Makefile
===
--- net-next-2.6.orig/drivers/net/can/sja1000/Makefile
+++ net-next-2.6/drivers/net/can/sja1000/Makefile
@@ -4,6 +4,7 @@
obj-$(CONFIG_CAN_SJA1000) += sja1000.o
obj-$(CONFIG_CAN_SJA1000_PLATFORM) += sja1000_platform.o
+obj-$(CONFIG_CAN_SJA1000_OF_PLATFORM) += sja1000_of_platform.o
obj-$(CONFIG_CAN_EMS_PCI) += ems_pci.o
obj-$(CONFIG_CAN_KVASER_PCI) += kvaser_pci.o
Index: net-next-2.6/drivers/net/can/sja1000/sja1000_of_platform.c
===
--- /dev/null
+++ net-next-2.6/drivers/net/can/sja1000/sja1000_of_platform.c
@@ -0,0 +1,215 @@
+/*
+ * Driver for SJA1000 CAN controllers on the OpenFirmware platform bus
+ *
+ * Copyright (C) 2008-2009 Wolfgang Grandegger
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the version 2 of the GNU General Public License
+ * as published by the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+/* This is a generic driver for SJA1000 chips on the OpenFirmware platform
+ * bus found on embedded PowerPC systems. You need a SJA1000 CAN node
+ * definition in your flattened device tree source (DTS) file similar to:
+ *
+ * c...@3,100 {
+ * compatible = "philips,sja1000";
+ * reg = <3 0x100 0x80>;
+ * clock-frequency = <800>;
+ * cdr-reg = <0x48>;
+ * ocr-reg = <0x0a>;
+ * interrupts = <2 0>;
+ * interrupt-parent = <&mpic>;
+ * };
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "sja1000.h"
+
+#define DRV_NAME "sja1000_of_platform"
+
+MODULE_AUTHOR("Wolfgang Grandegger ");
+MODULE_DESCRIPTION("Socket-CAN driver for SJA1000 on the OF platform bus");
+MODULE_LICENSE("GPL v2");
+
+#define SJA1000_OFP_CAN_CLOCK (1600 / 2)
+
+#define SJA1000_OFP_OCROCR_TX0_PULLDOWN
+#define SJA1000_OFP_CDR(CDR_CBP | CDR_CLK_OFF)
+
+static u8 sja1000_ofp_read_reg(const struct net_device *dev, int reg)
+{
+ return in_8((void __iomem *)(dev->base_addr + reg));
+}
+
+static void sja1000_ofp_write_reg(const struct net_device *dev, int reg, u8
val)
+{
+ out_8((void __iomem *)(dev->base_addr + reg), val);
+}
+
+static int __devexit sja1000_ofp_remove(struct of_device *ofdev)
+{
+ struct net_device *dev = dev_get_drvdata(&ofdev->dev);
+ struct device_node *np = ofdev->node;
+ struct resource res;
+
+ dev_set_drvdata(&ofdev->dev, NULL);
+
+ unregister_sja1000dev(dev);
+ free_sja1000dev(dev);
+ iounmap((void __iomem *)dev->base_addr);
+ irq_dispose_mapping(dev->irq);
+
+ of_address_to_resour
Re: [PATCH] mpc52xx_psc_spi: Convert to cs_control callback
On Thu, Apr 30, 2009 at 6:31 PM, Anton Vorontsov
wrote:
> mpc52xx_psc_spi driver is the last user of the legacy activate_cs
> and deactivate_cs callbacks, so convert the driver to the cs_control
This driver is missing a call to of_register_spi_devices(master, op->node);
Here's how I added it, but it could be done more cleanly.
diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
index 68c77a9..fe0658a 100644
--- a/drivers/spi/mpc52xx_psc_spi.c
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -370,24 +371,24 @@ static irqreturn_t mpc52xx_psc_spi_isr(int irq,
void *dev_id)
}
/* bus_num is used only for the case dev->platform_data == NULL */
-static int __init mpc52xx_psc_spi_do_probe(struct device *dev, u32 regaddr,
+static int __init mpc52xx_psc_spi_do_probe(struct of_device *op, u32 regaddr,
u32 size, unsigned int irq, s16 bus_num)
{
- struct fsl_spi_platform_data *pdata = dev->platform_data;
+ struct fsl_spi_platform_data *pdata = op->dev.platform_data;
struct mpc52xx_psc_spi *mps;
struct spi_master *master;
int ret;
- master = spi_alloc_master(dev, sizeof *mps);
+ master = spi_alloc_master(&op->dev, sizeof *mps);
if (master == NULL)
return -ENOMEM;
- dev_set_drvdata(dev, master);
+ dev_set_drvdata(&op->dev, master);
mps = spi_master_get_devdata(master);
mps->irq = irq;
if (pdata == NULL) {
- dev_warn(dev, "probe called without platform data, no "
+ dev_warn(&op->dev, "probe called without platform data, no "
"(de)activate_cs function will be called\n");
mps->activate_cs = NULL;
mps->deactivate_cs = NULL;
@@ -407,7 +408,7 @@ static int __init mpc52xx_psc_spi_do_probe(struct
device *dev, u32 regaddr,
mps->psc = ioremap(regaddr, size);
if (!mps->psc) {
- dev_err(dev, "could not ioremap I/O port range\n");
+ dev_err(&op->dev, "could not ioremap I/O port range\n");
ret = -EFAULT;
goto free_master;
}
@@ -439,6 +440,8 @@ static int __init mpc52xx_psc_spi_do_probe(struct
device *dev, u32 regaddr,
if (ret < 0)
goto unreg_master;
+ of_register_spi_devices(master, op->node);
+
return ret;
unreg_master:
@@ -495,7 +498,7 @@ static int __init mpc52xx_psc_spi_of_probe(struct
of_device *op,
id = *psc_nump + 1;
}
- return mpc52xx_psc_spi_do_probe(&op->dev, (u32)regaddr64, (u32)size64,
+ return mpc52xx_psc_spi_do_probe(op, (u32)regaddr64, (u32)size64,
irq_of_parse_and_map(op->node, 0), id);
}
--
Jon Smirl
jonsm...@gmail.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mmc: Add fsl,esdhc as a valid compatible to bind against
On Fri, 8 May 2009 08:52:49 -0500 Kumar Gala wrote: > We plan to use fsl,esdhc going forward as the base compatible so update > the driver to bind against it. > > Signed-off-by: Kumar Gala > --- Applied. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
On Thu, 2009-05-21 at 14:27 -0400, Becky Bruce wrote:
> I can work with that, but it's going to be a bit inefficient, as I
> actually need the dma_addr_t, not the phys_addr_t, so I'll have to
> convert. In every case, this is a conversion I've already done and
> that I need in the calling code as well.
Does
dma_addr_t dma_map_range(struct device *hwdev, phys_addr_t addr,
size_t size);
work for you?
If the range does not need mapping then it returns the dma address, if
you needed to calculate the dma address anyway to figure out if mapping
is required then this is fine. If the range does need mapping then it
returns NULL.
This subsumes many of the phys->dma address conversions which would
otherwise be done in the callers. IMHO this is an architecture specific
detail which should be pushed down into the arch code as much as
possible. The only ones which I don't think can be pushed down are the
ones in swiotlb_virt_to_bus/swiotlb_bus_to_virt.
BTW do you need swiotlb_bus_to_virt to be __weak or is the fact that it
is implemented in terms of swiotlb_bus_to_phys sufficient?
I have an appointment all afternoon and it's a bank holiday on Monday
but here is my WIP patch as an example of what I'm thinking. Obviously
some cleanups are still very much required:
* The Xen specific stuff in arch/x86/include/asm/dma-mapping.h
clearly needs to be properly abstracted away (I just stuck it
there for testing).
* swiotlb_phys_to_bus and swiotlb_bus_to_phys need to move to
arch/*/include/asm/dma-mapping.h instead of being __weak
* Maybe swiotlb_bus_to_virt can become static again.
* Need to finish auditing the handful of non-swiotlb users of
is_buffer_dma_capable.
* It might be possible to implement swiolb_dma_mapping_error
and/or swiotlb_dma_supported in terms of dma_map_range.
* Minor detail: it doesn't actually work at the moment ;-)
Ian.
diff --git a/arch/ia64/include/asm/dma-mapping.h
b/arch/ia64/include/asm/dma-mapping.h
index 36c0009..026667f 100644
--- a/arch/ia64/include/asm/dma-mapping.h
+++ b/arch/ia64/include/asm/dma-mapping.h
@@ -174,4 +174,12 @@ dma_cache_sync (struct device *dev, void *vaddr, size_t
size,
#define dma_is_consistent(d, h)(1) /* all we do is coherent
memory... */
+static inline dma_addr_t dma_map_range(struct device *dev, u64 mask,
+ phys_addr_t addr, size_t size)
+{
+ if (addr + size <= mask)
+ return addr;
+ return 0;
+}
+
#endif /* _ASM_IA64_DMA_MAPPING_H */
diff --git a/arch/x86/include/asm/dma-mapping.h
b/arch/x86/include/asm/dma-mapping.h
index 916cbb6..b2813ab 100644
--- a/arch/x86/include/asm/dma-mapping.h
+++ b/arch/x86/include/asm/dma-mapping.h
@@ -309,4 +309,20 @@ static inline void dma_free_coherent(struct device *dev,
size_t size,
ops->free_coherent(dev, size, vaddr, bus);
}
+static inline dma_addr_t dma_map_range(struct device *dev, u64 mask,
+ phys_addr_t addr, size_t size)
+{
+ dma_addr_t dma_addr;
+#ifdef CONFIG_XEN
+ extern int xen_range_needs_mapping(phys_addr_t paddr, size_t size);
+ if (xen_pv_domain() && xen_range_needs_mapping(addr, size))
+ return 0;
+#endif
+
+ dma_addr = swiotlb_phys_to_bus(dev, addr);
+ if (dma_addr + size <= mask)
+ return 0;
+ return dma_addr;
+}
+
#endif
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index 2fffc22..c2b4196 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -145,8 +145,8 @@ again:
if (!page)
return NULL;
- addr = page_to_phys(page);
- if (!is_buffer_dma_capable(dma_mask, addr, size)) {
+ addr = dma_map_range(dev, dma_mask, page_to_phys(page), size);
+ if (!(addr == 0)) {
__free_pages(page, get_order(size));
if (dma_mask < DMA_BIT_MASK(32) && !(flag & GFP_DMA)) {
diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
index 1e8920d..6a55770 100644
--- a/arch/x86/kernel/pci-gart_64.c
+++ b/arch/x86/kernel/pci-gart_64.c
@@ -191,13 +191,13 @@ static inline int
need_iommu(struct device *dev, unsigned long addr, size_t size)
{
return force_iommu ||
- !is_buffer_dma_capable(*dev->dma_mask, addr, size);
+ dma_map_range(dev, *dev->dma_mask, addr, size) == 0;
}
static inline int
nonforced_iommu(struct device *dev, unsigned long addr, size_t size)
{
- return !is_buffer_dma_capable(*dev->dma_mask, addr, size);
+ return dma_map_range(dev, *dev->dma_mask, addr, size) == 0;
}
/* Map a single continuous physical area into the IOMMU.
diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c
index 71d412a..712ce59 100644
--- a/arch/x86/kernel/pci-nommu.c
+++ b/arch/x86/kernel/pci-nommu.c
@@ -12,13 +12,13 @@
#include
static int
-che
Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
On Thu, 21 May 2009 13:18:54 -0700 Jeremy Fitzhardinge wrote: > Becky Bruce wrote: > > I can work with that, but it's going to be a bit inefficient, as I > > actually need the dma_addr_t, not the phys_addr_t, so I'll have to > > convert. In every case, this is a conversion I've already done and > > that I need in the calling code as well. Can we pass in both the > > phys_addr_t and the dma_addr_t? > > The Xen implementation would needs to do the phys to bus conversion page > by page anyway, so it wouldn't help much. But it also wouldn't hurt. > > How expensive is the phys-to-bus conversion on power? Is it worth > making the interface more complex for? Would passing phys+bus mean that > we wouldn't also need to pass dev? I don't think so. POWERPC needs it. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
On Thu, 21 May 2009 20:01:37 +0100 Ian Campbell wrote: > > It's not actually clear to me that we need that check, though. Can > > someone explain what case that was designed to catch? > > If map_single fails and returns NULL then we try to use > io_tlb_overflow_buffer, if that is somehow not DMA-able (for the > particular device) then the check will trigger. I would have thought we > could arrange that the overflow buffer is always OK and really if > map_page is failing we must be close the edge already. And iotlb buffers are not guaranteed to be DMA-capable; it's possible that some drivers (with poor dma address restrictions) can't handle some part of iotlb buffers. So after allocating some ioblb buffer, we need to check if the buffers are DMA-capable for a driver. Well, it's unlikely though. Well, it would be better to move the check to map_single(). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[GIT PULL] fsldma driver fixes
Hi Dan,
Here are fixes for Freescale DMA engine driver.
Thanks,
- Leo
The following changes since commit 5805977e63a36ad56594a623f3bd2bebcb7db233:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../jbarnes/drm-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/leo/fsl-soc.git fsldma
Ira Snyder (4):
fsldma: fix "DMA halt timeout!" errors
fsldma: fix infinite loop on multi-descriptor DMA chain completion
fsldma: snooping is not enabled for last entry in descriptor chain
fsldma: fix memory leak on error path in fsl_dma_prep_memcpy()
Li Yang (1):
fsldma: update mailling list address in MAINTAINERS
Roel Kluin (1):
fsldma: fix check on potential fdev->chan[] overflow
MAINTAINERS |2 +-
drivers/dma/fsldma.c | 58 ++---
2 files changed, 41 insertions(+), 19 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2b349ba..cac3e3b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2241,7 +2241,7 @@ P:Li Yang
M: le...@freescale.com
P: Zhang Wei
M: z...@zh-kernel.org
-L: linuxppc-embed...@ozlabs.org
+L: linuxppc-dev@ozlabs.org
L: linux-ker...@vger.kernel.org
S: Maintained
F: drivers/dma/fsldma.*
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index da8a8ed..1578310 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -179,9 +179,14 @@ static void dma_halt(struct fsl_dma_chan *fsl_chan)
static void set_ld_eol(struct fsl_dma_chan *fsl_chan,
struct fsl_desc_sw *desc)
{
+ u64 snoop_bits;
+
+ snoop_bits = ((fsl_chan->feature & FSL_DMA_IP_MASK) == FSL_DMA_IP_83XX)
+ ? FSL_DMA_SNEN : 0;
+
desc->hw.next_ln_addr = CPU_TO_DMA(fsl_chan,
- DMA_TO_CPU(fsl_chan, desc->hw.next_ln_addr, 64) | FSL_DMA_EOL,
- 64);
+ DMA_TO_CPU(fsl_chan, desc->hw.next_ln_addr, 64) | FSL_DMA_EOL
+ | snoop_bits, 64);
}
static void append_ld_queue(struct fsl_dma_chan *fsl_chan,
@@ -313,8 +318,8 @@ static void fsl_chan_toggle_ext_start(struct
fsl_dma_chan *fsl_chan, int enable)
static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
{
- struct fsl_desc_sw *desc = tx_to_fsl_desc(tx);
struct fsl_dma_chan *fsl_chan = to_fsl_chan(tx->chan);
+ struct fsl_desc_sw *desc;
unsigned long flags;
dma_cookie_t cookie;
@@ -322,14 +327,17 @@ static dma_cookie_t fsl_dma_tx_submit(struct
dma_async_tx_descriptor *tx)
spin_lock_irqsave(&fsl_chan->desc_lock, flags);
cookie = fsl_chan->common.cookie;
- cookie++;
- if (cookie < 0)
- cookie = 1;
- desc->async_tx.cookie = cookie;
- fsl_chan->common.cookie = desc->async_tx.cookie;
+ list_for_each_entry(desc, &tx->tx_list, node) {
+ cookie++;
+ if (cookie < 0)
+ cookie = 1;
- append_ld_queue(fsl_chan, desc);
- list_splice_init(&desc->async_tx.tx_list, fsl_chan->ld_queue.prev);
+ desc->async_tx.cookie = cookie;
+ }
+
+ fsl_chan->common.cookie = cookie;
+ append_ld_queue(fsl_chan, tx_to_fsl_desc(tx));
+ list_splice_init(&tx->tx_list, fsl_chan->ld_queue.prev);
spin_unlock_irqrestore(&fsl_chan->desc_lock, flags);
@@ -454,8 +462,8 @@ static struct dma_async_tx_descriptor *fsl_dma_prep_memcpy(
{
struct fsl_dma_chan *fsl_chan;
struct fsl_desc_sw *first = NULL, *prev = NULL, *new;
+ struct list_head *list;
size_t copy;
- LIST_HEAD(link_chain);
if (!chan)
return NULL;
@@ -472,7 +480,7 @@ static struct dma_async_tx_descriptor *fsl_dma_prep_memcpy(
if (!new) {
dev_err(fsl_chan->dev,
"No free memory for link descriptor\n");
- return NULL;
+ goto fail;
}
#ifdef FSL_DMA_LD_DEBUG
dev_dbg(fsl_chan->dev, "new link desc alloc %p\n", new);
@@ -507,7 +515,19 @@ static struct dma_async_tx_descriptor *fsl_dma_prep_memcpy(
/* Set End-of-link to the last link descriptor of new list*/
set_ld_eol(fsl_chan, new);
- return first ? &first->async_tx : NULL;
+ return &first->async_tx;
+
+fail:
+ if (!first)
+ return NULL;
+
+ list = &first->async_tx.tx_list;
+ list_for_each_entry_safe_reverse(new, prev, list, node) {
+ list_del(&new->node);
+ dma_pool_free(fsl_chan->desc_pool, new, new->async_tx.phys);
+ }
+
+ return NULL;
}
/**
@@ -598,15 +618,16 @@ static void fsl_chan_xfer_ld_queue(struct
fsl_dma_chan *fsl_chan)
dma_addr_t next_dest_addr;
unsigned long flags;
+ spin_lock_irqsave(&fsl_chan->desc_lock, flags);
+
if (!dma_is_i
Re: [PATCH] fsldma: fix memory leak on error path in fsl_dma_prep_memcpy()
On Sat, May 16, 2009 at 12:59 AM, Ira Snyder wrote: > When preparing a memcpy operation, if the kernel fails to allocate memory > for a link descriptor after the first link descriptor has already been > allocated, then some memory will never be released. Fix the problem by > walking the list of allocated descriptors backwards, and freeing the > allocated descriptors back into the DMA pool. > > Signed-off-by: Ira W. Snyder Applied the following patches: fsldma: fix "DMA halt timeout!" errors fsldma: fix infinite loop on multi-descriptor DMA chain completion fsldma: snooping is not enabled for last entry in descriptor chain fsldma: fix memory leak on error path in fsl_dma_prep_memcpy() Thanks - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: can't flush tlb on e500
On Fri, 2009-05-22 at 19:27 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-05-20 at 19:12 +0900, Saito Hideo wrote:
>
> > I think that the tlb should be cleared before mm->context.id is set
> > MMU_NO_CONTEXT.
>
> You are right, this definitely looks like a bug on platforms that have
> HW support for the tlbil instruction (and thus care about the PID for
> flushing) which afaik is only the case of recent freescale chips.
In fact, you are doubly right in that it also happens on other platforms
because local_flush_tlb_mm() will check if the PID is MMU_NO_CONTEXT
regardless of what tlbilx supports.. oops
Looks like I only ran my context torture test with CONFIG_SMP enabled.
Shame on me.
> Have you verified that this change fixes your problem ?
>
> Can you re-submit to linuxppc-dev@ozlabs.org mailing list, along with
> proper changeset comment and signed-off-by: line ?
>
> Cheers,
> Ben.
>
> > --- arch/powerpc/mm/mmu_context_nohash.c.orig 2009-03-24
> > 08:12:14.0 +0900
> > +++ arch/powerpc/mm/mmu_context_nohash.c2009-05-20 18:33:53.0
> > +0900
> > @@ -122,22 +122,22 @@ static unsigned int steal_context_up(uns
> > struct mm_struct *mm;
> > int cpu = smp_processor_id();
> >
> > /* Pick up the victim mm */
> > mm = context_mm[id];
> >
> > pr_debug("[%d] steal context %d from mm @%p\n", cpu, id, mm);
> >
> > - /* Mark this mm has having no context anymore */
> > - mm->context.id = MMU_NO_CONTEXT;
> > -
> > /* Flush the TLB for that context */
> > local_flush_tlb_mm(mm);
> >
> > + /* Mark this mm has having no context anymore */
> > + mm->context.id = MMU_NO_CONTEXT;
> > +
> > /* XXX This clear should ultimately be part of local_flush_tlb_mm */
> > __clear_bit(id, stale_map[cpu]);
> >
> > return id;
> > }
> >
> > #ifdef DEBUG_MAP_CONSISTENCY
> > static void context_check_map(void)
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@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-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: can't flush tlb on e500
On Wed, 2009-05-20 at 19:12 +0900, Saito Hideo wrote:
> I think that the tlb should be cleared before mm->context.id is set
> MMU_NO_CONTEXT.
You are right, this definitely looks like a bug on platforms that have
HW support for the tlbil instruction (and thus care about the PID for
flushing) which afaik is only the case of recent freescale chips.
Have you verified that this change fixes your problem ?
Can you re-submit to linuxppc-dev@ozlabs.org mailing list, along with
proper changeset comment and signed-off-by: line ?
Cheers,
Ben.
> --- arch/powerpc/mm/mmu_context_nohash.c.orig 2009-03-24
> 08:12:14.0 +0900
> +++ arch/powerpc/mm/mmu_context_nohash.c 2009-05-20 18:33:53.0
> +0900
> @@ -122,22 +122,22 @@ static unsigned int steal_context_up(uns
> struct mm_struct *mm;
> int cpu = smp_processor_id();
>
> /* Pick up the victim mm */
> mm = context_mm[id];
>
> pr_debug("[%d] steal context %d from mm @%p\n", cpu, id, mm);
>
> - /* Mark this mm has having no context anymore */
> - mm->context.id = MMU_NO_CONTEXT;
> -
> /* Flush the TLB for that context */
> local_flush_tlb_mm(mm);
>
> + /* Mark this mm has having no context anymore */
> + mm->context.id = MMU_NO_CONTEXT;
> +
> /* XXX This clear should ultimately be part of local_flush_tlb_mm */
> __clear_bit(id, stale_map[cpu]);
>
> return id;
> }
>
> #ifdef DEBUG_MAP_CONSISTENCY
> static void context_check_map(void)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@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-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
to access web server on PowerPC from system outside the local network
Hi, I have made web server on PowerPC and it runs nicely. Currently it is on internal network. I want to access it from any system outside the local network. Can any one let me know what is the procedure for that? Thanks for your time Raj Cricket on your mind? Visit the ultimate cricket website. Enter http://beta.cricket.yahoo.com___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] freescale: beyond ARRAY_SIZE of fdev->chan
On Wed, May 20, 2009 at 7:17 AM, Roel Kluin wrote:
> Do not go beyond ARRAY_SIZE of fdev->chan
>
> Signed-off-by: Roel Kluin
Indeed, thanks.
But I would like the title and description of this patch be changed to
like this:
fsldma: fix check on potential fdev->chan[] overflow
Fix the check of potential array overflow when using corrupted channel
device tree nodes.
> ---
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index da8a8ed..391b1bd 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -830,7 +830,7 @@ static int __devinit fsl_dma_chan_probe(struct
> fsl_dma_device *fdev,
> new_fsl_chan->reg.end - new_fsl_chan->reg.start + 1);
>
> new_fsl_chan->id = ((new_fsl_chan->reg.start - 0x100) & 0xfff) >> 7;
> - if (new_fsl_chan->id > FSL_DMA_MAX_CHANS_PER_DEVICE) {
> + if (new_fsl_chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {
> dev_err(fdev->dev, "There is no %d channel!\n",
> new_fsl_chan->id);
> err = -EINVAL;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
