[linux-sunxi] [PATCH] clk: sunxi-ng: sun6i-a31: Enable PLL-MIPI LDOs when ungating it

[Chen-Yu Tsai]

The PLL-MIPI clock is somewhat special as it has its own LDOs which
need to be turned on for this PLL to actually work and output a clock
signal.

Add the 2 LDO enable bits to the gate bits. This fixes issues with
the TCON not sending vblank interrupts when the tcon and dot clock are
indirectly clocked from the PLL-MIPI clock.

Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
Signed-off-by: Chen-Yu Tsai 
---

This can be queued for either 4.9 or 4.10.

The clock driver was introduced in 4.9,
but the users won't appear until 4.10.

---
 drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c 
b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
index 4a82a49cff5e..fc75a335a7ce 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -143,7 +143,7 @@ static SUNXI_CCU_NKM_WITH_MUX_GATE_LOCK(pll_mipi_clk, 
"pll-mipi",
4, 2,   /* K */
0, 4,   /* M */
21, 0,  /* mux */
-   BIT(31),/* gate */
+   BIT(31) | BIT(23) | BIT(22), /* gate */
BIT(28),/* lock */
CLK_SET_RATE_UNGATE);
 
-- 
2.10.2

-- 
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.

Re: [linux-sunxi] [PATCH sunxi-boards] add fex file from Nintendo NES Classic Edition

[Chen-Yu Tsai]

On Fri, Nov 18, 2016 at 3:01 PM, Naoki FUKAUMI  wrote:
> ah, sorry, my reply was about u-boot patch, not fex file...
>
> then, that fex is came from Japanese version. I can wait English
> version to compare difference.
>
> or should I use name of Japanese version?

I guess the English name is more recognizable outside of Japan.
Maybe you could add _japanese_version or something to the file name?

If they end up the same we could then just remove it.

ChenYu

>
> On Fri, Nov 18, 2016 at 1:18 PM, Naoki FUKAUMI  wrote:
>> hi
>>
>> On Fri, Nov 18, 2016 at 11:01 AM, Chen-Yu Tsai  wrote:
>>> Just to clarify, is this the Japanese version or the U.S. version?
>>
>> well,
>>
>> I have only Japanese version, but I prefer to use name of English
>> version for this kind of things.
>>
>> my patch is intended to support both version. I tested it on only
>> Japanese version. currently I have no feedback from U.S. version user.
>>
>>> AFAIK the Japanese version is Famicom Mini?
>>
>> official name is,
>>
>>  Nintendo Classic Mini: Family Computer (in Japanese, of course)
>>
>> "Famicom Mini" is another product.
>>  https://en.wikipedia.org/wiki/List_of_Classic_NES_Series_games
>>
>>> I think you mentioned on IRC that one has an LED and the other doesn't?
>>
>> I just saw some pictures of U.S. version on the web. I think there is
>> one LED on front (next to POWER/RESET buttons), but I cannot confirm
>> it.
>>
>> I'm sure there is no LED on Japanese version.
>>  
>> http://mazu-bunkai.com/bunkai-wp/wp-content/uploads/2016/11/nintendo_classic_mini-19.jpg
>>  
>> http://mazu-bunkai.com/bunkai-wp/wp-content/uploads/2016/11/nintendo_classic_mini-20.jpg
>>
>> I think, main board, connectors, and cables are same. controller and
>> sub board are different but I guess it's compatible enough.
>>
>> Regards,

-- 
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.

Re: [linux-sunxi] [PATCH sunxi-boards] add fex file from Nintendo NES Classic Edition

[Naoki FUKAUMI]

ah, sorry, my reply was about u-boot patch, not fex file...

then, that fex is came from Japanese version. I can wait English
version to compare difference.

or should I use name of Japanese version?

On Fri, Nov 18, 2016 at 1:18 PM, Naoki FUKAUMI  wrote:
> hi
>
> On Fri, Nov 18, 2016 at 11:01 AM, Chen-Yu Tsai  wrote:
>> Just to clarify, is this the Japanese version or the U.S. version?
>
> well,
>
> I have only Japanese version, but I prefer to use name of English
> version for this kind of things.
>
> my patch is intended to support both version. I tested it on only
> Japanese version. currently I have no feedback from U.S. version user.
>
>> AFAIK the Japanese version is Famicom Mini?
>
> official name is,
>
>  Nintendo Classic Mini: Family Computer (in Japanese, of course)
>
> "Famicom Mini" is another product.
>  https://en.wikipedia.org/wiki/List_of_Classic_NES_Series_games
>
>> I think you mentioned on IRC that one has an LED and the other doesn't?
>
> I just saw some pictures of U.S. version on the web. I think there is
> one LED on front (next to POWER/RESET buttons), but I cannot confirm
> it.
>
> I'm sure there is no LED on Japanese version.
>  
> http://mazu-bunkai.com/bunkai-wp/wp-content/uploads/2016/11/nintendo_classic_mini-19.jpg
>  
> http://mazu-bunkai.com/bunkai-wp/wp-content/uploads/2016/11/nintendo_classic_mini-20.jpg
>
> I think, main board, connectors, and cables are same. controller and
> sub board are different but I guess it's compatible enough.
>
> Regards,

