hdata: Fix dtc warnings

Message ID 20180623064809.6879-1-hegdevasant@linux.vnet.ibm.com
State Accepted
Headers show
Series
  • hdata: Fix dtc warnings
Related show

Checks

Context Check Description
snowpatch_ozlabs/make_check success Test make_check on branch master
snowpatch_ozlabs/apply_patch success master/apply_patch Successfully applied

Commit Message

Vasant Hegde June 23, 2018, 6:48 a.m.
Fix dtc warnings related to mcbist node.

Warning (reg_format): "reg" property in /xscom@623fc00000000/mcbist@1 has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
Warning (reg_format): "reg" property in /xscom@623fc00000000/mcbist@2 has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
Warning (reg_format): "reg" property in /xscom@603fc00000000/mcbist@1 has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
Warning (reg_format): "reg" property in /xscom@603fc00000000/mcbist@2 has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)

Ideally we should add proper xscom range here... but we are not getting that
information in HDAT today. Lets fix warning until we get proper data in HDAT.

Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
---
 hdata/memory.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Comments

Oliver June 25, 2018, 7:18 a.m. | #1
On Sat, Jun 23, 2018 at 4:48 PM, Vasant Hegde
<hegdevasant@linux.vnet.ibm.com> wrote:
> Fix dtc warnings related to mcbist node.
>
> Warning (reg_format): "reg" property in /xscom@623fc00000000/mcbist@1 has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
> Warning (reg_format): "reg" property in /xscom@623fc00000000/mcbist@2 has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
> Warning (reg_format): "reg" property in /xscom@603fc00000000/mcbist@1 has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
> Warning (reg_format): "reg" property in /xscom@603fc00000000/mcbist@2 has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
>
> Ideally we should add proper xscom range here... but we are not getting that
> information in HDAT today. Lets fix warning until we get proper data in HDAT.

The HDAT spec seems to use "MCBIST" to mean MC chiplet, so you could
use the base address of each chiplet rather than making one up. I did
some digging and found that:

MC01 (mcbist0) is at 0x7000000
MC23 (mcbist1) is at 0x8000000

That said our hierarchy doesn't make a whole lot of sense since the
MCSes are part of the nest chiplets rather than the MC chiplets. What
actually consumes this data? Does it care about the exact hierarchy or
does it just look at the dimm@ nodes at the bottom?

> Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
> ---
>  hdata/memory.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/hdata/memory.c b/hdata/memory.c
> index c0c30066e..578479fe1 100644
> --- a/hdata/memory.c
> +++ b/hdata/memory.c
> @@ -450,7 +450,9 @@ static void add_memory_controller(const struct HDIF_common_hdr *msarea,
>         if (!mcbist) {
>                 mcbist = dt_new_addr(xscom, "mcbist", mcbist_id);
>                 assert(mcbist);
> -               dt_add_mem_reg_property(mcbist, mcbist_id);
> +               dt_add_property_cells(mcbist, "#address-cells", 1);
> +               dt_add_property_cells(mcbist, "#size-cells", 0);
> +               dt_add_property_cells(mcbist, "reg", mcbist_id, 0);
>         }
>
>         mcs_id = MS_CONTROLLER_MCS_ID(controller_id);
> --
> 2.14.3
>
> _______________________________________________
> Skiboot mailing list
> Skiboot@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/skiboot
Vasant Hegde June 26, 2018, 12:04 p.m. | #2
On 06/25/2018 12:48 PM, Oliver wrote:
> On Sat, Jun 23, 2018 at 4:48 PM, Vasant Hegde
> <hegdevasant@linux.vnet.ibm.com> wrote:
>> Fix dtc warnings related to mcbist node.
>>
>> Warning (reg_format): "reg" property in /xscom@623fc00000000/mcbist@1 has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
>> Warning (reg_format): "reg" property in /xscom@623fc00000000/mcbist@2 has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
>> Warning (reg_format): "reg" property in /xscom@603fc00000000/mcbist@1 has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
>> Warning (reg_format): "reg" property in /xscom@603fc00000000/mcbist@2 has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
>>
>> Ideally we should add proper xscom range here... but we are not getting that
>> information in HDAT today. Lets fix warning until we get proper data in HDAT.
> 
> The HDAT spec seems to use "MCBIST" to mean MC chiplet, so you could
> use the base address of each chiplet rather than making one up. I did
> some digging and found that:
> 
> MC01 (mcbist0) is at 0x7000000
> MC23 (mcbist1) is at 0x8000000

Where did you get this info? HDAT doesn't mention this.

> 
> That said our hierarchy doesn't make a whole lot of sense since the
> MCSes are part of the nest chiplets rather than the MC chiplets. What
> actually consumes this data? Does it care about the exact hierarchy or
> does it just look at the dimm@ nodes at the bottom?

Google wanted the hierarchy. Hence I added like mcbist/mcs/mca/dimm.

-Vasant
Oliver June 26, 2018, 1:40 p.m. | #3
On Tue, Jun 26, 2018 at 10:04 PM, Vasant Hegde
<hegdevasant@linux.vnet.ibm.com> wrote:
> On 06/25/2018 12:48 PM, Oliver wrote:
>>
>> On Sat, Jun 23, 2018 at 4:48 PM, Vasant Hegde
>> <hegdevasant@linux.vnet.ibm.com> wrote:
>>>
>>> Fix dtc warnings related to mcbist node.
>>>
>>> Warning (reg_format): "reg" property in /xscom@623fc00000000/mcbist@1 has
>>> invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
>>> Warning (reg_format): "reg" property in /xscom@623fc00000000/mcbist@2 has
>>> invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
>>> Warning (reg_format): "reg" property in /xscom@603fc00000000/mcbist@1 has
>>> invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
>>> Warning (reg_format): "reg" property in /xscom@603fc00000000/mcbist@2 has
>>> invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
>>>
>>> Ideally we should add proper xscom range here... but we are not getting
>>> that
>>> information in HDAT today. Lets fix warning until we get proper data in
>>> HDAT.
>>
>>
>> The HDAT spec seems to use "MCBIST" to mean MC chiplet, so you could
>> use the base address of each chiplet rather than making one up. I did
>> some digging and found that:
>>
>> MC01 (mcbist0) is at 0x7000000
>> MC23 (mcbist1) is at 0x8000000
>
>
> Where did you get this info? HDAT doesn't mention this.

XSCOM documentation for the MC chiplet and via cronus to verify the
MC23 chiplet was at 0x8000000

>
>>
>> That said our hierarchy doesn't make a whole lot of sense since the
>> MCSes are part of the nest chiplets rather than the MC chiplets. What
>> actually consumes this data? Does it care about the exact hierarchy or
>> does it just look at the dimm@ nodes at the bottom?
>
>
> Google wanted the hierarchy. Hence I added like mcbist/mcs/mca/dimm.

I thought they were mainly interested in correlating DIMMs on a chip
with the DIMM VPD rather than the specific MCBIST/MCS/MCA  stuff. It
probably doesn't matter though.

>
> -Vasant
>
Stewart Smith Sept. 13, 2018, 8:56 a.m. | #4
Vasant Hegde <hegdevasant@linux.vnet.ibm.com> writes:
> Fix dtc warnings related to mcbist node.
>
> Warning (reg_format): "reg" property in /xscom@623fc00000000/mcbist@1 has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
> Warning (reg_format): "reg" property in /xscom@623fc00000000/mcbist@2 has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
> Warning (reg_format): "reg" property in /xscom@603fc00000000/mcbist@1 has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
> Warning (reg_format): "reg" property in /xscom@603fc00000000/mcbist@2 has invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
>
> Ideally we should add proper xscom range here... but we are not getting that
> information in HDAT today. Lets fix warning until we get proper data in HDAT.
>

Merged to master as of dd2dacf8ee0604107e93354cc2968e8f3bdf5cf0

Patch

diff --git a/hdata/memory.c b/hdata/memory.c
index c0c30066e..578479fe1 100644
--- a/hdata/memory.c
+++ b/hdata/memory.c
@@ -450,7 +450,9 @@  static void add_memory_controller(const struct HDIF_common_hdr *msarea,
 	if (!mcbist) {
 		mcbist = dt_new_addr(xscom, "mcbist", mcbist_id);
 		assert(mcbist);
-		dt_add_mem_reg_property(mcbist, mcbist_id);
+		dt_add_property_cells(mcbist, "#address-cells", 1);
+		dt_add_property_cells(mcbist, "#size-cells", 0);
+		dt_add_property_cells(mcbist, "reg", mcbist_id, 0);
 	}
 
 	mcs_id = MS_CONTROLLER_MCS_ID(controller_id);