mbox series

[U-Boot,v2,00/16] dtoc: Add support for 64-bit addresses

Message ID 20170829201601.64312-1-sjg@chromium.org
Headers show
Series dtoc: Add support for 64-bit addresses | expand

Message

Simon Glass Aug. 29, 2017, 8:15 p.m. UTC 
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

Comments

Philipp Tomsich Aug. 29, 2017, 8:31 p.m. UTC | #1 
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
>
Simon Glass Aug. 30, 2017, 9:37 a.m. UTC | #2 
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
Philipp Tomsich Aug. 30, 2017, 10:12 a.m. UTC | #3 
> 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.
Simon Glass Aug. 31, 2017, 12:52 p.m. UTC | #4 
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
Kever Yang Sept. 7, 2017, 3:11 a.m. UTC | #5 
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
>