-- 
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.

Re: [linux-sunxi] [PATCH sunxi-boards] add fex file from Nintendo NES Classic Edition

[Naoki FUKAUMI]

hi

On Fri, Nov 18, 2016 at 11:01 AM, Chen-Yu Tsai  wrote:
> Just to clarify, is this the Japanese version or the U.S. version?

well,

I have only Japanese version, but I prefer to use name of English
version for this kind of things.

my patch is intended to support both version. I tested it on only
Japanese version. currently I have no feedback from U.S. version user.

> AFAIK the Japanese version is Famicom Mini?

official name is,

 Nintendo Classic Mini: Family Computer (in Japanese, of course)

"Famicom Mini" is another product.
 https://en.wikipedia.org/wiki/List_of_Classic_NES_Series_games

> I think you mentioned on IRC that one has an LED and the other doesn't?

I just saw some pictures of U.S. version on the web. I think there is
one LED on front (next to POWER/RESET buttons), but I cannot confirm
it.

I'm sure there is no LED on Japanese version.
 
http://mazu-bunkai.com/bunkai-wp/wp-content/uploads/2016/11/nintendo_classic_mini-19.jpg
 
http://mazu-bunkai.com/bunkai-wp/wp-content/uploads/2016/11/nintendo_classic_mini-20.jpg

I think, main board, connectors, and cables are same. controller and
sub board are different but I guess it's compatible enough.

Regards,

-- 
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] drm/sun4i: Only count TCON endpoints as valid outputs

[Chen-Yu Tsai]

On Fri, Nov 18, 2016 at 3:02 AM, Maxime Ripard
 wrote:
> On Wed, Nov 16, 2016 at 05:37:31PM +0800, Chen-Yu Tsai wrote:
>> The sun4i DRM driver counts the number of endpoints it found and
>> registers the whole DRM pipeline if any endpoints are found.
>>
>> However, if the TCON and its child endpoints (LCD panels, TV encoder,
>> HDMI encoder, MIPI DSI encoder, etc.) aren't found, that means we
>> don't have any usable CRTCs, and the display pipeline is incomplete
>> and useless.
>
> If some node set as available is not probed, then yes, it does, but
> I'm not really sure how it's a problem. Quite the opposite actually.

Actually the problem occurs when the TCON is _not_ available, but
the other endpoints preceding it are.

>> The whole DRM display pipeline should only be registered and enabled
>> if there are proper outputs available.
>
> Unless I've misunderstood what you're saying, we could have the
> writeback for example that would just need the display engine.

Yeah, I guess that complicates things...

>> The debug message "Queued %d outputs on pipeline %d\n" is also telling.
>>
>> This patch makes the driver only count enabled TCON endpoints. If
>> none are found, the DRM pipeline is not used. This avoids screwing
>> up the simple framebuffer provided by the bootloader in cases where
>> we aren't able to support the display with the DRM subsystem, due
>> to lack of panel or bridge drivers, or just lack of progress.
>
> The framebuffer is removed only at bind time, which means that all the
> drivers have probed already. Lack of progress isn't an issue here,
> since the node simply won't be there, and we wouldn't have it in the
> component lists. And lack of drivers shouldn't be an issue either,
> since in order for bind to be called, all the drivers would have
> gone through their probe.
>
> So I'm not really sure what it fixes.

To recap, on sun6i I had enabled the display engine node by default
in the dtsi, along with the backend and drc. The tcon is disabled
by default, so it doesn't get added to the list of components.
The available components get probed, binded, and simplefb gets
pushed out.

I suppose disabling the display engine by default would be better?
At least simplefb still works.

Regards
ChenYu

> Maxime
>
> --
> Maxime Ripard, 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.

Re: [linux-sunxi] [PATCH sunxi-boards] add fex file from Nintendo NES Classic Edition

[Chen-Yu Tsai]

Hi,

Just to clarify, is this the Japanese version or the U.S. version?
AFAIK the Japanese version is Famicom Mini?
I think you mentioned on IRC that one has an LED and the other doesn't?

Thanks
ChenYu

-- 
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 01/11] net: dw: Add read_rom_hwaddr net_op hook

[Simon Glass]

Hi Oliver,

On 8 November 2016 at 08:54, Olliver Schinagl  wrote:
> Add the read_rom_hwaddr net_op hook so that it can be called from boards
> to read the mac from a ROM chip.
>
> Signed-off-by: Olliver Schinagl 
> ---
>  drivers/net/designware.c | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/drivers/net/designware.c b/drivers/net/designware.c
> index 9e6d726..aa87f30 100644
> --- a/drivers/net/designware.c
> +++ b/drivers/net/designware.c
> @@ -230,6 +230,23 @@ static int _dw_write_hwaddr(struct dw_eth_dev *priv, u8 
> *mac_id)
> return 0;
>  }
>
> +__weak int dw_board_read_rom_hwaddr(unsigned char *enetaddr)
> +{
> +   return -ENOSYS;
> +}

