* [PATCH v2 3/4] ARM: davinci: da8xx: add pdata-quirks, use for VPIF capture
From: Kevin Hilman @ 2016-12-07 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207193137.27947-1-khilman@baylibre.com>
Add pdata-quirks for da8xx DT platforms, which adds the legacy platform
data for vpif_capture driver.
Passing legacy platform_data is required until the V4L2 framework, and
subdevice drivers (such as the tvp514x) grow a way of selecting input
and output routing (c.f. V4L2 s_routing API)
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/mach-davinci/Makefile | 2 +-
arch/arm/mach-davinci/da8xx-dt.c | 2 +
arch/arm/mach-davinci/include/mach/common.h | 4 +
arch/arm/mach-davinci/pdata-quirks.c | 155 ++++++++++++++++++++++++++++
4 files changed, 162 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-davinci/pdata-quirks.c
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index da4c336b4637..90d2e6e4d913 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -21,7 +21,7 @@ obj-$(CONFIG_AINTC) += irq.o
obj-$(CONFIG_CP_INTC) += cp_intc.o
# Board specific
-obj-$(CONFIG_MACH_DA8XX_DT) += da8xx-dt.o
+obj-$(CONFIG_MACH_DA8XX_DT) += da8xx-dt.o pdata-quirks.o
obj-$(CONFIG_MACH_DAVINCI_EVM) += board-dm644x-evm.o
obj-$(CONFIG_MACH_SFFSDR) += board-sffsdr.o
obj-$(CONFIG_MACH_NEUROS_OSD2) += board-neuros-osd2.o
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index c9f7e9274aa8..69c8099de9f5 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -38,6 +38,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
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-vpif", 0x01e17000, "vpif", NULL),
{}
};
@@ -46,6 +47,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
static void __init da850_init_machine(void)
{
of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
+ pdata_quirks_init();
}
static const char *const da850_boards_compat[] __initconst = {
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 0b3c169758ed..1fd4cd2d1c23 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -102,6 +102,10 @@ int davinci_pm_init(void);
static inline int davinci_pm_init(void) { return 0; }
#endif
+#ifdef CONFIG_MACH_DA8XX_DT
+extern void __init pdata_quirks_init(void);
+#endif
+
#define SRAM_SIZE SZ_128K
#endif /* __ARCH_ARM_MACH_DAVINCI_COMMON_H */
diff --git a/arch/arm/mach-davinci/pdata-quirks.c b/arch/arm/mach-davinci/pdata-quirks.c
new file mode 100644
index 000000000000..a186513edf7e
--- /dev/null
+++ b/arch/arm/mach-davinci/pdata-quirks.c
@@ -0,0 +1,155 @@
+/*
+ * Legacy platform_data quirks
+ *
+ * Copyright (C) 2016 BayLibre, Inc
+ *
+ * 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.
+ */
+#include <linux/kernel.h>
+#include <linux/of_platform.h>
+
+#include <media/i2c/tvp514x.h>
+
+#include <mach/common.h>
+#include <mach/da8xx.h>
+#include <mach/mux.h>
+
+struct pdata_init {
+ const char *compatible;
+ void (*fn)(void);
+};
+
+#if IS_ENABLED(CONFIG_VIDEO_DAVINCI_VPIF_CAPTURE)
+
+#define TVP5147_CH0 "tvp514x-0"
+#define TVP5147_CH1 "tvp514x-1"
+
+/* VPIF capture configuration */
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1,
+};
+
+#define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
+
+static const struct vpif_input da850_ch0_inputs[] = {
+ {
+ .input = {
+ .index = 0,
+ .name = "Composite",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .capabilities = V4L2_IN_CAP_STD,
+ .std = TVP514X_STD_ALL,
+ },
+ .input_route = INPUT_CVBS_VI2B,
+ .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ .subdev_name = TVP5147_CH0,
+ },
+};
+
+static const struct vpif_input da850_ch1_inputs[] = {
+ {
+ .input = {
+ .index = 0,
+ .name = "S-Video",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .capabilities = V4L2_IN_CAP_STD,
+ .std = TVP514X_STD_ALL,
+ },
+ .input_route = INPUT_SVIDEO_VI2C_VI1C,
+ .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ .subdev_name = TVP5147_CH1,
+ },
+};
+
+static struct vpif_subdev_info da850_vpif_capture_sdev_info[] = {
+ {
+ .name = TVP5147_CH0,
+ .board_info = {
+ I2C_BOARD_INFO("tvp5146", 0x5d),
+ .platform_data = &tvp5146_pdata,
+ },
+ },
+ {
+ .name = TVP5147_CH1,
+ .board_info = {
+ I2C_BOARD_INFO("tvp5146", 0x5c),
+ .platform_data = &tvp5146_pdata,
+ },
+ },
+};
+
+static struct vpif_capture_config da850_vpif_capture_config = {
+ .subdev_info = da850_vpif_capture_sdev_info,
+ .subdev_count = ARRAY_SIZE(da850_vpif_capture_sdev_info),
+ .chan_config[0] = {
+ .inputs = da850_ch0_inputs,
+ .input_count = ARRAY_SIZE(da850_ch0_inputs),
+ .vpif_if = {
+ .if_type = VPIF_IF_BT656,
+ .hd_pol = 1,
+ .vd_pol = 1,
+ .fid_pol = 0,
+ },
+ },
+ .chan_config[1] = {
+ .inputs = da850_ch1_inputs,
+ .input_count = ARRAY_SIZE(da850_ch1_inputs),
+ .vpif_if = {
+ .if_type = VPIF_IF_BT656,
+ .hd_pol = 1,
+ .vd_pol = 1,
+ .fid_pol = 0,
+ },
+ },
+ .card_name = "DA850/OMAP-L138 Video Capture",
+};
+
+static void __init da850_vpif_legacy_init(void)
+{
+ int ret;
+
+ /* LCDK doesn't have the 2nd TVP514x on CH1 */
+ if (of_machine_is_compatible("ti,da850-lcdk"))
+ da850_vpif_capture_config.subdev_count = 1;
+
+ /* EVM (UI card) uses i2c adapter 1 (not default: zero) */
+ if (of_machine_is_compatible("ti,da850-evm"))
+ da850_vpif_capture_config.i2c_adapter_id = 1;
+
+ ret = da850_register_vpif_capture(&da850_vpif_capture_config);
+ if (ret)
+ pr_warn("%s: VPIF capture setup failed: %d\n",
+ __func__, ret);
+}
+#endif
+
+static void pdata_quirks_check(struct pdata_init *quirks)
+{
+ while (quirks->compatible) {
+ if (of_machine_is_compatible(quirks->compatible)) {
+ if (quirks->fn)
+ quirks->fn();
+ break;
+ }
+ quirks++;
+ }
+}
+
+static struct pdata_init pdata_quirks[] __initdata = {
+#if IS_ENABLED(CONFIG_VIDEO_DAVINCI_VPIF_CAPTURE)
+ { "ti,da850-lcdk", da850_vpif_legacy_init, },
+#if defined(CONFIG_DA850_UI_SD_VIDEO_PORT)
+ { "ti,da850-evm", da850_vpif_legacy_init, },
+#endif
+#endif
+ { /* sentinel */ },
+};
+
+void __init pdata_quirks_init(void)
+{
+ pdata_quirks_check(pdata_quirks);
+}
--
2.9.3
^ permalink raw reply related
* [PATCH v2 4/4] ARM: davinci: board-da850-evm: add I2C ID for VPIF
From: Kevin Hilman @ 2016-12-07 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207193137.27947-1-khilman@baylibre.com>
VPIF capture driver now has a way to specific I2C adapter ID (was
previously hard-coded.) Use the new interface.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/mach-davinci/board-da850-evm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 8e4539f69fdc..60f15f276ab7 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1229,6 +1229,7 @@ static struct vpif_subdev_info da850_vpif_capture_sdev_info[] = {
static struct vpif_capture_config da850_vpif_capture_config = {
.subdev_info = da850_vpif_capture_sdev_info,
.subdev_count = ARRAY_SIZE(da850_vpif_capture_sdev_info),
+ .i2c_adapter_id = 1,
.chan_config[0] = {
.inputs = da850_ch0_inputs,
.input_count = ARRAY_SIZE(da850_ch0_inputs),
--
2.9.3
^ permalink raw reply related
* [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check
From: Laurent Pinchart @ 2016-12-07 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87oa0nbldb.fsf@eliezer.anholt.net>
Hi Eric,
On Wednesday 07 Dec 2016 11:16:32 Eric Anholt wrote:
> Maxime Ripard <maxime.ripard@free-electrons.com> writes:
> > [ Unknown signature status ]
> >
> > On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote:
> >> The panels shipped with Allwinner devices are very "generic", i.e.
> >> they do not have model numbers or reliable sources of information
> >> for the timings (that we know of) other than the fex files shipped
> >> on them. The dot clock frequency provided in the fex files have all
> >> been rounded to the nearest MHz, as that is the unit used in them.
> >>
> >> We were using the simple panel "urt,umsh-8596md-t" as a substitute
> >> for the A13 Q8 tablets in the absence of a specific model for what
> >> may be many different but otherwise timing compatible panels. This
> >> was usable without any visual artifacts or side effects, until the
> >> dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4i:
> >> rgb: Validate the clock rate").
> >>
> >> The reason this check fails is because the dotclock frequency for
> >> this model is 33.26 MHz, which is not achievable with our dot clock
> >> hardware, and the rate returned by clk_round_rate deviates slightly,
> >> causing the driver to reject the display mode.
> >>
> >> The LCD panels have some tolerance on the dot clock frequency, even
> >> if it's not specified in their datasheets.
> >>
> >> This patch adds a 5% tolerence to the dot clock check.
> >
> > As we discussed already, I really believe this is just as arbitrary as
> > the current behaviour.
> >
> > Some panels require an exact frequency, some have a minimal frequency
> > but no maximum, some have a maximum frequency but no minimal, and I
> > guess most of them deviates by how much exactly they can take (and
> > possibly can take more easily a higher frequency, but are less
> > tolerant if you take a frequency lower than the nominal.
> >
> > And we cannot remove that check entirely, since some bridges will
> > report out of range frequencies for higher modes that we know we
> > cannot reach.
> >
> > We could just try to see if the screen pixel clock frequency is out of
> > the pixel clock range we can generate, but then we will loop back on
> > how much out of range is it exactly, and is it within the screen
> > tolerancy.
> >
> > We have an API to deal with the panel tolerancies in the DRM panel
> > framework, we can (and should) use it.
> >
> > I'm not sure how others usually deal with this though. I think I
> > remember Eric telling me that for the RPi they just adjusted the
> > timings a bit, but they only really had a single panel to deal with.
>
> For RPi, you just adjust the pixel clock of the panel's mode to be
> whatever the platform can support, and expand the blanking intervals to
> get the refresh rate back to desired. This is nothing like what the
> datasheet says, but it's not important what the datasheet says, it's
> important what makes the product work.
>
> Our clock driver looks for the best matching clock that's not over the
> target rate. This is somewhat unfortunate, as you end up slightly
> inflating your requested clocks so that a possible clock lands under
> that. I'd rather we chose the closest matching clock, but then people
> get worried about what if selected clock rate is 1% higher than expected
> (the answer is "nothing").
But if the closest match is 10% off and higher results could be different, in
which case a lower match that is 11% off might be better. The hard part is to
decide where to set the limit, and I'm afraid the answer is likely system-
dependent.
> I think this patch is a fine solution, and the alternative would be to
> just drop the mode high/low check and say that if you're pairing a panel
> with some display hardware, it's up to you to make sure that the panel's
> mode actually scans out successfully. Then, since compatible strings
> are cheap, you can use a new one if necessary to attach better modes to
> the panel for a particular clock driver by adjusting your timings to get
> closer to the refresh rates you want.
Given that timings tolerance can be system-dependent and not only panel-
dependent, it would make sense to specify them in DT (possibly an optional
properties with reasonable default values computed by drivers).
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 1/4] ARM: dts: davinci: da850: VPIF: add node and muxing
From: Laurent Pinchart @ 2016-12-07 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207193137.27947-2-khilman@baylibre.com>
Hi Kevin,
Thank you for the patch.
On Wednesday 07 Dec 2016 11:31:34 Kevin Hilman wrote:
> Add VPIF node an pins to da850 and enable on boards. VPIF has two input
> channels described using the standard DT ports and enpoints.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> arch/arm/boot/dts/da850-evm.dts | 6 ++++++
> arch/arm/boot/dts/da850-lcdk.dts | 6 ++++++
> arch/arm/boot/dts/da850.dtsi | 38 +++++++++++++++++++++++++++++++++++-
> 3 files changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/da850-evm.dts
> b/arch/arm/boot/dts/da850-evm.dts index 41de15fe15a2..212b50d4f84b 100644
> --- a/arch/arm/boot/dts/da850-evm.dts
> +++ b/arch/arm/boot/dts/da850-evm.dts
> @@ -289,3 +289,9 @@
> };
> };
> };
> +
> +&vpif {
> + pinctrl-names = "default";
> + pinctrl-0 = <&vpif_capture_pins>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
> b/arch/arm/boot/dts/da850-lcdk.dts index 7b8ab21fed6c..67f846f5bb35 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -219,3 +219,9 @@
> };
> };
> };
> +
> +&vpif {
> + pinctrl-names = "default";
> + pinctrl-0 = <&vpif_capture_pins>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index f79e1b91c680..dd2a13ed106e 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -186,7 +186,18 @@
> 0xc 0x88888888 0xffffffff
>
> >;
>
> };
> -
> + vpif_capture_pins: vpif_capture_pins {
> + pinctrl-single,bits = <
> + /* VP_DIN[2..7], VP_CLKIN1, VP_CLKIN0
*/
> + 0x38 0x11111111 0xffffffff
> + /* VP_DIN[10..15,0..1] */
> + 0x3c 0x11111111 0xffffffff
> + /* VP_DIN[8..9] */
> + 0x40 0x00000011 0x000000ff
> + /* VP_CLKIN3, VP_CLKIN2 */
> + 0x4c 0x00010100 0x000f0f00
> + >;
> + };
> };
> edma0: edma at 0 {
> compatible = "ti,edma3-tpcc";
> @@ -399,7 +410,32 @@
> <&edma0 0 1>;
> dma-names = "tx", "rx";
> };
> +
> + vpif: video at 217000 {
> + compatible = "ti,da850-vpif";
> + reg = <0x217000 0x1000>;
> + interrupts = <92>;
> + status = "disabled";
> +
> + /* VPIF capture: input channels */
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + vpif_ch0: endpoint at 0 {
> + reg = <0>;
> + bus-width = <8>;
> + };
> +
> + vpif_ch1: endpoint at 1 {
> + reg = <1>;
> + bus-width = <8>;
> + data-shift = <8>;
> + };
Given that the VPIF can also accept a single 16-bit input, I'd move the
endpoints to board files.
> + };
> + };
> };
> +
> aemif: aemif at 68000000 {
> compatible = "ti,da850-aemif";
> #address-cells = <2>;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2016-12-07 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481134912-2243-1-git-send-email-andrei.pistirica@microchip.com>
On Wed, Dec 07, 2016 at 08:21:51PM +0200, Andrei Pistirica wrote:
> +#ifdef CONFIG_MACB_USE_HWSTAMP
> +void gem_ptp_init(struct net_device *ndev);
> +void gem_ptp_remove(struct net_device *ndev);
> +
> +void gem_ptp_do_txstamp(struct macb *bp, struct sk_buff *skb);
> +void gem_ptp_do_rxstamp(struct macb *bp, struct sk_buff *skb);
These are in the hot path, and so you should do the test before
calling the global function, something like this:
void gem_ptp_txstamp(struct macb *bp, struct sk_buff *skb);
static void gem_ptp_do_txstamp(struct macb *bp, struct sk_buff *skb)
{
if (!bp->hwts_tx_en)
return;
gem_ptp_txstamp(bp, skb);
}
Ditto for Rx.
> +#else
> +static inline void gem_ptp_init(struct net_device *ndev) { }
> +static inline void gem_ptp_remove(struct net_device *ndev) { }
> +
> +static inline void gem_ptp_do_txstamp(struct macb *bp, struct sk_buff *skb) { }
> +static inline void gem_ptp_do_rxstamp(struct macb *bp, struct sk_buff *skb) { }
> +#endif
> +
> +static int gem_ptp_adjfine(struct ptp_clock_info *ptp, long scaled_ppm)
> +{
> + struct macb *bp = container_of(ptp, struct macb, ptp_caps);
> + u32 word, diff;
> + u64 adj, rate;
> + int neg_adj = 0;
> +
> + if (scaled_ppm < 0) {
> + neg_adj = 1;
> + scaled_ppm = -scaled_ppm;
> + }
> + rate = scaled_ppm;
> +
> + /* word: unused(8bit) | ns(8bit) | fractions(16bit) */
> + word = (bp->ns_incr << 16) + bp->subns_incr;
> +
> + adj = word;
> + adj *= rate;
> + adj >>= 16; /* remove fractions */
> + adj += 500000UL;
> + diff = div_u64(adj, 1000000UL);
In order to round correctly, shouldn't this be?
adj *= rate;
adj += 500000UL << 16;
adj >>= 16;
diff = div_u64(adj, 1000000UL);
> + word = neg_adj ? word - diff : word + diff;
> +
> + spin_lock(&bp->tsu_clk_lock);
> +
> + gem_writel(bp, TISUBN, GEM_BF(SUBNSINCR, (word & 0xffff)));
> + gem_writel(bp, TI, GEM_BF(NSINCR, (word >> 16)));
> +
> + spin_unlock(&bp->tsu_clk_lock);
> + return 0;
> +}
> +static s32 gem_ptp_max_adj(unsigned int f_nom)
> +{
> + u64 adj;
> +
> + /* The 48 bits of seconds for the GEM overflows every:
> + * 2^48/(365.25 * 24 * 60 *60) =~ 8 925 512 years (~= 9 mil years),
> + * thus the maximum adjust frequency must not overflow CNS register:
> + *
> + * addend = 10^9/nominal_freq
> + * adj_max = +/- addend*ppb_max/10^9
> + * max_ppb = (2^8-1)*nominal_freq-10^9
> + */
> + adj = f_nom;
> + adj *= 0xffff;
> + adj -= 1000000000ULL;
What is this computation, and how does it relate to the comment?
> + return adj;
> +}
> +/* While GEM can timestamp PTP packets, it does not mark the RX descriptor
Does it timestamp PTP event packets only, or all packets?
(See my comment in patch 2/2)
> + * to identify them. UDP packets must be parsed to identify PTP packets.
> + *
> + * Note: Inspired from drivers/net/ethernet/ti/cpts.c
> + */
Thanks,
Richard
^ permalink raw reply
* [PATCH 0/1] arm64: mm: add config options for page table configuration
From: Scott Branden @ 2016-12-07 19:39 UTC (permalink / raw)
To: linux-arm-kernel
This patch introduces config option CONFIG_MAX_PHYSMEM_BITS and
CONFIG_SECTIONS_SIZE_BITS to allow for memory savings for devices with
small memory areas in sparse memory configurations.
Scott Branden (1):
arm64: mm: add config options for page table configuration
arch/arm64/Kconfig | 21 +++++++++++++++++++++
arch/arm64/include/asm/sparsemem.h | 4 ++--
2 files changed, 23 insertions(+), 2 deletions(-)
--
2.5.0
^ permalink raw reply
* [PATCH 1/1] arm64: mm: add config options for page table configuration
From: Scott Branden @ 2016-12-07 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481139600-24455-1-git-send-email-scott.branden@broadcom.com>
Make MAX_PHYSMEM_BITS and SECTIONS_SIZE_BITS configurable by adding
config options.
Default to current settings currently defined in sparesmem.h.
For systems wishing to save memory the config options can be overridden.
Example, changing MAX_PHYSMEM_BITS from 48 to 36 at the same time as
changing SECTION_SIZE_BITS from 30 to 26 frees 13MB of memory.
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
---
arch/arm64/Kconfig | 21 +++++++++++++++++++++
arch/arm64/include/asm/sparsemem.h | 4 ++--
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 2482fdd..d0a95de 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -121,6 +121,27 @@ config ARCH_PHYS_ADDR_T_64BIT
config MMU
def_bool y
+config MAX_PHYSMEM_BITS
+ int "Maximum Physical Addressable Bits"
+ depends on SPARSEMEM
+ default 48
+ help
+ Maximum number of physical addressable bits.
+ If not all the physical bits are used this number can be reduced
+ to save memory when creating page tables.
+
+ If unsure, leave this at the default.
+
+config SECTION_SIZE_BITS
+ int "Section Size Bits"
+ depends on SPARSEMEM
+ default 30
+ help
+ Size of each memory section.
+ If you need to be able to allocate smaller
+ sections in page table this number can be change to save memory.
+
+ If unsure, leave this at the default.
config DEBUG_RODATA
def_bool y
diff --git a/arch/arm64/include/asm/sparsemem.h b/arch/arm64/include/asm/sparsemem.h
index 74a9d30..6677582 100644
--- a/arch/arm64/include/asm/sparsemem.h
+++ b/arch/arm64/include/asm/sparsemem.h
@@ -17,8 +17,8 @@
#define __ASM_SPARSEMEM_H
#ifdef CONFIG_SPARSEMEM
-#define MAX_PHYSMEM_BITS 48
-#define SECTION_SIZE_BITS 30
+#define MAX_PHYSMEM_BITS CONFIG_MAX_PHYSMEM_BITS
+#define SECTION_SIZE_BITS CONFIG_SECTION_SIZE_BITS
#endif
#endif
--
2.5.0
^ permalink raw reply related
* [RFC PATCH net-next v3 2/2] macb: Enable 1588 support in SAMA5Dx platforms.
From: Richard Cochran @ 2016-12-07 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481134912-2243-2-git-send-email-andrei.pistirica@microchip.com>
On Wed, Dec 07, 2016 at 08:21:52PM +0200, Andrei Pistirica wrote:
> +static int gem_hwtst_set(struct net_device *netdev,
> + struct ifreq *ifr, int cmd)
> +{
...
> + switch (config.rx_filter) {
> + case HWTSTAMP_FILTER_NONE:
> + if (priv->hwts_rx_en)
> + priv->hwts_rx_en = 0;
> + break;
> + case HWTSTAMP_FILTER_PTP_V1_L4_EVENT:
> + case HWTSTAMP_FILTER_PTP_V2_L4_EVENT:
> + case HWTSTAMP_FILTER_PTP_V2_L2_EVENT:
> + case HWTSTAMP_FILTER_ALL:
> + case HWTSTAMP_FILTER_PTP_V1_L4_SYNC:
> + case HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ:
> + case HWTSTAMP_FILTER_PTP_V2_L2_SYNC:
> + case HWTSTAMP_FILTER_PTP_V2_L4_SYNC:
> + case HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ:
> + case HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ:
> + case HWTSTAMP_FILTER_PTP_V2_EVENT:
> + case HWTSTAMP_FILTER_PTP_V2_SYNC:
> + case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
> + config.rx_filter = HWTSTAMP_FILTER_ALL;
Does the device really time stamp all packets?
Or did you mean "all PTP packets? For that, use
HWTSTAMP_FILTER_PTP_V2_EVENT.
Thanks,
Richard
^ permalink raw reply
* [PATCH v3 1/6] crypto: testmgr - avoid overlap in chunked tests
From: Ard Biesheuvel @ 2016-12-07 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207191920.GA139213@google.com>
On 7 December 2016 at 19:19, Eric Biggers <ebiggers@google.com> wrote:
> On Mon, Dec 05, 2016 at 06:42:23PM +0000, Ard Biesheuvel wrote:
>> The IDXn offsets are chosen such that tap values (which may go up to
>> 255) end up overlapping in the xbuf allocation. In particular, IDX1
>> and IDX3 are too close together, so update IDX3 to avoid this issue.
>>
>
> Hi Ard,
>
> This patch is causing the self-tests for "xts(ecb(aes-asm))" to fail.
> This is on x86. Any idea why?
Does this help at all?
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 670893bcf361..59e67f5b544b 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -63,7 +63,7 @@ int alg_test(const char *driver, const char *alg,
u32 type, u32 mask)
*/
#define IDX1 32
#define IDX2 32400
-#define IDX3 511
+#define IDX3 1511
#define IDX4 8193
#define IDX5 22222
#define IDX6 17101
> Here's what I see in the log:
>
> alg: skcipher: Chunk test 1 failed on encryption at page 0 for xts(ecb(aes-asm))
> 00000000: 1c 3b 3a 10 2f 77 03 86 e4 83 6c 99 e3 70 cf 9b
> 00000010: ea 00 80 3f 5e 48 23 57 a4 ae 12 d4 14 a3 e6 3b
> 00000020: 5d 31 e2 76 f8 fe 4a 8d 66 b3 17 f9 ac 68 3f 44
> 00000030: 68 0a 86 ac 35 ad fc 33 45 be fe cb 4b b1 88 fd
> 00000040: 57 76 92 6c 49 a3 09 5e b1 08 fd 10 98 ba ec 70
> 00000050: aa a6 69 99 a7 2a 82 f2 7d 84 8b 21 d4 a7 41 b0
> 00000060: c5 cd 4d 5f ff 9d ac 89 ae ba 12 29 61 d0 3a 75
> 00000070: 71 23 e9 87 0f 8a cf 10 00 02 08 87 89 14 29 ca
> 00000080: 2a 3e 7a 7d 7d f7 b1 03 55 16 5c 8b 9a 6d 0a 7d
> 00000090: e8 b0 62 c4 50 0d c4 cd 12 0c 0f 74 18 da e3 d0
> 000000a0: b5 78 1c 34 80 3f a7 54 21 c7 90 df e1 de 18 34
> 000000b0: f2 80 d7 66 7b 32 7f 6c 8c d7 55 7e 12 ac 3a 0f
> 000000c0: 93 ec 05 c5 2e 04 93 ef 31 a1 2d 3d 92 60 f7 9a
> 000000d0: 28 9d 6a 37 9b c7 0c 50 84 14 73 d1 a8 cc 81 ec
> 000000e0: 58 3e 96 45 e0 7b 8d 96 70 65 5b a5 bb cf ec c6
> 000000f0: dc 39 66 38 0a d8 fe cb 17 b6 ba 02 46 9a 02 0a
> 00000100: 84 e1 8e 8f 84 25 20 70 c1 3e 9f 1f 28 9b e5 4f
> 00000110: bc 48 14 57 77 8f 61 60 15 e1 32 7a 02 b1 40 f1
> 00000120: 50 5e b3 09 32 6d 68 37 8f 83 74 59 5c 84 9d 84
> 00000130: f4 c3 33 ec 44 23 88 51 43 cb 47 bd 71 c5 ed ae
> 00000140: 9b e6 9a 2f fe ce b1 be c9 de 24 4f be 15 99 2b
> 00000150: 11 b7 7c 04 0f 12 bd 8f 6a 97 5a 44 a0 f9 0c 29
> 00000160: a9 ab c3 d4 d8 93 92 72 84 c5 87 54 cc e2 94 52
> 00000170: 9f 86 14 dc d2 ab a9 91 92 5f ed c4 ae 74 ff ac
> 00000180: 6e 33 3b 93 eb 4a ff 04 79 da 9a 41 0e 44 50 e0
> 00000190: dd 7a e4 c6 e2 91 09 00 57 5d a4 01 fc 07 05 9f
> 000001a0: 64 5e 8b 7e 9b fd ef 33 94 30 54 ff 84 01 14 93
> 000001b0: c2 7b 34 29 ea ed b4 ed 53 76 44 1a 77 ed 43 85
> 000001c0: 1a d7 7f 16 f5 41 df d2 69 d5 0d 6a 5f 14 fb 0a
> 000001d0: 1e 2a 8f 42 61 9e 5e c2 59 bd 96 d0 e5 cc 23 1f
> 000001e0: fb 84 ed 15 a8 eb 66 07 31 6b f6 ef
>
> Eric
^ permalink raw reply related
* [PATCH 1/3] arm64: Define Qualcomm Technologies Falkor v1 CPU
From: Christopher Covington @ 2016-12-07 20:00 UTC (permalink / raw)
To: linux-arm-kernel
From: Shanker Donthineni <shankerd@codeaurora.org>
This patch adds the cputype info for Qualcomm Technologies ARMv8 CPU
implementer ID 0x51 and part number for Falkor v1 in cputype.h.
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
arch/arm64/include/asm/cputype.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 26a68dd..ee60561 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -71,6 +71,7 @@
#define ARM_CPU_IMP_APM 0x50
#define ARM_CPU_IMP_CAVIUM 0x43
#define ARM_CPU_IMP_BRCM 0x42
+#define ARM_CPU_IMP_QCOM 0x51
#define ARM_CPU_PART_AEM_V8 0xD0F
#define ARM_CPU_PART_FOUNDATION 0xD00
@@ -84,10 +85,13 @@
#define BRCM_CPU_PART_VULCAN 0x516
+#define QCOM_CPU_PART_FALKOR_V1 0x800
+
#define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53)
#define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57)
#define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)
+#define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR_V1)
#ifndef __ASSEMBLY__
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 2/3] arm64: Work around Falkor erratum 1003
From: Christopher Covington @ 2016-12-07 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207200028.4420-1-cov@codeaurora.org>
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.
Pseudo code:
write TTBRx_EL1[ASID] to a reserved value
ISB
write TTBRx_EL1[BADDR] to a desired value
ISB
write TTBRx_EL1[ASID] to a desired value
ISB
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
arch/arm64/Kconfig | 11 +++++++++++
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/kernel/cpu_errata.c | 7 +++++++
arch/arm64/mm/context.c | 10 ++++++++++
arch/arm64/mm/proc.S | 21 +++++++++++++++++++++
5 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 969ef88..1004a3d 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -474,6 +474,17 @@ config CAVIUM_ERRATUM_27456
If unsure, say Y.
+config QCOM_FALKOR_ERRATUM_E1003
+ bool "Falkor E1003: Incorrect translation due to ASID change"
+ default y
+ help
+ An incorrect translation TLBI entry may be created while
+ changing the ASID & translation table address together for
+ TTBR0_EL1. The workaround for this issue is use a reserved
+ ASID in cpu_do_switch_mm() before switching to target ASID.
+
+ If unsure, say Y.
+
endmenu
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 87b4465..cb6a8c2 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -34,7 +34,8 @@
#define ARM64_HAS_32BIT_EL0 13
#define ARM64_HYP_OFFSET_LOW 14
#define ARM64_MISMATCHED_CACHE_LINE_SIZE 15
+#define ARM64_WORKAROUND_QCOM_FALKOR_E1003 16
-#define ARM64_NCAPS 16
+#define ARM64_NCAPS 17
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index b75e917..3789e2f 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -130,6 +130,13 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
.def_scope = SCOPE_LOCAL_CPU,
.enable = cpu_enable_trap_ctr_access,
},
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1003
+ {
+ .desc = "Qualcomm Falkor erratum E1003",
+ .capability = ARM64_WORKAROUND_QCOM_FALKOR_E1003,
+ MIDR_RANGE(MIDR_QCOM_FALKOR_V1, 0x00, 0x00),
+ },
+#endif
{
}
};
diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index efcf1f7..f8d94ff 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -87,6 +87,11 @@ static void flush_context(unsigned int cpu)
/* Update the list of reserved ASIDs and the ASID bitmap. */
bitmap_clear(asid_map, 0, NUM_USER_ASIDS);
+ /* Reserve ASID '1' for Falkor erratum E1003 */
+ if (IS_ENABLED(CONFIG_QCOM_FALKOR_ERRATUM_E1003) &&
+ cpus_have_cap(ARM64_WORKAROUND_QCOM_FALKOR_E1003))
+ __set_bit(1, asid_map);
+
/*
* Ensure the generation bump is observed before we xchg the
* active_asids.
@@ -239,6 +244,11 @@ static int asids_init(void)
panic("Failed to allocate bitmap for %lu ASIDs\n",
NUM_USER_ASIDS);
+ /* Reserve ASID '1' for Falkor erratum E1003 */
+ if (IS_ENABLED(CONFIG_QCOM_FALKOR_ERRATUM_E1003) &&
+ cpus_have_cap(ARM64_WORKAROUND_QCOM_FALKOR_E1003))
+ __set_bit(1, asid_map);
+
pr_info("ASID allocator initialised with %lu entries\n", NUM_USER_ASIDS);
return 0;
}
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 352c73b..b4d6508 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -134,6 +134,27 @@ ENDPROC(cpu_do_resume)
ENTRY(cpu_do_switch_mm)
mmid x1, x1 // get mm->context.id
bfi x0, x1, #48, #16 // set the ASID
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1003
+alternative_if_not ARM64_WORKAROUND_QCOM_FALKOR_E1003
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+alternative_else
+ mrs x2, ttbr0_el1 // get cuurent TTBR0_EL1
+ mov x3, #1 // reserved ASID
+ bfi x2, x3, #48, #16 // set the reserved ASID + old BADDR
+ msr ttbr0_el1, x2 // update TTBR0_EL1
+ isb
+ bfi x2, x0, #0, #48 // set the desired BADDR + reserved ASID
+ msr ttbr0_el1, x2 // update TTBR0_EL1
+ isb
+alternative_endif
+#endif
msr ttbr0_el1, x0 // set TTBR0
isb
alternative_if ARM64_WORKAROUND_CAVIUM_27456
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH v6 0/5] davinci: VPIF: add DT support
From: Javier Martinez Canillas @ 2016-12-07 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207183025.20684-1-khilman@baylibre.com>
Hello Kevin,
On Wed, Dec 7, 2016 at 3:30 PM, Kevin Hilman <khilman@baylibre.com> wrote:
> Prepare the groundwork for adding DT support for davinci VPIF drivers.
> This series does some fixups/cleanups and then adds the DT binding and
> DT compatible string matching for DT probing.
>
> The controversial part from previous versions around async subdev
> parsing, and specifically hard-coding the input/output routing of
> subdevs, has been left out of this series. That part can be done as a
> follow-on step after agreement has been reached on the path forward.
I had a similar need for another board (OMAP3 IGEPv2), that has a
TVP5151 video decoder (that also supports 2 composite or 1 s-video
signal) attached to the OMAP3 ISP.
I posted some RFC patches [0] to define the input signals in the DT,
and AFAICT Laurent and Hans were not against the approach but just had
some comments on the DT binding.
Basically they wanted the ports to be directly in the tvp5150 node
instead of under a connectors sub-node [1] and to just be called just
a (input / output) port instead of a connector [2].
Unfortunately I was busy with other tasks so I couldn't res-pin the
patches, but I think you could have something similar in the DT
binding for your case and it shouldn't be hard to parse the ports /
endpoints in the driver to get that information from DT and setup the
input and output pins.
> With this version, platforms can still use the VPIF capture/display
> drivers, but must provide platform_data for the subdevs and subdev
> routing.
>
I guess DT backward compatibility isn't a big issue on this platform,
since support for the platform is quite recently and after all someone
who wants to use the vpif with current DT will need platform data and
pdata-quirks anyways. So I agree with you that the input / output
signals lookup from DT could be done as a follow-up.
[0]: https://lkml.org/lkml/2016/4/12/983
[1]: https://lkml.org/lkml/2016/4/27/678
[2]: https://lkml.org/lkml/2016/11/11/346
Best regards,
Javier
^ permalink raw reply
* [PATCH] arm64: Work around Falkor erratum 1009
From: Christopher Covington @ 2016-12-07 20:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207200028.4420-1-cov@codeaurora.org>
From: Shanker Donthineni <shankerd@codeaurora.org>
During a TLB invalidate sequence targeting the inner shareable
domain, Falkor may prematurely complete the DSB before all loads
and stores using the old translation are observed; instruction
fetches are not subject to the conditions of this erratum.
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
arch/arm64/Kconfig | 10 +++++++++
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/include/asm/tlbflush.h | 43 +++++++++++++++++++++++++++++++++++++++
arch/arm64/kernel/cpu_errata.c | 7 +++++++
arch/arm64/kvm/hyp/tlb.c | 39 ++++++++++++++++++++++++++++++-----
5 files changed, 96 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1004a3d..125440f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -485,6 +485,16 @@ config QCOM_FALKOR_ERRATUM_E1003
If unsure, say Y.
+config QCOM_FALKOR_ERRATUM_E1009
+ bool "Falkor E1009: Prematurely complete a DSB after a TLBI"
+ default y
+ help
+ Falkor CPU may prematurely complete a DSB following a TLBI xxIS
+ invalidate maintenance operations. Repeat the TLBI operation one
+ more time to fix the issue.
+
+ If unsure, say Y.
+
endmenu
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index cb6a8c2..5357d7f 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -35,7 +35,8 @@
#define ARM64_HYP_OFFSET_LOW 14
#define ARM64_MISMATCHED_CACHE_LINE_SIZE 15
#define ARM64_WORKAROUND_QCOM_FALKOR_E1003 16
+#define ARM64_WORKAROUND_QCOM_FALKOR_E1009 17
-#define ARM64_NCAPS 17
+#define ARM64_NCAPS 18
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index deab523..03bafc5 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -23,6 +23,7 @@
#include <linux/sched.h>
#include <asm/cputype.h>
+#include <asm/alternative.h>
/*
* Raw TLBI operations.
@@ -94,6 +95,13 @@ static inline void flush_tlb_all(void)
dsb(ishst);
__tlbi(vmalle1is);
dsb(ish);
+ asm volatile(ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "tlbi vmalle1is \n"
+ "dsb ish \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ : :);
isb();
}
@@ -104,6 +112,13 @@ static inline void flush_tlb_mm(struct mm_struct *mm)
dsb(ishst);
__tlbi(aside1is, asid);
dsb(ish);
+ asm volatile(ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "tlbi aside1is, %0 \n"
+ "dsb ish \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ : : "r" (asid));
}
static inline void flush_tlb_page(struct vm_area_struct *vma,
@@ -114,6 +129,13 @@ static inline void flush_tlb_page(struct vm_area_struct *vma,
dsb(ishst);
__tlbi(vale1is, addr);
dsb(ish);
+ asm volatile(ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "tlbi vale1is, %0 \n"
+ "dsb ish \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ : : "r" (addr));
}
/*
@@ -145,6 +167,13 @@ static inline void __flush_tlb_range(struct vm_area_struct *vma,
__tlbi(vae1is, addr);
}
dsb(ish);
+ asm volatile(ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "tlbi vae1is, %0 \n"
+ "dsb ish \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ : : "r" (end));
}
static inline void flush_tlb_range(struct vm_area_struct *vma,
@@ -169,6 +198,13 @@ static inline void flush_tlb_kernel_range(unsigned long start, unsigned long end
for (addr = start; addr < end; addr += 1 << (PAGE_SHIFT - 12))
__tlbi(vaae1is, addr);
dsb(ish);
+ asm volatile(ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "tlbi vaae1is, %0 \n"
+ "dsb ish \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ : : "r" (end));
isb();
}
@@ -183,6 +219,13 @@ static inline void __flush_tlb_pgtable(struct mm_struct *mm,
__tlbi(vae1is, addr);
dsb(ish);
+ asm volatile(ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "tlbi vae1is, %0 \n"
+ "dsb ish \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ : : "r" (addr));
}
#endif
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 3789e2f..8013579 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -137,6 +137,13 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
MIDR_RANGE(MIDR_QCOM_FALKOR_V1, 0x00, 0x00),
},
#endif
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1009
+ {
+ .desc = "Qualcomm Falkor erratum E1009",
+ .capability = ARM64_WORKAROUND_QCOM_FALKOR_E1009,
+ MIDR_RANGE(MIDR_QCOM_FALKOR_V1, 0x00, 0x00),
+ },
+#endif
{
}
};
diff --git a/arch/arm64/kvm/hyp/tlb.c b/arch/arm64/kvm/hyp/tlb.c
index 88e2f2b..dfd3a77 100644
--- a/arch/arm64/kvm/hyp/tlb.c
+++ b/arch/arm64/kvm/hyp/tlb.c
@@ -16,6 +16,7 @@
*/
#include <asm/kvm_hyp.h>
+#include <asm/alternative.h>
void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
{
@@ -32,7 +33,14 @@ void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
* whole of Stage-1. Weep...
*/
ipa >>= 12;
- asm volatile("tlbi ipas2e1is, %0" : : "r" (ipa));
+ asm volatile("tlbi ipas2e1is, %0 \n"
+ ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "dsb ish \n"
+ "tlbi ipas2e1is, %0 \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ : : "r" (ipa));
/*
* We have to ensure completion of the invalidation at Stage-2,
@@ -41,7 +49,14 @@ void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
* the Stage-1 invalidation happened first.
*/
dsb(ish);
- asm volatile("tlbi vmalle1is" : : );
+ asm volatile("tlbi vmalle1is \n"
+ ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "dsb ish \n"
+ "tlbi vmalle1is \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ : : );
dsb(ish);
isb();
@@ -57,7 +72,14 @@ void __hyp_text __kvm_tlb_flush_vmid(struct kvm *kvm)
write_sysreg(kvm->arch.vttbr, vttbr_el2);
isb();
- asm volatile("tlbi vmalls12e1is" : : );
+ asm volatile("tlbi vmalls12e1is \n"
+ ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "dsb ish \n"
+ "tlbi vmalls12e1is \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ : : );
dsb(ish);
isb();
@@ -82,7 +104,14 @@ void __hyp_text __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu)
void __hyp_text __kvm_flush_vm_context(void)
{
dsb(ishst);
- asm volatile("tlbi alle1is \n"
- "ic ialluis ": : );
+ asm volatile("tlbi alle1is \n"
+ ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "dsb ish \n"
+ "tlbi alle1is \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ "ic ialluis \n"
+ : : );
dsb(ish);
}
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [Nouveau] 4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k
From: Ilia Mirkin @ 2016-12-07 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAVeFuKfo3sZL84wTiR6ur=PVsPhcaU62ggTwy9r1aQEOq2HZw@mail.gmail.com>
On Wed, Dec 7, 2016 at 4:57 AM, Alexandre Courbot <gnurou@gmail.com> wrote:
> On Wed, Dec 7, 2016 at 6:53 PM, Michel D?nzer <michel@daenzer.net> wrote:
>> On 07/12/16 06:39 PM, Alexandre Courbot wrote:
>>> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
>>>> That's right -- nouveau currently requires 4k page sizes to work. This is a
>>>> software limitation, not a hardware one though.
>>>
>>> Looking at the trace I wonder - is the limitation in Nouveau or in TTM?
>>
>> Nouveau. Non-4K page sizes work fine with radeon (and presumably amdgpu).
>
> Thanks for the precision. I will check if Tegra iGPUs are also
> affected by this - if they are then it gives me a good excuse to take
> care of this bug.
For the most part it's confusion in the (nouveau) code as to what's a
gpu page and what's a cpu page (and the shifts involved). There are
some fringe issues that will need to be addressed, like the fact that
it's no longer a 1:1 mapping, which might be assumed in some places.
However I thought that 64K-pages were frowned upon nowadays for the
kernel - outside of HPC loads, most of the kernel memory becomes
pagecache, and files don't tend to be 64K-sized, so you have tons of
wasted memory (since you never cache multiple files in the same page).
But don't take that as me disapproving of such a project. It'd esp be
nice to do something like this outside of the PPC64 environment, where
BE concerns mix in with the 64K page concerns, and nothing works as a
result.
-ilia
^ permalink raw reply
* Synopsys Ethernet QoS Driver
From: Andy Shevchenko @ 2016-12-07 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87c8a24b-0812-7850-cb3f-7be691bab432@st.com>
On Mon, Nov 21, 2016 at 2:52 PM, Giuseppe CAVALLARO
<peppe.cavallaro@st.com> wrote:
First of all, +1 to (re-)use stmmac.
> The stmmac drivers run since many years on several platforms
> (sh4, stm32, arm, x86, mips ...) and it supports an huge of amount of
> configurations starting from 3.1x to 3.7x databooks.
As Intel employee who did some clean ups to that, acknowledge above.
> Concerning the stmicro/stmmac naming, these come from a really old
> story and have no issue to adopt new folder/file names.
I don't think it would be best idea for platform driver (though we can
keep driver's name in the structure in async with file name).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v3 1/6] crypto: testmgr - avoid overlap in chunked tests
From: Eric Biggers @ 2016-12-07 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_HUjCparJnZXzZR=m3obt+aypibpHrP_ivA==1QNYksg@mail.gmail.com>
On Wed, Dec 07, 2016 at 07:53:51PM +0000, Ard Biesheuvel wrote:
> Does this help at all?
>
> diff --git a/crypto/testmgr.c b/crypto/testmgr.c
> index 670893bcf361..59e67f5b544b 100644
> --- a/crypto/testmgr.c
> +++ b/crypto/testmgr.c
> @@ -63,7 +63,7 @@ int alg_test(const char *driver, const char *alg,
> u32 type, u32 mask)
> */
> #define IDX1 32
> #define IDX2 32400
> -#define IDX3 511
> +#define IDX3 1511
> #define IDX4 8193
> #define IDX5 22222
> #define IDX6 17101
>
Yes, with that change made the self-tests pass.
Eric
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: zx: Fix gic GICR property
From: Olof Johansson @ 2016-12-07 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206011244.GC2749@dragon>
On Tue, Dec 06, 2016 at 09:12:46AM +0800, Shawn Guo wrote:
> Hi Olof,
>
> On Mon, Dec 05, 2016 at 04:55:02PM -0800, Olof Johansson wrote:
> > Hi Shawn,
> >
> > On Sun, Dec 4, 2016 at 6:24 PM, Shawn Guo <shawnguo@kernel.org> wrote:
> > > Hi Arnd,
> > >
> > > On Fri, Dec 02, 2016 at 09:28:58PM +0100, Arnd Bergmann wrote:
> > >> Given that there is any concern about the patch now, and the merge
> > >> window is almost open, I'm moving both patches to the
> > >> next/fixes-non-critical branch and will merge it for v4.10 instead
> > >> of sending it for v4.9.
> > >>
> > >> If you end up deciding that the patch is wrong, please follow up
> > >> with a fix on top. Once the situation is resolved and the patch
> > >> merged upstream, feel free to ask stable at vger.kernel.org for a
> > >> backport to stable kernels to get it into v4.9.x.
> > >
> > > The patch is correct, though it can be cleaned up a bit further per
> > > Marc's suggestion. Since we now have 4.9-rc8, I'm wondering if we can
> > > still get this into 4.9 to save the stable kernel backport.
> > >
> > > I sent you a cleanup patch on top of this one yesterday. If you like,
> > > I can quickly resend the patch with the cleanup squashed.
> >
> > Since the patches have already been applied, an incremental patch to
> > apply on top would work best here.
>
> No problem. So would you please apply the incremental patch [1] to the
> same branch? Or I can send it to you later during -rc cycles. Just let
> me know your preference.
>
> Shawn
>
> [1] https://www.spinics.net/lists/arm-kernel/msg546957.html
So, it seems that Arnd didn't apply the old patch to fixes-non-critical, or
at least didn't push out after doing it. So, I've done that now, as well as
applied the fixup you have above.
-Olof
^ permalink raw reply
* [GIT PULL 1/2] DaVinci DT updates for v4.10 (part 4)
From: Olof Johansson @ 2016-12-07 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205110316.18514-1-nsekhar@ti.com>
On Mon, Dec 05, 2016 at 04:33:15PM +0530, Sekhar Nori wrote:
> The following changes since commit 878e908ad95637dc6567a9b5f6876a580ae90dfa:
>
> ARM: dts: da850: enable memctrl and mstpri nodes per board (2016-11-28 15:51:29 +0530)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.10/dt-4
>
> for you to fetch changes up to e4ce904d6289f2a72affd2a0f0a44da6e5d0cce4:
>
> ARM: dts: da850: enable high speed for mmc (2016-12-05 14:20:44 +0530)
>
> ----------------------------------------------------------------
> - Add device tree nodes for pin pull-up/pull-down
> bias control on DA850.
>
> - Enable high speed support on DA850 MMC/SD
Merged, thanks. It's getting late but this is a small delta.
-Olof
^ permalink raw reply
* [GIT PULL 2/2] DaVinci defconfig updates for v4.10 (part 4)
From: Olof Johansson @ 2016-12-07 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205110316.18514-2-nsekhar@ti.com>
On Mon, Dec 05, 2016 at 04:33:16PM +0530, Sekhar Nori wrote:
> The following changes since commit 213971e7571e27f47b4e926904a9adf794925c51:
>
> ARM: davinci_all_defconfig: Enable OHCI as module (2016-11-22 20:50:46 +0530)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.10/defconfig-4
>
> for you to fetch changes up to 47d03e48efa572109229aec9436948d92f44b689:
>
> ARM: davinci_all_defconfig: Enable da8xx usb otg (2016-12-01 19:52:12 +0530)
>
> ----------------------------------------------------------------
> Enable support for MUSB based USB OTG on DA850.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: Xilinx Zynq SOC changes for v4.10
From: Olof Johansson @ 2016-12-07 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1ff060ae-b142-9e72-6fef-21b81a147614@monstr.eu>
On Tue, Dec 06, 2016 at 01:46:01PM +0100, Michal Simek wrote:
> Hi,
>
> please pull this fix to your tree.
>
> Thanks,
> Michal
>
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> https://github.com/Xilinx/linux-xlnx.git tags/zynq-soc-for-4.10
>
> for you to fetch changes up to 7a3cc2a7b2c723aa552028f4e66841cec183756d:
>
> ARM: zynq: Reserve correct amount of non-DMA RAM (2016-11-14 16:07:58
> +0100)
>
> ----------------------------------------------------------------
> arm: Xilinx Zynq patches for v4.10
>
> - Fix dma issue
>
> ----------------------------------------------------------------
> Kyle Roeschley (1):
> ARM: zynq: Reserve correct amount of non-DMA RAM
Merged, thanks. Should this have been a fix, btw? I queued it for 4.10 merge
window now.
-Olof
^ permalink raw reply
* [GIT PULL v2] ARM: Xilinx Zynq DT changes for v4.10
From: Olof Johansson @ 2016-12-07 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <78b672c5-2f17-f166-815f-47b05dba66e7@monstr.eu>
On Tue, Dec 06, 2016 at 01:51:45PM +0100, Michal Simek wrote:
> Hi,
>
> please add these changes to your arm-soc repo.
> It fixes dtc warnings, small coding style changes and add support for
> Microzed.
>
> Thanks,
> Michal
>
> ---
> v2: Use correct zynq-dt-for-4.10 tag instead of zynqmp-dt-for-4.10.
>
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> https://github.com/Xilinx/linux-xlnx.git tags/zynq-dt-for-4.10
>
> for you to fetch changes up to df2f3c48b9cd51e2612a1598342769d09d849f39:
>
> arm: dts: zynq: Add MicroZed board support (2016-12-06 13:17:39 +0100)
Merged. In the future it'd be nice to get these a few weeks earlier in the
cycle.
-Olof
^ permalink raw reply
* [PATCH 16/18] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
From: Arnd Bergmann @ 2016-12-07 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207165913.GD31779@e104818-lin.cambridge.arm.com>
On Wednesday, December 7, 2016 4:59:13 PM CET Catalin Marinas wrote:
> On Tue, Dec 06, 2016 at 11:55:08AM +0530, Yury Norov wrote:
> > On Mon, Dec 05, 2016 at 04:34:23PM +0000, Catalin Marinas wrote:
> > > On Fri, Oct 21, 2016 at 11:33:15PM +0300, Yury Norov wrote:
> > > > New aarch32 ptrace syscall handler is introduced to avoid run-time
> > > > detection of the task type.
> > >
> > > What's wrong with the run-time detection? If it's just to avoid a
> > > negligible overhead, I would rather keep the code simpler by avoiding
> > > duplicating the generic compat_sys_ptrace().
> >
> > Nothing wrong. This is how Arnd asked me to do. You already asked this
> > question: http://lkml.iu.edu/hypermail/linux/kernel/1604.3/00930.html
>
> Hmm, I completely forgot about this ;). There is still an advantage to
> doing run-time checking if we avoid touching core code (less acks to
> gather and less code duplication).
>
> Let's see what Arnd says but the initial patch looked simpler.
I don't currently have either version of the patch in my inbox
(the archive is on a different machine), but in general I'd still
think it's best to avoid the runtime check for aarch64-ilp32
altogether. I'd have to look at the overall kernel source to
see if it's worth avoiding one or two instances though, or
if there are an overwhelming number of other checks that we
can't avoid at all.
Regarding ptrace, I notice that arch/tile doesn't even use
the compat entry point for its ilp32 user space on 64-bit
kernels, it just calls the regular 64-bit one. Would that
help here?
Arnd
^ permalink raw reply
* [PATCH] dts: sun8i-h3: correct UART3 pin definitions
From: Olof Johansson @ 2016-12-07 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206142710.6450-1-jorik@kippendief.biz>
On Tue, Dec 06, 2016 at 03:27:10PM +0100, jorik at kippendief.biz wrote:
> From: Jorik Jonker <jorik@kippendief.biz>
>
> In a previous commit, I made a copy/paste error in the pinmux
> definitions of UART3: PG{13,14} instead of PA{13,14}. This commit takes
> care of that. I have tested this commit on Orange Pi PC and Orange Pi
> Plus, and it works for these boards.
>
> Fixes: e3d11d3c45c5 ("dts: sun8i-h3: add pinmux definitions for
> UART2-3")
>
> Signed-off-by: Jorik Jonker <jorik@kippendief.biz>
Applied to fixes. Thanks.
-Olof
^ permalink raw reply
* [PATCH] ARM: dts: imx7d: fix LCDIF clock assignment
From: Olof Johansson @ 2016-12-07 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205020123.GA2066@dragon>
On Mon, Dec 05, 2016 at 10:01:24AM +0800, Shawn Guo wrote:
> Hi Arnd, Olof,
>
> On Sun, Dec 04, 2016 at 05:26:58PM -0800, Stefan Agner wrote:
> > Hi Shawn
> >
> > On 2016-11-23 15:02, Fabio Estevam wrote:
> > > On Tue, Nov 22, 2016 at 10:42 PM, Stefan Agner <stefan@agner.ch> wrote:
> > >> The eLCDIF IP of the i.MX 7 SoC knows multiple clocks and lists them
> > >> separately:
> > >>
> > >> Clock Clock Root Description
> > >> apb_clk MAIN_AXI_CLK_ROOT AXI clock
> > >> pix_clk LCDIF_PIXEL_CLK_ROOT Pixel clock
> > >> ipg_clk_s MAIN_AXI_CLK_ROOT Peripheral access clock
> > >>
> > >> All of them are switched by a single gate, which is part of the
> > >> IMX7D_LCDIF_PIXEL_ROOT_CLK clock. Hence using that clock also for
> > >> the AXI bus clock (clock-name "axi") makes sure the gate gets
> > >> enabled when accessing registers.
> > >>
> > >> There seem to be no separate AXI display clock, and the clock is
> > >> optional. Hence remove the dummy clock.
> > >>
> > >> This fixes kernel freezes when starting the X-Server (which
> > >> disables/re-enables the display controller).
> > >>
> > >> Signed-off-by: Stefan Agner <stefan@agner.ch>
> > >
> > > Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
> >
> > Since this fixes a kernel freeze, is there a chance to get this still in
> > 4.9?
>
> Since we get one more week to the final 4.9, is it possible for you to
> send this fix for 4.9 inclusion? Thanks.
>
> For the patch,
>
> Acked-by: Shawn Guo <shawnguo@kernel.org>
Applied, with the fixes line. In the future, please email arm at kernel.org too,
it's easier to make sure we don't miss it that way.
-Olof
^ permalink raw reply
* [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2016-12-07 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207193908.GA13062@netboy>
On Wed, Dec 07, 2016 at 08:39:09PM +0100, Richard Cochran wrote:
> > +static s32 gem_ptp_max_adj(unsigned int f_nom)
> > +{
> > + u64 adj;
> > +
> > + /* The 48 bits of seconds for the GEM overflows every:
> > + * 2^48/(365.25 * 24 * 60 *60) =~ 8 925 512 years (~= 9 mil years),
> > + * thus the maximum adjust frequency must not overflow CNS register:
> > + *
> > + * addend = 10^9/nominal_freq
> > + * adj_max = +/- addend*ppb_max/10^9
> > + * max_ppb = (2^8-1)*nominal_freq-10^9
> > + */
> > + adj = f_nom;
> > + adj *= 0xffff;
> > + adj -= 1000000000ULL;
>
> What is this computation, and how does it relate to the comment?
I am not sure what you meant, but it sounds like you are on the wrong
track. Let me explain...
The max_adj has nothing at all to do with the width of the time
register. Rather, it should reflect the maximum possible change in
the tuning word.
For example, with a nominal 8 ns period, the tuning word is 0x80000.
Looking at running the clock more slowly, the slowest possible word is
0x00001, meaning a difference of 0x7FFFF. This implies an adjustment
of 0x7FFFF/0x80000 or 999998092 ppb. Running more quickly, we can
already have 0x100000, twice as fast, or just under 2 billion ppb.
You should consider the extreme cases to determine the most limited
(smallest) max_adj value:
Case 1 - high frequency
~~~~~~~~~~~~~~~~~~~~~~~
With a nominal 1 ns period, we have the nominal tuning word 0x10000.
The smallest is 0x1 for a difference of 0xFFFF. This corresponds to
an adjustment of 0xFFFF/0x10000 = .9999847412109375 or 999984741 ppb.
Case 2 - low frequency
~~~~~~~~~~~~~~~~~~~~~~
With a nominal 255 ns period, the nominal word is 0xFF0000, the
largest 0xFFFFFF, and the difference is 0xFFFF. This corresponds to
and adjustment of 0xFFFF/0xFF0000 = .0039215087890625 or 3921508 ppb.
Since 3921508 ppb is a huge adjustment, you can simply use that as a
safe maximum, ignoring the actual input clock.
Thanks,
Richard
^ 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