RE: [PATCH V2] kernel/watchdog: fix spurious hard lockups
On Mon, 17 Jul 2017, Liang, Kan wrote: > There are three proposed patches so far. > Patch 1: The patch as above which speed up the hrtimer. > Patch 2: Thomas's first proposal. > https://patchwork.kernel.org/patch/9803033/ > https://patchwork.kernel.org/patch/9805903/ > Patch 3: my original proposal which increase the NMI watchdog timeout by 3X > https://patchwork.kernel.org/patch/9802053/ > > According to our test, only patch 3 works well. > The other two patches will hang the system eventually. > For patch 1, the system hang after running our test case for ~1 hour. > For patch 2, the system hang in running the overnight test. > There is no error message shown when the system hang. So I don't know the > root cause yet. That doesn't make sense. What's the exact test procedure? > BTW: We set 1 to watchdog_thresh when we did the test. > It's believed that can speed up the failure. Believe is not really a technical measure Thanks, tglx
Re: [PATCH 12/14] qcom: mtd: nand: change register offset defines with enums
On 2017-07-04 15:25, Archit Taneja wrote: On 06/29/2017 12:46 PM, Abhishek Sahu wrote: The current driver defines the register offset with preprocessor macro which is defined crossponding to NAND controller version 1.4.0. This patch changes these macro with enumeration. It also adds mapping array which contains controller register offsets for each register offset enumeration. This mapping array will be referenced before each register read and writes, where the register offset enumeration is being replaced with actual register offsets. Signed-off-by: Abhishek Sahu--- drivers/mtd/nand/qcom_nandc.c | 136 +++--- 1 file changed, 89 insertions(+), 47 deletions(-) diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c index 6d749b6..24750e6 100644 --- a/drivers/mtd/nand/qcom_nandc.c +++ b/drivers/mtd/nand/qcom_nandc.c @@ -24,43 +24,6 @@ #include #include -/* NANDc reg offsets */ -#defineNAND_FLASH_CMD 0x00 -#defineNAND_ADDR0 0x04 -#defineNAND_ADDR1 0x08 -#defineNAND_FLASH_CHIP_SELECT 0x0c -#defineNAND_EXEC_CMD 0x10 -#defineNAND_FLASH_STATUS 0x14 -#defineNAND_BUFFER_STATUS 0x18 -#defineNAND_DEV0_CFG0 0x20 -#defineNAND_DEV0_CFG1 0x24 -#defineNAND_DEV0_ECC_CFG 0x28 -#defineNAND_DEV1_ECC_CFG 0x2c -#defineNAND_DEV1_CFG0 0x30 -#defineNAND_DEV1_CFG1 0x34 -#defineNAND_READ_ID0x40 -#defineNAND_READ_STATUS0x44 -#defineNAND_DEV_CMD0 0xa0 -#defineNAND_DEV_CMD1 0xa4 -#defineNAND_DEV_CMD2 0xa8 -#defineNAND_DEV_CMD_VLD0xac -#defineSFLASHC_BURST_CFG 0xe0 -#defineNAND_ERASED_CW_DETECT_CFG 0xe8 -#defineNAND_ERASED_CW_DETECT_STATUS0xec -#defineNAND_EBI2_ECC_BUF_CFG 0xf0 -#defineFLASH_BUF_ACC 0x100 - -#defineNAND_CTRL 0xf00 -#defineNAND_VERSION0xf08 -#defineNAND_READ_LOCATION_00xf20 -#defineNAND_READ_LOCATION_10xf24 -#defineNAND_READ_LOCATION_20xf28 -#defineNAND_READ_LOCATION_30xf2c - -/* dummy register offsets, used by write_reg_dma */ -#defineNAND_DEV_CMD1_RESTORE 0xdead -#defineNAND_DEV_CMD_VLD_RESTORE0xbeef - /* NAND_FLASH_CMD bits */ #define PAGE_ACCBIT(4) #define LAST_PAGE BIT(5) @@ -204,6 +167,44 @@ #define QPIC_PER_CW_MAX_CMD_SGL (32) #define QPIC_PER_CW_MAX_DATA_SGL (8) +/* NANDc reg offsets enumeration */ +enum { + NAND_FLASH_CMD, + NAND_ADDR0, + NAND_ADDR1, + NAND_FLASH_CHIP_SELECT, + NAND_EXEC_CMD, + NAND_FLASH_STATUS, + NAND_BUFFER_STATUS, + NAND_DEV0_CFG0, + NAND_DEV0_CFG1, + NAND_DEV0_ECC_CFG, + NAND_DEV1_ECC_CFG, + NAND_DEV1_CFG0, + NAND_DEV1_CFG1, + NAND_READ_ID, + NAND_READ_STATUS, + NAND_DEV_CMD0, + NAND_DEV_CMD1, + NAND_DEV_CMD2, + NAND_DEV_CMD_VLD, + SFLASHC_BURST_CFG, + NAND_ERASED_CW_DETECT_CFG, + NAND_ERASED_CW_DETECT_STATUS, + NAND_EBI2_ECC_BUF_CFG, + FLASH_BUF_ACC, + NAND_CTRL, + NAND_VERSION, + NAND_READ_LOCATION_0, + NAND_READ_LOCATION_1, + NAND_READ_LOCATION_2, + NAND_READ_LOCATION_3, + + /* dummy register offsets, used by write_reg_dma */ + NAND_DEV_CMD1_RESTORE, + NAND_DEV_CMD_VLD_RESTORE, +}; + /* * This data type corresponds to the BAM transaction which will be used for all * NAND transfers. @@ -326,6 +327,7 @@ struct nandc_regs { *bam dma * @max_cwperpage:maximum qpic codeword required. calcualted *from all nand device pagesize + * @regs_offsets: register offset mapping array */ struct qcom_nand_controller { struct nand_hw_control controller; @@ -371,6 +373,7 @@ struct qcom_nand_controller { u32 cmd1, vld; u32 ecc_modes; + const u32 *regs_offsets; minor quirk: s/regs_offsets/reg_offsets Sure. I will fix this in v2. }; /* @@ -434,6 +437,40 @@ struct qcom_nand_driver_data { bool dma_bam_enabled; }; +/* Mapping table which contains the actual register offsets */ +static const u32 regs_offsets[] = { + [NAND_FLASH_CMD] = 0x00, + [NAND_ADDR0] = 0x04, + [NAND_ADDR1] = 0x08, + [NAND_FLASH_CHIP_SELECT] = 0x0c, +
Re: [PATCH v5 1/2] clk: gate: expose clk_gate_ops::is_enabled
Hi Stephen, On 07/14/2017 08:52 PM, kbuild test robot wrote: > Hi Gabriel, > > [auto build test ERROR on clk/clk-next] > [also build test ERROR on v4.12 next-20170714] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/gabriel-fernandez-st-com/clk-stm32h7-Add-stm32h743-clock-driver/20170714-170518 > base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next > config: arm-lpc32xx_defconfig (attached as .config) > compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 > reproduce: > wget > https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=arm > > All errors (new ones prefixed by >>): > >>> drivers/clk/nxp/clk-lpc32xx.c:906:12: error: static declaration of >>> 'clk_gate_is_enabled' follows non-static declaration > static int clk_gate_is_enabled(struct clk_hw *hw) > ^~~ > In file included from drivers/clk/nxp/clk-lpc32xx.c:13:0: > include/linux/clk-provider.h:346:5: note: previous declaration of > 'clk_gate_is_enabled' was here > int clk_gate_is_enabled(struct clk_hw *hw); > ^~~ > > vim +/clk_gate_is_enabled +906 drivers/clk/nxp/clk-lpc32xx.c > > f7c82a60 Vladimir Zapolskiy 2015-12-06 905 > f7c82a60 Vladimir Zapolskiy 2015-12-06 @906 static int > clk_gate_is_enabled(struct clk_hw *hw) > f7c82a60 Vladimir Zapolskiy 2015-12-06 907 { > f7c82a60 Vladimir Zapolskiy 2015-12-06 908 struct lpc32xx_clk_gate *clk = > to_lpc32xx_gate(hw); > f7c82a60 Vladimir Zapolskiy 2015-12-06 909 u32 val; > f7c82a60 Vladimir Zapolskiy 2015-12-06 910 bool is_set; > f7c82a60 Vladimir Zapolskiy 2015-12-06 911 > f7c82a60 Vladimir Zapolskiy 2015-12-06 912 regmap_read(clk_regmap, > clk->reg, ); > f7c82a60 Vladimir Zapolskiy 2015-12-06 913 is_set = val & > BIT(clk->bit_idx); > f7c82a60 Vladimir Zapolskiy 2015-12-06 914 > f7c82a60 Vladimir Zapolskiy 2015-12-06 915 return (clk->flags & > CLK_GATE_SET_TO_DISABLE ? !is_set : is_set); > f7c82a60 Vladimir Zapolskiy 2015-12-06 916 } > f7c82a60 Vladimir Zapolskiy 2015-12-06 917 > EXPORT_SYMBOL_GPL(__clk_gate_is_enabled); > > > :: The code at line 906 was first introduced by commit > :: f7c82a60ba26c2f003662bcb2cff131021c1e828 clk: lpc32xx: add common > clock framework driver > > :: TO: Vladimir Zapolskiy> :: CC: Michael Turquette > > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation Rename 'clk_gate_is_enabled' into'__clk_gate_is_enabled' from clk-gate.c file, is it a good solution for you ? i could add also EXPORT_SYMBOL_GPL(__clk_gate_is_enabled) if you are ok. Best Regards Gabriel
[PATCH v2 2/5] dt-bindings: gpu: add a power_model optional properties for MALI
This patch adds the MALI's power-model to set the IPA model to be used for power management. Signed-off-by: Caesar Wang--- Changes in v2: None Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 12 1 file changed, 12 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt index a461e47..b616e6b 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt @@ -37,6 +37,18 @@ Optional properties: - operating-points-v2 : Refer to Documentation/devicetree/bindings/power/opp.txt for details. +- power_model : Sets power model parameters. Note that this model was designed for the Juno + platform, and may not be suitable for other platforms. A structure containing : + - compatible: Should be arm,mali-simple-power-model + - dynamic-coefficient: Coefficient, in pW/(Hz V^2), which is multiplied + by v^2*f to calculate the dynamic power consumption. + - static-coefficient: Coefficient, in uW/V^3, which is multiplied by + v^3 to calculate the static power consumption. + - ts: An array containing coefficients for the temperature scaling + factor. This is used to scale the static power by a factor of + tsf/100, where tsf = ts[3]*T^3 + ts[2]*T^2 + ts[1]*T + ts[0], + and T = temperature in degrees. + - thermal-zone: A string identifying the thermal zone used for the GPU Example for a Mali-T760: -- 2.7.4
[PATCH v2 5/5] arm64: dts: rockchip: update the thermal zones for RK3399 SoCs
As RK3399 had used the Power allocator thermal governor by default, enabled this to manage thermals by dynamically allocating and limiting power to devices. Also, this patch supported the dynamic-power-coefficient/sustainable_power and GPU's power model for needed parameters with thermal IPA. The Thermal power allocator governor works optimatly with two passive trip points, for the better performance we will use the trip-point0 with 70 degree above which the governor control starts operating and trip-point1 with 85 degree is the target temperature by controlling. Signed-off-by: Caesar Wang--- Changes in v2: - foo@ will produce warnings when used without reg property. - update the commit to explain the two passive trip points changed. arch/arm64/boot/dts/rockchip/rk3399.dtsi | 62 +++- 1 file changed, 29 insertions(+), 33 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index 77d67cb..6d8a5eb 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi @@ -147,7 +147,7 @@ enable-method = "psci"; #cooling-cells = <2>; /* min followed by max */ clocks = < ARMCLKB>; - dynamic-power-coefficient = <100>; + dynamic-power-coefficient = <436>; }; cpu_b1: cpu@101 { @@ -156,7 +156,7 @@ reg = <0x0 0x101>; enable-method = "psci"; clocks = < ARMCLKB>; - dynamic-power-coefficient = <100>; + dynamic-power-coefficient = <436>; }; }; @@ -690,24 +690,25 @@ }; thermal_zones: thermal-zones { - cpu_thermal: cpu { + soc_thermal: soc-thermal { polling-delay-passive = <100>; polling-delay = <1000>; + sustainable-power = <1000>; thermal-sensors = < 0>; trips { - cpu_alert0: cpu_alert0 { + threshold: trip-point0 { temperature = <7>; hysteresis = <2000>; type = "passive"; }; - cpu_alert1: cpu_alert1 { - temperature = <75000>; + target: trip-point1 { + temperature = <85000>; hysteresis = <2000>; type = "passive"; }; - cpu_crit: cpu_crit { + soc_crit: soc-crit { temperature = <95000>; hysteresis = <2000>; type = "critical"; @@ -716,45 +717,31 @@ cooling-maps { map0 { - trip = <_alert0>; + trip = <>; cooling-device = - <_b0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + <_l0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + contribution = <4096>; }; map1 { - trip = <_alert1>; + trip = <>; cooling-device = - <_l0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, <_b0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + contribution = <1024>; + }; + map2 { + trip = <>; + cooling-device = + < THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + contribution = <4096>; }; }; }; - gpu_thermal: gpu { + gpu_thermal: gpu-thermal { polling-delay-passive = <100>; polling-delay = <1000>; thermal-sensors = < 1>; - - trips { - gpu_alert0: gpu_alert0 { - temperature = <75000>; -
Re: [PATCH 0/5] Add a script to check for Sphinx install requirements
> Am 17.07.2017 um 00:08 schrieb Mauro Carvalho Chehab >: > > [1] There's an unrelated bug with the Kernel's sphinx extension > kimage: when parsing GraphViz graphs, it uses "-Tpdf" argument, > in order to generate a PDF image. That doesn't work on some > distros, as GraphViz doesn't support PDF images. > Hmm .. http://www.graphviz.org/content/output-formats#dpdf Is it a problem of the GraphViz version? See http://www.graphviz.org/News.php .. """New Release 2.32 (1 August 2013) ... In addition, if the poppler library is available, Graphviz can now use PDF files as images.""" I suppose that 2.32 is in your distro .. it's from 2013 It seems, that the graphiz homepage is not up to date. I found the repo at github. There is a issue about PDF https://github.com/ellson/graphviz/issues/1180 So I guess graphviz is compiled without HAVE_PANGOCAIRO in your distros? -- Markus --
[PATCH v2 4/5] arm64: dts: rockchip: enable the GPU for RK3399-GRU
This patch enables the gpu and adds the mali-supply power for RK3399-GRU devices. Signed-off-by: Caesar Wang--- Changes in v2: None arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi index 90259cf..d48e98b 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi @@ -595,6 +595,11 @@ status = "okay"; }; + { + mali-supply = <_gpu>; + status = "okay"; +}; + ap_i2c_mic: { status = "okay"; -- 2.7.4
Re: [PATCH v2 1/3] mux: Add mux_control_get_optional() API
Generally looks like I imagined, but there are a few nits and some things that I'd like to do differently. Comments inline. Thanks! On 2017-07-14 23:40, Stephen Boyd wrote: > Sometimes drivers only use muxes under certain scenarios. For > example, the chipidea usb controller may be connected to a usb > switch on some platforms, and connected directly to a usb port on > others. The driver won't know one way or the other though, so add > a mux_control_get_optional() API that allows the driver to > differentiate errors getting the mux from there not being a mux > for the driver to use at all. > > Cc: Jonathan Cameron> Cc: Philipp Zabel > Signed-off-by: Stephen Boyd > --- > Documentation/driver-model/devres.txt | 1 + > drivers/mux/mux-core.c| 98 > --- > include/linux/mux/consumer.h | 4 ++ > 3 files changed, 83 insertions(+), 20 deletions(-) > > diff --git a/Documentation/driver-model/devres.txt > b/Documentation/driver-model/devres.txt > index 30e04f7a690d..4fdd3e63ff8b 100644 > --- a/Documentation/driver-model/devres.txt > +++ b/Documentation/driver-model/devres.txt > @@ -342,6 +342,7 @@ MUX >devm_mux_chip_alloc() >devm_mux_chip_register() >devm_mux_control_get() > + devm_mux_control_get_optional() > > PER-CPU MEM >devm_alloc_percpu() > diff --git a/drivers/mux/mux-core.c b/drivers/mux/mux-core.c > index 90b8995f07cb..a0e5bf16f02f 100644 > --- a/drivers/mux/mux-core.c > +++ b/drivers/mux/mux-core.c > @@ -289,6 +289,9 @@ EXPORT_SYMBOL_GPL(devm_mux_chip_register); > */ > unsigned int mux_control_states(struct mux_control *mux) > { > + if (!mux) > + return 0; > + I don't think this is appropriate. For this function, it might be ok, but... > return mux->states; > } > EXPORT_SYMBOL_GPL(mux_control_states); > @@ -338,6 +341,9 @@ int mux_control_select(struct mux_control *mux, unsigned > int state) > { > int ret; > > + if (!mux) > + return 0; > + ...here and for other cases below it's very odd to return "ok", when -EINVAL or something seems much more appropriate. And if -EINVAL is returned here, the benefit of returning fake values for anything pretty much falls apart. I simply don't like it, and prefer if the consumer code is arranged to not call the mux functions when the optional get() does not find the mux. > ret = down_killable(>lock); > if (ret < 0) > return ret; > @@ -370,6 +376,9 @@ int mux_control_try_select(struct mux_control *mux, > unsigned int state) > { > int ret; > > + if (!mux) > + return 0; > + > if (down_trylock(>lock)) > return -EBUSY; > > @@ -398,6 +407,9 @@ int mux_control_deselect(struct mux_control *mux) > { > int ret = 0; > > + if (!mux) > + return 0; > + > if (mux->idle_state != MUX_IDLE_AS_IS && > mux->idle_state != mux->cached_state) > ret = mux_control_set(mux, mux->idle_state); > @@ -422,14 +434,8 @@ static struct mux_chip *of_find_mux_chip_by_node(struct > device_node *np) > return dev ? to_mux_chip(dev) : NULL; > } > > -/** > - * mux_control_get() - Get the mux-control for a device. > - * @dev: The device that needs a mux-control. > - * @mux_name: The name identifying the mux-control. > - * > - * Return: A pointer to the mux-control, or an ERR_PTR with a negative errno. > - */ > -struct mux_control *mux_control_get(struct device *dev, const char *mux_name) > +struct mux_control * > +__mux_control_get(struct device *dev, const char *mux_name, bool optional) > { > struct device_node *np = dev->of_node; > struct of_phandle_args args; > @@ -441,6 +447,8 @@ struct mux_control *mux_control_get(struct device *dev, > const char *mux_name) > if (mux_name) { > index = of_property_match_string(np, "mux-control-names", >mux_name); > + if (index == -EINVAL && optional) > + return NULL; What about -ENODATA? And if an optional mux is found here, but lookup fails later in e.g. the of_parse_phandle_with_args call, then I think an error should be returned. Because that seems like an indication that DT specifies that there *should* be a mux, but then there isn't one. > if (index < 0) { > dev_err(dev, "mux controller '%s' not found\n", > mux_name); > @@ -451,6 +459,8 @@ struct mux_control *mux_control_get(struct device *dev, > const char *mux_name) > ret = of_parse_phandle_with_args(np, >"mux-controls", "#mux-control-cells", >index, ); > + if (ret == -ENOENT && optional) > + return NULL; > if (ret) { > dev_err(dev, "%s: failed to get mux-control
Re: [PATCH] EDAC: remove unnecessary static in edac_fake_inject_write()
On Tue, Jul 04, 2017 at 04:44:40PM -0500, Gustavo A. R. Silva wrote: > Remove unnecessary static on local variable _type_. > Such variable is initialized before being used, > on every execution path throughout the function. > The static has no benefit and, removing it reduces > the code size. > > This issue was detected using Coccinelle and the following semantic patch: > > @bad exists@ > position p; > identifier x; > type T; > @@ > > static T x@p; > ... > x = <+...x...+> > > @@ > identifier x; > expression e; > type T; > position p != bad.p; > @@ > > -static > T x@p; > ... when != x > when strict > ?x = e; So the fix is ok but I don't understand Coccinelle to be able to judge whether the above patch is fine or not. If it is, it probably should be put somewhere in scripts/coccinelle/ so that others can use it too so that they can catch such useless uses of static too. Lemme add the Coccinelle ML to CC. (Leaving in the rest for reference.) > In the following log you can see the difference in the code size and, > also a significant difference in bss segment. This log is the output > of the size command, before and after the code change: > > before: >textdata bss dec hex filename >2966 920 1284014 fae drivers/edac/debugfs.o > > after: >text data bssdec hex filename >2961 832 643857 f11 drivers/edac/debugfs.o > > Signed-off-by: Gustavo A. R. Silva> --- > drivers/edac/debugfs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/edac/debugfs.c b/drivers/edac/debugfs.c > index 92dbb7e..ba0af49 100644 > --- a/drivers/edac/debugfs.c > +++ b/drivers/edac/debugfs.c > @@ -8,7 +8,7 @@ static ssize_t edac_fake_inject_write(struct file *file, > { > struct device *dev = file->private_data; > struct mem_ctl_info *mci = to_mci(dev); > - static enum hw_event_mc_err_type type; > + enum hw_event_mc_err_type type; > u16 errcount = mci->fake_inject_count; > > if (!errcount) > -- > 2.5.0 > -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --
Re: [PATCH v2] mm/vmalloc: terminate searching since one node found
On 07/17/2017 04:07 PM, Zhaoyang Huang wrote: > It is no need to find the very beginning of the area within > alloc_vmap_area, which can be done by judging each node during the process > > For current approach, the worst case is that the starting node which be found > for searching the 'vmap_area_list' is close to the 'vstart', while the final > available one is round to the tail(especially for the left branch). > This commit have the list searching start at the first available node, which > will save the time of walking the rb tree'(1)' and walking the list(2). > > vmap_area_root > / \ > tmp_next U > / (1) > tmp >/ > ... > / > first(current approach) > > vmap_area_list->...->first->...->tmp->tmp_next the original code can ensure the following two points : A, the result vamp_area has the lowest available address in the range [vstart, vend) B, it can maintain the cached vamp_area node rightly which can speedup relative allocation i suspect this patch maybe destroy the above two points > (2) > > Signed-off-by: Zhaoyang Huang> --- > mm/vmalloc.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 34a1c3e..f833e07 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -459,9 +459,16 @@ static struct vmap_area *alloc_vmap_area(unsigned > long size, > > while (n) { > struct vmap_area *tmp; > + struct vmap_area *tmp_next; > tmp = rb_entry(n, struct vmap_area, rb_node); > + tmp_next = list_next_entry(tmp, list); > if (tmp->va_end >= addr) { > first = tmp; > + if (ALIGN(tmp->va_end, align) + size > + < tmp_next->va_start) { > + addr = ALIGN(tmp->va_end, align); > + goto found; > + } is the aim vamp_area the lowest available one if the goto occurs ? it will bypass the latter cached vamp_area info cached_hole_size update possibly if the goto occurs > if (tmp->va_start <= addr) > break; > n = n->rb_left; > -- > 1.9.1 >
Re: [PATCH 02/18] drm/sun4i: Add if statement instead of depends on
On Fri, Jul 14, 2017 at 11:09:07AM +0800, Chen-Yu Tsai wrote: > On Thu, Jul 13, 2017 at 10:12 PM, Maxime Ripard >wrote: > > The depends on relationship is obvious, and using an if statement will > > propagate it to every option without the need for each and every one of > > them to define it. > > > > Signed-off-by: Maxime Ripard > > Reviewed-by: Chen-Yu Tsai Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH v3 1/2] extcon: cros-ec: Add extcon-cros-ec driver to support display out.
Hi Enric, When I tried to apply this patch, error happened as following: (based on v4.13-rc1) Applying: extcon: cros-ec: Add extcon-cros-ec driver to support display out. error: patch failed: include/linux/mfd/cros_ec_commands.h:285 error: include/linux/mfd/cros_ec_commands.h: patch does not apply Is it based on v4.13-rc1? On 2017년 07월 17일 16:37, Enric Balletbo i Serra wrote: > From: Benson Leung> > This is the driver for the USB Type C cable detection mechanism > built into the ChromeOS Embedded Controller on systems that > have USB Type-C ports. > > At present, this allows for the presence of display out, but in > future, it may also be used to notify host and device type cables > and the presence of power. > > Signed-off-by: Benson Leung > Signed-off-by: Enric Balletbo i Serra > Acked-by: Chanwoo Choi > Acked-by: Lee Jones > --- > Changes since v2: > - Rebase on top of v4.13-rc1 > Changes since v1: > Requested by Chanwoo Choi > - Rename files changing _ for - > - Remove the unneeded blank line on bottom of header. > - Remove kobject.h and cros_ec_commands.h includes. > - Remove the debug message as is not necessary. > - Use the tab for indentation instead of space for if sentence. > - Define each variable on different lines when the variables should be >initialized. > - Remove EXTCON_USB and EXTCON_USB_HOST as are not really used for now. > - Add one blank line to split out between state and property setting. > - Add the author information (header and module) > > Enric Balletbo > - As Rob suggested to rename the compatible name to something indicating that >is USB Type C related I also renamed the file names, extcon-cros-ec -> >extcon-usbc-cros-ec, I think it's more clear. > > drivers/extcon/Kconfig | 7 + > drivers/extcon/Makefile | 1 + > drivers/extcon/extcon-usbc-cros-ec.c | 415 > +++ > include/linux/mfd/cros_ec_commands.h | 75 +++ > 4 files changed, 498 insertions(+) > create mode 100644 drivers/extcon/extcon-usbc-cros-ec.c > > diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig > index 6d50071..a7bca42 100644 > --- a/drivers/extcon/Kconfig > +++ b/drivers/extcon/Kconfig > @@ -150,4 +150,11 @@ config EXTCON_USB_GPIO > Say Y here to enable GPIO based USB cable detection extcon support. > Used typically if GPIO is used for USB ID pin detection. > > +config EXTCON_USBC_CROS_EC > + tristate "ChromeOS Embedded Controller EXTCON support" > + depends on MFD_CROS_EC > + help > + Say Y here to enable USB Type C cable detection extcon support when > + using Chrome OS EC based USB Type-C ports. > + > endif > diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile > index ecfa958..a73624e 100644 > --- a/drivers/extcon/Makefile > +++ b/drivers/extcon/Makefile > @@ -20,3 +20,4 @@ obj-$(CONFIG_EXTCON_QCOM_SPMI_MISC) += > extcon-qcom-spmi-misc.o > obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o > obj-$(CONFIG_EXTCON_SM5502) += extcon-sm5502.o > obj-$(CONFIG_EXTCON_USB_GPIO)+= extcon-usb-gpio.o > +obj-$(CONFIG_EXTCON_USBC_CROS_EC) += extcon-usbc-cros-ec.o > diff --git a/drivers/extcon/extcon-usbc-cros-ec.c > b/drivers/extcon/extcon-usbc-cros-ec.c > new file mode 100644 > index 000..e759ed4 > --- /dev/null > +++ b/drivers/extcon/extcon-usbc-cros-ec.c > @@ -0,0 +1,415 @@ > +/** > + * drivers/extcon/extcon-usbc-cros-ec - ChromeOS Embedded Controller extcon > + * > + * Copyright (C) 2017 Google, Inc > + * Author: Benson Leung > + * > + * This software is licensed under the terms of the GNU General Public > + * License version 2, as published by the Free Software Foundation, and > + * may be copied, distributed, and modified under those terms. > + * > + * 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 > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +struct cros_ec_extcon_info { > + struct device *dev; > + struct extcon_dev *edev; > + > + int port_id; > + > + struct cros_ec_device *ec; > + > + struct notifier_block notifier; > + > + bool dp; /* DisplayPort enabled */ > + bool mux; /* SuperSpeed (usb3) enabled */ > + unsigned int power_type; > +}; > + > +static const unsigned int usb_type_c_cable[] = { > + EXTCON_DISP_DP, > + EXTCON_NONE, > +}; > + > +/** > + * cros_ec_pd_command() - Send a command to the EC. > + * @info: pointer to struct cros_ec_extcon_info > + * @command: EC command > + * @version: EC command version > + * @outdata: EC command output data > + *
Re: [PATCH v6 2/6] clk: sunxi-ng: Add sun4i/sun7i CCU driver
Hi, On Fri, Jul 14, 2017 at 05:49:24PM +0300, Priit Laes wrote: > Introduce a clock controller driver for sun4i A10 and sun7i A20 > series SoCs. > > Signed-off-by: Priit Laes> --- > drivers/clk/sunxi-ng/Kconfig | 13 +- > drivers/clk/sunxi-ng/Makefile |1 +- > drivers/clk/sunxi-ng/ccu-sun4i-a10.c | 1454 ++- > drivers/clk/sunxi-ng/ccu-sun4i-a10.h | 61 +- > include/dt-bindings/clock/sun4i-a10-ccu.h | 200 +++- > include/dt-bindings/clock/sun7i-a20-ccu.h | 53 +- > include/dt-bindings/reset/sun4i-a10-ccu.h | 69 +- > 7 files changed, 1851 insertions(+) > create mode 100644 drivers/clk/sunxi-ng/ccu-sun4i-a10.c > create mode 100644 drivers/clk/sunxi-ng/ccu-sun4i-a10.h > create mode 100644 include/dt-bindings/clock/sun4i-a10-ccu.h > create mode 100644 include/dt-bindings/clock/sun7i-a20-ccu.h > create mode 100644 include/dt-bindings/reset/sun4i-a10-ccu.h > > diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig > index 7342928..1b5cea9 100644 > --- a/drivers/clk/sunxi-ng/Kconfig > +++ b/drivers/clk/sunxi-ng/Kconfig > @@ -11,6 +11,19 @@ config SUN50I_A64_CCU > default ARM64 && ARCH_SUNXI > depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST > > +config SUNXI_A10_CCU > + bool "Support for the Allwinner A10/A20 CCU" > + select SUNXI_CCU_DIV > + select SUNXI_CCU_MULT > + select SUNXI_CCU_NK > + select SUNXI_CCU_NKM > + select SUNXI_CCU_NM > + select SUNXI_CCU_MP > + select SUNXI_CCU_PHASE > + default MACH_SUN4I > + default MACH_SUN7I > + depends on MACH_SUN4I || MACH_SUN7I || COMPILE_TEST I'm a bit late on this one, but I agree with Olliver, it should be called SUN4I_A10. This is what we do for all the other symbols (and it should be ordered as such). > + > config SUN5I_CCU > bool "Support for the Allwinner sun5i family CCM" > default MACH_SUN5I > diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile > index 0c45fa5..01e958c 100644 > --- a/drivers/clk/sunxi-ng/Makefile > +++ b/drivers/clk/sunxi-ng/Makefile > @@ -21,6 +21,7 @@ lib-$(CONFIG_SUNXI_CCU) += ccu_mp.o > obj-$(CONFIG_SUN50I_A64_CCU) += ccu-sun50i-a64.o > obj-$(CONFIG_SUN5I_CCU) += ccu-sun5i.o > obj-$(CONFIG_SUN6I_A31_CCU) += ccu-sun6i-a31.o > +obj-$(CONFIG_SUNXI_A10_CCU) += ccu-sun4i-a10.o The ordering is wrong here too. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH v2] mm/page_alloc: Wait for oom_lock before retrying.
On Sun 16-07-17 19:59:51, Tetsuo Handa wrote: > Since the whole memory reclaim path has never been designed to handle the > scheduling priority inversions, those locations which are assuming that > execution of some code path shall eventually complete without using > synchronization mechanisms can get stuck (livelock) due to scheduling > priority inversions, for CPU time is not guaranteed to be yielded to some > thread doing such code path. > > mutex_trylock() in __alloc_pages_may_oom() (waiting for oom_lock) and > schedule_timeout_killable(1) in out_of_memory() (already held oom_lock) is > one of such locations, and it was demonstrated using artificial stressing > that the system gets stuck effectively forever because SCHED_IDLE priority > thread is unable to resume execution at schedule_timeout_killable(1) if > a lot of !SCHED_IDLE priority threads are wasting CPU time [1]. I do not understand this. All the contending tasks will go and sleep for 1s. How can they preempt the lock holder? -- Michal Hocko SUSE Labs
Re: [PATCH v3 1/2] extcon: cros-ec: Add extcon-cros-ec driver to support display out.
Hi, 2017-07-17 10:54 GMT+02:00 Chanwoo Choi: > Hi Enric, > > When I tried to apply this patch, error happened as following: > (based on v4.13-rc1) > > Applying: extcon: cros-ec: Add extcon-cros-ec driver to support display out. > error: patch failed: include/linux/mfd/cros_ec_commands.h:285 > error: include/linux/mfd/cros_ec_commands.h: patch does not apply > Very sorry about that, I had another patch that touched this file and I forget to invert the sequence, first apply these patches then the others. Let me fix that and resend again in few minutes, Very sorry for the noise. > Is it based on v4.13-rc1? > > > On 2017년 07월 17일 16:37, Enric Balletbo i Serra wrote: >> From: Benson Leung >> >> This is the driver for the USB Type C cable detection mechanism >> built into the ChromeOS Embedded Controller on systems that >> have USB Type-C ports. >> >> At present, this allows for the presence of display out, but in >> future, it may also be used to notify host and device type cables >> and the presence of power. >> >> Signed-off-by: Benson Leung >> Signed-off-by: Enric Balletbo i Serra >> Acked-by: Chanwoo Choi >> Acked-by: Lee Jones >> --- >> Changes since v2: >> - Rebase on top of v4.13-rc1 >> Changes since v1: >> Requested by Chanwoo Choi >> - Rename files changing _ for - >> - Remove the unneeded blank line on bottom of header. >> - Remove kobject.h and cros_ec_commands.h includes. >> - Remove the debug message as is not necessary. >> - Use the tab for indentation instead of space for if sentence. >> - Define each variable on different lines when the variables should be >>initialized. >> - Remove EXTCON_USB and EXTCON_USB_HOST as are not really used for now. >> - Add one blank line to split out between state and property setting. >> - Add the author information (header and module) >> >> Enric Balletbo >> - As Rob suggested to rename the compatible name to something indicating >> that >>is USB Type C related I also renamed the file names, extcon-cros-ec -> >>extcon-usbc-cros-ec, I think it's more clear. >> >> drivers/extcon/Kconfig | 7 + >> drivers/extcon/Makefile | 1 + >> drivers/extcon/extcon-usbc-cros-ec.c | 415 >> +++ >> include/linux/mfd/cros_ec_commands.h | 75 +++ >> 4 files changed, 498 insertions(+) >> create mode 100644 drivers/extcon/extcon-usbc-cros-ec.c >> >> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig >> index 6d50071..a7bca42 100644 >> --- a/drivers/extcon/Kconfig >> +++ b/drivers/extcon/Kconfig >> @@ -150,4 +150,11 @@ config EXTCON_USB_GPIO >> Say Y here to enable GPIO based USB cable detection extcon support. >> Used typically if GPIO is used for USB ID pin detection. >> >> +config EXTCON_USBC_CROS_EC >> + tristate "ChromeOS Embedded Controller EXTCON support" >> + depends on MFD_CROS_EC >> + help >> + Say Y here to enable USB Type C cable detection extcon support when >> + using Chrome OS EC based USB Type-C ports. >> + >> endif >> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile >> index ecfa958..a73624e 100644 >> --- a/drivers/extcon/Makefile >> +++ b/drivers/extcon/Makefile >> @@ -20,3 +20,4 @@ obj-$(CONFIG_EXTCON_QCOM_SPMI_MISC) += >> extcon-qcom-spmi-misc.o >> obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o >> obj-$(CONFIG_EXTCON_SM5502) += extcon-sm5502.o >> obj-$(CONFIG_EXTCON_USB_GPIO)+= extcon-usb-gpio.o >> +obj-$(CONFIG_EXTCON_USBC_CROS_EC) += extcon-usbc-cros-ec.o >> diff --git a/drivers/extcon/extcon-usbc-cros-ec.c >> b/drivers/extcon/extcon-usbc-cros-ec.c >> new file mode 100644 >> index 000..e759ed4 >> --- /dev/null >> +++ b/drivers/extcon/extcon-usbc-cros-ec.c >> @@ -0,0 +1,415 @@ >> +/** >> + * drivers/extcon/extcon-usbc-cros-ec - ChromeOS Embedded Controller extcon >> + * >> + * Copyright (C) 2017 Google, Inc >> + * Author: Benson Leung >> + * >> + * This software is licensed under the terms of the GNU General Public >> + * License version 2, as published by the Free Software Foundation, and >> + * may be copied, distributed, and modified under those terms. >> + * >> + * 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 >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +struct cros_ec_extcon_info { >> + struct device *dev; >> + struct extcon_dev *edev; >> + >> + int port_id; >> + >> + struct cros_ec_device *ec; >> + >> + struct notifier_block notifier; >> + >> + bool dp; /* DisplayPort enabled */ >>
Re: [PATCH 01/18] regmap: mmio: Add function to attach a clock
Hi Mark, On Thu, Jul 13, 2017 at 05:01:42PM +0100, Mark Brown wrote: > On Thu, Jul 13, 2017 at 04:12:56PM +0200, Maxime Ripard wrote: > > > This might be problematic if the clock to enable is stored in another node. > > Let's add a function that allows to attach a clock that has already been > > retrieved to a regmap in order to fix this. > > What is the use case for this? This is useful when the clock you want to be handled by the regmap is not described in the device node that probed the driver, but one of its subnode, or an another node entirely. We're in the latter case, where we have two controllers in the DT, but are driven by the same driver. We'll create two regmaps, but one will not have the proper of_node used to retrieve the clock. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for new timing mode
On Fri, Jul 14, 2017 at 02:42:55PM +0800, Chen-Yu Tsai wrote: > The register for the "new timing mode" also has bit fields for setting > output and sample timing phases. According to comments in Allwinner's > BSP kernel, the default values are good enough. > > Keep the default values already in the hardware when setting new timing > mode, instead of overwriting the whole register. > > Fixes: 9a37e53e451e ("mmc: sunxi: Enable the new timings for the A64 MMC > controllers") > Signed-off-by: Chen-Yu TsaiAcked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH 6/9] mm, page_alloc: simplify zonelist initialization
On Mon 17-07-17 09:58:04, Mel Gorman wrote: > On Mon, Jul 17, 2017 at 10:19:42AM +0200, Michal Hocko wrote: > > On Mon 17-07-17 09:07:23, Mel Gorman wrote: > > > On Mon, Jul 17, 2017 at 08:06:40AM +0200, Michal Hocko wrote: > > > > On Fri 14-07-17 15:18:23, Mel Gorman wrote: > > > > > Fairly sure that's not what you meant. > > > > > > > > > > > > > > > > pg_data_t *node = NODE_DATA(node_order[i]); > > > > > > > > > > > > - zoneref_idx = build_zonelists_node(node, zonelist, > > > > > > zoneref_idx); > > > > > > + nr_zones = build_zonelists_node(node, zonelist, > > > > > > nr_zones); > > > > > > > > > > I meant converting build_zonelists_node and passing in _zones and > > > > > returning false when an empty node is encountered. In this context, > > > > > it's also not about zones, it really is nr_zonerefs. Rename nr_zones > > > > > in > > > > > build_zonelists_node as well. > > > > > > > > hmm, why don't we rather make it zonerefs based then. Something > > > > like the following? > > > > > > Works for me. > > > > Should I fold it to the patch or make it a patch on its own? > > I have no strong feelings either way but if it was folded then the > overall naming should be easier to follow (at least for me). OK, I will fold it in then. Unless there are more issues/feedback to address I will repost the full series in few days. Thanks! -- Michal Hocko SUSE Labs
Re: [PATCH 03/11] clk: sunxi-ng: a83t: Support new timing mode for mmc2 clock
Hi, On Fri, Jul 14, 2017 at 02:42:54PM +0800, Chen-Yu Tsai wrote: > The MMC2 clock supports a new timing mode. When the new mode is active, > the output clock rate is halved. > > This patch sets the feature flag for the new timing mode, and adds > a pre-divider based on the mode bit. > > Signed-off-by: Chen-Yu Tsai> --- > drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 38 > +++ > 1 file changed, 30 insertions(+), 8 deletions(-) > > diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c > b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c > index 947f9f6e05d2..ee6688e9b361 100644 > --- a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c > +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c > @@ -418,14 +418,36 @@ static SUNXI_CCU_PHASE(mmc1_sample_clk, "mmc1-sample", > "mmc1", > static SUNXI_CCU_PHASE(mmc1_output_clk, "mmc1-output", "mmc1", > 0x08c, 8, 3, 0); > > -/* TODO Support MMC2 clock's new timing mode. */ > -static SUNXI_CCU_MP_WITH_MUX_GATE(mmc2_clk, "mmc2", mod0_default_parents, > - 0x090, > - 0, 4, /* M */ > - 16, 2,/* P */ > - 24, 2,/* mux */ > - BIT(31), /* gate */ > - 0); > +/* > + * MMC2 supports both old and new timing modes. When the new timing > + * mode is active, the output clock rate is halved by two. Here we > + * treat it as a variable pre-divider. Note that the pre-divider is > + * _not_ included in the possible factors during a set clock rate > + * operation. It is only read out. > + */ > +static const struct ccu_mux_var_prediv mmc2_new_timing_predivs[] = { > + { .index = 0, .shift = 30, .width = 1 }, > + { .index = 1, .shift = 30, .width = 1 }, > +}; > +static struct ccu_mp mmc2_clk = { > + .enable = BIT(31), > + .m = _SUNXI_CCU_DIV(0, 4), > + .p = _SUNXI_CCU_DIV(16, 2), > + .mux= { > + .shift = 24, > + .width = 2, > + .var_predivs= mmc2_new_timing_predivs, > + .n_var_predivs = ARRAY_SIZE(mmc2_new_timing_predivs), > + }, > + .common = { > + .reg= 0x090, > + .features = CCU_FEATURE_MMC_TIMING_SWITCH, > + .hw.init= CLK_HW_INIT_PARENTS("mmc2", > + mod0_default_parents, > + _mp_ops, > + CLK_GET_RATE_NOCACHE), > + }, > +}; Treating the new bit seems a bit of a hack to me. It only works because we're not evaluating the various pre-dividers during a determine_rate (and set_rate), but it might change in the future, and we will break all our eMMC controllers then. Since they're quite special, I was thinking about creating a new MMC clock type? We're going to use it on a number of SoCs, and we'll be able to model it properly, without crippling the regular and generic MP clocks. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCHv2 0/6] Motorola Droid 4 Audio Support
* Sebastian Reichel[170712 08:19]: > * Switch from simple-audio-card to audio-graph-card Gave this a quick try against v4.13-rc1 with SND_AUDIO_GRAPH_CARD enabled as a loadable module. However loading it oopses for me, see below. Maybe some dependencies are missing? Regards, Tony 8< BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747 in_atomic(): 1, irqs_disabled(): 128, pid: 1590, name: modprobe INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [< (null)>] (null) hardirqs last disabled at (0): [] copy_process.part.5+0x2c4/0x1ac8 softirqs last enabled at (0): [] copy_process.part.5+0x2c4/0x1ac8 softirqs last disabled at (0): [< (null)>] (null) CPU: 0 PID: 1590 Comm: modprobe Tainted: GW 4.13.0-rc1+ #126 Hardware name: Generic OMAP4 (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0xac/0xe0) [] (dump_stack) from [] (___might_sleep+0x228/0x2ac) [] (___might_sleep) from [] (__mutex_lock+0x28/0x9fc) [] (__mutex_lock) from [] (mutex_lock_nested+0x1c/0x24) [] (mutex_lock_nested) from [] (kernfs_remove+0x18/0x30) [] (kernfs_remove) from [] (kobject_del+0x14/0x44) [] (kobject_del) from [] (kobject_put+0x114/0x224) [] (kobject_put) from [] (of_get_next_parent+0x2c/0x4c) [] (of_get_next_parent) from [] (of_graph_get_port_parent+0x10/0x70) [] (of_graph_get_port_parent) from [] (asoc_simple_card_parse_graph_dai+0x98/0xe0 [snd_soc_simple_card_utils]) [] (asoc_simple_card_parse_graph_dai [snd_soc_simple_card_utils]) from [] (asoc_graph_card_probe+0x200/0x444 [snd_soc_audio_graph_card]) [] (asoc_graph_card_probe [snd_soc_audio_graph_card]) from [] (platform_drv_probe+0x50/0xb0) [] (platform_drv_probe) from [] (driver_probe_device+0x33c/0x478) [] (driver_probe_device) from [] (__driver_attach+0xe8/0x110) [] (__driver_attach) from [] (bus_for_each_dev+0x6c/0xa0) [] (bus_for_each_dev) from [] (bus_add_driver+0x198/0x270) [] (bus_add_driver) from [] (driver_register+0x78/0xf4) [] (driver_register) from [] (do_one_initcall+0x3c/0x170) [] (do_one_initcall) from [] (do_init_module+0x5c/0x1e0) [] (do_init_module) from [] (load_module+0x1270/0x14ec) [] (load_module) from [] (SyS_finit_module+0xa8/0xec) [] (SyS_finit_module) from [] (ret_fast_syscall+0x0/0x1c) OF: ERROR: Bad of_node_put() on /ocp/spi@48098000/pmic@0/audio-codec/port@0/endpoint
Re: [PATCH] PCI: dwc: designware: test PCIE_ATU_ENABLE bit to check enabled or not
Hi, Às 11:35 AM de 7/13/2017, Jisheng Zhang escreveu: > The ATU CTRL2 register is 32 bit, besides the enable bit, other bits > may also be set. To check whether the ATU is enabled or not, we should > test the enable it. > > Signed-off-by: Jisheng Zhang> --- > drivers/pci/dwc/pcie-designware.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/pci/dwc/pcie-designware.c > b/drivers/pci/dwc/pcie-designware.c > index 0e03af279259..6bf0b409050a 100644 > --- a/drivers/pci/dwc/pcie-designware.c > +++ b/drivers/pci/dwc/pcie-designware.c > @@ -177,7 +177,7 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int > index, int type, >*/ > for (retries = 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++) { > val = dw_pcie_readl_dbi(pci, PCIE_ATU_CR2); > - if (val == PCIE_ATU_ENABLE) > + if (val & PCIE_ATU_ENABLE) > return; > > usleep_range(LINK_WAIT_IATU_MIN, LINK_WAIT_IATU_MAX); > Make sense, turn it more accurate. Thanks! Acked-by: Joao Pinto
Re: [PATCH] printk: modify console_unlock with printk-safe macros
On (07/15/17 18:36), Pierre Kuo wrote: [..] > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > index fc47863..21557cc 100644 > --- a/kernel/printk/printk.c > +++ b/kernel/printk/printk.c > @@ -2194,8 +2194,7 @@ void console_unlock(void) > size_t ext_len = 0; > size_t len; > > - printk_safe_enter_irqsave(flags); > - raw_spin_lock(_lock); > + logbuf_lock_irqsave(flags); > if (seen_seq != log_next_seq) { > wake_klogd = true; > seen_seq = log_next_seq; > @@ -2267,8 +2266,7 @@ void console_unlock(void) >*/ > raw_spin_lock(_lock); > retry = console_seq != log_next_seq; > - raw_spin_unlock(_lock); > - printk_safe_exit_irqrestore(flags); > + logbuf_unlock_irqrestore(flags); > > if (retry && console_trylock()) > goto again; I did it that particular way for a reason - console_unlock() does a bunch of tricks: unlocking logbuf in the middle of printing loop, breaking out of loop with local IRQs disabled, re-taking the logbuf after the loop still will local IRQs disabled, etc. etc. I didn't want to (and still don't) mix-in logbuf macros; we do things that macros don't cover anyway. sorry, I don't agree that the patch improves readability. -ss
Re: [PATCH 3/5] sphinx-pre-install: use a requirements file
Em Mon, 17 Jul 2017 08:00:07 +0200 Markus Heiserescreveu: > > Am 17.07.2017 um 00:08 schrieb Mauro Carvalho Chehab > > : > > > > Instead of using 3 commands to install a virtualenv, use > > a single one, reading the requirements from this file: > > > > Documentation/sphinx/requirements.txt > > > > Signed-off-by: Mauro Carvalho Chehab > > Hi Mauro, > > I get a .. > > fatal: sha1 information is lacking or useless > (Documentation/doc-guide/sphinx.rst) > > and I miss the Documentation/doc-guide/sphinx.rst file in this patch. > > Did it only happened to me? Sorry, I forgot to mention. This patch depends on the patch series I posted before adding information about the Sphinx install procedures: [PATCH v2 0/6] Better document Sphinx install instructions https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1444295.html Thanks, Mauro
[PATCH] x86/microcode: Document the three loading methods
From: Borislav PetkovPaul Menzel asked recently how to load microcode on a system and I realized that we don't really have all the methods written down somewhere. Do that, so people can go and look them up. Signed-off-by: Borislav Petkov --- Documentation/x86/early-microcode.txt | 70 -- Documentation/x86/microcode.txt | 133 ++ 2 files changed, 133 insertions(+), 70 deletions(-) delete mode 100644 Documentation/x86/early-microcode.txt create mode 100644 Documentation/x86/microcode.txt diff --git a/Documentation/x86/early-microcode.txt b/Documentation/x86/early-microcode.txt deleted file mode 100644 index 07749e7f3d50.. --- a/Documentation/x86/early-microcode.txt +++ /dev/null @@ -1,70 +0,0 @@ -Early load microcode - -By Fenghua Yu - -Kernel can update microcode in early phase of boot time. Loading microcode early -can fix CPU issues before they are observed during kernel boot time. - -Microcode is stored in an initrd file. The microcode is read from the initrd -file and loaded to CPUs during boot time. - -The format of the combined initrd image is microcode in cpio format followed by -the initrd image (maybe compressed). Kernel parses the combined initrd image -during boot time. The microcode file in cpio name space is: -on Intel: kernel/x86/microcode/GenuineIntel.bin -on AMD : kernel/x86/microcode/AuthenticAMD.bin - -During BSP boot (before SMP starts), if the kernel finds the microcode file in -the initrd file, it parses the microcode and saves matching microcode in memory. -If matching microcode is found, it will be uploaded in BSP and later on in all -APs. - -The cached microcode patch is applied when CPUs resume from a sleep state. - -There are two legacy user space interfaces to load microcode, either through -/dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file -in sysfs. - -In addition to these two legacy methods, the early loading method described -here is the third method with which microcode can be uploaded to a system's -CPUs. - -The following example script shows how to generate a new combined initrd file in -/boot/initrd-3.5.0.ucode.img with original microcode microcode.bin and -original initrd image /boot/initrd-3.5.0.img. - -mkdir initrd -cd initrd -mkdir -p kernel/x86/microcode -cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin (or AuthenticAMD.bin) -find . | cpio -o -H newc >../ucode.cpio -cd .. -cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img - -Builtin microcode -= - -We can also load builtin microcode supplied through the regular firmware -builtin method CONFIG_FIRMWARE_IN_KERNEL. Only 64-bit is currently -supported. - -Here's an example: - -CONFIG_FIRMWARE_IN_KERNEL=y -CONFIG_EXTRA_FIRMWARE="intel-ucode/06-3a-09 amd-ucode/microcode_amd_fam15h.bin" -CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" - -This basically means, you have the following tree structure locally: - -/lib/firmware/ -|-- amd-ucode -... -| |-- microcode_amd_fam15h.bin -... -|-- intel-ucode -... -| |-- 06-3a-09 -... - -so that the build system can find those files and integrate them into -the final kernel image. The early loader finds them and applies them. diff --git a/Documentation/x86/microcode.txt b/Documentation/x86/microcode.txt new file mode 100644 index ..6ab130c6ca45 --- /dev/null +++ b/Documentation/x86/microcode.txt @@ -0,0 +1,133 @@ + The Linux Microcode Loader + +Authors: Fenghua Yu +Borislav Petkov + +The kernel has a x86 microcode loading facility which is supposed to +provide microcode loading methods in the OS. Potential use cases are +updating the microcode on platforms beyond the OEM EOL support, and +updating the microcode on long-running systems without rebooting. + +The loader supports three loading methods: + +1. Early load microcode +=== + +The kernel can update microcode very early during boot. Loading +microcode early can fix CPU issues before they are observed during +kernel boot time. + +The microcode is stored in an initrd file. During boot, it is read from +it and loaded into the CPU cores. + +The format of the combined initrd image is microcode in cpio format +followed by the initrd image (possibly compressed). The loader parses +the combined initrd image during boot. + +The microcode files in cpio name space are: + +on Intel: kernel/x86/microcode/GenuineIntel.bin +on AMD : kernel/x86/microcode/AuthenticAMD.bin + +During BSP (BootStrapping Processor) boot (pre-SMP), the kernel +scans the microcode file in the initrd. If microcode matching the +CPU is found, it will be applied in the BSP and later on in all APs +(Application Processors). + +The loader also saves the matching microcode for the CPU in memory. +Thus, the cached microcode patch is applied when CPUs resume
Re: Droid 4 boot failure due to 422580c3cea7 (mm/oom_kill.c: add tracepoints for oom reaper-related events)
Hi, On Sun, Jul 16, 2017 at 10:59:42PM -0700, Tony Lindgren wrote: > * Roman Gushchin[170716 05:55]: > > On Fri, Jul 14, 2017 at 07:23:43PM +0200, Sebastian Reichel wrote: > > > On Fri, Jul 14, 2017 at 02:12:21PM +, Roman Gushchin wrote: > > > > > On 14 Jul 2017, at 14:43, Sebastian Reichel > > > > > wrote: > > > > > I just bisected another issue breaking boot on Droid 4. My > > > > > bisect points to 422580c3cea7 (mm/oom_kill.c: add tracepoints > > > > > for oom reaper-related events). It do not see any message > > > > > printed to UART (with earlyprintk) once that commit is part > > > > > of my image. Kernel config is below. > > > > > > > This is really interesting, because this patch adds few > > > > tracepoints and all of them are called from the oom code, which is > > > > hopefully not a part of the boot process. > > > > > > > > Can you, please, confirm, that it can be reproduced with some > > > > confidence? If so, can you, please, eliminate the tracepoints > > > > calls and try to reproduce the boot failure? > > > > > > I can boot 9967468c0a10 ("Merge branch 'akpm' (patches from > > > Andrew)") after adding > > > > > > - http://git.kernel.org/tip/19d39a3810e7032f311ef83effdac40339b9d022 > > >(another issue, that breaks Droid 4 boot) > > > - a git revert of 422580c3cea7 > > > > > > OTOH there are strange problems. Using da16dd9785f8 + above > > > two commits also works. Using b5e16170f59b + above commits > > > does not work and bisection ended up in the merge commit. > > > > Hi, Sebastian! > > > > As commit 422580c3cea7 hasn't added any code, which is executed > > during the boot process, I could imagine only two options: > > 1) Added code/data occasionally broke some alignment/size contraints. > > 2) There is another instable bug, which compromised bisect results. > > > > Unfortunately, I can't help you with reproducing, because I haven't > > necessary hardware. > > > > Can you, please, try some older known to be good revision with > > the 422580c3cea7 patch applied? > > Sebastian, for me droid 4 boots just fine with v4.13-rc1 + > 19d39a3810e if that helps. So that's with commit 422580c3cea7. v4.13-rc1 + 19d39a3810e was also broken for me. I just disabled some unused bits in my .config and now the kernel boots with (with 422580c3cea7 that is). Maybe I hit some maximum image size limit for Droid 4? Anyways it looks like 422580c3cea7 is not the actual problem and merely reveals some other problem. -- Sebastian signature.asc Description: PGP signature
Re: [PATCH v1 1/2] ACPI / boot: Correct address space of __acpi_map_table()
On 2017/7/8 23:50, Andy Shevchenko wrote: > Sparse complains about wrong address space used in __acpi_map_table() > and in __acpi_unmap_table(). > > arch/x86/kernel/acpi/boot.c:127:29: warning: incorrect type in return > expression (different address spaces) > arch/x86/kernel/acpi/boot.c:127:29:expected char * > arch/x86/kernel/acpi/boot.c:127:29:got void [noderef] * > arch/x86/kernel/acpi/boot.c:135:23: warning: incorrect type in argument 1 > (different address spaces) > arch/x86/kernel/acpi/boot.c:135:23:expected void [noderef] *addr > arch/x86/kernel/acpi/boot.c:135:23:got char *map > > Correct address space to be in align of type of returned and passed > parameter. > > Signed-off-by: Andy Shevchenko> --- > arch/x86/kernel/acpi/boot.c | 4 ++-- > include/linux/acpi.h| 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c > index 6d534af94761..ac9bb564f004 100644 > --- a/arch/x86/kernel/acpi/boot.c > +++ b/arch/x86/kernel/acpi/boot.c > @@ -118,7 +118,7 @@ static u32 isa_irq_to_gsi[NR_IRQS_LEGACY] __read_mostly = > { > * This is just a simple wrapper around early_ioremap(), > * with sanity checks for phys == 0 and size == 0. > */ > -char *__init __acpi_map_table(unsigned long phys, unsigned long size) > +void __init __iomem *__acpi_map_table(unsigned long phys, unsigned long size) > { > > if (!phys || !size) > @@ -127,7 +127,7 @@ char *__init __acpi_map_table(unsigned long phys, > unsigned long size) > return early_ioremap(phys, size); > } > > -void __init __acpi_unmap_table(char *map, unsigned long size) > +void __init __acpi_unmap_table(void __iomem *map, unsigned long size) > { > if (!map || !size) > return; > diff --git a/include/linux/acpi.h b/include/linux/acpi.h > index 99f96df83dd8..17cb57a533bb 100644 > --- a/include/linux/acpi.h > +++ b/include/linux/acpi.h > @@ -224,8 +224,8 @@ struct acpi_subtable_proc { > int count; > }; > > -char * __acpi_map_table (unsigned long phys_addr, unsigned long size); > -void __acpi_unmap_table(char *map, unsigned long size); > +void __iomem *__acpi_map_table(unsigned long phys_addr, unsigned long size); > +void __acpi_unmap_table(void __iomem *map, unsigned long size); This breaks ACPI compile on ARM64 as ARM64 has its definition for those two functions, I see patches in linux-next already, should I add a patch on top to fix it, or this patch should be respined? Thanks Hanjun
[PATCH v2 2/5] ACPI / boot: Correct address space of __acpi_map_table()
Sparse complains about wrong address space used in __acpi_map_table() and in __acpi_unmap_table(). arch/x86/kernel/acpi/boot.c:127:29: warning: incorrect type in return expression (different address spaces) arch/x86/kernel/acpi/boot.c:127:29:expected char * arch/x86/kernel/acpi/boot.c:127:29:got void [noderef] * arch/x86/kernel/acpi/boot.c:135:23: warning: incorrect type in argument 1 (different address spaces) arch/x86/kernel/acpi/boot.c:135:23:expected void [noderef] *addr arch/x86/kernel/acpi/boot.c:135:23:got char *map Correct address space to be in align of type of returned and passed parameter. Signed-off-by: Andy Shevchenko--- arch/arm64/kernel/acpi.c| 4 ++-- arch/ia64/kernel/acpi.c | 4 ++-- arch/x86/kernel/acpi/boot.c | 4 ++-- include/linux/acpi.h| 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c index e25c11e727fe..b3162715ed78 100644 --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@ -95,7 +95,7 @@ static int __init dt_scan_depth1_nodes(unsigned long node, * __acpi_map_table() will be called before page_init(), so early_ioremap() * or early_memremap() should be called here to for ACPI table mapping. */ -char *__init __acpi_map_table(unsigned long phys, unsigned long size) +void __init __iomem *__acpi_map_table(unsigned long phys, unsigned long size) { if (!size) return NULL; @@ -103,7 +103,7 @@ char *__init __acpi_map_table(unsigned long phys, unsigned long size) return early_memremap(phys, size); } -void __init __acpi_unmap_table(char *map, unsigned long size) +void __init __acpi_unmap_table(void __iomem *map, unsigned long size) { if (!map || !size) return; diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c index 7508c306aa9e..b9388cc283bc 100644 --- a/arch/ia64/kernel/acpi.c +++ b/arch/ia64/kernel/acpi.c @@ -159,12 +159,12 @@ int acpi_request_vector(u32 int_type) return vector; } -char *__init __acpi_map_table(unsigned long phys_addr, unsigned long size) +void __init __iomem *__acpi_map_table(unsigned long phys, unsigned long size) { return __va(phys_addr); } -void __init __acpi_unmap_table(char *map, unsigned long size) +void __init __acpi_unmap_table(void __iomem *map, unsigned long size) { } diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 09ddb3cd627a..6d5b1346268a 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -118,7 +118,7 @@ static u32 isa_irq_to_gsi[NR_IRQS_LEGACY] __read_mostly = { * This is just a simple wrapper around early_ioremap(), * with sanity checks for phys == 0 and size == 0. */ -char *__init __acpi_map_table(unsigned long phys, unsigned long size) +void __init __iomem *__acpi_map_table(unsigned long phys, unsigned long size) { if (!phys || !size) @@ -127,7 +127,7 @@ char *__init __acpi_map_table(unsigned long phys, unsigned long size) return early_ioremap(phys, size); } -void __init __acpi_unmap_table(char *map, unsigned long size) +void __init __acpi_unmap_table(void __iomem *map, unsigned long size) { if (!map || !size) return; diff --git a/include/linux/acpi.h b/include/linux/acpi.h index c749eef1daa1..3848b56fcd83 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -228,8 +228,8 @@ struct acpi_subtable_proc { int count; }; -char * __acpi_map_table (unsigned long phys_addr, unsigned long size); -void __acpi_unmap_table(char *map, unsigned long size); +void __iomem *__acpi_map_table(unsigned long phys_addr, unsigned long size); +void __acpi_unmap_table(void __iomem *map, unsigned long size); int early_acpi_boot_init(void); int acpi_boot_init (void); void acpi_boot_table_init (void); -- 2.11.0
[PATCH v2 5/5] ACPI / boot: Don't handle SCI on HW reduced platforms
WIP Signed-off-by: Andy Shevchenko--- arch/x86/kernel/acpi/boot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 71c0feae60a4..4413cc2f7c3c 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -1184,7 +1184,7 @@ static int __init acpi_parse_madt_ioapic_entries(void) * If BIOS did not supply an INT_SRC_OVR for the SCI * pretend we got one so we can set the SCI flags. */ - if (!acpi_sci_override_gsi) + if (!acpi_sci_override_gsi && !acpi_gbl_reduced_hardware) acpi_sci_ioapic_setup(acpi_gbl_FADT.sci_interrupt, 0, 0, acpi_gbl_FADT.sci_interrupt); -- 2.11.0
[PATCH v2 1/5] ACPI / boot: Don't define unused variables
Some code in acpi_parse_x2apic() conditionally compiled, though parts of it are being used in any case. This annoys gcc. arch/x86/kernel/acpi/boot.c: In function ‘acpi_parse_x2apic’: arch/x86/kernel/acpi/boot.c:203:5: warning: variable ‘enabled’ set but not used [-Wunused-but-set-variable] u8 enabled; ^~~ arch/x86/kernel/acpi/boot.c:202:6: warning: variable ‘apic_id’ set but not used [-Wunused-but-set-variable] int apic_id; ^~~ Re-arrange the code to avoid compiling unused variables. Signed-off-by: Andy Shevchenko--- arch/x86/kernel/acpi/boot.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 6bb680671088..09ddb3cd627a 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -199,8 +199,10 @@ static int __init acpi_parse_x2apic(struct acpi_subtable_header *header, const unsigned long end) { struct acpi_madt_local_x2apic *processor = NULL; +#ifdef CONFIG_X86_X2APIC int apic_id; u8 enabled; +#endif processor = (struct acpi_madt_local_x2apic *)header; @@ -209,9 +211,10 @@ acpi_parse_x2apic(struct acpi_subtable_header *header, const unsigned long end) acpi_table_print_madt_entry(header); +#ifdef CONFIG_X86_X2APIC apic_id = processor->local_apic_id; enabled = processor->lapic_flags & ACPI_MADT_ENABLED; -#ifdef CONFIG_X86_X2APIC + /* * We need to register disabled CPU as well to permit * counting disabled CPUs. This allows us to size -- 2.11.0
[PATCH v2 0/5] ACPI / boot: Few amendments
This series does few amendments to architectural ACPI code related to boot, in particularly to arch/x86/kernel/acpi/boot.c. First two patches are amendments to satisfy compiler and static analyzer (the order is changed from first version which had been applied; in case of partial update first patch is already in tree). Third patch might be useful on platforms when debugging *PIC related code path to see how many legacy IRQs are registered. Fourth and fifth patches are preparation for some interesting implementation of ACPI HW reduced platforms (note, this does not mean it's against specification, patch 5 actually about following specification). Fifth patch might be subject to additional discussions. In v2: - fix function declarations in ia64 and arm64 as well (Hanjun) - add three more patches Andy Shevchenko (5): ACPI / boot: Don't define unused variables ACPI / boot: Correct address space of __acpi_map_table() ACPI / boot: Add number of legacy IRQs to debug output ACPI / boot: Not all platform require acpi_reduced_hw_init() ACPI / boot: Don't handle SCI on HW reduced platforms arch/arm64/kernel/acpi.c| 4 ++-- arch/ia64/kernel/acpi.c | 4 ++-- arch/x86/kernel/acpi/boot.c | 15 +-- include/linux/acpi.h| 7 +-- 4 files changed, 18 insertions(+), 12 deletions(-) -- 2.11.0
[PATCH v2 4/5] ACPI / boot: Not all platform require acpi_reduced_hw_init()
Some platform might take care of legacy devices on theirs own. Let's allow them to do that by exporting a weak function. Signed-off-by: Andy Shevchenko--- arch/x86/kernel/acpi/boot.c | 2 +- include/linux/acpi.h| 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 0186d3bae610..71c0feae60a4 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -1348,7 +1348,7 @@ static int __init dmi_ignore_irq0_timer_override(const struct dmi_system_id *d) * * We initialize the Hardware-reduced ACPI model here: */ -static void __init acpi_reduced_hw_init(void) +void __init __weak acpi_reduced_hw_init(void) { if (acpi_gbl_reduced_hardware) { /* diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 3848b56fcd83..3ef30a7b5444 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -230,6 +230,8 @@ struct acpi_subtable_proc { void __iomem *__acpi_map_table(unsigned long phys_addr, unsigned long size); void __acpi_unmap_table(void __iomem *map, unsigned long size); + +void acpi_reduced_hw_init(void); int early_acpi_boot_init(void); int acpi_boot_init (void); void acpi_boot_table_init (void); @@ -682,6 +684,7 @@ static inline struct device *acpi_get_first_physical_node(struct acpi_device *ad static inline void acpi_early_init(void) { } static inline void acpi_subsystem_init(void) { } +static inline void acpi_reduced_hw_init(void) { } static inline int early_acpi_boot_init(void) { return 0; -- 2.11.0
[PATCH v2 3/5] ACPI / boot: Add number of legacy IRQs to debug output
Sometimes it's useful to have when mp_config_acpi_legacy_irqs() is called. Signed-off-by: Andy Shevchenko--- arch/x86/kernel/acpi/boot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 6d5b1346268a..0186d3bae610 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -1078,7 +1078,7 @@ static void __init mp_config_acpi_legacy_irqs(void) mp_bus_id_to_type[MP_ISA_BUS] = MP_BUS_ISA; #endif set_bit(MP_ISA_BUS, mp_bus_not_pci); - pr_debug("Bus #%d is ISA\n", MP_ISA_BUS); + pr_debug("Bus #%d is ISA (nIRQs: %d)\n", MP_ISA_BUS, nr_legacy_irqs()); /* * Use the default configuration for the IRQs 0-15. Unless -- 2.11.0
[PATCH] perf probe: Fix build failure for get_target_map()
Commit 801bc8193463 ("perf probe: Allow placing uprobes in alternate namespaces.") is causing a build failure on powerpc: error: incompatible type for argument 2 of 'get_target_map' map = get_target_map(pev->target, pev->uprobes); ^~~ Fix it by changing parameters of get_target_map(). Fixes: 801bc8193463 ("perf probe: Allow placing uprobes in alternate namespaces.") Signed-off-by: Ravi Bangoria--- tools/perf/arch/powerpc/util/sym-handling.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/arch/powerpc/util/sym-handling.c b/tools/perf/arch/powerpc/util/sym-handling.c index bf9a259..9c4e23d 100644 --- a/tools/perf/arch/powerpc/util/sym-handling.c +++ b/tools/perf/arch/powerpc/util/sym-handling.c @@ -126,7 +126,7 @@ void arch__post_process_probe_trace_events(struct perf_probe_event *pev, struct rb_node *tmp; int i = 0; - map = get_target_map(pev->target, pev->uprobes); + map = get_target_map(pev->target, pev->nsi, pev->uprobes); if (!map || map__load(map) < 0) return; -- 2.1.4
[PATCH v3 08/23] media: camss: Add CSID files
These files control the CSID modules which handle the protocol and application layer of the CSI2 receivers. Signed-off-by: Todor Tomov--- .../media/platform/qcom/camss-8x16/camss-csid.c| 1073 .../media/platform/qcom/camss-8x16/camss-csid.h| 82 ++ 2 files changed, 1155 insertions(+) create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-csid.c create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-csid.h diff --git a/drivers/media/platform/qcom/camss-8x16/camss-csid.c b/drivers/media/platform/qcom/camss-8x16/camss-csid.c new file mode 100644 index 000..2bf3415 --- /dev/null +++ b/drivers/media/platform/qcom/camss-8x16/camss-csid.c @@ -0,0 +1,1073 @@ +/* + * camss-csid.c + * + * Qualcomm MSM Camera Subsystem - CSID Module + * + * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved. + * Copyright (C) 2015-2017 Linaro Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * 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 +#include +#include +#include +#include +#include +#include +#include +#include + +#include "camss-csid.h" +#include "camss.h" + +#define MSM_CSID_NAME "msm_csid" + +#define CAMSS_CSID_HW_VERSION 0x0 +#define CAMSS_CSID_CORE_CTRL_0 0x004 +#define CAMSS_CSID_CORE_CTRL_1 0x008 +#define CAMSS_CSID_RST_CMD 0x00c +#define CAMSS_CSID_CID_LUT_VC_n(n) (0x010 + 0x4 * (n)) +#define CAMSS_CSID_CID_n_CFG(n)(0x020 + 0x4 * (n)) +#define CAMSS_CSID_IRQ_CLEAR_CMD 0x060 +#define CAMSS_CSID_IRQ_MASK0x064 +#define CAMSS_CSID_IRQ_STATUS 0x068 +#define CAMSS_CSID_TG_CTRL 0x0a0 +#define CAMSS_CSID_TG_VC_CFG 0x0a4 +#define CAMSS_CSID_TG_VC_CFG_H_BLANKING0x3ff +#define CAMSS_CSID_TG_VC_CFG_V_BLANKING0x7f +#define CAMSS_CSID_TG_DT_n_CGG_0(n)(0x0ac + 0xc * (n)) +#define CAMSS_CSID_TG_DT_n_CGG_1(n)(0x0b0 + 0xc * (n)) +#define CAMSS_CSID_TG_DT_n_CGG_2(n)(0x0b4 + 0xc * (n)) + +#define DATA_TYPE_EMBEDDED_DATA_8BIT 0x12 +#define DATA_TYPE_YUV422_8BIT 0x1e +#define DATA_TYPE_RAW_6BIT 0x28 +#define DATA_TYPE_RAW_8BIT 0x2a +#define DATA_TYPE_RAW_10BIT0x2b +#define DATA_TYPE_RAW_12BIT0x2c + +#define DECODE_FORMAT_UNCOMPRESSED_6_BIT 0x0 +#define DECODE_FORMAT_UNCOMPRESSED_8_BIT 0x1 +#define DECODE_FORMAT_UNCOMPRESSED_10_BIT 0x2 +#define DECODE_FORMAT_UNCOMPRESSED_12_BIT 0x3 + +#define CSID_RESET_TIMEOUT_MS 500 + +static const struct { + u32 code; + u32 uncompressed; + u8 data_type; + u8 decode_format; + u8 uncompr_bpp; +} csid_input_fmts[] = { + { + MEDIA_BUS_FMT_UYVY8_2X8, + MEDIA_BUS_FMT_UYVY8_2X8, + DATA_TYPE_YUV422_8BIT, + DECODE_FORMAT_UNCOMPRESSED_8_BIT, + 16 + }, + { + MEDIA_BUS_FMT_VYUY8_2X8, + MEDIA_BUS_FMT_VYUY8_2X8, + DATA_TYPE_YUV422_8BIT, + DECODE_FORMAT_UNCOMPRESSED_8_BIT, + 16 + }, + { + MEDIA_BUS_FMT_YUYV8_2X8, + MEDIA_BUS_FMT_YUYV8_2X8, + DATA_TYPE_YUV422_8BIT, + DECODE_FORMAT_UNCOMPRESSED_8_BIT, + 16 + }, + { + MEDIA_BUS_FMT_YVYU8_2X8, + MEDIA_BUS_FMT_YVYU8_2X8, + DATA_TYPE_YUV422_8BIT, + DECODE_FORMAT_UNCOMPRESSED_8_BIT, + 16 + }, + { + MEDIA_BUS_FMT_SBGGR8_1X8, + MEDIA_BUS_FMT_SBGGR8_1X8, + DATA_TYPE_RAW_8BIT, + DECODE_FORMAT_UNCOMPRESSED_8_BIT, + 8 + }, + { + MEDIA_BUS_FMT_SGBRG8_1X8, + MEDIA_BUS_FMT_SGBRG8_1X8, + DATA_TYPE_RAW_8BIT, + DECODE_FORMAT_UNCOMPRESSED_8_BIT, + 8 + }, + { + MEDIA_BUS_FMT_SGRBG8_1X8, + MEDIA_BUS_FMT_SGRBG8_1X8, + DATA_TYPE_RAW_8BIT, + DECODE_FORMAT_UNCOMPRESSED_8_BIT, + 8 + }, + { + MEDIA_BUS_FMT_SRGGB8_1X8, + MEDIA_BUS_FMT_SRGGB8_1X8, + DATA_TYPE_RAW_8BIT, + DECODE_FORMAT_UNCOMPRESSED_8_BIT, + 8 + }, + { + MEDIA_BUS_FMT_SBGGR10_1X10, + MEDIA_BUS_FMT_SBGGR10_1X10, + DATA_TYPE_RAW_10BIT, + DECODE_FORMAT_UNCOMPRESSED_10_BIT, +
[PATCH v3 09/23] media: camss: Add ISPIF files
These files control the ISPIF module which handles the routing of the data streams from the CSIDs to the inputs of the VFE. Signed-off-by: Todor Tomov--- .../media/platform/qcom/camss-8x16/camss-ispif.c | 1127 .../media/platform/qcom/camss-8x16/camss-ispif.h | 85 ++ 2 files changed, 1212 insertions(+) create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-ispif.c create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-ispif.h diff --git a/drivers/media/platform/qcom/camss-8x16/camss-ispif.c b/drivers/media/platform/qcom/camss-8x16/camss-ispif.c new file mode 100644 index 000..cc32085 --- /dev/null +++ b/drivers/media/platform/qcom/camss-8x16/camss-ispif.c @@ -0,0 +1,1127 @@ +/* + * camss-ispif.c + * + * Qualcomm MSM Camera Subsystem - ISPIF Module + * + * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved. + * Copyright (C) 2015-2017 Linaro Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * 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 +#include +#include +#include +#include +#include +#include +#include +#include + +#include "camss-ispif.h" +#include "camss.h" + +#define MSM_ISPIF_NAME "msm_ispif" + +#define ispif_line_array(ptr_line) \ + ((const struct ispif_line (*)[]) &(ptr_line[-(ptr_line->id)])) + +#define to_ispif(ptr_line) \ + container_of(ispif_line_array(ptr_line), struct ispif_device, ptr_line) + +#define ISPIF_RST_CMD_00x008 +#define ISPIF_IRQ_GLOBAL_CLEAR_CMD 0x01c +#define ISPIF_VFE_m_CTRL_0(m) (0x200 + 0x200 * (m)) +#define ISPIF_VFE_m_CTRL_0_PIX0_LINE_BUF_EN(1 << 6) +#define ISPIF_VFE_m_IRQ_MASK_0(m) (0x208 + 0x200 * (m)) +#define ISPIF_VFE_m_IRQ_MASK_0_PIX0_ENABLE 0x1249 +#define ISPIF_VFE_m_IRQ_MASK_0_PIX0_MASK 0x1fff +#define ISPIF_VFE_m_IRQ_MASK_0_RDI0_ENABLE 0x02492000 +#define ISPIF_VFE_m_IRQ_MASK_0_RDI0_MASK 0x03ffe000 +#define ISPIF_VFE_m_IRQ_MASK_1(m) (0x20c + 0x200 * (m)) +#define ISPIF_VFE_m_IRQ_MASK_1_PIX1_ENABLE 0x1249 +#define ISPIF_VFE_m_IRQ_MASK_1_PIX1_MASK 0x1fff +#define ISPIF_VFE_m_IRQ_MASK_1_RDI1_ENABLE 0x02492000 +#define ISPIF_VFE_m_IRQ_MASK_1_RDI1_MASK 0x03ffe000 +#define ISPIF_VFE_m_IRQ_MASK_2(m) (0x210 + 0x200 * (m)) +#define ISPIF_VFE_m_IRQ_MASK_2_RDI2_ENABLE 0x1249 +#define ISPIF_VFE_m_IRQ_MASK_2_RDI2_MASK 0x1fff +#define ISPIF_VFE_m_IRQ_STATUS_0(m)(0x21c + 0x200 * (m)) +#define ISPIF_VFE_m_IRQ_STATUS_0_PIX0_OVERFLOW (1 << 12) +#define ISPIF_VFE_m_IRQ_STATUS_0_RDI0_OVERFLOW (1 << 25) +#define ISPIF_VFE_m_IRQ_STATUS_1(m)(0x220 + 0x200 * (m)) +#define ISPIF_VFE_m_IRQ_STATUS_1_PIX1_OVERFLOW (1 << 12) +#define ISPIF_VFE_m_IRQ_STATUS_1_RDI1_OVERFLOW (1 << 25) +#define ISPIF_VFE_m_IRQ_STATUS_2(m)(0x224 + 0x200 * (m)) +#define ISPIF_VFE_m_IRQ_STATUS_2_RDI2_OVERFLOW (1 << 12) +#define ISPIF_VFE_m_IRQ_CLEAR_0(m) (0x230 + 0x200 * (m)) +#define ISPIF_VFE_m_IRQ_CLEAR_1(m) (0x234 + 0x200 * (m)) +#define ISPIF_VFE_m_IRQ_CLEAR_2(m) (0x238 + 0x200 * (m)) +#define ISPIF_VFE_m_INTF_INPUT_SEL(m) (0x244 + 0x200 * (m)) +#define ISPIF_VFE_m_INTF_CMD_0(m) (0x248 + 0x200 * (m)) +#define ISPIF_VFE_m_INTF_CMD_1(m) (0x24c + 0x200 * (m)) +#define ISPIF_VFE_m_PIX_INTF_n_CID_MASK(m, n) \ + (0x254 + 0x200 * (m) + 0x4 * (n)) +#define ISPIF_VFE_m_RDI_INTF_n_CID_MASK(m, n) \ + (0x264 + 0x200 * (m) + 0x4 * (n)) +#define ISPIF_VFE_m_PIX_INTF_n_STATUS(m, n)\ + (0x2c0 + 0x200 * (m) + 0x4 * (n)) +#define ISPIF_VFE_m_RDI_INTF_n_STATUS(m, n)\ + (0x2d0 + 0x200 * (m) + 0x4 * (n)) + +#define CSI_PIX_CLK_MUX_SEL0x000 +#define CSI_RDI_CLK_MUX_SEL0x008 + +#define ISPIF_TIMEOUT_SLEEP_US 1000 +#define ISPIF_TIMEOUT_ALL_US 100 +#define ISPIF_RESET_TIMEOUT_MS 500 + +enum ispif_intf_cmd { + CMD_DISABLE_FRAME_BOUNDARY = 0x0, + CMD_ENABLE_FRAME_BOUNDARY = 0x1, + CMD_DISABLE_IMMEDIATELY = 0x2, + CMD_ALL_DISABLE_IMMEDIATELY = 0x, + CMD_ALL_NO_CHANGE = 0x, +}; + +static const u32 ispif_formats[] = { + MEDIA_BUS_FMT_UYVY8_2X8, + MEDIA_BUS_FMT_VYUY8_2X8, + MEDIA_BUS_FMT_YUYV8_2X8, + MEDIA_BUS_FMT_YVYU8_2X8, + MEDIA_BUS_FMT_SBGGR8_1X8, + MEDIA_BUS_FMT_SGBRG8_1X8, + MEDIA_BUS_FMT_SGRBG8_1X8, + MEDIA_BUS_FMT_SRGGB8_1X8, +
[PATCH v3 11/23] media: camss: Add files which handle the video device nodes
These files handle the video device nodes of the camss driver. Signed-off-by: Todor Tomov--- .../media/platform/qcom/camss-8x16/camss-video.c | 627 + .../media/platform/qcom/camss-8x16/camss-video.h | 66 +++ 2 files changed, 693 insertions(+) create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-video.c create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-video.h diff --git a/drivers/media/platform/qcom/camss-8x16/camss-video.c b/drivers/media/platform/qcom/camss-8x16/camss-video.c new file mode 100644 index 000..29483a4 --- /dev/null +++ b/drivers/media/platform/qcom/camss-8x16/camss-video.c @@ -0,0 +1,627 @@ +/* + * camss-video.c + * + * Qualcomm MSM Camera Subsystem - V4L2 device node + * + * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved. + * Copyright (C) 2015-2017 Linaro Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * 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 +#include +#include +#include +#include +#include +#include + +#include "camss-video.h" +#include "camss.h" + +/* + * struct format_info - ISP media bus format information + * @code: V4L2 media bus format code + * @pixelformat: V4L2 pixel format FCC identifier + * @bpp: Bits per pixel when stored in memory + */ +static const struct format_info { + u32 code; + u32 pixelformat; + unsigned int bpp; +} formats[] = { + { MEDIA_BUS_FMT_UYVY8_2X8, V4L2_PIX_FMT_UYVY, 16 }, + { MEDIA_BUS_FMT_VYUY8_2X8, V4L2_PIX_FMT_VYUY, 16 }, + { MEDIA_BUS_FMT_YUYV8_2X8, V4L2_PIX_FMT_YUYV, 16 }, + { MEDIA_BUS_FMT_YVYU8_2X8, V4L2_PIX_FMT_YVYU, 16 }, + { MEDIA_BUS_FMT_SBGGR8_1X8, V4L2_PIX_FMT_SBGGR8, 8 }, + { MEDIA_BUS_FMT_SGBRG8_1X8, V4L2_PIX_FMT_SGBRG8, 8 }, + { MEDIA_BUS_FMT_SGRBG8_1X8, V4L2_PIX_FMT_SGRBG8, 8 }, + { MEDIA_BUS_FMT_SRGGB8_1X8, V4L2_PIX_FMT_SRGGB8, 8 }, + { MEDIA_BUS_FMT_SBGGR10_1X10, V4L2_PIX_FMT_SBGGR10P, 10 }, + { MEDIA_BUS_FMT_SGBRG10_1X10, V4L2_PIX_FMT_SGBRG10P, 10 }, + { MEDIA_BUS_FMT_SGRBG10_1X10, V4L2_PIX_FMT_SGRBG10P, 10 }, + { MEDIA_BUS_FMT_SRGGB10_1X10, V4L2_PIX_FMT_SRGGB10P, 10 }, + { MEDIA_BUS_FMT_SBGGR12_1X12, V4L2_PIX_FMT_SRGGB12P, 12 }, + { MEDIA_BUS_FMT_SGBRG12_1X12, V4L2_PIX_FMT_SGBRG12P, 12 }, + { MEDIA_BUS_FMT_SGRBG12_1X12, V4L2_PIX_FMT_SGRBG12P, 12 }, + { MEDIA_BUS_FMT_SRGGB12_1X12, V4L2_PIX_FMT_SRGGB12P, 12 } +}; + +/* - + * Helper functions + */ + +/* + * video_mbus_to_pix_mp - Convert v4l2_mbus_framefmt to v4l2_pix_format_mplane + * @mbus: v4l2_mbus_framefmt format (input) + * @pix: v4l2_pix_format_mplane format (output) + * + * Fill the output pix structure with information from the input mbus format. + * + * Return 0 on success or a negative error code otherwise + */ +static unsigned int video_mbus_to_pix_mp(const struct v4l2_mbus_framefmt *mbus, +struct v4l2_pix_format_mplane *pix) +{ + unsigned int i; + u32 bytesperline; + + memset(pix, 0, sizeof(*pix)); + v4l2_fill_pix_format_mplane(pix, mbus); + + for (i = 0; i < ARRAY_SIZE(formats); ++i) { + if (formats[i].code == mbus->code) + break; + } + + if (WARN_ON(i == ARRAY_SIZE(formats))) + return -EINVAL; + + pix->pixelformat = formats[i].pixelformat; + pix->num_planes = 1; + bytesperline = pix->width * formats[i].bpp / 8; + bytesperline = ALIGN(bytesperline, 8); + pix->plane_fmt[0].bytesperline = bytesperline; + pix->plane_fmt[0].sizeimage = bytesperline * pix->height; + + return 0; +} + +static struct v4l2_subdev *video_remote_subdev(struct camss_video *video, + u32 *pad) +{ + struct media_pad *remote; + + remote = media_entity_remote_pad(>pad); + + if (!remote || !is_media_entity_v4l2_subdev(remote->entity)) + return NULL; + + if (pad) + *pad = remote->index; + + return media_entity_to_v4l2_subdev(remote->entity); +} + +static int video_get_subdev_format(struct camss_video *video, + struct v4l2_format *format) +{ + struct v4l2_subdev_format fmt; + struct v4l2_subdev *subdev; + u32 pad; + int ret; + + subdev = video_remote_subdev(video, ); + if (subdev == NULL) + return -EINVAL; + + fmt.pad = pad; + fmt.which =
[PATCH v3 10/23] media: camss: Add VFE files
These files control the VFE module. The VFE has different input interfaces. The PIX input interface feeds the input data to an image processing pipeline. Three RDI input interfaces bypass the image processing pipeline. The VFE also contains the AXI bus interface which writes the output data to memory. RDI interfaces are supported in this version. PIX interface is not supported. Signed-off-by: Todor Tomov--- drivers/media/platform/qcom/camss-8x16/camss-vfe.c | 1913 drivers/media/platform/qcom/camss-8x16/camss-vfe.h | 114 ++ 2 files changed, 2027 insertions(+) create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-vfe.c create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-vfe.h diff --git a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c new file mode 100644 index 000..b6dd29b --- /dev/null +++ b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c @@ -0,0 +1,1913 @@ +/* + * camss-vfe.c + * + * Qualcomm MSM Camera Subsystem - VFE Module + * + * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved. + * Copyright (C) 2015-2017 Linaro Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * 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 +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "camss-vfe.h" +#include "camss.h" + +#define MSM_VFE_NAME "msm_vfe" + +#define vfe_line_array(ptr_line) \ + ((const struct vfe_line (*)[]) &(ptr_line[-(ptr_line->id)])) + +#define to_vfe(ptr_line) \ + container_of(vfe_line_array(ptr_line), struct vfe_device, ptr_line) + +#define VFE_0_HW_VERSION 0x000 + +#define VFE_0_GLOBAL_RESET_CMD 0x00c +#define VFE_0_GLOBAL_RESET_CMD_CORE(1 << 0) +#define VFE_0_GLOBAL_RESET_CMD_CAMIF (1 << 1) +#define VFE_0_GLOBAL_RESET_CMD_BUS (1 << 2) +#define VFE_0_GLOBAL_RESET_CMD_BUS_BDG (1 << 3) +#define VFE_0_GLOBAL_RESET_CMD_REGISTER(1 << 4) +#define VFE_0_GLOBAL_RESET_CMD_TIMER (1 << 5) +#define VFE_0_GLOBAL_RESET_CMD_PM (1 << 6) +#define VFE_0_GLOBAL_RESET_CMD_BUS_MISR(1 << 7) +#define VFE_0_GLOBAL_RESET_CMD_TESTGEN (1 << 8) + +#define VFE_0_IRQ_CMD 0x024 +#define VFE_0_IRQ_CMD_GLOBAL_CLEAR (1 << 0) + +#define VFE_0_IRQ_MASK_0 0x028 +#define VFE_0_IRQ_MASK_0_RDIn_REG_UPDATE(n)(1 << ((n) + 5)) +#define VFE_0_IRQ_MASK_0_IMAGE_MASTER_n_PING_PONG(n) (1 << ((n) + 8)) +#define VFE_0_IRQ_MASK_0_RESET_ACK (1 << 31) +#define VFE_0_IRQ_MASK_1 0x02c +#define VFE_0_IRQ_MASK_1_VIOLATION (1 << 7) +#define VFE_0_IRQ_MASK_1_BUS_BDG_HALT_ACK (1 << 8) +#define VFE_0_IRQ_MASK_1_IMAGE_MASTER_n_BUS_OVERFLOW(n)(1 << ((n) + 9)) + +#define VFE_0_IRQ_CLEAR_0 0x030 +#define VFE_0_IRQ_CLEAR_1 0x034 + +#define VFE_0_IRQ_STATUS_0 0x038 +#define VFE_0_IRQ_STATUS_0_RDIn_REG_UPDATE(n) (1 << ((n) + 5)) +#define VFE_0_IRQ_STATUS_0_IMAGE_MASTER_n_PING_PONG(n) (1 << ((n) + 8)) +#define VFE_0_IRQ_STATUS_0_RESET_ACK (1 << 31) +#define VFE_0_IRQ_STATUS_1 0x03c +#define VFE_0_IRQ_STATUS_1_VIOLATION (1 << 7) +#define VFE_0_IRQ_STATUS_1_BUS_BDG_HALT_ACK(1 << 8) + +#define VFE_0_VIOLATION_STATUS 0x48 + +#define VFE_0_BUS_CMD 0x4c +#define VFE_0_BUS_CMD_Mx_RLD_CMD(x)(1 << (x)) + +#define VFE_0_BUS_CFG 0x050 + +#define VFE_0_BUS_XBAR_CFG_x(x)(0x58 + 0x4 * ((x) / 2)) +#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_SHIFT 8 +#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI0 5 +#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI1 6 +#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI2 7 + +#define VFE_0_BUS_IMAGE_MASTER_n_WR_CFG(n) (0x06c + 0x24 * (n)) +#define VFE_0_BUS_IMAGE_MASTER_n_WR_CFG_WR_PATH_SHIFT 0 +#define VFE_0_BUS_IMAGE_MASTER_n_WR_CFG_FRM_BASED_SHIFT1 +#define VFE_0_BUS_IMAGE_MASTER_n_WR_PING_ADDR(n) (0x070 + 0x24 * (n)) +#define VFE_0_BUS_IMAGE_MASTER_n_WR_PONG_ADDR(n) (0x074 + 0x24 * (n)) +#define VFE_0_BUS_IMAGE_MASTER_n_WR_ADDR_CFG(n)(0x078 + 0x24 * (n)) +#define VFE_0_BUS_IMAGE_MASTER_n_WR_ADDR_CFG_FRM_DROP_PER_SHIFT2 +#define VFE_0_BUS_IMAGE_MASTER_n_WR_ADDR_CFG_FRM_DROP_PER_MASK (0x1F << 2) + +#define VFE_0_BUS_IMAGE_MASTER_n_WR_UB_CFG(n) (0x07c +
[PATCH v3 14/23] camss: vfe: Format conversion support using PIX interface
Use VFE PIX input interface and do format conversion in VFE. Supported input format is UYVY (single plane YUV 4:2:2) and its different sample order variations. Supported output formats are: - NV12/NV21 (two plane YUV 4:2:0) - NV16/NV61 (two plane YUV 4:2:2) Signed-off-by: Todor Tomov--- .../media/platform/qcom/camss-8x16/camss-ispif.c | 2 + drivers/media/platform/qcom/camss-8x16/camss-vfe.c | 673 ++--- drivers/media/platform/qcom/camss-8x16/camss-vfe.h | 13 +- .../media/platform/qcom/camss-8x16/camss-video.c | 332 +++--- .../media/platform/qcom/camss-8x16/camss-video.h | 8 +- 5 files changed, 875 insertions(+), 153 deletions(-) diff --git a/drivers/media/platform/qcom/camss-8x16/camss-ispif.c b/drivers/media/platform/qcom/camss-8x16/camss-ispif.c index cc32085..04918c0 100644 --- a/drivers/media/platform/qcom/camss-8x16/camss-ispif.c +++ b/drivers/media/platform/qcom/camss-8x16/camss-ispif.c @@ -969,6 +969,8 @@ static enum ispif_intf ispif_get_intf(enum vfe_line_id line_id) return RDI1; case (VFE_LINE_RDI2): return RDI2; + case (VFE_LINE_PIX): + return PIX0; default: return RDI0; } diff --git a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c index b6dd29b..bef0209 100644 --- a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c +++ b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include #include @@ -52,29 +53,53 @@ #define VFE_0_GLOBAL_RESET_CMD_BUS_MISR(1 << 7) #define VFE_0_GLOBAL_RESET_CMD_TESTGEN (1 << 8) +#define VFE_0_MODULE_CFG 0x018 +#define VFE_0_MODULE_CFG_DEMUX (1 << 2) +#define VFE_0_MODULE_CFG_CHROMA_UPSAMPLE (1 << 3) +#define VFE_0_MODULE_CFG_SCALE_ENC (1 << 23) + +#define VFE_0_CORE_CFG 0x01c +#define VFE_0_CORE_CFG_PIXEL_PATTERN_YCBYCR0x4 +#define VFE_0_CORE_CFG_PIXEL_PATTERN_YCRYCB0x5 +#define VFE_0_CORE_CFG_PIXEL_PATTERN_CBYCRY0x6 +#define VFE_0_CORE_CFG_PIXEL_PATTERN_CRYCBY0x7 + #define VFE_0_IRQ_CMD 0x024 #define VFE_0_IRQ_CMD_GLOBAL_CLEAR (1 << 0) #define VFE_0_IRQ_MASK_0 0x028 +#define VFE_0_IRQ_MASK_0_CAMIF_SOF (1 << 0) +#define VFE_0_IRQ_MASK_0_CAMIF_EOF (1 << 1) #define VFE_0_IRQ_MASK_0_RDIn_REG_UPDATE(n)(1 << ((n) + 5)) +#define VFE_0_IRQ_MASK_0_line_n_REG_UPDATE(n) \ + ((n) == VFE_LINE_PIX ? (1 << 4) : VFE_0_IRQ_MASK_0_RDIn_REG_UPDATE(n)) #define VFE_0_IRQ_MASK_0_IMAGE_MASTER_n_PING_PONG(n) (1 << ((n) + 8)) +#define VFE_0_IRQ_MASK_0_IMAGE_COMPOSITE_DONE_n(n) (1 << ((n) + 25)) #define VFE_0_IRQ_MASK_0_RESET_ACK (1 << 31) #define VFE_0_IRQ_MASK_1 0x02c +#define VFE_0_IRQ_MASK_1_CAMIF_ERROR (1 << 0) #define VFE_0_IRQ_MASK_1_VIOLATION (1 << 7) #define VFE_0_IRQ_MASK_1_BUS_BDG_HALT_ACK (1 << 8) #define VFE_0_IRQ_MASK_1_IMAGE_MASTER_n_BUS_OVERFLOW(n)(1 << ((n) + 9)) +#define VFE_0_IRQ_MASK_1_RDIn_SOF(n) (1 << ((n) + 29)) #define VFE_0_IRQ_CLEAR_0 0x030 #define VFE_0_IRQ_CLEAR_1 0x034 #define VFE_0_IRQ_STATUS_0 0x038 +#define VFE_0_IRQ_STATUS_0_CAMIF_SOF (1 << 0) #define VFE_0_IRQ_STATUS_0_RDIn_REG_UPDATE(n) (1 << ((n) + 5)) +#define VFE_0_IRQ_STATUS_0_line_n_REG_UPDATE(n)\ + ((n) == VFE_LINE_PIX ? (1 << 4) : VFE_0_IRQ_STATUS_0_RDIn_REG_UPDATE(n)) #define VFE_0_IRQ_STATUS_0_IMAGE_MASTER_n_PING_PONG(n) (1 << ((n) + 8)) +#define VFE_0_IRQ_STATUS_0_IMAGE_COMPOSITE_DONE_n(n) (1 << ((n) + 25)) #define VFE_0_IRQ_STATUS_0_RESET_ACK (1 << 31) #define VFE_0_IRQ_STATUS_1 0x03c #define VFE_0_IRQ_STATUS_1_VIOLATION (1 << 7) #define VFE_0_IRQ_STATUS_1_BUS_BDG_HALT_ACK(1 << 8) +#define VFE_0_IRQ_STATUS_1_RDIn_SOF(n) (1 << ((n) + 29)) +#define VFE_0_IRQ_COMPOSITE_MASK_0 0x40 #define VFE_0_VIOLATION_STATUS 0x48 #define VFE_0_BUS_CMD 0x4c @@ -83,7 +108,10 @@ #define VFE_0_BUS_CFG 0x050 #define VFE_0_BUS_XBAR_CFG_x(x)(0x58 + 0x4 * ((x) / 2)) +#define VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_EN (1 << 1) +#define VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_SWAP_INTER_INTRA(0x3 << 4) #define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_SHIFT 8 +#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_LUMA 0 #define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI0 5 #define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI1 6 #define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI2 7 @@ -99,6 +127,8 @@ #define
Re: [PATCHv4 1/4] mfd: da9052: fix manual ADC read after timed out read
On Fri, 30 Jun 2017, Sebastian Reichel wrote: > It is possible that under heavy system load, the counter in the completion > struct, used for waiting for end of AD conversion, gets incremented twice. > To make sure the driver recovers from this situation, the completion struct > should be reinitialized. > > Signed-off-by: Sebastian Reichel> --- > drivers/mfd/da9052-core.c | 2 ++ > 1 file changed, 2 insertions(+) Applied, thanks. > diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c > index a88c2065d8ab..977418ca9117 100644 > --- a/drivers/mfd/da9052-core.c > +++ b/drivers/mfd/da9052-core.c > @@ -386,6 +386,8 @@ int da9052_adc_manual_read(struct da9052 *da9052, > unsigned char channel) > > mutex_lock(>auxadc_lock); > > + reinit_completion(>done); > + > /* Channel gets activated on enabling the Conversion bit */ > mux_sel = chan_mux[channel] | DA9052_ADC_MAN_MAN_CONV; > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH 08/15] kernel: convert ring_buffer.aux_refcount from atomic_t to refcount_t
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Suggested-by: Kees CookReviewed-by: David Windsor Reviewed-by: Hans Liljestrand Signed-off-by: Elena Reshetova --- kernel/events/core.c| 2 +- kernel/events/internal.h| 2 +- kernel/events/ring_buffer.c | 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index 9147397..072327e 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -5124,7 +5124,7 @@ static void perf_mmap_close(struct vm_area_struct *vma) /* this has to be the last one */ rb_free_aux(rb); - WARN_ON_ONCE(atomic_read(>aux_refcount)); + WARN_ON_ONCE(refcount_read(>aux_refcount)); mutex_unlock(>mmap_mutex); } diff --git a/kernel/events/internal.h b/kernel/events/internal.h index b8e6fdf..fb55716 100644 --- a/kernel/events/internal.h +++ b/kernel/events/internal.h @@ -48,7 +48,7 @@ struct ring_buffer { atomic_taux_mmap_count; unsigned long aux_mmap_locked; void(*free_aux)(void *); - atomic_taux_refcount; + refcount_t aux_refcount; void**aux_pages; void*aux_priv; diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c index 3353572..ba12fd2 100644 --- a/kernel/events/ring_buffer.c +++ b/kernel/events/ring_buffer.c @@ -357,7 +357,7 @@ void *perf_aux_output_begin(struct perf_output_handle *handle, if (!atomic_read(>aux_mmap_count)) goto err; - if (!atomic_inc_not_zero(>aux_refcount)) + if (!refcount_inc_not_zero(>aux_refcount)) goto err; /* @@ -648,7 +648,7 @@ int rb_alloc_aux(struct ring_buffer *rb, struct perf_event *event, * we keep a refcount here to make sure either of the two can * reference them safely. */ - atomic_set(>aux_refcount, 1); + refcount_set(>aux_refcount, 1); rb->aux_overwrite = overwrite; rb->aux_watermark = watermark; @@ -667,7 +667,7 @@ int rb_alloc_aux(struct ring_buffer *rb, struct perf_event *event, void rb_free_aux(struct ring_buffer *rb) { - if (atomic_dec_and_test(>aux_refcount)) + if (refcount_dec_and_test(>aux_refcount)) __rb_free_aux(rb); } -- 2.7.4
Re: [PATCHv4 3/4] dt-bindings: mfd: da9052: support TSI as ADC
On Fri, 30 Jun 2017, Sebastian Reichel wrote: > DA9052 allows using the touchscreen input pins as general purpose > analogue input pin by wiring analogue inputs to X+, X-, Y+ and Y- > and providing a reference voltage at TSIREF pin. > > Signed-off-by: Sebastian Reichel> --- > Documentation/devicetree/bindings/mfd/da9052-i2c.txt | 8 > 1 file changed, 8 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mfd/da9052-i2c.txt > b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt > index 9554292dc6cb..57fa74e65664 100644 > --- a/Documentation/devicetree/bindings/mfd/da9052-i2c.txt > +++ b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt > @@ -4,6 +4,14 @@ Required properties: > - compatible : Should be "dlg,da9052", "dlg,da9053-aa", >"dlg,da9053-ab", or "dlg,da9053-bb" > > +Optional properties: > +- dlg,tsi-as-adc : Boolean, if set the X+, X-, Y+, Y- touchscreen > +input lines are used as general purpose analogue > + input. > +- tsiref-supply: Phandle to the regulator, which provides the reference > + voltage for the TSIREF pin. Must be provided when the > + touchscreen pins are used for ADC purposes. > + DT Ack please. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 1/2] tee.txt: standardize document format
On Wed, Jul 12, 2017 at 10:35:04AM -0300, Mauro Carvalho Chehab wrote: > Each text file under Documentation follows a different format. Some > doesn't even have titles! > > Change its representation to follow the adopted standard, > using ReST markups for it to be parseable by Sphinx: > > - adjust identation of titles; > - mark ascii artwork as a literal block; > - adjust references. > > Signed-off-by: Mauro Carvalho ChehabLooks good to me. In case you're taking it by some other route: Acked-by: Jens Wiklander Please let me know if you'd like me to pick it up. -- Thanks, Jens
Re: [PATCH] printk: modify console_unlock with printk-safe macros
hi Sergey and Andy: > On (07/15/17 18:36), Pierre Kuo wrote: > [..] >> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c >> index fc47863..21557cc 100644 >> --- a/kernel/printk/printk.c >> +++ b/kernel/printk/printk.c >> @@ -2194,8 +2194,7 @@ void console_unlock(void) >> size_t ext_len = 0; >> size_t len; >> >> - printk_safe_enter_irqsave(flags); >> - raw_spin_lock(_lock); >> + logbuf_lock_irqsave(flags); >> if (seen_seq != log_next_seq) { >> wake_klogd = true; >> seen_seq = log_next_seq; >> @@ -2267,8 +2266,7 @@ void console_unlock(void) >>*/ >> raw_spin_lock(_lock); >> retry = console_seq != log_next_seq; >> - raw_spin_unlock(_lock); >> - printk_safe_exit_irqrestore(flags); >> + logbuf_unlock_irqrestore(flags); >> >> if (retry && console_trylock()) >> goto again; > > I did it that particular way for a reason - console_unlock() does a > bunch of tricks: unlocking logbuf in the middle of printing loop, > breaking out of loop with local IRQs disabled, re-taking the logbuf > after the loop still will local IRQs disabled, etc. etc. I didn't > want to (and still don't) mix-in logbuf macros; we do things that > macros don't cover anyway. sorry, I don't agree that the patch > improves readability. Got ur points and appreciate for your illustration. ^^ Thanks a lot,
Re: [PATCH 0/2] use correct values for startup time bits for AXP22X/AXP8XX PEKs
Hi all, On 17/07/2017 11:53, Quentin Schulz wrote: > According to their datasheets, the AXP221, AXP223, AXP288, AXP803, > AXP809 and AXP813 PEK have different values for startup time bits from > the AXP20X PEK (which are currently used for all the aforementioned PMICs). > > This patch series adds support for platform_device_id to axp20x-pek driver > to support different startup time bits depending on PMIC's variant and set > the correct platform_device_id in the mfd. > > This has been tested on AXP813. To perform the test, modify the value of > startup and/or shutdown of the pek in sysfs. Press the button soldered to > PEK input of the AXP the amount of time you set in sysfs. The PMIC shuts > down the board without needing to unplug any power supply. Press PEK button > the amount of time you set in sysfs for startup and the PMIC will start the > board. Note that the time bits are obivoulsy hardware reset to their > default when you unplug all power supplies from the board. > I forgot to add that it depends on this patch series (particularly the third patch (3/6) "mfd: axp20x: Add support for AXP813 PMIC") from Chen-Yu: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1428284.html Quentin > Thanks, > Quentin > > Quentin Schulz (2): > Input: axp20x-pek: add support for AXP221 PEK > mfd: axp20x: use correct platform device id for many PEK > > drivers/input/misc/axp20x-pek.c | 62 > ++--- > drivers/mfd/axp20x.c| 12 > 2 files changed, 58 insertions(+), 16 deletions(-) > -- Quentin Schulz, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: [RFC PATCH] ARM: dts: stm32: change pinctrl bindings definition
On Mon, Jul 17, 2017 at 1:00 PM, Alexandre TORGUEwrote: > blabla > > Signed-off-by: Alexandre TORGUE You may want to provide a little more detail here ;-) Arnd
Re: [PATCH V4 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device
Hi, On 7/15/2017 1:09 AM, Rob Clark wrote: > On Fri, Jul 14, 2017 at 3:36 PM, Will Deaconwrote: >> On Fri, Jul 14, 2017 at 03:34:42PM -0400, Rob Clark wrote: >>> On Fri, Jul 14, 2017 at 3:01 PM, Will Deacon wrote: On Fri, Jul 14, 2017 at 02:25:45PM -0400, Rob Clark wrote: > On Fri, Jul 14, 2017 at 2:06 PM, Will Deacon wrote: >> On Fri, Jul 14, 2017 at 01:42:13PM -0400, Rob Clark wrote: >>> On Fri, Jul 14, 2017 at 1:07 PM, Will Deacon >>> wrote: On Thu, Jul 13, 2017 at 10:55:10AM -0400, Rob Clark wrote: > On Thu, Jul 13, 2017 at 9:53 AM, Sricharan R > wrote: >> Hi, >> >> On 7/13/2017 5:20 PM, Rob Clark wrote: >>> On Thu, Jul 13, 2017 at 1:35 AM, Sricharan R >>> wrote: Hi Vivek, On 7/13/2017 10:43 AM, Vivek Gautam wrote: > Hi Stephen, > > > On 07/13/2017 04:24 AM, Stephen Boyd wrote: >> On 07/06, Vivek Gautam wrote: >>> @@ -1231,12 +1237,18 @@ static int arm_smmu_map(struct >>> iommu_domain *domain, unsigned long iova, >>> static size_t arm_smmu_unmap(struct iommu_domain *domain, >>> unsigned long iova, >>>size_t size) >>> { >>> -struct io_pgtable_ops *ops = >>> to_smmu_domain(domain)->pgtbl_ops; >>> +struct arm_smmu_domain *smmu_domain = >>> to_smmu_domain(domain); >>> +struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops; >>> +size_t ret; >>> if (!ops) >>> return 0; >>> -return ops->unmap(ops, iova, size); >>> +pm_runtime_get_sync(smmu_domain->smmu->dev); >> Can these map/unmap ops be called from an atomic context? I seem >> to recall that being a problem before. > > That's something which was dropped in the following patch merged > in master: > 523d7423e21b iommu/arm-smmu: Remove io-pgtable spinlock > > Looks like we don't need locks here anymore? Apart from the locking, wonder why a explicit pm_runtime is needed from unmap. Somehow looks like some path in the master using that should have enabled the pm ? >>> >>> Yes, there are a bunch of scenarios where unmap can happen with >>> disabled master (but not in atomic context). On the gpu side we >>> opportunistically keep a buffer mapping until the buffer is freed >>> (which can happen after gpu is disabled). Likewise, v4l2 won't >>> unmap >>> an exported dmabuf while some other driver holds a reference to it >>> (which can be dropped when the v4l2 device is suspended). >>> >>> Since unmap triggers tbl flush which touches iommu regs, the iommu >>> driver *definitely* needs a pm_runtime_get_sync(). >> >> Ok, with that being the case, there are two things here, >> >> 1) If the device links are still intact at these places where unmap >> is called, >> then pm_runtime from the master would setup the all the clocks. >> That would >> avoid reintroducing the locking indirectly here. >> >> 2) If not, then doing it here is the only way. But for both cases, >> since >> the unmap can be called from atomic context, resume handler here >> should >> avoid doing clk_prepare_enable , instead move the clk_prepare to >> the init. >> > > I do kinda like the approach Marek suggested.. of deferring the tlb > flush until resume. I'm wondering if we could combine that with > putting the mmu in a stalled state when we suspend (and not resume the > mmu until after the pending tlb flush)? I'm not sure that a stalled state is what we're after here, because we need to take care to prevent any table walks if we've freed the underlying pages. What we could try to do is disable the SMMU (put into global bypass) and invalidate the TLB when performing a suspend operation, then we just ignore invalidation whilst the clocks are stopped and, on resume, enable the SMMU again. >>> >>> wouldn't stalled just block any memory transactions by device(s) using >>> the context bank? Putting it in bypass isn't really a good thing if >>> there is any chance the device can sneak in a memory access before >>> we've taking it back out of bypass (ie.
Re: [PATCH 4/6] ARM: vexpress_defconfig: Cleanup from non-existing options
On Mon, Jul 17, 2017 at 07:49:54AM +0200, Krzysztof Kozlowski wrote: > ARCH_VEXPRESS_CA9X4 is gone since commit 81cc3f868d30 ("ARM: vexpress: > Remove non-DT code"). > > Signed-off-by: Krzysztof KozlowskiAcked-by: Liviu Dudau Thanks for the cleanup! Best regards, Liviu > --- > arch/arm/configs/vexpress_defconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/arm/configs/vexpress_defconfig > b/arch/arm/configs/vexpress_defconfig > index 0fa0ed577b15..edae1c58fe80 100644 > --- a/arch/arm/configs/vexpress_defconfig > +++ b/arch/arm/configs/vexpress_defconfig > @@ -19,7 +19,6 @@ CONFIG_MODULE_UNLOAD=y > # CONFIG_IOSCHED_DEADLINE is not set > # CONFIG_IOSCHED_CFQ is not set > CONFIG_ARCH_VEXPRESS=y > -CONFIG_ARCH_VEXPRESS_CA9X4=y > CONFIG_ARCH_VEXPRESS_DCSCB=y > CONFIG_ARCH_VEXPRESS_TC2_PM=y > # CONFIG_SWP_EMULATE is not set > -- > 2.7.4 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
Re: [PATCH 04/22] scsi: fusion: fix string overflow warning
On Mon, Jul 17, 2017 at 11:17 AM, David Laightwrote: > From: Arnd Bergmann >> Sent: 14 July 2017 13:07 >> gcc points out a theorerical string overflow: >> >> drivers/message/fusion/mptbase.c: In function 'mpt_detach': >> drivers/message/fusion/mptbase.c:2103:17: error: '%s' directive writing up >> to 31 bytes into a region >> of size 28 [-Werror=format-overflow=] >> sprintf(pname, MPT_PROCFS_MPTBASEDIR "/%s/summary", ioc->name); >>^ >> drivers/message/fusion/mptbase.c:2103:2: note: 'sprintf' output between 13 >> and 44 bytes into a >> destination of size 32 >> >> We can simply double the size of the local buffer here to be on the >> safe side. > > I think I'd change it to snprintf() as well. > Saves any worries if ioc->name isn't '\0' terminated. Ok, fair enough, I'll send a new version right away. Arnd
Re: [PATCH 2/2] usb: host: pci_quirks: Force hard reset of Renesas uPD72020x USB controller
On 10.07.2017 18:52, Marc Zyngier wrote: The Renesas uPD72020x XHCI controller seems to suffer from a really annoying bug, where it may retain some of its DMA programming across a XHCI reset, and despite the driver correctly programming new DMA addresses. This is visible if the device has been using 64bit DMA addresses, and is then switched to using 32bit DMA addresses. The top 32bits of the address (now zero) are ignored are replaced by the 32bit from the *previous* programming. Sticking with 64bit DMA always works, but doesn't seem very appropriate. A PCI reset of the device restores the normal functionnality, which is done at probe time. Unfortunately, this has to be done before any quirk has been discovered, hence the intrusive nature of the fix. Signed-off-by: Marc Zyngier--- drivers/usb/host/pci-quirks.c | 20 drivers/usb/host/pci-quirks.h | 1 + drivers/usb/host/xhci-pci.c | 7 +++ 3 files changed, 28 insertions(+) Acked-by: Mathias Nyman
[PATCH 6/7] dt-bindings: pci: qcom: Add support for IPQ8074
Add support for the IPQ8074 PCIe controller. IPQ8074 supports Gen 1/2, one lane, two PCIe root complex with support for MSI and legacy interrupts, and it conforms to PCI Express Base 2.1 specification. Signed-off-by: Varadarajan Narayanan--- .../devicetree/bindings/pci/qcom,pcie.txt | 67 ++ 1 file changed, 67 insertions(+) diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt index 9d418b7..643bcc2 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt @@ -9,6 +9,7 @@ - "qcom,pcie-apq8084" for apq8084 - "qcom,pcie-msm8996" for msm8996 or apq8096 - "qcom,pcie-ipq4019" for ipq4019 + - "qcom,pcie-ipq8074" for ipq8074 - reg: Usage: required @@ -261,3 +262,69 @@ pinctrl-0 = <_pins_default>; pinctrl-names = "default"; }; + +* Example for ipq8074 + pcie0: pci@2000 { + compatible = "qcom,pcie-ipq8074"; + reg = <0x2000 0xf1d + 0x2F20 0xa8 + 0x8 0x2000 + 0x2010 0x1000>; + reg-names = "dbi", "elbi", "parf", "config"; + device_type = "pci"; + linux,pci-domain = <0>; + bus-range = <0x00 0xff>; + num-lanes = <1>; + #address-cells = <3>; + #size-cells = <2>; + + phys = <_0>; + phy-names = "pciephy"; + + ranges = <0x8100 0 0x2020 0x2020 + 0 0x0010 /* downstream I/O */ + 0x8200 0 0x2030 0x2030 + 0 0x00d0>; /* non-prefetchable memory */ + + interrupts = <0 52 0>; + interrupt-names = "msi"; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0x7>; + interrupt-map = <0 0 0 1 0 75 +IRQ_TYPE_LEVEL_HIGH>, /* int_a */ + <0 0 0 2 0 78 +IRQ_TYPE_LEVEL_HIGH>, /* int_b */ + <0 0 0 3 0 79 +IRQ_TYPE_LEVEL_HIGH>, /* int_c */ + <0 0 0 4 0 83 +IRQ_TYPE_LEVEL_HIGH>; /* int_d */ + + clocks =< GCC_SYS_NOC_PCIE0_AXI_CLK>, + < GCC_PCIE0_AXI_M_CLK>, + < GCC_PCIE0_AXI_S_CLK>, + < GCC_PCIE0_AHB_CLK>, + < GCC_PCIE0_AUX_CLK>; + clock-names = "sys_noc", + "axi_m", + "axi_s", + "ahb", + "aux"; + + resets = < GCC_PCIE0_PIPE_ARES>, +< GCC_PCIE0_SLEEP_ARES>, +< GCC_PCIE0_CORE_STICKY_ARES>, +< GCC_PCIE0_AXI_MASTER_ARES>, +< GCC_PCIE0_AXI_SLAVE_ARES>, +< GCC_PCIE0_AHB_ARES>, +< GCC_PCIE0_AXI_MASTER_STICKY_ARES>; + reset-names = "pipe", + "sleep", + "sticky", + "axi_m", + "axi_s", + "ahb", + "axi_m_sticky"; + + perst-gpio = < 58 1>; + status = "disabled"; + }; -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 7/7] PCI: dwc: qcom: Add support for IPQ8074 PCIe controller
Add support for the IPQ8074 PCIe controller. IPQ8074 supports Gen 1/2, one lane, two PCIe root complex with support for MSI and legacy interrupts, and it conforms to PCI Express Base 2.1 specification. The core init is the similar to the existing SoC, however the clocks and reset lines differ. Signed-off-by: smuthayySigned-off-by: Varadarajan Narayanan --- drivers/pci/dwc/pcie-qcom.c | 259 1 file changed, 259 insertions(+) diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c index d15657d..c1fa356 100644 --- a/drivers/pci/dwc/pcie-qcom.c +++ b/drivers/pci/dwc/pcie-qcom.c @@ -37,6 +37,20 @@ #include "pcie-designware.h" #define PCIE20_PARF_SYS_CTRL 0x00 +#define MST_WAKEUP_EN BIT(13) +#define SLV_WAKEUP_EN BIT(12) +#define MSTR_ACLK_CGC_DIS BIT(10) +#define SLV_ACLK_CGC_DIS BIT(9) +#define CORE_CLK_CGC_DIS BIT(6) +#define AUX_PWR_DETBIT(4) +#define L23_CLK_RMV_DISBIT(2) +#define L1_CLK_RMV_DIS BIT(1) + +#define PCIE20_COMMAND_STATUS 0x04 +#define CMD_BME_VAL0x4 +#define PCIE20_DEVICE_CONTROL2_STATUS2 0x98 +#define PCIE_CAP_CPL_TIMEOUT_DISABLE 0x10 + #define PCIE20_PARF_PHY_CTRL 0x40 #define PCIE20_PARF_PHY_REFCLK 0x4C #define PCIE20_PARF_DBI_BASE_ADDR 0x168 @@ -58,9 +72,22 @@ #define CFG_BRIDGE_SB_INIT BIT(0) #define PCIE20_CAP 0x70 +#define PCIE20_CAP_LINK_CAPABILITIES (PCIE20_CAP + 0xC) +#define PCIE20_CAP_LINK_1 (PCIE20_CAP + 0x14) +#define PCIE_CAP_LINK1_VAL 0x2fd7f + +#define PCIE20_PARF_Q2A_FLUSH 0x1AC + +#define PCIE20_MISC_CONTROL_1_REG 0x8BC +#define DBI_RO_WR_EN 1 #define PERST_DELAY_US 1000 +#define AXI_CLK_RATE 2 + +#define PCIE20_v3_PARF_SLV_ADDR_SPACE_SIZE 0x358 +#define SLV_ADDR_SPACE_SZ 0x1000 + struct qcom_pcie_resources_v0 { struct clk *iface_clk; struct clk *core_clk; @@ -110,11 +137,26 @@ struct qcom_pcie_resources_v3 { struct reset_control *phy_ahb_reset; }; +struct qphy_reset { + struct reset_control*rst; + char*name; +}; + +struct qcom_pcie_resources_v4 { + struct clk *sys_noc_clk; + struct clk *axi_m_clk; + struct clk *axi_s_clk; + struct clk *ahb_clk; + struct clk *aux_clk; + struct qphy_reset rst[7]; +}; + union qcom_pcie_resources { struct qcom_pcie_resources_v0 v0; struct qcom_pcie_resources_v1 v1; struct qcom_pcie_resources_v2 v2; struct qcom_pcie_resources_v3 v3; + struct qcom_pcie_resources_v4 v4; }; struct qcom_pcie; @@ -139,6 +181,16 @@ struct qcom_pcie { #define to_qcom_pcie(x)dev_get_drvdata((x)->dev) +static inline void +writel_masked(void __iomem *addr, u32 clear_mask, u32 set_mask) +{ + u32 val = readl(addr); + + val &= ~clear_mask; + val |= set_mask; + writel(val, addr); +} + static void qcom_ep_reset_assert(struct qcom_pcie *pcie) { gpiod_set_value(pcie->reset, 1); @@ -884,6 +936,205 @@ static int qcom_pcie_init_v3(struct qcom_pcie *pcie) return ret; } +static int qcom_pcie_get_resources_v4(struct qcom_pcie *pcie) +{ + struct qcom_pcie_resources_v4 *res = >res.v4; + struct dw_pcie *pci = pcie->pci; + struct device *dev = pci->dev; + int i; + + res->sys_noc_clk = devm_clk_get(dev, "sys_noc"); + if (IS_ERR(res->sys_noc_clk)) + return PTR_ERR(res->sys_noc_clk); + + res->axi_m_clk = devm_clk_get(dev, "axi_m"); + if (IS_ERR(res->axi_m_clk)) + return PTR_ERR(res->axi_m_clk); + + res->axi_s_clk = devm_clk_get(dev, "axi_s"); + if (IS_ERR(res->axi_s_clk)) + return PTR_ERR(res->axi_s_clk); + + res->ahb_clk = devm_clk_get(dev, "ahb"); + if (IS_ERR(res->ahb_clk)) + return PTR_ERR(res->ahb_clk); + + res->aux_clk = devm_clk_get(dev, "aux"); + if (IS_ERR(res->aux_clk)) + return PTR_ERR(res->aux_clk); + + res->rst[0].name = "axi_m"; + res->rst[1].name = "axi_s"; + res->rst[2].name = "pipe"; + res->rst[3].name = "axi_m_sticky"; + res->rst[4].name = "sticky"; + res->rst[5].name = "ahb"; + res->rst[6].name = "sleep"; + + for (i = 0; i < ARRAY_SIZE(res->rst); i++) { + res->rst[i].rst = devm_reset_control_get(dev, res->rst[i].name); + if (IS_ERR(res->rst[i].rst)) +
[PATCH 3/7] phy: qcom-qmp: Fix phy pipe clock name
Presently, the phy pipe clock's name is assumed to be either usb3_phy_pipe_clk_src or pcie_XX_pipe_clk_src (where XX is the phy lane's number). However, this will not work if an SoC has more than one instance of the phy. Hence, instead of assuming the name of the clock, fetch it from the DT. Signed-off-by: Varadarajan Narayanan--- drivers/phy/qualcomm/phy-qcom-qmp.c | 28 1 file changed, 16 insertions(+), 12 deletions(-) diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c b/drivers/phy/qualcomm/phy-qcom-qmp.c index 78ca628..97020ec 100644 --- a/drivers/phy/qualcomm/phy-qcom-qmp.c +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c @@ -925,20 +925,13 @@ static int qcom_qmp_phy_clk_init(struct device *dev) *clk | +---+ | +-+ * +---+ */ -static int phy_pipe_clk_register(struct qcom_qmp *qmp, int id) +static int phy_pipe_clk_register(struct qcom_qmp *qmp, const char *clk_name) { - char name[24]; struct clk_fixed_rate *fixed; struct clk_init_data init = { }; - switch (qmp->cfg->type) { - case PHY_TYPE_USB3: - snprintf(name, sizeof(name), "usb3_phy_pipe_clk_src"); - break; - case PHY_TYPE_PCIE: - snprintf(name, sizeof(name), "pcie_%d_pipe_clk_src", id); - break; - default: + if ((qmp->cfg->type != PHY_TYPE_USB3) && + (qmp->cfg->type != PHY_TYPE_PCIE)) { /* not all phys register pipe clocks, so return success */ return 0; } @@ -947,7 +940,7 @@ static int phy_pipe_clk_register(struct qcom_qmp *qmp, int id) if (!fixed) return -ENOMEM; - init.name = name; + init.name = clk_name; init.ops = _fixed_rate_ops; /* controllers using QMP phys use 125MHz pipe clock interface */ @@ -1110,6 +1103,8 @@ static int qcom_qmp_phy_probe(struct platform_device *pdev) id = 0; for_each_available_child_of_node(dev->of_node, child) { + const char *clk_name; + /* Create per-lane phy */ ret = qcom_qmp_phy_create(dev, child, id); if (ret) { @@ -1118,11 +1113,20 @@ static int qcom_qmp_phy_probe(struct platform_device *pdev) return ret; } + ret = of_property_read_string(child, "clock-output-names", + _name); + if (ret) { + dev_err(dev, + "failed to get clock-output-names for lane%d phy, %d\n", + id, ret); + return ret; + } + /* * Register the pipe clock provided by phy. * See function description to see details of this pipe clock. */ - ret = phy_pipe_clk_register(qmp, id); + ret = phy_pipe_clk_register(qmp, clk_name); if (ret) { dev_err(qmp->dev, "failed to register pipe clock source\n"); -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 5/7] phy: qcom-qmp: Add support for IPQ8074
Add definitions required to enable QMP phy support for IPQ8074. Signed-off-by: smuthayySigned-off-by: Varadarajan Narayanan --- drivers/phy/qualcomm/phy-qcom-qmp.c | 135 1 file changed, 135 insertions(+) diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c b/drivers/phy/qualcomm/phy-qcom-qmp.c index 000ad1c..9019f66 100644 --- a/drivers/phy/qualcomm/phy-qcom-qmp.c +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c @@ -59,6 +59,7 @@ #define QSERDES_COM_PLL_RCTRL_MODE10x088 #define QSERDES_COM_PLL_CCTRL_MODE00x090 #define QSERDES_COM_PLL_CCTRL_MODE10x094 +#define QSERDES_COM_BIAS_EN_CTRL_BY_PSM0x0a8 #define QSERDES_COM_SYSCLK_EN_SEL 0x0ac #define QSERDES_COM_RESETSM_CNTRL 0x0b4 #define QSERDES_COM_RESTRIM_CTRL 0x0bc @@ -143,6 +144,11 @@ #define QPHY_LOCK_DETECT_CONFIG3 0x88 #define QPHY_PWRUP_RESET_DLY_TIME_AUXCLK 0xa0 #define QPHY_LP_WAKEUP_DLY_TIME_AUXCLK 0xa4 +#define QPHY_PLL_LOCK_CHK_DLY_TIME_AUXCLK_LSB 0x1A8 +#define QPHY_OSC_DTCT_ACTIONS 0x1AC +#define QPHY_RX_SIGDET_LVL 0x1D8 +#define QPHY_L1SS_WAKEUP_DLY_TIME_AUXCLK_LSB 0x1DC +#define QPHY_L1SS_WAKEUP_DLY_TIME_AUXCLK_MSB 0x1E0 /* QPHY_SW_RESET bit */ #define SW_RESET BIT(0) @@ -224,6 +230,17 @@ enum qphy_reg_layout { [QPHY_PCS_READY_STATUS] = 0x174, }; +static const unsigned int ipq8074_pciephy_regs_layout[] = { + [QPHY_COM_SW_RESET] = 0x800, + [QPHY_COM_POWER_DOWN_CONTROL] = 0x804, + [QPHY_COM_START_CONTROL]= 0x808, + [QPHY_COM_PCS_READY_STATUS] = QPHY_REG_INVAL, + [QPHY_PLL_LOCK_CHK_DLY_TIME]= 0xa8, + [QPHY_SW_RESET] = 0x00, + [QPHY_START_CTRL] = 0x08, + [QPHY_PCS_READY_STATUS] = 0x174, +}; + static const unsigned int usb3phy_regs_layout[] = { [QPHY_FLL_CNTRL1] = 0xc0, [QPHY_FLL_CNTRL2] = 0xc4, @@ -582,6 +599,121 @@ static inline void qphy_clrbits(void __iomem *base, u32 offset, u32 val) .mask_pcs_ready = PHYSTATUS, }; +static const struct qmp_phy_init_tbl ipq8074_pcie_serdes_tbl[] = { + QMP_PHY_INIT_CFG(QSERDES_COM_BIAS_EN_CLKBUFLR_EN, 0x18), + QMP_PHY_INIT_CFG(QSERDES_COM_CLK_ENABLE1, 0x10), + QMP_PHY_INIT_CFG(QSERDES_COM_BG_TRIM, 0xf), + QMP_PHY_INIT_CFG(QSERDES_COM_LOCK_CMP_EN, 0x1), + QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_MAP, 0x0), + QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_TIMER1, 0x1f), + QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_TIMER2, 0x3f), + QMP_PHY_INIT_CFG(QSERDES_COM_CMN_CONFIG, 0x6), + QMP_PHY_INIT_CFG(QSERDES_COM_PLL_IVCO, 0xf), + QMP_PHY_INIT_CFG(QSERDES_COM_HSCLK_SEL, 0x0), + QMP_PHY_INIT_CFG(QSERDES_COM_SVS_MODE_CLK_SEL, 0x1), + QMP_PHY_INIT_CFG(QSERDES_COM_CORE_CLK_EN, 0x20), + QMP_PHY_INIT_CFG(QSERDES_COM_CORECLK_DIV, 0xa), + QMP_PHY_INIT_CFG(QSERDES_COM_RESETSM_CNTRL, 0x20), + QMP_PHY_INIT_CFG(QSERDES_COM_BG_TIMER, 0xa), + QMP_PHY_INIT_CFG(QSERDES_COM_SYSCLK_EN_SEL, 0xa), + QMP_PHY_INIT_CFG(QSERDES_COM_DEC_START_MODE0, 0x82), + QMP_PHY_INIT_CFG(QSERDES_COM_DIV_FRAC_START3_MODE0, 0x3), + QMP_PHY_INIT_CFG(QSERDES_COM_DIV_FRAC_START2_MODE0, 0x55), + QMP_PHY_INIT_CFG(QSERDES_COM_DIV_FRAC_START1_MODE0, 0x55), + QMP_PHY_INIT_CFG(QSERDES_COM_LOCK_CMP3_MODE0, 0x0), + QMP_PHY_INIT_CFG(QSERDES_COM_LOCK_CMP2_MODE0, 0xD), + QMP_PHY_INIT_CFG(QSERDES_COM_LOCK_CMP1_MODE0, 0xD04), + QMP_PHY_INIT_CFG(QSERDES_COM_CLK_SELECT, 0x33), + QMP_PHY_INIT_CFG(QSERDES_COM_SYS_CLK_CTRL, 0x2), + QMP_PHY_INIT_CFG(QSERDES_COM_SYSCLK_BUF_ENABLE, 0x1f), + QMP_PHY_INIT_CFG(QSERDES_COM_CP_CTRL_MODE0, 0xb), + QMP_PHY_INIT_CFG(QSERDES_COM_PLL_RCTRL_MODE0, 0x16), + QMP_PHY_INIT_CFG(QSERDES_COM_PLL_CCTRL_MODE0, 0x28), + QMP_PHY_INIT_CFG(QSERDES_COM_INTEGLOOP_GAIN1_MODE0, 0x0), + QMP_PHY_INIT_CFG(QSERDES_COM_INTEGLOOP_GAIN0_MODE0, 0x80), + QMP_PHY_INIT_CFG(QSERDES_COM_BIAS_EN_CTRL_BY_PSM, 0x1), + QMP_PHY_INIT_CFG(QSERDES_COM_VCO_TUNE_CTRL, 0xa), + QMP_PHY_INIT_CFG(QSERDES_COM_SSC_EN_CENTER, 0x1), + QMP_PHY_INIT_CFG(QSERDES_COM_SSC_PER1, 0x31), + QMP_PHY_INIT_CFG(QSERDES_COM_SSC_PER2, 0x1), + QMP_PHY_INIT_CFG(QSERDES_COM_SSC_ADJ_PER1, 0x2), + QMP_PHY_INIT_CFG(QSERDES_COM_SSC_ADJ_PER2, 0x0), + QMP_PHY_INIT_CFG(QSERDES_COM_SSC_STEP_SIZE1, 0x2f), + QMP_PHY_INIT_CFG(QSERDES_COM_SSC_STEP_SIZE2, 0x19), + QMP_PHY_INIT_CFG(QSERDES_COM_CLK_EP_DIV, 0x19), + QMP_PHY_INIT_CFG(QSERDES_RX_SIGDET_CNTRL, 0x7), +}; + +static const struct
[PATCH 1/7] dt-bindings: phy: qmp: Add output-clock-names
The phy outputs a clock that will act as the parent for the phy's pipe clock. Add the name of this clock to the lane's DT node. Signed-off-by: Varadarajan Narayanan--- Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt index e11c563..5d7a51f 100644 --- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt @@ -60,6 +60,8 @@ Required properties for child node: one for each entry in clock-names. - clock-names: Must contain following for pcie and usb qmp phys: "pipe" for pipe clock specific to each lane. + - clock-output-names: Name of the phy clock that will be the parent for + the above pipe clock. - resets: a list of phandles and reset controller specifier pairs, one for each entry in reset-names. @@ -96,6 +98,7 @@ Example: clocks = < GCC_PCIE_0_PIPE_CLK>; clock-names = "pipe0"; + clock-output-names = "pcie_0_pipe_clk_src"; resets = < GCC_PCIE_0_PHY_BCR>; reset-names = "lane0"; }; -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 0/7] Add support for IPQ8074 PCIe phy and controller
Add definitions required to enable QMP phy support for IPQ8074. Add support for the IPQ8074 PCIe controller. IPQ8074 supports Gen 1/2, one lane, two PCIe root complex with support for MSI and legacy interrupts, and it conforms to PCI Express Base 2.1 specification. Varadarajan Narayanan (7): dt-bindings: phy: qmp: Add output-clock-names dt-bindings: phy: qmp: Add support for QMP phy in IPQ8074 phy: qcom-qmp: Fix phy pipe clock name phy: qcom-qmp: Handle unavailable registers phy: qcom-qmp: Add support for IPQ8074 dt-bindings: pci: qcom: Add support for IPQ8074 PCI: dwc: qcom: Add support for IPQ8074 PCIe controller .../devicetree/bindings/pci/qcom,pcie.txt | 67 ++ .../devicetree/bindings/phy/qcom-qmp-phy.txt | 31 +++ drivers/pci/dwc/pcie-qcom.c| 259 + drivers/phy/qualcomm/phy-qcom-qmp.c| 186 +-- 4 files changed, 522 insertions(+), 21 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 2/7] dt-bindings: phy: qmp: Add support for QMP phy in IPQ8074
IPQ8074 uses QMP phy controller that provides support to PCIe and USB. Adding dt binding information for the same. Signed-off-by: Varadarajan Narayanan--- .../devicetree/bindings/phy/qcom-qmp-phy.txt | 28 ++ 1 file changed, 28 insertions(+) diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt index 5d7a51f..80d766b 100644 --- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt @@ -6,6 +6,7 @@ controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB. Required properties: - compatible: compatible list, contains: + "qcom,ipq8074-qmp-pcie-phy" for PCIe phy on IPQ8074 "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996, "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996. @@ -107,3 +108,30 @@ Example: ... ... }; + + phy@86000 { + compatible = "qcom,ipq8074-qmp-pcie-phy"; + reg = <0x86000 0x1000>; + + #clock-cells = <1>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + resets = < GCC_PCIE0_PHY_BCR>, +< GCC_PCIE0PHY_PHY_BCR>; + reset-names = "phy", + "phy_phy"; + + status = "ok"; + + pciephy_0: lane@86000 { + reg = <0x86200 0x130>, + <0x86400 0x200>, + <0x86800 0x1f8>; + #phy-cells = <0>; + clocks = < GCC_PCIE0_PIPE_CLK>; + clock-names = "pipe0"; + clock-output-names = "pcie20_phy0_pipe_clk"; + }; + }; -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] mfd: Fix potential NULL pointer dereference
On Wed, 05 Jul 2017, Christophe JAILLET wrote: > if 'max8998_i2c_parse_dt_pdata() fails (when out of memory), a NULL > pointer dereference will occur in the error handling code. > > Return directly instead. > > Fixes: ee999fb3f17f("mfd: max8998: Add support for Device Tree") > Signed-off-by: Christophe JAILLET> --- > drivers/mfd/max8998.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) Applied, thanks. > diff --git a/drivers/mfd/max8998.c b/drivers/mfd/max8998.c > index 4c33b8063bc3..b1d3f70782d9 100644 > --- a/drivers/mfd/max8998.c > +++ b/drivers/mfd/max8998.c > @@ -192,10 +192,8 @@ static int max8998_i2c_probe(struct i2c_client *i2c, > > if (IS_ENABLED(CONFIG_OF) && i2c->dev.of_node) { > pdata = max8998_i2c_parse_dt_pdata(>dev); > - if (IS_ERR(pdata)) { > - ret = PTR_ERR(pdata); > - goto err; > - } > + if (IS_ERR(pdata)) > + return PTR_ERR(pdata); > } > > i2c_set_clientdata(i2c, max8998); -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH V8 1/6] PM / Domains: Add support to select performance-state of domains
On 21 June 2017 at 09:10, Viresh Kumarwrote: > Some platforms have the capability to configure the performance state of > their Power Domains. The performance levels are identified by positive > integer values, a lower value represents lower performance state. > > This patch adds a new genpd API: pm_genpd_update_performance_state(). > The caller passes the affected device and the frequency representing its > next DVFS state. > > The power domains get two new callbacks: > > - get_performance_state(): This is called by the genpd core to retrieve > the performance state (integer value) corresponding to a target > frequency for the device. This state is used by the genpd core to find > the highest requested state by all the devices powered by a domain. Please clarify this a bit more. I guess what you want to say is that genpd aggregates all requested performance state of all its devices and its subdomains, to be able to set a correct (highest requested) performance state. Moreover, could you perhaps explain a bit on *when* this callback becomes invoked. > > - set_performance_state(): The highest state retrieved from above > interface is then passed to this callback to finally program the > performance state of the power domain. When will this callback be invoked? What happens when a power domain gets powered off and then on. Is the performance state restored? Please elaborate a bit on this. > > The power domains can avoid supplying these callbacks, if they don't > support setting performance-states. > > A power domain may have only get_performance_state() callback, if it > doesn't have the capability of changing the performance state itself but > someone in its parent hierarchy has. > > A power domain may have only set_performance_state(), if it doesn't have > any direct devices below it but subdomains. And so the > get_performance_state() will never get called from the core. > It seems like the ->get_perfomance_state() is a device specific callback, while the ->set_performance_state() is a genpd domain callback. I am wondering whether we should try to improve the names of the callbacks to reflect this. > The more common case would be to have both the callbacks set. > > Another API, pm_genpd_has_performance_state(), is also added to let > other parts of the kernel check if the power domain of a device supports > performance-states or not. This could have been done from I think a better name of this function is: dev_pm_genpd_has_performance_state(). What do you think? We might even want to decide to explicitly stay using the terminology "DVFS" instead. In such case, perhaps converting the names of the callbacks/API to use "dvfs" instead. For the API added here, maybe dev_pm_genpd_can_dvfs(). > pm_genpd_update_performance_state() as well, but that routine gets > called every time we do DVFS for the device and it wouldn't be optimal > in that case. So pm_genpd_update_performance_state() is also a new API added in $subject patch. But there is no information about it in the changelog, besides the above. Please add that. Moreover, perhaps we should rename the function to dev_pm_genpd_set_dvfs() > > Note that, the performance level as returned by > ->get_performance_state() for the parent domain of a device is used for > all domains in parent hierarchy. Please clarify a bit on this. What exactly does this mean? > > Tested-by: Rajendra Nayak > Signed-off-by: Viresh Kumar > --- > drivers/base/power/domain.c | 223 > > include/linux/pm_domain.h | 22 + > 2 files changed, 245 insertions(+) > > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > index 71c95ad808d5..d506be9ff1f7 100644 > --- a/drivers/base/power/domain.c > +++ b/drivers/base/power/domain.c > @@ -466,6 +466,229 @@ static int genpd_dev_pm_qos_notifier(struct > notifier_block *nb, > return NOTIFY_DONE; > } > > +/* > + * Returns true if anyone in genpd's parent hierarchy has > + * set_performance_state() set. > + */ > +static bool genpd_has_set_performance_state(struct generic_pm_domain *genpd) > +{ So this function will be become in-directly called by generic drivers that supports DVFS of the genpd for their devices. I think the data you validate here would be better to be pre-validated at pm_genpd_init() and at pm_genpd_add|remove_subdomain() and the result stored in a variable in the genpd struct. Especially when a subdomain is added, that is a point when you can verify the *_performance_state() callbacks, and thus make sure it's a correct setup from the topology point of view. > + struct gpd_link *link; > + > + if (genpd->set_performance_state) > + return true; > + > + list_for_each_entry(link, >slave_links, slave_node) { > + if (genpd_has_set_performance_state(link->master)) > + return true; > +
Re: [PATCH] staging: unisys: visorbus: constify attribute_group structures.
On Mon, Jul 17, 2017 at 05:43:14PM +0530, Arvind Yadav wrote: > Hi Greg, > > > On Monday 17 July 2017 04:15 PM, Greg KH wrote: > > On Mon, Jul 17, 2017 at 02:55:37PM +0530, Arvind Yadav wrote: > > > attribute_groups are not supposed to change at runtime. All functions > > > working with attribute_groups provided by work > > > with const attribute_group. So mark the non-const structs as const. > > > > > > Signed-off-by: Arvind Yadav> > > --- > > > drivers/staging/unisys/visorbus/visorbus_main.c | 4 ++-- > > > drivers/staging/unisys/visorbus/visorchipset.c | 2 +- > > > 2 files changed, 3 insertions(+), 3 deletions(-) > > Why not just use the ATTRIBUTE_GROUPS() macro for these? Or is there > > something that is preventing that? > Yes, we can use. if we are only initializing '.attrs'. > ATTRIBUTE_GROUPS() will not work if we will initialize other member of > attribute_group like 'bin_attrs', 'is_visible', and 'name'. That means you should redo this patch :) Also, your changelog text had a typo, it is "attribute_group", not "attribute_groups". thanks, greg k-h
Re: Regression with suspicious RCU usage splats with cpu_pm change
On Sun, Jul 16, 2017 at 11:08:07PM -0700, Tony Lindgren wrote: > * Alex Shi[170716 16:25]: > > I reused the rcu_irq_enter_irqson() from RCU_NONIDLE to avoid this issue. > > It works fine. > > > > Tony, Could you like to give a tested-by if this patch works for you. > > Yeah that keeps things booting for me with no splats so: > > Tested-by: Tony Lindgren > > In general, it seems we're missing the knowledge in Linux kernel > of when the entire system is idle. Right now it seems that only > cpuidle_coupled knows that? > > We could probably simplify things by adding some PM state for > entire system idle. Then cpuidle code and timer code could use > that to test when it's safe to do whatever the SoC needs to do > to enter deeper power states. > > If we already have something like that, please do let me know :) Well, we used to have CONFIG_NO_HZ_FULL_SYSIDLE, which detected full-system idle lazily so as to avoid scalability bottlenecks. https://lwn.net/Articles/558284/ No one was using it, so I removed it last merge window. The patch that removed it is at sysidle.2017.05.11a, which can probably still be reverted cleanly. Or just use v4.11 or earlier. Thanx, Paul
Re: [PATCH 14/22] [media] usbvision-i2c: fix format overflow warning
On 17/07/17 14:57, Arnd Bergmann wrote: > On Mon, Jul 17, 2017 at 2:53 PM, Hans Verkuilwrote: >> On 14/07/17 14:07, Arnd Bergmann wrote: >>> gcc-7 notices that we copy a fixed length string into another >>> string of the same size, with additional characters: >>> >>> drivers/media/usb/usbvision/usbvision-i2c.c: In function >>> 'usbvision_i2c_register': >>> drivers/media/usb/usbvision/usbvision-i2c.c:190:36: error: '%d' directive >>> writing between 1 and 11 bytes into a region of size between 0 and 47 >>> [-Werror=format-overflow=] >>> sprintf(usbvision->i2c_adap.name, "%s-%d-%s", i2c_adap_template.name, >>> ^~ >>> drivers/media/usb/usbvision/usbvision-i2c.c:190:2: note: 'sprintf' output >>> between 4 and 76 bytes into a destination of size 48 >>> >>> We know this is fine as the template name is always "usbvision", so >>> we can easily avoid the warning by using this as the format string >>> directly. >> >> Hmm, how about replacing sprintf by snprintf? That feels a lot safer (this >> is very >> old code, it's not surprising it is still using sprintf). > > With snprintf(), you will still get a -Wformat-truncation warning. One > of my patches > disables that warning by default, but Mauro likes build-testing with > "make W=1", so > it would still show up then. > > However, we can do both: replace the string and use snprintf(). Yes please! Regards, Hans
[PATCH] Staging: vt6655: Fixing coding style warnings
Removes following warnings found by checkpatch.pl script: WARNING: Prefer using '"%s...", __func__' to using 'xxx', this function's name, in a string Signed-off-by: Simo Koskinen--- drivers/staging/vt6655/card.c | 6 +++--- drivers/staging/vt6655/mac.c | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/vt6655/card.c b/drivers/staging/vt6655/card.c index f5db2b3..14034e3 100644 --- a/drivers/staging/vt6655/card.c +++ b/drivers/staging/vt6655/card.c @@ -649,19 +649,19 @@ static unsigned short CARDwGetOFDMControlRate(struct vnt_private *priv, pr_debug("BASIC RATE: %X\n", priv->basic_rates); if (!CARDbIsOFDMinBasicRate((void *)priv)) { - pr_debug("CARDwGetOFDMControlRate:(NO OFDM) %d\n", wRateIdx); + pr_debug("%s:(NO OFDM) %d\n", __func__, wRateIdx); if (wRateIdx > RATE_24M) wRateIdx = RATE_24M; return wRateIdx; } while (ui > RATE_11M) { if (priv->basic_rates & ((u32)0x1 << ui)) { - pr_debug("CARDwGetOFDMControlRate : %d\n", ui); + pr_debug("%s : %d\n", __func__, ui); return (unsigned short)ui; } ui--; } - pr_debug("CARDwGetOFDMControlRate: 6M\n"); + pr_debug("%s: 6M\n", __func__); return (unsigned short)RATE_24M; } diff --git a/drivers/staging/vt6655/mac.c b/drivers/staging/vt6655/mac.c index 4aaa99b..f7550b2 100644 --- a/drivers/staging/vt6655/mac.c +++ b/drivers/staging/vt6655/mac.c @@ -809,7 +809,7 @@ void MACvSetKeyEntry(struct vnt_private *priv, unsigned short wKeyCtl, if (byLocalID <= 1) return; - pr_debug("MACvSetKeyEntry\n"); + pr_debug("%s\n", __func__); offset = MISCFIFO_KEYETRY0; offset += (uEntryIdx * MISCFIFO_KEYENTRYSIZE); -- 2.7.4
Re: [PATCHv2] staging: iio: adc: add missing of_node references to iio_dev
Hi, The patch seems to be reverted? Also should this part in the IIO core take care of automatically setting the of_node of the IIO device? As far as I can see we don't have to initialize it manually. /* If the calling driver did not initialize of_node, do it here */ if (!indio_dev->dev.of_node && indio_dev->dev.parent) indio_dev->dev.of_node = indio_dev->dev.parent->of_node; - Lars On 07/17/2017 02:34 PM, Hari Prasath wrote: > Adding missing indio_dev->dev.of_node references to allow iio consumers > to access the device channels. > > Signed-off-by: Hari Prasath> --- > v2: Wrong from mail ID in first version of patch > --- > drivers/staging/iio/adc/ad7192.c | 1 - > drivers/staging/iio/adc/ad7780.c | 1 - > 2 files changed, 2 deletions(-) > > diff --git a/drivers/staging/iio/adc/ad7192.c > b/drivers/staging/iio/adc/ad7192.c > index 78308a5..d11c6de 100644 > --- a/drivers/staging/iio/adc/ad7192.c > +++ b/drivers/staging/iio/adc/ad7192.c > @@ -668,7 +668,6 @@ static int ad7192_probe(struct spi_device *spi) > spi_set_drvdata(spi, indio_dev); > st->devid = spi_get_device_id(spi)->driver_data; > indio_dev->dev.parent = >dev; > - indio_dev->dev.of_node = spi->dev.of_node; > indio_dev->name = spi_get_device_id(spi)->name; > indio_dev->modes = INDIO_DIRECT_MODE; > > diff --git a/drivers/staging/iio/adc/ad7780.c > b/drivers/staging/iio/adc/ad7780.c > index e38d2ab9..dec3ba6 100644 > --- a/drivers/staging/iio/adc/ad7780.c > +++ b/drivers/staging/iio/adc/ad7780.c > @@ -195,7 +195,6 @@ static int ad7780_probe(struct spi_device *spi) > spi_set_drvdata(spi, indio_dev); > > indio_dev->dev.parent = >dev; > - indio_dev->dev.of_node = spi->dev.of_node; > indio_dev->name = spi_get_device_id(spi)->name; > indio_dev->modes = INDIO_DIRECT_MODE; > indio_dev->channels = >chip_info->channel; >
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods
On 2017/7/14 12:05, Paul E. McKenney wrote: > > More specifically: rcu_needs_cpu(), rcu_prepare_for_idle(), > rcu_cleanup_after_idle(), rcu_eqs_enter(), rcu_eqs_enter_common(), > rcu_dynticks_eqs_enter(), do_nocb_deferred_wakeup(), > rcu_dynticks_task_enter(), rcu_eqs_exit(), rcu_eqs_exit_common(), > rcu_dynticks_task_exit(), rcu_dynticks_eqs_exit(). > > The first three (rcu_needs_cpu(), rcu_prepare_for_idle(), and > rcu_cleanup_after_idle()) should not be significant unless you have > CONFIG_RCU_FAST_NO_HZ=y. If you do, it would be interesting to learn > how often invoke_rcu_core() is invoked from rcu_prepare_for_idle() > and rcu_cleanup_after_idle(), as this can raise softirq. Also > rcu_accelerate_cbs() and rcu_try_advance_all_cbs(). > > Knowing which of these is causing the most trouble might help me > reduce the overhead in the current idle path. I measured two cases, nothing notable found. The one is CONFIG_NO_HZ_IDLE=y, so the following function is just empty. rcu_prepare_for_idle(): NULL rcu_cleanup_after_idle(): NULL do_nocb_deferred_wakeup(): NULL rcu_dynticks_task_enter(): NULL rcu_dynticks_task_exit(): NULL And the following functions are traced separately, for each function I traced 3 times by intel_PT, for each time the sampling period is 1-second. num means the times the function is invoked in 1-second. (min, max, avg) is the function duration, the unit is nano-second. rcu_needs_cpu(): 1) num: 6110min: 3 max: 564avg: 17.0 2) num: 16535 min: 3 max: 683avg: 18.0 3) num: 8815min: 3 max: 394avg: 20.0 rcu_eqs_enter(): 1) num: 7956min: 17 max: 656avg: 32.0 2) num: 9170min: 17 max: 1075 avg: 35.0 3) num: 8604min: 17 max: 859avg: 29.0 rcu_eqs_enter_common(): 1) num: 14676 min: 15 max: 620avg: 28.0 2) num: 11180 min: 15 max: 795avg: 30.0 3) num: 11484 min: 15 max: 725avg: 29.0 rcu_dynticks_eqs_enter(): 1) num: 11035 min: 10 max: 580avg: 17.0 2) num: 15518 min: 10 max: 456avg: 16.0 3) num: 15320 min: 10 max: 454avg: 19.0 rcu_eqs_exit(): 1) num: 11080 min: 14 max: 893avg: 23.0 2) num: 13526 min: 14 max: 640avg: 23.0 3) num: 12534 min: 14 max: 630avg: 22.0 rcu_eqs_exit_common(): 1) num: 18002 min: 12 max: 553avg: 17.0 2) num: 10570 min: 11 max: 485avg: 17.0 3) num: 13628 min: 11 max: 567avg: 16.0 rcu_dynticks_eqs_exit(): 1) num: 11195 min: 11 max: 436avg: 16.0 2) num: 11808 min: 10 max: 506avg: 16.0 3) num: 8132min: 10 max: 546avg: 15.0 == The other case is CONFIG_NO_HZ_FULL, I also enabled the required config to make all the functions not empty. rcu_needs_cpu(): 1) num: 8530min: 5 max: 770avg: 13.0 2) num: 9965min: 5 max: 518avg: 12.0 3) num: 12503 min: 5 max: 755avg: 16.0 rcu_prepare_for_idle(): 1) num: 11662 min: 5 max: 684avg: 9.0 2) num: 15294 min: 5 max: 676avg: 9.0 3) num: 14332 min: 5 max: 524avg: 9.0 rcu_cleanup_after_idle(): 1) num: 13584 min: 4 max: 657avg: 6.0 2) num: 9102min: 4 max: 529avg: 5.0 3) num: 10648 min: 4 max: 471avg: 6.0 rcu_eqs_enter(): 1) num: 14222 min: 26 max: 745avg: 54.0 2) num: 12502 min: 26 max: 650avg: 53.0 3) num: 11834 min: 26 max: 863avg: 52.0 rcu_eqs_enter_common(): 1) num: 16792 min: 24 max: 973avg: 43.0 2) num: 19755 min: 24 max: 898avg: 45.0 3) num: 8167min: 24 max: 722avg: 42.0 rcu_dynticks_eqs_enter(): 1) num: 11605 min: 10 max: 532avg: 14.0 2) num: 10438 min: 9 max: 554avg: 14.0 3) num: 19816 min: 9 max: 701avg: 14.0 do_nocb_deferred_wakeup(): 1) num: 15348 min: 1 max: 459avg: 3.0 2) num: 12822 min: 1 max: 564avg: 4.0 3) num: 8272min: 0 max: 458avg: 3.0 rcu_dynticks_task_enter(): 1) num: 6358min: 1 max: 268avg: 1.0 2) num: 11128 min: 1 max: 360avg: 1.0 3) num: 20516 min: 1 max: 214avg: 1.0 rcu_eqs_exit(): 1) num: 16117 min: 20 max: 782avg: 43.0 2) num: 11042 min: 20 max: 775avg: 47.0 3) num: 16499 min: 20 max: 752avg: 46.0 rcu_eqs_exit_common(): 1) num: 12584 min: 17 max: 703avg: 28.0 2) num: 17412 min: 17 max: 759avg: 28.0 3) num: 16733 min: 17 max: 798avg: 29.0 rcu_dynticks_task_exit(): 1) num: 11730 min: 1 max: 528avg: 4.0 2) num: 18840 min: 1 max: 581avg: 5.0 3) num: 9815min: 1 max: 381avg: 4.0 rcu_dynticks_eqs_exit(): 1) num: 10902 min: 9 max: 557avg: 13.0 2) num: 19474 min: 9 max: 563avg: 13.0 3) num: 11865 min: 9 max: 672avg: 12.0 Please let me know if there is some data not reasonable, I can revisit again.
[PATCH v2 3/5] ACPI / boot: Add number of legacy IRQs to debug output
Sometimes it's useful to have when mp_config_acpi_legacy_irqs() is called. Signed-off-by: Andy Shevchenko--- arch/x86/kernel/acpi/boot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 6d5b1346268a..0186d3bae610 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -1078,7 +1078,7 @@ static void __init mp_config_acpi_legacy_irqs(void) mp_bus_id_to_type[MP_ISA_BUS] = MP_BUS_ISA; #endif set_bit(MP_ISA_BUS, mp_bus_not_pci); - pr_debug("Bus #%d is ISA\n", MP_ISA_BUS); + pr_debug("Bus #%d is ISA (nIRQs: %d)\n", MP_ISA_BUS, nr_legacy_irqs()); /* * Use the default configuration for the IRQs 0-15. Unless -- 2.11.0
[PATCH] [PING] Fix TIOCGPTPEER ioctl definition
This ioctl does nothing to justify an _IOC_READ or _IOC_WRITE flag because it doesn't copy anything from/to userspace to access the argument. Fixes: 54ebbfb16034 ("tty: add TIOCGPTPEER ioctl") Signed-off-by: Gleb Fotengauer-MalinovskiyAcked-by: Aleksa Sarai Acked-by: Arnd Bergmann --- arch/alpha/include/uapi/asm/ioctls.h | 2 +- arch/mips/include/uapi/asm/ioctls.h| 2 +- arch/parisc/include/uapi/asm/ioctls.h | 2 +- arch/powerpc/include/uapi/asm/ioctls.h | 2 +- arch/sh/include/uapi/asm/ioctls.h | 2 +- arch/sparc/include/uapi/asm/ioctls.h | 2 +- arch/xtensa/include/uapi/asm/ioctls.h | 2 +- include/uapi/asm-generic/ioctls.h | 2 +- 8 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/alpha/include/uapi/asm/ioctls.h b/arch/alpha/include/uapi/asm/ioctls.h index ff67b8373bf7..1cd7dc7d4870 100644 --- a/arch/alpha/include/uapi/asm/ioctls.h +++ b/arch/alpha/include/uapi/asm/ioctls.h @@ -100,7 +100,7 @@ #define TIOCGPKT _IOR('T', 0x38, int) /* Get packet mode state */ #define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */ #define TIOCGEXCL _IOR('T', 0x40, int) /* Get exclusive mode state */ -#define TIOCGPTPEER_IOR('T', 0x41, int) /* Safely open the slave */ +#define TIOCGPTPEER_IO('T', 0x41) /* Safely open the slave */ #define TIOCSERCONFIG 0x5453 #define TIOCSERGWILD 0x5454 diff --git a/arch/mips/include/uapi/asm/ioctls.h b/arch/mips/include/uapi/asm/ioctls.h index 68e19b689a00..1609cb0907ac 100644 --- a/arch/mips/include/uapi/asm/ioctls.h +++ b/arch/mips/include/uapi/asm/ioctls.h @@ -91,7 +91,7 @@ #define TIOCGPKT _IOR('T', 0x38, int) /* Get packet mode state */ #define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */ #define TIOCGEXCL _IOR('T', 0x40, int) /* Get exclusive mode state */ -#define TIOCGPTPEER_IOR('T', 0x41, int) /* Safely open the slave */ +#define TIOCGPTPEER_IO('T', 0x41) /* Safely open the slave */ /* I hope the range from 0x5480 on is free ... */ #define TIOCSCTTY 0x5480 /* become controlling tty */ diff --git a/arch/parisc/include/uapi/asm/ioctls.h b/arch/parisc/include/uapi/asm/ioctls.h index 674c68a5bbd0..d0e3321403be 100644 --- a/arch/parisc/include/uapi/asm/ioctls.h +++ b/arch/parisc/include/uapi/asm/ioctls.h @@ -60,7 +60,7 @@ #define TIOCGPKT _IOR('T', 0x38, int) /* Get packet mode state */ #define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */ #define TIOCGEXCL _IOR('T', 0x40, int) /* Get exclusive mode state */ -#define TIOCGPTPEER_IOR('T', 0x41, int) /* Safely open the slave */ +#define TIOCGPTPEER_IO('T', 0x41) /* Safely open the slave */ #define FIONCLEX 0x5450 /* these numbers need to be adjusted. */ #define FIOCLEX0x5451 diff --git a/arch/powerpc/include/uapi/asm/ioctls.h b/arch/powerpc/include/uapi/asm/ioctls.h index bfd609a3e928..e3b10469f787 100644 --- a/arch/powerpc/include/uapi/asm/ioctls.h +++ b/arch/powerpc/include/uapi/asm/ioctls.h @@ -100,7 +100,7 @@ #define TIOCGPKT _IOR('T', 0x38, int) /* Get packet mode state */ #define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */ #define TIOCGEXCL _IOR('T', 0x40, int) /* Get exclusive mode state */ -#define TIOCGPTPEER_IOR('T', 0x41, int) /* Safely open the slave */ +#define TIOCGPTPEER_IO('T', 0x41) /* Safely open the slave */ #define TIOCSERCONFIG 0x5453 #define TIOCSERGWILD 0x5454 diff --git a/arch/sh/include/uapi/asm/ioctls.h b/arch/sh/include/uapi/asm/ioctls.h index eec7901e9e65..787bac9f67da 100644 --- a/arch/sh/include/uapi/asm/ioctls.h +++ b/arch/sh/include/uapi/asm/ioctls.h @@ -93,7 +93,7 @@ #define TIOCGPKT _IOR('T', 0x38, int) /* Get packet mode state */ #define TIOCGPTLCK _IOR('T', 0x39, int) /* Get Pty lock state */ #define TIOCGEXCL _IOR('T', 0x40, int) /* Get exclusive mode state */ -#define TIOCGPTPEER_IOR('T', 0x41, int) /* Safely open the slave */ +#define TIOCGPTPEER_IO('T', 0x41) /* Safely open the slave */ #define TIOCSERCONFIG _IO('T', 83) /* 0x5453 */ #define TIOCSERGWILD _IOR('T', 84, int) /* 0x5454 */ diff --git a/arch/sparc/include/uapi/asm/ioctls.h b/arch/sparc/include/uapi/asm/ioctls.h index 6d27398632ea..f5df72b93bb2 100644 --- a/arch/sparc/include/uapi/asm/ioctls.h +++ b/arch/sparc/include/uapi/asm/ioctls.h @@ -88,7 +88,7 @@ #define TIOCGPTN _IOR('t', 134, unsigned int) /* Get Pty Number */ #define TIOCSPTLCK _IOW('t', 135, int) /* Lock/unlock PTY */ #define TIOCSIG_IOW('t', 136, int) /* Generate signal on Pty slave */ -#define TIOCGPTPEER_IOR('t', 137, int) /* Safely open the slave */ +#define TIOCGPTPEER_IO('t', 137) /* Safely open the slave */ /* Little f */ #define FIOCLEX_IO('f', 1) diff --git a/arch/xtensa/include/uapi/asm/ioctls.h b/arch/xtensa/include/uapi/asm/ioctls.h index 98b004e24e85..47d82c09be7b
[PATCH v2 2/5] ACPI / boot: Correct address space of __acpi_map_table()
Sparse complains about wrong address space used in __acpi_map_table() and in __acpi_unmap_table(). arch/x86/kernel/acpi/boot.c:127:29: warning: incorrect type in return expression (different address spaces) arch/x86/kernel/acpi/boot.c:127:29:expected char * arch/x86/kernel/acpi/boot.c:127:29:got void [noderef] * arch/x86/kernel/acpi/boot.c:135:23: warning: incorrect type in argument 1 (different address spaces) arch/x86/kernel/acpi/boot.c:135:23:expected void [noderef] *addr arch/x86/kernel/acpi/boot.c:135:23:got char *map Correct address space to be in align of type of returned and passed parameter. Signed-off-by: Andy Shevchenko--- arch/arm64/kernel/acpi.c| 4 ++-- arch/ia64/kernel/acpi.c | 4 ++-- arch/x86/kernel/acpi/boot.c | 4 ++-- include/linux/acpi.h| 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c index e25c11e727fe..b3162715ed78 100644 --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@ -95,7 +95,7 @@ static int __init dt_scan_depth1_nodes(unsigned long node, * __acpi_map_table() will be called before page_init(), so early_ioremap() * or early_memremap() should be called here to for ACPI table mapping. */ -char *__init __acpi_map_table(unsigned long phys, unsigned long size) +void __init __iomem *__acpi_map_table(unsigned long phys, unsigned long size) { if (!size) return NULL; @@ -103,7 +103,7 @@ char *__init __acpi_map_table(unsigned long phys, unsigned long size) return early_memremap(phys, size); } -void __init __acpi_unmap_table(char *map, unsigned long size) +void __init __acpi_unmap_table(void __iomem *map, unsigned long size) { if (!map || !size) return; diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c index 7508c306aa9e..b9388cc283bc 100644 --- a/arch/ia64/kernel/acpi.c +++ b/arch/ia64/kernel/acpi.c @@ -159,12 +159,12 @@ int acpi_request_vector(u32 int_type) return vector; } -char *__init __acpi_map_table(unsigned long phys_addr, unsigned long size) +void __init __iomem *__acpi_map_table(unsigned long phys, unsigned long size) { return __va(phys_addr); } -void __init __acpi_unmap_table(char *map, unsigned long size) +void __init __acpi_unmap_table(void __iomem *map, unsigned long size) { } diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 09ddb3cd627a..6d5b1346268a 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -118,7 +118,7 @@ static u32 isa_irq_to_gsi[NR_IRQS_LEGACY] __read_mostly = { * This is just a simple wrapper around early_ioremap(), * with sanity checks for phys == 0 and size == 0. */ -char *__init __acpi_map_table(unsigned long phys, unsigned long size) +void __init __iomem *__acpi_map_table(unsigned long phys, unsigned long size) { if (!phys || !size) @@ -127,7 +127,7 @@ char *__init __acpi_map_table(unsigned long phys, unsigned long size) return early_ioremap(phys, size); } -void __init __acpi_unmap_table(char *map, unsigned long size) +void __init __acpi_unmap_table(void __iomem *map, unsigned long size) { if (!map || !size) return; diff --git a/include/linux/acpi.h b/include/linux/acpi.h index c749eef1daa1..3848b56fcd83 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -228,8 +228,8 @@ struct acpi_subtable_proc { int count; }; -char * __acpi_map_table (unsigned long phys_addr, unsigned long size); -void __acpi_unmap_table(char *map, unsigned long size); +void __iomem *__acpi_map_table(unsigned long phys_addr, unsigned long size); +void __acpi_unmap_table(void __iomem *map, unsigned long size); int early_acpi_boot_init(void); int acpi_boot_init (void); void acpi_boot_table_init (void); -- 2.11.0
[Resend, PATCH v2 0/5] ACPI / boot: Few amendments
This series does few amendments to architectural ACPI code related to boot, in particularly to arch/x86/kernel/acpi/boot.c. First two patches are amendments to satisfy compiler and static analyzer (the order is changed from first version which had been applied; in case of partial update first patch is already in tree). Third patch might be useful on platforms when debugging *PIC related code path to see how many legacy IRQs are registered. Fourth and fifth patches are preparation for some interesting implementation of ACPI HW reduced platforms (note, this does not mean it's against specification, patch 5 actually about following specification). Fifth patch might be subject to additional discussions. In v2: - fix function declarations in ia64 and arm64 as well (Hanjun) - add three more patches Andy Shevchenko (5): ACPI / boot: Don't define unused variables ACPI / boot: Correct address space of __acpi_map_table() ACPI / boot: Add number of legacy IRQs to debug output ACPI / boot: Not all platform require acpi_reduced_hw_init() ACPI / boot: Don't handle SCI on HW reduced platforms arch/arm64/kernel/acpi.c| 4 ++-- arch/ia64/kernel/acpi.c | 4 ++-- arch/x86/kernel/acpi/boot.c | 15 +-- include/linux/acpi.h| 7 +-- 4 files changed, 18 insertions(+), 12 deletions(-) -- 2.11.0
Re: [PATCH 2/2] mfd: intel_soc_pmic: Differentiate between Bay and Cherry Trail CRC variants
On Sat, 01 Jul 2017, Hans de Goede wrote: > Both Bay and Cherry Trail devices may be used together with a Crystal Cove > PMIC. Each platform has its own variant of the PMIC, which both use the > same ACPI HID, but they are not 100% compatible. > > This commits makes the intel_soc_pmic_core code check the _HRV of the > ACPI-firmware-node and selects intel_soc_pmic_config_byt_crc resp. > intel_soc_pmic_config_cht_crc based on this. > > This fixes the Bay Trail specific ACPI OpRegion code causing problems > on Cherry Trail devices. Specifically this was causing the external > microsd slot on a Dell Venue 8 5855 (Cherry Trail version) to not work > and the eMMC to become unreliable and throw lots of errors. > > Reported-and-tested-by: russianneuromancerReal names only please. What is the name of this reporter/tester? > Signed-off-by: Hans de Goede > --- > drivers/mfd/Kconfig | 4 ++-- > drivers/mfd/intel_soc_pmic_core.c | 34 -- > 2 files changed, 30 insertions(+), 8 deletions(-) Code looks okay though: For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 1/2] mfd: intel_soc_pmic: Export separate mfd-cell configs for BYT and CHT
On Sat, 01 Jul 2017, Hans de Goede wrote: > Both Bay and Cherry Trail devices may be used together with a Crystal Cove > PMIC. Each platform has its own variant of the PMIC, which both use the > same ACPI HID, but they are not 100% compatible. > > Looking at the android x86 kernel sources where most of the Crystal Cove > code comes from, it talks about "Valley View", "Bay Trail" and / or BYT > without ever mentioning Cherry Trail, with the exception of the regulator > driver. The Asus Zenfone-2 kernel code has 2 regulator drivers, one > for Crystal Cove and one for what it calls Crystal Cove Plus. The > Crystal Cove Plus regulator driver is the only one to mention Cherry > Trail and that driver uses different register addresses then the > normal (Bay Trail) Crystal Cove regulator driver, showing that at > least the regulator register addresses are different. > > The GPIO code should work on both, and the PWM code is known to work on > both and is necessary for backlight control on some Cherry Trail devices. > > Testing has shown that the ACPI OpRegion code otoh is causing problems > on Cherry Trail devices, which is not surprising as it deals with the > regulators and those have different register addresses on CHT. > > Specifically the ACPI OpRegion code causes the external microsd slot on > a Dell Venue 8 5855 (Cherry Trail version) to not work and the eMMC to > become unreliable and throw lots of errors. > > This commit replaces the single mfd_cell array currently used for Crystal > Cove with 2 separate arrays, one for the Bay Trail variant and one for > the Cherry Trail variant, note that the Cherry Trail version of the array > only contains gpio and pwm cells. The PMIC OpRegion cell is deliberately > not included and drivers for the other cells in the Bay Trail cell array > were never upstreamed. > > Reported-and-tested-by: russianneuromancer> Signed-off-by: Hans de Goede > --- > drivers/mfd/intel_soc_pmic_core.c | 2 +- > drivers/mfd/intel_soc_pmic_core.h | 3 ++- > drivers/mfd/intel_soc_pmic_crc.c | 27 +++ > 3 files changed, 26 insertions(+), 6 deletions(-) For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 1/2] thermal: int340x: constify attribute_group structures.
Hi Andy, On Monday 17 July 2017 04:11 PM, Andy Shevchenko wrote: On Mon, 2017-07-17 at 16:04 +0530, Arvind Yadav wrote: attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by work with const attribute_group. So mark the non-const structs as const. I hope you did compile test it. I have compiled it. If we will see "int sysfs_create_group(struct kobject *kobj, const struct attribute_group *grp)" and "void sysfs_remove_group(struct kobject *kobj, const struct attribute_group *grp);" Here, passing parameter attribute_group are constant. So I have changed non-const as const. ~arvind File size before: text data bss dec hex filename 1687592 02279 8e7 int3400_thermal.o File size After adding 'const': text data bss dec hex filename 1751528 02279 8e7 int3400_thermal.o Signed-off-by: Arvind Yadav--- drivers/thermal/int340x_thermal/int3400_thermal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/thermal/int340x_thermal/int3400_thermal.c b/drivers/thermal/int340x_thermal/int3400_thermal.c index a9ec94e..b2ffbed 100644 --- a/drivers/thermal/int340x_thermal/int3400_thermal.c +++ b/drivers/thermal/int340x_thermal/int3400_thermal.c @@ -104,7 +104,7 @@ static ssize_t current_uuid_store(struct device *dev, NULL }; -static struct attribute_group uuid_attribute_group = { +static const struct attribute_group uuid_attribute_group = { .attrs = uuid_attrs, .name = "uuids" };
Re: [PATCH] mfd: intel_soc_pmic_chtwc: Turn Kconfig option into a bool
On Fri, 23 Jun 2017, Hans de Goede wrote: > The PMIC provides ACPI OpRegions which must be available for other > drivers' PS0 / PS3 methods early-on as such it must be builtin as the > Kconfig help text already states. > > Somehow its Kconfig option ended up being a tristate though, this fixes > this. > > Signed-off-by: Hans de Goede> --- > Note, feel free to squash this in the original commit if you wish Looks like the original commit is yet to be accepted. Please ensure it's squashed in and resubmit. > --- > drivers/mfd/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 8533cb46a875..be962d128f31 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -476,7 +476,7 @@ config INTEL_SOC_PMIC_BXTWC > on these systems. > > config INTEL_SOC_PMIC_CHTWC > - tristate "Support for Intel Cherry Trail Whiskey Cove PMIC" > + bool "Support for Intel Cherry Trail Whiskey Cove PMIC" > depends on ACPI && HAS_IOMEM && I2C=y && COMMON_CLK > depends on X86 || COMPILE_TEST > select MFD_CORE -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2] kbuild: trivial cleanups on the comments
Hi Cao, 2017-07-16 19:12 GMT+09:00 Cao jin: > index 61f87a9..f0a4ada 100644 > --- a/scripts/Kbuild.include > +++ b/scripts/Kbuild.include > @@ -85,8 +85,8 @@ TMPOUT := $(if $(KBUILD_EXTMOD),$(firstword > $(KBUILD_EXTMOD))/) > > # try-run > # Usage: option = $(call try-run, $(CC)...-o "$$TMP",option-ok,otherwise) > -# Exit code chooses option. "$$TMP" is can be used as temporary file and > -# is automatically cleaned up. > +# Exit code chooses option. "$$TMP" serves as temporary file and is > +# automatically cleaned up. I am not a native speaker, but I think "file" is countable. Maybe, is "as a temporary file" even better? > diff --git a/scripts/basic/Makefile b/scripts/basic/Makefile > index ec10d93..edd983f 100644 > --- a/scripts/basic/Makefile > +++ b/scripts/basic/Makefile > @@ -1,5 +1,5 @@ > ### > -# Makefile.basic lists the most basic programs used during the build process. > +# scripts/basic/Makefile lists the most basic programs used during the build > process. This change is correct, but this line will exceed 80 cols limit. Wrap the lines, or reword like "This Makefile lists ..." Either will do. > # The programs listed herein are what are needed to do the basic stuff, > # such as fix file dependencies. > # This initial step is needed to avoid files to be recompiled -- Best Regards Masahiro Yamada
[PATCH] sphinx-pre-install: check for the need of graphviz-gd
On newer versions of graphviz, it is needed to install a separate package for PDF support. Signed-off-by: Mauro Carvalho Chehab--- This patch depends on a previous patch series I sent yesterday. This, together with the other pending patches are available at: https://git.linuxtv.org/mchehab/experimental.git/log/?h=sphinx_install_v2 scripts/sphinx-pre-install | 9 + 1 file changed, 9 insertions(+) diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install index 230d9cc7ee1d..817241c674d3 100755 --- a/scripts/sphinx-pre-install +++ b/scripts/sphinx-pre-install @@ -285,6 +285,10 @@ sub give_redhat_hints() "xelatex" => "texlive-xetex-bin", ); + my @fedora26_opt_pkgs = ( + "graphviz-gd", # Fedora 26: needed for PDF support + ); + my @fedora_tex_pkgs = ( "texlive-collection-fontsrecommended", "texlive-collection-latex", @@ -293,6 +297,11 @@ sub give_redhat_hints() "dejavu-sans-mono-fonts", ); + my $release; + + $release = $1 if ($system_release =~ /Fedora\s+release\s+(\d+)/); + + check_rpm_missing(\@fedora26_opt_pkgs, 1) if ($pdf && $release >= 26); check_rpm_missing(\@fedora_tex_pkgs, 1) if ($pdf); check_missing_tex(1) if ($pdf); check_missing(\%map); -- 2.13.3
[PATCH v2] Input: adxl34x - fix gcc-7 -Wint-in-bool-context warning
FIFO_MODE is an macro expression with a '<<' operator, which gcc points out could be misread as a '<': drivers/input/misc/adxl34x.c: In function 'adxl34x_probe': drivers/input/misc/adxl34x.c:799:36: error: '<<' in boolean context, did you mean '<' ? [-Werror=int-in-bool-context] This converts the test to an explicit comparison with FIFO_BYPASS, making it clearer to gcc and the reader what is intended. Fixes: e27c729219ad ("Input: add driver for ADXL345/346 Digital Accelerometers") Signed-off-by: Arnd Bergmann--- v2: use FIFO_BYPASS instead of 0 drivers/input/misc/adxl34x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/misc/adxl34x.c b/drivers/input/misc/adxl34x.c index 2b2d02f408bb..a3e79bf5a04b 100644 --- a/drivers/input/misc/adxl34x.c +++ b/drivers/input/misc/adxl34x.c @@ -796,7 +796,7 @@ struct adxl34x *adxl34x_probe(struct device *dev, int irq, if (pdata->watermark) { ac->int_mask |= WATERMARK; - if (!FIFO_MODE(pdata->fifo_mode)) + if (FIFO_MODE(pdata->fifo_mode) == FIFO_BYPASS) ac->pdata.fifo_mode |= FIFO_STREAM; } else { ac->int_mask |= DATA_READY; -- 2.9.0
Re: [PATCH] mfd: max8925-i2c: remove unnecessary static in max8925_probe()
On Tue, 04 Jul 2017, Gustavo A. R. Silva wrote: > Remove unnecessary static on local variable _chip_. > Such variable is initialized before being used, > on every execution path throughout the function. > The static has no benefit and, removing it reduces > the code size. > > This issue was detected using Coccinelle and the following semantic patch: > > @bad exists@ > position p; > identifier x; > type T; > @@ > > static T x@p; > ... > x = <+...x...+> > > @@ > identifier x; > expression e; > type T; > position p != bad.p; > @@ > > -static > T x@p; > ... when != x > when strict > ?x = e; > > In the following log you can see the difference in the code size and, > also a significant difference in the bss segment. This log is the output > of the size command, before and after the code change: > > before: >text data bss dec hex filename >4188 1336 12856521614 drivers/mfd/max8925-i2c.o > > after: >text data bss dec hex filename >4135 1280 6454791567 drivers/mfd/max8925-i2c.o > > Signed-off-by: Gustavo A. R. Silva> --- > drivers/mfd/max8925-i2c.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH 4/7] phy: qcom-qmp: Handle unavailable registers
In some implementations of the QMP phy, some registers might not be present. Provide a way identify such registers and not access those registers. Signed-off-by: Varadarajan Narayanan--- drivers/phy/qualcomm/phy-qcom-qmp.c | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c b/drivers/phy/qualcomm/phy-qcom-qmp.c index 97020ec..000ad1c 100644 --- a/drivers/phy/qualcomm/phy-qcom-qmp.c +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c @@ -187,6 +187,8 @@ struct qmp_phy_init_tbl { .in_layout = 1, \ } +#define QPHY_REG_INVAL 0xu + /* set of registers with offsets different per-PHY */ enum qphy_reg_layout { /* Common block control registers */ @@ -676,15 +678,18 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp) qphy_setbits(serdes, cfg->regs[QPHY_COM_START_CONTROL], SERDES_START | PCS_START); - status = serdes + cfg->regs[QPHY_COM_PCS_READY_STATUS]; - mask = cfg->mask_com_pcs_ready; - - ret = readl_poll_timeout(status, val, (val & mask), 10, -PHY_INIT_COMPLETE_TIMEOUT); - if (ret) { - dev_err(qmp->dev, - "phy common block init timed-out\n"); - goto err_com_init; + if (cfg->regs[QPHY_COM_PCS_READY_STATUS] != QPHY_REG_INVAL) { + status = serdes + cfg->regs[QPHY_COM_PCS_READY_STATUS]; + mask = cfg->mask_com_pcs_ready; + + ret = readl_poll_timeout(status, val, (val & mask), 10, +PHY_INIT_COMPLETE_TIMEOUT); + if (ret) { + dev_err(qmp->dev, + "%s: phy common block init timed-out\n", + __func__); + goto err_com_init; + } } } -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 00/15] perf tools: Fix attr tests
On Mon, Jul 03, 2017 at 04:50:15PM +0200, Jiri Olsa wrote: > hi, > attr tests have been broken for some time now. Updating > the data files plus some other processing fixes. > > It's also available in here: > git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git > perf/attr_test hi, just noticed that this got removed from your branch.. anything wrong with that? thanks, jirka > > thanks, > jirka > --- > tools/perf/perf.h| > 1 + > tools/perf/tests/attr.c | > 12 +++- > tools/perf/tests/attr.py | > 50 +- > tools/perf/tests/attr/base-record| > 8 > tools/perf/tests/attr/base-stat | > 4 ++-- > tools/perf/tests/attr/test-record-C0 | > 1 + > tools/perf/tests/attr/test-record-basic | > 1 + > tools/perf/tests/attr/test-record-branch-any | > 2 +- > tools/perf/tests/attr/test-record-branch-filter-any | > 2 +- > tools/perf/tests/attr/test-record-branch-filter-any_call | > 2 +- > tools/perf/tests/attr/test-record-branch-filter-any_ret | > 2 +- > tools/perf/tests/attr/test-record-branch-filter-hv | > 2 +- > tools/perf/tests/attr/test-record-branch-filter-ind_call | > 2 +- > tools/perf/tests/attr/test-record-branch-filter-k| > 2 +- > tools/perf/tests/attr/test-record-branch-filter-u| > 2 +- > tools/perf/tests/attr/test-record-count | > 1 + > tools/perf/tests/attr/test-record-data | > 3 +-- > tools/perf/tests/attr/test-record-freq | > 1 + > tools/perf/tests/attr/test-record-graph-default | > 1 + > tools/perf/tests/attr/test-record-graph-dwarf| > 4 +++- > tools/perf/tests/attr/test-record-graph-fp | > 1 + > tools/perf/tests/attr/test-record-group | > 2 ++ > tools/perf/tests/attr/test-record-group-sampling | > 3 ++- > tools/perf/tests/attr/test-record-group1 | > 2 ++ > tools/perf/tests/attr/{test-record-no-delay => test-record-no-buffering} | > 4 ++-- > tools/perf/tests/attr/test-record-no-inherit | > 1 + > tools/perf/tests/attr/test-record-no-samples | > 1 + > tools/perf/tests/attr/test-record-period | > 1 + > tools/perf/tests/attr/test-record-raw| > 2 +- > tools/perf/tests/attr/test-stat-C0 | > 4 ++-- > tools/perf/tests/attr/test-stat-default | > 2 ++ > tools/perf/tests/attr/test-stat-detailed-1 | > 2 ++ > tools/perf/tests/attr/test-stat-detailed-2 | > 3 +++ > tools/perf/tests/attr/test-stat-detailed-3 | > 5 + > tools/perf/util/evsel.c | > 8 +++- > 35 files changed, 98 insertions(+), 46 deletions(-)
RE: [PATCH V2] kernel/watchdog: fix spurious hard lockups
> > On Mon, 17 Jul 2017, Liang, Kan wrote: > > There are three proposed patches so far. > > Patch 1: The patch as above which speed up the hrtimer. > > Patch 2: Thomas's first proposal. > > https://patchwork.kernel.org/patch/9803033/ > > https://patchwork.kernel.org/patch/9805903/ > > Patch 3: my original proposal which increase the NMI watchdog timeout > > by 3X https://patchwork.kernel.org/patch/9802053/ > > > > According to our test, only patch 3 works well. > > The other two patches will hang the system eventually. > > For patch 1, the system hang after running our test case for ~1 hour. > > For patch 2, the system hang in running the overnight test. > > There is no error message shown when the system hang. So I don't know > > the root cause yet. > > That doesn't make sense. What's the exact test procedure? I don't know the exact test procedure. The test case is from our customer. I only know that the test case makes calls into the x11 libs. > > > BTW: We set 1 to watchdog_thresh when we did the test. > > It's believed that can speed up the failure. > > Believe is not really a technical measure > 1 is a valid value for watchdog_thresh. It was set through the standard proc interface. /proc/sys/kernel/watchdog_thresh It should not impacts the final test result. Thanks, Kan
[PATCH v2] staging: iio: adc: add missing of_node references to iio_dev
Adding missing indio_dev->dev.of_node references to allow iio consumers to access the device channels. Signed-off-by: Hari Prasath--- v2: Wrong from email ID in first version of patch --- drivers/staging/iio/adc/ad7192.c | 1 + drivers/staging/iio/adc/ad7780.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/staging/iio/adc/ad7192.c b/drivers/staging/iio/adc/ad7192.c index d11c6de..78308a5 100644 --- a/drivers/staging/iio/adc/ad7192.c +++ b/drivers/staging/iio/adc/ad7192.c @@ -668,6 +668,7 @@ static int ad7192_probe(struct spi_device *spi) spi_set_drvdata(spi, indio_dev); st->devid = spi_get_device_id(spi)->driver_data; indio_dev->dev.parent = >dev; + indio_dev->dev.of_node = spi->dev.of_node; indio_dev->name = spi_get_device_id(spi)->name; indio_dev->modes = INDIO_DIRECT_MODE; diff --git a/drivers/staging/iio/adc/ad7780.c b/drivers/staging/iio/adc/ad7780.c index dec3ba6..e38d2ab9 100644 --- a/drivers/staging/iio/adc/ad7780.c +++ b/drivers/staging/iio/adc/ad7780.c @@ -195,6 +195,7 @@ static int ad7780_probe(struct spi_device *spi) spi_set_drvdata(spi, indio_dev); indio_dev->dev.parent = >dev; + indio_dev->dev.of_node = spi->dev.of_node; indio_dev->name = spi_get_device_id(spi)->name; indio_dev->modes = INDIO_DIRECT_MODE; indio_dev->channels = >chip_info->channel; -- 2.10.0.GIT
Re: [PATCH V4 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device
Hi, On 7/17/2017 5:16 PM, Sricharan R wrote: > Hi, > > On 7/15/2017 1:09 AM, Rob Clark wrote: >> On Fri, Jul 14, 2017 at 3:36 PM, Will Deaconwrote: >>> On Fri, Jul 14, 2017 at 03:34:42PM -0400, Rob Clark wrote: On Fri, Jul 14, 2017 at 3:01 PM, Will Deacon wrote: > On Fri, Jul 14, 2017 at 02:25:45PM -0400, Rob Clark wrote: >> On Fri, Jul 14, 2017 at 2:06 PM, Will Deacon wrote: >>> On Fri, Jul 14, 2017 at 01:42:13PM -0400, Rob Clark wrote: On Fri, Jul 14, 2017 at 1:07 PM, Will Deacon wrote: > On Thu, Jul 13, 2017 at 10:55:10AM -0400, Rob Clark wrote: >> On Thu, Jul 13, 2017 at 9:53 AM, Sricharan R >> wrote: >>> Hi, >>> >>> On 7/13/2017 5:20 PM, Rob Clark wrote: On Thu, Jul 13, 2017 at 1:35 AM, Sricharan R wrote: > Hi Vivek, > > On 7/13/2017 10:43 AM, Vivek Gautam wrote: >> Hi Stephen, >> >> >> On 07/13/2017 04:24 AM, Stephen Boyd wrote: >>> On 07/06, Vivek Gautam wrote: @@ -1231,12 +1237,18 @@ static int arm_smmu_map(struct iommu_domain *domain, unsigned long iova, static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned long iova, size_t size) { -struct io_pgtable_ops *ops = to_smmu_domain(domain)->pgtbl_ops; +struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); +struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops; +size_t ret; if (!ops) return 0; -return ops->unmap(ops, iova, size); +pm_runtime_get_sync(smmu_domain->smmu->dev); >>> Can these map/unmap ops be called from an atomic context? I seem >>> to recall that being a problem before. >> >> That's something which was dropped in the following patch merged >> in master: >> 523d7423e21b iommu/arm-smmu: Remove io-pgtable spinlock >> >> Looks like we don't need locks here anymore? > > Apart from the locking, wonder why a explicit pm_runtime is > needed > from unmap. Somehow looks like some path in the master using that > should have enabled the pm ? > Yes, there are a bunch of scenarios where unmap can happen with disabled master (but not in atomic context). On the gpu side we opportunistically keep a buffer mapping until the buffer is freed (which can happen after gpu is disabled). Likewise, v4l2 won't unmap an exported dmabuf while some other driver holds a reference to it (which can be dropped when the v4l2 device is suspended). Since unmap triggers tbl flush which touches iommu regs, the iommu driver *definitely* needs a pm_runtime_get_sync(). >>> >>> Ok, with that being the case, there are two things here, >>> >>> 1) If the device links are still intact at these places where >>> unmap is called, >>> then pm_runtime from the master would setup the all the clocks. >>> That would >>> avoid reintroducing the locking indirectly here. >>> >>> 2) If not, then doing it here is the only way. But for both cases, >>> since >>> the unmap can be called from atomic context, resume handler >>> here should >>> avoid doing clk_prepare_enable , instead move the clk_prepare >>> to the init. >>> >> >> I do kinda like the approach Marek suggested.. of deferring the tlb >> flush until resume. I'm wondering if we could combine that with >> putting the mmu in a stalled state when we suspend (and not resume >> the >> mmu until after the pending tlb flush)? > > I'm not sure that a stalled state is what we're after here, because > we need > to take care to prevent any table walks if we've freed the underlying > pages. > What we could try to do is disable the SMMU (put into global bypass) > and > invalidate the TLB when performing a suspend operation, then we just > ignore > invalidation whilst the clocks are stopped and, on resume, enable the > SMMU > again. wouldn't stalled just block any memory transactions by device(s) using the context
Re: [PATCH v1] staging: rts5208: Change fixed function names with "%s: ", __func__
On Fri, Jul 14, 2017 at 07:38:43PM +0530, Gaurav Pathak wrote: > staging: rts5208: Refactored code to avoid few defects. That's the subject line, why repeat it here? Please put a "real" description of the patch here. > > Signed-off-by: Gaurav Pathak> --- > Hi, Gaurav hope this text appaers in the email, and i put it at the right > place in patch. You did, but why are you writing to yourself? thanks, greg k-h
[PATCH net-next 2/5] virtio-net: pack headroom into ctx for mergeable buffer
Pack headroom into ctx, then during XDP set, we could know the size of headroom and copy if needed. This is required for avoiding reset on XDP. Signed-off-by: Jason Wang--- drivers/net/virtio_net.c | 29 - 1 file changed, 24 insertions(+), 5 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 1f8c15c..8fae9a8 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -270,6 +270,23 @@ static void skb_xmit_done(struct virtqueue *vq) netif_wake_subqueue(vi->dev, vq2txq(vq)); } +#define MRG_CTX_HEADER_SHIFT 22 +static void *mergeable_len_to_ctx(unsigned int truesize, + unsigned int headroom) +{ + return (void *)(unsigned long)((headroom << MRG_CTX_HEADER_SHIFT) | truesize); +} + +static unsigned int mergeable_ctx_to_headroom(void *mrg_ctx) +{ + return (unsigned long)mrg_ctx >> MRG_CTX_HEADER_SHIFT; +} + +static unsigned int mergeable_ctx_to_truesize(void *mrg_ctx) +{ + return (unsigned long)mrg_ctx & ((1 << MRG_CTX_HEADER_SHIFT) - 1); +} + /* Called from bottom half context */ static struct sk_buff *page_to_skb(struct virtnet_info *vi, struct receive_queue *rq, @@ -639,13 +656,14 @@ static struct sk_buff *receive_mergeable(struct net_device *dev, } rcu_read_unlock(); - if (unlikely(len > (unsigned long)ctx)) { + truesize = mergeable_ctx_to_truesize(ctx); + if (unlikely(len > truesize)) { pr_debug("%s: rx error: len %u exceeds truesize %lu\n", dev->name, len, (unsigned long)ctx); dev->stats.rx_length_errors++; goto err_skb; } - truesize = (unsigned long)ctx; + head_skb = page_to_skb(vi, rq, page, offset, len, truesize); curr_skb = head_skb; @@ -665,13 +683,14 @@ static struct sk_buff *receive_mergeable(struct net_device *dev, } page = virt_to_head_page(buf); - if (unlikely(len > (unsigned long)ctx)) { + + truesize = mergeable_ctx_to_truesize(ctx); + if (unlikely(len > truesize)) { pr_debug("%s: rx error: len %u exceeds truesize %lu\n", dev->name, len, (unsigned long)ctx); dev->stats.rx_length_errors++; goto err_skb; } - truesize = (unsigned long)ctx; num_skb_frags = skb_shinfo(curr_skb)->nr_frags; if (unlikely(num_skb_frags == MAX_SKB_FRAGS)) { @@ -889,7 +908,7 @@ static int add_recvbuf_mergeable(struct virtnet_info *vi, buf = (char *)page_address(alloc_frag->page) + alloc_frag->offset; buf += headroom; /* advance address leaving hole at front of pkt */ - ctx = (void *)(unsigned long)len; + ctx = mergeable_len_to_ctx(len, headroom); get_page(alloc_frag->page); alloc_frag->offset += len + headroom; hole = alloc_frag->size - alloc_frag->offset; -- 2.7.4
Re: [PATCH] perf probe: Fix build failure for get_target_map()
Em Mon, Jul 17, 2017 at 04:02:22PM +0530, Ravi Bangoria escreveu: > Commit 801bc8193463 ("perf probe: Allow placing uprobes in > alternate namespaces.") is causing a build failure on powerpc: > > error: incompatible type for argument 2 of 'get_target_map' > map = get_target_map(pev->target, pev->uprobes); > ^~~ > > Fix it by changing parameters of get_target_map(). Thanks, since this hasn't made it to Ingo I'll fold this into the patch where the problem was introduced, adding credits to you, leaving a Link to this message, so that we don't lose bisection in this area on powerpc. - Arnaldo > Fixes: 801bc8193463 ("perf probe: Allow placing uprobes in alternate > namespaces.") > Signed-off-by: Ravi Bangoria> --- > tools/perf/arch/powerpc/util/sym-handling.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/perf/arch/powerpc/util/sym-handling.c > b/tools/perf/arch/powerpc/util/sym-handling.c > index bf9a259..9c4e23d 100644 > --- a/tools/perf/arch/powerpc/util/sym-handling.c > +++ b/tools/perf/arch/powerpc/util/sym-handling.c > @@ -126,7 +126,7 @@ void arch__post_process_probe_trace_events(struct > perf_probe_event *pev, > struct rb_node *tmp; > int i = 0; > > - map = get_target_map(pev->target, pev->uprobes); > + map = get_target_map(pev->target, pev->nsi, pev->uprobes); > if (!map || map__load(map) < 0) > return; > > -- > 2.1.4
Re: [PATCH 05/11] mmc: sunxi: Support controllers that can use both old and new timings
Hi Chen-Yu, [auto build test ERROR on linus/master] [also build test ERROR on v4.13-rc1] [cannot apply to robh/for-next clk/clk-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Chen-Yu-Tsai/ARM-sun8i-a83t-Add-support-for-MMC-controllers/20170715-071008 config: arm64-allmodconfig (attached as .config) compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm64 All errors (new ones prefixed by >>): >> ERROR: "sunxi_ccu_set_mmc_timing_mode" [drivers/mmc/host/sunxi-mmc.ko] >> undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH] PCI: dwc: designware: make dw_pcie_prog_*_atu_unroll() static
Helper functions dw_pcie_prog_*_atu_unroll don't need to be in global scope, so make it static. Cleans up sparse warnings: - symbol 'dw_pcie_prog_outbound_atu_unroll' was not declared. Should it be static? - symbol 'dw_pcie_prog_inbound_atu_unroll' was not declared. Should it be static? Signed-off-by: Carlos Palminha--- Patch made against linux-next tree, tag next-20170714 drivers/pci/dwc/pcie-designware.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pci/dwc/pcie-designware.c b/drivers/pci/dwc/pcie-designware.c index 0e03af279259..48d6d0712ea8 100644 --- a/drivers/pci/dwc/pcie-designware.c +++ b/drivers/pci/dwc/pcie-designware.c @@ -107,7 +107,7 @@ static void dw_pcie_writel_ob_unroll(struct dw_pcie *pci, u32 index, u32 reg, dw_pcie_writel_dbi(pci, offset + reg, val); } -void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index, int type, +static void dw_pcie_prog_outbound_atu_unroll(struct dw_pcie *pci, int index, int type, u64 cpu_addr, u64 pci_addr, u32 size) { u32 retries, val; @@ -200,7 +200,7 @@ static void dw_pcie_writel_ib_unroll(struct dw_pcie *pci, u32 index, u32 reg, dw_pcie_writel_dbi(pci, offset + reg, val); } -int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, int index, int bar, +static int dw_pcie_prog_inbound_atu_unroll(struct dw_pcie *pci, int index, int bar, u64 cpu_addr, enum dw_pcie_as_type as_type) { int type; -- 2.11.0
[PATCH 05/15] kernel: convert task_struct.stack_refcount from atomic_t to refcount_t
refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Suggested-by: Kees CookReviewed-by: David Windsor Reviewed-by: Hans Liljestrand Signed-off-by: Elena Reshetova --- include/linux/init_task.h| 3 ++- include/linux/sched.h| 2 +- include/linux/sched/task_stack.h | 2 +- kernel/fork.c| 6 +++--- 4 files changed, 7 insertions(+), 6 deletions(-) diff --git a/include/linux/init_task.h b/include/linux/init_task.h index 7ba3fca..8be9369 100644 --- a/include/linux/init_task.h +++ b/include/linux/init_task.h @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include @@ -214,7 +215,7 @@ extern struct cred init_cred; #ifdef CONFIG_THREAD_INFO_IN_TASK # define INIT_TASK_TI(tsk) \ .thread_info = INIT_THREAD_INFO(tsk), \ - .stack_refcount = ATOMIC_INIT(1), + .stack_refcount = REFCOUNT_INIT(1), #else # define INIT_TASK_TI(tsk) #endif diff --git a/include/linux/sched.h b/include/linux/sched.h index 9380e44..bd49917 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -1078,7 +1078,7 @@ struct task_struct { #endif #ifdef CONFIG_THREAD_INFO_IN_TASK /* A live task holds one reference: */ - atomic_tstack_refcount; + refcount_t stack_refcount; #endif #ifdef CONFIG_LIVEPATCH int patch_state; diff --git a/include/linux/sched/task_stack.h b/include/linux/sched/task_stack.h index df6ea66..aab3809 100644 --- a/include/linux/sched/task_stack.h +++ b/include/linux/sched/task_stack.h @@ -60,7 +60,7 @@ static inline unsigned long *end_of_stack(struct task_struct *p) #ifdef CONFIG_THREAD_INFO_IN_TASK static inline void *try_get_task_stack(struct task_struct *tsk) { - return atomic_inc_not_zero(>stack_refcount) ? + return refcount_inc_not_zero(>stack_refcount) ? task_stack_page(tsk) : NULL; } diff --git a/kernel/fork.c b/kernel/fork.c index cfd8a42..6fd6be0 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -354,7 +354,7 @@ static void release_task_stack(struct task_struct *tsk) #ifdef CONFIG_THREAD_INFO_IN_TASK void put_task_stack(struct task_struct *tsk) { - if (atomic_dec_and_test(>stack_refcount)) + if (refcount_dec_and_test(>stack_refcount)) release_task_stack(tsk); } #endif @@ -372,7 +372,7 @@ void free_task(struct task_struct *tsk) * If the task had a separate stack allocation, it should be gone * by now. */ - WARN_ON_ONCE(atomic_read(>stack_refcount) != 0); + WARN_ON_ONCE(refcount_read(>stack_refcount) != 0); #endif rt_mutex_debug_task_free(tsk); ftrace_graph_exit_task(tsk); @@ -532,7 +532,7 @@ static struct task_struct *dup_task_struct(struct task_struct *orig, int node) tsk->stack_vm_area = stack_vm_area; #endif #ifdef CONFIG_THREAD_INFO_IN_TASK - atomic_set(>stack_refcount, 1); + refcount_set(>stack_refcount, 1); #endif if (err) -- 2.7.4
[RFC PATCH] ARM: dts: stm32: change pinctrl bindings definition
blabla Signed-off-by: Alexandre TORGUEdiff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi index a8113dc..4bb2b4f 100644 --- a/arch/arm/boot/dts/stm32f429.dtsi +++ b/arch/arm/boot/dts/stm32f429.dtsi @@ -47,7 +47,7 @@ #include "skeleton.dtsi" #include "armv7-m.dtsi" -#include +#include #include #include @@ -687,35 +687,35 @@ usart1_pins_a: usart1@0 { pins1 { - pinmux = ; + pinmux = ; /* USART1_TX */ bias-disable; drive-push-pull; slew-rate = <0>; }; pins2 { - pinmux = ; + pinmux = ; /* USART1_RX */ bias-disable; }; }; usart3_pins_a: usart3@0 { pins1 { - pinmux = ; + pinmux = ; /* USART3_TX */ bias-disable; drive-push-pull; slew-rate = <0>; }; pins2 { - pinmux = ; + pinmux = ; /* USART3_RX */ bias-disable; }; }; usbotg_fs_pins_a: usbotg_fs@0 { pins { - pinmux = , - , - ; + pinmux = , /* OTG_FS_ID */ + , /* OTG_FS_DM */ + ; /* OTG_FS_DP */ bias-disable; drive-push-pull; slew-rate = <2>; @@ -724,9 +724,9 @@ usbotg_fs_pins_b: usbotg_fs@1 { pins { - pinmux = , - , - ; + pinmux = , /* OTG_HS_ID */ + , /* OTG_HS_DM */ + ; /* OTG_HS_DP */ bias-disable; drive-push-pull; slew-rate = <2>; @@ -735,18 +735,18 @@ usbotg_hs_pins_a: usbotg_hs@0 { pins { - pinmux = , - , - , - , - , - , - , - , - , - , - , - ; + pinmux = , /* OTG_HS_ULPI_NXT*/ + , /* OTG_HS_ULPI_DIR */ + , /* OTG_HS_ULPI_STP */ + , /* OTG_HS_ULPI_CK */ + , /* OTG_HS_ULPI_D0 */ + , /* OTG_HS_ULPI_D1 */ + , /* OTG_HS_ULPI_D2 */ + , /* OTG_HS_ULPI_D3 */ + , /* OTG_HS_ULPI_D4 */ +
Re: [PATCH v10] vfio: ABI for mdev display dma-buf operation
Hi, > No need of flag here. If vGPU driver is not loaded in the guest, > there > is no surface being managed by vGPU, in that case this size will be > zero. Ok, we certainly have the same situation with intel. When the guest driver is not loaded (yet) there is no valid surface. We should cleanly define what the ioctl should do in that case, so all drivers behave the same way. I'd suggest that all fields defining the surface (drm_format, width, height, stride, size) should be set to zero in that case. cheers, Gerd
[RESEND PATCH v1] i2c: mediatek: send i2c master code at 400k
From: Jun GaoThe speed of sending i2c master code in high-speed mode depends on source clock, clock-div and TIMING register. The source clock and clock-div of different SoC are not all the same. In order to send i2c master code at 400k in high-speed mode, a appropriate value should be set to TIMING register for a certain source clock and clock-div. Signed-off-by: Jun Gao --- drivers/i2c/busses/i2c-mt65xx.c | 65 + 1 file changed, 46 insertions(+), 19 deletions(-) diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c index 45d6171..9bedf0b 100644 --- a/drivers/i2c/busses/i2c-mt65xx.c +++ b/drivers/i2c/busses/i2c-mt65xx.c @@ -50,7 +50,6 @@ #define I2C_FS_START_CON 0x1800 #define I2C_TIME_CLR_VALUE 0x #define I2C_TIME_DEFAULT_VALUE 0x0003 -#define I2C_FS_TIME_INIT_VALUE 0x1303 #define I2C_WRRD_TRANAC_VALUE 0x0002 #define I2C_RD_TRANAC_VALUE0x0001 @@ -154,6 +153,7 @@ struct mtk_i2c { bool use_push_pull; /* IO config push-pull mode */ u16 irq_stat; /* interrupt status */ + unsigned int clk_src_div; unsigned int speed_hz; /* The speed in transfer */ enum mtk_trans_op op; u16 timing_reg; @@ -285,23 +285,20 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c) * less than or equal to i2c->speed_hz. The calculation try to get * sample_cnt and step_cn */ -static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned int parent_clk, -unsigned int clock_div) +static int mtk_i2c_calculate_speed(struct mtk_i2c *i2c, unsigned int clk_src, + unsigned int target_speed, + unsigned int *timing_step_cnt, + unsigned int *timing_sample_cnt) { - unsigned int clk_src; unsigned int step_cnt; unsigned int sample_cnt; unsigned int max_step_cnt; - unsigned int target_speed; unsigned int base_sample_cnt = MAX_SAMPLE_CNT_DIV; unsigned int base_step_cnt; unsigned int opt_div; unsigned int best_mul; unsigned int cnt_mul; - clk_src = parent_clk / clock_div; - target_speed = i2c->speed_hz; - if (target_speed > MAX_HS_MODE_SPEED) target_speed = MAX_HS_MODE_SPEED; @@ -347,16 +344,48 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned int parent_clk, return -EINVAL; } - step_cnt--; - sample_cnt--; + *timing_step_cnt = step_cnt - 1; + *timing_sample_cnt = sample_cnt - 1; + + return 0; +} + +static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned int parent_clk) +{ + unsigned int clk_src; + unsigned int step_cnt; + unsigned int sample_cnt; + unsigned int target_speed; + int ret; + + clk_src = parent_clk / i2c->clk_src_div; + target_speed = i2c->speed_hz; if (target_speed > MAX_FS_MODE_SPEED) { + /* Set master code speed register */ + ret = mtk_i2c_calculate_speed(i2c, clk_src, MAX_FS_MODE_SPEED, + _cnt, _cnt); + if (ret < 0) + return ret; + + i2c->timing_reg = (sample_cnt << 8) | step_cnt; + /* Set the high speed mode register */ - i2c->timing_reg = I2C_FS_TIME_INIT_VALUE; + ret = mtk_i2c_calculate_speed(i2c, clk_src, target_speed, + _cnt, _cnt); + if (ret < 0) + return ret; + i2c->high_speed_reg = I2C_TIME_DEFAULT_VALUE | (sample_cnt << 12) | (step_cnt << 8); } else { - i2c->timing_reg = (sample_cnt << 8) | (step_cnt << 0); + ret = mtk_i2c_calculate_speed(i2c, clk_src, target_speed, + _cnt, _cnt); + if (ret < 0) + return ret; + + i2c->timing_reg = (sample_cnt << 8) | step_cnt; + /* Disable the high speed transaction */ i2c->high_speed_reg = I2C_TIME_CLR_VALUE; } @@ -647,8 +676,7 @@ static u32 mtk_i2c_functionality(struct i2c_adapter *adap) .functionality = mtk_i2c_functionality, }; -static int mtk_i2c_parse_dt(struct device_node *np, struct mtk_i2c *i2c, - unsigned int *clk_src_div) +static int mtk_i2c_parse_dt(struct device_node *np, struct mtk_i2c *i2c) { int ret; @@ -656,11 +684,11 @@ static int mtk_i2c_parse_dt(struct device_node *np, struct mtk_i2c *i2c, if (ret < 0) i2c->speed_hz = I2C_DEFAULT_SPEED; - ret = of_property_read_u32(np, "clock-div", clk_src_div); + ret =
[RFC PATCH] ARM: dts: stm32: change pinctrl bindings definition
Initially each pin was declared in "include/dt-bindings/stm32f429-pinfunc.h" and each definition contained SOC names (ex: STM32F429_PA9_FUNC_USART1_TX). Since this approach was approved, the number of supported MCU has increased (STM32F429/STM32F469/STM32f746/STM32H743). To avoid to add a new file in "include/dt-bindings" each time a new STM32 SOC arrives I propose a new approach which consist to use a macro to define pin muxing in device tree. All STM32 DT will use the common macro to define pinmux. Furthermore, it will make easy maintenance and integration of new SOC. To check that patch generate same dtb than befrore I used dtc binary to (re)generate dts files (before and after apply the series). Example on stm32f469-disco: ./scripts/dtc/dtc -I dtb -O dts -o stm32f469-disco-after.dts stm32f469-disco-after.dtb ./scripts/dtc/dtc -I dtb -O dts -o stm32f469-disco-before.dts stm32f469-disco-before.dtb Then diff -u stm32f469-disco-before.dts stm32f469-disco-after.dts Regards Alex Alexandre TORGUE (1): ARM: dts: stm32: change pinctrl bindings definition arch/arm/boot/dts/stm32f429.dtsi| 176 ++-- include/dt-bindings/pinctrl/stm32-pinfunc.h | 61 ++ include/dt-bindings/pinctrl/stm32f429-pinfunc.h | 1239 --- 3 files changed, 149 insertions(+), 1327 deletions(-) create mode 100644 include/dt-bindings/pinctrl/stm32-pinfunc.h delete mode 100644 include/dt-bindings/pinctrl/stm32f429-pinfunc.h -- 1.9.1
Re: Droid 4 boot failure due to 422580c3cea7 (mm/oom_kill.c: add tracepoints for oom reaper-related events)
[dropping people from Cc] Hi, On Mon, Jul 17, 2017 at 03:19:28AM -0700, Tony Lindgren wrote: > * Sebastian Reichel[170717 02:52]: > > On Sun, Jul 16, 2017 at 10:59:42PM -0700, Tony Lindgren wrote: > > > Sebastian, for me droid 4 boots just fine with v4.13-rc1 + > > > 19d39a3810e if that helps. So that's with commit 422580c3cea7. > > > > v4.13-rc1 + 19d39a3810e was also broken for me. I just disabled > > some unused bits in my .config and now the kernel boots with > > (with 422580c3cea7 that is). Maybe I hit some maximum image size > > limit for Droid 4? > > > > Anyways it looks like 422580c3cea7 is not the actual problem > > and merely reveals some other problem. > > OK. Maybe check kexec --image-size configuration if you have > a huge static kernel? I still use the IMGSIZE=26214400 from your kexec wrapper for Droid 4, which should be 25MB. With the updated .config my image looks like this: $ ls -lh arch/arm/boot/*Image -rwxr-xr-x 1 sre sre 17M Jul 17 12:44 arch/arm/boot/Image -rwxr-xr-x 1 sre sre 7.2M Jul 17 12:44 arch/arm/boot/zImage Unfortunately I did not check size before I dropped the config options. I don't think I removed 8M of config options, but who knows. -- Sebastian signature.asc Description: PGP signature
Re: [PATCH 1/3] PCI: dwc: Handle host_init failures
Hi Bjorn Andersson, Às 7:39 AM de 7/16/2017, Bjorn Andersson escreveu: > In several dwc based drivers host_init can fail, so make sure to > propagate and handle this to avoid continuing operation of a driver or > hardware in an invalid state. > > Signed-off-by: Bjorn Andersson> --- > drivers/pci/dwc/pci-dra7xx.c | 4 +++- > drivers/pci/dwc/pci-exynos.c | 4 +++- > drivers/pci/dwc/pci-imx6.c | 4 +++- > drivers/pci/dwc/pci-keystone.c | 4 +++- > drivers/pci/dwc/pci-layerscape.c | 14 ++ > drivers/pci/dwc/pcie-armada8k.c| 4 +++- > drivers/pci/dwc/pcie-artpec6.c | 4 +++- > drivers/pci/dwc/pcie-designware-host.c | 7 +-- > drivers/pci/dwc/pcie-designware-plat.c | 4 +++- > drivers/pci/dwc/pcie-designware.h | 2 +- > drivers/pci/dwc/pcie-kirin.c | 4 +++- > drivers/pci/dwc/pcie-qcom.c| 6 -- > drivers/pci/dwc/pcie-spear13xx.c | 4 +++- > 13 files changed, 47 insertions(+), 18 deletions(-) > > diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c > index f2fc5f47064e..e8c13bb76169 100644 > --- a/drivers/pci/dwc/pci-dra7xx.c > +++ b/drivers/pci/dwc/pci-dra7xx.c > @@ -195,7 +195,7 @@ static void dra7xx_pcie_enable_interrupts(struct > dra7xx_pcie *dra7xx) > dra7xx_pcie_enable_msi_interrupts(dra7xx); > } > > -static void dra7xx_pcie_host_init(struct pcie_port *pp) > +static int dra7xx_pcie_host_init(struct pcie_port *pp) > { > struct dw_pcie *pci = to_dw_pcie_from_pp(pp); > struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pci); > @@ -206,6 +206,8 @@ static void dra7xx_pcie_host_init(struct pcie_port *pp) > dw_pcie_wait_for_link(pci); > dw_pcie_msi_init(pp); > dra7xx_pcie_enable_interrupts(dra7xx); > + > + return 0; > } > > static const struct dw_pcie_host_ops dra7xx_pcie_host_ops = { > diff --git a/drivers/pci/dwc/pci-exynos.c b/drivers/pci/dwc/pci-exynos.c > index c78c06552590..f77f872e8b78 100644 > --- a/drivers/pci/dwc/pci-exynos.c > +++ b/drivers/pci/dwc/pci-exynos.c > @@ -581,13 +581,15 @@ static int exynos_pcie_link_up(struct dw_pcie *pci) > return 0; > } > > -static void exynos_pcie_host_init(struct pcie_port *pp) > +static int exynos_pcie_host_init(struct pcie_port *pp) > { > struct dw_pcie *pci = to_dw_pcie_from_pp(pp); > struct exynos_pcie *ep = to_exynos_pcie(pci); > > exynos_pcie_establish_link(ep); > exynos_pcie_enable_interrupts(ep); > + > + return 0; > } > > static const struct dw_pcie_host_ops exynos_pcie_host_ops = { > diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c > index bf5c3616e344..20aae4469ee4 100644 > --- a/drivers/pci/dwc/pci-imx6.c > +++ b/drivers/pci/dwc/pci-imx6.c > @@ -636,7 +636,7 @@ static int imx6_pcie_establish_link(struct imx6_pcie > *imx6_pcie) > return ret; > } > > -static void imx6_pcie_host_init(struct pcie_port *pp) > +static int imx6_pcie_host_init(struct pcie_port *pp) > { > struct dw_pcie *pci = to_dw_pcie_from_pp(pp); > struct imx6_pcie *imx6_pcie = to_imx6_pcie(pci); > @@ -649,6 +649,8 @@ static void imx6_pcie_host_init(struct pcie_port *pp) > > if (IS_ENABLED(CONFIG_PCI_MSI)) > dw_pcie_msi_init(pp); > + > + return 0; > } > > static int imx6_pcie_link_up(struct dw_pcie *pci) > diff --git a/drivers/pci/dwc/pci-keystone.c b/drivers/pci/dwc/pci-keystone.c > index 4783cec1f78d..3ad3f8aa27b0 100644 > --- a/drivers/pci/dwc/pci-keystone.c > +++ b/drivers/pci/dwc/pci-keystone.c > @@ -261,7 +261,7 @@ static int keystone_pcie_fault(unsigned long addr, > unsigned int fsr, > return 0; > } > > -static void __init ks_pcie_host_init(struct pcie_port *pp) > +static int __init ks_pcie_host_init(struct pcie_port *pp) > { > struct dw_pcie *pci = to_dw_pcie_from_pp(pp); > struct keystone_pcie *ks_pcie = to_keystone_pcie(pci); > @@ -289,6 +289,8 @@ static void __init ks_pcie_host_init(struct pcie_port *pp) >*/ > hook_fault_code(17, keystone_pcie_fault, SIGBUS, 0, > "Asynchronous external abort"); > + > + return 0; > } > > static const struct dw_pcie_host_ops keystone_pcie_host_ops = { > diff --git a/drivers/pci/dwc/pci-layerscape.c > b/drivers/pci/dwc/pci-layerscape.c > index fd861289ad8b..7581490f007c 100644 > --- a/drivers/pci/dwc/pci-layerscape.c > +++ b/drivers/pci/dwc/pci-layerscape.c > @@ -108,31 +108,35 @@ static int ls1021_pcie_link_up(struct dw_pcie *pci) > return 1; > } > > -static void ls1021_pcie_host_init(struct pcie_port *pp) > +static int ls1021_pcie_host_init(struct pcie_port *pp) > { > struct dw_pcie *pci = to_dw_pcie_from_pp(pp); > struct ls_pcie *pcie = to_ls_pcie(pci); > struct device *dev = pci->dev; > u32 index[2]; > + int ret; > > pcie->scfg = syscon_regmap_lookup_by_phandle(dev->of_node, >
Re: [PATCH] perf/x86/intel: Fix debug_store reset field for freq events
On Fri, Jul 14, 2017 at 10:22:49AM -0700, Andi Kleen wrote: > Jiri Olsawrites: > > > > Setting the reset field to 0 for freq events. > > Looks good to me. > > Reviewed-by: Andi Kleen > > BTW I suspect there's a related bug that > > perf record -e '{cycles:pp,branches}:S' .. > > would enable multi record PEBS, even though it shouldn't because > we need the PMI to read the other events. there's PERF_SAMPLE_READ om cycles's sample_type for this example so it won't pass the x86_pmu::free_running_flags filter also PERF_SAMPLE_TIME and PERF_SAMPLE_PERIOD will be set in your example which will prevent that, but those could be unset via record's '-c ' and '--no-timestamp' jirka
Re: [PATCH v4 0/3] some fixups for MediaTek cpufreq driver
On Monday, July 17, 2017 01:05:43 PM Viresh Kumar wrote: > On 17-07-17, 14:16, Sean Wang wrote: > > Hi, Viresh > > > > I missed to add Acks from Rob for patch 2 and 3 since we sent out almost > > at the same time. Do I need to resend again for this or the series is > > okay for you? > > Looks like you missed including Rafael for this series (He is the one > who applies these patches). > > I will let him answer for this. > > Please respin with all of the applicable tags. I haven't been following all of the discussions on this that closely. Thanks, Rafael
Re: [Patch v5 12/12] Documention: v4l: Documentation for HEVC CIDs
On Fri, 2017-07-07 at 17:59 +0300, Stanimir Varbanov wrote: > Hi, > > On 06/19/2017 08:10 AM, Smitha T Murthy wrote: > > Added V4l2 controls for HEVC encoder > > > > Signed-off-by: Smitha T Murthy> > --- > > Documentation/media/uapi/v4l/extended-controls.rst | 364 > > + > > 1 file changed, 364 insertions(+) > > > > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst > > b/Documentation/media/uapi/v4l/extended-controls.rst > > index abb1057..7767c70 100644 > > --- a/Documentation/media/uapi/v4l/extended-controls.rst > > +++ b/Documentation/media/uapi/v4l/extended-controls.rst > > @@ -1960,6 +1960,370 @@ enum v4l2_vp8_golden_frame_sel - > > 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3. > > > > > > > > > +``V4L2_CID_MPEG_VIDEO_HEVC_PROFILE`` > > +(enum) > > + > > +enum v4l2_mpeg_video_hevc_profile - > > +Select the desired profile for HEVC encoder. > > + > > +.. raw:: latex > > + > > +\begin{adjustbox}{width=\columnwidth} > > + > > +.. tabularcolumns:: |p{11.0cm}|p{10.0cm}| > > + > > +.. flat-table:: > > +:header-rows: 0 > > +:stub-columns: 0 > > + > > +* - ``V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN`` > > + - Main profile. > > MAIN10? > No just MAIN. > > +* - ``V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE`` > > + - Main still picture profile. > > + > > +.. raw:: latex > > + > > +\end{adjustbox} > > + > > + > > > > > +MFC 10.10 MPEG Controls > > +--- > > + > > +The following MPEG class controls deal with MPEG decoding and encoding > > +settings that are specific to the Multi Format Codec 10.10 device present > > +in the S5P and Exynos family of SoCs by Samsung. > > + > > + > > +.. _mfc1010-control-id: > > + > > +MFC 10.10 Control IDs > > +^ > > + > > +``V4L2_CID_MPEG_MFC10_VIDEO_HEVC_REF_NUMBER_FOR_PFRAMES (integer)`` > > +Selects number of P reference pictures required for HEVC encoder. > > +P-Frame can use 1 or 2 frames for reference. > > + > > +``V4L2_CID_MPEG_MFC10_VIDEO_HEVC_PREPEND_SPSPPS_TO_IDR (integer)`` > > +Indicates whether to generate SPS and PPS at every IDR. Setting it to 0 > > +disables generating SPS and PPS at every IDR. Setting it to one enables > > +generating SPS and PPS at every IDR. > > + > > I'm not sure those two should be driver specific, have to check does > venus driver has similar controls. > Yes please check and let me know if you have similar controls, I will move it out. > > + > > .. _camera-controls: > > > > Camera Control Reference > > >
Re: [PATCH] Documentation: dt: chosen property for kaslr-seed
On Sun, Jul 16, 2017 at 05:42:25PM +0100, Ard Biesheuvel wrote: > On 16 July 2017 at 03:13, Kees Cookwrote: > > On Sat, Jul 15, 2017 at 5:42 AM, Ard Biesheuvel > > wrote: > >> (+ Mark, Will, Catalin) > >> > >> On 15 July 2017 at 01:38, Kees Cook wrote: > >>> Document then /chosen/kaslr-seed property (and its interaction with the > >>> EFI_RNG_PROTOCOL API). > >>> > >>> Signed-off-by: Kees Cook > >>> --- > >>> Documentation/devicetree/bindings/chosen.txt | 22 -- > >>> 1 file changed, 20 insertions(+), 2 deletions(-) > >> > >> For the textual changes: > >> > >> Acked-by: Ard Biesheuvel > >> > >> *However*, documenting the /chosen/kaslr-seed property promotes it > >> from a stub<->kernel private interface to an external ABI between the > >> kernel and the bootloader, and we need to reach agreement on whether > >> doing so is desirable first IMHO. > > > > Oh! I thought that was the point (having a bootloader provide kaslr > > entropy). And that in the EFI case, it was the stub doing it. > > It was the opposite, actually, The /chosen node is the most > appropriate way for the EFI stub to communicate a seed value to the > kernel proper, given how it is needed extremely early in the boot. > (Using UEFI config tables like we do for the /dev/random seed is not > possible for this) > > So as a side effect, other bootloaders can use the same mechanism. I'm > fine with that, but it needs to be an explicit decision by the > maintainers imo. I was under the impression that we'd already assumed other bootloaders could set this, so I don't have a problem promoting this to a defined public interface. I guess we just need Will and Catalin to agree. FWIW: Acked-by: Mark Rutland As an aside, we might want to make a split between /chosen properties which are Linux-specific (e.g. this), and those which are somewhat generic (e.g. stdout-path), since other OSs may/should respect those generic ones. Mark.
[PATCH 0/3] arcpgu: Fixes and improvements
Hi all, Two fixes and an improvement for arcpgu. I've sent this patches in separate but I've now collected them all to ease the review. Best regards, Jose Miguel Abreu Jose Abreu (3): drm: arcpgu: Fix mmap() callback drm: arcpgu: Fix module unload drm: arcpgu: Allow some clock deviation in crtc->mode_valid() callback Cc: Carlos PalminhaCc: Alexey Brodkin Cc: Daniel Vetter Cc: Dave Airlie drivers/gpu/drm/arc/arcpgu_crtc.c | 7 --- drivers/gpu/drm/arc/arcpgu_drv.c | 26 ++ 2 files changed, 6 insertions(+), 27 deletions(-) -- 1.9.1
[PATCH 1/3] drm: arcpgu: Fix mmap() callback
Now that ARC properly supports DMA mmap() we can use the standard CMA helper to map dumb buffers. This makes ARC PGU works with standard DRM consumer applications like, for example, mpv/mplayer via DRM. While at it, use the DEFINE_DRM_GEM_CMA_FOPS() helper. This fixes the use of dumb buffers. Signed-off-by: Jose AbreuFixes: 0c4250e7b15e ("drm: Add support of ARC PGU display controller") Cc: Carlos Palminha Cc: Alexey Brodkin Cc: Daniel Vetter Cc: Dave Airlie --- drivers/gpu/drm/arc/arcpgu_drv.c | 24 +--- 1 file changed, 1 insertion(+), 23 deletions(-) diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c index 3e43a5d..20ab68f 100644 --- a/drivers/gpu/drm/arc/arcpgu_drv.c +++ b/drivers/gpu/drm/arc/arcpgu_drv.c @@ -48,29 +48,7 @@ static void arcpgu_setup_mode_config(struct drm_device *drm) drm->mode_config.funcs = _drm_modecfg_funcs; } -static int arcpgu_gem_mmap(struct file *filp, struct vm_area_struct *vma) -{ - int ret; - - ret = drm_gem_mmap(filp, vma); - if (ret) - return ret; - - vma->vm_page_prot = pgprot_noncached(vm_get_page_prot(vma->vm_flags)); - return 0; -} - -static const struct file_operations arcpgu_drm_ops = { - .owner = THIS_MODULE, - .open = drm_open, - .release = drm_release, - .unlocked_ioctl = drm_ioctl, - .compat_ioctl = drm_compat_ioctl, - .poll = drm_poll, - .read = drm_read, - .llseek = no_llseek, - .mmap = arcpgu_gem_mmap, -}; +DEFINE_DRM_GEM_CMA_FOPS(arcpgu_drm_ops); static void arcpgu_lastclose(struct drm_device *drm) { -- 1.9.1
[PATCH 3/3] drm: arcpgu: Allow some clock deviation in crtc->mode_valid() callback
Currently we expect that clock driver produces the exact same value as we are requiring. There can, and will, be some deviation however so we need to take that into account instead of just rejecting the mode. According to the HDMI spec we have a max of +-0.5% for the pixel clock frequency deviation. Lets take that into an advantage and use it to calculate how much deviation we can support. Signed-off-by: Jose AbreuAcked-by: Alexey Brodkin Cc: Carlos Palminha Cc: Alexey Brodkin Cc: Daniel Vetter Cc: Dave Airlie --- drivers/gpu/drm/arc/arcpgu_crtc.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c b/drivers/gpu/drm/arc/arcpgu_crtc.c index 1859dd3..55c5d5b 100644 --- a/drivers/gpu/drm/arc/arcpgu_crtc.c +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c @@ -69,12 +69,13 @@ static enum drm_mode_status arc_pgu_crtc_mode_valid(struct drm_crtc *crtc, { struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc); long rate, clk_rate = mode->clock * 1000; + long diff = clk_rate / 200; /* +-0.5% allowed by HDMI spec */ rate = clk_round_rate(arcpgu->clk, clk_rate); - if (rate != clk_rate) - return MODE_NOCLOCK; + if ((max(rate, clk_rate) - min(rate, clk_rate) < diff) && (rate > 0)) + return MODE_OK; - return MODE_OK; + return MODE_NOCLOCK; } static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc *crtc) -- 1.9.1