Instead of a weak function I think this should use driver model, with
a driver supplied by the board to read this value. It should be
possible to supply the 'hardware-address reading' device to any
Ethernet driver, not just dwmmc.

> +
> +static int designware_eth_read_rom_hwaddr(struct udevice *dev)
> +{
> +   int retval;
> +   struct eth_pdata *pdata = dev_get_platdata(dev);
> +
> +   retval = dw_board_read_rom_hwaddr(pdata->enetaddr);
> +   if (retval == -ENOSYS)
> +   return 0;
> +
> +   return retval;
> +}
> +
>  static void dw_adjust_link(struct eth_mac_regs *mac_p,
>struct phy_device *phydev)
>  {
> @@ -685,6 +702,7 @@ static const struct eth_ops designware_eth_ops = {
> .free_pkt   = designware_eth_free_pkt,
> .stop   = designware_eth_stop,
> .write_hwaddr   = designware_eth_write_hwaddr,
> +   .read_rom_hwaddr= designware_eth_read_rom_hwaddr,
>  };
>
>  static int designware_eth_ofdata_to_platdata(struct udevice *dev)
> --
> 2.10.2
>

Regards,
Simon

-- 
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] sunxi: add support for Nintendo NES Classic Edition

[FUKAUMI Naoki]

Signed-off-by: FUKAUMI Naoki 
---
 arch/arm/dts/Makefile  |  1 +
 .../dts/sun8i-r16-nintendo-nes-classic-edition.dts | 63 ++
 board/sunxi/MAINTAINERS|  5 ++
 configs/Nintendo_NES_Classic_Edition_defconfig | 24 +
 4 files changed, 93 insertions(+)
 create mode 100644 arch/arm/dts/sun8i-r16-nintendo-nes-classic-edition.dts
 create mode 100644 configs/Nintendo_NES_Classic_Edition_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 932dbe0..660f175 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -255,6 +255,7 @@ dtb-$(CONFIG_MACH_SUN8I_A33) += \
sun8i-a33-olinuxino.dtb \
sun8i-a33-q8-tablet.dtb \
sun8i-a33-sinlinx-sina33.dtb \
+   sun8i-r16-nintendo-nes-classic-edition.dtb \
sun8i-r16-parrot.dtb
 dtb-$(CONFIG_MACH_SUN8I_A83T) += \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
