From patchwork Wed Jun 24 18:50:51 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Srinivas Kandagatla X-Patchwork-Id: 6669881 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id A1C1C9F1C1 for ; Wed, 24 Jun 2015 18:54:43 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B68B5205BA for ; Wed, 24 Jun 2015 18:54:42 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CB98E205B4 for ; Wed, 24 Jun 2015 18:54:41 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Z7plZ-0006Ta-TJ; Wed, 24 Jun 2015 18:51:21 +0000 Received: from mail-wg0-f45.google.com ([74.125.82.45]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Z7plW-0006RN-Gl for linux-arm-kernel@lists.infradead.org; Wed, 24 Jun 2015 18:51:19 +0000 Received: by wgck11 with SMTP id k11so43908786wgc.0 for ; Wed, 24 Jun 2015 11:50:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=84Dh9dy5f0ffIyAuxo7LzetIcEBFQLLNcCsPnxV6V9U=; b=YETcEKcIwBgy4ThUo9B/y1xPClhp/fJH1A7j9NjQxlN5TZa69+shKLDWLK09EyBvZj r6b32iqM2LsFt+86B8Jx6mHkSLY3zOGkhofUgE31ehod9HRRu1ZB/PT7+wcIQLnw+ocb vLtQDV2PXrY5P/gcZJFRiNTsIfrm7pc063pf4APktG78IjGwXdaFAcDEyOZbVAxnnDY7 6Vc8be4AFnEvwytn2Z6aMO4b6frJPPQ5zQsT8Te8itdehkKYjp1eVq3cvuXh6KopiynV z9xDqfa3V/O/0E9+f+XbQwoEch2aX3s7gcQf5OGhEygW+bZNCre/gTyCgv+60Cf9P1D2 Y6wA== X-Gm-Message-State: ALoCoQliXfI4XIxwhR5kPQYoRq3/G2tfZ9yR2Tm7tDWk7YLu1Ch8gzljFsrnWgfrwaQfWTLvER37 X-Received: by 10.180.84.170 with SMTP id a10mr7663334wiz.52.1435171855746; Wed, 24 Jun 2015 11:50:55 -0700 (PDT) Received: from [192.168.1.8] (host-78-147-7-145.as13285.net. [78.147.7.145]) by mx.google.com with ESMTPSA id ju2sm3838340wid.12.2015.06.24.11.50.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2015 11:50:54 -0700 (PDT) Message-ID: <558AFC0B.1050400@linaro.org> Date: Wed, 24 Jun 2015 19:50:51 +0100 From: Srinivas Kandagatla User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stefan Wahren , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v6 0/9] Add simple NVMEM Framework via regmap. References: <1435014459-26138-1-git-send-email-srinivas.kandagatla@linaro.org> <235181230.251177.1435088854197.JavaMail.open-xchange@oxbsltgw00.schlund.de> <558A7C92.2040102@linaro.org> <558AA2E2.1010606@i2se.com> <558AAA8D.8030209@linaro.org> <1641569650.41238.1435168054323.JavaMail.open-xchange@oxbsltgw35.schlund.de> In-Reply-To: <1641569650.41238.1435168054323.JavaMail.open-xchange@oxbsltgw35.schlund.de> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150624_115118_751755_20AA2166 X-CRM114-Status: GOOD ( 26.35 ) X-Spam-Score: -1.9 (-) Cc: devicetree@vger.kernel.org, arnd@arndb.de, Greg Kroah-Hartman , linux-api@vger.kernel.org, s.hauer@pengutronix.de, sboyd@codeaurora.org, linux-kernel@vger.kernel.org, pantelis.antoniou@konsulko.com, Rob Herring , Mark Brown , Kumar Gala , mporter@konsulko.com, Maxime Ripard , linux-arm-msm@vger.kernel.org, wxt@rock-chips.com X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 24/06/15 18:47, Stefan Wahren wrote: > Hi Srinivas, > >> Srinivas Kandagatla hat am 24. Juni 2015 um >> 15:03 geschrieben: >> >> >> >> >> On 24/06/15 13:30, Stefan Wahren wrote: >>>>> If the question is just about hexdump, then hexdump itself can read >>>>> file from given offset and size. >>> yes, this is my question at first. Let me show the difference between >>> the current implementation and my expectations as a user. >>> >>> $ hexdump /sys/class/nvmem/mxs-ocotp/nvmem >>> >>> Current implementation: dump the complete register range defined in DT >>> >> Its dumping the range which is specified in the provider regmap. If the >> requirement is to dump only particular range, this has to be made >> explicit while creating regmap, which is to specify the base address to >> start from "First data register" and max_register to be "Last data >> register "- "First data register" > > i know about max_register, but i can't find the base address in regmap_config. > Base is not in the regmap config, its the value which you pass to the For example, if I had to do similar change to qfprom driver It would look like: ><-----------------------cut--------------------------------->< return PTR_ERR(regmap); ><-----------------------cut--------------------------------->< --srini > Do you mean struct regmap_access_table *rd_table ? > >> >>> User expectation: dump only the data from OCOTP block >>> >>> Let me explain it for i.MX28 OCOTP >>> >>> 0x8002c000 // Start of OCOTP register block (defined in DT) >>> >>> 0x8002c020 // First data register >>> >>> 0x8002c290 // Last data register >>> >>> 0x8002dfff // End of OCOTP register block (defined in DT) >>> >>> My knowledge about regmap is limited, but how can i achieve that hexdump >>> give me only the data registers? From my understanding this should be >>> handled in regmap and not in the read function. >> >> Setup the base and regmap_config correctly in the provider driver before >> calling regmap_init_mmio(). >> >> Let me know if you need more details. > > Yes, please. > > Stefan > >> >> --srini >> >>> >>> Are my expectations about the raw access wrong? >>> >>> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- > To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c index 7f7a82f..26ced95 100644 --- a/drivers/nvmem/qfprom.c +++ b/drivers/nvmem/qfprom.c @@ -52,9 +52,9 @@ static int qfprom_probe(struct platform_device *pdev) if (IS_ERR(base)) return PTR_ERR(base); - qfprom_regmap_config.max_register = resource_size(res) - 1; + qfprom_regmap_config.max_register = my_data_size; - regmap = devm_regmap_init_mmio(dev, base, &qfprom_regmap_config); + regmap = devm_regmap_init_mmio(dev, base + data_offset, &qfprom_regmap_config); if (IS_ERR(regmap)) { dev_err(dev, "regmap init failed\n");