Message ID | 20170829201601.64312-1-sjg@chromium.org |
---|---|
Headers | show |
Series | dtoc: Add support for 64-bit addresses | expand |
Simon, I should be able to give this a test drive on the RK3368 by the end of the week. For the RK3399 our board uses full OF_CONTROL, so I won’t really exercise this there. Given that the RK3399 can always fall back to OF_CONTROL for SPL (as is the default on Puma) and this only blocks the RK3368 TPL (which is not enabled for any other boards than Lion): should we try to get this merged for this release cycle or let it slip into the new merge window? Regards, Philipp. > On 29 Aug 2017, at 22:15, Simon Glass <sjg@chromium.org> wrote: > > This series updates dtoc to support 64-bit addresses automatically. These > appear in C code as fdt64_t arrays: > > struct dtd_test1 { > fdt64_t reg[2]; > > }; > > static struct dtd_test1 dtv_test1 = { > .reg = {0x123400000000, 0x5678}, > }; > > C code can then process these address and size parents easily. This > feature is controlled by the #address-cells and #size-cells values of the > parent. > > The v2 series also enhances phandle support so that it is now possible to > support phandles with different number of arguments. Several clean-up > patches are included also. > > Changes in v2: > - Support 'reg' properties with a single cell (e.g. #size-cells = 0) > - Introduce an fdt_val_t type which is either 32- or 64-bits long > - Update rk3368 and rk3399 uses > - Drop review tags since there are significant changes in this patch > > Simon Glass (16): > fdt: Sync libfdt up to upstream > dtoc: Adjust Node to record its parent > dtoc: Add a 64-bit type and a way to convert cells into 64 bits > dtoc: Avoid very long lines in output > dtoc: Add support for 32 or 64-bit addresses > dtoc: Handle 'reg' properties with unusual sizes > dtoc: Update the Fdt class to record phandles > dtoc: Use the Fdt's class's phandle map > dtoc: Make is_phandle() a member function > dtoc: Rename is_phandle() and adjust it to return more detail > dtoc: Rename the phandle struct > dtoc: Put each phandle on a separate line > dtoc: Put phandle args in an array > dtoc: Support properties containing multiple phandle values > dtoc: Rename the auto-generated dt-structs.h file > dtoc: Add a header to the generated files > > doc/driver-model/of-plat.txt | 2 +- > drivers/clk/clk-uclass.c | 4 +- > drivers/clk/rockchip/clk_rk3368.c | 2 +- > drivers/clk/rockchip/clk_rk3399.c | 4 +- > drivers/core/regmap.c | 2 +- > include/clk.h | 4 +- > include/dt-structs.h | 16 ++- > include/fdtdec.h | 2 + > include/regmap.h | 2 +- > include/syscon.h | 6 +- > lib/libfdt/fdt_rw.c | 20 ++- > lib/libfdt/libfdt.h | 31 +++++ > lib/libfdt/pylibfdt/libfdt.i | 58 ++++++++ > scripts/Makefile.spl | 5 +- > tools/dtoc/dtb_platdata.py | 204 ++++++++++++++++++++++------ > tools/dtoc/dtoc_test_addr32.dts | 27 ++++ > tools/dtoc/dtoc_test_addr32_64.dts | 33 +++++ > tools/dtoc/dtoc_test_addr64.dts | 33 +++++ > tools/dtoc/dtoc_test_addr64_32.dts | 33 +++++ > tools/dtoc/dtoc_test_phandle.dts | 16 ++- > tools/dtoc/dtoc_test_simple.dts | 14 ++ > tools/dtoc/fdt.py | 19 ++- > tools/dtoc/fdt_util.py | 16 +++ > tools/dtoc/test_dtoc.py | 270 ++++++++++++++++++++++++++++++++++++- > 24 files changed, 748 insertions(+), 75 deletions(-) > create mode 100644 tools/dtoc/dtoc_test_addr32.dts > create mode 100644 tools/dtoc/dtoc_test_addr32_64.dts > create mode 100644 tools/dtoc/dtoc_test_addr64.dts > create mode 100644 tools/dtoc/dtoc_test_addr64_32.dts > > -- > 2.14.1.342.g6490525c54-goog >
Hi Philipp, On 30 August 2017 at 04:31, Dr. Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote: > Simon, > > I should be able to give this a test drive on the RK3368 by the end of the week. > For the RK3399 our board uses full OF_CONTROL, so I won’t really exercise > this there. > > Given that the RK3399 can always fall back to OF_CONTROL for SPL (as is the > default on Puma) and this only blocks the RK3368 TPL (which is not enabled > for any other boards than Lion): should we try to get this merged for this release > cycle or let it slip into the new merge window? My preference would be to put it in a next branch, but if nothing else uses it then I suppose it is possible (up to you and Tom)? What is broken that this fixes? > > Regards, > Philipp. > Regards, Simon
> On 30 Aug 2017, at 11:37, Simon Glass <sjg@chromium.org> wrote: > > Hi Philipp, > > On 30 August 2017 at 04:31, Dr. Philipp Tomsich > <philipp.tomsich@theobroma-systems.com> wrote: >> Simon, >> >> I should be able to give this a test drive on the RK3368 by the end of the week. >> For the RK3399 our board uses full OF_CONTROL, so I won’t really exercise >> this there. >> >> Given that the RK3399 can always fall back to OF_CONTROL for SPL (as is the >> default on Puma) and this only blocks the RK3368 TPL (which is not enabled >> for any other boards than Lion): should we try to get this merged for this release >> cycle or let it slip into the new merge window? > > My preference would be to put it in a next branch, but if nothing else > uses it then I suppose it is possible (up to you and Tom)? What is > broken that this fixes? RK3399: SPL for all platforms using OF_PLATDATA RK3368: TPL (uses OF_PLATDATA) Given that TPL for the RK3368 is not used much (and we have a private branch for people that need it), I don’t mind going with the ‘next’ branch. I know that Kever has a few board configurations (EVB-RK3399, Firefly-RK3399) that are affected, but I’d rather see these moved to OF_CONTROL instead of OF_PLATDATA. Regards, Philipp.
Hi Philipp, On 30 August 2017 at 18:12, Dr. Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote: > >> On 30 Aug 2017, at 11:37, Simon Glass <sjg@chromium.org> wrote: >> >> Hi Philipp, >> >> On 30 August 2017 at 04:31, Dr. Philipp Tomsich >> <philipp.tomsich@theobroma-systems.com> wrote: >>> Simon, >>> >>> I should be able to give this a test drive on the RK3368 by the end of the week. >>> For the RK3399 our board uses full OF_CONTROL, so I won’t really exercise >>> this there. >>> >>> Given that the RK3399 can always fall back to OF_CONTROL for SPL (as is the >>> default on Puma) and this only blocks the RK3368 TPL (which is not enabled >>> for any other boards than Lion): should we try to get this merged for this release >>> cycle or let it slip into the new merge window? >> >> My preference would be to put it in a next branch, but if nothing else >> uses it then I suppose it is possible (up to you and Tom)? What is >> broken that this fixes? > > RK3399: SPL for all platforms using OF_PLATDATA > RK3368: TPL (uses OF_PLATDATA) > > Given that TPL for the RK3368 is not used much (and we have a private branch > for people that need it), I don’t mind going with the ‘next’ branch. > > I know that Kever has a few board configurations (EVB-RK3399, Firefly-RK3399) > that are affected, but I’d rather see these moved to OF_CONTROL instead of > OF_PLATDATA. Yes, I see OF_PLATDATA as an extreme measure to be used when we really have to. Regards Simon
Hi Simon, Thanks for your patches, It works very good. I have test the patch set on firefly-rk3399, and the SPL works with OF_PLATDATA after I fix issue in clk(Philipp has point out) driver, sdram driver and sdhci driver, I will send out my fix later. Pls add my test tag for this patch set. Tested-by: Kever Yang <kever.yang@rock-chips.com> Thanks, - Kever On 08/30/2017 04:15 AM, Simon Glass wrote: > This series updates dtoc to support 64-bit addresses automatically. These > appear in C code as fdt64_t arrays: > > struct dtd_test1 { > fdt64_t reg[2]; > > }; > > static struct dtd_test1 dtv_test1 = { > .reg = {0x123400000000, 0x5678}, > }; > > C code can then process these address and size parents easily. This > feature is controlled by the #address-cells and #size-cells values of the > parent. > > The v2 series also enhances phandle support so that it is now possible to > support phandles with different number of arguments. Several clean-up > patches are included also. > > Changes in v2: > - Support 'reg' properties with a single cell (e.g. #size-cells = 0) > - Introduce an fdt_val_t type which is either 32- or 64-bits long > - Update rk3368 and rk3399 uses > - Drop review tags since there are significant changes in this patch > > Simon Glass (16): > fdt: Sync libfdt up to upstream > dtoc: Adjust Node to record its parent > dtoc: Add a 64-bit type and a way to convert cells into 64 bits > dtoc: Avoid very long lines in output > dtoc: Add support for 32 or 64-bit addresses > dtoc: Handle 'reg' properties with unusual sizes > dtoc: Update the Fdt class to record phandles > dtoc: Use the Fdt's class's phandle map > dtoc: Make is_phandle() a member function > dtoc: Rename is_phandle() and adjust it to return more detail > dtoc: Rename the phandle struct > dtoc: Put each phandle on a separate line > dtoc: Put phandle args in an array > dtoc: Support properties containing multiple phandle values > dtoc: Rename the auto-generated dt-structs.h file > dtoc: Add a header to the generated files > > doc/driver-model/of-plat.txt | 2 +- > drivers/clk/clk-uclass.c | 4 +- > drivers/clk/rockchip/clk_rk3368.c | 2 +- > drivers/clk/rockchip/clk_rk3399.c | 4 +- > drivers/core/regmap.c | 2 +- > include/clk.h | 4 +- > include/dt-structs.h | 16 ++- > include/fdtdec.h | 2 + > include/regmap.h | 2 +- > include/syscon.h | 6 +- > lib/libfdt/fdt_rw.c | 20 ++- > lib/libfdt/libfdt.h | 31 +++++ > lib/libfdt/pylibfdt/libfdt.i | 58 ++++++++ > scripts/Makefile.spl | 5 +- > tools/dtoc/dtb_platdata.py | 204 ++++++++++++++++++++++------ > tools/dtoc/dtoc_test_addr32.dts | 27 ++++ > tools/dtoc/dtoc_test_addr32_64.dts | 33 +++++ > tools/dtoc/dtoc_test_addr64.dts | 33 +++++ > tools/dtoc/dtoc_test_addr64_32.dts | 33 +++++ > tools/dtoc/dtoc_test_phandle.dts | 16 ++- > tools/dtoc/dtoc_test_simple.dts | 14 ++ > tools/dtoc/fdt.py | 19 ++- > tools/dtoc/fdt_util.py | 16 +++ > tools/dtoc/test_dtoc.py | 270 ++++++++++++++++++++++++++++++++++++- > 24 files changed, 748 insertions(+), 75 deletions(-) > create mode 100644 tools/dtoc/dtoc_test_addr32.dts > create mode 100644 tools/dtoc/dtoc_test_addr32_64.dts > create mode 100644 tools/dtoc/dtoc_test_addr64.dts > create mode 100644 tools/dtoc/dtoc_test_addr64_32.dts >