diff --git a/arch/arm/dts/sun8i-r16-nintendo-nes-classic-edition.dts 
b/arch/arm/dts/sun8i-r16-nintendo-nes-classic-edition.dts
new file mode 100644
index 000..dce688e
--- /dev/null
+++ b/arch/arm/dts/sun8i-r16-nintendo-nes-classic-edition.dts
@@ -0,0 +1,63 @@
+/*
+ * Copyright (c) 2016 FUKAUMI Naoki 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-a33.dtsi"
+
+/ {
+   model = "Nintendo NES Classic Edition";
+   compatible = "nintendo,nes-classic-edition", "allwinner,sun8i-a33";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+};
diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index d7dc55b..e23d45e 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -232,6 +232,11 @@ M: Jelle van der Waa 
 S: Maintained
 F: configs/nanopi_neo_defconfig
 
+NINTENDO NES CLASSIC EDITION BOARD
+M: FUKAUMI Naoki 
+S: Maintained
+F: configs/Nintendo_NES_Classic_Edition_defconfig
+
 R16 EVB PARROT BOARD
 M: Quentin Schulz 
 S: Maintained
diff --git a/configs/Nintendo_NES_Classic_Edition_defconfig 
b/configs/Nintendo_NES_Classic_Edition_defconfig
new file mode 100644
index 000..fcda1be
--- /dev/null
+++ b/configs/Nintendo_NES_Classic_Edition_defconfig
@@ -0,0 +1,24 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+# CONFIG_SPL_MMC_SUPPORT is not set
+CONFIG_MACH_SUN8I_A33=y
+CONFIG_DRAM_CLK=600
+CONFIG_DRAM_ZQ=15291
+CONFIG_DRAM_ODT_EN=y
+# CONFIG_MMC is not set
+CONFIG_USB0_VBUS_DET="AXP0-VBUS-DETECT"
+CONFIG_AXP_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="sun8i-r16-nintendo-nes-classic-edition"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+CONFIG_AXP_DLDO1_VOLT=3300
+CONFIG_AXP_ELDO2_VOLT=1800
+CONFIG_USB_MUSB_GADGET=y

[linux-sunxi] [PATCH sunxi-boards] add fex file from Nintendo NES Classic Edition

[FUKAUMI Naoki]

---
 sys_config/a33/nintendo_nes_classic_edition.fex | 944 
 1 file changed, 944 insertions(+)
 create mode 100644 sys_config/a33/nintendo_nes_classic_edition.fex

diff --git a/sys_config/a33/nintendo_nes_classic_edition.fex 
b/sys_config/a33/nintendo_nes_classic_edition.fex
new file mode 100644
index 000..182a7e7
--- /dev/null
+++ b/sys_config/a33/nintendo_nes_classic_edition.fex
@@ -0,0 +1,944 @@
+[product]
+version = "100"
+machine = "parrot"
+
+[platform]
+eraseflag = 0
+next_work = 2
+debug_mode = 0
+power_switch = port:PL07<0><0>
+power_led = port:PE10<0><0>
+
+[target]
+boot_clock = 1008
+storage_type = -1
+burn_key = 0
+
+[power_sply]
+dcdc1_vol = 3000
+dcdc2_vol = 1100
+dcdc3_vol = 1200
+dcdc4_vol = 0
+dcdc5_vol = 1500
+aldo2_vol = 2500
+aldo3_vol = 3000
+dldo1_vol = 3300
+eldo2_vol = 1800
+
+[key_detect_en]
+keyen_flag = 1
+
+[fel_key]
+fel_key_max = 7
+fel_key_min = 2
+
+[card_boot]
+logical_start = 40960
+sprite_gpio0 =
+next_work = 3
+
+[card0_boot_para]
+card_ctrl = 0
+card_high_speed = 1
+card_line = 4
+sdc_d1 = port:PF00<2><1><2>
+sdc_d0 = port:PF01<2><1><2>
+sdc_clk = port:PF02<2><1><2>
+sdc_cmd = port:PF03<2><1><2>
+sdc_d3 = port:PF04<2><1><2>
+sdc_d2 = port:PF05<2><1><2>
+
+[card2_boot_para]
+card_ctrl = 2
+card_high_speed = 1
+card_line = 8
+sdc_2xmode = 1
+sdc_ddrmode = 1
+sdc_clk = port:PC05<3><1><2>
+sdc_cmd = port:PC06<3><1><2>
+sdc_d0 = port:PC08<3><1><2>
+sdc_d1 = port:PC09<3><1><2>
+sdc_d2 = port:PC10<3><1><2>
+sdc_d3 = port:PC11<3><1><2>
+sdc_d4 = port:PC12<3><1><2>
+sdc_d5 = port:PC13<3><1><2>
+sdc_d6 = port:PC14<3><1><2>
+sdc_d7 = port:PC15<3><1><2>
+
+[twi_para]
+twi_port = 0
+twi_scl = port:PH02<2>
+twi_sda = port:PH03<2>
+
+[uart_para]
+uart_debug_port = 0
+uart_debug_tx = port:PF02<3><1>
+uart_debug_rx = port:PF04<3><1>
+
+[force_uart_para]
+force_uart_port = 0
+force_uart_tx = port:PF02<3><1>
+force_uart_rx = port:PF04<3><1>
+
+[jtag_para]
+jtag_enable = 1
+jtag_ms = port:PF00<3>
+jtag_ck = port:PF05<3>
+jtag_do = port:PF03<3>
+jtag_di = port:PF01<3>
+
+[clock]
+pll3 = 297
+pll4 = 300
+pll6 = 600
+pll8 = 408
+pll9 = 480
+pll10 = 297
+pll_cpupat = 0
+pll_gpupat = -1002379674
+pll_videopat = 0
+pll_vepat = 0
+pll_hsicpat = 0
+pll_depat = 0
+pll_mipipat = 0
+pll_mipitun = -1979703288
+pll_mipibias = -133168128
+
+[pm_para]
+standby_mode = 1
+
+[dram_para]
+dram_clk = 600
+dram_type = 3
+dram_zq = 0x3bbb
+dram_odt_en = 1
+dram_para1 = 283246848
+dram_para2 = 0
+dram_mr0 = 7280
+dram_mr1 = 64
+dram_mr2 = 24
+dram_mr3 = 0
+dram_tpr0 = 0x47a14f
+dram_tpr1 = 0x1c2294c
+dram_tpr2 = 0x69049
+dram_tpr3 = 0x0
+dram_tpr4 = 0x0
+dram_tpr5 = 0x0
+dram_tpr6 = 0x0
+dram_tpr7 = 0x0
+dram_tpr8 = 0x0
+dram_tpr9 = 0x0
+dram_tpr10 = 0x0
+dram_tpr11 = 0x0
+dram_tpr12 = 0xa8
+dram_tpr13 = 0x10901
+
+[pm_para]
+standby_mode = 1
+
+[wakeup_src_para]
+cpu_en = 0
+cpu_freq = 48
+pll_ratio = 273
+dram_selfresh_en = 1
+dram_freq = 36
+wakeup_src_sw = port:PL07<4><0>
+
+[twi0]
+twi_used = 1
+twi_scl = port:PH02<2>
+twi_sda = port:PH03<2>
+
+[twi1]
+twi_used = 1
+twi_scl = port:PH04<2>
+twi_sda = port:PH05<2>
+
+[twi2]
+twi_used = 1
+twi_scl = port:PE12<3>
+twi_sda = port:PE13<3>
+
+[uart0]
+uart_used = 1
+uart_port = 0
+uart_type = 2
+uart_tx = port:PF02<3><1>
+uart_rx = port:PF04<3><1>
+
+[uart1]
+uart_used = 1
+uart_type = 4
+uart_tx = port:PG06<2><1>
+uart_rx = port:PG07<2><1>
+uart_rts = port:PG08<2><1>
+uart_cts = port:PG09<2><1>
+
+[uart2]
+uart_used = 1
+uart_type = 4
+uart_tx = port:PB00<2><1>
+uart_rx = port:PB01<2><1>
+uart_rts = port:PB02<2><1>
+uart_cts = port:PB03<2><1>
+
+[uart3]
+uart_used = 0
+uart_type = 4
+uart_tx = port:PH06<3><1>
+uart_rx = port:PH07<3><1>
+uart_rts = port:PH08<3><1>
+uart_cts = port:PH09<3><1>
+
+[uart4]
+uart_used = 0
+uart_port = 4
+uart_type = 2
+uart_tx = port:PA04<2><1>
+uart_rx = port:PA05<2><1>
+uart_rts = port:PA06<2><1>
+uart_cts = port:PA07<2><1>
+
+[spi0]
+spi_used = 0
+spi_cs_bitmap = 1
+spi_mosi = port:PC00<3>
+spi_miso = port:PC01<3>
+spi_sclk = port:PC02<3>
+spi_cs0 = port:PC03<3><1>
+
+[spi1]
+spi_used = 0
+spi_cs_bitmap = 1
+spi_cs0 = port:PA00<2><1>
+spi_sclk = port:PA01<2>
+spi_mosi = port:PA02<2>
+spi_miso = port:PA03<2>
+
+[spi_devices]
+spi_dev_num = 0
+
+[spi_board0]
+modalias = "at25df641"
+max_speed_hz = 5000
+bus_num = 0
+chip_select = 0
+mode = 0
+
+[ctp_para]
+ctp_used = 0
+ctp_name = "gt82x"
+ctp_twi_id = 0
+ctp_twi_addr = 0x5d
+ctp_screen_max_x = 1280
+ctp_screen_max_y = 800
+ctp_revert_x_flag = 1
+ctp_revert_y_flag = 1
+ctp_exchange_x_y_flag = 1
+ctp_int_port = port:PL04<4>
+ctp_wakeup = port:PL03<1><1>
+ctp_power_ldo =
+ctp_power_ldo_vol =
+ctp_power_io =
+
+[ctp_list_para]
+ctp_det_used = 0
+ft5x_ts = 1
+gt82x = 1
+gslX680 = 1
+gslX680new = 0
+gt9xx_ts = 1
+gt9xxf_ts = 0
+tu_ts = 0
+gt818_ts = 1
+zet622x = 1
+aw5306_ts = 1
+icn83xx_ts = 0
+
+[tkey_para]
+tkey_used = 0
+tkey_twi_id =
+tkey_twi_addr =
+tkey_int =
+
+[motor_para]
+motor_used = 0
+motor_shake = port:power3<1><1>
+motor_ldo = ""

[linux-sunxi] Re: [PATCH] ARM: dts: sunxi: Explicitly enable pull-ups for MMC pins

[Maxime Ripard]

On Thu, Nov 17, 2016 at 05:34:38PM +0800, Chen-Yu Tsai wrote:
> In the past, all the MMC pins had
> 
>   allwinner,pull = ;
> 
> which was actually a no-op. We were relying on U-boot to set the bias
> pull up for us. These properties were removed as part of the fix up to
> actually support no bias on the pins. During the transition some boards
> experienced regular MMC time-outs during normal operation, while others
> completely failed to initialize the SD card.
> 
> Given that MMC starts in open-drain mode and the pull-ups are required,
> it's best to enable it for all the pin settings.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks.

Maxime

-- 
Maxime Ripard, 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.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH v4 2/2] ARM: dts: sun6i: hummingbird-a31: Enable display output through VGA bridge

[Maxime Ripard]

On Wed, Nov 16, 2016 at 11:42:32PM +0800, Chen-Yu Tsai wrote:
> The Hummingbird A31 board has a VGA DAC which converts RGB output
> from the LCD interface to VGA analog signals.
> 
> Add nodes for the VGA DAC, its power supply, and enable this part
> of the display pipeline.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, 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.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH] drm/sun4i: tcon: Initialize regmap after enabling bus clocks

[Maxime Ripard]

On Wed, Nov 16, 2016 at 05:37:32PM +0800, Chen-Yu Tsai wrote:
> If we attempt to read/write the TCON registers before the bus clock
> is enabled, those accesses get ignored.
> 
> In practice this almost never occurs because U-boot had already enabled
> the bus clock as part of its firmware provided framebuffer (simplefb).
> 
> Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
> Signed-off-by: Chen-Yu Tsai 
> ---
> 
> I was looking around the DRM driver and noticed this sequence was off.
> 
> ---
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index c6afb2448655..8c2db65ea229 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -506,16 +506,16 @@ static int sun4i_tcon_bind(struct device *dev, struct 
> device *master,
>   return ret;
>   }
>  
> - ret = sun4i_tcon_init_regmap(dev, tcon);
> + ret = sun4i_tcon_init_clocks(dev, tcon);
>   if (ret) {
> - dev_err(dev, "Couldn't init our TCON regmap\n");
> + dev_err(dev, "Couldn't init our TCON clocks\n");
>   goto err_assert_reset;
>   }
>  
> - ret = sun4i_tcon_init_clocks(dev, tcon);
> + ret = sun4i_tcon_init_regmap(dev, tcon);
>   if (ret) {
> - dev_err(dev, "Couldn't init our TCON clocks\n");
> - goto err_assert_reset;
> + dev_err(dev, "Couldn't init our TCON regmap\n");
> + goto err_free_clocks;
>   }

That won't work either. sun4i_tcon_init_clocks requires the regmap to
be enabled before it calls sun4i_dclk_create.

Maybe we should just move that call outside of sun4i_tcon_init_clocks
and put it directly into the bind then.

Maxime

-- 
Maxime Ripard, 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.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH] drm/sun4i: Only count TCON endpoints as valid outputs

[Maxime Ripard]

On Wed, Nov 16, 2016 at 05:37:31PM +0800, Chen-Yu Tsai wrote:
> The sun4i DRM driver counts the number of endpoints it found and
> registers the whole DRM pipeline if any endpoints are found.
> 
> However, if the TCON and its child endpoints (LCD panels, TV encoder,
> HDMI encoder, MIPI DSI encoder, etc.) aren't found, that means we
> don't have any usable CRTCs, and the display pipeline is incomplete
> and useless.

If some node set as available is not probed, then yes, it does, but
I'm not really sure how it's a problem. Quite the opposite actually.

> The whole DRM display pipeline should only be registered and enabled
> if there are proper outputs available.

Unless I've misunderstood what you're saying, we could have the
writeback for example that would just need the display engine.

> The debug message "Queued %d outputs on pipeline %d\n" is also telling.
> 
> This patch makes the driver only count enabled TCON endpoints. If
> none are found, the DRM pipeline is not used. This avoids screwing
> up the simple framebuffer provided by the bootloader in cases where
> we aren't able to support the display with the DRM subsystem, due
> to lack of panel or bridge drivers, or just lack of progress.

The framebuffer is removed only at bind time, which means that all the
drivers have probed already. Lack of progress isn't an issue here,
since the node simply won't be there, and we wouldn't have it in the
component lists. And lack of drivers shouldn't be an issue either,
since in order for bind to be called, all the drivers would have
gone through their probe.

So I'm not really sure what it fixes.
Maxime

-- 
Maxime Ripard, 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.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2

[Jean-Francois Moine]

On Wed, 16 Nov 2016 22:33:06 +0100
Maxime Ripard  wrote:

> > > > The Device Engine just handles the planes of the LCDs, but, indeed,
> > > > the LCDs must know about the DE and the DE must know about the LCDs.
> > > > There are 2 ways to realize this knowledge in the DT:
> > > > 1) either the DE has one or two phandle's to the LCDs,
> > > > 2) or the LCDs have a phandle to the DE.
> > > > 
> > > > I chose the 1st way, the DE ports pointing to the endpoint of the LCDs
> > > > which is part of the video link (OF-graph LCD <-> connector).
> > > > It would be possible to have phandles to the LCDs themselves, but this
> > > > asks for more code.
> > > > 
> > > > The second way is also possible, but it also complexifies a bit the
> > > > exchanges DE <-> LCD.
> > > 
> > > I'm still not sure how it would complexify anything, and why you can't
> > > use the display graph to model the relation between the display engine
> > > and the TCON (and why you want to use a generic property that refers
> > > to the of-graph while it really isn't).
> > 
> > Complexification:
> > 1- my solution:
> >   At startup time, the DE device is the DRM device.
> 
> How do you deal with SoCs with multiple display engines then?

In the H3, A83T and A64, there is only one DE.
If many DEs in a SoC, there may be either one DRM device per DE or one
DRM device for the whole system. In this last case, the (global) DE
would have many resources (many I/O memory maps / IRQs..) and the
physical DE of each endpoint would be indicated by the position of its
phandle in the 'ports' array (DT documentation).

> > It has to know the devices entering in the video chains.
> >   The CRTCs (LCD/TCON) are found by
> > ports[i] -> parent
> >   The connectors are found by
> > ports[i] -> endpoint -> remote_endpoint -> parent
> > 2- with ports pointing to the LCDs:
> >   The CRTCs (LCD/TCON) are simply
> > ports[i]
> >   The connectors are found by
> > loop on all ports of ports[i]
> > ports[i][j] -> endpoint -> remote_endpoint -> parent
> > 3- with a phandle to the DE in the LCDs:
> 
> What do you mean with LCD? Panels? Why would panels have a phandle to
> the display engine?

LCD is the same as CRTC. I don't think people will connect old CRT's to
their new ARM boards. LCD's may be panels, modern TV sets, or any
digital display. The word LCD seems clearer to me in this context, even
if there may a DAC as an ancoder.

> >   The DE cannot be the DRM device because there is no information about
> >   the video devices in the DT. Then, the DRM devices are the LCDs.
> >   These LCDs must give their indices to the DE. So, the DE must implement
> >   some callback function to accept a LCD definition, and there must be
> >   a list of DEs in the driver to make the association DE <-> LCD[i]
> >   Some more problem may be raised if a user wants to have the same frame
> >   buffer on the 2 LCDs of a DE.
> 
> I have no idea what you're talking about, sorry.

Here is the DT (I am using back 'CRTC'):

de: display-controller@xxx {
...
};
crtc0: crt-controller@xxx{
...
display-controller = <>;
ports {
... /* to the crtc0 connectors */
}
};
crtc1: crt-controller@xxx{
...
display-controller = <>;
ports {
... /* to the crtc1 connectors */
};
};

