| Message ID | 20190617073252.27810-1-jagan@amarulasolutions.com |
|---|---|
| Headers |
Return-Path: <linux-amarula+bncBD7MFH7A7EEBB5MFTXUAKGQEEGR2S4Y@amarulasolutions.com> X-Original-To: linux-amarula@patchwork.amarulasolutions.com Delivered-To: linux-amarula@patchwork.amarulasolutions.com Received: from mail-pg1-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) by ganimede.amarulasolutions.com (Postfix) with ESMTPS id 78C3B3F072 for <linux-amarula@patchwork.amarulasolutions.com>; Mon, 17 Jun 2019 09:36:23 +0200 (CEST) Received: by mail-pg1-f197.google.com with SMTP id c18sf7219622pgk.2 for <linux-amarula@patchwork.amarulasolutions.com>; Mon, 17 Jun 2019 00:36:23 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1560756981; cv=pass; d=google.com; s=arc-20160816; b=WfOM5yeWZV+M2aKWTwAvPJmxOB1tU8rpJPGFku6wvuzR6UGr+BQXvCBGY/gpM1kM8M cZSBuSHzAqOtyH2l8f2fPtCvugsbRQq+fP6LVv2pFeVWoUdvMWkbjp605oVzs5Dft3Qa YhmFBaZDvmfNZXIUpNczXUpIRuC6o9KX9ullRwZyGiZgta62G9uC78mvIKeADlH6UJLr AqY5arGMCmyiQmSwgDuB/A0Kp8iFAeF/AJuV9U7GX5o2KlbXAB7rP4etE7nZkrB3ARC4 ydG1NYvkjYAFbZTe7ed+9kjah8jehoCm1pKj4+8MaGoV5CTYyUWaWQBF/rARBcrjG5n3 xskQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-archive:list-help:list-post:list-id :mailing-list:precedence:mime-version:message-id:date:subject:cc:to :from:dkim-signature; bh=gF4m2wKGsrwlhWuZLmHRRkykbkoIyWoac53uhd9WsVg=; b=tPg+oeVsp/9X8gu+pXZtSEcFYov+HiScFUfX1gg1cZEPV1KZTnBM3tK4UYFavUCMt3 i1N6rfHdhtlknCjI2PTdE+izB+LM5wXD4SGGFo06FI1GPvvhEoZrn/ZVurUMvd+Zplck H4TkFFIy/SgTUyU8yQOTrPSVghW8l0j7eALiJgqTmxz+RGgAhFDoLAasVCoBZGrven18 XCY2jdVihSBIe0Mt+DO7+A8WzfxVbhIr9U5+qf5lE0hx69cOZm79+tRzZ+VGF5+utpRD X3b5zENzWYdLngbGW/EjkxZlNS373M0RxMBZIwkeglPJzbQveP00P/583faRywHsWFlg pr3g== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b="RmBkV/9u"; spf=pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=jagan@amarulasolutions.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=from:to:cc:subject:date:message-id:mime-version:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-unsubscribe; bh=gF4m2wKGsrwlhWuZLmHRRkykbkoIyWoac53uhd9WsVg=; b=Mt81HM5d6sUMNi38bR1S39/03ZJF00H9JQOMy5RrwNMlKUeCTdjn4WLO3P2pONC9e5 yOAcNR1HaEl9TlE9Skm/JAGGDXDkgXj5KgN/rwCayLixDUDJz0VgpUPjFr9zyqAyvr2J zjlhcLWt9jk4bD0wzB5XFzBKFAhVNeAI580tA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :x-original-sender:x-original-authentication-results:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-unsubscribe; bh=gF4m2wKGsrwlhWuZLmHRRkykbkoIyWoac53uhd9WsVg=; b=PUomcbywGtIoi3TAutxNeWlHUI9rZmE1WPSkJtofTzkNrMi+YXGNQqHQ2MF85sCB2F POnUgc6JZ4yh9JNNylEUeNV00NAbYJWNAUm4dVelQFFFffvnOyCfyZFsBaMYAj6qjfRd PAAfJkn766+eM8T8+WsdEP6apdPhYCNW9Jc5/G8Ke2h5IXDpAQ65F6YgQkUvJwFTMsEN 0JboHmBWWh7qbpYSE83fUMkfTv2XTe0uSBLO9bs23pHfhsmXNn5nLZDPFjDSNd1UDgNN SNTI2Rb4p+Auzt2inLtfxCpeV2w7BlYIY0Y27fjBnGZb2vnc38zSNHYEbz+ZGw59T3Nc uS6w== X-Gm-Message-State: APjAAAXRG7kLAglLlqVBcC3vpBdTH8YfRgiOAMfqk0Jx3hNGrox+wjp0 7PVfwGL7JbB9kTrb2wRkxC12AXkH X-Google-Smtp-Source: APXvYqxh8LVuGMwfhMDlW61l18kDLtfGCRX2WlBSSEuRbi/9NQeR4Qw36YXsXDZ7lIxyFUVoYA3qpw== X-Received: by 2002:a17:902:d915:: with SMTP id c21mr40420129plz.335.1560756981540; Mon, 17 Jun 2019 00:36:21 -0700 (PDT) X-BeenThere: linux-amarula@amarulasolutions.com Received: by 2002:a62:e509:: with SMTP id n9ls3378502pff.2.gmail; Mon, 17 Jun 2019 00:36:21 -0700 (PDT) X-Received: by 2002:a63:c10d:: with SMTP id w13mr12234193pgf.28.1560756981085; Mon, 17 Jun 2019 00:36:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560756981; cv=none; d=google.com; s=arc-20160816; b=SBMeR04hkWtWmhyYn4Jk08Vau8UqDG/5HIeUZMpe3f/Ltr21+cZjRoBjuKeEQ/7L4l zymS/IhQeRdP7v6qCZp+KQH12X8QCpAM68iJScOM9a9xPyHJJcFI5PgQu2iLGuw2CsxR qS7cv1uKHEYKsz+c1AY32bzipkDvlbiwzcfAzQkpDMOlIlR9ve0fVUmI8CVAQRXzSifV nDFpzWe69cyZSYYseQSaGoPV6daM/xQ2IllsowMzD0hYRzM0EFnvGraIuIjUF+qxfehO 4ueEjY4KCqhrtxTJZArncF0Bt2jbqPVyzdKhlHhVKSdr4yT8ceH8TEKA6LmrkdvTS6wG QimQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:dkim-signature; bh=ZQQ+LJToCvj/yOSoVEzFfc8kBIaWvwzKHeIKUA4bZaA=; b=Sit0bmTwLGEsj2UMB8t9fgbOex+xfR+LKiAdRtpUVskxiQ/Qd770EYIHACo+NTC1gX JkdBy1FsiqJIBy2y2Ol51dd3L/tcSjyl1wMhkYT1NR7sSq0oFS10Gl6hg8sCTXtKYgqp hQxA0+xCfSBDSjbgAdBjSN7vWN/pazI85y2tGBaVZM1XfWeSyjAl8JFQyjrJGi2NDfGh dCErCMNAk3ziSql1R1DYJQmFWSMgEMns33ePecIa5lGAaBXaDizBvPRrXecpUDOBMpg4 VMzbWOjLRYPPBKVftywOM8e3duxST6k8GzBF1Yjzi9SwcHrrGKTYnBvROWyLPyW+sby5 v0Fg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b="RmBkV/9u"; spf=pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=jagan@amarulasolutions.com Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id x9sor12500633plv.3.2019.06.17.00.36.20 for <linux-amarula@amarulasolutions.com> (Google Transport Security); Mon, 17 Jun 2019 00:36:20 -0700 (PDT) Received-SPF: pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; X-Received: by 2002:a17:902:27a8:: with SMTP id d37mr107097865plb.150.1560756979645; Mon, 17 Jun 2019 00:36:19 -0700 (PDT) Received: from localhost.localdomain ([49.206.203.245]) by smtp.gmail.com with ESMTPSA id m41sm15205998pje.18.2019.06.17.00.36.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jun 2019 00:36:19 -0700 (PDT) From: Jagan Teki <jagan@amarulasolutions.com> To: Simon Glass <sjg@chromium.org>, Philipp Tomsich <philipp.tomsich@theobroma-systems.com>, Kever Yang <kever.yang@rock-chips.com>, YouMin Chen <cym@rock-chips.com>, u-boot@lists.denx.de Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>, gajjar04akash@gmail.com, linux-rockchip@lists.infradead.org, linux-amarula@amarulasolutions.com, Jagan Teki <jagan@amarulasolutions.com> Subject: [PATCH v2 00/99] ram: rk3399: Add LPDDR4 support Date: Mon, 17 Jun 2019 13:01:13 +0530 Message-Id: <20190617073252.27810-1-jagan@amarulasolutions.com> X-Mailer: git-send-email 2.18.0.321.gffc6fa0e3 MIME-Version: 1.0 X-Original-Sender: jagan@amarulasolutions.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b="RmBkV/9u"; spf=pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=jagan@amarulasolutions.com Content-Type: text/plain; charset="UTF-8" Precedence: list Mailing-list: list linux-amarula@amarulasolutions.com; contact linux-amarula+owners@amarulasolutions.com List-ID: <linux-amarula.amarulasolutions.com> X-Spam-Checked-In-Group: linux-amarula@amarulasolutions.com X-Google-Group-Id: 476853432473 List-Post: <https://groups.google.com/a/amarulasolutions.com/group/linux-amarula/post>, <mailto:linux-amarula@amarulasolutions.com> List-Help: <https://support.google.com/a/amarulasolutions.com/bin/topic.py?topic=25838>, <mailto:linux-amarula+help@amarulasolutions.com> List-Archive: <https://groups.google.com/a/amarulasolutions.com/group/linux-amarula/> List-Unsubscribe: <mailto:googlegroups-manage+476853432473+unsubscribe@googlegroups.com>, <https://groups.google.com/a/amarulasolutions.com/group/linux-amarula/subscribe> |
| Series |
ram: rk3399: Add LPDDR4 support
|
|
Message
Jagan Teki
June 17, 2019, 7:31 a.m. UTC
This is the v2 set for supporting LPDDR4 with associated features, wrt to previous series[1]. Thanks to - YouMin Chen - Akash Gajjar - Kever Yang for supporting all the help on this work. On summary this series support - Code warning and fixes - rank detection, this would required to probe single channel sdram configured in NanoPI-NEO4 - LPDDR4 support, tested in Rockpro64 and Rock-PI-4 Changes for v2: - handle LPDDR4 code as part of CONFIG_RAM_RK3399_LPDDR4 - support data_training and set_rate via sdram_rk3399_ops - add proper sys_reg_enc macros - add new patch to rename variable sdram_params with params - fix few commit messages patch 0001 - 0034: fix code warnings, prints, new macros patch 0035 - 0052: rank detection, sdram debug code patch 0053: use DDR3-1800 on NanoPI-NEO4 patch 0054 - 0094: lpddr4 support patch 0095: enable lpddr4 in Rockpro64 patch 0096: enable lpddr4 in Rock-PI-4 patch 0097: LPDDR4-100 timings patch 0098: Use LPDDR4-100 on Rockpro64 patch 0099: Use LPDDR4-100 on Rock-PI 4 Size (increased to ~3KiB ): - Puma RK3399 (u-boot-spl-dtb.bin): before: 115644 after: 118744 - NanoPI M4 (u-boot-tpl-dtb.bin) before: 41873 after: 44909 Travis-CI: https://travis-ci.org/openedev/u-boot-amarula/builds/546597944 Repo: https://github.com/openedev/u-boot-amarula/tree/rk3399-lpddr4 [1] https://patchwork.ozlabs.org/cover/1113893/ Any inputs? Jagan. Jagan Teki (99): ram: rk3399: Fix code warnings ram: rk3399: Add space between string with format specifier ram: rk3399: Add proper spaces in code ram: rk3399: s/sdram_params/params ram: rk3399: Handle data training return types ram: rk3399: Order include files ram: rk3399: Move macro after include files ram: rk3399: Clear PI_175 interrupts in data training ram: rk3399: Use rank mask in ca data training ram: rk3399: Use rank mask in wdql data training ram: rk3399: Add ddrtype enc macro ram: rk3399: Add channel number encoder macro ram: rk3399: Add row_3_4 enc macro ram: rk3399: Add chipinfo macro ram: rk3399: Add rank enc macro ram: rk3399: Add column enc macro ram: rk3399: Add bk enc macro ram: rk3399: Add dbw enc macro ram: rk3399: Add cs0_rw macro ram: rk3399: Add cs1_rw macro ram: rk3399: Add bw enc macro ram: rk3399: Rename sys_reg with sys_reg2 ram: rk3399: Update cs0_row to use sys_reg3 ram: rk3399: Update cs1_row to use sys_reg3 ram: rk3399: Add cs1_col enc macro ram: rk3399: Add ddr version enc macro ram: rk3399: Add ddrtimingC0 ram: rk3399: Add DdrMode ram: rk3399: Handle pctl_cfg return type ram: rk3399: s/tsel_wr_select_n/tsel_wr_select_dq_n ram: rk3399: s/tsel_wr_select_p/tsel_wr_select_dq_p ram: rk3399: s/ca_tsel_wr_select_n/tsel_wr_select_ca_n ram: rk3399: s/ca_tsel_wr_select_p/tsel_wr_select_ca_p ram: rk3399: Order tsel variables ram: rk3399: Add phy pctrl reset support ram: rk3399: Move pwrup_srefresh_exit to dram_info ram: rk3399: Add pctl start support ram: rockchip: rk3399: Add cap_info structure ram: rk3399: s/rk3399_base_params/sdram_base_params ram: rk3399: Move common sdram structures in common header arm: include: rockchip: Move dramtypes to common header arm: include: rockchip: Add DDR4 enum ram: rockchip: Add initial Kconfig debug_uart: Add printdec ram: rockchip: Add debug sdram driver ram: rockchip: debug: Add sdram_print_ddr_info ram: rockchip: debug: Get the cs capacity ram: rk3399: debug: Add sdram_print_stride ram: rk3399: Compute stride for 2 channels ram: rk3399: Compute stride for 1 channel a ram: rk3399: Add rank detection support ram: rk3399: Enable sdram debug functions rockchip: dts: rk3399: nanopi-neo4: Use DDR3-1866 dtsi clk: rockchip: rk3399: Fix check patch warnings and checks clk: rockchip: rk3399: Set 50MHz ddr clock clk: rockchip: rk3399: Set 400MHz ddr clock ram: rk3399: Add spaces in pctl_cfg ram: rk3399: Configure phy IO in ds odt ram: rockchip: Kconfig: Add RK3399 LPDDR4 entry ram: rk3399: Add lpddr4 rank mask for ca training ram: rk3399: Add lpddr4 rank mask for wdql training ram: rk3399: Move mode_sel assignment ram: rk3399: Don't wait for PLL lock in lpddr4 ram: rk3399: Avoid two channel ZQ Cal Start at the same time ram: rk3399: Configure PHY_898, PHY_919 for lpddr4 ram: rk3399: Configure BOOSTP_EN, BOOSTN_EN for lpddr4 ram: rk3399: Configure SLEWP_EN, SLEWN_EN for lpddr4 ram: rk3399: Configure PHY RX_CM_INPUT for lpddr4 ram: rk3399: Map chipselect for lpddr4 ram: rk3399: Configure tsel write ca for lpddr4 ram: rk3399: Don't disable dfi dram clk for lpddr4, rank 1 ram: rk3399: Add IO settings ram: sdram: Configure lpddr4 tsel rd, wr based on IO settings ram: rk3399: Add tsel control clock drive ram: rk3399: Configure soc odt support ram: rk3399: Get lpddr4 tsel_rd_en from io settings ram: rk3399: Update lpddr4 vref based on io settings ram: rk3399: Update lpddr4 mode_sel based on io settings ram: rk3399: Update lpddr4 vref_mode_ac ram: rk3399: Simplify data training first argument ram: rk3399: Handle data training via ops ram: rk3399: Add LPPDR4 mr detection arm: include: rockchip: Add rk3399 pmu file rockchip: rk3399: syscon: Add pmu support rockchip: dts: rk3399: Add u-boot,dm-pre-reloc for pmu ram: rk3399: Add LPPDDR4-400 timings inc ram: rk3399: Add LPPDDR4-800 timings inc ram: rk3399: Add set_rate sdram rk3399 ops ram: rk3399: Add lpddr4 set rate support ram: rk3399: Set lpddr4 dq odt ram: rk3399: Set lpddr4 ca odt ram: rk3399: Set lpddr4 MR3 ram: rk3399: Set lpddr4 MR12 ram: rk3399: Set lpddr4 MR14 configs: rockpro64: Enable LPDDR4 support configs: rock-pi-4: Enable LPDDR4 support rockchip: dts: rk3399: Add LPDDR4-100 timings rockchip: dts: rk3399: rockpro64: Use LPDDR4-100 dtsi rockchip: dts: rk3399: rock-pi-4: Use LPDDR4-100 dtsi arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi | 1 + arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi | 1 + arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 1 + arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi | 1537 +++++++++++ arch/arm/dts/rk3399-u-boot.dtsi | 4 + .../include/asm/arch-rockchip/pmu_rk3399.h | 72 + arch/arm/include/asm/arch-rockchip/sdram.h | 6 - .../include/asm/arch-rockchip/sdram_common.h | 90 + .../include/asm/arch-rockchip/sdram_rk322x.h | 7 - .../include/asm/arch-rockchip/sdram_rk3399.h | 65 +- arch/arm/mach-rockchip/rk3399/syscon_rk3399.c | 8 + configs/rock-pi-4-rk3399_defconfig | 1 + configs/rockpro64-rk3399_defconfig | 1 + drivers/clk/rockchip/clk_rk3399.c | 76 +- drivers/ram/Kconfig | 1 + drivers/ram/rockchip/Kconfig | 33 + drivers/ram/rockchip/Makefile | 3 +- .../ram/rockchip/sdram-rk3399-lpddr4-400.inc | 1570 +++++++++++ .../ram/rockchip/sdram-rk3399-lpddr4-800.inc | 1570 +++++++++++ drivers/ram/rockchip/sdram_debug.c | 147 ++ drivers/ram/rockchip/sdram_rk3399.c | 2289 ++++++++++++++--- include/debug_uart.h | 19 + 22 files changed, 7035 insertions(+), 467 deletions(-) create mode 100644 arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi create mode 100644 arch/arm/include/asm/arch-rockchip/pmu_rk3399.h create mode 100644 drivers/ram/rockchip/Kconfig create mode 100644 drivers/ram/rockchip/sdram-rk3399-lpddr4-400.inc create mode 100644 drivers/ram/rockchip/sdram-rk3399-lpddr4-800.inc create mode 100644 drivers/ram/rockchip/sdram_debug.c
Comments
On Mon, Jun 17, 2019 at 12:37 AM Jagan Teki <jagan@amarulasolutions.com> wrote: > > This is the v2 set for supporting LPDDR4 with associated > features, wrt to previous series[1]. > > Thanks to > - YouMin Chen > - Akash Gajjar > - Kever Yang > for supporting all the help on this work. > > On summary this series support > - Code warning and fixes > - rank detection, this would required to probe single channel > sdram configured in NanoPI-NEO4 > - LPDDR4 support, tested in Rockpro64 and Rock-PI-4 > > Changes for v2: > - handle LPDDR4 code as part of CONFIG_RAM_RK3399_LPDDR4 > - support data_training and set_rate via sdram_rk3399_ops > - add proper sys_reg_enc macros > - add new patch to rename variable sdram_params with params > - fix few commit messages > > patch 0001 - 0034: fix code warnings, prints, new macros > > patch 0035 - 0052: rank detection, sdram debug code > > patch 0053: use DDR3-1800 on NanoPI-NEO4 > > patch 0054 - 0094: lpddr4 support > > patch 0095: enable lpddr4 in Rockpro64 > > patch 0096: enable lpddr4 in Rock-PI-4 > > patch 0097: LPDDR4-100 timings > > patch 0098: Use LPDDR4-100 on Rockpro64 > > patch 0099: Use LPDDR4-100 on Rock-PI 4 > > Size (increased to ~3KiB ): > - Puma RK3399 (u-boot-spl-dtb.bin): > before: 115644 after: 118744 > - NanoPI M4 (u-boot-tpl-dtb.bin) > before: 41873 after: 44909 > > Travis-CI: > https://travis-ci.org/openedev/u-boot-amarula/builds/546597944 > > Repo: > https://github.com/openedev/u-boot-amarula/tree/rk3399-lpddr4 > > [1] https://patchwork.ozlabs.org/cover/1113893/ > > Any inputs? Was it absolutely necessary to split these changes into 99 commits? I believe at least some of them can be squashed. Reviewing 99 patches isn't feasible. > Jagan. > > Jagan Teki (99): > ram: rk3399: Fix code warnings > ram: rk3399: Add space between string with format specifier > ram: rk3399: Add proper spaces in code > ram: rk3399: s/sdram_params/params > ram: rk3399: Handle data training return types > ram: rk3399: Order include files > ram: rk3399: Move macro after include files > ram: rk3399: Clear PI_175 interrupts in data training > ram: rk3399: Use rank mask in ca data training > ram: rk3399: Use rank mask in wdql data training > ram: rk3399: Add ddrtype enc macro > ram: rk3399: Add channel number encoder macro > ram: rk3399: Add row_3_4 enc macro > ram: rk3399: Add chipinfo macro > ram: rk3399: Add rank enc macro > ram: rk3399: Add column enc macro > ram: rk3399: Add bk enc macro > ram: rk3399: Add dbw enc macro > ram: rk3399: Add cs0_rw macro > ram: rk3399: Add cs1_rw macro > ram: rk3399: Add bw enc macro > ram: rk3399: Rename sys_reg with sys_reg2 > ram: rk3399: Update cs0_row to use sys_reg3 > ram: rk3399: Update cs1_row to use sys_reg3 > ram: rk3399: Add cs1_col enc macro > ram: rk3399: Add ddr version enc macro > ram: rk3399: Add ddrtimingC0 > ram: rk3399: Add DdrMode > ram: rk3399: Handle pctl_cfg return type > ram: rk3399: s/tsel_wr_select_n/tsel_wr_select_dq_n > ram: rk3399: s/tsel_wr_select_p/tsel_wr_select_dq_p > ram: rk3399: s/ca_tsel_wr_select_n/tsel_wr_select_ca_n > ram: rk3399: s/ca_tsel_wr_select_p/tsel_wr_select_ca_p > ram: rk3399: Order tsel variables > ram: rk3399: Add phy pctrl reset support > ram: rk3399: Move pwrup_srefresh_exit to dram_info > ram: rk3399: Add pctl start support > ram: rockchip: rk3399: Add cap_info structure > ram: rk3399: s/rk3399_base_params/sdram_base_params > ram: rk3399: Move common sdram structures in common header > arm: include: rockchip: Move dramtypes to common header > arm: include: rockchip: Add DDR4 enum > ram: rockchip: Add initial Kconfig > debug_uart: Add printdec > ram: rockchip: Add debug sdram driver > ram: rockchip: debug: Add sdram_print_ddr_info > ram: rockchip: debug: Get the cs capacity > ram: rk3399: debug: Add sdram_print_stride > ram: rk3399: Compute stride for 2 channels > ram: rk3399: Compute stride for 1 channel a > ram: rk3399: Add rank detection support > ram: rk3399: Enable sdram debug functions > rockchip: dts: rk3399: nanopi-neo4: Use DDR3-1866 dtsi > clk: rockchip: rk3399: Fix check patch warnings and checks > clk: rockchip: rk3399: Set 50MHz ddr clock > clk: rockchip: rk3399: Set 400MHz ddr clock > ram: rk3399: Add spaces in pctl_cfg > ram: rk3399: Configure phy IO in ds odt > ram: rockchip: Kconfig: Add RK3399 LPDDR4 entry > ram: rk3399: Add lpddr4 rank mask for ca training > ram: rk3399: Add lpddr4 rank mask for wdql training > ram: rk3399: Move mode_sel assignment > ram: rk3399: Don't wait for PLL lock in lpddr4 > ram: rk3399: Avoid two channel ZQ Cal Start at the same time > ram: rk3399: Configure PHY_898, PHY_919 for lpddr4 > ram: rk3399: Configure BOOSTP_EN, BOOSTN_EN for lpddr4 > ram: rk3399: Configure SLEWP_EN, SLEWN_EN for lpddr4 > ram: rk3399: Configure PHY RX_CM_INPUT for lpddr4 > ram: rk3399: Map chipselect for lpddr4 > ram: rk3399: Configure tsel write ca for lpddr4 > ram: rk3399: Don't disable dfi dram clk for lpddr4, rank 1 > ram: rk3399: Add IO settings > ram: sdram: Configure lpddr4 tsel rd, wr based on IO settings > ram: rk3399: Add tsel control clock drive > ram: rk3399: Configure soc odt support > ram: rk3399: Get lpddr4 tsel_rd_en from io settings > ram: rk3399: Update lpddr4 vref based on io settings > ram: rk3399: Update lpddr4 mode_sel based on io settings > ram: rk3399: Update lpddr4 vref_mode_ac > ram: rk3399: Simplify data training first argument > ram: rk3399: Handle data training via ops > ram: rk3399: Add LPPDR4 mr detection > arm: include: rockchip: Add rk3399 pmu file > rockchip: rk3399: syscon: Add pmu support > rockchip: dts: rk3399: Add u-boot,dm-pre-reloc for pmu > ram: rk3399: Add LPPDDR4-400 timings inc > ram: rk3399: Add LPPDDR4-800 timings inc > ram: rk3399: Add set_rate sdram rk3399 ops > ram: rk3399: Add lpddr4 set rate support > ram: rk3399: Set lpddr4 dq odt > ram: rk3399: Set lpddr4 ca odt > ram: rk3399: Set lpddr4 MR3 > ram: rk3399: Set lpddr4 MR12 > ram: rk3399: Set lpddr4 MR14 > configs: rockpro64: Enable LPDDR4 support > configs: rock-pi-4: Enable LPDDR4 support > rockchip: dts: rk3399: Add LPDDR4-100 timings > rockchip: dts: rk3399: rockpro64: Use LPDDR4-100 dtsi > rockchip: dts: rk3399: rock-pi-4: Use LPDDR4-100 dtsi > > arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi | 1 + > arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi | 1 + > arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 1 + > arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi | 1537 +++++++++++ > arch/arm/dts/rk3399-u-boot.dtsi | 4 + > .../include/asm/arch-rockchip/pmu_rk3399.h | 72 + > arch/arm/include/asm/arch-rockchip/sdram.h | 6 - > .../include/asm/arch-rockchip/sdram_common.h | 90 + > .../include/asm/arch-rockchip/sdram_rk322x.h | 7 - > .../include/asm/arch-rockchip/sdram_rk3399.h | 65 +- > arch/arm/mach-rockchip/rk3399/syscon_rk3399.c | 8 + > configs/rock-pi-4-rk3399_defconfig | 1 + > configs/rockpro64-rk3399_defconfig | 1 + > drivers/clk/rockchip/clk_rk3399.c | 76 +- > drivers/ram/Kconfig | 1 + > drivers/ram/rockchip/Kconfig | 33 + > drivers/ram/rockchip/Makefile | 3 +- > .../ram/rockchip/sdram-rk3399-lpddr4-400.inc | 1570 +++++++++++ > .../ram/rockchip/sdram-rk3399-lpddr4-800.inc | 1570 +++++++++++ > drivers/ram/rockchip/sdram_debug.c | 147 ++ > drivers/ram/rockchip/sdram_rk3399.c | 2289 ++++++++++++++--- > include/debug_uart.h | 19 + > 22 files changed, 7035 insertions(+), 467 deletions(-) > create mode 100644 arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi > create mode 100644 arch/arm/include/asm/arch-rockchip/pmu_rk3399.h > create mode 100644 drivers/ram/rockchip/Kconfig > create mode 100644 drivers/ram/rockchip/sdram-rk3399-lpddr4-400.inc > create mode 100644 drivers/ram/rockchip/sdram-rk3399-lpddr4-800.inc > create mode 100644 drivers/ram/rockchip/sdram_debug.c > > -- > 2.18.0.321.gffc6fa0e3 > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot
> From: Jagan Teki <jagan@amarulasolutions.com> > Date: Mon, 17 Jun 2019 13:01:13 +0530 > > This is the v2 set for supporting LPDDR4 with associated > features, wrt to previous series[1]. > > Thanks to > - YouMin Chen > - Akash Gajjar > - Kever Yang > for supporting all the help on this work. > > On summary this series support > - Code warning and fixes > - rank detection, this would required to probe single channel > sdram configured in NanoPI-NEO4 > - LPDDR4 support, tested in Rockpro64 and Rock-PI-4 > > Changes for v2: > - handle LPDDR4 code as part of CONFIG_RAM_RK3399_LPDDR4 > - support data_training and set_rate via sdram_rk3399_ops > - add proper sys_reg_enc macros > - add new patch to rename variable sdram_params with params > - fix few commit messages > > patch 0001 - 0034: fix code warnings, prints, new macros > > patch 0035 - 0052: rank detection, sdram debug code > > patch 0053: use DDR3-1800 on NanoPI-NEO4 > > patch 0054 - 0094: lpddr4 support > > patch 0095: enable lpddr4 in Rockpro64 > > patch 0096: enable lpddr4 in Rock-PI-4 > > patch 0097: LPDDR4-100 timings > > patch 0098: Use LPDDR4-100 on Rockpro64 > > patch 0099: Use LPDDR4-100 on Rock-PI 4 > > Size (increased to ~3KiB ): > - Puma RK3399 (u-boot-spl-dtb.bin): > before: 115644 after: 118744 > - NanoPI M4 (u-boot-tpl-dtb.bin) > before: 41873 after: 44909 > > Travis-CI: > https://travis-ci.org/openedev/u-boot-amarula/builds/546597944 > > Repo: > https://github.com/openedev/u-boot-amarula/tree/rk3399-lpddr4 > > [1] https://patchwork.ozlabs.org/cover/1113893/ > > Any inputs? > Jagan. > > Jagan Teki (99): > ram: rk3399: Fix code warnings > ram: rk3399: Add space between string with format specifier > ram: rk3399: Add proper spaces in code > ram: rk3399: s/sdram_params/params > ram: rk3399: Handle data training return types > ram: rk3399: Order include files > ram: rk3399: Move macro after include files > ram: rk3399: Clear PI_175 interrupts in data training > ram: rk3399: Use rank mask in ca data training > ram: rk3399: Use rank mask in wdql data training > ram: rk3399: Add ddrtype enc macro > ram: rk3399: Add channel number encoder macro > ram: rk3399: Add row_3_4 enc macro > ram: rk3399: Add chipinfo macro > ram: rk3399: Add rank enc macro > ram: rk3399: Add column enc macro > ram: rk3399: Add bk enc macro > ram: rk3399: Add dbw enc macro > ram: rk3399: Add cs0_rw macro > ram: rk3399: Add cs1_rw macro > ram: rk3399: Add bw enc macro > ram: rk3399: Rename sys_reg with sys_reg2 > ram: rk3399: Update cs0_row to use sys_reg3 > ram: rk3399: Update cs1_row to use sys_reg3 > ram: rk3399: Add cs1_col enc macro > ram: rk3399: Add ddr version enc macro > ram: rk3399: Add ddrtimingC0 > ram: rk3399: Add DdrMode > ram: rk3399: Handle pctl_cfg return type > ram: rk3399: s/tsel_wr_select_n/tsel_wr_select_dq_n > ram: rk3399: s/tsel_wr_select_p/tsel_wr_select_dq_p > ram: rk3399: s/ca_tsel_wr_select_n/tsel_wr_select_ca_n > ram: rk3399: s/ca_tsel_wr_select_p/tsel_wr_select_ca_p > ram: rk3399: Order tsel variables > ram: rk3399: Add phy pctrl reset support > ram: rk3399: Move pwrup_srefresh_exit to dram_info > ram: rk3399: Add pctl start support > ram: rockchip: rk3399: Add cap_info structure > ram: rk3399: s/rk3399_base_params/sdram_base_params > ram: rk3399: Move common sdram structures in common header > arm: include: rockchip: Move dramtypes to common header > arm: include: rockchip: Add DDR4 enum > ram: rockchip: Add initial Kconfig > debug_uart: Add printdec > ram: rockchip: Add debug sdram driver > ram: rockchip: debug: Add sdram_print_ddr_info > ram: rockchip: debug: Get the cs capacity > ram: rk3399: debug: Add sdram_print_stride > ram: rk3399: Compute stride for 2 channels > ram: rk3399: Compute stride for 1 channel a > ram: rk3399: Add rank detection support > ram: rk3399: Enable sdram debug functions > rockchip: dts: rk3399: nanopi-neo4: Use DDR3-1866 dtsi > clk: rockchip: rk3399: Fix check patch warnings and checks > clk: rockchip: rk3399: Set 50MHz ddr clock > clk: rockchip: rk3399: Set 400MHz ddr clock > ram: rk3399: Add spaces in pctl_cfg > ram: rk3399: Configure phy IO in ds odt > ram: rockchip: Kconfig: Add RK3399 LPDDR4 entry > ram: rk3399: Add lpddr4 rank mask for ca training > ram: rk3399: Add lpddr4 rank mask for wdql training > ram: rk3399: Move mode_sel assignment > ram: rk3399: Don't wait for PLL lock in lpddr4 > ram: rk3399: Avoid two channel ZQ Cal Start at the same time > ram: rk3399: Configure PHY_898, PHY_919 for lpddr4 > ram: rk3399: Configure BOOSTP_EN, BOOSTN_EN for lpddr4 > ram: rk3399: Configure SLEWP_EN, SLEWN_EN for lpddr4 > ram: rk3399: Configure PHY RX_CM_INPUT for lpddr4 > ram: rk3399: Map chipselect for lpddr4 > ram: rk3399: Configure tsel write ca for lpddr4 > ram: rk3399: Don't disable dfi dram clk for lpddr4, rank 1 > ram: rk3399: Add IO settings > ram: sdram: Configure lpddr4 tsel rd, wr based on IO settings > ram: rk3399: Add tsel control clock drive > ram: rk3399: Configure soc odt support > ram: rk3399: Get lpddr4 tsel_rd_en from io settings > ram: rk3399: Update lpddr4 vref based on io settings > ram: rk3399: Update lpddr4 mode_sel based on io settings > ram: rk3399: Update lpddr4 vref_mode_ac > ram: rk3399: Simplify data training first argument > ram: rk3399: Handle data training via ops > ram: rk3399: Add LPPDR4 mr detection > arm: include: rockchip: Add rk3399 pmu file > rockchip: rk3399: syscon: Add pmu support > rockchip: dts: rk3399: Add u-boot,dm-pre-reloc for pmu > ram: rk3399: Add LPPDDR4-400 timings inc > ram: rk3399: Add LPPDDR4-800 timings inc > ram: rk3399: Add set_rate sdram rk3399 ops > ram: rk3399: Add lpddr4 set rate support > ram: rk3399: Set lpddr4 dq odt > ram: rk3399: Set lpddr4 ca odt > ram: rk3399: Set lpddr4 MR3 > ram: rk3399: Set lpddr4 MR12 > ram: rk3399: Set lpddr4 MR14 > configs: rockpro64: Enable LPDDR4 support > configs: rock-pi-4: Enable LPDDR4 support > rockchip: dts: rk3399: Add LPDDR4-100 timings > rockchip: dts: rk3399: rockpro64: Use LPDDR4-100 dtsi > rockchip: dts: rk3399: rock-pi-4: Use LPDDR4-100 dtsi > > arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi | 1 + > arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi | 1 + > arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 1 + > arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi | 1537 +++++++++++ > arch/arm/dts/rk3399-u-boot.dtsi | 4 + > .../include/asm/arch-rockchip/pmu_rk3399.h | 72 + > arch/arm/include/asm/arch-rockchip/sdram.h | 6 - > .../include/asm/arch-rockchip/sdram_common.h | 90 + > .../include/asm/arch-rockchip/sdram_rk322x.h | 7 - > .../include/asm/arch-rockchip/sdram_rk3399.h | 65 +- > arch/arm/mach-rockchip/rk3399/syscon_rk3399.c | 8 + > configs/rock-pi-4-rk3399_defconfig | 1 + > configs/rockpro64-rk3399_defconfig | 1 + > drivers/clk/rockchip/clk_rk3399.c | 76 +- > drivers/ram/Kconfig | 1 + > drivers/ram/rockchip/Kconfig | 33 + > drivers/ram/rockchip/Makefile | 3 +- > .../ram/rockchip/sdram-rk3399-lpddr4-400.inc | 1570 +++++++++++ > .../ram/rockchip/sdram-rk3399-lpddr4-800.inc | 1570 +++++++++++ > drivers/ram/rockchip/sdram_debug.c | 147 ++ > drivers/ram/rockchip/sdram_rk3399.c | 2289 ++++++++++++++--- > include/debug_uart.h | 19 + > 22 files changed, 7035 insertions(+), 467 deletions(-) > create mode 100644 arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi > create mode 100644 arch/arm/include/asm/arch-rockchip/pmu_rk3399.h > create mode 100644 drivers/ram/rockchip/Kconfig > create mode 100644 drivers/ram/rockchip/sdram-rk3399-lpddr4-400.inc > create mode 100644 drivers/ram/rockchip/sdram-rk3399-lpddr4-800.inc > create mode 100644 drivers/ram/rockchip/sdram_debug.c > > -- > 2.18.0.321.gffc6fa0e3 Tested on rockpro64 and firefly-rk3399. Both boards work with this diff provided I apply the two "boot-on" regulator diffs that I posted a couple of days ago. A significant improvement for rockpro64 and no regression for firefly-rk3399. So: Tested-by: Mark Kettenis <kettenis@openbsd.org>
Hi Vasily, On Fri, Jun 21, 2019 at 5:58 AM Vasily Khoruzhick <anarsoul@gmail.com> wrote: > > On Mon, Jun 17, 2019 at 12:37 AM Jagan Teki <jagan@amarulasolutions.com> wrote: > > > > This is the v2 set for supporting LPDDR4 with associated > > features, wrt to previous series[1]. > > > > Thanks to > > - YouMin Chen > > - Akash Gajjar > > - Kever Yang > > for supporting all the help on this work. > > > > On summary this series support > > - Code warning and fixes > > - rank detection, this would required to probe single channel > > sdram configured in NanoPI-NEO4 > > - LPDDR4 support, tested in Rockpro64 and Rock-PI-4 > > > > Changes for v2: > > - handle LPDDR4 code as part of CONFIG_RAM_RK3399_LPDDR4 > > - support data_training and set_rate via sdram_rk3399_ops > > - add proper sys_reg_enc macros > > - add new patch to rename variable sdram_params with params > > - fix few commit messages > > > > patch 0001 - 0034: fix code warnings, prints, new macros > > > > patch 0035 - 0052: rank detection, sdram debug code > > > > patch 0053: use DDR3-1800 on NanoPI-NEO4 > > > > patch 0054 - 0094: lpddr4 support > > > > patch 0095: enable lpddr4 in Rockpro64 > > > > patch 0096: enable lpddr4 in Rock-PI-4 > > > > patch 0097: LPDDR4-100 timings > > > > patch 0098: Use LPDDR4-100 on Rockpro64 > > > > patch 0099: Use LPDDR4-100 on Rock-PI 4 > > > > Size (increased to ~3KiB ): > > - Puma RK3399 (u-boot-spl-dtb.bin): > > before: 115644 after: 118744 > > - NanoPI M4 (u-boot-tpl-dtb.bin) > > before: 41873 after: 44909 > > > > Travis-CI: > > https://travis-ci.org/openedev/u-boot-amarula/builds/546597944 > > > > Repo: > > https://github.com/openedev/u-boot-amarula/tree/rk3399-lpddr4 > > > > [1] https://patchwork.ozlabs.org/cover/1113893/ > > > > Any inputs? > > Was it absolutely necessary to split these changes into 99 commits? I > believe at least some of them can be squashed. Reviewing 99 patches > isn't feasible. Squashed, I'm not sure because the patches were created to satisfy the bisectability and travis-ci, if you find any please feel to comment. About the commit count, I have mentioned in v1, the idea of having many commits in one series to have all lpddr4(-related) changes in one place and also all the commit has incremental approach of supporting rank detection and lpddr4. If require I'm open to sent next versions as multiple series, no problem on that. Jagan.
Hi Jagan, Thanks for your hard work. I'm sure everyone in the Rockchip community is excited about finally having this support in U-Boot. On Tue, 25 Jun 2019 at 12:46, Jagan Teki <jagan@amarulasolutions.com> wrote: [..] > > > > Was it absolutely necessary to split these changes into 99 commits? I > > believe at least some of them can be squashed. Reviewing 99 patches > > isn't feasible. > > Squashed, I'm not sure because the patches were created to satisfy the > bisectability and travis-ci, if you find any please feel to comment. > About the commit count, I have mentioned in v1, the idea of having > many commits in one series to have all lpddr4(-related) changes in one > place and also all the commit has incremental approach of supporting > rank detection and lpddr4. If require I'm open to sent next versions > as multiple series, no problem on that. > I strongly agree with Vasily, and I don't think multiple series makes it any better. What's the reason for having two commits for: "ram: rk3399: Set lpddr4 MR3" and "ram: rk3399: Set lpddr4 MR12" ? Or splitting all the "ram: rk3399: Add ... macro" ? What do you loose if you merge the patches into one? I must confess I am very surprised, and don't really understand what do you gain with this excessive split. Normally, when we are adding a new feature, we normally don't need many patches, so it's the other way around, really. Bisectability is about not breaking existing support, but because the feature is new, normally this is easy. Thanks again! Eze
On Wed, Jun 26, 2019 at 12:12 AM Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> wrote: > > Hi Jagan, > > Thanks for your hard work. I'm sure everyone in the Rockchip community > is excited about finally having this support in U-Boot. > > On Tue, 25 Jun 2019 at 12:46, Jagan Teki <jagan@amarulasolutions.com> wrote: > [..] > > > > > > Was it absolutely necessary to split these changes into 99 commits? I > > > believe at least some of them can be squashed. Reviewing 99 patches > > > isn't feasible. > > > > Squashed, I'm not sure because the patches were created to satisfy the > > bisectability and travis-ci, if you find any please feel to comment. > > About the commit count, I have mentioned in v1, the idea of having > > many commits in one series to have all lpddr4(-related) changes in one > > place and also all the commit has incremental approach of supporting > > rank detection and lpddr4. If require I'm open to sent next versions > > as multiple series, no problem on that. > > > > I strongly agree with Vasily, and I don't think multiple series makes it any > better. > > What's the reason for having two commits for: > > "ram: rk3399: Set lpddr4 MR3" and "ram: rk3399: Set lpddr4 MR12" ? These are individual lpddr4 set rate registers to support, each one is independent on it' own initialization and more over on the whole, it is critical to review. > > Or splitting all the "ram: rk3399: Add ... macro" ? You mean the patches 13 to 20 same like above each one has it's own meaning. It is not meaningful to squash them all. > > What do you loose if you merge the patches into one? > > I must confess I am very surprised, and don't really understand what do you > gain with this excessive split. Normally, when we are adding a new feature, > we normally don't need many patches, so it's the other way around, really. > > Bisectability is about not breaking existing support, but because the feature > is new, normally this is easy. Look, like the whole confusion seems to be because of more patches in one series and the cover-letter states that it support lpddr4. I understand it now, will send the relevant changes in next version accordingly, if require I will squash if any. Jagan.
Jagan, On 06/26/2019 06:22 PM, Jagan Teki wrote: > On Wed, Jun 26, 2019 at 12:12 AM Ezequiel Garcia > <ezequiel@vanguardiasur.com.ar> wrote: >> Hi Jagan, >> >> Thanks for your hard work. I'm sure everyone in the Rockchip community >> is excited about finally having this support in U-Boot. >> >> On Tue, 25 Jun 2019 at 12:46, Jagan Teki <jagan@amarulasolutions.com> wrote: >> [..] >>>> Was it absolutely necessary to split these changes into 99 commits? I >>>> believe at least some of them can be squashed. Reviewing 99 patches >>>> isn't feasible. >>> Squashed, I'm not sure because the patches were created to satisfy the >>> bisectability and travis-ci, if you find any please feel to comment. >>> About the commit count, I have mentioned in v1, the idea of having >>> many commits in one series to have all lpddr4(-related) changes in one >>> place and also all the commit has incremental approach of supporting >>> rank detection and lpddr4. If require I'm open to sent next versions >>> as multiple series, no problem on that. >>> >> I strongly agree with Vasily, and I don't think multiple series makes it any >> better. >> >> What's the reason for having two commits for: >> >> "ram: rk3399: Set lpddr4 MR3" and "ram: rk3399: Set lpddr4 MR12" ? > These are individual lpddr4 set rate registers to support, each one is > independent on it' own initialization and more over on the whole, it > is critical to review. > >> Or splitting all the "ram: rk3399: Add ... macro" ? > You mean the patches 13 to 20 same like above each one has it's own > meaning. It is not meaningful to squash them all. 99 patches is really too much, but I'm not sure how smaller it can be. Reference to kernel document, it suggest not more than 15 at one time: NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! <https://lkml.org/lkml/2005/7/11/336> But please note that I don't think split this into different series make any sense. But maybe you can try to squash as much as you can. eg. the update for dram_all_config may able to squash into one patch, and some new MACRO and its reference code may be able to squash. So it depends on how you define about _logical change_. I'm not sure if this have happen in the history of U-Boot mailing list, but I think this big patch set will be complained by many people if this is send to kernel. I would need to review all the code one by one, and merge them all at one time, so it does not affect much about my review, but for U-Boot patch submit requirement, I'm not sure if any suggestion from other maintainers. Thanks, - Kever >> What do you loose if you merge the patches into one? >> >> I must confess I am very surprised, and don't really understand what do you >> gain with this excessive split. Normally, when we are adding a new feature, >> we normally don't need many patches, so it's the other way around, really. >> >> Bisectability is about not breaking existing support, but because the feature >> is new, normally this is easy. > Look, like the whole confusion seems to be because of more patches in > one series and the cover-letter states that it support lpddr4. I > understand it now, will send the relevant changes in next version > accordingly, if require I will squash if any. > > Jagan. > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip >
Hi Kever, On Thu, Jul 4, 2019 at 3:57 PM Kever Yang <kever.yang@rock-chips.com> wrote: > > Jagan, > > > On 06/26/2019 06:22 PM, Jagan Teki wrote: > > On Wed, Jun 26, 2019 at 12:12 AM Ezequiel Garcia > <ezequiel@vanguardiasur.com.ar> wrote: > > Hi Jagan, > > Thanks for your hard work. I'm sure everyone in the Rockchip community > is excited about finally having this support in U-Boot. > > On Tue, 25 Jun 2019 at 12:46, Jagan Teki <jagan@amarulasolutions.com> wrote: > [..] > > Was it absolutely necessary to split these changes into 99 commits? I > believe at least some of them can be squashed. Reviewing 99 patches > isn't feasible. > > Squashed, I'm not sure because the patches were created to satisfy the > bisectability and travis-ci, if you find any please feel to comment. > About the commit count, I have mentioned in v1, the idea of having > many commits in one series to have all lpddr4(-related) changes in one > place and also all the commit has incremental approach of supporting > rank detection and lpddr4. If require I'm open to sent next versions > as multiple series, no problem on that. > > I strongly agree with Vasily, and I don't think multiple series makes it any > better. > > What's the reason for having two commits for: > > "ram: rk3399: Set lpddr4 MR3" and "ram: rk3399: Set lpddr4 MR12" ? > > These are individual lpddr4 set rate registers to support, each one is > independent on it' own initialization and more over on the whole, it > is critical to review. > > Or splitting all the "ram: rk3399: Add ... macro" ? > > You mean the patches 13 to 20 same like above each one has it's own > meaning. It is not meaningful to squash them all. > > > 99 patches is really too much, but I'm not sure how smaller it can be. > Reference to kernel document, it suggest not more than 15 at one time: Agreed. > NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! <https://lkml.org/lkml/2005/7/11/336> But please note that I don't think split this into different series make any sense. But maybe you can try to squash as much as you can. eg. the update for dram_all_config may able to squash into one patch, > and some new MACRO and its reference code may be able to squash. > So it depends on how you define about _logical change_. > I'm not sure if this have happen in the history of U-Boot mailing list, but > I think this big patch set will be complained by many people if this is send to > kernel. I don't mean to split the lpddr4 changes into multiple series. what I'm trying to say here is this series has patches that support code warnings, rank detection. Since each of them has it own identical features, I'm planning to send them first. and will squash what it require on lpddr4. Will that be okay for you?
Jagan, On 07/04/2019 06:54 PM, Jagan Teki wrote: > Hi Kever, > > On Thu, Jul 4, 2019 at 3:57 PM Kever Yang <kever.yang@rock-chips.com> wrote: >> Jagan, >> >> >> On 06/26/2019 06:22 PM, Jagan Teki wrote: >> >> On Wed, Jun 26, 2019 at 12:12 AM Ezequiel Garcia >> <ezequiel@vanguardiasur.com.ar> wrote: >> >> Hi Jagan, >> >> Thanks for your hard work. I'm sure everyone in the Rockchip community >> is excited about finally having this support in U-Boot. >> >> On Tue, 25 Jun 2019 at 12:46, Jagan Teki <jagan@amarulasolutions.com> wrote: >> [..] >> >> Was it absolutely necessary to split these changes into 99 commits? I >> believe at least some of them can be squashed. Reviewing 99 patches >> isn't feasible. >> >> Squashed, I'm not sure because the patches were created to satisfy the >> bisectability and travis-ci, if you find any please feel to comment. >> About the commit count, I have mentioned in v1, the idea of having >> many commits in one series to have all lpddr4(-related) changes in one >> place and also all the commit has incremental approach of supporting >> rank detection and lpddr4. If require I'm open to sent next versions >> as multiple series, no problem on that. >> >> I strongly agree with Vasily, and I don't think multiple series makes it any >> better. >> >> What's the reason for having two commits for: >> >> "ram: rk3399: Set lpddr4 MR3" and "ram: rk3399: Set lpddr4 MR12" ? >> >> These are individual lpddr4 set rate registers to support, each one is >> independent on it' own initialization and more over on the whole, it >> is critical to review. >> >> Or splitting all the "ram: rk3399: Add ... macro" ? >> >> You mean the patches 13 to 20 same like above each one has it's own >> meaning. It is not meaningful to squash them all. >> >> >> 99 patches is really too much, but I'm not sure how smaller it can be. >> Reference to kernel document, it suggest not more than 15 at one time: > Agreed. > >> NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! <https://lkml.org/lkml/2005/7/11/336> But please note that I don't think split this into different series make any sense. But maybe you can try to squash as much as you can. eg. the update for dram_all_config may able to squash into one patch, >> and some new MACRO and its reference code may be able to squash. >> So it depends on how you define about _logical change_. >> I'm not sure if this have happen in the history of U-Boot mailing list, but >> I think this big patch set will be complained by many people if this is send to >> kernel. > I don't mean to split the lpddr4 changes into multiple series. what > I'm trying to say here is this series has patches that support code > warnings, rank detection. Since each of them has it own identical > features, I'm planning to send them first. and will squash what it > require on lpddr4. > > Will that be okay for you? That's OK for me, just need to let people know the patch set dependency. Thanks, - Kever >