All of lore.kernel.org
 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

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

  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.