There are 2 DRM devices: one on crtc0, the other one on crtc1.
The DE device is isolated. But, to treat the planes, it must receive
information about the CRTCs. How?

> > Anyway, my solution is already used in the IMX Soc.
> > See 'display-subsystem' in arch/arm/boot/dts/imx6q.dtsi for an example.
> 
> Pointing out random example in the tree doesn't make a compelling
> argument.

This is not a random example. There was a thread about the 'ports'
phandle in the DT definition of the IMX video subsystem, and what kind
of OF function should be used (see one of my previous mails). In the DRI
list, nobody objected about the phandle by itself.

> > > > > > > Panel functions? In the CRTC driver?
> > > > > > 
> > > > > > Yes, dumb panel.
> > > > > 
> > > > > What do you mean by that? Using a Parallel/RGB interface?
> > > > 
> > > > Sorry, I though this was a well-known name. The 'dump panel' was used
> > > > in the documentation of my previous ARM machine as the video frame sent
> > > > to the HDMI controller. 'video_frame' is OK for you?
> > > 
> > > If it's the frame sent to the encoder, then it would be the CRTC by
> > > DRM's nomenclature.
> > 
> > The CRTC is a software entity. The frame buffer is a hardware entity.
> 
> Why are you about framebuffer now, this is nowhere in that
> discussion. Any way, the framebuffer is also what is put in a plane,
> so there's a name collision here, and you'll probably want to change
> 

[linux-sunxi] [PATCH 4.8 65/92] Revert "clocksource/drivers/timer_sun5i: Replace code by clocksource_mmio_init"

[Greg Kroah-Hartman]

4.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Chen-Yu Tsai 

commit 593876838826914a7e4e05fbbcb728be6fbc4d89 upstream.

struct clocksource is also used by the clk notifier callback, to
unregister and re-register the clocksource with a different clock rate.
clocksource_mmio_init does not pass back a pointer to the struct used,
and the clk notifier callback assumes that the struct clocksource in
struct sun5i_timer_clksrc is valid. This results in a kernel NULL
pointer dereference when the hstimer clock is changed:

Unable to handle kernel NULL pointer dereference at virtual address 0004
[] (clocksource_unbind) from [] 
(clocksource_unregister+0x2c/0x44)
[] (clocksource_unregister) from [] 
(sun5i_rate_cb_clksrc+0x34/0x3c)
[] (sun5i_rate_cb_clksrc) from [] 
(notifier_call_chain+0x44/0x84)
[] (notifier_call_chain) from [] 
(__srcu_notifier_call_chain+0x44/0x60)
[] (__srcu_notifier_call_chain) from [] 
(srcu_notifier_call_chain+0x18/0x20)
[] (srcu_notifier_call_chain) from [] 
(__clk_notify+0x70/0x7c)
[] (__clk_notify) from [] 
(clk_propagate_rate_change+0xa4/0xc4)
[] (clk_propagate_rate_change) from [] 
(clk_propagate_rate_change+0x6c/0xc4)

