linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Channa <ckadabi@codeaurora.org>
To: Matt Sealey <neko@bakuhatsu.net>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, linux-arm@lists.infradead.org,
	linux-kernel@vger.kernel.org, tsoni@codeaurora.org,
	Stephen Boyd <sboyd@codeaurora.org>,
	kyan@codeaurora.org, linux-kernel-owner@vger.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: Documentation for qcom,llcc
Date: Thu, 08 Feb 2018 16:24:16 -0800	[thread overview]
Message-ID: <0ce690ab886d4896506ba916d2d39554@codeaurora.org> (raw)
In-Reply-To: <CAHCPf3vt-ZCXgTfCZ-LSW3TSXAk5KBz3wCu-LuTOBdCB+sgGgw@mail.gmail.com>

On 2018-02-08 08:52, Matt Sealey wrote:
> Hiya,
> 
> On 25 January 2018 at 17:55, Channagoud Kadabi <ckadabi@codeaurora.org> 
> wrote:
>> Documentation for last level cache controller device tree bindings,
>> client bindings usage examples.
> 
> [snippety snip]
> 
>> +- llcc-bank-off:
>> +       Usage: required
>> +       Value Type: <u32 array>
>> +       Definition: Offsets of llcc banks from llcc base address 
>> starting from
>> +                   LLCC bank0.
>> +
>> +- llcc-broadcast-off:
>> +       Usage: required
>> +       Value Type: <u32>
>> +       Definition: Offset of broadcast register from LLCC bank0 
>> address.
> 
> What's with the redundant namespacing?
> 
> Have we not, as a community, realised that we do not need to namespace
> properties which are only present under
> a single binding or node, or even those that aren't? This mess started
> with the regulator bindings and it's never
> stopped. What are we at now, 25 years of device trees, 10 years of FDT 
> on Arm?
> 
> Notwithstanding the complete waste of rodata in the kernel image for
> matching (& increased time to compare), why
> wouldn't you consider why "bank-offset" for your node be any different
> than a common property for any other node?

I will clean up the name space and use bank-offset for the property 
name.

> 
> And if you need to describe register offsets... why aren't you able to
> use the reg property?

Reg property did not suit well for my need, so I choose to maintain 
offsets instead.

The registers in the HW block are organized as
                 (offset1)    (offset2)     (offset3)     (offset4)
Base(Block0) -- Block1 -- Block 2 -- Block 3 -- Broadcast_Block

Each block has identical register mapping. You can think of it as 4 
instances of identical HW.
Broadcast block is to simplify writes, you don't need to write to 
individual blocks instead write to broadcast block.

I use simple-mfd/syscon as the hardware has multiple functions.
Doing regmap on the the Base (Block0) and maintaining offset makes the 
driver cleaner rather than using the reg property for
each instance.

> 
> Ta,
> Matt

-- 
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,
a Linux Foundation Collaborative Project

  reply	other threads:[~2018-02-09  0:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-25 23:55 [PATCH 0/2] SDM845 System Cache Driver Channagoud Kadabi
2018-01-25 23:55 ` [PATCH 1/2] dt-bindings: Documentation for qcom,llcc Channagoud Kadabi
2018-02-01 10:44   ` Mark Rutland
2018-02-01 20:39     ` Channa
2018-02-02 11:05       ` Mark Rutland
2018-02-06 19:56         ` Channa
2018-02-13 14:37           ` Mark Rutland
2018-02-13 17:38             ` Channa
2018-02-01 10:48   ` Mark Rutland
2018-02-01 20:47     ` Channa
2018-02-02 11:08       ` Mark Rutland
2018-02-08 16:52   ` Matt Sealey
2018-02-09  0:24     ` Channa [this message]
2018-02-13 14:33       ` Mark Rutland
2018-01-25 23:55 ` [PATCH 2/2] drivers: soc: Add LLCC driver Channagoud Kadabi
2018-03-19 14:55   ` Jordan Crouse
2018-03-23 23:57     ` Channa
  -- strict thread matches above, loose matches on Subject: below --
2018-01-16 22:35 [PATCH 0/2] SDM845 System Cache Driver Channagoud Kadabi
2018-01-16 22:35 ` [PATCH 1/2] dt-bindings: Documentation for qcom,llcc Channagoud Kadabi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0ce690ab886d4896506ba916d2d39554@codeaurora.org \
    --to=ckadabi@codeaurora.org \
    --cc=kyan@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-arm@lists.infradead.org \
    --cc=linux-kernel-owner@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neko@bakuhatsu.net \
    --cc=sboyd@codeaurora.org \
    --cc=tsoni@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).