[PATCH] mtd: spi-nor-ids: Add Spansion s25fs512s flash entry

[Kuldeep Singh]

Spansion "s25fs512s" flash is incorrectly decoded as "s25fl512s" on
various platforms as former is not present. Add the entry.

Linux already has both the flashes present. A snippet below:
{ "s25fl512s",  INFO6(0x010220, 0x4d0080, 256 * 1024, 256...},
{ "s25fs512s",  INFO6(0x010220, 0x4d0081, 256 * 1024, 256...},

Signed-off-by: Kuldeep Singh 
---
 drivers/mtd/spi/spi-nor-ids.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 973b6f8..42baa84 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -193,7 +193,8 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("s25sl064p",  0x010216, 0x4d00,  64 * 1024, 128, 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("s25fl256s0", 0x010219, 0x4d00, 256 * 1024, 128, USE_CLSR) },
{ INFO("s25fl256s1", 0x010219, 0x4d01,  64 * 1024, 512, 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
-   { INFO6("s25fl512s",  0x010220, 0x4d0081, 256 * 1024, 256, 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
+   { INFO6("s25fl512s",  0x010220, 0x4d0080, 256 * 1024, 256, 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
+   { INFO6("s25fs512s",  0x010220, 0x4d0081, 256 * 1024, 256, 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
{ INFO("s25fl512s_256k",  0x010220, 0x4d00, 256 * 1024, 256, 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
{ INFO("s25fl512s_64k",  0x010220, 0x4d01, 64 * 1024, 1024, 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
{ INFO("s25fl512s_512k", 0x010220, 0x4f00, 256 * 1024, 256, 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_CLSR) },
-- 
2.7.4

Re: XHCI bringup on the Raspberry Pi 4

[Bin Meng]

Hi Nicolas,

On Thu, Apr 2, 2020 at 1:30 AM Nicolas Saenz Julienne
 wrote:
>
> Hi All,
> I'm working on enabling the VIA805 XCHI controller found on the new Raspberry
> Pi 4. The controller sits behind a PCIe bus, which I've already implemented[1]
> and will submit once the XCHI issues are resolved, as it's worthless 
> otherwise.
>
> The XHCI initialization gets stuck after issuing the fist 'enable slot'
> command. I've been reviewing the whole init process and comparing it to 
> Linux's
> for days without finding anything fishy. DMA constraints, which are important
> on the RPi are mantained, and on top of that, I can confirm DMA trough PCIe
> works fine as I see two 'port status change' events available in the ring
> before completly stalling. Also note that, unsurprisingly, the CRR bit in the
> CRCR register (which marks the running state of the Command Ring state 
> machine)
> is never set after ringing the relevant doorbell.

This is probably caused by the required structure setup by U-Boot is
viewed as buggy by the xHCI controller, hence there is no response to
the first "enable slot" command.

Could you please compare all the data structures, with the one set up
by the Linux kernel?

BTW: does Linux kernel xHCI driver work on this RPI 4 board?

>
> I'm clueless at this point, I figure the VIA805 is sensitive to the ordering 
> of
> some of the operations we perform in u-boot, or worse, the timing. For 
> example,
> I tried replicanting Linux's behaviour with regard to 'port status change'
> events, processing them before calling the 'enable slot' command. I also tried
> to mimic Linux by enabling port-0's power (the USB3 port) before starting the
> HC. Again, no luck.
>
> I attached the usb/xhci debug output, any ideas on where to look will be
> apreciated.
>

Regards,
Bin

RE: [PATCH v2 1/2] serial: ns16550: Revert "Move PCI access from ofdata_to_platdata() to probe()"

[Ang, Chee Hong]

> On Thu, Apr 2, 2020 at 7:28 PM Ang, Chee Hong 
> wrote:
> > > On Thu, Apr 02, 2020 at 12:55:14PM +0800, Bin Meng wrote:
> > > > On Thu, Apr 2, 2020 at 1:55 AM Simon Glass  wrote:
> > > > > On Wed, 1 Apr 2020 at 11:39, Andy Shevchenko
> > >  wrote:
> > > > > > On Wed, Apr 01, 2020 at 10:56:26AM -0600, Simon Glass wrote:
> > > > > > > On Wed, 1 Apr 2020 at 08:45, Andy Shevchenko
> > >  wrote:
> > > > > > > > On Wed, Apr 1, 2020 at 5:32 PM Bin Meng
> > > > > > > > 
> > > wrote:
> > > > > > > > > On Wed, Apr 1, 2020 at 9:58 PM Andy Shevchenko
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > The commit breaks serial console on the Intel Edison.
> > > > > > > > > >
> > > > > > > > > > This reverts commit
> 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Andy Shevchenko
> > > > > > > > > > 
> > > > > > > > > > ---
> > > > > > > > > >  drivers/serial/ns16550.c | 40
> > > > > > > > > > 
> > > > > > > > > >  1 file changed, 12 insertions(+), 28 deletions(-)
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Could you please spend some time to investigate why this
> > > > > > > > > breaks Intel
> > > Edison?
> > > > > > > > >
> > > > > > > > > Reverting this patch would mean we break other boards
> > > > > > > > > too as Wolfgang's patch wanted to fix the breakage in
> > > > > > > > > the first place. Much appreciated!
> > > > > > > >
> > > > > > > > I guess I'm wrong person here. The DM code is a complete
> > > > > > > > black box to
> > > me.
> > > > > > > > Nevertheless, I may test any provided fix / debug / etc patch by
> request.
> > > > > > > >
> > > > > > > > And I think it's fair to investigate by the one who made a
> > > > > > > > regression in the first place.
> > > > > > >
> > > > > > > Given that we have conflicting breakages, we need to debug Edison.
> > > > > >
> > > > > > I would glad to test any suggested change or debug patch!
> > > > > >
> > > > > > > Does it enable the debug UART?
> > > > > >
> > > > > > If I am not mistaken, it does not.
> > > > >
> > > > > Looks like you are right. If you know the address you could do
> > > > > that
> > > > > - see minnowmax for an example.
> > > >
> > > > Please suggest what's the best approach to proceed.
> > >
> > > Adding SoCFPGA folks to this thread as the first commit
> > > (82de42fa1468) is also breaking platforms there and then their fix
> > > for that problem is also causing problems, if I follow right.
> 
> > Yes. This commit (82de42fa1468) breaks our A10 platform.
> > I did submit similar patch to move some init code from ofdata_to_platdata() 
> > to
> probe() for our clock driver as well.
> > Check out the thread here:
> > https://lists.denx.de/pipermail/u-boot/2020-April/405252.html
> 
> I see half or less of the messages in the thread by above link.
> Can you summarize what should have been done in order to fix this?
1) Fix in the driver (broken by this commit: 82de42fa1468) by moving some code 
from ofdata_to_platdata() to probe().
2) Fix the DM core.
Simon and Marek were discussing about these 2 options.
Perhaps Simon can help shed some light here.
> 
> --
> With Best Regards,
> Andy Shevchenko

RE: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function

[Tan, Ley Foon]

> -Original Message-
> From: Marek Vasut 
> Sent: Friday, April 3, 2020 6:47 AM
> To: Tom Rini 
> Cc: Simon Glass ; Ang, Chee Hong
> ; U-Boot Mailing List ;
> Simon Goldschmidt ; See, Chin Liang
> ; Tan, Ley Foon ;
> Westergreen, Dalon 
> Subject: Re: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register
> base in probe function
> 
> On 4/3/20 12:10 AM, Tom Rini wrote:
> > On Thu, Apr 02, 2020 at 11:07:31PM +0200, Marek Vasut wrote:
> >> On 4/2/20 10:54 PM, Tom Rini wrote:
> >> [...]
> >>
>  I'm not sure it definitely should be changed. But I'll do a
>  patch and see how it looks.
> >>>
> >>> Do I understand it correctly that the patch
> >>> 82de42fa14682d408da935adfb0f935354c5008f actually completely
> >>> breaks SoCFPGA ? Then I would say this is a release blocker ?
> >> Yes. A10 SPL won't boot at all. It crashes during the clock manager
> setup.
> >
> > This came in right at the beginning of the cycle. I thought the
> > purpose of the 3-month cycle was to allow time to test?
> 
>  It was ... altera ?
> >>>
> >>> Sorry, I'm missing how that's an answer to the question.  This came
> >>> in basically right at the start of the merge window.
> >>
> >> I don't have an A10 available right now, so what can I do ?
> >
> > Ah, so the answer is "I can't test this platform myself".  That's what
> > then, thanks.
> 
> Clearly Altera can , since they reported this issue.
Yes, we have Arria10 devkit here and we see the issue when testing latest uboot.
It looks like other platform [1] also encounter issue with patch 
82de42fa14682d40. Like Marek said, we don't know any other driver is broken 
after this patch.

[1] https://patchwork.ozlabs.org/patch/1265188/ 

Regards
Ley Foon

[PATCH v4 13/13] dt-bindings: usb: mtk-xhci: Add binding for MediaTek xHCI host controller

[Chunfeng Yun]

Add dt-binding for MediaTek xHCI host controller

Signed-off-by: Chunfeng Yun 
---
v2~v4: no changes
---
 .../usb/mediatek,mtk-xhci.txt | 40 +++
 1 file changed, 40 insertions(+)
 create mode 100644 doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt

diff --git a/doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt 
b/doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt
new file mode 100644
index 00..0447468a2d
--- /dev/null
+++ b/doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt
@@ -0,0 +1,40 @@
+MediaTek xHCI
+
+The device node for USB3 host controller on MediaTek SoCs.
+
+Required properties:
+ - compatible : should be "mediatek,mtk-xhci"
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be "mac" for xHCI MAC and "ippc" for IP port control
+ - power-domains : a phandle to USB power domain node to control USB's
+   MTCMOS
+ - vusb33-supply : regulator of USB avdd3.3v
+
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+   entry in clock-names
+ - clock-names : must contain
+   "sys_ck": controller clock used by normal mode,
+   the following ones are optional:
+   "ref_ck": reference clock used by low power mode etc,
+   "mcu_ck": mcu_bus clock for register access,
+   "dma_ck": dma_bus clock for data transfer by DMA,
+   "xhci_ck": controller clock
+
+ - phys : list of all the USB PHYs on this HCD
+ - phy-names: name specifier for the USB PHY
+
+Optional properties:
+ - vbus-supply : reference to the VBUS regulator;
+
+Example:
+xhci: usb@1a0c {
+   compatible = "mediatek,mt7629-xhci", "mediatek,mtk-xhci";
+   reg = <0x1a0c 0x1000>, <0x1a0c3e00 0x0100>;
+   reg-names = "mac", "ippc";
+   power-domains = <&scpsys MT7629_POWER_DOMAIN_HIF1>;
+   clocks = <&ssusbsys CLK_SSUSB_SYS_EN>, <&ssusbsys CLK_SSUSB_REF_EN>,
+<&ssusbsys CLK_SSUSB_MCU_EN>, <&ssusbsys CLK_SSUSB_DMA_EN>;
+   clock-names = "sys_ck", "ref_ck", "mcu_ck", "dma_ck";
+   phys = <&u2port0 PHY_TYPE_USB2>, <&u3port0 PHY_TYPE_USB3>;
+   status = "disabled";
+};
-- 
2.25.1

[PATCH v4 11/13] arm: dts: mt7629: add usb related nodes

[Chunfeng Yun]

Add usb, phy and clock nodes

Signed-off-by: Chunfeng Yun 
---
v3~v4: no changes

v2:
1. remove fixed clock clk20m
---
 arch/arm/dts/mt7629-rfb.dts |  8 
 arch/arm/dts/mt7629.dtsi| 41 +
 2 files changed, 49 insertions(+)

diff --git a/arch/arm/dts/mt7629-rfb.dts b/arch/arm/dts/mt7629-rfb.dts
index 687fe1c029..bf84f76344 100644
--- a/arch/arm/dts/mt7629-rfb.dts
+++ b/arch/arm/dts/mt7629-rfb.dts
@@ -82,6 +82,14 @@
status = "okay";
 };
 
+&xhci {
+   status = "okay";
+};
+
+&u3phy {
+   status = "okay";
+};
+
 &watchdog {
pinctrl-names = "default";
pinctrl-0 = <&watchdog_pins>;
diff --git a/arch/arm/dts/mt7629.dtsi b/arch/arm/dts/mt7629.dtsi
index a33a74a556..d1c99c5d6a 100644
--- a/arch/arm/dts/mt7629.dtsi
+++ b/arch/arm/dts/mt7629.dtsi
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "skeleton.dtsi"
 
 / {
@@ -222,6 +223,46 @@
#size-cells = <0>;
};
 
+   ssusbsys: ssusbsys@1a00 {
+   compatible = "mediatek,mt7629-ssusbsys", "syscon";
+   reg = <0x1a00 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   xhci: usb@1a0c {
+   compatible = "mediatek,mt7629-xhci", "mediatek,mtk-xhci";
+   reg = <0x1a0c 0x1000>, <0x1a0c3e00 0x0100>;
+   reg-names = "mac", "ippc";
+   power-domains = <&scpsys MT7629_POWER_DOMAIN_HIF1>;
+   clocks = <&ssusbsys CLK_SSUSB_SYS_EN>,
+<&ssusbsys CLK_SSUSB_REF_EN>,
+<&ssusbsys CLK_SSUSB_MCU_EN>,
+<&ssusbsys CLK_SSUSB_DMA_EN>;
+   clock-names = "sys_ck", "ref_ck", "mcu_ck", "dma_ck";
+   phys = <&u2port0 PHY_TYPE_USB2>, <&u3port0 PHY_TYPE_USB3>;
+   status = "disabled";
+   };
+
+   u3phy: usb-phy@1a0c4000 {
+   compatible = "mediatek,mt7629-tphy", "mediatek,generic-tphy-v2";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x1a0c4000 0x1000>;
+   status = "disabled";
+
+   u2port0: usb-phy@0 {
+   reg = <0x0 0x0700>;
+   #phy-cells = <1>;
+   clocks = <&ssusbsys CLK_SSUSB_U2_PHY_EN>;
+   clock-names = "ref";
+   };
+
+   u3port0: usb-phy@700 {
+   reg = <0x0700 0x0700>;
+   #phy-cells = <1>;
+   };
+   };
+
ethsys: syscon@1b00 {
compatible = "mediatek,mt7629-ethsys", "syscon";
reg = <0x1b00 0x1000>;
-- 
2.25.1

[PATCH v4 12/13] dt-bindings: phy-mtk-tphy: add properties of address mapping and clocks

[Chunfeng Yun]

1. add the address mapping related properties;
2. make "ref" clock optional, and add optional clock "da_ref";
3. add the banks layout of TPHY V1 and V2;

Signed-off-by: Chunfeng Yun 
---
v2~v4: no changes
---
 doc/device-tree-bindings/phy/phy-mtk-tphy.txt | 78 ---
 1 file changed, 68 insertions(+), 10 deletions(-)

diff --git a/doc/device-tree-bindings/phy/phy-mtk-tphy.txt 
b/doc/device-tree-bindings/phy/phy-mtk-tphy.txt
index 037c5a4be5..8cd23d8c0b 100644
--- a/doc/device-tree-bindings/phy/phy-mtk-tphy.txt
+++ b/doc/device-tree-bindings/phy/phy-mtk-tphy.txt
@@ -7,10 +7,17 @@ controllers on MediaTek SoCs, such as, USB2.0, USB3.0, PCIe, 
and SATA.
 Required properties (controller (parent) node):
  - compatible  : should be one of
  "mediatek,generic-tphy-v1"
- - clocks  : (deprecated, use port's clocks instead) a list of phandle +
- clock-specifier pairs, one for each entry in clock-names
- - clock-names : (deprecated, use port's one instead) must contain
- "u3phya_ref": for reference clock of usb3.0 analog phy.
+ "mediatek,generic-tphy-v2"
+
+- #address-cells:  the number of cells used to represent physical
+   base addresses.
+- #size-cells: the number of cells used to represent the size of an address.
+- ranges:  the address mapping relationship to the parent, defined with
+   - empty value: if optional 'reg' is used.
+   - non-empty value: if optional 'reg' is not used. should set
+   the child's base address to 0, the physical address
+   within parent's address space, and the length of
+   the address map.
 
 Required nodes : a sub-node is required for each port the controller
  provides. Address range information including the usual
@@ -27,12 +34,6 @@ Optional properties (controller (parent) node):
 
 Required properties (port (child) node):
 - reg  : address and length of the register set for the port.
-- clocks   : a list of phandle + clock-specifier pairs, one for each
- entry in clock-names
-- clock-names  : must contain
- "ref": 48M reference clock for HighSpeed analog phy; and 26M
-   reference clock for SuperSpeed analog phy, sometimes is
-   24M, 25M or 27M, depended on platform.
 - #phy-cells   : should be 1 (See second example)
  cell after port phandle is phy type from:
- PHY_TYPE_USB2
@@ -40,6 +41,17 @@ Required properties (port (child) node):
- PHY_TYPE_PCIE
- PHY_TYPE_SATA
 
+Optional properties (port (child) node):
+- clocks   : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+- clock-names  : may contain
+ "ref": 48M reference clock for HighSpeed (digital) phy; and 
26M
+   reference clock for SuperSpeed (digital) phy, sometimes 
is
+   24M, 25M or 27M, depended on platform.
+ "da_ref": the reference clock of analog phy, used if the 
clocks
+   of analog and digital phys are separated, otherwise uses
+   "ref" clock only if needed.
+
 Example:
 
u3phy2: usb-phy@1a244000 {
@@ -84,3 +96,49 @@ usb30: usb@1127 {
phy-names = "usb2-0", "usb3-0";
...
 };
+
+Layout differences of banks between TPHY V1 and V2
+-
+IP V1:
+portoffsetbank
+shared  0xSPLLC
+0x0100FMREG
+u2 port00x0800U2PHY_COM
+u3 port00x0900U3PHYD
+0x0a00U3PHYD_BANK2
+0x0b00U3PHYA
+0x0c00U3PHYA_DA
+u2 port10x1000U2PHY_COM
+u3 port10x1100U3PHYD
+0x1200U3PHYD_BANK2
+0x1300U3PHYA
+0x1400U3PHYA_DA
+u2 port20x1800U2PHY_COM
+...
+
+IP V2:
+portoffsetbank
+u2 port00xMISC
+0x0100FMREG
+0x0300U2PHY_COM
+u3 port00x0700SPLLC
+0x0800CHIP
+0x0900U3PHYD
+0x0a00U3PHYD_BANK2
+0x0b00U3PHYA
+0x0c00U3PHYA_DA
+u2 port10x1000MISC
+0x1100FMREG
+0x1300U2PHY_COM
+u3 port10x1700SPLLC
+0x1800CHIP
+0x1900U3PHYD
+0x1a00U3PHYD_BANK2
+0x1b00U3PHYA
+0x1c00U3PHYA_DA
+u2 port20x2000MISC
+...
+
+SPLLC shared by u3 ports and FMREG shared by u2 ports on
+TPHY V1 are put back into each port; a new bank MISC for
+u2 ports and CHIP for u3 ports are added on TPHY V2.
-- 
2.25.1

[PATCH v4 04/13] test: dm: phy: add a test item for the phy_bulk API

[Chunfeng Yun]

Add a test item for the phy_bulk API

Signed-off-by: Chunfeng Yun 
---
v4: new patch
---
 arch/sandbox/dts/test.dts | 11 +++
 test/dm/phy.c | 29 +
 2 files changed, 40 insertions(+)

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 09e69a9d33..58f5309e4d 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -143,12 +143,23 @@
broken;
};
 
+   phy_provider2: gen_phy@2 {
+   compatible = "sandbox,phy";
+   #phy-cells = <0>;
+   };
+
gen_phy_user: gen_phy_user {
compatible = "simple-bus";
phys = <&phy_provider0 0>, <&phy_provider0 1>, <&phy_provider1>;
phy-names = "phy1", "phy2", "phy3";
};
 
+   gen_phy_user1: gen_phy_user1 {
+   compatible = "simple-bus";
+   phys = <&phy_provider0 0>, <&phy_provider2>;
+   phy-names = "phy1", "phy2";
+   };
+
some-bus {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/test/dm/phy.c b/test/dm/phy.c
index 21d92194b9..11d648c72f 100644
--- a/test/dm/phy.c
+++ b/test/dm/phy.c
@@ -110,3 +110,32 @@ static int dm_test_phy_ops(struct unit_test_state *uts)
return 0;
 }
 DM_TEST(dm_test_phy_ops, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+static int dm_test_phy_bulk(struct unit_test_state *uts)
+{
+   struct phy_bulk phys;
+   struct udevice *parent;
+
+   /* test normal operations */
+   ut_assertok(uclass_get_device_by_name(UCLASS_SIMPLE_BUS,
+ "gen_phy_user1", &parent));
+
+   ut_assertok(generic_phy_get_bulk(parent, &phys));
+   ut_asserteq(2, phys.count);
+
+   ut_asserteq(0, generic_phy_enable_bulk(&phys));
+   ut_asserteq(0, generic_phy_disable_bulk(&phys));
+
+   /* has a known problem phy */
+   ut_assertok(uclass_get_device_by_name(UCLASS_SIMPLE_BUS,
+ "gen_phy_user", &parent));
+
+   ut_assertok(generic_phy_get_bulk(parent, &phys));
+   ut_asserteq(3, phys.count);
+
+   ut_asserteq(-EIO, generic_phy_enable_bulk(&phys));
+   ut_asserteq(-EIO, generic_phy_disable_bulk(&phys));
+
+   return 0;
+}
+DM_TEST(dm_test_phy_bulk, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
-- 
2.25.1

[PATCH v4 07/13] phy: phy-mtk-tphy: add support USB phys

[Chunfeng Yun]

Support USB2 and USB3 PHY with shared banks when support multi-phys

Signed-off-by: Chunfeng Yun 
---
v3~v4: no changes

v2:
1. get the count of phys by dev_get_child_count()
---
 drivers/phy/phy-mtk-tphy.c | 227 +++--
 1 file changed, 218 insertions(+), 9 deletions(-)

diff --git a/drivers/phy/phy-mtk-tphy.c b/drivers/phy/phy-mtk-tphy.c
index bd089b7a43..71bc706c6e 100644
--- a/drivers/phy/phy-mtk-tphy.c
+++ b/drivers/phy/phy-mtk-tphy.c
@@ -20,11 +20,66 @@
 /* version V1 sub-banks offset base address */
 /* banks shared by multiple phys */
 #define SSUSB_SIFSLV_V1_SPLLC  0x000   /* shared by u3 phys */
+#define SSUSB_SIFSLV_V1_U2FREQ 0x100   /* shared by u2 phys */
 #define SSUSB_SIFSLV_V1_CHIP   0x300   /* shared by u3 phys */
+/* u2 phy bank */
+#define SSUSB_SIFSLV_V1_U2PHY_COM  0x000
 /* u3/pcie/sata phy banks */
 #define SSUSB_SIFSLV_V1_U3PHYD 0x000
 #define SSUSB_SIFSLV_V1_U3PHYA 0x200
 
+#define U3P_USBPHYACR0 0x000
+#define PA0_RG_U2PLL_FORCE_ON  BIT(15)
+#define PA0_RG_USB20_INTR_EN   BIT(5)
+
+#define U3P_USBPHYACR5 0x014
+#define PA5_RG_U2_HSTX_SRCAL_ENBIT(15)
+#define PA5_RG_U2_HSTX_SRCTRL  GENMASK(14, 12)
+#define PA5_RG_U2_HSTX_SRCTRL_VAL(x)   ((0x7 & (x)) << 12)
+#define PA5_RG_U2_HS_100U_U3_ENBIT(11)
+
+#define U3P_USBPHYACR6 0x018
+#define PA6_RG_U2_BC11_SW_EN   BIT(23)
+#define PA6_RG_U2_OTG_VBUSCMP_EN   BIT(20)
+#define PA6_RG_U2_SQTH GENMASK(3, 0)
+#define PA6_RG_U2_SQTH_VAL(x)  (0xf & (x))
+
+#define U3P_U2PHYACR4  0x020
+#define P2C_RG_USB20_GPIO_CTL  BIT(9)
+#define P2C_USB20_GPIO_MODEBIT(8)
+#define P2C_U2_GPIO_CTR_MSK\
+   (P2C_RG_USB20_GPIO_CTL | P2C_USB20_GPIO_MODE)
+
+#define U3P_U2PHYDTM0  0x068
+#define P2C_FORCE_UART_EN  BIT(26)
+#define P2C_FORCE_DATAIN   BIT(23)
+#define P2C_FORCE_DM_PULLDOWN  BIT(21)
+#define P2C_FORCE_DP_PULLDOWN  BIT(20)
+#define P2C_FORCE_XCVRSEL  BIT(19)
+#define P2C_FORCE_SUSPENDM BIT(18)
+#define P2C_FORCE_TERMSEL  BIT(17)
+#define P2C_RG_DATAIN  GENMASK(13, 10)
+#define P2C_RG_DATAIN_VAL(x)   ((0xf & (x)) << 10)
+#define P2C_RG_DMPULLDOWN  BIT(7)
+#define P2C_RG_DPPULLDOWN  BIT(6)
+#define P2C_RG_XCVRSEL GENMASK(5, 4)
+#define P2C_RG_XCVRSEL_VAL(x)  ((0x3 & (x)) << 4)
+#define P2C_RG_SUSPENDMBIT(3)
+#define P2C_RG_TERMSEL BIT(2)
+#define P2C_DTM0_PART_MASK \
+   (P2C_FORCE_DATAIN | P2C_FORCE_DM_PULLDOWN | \
+   P2C_FORCE_DP_PULLDOWN | P2C_FORCE_XCVRSEL | \
+   P2C_FORCE_TERMSEL | P2C_RG_DMPULLDOWN | \
+   P2C_RG_DPPULLDOWN | P2C_RG_TERMSEL)
+
+#define U3P_U2PHYDTM1  0x06C
+#define P2C_RG_UART_EN BIT(16)
+#define P2C_FORCE_IDDIGBIT(9)
+#define P2C_RG_VBUSVALID   BIT(5)
+#define P2C_RG_SESSEND BIT(4)
+#define P2C_RG_AVALID  BIT(2)
+#define P2C_RG_IDDIG   BIT(1)
+
 #define U3P_U3_CHIP_GPIO_CTLD  0x0c
 #define P3C_REG_IP_SW_RST  BIT(31)
 #define P3C_MCU_BUS_CK_GATE_EN BIT(30)
@@ -42,6 +97,14 @@
 #define P3A_RG_CLKDRV_AMP  GENMASK(31, 29)
 #define P3A_RG_CLKDRV_AMP_VAL(x)   ((0x7 & (x)) << 29)
 
+#define U3P_U3_PHYA_REG6   0x018
+#define P3A_RG_TX_EIDLE_CM GENMASK(31, 28)
+#define P3A_RG_TX_EIDLE_CM_VAL(x)  ((0xf & (x)) << 28)
+
+#define U3P_U3_PHYA_REG9   0x024
+#define P3A_RG_RX_DAC_MUX  GENMASK(5, 1)
+#define P3A_RG_RX_DAC_MUX_VAL(x)   ((0x1f & (x)) << 1)
+
 #define U3P_U3_PHYA_DA_REG00x100
 #define P3A_RG_XTAL_EXT_PE2H   GENMASK(17, 16)
 #define P3A_RG_XTAL_EXT_PE2H_VAL(x)((0x3 & (x)) << 16)
@@ -77,6 +140,16 @@
 #define P3A_RG_PLL_DELTA_PE2H  GENMASK(15, 0)
 #define P3A_RG_PLL_DELTA_PE2H_VAL(x)   (0x & (x))
 
+#define U3P_U3_PHYD_LFPS1  0x00c
+#define P3D_RG_FWAKE_THGENMASK(21, 16)
+#define P3D_RG_FWAKE_TH_VAL(x) ((0x3f & (x)) << 16)
+
+#define U3P_U3_PHYD_CDR1   0x05c
+#define P3D_RG_CDR_BIR_LTD1GENMASK(28, 24)
+#define P3D_RG_CDR_BIR_LTD1_VAL(x) ((0x1f & (x)) << 24)
+#define P3D_RG_CDR_BIR_LTD0GENMASK(12, 8)
+#define P3D_RG_CDR_BIR_LTD0_VAL(x) ((0x1f & (x)) << 8)
+
 #define U3P_U3_PHYD_RXDET1 0x128
 #define P3D_RG_RXDET_STB2_SET  GENMASK(17, 9)
 #define P3D_RG_RXDET_STB2_SET_VAL(x)   ((0x1ff & (x)) << 9)
@@ -85,6 +158,16 @@
 #define P3D_RG_RXDET_STB2_SET_P3   GENMASK(8, 0)
 #define P3D_RG_RXDET_STB2_SET_P3_VAL(x)(0x1ff & (x))
 
+#define U3P_SPLLC_XTALCTL3  

[PATCH v4 08/13] phy: phy-mtk-tphy: add support new version

[Chunfeng Yun]

The new version removes all shared banks between multi-phys

Signed-off-by: Chunfeng Yun 
---
v2~v4: no changes
---
 drivers/phy/phy-mtk-tphy.c | 68 +++---
 1 file changed, 63 insertions(+), 5 deletions(-)

diff --git a/drivers/phy/phy-mtk-tphy.c b/drivers/phy/phy-mtk-tphy.c
index 71bc706c6e..20167fe7cb 100644
--- a/drivers/phy/phy-mtk-tphy.c
+++ b/drivers/phy/phy-mtk-tphy.c
@@ -28,6 +28,17 @@
 #define SSUSB_SIFSLV_V1_U3PHYD 0x000
 #define SSUSB_SIFSLV_V1_U3PHYA 0x200
 
+/* version V2 sub-banks offset base address */
+/* u2 phy banks */
+#define SSUSB_SIFSLV_V2_MISC   0x000
+#define SSUSB_SIFSLV_V2_U2FREQ 0x100
+#define SSUSB_SIFSLV_V2_U2PHY_COM  0x300
+/* u3/pcie/sata phy banks */
+#define SSUSB_SIFSLV_V2_SPLLC  0x000
+#define SSUSB_SIFSLV_V2_CHIP   0x100
+#define SSUSB_SIFSLV_V2_U3PHYD 0x200
+#define SSUSB_SIFSLV_V2_U3PHYA 0x400
+
 #define U3P_USBPHYACR0 0x000
 #define PA0_RG_U2PLL_FORCE_ON  BIT(15)
 #define PA0_RG_USB20_INTR_EN   BIT(5)
@@ -162,6 +173,11 @@
 #define XC3_RG_U3_XTAL_RX_PWD  BIT(9)
 #define XC3_RG_U3_FRC_XTAL_RX_PWD  BIT(8)
 
+enum mtk_phy_version {
+   MTK_TPHY_V1 = 1,
+   MTK_TPHY_V2,
+};
+
 struct u2phy_banks {
void __iomem *misc;
void __iomem *fmreg;
@@ -192,6 +208,7 @@ struct mtk_phy_instance {
 struct mtk_tphy {
struct udevice *dev;
void __iomem *sif_base;
+   enum mtk_phy_version version;
struct mtk_phy_instance **phys;
int nphys;
 };
@@ -304,6 +321,9 @@ static void pcie_phy_instance_init(struct mtk_tphy *tphy,
 {
struct u3phy_banks *u3_banks = &instance->u3_banks;
 
+   if (tphy->version != MTK_TPHY_V1)
+   return;
+
clrsetbits_le32(u3_banks->phya + U3P_U3_PHYA_DA_REG0,
P3A_RG_XTAL_EXT_PE1H | P3A_RG_XTAL_EXT_PE2H,
P3A_RG_XTAL_EXT_PE1H_VAL(0x2) |
@@ -398,6 +418,31 @@ static void phy_v1_banks_init(struct mtk_tphy *tphy,
}
 }
 
+static void phy_v2_banks_init(struct mtk_tphy *tphy,
+ struct mtk_phy_instance *instance)
+{
+   struct u2phy_banks *u2_banks = &instance->u2_banks;
+   struct u3phy_banks *u3_banks = &instance->u3_banks;
+
+   switch (instance->type) {
+   case PHY_TYPE_USB2:
+   u2_banks->misc = instance->port_base + SSUSB_SIFSLV_V2_MISC;
+   u2_banks->fmreg = instance->port_base + SSUSB_SIFSLV_V2_U2FREQ;
+   u2_banks->com = instance->port_base + SSUSB_SIFSLV_V2_U2PHY_COM;
+   break;
+   case PHY_TYPE_USB3:
+   case PHY_TYPE_PCIE:
+   u3_banks->spllc = instance->port_base + SSUSB_SIFSLV_V2_SPLLC;
+   u3_banks->chip = instance->port_base + SSUSB_SIFSLV_V2_CHIP;
+   u3_banks->phyd = instance->port_base + SSUSB_SIFSLV_V2_U3PHYD;
+   u3_banks->phya = instance->port_base + SSUSB_SIFSLV_V2_U3PHYA;
+   break;
+   default:
+   dev_err(tphy->dev, "incompatible PHY type\n");
+   return;
+   }
+}
+
 static int mtk_phy_init(struct phy *phy)
 {
struct mtk_tphy *tphy = dev_get_priv(phy->dev);
@@ -500,7 +545,14 @@ static int mtk_phy_xlate(struct phy *phy,
return -EINVAL;
}
 
-   phy_v1_banks_init(tphy, instance);
+   if (tphy->version == MTK_TPHY_V1) {
+   phy_v1_banks_init(tphy, instance);
+   } else if (tphy->version == MTK_TPHY_V2) {
+   phy_v2_banks_init(tphy, instance);
+   } else {
+   dev_err(phy->dev, "phy version is not supported\n");
+   return -EINVAL;
+   }
 
return 0;
 }
@@ -527,9 +579,14 @@ static int mtk_tphy_probe(struct udevice *dev)
return -ENOMEM;
 
tphy->dev = dev;
-   tphy->sif_base = dev_read_addr_ptr(dev);
-   if (!tphy->sif_base)
-   return -ENOENT;
+   tphy->version = dev_get_driver_data(dev);
+
+   /* v1 has shared banks */
+   if (tphy->version == MTK_TPHY_V1) {
+   tphy->sif_base = dev_read_addr_ptr(dev);
+   if (!tphy->sif_base)
+   return -ENOENT;
+   }
 
dev_for_each_subnode(subnode, dev) {
struct mtk_phy_instance *instance;
@@ -560,7 +617,8 @@ static int mtk_tphy_probe(struct udevice *dev)
 }
 
 static const struct udevice_id mtk_tphy_id_table[] = {
-   { .compatible = "mediatek,generic-tphy-v1", },
+   { .compatible = "mediatek,generic-tphy-v1", .data = MTK_TPHY_V1, },
+   { .compatible = "mediatek,generic-tphy-v2", .data = MTK_TPHY_V2, },
{ }
 };
 
-- 
2.25.1

[PATCH v4 01/13] dm: core: Add function to get child count of ofnode or device

[Chunfeng Yun]

This patch add function used to get the child count of
a ofnode or a device

Signed-off-by: Chunfeng Yun 
---
v4: no changes

v3:
1. add non/inline function dev_get_child_count() instead of macro suggested 
by Simon

v2:
1. move ofnode_get_child_count() into ofnode.c suggested by Simon
2. add a new macro dev_get_child_count()
---
 drivers/core/ofnode.c | 11 +++
 drivers/core/read.c   |  5 +
 include/dm/ofnode.h   |  8 
 include/dm/read.h | 13 +
 4 files changed, 37 insertions(+)

diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 96a5dd20bd..6f4eb422a4 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -453,6 +453,17 @@ ofnode ofnode_get_chosen_node(const char *name)
return ofnode_path(prop);
 }
 
+int ofnode_get_child_count(ofnode parent)
+{
+   ofnode child;
+   int num = 0;
+
+   ofnode_for_each_subnode(child, parent)
+   num++;
+
+   return num;
+}
+
 static int decode_timing_property(ofnode node, const char *name,
  struct timing_entry *result)
 {
diff --git a/drivers/core/read.c b/drivers/core/read.c
index 1f999b1b31..046381f3a8 100644
--- a/drivers/core/read.c
+++ b/drivers/core/read.c
@@ -323,3 +323,8 @@ fdt_addr_t dev_read_addr_pci(const struct udevice *dev)
 
return addr;
 }
+
+int dev_get_child_count(const struct udevice *dev)
+{
+   return ofnode_get_child_count(dev_ofnode(dev));
+}
diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
index b5a50e8849..0d521dbcf1 100644
--- a/include/dm/ofnode.h
+++ b/include/dm/ofnode.h
@@ -793,6 +793,14 @@ ofnode ofnode_by_prop_value(ofnode from, const char 
*propname,
 ofnode_valid(node); \
 node = ofnode_next_subnode(node))
 
+/**
+ * ofnode_get_child_count() - get the child count of a ofnode
+ *
+ * @node: valid node to get its child count
+ * @return the number of subnodes
+ */
+int ofnode_get_child_count(ofnode parent);
+
 /**
  * ofnode_translate_address() - Translate a device-tree address
  *
diff --git a/include/dm/read.h b/include/dm/read.h
index da8c7f25e7..38cf76d07a 100644
--- a/include/dm/read.h
+++ b/include/dm/read.h
@@ -607,6 +607,14 @@ u64 dev_translate_dma_address(const struct udevice *dev,
  */
 int dev_read_alias_highest_id(const char *stem);
 
+/**
+ * dev_get_child_count() - get the child count of a device
+ *
+ * @dev: device to use for interation (struct udevice *)
+ * @return the count of child subnode
+ */
+int dev_get_child_count(const struct udevice *dev);
+
 #else /* CONFIG_DM_DEV_READ_INLINE is enabled */
 
 static inline int dev_read_u32(const struct udevice *dev,
@@ -885,6 +893,11 @@ static inline int dev_read_alias_highest_id(const char 
*stem)
return fdtdec_get_alias_highest_id(gd->fdt_blob, stem);
 }
 
+static inline int dev_get_child_count(const struct udevice *dev)
+{
+   return ofnode_get_child_count(dev_ofnode(dev));
+}
+
 #endif /* CONFIG_DM_DEV_READ_INLINE */
 
 /**
-- 
2.25.1

[PATCH v4 06/13] usb: dwc2_udc_otg: use the phy bulk API to get phys

[Chunfeng Yun]

Use the phy bulk API to get a group of phys

Signed-off-by: Chunfeng Yun 
---
v4: new patch
---
 drivers/usb/gadget/dwc2_udc_otg.c | 90 +--
 1 file changed, 12 insertions(+), 78 deletions(-)

diff --git a/drivers/usb/gadget/dwc2_udc_otg.c 
b/drivers/usb/gadget/dwc2_udc_otg.c
index 496abf38e7..c3d2575571 100644
--- a/drivers/usb/gadget/dwc2_udc_otg.c
+++ b/drivers/usb/gadget/dwc2_udc_otg.c
@@ -943,8 +943,7 @@ int usb_gadget_handle_interrupts(int index)
 struct dwc2_priv_data {
struct clk_bulk clks;
struct reset_ctl_bulk   resets;
-   struct phy *phys;
-   int num_phys;
+   struct phy_bulk phys;
struct udevice *usb33d_supply;
 };
 
@@ -953,87 +952,22 @@ int dm_usb_gadget_handle_interrupts(struct udevice *dev)
return dwc2_udc_handle_interrupt();
 }
 
-int dwc2_phy_setup(struct udevice *dev, struct phy **array, int *num_phys)
+static int dwc2_phy_setup(struct udevice *dev, struct phy_bulk *phys)
 {
-   int i, ret, count;
-   struct phy *usb_phys;
-
-   /* Return if no phy declared */
-   if (!dev_read_prop(dev, "phys", NULL))
-   return 0;
-
-   count = dev_count_phandle_with_args(dev, "phys", "#phy-cells");
-   if (count <= 0)
-   return count;
-
-   usb_phys = devm_kcalloc(dev, count, sizeof(struct phy),
-   GFP_KERNEL);
-   if (!usb_phys)
-   return -ENOMEM;
-
-   for (i = 0; i < count; i++) {
-   ret = generic_phy_get_by_index(dev, i, &usb_phys[i]);
-   if (ret && ret != -ENOENT) {
-   dev_err(dev, "Failed to get USB PHY%d for %s\n",
-   i, dev->name);
-   return ret;
-   }
-   }
-
-   for (i = 0; i < count; i++) {
-   ret = generic_phy_init(&usb_phys[i]);
-   if (ret) {
-   dev_err(dev, "Can't init USB PHY%d for %s\n",
-   i, dev->name);
-   goto phys_init_err;
-   }
-   }
+   int ret;
 
-   for (i = 0; i < count; i++) {
-   ret = generic_phy_power_on(&usb_phys[i]);
-   if (ret) {
-   dev_err(dev, "Can't power USB PHY%d for %s\n",
-   i, dev->name);
-   goto phys_poweron_err;
-   }
+   ret = generic_phy_get_bulk(dev, phys);
+   if (ret) {
+   dev_err(dev, "Failed to get phys\n");
+   return ret;
}
 
-   *array = usb_phys;
-   *num_phys =  count;
-
-   return 0;
-
-phys_poweron_err:
-   for (i = count - 1; i >= 0; i--)
-   generic_phy_power_off(&usb_phys[i]);
-
-   for (i = 0; i < count; i++)
-   generic_phy_exit(&usb_phys[i]);
-
-   return ret;
-
-phys_init_err:
-   for (; i >= 0; i--)
-   generic_phy_exit(&usb_phys[i]);
-
-   return ret;
+   return generic_phy_enable_bulk(phys);
 }
 
-void dwc2_phy_shutdown(struct udevice *dev, struct phy *usb_phys, int num_phys)
+static void dwc2_phy_shutdown(struct udevice *dev, struct phy_bulk *phys)
 {
-   int i, ret;
-
-   for (i = 0; i < num_phys; i++) {
-   if (!generic_phy_valid(&usb_phys[i]))
-   continue;
-
-   ret = generic_phy_power_off(&usb_phys[i]);
-   ret |= generic_phy_exit(&usb_phys[i]);
-   if (ret) {
-   dev_err(dev, "Can't shutdown USB PHY%d for %s\n",
-   i, dev->name);
-   }
-   }
+   generic_phy_disable_bulk(phys);
 }
 
 static int dwc2_udc_otg_ofdata_to_platdata(struct udevice *dev)
@@ -1159,7 +1093,7 @@ static int dwc2_udc_otg_probe(struct udevice *dev)
if (ret)
return ret;
 
-   ret = dwc2_phy_setup(dev, &priv->phys, &priv->num_phys);
+   ret = dwc2_phy_setup(dev, &priv->phys);
if (ret)
return ret;
 
@@ -1209,7 +1143,7 @@ static int dwc2_udc_otg_remove(struct udevice *dev)
 
clk_release_bulk(&priv->clks);
 
-   dwc2_phy_shutdown(dev, priv->phys, priv->num_phys);
+   dwc2_phy_shutdown(dev, &priv->phys);
 
return dm_scan_fdt_dev(dev);
 }
-- 
2.25.1

[PATCH v4 10/13] xhci: mediatek: Add support for MTK xHCI host controller

[Chunfeng Yun]

This patch is used to support the on-chip xHCI controller on
MediaTek SoCs, currently only control/bulk transfers are
supported.

Signed-off-by: Chunfeng Yun 
---
v4:
1. use phy_bulk API

v3:
1. use macro approach to access registers suggested by Marek

v2:
1. use clk_bulk to get clocks suggested by Marek
2. use clrsetbits_le32() etc suggeseted by Marek
---
 drivers/usb/host/Kconfig|   6 +
 drivers/usb/host/Makefile   |   1 +
 drivers/usb/host/xhci-mtk.c | 297 
 3 files changed, 304 insertions(+)
 create mode 100644 drivers/usb/host/xhci-mtk.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 0987ff25b1..931af268f4 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -30,6 +30,12 @@ config USB_XHCI_DWC3_OF_SIMPLE
  Support USB2/3 functionality in simple SoC integrations with
  USB controller based on the DesignWare USB3 IP Core.
 
+config USB_XHCI_MTK
+   bool "Support for MediaTek on-chip xHCI USB controller"
+   depends on ARCH_MEDIATEK
+   help
+ Enables support for the on-chip xHCI controller on MediaTek SoCs.
+
 config USB_XHCI_MVEBU
bool "MVEBU USB 3.0 support"
default y
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 7feeff679c..104821f188 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_USB_XHCI_DWC3_OF_SIMPLE) += dwc3-of-simple.o
 obj-$(CONFIG_USB_XHCI_ROCKCHIP) += xhci-rockchip.o
 obj-$(CONFIG_USB_XHCI_EXYNOS) += xhci-exynos5.o
 obj-$(CONFIG_USB_XHCI_FSL) += xhci-fsl.o
+obj-$(CONFIG_USB_XHCI_MTK) += xhci-mtk.o
 obj-$(CONFIG_USB_XHCI_MVEBU) += xhci-mvebu.o
 obj-$(CONFIG_USB_XHCI_OMAP) += xhci-omap.o
 obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
new file mode 100644
index 00..2fd7ae55d7
--- /dev/null
+++ b/drivers/usb/host/xhci-mtk.c
@@ -0,0 +1,297 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019 MediaTek, Inc.
+ * Authors: Chunfeng Yun 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* IPPC (IP Port Control) registers */
+#define IPPC_IP_PW_CTRL0   0x00
+#define CTRL0_IP_SW_RSTBIT(0)
+
+#define IPPC_IP_PW_CTRL1   0x04
+#define CTRL1_IP_HOST_PDN  BIT(0)
+
+#define IPPC_IP_PW_STS10x10
+#define STS1_IP_SLEEP_STS  BIT(30)
+#define STS1_U3_MAC_RSTBIT(16)
+#define STS1_XHCI_RST  BIT(11)
+#define STS1_SYS125_RSTBIT(10)
+#define STS1_REF_RST   BIT(8)
+#define STS1_SYSPLL_STABLE BIT(0)
+
+#define IPPC_IP_XHCI_CAP   0x24
+#define CAP_U3_PORT_NUM(p) ((p) & 0xff)
+#define CAP_U2_PORT_NUM(p) (((p) >> 8) & 0xff)
+
+#define IPPC_U3_CTRL_0P0x30
+#define CTRL_U3_PORT_HOST_SEL  BIT(2)
+#define CTRL_U3_PORT_PDN   BIT(1)
+#define CTRL_U3_PORT_DIS   BIT(0)
+
+#define IPPC_U2_CTRL_0P0x50
+#define CTRL_U2_PORT_HOST_SEL  BIT(2)
+#define CTRL_U2_PORT_PDN   BIT(1)
+#define CTRL_U2_PORT_DIS   BIT(0)
+
+#define IPPC_U3_CTRL(p)(IPPC_U3_CTRL_0P + ((p) * 0x08))
+#define IPPC_U2_CTRL(p)(IPPC_U2_CTRL_0P + ((p) * 0x08))
+
+struct mtk_xhci {
+   struct xhci_ctrl ctrl;  /* Needs to come first in this struct! */
+   struct xhci_hccr *hcd;
+   void __iomem *ippc;
+   struct udevice *dev;
+   struct udevice *vusb33_supply;
+   struct udevice *vbus_supply;
+   struct clk_bulk clks;
+   struct phy_bulk phys;
+   int num_u2ports;
+   int num_u3ports;
+};
+
+static int xhci_mtk_host_enable(struct mtk_xhci *mtk)
+{
+   u32 value;
+   u32 check_val;
+   int ret;
+   int i;
+
+   /* power on host ip */
+   clrbits_le32(mtk->ippc + IPPC_IP_PW_CTRL1, CTRL1_IP_HOST_PDN);
+
+   /* power on and enable all u3 ports */
+   for (i = 0; i < mtk->num_u3ports; i++) {
+   clrsetbits_le32(mtk->ippc + IPPC_U3_CTRL(i),
+   CTRL_U3_PORT_PDN | CTRL_U3_PORT_DIS,
+   CTRL_U3_PORT_HOST_SEL);
+   }
+
+   /* power on and enable all u2 ports */
+   for (i = 0; i < mtk->num_u2ports; i++) {
+   clrsetbits_le32(mtk->ippc + IPPC_U2_CTRL(i),
+   CTRL_U2_PORT_PDN | CTRL_U2_PORT_DIS,
+   CTRL_U2_PORT_HOST_SEL);
+   }
+
+   /*
+* wait for clocks to be stable, and clock domains reset to
+* be inactive after power on and enable ports
+*/
+   check_val = STS1_SYSPLL_STABLE | STS1_REF_RST |
+   STS1_SYS125_RST | STS1_XHCI_RST;
+
+   if (mtk->num_u

[PATCH v4 05/13] usb: dwc3: use the phy bulk API to get phys

[Chunfeng Yun]

Get a group of phys by the phy bulk API

Signed-off-by: Chunfeng Yun 
---
v4: new patch
---
 drivers/usb/dwc3/core.c | 83 -
 drivers/usb/dwc3/dwc3-generic.c |  7 ++-
 include/dwc3-uboot.h| 11 ++---
 3 files changed, 17 insertions(+), 84 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 4ec3f6df6a..908cca12b9 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -838,87 +838,22 @@ MODULE_LICENSE("GPL v2");
 MODULE_DESCRIPTION("DesignWare USB3 DRD Controller Driver");
 
 #if CONFIG_IS_ENABLED(PHY) && CONFIG_IS_ENABLED(DM_USB)
-int dwc3_setup_phy(struct udevice *dev, struct phy **array, int *num_phys)
+int dwc3_setup_phy(struct udevice *dev, struct phy_bulk *phys)
 {
-   int i, ret, count;
-   struct phy *usb_phys;
-
-   /* Return if no phy declared */
-   if (!dev_read_prop(dev, "phys", NULL))
-   return 0;
-   count = dev_count_phandle_with_args(dev, "phys", "#phy-cells");
-   if (count <= 0)
-   return count;
-
-   usb_phys = devm_kcalloc(dev, count, sizeof(struct phy),
-   GFP_KERNEL);
-   if (!usb_phys)
-   return -ENOMEM;
-
-   for (i = 0; i < count; i++) {
-   ret = generic_phy_get_by_index(dev, i, &usb_phys[i]);
-   if (ret && ret != -ENOENT) {
-   pr_err("Failed to get USB PHY%d for %s\n",
-  i, dev->name);
-   return ret;
-   }
-   }
-
-   for (i = 0; i < count; i++) {
-   ret = generic_phy_init(&usb_phys[i]);
-   if (ret) {
-   pr_err("Can't init USB PHY%d for %s\n",
-  i, dev->name);
-   goto phys_init_err;
-   }
-   }
+   int ret;
 
-   for (i = 0; i < count; i++) {
-   ret = generic_phy_power_on(&usb_phys[i]);
-   if (ret) {
-   pr_err("Can't power USB PHY%d for %s\n",
-  i, dev->name);
-   goto phys_poweron_err;
-   }
+   ret = generic_phy_get_bulk(dev, phys);
+   if (ret) {
+   dev_err(dev, "Failed to get phys\n");
+   return ret;
}
 
-   *array = usb_phys;
-   *num_phys =  count;
-   return 0;
-
-phys_poweron_err:
-   for (i = count - 1; i >= 0; i--)
-   generic_phy_power_off(&usb_phys[i]);
-
-   for (i = 0; i < count; i++)
-   generic_phy_exit(&usb_phys[i]);
-
-   return ret;
-
-phys_init_err:
-   for (; i >= 0; i--)
-   generic_phy_exit(&usb_phys[i]);
-
-   return ret;
+   return generic_phy_enable_bulk(phys);
 }
 
-int dwc3_shutdown_phy(struct udevice *dev, struct phy *usb_phys, int num_phys)
+int dwc3_shutdown_phy(struct udevice *dev, struct phy_bulk *phys)
 {
-   int i, ret;
-
-   for (i = 0; i < num_phys; i++) {
-   if (!generic_phy_valid(&usb_phys[i]))
-   continue;
-
-   ret = generic_phy_power_off(&usb_phys[i]);
-   ret |= generic_phy_exit(&usb_phys[i]);
-   if (ret) {
-   pr_err("Can't shutdown USB PHY%d for %s\n",
-  i, dev->name);
-   }
-   }
-
-   return 0;
+   return generic_phy_disable_bulk(phys);
 }
 #endif
 
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 3e116b2c5c..523189a5ff 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -33,8 +33,7 @@ struct dwc3_generic_plat {
 struct dwc3_generic_priv {
void *base;
struct dwc3 dwc3;
-   struct phy *phys;
-   int num_phys;
+   struct phy_bulk phys;
 };
 
 struct dwc3_generic_host_priv {
@@ -56,7 +55,7 @@ static int dwc3_generic_probe(struct udevice *dev,
dwc3_of_parse(dwc3);
 #endif
 
-   rc = dwc3_setup_phy(dev, &priv->phys, &priv->num_phys);
+   rc = dwc3_setup_phy(dev, &priv->phys);
if (rc)
return rc;
 
@@ -79,7 +78,7 @@ static int dwc3_generic_remove(struct udevice *dev,
struct dwc3 *dwc3 = &priv->dwc3;
 
dwc3_remove(dwc3);
-   dwc3_shutdown_phy(dev, priv->phys, priv->num_phys);
+   dwc3_shutdown_phy(dev, &priv->phys);
unmap_physmem(dwc3->regs, MAP_NOCACHE);
 
return 0;
diff --git a/include/dwc3-uboot.h b/include/dwc3-uboot.h
index 3c9e204cf0..ce835fd1b2 100644
--- a/include/dwc3-uboot.h
+++ b/include/dwc3-uboot.h
@@ -9,6 +9,7 @@
 #ifndef __DWC3_UBOOT_H_
 #define __DWC3_UBOOT_H_
 
+#include 
 #include 
 #include 
 
@@ -43,17 +44,15 @@ void dwc3_uboot_handle_interrupt(int index);
 
 struct phy;
 #if CONFIG_IS_ENABLED(PHY) && CONFIG_IS_ENABLED(DM_USB)
-int dwc3_setup_phy(struct udevice *dev, struct phy **array, int *num_phys);
-int dwc3_shutdown_phy(struct udevice *dev, struct 

[PATCH v4 00/13] Add support for MediaTek xHCI host controller

[Chunfeng Yun]

The series of patches are used to support xHCI host controller on
MediaTek SoCs which has a glue layer IPPC (IP Port Control), and
add USB function on T-PHY including T-PHY V1 and V2;
Finally add USB related nodes for MT7629 platform.

The files of xhci-mtk.* and phy-mtk-tphy.* are ported from
Linux Kenrel 5.6-rc1

v4 changes:
1. add phy_bulk API
2. use phy_bulk in xhci-mtk driver, also include dwc3/dwc2 drivers

v3 changes:
1. provide non/inline edev_get_child_count() suggested by Simon
2. squash [PATCH v2 02/10] into [PATCH v2 03/10] suggested by Simon
3. use macros to access IPPC registers suggested by Marek

v2 changes:
1. move ofnode_get_child_count() into ofnode.c suggested by Simon
2. add a test item for ofnode_get_child_count() suggested by Simon
3. use clk_bulk to get clocks suggested by Marek
4. use clrsetbits_le32() etc suggeseted by Marek
5. get the count of phys by dev_get_child_count()
6. drop reference to fixed clock clk20m

Chunfeng Yun (13):
  dm: core: Add function to get child count of ofnode or device
  test: dm: add test item for ofnode_get_child_count()
  phy: Add get/enable/disable for a bulk of phys
  test: dm: phy: add a test item for the phy_bulk API
  usb: dwc3: use the phy bulk API to get phys
  usb: dwc2_udc_otg: use the phy bulk API to get phys
  phy: phy-mtk-tphy: add support USB phys
  phy: phy-mtk-tphy: add support new version
  phy: phy-mtk-tphy: add a new reference clock
  xhci: mediatek: Add support for MTK xHCI host controller
  arm: dts: mt7629: add usb related nodes
  dt-bindings: phy-mtk-tphy: add properties of address mapping and
clocks
  dt-bindings: usb: mtk-xhci: Add binding for MediaTek xHCI host
controller

 arch/arm/dts/mt7629-rfb.dts   |   8 +
 arch/arm/dts/mt7629.dtsi  |  41 +++
 arch/sandbox/dts/test.dts |  29 ++
 doc/device-tree-bindings/phy/phy-mtk-tphy.txt |  78 -
 .../usb/mediatek,mtk-xhci.txt |  40 +++
 drivers/core/ofnode.c |  11 +
 drivers/core/read.c   |   5 +
 drivers/phy/phy-mtk-tphy.c| 316 +-
 drivers/phy/phy-uclass.c  |  80 +
 drivers/usb/dwc3/core.c   |  83 +
 drivers/usb/dwc3/dwc3-generic.c   |   7 +-
 drivers/usb/gadget/dwc2_udc_otg.c |  90 +
 drivers/usb/host/Kconfig  |   6 +
 drivers/usb/host/Makefile |   1 +
 drivers/usb/host/xhci-mtk.c   | 297 
 include/dm/ofnode.h   |   8 +
 include/dm/read.h |  13 +
 include/dwc3-uboot.h  |  11 +-
 include/generic-phy.h |  66 
 test/dm/ofnode.c  |  21 ++
 test/dm/phy.c |  29 ++
 21 files changed, 1051 insertions(+), 189 deletions(-)
 create mode 100644 doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt
 create mode 100644 drivers/usb/host/xhci-mtk.c

-- 
2.25.1

[PATCH v4 09/13] phy: phy-mtk-tphy: add a new reference clock

[Chunfeng Yun]

Usually the digital and analog phys use the same reference clock,
but some platforms have two separate reference clocks for each of
them, so add another optional clock to support them.
In order to keep the clock names consistent with PHY IP's, change
the da_ref for analog phy and ref clock for digital phy.

Signed-off-by: Chunfeng Yun 
---
v2~v4: no changes
---
 drivers/phy/phy-mtk-tphy.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/phy-mtk-tphy.c b/drivers/phy/phy-mtk-tphy.c
index 20167fe7cb..81525a48b7 100644
--- a/drivers/phy/phy-mtk-tphy.c
+++ b/drivers/phy/phy-mtk-tphy.c
@@ -199,8 +199,8 @@ struct mtk_phy_instance {
struct u3phy_banks u3_banks;
};
 
-   /* reference clock of anolog phy */
-   struct clk ref_clk;
+   struct clk ref_clk; /* reference clock of (digital) phy */
+   struct clk da_ref_clk;  /* reference clock of analog phy */
u32 index;
u32 type;
 };
@@ -450,8 +450,17 @@ static int mtk_phy_init(struct phy *phy)
int ret;
 
ret = clk_enable(&instance->ref_clk);
-   if (ret)
+   if (ret < 0) {
+   dev_err(tphy->dev, "failed to enable ref_clk\n");
return ret;
+   }
+
+   ret = clk_enable(&instance->da_ref_clk);
+   if (ret < 0) {
+   dev_err(tphy->dev, "failed to enable da_ref_clk %d\n", ret);
+   clk_disable(&instance->ref_clk);
+   return ret;
+   }
 
switch (instance->type) {
case PHY_TYPE_USB2:
@@ -502,6 +511,7 @@ static int mtk_phy_exit(struct phy *phy)
struct mtk_tphy *tphy = dev_get_priv(phy->dev);
struct mtk_phy_instance *instance = tphy->phys[phy->id];
 
+   clk_disable(&instance->da_ref_clk);
clk_disable(&instance->ref_clk);
 
return 0;
@@ -611,6 +621,11 @@ static int mtk_tphy_probe(struct udevice *dev)
 &instance->ref_clk);
if (err)
return err;
+
+   err = clk_get_optional_nodev(subnode, "da_ref",
+&instance->da_ref_clk);
+   if (err)
+   return err;
}
 
return 0;
-- 
2.25.1

[PATCH v4 02/13] test: dm: add test item for ofnode_get_child_count()

[Chunfeng Yun]

Add a test item for ofnode_get_child_count()

Signed-off-by: Chunfeng Yun 
Reviewed-by: Simon Glass 
---
v4: no changes

v3:
1. squash dts patch into this one suggested by Simon
2. add reviewed-by Simon

v2:
a new patch to test ofnode_get_child_count() suggested by Simon
---
 arch/sandbox/dts/test.dts | 18 ++
 test/dm/ofnode.c  | 21 +
 2 files changed, 39 insertions(+)

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 4a277934a7..09e69a9d33 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -202,6 +202,24 @@
compatible = "denx,u-boot-fdt-test1";
};
 
+   i-test {
+   compatible = "mediatek,u-boot-fdt-test";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   subnode0 {
+   reg = <0>;
+   };
+
+   subnode1 {
+   reg = <1>;
+   };
+
+   subnode2 {
+   reg = <2>;
+   };
+   };
+
devres-test {
compatible = "denx,u-boot-devres-test";
};
diff --git a/test/dm/ofnode.c b/test/dm/ofnode.c
index 1c49eaf38b..07d5c7d7a6 100644
--- a/test/dm/ofnode.c
+++ b/test/dm/ofnode.c
@@ -113,3 +113,24 @@ static int dm_test_ofnode_read_chosen(struct 
unit_test_state *uts)
return 0;
 }
 DM_TEST(dm_test_ofnode_read_chosen, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+static int dm_test_ofnode_get_child_count(struct unit_test_state *uts)
+{
+   ofnode node, child_node;
+   u32 val;
+
+   node = ofnode_path("/i-test");
+   ut_assert(ofnode_valid(node));
+
+   val = ofnode_get_child_count(node);
+   ut_asserteq(3, val);
+
+   child_node = ofnode_first_subnode(node);
+   ut_assert(ofnode_valid(child_node));
+   val = ofnode_get_child_count(child_node);
+   ut_asserteq(0, val);
+
+   return 0;
+}
+DM_TEST(dm_test_ofnode_get_child_count,
+   DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
-- 
2.25.1

[PATCH v4 03/13] phy: Add get/enable/disable for a bulk of phys

[Chunfeng Yun]

This patch adds a "bulk" API to the phy API in order to
get/enable/disable a group of phys associated with a device.

The bulk API will avoid adding a copy of the same code to
manage a group of phys in drivers.

Signed-off-by: Chunfeng Yun 
---
v4: new patch
---
 drivers/phy/phy-uclass.c | 80 
 include/generic-phy.h| 66 +
 2 files changed, 146 insertions(+)

diff --git a/drivers/phy/phy-uclass.c b/drivers/phy/phy-uclass.c
index e201a90c8c..62580520ad 100644
--- a/drivers/phy/phy-uclass.c
+++ b/drivers/phy/phy-uclass.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 static inline struct phy_ops *phy_dev_ops(struct udevice *dev)
@@ -161,6 +162,85 @@ int generic_phy_power_off(struct phy *phy)
return ops->power_off ? ops->power_off(phy) : 0;
 }
 
+int generic_phy_get_bulk(struct udevice *dev, struct phy_bulk *bulk)
+{
+   int i, ret, count;
+
+   bulk->count = 0;
+
+   /* Return if no phy declared */
+   if (!dev_read_prop(dev, "phys", NULL))
+   return 0;
+
+   count = dev_count_phandle_with_args(dev, "phys", "#phy-cells");
+   if (count < 1)
+   return count;
+
+   bulk->phys = devm_kcalloc(dev, count, sizeof(struct phy), GFP_KERNEL);
+   if (!bulk->phys)
+   return -ENOMEM;
+
+   for (i = 0; i < count; i++) {
+   ret = generic_phy_get_by_index(dev, i, &bulk->phys[i]);
+   if (ret) {
+   pr_err("Failed to get PHY%d for %s\n", i, dev->name);
+   return ret;
+   }
+   bulk->count++;
+   }
+
+   return 0;
+}
+
+int generic_phy_enable_bulk(struct phy_bulk *bulk)
+{
+   struct phy *phys = bulk->phys;
+   int count = bulk->count;
+   int i, ret;
+
+   for (i = 0; i < count; i++) {
+   ret = generic_phy_init(&phys[i]);
+   if (ret) {
+   pr_err("Can't init PHY%d\n", i);
+   goto phys_init_err;
+   }
+   }
+
+   for (i = 0; i < count; i++) {
+   ret = generic_phy_power_on(&phys[i]);
+   if (ret) {
+   pr_err("Can't power PHY%d\n", i);
+   goto phys_poweron_err;
+   }
+   }
+
+   return 0;
+
+phys_poweron_err:
+   for (; i > 0; i--)
+   generic_phy_power_off(&phys[i - 1]);
+
+   i = count;
+phys_init_err:
+   for (; i > 0; i--)
+   generic_phy_exit(&phys[i - 1]);
+
+   return ret;
+}
+
+int generic_phy_disable_bulk(struct phy_bulk *bulk)
+{
+   struct phy *phys = bulk->phys;
+   int i, ret = 0;
+
+   for (i = 0; i < bulk->count; i++) {
+   ret |= generic_phy_power_off(&phys[i]);
+   ret |= generic_phy_exit(&phys[i]);
+   }
+
+   return ret;
+}
+
 UCLASS_DRIVER(phy) = {
.id = UCLASS_PHY,
.name   = "phy",
diff --git a/include/generic-phy.h b/include/generic-phy.h
index 95caf58341..55395a50eb 100644
--- a/include/generic-phy.h
+++ b/include/generic-phy.h
@@ -122,6 +122,23 @@ struct phy_ops {
int (*power_off)(struct phy *phy);
 };
 
+/**
+ * struct phy_bulk - A handle to (allowing control of) a bulk of phys.
+ *
+ * Consumers provide storage for the phy bulk. The content of the structure is
+ * managed solely by the phy API. A phy bulk struct is initialized
+ * by "get"ing the phy bulk struct.
+ * The phy bulk struct is passed to all other bulk phy APIs to apply
+ * the API to all the phy in the bulk struct.
+ *
+ * @phys: An array of phy handles.
+ * @count: The number of phy handles in the phys array.
+ */
+struct phy_bulk {
+   struct phy *phys;
+   unsigned int count;
+};
+
 #ifdef CONFIG_PHY
 
 /**
@@ -221,6 +238,39 @@ int generic_phy_get_by_index(struct udevice *user, int 
index,
 int generic_phy_get_by_name(struct udevice *user, const char *phy_name,
struct phy *phy);
 
+/**
+ * generic_phy_get_bulk - Get all phys of a device.
+ *
+ * This looks up and gets all phys of the consumer device; each device is
+ * assumed to have n phys associated with it somehow, and this function finds
+ * and gets all of them in a separate structure.
+ *
+ * @dev:   The consumer device.
+ * @bulk   A pointer to a phy bulk struct to initialize.
+ * @return 0 if OK, or a negative error code.
+ */
+int generic_phy_get_bulk(struct udevice *dev, struct phy_bulk *bulk);
+
+/**
+ * generic_phy_enable_bulk() - Enable (init and power on) all phys in a phy
+ * bulk struct.
+ *
+ * @bulk:  A phy bulk struct that was previously successfully requested
+ * by generic_phy_get_bulk().
+ * @return 0 if OK, or negative error code.
+ */
+int generic_phy_enable_bulk(struct phy_bulk *bulk);
+
+/**
+ * generic_phy_disable_bulk() - Enable (power off and exit) all phys in a phy
+ * bulk struct.
+ *
+ 

RE: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96

[Pascal PAILLET-LME]

> -Original Message-
> From: Marek Vasut 
> Sent: jeudi 2 avril 2020 15:07
> To: Pascal PAILLET-LME ; Patrick DELAUNAY
> ; Patrice CHOTARD ; u-
> b...@lists.denx.de
> Cc: Manivannan Sadhasivam ;
> Alexandre TORGUE 
> Subject: Re: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration
> on AV96
> 
> On 4/2/20 2:53 PM, Pascal PAILLET-LME wrote:
> > Hi Marek,
> 
> Hi,
> [...]
> >>>   vdd: buck3 {
> >>>   regulator-name = "vdd";
> >>> - regulator-min-microvolt = <330>;
> >>> - regulator-max-microvolt = <330>;
> >>> + regulator-min-microvolt = <290>;
> >>> + regulator-max-microvolt = <290>;
> >>>   regulator-always-on;
> >>>   st,mask_reset;
> >>>   regulator-initial-mode = <0>; @@ -
> >> 268,6 +279,7 @@
> >>>   regulator-name = "vbus_otg";
> >>>   interrupts = ;
> >>>   interrupt-parent = <&pmic>;
> >>> + regulator-active-discharge = <1>;
> >> It seems this setting introduced other-consumption, it should not be
> >> used.
> > Other-consumption ? What does that mean ?
> 
>  It's a typo, Patrick means over-consumption.
> >>>
> >>> Ah. Do you have any details on that ?
> >>
> >> Sorry for typo.
> >>
> >> No details on my side, it was a Pascal Paillet's direct feedback 
> >> (Maintainer
> of
> >> STPMIC1 driver in Linux).
> > You can enable the active discharge on the STPMIC1's VBUSOTG. But, as
> soon as a USB host peripheral (such as laptop) will attach and provide VBUS,
> there will be a ~8mA continuous power consumption on VBUS through this
> OTG active discharge. There is no functional issue behind this 8mA; but you
> need to know that 8mA is not compliant with the USB suspend constraint
> (2.5mA max).
> 
> So why is it in there ?
Sorry, I'm not sure to catch your point... The property is available because 
the stpmic1
Propose this feature (enable a pull down resistor when VBUS_OTG is disabled). 
We have
Found during some test that it is better to not enable active discharge on 
vbus_otg.
I hope it answers,
pascal

AW: latest u-boot branch for Marvell Armada 88F3720

[Moritz Berghof]

Hey Marek, Hi Stefan,


it's really great that you answered so fast and helpfully, thank you!

It's great you want get the board ported to mainline. Me too. 


I build the U-boot mainline and uploaded on my espressobin. Used the ATF and 
WTMI from Marvell.

When I start the flashed .bin file, the U-boot crashed at this following point. 
"Synchronous Abort" handler, esr 0x96000210 

Prompt is attached at this mail. 

I think there is a problem with the RAM. For example, I build the U-Boot for 1 
GB RAM with the Marvell U-boot and the mainline/master. Important constant is 
DDR_TOPOLOGY=2  

make DEBUG=0 USE_COHERENT_MEM=0 LOG_LEVEL=20 SECURE=0 
CLOCKSPRESET=CPU_1000_DDR_800 DDR_TOPOLOGY=2 WTP=... BOOTDEV=SPINOR PARTNUM=0 
PLAT=a3700 all fip

But when the u-boot mainline starts it promts: U-Boot 
2020.04-rc3-00188-g350c44dfb9 (Mar 31 2020 - 10:52:01 +0200)

DRAM:  512 MiB


The Marvell U-boot promts DRAM: 1 GiB



So my question is, where do you define the RAM Size?

At armada-3720-espressobin.dts i expanded the memory size. No success. 
At mvebu_armada-37xx.h I expand the RAM for two banks. No success.

Or do you see there other problems by starting the mainline? 


Thanks,


--
Moritz Berghof
Software Engineering
Tel. +49 30 921028-209 
Fax +49 30 921028-020
mberg...@phoenixcontact.com
www.phoenixcontact.com
 
PHOENIX CONTACT Cyber Security GmbH
Richard-Willstätter-Straße 6
D-12489 Berlin
Register Court: AG Charlottenburg, HR B 202908
Geschäftsführer/General Manager: Kilian Golm

-Ursprüngliche Nachricht-
Von: Marek Behun  
Gesendet: Mittwoch, 25. März 2020 18:49
An: stefan roese 
Cc: Moritz Berghof ; u-boot mailing list 

Betreff: Re: latest u-boot branch for Marvell Armada 88F3720

***External email! Do not click links or open attachments unless you recognize 
the sender and know the content is safe.***

Hi,

mainline U-Boot should work for Armada 3720, although I haven't tested recent 
master (so I don't know if there are some regressions). But Turris Mox uses cca 
1 year old upstream with just few Mox specific patches atop (which I plan to 
get merged soon). You can find it here:
https://gitlab.labs.nic.cz/turris/mox-u-boot

One thing that may need reworking (to become compatible with Linux) is the 
comphy driver. Linux' comphy driver for this SOC uses smccc calls to ARM 
Trusted Firmware, but U-Boot does not, and instead initializes SERDESes on its 
own.

Bear in mind that U-Boot is not enough for booting Armada 3720 SOC. You do also 
need ARM Trusted Firmware (you don't need to use Marvell's ATF, since their 
patches are merged into upstream ATF), and you also need firmware for the 
secure Cortex-M3 processor (Marvell's name for this firmware is WTMI), which 
does DDR training. Marvell has this in A3700-utils-marvell repository. For 
Turris MOX, we build all of this via 
https://gitlab.labs.nic.cz/turris/mox-boot-builder
but this code can be MOX specific, so if you want to use it for other boards, I 
can provide more explanation of which does what and so on.

Marek

On Wed, 25 Mar 2020 17:44:57 +0100
Stefan Roese  wrote:

> Hi Moritz,
>
> On 25.03.20 16:05, Moritz Berghof wrote:
> > My Name is Moritz and we evaluate the Marvell Armada 88F3720 on the 
> > Marvell ESPRESSObin and the TURRIS MOX.
> >
> > Does someone know, where is the actual or latest u-boot branch for 
> > Marvell Armada 88F3720 placed? At the u-boot master or a marvell 
> > custodian tree or somewhere else? Does Marvell develop u-boot still 
> > for their Armada 88F3720 and when yes, where?
>
> Those boards are supported in general in mainline U-Boot. Though I 
> have to admit, that I didn't test any of those ports recently. I added 
> Marek Behun to Cc, as he did submit most of the Turris Mox stuff and 
> has more recent experience than I do.
>
> > Because that 
> > https://github.com/MarvellEmbeddedProcessors/u-boot-marvell,
> > which is well used on the ESPRESSObin is NOT up-to-date. 4 Years 
> > ago, last commit.
>
> I just took a quick glance at this repo and there are newer, more 
> recent branches, e.g. "u-boot-2018.03-armada-18.12". But still, this 
> is far away from mainline, I agree.
>
> Perhaps someone else (Marek) can comment on the current status of 
> mainline U-Boot on those boards? Is something missing? If yes, it 
> would be great to get it ported to mainline.
>
> Thanks,
> Stefan
>
> > I'm searching an actual u-boot platform for my Chip.
> >
> >
> > I look forward to your reply, thank you very much,
> >
> > --
> > Moritz Berghof
> > Software Engineer
> > Tel. +49 30 921028-209
> > Fax +49 30 921028-020
> > mberg...@phoenixcontact.com
> > www.phoenixcontact.com
> >
> > PHOENIX CONTACT Cyber Security GmbH
> > Richard-Willstätter-Straße 6
> > D-12489 Berlin
> > Register Court: AG Charlottenburg, HR B 202908 
> > Geschäftsführer/General Manager: Kilian Golm
> >
> >
> > 

RE: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96

[Pascal PAILLET-LME]

Hi Marek,


> -Original Message-
> From: Patrick DELAUNAY 
> Sent: mercredi 1 avril 2020 15:52
> To: Marek Vasut ; Patrice CHOTARD
> ; u-boot@lists.denx.de; Pascal PAILLET-LME
> 
> Cc: Manivannan Sadhasivam ;
> Alexandre TORGUE 
> Subject: RE: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on
> AV96
> 
> Hi,
> 
> > From: Marek Vasut 
> > Sent: mercredi 1 avril 2020 14:53
> > To: Patrice CHOTARD ; Patrick DELAUNAY
> > ; u-boot@lists.denx.de; Pascal PAILLET-LME
> > 
> > Cc: Manivannan Sadhasivam ;
> > Alexandre TORGUE 
> > Subject: Re: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC
> > configuration on
> > AV96
> > Importance: High
> >
> > On 4/1/20 2:45 PM, Patrice CHOTARD wrote:
> > >
> > > On 4/1/20 1:06 PM, Marek Vasut wrote:
> > >> On 4/1/20 9:34 AM, Patrick DELAUNAY wrote:
> > >>> Hi Marek and Pascal,
> > >> Hi,
> > >>
> > >> [...]
> [...]
> > vdd: buck3 {
> > regulator-name = "vdd";
> >  -  regulator-min-microvolt = <330>;
> >  -  regulator-max-microvolt = <330>;
> >  +  regulator-min-microvolt = <290>;
> >  +  regulator-max-microvolt = <290>;
> > regulator-always-on;
> > st,mask_reset;
> > regulator-initial-mode = <0>; @@ -
> 268,6 +279,7 @@
> > regulator-name = "vbus_otg";
> > interrupts = ;
> > interrupt-parent = <&pmic>;
> >  +  regulator-active-discharge = <1>;
> > >>> It seems this setting introduced other-consumption, it should not be
> used.
> > >> Other-consumption ? What does that mean ?
> > >
> > > It's a typo, Patrick means over-consumption.
> >
> > Ah. Do you have any details on that ?
> 
> Sorry for typo.
> 
> No details on my side, it was a Pascal Paillet's direct feedback (Maintainer 
> of
> STPMIC1 driver in Linux).
You can enable the active discharge on the STPMIC1's VBUSOTG. But, as soon as a 
USB host peripheral (such as laptop) will attach and provide VBUS, there will 
be a ~8mA continuous power consumption on VBUS through this OTG active 
discharge. There is no functional issue behind this 8mA; but you need to know 
that 8mA is not compliant with the USB suspend constraint (2.5mA max).
> 
> Anyway he will review your patch for Linux, with more details, and I merge
> this patch without modification for U-Boot.
> 
> Patrick

Pascal

Re: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function

[Marek Vasut]

On 4/3/20 12:10 AM, Tom Rini wrote:
> On Thu, Apr 02, 2020 at 11:07:31PM +0200, Marek Vasut wrote:
>> On 4/2/20 10:54 PM, Tom Rini wrote:
>> [...]
>>
 I'm not sure it definitely should be changed. But I'll do a patch and
 see how it looks.
>>>
>>> Do I understand it correctly that the patch
>>> 82de42fa14682d408da935adfb0f935354c5008f actually completely breaks
>>> SoCFPGA ? Then I would say this is a release blocker ?
>> Yes. A10 SPL won't boot at all. It crashes during the clock manager 
>> setup.
>
> This came in right at the beginning of the cycle. I thought the
> purpose of the 3-month cycle was to allow time to test?

 It was ... altera ?
>>>
>>> Sorry, I'm missing how that's an answer to the question.  This came in
>>> basically right at the start of the merge window.
>>
>> I don't have an A10 available right now, so what can I do ?
> 
> Ah, so the answer is "I can't test this platform myself".  That's what
> then, thanks.

Clearly Altera can , since they reported this issue.

Re: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function

[Tom Rini]

On Thu, Apr 02, 2020 at 11:07:31PM +0200, Marek Vasut wrote:
> On 4/2/20 10:54 PM, Tom Rini wrote:
> [...]
> 
> >> I'm not sure it definitely should be changed. But I'll do a patch and
> >> see how it looks.
> >
> > Do I understand it correctly that the patch
> > 82de42fa14682d408da935adfb0f935354c5008f actually completely breaks
> > SoCFPGA ? Then I would say this is a release blocker ?
>  Yes. A10 SPL won't boot at all. It crashes during the clock manager 
>  setup.
> >>>
> >>> This came in right at the beginning of the cycle. I thought the
> >>> purpose of the 3-month cycle was to allow time to test?
> >>
> >> It was ... altera ?
> > 
> > Sorry, I'm missing how that's an answer to the question.  This came in
> > basically right at the start of the merge window.
> 
> I don't have an A10 available right now, so what can I do ?

Ah, so the answer is "I can't test this platform myself".  That's what
then, thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function

[Simon Glass]

Hi Marek,

On Thu, 2 Apr 2020 at 15:07, Marek Vasut  wrote:
>
> On 4/2/20 10:54 PM, Tom Rini wrote:
> [...]
>
> >> I'm not sure it definitely should be changed. But I'll do a patch and
> >> see how it looks.
> >
> > Do I understand it correctly that the patch
> > 82de42fa14682d408da935adfb0f935354c5008f actually completely breaks
> > SoCFPGA ? Then I would say this is a release blocker ?
>  Yes. A10 SPL won't boot at all. It crashes during the clock manager 
>  setup.
> >>>
> >>> This came in right at the beginning of the cycle. I thought the
> >>> purpose of the 3-month cycle was to allow time to test?
> >>
> >> It was ... altera ?
> >
> > Sorry, I'm missing how that's an answer to the question.  This came in
> > basically right at the start of the merge window.
>
> I don't have an A10 available right now, so what can I do ?
>
> >>> I do plan to try out changing the behaviour to read a parent's ofdata
> >>> before the child, but I am not comfortable adding such a major change
> >>> just before a release. It could have any number of ill effects.
> >>>
> >>> Can you update the clock driver? E.g. you could move some of the code
> >>> from socfpga_a10_ofdata_to_platdata() to a probe() method?
> >>
> >> Can we revert the patch which broke arria10 instead ? It did work
> >> before, so who knows how many other ill side effects there are ...
> >
> > I'm not in favor of reverting 82de42fa1468 unless the answer is "that
> > commit was wrong" and not "that commit caused other problems to surface,
> > that we can fix".  I am quite willing to say "we need to delay the
> > release to test changes for problems that've surfaced and verify more
> > hardware is fine".
>
> If I understand this correctly, the clock code did scan the DT and bound
> all the clocks, so that drivers can use them. That's how bind function
> should work, it creates instances of devices, but without probing them.
> This doesn't work anymore if I understand it correctly, but that means
> the basic premise of DT is broken ? And the solution is to do more magic
> in probe function , which I don't think even works here ?

No...please see here from the cover letter:

Cover-letter:
dm: core: Fully separate ofdata_to_platdata() from probe()
At present ofdata_to_platdata() is done as part of device_probe(). Drivers
are supposed to read their platdata in the ofdata_to_platdata method() but
this requirement is not always followed.

Having these methods separate helps deal with of-platdata, where the
probe() method is common to both DT/of-platdata operation, but the
ofdata_to_platdata() method is implemented differently.

Another case has come up where this separate is useful. Generation of ACPI
tables uses the of-platdata but does not want to probe the device. Probing
would cause U-Boot to violate one of its design principles, viz that it
should only probe devices that are used. For ACPI we want to generate a
table for each device, even if U-Boot does not use it. In fact it may not
even be possible to probe the device - e.g. an SD card which is not
present will cause an error on probe, yet we still must tell Linux about
the SD card connector in case it is used while Linux is running.

This series splits out the ofdata_to_platdata() part of device_probe() so
that it can be used separately from device_probe(). Thus devices now go
through two distinct states when probing: reading platform data and
actually touching the hardware to bring the device up.

This should not break existing boards since the operations still happen in
mostly the same order. The main change is that parents and uclasses are
probed after ofdata_to_platdata() is called.

HOWEVER it is quite possible that some boards break the rules and due to
a series of unfortunate events, something will break. Two boards were
found in this category already. SO this series may require some tidying up
from board maintainers, if problems arise.

Note that there are cases where devices must be probed in the
ofdata_to_platdata() method. An example is where a GPIO is selected - this
obviously requires that the GPIO device is probed.

One board was found to burst its size limit with this series, despite the
very small size increase. The patches to remove use of BUG_ON() are to
ensure that this series passes tests.
END


Regards,
Simon

Re: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function

[Marek Vasut]

On 4/2/20 10:54 PM, Tom Rini wrote:
[...]

>> I'm not sure it definitely should be changed. But I'll do a patch and
>> see how it looks.
>
> Do I understand it correctly that the patch
> 82de42fa14682d408da935adfb0f935354c5008f actually completely breaks
> SoCFPGA ? Then I would say this is a release blocker ?
 Yes. A10 SPL won't boot at all. It crashes during the clock manager setup.
>>>
>>> This came in right at the beginning of the cycle. I thought the
>>> purpose of the 3-month cycle was to allow time to test?
>>
>> It was ... altera ?
> 
> Sorry, I'm missing how that's an answer to the question.  This came in
> basically right at the start of the merge window.

I don't have an A10 available right now, so what can I do ?

>>> I do plan to try out changing the behaviour to read a parent's ofdata
>>> before the child, but I am not comfortable adding such a major change
>>> just before a release. It could have any number of ill effects.
>>>
>>> Can you update the clock driver? E.g. you could move some of the code
>>> from socfpga_a10_ofdata_to_platdata() to a probe() method?
>>
>> Can we revert the patch which broke arria10 instead ? It did work
>> before, so who knows how many other ill side effects there are ...
> 
> I'm not in favor of reverting 82de42fa1468 unless the answer is "that
> commit was wrong" and not "that commit caused other problems to surface,
> that we can fix".  I am quite willing to say "we need to delay the
> release to test changes for problems that've surfaced and verify more
> hardware is fine".

If I understand this correctly, the clock code did scan the DT and bound
all the clocks, so that drivers can use them. That's how bind function
should work, it creates instances of devices, but without probing them.
This doesn't work anymore if I understand it correctly, but that means
the basic premise of DT is broken ? And the solution is to do more magic
in probe function , which I don't think even works here ?

Re: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function

[Tom Rini]

On Thu, Apr 02, 2020 at 09:45:25PM +0200, Marek Vasut wrote:
> On 4/2/20 8:50 PM, Simon Glass wrote:
> > Hi.
> 
> Hi,
> 
> [...]
> 
>  I suspect we could change this, so that
>  device_ofdata_to_platdata() first calls itself on its parent.
> 
>  I can think of various reasons why this change might be desirable.
> >>>
> >>> I think this is how it worked before already.
> >>
> >> Well effectively, yes, because ofdata and probe were joined together.
> 
> > Simon, do you have plan to fix this DM core issue ?
> 
>  I'm not sure it definitely should be changed. But I'll do a patch and
>  see how it looks.
> >>>
> >>> Do I understand it correctly that the patch
> >>> 82de42fa14682d408da935adfb0f935354c5008f actually completely breaks
> >>> SoCFPGA ? Then I would say this is a release blocker ?
> >> Yes. A10 SPL won't boot at all. It crashes during the clock manager setup.
> > 
> > This came in right at the beginning of the cycle. I thought the
> > purpose of the 3-month cycle was to allow time to test?
> 
> It was ... altera ?

Sorry, I'm missing how that's an answer to the question.  This came in
basically right at the start of the merge window.

> > I do plan to try out changing the behaviour to read a parent's ofdata
> > before the child, but I am not comfortable adding such a major change
> > just before a release. It could have any number of ill effects.
> > 
> > Can you update the clock driver? E.g. you could move some of the code
> > from socfpga_a10_ofdata_to_platdata() to a probe() method?
> 
> Can we revert the patch which broke arria10 instead ? It did work
> before, so who knows how many other ill side effects there are ...

I'm not in favor of reverting 82de42fa1468 unless the answer is "that
commit was wrong" and not "that commit caused other problems to surface,
that we can fix".  I am quite willing to say "we need to delay the
release to test changes for problems that've surfaced and verify more
hardware is fine".

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function

[Simon Goldschmidt]

On 02.04.2020 21:54, Marek Vasut wrote:

On 4/2/20 9:53 PM, Simon Goldschmidt wrote:



On 02.04.2020 21:49, Simon Glass wrote:

Hi Marek,

On Thu, 2 Apr 2020 at 13:45, Marek Vasut  wrote:


On 4/2/20 8:50 PM, Simon Glass wrote:

Hi.


Hi,

[...]


I suspect we could change this, so that
device_ofdata_to_platdata() first calls itself on its parent.

I can think of various reasons why this change might be
desirable.


I think this is how it worked before already.


Well effectively, yes, because ofdata and probe were joined
together.



Simon, do you have plan to fix this DM core issue ?


I'm not sure it definitely should be changed. But I'll do a patch
and
see how it looks.


Do I understand it correctly that the patch
82de42fa14682d408da935adfb0f935354c5008f actually completely breaks
SoCFPGA ? Then I would say this is a release blocker ?

Yes. A10 SPL won't boot at all. It crashes during the clock manager
setup.


This came in right at the beginning of the cycle. I thought the
purpose of the 3-month cycle was to allow time to test?


It was ... altera ?


I do plan to try out changing the behaviour to read a parent's ofdata
before the child, but I am not comfortable adding such a major change
just before a release. It could have any number of ill effects.

Can you update the clock driver? E.g. you could move some of the code
from socfpga_a10_ofdata_to_platdata() to a probe() method?


Can we revert the patch which broke arria10 instead ? It did work
before, so who knows how many other ill side effects there are ...


No, sorry, we need to fix Altera. Other boards have fixed driver bugs
exposed by the patch.

BTW what is a good Altera board to get that doesn't cost too much?


A problem here might be that you'd need to have a gen5, an A10 and a
stratix board to find all problems...


And agilex too ...


Hmm, I thought we would try and keep stratix and agilex more close than 
gen5/A10...


I even don't have any non-gen5 boards myself here, so I cannot even test 
those, either.


But in the end, yes, it would be a good thing to have all those boards 
execute basic tests at least after rc1 has been tagged. I wonder if 
OSADL could help out here, given they already have a broad range of 
boards testing linux-rt already. Or do we have a separate hardware area 
for this?


Regards,
Simon

Re: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function

[Simon Glass]

Any links to one?

- Simon

On Thu, 2 Apr 2020 at 13:54, Marek Vasut  wrote:
>
> On 4/2/20 9:53 PM, Simon Goldschmidt wrote:
> >
> >
> > On 02.04.2020 21:49, Simon Glass wrote:
> >> Hi Marek,
> >>
> >> On Thu, 2 Apr 2020 at 13:45, Marek Vasut  wrote:
> >>>
> >>> On 4/2/20 8:50 PM, Simon Glass wrote:
>  Hi.
> >>>
> >>> Hi,
> >>>
> >>> [...]
> >>>
> >>> I suspect we could change this, so that
> >>> device_ofdata_to_platdata() first calls itself on its parent.
> >>>
> >>> I can think of various reasons why this change might be
> >>> desirable.
> >>
> >> I think this is how it worked before already.
> >
> > Well effectively, yes, because ofdata and probe were joined
> > together.
> >>>
>  Simon, do you have plan to fix this DM core issue ?
> >>>
> >>> I'm not sure it definitely should be changed. But I'll do a patch
> >>> and
> >>> see how it looks.
> >>
> >> Do I understand it correctly that the patch
> >> 82de42fa14682d408da935adfb0f935354c5008f actually completely breaks
> >> SoCFPGA ? Then I would say this is a release blocker ?
> > Yes. A10 SPL won't boot at all. It crashes during the clock manager
> > setup.
> 
>  This came in right at the beginning of the cycle. I thought the
>  purpose of the 3-month cycle was to allow time to test?
> >>>
> >>> It was ... altera ?
> >>>
>  I do plan to try out changing the behaviour to read a parent's ofdata
>  before the child, but I am not comfortable adding such a major change
>  just before a release. It could have any number of ill effects.
> 
>  Can you update the clock driver? E.g. you could move some of the code
>  from socfpga_a10_ofdata_to_platdata() to a probe() method?
> >>>
> >>> Can we revert the patch which broke arria10 instead ? It did work
> >>> before, so who knows how many other ill side effects there are ...
> >>
> >> No, sorry, we need to fix Altera. Other boards have fixed driver bugs
> >> exposed by the patch.
> >>
> >> BTW what is a good Altera board to get that doesn't cost too much?
> >
> > A problem here might be that you'd need to have a gen5, an A10 and a
> > stratix board to find all problems...
>
> And agilex too ...

Re: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function

[Marek Vasut]

On 4/2/20 9:53 PM, Simon Goldschmidt wrote:
> 
> 
> On 02.04.2020 21:49, Simon Glass wrote:
>> Hi Marek,
>>
>> On Thu, 2 Apr 2020 at 13:45, Marek Vasut  wrote:
>>>
>>> On 4/2/20 8:50 PM, Simon Glass wrote:
 Hi.
>>>
>>> Hi,
>>>
>>> [...]
>>>
>>> I suspect we could change this, so that
>>> device_ofdata_to_platdata() first calls itself on its parent.
>>>
>>> I can think of various reasons why this change might be
>>> desirable.
>>
>> I think this is how it worked before already.
>
> Well effectively, yes, because ofdata and probe were joined
> together.
>>>
 Simon, do you have plan to fix this DM core issue ?
>>>
>>> I'm not sure it definitely should be changed. But I'll do a patch
>>> and
>>> see how it looks.
>>
>> Do I understand it correctly that the patch
>> 82de42fa14682d408da935adfb0f935354c5008f actually completely breaks
>> SoCFPGA ? Then I would say this is a release blocker ?
> Yes. A10 SPL won't boot at all. It crashes during the clock manager
> setup.

 This came in right at the beginning of the cycle. I thought the
 purpose of the 3-month cycle was to allow time to test?
>>>
>>> It was ... altera ?
>>>
 I do plan to try out changing the behaviour to read a parent's ofdata
 before the child, but I am not comfortable adding such a major change
 just before a release. It could have any number of ill effects.

 Can you update the clock driver? E.g. you could move some of the code
 from socfpga_a10_ofdata_to_platdata() to a probe() method?
>>>
>>> Can we revert the patch which broke arria10 instead ? It did work
>>> before, so who knows how many other ill side effects there are ...
>>
>> No, sorry, we need to fix Altera. Other boards have fixed driver bugs
>> exposed by the patch.
>>
>> BTW what is a good Altera board to get that doesn't cost too much?
> 
> A problem here might be that you'd need to have a gen5, an A10 and a
> stratix board to find all problems...

And agilex too ...

Re: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function

[Simon Goldschmidt]

On 02.04.2020 21:49, Simon Glass wrote:

Hi Marek,

On Thu, 2 Apr 2020 at 13:45, Marek Vasut  wrote:


On 4/2/20 8:50 PM, Simon Glass wrote:

Hi.


Hi,

[...]


I suspect we could change this, so that
device_ofdata_to_platdata() first calls itself on its parent.

I can think of various reasons why this change might be desirable.


I think this is how it worked before already.


Well effectively, yes, because ofdata and probe were joined together.



Simon, do you have plan to fix this DM core issue ?


I'm not sure it definitely should be changed. But I'll do a patch and
see how it looks.


Do I understand it correctly that the patch
82de42fa14682d408da935adfb0f935354c5008f actually completely breaks
SoCFPGA ? Then I would say this is a release blocker ?

Yes. A10 SPL won't boot at all. It crashes during the clock manager setup.


This came in right at the beginning of the cycle. I thought the
purpose of the 3-month cycle was to allow time to test?


It was ... altera ?


I do plan to try out changing the behaviour to read a parent's ofdata
before the child, but I am not comfortable adding such a major change
just before a release. It could have any number of ill effects.

Can you update the clock driver? E.g. you could move some of the code
from socfpga_a10_ofdata_to_platdata() to a probe() method?


Can we revert the patch which broke arria10 instead ? It did work
before, so who knows how many other ill side effects there are ...


No, sorry, we need to fix Altera. Other boards have fixed driver bugs
exposed by the patch.

BTW what is a good Altera board to get that doesn't cost too much?


A problem here might be that you'd need to have a gen5, an A10 and a 
stratix board to find all problems...


Regards,
Simon


Regards,
Simon

Re: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function

[Marek Vasut]

On 4/2/20 9:49 PM, Simon Glass wrote:
> Hi Marek,
> 
> On Thu, 2 Apr 2020 at 13:45, Marek Vasut  wrote:
>>
>> On 4/2/20 8:50 PM, Simon Glass wrote:
>>> Hi.
>>
>> Hi,
>>
>> [...]
>>
>> I suspect we could change this, so that
>> device_ofdata_to_platdata() first calls itself on its parent.
>>
>> I can think of various reasons why this change might be desirable.
>
> I think this is how it worked before already.

 Well effectively, yes, because ofdata and probe were joined together.
>>
>>> Simon, do you have plan to fix this DM core issue ?
>>
>> I'm not sure it definitely should be changed. But I'll do a patch and
>> see how it looks.
>
> Do I understand it correctly that the patch
> 82de42fa14682d408da935adfb0f935354c5008f actually completely breaks
> SoCFPGA ? Then I would say this is a release blocker ?
 Yes. A10 SPL won't boot at all. It crashes during the clock manager setup.
>>>
>>> This came in right at the beginning of the cycle. I thought the
>>> purpose of the 3-month cycle was to allow time to test?
>>
>> It was ... altera ?
>>
>>> I do plan to try out changing the behaviour to read a parent's ofdata
>>> before the child, but I am not comfortable adding such a major change
>>> just before a release. It could have any number of ill effects.
>>>
>>> Can you update the clock driver? E.g. you could move some of the code
>>> from socfpga_a10_ofdata_to_platdata() to a probe() method?
>>
>> Can we revert the patch which broke arria10 instead ? It did work
>> before, so who knows how many other ill side effects there are ...
> 
> No, sorry, we need to fix Altera. Other boards have fixed driver bugs
> exposed by the patch.

How is altera broken again ? It used to work fine.

> BTW what is a good Altera board to get that doesn't cost too much?

With arria10 ? I think there's only one, the a10 socdk ...

Re: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function

[Simon Glass]

Hi Marek,

On Thu, 2 Apr 2020 at 13:45, Marek Vasut  wrote:
>
> On 4/2/20 8:50 PM, Simon Glass wrote:
> > Hi.
>
> Hi,
>
> [...]
>
>  I suspect we could change this, so that
>  device_ofdata_to_platdata() first calls itself on its parent.
> 
>  I can think of various reasons why this change might be desirable.
> >>>
> >>> I think this is how it worked before already.
> >>
> >> Well effectively, yes, because ofdata and probe were joined together.
> 
> > Simon, do you have plan to fix this DM core issue ?
> 
>  I'm not sure it definitely should be changed. But I'll do a patch and
>  see how it looks.
> >>>
> >>> Do I understand it correctly that the patch
> >>> 82de42fa14682d408da935adfb0f935354c5008f actually completely breaks
> >>> SoCFPGA ? Then I would say this is a release blocker ?
> >> Yes. A10 SPL won't boot at all. It crashes during the clock manager setup.
> >
> > This came in right at the beginning of the cycle. I thought the
> > purpose of the 3-month cycle was to allow time to test?
>
> It was ... altera ?
>
> > I do plan to try out changing the behaviour to read a parent's ofdata
> > before the child, but I am not comfortable adding such a major change
> > just before a release. It could have any number of ill effects.
> >
> > Can you update the clock driver? E.g. you could move some of the code
> > from socfpga_a10_ofdata_to_platdata() to a probe() method?
>
> Can we revert the patch which broke arria10 instead ? It did work
> before, so who knows how many other ill side effects there are ...

No, sorry, we need to fix Altera. Other boards have fixed driver bugs
exposed by the patch.

BTW what is a good Altera board to get that doesn't cost too much?

Regards,
Simon

Re: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function

[Marek Vasut]

On 4/2/20 8:50 PM, Simon Glass wrote:
> Hi.

Hi,

[...]

 I suspect we could change this, so that
 device_ofdata_to_platdata() first calls itself on its parent.

 I can think of various reasons why this change might be desirable.
>>>
>>> I think this is how it worked before already.
>>
>> Well effectively, yes, because ofdata and probe were joined together.

> Simon, do you have plan to fix this DM core issue ?

 I'm not sure it definitely should be changed. But I'll do a patch and
 see how it looks.
>>>
>>> Do I understand it correctly that the patch
>>> 82de42fa14682d408da935adfb0f935354c5008f actually completely breaks
>>> SoCFPGA ? Then I would say this is a release blocker ?
>> Yes. A10 SPL won't boot at all. It crashes during the clock manager setup.
> 
> This came in right at the beginning of the cycle. I thought the
> purpose of the 3-month cycle was to allow time to test?

It was ... altera ?

> I do plan to try out changing the behaviour to read a parent's ofdata
> before the child, but I am not comfortable adding such a major change
> just before a release. It could have any number of ill effects.
> 
> Can you update the clock driver? E.g. you could move some of the code
> from socfpga_a10_ofdata_to_platdata() to a probe() method?

Can we revert the patch which broke arria10 instead ? It did work
before, so who knows how many other ill side effects there are ...

-- 
Best regards,
Marek Vasut

i.MX8QXP hangs in SPL after a "reboot" command

[Fabio Estevam]

Hi,

Does anyone managed to successfully run a "reboot" command on i.MX8QXP
with a mainline kernel? I see a hang in SPL on a imx8qxp-mek board:

# reboot
# Stopping network: OK
Saving random seed: [6.305029] random: dd: uninitialized urandom
read (512 bytes read)
OK
Stopping klogd: OK
Stopping syslogd: OK
umount: devtmpfs busy - remounted read-only
[6.352820] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
The system is going down NOW!
Sent SIGTERM to all processes
Se[8.362121] kvm: exiting hardware virtualization
[8.397849] reboot: Restarting system

U-Boot SPL 2020.04-rc4-00061-ge0718b3ab7 (Apr 02 2020 - 16:14:22 -0300)
Normal Boot
WDT:   Not found!
Trying to boot from MMC2_2
spl: mmc init failed with error: -70
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

Any suggestions?

Thanks,

Fabio Estevam

Re: [PATCH v2 1/2] serial: ns16550: Revert "Move PCI access from ofdata_to_platdata() to probe()"

[Andy Shevchenko]

On Thu, Apr 2, 2020 at 7:55 AM Bin Meng  wrote:
> On Thu, Apr 2, 2020 at 1:55 AM Simon Glass  wrote:
> > On Wed, 1 Apr 2020 at 11:39, Andy Shevchenko  
> > wrote:
> > > On Wed, Apr 01, 2020 at 10:56:26AM -0600, Simon Glass wrote:
> > > > On Wed, 1 Apr 2020 at 08:45, Andy Shevchenko 
> > > >  wrote:
> > > > > On Wed, Apr 1, 2020 at 5:32 PM Bin Meng  wrote:
> > > > > > On Wed, Apr 1, 2020 at 9:58 PM Andy Shevchenko
> > > > > >  wrote:
> > > > > > >
> > > > > > > The commit breaks serial console on the Intel Edison.
> > > > > > >
> > > > > > > This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c.
> > > > > > >
> > > > > > > Signed-off-by: Andy Shevchenko 
> > > > > > > ---
> > > > > > >  drivers/serial/ns16550.c | 40 
> > > > > > > 
> > > > > > >  1 file changed, 12 insertions(+), 28 deletions(-)
> > > > > > >
> > > > > >
> > > > > > Could you please spend some time to investigate why this breaks 
> > > > > > Intel Edison?
> > > > > >
> > > > > > Reverting this patch would mean we break other boards too as
> > > > > > Wolfgang's patch wanted to fix the breakage in the first place. Much
> > > > > > appreciated!
> > > > >
> > > > > I guess I'm wrong person here. The DM code is a complete black box to 
> > > > > me.
> > > > > Nevertheless, I may test any provided fix / debug / etc patch by 
> > > > > request.
> > > > >
> > > > > And I think it's fair to investigate by the one who made a regression
> > > > > in the first place.
> > > >
> > > > Given that we have conflicting breakages, we need to debug Edison.
> > >
> > > I would glad to test any suggested change or debug patch!
> > >
> > > > Does it enable the debug UART?
> > >
> > > If I am not mistaken, it does not.
> >
> > Looks like you are right. If you know the address you could do that -
> > see minnowmax for an example.
>
> Please suggest what's the best approach to proceed.

I think I understand what happened, and Wolfgang's patch *is* a culprit.

In serial_intel_mid.c we setup a divisor before probing the actual
device. Now, since the address retrieving has been moved further in
the initialization, we are writing to unknown registers and thus don't
properly initialize hardware.

So, the proper fix would be in my opinion to introduce a call back or
some other way to make ordering possible, like registering hw_init
callback in probe which will be called in the ns16550, or even do this
as a callback for all serial class drivers.

I don't dare to dive into this anticipating that crap will hit the fan.
So, please, who is knowing serial code, fix this asap!

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/3] dm: core: support reading a single indexed u32 value

[Simon Glass]

Hi Dario,

On Wed, 1 Apr 2020 at 13:43,  wrote:
>
> Do you think it would make sense to add indexed access also for the s32, u32u 
> and u64 types or at least some of those ?
>

I really don't know. I suspect it would be used at some point.

Regards,
Simon

> Thanks and regards
> Dario Binacchi
>
> > Il 31 marzo 2020 alle 1.57 Simon Glass  ha scritto:
> >
> >
> > On Sun, 29 Mar 2020 at 10:05, Dario Binacchi  wrote:
> > >
> > > The patch adds helper functions to allow reading a single indexed u32
> > > value from a device-tree property containing multiple u32 values, that
> > > is an array of integers.
> > >
> > > Signed-off-by: Dario Binacchi 
> > > ---
> > >
> > >  arch/sandbox/dts/test.dts |  1 +
> > >  drivers/core/of_access.c  | 22 +
> > >  drivers/core/ofnode.c | 40 +++
> > >  drivers/core/read.c   | 13 +
> > >  include/dm/of_access.h| 19 +++
> > >  include/dm/ofnode.h   | 25 
> > >  include/dm/read.h | 40 +++
> > >  test/dm/test-fdt.c| 29 
> > >  8 files changed, 189 insertions(+)
> > >
> >
> > Reviewed-by: Simon Glass 
> >
> > Very nice

Re: [PATCH 3/3] dm: core: refactor functions reading an u32 from dt

[Simon Glass]

Hi Dario,

On Wed, 1 Apr 2020 at 13:34,  wrote:
>
>
> > Il 31 marzo 2020 alle 1.57 Simon Glass  ha scritto:
> >
> >
> > On Sun, 29 Mar 2020 at 10:05, Dario Binacchi  wrote:
> > >
> > > Now reading a 32 bit value from a device-tree property can be expressed
> > > as reading the first element of an array with a single value.
> > >
> > > Signed-off-by: Dario Binacchi 
> > >
> > > ---
> > >
> > >  drivers/core/of_access.c | 16 +---
> > >  drivers/core/ofnode.c| 23 ++-
> > >  2 files changed, 3 insertions(+), 36 deletions(-)
> >
> > Reviewed-by: Simon Glass 
> >
> > Can you please check the code-size delta in SPL on a suitable board?
>
> I have a black beaglebone available (am335x_evm_defconfig).
>
> u-boot-spl.map generated without applying the refactoring patch
> 
>  .text.ofnode_read_u32
> 0x   0x2e drivers/built-in.o
>  .text.ofnode_read_u32_index
> 0x   0x38 drivers/built-in.o
>  .text.ofnode_read_u32_default
> 0x   0x12 drivers/built-in.o
>
> u-boot-spl.map genarated with the refactoring patch applied
> 
>  .text.ofnode_read_u32_index
> 0x   0x38 drivers/built-in.o
>  .text.ofnode_read_u32
> 0x0x8 drivers/built-in.o
>  .text.ofnode_read_u32_default
> 0x   0x14 drivers/built-in.o

Possibly, but a better test is to build your branch with the patch in:

buildman -b  

Then check the size:

buildman -b  -sS

or function detail:

buildman -b  -sSB

That will give us a true picture for SPL. It will show incremental
size increase with your patch.

See buildman docs for more info.

Regards,
Simon

Re: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function

[Simon Glass]

Hi.

On Wed, 1 Apr 2020 at 20:44, Ang, Chee Hong  wrote:
>
> > On 4/2/20 4:34 AM, Simon Glass wrote:
> > > Hi,
> > >
> > > On Tue, 31 Mar 2020 at 20:33, Ang, Chee Hong 
> > wrote:
> > >>
> > >>> Hi Marek,
> > >>>
> > >>> On Wed, 11 Mar 2020 at 05:55, Marek Vasut  wrote:
> > 
> >  On 3/11/20 12:50 PM, Simon Glass wrote:
> > > Hi,
> > 
> >  Hi,
> > 
> > > On Mon, 9 Mar 2020 at 02:22,  wrote:
> > >>
> > >> From: Chee Hong Ang 
> > >>
> > >> This commit (82de42fa14682d408da935adfb0f935354c5008f) calls
> > >> child's
> > >> ofdata_to_platdata() method before the parent is probed in dm core.
> > >> This has caused the driver no longer able to get the correct
> > >> parent clock's register base in the ofdata_to_platdata() method
> > >> because the parent clocks will only be probed after the child's
> > ofdata_to_platdata().
> > >> To resolve this, the clock parent's register base will only be
> > >> retrieved by the child in probe() method instead of 
> > >> ofdata_to_platdata().
> > >
> > > I think one thing that is going on here is that DM allows ofdata
> > > to be read for a device before its parent devices have been read,
> > > but it requires that parent devices be probed before their children.
> > 
> >  This seems wrong. The clock driver should be able to instantiate
> >  devices and read their ofdata without probing them. That is one of
> >  the core design principles of the DM.
> > >>>
> > >>> That's a different question. Yes you can read ofdata without probing a
> > device.
> > >>> That's why we have two methods.
> > >>>
> > >>> The point I am making is that at present there is no requirement
> > >>> that a parent's ofdata be read before a child's ofdata is read. But
> > >>> there is a requirement that a parent be probed before a child is probed.
> > >>>
> > 
> > > The idea is that it should be possible to read the ofdata for a
> > > node without needing to have done so for parents. But perhaps this
> > > assumption is too brave?
> > 
> >  Why is it brave ? That's how it always was, the DT is already
> >  there, so why wouldn't you be able to read it.
> > >>>
> > >>> That was my thinking too. But we are finding in a few situations
> > >>> that the child's ofdata depends on the parent's. For example, the
> > >>> parent may have a base address, or a range mapping, or something
> > >>> else that is needed for the child to correctly get its base address, 
> > >>> etc.
> > >>>
> > 
> > > I suspect we could change this, so that
> > > device_ofdata_to_platdata() first calls itself on its parent.
> > >
> > > I can think of various reasons why this change might be desirable.
> > 
> >  I think this is how it worked before already.
> > >>>
> > >>> Well effectively, yes, because ofdata and probe were joined together.
> > >
> > >> Simon, do you have plan to fix this DM core issue ?
> > >
> > > I'm not sure it definitely should be changed. But I'll do a patch and
> > > see how it looks.
> >
> > Do I understand it correctly that the patch
> > 82de42fa14682d408da935adfb0f935354c5008f actually completely breaks
> > SoCFPGA ? Then I would say this is a release blocker ?
> Yes. A10 SPL won't boot at all. It crashes during the clock manager setup.

This came in right at the beginning of the cycle. I thought the
purpose of the 3-month cycle was to allow time to test?

I do plan to try out changing the behaviour to read a parent's ofdata
before the child, but I am not comfortable adding such a major change
just before a release. It could have any number of ill effects.

Can you update the clock driver? E.g. you could move some of the code
from socfpga_a10_ofdata_to_platdata() to a probe() method?

Regards,
Simon

Re: U-Boot is broken on real N900 HW

[Pali Rohár]

On Wednesday 01 April 2020 12:32:29 Merlijn Wajer wrote:
> Hi,
> 
> On 01/04/2020 00:42, Pali Rohár wrote:
> > On Wednesday 01 April 2020 00:35:07 Pali Rohár wrote:
> >> This patch series contain fixes for Nokia RX-51 board (aka N900).
> >> After these changes it is possible to run U-Boot in qemu emulator again.
> >> And U-Boot can boot kernel image from RAM, eMMC or OneNAND memory without
> >> problem.
> > 
> > But on real Nokia N900 device is U-Boot crashing in reboot loop.
> > 
> > I do not have serial console for Nokia N900 to debug this issue, but
> > seems that it is related to OMAP I2C and OMAP HS MMC code. Problem is
> > that there is no crash and even no error in qemu emulator so I cannot
> > debug this issue.
> > 
> > First problem is around /* reset lp5523 led */ code in rx51.c. On real
> > N900 device it generates repeating messages:
> > 
> >   Check if pads/pull-ups of bus are properly configured
> >   Timed out in wait_for_event: status=
> > 
> > When I commented that few lines all these messages disappeared. So
> > problem is with OMAP I2C.
> > 
> > Second problem happen after misc_init_r() function finishes. U-Boot just
> > prints on N900 screen message "data abort" and reboots. As I do not have
> > serial console it is hard to debug. but I figured out that problem is in
> > mmc_set_ios() function in mmc.c file. In function mmc_set_clock() I put
> > debug info prior to mmc_set_ios() call and after it, and debug info
> > prior was printed, not after.
> > 
> > I remember that somebody had serial jig for Nokia N900, could somebody
> > look at this reboot loop problem?
> > 
> > And any idea how should be OMAP I2C configured in U-Boot to correctly
> > work?
> > 
> > Maybe I will try to find some time to git bisect which change broke
> > U-Boot on real N900 hardware.
> 
> Took latest u-boot master, applied patches and this is the result on
> serial (first part is NOLO booting, I think that can be ignored) [1].

...

> U-Boot 2020.04-rc4-00033-g7dbafe0634-dirty (Apr 01 2020 - 12:15:47 +0200)
> 
> OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> Nokia RX-51 + LPDDR/OneNAND
> I2C:   ready
> DRAM:  256 MiB
> NAND:  0 Bytes

Looks like that something with NAND is broken.

> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> In:vga
> Out:   vga
> Err:   vga
> Timed out in wait_for_event: status=0100
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> Timed out in wait_for_event: status=
> Check if pads/pull-ups of bus are properly configured
> i2c_read (addr phase): pads on bus probably not configured (status=0x10)
> i2c_write: timed out writig last byte!

These i2c errors are caused by

/* reset lp5523 led */
i2c_set_bus_num(1);
state = 0xff;
i2c_write(0x32, 0x3d, 1, &state, 1);
i2c_set_bus_num(0);

Is there anything which needs to be done to initialize i2c bus 1?
Because this code is working fine on older U-Boot version.

Was something changed to OMAP i2c bus code in U-Boot?

> OMAP die ID: 0314002404036ac10b01100f
> OMAP3530-HS ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
> 

And then U-Boot freeze, right?

Any idea how to debug this issue?

On my N900 I'm getting "data abort" error on display and then instant
reboot.

Re: [PATCH v2 1/2] serial: ns16550: Revert "Move PCI access from ofdata_to_platdata() to probe()"

[Andy Shevchenko]

On Thu, Apr 2, 2020 at 7:28 PM Ang, Chee Hong  wrote:
> > On Thu, Apr 02, 2020 at 12:55:14PM +0800, Bin Meng wrote:
> > > On Thu, Apr 2, 2020 at 1:55 AM Simon Glass  wrote:
> > > > On Wed, 1 Apr 2020 at 11:39, Andy Shevchenko
> >  wrote:
> > > > > On Wed, Apr 01, 2020 at 10:56:26AM -0600, Simon Glass wrote:
> > > > > > On Wed, 1 Apr 2020 at 08:45, Andy Shevchenko
> >  wrote:
> > > > > > > On Wed, Apr 1, 2020 at 5:32 PM Bin Meng 
> > wrote:
> > > > > > > > On Wed, Apr 1, 2020 at 9:58 PM Andy Shevchenko
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > The commit breaks serial console on the Intel Edison.
> > > > > > > > >
> > > > > > > > > This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Andy Shevchenko
> > > > > > > > > 
> > > > > > > > > ---
> > > > > > > > >  drivers/serial/ns16550.c | 40
> > > > > > > > > 
> > > > > > > > >  1 file changed, 12 insertions(+), 28 deletions(-)
> > > > > > > > >
> > > > > > > >
> > > > > > > > Could you please spend some time to investigate why this breaks 
> > > > > > > > Intel
> > Edison?
> > > > > > > >
> > > > > > > > Reverting this patch would mean we break other boards too as
> > > > > > > > Wolfgang's patch wanted to fix the breakage in the first
> > > > > > > > place. Much appreciated!
> > > > > > >
> > > > > > > I guess I'm wrong person here. The DM code is a complete black 
> > > > > > > box to
> > me.
> > > > > > > Nevertheless, I may test any provided fix / debug / etc patch by 
> > > > > > > request.
> > > > > > >
> > > > > > > And I think it's fair to investigate by the one who made a
> > > > > > > regression in the first place.
> > > > > >
> > > > > > Given that we have conflicting breakages, we need to debug Edison.
> > > > >
> > > > > I would glad to test any suggested change or debug patch!
> > > > >
> > > > > > Does it enable the debug UART?
> > > > >
> > > > > If I am not mistaken, it does not.
> > > >
> > > > Looks like you are right. If you know the address you could do that
> > > > - see minnowmax for an example.
> > >
> > > Please suggest what's the best approach to proceed.
> >
> > Adding SoCFPGA folks to this thread as the first commit (82de42fa1468) is 
> > also
> > breaking platforms there and then their fix for that problem is also causing
> > problems, if I follow right.

> Yes. This commit (82de42fa1468) breaks our A10 platform.
> I did submit similar patch to move some init code from ofdata_to_platdata() 
> to probe() for our clock driver as well.
> Check out the thread here:
> https://lists.denx.de/pipermail/u-boot/2020-April/405252.html

I see half or less of the messages in the thread by above link.
Can you summarize what should have been done in order to fix this?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/2] arm: tegra: add options for BOOTENV_EFI_SET_FDTFILE_FALLBACK for tegra186

[Stephen Warren]

On 4/1/20 5:28 PM, Peter Robinson wrote:
> Upstream linux DT naming doesn't align with the U-Boot DT, which may
> not always be the case so this allows using BOOTENV_EFI_SET_FDTFILE_FALLBACK
> where it might be appropriate for some boards.
> 
> Signed-off-by: Peter Robinson 
> ---
> 
> This is a bit of a hack for the Jetson TX2 because the U-Boot config
> using a different naming for the DT naming to upstream Linux, I'm not
> sure what naming L4T uses, and whether the 000/500 variants are widely
> enough available or whether they use differnet DTs in L4T.
> 
> Welcome to suggestions of a better way to fix this one but it works
> for booting the TX2 on Fedora using UEFI..

Does the default fdtfile value set up in patch 1 work in even a majority
of cases? In other words, is there a list of boards where the DT names
do match and where they don't?

>  include/config_distro_bootcmd.h   | 2 ++
>  include/configs/tegra186-common.h | 7 ++-

For T186, rather than adding fdtfile in patch 1, then removing it in
patch 2, shouldn't we drop the T186 changes from patch 1 and go direct
to the final solution in patch 2?

For downstream SW stacks at least, the best approach is to pass through
the cboot-supplied DTB to the kernel rather than loading a new one. This
is the only way we have at present to cater for:
- Different HW revisions.
- Runtime-generated data like memory settings, carve-out locations, ...
- Optional daughter boards detected at run-time.
- HW modifications/configurations indicated by NV-custom "ODMDATA"
values in the BCT.

That said, the upstream SW stacks don't currently support or use any of
that information, and only support a single specific HW revision of each
board (or the common subset between revisions), so perhaps this aspect
isn't too relevant.

[PATCH] ARM: dts: stm32: Temporarily drop cd-gpios from AV96 DT

[Marek Vasut]

The card-detect GPIO and any other GPIO access currently doesn't work in
U-Boot SPL on any STM32 platform and crashes the SPL. To work around this
problem on AV96 right before release, remove the cd-gpios from DT. This
patch must be reverted right after release, once the proper fix for the
GPIO driver, "gpio: stm32: support gpio ops in SPL", is applied.

Signed-off-by: Marek Vasut 
Cc: Manivannan Sadhasivam 
Cc: Patrick Delaunay 
Cc: Patrice Chotard 
Cc: Tom Rini 
---
NOTE: I think it's OK if Tom picks this one directly to reduce load on
  the ST people, since this is isolated to a single board.
---
 arch/arm/dts/stm32mp157a-avenger96.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts 
b/arch/arm/dts/stm32mp157a-avenger96.dts
index 1f32395e71..b23fa6dee0 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -353,7 +353,6 @@
pinctrl-0 = <&sdmmc1_b4_pins_a &sdmmc1_dir_pins_b>;
pinctrl-1 = <&sdmmc1_b4_od_pins_a &sdmmc1_dir_pins_b>;
pinctrl-2 = <&sdmmc1_b4_sleep_pins_a &sdmmc1_dir_sleep_pins_b>;
-   cd-gpios = <&gpioi 8 GPIO_ACTIVE_LOW>;
disable-wp;
st,sig-dir;
st,neg-edge;
-- 
2.25.1

Re: [RFC PATCH v2 05/13] mmc: add nexell driver

[Stefan B.]

Hi,

thanks a lot for your reply. As you already guessed I have ported the 
outdated U-Boot from FriendlyARM, see:

https://github.com/friendlyarm/u-boot/tree/nanopi2-v2016.01

The original MMC-driver has been nexell_dw_mmc.c, so I renamed it to 
nexell_dw_mmc_dm.c after changing to DM.


I will have a closer look at your suggestions and give you feedback ASAP.


Regards
Stefan Bosch


Am 02.04.20 um 13:03 schrieb Jaehoon Chung:

Hi,

On 3/28/20 6:43 PM, Stefan Bosch wrote:

Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
- mmc: nexell_dw_mmc.c changed to nexell_dw_mmc_dm.c (switched to DM).


It doesn't need to add postfix as _dm.



Signed-off-by: Stefan Bosch 
---

Changes in v2:
- commit "i2c: mmc: add nexell driver (gpio, i2c, mmc, pwm)" splitted
   into separate commits for gpio, i2c, mmc, pwm.

  drivers/mmc/Kconfig|   6 +
  drivers/mmc/Makefile   |   1 +
  drivers/mmc/nexell_dw_mmc_dm.c | 350 +
  3 files changed, 357 insertions(+)
  create mode 100644 drivers/mmc/nexell_dw_mmc_dm.c

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 2f0eedc..bb8e7c0 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -253,6 +253,12 @@ config MMC_DW_SNPS
  This selects support for Synopsys DesignWare Memory Card Interface 
driver
  extensions used in various Synopsys ARC devboards.
  
+config NEXELL_DWMMC

+   bool "Nexell SD/MMC controller support"
+   depends on ARCH_NEXELL
+   depends on MMC_DW
+   default y


Not depends on DM_MMC?


+
  config MMC_MESON_GX
bool "Meson GX EMMC controller support"
depends on DM_MMC && BLK && ARCH_MESON
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 9c1f8e5..a7b5a7b 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_SH_MMCIF) += sh_mmcif.o
  obj-$(CONFIG_SH_SDHI) += sh_sdhi.o
  obj-$(CONFIG_STM32_SDMMC2) += stm32_sdmmc2.o
  obj-$(CONFIG_JZ47XX_MMC) += jz_mmc.o
+obj-$(CONFIG_NEXELL_DWMMC) += nexell_dw_mmc_dm.o
  
  # SDHCI

  obj-$(CONFIG_MMC_SDHCI)   += sdhci.o
diff --git a/drivers/mmc/nexell_dw_mmc_dm.c b/drivers/mmc/nexell_dw_mmc_dm.c
new file mode 100644
index 000..b06b60d
--- /dev/null
+++ b/drivers/mmc/nexell_dw_mmc_dm.c
@@ -0,0 +1,350 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2016 Nexell
+ * Youngbok, Park 
+ *
+ * (C) Copyright 2019 Stefan Bosch 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DWMCI_CLKSEL   0x09C
+#define DWMCI_SHIFT_0  0x0
+#define DWMCI_SHIFT_1  0x1
+#define DWMCI_SHIFT_2  0x2
+#define DWMCI_SHIFT_3  0x3
+#define DWMCI_SET_SAMPLE_CLK(x)(x)
+#define DWMCI_SET_DRV_CLK(x)   ((x) << 16)
+#define DWMCI_SET_DIV_RATIO(x) ((x) << 24)
+#define DWMCI_CLKCTRL  0x114
+#define NX_MMC_CLK_DELAY(x, y, a, b)   x) & 0xFF) << 0) |\
+   (((y) & 0x03) << 16) |\
+   (((a) & 0xFF) << 8)  |\
+   (((b) & 0x03) << 24))
+
+struct nexell_mmc_plat {
+   struct mmc_config cfg;
+   struct mmc mmc;
+};
+
+struct nexell_dwmmc_priv {
+   struct clk *clk;
+   struct dwmci_host host;
+   int fifo_size;
+   bool fifo_mode;
+   int frequency;
+   u32 min_freq;
+   u32 max_freq;
+   int d_delay;
+   int d_shift;
+   int s_delay;
+   int s_shift;
+
+};
+
+struct clk *clk_get(const char *id);
+
+static void set_pin_stat(int index, int bit, int value)
+{
+#if !defined(CONFIG_SPL_BUILD)
+   nx_gpio_set_pad_function(index, bit, value);
+#else
+#if defined(CONFIG_ARCH_S5P4418) ||\
+   defined(CONFIG_ARCH_S5P6818)
+
+   unsigned long base[5] = {
+   PHY_BASEADDR_GPIOA, PHY_BASEADDR_GPIOB,
+   PHY_BASEADDR_GPIOC, PHY_BASEADDR_GPIOD,
+   PHY_BASEADDR_GPIOE,
+   };


I don't understand why gpio pin is set in mmc driver?
If nexell soc will change the gpio map and function value, does it needs to add 
other gpio control?


+
+   dw_mmc_set_pin(base[index], bit, value);
+#endif
+#endif
+}
+
+static void nx_dw_mmc_set_pin(struct dwmci_host *host)
+{
+   debug("  %s(): dev_index == %d", __func__, host->dev_index);
+
+   switch (host->dev_index) {
+   case 0:
+   set_pin_stat(0, 29, 1);
+   set_pin_stat(0, 31, 1);
+   set_pin_stat(1, 1, 1);
+   set_pin_stat(1, 3, 1);
+   set_pin_stat(1, 5, 1);
+   set_pin_stat(1, 7, 1);
+   break;
+   case 1:
+   set_pin_stat(3, 22, 1);
+   set_pin_stat(3, 23, 1);
+   set_pin_stat(3, 24, 1);
+   set_pin_stat(3, 25, 1);
+   set_pin_stat(3, 26, 1);
+   set_pin_stat(3, 27, 1);
+

RE: [PATCH v2 1/2] serial: ns16550: Revert "Move PCI access from ofdata_to_platdata() to probe()"

[Ang, Chee Hong]

> On Thu, Apr 02, 2020 at 12:55:14PM +0800, Bin Meng wrote:
> > Hi Simon, Andy,
> >
> > On Thu, Apr 2, 2020 at 1:55 AM Simon Glass  wrote:
> > >
> > > Hi Andy,
> > >
> > > On Wed, 1 Apr 2020 at 11:39, Andy Shevchenko
>  wrote:
> > > >
> > > > On Wed, Apr 01, 2020 at 10:56:26AM -0600, Simon Glass wrote:
> > > > > Hi Andy,
> > > > >
> > > > > On Wed, 1 Apr 2020 at 08:45, Andy Shevchenko
>  wrote:
> > > > > >
> > > > > > On Wed, Apr 1, 2020 at 5:32 PM Bin Meng 
> wrote:
> > > > > > > On Wed, Apr 1, 2020 at 9:58 PM Andy Shevchenko
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > The commit breaks serial console on the Intel Edison.
> > > > > > > >
> > > > > > > > This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c.
> > > > > > > >
> > > > > > > > Signed-off-by: Andy Shevchenko
> > > > > > > > 
> > > > > > > > ---
> > > > > > > >  drivers/serial/ns16550.c | 40
> > > > > > > > 
> > > > > > > >  1 file changed, 12 insertions(+), 28 deletions(-)
> > > > > > > >
> > > > > > >
> > > > > > > Could you please spend some time to investigate why this breaks 
> > > > > > > Intel
> Edison?
> > > > > > >
> > > > > > > Reverting this patch would mean we break other boards too as
> > > > > > > Wolfgang's patch wanted to fix the breakage in the first
> > > > > > > place. Much appreciated!
> > > > > >
> > > > > > I guess I'm wrong person here. The DM code is a complete black box 
> > > > > > to
> me.
> > > > > > Nevertheless, I may test any provided fix / debug / etc patch by 
> > > > > > request.
> > > > > >
> > > > > > And I think it's fair to investigate by the one who made a
> > > > > > regression in the first place.
> > > > >
> > > > > Given that we have conflicting breakages, we need to debug Edison.
> > > >
> > > > I would glad to test any suggested change or debug patch!
> > > >
> > > > > Does it enable the debug UART?
> > > >
> > > > If I am not mistaken, it does not.
> > >
> > > Looks like you are right. If you know the address you could do that
> > > - see minnowmax for an example.
> >
> > Please suggest what's the best approach to proceed.
> 
> Adding SoCFPGA folks to this thread as the first commit (82de42fa1468) is also
> breaking platforms there and then their fix for that problem is also causing
> problems, if I follow right.
> 
> --
> Tom

Yes. This commit (82de42fa1468) breaks our A10 platform.
I did submit similar patch to move some init code from ofdata_to_platdata() to 
probe() for our clock driver as well.
Check out the thread here:
https://lists.denx.de/pipermail/u-boot/2020-April/405252.html

Re: Please pull u-boot-video

[Anatolij Gustschin]

On Thu, 2 Apr 2020 18:13:50 +0200
Anatolij Gustschin ag...@denx.de wrote:
...
>   https://gitlab.denx.de/u-boot/custodians/u-boot-video.git 
> tags/video-fixes-2apr20
> 
> for you to fetch changes up to 05c65a82c3c1a1f5aced30babde51f934e066717:
> 
>   video: rockchip: Support 4K resolution for rk3399, HDMI (2020-04-02 
> 15:52:01 +0200)

Build test passed:
https://gitlab.denx.de/u-boot/custodians/u-boot-video/pipelines/2606

--
Anatolij

Please pull u-boot-video

[Anatolij Gustschin]

Hi Tom,

The following changes since commit e0718b3ab754860bd47677e6b4fc5b70da42c4ab:

  Merge tag 'dm-pull-1apr20' of git://git.denx.de/u-boot-dm (2020-04-01 
14:29:21 -0400)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-video.git 
tags/video-fixes-2apr20

for you to fetch changes up to 05c65a82c3c1a1f5aced30babde51f934e066717:

  video: rockchip: Support 4K resolution for rk3399, HDMI (2020-04-02 15:52:01 
+0200)


- rockchip RK3399 HDMI output fix


Jagan Teki (5):
  clk: rk3399: Set empty for vopl assigned-clocks
  video: rockchip: Fix vop modes for rk3399
  rockchip: Enable pre console for rk3399
  rockchip: Enable HDMI output on rk3399 board w/ HDMI
  video: rockchip: Support 4K resolution for rk3399, HDMI

 arch/arm/include/asm/arch-rockchip/vop_rk3288.h | 11 +++
 arch/arm/mach-rockchip/Kconfig  |  1 +
 common/Kconfig  |  1 +
 configs/nanopc-t4-rk3399_defconfig  |  7 +++
 configs/nanopi-m4-rk3399_defconfig  |  7 +++
 configs/nanopi-neo4-rk3399_defconfig|  7 +++
 configs/roc-pc-rk3399_defconfig |  6 ++
 configs/rock960-rk3399_defconfig|  7 +++
 drivers/clk/rockchip/clk_rk3399.c   |  7 +++
 drivers/video/rockchip/Kconfig  |  2 ++
 drivers/video/rockchip/rk3399_vop.c |  2 --
 drivers/video/rockchip/rk_vop.c |  4 
 include/configs/evb_rk3399.h|  5 +
 include/configs/rock960_rk3399.h|  5 +
 14 files changed, 70 insertions(+), 2 deletions(-)

Re: [PATCH] nand: brcmnand: return without disabling clock

[Álvaro Fernández Rojas]

> El 2 abr 2020, a las 17:49, Tom Rini  escribió:
> 
> On Thu, Apr 02, 2020 at 11:15:51AM +0200, Daniel Schwierzeck wrote:
>> 
>> 
>> Am 02.04.20 um 10:37 schrieb Álvaro Fernández Rojas:
>>> Linux Broadcom NAND driver only disabled clock if no childs are initialized.
>>> This section of the code seems to have been accidentally dropped when it was
>>> imported in U-Boot.
>>> 
>>> Signed-off-by: Álvaro Fernández Rojas 
>>> ---
>>> drivers/mtd/nand/raw/brcmnand/brcmnand.c | 9 -
>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>> 
>> 
>> Reviewed-by: Daniel Schwierzeck 
> 
> Does this need to go in to v2020.04?  Thanks!
> 
> -- 
> Tom

Not really. I tested it with a development branch and this affects bcm6362 
devices (nand not currently supported), but it doesn’t affect bcm63268 devices 
(1 device supported).

Best regards,
Álvaro.

Re: [PATCH] nand: brcmnand: return without disabling clock

[Tom Rini]

On Thu, Apr 02, 2020 at 11:15:51AM +0200, Daniel Schwierzeck wrote:
> 
> 
> Am 02.04.20 um 10:37 schrieb Álvaro Fernández Rojas:
> > Linux Broadcom NAND driver only disabled clock if no childs are initialized.
> > This section of the code seems to have been accidentally dropped when it was
> > imported in U-Boot.
> > 
> > Signed-off-by: Álvaro Fernández Rojas 
> > ---
> >  drivers/mtd/nand/raw/brcmnand/brcmnand.c | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> 
> Reviewed-by: Daniel Schwierzeck 

Does this need to go in to v2020.04?  Thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] rockchip: board: roc-pc-rk3399: Remove support for push button

[Suniel Mahesh]

On Thu, Apr 2, 2020 at 6:32 PM Kever Yang  wrote:
>
> Hi Sunil, Jagan,
>
> What suppose to be for LEDs status base on this patch and patch[0]?

The earlier patch with commit id and title below:
5a6d3d1fbca70d7f528c685292d64c4cd0106aa6
board: roc-pc-rk3399: Add support for onboard LED's and push
button to indicate power mode

introduced a scenario where, if the device is in a remote location and
rebooted, then human intervention
is required to press the Power key/push button.

The patch[0] is the fix for the reboot scenario.

But as pointed out by Markus Reichl, if there is a power
outage/interruption, still human intervention
is required to press the Power key/push button, and as result markus
suggested for a straight boot without
human intervention in all cases.
(http://lists.infradead.org/pipermail/linux-rockchip/2020-April/030224.html)

This patch does a straight boot without human intervention in all cases.

so, patch[0], patch[1], patch[2], patch[3] are not required.
patch[1]: https://patchwork.ozlabs.org/patch/1258095/
patch[2]: https://patchwork.ozlabs.org/patch/1258096/
patch[3]: https://patchwork.ozlabs.org/patch/1258097/

Thanks
Suniel
>
>
> Thanks,
>
> - Kever
>
> [0] https://patchwork.ozlabs.org/patch/1258094/
>
> On 2020/4/2 下午8:52, su...@amarulasolutions.com wrote:
>
> From: Suniel Mahesh 
>
> In case of a power interruption, human intervention is required which
> is not desirable if the device is installed at a remote location. Drop
> yellow LED as it is not much of use. Keep red LED(diy-led) as it is, to
> indicate board in full power mode.
>
> Signed-off-by: Suniel Mahesh 
> ---
> Note:
> - patch tested on rk3399-roc-pc
> - code related to button press is removed
> ---
>  board/firefly/roc-pc-rk3399/roc-pc-rk3399.c | 16 +---
>  1 file changed, 1 insertion(+), 15 deletions(-)
>
> diff --git a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c 
> b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
> index de9185a..0fe1914 100644
> --- a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
> +++ b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
> @@ -10,7 +10,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>
>  #ifndef CONFIG_SPL_BUILD
>  int board_early_init_f(void)
> @@ -34,26 +33,13 @@ out:
>
>  #if defined(CONFIG_TPL_BUILD)
>
> -#define PMUGRF_BASE 0xff32
>  #define GPIO0_BASE  0xff72
>
>  int board_early_init_f(void)
>  {
>   struct rockchip_gpio_regs * const gpio0 = (void *)GPIO0_BASE;
> - struct rk3399_pmugrf_regs * const pmugrf = (void *)PMUGRF_BASE;
>
> - /**
> - * 1. Glow yellow LED, termed as low power
> - * 2. Poll for on board power key press
> - * 3. Once 2 done, off yellow and glow red LED, termed as full power
> - * 4. Continue booting...
> - */
> - spl_gpio_output(gpio0, GPIO(BANK_A, 2), 1);
> -
> - spl_gpio_set_pull(&pmugrf->gpio0_p, GPIO(BANK_A, 5), GPIO_PULL_NORMAL);
> - while (readl(&gpio0->ext_port) & 0x20);
> -
> - spl_gpio_output(gpio0, GPIO(BANK_A, 2), 0);
> + /* Turn on red LED, indicating full power mode */
>   spl_gpio_output(gpio0, GPIO(BANK_B, 5), 1);
>
>   return 0;

Re: [PATCH v3 0/5] rockchip: rk3399: Fix HDMI out

[Anatolij Gustschin]

Hi Kever,

On Thu, 2 Apr 2020 22:28:53 +0800
Kever Yang kever.y...@rock-chips.com wrote:
...
> > Series applied to u-boot-video/video-fixes-v2020.04, thanks!  
> 
> I was about to apply these patches, and under travis build now.
> 
> It's also OK for these patches to merge into u-boot-video.

I'm build testing the series [1] and will submit a pull request to
Tom.

[1] https://gitlab.denx.de/u-boot/custodians/u-boot-video/pipelines/2606

--
Anatolij

Re: [PATCH v3 0/5] rockchip: rk3399: Fix HDMI out

[Kever Yang]

Hi Anatolij,

On 2020/4/2 下午9:56, Anatolij Gustschin wrote:

On Thu,  2 Apr 2020 17:11:20 +0530
Jagan Teki ja...@amarulasolutions.com wrote:
...

Jagan Teki (5):
   clk: rk3399: Set empty for vopl assigned-clocks
   video: rockchip: Fix vop modes for rk3399
   rockchip: Enable pre console for rk3399
   rockchip: Enable HDMI output on rk3399 board w/ HDMI
   video: rockchip: Support 4K resolution for rk3399, HDMI

  arch/arm/include/asm/arch-rockchip/vop_rk3288.h | 11 +++
  arch/arm/mach-rockchip/Kconfig  |  1 +
  common/Kconfig  |  1 +
  configs/nanopc-t4-rk3399_defconfig  |  7 +++
  configs/nanopi-m4-rk3399_defconfig  |  7 +++
  configs/nanopi-neo4-rk3399_defconfig|  7 +++
  configs/roc-pc-rk3399_defconfig |  6 ++
  configs/rock960-rk3399_defconfig|  7 +++
  drivers/clk/rockchip/clk_rk3399.c   |  7 +++
  drivers/video/rockchip/Kconfig  |  2 ++
  drivers/video/rockchip/rk3399_vop.c |  2 --
  drivers/video/rockchip/rk_vop.c |  4 
  include/configs/evb_rk3399.h|  5 +
  include/configs/rock960_rk3399.h|  5 +
  14 files changed, 70 insertions(+), 2 deletions(-)

Series applied to u-boot-video/video-fixes-v2020.04, thanks!


I was about to apply these patches, and under travis build now.

It's also OK for these patches to merge into u-boot-video.


Thanks,

- Kever



--
Anatolij

Re: [PATCH v3 0/5] rockchip: rk3399: Fix HDMI out

[Anatolij Gustschin]

On Thu,  2 Apr 2020 17:11:20 +0530
Jagan Teki ja...@amarulasolutions.com wrote:
...
> Jagan Teki (5):
>   clk: rk3399: Set empty for vopl assigned-clocks
>   video: rockchip: Fix vop modes for rk3399
>   rockchip: Enable pre console for rk3399
>   rockchip: Enable HDMI output on rk3399 board w/ HDMI
>   video: rockchip: Support 4K resolution for rk3399, HDMI
> 
>  arch/arm/include/asm/arch-rockchip/vop_rk3288.h | 11 +++
>  arch/arm/mach-rockchip/Kconfig  |  1 +
>  common/Kconfig  |  1 +
>  configs/nanopc-t4-rk3399_defconfig  |  7 +++
>  configs/nanopi-m4-rk3399_defconfig  |  7 +++
>  configs/nanopi-neo4-rk3399_defconfig|  7 +++
>  configs/roc-pc-rk3399_defconfig |  6 ++
>  configs/rock960-rk3399_defconfig|  7 +++
>  drivers/clk/rockchip/clk_rk3399.c   |  7 +++
>  drivers/video/rockchip/Kconfig  |  2 ++
>  drivers/video/rockchip/rk3399_vop.c |  2 --
>  drivers/video/rockchip/rk_vop.c |  4 
>  include/configs/evb_rk3399.h|  5 +
>  include/configs/rock960_rk3399.h|  5 +
>  14 files changed, 70 insertions(+), 2 deletions(-)

Series applied to u-boot-video/video-fixes-v2020.04, thanks!

--
Anatolij

Re: latest u-boot branch for Marvell Armada 88F3720

[Marek Behun]

On Thu, 2 Apr 2020 14:18:24 +0200
Stefan Roese  wrote:

> Hi Moritz,
> 
> On 02.04.20 13:30, Moritz Berghof wrote:
> > it's really great that you answered so fast and helpfully, thank you!
> > 
> > It's great you want get the board ported to mainline. Me too.
> > 
> > 
> > I build the U-boot mainline and uploaded on my espressobin. Used the ATF
> > and WTMI from Marvell.
> > 
> > When I start the flashed .bin file, the U-boot crashed at this following
> > point. "Synchronous Abort" handler, esr 0x96000210  
> 
> Looks like an issue with SATA - not sure why. You might want to try to
> disable SATA / AHCI for testing.
> 
> > Prompt is attached at this mail.
> > 
> > I think there is a problem with the RAM. For example, I build the U-Boot
> > for 1 GB RAM with the Marvell U-boot and the mainline/master. Important
> > constant is DDR_TOPOLOGY=2
> > 
> > make DEBUG=0 USE_COHERENT_MEM=0 LOG_LEVEL=20 SECURE=0 
> > CLOCKSPRESET=CPU_1000_DDR_800 DDR_TOPOLOGY=2 WTP=... BOOTDEV=SPINOR 
> > PARTNUM=0 PLAT=a3700 all fip
> > 
> > But when the u-boot mainline starts it promts:
> > U-Boot 2020.04-rc3-00188-g350c44dfb9 (Mar 31 2020 - 10:52:01 +0200)
> > 
> > DRAM:  512 MiB
> > 
> > 
> > The Marvell U-boot promts DRAM: 1 GiB
> > 
> > 
> > 
> > So my question is, where do you define the RAM Size?  
> 
> Take a look at arch/arm/mach-mvebu/arm64-common.c. Perhaps this code
> needs some changes for CONFIG_ARMADA_A3700 similar to what is done
> for CONFIG_ARMADA_8K ?
> 
> I suggest you debug in this area a bit to see, where it goes wrong.

There is a register on A3720 which should contain information about how
much RAM the system has (0xD200 if the device contains only one
DDR chip). It is written by the TIM image. I am going to send a patch
which uses this register to determine RAM size for Turris Mox.

The thing is that without upgrade of TIM header some Moxes may report
1 GB RAM in this register, although they only have 512 MB. So a call to
get_ram_size will still be needed.

Marek

[PATCH 2/2] arm: dts: k3-j721e: Increase OSPI default frequency to 50MHz

[Vignesh Raghavendra]

In 1 bit mode OSPI can work at upto 50MHz, this provides before write
performance. Therefore increase frequency from 40MHz to 50MHz

Signed-off-by: Vignesh Raghavendra 
---
 arch/arm/dts/k3-j721e-r5-common-proc-board.dts | 2 +-
 arch/arm/dts/k3-j721e-som-p0.dtsi  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts 
b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
index 403b158f4900..2dde65d9681d 100644
--- a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
@@ -309,7 +309,7 @@
reg = <0x0>;
spi-tx-bus-width = <1>;
spi-rx-bus-width = <8>;
-   spi-max-frequency = <4000>;
+   spi-max-frequency = <5000>;
cdns,tshsl-ns = <60>;
cdns,tsd2d-ns = <60>;
cdns,tchsh-ns = <60>;
diff --git a/arch/arm/dts/k3-j721e-som-p0.dtsi 
b/arch/arm/dts/k3-j721e-som-p0.dtsi
index 8497ff3e3e12..946de9c3fc69 100644
--- a/arch/arm/dts/k3-j721e-som-p0.dtsi
+++ b/arch/arm/dts/k3-j721e-som-p0.dtsi
@@ -87,7 +87,7 @@
reg = <0x0>;
spi-tx-bus-width = <1>;
spi-rx-bus-width = <8>;
-   spi-max-frequency = <4000>;
+   spi-max-frequency = <5000>;
cdns,tshsl-ns = <60>;
cdns,tsd2d-ns = <60>;
cdns,tchsh-ns = <60>;
-- 
2.26.0

[PATCH 1/2] arm: dts: k3-am654: Increase OSPI default frequency to 50MHz

[Vignesh Raghavendra]

In 1 bit mode OSPI can work at upto 50MHz, this provides before write
performance. Therefore increase frequency from 40MHz to 50MHz

Signed-off-by: Vignesh Raghavendra 
---
 arch/arm/dts/k3-am654-base-board.dts| 2 +-
 arch/arm/dts/k3-am654-r5-base-board.dts | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/k3-am654-base-board.dts 
b/arch/arm/dts/k3-am654-base-board.dts
index 5058b6c88e96..3ebf4af5e47a 100644
--- a/arch/arm/dts/k3-am654-base-board.dts
+++ b/arch/arm/dts/k3-am654-base-board.dts
@@ -191,7 +191,7 @@
reg = <0x0>;
spi-tx-bus-width = <1>;
spi-rx-bus-width = <8>;
-   spi-max-frequency = <4000>;
+   spi-max-frequency = <5000>;
cdns,tshsl-ns = <60>;
cdns,tsd2d-ns = <60>;
cdns,tchsh-ns = <60>;
diff --git a/arch/arm/dts/k3-am654-r5-base-board.dts 
b/arch/arm/dts/k3-am654-r5-base-board.dts
index 257b56a1b032..e6b78643c197 100644
--- a/arch/arm/dts/k3-am654-r5-base-board.dts
+++ b/arch/arm/dts/k3-am654-r5-base-board.dts
@@ -268,7 +268,7 @@
reg = <0x0>;
spi-tx-bus-width = <1>;
spi-rx-bus-width = <8>;
-   spi-max-frequency = <4000>;
+   spi-max-frequency = <5000>;
cdns,tshsl-ns = <60>;
cdns,tsd2d-ns = <60>;
cdns,tchsh-ns = <60>;
-- 
2.26.0

Re: [PATCH V3 13/14] ARM: dts: stm32: Adjust PLL4 settings on AV96

[Marek Vasut]

On 4/2/20 9:44 AM, Gerald BAEZA wrote:
> Hi Marek
> 
>> From: Marek Vasut 
>> Sent: mercredi 1 avril 2020 20:49
>>
>> On 4/1/20 6:49 PM, Gerald BAEZA wrote:
>>> Hi Marek and Patrick
>>
>> Hi,
>>
 From: Marek Vasut 
 Sent: mercredi 1 avril 2020 13:09

 On 4/1/20 12:24 PM, Patrick DELAUNAY wrote:
> Hi Gerald and Manivannan,

 Hi,

>> From: Marek Vasut 
>> Sent: mardi 31 mars 2020 19:52
>>
>> The PLL4 is supplying SDMMC12, SDMMC3 and SPDIF with 120 MHz and
>> FDCAN with 96 MHz. This isn't good for the SDMMC interfaces, which
>> can not easily divide the clock down to e.g. 50 MHz for high speed
>> SD and eMMC devices, so those devices end up running at 30 MHz as
>> that is
 120 MHz / 4.
>> Adjust the PLL4 settings such that both PLL4P and PLL4R run at 100
>> MHz instead, which is easy to divide to 50MHz for optimal operation
>> of both SD and eMMC, SPDIF clock are not that much slower and
>> FDCAN
>> is
 also unaffected.
>>>
>>> As far as I see, SPDIF is not supported on Avenger board so we don't care
>> for this one.
>>> FDCAN can be supported via the expansion connector, so better to keep it
>> high (and < 100 MHz).
>>
>> Why < 100 MHz and not <= 100 MHz ?
> 
> You're right, it is <= 100 MHz and it is important to be precise since you 
> were exactly on 100 MHz :)
> 
>>> Be careful because the LTDC pixel clock also comes from the PLL4Q and it is
>> used for the HDMI on Avenger.
>>> The pixel clock is very constraint and I am surprised by the initial 40 MHz
>> configuration (that becomes 50 MHz with your patch).
>>
>> Is that a problem that the LTDC pixel clock are 50 MHz ? The kernel will
>> reconfigure them anyway, so the 50 MHz is not the final value.
> 
> The kernel set_rate() changes the PLL output divisor, so it will indeed be 
> able to switch back to (600/15=) 40 MHz from an initial (600/12=) 50 MHz.
> 
>>> I would recommend to align the Avenger configuration to ST boards one,
>> that is the best compromise found so far (99 MHz for SDMMC and 74.250
>> MHz for HDMI):
>>
>> Why is this better than 100/50/100 ?
>>
>>> https://wiki.st.com/stm32mpu/wiki/STM32MP15_clock_tree
>>> /* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
>>> pll4: st,pll@3 {
>>> cfg = < 3 98 5 7 7 PQR(1,1,1) >;
>>> u-boot,dm-pre-reloc;
>>> };
>> [...]
> 
> The simplest explanation I found is here:
> https://timetoexplore.net/blog/video-timings-vga-720p-1080p
> (you can also look for "74.25" in the HDMI specification but there is more 
> text to read)
> 
> So 74.250 MHz is the needed pixel clock for 720p resolution in HDMI, that is 
> quite common, so this frequency is wished for interoperability with a maximum 
> of TVs.
> This frequency cannot be reached from the initial or your proposed PLL4 
> configuration, that is why I proposed to change this and align on ST board 
> clock tree.
> 
> For the other displays we are supporting on ST boards, the kernel is tuning 
> (down) this 74.250 MHz frequency via the set_rate (that changes the PLL 
> output divisor).

The article you found is focused on FPGA, where the FPGA is connected
directly to the HDMI TMDS signals without transceiver, so the FPGA has
to generate very precise clock. I don't think this is our case here.

The ADV7513 datasheet says nothing about such specific clock rate, it
only mentions maximum clock per resolution to be 82.5 MHz and that it
can do pixel repeat to meet the timing requirements.

(Note to self, PLL4R should run at 99 MHz too, to run FDCAN fast enough.)

Re: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96

[Marek Vasut]

On 4/2/20 2:53 PM, Pascal PAILLET-LME wrote:
> Hi Marek,

Hi,
[...]
>>> vdd: buck3 {
>>> regulator-name = "vdd";
>>> -   regulator-min-microvolt = <330>;
>>> -   regulator-max-microvolt = <330>;
>>> +   regulator-min-microvolt = <290>;
>>> +   regulator-max-microvolt = <290>;
>>> regulator-always-on;
>>> st,mask_reset;
>>> regulator-initial-mode = <0>; @@ -
>> 268,6 +279,7 @@
>>> regulator-name = "vbus_otg";
>>> interrupts = ;
>>> interrupt-parent = <&pmic>;
>>> +   regulator-active-discharge = <1>;
>> It seems this setting introduced other-consumption, it should not be
>> used.
> Other-consumption ? What does that mean ?

 It's a typo, Patrick means over-consumption.
>>>
>>> Ah. Do you have any details on that ?
>>
>> Sorry for typo.
>>
>> No details on my side, it was a Pascal Paillet's direct feedback (Maintainer 
>> of
>> STPMIC1 driver in Linux).
> You can enable the active discharge on the STPMIC1's VBUSOTG. But, as soon as 
> a USB host peripheral (such as laptop) will attach and provide VBUS, there 
> will be a ~8mA continuous power consumption on VBUS through this OTG active 
> discharge. There is no functional issue behind this 8mA; but you need to know 
> that 8mA is not compliant with the USB suspend constraint (2.5mA max).

So why is it in there ?

Re: [PATCH] rockchip: board: roc-pc-rk3399: Remove support for push button

[Kever Yang]

Hi Sunil, Jagan,

    What suppose to be for LEDs status base on this patch and patch[0]?


Thanks,

- Kever

[0] https://patchwork.ozlabs.org/patch/1258094/ 



On 2020/4/2 下午8:52, su...@amarulasolutions.com wrote:

From: Suniel Mahesh 

In case of a power interruption, human intervention is required which
is not desirable if the device is installed at a remote location. Drop
yellow LED as it is not much of use. Keep red LED(diy-led) as it is, to
indicate board in full power mode.

Signed-off-by: Suniel Mahesh 
---
Note:
- patch tested on rk3399-roc-pc
- code related to button press is removed
---
  board/firefly/roc-pc-rk3399/roc-pc-rk3399.c | 16 +---
  1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c 
b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
index de9185a..0fe1914 100644
--- a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
+++ b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
@@ -10,7 +10,6 @@
  #include 
  #include 
  #include 
-#include 
  
  #ifndef CONFIG_SPL_BUILD

  int board_early_init_f(void)
@@ -34,26 +33,13 @@ out:
  
  #if defined(CONFIG_TPL_BUILD)
  
-#define PMUGRF_BASE 0xff32

  #define GPIO0_BASE  0xff72
  
  int board_early_init_f(void)

  {
struct rockchip_gpio_regs * const gpio0 = (void *)GPIO0_BASE;
-   struct rk3399_pmugrf_regs * const pmugrf = (void *)PMUGRF_BASE;
  
-	/**

-* 1. Glow yellow LED, termed as low power
-* 2. Poll for on board power key press
-* 3. Once 2 done, off yellow and glow red LED, termed as full power
-* 4. Continue booting...
-*/
-   spl_gpio_output(gpio0, GPIO(BANK_A, 2), 1);
-
-   spl_gpio_set_pull(&pmugrf->gpio0_p, GPIO(BANK_A, 5), GPIO_PULL_NORMAL);
-   while (readl(&gpio0->ext_port) & 0x20);
-
-   spl_gpio_output(gpio0, GPIO(BANK_A, 2), 0);
+   /* Turn on red LED, indicating full power mode */
spl_gpio_output(gpio0, GPIO(BANK_B, 5), 1);
  
  	return 0;

Re: [PATCH v2 1/5] rockchip: Separate the reset cause from display cpuinfo

[Kever Yang]

On 2020/3/19 下午6:12, Jagan Teki wrote:

reset cause is a generic functionality based on the soc
cru registers in rockchip. This can be used for printing
the cause of reset in cpuinfo or some other place where
reset cause is needed.

Other than cpuinfo, reset cause can also be using during
bootcount for checking the specific reset cause and glow
the led based on the reset cause.

So, let's separate the reset cause code from cpuinfo, and
add a check to build it for rk3399, rk3288 since these two
soc are supporting reset cause as of now.

Signed-off-by: Jagan Teki 
---
Changes for v2:
- none

  arch/arm/include/asm/arch-rockchip/cru.h |  2 ++
  arch/arm/mach-rockchip/Makefile  |  5 -
  arch/arm/mach-rockchip/cpu-info.c| 20 
  3 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/cru.h 
b/arch/arm/include/asm/arch-rockchip/cru.h
index 5cf2aec11a..b2ffc57c7d 100644
--- a/arch/arm/include/asm/arch-rockchip/cru.h
+++ b/arch/arm/include/asm/arch-rockchip/cru.h
@@ -27,4 +27,6 @@ enum {
  
  #define MHz		100
  
+char *get_reset_cause(void);

+
  #endif /* _ROCKCHIP_CLOCK_H */
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 5b38526fe0..ef4898e00c 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -15,6 +15,10 @@ obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
  
  obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
  
+ifeq ($(CONFIG_ROCKCHIP_RK3288)$(CONFIG_ROCKCHIP_RK3399), y)

+obj-y += cpu-info.o
+endif
+
  ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
  
  # Always include boot_mode.o, as we bypass it (i.e. turn it off)

@@ -22,7 +26,6 @@ ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
  # we can have the preprocessor correctly recognise both 0x0 and 0
  # meaning "turn it off".
  obj-y += boot_mode.o
-obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o


I would prefer to keep this instead of only available for rk3288/rk3399,

because other SoCs also support this feature.


Thanks,

- Kever


  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
  obj-$(CONFIG_MISC_INIT_R) += misc.o
  endif
diff --git a/arch/arm/mach-rockchip/cpu-info.c 
b/arch/arm/mach-rockchip/cpu-info.c
index 4b0e99299a..ee0ec3d082 100644
--- a/arch/arm/mach-rockchip/cpu-info.c
+++ b/arch/arm/mach-rockchip/cpu-info.c
@@ -11,7 +11,7 @@
  #include 
  #include 
  
-static char *get_reset_cause(void)

+char *get_reset_cause(void)
  {
struct rockchip_cru *cru = rockchip_get_cru();
char *cause = NULL;
@@ -39,12 +39,6 @@ static char *get_reset_cause(void)
cause = "unknown reset";
}
  
-	/**

-* reset_reason env is used by rk3288, due to special use case
-* to figure it the boot behavior. so keep this as it is.
-*/
-   env_set("reset_reason", cause);
-
/*
 * Clear glb_rst_st, so we can determine the last reset cause
 * for following resets.
@@ -54,12 +48,22 @@ static char *get_reset_cause(void)
return cause;
  }
  
+#ifdef CONFIG_DISPLAY_CPUINFO

  int print_cpuinfo(void)
  {
+   char *cause = get_reset_cause();
+
printf("SoC: Rockchip %s\n", CONFIG_SYS_SOC);
-   printf("Reset cause: %s\n", get_reset_cause());
+   printf("Reset cause: %s\n", cause);
+
+   /**
+* reset_reason env is used by rk3288, due to special use case
+* to figure it the boot behavior. so keep this as it is.
+*/
+   env_set("reset_reason", cause);
  
  	/* TODO print operating temparature and clock */
  
  	return 0;

  }
+#endif

[PATCH] rockchip: board: roc-pc-rk3399: Remove support for push button

[sunil]

From: Suniel Mahesh 

In case of a power interruption, human intervention is required which
is not desirable if the device is installed at a remote location. Drop
yellow LED as it is not much of use. Keep red LED(diy-led) as it is, to
indicate board in full power mode.

Signed-off-by: Suniel Mahesh 
---
Note:
- patch tested on rk3399-roc-pc
- code related to button press is removed
---
 board/firefly/roc-pc-rk3399/roc-pc-rk3399.c | 16 +---
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c 
b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
index de9185a..0fe1914 100644
--- a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
+++ b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #ifndef CONFIG_SPL_BUILD
 int board_early_init_f(void)
@@ -34,26 +33,13 @@ out:
 
 #if defined(CONFIG_TPL_BUILD)
 
-#define PMUGRF_BASE 0xff32
 #define GPIO0_BASE  0xff72
 
 int board_early_init_f(void)
 {
struct rockchip_gpio_regs * const gpio0 = (void *)GPIO0_BASE;
-   struct rk3399_pmugrf_regs * const pmugrf = (void *)PMUGRF_BASE;
 
-   /**
-* 1. Glow yellow LED, termed as low power
-* 2. Poll for on board power key press
-* 3. Once 2 done, off yellow and glow red LED, termed as full power
-* 4. Continue booting...
-*/
-   spl_gpio_output(gpio0, GPIO(BANK_A, 2), 1);
-
-   spl_gpio_set_pull(&pmugrf->gpio0_p, GPIO(BANK_A, 5), GPIO_PULL_NORMAL);
-   while (readl(&gpio0->ext_port) & 0x20);
-
-   spl_gpio_output(gpio0, GPIO(BANK_A, 2), 0);
+   /* Turn on red LED, indicating full power mode */
spl_gpio_output(gpio0, GPIO(BANK_B, 5), 1);
 
return 0;
-- 
2.7.4

Re: [PATCH v2] arch: Add explicit linker script for u-boot-elf

[Álvaro Fernández Rojas]

Hi Daniel,

Tested on Netgear DGND3700v2 (bmips/bcm6362) with no regressions.

Tested-By: Álvaro Fernández Rojas 

> El 2 abr 2020, a las 11:28, Daniel Schwierzeck  
> escribió:
> 
> +cc Álvaro
> 
> Am 30.03.20 um 13:58 schrieb Michal Simek:
>> Commit f4dc714aaa2d ("arm64: Turn u-boot.bin back into an ELF file after
>> relocate-rela")
>> introduce REMAKE_ELF option to recreate u-boot.elf from u-boot ->
>> u-boot.bin + DT -> u-boot.elf.
>> 
>> The best is to ilustrate it from make V=1 output
>>  cat u-boot-nodtb.bin dts/dt.dtb > u-boot-dtb.bin
>>  cp u-boot-dtb.bin u-boot.bin
>> aarch64-linux-gnu-objcopy -I binary -B aarch64 -O elf64-littleaarch64  
>> u-boot.bin u-boot-elf.o
>>  aarch64-linux-gnu-ld.bfd u-boot-elf.o -o u-boot.elf 
>> --defsym="_start"=0x800 -Ttext=0x800
>> 
>> Last command has no explicit linker script passed that's why toolchain
>> internal linker script is used.
>> In Binutils 2.32 case it contains SIZEOF_HEADERS symbol which has changed
>> behavior by commit
>> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=64029e93683a266c38d19789e780f3748bd6a188
>> which result in situation that program headers has changed from
>> (xilinx_zynqmp_mini_defconfig)
>> 
>> Program Headers:
>>  Type   Offset VirtAddr   PhysAddr
>> FileSizMemSiz  Flags  Align
>>  LOAD   0x0001 0xfffc 0xfffc
>> 0x00018918 0x00018918  RW 0x1
>> 
>> to
>> 
>> Program Headers:
>>  Type   Offset VirtAddr   PhysAddr
>> FileSizMemSiz  Flags  Align
>>  LOAD   0x 0xfffb 0xfffb
>> 0x00028918 0x00028918  RW 0x1
>> 
>> Xilinx tools like XSDB or Bootgen are using program headers for loading ELF
>> to the right location and by above binutils change ELF is loaded to
>> incorrect location.
>> 
>> The patch is explicitly use u-boot-elf.lds (just cat now) for u-boot.elf
>> recreation which is called when REMAKE_ELF is setup.
>> By purpose u-boot-elf.lds doesn't contain OUTPUT_FORMAT/OUTPUT_ARCH to be
>> able to use by all archs.
>> 
>> Signed-off-by: Michal Simek 
>> ---
>> 
>> Changes in v2:
>> - Use preprocessor and Kconfig entry for passing different PLATFORM_ENTRY
>>  Suggested-by: Daniel Schwierzeck 
>> - I kept u-boot.elf.lds in origin location because most of lds are in arch/
>>  folder
>> 
>> Changes in v1:
>> - Compare to RFC
>> - MIPS has different elf entry point that's why I replaced simple cat with
>>  sed to setup proper entry point
> 
> Álvaro, could you test for regressions on BMIPS platform? Thanks.
> 
> Reviewed-by: Daniel Schwierzeck  >
> 
>> 
>> Sadanand, Mahesh: Please correct my description if I am wrong based on our
>> internal discussion about this issue.
>> 
>> Tom: I have been told that it is GCC issue but I found that commit in
>> binutils.
>> I am not doing these makefile stuff that's why I expect this should be
>> changed a little bit. Also arch/u-boot-elf.lds is likely incorrect location
>> but didn't find any better.
>> 
>> ---
>> Kconfig |  5 +
>> Makefile| 11 +--
>> arch/mips/config.mk |  1 -
>> arch/u-boot-elf.lds |  9 +
>> 4 files changed, 19 insertions(+), 7 deletions(-)
>> create mode 100644 arch/u-boot-elf.lds
>> 
>> diff --git a/Kconfig b/Kconfig
>> index 66148ce47790..dc23c35000f2 100644
>> --- a/Kconfig
>> +++ b/Kconfig
>> @@ -298,6 +298,11 @@ config ERR_PTR_OFFSET
>>pointer values - up to 'MAX_ERRNO' bytes below this value must be
>>unused/invalid addresses.
>> 
>> +config PLATFORM_ELFENTRY
>> +string
>> +default "__start" if MIPS
>> +default "_start"
>> +
>> endmenu  # General setup
>> 
>> menu "Boot images"
>> diff --git a/Makefile b/Makefile
>> index be1513227361..c1dc185e5c0e 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1648,18 +1648,17 @@ OBJCOPYFLAGS_u-boot-img-spl-at-end.bin := -I binary 
>> -O binary \
>> u-boot-img-spl-at-end.bin: u-boot.img spl/u-boot-spl.bin FORCE
>>  $(call if_changed,pad_cat)
>> 
>> -# Create a new ELF from a raw binary file.
>> -ifndef PLATFORM_ELFENTRY
>> -  PLATFORM_ELFENTRY = "_start"
>> -endif
>> quiet_cmd_u-boot-elf ?= LD  $@
>>  cmd_u-boot-elf ?= $(LD) u-boot-elf.o -o $@ \
>> ---defsym=$(PLATFORM_ELFENTRY)=$(CONFIG_SYS_TEXT_BASE) \
>> +-T u-boot-elf.lds 
>> --defsym=$(CONFIG_PLATFORM_ELFENTRY)=$(CONFIG_SYS_TEXT_BASE) \
>>  -Ttext=$(CONFIG_SYS_TEXT_BASE)
>> -u-boot.elf: u-boot.bin
>> +u-boot.elf: u-boot.bin u-boot-elf.lds
>>  $(Q)$(OBJCOPY) -I binary $(PLATFORM_ELFFLAGS) $< u-boot-elf.o
>>  $(call if_changed,u-boot-elf)
>> 
>> +u-boot-elf.lds: arch/u-boot-elf.lds prepare FORCE
>> +$(call if_changed_dep,cpp_lds)
>> +
>> # MediaTek's ARM-based u-boot needs a header to contains its load ad

Re: [PATCH v3 5/5] video: rockchip: Support 4K resolution for rk3399, HDMI

[Kever Yang]

On 2020/4/2 下午7:41, Jagan Teki wrote:

The default resolution for rockchip display is 1920x1080
which failed to work on 4K HDMI out displays on rk3399.

So, mark the default resolution as 3480x2160 for rk3399
HDMI out.

This would work all the hdmi display resolutions till
4K.

Signed-off-by: Jagan Teki 




Reviewed-by: Kever Yang 

Thanks,
- Kever

---
Changes for v3:
- new patch

  drivers/video/rockchip/Kconfig | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/video/rockchip/Kconfig b/drivers/video/rockchip/Kconfig
index 10182d0b66..cfd774ead6 100644
--- a/drivers/video/rockchip/Kconfig
+++ b/drivers/video/rockchip/Kconfig
@@ -22,6 +22,7 @@ menuconfig VIDEO_ROCKCHIP
  config VIDEO_ROCKCHIP_MAX_XRES
  int "Maximum horizontal resolution (for memory allocation purposes)"
depends on VIDEO_ROCKCHIP
+   default 3480 if ROCKCHIP_RK3399 && DISPLAY_ROCKCHIP_HDMI
default 1920
help
  The maximum horizontal resolution to support for the framebuffer.
@@ -31,6 +32,7 @@ config VIDEO_ROCKCHIP_MAX_XRES
  config VIDEO_ROCKCHIP_MAX_YRES
  int "Maximum vertical resolution (for memory allocation purposes)"
depends on VIDEO_ROCKCHIP
+   default 2160 if ROCKCHIP_RK3399 && DISPLAY_ROCKCHIP_HDMI
default 1080
help
  The maximum vertical resolution to support for the framebuffer.

Re: [PATCH v3 4/5] rockchip: Enable HDMI output on rk3399 board w/ HDMI

[Kever Yang]

On 2020/4/2 下午7:41, Jagan Teki wrote:

Enable config options and console setting to respective
rk3399 board for HDMI output.

Boards supported and tested on this patch are:
- NanoPc T4
- NanoPi M4
- NanoPi Neo4
- ROC-RK3399-PC
- Rock960

Cc: Manivannan Sadhasivam 
Signed-off-by: Jagan Teki 




Reviewed-by: Kever Yang 

Thanks,
- Kever

---
Changes for v3:
- add rock960 hdmi out support

  configs/nanopc-t4-rk3399_defconfig   | 7 +++
  configs/nanopi-m4-rk3399_defconfig   | 7 +++
  configs/nanopi-neo4-rk3399_defconfig | 7 +++
  configs/roc-pc-rk3399_defconfig  | 6 ++
  configs/rock960-rk3399_defconfig | 7 +++
  include/configs/evb_rk3399.h | 5 +
  include/configs/rock960_rk3399.h | 5 +
  7 files changed, 44 insertions(+)

diff --git a/configs/nanopc-t4-rk3399_defconfig 
b/configs/nanopc-t4-rk3399_defconfig
index 9ea9b11574..607a00dbf7 100644
--- a/configs/nanopc-t4-rk3399_defconfig
+++ b/configs/nanopc-t4-rk3399_defconfig
@@ -52,5 +52,12 @@ CONFIG_USB_ETHER_ASIX88179=y
  CONFIG_USB_ETHER_MCS7830=y
  CONFIG_USB_ETHER_RTL8152=y
  CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USB_KEYBOARD=y
  CONFIG_SPL_TINY_MEMSET=y
  CONFIG_ERRNO_STR=y
+CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_BPP16=y
+CONFIG_VIDEO_BPP32=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
diff --git a/configs/nanopi-m4-rk3399_defconfig 
b/configs/nanopi-m4-rk3399_defconfig
index ad0e808bf6..3fcb7ac2d7 100644
--- a/configs/nanopi-m4-rk3399_defconfig
+++ b/configs/nanopi-m4-rk3399_defconfig
@@ -52,5 +52,12 @@ CONFIG_USB_ETHER_ASIX88179=y
  CONFIG_USB_ETHER_MCS7830=y
  CONFIG_USB_ETHER_RTL8152=y
  CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USB_KEYBOARD=y
  CONFIG_SPL_TINY_MEMSET=y
  CONFIG_ERRNO_STR=y
+CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_BPP16=y
+CONFIG_VIDEO_BPP32=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
diff --git a/configs/nanopi-neo4-rk3399_defconfig 
b/configs/nanopi-neo4-rk3399_defconfig
index d038a8cab9..b9ea535e43 100644
--- a/configs/nanopi-neo4-rk3399_defconfig
+++ b/configs/nanopi-neo4-rk3399_defconfig
@@ -52,5 +52,12 @@ CONFIG_USB_ETHER_ASIX88179=y
  CONFIG_USB_ETHER_MCS7830=y
  CONFIG_USB_ETHER_RTL8152=y
  CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USB_KEYBOARD=y
  CONFIG_SPL_TINY_MEMSET=y
  CONFIG_ERRNO_STR=y
+CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_BPP16=y
+CONFIG_VIDEO_BPP32=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig
index d540a17aeb..be76524cef 100644
--- a/configs/roc-pc-rk3399_defconfig
+++ b/configs/roc-pc-rk3399_defconfig
@@ -59,3 +59,9 @@ CONFIG_USB_ETHER_SMSC95XX=y
  CONFIG_USB_KEYBOARD=y
  CONFIG_SPL_TINY_MEMSET=y
  CONFIG_ERRNO_STR=y
+CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_BPP16=y
+CONFIG_VIDEO_BPP32=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
diff --git a/configs/rock960-rk3399_defconfig b/configs/rock960-rk3399_defconfig
index ba4226e173..c4e954731a 100644
--- a/configs/rock960-rk3399_defconfig
+++ b/configs/rock960-rk3399_defconfig
@@ -58,5 +58,12 @@ CONFIG_USB_ETHER_ASIX88179=y
  CONFIG_USB_ETHER_MCS7830=y
  CONFIG_USB_ETHER_RTL8152=y
  CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USB_KEYBOARD=y
  CONFIG_SPL_TINY_MEMSET=y
  CONFIG_ERRNO_STR=y
+CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_BPP16=y
+CONFIG_VIDEO_BPP32=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
diff --git a/include/configs/evb_rk3399.h b/include/configs/evb_rk3399.h
index c0b0358893..2d3db22877 100644
--- a/include/configs/evb_rk3399.h
+++ b/include/configs/evb_rk3399.h
@@ -6,6 +6,11 @@
  #ifndef __EVB_RK3399_H
  #define __EVB_RK3399_H
  
+#define ROCKCHIP_DEVICE_SETTINGS \

+   "stdin=serial,usbkbd\0" \
+   "stdout=serial,vidconsole\0" \
+   "stderr=serial,vidconsole\0"
+
  #include 
  
  #if defined(CONFIG_ENV_IS_IN_MMC)

diff --git a/include/configs/rock960_rk3399.h b/include/configs/rock960_rk3399.h
index 746d24cbff..304ad2b7aa 100644
--- a/include/configs/rock960_rk3399.h
+++ b/include/configs/rock960_rk3399.h
@@ -6,6 +6,11 @@
  #ifndef __ROCK960_RK3399_H
  #define __ROCK960_RK3399_H
  
+#define ROCKCHIP_DEVICE_SETTINGS \

+   "stdin=serial,usbkbd\0" \
+   "stdout=serial,vidconsole\0" \
+   "stderr=serial,vidconsole\0"
+
  #include 
  
  #define CONFIG_SYS_MMC_ENV_DEV		1

Re: [PATCH v3 3/5] rockchip: Enable pre console for rk3399

[Kever Yang]

On 2020/4/2 下午7:41, Jagan Teki wrote:

Enable pre console buffer for rk3399 platform.

This would help to capture the console messages prior to
the console being initialised. Enabling this would help
to capture all the console messages on video output source
like HDMI. So we can find the full console messages of
U-Boot proper on HDMI display when enabled it for RK3399
platform boards.

Buffer address used for pre console is 0x0f20 which is
ram base plus 240MiB. right now the Allwinner SoC is using
similar computation.

Signed-off-by: Jagan Teki 




Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/mach-rockchip/Kconfig | 1 +
  common/Kconfig | 1 +
  2 files changed, 2 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index ed7514ab75..0cb1f23d0f 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -229,6 +229,7 @@ config ROCKCHIP_RK3399
select DM_PMIC
select DM_REGULATOR_FIXED
select BOARD_LATE_INIT
+   imply PRE_CONSOLE_BUFFER
imply ROCKCHIP_COMMON_BOARD
imply ROCKCHIP_SDRAM_COMMON
imply SPL_ROCKCHIP_COMMON_BOARD
diff --git a/common/Kconfig b/common/Kconfig
index 46e4193fc8..bd35de3056 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -568,6 +568,7 @@ config PRE_CON_BUF_ADDR
default 0x2f00 if ARCH_SUNXI && MACH_SUN9I
default 0x4f00 if ARCH_SUNXI && !MACH_SUN9I
default 0x0f00 if ROCKCHIP_RK3288
+   default 0x0f20 if ROCKCHIP_RK3399
help
  This sets the start address of the pre-console buffer. This must
  be in available memory and is accessed before relocation and

Re: [PATCH v3 2/5] video: rockchip: Fix vop modes for rk3399

[Kever Yang]

On 2020/4/2 下午7:41, Jagan Teki wrote:

VOP display endpoint pipeline configuration is differs
between rk3288 vs rk3399.

These VOP pipeline configuration depends on how the
different display interfaces connected in sequence to
IN and OUT ports like for,

RK3288:

vopb_out: port {
#address-cells = <1>;
#size-cells = <0>;
vopb_out_edp: endpoint@0 {
reg = <0>;
remote-endpoint = <&edp_in_vopb>;
};
vopb_out_hdmi: endpoint@1 {
reg = <1>;
 remote-endpoint = <&hdmi_in_vopb>;
 };
 vopb_out_lvds: endpoint@2 {
 reg = <2>;
 remote-endpoint = <&lvds_in_vopb>;
 };
 vopb_out_mipi: endpoint@3 {
 reg = <3>;
 remote-endpoint = <&mipi_in_vopb>;
 };
};

RK3399:

vopb_out: port {
  #address-cells = <1>;
  #size-cells = <0>;
  vopb_out_edp: endpoint@0 {
 reg = <0>;
 remote-endpoint = <&edp_in_vopb>;
  };
  vopb_out_mipi: endpoint@1 {
 reg = <1>;
 remote-endpoint = <&mipi_in_vopb>;
  };
  vopb_out_hdmi: endpoint@2 {
 reg = <2>;
 remote-endpoint = <&hdmi_in_vopb>;
  };
  vopb_out_mipi1: endpoint@3 {
 reg = <3>;
 remote-endpoint = <&mipi1_in_vopb>;
  };
  vopb_out_dp: endpoint@4 {
 reg = <4>;
 remote-endpoint = <&dp_in_vopb>;
  };
};

here, HDMI interface has endpoint 1 in rk3288 and 2 in rk3399.

The rockchip vop driver often depends on this determined endpoint
number and stored in vop_mode. So based on this vop_mode the bpp
and pin polarity would configure on detected display interface.

Since, the existing driver using rk3288 vop mode settings enabling
the same will result wrong display interface configuration for rk3399.

Add the patch for fixing these vop modes for rk3399.

Signed-off-by: Jagan Teki 




Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  arch/arm/include/asm/arch-rockchip/vop_rk3288.h | 11 +++
  drivers/video/rockchip/rk3399_vop.c |  2 --
  drivers/video/rockchip/rk_vop.c |  4 
  3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/vop_rk3288.h 
b/arch/arm/include/asm/arch-rockchip/vop_rk3288.h
index 8398249509..872a158b71 100644
--- a/arch/arm/include/asm/arch-rockchip/vop_rk3288.h
+++ b/arch/arm/include/asm/arch-rockchip/vop_rk3288.h
@@ -85,6 +85,16 @@ enum {
LB_RGB_1280X8 = 0x5
  };
  
+#if defined(CONFIG_ROCKCHIP_RK3399)

+enum vop_modes {
+   VOP_MODE_EDP = 0,
+   VOP_MODE_MIPI,
+   VOP_MODE_HDMI,
+   VOP_MODE_MIPI1,
+   VOP_MODE_DP,
+   VOP_MODE_NONE,
+};
+#else
  enum vop_modes {
VOP_MODE_EDP = 0,
VOP_MODE_HDMI,
@@ -94,6 +104,7 @@ enum vop_modes {
VOP_MODE_AUTO_DETECT,
VOP_MODE_UNKNOWN,
  };
+#endif
  
  /* VOP_VERSION_INFO */

  #define M_FPGA_VERSION (0x << 16)
diff --git a/drivers/video/rockchip/rk3399_vop.c 
b/drivers/video/rockchip/rk3399_vop.c
index 81c122d7a9..1d5b3931a6 100644
--- a/drivers/video/rockchip/rk3399_vop.c
+++ b/drivers/video/rockchip/rk3399_vop.c
@@ -45,8 +45,6 @@ static void rk3399_set_pin_polarity(struct udevice *dev,
V_RK3399_DSP_MIPI_POL(polarity));
break;
  
-	case VOP_MODE_LVDS:

-   /* The RK3399 has neither parallel RGB nor LVDS output. */
default:
debug("%s: unsupported output mode %x\n", __func__, mode);
}
diff --git a/drivers/video/rockchip/rk_vop.c b/drivers/video/rockchip/rk_vop.c
index e91d4dfa7f..e1bd656bee 100644
--- a/drivers/video/rockchip/rk_vop.c
+++ b/drivers/video/rockchip/rk_vop.c
@@ -118,10 +118,12 @@ static void rkvop_enable_output(struct udevice *dev, enum 
vop_modes mode)
V_EDP_OUT_EN(1));
break;
  
+#if defined(CONFIG_ROCKCHIP_RK3288)

case VOP_MODE_LVDS:
clrsetbits_le32(®s->sys_ctrl, M_ALL_OUT_EN,
V_RGB_OUT_EN(1));
break;
+#endif
  
  	case VOP_MODE_MIPI:

clrsetbits_le32(®s->sys_ctrl, M_ALL_OUT_EN,
@@ -313,7 +315,9 @@ static int rk_display_init(struct udevice *dev, ulong 
fbbase, ofnode ep_node)
/* Set bitwidth for vop display according to vop mode */
switch (vop_id) {
case VOP_MODE_EDP:
+#if defined(CONFIG_ROCKCHIP_RK3288)
case VOP_MODE_LVDS:
+#endif
l2bpp = VIDEO_BPP16;
break;
case VOP_MODE_HDMI:

Re: [PATCH v3 1/5] clk: rk3399: Set empty for vopl assigned-clocks

[Kever Yang]

On 2020/4/2 下午7:41, Jagan Teki wrote:

During vidconsole probe, the device probe will try to
check whether the assigned clocks on that video console
node is initialized or not? and return an error if not.

But, unlike Linux U-Boot won't require to handle these
vopl assigned-clocks since core clocks are enough to
handle the video out to process.

So, mark them as empty in set_rate to satisfy clk_set_defaults
so-that probe happened properly.

Signed-off-by: Jagan Teki 




Reviewed-by: Kever Yang 

Thanks,
- Kever

---
Changes for v3:
- new patch

  drivers/clk/rockchip/clk_rk3399.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index 865b80cc0f..1f62376595 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -994,6 +994,13 @@ static ulong rk3399_clk_set_rate(struct clk *clk, ulong 
rate)
case DCLK_VOP1:
ret = rk3399_vop_set_clk(priv->cru, clk->id, rate);
break;
+   case ACLK_VOP1:
+   case HCLK_VOP1:
+   /**
+* assigned-clocks handling won't require for vopl, so
+* return 0 to satisfy clk_set_defaults during device probe.
+*/
+   return 0;
case SCLK_DDRCLK:
ret = rk3399_ddr_set_clk(priv->cru, rate);
break;

Re: [PATCH v2 1/2] serial: ns16550: Revert "Move PCI access from ofdata_to_platdata() to probe()"

[Tom Rini]

On Thu, Apr 02, 2020 at 12:55:14PM +0800, Bin Meng wrote:
> Hi Simon, Andy,
> 
> On Thu, Apr 2, 2020 at 1:55 AM Simon Glass  wrote:
> >
> > Hi Andy,
> >
> > On Wed, 1 Apr 2020 at 11:39, Andy Shevchenko  
> > wrote:
> > >
> > > On Wed, Apr 01, 2020 at 10:56:26AM -0600, Simon Glass wrote:
> > > > Hi Andy,
> > > >
> > > > On Wed, 1 Apr 2020 at 08:45, Andy Shevchenko 
> > > >  wrote:
> > > > >
> > > > > On Wed, Apr 1, 2020 at 5:32 PM Bin Meng  wrote:
> > > > > > On Wed, Apr 1, 2020 at 9:58 PM Andy Shevchenko
> > > > > >  wrote:
> > > > > > >
> > > > > > > The commit breaks serial console on the Intel Edison.
> > > > > > >
> > > > > > > This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c.
> > > > > > >
> > > > > > > Signed-off-by: Andy Shevchenko 
> > > > > > > ---
> > > > > > >  drivers/serial/ns16550.c | 40 
> > > > > > > 
> > > > > > >  1 file changed, 12 insertions(+), 28 deletions(-)
> > > > > > >
> > > > > >
> > > > > > Could you please spend some time to investigate why this breaks 
> > > > > > Intel Edison?
> > > > > >
> > > > > > Reverting this patch would mean we break other boards too as
> > > > > > Wolfgang's patch wanted to fix the breakage in the first place. Much
> > > > > > appreciated!
> > > > >
> > > > > I guess I'm wrong person here. The DM code is a complete black box to 
> > > > > me.
> > > > > Nevertheless, I may test any provided fix / debug / etc patch by 
> > > > > request.
> > > > >
> > > > > And I think it's fair to investigate by the one who made a regression
> > > > > in the first place.
> > > >
> > > > Given that we have conflicting breakages, we need to debug Edison.
> > >
> > > I would glad to test any suggested change or debug patch!
> > >
> > > > Does it enable the debug UART?
> > >
> > > If I am not mistaken, it does not.
> >
> > Looks like you are right. If you know the address you could do that -
> > see minnowmax for an example.
> 
> Please suggest what's the best approach to proceed.

Adding SoCFPGA folks to this thread as the first commit (82de42fa1468)
is also breaking platforms there and then their fix for that problem is
also causing problems, if I follow right.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 0/5] rockchip: rk3399: Fix HDMI out

[Peter Robinson]

On Thu, Apr 2, 2020 at 12:41 PM Jagan Teki  wrote:
>
> Due to recent Linux dts(i) sync for rk3399. the existing
> vop driver is not working with HDMI out on RK3399.
>
> This is v3 patchset, for previous version fixes[1].
>
> Changes for v3:
> - handle vopl clks in clk driver
> - drop dts changes
> - fix 4K display out for rk3399
> Changes for v2:
> - use usbkbd as stdin
> - enable USB Keyboard
>
> [1] https://patchwork.ozlabs.org/cover/1264187/
>
> Any inputs?

This series works for me for display output on the Rock960, I had
tried one of the prior versions with it (I think v1) and it had caused
issues but the display comes up and outputs on HDMI for me so:
Tested-by: Peter Robinson 

> Jagan.
>
> Jagan Teki (5):
>   clk: rk3399: Set empty for vopl assigned-clocks
>   video: rockchip: Fix vop modes for rk3399
>   rockchip: Enable pre console for rk3399
>   rockchip: Enable HDMI output on rk3399 board w/ HDMI
>   video: rockchip: Support 4K resolution for rk3399, HDMI
>
>  arch/arm/include/asm/arch-rockchip/vop_rk3288.h | 11 +++
>  arch/arm/mach-rockchip/Kconfig  |  1 +
>  common/Kconfig  |  1 +
>  configs/nanopc-t4-rk3399_defconfig  |  7 +++
>  configs/nanopi-m4-rk3399_defconfig  |  7 +++
>  configs/nanopi-neo4-rk3399_defconfig|  7 +++
>  configs/roc-pc-rk3399_defconfig |  6 ++
>  configs/rock960-rk3399_defconfig|  7 +++
>  drivers/clk/rockchip/clk_rk3399.c   |  7 +++
>  drivers/video/rockchip/Kconfig  |  2 ++
>  drivers/video/rockchip/rk3399_vop.c |  2 --
>  drivers/video/rockchip/rk_vop.c |  4 
>  include/configs/evb_rk3399.h|  5 +
>  include/configs/rock960_rk3399.h|  5 +
>  14 files changed, 70 insertions(+), 2 deletions(-)
>
> --
> 2.17.1
>

Re: [PATCH v3 4/5] rockchip: Enable HDMI output on rk3399 board w/ HDMI

[Peter Robinson]

> Enable config options and console setting to respective
> rk3399 board for HDMI output.
>
> Boards supported and tested on this patch are:
> - NanoPc T4
> - NanoPi M4
> - NanoPi Neo4
> - ROC-RK3399-PC
> - Rock960
>
> Cc: Manivannan Sadhasivam 
> Signed-off-by: Jagan Teki 
Tested-by: Peter Robinson 

Tested on the Rock960 rev 1.2, I'm guessing the firefly-rk3399 should
be able to be enabled in a similar manner, will try and test that as
well when I get a moment.

> ---
> Changes for v3:
> - add rock960 hdmi out support
>
>  configs/nanopc-t4-rk3399_defconfig   | 7 +++
>  configs/nanopi-m4-rk3399_defconfig   | 7 +++
>  configs/nanopi-neo4-rk3399_defconfig | 7 +++
>  configs/roc-pc-rk3399_defconfig  | 6 ++
>  configs/rock960-rk3399_defconfig | 7 +++
>  include/configs/evb_rk3399.h | 5 +
>  include/configs/rock960_rk3399.h | 5 +
>  7 files changed, 44 insertions(+)
>
> diff --git a/configs/nanopc-t4-rk3399_defconfig 
> b/configs/nanopc-t4-rk3399_defconfig
> index 9ea9b11574..607a00dbf7 100644
> --- a/configs/nanopc-t4-rk3399_defconfig
> +++ b/configs/nanopc-t4-rk3399_defconfig
> @@ -52,5 +52,12 @@ CONFIG_USB_ETHER_ASIX88179=y
>  CONFIG_USB_ETHER_MCS7830=y
>  CONFIG_USB_ETHER_RTL8152=y
>  CONFIG_USB_ETHER_SMSC95XX=y
> +CONFIG_USB_KEYBOARD=y
>  CONFIG_SPL_TINY_MEMSET=y
>  CONFIG_ERRNO_STR=y
> +CONFIG_DM_VIDEO=y
> +CONFIG_VIDEO_BPP16=y
> +CONFIG_VIDEO_BPP32=y
> +CONFIG_DISPLAY=y
> +CONFIG_VIDEO_ROCKCHIP=y
> +CONFIG_DISPLAY_ROCKCHIP_HDMI=y
> diff --git a/configs/nanopi-m4-rk3399_defconfig 
> b/configs/nanopi-m4-rk3399_defconfig
> index ad0e808bf6..3fcb7ac2d7 100644
> --- a/configs/nanopi-m4-rk3399_defconfig
> +++ b/configs/nanopi-m4-rk3399_defconfig
> @@ -52,5 +52,12 @@ CONFIG_USB_ETHER_ASIX88179=y
>  CONFIG_USB_ETHER_MCS7830=y
>  CONFIG_USB_ETHER_RTL8152=y
>  CONFIG_USB_ETHER_SMSC95XX=y
> +CONFIG_USB_KEYBOARD=y
>  CONFIG_SPL_TINY_MEMSET=y
>  CONFIG_ERRNO_STR=y
> +CONFIG_DM_VIDEO=y
> +CONFIG_VIDEO_BPP16=y
> +CONFIG_VIDEO_BPP32=y
> +CONFIG_DISPLAY=y
> +CONFIG_VIDEO_ROCKCHIP=y
> +CONFIG_DISPLAY_ROCKCHIP_HDMI=y
> diff --git a/configs/nanopi-neo4-rk3399_defconfig 
> b/configs/nanopi-neo4-rk3399_defconfig
> index d038a8cab9..b9ea535e43 100644
> --- a/configs/nanopi-neo4-rk3399_defconfig
> +++ b/configs/nanopi-neo4-rk3399_defconfig
> @@ -52,5 +52,12 @@ CONFIG_USB_ETHER_ASIX88179=y
>  CONFIG_USB_ETHER_MCS7830=y
>  CONFIG_USB_ETHER_RTL8152=y
>  CONFIG_USB_ETHER_SMSC95XX=y
> +CONFIG_USB_KEYBOARD=y
>  CONFIG_SPL_TINY_MEMSET=y
>  CONFIG_ERRNO_STR=y
> +CONFIG_DM_VIDEO=y
> +CONFIG_VIDEO_BPP16=y
> +CONFIG_VIDEO_BPP32=y
> +CONFIG_DISPLAY=y
> +CONFIG_VIDEO_ROCKCHIP=y
> +CONFIG_DISPLAY_ROCKCHIP_HDMI=y
> diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig
> index d540a17aeb..be76524cef 100644
> --- a/configs/roc-pc-rk3399_defconfig
> +++ b/configs/roc-pc-rk3399_defconfig
> @@ -59,3 +59,9 @@ CONFIG_USB_ETHER_SMSC95XX=y
>  CONFIG_USB_KEYBOARD=y
>  CONFIG_SPL_TINY_MEMSET=y
>  CONFIG_ERRNO_STR=y
> +CONFIG_DM_VIDEO=y
> +CONFIG_VIDEO_BPP16=y
> +CONFIG_VIDEO_BPP32=y
> +CONFIG_DISPLAY=y
> +CONFIG_VIDEO_ROCKCHIP=y
> +CONFIG_DISPLAY_ROCKCHIP_HDMI=y
> diff --git a/configs/rock960-rk3399_defconfig 
> b/configs/rock960-rk3399_defconfig
> index ba4226e173..c4e954731a 100644
> --- a/configs/rock960-rk3399_defconfig
> +++ b/configs/rock960-rk3399_defconfig
> @@ -58,5 +58,12 @@ CONFIG_USB_ETHER_ASIX88179=y
>  CONFIG_USB_ETHER_MCS7830=y
>  CONFIG_USB_ETHER_RTL8152=y
>  CONFIG_USB_ETHER_SMSC95XX=y
> +CONFIG_USB_KEYBOARD=y
>  CONFIG_SPL_TINY_MEMSET=y
>  CONFIG_ERRNO_STR=y
> +CONFIG_DM_VIDEO=y
> +CONFIG_VIDEO_BPP16=y
> +CONFIG_VIDEO_BPP32=y
> +CONFIG_DISPLAY=y
> +CONFIG_VIDEO_ROCKCHIP=y
> +CONFIG_DISPLAY_ROCKCHIP_HDMI=y
> diff --git a/include/configs/evb_rk3399.h b/include/configs/evb_rk3399.h
> index c0b0358893..2d3db22877 100644
> --- a/include/configs/evb_rk3399.h
> +++ b/include/configs/evb_rk3399.h
> @@ -6,6 +6,11 @@
>  #ifndef __EVB_RK3399_H
>  #define __EVB_RK3399_H
>
> +#define ROCKCHIP_DEVICE_SETTINGS \
> +   "stdin=serial,usbkbd\0" \
> +   "stdout=serial,vidconsole\0" \
> +   "stderr=serial,vidconsole\0"
> +
>  #include 
>
>  #if defined(CONFIG_ENV_IS_IN_MMC)
> diff --git a/include/configs/rock960_rk3399.h 
> b/include/configs/rock960_rk3399.h
> index 746d24cbff..304ad2b7aa 100644
> --- a/include/configs/rock960_rk3399.h
> +++ b/include/configs/rock960_rk3399.h
> @@ -6,6 +6,11 @@
>  #ifndef __ROCK960_RK3399_H
>  #define __ROCK960_RK3399_H
>
> +#define ROCKCHIP_DEVICE_SETTINGS \
> +   "stdin=serial,usbkbd\0" \
> +   "stdout=serial,vidconsole\0" \
> +   "stderr=serial,vidconsole\0"
> +
>  #include 
>
>  #define CONFIG_SYS_MMC_ENV_DEV 1
> --
> 2.17.1
>

Re: [PATCH 09/16] efi_loader: imply FAT, FAT_WRITE

[Ilias Apalodimas]

On Wed, Apr 01, 2020 at 04:04:04PM +0900, AKASHI Takahiro wrote:
> > 
[...]
> > Yes, we may add further stores later on.
> 
> Why not now?
> How will you generalize it?
> 
> > Ilias wants to use the RPMB
> > area of eMMC devices.
> 
> I think that he plans to use RPMB as secure storage for Standalone MM.

Sorry for my really delayed replies, but I was over my head with EDK2 and RPMB
indeed :)
So my implementation is orthogonal to this patchset and I do have some code that
write UEFI variables on an RPMB via OP-TEE. 
> 
> > As an EFI system partition exists on any UEFI
> > compatible device I think implementing this first is a valid approach.
> 
> I don't deny your approach here, but
> I expect that more generic framework for back storage be
> implemented and FAT driver be on top of that.
> 
Akashi has a point here. On the other hand can't we just make the store a
callback in the future?
So for example is FAT_FS support is not included, we write the data into raw
flash sectors or a file.
That being said EDK2 uses Fvb and Fault Tolerant Writes to write the actual UEFI
variables. So you end up needing 3 partitions for the actual storage.  The
question here is should we implement something similar to u-boot EFI code since
this is only supposed to serve as a 'fallback'? If the board has OP-TEE then
that will be responsible for writing the variables (and it will use whatever
EDK2 uses).

I'll have a closer look to the patchset and try to give some feedback.

Regards
/Ilias
> -Takahiro Akashi
> 
> > 
> > Best regards
> > 
> > Heinrich
> > 
> > >
> > > -Takahiro Akashi
> > >
> > >> -Takahiro Akashi
> > >>
> > >>> Best regards
> > >>>
> > >>> Heinrich
> > >>>
> > 
> > >>
> > >> In addition, why do you treat FAT specifically here?
> > >> I remember that you insisted that other file system should be
> > >> allowed on U-Boot when I posted some patch.
> > >
> > > An EFI system partition is always FAT formatted. So if we want to safe
> > > U-Boot variables to the EFI system partition we require FAT.
> > 
> >  As system partition is required to be in FAT, file system used on
> >  other partitions must also be in FAT since, as I said before,
> >  UEFI specification clearly defines its file system format based on FAT.
> >  See section 13.3.
> > 
> >  So,
> > 
> > >> I remember that you insisted that other file system should be
> > >> allowed on U-Boot when I posted some patch.
> > 
> >  You reverted your statement above here.
> >  That is my point.
> > 
> >  -Takahiro Akashi
> > 
> > > Best regards
> > >
> > > Heinrich
> > >
> > >>
> > >> -Takahiro Akashi
> > >>
> > >>
> > >>> imply USB_KEYBOARD_FN_KEYS
> > >>> imply VIDEO_ANSI
> > >>> help
> > >>> --
> > >>> 2.25.1
> > >>>
> > 

Re: [PATCH v1 3/8] spi: dw: Rename "cs-gpio" to "cs-gpios"

[Sean Anderson]

On 4/2/20 8:17 AM, Jagan Teki wrote:
> On Fri, Mar 6, 2020 at 12:49 AM Sean Anderson  wrote:
>>
>> This property is named differently than other SPI drivers with the same
>> property, as well as the property as used in Linux.
>>
>> Signed-off-by: Sean Anderson 
>> ---
>>
>>  arch/arc/dts/axs10x_mb.dtsi  |  3 ++-
>>  arch/arc/dts/hsdk.dts|  3 ++-
>>  drivers/spi/designware_spi.c | 10 +++---
> 
> Better separate the dts changes and add sha1 from Linux if it synced.
> 

This is not from a specific patch; I just noticed that it was different
and changed it. I think it is clearer to include dts changes with the
code change. That way if someone is reviewing the device tree, it is
obvious why the change was made. Splitting the changes would also make
the code not run properly for the intermediate commit. This can be
annoying when bisecting. However, if you would still like it split, I
can do that.

--Sean

Re: [PATCH v1 4/8] spi: dw: Use generic function to read reg address

[Sean Anderson]

On 4/2/20 8:24 AM, Jagan Teki wrote:
> On Fri, Mar 6, 2020 at 12:49 AM Sean Anderson  wrote:
>>
>> Using an fdt-specific function causes problems when compiled with a live
>> tree.
>>
>> Signed-off-by: Sean Anderson 
>> ---
>>
>>  drivers/spi/designware_spi.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
>> index 765fa2f582..38c24fe550 100644
>> --- a/drivers/spi/designware_spi.c
>> +++ b/drivers/spi/designware_spi.c
>> @@ -161,7 +161,9 @@ static int dw_spi_ofdata_to_platdata(struct udevice *bus)
>>  {
>> struct dw_spi_platdata *plat = bus->platdata;
>>
>> -   plat->regs = (struct dw_spi *)devfdt_get_addr(bus);
>> +   plat->regs = dev_read_addr_ptr(bus);
>> +   if (!plat->regs)
>> +   return -EINVAL;
> 
> Better check the returned regs with FDT_ADDR_T_NONE
> 

This series depends on the series for k210 support which includes the
patch "dm: Fix error handling for dev_read_addr_ptr" [1]. This patch changes
the semantics for that function to be consistent regardless of whether a
live device tree is in use.

[1] https://patchwork.ozlabs.org/patch/1258450/

--Sean

Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash support

[Bin Meng]

Hi Jagan,

On Mon, Nov 18, 2019 at 10:49 AM Bin Meng  wrote:
>
> Hi Segar Kadam,
>
> On Mon, Nov 18, 2019 at 4:59 AM Sagar Kadam  wrote:
> >
> >
> > Hello Jagan/Bin,
> >
> > > -Original Message-
> > > From: U-Boot  On Behalf Of Bin Meng
> > > Sent: Monday, November 11, 2019 8:02 PM
> > > To: Jagan Teki 
> > > Cc: Palmer Dabbelt ( Sifive) ; U-Boot Mailing List  > > b...@lists.denx.de>; linux-amarula 
> > > Subject: Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash
> > > support
> > >
> > > Hi Jagan,
> > >
> > > On Sat, Nov 9, 2019 at 7:57 PM Jagan Teki 
> > > wrote:
> > > >
> > > > Hi Bin,
> > > >
> > > > On Tue, Oct 29, 2019 at 3:50 PM Bin Meng  wrote:
> > > > >
> > > > > Hi Jagan,
> > > > >
> > > > > On Tue, Oct 29, 2019 at 5:38 PM Bin Meng 
> > > wrote:
> > > > > >
> > > > > > Hi Jagan,
> > > > > >
> > > > > > On Wed, Oct 16, 2019 at 10:58 PM Jagan Teki
> > >  wrote:
> > > > > > >
> > > > > > > HiFive Unleashed A00 support is25wp256 spi-nor flash,
> > > > > > > So enable the same and add test result log for future
> > > > > > > reference.
> > > > > > >
> > > > > > > Tested on SiFive FU540 board.
> > > > > > >
> > > > > > > Signed-off-by: Jagan Teki 
> > > > > > > Reviewed-by: Bin Meng 
> > > > > > > Tested-by: Bin Meng 
> > > > > > > ---
> > > > > > >  .../dts/hifive-unleashed-a00-u-boot.dtsi  |  1 +
> > > > > > >  board/sifive/fu540/Kconfig|  3 +++
> > > > > > >  doc/board/sifive/fu540.rst| 19 
> > > > > > > +++
> > > > > > >  3 files changed, 23 insertions(+)
> > > > > > >
> > > > > > > diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > > > > index 25ec8265a5..d7a64134db 100644
> > > > > > > --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > > > > +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > > > > > @@ -5,6 +5,7 @@
> > > > > > >
> > > > > > >  / {
> > > > > > > aliases {
> > > > > > > +   spi0 = &qspi0;
> > > > > > > spi2 = &qspi2;
> > > > > > > };
> > > > > > >  };
> > > > > > > diff --git a/board/sifive/fu540/Kconfig 
> > > > > > > b/board/sifive/fu540/Kconfig
> > > > > > > index 5d65080429..c5a1bca03c 100644
> > > > > > > --- a/board/sifive/fu540/Kconfig
> > > > > > > +++ b/board/sifive/fu540/Kconfig
> > > > > > > @@ -26,6 +26,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> > > > > > > imply CMD_FS_GENERIC
> > > > > > > imply CMD_NET
> > > > > > > imply CMD_PING
> > > > > > > +   imply CMD_SF
> > > > > > > imply CLK_SIFIVE
> > > > > > > imply CLK_SIFIVE_FU540_PRCI
> > > > > > > imply DOS_PARTITION
> > > > > > > @@ -40,6 +41,8 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> > > > > > > imply SIFIVE_SERIAL
> > > > > > > imply SPI
> > > > > > > imply SPI_SIFIVE
> > > > > > > +   imply SPI_FLASH
> > > > > > > +   imply SPI_FLASH_ISSI
> > > > > > > imply MMC
> > > > > > > imply MMC_SPI
> > > > > > > imply MMC_BROKEN_CD
> > > > > > > diff --git a/doc/board/sifive/fu540.rst 
> > > > > > > b/doc/board/sifive/fu540.rst
> > > > > > > index 91b94ee06f..2e70cad02e 100644
> > > > > > > --- a/doc/board/sifive/fu540.rst
> > > > > > > +++ b/doc/board/sifive/fu540.rst
> > > > > > > @@ -366,3 +366,22 @@ load uImage.
> > > > > > >
> > > > > > > Please press Enter to activate this console.
> > > > > > > / #
> > > > > > > +
> > > > > > > +Sample spi nor flash test
> > > > > > > +-
> > > > > > > +
> > > > > > > +.. code-block:: none
> > > > > > > +
> > > > > > > +   => sf probe 0:2
> > > > > >
> > > > > > The cs number can't be 2. It should be zero.
> > > > >
> > > > > With this patch series, we got crazy duplicated flash devices created,
> > > > > see below:
> > > > >
> > > > > => sf probe
> > > > > unrecognized JEDEC id bytes: ff, ff, ff
> > > > > Failed to initialize SPI flash at 0:0 (error -2)
> > > > > => sf probe 0:2
> > > > > SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, 
> > > > > total 32
> > > MiB
> > > > > => sf probe 0:4
> > > > > SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, 
> > > > > total 32
> > > MiB
> > > > > => sf probe 0:6
> > > > > SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, 
> > > > > total 32
> > > MiB
> > > > > => dm tree
> > > > >  Class Index  Probed  DriverName
> > > > > ---
> > > > >  root  0  [ + ]   root_driver   root_driver
> > > > >  simple_bus0  [ + ]   generic_simple_bus|-- soc
> > > > >  clk   0  [ + ]   sifive-fu540-prci |   |--
> > > > > clock-controller@1000
> > > > >  serial0  [ + ]   serial_sifive |   |-- 
> > > > > serial@1001
> > > > >  serial1  [   ]   serial_sifive |   |-- 
> > > > > serial@10011000
> > > > >  spi

Re: [PATCH] Revert "board: roc-pc-rk3399: Add support for onboard LED's and push button to indicate power mode"

[Kever Yang]

Hi Suniel,

    Please use a new patch instead of 'Revert'.

BTW: please add 'rockchip:' at the beginning of the patch subject.


Thanks,

- Kever

On 2020/4/2 下午7:57, su...@amarulasolutions.com wrote:

From: Suniel Mahesh 

In case of a power interruption, human intervention is required which
is not desirable if the device is installed at a remote location. Keep
red LED as it is to indicate board in full power mode.

This reverts partially the commit 5a6d3d1fbca70d7f528c685292d64c4cd0106aa6.

Signed-off-by: Suniel Mahesh 
---
Note:
- patch tested on rk3399-roc-pc
- code related to button press is removed
---
  board/firefly/roc-pc-rk3399/roc-pc-rk3399.c | 16 +---
  1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c 
b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
index de9185a..0fe1914 100644
--- a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
+++ b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
@@ -10,7 +10,6 @@
  #include 
  #include 
  #include 
-#include 
  
  #ifndef CONFIG_SPL_BUILD

  int board_early_init_f(void)
@@ -34,26 +33,13 @@ out:
  
  #if defined(CONFIG_TPL_BUILD)
  
-#define PMUGRF_BASE 0xff32

  #define GPIO0_BASE  0xff72
  
  int board_early_init_f(void)

  {
struct rockchip_gpio_regs * const gpio0 = (void *)GPIO0_BASE;
-   struct rk3399_pmugrf_regs * const pmugrf = (void *)PMUGRF_BASE;
  
-	/**

-* 1. Glow yellow LED, termed as low power
-* 2. Poll for on board power key press
-* 3. Once 2 done, off yellow and glow red LED, termed as full power
-* 4. Continue booting...
-*/
-   spl_gpio_output(gpio0, GPIO(BANK_A, 2), 1);
-
-   spl_gpio_set_pull(&pmugrf->gpio0_p, GPIO(BANK_A, 5), GPIO_PULL_NORMAL);
-   while (readl(&gpio0->ext_port) & 0x20);
-
-   spl_gpio_output(gpio0, GPIO(BANK_A, 2), 0);
+   /* Turn on red LED, indicating full power mode */
spl_gpio_output(gpio0, GPIO(BANK_B, 5), 1);
  
  	return 0;

Re: [PATCH v1 4/8] spi: dw: Use generic function to read reg address

[Jagan Teki]

On Fri, Mar 6, 2020 at 12:49 AM Sean Anderson  wrote:
>
> Using an fdt-specific function causes problems when compiled with a live
> tree.
>
> Signed-off-by: Sean Anderson 
> ---
>
>  drivers/spi/designware_spi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
> index 765fa2f582..38c24fe550 100644
> --- a/drivers/spi/designware_spi.c
> +++ b/drivers/spi/designware_spi.c
> @@ -161,7 +161,9 @@ static int dw_spi_ofdata_to_platdata(struct udevice *bus)
>  {
> struct dw_spi_platdata *plat = bus->platdata;
>
> -   plat->regs = (struct dw_spi *)devfdt_get_addr(bus);
> +   plat->regs = dev_read_addr_ptr(bus);
> +   if (!plat->regs)
> +   return -EINVAL;

Better check the returned regs with FDT_ADDR_T_NONE

Re: AW: latest u-boot branch for Marvell Armada 88F3720

[Stefan Roese]

Hi Moritz,

On 02.04.20 13:30, Moritz Berghof wrote:

it's really great that you answered so fast and helpfully, thank you!

It's great you want get the board ported to mainline. Me too.


I build the U-boot mainline and uploaded on my espressobin. Used the ATF
and WTMI from Marvell.

When I start the flashed .bin file, the U-boot crashed at this following
point. "Synchronous Abort" handler, esr 0x96000210


Looks like an issue with SATA - not sure why. You might want to try to
disable SATA / AHCI for testing.


Prompt is attached at this mail.

I think there is a problem with the RAM. For example, I build the U-Boot
for 1 GB RAM with the Marvell U-boot and the mainline/master. Important
constant is DDR_TOPOLOGY=2

make DEBUG=0 USE_COHERENT_MEM=0 LOG_LEVEL=20 SECURE=0 
CLOCKSPRESET=CPU_1000_DDR_800 DDR_TOPOLOGY=2 WTP=... BOOTDEV=SPINOR PARTNUM=0 
PLAT=a3700 all fip

But when the u-boot mainline starts it promts:
U-Boot 2020.04-rc3-00188-g350c44dfb9 (Mar 31 2020 - 10:52:01 +0200)

DRAM:  512 MiB


The Marvell U-boot promts DRAM: 1 GiB



So my question is, where do you define the RAM Size?


Take a look at arch/arm/mach-mvebu/arm64-common.c. Perhaps this code
needs some changes for CONFIG_ARMADA_A3700 similar to what is done
for CONFIG_ARMADA_8K ?

I suggest you debug in this area a bit to see, where it goes wrong.


At armada-3720-espressobin.dts i expanded the memory size. No success.
At mvebu_armada-37xx.h I expand the RAM for two banks. No success.

Or do you see there other problems by starting the mainline?


Thanks,
Stefan

Re: [PATCH v1 3/8] spi: dw: Rename "cs-gpio" to "cs-gpios"

[Jagan Teki]

On Fri, Mar 6, 2020 at 12:49 AM Sean Anderson  wrote:
>
> This property is named differently than other SPI drivers with the same
> property, as well as the property as used in Linux.
>
> Signed-off-by: Sean Anderson 
> ---
>
>  arch/arc/dts/axs10x_mb.dtsi  |  3 ++-
>  arch/arc/dts/hsdk.dts|  3 ++-
>  drivers/spi/designware_spi.c | 10 +++---

Better separate the dts changes and add sha1 from Linux if it synced.

Re: [PATCH] spi: cadence-qspi: Move ref clock calculation to probe

[Jagan Teki]

On Wed, Feb 26, 2020 at 1:02 PM Simon Goldschmidt
 wrote:
>
>
>
> Vignesh Raghavendra  schrieb am Mi., 26. Feb. 2020, 08:29:
>>
>> +Simon who converted driver to use clk_get* APIs
>>
>> On 24/02/20 12:40 pm, Pratyush Yadav wrote:
>> > "assigned-clock-parents" and "assigned-clock-rates" DT properties take
>> > effect only after ofdata_to_platdata() when clk_set_defaults() is called
>> > in device_probe(). Therefore clk get rate() would return a wrong value
>> > in ofdata_to_platdata() when compared with probe. Hence it needs to be
>> > moved to probe.
>> >
>> > Tested on u-boot-ti/next.
>> >
>>
>> Acked-by: Vignesh Raghavendra 
>
>
> Fine by me. I actually moved it there after someone requested me to :-) I 
> first had it in the set_rate function...
>
> Acked-by: Simon Goldschmidt 

So, does this fixing something or will it work even for wrong value?
I'm thinking of picking it up for release, if associated boards got
tested.

Jagan.

[PATCH] Revert "board: roc-pc-rk3399: Add support for onboard LED's and push button to indicate power mode"

[sunil]

From: Suniel Mahesh 

In case of a power interruption, human intervention is required which
is not desirable if the device is installed at a remote location. Keep
red LED as it is to indicate board in full power mode.

This reverts partially the commit 5a6d3d1fbca70d7f528c685292d64c4cd0106aa6.

Signed-off-by: Suniel Mahesh 
---
Note:
- patch tested on rk3399-roc-pc
- code related to button press is removed
---
 board/firefly/roc-pc-rk3399/roc-pc-rk3399.c | 16 +---
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c 
b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
index de9185a..0fe1914 100644
--- a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
+++ b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #ifndef CONFIG_SPL_BUILD
 int board_early_init_f(void)
@@ -34,26 +33,13 @@ out:
 
 #if defined(CONFIG_TPL_BUILD)
 
-#define PMUGRF_BASE 0xff32
 #define GPIO0_BASE  0xff72
 
 int board_early_init_f(void)
 {
struct rockchip_gpio_regs * const gpio0 = (void *)GPIO0_BASE;
-   struct rk3399_pmugrf_regs * const pmugrf = (void *)PMUGRF_BASE;
 
-   /**
-* 1. Glow yellow LED, termed as low power
-* 2. Poll for on board power key press
-* 3. Once 2 done, off yellow and glow red LED, termed as full power
-* 4. Continue booting...
-*/
-   spl_gpio_output(gpio0, GPIO(BANK_A, 2), 1);
-
-   spl_gpio_set_pull(&pmugrf->gpio0_p, GPIO(BANK_A, 5), GPIO_PULL_NORMAL);
-   while (readl(&gpio0->ext_port) & 0x20);
-
-   spl_gpio_output(gpio0, GPIO(BANK_A, 2), 0);
+   /* Turn on red LED, indicating full power mode */
spl_gpio_output(gpio0, GPIO(BANK_B, 5), 1);
 
return 0;
-- 
2.7.4

Re: [Patch v3 1/3] mtd: spi-nor-ids: Enable SPI_NOR_OCTAL_READ flag for mt35xu*

[Jagan Teki]

On Wed, Mar 18, 2020 at 4:26 PM Priyanka Jain (OSS)
 wrote:
>
> >-Original Message-
> >From: U-Boot  On Behalf Of Kuldeep Singh
> >Sent: Saturday, March 14, 2020 6:24 PM
> >To: Priyanka Jain ; Jagan Teki
> >; Vignesh R ; u-
> >b...@lists.denx.de
> >Cc: Kuldeep Singh 
> >Subject: [Patch v3 1/3] mtd: spi-nor-ids: Enable SPI_NOR_OCTAL_READ flag for
> >mt35xu*
> >
> >Commit 658df8bd9464 ("mtd: spi-nor-core: Add octal mode support") enables
> >octal mode(1-1-8) support in spi-nor framework.
> >
> >mt35xu512aba and mt35xu02g supports SINGLE and OCTAL I/O. Hence,
> >enable SPI_NOR_OCTAL_READ flag for these flashes.
> >
> >Signed-off-by: Kuldeep Singh 
> >Reviewed-by: Vignesh Raghavendra 
> >---
> >v3: No change
> >v2: Reword commit message
> >
> > drivers/mtd/spi/spi-nor-ids.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c 
> >index
> >973b6f8..334c074 100644
> >--- a/drivers/mtd/spi/spi-nor-ids.c
> >+++ b/drivers/mtd/spi/spi-nor-ids.c
> >@@ -182,8 +182,8 @@ const struct flash_info spi_nor_ids[] = {
> >   { INFO("n25q00",  0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR
> >| SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> >   { INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR
> >| SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> >   { INFO("mt25qu02g",   0x20bb22, 0, 64 * 1024, 4096, SECT_4K |
> >USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> >-  { INFO("mt35xu512aba", 0x2c5b1a, 0,  128 * 1024,  512, USE_FSR |
> >SPI_NOR_4B_OPCODES) },
> >-  { INFO("mt35xu02g",  0x2c5b1c, 0, 128 * 1024,  2048, USE_FSR |
> >SPI_NOR_4B_OPCODES) },
> >+  { INFO("mt35xu512aba", 0x2c5b1a, 0,  128 * 1024,  512, USE_FSR |
> >SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
> >+  { INFO("mt35xu02g",  0x2c5b1c, 0, 128 * 1024,  2048, USE_FSR |
> >+SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
> > #endif
> > #ifdef CONFIG_SPI_FLASH_SPANSION  /* SPANSION */
> >   /* Spansion/Cypress -- single (large) sector size only, at least
> >--
> >2.7.4
> Reviewed-by: Priyanka Jain 
> Jagan,
>
> Please help to pick this patch or provide ack.

Yes I marked it to pick after MW.

Jagan.

Re: [u-boot][PATCH 2/2] spi: atmel-quadspi: Add verbose debug facilities to monitor register accesses

[Jagan Teki]

On Mon, Mar 23, 2020 at 6:38 PM  wrote:
>
> On Friday, March 20, 2020 11:37:59 AM EET tudor.amba...@microchip.com wrote:
> > From: Tudor Ambarus 
> >
> > This feature should not be enabled in release but can be useful for
> > developers who need to monitor register accesses at some specific places.
> >
> > Helped me identify a bug in u-boot, by comparing the register accesses
> > from the u-boot driver with the ones from its linux variant.
> >
> > Signed-off-by: Tudor Ambarus 
> > ---
> >  drivers/spi/atmel-quadspi.c | 114 ++--
> >  1 file changed, 96 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c
> > index 4099ee87993d..3de367e6a0c8 100644
> > --- a/drivers/spi/atmel-quadspi.c
> > +++ b/drivers/spi/atmel-quadspi.c
> > @@ -148,6 +148,7 @@ struct atmel_qspi {
> >   void __iomem *mem;
> >   resource_size_t mmap_size;
> >   const struct atmel_qspi_caps *caps;
> > + struct udevice *dev;
> >   ulong bus_clk_rate;
> >   u32 mr;
> >  };
> > @@ -169,6 +170,81 @@ static const struct atmel_qspi_mode atmel_qspi_modes[]
> > = { { 4, 4, 4, QSPI_IFR_WIDTH_QUAD_CMD },
> >  };
> >
> > +#ifdef VERBOSE_DEBUG
> > +static const char *atmel_qspi_reg_name(u32 offset, char *tmp, size_t sz)
> > +{
> > + switch (offset) {
> > + case QSPI_CR:
> > + return "CR";
> > + case QSPI_MR:
> > + return "MR";
> > + case QSPI_RD:
> > + return "MR";
> > + case QSPI_TD:
> > + return "TD";
> > + case QSPI_SR:
> > + return "SR";
> > + case QSPI_IER:
> > + return "IER";
> > + case QSPI_IDR:
> > + return "IDR";
> > + case QSPI_IMR:
> > + return "IMR";
> > + case QSPI_SCR:
> > + return "SCR";
> > + case QSPI_IAR:
> > + return "IAR";
> > + case QSPI_ICR:
> > + return "ICR/WICR";
> > + case QSPI_IFR:
> > + return "IFR";
> > + case QSPI_RICR:
> > + return "RICR";
> > + case QSPI_SMR:
> > + return "SMR";
> > + case QSPI_SKR:
> > + return "SKR";
> > + case QSPI_WPMR:
> > + return "WPMR";
> > + case QSPI_WPSR:
> > + return "WPSR";
> > + case QSPI_VERSION:
> > + return "VERSION";
> > + default:
> > + snprintf(tmp, sz, "0x%02x", offset);
> > + break;
> > + }
> > +
> > + return tmp;
> > +}
> > +#endif /* VERBOSE_DEBUG */
> > +
> > +static u32 atmel_qspi_read(struct atmel_qspi *aq, u32 offset)
> > +{
> > + u32 value = readl(aq->regs + offset);
> > +
> > +#ifdef VERBOSE_DEBUG
> > + char tmp[8];
>
> The largest string that I print is "ICR/WICR" which is 8bytes, but I didn't
> count the trailing null space, so the array should better be increased to 16
> bytes, to avoid truncation.
>
> > +
> > + dev_vdbg(aq->dev, "read 0x%08x from %s\n", value,
> > +  atmel_qspi_reg_name(offset, tmp, sizeof(tmp)));
> > +#endif /* VERBOSE_DEBUG */
> > +
> > + return value;
> > +}
> > +
> > +static void atmel_qspi_write(u32 value, struct atmel_qspi *aq, u32 offset)
> > +{
> > +#ifdef VERBOSE_DEBUG
> > + char tmp[8];
>
> ditto
>
> Jagan, if the rest looks good, would you do this change when applying? Let me
> know if I have to resubmit, or if there are any suggestions.

Yes and Applied to u-boot-spi/master

Re: [PATCH v2 1/4] arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates

[Jagan Teki]

On Thu, Apr 2, 2020 at 3:48 PM Mark Kettenis  wrote:
>
> > From: Jagan Teki 
> > Date: Thu, 2 Apr 2020 15:07:01 +0530
> >
> > Hi Kever,
> >
> > On Thu, Apr 2, 2020 at 2:48 PM Kever Yang  wrote:
> > >
> > > Hi Jagan,
> > >
> > > On 2020/3/31 下午1:59, Jagan Teki wrote:
> > > > On Tue, Mar 31, 2020 at 1:06 AM Mark Kettenis  
> > > > wrote:
> > > >>> From: Jagan Teki 
> > > >>> Cc: su...@amarulasolutions.com, u-boot@lists.denx.de,
> > > >>>  linux-rockc...@lists.infradead.org, 
> > > >>> linux-amar...@amarulasolutions.com,
> > > >>>  Jagan Teki 
> > > >>> Date: Mon, 30 Mar 2020 23:46:10 +0530
> > > >>> Content-Type: text/plain; charset=UTF-8
> > > >>>
> > > >>> Linux supporting assigned-clocks for VOP on rk3399 by assuming
> > > >>> U-Boot not initializing it on this linux commit:
> > > >>>
> > > >>> commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock 
> > > >>> rates")
> > > >>>
> > > >>> There is no specific need to initialize these assigned clock
> > > >>> in U-Boot as video drivers still work with default aclk and
> > > >>> hclk values. So, these clocks are simply not supported by rk3399
> > > >>> clock driver.
> > > >>>
> > > >>> But, during stdio probe of vidconsole, the device probe
> > > >>> will try to check whether the assigned clocks on that video
> > > >>> console node is initialized or not? and return error if not.
> > > >>>
> > > >>> So, delete these property via -u-boot dtsi as there is
> > > >>> no specific need in U-Boot.
> > > >> Deleting these properties isn't very helpful as it means the U-Boot
> > > >> device tree can no longer be used by the kernel.  Isn't it a better
> > > >> idea to implement these clocks as stubs in the u-boot clock driver?
> > > > I did try this before sorting out these changes, seems like it
> > > > requires a bit more tweaking the clock wrt display code. I really
> > > > didn't see any use case as of now for just to print u-boot log on
> > > > display out, and more over this support has been broken since from
> > > > releases. so bypassing these nodes can be a solutions for now.
> > >
> > >
> > > I agree with Mark for not touch the dts first. I don't know the detail
> > > of display driver but:
> > >
> > > - The rk3399 driver use to work without touch dts from kernel;
> > >
> > > - the clock driver have a rk3399_vop_set_clk() which does not depends on
> > > dts.
> >
> > The existing video drivers are written based on the puma dts and those
> > are not inline to Linux dts files, i.e. the reason the code is pushed
> > I think. The rest of rk3399 dtsi files are now inline to Linux as and
> > display out on these are broken from last 2 releases. so my idea is to
> > resolve the things one-after-another like
> > 1. Make existing video stuff work with all rk3399 (this series along
> > with this patch)
> > 2. Drop this patch change and make video drivers working w/o any
> > explicit changes in dts like this patch does.
> >
> > Since step 2, would take time, and require close testing of all boards
> > I would like to pick the existing stuff for the release. Mark my words
> > to fix the things for the next release.
>
> Fair enough.  I don't think fixing the issue is too difficult, but it
> is better to do these things in small steps anyway.

I have managed to fix this via clock driver(which seems more
reasonable as per Kever), so this is dropped in v3. thanks for
noticing.

Jagan.

[PATCH v3 5/5] video: rockchip: Support 4K resolution for rk3399, HDMI

[Jagan Teki]

The default resolution for rockchip display is 1920x1080
which failed to work on 4K HDMI out displays on rk3399.

So, mark the default resolution as 3480x2160 for rk3399
HDMI out.

This would work all the hdmi display resolutions till
4K.

Signed-off-by: Jagan Teki 
---
Changes for v3:
- new patch

 drivers/video/rockchip/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/video/rockchip/Kconfig b/drivers/video/rockchip/Kconfig
index 10182d0b66..cfd774ead6 100644
--- a/drivers/video/rockchip/Kconfig
+++ b/drivers/video/rockchip/Kconfig
@@ -22,6 +22,7 @@ menuconfig VIDEO_ROCKCHIP
 config VIDEO_ROCKCHIP_MAX_XRES
 int "Maximum horizontal resolution (for memory allocation purposes)"
depends on VIDEO_ROCKCHIP
+   default 3480 if ROCKCHIP_RK3399 && DISPLAY_ROCKCHIP_HDMI
default 1920
help
  The maximum horizontal resolution to support for the framebuffer.
@@ -31,6 +32,7 @@ config VIDEO_ROCKCHIP_MAX_XRES
 config VIDEO_ROCKCHIP_MAX_YRES
 int "Maximum vertical resolution (for memory allocation purposes)"
depends on VIDEO_ROCKCHIP
+   default 2160 if ROCKCHIP_RK3399 && DISPLAY_ROCKCHIP_HDMI
default 1080
help
  The maximum vertical resolution to support for the framebuffer.
-- 
2.17.1

[PATCH v3 4/5] rockchip: Enable HDMI output on rk3399 board w/ HDMI

[Jagan Teki]

Enable config options and console setting to respective
rk3399 board for HDMI output.

Boards supported and tested on this patch are:
- NanoPc T4
- NanoPi M4
- NanoPi Neo4
- ROC-RK3399-PC
- Rock960

Cc: Manivannan Sadhasivam 
Signed-off-by: Jagan Teki 
---
Changes for v3:
- add rock960 hdmi out support

 configs/nanopc-t4-rk3399_defconfig   | 7 +++
 configs/nanopi-m4-rk3399_defconfig   | 7 +++
 configs/nanopi-neo4-rk3399_defconfig | 7 +++
 configs/roc-pc-rk3399_defconfig  | 6 ++
 configs/rock960-rk3399_defconfig | 7 +++
 include/configs/evb_rk3399.h | 5 +
 include/configs/rock960_rk3399.h | 5 +
 7 files changed, 44 insertions(+)

diff --git a/configs/nanopc-t4-rk3399_defconfig 
b/configs/nanopc-t4-rk3399_defconfig
index 9ea9b11574..607a00dbf7 100644
--- a/configs/nanopc-t4-rk3399_defconfig
+++ b/configs/nanopc-t4-rk3399_defconfig
@@ -52,5 +52,12 @@ CONFIG_USB_ETHER_ASIX88179=y
 CONFIG_USB_ETHER_MCS7830=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USB_KEYBOARD=y
 CONFIG_SPL_TINY_MEMSET=y
 CONFIG_ERRNO_STR=y
+CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_BPP16=y
+CONFIG_VIDEO_BPP32=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
diff --git a/configs/nanopi-m4-rk3399_defconfig 
b/configs/nanopi-m4-rk3399_defconfig
index ad0e808bf6..3fcb7ac2d7 100644
--- a/configs/nanopi-m4-rk3399_defconfig
+++ b/configs/nanopi-m4-rk3399_defconfig
@@ -52,5 +52,12 @@ CONFIG_USB_ETHER_ASIX88179=y
 CONFIG_USB_ETHER_MCS7830=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USB_KEYBOARD=y
 CONFIG_SPL_TINY_MEMSET=y
 CONFIG_ERRNO_STR=y
+CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_BPP16=y
+CONFIG_VIDEO_BPP32=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
diff --git a/configs/nanopi-neo4-rk3399_defconfig 
b/configs/nanopi-neo4-rk3399_defconfig
index d038a8cab9..b9ea535e43 100644
--- a/configs/nanopi-neo4-rk3399_defconfig
+++ b/configs/nanopi-neo4-rk3399_defconfig
@@ -52,5 +52,12 @@ CONFIG_USB_ETHER_ASIX88179=y
 CONFIG_USB_ETHER_MCS7830=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USB_KEYBOARD=y
 CONFIG_SPL_TINY_MEMSET=y
 CONFIG_ERRNO_STR=y
+CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_BPP16=y
+CONFIG_VIDEO_BPP32=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig
index d540a17aeb..be76524cef 100644
--- a/configs/roc-pc-rk3399_defconfig
+++ b/configs/roc-pc-rk3399_defconfig
@@ -59,3 +59,9 @@ CONFIG_USB_ETHER_SMSC95XX=y
 CONFIG_USB_KEYBOARD=y
 CONFIG_SPL_TINY_MEMSET=y
 CONFIG_ERRNO_STR=y
+CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_BPP16=y
+CONFIG_VIDEO_BPP32=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
diff --git a/configs/rock960-rk3399_defconfig b/configs/rock960-rk3399_defconfig
index ba4226e173..c4e954731a 100644
--- a/configs/rock960-rk3399_defconfig
+++ b/configs/rock960-rk3399_defconfig
@@ -58,5 +58,12 @@ CONFIG_USB_ETHER_ASIX88179=y
 CONFIG_USB_ETHER_MCS7830=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USB_KEYBOARD=y
 CONFIG_SPL_TINY_MEMSET=y
 CONFIG_ERRNO_STR=y
+CONFIG_DM_VIDEO=y
+CONFIG_VIDEO_BPP16=y
+CONFIG_VIDEO_BPP32=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_DISPLAY_ROCKCHIP_HDMI=y
diff --git a/include/configs/evb_rk3399.h b/include/configs/evb_rk3399.h
index c0b0358893..2d3db22877 100644
--- a/include/configs/evb_rk3399.h
+++ b/include/configs/evb_rk3399.h
@@ -6,6 +6,11 @@
 #ifndef __EVB_RK3399_H
 #define __EVB_RK3399_H
 
+#define ROCKCHIP_DEVICE_SETTINGS \
+   "stdin=serial,usbkbd\0" \
+   "stdout=serial,vidconsole\0" \
+   "stderr=serial,vidconsole\0"
+
 #include 
 
 #if defined(CONFIG_ENV_IS_IN_MMC)
diff --git a/include/configs/rock960_rk3399.h b/include/configs/rock960_rk3399.h
index 746d24cbff..304ad2b7aa 100644
--- a/include/configs/rock960_rk3399.h
+++ b/include/configs/rock960_rk3399.h
@@ -6,6 +6,11 @@
 #ifndef __ROCK960_RK3399_H
 #define __ROCK960_RK3399_H
 
+#define ROCKCHIP_DEVICE_SETTINGS \
+   "stdin=serial,usbkbd\0" \
+   "stdout=serial,vidconsole\0" \
+   "stderr=serial,vidconsole\0"
+
 #include 
 
 #define CONFIG_SYS_MMC_ENV_DEV 1
-- 
2.17.1

[PATCH v3 2/5] video: rockchip: Fix vop modes for rk3399

[Jagan Teki]

VOP display endpoint pipeline configuration is differs
between rk3288 vs rk3399.

These VOP pipeline configuration depends on how the
different display interfaces connected in sequence to
IN and OUT ports like for,

RK3288:

vopb_out: port {
#address-cells = <1>;
#size-cells = <0>;
vopb_out_edp: endpoint@0 {
reg = <0>;
remote-endpoint = <&edp_in_vopb>;
};
vopb_out_hdmi: endpoint@1 {
reg = <1>;
remote-endpoint = <&hdmi_in_vopb>;
};
vopb_out_lvds: endpoint@2 {
reg = <2>;
remote-endpoint = <&lvds_in_vopb>;
};
vopb_out_mipi: endpoint@3 {
reg = <3>;
remote-endpoint = <&mipi_in_vopb>;
};
};

RK3399:

vopb_out: port {
 #address-cells = <1>;
 #size-cells = <0>;
 vopb_out_edp: endpoint@0 {
reg = <0>;
remote-endpoint = <&edp_in_vopb>;
 };
 vopb_out_mipi: endpoint@1 {
reg = <1>;
remote-endpoint = <&mipi_in_vopb>;
 };
 vopb_out_hdmi: endpoint@2 {
reg = <2>;
remote-endpoint = <&hdmi_in_vopb>;
 };
 vopb_out_mipi1: endpoint@3 {
reg = <3>;
remote-endpoint = <&mipi1_in_vopb>;
 };
 vopb_out_dp: endpoint@4 {
reg = <4>;
remote-endpoint = <&dp_in_vopb>;
 };
};

here, HDMI interface has endpoint 1 in rk3288 and 2 in rk3399.

The rockchip vop driver often depends on this determined endpoint
number and stored in vop_mode. So based on this vop_mode the bpp
and pin polarity would configure on detected display interface.

Since, the existing driver using rk3288 vop mode settings enabling
the same will result wrong display interface configuration for rk3399.

Add the patch for fixing these vop modes for rk3399.

Signed-off-by: Jagan Teki 
---
 arch/arm/include/asm/arch-rockchip/vop_rk3288.h | 11 +++
 drivers/video/rockchip/rk3399_vop.c |  2 --
 drivers/video/rockchip/rk_vop.c |  4 
 3 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/vop_rk3288.h 
b/arch/arm/include/asm/arch-rockchip/vop_rk3288.h
index 8398249509..872a158b71 100644
--- a/arch/arm/include/asm/arch-rockchip/vop_rk3288.h
+++ b/arch/arm/include/asm/arch-rockchip/vop_rk3288.h
@@ -85,6 +85,16 @@ enum {
LB_RGB_1280X8 = 0x5
 };
 
+#if defined(CONFIG_ROCKCHIP_RK3399)
+enum vop_modes {
+   VOP_MODE_EDP = 0,
+   VOP_MODE_MIPI,
+   VOP_MODE_HDMI,
+   VOP_MODE_MIPI1,
+   VOP_MODE_DP,
+   VOP_MODE_NONE,
+};
+#else
 enum vop_modes {
VOP_MODE_EDP = 0,
VOP_MODE_HDMI,
@@ -94,6 +104,7 @@ enum vop_modes {
VOP_MODE_AUTO_DETECT,
VOP_MODE_UNKNOWN,
 };
+#endif
 
 /* VOP_VERSION_INFO */
 #define M_FPGA_VERSION (0x << 16)
diff --git a/drivers/video/rockchip/rk3399_vop.c 
b/drivers/video/rockchip/rk3399_vop.c
index 81c122d7a9..1d5b3931a6 100644
--- a/drivers/video/rockchip/rk3399_vop.c
+++ b/drivers/video/rockchip/rk3399_vop.c
@@ -45,8 +45,6 @@ static void rk3399_set_pin_polarity(struct udevice *dev,
V_RK3399_DSP_MIPI_POL(polarity));
break;
 
-   case VOP_MODE_LVDS:
-   /* The RK3399 has neither parallel RGB nor LVDS output. */
default:
debug("%s: unsupported output mode %x\n", __func__, mode);
}
diff --git a/drivers/video/rockchip/rk_vop.c b/drivers/video/rockchip/rk_vop.c
index e91d4dfa7f..e1bd656bee 100644
--- a/drivers/video/rockchip/rk_vop.c
+++ b/drivers/video/rockchip/rk_vop.c
@@ -118,10 +118,12 @@ static void rkvop_enable_output(struct udevice *dev, enum 
vop_modes mode)
V_EDP_OUT_EN(1));
break;
 
+#if defined(CONFIG_ROCKCHIP_RK3288)
case VOP_MODE_LVDS:
clrsetbits_le32(®s->sys_ctrl, M_ALL_OUT_EN,
V_RGB_OUT_EN(1));
break;
+#endif
 
case VOP_MODE_MIPI:
clrsetbits_le32(®s->sys_ctrl, M_ALL_OUT_EN,
@@ -313,7 +315,9 @@ static int rk_display_init(struct udevice *dev, ulong 
fbbase, ofnode ep_node)
/* Set bitwidth for vop display according to vop mode */
switch (vop_id) {
case VOP_MODE_EDP:
+#if defined(CONFIG_ROCKCHIP_RK3288)
case VOP_MODE_LVDS:
+#endif
l2bpp = VIDEO_BPP16;
break;
case VOP_MODE_HDMI:
-- 
2.17.1

[PATCH v3 3/5] rockchip: Enable pre console for rk3399

[Jagan Teki]

Enable pre console buffer for rk3399 platform.

This would help to capture the console messages prior to
the console being initialised. Enabling this would help
to capture all the console messages on video output source
like HDMI. So we can find the full console messages of
U-Boot proper on HDMI display when enabled it for RK3399
platform boards.

Buffer address used for pre console is 0x0f20 which is
ram base plus 240MiB. right now the Allwinner SoC is using
similar computation.

Signed-off-by: Jagan Teki 
---
 arch/arm/mach-rockchip/Kconfig | 1 +
 common/Kconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index ed7514ab75..0cb1f23d0f 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -229,6 +229,7 @@ config ROCKCHIP_RK3399
select DM_PMIC
select DM_REGULATOR_FIXED
select BOARD_LATE_INIT
+   imply PRE_CONSOLE_BUFFER
imply ROCKCHIP_COMMON_BOARD
imply ROCKCHIP_SDRAM_COMMON
imply SPL_ROCKCHIP_COMMON_BOARD
diff --git a/common/Kconfig b/common/Kconfig
index 46e4193fc8..bd35de3056 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -568,6 +568,7 @@ config PRE_CON_BUF_ADDR
default 0x2f00 if ARCH_SUNXI && MACH_SUN9I
default 0x4f00 if ARCH_SUNXI && !MACH_SUN9I
default 0x0f00 if ROCKCHIP_RK3288
+   default 0x0f20 if ROCKCHIP_RK3399
help
  This sets the start address of the pre-console buffer. This must
  be in available memory and is accessed before relocation and
-- 
2.17.1

[PATCH v3 0/5] rockchip: rk3399: Fix HDMI out

[Jagan Teki]

Due to recent Linux dts(i) sync for rk3399. the existing
vop driver is not working with HDMI out on RK3399.

This is v3 patchset, for previous version fixes[1]. 

Changes for v3:
- handle vopl clks in clk driver
- drop dts changes
- fix 4K display out for rk3399
Changes for v2:
- use usbkbd as stdin
- enable USB Keyboard

[1] https://patchwork.ozlabs.org/cover/1264187/

Any inputs?
Jagan.

Jagan Teki (5):
  clk: rk3399: Set empty for vopl assigned-clocks
  video: rockchip: Fix vop modes for rk3399
  rockchip: Enable pre console for rk3399
  rockchip: Enable HDMI output on rk3399 board w/ HDMI
  video: rockchip: Support 4K resolution for rk3399, HDMI

 arch/arm/include/asm/arch-rockchip/vop_rk3288.h | 11 +++
 arch/arm/mach-rockchip/Kconfig  |  1 +
 common/Kconfig  |  1 +
 configs/nanopc-t4-rk3399_defconfig  |  7 +++
 configs/nanopi-m4-rk3399_defconfig  |  7 +++
 configs/nanopi-neo4-rk3399_defconfig|  7 +++
 configs/roc-pc-rk3399_defconfig |  6 ++
 configs/rock960-rk3399_defconfig|  7 +++
 drivers/clk/rockchip/clk_rk3399.c   |  7 +++
 drivers/video/rockchip/Kconfig  |  2 ++
 drivers/video/rockchip/rk3399_vop.c |  2 --
 drivers/video/rockchip/rk_vop.c |  4 
 include/configs/evb_rk3399.h|  5 +
 include/configs/rock960_rk3399.h|  5 +
 14 files changed, 70 insertions(+), 2 deletions(-)

-- 
2.17.1

[PATCH v3 1/5] clk: rk3399: Set empty for vopl assigned-clocks

[Jagan Teki]

During vidconsole probe, the device probe will try to
check whether the assigned clocks on that video console
node is initialized or not? and return an error if not.

But, unlike Linux U-Boot won't require to handle these
vopl assigned-clocks since core clocks are enough to
handle the video out to process.

So, mark them as empty in set_rate to satisfy clk_set_defaults
so-that probe happened properly.

Signed-off-by: Jagan Teki 
---
Changes for v3:
- new patch

 drivers/clk/rockchip/clk_rk3399.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index 865b80cc0f..1f62376595 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -994,6 +994,13 @@ static ulong rk3399_clk_set_rate(struct clk *clk, ulong 
rate)
case DCLK_VOP1:
ret = rk3399_vop_set_clk(priv->cru, clk->id, rate);
break;
+   case ACLK_VOP1:
+   case HCLK_VOP1:
+   /**
+* assigned-clocks handling won't require for vopl, so
+* return 0 to satisfy clk_set_defaults during device probe.
+*/
+   return 0;
case SCLK_DDRCLK:
ret = rk3399_ddr_set_clk(priv->cru, rate);
break;
-- 
2.17.1

Re: u-boot DT configuration node

[Mark Kettenis]

> From: Michal Simek 
> Date: Thu, 2 Apr 2020 08:05:36 +0200
> 
> On 01. 04. 20 20:09, Mark Kettenis wrote:
> >> From: Michal Simek 
> >> Date: Wed, 1 Apr 2020 11:23:13 +0200
> >>
> >> Hi Rob and others,
> >>
> >> for couple of years already u-boot is using config node in root DT for
> >> u-boot configuration.
> >>
> >> Here is one example in u-boot source code.
> >> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-spring.dts#L47
> >>
> >> And here is dt binding description
> >> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/config.txt
> >>
> >> I was checking dt binding specification and there no such a thing
> >> described there. It means I expect this is more adhoc u-boot solution.
> >> We have reached the point where could be beneficial to put some u-boot
> >> specific configurations to DT.
> >>
> >> Actually I have done similar thing some time ago too by using chosen
> >> node and add xilinx specific property there to point to eeprom.
> >> https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/zynqmp-zcu102-revA.dts#L39
> >>
> >> I think it is a time to discuss it and do it properly.
> >>
> >> First of all my question is where we could list SW prefixes to make sure
> >> that they are listed and everybody is aware about it. We have
> >> vendor-prefixes and we should have a way to record also prefixes for sw
> >> projects. U-Boot is using u-boot. Xen has file in the kernel with using
> >> xen prefix. At least these two should be listed.
> > 
> > OpenBSD is using "openbsd," as a prefix.  I've always thought it would
> > be good to have it listed in the list of vendor prefixes there.  In an
> > open source world it shouldn't matter whether an entity sells
> > something or not.  And in fact "inux," is already there.  And so is
> > "qemu,".
> 
> Good we have more.
> 
> 
> > 
> >> Next my question is what is the recommended way to pass sw specific
> >> parameters via DT? I think using chosen node is more appropriate then
> >> adhoc config node. Or is there a better way how this should be done?
> > 
> > On OpenBSD we do indeed use the the chosen node to pass information
> > between the bootloader and the kernel.
> 
> Can you please point me to any example or description what you are
> adding there?

Here is an example of what the chosen node looks like:

Node 0x2220
name: 'chosen'
openbsd,uefi-mmap-desc-ver: 0001
openbsd,uefi-mmap-desc-size: 0030
openbsd,uefi-mmap-size: 0540
openbsd,uefi-mmap-start: 0081.fbe37df8
openbsd,uefi-system-table: 0081.ff910018
openbsd,bootduid: 1b33bbab.1613122f
bootargs: 'sd0a:/bsd'
stdout-path: '/smb/serial@e101'

The openbsd,uefi-* proprties are effectively the same those already
documented for linux and xen.  The openbsd,bootduid contains the
unique idea of the boot disk such that the kernel can find it and use
it as its root disk.  There is also an openbsd,bootmac property to
support netbooting, and openbsd,sr-bootuuid and openbsd,sr-bootkey
properties to support booting from software raid with full disk
encryption.  The actual key is zeroed out as soon as possible by the
kernel.

This all is pretty much a private interface between the boot loader
and the kernel though.

For booting on arm64 systems that use ACPI instead of a device tree,
the bootloader creates its own minimal device tree that contains a few
specific nodes that use compatible properties wuth an "openbsd,"
prefix.  But once again that is a private interface between bootloader
and kernel.

Cheers,

Mark

Re: [PATCH v3 00/29] dm: Add programmatic generation of ACPI tables (part A)

[Simon Glass]

Hi Heinrich,

On Tue, 31 Mar 2020 at 00:37, Heinrich Schuchardt  wrote:
>
> On 3/31/20 1:12 AM, Simon Glass wrote:
> > This is split from the original series in an attempt to get things applied
> > in chunks.
> >
> > This section includes patches up to and including the 'acpi' command.
> >
> > Changes in v3:
> > - Add a pointer to information about acpi,compatible
> > - Add forward declarations for the functions
> > - Add missing error check in acpi_create_dmar()
> > - Add new patch to add hexdump.h to the unit test header
> > - Add new patch to move acpi_s3.h to include/acpi/
> > - Beef up the comment explaining how the unaligned address is used
> > - Change the example to ELAN
> > - Compute ACPI_NAME_MAX from ACPI_NAME_LEN
> > - Correct description of acpi,probed
> > - Drop 'Intel' from 'Intel ACPI'
>
>
> Hello Simon,
>
> not only x86 but also ARM can use ACPI tables for booting. Below I see
> all those files under arch/x86/lib/.

Not all. Actually quite a few are in drivers/core and lib/acpi.

>
> I think we should separate the x86 specific stuff from the general ACPI
> coding.
>
> This is not meant to stop this series but can be done afterwards.

Yes we can easily move things when needed and I've already moved
things based on feedback from ARM. I really don't want the location of
code to hold up progress.

Regards,
Simon


>
> Best regards
>
> Heinrich
>
> > - Drop acpi,name in example
> > - Drop duplicate assert
> > - Drop hid-descr-addr
> > - Drop mention of PRIC
> > - Fix 'RSDP' typo
> > - Fix 'XDST' typo
> > - Fix DMA_ typo
> > - Fix a few typos
> > - Fix file comment for acpi_table.c
> > - Fix indenting error mentioned by Andy Shevchenko
> > - Fix stray #endif
> > - Just add the device.txt binding file in this patch
> > - Make use of BIT()
> > - Move acpi_align_large() out of dm_test_acpi_setup_base_tables()
> > - Move acpi_table.h to include/acpi
> > - Rename acpi,desc to acpi,ddn
> > - Rename acpi_align_large() to acpi_align64()
> > - Rename acpi_return_name() to acpi_copy_name()
> > - Reword commit message to drop the bit about ACPI being complicated
> > - Split out hid-over-i2c into its own patch
> > - Update commit message to say that we move most of its contents
> > - Use strncpy() instead of strcpy() in acpi_copy_name()
> >
> > Changes in v2:
> > - Add in the acpi_table.h header file to this patch
> > - Add the hid-over-i2c binding document
> > - Add trailing commas to enum
> > - Don't bracket the definitions with DM_SPI
> > - Drop definition of ACPI_TABLE_CREATOR
> > - Drop the Chrome OS pieces
> > - Drop the other comment change since it is already applied
> > - Drop two unnecessary __packed
> > - Fix definition of HID
> > - Generalise the ACPI function recursion with acpi_recurse_method()
> > - Infer hid-over-i2c CID value
> > - Make _acpi_write_dev_tables() static and switch argument order
> > - Move LOGC_ACPI definition to this patch
> > - Move __packed to after struct
> > - Move the sandbox acpi_table.h header file to an earlier patch
> > - Rename the 'coreboot' console to 'U-Boot'
> > - Use #defines for MADT and MCFG version numbers
> >
> > Simon Glass (29):
> >cpu: Support querying the address width
> >spi: Add SPI mode enums
> >tpm: cr50: Release locality on exit
> >tpm: cr50: Add a comment for cr50_priv
> >tpm: cr50: Use the correct GPIO binding
> >tpm: Don't cleanup unless an error happens
> >dm: pci: Allow disabling auto-config for a device
> >x86: Correct wording of coreboot source code
> >x86: apl: Move p2sb ofdata reading to the correct method
> >pci: Adjust dm_pci_read_bar32() to return errors correctly
> >x86: apl: Add Global NVS table header
> >dm: core: Add basic ACPI support
> >dts: Add a binding for hid-over-i2c
> >acpi: Add a binding for ACPI settings in the device tree
> >acpi: Add a simple sandbox test
> >x86: Move acpi_s3.h to include/acpi/
> >x86: Move acpi_table header to main include/ directory
> >acpi: Add an __ACPI__ preprocessor symbol
> >acpi: Add a central location for table version numbers
> >acpi: Add support for DMAR
> >test: Add hexdump.h to the unit test header
> >acpi: Add a method to write tables for a device
> >acpi: Convert part of acpi_table to use acpi_ctx
> >x86: Allow devices to write ACPI tables
> >acpi: Drop code for missing XSDT from acpi_write_rsdp()
> >acpi: Move acpi_add_table() to generic code
> >acpi: Put table-setup code in its own function
> >acpi: Move the xsdt pointer to acpi_ctx
> >acpi: Add an acpi command
> >
> >   arch/sandbox/dts/test.dts |   8 +
> >   arch/sandbox/include/asm/acpi_table.h |   9 +
> >   arch/sandbox/include/asm/global_data.h|   1 +
> >   arch/x86/cpu/apollolake/cpu_spl.c |   2 +-
> >   arch/x86/cpu/apollolake/fsp_s.c   |   2 +-
> >   arch/x86/cpu/apollolake/pmc.c |   2 +-
> >   arch/x86/cpu/baytrail/acpi.c  

RE: [PATCH V3 13/14] ARM: dts: stm32: Adjust PLL4 settings on AV96

[Gerald BAEZA]

Hi Marek

> From: Marek Vasut 
> Sent: mercredi 1 avril 2020 20:49
> 
> On 4/1/20 6:49 PM, Gerald BAEZA wrote:
> > Hi Marek and Patrick
> 
> Hi,
> 
> >> From: Marek Vasut 
> >> Sent: mercredi 1 avril 2020 13:09
> >>
> >> On 4/1/20 12:24 PM, Patrick DELAUNAY wrote:
> >>> Hi Gerald and Manivannan,
> >>
> >> Hi,
> >>
>  From: Marek Vasut 
>  Sent: mardi 31 mars 2020 19:52
> 
>  The PLL4 is supplying SDMMC12, SDMMC3 and SPDIF with 120 MHz and
>  FDCAN with 96 MHz. This isn't good for the SDMMC interfaces, which
>  can not easily divide the clock down to e.g. 50 MHz for high speed
>  SD and eMMC devices, so those devices end up running at 30 MHz as
>  that is
> >> 120 MHz / 4.
>  Adjust the PLL4 settings such that both PLL4P and PLL4R run at 100
>  MHz instead, which is easy to divide to 50MHz for optimal operation
>  of both SD and eMMC, SPDIF clock are not that much slower and
> FDCAN
>  is
> >> also unaffected.
> >
> > As far as I see, SPDIF is not supported on Avenger board so we don't care
> for this one.
> > FDCAN can be supported via the expansion connector, so better to keep it
> high (and < 100 MHz).
> 
> Why < 100 MHz and not <= 100 MHz ?

You're right, it is <= 100 MHz and it is important to be precise since you were 
exactly on 100 MHz :)

> > Be careful because the LTDC pixel clock also comes from the PLL4Q and it is
> used for the HDMI on Avenger.
> > The pixel clock is very constraint and I am surprised by the initial 40 MHz
> configuration (that becomes 50 MHz with your patch).
> 
> Is that a problem that the LTDC pixel clock are 50 MHz ? The kernel will
> reconfigure them anyway, so the 50 MHz is not the final value.

The kernel set_rate() changes the PLL output divisor, so it will indeed be able 
to switch back to (600/15=) 40 MHz from an initial (600/12=) 50 MHz.

> > I would recommend to align the Avenger configuration to ST boards one,
> that is the best compromise found so far (99 MHz for SDMMC and 74.250
> MHz for HDMI):
> 
> Why is this better than 100/50/100 ?
> 
> > https://wiki.st.com/stm32mpu/wiki/STM32MP15_clock_tree
> > /* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
> > pll4: st,pll@3 {
> > cfg = < 3 98 5 7 7 PQR(1,1,1) >;
> > u-boot,dm-pre-reloc;
> > };
> [...]

The simplest explanation I found is here:
https://timetoexplore.net/blog/video-timings-vga-720p-1080p
(you can also look for "74.25" in the HDMI specification but there is more text 
to read)

So 74.250 MHz is the needed pixel clock for 720p resolution in HDMI, that is 
quite common, so this frequency is wished for interoperability with a maximum 
of TVs.
This frequency cannot be reached from the initial or your proposed PLL4 
configuration, that is why I proposed to change this and align on ST board 
clock tree.

For the other displays we are supporting on ST boards, the kernel is tuning 
(down) this 74.250 MHz frequency via the set_rate (that changes the PLL output 
divisor).

Best regards

Gérald

Re: [RFC PATCH v2 05/13] mmc: add nexell driver

[Jaehoon Chung]

Hi,

On 3/28/20 6:43 PM, Stefan Bosch wrote:
> Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
> - mmc: nexell_dw_mmc.c changed to nexell_dw_mmc_dm.c (switched to DM).

It doesn't need to add postfix as _dm.

> 
> Signed-off-by: Stefan Bosch 
> ---
> 
> Changes in v2:
> - commit "i2c: mmc: add nexell driver (gpio, i2c, mmc, pwm)" splitted
>   into separate commits for gpio, i2c, mmc, pwm.
> 
>  drivers/mmc/Kconfig|   6 +
>  drivers/mmc/Makefile   |   1 +
>  drivers/mmc/nexell_dw_mmc_dm.c | 350 
> +
>  3 files changed, 357 insertions(+)
>  create mode 100644 drivers/mmc/nexell_dw_mmc_dm.c
> 
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 2f0eedc..bb8e7c0 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -253,6 +253,12 @@ config MMC_DW_SNPS
> This selects support for Synopsys DesignWare Memory Card Interface 
> driver
> extensions used in various Synopsys ARC devboards.
>  
> +config NEXELL_DWMMC
> + bool "Nexell SD/MMC controller support"
> + depends on ARCH_NEXELL
> + depends on MMC_DW
> + default y

Not depends on DM_MMC?

> +
>  config MMC_MESON_GX
>   bool "Meson GX EMMC controller support"
>   depends on DM_MMC && BLK && ARCH_MESON
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index 9c1f8e5..a7b5a7b 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -43,6 +43,7 @@ obj-$(CONFIG_SH_MMCIF) += sh_mmcif.o
>  obj-$(CONFIG_SH_SDHI) += sh_sdhi.o
>  obj-$(CONFIG_STM32_SDMMC2) += stm32_sdmmc2.o
>  obj-$(CONFIG_JZ47XX_MMC) += jz_mmc.o
> +obj-$(CONFIG_NEXELL_DWMMC) += nexell_dw_mmc_dm.o
>  
>  # SDHCI
>  obj-$(CONFIG_MMC_SDHCI)  += sdhci.o
> diff --git a/drivers/mmc/nexell_dw_mmc_dm.c b/drivers/mmc/nexell_dw_mmc_dm.c
> new file mode 100644
> index 000..b06b60d
> --- /dev/null
> +++ b/drivers/mmc/nexell_dw_mmc_dm.c
> @@ -0,0 +1,350 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2016 Nexell
> + * Youngbok, Park 
> + *
> + * (C) Copyright 2019 Stefan Bosch 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DWMCI_CLKSEL 0x09C
> +#define DWMCI_SHIFT_00x0
> +#define DWMCI_SHIFT_10x1
> +#define DWMCI_SHIFT_20x2
> +#define DWMCI_SHIFT_30x3
> +#define DWMCI_SET_SAMPLE_CLK(x)  (x)
> +#define DWMCI_SET_DRV_CLK(x) ((x) << 16)
> +#define DWMCI_SET_DIV_RATIO(x)   ((x) << 24)
> +#define DWMCI_CLKCTRL0x114
> +#define NX_MMC_CLK_DELAY(x, y, a, b) x) & 0xFF) << 0) |\
> + (((y) & 0x03) << 16) |\
> + (((a) & 0xFF) << 8)  |\
> + (((b) & 0x03) << 24))
> +
> +struct nexell_mmc_plat {
> + struct mmc_config cfg;
> + struct mmc mmc;
> +};
> +
> +struct nexell_dwmmc_priv {
> + struct clk *clk;
> + struct dwmci_host host;
> + int fifo_size;
> + bool fifo_mode;
> + int frequency;
> + u32 min_freq;
> + u32 max_freq;
> + int d_delay;
> + int d_shift;
> + int s_delay;
> + int s_shift;
> +
> +};
> +
> +struct clk *clk_get(const char *id);
> +
> +static void set_pin_stat(int index, int bit, int value)
> +{
> +#if !defined(CONFIG_SPL_BUILD)
> + nx_gpio_set_pad_function(index, bit, value);
> +#else
> +#if defined(CONFIG_ARCH_S5P4418) ||  \
> + defined(CONFIG_ARCH_S5P6818)
> +
> + unsigned long base[5] = {
> + PHY_BASEADDR_GPIOA, PHY_BASEADDR_GPIOB,
> + PHY_BASEADDR_GPIOC, PHY_BASEADDR_GPIOD,
> + PHY_BASEADDR_GPIOE,
> + };

I don't understand why gpio pin is set in mmc driver?
If nexell soc will change the gpio map and function value, does it needs to add 
other gpio control?

> +
> + dw_mmc_set_pin(base[index], bit, value);
> +#endif
> +#endif
> +}
> +
> +static void nx_dw_mmc_set_pin(struct dwmci_host *host)
> +{
> + debug("  %s(): dev_index == %d", __func__, host->dev_index);
> +
> + switch (host->dev_index) {
> + case 0:
> + set_pin_stat(0, 29, 1);
> + set_pin_stat(0, 31, 1);
> + set_pin_stat(1, 1, 1);
> + set_pin_stat(1, 3, 1);
> + set_pin_stat(1, 5, 1);
> + set_pin_stat(1, 7, 1);
> + break;
> + case 1:
> + set_pin_stat(3, 22, 1);
> + set_pin_stat(3, 23, 1);
> + set_pin_stat(3, 24, 1);
> + set_pin_stat(3, 25, 1);
> + set_pin_stat(3, 26, 1);
> + set_pin_stat(3, 27, 1);
> + break;
> + case 2:
> + set_pin_stat(2, 18, 2);
> + set_pin_stat(2, 19, 2);
> + set_pin_stat(2, 20, 2);
> + set_pin_stat(2, 21, 2);
> + set_pin_stat(2, 22, 2);

RE: [PATCH v6 01/17] misc: add driver for the SiFive otp controller

[Pragnesh Patel]

Hi Jagan,

>-Original Message-
>From: Jagan Teki 
>Sent: 02 April 2020 14:46
>To: Pragnesh Patel 
>Cc: U-Boot-Denx ; Atish Patra
>; palmerdabb...@google.com; Bin Meng
>; Paul Walmsley ; Troy
>Benjegerdes ; Anup Patel
>; Sagar Kadam ; Rick Chen
>; Simon Glass ; Eugen Hristev
>; Tero Kristo ; Marcel
>Ziswiler ; Finley Xiao chips.com>; Peng Fan 
>Subject: Re: [PATCH v6 01/17] misc: add driver for the SiFive otp controller
>
>[External Email] Do not click links or attachments unless you recognize the
>sender and know the content is safe
>
>On Sun, Mar 29, 2020 at 10:36 PM Pragnesh Patel
> wrote:
>>
>> Added a misc driver to handle OTP memory in SiFive SoCs.
>>
>> Signed-off-by: Pragnesh Patel 
>> ---
>>  drivers/misc/Kconfig  |   7 ++
>>  drivers/misc/Makefile |   1 +
>>  drivers/misc/sifive-otp.c | 255
>> ++
>>  3 files changed, 263 insertions(+)
>>  create mode 100644 drivers/misc/sifive-otp.c
>>
>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index
>> f18aa8f7ba..5caf61d077 100644
>> --- a/drivers/misc/Kconfig
>> +++ b/drivers/misc/Kconfig
>> @@ -68,6 +68,13 @@ config ROCKCHIP_OTP
>>   addressing and a length or through child-nodes that are generated
>>   based on the e-fuse map retrieved from the DTS.
>>
>> +config SIFIVE_OTP
>> +   bool "SiFive eMemory OTP driver"
>> +   depends on RISCV && MISC
>> +   help
>> + Enable support for reading and writing the eMemory OTP on the
>> + SiFive SoCs.
>> +
>>  config VEXPRESS_CONFIG
>> bool "Enable support for Arm Versatile Express config bus"
>> depends on MISC
>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index
>> 2b843de93c..ee888631b6 100644
>> --- a/drivers/misc/Makefile
>> +++ b/drivers/misc/Makefile
>> @@ -58,6 +58,7 @@ obj-$(CONFIG_$(SPL_)PWRSEQ) += pwrseq-uclass.o
>>  obj-$(CONFIG_QFW) += qfw.o
>>  obj-$(CONFIG_ROCKCHIP_EFUSE) += rockchip-efuse.o
>>  obj-$(CONFIG_ROCKCHIP_OTP) += rockchip-otp.o
>> +obj-$(CONFIG_SIFIVE_OTP) += sifive-otp.o
>>  obj-$(CONFIG_SANDBOX) += syscon_sandbox.o misc_sandbox.o
>>  obj-$(CONFIG_SMSC_LPC47M) += smsc_lpc47m.o
>>  obj-$(CONFIG_SMSC_SIO1007) += smsc_sio1007.o diff --git
>> a/drivers/misc/sifive-otp.c b/drivers/misc/sifive-otp.c new file mode
>> 100644 index 00..c1c2386b97
>> --- /dev/null
>> +++ b/drivers/misc/sifive-otp.c
>> @@ -0,0 +1,255 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * This is a driver for the eMemory EG004K32TQ028XW01 NeoFuse
>> + * One-Time-Programmable (OTP) memory used within the SiFive FU540.
>> + * It is documented in the FU540 manual here:
>> + *
>> +https://www.sifive.com/documentation/chips/freedom-u540-c000-
>manual/
>> + *
>> + * Copyright (C) 2018 Philipp Hug 
>> + * Copyright (C) 2018 Joey Hewitt 
>> + *
>> + * Copyright (C) 2020 SiFive, Inc
>> + */
>> +
>> +/*
>> + * The FU540 stores 4096x32 bit (16KiB) values.
>> + * Index 0x00-0xff are reserved for SiFive internal use. (first 1KiB)
>> + * Right now first 1KiB is used to store only serial number.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define BYTES_PER_FUSE 4
>> +
>> +#define PA_RESET_VAL   0x00
>> +#define PAS_RESET_VAL  0x00
>> +#define PAIO_RESET_VAL 0x00
>> +#define PDIN_RESET_VAL 0x00
>> +#define PTM_RESET_VAL  0x00
>> +
>> +#define PCLK_ENABLE_VALBIT(0)
>> +#define PCLK_DISABLE_VAL   0x00
>> +
>> +#define PWE_WRITE_ENABLE   BIT(0)
>> +#define PWE_WRITE_DISABLE  0x00
>> +
>> +#define PTM_FUSE_PROGRAM_VAL   BIT(1)
>> +
>> +#define PCE_ENABLE_INPUT   BIT(0)
>> +#define PCE_DISABLE_INPUT  0x00
>> +
>> +#define PPROG_ENABLE_INPUT BIT(0)
>> +#define PPROG_DISABLE_INPUT0x00
>> +
>> +#define PTRIM_ENABLE_INPUT BIT(0)
>> +#define PTRIM_DISABLE_INPUT0x00
>> +
>> +#define PDSTB_DEEP_STANDBY_ENABLE  BIT(0)
>> +#define PDSTB_DEEP_STANDBY_DISABLE 0x00
>> +
>> +struct sifive_otp_regs {
>> +   u32 pa; /* Address input */
>> +   u32 paio;   /* Program address input */
>> +   u32 pas;/* Program redundancy cell selection input */
>> +   u32 pce;/* OTP Macro enable input */
>> +   u32 pclk;   /* Clock input */
>> +   u32 pdin;   /* Write data input */
>> +   u32 pdout;  /* Read data output */
>> +   u32 pdstb;  /* Deep standby mode enable input (active low) */
>> +   u32 pprog;  /* Program mode enable input */
>> +   u32 ptc;/* Test column enable input */
>> +   u32 ptm;/* Test mode enable input */
>> +   u32 ptm_rep;/* Repair function test mode enable input */
>> +   u32 ptr;/* Test row enable input */
>> +   u32 ptrim;  /* Repair function enable input */
>> +   u32 pwe;/* Write enable input (defines program cycle) */
>> +};
>> +
>> +struct sifive_otp_platdata {
>> +  

[PATCH v3 1/1] phy: add support for stingray PAXB PHY controller

[Rayagonda Kokatanur]

From: Srinath Mannam 

Add support for stingray PAXB PHY controller driver.
This driver supports maximum 8 PAXB phys using pipemux data.

Signed-off-by: Srinath Mannam 
Signed-off-by: Rayagonda Kokatanur 
Reviewed-by: Stefan Roese 
---
Changes from v2:
 -Address review comments from Stefan Roese,
  Rearrange the include files.
  Remove dm/device.h as its included part of dm.h.

Changes from v1:
 -Address review comments from Stefan Roese,
  Use GENMASK() instead of hard code value.
  Remove unwanted struct declaration.
  Get pr_err() into single line.

 drivers/phy/Kconfig   |   7 ++
 drivers/phy/Makefile  |   1 +
 drivers/phy/phy-bcm-sr-pcie.c | 177 ++
 3 files changed, 185 insertions(+)
 create mode 100644 drivers/phy/phy-bcm-sr-pcie.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index a72f34f0d4..f7003807fc 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -84,6 +84,13 @@ config BCM6368_USBH_PHY
help
  Support for the Broadcom MIPS BCM6368 USBH PHY.
 
+config BCM_SR_PCIE_PHY
+   bool "Broadcom Stingray PCIe PHY driver"
+   depends on PHY
+   help
+ Enable this to support the Broadcom Stingray PCIe PHY
+ If unsure, say N.
+
 config PHY_DA8XX_USB
tristate "TI DA8xx USB PHY Driver"
depends on PHY && ARCH_DAVINCI
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 43ce62e08c..3958f7899c 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_BCM6318_USBH_PHY) += bcm6318-usbh-phy.o
 obj-$(CONFIG_BCM6348_USBH_PHY) += bcm6348-usbh-phy.o
 obj-$(CONFIG_BCM6358_USBH_PHY) += bcm6358-usbh-phy.o
 obj-$(CONFIG_BCM6368_USBH_PHY) += bcm6368-usbh-phy.o
+obj-$(CONFIG_BCM_SR_PCIE_PHY) += phy-bcm-sr-pcie.o
 obj-$(CONFIG_PHY_SANDBOX) += sandbox-phy.o
 obj-$(CONFIG_$(SPL_)PIPE3_PHY) += ti-pipe3-phy.o
 obj-$(CONFIG_AM654_PHY) += phy-ti-am654.o
diff --git a/drivers/phy/phy-bcm-sr-pcie.c b/drivers/phy/phy-bcm-sr-pcie.c
new file mode 100644
index 00..36c77c4b63
--- /dev/null
+++ b/drivers/phy/phy-bcm-sr-pcie.c
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Broadcom
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* we have up to 8 PAXB based RC. The 9th one is always PAXC */
+#define SR_NR_PCIE_PHYS   8
+
+#define PCIE_PIPEMUX_CFG_OFFSET   0x10c
+#define PCIE_PIPEMUX_SELECT_STRAP GENMASK(3, 0)
+
+#define CDRU_STRAP_DATA_LSW_OFFSET0x5c
+#define PCIE_PIPEMUX_SHIFT19
+#define PCIE_PIPEMUX_MASK GENMASK(3, 0)
+
+/**
+ * struct sr_pcie_phy_core - Stingray PCIe PHY core control
+ *
+ * @dev: pointer to device
+ * @base: base register of PCIe SS
+ * @cdru: CDRU base address
+ * @pipemux: pipemuex strap
+ */
+struct sr_pcie_phy_core {
+   struct udevice *dev;
+   void __iomem *base;
+   void __iomem *cdru;
+   u32 pipemux;
+};
+
+/*
+ * PCIe PIPEMUX lookup table
+ *
+ * Each array index represents a PIPEMUX strap setting
+ * The array element represents a bitmap where a set bit means the PCIe
+ * core and associated serdes has been enabled as RC and is available for use
+ */
+static const u8 pipemux_table[] = {
+   /* PIPEMUX = 0, EP 1x16 */
+   0x00,
+   /* PIPEMUX = 1, EP 1x8 + RC 1x8, core 7 */
+   0x80,
+   /* PIPEMUX = 2, EP 4x4 */
+   0x00,
+   /* PIPEMUX = 3, RC 2x8, cores 0, 7 */
+   0x81,
+   /* PIPEMUX = 4, RC 4x4, cores 0, 1, 6, 7 */
+   0xc3,
+   /* PIPEMUX = 5, RC 8x2, all 8 cores */
+   0xff,
+   /* PIPEMUX = 6, RC 3x4 + 2x2, cores 0, 2, 3, 6, 7 */
+   0xcd,
+   /* PIPEMUX = 7, RC 1x4 + 6x2, cores 0, 2, 3, 4, 5, 6, 7 */
+   0xfd,
+   /* PIPEMUX = 8, EP 1x8 + RC 4x2, cores 4, 5, 6, 7 */
+   0xf0,
+   /* PIPEMUX = 9, EP 1x8 + RC 2x4, cores 6, 7 */
+   0xc0,
+   /* PIPEMUX = 10, EP 2x4 + RC 2x4, cores 1, 6 */
+   0x42,
+   /* PIPEMUX = 11, EP 2x4 + RC 4x2, cores 2, 3, 4, 5 */
+   0x3c,
+   /* PIPEMUX = 12, EP 1x4 + RC 6x2, cores 2, 3, 4, 5, 6, 7 */
+   0xfc,
+   /* PIPEMUX = 13, RC 2x4 + RC 1x4 + 2x2, cores 2, 3, 6 */
+   0x4c,
+};
+
+/*
+ * Return true if the strap setting is valid
+ */
+static bool pipemux_strap_is_valid(u32 pipemux)
+{
+   return !!(pipemux < ARRAY_SIZE(pipemux_table));
+}
+
+/*
+ * Read the PCIe PIPEMUX from strap
+ */
+static u32 pipemux_strap_read(struct sr_pcie_phy_core *core)
+{
+   u32 pipemux;
+
+   /*
+* Read PIPEMUX configuration register to determine the pipemux setting
+*
+* In the case when the value indicates using HW strap, fall back to
+* use HW strap
+*/
+   pipemux = readl(core->base + PCIE_PIPEMUX_CFG_OFFSET);
+   pipemux &= PCIE_PIPEMUX_MASK;
+   if (pipemux == PCIE_PIPEMUX_SELECT_STRAP) {
+   pipemux = readl(core->cdru + CDRU_STRAP_DATA_LSW_OFFSET);
+   pipemux >>= PCIE_PIPEMUX_SHIFT;
+   

Re: [PATCH v2 1/1] phy: add support for stingray PAXB PHY controller

[Rayagonda Kokatanur]

On Thu, Apr 2, 2020 at 3:29 PM Stefan Roese  wrote:
>
> On 02.04.20 10:45, Rayagonda Kokatanur wrote:
> > From: Srinath Mannam 
> >
> > Add support for stingray PAXB PHY controller driver.
> > This driver supports maximum 8 PAXB phys using pipemux data.
> >
> > Signed-off-by: Srinath Mannam 
> > Signed-off-by: Rayagonda Kokatanur 
> > ---
> > Changes from v1:
> >   -Address review comments from Stefan Roese,
> >Use GENMASK() instead of hard code value.
> >Remove unwanted struct declaration.
> >Get pr_err() into single line.
> >
> >   drivers/phy/Kconfig   |   7 ++
> >   drivers/phy/Makefile  |   1 +
> >   drivers/phy/phy-bcm-sr-pcie.c | 178 ++
> >   3 files changed, 186 insertions(+)
> >   create mode 100644 drivers/phy/phy-bcm-sr-pcie.c
> >
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> > index a72f34f0d4..f7003807fc 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -84,6 +84,13 @@ config BCM6368_USBH_PHY
> >   help
> > Support for the Broadcom MIPS BCM6368 USBH PHY.
> >
> > +config BCM_SR_PCIE_PHY
> > + bool "Broadcom Stingray PCIe PHY driver"
> > + depends on PHY
> > + help
> > +   Enable this to support the Broadcom Stingray PCIe PHY
> > +   If unsure, say N.
> > +
> >   config PHY_DA8XX_USB
> >   tristate "TI DA8xx USB PHY Driver"
> >   depends on PHY && ARCH_DAVINCI
> > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> > index 43ce62e08c..3958f7899c 100644
> > --- a/drivers/phy/Makefile
> > +++ b/drivers/phy/Makefile
> > @@ -9,6 +9,7 @@ obj-$(CONFIG_BCM6318_USBH_PHY) += bcm6318-usbh-phy.o
> >   obj-$(CONFIG_BCM6348_USBH_PHY) += bcm6348-usbh-phy.o
> >   obj-$(CONFIG_BCM6358_USBH_PHY) += bcm6358-usbh-phy.o
> >   obj-$(CONFIG_BCM6368_USBH_PHY) += bcm6368-usbh-phy.o
> > +obj-$(CONFIG_BCM_SR_PCIE_PHY) += phy-bcm-sr-pcie.o
> >   obj-$(CONFIG_PHY_SANDBOX) += sandbox-phy.o
> >   obj-$(CONFIG_$(SPL_)PIPE3_PHY) += ti-pipe3-phy.o
> >   obj-$(CONFIG_AM654_PHY) += phy-ti-am654.o
> > diff --git a/drivers/phy/phy-bcm-sr-pcie.c b/drivers/phy/phy-bcm-sr-pcie.c
> > new file mode 100644
> > index 00..080cac30b2
> > --- /dev/null
> > +++ b/drivers/phy/phy-bcm-sr-pcie.c
> > @@ -0,0 +1,178 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2019 Broadcom
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
>
> Sorry for spotting this so late (and my nitpicking comments), but I
> think these include files could be reordered and dm/device.h removed:
>
> #include 
> #include 
> #include 
> #include 
> #include 
>
> Other that that, feel free to add my:
>
> Reviewed-by: Stefan Roese 

Not an issue Stefan.
Thank you for your detailed review.
I will do the above changes and push patch v3.

>
> Thanks,
> Stefan
>
> > +
> > +/* we have up to 8 PAXB based RC. The 9th one is always PAXC */
> > +#define SR_NR_PCIE_PHYS   8
> > +
> > +#define PCIE_PIPEMUX_CFG_OFFSET   0x10c
> > +#define PCIE_PIPEMUX_SELECT_STRAP GENMASK(3, 0)
> > +
> > +#define CDRU_STRAP_DATA_LSW_OFFSET0x5c
> > +#define PCIE_PIPEMUX_SHIFT19
> > +#define PCIE_PIPEMUX_MASK GENMASK(3, 0)
> > +
> > +/**
> > + * struct sr_pcie_phy_core - Stingray PCIe PHY core control
> > + *
> > + * @dev: pointer to device
> > + * @base: base register of PCIe SS
> > + * @cdru: CDRU base address
> > + * @pipemux: pipemuex strap
> > + */
> > +struct sr_pcie_phy_core {
> > + struct udevice *dev;
> > + void __iomem *base;
> > + void __iomem *cdru;
> > + u32 pipemux;
> > +};
> > +
> > +/*
> > + * PCIe PIPEMUX lookup table
> > + *
> > + * Each array index represents a PIPEMUX strap setting
> > + * The array element represents a bitmap where a set bit means the PCIe
> > + * core and associated serdes has been enabled as RC and is available for 
> > use
> > + */
> > +static const u8 pipemux_table[] = {
> > + /* PIPEMUX = 0, EP 1x16 */
> > + 0x00,
> > + /* PIPEMUX = 1, EP 1x8 + RC 1x8, core 7 */
> > + 0x80,
> > + /* PIPEMUX = 2, EP 4x4 */
> > + 0x00,
> > + /* PIPEMUX = 3, RC 2x8, cores 0, 7 */
> > + 0x81,
> > + /* PIPEMUX = 4, RC 4x4, cores 0, 1, 6, 7 */
> > + 0xc3,
> > + /* PIPEMUX = 5, RC 8x2, all 8 cores */
> > + 0xff,
> > + /* PIPEMUX = 6, RC 3x4 + 2x2, cores 0, 2, 3, 6, 7 */
> > + 0xcd,
> > + /* PIPEMUX = 7, RC 1x4 + 6x2, cores 0, 2, 3, 4, 5, 6, 7 */
> > + 0xfd,
> > + /* PIPEMUX = 8, EP 1x8 + RC 4x2, cores 4, 5, 6, 7 */
> > + 0xf0,
> > + /* PIPEMUX = 9, EP 1x8 + RC 2x4, cores 6, 7 */
> > + 0xc0,
> > + /* PIPEMUX = 10, EP 2x4 + RC 2x4, cores 1, 6 */
> > + 0x42,
> > + /* PIPEMUX = 11, EP 2x4 + RC 4x2, cores 2, 3, 4, 5 */
> > + 0x3c,
> > + /* PIPEMUX = 12, EP 1x4 + RC 6x2, cores 2, 3, 4, 5, 6, 7 */
> > + 0xfc,
> > + /* PIPEMUX = 13, RC 2x4 + RC 1x4 + 2x2, cores 2, 3, 6 */
> > + 0x4c,
> > +};
> > 

Re: [PATCH v2 1/4] arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates

[Mark Kettenis]

> From: Jagan Teki 
> Date: Thu, 2 Apr 2020 15:07:01 +0530
> 
> Hi Kever,
> 
> On Thu, Apr 2, 2020 at 2:48 PM Kever Yang  wrote:
> >
> > Hi Jagan,
> >
> > On 2020/3/31 下午1:59, Jagan Teki wrote:
> > > On Tue, Mar 31, 2020 at 1:06 AM Mark Kettenis  
> > > wrote:
> > >>> From: Jagan Teki 
> > >>> Cc: su...@amarulasolutions.com, u-boot@lists.denx.de,
> > >>>  linux-rockc...@lists.infradead.org, 
> > >>> linux-amar...@amarulasolutions.com,
> > >>>  Jagan Teki 
> > >>> Date: Mon, 30 Mar 2020 23:46:10 +0530
> > >>> Content-Type: text/plain; charset=UTF-8
> > >>>
> > >>> Linux supporting assigned-clocks for VOP on rk3399 by assuming
> > >>> U-Boot not initializing it on this linux commit:
> > >>>
> > >>> commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock 
> > >>> rates")
> > >>>
> > >>> There is no specific need to initialize these assigned clock
> > >>> in U-Boot as video drivers still work with default aclk and
> > >>> hclk values. So, these clocks are simply not supported by rk3399
> > >>> clock driver.
> > >>>
> > >>> But, during stdio probe of vidconsole, the device probe
> > >>> will try to check whether the assigned clocks on that video
> > >>> console node is initialized or not? and return error if not.
> > >>>
> > >>> So, delete these property via -u-boot dtsi as there is
> > >>> no specific need in U-Boot.
> > >> Deleting these properties isn't very helpful as it means the U-Boot
> > >> device tree can no longer be used by the kernel.  Isn't it a better
> > >> idea to implement these clocks as stubs in the u-boot clock driver?
> > > I did try this before sorting out these changes, seems like it
> > > requires a bit more tweaking the clock wrt display code. I really
> > > didn't see any use case as of now for just to print u-boot log on
> > > display out, and more over this support has been broken since from
> > > releases. so bypassing these nodes can be a solutions for now.
> >
> >
> > I agree with Mark for not touch the dts first. I don't know the detail
> > of display driver but:
> >
> > - The rk3399 driver use to work without touch dts from kernel;
> >
> > - the clock driver have a rk3399_vop_set_clk() which does not depends on
> > dts.
> 
> The existing video drivers are written based on the puma dts and those
> are not inline to Linux dts files, i.e. the reason the code is pushed
> I think. The rest of rk3399 dtsi files are now inline to Linux as and
> display out on these are broken from last 2 releases. so my idea is to
> resolve the things one-after-another like
> 1. Make existing video stuff work with all rk3399 (this series along
> with this patch)
> 2. Drop this patch change and make video drivers working w/o any
> explicit changes in dts like this patch does.
> 
> Since step 2, would take time, and require close testing of all boards
> I would like to pick the existing stuff for the release. Mark my words
> to fix the things for the next release.

Fair enough.  I don't think fixing the issue is too difficult, but it
is better to do these things in small steps anyway.

RE: [PATCH v6 02/17] riscv: sifive: fu540: Use OTP DM driver for serial environment variable

[Pragnesh Patel]

Hi Jagan,

>-Original Message-
>From: Jagan Teki 
>Sent: 02 April 2020 14:59
>To: Pragnesh Patel 
>Cc: U-Boot-Denx ; Atish Patra
>; palmerdabb...@google.com; Bin Meng
>; Paul Walmsley ; Troy
>Benjegerdes ; Anup Patel
>; Sagar Kadam ; Rick Chen
>; Palmer Dabbelt 
>Subject: Re: [PATCH v6 02/17] riscv: sifive: fu540: Use OTP DM driver for 
>serial
>environment variable
>
>[External Email] Do not click links or attachments unless you recognize the
>sender and know the content is safe
>
>On Thu, Apr 2, 2020 at 2:54 PM Pragnesh Patel 
>wrote:
>>
>>
>> Hi Jagan,
>>
>> >-Original Message-
>> >From: Jagan Teki 
>> >Sent: 02 April 2020 14:49
>> >To: Pragnesh Patel 
>> >Cc: U-Boot-Denx ; Atish Patra
>> >; palmerdabb...@google.com; Bin Meng
>> >; Paul Walmsley ;
>Troy
>> >Benjegerdes ; Anup Patel
>> >; Sagar Kadam ; Rick
>Chen
>> >; Palmer Dabbelt 
>> >Subject: Re: [PATCH v6 02/17] riscv: sifive: fu540: Use OTP DM driver
>> >for serial environment variable
>> >
>> >[External Email] Do not click links or attachments unless you
>> >recognize the sender and know the content is safe
>> >
>> >On Sun, Mar 29, 2020 at 10:36 PM Pragnesh Patel
>> > wrote:
>> >>
>> >> Use the OTP DM driver to set the serial environment variable.
>> >>
>> >> Signed-off-by: Pragnesh Patel 
>> >> ---
>> >>  arch/riscv/dts/fu540-c000-u-boot.dtsi |  14 +++
>> >>  .../dts/hifive-unleashed-a00-u-boot.dtsi  |   6 +
>> >>  board/sifive/fu540/Kconfig|   2 +
>> >>  board/sifive/fu540/fu540.c| 111 ++
>> >>  4 files changed, 61 insertions(+), 72 deletions(-)  create mode
>> >> 100644 arch/riscv/dts/fu540-c000-u-boot.dtsi
>> >>  create mode 100644 arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
>> >>
>> >> diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi
>> >> b/arch/riscv/dts/fu540-c000-u-boot.dtsi
>> >> new file mode 100644
>> >> index 00..db55773bd2
>> >> --- /dev/null
>> >> +++ b/arch/riscv/dts/fu540-c000-u-boot.dtsi
>> >> @@ -0,0 +1,14 @@
>> >> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
>> >> +/*
>> >> + * (C) Copyright 2019 SiFive, Inc
>> >> + */
>> >> +
>> >> +/ {
>> >> +   soc {
>> >> +   otp: otp@1007 {
>> >> +   compatible = "sifive,fu540-c000-otp";
>> >> +   reg = <0x0 0x1007 0x0 0x0FFF>;
>> >> +   fuse-count = <0x1000>;
>> >> +   };
>> >> +   };
>> >> +};
>> >> diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
>> >> b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
>> >> new file mode 100644
>> >> index 00..f1735c1385
>> >> --- /dev/null
>> >> +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
>> >> @@ -0,0 +1,6 @@
>> >> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
>> >> +/*
>> >> + * Copyright (C) 2019 SiFive, Inc
>> >> + */
>> >> +
>> >> +#include "fu540-c000-u-boot.dtsi"
>> >> diff --git a/board/sifive/fu540/Kconfig
>> >> b/board/sifive/fu540/Kconfig index 5ca21474de..900197bbb2 100644
>> >> --- a/board/sifive/fu540/Kconfig
>> >> +++ b/board/sifive/fu540/Kconfig
>> >> @@ -48,5 +48,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
>> >> imply SIFIVE_GPIO
>> >> imply CMD_GPIO
>> >> imply SMP
>> >> +   imply MISC
>> >> +   imply SIFIVE_OTP
>> >
>> >Mark this default y if it is SIFIVE.
>>
>> All other SiFive drivers (SPI_SIFIVE, SIFIVE_GPIO) are enabled by "imply", 
>> so I
>am following the same. I think "imply" will make it default y.
>
>Just mark 'default y' on SIFIVE_OTP area of drivers/misc/Kconfig depends on
>SIFIVE SoC would select this driver so-that you no need to add impy
>SIFIVE_OTP here.

I am not sure if all SiFive SoC will contain SiFive OTP controller, so it's 
better not to make it default y.

If all Sifive SoCs contain OTP controller then I need to add another Kconfig 
option like "RISCV_SIFIVE" as shown below,
config SIFIVE_OTP
default y if RISCV_SIFIVE

>
>Jagan.

Re: [PATCH v2 1/1] phy: add support for stingray PAXB PHY controller

[Stefan Roese]

On 02.04.20 10:45, Rayagonda Kokatanur wrote:

From: Srinath Mannam 

Add support for stingray PAXB PHY controller driver.
This driver supports maximum 8 PAXB phys using pipemux data.

Signed-off-by: Srinath Mannam 
Signed-off-by: Rayagonda Kokatanur 
---
Changes from v1:
  -Address review comments from Stefan Roese,
   Use GENMASK() instead of hard code value.
   Remove unwanted struct declaration.
   Get pr_err() into single line.

  drivers/phy/Kconfig   |   7 ++
  drivers/phy/Makefile  |   1 +
  drivers/phy/phy-bcm-sr-pcie.c | 178 ++
  3 files changed, 186 insertions(+)
  create mode 100644 drivers/phy/phy-bcm-sr-pcie.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index a72f34f0d4..f7003807fc 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -84,6 +84,13 @@ config BCM6368_USBH_PHY
help
  Support for the Broadcom MIPS BCM6368 USBH PHY.
  
+config BCM_SR_PCIE_PHY

+   bool "Broadcom Stingray PCIe PHY driver"
+   depends on PHY
+   help
+ Enable this to support the Broadcom Stingray PCIe PHY
+ If unsure, say N.
+
  config PHY_DA8XX_USB
tristate "TI DA8xx USB PHY Driver"
depends on PHY && ARCH_DAVINCI
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 43ce62e08c..3958f7899c 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_BCM6318_USBH_PHY) += bcm6318-usbh-phy.o
  obj-$(CONFIG_BCM6348_USBH_PHY) += bcm6348-usbh-phy.o
  obj-$(CONFIG_BCM6358_USBH_PHY) += bcm6358-usbh-phy.o
  obj-$(CONFIG_BCM6368_USBH_PHY) += bcm6368-usbh-phy.o
+obj-$(CONFIG_BCM_SR_PCIE_PHY) += phy-bcm-sr-pcie.o
  obj-$(CONFIG_PHY_SANDBOX) += sandbox-phy.o
  obj-$(CONFIG_$(SPL_)PIPE3_PHY) += ti-pipe3-phy.o
  obj-$(CONFIG_AM654_PHY) += phy-ti-am654.o
diff --git a/drivers/phy/phy-bcm-sr-pcie.c b/drivers/phy/phy-bcm-sr-pcie.c
new file mode 100644
index 00..080cac30b2
--- /dev/null
+++ b/drivers/phy/phy-bcm-sr-pcie.c
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Broadcom
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 


Sorry for spotting this so late (and my nitpicking comments), but I
think these include files could be reordered and dm/device.h removed:

#include 
#include 
#include 
#include 
#include 

Other that that, feel free to add my:

Reviewed-by: Stefan Roese 

Thanks,
Stefan


+
+/* we have up to 8 PAXB based RC. The 9th one is always PAXC */
+#define SR_NR_PCIE_PHYS   8
+
+#define PCIE_PIPEMUX_CFG_OFFSET   0x10c
+#define PCIE_PIPEMUX_SELECT_STRAP GENMASK(3, 0)
+
+#define CDRU_STRAP_DATA_LSW_OFFSET0x5c
+#define PCIE_PIPEMUX_SHIFT19
+#define PCIE_PIPEMUX_MASK GENMASK(3, 0)
+
+/**
+ * struct sr_pcie_phy_core - Stingray PCIe PHY core control
+ *
+ * @dev: pointer to device
+ * @base: base register of PCIe SS
+ * @cdru: CDRU base address
+ * @pipemux: pipemuex strap
+ */
+struct sr_pcie_phy_core {
+   struct udevice *dev;
+   void __iomem *base;
+   void __iomem *cdru;
+   u32 pipemux;
+};
+
+/*
+ * PCIe PIPEMUX lookup table
+ *
+ * Each array index represents a PIPEMUX strap setting
+ * The array element represents a bitmap where a set bit means the PCIe
+ * core and associated serdes has been enabled as RC and is available for use
+ */
+static const u8 pipemux_table[] = {
+   /* PIPEMUX = 0, EP 1x16 */
+   0x00,
+   /* PIPEMUX = 1, EP 1x8 + RC 1x8, core 7 */
+   0x80,
+   /* PIPEMUX = 2, EP 4x4 */
+   0x00,
+   /* PIPEMUX = 3, RC 2x8, cores 0, 7 */
+   0x81,
+   /* PIPEMUX = 4, RC 4x4, cores 0, 1, 6, 7 */
+   0xc3,
+   /* PIPEMUX = 5, RC 8x2, all 8 cores */
+   0xff,
+   /* PIPEMUX = 6, RC 3x4 + 2x2, cores 0, 2, 3, 6, 7 */
+   0xcd,
+   /* PIPEMUX = 7, RC 1x4 + 6x2, cores 0, 2, 3, 4, 5, 6, 7 */
+   0xfd,
+   /* PIPEMUX = 8, EP 1x8 + RC 4x2, cores 4, 5, 6, 7 */
+   0xf0,
+   /* PIPEMUX = 9, EP 1x8 + RC 2x4, cores 6, 7 */
+   0xc0,
+   /* PIPEMUX = 10, EP 2x4 + RC 2x4, cores 1, 6 */
+   0x42,
+   /* PIPEMUX = 11, EP 2x4 + RC 4x2, cores 2, 3, 4, 5 */
+   0x3c,
+   /* PIPEMUX = 12, EP 1x4 + RC 6x2, cores 2, 3, 4, 5, 6, 7 */
+   0xfc,
+   /* PIPEMUX = 13, RC 2x4 + RC 1x4 + 2x2, cores 2, 3, 6 */
+   0x4c,
+};
+
+/*
+ * Return true if the strap setting is valid
+ */
+static bool pipemux_strap_is_valid(u32 pipemux)
+{
+   return !!(pipemux < ARRAY_SIZE(pipemux_table));
+}
+
+/*
+ * Read the PCIe PIPEMUX from strap
+ */
+static u32 pipemux_strap_read(struct sr_pcie_phy_core *core)
+{
+   u32 pipemux;
+
+   /*
+* Read PIPEMUX configuration register to determine the pipemux setting
+*
+* In the case when the value indicates using HW strap, fall back to
+* use HW strap
+*/
+   pipemux = readl(core->base + PCIE_PIPEMUX_CFG_OFFSET);
+   pipemux &= PCIE_PIPEMUX_MASK;
+

Re: [PATCH v6 00/17] RISC-V SiFive FU540 support SPL

[Jagan Teki]

On Thu, Apr 2, 2020 at 3:12 PM Pragnesh Patel  wrote:
>
> Hi Jagan,
>
> >-Original Message-
> >From: Jagan Teki 
> >Sent: 02 April 2020 14:42
> >To: Pragnesh Patel 
> >Cc: U-Boot-Denx ; Atish Patra
> >; palmerdabb...@google.com; Bin Meng
> >; Paul Walmsley ; Troy
> >Benjegerdes ; Anup Patel
> >; Sagar Kadam ; Rick Chen
> >
> >Subject: Re: [PATCH v6 00/17] RISC-V SiFive FU540 support SPL
> >
> >[External Email] Do not click links or attachments unless you recognize the
> >sender and know the content is safe
> >
> >On Sun, Mar 29, 2020 at 10:36 PM Pragnesh Patel
> > wrote:
> >>
> >> This series add support for SPL to FU540.U-Boot SPL can boot from
> >> L2 LIM (0x0800_) and jump to OpenSBI(FW_DYNAMIC firmware) and
> >> U-Boot proper from MMC devices.
> >>
> >> How to test this patch:
> >> 1) Go to OpenSBI-dir : make PLATFORM=sifive/fu540 O=build_dir
> >> I=install_dir FW_DYNAMIC=y install
> >> 2) cp install_dir/platform/sifive/fu540/firmware/fw_dynamic.bin
> >> /
> >
> >I think setting
> >OPENSBI= >ynamic.bin>
> >would help to attach the opensbi instead of copying into the source 
> >directory.
> >Would you please check that.
>
> Yes that will also work, if I need to submit v7 then will update this.

Thanks, please wait for sometime I'll send my comments for the rest of
the patches.

Jagan.

RE: [PATCH v6 00/17] RISC-V SiFive FU540 support SPL

[Pragnesh Patel]

Hi Jagan,

>-Original Message-
>From: Jagan Teki 
>Sent: 02 April 2020 14:42
>To: Pragnesh Patel 
>Cc: U-Boot-Denx ; Atish Patra
>; palmerdabb...@google.com; Bin Meng
>; Paul Walmsley ; Troy
>Benjegerdes ; Anup Patel
>; Sagar Kadam ; Rick Chen
>
>Subject: Re: [PATCH v6 00/17] RISC-V SiFive FU540 support SPL
>
>[External Email] Do not click links or attachments unless you recognize the
>sender and know the content is safe
>
>On Sun, Mar 29, 2020 at 10:36 PM Pragnesh Patel
> wrote:
>>
>> This series add support for SPL to FU540.U-Boot SPL can boot from
>> L2 LIM (0x0800_) and jump to OpenSBI(FW_DYNAMIC firmware) and
>> U-Boot proper from MMC devices.
>>
>> How to test this patch:
>> 1) Go to OpenSBI-dir : make PLATFORM=sifive/fu540 O=build_dir
>> I=install_dir FW_DYNAMIC=y install
>> 2) cp install_dir/platform/sifive/fu540/firmware/fw_dynamic.bin
>> /
>
>I think setting
>OPENSBI=ynamic.bin>
>would help to attach the opensbi instead of copying into the source directory.
>Would you please check that.

Yes that will also work, if I need to submit v7 then will update this.

>
>Jagan.