Revert the commit for now. clocksource_mmio_init can be made to pass back
a pointer, but the code churn and usage of an inner struct might not be
worth it.

Fixes: 157dfadef832 ("clocksource/drivers/timer_sun5i: Replace code by 
clocksource_mmio_init")
Reported-by: Maxime Ripard 
Signed-off-by: Chen-Yu Tsai 
Cc: linux-sunxi@googlegroups.com
Cc: Daniel Lezcano 
Cc: linux-arm-ker...@lists.infradead.org
Link: http://lkml.kernel.org/r/20161018054918.26855-1-w...@csie.org
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/clocksource/timer-sun5i.c |   16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

--- a/drivers/clocksource/timer-sun5i.c
+++ b/drivers/clocksource/timer-sun5i.c
@@ -152,6 +152,13 @@ static irqreturn_t sun5i_timer_interrupt
return IRQ_HANDLED;
 }
 
+static cycle_t sun5i_clksrc_read(struct clocksource *clksrc)
+{
+   struct sun5i_timer_clksrc *cs = to_sun5i_timer_clksrc(clksrc);
+
+   return ~readl(cs->timer.base + TIMER_CNTVAL_LO_REG(1));
+}
+
 static int sun5i_rate_cb_clksrc(struct notifier_block *nb,
unsigned long event, void *data)
 {
@@ -210,8 +217,13 @@ static int __init sun5i_setup_clocksourc
writel(TIMER_CTL_ENABLE | TIMER_CTL_RELOAD,
   base + TIMER_CTL_REG(1));
 
-   ret = clocksource_mmio_init(base + TIMER_CNTVAL_LO_REG(1), node->name,
-   rate, 340, 32, clocksource_mmio_readl_down);
+   cs->clksrc.name = node->name;
+   cs->clksrc.rating = 340;
+   cs->clksrc.read = sun5i_clksrc_read;
+   cs->clksrc.mask = CLOCKSOURCE_MASK(32);
+   cs->clksrc.flags = CLOCK_SOURCE_IS_CONTINUOUS;
+
+   ret = clocksource_register_hz(>clksrc, rate);
if (ret) {
pr_err("Couldn't register clock source.\n");
goto err_remove_notifier;


-- 
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] ARM: dts: sunxi: Explicitly enable pull-ups for MMC pins

[Chen-Yu Tsai]

In the past, all the MMC pins had

allwinner,pull = ;

which was actually a no-op. We were relying on U-boot to set the bias
pull up for us. These properties were removed as part of the fix up to
actually support no bias on the pins. During the transition some boards
experienced regular MMC time-outs during normal operation, while others
completely failed to initialize the SD card.

Given that MMC starts in open-drain mode and the pull-ups are required,
it's best to enable it for all the pin settings.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun4i-a10.dtsi | 1 +
 arch/arm/boot/dts/sun5i.dtsi | 1 +
 arch/arm/boot/dts/sun6i-a31.dtsi | 4 
 arch/arm/boot/dts/sun7i-a20.dtsi | 2 ++
 arch/arm/boot/dts/sun8i-a23-a33.dtsi | 3 +++
 arch/arm/boot/dts/sun8i-a83t.dtsi| 1 +
 arch/arm/boot/dts/sun8i-h3.dtsi  | 3 +++
 arch/arm/boot/dts/sun9i-a80.dtsi | 3 +++
 8 files changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index dae838e4dd9e..ba20b48c0702 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -1023,6 +1023,7 @@
   "PF3", "PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+   bias-pull-up;
};
 
