* [PATCH v2] arm64: topology: Avoid checking numa mask for scheduler MC selection
From: Catalin Marinas @ 2018-06-06 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606163846.495725-1-jeremy.linton@arm.com>
On Wed, Jun 06, 2018 at 11:38:46AM -0500, Jeremy Linton wrote:
> The numa mask subset check can often lead to system hang or crash during
> CPU hotplug and system suspend operation if NUMA is disabled. This is
> mostly observed on HMP systems where the CPU compute capacities are
> different and ends up in different scheduler domains. Since
> cpumask_of_node is returned instead core_sibling, the scheduler is
> confused with incorrect cpumasks(e.g. one CPU in two different sched
> domains at the same time) on CPU hotplug.
>
> Lets disable the NUMA siblings checks for the time being, as NUMA in
> socket machines have LLC's that will assure that the scheduler topology
> isn't "borken".
>
> The NUMA check exists to assure that if a LLC within a socket crosses
> NUMA nodes/chiplets the scheduler domains remain consistent. This code will
> likely have to be re-enabled in the near future once the NUMA mask story
> is sorted. At the moment its not necessary because the NUMA in socket
> machines LLC's are contained within the NUMA domains.
>
> Further, as a defensive mechanism during hot-plug, lets assure that the
> LLC siblings are also masked.
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Thanks for this. I queued it for this merging window.
--
Catalin
^ permalink raw reply
* [GIT PULL] Mailbox changes for v4.18
From: Jassi Brar @ 2018-06-06 17:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
The following changes since commit 7fbb6157630f2ba6ee355689061f9596b84373ef:
Merge tag 'armsoc-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2018-05-26
14:05:16 -0700)
are available in the Git repository at:
git://git.linaro.org/landing-teams/working/fujitsu/integration.git
tags/mailbox-v4.18
for you to fetch changes up to f83d1cfc8bcddf93bb6f55940fd59f5b047863e5:
mailbox/drivers/hisi: Consolidate the Kconfig for the MAILBOX
(2018-06-06 22:21:59 +0530)
----------------------------------------------------------------
- Remove HAS_DMA config dependencies
- New STMicroelectronics STM32 IPCC driver
- Enable QCom driver to run more controllers
- Fixed return code from null to ptr-err for Brcm driver
- Fix kconfig dependencies for the HiSilicon driver
----------------------------------------------------------------
Bjorn Andersson (1):
mailbox: qcom: Add msm8998 hmss compatible
Daniel Lezcano (1):
mailbox/drivers/hisi: Consolidate the Kconfig for the MAILBOX
Fabien Dessenne (2):
dt-bindings: mailbox: add STMicroelectronics STM32 IPCC binding
mailbox: add STMicroelectronics STM32 IPCC driver
Geert Uytterhoeven (1):
mailbox: Remove depends on HAS_DMA in case of platform dependency
Sibi Sankar (2):
dt-bindings: mailbox: Add APSS shared binding for SDM845 SoCs
mailbox: Add support for Qualcomm SDM845 SoCs
Stefan Wahren (1):
mailbox: bcm2835: Fix of_xlate return value
.../bindings/mailbox/qcom,apcs-kpss-global.txt | 2 +
.../devicetree/bindings/mailbox/stm32-ipcc.txt | 47 +++
drivers/mailbox/Kconfig | 22 +-
drivers/mailbox/Makefile | 2 +
drivers/mailbox/bcm2835-mailbox.c | 2 +-
drivers/mailbox/qcom-apcs-ipc-mailbox.c | 2 +
drivers/mailbox/stm32-ipcc.c | 402 +++++++++++++++++++++
7 files changed, 472 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mailbox/stm32-ipcc.txt
create mode 100644 drivers/mailbox/stm32-ipcc.c
^ permalink raw reply
* [PATCH] ARM: dts: cygnus: Add HWRNG node
From: Scott Branden @ 2018-06-06 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJiuCcdfmrdHf10JkVOGQXD77JN=_FUv2ysEGTzyvwON31HX_A@mail.gmail.com>
On 18-06-06 10:06 AM, Cl?ment P?ron wrote:
> Hi Scott, Florian,
>
> On Wed, 6 Jun 2018 at 18:47, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> On 06/06/201 8 09:03 AM, Scott Branden wrote:
>>> Hi Clement,
>>>
>>>
>>> On 18-06-06 02:34 AM, Cl?ment P?ron wrote:
>>>> From: Cl?ment Peron <clement.peron@devialet.com>
>>>>
>>>> There is a HWRNG in Broadcom Cygnus SoC, so enable it.
>>>>
>>>> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
>>> Thanks for upstreaming some missing Cygnus components.
>>>
>>> But, the problem is the tarball release from Broadcom you are extracting
>>> these changes from does not contain git history; so, you are missing the
>>> original authors and signed-off's.
>>> I checked our internal git repository and for this commit the author is:
>>> Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
>>>
>>> Please adjust author and signed-off appropriately. If there are other
>>> changes you are extracting from the source tarballs you have please
>>> contact me so we can construct patch appropriately.
>> If you want the original author's Signed-off-by to be preserved, why
>> don't you extract it from your internal git tree and submit the patch on
>> Mohamed's behalf?
>>
>> AFAICT what Clement is doing here is permissible given the Linux
>> developer certificate of origin though I am not a lawyer of course.
>> --
>> Florian
> Totally not my goal to steal the author and agree to keep track of the
> original author
> as soon as it's possible. I didn't though it was important for this
> patch as the same
> code is available in the dt-bindings documentation.
>
> Actually there are still some buggy components like DSA (Arun proposed
> a patch this morning)
> the PWM (config and delay aren't correct) and I2C. These are mainlined
> but can't be used
> and need a minimal effort to correctly work on Cygnus.
We have internal versions of most everything.? It's a matter of getting
people to push the appropriate patches out for upstream version to work.
Please contact the bcm-kernel-feedback list with issues and we can work
through common solution (or, likely already have a solution just not
upstreamed).
>
> Also there are some important components like USB Phy or Mailbox that
> were proposed and
> almost made it, but just need a small modification to be accepted.
Again - we may have internal solution already.? Yes, mailbox was
submitted upstream a long time ago and I think got stalled being
accepted upstream.? We can work through upstream solution by starting
with sending to bcm-kernel-feedback-list to discuss details.
>
> My idea was just to submit small patches that are trivial to review.
> In order to avoid keeping
> lots of patches in our kernel and also have something functional when
> building a mainline kernel.
I understand the difficulty you would have if you're trying to work with
a different kernel version in our release.? If you send me a list
directly of the drivers you use in Cygnus that will help me get those
changes prioritized to be pushed upstream.? And/or we can work together
on that.
>
> Regards,
> Clement
Thanks,
?Scott
^ permalink raw reply
* [PATCH] ARM: dts: cygnus: Add HWRNG node
From: Florian Fainelli @ 2018-06-06 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <676106a4-d763-725c-2342-f8d215fbd169@broadcom.com>
On 06/06/2018 10:14 AM, Scott Branden wrote:
>
>
> On 18-06-06 09:47 AM, Florian Fainelli wrote:
>> On 06/06/2018 09:03 AM, Scott Branden wrote:
>>> Hi Clement,
>>>
>>>
>>> On 18-06-06 02:34 AM, Cl?ment P?ron wrote:
>>>> From: Cl?ment Peron <clement.peron@devialet.com>
>>>>
>>>> There is a HWRNG in Broadcom Cygnus SoC, so enable it.
>>>>
>>>> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
>>> Thanks for upstreaming some missing Cygnus components.
>>>
>>> But, the problem is the tarball release from Broadcom you are extracting
>>> these changes from does not contain git history; so, you are missing the
>>> original authors and signed-off's.
>>> I checked our internal git repository and for this commit the author is:
>>> Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
>>>
>>> Please adjust author and signed-off appropriately.? If there are other
>>> changes you are extracting from the source tarballs you have please
>>> contact me so we can construct patch appropriately.
>> If you want the original author's Signed-off-by to be preserved, why
>> don't you extract it from your internal git tree and submit the patch on
>> Mohamed's behalf?
> Sure, I can submit the original patch to keep things simple and avoid
> finding a lawyer right now.
>>
>> AFAICT what Clement is doing here is permissible given the Linux
>> developer certificate of origin though I am not a lawyer of course.
> But, It would be great to get some guidance and clarification on this
> for sure.
> I'm reading:
> https://www.kernel.org/doc/html/v4.16/process/submitting-patches.html
>
> The change was created entirely by Broadcom, so seems difficult for
> somebody else to upstream change without appropriate authorship and
> signed off from copyright holder.
Indeed, but it is effectively Broadcom's fault for not providing a git
tree for the customer to pull from in order to preserve the original
authorship, if what was distributed is a tarball of changes against a
vanilla kernel (which is likely to be the case), then all author
attributions are lost.
Not suggesting you change how you deliver code to customers, we have the
same issue in the STB/CM group, except maybe customers care less about
upstreaming so we can do it ourselves at our own pace and using our own
attributions.
> Point a) and b) are not met in
> Developer's Certificate of Origin while point c) is being attempted
> (without a or b being certified).
I would think that point a) and b) are met by the very fact that the
Cygnus kernel port is GPLv2 code, being a derivative work of the Linux
kernel, and that should be enough.
This is kind of well established things, this has happened for many
Broadcom product lines unfortunately because not everyone is active like
you in getting things upstreamed. Those contributions were still
entirely valid and acceptable for the kernel community.
Maybe we do need a lawyer, Saul Goodman, are you here?
--
Florian
^ permalink raw reply
* [PATCH v2 5/5] arm64: perf: Add support for chaining event counters
From: Mark Rutland @ 2018-06-06 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527591356-10934-6-git-send-email-suzuki.poulose@arm.com>
On Tue, May 29, 2018 at 11:55:56AM +0100, Suzuki K Poulose wrote:
> Add support for 64bit event by using chained event counters
> and 64bit cycle counters.
>
> Arm v8 PMUv3 allows chaining a pair of adjacent PMU counters
> (with the lower counter number being always "even"). The low
> counter is programmed to count the event of interest and the
> high counter(odd numbered) is programmed with a special event
> code (0x1e - Chain).
I found this a little difficult to read. How about:
PMUv3 allows chaining a pair of adjacent 32-bit counters, effectively
forming a 64-bit counter. The low/even counter is programmed to count
the event of interest, and the high/odd counter is programmed to count
the CHAIN event, taken when the low/even counter overflows.
> Thus we need special allocation schemes
> to make the full use of available counters. So, we allocate the
> counters from either ends. i.e, chained counters are allocated
> from the lower end in pairs of two and the normal counters are
> allocated from the higher number. Also makes necessary changes to
> handle the chained events as a single event with 2 counters.
Why do we need to allocate in this way?
I can see this might make allocating a pair of counters more likely in
some cases, but there are still others where it wouldn't be possible
(and we'd rely on the rotation logic to repack the counters for us).
[...]
> +static inline u32 armv8pmu_read_evcntr(int idx)
> +{
> + return (armv8pmu_select_counter(idx) == idx) ?
> + read_sysreg(pmxevcntr_el0) : 0;
> +}
Given armv8pmu_select_counter() always returns the idx passed to it, I
don't think we need to check anything here. We can clean that up to be
void, and remove the existing checks.
[...]
> +static inline u64 armv8pmu_read_chain_counter(int idx)
> +{
> + u64 prev_hi, hi, lo;
> +
> + hi = armv8pmu_read_evcntr(idx);
> + do {
> + prev_hi = hi;
> + isb();
> + lo = armv8pmu_read_evcntr(idx - 1);
> + isb();
> + hi = armv8pmu_read_evcntr(idx);
> + } while (prev_hi != hi);
> +
> + return (hi << 32) | lo;
> +}
> +static inline void armv8pmu_write_chain_counter(int idx, u64 value)
> +{
> + armv8pmu_write_evcntr(idx, value >> 32);
> + isb();
> + armv8pmu_write_evcntr(idx - 1, value);
> +}
Can we use upper_32_bits() and lower_32_bits() here?
As a more general thing, I think we need to clean up the way we
read/write counters, because I don't think that it's right that we poke
them while they're running -- that means you get some arbitrary skew on
counter groups.
It looks like the only case we do that is the IRQ handler, so we should
be able to stop/start the PMU there.
With that, we can get rid of the ISB here, and likewise in
read_chain_counter, which wouldn't need to be a loop.
> +
> +static inline void armv8pmu_write_hw_counter(struct perf_event *event,
> + u64 value)
> +{
> + int idx = event->hw.idx;
> +
> + if (armv8pmu_event_is_chained(event))
> + armv8pmu_write_chain_counter(idx, value);
> + else
> + armv8pmu_write_evcntr(idx, value);
> +}
> +
> static inline void armv8pmu_write_counter(struct perf_event *event, u64 value)
> {
> struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
> @@ -541,14 +612,14 @@ static inline void armv8pmu_write_counter(struct perf_event *event, u64 value)
> smp_processor_id(), idx);
> else if (idx == ARMV8_IDX_CYCLE_COUNTER) {
> /*
> - * Set the upper 32bits as this is a 64bit counter but we only
> - * count using the lower 32bits and we want an interrupt when
> - * it overflows.
> + * Set the upper 32bits if we are counting this in
> + * 32bit mode, as this is a 64bit counter.
> */
It would be good to keep the explaination as to why.
> - value |= 0xffffffff00000000ULL;
> + if (!armv8pmu_event_is_64bit(event))
> + value |= 0xffffffff00000000ULL;
> write_sysreg(value, pmccntr_el0);
> - } else if (armv8pmu_select_counter(idx) == idx)
> - write_sysreg(value, pmxevcntr_el0);
> + } else
> + armv8pmu_write_hw_counter(event, value);
> }
> +static inline void armv8pmu_write_event_type(struct perf_event *event)
> +{
> + struct hw_perf_event *hwc = &event->hw;
> + int idx = hwc->idx;
> +
> + /*
> + * For chained events, write the the low counter event type
> + * followed by the high counter. The high counter is programmed
> + * with CHAIN event code with filters set to count at all ELs.
> + */
> + if (armv8pmu_event_is_chained(event)) {
> + u32 chain_evt = ARMV8_PMUV3_PERFCTR_CHAIN |
> + ARMV8_PMU_INCLUDE_EL2;
> +
> + armv8pmu_write_evtype(idx - 1, hwc->config_base);
> + isb();
> + armv8pmu_write_evtype(idx, chain_evt);
The ISB isn't necessary here, AFAICT. We only do this while the PMU is
disabled; no?
> + } else
> + armv8pmu_write_evtype(idx, hwc->config_base);
> +}
[...]
> +static inline void armv8pmu_enable_event_counter(struct perf_event *event)
> +{
> + int idx = event->hw.idx;
> +
> + /*
> + * For chained events, we enable the high counter followed by
> + * the low counter.
> + */
> + armv8pmu_enable_counter(idx);
> + if (armv8pmu_event_is_chained(event)) {
> + isb();
> + armv8pmu_enable_counter(idx - 1);
> + }
> +}
If we fix up the IRQ handler, this would only happen with the PMU as a
whole disabled, and we wouldn't care about ordering of enable/disable of
each event.
[...]
> +static inline void armv8pmu_disable_event_counter(struct perf_event *event)
> +{
> + struct hw_perf_event *hwc = &event->hw;
> + int idx = hwc->idx;
> +
> + /*
> + * Disable the low counter followed by the high counter
> + * for chained events.
> + */
> + if (armv8pmu_event_is_chained(event)) {
> + armv8pmu_disable_counter(idx - 1);
> + isb();
> + }
> +
> + armv8pmu_disable_counter(idx);
> +}
... likewise.
> @@ -679,6 +679,12 @@ static void cpu_pm_pmu_setup(struct arm_pmu *armpmu, unsigned long cmd)
> continue;
>
> event = hw_events->events[idx];
> + /*
> + * If there is no event at this idx (e.g, an idx used
> + * by a chained event in Arm v8 PMUv3), skip it.
> + */
> + if (!event)
> + continue;
We may as well lose the used_mask test if we're looking at the event
regardless.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v4 1/7] interconnect: Add generic on-chip interconnect API
From: Georgi Djakov @ 2018-06-06 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <43fedb5b-f4a5-8362-d0a2-534b85473bc1@linaro.org>
Hi Evan,
On 06/06/2018 05:59 PM, Georgi Djakov wrote:
>>> +
>>> +/**
>>> + * icc_node_create() - create a node
>>> + * @id: node id
>>> + *
>>> + * Return: icc_node pointer on success, or ERR_PTR() on error
>>> + */
>>> +struct icc_node *icc_node_create(int id)
>>> +{
>>> + struct icc_node *node;
>>> +
>>> + /* check if node already exists */
>>> + node = node_find(id);
>>> + if (node)
>>> + return node;
>>
>> This is probably going to do more harm than good once icc_node_delete comes
>> in, since it almost certainly indicates a programmer error or ID collision,
>> and will likely result in a double free. We should probably fail with
>> EEXIST instead.
>
> In the current approach we create the nodes one by one, and the linked
> nodes are created when they are referenced. The other way around would
> be to create first all the nodes and then populate the links to avoid
> the "chicken and egg" problem.
>
Just to elaborate a bit more on that: We can't actually register all the
nodes in advance, as we might have multiple interconnect providers
probing in different order. Each provider may have nodes linking to
nodes belonging to other providers (not probed yet). That's why we
create the nodes on the first reference and then, when the actual
provider driver is probed, the rest of the node data is filled.
Thanks,
Georgi
^ permalink raw reply
* [PATCH v2 1/1] ARM: dts: cygnus: enable iproc-hwrng
From: Scott Branden @ 2018-06-06 18:21 UTC (permalink / raw)
To: linux-arm-kernel
From: Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
Enable the HW rng driver "iproc-rng200" for all cygnus platforms.
Signed-off-by: Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 9fe4f5a..b0e38fa 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -417,6 +417,11 @@
status = "disabled";
};
+ rng: rng at 18032000 {
+ compatible = "brcm,iproc-rng200";
+ reg = <0x18032000 0x28>;
+ };
+
sdhci0: sdhci at 18041000 {
compatible = "brcm,sdhci-iproc-cygnus";
reg = <0x18041000 0x100>;
--
2.5.0
^ permalink raw reply related
* [PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations
From: Steven Rostedt @ 2018-06-06 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606142600.GN13775@localhost>
On Wed, 6 Jun 2018 16:26:00 +0200
Johan Hovold <johan@kernel.org> wrote:
> Looks like the greybus code above is working as intended by checking for
> unterminated string after the strncpy, even if this does now triggers
> the truncation warning.
Ah, yes I now see that. Thanks for pointing it out. But perhaps it
should also add the "- 1" to the strncpy() so that gcc doesn't think
it's a mistake.
-- Steve
^ permalink raw reply
* [PATCH] coresight: Fix check in coresight_tmc_etr_buf_insert_barrier_packet
From: Mathieu Poirier @ 2018-06-06 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527851302-5843-1-git-send-email-suzuki.poulose@arm.com>
On 1 June 2018 at 05:08, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> We request for "CORESIGHT_BARRIER_PKT_SIZE" length and we should
> be happy when we get that size.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
>
> Mathieu,
>
> Please could you pull this patch, if you are happy with it ?
> This fixes a problem in the ETR buf series, which I just
> noticed while testing the part2 of the series.
I will pick up the change - you will see it being queued when the
first rc comes out.
>
> Suzuki
> ---
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index e2bcef3..c736250 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -862,7 +862,7 @@ tmc_etr_buf_insert_barrier_packet(struct etr_buf *etr_buf, u64 offset)
>
> len = tmc_etr_buf_get_data(etr_buf, offset,
> CORESIGHT_BARRIER_PKT_SIZE, &bufp);
> - if (WARN_ON(len <= CORESIGHT_BARRIER_PKT_SIZE))
> + if (WARN_ON(len < CORESIGHT_BARRIER_PKT_SIZE))
> return -EINVAL;
> coresight_insert_barrier_packet(bufp);
> return offset + CORESIGHT_BARRIER_PKT_SIZE;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v4 0/6] Enhance support for the SP805 WDT
From: Florian Fainelli @ 2018-06-06 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527530497-10392-1-git-send-email-ray.jui@broadcom.com>
On 05/28/2018 11:01 AM, Ray Jui wrote:
> This patch series enhances the support for the SP805 watchdog timer.
> First of all, 'timeout-sec' devicetree property is added. In addition,
> support is also added to allow the driver to reset the watchdog if it
> has been detected that watchdot has been started in the bootloader. In
> this case, the driver will initiate the ping service from the kernel
> watchdog subsystem, before a user mode daemon takes over. This series
> also enables SP805 in the default ARM64 defconfig
>
> This patch series is based off v4.17-rc5 and is available on GIHUB:
> repo: https://github.com/Broadcom/arm64-linux.git
> branch: sp805-wdt-v4
>
> Changes since v3:
> - Improve description of 'timeout-sec' in the binding document, per
> recommendation from Guenter Roeck
>
> Changes since v2:
> - Fix indent and format to make them consistent within arm,sp805.txt
>
> Changes since v1:
> - Consolidate two duplicated SP805 binding documents into one
> - Slight change of the wdt_is_running implementation per discussion
>
> Ray Jui (6):
> Documentation: DT: Consolidate SP805 binding docs
> Documentation: DT: Add optional 'timeout-sec' property for sp805
> watchdog: sp805: add 'timeout-sec' DT property support
> watchdog: sp805: set WDOG_HW_RUNNING when appropriate
> arm64: dt: set initial SR watchdog timeout to 60 seconds
> arm64: defconfig: add CONFIG_ARM_SP805_WATCHDOG
I can take the last two patches and Guenter would take the first 4 or
would you want to proceed differently?
--
Florian
^ permalink raw reply
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Frank Rowand @ 2018-06-06 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <OSBPR01MB2054E3A1E383495F3534B551D2650@OSBPR01MB2054.jpnprd01.prod.outlook.com>
Hi Michel,
On 06/05/18 23:36, Michel Pollet wrote:
> Hi Frank,
>
> On 05 June 2018 18:34, Frank wrote:
>> On 06/05/18 04:28, Michel Pollet wrote:
>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>> it requires a special enable method to get it started.
>>>
>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>>> ---
>>> arch/arm/mach-shmobile/Makefile | 1 +
>>> arch/arm/mach-shmobile/smp-r9a06g032.c | 79
>>> ++++++++++++++++++++++++++++++++++
>>> 2 files changed, 80 insertions(+)
>>> create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
>>>
>>> diff --git a/arch/arm/mach-shmobile/Makefile
>>> b/arch/arm/mach-shmobile/Makefile index 1939f52..d7fc98f 100644
>>> --- a/arch/arm/mach-shmobile/Makefile
>>> +++ b/arch/arm/mach-shmobile/Makefile
>>> @@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0)+= smp-sh73a0.o
>> headsmp-scu.o platsmp-scu.o
>>> smp-$(CONFIG_ARCH_R8A7779)+= smp-r8a7779.o headsmp-scu.o
>> platsmp-scu.o
>>> smp-$(CONFIG_ARCH_R8A7790)+= smp-r8a7790.o
>>> smp-$(CONFIG_ARCH_R8A7791)+= smp-r8a7791.o
>>> +smp-$(CONFIG_ARCH_R9A06G032)+= smp-r9a06g032.o
>>> smp-$(CONFIG_ARCH_EMEV2)+= smp-emev2.o headsmp-scu.o
>> platsmp-scu.o
>>>
>>> # PM objects
>>> diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c
>>> b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>> new file mode 100644
>>> index 0000000..cd40e6e
>>> --- /dev/null
>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>> @@ -0,0 +1,79 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * R9A06G032 Second CA7 enabler.
>>> + *
>>> + * Copyright (C) 2018 Renesas Electronics Europe Limited
>>> + *
>>> + * Michel Pollet <michel.pollet@bp.renesas.com>,
>> <buserror@gmail.com>
>>> + * Derived from action,s500-smp
>>> + */
>>> +
>>> +#include <linux/io.h>
>>> +#include <linux/of.h>
>>> +#include <linux/of_address.h>
>>> +#include <linux/smp.h>
>>> +
>>> +/*
>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>> +it after
>>> + * writing an address into the BOOTADDR register of sysctrl.
>>> + *
>>> + * So the default value of the "cpu-release-addr" corresponds to
>> BOOTADDR...
>>> + *
>>> + * *However* the BOOTADDR register is not available when the kernel
>>> + * starts in NONSEC mode.
>>> + *
>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>> +pen
>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>> +SRAM address,
>>> + * which is not restricted.
>>
>> The binding document for cpu-release-addr does not have a definition for 32
>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>> for 32 bit arm to patch 1.
>
> Hmmm I do find a definition in
> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
> added my 'enable-method' -- And it is already used as 32 bits in at least
> arch/arm/boot/dts/stih407-family.dtsi.
>From cpus.txt:
- cpu-release-addr
Usage: required for systems that have an "enable-method"
property value of "spin-table".
Value type: <prop-encoded-array>
Definition:
# On ARM v8 64-bit systems must be a two cell
property identifying a 64-bit zero-initialised
memory location.
The definition specifies a two cell property for 64-bit systems.
Please add to the definition that cpu-release-addr is a one cell property
for 32-bit systems.
-Frank
>
> What do you want me to add to this exactly? Do you want me to just
> change "required for systems that have an "enable-method" property
> value of "spin-table" to also specify renesas,r9a06g032 ?
>
> Thanks!
> Michel
>
>>
>> -Frank
>>
>>
>>> + */
>>> +
>>> +static void __iomem *cpu_bootaddr;
>>> +
>>> +static DEFINE_SPINLOCK(cpu_lock);
>>> +
>>> +static int r9a06g032_smp_boot_secondary(unsigned int cpu, struct
>>> +task_struct *idle) {
>>> +if (!cpu_bootaddr)
>>> +return -ENODEV;
>>> +
>>> +spin_lock(&cpu_lock);
>>> +
>>> +writel(__pa_symbol(secondary_startup), cpu_bootaddr);
>>> +arch_send_wakeup_ipi_mask(cpumask_of(cpu));
>>> +
>>> +spin_unlock(&cpu_lock);
>>> +
>>> +return 0;
>>> +}
>>> +
>>> +static void __init r9a06g032_smp_prepare_cpus(unsigned int max_cpus)
>>> +{
>>> +struct device_node *dn;
>>> +int ret;
>>> +u32 bootaddr;
>>> +
>>> +dn = of_get_cpu_node(1, NULL);
>>> +if (!dn) {
>>> +pr_err("CPU#1: missing device tree node\n");
>>> +return;
>>> +}
>>> +/*
>>> + * Determine the address from which the CPU is polling.
>>> + * The bootloader *does* change this property
>>> + */
>>> +ret = of_property_read_u32(dn, "cpu-release-addr", &bootaddr);
>>> +of_node_put(dn);
>>> +if (ret) {
>>> +pr_err("CPU#1: invalid cpu-release-addr property\n");
>>> +return;
>>> +}
>>> +pr_info("CPU#1: cpu-release-addr %08x\n", bootaddr);
>>> +
>>> +cpu_bootaddr = ioremap(bootaddr, sizeof(bootaddr)); }
>>> +
>>> +static const struct smp_operations r9a06g032_smp_ops __initconst = {
>>> +.smp_prepare_cpus = r9a06g032_smp_prepare_cpus,
>>> +.smp_boot_secondary = r9a06g032_smp_boot_secondary, };
>>> +CPU_METHOD_OF_DECLARE(r9a06g032_smp, "renesas,r9a06g032-smp",
>>> +&r9a06g032_smp_ops);
>>>
>
>
>
>
> Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
>
^ permalink raw reply
* [PATCH v2 1/3] arm64: dts: allwinner: a64: add R_I2C controller
From: Maxime Ripard @ 2018-06-06 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606051702.6478-2-anarsoul@gmail.com>
On Tue, Jun 05, 2018 at 10:17:00PM -0700, Vasily Khoruzhick wrote:
> From: Icenowy Zheng <icenowy@aosc.io>
>
> Allwinner A64 has a I2C controller, which is in the R_ MMIO zone and has
> two groups of pinmuxes on PL bank, so it's called R_I2C.
>
> Add support for this I2C controller and the pinmux which doesn't conflict
> with RSB.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 +++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 1b2ef28c42bd..dcf957b2e7c8 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -46,6 +46,7 @@
> #include <dt-bindings/clock/sun8i-r-ccu.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/reset/sun50i-a64-ccu.h>
> +#include <dt-bindings/reset/sun8i-r-ccu.h>
>
> / {
> interrupt-parent = <&gic>;
> @@ -655,6 +656,18 @@
> #reset-cells = <1>;
> };
>
> + r_i2c: i2c at 1f02400 {
> + compatible = "allwinner,sun50i-a64-i2c",
> + "allwinner,sun6i-a31-i2c";
> + reg = <0x01f02400 0x400>;
> + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&r_ccu CLK_APB0_I2C>;
> + resets = <&r_ccu RST_APB0_I2C>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> r_pio: pinctrl at 1f02c00 {
> compatible = "allwinner,sun50i-a64-r-pinctrl";
> reg = <0x01f02c00 0x400>;
> @@ -666,6 +679,17 @@
> interrupt-controller;
> #interrupt-cells = <3>;
>
> +
> + r_i2c_pins: i2c {
> + pins = "PL0", "PL1";
> + function = "s_i2c";
> + };
> +
We usually don't have pin groups that are not used by any boards. I've
removed it and applied.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2 2/3] arm64: dts: allwinner: a64: Add PWM controllers
From: Maxime Ripard @ 2018-06-06 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606051702.6478-3-anarsoul@gmail.com>
On Tue, Jun 05, 2018 at 10:17:01PM -0700, Vasily Khoruzhick wrote:
> From: Andre Przywara <andre.przywara@arm.com>
>
> The Allwinner A64 SoC features two PWM controllers, which are fully
> compatible to the one used in the A13 and H3 chips.
>
> Add the nodes for the devices (one for the "normal" PWM, the other for
> the one in the CPUS domain) and the pins their outputs are connected to.
>
> On the A64 the "normal" PWM is muxed together with one of the MDIO pins
> used to communicate with the Ethernet PHY, so it won't be usable on many
> boards. But the Pinebook laptop uses this pin for controlling the LCD
> backlight.
>
> On Pine64 the CPUS PWM pin however is routed to the "RPi2" header,
> at the same location as the PWM pin on the RaspberryPi.
>
> Tested on Pinebook and Teres-I
>
> [vasily: fixed comment message as requested by Stefan Bruens, added default
> muxing options to pwm and r_pwm nodes]
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> Tested-by: Harald Geyer <harald@ccbib.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Rob Herring @ 2018-06-06 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bbbd287c-437e-d7bd-d40f-6bb914d96860@gmail.com>
On Wed, Jun 6, 2018 at 2:30 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> Hi Michel,
>
> On 06/05/18 23:36, Michel Pollet wrote:
>> Hi Frank,
>>
>> On 05 June 2018 18:34, Frank wrote:
>>> On 06/05/18 04:28, Michel Pollet wrote:
>>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>>> it requires a special enable method to get it started.
>>>>
>>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>>>> ---
>>>> arch/arm/mach-shmobile/Makefile | 1 +
>>>> arch/arm/mach-shmobile/smp-r9a06g032.c | 79
>>>> ++++++++++++++++++++++++++++++++++
>>>> 2 files changed, 80 insertions(+)
>>>> create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>
>>>> diff --git a/arch/arm/mach-shmobile/Makefile
>>>> b/arch/arm/mach-shmobile/Makefile index 1939f52..d7fc98f 100644
>>>> --- a/arch/arm/mach-shmobile/Makefile
>>>> +++ b/arch/arm/mach-shmobile/Makefile
>>>> @@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0)+= smp-sh73a0.o
>>> headsmp-scu.o platsmp-scu.o
>>>> smp-$(CONFIG_ARCH_R8A7779)+= smp-r8a7779.o headsmp-scu.o
>>> platsmp-scu.o
>>>> smp-$(CONFIG_ARCH_R8A7790)+= smp-r8a7790.o
>>>> smp-$(CONFIG_ARCH_R8A7791)+= smp-r8a7791.o
>>>> +smp-$(CONFIG_ARCH_R9A06G032)+= smp-r9a06g032.o
>>>> smp-$(CONFIG_ARCH_EMEV2)+= smp-emev2.o headsmp-scu.o
>>> platsmp-scu.o
>>>>
>>>> # PM objects
>>>> diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>> b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>> new file mode 100644
>>>> index 0000000..cd40e6e
>>>> --- /dev/null
>>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>> @@ -0,0 +1,79 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * R9A06G032 Second CA7 enabler.
>>>> + *
>>>> + * Copyright (C) 2018 Renesas Electronics Europe Limited
>>>> + *
>>>> + * Michel Pollet <michel.pollet@bp.renesas.com>,
>>> <buserror@gmail.com>
>>>> + * Derived from action,s500-smp
>>>> + */
>>>> +
>>>> +#include <linux/io.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/of_address.h>
>>>> +#include <linux/smp.h>
>>>> +
>>>> +/*
>>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>>> +it after
>>>> + * writing an address into the BOOTADDR register of sysctrl.
>>>> + *
>>>> + * So the default value of the "cpu-release-addr" corresponds to
>>> BOOTADDR...
>>>> + *
>>>> + * *However* the BOOTADDR register is not available when the kernel
>>>> + * starts in NONSEC mode.
>>>> + *
>>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>>> +pen
>>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>>> +SRAM address,
>>>> + * which is not restricted.
>>>
>>> The binding document for cpu-release-addr does not have a definition for 32
>>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>>> for 32 bit arm to patch 1.
>>
>> Hmmm I do find a definition in
>> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
>> added my 'enable-method' -- And it is already used as 32 bits in at least
>> arch/arm/boot/dts/stih407-family.dtsi.
>
> From cpus.txt:
>
> - cpu-release-addr
> Usage: required for systems that have an "enable-method"
> property value of "spin-table".
> Value type: <prop-encoded-array>
> Definition:
> # On ARM v8 64-bit systems must be a two cell
> property identifying a 64-bit zero-initialised
> memory location.
>
> The definition specifies a two cell property for 64-bit systems.
>
> Please add to the definition that cpu-release-addr is a one cell property
> for 32-bit systems.
Actually, this is all already documented in the DT spec and it is
always 2 cells[1]. We should perhaps just remove whatever is
duplicated from the spec.
Rob
[1]
``cpu-release-addr`` | SD | ``<u64>`` The
cpu-release-addr property is required for
cpu nodes that have
an enable-method property
value of
``"spin-table"``. The value specifies the
physical address of
a spin table entry that
releases a
secondary CPU from its spin loop.
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: allwinner: add support for Pinebook
From: Maxime Ripard @ 2018-06-06 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606051702.6478-4-anarsoul@gmail.com>
On Tue, Jun 05, 2018 at 10:17:02PM -0700, Vasily Khoruzhick wrote:
> From: Icenowy Zheng <icenowy@aosc.xyz>
>
> Pinebook is a A64-based laptop produced by Pine64, with the following
> peripherals:
>
> USB:
> - Two external USB ports (one is directly connected to A64's OTG
> controller, the other is under a internal hub connected to the host-only
> controller.)
> - USB HID keyboard and touchpad connected to the internal hub.
> - USB UVC camera connected to the internal hub.
>
> Power-related:
> - A DC IN jack connected to AXP803's DCIN pin.
> - A Li-Polymer battery connected to AXP803's battery pins.
>
> Storage:
> - An eMMC by Foresee on the main board (in the product revision of the
> main board it's designed to be switchable).
> - An external MicroSD card slot.
>
> Display:
> - An eDP LCD panel (1366x768) connected via an ANX6345 RGB-eDP bridge.
> - A mini HDMI port.
>
> Misc:
> - A Hall sensor designed to detect the status of lid, connected to GPIO PL12.
> - A headphone jack connected to the SoC's internal codec.
> - A debug UART port muxed with headphone jack.
>
> This commit adds basical support for it.
>
> [vasily: squashed several commits into one, added simplefb node, added usbphy
> to ehci0 and ohci0 nodes and other cosmetic changes to dts]
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
I've updated Icenowy's domain and applied, thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Florian Fainelli @ 2018-06-06 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bbbd287c-437e-d7bd-d40f-6bb914d96860@gmail.com>
On 06/06/2018 12:30 PM, Frank Rowand wrote:
> Hi Michel,
>
> On 06/05/18 23:36, Michel Pollet wrote:
>> Hi Frank,
>>
>> On 05 June 2018 18:34, Frank wrote:
>>> On 06/05/18 04:28, Michel Pollet wrote:
>>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>>> it requires a special enable method to get it started.
>>>>
>>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>>>> ---
>>>> arch/arm/mach-shmobile/Makefile | 1 +
>>>> arch/arm/mach-shmobile/smp-r9a06g032.c | 79
>>>> ++++++++++++++++++++++++++++++++++
>>>> 2 files changed, 80 insertions(+)
>>>> create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>
>>>> diff --git a/arch/arm/mach-shmobile/Makefile
>>>> b/arch/arm/mach-shmobile/Makefile index 1939f52..d7fc98f 100644
>>>> --- a/arch/arm/mach-shmobile/Makefile
>>>> +++ b/arch/arm/mach-shmobile/Makefile
>>>> @@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0)+= smp-sh73a0.o
>>> headsmp-scu.o platsmp-scu.o
>>>> smp-$(CONFIG_ARCH_R8A7779)+= smp-r8a7779.o headsmp-scu.o
>>> platsmp-scu.o
>>>> smp-$(CONFIG_ARCH_R8A7790)+= smp-r8a7790.o
>>>> smp-$(CONFIG_ARCH_R8A7791)+= smp-r8a7791.o
>>>> +smp-$(CONFIG_ARCH_R9A06G032)+= smp-r9a06g032.o
>>>> smp-$(CONFIG_ARCH_EMEV2)+= smp-emev2.o headsmp-scu.o
>>> platsmp-scu.o
>>>>
>>>> # PM objects
>>>> diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>> b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>> new file mode 100644
>>>> index 0000000..cd40e6e
>>>> --- /dev/null
>>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>> @@ -0,0 +1,79 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * R9A06G032 Second CA7 enabler.
>>>> + *
>>>> + * Copyright (C) 2018 Renesas Electronics Europe Limited
>>>> + *
>>>> + * Michel Pollet <michel.pollet@bp.renesas.com>,
>>> <buserror@gmail.com>
>>>> + * Derived from action,s500-smp
>>>> + */
>>>> +
>>>> +#include <linux/io.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/of_address.h>
>>>> +#include <linux/smp.h>
>>>> +
>>>> +/*
>>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>>> +it after
>>>> + * writing an address into the BOOTADDR register of sysctrl.
>>>> + *
>>>> + * So the default value of the "cpu-release-addr" corresponds to
>>> BOOTADDR...
>>>> + *
>>>> + * *However* the BOOTADDR register is not available when the kernel
>>>> + * starts in NONSEC mode.
>>>> + *
>>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>>> +pen
>>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>>> +SRAM address,
>>>> + * which is not restricted.
>>>
>>> The binding document for cpu-release-addr does not have a definition for 32
>>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>>> for 32 bit arm to patch 1.
>>
>> Hmmm I do find a definition in
>> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
>> added my 'enable-method' -- And it is already used as 32 bits in at least
>> arch/arm/boot/dts/stih407-family.dtsi.
>
> From cpus.txt:
>
> - cpu-release-addr
> Usage: required for systems that have an "enable-method"
> property value of "spin-table".
> Value type: <prop-encoded-array>
> Definition:
> # On ARM v8 64-bit systems must be a two cell
> property identifying a 64-bit zero-initialised
> memory location.
>
> The definition specifies a two cell property for 64-bit systems.
>
> Please add to the definition that cpu-release-addr is a one cell property
> for 32-bit systems.
Or maybe phrase it such that the number of cells encoded in
cpu-release-addr must exactly match the CPU node's #address-cells size?
--
Florian
^ permalink raw reply
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Geert Uytterhoeven @ 2018-06-06 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJCkP_c_wKGRc7Qzkiw8sZLRf6MGz-WgVsLjnQfqK8r6Q@mail.gmail.com>
Hi Rob,
On Wed, Jun 6, 2018 at 9:35 PM, Rob Herring <robh+dt@kernel.org> wrote:
> On Wed, Jun 6, 2018 at 2:30 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> On 06/05/18 23:36, Michel Pollet wrote:
>>> On 05 June 2018 18:34, Frank wrote:
>>>> On 06/05/18 04:28, Michel Pollet wrote:
>>>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>>>> it requires a special enable method to get it started.
>>>>>
>>>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>> +/*
>>>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>>>> +it after
>>>>> + * writing an address into the BOOTADDR register of sysctrl.
>>>>> + *
>>>>> + * So the default value of the "cpu-release-addr" corresponds to
>>>> BOOTADDR...
>>>>> + *
>>>>> + * *However* the BOOTADDR register is not available when the kernel
>>>>> + * starts in NONSEC mode.
>>>>> + *
>>>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>>>> +pen
>>>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>>>> +SRAM address,
>>>>> + * which is not restricted.
>>>>
>>>> The binding document for cpu-release-addr does not have a definition for 32
>>>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>>>> for 32 bit arm to patch 1.
>>>
>>> Hmmm I do find a definition in
>>> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
>>> added my 'enable-method' -- And it is already used as 32 bits in at least
>>> arch/arm/boot/dts/stih407-family.dtsi.
>>
>> From cpus.txt:
>>
>> - cpu-release-addr
>> Usage: required for systems that have an "enable-method"
>> property value of "spin-table".
>> Value type: <prop-encoded-array>
>> Definition:
>> # On ARM v8 64-bit systems must be a two cell
>> property identifying a 64-bit zero-initialised
>> memory location.
>>
>> The definition specifies a two cell property for 64-bit systems.
>>
>> Please add to the definition that cpu-release-addr is a one cell property
>> for 32-bit systems.
>
> Actually, this is all already documented in the DT spec and it is
> always 2 cells[1]. We should perhaps just remove whatever is
> duplicated from the spec.
>
> Rob
>
> [1]
> ``cpu-release-addr`` | SD | ``<u64>`` The
> cpu-release-addr property is required for
> cpu nodes that have
> an enable-method property
> value of
> ``"spin-table"``. The value specifies the
> physical address of
> a spin table entry that
> releases a
> secondary CPU from its spin loop.
Interesting. But why is this <u64>, and not just following #address-cells?
Due to the ePAPR-spec being 64-bit Power System-centric?
There's also "initial-mapped-area", which must use 64-bit values for effective
and physical addresses, according to ePAPR.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Geert Uytterhoeven @ 2018-06-06 19:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7e49c265-e332-29c5-5d91-4b5d5da6cb37@gmail.com>
Hi Florian,
On Wed, Jun 6, 2018 at 9:37 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 06/06/2018 12:30 PM, Frank Rowand wrote:
>> On 06/05/18 23:36, Michel Pollet wrote:
>>> On 05 June 2018 18:34, Frank wrote:
>>>> On 06/05/18 04:28, Michel Pollet wrote:
>>>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>>>> it requires a special enable method to get it started.
>>>>>
>>>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>> +/*
>>>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>>>> +it after
>>>>> + * writing an address into the BOOTADDR register of sysctrl.
>>>>> + *
>>>>> + * So the default value of the "cpu-release-addr" corresponds to
>>>> BOOTADDR...
>>>>> + *
>>>>> + * *However* the BOOTADDR register is not available when the kernel
>>>>> + * starts in NONSEC mode.
>>>>> + *
>>>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>>>> +pen
>>>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>>>> +SRAM address,
>>>>> + * which is not restricted.
>>>>
>>>> The binding document for cpu-release-addr does not have a definition for 32
>>>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>>>> for 32 bit arm to patch 1.
>>>
>>> Hmmm I do find a definition in
>>> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
>>> added my 'enable-method' -- And it is already used as 32 bits in at least
>>> arch/arm/boot/dts/stih407-family.dtsi.
>>
>> From cpus.txt:
>>
>> - cpu-release-addr
>> Usage: required for systems that have an "enable-method"
>> property value of "spin-table".
>> Value type: <prop-encoded-array>
>> Definition:
>> # On ARM v8 64-bit systems must be a two cell
>> property identifying a 64-bit zero-initialised
>> memory location.
>>
>> The definition specifies a two cell property for 64-bit systems.
>>
>> Please add to the definition that cpu-release-addr is a one cell property
>> for 32-bit systems.
>
> Or maybe phrase it such that the number of cells encoded in
> cpu-release-addr must exactly match the CPU node's #address-cells size?
The CPU node's #address-cells size is unrelated.
You need the #address-cells value from the SoC bus (typically the root
node, not considering heterogeneous systems with multiple CPUs ;-).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: allwinner: add support for Pinebook
From: Vasily Khoruzhick @ 2018-06-06 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606193701.seerxyy6g3nx3flk@flea>
On Wed, Jun 6, 2018 at 12:37 PM, Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
>
> I've updated Icenowy's domain and applied, thanks!
> Maxime
Thanks!
^ permalink raw reply
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Rob Herring @ 2018-06-06 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXv2UXTx_ttCqytH2TePoJ-Pw4gJ-PaSOmUL969ac1BMw@mail.gmail.com>
On Wed, Jun 6, 2018 at 2:42 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Rob,
>
> On Wed, Jun 6, 2018 at 9:35 PM, Rob Herring <robh+dt@kernel.org> wrote:
>> On Wed, Jun 6, 2018 at 2:30 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>>> On 06/05/18 23:36, Michel Pollet wrote:
>>>> On 05 June 2018 18:34, Frank wrote:
>>>>> On 06/05/18 04:28, Michel Pollet wrote:
>>>>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>>>>> it requires a special enable method to get it started.
>>>>>>
>>>>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>
>>>>>> --- /dev/null
>>>>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>
>>>>>> +/*
>>>>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>>>>> +it after
>>>>>> + * writing an address into the BOOTADDR register of sysctrl.
>>>>>> + *
>>>>>> + * So the default value of the "cpu-release-addr" corresponds to
>>>>> BOOTADDR...
>>>>>> + *
>>>>>> + * *However* the BOOTADDR register is not available when the kernel
>>>>>> + * starts in NONSEC mode.
>>>>>> + *
>>>>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>>>>> +pen
>>>>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>>>>> +SRAM address,
>>>>>> + * which is not restricted.
>>>>>
>>>>> The binding document for cpu-release-addr does not have a definition for 32
>>>>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>>>>> for 32 bit arm to patch 1.
>>>>
>>>> Hmmm I do find a definition in
>>>> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
>>>> added my 'enable-method' -- And it is already used as 32 bits in at least
>>>> arch/arm/boot/dts/stih407-family.dtsi.
>>>
>>> From cpus.txt:
>>>
>>> - cpu-release-addr
>>> Usage: required for systems that have an "enable-method"
>>> property value of "spin-table".
>>> Value type: <prop-encoded-array>
>>> Definition:
>>> # On ARM v8 64-bit systems must be a two cell
>>> property identifying a 64-bit zero-initialised
>>> memory location.
>>>
>>> The definition specifies a two cell property for 64-bit systems.
>>>
>>> Please add to the definition that cpu-release-addr is a one cell property
>>> for 32-bit systems.
>>
>> Actually, this is all already documented in the DT spec and it is
>> always 2 cells[1]. We should perhaps just remove whatever is
>> duplicated from the spec.
>>
>> Rob
>>
>> [1]
>> ``cpu-release-addr`` | SD | ``<u64>`` The
>> cpu-release-addr property is required for
>> cpu nodes that have
>> an enable-method property
>> value of
>> ``"spin-table"``. The value specifies the
>> physical address of
>> a spin table entry that
>> releases a
>> secondary CPU from its spin loop.
>
> Interesting. But why is this <u64>, and not just following #address-cells?
As you said in your other email, it's not the same.
> Due to the ePAPR-spec being 64-bit Power System-centric?
Other than #address-cells already having another defined purpose in
/cpus, my guess is 64-bit works for either and 32-bit SMP systems
didn't predate 64-bit (for the ePAPR author's perspective).
> There's also "initial-mapped-area", which must use 64-bit values for effective
> and physical addresses, according to ePAPR.
I would have thought that followed #{size,address}-cells being
/memory. Though, I guess the bootloader fills this in and it is much
easier to work with fixed sizes.
Rob
^ permalink raw reply
* [PATCH 1/2] arm64: avoid alloc memory on offline node
From: Bjorn Helgaas @ 2018-06-06 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606154516.GL6631@arm.com>
[+cc akpm, linux-mm, linux-pci]
On Wed, Jun 6, 2018 at 10:44 AM Will Deacon <will.deacon@arm.com> wrote:
>
> On Thu, May 31, 2018 at 08:14:38PM +0800, Xie XiuQi wrote:
> > A numa system may return node which is not online.
> > For example, a numa node:
> > 1) without memory
> > 2) NR_CPUS is very small, and the cpus on the node are not brought up
> >
> > In this situation, we use NUMA_NO_NODE to avoid oops.
> >
> > [ 25.732905] Unable to handle kernel NULL pointer dereference at virtual address 00001988
> > [ 25.740982] Mem abort info:
> > [ 25.743762] ESR = 0x96000005
> > [ 25.746803] Exception class = DABT (current EL), IL = 32 bits
> > [ 25.752711] SET = 0, FnV = 0
> > [ 25.755751] EA = 0, S1PTW = 0
> > [ 25.758878] Data abort info:
> > [ 25.761745] ISV = 0, ISS = 0x00000005
> > [ 25.765568] CM = 0, WnR = 0
> > [ 25.768521] [0000000000001988] user address but active_mm is swapper
> > [ 25.774861] Internal error: Oops: 96000005 [#1] SMP
> > [ 25.779724] Modules linked in:
> > [ 25.782768] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.17.0-rc6-mpam+ #115
> > [ 25.789714] Hardware name: Huawei D06/D06, BIOS Hisilicon D06 EC UEFI Nemo 2.0 RC0 - B305 05/28/2018
> > [ 25.798831] pstate: 80c00009 (Nzcv daif +PAN +UAO)
> > [ 25.803612] pc : __alloc_pages_nodemask+0xf0/0xe70
> > [ 25.808389] lr : __alloc_pages_nodemask+0x184/0xe70
> > [ 25.813252] sp : ffff00000996f660
> > [ 25.816553] x29: ffff00000996f660 x28: 0000000000000000
> > [ 25.821852] x27: 00000000014012c0 x26: 0000000000000000
> > [ 25.827150] x25: 0000000000000003 x24: ffff000008099eac
> > [ 25.832449] x23: 0000000000400000 x22: 0000000000000000
> > [ 25.837747] x21: 0000000000000001 x20: 0000000000000000
> > [ 25.843045] x19: 0000000000400000 x18: 0000000000010e00
> > [ 25.848343] x17: 000000000437f790 x16: 0000000000000020
> > [ 25.853641] x15: 0000000000000000 x14: 6549435020524541
> > [ 25.858939] x13: 20454d502067756c x12: 0000000000000000
> > [ 25.864237] x11: ffff00000996f6f0 x10: 0000000000000006
> > [ 25.869536] x9 : 00000000000012a4 x8 : ffff8023c000ff90
> > [ 25.874834] x7 : 0000000000000000 x6 : ffff000008d73c08
> > [ 25.880132] x5 : 0000000000000000 x4 : 0000000000000081
> > [ 25.885430] x3 : 0000000000000000 x2 : 0000000000000000
> > [ 25.890728] x1 : 0000000000000001 x0 : 0000000000001980
> > [ 25.896027] Process swapper/0 (pid: 1, stack limit = 0x (ptrval))
> > [ 25.902712] Call trace:
> > [ 25.905146] __alloc_pages_nodemask+0xf0/0xe70
> > [ 25.909577] allocate_slab+0x94/0x590
> > [ 25.913225] new_slab+0x68/0xc8
> > [ 25.916353] ___slab_alloc+0x444/0x4f8
> > [ 25.920088] __slab_alloc+0x50/0x68
> > [ 25.923562] kmem_cache_alloc_node_trace+0xe8/0x230
> > [ 25.928426] pci_acpi_scan_root+0x94/0x278
> > [ 25.932510] acpi_pci_root_add+0x228/0x4b0
> > [ 25.936593] acpi_bus_attach+0x10c/0x218
> > [ 25.940501] acpi_bus_attach+0xac/0x218
> > [ 25.944323] acpi_bus_attach+0xac/0x218
> > [ 25.948144] acpi_bus_scan+0x5c/0xc0
> > [ 25.951708] acpi_scan_init+0xf8/0x254
> > [ 25.955443] acpi_init+0x310/0x37c
> > [ 25.958831] do_one_initcall+0x54/0x208
> > [ 25.962653] kernel_init_freeable+0x244/0x340
> > [ 25.966999] kernel_init+0x18/0x118
> > [ 25.970474] ret_from_fork+0x10/0x1c
> > [ 25.974036] Code: 7100047f 321902a4 1a950095 b5000602 (b9400803)
> > [ 25.980162] ---[ end trace 64f0893eb21ec283 ]---
> > [ 25.984765] Kernel panic - not syncing: Fatal exception
> >
> > Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
> > Tested-by: Huiqiang Wang <wanghuiqiang@huawei.com>
> > Cc: Hanjun Guo <hanjun.guo@linaro.org>
> > Cc: Tomasz Nowicki <Tomasz.Nowicki@caviumnetworks.com>
> > Cc: Xishi Qiu <qiuxishi@huawei.com>
> > ---
> > arch/arm64/kernel/pci.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > index 0e2ea1c..e17cc45 100644
> > --- a/arch/arm64/kernel/pci.c
> > +++ b/arch/arm64/kernel/pci.c
> > @@ -170,6 +170,9 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> > struct pci_bus *bus, *child;
> > struct acpi_pci_root_ops *root_ops;
> >
> > + if (node != NUMA_NO_NODE && !node_online(node))
> > + node = NUMA_NO_NODE;
> > +
>
> This really feels like a bodge, but it does appear to be what other
> architectures do, so:
>
> Acked-by: Will Deacon <will.deacon@arm.com>
I agree, this doesn't feel like something we should be avoiding in the
caller of kzalloc_node().
I would not expect kzalloc_node() to return memory that's offline, no
matter what node we told it to allocate from. I could imagine it
returning failure, or returning memory from a node that *is* online,
but returning a pointer to offline memory seems broken.
Are we putting memory that's offline in the free list? I don't know
where to look to figure this out.
Bjorn
^ permalink raw reply
* [PATCH v4 05/14] coresight: get/put module in coresight_build/release_path
From: Kim Phillips @ 2018-06-06 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a457594c-b391-23e1-6ab5-d115073cac5a@arm.com>
On Wed, 6 Jun 2018 10:46:36 +0100
Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> On 06/06/2018 09:24 AM, Greg Kroah-Hartman wrote:
> > On Tue, Jun 05, 2018 at 04:07:01PM -0500, Kim Phillips wrote:
> >> Increment the refcnt for driver modules in current use by calling
> >> module_get in coresight_build_path and module_put in release_path.
> >>
> >> This prevents driver modules from being unloaded when they are in use,
> >> either in sysfs or perf mode.
> >
> > Why does it matter? Shouldn't you be allowed to remove any module at
> > any point in time, much like a networking driver?
> >
> >
> >>
> >> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> >> Cc: Leo Yan <leo.yan@linaro.org>
> >> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> >> Cc: Randy Dunlap <rdunlap@infradead.org>
> >> Cc: Suzuki K Poulose <Suzuki.Poulose@arm.com>
> >> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >> Cc: Russell King <linux@armlinux.org.uk>
> >> Signed-off-by: Kim Phillips <kim.phillips@arm.com>
> >> ---
> >> drivers/hwtracing/coresight/coresight.c | 9 +++++++++
> >> 1 file changed, 9 insertions(+)
> >>
> >> diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
> >> index 338f1719641c..1c941351f1d1 100644
> >> --- a/drivers/hwtracing/coresight/coresight.c
> >> +++ b/drivers/hwtracing/coresight/coresight.c
> >> @@ -465,6 +465,12 @@ static int _coresight_build_path(struct coresight_device *csdev,
> >>
> >> node->csdev = csdev;
> >> list_add(&node->link, path);
> >> +
> >> + if (!try_module_get(csdev->dev.parent->driver->owner)) {
> >
> > What is to keep parent->driver from going away right here? What keeps
> > parent around? This feels very fragile to me, I don't see any locking
> > anywhere around this code path to try to keep things in place.
>
> You're right. We do have coresight_mutex, which is held across the build
> path and the csdev is removed when a device is unregistered. However, I
> see that we don't hold the mutex while removing the connections from
> coresight_unregister(). Holding the mutex should protect us from the
> csdev being removed, while we build the path.
OK, I'll add this for the next version:
diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
index f96258de1e9b..da702507a55c 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -1040,8 +1040,12 @@ EXPORT_SYMBOL_GPL(coresight_register);
void coresight_unregister(struct coresight_device *csdev)
{
+ mutex_lock(&coresight_mutex);
+
/* Remove references of that device in the topology */
coresight_remove_conns(csdev);
device_unregister(&csdev->dev);
+
+ mutex_unlock(&coresight_mutex);
}
EXPORT_SYMBOL_GPL(coresight_unregister);
> And while we are at this, I also realised that we hold references to the
> parent devices for each connection (via bus_find_device() from
> of_coresight_get_endpoint_device()), while parsing the platform data,
> which is never released.
Would this fix that?:
diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
index a33a92ebe74b..a43ab078c85e 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -181,6 +181,8 @@ of_get_coresight_platform_data(struct device *dev,
pdata->child_names[i] = dev_name(rdev);
pdata->child_ports[i] = rendpoint.id;
+ put_device(rdev);
+
i++;
} while (ep);
}
Thanks,
Kim
^ permalink raw reply related
* [clk:clk-bcm-stingray 1/2] drivers/clk/bcm/clk-sr.c:217:3: error: 'BCM_SR_LCPLL0_SATA_REF_CLK' undeclared here (not in a function); did you mean 'BCM_SR_LCPLL0_SATA_REFN_CLK'?
From: Ray Jui @ 2018-06-06 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201806021742.e6HPCQOb%fengguang.wu@intel.com>
Hi Stephen,
I'd like to confirm this kbuild error is caused by changing of the defines
in the header.
That is, kbuild test should pass with 2/2 patch.
If my understanding is incorrect and this requires any further action,
please let me know.
Thanks,
Ray
-----Original Message-----
From: kbuild test robot [mailto:lkp at intel.com]
Sent: Saturday, June 2, 2018 2:02 AM
To: Pramod Kumar
Cc: kbuild-all at 01.org; linux-clk at vger.kernel.org;
linux-arm-kernel at lists.infradead.org; Stephen Boyd; Ray Jui
Subject: [clk:clk-bcm-stingray 1/2] drivers/clk/bcm/clk-sr.c:217:3: error:
'BCM_SR_LCPLL0_SATA_REF_CLK' undeclared here (not in a function); did you
mean 'BCM_SR_LCPLL0_SATA_REFN_CLK'?
tree: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
clk-bcm-stingray
head: 5afa881c6635427e68c73861a2c22d8cac00b984
commit: 48bf9a522c14449cc7c214c6062668ac54e4e88f [1/2] dt-bindings: clk:
Update Stingray binding doc
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 48bf9a522c14449cc7c214c6062668ac54e4e88f
# save the attached .config to linux build tree
make.cross ARCH=sh
Note: the clk/clk-bcm-stingray HEAD
5afa881c6635427e68c73861a2c22d8cac00b984 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/clk/bcm/clk-sr.c:59:3: error: 'BCM_SR_GENPLL0_SATA_CLK'
undeclared here (not in a function); did you mean
'BCM_SR_GENPLL0_SCR_CLK'?
[BCM_SR_GENPLL0_SATA_CLK] = {
^~~~~~~~~~~~~~~~~~~~~~~
BCM_SR_GENPLL0_SCR_CLK
drivers/clk/bcm/clk-sr.c:59:3: error: array index in initializer not of
integer type
drivers/clk/bcm/clk-sr.c:59:3: note: (near initialization for
'sr_genpll0_clk')
drivers/clk/bcm/clk-sr.c:184:3: error: 'BCM_SR_GENPLL5_FS_CLK'
undeclared here (not in a function); did you mean
'BCM_SR_GENPLL2_FS4_CLK'?
[BCM_SR_GENPLL5_FS_CLK] = {
^~~~~~~~~~~~~~~~~~~~~
BCM_SR_GENPLL2_FS4_CLK
drivers/clk/bcm/clk-sr.c:184:3: error: array index in initializer not
of integer type
drivers/clk/bcm/clk-sr.c:184:3: note: (near initialization for
'sr_genpll5_clk')
drivers/clk/bcm/clk-sr.c:185:14: warning: initialization makes integer
from pointer without a cast [-Wint-conversion]
.channel = BCM_SR_GENPLL5_FS_CLK,
^~~~~~~~~~~~~~~~~~~~~
drivers/clk/bcm/clk-sr.c:185:14: note: (near initialization for
'sr_genpll5_clk[0].channel')
drivers/clk/bcm/clk-sr.c:185:14: error: initializer element is not
constant
drivers/clk/bcm/clk-sr.c:185:14: note: (near initialization for
'sr_genpll5_clk[0].channel')
drivers/clk/bcm/clk-sr.c:190:3: error: 'BCM_SR_GENPLL5_SPU_CLK'
undeclared here (not in a function); did you mean 'BCM_SR_GENPLL5_FS_CLK'?
[BCM_SR_GENPLL5_SPU_CLK] = {
^~~~~~~~~~~~~~~~~~~~~~
BCM_SR_GENPLL5_FS_CLK
drivers/clk/bcm/clk-sr.c:190:3: error: array index in initializer not
of integer type
drivers/clk/bcm/clk-sr.c:190:3: note: (near initialization for
'sr_genpll5_clk')
drivers/clk/bcm/clk-sr.c:191:14: warning: initialization makes integer
from pointer without a cast [-Wint-conversion]
.channel = BCM_SR_GENPLL5_SPU_CLK,
^~~~~~~~~~~~~~~~~~~~~~
drivers/clk/bcm/clk-sr.c:191:14: note: (near initialization for
'sr_genpll5_clk[1].channel')
drivers/clk/bcm/clk-sr.c:191:14: error: initializer element is not
constant
drivers/clk/bcm/clk-sr.c:191:14: note: (near initialization for
'sr_genpll5_clk[1].channel')
>> drivers/clk/bcm/clk-sr.c:217:3: error: 'BCM_SR_LCPLL0_SATA_REF_CLK'
undeclared here (not in a function); did you mean
'BCM_SR_LCPLL0_SATA_REFN_CLK'?
[BCM_SR_LCPLL0_SATA_REF_CLK] = {
^~~~~~~~~~~~~~~~~~~~~~~~~~
BCM_SR_LCPLL0_SATA_REFN_CLK
drivers/clk/bcm/clk-sr.c:217:3: error: array index in initializer not
of integer type
drivers/clk/bcm/clk-sr.c:217:3: note: (near initialization for
'sr_lcpll0_clk')
drivers/clk/bcm/clk-sr.c:218:14: warning: initialization makes integer
from pointer without a cast [-Wint-conversion]
.channel = BCM_SR_LCPLL0_SATA_REF_CLK,
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/clk/bcm/clk-sr.c:218:14: note: (near initialization for
'sr_lcpll0_clk[0].channel')
drivers/clk/bcm/clk-sr.c:218:14: error: initializer element is not
constant
drivers/clk/bcm/clk-sr.c:218:14: note: (near initialization for
'sr_lcpll0_clk[0].channel')
drivers/clk/bcm/clk-sr.c:223:3: error: 'BCM_SR_LCPLL0_USB_REF_CLK'
undeclared here (not in a function); did you mean
'BCM_SR_LCPLL1_USB_REF_CLK'?
[BCM_SR_LCPLL0_USB_REF_CLK] = {
^~~~~~~~~~~~~~~~~~~~~~~~~
BCM_SR_LCPLL1_USB_REF_CLK
drivers/clk/bcm/clk-sr.c:223:3: error: array index in initializer not
of integer type
drivers/clk/bcm/clk-sr.c:223:3: note: (near initialization for
'sr_lcpll0_clk')
drivers/clk/bcm/clk-sr.c:224:14: warning: initialization makes integer
from pointer without a cast [-Wint-conversion]
.channel = BCM_SR_LCPLL0_USB_REF_CLK,
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/clk/bcm/clk-sr.c:224:14: note: (near initialization for
'sr_lcpll0_clk[1].channel')
drivers/clk/bcm/clk-sr.c:224:14: error: initializer element is not
constant
drivers/clk/bcm/clk-sr.c:224:14: note: (near initialization for
'sr_lcpll0_clk[1].channel')
>> drivers/clk/bcm/clk-sr.c:229:3: error: 'BCM_SR_LCPLL0_SATA_REFPN_CLK'
undeclared here (not in a function); did you mean
'BCM_SR_LCPLL0_SATA_REFN_CLK'?
[BCM_SR_LCPLL0_SATA_REFPN_CLK] = {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
BCM_SR_LCPLL0_SATA_REFN_CLK
drivers/clk/bcm/clk-sr.c:229:3: error: array index in initializer not
of integer type
drivers/clk/bcm/clk-sr.c:229:3: note: (near initialization for
'sr_lcpll0_clk')
drivers/clk/bcm/clk-sr.c:230:14: warning: initialization makes integer
from pointer without a cast [-Wint-conversion]
.channel = BCM_SR_LCPLL0_SATA_REFPN_CLK,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/clk/bcm/clk-sr.c:230:14: note: (near initialization for
'sr_lcpll0_clk[2].channel')
drivers/clk/bcm/clk-sr.c:230:14: error: initializer element is not
constant
drivers/clk/bcm/clk-sr.c:230:14: note: (near initialization for
'sr_lcpll0_clk[2].channel')
vim +217 drivers/clk/bcm/clk-sr.c
654cdd32 Sandeep Tripathy 2017-06-06 182
654cdd32 Sandeep Tripathy 2017-06-06 183 static const struct
iproc_clk_ctrl sr_genpll5_clk[] = {
654cdd32 Sandeep Tripathy 2017-06-06 184 [BCM_SR_GENPLL5_FS_CLK] =
{
654cdd32 Sandeep Tripathy 2017-06-06 185 .channel =
BCM_SR_GENPLL5_FS_CLK,
654cdd32 Sandeep Tripathy 2017-06-06 186 .flags =
IPROC_CLK_AON,
654cdd32 Sandeep Tripathy 2017-06-06 187 .enable =
ENABLE_VAL(0x4, 6, 0, 12),
654cdd32 Sandeep Tripathy 2017-06-06 188 .mdiv =
REG_VAL(0x18, 0, 9),
654cdd32 Sandeep Tripathy 2017-06-06 189 },
654cdd32 Sandeep Tripathy 2017-06-06 @190 [BCM_SR_GENPLL5_SPU_CLK] =
{
654cdd32 Sandeep Tripathy 2017-06-06 191 .channel =
BCM_SR_GENPLL5_SPU_CLK,
654cdd32 Sandeep Tripathy 2017-06-06 192 .flags =
IPROC_CLK_AON,
654cdd32 Sandeep Tripathy 2017-06-06 193 .enable =
ENABLE_VAL(0x4, 6, 0, 12),
654cdd32 Sandeep Tripathy 2017-06-06 194 .mdiv =
REG_VAL(0x18, 10, 9),
654cdd32 Sandeep Tripathy 2017-06-06 195 },
654cdd32 Sandeep Tripathy 2017-06-06 196 };
654cdd32 Sandeep Tripathy 2017-06-06 197
654cdd32 Sandeep Tripathy 2017-06-06 198 static int
sr_genpll5_clk_init(struct platform_device *pdev)
654cdd32 Sandeep Tripathy 2017-06-06 199 {
654cdd32 Sandeep Tripathy 2017-06-06 200
iproc_pll_clk_setup(pdev->dev.of_node,
654cdd32 Sandeep Tripathy 2017-06-06 201
&sr_genpll5, NULL, 0, sr_genpll5_clk,
654cdd32 Sandeep Tripathy 2017-06-06 202
ARRAY_SIZE(sr_genpll5_clk));
654cdd32 Sandeep Tripathy 2017-06-06 203 return 0;
654cdd32 Sandeep Tripathy 2017-06-06 204 }
654cdd32 Sandeep Tripathy 2017-06-06 205
654cdd32 Sandeep Tripathy 2017-06-06 206 static const struct
iproc_pll_ctrl sr_lcpll0 = {
654cdd32 Sandeep Tripathy 2017-06-06 207 .flags = IPROC_CLK_AON |
IPROC_CLK_PLL_NEEDS_SW_CFG,
654cdd32 Sandeep Tripathy 2017-06-06 208 .aon = AON_VAL(0x0, 2, 19,
18),
654cdd32 Sandeep Tripathy 2017-06-06 209 .reset = RESET_VAL(0x0,
31, 30),
654cdd32 Sandeep Tripathy 2017-06-06 210 .sw_ctrl =
SW_CTRL_VAL(0x4, 31),
654cdd32 Sandeep Tripathy 2017-06-06 211 .ndiv_int = REG_VAL(0x4,
16, 10),
654cdd32 Sandeep Tripathy 2017-06-06 212 .pdiv = REG_VAL(0x4, 26,
4),
654cdd32 Sandeep Tripathy 2017-06-06 213 .status = REG_VAL(0x38,
12, 1),
654cdd32 Sandeep Tripathy 2017-06-06 214 };
654cdd32 Sandeep Tripathy 2017-06-06 215
654cdd32 Sandeep Tripathy 2017-06-06 216 static const struct
iproc_clk_ctrl sr_lcpll0_clk[] = {
654cdd32 Sandeep Tripathy 2017-06-06 @217
[BCM_SR_LCPLL0_SATA_REF_CLK] = {
654cdd32 Sandeep Tripathy 2017-06-06 218 .channel =
BCM_SR_LCPLL0_SATA_REF_CLK,
654cdd32 Sandeep Tripathy 2017-06-06 219 .flags =
IPROC_CLK_AON,
654cdd32 Sandeep Tripathy 2017-06-06 220 .enable =
ENABLE_VAL(0x0, 7, 1, 13),
654cdd32 Sandeep Tripathy 2017-06-06 221 .mdiv =
REG_VAL(0x14, 0, 9),
654cdd32 Sandeep Tripathy 2017-06-06 222 },
654cdd32 Sandeep Tripathy 2017-06-06 @223
[BCM_SR_LCPLL0_USB_REF_CLK] = {
654cdd32 Sandeep Tripathy 2017-06-06 224 .channel =
BCM_SR_LCPLL0_USB_REF_CLK,
654cdd32 Sandeep Tripathy 2017-06-06 225 .flags =
IPROC_CLK_AON,
654cdd32 Sandeep Tripathy 2017-06-06 226 .enable =
ENABLE_VAL(0x0, 8, 2, 14),
654cdd32 Sandeep Tripathy 2017-06-06 227 .mdiv =
REG_VAL(0x14, 10, 9),
654cdd32 Sandeep Tripathy 2017-06-06 228 },
654cdd32 Sandeep Tripathy 2017-06-06 @229
[BCM_SR_LCPLL0_SATA_REFPN_CLK] = {
654cdd32 Sandeep Tripathy 2017-06-06 230 .channel =
BCM_SR_LCPLL0_SATA_REFPN_CLK,
654cdd32 Sandeep Tripathy 2017-06-06 231 .flags =
IPROC_CLK_AON,
654cdd32 Sandeep Tripathy 2017-06-06 232 .enable =
ENABLE_VAL(0x0, 9, 3, 15),
654cdd32 Sandeep Tripathy 2017-06-06 233 .mdiv =
REG_VAL(0x14, 20, 9),
654cdd32 Sandeep Tripathy 2017-06-06 234 },
654cdd32 Sandeep Tripathy 2017-06-06 235 };
654cdd32 Sandeep Tripathy 2017-06-06 236
:::::: The code at line 217 was first introduced by commit
:::::: 654cdd3229cd1d3f2bfb9df57baf88ba382a52be clk: bcm: Add clocks for
Stingray SOC
:::::: TO: Sandeep Tripathy <sandeep.tripathy@broadcom.com>
:::::: CC: Stephen Boyd <sboyd@codeaurora.org>
---
0-DAY kernel test infrastructure Open Source Technology
Center
https://lists.01.org/pipermail/kbuild-all Intel
Corporation
^ permalink raw reply
* [PATCH] perf: xgene: Fix IOB SLOW PMU parser error
From: Hoan Tran @ 2018-06-06 21:06 UTC (permalink / raw)
To: linux-arm-kernel
This patch fixes the below parser error of the IOB SLOW PMU.
# perf stat -a -e iob-slow0/cycle-count/ sleep 1
evenf syntax error: 'iob-slow0/cycle-count/'
\___ parser error
It replaces the "-" character by "_" character inside the PMU name.
Signed-off-by: Hoan Tran <hoan.tran@amperecomputing.com>
---
drivers/perf/xgene_pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/perf/xgene_pmu.c b/drivers/perf/xgene_pmu.c
index 6bdb1da..0e31f13 100644
--- a/drivers/perf/xgene_pmu.c
+++ b/drivers/perf/xgene_pmu.c
@@ -1463,7 +1463,7 @@ static char *xgene_pmu_dev_name(struct device *dev, u32 type, int id)
case PMU_TYPE_IOB:
return devm_kasprintf(dev, GFP_KERNEL, "iob%d", id);
case PMU_TYPE_IOB_SLOW:
- return devm_kasprintf(dev, GFP_KERNEL, "iob-slow%d", id);
+ return devm_kasprintf(dev, GFP_KERNEL, "iob_slow%d", id);
case PMU_TYPE_MCB:
return devm_kasprintf(dev, GFP_KERNEL, "mcb%d", id);
case PMU_TYPE_MC:
--
2.7.4
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Ampere Computing or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. Any review, copying, or distribution of this email (or any attachments thereto) is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
^ permalink raw reply related
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Frank Rowand @ 2018-06-06 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJCkP_c_wKGRc7Qzkiw8sZLRf6MGz-WgVsLjnQfqK8r6Q@mail.gmail.com>
On 06/06/18 12:35, Rob Herring wrote:
> On Wed, Jun 6, 2018 at 2:30 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> Hi Michel,
>>
>> On 06/05/18 23:36, Michel Pollet wrote:
>>> Hi Frank,
>>>
>>> On 05 June 2018 18:34, Frank wrote:
>>>> On 06/05/18 04:28, Michel Pollet wrote:
>>>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>>>>> it requires a special enable method to get it started.
>>>>>
>>>>> Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>>>>> ---
>>>>> arch/arm/mach-shmobile/Makefile | 1 +
>>>>> arch/arm/mach-shmobile/smp-r9a06g032.c | 79
>>>>> ++++++++++++++++++++++++++++++++++
>>>>> 2 files changed, 80 insertions(+)
>>>>> create mode 100644 arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>>
>>>>> diff --git a/arch/arm/mach-shmobile/Makefile
>>>>> b/arch/arm/mach-shmobile/Makefile index 1939f52..d7fc98f 100644
>>>>> --- a/arch/arm/mach-shmobile/Makefile
>>>>> +++ b/arch/arm/mach-shmobile/Makefile
>>>>> @@ -34,6 +34,7 @@ smp-$(CONFIG_ARCH_SH73A0)+= smp-sh73a0.o
>>>> headsmp-scu.o platsmp-scu.o
>>>>> smp-$(CONFIG_ARCH_R8A7779)+= smp-r8a7779.o headsmp-scu.o
>>>> platsmp-scu.o
>>>>> smp-$(CONFIG_ARCH_R8A7790)+= smp-r8a7790.o
>>>>> smp-$(CONFIG_ARCH_R8A7791)+= smp-r8a7791.o
>>>>> +smp-$(CONFIG_ARCH_R9A06G032)+= smp-r9a06g032.o
>>>>> smp-$(CONFIG_ARCH_EMEV2)+= smp-emev2.o headsmp-scu.o
>>>> platsmp-scu.o
>>>>>
>>>>> # PM objects
>>>>> diff --git a/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>> b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>> new file mode 100644
>>>>> index 0000000..cd40e6e
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
>>>>> @@ -0,0 +1,79 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>> +/*
>>>>> + * R9A06G032 Second CA7 enabler.
>>>>> + *
>>>>> + * Copyright (C) 2018 Renesas Electronics Europe Limited
>>>>> + *
>>>>> + * Michel Pollet <michel.pollet@bp.renesas.com>,
>>>> <buserror@gmail.com>
>>>>> + * Derived from action,s500-smp
>>>>> + */
>>>>> +
>>>>> +#include <linux/io.h>
>>>>> +#include <linux/of.h>
>>>>> +#include <linux/of_address.h>
>>>>> +#include <linux/smp.h>
>>>>> +
>>>>> +/*
>>>>> + * The second CPU is parked in ROM at boot time. It requires waking
>>>>> +it after
>>>>> + * writing an address into the BOOTADDR register of sysctrl.
>>>>> + *
>>>>> + * So the default value of the "cpu-release-addr" corresponds to
>>>> BOOTADDR...
>>>>> + *
>>>>> + * *However* the BOOTADDR register is not available when the kernel
>>>>> + * starts in NONSEC mode.
>>>>> + *
>>>>> + * So for NONSEC mode, the bootloader re-parks the second CPU into a
>>>>> +pen
>>>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to a
>>>>> +SRAM address,
>>>>> + * which is not restricted.
>>>>
>>>> The binding document for cpu-release-addr does not have a definition for 32
>>>> bit arm. The existing definition is only 64 bit arm. Please add the definition
>>>> for 32 bit arm to patch 1.
>>>
>>> Hmmm I do find a definition in
>>> Documentation/devicetree/bindings/arm/cpus.txt -- just under where I
>>> added my 'enable-method' -- And it is already used as 32 bits in at least
>>> arch/arm/boot/dts/stih407-family.dtsi.
>>
>> From cpus.txt:
>>
>> - cpu-release-addr
>> Usage: required for systems that have an "enable-method"
>> property value of "spin-table".
>> Value type: <prop-encoded-array>
>> Definition:
>> # On ARM v8 64-bit systems must be a two cell
>> property identifying a 64-bit zero-initialised
>> memory location.
>>
>> The definition specifies a two cell property for 64-bit systems.
>>
>> Please add to the definition that cpu-release-addr is a one cell property
>> for 32-bit systems.
>
> Actually, this is all already documented in the DT spec and it is
> always 2 cells[1]. We should perhaps just remove whatever is
> duplicated from the spec.
Thanks for noting that. I jumped to the (incorrect) conclusion that the
property should be one cell based on the code and the .dtsi.
There are about 4 more emails following this in the thread that discuss
what size cpu-release-addr should be. Whatever the end result is (one
cell or two or based on some #XXX-calls value), it needs to be documented
consistently in the binding and in the DT spec (or preferably only in the
DT spec), and if it is a two cell property for this system then
smp-r9a06g032.c and r9a06g032.dtsi need to be adjusted to reflect that.
-Frank
>
> Rob
>
> [1]
> ``cpu-release-addr`` | SD | ``<u64>`` The
> cpu-release-addr property is required for
> cpu nodes that have
> an enable-method property
> value of
> ``"spin-table"``. The value specifies the
> physical address of
> a spin table entry that
> releases a
> secondary CPU from its spin loop.
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox