* [linux-sunxi] [PATCH 1/7] pinctrl: sunxi: add support for pin controllers without bus gate
From: Icenowy Zheng @ 2018-01-11 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111104100.j5rwitma3wgtdivm@flea.lan>
? 2018?1?11???? CST ??6:41:00?Maxime Ripard ???
> On Thu, Jan 11, 2018 at 10:23:52AM +0000, Andre Przywara wrote:
> > Hi,
> >
> > On 11/01/18 10:14, Chen-Yu Tsai wrote:
> > > On Thu, Jan 11, 2018 at 6:08 PM, Andre Przywara <andre.przywara@arm.com>
wrote:
> > >> Hi,
> > >>
> > >> On 06/01/18 04:23, Icenowy Zheng wrote:
> > >>> The Allwinner H6 pin controllers (both the main one and the CPUs one)
> > >>> have no bus gate clocks.
> > >>>
> > >>> Add support for this kind of pin controllers.
> > >>>
> > >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > >>> ---
> > >>>
> > >>> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 30
> > >>> ++++++++++++++++++++----------
> > >>> drivers/pinctrl/sunxi/pinctrl-sunxi.h | 1 +
> > >>> 2 files changed, 21 insertions(+), 10 deletions(-)
> > >>>
> > >>> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> > >>> b/drivers/pinctrl/sunxi/pinctrl-sunxi.c index
> > >>> 4b6cb25bc796..68cd505679d9 100644
> > >>> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> > >>> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> > >>> @@ -1182,7 +1182,12 @@ static int sunxi_pinctrl_setup_debounce(struct
> > >>> sunxi_pinctrl *pctl,> >>>
> > >>> unsigned int hosc_div, losc_div;
> > >>> struct clk *hosc, *losc;
> > >>> u8 div, src;
> > >>>
> > >>> - int i, ret;
> > >>> + int i, ret, clk_count;
> > >>> +
> > >>> + if (pctl->desc->without_bus_gate)
> > >>> + clk_count = 2;
> > >>> + else
> > >>> + clk_count = 3;
> > >>>
> > >>> /* Deal with old DTs that didn't have the oscillators */
> > >>> if (of_count_phandle_with_args(node, "clocks", "#clock-cells")
> > >>> != 3)
> > >>>
> > >>> @@ -1360,15 +1365,19 @@ int sunxi_pinctrl_init_with_variant(struct
> > >>> platform_device *pdev,> >>>
> > >>> goto gpiochip_error;
> > >>>
> > >>> }
> > >>>
> > >>> - clk = devm_clk_get(&pdev->dev, NULL);
> > >>> - if (IS_ERR(clk)) {
> > >>> - ret = PTR_ERR(clk);
> > >>> - goto gpiochip_error;
> > >>> - }
> > >>> + if (!desc->without_bus_gate) {
> > >>
> > >> Do we really need explicit support for that case?
> > >> Can't we have something that works automatically?
> > >>
> > >> if (node has clock-names property) (A)
> > >>
> > >> use clocks as enumerated and named there
> > >
> > > You still need to know if the hardware has a bus gate or not.
> > > If it's missing, and it's disabled, you end up with unusable
> > > hardware.
> >
> > Yes. So what? If you have a broken DT, it will not work. Just don't do
> > it. I don't understand why we want to defend against this case.
>
> This is not the point, but rather: if we have a way to detect easily
> that the device tree is missing a property that is missing in our
> binding, why shouldn't we do it?
>
> We're already doing it for reg and interrupts for example, why not for
> the clocks?
>
> > > Unless you are fully trusting the device tree to be correct.
> >
> > Sorry, but what else do we trust?
> >
> > > IMHO that makes for hard to find bugs during SoC bringup.
> >
> > I am not sure if that is really an issue. I would expect people
> > doing SoC bringup to be able to cope with those kinds of problems.
>
> Riiiight, because it worked so well in the past. We definitely didn't
> overlooked some clocks used for debouncing in this particular driver,
> or some to get the timekeeping right in the RTC.
>
> The argument that "anyone who codes in the kernel should just know
> better" doesn't work, on multiple levels. Because anyone that actually
> knows better can make a mistake or overlook some feature (because you
> didn't have your morning coffee yet, or because it was undocumented)
> and because you just make someone that doesn't feel bad.
I agree it here -- when I'm doing initial trial on H6 I didn't found that apb
gate is missing ;-)
>
> So, yes, we cannot not trust the device tree. But if we have a way to
> detect simple mistakes in the binding, we should also do it.
>
> Maxime
^ permalink raw reply
* net-next/master boot bisection: v4.15-rc7-1221-g45f8982 on sama53d #4343-staging
From: Guillaume Tucker @ 2018-01-11 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1961011202.207.1515665766663.JavaMail.jenkins@ip-172-30-0-246>
Please see below - the kernelci.org automated bisection tool has
found this commit caused a boot failure on one platform in the
Free Electrons lab. Several bisections pointed to the same
commit over the past couple of days, with various kernel configs.
More details about the boot failure can be found here:
https://staging.kernelci.org/boot/all/job/net-next/branch/master/kernel/v4.15-rc5-999-gfea23fb-lava-bisect-v2-b-staging-4343-8/
Full boot log:
http://staging-storage.kernelci.org/net-next/master/v4.15-rc5-999-gfea23fb-lava-bisect-v2-b-staging-4343-8/arm/multi_v7_defconfig/lab-free-electrons-dev/boot-at91-sama5d3_xplained.html
It looks like a network interface initialisation error on this
platform. I haven't investigated any further and the automated
bisection tool is still experimental, so please take this with a
pinch of salt and sorry if this patch isn't the actual culprit.
Hope this helps!
Guillaume
On 11/01/18 10:16, kernelci.org bot wrote:
> Bisection result for net-next/master (v4.15-rc7-1221-g45f8982) on sama53d
>
> Good known revision:
>
> 72bca20 liquidio: Use zeroing memory allocator than allocator/memset
>
> Bad known revision:
>
> 45f8982 Merge branch 'hns3-next'
>
> Extra parameters:
>
> Tree: net-next
> URL: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
> Branch: master
> Target: sama53d
> Lab: lab-free-electrons
> Defconfig: multi_v7_defconfig
> Plan: boot
>
>
> Breaking commit found:
>
> -------------------------------------------------------------------------------
> commit fea23fb591cce99546baca043d2a068228e87a79
> Author: Russell King <rmk+kernel@armlinux.org.uk>
> Date: Tue Jan 2 10:58:58 2018 +0000
>
> net: phy: convert read-modify-write to phy_modify()
>
> Convert read-modify-write sequences in at803x, Marvell and core phylib
> to use phy_modify() to ensure safety.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
> index 1e190f3b..c271590 100644
> --- a/drivers/net/phy/at803x.c
> +++ b/drivers/net/phy/at803x.c
> @@ -215,34 +215,22 @@ static int at803x_suspend(struct phy_device *phydev)
> int value;
> int wol_enabled;
>
> - mutex_lock(&phydev->lock);
> -
> value = phy_read(phydev, AT803X_INTR_ENABLE);
> wol_enabled = value & AT803X_INTR_ENABLE_WOL;
>
> - value = phy_read(phydev, MII_BMCR);
> -
> if (wol_enabled)
> - value |= BMCR_ISOLATE;
> + value = BMCR_ISOLATE;
> else
> - value |= BMCR_PDOWN;
> + value = BMCR_PDOWN;
>
> - phy_write(phydev, MII_BMCR, value);
> -
> - mutex_unlock(&phydev->lock);
> + phy_modify(phydev, MII_BMCR, 0, value);
>
> return 0;
> }
>
> static int at803x_resume(struct phy_device *phydev)
> {
> - int value;
> -
> - value = phy_read(phydev, MII_BMCR);
> - value &= ~(BMCR_PDOWN | BMCR_ISOLATE);
> - phy_write(phydev, MII_BMCR, value);
> -
> - return 0;
> + return phy_modify(phydev, MII_BMCR, ~(BMCR_PDOWN | BMCR_ISOLATE), 0);
> }
>
> static int at803x_probe(struct phy_device *phydev)
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index ac39d90..2bd3896 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -471,7 +471,7 @@ static int m88e1121_config_aneg(struct phy_device *phydev)
>
> if (phy_interface_is_rgmii(phydev)) {
> err = m88e1121_config_aneg_rgmii_delays(phydev);
> - if (err)
> + if (err < 0)
> return err;
> }
>
> @@ -664,19 +664,14 @@ static int m88e1116r_config_init(struct phy_device *phydev)
>
> static int m88e3016_config_init(struct phy_device *phydev)
> {
> - int reg;
> + int ret;
>
> /* Enable Scrambler and Auto-Crossover */
> - reg = phy_read(phydev, MII_88E3016_PHY_SPEC_CTRL);
> - if (reg < 0)
> - return reg;
> -
> - reg &= ~MII_88E3016_DISABLE_SCRAMBLER;
> - reg |= MII_88E3016_AUTO_MDIX_CROSSOVER;
> -
> - reg = phy_write(phydev, MII_88E3016_PHY_SPEC_CTRL, reg);
> - if (reg < 0)
> - return reg;
> + ret = phy_modify(phydev, MII_88E3016_PHY_SPEC_CTRL,
> + ~MII_88E3016_DISABLE_SCRAMBLER,
> + MII_88E3016_AUTO_MDIX_CROSSOVER);
> + if (ret < 0)
> + return ret;
>
> return marvell_config_init(phydev);
> }
> @@ -685,42 +680,34 @@ static int m88e1111_config_init_hwcfg_mode(struct phy_device *phydev,
> u16 mode,
> int fibre_copper_auto)
> {
> - int temp;
> -
> - temp = phy_read(phydev, MII_M1111_PHY_EXT_SR);
> - if (temp < 0)
> - return temp;
> -
> - temp &= ~(MII_M1111_HWCFG_MODE_MASK |
> - MII_M1111_HWCFG_FIBER_COPPER_AUTO |
> - MII_M1111_HWCFG_FIBER_COPPER_RES);
> - temp |= mode;
> -
> if (fibre_copper_auto)
> - temp |= MII_M1111_HWCFG_FIBER_COPPER_AUTO;
> + mode |= MII_M1111_HWCFG_FIBER_COPPER_AUTO;
>
> - return phy_write(phydev, MII_M1111_PHY_EXT_SR, temp);
> + return phy_modify(phydev, MII_M1111_PHY_EXT_SR,
> + (u16)~(MII_M1111_HWCFG_MODE_MASK |
> + MII_M1111_HWCFG_FIBER_COPPER_AUTO |
> + MII_M1111_HWCFG_FIBER_COPPER_RES),
> + mode);
> }
>
> static int m88e1111_config_init_rgmii_delays(struct phy_device *phydev)
> {
> - int temp;
> -
> - temp = phy_read(phydev, MII_M1111_PHY_EXT_CR);
> - if (temp < 0)
> - return temp;
> + int delay;
>
> if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
> - temp |= (MII_M1111_RGMII_RX_DELAY | MII_M1111_RGMII_TX_DELAY);
> + delay = MII_M1111_RGMII_RX_DELAY | MII_M1111_RGMII_TX_DELAY;
> } else if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
> - temp &= ~MII_M1111_RGMII_TX_DELAY;
> - temp |= MII_M1111_RGMII_RX_DELAY;
> + delay = MII_M1111_RGMII_RX_DELAY;
> } else if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
> - temp &= ~MII_M1111_RGMII_RX_DELAY;
> - temp |= MII_M1111_RGMII_TX_DELAY;
> + delay = MII_M1111_RGMII_TX_DELAY;
> + } else {
> + delay = 0;
> }
>
> - return phy_write(phydev, MII_M1111_PHY_EXT_CR, temp);
> + return phy_modify(phydev, MII_M1111_PHY_EXT_CR,
> + (u16)~(MII_M1111_RGMII_RX_DELAY |
> + MII_M1111_RGMII_TX_DELAY),
> + delay);
> }
>
> static int m88e1111_config_init_rgmii(struct phy_device *phydev)
> @@ -766,7 +753,7 @@ static int m88e1111_config_init_rtbi(struct phy_device *phydev)
> int err;
>
> err = m88e1111_config_init_rgmii_delays(phydev);
> - if (err)
> + if (err < 0)
> return err;
>
> err = m88e1111_config_init_hwcfg_mode(
> @@ -793,7 +780,7 @@ static int m88e1111_config_init(struct phy_device *phydev)
>
> if (phy_interface_is_rgmii(phydev)) {
> err = m88e1111_config_init_rgmii(phydev);
> - if (err)
> + if (err < 0)
> return err;
> }
>
> @@ -834,7 +821,6 @@ static int m88e1121_config_init(struct phy_device *phydev)
> static int m88e1510_config_init(struct phy_device *phydev)
> {
> int err;
> - int temp;
>
> /* SGMII-to-Copper mode initialization */
> if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
> @@ -846,16 +832,15 @@ static int m88e1510_config_init(struct phy_device *phydev)
> return err;
>
> /* In reg 20, write MODE[2:0] = 0x1 (SGMII to Copper) */
> - temp = phy_read(phydev, MII_88E1510_GEN_CTRL_REG_1);
> - temp &= ~MII_88E1510_GEN_CTRL_REG_1_MODE_MASK;
> - temp |= MII_88E1510_GEN_CTRL_REG_1_MODE_SGMII;
> - err = phy_write(phydev, MII_88E1510_GEN_CTRL_REG_1, temp);
> + err = phy_modify(phydev, MII_88E1510_GEN_CTRL_REG_1,
> + ~MII_88E1510_GEN_CTRL_REG_1_MODE_MASK,
> + MII_88E1510_GEN_CTRL_REG_1_MODE_SGMII);
> if (err < 0)
> return err;
>
> /* PHY reset is necessary after changing MODE[2:0] */
> - temp |= MII_88E1510_GEN_CTRL_REG_1_RESET;
> - err = phy_write(phydev, MII_88E1510_GEN_CTRL_REG_1, temp);
> + err = phy_modify(phydev, MII_88E1510_GEN_CTRL_REG_1, 0,
> + MII_88E1510_GEN_CTRL_REG_1_RESET);
> if (err < 0)
> return err;
>
> @@ -961,7 +946,6 @@ static int m88e1149_config_init(struct phy_device *phydev)
>
> static int m88e1145_config_init_rgmii(struct phy_device *phydev)
> {
> - int temp;
> int err;
>
> err = m88e1111_config_init_rgmii_delays(phydev);
> @@ -973,15 +957,9 @@ static int m88e1145_config_init_rgmii(struct phy_device *phydev)
> if (err < 0)
> return err;
>
> - temp = phy_read(phydev, 0x1e);
> - if (temp < 0)
> - return temp;
> -
> - temp &= 0xf03f;
> - temp |= 2 << 9; /* 36 ohm */
> - temp |= 2 << 6; /* 39 ohm */
> -
> - err = phy_write(phydev, 0x1e, temp);
> + err = phy_modify(phydev, 0x1e, 0xf03f,
> + 2 << 9 | /* 36 ohm */
> + 2 << 6); /* 39 ohm */
> if (err < 0)
> return err;
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index be13b5d..2c5b2e0 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1368,9 +1368,8 @@ static int genphy_config_eee_advert(struct phy_device *phydev)
> */
> int genphy_setup_forced(struct phy_device *phydev)
> {
> - int ctl = phy_read(phydev, MII_BMCR);
> + u16 ctl = 0;
>
> - ctl &= BMCR_LOOPBACK | BMCR_ISOLATE | BMCR_PDOWN;
> phydev->pause = 0;
> phydev->asym_pause = 0;
>
> @@ -1382,7 +1381,8 @@ int genphy_setup_forced(struct phy_device *phydev)
> if (DUPLEX_FULL == phydev->duplex)
> ctl |= BMCR_FULLDPLX;
>
> - return phy_write(phydev, MII_BMCR, ctl);
> + return phy_modify(phydev, MII_BMCR,
> + BMCR_LOOPBACK | BMCR_ISOLATE | BMCR_PDOWN, ctl);
> }
> EXPORT_SYMBOL(genphy_setup_forced);
>
> @@ -1392,17 +1392,9 @@ EXPORT_SYMBOL(genphy_setup_forced);
> */
> int genphy_restart_aneg(struct phy_device *phydev)
> {
> - int ctl = phy_read(phydev, MII_BMCR);
> -
> - if (ctl < 0)
> - return ctl;
> -
> - ctl |= BMCR_ANENABLE | BMCR_ANRESTART;
> -
> /* Don't isolate the PHY if we're negotiating */
> - ctl &= ~BMCR_ISOLATE;
> -
> - return phy_write(phydev, MII_BMCR, ctl);
> + return phy_modify(phydev, MII_BMCR, ~BMCR_ISOLATE,
> + BMCR_ANENABLE | BMCR_ANRESTART);
> }
> EXPORT_SYMBOL(genphy_restart_aneg);
>
> @@ -1668,44 +1660,20 @@ EXPORT_SYMBOL(genphy_config_init);
>
> int genphy_suspend(struct phy_device *phydev)
> {
> - int value;
> -
> - mutex_lock(&phydev->lock);
> -
> - value = phy_read(phydev, MII_BMCR);
> - phy_write(phydev, MII_BMCR, value | BMCR_PDOWN);
> -
> - mutex_unlock(&phydev->lock);
> -
> - return 0;
> + return phy_modify(phydev, MII_BMCR, 0, BMCR_PDOWN);
> }
> EXPORT_SYMBOL(genphy_suspend);
>
> int genphy_resume(struct phy_device *phydev)
> {
> - int value;
> -
> - value = phy_read(phydev, MII_BMCR);
> - phy_write(phydev, MII_BMCR, value & ~BMCR_PDOWN);
> -
> - return 0;
> + return phy_modify(phydev, MII_BMCR, ~BMCR_PDOWN, 0);
> }
> EXPORT_SYMBOL(genphy_resume);
>
> int genphy_loopback(struct phy_device *phydev, bool enable)
> {
> - int value;
> -
> - value = phy_read(phydev, MII_BMCR);
> - if (value < 0)
> - return value;
> -
> - if (enable)
> - value |= BMCR_LOOPBACK;
> - else
> - value &= ~BMCR_LOOPBACK;
> -
> - return phy_write(phydev, MII_BMCR, value);
> + return phy_modify(phydev, MII_BMCR, ~BMCR_LOOPBACK,
> + enable ? BMCR_LOOPBACK : 0);
> }
> EXPORT_SYMBOL(genphy_loopback);
> -------------------------------------------------------------------------------
>
>
> Git bisection log:
>
> -------------------------------------------------------------------------------
> git bisect start
> # good: [72bca2084a21edda74b802bc076083d5951f67b4] liquidio: Use zeroing memory allocator than allocator/memset
> git bisect good 72bca2084a21edda74b802bc076083d5951f67b4
> # bad: [45f8982253ad3fd314e3580cb9209183ea3faa71] Merge branch 'hns3-next'
> git bisect bad 45f8982253ad3fd314e3580cb9209183ea3faa71
> # good: [44596f86826df00ab3ab1086b25f3cdcc11156a1] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
> git bisect good 44596f86826df00ab3ab1086b25f3cdcc11156a1
> # bad: [0befd061af59c4ba426588930f09eb9ea2475534] netfilter: nf_tables: remove nft_dereference()
> git bisect bad 0befd061af59c4ba426588930f09eb9ea2475534
> # bad: [d0adb51edb73c94a595bfa9d9bd8b35977e74fbf] nfp: add basic multicast filtering
> git bisect bad d0adb51edb73c94a595bfa9d9bd8b35977e74fbf
> # bad: [8a4816cad00bf14642f0ed6043b32d29a05006ce] tg3: Add Macronix NVRAM support
> git bisect bad 8a4816cad00bf14642f0ed6043b32d29a05006ce
> # good: [34dc08e4be208539b7c4aa8154a610e1736705e8] net: mdiobus: add unlocked accessors
> git bisect good 34dc08e4be208539b7c4aa8154a610e1736705e8
> # bad: [ee7e16b66a766e8f922aafe5edf9353b9f37a424] net: mdio: Only perform gpio reset for PHYs
> git bisect bad ee7e16b66a766e8f922aafe5edf9353b9f37a424
> # good: [424ca4c5512173e42b4086322dafd33ee882baf3] net: phy: marvell: fix paged access races
> git bisect good 424ca4c5512173e42b4086322dafd33ee882baf3
> # bad: [fea23fb591cce99546baca043d2a068228e87a79] net: phy: convert read-modify-write to phy_modify()
> git bisect bad fea23fb591cce99546baca043d2a068228e87a79
> # good: [2b74e5be17d25fbca4be236a19efcd2ecae81cb2] net: phy: add phy_modify() accessor
> git bisect good 2b74e5be17d25fbca4be236a19efcd2ecae81cb2
> # first bad commit: [fea23fb591cce99546baca043d2a068228e87a79] net: phy: convert read-modify-write to phy_modify()
> -------------------------------------------------------------------------------
>
^ permalink raw reply
* [RFC PATCH 0/2] drivers: clk: Add ZynqMP clock driver support
From: Sudeep Holla @ 2018-01-11 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515449797-5629-1-git-send-email-jollys@xilinx.com>
On 08/01/18 22:16, Jolly Shah wrote:
> Add clock driver for ZynqMP
>
Can you post the complete series in one set for easy of review. It's
currently broken into *6 - 8* different sets by different authors and
it's extremely hard to get the full view of how these pieces are
connected and extremely misleading. Can someone post them collectively
as you would already have it if you are doing some testing building on
each patch set.
IIUC mailbox is used for all the communication, right ?
If so, to start with just have 2 series one for mailbox/transport and
another for the whole protocol(eemi?) and users of it.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH -next] ASoC: stm32: fix a typo in stm32_adfsdm_probe()
From: Wei Yongjun @ 2018-01-11 11:11 UTC (permalink / raw)
To: linux-arm-kernel
Fix a typo, we should return PTR_ERR(priv->iio_cb) instead of
PTR_ERR(priv->iio_ch).
Fixes: 55da094824c4 ("ASoC: stm32: add DFSDM DAI support")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
sound/soc/stm/stm32_adfsdm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/stm/stm32_adfsdm.c b/sound/soc/stm/stm32_adfsdm.c
index af50891..7306e3e 100644
--- a/sound/soc/stm/stm32_adfsdm.c
+++ b/sound/soc/stm/stm32_adfsdm.c
@@ -320,7 +320,7 @@ static int stm32_adfsdm_probe(struct platform_device *pdev)
priv->iio_cb = iio_channel_get_all_cb(&pdev->dev, NULL, NULL);
if (IS_ERR(priv->iio_cb))
- return PTR_ERR(priv->iio_ch);
+ return PTR_ERR(priv->iio_cb);
ret = devm_snd_soc_register_platform(&pdev->dev,
&stm32_adfsdm_soc_platform);
^ permalink raw reply related
* [PATCH -next] IIO: ADC: fix return value check in stm32_dfsdm_adc_probe()
From: Wei Yongjun @ 2018-01-11 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In case of error, the function devm_iio_device_alloc() returns NULL
pointer not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.
Fixes: e2e6771c6462 ("IIO: ADC: add STM32 DFSDM sigma delta ADC support")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/iio/adc/stm32-dfsdm-adc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
index e628d04..5e87140 100644
--- a/drivers/iio/adc/stm32-dfsdm-adc.c
+++ b/drivers/iio/adc/stm32-dfsdm-adc.c
@@ -1100,9 +1100,9 @@ static int stm32_dfsdm_adc_probe(struct platform_device *pdev)
dev_data = (const struct stm32_dfsdm_dev_data *)of_id->data;
iio = devm_iio_device_alloc(dev, sizeof(*adc));
- if (IS_ERR(iio)) {
+ if (!iio) {
dev_err(dev, "%s: Failed to allocate IIO\n", __func__);
- return PTR_ERR(iio);
+ return -ENOMEM;
}
adc = iio_priv(iio);
^ permalink raw reply related
* [PATCH 1/9] iommu/of: Drop early initialisation hooks
From: JeffyChen @ 2018-01-11 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <60fdd375-ca74-0fea-c598-39a68b9e7735@samsung.com>
Hi Marek,
Thanks for your reply.
On 01/11/2018 05:40 PM, Marek Szyprowski wrote:
> Hi Jeffy,
>
> On 2018-01-11 09:22, Jeffy Chen wrote:
>> With the probe-deferral mechanism, early initialisation hooks are no
>> longer needed.
>>
>> Suggested-by: Robin Murphy <robin.murphy@arm.com>
>> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
>> ---
>>
>> drivers/iommu/arm-smmu-v3.c | 2 +-
>> drivers/iommu/arm-smmu.c | 12 ++++++------
>> drivers/iommu/exynos-iommu.c | 2 +-
>
> For Exynos IOMMU:
> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
> IPMMU and MSM IOMMU are no longer multi-platform safe after this patch.
> It breaks them in the same way as my commit 928055a01b3f ("iommu/exynos:
> Remove custom platform device registration code") broke Exynos IOMMU.
>
> You need a similar fix for them:
> https://www.spinics.net/lists/arm-kernel/msg627648.html
hmmm, right, i did saw this fix in the rockchip iommu driver too.
and there're also some other iommu drivers put bus_set_iommu in their
probe() to avoid that.
maybe we can do it in the iommu framework?
for example:
1/ add a bus type member to struct iommu_device
2/ and a iommu_device_set_bus()
3/ do the bus_set_iommu stuff in iommu_device_register()
4/ undo bus_set_iommu in iommu_device_unregister()
^ permalink raw reply
* [PATCH v3 0/7] Marvell NAND controller rework with ->exec_op()
From: Boris Brezillon @ 2018-01-11 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109103637.23798-1-miquel.raynal@free-electrons.com>
On Tue, 9 Jan 2018 11:36:30 +0100
Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
> Hi,
>
> After the addition of the NAND framework ->exec_op() interface (see [1]
> for the series preparing it and [2] for the last version of the
> core-side implementation of ->exec_op() itself), this series replaces
> the current Marvell NAND controller driver pxa3xx_nand.c with a rework
> called marvell_nand.c.
>
> Aside the fact that it drops the big state machine, improves the overall
> speed and implements raw accesses, it is the first driver-side
> implementation of the ->exec_op() interface and may be used as reference
> for latter reworks of the same type.
>
> One may find more detail about why a completely new driver is needed in
> the commit log of:
>
> "mtd: nand: add reworked Marvell NAND controller driver"
>
> Device tree NAND node definition for all platforms referring to the
> Marvell driver using the new bindings have already been accepted by the
> MVEBU DT maintainers and will be merged after the driver. They are more
> hierarchical and fit the real organization of the hardware, by having
> NAND partitions that are part of NAND chip nodes, themselves part of the
> NAND controller node.
>
> These changes have been tested on:
> - PXA3xx platform with a CM-X300 board (2kiB page NAND, 1b/512B
> strength, Hamming ECC engine) [32 bits]
> - Armada 385 DB AP (4kiB page NAND, 4b/512B, BCH ECC engine) [32 bits]
> - Armada 398 DB (4kiB page NAND, 8b/512B, BCH ECC engine using a layout
> with a last chunk different than the others) [32 bits]
> - Armada 7040 DB and Armada 8040 DB (4kiB page NAND, 4b/512B, BCH ECC
> engine) [64 bits]
> - Triax dvb-tc board (2kiB page NAND, 4b/512B, BCH ECC engine) [32 bits]
>
> This version is known not to be stable yet with a Zylonite based setup but
> otherwise looks good for Marvell EBU platforms.
So, here is the plan: since the driver has been tested on various mvebu
platforms and is known to work fine on these platforms, I'd like to
queue the driver and the patch modifying mvebu defconfigs (patches 1 to
4) for 4.16.
I'll leave other patches for 4.17, which means I'd like remaining bugs
to be fixed during the 4.16 release cycle so that we can eventually get
rid of the old driver. That's really important to me that we don't keep
both drivers around for too long, because my previous experience showed
that, when you have 2 drivers for the same HW, people don't switch to
the new one until they're forced to do it.
Robert, are you fine with this approach? What about the tests you were
doing? Did you make any progress? Did you find other issues?
>
> For people who would like to test it easily, a branch ready to be tested
> is available at [3]. It is based on nand/next and has all the changes
> brought by the previously mentionned series as well as this one.
>
> Thank you,
> Miqu?l
>
>
> [1] https://www.spinics.net/lists/arm-kernel/msg619633.html
> [2] http://lists.infradead.org/pipermail/linux-mtd/2017-December/077965.html
> [3] https://github.com/miquelraynal/linux/tree/marvell/nand-next/nfc
>
>
> Changes since v2:
> - Added a patch to create the nand-rb property in the Documentation
> - Rewording in the Documentation according to Rob's comments
> - Moved from marvell,rb to nand-rb property in the code
> - Disociated using this driver with Marvell EBU platforms than using
> it with PXA ones
> - Fixed the handling of 16-bit buses
> - Fixed SPDX comment style
> - Reorganized registers offsets/bit fields definitions as requested
> - Moved to Kernel doc
> - Changed the logic in ->select_chip() to use a prepared value of NDCR
> only instead of recalculating it
> - Fixed the presence of the SPARE_EN bit, reworked a bit the
> hmg_do_read/write() helpers
> - Fixed the OOB layouts that were unusable (all spare data first, then
> all ECC bytes)
> - Additional check on mtd->writesize when using NFCv1 (all sizes not
> supported)
> - Various typos/rewording
>
> Changes since v1:
> - Rewording
> - Fixed BCH ->read/write_page() hooks for 2kiB pages NAND chips
> - Removed license text, used SPDX tag instead
> - Removed read_page_data()
> - Enhanced the DT bindings document with the label property and the
> deprecated bindings.
> - Simplified the read_chunk() helper (OOB always read).
> - Simplified the ->bch_read_page() hook by removing the addition raw
> read to get ECC bytes.
> - Fixed the ->correct() function that did not check for bitflips in
> ECC bytes in erased pages.
>
>
> Miquel Raynal (7):
> dt-bindings: mtd: document new nand-rb property
> dt-bindings: mtd: add Marvell NAND controller documentation
> mtd: nand: add reworked Marvell NAND controller driver
> mtd: nand: use reworked NAND controller driver with Marvell EBU SoCs
> mtd: nand: use Marvell reworked NAND controller driver with all
> platforms
> dt-bindings: mtd: remove pxa3xx NAND controller documentation
> mtd: nand: remove useless fields from pxa3xx NAND platform data
>
> .../devicetree/bindings/mtd/marvell-nand.txt | 123 +
> Documentation/devicetree/bindings/mtd/nand.txt | 1 +
> .../devicetree/bindings/mtd/pxa3xx-nand.txt | 50 -
> arch/arm/configs/cm_x300_defconfig | 2 +-
> arch/arm/configs/mvebu_v7_defconfig | 2 +-
> arch/arm/configs/pxa3xx_defconfig | 3 +-
> arch/arm/configs/pxa_defconfig | 2 +-
> arch/arm/configs/raumfeld_defconfig | 2 +-
> arch/arm/mach-mmp/ttc_dkb.c | 4 +-
> arch/arm/mach-pxa/cm-x300.c | 8 +-
> arch/arm/mach-pxa/colibri-pxa3xx.c | 8 +-
> arch/arm/mach-pxa/colibri.h | 2 +-
> arch/arm/mach-pxa/littleton.c | 10 +-
> arch/arm/mach-pxa/mxm8x10.c | 10 +-
> arch/arm/mach-pxa/raumfeld.c | 6 +-
> arch/arm/mach-pxa/zylonite.c | 10 +-
> arch/arm64/configs/defconfig | 2 +-
> drivers/mtd/nand/Kconfig | 18 +-
> drivers/mtd/nand/Makefile | 2 +-
> drivers/mtd/nand/marvell_nand.c | 2896 ++++++++++++++++++++
> drivers/mtd/nand/pxa3xx_nand.c | 2104 --------------
> include/linux/platform_data/mtd-nand-pxa3xx.h | 43 +-
> 22 files changed, 3072 insertions(+), 2236 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mtd/marvell-nand.txt
> delete mode 100644 Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
> create mode 100644 drivers/mtd/nand/marvell_nand.c
> delete mode 100644 drivers/mtd/nand/pxa3xx_nand.c
>
^ permalink raw reply
* [PATCH v1 0/4] pwm support for allwinner sun8i R40/V40/T3 SOCs.
From: hao_zhang @ 2018-01-11 11:31 UTC (permalink / raw)
To: linux-arm-kernel
This patchset add pwm support for allwinner sun8i R40/V40/T3 SOCs.
Beause of my mistake, previous patch set from v4.
this patch set i resend it from v1 and fix some error.
PATCH LOG:
[v4,1/4] dt-bindings: pwm: binding allwinner sun8i R40/V40/T3.
https://patchwork.kernel.org/patch/10110177/
[v4,2/4] ARM: PWM: add allwinner sun8i R40/V40/T3 pwm support.
https://patchwork.kernel.org/patch/10110185/
[v4,3/4] ARM: dts: add pwm node for r40.
https://patchwork.kernel.org/patch/10110191/
Fixed:
1.change readl/writel to regmap.
2.undo the previous polarity, do clk_disable_unprepare()
and unlock spinlock while error return.
Regards,
Hao Zhang
hao_zhang (4):
dt-bindings: pwm: binding allwinner sun8i R40/V40/T3.
ARM: PWM: add allwinner sun8i R40/V40/T3 pwm support.
ARM: dts: add pwm pins for r40.
ARM: dts: add pwm node for r40.
.../devicetree/bindings/pwm/pwm-sun8i.txt | 18 +
arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 6 +
arch/arm/boot/dts/sun8i-r40.dtsi | 13 +
drivers/pwm/Kconfig | 10 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-sun8i-r40.c | 394 +++++++++++++++++++++
6 files changed, 442 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sun8i.txt
create mode 100644 drivers/pwm/pwm-sun8i-r40.c
--
2.7.4
^ permalink raw reply
* [PATCH v1 1/4] dt-bindings: pwm: binding allwinner sun8i R40/V40/T3.
From: hao_zhang @ 2018-01-11 11:31 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds allwinner R40, V40, T3 pwm binding documents.
Signed-off-by: hao_zhang <hao5781286@gmail.com>
---
Documentation/devicetree/bindings/pwm/pwm-sun8i.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sun8i.txt
diff --git a/Documentation/devicetree/bindings/pwm/pwm-sun8i.txt b/Documentation/devicetree/bindings/pwm/pwm-sun8i.txt
new file mode 100644
index 0000000..2c86c67
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-sun8i.txt
@@ -0,0 +1,18 @@
+Allwinner sun8i R40/V40/T3 SoC PWM controller
+
+Required properties:
+ - compatible: should be one of:
+ - "allwinner,sun8i-r40-pwm"
+ - reg: physical base address and length of the controller's registers
+ - #pwm-cells: should be 3. See pwm.txt in this directory for a description of
+ the cells format.
+ - clocks: From common clock binding, handle to the parent clock.
+
+Example:
+
+pwm: pwm at 1c23400 {
+ compatible = "allwinner,sun8i-r40-pwm";
+ reg = <0x01c23400 0x154>;
+ clocks = <&osc24M>;
+ #pwm-cells = <3>;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64: kdump: retain reserved memory regions
From: AKASHI Takahiro @ 2018-01-11 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9QX-r7Q5Dsze6MYRb8hbRyq=C__3BsZTBvvSyv1Y-KMg@mail.gmail.com>
On Wed, Jan 10, 2018 at 11:09:32AM +0000, Ard Biesheuvel wrote:
> On 10 January 2018 at 10:09, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> > This is a fix against the issue that crash dump kernel may hang up
> > during booting, which can happen on any ACPI-based system with "ACPI
> > Reclaim Memory."
> >
> > <kicking off kdump after panic>
> > Bye!
> > (snip...)
> > ACPI: Core revision 20170728
> > pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707
> > Internal error: Oops: 96000021 [#1] SMP
> > Modules linked in:
> > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
> > task: ffff000008d05180 task.stack: ffff000008cc0000
> > PC is at acpi_ns_lookup+0x25c/0x3c0
> > LR is at acpi_ds_load1_begin_op+0xa4/0x294
> > (snip...)
> > Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000)
> > Call trace:
> > (snip...)
> > [<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0
> > [<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294
> > [<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198
> > [<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270
> > [<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8
> > [<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8
> > [<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184
> > [<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68
> > [<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc
> > [<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264
> > [<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0
> > [<ffff000008badc20>] acpi_early_init+0x9c/0xd0
> > [<ffff000008b70d50>] start_kernel+0x3b4/0x43c
> > Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
> > ---[ end trace c46ed37f9651c58e ]---
> > Kernel panic - not syncing: Fatal exception
> > Rebooting in 10 seconds..
> >
> > (diagnosis)
> > * This fault is a data abort, alignment fault (ESR=0x96000021)
> > during reading out ACPI table.
> > * Initial ACPI tables are normally stored in system ram and marked as
> > "ACPI Reclaim memory" by the firmware.
> > * After the commit f56ab9a5b73c ("efi/arm: Don't mark ACPI reclaim
> > memory as MEMBLOCK_NOMAP"), those regions' attribute were changed
> > removing NOMAP bit and they are instead "memblock-reserved".
> > * When crash dump kernel boots up, it tries to accesses ACPI tables by
> > ioremap'ing them (through acpi_os_ioremap()).
> > * Since those regions are not included in device tree's
> > "usable-memory-range" and so not recognized as part of crash dump
> > kernel's system ram, ioremap() will create a non-cacheable mapping here.
> > * ACPI accessor/helper functions are compiled in without unaligned access
> > support (ACPI_MISALIGNMENT_NOT_SUPPORTED), eventually ending up a fatal
> > panic when accessing ACPI tables.
> >
> > With this patch, all the reserved memory regions, as well as NOMAP-
> > attributed ones which are presumably ACPI runtime code and data, are set
> > to be retained in system ram even if they are outside of usable memory
> > range specified by device tree blob. Accordingly, ACPI tables are mapped
> > as cacheable and can be safely accessed without causing unaligned access
> > faults.
> >
> > Reported-by: Bhupesh Sharma <bhsharma@redhat.com>
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > ---
> > arch/arm64/mm/init.c | 16 ++++++++++++++--
> > 1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 2d5a443b205c..e4a8b64a09b1 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -352,11 +352,23 @@ static void __init fdt_enforce_memory_region(void)
> > struct memblock_region reg = {
> > .size = 0,
> > };
> > + u64 idx;
> > + phys_addr_t start, end;
> >
> > of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> >
> > - if (reg.size)
> > - memblock_cap_memory_range(reg.base, reg.size);
>
> Given that memblock_cap_memory_range() was introduced by you for
> kdump, is there any way to handle it there?
Indeed, but I'm not sure that the new semantics of this function
is quite generic.
> If not, should we remove it?
I prefer to remove it.
Thanks,
-Takahiro AKASHI
> > + if (reg.size) {
> > +retry:
> > + /* exclude usable & !reserved memory */
> > + for_each_free_mem_range(idx, NUMA_NO_NODE, MEMBLOCK_NONE,
> > + &start, &end, NULL) {
> > + memblock_remove(start, end - start);
> > + goto retry;
> > + }
> > +
> > + /* add back fdt's usable memory */
> > + memblock_add(reg.base, reg.size);
> > + }
> > }
> >
> > void __init arm64_memblock_init(void)
> > --
> > 2.15.1
> >
^ permalink raw reply
* [PATCH v1 2/4] ARM: PWM: add allwinner sun8i R40/V40/T3 pwm support.
From: hao_zhang @ 2018-01-11 11:32 UTC (permalink / raw)
To: linux-arm-kernel
This patch add allwinner sun8i R40/V40/T3 pwm support.
Signed-off-by: hao_zhang <hao5781286@gmail.com>
---
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-sun8i-r40.c | 394 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 405 insertions(+)
create mode 100644 drivers/pwm/pwm-sun8i-r40.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 763ee50..cde5a70 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -444,6 +444,16 @@ config PWM_SUN4I
To compile this driver as a module, choose M here: the module
will be called pwm-sun4i.
+config PWM_SUN8I_R40
+ tristate "Allwinner PWM SUN8I R40 support"
+ depends on ARCH_SUNXI || COMPILE_TEST
+ depends on HAS_IOMEM && COMMON_CLK
+ help
+ Generic PWM framework driver for Allwinner SoCs R40, V40, T3.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-sun8i-r40.
+
config PWM_TEGRA
tristate "NVIDIA Tegra PWM support"
depends on ARCH_TEGRA
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 0258a74..026a55b 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_PWM_STM32) += pwm-stm32.o
obj-$(CONFIG_PWM_STM32_LP) += pwm-stm32-lp.o
obj-$(CONFIG_PWM_STMPE) += pwm-stmpe.o
obj-$(CONFIG_PWM_SUN4I) += pwm-sun4i.o
+obj-$(CONFIG_PWM_SUN8I_R40) += pwm-sun8i-r40.o
obj-$(CONFIG_PWM_TEGRA) += pwm-tegra.o
obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
diff --git a/drivers/pwm/pwm-sun8i-r40.c b/drivers/pwm/pwm-sun8i-r40.c
new file mode 100644
index 0000000..3d34285
--- /dev/null
+++ b/drivers/pwm/pwm-sun8i-r40.c
@@ -0,0 +1,394 @@
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/time.h>
+#include <linux/regmap.h>
+
+#define PWM_IRQ_ENABLE_REG 0x0000
+#define PCIE(ch) BIT(ch)
+
+#define PWM_IRQ_STATUS_REG 0x0004
+#define PIS(ch) BIT(ch)
+
+#define CAPTURE_IRQ_ENABLE_REG 0x0010
+#define CFIE(ch) BIT(ch << 1 + 1)
+#define CRIE(ch) BIT(ch << 1)
+
+#define CAPTURE_IRQ_STATUS_REG 0x0014
+#define CFIS(ch) BIT(ch << 1 + 1)
+#define CRIS(ch) BIT(ch << 1)
+
+#define CLK_CFG_REG(ch) (0x0020 + (ch >> 1) * 4)
+#define CLK_SRC BIT(7)
+#define CLK_SRC_BYPASS_SEC BIT(6)
+#define CLK_SRC_BYPASS_FIR BIT(5)
+#define CLK_GATING BIT(4)
+#define CLK_DIV_M GENMASK(3, 0)
+
+#define PWM_DZ_CTR_REG(ch) (0x0030 + (ch >> 1) * 4)
+#define PWM_DZ_INTV GENMASK(15, 8)
+#define PWM_DZ_EN BIT(0)
+
+#define PWM_ENABLE_REG 0x0040
+#define PWM_EN(ch) BIT(ch)
+
+#define CAPTURE_ENABLE_REG 0x0044
+#define CAP_EN(ch) BIT(ch)
+
+#define PWM_CTR_REG(ch) (0x0060 + ch * 0x20)
+#define PWM_PERIOD_RDY BIT(11)
+#define PWM_PUL_START BIT(10)
+#define PWM_MODE BIT(9)
+#define PWM_ACT_STA BIT(8)
+#define PWM_PRESCAL_K GENMASK(7, 0)
+
+#define PWM_PERIOD_REG(ch) (0x0064 + ch * 0x20)
+#define PWM_ENTIRE_CYCLE GENMASK(31, 16)
+#define PWM_ACT_CYCLE GENMASK(15, 0)
+
+#define PWM_CNT_REG(ch) (0x0068 + ch * 0x20)
+#define PWM_CNT_VAL GENMASK(15, 0)
+
+#define CAPTURE_CTR_REG(ch) (0x006c + ch * 0x20)
+#define CAPTURE_CRLF BIT(2)
+#define CAPTURE_CFLF BIT(1)
+#define CAPINV BIT(0)
+
+#define CAPTURE_RISE_REG(ch) (0x0070 + ch * 0x20)
+#define CAPTURE_CRLR GENMASK(15, 0)
+
+#define CAPTURE_FALL_REG(ch) (0x0074 + ch * 0x20)
+#define CAPTURE_CFLR GENMASK(15, 0)
+
+struct sun8i_pwm_data {
+ bool has_prescaler_bypass;
+ bool has_rdy;
+ unsigned int npwm;
+};
+
+struct sun8i_pwm_chip {
+ struct pwm_chip chip;
+ struct clk *clk;
+ void __iomem *base;
+ spinlock_t ctrl_lock;
+ const struct sun8i_pwm_data *data;
+ struct regmap *regmap;
+};
+
+static const u16 div_m_table[] = {
+ 1,
+ 2,
+ 4,
+ 8,
+ 16,
+ 32,
+ 64,
+ 128,
+ 256
+};
+
+static inline struct sun8i_pwm_chip *to_sun8i_pwm_chip(struct pwm_chip *chip)
+{
+ return container_of(chip, struct sun8i_pwm_chip, chip);
+}
+
+static u32 sun8i_pwm_read(struct sun8i_pwm_chip *sun8i_pwm,
+ unsigned long offset)
+{
+ u32 val;
+
+ regmap_read(sun8i_pwm->regmap, offset, &val);
+
+ return val;
+}
+
+static inline void sun8i_pwm_set_bit(struct sun8i_pwm_chip *sun8i_pwm,
+ unsigned long reg, u32 bit)
+{
+ regmap_update_bits(sun8i_pwm->regmap, reg, bit, bit);
+}
+
+static inline void sun8i_pwm_clear_bit(struct sun8i_pwm_chip *sun8i_pwm,
+ unsigned long reg, u32 bit)
+{
+ regmap_update_bits(sun8i_pwm->regmap, reg, bit, 0);
+}
+
+static inline void sun8i_pwm_set_value(struct sun8i_pwm_chip *sun8i_pwm,
+ unsigned long reg, u32 mask, u32 val)
+{
+ regmap_update_bits(sun8i_pwm->regmap, reg, mask, val);
+}
+
+static void sun8i_pwm_set_polarity(struct sun8i_pwm_chip *chip, u32 ch,
+ enum pwm_polarity polarity)
+{
+ if (polarity == PWM_POLARITY_NORMAL)
+ sun8i_pwm_set_bit(chip, PWM_CTR_REG(ch), PWM_ACT_STA);
+ else
+ sun8i_pwm_clear_bit(chip, PWM_CTR_REG(ch), PWM_ACT_STA);
+}
+
+static int sun8i_pwm_config(struct sun8i_pwm_chip *sun8i_pwm, u8 ch,
+ struct pwm_state *state)
+{
+ u64 clk_rate, clk_div, val;
+ u16 prescaler = 0;
+ u8 id = 0;
+
+ clk_rate = clk_get_rate(sun8i_pwm->clk);
+
+ if (clk_rate == 24000000)
+ sun8i_pwm_clear_bit(sun8i_pwm, CLK_CFG_REG(ch), CLK_SRC);
+ else
+ sun8i_pwm_set_bit(sun8i_pwm, CLK_CFG_REG(ch), CLK_SRC);
+
+ if (sun8i_pwm->data->has_prescaler_bypass) {
+ /* pwm output bypass */
+ if (ch % 2)
+ sun8i_pwm_set_bit(sun8i_pwm, CLK_CFG_REG(ch),
+ CLK_SRC_BYPASS_FIR);
+ else
+ sun8i_pwm_set_bit(sun8i_pwm, CLK_CFG_REG(ch),
+ CLK_SRC_BYPASS_SEC);
+ return 0;
+ }
+
+ val = state->period * clk_rate;
+ do_div(val, NSEC_PER_SEC);
+ if (val < 1) {
+ dev_err(sun8i_pwm->chip.dev,
+ "period expects a larger value\n");
+ return -EINVAL;
+ }
+
+ /* calculate and set prescalar, div table, pwn entrie cycle */
+ clk_div = val;
+
+ while (clk_div > 65535) {
+ prescaler++;
+ clk_div = val;
+ do_div(clk_div, prescaler + 1);
+ do_div(clk_div, div_m_table[id]);
+
+ if (prescaler == 255) {
+ prescaler = 0;
+ id++;
+ if (id == 9)
+ return -EINVAL;
+ }
+ }
+
+ sun8i_pwm_set_value(sun8i_pwm, PWM_PERIOD_REG(ch),
+ PWM_ENTIRE_CYCLE, clk_div << 16);
+ sun8i_pwm_set_value(sun8i_pwm, PWM_CTR_REG(ch),
+ PWM_PRESCAL_K, prescaler << 0);
+ sun8i_pwm_set_value(sun8i_pwm, CLK_CFG_REG(ch),
+ CLK_DIV_M, id << 0);
+
+ /* set duty cycle */
+ val = (prescaler + 1) * div_m_table[id] * clk_div;
+ val = state->period;
+ do_div(val, clk_div);
+ clk_div = state->duty_cycle;
+ do_div(clk_div, val);
+
+ sun8i_pwm_set_value(sun8i_pwm, PWM_PERIOD_REG(ch),
+ PWM_ACT_CYCLE, clk_div << 0);
+
+ return 0;
+}
+
+static int sun8i_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ int ret;
+ struct sun8i_pwm_chip *sun8i_pwm = to_sun8i_pwm_chip(chip);
+ struct pwm_state cstate;
+
+ pwm_get_state(pwm, &cstate);
+ if (!cstate.enabled) {
+ ret = clk_prepare_enable(sun8i_pwm->clk);
+ if (ret) {
+ dev_err(chip->dev, "failed to enable PWM clock\n");
+ return ret;
+ }
+ }
+
+ spin_lock(&sun8i_pwm->ctrl_lock);
+
+ if ((cstate.period != state->period) ||
+ (cstate.duty_cycle != state->duty_cycle)) {
+ ret = sun8i_pwm_config(sun8i_pwm, pwm->hwpwm, state);
+ if (ret) {
+ clk_disable_unprepare(sun8i_pwm->clk);
+ spin_unlock(&sun8i_pwm->ctrl_lock);
+ dev_err(chip->dev, "failed to config PWM\n");
+ return ret;
+ }
+ }
+
+ if (state->polarity != cstate.polarity)
+ sun8i_pwm_set_polarity(sun8i_pwm, pwm->hwpwm, state->polarity);
+
+ if (state->enabled) {
+ sun8i_pwm_set_bit(sun8i_pwm,
+ CLK_CFG_REG(pwm->hwpwm), CLK_GATING);
+
+ sun8i_pwm_set_bit(sun8i_pwm,
+ PWM_ENABLE_REG, PWM_EN(pwm->hwpwm));
+ } else {
+ sun8i_pwm_clear_bit(sun8i_pwm,
+ CLK_CFG_REG(pwm->hwpwm), CLK_GATING);
+
+ sun8i_pwm_clear_bit(sun8i_pwm,
+ PWM_ENABLE_REG, PWM_EN(pwm->hwpwm));
+ }
+
+ spin_unlock(&sun8i_pwm->ctrl_lock);
+
+ return 0;
+}
+
+static void sun8i_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct sun8i_pwm_chip *sun8i_pwm = to_sun8i_pwm_chip(chip);
+ u64 clk_rate, tmp;
+ u32 val;
+ u16 clk_div, act_cycle;
+ u8 prescal, id;
+
+ clk_rate = clk_get_rate(sun8i_pwm->clk);
+
+ val = sun8i_pwm_read(sun8i_pwm, PWM_CTR_REG(pwm->hwpwm));
+ if (PWM_ACT_STA & val)
+ state->polarity = PWM_POLARITY_NORMAL;
+ else
+ state->polarity = PWM_POLARITY_INVERSED;
+
+ prescal = PWM_PRESCAL_K & val;
+
+ val = sun8i_pwm_read(sun8i_pwm, PWM_ENABLE_REG);
+ if (PWM_EN(pwm->hwpwm) & val)
+ state->enabled = true;
+ else
+ state->enabled = false;
+
+ val = sun8i_pwm_read(sun8i_pwm, PWM_PERIOD_REG(pwm->hwpwm));
+ act_cycle = PWM_ACT_CYCLE & val;
+ clk_div = val >> 16;
+
+ val = sun8i_pwm_read(sun8i_pwm, CLK_CFG_REG(pwm->hwpwm));
+ id = CLK_DIV_M & val;
+
+ tmp = act_cycle * prescal * div_m_table[id] * NSEC_PER_SEC;
+ state->duty_cycle = DIV_ROUND_CLOSEST_ULL(tmp, clk_rate);
+ tmp = clk_div * prescal * div_m_table[id] * NSEC_PER_SEC;
+ state->period = DIV_ROUND_CLOSEST_ULL(tmp, clk_rate);
+}
+
+static const struct regmap_config sun8i_pwm_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = CAPTURE_FALL_REG(7),
+};
+
+static const struct pwm_ops sun8i_pwm_ops = {
+ .apply = sun8i_pwm_apply,
+ .get_state = sun8i_pwm_get_state,
+ .owner = THIS_MODULE,
+};
+
+static const struct sun8i_pwm_data sun8i_pwm_data_r40 = {
+ .has_prescaler_bypass = false,
+ .has_rdy = true,
+ .npwm = 8,
+};
+
+static const struct of_device_id sun8i_pwm_dt_ids[] = {
+ {
+ .compatible = "allwinner,sun8i-r40-pwm",
+ .data = &sun8i_pwm_data_r40,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, sun8i_pwm_dt_ids);
+
+static int sun8i_pwm_probe(struct platform_device *pdev)
+{
+ struct sun8i_pwm_chip *pwm;
+ struct resource *res;
+ int ret;
+ const struct of_device_id *match;
+
+ match = of_match_device(sun8i_pwm_dt_ids, &pdev->dev);
+
+ pwm = devm_kzalloc(&pdev->dev, sizeof(*pwm), GFP_KERNEL);
+ if (!pwm)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ pwm->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(pwm->base))
+ return PTR_ERR(pwm->base);
+
+ pwm->regmap = devm_regmap_init_mmio(&pdev->dev, pwm->base,
+ &sun8i_pwm_regmap_config);
+
+ pwm->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(pwm->clk))
+ return PTR_ERR(pwm->clk);
+
+ pwm->data = match->data;
+ pwm->chip.dev = &pdev->dev;
+ pwm->chip.ops = &sun8i_pwm_ops;
+ pwm->chip.base = -1;
+ pwm->chip.npwm = pwm->data->npwm;
+ pwm->chip.of_xlate = of_pwm_xlate_with_flags;
+ pwm->chip.of_pwm_n_cells = 3;
+
+ spin_lock_init(&pwm->ctrl_lock);
+
+ ret = pwmchip_add(&pwm->chip);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to add PWM chip: %d\n", ret);
+ return ret;
+ }
+
+ platform_set_drvdata(pdev, pwm);
+
+ return 0;
+}
+
+static int sun8i_pwm_remove(struct platform_device *pdev)
+{
+ struct sun8i_pwm_chip *pwm = platform_get_drvdata(pdev);
+
+ return pwmchip_remove(&pwm->chip);
+}
+
+static struct platform_driver sun8i_pwm_driver = {
+ .driver = {
+ .name = "sun8i-r40-pwm",
+ .of_match_table = sun8i_pwm_dt_ids,
+ },
+ .probe = sun8i_pwm_probe,
+ .remove = sun8i_pwm_remove,
+};
+module_platform_driver(sun8i_pwm_driver);
+
+MODULE_ALIAS("platform:sun8i-r40-pwm");
+MODULE_AUTHOR("Hao Zhang <hao5781286@gmail.com>");
+MODULE_DESCRIPTION("Allwinner sun8i-r40 PWM driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH v1 3/4] ARM: dts: add pwm pins for r40.
From: hao_zhang @ 2018-01-11 11:33 UTC (permalink / raw)
To: linux-arm-kernel
This patch add pwm pins for r40.
Signed-off-by: hao_zhang <hao5781286@gmail.com>
---
arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
index 8c5efe2..6cf6273 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -196,6 +196,12 @@
status = "okay";
};
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm_pins>;
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.7.4
^ permalink raw reply related
* [PATCH v1 4/4] ARM: dts: add pwm node for r40.
From: hao_zhang @ 2018-01-11 11:34 UTC (permalink / raw)
To: linux-arm-kernel
This patch add pwm node for r40.
Signed-off-by: hao_zhang <hao5781286@gmail.com>
---
arch/arm/boot/dts/sun8i-r40.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index 173dcc1..84c963c 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -295,6 +295,11 @@
bias-pull-up;
};
+ pwm_pins: pwm-pins {
+ pins = "PB2", "PB3";
+ function = "pwm";
+ };
+
uart0_pb_pins: uart0-pb-pins {
pins = "PB22", "PB23";
function = "uart0";
@@ -306,6 +311,14 @@
reg = <0x01c20c90 0x10>;
};
+ pwm: pwm at 1c23400 {
+ compatible = "allwinner,sun8i-r40-pwm";
+ reg = <0x01c23400 0x154>;
+ clocks = <&osc24M>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
uart0: serial at 1c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64: kdump: retain reserved memory regions
From: AKASHI Takahiro @ 2018-01-11 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A55F87F.2080501@arm.com>
James,
On Wed, Jan 10, 2018 at 11:26:55AM +0000, James Morse wrote:
> Hi Akashi,
>
> On 10/01/18 10:09, AKASHI Takahiro wrote:
> > This is a fix against the issue that crash dump kernel may hang up
> > during booting, which can happen on any ACPI-based system with "ACPI
> > Reclaim Memory."
> >
> > <kicking off kdump after panic>
> > Bye!
> > (snip...)
> > ACPI: Core revision 20170728
> > pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707
> > Internal error: Oops: 96000021 [#1] SMP
> > Modules linked in:
> > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
> > task: ffff000008d05180 task.stack: ffff000008cc0000
> > PC is at acpi_ns_lookup+0x25c/0x3c0
> > LR is at acpi_ds_load1_begin_op+0xa4/0x294
> > (snip...)
> > Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000)
> > Call trace:
> > (snip...)
> > [<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0
> > [<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294
> > [<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198
> > [<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270
> > [<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8
> > [<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8
> > [<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184
> > [<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68
> > [<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc
> > [<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264
> > [<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0
> > [<ffff000008badc20>] acpi_early_init+0x9c/0xd0
> > [<ffff000008b70d50>] start_kernel+0x3b4/0x43c
> > Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
> > ---[ end trace c46ed37f9651c58e ]---
> > Kernel panic - not syncing: Fatal exception
> > Rebooting in 10 seconds..
> >
> > (diagnosis)
> > * This fault is a data abort, alignment fault (ESR=0x96000021)
> > during reading out ACPI table.
> > * Initial ACPI tables are normally stored in system ram and marked as
> > "ACPI Reclaim memory" by the firmware.
> > * After the commit f56ab9a5b73c ("efi/arm: Don't mark ACPI reclaim
> > memory as MEMBLOCK_NOMAP"), those regions' attribute were changed
> > removing NOMAP bit and they are instead "memblock-reserved".
> > * When crash dump kernel boots up, it tries to accesses ACPI tables by
> > ioremap'ing them (through acpi_os_ioremap()).
> > * Since those regions are not included in device tree's
> > "usable-memory-range" and so not recognized as part of crash dump
> > kernel's system ram, ioremap() will create a non-cacheable mapping here.
>
> Ugh, because acpi_os_ioremap() looks at the efi memory map through the prism of
> what we pulled into memblock, which is different during kdump.
>
> Is an alternative to teach acpi_os_ioremap() to ask
> efi_mem_attributes() directly for the attributes to use?
> (e.g. arch_apei_get_mem_attribute())
I didn't think of this approach.
Do you mean a change like the patch below?
(I'm still debugging this code since the kernel fails to boot.)
Thanks,
-Takahiro AKASHI
>
> > * ACPI accessor/helper functions are compiled in without unaligned access
> > support (ACPI_MISALIGNMENT_NOT_SUPPORTED), eventually ending up a fatal
> > panic when accessing ACPI tables.
> >
> > With this patch, all the reserved memory regions, as well as NOMAP-
> > attributed ones which are presumably ACPI runtime code and data, are set
> > to be retained in system ram even if they are outside of usable memory
> > range specified by device tree blob. Accordingly, ACPI tables are mapped
> > as cacheable and can be safely accessed without causing unaligned access
> > faults.
>
>
> Thanks,
>
> James
===8<===
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 32f465a80e4e..6953aaaf2bfa 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -16,6 +16,7 @@
#include <linux/psci.h>
#include <asm/cputype.h>
+#include <asm/io.h>
#include <asm/smp_plat.h>
#include <asm/tlbflush.h>
@@ -29,18 +30,13 @@
/* Basic configuration for ACPI */
#ifdef CONFIG_ACPI
+pgprot_t __acpi_get_mem_attribute(phys_addr_t addr);
+
/* ACPI table mapping after acpi_permanent_mmap is set */
static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
acpi_size size)
{
- /*
- * EFI's reserve_regions() call adds memory with the WB attribute
- * to memblock via early_init_dt_add_memory_arch().
- */
- if (!memblock_is_memory(phys))
- return ioremap(phys, size);
-
- return ioremap_cache(phys, size);
+ return __ioremap(phys, size, __acpi_get_mem_attribute(phys));
}
#define acpi_os_ioremap acpi_os_ioremap
@@ -125,7 +121,10 @@ static inline const char *acpi_get_enable_method(int cpu)
* for compatibility.
*/
#define acpi_disable_cmcff 1
-pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
+static inline pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+{
+ return __acpi_get_mem_attribute(addr);
+}
#endif /* CONFIG_ACPI_APEI */
#ifdef CONFIG_ACPI_NUMA
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index b3162715ed78..43e9d8371f88 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -239,8 +239,7 @@ void __init acpi_boot_table_init(void)
}
}
-#ifdef CONFIG_ACPI_APEI
-pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+pgprot_t __acpi_get_mem_attribute(phys_addr_t addr)
{
/*
* According to "Table 8 Map: EFI memory types to AArch64 memory
@@ -261,4 +260,3 @@ pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
return __pgprot(PROT_NORMAL_NC);
return __pgprot(PROT_DEVICE_nGnRnE);
}
-#endif
^ permalink raw reply related
* [linux-sunxi] [PATCH 1/7] pinctrl: sunxi: add support for pin controllers without bus gate
From: Andre Przywara @ 2018-01-11 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111104100.j5rwitma3wgtdivm@flea.lan>
Hi,
On 11/01/18 10:41, Maxime Ripard wrote:
> On Thu, Jan 11, 2018 at 10:23:52AM +0000, Andre Przywara wrote:
>> Hi,
>>
>> On 11/01/18 10:14, Chen-Yu Tsai wrote:
>>> On Thu, Jan 11, 2018 at 6:08 PM, Andre Przywara <andre.przywara@arm.com> wrote:
>>>> Hi,
>>>>
>>>> On 06/01/18 04:23, Icenowy Zheng wrote:
>>>>> The Allwinner H6 pin controllers (both the main one and the CPUs one)
>>>>> have no bus gate clocks.
>>>>>
>>>>> Add support for this kind of pin controllers.
>>>>>
>>>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>>>>> ---
>>>>> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 30 ++++++++++++++++++++----------
>>>>> drivers/pinctrl/sunxi/pinctrl-sunxi.h | 1 +
>>>>> 2 files changed, 21 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
>>>>> index 4b6cb25bc796..68cd505679d9 100644
>>>>> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
>>>>> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
>>>>> @@ -1182,7 +1182,12 @@ static int sunxi_pinctrl_setup_debounce(struct sunxi_pinctrl *pctl,
>>>>> unsigned int hosc_div, losc_div;
>>>>> struct clk *hosc, *losc;
>>>>> u8 div, src;
>>>>> - int i, ret;
>>>>> + int i, ret, clk_count;
>>>>> +
>>>>> + if (pctl->desc->without_bus_gate)
>>>>> + clk_count = 2;
>>>>> + else
>>>>> + clk_count = 3;
>>>>>
>>>>> /* Deal with old DTs that didn't have the oscillators */
>>>>> if (of_count_phandle_with_args(node, "clocks", "#clock-cells") != 3)
>>>>> @@ -1360,15 +1365,19 @@ int sunxi_pinctrl_init_with_variant(struct platform_device *pdev,
>>>>> goto gpiochip_error;
>>>>> }
>>>>>
>>>>> - clk = devm_clk_get(&pdev->dev, NULL);
>>>>> - if (IS_ERR(clk)) {
>>>>> - ret = PTR_ERR(clk);
>>>>> - goto gpiochip_error;
>>>>> - }
>>>>> + if (!desc->without_bus_gate) {
>>>>
>>>> Do we really need explicit support for that case?
>>>> Can't we have something that works automatically?
>>>>
>>>> if (node has clock-names property) (A)
>>>> use clocks as enumerated and named there
>>>
>>> You still need to know if the hardware has a bus gate or not.
>>> If it's missing, and it's disabled, you end up with unusable
>>> hardware.
>>
>> Yes. So what? If you have a broken DT, it will not work. Just don't do
>> it. I don't understand why we want to defend against this case.
>
> This is not the point, but rather: if we have a way to detect easily
> that the device tree is missing a property that is missing in our
> binding, why shouldn't we do it?
>
> We're already doing it for reg and interrupts for example, why not for
> the clocks?
>
>>> Unless you are fully trusting the device tree to be correct.
>>
>> Sorry, but what else do we trust?
>>
>>> IMHO that makes for hard to find bugs during SoC bringup.
>>
>> I am not sure if that is really an issue. I would expect people
>> doing SoC bringup to be able to cope with those kinds of problems.
>
> Riiiight, because it worked so well in the past. We definitely didn't
> overlooked some clocks used for debouncing in this particular driver,
> or some to get the timekeeping right in the RTC.
I think that's a different issue, because debouncing is an optional
feature. How would those kind of explicit molly guards here have
prevented this omission in the past, when we only discovered that later?
> The argument that "anyone who codes in the kernel should just know
> better" doesn't work, on multiple levels. Because anyone that actually
> knows better can make a mistake or overlook some feature (because you
> didn't have your morning coffee yet, or because it was undocumented)
> and because you just make someone that doesn't feel bad.
I agree to that. But: If something doesn't work, checking clocks and
reset would be my first impulse. And Icenowy did exactly that and
quickly found it.
Plus this only protects against known pitfalls.
> So, yes, we cannot not trust the device tree. But if we have a way to
> detect simple mistakes in the binding, we should also do it.
I totally honour that, I am just wondering what price we pay for that.
This kind of: "We need three clocks here, or wait, two clock in this
particular case" sounds a bit dodgy and little future proof to me.
Which is somewhat confirmed by the fact that we need to adjust this
check now. So I suggest we remove it, as we have more, actual checks
afterwards anyway. That should cover future extensions without further ado:
The clock-names property should cater nicely for those cases, hence my
suggestion to rely on it. Plus we need to support the legacy DTs with
just a single clock and no clock-names. Done.
So I think we should change the devm_get_clk(..., NULL) to
devm_get_clk(..., "apb"), and then check for just a single unnamed clock
if that fails (older DTs), or no clock at all, if we need to support
future SoCs without debouncing.
Looking deeper I actually think we are not binding compliant at the
moment, as we rely on the "apb" clock to be the first one, however
clock-names = "hosc", "losc", "apb" would be perfectly legal as well, as
we don't document a certain order of the clock - which is not necessary
with clock-names.
I can make a patch if we agree on that.
Cheers,
Andre.
^ permalink raw reply
* [linux-sunxi] [PATCH 1/7] pinctrl: sunxi: add support for pin controllers without bus gate
From: Andre Przywara @ 2018-01-11 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106042326.46519-1-icenowy@aosc.io>
Hi,
another take to avoid this patch at all, I just remembered this from an
IRC discussion before:
On 06/01/18 04:23, Icenowy Zheng wrote:
> The Allwinner H6 pin controllers (both the main one and the CPUs one)
> have no bus gate clocks.
I don't think this is true. The pin controller *needs* an APB clock,
it's just not gate-able or not exposed or documented.
The "system bus tree" on page 90 in the manual shows that the "GPIO"
block is located on the APB1 bus.
So can't we just reference this apb clock directly? That would be much
cleaner, "more" correct and require less changes: "The best patch is no
patch":
clocks = <&ccu APB1>, <&osc24M>, <&osc32k>;
/* or whatever this APB clock is actually called. */
clock-names = "apb", "hosc", "losc";
Cheers,
Andre.
>
> Add support for this kind of pin controllers.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 30 ++++++++++++++++++++----------
> drivers/pinctrl/sunxi/pinctrl-sunxi.h | 1 +
> 2 files changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> index 4b6cb25bc796..68cd505679d9 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> @@ -1182,7 +1182,12 @@ static int sunxi_pinctrl_setup_debounce(struct sunxi_pinctrl *pctl,
> unsigned int hosc_div, losc_div;
> struct clk *hosc, *losc;
> u8 div, src;
> - int i, ret;
> + int i, ret, clk_count;
> +
> + if (pctl->desc->without_bus_gate)
> + clk_count = 2;
> + else
> + clk_count = 3;
>
> /* Deal with old DTs that didn't have the oscillators */
> if (of_count_phandle_with_args(node, "clocks", "#clock-cells") != 3)
> @@ -1360,15 +1365,19 @@ int sunxi_pinctrl_init_with_variant(struct platform_device *pdev,
> goto gpiochip_error;
> }
>
> - clk = devm_clk_get(&pdev->dev, NULL);
> - if (IS_ERR(clk)) {
> - ret = PTR_ERR(clk);
> - goto gpiochip_error;
> - }
> + if (!desc->without_bus_gate) {
> + clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + goto gpiochip_error;
> + }
>
> - ret = clk_prepare_enable(clk);
> - if (ret)
> - goto gpiochip_error;
> + ret = clk_prepare_enable(clk);
> + if (ret)
> + goto gpiochip_error;
> + } else {
> + clk = NULL;
> + }
>
> pctl->irq = devm_kcalloc(&pdev->dev,
> pctl->desc->irq_banks,
> @@ -1425,7 +1434,8 @@ int sunxi_pinctrl_init_with_variant(struct platform_device *pdev,
> return 0;
>
> clk_error:
> - clk_disable_unprepare(clk);
> + if (clk)
> + clk_disable_unprepare(clk);
> gpiochip_error:
> gpiochip_remove(pctl->chip);
> return ret;
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> index 11b128f54ed2..ccb6230f0bb5 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> @@ -113,6 +113,7 @@ struct sunxi_pinctrl_desc {
> unsigned irq_bank_base;
> bool irq_read_needs_mux;
> bool disable_strict_mode;
> + bool without_bus_gate;
> };
>
> struct sunxi_pinctrl_function {
>
^ permalink raw reply
* [PATCH v2 07/12] drm/sun4i: Add has_channel_0 TCON quirk
From: Maxime Ripard @ 2018-01-11 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110192512.19684-8-jernej.skrabec@siol.net>
On Wed, Jan 10, 2018 at 08:25:07PM +0100, Jernej Skrabec wrote:
> Some TCONs on newer SoCs doesn't support channel 0, since they are meant
> to be used only with TV or HDMI encoder.
>
> Prepare support for them with adding has_channel_0 quirk.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180111/3ff9eab4/attachment.sig>
^ permalink raw reply
* [PATCH v2 08/12] drm/sun4i: Add support for A83T second TCON
From: Maxime Ripard @ 2018-01-11 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110192512.19684-9-jernej.skrabec@siol.net>
On Wed, Jan 10, 2018 at 08:25:08PM +0100, Jernej Skrabec wrote:
> This TCON is connected to HDMI encoder.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180111/20acdf62/attachment.sig>
^ permalink raw reply
* [PATCH 00/10] perf tools: Add support for CoreSight trace decoding
From: Mark Brown @ 2018-01-11 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110180821.a92368599af8708790e0362b@arm.com>
On Wed, Jan 10, 2018 at 06:08:21PM -0600, Kim Phillips wrote:
> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> > Instructions on how to build and install the openCSD library are provided
> > in the HOWTO.md of the project repository.
> Usually when a perf builder sees something they need "on," they - or,
> at least I - start querying the host's package manager for something
> that provides it (e.g., apt search/install libopencsd), but since no
> distro provides libopencsd, this is bad because it misleads the user.
It's on the radar to push this at distros fairly soon. Part of the
discussion was wanting to get things to the point where the tools using
the library were far enough along that we could be reasonably sure that
there weren't any problems that were going to require ABI breaks to fix
before pushing the library at distros since ABI churn isn't nice for
packagers to deal with. There's also a bit of a chicken and egg problem
in that it's a lot easier to get distros to package libraries that have
users available (some are not really bothered about this of course but
it still helps).
> Keeping the library external will also inevitably introduce more
> source level synchronization problems because the perf sources being
> built may not be compatible with their version of the library, whether
> due to new features like new trace hardware support, or API changes.
Perf users installing from source rather than from a package (who do
tend to the more technical side even for kernel developers) already have
to cope with potentially installing at least dwarf, gtk2, libaudit,
libbfd, libelf, libnuma, libperl, libpython, libslang, libcrypto,
libunwind, libdw-dwarf-unwind, zlib, lzma, bpf and OpenJDK depending on
which features they want. I'm not sure that adding one more library is
going to be the end of the world here, especially once the packaging
starts to filter through distros. Until that happens at least people
are no worse off for not having the feature.
> As Mark Brown (cc'd) mentioned on the Coresight mailing list, this may
> be able to be done the same way the dtc is incorporated into the
> kernel, where only its relevant sources are included and updated as
> needed: see linux/scripts/dtc/update-dtc-source.sh.
Bear in mind that we need dtc for essentially all kernel development on
ARM and when it was introduced it was a new requirement for existing
systems, it's a bit of a different case here where it's an optional
feature in an optional tool.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180111/20414ad4/attachment.sig>
^ permalink raw reply
* [PATCH 1/9] iommu/of: Drop early initialisation hooks
From: Robin Murphy @ 2018-01-11 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A57471E.7020304@rock-chips.com>
Hi Jeffy,
On 11/01/18 11:14, JeffyChen wrote:
> Hi Marek,
>
> Thanks for your reply.
>
> On 01/11/2018 05:40 PM, Marek Szyprowski wrote:
>> Hi Jeffy,
>>
>> On 2018-01-11 09:22, Jeffy Chen wrote:
>>> With the probe-deferral mechanism, early initialisation hooks are no
>>> longer needed.
>>>
>>> Suggested-by: Robin Murphy <robin.murphy@arm.com>
In fact, shortly after I said that I had a "how hard can it be?" moment
and took a crack at it myself - sorry, I should probably have cc'd you
on that series[1].
>>> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
>>> ---
>>>
>>> ? drivers/iommu/arm-smmu-v3.c? |? 2 +-
>>> ? drivers/iommu/arm-smmu.c???? | 12 ++++++------
>>> ? drivers/iommu/exynos-iommu.c |? 2 +-
>>
>> For Exynos IOMMU:
>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>
>> IPMMU and MSM IOMMU are no longer multi-platform safe after this patch.
>> It breaks them in the same way as my commit 928055a01b3f ("iommu/exynos:
>> Remove custom platform device registration code") broke Exynos IOMMU.
>>
>> You need a similar fix for them:
>> https://www.spinics.net/lists/arm-kernel/msg627648.html
>
> hmmm, right, i did saw this fix in the rockchip iommu driver too.
>
> and there're also some other iommu drivers put bus_set_iommu in their
> probe() to avoid that.
>
> maybe we can do it in the iommu framework?
>
> for example:
> 1/ add a bus type member to struct iommu_device
> 2/ and a iommu_device_set_bus()
> 3/ do the bus_set_iommu stuff in iommu_device_register()
> 4/ undo bus_set_iommu in iommu_device_unregister()
Ultimately we'd like to get rid of the bus relationship altogether, so I
don't think it's really worth adding more infrastructure around it.
Having of-iommu-based drivers set bus ops at probe time, and others
conditionally from an initcall, is pretty clean and simple, so I'd
rather stick with that approach for now.
Robin.
[1]
https://lists.linuxfoundation.org/pipermail/iommu/2018-January/025395.html
^ permalink raw reply
* [PATCH v3 0/3] drm/sun4i: hdmi: Fix sun4i_tmds_determine_rate
From: Maxime Ripard @ 2018-01-11 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109020323.11852-1-net147@gmail.com>
On Tue, Jan 09, 2018 at 01:03:20PM +1100, Jonathan Liu wrote:
> This patchset fixes several issues in sun4i_tmds_determine_rate that I
> discovered while trying to get a projector connected to an Olimex
> A20-OLinuXino-LIME using HDMI with a native resolution of 1280x800 and
> pixel clock of 83.5 MHz to display at its native resolution.
Queued all three patches as fixes, thanks!
maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180111/6bfb307b/attachment-0001.sig>
^ permalink raw reply
* [PATCH 1/9] iommu/of: Drop early initialisation hooks
From: Marek Szyprowski @ 2018-01-11 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A57471E.7020304@rock-chips.com>
Hi Jeffy,
On 2018-01-11 12:14, JeffyChen wrote:
> Hi Marek,
>
> Thanks for your reply.
>
> On 01/11/2018 05:40 PM, Marek Szyprowski wrote:
>> Hi Jeffy,
>>
>> On 2018-01-11 09:22, Jeffy Chen wrote:
>>> With the probe-deferral mechanism, early initialisation hooks are no
>>> longer needed.
>>>
>>> Suggested-by: Robin Murphy <robin.murphy@arm.com>
>>> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
>>> ---
>>>
>>> ? drivers/iommu/arm-smmu-v3.c? |? 2 +-
>>> ? drivers/iommu/arm-smmu.c???? | 12 ++++++------
>>> ? drivers/iommu/exynos-iommu.c |? 2 +-
>>
>> For Exynos IOMMU:
>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>
>> IPMMU and MSM IOMMU are no longer multi-platform safe after this patch.
>> It breaks them in the same way as my commit 928055a01b3f ("iommu/exynos:
>> Remove custom platform device registration code") broke Exynos IOMMU.
>>
>> You need a similar fix for them:
>> https://www.spinics.net/lists/arm-kernel/msg627648.html
>
> hmmm, right, i did saw this fix in the rockchip iommu driver too.
>
> and there're also some other iommu drivers put bus_set_iommu in their
> probe() to avoid that.
>
> maybe we can do it in the iommu framework?
>
> for example:
> 1/ add a bus type member to struct iommu_device
> 2/ and a iommu_device_set_bus()
> 3/ do the bus_set_iommu stuff in iommu_device_register()
> 4/ undo bus_set_iommu in iommu_device_unregister()
Frankly, in case the device-tree based systems bus_set_iommu()
should not be needed at all. However for some legacy reasons it
is still required by a few bits of code (at least it was needed
some time ago). Probably it would be best if this is finally
resolved.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Applied "ASoC: stm32: fix a typo in stm32_adfsdm_probe()" to the asoc tree
From: Mark Brown @ 2018-01-11 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515669111-125208-1-git-send-email-weiyongjun1@huawei.com>
The patch
ASoC: stm32: fix a typo in stm32_adfsdm_probe()
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 6dee6722c6065f4850eab98c2b7b9f4a08a35813 Mon Sep 17 00:00:00 2001
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Thu, 11 Jan 2018 11:11:51 +0000
Subject: [PATCH] ASoC: stm32: fix a typo in stm32_adfsdm_probe()
Fix a typo, we should return PTR_ERR(priv->iio_cb) instead of
PTR_ERR(priv->iio_ch).
Fixes: 55da094824c4 ("ASoC: stm32: add DFSDM DAI support")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/stm/stm32_adfsdm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/stm/stm32_adfsdm.c b/sound/soc/stm/stm32_adfsdm.c
index af50891983c6..7306e3eca9e1 100644
--- a/sound/soc/stm/stm32_adfsdm.c
+++ b/sound/soc/stm/stm32_adfsdm.c
@@ -320,7 +320,7 @@ static int stm32_adfsdm_probe(struct platform_device *pdev)
priv->iio_cb = iio_channel_get_all_cb(&pdev->dev, NULL, NULL);
if (IS_ERR(priv->iio_cb))
- return PTR_ERR(priv->iio_ch);
+ return PTR_ERR(priv->iio_cb);
ret = devm_snd_soc_register_platform(&pdev->dev,
&stm32_adfsdm_soc_platform);
--
2.15.1
^ permalink raw reply related
* [GIT PULL] tee dynamic shm fixes for v4.16
From: Jens Wiklander @ 2018-01-11 12:44 UTC (permalink / raw)
To: linux-arm-kernel
Hello arm-soc maintainers,
Please pull these fixes for the previous tee-drv-dynamic-shm-for-v4.16
pull request that is currently kept in the drivers/tee-2 branch in the
arm-soc git.
This pull request addresses the question about registering memory that
isn't regular memory. I posted those patches some time ago with no feedback
so far.
There's also three small fixes to the dynamic shm patches that I've
picked up from the mailing lists.
Thanks,
Jens
The following changes since commit ef8e08d24ca84846ce639b835ebd2f15a943f42b:
tee: shm: inline tee_shm_get_id() (2017-12-15 13:36:21 +0100)
are available in the git repository at:
https://git.linaro.org/people/jens.wiklander/linux-tee.git tee-drv-dynamic-shm+fixes-for-v4.16
for you to fetch changes up to 2490cdf6435b1d3cac0dbf710cd752487c67c296:
tee: shm: Potential NULL dereference calling tee_shm_register() (2018-01-09 14:34:00 +0100)
----------------------------------------------------------------
This pull request updates the previous tee-drv-dynamic-shm-for-v4.16 pull
request with five new patches fixing review comments and errors.
Apart from three small fixes there's two larger patches that in the end
checks that memory to be registered really is normal cached memory.
----------------------------------------------------------------
Colin Ian King (2):
tee: shm: make function __tee_shm_alloc static
tee: shm: don't put_page on null shm->pages
Dan Carpenter (1):
tee: shm: Potential NULL dereference calling tee_shm_register()
Jens Wiklander (2):
tee: add start argument to shm_register callback
tee: optee: check type of registered shared memory
drivers/tee/optee/call.c | 50 +++++++++++++++++++++++++++++++++++----
drivers/tee/optee/optee_private.h | 6 +++--
drivers/tee/tee_shm.c | 18 +++++++-------
include/linux/tee_drv.h | 3 ++-
4 files changed, 62 insertions(+), 15 deletions(-)
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: Adam Ford @ 2018-01-11 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fd162516-cddc-e857-ce60-2cd89303971e@lechnology.com>
On Wed, Jan 10, 2018 at 8:50 PM, David Lechner <david@lechnology.com> wrote:
> On 01/10/2018 04:24 PM, Adam Ford wrote:
>>
>>
>> I am available tomorrow to build and test patches against the
>> da850-evm. I just need to know which version(s) to test.
>
>
> Great. As per the cover letter:
>
> You can find a working branch with everything included in the
> "common-clk-v5"
> branch of https://github.com/dlech/ev3dev-kernel.git.
I wasn't sure if things had changed after some of the dialog about the
bindings and device tree.
Here is my log with DEBUG_LL and CONFIG_EARLY_PRINTK set :
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
(Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
CST 2018
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
CPU: VIVT data cache, VIVT instruction cache
OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
Memory policy: Data cache writethrough
cma: Reserved 16 MiB at 0xc2c00000
DaVinci da850/omap-l138 variant 0x0
random: fast init done
Built 1 zonelists, mobility grouping on. Total pages: 16256
Kernel command line: console=ttyS2,115200n8 root=PARTUUID= rw
rootfstype=ext4 rootwait
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 42164K/65536K available (4548K kernel code, 280K rwdata, 1044K
rodata, 232K init, 143K bss, 6988K reserved, 16384K cma-reserved)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
vmalloc : 0xc4800000 - 0xff800000 ( 944 MB)
lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0x(ptrval) - 0x(ptrval) (4550 kB)
.init : 0x(ptrval) - 0x(ptrval) ( 232 kB)
.data : 0x(ptrval) - 0x(ptrval) ( 281 kB)
.bss : 0x(ptrval) - 0x(ptrval) ( 144 kB)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptible hierarchical RCU implementation.
Tasks RCU enabled.
NR_IRQS: 245
clocksource: timer0_1: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 79635851949 ns
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every
89478484971ns
Console: colour dummy device 80x30
Calibrating delay loop... 148.88 BogoMIPS (lpj=744448)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0xc0008400 - 0xc0008458
Hierarchical SRCU implementation.
devtmpfs: initialized
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 19112604462750000 ns
futex hash table entries: 256 (order: -1, 3072 bytes)
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor menu
mux: initialized RTC_ALARM
mux: Setting register RTC_ALARM
mux: PINMUX0 (0x00000000) = 0x44080000 -> 0x24080000
edma 1c00000.edma: memcpy is disabled
edma 1c00000.edma: TI EDMA DMA engine driver
edma 1e30000.edma: memcpy is disabled
edma 1e30000.edma: TI EDMA DMA engine driver
i2c_davinci 1c22000.i2c: could not find pctldev for node
/soc at 1c00000/pinmux at 14120/pinmux_i2c0_pins, deferring probe
clocksource: Switched to clocksource timer0_1
NET: Registered protocol family 2
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Initialise system trusted keyrings
workingset: timestamp_bits=30 max_order=14 bucket_order=0
Key type asymmetric registered
Asymmetric key parser 'x509' registered
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
io scheduler noop registered (default)
io scheduler mq-deadline registered
io scheduler kyber registered
pinctrl-single 1c14120.pinmux: 160 pins at pa fdfe34a6 size 80
Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
1c42000.serial: ttyS0 at MMIO 0x1c42000 (irq = 25, base_baud =
9375000) is a TI DA8xx/66AK2x
1d0c000.serial: ttyS1 at MMIO 0x1d0c000 (irq = 53, base_baud =
8250000) is a TI DA8xx/66AK2x
1d0d000.serial: ttyS2 at MMIO 0x1d0d000 (irq = 61, base_baud =
8250000) is a TI DA8xx/66AK2x
console [ttyS2] enabled
brd: module loaded
libphy: Fixed MDIO Bus: probed
davinci_mdio 1e24000.mdio: failed to get device clock
davinci_mdio: probe of 1e24000.mdio failed with error -2
i2c /dev entries driver
davinci_mmc 1c40000.mmc: Using DMA, 4-bit mode
NET: Registered protocol family 10
Segment Routing with IPv6
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
NET: Registered protocol family 17
Loading compiled-in X.509 certificates
mmc0: host does not support reading read-only switch, assuming
write-enable
mmc0: new high speed SDHC card at address b368
mmcblk0: mmc0:b368 00000 3.75 GiB
mmcblk0: p1 p2
pca953x 0-0020: 0-0020 supply vcc not found, using dummy regulator
pca953x 0-0020: failed reading register
pca953x: probe of 0-0020 failed with error -121
console [netcon0] enabled
netconsole: network logging started
davinci_emac 1e20000.ethernet: incompatible machine/device type for
reading mac address
hctosys: unable to open rtc device (rtc0)
>
^ 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