Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp1875064ybp; Wed, 9 Oct 2019 22:09:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqz/9zDLSkl/8IkRqGiWkbe43FdaIVe9aqvl7AivXo30oD/X3RWl6XIuzYhmqiUs2Akeq0mK X-Received: by 2002:a05:6402:13d5:: with SMTP id a21mr6516590edx.242.1570684175128; Wed, 09 Oct 2019 22:09:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570684175; cv=none; d=google.com; s=arc-20160816; b=DIdfS975SyKUCESYhdJaziFNuEPM79dHA9Z82TWHsb82Y61UQB7uv4tnZvD1/eCNCr Qv9KkHDz8ataTOJ3X80l+I6r+hS6ebHKBXGPneAL1LehVzwyan+N9GFZE85bzuhOnWuW D25/q6oujjUtXQkE7EeaSNmPX0JaMOGgsMVJFpGd9hjZJf+nowqyICG/jOgXVcNl6kbS VloZhfdXk77SF7dJ2w8wKiG6lZT3r4RSs0MYKESb+F+l9U3dQowfqd5Xl28mCl/1px0M NwBRPBX31BkSu3BnoB5yYg2qXRkevoQvFJIf32srN3HugEWXhoSllOnQJtULdVSLeUc5 B7+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=hBFZDfGuR1eCz504rymY6yn+Gz1DNyTRNd0ksweYHTI=; b=bu97VrGiPxhSczupn4TdIWr9GtkOn+WEzL6byYNs4FANrd9BIxbUbOdm/7H80SyMXm k8BDA2kuU1+1VIuLZ8jX2CFDq1NWEg4EDNG/tuINAM0mpSdCAHw8KyJF9aJQT671DTCb iAQ3TWCqHQtgHDb69GH7A1pF3zlz9tiIV6PzS5U/56wPU+DPVuBaqgeXj8uwDJwAKVXU tgwKTvMM4cgAslWEYuWYZhMkmT7aXEryTDMynlT5K2G5mlccpeOwOtFpKiatKP+kVW5H jqHkccckXV3do2U9fR813KVSz1yjhdEB+rwlM8U3FaZMS68fng8z1TAobfkSdAw3Ogw7 qofQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s27si2589976edm.226.2019.10.09.22.09.10; Wed, 09 Oct 2019 22:09:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728153AbfJJFJD (ORCPT + 99 others); Thu, 10 Oct 2019 01:09:03 -0400 Received: from mga09.intel.com ([134.134.136.24]:23904 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726065AbfJJFJD (ORCPT ); Thu, 10 Oct 2019 01:09:03 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2019 22:09:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,278,1566889200"; d="scan'208";a="218904879" Received: from linux.intel.com ([10.54.29.200]) by fmsmga004.fm.intel.com with ESMTP; 09 Oct 2019 22:09:01 -0700 Received: from [10.226.38.27] (unknown [10.226.38.27]) by linux.intel.com (Postfix) with ESMTP id AF7C75802B9; Wed, 9 Oct 2019 22:08:59 -0700 (PDT) Subject: Re: [PATCH v1 0/2] spi: cadence-qspi: Add cadence-qspi support for Intel LGM SoC To: Vignesh Raghavendra , broonie@kernel.org Cc: robh+dt@kernel.org, mark.rutland@arm.com, linux-spi@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, cheol.yong.kim@intel.com, qi-ming.wu@intel.com References: <20190916073843.39618-1-vadivel.muruganx.ramuthevar@linux.intel.com> <89e49834-8697-2917-d666-769969f074a4@linux.intel.com> <21cb17ab-b272-ce35-67fc-abce56969fee@ti.com> From: "Ramuthevar, Vadivel MuruganX" Message-ID: <897dd6a2-e319-4e67-48aa-dfd179e11609@linux.intel.com> Date: Thu, 10 Oct 2019 13:08:58 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <21cb17ab-b272-ce35-67fc-abce56969fee@ti.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vignesh, On 10/10/2019 12:18 PM, Vignesh Raghavendra wrote: > > On 10/10/19 7:04 AM, Ramuthevar, Vadivel MuruganX wrote: >> HI Vignesh, >> >> On 17/9/2019 12:50 AM, Vignesh Raghavendra wrote: >>> Hi, >>> >>> On 16/09/19 1:08 PM, Ramuthevar,Vadivel MuruganX wrote: >>>> patch 1: Add YAML for cadence-qspi devicetree cdocumentation. >>>> patch 2: cadence-qspi controller driver to support QSPI-NAND flash >>>> using existing spi-nand framework with legacy spi protocol. >>> Nope, you cannot have two drivers for the same IP (i.e Cadence QSPI) >>> just to support to different types of SPI memories. This is the reason >>> why spi_mem_ops was introduced. >>> >>> Please rewrite this driver over to use spi_mem_ops (instead of using >>> generic SPI xfers) so that same driver supports both SPI-NOR and >>> SPI-NAND flashes. Once that's done drivers/mtd/spi-nor/cadence-quadspi.c >>> can be deleted. >>> >>> There are few existing examples of spi_mem_ops users in drivers/spi/ >>> (git grep spi_mem_ops) and materials here on how to write such a driver: >>> >>> [1] >>> https://bootlin.com/blog/spi-mem-bringing-some-consistency-to-the-spi-memory-ecosystem/ >>> >>> [2] https://www.youtube.com/watch?v=PkWbuLM_gmU >> As per Mark Brown and your suggestion,  I have started adapting >> cadence-qaudspi driver with spi_mem_ops framework to work >> QSPI-NAND/NOR as a generic driver(completely removed the legacy >> SPI-XFERS),  is in progress on Intel LGM SoC. >> QSPI-IP on Intel LGM  do not have DMA  support and also not part of QSPI >> IP, so couldn't able to validate DMA related. >> will adapt the DMA things which are existing in cadence-quadspi.c as it is. >> > Great, appreciate the effort! > >> currently TI and Altera SoC's use this Cadence-qspi IP , both are not >> using DMA as per my understanding (correct me if it is wrong). >> confirmed through device tree entry. >> > TI platforms use DMA to read data from flash in memory mapped mode > (direct access controller) using mem-to-mem DMA channels. Mem-to-mem DMA > channels are requested as and when needed and are not part of DT > description (as they are not bound to a device) yes, understood now, Thanks! >> what is your opinion on DMA related stuff? > Not having DMA support would be a regression. Please keep the DAC + DMA > part as is. I can help you will all the DMA related testing... Sure, will keep DAC + DMA, as we discussed earlier use QUIRKS to differentiate and follow the same. --- With Regards Vadivel > Regards > Vignesh > >> also using macronix(QSPI-NOR) >> flash/Micron(QSPI-NAND). >> --- >> With Regards >> Vadivel >>>> Ramuthevar Vadivel Murugan (2): >>>>    dt-bindings: spi: Add support for cadence-qspi IP Intel LGM SoC >>>>    spi: cadence-qspi: Add QSPI support for Intel LGM SoC >>>> >>>>   .../devicetree/bindings/spi/cadence,qspi-nand.yaml |  84 +++ >>>>   drivers/spi/Kconfig                                |   9 + >>>>   drivers/spi/Makefile                               |   1 + >>>>   drivers/spi/spi-cadence-qspi-apb.c                 | 644 >>>> +++++++++++++++++++++ >>>>   drivers/spi/spi-cadence-qspi-apb.h                 | 174 ++++++ >>>>   drivers/spi/spi-cadence-qspi.c                     | 461 >>>> +++++++++++++++ >>>>   drivers/spi/spi-cadence-qspi.h                     |  73 +++ >>>>   7 files changed, 1446 insertions(+) >>>>   create mode 100644 >>>> Documentation/devicetree/bindings/spi/cadence,qspi-nand.yaml >>>>   create mode 100644 drivers/spi/spi-cadence-qspi-apb.c >>>>   create mode 100644 drivers/spi/spi-cadence-qspi-apb.h >>>>   create mode 100644 drivers/spi/spi-cadence-qspi.c >>>>   create mode 100644 drivers/spi/spi-cadence-qspi.h >>>>