[PATCH v2 04/10] ARM: sunxi: h3/h5: Add r_i2c I2C controller

From: Ondrej Jirman Allwinner H3/H5 SoCs have an I2C controller at PL GPIO bank. Add support for it in the device tree. Signed-off-by: Ondrej Jirman [Icenowy: Change to use r_ccu and change pinmux node name] Signed-off-by: Icenowy Zheng

[PATCH v2 04/10] ARM: sunxi: h3/h5: Add r_i2c I2C controller

From: Ondrej Jirman Allwinner H3/H5 SoCs have an I2C controller at PL GPIO bank. Add support for it in the device tree. Signed-off-by: Ondrej Jirman [Icenowy: Change to use r_ccu and change pinmux node name] Signed-off-by: Icenowy Zheng Reviewed-by: Chen-Yu Tsai --- Changes in v2: - Added

[PATCH v2 03/10] ARM: sunxi: h3/h5: Add r_i2c pinmux node

From: Ondrej Jirman H3/H5 SoCs contain an I2C controller optionally available on the PL0 and PL1 pins. This patch adds pinmux configuration for this controller. Signed-off-by: Ondrej Jirman [Icenowy: change commit message, node name and function name]

[PATCH v2 03/10] ARM: sunxi: h3/h5: Add r_i2c pinmux node

From: Ondrej Jirman H3/H5 SoCs contain an I2C controller optionally available on the PL0 and PL1 pins. This patch adds pinmux configuration for this controller. Signed-off-by: Ondrej Jirman [Icenowy: change commit message, node name and function name] Signed-off-by: Icenowy Zheng Reviewed-by:

[PATCH v2 02/10] regulator: add support for SY8106A regulator

