All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 1/6] ARM: shmobile: r8a7740 dtsi: Add L2 cache-controller node
Date: Fri, 07 Aug 2015 09:45:22 +0000	[thread overview]
Message-ID: <55C47E32.6070400@arm.com> (raw)
In-Reply-To: <CAMuHMdVAOba0ofmoy8OH2DdY1m3XaD8iOXvXBE035=C4yK58VQ@mail.gmail.com>



On 06/08/15 17:21, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Wed, Aug 5, 2015 at 12:58 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 05/08/15 11:44, Geert Uytterhoeven wrote:
>>> On Wed, Aug 5, 2015 at 11:34 AM, Sudeep Holla <sudeep.holla@arm.com>
>>> wrote:

[..]

>>>>
>>>> Any particular reason whey you need all this cache-* properties ? Is
>>>
>>> To describe the cache as good as possible.
>>
>> Why if you can probe it ? IMO DT is mostly useful to describe things
>> that can't be probed/discovered using hardware.
>>
>>>> something broken on these SoCs ? We should be able to get most of these
>>>> information from the SoC(reading some registers). It's good to avoid
>>>> passing them via DT if they can be discovered from hardware.
>>>
>>> So we have all these documented properties in
>>> Documentation/devicetree/bindings/arm/l2cc.txt, but they're not meant to
>>> be used?
>>
>> No I didn't mean that, I just wanted to know if they can't be probed due
>> to some hardware issue. It would avoid issues with wrong DTs especially
>> if they are not so easy to upgrade.
>
> I think it works just fine without them.
>

Yes, in general if you specify a value in DT that can be probed, its
usually to override the probed value(useful if there is some h/w errata)...

> Should I drop all cache-* properties marked optional in
> Documentation/devicetree/bindings/arm/l2cc.txt?
> That would be cache-size, cache-sets, cache-block-size, and cache-line-size.
>

... however if you incorrect values by mistake, then it's problematic
even if h/w provides correct value.


> What about the L1 cache? I know Linux uses none of the d-cache-*
> and i-cache-* properties.
>

Same there, IIRC PPC use them, but on ARM I think so far the need has
not arise.

Just to re-iterate myself, I am not against adding them, but it's not
really needed. I just wanted to know if there was any h/w issue.

Regards,
Sudeep

WARNING: multiple messages have this Message-ID (diff)
From: sudeep.holla@arm.com (Sudeep Holla)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 1/6] ARM: shmobile: r8a7740 dtsi: Add L2 cache-controller node
Date: Fri, 07 Aug 2015 10:45:22 +0100	[thread overview]
Message-ID: <55C47E32.6070400@arm.com> (raw)
In-Reply-To: <CAMuHMdVAOba0ofmoy8OH2DdY1m3XaD8iOXvXBE035=C4yK58VQ@mail.gmail.com>



On 06/08/15 17:21, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Wed, Aug 5, 2015 at 12:58 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 05/08/15 11:44, Geert Uytterhoeven wrote:
>>> On Wed, Aug 5, 2015 at 11:34 AM, Sudeep Holla <sudeep.holla@arm.com>
>>> wrote:

[..]

>>>>
>>>> Any particular reason whey you need all this cache-* properties ? Is
>>>
>>> To describe the cache as good as possible.
>>
>> Why if you can probe it ? IMO DT is mostly useful to describe things
>> that can't be probed/discovered using hardware.
>>
>>>> something broken on these SoCs ? We should be able to get most of these
>>>> information from the SoC(reading some registers). It's good to avoid
>>>> passing them via DT if they can be discovered from hardware.
>>>
>>> So we have all these documented properties in
>>> Documentation/devicetree/bindings/arm/l2cc.txt, but they're not meant to
>>> be used?
>>
>> No I didn't mean that, I just wanted to know if they can't be probed due
>> to some hardware issue. It would avoid issues with wrong DTs especially
>> if they are not so easy to upgrade.
>
> I think it works just fine without them.
>

Yes, in general if you specify a value in DT that can be probed, its
usually to override the probed value(useful if there is some h/w errata)...

> Should I drop all cache-* properties marked optional in
> Documentation/devicetree/bindings/arm/l2cc.txt?
> That would be cache-size, cache-sets, cache-block-size, and cache-line-size.
>

... however if you incorrect values by mistake, then it's problematic
even if h/w provides correct value.


> What about the L1 cache? I know Linux uses none of the d-cache-*
> and i-cache-* properties.
>

Same there, IIRC PPC use them, but on ARM I think so far the need has
not arise.

Just to re-iterate myself, I am not against adding them, but it's not
really needed. I just wanted to know if there was any h/w issue.

Regards,
Sudeep

WARNING: multiple messages have this Message-ID (diff)
From: Sudeep Holla <sudeep.holla@arm.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Simon Horman <horms@verge.net.au>,
	Magnus Damm <magnus.damm@gmail.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v4 1/6] ARM: shmobile: r8a7740 dtsi: Add L2 cache-controller node
Date: Fri, 07 Aug 2015 10:45:22 +0100	[thread overview]
Message-ID: <55C47E32.6070400@arm.com> (raw)
In-Reply-To: <CAMuHMdVAOba0ofmoy8OH2DdY1m3XaD8iOXvXBE035=C4yK58VQ@mail.gmail.com>



On 06/08/15 17:21, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Wed, Aug 5, 2015 at 12:58 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 05/08/15 11:44, Geert Uytterhoeven wrote:
>>> On Wed, Aug 5, 2015 at 11:34 AM, Sudeep Holla <sudeep.holla@arm.com>
>>> wrote:

