[linux-sunxi] sun4i drm driver not working on q8 a13 tablet ?
Hi All, As part of testing that my "ARM: dts: sun5i: Move display blocks to sun5i.dtsi" patch did not break anything I've been trying to get the sun4i-drm kms driver to work on a q8 a13 tablet. I've build the drm / panel bits as modules after doing : [root@localhost ~]# insmod syscopyarea.ko [root@localhost ~]# insmod sysfillrect.ko [root@localhost ~]# insmod sysimgblt.ko [root@localhost ~]# insmod fb_sys_fops.ko [root@localhost ~]# insmod drm.ko [root@localhost ~]# insmod drm_kms_helper.ko [root@localhost ~]# insmod sun4i-tcon.ko [root@localhost ~]# insmod sun4i_backend.ko [root@localhost ~]# insmod panel-simple.ko [root@localhost ~]# insmod sun4i-drm.ko I get the following in dmesg: [ 87.791338] [drm] Initialized drm 1.1.0 20060810 [ 113.883947] panel supply power not found, using dummy regulator [ 119.199189] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 119.210695] [drm] No driver support for vblank timestamp query. [ 119.238295] sun4i-drm display-engine: bound 1e6.display-backend (ops __mod_of__sun4i_backend_of_table_device_table [sun4i_backend]) [ 119.261666] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops __mod_of__sun4i_tcon_of_table_device_table [sun4i_tcon]) [ 119.287566] checking generic (5fe89000 177000) vs hw (0 ) [ 119.287599] fb: switching to sun4i-drm-fb from simple [ 119.304752] Console: switching to colour dummy device 80x30 [ 119.319700] sun4i-drm display-engine: No connectors reported connected with modes [ 119.343392] [drm] Cannot find any crtc or sizes - going 1024x768 [ 119.374591] Console: switching to colour frame buffer device 128x48 [ 119.433258] sun4i-drm display-engine: fb0: frame buffer device Esp. notice the "sun4i-drm display-engine: No connectors reported connected with modes" and "[drm] Cannot find any crtc or sizes - going 1024x768" Which clearly is wrong, after this the lcd-panel display becomes a mess, as if it is not getting any video data, which indeed seems to be what is happening. Regards, Hans -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH sunxi-tools v3 4/4] nand-image-builder: Fix --help/-h option
Am 03.06.2016 um 17:38 schrieb Boris Brezillon: --help/-h is not working correctly (it's printing the help context on stderr instead of stdout). Adding a valid shortcut for --help solves the problem. Signed-off-by: Boris Brezillon --- nand-image-builder.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Acked-by: Bernhard Nortmann -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH sunxi-tools v3 3/4] nand-image-builder: Rework the help context
Hi Boris!
Am 03.06.2016 um 17:38 schrieb Boris Brezillon:
Add explanations on where the options to pass to the tool should be
extracted from, and add two examples to illustrate this explanation.
Signed-off-by: Boris Brezillon
---
Changes since v2:
- limit line width in the help context
Changes since v1:
- use shorter option names
- rework the help context
---
nand-image-builder.c | 70 +---
1 file changed, 50 insertions(+), 20 deletions(-)
diff --git a/nand-image-builder.c b/nand-image-builder.c
index 465ab36..230ed0c 100644
--- a/nand-image-builder.c
+++ b/nand-image-builder.c
@@ -917,21 +917,51 @@ static void display_help(int status)
{
fprintf(status == EXIT_SUCCESS ? stdout : stderr,
"Usage: sunxi-nand-image-builder [OPTIONS] source-image
output-image\n"
+ "\n"
"Creates a raw NAND image that can be read by the sunxi NAND
controller.\n"
"\n"
- "-h--help Display
this help and exit\n"
- "-c / --ecc=/ ECC
config\n"
- " Valid strengths:
16, 24, 28, 32, 40, 48, 56, 60 and 64\n"
- " Valid steps: 512
and 1024\n"
- "-p--page-size=Page
size\n"
- "-o--oob-size= OOB size\n"
- "-u--usable-page-size= Usable page size.
Only needed for boot0 mode\n"
- "-e--eraseblock-size= Erase block
size\n"
- "-b--boot0 Build a
boot0 image.\n"
- "-s--scramble Scramble
data\n"
- "-a --address Where the image
will be programmed.\n"
- " This option is
only required for non boot0 images that are meant to be programmed at a non eraseblock
aligned offset.\n"
- "\n");
+ "-h --help Display this help and
exit\n"
+ "-c / --ecc=/ ECC config
(strength/step-size)\n"
+ "-p --page=Page size\n"
+ "-o --oob= OOB size\n"
+ "-u --usable= Usable page size\n"
+ "-e --eraseblock= Erase block size\n"
+ "-b --boot0 Build a boot0 image.\n"
+ "-s --scramble Scramble data\n"
+ "-a --addressWhere the image will be
programmed.\n"
Shouldn't the long option show the parameter too, i.e. "--address="?
+ "\n"
+ "Notes:\n"
+ "All the information you need to pass to this tool should be part
of\n"
+ "the NAND datasheet.\n"
+ "\n"
+ "The NAND controller only supports the following ECC configs\n"
+ " Valid ECC strengths: 16, 24, 28, 32, 40, 48, 56, 60 and 64\n"
+ " Valid ECC step size: 512 and 1024\n"
+ "\n"
+ "If you are building a boot0 image, you'll have specify extra
options.\n"
+ "These options should be chosen based on the layouts described
here:\n"
+ " http://linux-sunxi.org/NAND#More_information_on_BROM_NAND\n";
For consistency, either zero or two leading spaces in front of the URL?
+ "\n"
+ " --usable should be assigned the 'Hardware page' value\n"
+ " --ecc should be assigned the 'ECC capacity'/'ECC page'
values\n"
+ " --usable should be smaller than --page\n"
+ "\n"
+ "The --address option is only required for non-boot0 images that are
\n"
+ "meant to be programmed at a non eraseblock aligned offset.\n"
+ "\n"
+ "Examples:\n"
+ " The H27UCG8T2BTR-BC NAND exposes\n"
+ " * 16k pages\n"
+ " * 1280 OOB bytes per page\n"
+ " * 4M eraseblocks\n"
+ " * requires data scrambling\n"
+ " * expects a minimum ECC of 40bits/1024bytes\n"
+ "\n"
+ " A normal image can be generated with\n"
+ "sunxi-nand-image-builder -p 16384 -o 1280 -e 0x40 -s -c
40/1024\n"
+ " A boot0 image can be generated with\n"
+ "sunxi-nand-image-builder -p 16384 -o 1280 -e 0x40 -s -b -u
4096 -c 64/1024\n"
+ );
exit(status);
}
@@ -942,17 +972,17 @@ static int check_image_info(struct image_info *info)
unsigned i;
if (!info->page_size) {
- fprintf(stderr, "--page-size is m
[linux-sunxi] spidev on BananaPi R1 not working.
Hi,
I managed to get the SPI devices /dev/spidev0.0 and /dev/spidev0.1 to be
visible using the mainline kernel 4.4.11 on my BananaPi R1 (Allwinner A20)
with the attached patch to spidev.c and the dts. But the SPI device is not
working. When I send some data for example with *echo "test" >
/dev/spidev0.0 *I could see some activity on *both* chip select lines
SPI_CS0 and SPI_CS1, but no reaction on SPI0_CLK. Is this a bug somewhere
or is there additional tweaking in the dts required?
A testprogramm driving a small display via SPI works fine with the old
sunxi kernel.
Uli
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 67c8a76..1efa46e 100755
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -58,6 +58,9 @@
serial0 = &uart0;
serial1 = &uart3;
serial2 = &uart7;
+ spi0 = &spi0;
+ spi1 = &spi1;
+ spi2 = &spi2;
};
chosen {
@@ -252,6 +255,17 @@
<&spi0_cs0_pins_a>,
<&spi0_cs1_pins_a>;
status = "okay";
+ clock-frequency = <100>;
+ spidev@0x00 {
+ compatible = "allwinner,sun4i-a10-sp";
+ spi-max-frequency = <1>;
+ reg = <0>;
+ };
+ spidev@0x01 {
+ compatible = "allwinner,sun4i-a10-sp";
+ spi-max-frequency = <1>;
+ reg = <1>;
+ };
};
&uart0 {
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index d0e7dfc..80e21e0 100755
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -695,6 +695,7 @@ static struct class *spidev_class;
static const struct of_device_id spidev_dt_ids[] = {
{ .compatible = "rohm,dh2228fv" },
{ .compatible = "lineartechnology,ltc2488" },
+ { .compatible = "allwinner,sun4i-a10-sp" },
{},
};
MODULE_DEVICE_TABLE(of, spidev_dt_ids);
[linux-sunxi] Re: [PATCH v2 2/7] spl: nand: rename the SYS_NAND_U_BOOT_OFFS Kconfig option
On Sat, 04 Jun 2016 02:14:09 -0500 Scott Wood wrote: > On Sat, 2016-06-04 at 08:06 +0200, Boris Brezillon wrote: > > On Fri, 03 Jun 2016 20:08:49 -0500 > > Scott Wood wrote: > > > > > This doesn't work. CONFIG_SPL_NAND_U_BOOT_OFFS will always be defined > > > when SPL is defined, and the user will be forced to enter a value before > > > kconfig will continue (or kconfig will error out in an automated build). > > > > Yes, CONFIG_SPL_NAND_U_BOOT_OFFS will always be defined, but won't be > > used if CONFIG_SYS_NAND_U_BOOT_OFFS is defined in the config header > > file. > > And for the "user will forced to enter a value before Kconfig > > continue" comment, we could just have > > > > config SPL_NAND_U_BOOT_OFFS > > hex "Location in NAND to read U-Boot from" > > default 0x8000 if NAND_SUNXI > > default 0x0 > > ... > > If you do that, then that zero will override CONFIG_SYS_NAND_U_BOOT_OFFS from > the header. Nope, because the condition is #ifndef CONFIG_SYS_NAND_U_BOOT_OFFS #define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS #endif and not #ifdef CONFIG_SPL_NAND_U_BOOT_OFFS #define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS #endif So CONFIG_SYS_NAND_U_BOOT_OFFS is always preferred over CONFIG_SPL_NAND_U_BOOT_OFFS if it's defined. > > > > If you want to do this there needs to be a separate bool config that > > > controls whether the hex config exists. > > > > I can add an extra Kconfig option, but is it really necessary: > > if people are relying on it they will choose a valid value, and leave > > it to 0 otherwise. > > It's just a detail, so I'm fine adding this extra option if you think > > it's really useful. > > Zero *is* a valid value. Several boards already have that value for this > symbol. Even if that weren't the case, we want a mechanism for migrating > from header value to kconfig value that works for more than just this one > specific symbol. Sure, 0 is a perfectly valid value. The "default 0" is just here to prevent make from blocking because of a missing definition in the _defconfig. > > > > > > And there'd be no need to rename hex symbol. > > > > Well, functionally there's no problem keeping the existing SYS_ prefix > > if we add this extra option to activate the U_OFFS config in Kconfig, > > but I'm not sure this is a good idea to reuse config header names in > > Kconfig. > > > > And what happens if the user enabled this option (some like to enable > > everything :-)) and CONFIG_SYS_NAND_U_BOOT_OFFS is also defined in the > > board config header? > > Then the build fails with a redefined symbol, and the user learns their > lesson. :-) Fair enough. > > The "SYS" in CONFIG_SYS means it's not a user-tunable knob. From README: > > > There are two classes of configuration variables: > > > > * Configuration _OPTIONS_: > > These are selectable by the user and have names beginning with > > "CONFIG_". > > > > * Configuration _SETTINGS_: > > These depend on the hardware etc. and should not be meddled with if > > you don't know what you're doing; they have names beginning with > > "CONFIG_SYS_". Okay. I'll switch back to SYS_NAND_U_BOOT_OFFS, add an intermediate option to unlock this one in the config menu and rename CONFIG_SPL_NAND_U_BOOT_OFFS_REDUND into CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH] mmc: sunxi: Add support to the Allwinner A83T
The A83T has different clock delays.
The values have been adapted from the Banana Pi M3 driver.
Signed-off-by: Jean-Francois Moine
---
Documentation/devicetree/bindings/mmc/sunxi-mmc.txt | 3 ++-
drivers/mmc/host/sunxi-mmc.c| 12 +++-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
index 4bf41d8..45b8520 100644
--- a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
@@ -8,7 +8,8 @@ as the speed of SD standard 3.0.
Absolute maximum transfer rate is 200MB/s
Required properties:
- - compatible : "allwinner,sun4i-a10-mmc" or "allwinner,sun5i-a13-mmc"
+ - compatible : "allwinner,sun4i-a10-mmc", "allwinner,sun5i-a13-mmc",
+ "allwinner,sun8i-a83t-mmc" or "allwinner,sun9i-a80-mmc"
- reg : mmc controller base registers
- clocks : a list with 4 phandle + clock specifier pairs
- clock-names : must contain "ahb", "mmc", "output" and "sample"
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 7fc8b7a..707e705 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -941,6 +941,7 @@ static int sunxi_mmc_card_busy(struct mmc_host *mmc)
static const struct of_device_id sunxi_mmc_of_match[] = {
{ .compatible = "allwinner,sun4i-a10-mmc", },
{ .compatible = "allwinner,sun5i-a13-mmc", },
+ { .compatible = "allwinner,sun8i-a83t-mmc", },
{ .compatible = "allwinner,sun9i-a80-mmc", },
{ /* sentinel */ }
};
@@ -962,10 +963,17 @@ static const struct sunxi_mmc_clk_delay
sunxi_mmc_clk_delays[] = {
[SDXC_CLK_25M] = { .output = 180, .sample = 75 },
[SDXC_CLK_50M] = { .output = 90, .sample = 120 },
[SDXC_CLK_50M_DDR] = { .output = 60, .sample = 120 },
- /* Value from A83T "new timing mode". Works but might not be right. */
[SDXC_CLK_50M_DDR_8BIT] = { .output = 90, .sample = 180 },
};
+static const struct sunxi_mmc_clk_delay sun8i_a83t_mmc_clk_delays[] = {
+ [SDXC_CLK_400K] = { .output = 180, .sample = 180 },
+ [SDXC_CLK_25M] = { .output = 180, .sample = 50 },
+ [SDXC_CLK_50M] = { .output = 60, .sample = 50 },
+ [SDXC_CLK_50M_DDR] = { .output = 180, .sample = 90 },
+ [SDXC_CLK_50M_DDR_8BIT] = { .output = 180, .sample = 90 },
+};
+
static const struct sunxi_mmc_clk_delay sun9i_mmc_clk_delays[] = {
[SDXC_CLK_400K] = { .output = 180, .sample = 180 },
[SDXC_CLK_25M] = { .output = 180, .sample = 75 },
@@ -987,6 +995,8 @@ static int sunxi_mmc_resource_request(struct sunxi_mmc_host
*host,
if (of_device_is_compatible(np, "allwinner,sun9i-a80-mmc"))
host->clk_delays = sun9i_mmc_clk_delays;
+ else if (of_device_is_compatible(np, "allwinner,sun8i-a83t-mmc"))
+ host->clk_delays = sun8i_a83t_mmc_clk_delays;
else
host->clk_delays = sunxi_mmc_clk_delays;
--
2.8.3
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 3/7] spl: nand: support redundant u-boot image
On Sat, 2016-06-04 at 08:15 +0200, Boris Brezillon wrote: > On Fri, 03 Jun 2016 20:15:16 -0500 > Scott Wood wrote: > > > How does the failure get communicated to later > > parts of the system that would be responsible for such reflashing? > > Linux is taking care of that (a script tries to read the u-boot > partition, and if fails it reflashes it with the content of the > u-boot-backup partition, or with a reference u-boot.bin file). > I guess u-boot could do it too. > > Anyway, that's a different story ;). It seemed like it would be good to export the information if possible (e.g. an environment variable) rather than rereading and thus making failures happen twice as quickly. But that can wait until someone actually wants to use it that way. -Scott -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 2/7] spl: nand: rename the SYS_NAND_U_BOOT_OFFS Kconfig option
On Sat, 2016-06-04 at 08:06 +0200, Boris Brezillon wrote: > On Fri, 03 Jun 2016 20:08:49 -0500 > Scott Wood wrote: > > > This doesn't work. CONFIG_SPL_NAND_U_BOOT_OFFS will always be defined > > when SPL is defined, and the user will be forced to enter a value before > > kconfig will continue (or kconfig will error out in an automated build). > > Yes, CONFIG_SPL_NAND_U_BOOT_OFFS will always be defined, but won't be > used if CONFIG_SYS_NAND_U_BOOT_OFFS is defined in the config header > file. > And for the "user will forced to enter a value before Kconfig > continue" comment, we could just have > > config SPL_NAND_U_BOOT_OFFS > hex "Location in NAND to read U-Boot from" > default 0x8000 if NAND_SUNXI > default 0x0 > ... If you do that, then that zero will override CONFIG_SYS_NAND_U_BOOT_OFFS from the header. > > If you want to do this there needs to be a separate bool config that > > controls whether the hex config exists. > > I can add an extra Kconfig option, but is it really necessary: > if people are relying on it they will choose a valid value, and leave > it to 0 otherwise. > It's just a detail, so I'm fine adding this extra option if you think > it's really useful. Zero *is* a valid value. Several boards already have that value for this symbol. Even if that weren't the case, we want a mechanism for migrating from header value to kconfig value that works for more than just this one specific symbol. > > > And there'd be no need to rename hex symbol. > > Well, functionally there's no problem keeping the existing SYS_ prefix > if we add this extra option to activate the U_OFFS config in Kconfig, > but I'm not sure this is a good idea to reuse config header names in > Kconfig. > > And what happens if the user enabled this option (some like to enable > everything :-)) and CONFIG_SYS_NAND_U_BOOT_OFFS is also defined in the > board config header? Then the build fails with a redefined symbol, and the user learns their lesson. :-) The "SYS" in CONFIG_SYS means it's not a user-tunable knob. From README: > There are two classes of configuration variables: > > * Configuration _OPTIONS_: > These are selectable by the user and have names beginning with > "CONFIG_". > > * Configuration _SETTINGS_: > These depend on the hardware etc. and should not be meddled with if > you don't know what you're doing; they have names beginning with > "CONFIG_SYS_". -Scott -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
