On Tue, Jun 11, 2019 at 8:36 PM Philipp Tomsich <philipp.tomsich@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > On 11.06.2019, at 17:03, Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Tue, Jun 11, 2019 at 8:23 PM Philipp Tomsich > > <philipp.tomsich@xxxxxxxxxxxxxxxxxxxxx> wrote: > >> > >> > >> > >>> On 11.06.2019, at 16:50, Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx> wrote: > >>> > >>> Yes, it can be possible to break this series into multiple sub series > >>> but idea here is to mark all the required changes to support LPDDR4 > >>> in rk3399 in one set. if required we can break it from next versions. > >>> > >>> This is the initial set for supporting LPDDR4 with associated > >>> features. > >>> > >>> 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 > >>> > >>> patch 0001 - 0033: fix code warnings, prints, new macros > >>> > >>> patch 0034 - 0051: rank detection, sdram debug code > >>> > >>> patch 0052: Use DDR3-1800 on NanoPI-NEO4 > >>> > >>> patch 0053 - 0089: lpddr4 support > >>> > >>> patch 0090: LPDDR4-100 timings > >>> > >>> patch 0091: Use LPDDR4-100 on Rockpro64 > >>> > >>> patch 0092: Use LPDDR4-100 on Rock-PI 4 > >>> > >>> Note: Puma rk3399 has SPL size overflow, better to enable TPL > >>> for this board. > >> > >> We need to keep Puma on a SPL-only configuration for the time being. > >> Please make sure that the LPDDR4 code is an optional feature that does not > >> increase the DRAM-driver size for boards that don’t need/want it. > > > > We have few boards do have TPL-runnable, would be any technical issue > > to switch puma to TPL? because we have lpddr4 code part of existing > > driver itself and it require extra ifdef to consider which indeed look > > awful from code point-of-view. > > Our secure boot process (i.e. signing tools) currently depends on this and > the changeover won’t be quick… Not so quick, we have time till MW. isn't it possible? enabling secure tools in both TPL and SPL or TPL-alone would be meaningful trail. what do you think? _______________________________________________ Linux-rockchip mailing list Linux-rockchip@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-rockchip