[..]

>>>>
>>>> Any particular reason whey you need all this cache-* properties ? Is
>>>
>>> To describe the cache as good as possible.
>>
>> Why if you can probe it ? IMO DT is mostly useful to describe things
>> that can't be probed/discovered using hardware.
>>
>>>> something broken on these SoCs ? We should be able to get most of these
>>>> information from the SoC(reading some registers). It's good to avoid
>>>> passing them via DT if they can be discovered from hardware.
>>>
>>> So we have all these documented properties in
>>> Documentation/devicetree/bindings/arm/l2cc.txt, but they're not meant to
>>> be used?
>>
>> No I didn't mean that, I just wanted to know if they can't be probed due
>> to some hardware issue. It would avoid issues with wrong DTs especially
>> if they are not so easy to upgrade.
>
> I think it works just fine without them.
>

Yes, in general if you specify a value in DT that can be probed, its
usually to override the probed value(useful if there is some h/w errata)...

> Should I drop all cache-* properties marked optional in
> Documentation/devicetree/bindings/arm/l2cc.txt?
> That would be cache-size, cache-sets, cache-block-size, and cache-line-size.
>

... however if you incorrect values by mistake, then it's problematic
even if h/w provides correct value.


> What about the L1 cache? I know Linux uses none of the d-cache-*
> and i-cache-* properties.
>

Same there, IIRC PPC use them, but on ARM I think so far the need has
not arise.

Just to re-iterate myself, I am not against adding them, but it's not
really needed. I just wanted to know if there was any h/w issue.

Regards,
Sudeep

  reply	other threads:[~2015-08-07  9:45 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-05  8:58 [PATCH v4 0/6] ARM: shmobile: r8a7740/sh73a0 DT Cache Handling Geert Uytterhoeven
2015-08-05  8:58 ` Geert Uytterhoeven
2015-08-05  8:58 ` Geert Uytterhoeven
2015-08-05  8:58 ` [PATCH v4 1/6] ARM: shmobile: r8a7740 dtsi: Add L2 cache-controller node Geert Uytterhoeven
2015-08-05  8:58   ` Geert Uytterhoeven
2015-08-05  8:58   ` Geert Uytterhoeven
2015-08-05  9:34   ` Sudeep Holla
2015-08-05  9:34     ` Sudeep Holla
2015-08-05  9:34     ` Sudeep Holla
2015-08-05 10:44     ` Geert Uytterhoeven
2015-08-05 10:44       ` Geert Uytterhoeven
2015-08-05 10:44       ` Geert Uytterhoeven
2015-08-05 10:58       ` Sudeep Holla
2015-08-05 10:58         ` Sudeep Holla
2015-08-05 10:58         ` Sudeep Holla
2015-08-06 16:21         ` Geert Uytterhoeven
2015-08-06 16:21           ` Geert Uytterhoeven
2015-08-06 16:21           ` Geert Uytterhoeven
2015-08-07  9:45           ` Sudeep Holla [this message]
2015-08-07  9:45             ` Sudeep Holla
2015-08-07  9:45             ` Sudeep Holla
2015-11-20 16:14             ` Geert Uytterhoeven
2015-11-20 16:14               ` Geert Uytterhoeven
2015-11-20 16:14               ` Geert Uytterhoeven
2015-11-26 11:59               ` Sudeep Holla
2015-11-26 11:59                 ` Sudeep Holla
2015-11-26 11:59                 ` Sudeep Holla
2015-08-05  8:58 ` [PATCH v4 2/6] ARM: shmobile: r8a7740 dtsi: Add L1 cache information to CPU node Geert Uytterhoeven
2015-08-05  8:58   ` Geert Uytterhoeven
2015-08-05  8:58   ` Geert Uytterhoeven
2015-08-05  8:58 ` [PATCH v4 3/6] ARM: shmobile: sh73a0 dtsi: Add L2 cache-controller node Geert Uytterhoeven
2015-08-05  8:58   ` Geert Uytterhoeven
2015-08-05  8:58   ` Geert Uytterhoeven
2015-08-05  8:58 ` [PATCH v4 4/6] ARM: shmobile: sh73a0 dtsi: Add L1 cache information to CPU nodes Geert Uytterhoeven
2015-08-05  8:58   ` Geert Uytterhoeven
2015-08-05  8:58   ` Geert Uytterhoeven
2015-08-05  8:58 ` [PATCH v4 5/6] ARM: shmobile: r8a7740: Migrate to generic l2c OF initialization Geert Uytterhoeven
2015-08-05  8:58   ` Geert Uytterhoeven
2015-08-05  8:58   ` Geert Uytterhoeven
2015-08-05  8:58 ` [PATCH v4 6/6] ARM: shmobile: r8a7740: Remove mapping of L2 cache controller registers Geert Uytterhoeven
2015-08-05  8:58   ` Geert Uytterhoeven
2015-08-05  8:58   ` Geert Uytterhoeven
2015-08-06  0:35 ` [PATCH v4 0/6] ARM: shmobile: r8a7740/sh73a0 DT Cache Handling Simon Horman
2015-08-06  0:35   ` Simon Horman
2015-08-06  0:35   ` Simon Horman
2015-08-06  7:17   ` Geert Uytterhoeven
2015-08-06  7:17     ` Geert Uytterhoeven
2015-08-06  7:17     ` Geert Uytterhoeven
2015-08-07  0:34     ` Simon Horman
2015-08-07  0:34       ` Simon Horman
2015-08-07  0:34       ` Simon Horman

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=55C47E32.6070400@arm.com \
    --to=sudeep.holla@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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.