* [PATCH] of: build dbts with symbols when CONFIG_OF_OVERLAY is set
From: Andre Heider @ 2017-12-20 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0468b711-ba39-98d8-5bbe-0246a98db863@gmail.com>
On 18/12/17 23:10, Frank Rowand wrote:
> On 12/16/17 09:25, Andre Heider wrote:
>> Hi Frank,
>>
>> On 15/12/17 22:06, Frank Rowand wrote:
>>> On 12/14/17 07:12, Andre Heider wrote:
>>>> The overlay feature requires the base dtb to be built with symbols, so
>>>> lets build the dtbs with symbols when overlay support was explicitly
>>>> enabled.
>>>>
>>>> With CONFIG_OF_ALL_DTBS on ARCH=arm the 989 dtb files grow about ~38% on
>>>> average.
>>>>
>>>> Totals in bytes with the 3 biggest ones:
>>>>
>>>> Before:
>>>> ????90471??? arch/arm/boot/dts/am57xx-beagle-x15-revc.dtb
>>>> ????90521??? arch/arm/boot/dts/am57xx-beagle-x15-revb1.dtb
>>>> ????92639??? arch/arm/boot/dts/dra7-evm.dtb
>>>> ????25731296??? total
>>>>
>>>> After:
>>>> ????133203??? arch/arm/boot/dts/am57xx-beagle-x15-revc.dtb
>>>> ????133237??? arch/arm/boot/dts/am57xx-beagle-x15-revb1.dtb
>>>> ????134545??? arch/arm/boot/dts/dra7-evm.dtb
>>>> ????35464440??? total
>>>>
>>>> Signed-off-by: Andre Heider <a.heider@gmail.com>
>>>> ---
>>>>
>>>> Hi,
>>>>
>>>> while playing around with overlays I noticed that I needed to rebuilt
>>>> my distro's device trees because they didn't come with symbols.
>>>>
>>>> Is that for a reason, maybe the not so minor increase in size?
>>>
>>> Yes, size is the issue.
>>>
>>>
>>>>
>>>> Thanks,
>>>> Andre
>>>>
>>>> ? drivers/of/unittest-data/Makefile | 7 -------
>>>> ? scripts/Makefile.lib????????????? | 5 +++++
>>>> ? 2 files changed, 5 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/drivers/of/unittest-data/Makefile b/drivers/of/unittest-data/Makefile
>>>> index 32389acfa616..b65061013512 100644
>>>> --- a/drivers/of/unittest-data/Makefile
>>>> +++ b/drivers/of/unittest-data/Makefile
>>>> @@ -15,13 +15,6 @@ targets += overlay.dtb overlay.dtb.S
>>>> ? targets += overlay_bad_phandle.dtb overlay_bad_phandle.dtb.S
>>>> ? targets += overlay_bad_symbol.dtb overlay_bad_symbol.dtb.S
>>>> ? targets += overlay_base.dtb overlay_base.dtb.S
>>>> -
>>>> -# enable creation of __symbols__ node
>>>> -DTC_FLAGS_overlay := -@
>>>> -DTC_FLAGS_overlay_bad_phandle := -@
>>>> -DTC_FLAGS_overlay_bad_symbol := -@
>>>> -DTC_FLAGS_overlay_base := -@
>>>> -
>>>> ? endif
>>>> ? ? .PRECIOUS: \
>>>
>>> No.? The unittests require these to be set unconditionally.
>>>
>>>
>>>> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
>>>> index 1ca4dcd2d500..c7ba4aa8a07a 100644
>>>> --- a/scripts/Makefile.lib
>>>> +++ b/scripts/Makefile.lib
>>>> @@ -278,6 +278,11 @@ DTC_FLAGS += -Wnode_name_chars_strict \
>>>> ????? -Wproperty_name_chars_strict
>>>> ? endif
>>>> ? +ifeq ($(CONFIG_OF_OVERLAY),y)
>>>> +# enable creation of __symbols__ node
>>>> +DTC_FLAGS += -@
>>>> +endif
>>>> +
>>>> ? DTC_FLAGS += $(DTC_FLAGS_$(basetarget))
>>>> ? ? # Generate an assembly file to wrap the output of the device tree compiler
>>>>
>>>
>>> Not needed.? Instead set DTC_FLAGS in the make command.? For example:
>>>
>>> ??? DTC_FLAGS=-@ make qcom-apq8074-dragonboard.dtb
>>>
>>> There are a few architecture Makefiles that need to be fixed to not unconditionally
>>> set DTC_FLAGS.
>>
>> Rebuilding the dts files manually with symbols isn't the problem. The
>> idea was to enable it with a switch which distros simply can flip.
>>
>> Passing DTC_FLAGS to `make` would work too I guess, but on multi
>> platform builds that's still the same issue if there're boards which
>> can't handle that because of the size increase.
>>
>> Would a solution which enables symbols per family work? E.g.
>> CONFIG_MACH_SUN7I chooses to use -@ because it can handle it.
>>
>> Thanks,
>> Andre
>
> Making it easy for distros to increase the size of .dtb files is
> not the correct answer. We are trying to decrease the footprint
> of devicetree, not increase it.
I'm not sure I follow. If it's not acceptable to increase the size,
why's there overlay support in the first place?
There're distros/downstreams that support overlays today, like armbian,
beaglebone and rpi. All carrying their own patches to enable symbols [1]
[2] [3] and I'm sure others will follow. Why can't there be some sort of
switch for those to build their dtbs with symbols?
Regards,
Andre
[1]
https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/add-overlay-compilation-support.patch#L98
[2]
https://github.com/beagleboard/linux/commit/ed6b9450c2a2ec21149f14ff24770b69888abda6
[3]
https://github.com/raspberrypi/linux/blob/rpi-4.15.y/arch/arm/boot/dts/Makefile#L1124
^ permalink raw reply
* [PATCH v4 4/4] ARM: pinctrl: sunxi-pinctrl: fix pin funtion can not be match correctly.
From: Linus Walleij @ 2017-12-20 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213144748.GA18267@arx-s1>
On Wed, Dec 13, 2017 at 3:47 PM, hao_zhang <hao5781286@gmail.com> wrote:
> Pin function can not be match correctly when SUNXI_PIN describe with
> mutiple variant and same function.
>
> such as:
> on pinctrl-sun4i-a10.c
>
> SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2),
> SUNXI_FUNCTION(0x0, "gpio_in"),
> SUNXI_FUNCTION(0x1, "gpio_out"),
> SUNXI_FUNCTION_VARIANT(0x2, "pwm", /* PWM0 */
> PINCTRL_SUN4I_A10 |
> PINCTRL_SUN7I_A20),
> SUNXI_FUNCTION_VARIANT(0x3, "pwm", /* PWM0 */
> PINCTRL_SUN8I_R40)),
>
> it would always match to the first variant function
> (PINCTRL_SUN4I_A10, PINCTRL_SUN7I_A20)
>
> so we should add variant compare on it.
>
> Signed-off-by: hao_zhang <hao5781286@gmail.com>
Please resend patch with Maxime's suggestions fixed and his
ACK added so I can apply it.
I can take this patch separatelt, it does not need to be part of
the PWM series.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] pinctrl: rockchip: enable clock when reading pin direction register
From: Linus Walleij @ 2017-12-20 8:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212174343.192017-1-briannorris@chromium.org>
On Tue, Dec 12, 2017 at 6:43 PM, Brian Norris <briannorris@chromium.org> wrote:
> We generally leave the GPIO clock disabled, unless an interrupt is
> requested or we're accessing IO registers. We forgot to do this for the
> ->get_direction() callback, which means we can sometimes [1] get
> incorrect results [2] from, e.g., /sys/kernel/debug/gpio.
>
> Enable the clock, so we get the right results!
>
> [1] Sometimes, because many systems have 1 or mor interrupt requested on
> each GPIO bank, so they always leave their clock on.
>
> [2] Incorrect, meaning the register returns 0, and so we interpret that
> as "input".
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
Patch applied with Heiko's review tag.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 4/4] pinctrl: mediatek: update MAINTAINERS entry with MediaTek pinctrl driver
From: Linus Walleij @ 2017-12-20 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d41feb63ea2ebbfe58f5940ff27b031dd8024b28.1513059082.git.sean.wang@mediatek.com>
On Tue, Dec 12, 2017 at 7:24 AM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> I work for MediaTek on maintaining the existing MediaTek SoC whose target
> to home gateway such as MT7622 and MT7623 that is reusing MT2701 related
> files and will keep adding support for the following such kinds of SoCs
> in the future.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Reviewed-by: Biao Huang <biao.huang@mediatek.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 3/4] pinctrl: mediatek: add pinctrl driver for MT7622 SoC
From: Linus Walleij @ 2017-12-20 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5b42c51c965fb2824646630dd93d3d531610e344.1513059081.git.sean.wang@mediatek.com>
On Tue, Dec 12, 2017 at 7:24 AM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Add support for pinctrl on MT7622 SoC. The IO core found on the SoC has
> the registers for pinctrl, pinconf and gpio mixed up in the same register
> range. However, the IO core for the MT7622 SoC is completely distinct from
> anyone of previous MediaTek SoCs which already had support, such as
> the hardware internal, register address map and register detailed
> definition for each pin.
>
> Therefore, instead, the driver is being newly implemented by reusing
> generic methods provided from the core layer with GENERIC_PINCONF,
> GENERIC_PINCTRL_GROUPS, and GENERIC_PINMUX_FUNCTIONS for the sake of code
> simplicity and rid of superfluous code. Where the function of pins
> determined by groups is utilized in this driver which can help developers
> less confused with what combinations of pins effective on the SoC and even
> reducing the mistakes during the integration of those relevant boards.
>
> As the gpio_chip handling is also only a few lines, the driver also
> implements the gpio functionality directly through GPIOLIB.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Reviewed-by: Biao Huang <biao.huang@mediatek.com>
Patch applied. Very nice work!
As I've seen visiting Asia how popular MTK chips are for all kinds
of devices it's really nice to have proper upstream support directly from
Mediatek on these chips. You guys are awesome.
Some suggestions for improvements:
> +static void mtk_w32(struct mtk_pinctrl *pctl, u32 reg, u32 val)
> +{
> + writel_relaxed(val, pctl->base + reg);
> +}
> +
> +static u32 mtk_r32(struct mtk_pinctrl *pctl, u32 reg)
> +{
> + return readl_relaxed(pctl->base + reg);
> +}
> +
> +static void mtk_rmw(struct mtk_pinctrl *pctl, u32 reg, u32 mask, u32 set)
> +{
> + u32 val;
> +
> + val = mtk_r32(pctl, reg);
> + val &= ~mask;
> + val |= set;
> + mtk_w32(pctl, reg, val);
> +}
Have you considered replacing this with regmap-mmio? It does pretty much
the same thing. It could be an improvemet reducing code a bit and making
it more generic. The error codes from eg regmap_update_bits() can be
safely ignored on MMIO maps.
> +static int mtk_build_gpiochip(struct mtk_pinctrl *hw, struct device_node *np)
> +{
> + struct gpio_chip *chip = &hw->chip;
> + int ret;
> +
> + chip->label = PINCTRL_PINCTRL_DEV;
> + chip->parent = hw->dev;
> + chip->request = gpiochip_generic_request;
> + chip->free = gpiochip_generic_free;
> + chip->direction_input = mtk_gpio_direction_input;
> + chip->direction_output = mtk_gpio_direction_output;
Please submit a patch implementing chip->get_direction(), it
is really helpful, especially for debugging.
If your pin controller later adds support for things that can be
used from the GPIO side, like open drain or debounce, then
please consider at that point to also implement
chip->set_config() in the gpio_chip. That way your GPIO consumers
can use e.g. open drain through pin control as back-end.
See drivers/pinctrl/intel/pinctrl-intel.c for an example.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/4] pinctrl: mediatek: cleanup for placing all drivers under the menu
From: Linus Walleij @ 2017-12-20 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fc13c7249505784c1f89a2e0775bb9a75cd38c3f.1513059081.git.sean.wang@mediatek.com>
On Tue, Dec 12, 2017 at 7:24 AM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Since lots of MediaTek drivers had been added, it seems slightly better
> for that adding cleanup for placing MediaTek pinctrl drivers under the
> independent menu as other kinds of drivers usually was done.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Reviewed-by: Biao Huang <biao.huang@mediatek.com>
Patch applied. Also very nice!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 1/4] dt-bindings: pinctrl: add bindings for MediaTek MT7622 SoC
From: Linus Walleij @ 2017-12-20 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <eb93acdb07a0205e9d3089058b45aee1a6c04d50.1513059081.git.sean.wang@mediatek.com>
On Tue, Dec 12, 2017 at 7:24 AM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Add devicetree bindings for MediaTek MT7622 pinctrl driver.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Reviewed-by: Biao Huang <biao.huang@mediatek.com>
Patch applied with Rob's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V2 9/9] ARM: dts: stm32: add initial support of stm32mp157c eval board
From: Linus Walleij @ 2017-12-20 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513610272-7824-10-git-send-email-ludovic.Barre@st.com>
On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre <ludovic.Barre@st.com> wrote:
> From: Ludovic Barre <ludovic.barre@st.com>
>
> Add support of stm32mp157c evaluation board (part number: STM32MP157C-EV1)
> split in 2 elements:
> -Daughter board (part number: STM32MP157C-ED1)
> which includes CPU, memory and power supply
> -Mother board (part number: STM32MP157C-EM1)
> which includes external peripherals (like display, camera,...)
> and extension connectors.
>
> The daughter board can run alone, this is why the device tree files
> are split in two layers, for the complete evaluation board (ev1)
> and for the daughter board alone (ed1).
>
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
(...)
> diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts b/arch/arm/boot/dts/stm32mp157c-ev1.dts
Evaluation boards are important because they set a pattern that customers
will use.
Please consider to include nodes for all GPIO blocks used in this
evaluation board, and add:
gpio-line-names = "foo", "bar" ...;
See for example
arch/arm/boot/dts/bcm2835-rpi-a.dts
arch/arm/boot/dts/ste-snowball.dts
It's good to have because probably you guys have proper schematics and
know rail names of the stuff connected to those GPIO lines and so on,
so you can give the lines proper names.
It will be helpful for people using the reference design, especially with the
new character device, and also sets a pattern for people doing devices
based on the reference design and we really want to do that.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V2 6/9] pinctrl: stm32: Add STM32MP157 MPU support
From: Linus Walleij @ 2017-12-20 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513610272-7824-7-git-send-email-ludovic.Barre@st.com>
On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre <ludovic.Barre@st.com> wrote:
> From: Ludovic Barre <ludovic.barre@st.com>
>
> This driver consists of 2 controllers due to a hole in mapping:
> -1 controller for GPIO bankA to K.
> -1 controller for GPIO bankZ.
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V2 1/9] devicetree: bindings: Document supported STM32 SoC family
From: Linus Walleij @ 2017-12-20 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513610272-7824-2-git-send-email-ludovic.Barre@st.com>
On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre <ludovic.Barre@st.com> wrote:
> From: Ludovic Barre <ludovic.barre@st.com>
>
> This adds a list of supported STM32 SoC bindings.
>
> Signed-off-by: Gwenael Treuveur <gwenael.treuveur@st.com>
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] arm64: dts: Remove leading 0x and 0s from bindings notation
From: Andy Gross @ 2017-12-20 6:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214165352.27902-1-malat@debian.org>
On Thu, Dec 14, 2017 at 05:53:52PM +0100, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -E -i -e "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" -e "s/@0+([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" {} +
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
Acked-by: Andy Gross <andy.gross@linaro.org>
^ permalink raw reply
* [PATCH v2] IPI performance benchmark
From: Wanpeng Li @ 2017-12-20 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219085010.4081-1-ynorov@caviumnetworks.com>
Hi Yury,
2017-12-19 16:50 GMT+08:00 Yury Norov <ynorov@caviumnetworks.com>:
> This benchmark sends many IPIs in different modes and measures
> time for IPI delivery (first column), and total time, ie including
> time to acknowledge the receive by sender (second column).
>
> The scenarios are:
> Dry-run: do everything except actually sending IPI. Useful
> to estimate system overhead.
> Self-IPI: Send IPI to self CPU.
> Normal IPI: Send IPI to some other CPU.
> Broadcast IPI: Send broadcast IPI to all online CPUs.
> Broadcast lock: Send broadcast IPI to all online CPUs and force them
> acquire/release spinlock.
>
> The raw output looks like this:
> [ 155.363374] Dry-run: 0, 2999696 ns
> [ 155.429162] Self-IPI: 30385328, 65589392 ns
> [ 156.060821] Normal IPI: 566914128, 631453008 ns
> [ 158.384427] Broadcast IPI: 0, 2323368720 ns
> [ 160.831850] Broadcast lock: 0, 2447000544 ns
>
> For virtualized guests, sending and reveiving IPIs causes guest exit.
> I used this test to measure performance impact on KVM subsystem of
> Christoffer Dall's series "Optimize KVM/ARM for VHE systems" [1].
>
> Test machine is ThunderX2, 112 online CPUs. Below the results normalized
> to host dry-run time, broadcast lock results omitted. Smaller - better.
Could you test on a x86 box? I see a lot of calltraces on my haswell
client host, there is no calltrace in the guest, however, I can still
observe "Invalid parameters" warning when insmod this module. In
addition, the x86 box fails to boot when ipi_benchmark is buildin.
Regards,
Wanpeng Li
^ permalink raw reply
* [PATCH v3 18/20] ARM: dts: aspeed-romulus: Update Romulus system
From: Cédric Le Goater @ 2017-12-20 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220032328.30584-19-joel@jms.id.au>
On 12/20/2017 04:23 AM, Joel Stanley wrote:
> - Fix incorrect RAM size
> - Remove alias; these are now specified in the dtsi
> - Add newly upstreamed devices
> - Include OpenBMC flash layout
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: C?dric Le Goater <clg@kaod.org>
> ---
> v3:
> - Add GPIO include
> - Fix duplicate fmc and spi nodes
> - Add unit name for memory node to fix warning
> ---
> arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 133 +++++++++++++++++++++++++--
> 1 file changed, 126 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> index a7a9386f964d..623b6ab42021 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> @@ -1,23 +1,19 @@
> // SPDX-License-Identifier: GPL-2.0+
> /dts-v1/;
> -
> #include "aspeed-g5.dtsi"
> +#include <dt-bindings/gpio/aspeed-gpio.h>
>
> / {
> model = "Romulus BMC";
> compatible = "ibm,romulus-bmc", "aspeed,ast2500";
>
> - aliases {
> - serial4 = &uart5;
> - };
> -
> chosen {
> stdout-path = &uart5;
> bootargs = "console=ttyS4,115200 earlyprintk";
> };
>
> - memory {
> - reg = <0x80000000 0x40000000>;
> + memory at 80000000 {
> + reg = <0x80000000 0x20000000>;
> };
>
> reserved-memory {
> @@ -29,6 +25,49 @@
> no-map;
> reg = <0xbf000000 0x01000000>; /* 16M */
> };
> +
> + flash_memory: region at 98000000 {
> + no-map;
> + reg = <0x98000000 0x04000000>; /* 64M */
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + fault {
> + gpios = <&gpio ASPEED_GPIO(N, 2) GPIO_ACTIVE_LOW>;
> + };
> +
> + identify {
> + gpios = <&gpio ASPEED_GPIO(N, 4) GPIO_ACTIVE_HIGH>;
> + };
> +
> + power {
> + gpios = <&gpio ASPEED_GPIO(R, 5) GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + fsi: gpio-fsi {
> + compatible = "fsi-master-gpio", "fsi-master";
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + clock-gpios = <&gpio ASPEED_GPIO(AA, 0) GPIO_ACTIVE_HIGH>;
> + data-gpios = <&gpio ASPEED_GPIO(AA, 2) GPIO_ACTIVE_HIGH>;
> + mux-gpios = <&gpio ASPEED_GPIO(A, 6) GPIO_ACTIVE_HIGH>;
> + enable-gpios = <&gpio ASPEED_GPIO(D, 0) GPIO_ACTIVE_HIGH>;
> + trans-gpios = <&gpio ASPEED_GPIO(R, 2) GPIO_ACTIVE_HIGH>;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + checkstop {
> + label = "checkstop";
> + gpios = <&gpio ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>;
> + linux,code = <ASPEED_GPIO(J, 2)>;
> + };
> };
> };
>
> @@ -38,6 +77,7 @@
> status = "okay";
> m25p,fast-read;
> label = "bmc";
> +#include "openbmc-flash-layout.dtsi"
> };
> };
>
> @@ -53,6 +93,12 @@
> };
> };
>
> +&lpc_ctrl {
> + status = "okay";
> + memory-region = <&flash_memory>;
> + flash = <&spi1>;
> +};
> +
> &uart1 {
> /* Rear RS-232 connector */
> status = "okay";
> @@ -81,6 +127,10 @@
> pinctrl-0 = <&pinctrl_rmii1_default>;
> };
>
> +&i2c1 {
> + status = "okay";
> +};
> +
> &i2c2 {
> status = "okay";
> };
> @@ -133,8 +183,77 @@
>
> &i2c12 {
> status = "okay";
> +
> + max31785 at 52 {
> + compatible = "maxim,max31785";
> + reg = <0x52>;
> + };
> +};
> +
> +&gpio {
> + nic_func_mode0 {
> + gpio-hog;
> + gpios = <ASPEED_GPIO(D, 3) GPIO_ACTIVE_HIGH>;
> + output-low;
> + line-name = "nic_func_mode0";
> + };
> + nic_func_mode1 {
> + gpio-hog;
> + gpios = <ASPEED_GPIO(D, 4) GPIO_ACTIVE_HIGH>;
> + output-low;
> + line-name = "nic_func_mode1";
> + };
> };
>
> &vuart {
> status = "okay";
> };
> +
> +&gfx {
> + status = "okay";
> +};
> +
> +&pinctrl {
> + aspeed,external-nodes = <&gfx &lhc>;
> +};
> +
> +&pwm_tacho {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm0_default &pinctrl_pwm1_default>;
> +
> + fan at 0 {
> + reg = <0x00>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x08>;
> + };
> +
> + fan at 1 {
> + reg = <0x00>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x09>;
> + };
> +
> + fan at 2 {
> + reg = <0x01>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0a>;
> + };
> +
> + fan at 3 {
> + reg = <0x01>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0b>;
> + };
> +
> + fan at 4 {
> + reg = <0x00>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0c>;
> + };
> +
> + fan at 5 {
> + reg = <0x00>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0d>;
> + };
> +
> + fan at 6 {
> + reg = <0x01>;
> + aspeed,fan-tach-ch = /bits/ 8 <0x0e>;
> + };
> +};
>
^ permalink raw reply
* [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs
From: Sricharan R @ 2017-12-20 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220062712.GV19815@vireshk-i7>
Hi Viresh,
On 12/20/2017 11:57 AM, Viresh Kumar wrote:
> On 20-12-17, 11:55, Sricharan R wrote:
>>>> + opp-1400000000 {
>>>> + opp-hz = /bits/ 64 <1400000000>;
>>>> + opp-microvolt-speed0-pvs0-v0 = <1250000>;
>>>
>>> Why speed0 and v0 in all the names ?
>>>
>>
>> Ya, all the three (speed, pvs and version) are read from efuse. So all the three
>> can vary.
>
> Okay, so may be in the example you should have a mix of all the
> combinations to show how these things work ? You only showed values
> for a single efuse configuration currently.
>
Ha ok. Will add other examples as well.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs
From: Viresh Kumar @ 2017-12-20 6:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b0d8147a-46e1-0787-ae37-9c1ef957d190@codeaurora.org>
On 20-12-17, 11:55, Sricharan R wrote:
> >> + opp-1400000000 {
> >> + opp-hz = /bits/ 64 <1400000000>;
> >> + opp-microvolt-speed0-pvs0-v0 = <1250000>;
> >
> > Why speed0 and v0 in all the names ?
> >
>
> Ya, all the three (speed, pvs and version) are read from efuse. So all the three
> can vary.
Okay, so may be in the example you should have a mix of all the
combinations to show how these things work ? You only showed values
for a single efuse configuration currently.
--
viresh
^ permalink raw reply
* [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs
From: Sricharan R @ 2017-12-20 6:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220032614.GQ19815@vireshk-i7>
Hi Viresh,
On 12/20/2017 8:56 AM, Viresh Kumar wrote:
> On 19-12-17, 21:25, Sricharan R wrote:
>> + cpu at 0 {
>> + compatible = "qcom,krait";
>> + enable-method = "qcom,kpss-acc-v1";
>> + device_type = "cpu";
>> + reg = <0>;
>> + qcom,acc = <&acc0>;
>> + qcom,saw = <&saw0>;
>> + clocks = <&kraitcc 0>;
>> + clock-names = "cpu";
>> + cpu-supply = <&smb208_s2a>;
>> + operating-points-v2 = <&cpu_opp_table>;
>> + };
>> +
>> + qcom,pvs {
>> + qcom,pvs-format-a;
>> + };
>
> Not sure what Rob is going to say on that :)
>
Yes. Would be good to know the best way.
>> +
>> +
>> + cpu_opp_table: opp_table {
>> + compatible = "operating-points-v2";
>> +
>> + /*
>> + * Missing opp-shared property means CPUs switch DVFS states
>> + * independently.
>> + */
>> +
>> + opp-1400000000 {
>> + opp-hz = /bits/ 64 <1400000000>;
>> + opp-microvolt-speed0-pvs0-v0 = <1250000>;
>
> Why speed0 and v0 in all the names ?
>
Ya, all the three (speed, pvs and version) are read from efuse. So all the three
can vary.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v5 14/15] cpufreq: Add module to register cpufreq on Krait CPUs
From: Sricharan R @ 2017-12-20 6:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220033608.GR19815@vireshk-i7>
Hi Viresh,
On 12/20/2017 9:06 AM, Viresh Kumar wrote:
> On 19-12-17, 21:24, Sricharan R wrote:
>> From: Stephen Boyd <sboyd@codeaurora.org>
>>
>> Register a cpufreq-generic device whenever we detect that a
>> "qcom,krait" compatible CPU is present in DT.
>>
>> Cc: <devicetree@vger.kernel.org>
>> [Sricharan: updated to use dev_pm_opp_set_prop_name]
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>> drivers/cpufreq/Kconfig.arm | 9 ++
>> drivers/cpufreq/Makefile | 1 +
>> drivers/cpufreq/cpufreq-dt-platdev.c | 3 +-
>> drivers/cpufreq/qcom-cpufreq.c | 171 +++++++++++++++++++++++++++++++++++
>> 4 files changed, 183 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/cpufreq/qcom-cpufreq.c
>>
>> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
>> index bdce448..60f28e7 100644
>> --- a/drivers/cpufreq/Kconfig.arm
>> +++ b/drivers/cpufreq/Kconfig.arm
>> @@ -100,6 +100,15 @@ config ARM_OMAP2PLUS_CPUFREQ
>> depends on ARCH_OMAP2PLUS
>> default ARCH_OMAP2PLUS
>>
>> +config ARM_QCOM_CPUFREQ
>> + tristate "Qualcomm based"
>
> Qualcomm based ... ? You want to add something after this ?
>
Hmm, got truncated. Will add a proper one.
> And why tristate ? Do you really want to build a module for this ?
>
Given that cpufreq-dt that registers the driver already supports module,
don't think this needs to be a module. So will make it a bool.
>> + depends on ARCH_QCOM
>> + select PM_OPP
>> + help
>> + This adds the CPUFreq driver for Qualcomm SoC based boards.
>> +
>> + If in doubt, say N.
>> +
>> config ARM_S3C_CPUFREQ
>> bool
>> help
>> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> index 812f9e0..1496464 100644
>> --- a/drivers/cpufreq/Makefile
>> +++ b/drivers/cpufreq/Makefile
>> @@ -62,6 +62,7 @@ obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ) += mediatek-cpufreq.o
>> obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
>> obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
>> obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
>> +obj-$(CONFIG_ARM_QCOM_CPUFREQ) += qcom-cpufreq.o
>> obj-$(CONFIG_ARM_S3C24XX_CPUFREQ) += s3c24xx-cpufreq.o
>> obj-$(CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS) += s3c24xx-cpufreq-debugfs.o
>> obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
>> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
>> index ecc56e2..032ac4f 100644
>> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
>> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
>> @@ -118,7 +118,7 @@
>> { .compatible = "ti,am33xx", },
>> { .compatible = "ti,am43", },
>> { .compatible = "ti,dra7", },
>> -
>
> Keep this blank line as is..
>
ok
>> + { .compatible = "qcom,ipq8064", },
>
> And add another one here.
>
ok
>> { }
>> };
>>
>> @@ -157,6 +157,7 @@ static int __init cpufreq_dt_platdev_init(void)
>>
>> create_pdev:
>> of_node_put(np);
>> +
>
> Remove this.
>
ok
>> return PTR_ERR_OR_ZERO(platform_device_register_data(NULL, "cpufreq-dt",
>> -1, data,
>> sizeof(struct cpufreq_dt_platform_data)));
>> diff --git a/drivers/cpufreq/qcom-cpufreq.c b/drivers/cpufreq/qcom-cpufreq.c
>> new file mode 100644
>> index 0000000..3e5583d
>> --- /dev/null
>> +++ b/drivers/cpufreq/qcom-cpufreq.c
>> @@ -0,0 +1,171 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
>> +
>> +#include <linux/cpu.h>
>> +#include <linux/err.h>
>> +#include <linux/init.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pm_opp.h>
>> +#include <linux/slab.h>
>> +#include "cpufreq-dt.h"
>> +
>> +static void __init get_krait_bin_format_a(int *speed, int *pvs, int *pvs_ver)
>> +{
>> + void __iomem *base;
>> + u32 pte_efuse;
>> +
>> + *speed = *pvs = *pvs_ver = 0;
>> +
>> + base = ioremap(0x007000c0, 4);
>> + if (!base) {
>> + pr_warn("Unable to read efuse data. Defaulting to 0!\n");
>> + return;
>> + }
>> +
>> + pte_efuse = readl_relaxed(base);
>> + iounmap(base);
>> +
>> + *speed = pte_efuse & 0xf;
>> + if (*speed == 0xf)
>> + *speed = (pte_efuse >> 4) & 0xf;
>> +
>> + if (*speed == 0xf) {
>> + *speed = 0;
>> + pr_warn("Speed bin: Defaulting to %d\n", *speed);
>> + } else {
>> + pr_info("Speed bin: %d\n", *speed);
>> + }
>> +
>> + *pvs = (pte_efuse >> 10) & 0x7;
>> + if (*pvs == 0x7)
>> + *pvs = (pte_efuse >> 13) & 0x7;
>> +
>> + if (*pvs == 0x7) {
>> + *pvs = 0;
>> + pr_warn("PVS bin: Defaulting to %d\n", *pvs);
>> + } else {
>> + pr_info("PVS bin: %d\n", *pvs);
>> + }
>> +}
>> +
>> +static void __init get_krait_bin_format_b(int *speed, int *pvs, int *pvs_ver)
>> +{
>> + u32 pte_efuse, redundant_sel;
>> + void __iomem *base;
>> +
>> + *speed = 0;
>> + *pvs = 0;
>> + *pvs_ver = 0;
>> +
>> + base = ioremap(0xfc4b80b0, 8);
>> + if (!base) {
>> + pr_warn("Unable to read efuse data. Defaulting to 0!\n");
>> + return;
>> + }
>> +
>> + pte_efuse = readl_relaxed(base);
>> + redundant_sel = (pte_efuse >> 24) & 0x7;
>> + *speed = pte_efuse & 0x7;
>> + /* 4 bits of PVS are in efuse register bits 31, 8-6. */
>> + *pvs = ((pte_efuse >> 28) & 0x8) | ((pte_efuse >> 6) & 0x7);
>> + *pvs_ver = (pte_efuse >> 4) & 0x3;
>> +
>> + switch (redundant_sel) {
>> + case 1:
>> + *speed = (pte_efuse >> 27) & 0xf;
>> + break;
>> + case 2:
>> + *pvs = (pte_efuse >> 27) & 0xf;
>> + break;
>> + }
>> +
>> + /* Check SPEED_BIN_BLOW_STATUS */
>> + if (pte_efuse & BIT(3)) {
>> + pr_info("Speed bin: %d\n", *speed);
>> + } else {
>> + pr_warn("Speed bin not set. Defaulting to 0!\n");
>> + *speed = 0;
>> + }
>> +
>> + /* Check PVS_BLOW_STATUS */
>> + pte_efuse = readl_relaxed(base + 0x4) & BIT(21);
>> + if (pte_efuse) {
>> + pr_info("PVS bin: %d\n", *pvs);
>> + } else {
>> + pr_warn("PVS bin not set. Defaulting to 0!\n");
>> + *pvs = 0;
>> + }
>> +
>> + pr_info("PVS version: %d\n", *pvs_ver);
>> + iounmap(base);
>> +}
>> +
>> +static int __init qcom_cpufreq_populate_opps(void)
>> +{
>> + int speed, pvs, pvs_ver;
>> + struct device_node *np;
>> + struct device *dev;
>> + int cpu = 0;
>> + char pvs_name[] = "speedXX-pvsXX-vXX";
>> +
>> + np = of_find_node_by_name(NULL, "qcom,pvs");
>> + if (!np)
>> + return -ENODEV;
>> +
>> + if (of_property_read_bool(np, "qcom,pvs-format-a"))
>> + get_krait_bin_format_a(&speed, &pvs, &pvs_ver);
>> + else if (of_property_read_bool(np, "qcom,pvs-format-b"))
>> + get_krait_bin_format_b(&speed, &pvs, &pvs_ver);
>> + else
>> + return -ENODEV;
>> +
>> + snprintf(pvs_name, sizeof(pvs_name), "speed%d-pvs%d-v%d",
>> + speed, pvs, pvs_ver);
>> +
>> + for (cpu = 0; cpu < num_possible_cpus(); cpu++) {
>> + dev = get_cpu_device(cpu);
>> + if (!dev)
>> + return -ENODEV;
>> +
>> + if (IS_ERR(dev_pm_opp_set_prop_name(dev, pvs_name)))
>> + pr_warn("failed to add OPP name %s\n", pvs_name);
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int __init qcom_cpufreq_driver_init(void)
>> +{
>> + struct device *cpu_dev;
>> + struct device_node *np;
>> + int ret;
>> +
>> + cpu_dev = get_cpu_device(0);
>> + if (!cpu_dev)
>> + return -ENODEV;
>> +
>> + np = of_node_get(cpu_dev->of_node);
>> + if (!np)
>> + return -ENOENT;
>> +
>> + if (!of_device_is_compatible(np, "qcom,krait")) {
>> + of_node_put(np);
>> + return -ENODEV;
>> + }
>> + of_node_put(np);
>> +
>> + ret = qcom_cpufreq_populate_opps();
>> + if (ret)
>> + return ret;
>> +
>> + return PTR_ERR(platform_device_register_simple("cpufreq-dt",
>> + -1, NULL, 0));
>> +}
>> +module_init(qcom_cpufreq_driver_init);
>
> As there is no module exit, it doesn't make sense to keep this as
> tristate.
>
ok
> Looks mostly fine now other than these minor nits.
>
Ok, Thanks for the review. Will wait on feedback for rest of the patches
and repost with these fixed.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH net 0/3] Few mvneta fixes
From: Willy Tarreau @ 2017-12-20 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a18h_JB_P4DOFmd+v+f5KM1X9h513qUke_7nxoSJtiOUw@mail.gmail.com>
Hi Arnd,
On Tue, Dec 19, 2017 at 09:18:35PM +0100, Arnd Bergmann wrote:
> On Tue, Dec 19, 2017 at 5:59 PM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
> > Hello,
> >
> > here it is a small series of fixes found on the mvneta driver. They
> > had been already used in the vendor kernel and are now ported to
> > mainline.
>
> Does one of the patches look like it addresses the rare Oops we discussed on
> #kernelci this morning?
>
> https://storage.kernelci.org/stable/linux-4.9.y/v4.9.70/arm/mvebu_v7_defconfig/lab-free-electrons/boot-armada-375-db.html
I could be wrong but for me the 375 uses mvpp2, not mvneta, so this
should have no effect there.
Willy
^ permalink raw reply
* [PATCH] ARM: NOMMU: Setup VBAR/Hivecs for secondaries cores
From: afzal mohammed @ 2017-12-20 4:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4e80e47a-d7b4-c09c-fe88-a7dff6522038@arm.com>
Hi,
On Tue, Dec 19, 2017 at 02:44:01PM +0000, Vladimir Murzin wrote:
> > Was the issue observed on Cortex-R ?, and was it occuring with
> > CONFIG_CPU_HIGH_VECTOR enabled or disabled ?
>
> I caught it when was trying to setup VBAR and after code inspection I
> noticed that setting of Hivecs were changed as well.
Thinking again about this, should the Hivecs setting on secondary
CPU's be done (till a requirement comes) ?
ARM ARM deprecates using Hivecs setting on ARMv7-R, so this issue
might not be hit in practice for R class. While pre-ARMv7, lack of
Hivecs setting for secondaries, it seems can affect only ARMv6k
(multi-processing support added here ?) and i am making a guess that
even if there are ARMv6k with more than one core available, they might
not yet have run with MMU disabled to hit this case, probably the
reason no one has reported issue for long.
Perhaps, we can avoid configuring Hivecs for secondaries until some
one needs it ?
afzal
^ permalink raw reply
* [PATCH v2] arm64: dts: ls1088a: Add USB support
From: Yinbo Zhu @ 2017-12-20 4:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220025239.GB3766@dragon>
-----Original Message-----
From: Shawn Guo [mailto:shawnguo at kernel.org]
Sent: Wednesday, December 20, 2017 10:53 AM
To: Yinbo Zhu <yinbo.zhu@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Catalin Marinas ) <catalin.marinas@arm.com>; Will Deacon ) <will.deacon@arm.com>; Harninder Rai <harninder.rai@nxp.com>; Raghav Dogra <raghav.dogra@nxp.com>; Ashish Kumar <ashish.kumar@nxp.com>; Andy Tang <andy.tang@nxp.com>; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; linux-arm-kernel at lists.infradead.org; open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] arm64: dts: ls1088a: Add USB support
On Thu, Dec 07, 2017 at 07:33:28AM +0000, Yinbo Zhu wrote:
> Hi shawn guo,
>
> If my patch has no other issue,
> Can you help me push it to upstream.
>Are you talking about v4 patch? First of all, I cannot find v4 in my mailbox. That said, it seems you did not send
>the patch to me.
>Secondly, by checking the patch on patchwork, the usb nodes in fsl-ls1088a-rdb.dts do not sorted alphabetically
>in label name.
>Shawn
Hi shawn,
I will change the code as follows, right?
&esdhc {
status = "okay";
};
...
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
https://patchwork.kernel.org/patch/10059097/
Thanks
Yinbo.
^ permalink raw reply
* [PATCH v5 7/8] pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops
From: Keerthy @ 2017-12-20 4:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219152140.GA22971@lenoch>
On Tuesday 19 December 2017 08:51 PM, Ladislav Michl wrote:
> On Tue, Dec 19, 2017 at 01:55:48PM +0530, Keerthy wrote:
>> On Tuesday 19 December 2017 10:28 AM, Keerthy wrote:
>>> On Monday 18 December 2017 06:25 PM, Keerthy wrote:
>>>> On Monday 18 December 2017 03:01 PM, Ladislav Michl wrote:
>>>>> Keerthy,
>>>>>
>>>>> On Tue, Dec 12, 2017 at 11:42:16AM +0530, Keerthy wrote:
>>>>>> Adapt driver to utilize dmtimer pdata ops instead of pdata-quirks.
>>>>>>
>>>>>> Signed-off-by: Keerthy <j-keerthy@ti.com>
>>>>>> ---
>>>>>>
>>>>>> Changes in v4:
>>>>>>
>>>>>> * Switched to dev_get_platdata.
>>>>>
>>>>> Where do you expect dev.platform_data to be set? PWM driver is failing
>>>>> with:
>>>>> omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL
>>>>> omap-dmtimer-pwm: probe of dmtimer-pwm failed with error -22
>>>>>
>>>>> Which I fixed with patch bellow, to be able to test your patchset.
>>>>
>>>> Thanks! I will make the below patch part of my series.
>>>>
>>>>>
>>>>> Also I'm running a bit out of time, so I'll send few clean up
>>>>> patches and event capture code to get some feedback early.
>>>>>
>>>>> Regards,
>>>>> ladis
>>>>>
>>>>> diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
>>>>> index 39be39e6a8dd..d3d8a49cae0d 100644
>>>>> --- a/drivers/clocksource/timer-dm.c
>>>>> +++ b/drivers/clocksource/timer-dm.c
>>>>> @@ -773,6 +773,7 @@ static int omap_dm_timer_probe(struct platform_device *pdev)
>>>>> dev_err(dev, "%s: no platform data.\n", __func__);
>>>>> return -ENODEV;
>>>>> }
>>>>> + dev->platform_data = pdata;
>>>
>>> drivers/clocksource/timer-dm.c: In function 'omap_dm_timer_probe':
>>> drivers/clocksource/timer-dm.c:744:21: warning: assignment discards
>>> 'const' qualifier from pointer target type
>>>
>>> This cannot be done as we are assigning a const pointer to a non-const
>>> pointer.
>
> Oh, I didn't even assume it as proper fix, just to show what is missing :)
>
> But technically 'struct dmtimer_platform_data *pdata' is a constant which
> should not be changed. Also look how all that of_populate chain works -
> at the end const pointer is assigned to void* platform_data by simple
> (void *) overcast.
>
>>> I will figure out a different way for this fix.
>>
>> Ladis,
>>
>> I fixed that:
>>
>> diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
>> index 1cbd954..e58f555 100644
>> --- a/drivers/clocksource/timer-dm.c
>> +++ b/drivers/clocksource/timer-dm.c
>> @@ -807,17 +807,21 @@ static int omap_dm_timer_probe(struct
>> platform_device *pdev)
>> struct resource *mem, *irq;
>> struct device *dev = &pdev->dev;
>> const struct of_device_id *match;
>> - const struct dmtimer_platform_data *pdata;
>> + struct dmtimer_platform_data *pdata;
>> int ret;
>>
>> match = of_match_device(of_match_ptr(omap_timer_match), dev);
>> - pdata = match ? match->data : dev->platform_data;
>> + pdata = match ? (struct dmtimer_platform_data *)match->data :
>> + dev->platform_data;
>
> All that seems needlesly complicated, what about patch bellow?
>
>> if (!pdata && !dev->of_node) {
>> dev_err(dev, "%s: no platform data.\n", __func__);
>> return -ENODEV;
>> }
>>
>> + if (!dev->platform_data)
>> + dev->platform_data = pdata;
>
> Does the above condition bring us anything?
That was to avoid assigning the same thing.
>
>> irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>> if (unlikely(!irq)) {
>> dev_err(dev, "%s: no IRQ resource.\n", __func__);
>> @@ -946,7 +950,7 @@ static int omap_dm_timer_remove(struct
>> platform_device *pdev)
>> .write_status = omap_dm_timer_write_status,
>> };
>>
>> -static const struct dmtimer_platform_data omap3plus_pdata = {
>> +static struct dmtimer_platform_data omap3plus_pdata = {
>> .timer_errata = OMAP_TIMER_ERRATA_I103_I767,
>> .timer_ops = &dmtimer_ops,
>> };
>>
>> Can you check at your end if this works for you?
>
> Note, it is untested as I ran out of time and will continue after New Year.
>
> diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
> index 1cbd95420914..85024f11773a 100644
> --- a/drivers/clocksource/timer-dm.c
> +++ b/drivers/clocksource/timer-dm.c
> @@ -806,14 +806,16 @@ static int omap_dm_timer_probe(struct platform_device *pdev)
> struct omap_dm_timer *timer;
> struct resource *mem, *irq;
> struct device *dev = &pdev->dev;
> - const struct of_device_id *match;
> const struct dmtimer_platform_data *pdata;
> int ret;
>
> - match = of_match_device(of_match_ptr(omap_timer_match), dev);
> - pdata = match ? match->data : dev->platform_data;
> + pdata = of_device_get_match_data(dev);
> + if (!pdata)
> + pdata = dev_get_platdata(dev);
> + else
> + dev->platform_data = (void *) pdata;
>
> - if (!pdata && !dev->of_node) {
> + if (!pdata) {
> dev_err(dev, "%s: no platform data.\n", __func__);
> return -ENODEV;
> }
Ladis,
I have tested this on AM437 for dmtimer only. But i have checked that
pdata gets neatly assigned to dev->platform_data. So i believe that was
what was lacking. I will pick the above patch from you and post v6 with
your Tested-by as the pdata hooking was the only missing link for pwm.
Thanks for the patch once again.
Regards,
Keerthy
>
^ permalink raw reply
* [PATCH 1/4] pci: dwc: pci-dra7xx: Enable errata i870 for both EP and RC mode
From: Vignesh R @ 2017-12-20 4:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219162421.GD21501@red-moon>
On Tuesday 19 December 2017 09:54 PM, Lorenzo Pieralisi wrote:
> On Fri, Dec 01, 2017 at 11:43:08AM +0530, Vignesh R wrote:
>> Errata i870 is applicable in both EP and RC mode. Therefore rename
>> function dra7xx_pcie_ep_unaligned_memaccess(), that implements errata
>> workaround, to dra7xx_pcie_unaligned_memaccess() and call it from a
>> common place. So, that errata workaround is applied for both modes of
>> operation.
>>
>> Reported-by: Chris Welch <Chris.Welch@viavisolutions.com>
>> Signed-off-by: Vignesh R <vigneshr@ti.com>
>> ---
>>? drivers/pci/dwc/pci-dra7xx.c | 12 ++++++------
>>? 1 file changed, 6 insertions(+), 6 deletions(-)
>
> I need Kishon's ACK to apply it, thanks.
There are some enhancements to this patch. Will submit a v2 shortly.
Please ignore this version for now. Thanks!
--
Regards
Vignesh
^ permalink raw reply
* [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Timur Tabi @ 2017-12-20 4:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220022626.GH7997@codeaurora.org>
On 12/19/17 8:26 PM, Stephen Boyd wrote:
> The thing that I don't like about this patch is that we're
> modifying npins to indicate what gpios are available or not and
> then having a huge diff in this patch to do the 's/i/gpio/'.
Considering how small the driver is, I'm not sure if I'd say it's a
"huge" diff.
Frankly, I think this is a very elegant re-purposing of 'npins'.
> Ideally, everything would flow directly from the request callback
> and the SoC specific pinctrl driver would just tell the core code
> what all pins exist in hardware even if they're locked away and
> in use by something non-linux.
So you want the request callback to propagated to the SOC driver? I
guess that could work.
> That way, we don't have to rejig
> things in the SoC specific driver when the system configuration
> changes. I'm hoping we can do the valid mask part generically in
> the core pinctrl-msm.c file once so that things aren't spread
> around the SoC specific drivers and we solve ACPI and DT at the
> same time.
Well, now I'm confused. First I thought you wanted to move the valid
check into pinctrl-qdf2xxx, but now you say you want it done in
pinctrl-msm, but isn't that what my patches are doing now?
> We will want irq lines to be unallocated for things that aren't
> GPIOs, I'm not sure about ACPI and if it cares here, and we have
> a one to one mapping between irqs, GPIOs, and pinctrl pins with
> this hardware.
If the pin can't be requested, doesn't that take care of IRQ lines
automatically? I don't touch the irq_valid_mask code.
> Furthermore, we have the irq_valid_mask support in
> place already, so it seems that we can at least use the mask to
> be the one place where we indicate which pins are allowed to be
> used.
Well, I really didn't want to do that. Keep in mind that the root
problem is getting pinctrl-qdf2xxx to be able to tell pinctrl-msm what
pins are valid. That is the bulk of my code.
I'm understanding you less and less the more I read.
>And it seems like the simplest solution is to set the irq
> valid mask to be the GPIOs from the device property and then test
> that bitmask in the pinmux_ops structure's request callback so we
> cover both gpio (via the gpiochip_generic_request() ->
> pinmux_request_gpio() -> pin_request() path) and pinctrl (via the
> pin_request() path).
I do not understand that. To be honest, I think I already have the
simplest solution, at least for ACPI. I don't really want to complicate
my patches to support DT, since I don't really know what the DT-specific
problems are.
> Debugfs will need to test the mask too, but
> that should be simple. I believe you don't care about pin muxing,
> but it would make things work in both cases and will help if we
> want to limit access on platforms that use pin muxing.
I don't care about pin muxing, but my patches already take care of debugfs.
> Let's resolve this by the end of this week. If this plan works we
> can have the revert patch for get_direction() and the
> pinctrl-msm.c patch to update the valid mask on gpiochip
> registration.
Frankly, I thought I had everything resolved already, and it sounds like
you want me to start over from scratch anyway.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v6 1/5] clk: Add clock driver for ASPEED BMC SoCs
From: Joel Stanley @ 2017-12-20 3:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171128071908.12279-2-joel@jms.id.au>
On Tue, Nov 28, 2017 at 5:49 PM, Joel Stanley <joel@jms.id.au> wrote:
> This adds the stub of a driver for the ASPEED SoCs. The clocks are
> defined and the static registration is set up.
>
> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> v6:
> - Add SPDX copyright notices
> v5:
> - Add Andrew's reviewed-by
> - Make aspeed_gates not initconst to avoid section mismatch warning
> v3:
> - use named initlisers for aspeed_gates table
> - fix clocks typo
> - Move ASPEED_NUM_CLKS to the bottom of the list
> - Put gates at the start of the list, so we can use them to initalise
> the aspeed_gates table
> - Add ASPEED_CLK_SELECTION_2
> - Set parent of network MAC gates
> ---
> drivers/clk/Kconfig | 12 +++
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-aspeed.c | 139 +++++++++++++++++++++++++++++++
> include/dt-bindings/clock/aspeed-clock.h | 44 ++++++++++
> 4 files changed, 196 insertions(+)
> create mode 100644 drivers/clk/clk-aspeed.c
> create mode 100644 include/dt-bindings/clock/aspeed-clock.h
> diff --git a/include/dt-bindings/clock/aspeed-clock.h b/include/dt-bindings/clock/aspeed-clock.h
> new file mode 100644
> index 000000000000..9e170fb9a0da
> --- /dev/null
> +++ b/include/dt-bindings/clock/aspeed-clock.h
> @@ -0,0 +1,44 @@
> +/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
> +
> +#ifndef DT_BINDINGS_ASPEED_CLOCK_H
> +#define DT_BINDINGS_ASPEED_CLOCK_H
> +
> +#define ASPEED_CLK_GATE_ECLK 0
> +#define ASPEED_CLK_GATE_GCLK 1
> +#define ASPEED_CLK_GATE_MCLK 2
> +#define ASPEED_CLK_GATE_VCLK 3
> +#define ASPEED_CLK_GATE_BCLK 4
> +#define ASPEED_CLK_GATE_DCLK 5
> +#define ASPEED_CLK_GATE_REFCLK 6
> +#define ASPEED_CLK_GATE_USBPORT2CLK 7
> +#define ASPEED_CLK_GATE_LCLK 8
> +#define ASPEED_CLK_GATE_USBUHCICLK 9
> +#define ASPEED_CLK_GATE_D1CLK 10
> +#define ASPEED_CLK_GATE_YCLK 11
> +#define ASPEED_CLK_GATE_USBPORT1CLK 12
> +#define ASPEED_CLK_GATE_UART1CLK 13
> +#define ASPEED_CLK_GATE_UART2CLK 14
> +#define ASPEED_CLK_GATE_UART5CLK 15
> +#define ASPEED_CLK_GATE_ESPICLK 16
> +#define ASPEED_CLK_GATE_MAC1CLK 17
> +#define ASPEED_CLK_GATE_MAC2CLK 18
> +#define ASPEED_CLK_GATE_RSACLK 19
> +#define ASPEED_CLK_GATE_UART3CLK 20
> +#define ASPEED_CLK_GATE_UART4CLK 21
> +#define ASPEED_CLK_GATE_SDCLKCLK 22
> +#define ASPEED_CLK_GATE_LHCCLK 23
> +#define ASPEED_CLK_HPLL 24
> +#define ASPEED_CLK_AHB 25
> +#define ASPEED_CLK_APB 26
> +#define ASPEED_CLK_UART 27
> +#define ASPEED_CLK_SDIO 28
> +#define ASPEED_CLK_ECLK 29
> +#define ASPEED_CLK_ECLK_MUX 30
> +#define ASPEED_CLK_LHCLK 31
> +#define ASPEED_CLK_MAC 32
> +#define ASPEED_CLK_BCLK 33
> +#define ASPEED_CLK_MPLL 34
> +
> +#define ASPEED_NUM_CLKS 35
In reviewing this change as part of some ASPEED device tree changes,
we moved the define out of this header (as we do not want it to be
part of the ABI) and into the c file where it is used.
I have a v7 ready to send out with this change. Are there any other
issues with this before I send that version out?
Cheers,
Joel
^ permalink raw reply
* [PATCH v3 00/19] ARM: dts: aspeed: updates and new machines
From: Joel Stanley @ 2017-12-20 3:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220032328.30584-1-joel@jms.id.au>
On Wed, Dec 20, 2017 at 1:53 PM, Joel Stanley <joel@jms.id.au> wrote:
> This series of device tree patches for the ASPEED BMC machines
> moves all systems to use the soon to be merged clk driver, and
> updates machines to use all of the drivers we have upstream.
>
> v3: Address review from Rob and Cedric
> - Move aspeed-gpio.h usage out into the patches where use of the GPIO
> is added
> - Clarify that the aspeed-clock.h patch will be merged as part of
> the device tree tree. This is to ensure we don't depend on the clk
> tree for building.
Arnd, Michael, Stephen; how do we resolve this? We need the
dt-bindings header to be present for both the clk driver and the
device tree to build.
The clk driver is not (yet - soon I hope?) merged by Michael and
Stephen. I am about to commit the device tree changes that will go
through the ARM SoC tree.
Cheers,
Joel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox