[{"id":1757215,"web_url":"http://patchwork.ozlabs.org/comment/1757215/","msgid":"<87bmn4uhgd.fsf@concordia.ellerman.id.au>","date":"2017-08-25T09:25:54","subject":"Re: [PATCH v7 05/12] powerpc/vas: Define helpers to init window\n\tcontext","submitter":{"id":46580,"url":"http://patchwork.ozlabs.org/api/people/46580/","name":"Michael Ellerman","email":"mpe@ellerman.id.au"},"content":"Sukadev Bhattiprolu writes:\n> diff --git a/arch/powerpc/platforms/powernv/vas-window.c b/arch/powerpc/platforms/powernv/vas-window.c\n> index a3a705a..3a50d6a 100644\n> --- a/arch/powerpc/platforms/powernv/vas-window.c\n> +++ b/arch/powerpc/platforms/powernv/vas-window.c\n> @@ -11,6 +11,7 @@\n> #include \n> #include \n> #include \n> +#include \n> \n> #include \"vas.h\"\n> \n> @@ -185,6 +186,310 @@ int map_winctx_mmio_bars(struct vas_window *window)\n> \treturn 0;\n> }\n> \n> +/*\n> + * Reset all valid registers in the HV and OS/User Window Contexts for\n> + * the window identified by @window.\n> + *\n> + * NOTE: We cannot really use a for loop to reset window context. Not all\n> + *\t offsets in a window context are valid registers and the valid\n> + *\t registers are not sequential. And, we can only write to offsets\n> + *\t with valid registers (or is that only in Simics?).\n\nI assume there's no \"reset everything\" register we can write to do this\nfor us?\n\nAlso if you can clean up the comment to not mention Simics, I would\nassume that applies on real hardware too.\n\n> + */\n> +void reset_window_regs(struct vas_window *window)\n> +{\n> +\twrite_hvwc_reg(window, VREG(LPID), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(PID), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(XLATE_MSR), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(XLATE_LPCR), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(XLATE_CTL), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(AMR), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(SEIDR), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(FAULT_TX_WIN), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(OSU_INTR_SRC_RA), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(HV_INTR_SRC_RA), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(PSWID), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(SPARE1), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(SPARE2), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(SPARE3), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(SPARE4), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(SPARE5), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(SPARE6), 0ULL);\n\nShould we be writing to spare registers? Presumably in a future hardware\nrevision they might have some unknown purpose.\n\n> +\twrite_hvwc_reg(window, VREG(LFIFO_BAR), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(LDATA_STAMP_CTL), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(LDMA_CACHE_CTL), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(LRFIFO_PUSH), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(CURR_MSG_COUNT), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(LNOTIFY_AFTER_COUNT), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(LRX_WCRED), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(LRX_WCRED_ADDER), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(TX_WCRED), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(TX_WCRED_ADDER), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(LFIFO_SIZE), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(WINCTL), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(WIN_STATUS), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(WIN_CTX_CACHING_CTL), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(TX_RSVD_BUF_COUNT), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(LRFIFO_WIN_PTR), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(LNOTIFY_CTL), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(LNOTIFY_PID), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(LNOTIFY_LPID), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(LNOTIFY_TID), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(LNOTIFY_SCOPE), 0ULL);\n> +\twrite_hvwc_reg(window, VREG(NX_UTIL_ADDER), 0ULL);\n> +\n> +\t/* Skip read-only registers: NX_UTIL and NX_UTIL_SE */\n> +\n> +\t/*\n> +\t * The send and receive window credit adder registers are also\n> +\t * accessible from HVWC and have been initialized above. We don't\n> +\t * need to initialize from the OS/User Window Context, so skip\n> +\t * following calls:\n> +\t *\n> +\t *\twrite_uwc_reg(window, VREG(TX_WCRED_ADDER), 0ULL);\n> +\t *\twrite_uwc_reg(window, VREG(LRX_WCRED_ADDER), 0ULL);\n> +\t */\n> +}\n> +\n> +/*\n> + * Initialize window context registers related to Address Translation.\n> + * These registers are common to send/receive windows although they\n> + * differ for user/kernel windows. As we resolve the TODOs we may\n> + * want to add fields to vas_winctx and move the initialization to\n> + * init_vas_winctx_regs().\n> + */\n> +static void init_xlate_regs(struct vas_window *window, bool user_win)\n> +{\n> +\tuint64_t lpcr, val;\n> +\n> +\t/*\n> +\t * MSR_TA, MSR_US are false for both kernel and user.\n> +\t * MSR_DR and MSR_PR are false for kernel.\n> +\t */\n> +\tval = 0ULL;\n> +\tval = SET_FIELD(VAS_XLATE_MSR_HV, val, true);\n\nUsing a bool here presumably works, but if you actually wrote:\n\n ((u64)true << VAS_XLATE_MSR_HV)\n\nIt would look pretty weird. Using an int would be more normal.\n\n> +\tval = SET_FIELD(VAS_XLATE_MSR_SF, val, true);\n> +\tif (user_win) {\n> +\t\tval = SET_FIELD(VAS_XLATE_MSR_DR, val, true);\n> +\t\tval = SET_FIELD(VAS_XLATE_MSR_PR, val, true);\n> +\t}\n> +\twrite_hvwc_reg(window, VREG(XLATE_MSR), val);\n> +\n> +\tlpcr = mfspr(SPRN_LPCR);\n> +\tval = 0ULL;\n> +\t/*\n> +\t * NOTE: From Section 5.7.6.1 Segment Lookaside Buffer of the\n> +\t *\t Power ISA, v2.07, Page size encoding is 0 = 4KB, 5 = 64KB.\n\nWhich is 5.7.8.1 in ISA v3.0B.\n\n> +\t *\n> +\t * NOTE: From Section 1.3.1, Address Translation Context of the\n> +\t *\t Nest MMU Workbook, LPCR_SC should be 0 for Power9.\n> +\t */\n> +\tval = SET_FIELD(VAS_XLATE_LPCR_PAGE_SIZE, val, 5);\n> +\tval = SET_FIELD(VAS_XLATE_LPCR_ISL, val, lpcr & LPCR_ISL);\n> +\tval = SET_FIELD(VAS_XLATE_LPCR_TC, val, lpcr & LPCR_TC);\n> +\tval = SET_FIELD(VAS_XLATE_LPCR_SC, val, 0);\n> +\twrite_hvwc_reg(window, VREG(XLATE_LPCR), val);\n> +\n> +\t/*\n> +\t * Section 1.3.1 (Address translation Context) of NMMU workbook.\n> +\t *\t0b00\tHashed Page Table mode\n> +\t *\t0b01\tReserved\n> +\t *\t0b10\tRadix on HPT\n> +\t *\t0b11\tRadix on Radix\n> +\t */\n> +\tval = 0ULL;\n> +\tval = SET_FIELD(VAS_XLATE_MODE, val, radix_enabled() ? 3 : 2);\n> +\twrite_hvwc_reg(window, VREG(XLATE_CTL), val);\n> +\n> +\t/*\n> +\t * TODO: Can we mfspr(AMR) even for user windows?\n> +\t */\n> +\tval = 0ULL;\n> +\tval = SET_FIELD(VAS_AMR, val, mfspr(SPRN_AMR));\n> +\twrite_hvwc_reg(window, VREG(AMR), val);\n> +\n> +\tval = 0ULL;\n> +\tval = SET_FIELD(VAS_SEIDR, val, 0);\n> +\twrite_hvwc_reg(window, VREG(SEIDR), val);\n> +}\n> +\n> +/*\n> + * Initialize Reserved Send Buffer Count for the send window. It involves\n> + * writing to the register, reading it back to confirm that the hardware\n> + * has enough buffers to reserve. See section 1.3.1.2.1 of VAS workbook.\n> + *\n> + * Since we can only make a best-effort attempt to fulfill the request,\n> + * we don't return any errors if we cannot.\n> + *\n> + * TODO: Reserved (aka dedicated) send buffers are not supported yet.\n> + */\n> +static void init_rsvd_tx_buf_count(struct vas_window *txwin,\n> +\t\t\t\tstruct vas_winctx *winctx)\n> +{\n> +\twrite_hvwc_reg(txwin, VREG(TX_RSVD_BUF_COUNT), 0ULL);\n> +}\n> +\n> +/*\n> + * init_winctx_regs()\n> + *\tInitialize window context registers for a receive window.\n> + *\tExcept for caching control and marking window open, the registers\n> + *\tare initialized in the order listed in Section 3.1.4 (Window Context\n> + *\tCache Register Details) of the VAS workbook although they don't need\n> + *\tto be.\n> + *\n> + * Design note: For NX receive windows, NX allocates the FIFO buffer in OPAL\n> + *\t(so that it can get a large contiguous area) and passes that buffer\n> + *\tto kernel via device tree. We now write that buffer address to the\n> + *\tFIFO BAR. Would it make sense to do this all in OPAL? i.e have OPAL\n> + *\twrite the per-chip RX FIFO addresses to the windows during boot-up\n> + *\tas a one-time task? That could work for NX but what about other\n> + *\treceivers? Let the receivers tell us the rx-fifo buffers for now.\n\nWhy did we do it that way?\n\nIf I'm reading the skiboot code right, the \"large contiguous area\" is 32K.\n\nThat's less than a single page?!\n\n\ncheers","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org","linuxppc-dev@ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xdwmK2xzLz9s78\n\tfor ;\n\tFri, 25 Aug 2017 19:27:13 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xdwmK1cpyzDqFw\n\tfor ;\n\tFri, 25 Aug 2017 19:27:13 +1000 (AEST)","from ozlabs.org (bilbo.ozlabs.org [103.22.144.67])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xdwkv17nfzDrTT\n\tfor ;\n\tFri, 25 Aug 2017 19:25:59 +1000 (AEST)","by ozlabs.org (Postfix)\n\tid 3xdwkt6YdYz9sP5; Fri, 25 Aug 2017 19:25:58 +1000 (AEST)","from authenticated.ozlabs.org (localhost [127.0.0.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPSA id 3xdwkt4vgtz9sNd;\n\tFri, 25 Aug 2017 19:25:58 +1000 (AEST)"],"From":"Michael Ellerman ","To":"Sukadev Bhattiprolu ","Subject":"Re: [PATCH v7 05/12] powerpc/vas: Define helpers to init window\n\tcontext","In-Reply-To":"<1503556688-15412-6-git-send-email-sukadev@linux.vnet.ibm.com>","References":"<1503556688-15412-1-git-send-email-sukadev@linux.vnet.ibm.com>\n\t<1503556688-15412-6-git-send-email-sukadev@linux.vnet.ibm.com>","User-Agent":"Notmuch/0.21 (https://notmuchmail.org)","Date":"Fri, 25 Aug 2017 19:25:54 +1000","Message-ID":"<87bmn4uhgd.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"stewart@linux.vnet.ibm.com, mikey@neuling.org, linuxppc-dev@ozlabs.org, \n\tlinux-kernel@vger.kernel.org, apopple@au1.ibm.com, oohall@gmail.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1758360,"web_url":"http://patchwork.ozlabs.org/comment/1758360/","msgid":"<20170828044427.GC12907@us.ibm.com>","date":"2017-08-28T04:44:27","subject":"Re: [PATCH v7 05/12] powerpc/vas: Define helpers to init window\n\tcontext","submitter":{"id":984,"url":"http://patchwork.ozlabs.org/api/people/984/","name":"Sukadev Bhattiprolu","email":"sukadev@linux.vnet.ibm.com"},"content":"Michael Ellerman [mpe@ellerman.id.au] wrote:\n> Sukadev Bhattiprolu writes:\n> > diff --git a/arch/powerpc/platforms/powernv/vas-window.c b/arch/powerpc/platforms/powernv/vas-window.c\n> > index a3a705a..3a50d6a 100644\n> > --- a/arch/powerpc/platforms/powernv/vas-window.c\n> > +++ b/arch/powerpc/platforms/powernv/vas-window.c\n> > @@ -11,6 +11,7 @@\n> > #include \n> > #include \n> > #include \n> > +#include \n> > \n> > #include \"vas.h\"\n> > \n> > @@ -185,6 +186,310 @@ int map_winctx_mmio_bars(struct vas_window *window)\n> > \treturn 0;\n> > }\n> > \n> > +/*\n> > + * Reset all valid registers in the HV and OS/User Window Contexts for\n> > + * the window identified by @window.\n> > + *\n> > + * NOTE: We cannot really use a for loop to reset window context. Not all\n> > + *\t offsets in a window context are valid registers and the valid\n> > + *\t registers are not sequential. And, we can only write to offsets\n> > + *\t with valid registers (or is that only in Simics?).\n> \n> I assume there's no \"reset everything\" register we can write to do this\n> for us?\n\nChecked with the hardware team and they said there is no \"reset everything\"\nregister. While there are some tricky ways to clear the context, writing\nzeroes is the easiest.\n\n> \n> Also if you can clean up the comment to not mention Simics, I would\n> assume that applies on real hardware too.\n> \n> > + */\n> > +void reset_window_regs(struct vas_window *window)\n> > +{\n> > +\twrite_hvwc_reg(window, VREG(LPID), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(PID), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(XLATE_MSR), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(XLATE_LPCR), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(XLATE_CTL), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(AMR), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(SEIDR), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(FAULT_TX_WIN), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(OSU_INTR_SRC_RA), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(HV_INTR_SRC_RA), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(PSWID), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(SPARE1), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(SPARE2), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(SPARE3), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(SPARE4), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(SPARE5), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(SPARE6), 0ULL);\n> \n> Should we be writing to spare registers? Presumably in a future hardware\n> revision they might have some unknown purpose.\n\nSure, will skip those.\n\n> \n> > +\twrite_hvwc_reg(window, VREG(LFIFO_BAR), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(LDATA_STAMP_CTL), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(LDMA_CACHE_CTL), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(LRFIFO_PUSH), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(CURR_MSG_COUNT), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(LNOTIFY_AFTER_COUNT), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(LRX_WCRED), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(LRX_WCRED_ADDER), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(TX_WCRED), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(TX_WCRED_ADDER), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(LFIFO_SIZE), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(WINCTL), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(WIN_STATUS), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(WIN_CTX_CACHING_CTL), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(TX_RSVD_BUF_COUNT), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(LRFIFO_WIN_PTR), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(LNOTIFY_CTL), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(LNOTIFY_PID), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(LNOTIFY_LPID), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(LNOTIFY_TID), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(LNOTIFY_SCOPE), 0ULL);\n> > +\twrite_hvwc_reg(window, VREG(NX_UTIL_ADDER), 0ULL);\n> > +\n> > +\t/* Skip read-only registers: NX_UTIL and NX_UTIL_SE */\n> > +\n> > +\t/*\n> > +\t * The send and receive window credit adder registers are also\n> > +\t * accessible from HVWC and have been initialized above. We don't\n> > +\t * need to initialize from the OS/User Window Context, so skip\n> > +\t * following calls:\n> > +\t *\n> > +\t *\twrite_uwc_reg(window, VREG(TX_WCRED_ADDER), 0ULL);\n> > +\t *\twrite_uwc_reg(window, VREG(LRX_WCRED_ADDER), 0ULL);\n> > +\t */\n> > +}\n> > +\n> > +/*\n> > + * Initialize window context registers related to Address Translation.\n> > + * These registers are common to send/receive windows although they\n> > + * differ for user/kernel windows. As we resolve the TODOs we may\n> > + * want to add fields to vas_winctx and move the initialization to\n> > + * init_vas_winctx_regs().\n> > + */\n> > +static void init_xlate_regs(struct vas_window *window, bool user_win)\n> > +{\n> > +\tuint64_t lpcr, val;\n> > +\n> > +\t/*\n> > +\t * MSR_TA, MSR_US are false for both kernel and user.\n> > +\t * MSR_DR and MSR_PR are false for kernel.\n> > +\t */\n> > +\tval = 0ULL;\n> > +\tval = SET_FIELD(VAS_XLATE_MSR_HV, val, true);\n> \n> Using a bool here presumably works, but if you actually wrote:\n> \n> ((u64)true << VAS_XLATE_MSR_HV)\n> \n> It would look pretty weird. Using an int would be more normal.\n\nOk.\n> \n> > +\tval = SET_FIELD(VAS_XLATE_MSR_SF, val, true);\n> > +\tif (user_win) {\n> > +\t\tval = SET_FIELD(VAS_XLATE_MSR_DR, val, true);\n> > +\t\tval = SET_FIELD(VAS_XLATE_MSR_PR, val, true);\n> > +\t}\n> > +\twrite_hvwc_reg(window, VREG(XLATE_MSR), val);\n> > +\n> > +\tlpcr = mfspr(SPRN_LPCR);\n> > +\tval = 0ULL;\n> > +\t/*\n> > +\t * NOTE: From Section 5.7.6.1 Segment Lookaside Buffer of the\n> > +\t *\t Power ISA, v2.07, Page size encoding is 0 = 4KB, 5 = 64KB.\n> \n> Which is 5.7.8.1 in ISA v3.0B.\n\nOk.\n> \n> > +\t *\n> > +\t * NOTE: From Section 1.3.1, Address Translation Context of the\n> > +\t *\t Nest MMU Workbook, LPCR_SC should be 0 for Power9.\n> > +\t */\n> > +\tval = SET_FIELD(VAS_XLATE_LPCR_PAGE_SIZE, val, 5);\n> > +\tval = SET_FIELD(VAS_XLATE_LPCR_ISL, val, lpcr & LPCR_ISL);\n> > +\tval = SET_FIELD(VAS_XLATE_LPCR_TC, val, lpcr & LPCR_TC);\n> > +\tval = SET_FIELD(VAS_XLATE_LPCR_SC, val, 0);\n> > +\twrite_hvwc_reg(window, VREG(XLATE_LPCR), val);\n> > +\n> > +\t/*\n> > +\t * Section 1.3.1 (Address translation Context) of NMMU workbook.\n> > +\t *\t0b00\tHashed Page Table mode\n> > +\t *\t0b01\tReserved\n> > +\t *\t0b10\tRadix on HPT\n> > +\t *\t0b11\tRadix on Radix\n> > +\t */\n> > +\tval = 0ULL;\n> > +\tval = SET_FIELD(VAS_XLATE_MODE, val, radix_enabled() ? 3 : 2);\n> > +\twrite_hvwc_reg(window, VREG(XLATE_CTL), val);\n> > +\n> > +\t/*\n> > +\t * TODO: Can we mfspr(AMR) even for user windows?\n> > +\t */\n> > +\tval = 0ULL;\n> > +\tval = SET_FIELD(VAS_AMR, val, mfspr(SPRN_AMR));\n> > +\twrite_hvwc_reg(window, VREG(AMR), val);\n> > +\n> > +\tval = 0ULL;\n> > +\tval = SET_FIELD(VAS_SEIDR, val, 0);\n> > +\twrite_hvwc_reg(window, VREG(SEIDR), val);\n> > +}\n> > +\n> > +/*\n> > + * Initialize Reserved Send Buffer Count for the send window. It involves\n> > + * writing to the register, reading it back to confirm that the hardware\n> > + * has enough buffers to reserve. See section 1.3.1.2.1 of VAS workbook.\n> > + *\n> > + * Since we can only make a best-effort attempt to fulfill the request,\n> > + * we don't return any errors if we cannot.\n> > + *\n> > + * TODO: Reserved (aka dedicated) send buffers are not supported yet.\n> > + */\n> > +static void init_rsvd_tx_buf_count(struct vas_window *txwin,\n> > +\t\t\t\tstruct vas_winctx *winctx)\n> > +{\n> > +\twrite_hvwc_reg(txwin, VREG(TX_RSVD_BUF_COUNT), 0ULL);\n> > +}\n> > +\n> > +/*\n> > + * init_winctx_regs()\n> > + *\tInitialize window context registers for a receive window.\n> > + *\tExcept for caching control and marking window open, the registers\n> > + *\tare initialized in the order listed in Section 3.1.4 (Window Context\n> > + *\tCache Register Details) of the VAS workbook although they don't need\n> > + *\tto be.\n> > + *\n> > + * Design note: For NX receive windows, NX allocates the FIFO buffer in OPAL\n> > + *\t(so that it can get a large contiguous area) and passes that buffer\n> > + *\tto kernel via device tree. We now write that buffer address to the\n> > + *\tFIFO BAR. Would it make sense to do this all in OPAL? i.e have OPAL\n> > + *\twrite the per-chip RX FIFO addresses to the windows during boot-up\n> > + *\tas a one-time task? That could work for NX but what about other\n> > + *\treceivers? Let the receivers tell us the rx-fifo buffers for now.\n> \n> Why did we do it that way?\n> \n> If I'm reading the skiboot code right, the \"large contiguous area\" is 32K.\n> \n> That's less than a single page?!\n\nI guess it is because the FIFO can get larger in the future?\n\nCcing Haren.\n\nThanks\n\nSukadev\n\n> \n> \n> cheers","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org","linuxppc-dev@ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xgfPp3K1Dz9s7h\n\tfor ;\n\tMon, 28 Aug 2017 14:47:10 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xgfPp2L0DzDqXh\n\tfor ;\n\tMon, 28 Aug 2017 14:47:10 +1000 (AEST)","from ozlabs.org (ozlabs.org [IPv6:2401:3900:2:1::2])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xgfLq42C4zDqXl\n\tfor ;\n\tMon, 28 Aug 2017 14:44:35 +1000 (AEST)","from ozlabs.org (bilbo.ozlabs.org [103.22.144.67])\n\tby bilbo.ozlabs.org (Postfix) with ESMTP id 3xgfLq3TFHz8t2N\n\tfor ;\n\tMon, 28 Aug 2017 14:44:35 +1000 (AEST)","by ozlabs.org (Postfix)\n\tid 3xgfLq2w01z9s9Y; Mon, 28 Aug 2017 14:44:35 +1000 (AEST)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n\t[148.163.156.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xgfLq010hz9s7h\n\tfor ; Mon, 28 Aug 2017 14:44:34 +1000 (AEST)","from pps.filterd (m0098394.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv7S4hoap048156\n\tfor ; Mon, 28 Aug 2017 00:44:33 -0400","from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2cmagb42uj-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Mon, 28 Aug 2017 00:44:33 -0400","from localhost\n\tby e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tSun, 27 Aug 2017 22:44:32 -0600","from b03cxnp08026.gho.boulder.ibm.com (9.17.130.18)\n\tby e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tSun, 27 Aug 2017 22:44:29 -0600","from b03ledav005.gho.boulder.ibm.com\n\t(b03ledav005.gho.boulder.ibm.com [9.17.130.236])\n\tby b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v7S4iTdE63897664; Sun, 27 Aug 2017 21:44:29 -0700","from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id 0719ABE03A;\n\tSun, 27 Aug 2017 22:44:29 -0600 (MDT)","from suka-w540.localdomain (unknown [9.70.94.25])\n\tby b03ledav005.gho.boulder.ibm.com (Postfix) with ESMTP id C57D6BE038;\n\tSun, 27 Aug 2017 22:44:28 -0600 (MDT)","by suka-w540.localdomain (Postfix, from userid 1000)\n\tid 65F11229282; Sun, 27 Aug 2017 21:44:27 -0700 (PDT)"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=linux.vnet.ibm.com\n\t(client-ip=148.163.156.1; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=sukadev@linux.vnet.ibm.com; receiver=)","Date":"Sun, 27 Aug 2017 21:44:27 -0700","From":"Sukadev Bhattiprolu ","To":"Michael Ellerman ","Subject":"Re: [PATCH v7 05/12] powerpc/vas: Define helpers to init window\n\tcontext","References":"<1503556688-15412-1-git-send-email-sukadev@linux.vnet.ibm.com>\n\t<1503556688-15412-6-git-send-email-sukadev@linux.vnet.ibm.com>\n\t<87bmn4uhgd.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<87bmn4uhgd.fsf@concordia.ellerman.id.au>","X-Operating-System":"Linux 2.0.32 on an i486","User-Agent":"Mutt/1.7.1 (2016-10-04)","X-TM-AS-GCONF":"00","x-cbid":"17082804-0004-0000-0000-000012D5BC5D","X-IBM-SpamModules-Scores":"","X-IBM-SpamModules-Versions":"BY=3.00007625; HX=3.00000241; KW=3.00000007;\n\tPH=3.00000004; SC=3.00000225; SDB=6.00908648; UDB=6.00455614;\n\tIPR=6.00688888; \n\tBA=6.00005555; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009;\n\tZB=6.00000000; \n\tZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016893;\n\tXFM=3.00000015; UTC=2017-08-28 04:44:31","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17082804-0005-0000-0000-000080E2B484","Message-Id":"<20170828044427.GC12907@us.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-08-28_02:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1708280075","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"stewart@linux.vnet.ibm.com, mikey@neuling.org, linuxppc-dev@ozlabs.org, \n\tlinux-kernel@vger.kernel.org, apopple@au1.ibm.com, oohall@gmail.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}}]