Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5505804yba; Wed, 8 May 2019 14:39:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqyUPIKbBpK0FOm3j1EoeqOqss7Xmis2eSFNx7JzUEO/pJuA32ZioDB530pQJpKhEIP5A8HZ X-Received: by 2002:a62:6807:: with SMTP id d7mr51128721pfc.75.1557351578781; Wed, 08 May 2019 14:39:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557351578; cv=none; d=google.com; s=arc-20160816; b=HpOOzD2xmATrsKzrlH2//xIL06A99TDbIfkA0+cCvFsOtnvhzsUWSrheB2ebmSG16k M+pI5HOdeDgxdWgZ+Ug1346kyOPcrzj162xSuo9oCEXEYks2pHJncBTrfJsFA+YYlGHA UPy2RCJva8zzUsVHxzaJIAgFjzbVzlg3ftgclZlSQBgqNDgxJeI3lHm2Cpj8b4PYbLUQ mSk119jUKjVkPQsEV6Yw+epMmTkZEv37sHZSOhT6CTXLMeAW9NvZypEamUPCEU7gVh+H Op5s3Pmf9PN6gl8+wwpb0ey7hcz/M8UMmXIKLksHSFumnU7OtLptEquKWhzkLwZRbS1I xqXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=5aJG1c6vlheNdOqjrdl3fJiyQzUboYjwPsleuLlW+7s=; b=HUTOBKacq2PAU4JUxcMSGvMeChvY1EVE+gxIjzYsurVTD+dqmoRQ2Xbbe7C/1Xr87x AunsVf9XXxqn41BlB4fWd6ckPBBx62cT/i+PX1RTyf+zyktDp3QFDsWHmcgOAB3y9ytZ yab17/BdMI0i07cnEqLTDFxJogEZgRIV7l5wpfLdEv1N4JgXyscdc0GBkuEHJZ548qId cZSRKzaffHctH+QR2Ofeha5Vjg8oQv45beJqIB1P8m2BQSnMbCEyJfFqgBVVUaZWFNHf OdlrMmmHrUzADCrc8NYuH1MbJiZZlaBzM1lTrp0sYt5D9DH3Jtg3qV9z5GJvXRqsQWmS +o+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NVRkrMZZ; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r127si740pfr.78.2019.05.08.14.39.23; Wed, 08 May 2019 14:39:38 -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=@kernel.org header.s=default header.b=NVRkrMZZ; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728405AbfEHUf2 (ORCPT + 99 others); Wed, 8 May 2019 16:35:28 -0400 Received: from mail.kernel.org ([198.145.29.99]:39340 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726526AbfEHUf2 (ORCPT ); Wed, 8 May 2019 16:35:28 -0400 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 679042173E; Wed, 8 May 2019 20:35:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557347727; bh=5aJG1c6vlheNdOqjrdl3fJiyQzUboYjwPsleuLlW+7s=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NVRkrMZZAMA55Yn9gLTgQc1JSqU32PF1aw5Z7lEUXbLaF1VOaCTYr9NN7g3zR6eek Yjjc6KY51ZTFSq1SER63IvktW0DkDb8dxTcniSKWMv4PnFFKTZ1AfopaDuHQbcukfc +Spl7TjXmM0Qt8o/7LLIhRQbcixnrtiLiBoKdZ+I= Received: by mail-qt1-f172.google.com with SMTP id a17so27733qth.3; Wed, 08 May 2019 13:35:27 -0700 (PDT) X-Gm-Message-State: APjAAAUw7oLSJEXNcU+ry8adEGCxx0LqQVuUNwcXjFX1rYqUlYRFcXq0 yQ2bPkcHTAryVEEhsa2NV3VGxpnwAjM3clcbxg== X-Received: by 2002:a0c:f68e:: with SMTP id p14mr182544qvn.77.1557347726619; Wed, 08 May 2019 13:35:26 -0700 (PDT) MIME-Version: 1.0 References: <1557155521-30949-1-git-send-email-l.luba@partner.samsung.com> <1557155521-30949-8-git-send-email-l.luba@partner.samsung.com> <20190507170422.GA25179@bogus> In-Reply-To: From: Rob Herring Date: Wed, 8 May 2019 15:35:15 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7 07/13] dt-bindings: memory-controllers: add Exynos5422 DMC device description To: Lukasz Luba Cc: Krzysztof Kozlowski , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" , "open list:THERMAL" , "linux-samsung-soc@vger.kernel.org" , =?UTF-8?B?QmFydMWCb21pZWogxbtvxYJuaWVya2lld2ljeg==?= , Kukjin Kim , Chanwoo Choi , Kyungmin Park , Marek Szyprowski , Sylwester Nawrocki , MyungJoo Ham , Kees Cook , Tony Lindgren , Joerg Roedel , Thierry Reding , Dmitry Osipenko , willy.mh.wolff.ml@gmail.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 8, 2019 at 4:45 AM Lukasz Luba wrote: > > > On 5/8/19 9:19 AM, Krzysztof Kozlowski wrote: > > On Tue, 7 May 2019 at 19:04, Rob Herring wrote: > >>> +- devfreq-events : phandles of the PPMU events used by the controller. > >>> +- samsung,syscon-chipid : phandle of the ChipID used by the controller. > >>> +- samsung,syscon-clk : phandle of the clock register set used by the controller. > >> > >> Looks like a hack. Can't you get this from the clocks property? What is > >> this for? > > > > Hi Rob, > > > > Lukasz uses these two syscon regmaps to read certain registers. For > > chipid he reads it to check the size of attached memory (only 2 GB > > version is supported). This indeed looks like a hack. However the > > second regmap (clk) is needed to get the timing data from registers > > from DMC clock driver address space. These are registers with memory > > timing so their data is not exposed anyway in common clk framework. Okay, please just explain what your accessing. Consider adding the offset as a cell in case stuff moves around on another chip. > > > > Best regards, > > Krzysztof > > Thank you Krzysztof for a fast response. I have also responded to Rob. > I wouldn't call accessing chipid registers as a hack, though. The DMC > registers do not contain information about the memory chip since it is > in phase of production the board not the chip. Thus, chipid regs (which > loads from e-fuses) are best place to put information about memory > type/size. For efuses, we have a binding (nvmem). Maybe you should use it. Rob