* [PATCH 0/2] crypto: implement SM4 for arm64 using special instructions
From: Herbert Xu @ 2018-05-05 7:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180425122046.12695-1-ard.biesheuvel@linaro.org>
On Wed, Apr 25, 2018 at 02:20:44PM +0200, Ard Biesheuvel wrote:
> Patch #1 makes some preparatory changes so the C routines can be used as
> a fallback by other drivers.
>
> Patch #2 implements the SM4 core cipher using the special instructions
> introduced as an optional extension by revision 8.2 of the ARM architecture.
>
> Note that this does not implement cipher+chaining mode combinations as we
> do for AES. This can be added later if desiresd.
>
> Ard Biesheuvel (2):
> crypto: sm4 - export encrypt/decrypt routines to other drivers
> crypto: arm64 - add support for SM4 encryption using special
> instructions
>
> arch/arm64/crypto/Kconfig | 6 ++
> arch/arm64/crypto/Makefile | 3 +
> arch/arm64/crypto/sm4-ce-core.S | 36 ++++++++++
> arch/arm64/crypto/sm4-ce-glue.c | 73 ++++++++++++++++++++
> crypto/sm4_generic.c | 10 +--
> include/crypto/sm4.h | 3 +
> 6 files changed, 127 insertions(+), 4 deletions(-)
> create mode 100644 arch/arm64/crypto/sm4-ce-core.S
> create mode 100644 arch/arm64/crypto/sm4-ce-glue.c
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 0/2] Fix stm32-rng for default state and suspend
From: Herbert Xu @ 2018-05-05 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180423150426.22198-1-lionel.debieve@st.com>
On Mon, Apr 23, 2018 at 05:04:24PM +0200, Lionel Debieve wrote:
> This series are fixing the default build state for stm32-rng that
> activate the driver with arm multi_v7_defconfig.
> Second patch is fixing the power suspend/resume behavior which was
> not working.
>
> Lionel Debieve (2):
> hwrng: stm32 - define default state for rng driver
> hwrng: stm32-rng: Fix pm_suspend issue
>
> drivers/char/hw_random/Kconfig | 1 +
> drivers/char/hw_random/stm32-rng.c | 9 +++++++--
> 2 files changed, 8 insertions(+), 2 deletions(-)
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v14 2/8] ASoC: sun4i-codec: Add Mic1 Boost Volume, Mic2 Boost Volume
From: Danny Milosavljevic @ 2018-05-05 7:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503143319.4vyh2y5sluatssnv@flea>
Hi Maxime,
On Thu, 3 May 2018 16:33:19 +0200
Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > +struct sun4i_codec_quirks {
> > + const struct regmap_config *regmap_config;
> > + const struct snd_soc_component_driver *codec;
> > + struct snd_soc_card * (*create_card)(struct device *dev);
> > + struct reg_field reg_adc_fifoc; /* used for regmap_field */
> > + unsigned int reg_dac_txdata; /* TX FIFO offset for DMA config */
> > + unsigned int reg_adc_rxdata; /* RX FIFO offset for DMA config */
> > + bool has_reset;
> > + const struct snd_kcontrol_new *controls;
> > + unsigned int num_controls;
> > +};
> > +
> > +static int sun4i_codec_component_driver_probe(struct snd_soc_component *codec)
> > +{
> > + const struct sun4i_codec_quirks *quirks;
> > +
> > + quirks = of_device_get_match_data(codec->dev);
> > + return snd_soc_add_component_controls(codec,
> > + quirks->controls,
> > + quirks->num_controls);
>
> Why not just extending the sun4i_codec_controls to add it, and create
> a duplicate one for the A20?
Because sun4i_codec_controls has five controls shared between A10 and A20,
and only two not shared.
And if we extended sun4i_codec_controls, we'd also have to duplicate
sun4i_codec_codec in order to use sun4i_codec_controls vs. sun7i_codec_controls,
which really contains exactly the same data otherwise.
The quirks here are just for two controls, Mic1 Boost Volume and Mic2 Boost Volume,
and there not even for the names or anything - just for some reason the register
moved away.
The simplest way was to add it to the quirks - which already have a variant
selection etc.
^ permalink raw reply
* [PATCH v6 3/6] kernel/reboot.c: export pm_power_off_prepare
From: Oleksij Rempel @ 2018-05-05 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504134956.36dc72a253d03e94a517a867@linux-foundation.org>
Moving Rafael from Cc to To.
Hi Rafael,
can you please help here?
I need your ACK or NACK for this patch.
On Fri, May 04, 2018 at 01:49:56PM -0700, Andrew Morton wrote:
> On Fri, 4 May 2018 20:50:52 +0200 Oleksij Rempel <o.rempel@pengutronix.de> wrote:
>
> > Hallo Andrew,
> > I need your ACK or NACK for this patch.
> >
> > This function is used to configure external PMIC to interpret
> > signal which will be triggered by pm_power_off as power off.
> > Since same signal can be used for stand by, I linked PMIC configuration
> > with pm_power_off_prepare to avoid possible conflicts.
> >
> > ...
> >
> > > --- a/kernel/reboot.c
> > > +++ b/kernel/reboot.c
> > > @@ -49,6 +49,7 @@ int reboot_force;
> > > */
> > >
> > > void (*pm_power_off_prepare)(void);
> > > +EXPORT_SYMBOL(pm_power_off_prepare);
> > >
>
> OK by me, but it's more of a Rafael thing.
>
--
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 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180505/28f953ea/attachment-0001.sig>
^ permalink raw reply
* [PATCH v14 3/8] ASoC: sun4i-codec: Merge sun4i_codec_left_mixer_controls and sun4i_codec_right_mixer_controls into sun4i_codec_mixer_controls
From: Danny Milosavljevic @ 2018-05-05 6:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503144618.oojhvmey44dtg5fa@flea>
Hi Maxime,
On Thu, 3 May 2018 16:46:19 +0200
Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> Doesn't that mean that the controls will be shared between the right
> and left mixers now, which wasn't the case before?
Yes. However Chen-Yu said that except for debugfs that cannot be
observed by user space anyway.
It's nice to have the NEW controls have multiple channels, which is what
this does.
>And also, wouldn't
> the controls be called "Left Mixer Left Mixer Left DAC Playback
> Switch" (for the first one) now?
No. I checked using "amixer" - the names look fine,
"Left Mixer Left DAC Playback Switch".
With the patch series, amixer says:
numid=10,iface=MIXER,name='FM Playback Switch'
numid=6,iface=MIXER,name='FM Playback Volume'
numid=5,iface=MIXER,name='Line Boost Volume'
numid=9,iface=MIXER,name='Line Playback Switch'
numid=4,iface=MIXER,name='Line Playback Volume'
numid=1,iface=MIXER,name='Mic1 Boost Volume'
numid=11,iface=MIXER,name='Mic1 Playback Switch'
numid=2,iface=MIXER,name='Mic2 Boost Volume'
numid=12,iface=MIXER,name='Mic2 Playback Switch'
numid=7,iface=MIXER,name='Mic Playback Volume'
numid=18,iface=MIXER,name='Capture Source'
numid=19,iface=MIXER,name='Differential Line Source'
numid=8,iface=MIXER,name='Left Mixer Left DAC Playback Switch'
numid=15,iface=MIXER,name='Power Amplifier DAC Playback Switch'
numid=16,iface=MIXER,name='Power Amplifier Mixer Playback Switch'
numid=17,iface=MIXER,name='Power Amplifier Mute Switch'
numid=3,iface=MIXER,name='Power Amplifier Volume'
numid=14,iface=MIXER,name='Right Mixer Left DAC Playback Switch'
numid=13,iface=MIXER,name='Right Mixer Right DAC Playback Switch'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180505/33d470da/attachment.sig>
^ permalink raw reply
* [PATCH V3 1/2] clk: imx6sx: add missing lvds2 clock to the clock tree
From: Stephen Boyd @ 2018-05-05 2:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1524209891-14146-1-git-send-email-Anson.Huang@nxp.com>
Quoting Anson Huang (2018-04-20 00:38:10)
> i.MX6SX has lvds2 (analog clock2), an I/O clock like lvds1.
> And this lvds2, along with lvds1, can be used to provide
> external clock source to the internal pll, such as pll4_audio
> and pll5_video.
>
> This patch mainly adds the lvds2 to the clock tree and fix its
> relationship with pll accordingly.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
Applied to clk-next
^ permalink raw reply
* [PATCH] clk: imx6ul: fix periph clk2 clock mux selection
From: Stephen Boyd @ 2018-05-05 2:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180418125254.4397-1-stefan@agner.ch>
Quoting Stefan Agner (2018-04-18 05:52:54)
> According to the data sheet the 3rd choice is the bypass clock
> of pll2. This should not have any effect in practice as this
> selection is not used currently.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
Applied to clk-next
^ permalink raw reply
* [RESEND PATCH 5/5] usb: mtu3: make USB_MTU3_DUAL_ROLE depend on EXTCON but not USB_MTU3
From: Chunfeng Yun @ 2018-05-05 2:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3b0c7ca576fee8220d63c9914483b70b0fbc8783.1525486663.git.chunfeng.yun@mediatek.com>
In fact the driver depends on EXTCON only when it's configed as
USB_MTU3_DUAL_ROLE, so make USB_MTU3_DUAL_ROLE depend on EXTCON but
not USB_MTU3.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig
index 25cd619..8daf277 100644
--- a/drivers/usb/mtu3/Kconfig
+++ b/drivers/usb/mtu3/Kconfig
@@ -2,7 +2,7 @@
config USB_MTU3
tristate "MediaTek USB3 Dual Role controller"
- depends on EXTCON && (USB || USB_GADGET) && HAS_DMA
+ depends on (USB || USB_GADGET) && HAS_DMA
depends on ARCH_MEDIATEK || COMPILE_TEST
select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD
help
@@ -40,6 +40,7 @@ config USB_MTU3_GADGET
config USB_MTU3_DUAL_ROLE
bool "Dual Role mode"
depends on ((USB=y || USB=USB_MTU3) && (USB_GADGET=y || USB_GADGET=USB_MTU3))
+ depends on (EXTCON=y || EXTCON=USB_MTU3)
help
This is the default mode of working of MTU3 controller where
both host and gadget features are enabled.
--
1.9.1
^ permalink raw reply related
* [RESEND PATCH 4/5] usb: mtu3: fix operation failure when test TEST_J/K
From: Chunfeng Yun @ 2018-05-05 2:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3b0c7ca576fee8220d63c9914483b70b0fbc8783.1525486663.git.chunfeng.yun@mediatek.com>
There is an error dialog popped up in PC when test TEST_J/K
by EHSETT tool, due to not waiting for the completion of
control transfer. Here fix it by entering test mode after
Status Stage finish.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3_gadget_ep0.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/usb/mtu3/mtu3_gadget_ep0.c b/drivers/usb/mtu3/mtu3_gadget_ep0.c
index d67b540..0d2b1cf 100644
--- a/drivers/usb/mtu3/mtu3_gadget_ep0.c
+++ b/drivers/usb/mtu3/mtu3_gadget_ep0.c
@@ -7,6 +7,7 @@
* Author: Chunfeng.Yun <chunfeng.yun@mediatek.com>
*/
+#include <linux/iopoll.h>
#include <linux/usb/composite.h>
#include "mtu3.h"
@@ -263,6 +264,7 @@ static int handle_test_mode(struct mtu3 *mtu, struct usb_ctrlrequest *setup)
{
void __iomem *mbase = mtu->mac_base;
int handled = 1;
+ u32 value;
switch (le16_to_cpu(setup->wIndex) >> 8) {
case TEST_J:
@@ -292,6 +294,14 @@ static int handle_test_mode(struct mtu3 *mtu, struct usb_ctrlrequest *setup)
if (mtu->test_mode_nr == TEST_PACKET_MODE)
ep0_load_test_packet(mtu);
+ /* send status before entering test mode. */
+ value = mtu3_readl(mbase, U3D_EP0CSR) & EP0_W1C_BITS;
+ mtu3_writel(mbase, U3D_EP0CSR, value | EP0_SETUPPKTRDY | EP0_DATAEND);
+
+ /* wait for ACK status sent by host */
+ readl_poll_timeout(mbase + U3D_EP0CSR, value,
+ !(value & EP0_DATAEND), 100, 5000);
+
mtu3_writel(mbase, U3D_USB2_TEST_MODE, mtu->test_mode_nr);
mtu->ep0_state = MU3D_EP0_STATE_SETUP;
--
1.9.1
^ permalink raw reply related
* [RESEND PATCH 3/5] usb: mtu3: fix an unrecognized issue when connected with PC
From: Chunfeng Yun @ 2018-05-05 2:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3b0c7ca576fee8220d63c9914483b70b0fbc8783.1525486663.git.chunfeng.yun@mediatek.com>
When boot on the platform with the USB cable connected to Win7,
the Win7 will pop up an error dialog: "USB Device not recognized",
but finally the Win7 can enumerate it successfully.
The root cause is as the following:
When the xHCI driver set PORT_POWER of the OTG port, and if both
IDPIN and VBUS_VALID are high at the same time, the MTU3 controller
will set SESSION and pull up DP, so the Win7 can detect existence
of USB device, but if the mtu3 driver can't switch to device mode
during the debounce time, the Win7 can not enumerate it.
Here to fix it by removing the 1s delayed EXTCON register to speed up
mode switch.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3.h | 4 ----
drivers/usb/mtu3/mtu3_dr.c | 25 +++----------------------
2 files changed, 3 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index 2cd00a2..a56fee0 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -197,9 +197,6 @@ struct mtu3_gpd_ring {
* @edev: external connector used to detect vbus and iddig changes
* @vbus_nb: notifier for vbus detection
* @vbus_nb: notifier for iddig(idpin) detection
-* @extcon_reg_dwork: delay work for extcon notifier register, waiting for
-* xHCI driver initialization, it's necessary for system bootup
-* as device.
* @is_u3_drd: whether port0 supports usb3.0 dual-role device or not
* @manual_drd_enabled: it's true when supports dual-role device by debugfs
* to switch host/device modes depending on user input.
@@ -209,7 +206,6 @@ struct otg_switch_mtk {
struct extcon_dev *edev;
struct notifier_block vbus_nb;
struct notifier_block id_nb;
- struct delayed_work extcon_reg_dwork;
bool is_u3_drd;
bool manual_drd_enabled;
};
diff --git a/drivers/usb/mtu3/mtu3_dr.c b/drivers/usb/mtu3/mtu3_dr.c
index db7562d..80083e0 100644
--- a/drivers/usb/mtu3/mtu3_dr.c
+++ b/drivers/usb/mtu3/mtu3_dr.c
@@ -238,15 +238,6 @@ static int ssusb_extcon_register(struct otg_switch_mtk *otg_sx)
return 0;
}
-static void extcon_register_dwork(struct work_struct *work)
-{
- struct delayed_work *dwork = to_delayed_work(work);
- struct otg_switch_mtk *otg_sx =
- container_of(dwork, struct otg_switch_mtk, extcon_reg_dwork);
-
- ssusb_extcon_register(otg_sx);
-}
-
/*
* We provide an interface via debugfs to switch between host and device modes
* depending on user input.
@@ -407,18 +398,10 @@ int ssusb_otg_switch_init(struct ssusb_mtk *ssusb)
{
struct otg_switch_mtk *otg_sx = &ssusb->otg_switch;
- if (otg_sx->manual_drd_enabled) {
+ if (otg_sx->manual_drd_enabled)
ssusb_debugfs_init(ssusb);
- } else {
- INIT_DELAYED_WORK(&otg_sx->extcon_reg_dwork,
- extcon_register_dwork);
-
- /*
- * It is enough to delay 1s for waiting for
- * host initialization
- */
- schedule_delayed_work(&otg_sx->extcon_reg_dwork, HZ);
- }
+ else
+ ssusb_extcon_register(otg_sx);
return 0;
}
@@ -429,6 +412,4 @@ void ssusb_otg_switch_exit(struct ssusb_mtk *ssusb)
if (otg_sx->manual_drd_enabled)
ssusb_debugfs_exit(ssusb);
- else
- cancel_delayed_work(&otg_sx->extcon_reg_dwork);
}
--
1.9.1
^ permalink raw reply related
* [RESEND PATCH 2/5] usb: mtu3: remove repeated setting of gadget state
From: Chunfeng Yun @ 2018-05-05 2:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3b0c7ca576fee8220d63c9914483b70b0fbc8783.1525486663.git.chunfeng.yun@mediatek.com>
The usb_add_gadget_udc() will set the gadget state as
USB_STATE_NOTATTACHED, so we needn't set it again.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3_gadget.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3_gadget.c b/drivers/usb/mtu3/mtu3_gadget.c
index f05f10f..de0de01 100644
--- a/drivers/usb/mtu3/mtu3_gadget.c
+++ b/drivers/usb/mtu3/mtu3_gadget.c
@@ -660,14 +660,10 @@ int mtu3_gadget_setup(struct mtu3 *mtu)
mtu3_gadget_init_eps(mtu);
ret = usb_add_gadget_udc(mtu->dev, &mtu->g);
- if (ret) {
+ if (ret)
dev_err(mtu->dev, "failed to register udc\n");
- return ret;
- }
- usb_gadget_set_state(&mtu->g, USB_STATE_NOTATTACHED);
-
- return 0;
+ return ret;
}
void mtu3_gadget_cleanup(struct mtu3 *mtu)
--
1.9.1
^ permalink raw reply related
* [RESEND PATCH 1/5] usb: mtu3: avoid TX data length truncated in SS/SSP mode
From: Chunfeng Yun @ 2018-05-05 2:21 UTC (permalink / raw)
To: linux-arm-kernel
The variable of 'count' is declared as u8, this will cause an issue
due to value truncated when works in SS or SSP mode and data length
is greater than 255, so change it as u32.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3_gadget_ep0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/mtu3/mtu3_gadget_ep0.c b/drivers/usb/mtu3/mtu3_gadget_ep0.c
index ebdcf7a..d67b540 100644
--- a/drivers/usb/mtu3/mtu3_gadget_ep0.c
+++ b/drivers/usb/mtu3/mtu3_gadget_ep0.c
@@ -546,7 +546,7 @@ static void ep0_tx_state(struct mtu3 *mtu)
struct usb_request *req;
u32 csr;
u8 *src;
- u8 count;
+ u32 count;
u32 maxp;
dev_dbg(mtu->dev, "%s\n", __func__);
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/2] phy: mediatek: add XS-PHY driver
From: Chunfeng Yun @ 2018-05-05 2:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525486506-19301-1-git-send-email-chunfeng.yun@mediatek.com>
Support XS-PHY for MediaTek SoCs with USB3.1 GEN2 controller
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/phy/mediatek/Kconfig | 9 +
drivers/phy/mediatek/Makefile | 1 +
drivers/phy/mediatek/phy-mtk-xsphy.c | 600 ++++++++++++++++++++++++++++++++++
3 files changed, 610 insertions(+)
create mode 100644 drivers/phy/mediatek/phy-mtk-xsphy.c
diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
index 88ab4e2..8857d00 100644
--- a/drivers/phy/mediatek/Kconfig
+++ b/drivers/phy/mediatek/Kconfig
@@ -12,3 +12,12 @@ config PHY_MTK_TPHY
different banks layout, the T-PHY with shared banks between
multi-ports is first version, otherwise is second veriosn,
so you can easily distinguish them by banks layout.
+
+config PHY_MTK_XSPHY
+ tristate "MediaTek XS-PHY Driver"
+ depends on ARCH_MEDIATEK && OF
+ select GENERIC_PHY
+ help
+ Enable this to support the SuperSpeedPlus XS-PHY transceiver for
+ USB3.1 GEN2 controllers on MediaTek chips. The driver supports
+ multiple USB2.0, USB3.1 GEN2 ports.
diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
index 1bdab14..ee49edc 100644
--- a/drivers/phy/mediatek/Makefile
+++ b/drivers/phy/mediatek/Makefile
@@ -4,3 +4,4 @@
#
obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
+obj-$(CONFIG_PHY_MTK_XSPHY) += phy-mtk-xsphy.o
diff --git a/drivers/phy/mediatek/phy-mtk-xsphy.c b/drivers/phy/mediatek/phy-mtk-xsphy.c
new file mode 100644
index 0000000..020cd02
--- /dev/null
+++ b/drivers/phy/mediatek/phy-mtk-xsphy.c
@@ -0,0 +1,600 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek USB3.1 gen2 xsphy Driver
+ *
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
+ *
+ */
+
+#include <dt-bindings/phy/phy.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+
+/* u2 phy banks */
+#define SSUSB_SIFSLV_MISC 0x000
+#define SSUSB_SIFSLV_U2FREQ 0x100
+#define SSUSB_SIFSLV_U2PHY_COM 0x300
+
+/* u3 phy shared banks */
+#define SSPXTP_SIFSLV_DIG_GLB 0x000
+#define SSPXTP_SIFSLV_PHYA_GLB 0x100
+
+/* u3 phy banks */
+#define SSPXTP_SIFSLV_DIG_LN_TOP 0x000
+#define SSPXTP_SIFSLV_DIG_LN_TX0 0x100
+#define SSPXTP_SIFSLV_DIG_LN_RX0 0x200
+#define SSPXTP_SIFSLV_DIG_LN_DAIF 0x300
+#define SSPXTP_SIFSLV_PHYA_LN 0x400
+
+#define XSP_U2FREQ_FMCR0 ((SSUSB_SIFSLV_U2FREQ) + 0x00)
+#define P2F_RG_FREQDET_EN BIT(24)
+#define P2F_RG_CYCLECNT GENMASK(23, 0)
+#define P2F_RG_CYCLECNT_VAL(x) ((P2F_RG_CYCLECNT) & (x))
+
+#define XSP_U2FREQ_MMONR0 ((SSUSB_SIFSLV_U2FREQ) + 0x0c)
+
+#define XSP_U2FREQ_FMMONR1 ((SSUSB_SIFSLV_U2FREQ) + 0x10)
+#define P2F_RG_FRCK_EN BIT(8)
+#define P2F_USB_FM_VALID BIT(0)
+
+#define XSP_USBPHYACR0 ((SSUSB_SIFSLV_U2PHY_COM) + 0x00)
+#define P2A0_RG_INTR_EN BIT(5)
+
+#define XSP_USBPHYACR1 ((SSUSB_SIFSLV_U2PHY_COM) + 0x04)
+#define P2A1_RG_INTR_CAL GENMASK(23, 19)
+#define P2A1_RG_INTR_CAL_VAL(x) ((0x1f & (x)) << 19)
+#define P2A1_RG_VRT_SEL GENMASK(14, 12)
+#define P2A1_RG_VRT_SEL_VAL(x) ((0x7 & (x)) << 12)
+#define P2A1_RG_TERM_SEL GENMASK(10, 8)
+#define P2A1_RG_TERM_SEL_VAL(x) ((0x7 & (x)) << 8)
+
+#define XSP_USBPHYACR5 ((SSUSB_SIFSLV_U2PHY_COM) + 0x014)
+#define P2A5_RG_HSTX_SRCAL_EN BIT(15)
+#define P2A5_RG_HSTX_SRCTRL GENMASK(14, 12)
+#define P2A5_RG_HSTX_SRCTRL_VAL(x) ((0x7 & (x)) << 12)
+
+#define XSP_USBPHYACR6 ((SSUSB_SIFSLV_U2PHY_COM) + 0x018)
+#define P2A6_RG_BC11_SW_EN BIT(23)
+#define P2A6_RG_OTG_VBUSCMP_EN BIT(20)
+
+#define XSP_U2PHYDTM1 ((SSUSB_SIFSLV_U2PHY_COM) + 0x06C)
+#define P2D_FORCE_IDDIG BIT(9)
+#define P2D_RG_VBUSVALID BIT(5)
+#define P2D_RG_SESSEND BIT(4)
+#define P2D_RG_AVALID BIT(2)
+#define P2D_RG_IDDIG BIT(1)
+
+#define SSPXTP_PHYA_GLB_00 ((SSPXTP_SIFSLV_PHYA_GLB) + 0x00)
+#define RG_XTP_GLB_BIAS_INTR_CTRL GENMASK(21, 16)
+#define RG_XTP_GLB_BIAS_INTR_CTRL_VAL(x) ((0x3f & (x)) << 16)
+
+#define SSPXTP_PHYA_LN_04 ((SSPXTP_SIFSLV_PHYA_LN) + 0x04)
+#define RG_XTP_LN0_TX_IMPSEL GENMASK(4, 0)
+#define RG_XTP_LN0_TX_IMPSEL_VAL(x) (0x1f & (x))
+
+#define SSPXTP_PHYA_LN_14 ((SSPXTP_SIFSLV_PHYA_LN) + 0x014)
+#define RG_XTP_LN0_RX_IMPSEL GENMASK(4, 0)
+#define RG_XTP_LN0_RX_IMPSEL_VAL(x) (0x1f & (x))
+
+#define XSP_REF_CLK 26 /* MHZ */
+#define XSP_SLEW_RATE_COEF 17
+#define XSP_SR_COEF_DIVISOR 1000
+#define XSP_FM_DET_CYCLE_CNT 1024
+
+struct xsphy_instance {
+ struct phy *phy;
+ void __iomem *port_base;
+ struct clk *ref_clk; /* reference clock of anolog phy */
+ u32 index;
+ u32 type;
+ /* only for HQA test */
+ int efuse_intr;
+ int efuse_tx_imp;
+ int efuse_rx_imp;
+ /* u2 eye diagram */
+ int eye_src;
+ int eye_vrt;
+ int eye_term;
+};
+
+struct mtk_xsphy {
+ struct device *dev;
+ void __iomem *glb_base; /* only shared u3 sif */
+ struct xsphy_instance **phys;
+ int nphys;
+ int src_ref_clk; /* MHZ, reference clock for slew rate calibrate */
+ int src_coef; /* coefficient for slew rate calibrate */
+};
+
+static void u2_phy_slew_rate_calibrate(struct mtk_xsphy *xsphy,
+ struct xsphy_instance *inst)
+{
+ void __iomem *pbase = inst->port_base;
+ int calib_val;
+ int fm_out;
+ u32 tmp;
+
+ /* use force value */
+ if (inst->eye_src)
+ return;
+
+ /* enable USB ring oscillator */
+ tmp = readl(pbase + XSP_USBPHYACR5);
+ tmp |= P2A5_RG_HSTX_SRCAL_EN;
+ writel(tmp, pbase + XSP_USBPHYACR5);
+ udelay(1); /* wait clock stable */
+
+ /* enable free run clock */
+ tmp = readl(pbase + XSP_U2FREQ_FMMONR1);
+ tmp |= P2F_RG_FRCK_EN;
+ writel(tmp, pbase + XSP_U2FREQ_FMMONR1);
+
+ /* set cycle count as 1024 */
+ tmp = readl(pbase + XSP_U2FREQ_FMCR0);
+ tmp &= ~(P2F_RG_CYCLECNT);
+ tmp |= P2F_RG_CYCLECNT_VAL(XSP_FM_DET_CYCLE_CNT);
+ writel(tmp, pbase + XSP_U2FREQ_FMCR0);
+
+ /* enable frequency meter */
+ tmp = readl(pbase + XSP_U2FREQ_FMCR0);
+ tmp |= P2F_RG_FREQDET_EN;
+ writel(tmp, pbase + XSP_U2FREQ_FMCR0);
+
+ /* ignore return value */
+ readl_poll_timeout(pbase + XSP_U2FREQ_FMMONR1, tmp,
+ (tmp & P2F_USB_FM_VALID), 10, 200);
+
+ fm_out = readl(pbase + XSP_U2FREQ_MMONR0);
+
+ /* disable frequency meter */
+ tmp = readl(pbase + XSP_U2FREQ_FMCR0);
+ tmp &= ~P2F_RG_FREQDET_EN;
+ writel(tmp, pbase + XSP_U2FREQ_FMCR0);
+
+ /* disable free run clock */
+ tmp = readl(pbase + XSP_U2FREQ_FMMONR1);
+ tmp &= ~P2F_RG_FRCK_EN;
+ writel(tmp, pbase + XSP_U2FREQ_FMMONR1);
+
+ if (fm_out) {
+ /* (1024 / FM_OUT) x reference clock frequency x coefficient */
+ tmp = xsphy->src_ref_clk * xsphy->src_coef;
+ tmp = (tmp * XSP_FM_DET_CYCLE_CNT) / fm_out;
+ calib_val = DIV_ROUND_CLOSEST(tmp, XSP_SR_COEF_DIVISOR);
+ } else {
+ /* if FM detection fail, set default value */
+ calib_val = 3;
+ }
+ dev_dbg(xsphy->dev, "phy.%d, fm_out:%d, calib:%d (clk:%d, coef:%d)\n",
+ inst->index, fm_out, calib_val,
+ xsphy->src_ref_clk, xsphy->src_coef);
+
+ /* set HS slew rate */
+ tmp = readl(pbase + XSP_USBPHYACR5);
+ tmp &= ~P2A5_RG_HSTX_SRCTRL;
+ tmp |= P2A5_RG_HSTX_SRCTRL_VAL(calib_val);
+ writel(tmp, pbase + XSP_USBPHYACR5);
+
+ /* disable USB ring oscillator */
+ tmp = readl(pbase + XSP_USBPHYACR5);
+ tmp &= ~P2A5_RG_HSTX_SRCAL_EN;
+ writel(tmp, pbase + XSP_USBPHYACR5);
+}
+
+static void u2_phy_instance_init(struct mtk_xsphy *xsphy,
+ struct xsphy_instance *inst)
+{
+ void __iomem *pbase = inst->port_base;
+ u32 tmp;
+
+ /* DP/DM BC1.1 path Disable */
+ tmp = readl(pbase + XSP_USBPHYACR6);
+ tmp &= ~P2A6_RG_BC11_SW_EN;
+ writel(tmp, pbase + XSP_USBPHYACR6);
+
+ tmp = readl(pbase + XSP_USBPHYACR0);
+ tmp |= P2A0_RG_INTR_EN;
+ writel(tmp, pbase + XSP_USBPHYACR0);
+}
+
+static void u2_phy_instance_power_on(struct mtk_xsphy *xsphy,
+ struct xsphy_instance *inst)
+{
+ void __iomem *pbase = inst->port_base;
+ u32 index = inst->index;
+ u32 tmp;
+
+ tmp = readl(pbase + XSP_USBPHYACR6);
+ tmp |= P2A6_RG_OTG_VBUSCMP_EN;
+ writel(tmp, pbase + XSP_USBPHYACR6);
+
+ tmp = readl(pbase + XSP_U2PHYDTM1);
+ tmp |= P2D_RG_VBUSVALID | P2D_RG_AVALID;
+ tmp &= ~P2D_RG_SESSEND;
+ writel(tmp, pbase + XSP_U2PHYDTM1);
+
+ dev_dbg(xsphy->dev, "%s(%d)\n", __func__, index);
+}
+
+static void u2_phy_instance_power_off(struct mtk_xsphy *xsphy,
+ struct xsphy_instance *inst)
+{
+ void __iomem *pbase = inst->port_base;
+ u32 index = inst->index;
+ u32 tmp;
+
+ tmp = readl(pbase + XSP_USBPHYACR6);
+ tmp &= ~P2A6_RG_OTG_VBUSCMP_EN;
+ writel(tmp, pbase + XSP_USBPHYACR6);
+
+ tmp = readl(pbase + XSP_U2PHYDTM1);
+ tmp &= ~(P2D_RG_VBUSVALID | P2D_RG_AVALID);
+ tmp |= P2D_RG_SESSEND;
+ writel(tmp, pbase + XSP_U2PHYDTM1);
+
+ dev_dbg(xsphy->dev, "%s(%d)\n", __func__, index);
+}
+
+static void u2_phy_instance_set_mode(struct mtk_xsphy *xsphy,
+ struct xsphy_instance *inst,
+ enum phy_mode mode)
+{
+ u32 tmp;
+
+ tmp = readl(inst->port_base + XSP_U2PHYDTM1);
+ switch (mode) {
+ case PHY_MODE_USB_DEVICE:
+ tmp |= P2D_FORCE_IDDIG | P2D_RG_IDDIG;
+ break;
+ case PHY_MODE_USB_HOST:
+ tmp |= P2D_FORCE_IDDIG;
+ tmp &= ~P2D_RG_IDDIG;
+ break;
+ case PHY_MODE_USB_OTG:
+ tmp &= ~(P2D_FORCE_IDDIG | P2D_RG_IDDIG);
+ break;
+ default:
+ return;
+ }
+ writel(tmp, inst->port_base + XSP_U2PHYDTM1);
+}
+
+static void phy_parse_property(struct mtk_xsphy *xsphy,
+ struct xsphy_instance *inst)
+{
+ struct device *dev = &inst->phy->dev;
+
+ switch (inst->type) {
+ case PHY_TYPE_USB2:
+ device_property_read_u32(dev, "mediatek,efuse-intr",
+ &inst->efuse_intr);
+ device_property_read_u32(dev, "mediatek,eye-src",
+ &inst->eye_src);
+ device_property_read_u32(dev, "mediatek,eye-vrt",
+ &inst->eye_vrt);
+ device_property_read_u32(dev, "mediatek,eye-term",
+ &inst->eye_term);
+ dev_dbg(dev, "intr:%d, src:%d, vrt:%d, term:%d\n",
+ inst->efuse_intr, inst->eye_src,
+ inst->eye_vrt, inst->eye_term);
+ break;
+ case PHY_TYPE_USB3:
+ device_property_read_u32(dev, "mediatek,efuse-intr",
+ &inst->efuse_intr);
+ device_property_read_u32(dev, "mediatek,efuse-tx-imp",
+ &inst->efuse_tx_imp);
+ device_property_read_u32(dev, "mediatek,efuse-rx-imp",
+ &inst->efuse_rx_imp);
+ dev_dbg(dev, "intr:%d, tx-imp:%d, rx-imp:%d\n",
+ inst->efuse_intr, inst->efuse_tx_imp,
+ inst->efuse_rx_imp);
+ break;
+ default:
+ dev_err(xsphy->dev, "incompatible phy type\n");
+ return;
+ }
+}
+
+static void u2_phy_props_set(struct mtk_xsphy *xsphy,
+ struct xsphy_instance *inst)
+{
+ void __iomem *pbase = inst->port_base;
+ u32 tmp;
+
+ if (inst->efuse_intr) {
+ tmp = readl(pbase + XSP_USBPHYACR1);
+ tmp &= ~P2A1_RG_INTR_CAL;
+ tmp |= P2A1_RG_INTR_CAL_VAL(inst->efuse_intr);
+ writel(tmp, pbase + XSP_USBPHYACR1);
+ }
+
+ if (inst->eye_src) {
+ tmp = readl(pbase + XSP_USBPHYACR5);
+ tmp &= ~P2A5_RG_HSTX_SRCTRL;
+ tmp |= P2A5_RG_HSTX_SRCTRL_VAL(inst->eye_src);
+ writel(tmp, pbase + XSP_USBPHYACR5);
+ }
+
+ if (inst->eye_vrt) {
+ tmp = readl(pbase + XSP_USBPHYACR1);
+ tmp &= ~P2A1_RG_VRT_SEL;
+ tmp |= P2A1_RG_VRT_SEL_VAL(inst->eye_vrt);
+ writel(tmp, pbase + XSP_USBPHYACR1);
+ }
+
+ if (inst->eye_term) {
+ tmp = readl(pbase + XSP_USBPHYACR1);
+ tmp &= ~P2A1_RG_TERM_SEL;
+ tmp |= P2A1_RG_TERM_SEL_VAL(inst->eye_term);
+ writel(tmp, pbase + XSP_USBPHYACR1);
+ }
+}
+
+static void u3_phy_props_set(struct mtk_xsphy *xsphy,
+ struct xsphy_instance *inst)
+{
+ void __iomem *pbase = inst->port_base;
+ u32 tmp;
+
+ if (inst->efuse_intr) {
+ tmp = readl(xsphy->glb_base + SSPXTP_PHYA_GLB_00);
+ tmp &= ~RG_XTP_GLB_BIAS_INTR_CTRL;
+ tmp |= RG_XTP_GLB_BIAS_INTR_CTRL_VAL(inst->efuse_intr);
+ writel(tmp, xsphy->glb_base + SSPXTP_PHYA_GLB_00);
+ }
+
+ if (inst->efuse_tx_imp) {
+ tmp = readl(pbase + SSPXTP_PHYA_LN_04);
+ tmp &= ~RG_XTP_LN0_TX_IMPSEL;
+ tmp |= RG_XTP_LN0_TX_IMPSEL_VAL(inst->efuse_tx_imp);
+ writel(tmp, pbase + SSPXTP_PHYA_LN_04);
+ }
+
+ if (inst->efuse_rx_imp) {
+ tmp = readl(pbase + SSPXTP_PHYA_LN_14);
+ tmp &= ~RG_XTP_LN0_RX_IMPSEL;
+ tmp |= RG_XTP_LN0_RX_IMPSEL_VAL(inst->efuse_rx_imp);
+ writel(tmp, pbase + SSPXTP_PHYA_LN_14);
+ }
+}
+
+static int mtk_phy_init(struct phy *phy)
+{
+ struct xsphy_instance *inst = phy_get_drvdata(phy);
+ struct mtk_xsphy *xsphy = dev_get_drvdata(phy->dev.parent);
+ int ret;
+
+ ret = clk_prepare_enable(inst->ref_clk);
+ if (ret) {
+ dev_err(xsphy->dev, "failed to enable ref_clk\n");
+ return ret;
+ }
+
+ switch (inst->type) {
+ case PHY_TYPE_USB2:
+ u2_phy_instance_init(xsphy, inst);
+ u2_phy_props_set(xsphy, inst);
+ break;
+ case PHY_TYPE_USB3:
+ u3_phy_props_set(xsphy, inst);
+ break;
+ default:
+ dev_err(xsphy->dev, "incompatible phy type\n");
+ clk_disable_unprepare(inst->ref_clk);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int mtk_phy_power_on(struct phy *phy)
+{
+ struct xsphy_instance *inst = phy_get_drvdata(phy);
+ struct mtk_xsphy *xsphy = dev_get_drvdata(phy->dev.parent);
+
+ if (inst->type == PHY_TYPE_USB2) {
+ u2_phy_instance_power_on(xsphy, inst);
+ u2_phy_slew_rate_calibrate(xsphy, inst);
+ }
+
+ return 0;
+}
+
+static int mtk_phy_power_off(struct phy *phy)
+{
+ struct xsphy_instance *inst = phy_get_drvdata(phy);
+ struct mtk_xsphy *xsphy = dev_get_drvdata(phy->dev.parent);
+
+ if (inst->type == PHY_TYPE_USB2)
+ u2_phy_instance_power_off(xsphy, inst);
+
+ return 0;
+}
+
+static int mtk_phy_exit(struct phy *phy)
+{
+ struct xsphy_instance *inst = phy_get_drvdata(phy);
+
+ clk_disable_unprepare(inst->ref_clk);
+ return 0;
+}
+
+static int mtk_phy_set_mode(struct phy *phy, enum phy_mode mode)
+{
+ struct xsphy_instance *inst = phy_get_drvdata(phy);
+ struct mtk_xsphy *xsphy = dev_get_drvdata(phy->dev.parent);
+
+ if (inst->type == PHY_TYPE_USB2)
+ u2_phy_instance_set_mode(xsphy, inst, mode);
+
+ return 0;
+}
+
+static struct phy *mtk_phy_xlate(struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct mtk_xsphy *xsphy = dev_get_drvdata(dev);
+ struct xsphy_instance *inst = NULL;
+ struct device_node *phy_np = args->np;
+ int index;
+
+ if (args->args_count != 1) {
+ dev_err(dev, "invalid number of cells in 'phy' property\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ for (index = 0; index < xsphy->nphys; index++)
+ if (phy_np == xsphy->phys[index]->phy->dev.of_node) {
+ inst = xsphy->phys[index];
+ break;
+ }
+
+ if (!inst) {
+ dev_err(dev, "failed to find appropriate phy\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ inst->type = args->args[0];
+ if (!(inst->type == PHY_TYPE_USB2 ||
+ inst->type == PHY_TYPE_USB3)) {
+ dev_err(dev, "unsupported phy type: %d\n", inst->type);
+ return ERR_PTR(-EINVAL);
+ }
+
+ phy_parse_property(xsphy, inst);
+
+ return inst->phy;
+}
+
+static const struct phy_ops mtk_xsphy_ops = {
+ .init = mtk_phy_init,
+ .exit = mtk_phy_exit,
+ .power_on = mtk_phy_power_on,
+ .power_off = mtk_phy_power_off,
+ .set_mode = mtk_phy_set_mode,
+ .owner = THIS_MODULE,
+};
+
+static const struct of_device_id mtk_xsphy_id_table[] = {
+ { .compatible = "mediatek,xsphy", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, mtk_xsphy_id_table);
+
+static int mtk_xsphy_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ struct device_node *child_np;
+ struct phy_provider *provider;
+ struct resource *glb_res;
+ struct mtk_xsphy *xsphy;
+ struct resource res;
+ int port, retval;
+
+ xsphy = devm_kzalloc(dev, sizeof(*xsphy), GFP_KERNEL);
+ if (!xsphy)
+ return -ENOMEM;
+
+ xsphy->nphys = of_get_child_count(np);
+ xsphy->phys = devm_kcalloc(dev, xsphy->nphys,
+ sizeof(*xsphy->phys), GFP_KERNEL);
+ if (!xsphy->phys)
+ return -ENOMEM;
+
+ xsphy->dev = dev;
+ platform_set_drvdata(pdev, xsphy);
+
+ glb_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ /* optional, may not exist if no u3 phys */
+ if (glb_res) {
+ /* get banks shared by multiple u3 phys */
+ xsphy->glb_base = devm_ioremap_resource(dev, glb_res);
+ if (IS_ERR(xsphy->glb_base)) {
+ dev_err(dev, "failed to remap glb regs\n");
+ return PTR_ERR(xsphy->glb_base);
+ }
+ }
+
+ xsphy->src_ref_clk = XSP_REF_CLK;
+ xsphy->src_coef = XSP_SLEW_RATE_COEF;
+ /* update parameters of slew rate calibrate if exist */
+ device_property_read_u32(dev, "mediatek,src-ref-clk-mhz",
+ &xsphy->src_ref_clk);
+ device_property_read_u32(dev, "mediatek,src-coef", &xsphy->src_coef);
+
+ port = 0;
+ for_each_child_of_node(np, child_np) {
+ struct xsphy_instance *inst;
+ struct phy *phy;
+
+ inst = devm_kzalloc(dev, sizeof(*inst), GFP_KERNEL);
+ if (!inst) {
+ retval = -ENOMEM;
+ goto put_child;
+ }
+
+ xsphy->phys[port] = inst;
+
+ phy = devm_phy_create(dev, child_np, &mtk_xsphy_ops);
+ if (IS_ERR(phy)) {
+ dev_err(dev, "failed to create phy\n");
+ retval = PTR_ERR(phy);
+ goto put_child;
+ }
+
+ retval = of_address_to_resource(child_np, 0, &res);
+ if (retval) {
+ dev_err(dev, "failed to get address resource(id-%d)\n",
+ port);
+ goto put_child;
+ }
+
+ inst->port_base = devm_ioremap_resource(&phy->dev, &res);
+ if (IS_ERR(inst->port_base)) {
+ dev_err(dev, "failed to remap phy regs\n");
+ retval = PTR_ERR(inst->port_base);
+ goto put_child;
+ }
+
+ inst->phy = phy;
+ inst->index = port;
+ phy_set_drvdata(phy, inst);
+ port++;
+
+ inst->ref_clk = devm_clk_get(&phy->dev, "ref");
+ if (IS_ERR(inst->ref_clk)) {
+ dev_err(dev, "failed to get ref_clk(id-%d)\n", port);
+ retval = PTR_ERR(inst->ref_clk);
+ goto put_child;
+ }
+ }
+
+ provider = devm_of_phy_provider_register(dev, mtk_phy_xlate);
+ return PTR_ERR_OR_ZERO(provider);
+
+put_child:
+ of_node_put(child_np);
+ return retval;
+}
+
+static struct platform_driver mtk_xsphy_driver = {
+ .probe = mtk_xsphy_probe,
+ .driver = {
+ .name = "mtk-xsphy",
+ .of_match_table = mtk_xsphy_id_table,
+ },
+};
+
+module_platform_driver(mtk_xsphy_driver);
+
+MODULE_AUTHOR("Chunfeng Yun <chunfeng.yun@mediatek.com>");
+MODULE_DESCRIPTION("MediaTek USB XS-PHY driver");
+MODULE_LICENSE("GPL v2");
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: add MediaTek XS-PHY binding
From: Chunfeng Yun @ 2018-05-05 2:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525486506-19301-1-git-send-email-chunfeng.yun@mediatek.com>
Add a DT binding documentation of XS-PHY for MediaTek SoCs
with USB3.1 GEN2 controller
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
.../devicetree/bindings/phy/phy-mtk-xsphy.txt | 110 ++++++++++++++++++++
1 file changed, 110 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt
diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt b/Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt
new file mode 100644
index 0000000..9a95fab
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt
@@ -0,0 +1,110 @@
+MediaTek XS-PHY binding
+--------------------------
+
+The XS-PHY controller supports physical layer functionality for USB3.1
+GEN2 controller on MediaTek SoCs.
+
+Required properties (controller (parent) node):
+ - compatible : should be "mediatek,<soc-model>-xsphy", "mediatek,xsphy",
+ soc-model is the name of SoC, such as mt2712 etc;
+ when using "mediatek,xsphy" compatible string, you need SoC specific
+ ones in addition, one of:
+ - "mediatek,mt3611-xsphy"
+
+ - #address-cells, #size-cells : should use the same values as the root node
+ - ranges: must be present
+
+Optional properties (controller (parent) node):
+ - reg : offset and length of register shared by multiple U3 ports,
+ exclude port's private register, if only U2 ports provided,
+ shouldn't use the property.
+ - mediatek,src-ref-clk-mhz : u32, frequency of reference clock for slew rate
+ calibrate
+ - mediatek,src-coef : u32, coefficient for slew rate calibrate, depends on
+ SoC process
+
+Required nodes : a sub-node is required for each port the controller
+ provides. Address range information including the usual
+ 'reg' property is used inside these nodes to describe
+ the controller's topology.
+
+Required properties (port (child) node):
+- reg : address and length of the register set for the port.
+- clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+- clock-names : must contain
+ "ref": 48M reference clock for HighSpeed analog phy; and 26M
+ reference clock for SuperSpeedPlus analog phy, sometimes is
+ 24M, 25M or 27M, depended on platform.
+- #phy-cells : should be 1
+ cell after port phandle is phy type from:
+ - PHY_TYPE_USB2
+ - PHY_TYPE_USB3
+
+The following optional properties are only for debug or HQA test
+Optional properties (PHY_TYPE_USB2 port (child) node):
+- mediatek,eye-src : u32, the value of slew rate calibrate
+- mediatek,eye-vrt : u32, the selection of VRT reference voltage
+- mediatek,eye-term : u32, the selection of HS_TX TERM reference voltage
+- mediatek,efuse-intr : u32, the selection of Internal Resistor
+
+Optional properties (PHY_TYPE_USB3 port (child) node):
+- mediatek,efuse-intr : u32, the selection of Internal Resistor
+- mediatek,efuse-tx-imp : u32, the selection of TX Impedance
+- mediatek,efuse-rx-imp : u32, the selection of RX Impedance
+
+Banks layout of xsphy
+-------------------------------------------------------------
+port offset bank
+u2 port0 0x0000 MISC
+ 0x0100 FMREG
+ 0x0300 U2PHY_COM
+u2 port1 0x1000 MISC
+ 0x1100 FMREG
+ 0x1300 U2PHY_COM
+u2 port2 0x2000 MISC
+ ...
+u31 common 0x3000 DIG_GLB
+ 0x3100 PHYA_GLB
+u31 port0 0x3400 DIG_LN_TOP
+ 0x3500 DIG_LN_TX0
+ 0x3600 DIG_LN_RX0
+ 0x3700 DIG_LN_DAIF
+ 0x3800 PHYA_LN
+u31 port1 0x3a00 DIG_LN_TOP
+ 0x3b00 DIG_LN_TX0
+ 0x3c00 DIG_LN_RX0
+ 0x3d00 DIG_LN_DAIF
+ 0x3e00 PHYA_LN
+ ...
+
+DIG_GLB & PHYA_GLB are shared by U31 ports.
+
+Example:
+
+u3phy: usb-phy at 11c40000 {
+ compatible = "mediatek,mt3611-xsphy", "mediatek,xsphy";
+ reg = <0 0x11c43000 0 0x0200>;
+ mediatek,src-ref-clk-mhz = <26>;
+ mediatek,src-coef = <17>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ u2port0: usb-phy at 11c40000 {
+ reg = <0 0x11c40000 0 0x0400>;
+ clocks = <&clk48m>;
+ clock-names = "ref";
+ mediatek,eye-src = <4>;
+ #phy-cells = <1>;
+ };
+
+ u3port0: usb-phy at 11c43000 {
+ reg = <0 0x11c43400 0 0x0500>;
+ clocks = <&clk26m>;
+ clock-names = "ref";
+ mediatek,efuse-intr = <28>;
+ #phy-cells = <1>;
+ };
+};
+
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 0/2] Add MediaTek XS-PHY driver
From: Chunfeng Yun @ 2018-05-05 2:15 UTC (permalink / raw)
To: linux-arm-kernel
>From a0814ad7725587a06d273997e0fdf5161f916fd8 Mon Sep 17 00:00:00 2001
From: Chunfeng Yun <chunfeng.yun@mediatek.com>
Date: Sat, 5 May 2018 09:56:59 +0800
Subject: [PATCH v2 0/2] Add MediaTek XS-PHY driver
This patch series support the SuperSpeedPlus XS-PHY transceiver for
USB3.1 GEN2 controller on MediaTek chips. The driver supports multiple
USB2.0, USB3.1 GEN2 ports.
v2: changes in binding (suggested by Rob)
1. list all valid SoCs for compatible
2. move required child nodes after parent optional ones
3. remove status property in example
4. move banks layout example before dts one
5. remove phy binding example
6. add #address-cells, #size-cells, ranges properties for parent node
Chunfeng Yun (2):
dt-bindings: add MediaTek XS-PHY binding
phy: mediatek: add XS-PHY driver
.../devicetree/bindings/phy/phy-mtk-xsphy.txt | 110 ++++
drivers/phy/mediatek/Kconfig | 9 +
drivers/phy/mediatek/Makefile | 1 +
drivers/phy/mediatek/phy-mtk-xsphy.c | 600 +++++++++++++++++++++
4 files changed, 720 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt
create mode 100644 drivers/phy/mediatek/phy-mtk-xsphy.c
--
1.9.1
^ permalink raw reply
* [PATCH v2] phy: phy-mtk-tphy: use SPDX license tag
From: Chunfeng Yun @ 2018-05-05 1:47 UTC (permalink / raw)
To: linux-arm-kernel
Use SPDX-License-Identifier tag instead of the GPL license text
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
v2: change subject line to fix checkpatch warning:
"A patch subject line should describe the change not
the tool that found it"
---
drivers/phy/mediatek/Makefile | 1 +
drivers/phy/mediatek/phy-mtk-tphy.c | 10 +---------
2 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
index 763a92e..1bdab14 100644
--- a/drivers/phy/mediatek/Makefile
+++ b/drivers/phy/mediatek/Makefile
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
#
# Makefile for the phy drivers.
#
diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c b/drivers/phy/mediatek/phy-mtk-tphy.c
index 38c281b..b962339 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -1,16 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2015 MediaTek Inc.
* Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
*
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
*/
#include <dt-bindings/phy/phy.h>
--
1.9.1
^ permalink raw reply related
* [RFC PATCH] driver core: make deferring probe forever optional
From: Mark Brown @ 2018-05-05 1:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74d495d8-04e2-fb7d-7d07-0905fbc8a6cf@arm.com>
On Wed, May 02, 2018 at 07:49:57PM +0100, Robin Murphy wrote:
> I guess there's also the possibility that a single driver may want multiple
> behaviours, if e.g. if SoC variants A and B have some identical peripherals
> but slightly different pinctrl/IOMMU/etc. hardware such that A has workable
> default behaviour and can be treated as optional, whereas B absolutely must
> be controlled by the kernel for the consumers to function properly, and they
> *should* defer forever otherwise. I think that would pretty much demand some
> sort of explicitly-curated white/blacklist setup at the subsystem or driver
> level.
Different board variants, and possibly even different bootloaders might
also be an issue here - a vendor bootloader might do pinmuxing that an
upstream bootloader doesn't for example. In some cases the pinmuxing
even depends on the boot method with things only getting configured if
the bootloader wanted to use them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180505/a0a54ead/attachment.sig>
^ permalink raw reply
* [PATCH 1/3] spi: meson-axg: support MAX 80M clock
From: Mark Brown @ 2018-05-05 0:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6cdee2c8-2ca4-2efb-43ac-c233516c0570@amlogic.com>
On Fri, May 04, 2018 at 09:56:10AM +0800, Yixun Lan wrote:
> Here I only introduce the dt compatible data to differentiate the
> old/new controller, the compatible name is not changed, and none of the
> property is introduced.
Right, sorry - this bit is fine.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180505/a4c8caf9/attachment.sig>
^ permalink raw reply
* [PATCH v3 3/3] sh: add the sh_ prefix to early platform symbols
From: Arnd Bergmann @ 2018-05-05 0:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504132731.14574-4-brgl@bgdev.pl>
On Fri, May 4, 2018 at 9:27 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Old early platform device support is now sh-specific. Before moving on
> to implementing new early platform framework based on real platform
> devices, prefix all early platform symbols with 'sh_'.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Looks good. I was thinking of something shorter as the new namespace,
but actually using a longer name like you do seems appropriate since
we don't want anyone to actually use it. ;-)
Arnd
^ permalink raw reply
* [PATCH v3 1/3] clocksource: timer-ti-dm: remove the early platform driver registration
From: Arnd Bergmann @ 2018-05-05 0:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504132731.14574-2-brgl@bgdev.pl>
On Fri, May 4, 2018 at 9:27 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> This driver is no longer used as an early platform driver. Remove the
> registration macro.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH v2 10/27] dts: bindings: Restrict coresight tmc-etr scatter-gather mode
From: Rob Herring @ 2018-05-04 22:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkwozU7QC5EeEy46KrEd4X7J9S69SiNg8-GhSSuMkhQrBw@mail.gmail.com>
On Thu, May 3, 2018 at 3:32 PM, Mathieu Poirier
<mathieu.poirier@linaro.org> wrote:
> On 1 May 2018 at 07:13, Rob Herring <robh@kernel.org> wrote:
>> On Tue, May 01, 2018 at 10:10:40AM +0100, Suzuki K Poulose wrote:
>>> We are about to add the support for ETR builtin scatter-gather mode
>>> for dealing with large amount of trace buffers. However, on some of
>>> the platforms, using the ETR SG mode can lock up the system due to
>>> the way the ETR is connected to the memory subsystem.
>>>
>>> In SG mode, the ETR performs READ from the scatter-gather table to
>>> fetch the next page and regular WRITE of trace data. If the READ
>>> operation doesn't complete(due to the memory subsystem issues,
>>> which we have seen on a couple of platforms) the trace WRITE
>>> cannot proceed leading to issues. So, we by default do not
>>> use the SG mode, unless it is known to be safe on the platform.
>>> We define a DT property for the TMC node to specify whether we
>>> have a proper SG mode.
>>>
>>> Cc: Mathieu Poirier <matheiu.poirier@linaro.org>
>>> Cc: Mike Leach <mike.leach@linaro.org>
>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>> Cc: John Horley <john.horley@arm.com>
>>> Cc: Robert Walker <robert.walker@arm.com>
>>> Cc: devicetree at vger.kernel.org
>>> Cc: frowand.list at gmail.com
>>> Cc: Rob Herring <robh@kernel.org>
>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>> ---
>>> Documentation/devicetree/bindings/arm/coresight.txt | 3 +++
>>> drivers/hwtracing/coresight/coresight-tmc.c | 8 +++++++-
>>> 2 files changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
>>> index cdd84d0..7c0c8f0 100644
>>> --- a/Documentation/devicetree/bindings/arm/coresight.txt
>>> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
>>> @@ -88,6 +88,9 @@ its hardware characteristcs.
>>> * arm,buffer-size: size of contiguous buffer space for TMC ETR
>>> (embedded trace router)
>>>
>>> + * scatter-gather: boolean. Indicates that the TMC-ETR can safely
>>> + use the SG mode on this system.
>>> +
>>
>> Needs a vendor prefix.
>>
>
> Thinking further on this, do we need to make it device specific as
> well - something like "arm,etr-scatter-gather"? That way we don't
> have to redefine "scatter-gather" for other ARM devices if they happen
> to need the same property but for different reasons.
No. If we had a bunch of cases, then we'd probably want to have just
'scatter-gather'.
BTW, if SG had already been supported, then I'd say this is a quirk
and we should invert this property. Otherwise, you'd be disabling once
enabled SG and require working platforms to update their dtb. Of
course, I shouldn't really let the state of an OS driver influence the
DT binding.
Rob
^ permalink raw reply
* [PATCH] [stable] arm64: Add work around for Arm Cortex-A55 Erratum 1024718
From: Greg KH @ 2018-05-04 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525170364-21032-1-git-send-email-suzuki.poulose@arm.com>
On Tue, May 01, 2018 at 11:26:04AM +0100, Suzuki K Poulose wrote:
> commit ece1397cbc89c51914fae1aec729539cfd8bd62b upstream
>
> Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer
> from an erratum 1024718, which causes incorrect updates when DBM/AP
> bits in a page table entry is modified without a break-before-make
> sequence. The work around is to disable the hardware DBM feature
> on the affected cores. The hardware Access Flag management features
> is not affected.
>
> The hardware DBM feature is a non-conflicting capability, i.e, the
> kernel could handle cores using the feature and those without having
> the features running at the same time. So this work around is detected
> at early boot time, rather than delaying it until the CPUs are brought
> up into the kernel with MMU turned on. This also avoids other complexities
> with late CPUs turning online, with or without the hardware DBM features.
>
> Note: The upstream commit is on top of a reworked capability
> infrastructure for arm64 heterogeneous systems, which allows
> handling this later in the boot process. This backport
> is based on the original version of the patch [0]. Folded the 3
> patches into this single commit, removing the unncessary bits.
>
> [0] https://lkml.kernel.org/r/20180116102323.3470-1-suzuki.poulose at arm.com
>
> Cc: stable at vger.kernel.org # v4.3 to v4.16
This only would apply to the 4.16.y tree. Can you provide working
backports to 4.14.y, 4.9.y, and 4.4.y so I can queue them up there as
well?
thanks,
greg k-h
^ permalink raw reply
* [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI
From: Giulio Benetti @ 2018-05-04 22:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <644bcd2f-3479-3f3c-3aef-9db3d565c133@orpaltech.com>
Hi Sergey,
Il 04/05/2018 23:59, Sergey Suloev ha scritto:
> Hi, Giulio,
>
> On 05/05/2018 12:52 AM, Giulio Benetti wrote:
>> Hi Maxime!
>>
>> Il 04/05/2018 10:06, Maxime Ripard ha scritto:
>>> Hi,
>>>
>>> On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote:
>>>>>> You don't have to handcode the fragments anymore with the new syntax,
>>>>>> and U-Boot makes it really trivial to use if you use the FIT image
>>>>>> format to have multiple overlays bundled in the same image. You can
>>>>>> choose to apply them dynamically, for example based on an EEPROM or
>>>>>> some other metric to see which combination you have.
>>>>>
>>>>> Ah, this is interesting. I'm going to experiment with that.
>>>>>
>>>>
>>>> I'm struggling against this, I don't really know how to proceed,
>>>> except keeping monolithic dts files including other dtsi files.
>>>>
>>>> About dt-overlays I've tried to look around lot of time,
>>>> but the only thing I've found is this:
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays
>>>>
>>>>
>>>> where they use .dtso tagging them as "/plugin/;"
>>>> and compile all .dtso found in dts folder.
>>>> Then they obtain .dtbo files that should be the dt-overlays we have
>>>> spoken
>>>> about right?
>>>
>>> Yes. You don't have to do that though, you can just rely on dtc to
>>> compile them, outside of the linux build system.
>>>
>>>> What I can't understand is if there's a real standard at this time to
>>>> follow, because on renesas-driver they use their way to handle all
>>>> .dtso
>>>> files, but on mainline there seems to be nothing about that.
>>>
>>> I'm not sure what you mean here. It's just fragments of device tree,
>>> that have to be compiled using dtc, that's it. You can use the Linux
>>> build system infrastructure to do that, or you can build your own
>>> simpler one. That's really up to you. See for example
>>> https://github.com/NextThingCo/CHIP-dt-overlays/blob/master/Makefile
>>>
>>> (even though the overlays themselves use the legacy syntax and
>>> shouldn't really be used an examples)
>>
>> Everything works now!
>> Thank you very much!
>> I've setted up a Repo on Github to give an example on how make it work
>> with no pain:
>> https://github.com/micronovasrl/linova-dtoverlays
>>
>> At the moment it's a mess all around, but it's working and give an
>> idea on how to make it work. Though I'm going to clean it up well as a
>> base for linova dtoverlays.
>>
>> Ah, btw, can you confirm me that base dts file must be compiled
>> outside kernel with:
>> dtc -@ ....
>> Otherwise as in-tree dts with make dtbs "-@" argument is not passed.
>> Right?
>>
>> Thank you a lot for your help and time again!
>>
>> Best regards!
>>
> I'd highly recommend you to look at Armbian overlay support: it is easy
> and elegant.
>
> https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/add-overlay-compilation-support.patch
>
>
> https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/add-sunxi-overlays.patch
Thanks for pointing me that,
but as we've discussed before, at the moment overlays are not going to
be included in Mainline Kernel(Maxime correct if I'm wrong).
Try to think maintaining thousands and thousands of overlays,
it would be a nightmare(IMHO).
Maybe it will change, I don't know.
Thanks anyway.
Best regards
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
^ permalink raw reply
* [PATCH] arm64: dts: qcom: sdm845: Sort nodes in the soc by address
From: Douglas Anderson @ 2018-05-04 22:03 UTC (permalink / raw)
To: linux-arm-kernel
This is pure-churn and should be a no-op. I'm doing it in the hopes
of reducing merge conflicts. When things are sorted in a sane way
(and by base address seems sane) then it's less likely that future
patches will cause merge conflicts.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 152 +++++++++++++--------------
1 file changed, 76 insertions(+), 76 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 486ace9a9e8b..101350743bd2 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -158,32 +158,50 @@
ranges = <0 0 0 0xffffffff>;
compatible = "simple-bus";
- intc: interrupt-controller at 17a00000 {
- compatible = "arm,gic-v3";
+ gcc: clock-controller at 100000 {
+ compatible = "qcom,gcc-sdm845";
+ reg = <0x100000 0x1f0000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
+ geniqup at ac0000 {
+ compatible = "qcom,geni-se-qup";
+ reg = <0xac0000 0x6000>;
+ clock-names = "m-ahb", "s-ahb";
+ clocks = <&gcc 105>,
+ <&gcc 106>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
- #interrupt-cells = <3>;
- interrupt-controller;
- reg = <0x17a00000 0x10000>, /* GICD */
- <0x17a60000 0x100000>; /* GICR * 8 */
- interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
- gic-its at 17a40000 {
- compatible = "arm,gic-v3-its";
- msi-controller;
- #msi-cells = <1>;
- reg = <0x17a40000 0x20000>;
+ uart2: serial at a84000 {
+ compatible = "qcom,geni-debug-uart";
+ reg = <0xa84000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc 89>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_uart2_default>;
+ pinctrl-1 = <&qup_uart2_sleep>;
+ interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
};
- };
- gcc: clock-controller at 100000 {
- compatible = "qcom,gcc-sdm845";
- reg = <0x100000 0x1f0000>;
- #clock-cells = <1>;
- #reset-cells = <1>;
- #power-domain-cells = <1>;
+ i2c10: i2c at a88000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa88000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc 91>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c10_default>;
+ pinctrl-1 = <&qup_i2c10_sleep>;
+ interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
tlmm: pinctrl at 3400000 {
@@ -224,6 +242,45 @@
};
};
+ spmi_bus: spmi at c440000 {
+ compatible = "qcom,spmi-pmic-arb";
+ reg = <0xc440000 0x1100>,
+ <0xc600000 0x2000000>,
+ <0xe600000 0x100000>,
+ <0xe700000 0xa0000>,
+ <0xc40a000 0x26000>;
+ reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
+ interrupt-names = "periph_irq";
+ interrupts = <GIC_SPI 481 IRQ_TYPE_LEVEL_HIGH>;
+ qcom,ee = <0>;
+ qcom,channel = <0>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ interrupt-controller;
+ #interrupt-cells = <4>;
+ cell-index = <0>;
+ };
+
+ intc: interrupt-controller at 17a00000 {
+ compatible = "arm,gic-v3";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x17a00000 0x10000>, /* GICD */
+ <0x17a60000 0x100000>; /* GICR * 8 */
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+
+ gic-its at 17a40000 {
+ compatible = "arm,gic-v3-its";
+ msi-controller;
+ #msi-cells = <1>;
+ reg = <0x17a40000 0x20000>;
+ status = "disabled";
+ };
+ };
+
timer at 17c90000 {
#address-cells = <1>;
#size-cells = <1>;
@@ -281,62 +338,5 @@
status = "disabled";
};
};
-
- spmi_bus: spmi at c440000 {
- compatible = "qcom,spmi-pmic-arb";
- reg = <0xc440000 0x1100>,
- <0xc600000 0x2000000>,
- <0xe600000 0x100000>,
- <0xe700000 0xa0000>,
- <0xc40a000 0x26000>;
- reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
- interrupt-names = "periph_irq";
- interrupts = <GIC_SPI 481 IRQ_TYPE_LEVEL_HIGH>;
- qcom,ee = <0>;
- qcom,channel = <0>;
- #address-cells = <2>;
- #size-cells = <0>;
- interrupt-controller;
- #interrupt-cells = <4>;
- cell-index = <0>;
- };
-
- geniqup at ac0000 {
- compatible = "qcom,geni-se-qup";
- reg = <0xac0000 0x6000>;
- clock-names = "m-ahb", "s-ahb";
- clocks = <&gcc 105>,
- <&gcc 106>;
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
- status = "disabled";
-
- uart2: serial at a84000 {
- compatible = "qcom,geni-debug-uart";
- reg = <0xa84000 0x4000>;
- clock-names = "se";
- clocks = <&gcc 89>;
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&qup_uart2_default>;
- pinctrl-1 = <&qup_uart2_sleep>;
- interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
- status = "disabled";
- };
-
- i2c10: i2c at a88000 {
- compatible = "qcom,geni-i2c";
- reg = <0xa88000 0x4000>;
- clock-names = "se";
- clocks = <&gcc 91>;
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&qup_i2c10_default>;
- pinctrl-1 = <&qup_i2c10_sleep>;
- interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
- #address-cells = <1>;
- #size-cells = <0>;
- status = "disabled";
- };
- };
};
};
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI
From: Sergey Suloev @ 2018-05-04 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <afc78821-2d08-3f4f-d008-5b2d216e96c0@micronovasrl.com>
Hi, Giulio,
On 05/05/2018 12:52 AM, Giulio Benetti wrote:
> Hi Maxime!
>
> Il 04/05/2018 10:06, Maxime Ripard ha scritto:
>> Hi,
>>
>> On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote:
>>>>> You don't have to handcode the fragments anymore with the new syntax,
>>>>> and U-Boot makes it really trivial to use if you use the FIT image
>>>>> format to have multiple overlays bundled in the same image. You can
>>>>> choose to apply them dynamically, for example based on an EEPROM or
>>>>> some other metric to see which combination you have.
>>>>
>>>> Ah, this is interesting. I'm going to experiment with that.
>>>>
>>>
>>> I'm struggling against this, I don't really know how to proceed,
>>> except keeping monolithic dts files including other dtsi files.
>>>
>>> About dt-overlays I've tried to look around lot of time,
>>> but the only thing I've found is this:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays
>>>
>>>
>>> where they use .dtso tagging them as "/plugin/;"
>>> and compile all .dtso found in dts folder.
>>> Then they obtain .dtbo files that should be the dt-overlays we have
>>> spoken
>>> about right?
>>
>> Yes. You don't have to do that though, you can just rely on dtc to
>> compile them, outside of the linux build system.
>>
>>> What I can't understand is if there's a real standard at this time to
>>> follow, because on renesas-driver they use their way to handle all
>>> .dtso
>>> files, but on mainline there seems to be nothing about that.
>>
>> I'm not sure what you mean here. It's just fragments of device tree,
>> that have to be compiled using dtc, that's it. You can use the Linux
>> build system infrastructure to do that, or you can build your own
>> simpler one. That's really up to you. See for example
>> https://github.com/NextThingCo/CHIP-dt-overlays/blob/master/Makefile
>>
>> (even though the overlays themselves use the legacy syntax and
>> shouldn't really be used an examples)
>
> Everything works now!
> Thank you very much!
> I've setted up a Repo on Github to give an example on how make it work
> with no pain:
> https://github.com/micronovasrl/linova-dtoverlays
>
> At the moment it's a mess all around, but it's working and give an
> idea on how to make it work. Though I'm going to clean it up well as a
> base for linova dtoverlays.
>
> Ah, btw, can you confirm me that base dts file must be compiled
> outside kernel with:
> dtc -@ ....
> Otherwise as in-tree dts with make dtbs "-@" argument is not passed.
> Right?
>
> Thank you a lot for your help and time again!
>
> Best regards!
>
I'd highly recommend you to look at Armbian overlay support: it is easy
and elegant.
https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/add-overlay-compilation-support.patch
https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/add-sunxi-overlays.patch
Sergey
^ 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