[{"id":1757252,"web_url":"http://patchwork.ozlabs.org/comment/1757252/","msgid":"<87valct177.fsf@concordia.ellerman.id.au>","date":"2017-08-25T10:02:20","subject":"Re: [PATCH v7 10/12] powerpc/vas: Define vas_win_close() interface","submitter":{"id":46580,"url":"http://patchwork.ozlabs.org/api/people/46580/","name":"Michael Ellerman","email":"mpe@ellerman.id.au"},"content":"Hi Suka,\n\nMore comments :)\n\nSukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> writes:\n\n> diff --git a/arch/powerpc/platforms/powernv/vas-window.c b/arch/powerpc/platforms/powernv/vas-window.c\n> index 2dd4b63..24288dd 100644\n> --- a/arch/powerpc/platforms/powernv/vas-window.c\n> +++ b/arch/powerpc/platforms/powernv/vas-window.c\n> @@ -879,11 +887,92 @@ struct vas_window *vas_rx_win_open(int vasid, enum vas_cop_type cop,\n>  }\n>  EXPORT_SYMBOL_GPL(vas_rx_win_open);\n>  \n> -/* stub for now */\n> +static void poll_window_busy_state(struct vas_window *window)\n> +{\n> +\tint busy;\n> +\tuint64_t val;\n> +\n> +retry:\n> +\t/*\n> +\t * Poll Window Busy flag\n> +\t */\n> +\tval = read_hvwc_reg(window, VREG(WIN_STATUS));\n> +\tbusy = GET_FIELD(VAS_WIN_BUSY, val);\n> +\tif (busy) {\n> +\t\tval = 0;\n> +\t\tschedule_timeout(2000);\n\nWhat's 2000?\n\nThat's in jiffies, so it's not a fixed amount of time.\n\nBut on a typical config that will be 20 _seconds_ ?!\n\nBut you haven't set the task state, so AFAIK it will just return\ninstantly.\n\nAnd if there's a software/hardware bug and it never stops being busy,\nthen we have a softlockup. The other option would be print a big fat\nwarning and just not free the window. But maybe that doesn't work for\nother reasons.\n\n> +\t\tgoto retry;\n> +\t}\n> +}\n> +\n> +static void poll_window_castout(struct vas_window *window)\n> +{\n> +\tint cached;\n> +\tuint64_t val;\n> +\n> +\t/* Cast window context out of the cache */\n> +retry:\n> +\tval = read_hvwc_reg(window, VREG(WIN_CTX_CACHING_CTL));\n> +\tcached = GET_FIELD(VAS_WIN_CACHE_STATUS, val);\n> +\tif (cached) {\n> +\t\tval = 0ULL;\n> +\t\tval = SET_FIELD(VAS_CASTOUT_REQ, val, 1);\n> +\t\tval = SET_FIELD(VAS_PUSH_TO_MEM, val, 0);\n> +\t\twrite_hvwc_reg(window, VREG(WIN_CTX_CACHING_CTL), val);\n\nSigh, I still don't like that macro :)\n\nor:\n\t\twrite_hvwc_reg(window, VREG(WIN_CTX_CACHING_CTL), 1ull << 63);\n\n> +\n> +\t\tschedule_timeout(2000);\n> +\t\tgoto retry;\n> +\t}\n> +}\n> +\n> +/*\n> + * Close a window.\n> + *\n> + * See Section 1.12.1 of VAS workbook v1.05 for details on closing window:\n> + *\t- Disable new paste operations (unmap paste address)\n> + *\t- Poll for the \"Window Busy\" bit to be cleared\n> + *\t- Clear the Open/Enable bit for the Window.\n> + *\t- Poll for return of window Credits (implies FIFO empty for Rx win?)\n> + *\t- Unpin and cast window context out of cache\n> + *\n> + * Besides the hardware, kernel has some bookkeeping of course.\n> + */\n>  int vas_win_close(struct vas_window *window)\n>  {\n> -\treturn -1;\n> +\tuint64_t val;\n> +\n> +\tif (!window)\n> +\t\treturn 0;\n> +\n> +\tif (!window->tx_win && atomic_read(&window->num_txwins) != 0) {\n> +\t\tpr_devel(\"VAS: Attempting to close an active Rx window!\\n\");\n> +\t\tWARN_ON_ONCE(1);\n> +\t\treturn -EAGAIN;\n\nEAGAIN means \"if you do the same thing again it might work\".\n\nI don't think that's right here. The window is not in a state where it\ncan be freed, the caller needs to do something to fix that.\n\nEBUSY would probably be more appropriate.\n\n\ncheers","headers":{"Return-Path":"<linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org>","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 3xdxZ64xYgz9sRY\n\tfor <patchwork-incoming@ozlabs.org>;\n\tFri, 25 Aug 2017 20:03:26 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xdxZ6465lzDrSS\n\tfor <patchwork-incoming@ozlabs.org>;\n\tFri, 25 Aug 2017 20:03:26 +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 3xdxXt2ZkzzDqHx\n\tfor <linuxppc-dev@lists.ozlabs.org>;\n\tFri, 25 Aug 2017 20:02:22 +1000 (AEST)","by ozlabs.org (Postfix)\n\tid 3xdxXt1lbGz9sRW; Fri, 25 Aug 2017 20:02:22 +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 3xdxXt08sKz9sPs;\n\tFri, 25 Aug 2017 20:02:21 +1000 (AEST)"],"From":"Michael Ellerman <mpe@ellerman.id.au>","To":"Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>","Subject":"Re: [PATCH v7 10/12] powerpc/vas: Define vas_win_close() interface","In-Reply-To":"<1503556688-15412-11-git-send-email-sukadev@linux.vnet.ibm.com>","References":"<1503556688-15412-1-git-send-email-sukadev@linux.vnet.ibm.com>\n\t<1503556688-15412-11-git-send-email-sukadev@linux.vnet.ibm.com>","User-Agent":"Notmuch/0.21 (https://notmuchmail.org)","Date":"Fri, 25 Aug 2017 20:02:20 +1000","Message-ID":"<87valct177.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<linuxppc-dev.lists.ozlabs.org>","List-Unsubscribe":"<https://lists.ozlabs.org/options/linuxppc-dev>,\n\t<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=unsubscribe>","List-Archive":"<http://lists.ozlabs.org/pipermail/linuxppc-dev/>","List-Post":"<mailto:linuxppc-dev@lists.ozlabs.org>","List-Help":"<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=help>","List-Subscribe":"<https://lists.ozlabs.org/listinfo/linuxppc-dev>,\n\t<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=subscribe>","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<linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org>"}},{"id":1758363,"web_url":"http://patchwork.ozlabs.org/comment/1758363/","msgid":"<20170828051446.GF12907@us.ibm.com>","date":"2017-08-28T05:14:46","subject":"Re: [PATCH v7 10/12] powerpc/vas: Define vas_win_close() interface","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> Hi Suka,\n> \n> More comments :)\n\nThanks!\n\n> \n> Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> writes:\n> \n> > diff --git a/arch/powerpc/platforms/powernv/vas-window.c b/arch/powerpc/platforms/powernv/vas-window.c\n> > index 2dd4b63..24288dd 100644\n> > --- a/arch/powerpc/platforms/powernv/vas-window.c\n> > +++ b/arch/powerpc/platforms/powernv/vas-window.c\n> > @@ -879,11 +887,92 @@ struct vas_window *vas_rx_win_open(int vasid, enum vas_cop_type cop,\n> >  }\n> >  EXPORT_SYMBOL_GPL(vas_rx_win_open);\n> >  \n> > -/* stub for now */\n> > +static void poll_window_busy_state(struct vas_window *window)\n> > +{\n> > +\tint busy;\n> > +\tuint64_t val;\n> > +\n> > +retry:\n> > +\t/*\n> > +\t * Poll Window Busy flag\n> > +\t */\n> > +\tval = read_hvwc_reg(window, VREG(WIN_STATUS));\n> > +\tbusy = GET_FIELD(VAS_WIN_BUSY, val);\n> > +\tif (busy) {\n> > +\t\tval = 0;\n> > +\t\tschedule_timeout(2000);\n> \n> What's 2000?\n> \n> That's in jiffies, so it's not a fixed amount of time.\n> \n> But on a typical config that will be 20 _seconds_ ?!\n\nOk. Should I change to that just HZ and\n\n> \n> But you haven't set the task state, so AFAIK it will just return\n> instantly.\n\ncall set_current_state(TASK_UNINTERRUPTIBLE) before the schedule_timeout()?\n\n> \n> And if there's a software/hardware bug and it never stops being busy,\n> then we have a softlockup. The other option would be print a big fat\n> warning and just not free the window. But maybe that doesn't work for\n> other reasons.\n> \n> > +\t\tgoto retry;\n> > +\t}\n> > +}\n> > +\n> > +static void poll_window_castout(struct vas_window *window)\n> > +{\n> > +\tint cached;\n> > +\tuint64_t val;\n> > +\n> > +\t/* Cast window context out of the cache */\n> > +retry:\n> > +\tval = read_hvwc_reg(window, VREG(WIN_CTX_CACHING_CTL));\n> > +\tcached = GET_FIELD(VAS_WIN_CACHE_STATUS, val);\n> > +\tif (cached) {\n> > +\t\tval = 0ULL;\n> > +\t\tval = SET_FIELD(VAS_CASTOUT_REQ, val, 1);\n> > +\t\tval = SET_FIELD(VAS_PUSH_TO_MEM, val, 0);\n> > +\t\twrite_hvwc_reg(window, VREG(WIN_CTX_CACHING_CTL), val);\n> \n> Sigh, I still don't like that macro :)\n\n:-) For one thing, I have used it a lot now and secondly isn't it easier\nto know that VAS_CASTOUT_REQ bit is set to 1 without worrying about its\nbit position? When debugging, yes we have to ensure VAS_CASTOUT_REQ is\nproperly defined and we have to work out value in \"val\".\n\n> \n> or:\n> \t\twrite_hvwc_reg(window, VREG(WIN_CTX_CACHING_CTL), 1ull << 63);\n> \n> > +\n> > +\t\tschedule_timeout(2000);\n> > +\t\tgoto retry;\n> > +\t}\n> > +}\n> > +\n> > +/*\n> > + * Close a window.\n> > + *\n> > + * See Section 1.12.1 of VAS workbook v1.05 for details on closing window:\n> > + *\t- Disable new paste operations (unmap paste address)\n> > + *\t- Poll for the \"Window Busy\" bit to be cleared\n> > + *\t- Clear the Open/Enable bit for the Window.\n> > + *\t- Poll for return of window Credits (implies FIFO empty for Rx win?)\n> > + *\t- Unpin and cast window context out of cache\n> > + *\n> > + * Besides the hardware, kernel has some bookkeeping of course.\n> > + */\n> >  int vas_win_close(struct vas_window *window)\n> >  {\n> > -\treturn -1;\n> > +\tuint64_t val;\n> > +\n> > +\tif (!window)\n> > +\t\treturn 0;\n> > +\n> > +\tif (!window->tx_win && atomic_read(&window->num_txwins) != 0) {\n> > +\t\tpr_devel(\"VAS: Attempting to close an active Rx window!\\n\");\n> > +\t\tWARN_ON_ONCE(1);\n> > +\t\treturn -EAGAIN;\n> \n> EAGAIN means \"if you do the same thing again it might work\".\n> \n> I don't think that's right here. The window is not in a state where it\n> can be freed, the caller needs to do something to fix that.\n> \n> EBUSY would probably be more appropriate.\n\nOk. Should not happen now (or even with the fast thread-wake up code)\nsince only the kernel should be closing the windows - so its really a\nbug.  Will change to EBUSY though.\n> \n> \n> cheers","headers":{"Return-Path":"<linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org>","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 3xgg3L0QBTz9s9Y\n\tfor <patchwork-incoming@ozlabs.org>;\n\tMon, 28 Aug 2017 15:16:14 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xgg3K6TzHzDqHc\n\tfor <patchwork-incoming@ozlabs.org>;\n\tMon, 28 Aug 2017 15:16:13 +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 3xgg1q420QzDqGG\n\tfor <linuxppc-dev@lists.ozlabs.org>;\n\tMon, 28 Aug 2017 15:14:55 +1000 (AEST)","from ozlabs.org (ozlabs.org [IPv6:2401:3900:2:1::2])\n\tby bilbo.ozlabs.org (Postfix) with ESMTP id 3xgg1q2v2Kz8t8c\n\tfor <linuxppc-dev@lists.ozlabs.org>;\n\tMon, 28 Aug 2017 15:14:55 +1000 (AEST)","by ozlabs.org (Postfix)\n\tid 3xgg1q2bZ9z9sPk; Mon, 28 Aug 2017 15:14:55 +1000 (AEST)","from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n\t[148.163.158.5])\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 3xgg1p5zrJz9sP3\n\tfor <linuxppc-dev@ozlabs.org>; Mon, 28 Aug 2017 15:14:54 +1000 (AEST)","from pps.filterd (m0098419.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv7S5DjtN095622\n\tfor <linuxppc-dev@ozlabs.org>; Mon, 28 Aug 2017 01:14:52 -0400","from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 2cmb2qumaw-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor <linuxppc-dev@ozlabs.org>; Mon, 28 Aug 2017 01:14:51 -0400","from localhost\n\tby e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor <linuxppc-dev@ozlabs.org> from <sukadev@linux.vnet.ibm.com>;\n\tSun, 27 Aug 2017 23:14:51 -0600","from b03cxnp08027.gho.boulder.ibm.com (9.17.130.19)\n\tby e33.co.us.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tSun, 27 Aug 2017 23:14:48 -0600","from b03ledav001.gho.boulder.ibm.com\n\t(b03ledav001.gho.boulder.ibm.com [9.17.130.232])\n\tby b03cxnp08027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v7S5ElCk65470600; Sun, 27 Aug 2017 22:14:48 -0700","from b03ledav001.gho.boulder.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id DDE0F6E03A;\n\tSun, 27 Aug 2017 23:14:47 -0600 (MDT)","from suka-w540.localdomain (unknown [9.70.94.25])\n\tby b03ledav001.gho.boulder.ibm.com (Postfix) with ESMTP id 99F3A6E03D;\n\tSun, 27 Aug 2017 23:14:47 -0600 (MDT)","by suka-w540.localdomain (Postfix, from userid 1000)\n\tid 307392255F3; Sun, 27 Aug 2017 22:14:46 -0700 (PDT)"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=linux.vnet.ibm.com\n\t(client-ip=148.163.158.5; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=sukadev@linux.vnet.ibm.com; receiver=<UNKNOWN>)","Date":"Sun, 27 Aug 2017 22:14:46 -0700","From":"Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>","To":"Michael Ellerman <mpe@ellerman.id.au>","Subject":"Re: [PATCH v7 10/12] powerpc/vas: Define vas_win_close() interface","References":"<1503556688-15412-1-git-send-email-sukadev@linux.vnet.ibm.com>\n\t<1503556688-15412-11-git-send-email-sukadev@linux.vnet.ibm.com>\n\t<87valct177.fsf@concordia.ellerman.id.au>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<87valct177.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":"17082805-0008-0000-0000-0000087C2507","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.00908658; UDB=6.00455620;\n\tIPR=6.00688899; \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 05:14:50","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17082805-0009-0000-0000-000043BD7085","Message-Id":"<20170828051446.GF12907@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=2\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-1708280084","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<linuxppc-dev.lists.ozlabs.org>","List-Unsubscribe":"<https://lists.ozlabs.org/options/linuxppc-dev>,\n\t<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=unsubscribe>","List-Archive":"<http://lists.ozlabs.org/pipermail/linuxppc-dev/>","List-Post":"<mailto:linuxppc-dev@lists.ozlabs.org>","List-Help":"<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=help>","List-Subscribe":"<https://lists.ozlabs.org/listinfo/linuxppc-dev>,\n\t<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=subscribe>","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<linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org>"}},{"id":1758521,"web_url":"http://patchwork.ozlabs.org/comment/1758521/","msgid":"<87d17fvrxu.fsf@concordia.ellerman.id.au>","date":"2017-08-28T11:43:09","subject":"Re: [PATCH v7 10/12] powerpc/vas: Define vas_win_close() interface","submitter":{"id":46580,"url":"http://patchwork.ozlabs.org/api/people/46580/","name":"Michael Ellerman","email":"mpe@ellerman.id.au"},"content":"Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> writes:\n\n> Michael Ellerman [mpe@ellerman.id.au] wrote:\n>> Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> writes:\n>> > diff --git a/arch/powerpc/platforms/powernv/vas-window.c b/arch/powerpc/platforms/powernv/vas-window.c\n>> > index 2dd4b63..24288dd 100644\n>> > --- a/arch/powerpc/platforms/powernv/vas-window.c\n>> > +++ b/arch/powerpc/platforms/powernv/vas-window.c\n>> > @@ -879,11 +887,92 @@ struct vas_window *vas_rx_win_open(int vasid, enum vas_cop_type cop,\n>> >  }\n>> >  EXPORT_SYMBOL_GPL(vas_rx_win_open);\n>> >  \n>> > -/* stub for now */\n>> > +static void poll_window_busy_state(struct vas_window *window)\n>> > +{\n>> > +\tint busy;\n>> > +\tuint64_t val;\n>> > +\n>> > +retry:\n>> > +\t/*\n>> > +\t * Poll Window Busy flag\n>> > +\t */\n>> > +\tval = read_hvwc_reg(window, VREG(WIN_STATUS));\n>> > +\tbusy = GET_FIELD(VAS_WIN_BUSY, val);\n>> > +\tif (busy) {\n>> > +\t\tval = 0;\n>> > +\t\tschedule_timeout(2000);\n>> \n>> What's 2000?\n>> \n>> That's in jiffies, so it's not a fixed amount of time.\n>> \n>> But on a typical config that will be 20 _seconds_ ?!\n>\n> Ok. Should I change to that just HZ and\n\nDoes the hardware give us any idea how long we need to wait?\n\nHZ is better I guess but it's still a long time.\n\n>> But you haven't set the task state, so AFAIK it will just return\n>> instantly.\n>\n> call set_current_state(TASK_UNINTERRUPTIBLE) before the schedule_timeout()?\n\nYes.\n\n>> > +\tval = read_hvwc_reg(window, VREG(WIN_CTX_CACHING_CTL));\n>> > +\tcached = GET_FIELD(VAS_WIN_CACHE_STATUS, val);\n>> > +\tif (cached) {\n>> > +\t\tval = 0ULL;\n>> > +\t\tval = SET_FIELD(VAS_CASTOUT_REQ, val, 1);\n>> > +\t\tval = SET_FIELD(VAS_PUSH_TO_MEM, val, 0);\n>> > +\t\twrite_hvwc_reg(window, VREG(WIN_CTX_CACHING_CTL), val);\n>> \n>> Sigh, I still don't like that macro :)\n>\n> :-) For one thing, I have used it a lot now and secondly isn't it easier\n> to know that VAS_CASTOUT_REQ bit is set to 1 without worrying about its\n> bit position?\n\nYeah I guess it depends what you're doing. Are you comparing the code to\nthe spec, where seeing the name is probably what you want?\n\nOr are you debugging the code running on hardware, where you have a dump\nof register values or a trace etc. and you don't have any names just hex\nvalues.\n\nAt least in my experience I spend more time doing the latter, so being\nable to match the hex values in the code up with values I see in memory\nor in registers is preferable.\n\nBut it's your code so I'll stop whining about that macro :)\n\n\ncheers","headers":{"Return-Path":"<linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org>","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 [IPv6:2401:3900:2:1::3])\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 3xgqg61ZZ4z9s7g\n\tfor <patchwork-incoming@ozlabs.org>;\n\tMon, 28 Aug 2017 21:44:18 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xgqg603mLzDqMV\n\tfor <patchwork-incoming@ozlabs.org>;\n\tMon, 28 Aug 2017 21:44:18 +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 3xgqds14N2zDq66\n\tfor <linuxppc-dev@lists.ozlabs.org>;\n\tMon, 28 Aug 2017 21:43:13 +1000 (AEST)","by ozlabs.org (Postfix)\n\tid 3xgqdr6hkzz9sN7; Mon, 28 Aug 2017 21:43:12 +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 3xgqdr4w9Zz9sD9;\n\tMon, 28 Aug 2017 21:43:12 +1000 (AEST)"],"From":"Michael Ellerman <mpe@ellerman.id.au>","To":"Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>","Subject":"Re: [PATCH v7 10/12] powerpc/vas: Define vas_win_close() interface","In-Reply-To":"<20170828051446.GF12907@us.ibm.com>","References":"<1503556688-15412-1-git-send-email-sukadev@linux.vnet.ibm.com>\n\t<1503556688-15412-11-git-send-email-sukadev@linux.vnet.ibm.com>\n\t<87valct177.fsf@concordia.ellerman.id.au>\n\t<20170828051446.GF12907@us.ibm.com>","User-Agent":"Notmuch/0.21 (https://notmuchmail.org)","Date":"Mon, 28 Aug 2017 21:43:09 +1000","Message-ID":"<87d17fvrxu.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<linuxppc-dev.lists.ozlabs.org>","List-Unsubscribe":"<https://lists.ozlabs.org/options/linuxppc-dev>,\n\t<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=unsubscribe>","List-Archive":"<http://lists.ozlabs.org/pipermail/linuxppc-dev/>","List-Post":"<mailto:linuxppc-dev@lists.ozlabs.org>","List-Help":"<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=help>","List-Subscribe":"<https://lists.ozlabs.org/listinfo/linuxppc-dev>,\n\t<mailto:linuxppc-dev-request@lists.ozlabs.org?subject=subscribe>","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<linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org>"}}]