Re: [PATCH 2/4] clk: qcom: Add clk_rcg2_gfx3d_ops for SDM845
Quoting Jordan Crouse (2018-08-06 08:04:37) > On Mon, Aug 06, 2018 at 02:37:18PM +0530, Amit Nischal wrote: > > On 2018-08-03 04:14, Stephen Boyd wrote: > > >Quoting Amit Nischal (2018-07-30 04:28:56) > > >>On 2018-07-25 12:28, Stephen Boyd wrote: > > >>> > > >>> Ok. Sounds good! Is the rate range call really needed? It can't be > > >>> determined in the PLL code with some table or avoided by making sure > > >>> GPU > > >>> uses OPP table with only approved frequencies? > > >>> > > >> > > >>Currently fabia PLL code does not have any table to check this and > > >>intention > > >>was to avoid relying on the client to call set_rate with only approved > > >>frequencies so we have added the set_rate_range() call in the GPUCC > > >>driver > > >>in order to set the rate range. > > >> > > > > > >But GPU will use OPP so it doesn't seem like it really buys us anything > > >here. And it really doesn't matter when the clk driver implementation > > >doesn't use the min/max to clamp the values of the round_rate() > > >call. Is > > >that being done here? I need to double check. I would be more convinced > > >if the implementation was looking at min/max to constrain the rate > > >requested. > > > > > > > So our understanding is that GPU(client) driver will always call the > > set_rate with approved frequencies only and we can completely rely > > on the > > client. Is our understanding is correct? > > > First: on sdm845 the software doesn't set the GPU clocks - we rely on the GMU > firmware to do that on our behalf but for the GPU at least this is an academic > exercise. So what is this GPU clk driver for then? > > But that said: traditionally we've expected that the clock driver correctly > clamp the requested rate to the correct values. In the past we have taken > advantage of this and we may in the future. I don't think it is reasonable > to require the leaf driver to only pass "approved" frequencies especially > since we depend on our own OPP table that may or may not be similar to the > one used by the clock driver. > Ok. Sounds like things can't be kept in sync between the clk driver and the OPP tables. Why is that hard to do? Either way, I'd be fine if the code actually used the frequency limits to round the rate to something within range, but I don't recall seeing that being done here. So if the min/max limits stay, the clk driver should round to within that range.
Re: [PATCH 2/4] clk: qcom: Add clk_rcg2_gfx3d_ops for SDM845
Quoting Jordan Crouse (2018-08-06 08:04:37) > On Mon, Aug 06, 2018 at 02:37:18PM +0530, Amit Nischal wrote: > > On 2018-08-03 04:14, Stephen Boyd wrote: > > >Quoting Amit Nischal (2018-07-30 04:28:56) > > >>On 2018-07-25 12:28, Stephen Boyd wrote: > > >>> > > >>> Ok. Sounds good! Is the rate range call really needed? It can't be > > >>> determined in the PLL code with some table or avoided by making sure > > >>> GPU > > >>> uses OPP table with only approved frequencies? > > >>> > > >> > > >>Currently fabia PLL code does not have any table to check this and > > >>intention > > >>was to avoid relying on the client to call set_rate with only approved > > >>frequencies so we have added the set_rate_range() call in the GPUCC > > >>driver > > >>in order to set the rate range. > > >> > > > > > >But GPU will use OPP so it doesn't seem like it really buys us anything > > >here. And it really doesn't matter when the clk driver implementation > > >doesn't use the min/max to clamp the values of the round_rate() > > >call. Is > > >that being done here? I need to double check. I would be more convinced > > >if the implementation was looking at min/max to constrain the rate > > >requested. > > > > > > > So our understanding is that GPU(client) driver will always call the > > set_rate with approved frequencies only and we can completely rely > > on the > > client. Is our understanding is correct? > > > First: on sdm845 the software doesn't set the GPU clocks - we rely on the GMU > firmware to do that on our behalf but for the GPU at least this is an academic > exercise. So what is this GPU clk driver for then? > > But that said: traditionally we've expected that the clock driver correctly > clamp the requested rate to the correct values. In the past we have taken > advantage of this and we may in the future. I don't think it is reasonable > to require the leaf driver to only pass "approved" frequencies especially > since we depend on our own OPP table that may or may not be similar to the > one used by the clock driver. > Ok. Sounds like things can't be kept in sync between the clk driver and the OPP tables. Why is that hard to do? Either way, I'd be fine if the code actually used the frequency limits to round the rate to something within range, but I don't recall seeing that being done here. So if the min/max limits stay, the clk driver should round to within that range.
Re: [PATCH 4.4 00/12] 4.4.147-stable review
On 8 August 2018 at 00:22, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.147 release. > There are 12 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:34 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.147-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm and x86_64. Summary kernel: 4.4.147-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: ed5153769cba52b60a0c6210cb1ac41843f37200 git describe: v4.4.146-13-ged5153769cba Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.146-13-ged5153769cba No regressions (compared to build v4.4.146-12-gdb3e08ea00d0) Ran 12163 total tests in the following environments and test suites. Environments -- - juno-r2 - arm64 - qemu_arm - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none Summary kernel: 4.4.147-rc1 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git branch: 4.4.147-rc1-hikey-20180807-254 git commit: a7af4a3cb7756f8a159f54cb757f30764f3d5166 git describe: 4.4.147-rc1-hikey-20180807-254 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.147-rc1-hikey-20180807-254 No regressions (compared to build 4.4.147-rc1-hikey-20180807-253) Ran 2705 total tests in the following environments and test suites. Environments -- - hi6220-hikey - arm64 - qemu_arm64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v3] locking/rwsem: Exit read lock slowpath if queue empty & no writer
On 07/24/2018 03:10 PM, Waiman Long wrote:
> It was discovered that a constant stream of readers with occassional
> writers pounding on a rwsem may cause many of the readers to enter the
> slowpath unnecessarily thus increasing latency and lowering performance.
>
> In the current code, a reader entering the slowpath critical section
> will unconditionally set the WAITING_BIAS, if not set yet, and clear
> its active count even if no one is in the wait queue and no writer
> is present. This causes some incoming readers to observe the presence
> of waiters in the wait queue and hence have to go into the slowpath
> themselves.
>
> With sufficient numbers of readers and a relatively short lock hold time,
> the WAITING_BIAS may be repeatedly turned on and off and a substantial
> portion of the readers will go into the slowpath sustaining a rather
> long queue in the wait queue spinlock and repeated WAITING_BIAS on/off
> cycle until the logjam is broken opportunistically.
>
> To avoid this situation from happening, an additional check is added to
> detect the special case that the reader in the critical section is the
> only one in the wait queue and no writer is present. When that happens,
> it can just exit the slowpath and return immediately as its active count
> has already been set in the lock. Other incoming readers won't observe
> the presence of waiters and so will not be forced into the slowpath.
>
> The issue was found in a customer site where they had an application
> that pounded on the pread64 syscalls heavily on an XFS filesystem. The
> application was run in a recent 4-socket boxes with a lot of CPUs. They
> saw significant spinlock contention in the rwsem_down_read_failed() call.
> With this patch applied, the system CPU usage went down from 85% to 57%,
> and the spinlock contention in the pread64 syscalls was gone.
>
> v3: Revise the commit log and comment again.
> v2: Add customer testing results and remove wording that may cause
> confusion.
>
> Signed-off-by: Waiman Long
> ---
> kernel/locking/rwsem-xadd.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
> index 3064c50..01fcb80 100644
> --- a/kernel/locking/rwsem-xadd.c
> +++ b/kernel/locking/rwsem-xadd.c
> @@ -233,8 +233,19 @@ static void __rwsem_mark_wake(struct rw_semaphore *sem,
> waiter.type = RWSEM_WAITING_FOR_READ;
>
> raw_spin_lock_irq(>wait_lock);
> - if (list_empty(>wait_list))
> + if (list_empty(>wait_list)) {
> + /*
> + * In case the wait queue is empty and the lock isn't owned
> + * by a writer, this reader can exit the slowpath and return
> + * immediately as its RWSEM_ACTIVE_READ_BIAS has already
> + * been set in the count.
> + */
> + if (atomic_long_read(>count) >= 0) {
> + raw_spin_unlock_irq(>wait_lock);
> + return sem;
> + }
> adjustment += RWSEM_WAITING_BIAS;
> + }
> list_add_tail(, >wait_list);
>
> /* we're now waiting on the lock, but no longer actively locking */
Will this patch be eligible to go into 4.19 or 4.20?
Thanks,
Longman
Re: [PATCH v3] locking/rwsem: Exit read lock slowpath if queue empty & no writer
On 07/24/2018 03:10 PM, Waiman Long wrote:
> It was discovered that a constant stream of readers with occassional
> writers pounding on a rwsem may cause many of the readers to enter the
> slowpath unnecessarily thus increasing latency and lowering performance.
>
> In the current code, a reader entering the slowpath critical section
> will unconditionally set the WAITING_BIAS, if not set yet, and clear
> its active count even if no one is in the wait queue and no writer
> is present. This causes some incoming readers to observe the presence
> of waiters in the wait queue and hence have to go into the slowpath
> themselves.
>
> With sufficient numbers of readers and a relatively short lock hold time,
> the WAITING_BIAS may be repeatedly turned on and off and a substantial
> portion of the readers will go into the slowpath sustaining a rather
> long queue in the wait queue spinlock and repeated WAITING_BIAS on/off
> cycle until the logjam is broken opportunistically.
>
> To avoid this situation from happening, an additional check is added to
> detect the special case that the reader in the critical section is the
> only one in the wait queue and no writer is present. When that happens,
> it can just exit the slowpath and return immediately as its active count
> has already been set in the lock. Other incoming readers won't observe
> the presence of waiters and so will not be forced into the slowpath.
>
> The issue was found in a customer site where they had an application
> that pounded on the pread64 syscalls heavily on an XFS filesystem. The
> application was run in a recent 4-socket boxes with a lot of CPUs. They
> saw significant spinlock contention in the rwsem_down_read_failed() call.
> With this patch applied, the system CPU usage went down from 85% to 57%,
> and the spinlock contention in the pread64 syscalls was gone.
>
> v3: Revise the commit log and comment again.
> v2: Add customer testing results and remove wording that may cause
> confusion.
>
> Signed-off-by: Waiman Long
> ---
> kernel/locking/rwsem-xadd.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
> index 3064c50..01fcb80 100644
> --- a/kernel/locking/rwsem-xadd.c
> +++ b/kernel/locking/rwsem-xadd.c
> @@ -233,8 +233,19 @@ static void __rwsem_mark_wake(struct rw_semaphore *sem,
> waiter.type = RWSEM_WAITING_FOR_READ;
>
> raw_spin_lock_irq(>wait_lock);
> - if (list_empty(>wait_list))
> + if (list_empty(>wait_list)) {
> + /*
> + * In case the wait queue is empty and the lock isn't owned
> + * by a writer, this reader can exit the slowpath and return
> + * immediately as its RWSEM_ACTIVE_READ_BIAS has already
> + * been set in the count.
> + */
> + if (atomic_long_read(>count) >= 0) {
> + raw_spin_unlock_irq(>wait_lock);
> + return sem;
> + }
> adjustment += RWSEM_WAITING_BIAS;
> + }
> list_add_tail(, >wait_list);
>
> /* we're now waiting on the lock, but no longer actively locking */
Will this patch be eligible to go into 4.19 or 4.20?
Thanks,
Longman
Re: [PATCH 4.4 00/12] 4.4.147-stable review
On 8 August 2018 at 00:22, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.147 release. > There are 12 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:34 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.147-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm and x86_64. Summary kernel: 4.4.147-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: ed5153769cba52b60a0c6210cb1ac41843f37200 git describe: v4.4.146-13-ged5153769cba Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.146-13-ged5153769cba No regressions (compared to build v4.4.146-12-gdb3e08ea00d0) Ran 12163 total tests in the following environments and test suites. Environments -- - juno-r2 - arm64 - qemu_arm - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none Summary kernel: 4.4.147-rc1 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git branch: 4.4.147-rc1-hikey-20180807-254 git commit: a7af4a3cb7756f8a159f54cb757f30764f3d5166 git describe: 4.4.147-rc1-hikey-20180807-254 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.147-rc1-hikey-20180807-254 No regressions (compared to build 4.4.147-rc1-hikey-20180807-253) Ran 2705 total tests in the following environments and test suites. Environments -- - hi6220-hikey - arm64 - qemu_arm64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests -- Linaro LKFT https://lkft.linaro.org
[GIT PULL] FSI fixes for 4.19
Hi Greg ! This adds two FSI fixes to what you already have in your tree - Fix a NULL dereference in the scom driver - Fix a command buffer size issue in the sbefifo driver that breaks some operations with POWER system debugger (cronus) Cheers, Ben. The following changes since tag fsi-updates-2018-07-27: fsi: Prevent multiple concurrent rescans (2018-07-27 09:58:12 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/linux-fsi.git tags/fsi-updates-2018-08-08 for you to fetch changes up to 15e2a7218c2788d79c566d17cb9428c221e7: fsi: sbefifo: Bump max command length (2018-08-08 15:44:47 +1000) Benjamin Herrenschmidt (2): fsi: scom: Fix NULL dereference fsi: sbefifo: Bump max command length drivers/fsi/fsi-sbefifo.c | 39 --- drivers/fsi/fsi-scom.c| 1 + 2 files changed, 33 insertions(+), 7 deletions(-)
[GIT PULL] FSI fixes for 4.19
Hi Greg ! This adds two FSI fixes to what you already have in your tree - Fix a NULL dereference in the scom driver - Fix a command buffer size issue in the sbefifo driver that breaks some operations with POWER system debugger (cronus) Cheers, Ben. The following changes since tag fsi-updates-2018-07-27: fsi: Prevent multiple concurrent rescans (2018-07-27 09:58:12 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/linux-fsi.git tags/fsi-updates-2018-08-08 for you to fetch changes up to 15e2a7218c2788d79c566d17cb9428c221e7: fsi: sbefifo: Bump max command length (2018-08-08 15:44:47 +1000) Benjamin Herrenschmidt (2): fsi: scom: Fix NULL dereference fsi: sbefifo: Bump max command length drivers/fsi/fsi-sbefifo.c | 39 --- drivers/fsi/fsi-scom.c| 1 + 2 files changed, 33 insertions(+), 7 deletions(-)
Re: [PATCH v2 02/18] clk: intel: Add clock driver for Intel MIPS SoCs
Quoting Songjun Wu (2018-08-02 20:02:21)
> From: Yixin Zhu
>
> This driver provides PLL clock registration as well as various clock
> branches, e.g. MUX clock, gate clock, divider clock and so on.
>
> PLLs that provide clock to DDR, CPU and peripherals are shown below:
>
> +-+
> |--->| LCPLL3 0|--PCIe clk-->
>XO |+-+
> +---|
> |+-+
> ||3|--PAE clk-->
> |--->| PLL0B 2|--GSWIP clk-->
> ||1|--DDR clk-->DDR PHY clk-->
> ||0|--CPU1 clk--+ +-+
> |+-+|--->0|
> | | MUX |--CPU clk-->
> |+-+|--->1|
> ||0|--CPU0 clk--+ +-+
> |--->| PLLOA 1|--SSX4 clk-->
> |2|--NGI clk-->
> |3|--CBM clk-->
> +-+
Thanks for the picture!
>
> Signed-off-by: Yixin Zhu
> Signed-off-by: Songjun Wu
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 0bb25dd009d1..d929ca4607cf 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -72,6 +72,9 @@ obj-$(CONFIG_ARCH_HISI) += hisilicon/
> obj-y += imgtec/
> obj-$(CONFIG_ARCH_MXC) += imx/
> obj-$(CONFIG_MACH_INGENIC) += ingenic/
> +ifeq ($(CONFIG_COMMON_CLK), y)
> +obj-y +=intel/
> +endif
Why not obj-$(CONFIG_INTEL_CCF) or something like that?
> obj-$(CONFIG_ARCH_KEYSTONE)+= keystone/
> obj-$(CONFIG_MACH_LOONGSON32) += loongson1/
> obj-y += mediatek/
> diff --git a/drivers/clk/intel/Kconfig b/drivers/clk/intel/Kconfig
> new file mode 100644
> index ..c7d3fb1721fa
> --- /dev/null
> +++ b/drivers/clk/intel/Kconfig
> @@ -0,0 +1,20 @@
> +# SPDX-License-Identifier: GPL-2.0
> +config INTEL_CGU_CLK
> + depends on COMMON_CLK
> + depends on INTEL_MIPS || COMPILE_TEST
> + select MFD_SYSCON
> + bool "Intel clock controller support"
> + help
> + This driver support Intel CGU (Clock Generation Unit).
Is it really called a clock generation unit? Or that's just copied from
sunxi driver?
> +
> +choice
> + prompt "SoC platform selection"
> + depends on INTEL_CGU_CLK
> + default INTEL_GRX500_CGU_CLK
> +
> +config INTEL_GRX500_CGU_CLK
> + bool "GRX500 CLK"
> + help
> + Clock driver of GRX500 platform.
> +
> +endchoice
> diff --git a/drivers/clk/intel/Makefile b/drivers/clk/intel/Makefile
> new file mode 100644
> index ..16a0138e52c2
> --- /dev/null
> +++ b/drivers/clk/intel/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0
> +# Makefile for intel specific clk
> +
> +obj-$(CONFIG_INTEL_CGU_CLK) += clk-cgu.o clk-cgu-pll.o
> +ifneq ($(CONFIG_INTEL_GRX500_CGU_CLK),)
> + obj-y += clk-grx500.o
> +endif
> diff --git a/drivers/clk/intel/clk-cgu-pll.c b/drivers/clk/intel/clk-cgu-pll.c
> new file mode 100644
> index ..20759bc27e95
> --- /dev/null
> +++ b/drivers/clk/intel/clk-cgu-pll.c
> @@ -0,0 +1,166 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 Intel Corporation.
> + * Zhu YiXin
> + */
> +
> +#include
Is this include used?
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "clk-cgu-pll.h"
> +#include "clk-cgu.h"
> +
> +#define to_intel_clk_pll(_hw) container_of(_hw, struct intel_clk_pll, hw)
> +
> +/*
> + * Calculate formula:
> + * rate = (prate * mult + (prate * frac) / frac_div) / div
> + */
> +static unsigned long
> +intel_pll_calc_rate(unsigned long prate, unsigned int mult,
> + unsigned int div, unsigned int frac,
> + unsigned int frac_div)
> +{
> + u64 crate, frate, rate64;
> +
> + rate64 = prate;
> + crate = rate64 * mult;
> +
> + if (frac) {
> + frate = rate64 * frac;
> + do_div(frate, frac_div);
> + crate += frate;
> + }
> + do_div(crate, div);
> +
> + return (unsigned long)crate;
> +}
> +
> +static void
> +grx500_pll_get_params(struct intel_clk_pll *pll, unsigned int *mult,
> + unsigned int *frac)
> +{
> + *mult = intel_get_clk_val(pll->map, pll->reg, 2, 7);
> + *frac = intel_get_clk_val(pll->map, pll->reg, 9, 21);
> +}
> +
> +static int intel_wait_pll_lock(struct intel_clk_pll *pll, int bit_idx)
> +{
> + unsigned int val;
> +
> + return regmap_read_poll_timeout(pll->map, pll->reg, val,
> + val & BIT(bit_idx), 10, 1000);
> +}
> +
> +static unsigned long
> +intel_grx500_pll_recalc_rate(struct clk_hw *hw, unsigned long prate)
> +{
> + struct
Re: [PATCH v2 02/18] clk: intel: Add clock driver for Intel MIPS SoCs
Quoting Songjun Wu (2018-08-02 20:02:21)
> From: Yixin Zhu
>
> This driver provides PLL clock registration as well as various clock
> branches, e.g. MUX clock, gate clock, divider clock and so on.
>
> PLLs that provide clock to DDR, CPU and peripherals are shown below:
>
> +-+
> |--->| LCPLL3 0|--PCIe clk-->
>XO |+-+
> +---|
> |+-+
> ||3|--PAE clk-->
> |--->| PLL0B 2|--GSWIP clk-->
> ||1|--DDR clk-->DDR PHY clk-->
> ||0|--CPU1 clk--+ +-+
> |+-+|--->0|
> | | MUX |--CPU clk-->
> |+-+|--->1|
> ||0|--CPU0 clk--+ +-+
> |--->| PLLOA 1|--SSX4 clk-->
> |2|--NGI clk-->
> |3|--CBM clk-->
> +-+
Thanks for the picture!
>
> Signed-off-by: Yixin Zhu
> Signed-off-by: Songjun Wu
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 0bb25dd009d1..d929ca4607cf 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -72,6 +72,9 @@ obj-$(CONFIG_ARCH_HISI) += hisilicon/
> obj-y += imgtec/
> obj-$(CONFIG_ARCH_MXC) += imx/
> obj-$(CONFIG_MACH_INGENIC) += ingenic/
> +ifeq ($(CONFIG_COMMON_CLK), y)
> +obj-y +=intel/
> +endif
Why not obj-$(CONFIG_INTEL_CCF) or something like that?
> obj-$(CONFIG_ARCH_KEYSTONE)+= keystone/
> obj-$(CONFIG_MACH_LOONGSON32) += loongson1/
> obj-y += mediatek/
> diff --git a/drivers/clk/intel/Kconfig b/drivers/clk/intel/Kconfig
> new file mode 100644
> index ..c7d3fb1721fa
> --- /dev/null
> +++ b/drivers/clk/intel/Kconfig
> @@ -0,0 +1,20 @@
> +# SPDX-License-Identifier: GPL-2.0
> +config INTEL_CGU_CLK
> + depends on COMMON_CLK
> + depends on INTEL_MIPS || COMPILE_TEST
> + select MFD_SYSCON
> + bool "Intel clock controller support"
> + help
> + This driver support Intel CGU (Clock Generation Unit).
Is it really called a clock generation unit? Or that's just copied from
sunxi driver?
> +
> +choice
> + prompt "SoC platform selection"
> + depends on INTEL_CGU_CLK
> + default INTEL_GRX500_CGU_CLK
> +
> +config INTEL_GRX500_CGU_CLK
> + bool "GRX500 CLK"
> + help
> + Clock driver of GRX500 platform.
> +
> +endchoice
> diff --git a/drivers/clk/intel/Makefile b/drivers/clk/intel/Makefile
> new file mode 100644
> index ..16a0138e52c2
> --- /dev/null
> +++ b/drivers/clk/intel/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0
> +# Makefile for intel specific clk
> +
> +obj-$(CONFIG_INTEL_CGU_CLK) += clk-cgu.o clk-cgu-pll.o
> +ifneq ($(CONFIG_INTEL_GRX500_CGU_CLK),)
> + obj-y += clk-grx500.o
> +endif
> diff --git a/drivers/clk/intel/clk-cgu-pll.c b/drivers/clk/intel/clk-cgu-pll.c
> new file mode 100644
> index ..20759bc27e95
> --- /dev/null
> +++ b/drivers/clk/intel/clk-cgu-pll.c
> @@ -0,0 +1,166 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 Intel Corporation.
> + * Zhu YiXin
> + */
> +
> +#include
Is this include used?
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "clk-cgu-pll.h"
> +#include "clk-cgu.h"
> +
> +#define to_intel_clk_pll(_hw) container_of(_hw, struct intel_clk_pll, hw)
> +
> +/*
> + * Calculate formula:
> + * rate = (prate * mult + (prate * frac) / frac_div) / div
> + */
> +static unsigned long
> +intel_pll_calc_rate(unsigned long prate, unsigned int mult,
> + unsigned int div, unsigned int frac,
> + unsigned int frac_div)
> +{
> + u64 crate, frate, rate64;
> +
> + rate64 = prate;
> + crate = rate64 * mult;
> +
> + if (frac) {
> + frate = rate64 * frac;
> + do_div(frate, frac_div);
> + crate += frate;
> + }
> + do_div(crate, div);
> +
> + return (unsigned long)crate;
> +}
> +
> +static void
> +grx500_pll_get_params(struct intel_clk_pll *pll, unsigned int *mult,
> + unsigned int *frac)
> +{
> + *mult = intel_get_clk_val(pll->map, pll->reg, 2, 7);
> + *frac = intel_get_clk_val(pll->map, pll->reg, 9, 21);
> +}
> +
> +static int intel_wait_pll_lock(struct intel_clk_pll *pll, int bit_idx)
> +{
> + unsigned int val;
> +
> + return regmap_read_poll_timeout(pll->map, pll->reg, val,
> + val & BIT(bit_idx), 10, 1000);
> +}
> +
> +static unsigned long
> +intel_grx500_pll_recalc_rate(struct clk_hw *hw, unsigned long prate)
> +{
> + struct
[PATCH] PCI: Fix calculation of bridge window's size
There are some 0 resource size pci devices, and it leads to the
accumulator fails to maintain the correct value.
It results in a strange issue on my machine that xhci_hcd failed to init.
[2.437278] xhci_hcd :05:00.0: init :05:00.0 fail, -16
[2.437300] xhci_hcd: probe of :05:00.0 failed with error -16
To fix this, check if the resource size equals to 0, doesn't increase size.
Fixes: c9c75143a596 ("PCI: Fix calculation of bridge window's size and
alignment")
CC: sta...@vger.kernel.org # 4.14+
Signed-off-by: AceLan Kao
---
drivers/pci/setup-bus.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 79b1824e83b4..ae05dde8c6e3 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1061,7 +1061,8 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned
long mask,
r->flags = 0;
continue;
}
- size += max(r_size, align);
+ if (r_size != 0)
+ size += max(r_size, align);
/* Exclude ranges with size > align from
calculation of the alignment. */
if (r_size <= align)
--
2.17.1
[PATCH] PCI: Fix calculation of bridge window's size
There are some 0 resource size pci devices, and it leads to the
accumulator fails to maintain the correct value.
It results in a strange issue on my machine that xhci_hcd failed to init.
[2.437278] xhci_hcd :05:00.0: init :05:00.0 fail, -16
[2.437300] xhci_hcd: probe of :05:00.0 failed with error -16
To fix this, check if the resource size equals to 0, doesn't increase size.
Fixes: c9c75143a596 ("PCI: Fix calculation of bridge window's size and
alignment")
CC: sta...@vger.kernel.org # 4.14+
Signed-off-by: AceLan Kao
---
drivers/pci/setup-bus.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 79b1824e83b4..ae05dde8c6e3 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1061,7 +1061,8 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned
long mask,
r->flags = 0;
continue;
}
- size += max(r_size, align);
+ if (r_size != 0)
+ size += max(r_size, align);
/* Exclude ranges with size > align from
calculation of the alignment. */
if (r_size <= align)
--
2.17.1
Re: [PATCH 0/2] x86/intel_rdt and perf/x86: Fix lack of coordination with perf
Hi Tony, On 8/7/2018 6:28 PM, Luck, Tony wrote: > Would it help to call routines to read the "before" values of the counter > twice. The first time to preload the cache with anything needed to execute > the perf code path. >>> In an attempt to improve the accuracy of the above I modified it to the >>> following: >>> >>> /* create the two events as before in "enabled" state */ >>> l2_hit_pmcnum = l2_hit_event->hw.event_base_rdpmc; >>> l2_miss_pmcnum = l2_miss_event->hw.event_base_rdpmc; >>> local_irq_disable(); >>> /* disable hw prefetchers */ >>> /* init local vars to loop through pseudo-locked mem > * may take some misses in the perf code > */ > l2_hits_before = native_read_pmc(l2_hit_pmcnum); > l2_miss_before = native_read_pmc(l2_miss_pmcnum); > /* Read counters again, hope no new misses here */ >>> l2_hits_before = native_read_pmc(l2_hit_pmcnum); >>> l2_miss_before = native_read_pmc(l2_miss_pmcnum); >>> /* loop through pseudo-locked mem */ >>> l2_hits_after = native_read_pmc(l2_hit_pmcnum); >>> l2_miss_after = native_read_pmc(l2_miss_pmcnum); >>> /* enable hw prefetchers */ >>> local_irq_enable(); > The end of my previous email to Peter contains a solution that does address all the feedback received up to this point while also able to obtain (what I thought to be ... more below) accurate results. The code you comment on below is not this latest version but your suggestion is valuable and I do try it out on two different ways from what you quote below to read the perf data. So, instead of reading data with native_read_pmc() as in the code you quoted I first test when reading data twice using the original recommendation of "perf_event_read_local()" and second when reading data twice using "rdpmcl()" chosen instead of native_read_pmc(). First, reading data using perf_event_read_local() called twice. When testing as follows: /* create perf events */ /* disable irq */ /* disable hw prefetchers */ /* init local vars */ /* read before data twice as follows: */ perf_event_read_local(l2_hit_event, _hits_before, NULL, NULL); perf_event_read_local(l2_miss_event, _miss_before, NULL, NULL); perf_event_read_local(l2_hit_event, _hits_before, NULL, NULL); perf_event_read_local(l2_miss_event, _miss_before, NULL, NULL); /* read through pseudo-locked memory */ perf_event_read_local(l2_hit_event, _hits_after, NULL, NULL); perf_event_read_local(l2_miss_event, _miss_after, NULL, NULL); /* re enable hw prefetchers */ /* enable irq */ /* write data to tracepoint */ With the above I am not able to obtain accurate data: pseudo_lock_mea-351 [002] 61.859147: pseudo_lock_l2: hits=4109 miss=0 pseudo_lock_mea-354 [002] 63.045734: pseudo_lock_l2: hits=4103 miss=6 pseudo_lock_mea-357 [002] 64.104673: pseudo_lock_l2: hits=4106 miss=3 pseudo_lock_mea-360 [002] 65.174775: pseudo_lock_l2: hits=4105 miss=5 pseudo_lock_mea-367 [002] 66.232308: pseudo_lock_l2: hits=4104 miss=5 pseudo_lock_mea-370 [002] 67.291844: pseudo_lock_l2: hits=4103 miss=6 pseudo_lock_mea-373 [002] 68.348725: pseudo_lock_l2: hits=4105 miss=5 pseudo_lock_mea-376 [002] 69.409738: pseudo_lock_l2: hits=4105 miss=5 pseudo_lock_mea-379 [002] 70.466763: pseudo_lock_l2: hits=4105 miss=5 Second, reading data using rdpmcl() called twice. This is the same solution as documented in my previous email, with the two extra rdpmcl() calls added. An overview of the flow: /* create perf events */ /* disable irq */ /* check perf event error state */ /* disable hw prefetchers */ /* init local vars */ /* read before data twice as follows: */ rdpmcl(l2_hit_pmcnum, l2_hits_before); rdpmcl(l2_miss_pmcnum, l2_miss_before); rdpmcl(l2_hit_pmcnum, l2_hits_before); rdpmcl(l2_miss_pmcnum, l2_miss_before); /* read through pseudo-locked memory */ rdpmcl(l2_hit_pmcnum, l2_hits_after); rdpmcl(l2_miss_pmcnum, l2_miss_after); /* re enable hw prefetchers */ /* enable irq */ /* write data to tracepoint */ Here as expected a simple test showed that the data was accurate (hits=4096 miss=0) so I repeated the creation and measurement of pseudo-locked region at different sizes under different loads. Each possible pseudo-lock region size is created and measured 100 times on an idle system and 100 times on a system with a noisy neighbor - this resulted in a total of 2800 pseudo-lock region creations each followed by a measurement of that region. The results of these tests are the best I have yet seen. In this total of 2800 measurements the number of cache hits were miscounted only in eight measurements - each miscount was under(?) counted with one. Specifically, a memory region consisting of 8192 cache lines was measured as "hits=8191 miss=0", three memory regions with 12288 cache lines were measured as "hits=12287 miss=0", two memory regions with 10240 cache lines were measured as "hits=10239 miss=0", and two memory regions with 14336 cache lines were measured as "hits=14335 miss=0". I
Re: [PATCH 0/2] x86/intel_rdt and perf/x86: Fix lack of coordination with perf
Hi Tony, On 8/7/2018 6:28 PM, Luck, Tony wrote: > Would it help to call routines to read the "before" values of the counter > twice. The first time to preload the cache with anything needed to execute > the perf code path. >>> In an attempt to improve the accuracy of the above I modified it to the >>> following: >>> >>> /* create the two events as before in "enabled" state */ >>> l2_hit_pmcnum = l2_hit_event->hw.event_base_rdpmc; >>> l2_miss_pmcnum = l2_miss_event->hw.event_base_rdpmc; >>> local_irq_disable(); >>> /* disable hw prefetchers */ >>> /* init local vars to loop through pseudo-locked mem > * may take some misses in the perf code > */ > l2_hits_before = native_read_pmc(l2_hit_pmcnum); > l2_miss_before = native_read_pmc(l2_miss_pmcnum); > /* Read counters again, hope no new misses here */ >>> l2_hits_before = native_read_pmc(l2_hit_pmcnum); >>> l2_miss_before = native_read_pmc(l2_miss_pmcnum); >>> /* loop through pseudo-locked mem */ >>> l2_hits_after = native_read_pmc(l2_hit_pmcnum); >>> l2_miss_after = native_read_pmc(l2_miss_pmcnum); >>> /* enable hw prefetchers */ >>> local_irq_enable(); > The end of my previous email to Peter contains a solution that does address all the feedback received up to this point while also able to obtain (what I thought to be ... more below) accurate results. The code you comment on below is not this latest version but your suggestion is valuable and I do try it out on two different ways from what you quote below to read the perf data. So, instead of reading data with native_read_pmc() as in the code you quoted I first test when reading data twice using the original recommendation of "perf_event_read_local()" and second when reading data twice using "rdpmcl()" chosen instead of native_read_pmc(). First, reading data using perf_event_read_local() called twice. When testing as follows: /* create perf events */ /* disable irq */ /* disable hw prefetchers */ /* init local vars */ /* read before data twice as follows: */ perf_event_read_local(l2_hit_event, _hits_before, NULL, NULL); perf_event_read_local(l2_miss_event, _miss_before, NULL, NULL); perf_event_read_local(l2_hit_event, _hits_before, NULL, NULL); perf_event_read_local(l2_miss_event, _miss_before, NULL, NULL); /* read through pseudo-locked memory */ perf_event_read_local(l2_hit_event, _hits_after, NULL, NULL); perf_event_read_local(l2_miss_event, _miss_after, NULL, NULL); /* re enable hw prefetchers */ /* enable irq */ /* write data to tracepoint */ With the above I am not able to obtain accurate data: pseudo_lock_mea-351 [002] 61.859147: pseudo_lock_l2: hits=4109 miss=0 pseudo_lock_mea-354 [002] 63.045734: pseudo_lock_l2: hits=4103 miss=6 pseudo_lock_mea-357 [002] 64.104673: pseudo_lock_l2: hits=4106 miss=3 pseudo_lock_mea-360 [002] 65.174775: pseudo_lock_l2: hits=4105 miss=5 pseudo_lock_mea-367 [002] 66.232308: pseudo_lock_l2: hits=4104 miss=5 pseudo_lock_mea-370 [002] 67.291844: pseudo_lock_l2: hits=4103 miss=6 pseudo_lock_mea-373 [002] 68.348725: pseudo_lock_l2: hits=4105 miss=5 pseudo_lock_mea-376 [002] 69.409738: pseudo_lock_l2: hits=4105 miss=5 pseudo_lock_mea-379 [002] 70.466763: pseudo_lock_l2: hits=4105 miss=5 Second, reading data using rdpmcl() called twice. This is the same solution as documented in my previous email, with the two extra rdpmcl() calls added. An overview of the flow: /* create perf events */ /* disable irq */ /* check perf event error state */ /* disable hw prefetchers */ /* init local vars */ /* read before data twice as follows: */ rdpmcl(l2_hit_pmcnum, l2_hits_before); rdpmcl(l2_miss_pmcnum, l2_miss_before); rdpmcl(l2_hit_pmcnum, l2_hits_before); rdpmcl(l2_miss_pmcnum, l2_miss_before); /* read through pseudo-locked memory */ rdpmcl(l2_hit_pmcnum, l2_hits_after); rdpmcl(l2_miss_pmcnum, l2_miss_after); /* re enable hw prefetchers */ /* enable irq */ /* write data to tracepoint */ Here as expected a simple test showed that the data was accurate (hits=4096 miss=0) so I repeated the creation and measurement of pseudo-locked region at different sizes under different loads. Each possible pseudo-lock region size is created and measured 100 times on an idle system and 100 times on a system with a noisy neighbor - this resulted in a total of 2800 pseudo-lock region creations each followed by a measurement of that region. The results of these tests are the best I have yet seen. In this total of 2800 measurements the number of cache hits were miscounted only in eight measurements - each miscount was under(?) counted with one. Specifically, a memory region consisting of 8192 cache lines was measured as "hits=8191 miss=0", three memory regions with 12288 cache lines were measured as "hits=12287 miss=0", two memory regions with 10240 cache lines were measured as "hits=10239 miss=0", and two memory regions with 14336 cache lines were measured as "hits=14335 miss=0". I
Re: [PATCH v2] resource: Merge resources on a node when hot-adding memory
On Tue, Aug 7, 2018 at 9:52 PM, Vlastimil Babka wrote:
> On 08/06/2018 08:52 AM, Rashmica Gupta wrote:
>> When hot-removing memory release_mem_region_adjustable() splits
>> iomem resources if they are not the exact size of the memory being
>> hot-deleted. Adding this memory back to the kernel adds a new
>> resource.
>>
>> Eg a node has memory 0x0 - 0xf. Offlining and hot-removing
>> 1GB from 0xf4000 results in the single resource 0x0-0xf being
>> split into two resources: 0x0-0xf3fff and 0xf8000-0xf.
>>
>> When we hot-add the memory back we now have three resources:
>> 0x0-0xf3fff, 0xf4000-0xf7fff, and 0xf8000-0xf.
>>
>> Now if we try to remove a section of memory that overlaps these resources,
>> like 2GB from 0xf4000, release_mem_region_adjustable() fails as it
>> expects the chunk of memory to be within the boundaries of a single
>> resource.
>
> Hi,
>
> it's the first time I see the resource code, so I might be easily wrong.
> How can it happen that the second remove is section aligned but the
> first one not?
>
I probably shouldn't have used that word... When I said "a section of memory"
I really meant "a chunk of memory" or "some memory".
>> This patch adds a function request_resource_and_merge(). This is called
>> instead of request_resource_conflict() when registering a resource in
>> add_memory(). It calls request_resource_conflict() and if hot-removing is
>> enabled (if it isn't we won't get resource fragmentation) we attempt to
>> merge contiguous resources on the node.
>>
>> Signed-off-by: Rashmica Gupta
> ...
>> --- a/kernel/resource.c
>> +++ b/kernel/resource.c
> ...
>> +/*
>> + * Attempt to merge resources on the node
>> + */
>> +static void merge_node_resources(int nid, struct resource *parent)
>> +{
>> + struct resource *res;
>> + uint64_t start_addr;
>> + uint64_t end_addr;
>> + int ret;
>> +
>> + start_addr = node_start_pfn(nid) << PAGE_SHIFT;
>> + end_addr = node_end_pfn(nid) << PAGE_SHIFT;
>> +
>> + write_lock(_lock);
>> +
>> + /* Get the first resource */
>> + res = parent->child;
>> +
>> + while (res) {
>> + /* Check that the resource is within the node */
>> + if (res->start < start_addr) {
>> + res = res->sibling;
>> + continue;
>> + }
>> + /* Exit if resource is past end of node */
>> + if (res->sibling->end > end_addr)
>> + break;
>
> IIUC, resource end is closed, so adjacent resources's start is end+1.
> But node_end_pfn is open, so the comparison above should use '>='
> instead of '>'?
You are right. Thanks for spotting that.
>
>> +
>> + ret = merge_resources(res);
>> + if (!ret)
>> + continue;
>> + res = res->sibling;
>
> Should this rather use next_resource() to merge at all levels of the
> hierarchy? Although memory seems to be flat under _resource so it
> would be just future-proofing.
I don't know enough about the hierarchy and layout of resources to comment on
this.
>
> Thanks,
> Vlastimil
Re: [PATCH v2] resource: Merge resources on a node when hot-adding memory
On Tue, Aug 7, 2018 at 9:52 PM, Vlastimil Babka wrote:
> On 08/06/2018 08:52 AM, Rashmica Gupta wrote:
>> When hot-removing memory release_mem_region_adjustable() splits
>> iomem resources if they are not the exact size of the memory being
>> hot-deleted. Adding this memory back to the kernel adds a new
>> resource.
>>
>> Eg a node has memory 0x0 - 0xf. Offlining and hot-removing
>> 1GB from 0xf4000 results in the single resource 0x0-0xf being
>> split into two resources: 0x0-0xf3fff and 0xf8000-0xf.
>>
>> When we hot-add the memory back we now have three resources:
>> 0x0-0xf3fff, 0xf4000-0xf7fff, and 0xf8000-0xf.
>>
>> Now if we try to remove a section of memory that overlaps these resources,
>> like 2GB from 0xf4000, release_mem_region_adjustable() fails as it
>> expects the chunk of memory to be within the boundaries of a single
>> resource.
>
> Hi,
>
> it's the first time I see the resource code, so I might be easily wrong.
> How can it happen that the second remove is section aligned but the
> first one not?
>
I probably shouldn't have used that word... When I said "a section of memory"
I really meant "a chunk of memory" or "some memory".
>> This patch adds a function request_resource_and_merge(). This is called
>> instead of request_resource_conflict() when registering a resource in
>> add_memory(). It calls request_resource_conflict() and if hot-removing is
>> enabled (if it isn't we won't get resource fragmentation) we attempt to
>> merge contiguous resources on the node.
>>
>> Signed-off-by: Rashmica Gupta
> ...
>> --- a/kernel/resource.c
>> +++ b/kernel/resource.c
> ...
>> +/*
>> + * Attempt to merge resources on the node
>> + */
>> +static void merge_node_resources(int nid, struct resource *parent)
>> +{
>> + struct resource *res;
>> + uint64_t start_addr;
>> + uint64_t end_addr;
>> + int ret;
>> +
>> + start_addr = node_start_pfn(nid) << PAGE_SHIFT;
>> + end_addr = node_end_pfn(nid) << PAGE_SHIFT;
>> +
>> + write_lock(_lock);
>> +
>> + /* Get the first resource */
>> + res = parent->child;
>> +
>> + while (res) {
>> + /* Check that the resource is within the node */
>> + if (res->start < start_addr) {
>> + res = res->sibling;
>> + continue;
>> + }
>> + /* Exit if resource is past end of node */
>> + if (res->sibling->end > end_addr)
>> + break;
>
> IIUC, resource end is closed, so adjacent resources's start is end+1.
> But node_end_pfn is open, so the comparison above should use '>='
> instead of '>'?
You are right. Thanks for spotting that.
>
>> +
>> + ret = merge_resources(res);
>> + if (!ret)
>> + continue;
>> + res = res->sibling;
>
> Should this rather use next_resource() to merge at all levels of the
> hierarchy? Although memory seems to be flat under _resource so it
> would be just future-proofing.
I don't know enough about the hierarchy and layout of resources to comment on
this.
>
> Thanks,
> Vlastimil
Re: [PATCH RFC 00/10] Introduce lockless shrink_slab()
On Tue, Aug 7, 2018 at 6:12 PM Stephen Rothwell wrote: > > Hi Kirill, > > On Tue, 07 Aug 2018 18:37:19 +0300 Kirill Tkhai wrote: > > > > After bitmaps of not-empty memcg shrinkers were implemented > > (see "[PATCH v9 00/17] Improve shrink_slab() scalability..." > > series, which is already in mm tree), all the evil in perf > > trace has moved from shrink_slab() to down_read_trylock(). > > As reported by Shakeel Butt: > > > > > I created 255 memcgs, 255 ext4 mounts and made each memcg create a > > > file containing few KiBs on corresponding mount. Then in a separate > > > memcg of 200 MiB limit ran a fork-bomb. > > > > > > I ran the "perf record -ag -- sleep 60" and below are the results: > > > + 47.49%fb.sh [kernel.kallsyms][k] > > down_read_trylock > > > + 30.72%fb.sh [kernel.kallsyms][k] up_read > > > + 9.51%fb.sh [kernel.kallsyms][k] mem_cgroup_iter > > > + 1.69%fb.sh [kernel.kallsyms][k] > > shrink_node_memcg > > > + 1.35%fb.sh [kernel.kallsyms][k] > > mem_cgroup_protected > > > + 1.05%fb.sh [kernel.kallsyms][k] > > queued_spin_lock_slowpath > > > + 0.85%fb.sh [kernel.kallsyms][k] _raw_spin_lock > > > + 0.78%fb.sh [kernel.kallsyms][k] lruvec_lru_size > > > + 0.57%fb.sh [kernel.kallsyms][k] shrink_node > > > + 0.54%fb.sh [kernel.kallsyms][k] queue_work_on > > > + 0.46%fb.sh [kernel.kallsyms][k] > > shrink_slab_memcg > > > > The patchset continues to improve shrink_slab() scalability and makes > > it lockless completely. Here are several steps for that: > > So do you have any numbers for after theses changes? > I will do the same experiment as before with these patches sometime this or next week. BTW Kirill, thanks for pushing this. regards, Shakeel
Re: [PATCH RFC 00/10] Introduce lockless shrink_slab()
On Tue, Aug 7, 2018 at 6:12 PM Stephen Rothwell wrote: > > Hi Kirill, > > On Tue, 07 Aug 2018 18:37:19 +0300 Kirill Tkhai wrote: > > > > After bitmaps of not-empty memcg shrinkers were implemented > > (see "[PATCH v9 00/17] Improve shrink_slab() scalability..." > > series, which is already in mm tree), all the evil in perf > > trace has moved from shrink_slab() to down_read_trylock(). > > As reported by Shakeel Butt: > > > > > I created 255 memcgs, 255 ext4 mounts and made each memcg create a > > > file containing few KiBs on corresponding mount. Then in a separate > > > memcg of 200 MiB limit ran a fork-bomb. > > > > > > I ran the "perf record -ag -- sleep 60" and below are the results: > > > + 47.49%fb.sh [kernel.kallsyms][k] > > down_read_trylock > > > + 30.72%fb.sh [kernel.kallsyms][k] up_read > > > + 9.51%fb.sh [kernel.kallsyms][k] mem_cgroup_iter > > > + 1.69%fb.sh [kernel.kallsyms][k] > > shrink_node_memcg > > > + 1.35%fb.sh [kernel.kallsyms][k] > > mem_cgroup_protected > > > + 1.05%fb.sh [kernel.kallsyms][k] > > queued_spin_lock_slowpath > > > + 0.85%fb.sh [kernel.kallsyms][k] _raw_spin_lock > > > + 0.78%fb.sh [kernel.kallsyms][k] lruvec_lru_size > > > + 0.57%fb.sh [kernel.kallsyms][k] shrink_node > > > + 0.54%fb.sh [kernel.kallsyms][k] queue_work_on > > > + 0.46%fb.sh [kernel.kallsyms][k] > > shrink_slab_memcg > > > > The patchset continues to improve shrink_slab() scalability and makes > > it lockless completely. Here are several steps for that: > > So do you have any numbers for after theses changes? > I will do the same experiment as before with these patches sometime this or next week. BTW Kirill, thanks for pushing this. regards, Shakeel
Re: [PATCH 3.18 00/85] 3.18.118-stable review
On Tue, Aug 07, 2018 at 08:52:59PM -0600, Shuah Khan wrote: > On 08/07/2018 12:51 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.18.118 release. > > There are 85 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Aug 9 17:23:43 UTC 2018. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.118-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-3.18.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 3.18 00/85] 3.18.118-stable review
On Tue, Aug 07, 2018 at 08:52:59PM -0600, Shuah Khan wrote: > On 08/07/2018 12:51 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.18.118 release. > > There are 85 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Aug 9 17:23:43 UTC 2018. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.118-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-3.18.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 4.14 222/246] ext4: fix check to prevent initializing reserved inodes
On Wed, Aug 08, 2018 at 12:17:30AM +0200, Matthias Schiffer wrote: > On 08/01/2018 06:52 PM, Greg Kroah-Hartman wrote: > > 4.14-stable review patch. If anyone has any objections, please let me know. > > It seems this patch is still missing from the 4.4.y and 4.9.y branches. Maybe because no one has provided a working backport? :)
Re: [PATCH 4.14 222/246] ext4: fix check to prevent initializing reserved inodes
On Wed, Aug 08, 2018 at 12:17:30AM +0200, Matthias Schiffer wrote: > On 08/01/2018 06:52 PM, Greg Kroah-Hartman wrote: > > 4.14-stable review patch. If anyone has any objections, please let me know. > > It seems this patch is still missing from the 4.4.y and 4.9.y branches. Maybe because no one has provided a working backport? :)
Re: [PATCH 4.9 00/17] 4.9.119-stable review
On 8 August 2018 at 00:21, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.119 release. > There are 17 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:30 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.119-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm and x86_64. Summary kernel: 4.9.119-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: 1e9cd04e077b33f5dbecb2ddbc53695724b0cf97 git describe: v4.9.118-18-g1e9cd04e077b Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.118-18-g1e9cd04e077b No regressions (compared to build v4.9.118-17-g575cd33d16af) Ran 15539 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 4.9 00/17] 4.9.119-stable review
On 8 August 2018 at 00:21, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.119 release. > There are 17 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:30 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.119-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm and x86_64. Summary kernel: 4.9.119-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: 1e9cd04e077b33f5dbecb2ddbc53695724b0cf97 git describe: v4.9.118-18-g1e9cd04e077b Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.118-18-g1e9cd04e077b No regressions (compared to build v4.9.118-17-g575cd33d16af) Ran 15539 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 4.14 00/21] 4.14.62-stable review
On 8 August 2018 at 00:21, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.62 release. > There are 21 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:22 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.62-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm and x86_64. Summary kernel: 4.14.62-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: 5a43290b0403cc685cb30f8b65843e03980e9499 git describe: v4.14.61-22-g5a43290b0403 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.61-22-g5a43290b0403 No regressions (compared to build v4.14.61-21-g24cbd55fcf52) Ran 16631 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-syscalls-tests * ltp-timers-tests * ltp-securebits-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 4.14 00/21] 4.14.62-stable review
On 8 August 2018 at 00:21, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.62 release. > There are 21 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:22 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.62-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm and x86_64. Summary kernel: 4.14.62-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: 5a43290b0403cc685cb30f8b65843e03980e9499 git describe: v4.14.61-22-g5a43290b0403 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.61-22-g5a43290b0403 No regressions (compared to build v4.14.61-21-g24cbd55fcf52) Ran 16631 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-syscalls-tests * ltp-timers-tests * ltp-securebits-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 4.17 00/18] 4.17.14-stable review
On 8 August 2018 at 00:21, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.17.14 release. > There are 18 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:05 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.17.14-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.17.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm and x86_64. Summary kernel: 4.17.14-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.17.y git commit: 53b91e019709af31eaf31b16123585f05c00a411 git describe: v4.17.13-19-g53b91e019709 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.17-oe/build/v4.17.13-19-g53b91e019709 No regressions (compared to build v4.17.13) Ran 13918 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 4.17 00/18] 4.17.14-stable review
On 8 August 2018 at 00:21, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.17.14 release. > There are 18 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:05 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.17.14-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.17.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm and x86_64. Summary kernel: 4.17.14-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.17.y git commit: 53b91e019709af31eaf31b16123585f05c00a411 git describe: v4.17.13-19-g53b91e019709 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.17-oe/build/v4.17.13-19-g53b91e019709 No regressions (compared to build v4.17.13) Ran 13918 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On Tue, 7 Aug 2018, Andi Kleen wrote: > > Which simply does not work. Look at Goldmont Fam 6 Model 5C. The SoCs > > with that Fam/Model combination are: > > > > - Apollo Lake > > - Broxton (has two platforms: Morganfield and Willowtrail) > > Right pick one. The others are the same for software purposes > and can be handled in the same way. Pick one is really not a good choice. > > It's even worse with Silvermont. > > > > So no, the interesting information is the UARCH and the variant of that, > > With Uarch you mean the core uarch? That doesn't really work for > something like Silvermont or Goldmont. > > > e.g. UARCH_CLIENT, UARCH_SERVER, UARCH_WHATEVER. All the magic Code Names > > Right your scheme totally doesn't work on Silvermont because there > are multiple client variants. We have that for the big cores as well: #define INTEL_FAM6_HASWELL_CORE 0x3C #define INTEL_FAM6_HASWELL_X0x3F #define INTEL_FAM6_HASWELL_ULT 0x45 #define INTEL_FAM6_HASWELL_GT3E 0x46 Why would we treat ATOM differently? It's all the same scheme: SILVERMONT_CLIENT 0x37 Baytrail, Valleyview SILVERMONT_SERVER 0x40 Avaton, Rangely and on goldmont it's not any different. We really want one scheme for both Core and ATOM and not randomly picked different ones. For the kernel (aside of some peripheral stuff) the most interesting information is the UARCH plus the extra features which are enabled on a particular SoC. The current naming scheme e.g. for SILVERMONT is utter crap because the 1/2 variants are in fact CLIENT/SERVER and the comment in the header file, that there is no better name, is just silly. Thanks, tglx
Re: [PATCH] x86/cpu: Rename Denverton and Gemini Lake
On Tue, 7 Aug 2018, Andi Kleen wrote: > > Which simply does not work. Look at Goldmont Fam 6 Model 5C. The SoCs > > with that Fam/Model combination are: > > > > - Apollo Lake > > - Broxton (has two platforms: Morganfield and Willowtrail) > > Right pick one. The others are the same for software purposes > and can be handled in the same way. Pick one is really not a good choice. > > It's even worse with Silvermont. > > > > So no, the interesting information is the UARCH and the variant of that, > > With Uarch you mean the core uarch? That doesn't really work for > something like Silvermont or Goldmont. > > > e.g. UARCH_CLIENT, UARCH_SERVER, UARCH_WHATEVER. All the magic Code Names > > Right your scheme totally doesn't work on Silvermont because there > are multiple client variants. We have that for the big cores as well: #define INTEL_FAM6_HASWELL_CORE 0x3C #define INTEL_FAM6_HASWELL_X0x3F #define INTEL_FAM6_HASWELL_ULT 0x45 #define INTEL_FAM6_HASWELL_GT3E 0x46 Why would we treat ATOM differently? It's all the same scheme: SILVERMONT_CLIENT 0x37 Baytrail, Valleyview SILVERMONT_SERVER 0x40 Avaton, Rangely and on goldmont it's not any different. We really want one scheme for both Core and ATOM and not randomly picked different ones. For the kernel (aside of some peripheral stuff) the most interesting information is the UARCH plus the extra features which are enabled on a particular SoC. The current naming scheme e.g. for SILVERMONT is utter crap because the 1/2 variants are in fact CLIENT/SERVER and the comment in the header file, that there is no better name, is just silly. Thanks, tglx
Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage
On Tue, Aug 7, 2018 at 8:53 PM, Joel Fernandes wrote: > On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote: >> Hi Steve, >> >> On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote: > [...] @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void); } while ((++it_func_ptr)->func);\ } \ \ - if (rcuidle)\ - srcu_read_unlock_notrace(_srcu, idx);\ + srcu_read_unlock_notrace(ss, idx); \ >>> >>> Hmm, why do we have the two different srcu handles? >> >> Because if the memory operations happening on the normal SRCU handle >> (during srcu_read_lock) is interrupted by NMI, then the other handle >> (devoted to NMI) could be used instead and not bother the interrupted >> handle. Does that makes sense? >> >> When I talked to Paul few months ago about SRCU from NMI context, he >> mentioned the per-cpu memory operations during srcu_read_lock can be >> NMI interrupted, that's why we added that warning. > > So I looked more closely, __srcu_read_lock on 2 different handles may > still be doing a this_cpu_inc on the same location.. > (sp->sda->srcu_lock_count). :-( > > Paul any ideas on how to solve this? > > It does start to seem like a show stopper :-( Steve, another thing we could do is drop "tracepoint: Make rcuidle tracepoint callers use SRCU" and just call into irqsoff and preemptoff tracer hooks directly. The reason I added "tracepoint: Make rcuidle tracepoint callers use SRCU" is because lockdep's performance dropped with existing tracepoint code and SRCU improved that. But now that you're calling directly into lockdep that shouldn't be an issue. That should resolve your NMI issues and keep my macro and other clean ups from the original patch. What do you think? I am out in the morning, but I could write this up in the evening when I get some time (unless you do it before me). thanks, - Joel
Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage
On Tue, Aug 7, 2018 at 8:53 PM, Joel Fernandes wrote: > On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote: >> Hi Steve, >> >> On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote: > [...] @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void); } while ((++it_func_ptr)->func);\ } \ \ - if (rcuidle)\ - srcu_read_unlock_notrace(_srcu, idx);\ + srcu_read_unlock_notrace(ss, idx); \ >>> >>> Hmm, why do we have the two different srcu handles? >> >> Because if the memory operations happening on the normal SRCU handle >> (during srcu_read_lock) is interrupted by NMI, then the other handle >> (devoted to NMI) could be used instead and not bother the interrupted >> handle. Does that makes sense? >> >> When I talked to Paul few months ago about SRCU from NMI context, he >> mentioned the per-cpu memory operations during srcu_read_lock can be >> NMI interrupted, that's why we added that warning. > > So I looked more closely, __srcu_read_lock on 2 different handles may > still be doing a this_cpu_inc on the same location.. > (sp->sda->srcu_lock_count). :-( > > Paul any ideas on how to solve this? > > It does start to seem like a show stopper :-( Steve, another thing we could do is drop "tracepoint: Make rcuidle tracepoint callers use SRCU" and just call into irqsoff and preemptoff tracer hooks directly. The reason I added "tracepoint: Make rcuidle tracepoint callers use SRCU" is because lockdep's performance dropped with existing tracepoint code and SRCU improved that. But now that you're calling directly into lockdep that shouldn't be an issue. That should resolve your NMI issues and keep my macro and other clean ups from the original patch. What do you think? I am out in the morning, but I could write this up in the evening when I get some time (unless you do it before me). thanks, - Joel
did you recieve
Did you receive my email yesterday? Just want to check if you have needs for photo editing for our studio? We normally edit 300 images within 12-24 hours. We take care of different kinds of e-commerce photos, jewelry images, and portrait model images. Including cutting out and clipping path and others, we also give retouching for your images. You may drop us a photo if you want to check our quality, we will provide testing. Thanks, Roy
did you recieve
Did you receive my email yesterday? Just want to check if you have needs for photo editing for our studio? We normally edit 300 images within 12-24 hours. We take care of different kinds of e-commerce photos, jewelry images, and portrait model images. Including cutting out and clipping path and others, we also give retouching for your images. You may drop us a photo if you want to check our quality, we will provide testing. Thanks, Roy
Re: [PATCH] Input: cros_ec_keyb: Remove check before calling pm_wakeup_event.
Hi Ravi,
On 2018-08-07 23:59, Ravi Chandra Sadineni wrote:
> hi Merek,
>
> I tried booting a snow device and could not get it to boot it to the
> console. I assume i don't have right kernel config. Can you share your
> config if possible.
I use standard exynos_defconfig bundled with Linux kernel. I've followed
this instruction to boot in on Snow:
https://s-opensource.org/2016/03/24/use-mainline-u-boot-non-signed-kernels-exynos-chromebooks/
>
> Thanks,
> RaviOn Mon, Aug 6, 2018 at 4:05 PM Ravi Chandra Sadineni
> wrote:
>> Hi Merek,
>>
>> Thanks for the info. Lemme understand what's going on. Will update the
>> thread once I have more info.
>>
>> Thanks,
>> Ravi
>> On Mon, Aug 6, 2018 at 12:15 AM Marek Szyprowski
>> wrote:
>>> Hi Dmitry
>>>
>>> On 2018-08-06 08:16, Dmitry Torokhov wrote:
On Sun, Aug 5, 2018 at 10:29 PM Marek Szyprowski
wrote:
> Hi Ravi,
>
> On 2018-08-03 18:53, Ravi Chandra Sadineni wrote:
>> Understood. I am trying to reproduce this issue locally. Wanted to
>> know the version of the kernel so I can give a try. Marek, can you
>> please confirm the kernel version.
>>
> Yes, sorry for the missing context, I was in hurry writing the report and
> I wanted to send it before leaving the office. I'm testing mainline on
> Snow
> with exynos_defconfig.
>
> Suspend/resume is partially broken already with mainline, but if you
> disable
> CPUfreq support, it works fine on Linux v4.17.
>
> I've posted CPUfreq related fixes here if you are interested:
> https://patchwork.kernel.org/patch/10554607/
> https://patchwork.kernel.org/patch/10554603/
>
> The issue with cros_ec_keyb patch appears first on Linux v4.18-rc1, which
> is
> the first release with that patch.
Marek, this patch should only be in -next, I do not believe I sent it
to Linus just yet. If mainline is broken for you it can't be caused by
this patch.
>>> Aaahh. My fault then. The suspend/resume issue is cause by commit
>>> 38ba34a43dbc ("Input: cros_ec_keyb - mark cros_ec_keyb driver as wake
>>> enabled device."), which has been merged to v4.18-rc1.
>>>
>>> It looks that I've downloaded wrong patch from the patchwork to reply it
>>> with a a bug report. :( I'm really sorry for the noise in the wrong thread.
>>>
>>> Ravi: please let me know how can I help you to debug this issue.
>>>
> Linux -next from 20180803, which has a few
> more patches for cros_ec_keyb suffers from the same issue.
Just to confirm, if you revert only this patch from -next you get
suspend/resume back?
Thanks.
>>> Best regards
>>> --
>>> Marek Szyprowski, PhD
>>> Samsung R Institute Poland
>>>
>
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
Re: [PATCH] Input: cros_ec_keyb: Remove check before calling pm_wakeup_event.
Hi Ravi,
On 2018-08-07 23:59, Ravi Chandra Sadineni wrote:
> hi Merek,
>
> I tried booting a snow device and could not get it to boot it to the
> console. I assume i don't have right kernel config. Can you share your
> config if possible.
I use standard exynos_defconfig bundled with Linux kernel. I've followed
this instruction to boot in on Snow:
https://s-opensource.org/2016/03/24/use-mainline-u-boot-non-signed-kernels-exynos-chromebooks/
>
> Thanks,
> RaviOn Mon, Aug 6, 2018 at 4:05 PM Ravi Chandra Sadineni
> wrote:
>> Hi Merek,
>>
>> Thanks for the info. Lemme understand what's going on. Will update the
>> thread once I have more info.
>>
>> Thanks,
>> Ravi
>> On Mon, Aug 6, 2018 at 12:15 AM Marek Szyprowski
>> wrote:
>>> Hi Dmitry
>>>
>>> On 2018-08-06 08:16, Dmitry Torokhov wrote:
On Sun, Aug 5, 2018 at 10:29 PM Marek Szyprowski
wrote:
> Hi Ravi,
>
> On 2018-08-03 18:53, Ravi Chandra Sadineni wrote:
>> Understood. I am trying to reproduce this issue locally. Wanted to
>> know the version of the kernel so I can give a try. Marek, can you
>> please confirm the kernel version.
>>
> Yes, sorry for the missing context, I was in hurry writing the report and
> I wanted to send it before leaving the office. I'm testing mainline on
> Snow
> with exynos_defconfig.
>
> Suspend/resume is partially broken already with mainline, but if you
> disable
> CPUfreq support, it works fine on Linux v4.17.
>
> I've posted CPUfreq related fixes here if you are interested:
> https://patchwork.kernel.org/patch/10554607/
> https://patchwork.kernel.org/patch/10554603/
>
> The issue with cros_ec_keyb patch appears first on Linux v4.18-rc1, which
> is
> the first release with that patch.
Marek, this patch should only be in -next, I do not believe I sent it
to Linus just yet. If mainline is broken for you it can't be caused by
this patch.
>>> Aaahh. My fault then. The suspend/resume issue is cause by commit
>>> 38ba34a43dbc ("Input: cros_ec_keyb - mark cros_ec_keyb driver as wake
>>> enabled device."), which has been merged to v4.18-rc1.
>>>
>>> It looks that I've downloaded wrong patch from the patchwork to reply it
>>> with a a bug report. :( I'm really sorry for the noise in the wrong thread.
>>>
>>> Ravi: please let me know how can I help you to debug this issue.
>>>
> Linux -next from 20180803, which has a few
> more patches for cros_ec_keyb suffers from the same issue.
Just to confirm, if you revert only this patch from -next you get
suspend/resume back?
Thanks.
>>> Best regards
>>> --
>>> Marek Szyprowski, PhD
>>> Samsung R Institute Poland
>>>
>
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
[PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
Clock framework will enable those clocks registered
with CLK_IS_CRITICAL flag, so no need to have
clks_init_on array during clock initialization now.
Signed-off-by: Anson Huang
---
drivers/clk/imx/clk-imx7d.c | 27 ---
drivers/clk/imx/clk.h | 7 +++
2 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index c4518d7..076460b 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -379,13 +379,6 @@ static const char *pll_enet_bypass_sel[] = {
"pll_enet_main", "pll_enet_main_src
static const char *pll_audio_bypass_sel[] = { "pll_audio_main",
"pll_audio_main_src", };
static const char *pll_video_bypass_sel[] = { "pll_video_main",
"pll_video_main_src", };
-static int const clks_init_on[] __initconst = {
- IMX7D_ARM_A7_ROOT_CLK, IMX7D_MAIN_AXI_ROOT_CLK,
- IMX7D_PLL_SYS_MAIN_480M_CLK, IMX7D_IPG_ROOT_CLK,
- IMX7D_DRAM_PHYM_ROOT_CLK, IMX7D_DRAM_ROOT_CLK,
- IMX7D_DRAM_PHYM_ALT_ROOT_CLK, IMX7D_DRAM_ALT_ROOT_CLK,
-};
-
static struct clk_onecell_data clk_data;
static struct clk ** const uart_clks[] __initconst = {
@@ -403,7 +396,6 @@ static void __init imx7d_clocks_init(struct device_node
*ccm_node)
{
struct device_node *np;
void __iomem *base;
- int i;
clks[IMX7D_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
clks[IMX7D_OSC_24M_CLK] = of_clk_get_by_name(ccm_node, "osc");
@@ -466,7 +458,7 @@ static void __init imx7d_clocks_init(struct device_node
*ccm_node)
clks[IMX7D_PLL_SYS_MAIN_120M] =
imx_clk_fixed_factor("pll_sys_main_120m", "pll_sys_main_clk", 1, 4);
clks[IMX7D_PLL_DRAM_MAIN_533M] = imx_clk_fixed_factor("pll_dram_533m",
"pll_dram_main_clk", 1, 2);
- clks[IMX7D_PLL_SYS_MAIN_480M_CLK] =
imx_clk_gate_dis("pll_sys_main_480m_clk", "pll_sys_main_480m", base + 0xb0, 4);
+ clks[IMX7D_PLL_SYS_MAIN_480M_CLK] =
imx_clk_gate_dis_flags("pll_sys_main_480m_clk", "pll_sys_main_480m", base +
0xb0, 4, CLK_IS_CRITICAL);
clks[IMX7D_PLL_SYS_MAIN_240M_CLK] =
imx_clk_gate_dis("pll_sys_main_240m_clk", "pll_sys_main_240m", base + 0xb0, 5);
clks[IMX7D_PLL_SYS_MAIN_120M_CLK] =
imx_clk_gate_dis("pll_sys_main_120m_clk", "pll_sys_main_120m", base + 0xb0, 6);
clks[IMX7D_PLL_DRAM_MAIN_533M_CLK] = imx_clk_gate("pll_dram_533m_clk",
"pll_dram_533m", base + 0x70, 12);
@@ -719,7 +711,7 @@ static void __init imx7d_clocks_init(struct device_node
*ccm_node)
clks[IMX7D_ENET_AXI_ROOT_DIV] = imx_clk_divider2("enet_axi_post_div",
"enet_axi_pre_div", base + 0x8900, 0, 6);
clks[IMX7D_NAND_USDHC_BUS_ROOT_CLK] =
imx_clk_divider2("nand_usdhc_root_clk", "nand_usdhc_pre_div", base + 0x8980, 0,
6);
clks[IMX7D_AHB_CHANNEL_ROOT_DIV] = imx_clk_divider2("ahb_root_clk",
"ahb_pre_div", base + 0x9000, 0, 6);
- clks[IMX7D_IPG_ROOT_CLK] = imx_clk_divider2("ipg_root_clk",
"ahb_root_clk", base + 0x9080, 0, 2);
+ clks[IMX7D_IPG_ROOT_CLK] = imx_clk_divider_flags("ipg_root_clk",
"ahb_root_clk", base + 0x9080, 0, 2, CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE |
CLK_SET_RATE_PARENT);
clks[IMX7D_DRAM_ROOT_DIV] = imx_clk_divider2("dram_post_div",
"dram_cg", base + 0x9880, 0, 3);
clks[IMX7D_DRAM_PHYM_ALT_ROOT_DIV] =
imx_clk_divider2("dram_phym_alt_post_div", "dram_phym_alt_pre_div", base +
0xa000, 0, 3);
clks[IMX7D_DRAM_ALT_ROOT_DIV] = imx_clk_divider2("dram_alt_post_div",
"dram_alt_pre_div", base + 0xa080, 0, 3);
@@ -783,17 +775,17 @@ static void __init imx7d_clocks_init(struct device_node
*ccm_node)
clks[IMX7D_CLKO1_ROOT_DIV] = imx_clk_divider2("clko1_post_div",
"clko1_pre_div", base + 0xbd80, 0, 6);
clks[IMX7D_CLKO2_ROOT_DIV] = imx_clk_divider2("clko2_post_div",
"clko2_pre_div", base + 0xbe00, 0, 6);
- clks[IMX7D_ARM_A7_ROOT_CLK] = imx_clk_gate4("arm_a7_root_clk",
"arm_a7_div", base + 0x4000, 0);
+ clks[IMX7D_ARM_A7_ROOT_CLK] = imx_clk_gate2_flags("arm_a7_root_clk",
"arm_a7_div", base + 0x4000, 0, CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE);
clks[IMX7D_ARM_M4_ROOT_CLK] = imx_clk_gate4("arm_m4_root_clk",
"arm_m4_div", base + 0x4010, 0);
- clks[IMX7D_MAIN_AXI_ROOT_CLK] = imx_clk_gate4("main_axi_root_clk",
"axi_post_div", base + 0x4040, 0);
+ clks[IMX7D_MAIN_AXI_ROOT_CLK] =
imx_clk_gate2_flags("main_axi_root_clk", "axi_post_div", base + 0x4040, 0,
CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE);
clks[IMX7D_DISP_AXI_ROOT_CLK] = imx_clk_gate4("disp_axi_root_clk",
"disp_axi_post_div", base + 0x4050, 0);
clks[IMX7D_ENET_AXI_ROOT_CLK] = imx_clk_gate4("enet_axi_root_clk",
"enet_axi_post_div", base + 0x4060, 0);
clks[IMX7D_OCRAM_CLK] = imx_clk_gate4("ocram_clk", "main_axi_root_clk",
base + 0x4110, 0);
clks[IMX7D_OCRAM_S_CLK] = imx_clk_gate4("ocram_s_clk", "ahb_root_clk",
base + 0x4120, 0);
- clks[IMX7D_DRAM_ROOT_CLK] = imx_clk_gate4("dram_root_clk",
"dram_post_div", base +
[PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
Clock framework will enable those clocks registered
with CLK_IS_CRITICAL flag, so no need to have
clks_init_on array during clock initialization now.
Signed-off-by: Anson Huang
---
drivers/clk/imx/clk-imx7d.c | 27 ---
drivers/clk/imx/clk.h | 7 +++
2 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index c4518d7..076460b 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -379,13 +379,6 @@ static const char *pll_enet_bypass_sel[] = {
"pll_enet_main", "pll_enet_main_src
static const char *pll_audio_bypass_sel[] = { "pll_audio_main",
"pll_audio_main_src", };
static const char *pll_video_bypass_sel[] = { "pll_video_main",
"pll_video_main_src", };
-static int const clks_init_on[] __initconst = {
- IMX7D_ARM_A7_ROOT_CLK, IMX7D_MAIN_AXI_ROOT_CLK,
- IMX7D_PLL_SYS_MAIN_480M_CLK, IMX7D_IPG_ROOT_CLK,
- IMX7D_DRAM_PHYM_ROOT_CLK, IMX7D_DRAM_ROOT_CLK,
- IMX7D_DRAM_PHYM_ALT_ROOT_CLK, IMX7D_DRAM_ALT_ROOT_CLK,
-};
-
static struct clk_onecell_data clk_data;
static struct clk ** const uart_clks[] __initconst = {
@@ -403,7 +396,6 @@ static void __init imx7d_clocks_init(struct device_node
*ccm_node)
{
struct device_node *np;
void __iomem *base;
- int i;
clks[IMX7D_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
clks[IMX7D_OSC_24M_CLK] = of_clk_get_by_name(ccm_node, "osc");
@@ -466,7 +458,7 @@ static void __init imx7d_clocks_init(struct device_node
*ccm_node)
clks[IMX7D_PLL_SYS_MAIN_120M] =
imx_clk_fixed_factor("pll_sys_main_120m", "pll_sys_main_clk", 1, 4);
clks[IMX7D_PLL_DRAM_MAIN_533M] = imx_clk_fixed_factor("pll_dram_533m",
"pll_dram_main_clk", 1, 2);
- clks[IMX7D_PLL_SYS_MAIN_480M_CLK] =
imx_clk_gate_dis("pll_sys_main_480m_clk", "pll_sys_main_480m", base + 0xb0, 4);
+ clks[IMX7D_PLL_SYS_MAIN_480M_CLK] =
imx_clk_gate_dis_flags("pll_sys_main_480m_clk", "pll_sys_main_480m", base +
0xb0, 4, CLK_IS_CRITICAL);
clks[IMX7D_PLL_SYS_MAIN_240M_CLK] =
imx_clk_gate_dis("pll_sys_main_240m_clk", "pll_sys_main_240m", base + 0xb0, 5);
clks[IMX7D_PLL_SYS_MAIN_120M_CLK] =
imx_clk_gate_dis("pll_sys_main_120m_clk", "pll_sys_main_120m", base + 0xb0, 6);
clks[IMX7D_PLL_DRAM_MAIN_533M_CLK] = imx_clk_gate("pll_dram_533m_clk",
"pll_dram_533m", base + 0x70, 12);
@@ -719,7 +711,7 @@ static void __init imx7d_clocks_init(struct device_node
*ccm_node)
clks[IMX7D_ENET_AXI_ROOT_DIV] = imx_clk_divider2("enet_axi_post_div",
"enet_axi_pre_div", base + 0x8900, 0, 6);
clks[IMX7D_NAND_USDHC_BUS_ROOT_CLK] =
imx_clk_divider2("nand_usdhc_root_clk", "nand_usdhc_pre_div", base + 0x8980, 0,
6);
clks[IMX7D_AHB_CHANNEL_ROOT_DIV] = imx_clk_divider2("ahb_root_clk",
"ahb_pre_div", base + 0x9000, 0, 6);
- clks[IMX7D_IPG_ROOT_CLK] = imx_clk_divider2("ipg_root_clk",
"ahb_root_clk", base + 0x9080, 0, 2);
+ clks[IMX7D_IPG_ROOT_CLK] = imx_clk_divider_flags("ipg_root_clk",
"ahb_root_clk", base + 0x9080, 0, 2, CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE |
CLK_SET_RATE_PARENT);
clks[IMX7D_DRAM_ROOT_DIV] = imx_clk_divider2("dram_post_div",
"dram_cg", base + 0x9880, 0, 3);
clks[IMX7D_DRAM_PHYM_ALT_ROOT_DIV] =
imx_clk_divider2("dram_phym_alt_post_div", "dram_phym_alt_pre_div", base +
0xa000, 0, 3);
clks[IMX7D_DRAM_ALT_ROOT_DIV] = imx_clk_divider2("dram_alt_post_div",
"dram_alt_pre_div", base + 0xa080, 0, 3);
@@ -783,17 +775,17 @@ static void __init imx7d_clocks_init(struct device_node
*ccm_node)
clks[IMX7D_CLKO1_ROOT_DIV] = imx_clk_divider2("clko1_post_div",
"clko1_pre_div", base + 0xbd80, 0, 6);
clks[IMX7D_CLKO2_ROOT_DIV] = imx_clk_divider2("clko2_post_div",
"clko2_pre_div", base + 0xbe00, 0, 6);
- clks[IMX7D_ARM_A7_ROOT_CLK] = imx_clk_gate4("arm_a7_root_clk",
"arm_a7_div", base + 0x4000, 0);
+ clks[IMX7D_ARM_A7_ROOT_CLK] = imx_clk_gate2_flags("arm_a7_root_clk",
"arm_a7_div", base + 0x4000, 0, CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE);
clks[IMX7D_ARM_M4_ROOT_CLK] = imx_clk_gate4("arm_m4_root_clk",
"arm_m4_div", base + 0x4010, 0);
- clks[IMX7D_MAIN_AXI_ROOT_CLK] = imx_clk_gate4("main_axi_root_clk",
"axi_post_div", base + 0x4040, 0);
+ clks[IMX7D_MAIN_AXI_ROOT_CLK] =
imx_clk_gate2_flags("main_axi_root_clk", "axi_post_div", base + 0x4040, 0,
CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE);
clks[IMX7D_DISP_AXI_ROOT_CLK] = imx_clk_gate4("disp_axi_root_clk",
"disp_axi_post_div", base + 0x4050, 0);
clks[IMX7D_ENET_AXI_ROOT_CLK] = imx_clk_gate4("enet_axi_root_clk",
"enet_axi_post_div", base + 0x4060, 0);
clks[IMX7D_OCRAM_CLK] = imx_clk_gate4("ocram_clk", "main_axi_root_clk",
base + 0x4110, 0);
clks[IMX7D_OCRAM_S_CLK] = imx_clk_gate4("ocram_s_clk", "ahb_root_clk",
base + 0x4120, 0);
- clks[IMX7D_DRAM_ROOT_CLK] = imx_clk_gate4("dram_root_clk",
"dram_post_div", base +
[PATCH 1/2] clk: imx: imx7d: remove unnecessary clocks from clks_init_on array
On i.MX7D, IMX7D_NAND_USDHC_BUS_ROOT_CLK is NOT necessary
for system, and IMX7D_AHB_CHANNEL_ROOT_CLK is NOT existing
at all, remove them from clks_init_on array.
Signed-off-by: Anson Huang
---
drivers/clk/imx/clk-imx7d.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 881b772..c4518d7 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -381,10 +381,9 @@ static const char *pll_video_bypass_sel[] = {
"pll_video_main", "pll_video_main_
static int const clks_init_on[] __initconst = {
IMX7D_ARM_A7_ROOT_CLK, IMX7D_MAIN_AXI_ROOT_CLK,
- IMX7D_PLL_SYS_MAIN_480M_CLK, IMX7D_NAND_USDHC_BUS_ROOT_CLK,
+ IMX7D_PLL_SYS_MAIN_480M_CLK, IMX7D_IPG_ROOT_CLK,
IMX7D_DRAM_PHYM_ROOT_CLK, IMX7D_DRAM_ROOT_CLK,
IMX7D_DRAM_PHYM_ALT_ROOT_CLK, IMX7D_DRAM_ALT_ROOT_CLK,
- IMX7D_AHB_CHANNEL_ROOT_CLK, IMX7D_IPG_ROOT_CLK,
};
static struct clk_onecell_data clk_data;
--
2.7.4
[PATCH 1/2] clk: imx: imx7d: remove unnecessary clocks from clks_init_on array
On i.MX7D, IMX7D_NAND_USDHC_BUS_ROOT_CLK is NOT necessary
for system, and IMX7D_AHB_CHANNEL_ROOT_CLK is NOT existing
at all, remove them from clks_init_on array.
Signed-off-by: Anson Huang
---
drivers/clk/imx/clk-imx7d.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 881b772..c4518d7 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -381,10 +381,9 @@ static const char *pll_video_bypass_sel[] = {
"pll_video_main", "pll_video_main_
static int const clks_init_on[] __initconst = {
IMX7D_ARM_A7_ROOT_CLK, IMX7D_MAIN_AXI_ROOT_CLK,
- IMX7D_PLL_SYS_MAIN_480M_CLK, IMX7D_NAND_USDHC_BUS_ROOT_CLK,
+ IMX7D_PLL_SYS_MAIN_480M_CLK, IMX7D_IPG_ROOT_CLK,
IMX7D_DRAM_PHYM_ROOT_CLK, IMX7D_DRAM_ROOT_CLK,
IMX7D_DRAM_PHYM_ALT_ROOT_CLK, IMX7D_DRAM_ALT_ROOT_CLK,
- IMX7D_AHB_CHANNEL_ROOT_CLK, IMX7D_IPG_ROOT_CLK,
};
static struct clk_onecell_data clk_data;
--
2.7.4
[RESEND PATCH] init/Kconfig: Use short unix-style option instead of --longname
From: Rob Landley Avoids warning messages with the latest release of toybox, which never bothered to implement the --longopts nothing was using. Signed-off-by: Rob Landley Signed-off-by: Masahiro Yamada --- This was sent to the trivial ML some time ago, but not applied yet. I will apply this to kbuild tree for v4.19 [yamada.masah...@socionext.com Move the patch description under '---' to the commit log body. ] init/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index 794a1b1..944b1fd 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -2,9 +2,9 @@ config DEFCONFIG_LIST string depends on !UML option defconfig_list - default "/lib/modules/$(shell,uname --release)/.config" + default "/lib/modules/$(shell,uname -r)/.config" default "/etc/kernel-config" - default "/boot/config-$(shell,uname --release)" + default "/boot/config-$(shell,uname -r)" default ARCH_DEFCONFIG default "arch/$(ARCH)/defconfig" -- 2.7.4
[RESEND PATCH] init/Kconfig: Use short unix-style option instead of --longname
From: Rob Landley Avoids warning messages with the latest release of toybox, which never bothered to implement the --longopts nothing was using. Signed-off-by: Rob Landley Signed-off-by: Masahiro Yamada --- This was sent to the trivial ML some time ago, but not applied yet. I will apply this to kbuild tree for v4.19 [yamada.masah...@socionext.com Move the patch description under '---' to the commit log body. ] init/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index 794a1b1..944b1fd 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -2,9 +2,9 @@ config DEFCONFIG_LIST string depends on !UML option defconfig_list - default "/lib/modules/$(shell,uname --release)/.config" + default "/lib/modules/$(shell,uname -r)/.config" default "/etc/kernel-config" - default "/boot/config-$(shell,uname --release)" + default "/boot/config-$(shell,uname -r)" default ARCH_DEFCONFIG default "arch/$(ARCH)/defconfig" -- 2.7.4
Re: [PATCH v2 08/18] serial: intel: Get serial id from dts
On 8/7/2018 3:33 PM, Geert Uytterhoeven wrote:
Hi Songjun,
On Fri, Aug 3, 2018 at 5:04 AM Songjun Wu wrote:
Get serial id from dts.
"#ifdef CONFIG_LANTIQ" preprocessor is used because LTQ_EARLY_ASC
macro is defined in lantiq_soc.h.
lantiq_soc.h is in arch path for legacy product support.
arch/mips/include/asm/mach-lantiq/xway/lantiq_soc.h
If "#ifdef preprocessor" is changed to
"if (IS_ENABLED(CONFIG_LANTIQ))", when CONFIG_LANTIQ is not enabled,
code using LTQ_EARLY_ASC is compiled.
Compilation will fail for no LTQ_EARLY_ASC defined.
Signed-off-by: Songjun Wu
Thanks for your patch!
@@ -699,9 +700,19 @@ lqasc_probe(struct platform_device *pdev)
return -ENODEV;
}
- /* check if this is the console port */
- if (mmres->start != CPHYSADDR(LTQ_EARLY_ASC))
- line = 1;
+ /* get serial id */
+ line = of_alias_get_id(node, "serial");
+ if (line < 0) {
+#ifdef CONFIG_LANTIQ
+ if (mmres->start == CPHYSADDR(LTQ_EARLY_ASC))
+ line = 0;
+ else
+ line = 1;
+#else
+ dev_err(>dev, "failed to get alias id, errno %d\n", line);
+ return line;
Please note that not providing a fallback here makes life harder when using
DT overlays.
See the description of commit 7678f4c20fa7670f ("serial: sh-sci: Add support
for dynamic instances") for background info.
Thanks for your comment.
The logic in commit 7678f4c20fa7670f is not suitable here.
We need to know which serial instance is used for console.
We cannot use dynamic serial instance here.
Re: [PATCH v2 08/18] serial: intel: Get serial id from dts
On 8/7/2018 3:33 PM, Geert Uytterhoeven wrote:
Hi Songjun,
On Fri, Aug 3, 2018 at 5:04 AM Songjun Wu wrote:
Get serial id from dts.
"#ifdef CONFIG_LANTIQ" preprocessor is used because LTQ_EARLY_ASC
macro is defined in lantiq_soc.h.
lantiq_soc.h is in arch path for legacy product support.
arch/mips/include/asm/mach-lantiq/xway/lantiq_soc.h
If "#ifdef preprocessor" is changed to
"if (IS_ENABLED(CONFIG_LANTIQ))", when CONFIG_LANTIQ is not enabled,
code using LTQ_EARLY_ASC is compiled.
Compilation will fail for no LTQ_EARLY_ASC defined.
Signed-off-by: Songjun Wu
Thanks for your patch!
@@ -699,9 +700,19 @@ lqasc_probe(struct platform_device *pdev)
return -ENODEV;
}
- /* check if this is the console port */
- if (mmres->start != CPHYSADDR(LTQ_EARLY_ASC))
- line = 1;
+ /* get serial id */
+ line = of_alias_get_id(node, "serial");
+ if (line < 0) {
+#ifdef CONFIG_LANTIQ
+ if (mmres->start == CPHYSADDR(LTQ_EARLY_ASC))
+ line = 0;
+ else
+ line = 1;
+#else
+ dev_err(>dev, "failed to get alias id, errno %d\n", line);
+ return line;
Please note that not providing a fallback here makes life harder when using
DT overlays.
See the description of commit 7678f4c20fa7670f ("serial: sh-sci: Add support
for dynamic instances") for background info.
Thanks for your comment.
The logic in commit 7678f4c20fa7670f is not suitable here.
We need to know which serial instance is used for console.
We cannot use dynamic serial instance here.
linux-next: manual merge of the kvm tree with the tip tree
Hi all,
Paolo pointed out a semantic conflict between the kvm tree and the tip
tree in
arch/x86/kernel/kvm.c
between commit:
368a540e0232 ("x86/kvmclock: Remove memblock dependency")
from the tip tree and commit:
d63bae079b64 ("KVM: X86: Add kvm hypervisor init time platform setup
callback")
from the kvm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
I applied the following (as suggested) after the automatic merge:
From: Stephen Rothwell
Date: Wed, 8 Aug 2018 13:48:34 +1000
Subject: [PATCH] kvm: x86: fix semantic conflict in platform init
Signed-off-by: Stephen Rothwell
---
arch/x86/kernel/kvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 0906b8731393..e2499bad3209 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -714,13 +714,13 @@ static void __init kvm_apic_init(void)
static void __init kvm_init_platform(void)
{
x86_platform.apic_post_init = kvm_apic_init;
+ kvmclock_init();
}
const __initconst struct hypervisor_x86 x86_hyper_kvm = {
.name = "KVM",
.detect = kvm_detect,
.type = X86_HYPER_KVM,
- .init.init_platform = kvmclock_init,
.init.guest_late_init = kvm_guest_init,
.init.x2apic_available = kvm_para_available,
.init.init_platform = kvm_init_platform,
--
2.18.0
--
Cheers,
Stephen Rothwell
pgpCy0p8GIxnH.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the kvm tree with the tip tree
Hi all,
Paolo pointed out a semantic conflict between the kvm tree and the tip
tree in
arch/x86/kernel/kvm.c
between commit:
368a540e0232 ("x86/kvmclock: Remove memblock dependency")
from the tip tree and commit:
d63bae079b64 ("KVM: X86: Add kvm hypervisor init time platform setup
callback")
from the kvm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
I applied the following (as suggested) after the automatic merge:
From: Stephen Rothwell
Date: Wed, 8 Aug 2018 13:48:34 +1000
Subject: [PATCH] kvm: x86: fix semantic conflict in platform init
Signed-off-by: Stephen Rothwell
---
arch/x86/kernel/kvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 0906b8731393..e2499bad3209 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -714,13 +714,13 @@ static void __init kvm_apic_init(void)
static void __init kvm_init_platform(void)
{
x86_platform.apic_post_init = kvm_apic_init;
+ kvmclock_init();
}
const __initconst struct hypervisor_x86 x86_hyper_kvm = {
.name = "KVM",
.detect = kvm_detect,
.type = X86_HYPER_KVM,
- .init.init_platform = kvmclock_init,
.init.guest_late_init = kvm_guest_init,
.init.x2apic_available = kvm_para_available,
.init.init_platform = kvm_init_platform,
--
2.18.0
--
Cheers,
Stephen Rothwell
pgpCy0p8GIxnH.pgp
Description: OpenPGP digital signature
Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage
On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote: > Hi Steve, > > On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote: [...] >>> @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void); >>> } while ((++it_func_ptr)->func);\ >>> } \ >>> \ >>> - if (rcuidle)\ >>> - srcu_read_unlock_notrace(_srcu, idx);\ >>> + srcu_read_unlock_notrace(ss, idx); \ >> >> Hmm, why do we have the two different srcu handles? > > Because if the memory operations happening on the normal SRCU handle > (during srcu_read_lock) is interrupted by NMI, then the other handle > (devoted to NMI) could be used instead and not bother the interrupted > handle. Does that makes sense? > > When I talked to Paul few months ago about SRCU from NMI context, he > mentioned the per-cpu memory operations during srcu_read_lock can be > NMI interrupted, that's why we added that warning. So I looked more closely, __srcu_read_lock on 2 different handles may still be doing a this_cpu_inc on the same location.. (sp->sda->srcu_lock_count). :-( Paul any ideas on how to solve this? It does start to seem like a show stopper :-(
Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage
On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote: > Hi Steve, > > On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote: [...] >>> @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void); >>> } while ((++it_func_ptr)->func);\ >>> } \ >>> \ >>> - if (rcuidle)\ >>> - srcu_read_unlock_notrace(_srcu, idx);\ >>> + srcu_read_unlock_notrace(ss, idx); \ >> >> Hmm, why do we have the two different srcu handles? > > Because if the memory operations happening on the normal SRCU handle > (during srcu_read_lock) is interrupted by NMI, then the other handle > (devoted to NMI) could be used instead and not bother the interrupted > handle. Does that makes sense? > > When I talked to Paul few months ago about SRCU from NMI context, he > mentioned the per-cpu memory operations during srcu_read_lock can be > NMI interrupted, that's why we added that warning. So I looked more closely, __srcu_read_lock on 2 different handles may still be doing a this_cpu_inc on the same location.. (sp->sda->srcu_lock_count). :-( Paul any ideas on how to solve this? It does start to seem like a show stopper :-(
Re: [PATCH v3] PCI/AER: Do not clear AER bits if we don't own AER
On 08/07/2018 08:14 PM, Bjorn Helgaas wrote:
On Mon, Jul 30, 2018 at 06:35:31PM -0500, Alexandru Gagniuc wrote:
When we don't own AER, we shouldn't touch the AER error bits. Clearing
error bits willy-nilly might cause firmware to miss some errors. In
theory, these bits get cleared by FFS, or via ACPI _HPX method. These
mechanisms are not subject to the problem.
What's FFS?
Firmware-first. Nobody likes spelling it out, and all other proposed
acronyms are insanely tong-twisting. So, FFS.
I guess you mean FFS and _HPX are not subject to the problem because
they're supplied by firmware, so firmware would be responsible for
looking at the bits before clearing them?
Exactly.
This race is mostly of theoretical significance, since I can't
reasonably demonstrate this race in the lab.
On a side-note, pcie_aer_is_kernel_first() is created to alleviate the
need for two checks: aer_cap and get_firmware_first().
Signed-off-by: Alexandru Gagniuc
---
Changes since v2:
- Added missing negation in pci_cleanup_aer_error_status_regs()
drivers/pci/pcie/aer.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index a2e88386af28..40e5c86271d1 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -307,6 +307,12 @@ int pcie_aer_get_firmware_first(struct pci_dev *dev)
aer_set_firmware_first(dev);
return dev->__aer_firmware_first;
}
+
+static bool pcie_aer_is_kernel_first(struct pci_dev *dev)
+{
+ return !!dev->aer_cap && !pcie_aer_get_firmware_first(dev);
+}
I think it complicates things to have both "firmware_first" and
"kernel_first" interfaces, so I would prefer to stick with the
existing "firmware_first" style.
#define PCI_EXP_AER_FLAGS (PCI_EXP_DEVCTL_CERE |
PCI_EXP_DEVCTL_NFERE | \
PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
@@ -337,10 +343,7 @@ bool aer_acpi_firmware_first(void)
int pci_enable_pcie_error_reporting(struct pci_dev *dev)
{
- if (pcie_aer_get_firmware_first(dev))
- return -EIO;
-
- if (!dev->aer_cap)
+ if (!pcie_aer_is_kernel_first(dev))
return -EIO;
return pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_AER_FLAGS);
This change doesn't actually fix anything, does it? It looks like a
cleanup that doesn't change the behavior.
Initially (v1), this was a one-liner, but someone had a complaint about
having pcie_aer_get_firmware_first() boilerplate all over the place.
That's why I added the "kernel_first" function (previous comment), and
then updated this here for completeness. I'm also fine with v1.
@@ -349,7 +352,7 @@ EXPORT_SYMBOL_GPL(pci_enable_pcie_error_reporting);
int pci_disable_pcie_error_reporting(struct pci_dev *dev)
{
- if (pcie_aer_get_firmware_first(dev))
+ if (!pcie_aer_is_kernel_first(dev))
return -EIO;
This change does effectively add a test for dev->aer_cap. That makes
sense in terms of symmetry with pci_enable_pcie_error_reporting(),
but I think it should be a separate patch because it's conceptually
separate from the change below.
We should keep the existing behavior (but add the symmetry) here for
now, but it's not clear to me that these paths should care about AER
or firmware-first at all. PCI_EXP_DEVCTL is not an AER register and
we have the _HPX mechanism for firmware to influence it (which these
paths currently ignore). I suspect we should program these reporting
enable bits in the core enumeration path instead of having drivers
call these interfaces.
The headache is that FFS needs the reporting bit to stay enabled in
order to get AER notifications. Disabling things here could really break
firmware. Of course, that's a cyclical argument, since FW is broken by
definition.
If/when we make changes along these lines, the history will be easier
to follow if *this* change is not connected with the change below to
pci_cleanup_aer_error_status_regs().
I agree. I think it might be preferred then to go with v1, and leave the
refactoring to a later time, since the extra changes are cosmetical and
social.
return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
@@ -383,10 +386,10 @@ int pci_cleanup_aer_error_status_regs(struct pci_dev *dev)
if (!pci_is_pcie(dev))
return -ENODEV;
- pos = dev->aer_cap;
- if (!pos)
+ if (!pcie_aer_is_kernel_first(dev))
return -EIO;
This part makes sense to me, but I think I would rather have it match
the existing style in pci_enable_pcie_error_reporting(), i.e., keep
the test for dev->aer_cap and add a test for
pcie_aer_get_firmware_first().
Had it that way in v1.
Alex
+ pos = dev->aer_cap;
port_type = pci_pcie_type(dev);
if (port_type == PCI_EXP_TYPE_ROOT_PORT) {
pci_read_config_dword(dev, pos + PCI_ERR_ROOT_STATUS, );
--
Re: [PATCH v3] PCI/AER: Do not clear AER bits if we don't own AER
On 08/07/2018 08:14 PM, Bjorn Helgaas wrote:
On Mon, Jul 30, 2018 at 06:35:31PM -0500, Alexandru Gagniuc wrote:
When we don't own AER, we shouldn't touch the AER error bits. Clearing
error bits willy-nilly might cause firmware to miss some errors. In
theory, these bits get cleared by FFS, or via ACPI _HPX method. These
mechanisms are not subject to the problem.
What's FFS?
Firmware-first. Nobody likes spelling it out, and all other proposed
acronyms are insanely tong-twisting. So, FFS.
I guess you mean FFS and _HPX are not subject to the problem because
they're supplied by firmware, so firmware would be responsible for
looking at the bits before clearing them?
Exactly.
This race is mostly of theoretical significance, since I can't
reasonably demonstrate this race in the lab.
On a side-note, pcie_aer_is_kernel_first() is created to alleviate the
need for two checks: aer_cap and get_firmware_first().
Signed-off-by: Alexandru Gagniuc
---
Changes since v2:
- Added missing negation in pci_cleanup_aer_error_status_regs()
drivers/pci/pcie/aer.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index a2e88386af28..40e5c86271d1 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -307,6 +307,12 @@ int pcie_aer_get_firmware_first(struct pci_dev *dev)
aer_set_firmware_first(dev);
return dev->__aer_firmware_first;
}
+
+static bool pcie_aer_is_kernel_first(struct pci_dev *dev)
+{
+ return !!dev->aer_cap && !pcie_aer_get_firmware_first(dev);
+}
I think it complicates things to have both "firmware_first" and
"kernel_first" interfaces, so I would prefer to stick with the
existing "firmware_first" style.
#define PCI_EXP_AER_FLAGS (PCI_EXP_DEVCTL_CERE |
PCI_EXP_DEVCTL_NFERE | \
PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
@@ -337,10 +343,7 @@ bool aer_acpi_firmware_first(void)
int pci_enable_pcie_error_reporting(struct pci_dev *dev)
{
- if (pcie_aer_get_firmware_first(dev))
- return -EIO;
-
- if (!dev->aer_cap)
+ if (!pcie_aer_is_kernel_first(dev))
return -EIO;
return pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_AER_FLAGS);
This change doesn't actually fix anything, does it? It looks like a
cleanup that doesn't change the behavior.
Initially (v1), this was a one-liner, but someone had a complaint about
having pcie_aer_get_firmware_first() boilerplate all over the place.
That's why I added the "kernel_first" function (previous comment), and
then updated this here for completeness. I'm also fine with v1.
@@ -349,7 +352,7 @@ EXPORT_SYMBOL_GPL(pci_enable_pcie_error_reporting);
int pci_disable_pcie_error_reporting(struct pci_dev *dev)
{
- if (pcie_aer_get_firmware_first(dev))
+ if (!pcie_aer_is_kernel_first(dev))
return -EIO;
This change does effectively add a test for dev->aer_cap. That makes
sense in terms of symmetry with pci_enable_pcie_error_reporting(),
but I think it should be a separate patch because it's conceptually
separate from the change below.
We should keep the existing behavior (but add the symmetry) here for
now, but it's not clear to me that these paths should care about AER
or firmware-first at all. PCI_EXP_DEVCTL is not an AER register and
we have the _HPX mechanism for firmware to influence it (which these
paths currently ignore). I suspect we should program these reporting
enable bits in the core enumeration path instead of having drivers
call these interfaces.
The headache is that FFS needs the reporting bit to stay enabled in
order to get AER notifications. Disabling things here could really break
firmware. Of course, that's a cyclical argument, since FW is broken by
definition.
If/when we make changes along these lines, the history will be easier
to follow if *this* change is not connected with the change below to
pci_cleanup_aer_error_status_regs().
I agree. I think it might be preferred then to go with v1, and leave the
refactoring to a later time, since the extra changes are cosmetical and
social.
return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
@@ -383,10 +386,10 @@ int pci_cleanup_aer_error_status_regs(struct pci_dev *dev)
if (!pci_is_pcie(dev))
return -ENODEV;
- pos = dev->aer_cap;
- if (!pos)
+ if (!pcie_aer_is_kernel_first(dev))
return -EIO;
This part makes sense to me, but I think I would rather have it match
the existing style in pci_enable_pcie_error_reporting(), i.e., keep
the test for dev->aer_cap and add a test for
pcie_aer_get_firmware_first().
Had it that way in v1.
Alex
+ pos = dev->aer_cap;
port_type = pci_pcie_type(dev);
if (port_type == PCI_EXP_TYPE_ROOT_PORT) {
pci_read_config_dword(dev, pos + PCI_ERR_ROOT_STATUS, );
--
Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage
Hi Steve,
On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote:
> On Tue, 7 Aug 2018 19:13:32 -0700
> Joel Fernandes wrote:
>> >
>> >> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
>> >> From: "Joel Fernandes (Google)"
>> >> Date: Sun, 5 Aug 2018 20:17:41 -0700
>> >> Subject: [PATCH] tracepoint: Run tracepoints even after CPU is offline
>> >>
>> >> Commit f37755490fe9 ("tracepoints: Do not trace when cpu is offline")
>> >> causes a problem for lockdep using tracepoint code. Once a CPU is
>> >> offline, tracepoints donot get called, however this causes a big problem
>> >> for lockdep probes that need to run so that IRQ annotations are marked
>> >> correctly.
>> >>
>> >> A race is possible where while the CPU is going offline, an interrupt
>> >> can come in and then a lockdep assert causes an annotation warning:
>> >>
>> >> [ 106.551354] IRQs not enabled as expected
>> >> [ 106.551785] WARNING: CPU: 1 PID: 0 at kernel/time/tick-sched.c:982
>> >> tick_nohz_idle_enter+0x99/0xb0
>> >> [ 106.552964] Modules linked in:
>> >> [ 106.553299] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW
>> >>
>> >> We need tracepoints to run as late as possible. This commit fixes the
>> >> issue by removing the cpu_online check in tracepoint code that was
>> >> introduced in the mentioned commit, however we now switch to using SRCU
>> >> for all tracepoints and special handle calling tracepoints from NMI so
>> >> that we don't run into issues that result from using sched-RCU when the
>> >> CPUs are marked to be offline.
>> >>
>> >> Fixes: c3bc8fd637a9 ("tracing: Centralize preemptirq tracepoints and
>> >> unify their usage")
>> >> Reported-by: Masami Hiramatsu
>> >> Signed-off-by: Joel Fernandes (Google)
>> >
>> >
>> > The above change log doesn't look like it matches the NMI patch.
>> >
>> > Can you resend with just the NMI changes? I already handled the cpu
>> > offline ones.
>>
>> Ok, sent with "cpu offline" changes dropped, here it is:
>> https://lore.kernel.org/patchwork/patch/972657/
>>
>> If you could add your Reported-by to it, that would be great as well.
>>
>> >
>> > But I may still have concerns with this patch.
>>
>> Ok let me know what you think.
>>
>
> Not sure you saw this part of my reply:
I missed the part on the srcu handles, sorry.
>
>> @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
>> } while ((++it_func_ptr)->func);\
>> } \
>> \
>> - if (rcuidle)\
>> - srcu_read_unlock_notrace(_srcu, idx);\
>> + srcu_read_unlock_notrace(ss, idx); \
>
> Hmm, why do we have the two different srcu handles?
Because if the memory operations happening on the normal SRCU handle
(during srcu_read_lock) is interrupted by NMI, then the other handle
(devoted to NMI) could be used instead and not bother the interrupted
handle. Does that makes sense?
When I talked to Paul few months ago about SRCU from NMI context, he
mentioned the per-cpu memory operations during srcu_read_lock can be
NMI interrupted, that's why we added that warning.
> Thinking about this, if this can be called by the "thunk" code, then
> there might be an issue. I think the "thunk" code can be called before
> in_nmi() is set, so we don't know if we are in an NMI or not. I need to
> look at that code to make sure. If in_nmi() still works, then we should
> use the _nmi srcu handle (if that's required).
>
> But I'm not sure using SRCU for all tracepoints is needed at this
> moment. I'll have to look deeper into this tomorrow. But it's getting
> close to the merge window, and this needs to be settled quick. Another
> "partial revert" may be needed until this gets settled.
I did read this part, yes I'm not sure either. You mentioned you would
confirm that in the morning, I look forward to it. I hope the in_nmi()
function is reliable to use from here.
RE: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020
> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Wednesday, August 8, 2018 2:44 AM
> To: Bharat Bhushan ;
> b...@kernel.crashing.org; pau...@samba.org; m...@ellerman.id.au;
> ga...@kernel.crashing.org; mark.rutl...@arm.com;
> kstew...@linuxfoundation.org; gre...@linuxfoundation.org;
> devicet...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux-
> ker...@vger.kernel.org
> Cc: r...@kernel.org; keesc...@chromium.org; tyr...@linux.vnet.ibm.com;
> j...@perches.com
> Subject: Re: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020
>
> On Fri, 2018-07-27 at 15:18 +0530, Bharat Bhushan wrote:
> > MPIC on NXP (Freescale) P2020 supports following irq
> > ranges:
> > > 0 - 11 (External interrupt)
> > > 16 - 79 (Internal interrupt)
> > > 176 - 183 (Messaging interrupt)
> > > 224 - 231 (Shared message signaled interrupt)
>
> Why don't you convert to the 4-cell interrupt specifiers that make dealing
> with these ranges less error-prone?
Ok , will do if we agree to have this series as per comment on other patch.
>
> > diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > index 1006950..49ff348 100644
> > --- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > +++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > @@ -57,6 +57,11 @@ void __init mpc85xx_rdb_pic_init(void)
> > MPIC_BIG_ENDIAN |
> > MPIC_SINGLE_DEST_CPU,
> > 0, 256, " OpenPIC ");
> > + } else if (of_machine_is_compatible("fsl,P2020RDB-PC")) {
> > + mpic = mpic_alloc(NULL, 0,
> > + MPIC_BIG_ENDIAN |
> > + MPIC_SINGLE_DEST_CPU,
> > + 0, 0, " OpenPIC ");
> > } else {
> > mpic = mpic_alloc(NULL, 0,
> > MPIC_BIG_ENDIAN |
>
> I don't think we want to grow a list of every single revision of every board
> in
> these platform files.
One other confusing observation I have is that "irq_count" from platform code
is given precedence over "last-interrupt-source" in device-tree.
Should not device-tree should have precedence otherwise there is no point using
" last-interrupt-source" if platform code passes "irq_count" in mpic_alloc().
Thanks
-Bharat
>
> -Scott
Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage
Hi Steve,
On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote:
> On Tue, 7 Aug 2018 19:13:32 -0700
> Joel Fernandes wrote:
>> >
>> >> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
>> >> From: "Joel Fernandes (Google)"
>> >> Date: Sun, 5 Aug 2018 20:17:41 -0700
>> >> Subject: [PATCH] tracepoint: Run tracepoints even after CPU is offline
>> >>
>> >> Commit f37755490fe9 ("tracepoints: Do not trace when cpu is offline")
>> >> causes a problem for lockdep using tracepoint code. Once a CPU is
>> >> offline, tracepoints donot get called, however this causes a big problem
>> >> for lockdep probes that need to run so that IRQ annotations are marked
>> >> correctly.
>> >>
>> >> A race is possible where while the CPU is going offline, an interrupt
>> >> can come in and then a lockdep assert causes an annotation warning:
>> >>
>> >> [ 106.551354] IRQs not enabled as expected
>> >> [ 106.551785] WARNING: CPU: 1 PID: 0 at kernel/time/tick-sched.c:982
>> >> tick_nohz_idle_enter+0x99/0xb0
>> >> [ 106.552964] Modules linked in:
>> >> [ 106.553299] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW
>> >>
>> >> We need tracepoints to run as late as possible. This commit fixes the
>> >> issue by removing the cpu_online check in tracepoint code that was
>> >> introduced in the mentioned commit, however we now switch to using SRCU
>> >> for all tracepoints and special handle calling tracepoints from NMI so
>> >> that we don't run into issues that result from using sched-RCU when the
>> >> CPUs are marked to be offline.
>> >>
>> >> Fixes: c3bc8fd637a9 ("tracing: Centralize preemptirq tracepoints and
>> >> unify their usage")
>> >> Reported-by: Masami Hiramatsu
>> >> Signed-off-by: Joel Fernandes (Google)
>> >
>> >
>> > The above change log doesn't look like it matches the NMI patch.
>> >
>> > Can you resend with just the NMI changes? I already handled the cpu
>> > offline ones.
>>
>> Ok, sent with "cpu offline" changes dropped, here it is:
>> https://lore.kernel.org/patchwork/patch/972657/
>>
>> If you could add your Reported-by to it, that would be great as well.
>>
>> >
>> > But I may still have concerns with this patch.
>>
>> Ok let me know what you think.
>>
>
> Not sure you saw this part of my reply:
I missed the part on the srcu handles, sorry.
>
>> @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
>> } while ((++it_func_ptr)->func);\
>> } \
>> \
>> - if (rcuidle)\
>> - srcu_read_unlock_notrace(_srcu, idx);\
>> + srcu_read_unlock_notrace(ss, idx); \
>
> Hmm, why do we have the two different srcu handles?
Because if the memory operations happening on the normal SRCU handle
(during srcu_read_lock) is interrupted by NMI, then the other handle
(devoted to NMI) could be used instead and not bother the interrupted
handle. Does that makes sense?
When I talked to Paul few months ago about SRCU from NMI context, he
mentioned the per-cpu memory operations during srcu_read_lock can be
NMI interrupted, that's why we added that warning.
> Thinking about this, if this can be called by the "thunk" code, then
> there might be an issue. I think the "thunk" code can be called before
> in_nmi() is set, so we don't know if we are in an NMI or not. I need to
> look at that code to make sure. If in_nmi() still works, then we should
> use the _nmi srcu handle (if that's required).
>
> But I'm not sure using SRCU for all tracepoints is needed at this
> moment. I'll have to look deeper into this tomorrow. But it's getting
> close to the merge window, and this needs to be settled quick. Another
> "partial revert" may be needed until this gets settled.
I did read this part, yes I'm not sure either. You mentioned you would
confirm that in the morning, I look forward to it. I hope the in_nmi()
function is reliable to use from here.
RE: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020
> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Wednesday, August 8, 2018 2:44 AM
> To: Bharat Bhushan ;
> b...@kernel.crashing.org; pau...@samba.org; m...@ellerman.id.au;
> ga...@kernel.crashing.org; mark.rutl...@arm.com;
> kstew...@linuxfoundation.org; gre...@linuxfoundation.org;
> devicet...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux-
> ker...@vger.kernel.org
> Cc: r...@kernel.org; keesc...@chromium.org; tyr...@linux.vnet.ibm.com;
> j...@perches.com
> Subject: Re: [RFC 5/5] powerpc/fsl: Add supported-irq-ranges for P2020
>
> On Fri, 2018-07-27 at 15:18 +0530, Bharat Bhushan wrote:
> > MPIC on NXP (Freescale) P2020 supports following irq
> > ranges:
> > > 0 - 11 (External interrupt)
> > > 16 - 79 (Internal interrupt)
> > > 176 - 183 (Messaging interrupt)
> > > 224 - 231 (Shared message signaled interrupt)
>
> Why don't you convert to the 4-cell interrupt specifiers that make dealing
> with these ranges less error-prone?
Ok , will do if we agree to have this series as per comment on other patch.
>
> > diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > index 1006950..49ff348 100644
> > --- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > +++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> > @@ -57,6 +57,11 @@ void __init mpc85xx_rdb_pic_init(void)
> > MPIC_BIG_ENDIAN |
> > MPIC_SINGLE_DEST_CPU,
> > 0, 256, " OpenPIC ");
> > + } else if (of_machine_is_compatible("fsl,P2020RDB-PC")) {
> > + mpic = mpic_alloc(NULL, 0,
> > + MPIC_BIG_ENDIAN |
> > + MPIC_SINGLE_DEST_CPU,
> > + 0, 0, " OpenPIC ");
> > } else {
> > mpic = mpic_alloc(NULL, 0,
> > MPIC_BIG_ENDIAN |
>
> I don't think we want to grow a list of every single revision of every board
> in
> these platform files.
One other confusing observation I have is that "irq_count" from platform code
is given precedence over "last-interrupt-source" in device-tree.
Should not device-tree should have precedence otherwise there is no point using
" last-interrupt-source" if platform code passes "irq_count" in mpic_alloc().
Thanks
-Bharat
>
> -Scott
Re: [PATCH 2/3] perf report: Add raw report support for s390 auxiliary trace
Thomas Richter writes:
> Add support for s390 auxiliary trace support.
> Use 'perf record -e rbd000' to create the perf.data file.
> The event also has the symbolic name SF_CYCLES_BASIC_DIAG,
> using 'perf record -e SF_CYCLES_BASIC_DIAG' is equivalent.
...
>
> Signed-off-by: Thomas Richter
> Reviewed-by: Hendrik Brueckner
> ---
> tools/perf/util/s390-cpumsf-kernel.h | 71
> tools/perf/util/s390-cpumsf.c| 244 ++-
> 2 files changed, 314 insertions(+), 1 deletion(-)
> create mode 100644 tools/perf/util/s390-cpumsf-kernel.h
I'm seeing a build break on ppc64le which seems to be caused by this
commit (I haven't bisected):
util/s390-cpumsf.c: In function ‘trailer_timestamp’:
util/s390-cpumsf.c:222:2: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
return *((unsigned long long *) >timestamp[te->t]);
^
And on powerpc big endian:
In file included from util/cpumap.h:10:0,
from util/s390-cpumsf.c:150:
util/s390-cpumsf.c: In function ‘s390_cpumsf_basic_show’:
util/s390-cpumsf.c:187:10: error: format ‘%lx’ expects argument of type ‘long
unsigned int’, but argument 4 has type ‘size_t {aka unsigned int}’
[-Werror=format=]
pr_err("Invalid AUX trace basic entry [%#08lx]\n", pos);
^
cheers
RE: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq ranges
> -Original Message- > From: Scott Wood [mailto:o...@buserror.net] > Sent: Wednesday, August 8, 2018 2:34 AM > To: Rob Herring ; Bharat Bhushan > > Cc: b...@kernel.crashing.org; pau...@samba.org; m...@ellerman.id.au; > ga...@kernel.crashing.org; mark.rutl...@arm.com; > kstew...@linuxfoundation.org; gre...@linuxfoundation.org; > devicet...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux- > ker...@vger.kernel.org; keesc...@chromium.org; > tyr...@linux.vnet.ibm.com; j...@perches.com > Subject: Re: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq > ranges > > On Tue, 2018-08-07 at 12:09 -0600, Rob Herring wrote: > > On Fri, Jul 27, 2018 at 03:17:59PM +0530, Bharat Bhushan wrote: > > > Freescale MPIC h/w may not support all interrupt sources reported by > > > hardware, "last-interrupt-source" or platform. On these platforms a > > > misconfigured device tree that assigns one of the reserved > > > interrupts leaves a non-functioning system without warning. > > > > There are lots of ways to misconfigure DTs. I don't think this is > > special and needs a property. > > Yeah, the system will be just as non-functioning if you specify a valid-but- > wrong-for-the-device interrupt number. Some is one additional benefits of this changes, MPIC have reserved regions for un-supported interrupts and read/writes to these reserved regions seams have no effect. MPIC driver reads/writes to the reserved regions during init/uninit and save/restore state. Let me know if it make sense to have these changes for mentioned reasons. Thanks -Bharat > > > We've had some interrupt mask or valid properties in the past, but > > generally don't accept those. > > FWIW, some of them like protected-sources and mpic-msgr-receive-mask > aren't for detecting errors, but are for partitioning (though the former is > obsolete with pic-no-reset). > > -Scott
Re: [PATCH 2/3] perf report: Add raw report support for s390 auxiliary trace
Thomas Richter writes:
> Add support for s390 auxiliary trace support.
> Use 'perf record -e rbd000' to create the perf.data file.
> The event also has the symbolic name SF_CYCLES_BASIC_DIAG,
> using 'perf record -e SF_CYCLES_BASIC_DIAG' is equivalent.
...
>
> Signed-off-by: Thomas Richter
> Reviewed-by: Hendrik Brueckner
> ---
> tools/perf/util/s390-cpumsf-kernel.h | 71
> tools/perf/util/s390-cpumsf.c| 244 ++-
> 2 files changed, 314 insertions(+), 1 deletion(-)
> create mode 100644 tools/perf/util/s390-cpumsf-kernel.h
I'm seeing a build break on ppc64le which seems to be caused by this
commit (I haven't bisected):
util/s390-cpumsf.c: In function ‘trailer_timestamp’:
util/s390-cpumsf.c:222:2: error: dereferencing type-punned pointer will break
strict-aliasing rules [-Werror=strict-aliasing]
return *((unsigned long long *) >timestamp[te->t]);
^
And on powerpc big endian:
In file included from util/cpumap.h:10:0,
from util/s390-cpumsf.c:150:
util/s390-cpumsf.c: In function ‘s390_cpumsf_basic_show’:
util/s390-cpumsf.c:187:10: error: format ‘%lx’ expects argument of type ‘long
unsigned int’, but argument 4 has type ‘size_t {aka unsigned int}’
[-Werror=format=]
pr_err("Invalid AUX trace basic entry [%#08lx]\n", pos);
^
cheers
RE: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq ranges
> -Original Message- > From: Scott Wood [mailto:o...@buserror.net] > Sent: Wednesday, August 8, 2018 2:34 AM > To: Rob Herring ; Bharat Bhushan > > Cc: b...@kernel.crashing.org; pau...@samba.org; m...@ellerman.id.au; > ga...@kernel.crashing.org; mark.rutl...@arm.com; > kstew...@linuxfoundation.org; gre...@linuxfoundation.org; > devicet...@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux- > ker...@vger.kernel.org; keesc...@chromium.org; > tyr...@linux.vnet.ibm.com; j...@perches.com > Subject: Re: [RFC 3/5] powerpc/mpic: Add support for non-contiguous irq > ranges > > On Tue, 2018-08-07 at 12:09 -0600, Rob Herring wrote: > > On Fri, Jul 27, 2018 at 03:17:59PM +0530, Bharat Bhushan wrote: > > > Freescale MPIC h/w may not support all interrupt sources reported by > > > hardware, "last-interrupt-source" or platform. On these platforms a > > > misconfigured device tree that assigns one of the reserved > > > interrupts leaves a non-functioning system without warning. > > > > There are lots of ways to misconfigure DTs. I don't think this is > > special and needs a property. > > Yeah, the system will be just as non-functioning if you specify a valid-but- > wrong-for-the-device interrupt number. Some is one additional benefits of this changes, MPIC have reserved regions for un-supported interrupts and read/writes to these reserved regions seams have no effect. MPIC driver reads/writes to the reserved regions during init/uninit and save/restore state. Let me know if it make sense to have these changes for mentioned reasons. Thanks -Bharat > > > We've had some interrupt mask or valid properties in the past, but > > generally don't accept those. > > FWIW, some of them like protected-sources and mpic-msgr-receive-mask > aren't for detecting errors, but are for partitioning (though the former is > obsolete with pic-no-reset). > > -Scott
[PATCH v4 4/5] Allow to disable FPU support
FPU codes have been separated from common part in previous patches.
This patch add the CONFIG_FPU option and some stubs, so that a no-FPU
configuration is allowed.
Signed-off-by: Alan Kao
Cc: Greentime Hu
Cc: Vincent Chen
Cc: Zong Li
Cc: Nick Hu
---
arch/riscv/Kconfig | 9 +
arch/riscv/include/asm/switch_to.h | 10 ++
arch/riscv/kernel/Makefile | 2 +-
arch/riscv/kernel/process.c| 4 +++-
arch/riscv/kernel/signal.c | 5 +
5 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 6debcc4afc72..6069597ba73f 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -232,6 +232,15 @@ config RISCV_BASE_PMU
endmenu
+config FPU
+ bool "FPU support"
+ default y
+ help
+ Say N here if you want to disable all floating-point related procedure
+ in the kernel.
+
+ If you don't know what to do here, say Y.
+
endmenu
menu "Kernel type"
diff --git a/arch/riscv/include/asm/switch_to.h
b/arch/riscv/include/asm/switch_to.h
index dd6b05bff75b..093050b03543 100644
--- a/arch/riscv/include/asm/switch_to.h
+++ b/arch/riscv/include/asm/switch_to.h
@@ -18,6 +18,7 @@
#include
#include
+#ifdef CONFIG_FPU
extern void __fstate_save(struct task_struct *save_to);
extern void __fstate_restore(struct task_struct *restore_from);
@@ -55,6 +56,15 @@ static inline void __switch_to_aux(struct task_struct *prev,
fstate_restore(next, task_pt_regs(next));
}
+#define DEFAULT_SSTATUS (SR_SPIE | SR_FS_INITIAL)
+
+#else
+#define fstate_save(task, regs) do { } while (0)
+#define fstate_restore(task, regs) do { } while (0)
+#define __switch_to_aux(__prev, __next) do { } while (0)
+#define DEFAULT_SSTATUS (SR_SPIE | SR_FS_OFF)
+#endif
+
extern struct task_struct *__switch_to(struct task_struct *,
struct task_struct *);
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index bd433efd915e..f13f7f276639 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -13,7 +13,6 @@ extra-y += vmlinux.lds
obj-y += cpu.o
obj-y += cpufeature.o
obj-y += entry.o
-obj-y += fpu.o
obj-y += irq.o
obj-y += process.o
obj-y += ptrace.o
@@ -32,6 +31,7 @@ obj-y += vdso/
CFLAGS_setup.o := -mcmodel=medany
+obj-$(CONFIG_FPU) += fpu.o
obj-$(CONFIG_SMP) += smpboot.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_MODULES) += module.o
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index cb209139ba53..3820d89e2db9 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -83,7 +83,7 @@ void show_regs(struct pt_regs *regs)
void start_thread(struct pt_regs *regs, unsigned long pc,
unsigned long sp)
{
- regs->sstatus = SR_SPIE /* User mode, irqs on */ | SR_FS_INITIAL;
+ regs->sstatus = DEFAULT_SSTATUS;
regs->sepc = pc;
regs->sp = sp;
set_fs(USER_DS);
@@ -91,12 +91,14 @@ void start_thread(struct pt_regs *regs, unsigned long pc,
void flush_thread(void)
{
+#ifdef CONFIG_FPU
/*
* Reset FPU context
* frm: round to nearest, ties to even (IEEE default)
* fflags: accrued exceptions cleared
*/
memset(>thread.fstate, 0, sizeof(current->thread.fstate));
+#endif
}
int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
index 6a18b9819ead..2450b824d799 100644
--- a/arch/riscv/kernel/signal.c
+++ b/arch/riscv/kernel/signal.c
@@ -37,6 +37,7 @@ struct rt_sigframe {
struct ucontext uc;
};
+#ifdef CONFIG_FPU
static long restore_fp_state(struct pt_regs *regs,
union __riscv_fp_state *sc_fpregs)
{
@@ -85,6 +86,10 @@ static long save_fp_state(struct pt_regs *regs,
return err;
}
+#else
+#define save_fp_state(task, regs) (0)
+#define restore_fp_state(task, regs) (0)
+#endif
static long restore_sigcontext(struct pt_regs *regs,
struct sigcontext __user *sc)
--
2.18.0
[PATCH v4 4/5] Allow to disable FPU support
FPU codes have been separated from common part in previous patches.
This patch add the CONFIG_FPU option and some stubs, so that a no-FPU
configuration is allowed.
Signed-off-by: Alan Kao
Cc: Greentime Hu
Cc: Vincent Chen
Cc: Zong Li
Cc: Nick Hu
---
arch/riscv/Kconfig | 9 +
arch/riscv/include/asm/switch_to.h | 10 ++
arch/riscv/kernel/Makefile | 2 +-
arch/riscv/kernel/process.c| 4 +++-
arch/riscv/kernel/signal.c | 5 +
5 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 6debcc4afc72..6069597ba73f 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -232,6 +232,15 @@ config RISCV_BASE_PMU
endmenu
+config FPU
+ bool "FPU support"
+ default y
+ help
+ Say N here if you want to disable all floating-point related procedure
+ in the kernel.
+
+ If you don't know what to do here, say Y.
+
endmenu
menu "Kernel type"
diff --git a/arch/riscv/include/asm/switch_to.h
b/arch/riscv/include/asm/switch_to.h
index dd6b05bff75b..093050b03543 100644
--- a/arch/riscv/include/asm/switch_to.h
+++ b/arch/riscv/include/asm/switch_to.h
@@ -18,6 +18,7 @@
#include
#include
+#ifdef CONFIG_FPU
extern void __fstate_save(struct task_struct *save_to);
extern void __fstate_restore(struct task_struct *restore_from);
@@ -55,6 +56,15 @@ static inline void __switch_to_aux(struct task_struct *prev,
fstate_restore(next, task_pt_regs(next));
}
+#define DEFAULT_SSTATUS (SR_SPIE | SR_FS_INITIAL)
+
+#else
+#define fstate_save(task, regs) do { } while (0)
+#define fstate_restore(task, regs) do { } while (0)
+#define __switch_to_aux(__prev, __next) do { } while (0)
+#define DEFAULT_SSTATUS (SR_SPIE | SR_FS_OFF)
+#endif
+
extern struct task_struct *__switch_to(struct task_struct *,
struct task_struct *);
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index bd433efd915e..f13f7f276639 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -13,7 +13,6 @@ extra-y += vmlinux.lds
obj-y += cpu.o
obj-y += cpufeature.o
obj-y += entry.o
-obj-y += fpu.o
obj-y += irq.o
obj-y += process.o
obj-y += ptrace.o
@@ -32,6 +31,7 @@ obj-y += vdso/
CFLAGS_setup.o := -mcmodel=medany
+obj-$(CONFIG_FPU) += fpu.o
obj-$(CONFIG_SMP) += smpboot.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_MODULES) += module.o
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index cb209139ba53..3820d89e2db9 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -83,7 +83,7 @@ void show_regs(struct pt_regs *regs)
void start_thread(struct pt_regs *regs, unsigned long pc,
unsigned long sp)
{
- regs->sstatus = SR_SPIE /* User mode, irqs on */ | SR_FS_INITIAL;
+ regs->sstatus = DEFAULT_SSTATUS;
regs->sepc = pc;
regs->sp = sp;
set_fs(USER_DS);
@@ -91,12 +91,14 @@ void start_thread(struct pt_regs *regs, unsigned long pc,
void flush_thread(void)
{
+#ifdef CONFIG_FPU
/*
* Reset FPU context
* frm: round to nearest, ties to even (IEEE default)
* fflags: accrued exceptions cleared
*/
memset(>thread.fstate, 0, sizeof(current->thread.fstate));
+#endif
}
int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
index 6a18b9819ead..2450b824d799 100644
--- a/arch/riscv/kernel/signal.c
+++ b/arch/riscv/kernel/signal.c
@@ -37,6 +37,7 @@ struct rt_sigframe {
struct ucontext uc;
};
+#ifdef CONFIG_FPU
static long restore_fp_state(struct pt_regs *regs,
union __riscv_fp_state *sc_fpregs)
{
@@ -85,6 +86,10 @@ static long save_fp_state(struct pt_regs *regs,
return err;
}
+#else
+#define save_fp_state(task, regs) (0)
+#define restore_fp_state(task, regs) (0)
+#endif
static long restore_sigcontext(struct pt_regs *regs,
struct sigcontext __user *sc)
--
2.18.0
[PATCH v4 1/5] Extract FPU context operations from entry.S
We move __fstate_save and __fstate_restore to a new source file, fpu.S. Signed-off-by: Alan Kao Cc: Greentime Hu Cc: Vincent Chen Cc: Zong Li Cc: Nick Hu Reviewed-by: Christoph Hellwig --- arch/riscv/kernel/Makefile | 1 + arch/riscv/kernel/entry.S | 87 -- arch/riscv/kernel/fpu.S| 106 + 3 files changed, 107 insertions(+), 87 deletions(-) create mode 100644 arch/riscv/kernel/fpu.S diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile index e1274fc03af4..bd433efd915e 100644 --- a/arch/riscv/kernel/Makefile +++ b/arch/riscv/kernel/Makefile @@ -13,6 +13,7 @@ extra-y += vmlinux.lds obj-y += cpu.o obj-y += cpufeature.o obj-y += entry.o +obj-y += fpu.o obj-y += irq.o obj-y += process.o obj-y += ptrace.o diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S index 9aaf6c986771..edcd5920ee4e 100644 --- a/arch/riscv/kernel/entry.S +++ b/arch/riscv/kernel/entry.S @@ -357,93 +357,6 @@ ENTRY(__switch_to) ret ENDPROC(__switch_to) -ENTRY(__fstate_save) - li a2, TASK_THREAD_F0 - add a0, a0, a2 - li t1, SR_FS - csrs sstatus, t1 - frcsr t0 - fsd f0, TASK_THREAD_F0_F0(a0) - fsd f1, TASK_THREAD_F1_F0(a0) - fsd f2, TASK_THREAD_F2_F0(a0) - fsd f3, TASK_THREAD_F3_F0(a0) - fsd f4, TASK_THREAD_F4_F0(a0) - fsd f5, TASK_THREAD_F5_F0(a0) - fsd f6, TASK_THREAD_F6_F0(a0) - fsd f7, TASK_THREAD_F7_F0(a0) - fsd f8, TASK_THREAD_F8_F0(a0) - fsd f9, TASK_THREAD_F9_F0(a0) - fsd f10, TASK_THREAD_F10_F0(a0) - fsd f11, TASK_THREAD_F11_F0(a0) - fsd f12, TASK_THREAD_F12_F0(a0) - fsd f13, TASK_THREAD_F13_F0(a0) - fsd f14, TASK_THREAD_F14_F0(a0) - fsd f15, TASK_THREAD_F15_F0(a0) - fsd f16, TASK_THREAD_F16_F0(a0) - fsd f17, TASK_THREAD_F17_F0(a0) - fsd f18, TASK_THREAD_F18_F0(a0) - fsd f19, TASK_THREAD_F19_F0(a0) - fsd f20, TASK_THREAD_F20_F0(a0) - fsd f21, TASK_THREAD_F21_F0(a0) - fsd f22, TASK_THREAD_F22_F0(a0) - fsd f23, TASK_THREAD_F23_F0(a0) - fsd f24, TASK_THREAD_F24_F0(a0) - fsd f25, TASK_THREAD_F25_F0(a0) - fsd f26, TASK_THREAD_F26_F0(a0) - fsd f27, TASK_THREAD_F27_F0(a0) - fsd f28, TASK_THREAD_F28_F0(a0) - fsd f29, TASK_THREAD_F29_F0(a0) - fsd f30, TASK_THREAD_F30_F0(a0) - fsd f31, TASK_THREAD_F31_F0(a0) - sw t0, TASK_THREAD_FCSR_F0(a0) - csrc sstatus, t1 - ret -ENDPROC(__fstate_save) - -ENTRY(__fstate_restore) - li a2, TASK_THREAD_F0 - add a0, a0, a2 - li t1, SR_FS - lw t0, TASK_THREAD_FCSR_F0(a0) - csrs sstatus, t1 - fld f0, TASK_THREAD_F0_F0(a0) - fld f1, TASK_THREAD_F1_F0(a0) - fld f2, TASK_THREAD_F2_F0(a0) - fld f3, TASK_THREAD_F3_F0(a0) - fld f4, TASK_THREAD_F4_F0(a0) - fld f5, TASK_THREAD_F5_F0(a0) - fld f6, TASK_THREAD_F6_F0(a0) - fld f7, TASK_THREAD_F7_F0(a0) - fld f8, TASK_THREAD_F8_F0(a0) - fld f9, TASK_THREAD_F9_F0(a0) - fld f10, TASK_THREAD_F10_F0(a0) - fld f11, TASK_THREAD_F11_F0(a0) - fld f12, TASK_THREAD_F12_F0(a0) - fld f13, TASK_THREAD_F13_F0(a0) - fld f14, TASK_THREAD_F14_F0(a0) - fld f15, TASK_THREAD_F15_F0(a0) - fld f16, TASK_THREAD_F16_F0(a0) - fld f17, TASK_THREAD_F17_F0(a0) - fld f18, TASK_THREAD_F18_F0(a0) - fld f19, TASK_THREAD_F19_F0(a0) - fld f20, TASK_THREAD_F20_F0(a0) - fld f21, TASK_THREAD_F21_F0(a0) - fld f22, TASK_THREAD_F22_F0(a0) - fld f23, TASK_THREAD_F23_F0(a0) - fld f24, TASK_THREAD_F24_F0(a0) - fld f25, TASK_THREAD_F25_F0(a0) - fld f26, TASK_THREAD_F26_F0(a0) - fld f27, TASK_THREAD_F27_F0(a0) - fld f28, TASK_THREAD_F28_F0(a0) - fld f29, TASK_THREAD_F29_F0(a0) - fld f30, TASK_THREAD_F30_F0(a0) - fld f31, TASK_THREAD_F31_F0(a0) - fscsr t0 - csrc sstatus, t1 - ret -ENDPROC(__fstate_restore) - - .section ".rodata" /* Exception vector table */ ENTRY(excp_vect_table) diff --git a/arch/riscv/kernel/fpu.S b/arch/riscv/kernel/fpu.S new file mode 100644 index ..1defb0618aff --- /dev/null +++ b/arch/riscv/kernel/fpu.S @@ -0,0 +1,106 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (C) 2012 Regents of the University of California + * Copyright (C) 2017 SiFive + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include + +#include
[PATCH v4 1/5] Extract FPU context operations from entry.S
We move __fstate_save and __fstate_restore to a new source file, fpu.S. Signed-off-by: Alan Kao Cc: Greentime Hu Cc: Vincent Chen Cc: Zong Li Cc: Nick Hu Reviewed-by: Christoph Hellwig --- arch/riscv/kernel/Makefile | 1 + arch/riscv/kernel/entry.S | 87 -- arch/riscv/kernel/fpu.S| 106 + 3 files changed, 107 insertions(+), 87 deletions(-) create mode 100644 arch/riscv/kernel/fpu.S diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile index e1274fc03af4..bd433efd915e 100644 --- a/arch/riscv/kernel/Makefile +++ b/arch/riscv/kernel/Makefile @@ -13,6 +13,7 @@ extra-y += vmlinux.lds obj-y += cpu.o obj-y += cpufeature.o obj-y += entry.o +obj-y += fpu.o obj-y += irq.o obj-y += process.o obj-y += ptrace.o diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S index 9aaf6c986771..edcd5920ee4e 100644 --- a/arch/riscv/kernel/entry.S +++ b/arch/riscv/kernel/entry.S @@ -357,93 +357,6 @@ ENTRY(__switch_to) ret ENDPROC(__switch_to) -ENTRY(__fstate_save) - li a2, TASK_THREAD_F0 - add a0, a0, a2 - li t1, SR_FS - csrs sstatus, t1 - frcsr t0 - fsd f0, TASK_THREAD_F0_F0(a0) - fsd f1, TASK_THREAD_F1_F0(a0) - fsd f2, TASK_THREAD_F2_F0(a0) - fsd f3, TASK_THREAD_F3_F0(a0) - fsd f4, TASK_THREAD_F4_F0(a0) - fsd f5, TASK_THREAD_F5_F0(a0) - fsd f6, TASK_THREAD_F6_F0(a0) - fsd f7, TASK_THREAD_F7_F0(a0) - fsd f8, TASK_THREAD_F8_F0(a0) - fsd f9, TASK_THREAD_F9_F0(a0) - fsd f10, TASK_THREAD_F10_F0(a0) - fsd f11, TASK_THREAD_F11_F0(a0) - fsd f12, TASK_THREAD_F12_F0(a0) - fsd f13, TASK_THREAD_F13_F0(a0) - fsd f14, TASK_THREAD_F14_F0(a0) - fsd f15, TASK_THREAD_F15_F0(a0) - fsd f16, TASK_THREAD_F16_F0(a0) - fsd f17, TASK_THREAD_F17_F0(a0) - fsd f18, TASK_THREAD_F18_F0(a0) - fsd f19, TASK_THREAD_F19_F0(a0) - fsd f20, TASK_THREAD_F20_F0(a0) - fsd f21, TASK_THREAD_F21_F0(a0) - fsd f22, TASK_THREAD_F22_F0(a0) - fsd f23, TASK_THREAD_F23_F0(a0) - fsd f24, TASK_THREAD_F24_F0(a0) - fsd f25, TASK_THREAD_F25_F0(a0) - fsd f26, TASK_THREAD_F26_F0(a0) - fsd f27, TASK_THREAD_F27_F0(a0) - fsd f28, TASK_THREAD_F28_F0(a0) - fsd f29, TASK_THREAD_F29_F0(a0) - fsd f30, TASK_THREAD_F30_F0(a0) - fsd f31, TASK_THREAD_F31_F0(a0) - sw t0, TASK_THREAD_FCSR_F0(a0) - csrc sstatus, t1 - ret -ENDPROC(__fstate_save) - -ENTRY(__fstate_restore) - li a2, TASK_THREAD_F0 - add a0, a0, a2 - li t1, SR_FS - lw t0, TASK_THREAD_FCSR_F0(a0) - csrs sstatus, t1 - fld f0, TASK_THREAD_F0_F0(a0) - fld f1, TASK_THREAD_F1_F0(a0) - fld f2, TASK_THREAD_F2_F0(a0) - fld f3, TASK_THREAD_F3_F0(a0) - fld f4, TASK_THREAD_F4_F0(a0) - fld f5, TASK_THREAD_F5_F0(a0) - fld f6, TASK_THREAD_F6_F0(a0) - fld f7, TASK_THREAD_F7_F0(a0) - fld f8, TASK_THREAD_F8_F0(a0) - fld f9, TASK_THREAD_F9_F0(a0) - fld f10, TASK_THREAD_F10_F0(a0) - fld f11, TASK_THREAD_F11_F0(a0) - fld f12, TASK_THREAD_F12_F0(a0) - fld f13, TASK_THREAD_F13_F0(a0) - fld f14, TASK_THREAD_F14_F0(a0) - fld f15, TASK_THREAD_F15_F0(a0) - fld f16, TASK_THREAD_F16_F0(a0) - fld f17, TASK_THREAD_F17_F0(a0) - fld f18, TASK_THREAD_F18_F0(a0) - fld f19, TASK_THREAD_F19_F0(a0) - fld f20, TASK_THREAD_F20_F0(a0) - fld f21, TASK_THREAD_F21_F0(a0) - fld f22, TASK_THREAD_F22_F0(a0) - fld f23, TASK_THREAD_F23_F0(a0) - fld f24, TASK_THREAD_F24_F0(a0) - fld f25, TASK_THREAD_F25_F0(a0) - fld f26, TASK_THREAD_F26_F0(a0) - fld f27, TASK_THREAD_F27_F0(a0) - fld f28, TASK_THREAD_F28_F0(a0) - fld f29, TASK_THREAD_F29_F0(a0) - fld f30, TASK_THREAD_F30_F0(a0) - fld f31, TASK_THREAD_F31_F0(a0) - fscsr t0 - csrc sstatus, t1 - ret -ENDPROC(__fstate_restore) - - .section ".rodata" /* Exception vector table */ ENTRY(excp_vect_table) diff --git a/arch/riscv/kernel/fpu.S b/arch/riscv/kernel/fpu.S new file mode 100644 index ..1defb0618aff --- /dev/null +++ b/arch/riscv/kernel/fpu.S @@ -0,0 +1,106 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (C) 2012 Regents of the University of California + * Copyright (C) 2017 SiFive + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation, version 2. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include + +#include
[PATCH v4 5/5] Auto-detect whether a FPU exists
We expect that a kernel with CONFIG_FPU=y can still support no-FPU machines.
To do so, the kernel should first examine the existence of a FPU, then
do nothing if a FPU does exist; otherwise, it should disable/bypass all
FPU-related functions.
In this patch, a new global variable, no_fpu, is created and determined
when parsing the hardware capability from device tree during booting.
This variable is used in those FPU-related functions.
Signed-off-by: Alan Kao
Cc: Greentime Hu
Cc: Vincent Chen
Cc: Zong Li
Cc: Nick Hu
---
arch/riscv/include/asm/hwcap.h | 3 +++
arch/riscv/include/asm/switch_to.h | 13 -
arch/riscv/kernel/cpufeature.c | 11 +++
arch/riscv/kernel/signal.c | 6 ++
4 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 8a4ed7bbcbea..1b870086a869 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -33,5 +33,8 @@ enum {
};
extern unsigned long elf_hwcap;
+#ifdef CONFIG_FPU
+extern bool no_fpu;
+#endif
#endif
#endif
diff --git a/arch/riscv/include/asm/switch_to.h
b/arch/riscv/include/asm/switch_to.h
index 093050b03543..7278e3eb7a70 100644
--- a/arch/riscv/include/asm/switch_to.h
+++ b/arch/riscv/include/asm/switch_to.h
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_FPU
extern void __fstate_save(struct task_struct *save_to);
@@ -30,6 +31,9 @@ static inline void __fstate_clean(struct pt_regs *regs)
static inline void fstate_save(struct task_struct *task,
struct pt_regs *regs)
{
+ if (unlikely(no_fpu))
+ return;
+
if ((regs->sstatus & SR_FS) == SR_FS_DIRTY) {
__fstate_save(task);
__fstate_clean(regs);
@@ -39,6 +43,9 @@ static inline void fstate_save(struct task_struct *task,
static inline void fstate_restore(struct task_struct *task,
struct pt_regs *regs)
{
+ if (unlikely(no_fpu))
+ return;
+
if ((regs->sstatus & SR_FS) != SR_FS_OFF) {
__fstate_restore(task);
__fstate_clean(regs);
@@ -50,13 +57,17 @@ static inline void __switch_to_aux(struct task_struct *prev,
{
struct pt_regs *regs;
+ if (unlikely(no_fpu))
+ return;
+
regs = task_pt_regs(prev);
if (unlikely(regs->sstatus & SR_SD))
fstate_save(prev, regs);
fstate_restore(next, task_pt_regs(next));
}
-#define DEFAULT_SSTATUS (SR_SPIE | SR_FS_INITIAL)
+#define DEFAULT_SSTATUS \
+ ((unlikely(no_fpu)) ? (SR_SPIE | SR_FS_OFF) : (SR_SPIE | SR_FS_INITIAL))
#else
#define fstate_save(task, regs) do { } while (0)
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 17011a870044..bc269c1e0b1a 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -22,6 +22,9 @@
#include
unsigned long elf_hwcap __read_mostly;
+#ifdef CONFIG_FPU
+bool no_fpu __read_mostly;
+#endif
void riscv_fill_hwcap(void)
{
@@ -58,4 +61,12 @@ void riscv_fill_hwcap(void)
elf_hwcap |= isa2hwcap[(unsigned char)(isa[i])];
pr_info("elf_hwcap is 0x%lx", elf_hwcap);
+
+#ifdef CONFIG_FPU
+ no_fpu = 0;
+ if (!(elf_hwcap & (COMPAT_HWCAP_ISA_F | COMPAT_HWCAP_ISA_D))) {
+ pr_info("Bypass FPU code.");
+ no_fpu = 1;
+ }
+#endif
}
diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
index 2450b824d799..9714e4fccb69 100644
--- a/arch/riscv/kernel/signal.c
+++ b/arch/riscv/kernel/signal.c
@@ -45,6 +45,9 @@ static long restore_fp_state(struct pt_regs *regs,
struct __riscv_d_ext_state __user *state = _fpregs->d;
size_t i;
+ if (unlikely(no_fpu))
+ return 0;
+
err = __copy_from_user(>thread.fstate, state, sizeof(*state));
if (unlikely(err))
return err;
@@ -72,6 +75,9 @@ static long save_fp_state(struct pt_regs *regs,
struct __riscv_d_ext_state __user *state = _fpregs->d;
size_t i;
+ if (unlikely(no_fpu))
+ return 0;
+
fstate_save(current, regs);
err = __copy_to_user(state, >thread.fstate, sizeof(*state));
if (unlikely(err))
--
2.18.0
[PATCH v4 2/5] Refactor FPU code in signal setup/return procedures
FPU-related logic is separated from normal signal handling path in
this patch. Kernel can easily be configured to exclude those procedures
for no-FPU systems.
Signed-off-by: Alan Kao
Cc: Greentime Hu
Cc: Vincent Chen
Cc: Zong Li
Cc: Nick Hu
Reviewed-by: Christoph Hellwig
---
arch/riscv/kernel/signal.c | 68 +++---
1 file changed, 41 insertions(+), 27 deletions(-)
diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
index 718d0c984ef0..6a18b9819ead 100644
--- a/arch/riscv/kernel/signal.c
+++ b/arch/riscv/kernel/signal.c
@@ -37,45 +37,63 @@ struct rt_sigframe {
struct ucontext uc;
};
-static long restore_d_state(struct pt_regs *regs,
- struct __riscv_d_ext_state __user *state)
+static long restore_fp_state(struct pt_regs *regs,
+union __riscv_fp_state *sc_fpregs)
{
long err;
+ struct __riscv_d_ext_state __user *state = _fpregs->d;
+ size_t i;
+
err = __copy_from_user(>thread.fstate, state, sizeof(*state));
- if (likely(!err))
- fstate_restore(current, regs);
+ if (unlikely(err))
+ return err;
+
+ fstate_restore(current, regs);
+
+ /* We support no other extension state at this time. */
+ for (i = 0; i < ARRAY_SIZE(sc_fpregs->q.reserved); i++) {
+ u32 value;
+
+ err = __get_user(value, _fpregs->q.reserved[i]);
+ if (unlikely(err))
+ break;
+ if (value != 0)
+ return -EINVAL;
+ }
+
return err;
}
-static long save_d_state(struct pt_regs *regs,
- struct __riscv_d_ext_state __user *state)
+static long save_fp_state(struct pt_regs *regs,
+ union __riscv_fp_state *sc_fpregs)
{
+ long err;
+ struct __riscv_d_ext_state __user *state = _fpregs->d;
+ size_t i;
+
fstate_save(current, regs);
- return __copy_to_user(state, >thread.fstate, sizeof(*state));
+ err = __copy_to_user(state, >thread.fstate, sizeof(*state));
+ if (unlikely(err))
+ return err;
+
+ /* We support no other extension state at this time. */
+ for (i = 0; i < ARRAY_SIZE(sc_fpregs->q.reserved); i++) {
+ err = __put_user(0, _fpregs->q.reserved[i]);
+ if (unlikely(err))
+ break;
+ }
+
+ return err;
}
static long restore_sigcontext(struct pt_regs *regs,
struct sigcontext __user *sc)
{
long err;
- size_t i;
/* sc_regs is structured the same as the start of pt_regs */
err = __copy_from_user(regs, >sc_regs, sizeof(sc->sc_regs));
- if (unlikely(err))
- return err;
/* Restore the floating-point state. */
- err = restore_d_state(regs, >sc_fpregs.d);
- if (unlikely(err))
- return err;
- /* We support no other extension state at this time. */
- for (i = 0; i < ARRAY_SIZE(sc->sc_fpregs.q.reserved); i++) {
- u32 value;
- err = __get_user(value, >sc_fpregs.q.reserved[i]);
- if (unlikely(err))
- break;
- if (value != 0)
- return -EINVAL;
- }
+ err |= restore_fp_state(regs, >sc_fpregs);
return err;
}
@@ -124,14 +142,10 @@ static long setup_sigcontext(struct rt_sigframe __user
*frame,
{
struct sigcontext __user *sc = >uc.uc_mcontext;
long err;
- size_t i;
/* sc_regs is structured the same as the start of pt_regs */
err = __copy_to_user(>sc_regs, regs, sizeof(sc->sc_regs));
/* Save the floating-point state. */
- err |= save_d_state(regs, >sc_fpregs.d);
- /* We support no other extension state at this time. */
- for (i = 0; i < ARRAY_SIZE(sc->sc_fpregs.q.reserved); i++)
- err |= __put_user(0, >sc_fpregs.q.reserved[i]);
+ err |= save_fp_state(regs, >sc_fpregs);
return err;
}
--
2.18.0
[PATCH v4 3/5] Cleanup ISA string setting
Just a side note: (Assume that atomic and compressed is on) Before this patch, assembler was always given the riscv64imafdc MARCH string because there are fld/fsd's in entry.S; compiler was always given riscv64imac because kernel doesn't need floating point code generation. After this, the MARCH string in AFLAGS and CFLAGS become the same. Signed-off-by: Alan Kao Cc: Greentime Hu Cc: Vincent Chen Cc: Zong Li Cc: Nick Hu Reviewed-by: Christoph Hellwig --- arch/riscv/Makefile | 19 --- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile index 6d4a5f6c3f4f..e0fe6790624f 100644 --- a/arch/riscv/Makefile +++ b/arch/riscv/Makefile @@ -26,7 +26,6 @@ ifeq ($(CONFIG_ARCH_RV64I),y) KBUILD_CFLAGS += -mabi=lp64 KBUILD_AFLAGS += -mabi=lp64 - KBUILD_MARCH = rv64im LDFLAGS += -melf64lriscv else BITS := 32 @@ -34,22 +33,20 @@ else KBUILD_CFLAGS += -mabi=ilp32 KBUILD_AFLAGS += -mabi=ilp32 - KBUILD_MARCH = rv32im LDFLAGS += -melf32lriscv endif KBUILD_CFLAGS += -Wall -ifeq ($(CONFIG_RISCV_ISA_A),y) - KBUILD_ARCH_A = a -endif -ifeq ($(CONFIG_RISCV_ISA_C),y) - KBUILD_ARCH_C = c -endif - -KBUILD_AFLAGS += -march=$(KBUILD_MARCH)$(KBUILD_ARCH_A)fd$(KBUILD_ARCH_C) +# ISA string setting +riscv-march-$(CONFIG_ARCH_RV32I) := rv32im +riscv-march-$(CONFIG_ARCH_RV64I) := rv64im +riscv-march-$(CONFIG_RISCV_ISA_A) := $(riscv-march-y)a +riscv-march-y := $(riscv-march-y)fd +riscv-march-$(CONFIG_RISCV_ISA_C) := $(riscv-march-y)c +KBUILD_CFLAGS += -march=$(riscv-march-y) +KBUILD_AFLAGS += -march=$(riscv-march-y) -KBUILD_CFLAGS += -march=$(KBUILD_MARCH)$(KBUILD_ARCH_A)$(KBUILD_ARCH_C) KBUILD_CFLAGS += -mno-save-restore KBUILD_CFLAGS += -DCONFIG_PAGE_OFFSET=$(CONFIG_PAGE_OFFSET) -- 2.18.0
[PATCH v4 5/5] Auto-detect whether a FPU exists
We expect that a kernel with CONFIG_FPU=y can still support no-FPU machines.
To do so, the kernel should first examine the existence of a FPU, then
do nothing if a FPU does exist; otherwise, it should disable/bypass all
FPU-related functions.
In this patch, a new global variable, no_fpu, is created and determined
when parsing the hardware capability from device tree during booting.
This variable is used in those FPU-related functions.
Signed-off-by: Alan Kao
Cc: Greentime Hu
Cc: Vincent Chen
Cc: Zong Li
Cc: Nick Hu
---
arch/riscv/include/asm/hwcap.h | 3 +++
arch/riscv/include/asm/switch_to.h | 13 -
arch/riscv/kernel/cpufeature.c | 11 +++
arch/riscv/kernel/signal.c | 6 ++
4 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 8a4ed7bbcbea..1b870086a869 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -33,5 +33,8 @@ enum {
};
extern unsigned long elf_hwcap;
+#ifdef CONFIG_FPU
+extern bool no_fpu;
+#endif
#endif
#endif
diff --git a/arch/riscv/include/asm/switch_to.h
b/arch/riscv/include/asm/switch_to.h
index 093050b03543..7278e3eb7a70 100644
--- a/arch/riscv/include/asm/switch_to.h
+++ b/arch/riscv/include/asm/switch_to.h
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_FPU
extern void __fstate_save(struct task_struct *save_to);
@@ -30,6 +31,9 @@ static inline void __fstate_clean(struct pt_regs *regs)
static inline void fstate_save(struct task_struct *task,
struct pt_regs *regs)
{
+ if (unlikely(no_fpu))
+ return;
+
if ((regs->sstatus & SR_FS) == SR_FS_DIRTY) {
__fstate_save(task);
__fstate_clean(regs);
@@ -39,6 +43,9 @@ static inline void fstate_save(struct task_struct *task,
static inline void fstate_restore(struct task_struct *task,
struct pt_regs *regs)
{
+ if (unlikely(no_fpu))
+ return;
+
if ((regs->sstatus & SR_FS) != SR_FS_OFF) {
__fstate_restore(task);
__fstate_clean(regs);
@@ -50,13 +57,17 @@ static inline void __switch_to_aux(struct task_struct *prev,
{
struct pt_regs *regs;
+ if (unlikely(no_fpu))
+ return;
+
regs = task_pt_regs(prev);
if (unlikely(regs->sstatus & SR_SD))
fstate_save(prev, regs);
fstate_restore(next, task_pt_regs(next));
}
-#define DEFAULT_SSTATUS (SR_SPIE | SR_FS_INITIAL)
+#define DEFAULT_SSTATUS \
+ ((unlikely(no_fpu)) ? (SR_SPIE | SR_FS_OFF) : (SR_SPIE | SR_FS_INITIAL))
#else
#define fstate_save(task, regs) do { } while (0)
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 17011a870044..bc269c1e0b1a 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -22,6 +22,9 @@
#include
unsigned long elf_hwcap __read_mostly;
+#ifdef CONFIG_FPU
+bool no_fpu __read_mostly;
+#endif
void riscv_fill_hwcap(void)
{
@@ -58,4 +61,12 @@ void riscv_fill_hwcap(void)
elf_hwcap |= isa2hwcap[(unsigned char)(isa[i])];
pr_info("elf_hwcap is 0x%lx", elf_hwcap);
+
+#ifdef CONFIG_FPU
+ no_fpu = 0;
+ if (!(elf_hwcap & (COMPAT_HWCAP_ISA_F | COMPAT_HWCAP_ISA_D))) {
+ pr_info("Bypass FPU code.");
+ no_fpu = 1;
+ }
+#endif
}
diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
index 2450b824d799..9714e4fccb69 100644
--- a/arch/riscv/kernel/signal.c
+++ b/arch/riscv/kernel/signal.c
@@ -45,6 +45,9 @@ static long restore_fp_state(struct pt_regs *regs,
struct __riscv_d_ext_state __user *state = _fpregs->d;
size_t i;
+ if (unlikely(no_fpu))
+ return 0;
+
err = __copy_from_user(>thread.fstate, state, sizeof(*state));
if (unlikely(err))
return err;
@@ -72,6 +75,9 @@ static long save_fp_state(struct pt_regs *regs,
struct __riscv_d_ext_state __user *state = _fpregs->d;
size_t i;
+ if (unlikely(no_fpu))
+ return 0;
+
fstate_save(current, regs);
err = __copy_to_user(state, >thread.fstate, sizeof(*state));
if (unlikely(err))
--
2.18.0
[PATCH v4 2/5] Refactor FPU code in signal setup/return procedures
FPU-related logic is separated from normal signal handling path in
this patch. Kernel can easily be configured to exclude those procedures
for no-FPU systems.
Signed-off-by: Alan Kao
Cc: Greentime Hu
Cc: Vincent Chen
Cc: Zong Li
Cc: Nick Hu
Reviewed-by: Christoph Hellwig
---
arch/riscv/kernel/signal.c | 68 +++---
1 file changed, 41 insertions(+), 27 deletions(-)
diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
index 718d0c984ef0..6a18b9819ead 100644
--- a/arch/riscv/kernel/signal.c
+++ b/arch/riscv/kernel/signal.c
@@ -37,45 +37,63 @@ struct rt_sigframe {
struct ucontext uc;
};
-static long restore_d_state(struct pt_regs *regs,
- struct __riscv_d_ext_state __user *state)
+static long restore_fp_state(struct pt_regs *regs,
+union __riscv_fp_state *sc_fpregs)
{
long err;
+ struct __riscv_d_ext_state __user *state = _fpregs->d;
+ size_t i;
+
err = __copy_from_user(>thread.fstate, state, sizeof(*state));
- if (likely(!err))
- fstate_restore(current, regs);
+ if (unlikely(err))
+ return err;
+
+ fstate_restore(current, regs);
+
+ /* We support no other extension state at this time. */
+ for (i = 0; i < ARRAY_SIZE(sc_fpregs->q.reserved); i++) {
+ u32 value;
+
+ err = __get_user(value, _fpregs->q.reserved[i]);
+ if (unlikely(err))
+ break;
+ if (value != 0)
+ return -EINVAL;
+ }
+
return err;
}
-static long save_d_state(struct pt_regs *regs,
- struct __riscv_d_ext_state __user *state)
+static long save_fp_state(struct pt_regs *regs,
+ union __riscv_fp_state *sc_fpregs)
{
+ long err;
+ struct __riscv_d_ext_state __user *state = _fpregs->d;
+ size_t i;
+
fstate_save(current, regs);
- return __copy_to_user(state, >thread.fstate, sizeof(*state));
+ err = __copy_to_user(state, >thread.fstate, sizeof(*state));
+ if (unlikely(err))
+ return err;
+
+ /* We support no other extension state at this time. */
+ for (i = 0; i < ARRAY_SIZE(sc_fpregs->q.reserved); i++) {
+ err = __put_user(0, _fpregs->q.reserved[i]);
+ if (unlikely(err))
+ break;
+ }
+
+ return err;
}
static long restore_sigcontext(struct pt_regs *regs,
struct sigcontext __user *sc)
{
long err;
- size_t i;
/* sc_regs is structured the same as the start of pt_regs */
err = __copy_from_user(regs, >sc_regs, sizeof(sc->sc_regs));
- if (unlikely(err))
- return err;
/* Restore the floating-point state. */
- err = restore_d_state(regs, >sc_fpregs.d);
- if (unlikely(err))
- return err;
- /* We support no other extension state at this time. */
- for (i = 0; i < ARRAY_SIZE(sc->sc_fpregs.q.reserved); i++) {
- u32 value;
- err = __get_user(value, >sc_fpregs.q.reserved[i]);
- if (unlikely(err))
- break;
- if (value != 0)
- return -EINVAL;
- }
+ err |= restore_fp_state(regs, >sc_fpregs);
return err;
}
@@ -124,14 +142,10 @@ static long setup_sigcontext(struct rt_sigframe __user
*frame,
{
struct sigcontext __user *sc = >uc.uc_mcontext;
long err;
- size_t i;
/* sc_regs is structured the same as the start of pt_regs */
err = __copy_to_user(>sc_regs, regs, sizeof(sc->sc_regs));
/* Save the floating-point state. */
- err |= save_d_state(regs, >sc_fpregs.d);
- /* We support no other extension state at this time. */
- for (i = 0; i < ARRAY_SIZE(sc->sc_fpregs.q.reserved); i++)
- err |= __put_user(0, >sc_fpregs.q.reserved[i]);
+ err |= save_fp_state(regs, >sc_fpregs);
return err;
}
--
2.18.0
[PATCH v4 3/5] Cleanup ISA string setting
Just a side note: (Assume that atomic and compressed is on) Before this patch, assembler was always given the riscv64imafdc MARCH string because there are fld/fsd's in entry.S; compiler was always given riscv64imac because kernel doesn't need floating point code generation. After this, the MARCH string in AFLAGS and CFLAGS become the same. Signed-off-by: Alan Kao Cc: Greentime Hu Cc: Vincent Chen Cc: Zong Li Cc: Nick Hu Reviewed-by: Christoph Hellwig --- arch/riscv/Makefile | 19 --- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile index 6d4a5f6c3f4f..e0fe6790624f 100644 --- a/arch/riscv/Makefile +++ b/arch/riscv/Makefile @@ -26,7 +26,6 @@ ifeq ($(CONFIG_ARCH_RV64I),y) KBUILD_CFLAGS += -mabi=lp64 KBUILD_AFLAGS += -mabi=lp64 - KBUILD_MARCH = rv64im LDFLAGS += -melf64lriscv else BITS := 32 @@ -34,22 +33,20 @@ else KBUILD_CFLAGS += -mabi=ilp32 KBUILD_AFLAGS += -mabi=ilp32 - KBUILD_MARCH = rv32im LDFLAGS += -melf32lriscv endif KBUILD_CFLAGS += -Wall -ifeq ($(CONFIG_RISCV_ISA_A),y) - KBUILD_ARCH_A = a -endif -ifeq ($(CONFIG_RISCV_ISA_C),y) - KBUILD_ARCH_C = c -endif - -KBUILD_AFLAGS += -march=$(KBUILD_MARCH)$(KBUILD_ARCH_A)fd$(KBUILD_ARCH_C) +# ISA string setting +riscv-march-$(CONFIG_ARCH_RV32I) := rv32im +riscv-march-$(CONFIG_ARCH_RV64I) := rv64im +riscv-march-$(CONFIG_RISCV_ISA_A) := $(riscv-march-y)a +riscv-march-y := $(riscv-march-y)fd +riscv-march-$(CONFIG_RISCV_ISA_C) := $(riscv-march-y)c +KBUILD_CFLAGS += -march=$(riscv-march-y) +KBUILD_AFLAGS += -march=$(riscv-march-y) -KBUILD_CFLAGS += -march=$(KBUILD_MARCH)$(KBUILD_ARCH_A)$(KBUILD_ARCH_C) KBUILD_CFLAGS += -mno-save-restore KBUILD_CFLAGS += -DCONFIG_PAGE_OFFSET=$(CONFIG_PAGE_OFFSET) -- 2.18.0
[PATCH v4 0/5] riscv: Add support to no-FPU systems
This patchset adds an option, CONFIG_FPU, to enable/disable floating- point procedures. Kernel's new behavior will be as follows: * with CONFIG_FPU=y All FPU codes are reserved. If no FPU is found during booting, a global flag will be set, and those functions will be bypassed with condition check to that flag. * with CONFIG_FPU=n No floating-point instructions in kernel and all related settings are excluded. Changes in v4: - Append a new patch to detect existence of FPU and followups. - Add SPDX header to newly created fpu.S. - Fix a build error, sorry for that. - Fix wording, style, etc. Changes in v3: - Refactor the whole patch into independent ones. Changes in v2: - Various code cleanups and style fixes. Alan Kao (5): Extract FPU context operations from entry.S Refactor FPU code in signal setup/return procedures Cleanup ISA string setting Allow to disable FPU support Auto-detect whether a FPU exists arch/riscv/Kconfig | 9 +++ arch/riscv/Makefile| 19 +++--- arch/riscv/include/asm/hwcap.h | 3 + arch/riscv/include/asm/switch_to.h | 21 ++ arch/riscv/kernel/Makefile | 1 + arch/riscv/kernel/cpufeature.c | 11 +++ arch/riscv/kernel/entry.S | 87 --- arch/riscv/kernel/fpu.S| 106 + arch/riscv/kernel/process.c| 4 +- arch/riscv/kernel/signal.c | 79 + 10 files changed, 214 insertions(+), 126 deletions(-) create mode 100644 arch/riscv/kernel/fpu.S -- 2.18.0
[PATCH v4 0/5] riscv: Add support to no-FPU systems
This patchset adds an option, CONFIG_FPU, to enable/disable floating- point procedures. Kernel's new behavior will be as follows: * with CONFIG_FPU=y All FPU codes are reserved. If no FPU is found during booting, a global flag will be set, and those functions will be bypassed with condition check to that flag. * with CONFIG_FPU=n No floating-point instructions in kernel and all related settings are excluded. Changes in v4: - Append a new patch to detect existence of FPU and followups. - Add SPDX header to newly created fpu.S. - Fix a build error, sorry for that. - Fix wording, style, etc. Changes in v3: - Refactor the whole patch into independent ones. Changes in v2: - Various code cleanups and style fixes. Alan Kao (5): Extract FPU context operations from entry.S Refactor FPU code in signal setup/return procedures Cleanup ISA string setting Allow to disable FPU support Auto-detect whether a FPU exists arch/riscv/Kconfig | 9 +++ arch/riscv/Makefile| 19 +++--- arch/riscv/include/asm/hwcap.h | 3 + arch/riscv/include/asm/switch_to.h | 21 ++ arch/riscv/kernel/Makefile | 1 + arch/riscv/kernel/cpufeature.c | 11 +++ arch/riscv/kernel/entry.S | 87 --- arch/riscv/kernel/fpu.S| 106 + arch/riscv/kernel/process.c| 4 +- arch/riscv/kernel/signal.c | 79 + 10 files changed, 214 insertions(+), 126 deletions(-) create mode 100644 arch/riscv/kernel/fpu.S -- 2.18.0
Re: [PATCH 2/2] spi: sprd: Add SPI driver for Spreadtrum SC9860
Hi Trent,
On 8 August 2018 at 01:10, Trent Piepho wrote:
> On Tue, 2018-08-07 at 18:43 +0800, Baolin Wang wrote:
>>
>> +static u32 sprd_spi_transfer_max_timeout(struct sprd_spi *ss,
>> + struct spi_transfer *t)
>> +{
>> + /*
>> + * The time spent on transmission of the full FIFO data is the maximum
>> + * SPI transmission time.
>> + */
>> + u32 size = t->bits_per_word * SPRD_SPI_FIFO_SIZE;
>> + u32 bit_time_us = SPRD_SPI_HZ / t->speed_hz + 1;
>> + u32 total_time_us = size * bit_time_us;
>> + /*
>> + * There is an interval between data and the data in our SPI hardware,
>> + * so the total transmission time need add the interval time.
>> + *
>> + * The inteval calculation formula:
>> + * interval time (source clock cycles) = interval * 4 + 10.
>> + */
>> + u32 interval_cycle = SPRD_SPI_FIFO_SIZE * ((ss->interval << 2) + 10);
>> + u32 interval_time_us = interval_cycle * SPRD_SPI_HZ / ss->src_clk + 1;
>
> If interval is greater than 31, this will overflow.
Usually we will not set such a big value for interval, but this is a
risk like you said. So we will check and limit the interval value to
make sure the formula will not overflow.
>
> Also SPRD_SPI_HZ is not the speed anything runs at, as one might think
> from the name. It's the number of microseconds in a second. The is
> already a Linux macro for that, USEC_PER_SEC, that you should use
> instead.
Right, will use USEC_PER_SEC instead.
>
>> +
>> + return total_time_us + interval_time_us;
>> +}
>> +
>
>
>> +static void sprd_spi_set_speed(struct sprd_spi *ss, u32 speed_hz)
>> +{
>> + /*
>> + * From SPI datasheet, the prescale calculation formula:
>> + * prescale = SPI source clock / (2 * SPI_freq) - 1;
>> + */
>> + u32 clk_div = ss->src_clk / (speed_hz << 1) - 1;
>
> You should probably round up here. The convention is to use the
> closest speed less than equal to the requested speed, but since this is
> a divider, rounding it down will select the next highest speed.
Per the datasheet, we do not need round up/down the speed. Since our
hardware can handle the clock calculated by the above formula if the
requested speed is in the normal region (less than ->max_speed_hz).
>> +
>> + writel_relaxed(clk_div, ss->base + SPRD_SPI_CLKD);
>> +}
>> +
>
>> +
>> +static int sprd_spi_probe(struct platform_device *pdev)
>> +{
>> + struct device_node *np = pdev->dev.of_node;
>> + struct spi_controller *sctlr;
>> + struct resource *res;
>> + struct sprd_spi *ss;
>> + int ret;
>> +
>> + pdev->id = of_alias_get_id(pdev->dev.of_node, "spi");
>> + sctlr = spi_alloc_master(>dev, sizeof(*ss));
>> + if (!sctlr)
>> + return -ENOMEM;
>> +
>> + ss = spi_controller_get_devdata(sctlr);
>> + if (of_property_read_u32(np, "sprd,spi-interval", >interval))
>> + ss->interval = SPRD_SPI_ITVL_NUM;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + ss->base = devm_ioremap_resource(>dev, res);
>> + if (IS_ERR(ss->base)) {
>> + ret = PTR_ERR(ss->base);
>> + goto free_controller;
>> + }
>> +
>> + ss->dev = >dev;
>> + sctlr->dev.of_node = pdev->dev.of_node;
>> + sctlr->mode_bits = SPI_CPOL | SPI_CPHA | SPI_3WIRE | SPI_TX_DUAL;
>> + sctlr->bus_num = pdev->id;
>> + sctlr->setup = sprd_spi_setup;
>> + sctlr->set_cs = sprd_spi_chipselect;
>> + sctlr->transfer_one = sprd_spi_transfer_one;
>> + sctlr->max_speed_hz = (ss->src_clk / 2) < SPRD_SPI_MAX_SPEED_HZ ?
>> + ss->src_clk / 2 : SPRD_SPI_MAX_SPEED_HZ;
>
> You can write this as:
> sctlr->max_speed_hz = min(ss->src_clk / 2, SPRD_SPI_MAX_SPEED_HZ);
Right. Thanks for your comments.
--
Baolin Wang
Best Regards
Re: [PATCH 2/2] spi: sprd: Add SPI driver for Spreadtrum SC9860
Hi Trent,
On 8 August 2018 at 01:10, Trent Piepho wrote:
> On Tue, 2018-08-07 at 18:43 +0800, Baolin Wang wrote:
>>
>> +static u32 sprd_spi_transfer_max_timeout(struct sprd_spi *ss,
>> + struct spi_transfer *t)
>> +{
>> + /*
>> + * The time spent on transmission of the full FIFO data is the maximum
>> + * SPI transmission time.
>> + */
>> + u32 size = t->bits_per_word * SPRD_SPI_FIFO_SIZE;
>> + u32 bit_time_us = SPRD_SPI_HZ / t->speed_hz + 1;
>> + u32 total_time_us = size * bit_time_us;
>> + /*
>> + * There is an interval between data and the data in our SPI hardware,
>> + * so the total transmission time need add the interval time.
>> + *
>> + * The inteval calculation formula:
>> + * interval time (source clock cycles) = interval * 4 + 10.
>> + */
>> + u32 interval_cycle = SPRD_SPI_FIFO_SIZE * ((ss->interval << 2) + 10);
>> + u32 interval_time_us = interval_cycle * SPRD_SPI_HZ / ss->src_clk + 1;
>
> If interval is greater than 31, this will overflow.
Usually we will not set such a big value for interval, but this is a
risk like you said. So we will check and limit the interval value to
make sure the formula will not overflow.
>
> Also SPRD_SPI_HZ is not the speed anything runs at, as one might think
> from the name. It's the number of microseconds in a second. The is
> already a Linux macro for that, USEC_PER_SEC, that you should use
> instead.
Right, will use USEC_PER_SEC instead.
>
>> +
>> + return total_time_us + interval_time_us;
>> +}
>> +
>
>
>> +static void sprd_spi_set_speed(struct sprd_spi *ss, u32 speed_hz)
>> +{
>> + /*
>> + * From SPI datasheet, the prescale calculation formula:
>> + * prescale = SPI source clock / (2 * SPI_freq) - 1;
>> + */
>> + u32 clk_div = ss->src_clk / (speed_hz << 1) - 1;
>
> You should probably round up here. The convention is to use the
> closest speed less than equal to the requested speed, but since this is
> a divider, rounding it down will select the next highest speed.
Per the datasheet, we do not need round up/down the speed. Since our
hardware can handle the clock calculated by the above formula if the
requested speed is in the normal region (less than ->max_speed_hz).
>> +
>> + writel_relaxed(clk_div, ss->base + SPRD_SPI_CLKD);
>> +}
>> +
>
>> +
>> +static int sprd_spi_probe(struct platform_device *pdev)
>> +{
>> + struct device_node *np = pdev->dev.of_node;
>> + struct spi_controller *sctlr;
>> + struct resource *res;
>> + struct sprd_spi *ss;
>> + int ret;
>> +
>> + pdev->id = of_alias_get_id(pdev->dev.of_node, "spi");
>> + sctlr = spi_alloc_master(>dev, sizeof(*ss));
>> + if (!sctlr)
>> + return -ENOMEM;
>> +
>> + ss = spi_controller_get_devdata(sctlr);
>> + if (of_property_read_u32(np, "sprd,spi-interval", >interval))
>> + ss->interval = SPRD_SPI_ITVL_NUM;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + ss->base = devm_ioremap_resource(>dev, res);
>> + if (IS_ERR(ss->base)) {
>> + ret = PTR_ERR(ss->base);
>> + goto free_controller;
>> + }
>> +
>> + ss->dev = >dev;
>> + sctlr->dev.of_node = pdev->dev.of_node;
>> + sctlr->mode_bits = SPI_CPOL | SPI_CPHA | SPI_3WIRE | SPI_TX_DUAL;
>> + sctlr->bus_num = pdev->id;
>> + sctlr->setup = sprd_spi_setup;
>> + sctlr->set_cs = sprd_spi_chipselect;
>> + sctlr->transfer_one = sprd_spi_transfer_one;
>> + sctlr->max_speed_hz = (ss->src_clk / 2) < SPRD_SPI_MAX_SPEED_HZ ?
>> + ss->src_clk / 2 : SPRD_SPI_MAX_SPEED_HZ;
>
> You can write this as:
> sctlr->max_speed_hz = min(ss->src_clk / 2, SPRD_SPI_MAX_SPEED_HZ);
Right. Thanks for your comments.
--
Baolin Wang
Best Regards
Re: [PATCH v2 03/18] dt-bindings: clk: Add documentation of grx500 clock controller
On 8/6/2018 11:18 PM, Rob Herring wrote:
On Thu, Aug 2, 2018 at 9:03 PM Songjun Wu wrote:
From: Yixin Zhu
This patch adds binding documentation for grx500 clock controller.
Signed-off-by: YiXin Zhu
Signed-off-by: Songjun Wu
---
Changes in v2:
- Rewrite clock driver's dt-binding document according to Rob Herring's
comments.
- Simplify device tree docoment, remove some clock description.
.../devicetree/bindings/clock/intel,grx500-clk.txt | 39 ++
Please match the compatible string: intel,grx500-cgu.txt
Will update to use same name.
1 file changed, 39 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
diff --git a/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
b/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
new file mode 100644
index ..e54e1dad9196
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
@@ -0,0 +1,39 @@
+Device Tree Clock bindings for grx500 PLL controller.
+
+This binding uses the common clock binding:
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The grx500 clock controller supplies clock to various controllers within the
+SoC.
+
+Required properties for clock node
+- compatible: Should be "intel,grx500-cgu".
+- reg: physical base address of the controller and length of memory range.
+- #clock-cells: should be 1.
+
+Optional Propteries:
+- intel,osc-frequency: frequency of the osc clock.
+if missing, driver will use clock rate defined in the driver.
This should use a fixed-clock node instead.
Yes, This is a fixed clock node registered in driver code.
The frequency of the fixed clock is designed to be overwritten by device
tree in case some one verify
clock driver in the emulation platform or in some cases frequency other
than driver defined one is preferred.
These kinds of cases are very rare. But I feel it would be better to
have a way to use customized frequency.
The frequency defined in device tree will overwritten driver defined
frequency before registering fixed-clock node.
+
+Example: Clock controller node:
+
+ cgu: cgu@1620 {
+compatible = "intel,grx500-cgu", "syscon";
+ reg = <0x1620 0x200>;
+ #clock-cells = <1>;
+ };
+
+
+Example: UART controller node that consumes the clock generated by clock
+ controller.
+
+ asc0: serial@1660 {
+ compatible = "lantiq,asc";
+ reg = <0x1660 0x10>;
+ interrupt-parent = <>;
+ interrupts = ,
+ ,
+ ;
+ clocks = < CLK_SSX4>, < GCLK_UART>;
+ clock-names = "freq", "asc";
+ };
--
2.11.0
Re: [PATCH v2 03/18] dt-bindings: clk: Add documentation of grx500 clock controller
On 8/6/2018 11:18 PM, Rob Herring wrote:
On Thu, Aug 2, 2018 at 9:03 PM Songjun Wu wrote:
From: Yixin Zhu
This patch adds binding documentation for grx500 clock controller.
Signed-off-by: YiXin Zhu
Signed-off-by: Songjun Wu
---
Changes in v2:
- Rewrite clock driver's dt-binding document according to Rob Herring's
comments.
- Simplify device tree docoment, remove some clock description.
.../devicetree/bindings/clock/intel,grx500-clk.txt | 39 ++
Please match the compatible string: intel,grx500-cgu.txt
Will update to use same name.
1 file changed, 39 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
diff --git a/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
b/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
new file mode 100644
index ..e54e1dad9196
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
@@ -0,0 +1,39 @@
+Device Tree Clock bindings for grx500 PLL controller.
+
+This binding uses the common clock binding:
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The grx500 clock controller supplies clock to various controllers within the
+SoC.
+
+Required properties for clock node
+- compatible: Should be "intel,grx500-cgu".
+- reg: physical base address of the controller and length of memory range.
+- #clock-cells: should be 1.
+
+Optional Propteries:
+- intel,osc-frequency: frequency of the osc clock.
+if missing, driver will use clock rate defined in the driver.
This should use a fixed-clock node instead.
Yes, This is a fixed clock node registered in driver code.
The frequency of the fixed clock is designed to be overwritten by device
tree in case some one verify
clock driver in the emulation platform or in some cases frequency other
than driver defined one is preferred.
These kinds of cases are very rare. But I feel it would be better to
have a way to use customized frequency.
The frequency defined in device tree will overwritten driver defined
frequency before registering fixed-clock node.
+
+Example: Clock controller node:
+
+ cgu: cgu@1620 {
+compatible = "intel,grx500-cgu", "syscon";
+ reg = <0x1620 0x200>;
+ #clock-cells = <1>;
+ };
+
+
+Example: UART controller node that consumes the clock generated by clock
+ controller.
+
+ asc0: serial@1660 {
+ compatible = "lantiq,asc";
+ reg = <0x1660 0x10>;
+ interrupt-parent = <>;
+ interrupts = ,
+ ,
+ ;
+ clocks = < CLK_SSX4>, < GCLK_UART>;
+ clock-names = "freq", "asc";
+ };
--
2.11.0
[PATCH] ASoC: max98373: Added software reset register to readable registers
Signed-off-by: Ryan Lee
---
Changes : Added 'MAX98373_R2000_SW_RESET' register to
'max98373_readable_register'
Software reset didn't work properly after suspend/resume.
sound/soc/codecs/max98373.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/max98373.c b/sound/soc/codecs/max98373.c
index a925861..92b7125 100644
--- a/sound/soc/codecs/max98373.c
+++ b/sound/soc/codecs/max98373.c
@@ -488,6 +488,7 @@ static const DECLARE_TLV_DB_RANGE(max98373_bde_gain_tlv,
static bool max98373_readable_register(struct device *dev, unsigned int reg)
{
switch (reg) {
+ case MAX98373_R2000_SW_RESET:
case MAX98373_R2001_INT_RAW1 ... MAX98373_R200C_INT_EN3:
case MAX98373_R2010_IRQ_CTRL:
case MAX98373_R2014_THERM_WARN_THRESH
--
2.7.4
[PATCH] ASoC: max98373: Added software reset register to readable registers
Signed-off-by: Ryan Lee
---
Changes : Added 'MAX98373_R2000_SW_RESET' register to
'max98373_readable_register'
Software reset didn't work properly after suspend/resume.
sound/soc/codecs/max98373.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/max98373.c b/sound/soc/codecs/max98373.c
index a925861..92b7125 100644
--- a/sound/soc/codecs/max98373.c
+++ b/sound/soc/codecs/max98373.c
@@ -488,6 +488,7 @@ static const DECLARE_TLV_DB_RANGE(max98373_bde_gain_tlv,
static bool max98373_readable_register(struct device *dev, unsigned int reg)
{
switch (reg) {
+ case MAX98373_R2000_SW_RESET:
case MAX98373_R2001_INT_RAW1 ... MAX98373_R200C_INT_EN3:
case MAX98373_R2010_IRQ_CTRL:
case MAX98373_R2014_THERM_WARN_THRESH
--
2.7.4
Re: [PATCH 4.4 00/12] 4.4.147-stable review
On 08/07/2018 12:52 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.147 release. > There are 12 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:34 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.147-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 4.4 00/12] 4.4.147-stable review
On 08/07/2018 12:52 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.147 release. > There are 12 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:34 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.147-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 4.9 00/17] 4.9.119-stable review
On 08/07/2018 12:51 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.119 release. > There are 17 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:30 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.119-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 4.9 00/17] 4.9.119-stable review
On 08/07/2018 12:51 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.119 release. > There are 17 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:30 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.119-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 4.14 00/21] 4.14.62-stable review
On 08/07/2018 12:51 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.62 release. > There are 21 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:22 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.62-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 4.14 00/21] 4.14.62-stable review
On 08/07/2018 12:51 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.62 release. > There are 21 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:22 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.62-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 4.17 00/18] 4.17.14-stable review
On 08/07/2018 12:51 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.17.14 release. > There are 18 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:05 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.17.14-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.17.y > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 4.17 00/18] 4.17.14-stable review
On 08/07/2018 12:51 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.17.14 release. > There are 18 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:05 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.17.14-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.17.y > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 3.18 00/85] 3.18.118-stable review
On 08/07/2018 12:51 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.118 release. > There are 85 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:43 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.118-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-3.18.y > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 3.18 00/85] 3.18.118-stable review
On 08/07/2018 12:51 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.118 release. > There are 85 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Aug 9 17:23:43 UTC 2018. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.118-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-3.18.y > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH v2 02/18] clk: intel: Add clock driver for Intel MIPS SoCs
On 8/6/2018 11:19 PM, Rob Herring wrote: On Thu, Aug 2, 2018 at 9:03 PM Songjun Wu wrote: From: Yixin Zhu This driver provides PLL clock registration as well as various clock branches, e.g. MUX clock, gate clock, divider clock and so on. PLLs that provide clock to DDR, CPU and peripherals are shown below: +-+ |--->| LCPLL3 0|--PCIe clk--> XO |+-+ +---| |+-+ ||3|--PAE clk--> |--->| PLL0B 2|--GSWIP clk--> ||1|--DDR clk-->DDR PHY clk--> ||0|--CPU1 clk--+ +-+ |+-+|--->0| | | MUX |--CPU clk--> |+-+|--->1| ||0|--CPU0 clk--+ +-+ |--->| PLLOA 1|--SSX4 clk--> |2|--NGI clk--> |3|--CBM clk--> +-+ Signed-off-by: Yixin Zhu Signed-off-by: Songjun Wu --- Changes in v2: - Rewrite clock driver, add platform clock description details in clock driver. drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 3 + drivers/clk/intel/Kconfig| 20 ++ drivers/clk/intel/Makefile | 7 + drivers/clk/intel/clk-cgu-pll.c | 166 ++ drivers/clk/intel/clk-cgu-pll.h | 34 ++ drivers/clk/intel/clk-cgu.c | 470 +++ drivers/clk/intel/clk-cgu.h | 259 +++ drivers/clk/intel/clk-grx500.c | 168 ++ include/dt-bindings/clock/intel,grx500-clk.h | 69 This belongs with the clk binding patch. Rob Thanks for review. Will move it to clock binding patch.
Re: [PATCH v2 02/18] clk: intel: Add clock driver for Intel MIPS SoCs
On 8/6/2018 11:19 PM, Rob Herring wrote: On Thu, Aug 2, 2018 at 9:03 PM Songjun Wu wrote: From: Yixin Zhu This driver provides PLL clock registration as well as various clock branches, e.g. MUX clock, gate clock, divider clock and so on. PLLs that provide clock to DDR, CPU and peripherals are shown below: +-+ |--->| LCPLL3 0|--PCIe clk--> XO |+-+ +---| |+-+ ||3|--PAE clk--> |--->| PLL0B 2|--GSWIP clk--> ||1|--DDR clk-->DDR PHY clk--> ||0|--CPU1 clk--+ +-+ |+-+|--->0| | | MUX |--CPU clk--> |+-+|--->1| ||0|--CPU0 clk--+ +-+ |--->| PLLOA 1|--SSX4 clk--> |2|--NGI clk--> |3|--CBM clk--> +-+ Signed-off-by: Yixin Zhu Signed-off-by: Songjun Wu --- Changes in v2: - Rewrite clock driver, add platform clock description details in clock driver. drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 3 + drivers/clk/intel/Kconfig| 20 ++ drivers/clk/intel/Makefile | 7 + drivers/clk/intel/clk-cgu-pll.c | 166 ++ drivers/clk/intel/clk-cgu-pll.h | 34 ++ drivers/clk/intel/clk-cgu.c | 470 +++ drivers/clk/intel/clk-cgu.h | 259 +++ drivers/clk/intel/clk-grx500.c | 168 ++ include/dt-bindings/clock/intel,grx500-clk.h | 69 This belongs with the clk binding patch. Rob Thanks for review. Will move it to clock binding patch.
Re: [PATCH v7 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings
On 8/8/2018 12:54 AM, skan...@codeaurora.org wrote:
On 2018-08-07 04:12, Sudeep Holla wrote:
On Mon, Aug 06, 2018 at 01:54:24PM -0700, skan...@codeaurora.org wrote:
On 2018-08-03 16:46, Stephen Boyd wrote:
>Quoting Taniya Das (2018-07-24 03:42:49)
>>diff --git
>>a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
>>b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
>>new file mode 100644
>>index 000..22d4355
>>--- /dev/null
>>+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
>>@@ -0,0 +1,172 @@
>[...]
>>+
>>+ CPU7: cpu@700 {
>>+ device_type = "cpu";
>>+ compatible = "qcom,kryo385";
>>+ reg = <0x0 0x700>;
>>+ enable-method = "psci";
>>+ next-level-cache = <_700>;
>>+ qcom,freq-domain = <_domain_table1>;
>>+ L2_700: l2-cache {
>>+ compatible = "cache";
>>+ next-level-cache = <_0>;
>>+ };
>>+ };
>>+ };
>>+
>>+ qcom,cpufreq-hw {
>>+ compatible = "qcom,cpufreq-hw";
>>+
>>+ clocks = < RPMH_CXO_CLK>;
>>+ clock-names = "xo";
>>+
>>+ #address-cells = <2>;
>>+ #size-cells = <2>;
>>+ ranges;
>>+ freq_domain_table0: freq_table0 {
>>+ reg = <0 0x17d43000 0 0x1400>;
>>+ };
>>+
>>+ freq_domain_table1: freq_table1 {
>>+ reg = <0 0x17d45800 0 0x1400>;
>>+ };
>
>Sorry, this is just not proper DT design. The whole node should have a
>reg property, and it should contain two (or three if we're handling the
>L3 clk domain?) different offsets for the different power clusters. The
>problem seems to still be that we don't have a way to map the CPUs to
>the clk domains they're in provided by this hardware block. Making
>subnodes is not the solution.
The problem is mapping clock domains to logical CPUs that CPUfreq
uses. The
physical CPU to logical CPU mapping can be changed by the kernel (even
through DT if I'm not mistaken). So we need to have a way to tell in DT
which physical CPUs are connected to which CPU freq clock domain.
How about passing CPU freq clock domain id as along with phandle in
qcom,freq-domain ?
Now sure what you mean here. There's no such this as CPUfreq clock
domain id. It has policies that are made up of logical CPU numbers.
Logical CPU is not something that you can fix in DT.
-Saravana
Sudeep,
Earlier the design was the freq_domain would take the CPU phandles
freq_domain:
cpus = < >;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
--
Re: [PATCH v7 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings
On 8/8/2018 12:54 AM, skan...@codeaurora.org wrote:
On 2018-08-07 04:12, Sudeep Holla wrote:
On Mon, Aug 06, 2018 at 01:54:24PM -0700, skan...@codeaurora.org wrote:
On 2018-08-03 16:46, Stephen Boyd wrote:
>Quoting Taniya Das (2018-07-24 03:42:49)
>>diff --git
>>a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
>>b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
>>new file mode 100644
>>index 000..22d4355
>>--- /dev/null
>>+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
>>@@ -0,0 +1,172 @@
>[...]
>>+
>>+ CPU7: cpu@700 {
>>+ device_type = "cpu";
>>+ compatible = "qcom,kryo385";
>>+ reg = <0x0 0x700>;
>>+ enable-method = "psci";
>>+ next-level-cache = <_700>;
>>+ qcom,freq-domain = <_domain_table1>;
>>+ L2_700: l2-cache {
>>+ compatible = "cache";
>>+ next-level-cache = <_0>;
>>+ };
>>+ };
>>+ };
>>+
>>+ qcom,cpufreq-hw {
>>+ compatible = "qcom,cpufreq-hw";
>>+
>>+ clocks = < RPMH_CXO_CLK>;
>>+ clock-names = "xo";
>>+
>>+ #address-cells = <2>;
>>+ #size-cells = <2>;
>>+ ranges;
>>+ freq_domain_table0: freq_table0 {
>>+ reg = <0 0x17d43000 0 0x1400>;
>>+ };
>>+
>>+ freq_domain_table1: freq_table1 {
>>+ reg = <0 0x17d45800 0 0x1400>;
>>+ };
>
>Sorry, this is just not proper DT design. The whole node should have a
>reg property, and it should contain two (or three if we're handling the
>L3 clk domain?) different offsets for the different power clusters. The
>problem seems to still be that we don't have a way to map the CPUs to
>the clk domains they're in provided by this hardware block. Making
>subnodes is not the solution.
The problem is mapping clock domains to logical CPUs that CPUfreq
uses. The
physical CPU to logical CPU mapping can be changed by the kernel (even
through DT if I'm not mistaken). So we need to have a way to tell in DT
which physical CPUs are connected to which CPU freq clock domain.
How about passing CPU freq clock domain id as along with phandle in
qcom,freq-domain ?
Now sure what you mean here. There's no such this as CPUfreq clock
domain id. It has policies that are made up of logical CPU numbers.
Logical CPU is not something that you can fix in DT.
-Saravana
Sudeep,
Earlier the design was the freq_domain would take the CPU phandles
freq_domain:
cpus = < >;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
--
Re: [PATCH 2/2] spi: sprd: Add SPI driver for Spreadtrum SC9860
Hi Mark,
On 7 August 2018 at 22:24, Mark Brown wrote:
> On Tue, Aug 07, 2018 at 06:43:38PM +0800, Baolin Wang wrote:
>> From: Lanqing Liu
>>
>> This patch adds the SPI controller driver for Spreadtrum SC9860 platform.
>
> This all looks pretty clean, a few comments below but nothing too major:
>
>> +static void sprd_spi_chipselect(struct spi_device *sdev, bool cs)
>> +{
>> + struct spi_controller *sctlr = sdev->controller;
>> + struct sprd_spi *ss = spi_controller_get_devdata(sctlr);
>> + u32 val;
>> + int ret;
>> +
>> + ret = pm_runtime_get_sync(ss->dev);
>> + if (ret < 0) {
>> + dev_err(ss->dev, "failed to resume SPI controller\n");
>> + return;
>> + }
>
> Something else further up the stack should probably have runtime PM
> enabled already - we should only be changing chip select as part of a
> bigger operation. If you use the core auto_runtime_pm feature this will
> definitely happen.
Indeed, will use auto_runtime_pm.
>
>> + bits_per_word = bits_per_word > 16 ? round_up(bits_per_word, 16) :
>> + round_up(bits_per_word, 8);
>
> Please
Sorry I did not get your points here, could you elaborate on?
>
>> + switch (bits_per_word) {
>> + case 8:
>> + case 16:
>> + case 32:
>
> It'd be nice to have a default case, the core should check for you but
> it's nice to have defensive programming here.
Sure.
>
>> +static int sprd_spi_transfer_one(struct spi_controller *sctlr,
>> + struct spi_device *sdev,
>> + struct spi_transfer *t)
>> +{
>> + struct sprd_spi *ss = spi_controller_get_devdata(sctlr);
>> + int ret;
>> +
>> + ret = pm_runtime_get_sync(ss->dev);
>> + if (ret < 0) {
>> + dev_err(ss->dev, "failed to resume SPI controller\n");
>> + goto rpm_err;
>> + }
>
> Same thing with runtime PM here - the core can do this for you.
Yes.
>
>> +static int sprd_spi_setup(struct spi_device *spi_dev)
>> +{
>> + struct spi_controller *sctlr = spi_dev->controller;
>> + struct sprd_spi *ss = spi_controller_get_devdata(sctlr);
>> + int ret;
>> +
>> + ret = pm_runtime_get_sync(ss->dev);
>> + if (ret < 0) {
>> + dev_err(ss->dev, "failed to resume SPI controller\n");
>> + return ret;
>> + }
>> +
>> + ss->hw_mode = spi_dev->mode;
>> + sprd_spi_init_hw(ss);
>
> This can be called for one chip select while another is in progress so
> it's not good to actually configure the hardware here unless the
> configuration is in a chip select specific set of registers. Instead
> you should defer to when the transfer is being set up.
You are right, will move these into transfer setup.
>
>> +static int sprd_spi_clk_init(struct platform_device *pdev, struct sprd_spi
>> *ss)
>> +{
>> + struct clk *clk_spi, *clk_parent;
>> +
>> + clk_spi = devm_clk_get(>dev, "spi");
>> + if (IS_ERR(clk_spi)) {
>> + dev_warn(>dev, "can't get the spi clock\n");
>> + clk_spi = NULL;
>> + }
>
> I suspect some of these clocks are essential and you should probably
> return an error if you can't get them (especially if probe deferral
> becomes a factor).
The 'spi' and 'source' clock can be optional, and the SPI can work at
default source clock without setting 'spi' and 'source' clock. This is
used on our FPGA board which has not set the spi source clock, but
still make the SPI can work. So here we just give a warning.
>> + if (!clk_set_parent(clk_spi, clk_parent))
>> + ss->src_clk = clk_get_rate(clk_spi);
>> + else
>> + ss->src_clk = SPRD_SPI_DEFAULT_SOURCE;
>
> Are upstream DTs going to be missing the clock setup needed here?
Right. DTs can not set 'spi' and 'source' clock to make SPI work at
default clock. Thanks for your useful comments.
--
Baolin Wang
Best Regards
Re: [PATCH 2/2] spi: sprd: Add SPI driver for Spreadtrum SC9860
Hi Mark,
On 7 August 2018 at 22:24, Mark Brown wrote:
> On Tue, Aug 07, 2018 at 06:43:38PM +0800, Baolin Wang wrote:
>> From: Lanqing Liu
>>
>> This patch adds the SPI controller driver for Spreadtrum SC9860 platform.
>
> This all looks pretty clean, a few comments below but nothing too major:
>
>> +static void sprd_spi_chipselect(struct spi_device *sdev, bool cs)
>> +{
>> + struct spi_controller *sctlr = sdev->controller;
>> + struct sprd_spi *ss = spi_controller_get_devdata(sctlr);
>> + u32 val;
>> + int ret;
>> +
>> + ret = pm_runtime_get_sync(ss->dev);
>> + if (ret < 0) {
>> + dev_err(ss->dev, "failed to resume SPI controller\n");
>> + return;
>> + }
>
> Something else further up the stack should probably have runtime PM
> enabled already - we should only be changing chip select as part of a
> bigger operation. If you use the core auto_runtime_pm feature this will
> definitely happen.
Indeed, will use auto_runtime_pm.
>
>> + bits_per_word = bits_per_word > 16 ? round_up(bits_per_word, 16) :
>> + round_up(bits_per_word, 8);
>
> Please
Sorry I did not get your points here, could you elaborate on?
>
>> + switch (bits_per_word) {
>> + case 8:
>> + case 16:
>> + case 32:
>
> It'd be nice to have a default case, the core should check for you but
> it's nice to have defensive programming here.
Sure.
>
>> +static int sprd_spi_transfer_one(struct spi_controller *sctlr,
>> + struct spi_device *sdev,
>> + struct spi_transfer *t)
>> +{
>> + struct sprd_spi *ss = spi_controller_get_devdata(sctlr);
>> + int ret;
>> +
>> + ret = pm_runtime_get_sync(ss->dev);
>> + if (ret < 0) {
>> + dev_err(ss->dev, "failed to resume SPI controller\n");
>> + goto rpm_err;
>> + }
>
> Same thing with runtime PM here - the core can do this for you.
Yes.
>
>> +static int sprd_spi_setup(struct spi_device *spi_dev)
>> +{
>> + struct spi_controller *sctlr = spi_dev->controller;
>> + struct sprd_spi *ss = spi_controller_get_devdata(sctlr);
>> + int ret;
>> +
>> + ret = pm_runtime_get_sync(ss->dev);
>> + if (ret < 0) {
>> + dev_err(ss->dev, "failed to resume SPI controller\n");
>> + return ret;
>> + }
>> +
>> + ss->hw_mode = spi_dev->mode;
>> + sprd_spi_init_hw(ss);
>
> This can be called for one chip select while another is in progress so
> it's not good to actually configure the hardware here unless the
> configuration is in a chip select specific set of registers. Instead
> you should defer to when the transfer is being set up.
You are right, will move these into transfer setup.
>
>> +static int sprd_spi_clk_init(struct platform_device *pdev, struct sprd_spi
>> *ss)
>> +{
>> + struct clk *clk_spi, *clk_parent;
>> +
>> + clk_spi = devm_clk_get(>dev, "spi");
>> + if (IS_ERR(clk_spi)) {
>> + dev_warn(>dev, "can't get the spi clock\n");
>> + clk_spi = NULL;
>> + }
>
> I suspect some of these clocks are essential and you should probably
> return an error if you can't get them (especially if probe deferral
> becomes a factor).
The 'spi' and 'source' clock can be optional, and the SPI can work at
default source clock without setting 'spi' and 'source' clock. This is
used on our FPGA board which has not set the spi source clock, but
still make the SPI can work. So here we just give a warning.
>> + if (!clk_set_parent(clk_spi, clk_parent))
>> + ss->src_clk = clk_get_rate(clk_spi);
>> + else
>> + ss->src_clk = SPRD_SPI_DEFAULT_SOURCE;
>
> Are upstream DTs going to be missing the clock setup needed here?
Right. DTs can not set 'spi' and 'source' clock to make SPI work at
default clock. Thanks for your useful comments.
--
Baolin Wang
Best Regards
Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage
On Tue, 7 Aug 2018 19:13:32 -0700
Joel Fernandes wrote:
> On Tue, Aug 7, 2018 at 6:55 PM, Steven Rostedt wrote:
> > On Tue, 7 Aug 2018 18:17:42 -0700
> > Joel Fernandes wrote:
> >
> >> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
> >> From: "Joel Fernandes (Google)"
> >> Date: Sun, 5 Aug 2018 20:17:41 -0700
> >> Subject: [PATCH] tracepoint: Run tracepoints even after CPU is offline
> >>
> >> Commit f37755490fe9 ("tracepoints: Do not trace when cpu is offline")
> >> causes a problem for lockdep using tracepoint code. Once a CPU is
> >> offline, tracepoints donot get called, however this causes a big problem
> >> for lockdep probes that need to run so that IRQ annotations are marked
> >> correctly.
> >>
> >> A race is possible where while the CPU is going offline, an interrupt
> >> can come in and then a lockdep assert causes an annotation warning:
> >>
> >> [ 106.551354] IRQs not enabled as expected
> >> [ 106.551785] WARNING: CPU: 1 PID: 0 at kernel/time/tick-sched.c:982
> >> tick_nohz_idle_enter+0x99/0xb0
> >> [ 106.552964] Modules linked in:
> >> [ 106.553299] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW
> >>
> >> We need tracepoints to run as late as possible. This commit fixes the
> >> issue by removing the cpu_online check in tracepoint code that was
> >> introduced in the mentioned commit, however we now switch to using SRCU
> >> for all tracepoints and special handle calling tracepoints from NMI so
> >> that we don't run into issues that result from using sched-RCU when the
> >> CPUs are marked to be offline.
> >>
> >> Fixes: c3bc8fd637a9 ("tracing: Centralize preemptirq tracepoints and
> >> unify their usage")
> >> Reported-by: Masami Hiramatsu
> >> Signed-off-by: Joel Fernandes (Google)
> >
> >
> > The above change log doesn't look like it matches the NMI patch.
> >
> > Can you resend with just the NMI changes? I already handled the cpu
> > offline ones.
>
> Ok, sent with "cpu offline" changes dropped, here it is:
> https://lore.kernel.org/patchwork/patch/972657/
>
> If you could add your Reported-by to it, that would be great as well.
>
> >
> > But I may still have concerns with this patch.
>
> Ok let me know what you think.
>
Not sure you saw this part of my reply:
> @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
> } while ((++it_func_ptr)->func);\
> } \
> \
> - if (rcuidle)\
> - srcu_read_unlock_notrace(_srcu, idx);\
> + srcu_read_unlock_notrace(ss, idx); \
Hmm, why do we have the two different srcu handles?
Thinking about this, if this can be called by the "thunk" code, then
there might be an issue. I think the "thunk" code can be called before
in_nmi() is set, so we don't know if we are in an NMI or not. I need to
look at that code to make sure. If in_nmi() still works, then we should
use the _nmi srcu handle (if that's required).
But I'm not sure using SRCU for all tracepoints is needed at this
moment. I'll have to look deeper into this tomorrow. But it's getting
close to the merge window, and this needs to be settled quick. Another
"partial revert" may be needed until this gets settled.
-- Steve
Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage
On Tue, 7 Aug 2018 19:13:32 -0700
Joel Fernandes wrote:
> On Tue, Aug 7, 2018 at 6:55 PM, Steven Rostedt wrote:
> > On Tue, 7 Aug 2018 18:17:42 -0700
> > Joel Fernandes wrote:
> >
> >> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
> >> From: "Joel Fernandes (Google)"
> >> Date: Sun, 5 Aug 2018 20:17:41 -0700
> >> Subject: [PATCH] tracepoint: Run tracepoints even after CPU is offline
> >>
> >> Commit f37755490fe9 ("tracepoints: Do not trace when cpu is offline")
> >> causes a problem for lockdep using tracepoint code. Once a CPU is
> >> offline, tracepoints donot get called, however this causes a big problem
> >> for lockdep probes that need to run so that IRQ annotations are marked
> >> correctly.
> >>
> >> A race is possible where while the CPU is going offline, an interrupt
> >> can come in and then a lockdep assert causes an annotation warning:
> >>
> >> [ 106.551354] IRQs not enabled as expected
> >> [ 106.551785] WARNING: CPU: 1 PID: 0 at kernel/time/tick-sched.c:982
> >> tick_nohz_idle_enter+0x99/0xb0
> >> [ 106.552964] Modules linked in:
> >> [ 106.553299] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW
> >>
> >> We need tracepoints to run as late as possible. This commit fixes the
> >> issue by removing the cpu_online check in tracepoint code that was
> >> introduced in the mentioned commit, however we now switch to using SRCU
> >> for all tracepoints and special handle calling tracepoints from NMI so
> >> that we don't run into issues that result from using sched-RCU when the
> >> CPUs are marked to be offline.
> >>
> >> Fixes: c3bc8fd637a9 ("tracing: Centralize preemptirq tracepoints and
> >> unify their usage")
> >> Reported-by: Masami Hiramatsu
> >> Signed-off-by: Joel Fernandes (Google)
> >
> >
> > The above change log doesn't look like it matches the NMI patch.
> >
> > Can you resend with just the NMI changes? I already handled the cpu
> > offline ones.
>
> Ok, sent with "cpu offline" changes dropped, here it is:
> https://lore.kernel.org/patchwork/patch/972657/
>
> If you could add your Reported-by to it, that would be great as well.
>
> >
> > But I may still have concerns with this patch.
>
> Ok let me know what you think.
>
Not sure you saw this part of my reply:
> @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
> } while ((++it_func_ptr)->func);\
> } \
> \
> - if (rcuidle)\
> - srcu_read_unlock_notrace(_srcu, idx);\
> + srcu_read_unlock_notrace(ss, idx); \
Hmm, why do we have the two different srcu handles?
Thinking about this, if this can be called by the "thunk" code, then
there might be an issue. I think the "thunk" code can be called before
in_nmi() is set, so we don't know if we are in an NMI or not. I need to
look at that code to make sure. If in_nmi() still works, then we should
use the _nmi srcu handle (if that's required).
But I'm not sure using SRCU for all tracepoints is needed at this
moment. I'll have to look deeper into this tomorrow. But it's getting
close to the merge window, and this needs to be settled quick. Another
"partial revert" may be needed until this gets settled.
-- Steve
Re: [PATCH 1/2] dt-bindings: spi: Add Spreadtrum SPI controller documentation
Hi Mark, On 7 August 2018 at 21:41, Mark Brown wrote: > On Tue, Aug 07, 2018 at 06:43:37PM +0800, Baolin Wang wrote: > >> +Optional properties: >> +- sprd,spi-interval: Specify the intervals of two SPI frames, which can be >> + converted to the delay clock cycles = interval number * 4 + 10. > > What's a frame here, and does it overlap with any of the existing delay > configuration we have? In general it's better for this stuff to be > configured at runtime by the device rather than at DT time by the > controller since that way if the device needs the delays we always do > them if we can and if they are only needed some of the time (eg, for > only one device on the bus or for only some operations) then we don't > take the performance hit when we don't need to. Sorry for confusing. Let me try to explain it explicitly. We can set the word size (bits_per_word) for each transmission, for our SPI controller, after every word size transmission, we need one interval time (hardware automatically) to make sure the slave has enough time to receive the whole data. Yes, I agree we should configure it at runtime by the device, but we did not find one member to use in 'struct spi_transfer', we just find one similar 'delay_usecs' member in 'struct spi_transfer' but not same. We can use 'delay_usecs' to set our hardware interval value, but we should clean it when transfer is done, since we do not need to delay after the transfer in spi_transfer_one _message(). Or can we add one new member maybe named 'word_interval' to indicate the interval time between word size transmission? What do you prefer or other better solution? Thanks. -- Baolin Wang Best Regards
Re: [PATCH 1/2] dt-bindings: spi: Add Spreadtrum SPI controller documentation
Hi Mark, On 7 August 2018 at 21:41, Mark Brown wrote: > On Tue, Aug 07, 2018 at 06:43:37PM +0800, Baolin Wang wrote: > >> +Optional properties: >> +- sprd,spi-interval: Specify the intervals of two SPI frames, which can be >> + converted to the delay clock cycles = interval number * 4 + 10. > > What's a frame here, and does it overlap with any of the existing delay > configuration we have? In general it's better for this stuff to be > configured at runtime by the device rather than at DT time by the > controller since that way if the device needs the delays we always do > them if we can and if they are only needed some of the time (eg, for > only one device on the bus or for only some operations) then we don't > take the performance hit when we don't need to. Sorry for confusing. Let me try to explain it explicitly. We can set the word size (bits_per_word) for each transmission, for our SPI controller, after every word size transmission, we need one interval time (hardware automatically) to make sure the slave has enough time to receive the whole data. Yes, I agree we should configure it at runtime by the device, but we did not find one member to use in 'struct spi_transfer', we just find one similar 'delay_usecs' member in 'struct spi_transfer' but not same. We can use 'delay_usecs' to set our hardware interval value, but we should clean it when transfer is done, since we do not need to delay after the transfer in spi_transfer_one _message(). Or can we add one new member maybe named 'word_interval' to indicate the interval time between word size transmission? What do you prefer or other better solution? Thanks. -- Baolin Wang Best Regards
Re: [PATCH v2] kbuild: make samples really depend on headers_install
2018-08-08 11:14 GMT+09:00 Masahiro Yamada :
> Kernel headers must be installed into $(objtree)/usr/include to avoid
> the build failure of samples.
>
> Commit ddea05fa148b ("kbuild: make samples depend on headers_install")
> addressed this, but "samples/" is only used for the single target build.
>
> "make samples/" properly installs kernel headers, but it does not work
> for general building because a phony target "sample" (no trailing slash)
> is used.
>
> Reported-by: David Howells
> Signed-off-by: Masahiro Yamada
> ---
David,
Could you check this patch, please?
Will you apply this to your tree
to fix the vfs sample issue?
Please let me know your thought.
Thanks.
> Changes in v2:
> - Correct commit log (backslash -> slash)
> - Fix a typo
>
> Makefile | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 7a3c454..1e47d13 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1009,9 +1009,10 @@ ifdef CONFIG_GDB_SCRIPTS
> endif
> +$(call if_changed,link-vmlinux)
>
> -# Build samples along the rest of the kernel
> +# Build samples along the rest of the kernel. This needs headers_install.
> ifdef CONFIG_SAMPLES
> vmlinux-dirs += samples
> +samples: headers_install
> endif
>
> # The actual objects are generated when descending,
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Masahiro Yamada
Re: [PATCH v2] kbuild: make samples really depend on headers_install
2018-08-08 11:14 GMT+09:00 Masahiro Yamada :
> Kernel headers must be installed into $(objtree)/usr/include to avoid
> the build failure of samples.
>
> Commit ddea05fa148b ("kbuild: make samples depend on headers_install")
> addressed this, but "samples/" is only used for the single target build.
>
> "make samples/" properly installs kernel headers, but it does not work
> for general building because a phony target "sample" (no trailing slash)
> is used.
>
> Reported-by: David Howells
> Signed-off-by: Masahiro Yamada
> ---
David,
Could you check this patch, please?
Will you apply this to your tree
to fix the vfs sample issue?
Please let me know your thought.
Thanks.
> Changes in v2:
> - Correct commit log (backslash -> slash)
> - Fix a typo
>
> Makefile | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 7a3c454..1e47d13 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1009,9 +1009,10 @@ ifdef CONFIG_GDB_SCRIPTS
> endif
> +$(call if_changed,link-vmlinux)
>
> -# Build samples along the rest of the kernel
> +# Build samples along the rest of the kernel. This needs headers_install.
> ifdef CONFIG_SAMPLES
> vmlinux-dirs += samples
> +samples: headers_install
> endif
>
> # The actual objects are generated when descending,
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Masahiro Yamada
Re: simplified RISC-V interrupt and clocksource handling v3
On Sat, 04 Aug 2018 01:23:11 PDT (-0700), Christoph Hellwig wrote:
This series tries adds support for interrupt handling and timers
for the RISC-V architecture.
The basic per-hart interrupt handling implemented by the scause
and sie CSRs is extremely simple and implemented directly in
arch/riscv/kernel/irq.c. In addition there is a irqchip driver
for the PLIC external interrupt controller, which is called through
the set_handle_irq API, and a clocksource driver that gets its
timer interrupt directly from the low-level interrupt handling.
Compared to previous iterations this version does not try to use an
irqchip driver for the low-level interrupt handling. This saves
a couple indirect calls and an additional read of the scause CSR
in the hot path, makes the code much simpler and last but not least
avoid the dependency on a device tree for a mandatory architectural
feature.
A git tree is available here (contains a few more patches before
the ones in this series)
git://git.infradead.org/users/hch/riscv.git riscv-irq-simple.3
Gitweb:
http://git.infradead.org/users/hch/riscv.git/shortlog/refs/heads/riscv-irq-simple.3
Changes since v2:
- actually use SEIE instead of STIE in the plic driver
- rename the default compat string for the plic to sifive,u5-plic
- various spelling fixes
- drop a superflous derefence in the plic driver that is taken care of
by the following loop
- drop the patch to document the enable method - not relevant for the
rest of the series
- drop the patches for the per-hart timebase frequency - not relevant
for the rest of the series.
- use riscv_of_processor_hart in the timer driver
Changes since v1:
- rename the plic driver to irq-sifive-plic
- switch to a default compatible of sifive,plic0 (still supporting the
riscv,plic0 name for compatibility)
- add a reference for the SiFive PLIC register layout
- fix plic_toggle addressing for large numbers of hwirqs
- remove the call to ack_bad_irq
- use a raw spinlock for plic_toggle_lock
- use the irq_desc cpumask in the plic enable/disable methods
- add back OF contexid parsing in the plic driver
- don't allow COMPILE_TEST builds of the clocksource driver, as it
depends on
- default the clocksource driver to y
- clean up naming in the clocksource driver
- remove the MINDELTA and MAXDELTA #defines
- various DT binding fixes
Thanks! Modulo the one device tree issue I replied to in patch 3 this looks
great! We've already gotten the ACKs to take this through the RISC-V tree, so
I'm going to put this along with the queued RISC-V patches on our for-next
branch, including my proposed change for "sifive,plic-1.0" but leaving the
device tree bindings with #{address,size}-cells=1.
We can always change this, but I'd like to get this out so people can start
playing with it earlier rather than later.
Thanks to everyone for all the help!
Re: simplified RISC-V interrupt and clocksource handling v3
On Sat, 04 Aug 2018 01:23:11 PDT (-0700), Christoph Hellwig wrote:
This series tries adds support for interrupt handling and timers
for the RISC-V architecture.
The basic per-hart interrupt handling implemented by the scause
and sie CSRs is extremely simple and implemented directly in
arch/riscv/kernel/irq.c. In addition there is a irqchip driver
for the PLIC external interrupt controller, which is called through
the set_handle_irq API, and a clocksource driver that gets its
timer interrupt directly from the low-level interrupt handling.
Compared to previous iterations this version does not try to use an
irqchip driver for the low-level interrupt handling. This saves
a couple indirect calls and an additional read of the scause CSR
in the hot path, makes the code much simpler and last but not least
avoid the dependency on a device tree for a mandatory architectural
feature.
A git tree is available here (contains a few more patches before
the ones in this series)
git://git.infradead.org/users/hch/riscv.git riscv-irq-simple.3
Gitweb:
http://git.infradead.org/users/hch/riscv.git/shortlog/refs/heads/riscv-irq-simple.3
Changes since v2:
- actually use SEIE instead of STIE in the plic driver
- rename the default compat string for the plic to sifive,u5-plic
- various spelling fixes
- drop a superflous derefence in the plic driver that is taken care of
by the following loop
- drop the patch to document the enable method - not relevant for the
rest of the series
- drop the patches for the per-hart timebase frequency - not relevant
for the rest of the series.
- use riscv_of_processor_hart in the timer driver
Changes since v1:
- rename the plic driver to irq-sifive-plic
- switch to a default compatible of sifive,plic0 (still supporting the
riscv,plic0 name for compatibility)
- add a reference for the SiFive PLIC register layout
- fix plic_toggle addressing for large numbers of hwirqs
- remove the call to ack_bad_irq
- use a raw spinlock for plic_toggle_lock
- use the irq_desc cpumask in the plic enable/disable methods
- add back OF contexid parsing in the plic driver
- don't allow COMPILE_TEST builds of the clocksource driver, as it
depends on
- default the clocksource driver to y
- clean up naming in the clocksource driver
- remove the MINDELTA and MAXDELTA #defines
- various DT binding fixes
Thanks! Modulo the one device tree issue I replied to in patch 3 this looks
great! We've already gotten the ACKs to take this through the RISC-V tree, so
I'm going to put this along with the queued RISC-V patches on our for-next
branch, including my proposed change for "sifive,plic-1.0" but leaving the
device tree bindings with #{address,size}-cells=1.
We can always change this, but I'd like to get this out so people can start
playing with it earlier rather than later.
Thanks to everyone for all the help!
