From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5A449C433F5 for ; Wed, 13 Apr 2022 03:55:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232204AbiDMD5f (ORCPT ); Tue, 12 Apr 2022 23:57:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41824 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232170AbiDMD51 (ORCPT ); Tue, 12 Apr 2022 23:57:27 -0400 Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5BF4D13CCE for ; Tue, 12 Apr 2022 20:55:07 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id b188so803956oia.13 for ; Tue, 12 Apr 2022 20:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=FvzKmQHaXA0DZABJVytp1jfjqBhOZKxzqyShV5ysPaI=; b=OAYW9UBBpw4A+iCY4I5EaWlkldsxeOp+anBKmwX62Q0TRRCSFVHoTCU5lunO/PwDLx o9Lq+MXt+IxvKdH0+TdwOTFmR5YDmI6ZONy2//sJsfgol5+xR2NEjtKeNDnKFkHRMyLX uQV14/xbRAHLShTXWvkTeNZPc7KBdG+lJ2ai5PR/UXkH2YMusFSkfEqo/SBYzYCMwiRZ 4CwUcjqa5I8qMkUoPikziGCvExKSgudLFV/G9BqZmw6fXq1ERAJUJUcr8gfAmhDtNXAO U/SWYihomjkSpBd2ZLvLsVY6dBsmG35qBse0B1wtgjTr82HNcKu1hl4mrtjzl7oddirx 0AMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=FvzKmQHaXA0DZABJVytp1jfjqBhOZKxzqyShV5ysPaI=; b=7Mja+juIjJ92iAlADg5Cu3SyyOsLVprqvxyBh9keIFWq32VxyDqD9Pw84k3+EZOSgI lUcbmo3svhso77fjdzSgc4s3w+SiQp1TwHIJLksqIn+pJLNKKj26v1Pr/oSFvhtHpC4+ svpUJ58fRoSC2n6z0ZGeNToHJEV2kwVtIPD6KU/8wmQh6JzzNLpj5x9ut+CnYaEmQRUk kNDSWskE6C+04Se2rfu72noinKiIgezwd3tru+wdU081jaUUugmBrsxn4LI9lvq8I5r6 pPEkpRy35kDcrCZJ9vhOpu7kdYPBrWJRbJZDPGBMCRLkidok20D1zHxRk2qx7WaWW7fM K9VQ== X-Gm-Message-State: AOAM531EFu9vu9MHftCXPdm9sdu+eNXC+STZoO88nIcpOeIWiQgGdw4i nci1y4sxS0kK14REkLTgd2orXw== X-Google-Smtp-Source: ABdhPJytHv9MYWBDz80W+4BG+BN0cR8bkxDn1ifdKRCOmARN+MzL0v9/ak+9qWlwCN1TEpvdUahlHA== X-Received: by 2002:a05:6808:1201:b0:2f9:ef08:1a4f with SMTP id a1-20020a056808120100b002f9ef081a4fmr3263265oil.192.1649822106718; Tue, 12 Apr 2022 20:55:06 -0700 (PDT) Received: from ripper ([2600:1700:a0:3dc8:205:1bff:fec0:b9b3]) by smtp.gmail.com with ESMTPSA id e9-20020a056820060900b003216277bfdasm13576747oow.19.2022.04.12.20.55.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 20:55:06 -0700 (PDT) Date: Tue, 12 Apr 2022 20:57:20 -0700 From: Bjorn Andersson To: Vinod Koul Cc: Rob Herring , Krzysztof Kozlowski , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] arm64: dts: qcom: sm8350: Add GENI I2C/SPI DMA channels Message-ID: References: <20220412215137.2385831-1-bjorn.andersson@linaro.org> <20220412215137.2385831-2-bjorn.andersson@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue 12 Apr 20:14 PDT 2022, Vinod Koul wrote: > On 12-04-22, 14:51, Bjorn Andersson wrote: > > The GENI I2C and SPI controllers may use the GPI DMA engine, define the > > rx and tx channels for these controllers to enable this. > > > > Signed-off-by: Bjorn Andersson > > --- > > arch/arm64/boot/dts/qcom/sm8350.dtsi | 108 +++++++++++++++++++++++++++ > > 1 file changed, 108 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi > > index 7e585d9e4c68..8547c0b2f060 100644 > > --- a/arch/arm64/boot/dts/qcom/sm8350.dtsi > > +++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi > > @@ -721,6 +721,9 @@ i2c14: i2c@880000 { > > pinctrl-names = "default"; > > pinctrl-0 = <&qup_i2c14_default>; > > interrupts = ; > > + dmas = <&gpi_dma2 0 0 QCOM_GPI_I2C>, > > + <&gpi_dma2 1 0 QCOM_GPI_I2C>; > > + dma-names = "tx", "rx"; > > I have been thinking about this. I dont feel this is right approach here > as this is board dependent and having the firmware loaded on the board.. > > This was tested on HDK and can fail in MTP or other boards.. which might > be in FIFO mode > But if the controller is in FIFO mode, then !fifo_disable so we wouldn't try to pick up the dmas. And in the opposite case, i.e. when fifo_disable, the introduction of the GPI implementation meant that the i2c driver wouldn't no longer probe without the dmas specified. Unfortunately we don't have any i2c busses enabled on the MTP currently, so I'm not able to validate this easily. For the SPI driver though, the same logic is used to invoke spi_geni_grab_gpi_chan(). So dmas will only be considered if fifo_disabled is set. That said, in the even that the SPI driver finds a fifo_disabled controller and dma_request_chan() returns an error, we will fall back to fifo mode instead. I'm not sure if that's desirable... If that makes sense, we should at least handle EPROBE_DEFER instead of falling through to fifo mode. Regards, Bjorn > So, I think it might be apt to move these to board dtsi.. what do you > think? > > -- > ~Vinod