All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
To: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Cc: "kgene-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
	<kgene-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Marc Zyngier <Marc.Zyngier-5wv7dgnIgG8@public.gmane.org>,
	"arnd-r2nGTMty4D4@public.gmane.org"
	<arnd-r2nGTMty4D4@public.gmane.org>,
	"olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org"
	<olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>,
	Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>,
	Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
	"inki.dae-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org"
	<inki.dae-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	"chanho61.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org"
	<chanho61.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	"sw0312.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org"
	<sw0312.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	"jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org"
	<jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	"ideal.song-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org"
	<ideal.song-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	"a.kesavan-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org"
	<a.kesavan-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v7 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Date: Tue, 7 Apr 2015 11:25:27 +0100	[thread overview]
Message-ID: <20150407102523.GA23190@leverpostej> (raw)
In-Reply-To: <551DD321.6030707-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

> >>> I'm very worried about adding a DT that's known broken, especially when
> >>> we have no idea as to if/when the FW will be fixed judging from prior
> >>> replies.
> >>
> >> As I replied, I can not fix the FW because I don't have any code of FW.
> > 
> > Surely you are able to contact those who do?
> > 
> >> I don't have any solution to fix it on Linux kernel level.
> >>
> >> So, If you agree, I can add the comment of CPU0 hotplug issue on DT file.
> > 
> > I disagree. I do not want to add a DT that is known to be broken;
> > especially when we have no idea how to fix it. It creates long-term
> > maintenance pain for everyone, and marginal gain for few. A comment does
> > nothing to aid the end-user.
> > 
> > So NAK to the PSCI node and PSCI enable method in this dts until we
> > either have a working firmware, or a reasonable mechanism to handle the
> > deficiency.
> 
> There is only CPU0 hotplug issue. Excpet CPU{1-7} are well working.

I understand that, but the issue with CPU0 is still a blocker from my
PoV.

> To fix this issue, we must need the help of firmware developer.
> But, We never get the any help.

Previously you said that you did not have access to the source code
rather than not having help from the relevant firmware engineers. I take
it you have informed them of the issue with CPU0?

> Also, as I mentioned on previous mail, all Exynos SoCs can not turn
> off the CPU0. I've never seen Exynos SoC that CP0 hotplug is possible.

While that may be the case, PSCI is a more generic standard, and it is
used on systems where CPU0 can be hot unplugged. So Exynos-specific
details cannot dictate how the kernel PSCI driver should behave.

Is there a particular reason that CPU0 cannot be hotplugged?

In PSCI 0.2 and later it's possible to determine whether a trusted OS
prohibits a core from being hotplugged, but this mechanism doesn't exist
in earlier versions. I am not averse to adding a property to PSCI 0.1
to mark a CPU as not being hotpluggable if there is a fundamental reason
(i.e. not simply a bug) for this being the case.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Date: Tue, 7 Apr 2015 11:25:27 +0100	[thread overview]
Message-ID: <20150407102523.GA23190@leverpostej> (raw)
In-Reply-To: <551DD321.6030707@samsung.com>

> >>> I'm very worried about adding a DT that's known broken, especially when
> >>> we have no idea as to if/when the FW will be fixed judging from prior
> >>> replies.
> >>
> >> As I replied, I can not fix the FW because I don't have any code of FW.
> > 
> > Surely you are able to contact those who do?
> > 
> >> I don't have any solution to fix it on Linux kernel level.
> >>
> >> So, If you agree, I can add the comment of CPU0 hotplug issue on DT file.
> > 
> > I disagree. I do not want to add a DT that is known to be broken;
> > especially when we have no idea how to fix it. It creates long-term
> > maintenance pain for everyone, and marginal gain for few. A comment does
> > nothing to aid the end-user.
> > 
> > So NAK to the PSCI node and PSCI enable method in this dts until we
> > either have a working firmware, or a reasonable mechanism to handle the
> > deficiency.
> 
> There is only CPU0 hotplug issue. Excpet CPU{1-7} are well working.

I understand that, but the issue with CPU0 is still a blocker from my
PoV.

> To fix this issue, we must need the help of firmware developer.
> But, We never get the any help.

Previously you said that you did not have access to the source code
rather than not having help from the relevant firmware engineers. I take
it you have informed them of the issue with CPU0?

> Also, as I mentioned on previous mail, all Exynos SoCs can not turn
> off the CPU0. I've never seen Exynos SoC that CP0 hotplug is possible.

While that may be the case, PSCI is a more generic standard, and it is
used on systems where CPU0 can be hot unplugged. So Exynos-specific
details cannot dictate how the kernel PSCI driver should behave.

Is there a particular reason that CPU0 cannot be hotplugged?

In PSCI 0.2 and later it's possible to determine whether a trusted OS
prohibits a core from being hotplugged, but this mechanism doesn't exist
in earlier versions. I am not averse to adding a property to PSCI 0.1
to mark a CPU as not being hotpluggable if there is a fundamental reason
(i.e. not simply a bug) for this being the case.

Thanks,
Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Chanwoo Choi <cw00.choi@samsung.com>
Cc: "kgene@kernel.org" <kgene@kernel.org>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"olof@lixom.net" <olof@lixom.net>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"inki.dae@samsung.com" <inki.dae@samsung.com>,
	"chanho61.park@samsung.com" <chanho61.park@samsung.com>,
	"sw0312.kim@samsung.com" <sw0312.kim@samsung.com>,
	"jh80.chung@samsung.com" <jh80.chung@samsung.com>,
	"ideal.song@samsung.com" <ideal.song@samsung.com>,
	"a.kesavan@samsung.com" <a.kesavan@samsung.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-samsung-soc@vger.kernel.org" 
	<linux-samsung-soc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v7 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Date: Tue, 7 Apr 2015 11:25:27 +0100	[thread overview]
Message-ID: <20150407102523.GA23190@leverpostej> (raw)
In-Reply-To: <551DD321.6030707@samsung.com>

> >>> I'm very worried about adding a DT that's known broken, especially when
> >>> we have no idea as to if/when the FW will be fixed judging from prior
> >>> replies.
> >>
> >> As I replied, I can not fix the FW because I don't have any code of FW.
> > 
> > Surely you are able to contact those who do?
> > 
> >> I don't have any solution to fix it on Linux kernel level.
> >>
> >> So, If you agree, I can add the comment of CPU0 hotplug issue on DT file.
> > 
> > I disagree. I do not want to add a DT that is known to be broken;
> > especially when we have no idea how to fix it. It creates long-term
> > maintenance pain for everyone, and marginal gain for few. A comment does
> > nothing to aid the end-user.
> > 
> > So NAK to the PSCI node and PSCI enable method in this dts until we
> > either have a working firmware, or a reasonable mechanism to handle the
> > deficiency.
> 
> There is only CPU0 hotplug issue. Excpet CPU{1-7} are well working.

I understand that, but the issue with CPU0 is still a blocker from my
PoV.

> To fix this issue, we must need the help of firmware developer.
> But, We never get the any help.

Previously you said that you did not have access to the source code
rather than not having help from the relevant firmware engineers. I take
it you have informed them of the issue with CPU0?

> Also, as I mentioned on previous mail, all Exynos SoCs can not turn
> off the CPU0. I've never seen Exynos SoC that CP0 hotplug is possible.

While that may be the case, PSCI is a more generic standard, and it is
used on systems where CPU0 can be hot unplugged. So Exynos-specific
details cannot dictate how the kernel PSCI driver should behave.

Is there a particular reason that CPU0 cannot be hotplugged?

In PSCI 0.2 and later it's possible to determine whether a trusted OS
prohibits a core from being hotplugged, but this mechanism doesn't exist
in earlier versions. I am not averse to adding a property to PSCI 0.1
to mark a CPU as not being hotpluggable if there is a fundamental reason
(i.e. not simply a bug) for this being the case.

