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
WARNING: multiple messages have this Message-ID (diff)
From: ckadabi@codeaurora.org (Channa)
To: linux-arm-kernel@lists.infradead.org
Subject: [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: 37+ 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 ` Channagoud Kadabi
2018-01-25 23:55 ` [PATCH 1/2] dt-bindings: Documentation for qcom,llcc Channagoud Kadabi
2018-01-25 23:55 ` Channagoud Kadabi
2018-02-01 10:44 ` Mark Rutland
2018-02-01 10:44 ` Mark Rutland
2018-02-01 20:39 ` Channa
2018-02-01 20:39 ` Channa
2018-02-02 11:05 ` Mark Rutland
2018-02-02 11:05 ` Mark Rutland
2018-02-06 19:56 ` Channa
2018-02-06 19:56 ` Channa
2018-02-06 19:56 ` Channa
2018-02-13 14:37 ` Mark Rutland
2018-02-13 14:37 ` Mark Rutland
2018-02-13 17:38 ` Channa
2018-02-13 17:38 ` Channa
2018-02-01 10:48 ` Mark Rutland
2018-02-01 10:48 ` Mark Rutland
2018-02-01 20:47 ` Channa
2018-02-01 20:47 ` Channa
2018-02-01 20:47 ` Channa
2018-02-02 11:08 ` Mark Rutland
2018-02-02 11:08 ` Mark Rutland
2018-02-08 16:52 ` Matt Sealey
2018-02-08 16:52 ` Matt Sealey
2018-02-09 0:24 ` Channa [this message]
2018-02-09 0:24 ` Channa
2018-02-13 14:33 ` Mark Rutland
2018-02-13 14:33 ` Mark Rutland
2018-01-25 23:55 ` [PATCH 2/2] drivers: soc: Add LLCC driver Channagoud Kadabi
2018-01-25 23:55 ` Channagoud Kadabi
2018-03-19 14:55 ` Jordan Crouse
2018-03-19 14:55 ` Jordan Crouse
2018-03-23 23:57 ` Channa
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.