Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp1210938ybi; Wed, 3 Jul 2019 11:26:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqy1/tqXXY3ubqwSeAeBUBMw7/wUKJ523HAzEkNOjzFEUou2b7Knu0Ek0b/v7gpAGSs/ALXM X-Received: by 2002:a17:902:ac86:: with SMTP id h6mr40872610plr.98.1562178368153; Wed, 03 Jul 2019 11:26:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562178368; cv=none; d=google.com; s=arc-20160816; b=wUDtWZWGYC1s43ZxaNrFHCWkAwflWjKtnT8E0JK5lMJGCRSYN1IWgAfQGjNZmQWOO2 KiuFzo3zUjM0GfJNXzbarUByfd6L89fRQo9uCKygYGaRObFWF3Z5wyJM3FpKtnBwaNzd fqJSgde+o9LDmxuqZrqZQ3WZuNJ9Ce5mN2k6b/sXlm8Kvjnytegv6f7SuPaXJjL059sm VTDhBz5imr70hqBUxzelG6GngdbHSW45zoRoFXF+YS6Al4lbCyXR63cEFGQKy41Pz3eL Vi/KiMdqTJoAMTQVwU/muw9U5NqDgEMxothPYDUg5aQKngzk6h3tSIip8ap2vZwSp1XW IFgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject :dkim-signature; bh=Chz7KpzfDvb4cnBPbwvegn1AV1XaBRdzu8IfAxBfQ5I=; b=QD8mDvL8HVFSRXpUqksmC1cS5zNvT2DLmlzKajlJMUD8d3CFJA3/82lm75eGIReZZy 06Etj5d3I2GXMtZ7hPEZBNcS8kHM/SlpaDMM3ZHB7VIL2VQNplWV2+JlnQrCENthZ3oS H3SIBkbRFT6LgIDYd55Klv5LVfIF8c9Qdq9VueoFmU7J6LmDHMzMOtERBm5bbLFidte7 Y1n+U4mtHwdHY5Gim9sJqp74uh72W7N244BxfWemFHg7ewp3Rnqr5f8w891yWwiBwM40 qvPoI2GmpBHv0tHkY3PKTFkpUfpCeQZdlAX7tjhyTFk9Ymm063qF8O5bHCWu3pb5KCaR HbSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cogentembedded-com.20150623.gappssmtp.com header.s=20150623 header.b="EbX/sgax"; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a63si2844887pla.348.2019.07.03.11.25.52; Wed, 03 Jul 2019 11:26:08 -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; dkim=pass header.i=@cogentembedded-com.20150623.gappssmtp.com header.s=20150623 header.b="EbX/sgax"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727032AbfGCSOG (ORCPT + 99 others); Wed, 3 Jul 2019 14:14:06 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:45036 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726845AbfGCSOG (ORCPT ); Wed, 3 Jul 2019 14:14:06 -0400 Received: by mail-lj1-f195.google.com with SMTP id k18so3442631ljc.11 for ; Wed, 03 Jul 2019 11:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cogentembedded-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Chz7KpzfDvb4cnBPbwvegn1AV1XaBRdzu8IfAxBfQ5I=; b=EbX/sgaxxHFwsU8r1WEvx2OotnABVYExtQp10LvIyCVm9iETlGlR0qTT/HGyH4ncpI dsfpLRJ4yceh680j4RwwUkSvmS+FUTReqoSu8asLR3dTcJtGaT1Im4/p060H9dj7FZLf DTxBgsrXJ35tib7SreK4cIC0eJcI4vNdDroQnYoSiSllACf1Appfu5TuhnRPE6sU8Hn1 HABwqoVCDdsOKcWWZJqxJC1q0QKulmoxO7nuuKcH11gVvjuHSH8z6ZtrmKfvzTkPu5s6 WJ1st9bKhy0Yqtzx+khfGOGRRrcVDfN/Tp0BMnW5GdZ9FQ5piRaJyinPh7gWRrb+yXOK C7Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Chz7KpzfDvb4cnBPbwvegn1AV1XaBRdzu8IfAxBfQ5I=; b=KDZEb/aiYW3UWvjAsko1LEMJZCllHPL0H9M2iR7LqW87jiIfA6cHoxDt5fUgsw18QA sr3zKa3sm1r/lLTqpVY/yyXro49mv1KTzJ2b3RtrbshaKnC9dj1ZnzCjhERa9N6ozE5m 1Lkgrdw80jXJjpns+h6xwjRQh3LIYhMY12Uc8BGwIPvojWanTLMTRwlZcjOikWhuzSA0 7UClV8hp31EM44pDcvlNvjQcEIByKzFJ7XPyNU/68L20gjCxcnargx/hL3jobhE/7sDV NP0Yvmb10dyTGFcpfPFeC30gn1AI1DI+Hry5fIlkLrUxlsP6sqMhqTI+ZI+zjJpdm9/t lCRg== X-Gm-Message-State: APjAAAXpnmXLEWaCzVC4hRDlKVtmKcFWhJvsjj6jKukckp4gSLFYfHVn gbdPR6K1UK9w7ZmN3cYVYIbgcg== X-Received: by 2002:a2e:9213:: with SMTP id k19mr22028028ljg.237.1562177644239; Wed, 03 Jul 2019 11:14:04 -0700 (PDT) Received: from wasted.cogentembedded.com ([2a00:1fa0:4463:651e:e5a9:49e2:7053:81e9]) by smtp.gmail.com with ESMTPSA id o11sm496196lfl.15.2019.07.03.11.14.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 11:14:03 -0700 (PDT) Subject: Re: [PATCH v8 3/5] mtd: Add support for HyperBus memory devices To: Vignesh Raghavendra , Boris Brezillon , Marek Vasut , Richard Weinberger , Rob Herring Cc: linux-mtd@lists.infradead.org, Miquel Raynal , devicetree@vger.kernel.org, Mason Yang , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Tokunori Ikegami References: <20190625075746.10439-1-vigneshr@ti.com> <20190625075746.10439-4-vigneshr@ti.com> <31657fd1-c1c9-7672-14c1-e6f67eee6ac1@cogentembedded.com> <5009c418-a051-a42a-f78a-360f7230dd2b@ti.com> From: Sergei Shtylyov Organization: Cogent Embedded Message-ID: <8e870356-90ba-4762-b1fd-8a13ce6ebcc8@cogentembedded.com> Date: Wed, 3 Jul 2019 21:14:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5009c418-a051-a42a-f78a-360f7230dd2b@ti.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-MW Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello! On 07/03/2019 07:41 AM, Vignesh Raghavendra wrote: >>> Cypress' HyperBus is Low Signal Count, High Performance Double Data Rate >>> Bus interface between a host system master and one or more slave >>> interfaces. HyperBus is used to connect microprocessor, microcontroller, >>> or ASIC devices with random access NOR flash memory (called HyperFlash) >>> or self refresh DRAM (called HyperRAM). >>> >>> Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) >>> signal and either Single-ended clock(3.0V parts) or Differential clock >>> (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. >>> At bus level, it follows a separate protocol described in HyperBus >>> specification[1]. >>> >>> HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar >>> to that of existing parallel NORs. Since HyperBus is x8 DDR bus, >>> its equivalent to x16 parallel NOR flash with respect to bits per clock >>> cycle. But HyperBus operates at >166MHz frequencies. >>> HyperRAM provides direct random read/write access to flash memory >>> array. >>> >>> But, HyperBus memory controllers seem to abstract implementation details >>> and expose a simple MMIO interface to access connected flash. >>> >>> Add support for registering HyperFlash devices with MTD framework. MTD >>> maps framework along with CFI chip support framework are used to support >>> communicating with flash. >>> >>> Framework is modelled along the lines of spi-nor framework. HyperBus >>> memory controller (HBMC) drivers calls hyperbus_register_device() to >>> register a single HyperFlash device. HyperFlash core parses MMIO access >>> information from DT, sets up the map_info struct, probes CFI flash and >>> registers it with MTD framework. >>> >>> Some HBMC masters need calibration/training sequence[3] to be carried >>> out, in order for DLL inside the controller to lock, by reading a known >>> string/pattern. This is done by repeatedly reading CFI Query >>> Identification String. Calibration needs to be done before trying to detect >>> flash as part of CFI flash probe. >>> >>> HyperRAM is not supported at the moment. >>> >>> HyperBus specification can be found at[1] >>> HyperFlash datasheet can be found at[2] >>> >>> [1] https://www.cypress.com/file/213356/download >>> [2] https://www.cypress.com/file/213346/download >>> [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf >>> Table 12-5741. HyperFlash Access Sequence >>> >>> Signed-off-by: Vignesh Raghavendra >> [...] >> >> I have at least created my HyperBus driver and unfortunately I'm having serious At last. :-) >> issues with the design of the support core (see below)... >> >> [...] >>> diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c >>> new file mode 100644 >>> index 000000000000..63a9e64895bc >>> --- /dev/null >>> +++ b/drivers/mtd/hyperbus/hyperbus-core.c >>> @@ -0,0 +1,154 @@ >> [...] >>> +int hyperbus_register_device(struct hyperbus_device *hbdev) >>> +{ >>> + const struct hyperbus_ops *ops; >>> + struct hyperbus_ctlr *ctlr; >>> + struct device_node *np; >>> + struct map_info *map; >>> + struct resource res; >>> + struct device *dev; >>> + int ret; >>> + >>> + if (!hbdev || !hbdev->np || !hbdev->ctlr || !hbdev->ctlr->dev) { >>> + pr_err("hyperbus: please fill all the necessary fields!\n"); >>> + return -EINVAL; >>> + } >>> + >>> + np = hbdev->np; >>> + ctlr = hbdev->ctlr; >>> + if (!of_device_is_compatible(np, "cypress,hyperflash")) >>> + return -ENODEV; >>> + >>> + hbdev->memtype = HYPERFLASH; >>> + >>> + ret = of_address_to_resource(np, 0, &res); >> >> Hm, I doubt that the HB devices are wholly mapped into memory space, that seems >> like a property of the HB controller. In my case, the flash device in the DT has >> only single-cell "reg" prop (equal to the chip select #). Then this function returns >> -EINVAL and the registration fails. Also, in my case such mapping is R/O, not R/W. >> > > You could declare R/O MMIO region in controla and set up a translation using ranges > from slave's reg CS based reg mapping like: No, not all HB controllers work the same (simple) way as yours. In case of RPC-IF, the direct read map is a 64 MiB window into a possibly larger flash chip, it has a register supplying address bits 25:31... > + hbmc: hyperbus@47034000 { > + compatible = "ti,am654-hbmc"; > + reg = <0x0 0x47034000 0x0 0x100>, > + <0x5 0x00000000 0x1 0x0000000>; > + #address-cells = <2>; > + #size-cells = <1>; > + ranges = <0x0 0x0 0x5 0x00000000 0x4000000>, /* CS0 - 64MB */ > + <0x1 0x0 0x5 0x04000000 0x4000000>; /* CS1 - 64MB */ > + > + /* Slave flash node */ > + flash@0,0 { > + compatible = "cypress,hyperflash", "cfi-flash"; > + reg = <0x0 0x0 0x4000000>; > + }; > + }; > > If you use just CS# how would you handle CS to MMIO region mapping? > Does both CS use the same MMIO base for reads? The RPC-IF HF mode only has a single CS signal. [...] MBR, Sergei