* Re: [PATCH 1/2] arm64: dts: Add a device tree for the Librem5 phone
From: Martin Kepplinger @ 2020-05-25 8:47 UTC (permalink / raw)
To: robh, kernel, shawnguo, s.hauer, kernel, festevam, linux-imx,
mchehab, Anson.Huang, agx, angus
Cc: devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20200514155737.12160-1-martin.kepplinger@puri.sm>
On 14.05.20 17:57, Martin Kepplinger wrote:
> From: "Angus Ainslie (Purism)" <angus@akkea.ca>
>
> Add a devicetree description for the Librem 5 phone. The early batches
> that have been sold are supported as well as the mass-produced device
> available later this year, see https://puri.sm/products/librem-5/
>
> This boots to a working console with working WWAN modem, wifi usdhc,
> IMU sensor device, proximity sensor, haptic motor, gpio keys, GNSS and LEDs.
>
> Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
> Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> .../boot/dts/freescale/imx8mq-librem5.dts | 1174 +++++++++++++++++
> 2 files changed, 1175 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-librem5.dts
>
hi,
I highly appreciate it in case you can take time to review. It's not the
smallest board, but this "base" support isn't huge either. For
devicetree people this is certainly easy to read and I'll be happy for
any opinions, objections or Acks you might have.
thanks,
martin
_______________________________________________
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 1/5] net: macb: fix wakeup test in runtime suspend/resume routines
From: Russell King - ARM Linux admin @ 2020-05-25 8:47 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Alexandre Belloni, f.fainelli, antoine.tenart, netdev,
linux-kernel, Claudiu Beznea, harini.katakam, Jakub Kicinski,
David S. Miller, linux-arm-kernel
In-Reply-To: <e43e7ed6-c78a-7995-3f46-0bdbf32f361c@microchip.com>
On Mon, May 25, 2020 at 10:18:16AM +0200, Nicolas Ferre wrote:
> On 07/05/2020 at 12:03, Nicolas Ferre wrote:
> > On 06/05/2020 at 22:18, Jakub Kicinski wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > >
> > > On Wed, 6 May 2020 13:37:37 +0200 nicolas.ferre@microchip.com wrote:
> > > > From: Nicolas Ferre <nicolas.ferre@microchip.com>
> > > >
> > > > Use the proper struct device pointer to check if the wakeup flag
> > > > and wakeup source are positioned.
> > > > Use the one passed by function call which is equivalent to
> > > > &bp->dev->dev.parent.
> > > >
> > > > It's preventing the trigger of a spurious interrupt in case the
> > > > Wake-on-Lan feature is used.
> > > >
> > > > Fixes: bc1109d04c39 ("net: macb: Add pm runtime support")
> > >
> > > Fixes tag: Fixes: bc1109d04c39 ("net: macb: Add pm runtime support")
> > > Has these problem(s):
> > > - Target SHA1 does not exist
> >
> > Indeed, it's:
> > Fixes: d54f89af6cc4 ("net: macb: Add pm runtime support")
> >
> > David: do I have to respin or you can modify it?
>
> David, all, I'm about to resend this series (alternative to "ping"),
> however:
>
> 1/ Now that it's late in the cycle, I'd like that you tell me if I rebase on
> net-next because it isn't not sensible to queue such (non urgeent) changes
> at rc7
>
> 2/ I didn't get answers from Russell and can't tell if there's a better way
> of handling underlying phylink error of phylink_ethtool_set_wol() in patch
> 3/5
I think you could have answered your own questions there, but I seemed
easier to send an email. I've just read the code, typed out an
appropriate description of the code's behaviour, and then derived the
answer to your questions without anything else.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps 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: [PATCH v4 3/5] net: macb: fix macb_get/set_wol() when moving to phylink
From: Russell King - ARM Linux admin @ 2020-05-25 8:41 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Alexandre Belloni, f.fainelli, antoine.tenart, netdev,
linux-kernel, David S. Miller, harini.katakam, Claudiu Beznea,
linux-arm-kernel
In-Reply-To: <c0bc2167-e49e-1026-94e3-cb5931755389@microchip.com>
On Wed, May 13, 2020 at 04:16:04PM +0200, Nicolas Ferre wrote:
> Russell,
>
> Thanks for the feedback.
>
> On 13/05/2020 at 15:05, Russell King - ARM Linux admin wrote:
> > On Wed, May 06, 2020 at 01:37:39PM +0200, nicolas.ferre@microchip.com wrote:
> > > From: Nicolas Ferre <nicolas.ferre@microchip.com>
> > >
> > > Keep previous function goals and integrate phylink actions to them.
> > >
> > > phylink_ethtool_get_wol() is not enough to figure out if Ethernet driver
> > > supports Wake-on-Lan.
> > > Initialization of "supported" and "wolopts" members is done in phylink
> > > function, no need to keep them in calling function.
> > >
> > > phylink_ethtool_set_wol() return value is not enough to determine
> > > if WoL is enabled for the calling Ethernet driver. Call it first
> > > but don't rely on its return value as most of simple PHY drivers
> > > don't implement a set_wol() function.
> > >
> > > Fixes: 7897b071ac3b ("net: macb: convert to phylink")
> > > Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
> > > Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> > > Cc: Claudiu Beznea <claudiu.beznea@microchip.com>
> > > Cc: Harini Katakam <harini.katakam@xilinx.com>
> > > Cc: Antoine Tenart <antoine.tenart@bootlin.com>
> > > ---
> > > drivers/net/ethernet/cadence/macb_main.c | 18 ++++++++++--------
> > > 1 file changed, 10 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> > > index 53e81ab048ae..24c044dc7fa0 100644
> > > --- a/drivers/net/ethernet/cadence/macb_main.c
> > > +++ b/drivers/net/ethernet/cadence/macb_main.c
> > > @@ -2817,21 +2817,23 @@ static void macb_get_wol(struct net_device *netdev, struct ethtool_wolinfo *wol)
> > > {
> > > struct macb *bp = netdev_priv(netdev);
> > >
> > > - wol->supported = 0;
> > > - wol->wolopts = 0;
> > > -
> > > - if (bp->wol & MACB_WOL_HAS_MAGIC_PACKET)
> > > + if (bp->wol & MACB_WOL_HAS_MAGIC_PACKET) {
> > > phylink_ethtool_get_wol(bp->phylink, wol);
> > > + wol->supported |= WAKE_MAGIC;
> > > +
> > > + if (bp->wol & MACB_WOL_ENABLED)
> > > + wol->wolopts |= WAKE_MAGIC;
> > > + }
> > > }
> > >
> > > static int macb_set_wol(struct net_device *netdev, struct ethtool_wolinfo *wol)
> > > {
> > > struct macb *bp = netdev_priv(netdev);
> > > - int ret;
> > >
> > > - ret = phylink_ethtool_set_wol(bp->phylink, wol);
> > > - if (!ret)
> > > - return 0;
> > > + /* Pass the order to phylink layer.
> > > + * Don't test return value as set_wol() is often not supported.
> > > + */
> > > + phylink_ethtool_set_wol(bp->phylink, wol);
> >
> > If this returns an error, does that mean WOL works or does it not?
>
> In my use case (simple phy: "Micrel KSZ8081"), if I have the error
> "-EOPNOTSUPP", it simply means that this phy driver doesn't have the
> set_wol() function. But on the MAC side, I can perfectly wake-up on WoL
> event as the phy acts as a pass-through.
>
> > Note that if set_wol() is not supported, this will return -EOPNOTSUPP.
> > What about other errors?
>
> True, I don't manage them. But for now this patch is a fix that only reverts
> to previous behavior. In other terms, it only fixes the regression.
>
> But can I make the difference, and how, between?
> 1/ the phy doesn't support WoL and could prevent the WoL to happen on the
> MAC
> 2/ the phy doesn't implement (yet) the set_wol() function, if MAC can
> manage, it's fine
I think you need to read and understand the code, but don't worry, I'll
do it for you. There are not that many implementations in phylib, so
it doesn't take long:
m88e1318_set_wol(), dp83867_set_wol(), dp83822_set_wol(),
at803x_set_wol(), lan88xx_set_wol(), and vsc85xx_wol_set().
For case 2, phylib returns -EOPNOTSUPP.
m88e1318_set_wol() returns zero on success, or propagates an error from
the MDIO bus accessors.
dp83867_set_wol() returns zero on success, or -EINVAL if the MAC address
is invalid. No bus errors are propagated.
dp83822_set_wol() is the same as dp83867_set_wol().
at803x_set_wol() returns zero on success, or -ENODEV if there is no
netdev attached (which means you shouldn't be calling this anyway),
-EINVAL if the MAC address is invalid, or sometimes propagates an
error from the MDIO bus accessors.
lan88xx_set_wol() always returns zero, but the function does nothing
other than saving the requested state, and uses that to avoid calling
genphy_suspend() for this PHY.
vsc85xx_wol_set() returns zero on success, or propagates an error from
the MDIO bus accessors.
So, what we can tell from the return code is:
- If it returned zero, the PHY likely supports and properly configured
WoL, and you may not need to configure the MAC (depends on whether
the PHY can wake the system up on its own.)
- If it returns -EOPNOTSUPP, there is no support for WoL at the PHY,
and you need to program your MAC - assuming that the PHY is going to
stay alive.
- If it returns some other error code, there was a failure of some sort
to configure the PHY for WoL, which probably means the PHY is not
responding, and probably means the system isn't going to be capable
of waking up through this PHY.
For case 1, there is no code path that detects whether the PHY concerned
supports WoL or doesn't - the code paths in each driver assume that if
the PHY supports WoL, then it supports WoL.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps 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: [PATCH] media: exynos4-is: Fix runtime PM imbalance in isp_video_open
From: Sylwester Nawrocki @ 2020-05-25 8:40 UTC (permalink / raw)
To: Dinghao Liu, kjlu
Cc: linux-samsung-soc, linux-kernel, Krzysztof Kozlowski,
Kyungmin Park, Kukjin Kim, Sylwester Nawrocki,
Mauro Carvalho Chehab, linux-arm-kernel, linux-media
In-Reply-To: <20200524033404.23227-1-dinghao.liu@zju.edu.cn>
On 5/24/20 05:34, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> when it returns an error code. Thus a pairing decrement is needed on
> the error handling path to keep the counter balanced.
>
> Signed-off-by: Dinghao Liu<dinghao.liu@zju.edu.cn>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
_______________________________________________
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 09/13] soc: mediatek: cmdq: add write_s value function
From: Matthias Brugger @ 2020-05-25 8:39 UTC (permalink / raw)
To: Dennis-YC Hsieh
Cc: Mark Rutland, devicetree, Philipp Zabel, wsd_upstream,
David Airlie, Jassi Brar, linux-kernel, dri-devel, HS Liao,
Rob Herring, linux-mediatek, Houlong Wei, Daniel Vetter, CK Hu,
Bibby Hsieh, linux-arm-kernel
In-Reply-To: <1590373621.31522.7.camel@mtkswgap22>
On 25/05/2020 04:27, Dennis-YC Hsieh wrote:
>
> On Sun, 2020-05-24 at 20:13 +0200, Matthias Brugger wrote:
>>
>> On 24/05/2020 19:31, Dennis-YC Hsieh wrote:
>>> Hi Matthias,
>>>
>>> Thanks for your comment.
>>>
>>> On Sat, 2020-05-16 at 20:20 +0200, Matthias Brugger wrote:
>>>>
>>>> On 08/03/2020 11:52, Dennis YC Hsieh wrote:
>>>>> add write_s function in cmdq helper functions which
>>>>> writes a constant value to address with large dma
>>>>> access support.
>>>>>
>>>>> Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
>>>>> Reviewed-by: CK Hu <ck.hu@mediatek.com>
>>>>> ---
>>>>> drivers/soc/mediatek/mtk-cmdq-helper.c | 26 ++++++++++++++++++++++++++
>>>>> include/linux/soc/mediatek/mtk-cmdq.h | 14 ++++++++++++++
>>>>> 2 files changed, 40 insertions(+)
>>>>>
>>>>> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>>>> index 03c129230cd7..a9ebbabb7439 100644
>>>>> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
>>>>> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>>>> @@ -269,6 +269,32 @@ int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
>>>>> }
>>>>> EXPORT_SYMBOL(cmdq_pkt_write_s);
>>>>>
>>>>> +int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
>>>>> + u16 addr_low, u32 value, u32 mask)
>>>>> +{
>>>>> + struct cmdq_instruction inst = { {0} };
>>>>> + int err;
>>>>> +
>>>>> + if (mask != U32_MAX) {
>>>>> + inst.op = CMDQ_CODE_MASK;
>>>>> + inst.mask = ~mask;
>>>>> + err = cmdq_pkt_append_command(pkt, inst);
>>>>> + if (err < 0)
>>>>> + return err;
>>>>> +
>>>>> + inst.op = CMDQ_CODE_WRITE_S_MASK;
>>>>> + } else {
>>>>> + inst.op = CMDQ_CODE_WRITE_S;
>>>>> + }
>>>>> +
>>>>> + inst.sop = high_addr_reg_idx;
>>>>
>>>> Writing u16 value in a 5 bit wide variable?
>>>
>>> We need only 5 bits in this case. I'll change high_addr_reg_idx
>>> parameter to u8.
>>>
>>
>> Ok, please make sure to mask the value, so that it's explicit in the code that
>> we only use the lowest 5 bits of high_addr_reg_idx.
>
> Is it necessary to mask the value?
> Since sop already defined as "u8 sop:5;", I thought it is explicit that
> only use 5 bits and compiler should do the rest jobs.
Yes but it makes the code more explicit if we have a
inst.sop = high_addr_reg_idx & 0x1f;
What do you think?
Regards,
Matthias
>
>
> Regards,
> Dennis
>
>>
>> Regards,
>> Matthias
>>
>>>>
>>>>> + inst.offset = addr_low;
>>>>> + inst.value = value;
>>>>> +
>>>>> + return cmdq_pkt_append_command(pkt, inst);
>>>>> +}
>>>>> +EXPORT_SYMBOL(cmdq_pkt_write_s_value);
>>>>> +
>>>>> int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
>>>>> {
>>>>> struct cmdq_instruction inst = { {0} };
>>>>> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
>>>>> index 01b4184af310..fec292aac83c 100644
>>>>> --- a/include/linux/soc/mediatek/mtk-cmdq.h
>>>>> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
>>>>> @@ -135,6 +135,20 @@ int cmdq_pkt_read_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx, u16 addr_low,
>>>>> int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
>>>>> u16 addr_low, u16 src_reg_idx, u32 mask);
>>>>>
>>>>> +/**
>>>>> + * cmdq_pkt_write_s_value() - append write_s command with mask to the CMDQ
>>>>> + * packet which write value to a physical address
>>>>> + * @pkt: the CMDQ packet
>>>>> + * @high_addr_reg_idx: internal regisger ID which contains high address of pa
>>>>
>>>> register
>>>
>>> will fix
>>>
>>>
>>> Regards,
>>> Dennis
>>>
>>>>
>>>>> + * @addr_low: low address of pa
>>>>> + * @value: the specified target value
>>>>> + * @mask: the specified target mask
>>>>> + *
>>>>> + * Return: 0 for success; else the error code is returned
>>>>> + */
>>>>> +int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
>>>>> + u16 addr_low, u32 value, u32 mask);
>>>>> +
>>>>> /**
>>>>> * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
>>>>> * @pkt: the CMDQ packet
>>>>>
>>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: next/master bisection: baseline.login on meson-sm1-sei610
From: Guillaume Tucker @ 2020-05-25 8:39 UTC (permalink / raw)
To: Felipe Balbi, Neil Armstrong, Martin Blumenstingl
Cc: kernelci-results, Kevin Hilman, linux-usb, linux-kernel,
linux-next, Greg Kroah-Hartman, linux-amlogic, linux-arm-kernel
In-Reply-To: <5ec9617c.1c69fb81.b979a.bf47@mx.google.com>
Please see the bisection report below about a kernel Oops.
Reports aren't automatically sent to the public while we're
trialing new bisection features on kernelci.org but this one
looks valid.
Guillaume
On 23/05/2020 18:46, kernelci.org bot wrote:
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This automated bisection report was sent to you on the basis *
> * that you may be involved with the breaking commit it has *
> * found. No manual investigation has been done to verify it, *
> * and the root cause of the problem may be somewhere else. *
> * *
> * If you do send a fix, please include this trailer: *
> * Reported-by: "kernelci.org bot" <bot@kernelci.org> *
> * *
> * Hope this helps! *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
> next/master bisection: baseline.login on meson-sm1-sei610
>
> Summary:
> Start: c11d28ab4a691 Add linux-next specific files for 20200522
> Plain log: https://storage.kernelci.org/next/master/next-20200522/arm64/defconfig/gcc-8/lab-baylibre/baseline-meson-sm1-sei610.txt
> HTML log: https://storage.kernelci.org/next/master/next-20200522/arm64/defconfig/gcc-8/lab-baylibre/baseline-meson-sm1-sei610.html
> Result: 013af227f58a9 usb: dwc3: meson-g12a: handle the phy and glue registers separately
>
> Checks:
> revert: PASS
> verify: PASS
>
> Parameters:
> Tree: next
> URL: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> Branch: master
> Target: meson-sm1-sei610
> CPU arch: arm64
> Lab: lab-baylibre
> Compiler: gcc-8
> Config: defconfig
> Test case: baseline.login
>
> Breaking commit found:
>
> -------------------------------------------------------------------------------
> commit 013af227f58a97ffc61b99301f8f4448dc7e7f55
> Author: Neil Armstrong <narmstrong@baylibre.com>
> Date: Thu Mar 26 14:44:55 2020 +0100
>
> usb: dwc3: meson-g12a: handle the phy and glue registers separately
>
> On the Amlogic GXL/GXM SoCs, only the USB control registers are available,
> the PHY mode being handled in the PHY registers.
>
> Thus, handle the PHY mode registers in separate regmaps and prepare
> support for Amlogic GXL/GXM SoCs by moving the regmap setup in a callback
> set in the SoC match data.
>
> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Felipe Balbi <balbi@kernel.org>
>
> diff --git a/drivers/usb/dwc3/dwc3-meson-g12a.c b/drivers/usb/dwc3/dwc3-meson-g12a.c
> index f49c9e2665376..d7eff4d7c5fe6 100644
> --- a/drivers/usb/dwc3/dwc3-meson-g12a.c
> +++ b/drivers/usb/dwc3/dwc3-meson-g12a.c
> @@ -30,7 +30,7 @@
> #include <linux/usb/role.h>
> #include <linux/regulator/consumer.h>
>
> -/* USB2 Ports Control Registers */
> +/* USB2 Ports Control Registers, offsets are per-port */
>
> #define U2P_REG_SIZE 0x20
>
> @@ -50,14 +50,16 @@
>
> /* USB Glue Control Registers */
>
> -#define USB_R0 0x80
> +#define G12A_GLUE_OFFSET 0x80
> +
> +#define USB_R0 0x00
> #define USB_R0_P30_LANE0_TX2RX_LOOPBACK BIT(17)
> #define USB_R0_P30_LANE0_EXT_PCLK_REQ BIT(18)
> #define USB_R0_P30_PCS_RX_LOS_MASK_VAL_MASK GENMASK(28, 19)
> #define USB_R0_U2D_SS_SCALEDOWN_MODE_MASK GENMASK(30, 29)
> #define USB_R0_U2D_ACT BIT(31)
>
> -#define USB_R1 0x84
> +#define USB_R1 0x04
> #define USB_R1_U3H_BIGENDIAN_GS BIT(0)
> #define USB_R1_U3H_PME_ENABLE BIT(1)
> #define USB_R1_U3H_HUB_PORT_OVERCURRENT_MASK GENMASK(4, 2)
> @@ -69,23 +71,23 @@
> #define USB_R1_U3H_FLADJ_30MHZ_REG_MASK GENMASK(24, 19)
> #define USB_R1_P30_PCS_TX_SWING_FULL_MASK GENMASK(31, 25)
>
> -#define USB_R2 0x88
> +#define USB_R2 0x08
> #define USB_R2_P30_PCS_TX_DEEMPH_3P5DB_MASK GENMASK(25, 20)
> #define USB_R2_P30_PCS_TX_DEEMPH_6DB_MASK GENMASK(31, 26)
>
> -#define USB_R3 0x8c
> +#define USB_R3 0x0c
> #define USB_R3_P30_SSC_ENABLE BIT(0)
> #define USB_R3_P30_SSC_RANGE_MASK GENMASK(3, 1)
> #define USB_R3_P30_SSC_REF_CLK_SEL_MASK GENMASK(12, 4)
> #define USB_R3_P30_REF_SSP_EN BIT(13)
>
> -#define USB_R4 0x90
> +#define USB_R4 0x10
> #define USB_R4_P21_PORT_RESET_0 BIT(0)
> #define USB_R4_P21_SLEEP_M0 BIT(1)
> #define USB_R4_MEM_PD_MASK GENMASK(3, 2)
> #define USB_R4_P21_ONLY BIT(4)
>
> -#define USB_R5 0x94
> +#define USB_R5 0x14
> #define USB_R5_ID_DIG_SYNC BIT(0)
> #define USB_R5_ID_DIG_REG BIT(1)
> #define USB_R5_ID_DIG_CFG_MASK GENMASK(3, 2)
> @@ -125,20 +127,27 @@ static const char *meson_a1_phy_names[] = {
> "usb2-phy0", "usb2-phy1"
> };
>
> +struct dwc3_meson_g12a;
> +
> struct dwc3_meson_g12a_drvdata {
> bool otg_switch_supported;
> struct clk_bulk_data *clks;
> int num_clks;
> const char **phy_names;
> int num_phys;
> + int (*setup_regmaps)(struct dwc3_meson_g12a *priv, void __iomem *base);
> };
>
> +static int dwc3_meson_g12a_setup_regmaps(struct dwc3_meson_g12a *priv,
> + void __iomem *base);
> +
> static struct dwc3_meson_g12a_drvdata g12a_drvdata = {
> .otg_switch_supported = true,
> .clks = meson_g12a_clocks,
> .num_clks = ARRAY_SIZE(meson_g12a_clocks),
> .phy_names = meson_g12a_phy_names,
> .num_phys = ARRAY_SIZE(meson_g12a_phy_names),
> + .setup_regmaps = dwc3_meson_g12a_setup_regmaps,
> };
>
> static struct dwc3_meson_g12a_drvdata a1_drvdata = {
> @@ -147,11 +156,13 @@ static struct dwc3_meson_g12a_drvdata a1_drvdata = {
> .num_clks = ARRAY_SIZE(meson_a1_clocks),
> .phy_names = meson_a1_phy_names,
> .num_phys = ARRAY_SIZE(meson_a1_phy_names),
> + .setup_regmaps = dwc3_meson_g12a_setup_regmaps,
> };
>
> struct dwc3_meson_g12a {
> struct device *dev;
> - struct regmap *regmap;
> + struct regmap *u2p_regmap[PHY_COUNT];
> + struct regmap *usb_glue_regmap;
> struct reset_control *reset;
> struct phy *phys[PHY_COUNT];
> enum usb_dr_mode otg_mode;
> @@ -168,11 +179,11 @@ static void dwc3_meson_g12a_usb2_set_mode(struct dwc3_meson_g12a *priv,
> int i, enum phy_mode mode)
> {
> if (mode == PHY_MODE_USB_HOST)
> - regmap_update_bits(priv->regmap, U2P_R0 + (U2P_REG_SIZE * i),
> + regmap_update_bits(priv->u2p_regmap[i], U2P_R0,
> U2P_R0_HOST_DEVICE,
> U2P_R0_HOST_DEVICE);
> else
> - regmap_update_bits(priv->regmap, U2P_R0 + (U2P_REG_SIZE * i),
> + regmap_update_bits(priv->u2p_regmap[i], U2P_R0,
> U2P_R0_HOST_DEVICE, 0);
> }
>
> @@ -192,13 +203,12 @@ static int dwc3_meson_g12a_usb2_init(struct dwc3_meson_g12a *priv)
> if (!strstr(priv->drvdata->phy_names[i], "usb2"))
> continue;
>
> - regmap_update_bits(priv->regmap, U2P_R0 + (U2P_REG_SIZE * i),
> + regmap_update_bits(priv->u2p_regmap[i], U2P_R0,
> U2P_R0_POWER_ON_RESET,
> U2P_R0_POWER_ON_RESET);
>
> if (priv->drvdata->otg_switch_supported && i == USB2_OTG_PHY) {
> - regmap_update_bits(priv->regmap,
> - U2P_R0 + (U2P_REG_SIZE * i),
> + regmap_update_bits(priv->u2p_regmap[i], U2P_R0,
> U2P_R0_ID_PULLUP | U2P_R0_DRV_VBUS,
> U2P_R0_ID_PULLUP | U2P_R0_DRV_VBUS);
>
> @@ -208,7 +218,7 @@ static int dwc3_meson_g12a_usb2_init(struct dwc3_meson_g12a *priv)
> dwc3_meson_g12a_usb2_set_mode(priv, i,
> PHY_MODE_USB_HOST);
>
> - regmap_update_bits(priv->regmap, U2P_R0 + (U2P_REG_SIZE * i),
> + regmap_update_bits(priv->u2p_regmap[i], U2P_R0,
> U2P_R0_POWER_ON_RESET, 0);
> }
>
> @@ -217,7 +227,7 @@ static int dwc3_meson_g12a_usb2_init(struct dwc3_meson_g12a *priv)
>
> static void dwc3_meson_g12a_usb3_init(struct dwc3_meson_g12a *priv)
> {
> - regmap_update_bits(priv->regmap, USB_R3,
> + regmap_update_bits(priv->usb_glue_regmap, USB_R3,
> USB_R3_P30_SSC_RANGE_MASK |
> USB_R3_P30_REF_SSP_EN,
> USB_R3_P30_SSC_ENABLE |
> @@ -225,21 +235,21 @@ static void dwc3_meson_g12a_usb3_init(struct dwc3_meson_g12a *priv)
> USB_R3_P30_REF_SSP_EN);
> udelay(2);
>
> - regmap_update_bits(priv->regmap, USB_R2,
> + regmap_update_bits(priv->usb_glue_regmap, USB_R2,
> USB_R2_P30_PCS_TX_DEEMPH_3P5DB_MASK,
> FIELD_PREP(USB_R2_P30_PCS_TX_DEEMPH_3P5DB_MASK, 0x15));
>
> - regmap_update_bits(priv->regmap, USB_R2,
> + regmap_update_bits(priv->usb_glue_regmap, USB_R2,
> USB_R2_P30_PCS_TX_DEEMPH_6DB_MASK,
> FIELD_PREP(USB_R2_P30_PCS_TX_DEEMPH_6DB_MASK, 0x20));
>
> udelay(2);
>
> - regmap_update_bits(priv->regmap, USB_R1,
> + regmap_update_bits(priv->usb_glue_regmap, USB_R1,
> USB_R1_U3H_HOST_PORT_POWER_CONTROL_PRESENT,
> USB_R1_U3H_HOST_PORT_POWER_CONTROL_PRESENT);
>
> - regmap_update_bits(priv->regmap, USB_R1,
> + regmap_update_bits(priv->usb_glue_regmap, USB_R1,
> USB_R1_P30_PCS_TX_SWING_FULL_MASK,
> FIELD_PREP(USB_R1_P30_PCS_TX_SWING_FULL_MASK, 127));
> }
> @@ -247,16 +257,16 @@ static void dwc3_meson_g12a_usb3_init(struct dwc3_meson_g12a *priv)
> static void dwc3_meson_g12a_usb_otg_apply_mode(struct dwc3_meson_g12a *priv)
> {
> if (priv->otg_phy_mode == PHY_MODE_USB_DEVICE) {
> - regmap_update_bits(priv->regmap, USB_R0,
> + regmap_update_bits(priv->usb_glue_regmap, USB_R0,
> USB_R0_U2D_ACT, USB_R0_U2D_ACT);
> - regmap_update_bits(priv->regmap, USB_R0,
> + regmap_update_bits(priv->usb_glue_regmap, USB_R0,
> USB_R0_U2D_SS_SCALEDOWN_MODE_MASK, 0);
> - regmap_update_bits(priv->regmap, USB_R4,
> + regmap_update_bits(priv->usb_glue_regmap, USB_R4,
> USB_R4_P21_SLEEP_M0, USB_R4_P21_SLEEP_M0);
> } else {
> - regmap_update_bits(priv->regmap, USB_R0,
> + regmap_update_bits(priv->usb_glue_regmap, USB_R0,
> USB_R0_U2D_ACT, 0);
> - regmap_update_bits(priv->regmap, USB_R4,
> + regmap_update_bits(priv->usb_glue_regmap, USB_R4,
> USB_R4_P21_SLEEP_M0, 0);
> }
> }
> @@ -269,17 +279,17 @@ static int dwc3_meson_g12a_usb_init(struct dwc3_meson_g12a *priv)
> if (ret)
> return ret;
>
> - regmap_update_bits(priv->regmap, USB_R1,
> + regmap_update_bits(priv->usb_glue_regmap, USB_R1,
> USB_R1_U3H_FLADJ_30MHZ_REG_MASK,
> FIELD_PREP(USB_R1_U3H_FLADJ_30MHZ_REG_MASK, 0x20));
>
> - regmap_update_bits(priv->regmap, USB_R5,
> + regmap_update_bits(priv->usb_glue_regmap, USB_R5,
> USB_R5_ID_DIG_EN_0,
> USB_R5_ID_DIG_EN_0);
> - regmap_update_bits(priv->regmap, USB_R5,
> + regmap_update_bits(priv->usb_glue_regmap, USB_R5,
> USB_R5_ID_DIG_EN_1,
> USB_R5_ID_DIG_EN_1);
> - regmap_update_bits(priv->regmap, USB_R5,
> + regmap_update_bits(priv->usb_glue_regmap, USB_R5,
> USB_R5_ID_DIG_TH_MASK,
> FIELD_PREP(USB_R5_ID_DIG_TH_MASK, 0xff));
>
> @@ -292,7 +302,8 @@ static int dwc3_meson_g12a_usb_init(struct dwc3_meson_g12a *priv)
> return 0;
> }
>
> -static const struct regmap_config phy_meson_g12a_usb3_regmap_conf = {
> +static const struct regmap_config phy_meson_g12a_usb_glue_regmap_conf = {
> + .name = "usb-glue",
> .reg_bits = 8,
> .val_bits = 32,
> .reg_stride = 4,
> @@ -329,7 +340,7 @@ static enum phy_mode dwc3_meson_g12a_get_id(struct dwc3_meson_g12a *priv)
> {
> u32 reg;
>
> - regmap_read(priv->regmap, USB_R5, ®);
> + regmap_read(priv->usb_glue_regmap, USB_R5, ®);
>
> if (reg & (USB_R5_ID_DIG_SYNC | USB_R5_ID_DIG_REG))
> return PHY_MODE_USB_DEVICE;
> @@ -405,7 +416,8 @@ static irqreturn_t dwc3_meson_g12a_irq_thread(int irq, void *data)
> dev_warn(priv->dev, "Failed to switch OTG mode\n");
> }
>
> - regmap_update_bits(priv->regmap, USB_R5, USB_R5_ID_DIG_IRQ, 0);
> + regmap_update_bits(priv->usb_glue_regmap, USB_R5,
> + USB_R5_ID_DIG_IRQ, 0);
>
> return IRQ_HANDLED;
> }
> @@ -440,7 +452,7 @@ static int dwc3_meson_g12a_otg_init(struct platform_device *pdev,
>
> if (priv->otg_mode == USB_DR_MODE_OTG) {
> /* Ack irq before registering */
> - regmap_update_bits(priv->regmap, USB_R5,
> + regmap_update_bits(priv->usb_glue_regmap, USB_R5,
> USB_R5_ID_DIG_IRQ, 0);
>
> irq = platform_get_irq(pdev, 0);
> @@ -476,6 +488,41 @@ static int dwc3_meson_g12a_otg_init(struct platform_device *pdev,
> return 0;
> }
>
> +static int dwc3_meson_g12a_setup_regmaps(struct dwc3_meson_g12a *priv,
> + void __iomem *base)
> +{
> + int i;
> +
> + priv->usb_glue_regmap = devm_regmap_init_mmio(priv->dev,
> + base + G12A_GLUE_OFFSET,
> + &phy_meson_g12a_usb_glue_regmap_conf);
> + if (IS_ERR(priv->usb_glue_regmap))
> + return PTR_ERR(priv->usb_glue_regmap);
> +
> + /* Create a regmap for each USB2 PHY control register set */
> + for (i = 0; i < priv->usb2_ports; i++) {
> + struct regmap_config u2p_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .max_register = U2P_R1,
> + };
> +
> + u2p_regmap_config.name = devm_kasprintf(priv->dev, GFP_KERNEL,
> + "u2p-%d", i);
> + if (!u2p_regmap_config.name)
> + return -ENOMEM;
> +
> + priv->u2p_regmap[i] = devm_regmap_init_mmio(priv->dev,
> + base + (i * U2P_REG_SIZE),
> + &u2p_regmap_config);
> + if (IS_ERR(priv->u2p_regmap[i]))
> + return PTR_ERR(priv->u2p_regmap[i]);
> + }
> +
> + return 0;
> +}
> +
> static int dwc3_meson_g12a_probe(struct platform_device *pdev)
> {
> struct dwc3_meson_g12a *priv;
> @@ -492,10 +539,12 @@ static int dwc3_meson_g12a_probe(struct platform_device *pdev)
> if (IS_ERR(base))
> return PTR_ERR(base);
>
> - priv->regmap = devm_regmap_init_mmio(dev, base,
> - &phy_meson_g12a_usb3_regmap_conf);
> - if (IS_ERR(priv->regmap))
> - return PTR_ERR(priv->regmap);
> + priv->drvdata = of_device_get_match_data(&pdev->dev);
> +
> + priv->dev = dev;
> + ret = priv->drvdata->setup_regmaps(priv, base);
> + if (ret)
> + return ret;
>
> priv->vbus = devm_regulator_get_optional(dev, "vbus");
> if (IS_ERR(priv->vbus)) {
> @@ -504,8 +553,6 @@ static int dwc3_meson_g12a_probe(struct platform_device *pdev)
> priv->vbus = NULL;
> }
>
> - priv->drvdata = of_device_get_match_data(&pdev->dev);
> -
> ret = devm_clk_bulk_get(dev,
> priv->drvdata->num_clks,
> priv->drvdata->clks);
> @@ -518,7 +565,6 @@ static int dwc3_meson_g12a_probe(struct platform_device *pdev)
> return ret;
>
> platform_set_drvdata(pdev, priv);
> - priv->dev = dev;
>
> priv->reset = devm_reset_control_get(dev, NULL);
> if (IS_ERR(priv->reset)) {
> -------------------------------------------------------------------------------
>
>
> Git bisection log:
>
> -------------------------------------------------------------------------------
> git bisect start
> # good: [051143e1602d90ea71887d92363edd539d411de5] Merge tag 'apparmor-pr-2020-05-21' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor
> git bisect good 051143e1602d90ea71887d92363edd539d411de5
> # bad: [c11d28ab4a691736e30b49813fb801847bd44e83] Add linux-next specific files for 20200522
> git bisect bad c11d28ab4a691736e30b49813fb801847bd44e83
> # good: [df7926cf2d7421586d4a2e2641206a59303b6ed0] Merge remote-tracking branch 'crypto/master'
> git bisect good df7926cf2d7421586d4a2e2641206a59303b6ed0
> # good: [22f04c4413814d3b42424eb7b088022ba2ed53ee] next-20200518/tip
> git bisect good 22f04c4413814d3b42424eb7b088022ba2ed53ee
> # bad: [82ca9f0ddfe370eae76d35e1972ac8267e4808ed] Merge remote-tracking branch 'staging/staging-next'
> git bisect bad 82ca9f0ddfe370eae76d35e1972ac8267e4808ed
> # bad: [1237e48654fb052ad365f22bf5b1fdc21d8fc2bd] Merge remote-tracking branch 'phy-next/next'
> git bisect bad 1237e48654fb052ad365f22bf5b1fdc21d8fc2bd
> # good: [4aee12750ad1a94d0a9f029ab2b3232538c81769] Merge remote-tracking branch 'kvm/linux-next'
> git bisect good 4aee12750ad1a94d0a9f029ab2b3232538c81769
> # good: [8579b345bb924fecc6b8c75e55aee8569d2b5eae] Merge remote-tracking branch 'usb/usb-next'
> git bisect good 8579b345bb924fecc6b8c75e55aee8569d2b5eae
> # bad: [ec948d2c4511002b8511451e8f318603453eb0b8] usb: dwc3: gadget: Handle XferComplete for streams
> git bisect bad ec948d2c4511002b8511451e8f318603453eb0b8
> # bad: [32e51c59a00c8cef62cb8e5b846dafb3d94d58ab] usb: cdns3: change dev_info to dev_dbg for debug message
> git bisect bad 32e51c59a00c8cef62cb8e5b846dafb3d94d58ab
> # good: [8f385b67555415cb01079a8ad3b1e16010c5005b] dt-bindings: usb: amlogic,meson-g12a-usb-ctrl: add the Amlogic GXL and GXM Families USB Glue Bindings
> git bisect good 8f385b67555415cb01079a8ad3b1e16010c5005b
> # bad: [9bc3395c24962e8c8e4f590ca2740c56e4a7a4fe] usb: dwc3: gadget: Store resource index of start cmd
> git bisect bad 9bc3395c24962e8c8e4f590ca2740c56e4a7a4fe
> # bad: [8f5bc1ec770c2bdc8c604ba4119a77d81d8f3529] usb: dwc3: meson-g12a: check return of dwc3_meson_g12a_usb_init
> git bisect bad 8f5bc1ec770c2bdc8c604ba4119a77d81d8f3529
> # bad: [013af227f58a97ffc61b99301f8f4448dc7e7f55] usb: dwc3: meson-g12a: handle the phy and glue registers separately
> git bisect bad 013af227f58a97ffc61b99301f8f4448dc7e7f55
> # good: [5174564cb9156a7c7b4d94a64c1cafdfd9a20403] usb: dwc3: meson-g12a: specify phy names in soc data
> git bisect good 5174564cb9156a7c7b4d94a64c1cafdfd9a20403
> # first bad commit: [013af227f58a97ffc61b99301f8f4448dc7e7f55] usb: dwc3: meson-g12a: handle the phy and glue registers separately
> -------------------------------------------------------------------------------
>
_______________________________________________
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 2/4] pinctrl: sunxi: add support for the Allwinner A100 pin controller
From: Maxime Ripard @ 2020-05-22 15:28 UTC (permalink / raw)
To: Frank Lee
Cc: devicetree, linux-gpio, sboyd, mturquette, linux-kernel,
linux-clk, tiny.windzz, wens, robh+dt, huangshuosheng, p.zabel,
linus.walleij, linux-arm-kernel
In-Reply-To: <20200522030743.10204-3-frank@allwinnertech.com>
[-- Attachment #1.1: Type: text/plain, Size: 35314 bytes --]
Hi,
On Fri, May 22, 2020 at 11:07:41AM +0800, Frank Lee wrote:
> This commit introduces support for the pin controller on A100.
>
> Signed-off-by: Frank Lee <frank@allwinnertech.com>
> ---
> drivers/pinctrl/sunxi/Kconfig | 10 +
> drivers/pinctrl/sunxi/Makefile | 2 +
> drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c | 105 +++
> drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c | 710 ++++++++++++++++++
This will need a DT binding too, and please make sure to run checkpatch with
--strict, you have a bunch of misaligned parenthesis.
> 4 files changed, 827 insertions(+)
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
>
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index f7aae200ee15..593293584ecc 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -94,6 +94,16 @@ config PINCTRL_SUN50I_A64_R
> default ARM64 && ARCH_SUNXI
> select PINCTRL_SUNXI
>
> +config PINCTRL_SUN50I_A100
> + bool "Support for the Allwinner A100 PIO"
> + default ARM64 && ARCH_SUNXI
> + select PINCTRL_SUNXI
> +
> +config PINCTRL_SUN50I_A100_R
> + bool "Support for the Allwinner A100 R-PIO"
> + default ARM64 && ARCH_SUNXI
> + select PINCTRL_SUNXI
> +
> config PINCTRL_SUN50I_H5
> bool "Support for the Allwinner H5 PIO"
> default ARM64 && ARCH_SUNXI
> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> index fafcdae8134f..8b7ff0dc3bdf 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -13,6 +13,8 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23_R) += pinctrl-sun8i-a23-r.o
> obj-$(CONFIG_PINCTRL_SUN8I_A33) += pinctrl-sun8i-a33.o
> obj-$(CONFIG_PINCTRL_SUN50I_A64) += pinctrl-sun50i-a64.o
> obj-$(CONFIG_PINCTRL_SUN50I_A64_R) += pinctrl-sun50i-a64-r.o
> +obj-$(CONFIG_PINCTRL_SUN50I_A100) += pinctrl-sun50i-a100.o
> +obj-$(CONFIG_PINCTRL_SUN50I_A100_R) += pinctrl-sun50i-a100-r.o
> obj-$(CONFIG_PINCTRL_SUN8I_A83T) += pinctrl-sun8i-a83t.o
> obj-$(CONFIG_PINCTRL_SUN8I_A83T_R) += pinctrl-sun8i-a83t-r.o
> obj-$(CONFIG_PINCTRL_SUN8I_H3) += pinctrl-sun8i-h3.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c
> new file mode 100644
> index 000000000000..d38d8770c9da
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c
> @@ -0,0 +1,105 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 Frank Lee <frank@allwinner.com>
> + *
> + * Based on:
> + * huangshuosheng <huangshuosheng@allwinnertech.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/pinctrl/pinctrl.h>
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin a100_r_pins[] = {
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_i2c0"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_i2c0"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_uart0"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_uart0"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_jtag"), /* MS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_jtag"), /* CK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_jtag"), /* DO */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_jtag"), /* DI */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_i2c1"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_i2c1"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_pwm"),
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 10)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_cpu"), /* CUR_W */
> + SUNXI_FUNCTION(0x3, "s_cir"), /* IN */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 11)),
> +};
> +
> +static const struct sunxi_pinctrl_desc a100_r_pinctrl_data = {
> + .pins = a100_r_pins,
> + .npins = ARRAY_SIZE(a100_r_pins),
> + .pin_base = PL_BASE,
> + .irq_banks = 1,
> +};
> +
> +static int a100_r_pinctrl_probe(struct platform_device *pdev)
> +{
> + return sunxi_pinctrl_init(pdev, &a100_r_pinctrl_data);
> +}
> +
> +static const struct of_device_id a100_r_pinctrl_match[] = {
> + { .compatible = "allwinner,sun50i-a100-r-pinctrl", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, a100_r_pinctrl_match);
> +
> +static struct platform_driver a100_r_pinctrl_driver = {
> + .probe = a100_r_pinctrl_probe,
> + .driver = {
> + .name = "sun50iw10p1-r-pinctrl",
> + .of_match_table = a100_r_pinctrl_match,
> + },
> +};
> +module_platform_driver(a100_r_pinctrl_driver);
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
> new file mode 100644
> index 000000000000..b9591009f0a4
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
> @@ -0,0 +1,710 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 Frank Lee <frank@allwinner.com>
> + *
> + * Based on:
> + * huangshuosheng <huangshuosheng@allwinnertech.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/pinctrl/pinctrl.h>
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin a100_pins[] = {
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* TX */
> + SUNXI_FUNCTION(0x3, "spi2"), /* CS */
> + SUNXI_FUNCTION(0x4, "jtag"), /* MS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* RX */
> + SUNXI_FUNCTION(0x3, "spi2"), /* CLK */
> + SUNXI_FUNCTION(0x4, "jtag"), /* CK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* RTS */
> + SUNXI_FUNCTION(0x3, "spi2"), /* MOSI */
> + SUNXI_FUNCTION(0x4, "jtag"), /* DO */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* CTS */
> + SUNXI_FUNCTION(0x3, "spi2"), /* MISO */
> + SUNXI_FUNCTION(0x4, "jtag"), /* DI */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c1"), /* SCK */
> + SUNXI_FUNCTION(0x3, "i2s0"), /* MCLK */
> + SUNXI_FUNCTION(0x4, "jtag"), /* MS_GPU */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c1"), /* SDA */
> + SUNXI_FUNCTION(0x3, "i2s0"), /* BCLK */
> + SUNXI_FUNCTION(0x4, "jtag"), /* CK_GPU */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s0"), /* LRCK */
> + SUNXI_FUNCTION(0x4, "jtag"), /* DO_GPU */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "spdif"), /* DIN */
> + SUNXI_FUNCTION(0x3, "i2s0"), /* DOUT0 */
> + SUNXI_FUNCTION(0x4, "i2s0"), /* DIN1 */
I guess the second one would be i2s1?
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "spdif"), /* DOUT */
> + SUNXI_FUNCTION(0x3, "i2s0"), /* DIN0 */
> + SUNXI_FUNCTION(0x4, "i2s0"), /* DOUT1 */
Ditto
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart0"), /* TX */
> + SUNXI_FUNCTION(0x3, "i2c0"), /* SCK */
> + SUNXI_FUNCTION(0x4, "jtag"), /* DI_GPU */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart0"), /* RX */
> + SUNXI_FUNCTION(0x3, "i2c0"), /* SDA */
> + SUNXI_FUNCTION(0x4, "pwm1"),
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 10)),
> + /* HOLE */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* WE */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* DS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* ALE */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* RST */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* CLE */
> + SUNXI_FUNCTION(0x4, "spi0"), /* MOSI */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* CE1 */
> + SUNXI_FUNCTION(0x4, "spi0"), /* CS0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* CE0 */
> + SUNXI_FUNCTION(0x4, "spi0"), /* MISO */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* RE */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* RB0 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* CMD */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* RB1 */
> + SUNXI_FUNCTION(0x4, "spi0"), /* CS1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ7 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ6 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D4 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 9)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ5 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 10)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ4 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D5 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 11)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQS */
> + SUNXI_FUNCTION(0x4, "spi0"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 12)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ3 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 13)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ2 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D6 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 14)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ1 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D2 */
> + SUNXI_FUNCTION(0x4, "spi0"), /* WP */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 15)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 16),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ0 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D7 */
> + SUNXI_FUNCTION(0x4, "spi0"), /* HOLD */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 16)),
> + /* HOLE */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D2 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* D0P */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DP0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D3 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* D0N */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DM0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D4 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* D1P */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DP1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D5 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* D1N */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DM1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D6 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* D2P */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* CKP */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D7 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* D2N */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* CKM */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D10 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* CKP */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DP2 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D11 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* CKN */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DM2 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D12 */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DP3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D13 */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DM3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 9)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D14 */
> + SUNXI_FUNCTION(0x4, "spi1"), /* CS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 10)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D15 */
> + SUNXI_FUNCTION(0x4, "spi1"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 11)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D18 */
> + SUNXI_FUNCTION(0x4, "spi1"), /* MOSI */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 12)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D19 */
> + SUNXI_FUNCTION(0x4, "spi1"), /* MISO */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 13)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 14),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D20 */
> + SUNXI_FUNCTION(0x4, "uart3"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 14)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 15),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D21 */
> + SUNXI_FUNCTION(0x4, "uart3"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 15)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 16),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D22 */
> + SUNXI_FUNCTION(0x4, "uart3"), /* RTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 16)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 17),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D23 */
> + SUNXI_FUNCTION(0x4, "uart3"), /* CTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 17)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 18),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* CLK */
> + SUNXI_FUNCTION(0x4, "uart4"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 18)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 19),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* DE */
> + SUNXI_FUNCTION(0x4, "uart4"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 19)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 20),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* HSYNC */
> + SUNXI_FUNCTION(0x3, "pwm2"),
> + SUNXI_FUNCTION(0x4, "uart4"), /* RTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 20)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 21),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* VSYNC */
> + SUNXI_FUNCTION(0x3, "pwm3"),
> + SUNXI_FUNCTION(0x4, "uart4"), /* CTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 21)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 22),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "pwm1"),
> + SUNXI_FUNCTION(0x4, "i2c0"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 22)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 23),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "pwm0"),
> + SUNXI_FUNCTION(0x4, "i2c0"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 23)),
> + /* HOLE */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* MCLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c2"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c2"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c3"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c3"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* MCLK */
> + SUNXI_FUNCTION(0x3, "pll"), /* LOCK_DBG */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* MCLK */
> + SUNXI_FUNCTION(0x5, "ledc"), /* LEDC */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "bist0"), /* RESULT0 */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* BCLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* SM_VS */
> + SUNXI_FUNCTION(0x3, "bist0"), /* RESULT1 */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* LRCK */
> + SUNXI_FUNCTION(0x5, "tcon0"), /* TRIG */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "bist0"), /* RESULT2 */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* DOUT0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "bist0"), /* RESULT3 */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* DIN0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 9)),
> + /* HOLE */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D1 */
> + SUNXI_FUNCTION(0x3, "jtag"), /* MS1 */
> + SUNXI_FUNCTION(0x4, "jtag"), /* MS_GPU */
We should use another name here, since the code will just pick the first one and
ignore the second. What about jtag-gpu?
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D0 */
> + SUNXI_FUNCTION(0x3, "jtag"), /* DI1 */
> + SUNXI_FUNCTION(0x4, "jtag"), /* DI_GPU */
Ditto
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* CLK */
> + SUNXI_FUNCTION(0x3, "uart0"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* CMD */
> + SUNXI_FUNCTION(0x3, "jtag"), /* DO */
> + SUNXI_FUNCTION(0x4, "jtag"), /* DO_GPU */
Ditto
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D3 */
> + SUNXI_FUNCTION(0x3, "uart0"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D2 */
> + SUNXI_FUNCTION(0x3, "jtag"), /* CK */
> + SUNXI_FUNCTION(0x4, "jtag"), /* CK_GPU */
Ditto
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 6)),
> + /* HOLE */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* CMD */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D2 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* RTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* CTS */
> + SUNXI_FUNCTION(0x3, "i2s1"), /* MCLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 9)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s1"), /* BCLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 10)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s1"), /* LRCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 11)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s1"), /* DOUT0 */
> + SUNXI_FUNCTION(0x4, "i2s1"), /* DIN1 */
This is suspicious too
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 12)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s1"), /* DIN0 */
> + SUNXI_FUNCTION(0x4, "i2s1"), /* DOUT1 */
Here too
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 13)),
> + /* HOLE */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c0"), /* SCK */
> + SUNXI_FUNCTION(0x5, "emac0"), /* RXD1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c0"), /* SDA */
> + SUNXI_FUNCTION(0x5, "emac0"), /* RXD0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c1"), /* SCK */
> + SUNXI_FUNCTION(0x3, "cpu"), /* CUR_W */
What is "cpu" supposed to be?
> + SUNXI_FUNCTION(0x5, "emac0"), /* RXCTL */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c1"), /* SDA */
> + SUNXI_FUNCTION(0x3, "cir0"), /* OUT */
> + SUNXI_FUNCTION(0x5, "emac0"), /* CLKIN */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart3"), /* TX */
> + SUNXI_FUNCTION(0x3, "spi1"), /* CS */
> + SUNXI_FUNCTION(0x4, "cpu"), /* CUR_W */
> + SUNXI_FUNCTION(0x5, "emac0"), /* TXD1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart3"), /* RX */
> + SUNXI_FUNCTION(0x3, "spi1"), /* CLK */
> + SUNXI_FUNCTION(0x4, "ledc"),
> + SUNXI_FUNCTION(0x5, "emac0"), /* TXD0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart3"), /* RTS */
> + SUNXI_FUNCTION(0x3, "spi1"), /* MOSI */
> + SUNXI_FUNCTION(0x5, "emac0"), /* TXCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart3"), /* CTS */
> + SUNXI_FUNCTION(0x3, "spi1"), /* MISO */
> + SUNXI_FUNCTION(0x4, "spdif"), /* OUT */
> + SUNXI_FUNCTION(0x5, "emac0"), /* TXCTL */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "dmic"), /* CLK */
> + SUNXI_FUNCTION(0x3, "spi2"), /* CS */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* MCLK */
> + SUNXI_FUNCTION(0x5, "i2s2"), /* DIN2 */
Same issue than previously
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "dmic"), /* DATA0 */
> + SUNXI_FUNCTION(0x3, "spi2"), /* CLK */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* BCLK */
> + SUNXI_FUNCTION(0x5, "emac0"), /* MDC */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 9)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "dmic"), /* DATA1 */
> + SUNXI_FUNCTION(0x3, "spi2"), /* MOSI */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* LRCK */
> + SUNXI_FUNCTION(0x5, "emac0"), /* MDIO */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 10)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "dmic"), /* DATA2 */
> + SUNXI_FUNCTION(0x3, "spi2"), /* MISO */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* DOUT0 */
> + SUNXI_FUNCTION(0x5, "i2s2"), /* DIN1 */
Here as well
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 11)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "dmic"), /* DATA3 */
> + SUNXI_FUNCTION(0x3, "i2c3"), /* SCK */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* DIN0 */
> + SUNXI_FUNCTION(0x5, "i2s2"), /* DOUT1 */
Ditto
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 12)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2c3"), /* SCK */
> + SUNXI_FUNCTION(0x4, "i2s3"), /* MCLK */
> + SUNXI_FUNCTION(0x5, "emac0"), /* EPHY */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 13)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 14),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x4, "i2s3"), /* BCLK */
> + SUNXI_FUNCTION(0x5, "emac0"), /* RXD3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 14)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 15),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x4, "i2s3"), /* LRCK */
> + SUNXI_FUNCTION(0x5, "emac0"), /* RXD2 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 15)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 16),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s3"), /* DOUT0 */
> + SUNXI_FUNCTION(0x4, "i2s3"), /* DIN1 */
Ditto
> + SUNXI_FUNCTION(0x5, "emac0"), /* RXCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 16)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 17),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s3"), /* DOUT1 */
> + SUNXI_FUNCTION(0x4, "i2s3"), /* DIN0 */
Ditto
> + SUNXI_FUNCTION(0x5, "emac0"), /* TXD3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 17)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 18),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "cir0"), /* OUT */
> + SUNXI_FUNCTION(0x3, "i2s3"), /* DOUT2 */
> + SUNXI_FUNCTION(0x4, "i2s3"), /* DIN2 */
Ditto
> + SUNXI_FUNCTION(0x5, "emac0"), /* TXD2 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 18)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 19),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "cir0"), /* IN */
> + SUNXI_FUNCTION(0x3, "i2s3"), /* DOUT3 */
> + SUNXI_FUNCTION(0x4, "i2s3"), /* DIN3 */
Ditto
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 4/4] arm64: allwinner: A100: add support for Allwinner Perf1 board
From: Maxime Ripard @ 2020-05-22 15:31 UTC (permalink / raw)
To: Frank Lee
Cc: devicetree, linux-gpio, sboyd, mturquette, linux-kernel,
linux-clk, tiny.windzz, wens, robh+dt, huangshuosheng, p.zabel,
linus.walleij, linux-arm-kernel
In-Reply-To: <20200522030743.10204-5-frank@allwinnertech.com>
[-- Attachment #1.1: Type: text/plain, Size: 2286 bytes --]
Hi,
On Fri, May 22, 2020 at 11:07:43AM +0800, Frank Lee wrote:
> A100 perf1 is an Allwinner A100-based SBC, with the following features:
>
> - 1GiB DDR3 DRAM
> - AXP803 PMIC
> - 2 USB 2.0 ports
> - MicroSD slot and on-board eMMC module
> - on-board Nand flash
> - ···
>
> Adds initial support for it, including the UART.
>
> Signed-off-by: Frank Lee <frank@allwinnertech.com>
Which bootloader have you used to test this?
> ---
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../allwinner/sun50i-a100-allwinner-perf1.dts | 27 +++++++++++++++++++
> 2 files changed, 28 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index e4d3cd0ac5bb..ab780dbdd17b 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -14,6 +14,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus-v1.2.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-emlid-neutis-n5-devboard.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
> new file mode 100644
> index 000000000000..32c9986920ed
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (c) 2020 Frank Lee <frank@allwinner.com>
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a100.dtsi"
> +
> +/{
> + model = "A100 perf1";
Having the same casing and the "brand" would be great here, so something like
"Allwinner A100 Perf1", or just Perf1 if that name is only ever going to be used
on the A100
> + compatible = "allwinner,a100-perf1", "allwinner,sun50i-a100";
This binding needs to be documented
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 10/13] soc: mediatek: cmdq: export finalize function
From: Matthias Brugger @ 2020-05-25 8:38 UTC (permalink / raw)
To: Chun-Kuang Hu
Cc: Mark Rutland, devicetree, Daniel Vetter, wsd_upstream,
David Airlie, Jassi Brar, linux-kernel, DRI Development, HS Liao,
Dennis YC Hsieh, Rob Herring,
moderated list:ARM/Mediatek SoC support, Houlong Wei,
Philipp Zabel, Linux ARM
In-Reply-To: <CAAOTY___HNcRPr8Jq-wNPO_G9pLVjf2D7ezbpPcGbXVNYy1_nA@mail.gmail.com>
On 25/05/2020 02:23, Chun-Kuang Hu wrote:
> Hi, Matthias:
>
> Matthias Brugger <matthias.bgg@gmail.com> 於 2020年5月17日 週日 上午2:22寫道：
>>
>>
>>
>> On 08/03/2020 11:52, Dennis YC Hsieh wrote:
>>> Export finalize function to client which helps append eoc and jump
>>> command to pkt. Let client decide call finalize or not.
>>>
>>> Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
>>> Reviewed-by: CK Hu <ck.hu@mediatek.com>
>>> ---
>>> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 +
>>> drivers/soc/mediatek/mtk-cmdq-helper.c | 7 ++-----
>>> include/linux/soc/mediatek/mtk-cmdq.h | 8 ++++++++
>>> 3 files changed, 11 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
>>> index 0dfcd1787e65..7daaabc26eb1 100644
>>> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
>>> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
>>> @@ -490,6 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
>>> cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
>>> cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
>>> mtk_crtc_ddp_config(crtc, cmdq_handle);
>>> + cmdq_pkt_finalize(cmdq_handle);
>>> cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
>>> }
>>> #endif
>>
>> This should be a independent patch.
>> Other then that patch looks good.
>
> Apply only drm part or only cmdq helpr part, it would be abnormal.
Right it would break DRM driver (if only applied to cmdq) or compilation if only
applied to DRM.
> Shall we seperate this patch?
After thinking twice, I think we can leave it as it is. If you provide your
Acked-by I can take it thorugh my tree, if that's OK for you.
Regards,
Matthias
> Or seperate it but make sure these two patches be in the same tree?
>
> Regards,
> Chun-Kuang.
>
>>
>>> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> index a9ebbabb7439..59bc1164b411 100644
>>> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> @@ -372,7 +372,7 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
>>> }
>>> EXPORT_SYMBOL(cmdq_pkt_assign);
>>>
>>> -static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>>> +int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>>> {
>>> struct cmdq_instruction inst = { {0} };
>>> int err;
>>> @@ -392,6 +392,7 @@ static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>>>
>>> return err;
>>> }
>>> +EXPORT_SYMBOL(cmdq_pkt_finalize);
>>>
>>> static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
>>> {
>>> @@ -426,10 +427,6 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, cmdq_async_flush_cb cb,
>>> unsigned long flags = 0;
>>> struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
>>>
>>> - err = cmdq_pkt_finalize(pkt);
>>> - if (err < 0)
>>> - return err;
>>> -
>>> pkt->cb.cb = cb;
>>> pkt->cb.data = data;
>>> pkt->async_cb.cb = cmdq_pkt_flush_async_cb;
>>> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
>>> index fec292aac83c..99e77155f967 100644
>>> --- a/include/linux/soc/mediatek/mtk-cmdq.h
>>> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
>>> @@ -213,6 +213,14 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
>>> */
>>> int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
>>>
>>> +/**
>>> + * cmdq_pkt_finalize() - Append EOC and jump command to pkt.
>>> + * @pkt: the CMDQ packet
>>> + *
>>> + * Return: 0 for success; else the error code is returned
>>> + */
>>> +int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
>>> +
>>> /**
>>> * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
>>> * packet and call back at the end of done packet
>>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
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] media: exynos4-is: Fix runtime PM imbalance in fimc_is_probe
From: Sylwester Nawrocki @ 2020-05-25 8:38 UTC (permalink / raw)
To: Dinghao Liu, kjlu
Cc: linux-samsung-soc, linux-kernel, Krzysztof Kozlowski,
Kyungmin Park, Kukjin Kim, Sylwester Nawrocki,
Mauro Carvalho Chehab, linux-arm-kernel, linux-media
In-Reply-To: <20200524025903.17219-1-dinghao.liu@zju.edu.cn>
On 5/24/20 04:59, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> when it returns an error code. Thus a pairing decrement is needed on
> the error handling path to keep the counter balanced. For all error
> paths after pm_runtime_get_sync(), things are the same.
>
> Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
_______________________________________________
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 12/15] PCI: rcar: Use pci_host_probe() to register host
From: Geert Uytterhoeven @ 2020-05-25 8:31 UTC (permalink / raw)
To: Rob Herring
Cc: Lorenzo Pieralisi, linux-pci, Yoshihiro Shimoda, Linux-Renesas,
Bjorn Helgaas, Linux ARM, Marek Vasut
In-Reply-To: <20200522234832.954484-13-robh@kernel.org>
Hi Rob,
On Sat, May 23, 2020 at 1:50 AM Rob Herring <robh@kernel.org> wrote:
> The rcar host driver does the same host registration and bus scanning
> calls as pci_host_probe, so let's use it instead.
>
> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Cc: linux-renesas-soc@vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
Thanks for your patch!
Note that this does have 2 side effects: the "linux,pci-probe-only" DT
property and the "pcie_scan_all" kernel command line option are now taken
into account.
Regardless:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] stmmac: platform: add "snps, dwmac-5.10a" IP compatible string
From: Fugang Duan @ 2020-05-25 8:22 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue, joabreu, kuba, davem
Cc: fugang.duan, mcoquelin.stm32, netdev, p.zabel, linux-stm32,
linux-arm-kernel
Add "snps,dwmac-5.10a" compatible string for 5.10a version that can
avoid to define some plat data in glue layer.
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index bcda49d..f32317f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -507,7 +507,8 @@ stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)
if (of_device_is_compatible(np, "snps,dwmac-4.00") ||
of_device_is_compatible(np, "snps,dwmac-4.10a") ||
- of_device_is_compatible(np, "snps,dwmac-4.20a")) {
+ of_device_is_compatible(np, "snps,dwmac-4.20a") ||
+ of_device_is_compatible(np, "snps,dwmac-5.10a")) {
plat->has_gmac4 = 1;
plat->has_gmac = 0;
plat->pmt = 1;
--
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 related
* [PATCH v2] iio: stm32-dfsdm-adc: remove usage of iio_priv_to_dev() helper
From: Alexandru Ardelean @ 2020-05-25 8:26 UTC (permalink / raw)
To: linux-iio, linux-stm32, linux-arm-kernel, linux-kernel
Cc: Alexandru Ardelean, alexandre.torgue, mcoquelin.stm32
In-Reply-To: <20200522130804.631508-1-alexandru.ardelean@analog.com>
We may want to get rid of the iio_priv_to_dev() helper. The reason is that
we will hide some of the members of the iio_dev structure (to prevent
drivers from accessing them directly), and that will also mean hiding the
implementation of the iio_priv_to_dev() helper inside the IIO core.
Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
may not be fast anymore, so a general idea is to try to get rid of the
iio_priv_to_dev() altogether.
The iio_priv() helper won't be affected by the rework, as the iio_dev
struct will keep a reference to the private information.
For this driver, not using iio_priv_to_dev(), means reworking some paths to
pass the iio device and using iio_priv() to access the private information.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
Changelog v1 -> v2:
* changed some paths to pass a reference to ref to iio device and access
private state-struct via iio_priv()
drivers/iio/adc/stm32-dfsdm-adc.c | 65 ++++++++++++++++---------------
1 file changed, 33 insertions(+), 32 deletions(-)
diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
index 76a60d93fe23..03dfc0b6ba98 100644
--- a/drivers/iio/adc/stm32-dfsdm-adc.c
+++ b/drivers/iio/adc/stm32-dfsdm-adc.c
@@ -330,9 +330,9 @@ static int stm32_dfsdm_compute_all_osrs(struct iio_dev *indio_dev,
return 0;
}
-static int stm32_dfsdm_start_channel(struct stm32_dfsdm_adc *adc)
+static int stm32_dfsdm_start_channel(struct iio_dev *indio_dev)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
struct regmap *regmap = adc->dfsdm->regmap;
const struct iio_chan_spec *chan;
unsigned int bit;
@@ -350,9 +350,9 @@ static int stm32_dfsdm_start_channel(struct stm32_dfsdm_adc *adc)
return 0;
}
-static void stm32_dfsdm_stop_channel(struct stm32_dfsdm_adc *adc)
+static void stm32_dfsdm_stop_channel(struct iio_dev *indio_dev)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
struct regmap *regmap = adc->dfsdm->regmap;
const struct iio_chan_spec *chan;
unsigned int bit;
@@ -418,11 +418,11 @@ static void stm32_dfsdm_stop_filter(struct stm32_dfsdm *dfsdm,
DFSDM_CR1_DFEN_MASK, DFSDM_CR1_DFEN(0));
}
-static int stm32_dfsdm_filter_set_trig(struct stm32_dfsdm_adc *adc,
+static int stm32_dfsdm_filter_set_trig(struct iio_dev *indio_dev,
unsigned int fl_id,
struct iio_trigger *trig)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
struct regmap *regmap = adc->dfsdm->regmap;
u32 jextsel = 0, jexten = STM32_DFSDM_JEXTEN_DISABLED;
int ret;
@@ -447,11 +447,11 @@ static int stm32_dfsdm_filter_set_trig(struct stm32_dfsdm_adc *adc,
return 0;
}
-static int stm32_dfsdm_channels_configure(struct stm32_dfsdm_adc *adc,
+static int stm32_dfsdm_channels_configure(struct iio_dev *indio_dev,
unsigned int fl_id,
struct iio_trigger *trig)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
struct regmap *regmap = adc->dfsdm->regmap;
struct stm32_dfsdm_filter *fl = &adc->dfsdm->fl_list[fl_id];
struct stm32_dfsdm_filter_osr *flo = &fl->flo[0];
@@ -491,11 +491,11 @@ static int stm32_dfsdm_channels_configure(struct stm32_dfsdm_adc *adc,
return 0;
}
-static int stm32_dfsdm_filter_configure(struct stm32_dfsdm_adc *adc,
+static int stm32_dfsdm_filter_configure(struct iio_dev *indio_dev,
unsigned int fl_id,
struct iio_trigger *trig)
{
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
struct regmap *regmap = adc->dfsdm->regmap;
struct stm32_dfsdm_filter *fl = &adc->dfsdm->fl_list[fl_id];
struct stm32_dfsdm_filter_osr *flo = &fl->flo[fl->fast];
@@ -521,7 +521,7 @@ static int stm32_dfsdm_filter_configure(struct stm32_dfsdm_adc *adc,
if (ret)
return ret;
- ret = stm32_dfsdm_filter_set_trig(adc, fl_id, trig);
+ ret = stm32_dfsdm_filter_set_trig(indio_dev, fl_id, trig);
if (ret)
return ret;
@@ -729,21 +729,22 @@ static ssize_t dfsdm_adc_audio_set_spiclk(struct iio_dev *indio_dev,
return len;
}
-static int stm32_dfsdm_start_conv(struct stm32_dfsdm_adc *adc,
+static int stm32_dfsdm_start_conv(struct iio_dev *indio_dev,
struct iio_trigger *trig)
{
+ struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
struct regmap *regmap = adc->dfsdm->regmap;
int ret;
- ret = stm32_dfsdm_channels_configure(adc, adc->fl_id, trig);
+ ret = stm32_dfsdm_channels_configure(indio_dev, adc->fl_id, trig);
if (ret < 0)
return ret;
- ret = stm32_dfsdm_start_channel(adc);
+ ret = stm32_dfsdm_start_channel(indio_dev);
if (ret < 0)
return ret;
- ret = stm32_dfsdm_filter_configure(adc, adc->fl_id, trig);
+ ret = stm32_dfsdm_filter_configure(indio_dev, adc->fl_id, trig);
if (ret < 0)
goto stop_channels;
@@ -757,13 +758,14 @@ static int stm32_dfsdm_start_conv(struct stm32_dfsdm_adc *adc,
regmap_update_bits(regmap, DFSDM_CR1(adc->fl_id),
DFSDM_CR1_CFG_MASK, 0);
stop_channels:
- stm32_dfsdm_stop_channel(adc);
+ stm32_dfsdm_stop_channel(indio_dev);
return ret;
}
-static void stm32_dfsdm_stop_conv(struct stm32_dfsdm_adc *adc)
+static void stm32_dfsdm_stop_conv(struct iio_dev *indio_dev)
{
+ struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
struct regmap *regmap = adc->dfsdm->regmap;
stm32_dfsdm_stop_filter(adc->dfsdm, adc->fl_id);
@@ -771,7 +773,7 @@ static void stm32_dfsdm_stop_conv(struct stm32_dfsdm_adc *adc)
regmap_update_bits(regmap, DFSDM_CR1(adc->fl_id),
DFSDM_CR1_CFG_MASK, 0);
- stm32_dfsdm_stop_channel(adc);
+ stm32_dfsdm_stop_channel(indio_dev);
}
static int stm32_dfsdm_set_watermark(struct iio_dev *indio_dev,
@@ -1017,7 +1019,7 @@ static int __stm32_dfsdm_postenable(struct iio_dev *indio_dev)
goto stop_dfsdm;
}
- ret = stm32_dfsdm_start_conv(adc, indio_dev->trig);
+ ret = stm32_dfsdm_start_conv(indio_dev, indio_dev->trig);
if (ret) {
dev_err(&indio_dev->dev, "Can't start conversion\n");
goto err_stop_dma;
@@ -1063,7 +1065,7 @@ static void __stm32_dfsdm_predisable(struct iio_dev *indio_dev)
{
struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
- stm32_dfsdm_stop_conv(adc);
+ stm32_dfsdm_stop_conv(indio_dev);
stm32_dfsdm_adc_dma_stop(indio_dev);
@@ -1159,7 +1161,7 @@ static int stm32_dfsdm_single_conv(struct iio_dev *indio_dev,
adc->nconv = 1;
adc->smask = BIT(chan->scan_index);
- ret = stm32_dfsdm_start_conv(adc, NULL);
+ ret = stm32_dfsdm_start_conv(indio_dev, NULL);
if (ret < 0) {
regmap_update_bits(adc->dfsdm->regmap, DFSDM_CR2(adc->fl_id),
DFSDM_CR2_REOCIE_MASK, DFSDM_CR2_REOCIE(0));
@@ -1180,7 +1182,7 @@ static int stm32_dfsdm_single_conv(struct iio_dev *indio_dev,
else
ret = IIO_VAL_INT;
- stm32_dfsdm_stop_conv(adc);
+ stm32_dfsdm_stop_conv(indio_dev);
stm32_dfsdm_process_data(adc, res);
@@ -1313,8 +1315,8 @@ static const struct iio_info stm32_dfsdm_info_adc = {
static irqreturn_t stm32_dfsdm_irq(int irq, void *arg)
{
- struct stm32_dfsdm_adc *adc = arg;
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = arg;
+ struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
struct regmap *regmap = adc->dfsdm->regmap;
unsigned int status, int_en;
@@ -1574,7 +1576,7 @@ static int stm32_dfsdm_adc_probe(struct platform_device *pdev)
iio->dev.of_node = np;
iio->modes = INDIO_DIRECT_MODE;
- platform_set_drvdata(pdev, adc);
+ platform_set_drvdata(pdev, iio);
ret = of_property_read_u32(dev->of_node, "reg", &adc->fl_id);
if (ret != 0 || adc->fl_id >= adc->dfsdm->num_fls) {
@@ -1603,7 +1605,7 @@ static int stm32_dfsdm_adc_probe(struct platform_device *pdev)
return irq;
ret = devm_request_irq(dev, irq, stm32_dfsdm_irq,
- 0, pdev->name, adc);
+ 0, pdev->name, iio);
if (ret < 0) {
dev_err(dev, "Failed to request IRQ\n");
return ret;
@@ -1650,8 +1652,8 @@ static int stm32_dfsdm_adc_probe(struct platform_device *pdev)
static int stm32_dfsdm_adc_remove(struct platform_device *pdev)
{
- struct stm32_dfsdm_adc *adc = platform_get_drvdata(pdev);
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+ struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
if (adc->dev_data->type == DFSDM_AUDIO)
of_platform_depopulate(&pdev->dev);
@@ -1663,8 +1665,7 @@ static int stm32_dfsdm_adc_remove(struct platform_device *pdev)
static int __maybe_unused stm32_dfsdm_adc_suspend(struct device *dev)
{
- struct stm32_dfsdm_adc *adc = dev_get_drvdata(dev);
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
if (iio_buffer_enabled(indio_dev))
__stm32_dfsdm_predisable(indio_dev);
@@ -1674,8 +1675,8 @@ static int __maybe_unused stm32_dfsdm_adc_suspend(struct device *dev)
static int __maybe_unused stm32_dfsdm_adc_resume(struct device *dev)
{
- struct stm32_dfsdm_adc *adc = dev_get_drvdata(dev);
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
const struct iio_chan_spec *chan;
struct stm32_dfsdm_channel *ch;
int i, ret;
--
2.25.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
* Recall: [PATCH net 1/1] net: stmmac: enable timestamp snapshot for required PTP packets in dwmac v5.10a
From: Andy Duan @ 2020-05-25 8:26 UTC (permalink / raw)
To: peppe.cavallaro@st.com, alexandre.torgue@st.com,
joabreu@synopsys.com, kuba@kernel.org, davem@davemloft.net
Cc: Andy Duan, mcoquelin.stm32@gmail.com, netdev@vger.kernel.org,
p.zabel@pengutronix.de, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
Andy Duan would like to recall the message, "[PATCH net 1/1] net: stmmac: enable timestamp snapshot for required PTP packets in dwmac v5.10a".
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net 1/1] net: stmmac: enable timestamp snapshot for required PTP packets in dwmac v5.10a
From: Fugang Duan @ 2020-05-25 8:18 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue, joabreu, kuba, davem
Cc: fugang.duan, mcoquelin.stm32, netdev, p.zabel, linux-stm32,
linux-arm-kernel
For rx filter 'HWTSTAMP_FILTER_PTP_V2_EVENT', it should be
PTP v2/802.AS1, any layer, any kind of event packet, but HW only
take timestamp snapshot for below PTP message: sync, Pdelay_req,
Pdelay_resp.
Then it causes below issue when test E2E case:
ptp4l[2479.534]: port 1: received DELAY_REQ without timestamp
ptp4l[2481.423]: port 1: received DELAY_REQ without timestamp
ptp4l[2481.758]: port 1: received DELAY_REQ without timestamp
ptp4l[2483.524]: port 1: received DELAY_REQ without timestamp
ptp4l[2484.233]: port 1: received DELAY_REQ without timestamp
ptp4l[2485.750]: port 1: received DELAY_REQ without timestamp
ptp4l[2486.888]: port 1: received DELAY_REQ without timestamp
ptp4l[2487.265]: port 1: received DELAY_REQ without timestamp
ptp4l[2487.316]: port 1: received DELAY_REQ without timestamp
Timestamp snapshot dependency on register bits in received path:
SNAPTYPSEL TSMSTRENA TSEVNTENA PTP_Messages
01 x 0 SYNC, Follow_Up, Delay_Req,
Delay_Resp, Pdelay_Req, Pdelay_Resp,
Pdelay_Resp_Follow_Up
01 0 1 SYNC, Pdelay_Req, Pdelay_Resp
For dwmac v5.10a, enabling all events by setting register
DWC_EQOS_TIME_STAMPING[SNAPTYPSEL] to 2’b01, clearing bit [TSEVNTENA]
to 0’b0, which can support all required events.
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b6f92c7..73677c3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -630,7 +630,8 @@ static int stmmac_hwtstamp_set(struct net_device *dev, struct ifreq *ifr)
config.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
ptp_v2 = PTP_TCR_TSVER2ENA;
snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
- ts_event_en = PTP_TCR_TSEVNTENA;
+ if (priv->synopsys_id != DWMAC_CORE_5_10)
+ ts_event_en = PTP_TCR_TSEVNTENA;
ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
ptp_over_ethernet = PTP_TCR_TSIPENA;
--
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 related
* Re: [PATCH v4 1/5] net: macb: fix wakeup test in runtime suspend/resume routines
From: Nicolas Ferre @ 2020-05-25 8:18 UTC (permalink / raw)
To: Jakub Kicinski, netdev, David S. Miller, f.fainelli,
Russell King - ARM Linux admin
Cc: Alexandre Belloni, antoine.tenart, linux-kernel, harini.katakam,
Claudiu Beznea, linux-arm-kernel
In-Reply-To: <347c9a4f-8a01-a931-c9d5-536339337f8a@microchip.com>
On 07/05/2020 at 12:03, Nicolas Ferre wrote:
> On 06/05/2020 at 22:18, Jakub Kicinski wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> On Wed, 6 May 2020 13:37:37 +0200 nicolas.ferre@microchip.com wrote:
>>> From: Nicolas Ferre <nicolas.ferre@microchip.com>
>>>
>>> Use the proper struct device pointer to check if the wakeup flag
>>> and wakeup source are positioned.
>>> Use the one passed by function call which is equivalent to
>>> &bp->dev->dev.parent.
>>>
>>> It's preventing the trigger of a spurious interrupt in case the
>>> Wake-on-Lan feature is used.
>>>
>>> Fixes: bc1109d04c39 ("net: macb: Add pm runtime support")
>>
>> Fixes tag: Fixes: bc1109d04c39 ("net: macb: Add pm runtime support")
>> Has these problem(s):
>> - Target SHA1 does not exist
>
> Indeed, it's:
> Fixes: d54f89af6cc4 ("net: macb: Add pm runtime support")
>
> David: do I have to respin or you can modify it?
David, all, I'm about to resend this series (alternative to "ping"),
however:
1/ Now that it's late in the cycle, I'd like that you tell me if I
rebase on net-next because it isn't not sensible to queue such (non
urgeent) changes at rc7
2/ I didn't get answers from Russell and can't tell if there's a better
way of handling underlying phylink error of phylink_ethtool_set_wol() in
patch 3/5
Best regards,
Nicolas
>>> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
>>> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>>> Cc: Claudiu Beznea <claudiu.beznea@microchip.com>
>>> Cc: Harini Katakam <harini.katakam@xilinx.com>
>>> ---
>>> drivers/net/ethernet/cadence/macb_main.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
>>> index 36290a8e2a84..d11fae37d46b 100644
>>> --- a/drivers/net/ethernet/cadence/macb_main.c
>>> +++ b/drivers/net/ethernet/cadence/macb_main.c
>>> @@ -4616,7 +4616,7 @@ static int __maybe_unused macb_runtime_suspend(struct device *dev)
>>> struct net_device *netdev = dev_get_drvdata(dev);
>>> struct macb *bp = netdev_priv(netdev);
>>>
>>> - if (!(device_may_wakeup(&bp->dev->dev))) {
>>> + if (!(device_may_wakeup(dev))) {
>>> clk_disable_unprepare(bp->tx_clk);
>>> clk_disable_unprepare(bp->hclk);
>>> clk_disable_unprepare(bp->pclk);
>>> @@ -4632,7 +4632,7 @@ static int __maybe_unused macb_runtime_resume(struct device *dev)
>>> struct net_device *netdev = dev_get_drvdata(dev);
>>> struct macb *bp = netdev_priv(netdev);
>>>
>>> - if (!(device_may_wakeup(&bp->dev->dev))) {
>>> + if (!(device_may_wakeup(dev))) {
>>> clk_prepare_enable(bp->pclk);
>>> clk_prepare_enable(bp->hclk);
>>> clk_prepare_enable(bp->tx_clk);
>>
>
>
--
Nicolas Ferre
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net 1/1] net: stmmac: enable timestamp snapshot for required PTP packets in dwmac v5.10a
From: Fugang Duan @ 2020-05-25 8:09 UTC (permalink / raw)
To: peppe.cavallaro, alexandre.torgue, joabreu, kuba, davem
Cc: fugang.duan, mcoquelin.stm32, netdev, p.zabel, linux-stm32,
linux-arm-kernel
For rx filter 'HWTSTAMP_FILTER_PTP_V2_EVENT', it should be
PTP v2/802.AS1, any layer, any kind of event packet, but HW only
take timestamp snapshot for below PTP message: sync, Pdelay_req,
Pdelay_resp.
Then it causes below issue when test E2E case:
ptp4l[2479.534]: port 1: received DELAY_REQ without timestamp
ptp4l[2481.423]: port 1: received DELAY_REQ without timestamp
ptp4l[2481.758]: port 1: received DELAY_REQ without timestamp
ptp4l[2483.524]: port 1: received DELAY_REQ without timestamp
ptp4l[2484.233]: port 1: received DELAY_REQ without timestamp
ptp4l[2485.750]: port 1: received DELAY_REQ without timestamp
ptp4l[2486.888]: port 1: received DELAY_REQ without timestamp
ptp4l[2487.265]: port 1: received DELAY_REQ without timestamp
ptp4l[2487.316]: port 1: received DELAY_REQ without timestamp
Timestamp snapshot dependency on register bits in received path:
SNAPTYPSEL TSMSTRENA TSEVNTENA PTP_Messages
01 x 0 SYNC, Follow_Up, Delay_Req,
Delay_Resp, Pdelay_Req, Pdelay_Resp,
Pdelay_Resp_Follow_Up
01 0 1 SYNC, Pdelay_Req, Pdelay_Resp
For dwmac v5.10a, enabling all events by setting register
DWC_EQOS_TIME_STAMPING[SNAPTYPSEL] to 2’b01, clearing bit [TSEVNTENA]
to 0’b0, which can support all required events.
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b6f92c7..73677c3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -630,7 +630,8 @@ static int stmmac_hwtstamp_set(struct net_device *dev, struct ifreq *ifr)
config.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
ptp_v2 = PTP_TCR_TSVER2ENA;
snap_type_sel = PTP_TCR_SNAPTYPSEL_1;
- ts_event_en = PTP_TCR_TSEVNTENA;
+ if (priv->synopsys_id != DWMAC_CORE_5_10)
+ ts_event_en = PTP_TCR_TSEVNTENA;
ptp_over_ipv4_udp = PTP_TCR_TSIPV4ENA;
ptp_over_ipv6_udp = PTP_TCR_TSIPV6ENA;
ptp_over_ethernet = PTP_TCR_TSIPENA;
--
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 related
* [PATCH] arm64: dts: ls1028a: add one more thermal zone support
From: Yuantian Tang @ 2020-05-25 7:38 UTC (permalink / raw)
To: shawnguo, robh+dt, mark.rutland, catalin.marinas, will.deacon
Cc: devicetree, Yuantian Tang, linux-kernel, linux-arm-kernel
There are 2 thermal zones in ls1028a soc. Current dts only
includes one. This patch adds the other thermal zone node
in dts to enable it.
Signed-off-by: Yuantian Tang <andy.tang@nxp.com>
---
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 22 ++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 055f114cf848..bc6f0c0f85da 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -129,11 +129,31 @@
};
thermal-zones {
- core-cluster {
+ ddr-controller {
polling-delay-passive = <1000>;
polling-delay = <5000>;
thermal-sensors = <&tmu 0>;
+ trips {
+ ddr-ctrler-alert {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ ddr-ctrler-crit {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+
+ core-cluster {
+ polling-delay-passive = <1000>;
+ polling-delay = <5000>;
+ thermal-sensors = <&tmu 1>;
+
trips {
core_cluster_alert: core-cluster-alert {
temperature = <85000>;
--
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 5/5] crypto: stm32/crc: protect from concurrent accesses
From: Ard Biesheuvel @ 2020-05-25 7:46 UTC (permalink / raw)
To: Nicolas TOROMANOFF
Cc: Alexandre TORGUE, Linux Kernel Mailing List, David S . Miller,
Linux Crypto Mailing List, Maxime Coquelin,
linux-stm32@st-md-mailman.stormreply.com, Linux ARM, Herbert Xu
In-Reply-To: <67c25d90d9714a85b52f3d9c2070af88@SFHDAG6NODE1.st.com>
On Mon, 25 May 2020 at 09:24, Nicolas TOROMANOFF
<nicolas.toromanoff@st.com> wrote:
>
> Hello,
>
> > -----Original Message-----
> > From: Ard Biesheuvel <ardb@kernel.org>
> > Sent: Friday, May 22, 2020 6:12 PM>
> > On Tue, 12 May 2020 at 16:13, Nicolas Toromanoff
> > <nicolas.toromanoff@st.com> wrote:
> > >
> > > Protect STM32 CRC device from concurrent accesses.
> > >
> > > As we create a spinlocked section that increase with buffer size, we
> > > provide a module parameter to release the pressure by splitting
> > > critical section in chunks.
> > >
> > > Size of each chunk is defined in burst_size module parameter.
> > > By default burst_size=0, i.e. don't split incoming buffer.
> > >
> > > Signed-off-by: Nicolas Toromanoff <nicolas.toromanoff@st.com>
> >
> > Would you mind explaining the usage model here? It looks like you are sharing a
> > CRC hardware accelerator with a synchronous interface between different users
> > by using spinlocks? You are aware that this will tie up the waiting CPUs
> > completely during this time, right? So it would be much better to use a mutex
> > here. Or perhaps it would make more sense to fall back to a s/w based CRC
> > routine if the h/w is tied up working for another task?
>
> I know mutex are more acceptable here, but shash _update() and _init() may be call
> from any context, and so I cannot take a mutex.
> And to protect my concurrent HW access I only though about spinlock. Due to possible
> constraint on CPUs, I add a burst_size option to force slitting long buffer into smaller one,
> and so decrease time we take the lock.
> But I didn't though to fallback to software CRC.
>
> I'll do a patch on top.
> In in the burst_update() function I'll use a spin_trylock_irqsave() and use software CRC32 if HW is already in use.
>
Right. I didn't even notice that you were keeping interrupts disabled
the whole time when using the h/w block. That means that any serious
use of this h/w block will make IRQ latency go through the roof.
I recommend that you go back to the drawing board on this driver,
rather than papering over the issues with a spin_trylock(). Perhaps it
would be better to model it as a ahash (even though the h/w block
itself is synchronous) and use a kthread to feed in the data.
_______________________________________________
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 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
From: Ricardo Cañuelo @ 2020-05-25 7:43 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, geert+renesas, xuwei5, robh+dt, kernel,
linux-arm-kernel
In-Reply-To: <20200514152239.GG5955@pendragon.ideasonboard.com>
Hi Laurent,
On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > If we want to be more strict and require the definition of all the
> > supplies, there will be many more DTs changes in the series, and I'm not
> > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > at them and it's not always clear which regulators to use or if they are
> > even defined.
>
> We can decouple the two though (I think). The bindings should reflect
> what we consider right, and the dts files could be fixed on top.
Do you have a suggestion on how to do this? If we decouple the two
tasks most of the work would be searching for DTs to fix and finding a
way to fix each one of them, and unless I do this _before_ the binding
conversion I'll get a lot of dtbs_check errors.
The binding conversion itself is done, if we go this route the only
additional change would be to make the supplies required.
Cheers,
Ricardo
_______________________________________________
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 5/5] crypto: stm32/crc: protect from concurrent accesses
From: Nicolas TOROMANOFF @ 2020-05-25 7:24 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Alexandre TORGUE, Linux Kernel Mailing List, David S . Miller,
Linux Crypto Mailing List, Maxime Coquelin,
linux-stm32@st-md-mailman.stormreply.com, Linux ARM, Herbert Xu
In-Reply-To: <CAMj1kXGs6UgkKb5+tH2B-+26=tbjHq3UUY2gxfcRfMb1nGVuFA@mail.gmail.com>
Hello,
> -----Original Message-----
> From: Ard Biesheuvel <ardb@kernel.org>
> Sent: Friday, May 22, 2020 6:12 PM>
> On Tue, 12 May 2020 at 16:13, Nicolas Toromanoff
> <nicolas.toromanoff@st.com> wrote:
> >
> > Protect STM32 CRC device from concurrent accesses.
> >
> > As we create a spinlocked section that increase with buffer size, we
> > provide a module parameter to release the pressure by splitting
> > critical section in chunks.
> >
> > Size of each chunk is defined in burst_size module parameter.
> > By default burst_size=0, i.e. don't split incoming buffer.
> >
> > Signed-off-by: Nicolas Toromanoff <nicolas.toromanoff@st.com>
>
> Would you mind explaining the usage model here? It looks like you are sharing a
> CRC hardware accelerator with a synchronous interface between different users
> by using spinlocks? You are aware that this will tie up the waiting CPUs
> completely during this time, right? So it would be much better to use a mutex
> here. Or perhaps it would make more sense to fall back to a s/w based CRC
> routine if the h/w is tied up working for another task?
I know mutex are more acceptable here, but shash _update() and _init() may be call
from any context, and so I cannot take a mutex.
And to protect my concurrent HW access I only though about spinlock. Due to possible
constraint on CPUs, I add a burst_size option to force slitting long buffer into smaller one,
and so decrease time we take the lock.
But I didn't though to fallback to software CRC.
I'll do a patch on top.
In in the burst_update() function I'll use a spin_trylock_irqsave() and use software CRC32 if HW is already in use.
Thanks and regards,
Nicolas.
> Using spinlocks for this is really not acceptable.
>
>
>
> > ---
> > drivers/crypto/stm32/stm32-crc32.c | 47
> > ++++++++++++++++++++++++++++--
> > 1 file changed, 45 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/crypto/stm32/stm32-crc32.c
> > b/drivers/crypto/stm32/stm32-crc32.c
> > index 413415c216ef..3ba41148c2a4 100644
> > --- a/drivers/crypto/stm32/stm32-crc32.c
> > +++ b/drivers/crypto/stm32/stm32-crc32.c
> > @@ -35,11 +35,16 @@
> >
> > #define CRC_AUTOSUSPEND_DELAY 50
> >
> > +static unsigned int burst_size;
> > +module_param(burst_size, uint, 0644); MODULE_PARM_DESC(burst_size,
> > +"Select burst byte size (0 unlimited)");
> > +
> > struct stm32_crc {
> > struct list_head list;
> > struct device *dev;
> > void __iomem *regs;
> > struct clk *clk;
> > + spinlock_t lock;
> > };
> >
> > struct stm32_crc_list {
> > @@ -109,6 +114,7 @@ static int stm32_crc_init(struct shash_desc *desc)
> > struct stm32_crc_desc_ctx *ctx = shash_desc_ctx(desc);
> > struct stm32_crc_ctx *mctx = crypto_shash_ctx(desc->tfm);
> > struct stm32_crc *crc;
> > + unsigned long flags;
> >
> > crc = stm32_crc_get_next_crc();
> > if (!crc)
> > @@ -116,6 +122,8 @@ static int stm32_crc_init(struct shash_desc *desc)
> >
> > pm_runtime_get_sync(crc->dev);
> >
> > + spin_lock_irqsave(&crc->lock, flags);
> > +
> > /* Reset, set key, poly and configure in bit reverse mode */
> > writel_relaxed(bitrev32(mctx->key), crc->regs + CRC_INIT);
> > writel_relaxed(bitrev32(mctx->poly), crc->regs + CRC_POL); @@
> > -125,18 +133,21 @@ static int stm32_crc_init(struct shash_desc *desc)
> > /* Store partial result */
> > ctx->partial = readl_relaxed(crc->regs + CRC_DR);
> >
> > + spin_unlock_irqrestore(&crc->lock, flags);
> > +
> > pm_runtime_mark_last_busy(crc->dev);
> > pm_runtime_put_autosuspend(crc->dev);
> >
> > return 0;
> > }
> >
> > -static int stm32_crc_update(struct shash_desc *desc, const u8 *d8,
> > - unsigned int length)
> > +static int burst_update(struct shash_desc *desc, const u8 *d8,
> > + size_t length)
> > {
> > struct stm32_crc_desc_ctx *ctx = shash_desc_ctx(desc);
> > struct stm32_crc_ctx *mctx = crypto_shash_ctx(desc->tfm);
> > struct stm32_crc *crc;
> > + unsigned long flags;
> >
> > crc = stm32_crc_get_next_crc();
> > if (!crc)
> > @@ -144,6 +155,8 @@ static int stm32_crc_update(struct shash_desc
> > *desc, const u8 *d8,
> >
> > pm_runtime_get_sync(crc->dev);
> >
> > + spin_lock_irqsave(&crc->lock, flags);
> > +
> > /*
> > * Restore previously calculated CRC for this context as init value
> > * Restore polynomial configuration @@ -182,12 +195,40 @@
> > static int stm32_crc_update(struct shash_desc *desc, const u8 *d8,
> > /* Store partial result */
> > ctx->partial = readl_relaxed(crc->regs + CRC_DR);
> >
> > + spin_unlock_irqrestore(&crc->lock, flags);
> > +
> > pm_runtime_mark_last_busy(crc->dev);
> > pm_runtime_put_autosuspend(crc->dev);
> >
> > return 0;
> > }
> >
> > +static int stm32_crc_update(struct shash_desc *desc, const u8 *d8,
> > + unsigned int length) {
> > + const unsigned int burst_sz = burst_size;
> > + unsigned int rem_sz;
> > + const u8 *cur;
> > + size_t size;
> > + int ret;
> > +
> > + if (!burst_sz)
> > + return burst_update(desc, d8, length);
> > +
> > + /* Digest first bytes not 32bit aligned at first pass in the loop */
> > + size = min(length,
> > + burst_sz + (unsigned int)d8 - ALIGN_DOWN((unsigned int)d8,
> > + sizeof(u32)));
> > + for (rem_sz = length, cur = d8; rem_sz;
> > + rem_sz -= size, cur += size, size = min(rem_sz, burst_sz)) {
> > + ret = burst_update(desc, cur, size);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static int stm32_crc_final(struct shash_desc *desc, u8 *out) {
> > struct stm32_crc_desc_ctx *ctx = shash_desc_ctx(desc); @@
> > -300,6 +341,8 @@ static int stm32_crc_probe(struct platform_device *pdev)
> > pm_runtime_irq_safe(dev);
> > pm_runtime_enable(dev);
> >
> > + spin_lock_init(&crc->lock);
> > +
> > platform_set_drvdata(pdev, crc);
> >
> > spin_lock(&crc_list.lock);
> > --
> > 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
* Re: [PATCH v2 5/6] mm: tlb: Provide flush_*_tlb_range wrappers
From: Zhenyu Ye @ 2020-05-25 7:19 UTC (permalink / raw)
To: Catalin Marinas
Cc: mark.rutland, peterz, linux-mm, guohanjun, will, linux-arch,
yuzhao, aneesh.kumar, steven.price, arm, Dave.Martin, arnd,
suzuki.poulose, npiggin, zhangshaokun, broonie, rostedt,
prime.zeng, kuhn.chenqun, tglx, linux-arm-kernel, xiexiangyou,
linux-kernel, maz, akpm
In-Reply-To: <20200522154254.GD26492@gaia>
On 2020/5/22 23:42, Catalin Marinas wrote:
> On Thu, Apr 23, 2020 at 09:56:55PM +0800, Zhenyu Ye wrote:
>> diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c
>> index 3d7c01e76efc..3eff199d3507 100644
>> --- a/mm/pgtable-generic.c
>> +++ b/mm/pgtable-generic.c
>> @@ -101,6 +101,28 @@ pte_t ptep_clear_flush(struct vm_area_struct *vma, unsigned long address,
>>
>> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>>
>> +#ifndef __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
>> +
>> +#define FLUSH_Pxx_TLB_RANGE(_pxx) \
>> +void flush_##_pxx##_tlb_range(struct vm_area_struct *vma, \
>> + unsigned long addr, unsigned long end) \
>> +{ \
>> + struct mmu_gather tlb; \
>> + \
>> + tlb_gather_mmu(&tlb, vma->vm_mm, addr, end); \
>> + tlb_start_vma(&tlb, vma); \
>> + tlb_flush_##_pxx##_range(&tlb, addr, end - addr); \
>> + tlb_end_vma(&tlb, vma); \
>> + tlb_finish_mmu(&tlb, addr, end); \
>> +}
>
> I may have confused myself (flush_p??_tlb_* vs. tlb_flush_p??_*) but do
> actually need this whole tlb_gather thing here? IIUC (by grep'ing),
> flush_p?d_tlb_range() is only called on huge pages, so we should know
> the level already.
>
tlb_flush_##_pxx##_range() is used to set tlb->cleared_*,
flush_##_pxx##_tlb_range() will actually flush the TLB entry.
In arch64, tlb_flush_p?d_range() is defined as:
#define flush_pmd_tlb_range(vma, addr, end) flush_tlb_range(vma, addr, end)
#define flush_pud_tlb_range(vma, addr, end) flush_tlb_range(vma, addr, end)
So even if we know the level here, we can not pass the value to tlbi
instructions (flush_tlb_range() is a common kernel interface and retro-fit it
needs lots of changes), according to Peter's suggestion, I finally decide to
pass the value of TTL by the tlb_gather_* frame.[1]
[1] https://lore.kernel.org/linux-arm-kernel/20200331142927.1237-1-yezhenyu2@huawei.com/
Thanks,
Zhenyu
_______________________________________________
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 7/7] iommu/mediatek: Add mt6779 basic support
From: Yong Wu @ 2020-05-25 6:54 UTC (permalink / raw)
To: Chao Hao
Cc: devicetree, FY Yang, wsd_upstream, Joerg Roedel, linux-kernel,
iommu, Rob Herring, linux-mediatek, Matthias Brugger, Jun Yan,
linux-arm-kernel
In-Reply-To: <20200509083654.5178-8-chao.hao@mediatek.com>
On Sat, 2020-05-09 at 16:36 +0800, Chao Hao wrote:
> 1. Start from mt6779, INVLDT_SEL move to offset=0x2c, so we add
> REG_MMU_INV_SEL_GEN2 definition and mt6779 uses it.
> 2. Change PROTECT_PA_ALIGN from 128 byte to 256 byte.
> 3. For REG_MMU_CTRL_REG register, we only need to change bit[2:0],
> others bits keep default value, ex: enable victim tlb.
> 4. Add mt6779_data to support mm_iommu HW init.
>
> Signed-off-by: Chao Hao <chao.hao@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 18 +++++++++++++++---
> drivers/iommu/mtk_iommu.h | 1 +
> 2 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index dc9ae944e712..34c4ffb77c73 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -37,6 +37,7 @@
> #define REG_MMU_INVLD_START_A 0x024
> #define REG_MMU_INVLD_END_A 0x028
>
> +#define REG_MMU_INV_SEL_GEN2 0x02c
> #define REG_MMU_INV_SEL_GEN1 0x038
Normally the register name comes from the CODA. In the lasted CODA,
this is called "MMU_INVLDT_SEL". But it's same with the previous 0x38
totally. Using _GEN1, _GEN2 is ok for me. Please add its coda name in
the comment. like:
#define REG_MMU_INV_SEL_GEN2 0x02c /* MMU_INVLDT_SEL */
> #define F_INVLD_EN0 BIT(0)
> #define F_INVLD_EN1 BIT(1)
> @@ -97,7 +98,7 @@
> #define F_MMU_INT_ID_LARB_ID(a) (((a) >> 7) & 0x7)
> #define F_MMU_INT_ID_PORT_ID(a) (((a) >> 2) & 0x1f)
>
> -#define MTK_PROTECT_PA_ALIGN 128
> +#define MTK_PROTECT_PA_ALIGN 256
>
> /*
> * Get the local arbiter ID and the portid within the larb arbiter
> @@ -554,11 +555,12 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> return ret;
> }
>
> + regval = readl_relaxed(data->base + REG_MMU_CTRL_REG);
> if (data->plat_data->m4u_plat == M4U_MT8173)
> - regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
> + regval |= F_MMU_PREFETCH_RT_REPLACE_MOD |
The default value is not ok for mt8173(Its bit9 is in_order_write_en, we
could not use its default 1'b1). thus, Don't touch this line.
> F_MMU_TF_PROT_TO_PROGRAM_ADDR_MT8173;
> else
> - regval = F_MMU_TF_PROT_TO_PROGRAM_ADDR;
> + regval |= F_MMU_TF_PROT_TO_PROGRAM_ADDR;
> writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
>
> regval = F_L2_MULIT_HIT_EN |
> @@ -804,6 +806,15 @@ static const struct mtk_iommu_plat_data mt2712_data = {
> .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}},
> };
>
> +static const struct mtk_iommu_plat_data mt6779_data = {
> + .m4u_plat = M4U_MT6779,
> + .larbid_remap = {{0}, {1}, {2}, {3}, {5}, {7, 8}, {10}, {9}},
> + .has_sub_comm = true,
> + .has_wr_len = true,
> + .has_misc_ctrl = true,
> + .inv_sel_reg = REG_MMU_INV_SEL_GEN2,
align '=' a bit.
> +};
> +
> static const struct mtk_iommu_plat_data mt8173_data = {
> .m4u_plat = M4U_MT8173,
> .has_4gb_mode = true,
> @@ -822,6 +833,7 @@ static const struct mtk_iommu_plat_data mt8183_data = {
>
> static const struct of_device_id mtk_iommu_of_ids[] = {
> { .compatible = "mediatek,mt2712-m4u", .data = &mt2712_data},
> + { .compatible = "mediatek,mt6779-m4u", .data = &mt6779_data},
> { .compatible = "mediatek,mt8173-m4u", .data = &mt8173_data},
> { .compatible = "mediatek,mt8183-m4u", .data = &mt8183_data},
> {}
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index 9971cedd72ea..fb79e710c8d9 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -31,6 +31,7 @@ struct mtk_iommu_suspend_reg {
> enum mtk_iommu_plat {
> M4U_MT2701,
> M4U_MT2712,
> + M4U_MT6779,
> M4U_MT8173,
> M4U_MT8183,
> };
_______________________________________________
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/6] arm64: Add tlbi_user_level TLB invalidation helper
From: Zhenyu Ye @ 2020-05-25 6:57 UTC (permalink / raw)
To: Catalin Marinas
Cc: mark.rutland, peterz, linux-mm, guohanjun, will, linux-arch,
yuzhao, aneesh.kumar, steven.price, arm, Dave.Martin, arnd,
suzuki.poulose, npiggin, zhangshaokun, broonie, rostedt,
prime.zeng, kuhn.chenqun, tglx, linux-arm-kernel, xiexiangyou,
linux-kernel, maz, akpm
In-Reply-To: <20200522154925.GE26492@gaia>
On 2020/5/22 23:49, Catalin Marinas wrote:
> On Thu, Apr 23, 2020 at 09:56:53PM +0800, Zhenyu Ye wrote:
>> @@ -190,8 +196,8 @@ static inline void flush_tlb_page_nosync(struct vm_area_struct *vma,
>> unsigned long addr = __TLBI_VADDR(uaddr, ASID(vma->vm_mm));
>>
>> dsb(ishst);
>> - __tlbi(vale1is, addr);
>> - __tlbi_user(vale1is, addr);
>> + __tlbi_level(vale1is, addr, 0);
>> + __tlbi_user_level(vale1is, addr, 0);
>> }
>
> This one remains with a level 0 throughout the series. Is this
> intentional? If we can't guarantee the level here, better to use the
> non-level __tlbi().
>
OK, I will change it back to non-level __tlbi().
Thanks,
Zhenyu
_______________________________________________
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 2/6] arm64: Add level-hinted TLB invalidation helper
From: Zhenyu Ye @ 2020-05-25 6:54 UTC (permalink / raw)
To: Catalin Marinas
Cc: mark.rutland, peterz, linux-mm, guohanjun, will, linux-arch,
yuzhao, aneesh.kumar, steven.price, arm, Dave.Martin, arnd,
suzuki.poulose, npiggin, zhangshaokun, broonie, rostedt,
prime.zeng, kuhn.chenqun, tglx, linux-arm-kernel, xiexiangyou,
linux-kernel, maz, akpm
In-Reply-To: <20200522155017.GG26492@gaia>
On 2020/5/22 23:50, Catalin Marinas wrote:
> On Thu, Apr 23, 2020 at 09:56:52PM +0800, Zhenyu Ye wrote:
>> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
>> index bc3949064725..5f9f189bc6d2 100644
>> --- a/arch/arm64/include/asm/tlbflush.h
>> +++ b/arch/arm64/include/asm/tlbflush.h
>> @@ -10,6 +10,7 @@
>>
>> #ifndef __ASSEMBLY__
>>
>> +#include <linux/bitfield.h>
>> #include <linux/mm_types.h>
>> #include <linux/sched.h>
>> #include <asm/cputype.h>
>> @@ -59,6 +60,35 @@
>> __ta; \
>> })
>>
>> +#define TLBI_TTL_MASK GENMASK_ULL(47, 44)
>> +
>> +#define __tlbi_level(op, addr, level) \
>> + do { \
>
> Nitpick: move "do {" on the same line as __tlbi_level() to reduce the
> indentation levels of the whole block.
>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
>
OK.
_______________________________________________
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