* Re: [PATCH v5 05/13] soc: mediatek: cmdq: return send msg error code
From: Matthias Brugger @ 2020-05-16 17:56 UTC (permalink / raw)
To: Dennis YC Hsieh, Rob Herring, Mark Rutland, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: linux-kernel, linux-mediatek, devicetree, wsd_upstream, dri-devel,
Bibby Hsieh, CK Hu, Houlong Wei, linux-arm-kernel, HS Liao
In-Reply-To: <1583664775-19382-6-git-send-email-dennis-yc.hsieh@mediatek.com>
On 08/03/2020 11:52, Dennis YC Hsieh wrote:
> Return error code to client if send message fail,
> so that client has chance to error handling.
>
> Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
> Fixes: 576f1b4bc802 ("soc: mediatek: Add Mediatek CMDQ helper")
> Reviewed-by: CK Hu <ck.hu@mediatek.com>
Queued for v5.7-fixes
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 2e1bc513569b..98f23ba3ba47 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -351,7 +351,9 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, cmdq_async_flush_cb cb,
> spin_unlock_irqrestore(&client->lock, flags);
> }
>
> - mbox_send_message(client->chan, pkt);
> + err = mbox_send_message(client->chan, pkt);
> + if (err < 0)
> + return err;
> /* We can send next packet immediately, so just call txdone. */
> mbox_client_txdone(client->chan, 0);
>
>
^ permalink raw reply
* Re: [PATCH v2 1/7] Documentation: device-tree: sound: Update lpass-cpu driver binding
From: Ajit Pandey @ 2020-05-16 17:37 UTC (permalink / raw)
To: Mark Brown
Cc: plai, bgoswami, srinivas.kandagatla, alsa-devel, devicetree,
linux-kernel
On 5/14/2020 10:14 PM, Mark Brown wrote:
> On Thu, May 14, 2020 at 10:08:12PM +0530, Ajit Pandey wrote:
>> Done the required cleanups to update lpass-cpu binding with newer
>> yaml formats.
> Please do YAML conversions as the last thing in any patch series, there
> is quite a big backlog of reviews of YAML conversions so they can slow
> down the code development. It's good to do them, just try to make sure
> other patches don't depend on them.
>
> Please submit patches using subject lines reflecting the style for the
> subsystem, this makes it easier for people to identify relevant patches.
> Look at what existing commits in the area you're changing are doing and
> make sure your subject lines visually resemble what they're doing.
> There's no need to resubmit to fix this alone.
Ok.. we'll do the yaml conversion as a separate patch chain so that it
won't block
merging of this feature in ASoC core.
^ permalink raw reply
* Re: [PATCH v9 2/6] arm: dts: mt2701: Add usb2 device nodes
From: Matthias Brugger @ 2020-05-16 17:31 UTC (permalink / raw)
To: min.guo, Bin Liu, Rob Herring
Cc: Greg Kroah-Hartman, Mark Rutland, Alan Stern, chunfeng.yun,
linux-usb, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, tony, hdegoede
In-Reply-To: <20191211015446.11477-3-min.guo@mediatek.com>
On 11/12/2019 02:54, min.guo@mediatek.com wrote:
> From: Min Guo <min.guo@mediatek.com>
>
> Add musb nodes and usb2 phy nodes for MT2701
>
> Signed-off-by: Min Guo <min.guo@mediatek.com>
Applied now to v5.7-next/dts32
Sorry for the long delay!
> ---
> changes in v9:
> 1. Add usb-role-switch
> 2. Remove label of usb connector child node
> 3. Change usb connector child node compatible as "gpio-usb-b-connector", "usb-b-connector";
>
> changes in v8:
> 1. no changes
>
> changes in v7:
> 1. Change usb connector child node compatible as "gpio-usb-b-connector"
>
> changes in v6:
> 1. Modify usb connector child node
>
> changes in v5:
> 1. Add usb connector child node
>
> changes in v4:
> 1. no changes
>
> changes in v3:
> 1. no changes
>
> changes in v2:
> 1. Remove phy-names
> ---
> arch/arm/boot/dts/mt2701-evb.dts | 21 ++++++++++++++++++++
> arch/arm/boot/dts/mt2701.dtsi | 33 ++++++++++++++++++++++++++++++++
> 2 files changed, 54 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
> index be0edb3dae6c..844ed3f971fe 100644
> --- a/arch/arm/boot/dts/mt2701-evb.dts
> +++ b/arch/arm/boot/dts/mt2701-evb.dts
> @@ -6,6 +6,7 @@
> */
>
> /dts-v1/;
> +#include <dt-bindings/gpio/gpio.h>
> #include "mt2701.dtsi"
>
> / {
> @@ -60,6 +61,15 @@ backlight_lcd: backlight_lcd {
> >;
> default-brightness-level = <9>;
> };
> +
> + usb_vbus: regulator@0 {
> + compatible = "regulator-fixed";
> + regulator-name = "usb_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + gpio = <&pio 45 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> };
>
> &auxadc {
> @@ -229,3 +239,14 @@ pins1 {
> &uart0 {
> status = "okay";
> };
> +
> +&usb2 {
> + status = "okay";
> + usb-role-switch;
> + connector{
> + compatible = "gpio-usb-b-connector", "usb-b-connector";
> + type = "micro";
> + id-gpios = <&pio 44 GPIO_ACTIVE_HIGH>;
> + vbus-supply = <&usb_vbus>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index 180377e56ef4..a6b1434e83fb 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -670,6 +670,39 @@ u3port1: usb-phy@1a244900 {
> };
> };
>
> + usb2: usb@11200000 {
> + compatible = "mediatek,mt2701-musb",
> + "mediatek,mtk-musb";
> + reg = <0 0x11200000 0 0x1000>;
> + interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-names = "mc";
> + phys = <&u2port2 PHY_TYPE_USB2>;
> + dr_mode = "otg";
> + clocks = <&pericfg CLK_PERI_USB0>,
> + <&pericfg CLK_PERI_USB0_MCU>,
> + <&pericfg CLK_PERI_USB_SLV>;
> + clock-names = "main","mcu","univpll";
> + power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
> + status = "disabled";
> + };
> +
> + u2phy0: usb-phy@11210000 {
> + compatible = "mediatek,generic-tphy-v1";
> + reg = <0 0x11210000 0 0x0800>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + status = "okay";
> +
> + u2port2: usb-phy@1a1c4800 {
> + reg = <0 0x11210800 0 0x0100>;
> + clocks = <&topckgen CLK_TOP_USB_PHY48M>;
> + clock-names = "ref";
> + #phy-cells = <1>;
> + status = "okay";
> + };
> + };
> +
> ethsys: syscon@1b000000 {
> compatible = "mediatek,mt2701-ethsys", "syscon";
> reg = <0 0x1b000000 0 0x1000>;
>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: iio: chemical: add CO2 EZO module documentation
From: Jonathan Cameron @ 2020-05-16 16:56 UTC (permalink / raw)
To: Matt Ranostay; +Cc: linux-iio, devicetree
In-Reply-To: <20200511023214.14704-2-matt.ranostay@konsulko.com>
On Mon, 11 May 2020 05:32:13 +0300
Matt Ranostay <matt.ranostay@konsulko.com> wrote:
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
This crossed with the RTD driver, so applied with fuzz to the togreg
branch of iio.git and pushed out as testing for the autobuilders to play
with it. As ever if a DT maintainer wants to comment there is still
time to add tags (though in this case it is trivial enough I'd not waste
your time reading it!)
Jonathan
> ---
> .../devicetree/bindings/iio/chemical/atlas,sensor.yaml | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/chemical/atlas,sensor.yaml b/Documentation/devicetree/bindings/iio/chemical/atlas,sensor.yaml
> index edcd2904d50e..0d109e1b34ee 100644
> --- a/Documentation/devicetree/bindings/iio/chemical/atlas,sensor.yaml
> +++ b/Documentation/devicetree/bindings/iio/chemical/atlas,sensor.yaml
> @@ -4,19 +4,20 @@
> $id: http://devicetree.org/schemas/iio/chemical/atlas,sensor.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: Atlas Scientific OEM sensors
> +title: Atlas Scientific OEM + EZO sensors
>
> maintainers:
> - Matt Ranostay <matt.ranostay@konsulko.com>
>
> description: |
> - Atlas Scientific OEM sensors connected via I2C
> + Atlas Scientific OEM + EZO sensors connected via I2C
>
> Datasheets:
> http://www.atlas-scientific.com/_files/_datasheets/_oem/DO_oem_datasheet.pdf
> http://www.atlas-scientific.com/_files/_datasheets/_oem/EC_oem_datasheet.pdf
> http://www.atlas-scientific.com/_files/_datasheets/_oem/ORP_oem_datasheet.pdf
> http://www.atlas-scientific.com/_files/_datasheets/_oem/pH_oem_datasheet.pdf
> + http://www.atlas-scientific.com/_files/_datasheets/_probe/EZO_CO2_Datasheet.pdf
>
> properties:
> compatible:
> @@ -25,6 +26,7 @@ properties:
> - atlas,ec-sm
> - atlas,orp-sm
> - atlas,ph-sm
> + - atlas,co2-ezo
>
> reg:
> maxItems: 1
^ permalink raw reply
* Re: [PATCH v13 1/2] arm: dts: mt2712: add uart APDMA to device tree
From: Matthias Brugger @ 2020-05-16 16:52 UTC (permalink / raw)
To: Long Cheng, Vinod Koul, Randy Dunlap, Rob Herring, Mark Rutland,
Ryder Lee, Sean Wang, Nicolas Boichat
Cc: Dan Williams, Greg Kroah-Hartman, Jiri Slaby, Sean Wang,
dmaengine, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, linux-serial, srv_heupstream, Yingjoe Chen, YT Shen,
Zhenbao Liu
In-Reply-To: <1558596909-14084-2-git-send-email-long.cheng@mediatek.com>
On 23/05/2019 09:35, Long Cheng wrote:
> 1. add uart APDMA controller device node
> 2. add uart 0/1/2/3/4/5 DMA function
Due to the fact that 2/2 is not yet applied, please rephrase the commit message
and rebase on current mainline kernel.
Thanks
Matthias
>
> Signed-off-by: Long Cheng <long.cheng@mediatek.com>
> ---
> arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 51 +++++++++++++++++++++++++++++
> 1 file changed, 51 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> index 43307ba..a7a7362 100644
> --- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> @@ -300,6 +300,9 @@
> interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
> clocks = <&baud_clk>, <&sys_clk>;
> clock-names = "baud", "bus";
> + dmas = <&apdma 10
> + &apdma 11>;
> + dma-names = "tx", "rx";
> status = "disabled";
> };
>
> @@ -369,6 +372,39 @@
> (GIC_CPU_MASK_RAW(0x13) | IRQ_TYPE_LEVEL_HIGH)>;
> };
>
> + apdma: dma-controller@11000400 {
> + compatible = "mediatek,mt2712-uart-dma",
> + "mediatek,mt6577-uart-dma";
> + reg = <0 0x11000400 0 0x80>,
> + <0 0x11000480 0 0x80>,
> + <0 0x11000500 0 0x80>,
> + <0 0x11000580 0 0x80>,
> + <0 0x11000600 0 0x80>,
> + <0 0x11000680 0 0x80>,
> + <0 0x11000700 0 0x80>,
> + <0 0x11000780 0 0x80>,
> + <0 0x11000800 0 0x80>,
> + <0 0x11000880 0 0x80>,
> + <0 0x11000900 0 0x80>,
> + <0 0x11000980 0 0x80>;
> + interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 105 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 106 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 107 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 108 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 109 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 110 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 111 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 112 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 113 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 114 IRQ_TYPE_LEVEL_LOW>;
> + dma-requests = <12>;
> + clocks = <&pericfg CLK_PERI_AP_DMA>;
> + clock-names = "apdma";
> + #dma-cells = <1>;
> + };
> +
> auxadc: adc@11001000 {
> compatible = "mediatek,mt2712-auxadc";
> reg = <0 0x11001000 0 0x1000>;
> @@ -385,6 +421,9 @@
> interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_LOW>;
> clocks = <&baud_clk>, <&sys_clk>;
> clock-names = "baud", "bus";
> + dmas = <&apdma 0
> + &apdma 1>;
> + dma-names = "tx", "rx";
> status = "disabled";
> };
>
> @@ -395,6 +434,9 @@
> interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_LOW>;
> clocks = <&baud_clk>, <&sys_clk>;
> clock-names = "baud", "bus";
> + dmas = <&apdma 2
> + &apdma 3>;
> + dma-names = "tx", "rx";
> status = "disabled";
> };
>
> @@ -405,6 +447,9 @@
> interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_LOW>;
> clocks = <&baud_clk>, <&sys_clk>;
> clock-names = "baud", "bus";
> + dmas = <&apdma 4
> + &apdma 5>;
> + dma-names = "tx", "rx";
> status = "disabled";
> };
>
> @@ -415,6 +460,9 @@
> interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_LOW>;
> clocks = <&baud_clk>, <&sys_clk>;
> clock-names = "baud", "bus";
> + dmas = <&apdma 6
> + &apdma 7>;
> + dma-names = "tx", "rx";
> status = "disabled";
> };
>
> @@ -629,6 +677,9 @@
> interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_LOW>;
> clocks = <&baud_clk>, <&sys_clk>;
> clock-names = "baud", "bus";
> + dmas = <&apdma 8
> + &apdma 9>;
> + dma-names = "tx", "rx";
> status = "disabled";
> };
>
>
^ permalink raw reply
* Re: [PATCH v14 0/2] iio: proximity: driver for vcnl3020
From: Jonathan Cameron @ 2020-05-16 16:41 UTC (permalink / raw)
To: Ivan Mikhaylov
Cc: Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
linux-iio, linux-kernel, devicetree, Mark Rutland, Rob Herring,
Andy Shevchenko
In-Reply-To: <20200510184537.10335-1-i.mikhaylov@yadro.com>
On Sun, 10 May 2020 21:45:35 +0300
Ivan Mikhaylov <i.mikhaylov@yadro.com> wrote:
> Add proximity sensor driver for Vishay vcnl3020. Only on-demand
> measurement is supported for now.
Hi Ivan,
Great and thanks for your persistence on this driver!
All looks good to me.
I will give time or a dt-bindings review as so far only
Rob's bot as commented. The look fine to me but as Rob
can certify I'm not very good at reviewing those things!
Thanks,
Jonathan
>
> Changes from v13:
> 1. description change for LED current.
>
> Changes from v12:
> 1. forgot to change path inside yaml.
>
> Changes from v11:
> 1. minor changes to yaml.
>
> Changes from v10:
> 1. add vcnl3020_property struct for optional properties.
>
> Changes from v9:
> 1. minor changes.
> 2. pass microamps from dts, not register value.
>
> Changes from v8:
> 1. add vcnl3020 prefix into get_and_apply_property function.
> 2. add bsd license into yaml.
> 3. vishay,led-current-milliamp -> vishay,led-current-microamp.
> 4. add default value into vishay,led-current-microamp and change
> register values into microamps.
>
> Changes from v7:
> 1. forgot to add Reviewed-by tag.
>
> Changes from v6:
> 1. minor changes
> 1.1 remove VCNL_DRV_NAME
> 1.2 add braces in get_and_apply_property
>
> Changes from v5:
> 1. add get_and_apply_property function for optional parameters.
> 2. minor changes.
>
> Changes from v4:
> 1. add vdd-supply,vddio-supply,interrupts properties into yaml.
> 2. led-current -> vishay,led-current-milliamp in yaml.
> 3. add possible values enum list.
> 4. add bulk_read for result hi/lo registers.
> 5. add description of vcnl3020_data structure.
> 6. vcnl3020 id table is removed.
> 7. make "vishay,led-current-milliamp" optional in yaml and code.
>
> Changes from v3:
> 1. minor changes.
> 2. add i2c block to fix dts section in yaml.
>
> Changes from v2:
> 1. using regmap_read_poll_timeout instead of do-while in measurement
> function.
> 2. change struct i2client* in vcnl3020_data to struct dev*
> 3. enable REGMAP_I2C in Kconfig
>
> Changes from v1:
> 1. using regmap interface instead of i2c_smbus_* calls.
> 2. switch from probe to probe_new.
> 3. s32/int32_t -> int
>
> Ivan Mikhaylov (2):
> dt-bindings: proximity: provide vcnl3020 device tree binding document
> iio: proximity: Add driver support for vcnl3020 proximity sensor
>
> .../iio/proximity/vishay,vcnl3020.yaml | 62 +++++
> drivers/iio/proximity/Kconfig | 11 +
> drivers/iio/proximity/Makefile | 1 +
> drivers/iio/proximity/vcnl3020.c | 258 ++++++++++++++++++
> 4 files changed, 332 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/proximity/vishay,vcnl3020.yaml
> create mode 100644 drivers/iio/proximity/vcnl3020.c
>
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: gpu: mali-utgard: add mediatek, mt7623-mali compatible
From: Matthias Brugger @ 2020-05-16 16:22 UTC (permalink / raw)
To: ryder.lee, Rob Herring
Cc: Weijie Gao, Sean Wang, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ryder Lee
In-Reply-To: <efeadefe3895bcadf1d2e9847b82206dd8c7ec35.1563867856.git.ryder.lee@mediatek.com>
On 24/07/2019 11:01, ryder.lee@kernel.org wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> The MediaTek MT7623 SoC contains a Mali-450, so add a compatible for it
> and define its own vendor-specific properties.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
I ported the changes to the new yaml file and applied them to v5.7-next/dts32
Thanks
> ---
> Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> index ae63f09fda7d..73021e2dda25 100644
> --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
> @@ -17,6 +17,7 @@ Required properties:
> + amlogic,meson8b-mali
> + amlogic,meson-gxbb-mali
> + amlogic,meson-gxl-mali
> + + mediatek,mt7623-mali
> + rockchip,rk3036-mali
> + rockchip,rk3066-mali
> + rockchip,rk3188-mali
> @@ -88,6 +89,10 @@ to specify one more vendor-specific compatible, among:
> Required properties:
> * resets: phandle to the reset line for the GPU
>
> + - mediatek,mt7623-mali
> + Required properties:
> + * resets: phandle to the reset line for the GPU
> +
> - Rockchip variants:
> Required properties:
> * resets: phandle to the reset line for the GPU
>
^ permalink raw reply
* Re: [PATCH 1/2] arm: dts: mt7623: add Mali-450 device node
From: Matthias Brugger @ 2020-05-16 16:22 UTC (permalink / raw)
To: ryder.lee, Rob Herring
Cc: Weijie Gao, Sean Wang, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Ryder Lee
In-Reply-To: <af7b5a2e00eb3a4b6262807c378e43afd5f74779.1563867856.git.ryder.lee@mediatek.com>
On 24/07/2019 11:00, ryder.lee@kernel.org wrote:
> From: Ryder Lee <ryder.lee@mediatek.com>
>
> Add a node for Mali-450.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Applied to v5.7-next/dts32
> ---
> kmscube as well as X11 EGL tests work fine (use Lima driver).
> ---
> arch/arm/boot/dts/mt7623.dtsi | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
> index a79f0b6c3429..6a9c5afb9a36 100644
> --- a/arch/arm/boot/dts/mt7623.dtsi
> +++ b/arch/arm/boot/dts/mt7623.dtsi
> @@ -3,6 +3,7 @@
> * Copyright (c) 2017-2018 MediaTek Inc.
> * Author: John Crispin <john@phrozen.org>
> * Sean Wang <sean.wang@mediatek.com>
> + * Ryder Lee <ryder.lee@mediatek.com>
> *
> */
>
> @@ -733,6 +734,30 @@
> #reset-cells = <1>;
> };
>
> + mali: gpu@13040000 {
> + compatible = "mediatek,mt7623-mali", "arm,mali-450";
> + reg = <0 0x13040000 0 0x30000>;
> + interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 171 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 172 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 173 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 174 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 175 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 176 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 177 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 178 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 179 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 180 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-names = "gp", "gpmmu", "pp0", "ppmmu0", "pp1",
> + "ppmmu1", "pp2", "ppmmu2", "pp3", "ppmmu3",
> + "pp";
> + clocks = <&topckgen CLK_TOP_MMPLL>,
> + <&g3dsys CLK_G3DSYS_CORE>;
> + clock-names = "bus", "core";
> + power-domains = <&scpsys MT2701_POWER_DOMAIN_MFG>;
> + resets = <&g3dsys MT2701_G3DSYS_CORE_RST>;
> + };
> +
> mmsys: syscon@14000000 {
> compatible = "mediatek,mt7623-mmsys",
> "mediatek,mt2701-mmsys",
>
^ permalink raw reply
* Re: [PATCH v5 03/13] mailbox: cmdq: support mt6779 gce platform definition
From: Matthias Brugger @ 2020-05-16 16:10 UTC (permalink / raw)
To: Dennis YC Hsieh, Rob Herring, Mark Rutland, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: linux-kernel, linux-mediatek, devicetree, wsd_upstream, dri-devel,
Bibby Hsieh, CK Hu, Houlong Wei, linux-arm-kernel, HS Liao
In-Reply-To: <1583664775-19382-4-git-send-email-dennis-yc.hsieh@mediatek.com>
On 08/03/2020 11:52, Dennis YC Hsieh wrote:
> Add gce v4 hardware support with different thread number and shift.
>
> Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
> Reviewed-by: CK Hu <ck.hu@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
> ---
> drivers/mailbox/mtk-cmdq-mailbox.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
> index 4dbee9258127..9994ac9426d6 100644
> --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> @@ -572,10 +572,12 @@ static const struct dev_pm_ops cmdq_pm_ops = {
>
> static const struct gce_plat gce_plat_v2 = {.thread_nr = 16};
> static const struct gce_plat gce_plat_v3 = {.thread_nr = 24};
> +static const struct gce_plat gce_plat_v4 = {.thread_nr = 24, .shift = 3};
>
> static const struct of_device_id cmdq_of_ids[] = {
> {.compatible = "mediatek,mt8173-gce", .data = (void *)&gce_plat_v2},
> {.compatible = "mediatek,mt8183-gce", .data = (void *)&gce_plat_v3},
> + {.compatible = "mediatek,mt6779-gce", .data = (void *)&gce_plat_v4},
> {}
> };
>
>
^ permalink raw reply
* Re: [RESEND,v2,1/1] arm: dts: mediatek: add mt7629 pwm support
From: Matthias Brugger @ 2020-05-16 15:37 UTC (permalink / raw)
To: Sam Shih, Rob Herring, Mark Rutland
Cc: devicetree, linux-arm-kernel, linux-kernel, linux-mediatek
In-Reply-To: <1581474926-28633-2-git-send-email-sam.shih@mediatek.com>
On 12/02/2020 03:35, Sam Shih wrote:
> This adds pwm support for MT7629.
> Used:
> https://patchwork.kernel.org/patch/11160851/
>
> Change since v1:
> remove unused property num-pwm
>
> Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Applied now to v5.7-next/dts32
Thanks!
> ---
> arch/arm/boot/dts/mt7629.dtsi | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mt7629.dtsi b/arch/arm/boot/dts/mt7629.dtsi
> index 867b88103b9d..ce2a30a24017 100644
> --- a/arch/arm/boot/dts/mt7629.dtsi
> +++ b/arch/arm/boot/dts/mt7629.dtsi
> @@ -241,6 +241,20 @@
> status = "disabled";
> };
>
> + pwm: pwm@11006000 {
> + compatible = "mediatek,mt7629-pwm";
> + reg = <0x11006000 0x1000>;
> + interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&topckgen CLK_TOP_PWM_SEL>,
> + <&pericfg CLK_PERI_PWM_PD>,
> + <&pericfg CLK_PERI_PWM1_PD>;
> + clock-names = "top", "main", "pwm1";
> + assigned-clocks = <&topckgen CLK_TOP_PWM_SEL>;
> + assigned-clock-parents =
> + <&topckgen CLK_TOP_UNIVPLL2_D4>;
> + status = "disabled";
> + };
> +
> i2c: i2c@11007000 {
> compatible = "mediatek,mt7629-i2c",
> "mediatek,mt2712-i2c";
>
^ permalink raw reply
* Re: [RESEND PATCH v5 11/11] arm64: dts: mt2712: use non-empty ranges for usb-phy
From: Matthias Brugger @ 2020-05-16 15:35 UTC (permalink / raw)
To: Chunfeng Yun, Kishon Vijay Abraham I
Cc: Rob Herring, Mark Rutland, linux-arm-kernel, linux-mediatek,
linux-kernel, devicetree
In-Reply-To: <0b039294697126edb25a699b8c25b7fcc84eed36.1581389234.git.chunfeng.yun@mediatek.com>
On 11/02/2020 04:21, Chunfeng Yun wrote:
> Use non-empty ranges for usb-phy to make the layout of
> its registers clearer;
> Replace deprecated compatible by generic
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
queued for v5.7-next/dts64
Thanks a lot
> ---
> v3~v5: no changes
>
> v2: use generic compatible
> ---
> arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 42 ++++++++++++-----------
> 1 file changed, 22 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> index 43307bad3f0d..e24f2f2f6004 100644
> --- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> @@ -697,30 +697,31 @@ usb_host0: xhci@11270000 {
> };
>
> u3phy0: usb-phy@11290000 {
> - compatible = "mediatek,mt2712-u3phy";
> - #address-cells = <2>;
> - #size-cells = <2>;
> - ranges;
> + compatible = "mediatek,mt2712-tphy",
> + "mediatek,generic-tphy-v2";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0 0x11290000 0x9000>;
> status = "okay";
>
> - u2port0: usb-phy@11290000 {
> - reg = <0 0x11290000 0 0x700>;
> + u2port0: usb-phy@0 {
> + reg = <0x0 0x700>;
> clocks = <&clk26m>;
> clock-names = "ref";
> #phy-cells = <1>;
> status = "okay";
> };
>
> - u2port1: usb-phy@11298000 {
> - reg = <0 0x11298000 0 0x700>;
> + u2port1: usb-phy@8000 {
> + reg = <0x8000 0x700>;
> clocks = <&clk26m>;
> clock-names = "ref";
> #phy-cells = <1>;
> status = "okay";
> };
>
> - u3port0: usb-phy@11298700 {
> - reg = <0 0x11298700 0 0x900>;
> + u3port0: usb-phy@8700 {
> + reg = <0x8700 0x900>;
> clocks = <&clk26m>;
> clock-names = "ref";
> #phy-cells = <1>;
> @@ -760,30 +761,31 @@ usb_host1: xhci@112c0000 {
> };
>
> u3phy1: usb-phy@112e0000 {
> - compatible = "mediatek,mt2712-u3phy";
> - #address-cells = <2>;
> - #size-cells = <2>;
> - ranges;
> + compatible = "mediatek,mt2712-tphy",
> + "mediatek,generic-tphy-v2";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0 0x112e0000 0x9000>;
> status = "okay";
>
> - u2port2: usb-phy@112e0000 {
> - reg = <0 0x112e0000 0 0x700>;
> + u2port2: usb-phy@0 {
> + reg = <0x0 0x700>;
> clocks = <&clk26m>;
> clock-names = "ref";
> #phy-cells = <1>;
> status = "okay";
> };
>
> - u2port3: usb-phy@112e8000 {
> - reg = <0 0x112e8000 0 0x700>;
> + u2port3: usb-phy@8000 {
> + reg = <0x8000 0x700>;
> clocks = <&clk26m>;
> clock-names = "ref";
> #phy-cells = <1>;
> status = "okay";
> };
>
> - u3port1: usb-phy@112e8700 {
> - reg = <0 0x112e8700 0 0x900>;
> + u3port1: usb-phy@8700 {
> + reg = <0x8700 0x900>;
> clocks = <&clk26m>;
> clock-names = "ref";
> #phy-cells = <1>;
>
^ permalink raw reply
* Re: [PATCH v13 5/6] rtc: mt6397: Add support for the MediaTek MT6358 RTC
From: Matthias Brugger @ 2020-05-16 15:25 UTC (permalink / raw)
To: Hsin-Hsiung Wang, Lee Jones, Rob Herring, Alexandre Belloni
Cc: drinkcat, Sean Wang, Sebastian Reichel, Eddie Huang,
Alessandro Zummo, Frank Wunderlich, Josef Friedl, Richard Fontana,
Thomas Gleixner, Ran Bi, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, linux-pm, linux-rtc, srv_heupstream
In-Reply-To: <1587438012-24832-6-git-send-email-hsin-hsiung.wang@mediatek.com>
Hi Lee,
On 21/04/2020 05:00, Hsin-Hsiung Wang wrote:
> From: Ran Bi <ran.bi@mediatek.com>
>
> This add support for the MediaTek MT6358 RTC. Driver using
> compatible data to store different RTC_WRTGR address offset.
> This replace RTC_WRTGR to RTC_WRTGR_MT6323 in mt6323-poweroff
> driver which only needed by armv7 CPU without ATF.
>
> Signed-off-by: Ran Bi <ran.bi@mediatek.com>
> Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Acked-by: Sebastian Reichel <sre@kernel.org>
> Reviewed-by: Yingjoe Chen <yingjoe.chen@mediatek.com>
We have Acked-by from rtc and reset drivers maintainers. Are you OK to take them
through your mfd branch?
Are you planning to queue them for v5.8?
Just asking because if so I'd queue patch 6 through my tree.
Regards,
Matthias
> ---
> drivers/power/reset/mt6323-poweroff.c | 2 +-
> drivers/rtc/rtc-mt6397.c | 18 +++++++++++++++---
> include/linux/mfd/mt6397/rtc.h | 9 ++++++++-
> 3 files changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/power/reset/mt6323-poweroff.c b/drivers/power/reset/mt6323-poweroff.c
> index 1caf43d..0532803 100644
> --- a/drivers/power/reset/mt6323-poweroff.c
> +++ b/drivers/power/reset/mt6323-poweroff.c
> @@ -30,7 +30,7 @@ static void mt6323_do_pwroff(void)
> int ret;
>
> regmap_write(pwrc->regmap, pwrc->base + RTC_BBPU, RTC_BBPU_KEY);
> - regmap_write(pwrc->regmap, pwrc->base + RTC_WRTGR, 1);
> + regmap_write(pwrc->regmap, pwrc->base + RTC_WRTGR_MT6323, 1);
>
> ret = regmap_read_poll_timeout(pwrc->regmap,
> pwrc->base + RTC_BBPU, val,
> diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
> index cda238d..f8b1353 100644
> --- a/drivers/rtc/rtc-mt6397.c
> +++ b/drivers/rtc/rtc-mt6397.c
> @@ -9,6 +9,7 @@
> #include <linux/mfd/mt6397/core.h>
> #include <linux/module.h>
> #include <linux/mutex.h>
> +#include <linux/of_device.h>
> #include <linux/platform_device.h>
> #include <linux/regmap.h>
> #include <linux/rtc.h>
> @@ -20,7 +21,7 @@ static int mtk_rtc_write_trigger(struct mt6397_rtc *rtc)
> int ret;
> u32 data;
>
> - ret = regmap_write(rtc->regmap, rtc->addr_base + RTC_WRTGR, 1);
> + ret = regmap_write(rtc->regmap, rtc->addr_base + rtc->data->wrtgr, 1);
> if (ret < 0)
> return ret;
>
> @@ -269,6 +270,8 @@ static int mtk_rtc_probe(struct platform_device *pdev)
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> rtc->addr_base = res->start;
>
> + rtc->data = of_device_get_match_data(&pdev->dev);
> +
> rtc->irq = platform_get_irq(pdev, 0);
> if (rtc->irq < 0)
> return rtc->irq;
> @@ -325,9 +328,18 @@ static int mt6397_rtc_resume(struct device *dev)
> static SIMPLE_DEV_PM_OPS(mt6397_pm_ops, mt6397_rtc_suspend,
> mt6397_rtc_resume);
>
> +static const struct mtk_rtc_data mt6358_rtc_data = {
> + .wrtgr = RTC_WRTGR_MT6358,
> +};
> +
> +static const struct mtk_rtc_data mt6397_rtc_data = {
> + .wrtgr = RTC_WRTGR_MT6397,
> +};
> +
> static const struct of_device_id mt6397_rtc_of_match[] = {
> - { .compatible = "mediatek,mt6323-rtc", },
> - { .compatible = "mediatek,mt6397-rtc", },
> + { .compatible = "mediatek,mt6323-rtc", .data = &mt6397_rtc_data },
> + { .compatible = "mediatek,mt6358-rtc", .data = &mt6358_rtc_data },
> + { .compatible = "mediatek,mt6397-rtc", .data = &mt6397_rtc_data },
> { }
> };
> MODULE_DEVICE_TABLE(of, mt6397_rtc_of_match);
> diff --git a/include/linux/mfd/mt6397/rtc.h b/include/linux/mfd/mt6397/rtc.h
> index 7dfb63b..66989a1 100644
> --- a/include/linux/mfd/mt6397/rtc.h
> +++ b/include/linux/mfd/mt6397/rtc.h
> @@ -18,7 +18,9 @@
> #define RTC_BBPU_CBUSY BIT(6)
> #define RTC_BBPU_KEY (0x43 << 8)
>
> -#define RTC_WRTGR 0x003c
> +#define RTC_WRTGR_MT6358 0x003a
> +#define RTC_WRTGR_MT6397 0x003c
> +#define RTC_WRTGR_MT6323 RTC_WRTGR_MT6397
>
> #define RTC_IRQ_STA 0x0002
> #define RTC_IRQ_STA_AL BIT(0)
> @@ -65,6 +67,10 @@
> #define MTK_RTC_POLL_DELAY_US 10
> #define MTK_RTC_POLL_TIMEOUT (jiffies_to_usecs(HZ))
>
> +struct mtk_rtc_data {
> + u32 wrtgr;
> +};
> +
> struct mt6397_rtc {
> struct device *dev;
> struct rtc_device *rtc_dev;
> @@ -74,6 +80,7 @@ struct mt6397_rtc {
> struct regmap *regmap;
> int irq;
> u32 addr_base;
> + const struct mtk_rtc_data *data;
> };
>
> #endif /* _LINUX_MFD_MT6397_RTC_H_ */
>
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: mt8173: fix mdp aliases property name
From: Matthias Brugger @ 2020-05-16 15:09 UTC (permalink / raw)
To: Hans Verkuil, Hsin-Yi Wang, linux-arm-kernel, linux-mediatek
Cc: Minghsiu Tsai, Houlong Wei, Andrew-CT Chen, Mauro Carvalho Chehab,
linux-media, linux-kernel, Rob Herring, devicetree
In-Reply-To: <4e335bc7-a45d-4688-a578-1e9793a61229@xs4all.nl>
On 16/04/2020 10:41, Hans Verkuil wrote:
> On 14/04/2020 05:08, Hsin-Yi Wang wrote:
>> Fix warning:
>> Warning (alias_paths): /aliases: aliases property name must include only lowercase and '-'
>>
>> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
>> ---
>> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 16 ++++++++--------
>> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> I'll merge patch 2/2 for 5.8. I assume that this dtsi patch is merged through
> a mediatek subsystem?
>
Correct. Now queued in v5.7-next/dts64
Thanks!
> Regards,
>
> Hans
>
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> index a212bf124e81..d1e9c41004b4 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> @@ -42,14 +42,14 @@ aliases {
>> dpi0 = &dpi0;
>> dsi0 = &dsi0;
>> dsi1 = &dsi1;
>> - mdp_rdma0 = &mdp_rdma0;
>> - mdp_rdma1 = &mdp_rdma1;
>> - mdp_rsz0 = &mdp_rsz0;
>> - mdp_rsz1 = &mdp_rsz1;
>> - mdp_rsz2 = &mdp_rsz2;
>> - mdp_wdma0 = &mdp_wdma0;
>> - mdp_wrot0 = &mdp_wrot0;
>> - mdp_wrot1 = &mdp_wrot1;
>> + mdp-rdma0 = &mdp_rdma0;
>> + mdp-rdma1 = &mdp_rdma1;
>> + mdp-rsz0 = &mdp_rsz0;
>> + mdp-rsz1 = &mdp_rsz1;
>> + mdp-rsz2 = &mdp_rsz2;
>> + mdp-wdma0 = &mdp_wdma0;
>> + mdp-wrot0 = &mdp_wrot0;
>> + mdp-wrot1 = &mdp_wrot1;
>> serial0 = &uart0;
>> serial1 = &uart1;
>> serial2 = &uart2;
>>
>
^ permalink raw reply
* Re: [PATCH 0/4] Add I2C controller support for MT6797 SoC
From: Matthias Brugger @ 2020-05-16 15:05 UTC (permalink / raw)
To: Manivannan Sadhasivam, robh+dt
Cc: devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
adamboardman
In-Reply-To: <20200222162444.11590-1-manivannan.sadhasivam@linaro.org>
On 22/02/2020 17:24, Manivannan Sadhasivam wrote:
> Hello,
>
> This patchset adds I2C controller support for Mediatek MT6797 SoC. There
> are a total of 8 I2C controllers in this SoC (2 being shared) and they are
> same as the controllers present in MT6577 SoC. Hence, the driver support is
> added with DT fallback method.
>
> As per the datasheet, there are controllers with _imm prefix like i2c2_imm
> and i2c3_imm. These appears to be in different memory regions but sharing
> the same pins with i2c2 and i2c3 respectively. Since there is no clear
> evidence of what they really are, I've adapted the numbering/naming scheme
> from the downstream code by Mediatek.
>
> This patchset has been tested on 96Boards X20 development board.
>
> Thanks,
> Mani
>
> Manivannan Sadhasivam (4):
> dt-bindings: i2c: Document I2C controller binding for MT6797 SoC
> arm64: dts: mediatek: Add I2C support for MT6797 SoC
> arm64: dts: mediatek: Enable I2C support for 96Boards X20 Development
> board
> arm64: dts: mediatek: Switch to SPDX license identifier for MT6797 SoC
All four queued now in v5.7-next/dts64
Thanks!
>
> .../devicetree/bindings/i2c/i2c-mt65xx.txt | 1 +
> .../boot/dts/mediatek/mt6797-x20-dev.dts | 49 ++++
> arch/arm64/boot/dts/mediatek/mt6797.dtsi | 229 +++++++++++++++++-
> 3 files changed, 271 insertions(+), 8 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: i2c: Document I2C controller binding for MT6797 SoC
From: Matthias Brugger @ 2020-05-16 15:05 UTC (permalink / raw)
To: Wolfram Sang
Cc: Rob Herring, Manivannan Sadhasivam, robh+dt, devicetree,
linux-arm-kernel, linux-mediatek, linux-kernel, adamboardman
In-Reply-To: <20200515165605.GA19423@ninjato>
On 15/05/2020 18:56, Wolfram Sang wrote:
> On Fri, May 15, 2020 at 04:48:28PM +0200, Matthias Brugger wrote:
>> Hi Wolfram,
>>
>> On 26/02/2020 23:23, Rob Herring wrote:
>>> On Sat, 22 Feb 2020 21:54:41 +0530, Manivannan Sadhasivam wrote:
>>>> I2C controller driver for MT6577 SoC is reused for MT6797 SoC.
>>>> Hence, document that in DT binding.
>>>>
>>>> Signed-off-by: Manivannan Sadhasivam
>>>> <manivannan.sadhasivam@linaro.org> ---
>>>> Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt | 1 + 1 file
>>>> changed, 1 insertion(+)
>>>>
>>>
>>> Acked-by: Rob Herring <robh@kernel.org>
>>>
>>
>> Do you want to take this thorough your tree or are you OK if I take it
>> thorough mine?
>
> The I2C list is neither in the CC field, nor is the patch in patchwork.
Right didn't check that.
> I suggest you take it.
>
> Acked-by: Wolfram Sang <wsa@kernel.org>
>
Thanks Wolfram.
Now queued in v5.7-next/dts64
^ permalink raw reply
* Re: [PATCH v2 4/7] dt-bindings: iio: accel: Add required regulators to bma180
From: Jonathan Cameron @ 2020-05-16 15:03 UTC (permalink / raw)
To: Jonathan Bakker
Cc: knaack.h, lars, pmeerw, robh+dt, linus.walleij, kstewart, tglx,
linux-iio, devicetree, linux-kernel, Rob Herring
In-Reply-To: <BN6PR04MB066073FD4A47219484D9C258A3BC0@BN6PR04MB0660.namprd04.prod.outlook.com>
On Thu, 14 May 2020 13:48:58 -0700
Jonathan Bakker <xc-racer2@live.ca> wrote:
> The bma180 and related chips should have two registers attached to
registers-> regulators.
I'll fix that up.
J
> them. The IIO driver currently uses them, document them here as
> well.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
> ---
> Changes from v1
> - Added A-b and R-b tags
> ---
> Documentation/devicetree/bindings/iio/accel/bma180.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt b/Documentation/devicetree/bindings/iio/accel/bma180.txt
> index cfbfc6276b3c..33da4a6fdb39 100644
> --- a/Documentation/devicetree/bindings/iio/accel/bma180.txt
> +++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
> @@ -14,6 +14,8 @@ Required properties:
> "bosch,bma254"
> "bosch,smb380"
> - reg : the I2C address of the sensor
> + - vdd-supply : regulator phandle connected to the VDD pin
> + - vddio-supply : regulator phandle connected to the VDDIO pin
>
> Optional properties:
>
^ permalink raw reply
* Re: [PATCH 0/2] iio: adc: Add a current from voltage driver
From: Jonathan Bakker @ 2020-05-16 15:01 UTC (permalink / raw)
To: Lars-Peter Clausen, jic23, knaack.h, pmeerw, robh+dt, linux-iio,
linux-kernel, devicetree
Cc: linus.walleij
In-Reply-To: <d5f785bf-15f5-9ca5-f7f8-863c74447010@metafoo.de>
Oops, sorry about that, you're absolutely right. The current-sense-shunt part
of iio-rescale is exactly what I was looking for.
Thanks,
Jonathan
On 2020-05-15 11:28 p.m., Lars-Peter Clausen wrote:
> On 5/16/20 4:26 AM, Jonathan Bakker wrote:
>> In the discussion around adding the GP2A002 light driver, there came
>> up the question of what to do when a system emulates a current ADC
>> by using a voltage ADC and a resistor. Rather than adding it on
>> a per-driver basis, it was suggested(1) to add a minimal IIO driver
>> to support this situation.
>>
>> The new driver is fairly simple - it simply takes a voltage ADC and
>> a resistor value in ohms exposed as the scale and outputs a current.
>>
>> It has been tested on a first-gen Galaxy S device which has the above
>> mentioned GP2A002 chip connected to the voltage ADC resistor complex.
>>
>> 1) https://lore.kernel.org/linux-iio/20200202150843.762c6897@archlinux/
>
> Hi,
>
> There is afe/iio-rescale.c, which I think already implements this functionality.
>
> - Lars
>
>
^ permalink raw reply
* Re: [PATCH v2 05/19] spi: dw: Enable interrupts in accordance with DMA xfer mode
From: Serge Semin @ 2020-05-16 14:06 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Serge Semin, Mark Brown, Georgy Vlasov, Ramil Zaripov,
Alexey Malahov, Thomas Bogendoerfer, Paul Burton, Ralf Baechle,
Arnd Bergmann, Allison Randal, Gareth Williams, Rob Herring,
linux-mips, devicetree, Jarkko Nikula, Thomas Gleixner,
Wan Ahmad Zainie, linux-spi, linux-kernel
In-Reply-To: <20200515122700.GY185537@smile.fi.intel.com>
On Fri, May 15, 2020 at 03:27:00PM +0300, Andy Shevchenko wrote:
> On Fri, May 15, 2020 at 01:47:44PM +0300, Serge Semin wrote:
> > It's pointless to track the Tx overrun interrupts if Rx-only SPI
> > transfer is issued. Similarly there is no need in handling the Rx
> > overrun/underrun interrupts if Tx-only SPI transfer is executed.
> > So lets unmask the interrupts only if corresponding SPI
> > transactions are implied.
>
> My comments below.
>
> > Co-developed-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
> > Signed-off-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
> > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > Cc: Paul Burton <paulburton@kernel.org>
> > Cc: Ralf Baechle <ralf@linux-mips.org>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Allison Randal <allison@lohutok.net>
> > Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Cc: Gareth Williams <gareth.williams.jx@renesas.com>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: linux-mips@vger.kernel.org
> > Cc: devicetree@vger.kernel.org
>
> I think you really need to revisit Cc list in all patches (DT people hardly
> interested in this one, though ones where properties are being used might be
> point of interest).
>
> ...
>
> > /* Set the interrupt mask */
> > - spi_umask_intr(dws, SPI_INT_TXOI | SPI_INT_RXUI | SPI_INT_RXOI);
> > + spi_umask_intr(dws, imr);
>
> Can we rather do like this
>
> /* Set the interrupt mask */
> if (xfer->tx_buf)
> imr |= SPI_INT_TXOI;
> if (xfer->rx_buf)
> imr |= SPI_INT_RXUI | SPI_INT_RXOI;
> spi_umask_intr(dws, imr);
>
> ?
>
> (First block sets DMA, second one IRQ)
I'd rather leave it as is.
-Sergey
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: power: reset: Unrequire regmap property in syscon-reboot node
From: Serge Semin @ 2020-05-16 13:26 UTC (permalink / raw)
To: Rob Herring, Sebastian Reichel
Cc: Serge Semin, Ralf Baechle, linux-mips, Allison Randal,
Kate Stewart, Thomas Bogendoerfer, linux-kernel,
Krzysztof Kozlowski, Jonathan Cameron, Arnd Bergmann,
Alexandre Belloni, Paul Burton, linux-pm, devicetree,
Richard Fontana, Thomas Gleixner, Rob Herring, Alexey Malahov
In-Reply-To: <20200515031449.GA32456@bogus>
On Thu, May 14, 2020 at 10:14:49PM -0500, Rob Herring wrote:
> On Fri, 8 May 2020 02:38:45 +0300, Serge Semin wrote:
> > Since normally syscon-reboot block is supposed to be a part of a system
> > controller, lets mark the regmap property as deprecated and recommend the
> > syscon-reboot node to be a sub-node of SYSCON.
> >
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > Cc: Paul Burton <paulburton@kernel.org>
> > Cc: Ralf Baechle <ralf@linux-mips.org>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Allison Randal <allison@lohutok.net>
> > Cc: Richard Fontana <rfontana@redhat.com>
> > Cc: Kate Stewart <kstewart@linuxfoundation.org>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: linux-mips@vger.kernel.org
> >
> > ---
> >
> > Changelog v2:
> > - This is a new patch created as a result of the discussion:
> > https://lore.kernel.org/linux-pm/20200306130402.1F4F0803079F@mail.baikalelectronics.ru/
> > ---
> > .../bindings/power/reset/syscon-reboot.yaml | 15 ++++++++++-----
> > 1 file changed, 10 insertions(+), 5 deletions(-)
> >
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Great. Thanks!
Sebastian, Rob is ok with the change. Could you take a look at the next patch?
-Sergey
^ permalink raw reply
* Re: [PATCH v10 2/3] mfd: add Gateworks System Controller core driver
From: kbuild test robot @ 2020-05-16 13:14 UTC (permalink / raw)
To: Tim Harvey, Lee Jones, Jean Delvare, Guenter Roeck, linux-hwmon,
Rob Herring, Frank Rowand, devicetree, linux-kernel, Robert Jones
Cc: kbuild-all, Tim Harvey
In-Reply-To: <1589555891-16502-3-git-send-email-tharvey@gateworks.com>
[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]
Hi Tim,
I love your patch! Yet something to improve:
[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on hwmon/hwmon-next linus/master v5.7-rc5 next-20200515]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Tim-Harvey/Add-support-for-the-Gateworks-System-Controller/20200515-232142
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>, old ones prefixed by <<):
>> drivers/mfd/gateworks-gsc.c:270:14: error: 'gsc_id_table' undeclared here (not in a function)
270 | .id_table = gsc_id_table,
| ^~~~~~~~~~~~
vim +/gsc_id_table +270 drivers/mfd/gateworks-gsc.c
264
265 static struct i2c_driver gsc_driver = {
266 .driver = {
267 .name = "gateworks-gsc",
268 .of_match_table = gsc_of_match,
269 },
> 270 .id_table = gsc_id_table,
271 .probe_new = gsc_probe,
272 .remove = gsc_remove,
273 };
274 module_i2c_driver(gsc_driver);
275
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 65488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 20/20] cpufreq: Return zero on success in boost sw setting
From: Serge Semin @ 2020-05-16 12:52 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Serge Semin, Thomas Bogendoerfer, Rafael J. Wysocki, Viresh Kumar,
Ulf Hansson, Matthias Kaehlcke, Alexey Malahov, Paul Burton,
Ralf Baechle, Arnd Bergmann, Rob Herring, linux-mips, devicetree,
stable, Frederic Weisbecker, Ingo Molnar, Yue Hu, linux-pm,
linux-kernel
In-Reply-To: <c5109483-4c14-1a0c-efa9-51edf01c12de@intel.com>
Hello Rafael,
On Fri, May 15, 2020 at 05:58:47PM +0200, Rafael J. Wysocki wrote:
> On 5/6/2020 7:42 PM, Sergey.Semin@baikalelectronics.ru wrote:
> > From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> >
> > Recent commit e61a41256edf ("cpufreq: dev_pm_qos_update_request() can
> > return 1 on success") fixed a problem when active policies traverse
> > was falsely stopped due to invalidly treating the non-zero return value
> > from freq_qos_update_request() method as an error. Yes, that function
> > can return positive values if the requested update actually took place.
> > The current problem is that the returned value is then passed to the
> > return cell of the cpufreq_boost_set_sw() (set_boost callback) method.
> > This value is then also analyzed for being non-zero, which is also
> > treated as having an error. As a result during the boost activation
> > we'll get an error returned while having the QOS frequency update
> > successfully performed. Fix this by returning a negative value from the
> > cpufreq_boost_set_sw() if actual error was encountered and zero
> > otherwise treating any positive values as the successful operations
> > completion.
> >
> > Fixes: 18c49926c4bf ("cpufreq: Add QoS requests for userspace constraints")
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > Cc: Paul Burton <paulburton@kernel.org>
> > Cc: Ralf Baechle <ralf@linux-mips.org>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: linux-mips@vger.kernel.org
> > Cc: devicetree@vger.kernel.org
> > Cc: stable@vger.kernel.org
> > ---
> > drivers/cpufreq/cpufreq.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 045f9fe157ce..5870cdca88cf 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -2554,7 +2554,7 @@ static int cpufreq_boost_set_sw(int state)
> > break;
> > }
> > - return ret;
> > + return ret < 0 ? ret : 0;
> > }
> > int cpufreq_boost_trigger_state(int state)
>
> IMO it is better to update the caller of this function to handle the
> positive value possibly returned by it correctly.
Could you elaborate why? Viresh seems to be ok with this solution.
As I see it the caller doesn't expect the positive value returned by the
original freq_qos_update_request(). It just doesn't need to know whether the
effective policy has been updated or not, it only needs to make sure the
operations has been successful. Moreover the positive value is related only
to the !last! active policy, which doesn't give the caller a full picture
of the policy change anyway. So taking all of these into account I'd leave the
fix as is.
Regards,
-Sergey
>
> Thanks!
>
>
^ permalink raw reply
* Re: [PATCH v3 7/7] clocksource: mips-gic-timer: Set limitations on clocksource/sched-clocks usage
From: Serge Semin @ 2020-05-16 12:16 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Serge Semin, Thomas Bogendoerfer, Thomas Gleixner, Alexey Malahov,
Paul Burton, Ralf Baechle, Alessandro Zummo, Alexandre Belloni,
Arnd Bergmann, Rob Herring, linux-mips, linux-rtc, devicetree,
Vincenzo Frascino, linux-kernel
In-Reply-To: <20200515171004.GA760381@linaro.org>
Hello Daniel,
Thanks for your comment. My response is below.
On Fri, May 15, 2020 at 07:10:04PM +0200, Daniel Lezcano wrote:
> On Thu, May 07, 2020 at 12:41:07AM +0300, Serge Semin wrote:
> > Currently neither clocksource nor scheduler clock kernel framework
> > support the clocks with variable frequency. Needless to say how many
> > problems may cause the sudden base clocks frequency change. In a
> > simplest case the system time will either slow down or speed up.
> > Since on CM2.5 and earlier MIPS GIC timer is synchronously clocked
> > with CPU we must set some limitations on using it for these frameworks
> > if CPU frequency may change. First of all it's not safe to have the
> > MIPS GIC used for scheduler timings. So we shouldn't proceed with
> > the clocks registration in the sched-subsystem. Secondly we must
> > significantly decrease the MIPS GIC clocksource rating. This will let
> > the system to use it only as a last resort.
> >
> > Note CM3.x-based systems may also experience the problems with MIPS GIC
> > if the CPU-frequency change is activated for the whole CPU cluster
> > instead of using the individual CPC core clocks divider.
>
> May be there is no alternative but the code looks a bit hacksih. Isn't possible
> to do something with the sched_mark_unstable?
>
> Or just not use the timer at all ?
Not using the timer might be better, but not that good alternative either
especially in our case due to very slow external timer. Me and Thomas
Bogendoerfer discussed the similar commit I've provided to the csrc-r4k driver
available on MIPS:
https://lkml.org/lkml/2020/5/11/576
To cut it short, you are right. The solution with using clocksource_mark_unstable()
is better alternative spied up in x86 tsc implementation. I'll use a similar
approach here and submit the updated patch in v3.
Could you please proceed with the rest of the series review? I'd like to send
the next version with as many comments taken into account as possible. The
patchset has been submitted a while ago, but except Rob noone have had any
comments.(
-Sergey
^ permalink raw reply
* Re: [PATCH v8 2/6] ARM: tegra: Add device-tree for ASUS Google Nexus 7
From: Dmitry Osipenko @ 2020-05-16 12:01 UTC (permalink / raw)
To: Michał Mirosław
Cc: Rob Herring, Thierry Reding, Jonathan Hunter, David Heidelberg,
Peter Geis, Stephen Warren, Nicolas Chauvet, Pedro Ângelo,
Matt Merhar, Zack Pearsall, linux-tegra, devicetree, linux-kernel
In-Reply-To: <20200515181847.GA13860@qmqm.qmqm.pl>
15.05.2020 21:18, Michał Mirosław пишет:
> On Fri, May 15, 2020 at 12:36:50AM +0300, Dmitry Osipenko wrote:
>> There are few hardware variants of NVIDIA Tegra30-based Nexus 7 device:
>>
>> 1. WiFi-only (named Grouper)
>> 2. GSM (named Tilapia)
>> 3. Using Maxim PMIC (E1565 board ID)
>> 4. Using Ti PMIC (PM269 board ID)
>
> Hi,
>
> I've briefly looked at the PM269 devicetree (PMIC part) and it looks very
> similar, if not the same, to what I deduced from the TF300T kernel.
Hello Michał,
Definitely there are board parts that are reused by different devices.
This is not surprising since most of the boards are designed by the same
company.
> Those devices don't look to differ much from original Cardhu tablet
> devkit, so maybe the trees can base off of that?
I don't think it's really possible in a case of Nexus 7 because in
overall the used hardware components differ a bit too much. It shouldn't
worth the effort, IMO.
> I would also guess that because of this 'ram-code', memory timings would
> be duplicated between devices. I can see small differences between
> ram-code=1 timings of Grouper and TF300T, though they look like arbiter
> tuning differences. I'll have to test if my TF300T works with Grouper's
> settings. In case they work, could you split the memory timings to another
> dtsi file?
Yes, perhaps this could be done. The memory timings on Grouper and
Tilapia are pretty much the same as well. As you noticed, there are some
tuning differences of TF300T in comparison to the Nexus 7, the same
applies to the Grouper and Tilapia variants.
> BTW, shouldn't EMC timing set match MC? I see more frequencies listed in
> MC than EMC nodes.
The MC timings are exactly the same on Grouper and Tilapia, but EMC
timings have a very minor differences, and thus, the common.dtsi misses
these differentiating EMC timings, they are defined in grouper.dtsi and
tilapia.dts.
I guess we indeed could try to select the lowest common denominator
timing and re-use it. I'll consider this change for v9, thank you very
much for the suggestion.
^ permalink raw reply
* RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller
From: Felipe Balbi @ 2020-05-16 11:57 UTC (permalink / raw)
To: Jun Li, Thinh Nguyen, Jun Li
Cc: John Stultz, lkml, Yu Chen, Greg Kroah-Hartman, Rob Herring,
Mark Rutland, ShuFan Lee, Heikki Krogerus, Suzuki K Poulose,
Chunfeng Yun, Hans de Goede, Andy Shevchenko, Valentin Schneider,
Jack Pham, Linux USB List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Peter Chen, Thinh Nguyen
In-Reply-To: <VE1PR04MB6528AB046FD441A5DDD83CD289BA0@VE1PR04MB6528.eurprd04.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1500 bytes --]
Hi,
Jun Li <jun.li@nxp.com> writes:
>> >> Hi Thinh, could you comment this?
>> >
>> > You only need to wake up the usb2 phy when issuing the command while
>> > running in highspeed or below. If you're running in SS or higher,
>> > internally the controller does it for you for usb3 phy. In Jun's case,
>> > it seems like it takes longer for his phy to wake up.
>> >
>> > IMO, in this case, I think it's fine to increase the command timeout.
>>
>> Is there an upper limit to this? Is 32k clock the slowest that can be fed to the
>> PHY as a suspend clock?
>
> Yes, 32K clock is the slowest, Per DWC3 document on Power Down Scale
> (bits 31:19 of GCTL):
>
> "Power Down Scale (PwrDnScale)
> The USB3 suspend_clk input replaces pipe3_rx_pclk as a clock source
> to a small part of the USB3 controller that operates when the SS PHY
> is in its lowest power (P3) state, and therefore does not provide a clock.
> The Power Down Scale field specifies how many suspend_clk periods
> fit into a 16 kHz clock period. When performing the division, round up
> the remainder.
> For example, when using an 8-bit/16-bit/32-bit PHY and 25-MHz Suspend clock,
> Power Down Scale = 25000 kHz/16 kHz = 13'd1563 (rounder up)
> Note:
> - Minimum Suspend clock frequency is 32 kHz
> - Maximum Suspend clock frequency is 125 MHz"
Cool, now do we have an upper bound for how many clock cycles it takes
to wake up the PHY? Then we can just set the time to that upper bound.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH v2 18/20] mips: csrc-r4k: Decrease r4k-clocksource rating if CPU_FREQ enabled
From: Serge Semin @ 2020-05-16 11:55 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Serge Semin, Alexey Malahov, Paul Burton, Ralf Baechle,
Greg Kroah-Hartman, Arnd Bergmann, Rob Herring, linux-pm,
devicetree, Vincenzo Frascino, Thomas Gleixner, linux-mips,
linux-kernel
In-Reply-To: <20200515210647.GA22922@alpha.franken.de>
On Fri, May 15, 2020 at 11:06:47PM +0200, Thomas Bogendoerfer wrote:
> On Fri, May 15, 2020 at 10:48:27AM +0300, Serge Semin wrote:
> > Thomas,
> > Could you take a look at my comment below so I could proceed with the
> > patchset v3 development?
>
> I can't help, but using r4k clocksource with changing frequency is
> probaly only usefull as a random generator. So IMHO the only two
> options are disabling it or implement what arch/x86/kernel/tsc.c does.
Then it's settled. I'll resend the series with csrc-r4k updated to have the
tsc-like design implemented.
-Sergey
>
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea. [ RFC1925, 2.3 ]
^ 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