* [PATCH v2 1/2] mmc: sdhci-iproc: Add brcm,sdhci-iproc compat string in bindings document
From: Ulf Hansson @ 2016-11-10 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478018277-10097-2-git-send-email-scott.branden@broadcom.com>
On 1 November 2016 at 17:37, Scott Branden <scott.branden@broadcom.com> wrote:
> Adds brcm,sdhci-iproc compat string to DT bindings document for
> the iProc SDHCI driver.
>
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
> index be56d2b..954561d 100644
> --- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
> +++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
> @@ -7,6 +7,15 @@ Required properties:
> - compatible : Should be one of the following
> "brcm,bcm2835-sdhci"
> "brcm,sdhci-iproc-cygnus"
> + "brcm,sdhci-iproc"
> +
> +Use brcm2835-sdhci for Rasperry PI.
> +
> +Use sdhci-iproc-cygnus for Broadcom SDHCI Controllers
> +restricted to 32bit host accesses to SDHCI registers.
> +
> +Use sdhci-iproc for Broadcom SDHCI Controllers that allow standard
> +8, 16, 32-bit host access to SDHCI register.
>
> - clocks : The clock feeding the SDHCI controller.
>
> --
> 2.5.0
>
^ permalink raw reply
* [PATCH v6 6/9] drm/hisilicon/hibmc: Add encoder for VDAC
From: Sean Paul @ 2016-11-10 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477639682-22520-7-git-send-email-zourongrong@gmail.com>
On Fri, Oct 28, 2016 at 3:27 AM, Rongrong Zou <zourongrong@gmail.com> wrote:
> Add encoder funcs and helpers for VDAC.
>
> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
> ---
> drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 6 ++
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 89 ++++++++++++++++++++++++
> 4 files changed, 98 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile b/drivers/gpu/drm/hisilicon/hibmc/Makefile
> index 72e107e..e04f114 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
> +++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
> @@ -1,5 +1,5 @@
> ccflags-y := -Iinclude/drm
> -hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_fbdev.o hibmc_drm_power.o hibmc_ttm.o
> +hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_vdac.o hibmc_drm_fbdev.o hibmc_drm_power.o hibmc_ttm.o
>
> obj-$(CONFIG_DRM_HISI_HIBMC) +=hibmc-drm.o
> #obj-y += hibmc-drm.o
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> index 303cd36..ba191e1 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> @@ -125,6 +125,12 @@ static int hibmc_kms_init(struct hibmc_drm_device *hidev)
> return ret;
> }
>
> + ret = hibmc_encoder_init(hidev);
> + if (ret) {
> + DRM_ERROR("failed to init encoder\n");
> + return ret;
> + }
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> index 5731ec2..401cea4 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> @@ -47,6 +47,7 @@ struct hibmc_drm_device {
> struct drm_device *dev;
> struct drm_plane plane;
> struct drm_crtc crtc;
> + struct drm_encoder encoder;
Same comment here, you don't need to keep track of this
> bool mode_config_initialized;
>
> /* ttm */
> @@ -87,6 +88,7 @@ static inline struct hibmc_bo *gem_to_hibmc_bo(struct drm_gem_object *gem)
>
> int hibmc_plane_init(struct hibmc_drm_device *hidev);
> int hibmc_crtc_init(struct hibmc_drm_device *hidev);
> +int hibmc_encoder_init(struct hibmc_drm_device *hidev);
> int hibmc_fbdev_init(struct hibmc_drm_device *hidev);
> void hibmc_fbdev_fini(struct hibmc_drm_device *hidev);
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> new file mode 100644
> index 0000000..953f659
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> @@ -0,0 +1,89 @@
> +/* Hisilicon Hibmc SoC drm driver
> + *
> + * Based on the bochs drm driver.
> + *
> + * Copyright (c) 2016 Huawei Limited.
> + *
> + * Author:
> + * Rongrong Zou <zourongrong@huawei.com>
> + * Rongrong Zou <zourongrong@gmail.com>
> + * Jianhua Li <lijianhua@huawei.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + */
> +
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_crtc_helper.h>
> +
> +#include "hibmc_drm_drv.h"
> +#include "hibmc_drm_regs.h"
> +
> +static int defx = 800;
> +static int defy = 600;
> +
> +module_param(defx, int, 0444);
> +module_param(defy, int, 0444);
> +MODULE_PARM_DESC(defx, "default x resolution");
> +MODULE_PARM_DESC(defy, "default y resolution");
Not used, and I'm not sure these are a good idea
> +
> +static void hibmc_encoder_disable(struct drm_encoder *encoder)
> +{
> +}
> +
> +static void hibmc_encoder_enable(struct drm_encoder *encoder)
> +{
> +}
Null-checked, no need to stub
> +
> +static void hibmc_encoder_mode_set(struct drm_encoder *encoder,
> + struct drm_display_mode *mode,
> + struct drm_display_mode *adj_mode)
> +{
> + u32 reg;
> + struct drm_device *dev = encoder->dev;
> + struct hibmc_drm_device *hidev = dev->dev_private;
> +
> + /* just open DISPLAY_CONTROL_HISILE register bit 3:0*/
> + reg = readl(hidev->mmio + DISPLAY_CONTROL_HISILE);
> + reg |= 0xf;
Can you just pull this into a #define instead of explaining in the comment?
> + writel(reg, hidev->mmio + DISPLAY_CONTROL_HISILE);
> +}
> +
> +static int hibmc_encoder_atomic_check(struct drm_encoder *encoder,
> + struct drm_crtc_state *crtc_state,
> + struct drm_connector_state *conn_state)
> +{
> + return 0;
> +}
null-checked, remove stub
> +
> +static const struct drm_encoder_helper_funcs hibmc_encoder_helper_funcs = {
> + .mode_set = hibmc_encoder_mode_set,
> + .disable = hibmc_encoder_disable,
> + .enable = hibmc_encoder_enable,
> + .atomic_check = hibmc_encoder_atomic_check,
> +};
> +
> +static const struct drm_encoder_funcs hibmc_encoder_encoder_funcs = {
> + .destroy = drm_encoder_cleanup,
> +};
> +
> +int hibmc_encoder_init(struct hibmc_drm_device *hidev)
> +{
> + struct drm_device *dev = hidev->dev;
> + struct drm_encoder *encoder = &hidev->encoder;
> + int ret;
> +
> + encoder->possible_crtcs = 0x1;
> + ret = drm_encoder_init(dev, encoder, &hibmc_encoder_encoder_funcs,
> + DRM_MODE_ENCODER_DAC, NULL);
> + if (ret) {
> + DRM_ERROR("failed to init encoder\n");
print ret
> + return ret;
> + }
> +
> + drm_encoder_helper_add(encoder, &hibmc_encoder_helper_funcs);
> + return 0;
> +}
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 5/9] drm/hisilicon/hibmc: Add crtc for DE
From: Sean Paul @ 2016-11-10 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477639682-22520-6-git-send-email-zourongrong@gmail.com>
On Fri, Oct 28, 2016 at 3:27 AM, Rongrong Zou <zourongrong@gmail.com> wrote:
> Add crtc funcs and helper funcs for DE.
>
> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
> ---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 318 ++++++++++++++++++++++++
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 6 +
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +
> 3 files changed, 326 insertions(+)
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> index 9c1a68c..9b5d0d0 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> @@ -23,6 +23,7 @@
>
> #include "hibmc_drm_drv.h"
> #include "hibmc_drm_regs.h"
> +#include "hibmc_drm_de.h"
> #include "hibmc_drm_power.h"
nit: alphabetize
>
> /* ---------------------------------------------------------------------- */
Remove
> @@ -168,3 +169,320 @@ int hibmc_plane_init(struct hibmc_drm_device *hidev)
> drm_plane_helper_add(plane, &hibmc_plane_helper_funcs);
> return 0;
> }
> +
> +static void hibmc_crtc_enable(struct drm_crtc *crtc)
> +{
> + unsigned int reg;
> + /* power mode 0 is default. */
This comment seems to be in the wrong place
> + struct hibmc_drm_device *hidev = crtc->dev->dev_private;
> +
> + hibmc_set_power_mode(hidev, HIBMC_PW_MODE_CTL_MODE_MODE0);
> +
> + /* Enable display power gate & LOCALMEM power gate*/
> + reg = readl(hidev->mmio + HIBMC_CURRENT_GATE);
> + reg &= ~HIBMC_CURR_GATE_LOCALMEM_MASK;
> + reg &= ~HIBMC_CURR_GATE_DISPLAY_MASK;
> + reg |= HIBMC_CURR_GATE_LOCALMEM(ON);
> + reg |= HIBMC_CURR_GATE_DISPLAY(ON);
> + hibmc_set_current_gate(hidev, reg);
> + drm_crtc_vblank_on(crtc);
> +}
> +
> +static void hibmc_crtc_disable(struct drm_crtc *crtc)
> +{
> + unsigned int reg;
> + struct hibmc_drm_device *hidev = crtc->dev->dev_private;
> +
> + drm_crtc_vblank_off(crtc);
> +
> + hibmc_set_power_mode(hidev, HIBMC_PW_MODE_CTL_MODE_SLEEP);
> +
> + /* Enable display power gate & LOCALMEM power gate*/
> + reg = readl(hidev->mmio + HIBMC_CURRENT_GATE);
> + reg &= ~HIBMC_CURR_GATE_LOCALMEM_MASK;
> + reg &= ~HIBMC_CURR_GATE_DISPLAY_MASK;
> + reg |= HIBMC_CURR_GATE_LOCALMEM(OFF);
> + reg |= HIBMC_CURR_GATE_DISPLAY(OFF);
> + hibmc_set_current_gate(hidev, reg);
> +}
> +
> +static int hibmc_crtc_atomic_check(struct drm_crtc *crtc,
> + struct drm_crtc_state *state)
> +{
> + return 0;
> +}
Caller NULL-checks, no need for stub
> +
> +static unsigned int format_pll_reg(void)
> +{
> + unsigned int pllreg = 0;
> + struct panel_pll pll = {0};
> +
> + /* Note that all PLL's have the same format. Here,
> + * we just use Panel PLL parameter to work out the bit
> + * fields in the register.On returning a 32 bit number, the value can
> + * be applied to any PLL in the calling function.
> + */
> + pllreg |= HIBMC_PLL_CTRL_BYPASS(OFF) & HIBMC_PLL_CTRL_BYPASS_MASK;
> + pllreg |= HIBMC_PLL_CTRL_POWER(ON) & HIBMC_PLL_CTRL_POWER_MASK;
> + pllreg |= HIBMC_PLL_CTRL_INPUT(OSC) & HIBMC_PLL_CTRL_INPUT_MASK;
> + pllreg |= HIBMC_PLL_CTRL_POD(pll.POD) & HIBMC_PLL_CTRL_POD_MASK;
> + pllreg |= HIBMC_PLL_CTRL_OD(pll.OD) & HIBMC_PLL_CTRL_OD_MASK;
> + pllreg |= HIBMC_PLL_CTRL_N(pll.N) & HIBMC_PLL_CTRL_N_MASK;
> + pllreg |= HIBMC_PLL_CTRL_M(pll.M) & HIBMC_PLL_CTRL_M_MASK;
> +
> + return pllreg;
> +}
> +
> +static void set_vclock_hisilicon(struct drm_device *dev, unsigned long pll)
> +{
> + unsigned long tmp0, tmp1;
> + struct hibmc_drm_device *hidev = dev->dev_private;
> +
> + /* 1. outer_bypass_n=0 */
> + tmp0 = readl(hidev->mmio + CRT_PLL1_HS);
> + tmp0 &= 0xBFFFFFFF;
> + writel(tmp0, hidev->mmio + CRT_PLL1_HS);
> +
> + /* 2. pll_pd=1?inter_bypass=1 */
> + writel(0x21000000, hidev->mmio + CRT_PLL1_HS);
> +
> + /* 3. config pll */
> + writel(pll, hidev->mmio + CRT_PLL1_HS);
> +
> + /* 4. delay */
> + mdelay(1);
These should be usleep_range() see
https://www.kernel.org/doc/Documentation/timers/timers-howto.txt
> +
> + /* 5. pll_pd =0 */
> + tmp1 = pll & ~0x01000000;
> + writel(tmp1, hidev->mmio + CRT_PLL1_HS);
> +
> + /* 6. delay */
> + mdelay(1);
> +
> + /* 7. inter_bypass=0 */
> + tmp1 &= ~0x20000000;
> + writel(tmp1, hidev->mmio + CRT_PLL1_HS);
> +
> + /* 8. delay */
> + mdelay(1);
> +
> + /* 9. outer_bypass_n=1 */
> + tmp1 |= 0x40000000;
> + writel(tmp1, hidev->mmio + CRT_PLL1_HS);
This function is a whole lot of magic. Any chance you can pull the
values out into #defines?
> +}
> +
> +/* This function takes care the extra registers and bit fields required to
nit: multi-line comments have a leading /* line with the comment
starting on the following line
applies below as well
> + *setup a mode in board.
nit: space between * and comment, ie: * setup a mode in board
applies to the rest of the comment too
> + *Explanation about Display Control register:
> + *FPGA only supports 7 predefined pixel clocks, and clock select is
> + *in bit 4:0 of new register 0x802a8.
> + */
> +static unsigned int display_ctrl_adjust(struct drm_device *dev,
> + struct drm_display_mode *mode,
> + unsigned int ctrl)
> +{
> + unsigned long x, y;
> + unsigned long pll1; /* bit[31:0] of PLL */
> + unsigned long pll2; /* bit[63:32] of PLL */
> + struct hibmc_drm_device *hidev = dev->dev_private;
> +
> + x = mode->hdisplay;
> + y = mode->vdisplay;
> +
> + /* Hisilicon has to set up a new register for PLL control
> + *(CRT_PLL1_HS & CRT_PLL2_HS).
> + */
> + if (x == 800 && y == 600) {
> + pll1 = CRT_PLL1_HS_40MHZ;
> + pll2 = CRT_PLL2_HS_40MHZ;
> + } else if (x == 1024 && y == 768) {
> + pll1 = CRT_PLL1_HS_65MHZ;
> + pll2 = CRT_PLL2_HS_65MHZ;
> + } else if (x == 1152 && y == 864) {
> + pll1 = CRT_PLL1_HS_80MHZ_1152;
> + pll2 = CRT_PLL2_HS_80MHZ;
> + } else if (x == 1280 && y == 768) {
> + pll1 = CRT_PLL1_HS_80MHZ;
> + pll2 = CRT_PLL2_HS_80MHZ;
> + } else if (x == 1280 && y == 720) {
> + pll1 = CRT_PLL1_HS_74MHZ;
> + pll2 = CRT_PLL2_HS_74MHZ;
> + } else if (x == 1280 && y == 960) {
> + pll1 = CRT_PLL1_HS_108MHZ;
> + pll2 = CRT_PLL2_HS_108MHZ;
> + } else if (x == 1280 && y == 1024) {
> + pll1 = CRT_PLL1_HS_108MHZ;
> + pll2 = CRT_PLL2_HS_108MHZ;
> + } else if (x == 1600 && y == 1200) {
> + pll1 = CRT_PLL1_HS_162MHZ;
> + pll2 = CRT_PLL2_HS_162MHZ;
> + } else if (x == 1920 && y == 1080) {
> + pll1 = CRT_PLL1_HS_148MHZ;
> + pll2 = CRT_PLL2_HS_148MHZ;
> + } else if (x == 1920 && y == 1200) {
> + pll1 = CRT_PLL1_HS_193MHZ;
> + pll2 = CRT_PLL2_HS_193MHZ;
> + } else /* default to VGA clock */ {
> + pll1 = CRT_PLL1_HS_25MHZ;
> + pll2 = CRT_PLL2_HS_25MHZ;
> + }
This seems like something that should be checked in atomic_check so
you can be sure the mode is supported.
It would also be nice to pull this out into a separate function (and a
lookup table if you're feeling adventurous)
> +
> + writel(pll2, hidev->mmio + CRT_PLL2_HS);
> + set_vclock_hisilicon(dev, pll1);
> +
> + /* Hisilicon has to set up the top-left and bottom-right
> + * registers as well.
> + * Note that normal chip only use those two register for
> + * auto-centering mode.
> + */
> + writel((HIBMC_CRT_AUTO_CENTERING_TL_TOP(0) &
> + HIBMC_CRT_AUTO_CENTERING_TL_TOP_MSK) |
> + (HIBMC_CRT_AUTO_CENTERING_TL_LEFT(0) &
> + HIBMC_CRT_AUTO_CENTERING_TL_LEFT_MSK),
> + hidev->mmio + HIBMC_CRT_AUTO_CENTERING_TL);
> +
> + writel((HIBMC_CRT_AUTO_CENTERING_BR_BOTTOM(y - 1) &
> + HIBMC_CRT_AUTO_CENTERING_BR_BOTTOM_MASK) |
> + (HIBMC_CRT_AUTO_CENTERING_BR_RIGHT(x - 1) &
> + HIBMC_CRT_AUTO_CENTERING_BR_RIGHT_MASK),
> + hidev->mmio + HIBMC_CRT_AUTO_CENTERING_BR);
> +
> + /* Assume common fields in ctrl have been properly set before
> + * calling this function.
> + * This function only sets the extra fields in ctrl.
> + */
> +
> + /* Set bit 25 of display controller: Select CRT or VGA clock */
> + ctrl &= ~HIBMC_CRT_DISP_CTL_CRTSELECT_MASK;
> + ctrl &= ~HIBMC_CRT_DISP_CTL_CLOCK_PHASE_MASK;
> +
> + ctrl |= HIBMC_CRT_DISP_CTL_CRTSELECT(CRTSELECT_CRT);
> +
> + /*ctrl = FIELD_SET(ctrl, HIBMC_CRT_DISP_CTL, CRTSELECT, CRT);*/
What's the deal with this commented code?
> +
> + /* Set bit 14 of display controller */
> + /*ctrl &= FIELD_CLEAR(HIBMC_CRT_DISP_CTL, CLOCK_PHASE);*/
> +
> + /* clock_phase_polarity is 0 */
> + ctrl |= HIBMC_CRT_DISP_CTL_CLOCK_PHASE(PHASE_ACTIVE_HIGH);
> + /*ctrl = FIELD_SET(ctrl, HIBMC_CRT_DISP_CTL,*/
> + /*CLOCK_PHASE, ACTIVE_HIGH);*/
Here too...
> +
> + writel(ctrl, hidev->mmio + HIBMC_CRT_DISP_CTL);
> +
> + return ctrl;
> +}
> +
> +static void hibmc_crtc_mode_set_nofb(struct drm_crtc *crtc)
> +{
> + unsigned int val;
> + struct drm_display_mode *mode = &crtc->state->mode;
> + struct drm_device *dev = crtc->dev;
> + struct hibmc_drm_device *hidev = dev->dev_private;
> +
> + writel(format_pll_reg(), hidev->mmio + HIBMC_CRT_PLL_CTRL);
> + writel((HIBMC_CRT_HORZ_TOTAL_TOTAL(mode->htotal - 1) &
> + HIBMC_CRT_HORZ_TOTAL_TOTAL_MASK) |
> + (HIBMC_CRT_HORZ_TOTAL_DISPLAY_END(mode->hdisplay - 1) &
> + HIBMC_CRT_HORZ_TOTAL_DISPLAY_END_MASK),
You could probably macroize this code to make it more readable
> + hidev->mmio + HIBMC_CRT_HORZ_TOTAL);
> +
> + writel((HIBMC_CRT_HORZ_SYNC_WIDTH(mode->hsync_end - mode->hsync_start)
> + & HIBMC_CRT_HORZ_SYNC_WIDTH_MASK) |
> + (HIBMC_CRT_HORZ_SYNC_START(mode->hsync_start - 1)
> + & HIBMC_CRT_HORZ_SYNC_START_MASK),
> + hidev->mmio + HIBMC_CRT_HORZ_SYNC);
> +
> + writel((HIBMC_CRT_VERT_TOTAL_TOTAL(mode->vtotal - 1) &
> + HIBMC_CRT_VERT_TOTAL_TOTAL_MASK) |
> + (HIBMC_CRT_VERT_TOTAL_DISPLAY_END(mode->vdisplay - 1) &
> + HIBMC_CRT_VERT_TOTAL_DISPLAY_END_MASK),
> + hidev->mmio + HIBMC_CRT_VERT_TOTAL);
> +
> + writel((HIBMC_CRT_VERT_SYNC_HEIGHT(mode->vsync_end - mode->vsync_start)
> + & HIBMC_CRT_VERT_SYNC_HEIGHT_MASK) |
> + (HIBMC_CRT_VERT_SYNC_START(mode->vsync_start - 1) &
> + HIBMC_CRT_VERT_SYNC_START_MASK),
> + hidev->mmio + HIBMC_CRT_VERT_SYNC);
> +
> + val = HIBMC_CRT_DISP_CTL_VSYNC_PHASE(0) &
> + HIBMC_CRT_DISP_CTL_VSYNC_PHASE_MASK;
> + val |= HIBMC_CRT_DISP_CTL_HSYNC_PHASE(0) &
> + HIBMC_CRT_DISP_CTL_HSYNC_PHASE_MASK;
> + val |= HIBMC_CRT_DISP_CTL_TIMING(ENABLE);
> + val |= HIBMC_CRT_DISP_CTL_PLANE(ENABLE);
> +
> + display_ctrl_adjust(dev, mode, val);
> +}
> +
> +static void hibmc_crtc_atomic_begin(struct drm_crtc *crtc,
> + struct drm_crtc_state *old_state)
> +{
> + unsigned int reg;
> + struct drm_device *dev = crtc->dev;
> + struct hibmc_drm_device *hidev = dev->dev_private;
> +
> + hibmc_set_power_mode(hidev, HIBMC_PW_MODE_CTL_MODE_MODE0);
> +
> + /* Enable display power gate & LOCALMEM power gate*/
> + reg = readl(hidev->mmio + HIBMC_CURRENT_GATE);
> + reg &= ~HIBMC_CURR_GATE_DISPLAY_MASK;
> + reg &= ~HIBMC_CURR_GATE_LOCALMEM_MASK;
> + reg |= HIBMC_CURR_GATE_DISPLAY(ON);
> + reg |= HIBMC_CURR_GATE_LOCALMEM(ON);
> + hibmc_set_current_gate(hidev, reg);
> +
> + /* We can add more initialization as needed. */
> +}
> +
> +static void hibmc_crtc_atomic_flush(struct drm_crtc *crtc,
> + struct drm_crtc_state *old_state)
> +
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&crtc->dev->event_lock, flags);
> + if (crtc->state->event)
> + drm_crtc_send_vblank_event(crtc, crtc->state->event);
> + crtc->state->event = NULL;
> +
> + spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
> +}
> +
> +/* These provide the minimum set of functions required to handle a CRTC */
nit: don't need this comment
> +static const struct drm_crtc_funcs hibmc_crtc_funcs = {
> + .page_flip = drm_atomic_helper_page_flip,
> + .set_config = drm_atomic_helper_set_config,
> + .destroy = drm_crtc_cleanup,
> + .reset = drm_atomic_helper_crtc_reset,
> + .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> +};
> +
> +static const struct drm_crtc_helper_funcs hibmc_crtc_helper_funcs = {
> + .enable = hibmc_crtc_enable,
> + .disable = hibmc_crtc_disable,
> + .mode_set_nofb = hibmc_crtc_mode_set_nofb,
> + .atomic_check = hibmc_crtc_atomic_check,
> + .atomic_begin = hibmc_crtc_atomic_begin,
> + .atomic_flush = hibmc_crtc_atomic_flush,
> +};
> +
> +int hibmc_crtc_init(struct hibmc_drm_device *hidev)
> +{
> + struct drm_device *dev = hidev->dev;
> + struct drm_crtc *crtc = &hidev->crtc;
> + struct drm_plane *plane = &hidev->plane;
> + int ret;
> +
> + ret = drm_crtc_init_with_planes(dev, crtc, plane,
> + NULL, &hibmc_crtc_funcs, NULL);
> + if (ret) {
> + DRM_ERROR("failed to init crtc.\n");
print return code
> + return ret;
> + }
> +
> + drm_mode_crtc_set_gamma_size(crtc, 256);
check return code
> + drm_crtc_helper_add(crtc, &hibmc_crtc_helper_funcs);
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> index 7d96583..303cd36 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> @@ -119,6 +119,12 @@ static int hibmc_kms_init(struct hibmc_drm_device *hidev)
> return ret;
> }
>
> + ret = hibmc_crtc_init(hidev);
> + if (ret) {
> + DRM_ERROR("failed to init crtc.\n");
> + return ret;
> + }
Typically the plane is initialized internally in the crtc driver. I
think this is a good design pattern, and you should probably use it.
So how about squashing this down with the plane patch and keeping the
plane inside hibmc_drm_de.c?
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> index 49e39d2..5731ec2 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> @@ -46,6 +46,7 @@ struct hibmc_drm_device {
> /* drm */
> struct drm_device *dev;
> struct drm_plane plane;
I don't think you should be keeping track of plane here. plane is only
used in the crtc init, which should be addressed by the previous
comment.
> + struct drm_crtc crtc;
crtc is only used in the irq handler, so you could remove this here
and just call drm_handle_vblank(dev, 0) in the handler.
> bool mode_config_initialized;
>
> /* ttm */
> @@ -85,6 +86,7 @@ static inline struct hibmc_bo *gem_to_hibmc_bo(struct drm_gem_object *gem)
> #define DRM_FILE_PAGE_OFFSET (0x100000000ULL >> PAGE_SHIFT)
>
> int hibmc_plane_init(struct hibmc_drm_device *hidev);
> +int hibmc_crtc_init(struct hibmc_drm_device *hidev);
> int hibmc_fbdev_init(struct hibmc_drm_device *hidev);
> void hibmc_fbdev_fini(struct hibmc_drm_device *hidev);
>
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH fpga 9/9] fpga: Remove support for non-sg drivers
From: Joshua Clayton @ 2016-11-10 22:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110163315.GB22004@obsidianresearch.com>
On 11/10/2016 08:33 AM, Jason Gunthorpe wrote:
>>> struct fpga_manager_ops {
>>> enum fpga_mgr_states (*state)(struct fpga_manager *mgr);
>>> - int (*write_init)(struct fpga_manager *mgr, u32 flags,
>>> - const char *buf, size_t count);
>>> - int (*write)(struct fpga_manager *mgr, const char *buf, size_t count);
>>> int (*write_init_sg)(struct fpga_manager *mgr, u32 flags,
>>> struct sg_table *sgt);
>>> int (*write_sg)(struct fpga_manager *mgr, struct sg_table *sgt);
>>> @@ -118,6 +113,8 @@ struct fpga_manager {
>>>
>>> int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags,
>>> const char *buf, size_t count);
>>> +int fpga_mgr_buf_load_sg(struct fpga_manager *mgr, u32 flags,
>>> + struct sg_table *sgt);
>>>
>>> int fpga_mgr_firmware_load(struct fpga_manager *mgr, u32 flags,
>>> const char *image_name);
>> I don't have any feeling either way about switching to scatter-gather.
>> (Not zynq or socfpga user)
>> But I do object to renaming the API.
>> write_init() and write() do not imply a particular implementation, nor even that
>> the buffer is coherent.
> Neither the sg or old linear interface imply any particular
> underlying driver implementation.
>
> All that is being changed is how the list of physical pages gets
> passed to the driver. The linear interface requires them to be
> contiguously mapped (eg in a vmap) while the SG interface
> directly passes a list of physical page addresses.
>
> Any alogrithm that works with the old interface can run on the new
> interface, and the new interface can support much better options for
> DMA drivers, while not requiring the higher layers to perform a high
> order allocation (vmap or otherwise) to create the contiguous memory.
>
> The reason the old interface is being deleted here is so the fpga mgr
> API can be expanded to accept a sg list directly. Since we cannot
> convert a general sg list to linear memory the liner option must be
> totally removed.
OK. That sounds reasonable.
>> I am working to merge an fpga manager which uses SPI to load the bitstream
>> (see https://www.spinics.net/lists/arm-kernel/msg539328.html)
>> Any dma in use there would come from the spi driver. write_init_sg, and write_sg
>> don't make any sense in my case.
> No, it still make lots of sense.
>
> SPI has been slowly transforming to use the same sort of SG scheme
> universally, including facing the client. (see
> 6ad45a27cbe343ec8d7888e5edf6335499a4b555)
Thanks for sharing that link.
>
> Some day your driver can just pass the SGs directly to spi and
> everything will be great.
>
> In the mean time it can do sg_miter_next to get mapped buffers.
..so I have a way forward if this series gets merged.
That was my main concern.
And as a dma n00b, learning to use dma engine structures to do
non-dma xfer was not very high on my list.
>> Would it not make sense to keep the top level API the same?
> Fundamentally no.
>
> Jason
Joshua
^ permalink raw reply
* [PATCH -next] cpufreq: brcmstb-avs-cpufreq: make symbol brcm_avs_cpufreq_attr static
From: Markus Mayer @ 2016-11-10 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791145-21137-1-git-send-email-weiyj.lk@gmail.com>
On 10 November 2016 at 07:19, Wei Yongjun <weiyj.lk@gmail.com> wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warning:
>
> drivers/cpufreq/brcmstb-avs-cpufreq.c:982:18: warning:
> symbol 'brcm_avs_cpufreq_attr' was not declared. Should it be static?
Yes, thanks for the fix.
Acked-by: Markus Mayer <mmayer@broadcom.com>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/cpufreq/brcmstb-avs-cpufreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c b/drivers/cpufreq/brcmstb-avs-cpufreq.c
> index b761d54..4fda623 100644
> --- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
> +++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
> @@ -979,7 +979,7 @@ cpufreq_freq_attr_ro(brcm_avs_pmap);
> cpufreq_freq_attr_ro(brcm_avs_voltage);
> cpufreq_freq_attr_ro(brcm_avs_frequency);
>
> -struct freq_attr *brcm_avs_cpufreq_attr[] = {
> +static struct freq_attr *brcm_avs_cpufreq_attr[] = {
> &cpufreq_freq_attr_scaling_available_freqs,
> &brcm_avs_pstate,
> &brcm_avs_mode,
>
^ permalink raw reply
* [PATCH v6 4/9] drm/hisilicon/hibmc: Add plane for DE
From: Sean Paul @ 2016-11-10 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477639682-22520-5-git-send-email-zourongrong@gmail.com>
On Fri, Oct 28, 2016 at 3:27 AM, Rongrong Zou <zourongrong@gmail.com> wrote:
> Add plane funcs and helper funcs for DE.
>
> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
> ---
> drivers/gpu/drm/hisilicon/hibmc/Kconfig | 1 +
> drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 170 ++++++++++++++++++++++++
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.h | 29 ++++
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 51 ++++++-
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 5 +
> drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 6 +
> 7 files changed, 261 insertions(+), 3 deletions(-)
> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> create mode 100644 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.h
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
> index bcb8c18..380622a 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/Kconfig
> +++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
> @@ -1,6 +1,7 @@
> config DRM_HISI_HIBMC
> tristate "DRM Support for Hisilicon Hibmc"
> depends on DRM && PCI
> + select DRM_KMS_HELPER
> select DRM_TTM
>
> help
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile b/drivers/gpu/drm/hisilicon/hibmc/Makefile
> index 810a37e..72e107e 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/Makefile
> +++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
> @@ -1,5 +1,5 @@
> ccflags-y := -Iinclude/drm
> -hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_fbdev.o hibmc_drm_power.o hibmc_ttm.o
> +hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_de.o hibmc_drm_fbdev.o hibmc_drm_power.o hibmc_ttm.o
>
> obj-$(CONFIG_DRM_HISI_HIBMC) +=hibmc-drm.o
> #obj-y += hibmc-drm.o
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> new file mode 100644
> index 0000000..9c1a68c
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> @@ -0,0 +1,170 @@
> +/* Hisilicon Hibmc SoC drm driver
> + *
> + * Based on the bochs drm driver.
> + *
> + * Copyright (c) 2016 Huawei Limited.
> + *
> + * Author:
> + * Rongrong Zou <zourongrong@huawei.com>
> + * Rongrong Zou <zourongrong@gmail.com>
> + * Jianhua Li <lijianhua@huawei.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + */
> +
> +#include <drm/drm_atomic.h>
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_crtc_helper.h>
> +#include <drm/drm_plane_helper.h>
> +
> +#include "hibmc_drm_drv.h"
> +#include "hibmc_drm_regs.h"
> +#include "hibmc_drm_power.h"
> +
> +/* ---------------------------------------------------------------------- */
Remove
> +
> +static int hibmc_plane_atomic_check(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + struct drm_framebuffer *fb = state->fb;
> + struct drm_crtc *crtc = state->crtc;
> + struct drm_crtc_state *crtc_state;
> + u32 src_x = state->src_x >> 16;
> + u32 src_y = state->src_y >> 16;
> + u32 src_w = state->src_w >> 16;
> + u32 src_h = state->src_h >> 16;
> + int crtc_x = state->crtc_x;
> + int crtc_y = state->crtc_y;
> + u32 crtc_w = state->crtc_w;
> + u32 crtc_h = state->crtc_h;
I don't think you gain anything with the crtc_* vars
> +
> + if (!crtc || !fb)
> + return 0;
> +
> + crtc_state = drm_atomic_get_crtc_state(state->state, crtc);
> + if (IS_ERR(crtc_state))
> + return PTR_ERR(crtc_state);
> +
> + if (src_w != crtc_w || src_h != crtc_h) {
> + DRM_ERROR("Scale not support!!!\n");
I like the enthusiasm, but I think DRM_DEBUG_ATOMIC would be better
> + return -EINVAL;
> + }
> +
> + if (src_x + src_w > fb->width ||
> + src_y + src_h > fb->height)
These should be already covered in drm_atomic_plane_check
> + return -EINVAL;
> +
> + if (crtc_x < 0 || crtc_y < 0)
Print DRM_DEBUG_ATOMIC message here
> + return -EINVAL;
> +
> + if (crtc_x + crtc_w > crtc_state->adjusted_mode.hdisplay ||
> + crtc_y + crtc_h > crtc_state->adjusted_mode.vdisplay)
DRM_DEBUG_ATOMIC here too
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static void hibmc_plane_atomic_update(struct drm_plane *plane,
> + struct drm_plane_state *old_state)
> +{
> + struct drm_plane_state *state = plane->state;
> + u32 reg;
> + int ret;
> + u64 gpu_addr = 0;
> + unsigned int line_l;
> + struct hibmc_drm_device *hidev =
> + (struct hibmc_drm_device *)plane->dev->dev_private;
> +
nit: extra line
> + struct hibmc_framebuffer *hibmc_fb;
> + struct hibmc_bo *bo;
> +
> + hibmc_fb = to_hibmc_framebuffer(state->fb);
> + bo = gem_to_hibmc_bo(hibmc_fb->obj);
> + ret = ttm_bo_reserve(&bo->bo, true, false, NULL);
> + if (ret)
Print error
> + return;
> +
> + hibmc_bo_pin(bo, TTM_PL_FLAG_VRAM, &gpu_addr);
Check return value
> + if (ret) {
> + ttm_bo_unreserve(&bo->bo);
> + return;
> + }
> +
> + ttm_bo_unreserve(&bo->bo);
Move this up before the conditional so you don't have to call it in
both branches
> +
> + writel(gpu_addr, hidev->mmio + HIBMC_CRT_FB_ADDRESS);
> +
> + reg = state->fb->width * (state->fb->bits_per_pixel >> 3);
> + /* now line_pad is 16 */
> + reg = PADDING(16, reg);
> +
> + line_l = state->fb->width * state->fb->bits_per_pixel / 8;
above, you >> 3. here you / 8, pick one?
> + line_l = PADDING(16, line_l);
> + writel((HIBMC_CRT_FB_WIDTH_WIDTH(reg) & HIBMC_CRT_FB_WIDTH_WIDTH_MASK) |
> + (HIBMC_CRT_FB_WIDTH_OFFS(line_l) & HIBMC_CRT_FB_WIDTH_OFFS_MASK),
> + hidev->mmio + HIBMC_CRT_FB_WIDTH);
> +
> + /* SET PIXEL FORMAT */
> + reg = readl(hidev->mmio + HIBMC_CRT_DISP_CTL);
> + reg = reg & ~HIBMC_CRT_DISP_CTL_FORMAT_MASK;
> + reg = reg | (HIBMC_CRT_DISP_CTL_FORMAT(state->fb->bits_per_pixel >> 4) &
> + HIBMC_CRT_DISP_CTL_FORMAT_MASK);
> + writel(reg, hidev->mmio + HIBMC_CRT_DISP_CTL);
> +}
> +
> +static void hibmc_plane_atomic_disable(struct drm_plane *plane,
> + struct drm_plane_state *old_state)
> +{
> +}
The caller checks for NULL, no need to stub
> +
> +static const u32 channel_formats1[] = {
> + DRM_FORMAT_RGB565, DRM_FORMAT_BGR565, DRM_FORMAT_RGB888,
> + DRM_FORMAT_BGR888, DRM_FORMAT_XRGB8888, DRM_FORMAT_XBGR8888,
> + DRM_FORMAT_RGBA8888, DRM_FORMAT_BGRA8888, DRM_FORMAT_ARGB8888,
> + DRM_FORMAT_ABGR8888
> +};
> +
> +static struct drm_plane_funcs hibmc_plane_funcs = {
> + .update_plane = drm_atomic_helper_update_plane,
> + .disable_plane = drm_atomic_helper_disable_plane,
> + .set_property = drm_atomic_helper_plane_set_property,
> + .destroy = drm_plane_cleanup,
> + .reset = drm_atomic_helper_plane_reset,
> + .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> +};
> +
> +static const struct drm_plane_helper_funcs hibmc_plane_helper_funcs = {
> + .atomic_check = hibmc_plane_atomic_check,
> + .atomic_update = hibmc_plane_atomic_update,
> + .atomic_disable = hibmc_plane_atomic_disable,
> +};
> +
> +int hibmc_plane_init(struct hibmc_drm_device *hidev)
> +{
> + struct drm_device *dev = hidev->dev;
> + struct drm_plane *plane = &hidev->plane;
> + int ret = 0;
> +
> + /*
> + * plane init
> + * TODO: Now only support primary plane, overlay planes
> + * need to do.
> + */
> + ret = drm_universal_plane_init(dev, plane, 1, &hibmc_plane_funcs,
> + channel_formats1,
> + ARRAY_SIZE(channel_formats1),
> + DRM_PLANE_TYPE_PRIMARY,
> + NULL);
> + if (ret) {
> + DRM_ERROR("fail to init plane!!!\n");
> + return ret;
> + }
> +
> + drm_plane_helper_add(plane, &hibmc_plane_helper_funcs);
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.h
> new file mode 100644
> index 0000000..4ce0d7b
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.h
> @@ -0,0 +1,29 @@
> +/* Hisilicon Hibmc SoC drm driver
> + *
> + * Based on the bochs drm driver.
> + *
> + * Copyright (c) 2016 Huawei Limited.
> + *
> + * Author:
> + * Rongrong Zou <zourongrong@huawei.com>
> + * Rongrong Zou <zourongrong@gmail.com>
> + * Jianhua Li <lijianhua@huawei.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + */
> +
> +#ifndef HIBMC_DRM_DE_H
> +#define HIBMC_DRM_DE_H
> +
> +struct panel_pll {
> + unsigned long M;
> + unsigned long N;
> + unsigned long OD;
> + unsigned long POD;
> +};
> +
> +#endif
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> index 5ac7a7e..7d96583 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> @@ -18,6 +18,7 @@
>
> #include <linux/module.h>
> #include <linux/console.h>
> +#include <drm/drm_crtc_helper.h>
>
> #include "hibmc_drm_drv.h"
> #include "hibmc_drm_regs.h"
> @@ -47,8 +48,8 @@ static void hibmc_disable_vblank(struct drm_device *dev, unsigned int pipe)
> }
>
> static struct drm_driver hibmc_driver = {
> - .driver_features = DRIVER_GEM,
> -
> + .driver_features = DRIVER_GEM | DRIVER_MODESET |
> + DRIVER_ATOMIC,
> .fops = &hibmc_fops,
> .name = "hibmc",
> .date = "20160828",
> @@ -70,6 +71,7 @@ static int hibmc_pm_suspend(struct device *dev)
> struct drm_device *drm_dev = pci_get_drvdata(pdev);
> struct hibmc_drm_device *hidev = drm_dev->dev_private;
>
> + drm_kms_helper_poll_disable(drm_dev);
> drm_fb_helper_set_suspend_unlocked(&hidev->fbdev->helper, 1);
>
> return 0;
> @@ -81,7 +83,9 @@ static int hibmc_pm_resume(struct device *dev)
> struct drm_device *drm_dev = pci_get_drvdata(pdev);
> struct hibmc_drm_device *hidev = drm_dev->dev_private;
>
> + drm_helper_resume_force_mode(drm_dev);
> drm_fb_helper_set_suspend_unlocked(&hidev->fbdev->helper, 0);
> + drm_kms_helper_poll_enable(drm_dev);
>
> return 0;
> }
> @@ -91,6 +95,41 @@ static int hibmc_pm_resume(struct device *dev)
> hibmc_pm_resume)
> };
>
> +static int hibmc_kms_init(struct hibmc_drm_device *hidev)
> +{
> + int ret;
> +
> + drm_mode_config_init(hidev->dev);
> + hidev->mode_config_initialized = true;
> +
> + hidev->dev->mode_config.min_width = 0;
> + hidev->dev->mode_config.min_height = 0;
> + hidev->dev->mode_config.max_width = 1920;
> + hidev->dev->mode_config.max_height = 1440;
> +
> + hidev->dev->mode_config.fb_base = hidev->fb_base;
> + hidev->dev->mode_config.preferred_depth = 24;
> + hidev->dev->mode_config.prefer_shadow = 0;
> +
> + hidev->dev->mode_config.funcs = (void *)&hibmc_mode_funcs;
> +
> + ret = hibmc_plane_init(hidev);
> + if (ret) {
> + DRM_ERROR("fail to init plane!!!\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void hibmc_kms_fini(struct hibmc_drm_device *hidev)
> +{
> + if (hidev->mode_config_initialized) {
> + drm_mode_config_cleanup(hidev->dev);
> + hidev->mode_config_initialized = false;
> + }
> +}
> +
> static int hibmc_hw_config(struct hibmc_drm_device *hidev)
> {
> unsigned int reg;
> @@ -183,6 +222,7 @@ static int hibmc_unload(struct drm_device *dev)
> struct hibmc_drm_device *hidev = dev->dev_private;
>
> hibmc_fbdev_fini(hidev);
> + hibmc_kms_fini(hidev);
> hibmc_mm_fini(hidev);
> hibmc_hw_fini(hidev);
> dev->dev_private = NULL;
> @@ -208,6 +248,13 @@ static int hibmc_load(struct drm_device *dev, unsigned long flags)
> if (ret)
> goto err;
>
> + ret = hibmc_kms_init(hidev);
> + if (ret)
> + goto err;
> +
> + /* reset all the states of crtc/plane/encoder/connector */
> + drm_mode_config_reset(dev);
> +
> ret = hibmc_fbdev_init(hidev);
> if (ret)
> goto err;
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> index a40e9a7..49e39d2 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> @@ -45,6 +45,8 @@ struct hibmc_drm_device {
>
> /* drm */
> struct drm_device *dev;
> + struct drm_plane plane;
> + bool mode_config_initialized;
>
> /* ttm */
> struct {
> @@ -82,6 +84,7 @@ static inline struct hibmc_bo *gem_to_hibmc_bo(struct drm_gem_object *gem)
>
> #define DRM_FILE_PAGE_OFFSET (0x100000000ULL >> PAGE_SHIFT)
>
> +int hibmc_plane_init(struct hibmc_drm_device *hidev);
> int hibmc_fbdev_init(struct hibmc_drm_device *hidev);
> void hibmc_fbdev_fini(struct hibmc_drm_device *hidev);
>
> @@ -102,4 +105,6 @@ int hibmc_dumb_mmap_offset(struct drm_file *file, struct drm_device *dev,
> u32 handle, u64 *offset);
> int hibmc_mmap(struct file *filp, struct vm_area_struct *vma);
>
> +extern const struct drm_mode_config_funcs hibmc_mode_funcs;
> +
> #endif
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
> index 9822f62..beb4d76 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
> @@ -554,3 +554,9 @@ struct hibmc_framebuffer *
> }
> return &hibmc_fb->fb;
> }
> +
> +const struct drm_mode_config_funcs hibmc_mode_funcs = {
> + .atomic_check = drm_atomic_helper_check,
> + .atomic_commit = drm_atomic_helper_commit,
> + .fb_create = hibmc_user_framebuffer_create,
> +};
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] ARM: mvebu: fixes for v4.9 (#1)
From: Gregory CLEMENT @ 2016-11-10 21:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the first pull request for fixes for mvebu for v4.9.
Gregory
The following changes since commit bc33b0ca11e3df467777a4fa7639ba488c9d4911:
Linux 4.9-rc4 (2016-11-05 16:23:36 -0700)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-fixes-4.9-1
for you to fetch changes up to 8d897006fe9206d64cbe353310be26d7c911e69d:
arm64: dts: marvell: add unique identifiers for Armada A8k SPI controllers (2016-11-09 09:44:08 +0100)
----------------------------------------------------------------
mvebu fixes for 4.9 (part 1)
All of them are fixes for arm64 device tree
- 2 for the SPI node on the Armada 7K/8K
- 1 for the clock node on the Armada 37xx
----------------------------------------------------------------
Gregory CLEMENT (1):
arm64: dts: marvell: Fix typo in label name on Armada 37xx
Marcin Wojtas (2):
arm64: dts: marvell: fix clocksource for CP110 slave SPI0
arm64: dts: marvell: add unique identifiers for Armada A8k SPI controllers
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 4 ++--
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules
From: Rob Herring @ 2016-11-10 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v66C15fU1b2+xNDV8Fv2kmmKXyUknA8=9wXztUcs8CNKLg@mail.gmail.com>
On Sun, Nov 6, 2016 at 7:56 PM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Mon, Nov 7, 2016 at 9:29 AM, Peter Chen <hzpeterchen@gmail.com> wrote:
>> On Fri, Nov 04, 2016 at 01:51:34PM -0700, Stephen Boyd wrote:
>>> Quoting Peter Chen (2016-10-24 18:16:32)
>>> > On Mon, Oct 24, 2016 at 12:48:24PM -0700, Stephen Boyd wrote:
>>> > > Quoting Chen-Yu Tsai (2016-10-24 05:19:05)
>>> > > > Hi,
>>> > > >
>>> > > > On Tue, Oct 18, 2016 at 9:56 AM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
>>> > > > > The ULPI bus can be built as a module, and it will soon be
>>> > > > > calling these functions when it supports probing devices from DT.
>>> > > > > Export them so they can be used by the ULPI module.
>>> > > > >
>>> > > > > Acked-by: Rob Herring <robh@kernel.org>
>>> > > > > Cc: <devicetree@vger.kernel.org>
>>> > > > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
>>> > > > > ---
>>> > > > > drivers/of/device.c | 2 ++
>>> > > > > 1 file changed, 2 insertions(+)
>>> > > > >
>>> > > > > diff --git a/drivers/of/device.c b/drivers/of/device.c
>>> > > > > index 8a22a253a830..6719ab35b62e 100644
>>> > > > > --- a/drivers/of/device.c
>>> > > > > +++ b/drivers/of/device.c
>>> > > > > @@ -225,6 +225,7 @@ ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len)
>>> > > > >
>>> > > > > return tsize;
>>> > > > > }
>>> > > > > +EXPORT_SYMBOL_GPL(of_device_get_modalias);
>>> > > > >
>>> > > > > int of_device_request_module(struct device *dev)
>>> > > > > {
>>> > > > > @@ -290,6 +291,7 @@ void of_device_uevent(struct device *dev, struct kobj_uevent_env *env)
>>> > > > > }
>>> > > > > mutex_unlock(&of_mutex);
>>> > > > > }
>>> > > > > +EXPORT_SYMBOL_GPL(of_device_uevent_modalias);
>>> > > >
>>> > > > This is trailing the wrong function.
>>> > > >
>>> > >
>>> > > Good catch. Must have been some bad rebase.
>>> > >
>>> > > Peter, can you fix it while applying or should I resend this patch?
>>> > >
>>> >
>>> > But, this is device tree patch. I can only get chipidea part and other
>>> > USB patches if Greg agrees.
>>> >
>>>
>>> Were you expecting Rob to take the drivers/of/* patches? Sorry I thought
>>> Rob acked them so they could go through usb with the other changes.
>>
>> I am just worried about possible merge error when linus pulls both OF
>> and USB tree. Greg, is it ok the OF patches through USB tree with OF
>> maintainer's ack?
>
> May I suggest putting the OF patches on an immutable branch so other
> subsystems can pull them in without pulling in the USB patches? At
> least I want to use them in the I2C subsystem, and in the sunxi-rsb
> driver.
Do you have patches using this already. If not, it is starting to get
a bit late for v4.10.
I can apply this, but then you'll just be pulling in other DT patches.
Rob
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Jacek Anaszewski @ 2016-11-10 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110202910.GE28832@amd>
Hi,
On 11/10/2016 09:29 PM, Pavel Machek wrote:
> On Thu 2016-11-10 10:55:37, Tony Lindgren wrote:
>> * Pavel Machek <pavel@ucw.cz> [161110 09:29]:
>>> Hi!
>>>
>>>>>>> Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing
>>>>>>> the sysfs brightness attr for changes.") breaks runtime PM for me.
>>>>>>>
>>>>>>> On my omap dm3730 based test system, idle power consumption is over 70
>>>>>>> times higher now with this patch! It goes from about 6mW for the core
>>>>>>> system to over 440mW during idle meaning there's some busy timer now
>>>>>>> active.
>>>>>>>
>>>>>>> Reverting this patch fixes the issue. Any ideas?
>>>
>>> Are you using any LED that toggles with high frequency? Like perhaps
>>> LED that is lit when CPU is active?
>>
>> Yeah one of them seems to have cpu0 as the default trigger.
>
> Aha. Its quite obvious we don't want to notify sysfs each time that
> one is toggled, right?
>
> IMO brightness should display max brightness for the trigger, as Hans
> suggested, anything else is madness for trigger such as cpu activity.
Are you suggesting that we should revert changes introduced
by below patch?
commit 29d76dfa29fe22583aefddccda0bc56aa81035dc
Author: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Date: Tue Mar 18 09:47:48 2008 +0000
leds: Add support to leds with readable status
Some led hardware allows drivers to query the led state, and this patch
adds a hook to let the led class take advantage of that information
when
available.
Without this functionality, when access to the led hardware is not
exclusive (i.e. firmware or hardware might change its state behind the
kernel's back), reality goes out of sync with the led class' idea
of what
the led is doing, which is annoying at best.
Behaviour for drivers that do not or cannot read the led status is
unchanged.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH v2 2/6] mfd: stm32-adc: Add support for stm32 ADC
From: kbuild test robot @ 2016-11-10 21:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478794738-28933-3-git-send-email-fabrice.gasnier@st.com>
Hi Fabrice,
[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.9-rc4 next-20161110]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Fabrice-Gasnier/Add-support-for-STM32-ADC/20161111-011922
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: s390-allmodconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390
All errors (new ones prefixed by >>):
drivers/mfd/stm32-adc-core: struct of_device_id is 200 bytes. The last of 1 is:
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x73 0x74 0x2c 0x73 0x74 0x6d 0x33 0x32 0x66 0x34 0x2d 0x61 0x64 0x63 0x2d 0x63 0x6f 0x72 0x65 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
>> FATAL: drivers/mfd/stm32-adc-core: struct of_device_id is not terminated with a NULL entry!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 43228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161111/899d505c/attachment-0001.gz>
^ permalink raw reply
* [PATCH] serial: sirf: Simplify a test
From: Julia Lawall @ 2016-11-10 21:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <39a1050e-fb64-a6e5-8939-4e01631e59ea@wanadoo.fr>
On Tue, 8 Nov 2016, Christophe JAILLET wrote:
> Le 07/11/2016 ? 14:50, Arnd Bergmann a ?crit :
> > On Tuesday, November 1, 2016 8:03:33 AM CET Christophe JAILLET wrote:
> > > 'dmaengine_prep_dma_cyclic()' does not return an error pointer, so the
> > > test
> > > can be simplified to be more consistent.
> > >
> > > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> > The change looks correct in principle. It would be good to automate looking
> > for other instances of this bug. How did you find it? Do you have e.g. a
> > coccinelle script or did you just stumble over the issue by accident?
> Hi,
>
> You can have an idea of the strategy used in this post:
> https://lkml.org/lkml/2016/11/1/388
>
> Julia is currently working on a more complete strategy in order to find such
> issues.
I have a set of reports in the files listed below. If anyone wants to
take a look at them, I would be happy to send them along. It is
definitely possible that the list contains false positives.
julia
arch/arm64/kernel/ptrace.c
arch/arm/mach-davinci/usb-da8xx.c
arch/arm/mach-omap2/pm.c
arch/mips/ath79/clock.c
arch/mips/ath79/pci.c
arch/sh/boards/mach-sdk7786/setup.c
arch/sh/kernel/cpu/clock.c
arch/sh/kernel/cpu/sh2a/clock-sh7264.c
arch/sh/kernel/cpu/sh2a/clock-sh7269.c
arch/sh/kernel/cpu/sh4a/clock-sh7343.c
arch/sh/kernel/cpu/sh4a/clock-sh7366.c
arch/sh/kernel/cpu/sh4a/clock-sh7722.c
arch/sh/kernel/cpu/sh4a/clock-sh7723.c
arch/sh/kernel/cpu/sh4a/clock-sh7724.c
arch/sh/kernel/cpu/sh4a/clock-sh7734.c
arch/sh/kernel/cpu/sh4a/clock-sh7757.c
arch/sh/kernel/cpu/sh4a/clock-sh7785.c
arch/sh/kernel/cpu/sh4a/clock-sh7786.c
arch/sh/kernel/cpu/sh4a/clock-shx3.c
arch/sparc/kernel/perf_event.c
block/bsg.c
drivers/acpi/apei/ghes.c
drivers/block/loop.c
drivers/block/mtip32xx/mtip32xx.c
drivers/block/nbd.c
drivers/block/pktcdvd.c
drivers/clk/bcm/clk-bcm2835.c
drivers/clk/keystone/pll.c
drivers/clk/mmp/clk-frac.c
drivers/clk/renesas/renesas-cpg-mssr.c
drivers/clk/rockchip/clk.c
drivers/clk/sirf/clk-atlas6.c
drivers/clk/sirf/clk-atlas7.c
drivers/clk/sirf/clk-prima2.c
drivers/clk/spear/clk-aux-synth.c
drivers/clk/spear/clk-frac-synth.c
drivers/clk/spear/clk-gpt-synth.c
drivers/clk/spear/clk-vco-pll.c
drivers/clk/ti/fapll.c
drivers/clk/ux500/clk-prcc.c
drivers/clk/ux500/clk-prcmu.c
drivers/clocksource/armv7m_systick.c
drivers/cpufreq/loongson1-cpufreq.c
drivers/cpufreq/spear-cpufreq.c
drivers/crypto/marvell/hash.c
drivers/crypto/sunxi-ss/sun4i-ss-core.c
drivers/dma/dmaengine.c
drivers/dma/imx-sdma.c
drivers/dma/xilinx/xilinx_dma.c
drivers/gpio/gpiolib.c
drivers/gpu/drm/drm_edid.c
drivers/gpu/drm/drm_gem.c
drivers/gpu/drm/drm_property.c
drivers/gpu/drm/etnaviv/etnaviv_dump.c
drivers/gpu/drm/i915/i915_gem_gtt.c
drivers/gpu/drm/i915/i915_gem_userptr.c
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_engine_cs.c
drivers/gpu/drm/i915/intel_fbdev.c
drivers/gpu/drm/i915/intel_guc_loader.c
drivers/gpu/drm/i915/intel_overlay.c
drivers/gpu/drm/i915/intel_ringbuffer.c
drivers/gpu/drm/imx/imx-drm-core.c
drivers/gpu/drm/imx/ipuv3-crtc.c
drivers/gpu/drm/msm/dsi/dsi.c
drivers/gpu/drm/msm/dsi/dsi_manager.c
drivers/gpu/drm/msm/edp/edp.c
drivers/gpu/drm/msm/hdmi/hdmi.c
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
drivers/gpu/drm/msm/msm_drv.c
drivers/gpu/drm/msm/msm_fbdev.c
drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
drivers/gpu/drm/omapdrm/omap_fbdev.c
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
drivers/gpu/drm/tegra/dc.c
drivers/gpu/drm/tegra/dpaux.c
drivers/gpu/drm/vgem/vgem_fence.c
drivers/gpu/drm/vmwgfx/vmwgfx_context.c
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
drivers/iio/adc/rockchip_saradc.c
drivers/infiniband/core/agent.c
drivers/infiniband/core/ucma.c
drivers/infiniband/core/ucm.c
drivers/infiniband/core/user_mad.c
drivers/infiniband/hw/hfi1/user_sdma.c
drivers/infiniband/hw/mlx4/cm.c
drivers/infiniband/hw/mlx4/mcg.c
drivers/infiniband/hw/mlx5/main.c
drivers/infiniband/hw/mthca/mthca_cmd.c
drivers/infiniband/hw/qedr/verbs.c
drivers/infiniband/hw/usnic/usnic_ib_main.c
drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c
drivers/infiniband/hw/usnic/usnic_ib_verbs.c
drivers/infiniband/ulp/ipoib/ipoib_main.c
drivers/input/keyboard/gpio_keys.c
drivers/iommu/ipmmu-vmsa.c
drivers/leds/leds-pca963x.c
drivers/lightnvm/core.c
drivers/md/dm-cache-policy.c
drivers/md/dm-mpath.c
drivers/media/platform/sti/hva/hva-hw.c
drivers/media/rc/sunxi-cir.c
drivers/media/v4l2-core/videobuf2-core.c
drivers/mfd/max8997.c
drivers/mfd/max8998.c
drivers/mfd/twl-core.c
drivers/misc/c2port/c2port-duramar2150.c
drivers/misc/cxl/api.c
drivers/misc/cxl/pci.c
drivers/misc/cxl/phb.c
drivers/misc/mic/scif/scif_dma.c
drivers/mmc/host/omap_hsmmc.c
drivers/mmc/host/sdhci-st.c
drivers/mtd/devices/docg3.c
drivers/mtd/nand/davinci_nand.c
drivers/mtd/nand/nand_base.c
drivers/mtd/spi-nor/spi-nor.c
drivers/net/can/usb/gs_usb.c
drivers/net/ethernet/amd/sun3lance.c
drivers/net/ethernet/broadcom/bgmac.c
drivers/net/ethernet/broadcom/genet/bcmmii.c
drivers/net/ethernet/cadence/macb.c
drivers/net/ethernet/freescale/fec_main.c
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
drivers/net/ethernet/hisilicon/hns/hns_enet.c
drivers/net/ethernet/i825xx/lasi_82596.c
drivers/net/ethernet/intel/e1000e/ptp.c
drivers/net/ethernet/intel/igb/igb_ptp.c
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
drivers/net/ethernet/mellanox/mlx4/en_clock.c
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
drivers/net/ethernet/realtek/8139too.c
drivers/net/ethernet/renesas/sh_eth.c
drivers/net/ethernet/sfc/ptp.c
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c
drivers/net/ethernet/sun/sunvnet_common.c
drivers/net/ethernet/ti/davinci_emac.c
drivers/net/ethernet/ti/netcp_core.c
drivers/net/phy/mdio-xgene.c
drivers/net/vrf.c
drivers/net/vxlan.c
drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
drivers/net/wireless/intel/iwlwifi/mvm/d3.c
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
drivers/nvdimm/namespace_devs.c
drivers/oprofile/nmi_timer_int.c
drivers/parport/parport_pc.c
drivers/phy/phy-rockchip-inno-usb2.c
drivers/phy/phy-rockchip-usb.c
drivers/phy/phy-ti-pipe3.c
drivers/pinctrl/core.c
drivers/pinctrl/sunxi/pinctrl-sunxi.c
drivers/powercap/intel_rapl.c
drivers/power/supply/ab8500_charger.c
drivers/power/supply/bq25890_charger.c
drivers/power/supply/da9150-charger.c
drivers/power/supply/pda_power.c
drivers/power/supply/twl4030_charger.c
drivers/regulator/fixed.c
drivers/rtc/rtc-hid-sensor-time.c
drivers/rtc/rtc-snvs.c
drivers/s390/block/dasd_eckd.c
drivers/s390/block/dasd_eer.c
drivers/s390/scsi/zfcp_fsf.c
drivers/scsi/cxlflash/superpipe.c
drivers/sh/clk/cpg.c
drivers/soc/rockchip/pm_domains.c
drivers/soc/ti/knav_qmss_queue.c
drivers/spi/spi-s3c64xx.c
drivers/staging/android/ion/ion.c
drivers/staging/android/ion/ion_dummy_driver.c
drivers/staging/android/ion/ion_heap.c
drivers/staging/android/ion/tegra/tegra_ion.c
drivers/staging/lustre/lnet/libcfs/tracefile.c
drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
drivers/staging/lustre/lustre/llite/llite_lib.c
drivers/staging/lustre/lustre/llite/namei.c
drivers/staging/lustre/lustre/obdclass/obd_config.c
drivers/staging/lustre/lustre/osc/osc_request.c
drivers/thermal/int340x_thermal/processor_thermal_device.c
drivers/thermal/tegra/soctherm.c
drivers/thermal/ti-soc-thermal/ti-thermal-common.c
drivers/tty/serial/atmel_serial.c
drivers/tty/serial/mxs-auart.c
drivers/tty/serial/sh-sci.c
drivers/tty/vt/vt.c
drivers/usb/dwc2/platform.c
drivers/usb/gadget/legacy/nokia.c
drivers/usb/gadget/udc/fsl_udc_core.c
drivers/usb/gadget/udc/mv_udc_core.c
drivers/usb/gadget/udc/omap_udc.c
drivers/usb/gadget/udc/pxa25x_udc.c
drivers/usb/gadget/udc/pxa27x_udc.c
drivers/usb/gadget/udc/s3c-hsudc.c
drivers/usb/host/ehci-fsl.c
drivers/usb/host/ehci-msm.c
drivers/usb/host/ohci-omap.c
drivers/usb/musb/am35x.c
drivers/usb/musb/blackfin.c
drivers/usb/musb/da8xx.c
drivers/usb/musb/davinci.c
drivers/usb/musb/musb_core.c
drivers/usb/musb/tusb6010.c
drivers/usb/musb/ux500.c
drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
drivers/xen/pcpu.c
drivers/xen/xenbus/xenbus_probe_frontend.c
fs/9p/fid.c
fs/9p/vfs_inode.c
fs/9p/vfs_inode_dotl.c
fs/binfmt_elf.c
fs/binfmt_elf_fdpic.c
fs/block_dev.c
fs/btrfs/disk-io.c
fs/btrfs/extent_io.c
fs/btrfs/file.c
fs/btrfs/inode.c
fs/btrfs/relocation.c
fs/btrfs/scrub.c
fs/btrfs/send.c
fs/btrfs/volumes.c
fs/ceph/caps.c
fs/ceph/inode.c
fs/ceph/snap.c
fs/cifs/connect.c
fs/cifs/inode.c
fs/cifs/smb1ops.c
fs/coredump.c
fs/ecryptfs/keystore.c
fs/exec.c
fs/ext4/extents.c
fs/ext4/ialloc.c
fs/ext4/readpage.c
fs/ext4/resize.c
fs/f2fs/data.c
fs/fuse/dir.c
fs/fuse/file.c
fs/gfs2/glock.c
fs/gfs2/inode.c
fs/hfs/brec.c
fs/hfsplus/brec.c
fs/jffs2/acl.c
fs/namespace.c
fs/nfsd/nfs3xdr.c
fs/nfsd/nfsfh.c
fs/ocfs2/dir.c
fs/ocfs2/export.c
fs/ocfs2/file.c
fs/ocfs2/inode.c
fs/ocfs2/localalloc.c
fs/ocfs2/namei.c
fs/ocfs2/suballoc.c
fs/overlayfs/super.c
fs/proc/root.c
fs/proc/self.c
fs/proc/thread_self.c
fs/ubifs/find.c
fs/ubifs/gc.c
fs/ubifs/lpt_commit.c
ipc/mqueue.c
ipc/msg.c
kernel/events/core.c
kernel/nsproxy.c
kernel/padata.c
mm/mmap.c
mm/swapfile.c
net/9p/client.c
net/atm/lec.c
net/atm/proc.c
net/bridge/br_forward.c
net/ceph/ceph_common.c
net/ceph/osdmap.c
net/core/dev.c
net/core/neighbour.c
net/ipv4/inet_connection_sock.c
net/ipv4/ip_output.c
net/ipv4/netfilter/arp_tables.c
net/ipv4/netfilter/ip_tables.c
net/ipv6/addrconf.c
net/ipv6/calipso.c
net/ipv6/icmp.c
net/ipv6/ip6_fib.c
net/ipv6/netfilter/ip6_tables.c
net/ipv6/route.c
net/mac80211/chan.c
net/mpls/af_mpls.c
net/netfilter/ipvs/ip_vs_ctl.c
net/netfilter/nfnetlink_queue.c
net/netfilter/nf_tables_api.c
net/openvswitch/datapath.c
net/rds/ib_cm.c
net/rds/rdma_transport.c
net/rds/send.c
net/rxrpc/conn_client.c
net/xfrm/xfrm_policy.c
security/apparmor/path.c
security/integrity/ima/ima_api.c
security/keys/keyctl.c
security/selinux/hooks.c
sound/soc/sunxi/sun4i-codec.c
tools/testing/nvdimm/test/nfit.c
virt/kvm/eventfd.c
^ permalink raw reply
* [PATCH] drm/rockchip: return ERR_PTR instead of NULL
From: Julia Lawall @ 2016-11-10 21:10 UTC (permalink / raw)
To: linux-arm-kernel
rockchip_drm_framebuffer_init is only used in one case, in
rockchip_drm_fbdev.c, where its return value is tested using IS_ERR. To
enable propagating the reason for the error, change the definition so that
it returns an ERR_PTR value.
Problem found with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 0f6eda0..01e11bf 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -213,7 +213,7 @@ struct drm_framebuffer *
rockchip_fb = rockchip_fb_alloc(dev, mode_cmd, &obj, 1);
if (IS_ERR(rockchip_fb))
- return NULL;
+ return ERR_CAST(rockchip_fb);
return &rockchip_fb->fb;
}
^ permalink raw reply related
* [PATCH v2] of, numa: Return NUMA_NO_NODE from disable of_node_to_nid() if nid not possible.
From: Rob Herring @ 2016-11-10 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <93b7769a-4907-176e-9f18-0bf6bd72d15d@caviumnetworks.com>
On Thu, Nov 3, 2016 at 10:11 AM, David Daney <ddaney@caviumnetworks.com> wrote:
> On 11/02/2016 08:37 PM, Rob Herring wrote:
>>
>> On Fri, Oct 28, 2016 at 4:15 PM, David Daney <ddaney.cavm@gmail.com>
>> wrote:
>>>
>>> From: David Daney <david.daney@cavium.com>
>>>
>>> On arm64 NUMA kernels we can pass "numa=off" on the command line to
>>> disable NUMA. A side effect of this is that kmalloc_node() calls to
>>> non-zero nodes will crash the system with an OOPS:
>>>
>>> [ 0.000000] ITS at 0x0000901000020000: allocated 2097152 Devices
>>> @10002000000 (flat, esz 8, psz 64K, shr 1)
>>> [ 0.000000] Unable to handle kernel NULL pointer dereference at
>>> virtual address 00001680
>>> [ 0.000000] pgd = fffffc0009470000
>>> [ 0.000000] [00001680] *pgd=0000010ffff90003, *pud=0000010ffff90003,
>>> *pmd=0000010ffff90003, *pte=0000000000000000
>>> [ 0.000000] Internal error: Oops: 96000006 [#1] SMP
>>> .
>>> .
>>> .
>>> [ 0.000000] [<fffffc00081c8950>] __alloc_pages_nodemask+0xa4/0xe68
>>> [ 0.000000] [<fffffc000821fa70>] new_slab+0xd0/0x564
>>> [ 0.000000] [<fffffc0008221e24>] ___slab_alloc+0x2e4/0x514
>>> [ 0.000000] [<fffffc0008239498>] __slab_alloc+0x48/0x58
>>> [ 0.000000] [<fffffc0008222c20>] __kmalloc_node+0xd0/0x2dc
>>> [ 0.000000] [<fffffc0008115374>] __irq_domain_add+0x7c/0x164
>>> [ 0.000000] [<fffffc0008b461dc>] its_probe+0x784/0x81c
>>> [ 0.000000] [<fffffc0008b462bc>] its_init+0x48/0x1b0
>>> [ 0.000000] [<fffffc0008b4543c>] gic_init_bases+0x228/0x360
>>> [ 0.000000] [<fffffc0008b456bc>] gic_of_init+0x148/0x1cc
>>> [ 0.000000] [<fffffc0008b5aec8>] of_irq_init+0x184/0x298
>>> [ 0.000000] [<fffffc0008b43f9c>] irqchip_init+0x14/0x38
>>> [ 0.000000] [<fffffc0008b12d60>] init_IRQ+0xc/0x30
>>> [ 0.000000] [<fffffc0008b10a3c>] start_kernel+0x240/0x3b8
>>> [ 0.000000] [<fffffc0008b101c4>] __primary_switched+0x30/0x6c
>>> [ 0.000000] Code: 912ec2a0 b9403809 0a0902fb 37b007db (f9400300)
>>> .
>>> .
>>> .
>>>
>>> This is caused by code like this in kernel/irq/irqdomain.c
>>>
>>> domain = kzalloc_node(sizeof(*domain) + (sizeof(unsigned int) *
>>> size),
>>> GFP_KERNEL, of_node_to_nid(of_node));
>>>
>>> When NUMA is disabled, the concept of a node is really undefined, so
>>> of_node_to_nid() should unconditionally return NUMA_NO_NODE.
>>>
>>> Fix by returning NUMA_NO_NODE when the nid is not in the set of
>>> possible nodes.
>>>
>>> Reported-by: Gilbert Netzer <noname@pdc.kth.se>
>>> Signed-off-by: David Daney <david.daney@cavium.com>
>>
>>
>> Does this need to go in 4.9?
>
>
> That would be my preference.
Given how late this is now, my having nothing else for 4.9 and that
his has never worked, I've applied for 4.10, but I did tag for stable.
Rob
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Pavel Machek @ 2016-11-10 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <de3b4ae7-6a08-2a03-d80e-059c71c58aed@redhat.com>
Hi!
> >>It seems that we should get back to your initial approach. i.e. only
> >>brightness changes caused by hardware should be reported.
> >
> >I don't think enabling poll() here is good idea. Some hardware won't
> >be able to tell you that it changed the state. Returning maximum
> >brightness trigger is going to use seems easier/better.
>
> The idea here is to allow userspace to poll() on the brightness
> sysfs atrribute to detect changes autonomously done by the hardware,
> such as e.g. happens on both Dell and Thinkpad laptops when pressing
> the keyboard backlight cycle hotkey. Note that these keys do not
> generate key-press events, the cycling through the brightness levels
> (including off) is done entirely in firmware.
Ok, so you can do that for keyboard backlight on thinkpad... I guess
you handle that as a special trigger on the keyboard leds? Can other
triggers, such as heartbeat, be assigned to that "led"?
> But we do get other ACPI events for this which we can use to let
> userspace know this happens, which is something which user-
> interfaces which allow control over the kbd backlight want to know.
Yes, you can do that for keyboard backlight... but on thinkpads there
are more leds, such as battery led. That can blink on battery low, and
I don't think you can read the current status from hardware.
Getting current state of led blinking with cpu trigger is also not
quite a good idea.
So IMO this should not be done in generic code. Instead,
kbd-backlight trigger should have special attribute, and that one
should be pollable.
> I understand that we will not always be able to do this, here is the
> Documentation/ABI/testing/sysfs-class-led text I have in mind:
>
> The file supports poll() to detect changes, changes are only
> signalled when this file is written or when the hardware /
> firmware changes the brightness itself and the driver can detect
> this. Changes done by kernel triggers / software blinking are
> not signalled.
>
> Note the "and the driver can detect this" language, that has been there
> since v1 of the poll() notification patch since I already expected not
> all hardware to be able to signal this.
Lets move it to separate attribute, for triggers that can do that,
please.
We do want a way to read maximum brightness for the heartbeat trigger,
for example..
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161110/5e875363/attachment.sig>
^ permalink raw reply
* PM regression with LED changes in next-20161109
From: Pavel Machek @ 2016-11-10 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110175537.GF27724@atomide.com>
On Thu 2016-11-10 10:55:37, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [161110 09:29]:
> > Hi!
> >
> > > >>>Looks like commit 883d32ce3385 ("leds: core: Add support for poll()ing
> > > >>>the sysfs brightness attr for changes.") breaks runtime PM for me.
> > > >>>
> > > >>>On my omap dm3730 based test system, idle power consumption is over 70
> > > >>>times higher now with this patch! It goes from about 6mW for the core
> > > >>>system to over 440mW during idle meaning there's some busy timer now
> > > >>>active.
> > > >>>
> > > >>>Reverting this patch fixes the issue. Any ideas?
> >
> > Are you using any LED that toggles with high frequency? Like perhaps
> > LED that is lit when CPU is active?
>
> Yeah one of them seems to have cpu0 as the default trigger.
Aha. Its quite obvious we don't want to notify sysfs each time that
one is toggled, right?
IMO brightness should display max brightness for the trigger, as Hans
suggested, anything else is madness for trigger such as cpu activity.
Thanks and best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161110/db73f569/attachment.sig>
^ permalink raw reply
* [PATCH] PM / Domains: Fix compatible for domain idle state
From: Rob Herring @ 2016-11-10 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFoCjf1qSBDWUY_wNx21_78fRrFqcqrFbsSmabzAZJxQAQ@mail.gmail.com>
On Mon, Nov 07, 2016 at 12:14:28PM +0100, Ulf Hansson wrote:
> On 3 November 2016 at 22:54, Lina Iyer <lina.iyer@linaro.org> wrote:
> > Re-using idle state definition provided by arm,idle-state for domain
> > idle states creates a lot of confusion and limits further evolution of
> > the domain idle definition. To keep things clear and simple, define a
> > idle states for domain using a new compatible "domain-idle-state".
> >
> > Fix existing PM domains code to look for the newly defined compatible.
> >
> > Cc: <devicetree@vger.kernel.org>
> > Cc: Rob Herring <robh@kernel.org>
> > Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
> > ---
> > .../bindings/power/domain-idle-state.txt | 33 ++++++++++++++++++++++
> > .../devicetree/bindings/power/power_domain.txt | 8 +++---
> > drivers/base/power/domain.c | 2 +-
> > 3 files changed, 38 insertions(+), 5 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt
> >
> > diff --git a/Documentation/devicetree/bindings/power/domain-idle-state.txt b/Documentation/devicetree/bindings/power/domain-idle-state.txt
> > new file mode 100644
> > index 0000000..eefc7ed
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/power/domain-idle-state.txt
> > @@ -0,0 +1,33 @@
> > +PM Domain Idle State Node:
> > +
> > +A domain idle state node represents the state parameters that will be used to
> > +select the state when there are no active components in the domain.
> > +
> > +The state node has the following parameters -
> > +
> > +- compatible:
> > + Usage: Required
> > + Value type: <string>
> > + Definition: Must be "domain-idle-state".
> > +
> > +- entry-latency-us
> > + Usage: Required
> > + Value type: <prop-encoded-array>
> > + Definition: u32 value representing worst case latency in
> > + microseconds required to enter the idle state.
> > + The exit-latency-us duration may be guaranteed
> > + only after entry-latency-us has passed.
>
> As we anyway are going to change this, why not use an u64 and have the
> value in ns instead of us?
I can't imagine that you would need more resolution or range. For times
less than 1us, s/w and register access times are going to dominate the
time.
Unless there is a real need, I'd keep alignment with the existing
binding.
Rob
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
From: Dave Gerlach @ 2016-11-10 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5811FE09.8000006@ti.com>
Rob, Ulf, Jon,
On 10/27/2016 08:15 AM, Dave Gerlach wrote:
> +Jon
> On 10/26/2016 04:59 PM, Rob Herring wrote:
>> On Mon, Oct 24, 2016 at 12:00 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>>> Dave Gerlach <d-gerlach@ti.com> writes:
>>>
>>>> Hi,
>>>> On 10/21/2016 01:48 PM, Kevin Hilman wrote:
>>>>> Dave Gerlach <d-gerlach@ti.com> writes:
>>>>>
>>>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>>>> will hook into the genpd framework and allow the TI SCI protocol to
>>>>>> control device power states.
>>>>>>
>>>>>> Also, provide macros representing each device index as understood
>>>>>> by TI SCI to be used in the device node power-domain references.
>>>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>>>
>>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>>>> ---
>>>>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 54 +++++++++++++
>>>>>> MAINTAINERS | 2 +
>>>>>> include/dt-bindings/genpd/k2g.h | 90 ++++++++++++++++++++++
>>>>>> 3 files changed, 146 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>> new file mode 100644
>>>>>> index 000000000000..32f38a349656
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>> @@ -0,0 +1,54 @@
>>>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>>>> +---------------------------------------------
>>>>>> +
>>>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
>>>>>> +responsible for controlling the state of the IPs that are present.
>>>>>> +Communication between the host processor running an OS and the system
>>>>>> +controller happens through a protocol known as TI-SCI [1]. This pm domain
>>>>>> +implementation plugs into the generic pm domain framework and makes use of
>>>>>> +the TI SCI protocol power on and off each device when needed.
>>>>>> +
>>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>>> +
>>>>>> +PM Domain Node
>>>>>> +==============
>>>>>> +The PM domain node represents the global PM domain managed by the PMMC,
>>>>>> +which in this case is the single implementation as documented by the generic
>>>>>> +PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
>>>>>> +
>>>>>> +Required Properties:
>>>>>> +--------------------
>>>>>> +- compatible: should be "ti,sci-pm-domain"
>>>>>> +- #power-domain-cells: Must be 0.
>>>>>> +- ti,sci: Phandle to the TI SCI device to use for managing the devices.
>>>>>>
>>>>>> +Example:
>>>>>> +--------------------
>>>>>> +k2g_pds: k2g_pds {
>>>>>
>>>>> should use generic name like "power-contoller", e.g. k2g_pds: power-controller
>>>>
>>>> Ok, that makes more sense.
>>>>
>>>>>
>>>>>> + compatible = "ti,sci-pm-domain";
>>>>>> + #power-domain-cells = <0>;
>>>>>> + ti,sci = <&pmmc>;
>>>>>> +};
>>>>>> +
>>>>>> +PM Domain Consumers
>>>>>> +===================
>>>>>> +Hardware blocks that require SCI control over their state must provide
>>>>>> +a reference to the sci-pm-domain they are part of and a unique device
>>>>>> +specific ID that identifies the device.
>>>>>> +
>>>>>> +Required Properties:
>>>>>> +--------------------
>>>>>> +- power-domains: phandle pointing to the corresponding PM domain node.
>>>>>> +- ti,sci-id: index representing the device id to be passed oevr SCI to
>>>>>> + be used for device control.
>>>>>
>>>>> This ID doesn't look right.
>>>>>
>>>>> Why not use #power-domain-cells = <1> and pass the index in the DT? ...
>>
>> Exactly. ti,sci-id is a NAK for me.
>
> I was told not to use the onecell during v1 discussion. I agree this would be
> ideal but I cannot due to what the bindings represent, the phandle parameter is
> an index into a list of genpds, whereas we need an actual ID number we can use
> and I do not have the ability to get that from the phandle.
>
> @Ulf/Jon, is there any hope of bringing back custom xlate functions for genpd
> providers? I don't have a good background on why it was even removed. I can
> maintain a single genpd for all devices but I need a way to parse this ID,
> whether it's from a separate property or a phandle. It is locked now to indexing
> into a list of genpds but I need additional per device information for devices
> bound to a genpd and I need either a custom parameter or the ability to parse
> the phandle myself.
>
Any comments here? The meaning of the phandle onecell is fixed in the
genpd framework so I'm not sure how we want to move forward with this, I
need to pass a power domain ID to the genpd driver, and if this
shouldn't be a new property I'm not sure what direction we should take.
Regards,
Dave
>>
>>>>>
>>>>>> +See dt-bindings/genpd/k2g.h for the list of valid identifiers for k2g.
>>>>>> +
>>>>>> +Example:
>>>>>> +--------------------
>>>>>> +uart0: serial at 02530c00 {
>>>>>> + compatible = "ns16550a";
>>>>>> + ...
>>>>>> + power-domains = <&k2g_pds>;
>>>>>> + ti,sci-id = <K2G_DEV_UART0>;
>>>>>
>>>>> ... like this:
>>>>>
>>>>> power-domains = <&k2g_pds K2G_DEV_UART0>;
>>>>
>>>> That's how I did it in version one actually. I was able to define my
>>>> own xlate function to parse the phandle and get that index, but Ulf
>>>> pointed me to this series by Jon Hunter [1] that simplified genpd
>>>> providers and dropped the concept of adding your own xlate. This locks
>>>> the onecell approach to using a fixed static array of genpds that get
>>>> indexed into (without passing the index to the provider, just the
>>>> genpd that's looked up), which doesn't fit our usecase, as we don't
>>>> want a 1 to 1 genpd to device mapping based on the comments provided
>>>> in v1. Now we just use the genpd device attach/detach hooks to parse
>>>> the sci-id and then use it in the genpd device start/stop hooks.
>>
>> I have no idea what any of this means. All sounds like driver
>> architecture, not anything to do with bindings.
>
> This was a response to Kevin, not part of binding description.
>
>>
>>>
>>> Ah, right. I remember now. This approach allows you to use a single
>>> genpd as discussed earlier.
>>>
>>> Makes sense now, suggestion retracted.
>>
>> IIRC, the bindings in Jon's case had a node for each domain and didn't
>> need any additional property.
>
> Yes but we only have one domain and index into it, not into a list of domains,
> so the additional property is solving a different problem.
>
> Regards,
> Dave
>
>>
>> Rob
>>
>
^ permalink raw reply
* [PATCH v4 1/5] arm64: perf: Basic uncore counter support for Cavium ThunderX SOC
From: Will Deacon @ 2016-11-10 19:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110165405.GH4418@leverpostej>
On Thu, Nov 10, 2016 at 04:54:06PM +0000, Mark Rutland wrote:
> On Sat, Oct 29, 2016 at 01:55:29PM +0200, Jan Glauber wrote:
> > diff --git a/drivers/perf/uncore/uncore_cavium.c b/drivers/perf/uncore/uncore_cavium.c
> > new file mode 100644
> > index 0000000..a7b4277
> > --- /dev/null
> > +++ b/drivers/perf/uncore/uncore_cavium.c
> > + * Some notes about the various counters supported by this "uncore" PMU
> > + * and the design:
> > + *
> > + * All counters are 64 bit long.
> > + * There are no overflow interrupts.
> > + * Counters are summarized per node/socket.
> > + * Most devices appear as separate PCI devices per socket with the exception
> > + * of OCX TLK which appears as one PCI device per socket and contains several
> > + * units with counters that are merged.
>
> As a general note, as I commented on the QC L2 PMU driver [1,2], we need
> to figure out if we should be aggregating physical PMUs or not.
>
> Judging by subsequent patches, each unit has individual counters and
> controls, and thus we cannot atomically read/write counters or controls
> across them. As such, I do not think we should aggregate them, and
> should expose them separately to userspace.
I thought each unit was registered as a separate PMU to perf? Or are you
specifically commenting on the OCX TLK? The comment there suggests that
the units cannot be individually enabled/disabled and, without docs, I
trust that's the case.
Will
^ permalink raw reply
* [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Benjamin Herrenschmidt @ 2016-11-10 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110112224.GB4418@leverpostej>
On Thu, 2016-11-10 at 11:22 +0000, Mark Rutland wrote:
> On POWER8, our PCIe doesn't do IO at all, but we have an LPC bus behind
> > firmware calls ;-) We use that infrastructure to plumb in the LPC bus.
>
> Just to check, do you hook that in your inb/outb/etc?
Yes.
> Generally, it would seem nicer if we could have higher-level
> isa_{inb,outb,whatever} accessors that we could hook separately from
> other IO.
Maybe but generally speaking, we don't discriminate accessors per bus,
ie, readl etc... work on all memory mapped busses, inb... works on all
busses with an "IO space", at least that's been the idea. It probably
all comes from the fact that PCI IO and ISA are the same space on
x86 and most other platforms (not all).
> We don't necessarily have to move all ISA drivers over to that if we had
> a separate symbol for that interface.
What I do on ppc today is that I have a chunk of virtual address space
that is reserved for "IO space". The first 64k are "reserved" in that
they route to "the primary" ISA bus (for legacy crap that uses hard
coded addresses, though I use that for my LPC bus too). I "allocate"
space for the PCI IO spaces higher in that space. Was I to support more
LPC busses I could allocate them up there too.
The IO resource of a given device thus becomes the actual IO port plus
the offset of the base of the segment it's in.
For memory mapped IO, inb/outb will just add the virtual address of
the base of all IO space to that. The hooking mechanism will pickup
the stuff that isn't memory mapped.
It's a bit messy but then IO space performance has never been a huge
worry since IO cycles tend to be very slow to begin with.
Note: We also have the ISA memory and ISA FW spaces that we don't have
good accessors for. They somewhat exist (I think the fbdev layer uses
some for vga) but it's messy.
Cheers,
Ben.
^ permalink raw reply
* [RESEND PATCH v1 07/11] perf: hisi: Add support for Hisilicon SoC event counters
From: Mark Rutland @ 2016-11-10 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478151727-20250-8-git-send-email-anurup.m@huawei.com>
On Thu, Nov 03, 2016 at 01:42:03AM -0400, Anurup M wrote:
> + do {
> + /* Get count from individual L3C banks and sum them up */
> + for (i = 0; i < num_banks; i++) {
> + total_raw_count += hisi_read_l3c_counter(l3c_hwmod_data,
> + idx, i);
> + }
> + prev_raw_count = local64_read(&hwc->prev_count);
> +
> + /*
> + * As prev_raw_count is updated with average value of
> + * L3 cache banks, we multiply it by no of banks and
> + * compute the delta
> + */
> + delta = (total_raw_count - (prev_raw_count * num_banks)) &
> + HISI_MAX_PERIOD;
> +
> + local64_add(delta, &event->count);
> +
> + /*
> + * Divide by num of banks to get average count and
> + * update prev_count with this value
> + */
> + avg_raw_count = total_raw_count / num_banks;
> + } while (local64_cmpxchg(
> + &hwc->prev_count, prev_raw_count, avg_raw_count) !=
> + prev_raw_count);
Please don't aggregate like this; expose separate PMUs instead.
This is racy, and by averaging and multiplying we're making up and/or
throwing away data.
[...]
> + event_value = (val -
> + HISI_HWEVENT_L3C_READ_ALLOCATE);
> +
> + /* Select the appropriate Event select register */
> + if (idx > 3)
> + reg_offset += 4;
> +
> + /* Value to write to event type register */
> + val = event_value << (8 * idx);
> +
Please add helpers for these, and explain *why* the transformations are
necessary.
> + /* Find the djtag Identifier of the Unit */
> + client = l3c_hwmod_data->client;
> +
> + /*
> + * Set the event in L3C_EVENT_TYPEx Register
> + * for all L3C banks
> + */
As above, it seems like you should expose a separate PMU per bank
instead. That applies for all the other instances where you iterate over
banks.
[...]
> + for (i = 0; i < l3c_hwmod_data->l3c_hwcfg.num_banks; i++) {
> + module_id = l3c_hwmod_data->l3c_hwcfg.module_id[i];
> + cfg_en = l3c_hwmod_data->l3c_hwcfg.bank_cfgen[i];
> + ret = hisi_djtag_writereg(module_id,
> + cfg_en,
> + reg_offset,
> + value,
> + client);
> + if (!ret)
> + ret = value;
> + }
This is impossible to read. Please factor this into helpers such that
you don't need this amount of indentation.
Please do similarly elsewhere when you see this indentation pattern.
[...]
> +static int hisi_l3c_get_event_idx(struct hisi_pmu *pl3c_pmu)
> +{
> + struct hisi_l3c_data *l3c_hwmod_data = pl3c_pmu->hwmod_data;
> + int event_idx;
> +
> + event_idx =
> + find_first_zero_bit(
> + l3c_hwmod_data->hisi_l3c_event_used_mask,
> + pl3c_pmu->num_counters);
> +
> + if (event_idx == HISI_MAX_CFG_L3C_CNTR)
> + return -EAGAIN;
> +
> + __set_bit(event_idx,
> + l3c_hwmod_data->hisi_l3c_event_used_mask);
> +
> + return event_idx;
> +}
Please get rid of the weird hungarian notation (i.e. don't use 'p' as a
prefix for pointers), and use temporary variables consistently, e.g.
static int hisi_l3c_get_event_idx(struct hisi_pmu *l3c_pmu)
{
struct hisi_l3c_data *l3c_hwmod_data = l3c_pmu->hwmod_data;
unsigned long *used_mask = l3c_hwmod_data->hisi_l3c_event_used_mask;
int num_counters = pl3c_pmu->num_counters
int idx;
idx = find_first_zero_bit(used_mask, num_counters);
if (idx == num_counters)
return -EAGAIN;
set_bit(idx, used_mask);
return idx;
}
[...]
> + if (of_property_read_u32(node, "counter-reg",
> + &pl3c_hwcfg->counter_reg0_off)) {
> + dev_err(dev, "DT:Couldnot read counter-reg!\n");
> + return -EINVAL;
> + }
Please use spaces in these messages.
Otherwise, my comments on the binding apply here.
[...]
> +static int init_hisi_l3c_data(struct device *dev,
> + struct hisi_pmu *pl3c_pmu,
> + struct hisi_djtag_client *client)
> +{
> + struct hisi_l3c_data *l3c_hwmod_data = NULL;
> + int ret;
> +
> + l3c_hwmod_data = kzalloc(sizeof(struct hisi_l3c_data),
> + GFP_KERNEL);
Use:
l3c_hwmod_data = kzalloc(sizeof(*l3c_hwmod_data, GFP_KERNEL):
[...]
> +static int hisi_pmu_l3c_dev_probe(struct hisi_djtag_client *client)
> +{
> + struct hisi_pmu *pl3c_pmu = NULL;
> + struct device *dev = &client->dev;
> + int ret;
> +
> + pl3c_pmu = hisi_pmu_alloc(dev);
> + if (IS_ERR(pl3c_pmu))
> + return PTR_ERR(pl3c_pmu);
Why use error pointers for this?
hisi_pmu_alloc() only ever returns ERR_PTR(-ENOMEM) if it failed to
allocate.
It's far simpler to have it pass on NULL there, and here do:
pl3c_pmu = hisi_pmu_alloc(dev);
if (!pl3c_pmu)
return -ENOMEM;
Please also s/pl3c_pmu/l3c_pmu/ here, and elsewhere throughout the
driver. The 'p' only serves to make this harder to read.
[...]
> + /* Register with perf PMU */
> + pl3c_pmu->pmu = (struct pmu) {
> + .name = pl3c_pmu->name,
> + .task_ctx_nr = perf_invalid_context,
> + .event_init = hisi_uncore_pmu_event_init,
> + .add = hisi_uncore_pmu_add,
> + .del = hisi_uncore_pmu_del,
> + .start = hisi_uncore_pmu_start,
> + .stop = hisi_uncore_pmu_stop,
> + .read = hisi_uncore_pmu_read,
> + };
Please remove the comment above this.
[...]
> +int hisi_uncore_pmu_event_init(struct perf_event *event)
> +{
> + int err;
> + struct hisi_pmu *phisi_pmu = to_hisi_pmu(event->pmu);
This is undefined behaviour. This must be done *after* we check the
event->pmu->type.
> +
> + if (event->attr.type != event->pmu->type)
> + return -ENOENT;
> +
> + /* we do not support sampling as the counters are all
> + * shared by all CPU cores in a CPU die(SCCL). Also we
> + * donot support attach to a task(per-process mode)
> + */
> + if (is_sampling_event(event) || event->attach_state & PERF_ATTACH_TASK)
> + return -EOPNOTSUPP;
> +
> + /* counters do not have these bits */
> + if (event->attr.exclude_user ||
> + event->attr.exclude_kernel ||
> + event->attr.exclude_host ||
> + event->attr.exclude_guest ||
> + event->attr.exclude_hv ||
> + event->attr.exclude_idle)
> + return -EINVAL;
> +
> + if (event->cpu < 0)
> + return -EINVAL;
> +
> + event->cpu = cpumask_first(&phisi_pmu->cpu);
You should also check the event grouping.
Take a look at what we do in arch/arm/mm/cache-l2x0-pmu.c.
[...]
> +/*
> + * Enable counter and set the counter to count
> + * the event that we're interested in.
> + */
> +void hisi_uncore_pmu_enable_event(struct perf_event *event)
> +{
> + struct hw_perf_event *hwc = &event->hw;
> + struct hisi_pmu *phisi_pmu = to_hisi_pmu(event->pmu);
> +
> + /* Disable the hardware event counting */
> + if (phisi_pmu->ops->disable_counter)
> + phisi_pmu->ops->disable_counter(phisi_pmu, GET_CNTR_IDX(hwc));
Why isn't the counter already disabled?
> + /*
> + * Set event (if destined for Hisilicon SoC counters).
> + */
> + if (phisi_pmu->ops->set_evtype)
> + phisi_pmu->ops->set_evtype(phisi_pmu, GET_CNTR_IDX(hwc),
> + hwc->config_base);
Why isn't this done in the pmu::event_add callback?
> +
> + /* Enable the hardware event counting */
> + if (phisi_pmu->ops->enable_counter)
> + phisi_pmu->ops->enable_counter(phisi_pmu, GET_CNTR_IDX(hwc));
This should be the only necessary part of this function.
> +}
> +
> +void hisi_pmu_set_event_period(struct perf_event *event)
> +{
> + struct hw_perf_event *hwc = &event->hw;
> + struct hisi_pmu *phisi_pmu = to_hisi_pmu(event->pmu);
> +
> + /*
> + * The Hisilicon PMU counters have a period of 2^32. To account for the
> + * possiblity of extreme interrupt latency we program for a period of
> + * half that. Hopefully we can handle the interrupt before another 2^31
> + * events occur and the counter overtakes its previous value.
> + */
> + u64 val = 1ULL << 31;
> +
> + local64_set(&hwc->prev_count, val);
> +
> + /* Write to the hardware event counter */
> + phisi_pmu->ops->write_counter(phisi_pmu, hwc, val);
> +}
> +
> +void hisi_uncore_pmu_start(struct perf_event *event, int flags)
> +{
> + struct hw_perf_event *hwc = &event->hw;
> + struct hisi_pmu *phisi_pmu = to_hisi_pmu(event->pmu);
> + struct hisi_pmu_hw_events *hw_events;
> +
> + hw_events = &phisi_pmu->hw_events;
> +
> + if (WARN_ON_ONCE(!(hwc->state & PERF_HES_STOPPED)))
> + return;
> +
> + WARN_ON_ONCE(!(hwc->state & PERF_HES_UPTODATE));
> + hwc->state = 0;
> +
> + if (phisi_pmu->ops->set_event_period)
> + phisi_pmu->ops->set_event_period(event);
When will this differ from hisi_pmu_set_event_period() above?
> + if (flags & PERF_EF_RELOAD) {
> + u64 prev_raw_count = local64_read(&hwc->prev_count);
> +
> + phisi_pmu->ops->write_counter(phisi_pmu, hwc,
> + (u32)prev_raw_count);
> + }
If we always go through hisi_pmu_set_event_period(), this looks
redundant.
> +
> + hisi_uncore_pmu_enable_event(event);
There's no matching disable_event() call in this function, so this looks
suspicious.
> + perf_event_update_userpage(event);
> +}
> +
> +void hisi_uncore_pmu_stop(struct perf_event *event, int flags)
> +{
> + struct hw_perf_event *hwc = &event->hw;
> + struct hisi_pmu *phisi_pmu = to_hisi_pmu(event->pmu);
> +
> + if (hwc->state & PERF_HES_UPTODATE)
> + return;
Why?
[...]
> +int hisi_uncore_common_fwprop_read(struct device *dev,
> + struct hisi_pmu *phisi_pmu)
> +{
> + if (device_property_read_u32(dev, "num-events",
> + &phisi_pmu->num_events)) {
> + dev_err(dev, "Cant read num-events from DT!\n");
> + return -EINVAL;
> + }
For consistency with the rest of the driver, and given there is no ACPI
support, please use the of_property_* API here.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
From: Olof Johansson @ 2016-11-10 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7ccc12bc-9a05-47e3-8ab8-d1b0ad31159e@arm.com>
On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 10/11/16 14:12, Rob Herring wrote:
>>
>> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com>
>> wrote:
>>>
>>>
>>>
>>> On 10/11/16 01:22, Rob Herring wrote:
>>>>
>>>>
>>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>>>
>>>>>
>>>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>>>
>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>>> ---
>>>>> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> index d1882c4540d0..ebd03fc93135 100644
>>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>>>> operations.
>>>>>
>>>>> Required properties:
>>>>>
>>>>> -- compatible : should be "arm,scpi"
>>>>> +- compatible : should be
>>>>> + * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>>>> above
>>>>> + * "arm,legacy-scpi" : For implementations complying pre SCPI
>>>>> v1.0
>>>>
>>>>
>>>>
>>>> I'd prefer that we explicitly enumerate the old versions. Are there
>>>> many?
>>>>
>>>
>>> I understand your concern, but this legacy SCPI protocol was not
>>> officially released. It was just WIP which vendors picked up from very
>>> early releases. Since they are not numbered, it's hard to have specific
>>> compatibles with different versions until v1.0. That's one of the reason
>>> to retain platform specific compatible so that we can add any quirks
>>> based on them if needed.
>>>
>>> I will probably add these information in the commit log so that it's
>>> clear why we can't do version based compatible.
>>
>>
>> This is exactly my point. By enumerate, I meant having platform
>> specific compatibles. Having "arm,legacy-scpi" is pointless because
>> who knows what version they followed and they may all be different.
>>
>
> OK, but IIUC Olof's concern wanted a generic one along with the platform
> specific compatible which kind of makes sense as so far we have seen
> some commonality between Amlogic and Rockchip.
>
> E.g. Amlogic follows most of the legacy protocol though it deviates in
> couple of things which we can handle with platform specific compatible
> (in the following patch in the series). When another user(Rockchip ?)
> make use of this legacy protocol, we can start using those platform
> specific compatible for deviations only.
>
> Is that not acceptable ?
If there's no shared legacy feature set, then it's probably less
useful to have a shared less precise compatible value.
What the main point I was trying to get across was that we shouldn't
expand the generic binding with per-vendor compatible fields, instead
we should have those as extensions on the side.
I'm also a little apprehensive of using "legacy", it goes in the same
bucket as "misc". At some point 1.0 will be legacy too, etc.
-Olof
^ permalink raw reply
* [PATCH 6/6] ARM: dts: rockchip: add rockchip RK1108 Evaluation board
From: Rob Herring @ 2016-11-10 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478177039-12257-1-git-send-email-andy.yan@rock-chips.com>
On Thu, Nov 03, 2016 at 08:43:59PM +0800, Andy Yan wrote:
> RK1108EVB is designed by Rockchip for CVR field.
> This patch add basic support for it, which can boot with
> initramfs into shell.
>
> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
> ---
>
> Documentation/devicetree/bindings/arm/rockchip.txt | 3 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/rk1108-evb.dts | 69 ++++++++++++++++++++++
> 3 files changed, 73 insertions(+)
> create mode 100644 arch/arm/boot/dts/rk1108-evb.dts
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/6] dt-bindings: rockchip-dw-mshc: add RK1108 dw-mshc description
From: Rob Herring @ 2016-11-10 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478176250-11840-1-git-send-email-andy.yan@rock-chips.com>
On Thu, Nov 03, 2016 at 08:30:50PM +0800, Andy Yan wrote:
> From: Shawn Lin <shawn.lin@rock-chips.com>
>
> Add "rockchip,rk1108-dw-mshc", "rockchip,rk3288-dw-mshc" for
> dwmmc on rk1108 platform.
>
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>
> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
> ---
>
> Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 13/13] Documentation: synopsys-dw-mshc: remove the unused properties
From: Rob Herring @ 2016-11-10 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103062135.10697-14-jh80.chung@samsung.com>
On Thu, Nov 03, 2016 at 03:21:35PM +0900, Jaehoon Chung wrote:
> "support-highspeed" was the obsoleted property.
> And "broken-cd" is not synopsys specific property.
> It can be referred to mmc.txt binding Documentation.
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> ---
> Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 5 -----
> 1 file changed, 5 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 0/8] DMA: s3c64xx: Conversion to the new channel request API
From: Krzysztof Kozlowski @ 2016-11-10 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478791076-19528-1-git-send-email-s.nawrocki@samsung.com>
On Thu, Nov 10, 2016 at 04:17:48PM +0100, Sylwester Nawrocki wrote:
> This patch series aims to convert the s3c64xx platform to use
> the new DMA channel request API, i.e. this is only meaningful
> for non-dt systems using s3c64xx SoCs.
>
> Presumably the first 2 or 4 patches in this series could be queued
> for v4.10-rc1 and the remaining patches could be left for subsequent
> release, to avoid non-trivial conflict with patches already applied
> in the ASoC tree.
Sounds good to me. Should I put the ARM/s3c64xx commits on separate
branch in case someone would like to pull a tag with it?
Best regards,
Krzysztof
^ 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