Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp272793pxx; Thu, 29 Oct 2020 02:10:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxrk6TfTX0gVAnqvs5M9iEdvlYWRbWE7FQNyWd1fxnTmGNGpFby+myudqbQbxDd1NOjh9Cw X-Received: by 2002:a50:cf45:: with SMTP id d5mr2844748edk.225.1603962603258; Thu, 29 Oct 2020 02:10:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603962603; cv=none; d=google.com; s=arc-20160816; b=lLkZVWNB+Rgo7GOajWfBWieCYIWhGypyTESriWcdxQwwq4J4XJzFNXxIIJ6u/2kxo/ K691CEQs44dGuWrwZmvI/NLc/glRua6xp1tvGN9IQbO/fDsJVczWrhBbyYIeS6mDyGlG a+QCMd4jeGFU0d2aH3hGOeCxwQ8rGosOmrx8R4MASjHKi1NFjJUVMGTOp0srck3xqI4Z rXkJfZvDinyJeWN3FfdC7y6iW2bCkg5APzzVmVTPNZi8WElp4tY/XUiwqC3dwoHrE9BB e5DcZDkp4Qd2o5mvproURDYqQB+5Sc0+PmK9JLNVaLfihoIDaLjBKtJAmiItPEoXIhqk gVWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=4p0jzQ9xjspBaRvrMUSo2ZQkPue3DYdv+WikSwIFNA0=; b=TtaLxXjbhPJVuGIh9sUlXwupBitoI64GLoCheJASlRlk66gGSgyMqhW9F1C91JGY+G ghwJJdILkP8676VQpROEng9isX0VhGxFCaC9M6eFUSJgT2sdZgaHpEawLz7O4GzqQssg ojGFjjrh5WjpHVt6HQFA3j6IQVy8JeGBD+5QDaNJo5HiB1gSIDxMpwU2rUiPBGjtRZWI ct8obg5HCdm8VeWpFlp7CJAey1Bud16uDHUOEN4ReEYWF9BaBsavTCBjTb56zvBJAARx 88NuNclUFS3aOHCW01hn57bAi1q/F/T9d8aMNz4fNrQNy6KMZdfSfNqSAA9N/Lt0YkZe r3kw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w6si1646080edf.136.2020.10.29.02.09.39; Thu, 29 Oct 2020 02:10:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729238AbgJ2Iin convert rfc822-to-8bit (ORCPT + 99 others); Thu, 29 Oct 2020 04:38:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38786 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729975AbgJ2Ii1 (ORCPT ); Thu, 29 Oct 2020 04:38:27 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A20E2C0613D2; Thu, 29 Oct 2020 01:38:27 -0700 (PDT) Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 9CEF41F45880; Thu, 29 Oct 2020 08:38:24 +0000 (GMT) Date: Thu, 29 Oct 2020 09:38:16 +0100 From: Boris Brezillon To: Miquel Raynal Cc: mdalam@codeaurora.org, devicetree@vger.kernel.org, vigneshr@ti.com, richard@nod.at, linux-kernel@vger.kernel.org, robh+dt@kernel.org, bjorn.andersson@linaro.org, agross@kernel.org, linux-mtd@lists.infradead.org, linux-arm-msm@vger.kernel.org, sricharan@codeaurora.org Subject: Re: [PATCH 0/5] mtd: rawnand: qcom: Add support for QSPI nand Message-ID: <20201029093816.7dab154a@collabora.com> In-Reply-To: <20201029085344.5b2a4b51@xps13> References: <1602307902-16761-1-git-send-email-mdalam@codeaurora.org> <20201028104835.3dc31745@xps13> <10db598eed716d7759bc0125b6977cf1@codeaurora.org> <20201029085344.5b2a4b51@xps13> Organization: Collabora X-Mailer: Claws Mail 3.17.7 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 29 Oct 2020 08:53:44 +0100 Miquel Raynal wrote: > Hello, > > mdalam@codeaurora.org wrote on Wed, 28 Oct 2020 23:54:23 +0530: > > > On 2020-10-28 15:18, Miquel Raynal wrote: > > > Hello, > > > > > > Md Sadre Alam wrote on Sat, 10 Oct 2020 > > > 11:01:37 +0530: > > > > > >> QPIC 2.0 supports Serial NAND support in addition to all features and > > >> commands in QPIC 1.0 for parallel NAND. Parallel and Serial NAND >> cannot > > >> operate simultaneously. QSPI nand devices will connect to QPIC >> IO_MACRO > > >> block of QPIC controller. There is a separate IO_MACRO clock for >> IO_MACRO > > >> block. Default IO_MACRO block divide the input clock by 4. so if >> IO_MACRO > > >> input clock is 320MHz then on bus it will be 80MHz, so QSPI nand >> device > > >> should also support this frequency. > > >> >> QPIC provides 4 data pins to QSPI nand. In standard SPI mode (x1 mode) >> data > > >> transfer will occur on only 2 pins one pin for Serial data in and one >> for > > >> serial data out. In QUAD SPI mode (x4 mode) data transfer will occur >> at all > > >> the four data lines. QPIC controller supports command for x1 mode and >> x4 mode. > > >> >> Md Sadre Alam (5): > > >> dt-bindings: qcom_nandc: IPQ5018 QPIC NAND documentation > > >> mtd: rawnand: qcom: Add initial support for qspi nand > > >> mtd: rawnand: qcom: Read QPIC version > > >> mtd: rawnand: qcom: Enable support for erase,read & write for serial > > >> nand. > > >> mtd: rawnand: qcom: Add support for serial training. > > >> >> .../devicetree/bindings/mtd/qcom_nandc.txt | 3 + > > >> drivers/mtd/nand/raw/nand_ids.c | 13 + > > >> drivers/mtd/nand/raw/qcom_nandc.c | 502 >> ++++++++++++++++++++- > > >> 3 files changed, 494 insertions(+), 24 deletions(-) > > >> > > I'm sorry but this series clearly breaks the current layering. I cannot > > > authorize SPI-NAND code to fall into the raw NAND subsystem. > > > > > > > I am agree with you, we should not add SPI-NAND changes inside > > raw NAND subsystem. > > > > > As both typologies cannot be used at the same time, I guess you should > > > have another driver handling this feature under the spi/ subsystem + > > > a few declarations in the SPI-NAND devices list. > > > > > > > Initially I was started writing separate driver under SPI-NAND subsystem then I > > realized that more than 85% of raw/qcom_nand.c code getting duplicated. > > > > That's why I have added this SPI-NAND change in raw/qcom_nand.c since > > more than 85% of code will be reused. > > > > If I will add this change inside SPI-NAND subsystem then much of > > raw/qcom_nand.c code will get duplicated. Would it be ok ? > > What about moving the generic code to drivers/mtd/nand/common/ and Yeah, I don't think drivers/mtd/nand/common/ is the right place to put this common code TBH, and I don't really see what's to be shared between the NAND controller and SPI controller drivers. If it's just helpers to access the registers, those can probably live in drivers/soc/qcom/qcom_qpic2.c. > referring to it from drivers/mtd/nand/raw/qcom_nand.c and > drivers/spi/spi-qcom.c (or such)? > > Thanks, > Miquèl > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/