Thanks,
Mark.

  parent reply	other threads:[~2015-04-07 10:25 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-18  0:17 [PATCH v7 0/9] arm64: Add the support for new Exynos5433 SoC Chanwoo Choi
2015-03-18  0:17 ` Chanwoo Choi
2015-03-18  0:17 ` [PATCH v7 1/9] arm64: dts: exynos: Add dts files for 64-bit " Chanwoo Choi
2015-03-18  0:17   ` Chanwoo Choi
2015-03-30 16:09   ` Mark Rutland
2015-03-30 16:09     ` Mark Rutland
2015-03-30 23:56     ` Chanwoo Choi
2015-03-30 23:56       ` Chanwoo Choi
2015-04-02 17:35       ` Mark Rutland
2015-04-02 17:35         ` Mark Rutland
2015-04-02 23:39         ` Chanwoo Choi
2015-04-02 23:39           ` Chanwoo Choi
     [not found]           ` <551DD321.6030707-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-04-07 10:25             ` Mark Rutland [this message]
2015-04-07 10:25               ` Mark Rutland
2015-04-07 10:25               ` Mark Rutland
2015-04-13 10:56               ` Mark Rutland
2015-04-13 10:56                 ` Mark Rutland
2015-04-13 12:06                 ` Chanwoo Choi
2015-04-13 12:06                   ` Chanwoo Choi
2015-04-13 15:49                   ` Mark Rutland
2015-04-13 15:49                     ` Mark Rutland
2015-04-14  7:53                     ` Chanwoo Choi
2015-04-14  7:53                       ` Chanwoo Choi
2015-03-18  0:17 ` [PATCH v7 2/9] arm64: dts: exynos: Add MSHC dt node for Exynos5433 Chanwoo Choi
2015-03-18  0:17   ` Chanwoo Choi
2015-03-18  0:17 ` [PATCH v7 3/9] arm64: dts: exynos: Add SPI/PDMA " Chanwoo Choi
2015-03-18  0:17   ` Chanwoo Choi
2015-03-18  0:17   ` Chanwoo Choi
     [not found] ` <1426637856-3730-1-git-send-email-cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-03-18  0:17   ` [PATCH v7 4/9] arm64: dts: exynos: Add PMU " Chanwoo Choi
2015-03-18  0:17     ` Chanwoo Choi
2015-03-18  0:17     ` Chanwoo Choi
2015-03-18  0:17 ` [PATCH v7 5/9] arm64: dts: exynos: Add RTC and ADC dt node for Exynos5433 SoC Chanwoo Choi
2015-03-18  0:17   ` Chanwoo Choi
2015-03-18  0:17 ` [PATCH v7 6/9] arm64: dts: exynos: Add ADMA " Chanwoo Choi
2015-03-18  0:17   ` Chanwoo Choi
2015-03-18  0:17 ` [PATCH v7 7/9] arm64: dts: exynos: Add I2S " Chanwoo Choi
2015-03-18  0:17   ` Chanwoo Choi
2015-03-18  0:17 ` [PATCH v7 8/9] arm64: dts: exynos: Add TMU sensor " Chanwoo Choi
2015-03-18  0:17   ` Chanwoo Choi
2015-03-18  0:17 ` [PATCH v7 9/9] arm64: dts: exynos: Add thermal-zones " Chanwoo Choi
2015-03-18  0:17   ` Chanwoo Choi
2015-03-19 20:52 ` [PATCH v7 0/9] arm64: Add the support for new " Chanwoo Choi
2015-03-19 20:52   ` Chanwoo Choi
2015-03-24  8:09   ` Kukjin Kim
2015-03-24  8:09     ` Kukjin Kim
2015-03-24 23:30     ` Chanwoo Choi
2015-03-24 23:30       ` Chanwoo Choi

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=20150407102523.GA23190@leverpostej \
    --to=mark.rutland-5wv7dgnigg8@public.gmane.org \
    --cc=Catalin.Marinas-5wv7dgnIgG8@public.gmane.org \
    --cc=Marc.Zyngier-5wv7dgnIgG8@public.gmane.org \
    --cc=Will.Deacon-5wv7dgnIgG8@public.gmane.org \
    --cc=a.kesavan-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=chanho61.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=ideal.song-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=inki.dae-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=kgene-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org \
    --cc=sw0312.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.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.