* [PATCH 0/3] MPU-3050 defconfig updates
From: Linus Walleij @ 2016-12-27 12:05 UTC (permalink / raw)
To: linux-arm-kernel
Here are three defconfig patches to the ARM SoC tree that replace
the use of the partial input driver for MPU-3050 with the fully featured
IIO replacement driver.
Please apply these directly for defconfig updates post-v4.10-rc1.
Linus Walleij (3):
ARM: defconfig: replace MPU3050 driver on multi_v7
ARM: defconfig: tegra: switch to MPU3050 IIO driver
ARM: defconfig: pxa: cut MPU3050 input driver
arch/arm/configs/multi_v7_defconfig | 4 +++-
arch/arm/configs/pxa_defconfig | 1 -
arch/arm/configs/tegra_defconfig | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH 1/3] ARM: defconfig: replace MPU3050 driver on multi_v7
From: Linus Walleij @ 2016-12-27 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161227120530.31190-1-linus.walleij@linaro.org>
The multi_v7 config enable the MPU3050 gyro input driver, but
there is now a dedicated IIO gyro driver for the same component,
which is the right subsystem to handle this. Replace it in the
defconfig. As we want the full IIO featureset and as other v7
systems will likely enjoy using IIO for their sensor work (such
as the Android-to-IIO userspace HAL), we take this opportunity to
turn on the standard sensor HRtimer triggering.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/configs/multi_v7_defconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index b01a43851294..a4607224289e 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -296,7 +296,6 @@ CONFIG_TOUCHSCREEN_WM97XX=m
CONFIG_INPUT_MISC=y
CONFIG_INPUT_MAX77693_HAPTIC=m
CONFIG_INPUT_MAX8997_HAPTIC=m
-CONFIG_INPUT_MPU3050=y
CONFIG_INPUT_AXP20X_PEK=m
CONFIG_INPUT_ADXL34X=m
CONFIG_SERIO_AMBAKMI=y
@@ -847,15 +846,18 @@ CONFIG_MEMORY=y
CONFIG_EXTCON=y
CONFIG_TI_AEMIF=y
CONFIG_IIO=y
+CONFIG_IIO_SW_TRIGGER=y
CONFIG_AT91_ADC=m
CONFIG_AT91_SAMA5D2_ADC=m
CONFIG_BERLIN2_ADC=m
CONFIG_EXYNOS_ADC=m
CONFIG_VF610_ADC=m
CONFIG_XILINX_XADC=y
+CONFIG_MPU3050_I2C=y
CONFIG_CM36651=m
CONFIG_AK8975=y
CONFIG_RASPBERRYPI_POWER=y
+CONFIG_IIO_HRTIMER_TRIGGER=y
CONFIG_PWM=y
CONFIG_PWM_ATMEL=m
CONFIG_PWM_ATMEL_HLCDC_PWM=m
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] ARM: defconfig: tegra: switch to MPU3050 IIO driver
From: Linus Walleij @ 2016-12-27 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161227120530.31190-1-linus.walleij@linaro.org>
The Tegra is currently configured to use the old input driver for the
MPU-3050. Switch to the new IIO driver.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/configs/tegra_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index 844eeef5a509..f0efc854b5a2 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -120,7 +120,6 @@ CONFIG_TOUCHSCREEN_WM97XX=y
# CONFIG_TOUCHSCREEN_WM9713 is not set
CONFIG_TOUCHSCREEN_STMPE=y
CONFIG_INPUT_MISC=y
-CONFIG_INPUT_MPU3050=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_DEVKMEM is not set
CONFIG_SERIAL_8250=y
@@ -263,6 +262,7 @@ CONFIG_ARCH_TEGRA_114_SOC=y
CONFIG_ARCH_TEGRA_124_SOC=y
CONFIG_MEMORY=y
CONFIG_IIO=y
+CONFIG_MPU3050_I2C=y
CONFIG_AK8975=y
CONFIG_PWM=y
CONFIG_PWM_TEGRA=y
--
2.9.3
^ permalink raw reply related
* [PATCH 3/3] ARM: defconfig: pxa: cut MPU3050 input driver
From: Linus Walleij @ 2016-12-27 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161227120530.31190-1-linus.walleij@linaro.org>
The PXA defconfig compiles the legacy MPU3050 driver as a module,
but the device does not appear in device trees nor board files, so
remove this from the defconfig assuming it was a mistake to add it
in the first place.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/configs/pxa_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig
index e4314b1227a3..ce4660c79c7a 100644
--- a/arch/arm/configs/pxa_defconfig
+++ b/arch/arm/configs/pxa_defconfig
@@ -334,7 +334,6 @@ CONFIG_TOUCHSCREEN_TOUCHIT213=m
CONFIG_TOUCHSCREEN_PCAP=m
CONFIG_TOUCHSCREEN_ST1232=m
CONFIG_INPUT_MISC=y
-CONFIG_INPUT_MPU3050=m
CONFIG_INPUT_AXP20X_PEK=m
CONFIG_INPUT_UINPUT=m
CONFIG_INPUT_GPIO_ROTARY_ENCODER=m
--
2.9.3
^ permalink raw reply related
* [PATCH V1] pinctrl:pxa:pinctrl-pxa2xx:- No need of devm functions
From: Linus Walleij @ 2016-12-27 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481207730-6332-1-git-send-email-arvind.yadav.cs@gmail.com>
On Thu, Dec 8, 2016 at 3:35 PM, Arvind Yadav <arvind.yadav.cs@gmail.com> wrote:
> In functions pxa2xx_build_functions, the memory allocated for
> 'functions' is live within the function only. After the
> allocation it is immediately freed with devm_kfree. There is
> no need to allocate memory for 'functions' with devm function
> so replace devm_kcalloc with kcalloc and devm_kfree with kfree.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
I want the maintainer Robert Jarzmik to review this before I do anything
with it.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/6] ARM: mach-mx31_3ds: Remove camera support
From: Fabio Estevam @ 2016-12-27 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAM=E1R4L+BtFqAdRCUFzaZLkuZ7+8KUxO9iTkDqRz94RrOrz0Q@mail.gmail.com>
Hi Magnus,
On Tue, Dec 27, 2016 at 8:05 AM, Magnus Lilja <lilja.magnus@gmail.com> wrote:
> CSI_D5 is marked as "not floating" by default, as opposed to "input,
> pulled up" on many other pins on the i.MX31. That makes me wonder if
> it's best to keep the initialization of CSI_D5 and RI_DTE1 to make
> sure the pins are set to a defined state (that also will set the
> camera off).
After this patch the camera will not be powered by the mc13783 PMIC
anymore, so I think it is safe to remove the code that handles the
camera GPIOs.
> Will test the patch on hardware in a couple of days.
Thanks!
^ permalink raw reply
* [PATCH v2 05/12] Document: dt: binding: imx: update pinctrl doc for imx6sll
From: Linus Walleij @ 2016-12-27 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482832070-22668-6-git-send-email-ping.bai@nxp.com>
On Tue, Dec 27, 2016 at 10:47 AM, Bai Ping <ping.bai@nxp.com> wrote:
> Add pinctrl binding doc update for imx6sll.
>
> Signed-off-by: Bai Ping <ping.bai@nxp.com>
I have to push back on this a bit.
> +Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
> +and usage.
I understand that it is building on top of the old i.MX bindings and that
it has some kind of "tradition" coming with it.
At the same time, the i.MX bindings came about before we had the
generic pin control bindings defined.
> +CONFIG bits definition:
> +PAD_CTL_LVE (1 << 22)
> +PAD_CTL_HYS (1 << 16)
> +PAD_CTL_PUS_100K_DOWN (0 << 14)
> +PAD_CTL_PUS_47K_UP (1 << 14)
> +PAD_CTL_PUS_100K_UP (2 << 14)
> +PAD_CTL_PUS_22K_UP (3 << 14)
> +PAD_CTL_PUE (1 << 13)
> +PAD_CTL_PKE (1 << 12)
> +PAD_CTL_ODE (1 << 11)
> +PAD_CTL_SPEED_LOW (0 << 6)
> +PAD_CTL_SPEED_MED (1 << 6)
> +PAD_CTL_SPEED_HIGH (3 << 6)
> +PAD_CTL_DSE_DISABLE (0 << 3)
> +PAD_CTL_DSE_260ohm (1 << 3)
> +PAD_CTL_DSE_130ohm (2 << 3)
> +PAD_CTL_DSE_87ohm (3 << 3)
> +PAD_CTL_DSE_65ohm (4 << 3)
> +PAD_CTL_DSE_52ohm (5 << 3)
> +PAD_CTL_DSE_43ohm (6 << 3)
> +PAD_CTL_DSE_37ohm (7 << 3)
> +PAD_CTL_SRE_FAST (1 << 0)
> +PAD_CTL_SRE_SLOW (0 << 0)
A whole slew of these if not all correspond to the generic bindings.
I would consider augmenting the code in the driver to handle the generic
bindings *in addition* to the old legacy bindings, and use those over these
random custom bits.
Read drivers using CONFIG_GENERIC_PINCONF as an inspiration.
For example see commit
cefbf1a1b29531a970bc2908a50a75d6474fcc38
"pinctrl: sunxi: Support generic binding"
from Maxime Ripard, where he does a similar thing for sunxi.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 06/12] driver: pinctrl: imx: Add pinctrl driver support for imx6sll
From: Linus Walleij @ 2016-12-27 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482832070-22668-7-git-send-email-ping.bai@nxp.com>
On Tue, Dec 27, 2016 at 10:47 AM, Bai Ping <ping.bai@nxp.com> wrote:
> Add pinctrl driver support for imx6sll.
>
> Signed-off-by: Bai Ping <ping.bai@nxp.com>
(...)
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -514,6 +514,7 @@ config SOC_IMX6SL
>
> config SOC_IMX6SLL
> bool "i.MX6 SoloLiteLite support"
> + select PINCTRL_IMX6SLL
This needs to be separate so I can merge the pure pin control patch
to my tree.
Apart from that, look into using generic pinconf.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] PCI: exynos: refactor exynos pcie driver
From: Bartlomiej Zolnierkiewicz @ 2016-12-27 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482490587-13611-1-git-send-email-pankaj.dubey@samsung.com>
Hi,
On Friday, December 23, 2016 04:26:27 PM Pankaj Dubey wrote:
> From: Niyas Ahmed S T <niyas.ahmed@samsung.com>
>
> Currently Exynos PCIe driver is only supported for Exynos5440 SoC.
> This patch does refactoring of Exynos PCIe driver to extend support
> for other Exynos SoC.
>
> Following are the main changes done via this patch:
> 1) It adds separate structs for memory, clock resources.
> 2) It add exynos_pcie_ops struct which will allow us to support the
> differences in resources in different Exynos SoC.
>
> No functional change intended.
>
> Signed-off-by: Niyas Ahmed S T <niyas.ahmed@samsung.com>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
I would also like to see the explanation for 1) (as already
requested by Jingoo). Otherwise it all looks fine to me:
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH v8 1/8] soc: samsung: add exynos chipid driver support
From: Bartlomiej Zolnierkiewicz @ 2016-12-27 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481375323-29724-2-git-send-email-pankaj.dubey@samsung.com>
Hi,
On Saturday, December 10, 2016 06:38:36 PM Pankaj Dubey wrote:
> Exynos SoCs have Chipid, for identification of product IDs and SoC revisions.
> This patch intends to provide initialization code for all these functionalities,
> at the same time it provides some sysfs entries for accessing these information
> to user-space.
>
> This driver uses existing binding for exynos-chipid.
>
> CC: Grant Likely <grant.likely@linaro.org>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> [m.szyprowski: for suggestion and code snippet of product_id_to_soc_id]
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/soc/samsung/Kconfig | 5 ++
> drivers/soc/samsung/Makefile | 1 +
> drivers/soc/samsung/exynos-chipid.c | 116 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 122 insertions(+)
> create mode 100644 drivers/soc/samsung/exynos-chipid.c
[...]
> diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
> new file mode 100644
> index 0000000..cf0128b
> --- /dev/null
> +++ b/drivers/soc/samsung/exynos-chipid.c
[...]
> +/**
> + * exynos_chipid_early_init: Early chipid initialization
> + */
> +int __init exynos_chipid_early_init(void)
> +{
> + struct soc_device_attribute *soc_dev_attr;
> + struct soc_device *soc_dev;
> + struct device_node *root;
> + struct device_node *np;
> + void __iomem *exynos_chipid_base;
> + const struct of_device_id *match;
> + u32 product_id;
> + u32 revision;
> +
> + np = of_find_matching_node_and_match(NULL,
> + of_exynos_chipid_ids, &match);
> + if (!np)
> + return -ENODEV;
> +
> + exynos_chipid_base = of_iomap(np, 0);
of_node_put(np) is missing here.
> + if (!exynos_chipid_base)
> + return PTR_ERR(exynos_chipid_base);
PTR_ERR use here is incorrect - of_iomap() returns valid pointer or
NULL. Please just return -NODEV on of_iomap() failure.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH v4 4/4] clk: rockchip: add clock controller for rk3328
From: Heiko Stuebner @ 2016-12-27 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482820373-10186-5-git-send-email-zhangqing@rock-chips.com>
Hi Elaine,
Am Dienstag, 27. Dezember 2016, 14:32:53 CET schrieb Elaine Zhang:
> Add the clock tree definition for the new rk3328 SoC.
looks good in general, I have some styling nitpicks below and would like
the grf-clocks solved differently, also explained below:
> diff --git a/drivers/clk/rockchip/clk-rk3328.c
> b/drivers/clk/rockchip/clk-rk3328.c new file mode 100644
> index 000000000000..9958ce7d0dcd
> --- /dev/null
> +++ b/drivers/clk/rockchip/clk-rk3328.c
> +static struct rockchip_clk_branch rk3328_clk_branches[] __initdata = {
[...]
> + /*
> + * Clock-Architecture Diagram 8
> + */
blank line between two comment blocks please.
Same for similar setups in the code above.
> + /* PD_GMAC */
> +
> + COMPOSITE(ACLK_GMAC, "aclk_gmac", mux_2plls_hdmiphy_p, 0,
> + RK3328_CLKSEL_CON(35), 6, 2, MFLAGS, 0, 5, DFLAGS,
> + RK3328_CLKGATE_CON(3), 2, GFLAGS),
> + COMPOSITE_NOMUX(PCLK_GMAC, "pclk_gmac", "aclk_gmac", 0,
> + RK3328_CLKSEL_CON(25), 8, 3, DFLAGS,
> + RK3328_CLKGATE_CON(9), 0, GFLAGS),
> +
> + COMPOSITE(SCLK_MAC2IO_SRC, "clk_mac2io_src", mux_2plls_p, 0,
> + RK3328_CLKSEL_CON(27), 7, 1, MFLAGS, 0, 5, DFLAGS,
> + RK3328_CLKGATE_CON(3), 1, GFLAGS),
> + GATE(SCLK_MAC2IO_REF, "clk_mac2io_ref", "clk_mac2io", 0,
> + RK3328_CLKGATE_CON(9), 7, GFLAGS),
> + GATE(SCLK_MAC2IO_RX, "clk_mac2io_rx", "clk_mac2io", 0,
> + RK3328_CLKGATE_CON(9), 4, GFLAGS),
> + GATE(SCLK_MAC2IO_TX, "clk_mac2io_tx", "clk_mac2io", 0,
> + RK3328_CLKGATE_CON(9), 5, GFLAGS),
> + GATE(SCLK_MAC2IO_REFOUT, "clk_mac2io_refout", "clk_mac2io", 0,
> + RK3328_CLKGATE_CON(9), 6, GFLAGS),
> + COMPOSITE(SCLK_MAC2IO_OUT, "clk_mac2io_out", mux_2plls_p, 0,
> + RK3328_CLKSEL_CON(27), 15, 1, MFLAGS, 8, 5, DFLAGS,
> + RK3328_CLKGATE_CON(3), 5, GFLAGS),
> +
> + COMPOSITE(SCLK_MAC2PHY_SRC, "clk_mac2phy_src", mux_2plls_p, 0,
> + RK3328_CLKSEL_CON(26), 7, 1, MFLAGS, 0, 5, DFLAGS,
> + RK3328_CLKGATE_CON(3), 0, GFLAGS),
> + GATE(SCLK_MAC2PHY_REF, "clk_mac2phy_ref", "clk_mac2phy", 0,
> + RK3328_CLKGATE_CON(9), 3, GFLAGS),
> + GATE(SCLK_MAC2PHY_RXTX, "clk_mac2phy_rxtx", "clk_mac2phy", 0,
> + RK3328_CLKGATE_CON(9), 1, GFLAGS),
> + COMPOSITE_NOMUX(SCLK_MAC2PHY_OUT, "clk_mac2phy_out", "clk_mac2phy", 0,
> + RK3328_CLKSEL_CON(26), 8, 2, DFLAGS,
> + RK3328_CLKGATE_CON(9), 2, GFLAGS),
Please look at the other clock drivers for indentation. I.e. don't align with
the "(", but instead use the same indent everywhere.
This makes things like the register address always sit in the same position
and thus makes it easier to read the clock diagram.
> + FACTOR(0, "xin12m", "xin24m", 0, 1, 2),
> +
> + /*
> + * Clock-Architecture Diagram 9
> + */
> +
For the following long list of gates, just make it one line per gate and do
not line-break them ... see other clock drivers for reference.
This long gate list is very uniform (= only gates) and reducing the number
of lines needed makes it easier to parse for those.
> + /* PD_VOP */
> + GATE(ACLK_RGA, "aclk_rga", "aclk_rga_pre", 0,
> + RK3328_CLKGATE_CON(21), 10, GFLAGS),
> + GATE(0, "aclk_rga_niu", "aclk_rga_pre", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(22), 3, GFLAGS),
> + GATE(ACLK_VOP, "aclk_vop", "aclk_vop_pre", 0,
> + RK3328_CLKGATE_CON(21), 2, GFLAGS),
> + GATE(0, "aclk_vop_niu", "aclk_vop_pre", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(21), 4, GFLAGS),
> +
> + GATE(ACLK_IEP, "aclk_iep", "aclk_vio_pre", 0,
> + RK3328_CLKGATE_CON(21), 6, GFLAGS),
> + GATE(ACLK_CIF, "aclk_cif", "aclk_vio_pre", 0,
> + RK3328_CLKGATE_CON(21), 8, GFLAGS),
> + GATE(ACLK_HDCP, "aclk_hdcp", "aclk_vio_pre", 0,
> + RK3328_CLKGATE_CON(21), 15, GFLAGS),
> + GATE(0, "aclk_vio_niu", "aclk_vio_pre", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(22), 2, GFLAGS),
> +
> + GATE(HCLK_VOP, "hclk_vop", "hclk_vio_pre", 0,
> + RK3328_CLKGATE_CON(21), 3, GFLAGS),
> + GATE(0, "hclk_vop_niu", "hclk_vio_pre", 0,
> + RK3328_CLKGATE_CON(21), 5, GFLAGS),
> + GATE(HCLK_IEP, "hclk_iep", "hclk_vio_pre", 0,
> + RK3328_CLKGATE_CON(21), 7, GFLAGS),
> + GATE(HCLK_CIF, "hclk_cif", "hclk_vio_pre", 0,
> + RK3328_CLKGATE_CON(21), 9, GFLAGS),
> + GATE(HCLK_RGA, "hclk_rga", "hclk_vio_pre", 0,
> + RK3328_CLKGATE_CON(21), 11, GFLAGS),
> + GATE(0, "hclk_ahb1tom", "hclk_vio_pre", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(21), 12, GFLAGS),
> + GATE(0, "pclk_vio_h2p", "hclk_vio_pre", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(21), 13, GFLAGS),
> + GATE(0, "hclk_vio_h2p", "hclk_vio_pre", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(21), 14, GFLAGS),
> + GATE(HCLK_HDCP, "hclk_hdcp", "hclk_vio_pre", 0,
> + RK3328_CLKGATE_CON(22), 0, GFLAGS),
> + GATE(HCLK_VIO, "hclk_vio", "hclk_vio_pre", 0,
> + RK3328_CLKGATE_CON(22), 1, GFLAGS),
> + GATE(PCLK_HDMI, "pclk_hdmi", "hclk_vio_pre", 0,
> + RK3328_CLKGATE_CON(22), 4, GFLAGS),
> + GATE(PCLK_HDCP, "pclk_hdcp", "hclk_vio_pre", 0,
> + RK3328_CLKGATE_CON(22), 5, GFLAGS),
> +
> + /* PD_PERI */
> + GATE(0, "aclk_peri_noc", "aclk_peri", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(19), 11, GFLAGS),
> + GATE(ACLK_USB3OTG, "aclk_usb3otg", "aclk_peri", 0,
> + RK3328_CLKGATE_CON(19), 4, GFLAGS),
> +
> + GATE(HCLK_SDMMC, "hclk_sdmmc", "hclk_peri", 0,
> + RK3328_CLKGATE_CON(19), 0, GFLAGS),
> + GATE(HCLK_SDIO, "hclk_sdio", "hclk_peri", 0,
> + RK3328_CLKGATE_CON(19), 1, GFLAGS),
> + GATE(HCLK_EMMC, "hclk_emmc", "hclk_peri", 0,
> + RK3328_CLKGATE_CON(19), 2, GFLAGS),
> + GATE(HCLK_SDMMC_EXT, "hclk_sdmmc_ext", "hclk_peri", 0,
> + RK3328_CLKGATE_CON(19), 15, GFLAGS),
> + GATE(HCLK_HOST0, "hclk_host0", "hclk_peri", 0,
> + RK3328_CLKGATE_CON(19), 6, GFLAGS),
> + GATE(HCLK_HOST0_ARB, "hclk_host0_arb", "hclk_peri", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(19), 7, GFLAGS),
> + GATE(HCLK_OTG, "hclk_otg", "hclk_peri", 0,
> + RK3328_CLKGATE_CON(19), 8, GFLAGS),
> + GATE(HCLK_OTG_PMU, "hclk_otg_pmu", "hclk_peri", 0,
> + RK3328_CLKGATE_CON(19), 9, GFLAGS),
> + GATE(0, "hclk_peri_niu", "hclk_peri", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(19), 12, GFLAGS),
> + GATE(0, "pclk_peri_niu", "hclk_peri", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(19), 13, GFLAGS),
> +
> + /* PD_GMAC */
> + GATE(ACLK_MAC2PHY, "aclk_mac2phy", "aclk_gmac", 0,
> + RK3328_CLKGATE_CON(26), 0, GFLAGS),
> + GATE(ACLK_MAC2IO, "aclk_mac2io", "aclk_gmac", 0,
> + RK3328_CLKGATE_CON(26), 2, GFLAGS),
> + GATE(0, "aclk_gmac_niu", "aclk_gmac", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(26), 4, GFLAGS),
> + GATE(PCLK_MAC2PHY, "pclk_mac2phy", "pclk_gmac", 0,
> + RK3328_CLKGATE_CON(26), 1, GFLAGS),
> + GATE(PCLK_MAC2IO, "pclk_mac2io", "pclk_gmac", 0,
> + RK3328_CLKGATE_CON(26), 3, GFLAGS),
> + GATE(0, "pclk_gmac_niu", "pclk_gmac", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(26), 5, GFLAGS),
> +
> + /* PD_BUS */
> + GATE(0, "aclk_bus_niu", "aclk_bus_pre", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(15), 12, GFLAGS),
> + GATE(ACLK_DCF, "aclk_dcf", "aclk_bus_pre", 0,
> + RK3328_CLKGATE_CON(15), 11, GFLAGS),
> + GATE(ACLK_TSP, "aclk_tsp", "aclk_bus_pre", 0,
> + RK3328_CLKGATE_CON(17), 12, GFLAGS),
> + GATE(0, "aclk_intmem", "aclk_bus_pre", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(15), 0, GFLAGS),
> + GATE(ACLK_DMAC, "aclk_dmac_bus", "aclk_bus_pre", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(15), 1, GFLAGS),
> +
> + GATE(0, "hclk_rom", "hclk_bus_pre", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(15), 2, GFLAGS),
> + GATE(HCLK_I2S0_8CH, "hclk_i2s0_8ch", "hclk_bus_pre", 0,
> + RK3328_CLKGATE_CON(15), 3, GFLAGS),
> + GATE(HCLK_I2S1_8CH, "hclk_i2s1_8ch", "hclk_bus_pre", 0,
> + RK3328_CLKGATE_CON(15), 4, GFLAGS),
> + GATE(HCLK_I2S2_2CH, "hclk_i2s2_2ch", "hclk_bus_pre", 0,
> + RK3328_CLKGATE_CON(15), 5, GFLAGS),
> + GATE(HCLK_SPDIF_8CH, "hclk_spdif_8ch", "hclk_bus_pre", 0,
> + RK3328_CLKGATE_CON(15), 6, GFLAGS),
> + GATE(HCLK_TSP, "hclk_tsp", "hclk_bus_pre", 0,
> + RK3328_CLKGATE_CON(17), 11, GFLAGS),
> + GATE(HCLK_CRYPTO_MST, "hclk_crypto_mst", "hclk_bus_pre", 0,
> + RK3328_CLKGATE_CON(15), 7, GFLAGS),
> + GATE(HCLK_CRYPTO_SLV, "hclk_crypto_slv", "hclk_bus_pre", 0,
> + RK3328_CLKGATE_CON(15), 8, GFLAGS),
> + GATE(0, "hclk_bus_niu", "hclk_bus_pre", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(15), 13, GFLAGS),
> + GATE(HCLK_PDM, "hclk_pdm", "hclk_bus_pre", 0,
> + RK3328_CLKGATE_CON(28), 0, GFLAGS),
> +
> + GATE(0, "pclk_bus_niu", "pclk_bus", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(15), 14, GFLAGS),
> + GATE(0, "pclk_efuse", "pclk_bus", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(15), 9, GFLAGS),
> + GATE(0, "pclk_otp", "pclk_bus", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(28), 4, GFLAGS),
> + GATE(PCLK_I2C0, "pclk_i2c0", "pclk_bus", 0,
> + RK3328_CLKGATE_CON(15), 10, GFLAGS),
> + GATE(PCLK_I2C1, "pclk_i2c1", "pclk_bus", 0,
> + RK3328_CLKGATE_CON(16), 0, GFLAGS),
> + GATE(PCLK_I2C2, "pclk_i2c2", "pclk_bus", 0,
> + RK3328_CLKGATE_CON(16), 1, GFLAGS),
> + GATE(PCLK_I2C3, "pclk_i2c3", "pclk_bus", 0,
> + RK3328_CLKGATE_CON(16), 2, GFLAGS),
> + GATE(PCLK_TIMER, "pclk_timer0", "pclk_bus", 0,
> + RK3328_CLKGATE_CON(16), 3, GFLAGS),
> + GATE(0, "pclk_stimer", "pclk_bus", 0,
> + RK3328_CLKGATE_CON(16), 4, GFLAGS),
> + GATE(PCLK_SPI, "pclk_spi", "pclk_bus", 0,
> + RK3328_CLKGATE_CON(16), 5, GFLAGS),
> + GATE(PCLK_PWM, "pclk_rk_pwm", "pclk_bus", 0,
> + RK3328_CLKGATE_CON(16), 6, GFLAGS),
> + GATE(PCLK_GPIO0, "pclk_gpio0", "pclk_bus", 0,
> + RK3328_CLKGATE_CON(16), 7, GFLAGS),
> + GATE(PCLK_GPIO1, "pclk_gpio1", "pclk_bus", 0,
> + RK3328_CLKGATE_CON(16), 8, GFLAGS),
> + GATE(PCLK_GPIO2, "pclk_gpio2", "pclk_bus", 0,
> + RK3328_CLKGATE_CON(16), 9, GFLAGS),
> + GATE(PCLK_GPIO3, "pclk_gpio3", "pclk_bus", 0,
> + RK3328_CLKGATE_CON(16), 10, GFLAGS),
> + GATE(PCLK_UART0, "pclk_uart0", "pclk_bus", 0,
> + RK3328_CLKGATE_CON(16), 11, GFLAGS),
> + GATE(PCLK_UART1, "pclk_uart1", "pclk_bus", 0,
> + RK3328_CLKGATE_CON(16), 12, GFLAGS),
> + GATE(PCLK_UART2, "pclk_uart2", "pclk_bus", 0,
> + RK3328_CLKGATE_CON(16), 13, GFLAGS),
> + GATE(PCLK_TSADC, "pclk_tsadc", "pclk_bus", 0,
> + RK3328_CLKGATE_CON(16), 14, GFLAGS),
> + GATE(PCLK_DCF, "pclk_dcf", "pclk_bus", 0,
> + RK3328_CLKGATE_CON(16), 15, GFLAGS),
> + GATE(PCLK_GRF, "pclk_grf", "pclk_bus", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(17), 0, GFLAGS),
> + GATE(0, "pclk_cru", "pclk_bus", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(17), 4, GFLAGS),
> + GATE(0, "pclk_sgrf", "pclk_bus", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(17), 6, GFLAGS),
> + GATE(0, "pclk_sim", "pclk_bus", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(17), 10, GFLAGS),
> + GATE(PCLK_SARADC, "pclk_saradc", "pclk_bus", 0,
> + RK3328_CLKGATE_CON(17), 15, GFLAGS),
> + GATE(0, "pclk_pmu", "pclk_bus", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(28), 3, GFLAGS),
> +
> + GATE(PCLK_USB3PHY_OTG, "pclk_usb3phy_otg", "pclk_phy_pre", 0,
> + RK3328_CLKGATE_CON(28), 1, GFLAGS),
> + GATE(PCLK_USB3PHY_PIPE, "pclk_usb3phy_pipe", "pclk_phy_pre", 0,
> + RK3328_CLKGATE_CON(28), 2, GFLAGS),
> + GATE(PCLK_USB3_GRF, "pclk_usb3_grf", "pclk_phy_pre", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(17), 2, GFLAGS),
> + GATE(PCLK_USB2_GRF, "pclk_usb2_grf", "pclk_phy_pre", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(17), 14, GFLAGS),
> + GATE(0, "pclk_ddrphy", "pclk_phy_pre", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(17), 13, GFLAGS),
> + GATE(0, "pclk_acodecphy", "pclk_phy_pre", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(17), 5, GFLAGS),
> + GATE(PCLK_HDMIPHY, "pclk_hdmiphy", "pclk_phy_pre", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(17), 7, GFLAGS),
> + GATE(0, "pclk_vdacphy", "pclk_phy_pre", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(17), 8, GFLAGS),
> + GATE(0, "pclk_phy_niu", "pclk_phy_pre", CLK_IGNORE_UNUSED,
> + RK3328_CLKGATE_CON(15), 15, GFLAGS),
> +static void __init rk3328_clk_init(struct device_node *np)
> +{
> + struct rockchip_clk_provider *ctx;
> + void __iomem *reg_base;
> +
> + reg_base = of_iomap(np, 0);
> + if (!reg_base) {
> + pr_err("%s: could not map cru region\n", __func__);
> + return;
> + }
> +
> + rk3328_cru_base = reg_base;
> +
> + ctx = rockchip_clk_init(np, reg_base, CLK_NR_CLKS);
> + if (IS_ERR(ctx)) {
> + pr_err("%s: rockchip clk init failed\n", __func__);
> + iounmap(reg_base);
> + return;
> + }
> +
> + rockchip_clk_register_plls(ctx, rk3328_pll_clks,
> + ARRAY_SIZE(rk3328_pll_clks),
> + RK3328_GRF_SOC_STATUS0);
> + rockchip_clk_register_branches(ctx, rk3328_clk_branches,
> + ARRAY_SIZE(rk3328_clk_branches));
> + rockchip_clk_protect_critical(rk3328_critical_clocks,
> + ARRAY_SIZE(rk3328_critical_clocks));
> +
> + rockchip_clk_register_armclk(ctx, ARMCLK, "armclk",
> + mux_armclk_p, ARRAY_SIZE(mux_armclk_p),
> + &rk3328_cpuclk_data, rk3328_cpuclk_rates,
> + ARRAY_SIZE(rk3328_cpuclk_rates));
> +
> + rockchip_register_softrst(np, 11, reg_base + RK3328_SOFTRST_CON(0),
> + ROCKCHIP_SOFTRST_HIWORD_MASK);
> +
> + rockchip_register_restart_notifier(ctx, RK3328_GLB_SRST_FST, NULL);
> +
> + rockchip_clk_of_add_provider(np, ctx);
> +
> + atomic_notifier_chain_register(&panic_notifier_list,
> + &rk3328_clk_panic_block);
please drop this notifier and asorted code above for dumping cru registers.
> +}
> +
> +CLK_OF_DECLARE(rk3328_cru, "rockchip,rk3328-cru", rk3328_clk_init);
> +
> +static void __init rk3328_grf_clk_init(struct device_node *np)
> +{
> + struct rockchip_clk_provider *ctx;
> + void __iomem *reg_base;
> +
> + reg_base = of_iomap(np, 0);
> + if (!reg_base) {
> + pr_err("%s: could not map cru pmu region\n", __func__);
> + return;
> + }
> +
> + ctx = rockchip_clk_init(np, reg_base, CLKGRF_NR_CLKS);
> + if (IS_ERR(ctx)) {
> + pr_err("%s: rockchip pmu clk init failed\n", __func__);
> + return;
> + }
> +
> + rockchip_clk_register_branches(ctx, rk3328_clk_grf_branches,
> + ARRAY_SIZE(rk3328_clk_grf_branches));
> +
> + rockchip_clk_of_add_provider(np, ctx);
> +}
We definitly don't want to bind against the regular GRF node. This causes a
double mapping of the region and in general this isn't the clock-controller
and just contains 2 clocks controls that somehow ended up in the GRF :-) .
Instead please take a look at the muxgrf clock patches I Cc'ed you on some
minutes ago.
> +CLK_OF_DECLARE(rk3328_cru_grf, "rockchip,rk3328-grf", rk3328_grf_clk_init);
> diff --git a/drivers/clk/rockchip/clk.h b/drivers/clk/rockchip/clk.h index
> 06acb7e0911f..7225997f8d52 100644
> --- a/drivers/clk/rockchip/clk.h
> +++ b/drivers/clk/rockchip/clk.h
> @@ -91,6 +91,28 @@
> #define RK3288_EMMC_CON0 0x218
> #define RK3288_EMMC_CON1 0x21c
>
> +#define RK3328_PLL_CON(x) RK2928_PLL_CON(x)
> +#define RK3328_CLKSEL_CON(x) ((x) * 0x4 + 0x100)
> +#define RK3328_CLKGATE_CON(x) ((x) * 0x4 + 0x200)
> +#define RK3328_GRFCLKSEL_CON(x) ((x) * 0x4 + 0x100)
> +#define RK3328_GLB_SRST_FST 0x9c
> +#define RK3328_GLB_SRST_SND 0x98
> +#define RK3328_SOFTRST_CON(x) ((x) * 0x4 + 0x300)
> +#define RK3328_MODE_CON 0x80
> +#define RK3328_MISC_CON 0x84
-----
> +#define RK3328_DIV_ACLKM_MASK 0x7
> +#define RK3328_DIV_ACLKM_SHIFT 4
> +#define RK3328_DIV_PCLK_DBG_MASK 0xf
> +#define RK3328_DIV_PCLK_DBG_SHIFT 0
-----
please move these to the armclk defintion in the controller driver
where already the other definitions are
Thanks
Heiko
^ permalink raw reply
* [PATCH v3 resend] i2c: designware: add reset interface
From: Zhangfei Gao @ 2016-12-27 14:22 UTC (permalink / raw)
To: linux-arm-kernel
Some platforms like hi3660 need do reset first to allow accessing registers
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Ramiro Oliveira <ramiro.oliveira@synopsys.com>
---
rebase to 4.10-rc1
drivers/i2c/busses/i2c-designware-core.h | 1 +
drivers/i2c/busses/i2c-designware-platdrv.c | 28 ++++++++++++++++++++++++----
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-core.h b/drivers/i2c/busses/i2c-designware-core.h
index 26250b4..302807c 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -88,6 +88,7 @@ struct dw_i2c_dev {
void __iomem *base;
struct completion cmd_complete;
struct clk *clk;
+ struct reset_control *rst;
u32 (*get_clk_rate_khz) (struct dw_i2c_dev *dev);
struct dw_pci_controller *controller;
int cmd_err;
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 6ce4313..79c4b4e 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -38,6 +38,7 @@
#include <linux/pm_runtime.h>
#include <linux/property.h>
#include <linux/io.h>
+#include <linux/reset.h>
#include <linux/slab.h>
#include <linux/acpi.h>
#include <linux/platform_data/i2c-designware.h>
@@ -199,6 +200,14 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
dev->irq = irq;
platform_set_drvdata(pdev, dev);
+ dev->rst = devm_reset_control_get_optional_exclusive(&pdev->dev, NULL);
+ if (IS_ERR(dev->rst)) {
+ if (PTR_ERR(dev->rst) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ } else {
+ reset_control_deassert(dev->rst);
+ }
+
if (pdata) {
dev->clk_freq = pdata->i2c_scl_freq;
} else {
@@ -235,12 +244,13 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
&& dev->clk_freq != 1000000 && dev->clk_freq != 3400000) {
dev_err(&pdev->dev,
"Only 100kHz, 400kHz, 1MHz and 3.4MHz supported");
- return -EINVAL;
+ r = -EINVAL;
+ goto exit_reset;
}
r = i2c_dw_eval_lock_support(dev);
if (r)
- return r;
+ goto exit_reset;
dev->functionality = I2C_FUNC_10BIT_ADDR | DW_IC_DEFAULT_FUNCTIONALITY;
@@ -286,10 +296,18 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
}
r = i2c_dw_probe(dev);
- if (r && !dev->pm_runtime_disabled)
- pm_runtime_disable(&pdev->dev);
+ if (r)
+ goto exit_probe;
return r;
+
+exit_probe:
+ if (!dev->pm_runtime_disabled)
+ pm_runtime_disable(&pdev->dev);
+exit_reset:
+ if (!IS_ERR_OR_NULL(dev->rst))
+ reset_control_assert(dev->rst);
+ return r;
}
static int dw_i2c_plat_remove(struct platform_device *pdev)
@@ -306,6 +324,8 @@ static int dw_i2c_plat_remove(struct platform_device *pdev)
pm_runtime_put_sync(&pdev->dev);
if (!dev->pm_runtime_disabled)
pm_runtime_disable(&pdev->dev);
+ if (!IS_ERR_OR_NULL(dev->rst))
+ reset_control_assert(dev->rst);
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
From: Ard Biesheuvel @ 2016-12-27 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161227100400.GA10629@gondor.apana.org.au>
> On 27 Dec 2016, at 10:04, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
>> On Thu, Dec 08, 2016 at 02:28:57PM +0000, Ard Biesheuvel wrote:
>> Another port of existing x86 SSE code to NEON, again both for arm64 and ARM.
>>
>> ChaCha20 is a stream cipher described in RFC 7539, and is intended to be
>> an efficient software implementable 'standby cipher', in case AES cannot
>> be used.
>>
>> This NEON implementation is almost 2x as fast as the generic C code
>> (measured on Cortex-A57 using the arm64 version)
>>
>> I'm aware that blkciphers are deprecated in favor of skciphers, but this
>> code (like the x86 version) uses the init and setkey routines of the generic
>> version, so it is probably better to port all implementations at once.
>>
>> Ard Biesheuvel (2):
>> crypto: arm64/chacha20 - implement NEON version based on SSE3 code
>> crypto: arm/chacha20 - implement NEON version based on SSE3 code
>
> Both patches applied. Thanks.
You just nacked the v2 of this series (due to the chunksize/walksize) and i rewrote them as skciphers as well
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v3 resend] i2c: designware: add reset interface
From: Jarkko Nikula @ 2016-12-27 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482848560-3752-1-git-send-email-zhangfei.gao@linaro.org>
On 12/27/2016 04:22 PM, Zhangfei Gao wrote:
> Some platforms like hi3660 need do reset first to allow accessing registers
>
> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Tested-by: Ramiro Oliveira <ramiro.oliveira@synopsys.com>
> ---
> rebase to 4.10-rc1
>
> drivers/i2c/busses/i2c-designware-core.h | 1 +
> drivers/i2c/busses/i2c-designware-platdrv.c | 28 ++++++++++++++++++++++++----
> 2 files changed, 25 insertions(+), 4 deletions(-)
>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
^ permalink raw reply
* [PATCH 7/9] pinctrl: samsung: Add property to mark pad state as suitable for power down
From: Krzysztof Kozlowski @ 2016-12-27 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bd48fe32-5296-fc23-dbb8-d212292d76cd@samsung.com>
On Tue, Dec 27, 2016 at 11:30:57AM +0100, Marek Szyprowski wrote:
> Hi Krzysztof,
>
>
> On 2016-12-25 20:19, Krzysztof Kozlowski wrote:
> > On Fri, Dec 23, 2016 at 01:24:47PM +0100, Marek Szyprowski wrote:
> > > Add support for special property "samsung,off-state", which indicates a special
> > > state suitable for device's "sleep" state. Its pin values/properties should
> > > match the configuration in power down mode. It indicates that pin controller
> > > can notify runtime power management subsystem, that it is ready for runtime
> > > suspend if its all pins are configured for such state. This in turn might
> > > allow to turn respective power domain off to reduce power consumption.
> > >
> > > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > > ---
> > > Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt | 8 ++++++++
> > > drivers/pinctrl/samsung/pinctrl-samsung.c | 4 ++++
> > > drivers/pinctrl/samsung/pinctrl-samsung.h | 1 +
> > > 3 files changed, 13 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> > > index b7bd2e12a269..354eea0e7798 100644
> > > --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> > > +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> > > @@ -105,6 +105,7 @@ Required Properties:
> > > - samsung,pin-drv: Drive strength configuration.
> > > - samsung,pin-pud-pdn: Pull up/down configuration in power down mode.
> > > - samsung,pin-drv-pdn: Drive strength configuration in power down mode.
> > > + - samsung,off-state: Mark this configuration as suitable for bank power off.
> > > The values specified by these config properties should be derived from the
> > > hardware manual and these values are programmed as-is into the pin
> > > @@ -113,6 +114,13 @@ Required Properties:
> > > Note: A child should include atleast a pin function selection property or
> > > pin configuration property (one or more) or both.
> > > + Note: Special property "samsung,off-state" indicates that this state can
> > > + be used for device's "sleep" pins state. Its pin values/properties should
> > > + match the configuration in power down mode.
> > Why power down values cannot be used for sleep state? Why you need
> > separate pin control state? If pins values should match power down
> > configuration, then they could just be added to default state, couldn't
> > they?
>
> Separate sleep state is needed because of the pin control bindings and
> design.
>
> A separate sleep state is required to let pin control client driver (in this
> case
> Exynos I2S driver) let to choose when it is okay to switch pads into sleep
> state and I see no other way to achieve this.
Maybe the pinctrl API should be extended for this? Doing this in DTS
just for purpose of passing information between drivers (consumer and
provider) looks odd.
Anyway, you are proposing a new binding so please Cc devicetree mailing
list and device tree maintainers.
> > In the patch 2/9, existing configuration:
> > 716 i2s0_bus: i2s0-bus {
> > (...)
> > 719 samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
> > 720 samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
> > 721 samsung,pin-drv = <EXYNOS5420_PIN_DRV_LV1>;
> > 722 };
> >
> > additional configuration:
> > + i2s0_bus_slp: i2s0-bus-slp {
> > + samsung,pin-function = <EXYNOS_PIN_FUNC_INPUT>;
> > + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
> > + samsung,pin-drv = <EXYNOS5420_PIN_DRV_LV1>;
> > + samsung,pin-con-pdn = <EXYNOS_PIN_PDN_INPUT>;
> > + samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>;
> > + samsung,off-state;
> > + };
>
> I agree that it would be possible to get rid of "samsung,off-state" property
> and
> just detect off state when func/pud pair matches power down func/pud.
>
> > > It indicates that pin control
> > > + can notify runtime power management subsystem, that it is ready for runtime
> > > + suspend if its all pins are configured for such state. This in turn might
> > > + allow to turn respective power domain off to reduce power consumption.
> > What do you mean by "notifying RPM subsystem"? Either this is
> > description of hardware in certain mode (sleep state) or this is not
> > device tree property.
>
> Maybe I wrote the description with a view too limited to the kernel
> operation
> perspective, but if we remove the need to mark state as off, the above
> description
> will not be needed.
But still it wouldn't be describing any hardware property, would it?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 5/9] pinctrl: samsung: Move retention control from mach-exynos to the pinctrl driver
From: Krzysztof Kozlowski @ 2016-12-27 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5d09e29f-5796-cce6-75d5-ed5a0145092f@samsung.com>
On Tue, Dec 27, 2016 at 11:12:26AM +0100, Marek Szyprowski wrote:
> Hi Tomasz,
>
>
> On 2016-12-26 06:55, Tomasz Figa wrote:
> > 2016-12-23 21:24 GMT+09:00 Marek Szyprowski <m.szyprowski@samsung.com>:
> > > Pad retention control after suspend/resume cycle should be done from pin
> > > controller driver instead of PMU (power management unit) driver to avoid
> > > possible ordering and logical dependencies. Till now it worked fine only
> > > because PMU driver registered its sys_ops after pin controller.
> > >
> > > This patch moves pad retention control from PMU driver to Exynos pin
> > > controller driver. This is a preparation for adding new features to Exynos
> > > pin controller driver, like runtime power management and suspending
> > > individual pin controllers, which might be a part of some power domain.
> > >
> > It looks like this change will essentially break the compatibility
> > with DTBs that don't have the pmu syscon specified in pin controller
> > nodes.
> >
> > On the other hand, moving this code to where it actually belongs
> > really makes sense, so maybe we could just avoid the need of having
> > this property, by looking up the PMU manually, by hardcoded string or
> > so, if the proper property is not present?
>
> Well, once again the topic of mythical device tree compatibility appearch.
>
> There are imho following possibilities:
>
> 1. https://patchwork.kernel.org/patch/9477963/ ("Explicitly mark Samsung
> Exynos SoC bindings as unstable"), simply apply this approach and ignore
> users, who don't update their device tree blobs (are there any??).
That is not how it works. Assuming that there was this "mythical
compatibility" then you would have to wait a few moments between marking
something "to be broken" and actually breaking it. In other words, if
you wanted to silence the "breaking compatibility" folks, then the patch
above should have been sent a while ago.
> 2. Switch to syscon_regmap_lookup_by_compatible() lookup and hardcode PMU
> compatible id for all Exynos SoCs in the pin control driver. Then maybe,
> while unifying the code, switch other Exynos drivers to this approach
> and remove PMU phandles from device tree to make the code a bit more
> consistent across drivers and easier to understand.
>
> 3. Mixed approach, which combines drawbacks of both approaches. Additional
> dead code for handling mythical compatibility and harder to understand
> relations between the drivers.
>
>
> > [...]
> >
> > > diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> > > index 1baf19eecabf..b7bd2e12a269 100644
> > > --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> > > +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> > > @@ -43,6 +43,10 @@ Required Properties:
> > > };
> > > };
> > >
> > > +- samsung,pmu-syscon: Phandle to the PMU system controller, to let driver
> > > + to control pad retention after system suspend/resume cycle (only for Exynos
> > > + SoC series).
> > > +
> > Ah, here it is. I think adding relevant binding documentation at the
> > beginning of the series would make it much easier for reviewers to
> > understand the change.
>
> I already pointed that patches are ordered to make the changes bisectable,
> what
> usually means that new properties are added first, before being required by
> the
> drivers.
I saw the explanation for this order and I don't have problems with it.
However you can always split to separate patch the documentation for
bindings. It won't break bisectability.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ARM, ARM64: dts: drop "arm, amba-bus" in favor of "simple-bus" part 3
From: Masahiro Yamada @ 2016-12-27 15:51 UTC (permalink / raw)
To: linux-arm-kernel
Tree-wide replacement was done by commit 2ef7d5f342c1 ("ARM, ARM64:
dts: drop "arm,amba-bus" in favor of "simple-bus"), then the 2nd
round by commit 15b7cc78f095 ("arm64: dts: drop "arm,amba-bus" in
favor of "simple-bus" part 2").
Here, some new users have appeared for Linux v4.10-rc1. Eliminate
them now.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Hi Arnd, Olof,
Can you pick this up for v4.10 fixes?
If we carry arm,amba-bus until the release, we will need to
take more time to deprecate it.
arch/arm/boot/dts/qcom-mdm9615.dtsi | 2 +-
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-mdm9615.dtsi b/arch/arm/boot/dts/qcom-mdm9615.dtsi
index 5ae4ec5..c852b69 100644
--- a/arch/arm/boot/dts/qcom-mdm9615.dtsi
+++ b/arch/arm/boot/dts/qcom-mdm9615.dtsi
@@ -357,7 +357,7 @@
};
amba {
- compatible = "arm,amba-bus";
+ compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 64226d5..135890c 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -1367,7 +1367,7 @@
};
amba {
- compatible = "arm,amba-bus";
+ compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
--
2.7.4
^ permalink raw reply related
* [PATCH] pinctrl: single: fix spelling mistakes on "Ivalid"
From: Tony Lindgren @ 2016-12-27 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161223004714.7491-1-colin.king@canonical.com>
* Colin King <colin.king@canonical.com> [161222 16:48]:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fixe to spelling mistake "Ivalid" to "Invalid" in
> dev_err error message.
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v2 00/11] net: mvpp2: misc improvements and preparation patches
From: Thomas Petazzoni @ 2016-12-27 16:54 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This series contains a number of misc improvements and preparation
patches for an upcoming series that adds support for the new PPv2.2
network controller to the mvpp2 driver.
The most significant improvements are:
- Switching to using build_skb(), which is necessary for the upcoming
PPv2.2 support, but anyway a good improvement to the current mvpp2
driver (supporting PPv2.1).
- Making the driver build on 64-bit platforms.
Changes since v1:
- This series is split as a separate series from the larger patch set
adding support for PPv2.2 in the mvpp2 driver, as requested by
David Miller.
- Rebased on top of v4.10-rc1.
Thanks!
Thomas
Thomas Petazzoni (11):
net: mvpp2: handle too large value handling in
mvpp2_rx_pkts_coal_set()
net: mvpp2: handle too large value in mvpp2_rx_time_coal_set()
net: mvpp2: release reference to txq_cpu[] entry after unmapping
net: mvpp2: remove unused 'tx_skb' field of 'struct mvpp2_tx_queue'
net: mvpp2: drop useless fields in mvpp2_bm_pool and related code
net: mvpp2: simplify mvpp2_bm_bufs_add()
net: mvpp2: remove unused register definitions
net: mvpp2: fix indentation of MVPP2_EXT_GLOBAL_CTRL_DEFAULT
net: mvpp2: simplify MVPP2_PRS_RI_* definitions
net: mvpp2: switch to build_skb() in the RX path
net: mvpp2: enable building on 64-bit platforms
drivers/net/ethernet/marvell/Kconfig | 3 +-
drivers/net/ethernet/marvell/mvpp2.c | 161 ++++++++++++++++++++---------------
2 files changed, 93 insertions(+), 71 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 01/11] net: mvpp2: handle too large value handling in mvpp2_rx_pkts_coal_set()
From: Thomas Petazzoni @ 2016-12-27 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482857660-16092-1-git-send-email-thomas.petazzoni@free-electrons.com>
Currently, mvpp2_rx_pkts_coal_set() does the following to avoid setting
a too large value for the RX coalescing by packet number:
val = (pkts & MVPP2_OCCUPIED_THRESH_MASK);
This means that if you set a value that is slightly higher the the
maximum number of packets, you in fact get a very low value. It makes a
lot more sense to simply check if the value is too high, and if it's too
high, limit it to the maximum possible value.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 4fe430c..02d91e4 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -4381,11 +4381,11 @@ static void mvpp2_txp_max_tx_size_set(struct mvpp2_port *port)
static void mvpp2_rx_pkts_coal_set(struct mvpp2_port *port,
struct mvpp2_rx_queue *rxq, u32 pkts)
{
- u32 val;
+ if (pkts > MVPP2_OCCUPIED_THRESH_MASK)
+ pkts = MVPP2_OCCUPIED_THRESH_MASK;
- val = (pkts & MVPP2_OCCUPIED_THRESH_MASK);
mvpp2_write(port->priv, MVPP2_RXQ_NUM_REG, rxq->id);
- mvpp2_write(port->priv, MVPP2_RXQ_THRESH_REG, val);
+ mvpp2_write(port->priv, MVPP2_RXQ_THRESH_REG, pkts);
rxq->pkts_coal = pkts;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2 02/11] net: mvpp2: handle too large value in mvpp2_rx_time_coal_set()
From: Thomas Petazzoni @ 2016-12-27 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482857660-16092-1-git-send-email-thomas.petazzoni@free-electrons.com>
When configuring the MVPP2_ISR_RX_THRESHOLD_REG with the RX coalescing
time threshold, we do not check for the maximum allowed value supported
by the driver, which means we might overflow and use a bogus value. This
commit adds a check for this situation, and if a value higher than what
is supported by the hardware is provided, then we use the maximum value
supported by the hardware.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 02d91e4..a1ba89f 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -154,6 +154,7 @@
/* Interrupt Cause and Mask registers */
#define MVPP2_ISR_RX_THRESHOLD_REG(rxq) (0x5200 + 4 * (rxq))
+#define MVPP2_MAX_ISR_RX_THRESHOLD 0xfffff0
#define MVPP2_ISR_RXQ_GROUP_REG(rxq) (0x5400 + 4 * (rxq))
#define MVPP2_ISR_ENABLE_REG(port) (0x5420 + 4 * (port))
#define MVPP2_ISR_ENABLE_INTERRUPT(mask) ((mask) & 0xffff)
@@ -4397,6 +4398,12 @@ static void mvpp2_rx_time_coal_set(struct mvpp2_port *port,
u32 val;
val = (port->priv->tclk / USEC_PER_SEC) * usec;
+
+ if (val > MVPP2_MAX_ISR_RX_THRESHOLD) {
+ val = MVPP2_MAX_ISR_RX_THRESHOLD;
+ usec = (val * USEC_PER_SEC) / port->priv->tclk;
+ }
+
mvpp2_write(port->priv, MVPP2_ISR_RX_THRESHOLD_REG(rxq->id), val);
rxq->time_coal = usec;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 03/11] net: mvpp2: release reference to txq_cpu[] entry after unmapping
From: Thomas Petazzoni @ 2016-12-27 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482857660-16092-1-git-send-email-thomas.petazzoni@free-electrons.com>
The mvpp2_txq_bufs_free() function is called upon TX completion to DMA
unmap TX buffers, and free the corresponding SKBs. It gets the
references to the SKB to free and the DMA buffer to unmap from a per-CPU
txq_pcpu data structure.
However, the code currently increments the pointer to the next entry
before doing the DMA unmap and freeing the SKB. It does not cause any
visible problem because for a given SKB the TX completion is guaranteed
to take place on the CPU where the TX was started. However, it is much
more logical to increment the pointer to the next entry once the current
entry has been completely unmapped/released.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index a1ba89f..d098c7b 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -4420,13 +4420,12 @@ static void mvpp2_txq_bufs_free(struct mvpp2_port *port,
struct mvpp2_txq_pcpu_buf *tx_buf =
txq_pcpu->buffs + txq_pcpu->txq_get_index;
- mvpp2_txq_inc_get(txq_pcpu);
-
dma_unmap_single(port->dev->dev.parent, tx_buf->phys,
tx_buf->size, DMA_TO_DEVICE);
- if (!tx_buf->skb)
- continue;
- dev_kfree_skb_any(tx_buf->skb);
+ if (tx_buf->skb)
+ dev_kfree_skb_any(tx_buf->skb);
+
+ mvpp2_txq_inc_get(txq_pcpu);
}
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2 04/11] net: mvpp2: remove unused 'tx_skb' field of 'struct mvpp2_tx_queue'
From: Thomas Petazzoni @ 2016-12-27 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482857660-16092-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit remove a field of 'struct mvpp2_tx_queue' that is not used
anywhere.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index d098c7b..6720cdac 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -823,9 +823,6 @@ struct mvpp2_tx_queue {
/* Per-CPU control of physical Tx queues */
struct mvpp2_txq_pcpu __percpu *pcpu;
- /* Array of transmitted skb */
- struct sk_buff **tx_skb;
-
u32 done_pkts_coal;
/* Virtual address of thex Tx DMA descriptors array */
--
2.7.4
^ permalink raw reply related
* [PATCH v2 05/11] net: mvpp2: drop useless fields in mvpp2_bm_pool and related code
From: Thomas Petazzoni @ 2016-12-27 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482857660-16092-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit drops dead code from the mvpp2 driver. The 'in_use' and
'in_use_thresh' fields of 'struct mvpp2_bm_pool' are
incremented/decremented/initialized in various places. But they are only
used in one place:
if (is_recycle &&
(atomic_read(&bm_pool->in_use) < bm_pool->in_use_thresh))
return 0;
However 'is_recycle', passed as argument to mvpp2_rx_refill() is always
false. So in fact, this code is never reached, and the 'is_recycle'
argument is useless. So let's drop this code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 18 +++---------------
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 6720cdac..bfa9f77 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -930,10 +930,6 @@ struct mvpp2_bm_pool {
/* Ports using BM pool */
u32 port_map;
-
- /* Occupied buffers indicator */
- atomic_t in_use;
- int in_use_thresh;
};
struct mvpp2_buff_hdr {
@@ -3399,7 +3395,6 @@ static int mvpp2_bm_pool_create(struct platform_device *pdev,
bm_pool->size = size;
bm_pool->pkt_size = 0;
bm_pool->buf_num = 0;
- atomic_set(&bm_pool->in_use, 0);
return 0;
}
@@ -3656,7 +3651,6 @@ static int mvpp2_bm_bufs_add(struct mvpp2_port *port,
/* Update BM driver with number of buffers added to pool */
bm_pool->buf_num += i;
- bm_pool->in_use_thresh = bm_pool->buf_num / 4;
netdev_dbg(port->dev,
"%s pool %d: pkt_size=%4d, buf_size=%4d, total_size=%4d\n",
@@ -4997,23 +4991,18 @@ static void mvpp2_rx_csum(struct mvpp2_port *port, u32 status,
/* Reuse skb if possible, or allocate a new skb and add it to BM pool */
static int mvpp2_rx_refill(struct mvpp2_port *port,
- struct mvpp2_bm_pool *bm_pool,
- u32 bm, int is_recycle)
+ struct mvpp2_bm_pool *bm_pool, u32 bm)
{
struct sk_buff *skb;
dma_addr_t phys_addr;
- if (is_recycle &&
- (atomic_read(&bm_pool->in_use) < bm_pool->in_use_thresh))
- return 0;
-
/* No recycle or too many buffers are in use, so allocate a new skb */
skb = mvpp2_skb_alloc(port, bm_pool, &phys_addr, GFP_ATOMIC);
if (!skb)
return -ENOMEM;
mvpp2_pool_refill(port, bm, (u32)phys_addr, (u32)skb);
- atomic_dec(&bm_pool->in_use);
+
return 0;
}
@@ -5139,7 +5128,7 @@ static int mvpp2_rx(struct mvpp2_port *port, int rx_todo,
skb = (struct sk_buff *)rx_desc->buf_cookie;
- err = mvpp2_rx_refill(port, bm_pool, bm, 0);
+ err = mvpp2_rx_refill(port, bm_pool, bm);
if (err) {
netdev_err(port->dev, "failed to refill BM pools\n");
goto err_drop_frame;
@@ -5150,7 +5139,6 @@ static int mvpp2_rx(struct mvpp2_port *port, int rx_todo,
rcvd_pkts++;
rcvd_bytes += rx_bytes;
- atomic_inc(&bm_pool->in_use);
skb_reserve(skb, MVPP2_MH_SIZE);
skb_put(skb, rx_bytes);
--
2.7.4
^ permalink raw reply related
* [PATCH v2 06/11] net: mvpp2: simplify mvpp2_bm_bufs_add()
From: Thomas Petazzoni @ 2016-12-27 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482857660-16092-1-git-send-email-thomas.petazzoni@free-electrons.com>
The mvpp2_bm_bufs_add() currently creates a fake cookie by calling
mvpp2_bm_cookie_pool_set(), just to be able to call
mvpp2_pool_refill(). But all what mvpp2_pool_refill() does is extract
the pool ID from the cookie, and call mvpp2_bm_pool_put() with this ID.
Instead of doing this convoluted thing, just call mvpp2_bm_pool_put()
directly, since we have the BM pool ID.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/net/ethernet/marvell/mvpp2.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index bfa9f77..8174f40 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -3626,7 +3626,6 @@ static int mvpp2_bm_bufs_add(struct mvpp2_port *port,
{
struct sk_buff *skb;
int i, buf_size, total_size;
- u32 bm;
dma_addr_t phys_addr;
buf_size = MVPP2_RX_BUF_SIZE(bm_pool->pkt_size);
@@ -3640,13 +3639,12 @@ static int mvpp2_bm_bufs_add(struct mvpp2_port *port,
return 0;
}
- bm = mvpp2_bm_cookie_pool_set(0, bm_pool->id);
for (i = 0; i < buf_num; i++) {
skb = mvpp2_skb_alloc(port, bm_pool, &phys_addr, GFP_KERNEL);
if (!skb)
break;
- mvpp2_pool_refill(port, bm, (u32)phys_addr, (u32)skb);
+ mvpp2_bm_pool_put(port, bm_pool->id, (u32)phys_addr, (u32)skb);
}
/* Update BM driver with number of buffers added to pool */
--
2.7.4
^ permalink raw reply related
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