From: Ondrej Jirman SY8106A is an I2C attached single output regulator made by Silergy Corp, which is used on several Allwinner H3/H5 SBCs to control the power supply of the ARM cores. Add a driver for it. Signed-off-by: Ondrej Jirman [Icenowy: Change

[PATCH v2 02/10] regulator: add support for SY8106A regulator

From: Ondrej Jirman SY8106A is an I2C attached single output regulator made by Silergy Corp, which is used on several Allwinner H3/H5 SBCs to control the power supply of the ARM cores. Add a driver for it. Signed-off-by: Ondrej Jirman [Icenowy: Change commit message, remove enable/disable

[PATCH v2 01/10] dt-bindings: add binding for the SY8106A voltage regulator

From: Ondrej Jirman SY8106A is an I2C-controlled adjustable voltage regulator made by Silergy Corp. Add its device tree binding. Signed-off-by: Ondrej Jirman [Icenowy: Change commit message and slight fixes] Signed-off-by: Icenowy Zheng

[PATCH v2 01/10] dt-bindings: add binding for the SY8106A voltage regulator

From: Ondrej Jirman SY8106A is an I2C-controlled adjustable voltage regulator made by Silergy Corp. Add its device tree binding. Signed-off-by: Ondrej Jirman [Icenowy: Change commit message and slight fixes] Signed-off-by: Icenowy Zheng Reviewed-by: Chen-Yu Tsai Acked-by: Rob Herring ---

[PATCH v2 00/10] Allwinner H3 DVFS support

This patchset tries to add DVFS support for Allwinner H3 SoC, considering two kinds of adjustable regulators used on H3 boards: SY8106A I2C-controlled regulator and SY8113B regulator (controllable by GPIO with some special designs on the board), and also taking the uncontrollable boards into

[PATCH v2 00/10] Allwinner H3 DVFS support

This patchset tries to add DVFS support for Allwinner H3 SoC, considering two kinds of adjustable regulators used on H3 boards: SY8106A I2C-controlled regulator and SY8113B regulator (controllable by GPIO with some special designs on the board), and also taking the uncontrollable boards into

Re: [PATCH 01/15] firmware: qcom: scm: Add ipq4019 soc compatible

Hi Rob, On 2/5/2018 11:37 AM, Rob Herring wrote: > On Mon, Jan 29, 2018 at 10:41:15AM +0530, Sricharan R wrote: >> Add the compatible for ipq4019. >> This does not need clocks to do scm calls. >> >> Signed-off-by: Sricharan R >> --- >>

Re: [PATCH 01/15] firmware: qcom: scm: Add ipq4019 soc compatible

Hi Rob, On 2/5/2018 11:37 AM, Rob Herring wrote: > On Mon, Jan 29, 2018 at 10:41:15AM +0530, Sricharan R wrote: >> Add the compatible for ipq4019. >> This does not need clocks to do scm calls. >> >> Signed-off-by: Sricharan R >> --- >> Documentation/devicetree/bindings/firmware/qcom,scm.txt | 3

Re: [PATCH v6 15/15] dt-bindings: cpufreq: Document operating-points-v2-krait-cpu

Hi Viresh, On 2/6/2018 9:57 AM, Viresh Kumar wrote: > On 06-02-18, 09:38, Sricharan R wrote: >> In Certain QCOM SoCs like ipq8064, apq8064, msm8960, msm8974 >> that has KRAIT processors the voltage/current value of each OPP >> varies based on the silicon variant in use. >>

Re: [PATCH RESEND] rpmsg: virtio_rpmsg_bus: fix rpmsg_probe() for virtio-mmio transport

Hi Bjorn, Can you please have a look at this patch? Regards, Anup

Re: [PATCH RESEND] rpmsg: Add driver_override device attribute for rpmsg_device

Hi Bjorn, Can you please have a look at this patch? Regards, Anup

Re: [PATCH v6 15/15] dt-bindings: cpufreq: Document operating-points-v2-krait-cpu

Hi Viresh, On 2/6/2018 9:57 AM, Viresh Kumar wrote: > On 06-02-18, 09:38, Sricharan R wrote: >> In Certain QCOM SoCs like ipq8064, apq8064, msm8960, msm8974 >> that has KRAIT processors the voltage/current value of each OPP >> varies based on the silicon variant in use. >>

Re: [PATCH RESEND] rpmsg: virtio_rpmsg_bus: fix rpmsg_probe() for virtio-mmio transport

Hi Bjorn, Can you please have a look at this patch? Regards, Anup

Re: [PATCH RESEND] rpmsg: Add driver_override device attribute for rpmsg_device

Hi Bjorn, Can you please have a look at this patch? Regards, Anup

Re: [PATCH v6 14/15] cpufreq: Add module to register cpufreq on Krait CPUs

Hi Viresh, On 2/6/2018 9:56 AM, Viresh Kumar wrote: > On 06-02-18, 09:38, Sricharan R wrote: >> diff --git a/drivers/cpufreq/qcom-cpufreq.c b/drivers/cpufreq/qcom-cpufreq.c >> new file mode 100644 >> index 000..5b988d4 >> --- /dev/null >> +++ b/drivers/cpufreq/qcom-cpufreq.c >> @@ -0,0 +1,161

Re: [PATCH v6 14/15] cpufreq: Add module to register cpufreq on Krait CPUs

Hi Viresh, On 2/6/2018 9:56 AM, Viresh Kumar wrote: > On 06-02-18, 09:38, Sricharan R wrote: >> diff --git a/drivers/cpufreq/qcom-cpufreq.c b/drivers/cpufreq/qcom-cpufreq.c >> new file mode 100644 >> index 000..5b988d4 >> --- /dev/null >> +++ b/drivers/cpufreq/qcom-cpufreq.c >> @@ -0,0 +1,161

Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

On Tue, 2018-02-06 at 15:05 +1100, Benjamin Herrenschmidt wrote: > On Tue, 2018-02-06 at 10:38 +0800, Ryder Lee wrote: > > > > I think the code should look at the bridge address <0x0800 ...> we list > > in bindings for resolving interrupts in this case, but it seems like it > > use the

Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

On Tue, 2018-02-06 at 15:05 +1100, Benjamin Herrenschmidt wrote: > On Tue, 2018-02-06 at 10:38 +0800, Ryder Lee wrote: > > > > I think the code should look at the bridge address <0x0800 ...> we list > > in bindings for resolving interrupts in this case, but it seems like it > > use the

Re: [PATCH 8/8] thermal/drivers/cpu_cooling: Add the combo cpu cooling device

On 05-02-18, 11:32, Daniel Lezcano wrote: > On 05/02/2018 05:17, Viresh Kumar wrote: > > Right, but I thought the cooling-maps can help us specify different cooling > > states for different cooling devices for the same trip point. Maybe my > > understanding of that is incorrect. Any inputs on

Re: [PATCH 8/8] thermal/drivers/cpu_cooling: Add the combo cpu cooling device

On 05-02-18, 11:32, Daniel Lezcano wrote: > On 05/02/2018 05:17, Viresh Kumar wrote: > > Right, but I thought the cooling-maps can help us specify different cooling > > states for different cooling devices for the same trip point. Maybe my > > understanding of that is incorrect. Any inputs on

Re: [PATCH v6 15/15] dt-bindings: cpufreq: Document operating-points-v2-krait-cpu

On 06-02-18, 09:38, Sricharan R wrote: > In Certain QCOM SoCs like ipq8064, apq8064, msm8960, msm8974 > that has KRAIT processors the voltage/current value of each OPP > varies based on the silicon variant in use. > operating-points-v2-krait-cpu specifies the phandle to nvmem efuse cells > and the

Re: [PATCH v6 15/15] dt-bindings: cpufreq: Document operating-points-v2-krait-cpu

On 06-02-18, 09:38, Sricharan R wrote: > In Certain QCOM SoCs like ipq8064, apq8064, msm8960, msm8974 > that has KRAIT processors the voltage/current value of each OPP > varies based on the silicon variant in use. > operating-points-v2-krait-cpu specifies the phandle to nvmem efuse cells > and the

Re: [PATCH v6 14/15] cpufreq: Add module to register cpufreq on Krait CPUs

On 06-02-18, 09:38, Sricharan R wrote: > diff --git a/drivers/cpufreq/qcom-cpufreq.c b/drivers/cpufreq/qcom-cpufreq.c > new file mode 100644 > index 000..5b988d4 > --- /dev/null > +++ b/drivers/cpufreq/qcom-cpufreq.c > @@ -0,0 +1,161 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// Copyright

Re: [PATCH v6 14/15] cpufreq: Add module to register cpufreq on Krait CPUs

On 06-02-18, 09:38, Sricharan R wrote: > diff --git a/drivers/cpufreq/qcom-cpufreq.c b/drivers/cpufreq/qcom-cpufreq.c > new file mode 100644 > index 000..5b988d4 > --- /dev/null > +++ b/drivers/cpufreq/qcom-cpufreq.c > @@ -0,0 +1,161 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// Copyright

Re: [PATCH v3 14/21] fpga: dfl: add fpga manager platform driver for FME

On Mon, Feb 5, 2018 at 7:47 PM, Wu Hao wrote: > On Mon, Feb 05, 2018 at 10:36:45AM -0800, Luebbers, Enno wrote: >> Hi Hao, >> >> On Sun, Feb 04, 2018 at 05:37:06PM +0800, Wu Hao wrote: >> > On Fri, Feb 02, 2018 at 04:26:26PM -0800, Luebbers, Enno wrote: >> > > Hi Hao, Alan, >> >

Re: [PATCH v3 14/21] fpga: dfl: add fpga manager platform driver for FME

On Mon, Feb 5, 2018 at 7:47 PM, Wu Hao wrote: > On Mon, Feb 05, 2018 at 10:36:45AM -0800, Luebbers, Enno wrote: >> Hi Hao, >> >> On Sun, Feb 04, 2018 at 05:37:06PM +0800, Wu Hao wrote: >> > On Fri, Feb 02, 2018 at 04:26:26PM -0800, Luebbers, Enno wrote: >> > > Hi Hao, Alan, >> > > >> > > On Fri,

Re: [PATCH v3 14/21] fpga: dfl: add fpga manager platform driver for FME

On Mon, Feb 5, 2018 at 8:17 PM, Wu Hao wrote: > On Mon, Feb 05, 2018 at 11:21:52AM -0600, Alan Tull wrote: >> On Sun, Feb 4, 2018 at 4:05 AM, Wu Hao wrote: >> > On Sat, Feb 03, 2018 at 11:41:24AM +0100, Moritz Fischer wrote: >> >> Hi Hao, >> >> >> >> On Fri,

Re: [PATCH v3 14/21] fpga: dfl: add fpga manager platform driver for FME

On Mon, Feb 5, 2018 at 8:17 PM, Wu Hao wrote: > On Mon, Feb 05, 2018 at 11:21:52AM -0600, Alan Tull wrote: >> On Sun, Feb 4, 2018 at 4:05 AM, Wu Hao wrote: >> > On Sat, Feb 03, 2018 at 11:41:24AM +0100, Moritz Fischer wrote: >> >> Hi Hao, >> >> >> >> On Fri, Feb 02, 2018 at 04:26:26PM -0800,

Re: [PATCH BUGFIX 1/1] block, bfq: add requeue-request hook

Hi Paolo, I applied this to master.today, flipped udev back to bfq and took it for a spin.  Unfortunately, box fairly quickly went boom under load. [ 454.739975] [ cut here ] [ 454.739979] list_add corruption. prev->next should be next (5f99a42a), but was

Re: [PATCH BUGFIX 1/1] block, bfq: add requeue-request hook

Hi Paolo, I applied this to master.today, flipped udev back to bfq and took it for a spin.  Unfortunately, box fairly quickly went boom under load. [ 454.739975] [ cut here ] [ 454.739979] list_add corruption. prev->next should be next (5f99a42a), but was

[PATCH v6 11/15] clk: qcom: Add Krait clock controller driver

From: Stephen Boyd The Krait CPU clocks are made up of a primary mux and secondary mux for each CPU and the L2, controlled via cp15 accessors. For Kraits within KPSSv1 each secondary mux accepts a different aux source, but on KPSSv2 each secondary mux accepts the same aux

[PATCH v6 10/15] dt-bindings: arm: Document qcom,kpss-gcc

From: Stephen Boyd The ACC and GCC regions present in KPSSv1 contain registers to control clocks and power to each Krait CPU and L2. Documenting the bindings here. Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd ---

[PATCH v6 11/15] clk: qcom: Add Krait clock controller driver

From: Stephen Boyd The Krait CPU clocks are made up of a primary mux and secondary mux for each CPU and the L2, controlled via cp15 accessors. For Kraits within KPSSv1 each secondary mux accepts a different aux source, but on KPSSv2 each secondary mux accepts the same aux source. Cc:

[PATCH v6 10/15] dt-bindings: arm: Document qcom,kpss-gcc

From: Stephen Boyd The ACC and GCC regions present in KPSSv1 contain registers to control clocks and power to each Krait CPU and L2. Documenting the bindings here. Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd --- .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt | 7 +

[PATCH v6 13/15] clk: qcom: Add safe switch hook for krait mux clocks

When the Hfplls are reprogrammed during the rate change, the primary muxes which are sourced from the same hfpll for higher frequencies, needs to be switched to the 'safe secondary mux' as the parent for that small window. This is done by registering a clk notifier for the muxes and switching to

[PATCH v6 15/15] dt-bindings: cpufreq: Document operating-points-v2-krait-cpu

In Certain QCOM SoCs like ipq8064, apq8064, msm8960, msm8974 that has KRAIT processors the voltage/current value of each OPP varies based on the silicon variant in use. operating-points-v2-krait-cpu specifies the phandle to nvmem efuse cells and the operating-points-v2 table for each opp. The

[PATCH v6 12/15] dt-bindings: clock: Document qcom,krait-cc

From: Stephen Boyd The Krait clock controller controls the krait CPU and the L2 clocks consisting a primary mux and secondary mux. Add document for that. Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd ---

[PATCH v6 14/15] cpufreq: Add module to register cpufreq on Krait CPUs

From: Stephen Boyd Register a cpufreq-generic device whenever we detect that a "qcom,krait" compatible CPU is present in DT. Cc: [Sricharan: updated to use dev_pm_opp_set_prop_name, NVMEM apis, new binding] Signed-off-by: Sricharan

[PATCH v6 13/15] clk: qcom: Add safe switch hook for krait mux clocks

When the Hfplls are reprogrammed during the rate change, the primary muxes which are sourced from the same hfpll for higher frequencies, needs to be switched to the 'safe secondary mux' as the parent for that small window. This is done by registering a clk notifier for the muxes and switching to

[PATCH v6 15/15] dt-bindings: cpufreq: Document operating-points-v2-krait-cpu

In Certain QCOM SoCs like ipq8064, apq8064, msm8960, msm8974 that has KRAIT processors the voltage/current value of each OPP varies based on the silicon variant in use. operating-points-v2-krait-cpu specifies the phandle to nvmem efuse cells and the operating-points-v2 table for each opp. The

[PATCH v6 12/15] dt-bindings: clock: Document qcom,krait-cc

From: Stephen Boyd The Krait clock controller controls the krait CPU and the L2 clocks consisting a primary mux and secondary mux. Add document for that. Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd --- .../devicetree/bindings/clock/qcom,krait-cc.txt| 22 ++ 1

[PATCH v6 14/15] cpufreq: Add module to register cpufreq on Krait CPUs

From: Stephen Boyd Register a cpufreq-generic device whenever we detect that a "qcom,krait" compatible CPU is present in DT. Cc: [Sricharan: updated to use dev_pm_opp_set_prop_name, NVMEM apis, new binding] Signed-off-by: Sricharan R Signed-off-by: Stephen Boyd ---

[PATCH v6 04/15] clk: qcom: Add HFPLL driver

From: Stephen Boyd On some devices (MSM8974 for example), the HFPLLs are instantiated within the Krait processor subsystem as separate register regions. Add a driver for these PLLs so that we can provide HFPLL clocks for use by the system. Cc:

[PATCH v6 04/15] clk: qcom: Add HFPLL driver

From: Stephen Boyd On some devices (MSM8974 for example), the HFPLLs are instantiated within the Krait processor subsystem as separate register regions. Add a driver for these PLLs so that we can provide HFPLL clocks for use by the system. Cc: Signed-off-by: Stephen Boyd ---

[PATCH v6 07/15] clk: qcom: Add IPQ806X's HFPLLs

From: Stephen Boyd Describe the HFPLLs present on IPQ806X devices. Signed-off-by: Stephen Boyd --- drivers/clk/qcom/gcc-ipq806x.c | 82 ++ 1 file changed, 82 insertions(+) diff --git

[PATCH v6 07/15] clk: qcom: Add IPQ806X's HFPLLs

From: Stephen Boyd Describe the HFPLLs present on IPQ806X devices. Signed-off-by: Stephen Boyd --- drivers/clk/qcom/gcc-ipq806x.c | 82 ++ 1 file changed, 82 insertions(+) diff --git a/drivers/clk/qcom/gcc-ipq806x.c b/drivers/clk/qcom/gcc-ipq806x.c

[PATCH v6 06/15] clk: qcom: Add MSM8960/APQ8064's HFPLLs

From: Stephen Boyd Describe the HFPLLs present on MSM8960 and APQ8064 devices. Acked-by: Rob Herring (bindings) Signed-off-by: Stephen Boyd --- drivers/clk/qcom/gcc-msm8960.c | 172 +++

[PATCH v6 09/15] clk: qcom: Add KPSS ACC/GCC driver

From: Stephen Boyd The ACC and GCC regions present in KPSSv1 contain registers to control clocks and power to each Krait CPU and L2. For CPUfreq purposes probe these devices and expose a mux clock that chooses between PXO and PLL8. Cc:

[PATCH v6 06/15] clk: qcom: Add MSM8960/APQ8064's HFPLLs

From: Stephen Boyd Describe the HFPLLs present on MSM8960 and APQ8064 devices. Acked-by: Rob Herring (bindings) Signed-off-by: Stephen Boyd --- drivers/clk/qcom/gcc-msm8960.c | 172 +++ include/dt-bindings/clock/qcom,gcc-msm8960.h | 2 + 2 files

[PATCH v6 09/15] clk: qcom: Add KPSS ACC/GCC driver

From: Stephen Boyd The ACC and GCC regions present in KPSSv1 contain registers to control clocks and power to each Krait CPU and L2. For CPUfreq purposes probe these devices and expose a mux clock that chooses between PXO and PLL8. Cc: Signed-off-by: Stephen Boyd --- drivers/clk/qcom/Kconfig

[PATCH v6 08/15] clk: qcom: Add support for Krait clocks

From: Stephen Boyd The Krait clocks are made up of a series of muxes and a divider that choose between a fixed rate clock and dedicated HFPLLs for each CPU. Instead of using mmio accesses to remux parents, the Krait implementation exposes the remux control via cp15

[PATCH v6 08/15] clk: qcom: Add support for Krait clocks

From: Stephen Boyd The Krait clocks are made up of a series of muxes and a divider that choose between a fixed rate clock and dedicated HFPLLs for each CPU. Instead of using mmio accesses to remux parents, the Krait implementation exposes the remux control via cp15 registers. Support these

[PATCH v6 03/15] clk: qcom: Add support for High-Frequency PLLs (HFPLLs)

From: Stephen Boyd HFPLLs are the main frequency source for Krait CPU clocks. Add support for changing the rate of these PLLs. Signed-off-by: Stephen Boyd --- drivers/clk/qcom/Makefile| 1 + drivers/clk/qcom/clk-hfpll.c | 244

[PATCH v6 03/15] clk: qcom: Add support for High-Frequency PLLs (HFPLLs)

From: Stephen Boyd HFPLLs are the main frequency source for Krait CPU clocks. Add support for changing the rate of these PLLs. Signed-off-by: Stephen Boyd --- drivers/clk/qcom/Makefile| 1 + drivers/clk/qcom/clk-hfpll.c | 244 +++

[PATCH v6 05/15] dt-bindings: clock: Document qcom,hfpll

From: Stephen Boyd Adds bindings document for qcom,hfpll instantiated within the Krait processor subsystem as separate register region. Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd ---

[PATCH v6 05/15] dt-bindings: clock: Document qcom,hfpll

From: Stephen Boyd Adds bindings document for qcom,hfpll instantiated within the Krait processor subsystem as separate register region. Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd --- .../devicetree/bindings/clock/qcom,hfpll.txt | 46 ++ 1 file changed, 46

[PATCH v6 01/15] ARM: Add Krait L2 register accessor functions

From: Stephen Boyd Krait CPUs have a handful of L2 cache controller registers that live behind a cp15 based indirection register. First you program the indirection register (l2cpselr) to point the L2 'window' register (l2cpdr) at what you want to read/write. Then you

[PATCH v6 01/15] ARM: Add Krait L2 register accessor functions

From: Stephen Boyd Krait CPUs have a handful of L2 cache controller registers that live behind a cp15 based indirection register. First you program the indirection register (l2cpselr) to point the L2 'window' register (l2cpdr) at what you want to read/write. Then you read/write the 'window'

[PATCH v6 02/15] clk: mux: Split out register accessors for reuse

From: Stephen Boyd We want to reuse the logic in clk-mux.c for other clock drivers that don't use readl as register accessors. Fortunately, there really isn't much to the mux code besides the table indirection and quirk flags if you assume any bit shifting and masking has

[PATCH v6 02/15] clk: mux: Split out register accessors for reuse

From: Stephen Boyd We want to reuse the logic in clk-mux.c for other clock drivers that don't use readl as register accessors. Fortunately, there really isn't much to the mux code besides the table indirection and quirk flags if you assume any bit shifting and masking has been done already. Pull

[PATCH v6 00/15] [v6] Krait clocks + Krait CPUfreq

[v6] * Adrressed comments from Viresh for patch #14 in v5 [5] * Introduced a new binding operating-points-v2-krait-cpu as per discussion with Rob * Added Review tags [v5] * Addressed comments from Rob for bindings * Addressed comments from Viresh to use dev_pm_opp_set_prop_name,

[PATCH v6 00/15] [v6] Krait clocks + Krait CPUfreq

[v6] * Adrressed comments from Viresh for patch #14 in v5 [5] * Introduced a new binding operating-points-v2-krait-cpu as per discussion with Rob * Added Review tags [v5] * Addressed comments from Rob for bindings * Addressed comments from Viresh to use dev_pm_opp_set_prop_name,

Re: [PATCH 3/3] clk: exynos5433: Add CLK_IGNORE_UNUSED flag to sclk_ioclk_i2s1_bclk

On 2018년 02월 05일 23:22, Sylwester Nawrocki wrote: > The sclk_ioclk_i2s1_bclk clock is not currently handled by any driver > and disabling this clock by the clk core prevents proper operation > of the I2S1 block. CLK_IGNORE_UNUSED flag is added as a temporary fix. > > Signed-off-by: Sylwester

Re: [PATCH 3/3] clk: exynos5433: Add CLK_IGNORE_UNUSED flag to sclk_ioclk_i2s1_bclk

On 2018년 02월 05일 23:22, Sylwester Nawrocki wrote: > The sclk_ioclk_i2s1_bclk clock is not currently handled by any driver > and disabling this clock by the clk core prevents proper operation > of the I2S1 block. CLK_IGNORE_UNUSED flag is added as a temporary fix. > > Signed-off-by: Sylwester

Re: [PATCH 2/3] clk: exynos5433: Allow audio subsystem clock rate propagation

Hi Sylwester, On 2018년 02월 05일 23:22, Sylwester Nawrocki wrote: > CLK_SET_RATE_PARENT flag is added to definitions of clocks on a path > starting from CLK_SCLK_I2S1 up to AUD_PLL in order to allow setting > required audio root clock frequency for the I2S1 block. This is now > only done for the

Re: [PATCH 2/3] clk: exynos5433: Allow audio subsystem clock rate propagation

Hi Sylwester, On 2018년 02월 05일 23:22, Sylwester Nawrocki wrote: > CLK_SET_RATE_PARENT flag is added to definitions of clocks on a path > starting from CLK_SCLK_I2S1 up to AUD_PLL in order to allow setting > required audio root clock frequency for the I2S1 block. This is now > only done for the

Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

On Tue, 2018-02-06 at 10:38 +0800, Ryder Lee wrote: > > I think the code should look at the bridge address <0x0800 ...> we list > in bindings for resolving interrupts in this case, but it seems like it > use the 'pdev->defvn << 8' which is not really we want and will lead to > mismatch. > >

Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

On Tue, 2018-02-06 at 10:38 +0800, Ryder Lee wrote: > > I think the code should look at the bridge address <0x0800 ...> we list > in bindings for resolving interrupts in this case, but it seems like it > use the 'pdev->defvn << 8' which is not really we want and will lead to > mismatch. > >

Re: [RESEND PATCH] rtc: Fix overflow when converting time64_t to rtc_time

Hi Alexandre, On 26 January 2018 at 17:24, Arnd Bergmann wrote: > On Fri, Jan 26, 2018 at 6:06 AM, Baolin Wang wrote: >> If we convert one large time values to rtc_time, in the original formula >> 'days * 86400' can be overflowed in 'unsigned int' type to

Re: [RESEND PATCH] rtc: Fix overflow when converting time64_t to rtc_time

Hi Alexandre, On 26 January 2018 at 17:24, Arnd Bergmann wrote: > On Fri, Jan 26, 2018 at 6:06 AM, Baolin Wang wrote: >> If we convert one large time values to rtc_time, in the original formula >> 'days * 86400' can be overflowed in 'unsigned int' type to make the formula >> get one incorrect

[PATCH] f2fs: add fi->commit_lock to protect commit GCed pages

This patch adds fi->commit_lock to avoid the case that GCed node pages are committed but GCed data pages are not committed. This can avoid the db file run into inconsistent state when sudden-power-off happens if data pages of atomic file is allowed to be GCed before. Signed-off-by: Yunlong Song

[PATCH] f2fs: add fi->commit_lock to protect commit GCed pages

This patch adds fi->commit_lock to avoid the case that GCed node pages are committed but GCed data pages are not committed. This can avoid the db file run into inconsistent state when sudden-power-off happens if data pages of atomic file is allowed to be GCed before. Signed-off-by: Yunlong Song

linux-next: Tree for Feb 6

Hi all, Please do not add any v4.17 material to your linux-next included branches until after v4.16-rc1 has been released. Changes since 20180205: Linus' tree lost its build failure. The tip tree gained conflicts against Linus' tree. The akpm tree lost a patch that turned up elsewhere. Non

linux-next: Tree for Feb 6

Hi all, Please do not add any v4.17 material to your linux-next included branches until after v4.16-rc1 has been released. Changes since 20180205: Linus' tree lost its build failure. The tip tree gained conflicts against Linus' tree. The akpm tree lost a patch that turned up elsewhere. Non

[PATCH] linux 2.6.36 netfilter conntrack: Fix conntrack table full error when low memory

0001-linux2.6.36-netfilter-conntrack-Fix-conntrack-table-full-error-w.patch Description: Binary data

[PATCH] linux 2.6.36 netfilter conntrack: Fix conntrack table full error when low memory

0001-linux2.6.36-netfilter-conntrack-Fix-conntrack-table-full-error-w.patch Description: Binary data

Re: [RFC] apparent bogosity in unregister_ftrace_function_probe_func()

2018-02-06 2:48 GMT+00:00 Steven Rostedt : > On Tue, 6 Feb 2018 02:44:03 + > Dmitry Safonov <0x7f454...@gmail.com> wrote: > > >> Yes, I've planned to do this.. >> As it's merge-window now I thought doing this a week later. >> So, it's up to you - just let me know so we

Re: [RFC] apparent bogosity in unregister_ftrace_function_probe_func()

2018-02-06 2:48 GMT+00:00 Steven Rostedt : > On Tue, 6 Feb 2018 02:44:03 + > Dmitry Safonov <0x7f454...@gmail.com> wrote: > > >> Yes, I've planned to do this.. >> As it's merge-window now I thought doing this a week later. >> So, it's up to you - just let me know so we will not end doing the

Re: [PATCH v21 4/4] soc: mediatek: Add Mediatek CMDQ helper

Hi, Houlong: I've some inline comment. On Wed, 2018-01-31 at 15:28 +0800, houlong@mediatek.com wrote: > From: "hs.l...@mediatek.com" > > Add Mediatek CMDQ helper to create CMDQ packet and assemble GCE op code. > > Signed-off-by: Houlong Wei

Re: [PATCH v21 4/4] soc: mediatek: Add Mediatek CMDQ helper

Hi, Houlong: I've some inline comment. On Wed, 2018-01-31 at 15:28 +0800, houlong@mediatek.com wrote: > From: "hs.l...@mediatek.com" > > Add Mediatek CMDQ helper to create CMDQ packet and assemble GCE op code. > > Signed-off-by: Houlong Wei > Signed-off-by: HS Liao > --- >

Re: [PATCH 1/3] perf tools: Fix period/freq terms setup

On Mon, Feb 5, 2018 at 1:13 PM, Arnaldo Carvalho de Melo wrote: > Em Mon, Feb 05, 2018 at 12:58:16PM -0800, Stephane Eranian escreveu: >> On Mon, Feb 5, 2018 at 7:17 AM, Jiri Olsa wrote: >> > On Fri, Feb 02, 2018 at 01:04:34PM -0800, Stephane Eranian wrote: >>

Re: [PATCH 1/3] perf tools: Fix period/freq terms setup

On Mon, Feb 5, 2018 at 1:13 PM, Arnaldo Carvalho de Melo wrote: > Em Mon, Feb 05, 2018 at 12:58:16PM -0800, Stephane Eranian escreveu: >> On Mon, Feb 5, 2018 at 7:17 AM, Jiri Olsa wrote: >> > On Fri, Feb 02, 2018 at 01:04:34PM -0800, Stephane Eranian wrote: >> >> On Fri, Feb 2, 2018 at 12:40 PM,

Re: [RFC] apparent bogosity in unregister_ftrace_function_probe_func()

On Tue, 6 Feb 2018 02:44:03 + Dmitry Safonov <0x7f454...@gmail.com> wrote: > Yes, I've planned to do this.. > As it's merge-window now I thought doing this a week later. > So, it's up to you - just let me know so we will not end doing the same fix :) > If you haven't done it already, I'll

Re: [RFC] apparent bogosity in unregister_ftrace_function_probe_func()

On Tue, 6 Feb 2018 02:44:03 + Dmitry Safonov <0x7f454...@gmail.com> wrote: > Yes, I've planned to do this.. > As it's merge-window now I thought doing this a week later. > So, it's up to you - just let me know so we will not end doing the same fix :) > If you haven't done it already, I'll

Re: [PATCH v3 06/21] fpga: dfl: adds fpga_cdev_find_port

On Mon, Feb 05, 2018 at 04:08:19PM -0600, Alan Tull wrote: > On Mon, Nov 27, 2017 at 12:42 AM, Wu Hao wrote: > > Hi Hao, > > A couple comments below. > > > For feature devices, e.g FPGA Management Engine (FME), > > The first use I see of this function in this patchset is the

Re: [PATCH v3 06/21] fpga: dfl: adds fpga_cdev_find_port

On Mon, Feb 05, 2018 at 04:08:19PM -0600, Alan Tull wrote: > On Mon, Nov 27, 2017 at 12:42 AM, Wu Hao wrote: > > Hi Hao, > > A couple comments below. > > > For feature devices, e.g FPGA Management Engine (FME), > > The first use I see of this function in this patchset is the FME PR, > not the

Re: [PATCH 2/5] KVM: x86: add support for UMIP

2017-11-13 22:40 GMT+08:00 Paolo Bonzini : > Add the CPUID bits, make the CR4.UMIP bit not reserved anymore, and > add UMIP support for instructions that are already emulated by KVM. > > Signed-off-by: Paolo Bonzini > --- >

Re: [PATCH 2/5] KVM: x86: add support for UMIP

2017-11-13 22:40 GMT+08:00 Paolo Bonzini : > Add the CPUID bits, make the CR4.UMIP bit not reserved anymore, and > add UMIP support for instructions that are already emulated by KVM. > > Signed-off-by: Paolo Bonzini > --- > arch/x86/include/asm/kvm_host.h | 2 +- > arch/x86/kvm/cpuid.c

Re: [PATCH 1/3] clk: exynos5433: Extend list of available AUD_PLL output frequencies

Hi Sylwester, When I developed the clk-exynos5433.c I referred to the following description. TRM specified that "Samsung recommends only the values between 252MH ~ 400MHz in the PMS2460X PMS value" for aud_pll. It looks like that you refer to clk-exynos5420.c driver. But, I'm wondering

Re: [PATCH 1/3] clk: exynos5433: Extend list of available AUD_PLL output frequencies

Hi Sylwester, When I developed the clk-exynos5433.c I referred to the following description. TRM specified that "Samsung recommends only the values between 252MH ~ 400MHz in the PMS2460X PMS value" for aud_pll. It looks like that you refer to clk-exynos5420.c driver. But, I'm wondering

Re: [RFC] apparent bogosity in unregister_ftrace_function_probe_func()

2018-02-06 2:40 GMT+00:00 Steven Rostedt : > On Tue, 6 Feb 2018 11:26:14 +0900 > Masami Hiramatsu wrote: > >> No, that code looks good to me. :) >> >> BTW, did you also remove "search = buff;" line in >> unregister_ftrace_function_probe_func() too? > >

Re: [PATCH 2/3] ARM: dts: sun8i: add audio codec support into V3s DTSI

于 2018年2月3日 GMT+08:00 上午3:49:35, Maxime Ripard 写到: >On Fri, Feb 02, 2018 at 10:01:52PM +0800, Icenowy Zheng wrote: >> Allwinner V3s SoC features an internal audio codec like the one in >H3, >> and a analog codec like the one in H3/A23 (but much simpler). >> >> Add

Re: [PATCH 2/3] ARM: dts: sun8i: add audio codec support into V3s DTSI

于 2018年2月3日 GMT+08:00 上午3:49:35, Maxime Ripard 写到: >On Fri, Feb 02, 2018 at 10:01:52PM +0800, Icenowy Zheng wrote: >> Allwinner V3s SoC features an internal audio codec like the one in >H3, >> and a analog codec like the one in H3/A23 (but much simpler). >> >> Add them in the DTSI file. >> >>

Re: [RFC] apparent bogosity in unregister_ftrace_function_probe_func()

2018-02-06 2:40 GMT+00:00 Steven Rostedt : > On Tue, 6 Feb 2018 11:26:14 +0900 > Masami Hiramatsu wrote: > >> No, that code looks good to me. :) >> >> BTW, did you also remove "search = buff;" line in >> unregister_ftrace_function_probe_func() too? > > That's a separate bug, and should be a

Re: [RFC] apparent bogosity in unregister_ftrace_function_probe_func()

On Tue, 6 Feb 2018 11:26:14 +0900 Masami Hiramatsu wrote: > No, that code looks good to me. :) > > BTW, did you also remove "search = buff;" line in > unregister_ftrace_function_probe_func() too? That's a separate bug, and should be a separate patch. Dmitry mentioned that

[RFC] tracing: Improve design of preemptirq tracepoints and its users

This patch detaches the preemptirq tracepoints from the tracers and keeps it separate. With this, several ifdefs are cleaner, and lockdep and other users can use the preemptirq tracepoints by registering probes onto them. This makes it much cleaner, but not just that: PROVE_LOCKING and

<    1   2   3   4   5   6   7   8   9   10   >