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
next prev parent 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).