| Message ID | 20181206082910.114560-1-aik@ozlabs.ru |
|---|---|
| State | Accepted |
| Headers | show |
| Series | npu2: Advertise correct TCE page size | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | success | master/apply_patch Successfully applied |
| snowpatch_ozlabs/snowpatch_job_snowpatch-skiboot | success | Test snowpatch/job/snowpatch-skiboot on branch master |
Alexey Kardashevskiy <aik@ozlabs.ru> writes: > The P9 NPU workbook says that only 4K/64K/16M/256M page size are supported > and in fact npu2_map_pe_dma_window() supports just these but in absence of > the "ibm,supported-tce-sizes" property Linux assumes the default P9 PHB4 > page sizes - 4K/64K/2M/1G - so when Linux tries 2M/1G TCEs, we get lots of > "Unexpected TCE size" from npu2_tce_kill(). > > This advertises TCE page sizes so Linux could handle it correctly, i.e. > fall back to 4K/64K TCEs. Merged to master as of 003ccd5775161d352c53cac3d00c6283eb036ffc - should this also go to stable?
On 11/12/2018 17:30, Stewart Smith wrote: > Alexey Kardashevskiy <aik@ozlabs.ru> writes: >> The P9 NPU workbook says that only 4K/64K/16M/256M page size are supported >> and in fact npu2_map_pe_dma_window() supports just these but in absence of >> the "ibm,supported-tce-sizes" property Linux assumes the default P9 PHB4 >> page sizes - 4K/64K/2M/1G - so when Linux tries 2M/1G TCEs, we get lots of >> "Unexpected TCE size" from npu2_tce_kill(). >> >> This advertises TCE page sizes so Linux could handle it correctly, i.e. >> fall back to 4K/64K TCEs. > > Merged to master as of 003ccd5775161d352c53cac3d00c6283eb036ffc - should > this also go to stable? The userspace can trigger those "Unexpected TCE size" messages a lot, is this a good enough reason for stable?
Alexey Kardashevskiy <aik@ozlabs.ru> writes: > On 11/12/2018 17:30, Stewart Smith wrote: >> Alexey Kardashevskiy <aik@ozlabs.ru> writes: >>> The P9 NPU workbook says that only 4K/64K/16M/256M page size are supported >>> and in fact npu2_map_pe_dma_window() supports just these but in absence of >>> the "ibm,supported-tce-sizes" property Linux assumes the default P9 PHB4 >>> page sizes - 4K/64K/2M/1G - so when Linux tries 2M/1G TCEs, we get lots of >>> "Unexpected TCE size" from npu2_tce_kill(). >>> >>> This advertises TCE page sizes so Linux could handle it correctly, i.e. >>> fall back to 4K/64K TCEs. >> >> Merged to master as of 003ccd5775161d352c53cac3d00c6283eb036ffc - should >> this also go to stable? > > The userspace can trigger those "Unexpected TCE size" messages a lot, is > this a good enough reason for stable? Probably - annoying messages are a bug.
diff --git a/hw/npu2.c b/hw/npu2.c index 767306f..57f5c4b 100644 --- a/hw/npu2.c +++ b/hw/npu2.c @@ -1934,6 +1934,11 @@ static void npu2_add_phb_properties(struct npu2 *p) NPU2_MAX_PE_NUM); dt_add_property_cells(np, "ibm,opal-reserved-pe", NPU2_RESERVED_PE_NUM); + dt_add_property_cells(np, "ibm,supported-tce-sizes", + 12, // 4K + 16, // 64K + 24, // 16M + 28); // 256M dt_add_property_u64s(np, "ibm,mmio-atsd", MMIO_ATSD_ADDR(p->regs, 0),
The P9 NPU workbook says that only 4K/64K/16M/256M page size are supported and in fact npu2_map_pe_dma_window() supports just these but in absence of the "ibm,supported-tce-sizes" property Linux assumes the default P9 PHB4 page sizes - 4K/64K/2M/1G - so when Linux tries 2M/1G TCEs, we get lots of "Unexpected TCE size" from npu2_tce_kill(). This advertises TCE page sizes so Linux could handle it correctly, i.e. fall back to 4K/64K TCEs. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> --- hw/npu2.c | 5 +++++ 1 file changed, 5 insertions(+)