mmc0_cd_pin_reference_design: mmc0_cd_pin@0 {
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 7ab6b336533e..54170147040f 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -582,6 +582,7 @@
   "PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+   bias-pull-up;
};
 
mmc2_pins_a: mmc2@0 {
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 7ea1116c7c88..20a0331ddfb5 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -547,6 +547,7 @@
 "PF3", "PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+   bias-pull-up;
};
 
mmc1_pins_a: mmc1@0 {
@@ -554,6 +555,7 @@
 "PG4", "PG5";
function = "mmc1";
drive-strength = <30>;
+   bias-pull-up;
};
 
mmc2_pins_a: mmc2@0 {
@@ -571,6 +573,7 @@
 "PC24";
function = "mmc2";
drive-strength = <30>;
+   bias-pull-up;
};
 
mmc3_8bit_emmc_pins: mmc3@1 {
@@ -580,6 +583,7 @@
 "PC24";
function = "mmc3";
drive-strength = <40>;
+   bias-pull-up;
};
 
uart0_pins_a: uart0@0 {
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 34d613b0dd73..a1ee4197129a 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -1179,6 +1179,7 @@
   "PF3", "PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+   bias-pull-up;
};
 
mmc0_cd_pin_reference_design: mmc0_cd_pin@0 {
@@ -1200,6 +1201,7 @@
   "PI7", "PI8", "PI9";
function = "mmc3";
drive-strength = <30>;
+   bias-pull-up;
};
 
ps20_pins_a: ps20@0 {
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi 
b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index ecb49a5a7615..bc3e936edfcf 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -293,6 +293,7 @@
   "PF3", "PF4", "PF5";
function = "mmc0";
drive-strength = <30>;
+   bias-pull-up;
};
 
mmc1_pins_a: mmc1@0 {
@@ -300,6 +301,7 @@
   "PG3", "PG4", "PG5";
function = "mmc1";
drive-strength = <30>;
+