* [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
* [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 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
* [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
* [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 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
* [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 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 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 2/4] ARM: davinci_all_defconfig: enable video capture as modules
From: Kevin Hilman @ 2016-12-07 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207193137.27947-1-khilman@baylibre.com>
Enable media support and V4L2 capture, along with video decoders used
on da850 platforms.
Tested on da850-lcdk.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/configs/davinci_all_defconfig | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index 5e5dd6bc5ed9..fd05bc35fb36 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -123,6 +123,12 @@ CONFIG_TPS6507X=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_TPS6507X=y
+CONFIG_MEDIA_SUPPORT=m
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_VIDEO_DAVINCI_VPIF_CAPTURE=m
+# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
+CONFIG_VIDEO_TVP514X=m
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DA8XX=y
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/4] ARM: dts: davinci: da850: VPIF: add node and muxing
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 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>;
+ };
+ };
+ };
};
+
aemif: aemif at 68000000 {
compatible = "ti,da850-aemif";
#address-cells = <2>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 0/4] ARM: davinci: da850: add/enable video capture
From: Kevin Hilman @ 2016-12-07 19:31 UTC (permalink / raw)
To: linux-arm-kernel
Add support for VPIF video capture using DT (partially.)
The main VPIF device, and its pin muxing are using DT, but legacy
platform_data is still required for the 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)
Dependencies:
- VPIF driver changes:
[PATCH v6 0/5] davinci: VPIF: add DT support
https://marc.info/?l=linux-arm-kernel&m=148113556200610
Kevin Hilman (4):
ARM: dts: davinci: da850: VPIF: add node and muxing
ARM: davinci_all_defconfig: enable video capture as modules
ARM: davinci: da8xx: add pdata-quirks, use for VPIF capture
ARM: davinci: board-da850-evm: add I2C ID for VPIF
arch/arm/boot/dts/da850-evm.dts | 6 ++
arch/arm/boot/dts/da850-lcdk.dts | 6 ++
arch/arm/boot/dts/da850.dtsi | 38 ++++++-
arch/arm/configs/davinci_all_defconfig | 6 ++
arch/arm/mach-davinci/Makefile | 2 +-
arch/arm/mach-davinci/board-da850-evm.c | 1 +
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 ++++++++++++++++++++++++++++
9 files changed, 218 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-davinci/pdata-quirks.c
--
2.9.3
^ permalink raw reply
* [PATCH v2] ARM: dts: lpc32xx: add pwm-cells to base dts file
From: Sylvain Lemieux @ 2016-12-07 19:30 UTC (permalink / raw)
To: linux-arm-kernel
From: Sylvain Lemieux <slemieux@tycoint.com>
There is no need to define the "pwm-cells" in the board
specific dts file; move the entry to the base dts file.
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
---
Changes in v2:
* Update the "pwm-cells" to be compatible with the latest
lpc32xx-pwm driver implementation.
Note:
* This patch have a dependency on the following patcheset:
"pwm: lpc32xx: switch driver to one phandle argument for PWM consumers"
http://www.spinics.net/lists/arm-kernel/msg547013.html
arch/arm/boot/dts/lpc32xx.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index 218d9fa..c031c94 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -472,6 +472,7 @@
assigned-clocks = <&clk LPC32XX_CLK_PWM1>;
assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
status = "disabled";
+ #pwm-cells = <1>;
};
pwm2: pwm at 4005C004 {
@@ -481,6 +482,7 @@
assigned-clocks = <&clk LPC32XX_CLK_PWM2>;
assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
status = "disabled";
+ #pwm-cells = <1>;
};
timer3: timer at 40060000 {
--
1.8.3.1
^ permalink raw reply related
* [PATCH V2 4/5] ARM: BCM5301X: Specify all RAM by including an extra block
From: Jon Mason @ 2016-12-07 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207075655.7396-4-zajec5@gmail.com>
On Wed, Dec 07, 2016 at 08:56:54AM +0100, Rafa? Mi?ecki wrote:
> From: Rafa? Mi?ecki <rafal@milecki.pl>
>
> The first 128 MiB of RAM can be accessed using an alias at address 0x0.
>
> In theory we could access whole RAM using 0x80000000 - 0xbfffffff range
> (up to 1 GiB) but it doesn't seem to work on Northstar. For some reason
> (hardware setup left by the bootloader maybe?) 0x80000000 - 0x87ffffff
> range can't be used. I reproduced this problem on:
> 1) Buffalo WZR-600DHP2 (BCM47081)
> 2) Netgear R6250 (BCM4708)
> 3) D-Link DIR-885L (BCM47094)
>
> So it seems we're forced to access first 128 MiB using alias at 0x0 and
> the rest using real base address + 128 MiB offset which is 0x88000000.
>
> Signed-off-by: Rafa? Mi?ecki <rafal@milecki.pl>
Acked-by: Jon Mason <jon.mason@broadcom.com>
> ---
> V2: Updated commit message, thanks Jon!
> Included XWR-3100
> ---
> arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-netgear-r6250.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts | 3 ++-
> arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts | 3 ++-
> arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 3 ++-
> arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts | 3 ++-
> arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts | 3 ++-
> arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts | 3 ++-
> arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 3 ++-
> arch/arm/boot/dts/bcm4709-netgear-r8000.dts | 3 ++-
> arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 3 ++-
> arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts | 3 ++-
> arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 3 ++-
> 16 files changed, 32 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> index 112a5a8..d241cee 100644
> --- a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> +++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> index 3600f56..b0e6204 100644
> --- a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> +++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> index d49afec0..c9ba6b9 100644
> --- a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> +++ b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x18000000>;
> };
>
> spi {
> diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> index 8519548..b9f66c0 100644
> --- a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> +++ b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts b/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
> index 6229ef2..ae0199f 100644
> --- a/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
> +++ b/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> index 74cfcd3..36b628b1 100644
> --- a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> +++ b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts b/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
> index 71b98cf..db8608b 100644
> --- a/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
> +++ b/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> index 2922536..d51586d 100644
> --- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> +++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> spi {
> diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
> index 184fd92..de041b8 100644
> --- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
> +++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> gpio-keys {
> diff --git a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
> index eac0f52..eaca687 100644
> --- a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
> +++ b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
> index aab39c9..b32957c 100644
> --- a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
> +++ b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x18000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> index 7ab1176..f459a98 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> index 56d38a3..cd13534 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> index 7fb9270..64ded76 100644
> --- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> +++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> nand: nand at 18028000 {
> diff --git a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
> index 93cc91d..5cf4ab1 100644
> --- a/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
> +++ b/arch/arm/boot/dts/bcm47094-luxul-xwr-3100.dts
> @@ -18,7 +18,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> index 7ecd57c..600795e 100644
> --- a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> +++ b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> @@ -18,7 +18,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x18000000>;
> };
>
> leds {
> --
> 2.10.1
>
^ permalink raw reply
* mmc: core: complete/wait_for_completion performance
From: Stefan Wahren @ 2016-12-07 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481095953.17027.0.camel@embedded.rocks>
Hi J?rg,
> J?rg Krause <joerg.krause@embedded.rocks> hat am 7. Dezember 2016 um 08:32
> geschrieben:
>
>
> Hit Stefan,
>
> On Sat, 2016-11-26 at 20:10 +0100, Stefan Wahren wrote:
> > Hi J?rg,
> >
> > > J?rg Krause <joerg.krause@embedded.rocks> hat am 20. November 2016
> > > um 20:10
> > > geschrieben:
> > >
> > >
> > > On Sun, 2016-11-20 at 16:44 +0100, Stefan Wahren wrote:
> > > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 20. November
> > > > > 2016
> > > > > um 15:42
> > > > > geschrieben:
> > > > >
> > > > >
> > > > > Hi Stefan,
> > > > >
> > > > > On Sun, 2016-11-20 at 14:28 +0100, Stefan Wahren wrote:
> > > > > > Hi J?rg,
> > > > > >
> > > > > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 20.
> > > > > > > November
> > > > > > > 2016
> > > > > > > um 13:27
> > > > > > > geschrieben:
> > > > > > >
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I started the discussion on this mailing list in another
> > > > > > > thread
> > > > > > > [1],
> > > > > > > but I'd like to move it to a new thread, because it might
> > > > > > > be
> > > > > > > mmc
> > > > > > > specific.
> > > > > > >
> > > > > > > The issue is that I am noticed low wifi network throughput
> > > > > > > on
> > > > > > > an
> > > > > > > i.MX28
> > > > > > > board with the mainline kernel (v4.7.10, about 6 Mbps)
> > > > > > > compared
> > > > > > > to
> > > > > > > the
> > > > > > > vendor kernel (Freescale v2.6.35.3, about 20 Mbps). The
> > > > > > > wifi
> > > > > > > chip
> > > > > > > is
> > > > > > > attached using the SDIO interface.
> > > > > > >
> > > > > > > I started investigation where the bottleneck in the
> > > > > > > mainline
> > > > > > > kernel?might come from. Therefore I checked that the
> > > > > > > configs
> > > > > > > and
> > > > > > > settings for the interfaces and drivers are the same. They
> > > > > > > are.
> > > > > >
> > > > > > so you're not using the mxs_defconfig settings anymore?
> > > > >
> > > > > No, I changed the settings.
> > > > >
> > > >
> > > > What happens to performance to if you change the following
> > > > settings
> > > > to the same
> > > > like in mxs_defconfig?
> > > >
> > > > CONFIG_PREEMPT_VOLUNTARY=y
> > > > CONFIG_DEFAULT_IOSCHED="noop"
> > >
> > > No much change at all. The time difference between complete() and
> > > wait_for_complete() decreases in best case to 110 us, but also
> > > varies
> > > to above 130 us.
> >
> > just a weird idea. Did you tried to add MMC_CAP_CMD23 into the caps
> > [1]?
> >
> > [1] - http://lxr.free-electrons.com/source/drivers/mmc/host/mxs-mmc.c
> > ?v=4.8#L642
>
> I tried, but it did not improved the timing or throughput. However,
> many thanks for the input.
>
> J?rg
did you try cyclictest [1]?
Beside the time for a request the amount of requests for the complete iperf test
would we interesting. Maybe there are retries.
I'm still interested in your PIO mode patches for mxs-mmc even without clean up.
[1] - https://git.kernel.org/cgit/utils/rt-tests/rt-tests.git/
^ permalink raw reply
* [PATCH v3 1/6] crypto: testmgr - avoid overlap in chunked tests
From: Eric Biggers @ 2016-12-07 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480963348-24203-2-git-send-email-ard.biesheuvel@linaro.org>
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? 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
* [RESEND PATCH v2 4/7] drm/vc4: Add support for the VEC (Video Encoder) IP
From: Eric Anholt @ 2016-12-07 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207161205.485a3046@bbrezillon>
Boris Brezillon <boris.brezillon@free-electrons.com> writes:
> On Mon, 5 Dec 2016 17:50:13 -0800
> Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>> On 12/02/2016 05:48 AM, Boris Brezillon wrote:
>> > The VEC IP is a TV DAC, providing support for PAL and NTSC standards.
>> >
>> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>> > ---
>>
>> > diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
>> > new file mode 100644
>> > index 000000000000..2d4256fcc6f2
>> > --- /dev/null
>> > +++ b/drivers/gpu/drm/vc4/vc4_vec.c
>> > @@ -0,0 +1,657 @@
>> > +/*
>> > + * Copyright (C) 2016 Broadcom Limited
>>
>> The standard copyright template post acquisition is just Broadcom, not
>> Broadcom Limited, nor Broadcom corporation. Can you audit your entire
>> submission and fix this up accordingly?
>
> This is the only patch adding a copyright header.
> Eric, can you fix that when applying the series or should I resend a
> new version?
I'll fix it when applying, that's fine. (I had in v1 and forgot to tell
you!)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161207/ac9e00a2/attachment.sig>
^ permalink raw reply
* [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check
From: Eric Anholt @ 2016-12-07 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206172911.z6sbjzgqv3vfcrfh@lukather>
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").
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161207/d2a9b314/attachment.sig>
^ permalink raw reply
* [PATCH 6/9] dt-bindings: Document rk3399 Gru/Kevin
From: Heiko Stuebner @ 2016-12-07 19:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207174139.GA87970@google.com>
Am Mittwoch, 7. Dezember 2016, 09:41:39 CET schrieb Brian Norris:
> On Wed, Dec 07, 2016 at 06:12:13PM +0100, Heiko Stuebner wrote:
> > Hi Brian,
> >
> > Am Donnerstag, 1. Dezember 2016, 18:27:30 CET schrieb Brian Norris:
> > > Gru is a base dev board for a family of devices, including Kevin. Both
> > > utilize Rockchip RK3399, and they share much of their design.
> > >
> > > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > > ---
> > >
> > > Documentation/devicetree/bindings/arm/rockchip.txt | 20
> > >
> > > ++++++++++++++++++++ 1 file changed, 20 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
> > > b/Documentation/devicetree/bindings/arm/rockchip.txt index
> > > cc4ace6397ab..830e13f5890c 100644
> > > --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> > > +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> > > @@ -99,6 +99,26 @@ Rockchip platforms device tree bindings
> > >
> > > "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
> > > "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
> > >
> > > +- Google Gru (dev-board):
> > boards sorted alphabetically please
> >
> > Brian, Gru, Jaq, ... Kevin, ...
> >
> > While the sorting of old boards is not right yet, new boards should be
> > sorted.
> I got the idea that there was some attempt to group logically before
> alphabetically. Like keeping board/SoC families together. But maybe not.
>
> I can do as you suggested, if you don't care about keeping actual
> similar boards together (i.e., veyron/3288 vs gru/3399).
I'd prefer a simple alphabetical sorting.
I think people reading the document will know what device they have, but not
necessarily the actual soc in it. At least I would look for Google Kevin
primarily without thinking of the soc at first.
And in general, most Rockchip boards (maybe except Google-boards) tend to
follow the reference design quite closely, so it may become hard to decide
when one is similar to another :-) . So best to keep it simple.
^ permalink raw reply
* [PATCH 4/9] arm64: dts: rockchip: support dwc3 USB for rk3399
From: Heiko Stuebner @ 2016-12-07 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207190301.GA107036@google.com>
Am Mittwoch, 7. Dezember 2016, 11:03:02 CET schrieb Brian Norris:
> On Wed, Dec 07, 2016 at 08:01:23PM +0100, Heiko Stuebner wrote:
> > Am Mittwoch, 7. Dezember 2016, 09:52:08 CET schrieb Brian Norris:
> > > But pcie at f8000000 is also out of order then. I guess maybe
> > > that's the only one then.
> >
> > Yep, pcie is misplaced as sadly sometimes I miss those errors as well.
>
> OK. Do you want me to patch that at the end of my series, or is that
> unnecessary churn?
I'm still pondering [and am investing way to much brain cells in trying to
decide this ;-) ], but tend to want to move it.
That way the dtsi gives the correct sorting impression for future dt-patches
of which I guess we'll see a lot in the time to come.
So yes, please move it as well.
Thanks
Heiko
^ permalink raw reply
* [PATCH 3/8] rtc: add STM32 RTC driver
From: Alexandre Belloni @ 2016-12-07 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480687801-19525-5-git-send-email-amelie.delaunay@st.com>
Hi,
It seems mostly fine.
On 02/12/2016 at 15:09:56 +0100, Amelie Delaunay wrote :
> This patch adds support for the STM32 RTC.
>
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> ---
> drivers/rtc/Kconfig | 10 +
> drivers/rtc/Makefile | 1 +
> drivers/rtc/rtc-stm32.c | 777 ++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 788 insertions(+)
> create mode 100644 drivers/rtc/rtc-stm32.c
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index e859d14..dd8b218 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -1706,6 +1706,16 @@ config RTC_DRV_PIC32
> This driver can also be built as a module. If so, the module
> will be called rtc-pic32
>
> +config RTC_DRV_STM32
> + tristate "STM32 On-Chip RTC"
> + depends on ARCH_STM32
Can you add COMPILE_TEST? Looking at it, nothing seemed to be
architecture specific and this nicely increases compile test coverage.
It should also probably select REGMAP_MMIO.
> diff --git a/drivers/rtc/rtc-stm32.c b/drivers/rtc/rtc-stm32.c
> new file mode 100644
> index 0000000..9e710ff
> --- /dev/null
> +++ b/drivers/rtc/rtc-stm32.c
> @@ -0,0 +1,777 @@
> +/*
> + * Copyright (C) Amelie Delaunay 2015
> + * Author: Amelie Delaunay <adelaunay.stm32@gmail.com>
This differs from your SoB. I don't really care but it seems odd.
> + * License terms: GNU General Public License (GPL), version 2
> + */
> +
> +#include <linux/bcd.h>
> +#include <linux/clk.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/ioport.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/rtc.h>
> +#include <linux/spinlock.h>
> +
I have the feeling that some of those headers are not necessary maybe
some cleanup should be done.
> +static struct regmap *dbp;
> +
> +struct stm32_rtc {
> + struct rtc_device *rtc_dev;
> + void __iomem *base;
> + struct clk *pclk;
> + struct clk *ck_rtc;
> + unsigned int clksrc;
> + spinlock_t lock; /* Protects registers accesses */
That comment makes checkpatch happy but is not super useful :) Anyway...
> +static irqreturn_t stm32_rtc_alarm_irq(int irq, void *dev_id)
> +{
...can you make that one a threaded IRQ? If that's the case, just take
the rtc_device mutex here and remove the spinlock. All the other
function are already protected.
> +static int stm32_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
> +{
> + struct stm32_rtc *rtc = dev_get_drvdata(dev);
> + struct rtc_time *tm = &alrm->time;
> + unsigned int alrmar, cr, isr;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(&rtc->lock, irqflags);
> +
> + alrmar = stm32_rtc_readl(rtc, STM32_RTC_ALRMAR);
> + cr = stm32_rtc_readl(rtc, STM32_RTC_CR);
> + isr = stm32_rtc_readl(rtc, STM32_RTC_ISR);
> +
> + spin_unlock_irqrestore(&rtc->lock, irqflags);
> +
> + if (alrmar & STM32_RTC_ALRMXR_DATE_MASK) {
> + /*
> + * Date/day don't care in Alarm comparison so alarm triggers
I guess you meant "doesn't matter" (that is also valid for the other
usages of "don't care".
> + * every day
> + */
> + tm->tm_mday = -1;
> + tm->tm_wday = -1;
> + } else {
> + if (alrmar & STM32_RTC_ALRMXR_WDSEL) {
> + /* Alarm is set to a day of week */
> + tm->tm_mday = -1;
> + tm->tm_wday = (alrmar & STM32_RTC_ALRMXR_WDAY) >>
> + STM32_RTC_ALRMXR_WDAY_SHIFT;
> + tm->tm_wday %= 7;
> + } else {
> + /* Alarm is set to a day of month */
> + tm->tm_wday = -1;
> + tm->tm_mday = (alrmar & STM32_RTC_ALRMXR_DATE) >>
> + STM32_RTC_ALRMXR_DATE_SHIFT;
> + }
> + }
> +
> + if (alrmar & STM32_RTC_ALRMXR_HOUR_MASK) {
> + /* Hours don't care in Alarm comparison */
> + tm->tm_hour = -1;
> + } else {
> + tm->tm_hour = (alrmar & STM32_RTC_ALRMXR_HOUR) >>
> + STM32_RTC_ALRMXR_HOUR_SHIFT;
> + if (alrmar & STM32_RTC_ALRMXR_PM)
> + tm->tm_hour += 12;
> + }
> +
> + if (alrmar & STM32_RTC_ALRMXR_MIN_MASK) {
> + /* Minutes don't care in Alarm comparison */
> + tm->tm_min = -1;
> + } else {
> + tm->tm_min = (alrmar & STM32_RTC_ALRMXR_MIN) >>
> + STM32_RTC_ALRMXR_MIN_SHIFT;
> + }
> +
> + if (alrmar & STM32_RTC_ALRMXR_SEC_MASK) {
> + /* Seconds don't care in Alarm comparison */
> + tm->tm_sec = -1;
> + } else {
> + tm->tm_sec = (alrmar & STM32_RTC_ALRMXR_SEC) >>
> + STM32_RTC_ALRMXR_SEC_SHIFT;
> + }
> +
I'm not sure those multiple cases (including STM32_RTC_ALRMXR_WDSEL) are
useful because the core will always give you valid tm_sec, tm_min,
tm_hour and tm_mday (it is actually checked up to four times!) so you
should always end up in the same configuration.
If you think some code other than Linux may set an alarm (e.g. the
bootloader) then you may keep them in read_alarm but at least you can
remove them from set_alarm.
> +static int stm32_rtc_probe(struct platform_device *pdev)
> +{
> + struct stm32_rtc *rtc;
> + struct resource *res;
> + int ret;
> +
> + rtc = devm_kzalloc(&pdev->dev, sizeof(*rtc), GFP_KERNEL);
> + if (!rtc)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + rtc->base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(rtc->base))
> + return PTR_ERR(rtc->base);
> +
> + dbp = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "st,syscfg");
> + if (IS_ERR(dbp)) {
> + dev_err(&pdev->dev, "no st,syscfg\n");
> + return PTR_ERR(dbp);
> + }
> +
> + spin_lock_init(&rtc->lock);
> +
> + rtc->ck_rtc = devm_clk_get(&pdev->dev, "ck_rtc");
> + if (IS_ERR(rtc->ck_rtc)) {
> + dev_err(&pdev->dev, "no ck_rtc clock");
> + return PTR_ERR(rtc->ck_rtc);
> + }
> +
> + ret = clk_prepare_enable(rtc->ck_rtc);
> + if (ret)
> + return ret;
> +
> + if (dbp)
> + regmap_update_bits(dbp, PWR_CR, PWR_CR_DBP, PWR_CR_DBP);
> +
> + ret = stm32_rtc_init(pdev, rtc);
> + if (ret)
> + goto err;
> +
Isn't that RTC backuped in some way, do you really need to reinit it
each time the system reboots?
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 4/9] arm64: dts: rockchip: support dwc3 USB for rk3399
From: Brian Norris @ 2016-12-07 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1972184.o3UeJg0tK9@phil>
On Wed, Dec 07, 2016 at 08:01:23PM +0100, Heiko Stuebner wrote:
> Am Mittwoch, 7. Dezember 2016, 09:52:08 CET schrieb Brian Norris:
> > But pcie at f8000000 is also out of order then. I guess maybe
> > that's the only one then.
>
> Yep, pcie is misplaced as sadly sometimes I miss those errors as well.
OK. Do you want me to patch that at the end of my series, or is that
unnecessary churn?
Brian
^ permalink raw reply
* [PATCH 4/9] arm64: dts: rockchip: support dwc3 USB for rk3399
From: Heiko Stuebner @ 2016-12-07 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207175208.GB87970@google.com>
Am Mittwoch, 7. Dezember 2016, 09:52:08 CET schrieb Brian Norris:
> Hi,
>
> On Wed, Dec 07, 2016 at 06:09:16PM +0100, Heiko Stuebner wrote:
> > Am Donnerstag, 1. Dezember 2016, 18:27:28 CET schrieb Brian Norris:
> > > Add the dwc3 usb needed node information for rk3399.
> > >
> > > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > > ---
> > > Somewhat rewritten from Caesar's reposting (v2) of my patch.
> > >
> > > Changes:
> > > * Include USB2 PHY (which is now in -next)
> > > * Don't include USB3 PHY, as extcon support is not ready yet
> > > * Drop non-upstream properties
> > > * Fixup whitespace a bit
> > >
> > > ---
> > >
> > > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 60
> > >
> > > ++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > > b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index
> > > 4ca8f9a7601c..1e97fb8c6415
> > > 100644
> > > --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > > +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > > @@ -316,6 +316,66 @@
> > >
> > > };
> > >
> > > };
> > >
> > > + usbdrd3_0: usb at fe800000 {
> >
> > insert location above usb at fe380000 is sorted wrong
>
> So, *how* do you think things are sorted here? Alphabetical by label? Or
> by node name? Or by unit address? I guess I'm seeing you meant unit
> address.
correct. Per unit-address first, nodes without address alphabetical by node-
name (above nodes with addresses), never by label.
> But pcie at f8000000 is also out of order then. I guess maybe
> that's the only one then.
Yep, pcie is misplaced as sadly sometimes I miss those errors as well.
Heiko
> > > + compatible = "rockchip,rk3399-dwc3";
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + ranges;
> > > + clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
> > > + <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
> > > + <&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
> > > + clock-names = "clk_usb3otg0_ref", "clk_usb3otg0_suspend",
> > > + "aclk_usb3otg0", "aclk_usb3_rksoc_axi_perf",
> > > + "aclk_usb3", "aclk_usb3_grf";
> >
> > clock-names do not match binding. The dwc3-of-simple does not care, as it
> > just enables all of them it seems, but binding doc states the clock names
> > as>
> > - clock-names: Should contain the following:
> > "ref_clk" Controller reference clk, have to be 24 MHz
> > "suspend_clk" Controller suspend clk, have to be 24 MHz or 32 KHz
> > "bus_clk" Master/Core clock, have to be >= 62.5 MHz for SS
> >
> > operation and >= 30MHz for HS operation
> >
> > "grf_clk" Controller grf clk
>
> Ah, sorry. I'll try to go with the rockchip,dwc3.txt names better.
>
> There are a few extra clocks here now, but I think those might only be
> for USB3 support, which isn't really working yet. I'll either document
> them or drop them.
>
> > > + resets = <&cru SRST_A_USB3_OTG0>;
> > > + reset-names = "usb3-otg";
> >
> > you could update the binding documentation to list this one.
>
> Similar story; this is only used for some of the hacky stuff Rockchip is
> doing for USB3/TypeC stuff out of tree. I'll either document it or drop
> it (as I'm not actually using it yet).
>
> Thanks,
> Brian
>
> > Heiko
> >
> > > + status = "disabled";
> > > +
> > > + usbdrd_dwc3_0: dwc3 {
> > > + compatible = "snps,dwc3";
> > > + reg = <0x0 0xfe800000 0x0 0x100000>;
> > > + interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
> > > + dr_mode = "otg";
> > > + phys = <&u2phy0_otg>;
> > > + phy-names = "usb2-phy";
> > > + snps,dis_enblslpm_quirk;
> > > + snps,dis-u2-freeclk-exists-quirk;
> > > + snps,dis_u2_susphy_quirk;
> > > + snps,dis-del-phy-power-chg-quirk;
> > > + status = "disabled";
> > > + };
> > > + };
>
> [...]
^ permalink raw reply
* [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: Shanker Donthineni @ 2016-12-07 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1899e46c-7b06-01d6-6cff-eb0985a4f11d@redhat.com>
Hi Eric,
Is there any reason why you are not supporting SMMUv3 driver? Qualcomm
hardware doesn't not support SMMUv2 hardware, please add support for
SMMUv3 in next patch set. I've ported ' RFC,v3,09/10] iommu/arm-smmu:
Implement reserved region get/put callbacks' to SMMUv3 driver and tested
device-pass-through feature on Qualcomm server platform without any issue.
Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
--
Shanker Donthineni
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
* [PATCH] Input: lpc32xx-keys - fix invalid error handling of a requested irq
From: Sylvain Lemieux @ 2016-12-07 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7AAD38C5-E1CF-40EF-8E5B-8BCB9B5897C4@gmail.com>
On Wed, 2016-12-07 at 10:46 -0800, Dmitry Torokhov wrote:
> On December 7, 2016 10:13:07 AM PST, Sylvain Lemieux <slemieux.tyco@gmail.com> wrote:
> >On Mon, 2016-12-05 at 03:47 +0200, Vladimir Zapolskiy wrote:
> >> Semantics of NR_IRQS is different on machines with SPARSE_IRQ option
> >> disabled or enabled, in the latter case IRQs are allocated starting
> >> at least from the value specified by NR_IRQS and going upwards, so
> >> the check of (irq >= NR_IRQ) to decide about an error code returned
> >by
> >> platform_get_irq() is completely invalid, don't attempt to overrule
> >> irq subsystem in the driver.
> >>
> >> The change fixes lpc32xx_keys driver initialization on boot:
> >>
> >> lpc32xx_keys 40050000.key: failed to get platform irq
> >> lpc32xx_keys: probe of 40050000.key failed with error -22
> >>
> >> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> >> ---
> >> drivers/input/keyboard/lpc32xx-keys.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >Cosmetic - please update the subject line when doing the commit:
> >replace " -" by ":" after lpc32xx-keys
>
> Why? The format on all input patches is "Input: <driver> - <subject>" and had been this for 10+ years.
>
My mistake; did not look at the tree "subject line" commit log
You can dropped my comment.
Regards,
Sylvain
>
> Thanks.
>
^ 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