Re: fsl-esdhc on P2020 weird endianess behavior
Elie De Brauwer wrote: On 01/24/11 04:26, tiejun.chen wrote: Elie De Brauwer wrote: Hello list, I have a P2020 processor on a custom board which uses the embedded fsl-esdhc controller. Hardware-wise this is functional and in u-boot everything seems to behave (mmc part 0 gives the correct partition table and ext2ls/fatls are capable of reading the contents of the sd card). However as soon as I start Linux (2.6.36), I get all sorts of unwanted behavior. Linux is unable to detect the partition layout (but if I do a Can you re-partition that under Linux? i.e, you can use fdisk to do this. Then I'm a bit curious what it'll be happened. This was already partitioned under (x86) Linux, and when I plug it into I means you should partition the disk on the PPC Linux, not x86. As you know x86 work with LE for Linux, but PPC with BE. So I think you should partition that on the same type machine. Can you try it? my laptop it sees the MBR (but also on target, in U-boot, the mmc part 0 command shows the correct partition table). And this does not explain I didn't check this implemented codes within u-boot. Maybe u-boot can do something to swap MMC ending problem. You can try to get the conclusion. Firstly you can re-partition that on PPC Linux then check if u-boot can identify it properly. I guess u-boot still can read that successfully. Tiejun why the card registers (such as the scr pasted below) also seem to have their endianess swapped, which will result in other side-effects, such as improper reading of card capabilities. hexdump of the MBR, I see the endianness is swapped (last 4 bytes are aa 55 00 00). Also when I try to obtain the card registers they show the same behavior: # cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr b502 While for comparison the same value on my (x86) laptop gives: edb@lapedb:/sys/devices/pci:00/:00:1e.0/:15:00.2/mmc_host/mmc0/mmc0:0001$ cat scr 02b5 In my config I have the following set: CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_IO_ACCESSORS=y CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y # CONFIG_MMC_SDHCI_PCI is not set CONFIG_MMC_SDHCI_OF=y CONFIG_MMC_SDHCI_OF_ESDHC=y At least looks the config is fine. Tiejun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: fsl-esdhc on P2020 weird endianess behavior
On 01/24/11 09:15, tiejun.chen wrote: Elie De Brauwer wrote: On 01/24/11 04:26, tiejun.chen wrote: Elie De Brauwer wrote: Hello list, I have a P2020 processor on a custom board which uses the embedded fsl-esdhc controller. Hardware-wise this is functional and in u-boot everything seems to behave (mmc part 0 gives the correct partition table and ext2ls/fatls are capable of reading the contents of the sd card). However as soon as I start Linux (2.6.36), I get all sorts of unwanted behavior. Linux is unable to detect the partition layout (but if I do a Can you re-partition that under Linux? i.e, you can use fdisk to do this. Then I'm a bit curious what it'll be happened. This was already partitioned under (x86) Linux, and when I plug it into I means you should partition the disk on the PPC Linux, not x86. As you know x86 work with LE for Linux, but PPC with BE. So I think you should partition that on the same type machine. Can you try it? my laptop it sees the MBR (but also on target, in U-boot, the mmc part 0 command shows the correct partition table). And this does not explain I didn't check this implemented codes within u-boot. Maybe u-boot can do something to swap MMC ending problem. You can try to get the conclusion. Firstly you can re-partition that on PPC Linux then check if u-boot can identify it properly. I guess u-boot still can read that successfully. Unfortunately two wrongs don't make a right here. When I fdisk it on target, then on target the partition gets detected, in u-boot it fails (Unknown partition table). To be honest this was already the behavior which I expected because the endianness swap was also seen for the card registers. So I think something more fundamental is wrong (which in turn smells like the BIG_ENDIAN_32BIT_BYTE_SWAPPER but this is used in a very convincing way by the fsl-esdh driver... why the card registers (such as the scr pasted below) also seem to have their endianess swapped, which will result in other side-effects, such as improper reading of card capabilities. hexdump of the MBR, I see the endianness is swapped (last 4 bytes are aa 55 00 00). Also when I try to obtain the card registers they show the same behavior: # cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr b502 While for comparison the same value on my (x86) laptop gives: edb@lapedb:/sys/devices/pci:00/:00:1e.0/:15:00.2/mmc_host/mmc0/mmc0:0001$ cat scr 02b5 In my config I have the following set: CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_IO_ACCESSORS=y CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y # CONFIG_MMC_SDHCI_PCI is not set CONFIG_MMC_SDHCI_OF=y CONFIG_MMC_SDHCI_OF_ESDHC=y At least looks the config is fine. Tiejun -- Elie De Brauwer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: fsl-esdhc on P2020 weird endianess behavior
Elie De Brauwer wrote: On 01/24/11 09:15, tiejun.chen wrote: Elie De Brauwer wrote: On 01/24/11 04:26, tiejun.chen wrote: Elie De Brauwer wrote: Hello list, I have a P2020 processor on a custom board which uses the embedded fsl-esdhc controller. Hardware-wise this is functional and in u-boot everything seems to behave (mmc part 0 gives the correct partition table and ext2ls/fatls are capable of reading the contents of the sd card). However as soon as I start Linux (2.6.36), I get all sorts of unwanted behavior. Linux is unable to detect the partition layout (but if I do a Can you re-partition that under Linux? i.e, you can use fdisk to do this. Then I'm a bit curious what it'll be happened. This was already partitioned under (x86) Linux, and when I plug it into I means you should partition the disk on the PPC Linux, not x86. As you know x86 work with LE for Linux, but PPC with BE. So I think you should partition that on the same type machine. Can you try it? my laptop it sees the MBR (but also on target, in U-boot, the mmc part 0 command shows the correct partition table). And this does not explain I didn't check this implemented codes within u-boot. Maybe u-boot can do something to swap MMC ending problem. You can try to get the conclusion. Firstly you can re-partition that on PPC Linux then check if u-boot can identify it properly. I guess u-boot still can read that successfully. Unfortunately two wrongs don't make a right here. When I fdisk it on target, then on target the partition gets detected, in u-boot it fails (Unknown partition table). To be honest this was already the behavior which I expected because the endianness swap was also seen for the card registers. So I think something more fundamental is wrong (which in turn smells like the BIG_ENDIAN_32BIT_BYTE_SWAPPER but this is used in a very convincing way by the fsl-esdh driver... As you said looks you can disable 'MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER' from the Kconfig to rebuild Linux since its unnecessary for your target. Tiejun why the card registers (such as the scr pasted below) also seem to have their endianess swapped, which will result in other side-effects, such as improper reading of card capabilities. hexdump of the MBR, I see the endianness is swapped (last 4 bytes are aa 55 00 00). Also when I try to obtain the card registers they show the same behavior: # cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr b502 While for comparison the same value on my (x86) laptop gives: edb@lapedb:/sys/devices/pci:00/:00:1e.0/:15:00.2/mmc_host/mmc0/mmc0:0001$ cat scr 02b5 In my config I have the following set: CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_IO_ACCESSORS=y CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y # CONFIG_MMC_SDHCI_PCI is not set CONFIG_MMC_SDHCI_OF=y CONFIG_MMC_SDHCI_OF_ESDHC=y At least looks the config is fine. Tiejun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: fsl-esdhc on P2020 weird endianess behavior
On 01/24/11 10:28, tiejun.chen wrote:
Elie De Brauwer wrote:
On 01/24/11 09:15, tiejun.chen wrote:
Elie De Brauwer wrote:
On 01/24/11 04:26, tiejun.chen wrote:
Elie De Brauwer wrote:
Hello list,
I have a P2020 processor on a custom board which uses the embedded
fsl-esdhc controller. Hardware-wise this is functional and in u-boot
everything seems to behave (mmc part 0 gives the correct partition
table
and ext2ls/fatls are capable of reading the contents of the sd card).
However as soon as I start Linux (2.6.36), I get all sorts of unwanted
behavior. Linux is unable to detect the partition layout (but if I
do a
Can you re-partition that under Linux? i.e, you can use fdisk to do
this. Then
I'm a bit curious what it'll be happened.
This was already partitioned under (x86) Linux, and when I plug it into
I means you should partition the disk on the PPC Linux, not x86. As
you know x86
work with LE for Linux, but PPC with BE. So I think you should
partition that on
the same type machine. Can you try it?
my laptop it sees the MBR (but also on target, in U-boot, the mmc part 0
command shows the correct partition table). And this does not explain
I didn't check this implemented codes within u-boot. Maybe u-boot can do
something to swap MMC ending problem. You can try to get the
conclusion. Firstly
you can re-partition that on PPC Linux then check if u-boot can
identify it
properly. I guess u-boot still can read that successfully.
Unfortunately two wrongs don't make a right here. When I fdisk it on
target, then on target the partition gets detected, in u-boot it fails
(Unknown partition table). To be honest this was already the behavior
which I expected because the endianness swap was also seen for the card
registers. So I think something more fundamental is wrong (which in turn
smells like the BIG_ENDIAN_32BIT_BYTE_SWAPPER but this is used in a
very convincing way by the fsl-esdh driver...
As you said looks you can disable 'MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER' from
the Kconfig to rebuild Linux since its unnecessary for your target.
Well no, since this gets selected by the fsl-esdhc driver
config MMC_SDHCI_OF_ESDHC
bool SDHCI OF support for the Freescale eSDHC controller
depends on MMC_SDHCI_OF
select MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER
help
This selects the Freescale eSDHC controller support.
If unsure, say N.
And if you look in the sdhc-of.esdhc.c
(http://lxr.linux.no/#linux+v2.6.37/drivers/mmc/host/sdhci-of-esdhc.c#L75 )
you can see that this driver is very stubborn in using the sdhci_be32bs*
variants, so it just won't compile without the BYTE_SWAPPER set. But the
entire sdhci_esdhc struct looks odd (for example they do byteswapping
for the read_b but nog for the write_b, and it gets only done for the
{read|write}_l. I'll try using the 'regular' callbacks here instead of
the byteswapped versions.
Tiejun
why the card registers (such as the scr pasted below) also seem to have
their endianess swapped, which will result in other side-effects, such
as improper reading of card capabilities.
hexdump of the MBR, I see the endianness is swapped (last 4 bytes
are aa
55 00 00). Also when I try to obtain the card registers they show the
same behavior:
# cat ./devices/soc.0/ff72e000.sdhci/mmc_host/mmc0/mmc0:0001/scr
b502
While for comparison the same value on my (x86) laptop gives:
edb@lapedb:/sys/devices/pci:00/:00:1e.0/:15:00.2/mmc_host/mmc0/mmc0:0001$
cat scr
02b5
In my config I have the following set:
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_IO_ACCESSORS=y
CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER=y
# CONFIG_MMC_SDHCI_PCI is not set
CONFIG_MMC_SDHCI_OF=y
CONFIG_MMC_SDHCI_OF_ESDHC=y
At least looks the config is fine.
Tiejun
--
Elie De Brauwer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/4 v4] video, sm501: add I/O functions for use on powerpc
- add read/write functions for using this driver
also on powerpc plattforms
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
- use ioread/write32{be} accessors instead of
__do_readl/__do_writel{_be}
- edid support patch
./scripts/checkpatch.pl
0001-video-sm501-add-I-O-functions-for-use-on-powerpc.patch
total: 0 errors, 0 warnings, 841 lines checked
0001-video-sm501-add-I-O-functions-for-use-on-powerpc.patch has no obvious
style problems and is ready for submission.
drivers/mfd/sm501.c | 125 +-
drivers/video/sm501fb.c | 172 --
include/linux/sm501.h |8 ++
3 files changed, 161 insertions(+), 144 deletions(-)
diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c
index 5de3a76..558d5f3 100644
--- a/drivers/mfd/sm501.c
+++ b/drivers/mfd/sm501.c
@@ -133,10 +133,10 @@ static unsigned long decode_div(unsigned long pll2,
unsigned long val,
static void sm501_dump_clk(struct sm501_devdata *sm)
{
- unsigned long misct = readl(sm-regs + SM501_MISC_TIMING);
- unsigned long pm0 = readl(sm-regs + SM501_POWER_MODE_0_CLOCK);
- unsigned long pm1 = readl(sm-regs + SM501_POWER_MODE_1_CLOCK);
- unsigned long pmc = readl(sm-regs + SM501_POWER_MODE_CONTROL);
+ unsigned long misct = smc501_readl(sm-regs + SM501_MISC_TIMING);
+ unsigned long pm0 = smc501_readl(sm-regs + SM501_POWER_MODE_0_CLOCK);
+ unsigned long pm1 = smc501_readl(sm-regs + SM501_POWER_MODE_1_CLOCK);
+ unsigned long pmc = smc501_readl(sm-regs + SM501_POWER_MODE_CONTROL);
unsigned long sdclk0, sdclk1;
unsigned long pll2 = 0;
@@ -193,29 +193,29 @@ static void sm501_dump_regs(struct sm501_devdata *sm)
void __iomem *regs = sm-regs;
dev_info(sm-dev, System Control %08x\n,
- readl(regs + SM501_SYSTEM_CONTROL));
+ smc501_readl(regs + SM501_SYSTEM_CONTROL));
dev_info(sm-dev, Misc Control %08x\n,
- readl(regs + SM501_MISC_CONTROL));
+ smc501_readl(regs + SM501_MISC_CONTROL));
dev_info(sm-dev, GPIO Control Low %08x\n,
- readl(regs + SM501_GPIO31_0_CONTROL));
+ smc501_readl(regs + SM501_GPIO31_0_CONTROL));
dev_info(sm-dev, GPIO Control Hi %08x\n,
- readl(regs + SM501_GPIO63_32_CONTROL));
+ smc501_readl(regs + SM501_GPIO63_32_CONTROL));
dev_info(sm-dev, DRAM Control %08x\n,
- readl(regs + SM501_DRAM_CONTROL));
+ smc501_readl(regs + SM501_DRAM_CONTROL));
dev_info(sm-dev, Arbitration Ctrl %08x\n,
- readl(regs + SM501_ARBTRTN_CONTROL));
+ smc501_readl(regs + SM501_ARBTRTN_CONTROL));
dev_info(sm-dev, Misc Timing %08x\n,
- readl(regs + SM501_MISC_TIMING));
+ smc501_readl(regs + SM501_MISC_TIMING));
}
static void sm501_dump_gate(struct sm501_devdata *sm)
{
dev_info(sm-dev, CurrentGate %08x\n,
- readl(sm-regs + SM501_CURRENT_GATE));
+ smc501_readl(sm-regs + SM501_CURRENT_GATE));
dev_info(sm-dev, CurrentClock %08x\n,
- readl(sm-regs + SM501_CURRENT_CLOCK));
+ smc501_readl(sm-regs + SM501_CURRENT_CLOCK));
dev_info(sm-dev, PowerModeControl %08x\n,
- readl(sm-regs + SM501_POWER_MODE_CONTROL));
+ smc501_readl(sm-regs + SM501_POWER_MODE_CONTROL));
}
#else
@@ -231,7 +231,7 @@ static inline void sm501_dump_clk(struct sm501_devdata *sm)
{ }
static void sm501_sync_regs(struct sm501_devdata *sm)
{
- readl(sm-regs);
+ smc501_readl(sm-regs);
}
static inline void sm501_mdelay(struct sm501_devdata *sm, unsigned int delay)
@@ -261,11 +261,11 @@ int sm501_misc_control(struct device *dev,
spin_lock_irqsave(sm-reg_lock, save);
- misc = readl(sm-regs + SM501_MISC_CONTROL);
+ misc = smc501_readl(sm-regs + SM501_MISC_CONTROL);
to = (misc ~clear) | set;
if (to != misc) {
- writel(to, sm-regs + SM501_MISC_CONTROL);
+ smc501_writel(to, sm-regs +
[PATCH 2/4 v4] 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
./scripts/checkpatch.pl 0002-video-sm501-add-edid-and-commandline-support.patch
total: 0 errors, 0 warnings, 123 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| 67
2 files changed, 71 insertions(+), 6 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..30b53ae 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
+ ret = fb_find_mode(fb-var, fb,
NULL, NULL, 0, NULL, 8);
- if (ret == 0 || ret == 4) {
-
[PATCH 3/4 v4] 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
./scripts/checkpatch.pl 0003-video-sm501-add-OF-binding-to-support-SM501.patch
total: 0 errors, 0 warnings, 117 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 | 16 +++-
drivers/video/sm501fb.c | 33 -
3 files changed, 81 insertions(+), 2 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..5b7a8f4 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,14 @@ 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-mem_res)
+ pr_debug(sm501 mem 0x%lx, 0x%lx\n,
+sm-mem_res-start, sm-mem_res-end);
+ if (sm-io_res)
+ pr_debug(sm501 io 0x%lx, 0x%lx\n,
+sm-io_res-start, sm-io_res-end);
+
if (sm-io_res == NULL || sm-mem_res == NULL) {
dev_err(dev-dev, failed to get IO resource\n);
ret = -ENOENT;
@@ -1735,10 +1743,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 30b53ae..2ae57aa 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
[PATCH 4/4 v4] powerpc, video: add SM501 support for charon board.
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
---
- changes since v1:
- no board specific defconfig file for mpc52xx based boards as suggested
from Wolfram Sang
- changes since v2:
add Ben Dooks, Vincent Sanders and Samuel Ortiz and lkml to cc, as
suggested from Paul Mundt.
- changes since v3:
- rebased against v2.6.38-rc2
./scripts/checkpatch.pl
0004-powerpc-video-add-SM501-support-for-charon-board.patch
total: 0 errors, 0 warnings, 22 lines checked
0004-powerpc-video-add-SM501-support-for-charon-board.patch has no obvious
style problems and is ready for submission.
arch/powerpc/boot/dts/charon.dts | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/charon.dts b/arch/powerpc/boot/dts/charon.dts
index 9776889..0e00e50 100644
--- a/arch/powerpc/boot/dts/charon.dts
+++ b/arch/powerpc/boot/dts/charon.dts
@@ -186,6 +186,7 @@
#address-cells = 2;
#size-cells = 1;
ranges = 0 0 0xfc00 0x0200
+ 1 0 0xe000 0x0400 // CS1 range, SM501
3 0 0xe800 0x0008;
flash@0,0 {
@@ -197,6 +198,15 @@
#address-cells = 1;
};
+ display@1,0 {
+ compatible = smi,sm501;
+ reg = 1 0x 0x0080
+ 1 0x03e0 0x0020;
+ mode = 640x480-32@60;
+ interrupts = 1 1 3;
+ little-endian;
+ };
+
mram0@3,0 {
compatible = mtd-ram;
reg = 3 0x0 0x8;
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BootX
Hi, I've never done any real kernel debugging. Can anyone give any pointers on how to do early boot debugging on an old world (buggy OF) powermac? Can I do anything using a serial console? A little reading last night suggested that spinlocks are supposed to disappear for single processor machines. I do not understand why they are present in 3.4.6 (at least the symbol anyway)? The 'acct_lock' spin lock was also missing with gcc 4.2.4. kevin On Sat, Jan 22, 2011 at 12:24 PM, kevin diggs diggskevi...@gmail.com wrote: Hi, If I enable SMP then I can build a 2.6.28 kernel with gcc 4.3.5 that WILL boot on the PowerMac8600 (single 750GX). The previously mentioned G4 that runs is a dual cpu beast and thus also runs SMP. I at least know this (ok, I THINK I know): For non-SMP: The spinlock 'acct_lock' in kernel/acct.c that IS present in 3.4.6 (i.e. kernel 2.6.28 compiled with gcc 3.4.6). Not so much for 4.3.5. I have not yet done a general 4.3.5 compiled 2.6.28 spinlock safari. Don't some funky, optimizery things happen to spinlocks for the NON-smp case? I'll see what the 4.2.x gcc does. Thanks! kevin P.S.: There is one other difference for the SMP 4.3.5 compiled 2.6.28: my 750gx cpufreq driver gets disabled. It is fairly isolated code though. Should not be able to nuke the spinlock in kernel/acct.c On Fri, Jan 21, 2011 at 1:26 PM, kevin diggs diggskevi...@gmail.com wrote: Hi, Anyone familiar with BootX? Could my problems with the 8600 be related to some interaction with BootX? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
FSL DMA engine transfer to PCI memory
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 L0s 64ns, L1 1us
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.
Felix.
___
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 Mon, 24 Jan 2011 23:47:22 +0200
Felix Radensky fe...@embedded-sol.com wrote:
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;
Why are you casting a virtual address to dma_addr_t?
The destination address is PCI memory address returned by
pci_ioremap_bar().
You need the physical address.
-Scott
___
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 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 L0s 64ns, L1 1us
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 completion which are on the
stack.
Hope it helps,
Ira
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
Re: FSL DMA engine transfer to PCI memory
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 completion which are on the
stack.
Hope it helps,
Ira
Thanks for your help. I'm now passing the result of
pci_resource_start(pdev, 0)
as destination address, and destination buffer changes
Re: FSL DMA engine transfer to PCI memory
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.
Re: [PATCH 4/4 v5] powerpc, video: add SM501 support for charon board.
On Tue, Jan 25, 2011 at 07:45:46AM +0100, Heiko Schocher wrote:
@@ -197,6 +198,15 @@
#address-cells = 1;
};
+ display@1,0 {
+ compatible = smi,sm501;
+ reg = 1 0x 0x0080
+1 0x03e0 0x0020;
+ mode = 640x480-32@60;
+ interrupts = 1 1 3;
+ little-endian;
+ };
+
The endian designation looks good, but it still doesn't explain why you
have a remaining CONFIG_PPC_MPC52xx ifdef encapsulating the property
check in the sm501fb patch. It shouldn't be needed at all. If the
platform supports OF then the property will need to be set one way or the
other, so there is no need for any board or CPU ifdeffery within the
driver itself.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4 v5] powerpc, video: add SM501 support for charon board.
Hello Paul,
Paul Mundt wrote:
On Tue, Jan 25, 2011 at 07:45:46AM +0100, Heiko Schocher wrote:
@@ -197,6 +198,15 @@
#address-cells = 1;
};
+display@1,0 {
+compatible = smi,sm501;
+reg = 1 0x 0x0080
+ 1 0x03e0 0x0020;
+mode = 640x480-32@60;
+interrupts = 1 1 3;
+little-endian;
+};
+
The endian designation looks good, but it still doesn't explain why you
have a remaining CONFIG_PPC_MPC52xx ifdef encapsulating the property
check in the sm501fb patch. It shouldn't be needed at all. If the
platform supports OF then the property will need to be set one way or the
other, so there is no need for any board or CPU ifdeffery within the
driver itself.
Argh, of course you are right, thanks! I post an update for the
sm501fb of support patch.
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
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_7450 0x8000
#define PVR_8540 0x8020
#define PVR_8560 0x8020
+#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)
+ switch (maj) {
+ case 1:
+ if (min 1)
+ have_e500_cpu_a005_erratum = 1;
+ break;
+ case 2:
+ if (min 3)
+ have_e500_cpu_a005_erratum = 1;
+ break;
+ case 3:
+ case 4:
+ case 5:
+ if (min 1)
+ have_e500_cpu_a005_erratum = 1;
+ break;
+ default:
+ break;
+ }
+ }
+
+ return 0;
+}
+
+module_init(spe_mathemu_init);
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/4 v4] 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.
./scripts/checkpatch.pl 0003-video-sm501-add-OF-binding-to-support-SM501.patch
total: 0 errors, 0 warnings, 117 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 | 16 +++-
drivers/video/sm501fb.c | 33 -
3 files changed, 81 insertions(+), 2 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..5b7a8f4 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,14 @@ 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-mem_res)
+ pr_debug(sm501 mem 0x%lx, 0x%lx\n,
+sm-mem_res-start, sm-mem_res-end);
+ if (sm-io_res)
+ pr_debug(sm501 io 0x%lx, 0x%lx\n,
+sm-io_res-start, sm-io_res-end);
+
if (sm-io_res == NULL || sm-mem_res == NULL) {
dev_err(dev-dev, failed to get IO resource\n);
ret = -ENOENT;
@@ -1735,10 +1743,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 30b53ae..bbdb359 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 |
Re: [PATCH 3/4 v4] video, sm501: add OF binding to support SM501
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(),
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(..);
}
...
___
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
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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
