* [PATCH v2 2/2] arm: perf: Mark as non-removable
From: Alexander Stein @ 2017-01-04 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161222224547.GA30170@remoulade>
Hi,
On Thursday 22 December 2016 22:48:32, Mark Rutland wrote:
> On Wed, Dec 21, 2016 at 04:03:40PM +0100, Alexander Stein wrote:
> > This driver can only built into the kernel. So disallow driver bind/unbind
> > and also prevent a kernel error in case DEBUG_TEST_DRIVER_REMOVE is
> > enabled.
> >
> > Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> > ---
> >
> > arch/arm/kernel/perf_event_v7.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/kernel/perf_event_v7.c
> > b/arch/arm/kernel/perf_event_v7.c index b942349..795e373 100644
> > --- a/arch/arm/kernel/perf_event_v7.c
> > +++ b/arch/arm/kernel/perf_event_v7.c
> > @@ -2029,6 +2029,7 @@ static int armv7_pmu_device_probe(struct
> > platform_device *pdev)>
> > static struct platform_driver armv7_pmu_driver = {
> >
> > .driver = {
> >
> > .name = "armv7-pmu",
> >
> > + .suppress_bind_attrs = true,
> >
> > .of_match_table = armv7_pmu_of_device_ids,
> >
> > },
>
> While this patch looks correct, the other perf_event_* drivers (e.g. those
> under arch/arm/) will need similar treatment.
Yep, but this is the only one I can actually test.
> More generally, updating each and every driver in this manner seems like a
> scattergun approach that is tiresome and error prone.
>
> IMO, it would be vastly better for a higher layer to enforce that we don't
> attempt to unbind drivers where the driver does not have a remove callback,
> as is the case here (and I suspect most over cases where
> DEBUG_TEST_DRIVER_REMOVE is blowing up).
You mean something like this?
> diff --git a/drivers/base/driver.c b/drivers/base/driver.c
> index 4eabfe2..3b6c1a2d 100644
> --- a/drivers/base/driver.c
> +++ b/drivers/base/driver.c
> @@ -158,6 +158,9 @@ int driver_register(struct device_driver *drv)
>
> printk(KERN_WARNING "Driver '%s' needs updating - please use
> "
>
> "bus_type methods\n", drv->name);
>
> + if (!drv->remove)
> + drv->suppress_bind_attrs = true;
> +
>
> other = driver_find(drv->name, drv->bus);
> if (other) {
>
> printk(KERN_ERR "Error: Driver '%s' is already registered, "
> Is there any reason that can't be enforced at the bus layer, say?
I'm not sure if the change above works with remove functions set in struct
bus_type too.
But on the other hand this would hide errors in drivers which are actually
removable but do not cleanup properly which DEBUG_TEST_DRIVER_REMOVE tries to
detect. By setting .suppress_bind_attrs = true explicitely you state "This
driver cannot be removed!", so the remove callback is not missing by accident.
Best regards,
Alexander
^ permalink raw reply
* [PATCH 1/3] linux/const.h: move UL() macro to include/linux/const.h
From: Geert Uytterhoeven @ 2017-01-04 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483520127-29316-2-git-send-email-yamada.masahiro@socionext.com>
Hi Yamada-san,
On Wed, Jan 4, 2017 at 9:55 AM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> Some architectures are duplicating the definition of UL():
>
> #define UL(x) _AC(x, UL)
>
> This is not actually arch-specific, so it will be useful to move it
> to a common header. Currently, we only have the uapi variant for
> linux/const.h, so I am creating include/linux/const.h.
>
> I am also adding _UL(x), _ULL(x), ULL(x) because _AC() is used for
> UL in most places (and ULL in some places). I expect _AC(..., UL)
> will be replaced with _UL(...) or UL(...). The underscore-prefixed
> one should be used for exported headers.
>
> Note:
> I renamed UL(x) in arch/m68k/mm/init.c, where it is used for a
> different meaning.
Shouldn't that be a separate (prerequisite) patch?
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> arch/arm/include/asm/memory.h | 6 ------
> arch/arm64/include/asm/memory.h | 6 ------
> arch/m68k/mm/init.c | 6 +++---
> arch/unicore32/include/asm/memory.h | 6 ------
> include/linux/const.h | 9 +++++++++
> include/uapi/linux/const.h | 9 ++++++---
> 6 files changed, 18 insertions(+), 24 deletions(-)
> create mode 100644 include/linux/const.h
For the m68k change:
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2] drm: tilcdc: simplify the recovery from sync lost error on rev1
From: Jyri Sarha @ 2017-01-04 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482158834-29477-1-git-send-email-bgolaszewski@baylibre.com>
On 12/19/16 16:47, Bartosz Golaszewski wrote:
> Revision 2 of LCDC suffers from an issue where a SYNC_LOST error
> caused by limited memory bandwidth may leave the picture shifted a
> couple pixels to the right.
>
> This issue has not been observed on revision 1, while the recovery
> mechanism introduces a different issue, where the END_OF_FRAME
> interrupt doesn't fire while drm is waiting for vblanks.
>
> On rev1: recover from sync lost errors by simply clearing the
> RASTER_ENABLE bit in the RASTER_CTRL register and re-enabling it
> again as is suggested by the datasheet.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
After testing I'll send this as fixes pull req for tilcdc 4.10.
Reviewed-by: Jyri Sarha <jsarha@ti.com>
> ---
> v1 -> v2:
> - add a check to see if the RASTER_ENABLE bit is set before clearing it
>
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 27 ++++++++++++++++++---------
> 1 file changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 9942b05..2004107 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -856,7 +856,7 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
> struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
> struct drm_device *dev = crtc->dev;
> struct tilcdc_drm_private *priv = dev->dev_private;
> - uint32_t stat;
> + uint32_t stat, reg;
>
> stat = tilcdc_read_irqstatus(dev);
> tilcdc_clear_irqstatus(dev, stat);
> @@ -921,17 +921,26 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
> dev_err_ratelimited(dev->dev, "%s(0x%08x): Sync lost",
> __func__, stat);
> tilcdc_crtc->frame_intact = false;
> - if (tilcdc_crtc->sync_lost_count++ >
> - SYNC_LOST_COUNT_LIMIT) {
> - dev_err(dev->dev, "%s(0x%08x): Sync lost flood detected, recovering", __func__, stat);
> - queue_work(system_wq, &tilcdc_crtc->recover_work);
> - if (priv->rev == 1)
> + if (priv->rev == 1) {
> + reg = tilcdc_read(dev, LCDC_RASTER_CTRL_REG);
> + if (reg & LCDC_RASTER_ENABLE) {
> tilcdc_clear(dev, LCDC_RASTER_CTRL_REG,
> - LCDC_V1_SYNC_LOST_INT_ENA);
> - else
> + LCDC_RASTER_ENABLE);
> + tilcdc_set(dev, LCDC_RASTER_CTRL_REG,
> + LCDC_RASTER_ENABLE);
> + }
> + } else {
> + if (tilcdc_crtc->sync_lost_count++ >
> + SYNC_LOST_COUNT_LIMIT) {
> + dev_err(dev->dev,
> + "%s(0x%08x): Sync lost flood detected, recovering",
> + __func__, stat);
> + queue_work(system_wq,
> + &tilcdc_crtc->recover_work);
> tilcdc_write(dev, LCDC_INT_ENABLE_CLR_REG,
> LCDC_SYNC_LOST);
> - tilcdc_crtc->sync_lost_count = 0;
> + tilcdc_crtc->sync_lost_count = 0;
> + }
> }
> }
>
>
^ permalink raw reply
* [PATCH 0/2] ARM: dts: oxnas: Update with dt-bindings
From: Neil Armstrong @ 2017-01-04 9:30 UTC (permalink / raw)
To: linux-arm-kernel
This patchsets updates the OX810SE and OX820 dtsi with the reset and
clock dt-bindings includes then replaces magic values with bindings
defines.
Neil Armstrong (2):
ARM: dts: OX810: Update with dt-bindings includes
ARM: dts: OX820: Update with dt-bindings includes
arch/arm/boot/dts/ox810se.dtsi | 10 ++++++----
arch/arm/boot/dts/ox820.dtsi | 14 ++++++++------
2 files changed, 14 insertions(+), 10 deletions(-)
--
2.7.0
^ permalink raw reply
* [PATCH 1/2] ARM: dts: OX810: Update with dt-bindings includes
From: Neil Armstrong @ 2017-01-04 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104093046.12428-1-narmstrong@baylibre.com>
Add OX810SE dt-bindings includes files for clocks and resets, replace
resets numbers by human readable defines.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm/boot/dts/ox810se.dtsi | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/ox810se.dtsi b/arch/arm/boot/dts/ox810se.dtsi
index ce13705..46aa6db 100644
--- a/arch/arm/boot/dts/ox810se.dtsi
+++ b/arch/arm/boot/dts/ox810se.dtsi
@@ -7,6 +7,8 @@
*/
/include/ "skeleton.dtsi"
+#include <dt-bindings/clock/oxsemi,ox810se.h>
+#include <dt-bindings/reset/oxsemi,ox810se.h>
/ {
compatible = "oxsemi,ox810se";
@@ -242,7 +244,7 @@
current-speed = <115200>;
no-loopback-test;
status = "disabled";
- resets = <&reset 17>;
+ resets = <&reset RESET_UART1>;
};
uart1: serial at 300000 {
@@ -256,7 +258,7 @@
current-speed = <115200>;
no-loopback-test;
status = "disabled";
- resets = <&reset 18>;
+ resets = <&reset RESET_UART2>;
};
uart2: serial at 900000 {
@@ -270,7 +272,7 @@
current-speed = <115200>;
no-loopback-test;
status = "disabled";
- resets = <&reset 22>;
+ resets = <&reset RESET_UART3>;
};
uart3: serial at a00000 {
@@ -284,7 +286,7 @@
current-speed = <115200>;
no-loopback-test;
status = "disabled";
- resets = <&reset 23>;
+ resets = <&reset RESET_UART4>;
};
};
--
2.7.0
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: OX820: Update with dt-bindings includes
From: Neil Armstrong @ 2017-01-04 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104093046.12428-1-narmstrong@baylibre.com>
Add OX820 dt-bindings includes files for clocks and resets, replace
resets numbers by human readable defines.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm/boot/dts/ox820.dtsi | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/ox820.dtsi b/arch/arm/boot/dts/ox820.dtsi
index e40f282..4592075 100644
--- a/arch/arm/boot/dts/ox820.dtsi
+++ b/arch/arm/boot/dts/ox820.dtsi
@@ -8,6 +8,8 @@
/include/ "skeleton.dtsi"
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/oxsemi,ox820.h>
+#include <dt-bindings/reset/oxsemi,ox820.h>
/ {
compatible = "oxsemi,ox820";
@@ -83,8 +85,8 @@
nandc: nand-controller at 41000000 {
compatible = "oxsemi,ox820-nand";
reg = <0x41000000 0x100000>;
- clocks = <&stdclk 11>;
- resets = <&reset 15>;
+ clocks = <&stdclk CLK_820_NAND>;
+ resets = <&reset RESET_NAND>;
#address-cells = <1>;
#size-cells = <0>;
status = "disabled";
@@ -99,9 +101,9 @@
mac-address = [000000000000]; /* Filled in by U-Boot */
phy-mode = "rgmii";
- clocks = <&stdclk 9>, <&gmacclk>;
+ clocks = <&stdclk CLK_820_ETHA>, <&gmacclk>;
clock-names = "gmac", "stmmaceth";
- resets = <&reset 6>;
+ resets = <&reset RESET_MAC>;
/* Regmap for sys registers */
oxsemi,sys-ctrl = <&sys>;
@@ -208,7 +210,7 @@
no-loopback-test;
status = "disabled";
clocks = <&sysclk>;
- resets = <&reset 17>;
+ resets = <&reset RESET_UART1>;
};
uart1: serial at 300000 {
@@ -222,7 +224,7 @@
no-loopback-test;
status = "disabled";
clocks = <&sysclk>;
- resets = <&reset 18>;
+ resets = <&reset RESET_UART2>;
};
rps at 400000 {
--
2.7.0
^ permalink raw reply related
* [PATCH v2 06/11] mfd: axp20x: add separate MFD cell for AXP223
From: Lee Jones @ 2017-01-04 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209110419.28981-7-quentin.schulz@free-electrons.com>
On Fri, 09 Dec 2016, Quentin Schulz wrote:
> The AXP223 shares most of its logic with the AXP221 but has some
> differences for the VBUS power supply driver. Thus, to probe the driver
> with the correct compatible, the AXP221 and the AXP223 now have separate
> MFD cells.
>
> AXP221 MFD cells are renamed from axp22x_cells to axp221_cells to avoid
> confusion.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> ---
>
> v2:
> - correct indentation,
> - renaming axp22x_cells to axp221_cells to avoid confusion between axp22x,
> axp221 and axp223
>
> drivers/mfd/axp20x.c | 28 ++++++++++++++++++++++++----
> 1 file changed, 24 insertions(+), 4 deletions(-)
Applied, thanks.
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 6ee2cc6..b31f123 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -591,7 +591,22 @@ static struct mfd_cell axp20x_cells[] = {
> },
> };
>
> -static struct mfd_cell axp22x_cells[] = {
> +static struct mfd_cell axp221_cells[] = {
> + {
> + .name = "axp20x-pek",
> + .num_resources = ARRAY_SIZE(axp22x_pek_resources),
> + .resources = axp22x_pek_resources,
> + }, {
> + .name = "axp20x-regulator",
> + }, {
> + .name = "axp20x-usb-power-supply",
> + .of_compatible = "x-powers,axp221-usb-power-supply",
> + .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
> + .resources = axp22x_usb_power_supply_resources,
> + },
> +};
> +
> +static struct mfd_cell axp223_cells[] = {
> {
> .name = "axp20x-pek",
> .num_resources = ARRAY_SIZE(axp22x_pek_resources),
> @@ -600,7 +615,7 @@ static struct mfd_cell axp22x_cells[] = {
> .name = "axp20x-regulator",
> }, {
> .name = "axp20x-usb-power-supply",
> - .of_compatible = "x-powers,axp221-usb-power-supply",
> + .of_compatible = "x-powers,axp223-usb-power-supply",
> .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
> .resources = axp22x_usb_power_supply_resources,
> },
> @@ -793,9 +808,14 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
> axp20x->regmap_irq_chip = &axp20x_regmap_irq_chip;
> break;
> case AXP221_ID:
> + axp20x->nr_cells = ARRAY_SIZE(axp221_cells);
> + axp20x->cells = axp221_cells;
> + axp20x->regmap_cfg = &axp22x_regmap_config;
> + axp20x->regmap_irq_chip = &axp22x_regmap_irq_chip;
> + break;
> case AXP223_ID:
> - axp20x->nr_cells = ARRAY_SIZE(axp22x_cells);
> - axp20x->cells = axp22x_cells;
> + axp20x->nr_cells = ARRAY_SIZE(axp223_cells);
> + axp20x->cells = axp223_cells;
> axp20x->regmap_cfg = &axp22x_regmap_config;
> axp20x->regmap_irq_chip = &axp22x_regmap_irq_chip;
> break;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2] coresight: etm4x: Fix enabling of cycle accurate tracing in perf.
From: Mike Leach @ 2017-01-04 9:47 UTC (permalink / raw)
To: linux-arm-kernel
Using perf record 'cyclacc' option in cs_etm event was not setting up cycle
accurate trace correctly.
Corrects bit set in TRCCONFIGR to enable cycle accurate trace.
Programs TRCCCCTLR with a valid threshold value as required by ETMv4 spec.
Signed-off-by: Mike Leach <mike.leach@linaro.org>
---
drivers/hwtracing/coresight/coresight-etm4x.c | 7 +++++--
drivers/hwtracing/coresight/coresight-etm4x.h | 1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index 4db8d6a..c5a65d1 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -216,8 +216,11 @@ static int etm4_parse_event_config(struct etmv4_drvdata *drvdata,
goto out;
/* Go from generic option to ETMv4 specifics */
- if (attr->config & BIT(ETM_OPT_CYCACC))
- config->cfg |= ETMv4_MODE_CYCACC;
+ if (attr->config & BIT(ETM_OPT_CYCACC)) {
+ config->cfg |= BIT(4);
+ /* TRM: Must program this for cycacc to work */
+ config->ccctlr = ETM_CYC_THRESHOLD_DEFAULT;
+ }
if (attr->config & BIT(ETM_OPT_TS))
config->cfg |= ETMv4_MODE_TIMESTAMP;
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
index ba8d3f8..b3b5ea7 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.h
+++ b/drivers/hwtracing/coresight/coresight-etm4x.h
@@ -146,6 +146,7 @@
#define ETM_ARCH_V4 0x40
#define ETMv4_SYNC_MASK 0x1F
#define ETM_CYC_THRESHOLD_MASK 0xFFF
+#define ETM_CYC_THRESHOLD_DEFAULT 0x100
#define ETMv4_EVENT_MASK 0xFF
#define ETM_CNTR_MAX_VAL 0xFFFF
#define ETM_TRACEID_MASK 0x3f
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] drm/meson: Fix CVBS initialization
From: Neil Armstrong @ 2017-01-04 9:55 UTC (permalink / raw)
To: linux-arm-kernel
This serie fixes the CVBS initialization when HDMI is already configured
by the bootloader and fixes the CVBS vdac disable register values.
Neil Armstrong (2):
drm/meson: Fix CVBS initialization when HDMI is configured by
bootloader
drm/meson: Fix CVBS VDAC disable
drivers/gpu/drm/meson/meson_venc.c | 19 +++++++++++++++++++
drivers/gpu/drm/meson/meson_venc_cvbs.c | 2 +-
2 files changed, 20 insertions(+), 1 deletion(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/2] drm/meson: Fix CVBS initialization when HDMI is configured by bootloader
From: Neil Armstrong @ 2017-01-04 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483523752-14705-1-git-send-email-narmstrong@baylibre.com>
When the HDMI output is configured by the bootloader, there is mismatch is the
pipeline configuration and the Vsync interrupt fails to trigger.
This commit disables the HDMI blocks in the probe phase.
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/gpu/drm/meson/meson_venc.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/meson/meson_venc.c b/drivers/gpu/drm/meson/meson_venc.c
index d836b22..f7c87017 100644
--- a/drivers/gpu/drm/meson/meson_venc.c
+++ b/drivers/gpu/drm/meson/meson_venc.c
@@ -38,6 +38,11 @@
* - TV Panel encoding via ENCT
*/
+/* HHI Registers */
+#define HHI_VDAC_CNTL0 0x2F4 /* 0xbd offset in data sheet */
+#define HHI_VDAC_CNTL1 0x2F8 /* 0xbe offset in data sheet */
+#define HHI_HDMI_PHY_CNTL0 0x3a0 /* 0xe8 offset in data sheet */
+
struct meson_cvbs_enci_mode meson_cvbs_enci_pal = {
.mode_tag = MESON_VENC_MODE_CVBS_PAL,
.hso_begin = 3,
@@ -242,6 +247,20 @@ void meson_venc_disable_vsync(struct meson_drm *priv)
void meson_venc_init(struct meson_drm *priv)
{
+ /* Disable CVBS VDAC */
+ regmap_write(priv->hhi, HHI_VDAC_CNTL0, 0);
+ regmap_write(priv->hhi, HHI_VDAC_CNTL1, 8);
+
+ /* Power Down Dacs */
+ writel_relaxed(0xff, priv->io_base + _REG(VENC_VDAC_SETTING));
+
+ /* Disable HDMI PHY */
+ regmap_write(priv->hhi, HHI_HDMI_PHY_CNTL0, 0);
+
+ /* Disable HDMI */
+ writel_bits_relaxed(0x3, 0,
+ priv->io_base + _REG(VPU_HDMI_SETTING));
+
/* Disable all encoders */
writel_relaxed(0, priv->io_base + _REG(ENCI_VIDEO_EN));
writel_relaxed(0, priv->io_base + _REG(ENCP_VIDEO_EN));
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] drm/meson: Fix CVBS VDAC disable
From: Neil Armstrong @ 2017-01-04 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483523752-14705-1-git-send-email-narmstrong@baylibre.com>
This commit fixes the VDAC disabling register write values.
Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/gpu/drm/meson/meson_venc_cvbs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/meson/meson_venc_cvbs.c b/drivers/gpu/drm/meson/meson_venc_cvbs.c
index c809c08..a2bcc70 100644
--- a/drivers/gpu/drm/meson/meson_venc_cvbs.c
+++ b/drivers/gpu/drm/meson/meson_venc_cvbs.c
@@ -167,7 +167,7 @@ static void meson_venc_cvbs_encoder_disable(struct drm_encoder *encoder)
/* Disable CVBS VDAC */
regmap_write(priv->hhi, HHI_VDAC_CNTL0, 0);
- regmap_write(priv->hhi, HHI_VDAC_CNTL1, 0);
+ regmap_write(priv->hhi, HHI_VDAC_CNTL1, 8);
}
static void meson_venc_cvbs_encoder_enable(struct drm_encoder *encoder)
--
1.9.1
^ permalink raw reply related
* [PATCH] drm/meson: Fix plane atomic check when no crtc for the plane
From: Neil Armstrong @ 2017-01-04 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104091020.rvikywzzfsqxxp5t@phenom.ffwll.local>
On 01/04/2017 10:10 AM, Daniel Vetter wrote:
> On Tue, Jan 03, 2017 at 10:20:54AM +0100, Neil Armstrong wrote:
>> When no CRTC is associated with the plane, the meson_plane_atomic_check()
>> call breaks the kernel with an Oops.
>>
>> Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>
> Makes sense, pls send a pull request with this to Dave.
> -Daniel
Hi Daniel,
OK, I will push this one with the CVBS fixes I just pushed.
Thanks,
Neil
^ permalink raw reply
* [PATCH v3 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Jose Abreu @ 2017-01-04 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483512847-25710-3-git-send-email-appanad@xilinx.com>
Hi Kedar,
On 04-01-2017 06:54, Kedareswara rao Appana wrote:
> When VDMA is configured for more than one frame in the h/w
> for example h/w is configured for n number of frames and user
> Submits n number of frames and triggered the DMA using issue_pending API.
> In the current driver flow we are submitting one frame at a time
> but we should submit all the n number of frames at one time as the h/w
> Is configured for n number of frames.
>
> This patch fixes this issue.
>
> Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
Looks fine. I have a couple of minor comments, if you address
them you can add "Reviewed-by: Jose Abreu <joabreu@synopsys.com>"
in next version.
> ---
> Changes for v3:
> ---> Added Checks for frame store configuration. If frame store
> Configuration is not present at the h/w level and user
> Submits less frames added debug prints in the driver as relevant.
> Changes for v2:
> ---> Fixed race conditions in the driver as suggested by Jose Abreu
> ---> Fixed unnecessray if else checks in the vdma_start_transfer
> as suggested by Laurent Pinchart.
>
> .../devicetree/bindings/dma/xilinx/xilinx_dma.txt | 2 +
> drivers/dma/xilinx/xilinx_dma.c | 78 +++++++++++++++-------
> 2 files changed, 57 insertions(+), 23 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> index a2b8bfa..1f65e09 100644
> --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
> @@ -66,6 +66,8 @@ Optional child node properties:
> Optional child node properties for VDMA:
> - xlnx,genlock-mode: Tells Genlock synchronization is
> enabled/disabled in hardware.
> +- xlnx,fstore-config: Tells Whether Frame Store Configuration is
> + enabled/disabled in hardware.
> Optional child node properties for AXI DMA:
> -dma-channels: Number of dma channels in child node.
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index be7eb41..7cd8e08 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -322,6 +322,7 @@ struct xilinx_dma_tx_descriptor {
> * @genlock: Support genlock mode
> * @err: Channel has errors
> * @idle: Check for channel idle
> + * @has_fstoreconfig: Check for frame store configuration
> * @tasklet: Cleanup work after irq
> * @config: Device configuration info
> * @flush_on_fsync: Flush on Frame sync
> @@ -353,6 +354,7 @@ struct xilinx_dma_chan {
> bool genlock;
> bool err;
> bool idle;
> + bool has_fstoreconfig;
> struct tasklet_struct tasklet;
> struct xilinx_vdma_config config;
> bool flush_on_fsync;
> @@ -990,6 +992,26 @@ static void xilinx_vdma_start_transfer(struct xilinx_dma_chan *chan)
> if (list_empty(&chan->pending_list))
> return;
>
> + /*
> + * Note: When VDMA is built with default h/w configuration
> + * On the S2MM(recv) side user should submit frames upto
> + * H/W configured. If users submits less than h/w configured
> + * VDMA engine tries to write to a invalid location
> + * Results undefined behaviour/memory corruption.
> + *
> + * If user would like to submit frames less than h/w capable
> + * On S2MM side please enable debug info 13 at the h/w level
> + * It will allows the frame buffers numbers to be modified at runtime.
> + */
> + if (!chan->has_fstoreconfig && chan->direction == DMA_DEV_TO_MEM &&
> + chan->desc_pendingcount < chan->num_frms) {
> + dev_dbg(chan->dev, "Frame Store Configuration is not enabled at the");
> + dev_dbg(chan->dev, " H/w level enable Debug info 13 at the h/w level");
> + dev_dbg(chan->dev, " OR Submit the frames upto h/w Capable\n\r");
> +
> + return;
> + }
Hmm, may dev_warn would be more suitable because with dev_dbg and
no dynamic debug enabled user will not know what happened. Also,
I am aware that in direction DMA_MEM_TO_DEV there will be no
corruption in PC side but it will be corruption in VDMA side
because it will read from invalid memory locations. Maybe drop
the check for channel direction.
I am also not fancy about dropping prints that are not grep'able
(you do not break line in each print so a user searching for the
whole string will not find it). Try to do a line break in each
print or change the string to be smaller.
Best regards,
Jose Miguel Abreu
> +
> desc = list_first_entry(&chan->pending_list,
> struct xilinx_dma_tx_descriptor, node);
> tail_desc = list_last_entry(&chan->pending_list,
> @@ -1052,25 +1074,38 @@ static void xilinx_vdma_start_transfer(struct xilinx_dma_chan *chan)
> if (chan->has_sg) {
> dma_ctrl_write(chan, XILINX_DMA_REG_TAILDESC,
> tail_segment->phys);
> + list_splice_tail_init(&chan->pending_list, &chan->active_list);
> + chan->desc_pendingcount = 0;
> } else {
> struct xilinx_vdma_tx_segment *segment, *last = NULL;
> - int i = 0;
> + int i = 0, j = 0;
>
> if (chan->desc_submitcount < chan->num_frms)
> i = chan->desc_submitcount;
>
> - list_for_each_entry(segment, &desc->segments, node) {
> - if (chan->ext_addr)
> - vdma_desc_write_64(chan,
> - XILINX_VDMA_REG_START_ADDRESS_64(i++),
> - segment->hw.buf_addr,
> - segment->hw.buf_addr_msb);
> - else
> - vdma_desc_write(chan,
> - XILINX_VDMA_REG_START_ADDRESS(i++),
> - segment->hw.buf_addr);
> -
> - last = segment;
> + for (j = 0; j < chan->num_frms; ) {
> + list_for_each_entry(segment, &desc->segments, node) {
> + if (chan->ext_addr)
> + vdma_desc_write_64(chan,
> + XILINX_VDMA_REG_START_ADDRESS_64(i++),
> + segment->hw.buf_addr,
> + segment->hw.buf_addr_msb);
> + else
> + vdma_desc_write(chan,
> + XILINX_VDMA_REG_START_ADDRESS(i++),
> + segment->hw.buf_addr);
> +
> + last = segment;
> + }
> + list_del(&desc->node);
> + list_add_tail(&desc->node, &chan->active_list);
> + j++;
> + if (list_empty(&chan->pending_list) ||
> + (i == chan->num_frms))
> + break;
> + desc = list_first_entry(&chan->pending_list,
> + struct xilinx_dma_tx_descriptor,
> + node);
> }
>
> if (!last)
> @@ -1081,20 +1116,14 @@ static void xilinx_vdma_start_transfer(struct xilinx_dma_chan *chan)
> vdma_desc_write(chan, XILINX_DMA_REG_FRMDLY_STRIDE,
> last->hw.stride);
> vdma_desc_write(chan, XILINX_DMA_REG_VSIZE, last->hw.vsize);
> - }
>
> - chan->idle = false;
> - if (!chan->has_sg) {
> - list_del(&desc->node);
> - list_add_tail(&desc->node, &chan->active_list);
> - chan->desc_submitcount++;
> - chan->desc_pendingcount--;
> + chan->desc_submitcount += j;
> + chan->desc_pendingcount -= j;
> if (chan->desc_submitcount == chan->num_frms)
> chan->desc_submitcount = 0;
> - } else {
> - list_splice_tail_init(&chan->pending_list, &chan->active_list);
> - chan->desc_pendingcount = 0;
> }
> +
> + chan->idle = false;
> }
>
> /**
> @@ -1342,6 +1371,7 @@ static int xilinx_dma_reset(struct xilinx_dma_chan *chan)
>
> chan->err = false;
> chan->idle = true;
> + chan->desc_submitcount = 0;
>
> return err;
> }
> @@ -2315,6 +2345,8 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
> has_dre = of_property_read_bool(node, "xlnx,include-dre");
>
> chan->genlock = of_property_read_bool(node, "xlnx,genlock-mode");
> + chan->has_fstoreconfig = of_property_read_bool(node,
> + "xlnx,fstore-config");
>
> err = of_property_read_u32(node, "xlnx,datawidth", &value);
> if (err) {
^ permalink raw reply
* [PATCH v2 09/11] net: mvpp2: simplify MVPP2_PRS_RI_* definitions
From: David Laight @ 2017-01-04 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482857660-16092-10-git-send-email-thomas.petazzoni@free-electrons.com>
From: Thomas Petazzoni
> Sent: 27 December 2016 16:54
> Some of the MVPP2_PRS_RI_* definitions use the ~(value) syntax, which
> doesn't compile nicely on 64-bit. Moreover, those definitions are in
> fact unneeded, since they are always used in combination with a bit
> mask that ensures only the appropriate bits are modified.
>
> Therefore, such definitions should just be set to 0x0. For example:
>
> #define MVPP2_PRS_RI_L2_CAST_MASK 0x600
> #define MVPP2_PRS_RI_L2_UCAST ~(BIT(9) | BIT(10))
> #define MVPP2_PRS_RI_L2_MCAST BIT(9)
> #define MVPP2_PRS_RI_L2_BCAST BIT(10)
>
> becomes
>
> #define MVPP2_PRS_RI_L2_CAST_MASK 0x600
> #define MVPP2_PRS_RI_L2_UCAST 0x0
> #define MVPP2_PRS_RI_L2_MCAST BIT(9)
> #define MVPP2_PRS_RI_L2_BCAST BIT(10)
...
Shouldn't MVPP2_PRS_RI_L2_CAST_MASK be defined as
(MVPP2_PRS_RI_L2_MCAST | MVPP2_PRS_RI_L2_BCAST)?
David
^ permalink raw reply
* [RFC PATCH 06/10] perf/core: Export AUX buffer helpers to modules
From: Peter Zijlstra @ 2017-01-04 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483467027-14547-7-git-send-email-will.deacon@arm.com>
On Tue, Jan 03, 2017 at 06:10:23PM +0000, Will Deacon wrote:
> +EXPORT_SYMBOL(perf_aux_output_begin);
> +EXPORT_SYMBOL(perf_aux_output_end);
> +EXPORT_SYMBOL(perf_aux_output_skip);
> +EXPORT_SYMBOL(perf_get_aux);
$ git grep EXPORT kernel/events/
kernel/events/core.c:EXPORT_SYMBOL_GPL(perf_event_disable);
kernel/events/core.c:EXPORT_SYMBOL_GPL(perf_event_enable);
kernel/events/core.c:EXPORT_SYMBOL_GPL(perf_event_addr_filters_sync);
kernel/events/core.c:EXPORT_SYMBOL_GPL(perf_event_refresh);
kernel/events/core.c:EXPORT_SYMBOL_GPL(perf_event_release_kernel);
kernel/events/core.c:EXPORT_SYMBOL_GPL(perf_event_read_value);
kernel/events/core.c:EXPORT_SYMBOL_GPL(perf_register_guest_info_callbacks);
kernel/events/core.c:EXPORT_SYMBOL_GPL(perf_unregister_guest_info_callbacks);
kernel/events/core.c:EXPORT_SYMBOL_GPL(perf_swevent_get_recursion_context);
kernel/events/core.c:EXPORT_SYMBOL_GPL(perf_trace_run_bpf_submit);
kernel/events/core.c:EXPORT_SYMBOL_GPL(perf_tp_event);
kernel/events/core.c:EXPORT_SYMBOL_GPL(perf_pmu_register);
kernel/events/core.c:EXPORT_SYMBOL_GPL(perf_pmu_unregister);
kernel/events/core.c:EXPORT_SYMBOL_GPL(perf_event_create_kernel_counter);
kernel/events/core.c:EXPORT_SYMBOL_GPL(perf_pmu_migrate_context);
kernel/events/core.c:EXPORT_SYMBOL_GPL(perf_event_sysfs_show);
kernel/events/hw_breakpoint.c:EXPORT_SYMBOL_GPL(register_user_hw_breakpoint);
kernel/events/hw_breakpoint.c:EXPORT_SYMBOL_GPL(modify_user_hw_breakpoint);
kernel/events/hw_breakpoint.c:EXPORT_SYMBOL_GPL(unregister_hw_breakpoint);
kernel/events/hw_breakpoint.c:EXPORT_SYMBOL_GPL(register_wide_hw_breakpoint);
kernel/events/hw_breakpoint.c:EXPORT_SYMBOL_GPL(unregister_wide_hw_breakpoint);
kernel/events/uprobes.c:EXPORT_SYMBOL_GPL(uprobe_register);
kernel/events/uprobes.c:EXPORT_SYMBOL_GPL(uprobe_unregister);
I see a distinct difference here... :-)
^ permalink raw reply
* [PATCH v6 06/14] irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare for ACPI
From: Hanjun Guo @ 2017-01-04 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e08b5583-bb82-4676-2370-1147d79416ac@arm.com>
On 2017/1/4 17:02, Marc Zyngier wrote:
> On 04/01/17 08:25, Hanjun Guo wrote:
>> On 2017/1/4 15:29, Tomasz Nowicki wrote:
>>> On 04.01.2017 08:02, Hanjun Guo wrote:
>>>> Hi Tomasz,
>>>>
>>>> On 2017/1/3 15:41, Tomasz Nowicki wrote:
>>>>> Hi,
>>>>>
>>>>> Can we merge patch 4 & 6 into one patch so that we keep refactoring part
>>>>> as one piece ? I do not see a reason to keep them separate or have patch
>>>>> 5 in between. You can refactor what needs to be refactored, add
>>>>> necessary functions to iort.c and then support ACPI for
>>>>> irq-gic-v3-its-platform-msi.c
>>>>
>>>> There are two functions here,
>>>> - retrieve the dev id from IORT which was DT based only;
>>>>
>>>> - init the platform msi domain from MADT;
>>>>
>>>> For each of them split it into two steps,
>>>> - refactor the code for ACPI later and it's easy for review
>>>> because wen can easily to figure out it has functional
>>>> change or not
>>>>
>>>> - add ACPI functionality
>>>>
>>>> Does it make sense?
>>>
>>> It is up to Marc, but personally I prefer:
>>> 1. Refactor dev id retrieving and init function in one patch and
>>> highlight no functional changes in changelog
>>> 2. Crate necessary infrastructure in iort.c
>>> 3. Then add ACPI support to irq-gic-v3-its-platform-msi.c
>>
>> I have no strong preferences, and it's easy to do so as just
>> need to squash/reorder the patches.
>>
>> Marc, Lorenzo, could you give some suggestions here?
>
> I think it'd make the reviewing easier to have patches that are
> semantically grouped together (all the ACPI IORT together, for example).
>
> It would help understanding where you're aiming at instead of jumping
> from irqchip to ACPI and back every other patch...
OK, I will reorder the patches and address the comments, then post
a new version.
Thanks
Hanjun
^ permalink raw reply
* [PATCH 2/4] dt-bindings: mfd: Remove TPS65217 interrupts
From: Lee Jones @ 2017-01-04 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209062833.5768-3-woogyom.kim@gmail.com>
On Fri, 09 Dec 2016, Milo Kim wrote:
> Interrupt numbers are from the datasheet, so no need to keep them in
> the ABI. Use the number in the DT file.
>
> Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
> ---
> arch/arm/boot/dts/am335x-bone-common.dtsi | 8 +++-----
> include/dt-bindings/mfd/tps65217.h | 26 --------------------------
> 2 files changed, 3 insertions(+), 31 deletions(-)
> delete mode 100644 include/dt-bindings/mfd/tps65217.h
Acked-by: Lee Jones <lee.jones@linaro.org>
I'm happy for this to go in via your respective ARM tree.
> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
> index 14b6269..3e32dd1 100644
> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
> @@ -6,8 +6,6 @@
> * published by the Free Software Foundation.
> */
>
> -#include <dt-bindings/mfd/tps65217.h>
> -
> / {
> cpus {
> cpu at 0 {
> @@ -319,13 +317,13 @@
> ti,pmic-shutdown-controller;
>
> charger {
> - interrupts = <TPS65217_IRQ_AC>, <TPS65217_IRQ_USB>;
> - interrupt-names = "AC", "USB";
> + interrupts = <0>, <1>;
> + interrupt-names = "USB", "AC";
> status = "okay";
> };
>
> pwrbutton {
> - interrupts = <TPS65217_IRQ_PB>;
> + interrupts = <2>;
> status = "okay";
> };
>
> diff --git a/include/dt-bindings/mfd/tps65217.h b/include/dt-bindings/mfd/tps65217.h
> deleted file mode 100644
> index cafb9e6..0000000
> --- a/include/dt-bindings/mfd/tps65217.h
> +++ /dev/null
> @@ -1,26 +0,0 @@
> -/*
> - * This header provides macros for TI TPS65217 DT bindings.
> - *
> - * Copyright (C) 2016 Texas Instruments
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful, but
> - * WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> - * General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License along with
> - * this program. If not, see <http://www.gnu.org/licenses/>.
> - */
> -
> -#ifndef __DT_BINDINGS_TPS65217_H__
> -#define __DT_BINDINGS_TPS65217_H__
> -
> -#define TPS65217_IRQ_USB 0
> -#define TPS65217_IRQ_AC 1
> -#define TPS65217_IRQ_PB 2
> -
> -#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [RFC PATCH 01/10] arm64: cpufeature: allow for version discrepancy in PMU implementations
From: Mark Rutland @ 2017-01-04 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483467027-14547-2-git-send-email-will.deacon@arm.com>
On Tue, Jan 03, 2017 at 06:10:18PM +0000, Will Deacon wrote:
> Perf already supports multiple PMU instances for heterogeneous systems,
> so there's no need to be strict in the cpufeature checking, particularly
> as the PMU extension is optional in the architecture.
>
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
There are remaining issues with PMU support exposed to KVM guests in
hetereogeneous systems, but I think that's a larger issue with KVM and
heterogeneous CPUs (and we're already aware of it), so FWIW:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
> arch/arm64/kernel/cpufeature.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index fdf8f045929f..47d0226620e8 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -184,7 +184,11 @@ static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
> ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_CTX_CMPS_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_WRPS_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_BRPS_SHIFT, 4, 0),
> - S_ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64DFR0_PMUVER_SHIFT, 4, 0),
> + /*
> + * We can instantiate multiple PMU instances with different levels
> + * of support.
> + * */
> + S_ARM64_FTR_BITS(FTR_NONSTRICT, FTR_EXACT, ID_AA64DFR0_PMUVER_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64DFR0_TRACEVER_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64DFR0_DEBUGVER_SHIFT, 4, 0x6),
> ARM64_FTR_END,
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH v2 2/5] arm64: Work around Falkor erratum 1003
From: Christoffer Dall @ 2017-01-04 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229224335.13531-2-cov@codeaurora.org>
On Thu, Dec 29, 2016 at 05:43:32PM -0500, Christopher Covington wrote:
> From: Shanker Donthineni <shankerd@codeaurora.org>
>
> On the Qualcomm Datacenter Technologies Falkor v1 CPU, memory accesses may
> allocate TLB entries using an incorrect ASID when TTBRx_EL1 is being
> updated. Changing the TTBRx_EL1[ASID] and TTBRx_EL1[BADDR] fields
> separately using a reserved ASID will ensure that there are no TLB entries
> with incorrect ASID after changing the the ASID.
When we restore guest state in KVM, we completely save and restore
TTBRx_EL1 from EL2. Would that be affected by this erratum?
Thanks,
-Christoffer
^ permalink raw reply
* [RFC v2 PATCH 1/3] ARM: NOMMU: introduce dma operations for noMMU
From: Vladimir Murzin @ 2017-01-04 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+M3ks7Kzskb-VBQQdC2cNC52kro+6g2M6n5Rw4_vz-T4xn_eg@mail.gmail.com>
Hello Benjamin,
On 02/01/17 15:26, Benjamin Gaignard wrote:
> Hello Vladimir,
>
> I have tested your patch on my setup (stm32f4: no MMU, no MPU) where
> I'm writing display driver.
> This driver use dma_alloc_wc() and dma_mmap_wc() for frame buffer
> allocation and mmapping.
>
> In dma-mapping-nommu.c you haven't implement dma_map_ops.mmap so
> obviously my driver
> doesn't work with your code.
> In current implementation it is buggy too but I submit a patch to fix
> that problem:
> http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8633/1
>
> Could it be possible for you to include mmap support in dma-mapping-nommu.c ?
>
IIRC, stm32f4 is Cortex-M4, so no cache support and it means that it uses
dma_noop_ops. I offloaded mmap to common implementation, but completely forgot
it has the same restriction as arm counterpart. Regardless, thanks for
noticing that!
It seems that I need to check that mapping is done from DMA coherent area (I'm
moving to dma-coherent and here we have dma_mmap_from_coherent for that) and
something like bellow for dma_noop_ops:
diff --git a/lib/dma-noop.c b/lib/dma-noop.c
index 3d766e7..d838b88 100644
--- a/lib/dma-noop.c
+++ b/lib/dma-noop.c
@@ -64,6 +64,25 @@ static int dma_noop_supported(struct device *dev, u64 mask)
return 1;
}
+static int dma_noop_mmap(struct device *dev, struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size)
+{
+ unsigned long user_count = vma_pages(vma);
+ unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
+ unsigned long pfn = page_to_pfn(virt_to_page(cpu_addr));
+ unsigned long off = vma->vm_pgoff;
+ int ret = -ENXIO;
+
+ if (off < count && user_count <= (count - off)) {
+ ret = remap_pfn_range(vma, vma->vm_start,
+ pfn + off,
+ user_count << PAGE_SHIFT,
+ vma->vm_page_prot);
+ }
+
+ return ret;
+}
+
struct dma_map_ops dma_noop_ops = {
.alloc = dma_noop_alloc,
.free = dma_noop_free,
@@ -71,6 +90,7 @@ struct dma_map_ops dma_noop_ops = {
.map_sg = dma_noop_map_sg,
.mapping_error = dma_noop_mapping_error,
.dma_supported = dma_noop_supported,
+ .mmap = dma_noop_mmap,
};
EXPORT_SYMBOL(dma_noop_ops);
I'd be glad to hear if it works for you.
Cheers
Vladimir
> Regards,
> Benjamin
^ permalink raw reply related
* [PATCH 0/2] ARM: davinci: improve the nand clock lookup
From: Bartosz Golaszewski @ 2017-01-04 10:36 UTC (permalink / raw)
To: linux-arm-kernel
Hi Sekhar,
this is a follow-up to the series fixing the da850 clocks.
Instead of having a half-measure of leaving out the dev_id from the
clock lookup table, make the aemif driver capable of accessing it
over platform data.
Tested with da850-lcdk.
Bartosz Golaszewski (2):
memory: aemif: allow passing device lookup table as platform data
ARM: da850: add the nand dev_id to the clock lookup table
arch/arm/mach-davinci/da850.c | 10 +---------
arch/arm/mach-davinci/da8xx-dt.c | 12 +++++++++++-
drivers/memory/ti-aemif.c | 8 +++++++-
include/linux/platform_data/ti-aemif.h | 23 +++++++++++++++++++++++
4 files changed, 42 insertions(+), 11 deletions(-)
create mode 100644 include/linux/platform_data/ti-aemif.h
--
2.9.3
^ permalink raw reply
* [PATCH 1/2] memory: aemif: allow passing device lookup table as platform data
From: Bartosz Golaszewski @ 2017-01-04 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483526167-24209-1-git-send-email-bgolaszewski@baylibre.com>
TI aemif driver creates its own subnodes of the device tree in order
to guarantee that all child devices are probed after the AEMIF timing
parameters are configured.
Some devices (e.g. da850) use struct of_dev_auxdata for clock lookup
but nodes created from within the aemif driver can't access the lookup
table.
Create a platform data structure that holds a pointer to
of_dev_auxdata so that we can use it with of_platform_populate().
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/memory/ti-aemif.c | 8 +++++++-
include/linux/platform_data/ti-aemif.h | 23 +++++++++++++++++++++++
2 files changed, 30 insertions(+), 1 deletion(-)
create mode 100644 include/linux/platform_data/ti-aemif.h
diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c
index a579a0f..22c1aee 100644
--- a/drivers/memory/ti-aemif.c
+++ b/drivers/memory/ti-aemif.c
@@ -20,6 +20,7 @@
#include <linux/of.h>
#include <linux/of_platform.h>
#include <linux/platform_device.h>
+#include <linux/platform_data/ti-aemif.h>
#define TA_SHIFT 2
#define RHOLD_SHIFT 4
@@ -335,6 +336,8 @@ static int aemif_probe(struct platform_device *pdev)
struct device_node *np = dev->of_node;
struct device_node *child_np;
struct aemif_device *aemif;
+ struct aemif_platform_data *pdata;
+ struct of_dev_auxdata *dev_lookup;
if (np == NULL)
return 0;
@@ -343,6 +346,9 @@ static int aemif_probe(struct platform_device *pdev)
if (!aemif)
return -ENOMEM;
+ pdata = dev_get_platdata(&pdev->dev);
+ dev_lookup = pdata ? pdata->dev_lookup : NULL;
+
platform_set_drvdata(pdev, aemif);
aemif->clk = devm_clk_get(dev, NULL);
@@ -390,7 +396,7 @@ static int aemif_probe(struct platform_device *pdev)
* parameters are set.
*/
for_each_available_child_of_node(np, child_np) {
- ret = of_platform_populate(child_np, NULL, NULL, dev);
+ ret = of_platform_populate(child_np, NULL, dev_lookup, dev);
if (ret < 0)
goto error;
}
diff --git a/include/linux/platform_data/ti-aemif.h b/include/linux/platform_data/ti-aemif.h
new file mode 100644
index 0000000..ac72e11
--- /dev/null
+++ b/include/linux/platform_data/ti-aemif.h
@@ -0,0 +1,23 @@
+/*
+ * TI DaVinci AEMIF platform glue.
+ *
+ * Copyright (C) 2017 BayLibre SAS
+ *
+ * Author:
+ * Bartosz Golaszewski <bgolaszewski@baylibre.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __TI_DAVINCI_AEMIF_DATA_H__
+#define __TI_DAVINCI_AEMIF_DATA_H__
+
+#include <linux/of_platform.h>
+
+struct aemif_platform_data {
+ struct of_dev_auxdata *dev_lookup;
+};
+
+#endif /* __TI_DAVINCI_AEMIF_DATA_H__ */
--
2.9.3
^ permalink raw reply related
* [PATCH 2/2] ARM: da850: add the nand dev_id to the clock lookup table
From: Bartosz Golaszewski @ 2017-01-04 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483526167-24209-1-git-send-email-bgolaszewski@baylibre.com>
The aemif driver can now access struct of_dev_auxdata (using platform
data).
Add the device id to the clock lookup table for the nand clock and
create a separate lookup table for aemif subnodes.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/da850.c | 10 +---------
arch/arm/mach-davinci/da8xx-dt.c | 12 +++++++++++-
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 55f6e11..7475f02 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -557,15 +557,7 @@ static struct clk_lookup da850_clks[] = {
CLK("da830-mmc.0", NULL, &mmcsd0_clk),
CLK("da830-mmc.1", NULL, &mmcsd1_clk),
CLK("ti-aemif", NULL, &aemif_clk),
- /*
- * The only user of this clock is davinci_nand and it get's it through
- * con_id. The nand node itself is created from within the aemif
- * driver to guarantee that it's probed after the aemif timing
- * parameters are configured. of_dev_auxdata is not accessible from
- * the aemif driver and can't be passed to of_platform_populate(). For
- * that reason we're leaving the dev_id here as NULL.
- */
- CLK(NULL, "aemif", &aemif_nand_clk),
+ CLK("davinci-nand.0", "aemif", &aemif_nand_clk),
CLK("ohci-da8xx", "usb11", &usb11_clk),
CLK("musb-da8xx", "usb20", &usb20_clk),
CLK("spi_davinci.0", NULL, &spi0_clk),
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 9ee44da..06205fe 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -11,6 +11,7 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/irqdomain.h>
+#include <linux/platform_data/ti-aemif.h>
#include <asm/mach/arch.h>
@@ -18,6 +19,15 @@
#include "cp_intc.h"
#include <mach/da8xx.h>
+static struct of_dev_auxdata da850_aemif_auxdata_lookup[] = {
+ OF_DEV_AUXDATA("ti,davinci-nand", 0x62000000, "davinci-nand.0", NULL),
+ {}
+};
+
+static struct aemif_platform_data aemif_data = {
+ .dev_lookup = da850_aemif_auxdata_lookup,
+};
+
static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
OF_DEV_AUXDATA("ti,davinci-i2c", 0x01e28000, "i2c_davinci.2", NULL),
@@ -37,7 +47,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,davinci-dm6467-emac", 0x01e20000, "davinci_emac.1",
NULL),
OF_DEV_AUXDATA("ti,da830-mcasp-audio", 0x01d00000, "davinci-mcasp.0", NULL),
- OF_DEV_AUXDATA("ti,da850-aemif", 0x68000000, "ti-aemif", NULL),
+ OF_DEV_AUXDATA("ti,da850-aemif", 0x68000000, "ti-aemif", &aemif_data),
OF_DEV_AUXDATA("ti,da850-tilcdc", 0x01e13000, "da8xx_lcdc.0", NULL),
OF_DEV_AUXDATA("ti,da830-ohci", 0x01e25000, "ohci-da8xx", NULL),
OF_DEV_AUXDATA("ti,da830-musb", 0x01e00000, "musb-da8xx", NULL),
--
2.9.3
^ permalink raw reply related
* [PATCH] ARM: dts: armada388-clearfog: fix SPI flash #size-cells
From: Gregory CLEMENT @ 2017-01-04 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cO41M-0007xc-Id@rmk-PC.armlinux.org.uk>
Hi Russell,
On lun., janv. 02 2017, Russell King <rmk+kernel@armlinux.org.uk> wrote:
> The SPI flash #size-cells is specified in the binding documentation to
> have value 1, but we were setting it to zero. This wasn't causing any
> problem as we do not list any partitions, but it's worth specifying
> correctly if we're going to specify it at all.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied on mvebu/dt
Thanks,
Gregory
> ---
> arch/arm/boot/dts/armada-388-clearfog.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts b/arch/arm/boot/dts/armada-388-clearfog.dts
> index 71ce201c903e..3e7c3a6237c3 100644
> --- a/arch/arm/boot/dts/armada-388-clearfog.dts
> +++ b/arch/arm/boot/dts/armada-388-clearfog.dts
> @@ -437,7 +437,7 @@
>
> spi-flash at 0 {
> #address-cells = <1>;
> - #size-cells = <0>;
> + #size-cells = <1>;
> compatible = "w25q32", "jedec,spi-nor";
> reg = <0>; /* Chip select 0 */
> spi-max-frequency = <3000000>;
> --
> 2.7.4
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [RFC PATCH 09/10] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension
From: Peter Zijlstra @ 2017-01-04 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483467027-14547-10-git-send-email-will.deacon@arm.com>
On Tue, Jan 03, 2017 at 06:10:26PM +0000, Will Deacon wrote:
> The ARMv8.2 architecture introduces the Statistical Profiling Extension
> (SPE). SPE provides a way to configure and collect profiling samples
> from the CPU in the form of a trace buffer, which can be mapped directly
> into userspace using the perf AUX buffer infrastructure.
>
> This patch adds support for SPE in the form of a new perf driver.
>
Can you give a little high level overview of what exactly SPE is?
^ 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