Re: [PATCH 3/4 v4] video, sm501: add OF binding to support SM501
Hello Paul,
Paul Mundt wrote:
On Tue, Jan 25, 2011 at 08:20:31AM +0100, Heiko Schocher wrote:
@@ -1934,7 +1943,29 @@ static int __devinit sm501fb_probe(struct
platform_device *pdev)
}
if (info-pdata == NULL) {
-dev_info(dev, using default configuration data\n);
+int found = 0;
+#if defined(CONFIG_OF)
+struct device_node *np = pdev-dev.parent-of_node;
+const u8 *prop;
+const char *cp;
+int len;
+
+info-pdata = sm501fb_def_pdata;
+if (np) {
+/* Get EDID */
+cp = of_get_property(np, mode, len);
+if (cp)
+strcpy(fb_mode, cp);
+prop = of_get_property(np, edid, len);
+if (prop len == EDID_LENGTH) {
+info-edid_data = kmemdup(prop, EDID_LENGTH,
+ GFP_KERNEL);
+found = 1;
+}
+}
+#endif
+if (!found)
+dev_info(dev, using default configuration data\n);
}
/* probe for the presence of each panel */
Starting to get a bit pedantic.. but kmemdup() tries to do a kmalloc(),
No problem!
and so can fail. Your other patches handle the info-edid_data == NULL
case, in addition to the kfree(), but you're probably going to want to
chomp that found assignment incase of the allocation failing and falling
back on the default mode.
You also don't really have any need to keep the EDID block around after
probe as far as I can tell, so you should be able to rework this in to
something more like:
info-edid_data = kmemdup(..);
...
if (info-edid_data) {
fb_edid_to_monspecs(..);
kfree(info-edid_data);
fb_videomode_to_modelist(..);
}
...
Ok, rework this part, thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4 v4] video, sm501: add edid and commandline support
Hello Paul,
Paul Mundt wrote:
On Mon, Jan 24, 2011 at 10:57:27AM +0100, Heiko Schocher wrote:
@@ -1884,7 +1935,6 @@ static int __devinit sm501fb_probe(struct
platform_device *pdev)
if (info-pdata == NULL) {
dev_info(dev, using default configuration data\n);
-info-pdata = sm501fb_def_pdata;
}
/* probe for the presence of each panel */
I assume this is accidental? I don't see how you're compensating for this
in any of the other patches at least, as it's orthogonal from the default
mode settings.
Seems so, rework this too, thanks!
bye,
heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] e500: Erratum cpu a005 workaround
-Original Message-
From: Gala Kumar-B11780
Sent: Tuesday, January 25, 2011 3:01 PM
To: Liu Yu-B13201
Cc: linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780
Subject: Re: [PATCH] e500: Erratum cpu a005 workaround
On Jan 25, 2011, at 12:02 AM, Liu Yu wrote:
This errata can occur if a single-precision floating-point,
double-precision
floating-point or vector floating-point instruction on a
mispredicted branch
path signals one of the floating-point data interrupts
which are enabled by the
SPEFSCR (FINVE, FDBZE, FUNFE or FOVFE bits). This
interrupt must be recorded
in a one-cycle window when the misprediction is resolved.
If this extremely
rare event should occur, the result could be:
The SPE Data Exception from the mispredicted path may be reported
erroneously if a single-precision floating-point, double-precision
floating-point or vector floating-point instruction is the
second instruction
on the correct branch path.
According to errata description, some efp instructions
which are not supposed to trigger SPE exceptions
can trigger the exceptions in this case.
However, as we haven't emulated these instructions here,
a signal will send to userspace, and userspace application
would exit.
This patch re-issue the efp instruction that we haven't emulated,
so that hardware can properly execute it again if this case happen.
Signed-off-by: Liu Yu yu@freescale.com
---
This is an erratum workaround patch.
It would be better if the patch can go into 2.6.38.
arch/powerpc/include/asm/reg.h |2 +
arch/powerpc/math-emu/math_efp.c | 53
+-
2 files changed, 54 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h
b/arch/powerpc/include/asm/reg.h
index 6315edc..0abfd91 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -833,6 +833,8 @@
#define PVR_74500x8000
#define PVR_85400x8020
#define PVR_85600x8020
+#define PVR_VER_E500V1 0x8020
+#define PVR_VER_E500V2 0x8021
/*
* For the 8xx processors, all of them report the same PVR
family for
* the PowerPC core. The various versions of these
processors must be
diff --git a/arch/powerpc/math-emu/math_efp.c
b/arch/powerpc/math-emu/math_efp.c
index 41f4ef3..634830b 100644
--- a/arch/powerpc/math-emu/math_efp.c
+++ b/arch/powerpc/math-emu/math_efp.c
@@ -1,7 +1,7 @@
/*
* arch/powerpc/math-emu/math_efp.c
*
- * Copyright (C) 2006-2008 Freescale Semiconductor, Inc.
All rights reserved.
+ * Copyright (C) 2006-2008, 2010 Freescale Semiconductor, Inc.
*
* Author: Ebony Zhu, ebony@freescale.com
* Yu Liu, yu@freescale.com
@@ -104,6 +104,8 @@
#define FP_EX_MASK (FP_EX_INEXACT | FP_EX_INVALID |
FP_EX_DIVZERO | \
FP_EX_UNDERFLOW | FP_EX_OVERFLOW)
+static int have_e500_cpu_a005_erratum;
+
union dw_union {
u64 dp[1];
u32 wp[2];
@@ -652,6 +654,15 @@ update_regs:
return 0;
illegal:
+ if (have_e500_cpu_a005_erratum) {
+ /* according to e500 cpu a005 erratum, reissue
efp inst */
+ regs-nip -= 4;
+#ifdef DEBUG
+ printk(KERN_DEBUG re-issue efp inst: %08lx\n,
speinsn);
+#endif
+ return 0;
+ }
+
printk(KERN_ERR \nOoops! IEEE-754 compliance handler
encountered un-supported instruction.\ninst code: %08lx\n, speinsn);
return -ENOSYS;
}
@@ -718,3 +729,43 @@ int speround_handler(struct pt_regs *regs)
return 0;
}
+
+int __init spe_mathemu_init(void)
+{
+ u32 pvr, maj, min;
+
+ pvr = mfspr(SPRN_PVR);
+
+ if ((PVR_VER(pvr) == PVR_VER_E500V1) ||
+ (PVR_VER(pvr) == PVR_VER_E500V2)) {
+ maj = PVR_MAJ(pvr);
+ min = PVR_MIN(pvr);
+
+ /*
+* E500 revision below 1.1, 2.3, 3.1, 4.1, 5.1
+* need cpu a005 errata workaround
+*/
This isn't the way to do this. We normally add entries in
cputable.c an add a new cpu_feature_bit for the errata.
Than above we'd do:
if (cur_cpu_spec-cpu_features CPU_FTR_E500_A005_ERRATUM)
IMHO, a cpu erratum is not a cpu feature.
See there're only 32 bits can be used for all PowerPC platform to represent cpu
feature,
then is it worth consuming one of them to represent one e500 erratum?
Thanks,
Yu
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: FSL DMA engine transfer to PCI memory
I'm trying to use FSL DMA engine to perform DMA transfer from
memory buffer obtained by kmalloc() to PCI memory. This is on
custom board based on P2020 running linux-2.6.35. The PCI
device is Altera FPGA, connected directly to SoC PCI-E controller.
You'll need to use the dma engine that is part of the PCIe
interface in order to get large PCIe transfers.
I think everything else will still generate single 32bit PCIe
transfers - which are (if your measurements match mine)
exceptionally lethargic - the ISA bus is faster!
That does work provided you remember to give the dma controller
physical addresses and byteswap absolutely everything.
(Oh, and I didn't get single word transfers to work - they locked
the dma controller - not a problem since they are faster by PIO.)
Note that the PPC Linux (Linux in general??) doesn't have a
'virtual to physical' function that works for all addresses,
you'll need to remember the physical address of the PCIe slave
and use malloc'ed memory for the descriptors (on which
virt_to_phys() actually works).
I don't think there is a standard device driver for the PCIe dma,
I couldn't even find any header files that were vaugely relevent
except in the uboot sources.
I certainly wrote some code that just assumes it is on the right
hardware!
These are the relevant bits of code
Global initialisation:
/* Enable the read/write dma controllers */
csb_ctrl = in_le32(pex-pex_csb_ctrl);
csb_ctrl |= PEX_CSB_CTRL_WDMAE | PEX_CSB_CTRL_RDMAE;
out_le32(pex-pex_csb_ctrl, csb_ctrl);
/* We don't rely on the dma polling the descriptor, I have NFI
* whether the default of 0 means 'never poll' or 'poll very
quickly'.
* Set a large slow value for sanity. */
out_le32(pex-pex_dms_dstmr, ~0u);
Transfer setup:
/* We only support aligned writes - caller must verify */
dma_ctrl = PDMAD_CTRL_VALID;
dma_ctrl |= PDMAD_CTRL_SNOOP_CSB;
dma_ctrl |= PDMAD_CTRL_1ST_BYTES | PDMAD_CTRL_LAST_BYTES;
dma_ctrl |= PDMAD_CTRL_NEXT_VALID;
dma_ctrl |= len (PDMAD_CTRL_LEN_SHIFT - 2);
/* Fill in DMA descriptor */
st_le32(desc-pdmad_ctrl, dma_ctrl);
/* We MUST clear the status - otherwise the xfer will be skipped */
st_le32(desc-pdmad_stat, 0);
st_le32(desc-pdmad_src_address, src_phys);
st_le32(desc-pdmad_dst_address, dst_phys);
st_le32(desc-pdmad_next_desc, 0);
/* Clear old status */
st_le32(pex_dma-pex_dma_stat, in_le32(pex_dma-pex_dma_stat));
/* Give descriptor address to dma engine */
st_le32(pex_dma-pex_dma_addr, virt_to_phys(desc));
/* Wait for all above memory cycles, then start xfer */
iosync();
st_le32(pex_dma-pex_dma_ctrl, PEX_DMA_CTRL_START |
PEX_DMA_CTRL_SNOOP);
Poll for completion:
/* Wait for transfer to complete/fail */
do {
desc_stat = ld_le32(desc-pdmad_stat);
} while (!(desc_stat PDMAD_STAT_DONE));
status = ld_le32(pex_dma-pex_dma_stat);
if (status == (PEX_DMA_STAT_DSCPL | PEX_DMA_STAT_CHCPL)
desc_stat == PDMAD_STAT_DONE)
/* Transfer ok */
return 0;
/* Transfer failed */
Oh, since I couldn't find it in the documentation, the first
word of the dma descriptor is 'ctrl' and the last 'next_desc'.
David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: FSL DMA engine transfer to PCI memory
Hi Ira,
On 01/25/2011 02:18 AM, Ira W. Snyder wrote:
On Tue, Jan 25, 2011 at 01:39:39AM +0200, Felix Radensky wrote:
Hi Ira, Scott
On 01/25/2011 12:26 AM, Ira W. Snyder wrote:
On Mon, Jan 24, 2011 at 11:47:22PM +0200, Felix Radensky wrote:
Hi,
I'm trying to use FSL DMA engine to perform DMA transfer from
memory buffer obtained by kmalloc() to PCI memory. This is on
custom board based on P2020 running linux-2.6.35. The PCI
device is Altera FPGA, connected directly to SoC PCI-E controller.
01:00.0 Unassigned class [ff00]: Altera Corporation Unknown device
0004 (rev 01)
Subsystem: Altera Corporation Unknown device 0004
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
TAbort-TAbort-MAbort-SERR-PERR-
Interrupt: pin A routed to IRQ 16
Region 0: Memory at c000 (32-bit, non-prefetchable)
[size=128K]
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
Queue=0/0 Enable-
Address: Data:
Capabilities: [78] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] Express Endpoint IRQ 0
Device: Supported: MaxPayload 256 bytes, PhantFunc 0,
ExtTag-
Device: Latency L0s64ns, L11us
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal-
Unsupported-
Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 1
Link: Latency L0s unlimited, L1 unlimited
Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Capabilities: [100] Virtual Channel
I can successfully writel() to PCI memory via address obtained from
pci_ioremap_bar().
Here's my DMA transfer routine
static int dma_transfer(struct dma_chan *chan, void *dst, void *src,
size_t len)
{
int rc = 0;
dma_addr_t dma_src;
dma_addr_t dma_dst;
dma_cookie_t cookie;
struct completion cmp;
enum dma_status status;
enum dma_ctrl_flags flags = 0;
struct dma_device *dev = chan-device;
struct dma_async_tx_descriptor *tx = NULL;
unsigned long tmo = msecs_to_jiffies(FPGA_DMA_TIMEOUT_MS);
dma_src = dma_map_single(dev-dev, src, len, DMA_TO_DEVICE);
if (dma_mapping_error(dev-dev, dma_src)) {
printk(KERN_ERR Failed to map src for DMA\n);
return -EIO;
}
dma_dst = (dma_addr_t)dst;
flags = DMA_CTRL_ACK |
DMA_COMPL_SRC_UNMAP_SINGLE |
DMA_COMPL_SKIP_DEST_UNMAP |
DMA_PREP_INTERRUPT;
tx = dev-device_prep_dma_memcpy(chan, dma_dst, dma_src, len, flags);
if (!tx) {
printk(KERN_ERR %s: Failed to prepare DMA transfer\n,
__FUNCTION__);
dma_unmap_single(dev-dev, dma_src, len, DMA_TO_DEVICE);
return -ENOMEM;
}
init_completion(cmp);
tx-callback = dma_callback;
tx-callback_param =cmp;
cookie = tx-tx_submit(tx);
if (dma_submit_error(cookie)) {
printk(KERN_ERR %s: Failed to start DMA transfer\n,
__FUNCTION__);
return -ENOMEM;
}
dma_async_issue_pending(chan);
tmo = wait_for_completion_timeout(cmp, tmo);
status = dma_async_is_tx_complete(chan, cookie, NULL, NULL);
if (tmo == 0) {
printk(KERN_ERR %s: Transfer timed out\n, __FUNCTION__);
rc = -ETIMEDOUT;
} else if (status != DMA_SUCCESS) {
printk(KERN_ERR %s: Transfer failed: status is %s\n,
__FUNCTION__,
status == DMA_ERROR ? error : in progress);
dev-device_control(chan, DMA_TERMINATE_ALL, 0);
rc = -EIO;
}
return rc;
}
The destination address is PCI memory address returned by
pci_ioremap_bar().
The transfer silently fails, destination buffer doesn't change
contents, but no
error condition is reported.
What am I doing wrong ?
Thanks a lot in advance.
Your destination address is wrong. The device_prep_dma_memcpy() routine
works in physical addresses only (dma_addr_t type). Your source address
looks fine: you're using the result of dma_map_single(), which returns a
physical address.
Your destination address should be something that comes from struct
pci_dev.resource[x].start + offset if necessary. In your lspci output
above, that will be 0xc000.
Another possible problem: AFAIK you must use the _ONSTACK() variants
from include/linux/completion.h for struct
FW: FSL DMA engine transfer to PCI memory
memcpy_toio() works fine, the data is written correctly. After DMA, the correct data appears at offsets 0xC, 0x1C, 0x2C, etc. of the destination buffer. I have 12 bytes of junk, 4 bytes of correct data, then again 12 bytes of junk and so on. Does your Avalon MM slave decode the 4 byte enables? The slave always sees 2 Avalon MM writes, one of which will have no byte enables asserted. (Actually it is a 64bit Avalon transfer - and a bus width adapter gets inserted for you.) Internal M9K memory blocks get this right... David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: FSL DMA engine transfer to PCI memory
On Tue, Jan 25, 2011 at 04:32:02PM +0200, Felix Radensky wrote:
Hi Ira,
On 01/25/2011 02:18 AM, Ira W. Snyder wrote:
On Tue, Jan 25, 2011 at 01:39:39AM +0200, Felix Radensky wrote:
Hi Ira, Scott
On 01/25/2011 12:26 AM, Ira W. Snyder wrote:
On Mon, Jan 24, 2011 at 11:47:22PM +0200, Felix Radensky wrote:
Hi,
I'm trying to use FSL DMA engine to perform DMA transfer from
memory buffer obtained by kmalloc() to PCI memory. This is on
custom board based on P2020 running linux-2.6.35. The PCI
device is Altera FPGA, connected directly to SoC PCI-E controller.
01:00.0 Unassigned class [ff00]: Altera Corporation Unknown device
0004 (rev 01)
Subsystem: Altera Corporation Unknown device 0004
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
TAbort-TAbort-MAbort-SERR-PERR-
Interrupt: pin A routed to IRQ 16
Region 0: Memory at c000 (32-bit, non-prefetchable)
[size=128K]
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
Queue=0/0 Enable-
Address: Data:
Capabilities: [78] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] Express Endpoint IRQ 0
Device: Supported: MaxPayload 256 bytes, PhantFunc 0,
ExtTag-
Device: Latency L0s64ns, L11us
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal-
Unsupported-
Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s,
Port 1
Link: Latency L0s unlimited, L1 unlimited
Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Capabilities: [100] Virtual Channel
I can successfully writel() to PCI memory via address obtained from
pci_ioremap_bar().
Here's my DMA transfer routine
static int dma_transfer(struct dma_chan *chan, void *dst, void *src,
size_t len)
{
int rc = 0;
dma_addr_t dma_src;
dma_addr_t dma_dst;
dma_cookie_t cookie;
struct completion cmp;
enum dma_status status;
enum dma_ctrl_flags flags = 0;
struct dma_device *dev = chan-device;
struct dma_async_tx_descriptor *tx = NULL;
unsigned long tmo = msecs_to_jiffies(FPGA_DMA_TIMEOUT_MS);
dma_src = dma_map_single(dev-dev, src, len, DMA_TO_DEVICE);
if (dma_mapping_error(dev-dev, dma_src)) {
printk(KERN_ERR Failed to map src for DMA\n);
return -EIO;
}
dma_dst = (dma_addr_t)dst;
flags = DMA_CTRL_ACK |
DMA_COMPL_SRC_UNMAP_SINGLE |
DMA_COMPL_SKIP_DEST_UNMAP |
DMA_PREP_INTERRUPT;
tx = dev-device_prep_dma_memcpy(chan, dma_dst, dma_src, len,
flags);
if (!tx) {
printk(KERN_ERR %s: Failed to prepare DMA transfer\n,
__FUNCTION__);
dma_unmap_single(dev-dev, dma_src, len, DMA_TO_DEVICE);
return -ENOMEM;
}
init_completion(cmp);
tx-callback = dma_callback;
tx-callback_param =cmp;
cookie = tx-tx_submit(tx);
if (dma_submit_error(cookie)) {
printk(KERN_ERR %s: Failed to start DMA transfer\n,
__FUNCTION__);
return -ENOMEM;
}
dma_async_issue_pending(chan);
tmo = wait_for_completion_timeout(cmp, tmo);
status = dma_async_is_tx_complete(chan, cookie, NULL, NULL);
if (tmo == 0) {
printk(KERN_ERR %s: Transfer timed out\n, __FUNCTION__);
rc = -ETIMEDOUT;
} else if (status != DMA_SUCCESS) {
printk(KERN_ERR %s: Transfer failed: status is %s\n,
__FUNCTION__,
status == DMA_ERROR ? error : in progress);
dev-device_control(chan, DMA_TERMINATE_ALL, 0);
rc = -EIO;
}
return rc;
}
The destination address is PCI memory address returned by
pci_ioremap_bar().
The transfer silently fails, destination buffer doesn't change
contents, but no
error condition is reported.
What am I doing wrong ?
Thanks a lot in advance.
Your destination address is wrong. The device_prep_dma_memcpy() routine
works in physical addresses only (dma_addr_t type). Your source address
looks fine: you're using the result of dma_map_single(), which returns a
RE: FSL DMA engine transfer to PCI memory
custom board based on P2020 running linux-2.6.35. The PCI device is Altera FPGA, connected directly to SoC PCI-E controller. This sounds like your FPGA doesn't handle burst mode accesses correctly. A logic analyzer will help you prove it. He is doing PCIe, not PCI. A PCIe transfers is an HDLC packet pair, one containing the request, the other the response. In order to get any significant throughput the hdlc packet(s) have to contain all the data (eg 128 bytes). On the ppc we used that means you have to use the dma controller inside the PCIe interface block. The generic dma controller can't even generate 64bit cycles into the ppc's PCIe engine. David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: FSL DMA engine transfer to PCI memory
On Tue, 25 Jan 2011 16:34:49 + David Laight david.lai...@aculab.com wrote: custom board based on P2020 running linux-2.6.35. The PCI device is Altera FPGA, connected directly to SoC PCI-E controller. This sounds like your FPGA doesn't handle burst mode accesses correctly. A logic analyzer will help you prove it. He is doing PCIe, not PCI. A PCIe transfers is an HDLC packet pair, one containing the request, the other the response. In order to get any significant throughput the hdlc packet(s) have to contain all the data (eg 128 bytes). On the ppc we used that means you have to use the dma controller inside the PCIe interface block. What was the ppc you used? On 85xx/QorIQ-family chips such as P2020, there is no DMA controller inside the PCIe controller itself (or are you talking about bus mastering by the PCIe device[1]? interface is a bit ambiguous), though it was considered part of the PCI controller on 82xx. The DMA engine and PCIe are both on OCeaN, so the traffic does not need to pass through the e500 Coherency Module. My understanding -- for what it's worth, coming from a software person :-) -- is that you should be able to get large transfer chunks using the DMA engine. I suggest getting things working, and then seeing whether the performance is acceptable. The generic dma controller can't even generate 64bit cycles into the ppc's PCIe engine. Could you elaborate? -Scott [1] To the original poster, is there any reason you're not doing bus mastering from the PCIe device, assuming you control the content of the FPGA? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V8 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
-Original Message- From: Greg KH [mailto:g...@kroah.com] Sent: Saturday, January 22, 2011 7:02 PM To: tma...@apm.com Cc: linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH V8 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver On Wed, Jan 19, 2011 at 02:57:16PM -0800, tma...@apm.com wrote: From: Tirumala Marri tma...@apm.com v8: 1. Add set_wedge to usb_ep_ops. v7: 1. Fix sparse tool warnings. 2. Fix checkpatch errors and warnings. 3. Rename USB_OTG config variable to USB_DWC_CONFIG Tirumala Marri (10): USB/ppc4xx: Add Synopsys DWC OTG Register definitions USB/ppc4xx: Add Synopsys DWC OTG driver framework USB/ppc4xx: Add Synopsys DWC OTG Core Interface Layer USB/ppc4xx: Add Synopsys DWC OTG HCD function USB/ppc4xx: Add Synopsys DWC OTG HCD interrupt function USB/ppc4xx: Add Synopsys DWC OTG HCD queue function USB/ppc4xx: Add Synopsys DWC OTG PCD function USB ppc4xx: Add Synopsys DWC OTG PCD interrupt function USB/ppc4xx:Synopsys DWC OTG driver enable gadget support USB ppc4xx: Add Synopsys DWC OTG driver kernel configuration and Makefile drivers/Makefile|2 + drivers/usb/Kconfig |3 +- drivers/usb/dwc_otg/Kconfig | 96 ++ Why are you creating a new subdirectory here? Shouldn't it be in drivers/usb/otg/dwc/ instead? drivers/usb/dwc_otg/Makefile| 19 + drivers/usb/dwc_otg/dwc_otg_apmppc.c| 414 ++ drivers/usb/dwc_otg/dwc_otg_cil.c | 972 drivers/usb/dwc_otg/dwc_otg_cil.h | 1220 +++ drivers/usb/dwc_otg/dwc_otg_cil_intr.c | 616 drivers/usb/dwc_otg/dwc_otg_driver.h| 76 + drivers/usb/dwc_otg/dwc_otg_hcd.c | 2466 +++ drivers/usb/dwc_otg/dwc_otg_hcd.h | 416 ++ drivers/usb/dwc_otg/dwc_otg_hcd_intr.c | 1477 ++ drivers/usb/dwc_otg/dwc_otg_hcd_queue.c | 696 + drivers/usb/dwc_otg/dwc_otg_param.c | 180 +++ drivers/usb/dwc_otg/dwc_otg_pcd.c | 1766 ++ drivers/usb/dwc_otg/dwc_otg_pcd.h | 139 ++ drivers/usb/dwc_otg/dwc_otg_pcd_intr.c | 2311 + drivers/usb/dwc_otg/dwc_otg_regs.h | 1325 + As you are in your own subdir, no need to put dwc_otg_ at the start of every file name, right? Care to make these changes and resend? [Marri] Sure I will make changes and resend. -Marri ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
750gx cpufreq induced kernel panic in 2.6.36
Hi, The cpufreq driver I wrote for the 750gx causes a kernel panic in 2.6.36. This is from a screen shot: [c6035f30] [c001014c] timer_interrupt+0x13c/0x19c [c6035f40] [c0013294] ret_from_except+0x0/0x14 --- Exception: 901 at 0x1000c694 LR = 0x1000f3e4 Instruction dump: 4b48 38610008 4be7b2b1 4b9c 9421fff0 7c0802a6 bfc10xxx 90010014 7ca6 68008000 54008ffe 0f00 3d20c030 2f84 Kernel panic - not syncing: Fatal exception in interrupt Call Trace: [c6035bf0] [c00084e4] show_stack+0x3c/0x160 (unreliable) [c6035c20] [c002cf44] panic+0xa4/0x1c8 [c6035c70] [c001085c] die+0x194/0x1a0 [c6035c90] [c0010aa8] _exception+0xfc/0x108 [c6035d80] [c0013248] ret_from_except_full+0x0/0x4c --- Exception: 700 at cpufreq_notify_transition+0x20/0x128 LR = cf750gx_pll_switch_cb+0x20/0xd0 [cf750gx] [c6035e40] [c02e2280] 0xc02e2280 (unreliable) [c6035e50] [ddc4b3dc] cf750gx_pll_switch_cb+0x20/0xd0 [cf750gx] [c6035e60] [c004d7ac] notifier_call_chain+0x60/0xb0 [c6035e80] [ddc361c4] pllif_i_switch_PLLs+0xa0/0x140 [pll_if] [c6035e90] [ddc365fc] pllif_i_timer_f+0x4c/0x6c [pll_if] [c6035ea0] [c004bb24] __run_hrtimer+0x44/0xb8 [c6035eb0] [c004c1f8] hrtimer_interrupt+0x10c/0x388 [c6035f30] [c001014c] timer_interrupt+0x13c/0x19c [c6035f40] [c0013294] ret_from_except+0x0/0x14 --- Exception: 901 at 0x1000c694 LR = 0x1000f3e4 Rebooting in 180 seconds.._ What are exception 700 901? The 0x1000c694 address looks fishy? Thanks! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 750gx cpufreq induced kernel panic in 2.6.36
On Tue, 2011-01-25 at 17:54 -0600, kevin diggs wrote: Hi, The cpufreq driver I wrote for the 750gx causes a kernel panic in 2.6.36. This is from a screen shot: [c6035f30] [c001014c] timer_interrupt+0x13c/0x19c [c6035f40] [c0013294] ret_from_except+0x0/0x14 --- Exception: 901 at 0x1000c694 LR = 0x1000f3e4 Instruction dump: 4b48 38610008 4be7b2b1 4b9c 9421fff0 7c0802a6 bfc10xxx 90010014 7ca6 68008000 54008ffe 0f00 3d20c030 2f84 Kernel panic - not syncing: Fatal exception in interrupt Call Trace: [c6035bf0] [c00084e4] show_stack+0x3c/0x160 (unreliable) [c6035c20] [c002cf44] panic+0xa4/0x1c8 [c6035c70] [c001085c] die+0x194/0x1a0 [c6035c90] [c0010aa8] _exception+0xfc/0x108 [c6035d80] [c0013248] ret_from_except_full+0x0/0x4c --- Exception: 700 at cpufreq_notify_transition+0x20/0x128 LR = cf750gx_pll_switch_cb+0x20/0xd0 [cf750gx] [c6035e40] [c02e2280] 0xc02e2280 (unreliable) [c6035e50] [ddc4b3dc] cf750gx_pll_switch_cb+0x20/0xd0 [cf750gx] [c6035e60] [c004d7ac] notifier_call_chain+0x60/0xb0 [c6035e80] [ddc361c4] pllif_i_switch_PLLs+0xa0/0x140 [pll_if] [c6035e90] [ddc365fc] pllif_i_timer_f+0x4c/0x6c [pll_if] [c6035ea0] [c004bb24] __run_hrtimer+0x44/0xb8 [c6035eb0] [c004c1f8] hrtimer_interrupt+0x10c/0x388 [c6035f30] [c001014c] timer_interrupt+0x13c/0x19c [c6035f40] [c0013294] ret_from_except+0x0/0x14 --- Exception: 901 at 0x1000c694 LR = 0x1000f3e4 Rebooting in 180 seconds.._ What are exception 700 901? 700 is a program check (illegal instruction or BUG_ON() statement) 900 is decrementer (aka timer) interrupt. The 0x1000c694 address looks fishy? That's userspace. So you took a timer interrupt, which got into hrtimer, and something you did caused cpufreq_notify_transition to crash, probably with a BUG_ON (which you can probably see above what you pasted, unless you don't have access to that part of the backtrace). Cheers, Ben. Thanks! kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/4 v5] video, sm501: add edid and commandline support
- add commandline options:
sm501fb.mode:
Specify resolution as xresxyres[-bpp][@refresh]
sm501fb.bpp:
Specify bit-per-pixel if not specified mode
- Add support for encoding display mode information
in the device tree using verbatim EDID block.
If the edid entry in the smi,sm501 node is present,
the driver will build mode database using EDID data
and allow setting the display modes from this database.
Signed-off-by: Heiko Schocher h...@denx.de
cc: linux-fb...@vger.kernel.org
cc: devicetree-disc...@ozlabs.org
cc: Ben Dooks b...@simtec.co.uk
cc: Vincent Sanders vi...@simtec.co.uk
cc: Samuel Ortiz sa...@linux.intel.com
cc: linux-ker...@vger.kernel.org
cc: Randy Dunlap rdun...@xenotime.net
cc: Paul Mundt let...@linux-sh.org
---
- changes since v1:
add Ben Dooks, Vincent Sanders and Samuel Ortiz to cc, as suggested from
Paul Mundt.
- changes since v2:
add comments from Randy Dunlap:
- move parameter documentation to Documentation/fb/sm501.txt
- changes since v3:
- rebased against v2.6.38-rc2
- split in 3 patches
- of support patch
- i/o routine patch
- edid support patch
- changes since v4:
- add info-pdata = sm501fb_def_pdata; in sm501fb_probe()
as Paul Mundt suggested (and I wrongly deleted)
- move kfree(info-edid_data); to patch 3/4
as edid_data is only allocated in the CONFIG_OF case
./scripts/checkpatch.pl 0002-video-sm501-add-edid-and-commandline-support.patch
total: 0 errors, 0 warnings, 109 lines checked
0002-video-sm501-add-edid-and-commandline-support.patch has no obvious style
problems and is ready for submission.
Documentation/fb/sm501.txt | 10 +++
drivers/video/sm501fb.c| 65 ---
2 files changed, 70 insertions(+), 5 deletions(-)
create mode 100644 Documentation/fb/sm501.txt
diff --git a/Documentation/fb/sm501.txt b/Documentation/fb/sm501.txt
new file mode 100644
index 000..8d17aeb
--- /dev/null
+++ b/Documentation/fb/sm501.txt
@@ -0,0 +1,10 @@
+Configuration:
+
+You can pass the following kernel command line options to sm501
videoframebuffer:
+
+ sm501fb.bpp=SM501 Display driver:
+ Specifiy bits-per-pixel if not specified by 'mode'
+
+ sm501fb.mode= SM501 Display driver:
+ Specify resolution as
+ xresxyres[-bpp][@refresh]
diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c
index c5b4b95..d60b2a2 100644
--- a/drivers/video/sm501fb.c
+++ b/drivers/video/sm501fb.c
@@ -41,6 +41,26 @@
#include linux/sm501.h
#include linux/sm501-regs.h
+#include edid.h
+
+static char *fb_mode = 640x480-16@60;
+static unsigned long default_bpp = 16;
+
+static struct fb_videomode __devinitdata sm501_default_mode = {
+ .refresh= 60,
+ .xres = 640,
+ .yres = 480,
+ .pixclock = 20833,
+ .left_margin= 142,
+ .right_margin = 13,
+ .upper_margin = 21,
+ .lower_margin = 1,
+ .hsync_len = 69,
+ .vsync_len = 3,
+ .sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ .vmode = FB_VMODE_NONINTERLACED
+};
+
#define NR_PALETTE 256
enum sm501_controller {
@@ -77,6 +97,7 @@ struct sm501fb_info {
void __iomem*regs2d;/* 2d remapped registers */
void __iomem*fbmem; /* remapped framebuffer */
size_t fbmem_len; /* length of remapped region */
+ u8 *edid_data;
};
/* per-framebuffer private data */
@@ -1725,9 +1746,16 @@ static int sm501fb_init_fb(struct fb_info *fb,
fb-var.vmode = FB_VMODE_NONINTERLACED;
fb-var.bits_per_pixel = 16;
+ if (info-edid_data) {
+ /* Now build modedb from EDID */
+ fb_edid_to_monspecs(info-edid_data, fb-monspecs);
+ fb_videomode_to_modelist(fb-monspecs.modedb,
+fb-monspecs.modedb_len,
+fb-modelist);
+ }
+
if (enable (pd-flags SM501FB_FLAG_USE_INIT_MODE) 0) {
/* TODO read the mode from the current display */
-
} else {
if (pd-def_mode) {
dev_info(info-dev, using supplied mode\n);
@@ -1737,12 +1765,34 @@ static int sm501fb_init_fb(struct fb_info *fb,
fb-var.xres_virtual = fb-var.xres;
fb-var.yres_virtual = fb-var.yres;
} else {
- ret = fb_find_mode(fb-var, fb,
+ if (info-edid_data)
+ ret = fb_find_mode(fb-var, fb, fb_mode,
+ fb-monspecs.modedb,
+ fb-monspecs.modedb_len,
+ sm501_default_mode, default_bpp);
+ else
[PATCH 3/4 v5] video, sm501: add OF binding to support SM501
- add binding to OF, compatible name smi,sm501
Signed-off-by: Heiko Schocher h...@denx.de
cc: linux-fb...@vger.kernel.org
cc: devicetree-disc...@ozlabs.org
cc: Ben Dooks b...@simtec.co.uk
cc: Vincent Sanders vi...@simtec.co.uk
cc: Samuel Ortiz sa...@linux.intel.com
cc: linux-ker...@vger.kernel.org
cc: Randy Dunlap rdun...@xenotime.net
cc: Paul Mundt let...@linux-sh.org
---
- changes since v1:
add Ben Dooks, Vincent Sanders and Samuel Ortiz to cc, as suggested from
Paul Mundt.
- changes since v2:
add comments from Randy Dunlap:
- move parameter documentation to Documentation/fb/sm501.txt
- changes since v3:
- rebased against v2.6.38-rc2
- split in 3 patches
- of support patch
- get rid of #if defined(CONFIG_PPC_MPC52xx) usage
hide this in DTS, as Paul suggested.
- i/o routine patch
- edid support patch
- changes since v4
replace remaining CONFIG_PPC_MPC52xx with CONFIG_OF, as
it is no longer MPC52xx only.
- changes since v5
free edid_data after its usage, as it is no longer needed,
suggested from Paul Mundt. Also fall back to default if
kmemdup(edid_data) fails.
./scripts/checkpatch.pl 0003-video-sm501-add-OF-binding-to-support-SM501.patch
total: 0 errors, 0 warnings, 132 lines checked
0003-video-sm501-add-OF-binding-to-support-SM501.patch has no obvious style
problems and is ready for submission.
Documentation/powerpc/dts-bindings/sm501.txt | 34 +
drivers/mfd/sm501.c |9 +-
drivers/video/sm501fb.c | 42 --
3 files changed, 81 insertions(+), 4 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt
diff --git a/Documentation/powerpc/dts-bindings/sm501.txt
b/Documentation/powerpc/dts-bindings/sm501.txt
new file mode 100644
index 000..7d319fb
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/sm501.txt
@@ -0,0 +1,34 @@
+* SM SM501
+
+The SM SM501 is a LCD controller, with proper hardware, it can also
+drive DVI monitors.
+
+Required properties:
+- compatible : should be smi,sm501.
+- reg : contain two entries:
+- First entry: System Configuration register
+- Second entry: IO space (Display Controller register)
+- interrupts : SMI interrupt to the cpu should be described here.
+- interrupt-parent : the phandle for the interrupt controller that
+ services interrupts for this device.
+
+Optional properties:
+- mode : select a video mode:
+xresxyres[-bpp][@refresh]
+- edid : verbatim EDID data block describing attached display.
+ Data from the detailed timing descriptor will be used to
+ program the display controller.
+- little-endian: availiable on big endian systems, to
+ set different foreign endian.
+- big-endian: availiable on little endian systems, to
+ set different foreign endian.
+
+Example for MPC5200:
+ display@1,0 {
+ compatible = smi,sm501;
+ reg = 1 0x 0x0080
+ 1 0x03e0 0x0020;
+ interrupts = 1 1 3;
+ mode = 640x480-32@60;
+ edid = [edid-data];
+ };
diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c
index 558d5f3..df3702c 100644
--- a/drivers/mfd/sm501.c
+++ b/drivers/mfd/sm501.c
@@ -1377,7 +1377,7 @@ static int __devinit sm501_init_dev(struct sm501_devdata
*sm)
sm501_register_gpio(sm);
}
- if (pdata-gpio_i2c != NULL pdata-gpio_i2c_nr 0) {
+ if (pdata pdata-gpio_i2c != NULL pdata-gpio_i2c_nr 0) {
if (!sm501_gpio_isregistered(sm))
dev_err(sm-dev, no gpio available for i2c gpio.\n);
else
@@ -1422,6 +1422,7 @@ static int __devinit sm501_plat_probe(struct
platform_device *dev)
sm-io_res = platform_get_resource(dev, IORESOURCE_MEM, 1);
sm-mem_res = platform_get_resource(dev, IORESOURCE_MEM, 0);
+
if (sm-io_res == NULL || sm-mem_res == NULL) {
dev_err(dev-dev, failed to get IO resource\n);
ret = -ENOENT;
@@ -1735,10 +1736,16 @@ static struct pci_driver sm501_pci_driver = {
MODULE_ALIAS(platform:sm501);
+static struct of_device_id __devinitdata of_sm501_match_tbl[] = {
+ { .compatible = smi,sm501, },
+ { /* end */ }
+};
+
static struct platform_driver sm501_plat_driver = {
.driver = {
.name = sm501,
.owner = THIS_MODULE,
+ .of_match_table = of_sm501_match_tbl,
},
.probe = sm501_plat_probe,
.remove = sm501_plat_remove,
diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c
index d60b2a2..92b001d 100644
--- a/drivers/video/sm501fb.c
+++ b/drivers/video/sm501fb.c
@@ -1729,6 +1729,15 @@ static int sm501fb_init_fb(struct fb_info *fb,
FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_FILLRECT |
FBINFO_HWACCEL_XPAN | FBINFO_HWACCEL_YPAN;
+#if defined(CONFIG_OF)
