| Message ID | 20180623064809.6879-1-hegdevasant@linux.vnet.ibm.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | hdata: Fix dtc warnings | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | success | master/apply_patch Successfully applied |
| snowpatch_ozlabs/make_check | success | Test make_check on branch master |
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
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
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 >
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
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);
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(-)