Message ID | 1681481153-24036-1-git-send-email-quic_vnivarth@quicinc.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp422004vqo; Fri, 14 Apr 2023 07:24:40 -0700 (PDT) X-Google-Smtp-Source: AKy350aDs2j+lIe2gniYWd0/3H3HY3C1rl++nzbPGJY1ahCDQaFNlpy7pBzyKm6S+MdyAVfQ/br7 X-Received: by 2002:a17:902:ecc5:b0:1a6:54cd:ccd9 with SMTP id a5-20020a170902ecc500b001a654cdccd9mr941575plh.9.1681482279806; Fri, 14 Apr 2023 07:24:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681482279; cv=none; d=google.com; s=arc-20160816; b=CQNifC1sIr3iuEa0O3RyjN1UN094HL9tAvy3DTZ86d6bAH9ZiJOQnYsjx1uj9kPtUz PxVNVabDSyx1wRt/1wvx4bwBlSf+ZyOZQemZrzH8aK09G6ywT8Plx40ZPIpZP11bb0nv p3bMzV4a2DHGYxC8muzeYAhyYdoJ3ylcm5Rc5VyV/QAe5weBmm4jnsxom/Rp38fUw5+E 2hhCRgO36k0GFH3UpCBdYcZC8OyehGQwtq4OQMhE2sajrMWdnKOwwAss3f47kjUhmdrX vlQEIm5njjfGKR5UVuvtyQyLfw7JSHNmKra2zBlTGDRsjs0hamsP05hcC9wXuNeGYQyO 5QLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from :dkim-signature; bh=EKe2QrwUnzXz12XwmiQu3Ki5QHbBdv8NEZKMxWSPElM=; b=xtZnJqJc+XMMonnku7l6mEGCExebBqKhBw+Bplo4Y8ziYMT+Xtx0hBonp229JxxGJV kk9yey9tmkxTt5pys78hsVkipa4pSzaVPLvKaD4FpwOkRGB7zXKg0mmrrMpphG3AukF0 eBQRqNPkl36PFzMyxqsOoQ9alLLjp0Gedz7f320WlYpRq96kbLzAKFgJ6pminFSXGRSL avUpvRcSdeSfWuGcZpI1XPaaJPFnjFdS3Pn2ugWnHW6vsGYPLzqJWpiJrTPM+O+Ra2gs OclsuXB2PW9Y/HazTMTw/tQY6nw78+KVr77/uH1+Wp08kjJIyeyncGhDlVYTG2IBNqWi q1TA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=pczyRFsQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k17-20020a170902c41100b001a6a06397d2si1657597plk.32.2023.04.14.07.24.22; Fri, 14 Apr 2023 07:24:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=pczyRFsQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229902AbjDNOG4 (ORCPT <rfc822;leviz.kernel.dev@gmail.com> + 99 others); Fri, 14 Apr 2023 10:06:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57406 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230265AbjDNOGs (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 14 Apr 2023 10:06:48 -0400 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BBE5DBBA8; Fri, 14 Apr 2023 07:06:30 -0700 (PDT) Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 33EDiX4t032368; Fri, 14 Apr 2023 14:06:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id; s=qcppdkim1; bh=EKe2QrwUnzXz12XwmiQu3Ki5QHbBdv8NEZKMxWSPElM=; b=pczyRFsQITwiYwziOzBeOlHyQVSBYZHZwKDEm+gVuqvtUGJxd2+EMmwiFojeNWhdAzn8 wg2W/mUi9p3DbvE72AQtGegW9m2QTf+9NoJCnHVvu5U+x4NMbiK647QdTxSl9jZGqJIP BwHm8q8jddKFm1zKy71jyK32ZM2Zi7RqfakheuVlekeuRE2FrxZJx9LZQrE+9Nn1Z7KR KkzSCAJGLQ3Cb5v5Zo6bwlG6OJ8+ciuH9HtV5AhEabe2atTKryG4vmr+hvsIMzepQ2he 8YYmjM2PaH/MNbHPuDbfHqSq5CV0SWcbtSBDEoehcVvU/pcxwQNbLGkqwi9R1/RXscZG 1g== Received: from apblrppmta02.qualcomm.com (blr-bdr-fw-01_GlobalNAT_AllZones-Outside.qualcomm.com [103.229.18.19]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3py1wpguvd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 Apr 2023 14:06:01 +0000 Received: from pps.filterd (APBLRPPMTA02.qualcomm.com [127.0.0.1]) by APBLRPPMTA02.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTP id 33EE5vOw024648; Fri, 14 Apr 2023 14:05:57 GMT Received: from pps.reinject (localhost [127.0.0.1]) by APBLRPPMTA02.qualcomm.com (PPS) with ESMTPS id 3pu1bkwpvv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 14 Apr 2023 14:05:57 +0000 Received: from APBLRPPMTA02.qualcomm.com (APBLRPPMTA02.qualcomm.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 33EE5vlC024643; Fri, 14 Apr 2023 14:05:57 GMT Received: from hu-sgudaval-hyd.qualcomm.com (hu-vnivarth-hyd.qualcomm.com [10.213.111.166]) by APBLRPPMTA02.qualcomm.com (PPS) with ESMTP id 33EE5vTQ024642; Fri, 14 Apr 2023 14:05:57 +0000 Received: by hu-sgudaval-hyd.qualcomm.com (Postfix, from userid 3994820) id 85DC1466C; Fri, 14 Apr 2023 19:35:56 +0530 (+0530) From: Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> To: agross@kernel.org, andersson@kernel.org, konrad.dybcio@linaro.org, broonie@kernel.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, cros-qcom-dts-watchers@chromium.org, linux-arm-msm@vger.kernel.org, linux-spi@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Cc: quic_msavaliy@quicinc.com, dianders@chromium.org, mka@chromium.org, swboyd@chromium.org, quic_vtanuku@quicinc.com, Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> Subject: [PATCH v3 0/3] spi: Add DMA mode support to spi-qcom-qspi Date: Fri, 14 Apr 2023 19:35:50 +0530 Message-Id: <1681481153-24036-1-git-send-email-quic_vnivarth@quicinc.com> X-Mailer: git-send-email 2.7.4 X-QCInternal: smtphost X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: F74-kWDR6i4unDVgIBqZLi47ef8HHvJw X-Proofpoint-ORIG-GUID: F74-kWDR6i4unDVgIBqZLi47ef8HHvJw X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-04-14_07,2023-04-14_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 adultscore=0 priorityscore=1501 mlxscore=0 phishscore=0 impostorscore=0 mlxlogscore=418 malwarescore=0 lowpriorityscore=0 clxscore=1011 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304140126 X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1763161963104766630?= X-GMAIL-MSGID: =?utf-8?q?1763161963104766630?= |
Series |
spi: Add DMA mode support to spi-qcom-qspi
|
|
Message
Vijaya Krishna Nivarthi
April 14, 2023, 2:05 p.m. UTC
There are large number of QSPI irqs that fire during boot/init and later on every suspend/resume. This could be made faster by doing DMA instead of PIO. Below is comparison for number of interrupts raised in 2 acenarios... Boot up and stabilise Suspend/Resume Sequence PIO DMA ======================= Boot-up 69088 19284 S/R 5066 3430 Though we have not made measurements for speed, power we expect the performance to be better with DMA mode and no regressions were encountered in testing. Vijaya Krishna Nivarthi (3): spi: dt-bindings: qcom,spi-qcom-qspi: Add iommus arm64: dts: qcom: sc7280: Add stream-id of qspi to iommus spi: spi-qcom-qspi: Add DMA mode support --- v2 -> v3: - Modified commit messages - Made a change to driver based on re-review v1 -> v2: - Added documentation file to the series - Made changes to driver based on HPG re-review --- .../bindings/spi/qcom,spi-qcom-qspi.yaml | 3 + arch/arm64/boot/dts/qcom/sc7280.dtsi | 1 + drivers/spi/spi-qcom-qspi.c | 434 +++++++++++++++++++-- 3 files changed, 407 insertions(+), 31 deletions(-)
Comments
Hi, On Fri, Apr 14, 2023 at 7:06 AM Vijaya Krishna Nivarthi <quic_vnivarth@quicinc.com> wrote: > > There are large number of QSPI irqs that fire during boot/init and later > on every suspend/resume. > This could be made faster by doing DMA instead of PIO. > Below is comparison for number of interrupts raised in 2 acenarios... s/acenarios/scenarios > Boot up and stabilise > Suspend/Resume > > Sequence PIO DMA > ======================= > Boot-up 69088 19284 > S/R 5066 3430 > > Though we have not made measurements for speed, power we expect > the performance to be better with DMA mode and no regressions were > encountered in testing. Measuring the speed isn't really very hard, so I gave it a shot. I used a truly terrible python script to do this on a Chromebook: -- import os import time os.system(""" stop ui stop powerd cd /sys/devices/system/cpu/cpufreq for policy in policy*; do cat ${policy}/cpuinfo_max_freq > ${policy}/scaling_min_freq done """) all_times = [] for i in range(1000): start = time.time() os.system("flashrom -p host -r /tmp/foo.bin") end = time.time() all_times.append(end - start) print("Iteration %d, min=%.2f, max=%.2f, avg=%.2f" % ( i, min(all_times), max(all_times), sum(all_times) / len(all_times))) -- The good news is that after applying your patches the loop runs _much_ faster. The bad news is that it runs much faster because it very quickly fails and errors out. flashrom just keeps reporting: Opened /dev/mtd0 successfully Found Programmer flash chip "Opaque flash chip" (8192 kB, Programmer-specific) on host. Reading flash... Cannot read 0x001000 bytes at 0x000000: Connection timed out read_flash: failed to read (00000000..0x7fffff). Read operation failed! FAILED. FAILED I went back and tried v1, v2, and v3 and all three versions fail.
Hi, On Fri, Apr 14, 2023 at 8:48 AM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Fri, Apr 14, 2023 at 7:06 AM Vijaya Krishna Nivarthi > <quic_vnivarth@quicinc.com> wrote: > > > > There are large number of QSPI irqs that fire during boot/init and later > > on every suspend/resume. > > This could be made faster by doing DMA instead of PIO. > > Below is comparison for number of interrupts raised in 2 acenarios... > > s/acenarios/scenarios > > > Boot up and stabilise > > Suspend/Resume > > > > Sequence PIO DMA > > ======================= > > Boot-up 69088 19284 > > S/R 5066 3430 > > > > Though we have not made measurements for speed, power we expect > > the performance to be better with DMA mode and no regressions were > > encountered in testing. > > Measuring the speed isn't really very hard, so I gave it a shot. > > I used a truly terrible python script to do this on a Chromebook: > > -- > > import os > import time > > os.system(""" > stop ui > stop powerd > > cd /sys/devices/system/cpu/cpufreq > for policy in policy*; do > cat ${policy}/cpuinfo_max_freq > ${policy}/scaling_min_freq > done > """) > > all_times = [] > for i in range(1000): > start = time.time() > os.system("flashrom -p host -r /tmp/foo.bin") > end = time.time() > > all_times.append(end - start) > print("Iteration %d, min=%.2f, max=%.2f, avg=%.2f" % ( > i, min(all_times), max(all_times), sum(all_times) / len(all_times))) > > -- > > The good news is that after applying your patches the loop runs _much_ faster. > > The bad news is that it runs much faster because it very quickly fails > and errors out. flashrom just keeps reporting: > > Opened /dev/mtd0 successfully > Found Programmer flash chip "Opaque flash chip" (8192 kB, > Programmer-specific) on host. > Reading flash... Cannot read 0x001000 bytes at 0x000000: Connection timed out > read_flash: failed to read (00000000..0x7fffff). > Read operation failed! > FAILED. > FAILED > > I went back and tried v1, v2, and v3 and all three versions fail. Ah, I see what's likely the problem. Your patch series only adds the "iommus" for sc7280 but I'm testing on sc7180. That means: 1. You need to add the iommus to _all_ the boards that have qspi. That means sc7280, sc7180, and sdm845. 2. Ideally the code should still be made to work (it should fall back to PIO mode) if DMA isn't properly enabled. That would keep old device trees working, which we're supposed to do. -Doug
On 4/14/2023 10:12 PM, Doug Anderson wrote: > Hi, > > On Fri, Apr 14, 2023 at 8:48 AM Doug Anderson <dianders@chromium.org> wrote: >> Hi, >> >> On Fri, Apr 14, 2023 at 7:06 AM Vijaya Krishna Nivarthi >> <quic_vnivarth@quicinc.com> wrote: >>> There are large number of QSPI irqs that fire during boot/init and later >>> on every suspend/resume. >>> This could be made faster by doing DMA instead of PIO. >>> Below is comparison for number of interrupts raised in 2 acenarios... >> s/acenarios/scenarios >> >>> Boot up and stabilise >>> Suspend/Resume >>> >>> Sequence PIO DMA >>> ======================= >>> Boot-up 69088 19284 >>> S/R 5066 3430 >>> >>> Though we have not made measurements for speed, power we expect >>> the performance to be better with DMA mode and no regressions were >>> encountered in testing. >> Measuring the speed isn't really very hard, so I gave it a shot. >> >> I used a truly terrible python script to do this on a Chromebook: >> >> -- >> >> import os >> import time >> >> os.system(""" >> stop ui >> stop powerd >> >> cd /sys/devices/system/cpu/cpufreq >> for policy in policy*; do >> cat ${policy}/cpuinfo_max_freq > ${policy}/scaling_min_freq >> done >> """) >> >> all_times = [] >> for i in range(1000): >> start = time.time() >> os.system("flashrom -p host -r /tmp/foo.bin") >> end = time.time() >> >> all_times.append(end - start) >> print("Iteration %d, min=%.2f, max=%.2f, avg=%.2f" % ( >> i, min(all_times), max(all_times), sum(all_times) / len(all_times))) >> >> -- >> >> The good news is that after applying your patches the loop runs _much_ faster. >> >> The bad news is that it runs much faster because it very quickly fails >> and errors out. flashrom just keeps reporting: >> >> Opened /dev/mtd0 successfully >> Found Programmer flash chip "Opaque flash chip" (8192 kB, >> Programmer-specific) on host. >> Reading flash... Cannot read 0x001000 bytes at 0x000000: Connection timed out >> read_flash: failed to read (00000000..0x7fffff). >> Read operation failed! >> FAILED. >> FAILED >> >> I went back and tried v1, v2, and v3 and all three versions fail. > Ah, I see what's likely the problem. Your patch series only adds the > "iommus" for sc7280 but I'm testing on sc7180. That means: > > 1. You need to add the iommus to _all_ the boards that have qspi. That > means sc7280, sc7180, and sdm845. > > 2. Ideally the code should still be made to work (it should fall back > to PIO mode) if DMA isn't properly enabled. That would keep old device > trees working, which we're supposed to do. Thank you very much for the review, script, test and quick debug. Will check same and update a v4. -Vijay/ > -Doug