All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Andrew Jones <drjones@redhat.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, jeremy.linton@arm.com,
	ard.biesheuvel@linaro.org, shunyong.yang@hxt-semitech.com,
	yu.zheng@hxt-semitech.com, catalin.marinas@arm.com,
	will.deacon@arm.com
Subject: Re: [PATCH] arm64: acpi: reenumerate topology ids
Date: Fri, 29 Jun 2018 11:29:27 +0100	[thread overview]
Message-ID: <20180629102927.GA18043@e107155-lin> (raw)
In-Reply-To: <20180628173243.obydzakh2stfs26w@kamzik.brq.redhat.com>

On Thu, Jun 28, 2018 at 07:32:43PM +0200, Andrew Jones wrote:
> On Thu, Jun 28, 2018 at 05:30:51PM +0100, Sudeep Holla wrote:
> > I am not sure if we can ever guarantee that DT and ACPI will get the
> > same ids whatever counter we use as it depends on the order presented in
> > the firmware(DT or ACPI). So I am not for generating ids for core and
> > threads in that way.
>
> I don't believe we have to guarantee that the exact (package,core,thread)
> triplet describing a PE with DT matches ACPI. We just need to guarantee
> that each triplet we select properly puts a PE in the same group as its
> peers. So, as long as we keep the grouping described by DT or ACPI, then
> the (package,core,thread) IDs assigned are pretty arbitrary.
>

If that's the requirement, we already do that. The IDs are just too
arbitrary :)

> I could change the commit message to state we can generate IDs *like*
> DT does (i.e. with counters), even if they may not result in identical
> triplet to PE mappings.
>

Why we need to make it *like DT* ?

> >
> > So I would like to keep it simple and just have this counters for
> > package ids as demonstrated in Shunyong's patch.
> >
>
> If we don't also handle cores when there are threads, then the cores
> will also end up having weird IDs.
>

Yes, but if PPTT says it has valid ID, I would prefer that over DT like
generated.

--
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] arm64: acpi: reenumerate topology ids
Date: Fri, 29 Jun 2018 11:29:27 +0100	[thread overview]
Message-ID: <20180629102927.GA18043@e107155-lin> (raw)
In-Reply-To: <20180628173243.obydzakh2stfs26w@kamzik.brq.redhat.com>

On Thu, Jun 28, 2018 at 07:32:43PM +0200, Andrew Jones wrote:
> On Thu, Jun 28, 2018 at 05:30:51PM +0100, Sudeep Holla wrote:
> > I am not sure if we can ever guarantee that DT and ACPI will get the
> > same ids whatever counter we use as it depends on the order presented in
> > the firmware(DT or ACPI). So I am not for generating ids for core and
> > threads in that way.
>
> I don't believe we have to guarantee that the exact (package,core,thread)
> triplet describing a PE with DT matches ACPI. We just need to guarantee
> that each triplet we select properly puts a PE in the same group as its
> peers. So, as long as we keep the grouping described by DT or ACPI, then
> the (package,core,thread) IDs assigned are pretty arbitrary.
>

If that's the requirement, we already do that. The IDs are just too
arbitrary :)

> I could change the commit message to state we can generate IDs *like*
> DT does (i.e. with counters), even if they may not result in identical
> triplet to PE mappings.
>

Why we need to make it *like DT* ?

> >
> > So I would like to keep it simple and just have this counters for
> > package ids as demonstrated in Shunyong's patch.
> >
>
> If we don't also handle cores when there are threads, then the cores
> will also end up having weird IDs.
>

Yes, but if PPTT says it has valid ID, I would prefer that over DT like
generated.

--
Regards,
Sudeep

  reply	other threads:[~2018-06-29 10:29 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-28 14:51 [PATCH] arm64: acpi: reenumerate topology ids Andrew Jones
2018-06-28 14:51 ` Andrew Jones
2018-06-28 16:30 ` Sudeep Holla
2018-06-28 16:30   ` Sudeep Holla
2018-06-28 17:12   ` Jeremy Linton
2018-06-28 17:12     ` Jeremy Linton
2018-06-29 10:53     ` Sudeep Holla
2018-06-29 10:53       ` Sudeep Holla
2018-06-29 11:42       ` Andrew Jones
2018-06-29 11:42         ` Andrew Jones
2018-06-29 11:55         ` Andrew Jones
2018-06-29 11:55           ` Andrew Jones
2018-06-29 13:48           ` Sudeep Holla
2018-06-29 13:48             ` Sudeep Holla
2018-06-29 13:38         ` Sudeep Holla
2018-06-29 13:38           ` Sudeep Holla
2018-06-29 16:03           ` Andrew Jones
2018-06-29 16:03             ` Andrew Jones
2018-06-28 17:32   ` Andrew Jones
2018-06-28 17:32     ` Andrew Jones
2018-06-29 10:29     ` Sudeep Holla [this message]
2018-06-29 10:29       ` Sudeep Holla
2018-06-29 11:23       ` Andrew Jones
2018-06-29 11:23         ` Andrew Jones
2018-06-29 13:29         ` Sudeep Holla
2018-06-29 13:29           ` Sudeep Holla
2018-06-29 15:46           ` Andrew Jones
2018-06-29 15:46             ` Andrew Jones
2018-06-29 15:55             ` Sudeep Holla
2018-06-29 15:55               ` Sudeep Holla
2018-06-29 16:48             ` Jeremy Linton
2018-06-29 16:48               ` Jeremy Linton
2018-06-29 17:03               ` Andrew Jones
2018-06-29 17:03                 ` Andrew Jones
2018-06-29 17:23                 ` Sudeep Holla
2018-06-29 17:23                   ` Sudeep Holla
2018-06-29 18:03                   ` Andrew Jones
2018-06-29 18:03                     ` Andrew Jones
2018-07-02 14:58             ` Jeffrey Hugo
2018-07-02 14:58               ` Jeffrey Hugo

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=20180629102927.GA18043@e107155-lin \
    --to=sudeep.holla@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=drjones@redhat.com \
    --cc=jeremy.linton@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shunyong.yang@hxt-semitech.com \
    --cc=will.deacon@arm.com \
    --cc=yu.zheng@hxt-semitech.com \
    /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.