* [PATCH next v11 02/11] dt-bindings: connector: add optional properties for Type-B
From: Chunfeng Yun @ 2019-08-29 9:22 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Biju Das
Cc: Mark Rutland, devicetree, Hans de Goede, Heikki Krogerus,
Badhri Jagan Sridharan, Linus Walleij, linux-usb, linux-kernel,
Matthias Brugger, Andy Shevchenko, linux-mediatek, Min Guo,
Chunfeng Yun, Nagarjuna Kristam, Adam Thomson, linux-arm-kernel,
Li Jun
In-Reply-To: <1567070558-29417-1-git-send-email-chunfeng.yun@mediatek.com>
Add id-gpios, vbus-gpios, vbus-supply and pinctrl properties for
usb-b-connector
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
---
v11 changes:
1. add Reviewed-by Linus
v6~v10 no changes
v5 changes:
1. add reviewed by Rob
v4 no changes
v3 changes:
1. add GPIO direction, and use fixed-regulator for GPIO controlled
VBUS regulator suggested by Rob;
v2 changes:
1. describe more clear for vbus-gpios and vbus-supply suggested by Hans
---
.../bindings/connector/usb-connector.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt b/Documentation/devicetree/bindings/connector/usb-connector.txt
index cef556d4e5ee..d357987181ee 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.txt
+++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
@@ -17,6 +17,20 @@ Optional properties:
- self-powered: Set this property if the usb device that has its own power
source.
+Optional properties for usb-b-connector:
+- id-gpios: an input gpio for USB ID pin.
+- vbus-gpios: an input gpio for USB VBUS pin, used to detect presence of
+ VBUS 5V.
+ see gpio/gpio.txt.
+- vbus-supply: a phandle to the regulator for USB VBUS if needed when host
+ mode or dual role mode is supported.
+ Particularly, if use an output GPIO to control a VBUS regulator, should
+ model it as a regulator.
+ see regulator/fixed-regulator.yaml
+- pinctrl-names : a pinctrl state named "default" is optional
+- pinctrl-0 : pin control group
+ see pinctrl/pinctrl-bindings.txt
+
Optional properties for usb-c-connector:
- power-role: should be one of "source", "sink" or "dual"(DRP) if typec
connector has power support.
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH next v11 01/11] dt-binding: usb: add usb-role-switch property
From: Chunfeng Yun @ 2019-08-29 9:22 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Biju Das
Cc: Mark Rutland, devicetree, Hans de Goede, Heikki Krogerus,
Badhri Jagan Sridharan, Linus Walleij, linux-usb, Yu Chen,
linux-kernel, Matthias Brugger, Andy Shevchenko, linux-mediatek,
Min Guo, Chunfeng Yun, Nagarjuna Kristam, Adam Thomson,
linux-arm-kernel, Li Jun
In-Reply-To: <1567070558-29417-1-git-send-email-chunfeng.yun@mediatek.com>
Add a property usb-role-switch to tell the driver that use
USB Role Switch framework to handle the role switch,
it's useful when the driver has already supported other ways,
such as extcon framework etc.
Cc: Biju Das <biju.das@bp.renesas.com>
Cc: Yu Chen <chenyu56@huawei.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
---
v7~v11: no changes
v6:
1. merge into this series patch
2. add Reviewed-by
(no v4, v5)
v3:
add property type, modify description suggested by Heikki
v2:
describe it in terms of h/w functionality suggested by Rob
v1:
the property is discussed in:
[v2,2/7] dt-bindings: usb: renesas_usb3: add usb-role-switch property
https://patchwork.kernel.org/patch/10852497/
Mediatek and Hisilicon also try to use it:
[v4,3/6] dt-bindings: usb: mtu3: add properties about USB Role Switch
https://patchwork.kernel.org/patch/10918385/
[v4,6/6] usb: mtu3: register a USB Role Switch for dual role mode
https://patchwork.kernel.org/patch/10918367/
[v6,10/13] usb: dwc3: Registering a role switch in the DRD code
https://patchwork.kernel.org/patch/10909981/
---
Documentation/devicetree/bindings/usb/generic.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
index 0a74ab8dfdc2..cf5a1ad456e6 100644
--- a/Documentation/devicetree/bindings/usb/generic.txt
+++ b/Documentation/devicetree/bindings/usb/generic.txt
@@ -30,6 +30,10 @@ Optional properties:
optional for OTG device.
- adp-disable: tells OTG controllers we want to disable OTG ADP, ADP is
optional for OTG device.
+ - usb-role-switch: boolean, indicates that the device is capable of assigning
+ the USB data role (USB host or USB device) for a given
+ USB connector, such as Type-C, Type-B(micro).
+ see connector/usb-connector.txt.
This is an attribute to a USB controller such as:
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH next v11 00/11] add USB GPIO based connection detection driver
From: Chunfeng Yun @ 2019-08-29 9:22 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Biju Das
Cc: Mark Rutland, devicetree, Hans de Goede, Heikki Krogerus,
Badhri Jagan Sridharan, Linus Walleij, linux-usb, linux-kernel,
Matthias Brugger, Andy Shevchenko, linux-mediatek, Min Guo,
Chunfeng Yun, Nagarjuna Kristam, Adam Thomson, linux-arm-kernel,
Li Jun
Because the USB Connector is introduced and the requirement of
usb-connector.txt binding, the old way using extcon to support
USB Dual-Role switch is now deprecated, meanwhile there is no
available common driver when use Type-B connector, typically
using an input GPIO to detect USB ID pin.
This patch series introduce a USB GPIO based connection detection
driver and try to replace the function provided by extcon-usb-gpio
driver.
v11 changes:
1. add Reviewed-by Linus for [02/11] ad [03/11]
2. change compatible as "gpio-usb-b-connector", and remove label
in example suggested by Rob
NOTE: based on the following series
https://lore.kernel.org/patchwork/patch/1103630/
[v3,1/7] drivers: Introduce device lookup variants by name
they are already in:
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/log/drivers/base/core.c?h=driver-core-next
v10 changes:
1. revert commit log changes of [06/11] and [07/11]
v9 changes:
1. replace signed-off-by by suggested-by Heikki
2. add reviewed-by Linus
3. use class_find_device_by_fwnode() introduced by series [1]
[1]:
https://lore.kernel.org/patchwork/patch/1103630/
[v3,1/7] drivers: Introduce device lookup variants by name
they are already in:
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/log/drivers/base/core.c?h=driver-core-next
v8 changes:
1. rename the driver's name suggested by Heikki
2. move the driver from usb/roles/ into usb/common/ suggested by Heikki
3. introduce Kconfig for usb common core to add the new driver
4. modify binding of the driver
5. rename the subject title
v7 changes:
1. [5/10]: add signed-off-by Chunfeng
2. [6/10]: add signed-off-by Chunfeng
3. [6/10]: depends on linux-next of Rafael's tree [1]
4. [7/10]: add signed-off-by Chunfeng and tested-by Biju
5. [9/10]: add tested-by Nagarjuna, and remove DEV_PMS_OPS suggested by Andy
[1] https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=linux-next
v6 changes:
1. merge [1] and [2] into this series
2. don't use graph anymore to find usb-role-switch
3. abandon [3] and introduce three patches (6, 7, 8 in this series)
to rebuild APIs getting usb-role-switch
[1]: [v3] dt-binding: usb: add usb-role-switch property
https://patchwork.kernel.org/patch/10934835/
[2]: [v6,08/13] usb: roles: Introduce stubs for the exiting functions in role.h
https://patchwork.kernel.org/patch/10909971/
[3]: [PATCH v5 4/6] usb: roles: add API to get usb_role_switch by node
v5 changes:
1. remove linux/of.h and put usb_role_switch when error happens,
suggested by Biju
2. treat Type-B connector as USB controller's child, but not as
a virtual device, suggested by Rob
3. provide and use generic property "usb-role-switch", see [1],
suggested by Rob
Note: this series still depends on [2]
[1]: [v3] dt-binding: usb: add usb-role-switch property
https://patchwork.kernel.org/patch/10934835/
[2]: [v6,08/13] usb: roles: Introduce stubs for the exiting functions in role.h
https://patchwork.kernel.org/patch/10909971/
v4 changes:
1. use switch_fwnode_match() to find fwnode suggested by Heikki
2. assign fwnode member of usb_role_switch struct suggested by Heikki
3. make [4/6] depend on [2]
3. remove linux/gpio.h suggested by Linus
4. put node when error happens
[4/6] usb: roles: add API to get usb_role_switch by node
[2] [v6,08/13] usb: roles: Introduce stubs for the exiting functions in role.h
https://patchwork.kernel.org/patch/10909971/
v3 changes:
1. add GPIO direction, and use fixed-regulator for GPIO controlled
VBUS regulator suggested by Rob;
2. rebuild fwnode_usb_role_switch_get() suggested by Andy and Heikki
3. treat the type-B connector as a virtual device;
4. change file name of driver again
5. select USB_ROLE_SWITCH in mtu3/Kconfig suggested by Heikki
6. rename ssusb_mode_manual_switch() to ssusb_mode_switch()
v2 changes:
1. make binding clear, and add a extra compatible suggested by Hans
Chunfeng Yun (8):
dt-binding: usb: add usb-role-switch property
dt-bindings: connector: add optional properties for Type-B
dt-bindings: usb: add binding for USB GPIO based connection detection
driver
dt-bindings: usb: mtu3: add properties about USB Role Switch
usb: roles: get usb-role-switch from parent
usb: common: create Kconfig file
usb: common: add USB GPIO based connection detection driver
usb: mtu3: register a USB Role Switch for dual role mode
Heikki Krogerus (2):
device connection: Add fwnode_connection_find_match()
usb: roles: Add fwnode_usb_role_switch_get() function
Yu Chen (1):
usb: roles: Introduce stubs for the exiting functions in role.h
.../bindings/connector/usb-connector.txt | 14 +
.../devicetree/bindings/usb/generic.txt | 4 +
.../devicetree/bindings/usb/mediatek,mtu3.txt | 10 +
.../devicetree/bindings/usb/usb-conn-gpio.txt | 30 ++
drivers/base/devcon.c | 43 ++-
drivers/usb/Kconfig | 35 +--
drivers/usb/common/Kconfig | 51 ++++
drivers/usb/common/Makefile | 1 +
drivers/usb/common/usb-conn-gpio.c | 284 ++++++++++++++++++
drivers/usb/mtu3/Kconfig | 1 +
drivers/usb/mtu3/mtu3.h | 5 +
drivers/usb/mtu3/mtu3_debugfs.c | 4 +-
drivers/usb/mtu3/mtu3_dr.c | 48 ++-
drivers/usb/mtu3/mtu3_dr.h | 6 +-
drivers/usb/mtu3/mtu3_plat.c | 3 +-
drivers/usb/roles/class.c | 41 ++-
include/linux/device.h | 10 +-
include/linux/usb/role.h | 37 +++
18 files changed, 569 insertions(+), 58 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
create mode 100644 drivers/usb/common/Kconfig
create mode 100644 drivers/usb/common/usb-conn-gpio.c
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v2 04/10] dt-bindings: pci: layerscape-pci: add compatible strings for ls1088a and ls2088a
From: Xiaowei Bao @ 2019-08-29 9:19 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland@arm.com, Roy Zang, arnd@arndb.de,
devicetree@vger.kernel.org, gregkh@linuxfoundation.org,
linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, kishon@ti.com, M.h. Lian,
gustavo.pimentel@synopsys.com, jingoohan1@gmail.com,
bhelgaas@google.com, andrew.murray@arm.com, Leo Li,
shawnguo@kernel.org, Mingkai Hu,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190827222617.GA16361@bogus>
> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: 2019年8月28日 6:26
> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> Cc: bhelgaas@google.com; mark.rutland@arm.com; shawnguo@kernel.org;
> Leo Li <leoyang.li@nxp.com>; kishon@ti.com; lorenzo.pieralisi@arm.co;
> arnd@arndb.de; gregkh@linuxfoundation.org; M.h. Lian
> <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy Zang
> <roy.zang@nxp.com>; jingoohan1@gmail.com;
> gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org;
> andrew.murray@arm.com
> Subject: Re: [PATCH v2 04/10] dt-bindings: pci: layerscape-pci: add compatible
> strings for ls1088a and ls2088a
>
> On Thu, Aug 22, 2019 at 07:22:36PM +0800, Xiaowei Bao wrote:
> > Add compatible strings for ls1088a and ls2088a.
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > ---
> > v2:
> > - No change.
> >
> > Documentation/devicetree/bindings/pci/layerscape-pci.txt | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > index e20ceaa..16f592e 100644
> > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > @@ -22,7 +22,10 @@ Required properties:
> > "fsl,ls1043a-pcie"
> > "fsl,ls1012a-pcie"
> > EP mode:
> > - "fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep"
> > + "fsl,ls-pcie-ep"
>
> Wasn't this a fallback? Each line should be one valid combination of
> compatible strings.
Thanks, got it, I will modify it in next version patch.
Thanks
Xiaowei
>
> > + "fsl,ls1046a-pcie-ep"
> > + "fsl,ls1088a-pcie-ep"
> > + "fsl,ls2088a-pcie-ep"
> > - reg: base addresses and lengths of the PCIe controller register blocks.
> > - interrupts: A list of interrupt outputs of the controller. Must contain an
> > entry for each entry in the interrupt-names property.
> > --
> > 2.9.5
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v2 1/2] input: keyboard: snvs_pwrkey: Send key events for i.MX6 S, DL and Q
From: Robin Gong @ 2019-08-29 9:11 UTC (permalink / raw)
To: Marco Felsch, robin
Cc: Mark Rutland, devicetree @ vger . kernel . org, Fabio Estevam,
Adam Ford, Sascha Hauer, Dmitry Torokhov,
linux-kernel @ vger . kernel . org, Rob Herring, dl-linux-imx,
Pengutronix Kernel Team, linux-input @ vger . kernel . org,
Shawn Guo, linux-arm-kernel @ lists . infradead . org
In-Reply-To: <20190829081712.timamprawezzbesn@pengutronix.de>
On 2019-08-29 16:17, Marco Felsch wrote:
> > > While reading the rm it seems that
> > > the snvs block has a dedicated version register. IMHO this could be
> > > a better way to apply the change also to existing devices with old
> > > firmware.
> >
> > I thought the same thing, and fully agree with you. However I do not
> > have a way to determine which versions are out there. Since I couldn't
> > find any documentation on this, and I only have i.MX6 S/DL, D/Q and UL
> laying around.
>
> @NXP Kernel Team
> Can we get some more information here?
Go ahead, please. That snvs version register SNVS_HPVIDR1 should work as expect.
MINOR_REV checking is enough, none-zero means for soc after i.mx6sx, but
Zero means i.mx6q/dl/sl elder soc.
>
> Regards,
> Marco
>
> > Regards,
> > Robin van der Gracht
> >
>
> --
> Pengutronix e.K. |
> |
> Industrial Linux Solutions |
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.p
> engutronix.de%2F&data=02%7C01%7Cyibin.gong%40nxp.com%7C8d4e1
> 0cd77bd4652f3eb08d72c594e76%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
> C0%7C0%7C637026634390359345&sdata=mhXlUxmLWg8qtwhPQfkJZm
> VAn4QQ3YybLOSh83uf27E%3D&reserved=0 |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> Amtsgericht Hildesheim, HRA 2686 | Fax:
> +49-5121-206917-5555 |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 0/2] arm64: dts: ti: k3: Update the power-domain cells
From: Lokesh Vutla @ 2019-08-29 8:48 UTC (permalink / raw)
To: Tero Kristo, Nishanth Menon, Santosh Shilimkar, Rob Herring
Cc: Device Tree Mailing List, Sekhar Nori, Linux ARM Mailing List
In-Reply-To: <4dab34ae-e7cc-6c6e-4adb-3a061027ab39@ti.com>
Hi Tero,
On 29/08/19 1:01 PM, Tero Kristo wrote:
> On 20/08/2019 15:48, Lokesh Vutla wrote:
>>
>>
>> On 29/07/19 6:00 PM, Lokesh Vutla wrote:
>>> Update the power-domains cells on all K3 based devices to reflect
>>> exclusive and shared permissions in each device.
>>
>> Gentle Ping on this series.
>>
>> Thanks and regards,
>> Lokesh
>>
>
> This can't be merged until the driver portion is in. I could probably live with
> an immutable branch though.
Santosh already sent a pull request[0] with the driver changes. IMHO, dt changes
can be merged in. I don't think we need to wait for one release for DT changes
to get in or did I mis-understood your statement?
[0] https://lkml.org/lkml/2019/8/26/1124
Thanks and regards,
Lokesh
>
> -Tero
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 5/5] ARM: dts: stm32: add ddrperfm on stm32mp157c
From: Alexandre Torgue @ 2019-08-29 8:48 UTC (permalink / raw)
To: Gerald BAEZA, will@kernel.org, mark.rutland@arm.com,
robh+dt@kernel.org, mcoquelin.stm32@gmail.com, corbet@lwn.net,
linux@armlinux.org.uk, olof@lixom.net, arnd@arndb.de,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <1566918464-23927-6-git-send-email-gerald.baeza@st.com>
Hi Gerald
On 8/27/19 5:08 PM, Gerald BAEZA wrote:
> The DDRPERFM is the DDR Performance Monitor embedded
> in STM32MP1 SOC.
>
> Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
> ---
> arch/arm/boot/dts/stm32mp157c.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi
> b/arch/arm/boot/dts/stm32mp157c.dtsi
> index 0c4e6eb..6ea6933 100644
> --- a/arch/arm/boot/dts/stm32mp157c.dtsi
> +++ b/arch/arm/boot/dts/stm32mp157c.dtsi
> @@ -1378,6 +1378,14 @@
> };
> };
>
> + ddrperfm: perf@5a007000 {
> + compatible = "st,stm32-ddr-pmu";
> + reg = <0x5a007000 0x400>;
> + clocks = <&rcc DDRPERFM>;
> + resets = <&rcc DDRPERFM_R>;
> + status = "okay";
No need to add "status = "okay"" here.
regards
Alex
> + };
> +
> usart1: serial@5c000000 {
> compatible = "st,stm32h7-uart";
> reg = <0x5c000000 0x400>;
> --
> 2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [arm:for-next 13/25] include/linux/error-injection.h:7:10: fatal error: asm/error-injection.h: No such file or directory
From: Will Deacon @ 2019-08-29 8:32 UTC (permalink / raw)
To: Leo Yan, rmk+kernel; +Cc: kbuild test robot, linux-arm-kernel, kbuild-all
In-Reply-To: <20190829064310.GC10583@leoy-ThinkPad-X240s>
[ Move RMK to To: ]
On Thu, Aug 29, 2019 at 02:43:10PM +0800, Leo Yan wrote:
> On Thu, Aug 29, 2019 at 08:49:16AM +0800, kbuild test robot wrote:
> > tree: git://git.armlinux.org.uk/~rmk/linux-arm.git for-next
> > head: d0d54dc04e37be14a9e51d9a2e431f302948e99d
> > commit: 566c290c6498b2fdc04a54556c4e8747f0298c7b [13/25] ARM: 8899/1: arm/arm64: Add support for function error injection
> > config: arm-allmodconfig (attached as .config)
> > compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
> > reproduce:
> > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > git checkout 566c290c6498b2fdc04a54556c4e8747f0298c7b
> > # save the attached .config to linux build tree
> > GCC_VERSION=7.4.0 make.cross ARCH=arm
> >
> > If you fix the issue, kindly add following tag
> > Reported-by: kbuild test robot <lkp@intel.com>
> >
> > All errors (new ones prefixed by >>):
> >
> > In file included from include/linux/module.h:22:0,
> > from drivers/pps/pps.c:11:
> > >> include/linux/error-injection.h:7:10: fatal error: asm/error-injection.h: No such file or directory
> > #include <asm/error-injection.h>
> > ^~~~~~~~~~~~~~~~~~~~~~~
> > compilation terminated.
>
> This building error is caused by there have a dependent patch:
> error-injection: Consolidate override function definition
> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?h=for-next/error-injection&id=45880f7b7b19e043ce0aaa4cb7d05369425c82fa
Ah, I guess you put the ARM patch into the patch system without reference to
the core parts?
> This patch has been picked up by Will in one of arm64's next branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/error-injection
>
> I don't know what's the best practice for the dependency between
> two branches, if need me to follow up anything, please let me know.
The for-next/error-injection branch here:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/error-injection
is stable, so I suppose either:
* That could be pulled into the ARM tree, or
* The ARM part could wait until the core stuff has landed in mainline, or
* I could take the ARM patch via the arm64 tree if Russell is ok with it
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv1 0/3] Odroid c2 missing regulator linking
From: Neil Armstrong @ 2019-08-29 8:28 UTC (permalink / raw)
To: Anand Moon, Rob Herring, Martin Blumenstingl, Jerome Brunet,
Kevin Hilman
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-amlogic
In-Reply-To: <20190828202723.1145-1-linux.amoon@gmail.com>
On 28/08/2019 22:27, Anand Moon wrote:
> Below small changes help re-configure or fix missing inter linking
> of regulator node.
>
> Changes based top on my prevoius series.
For the serie:
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
>
> [0] https://patchwork.kernel.org/cover/11113091/
>
> TOOD: Add support for DVFS GXBB odroid board in next series.
I'm curious how you will do this !
>
> Best Regards
> -Anand
>
> Anand Moon (3):
> arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0
> regulator
> arm64: dts: meson: odroid-c2: Add missing regulator linked to
> VDDIO_AO3V3 regulator
> arm64: dts: meson: odroid-c2: Add missing regulator linked to HDMI
> supply
>
> .../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 44 ++++++++++++++++---
> 1 file changed, 38 insertions(+), 6 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] input: keyboard: snvs_pwrkey: Send key events for i.MX6 S, DL and Q
From: Marco Felsch @ 2019-08-29 8:17 UTC (permalink / raw)
To: robin
Cc: Mark Rutland, devicetree @ vger . kernel . org, Fabio Estevam,
Adam Ford, Sascha Hauer, Dmitry Torokhov,
linux-kernel @ vger . kernel . org, Rob Herring, dl-linux-imx,
Pengutronix Kernel Team, linux-input @ vger . kernel . org,
Robin Gong, Shawn Guo, linux-arm-kernel @ lists . infradead . org
In-Reply-To: <6d353af709ea545cc34abca5c40674e3@protonic.nl>
Hi Robin,
On 19-08-29 09:24, robin wrote:
> Hi Marco,
>
> On 2019-08-28 11:15, Marco Felsch wrote:
> > Hi Robin,
> >
> > thanks for the patch.
> >
> > On 19-08-27 14:32, Robin van der Gracht wrote:
> > > The first generation i.MX6 processors does not send an interrupt
> > > when the
> > > power key is pressed. It sends a power down request interrupt if the
> > > key is
> > > released before a hard shutdown (5 second press). This should allow
> > > software to bring down the SoC safely.
> > >
> > > For this driver to work as a regular power key with the older SoCs,
> > > we need
> > > to send a keypress AND release when we get the power down request irq.
> > >
> > > Signed-off-by: Robin van der Gracht <robin@protonic.nl>
> > > ---
> > > .../devicetree/bindings/crypto/fsl-sec4.txt | 16 ++++--
> > > drivers/input/keyboard/Kconfig | 2 +-
> > > drivers/input/keyboard/snvs_pwrkey.c | 52
> > > ++++++++++++++++---
> >
> > Can we split this so the dt-bindings are a standalone patch? IMHO this
> > is the usual way because the maintainer can squash them on there needs.
>
> Not sure what you mean, do you want me to make a separate patch for the
> devicetree binding documentation here?
Yes.
> > Also it would be cool to document the changes. A common place for
> > changes is after the '---' or on the cover-letter.
>
> Agreed!
>
> v1 -> v2:
> - Nolonger altering the existing compatible string, just add a second one.
> - Moved the event emiting work out of the irq handler to the timer handler.
> - Assign hwtype directly to of_device_id->data instead of a struct
> platform_device_id entry which has it's .driver_data set to hwtype.
> - Document the new device tree binding.
> - Update commit message to make more clear why we want to make this change.
>
> >
> > > 3 files changed, 57 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
> > > b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
> > > index 2fe245ca816a..e4fbb9797082 100644
> > > --- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
> > > +++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
> > > @@ -420,14 +420,22 @@ EXAMPLE
> > > =====================================================================
> > > System ON/OFF key driver
> > >
> > > - The snvs-pwrkey is designed to enable POWER key function which
> > > controlled
> > > - by SNVS ONOFF, the driver can report the status of POWER key and
> > > wakeup
> > > - system if pressed after system suspend.
> > > + The snvs-pwrkey is designed to enable POWER key function which is
> > > controlled
> > > + by SNVS ONOFF. It can wakeup the system if pressed after system
> > > suspend.
> > > +
> > > + There are two generations of SVNS pwrkey hardware. The first
> > > generation is
> > > + included in i.MX6 Solo, DualLite and Quad processors. The second
> > > generation
> > > + is included in i.MX6 SoloX and newer SoCs.
> > > +
> > > + Second generation SNVS can detect and report the status of POWER
> > > key, but the
> > > + first generation can only detect a key release and so emits an
> > > instantaneous
> > > + press and release event when the key is released.
> > >
> > > - compatible:
> > > Usage: required
> > > Value type: <string>
> > > - Definition: Mush include "fsl,sec-v4.0-pwrkey".
> > > + Definition: Must include "fsl,sec-v4.0-pwrkey" for i.MX6
> > > SoloX and newer
> > > + or "fsl,imx6qdl-snvs-pwrkey" for older SoCs.
> > >
> > > - interrupts:
> > > Usage: required
> > > diff --git a/drivers/input/keyboard/Kconfig
> > > b/drivers/input/keyboard/Kconfig
> > > index 7c4f19dab34f..937e58da5ce1 100644
> > > --- a/drivers/input/keyboard/Kconfig
> > > +++ b/drivers/input/keyboard/Kconfig
> > > @@ -436,7 +436,7 @@ config KEYBOARD_SNVS_PWRKEY
> > > depends on OF
> > > help
> > > This is the snvs powerkey driver for the Freescale i.MX
> > > application
> > > - processors that are newer than i.MX6 SX.
> > > + processors.
> > >
> > > To compile this driver as a module, choose M here; the
> > > module will be called snvs_pwrkey.
> > > diff --git a/drivers/input/keyboard/snvs_pwrkey.c
> > > b/drivers/input/keyboard/snvs_pwrkey.c
> > > index 5342d8d45f81..d71c44733103 100644
> > > --- a/drivers/input/keyboard/snvs_pwrkey.c
> > > +++ b/drivers/input/keyboard/snvs_pwrkey.c
> > > @@ -29,6 +29,11 @@
> > > #define DEBOUNCE_TIME 30
> > > #define REPEAT_INTERVAL 60
> > >
> > > +enum imx_snvs_hwtype {
> > > + IMX6SX_SNVS, /* i.MX6 SoloX and newer */
> > > + IMX6QDL_SNVS, /* i.MX6 Solo, DualLite and Quad */
> > > +};
> > > +
> > > struct pwrkey_drv_data {
> > > struct regmap *snvs;
> > > int irq;
> > > @@ -37,14 +42,41 @@ struct pwrkey_drv_data {
> > > int wakeup;
> > > struct timer_list check_timer;
> > > struct input_dev *input;
> > > + enum imx_snvs_hwtype hwtype;
> > > };
> > >
> > > +static const struct of_device_id imx_snvs_pwrkey_ids[] = {
> > > + {
> > > + .compatible = "fsl,sec-v4.0-pwrkey",
> > > + .data = (const void *)IMX6SX_SNVS,
> > > + },
> > > + {
> > > + .compatible = "fsl,imx6qdl-snvs-pwrkey",
> > > + .data = (const void *)IMX6QDL_SNVS,
> > > + },
> > > + { /* sentinel */ },
> > > +};
> > > +MODULE_DEVICE_TABLE(of, imx_snvs_pwrkey_ids);
> >
> > Can we keep this on the original place if you are using ...
> >
> > > +
> > > static void imx_imx_snvs_check_for_events(struct timer_list *t)
> > > {
> > > struct pwrkey_drv_data *pdata = from_timer(pdata, t, check_timer);
> > > struct input_dev *input = pdata->input;
> > > u32 state;
> > >
> > > + if (pdata->hwtype == IMX6QDL_SNVS) {
> > > + /*
> > > + * The first generation i.MX6 SoCs only sends an interrupt on
> > > + * button release. To mimic power-key usage, we'll prepend a
> > > + * press event.
> > > + */
> > > + input_report_key(input, pdata->keycode, 1);
> >
> > Missing input_sync() here?
>
> Yes you are right. Odd that systemd powerkey handling didn't complain.
>
> >
> > > + input_report_key(input, pdata->keycode, 0);
> > > + input_sync(input);
> > > + pm_relax(input->dev.parent);
> > > + return;
> > > + }
> > > +
> > > regmap_read(pdata->snvs, SNVS_HPSR_REG, &state);
> > > state = state & SNVS_HPSR_BTN ? 1 : 0;
> > >
> > > @@ -67,13 +99,17 @@ static irqreturn_t imx_snvs_pwrkey_interrupt(int
> > > irq, void *dev_id)
> > > {
> > > struct platform_device *pdev = dev_id;
> > > struct pwrkey_drv_data *pdata = platform_get_drvdata(pdev);
> > > + unsigned long expire = jiffies;
> > > u32 lp_status;
> > >
> > > pm_wakeup_event(pdata->input->dev.parent, 0);
> > >
> > > regmap_read(pdata->snvs, SNVS_LPSR_REG, &lp_status);
> > > - if (lp_status & SNVS_LPSR_SPO)
> > > - mod_timer(&pdata->check_timer, jiffies +
> > > msecs_to_jiffies(DEBOUNCE_TIME));
> > > + if (lp_status & SNVS_LPSR_SPO) {
> > > + if (pdata->hwtype == IMX6SX_SNVS)
> > > + expire += msecs_to_jiffies(DEBOUNCE_TIME);
> > > + mod_timer(&pdata->check_timer, expire);
> >
> > Is this desired because the timer gets triggered earlier.
>
> Yes, since the first generation has debounce implemented in hardware,
> we dont need to add another one.
>
> Now looking at it, maybe I should change the conditional to:
>
> if (pdata->hwtype != IMX6QDL_SNVS)
> expire += msecs_to_jiffies(DEBOUNCE_TIME);
>
> to make this more clear.
Maybe we should add:
if (pdata->hwtype != IMX6QDL_SNVS)
expire = jiffies + msecs_to_jiffies(DEBOUNCE_TIME);
So we can ensure the correct DEBOUNCE time for the other SoC's.
>
> >
> > > + }
> > >
> > > /* clear SPO status */
> > > regmap_write(pdata->snvs, SNVS_LPSR_REG, SNVS_LPSR_SPO);
> > > @@ -93,6 +129,7 @@ static int imx_snvs_pwrkey_probe(struct
> > > platform_device *pdev)
> > > struct pwrkey_drv_data *pdata = NULL;
> > > struct input_dev *input = NULL;
> > > struct device_node *np;
> > > + const struct of_device_id *match;
> > > int error;
> > >
> > > /* Get SNVS register Page */
> > > @@ -100,6 +137,10 @@ static int imx_snvs_pwrkey_probe(struct
> > > platform_device *pdev)
> > > if (!np)
> > > return -ENODEV;
> > >
> > > + match = of_match_node(imx_snvs_pwrkey_ids, np);
> > > + if (!match)
> > > + return -ENODEV;
> >
> > ... of_device_get_match_data() here.
>
> of_device_get_match_data() returns NULL on error. In this case, because I
> assigned integer values to the .data pointers, casting NULL back to an
> integer will result in a valid hwtype.
>
> I could declare a special struct with a 'quirks' field like they did in the
> flexcan diver: 'drivers/net/can/flexcan.c'.
>
> Use of_device_get_match_data() to get it, and define a quirk like:
> SNVS_QUIRK_NO_BTN_PRESS_IRQ. This might also improve readability.
IMHO we don't need that check because of:
8<-----------------------------
...
np = pdev->dev.of_node
if (!np)
return -ENODEV;
...
8<-----------------------------
So we can asign it directly.
> > While reading the rm it seems that
> > the snvs block has a dedicated version register. IMHO this could be a
> > better way to apply the change also to existing devices with old
> > firmware.
>
> I thought the same thing, and fully agree with you. However I do not have
> a way to determine which versions are out there. Since I couldn't find any
> documentation on this, and I only have i.MX6 S/DL, D/Q and UL laying around.
@NXP Kernel Team
Can we get some more information here?
Regards,
Marco
> Regards,
> Robin van der Gracht
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 14/14] arm64: dts: Add power controller device node of MT8183
From: CK Hu @ 2019-08-29 8:15 UTC (permalink / raw)
To: Matthias Brugger
Cc: Rob Herring, Nicolas Boichat, Weiyi Lu, srv_heupstream,
James Liao, linux-kernel, Fan Chen, linux-mediatek,
linux-arm-kernel, Yong Wu
In-Reply-To: <dbe45059-f265-fc6e-8ec5-b2166d503186@gmail.com>
Hi, Matthias:
On Thu, 2019-08-29 at 09:19 +0200, Matthias Brugger wrote:
>
> On 01/07/2019 10:57, CK Hu wrote:
> > Hi, Weiyi:
> >
> > On Thu, 2019-06-20 at 10:38 +0800, Weiyi Lu wrote:
> >> Add power controller node and smi-common node for MT8183
> >> In scpsys node, it contains clocks and regmapping of
> >> infracfg and smi-common for bus protection.
> >>
> >> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
> >> ---
> >> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 62 ++++++++++++++++++++++++++++++++
> >> 1 file changed, 62 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> >> index 08274bf..75c4881 100644
> >> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> >> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> >> @@ -8,6 +8,7 @@
> >> #include <dt-bindings/clock/mt8183-clk.h>
> >> #include <dt-bindings/interrupt-controller/arm-gic.h>
> >> #include <dt-bindings/interrupt-controller/irq.h>
> >> +#include <dt-bindings/power/mt8183-power.h>
> >>
> >> / {
> >> compatible = "mediatek,mt8183";
> >> @@ -196,6 +197,62 @@
> >> #clock-cells = <1>;
> >> };
> >>
> >> + scpsys: syscon@10006000 {
> >> + compatible = "mediatek,mt8183-scpsys", "syscon";
> >> + #power-domain-cells = <1>;
> >> + reg = <0 0x10006000 0 0x1000>;
> >> + clocks = <&topckgen CLK_TOP_MUX_AUD_INTBUS>,
> >> + <&infracfg CLK_INFRA_AUDIO>,
> >> + <&infracfg CLK_INFRA_AUDIO_26M_BCLK>,
> >> + <&topckgen CLK_TOP_MUX_MFG>,
> >> + <&topckgen CLK_TOP_MUX_MM>,
> >> + <&topckgen CLK_TOP_MUX_CAM>,
> >> + <&topckgen CLK_TOP_MUX_IMG>,
> >> + <&topckgen CLK_TOP_MUX_IPU_IF>,
> >> + <&topckgen CLK_TOP_MUX_DSP>,
> >> + <&topckgen CLK_TOP_MUX_DSP1>,
> >> + <&topckgen CLK_TOP_MUX_DSP2>,
> >> + <&mmsys CLK_MM_SMI_COMMON>,
> >> + <&mmsys CLK_MM_SMI_LARB0>,
> >> + <&mmsys CLK_MM_SMI_LARB1>,
> >> + <&mmsys CLK_MM_GALS_COMM0>,
> >> + <&mmsys CLK_MM_GALS_COMM1>,
> >> + <&mmsys CLK_MM_GALS_CCU2MM>,
> >> + <&mmsys CLK_MM_GALS_IPU12MM>,
> >> + <&mmsys CLK_MM_GALS_IMG2MM>,
> >> + <&mmsys CLK_MM_GALS_CAM2MM>,
> >> + <&mmsys CLK_MM_GALS_IPU2MM>,
> >
> > Up to now, MT8183 mmsys has the same resource with another device node:
> >
> > mmsys: syscon@14000000 {
> > compatible = "mediatek,mt8183-mmsys", "syscon";
> > reg = <0 0x14000000 0 0x1000>;
> > #clock-cells = <1>;
> > };
> >
> > display_components: dispsys@14000000 {
> > compatible = "mediatek,mt8183-display";
> > reg = <0 0x14000000 0 0x1000>;
> > power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
> > };
> >
> > I think this two node should be merge into one node, so I've try to
> > merge them:
> >
> > mmsys: syscon@14000000 {
> > compatible = "mediatek,mt8183-mmsys", "syscon";
> > reg = <0 0x14000000 0 0x1000>;
> > power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
> > #clock-cells = <1>;
> > };
> >
> > But I got a kernel panic when boot,
> >
> > [ 3.458523] Unable to handle kernel paging request at virtual address
> > fffffffffffffdfb
> > [ 3.466999] Mem abort info:
> > [ 3.470116] ESR = 0x96000005
> > [ 3.473268] Exception class = DABT (current EL), IL = 32 bits
> > [ 3.479375] SET = 0, FnV = 0
> > [ 3.482530] EA = 0, S1PTW = 0
> > [ 3.485785] Data abort info:
> > [ 3.488831] ISV = 0, ISS = 0x00000005
> > [ 3.493067] CM = 0, WnR = 0
> > [ 3.496229] swapper pgtable: 4k pages, 39-bit VAs, pgdp =
> > 000000004f8fa26d
> > [ 3.503214] [fffffffffffffdfb] pgd=0000000000000000,
> > pud=0000000000000000
> > [ 3.510408] Internal error: Oops: 96000005 [#1] PREEMPT SMP
> > [ 3.515974] Modules linked in:
> > [ 3.519023] Process kworker/0:3 (pid: 106, stack limit =
> > 0x00000000281d0651)
> > [ 3.526066] CPU: 0 PID: 106 Comm: kworker/0:3 Tainted: G W
> > 4.19.43 #208
> > [ 3.533974] Hardware name: MediaTek kukui rev1 board (DT)
> > [ 3.539374] Workqueue: events deferred_probe_work_func
> > [ 3.544507] pstate: 20000005 (nzCv daif -PAN -UAO)
> > [ 3.549294] pc : clk_prepare+0x18/0x40
> > [ 3.553038] lr : scpsys_clk_enable+0x40/0xb4
> > [ 3.557299] sp : ffffff800855b9e0
> > [ 3.560606] x29: ffffff800855b9f0 x28: ffffff93e1e5f594
> > [ 3.565911] x27: 000000000000000f x26: ffffff93e1e5e9b8
> > [ 3.571217] x25: 000000003b9aca00 x24: ffffff800858530c
> > [ 3.576522] x23: ffffffffffffffff x22: fffffffffffffdfb
> > [ 3.581827] x21: 000000000000000a x20: ffffffccb89aafc8
> > [ 3.587132] x19: fffffffffffffdfb x18: 00005a5c77082016
> > [ 3.592438] x17: 0000000000000400 x16: 0000000000000001
> > [ 3.597743] x15: 0000000000000009 x14: ffffff93e271c908
> > [ 3.603048] x13: 0000000000000b22 x12: 0000000000000008
> > [ 3.608353] x11: 0000000001d063de x10: 0000000000000008
> > [ 3.613659] x9 : 00000000ffffffed x8 : 0000000000000000
> > [ 3.618964] x7 : 736d6c2dff7224fe x6 : 0000008000000000
> > [ 3.624269] x5 : 0000000000000000 x4 : 0000000080000000
> > [ 3.629575] x3 : 002f6d6e74000000 x2 : 0000000000000000
> > [ 3.634880] x1 : 000000000000000a x0 : fffffffffffffdfb
> > [ 3.640185] Call trace:
> > [ 3.642625] clk_prepare+0x18/0x40
> > [ 3.646019] scpsys_clk_enable+0x40/0xb4
> > [ 3.649935] scpsys_power_on+0x13c/0x304
> > [ 3.653850] scpsys_probe+0xe0/0x5fc
> > [ 3.657419] platform_drv_probe+0x80/0xb0
> > [ 3.661420] really_probe+0x114/0x28c
> > [ 3.665075] driver_probe_device+0x64/0xfc
> > [ 3.669164] __device_attach_driver+0xb8/0xd0
> > [ 3.673513] bus_for_each_drv+0x88/0xd0
> > [ 3.677341] __device_attach+0xac/0x130
> > [ 3.681169] device_initial_probe+0x20/0x2c
> > [ 3.685344] bus_probe_device+0x34/0x90
> > [ 3.689172] deferred_probe_work_func+0x74/0xac
> > [ 3.693698] process_one_work+0x210/0x420
> > [ 3.697700] worker_thread+0x278/0x3e4
> > [ 3.701443] kthread+0x11c/0x12c
> > [ 3.704665] ret_from_fork+0x10/0x18
> >
> > I'm not really understand what happen, but scpsys and mmsys point to
> > each other in MT8183. Why these two node point to each other in MT8183?
> > If this is really hardware limitation, we need to solve this in driver.
> > If this is not a hardware limitation, I would like to re-organize device
> > tree to prevent this problem.
> >
>
> How do you register the clocks?
> We would need to have a solution as proposed in:
> https://patchwork.kernel.org/cover/10686345/
>
I register the clocks just like what you have done in that series. I've
no MT8173 platform now, so I tried it in MT8183, but I'm blocked by this
scpsys problem.
> CK Hu, as far as I remember you wanted to look into it. If you don't have time,
> I can give it a try next week. Right now I have a bit of free time to work on that.
Because I'm blocked, so it's better that you could continue that work in
MT8173 or MT2701.
Regards,
CK
>
> Regards,
> Matthias
>
> > Regards,
> > CK
> >
> >
> >> + <&imgsys CLK_IMG_LARB5>,
> >> + <&imgsys CLK_IMG_LARB2>,
> >> + <&camsys CLK_CAM_LARB6>,
> >> + <&camsys CLK_CAM_LARB3>,
> >> + <&camsys CLK_CAM_SENINF>,
> >> + <&camsys CLK_CAM_CAMSV0>,
> >> + <&camsys CLK_CAM_CAMSV1>,
> >> + <&camsys CLK_CAM_CAMSV2>,
> >> + <&camsys CLK_CAM_CCU>,
> >> + <&ipu_conn CLK_IPU_CONN_IPU>,
> >> + <&ipu_conn CLK_IPU_CONN_AHB>,
> >> + <&ipu_conn CLK_IPU_CONN_AXI>,
> >> + <&ipu_conn CLK_IPU_CONN_ISP>,
> >> + <&ipu_conn CLK_IPU_CONN_CAM_ADL>,
> >> + <&ipu_conn CLK_IPU_CONN_IMG_ADL>;
> >> + clock-names = "audio", "audio1", "audio2",
> >> + "mfg", "mm", "cam",
> >> + "isp", "vpu", "vpu1",
> >> + "vpu2", "vpu3", "mm-0",
> >> + "mm-1", "mm-2", "mm-3",
> >> + "mm-4", "mm-5", "mm-6",
> >> + "mm-7", "mm-8", "mm-9",
> >> + "isp-0", "isp-1", "cam-0",
> >> + "cam-1", "cam-2", "cam-3",
> >> + "cam-4", "cam-5", "cam-6",
> >> + "vpu-0", "vpu-1", "vpu-2",
> >> + "vpu-3", "vpu-4", "vpu-5";
> >> + infracfg = <&infracfg>;
> >> + smi_comm = <&smi_common>;
> >> + };
> >> +
> >> apmixedsys: syscon@1000c000 {
> >> compatible = "mediatek,mt8183-apmixedsys", "syscon";
> >> reg = <0 0x1000c000 0 0x1000>;
> >> @@ -260,6 +317,11 @@
> >> #clock-cells = <1>;
> >> };
> >>
> >> + smi_common: smi@14019000 {
> >> + compatible = "mediatek,mt8183-smi-common", "syscon";
> >> + reg = <0 0x14019000 0 0x1000>;
> >> + };
> >> +
> >> imgsys: syscon@15020000 {
> >> compatible = "mediatek,mt8183-imgsys", "syscon";
> >> reg = <0 0x15020000 0 0x1000>;
> >
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: Emit __gnu_mcount_nc when using Clang 10.0.0 or newer
From: Stefan Agner @ 2019-08-29 7:57 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Arnd Bergmann, Nick Desaulniers, Russell King, linux-kernel,
clang-built-linux, Matthias Kaehlcke, linux-arm-kernel
In-Reply-To: <20190829062635.45609-1-natechancellor@gmail.com>
On 2019-08-29 08:26, Nathan Chancellor wrote:
> Currently, multi_v7_defconfig + CONFIG_FUNCTION_TRACER fails to build
> with clang:
>
> arm-linux-gnueabi-ld: kernel/softirq.o: in function `_local_bh_enable':
> softirq.c:(.text+0x504): undefined reference to `mcount'
> arm-linux-gnueabi-ld: kernel/softirq.o: in function `__local_bh_enable_ip':
> softirq.c:(.text+0x58c): undefined reference to `mcount'
> arm-linux-gnueabi-ld: kernel/softirq.o: in function `do_softirq':
> softirq.c:(.text+0x6c8): undefined reference to `mcount'
> arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_enter':
> softirq.c:(.text+0x75c): undefined reference to `mcount'
> arm-linux-gnueabi-ld: kernel/softirq.o: in function `irq_exit':
> softirq.c:(.text+0x840): undefined reference to `mcount'
> arm-linux-gnueabi-ld: kernel/softirq.o:softirq.c:(.text+0xa50): more
> undefined references to `mcount' follow
>
> clang can emit a working mcount symbol, __gnu_mcount_nc, when
> '-meabi gnu' is passed to it. Until r369147 in LLVM, this was
> broken and caused the kernel not to boot because the calling
> convention was not correct. Now that it is fixed, add this to
> the command line when clang is 10.0.0 or newer so everything
> works properly.
Cool, finally function tracing with Clang :-)
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/35
> Link: https://bugs.llvm.org/show_bug.cgi?id=33845
> Link:
> https://github.com/llvm/llvm-project/commit/16fa8b09702378bacfa3d07081afe6b353b99e60
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
--
Stefan
> ---
> arch/arm/Makefile | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index c3624ca6c0bc..7b5a26a866fc 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -112,6 +112,12 @@ ifeq ($(CONFIG_ARM_UNWIND),y)
> CFLAGS_ABI +=-funwind-tables
> endif
>
> +ifeq ($(CONFIG_CC_IS_CLANG),y)
> +ifeq ($(shell test $(CONFIG_CLANG_VERSION) -ge 100000; echo $$?),0)
> +CFLAGS_ABI +=-meabi gnu
> +endif
> +endif
> +
> # Accept old syntax despite ".syntax unified"
> AFLAGS_NOWARN :=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv5 2/2] ARM: dts: Add support for i.MX6 UltraLite DART Variscite Customboard
From: Marco Felsch @ 2019-08-29 7:54 UTC (permalink / raw)
To: Oliver Graute
Cc: Mark Rutland, devicetree, narmstrong, Fabio Estevam, Sascha Hauer,
linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, shawnguo, linux-arm-kernel
In-Reply-To: <1567009160-21965-3-git-send-email-oliver.graute@gmail.com>
Hi Oliver,
On 19-08-28 18:19, Oliver Graute wrote:
> This patch adds DeviceTree Source for the i.MX6 UltraLite DART NAND/WIFI
>
> Signed-off-by: Oliver Graute <oliver.graute@gmail.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx6ul-var-6ulcustomboard.dts | 196 ++++++++++++++++++++++++
> 2 files changed, 197 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6ul-var-6ulcustomboard.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index a24a6a1..a2a69e4 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -579,6 +579,7 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
> imx6ul-tx6ul-0010.dtb \
> imx6ul-tx6ul-0011.dtb \
> imx6ul-tx6ul-mainboard.dtb \
> + imx6ul-var-6ulcustomboard.dtb \
> imx6ull-14x14-evk.dtb \
> imx6ull-colibri-eval-v3.dtb \
> imx6ull-colibri-wifi-eval-v3.dtb \
> diff --git a/arch/arm/boot/dts/imx6ul-var-6ulcustomboard.dts b/arch/arm/boot/dts/imx6ul-var-6ulcustomboard.dts
> new file mode 100644
> index 00000000..1861b34
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6ul-var-6ulcustomboard.dts
> @@ -0,0 +1,196 @@
> +// SPDX-License-Identifier: (GPL-2.0)
> +/*
> + * Support for Variscite DART-6UL Module
> + *
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + * Copyright (C) 2015-2016 Variscite Ltd. - http://www.variscite.com
> + * Copyright (C) 2018-2019 Oliver Graute <oliver.graute@gmail.com>
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/input/input.h>
> +#include "imx6ul-imx6ull-var-dart-common.dtsi"
> +
> +/ {
> + model = "Variscite i.MX6 UltraLite Carrier-board";
> + compatible = "variscite,6ulcustomboard", "fsl,imx6ul";
> +
> + backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm1 0 20000>;
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + default-brightness-level = <6>;
> + status = "okay";
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + user {
> + gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
Please mux the gpios where you need them. In this case mux it within the
gpio-keys node.
> + linux,code = <KEY_BACK>;
> + gpio-key,wakeup;
> + };
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + d16-led {
> + gpios = <&gpio4 20 GPIO_ACTIVE_HIGH>;
The same applies here.
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +
> + sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "wm8731audio";
> + simple-audio-card,widgets =
> + "Headphone", "Headphone Jack",
> + "Line", "Line Jack",
> + "Microphone", "Mic Jack";
> + simple-audio-card,routing =
> + "Headphone Jack", "RHPOUT",
> + "Headphone Jack", "LHPOUT",
> + "LLINEIN", "Line Jack",
> + "RLINEIN", "Line Jack",
> + "MICIN", "Mic Bias",
> + "Mic Bias", "Mic Jack";
> + simple-audio-card,format = "i2s";
> + simple-audio-card,bitclock-master = <&sound_master>;
> + simple-audio-card,frame-master = <&sound_master>;
> +
> + sound_master: simple-audio-card,cpu {
> + sound-dai = <&sai2>;
> + };
Where is the codec node?
> + };
> +};
> +
> +&can1 {
> + status = "okay";
We need to move the complete muxing from the SoM dtsi to the baseboard
for all baseboard related nodes.. I tought that the Dart 6UL layout
follows a specific standard but that isn't the case.
> +};
> +
> +&can2 {
> + status = "okay";
> +};
> +
> +&fec1 {
> + phy-mode = "rgmii";
This avoid such re-assigning here too. Also the imx6ul only support
10/100 Mbit/s. So rgmii makes no sense here.
> + phy-reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
> + phy-handle = <ðphy0>;
> + status = "okay";
> +};
> +
> +&fec2 {
> + phy-mode = "rgmii";
> + phy-reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
> + phy-handle = <ðphy1>;
> + status = "okay";
> +};
> +
> +&i2c1 {
> + clock-frequency = <400000>;
> + status = "okay";
> +};
> +
> +&i2c2 {
> + clock_frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c2>;
> + status = "okay";
> +
> + wm8731: audio-codec@1a {
> + #sound-dai-cells = <0>;
Please move #sound-dai-cells below compatible and reg property.
> + compatible = "wlf,wm8731";
> + reg = <0x1a>;
> + clocks = <&clks IMX6UL_CLK_SAI2>;
> + clock-names = "mclk";
> + };
> +
> + touchscreen@38 {
> + compatible = "edt,edt-ft5x06";
> + reg = <0x38>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <4 0>;
Make use of IRQ_TYPE_*
> + touchscreen-size-x = <800>;
> + touchscreen-size-y = <480>;
> + touchscreen-inverted-x;
> + touchscreen-inverted-y;
> + wakeup-source;
> + };
> +
> + rtc@68 {
> + compatible = "dallas,ds1337";
> + reg = <0x68>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_rtc>;
> + interrupt-parent = <&gpio5>;
> + interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
> + };
> +};
> +
> +&lcdif {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lcdif>;
> + display = <&display0>;
> + status = "okay";
> +
> + display0: display0 {
> + bits-per-pixel = <16>;
> + bus-width = <24>;
> +
> + display-timings {
> + native-mode = <&timing0>;
> + timing0: timing0 {
> + clock-frequency =<35000000>;
> + hactive = <800>;
> + vactive = <480>;
> + hfront-porch = <40>;
> + hback-porch = <40>;
> + hsync-len = <48>;
> + vback-porch = <29>;
> + vfront-porch = <13>;
> + vsync-len = <3>;
> + hsync-active = <0>;
> + vsync-active = <0>;
> + de-active = <1>;
> + pixelclk-active = <0>;
> + };
> + };
> + };
> +};
> +
> +&pwm1 {
> + status = "okay";
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> +
> +&uart2 {
> + status = "okay";
> +};
> +
> +&uart3 {
> + status = "okay";
> +};
> +
> +&usbotg1 {
> + dr_mode = "host";
> + status = "okay";
> +};
> +
> +&usbotg2 {
> + dr_mode = "host";
> + status = "okay";
> +};
> +
> +&iomuxc {
> + pinctrl_rtc: rtcgrp {
> + fsl,pins = <
> + MX6UL_PAD_SNVS_TAMPER7__GPIO5_IO07 0x1b0b0
> + >;
> + };
As I said above, move the complete muxing pwm/usb/i2c/lcd/... from the
som dtsi to the baseboard dts because it is only valid for this
baseboard. Another baseboard using this som can have a complete
different mux option.
Regards,
Marco
> +};
> --
> 2.7.4
>
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: dts: ls1028a: fix a compatible issue
From: Yuantian Tang @ 2019-08-29 7:34 UTC (permalink / raw)
To: shawnguo
Cc: mark.rutland, devicetree, Yuantian Tang, leoyang.li, robh+dt,
linux-arm-kernel
The I2C multiplexer used on ls1028aqds is PCA9547, not PCA9847.
So correct it.
Signed-off-by: Yuantian Tang <andy.tang@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
index 5e14e5a19744..f5da9e8b0d9d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
@@ -107,7 +107,7 @@
status = "okay";
i2c-mux@77 {
- compatible = "nxp,pca9847";
+ compatible = "nxp,pca9547";
reg = <0x77>;
#address-cells = <1>;
#size-cells = <0>;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v5 0/2] arm64: dts: ti: k3: Update the power-domain cells
From: Tero Kristo @ 2019-08-29 7:31 UTC (permalink / raw)
To: Lokesh Vutla, Nishanth Menon, Santosh Shilimkar, Rob Herring
Cc: Device Tree Mailing List, Sekhar Nori, Linux ARM Mailing List
In-Reply-To: <9aa7eeaf-36ee-3d5f-9654-d8fa37577877@ti.com>
On 20/08/2019 15:48, Lokesh Vutla wrote:
>
>
> On 29/07/19 6:00 PM, Lokesh Vutla wrote:
>> Update the power-domains cells on all K3 based devices to reflect
>> exclusive and shared permissions in each device.
>
> Gentle Ping on this series.
>
> Thanks and regards,
> Lokesh
>
This can't be merged until the driver portion is in. I could probably
live with an immutable branch though.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv5 1/2] ARM: dts: imx6ul: Add Variscite DART-6UL SoM support
From: Marco Felsch @ 2019-08-29 7:28 UTC (permalink / raw)
To: Oliver Graute
Cc: Mark Rutland, devicetree, narmstrong, Fabio Estevam, Sascha Hauer,
linux-kernel, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, shawnguo, linux-arm-kernel
In-Reply-To: <1567009160-21965-2-git-send-email-oliver.graute@gmail.com>
Hi Oliver,
thanks for the patch.
On 19-08-28 18:19, Oliver Graute wrote:
> This patch adds support for the i.MX6UL variant of the Variscite DART-6UL
> SoM Carrier-Board
>
> Signed-off-by: Oliver Graute <oliver.graute@gmail.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../boot/dts/imx6ul-imx6ull-var-dart-common.dtsi | 445 +++++++++++++++++++++
Is it a imx6ul or a imx6ull? Also can you add a changelog the next time?
> 1 file changed, 445 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6ul-imx6ull-var-dart-common.dtsi
>
> diff --git a/arch/arm/boot/dts/imx6ul-imx6ull-var-dart-common.dtsi b/arch/arm/boot/dts/imx6ul-imx6ull-var-dart-common.dtsi
> new file mode 100644
> index 00000000..f345d69
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6ul-imx6ull-var-dart-common.dtsi
> @@ -0,0 +1,445 @@
> +// SPDX-License-Identifier: (GPL-2.0)
> +/dts-v1/;
> +
> +#include "imx6ul.dtsi"
> +/ {
> + chosen {
> + stdout-path = &uart1;
You specify uart1 here and disable the node below... That seems wrong to
me.
> + };
> +
> + memory@80000000 {
> + device_type = "memory";
> + reg = <0x80000000 0x20000000>;
> + };
> +
> + touch_3v3_regulator: regulator-touch-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "touch_3v3_supply";
> + regulator-always-on;
Why is it always-on?
> + };
Please name the phandle reg_touch_3v3 and specify the
regulator-min-microvolt/regulator-max-microvolt properties.
> +
> + reg_sd1_vmmc: regulator-sd1-vmmc {
> + compatible = "regulator-fixed";
> + regulator-name = "VSD_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + reg_gpio_dvfs: regulator-gpio {
> + compatible = "regulator-gpio";
> + regulator-min-microvolt = <1300000>;
> + regulator-max-microvolt = <1400000>;
> + regulator-name = "gpio_dvfs";
> + regulator-type = "voltage";
> + gpios = <&gpio4 13 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + states = <1300000 0x1 1400000 0x0>;
> + };
> +
> + rmii_ref_clk: clock-rmii-ref {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <25000000>;
> + clock-output-names = "rmii-ref";
> + };
Alphabetical ordering please and please rename the phandle to
clk_rmii_ref or something.
> +
> +};
> +
> +&adc1 {
> + vref-supply = <&touch_3v3_regulator>;
> + status = "okay";
> +};
> +
> +&can1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flexcan1>;
> + status = "disabled";
No need to disable it here, it is disabled in the SoC DT.
> +};
> +
> +&can2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flexcan2>;
> + status = "disabled";
Here too.
> +};
> +
> +&cpu0 {
> + arm-supply = <®_arm>;
> + soc-supply = <®_soc>;
> +};
> +
> +&fec1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enet1>;
> + phy-mode = "rmii";
> + status = "disabled";
And here.
> +};
> +
> +&fec2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enet2>;
> + phy-mode = "rmii";
> + status = "disabled";
And here.
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy0: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + micrel,rmii-reference-clock-select-25-mhz;
> + clocks = <&rmii_ref_clk>;
> + clock-names = "rmii-ref";
Do we need to specify the clock-names?
> + reg = <1>;
> + };
> +
> + ethphy1: ethernet-phy@3 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + micrel,rmii-reference-clock-select-25-mhz;
> + clocks = <&rmii_ref_clk>;
> + clock-names = "rmii-ref";
> + reg = <3>;
> + };
> + };
> +};
> +
> +&gpmi {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpmi_nand>;
> + status = "okay";
> +
> + partition@0 {
> + label = "spl";
> + reg = <0x00000000 0x00200000>;
> + };
> +
> + partition@200000 {
> + label = "uboot";
> + reg = <0x00200000 0x00200000>;
> + };
> +
> + partition@400000 {
> + label = "uboot-env";
> + reg = <0x00400000 0x00200000>;
> + };
> +
> + partition@600000 {
> + label = "kernel";
> + reg = <0x00600000 0x00800000>;
> + };
> +
> + partition@e00000 {
> + label = "rootfs";
> + reg = <0x00e00000 0x3f200000>;
> + };
Nope, partitions must be within a subnode. Please check
Documentation/devicetree/bindings/mtd/partition.txt.
> +};
> +
> +&i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c1>;
> + status = "disabled";
Drop the status line.
> +};
> +
> +&i2c2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c2>;
> + status = "disabled";
Drop the status line.
> +};
> +
> +&pwm1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm1>;
> + status = "disabled";
Drop the status line.
> +};
> +
> +&sai2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_sai2>;
> + assigned-clocks = <&clks IMX6UL_CLK_SAI2_SEL>,
> + <&clks IMX6UL_CLK_SAI2>;
> + assigned-clock-parents = <&clks IMX6UL_CLK_PLL4_AUDIO_DIV>;
> + assigned-clock-rates = <0>, <12288000>;
> + fsl,sai-mclk-direction-output;
> + status = "okay";
> +};
> +
> +&snvs_poweroff {
> + status = "okay";
> +};
> +
> +&snvs_rtc {
> + status = "disabled";
> +};
> +
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart1>;
> + status = "disabled";
No need.
> +};
> +
> +&uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart2>;
> + uart-has-rtscts;
> + status = "disabled";
No need.
> +};
> +
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart3>;
> + uart-has-rtscts;
> + status = "disabled";
No need.
> +};
> +
> +&usbotg1 {
> + disable-over-current;
> + status = "disabled";
No need.
> +};
> +
> +&usbotg2 {
> + disable-over-current;
> + status = "disabled";
No need.
> +};
> +
> +&usdhc1 {
> + pinctrl-names = "default", "state_100mhz", "state_200mhz";
> + pinctrl-0 = <&pinctrl_usdhc1>;
> + pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
> + pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
> + no-1-8-v;
> + keep-power-in-suspend;
> + vmmc-supply = <®_sd1_vmmc>;
I tought the highspeed modes using 1.8V signal levels.
> + non-removable;
Please specify the bus-with too. BTW. is it a SD-Card or an eMMC?
> + status = "okay";
> +};
> +
> +&usdhc2 {
> + status = "disabled";
> +};
Remove the whole node.
> +&wdog1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_wdog>;
> + fsl,ext-reset-output;
> +};
> +
> +&iomuxc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hog>;
> +
> + pinctrl_enet1: enet1grp {
> + fsl,pins = <
> + MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0
> + MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0
> + MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0
> + MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0
> + MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0
> + MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
> + MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
> + MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031
> + >;
> + };
> +
> + pinctrl_enet2: enet2grp {
> + fsl,pins = <
> + MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN 0x1b0b0
> + MX6UL_PAD_ENET2_RX_ER__ENET2_RX_ER 0x1b0b0
> + MX6UL_PAD_ENET2_RX_DATA0__ENET2_RDATA00 0x1b0b0
> + MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01 0x1b0b0
> + MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN 0x1b0b0
> + MX6UL_PAD_ENET2_TX_DATA0__ENET2_TDATA00 0x1b0b0
> + MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01 0x1b0b0
> + MX6UL_PAD_ENET2_TX_CLK__ENET2_REF_CLK2 0x4001b031
> + MX6UL_PAD_GPIO1_IO07__ENET2_MDC 0x1b0b0
> + MX6UL_PAD_GPIO1_IO06__ENET2_MDIO 0x1b0b0
> + MX6UL_PAD_JTAG_MOD__GPIO1_IO10 0x1b0b0
> + >;
> + };
> +
> + pinctrl_flexcan1: flexcan1grp{
> + fsl,pins = <
> + MX6UL_PAD_LCD_DATA09__FLEXCAN1_RX 0x1b020
> + MX6UL_PAD_LCD_DATA08__FLEXCAN1_TX 0x1b020
> + >;
> + };
> +
> + pinctrl_flexcan2: flexcan2grp{
> + fsl,pins = <
> + MX6UL_PAD_UART2_RTS_B__FLEXCAN2_RX 0x1b020
> + MX6UL_PAD_UART2_CTS_B__FLEXCAN2_TX 0x1b020
> + >;
> + };
> +
> + pinctrl_gpio_leds: gpioledsgrp {
> + fsl,pins = <
> + MX6UL_PAD_CSI_HSYNC__GPIO4_IO20 0x1b0b0
> + MX6UL_PAD_GPIO1_IO00__GPIO1_IO00 0x17059
> + >;
> + };
You didn't reference that node.
> +
> + pinctrl_gpmi_nand: gpminandgrp {
> + fsl,pins = <
> + MX6UL_PAD_NAND_CLE__RAWNAND_CLE 0xb0b1
> + MX6UL_PAD_NAND_ALE__RAWNAND_ALE 0xb0b1
> + MX6UL_PAD_NAND_WP_B__RAWNAND_WP_B 0xb0b1
> + MX6UL_PAD_NAND_READY_B__RAWNAND_READY_B 0xb000
> + MX6UL_PAD_NAND_CE0_B__RAWNAND_CE0_B 0xb0b1
> + MX6UL_PAD_NAND_CE1_B__RAWNAND_CE1_B 0xb0b1
> + MX6UL_PAD_NAND_RE_B__RAWNAND_RE_B 0xb0b1
> + MX6UL_PAD_NAND_WE_B__RAWNAND_WE_B 0xb0b1
> + MX6UL_PAD_NAND_DATA00__RAWNAND_DATA00 0xb0b1
> + MX6UL_PAD_NAND_DATA01__RAWNAND_DATA01 0xb0b1
> + MX6UL_PAD_NAND_DATA02__RAWNAND_DATA02 0xb0b1
> + MX6UL_PAD_NAND_DATA03__RAWNAND_DATA03 0xb0b1
> + MX6UL_PAD_NAND_DATA04__RAWNAND_DATA04 0xb0b1
> + MX6UL_PAD_NAND_DATA05__RAWNAND_DATA05 0xb0b1
> + MX6UL_PAD_NAND_DATA06__RAWNAND_DATA06 0xb0b1
> + MX6UL_PAD_NAND_DATA07__RAWNAND_DATA07 0xb0b1
> + >;
> + };
> +
> + pinctrl_hog: hoggrp {
> + fsl,pins = <
> + MX6UL_PAD_GPIO1_IO03__OSC32K_32K_OUT 0x03029
> + >;
> + };
> +
> + pinctrl_i2c1: i2c1grp {
> + fsl,pins = <
> + MX6UL_PAD_UART4_TX_DATA__I2C1_SCL 0x4001b8b0
> + MX6UL_PAD_UART4_RX_DATA__I2C1_SDA 0x4001b8b0
> + >;
> + };
> +
> + pinctrl_i2c2: i2c2grp {
> + fsl,pins = <
> + MX6UL_PAD_UART5_TX_DATA__I2C2_SCL 0x4001b8b0
> + MX6UL_PAD_UART5_RX_DATA__I2C2_SDA 0x4001b8b0
> + >;
> + };
> +
> + pinctrl_lcdif: lcdif {
> + fsl,pins = <
> + MX6UL_PAD_LCD_DATA02__LCDIF_DATA02 0x79
> + MX6UL_PAD_LCD_DATA03__LCDIF_DATA03 0x79
> + MX6UL_PAD_LCD_DATA04__LCDIF_DATA04 0x79
> + MX6UL_PAD_LCD_DATA05__LCDIF_DATA05 0x79
> + MX6UL_PAD_LCD_DATA06__LCDIF_DATA06 0x79
> + MX6UL_PAD_LCD_DATA07__LCDIF_DATA07 0x79
> + MX6UL_PAD_LCD_DATA10__LCDIF_DATA10 0x79
> + MX6UL_PAD_LCD_DATA11__LCDIF_DATA11 0x79
> + MX6UL_PAD_LCD_DATA12__LCDIF_DATA12 0x79
> + MX6UL_PAD_LCD_DATA13__LCDIF_DATA13 0x79
> + MX6UL_PAD_LCD_DATA14__LCDIF_DATA14 0x79
> + MX6UL_PAD_LCD_DATA15__LCDIF_DATA15 0x79
> + MX6UL_PAD_LCD_DATA18__LCDIF_DATA18 0x79
> + MX6UL_PAD_LCD_DATA19__LCDIF_DATA19 0x79
> + MX6UL_PAD_LCD_DATA20__LCDIF_DATA20 0x79
> + MX6UL_PAD_LCD_DATA21__LCDIF_DATA21 0x79
> + MX6UL_PAD_LCD_DATA22__LCDIF_DATA22 0x79
> + MX6UL_PAD_LCD_DATA23__LCDIF_DATA23 0x79
> + MX6UL_PAD_LCD_CLK__LCDIF_CLK 0x79
> + MX6UL_PAD_LCD_ENABLE__LCDIF_ENABLE 0x79
> + >;
> + };
You didn't reference that.
> +
> + pinctrl_pwm1: pwm1grp {
> + fsl,pins = <
> + MX6UL_PAD_LCD_DATA00__PWM1_OUT 0x110b0
> + >;
> + };
> +
> + pinctrl_sai1: sai1grp {
> + fsl,pins = <
> + MX6UL_PAD_CSI_DATA05__SAI1_TX_BCLK 0x11088
> + MX6UL_PAD_CSI_DATA04__SAI1_TX_SYNC 0x17088
> + MX6UL_PAD_CSI_DATA06__SAI1_RX_DATA 0x11088
> + MX6UL_PAD_CSI_DATA07__SAI1_TX_DATA 0x11088
> + >;
> + };
You didn't reference that.
> + pinctrl_sai2: sai2grp {
> + fsl,pins = <
> + MX6UL_PAD_JTAG_TDI__SAI2_TX_BCLK 0x17088
> + MX6UL_PAD_JTAG_TDO__SAI2_TX_SYNC 0x17088
> + MX6UL_PAD_JTAG_TRST_B__SAI2_TX_DATA 0x11088
> + MX6UL_PAD_JTAG_TCK__SAI2_RX_DATA 0x11088
> + MX6UL_PAD_JTAG_TMS__SAI2_MCLK 0x17088
> + >;
> + };
> +
> + pinctrl_tsc: tscgrp {
> + fsl,pins = <
> + MX6UL_PAD_GPIO1_IO01__GPIO1_IO01 0xb0
> + MX6UL_PAD_GPIO1_IO02__GPIO1_IO02 0xb0
> + MX6UL_PAD_GPIO1_IO03__GPIO1_IO03 0xb0
> + MX6UL_PAD_GPIO1_IO04__GPIO1_IO04 0xb0
> + >;
> + };
You didn't reference that.
> + pinctrl_uart1: uart1grp {
> + fsl,pins = <
> + MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
> + MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
> + >;
> + };
> +
> + pinctrl_uart2: uart2grp {
> + fsl,pins = <
> + MX6UL_PAD_UART2_TX_DATA__UART2_DCE_TX 0x1b0b1
> + MX6UL_PAD_UART2_RX_DATA__UART2_DCE_RX 0x1b0b1
> + MX6UL_PAD_UART2_CTS_B__UART2_DCE_CTS 0x1b0b1
> + MX6UL_PAD_UART2_RTS_B__UART2_DCE_RTS 0x1b0b1
> + >;
> + };
> +
> + pinctrl_uart3: uart3grp {
> + fsl,pins = <
> + MX6UL_PAD_UART3_TX_DATA__UART3_DCE_TX 0x1b0b1
> + MX6UL_PAD_UART3_RX_DATA__UART3_DCE_RX 0x1b0b1
> + MX6UL_PAD_UART3_CTS_B__UART3_DCE_CTS 0x1b0b1
> + MX6UL_PAD_UART3_RTS_B__UART3_DCE_RTS 0x1b0b1
> + >;
> + };
> +
> + pinctrl_usdhc1: usdhc1grp {
> + fsl,pins = <
> + MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
> + MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x17059
> + MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
> + MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
> + MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
> + MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
> + MX6UL_PAD_CSI_VSYNC__GPIO4_IO19 0x1b0b1
> + >;
> + };
> +
> + pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
> + fsl,pins = <
> + MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x170b9
> + MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x100b9
> + MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x170b9
> + MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x170b9
> + MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x170b9
> + MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x170b9
> + MX6UL_PAD_CSI_VSYNC__GPIO4_IO19 0x1b0b1
> + >;
> + };
> +
> + pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
> + fsl,pins = <
> + MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x170f9
> + MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x100f9
> + MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x170f9
> + MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x170f9
> + MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x170f9
> + MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x170f9
> + MX6UL_PAD_CSI_VSYNC__GPIO4_IO19 0x1b0b1
> + >;
> + };
> +
> + pinctrl_wdog: wdoggrp {
> + fsl,pins = <
> + MX6UL_PAD_GPIO1_IO08__WDOG1_WDOG_B 0x78b0
> + >;
> + };
> +};
> --
> 2.7.4
>
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH V9 1/3] perf: imx8_ddr_perf: add AXI ID filter support
From: Joakim Zhang @ 2019-08-29 7:26 UTC (permalink / raw)
To: Will Deacon
Cc: mark.rutland@arm.com, Frank Li, robin.murphy@arm.com,
dl-linux-imx, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190828134427.z4zmqucm7fcuuies@willie-the-truck>
> -----Original Message-----
> From: Will Deacon <will@kernel.org>
> Sent: 2019年8月28日 21:44
> To: Joakim Zhang <qiangqing.zhang@nxp.com>
> Cc: mark.rutland@arm.com; robin.murphy@arm.com; Frank Li
> <frank.li@nxp.com>; dl-linux-imx <linux-imx@nxp.com>;
> linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH V9 1/3] perf: imx8_ddr_perf: add AXI ID filter support
>
> On Wed, Aug 28, 2019 at 12:07:52PM +0000, Joakim Zhang wrote:
> > AXI filtering is used by CSV modes 0x41 and 0x42 to count reads or
> > writes with an ARID or AWID matching filter setting. Granularity is at
> > subsystem level. Implementation does not allow filtring between
> > masters within a subsystem. Filter is defined with 2 configuration
> parameters.
> >
> > --AXI_ID defines AxID matching value
> > --AXI_MASKING defines which bits of AxID are meaningful for the matching
> > 0：corresponding bit is masked
> > 1: corresponding bit is not masked, i.e. used to do the matching
> >
> > When non-masked bits are matching corresponding AXI_ID bits then
> > counter is incremented. This filter allows counting read or write
> > access from a subsystem or multiple subsystems.
> >
> > Perf counter is incremented if AxID && AXI_MASKING == AXI_ID &&
> > AXI_MASKING
> >
> > AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance
> counter.
> >
> > Read and write AXI ID filter should write same value to DPCR1 if want
> > to specify at the same time as this filter is shared between counters.
> >
> > e.g.
> > perf stat -a -e imx8_ddr0/axid-read,axi_mask=0xMMMM,axi_id=0xDDDD/
> cmd
> > perf stat -a -e imx8_ddr0/axid-write,axi_mask=0xMMMM,axi_id=0xDDDD/
> > cmd
> >
> > NOTE: axi_mask is inverted in userspace(i.e. set bits are bits to
> > mask), and it will be reverted in driver automatically. so that the
> > user can just specify axi_id to monitor a specific id, rather than having to
> specify axi_mask.
> > e.g.
> > perf stat -a -e imx8_ddr0/axid-read,axi_id=0x12/ cmd, which will
> > monitor ARID=0x12
> >
> > Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
>
> Thanks, I've pushed this series out to:
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern
> el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fwill%2Flinux.git%2Flog%2F
> %3Fh%3Dfor-next%2Fperf&data=02%7C01%7Cqiangqing.zhang%40nxp.c
> om%7C547006e0cf704b87bda808d72bbddc77%7C686ea1d3bc2b4c6fa92cd99c
> 5c301635%7C0%7C0%7C637025966766610086&sdata=zaeqH%2BFvoN%
> 2BiAjrl1%2FnDTTF30LFNcJBYgtFQXwx3MeM%3D&reserved=0
>
> and plan to send it for 5.4. I did rewrite the commit messages, so please take a
> look. I also folded the other two patches together.
>
> Thanks,
Thanks Will. The commit messages rewrote is fine for me.
I have another question want to ask you, could you give me some suggestions?
# perf stat -a -e imx8_ddr0/axid-read,axi_mask=0xf,axi_id=0x10/ cmd
It will count all read transactions from AXI IDs 0x10 - 0x1f. If we suppose these 16 IDs are for GPU Subsystem, with above configuration we may want to monitor all read
transactions from GPU subsystem. However, it is tedious for user to configure, they may not know the AXI IDs map, had better we can configure like below, the GPU string is more straightforward.
# perf stat -a -e imx8_ddr0/axid-read,"GPU"/ cmd
which "GPU" string is same with "axi_mask=0xf,axi_id=0x10".
Best Regards,
Joakim Zhang
> Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] input: keyboard: snvs_pwrkey: Send key events for i.MX6 S, DL and Q
From: robin @ 2019-08-29 7:24 UTC (permalink / raw)
To: Marco Felsch
Cc: Mark Rutland, devicetree @ vger . kernel . org, Fabio Estevam,
Adam Ford, Sascha Hauer, Dmitry Torokhov,
linux-kernel @ vger . kernel . org, Rob Herring, dl-linux-imx,
Pengutronix Kernel Team, linux-input @ vger . kernel . org,
Robin Gong, Shawn Guo, linux-arm-kernel @ lists . infradead . org
In-Reply-To: <20190828091550.pdc57wanu6twew5p@pengutronix.de>
Hi Marco,
On 2019-08-28 11:15, Marco Felsch wrote:
> Hi Robin,
>
> thanks for the patch.
>
> On 19-08-27 14:32, Robin van der Gracht wrote:
>> The first generation i.MX6 processors does not send an interrupt when
>> the
>> power key is pressed. It sends a power down request interrupt if the
>> key is
>> released before a hard shutdown (5 second press). This should allow
>> software to bring down the SoC safely.
>>
>> For this driver to work as a regular power key with the older SoCs, we
>> need
>> to send a keypress AND release when we get the power down request irq.
>>
>> Signed-off-by: Robin van der Gracht <robin@protonic.nl>
>> ---
>> .../devicetree/bindings/crypto/fsl-sec4.txt | 16 ++++--
>> drivers/input/keyboard/Kconfig | 2 +-
>> drivers/input/keyboard/snvs_pwrkey.c | 52
>> ++++++++++++++++---
>
> Can we split this so the dt-bindings are a standalone patch? IMHO this
> is the usual way because the maintainer can squash them on there needs.
Not sure what you mean, do you want me to make a separate patch for the
devicetree binding documentation here?
> Also it would be cool to document the changes. A common place for
> changes is after the '---' or on the cover-letter.
Agreed!
v1 -> v2:
- Nolonger altering the existing compatible string, just add a second
one.
- Moved the event emiting work out of the irq handler to the timer
handler.
- Assign hwtype directly to of_device_id->data instead of a struct
platform_device_id entry which has it's .driver_data set to hwtype.
- Document the new device tree binding.
- Update commit message to make more clear why we want to make this
change.
>
>> 3 files changed, 57 insertions(+), 13 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
>> b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
>> index 2fe245ca816a..e4fbb9797082 100644
>> --- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
>> +++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
>> @@ -420,14 +420,22 @@ EXAMPLE
>> =====================================================================
>> System ON/OFF key driver
>>
>> - The snvs-pwrkey is designed to enable POWER key function which
>> controlled
>> - by SNVS ONOFF, the driver can report the status of POWER key and
>> wakeup
>> - system if pressed after system suspend.
>> + The snvs-pwrkey is designed to enable POWER key function which is
>> controlled
>> + by SNVS ONOFF. It can wakeup the system if pressed after system
>> suspend.
>> +
>> + There are two generations of SVNS pwrkey hardware. The first
>> generation is
>> + included in i.MX6 Solo, DualLite and Quad processors. The second
>> generation
>> + is included in i.MX6 SoloX and newer SoCs.
>> +
>> + Second generation SNVS can detect and report the status of POWER
>> key, but the
>> + first generation can only detect a key release and so emits an
>> instantaneous
>> + press and release event when the key is released.
>>
>> - compatible:
>> Usage: required
>> Value type: <string>
>> - Definition: Mush include "fsl,sec-v4.0-pwrkey".
>> + Definition: Must include "fsl,sec-v4.0-pwrkey" for i.MX6 SoloX
>> and newer
>> + or "fsl,imx6qdl-snvs-pwrkey" for older SoCs.
>>
>> - interrupts:
>> Usage: required
>> diff --git a/drivers/input/keyboard/Kconfig
>> b/drivers/input/keyboard/Kconfig
>> index 7c4f19dab34f..937e58da5ce1 100644
>> --- a/drivers/input/keyboard/Kconfig
>> +++ b/drivers/input/keyboard/Kconfig
>> @@ -436,7 +436,7 @@ config KEYBOARD_SNVS_PWRKEY
>> depends on OF
>> help
>> This is the snvs powerkey driver for the Freescale i.MX
>> application
>> - processors that are newer than i.MX6 SX.
>> + processors.
>>
>> To compile this driver as a module, choose M here; the
>> module will be called snvs_pwrkey.
>> diff --git a/drivers/input/keyboard/snvs_pwrkey.c
>> b/drivers/input/keyboard/snvs_pwrkey.c
>> index 5342d8d45f81..d71c44733103 100644
>> --- a/drivers/input/keyboard/snvs_pwrkey.c
>> +++ b/drivers/input/keyboard/snvs_pwrkey.c
>> @@ -29,6 +29,11 @@
>> #define DEBOUNCE_TIME 30
>> #define REPEAT_INTERVAL 60
>>
>> +enum imx_snvs_hwtype {
>> + IMX6SX_SNVS, /* i.MX6 SoloX and newer */
>> + IMX6QDL_SNVS, /* i.MX6 Solo, DualLite and Quad */
>> +};
>> +
>> struct pwrkey_drv_data {
>> struct regmap *snvs;
>> int irq;
>> @@ -37,14 +42,41 @@ struct pwrkey_drv_data {
>> int wakeup;
>> struct timer_list check_timer;
>> struct input_dev *input;
>> + enum imx_snvs_hwtype hwtype;
>> };
>>
>> +static const struct of_device_id imx_snvs_pwrkey_ids[] = {
>> + {
>> + .compatible = "fsl,sec-v4.0-pwrkey",
>> + .data = (const void *)IMX6SX_SNVS,
>> + },
>> + {
>> + .compatible = "fsl,imx6qdl-snvs-pwrkey",
>> + .data = (const void *)IMX6QDL_SNVS,
>> + },
>> + { /* sentinel */ },
>> +};
>> +MODULE_DEVICE_TABLE(of, imx_snvs_pwrkey_ids);
>
> Can we keep this on the original place if you are using ...
>
>> +
>> static void imx_imx_snvs_check_for_events(struct timer_list *t)
>> {
>> struct pwrkey_drv_data *pdata = from_timer(pdata, t, check_timer);
>> struct input_dev *input = pdata->input;
>> u32 state;
>>
>> + if (pdata->hwtype == IMX6QDL_SNVS) {
>> + /*
>> + * The first generation i.MX6 SoCs only sends an interrupt on
>> + * button release. To mimic power-key usage, we'll prepend a
>> + * press event.
>> + */
>> + input_report_key(input, pdata->keycode, 1);
>
> Missing input_sync() here?
Yes you are right. Odd that systemd powerkey handling didn't complain.
>
>> + input_report_key(input, pdata->keycode, 0);
>> + input_sync(input);
>> + pm_relax(input->dev.parent);
>> + return;
>> + }
>> +
>> regmap_read(pdata->snvs, SNVS_HPSR_REG, &state);
>> state = state & SNVS_HPSR_BTN ? 1 : 0;
>>
>> @@ -67,13 +99,17 @@ static irqreturn_t imx_snvs_pwrkey_interrupt(int
>> irq, void *dev_id)
>> {
>> struct platform_device *pdev = dev_id;
>> struct pwrkey_drv_data *pdata = platform_get_drvdata(pdev);
>> + unsigned long expire = jiffies;
>> u32 lp_status;
>>
>> pm_wakeup_event(pdata->input->dev.parent, 0);
>>
>> regmap_read(pdata->snvs, SNVS_LPSR_REG, &lp_status);
>> - if (lp_status & SNVS_LPSR_SPO)
>> - mod_timer(&pdata->check_timer, jiffies +
>> msecs_to_jiffies(DEBOUNCE_TIME));
>> + if (lp_status & SNVS_LPSR_SPO) {
>> + if (pdata->hwtype == IMX6SX_SNVS)
>> + expire += msecs_to_jiffies(DEBOUNCE_TIME);
>> + mod_timer(&pdata->check_timer, expire);
>
> Is this desired because the timer gets triggered earlier.
Yes, since the first generation has debounce implemented in hardware,
we dont need to add another one.
Now looking at it, maybe I should change the conditional to:
if (pdata->hwtype != IMX6QDL_SNVS)
expire += msecs_to_jiffies(DEBOUNCE_TIME);
to make this more clear.
>
>> + }
>>
>> /* clear SPO status */
>> regmap_write(pdata->snvs, SNVS_LPSR_REG, SNVS_LPSR_SPO);
>> @@ -93,6 +129,7 @@ static int imx_snvs_pwrkey_probe(struct
>> platform_device *pdev)
>> struct pwrkey_drv_data *pdata = NULL;
>> struct input_dev *input = NULL;
>> struct device_node *np;
>> + const struct of_device_id *match;
>> int error;
>>
>> /* Get SNVS register Page */
>> @@ -100,6 +137,10 @@ static int imx_snvs_pwrkey_probe(struct
>> platform_device *pdev)
>> if (!np)
>> return -ENODEV;
>>
>> + match = of_match_node(imx_snvs_pwrkey_ids, np);
>> + if (!match)
>> + return -ENODEV;
>
> ... of_device_get_match_data() here.
of_device_get_match_data() returns NULL on error. In this case, because
I
assigned integer values to the .data pointers, casting NULL back to an
integer will result in a valid hwtype.
I could declare a special struct with a 'quirks' field like they did in
the
flexcan diver: 'drivers/net/can/flexcan.c'.
Use of_device_get_match_data() to get it, and define a quirk like:
SNVS_QUIRK_NO_BTN_PRESS_IRQ. This might also improve readability.
> While reading the rm it seems that
> the snvs block has a dedicated version register. IMHO this could be a
> better way to apply the change also to existing devices with old
> firmware.
I thought the same thing, and fully agree with you. However I do not
have
a way to determine which versions are out there. Since I couldn't find
any
documentation on this, and I only have i.MX6 S/DL, D/Q and UL laying
around.
Regards,
Robin van der Gracht
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/3] arm: Add support for function error injection
From: Leo Yan @ 2019-08-29 7:23 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Song Liu, Benjamin Herrenschmidt, Alexei Starovoitov,
Oleg Nesterov, Paul Mackerras, H. Peter Anvin, Will Deacon,
linux-arch, Daniel Borkmann, Michael Ellerman, x86,
clang-built-linux, Ingo Molnar, Catalin Marinas, Yonghong Song,
Naveen N. Rao, Arnd Bergmann, Borislav Petkov, Thomas Gleixner,
linux-arm-kernel, netdev, linux-kernel, Masami Hiramatsu, bpf,
linuxppc-dev, Martin KaFai Lau
In-Reply-To: <20190829065729.GU13294@shell.armlinux.org.uk>
Hi Russell,
On Thu, Aug 29, 2019 at 07:57:29AM +0100, Russell King - ARM Linux admin wrote:
> I'm sorry, I can't apply this, it produces loads of:
>
> include/linux/error-injection.h:7:10: fatal error: asm/error-injection.h: No such file or directory
>
> Since your patch 1 has been merged by the ARM64 people, I can't take
> it until next cycle.
For this case, do you want me to resend this patch in next merge
window? Or you have picked up this patch but will send PR in next
cycle?
Thanks,
Leo Yan
> On Mon, Aug 19, 2019 at 05:18:08PM +0800, Leo Yan wrote:
> > Hi Russell,
> >
> > On Tue, Aug 06, 2019 at 06:00:15PM +0800, Leo Yan wrote:
> > > This patch implements arm specific functions regs_set_return_value() and
> > > override_function_with_return() to support function error injection.
> > >
> > > In the exception flow, it updates pt_regs::ARM_pc with pt_regs::ARM_lr
> > > so can override the probed function return.
> >
> > Gentle ping ... Could you review this patch?
> >
> > Thanks,
> > Leo.
> >
> > > Signed-off-by: Leo Yan <leo.yan@linaro.org>
> > > ---
> > > arch/arm/Kconfig | 1 +
> > > arch/arm/include/asm/ptrace.h | 5 +++++
> > > arch/arm/lib/Makefile | 2 ++
> > > arch/arm/lib/error-inject.c | 19 +++++++++++++++++++
> > > 4 files changed, 27 insertions(+)
> > > create mode 100644 arch/arm/lib/error-inject.c
> > >
> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > index 33b00579beff..2d3d44a037f6 100644
> > > --- a/arch/arm/Kconfig
> > > +++ b/arch/arm/Kconfig
> > > @@ -77,6 +77,7 @@ config ARM
> > > select HAVE_EXIT_THREAD
> > > select HAVE_FAST_GUP if ARM_LPAE
> > > select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
> > > + select HAVE_FUNCTION_ERROR_INJECTION if !THUMB2_KERNEL
> > > select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG
> > > select HAVE_FUNCTION_TRACER if !XIP_KERNEL
> > > select HAVE_GCC_PLUGINS
> > > diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h
> > > index 91d6b7856be4..3b41f37b361a 100644
> > > --- a/arch/arm/include/asm/ptrace.h
> > > +++ b/arch/arm/include/asm/ptrace.h
> > > @@ -89,6 +89,11 @@ static inline long regs_return_value(struct pt_regs *regs)
> > > return regs->ARM_r0;
> > > }
> > >
> > > +static inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc)
> > > +{
> > > + regs->ARM_r0 = rc;
> > > +}
> > > +
> > > #define instruction_pointer(regs) (regs)->ARM_pc
> > >
> > > #ifdef CONFIG_THUMB2_KERNEL
> > > diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> > > index b25c54585048..8f56484a7156 100644
> > > --- a/arch/arm/lib/Makefile
> > > +++ b/arch/arm/lib/Makefile
> > > @@ -42,3 +42,5 @@ ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
> > > CFLAGS_xor-neon.o += $(NEON_FLAGS)
> > > obj-$(CONFIG_XOR_BLOCKS) += xor-neon.o
> > > endif
> > > +
> > > +obj-$(CONFIG_FUNCTION_ERROR_INJECTION) += error-inject.o
> > > diff --git a/arch/arm/lib/error-inject.c b/arch/arm/lib/error-inject.c
> > > new file mode 100644
> > > index 000000000000..2d696dc94893
> > > --- /dev/null
> > > +++ b/arch/arm/lib/error-inject.c
> > > @@ -0,0 +1,19 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +
> > > +#include <linux/error-injection.h>
> > > +#include <linux/kprobes.h>
> > > +
> > > +void override_function_with_return(struct pt_regs *regs)
> > > +{
> > > + /*
> > > + * 'regs' represents the state on entry of a predefined function in
> > > + * the kernel/module and which is captured on a kprobe.
> > > + *
> > > + * 'regs->ARM_lr' contains the the link register for the probed
> > > + * function, when kprobe returns back from exception it will override
> > > + * the end of probed function and directly return to the predefined
> > > + * function's caller.
> > > + */
> > > + instruction_pointer_set(regs, regs->ARM_lr);
> > > +}
> > > +NOKPROBE_SYMBOL(override_function_with_return);
> > > --
> > > 2.17.1
> > >
> >
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [EXT] [PATCH v3 0/2] drm: bridge: Add NWL MIPI DSI host controller support
From: Guido Günther @ 2019-08-29 7:22 UTC (permalink / raw)
To: Robert Chiras
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
jernej.skrabec@siol.net, kernel@pengutronix.de, sam@ravnborg.org,
narmstrong@baylibre.com, airlied@linux.ie, festevam@gmail.com,
s.hauer@pengutronix.de, jonas@kwiboo.se,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
a.hajda@samsung.com, robh+dt@kernel.org, arnd@arndb.de,
dl-linux-imx, daniel@ffwll.ch, shawnguo@kernel.org,
lee.jones@linaro.org, linux-arm-kernel@lists.infradead.org,
Laurent.pinchart@ideasonboard.com
In-Reply-To: <1567002587.3209.122.camel@nxp.com>
Hi,
On Wed, Aug 28, 2019 at 02:29:48PM +0000, Robert Chiras wrote:
> Hi Guido,
>
> I tested this on my setup and it works. My DSI panel is a little bit
> different and it doesn't work with this as-is, but I added some
> improvements on top of this, in order to be able to setup the clocks.
> The changes I made can arrive on top of this as improvements, of
> course, since it will allow this driver to dinamically set the
> video_pll clock for any kind of mode.
>
> So, for the whole patch-set, you can add:
> Tested-by: Robert Chiras <robert.chiras@nxp.com>
> Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
Added for v4, thanks!
-- Guido
>
> Best regards,
> Robert
>
> On Jo, 2019-08-22 at 12:44 +0200, Guido Günther wrote:
> > This adds initial support for the NWL MIPI DSI Host controller found
> > on i.MX8
> > SoCs.
> >
> > It adds support for the i.MX8MQ but the same IP core can also be
> > found on e.g.
> > i.MX8QXP. I added the necessary hooks to support other imx8 variants
> > but since
> > I only have imx8mq boards to test I omitted the platform data for
> > other SoCs.
> >
> > The code is based on NXPs BSP so I added Robert Chiras as
> > Co-authored-by. Robert, if this looks sane could you add your
> > Signed-off-by:?
> >
> > The most notable changes over the BSP driver are
> > - Calculate HS mode timing from phy_configure_opts_mipi_dphy
> > - Perform all clock setup via DT
> > - Merge nwl-imx and nwl drivers
> > - Add B0 silion revision quirk
> > - become a bridge driver to hook into mxsfb (from what I read[0]
> > DCSS, which
> > also can drive the nwl on the imx8mq will likely not become part
> > of
> > imx-display-subsystem so it makes sense to make it drive a bridge
> > for dsi as
> > well).
> > - Use panel_bridge to attach the panel
> > - Use multiplex framework instead of accessing syscon directly
> >
> > This has been tested on a Librem 5 devkit using mxsfb with Robert's
> > patches[1]
> > and the rocktech-jh057n00900 panel driver on next-20190821. The DCSS
> > can later
> > on also act as input source too.
> >
> > Changes from v2:
> > - Per review comments by Rob Herring
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> > ists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> > August%2F230448.html&data=02%7C01%7Crobert.chiras%40nxp.com%7C757
> > 201f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> > 7C0%7C637020674654566414&sdata=JdvAdCPGq2CTsW%2BgXgnAVltWMIfdCDQn
> > dXSLYpnjEH8%3D&reserved=0
> > - bindings:
> > - Simplify by restricting to fsl,imx8mq-nwl-dsi
> > - document reset lines
> > - add port@{0,1}
> > - use a real compatible string for the panel
> > - resets are required
> > - Per review comments by Arnd Bergmann
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> > ists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> > August%2F230868.html&data=02%7C01%7Crobert.chiras%40nxp.com%7C757
> > 201f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> > 7C0%7C637020674654566414&sdata=LyJpZjQjMCe5zUdvK8CD8ETucLPxx621gW
> > xtpAr8DM4%3D&reserved=0
> > - Don't access iomuxc_gpr regs directly. This allows us to drop the
> > first patch in the series with the iomuxc_gpr field defines.
> > - Per review comments by Laurent Pinchart
> > - Fix wording in bindings
> > - Add mux-controls to bindings
> > - Don't print error message on dphy probe deferal
> >
> > Changes from v1:
> > - Per review comments by Sam Ravnborg
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> > ists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> > July%2F228130.html&data=02%7C01%7Crobert.chiras%40nxp.com%7C75720
> > 1f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> > 0%7C637020674654566414&sdata=AU2gzIwrbCdIBZenPWWYYX%2BgdX53zc2%2B
> > SQhZbuN%2FWpU%3D&reserved=0
> > - Change binding docs to YAML
> > - build: Don't always visit imx-nwl/
> > - build: Add header-test-y
> > - Sort headers according to DRM convention
> > - Use drm_display_mode instead of videmode
> > - Per review comments by Fabio Estevam
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> > ists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> > July%2F228299.html&data=02%7C01%7Crobert.chiras%40nxp.com%7C75720
> > 1f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> > 0%7C637020674654566414&sdata=6kpIZ6iNAQ13fMXU6sqENLwy%2FdIWL6ef8j
> > gyas7I0CQ%3D&reserved=0
> > - Don't restrict build to ARCH_MXC
> > - Drop unused includes
> > - Drop unreachable code in imx_nwl_dsi_bridge_mode_fixup()
> > - Drop remaining calls of dev_err() and use DRM_DEV_ERR()
> > consistently.
> > - Use devm_platform_ioremap_resource()
> > - Drop devm_free_irq() in probe() error path
> > - Use single line comments where sufficient
> > - Use <linux/time64.h> instead of defining USEC_PER_SEC
> > - Make input source select imx8 specific
> > - Drop <asm/unaligned.h> inclusion (after removal of
> > get_unaligned_le32)
> > - Drop all EXPORT_SYMBOL_GPL() for functions used in the same
> > module
> > but different source files.
> > - Drop nwl_dsi_enable_{rx,tx}_clock() by invoking
> > clk_prepare_enable()
> > directly
> > - Remove pointless comment
> > - Laurent Pinchart
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> > ists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> > July%2F228313.html&data=02%7C01%7Crobert.chiras%40nxp.com%7C75720
> > 1f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> > 0%7C637020674654566414&sdata=tDlVGeET1CPMH9W%2FqmnePNR51vNaTKD%2F
> > iFOoR9%2FmESc%3D&reserved=0
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> > ists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> > July%2F228308.html&data=02%7C01%7Crobert.chiras%40nxp.com%7C75720
> > 1f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> > 0%7C637020674654566414&sdata=NsLGAL8%2BcOC0ZZxxeoGe7VxQCgqSBEN4G3
> > WVGOeZpCo%3D&reserved=0
> > - Drop (on iMX8MQ) unused csr regmap
> > - Use NWL_MAX_PLATFORM_CLOCKS everywhere
> > - Drop get_unaligned_le32() usage
> > - remove duplicate 'for the' in binding docs
> > - Don't include unused <linux/clk-provider.h>
> > - Don't include unused <linux/component.h>
> > - Drop dpms_mode for tracking state, trust the drm layer on that
> > - Use pm_runtime_put() instead of pm_runtime_put_sync()
> > - Don't overwrite encoder type
> > - Make imx_nwl_platform_data const
> > - Use the reset controller API instead of open coding that platform
> > specific
> > part
> > - Use <linux/bitfield.h> intead of making up our own defines
> > - name mipi_dsi_transfer less generic: nwl_dsi_transfer
> > - ensure clean in .remove by calling mipi_dsi_host_unregister.
> > - prefix constants by NWL_DSI_
> > - properly format transfer_direction enum
> > - simplify platform clock handling
> > - Don't modify state in mode_fixup() and use mode_set() instead
> > - Drop bridge detach(), already handle by nwl_dsi_host_detach()
> > - Drop USE_*_QUIRK() macros
> > - Drop (for now) unused clock defnitions. 'pixel' and 'bypass' clock
> > will be
> > used for i.MX8 SoCs but since they're unused atm drop the
> > definitions - but
> > keep the logic to enable/disable several clocks in place since we
> > know we'll
> > need it in the future.
> >
> > Changes from v0:
> > - Add quirk for IMQ8MQ silicon B0 revision to not mess with the
> > system reset controller on power down since enable() won't work
> > otherwise.
> > - Drop devm_free_irq() handled by the device driver core
> > - Disable tx esc clock after the phy power down to unbreak
> > disable/enable (unblank/blank)
> > - Add ports to dt binding docs
> > - Select GENERIC_PHY_MIPI_DPHY instead of GENERIC_PHY for
> > phy_mipi_dphy_get_default_config
> > - Select DRM_MIPI_DSI
> > - Include drm_print.h to fix build on next-20190408
> > - Drop some debugging messages
> > - Newline terminate all DRM_ printouts
> > - Turn component driver into a drm bridge
> >
> > [0]: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
> > 2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2019-
> > May%2F219484.html&data=02%7C01%7Crobert.chiras%40nxp.com%7C757201
> > f9aaa54653580e08d726edb290%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> > %7C637020674654566414&sdata=4IVjhLy3a2XxZ4jYwDFD23D%2BvwAVAEj44hY
> > fvvp8OpQ%3D&reserved=0
> > [1]: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
> > 2Fpatchwork.freedesktop.org%2Fseries%2F62822%2F&data=02%7C01%7Cro
> > bert.chiras%40nxp.com%7C757201f9aaa54653580e08d726edb290%7C686ea1d3bc
> > 2b4c6fa92cd99c5c301635%7C0%7C0%7C637020674654566414&sdata=GueUBOc
> > baGjWtWcMYBplL6ki2UbgaFPkQHg%2F6eReiYg%3D&reserved=0
> >
> > To: David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
> > Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>
> > , Shawn Guo <shawnguo@kernel.org>, Sascha Hauer <s.hauer@pengutronix.
> > de>, Pengutronix Kernel Team <kernel@pengutronix.de>, Fabio Estevam <
> > festevam@gmail.com>, NXP Linux Team <linux-imx@nxp.com>, Andrzej
> > Hajda <a.hajda@samsung.com>, Neil Armstrong <narmstrong@baylibre.com>
> > , Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, Jonas Karlman
> > <jonas@kwiboo.se>, Jernej Skrabec <jernej.skrabec@siol.net>, Lee
> > Jones <lee.jones@linaro.org>, Guido Günther <agx@sigxcpu.org>, dri-de
> > vel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-arm-kern
> > el@lists.infradead.org, linux-kernel@vger.kernel.org, Robert Chiras <
> > robert.chiras@nxp.com>, Sam Ravnborg <sam@ravnborg.org>, Fabio
> > Estevam <festevam@gmail.com>, Arnd Bergmann <arnd@arndb.de>
> >
> >
> > Guido Günther (2):
> > dt-bindings: display/bridge: Add binding for NWL mipi dsi host
> > controller
> > drm/bridge: Add NWL MIPI DSI host controller support
> >
> > .../bindings/display/bridge/nwl-dsi.yaml | 155 ++++
> > drivers/gpu/drm/bridge/Kconfig | 2 +
> > drivers/gpu/drm/bridge/Makefile | 1 +
> > drivers/gpu/drm/bridge/nwl-dsi/Kconfig | 16 +
> > drivers/gpu/drm/bridge/nwl-dsi/Makefile | 4 +
> > drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c | 501 +++++++++++++
> > drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h | 65 ++
> > drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c | 700
> > ++++++++++++++++++
> > drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h | 112 +++
> > 9 files changed, 1556 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Kconfig
> > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Makefile
> > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
> > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h
> > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c
> > create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h
> >
> > --
> > 2.20.1
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 14/14] arm64: dts: Add power controller device node of MT8183
From: Matthias Brugger @ 2019-08-29 7:19 UTC (permalink / raw)
To: CK Hu, Weiyi Lu
Cc: Rob Herring, Nicolas Boichat, srv_heupstream, James Liao,
linux-kernel, Fan Chen, linux-mediatek, linux-arm-kernel, Yong Wu
In-Reply-To: <1561971461.12937.8.camel@mtksdaap41>
On 01/07/2019 10:57, CK Hu wrote:
> Hi, Weiyi:
>
> On Thu, 2019-06-20 at 10:38 +0800, Weiyi Lu wrote:
>> Add power controller node and smi-common node for MT8183
>> In scpsys node, it contains clocks and regmapping of
>> infracfg and smi-common for bus protection.
>>
>> Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
>> ---
>> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 62 ++++++++++++++++++++++++++++++++
>> 1 file changed, 62 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>> index 08274bf..75c4881 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>> @@ -8,6 +8,7 @@
>> #include <dt-bindings/clock/mt8183-clk.h>
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> #include <dt-bindings/interrupt-controller/irq.h>
>> +#include <dt-bindings/power/mt8183-power.h>
>>
>> / {
>> compatible = "mediatek,mt8183";
>> @@ -196,6 +197,62 @@
>> #clock-cells = <1>;
>> };
>>
>> + scpsys: syscon@10006000 {
>> + compatible = "mediatek,mt8183-scpsys", "syscon";
>> + #power-domain-cells = <1>;
>> + reg = <0 0x10006000 0 0x1000>;
>> + clocks = <&topckgen CLK_TOP_MUX_AUD_INTBUS>,
>> + <&infracfg CLK_INFRA_AUDIO>,
>> + <&infracfg CLK_INFRA_AUDIO_26M_BCLK>,
>> + <&topckgen CLK_TOP_MUX_MFG>,
>> + <&topckgen CLK_TOP_MUX_MM>,
>> + <&topckgen CLK_TOP_MUX_CAM>,
>> + <&topckgen CLK_TOP_MUX_IMG>,
>> + <&topckgen CLK_TOP_MUX_IPU_IF>,
>> + <&topckgen CLK_TOP_MUX_DSP>,
>> + <&topckgen CLK_TOP_MUX_DSP1>,
>> + <&topckgen CLK_TOP_MUX_DSP2>,
>> + <&mmsys CLK_MM_SMI_COMMON>,
>> + <&mmsys CLK_MM_SMI_LARB0>,
>> + <&mmsys CLK_MM_SMI_LARB1>,
>> + <&mmsys CLK_MM_GALS_COMM0>,
>> + <&mmsys CLK_MM_GALS_COMM1>,
>> + <&mmsys CLK_MM_GALS_CCU2MM>,
>> + <&mmsys CLK_MM_GALS_IPU12MM>,
>> + <&mmsys CLK_MM_GALS_IMG2MM>,
>> + <&mmsys CLK_MM_GALS_CAM2MM>,
>> + <&mmsys CLK_MM_GALS_IPU2MM>,
>
> Up to now, MT8183 mmsys has the same resource with another device node:
>
> mmsys: syscon@14000000 {
> compatible = "mediatek,mt8183-mmsys", "syscon";
> reg = <0 0x14000000 0 0x1000>;
> #clock-cells = <1>;
> };
>
> display_components: dispsys@14000000 {
> compatible = "mediatek,mt8183-display";
> reg = <0 0x14000000 0 0x1000>;
> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
> };
>
> I think this two node should be merge into one node, so I've try to
> merge them:
>
> mmsys: syscon@14000000 {
> compatible = "mediatek,mt8183-mmsys", "syscon";
> reg = <0 0x14000000 0 0x1000>;
> power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
> #clock-cells = <1>;
> };
>
> But I got a kernel panic when boot,
>
> [ 3.458523] Unable to handle kernel paging request at virtual address
> fffffffffffffdfb
> [ 3.466999] Mem abort info:
> [ 3.470116] ESR = 0x96000005
> [ 3.473268] Exception class = DABT (current EL), IL = 32 bits
> [ 3.479375] SET = 0, FnV = 0
> [ 3.482530] EA = 0, S1PTW = 0
> [ 3.485785] Data abort info:
> [ 3.488831] ISV = 0, ISS = 0x00000005
> [ 3.493067] CM = 0, WnR = 0
> [ 3.496229] swapper pgtable: 4k pages, 39-bit VAs, pgdp =
> 000000004f8fa26d
> [ 3.503214] [fffffffffffffdfb] pgd=0000000000000000,
> pud=0000000000000000
> [ 3.510408] Internal error: Oops: 96000005 [#1] PREEMPT SMP
> [ 3.515974] Modules linked in:
> [ 3.519023] Process kworker/0:3 (pid: 106, stack limit =
> 0x00000000281d0651)
> [ 3.526066] CPU: 0 PID: 106 Comm: kworker/0:3 Tainted: G W
> 4.19.43 #208
> [ 3.533974] Hardware name: MediaTek kukui rev1 board (DT)
> [ 3.539374] Workqueue: events deferred_probe_work_func
> [ 3.544507] pstate: 20000005 (nzCv daif -PAN -UAO)
> [ 3.549294] pc : clk_prepare+0x18/0x40
> [ 3.553038] lr : scpsys_clk_enable+0x40/0xb4
> [ 3.557299] sp : ffffff800855b9e0
> [ 3.560606] x29: ffffff800855b9f0 x28: ffffff93e1e5f594
> [ 3.565911] x27: 000000000000000f x26: ffffff93e1e5e9b8
> [ 3.571217] x25: 000000003b9aca00 x24: ffffff800858530c
> [ 3.576522] x23: ffffffffffffffff x22: fffffffffffffdfb
> [ 3.581827] x21: 000000000000000a x20: ffffffccb89aafc8
> [ 3.587132] x19: fffffffffffffdfb x18: 00005a5c77082016
> [ 3.592438] x17: 0000000000000400 x16: 0000000000000001
> [ 3.597743] x15: 0000000000000009 x14: ffffff93e271c908
> [ 3.603048] x13: 0000000000000b22 x12: 0000000000000008
> [ 3.608353] x11: 0000000001d063de x10: 0000000000000008
> [ 3.613659] x9 : 00000000ffffffed x8 : 0000000000000000
> [ 3.618964] x7 : 736d6c2dff7224fe x6 : 0000008000000000
> [ 3.624269] x5 : 0000000000000000 x4 : 0000000080000000
> [ 3.629575] x3 : 002f6d6e74000000 x2 : 0000000000000000
> [ 3.634880] x1 : 000000000000000a x0 : fffffffffffffdfb
> [ 3.640185] Call trace:
> [ 3.642625] clk_prepare+0x18/0x40
> [ 3.646019] scpsys_clk_enable+0x40/0xb4
> [ 3.649935] scpsys_power_on+0x13c/0x304
> [ 3.653850] scpsys_probe+0xe0/0x5fc
> [ 3.657419] platform_drv_probe+0x80/0xb0
> [ 3.661420] really_probe+0x114/0x28c
> [ 3.665075] driver_probe_device+0x64/0xfc
> [ 3.669164] __device_attach_driver+0xb8/0xd0
> [ 3.673513] bus_for_each_drv+0x88/0xd0
> [ 3.677341] __device_attach+0xac/0x130
> [ 3.681169] device_initial_probe+0x20/0x2c
> [ 3.685344] bus_probe_device+0x34/0x90
> [ 3.689172] deferred_probe_work_func+0x74/0xac
> [ 3.693698] process_one_work+0x210/0x420
> [ 3.697700] worker_thread+0x278/0x3e4
> [ 3.701443] kthread+0x11c/0x12c
> [ 3.704665] ret_from_fork+0x10/0x18
>
> I'm not really understand what happen, but scpsys and mmsys point to
> each other in MT8183. Why these two node point to each other in MT8183?
> If this is really hardware limitation, we need to solve this in driver.
> If this is not a hardware limitation, I would like to re-organize device
> tree to prevent this problem.
>
How do you register the clocks?
We would need to have a solution as proposed in:
https://patchwork.kernel.org/cover/10686345/
CK Hu, as far as I remember you wanted to look into it. If you don't have time,
I can give it a try next week. Right now I have a bit of free time to work on that.
Regards,
Matthias
> Regards,
> CK
>
>
>> + <&imgsys CLK_IMG_LARB5>,
>> + <&imgsys CLK_IMG_LARB2>,
>> + <&camsys CLK_CAM_LARB6>,
>> + <&camsys CLK_CAM_LARB3>,
>> + <&camsys CLK_CAM_SENINF>,
>> + <&camsys CLK_CAM_CAMSV0>,
>> + <&camsys CLK_CAM_CAMSV1>,
>> + <&camsys CLK_CAM_CAMSV2>,
>> + <&camsys CLK_CAM_CCU>,
>> + <&ipu_conn CLK_IPU_CONN_IPU>,
>> + <&ipu_conn CLK_IPU_CONN_AHB>,
>> + <&ipu_conn CLK_IPU_CONN_AXI>,
>> + <&ipu_conn CLK_IPU_CONN_ISP>,
>> + <&ipu_conn CLK_IPU_CONN_CAM_ADL>,
>> + <&ipu_conn CLK_IPU_CONN_IMG_ADL>;
>> + clock-names = "audio", "audio1", "audio2",
>> + "mfg", "mm", "cam",
>> + "isp", "vpu", "vpu1",
>> + "vpu2", "vpu3", "mm-0",
>> + "mm-1", "mm-2", "mm-3",
>> + "mm-4", "mm-5", "mm-6",
>> + "mm-7", "mm-8", "mm-9",
>> + "isp-0", "isp-1", "cam-0",
>> + "cam-1", "cam-2", "cam-3",
>> + "cam-4", "cam-5", "cam-6",
>> + "vpu-0", "vpu-1", "vpu-2",
>> + "vpu-3", "vpu-4", "vpu-5";
>> + infracfg = <&infracfg>;
>> + smi_comm = <&smi_common>;
>> + };
>> +
>> apmixedsys: syscon@1000c000 {
>> compatible = "mediatek,mt8183-apmixedsys", "syscon";
>> reg = <0 0x1000c000 0 0x1000>;
>> @@ -260,6 +317,11 @@
>> #clock-cells = <1>;
>> };
>>
>> + smi_common: smi@14019000 {
>> + compatible = "mediatek,mt8183-smi-common", "syscon";
>> + reg = <0 0x14019000 0 0x1000>;
>> + };
>> +
>> imgsys: syscon@15020000 {
>> compatible = "mediatek,mt8183-imgsys", "syscon";
>> reg = <0 0x15020000 0 0x1000>;
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH pinctrl/fixes] pinctrl: aspeed: Fix spurious mux failures on the AST2500
From: Andrew Jeffery @ 2019-08-29 7:17 UTC (permalink / raw)
To: linux-gpio
Cc: linux-aspeed, Andrew Jeffery, linus.walleij, linux-kernel, joel,
openbmc, linux-arm-kernel, John Wang
Commit 674fa8daa8c9 ("pinctrl: aspeed-g5: Delay acquisition of regmaps")
was determined to be a partial fix to the problem of acquiring the LPC
Host Controller and GFX regmaps: The AST2500 pin controller may need to
fetch syscon regmaps during expression evaluation as well as when
setting mux state. For example, this case is hit by attempting to export
pins exposing the LPC Host Controller as GPIOs.
An optional eval() hook is added to the Aspeed pinmux operation struct
and called from aspeed_sig_expr_eval() if the pointer is set by the
SoC-specific driver. This enables the AST2500 to perform the custom
action of acquiring its regmap dependencies as required.
John Wang tested the fix on an Inspur FP5280G2 machine (AST2500-based)
where the issue was found, and I've booted the fix on Witherspoon
(AST2500) and Palmetto (AST2400) machines, and poked at relevant pins
under QEMU by forcing mux configurations via devmem before exporting
GPIOs to exercise the driver.
Fixes: 7d29ed88acbb ("pinctrl: aspeed: Read and write bits in LPC and GFX controllers")
Fixes: 674fa8daa8c9 ("pinctrl: aspeed-g5: Delay acquisition of regmaps")
Reported-by: John Wang <wangzqbj@inspur.com>
Tested-by: John Wang <wangzqbj@inspur.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
Hi Linus,
The timing of merging the AST2600 (g6) driver and 674fa8daa8c9 ("pinctrl:
aspeed-g5: Delay acquisition of regmaps") caused a bit of a rough spot a
few weeks back. This fix doesn't cause any such disruption - I've
developed it on top of pinctrl/fixes and back-merged the result into
pinctrl/devel to test for build breakage (via CONFIG_COMPILE_TEST to
enable all of the g4, g5 and g6 drivers). All three ASPEED pinctrl
drivers built successfully, so it should be enough to simply take this
patch through pinctrl/fixes and leave pinctrl/devel as is for the 5.4
merge window.
---
drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 30 +++++++++++++++++++++-
drivers/pinctrl/aspeed/pinmux-aspeed.c | 7 +++--
drivers/pinctrl/aspeed/pinmux-aspeed.h | 7 ++---
3 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
index ba6438ac4d72..ff84d1afd229 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
@@ -2552,7 +2552,7 @@ static struct regmap *aspeed_g5_acquire_regmap(struct aspeed_pinmux_data *ctx,
if (IS_ERR(map))
return map;
} else
- map = ERR_PTR(-ENODEV);
+ return ERR_PTR(-ENODEV);
ctx->maps[ASPEED_IP_LPC] = map;
dev_dbg(ctx->dev, "Acquired LPC regmap");
@@ -2562,6 +2562,33 @@ static struct regmap *aspeed_g5_acquire_regmap(struct aspeed_pinmux_data *ctx,
return ERR_PTR(-EINVAL);
}
+static int aspeed_g5_sig_expr_eval(struct aspeed_pinmux_data *ctx,
+ const struct aspeed_sig_expr *expr,
+ bool enabled)
+{
+ int ret;
+ int i;
+
+ for (i = 0; i < expr->ndescs; i++) {
+ const struct aspeed_sig_desc *desc = &expr->descs[i];
+ struct regmap *map;
+
+ map = aspeed_g5_acquire_regmap(ctx, desc->ip);
+ if (IS_ERR(map)) {
+ dev_err(ctx->dev,
+ "Failed to acquire regmap for IP block %d\n",
+ desc->ip);
+ return PTR_ERR(map);
+ }
+
+ ret = aspeed_sig_desc_eval(desc, enabled, ctx->maps[desc->ip]);
+ if (ret <= 0)
+ return ret;
+ }
+
+ return 1;
+}
+
/**
* Configure a pin's signal by applying an expression's descriptor state for
* all descriptors in the expression.
@@ -2647,6 +2674,7 @@ static int aspeed_g5_sig_expr_set(struct aspeed_pinmux_data *ctx,
}
static const struct aspeed_pinmux_ops aspeed_g5_ops = {
+ .eval = aspeed_g5_sig_expr_eval,
.set = aspeed_g5_sig_expr_set,
};
diff --git a/drivers/pinctrl/aspeed/pinmux-aspeed.c b/drivers/pinctrl/aspeed/pinmux-aspeed.c
index 839c01b7953f..57305ca838a7 100644
--- a/drivers/pinctrl/aspeed/pinmux-aspeed.c
+++ b/drivers/pinctrl/aspeed/pinmux-aspeed.c
@@ -78,11 +78,14 @@ int aspeed_sig_desc_eval(const struct aspeed_sig_desc *desc,
* neither the enabled nor disabled state. Thus we must explicitly test for
* either condition as required.
*/
-int aspeed_sig_expr_eval(const struct aspeed_pinmux_data *ctx,
+int aspeed_sig_expr_eval(struct aspeed_pinmux_data *ctx,
const struct aspeed_sig_expr *expr, bool enabled)
{
+ int ret;
int i;
- int ret;
+
+ if (ctx->ops->eval)
+ return ctx->ops->eval(ctx, expr, enabled);
for (i = 0; i < expr->ndescs; i++) {
const struct aspeed_sig_desc *desc = &expr->descs[i];
diff --git a/drivers/pinctrl/aspeed/pinmux-aspeed.h b/drivers/pinctrl/aspeed/pinmux-aspeed.h
index 52d299b59ce2..db3457c86f48 100644
--- a/drivers/pinctrl/aspeed/pinmux-aspeed.h
+++ b/drivers/pinctrl/aspeed/pinmux-aspeed.h
@@ -702,6 +702,8 @@ struct aspeed_pin_function {
struct aspeed_pinmux_data;
struct aspeed_pinmux_ops {
+ int (*eval)(struct aspeed_pinmux_data *ctx,
+ const struct aspeed_sig_expr *expr, bool enabled);
int (*set)(struct aspeed_pinmux_data *ctx,
const struct aspeed_sig_expr *expr, bool enabled);
};
@@ -722,9 +724,8 @@ struct aspeed_pinmux_data {
int aspeed_sig_desc_eval(const struct aspeed_sig_desc *desc, bool enabled,
struct regmap *map);
-int aspeed_sig_expr_eval(const struct aspeed_pinmux_data *ctx,
- const struct aspeed_sig_expr *expr,
- bool enabled);
+int aspeed_sig_expr_eval(struct aspeed_pinmux_data *ctx,
+ const struct aspeed_sig_expr *expr, bool enabled);
static inline int aspeed_sig_expr_set(struct aspeed_pinmux_data *ctx,
const struct aspeed_sig_expr *expr,
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3] ARM: ftrace: remove mcount(),ftrace_caller_old() and ftrace_call_old()
From: Jisheng Zhang @ 2019-08-29 7:06 UTC (permalink / raw)
To: Steven Rostedt, Ingo Molnar, Russell King
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190823182239.20f9a656@xhacker.debian>
Hi Russell,
On Fri, 23 Aug 2019 18:22:39 +0800 Jisheng Zhang wrote:
> Commit d3c61619568c ("ARM: 8788/1: ftrace: remove old mcount support")
> removed the old mcount support, but forget to remove these three
> declarations. This patch removes them.
May I put this patch into your patch system?
thanks
>
> Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> ---
>
> Changes since v2:
> - really remove mcount() declaration too. I made a mistake when sending out v2
>
> Changes since v1:
> - remove mcount() declaration too
>
> arch/arm/include/asm/ftrace.h | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
> index 18b0197f2384..48ec1d0337da 100644
> --- a/arch/arm/include/asm/ftrace.h
> +++ b/arch/arm/include/asm/ftrace.h
> @@ -11,7 +11,6 @@
> #define MCOUNT_INSN_SIZE 4 /* sizeof mcount call */
>
> #ifndef __ASSEMBLY__
> -extern void mcount(void);
> extern void __gnu_mcount_nc(void);
>
> #ifdef CONFIG_DYNAMIC_FTRACE
> @@ -23,9 +22,6 @@ static inline unsigned long ftrace_call_adjust(unsigned long addr)
> /* With Thumb-2, the recorded addresses have the lsb set */
> return addr & ~1;
> }
> -
> -extern void ftrace_caller_old(void);
> -extern void ftrace_call_old(void);
> #endif
>
> #endif
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 3/4] dt-bindings: Add Qualcomm USB SuperSpeed PHY bindings
From: Jorge Ramirez @ 2019-08-29 7:03 UTC (permalink / raw)
To: Bjorn Andersson
Cc: mark.rutland, robh, jackp, kishon, gregkh, linux-usb,
khasim.mohammed, linux-kernel, swboyd, devicetree, linux-arm-msm,
andy.gross, shawn.guo, linux-arm-kernel
In-Reply-To: <20190223165218.GB572@tuxbook-pro>
On 2/23/19 17:52, Bjorn Andersson wrote:
> On Thu 07 Feb 03:17 PST 2019, Jorge Ramirez-Ortiz wrote:
>
>> Binding description for Qualcomm's Synopsys 1.0.0 SuperSpeed phy
>> controller embedded in QCS404.
>>
>> Based on Sriharsha Allenki's <sallenki@codeaurora.org> original
>> definitions.
>>
>> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
>> ---
>> .../bindings/phy/qcom,snps-usb-ssphy.txt | 79 +++++++++++++++++++
>> 1 file changed, 79 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/phy/qcom,snps-usb-ssphy.txt
>>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom,snps-usb-ssphy.txt b/Documentation/devicetree/bindings/phy/qcom,snps-usb-ssphy.txt
>> new file mode 100644
>> index 000000000000..354e6f9cef62
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,snps-usb-ssphy.txt
>> @@ -0,0 +1,79 @@
>> +Qualcomm Synopsys 1.0.0 SS phy controller
>> +===========================================
>> +
>> +Qualcomm 1.0.0 SS phy controller supports SuperSpeed USB connectivity on
>> +some Qualcomm platforms.
>> +
>> +Required properties:
>> +
>> +- compatible:
>> + Value type: <string>
>> + Definition: Should contain "qcom,snps-usb-ssphy".
>
> Per Rob's request make this:
>
> Should contain "qcom,qcs404-snps-usb-ssphy" and "qcom,snps-usb-ssphy"
ok
>
> You can then leave the driver matching on qcom,snps-usb-ssphy for now
> and if we ever find this to be incompatible with other platforms we can
> make the driver match on the platform-specific compatible.
ok
>
>> +
>> +- reg:
>> + Value type: <prop-encoded-array>
>> + Definition: USB PHY base address and length of the register map.
>> +
>> +- #phy-cells:
>> + Value type: <u32>
>> + Definition: Should be 0. See phy/phy-bindings.txt for details.
>> +
>> +- clocks:
>> + Value type: <prop-encoded-array>
>> + Definition: See clock-bindings.txt section "consumers". List of
>> + three clock specifiers for reference, phy core and
>> + pipe clocks.
>> +
>> +- clock-names:
>> + Value type: <string>
>> + Definition: Names of the clocks in 1-1 correspondence with the "clocks"
>> + property. Must contain "ref", "phy" and "pipe".
>> +
>> +- vdd-supply:
>> + Value type: <phandle>
>> + Definition: phandle to the regulator VDD supply node.
>> +
>> +- vdda1p8-supply:
>> + Value type: <phandle>
>> + Definition: phandle to the regulator 1.8V supply node.
>> +
>> +Optional properties:
>> +
>> +- resets:
>> + Value type: <prop-encoded-array>
>> + Definition: See reset.txt section "consumers". Specifiers for COM and
>> + PHY resets.
>> +
>> +- reset-names:
>> + Value type: <string>
>> + Definition: Names of the resets in 1-1 correspondence with the "resets"
>> + property. Must contain "com" and "phy" if the property is
>> + specified.
>> +
>> +Required child nodes:
>> +
>> +- usb connector node as defined in bindings/connector/usb-connector.txt
>> + containing the property vbus-supply.
>> +
>> +Example:
>> +
>> +usb3_phy: usb3-phy@78000 {
>> + compatible = "qcom,snps-usb-ssphy";
>> + reg = <0x78000 0x400>;
>> + #phy-cells = <0>;
>> + clocks = <&rpmcc RPM_SMD_LN_BB_CLK>,
>> + <&gcc GCC_USB_HS_PHY_CFG_AHB_CLK>,
>> + <&gcc GCC_USB3_PHY_PIPE_CLK>;
>> + clock-names = "ref", "phy", "pipe";
>> + resets = <&gcc GCC_USB3_PHY_BCR>,
>> + <&gcc GCC_USB3PHY_PHY_BCR>;
>> + reset-names = "com", "phy";
>> + vdd-supply = <&vreg_l3_1p05>;
>> + vdda1p8-supply = <&vreg_l5_1p8>;
>> + usb3_c_connector: usb3-c-connector {
>
> The USB-C connector is attached both to the HS and SS PHYs, so I think
> you should represent this external to this node and use of_graph to
> query it.
but AFAICS we wont be able to retrieve the vbux-supply from an external
node (that interface does not exist).
rob, do you have a suggestion?
>
> So the connector should look similar to example 2 in
> connector/usb-connector.txt.
>
> Regards,
> Bjorn
>
>> + compatible = "usb-c-connector";
>> + label = "USB-C";
>> + type = "micro";
>> + vbus-supply = <&usb3_vbus_reg>;
>> + };
>> +};
>> --
>> 2.20.1
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next v4 3/3] dt-bindings: net: ethernet: Update mt7622 docs and dts to reflect the new phylink API
From: Matthias Brugger @ 2019-08-29 7:03 UTC (permalink / raw)
To: David Miller
Cc: nelson.chang, frank-w, netdev, sean.wang, linux-mips, linux,
opensource, linux-mediatek, john, sr, linux-arm-kernel
In-Reply-To: <20190828.125658.1743313522645522716.davem@davemloft.net>
On 28/08/2019 21:56, David Miller wrote:
> From: Matthias Brugger <matthias.bgg@gmail.com>
> Date: Wed, 28 Aug 2019 11:29:45 +0200
>
>> Thanks for taking this patch. For the next time, please make sure that dts[i]
>> patches are independent from the binding description, as dts[i] should go
>> through my tree. No problem for this round, just saying for the future.
>
> That's not always possible nor reasonable, to be quite honest.
>
Right now no case comes to my mind. What would be a case where this is not
reasonable or possible?
Regards,
Matthias
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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