* [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
From: Lorenzo Pieralisi @ 2016-10-17 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f9dfa5a4-f42a-265f-ab84-7599f2de37ed@arm.com>
On Mon, Oct 17, 2016 at 03:19:46PM +0100, Robin Murphy wrote:
> Hi Lorenzo,
>
> On 17/10/16 14:21, Lorenzo Pieralisi wrote:
> > On Mon, Oct 17, 2016 at 12:06:20PM +0100, Robin Murphy wrote:
> >> We now delay installing our per-bus iommu_ops until we know an SMMU has
> >> successfully probed, as they don't serve much purpose beforehand, and
> >> doing so also avoids fights between multiple IOMMU drivers in a single
> >> kernel. However, the upshot of passing the return value of bus_set_iommu()
> >> back from our probe function is that if there happens to be more than
> >> one SMMUv3 device in a system, the second and subsequent probes will
> >> wind up returning -EBUSY to the driver core and getting torn down again.
> >>
> >> There are essentially 3 cases in which bus_set_iommu() returns nonzero:
> >> 1. The bus already has iommu_ops installed
> >> 2. One of the add_device callbacks from the initial notifier failed
> >> 3. Allocating or installing the notifier itself failed
> >>
> >> The first two are down to devices other than the SMMU in question, so
> >> shouldn't abort an otherwise-successful SMMU probe, whilst the third is
> >> indicative of the kind of catastrophic system failure which isn't going
> >> to get much further anyway. Consequently, there is little harm in
> >> ignoring the return value either way.
> >>
> >> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >> ---
> >> drivers/iommu/arm-smmu-v3.c | 11 ++++-------
> >> 1 file changed, 4 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> >> index 15c01c3cd540..74fbef384deb 100644
> >> --- a/drivers/iommu/arm-smmu-v3.c
> >> +++ b/drivers/iommu/arm-smmu-v3.c
> >> @@ -2637,16 +2637,13 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> >> of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> >> #ifdef CONFIG_PCI
> >> pci_request_acs();
> >> - ret = bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
> >> - if (ret)
> >> - return ret;
> >> + bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
> >> #endif
> >> #ifdef CONFIG_ARM_AMBA
> >> - ret = bus_set_iommu(&amba_bustype, &arm_smmu_ops);
> >> - if (ret)
> >> - return ret;
> >> + bus_set_iommu(&amba_bustype, &arm_smmu_ops);
> >> #endif
> >> - return bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
> >> + bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
> >> + return 0;
> >
> > Nit: I do not see why you would not take the same approach as
> > the ARM SMMUv1/v2, namely checking if ops are already set and
> > skip the call if that's the case.
>
> Well, I'd say it really goes the other way around - since the very first
> thing bus_set_iommu() does is check if ops are present, and return if
> so, and the v2 driver already doesn't care about that return value,
> there's not really any need for it to duplicate the check either. I
> didn't change it at the time to avoid cluttering the gigantic rework any
> further, but I could spin a cleanup patch if you like.
No worries, it was to understand if there was a reason to keep
the code different and after another look I agree with what
you are saying (by checking if ops are present you could eg
avoid calling pci_request_acs() every probe but that's a detail).
Thanks for fixing it !
Lorenzo
> > Anyway:
> >
> > Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>
> Thanks!
>
> Robin.
>
^ permalink raw reply
* [PATCH v8 1/2] ARM: dts: Add TOPEET itop core board SCP package version
From: ayaka @ 2016-10-17 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017162759.GA25818@kozik-lap>
On 10/18/2016 12:27 AM, Krzysztof Kozlowski wrote:
> On Mon, Sep 19, 2016 at 11:48:22PM +0800, Randy Li wrote:
>> The TOPEET itop is a samsung exnynos 4412 core board, which have
>> two package versions. This patch add the support for SCP version.
>>
>> Currently supported are USB3503A HSIC, USB OTG, eMMC, rtc and
>> PMIC. The future features are in the based board. Also MFC and
>> watchdog have been enabled.
>>
>> Signed-off-by: Randy Li <ayaka@soulik.info>
>> ---
>> arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 501 ++++++++++++++++++++++++
>> 1 file changed, 501 insertions(+)
>> create mode 100644 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
> I wanted to apply it... but then I saw a bunch of checkpatch trivial issues.
> Really, after v8? The code must compile (v6 did not compile...), there
> should be no warnings from smatch, sparse and checkpatch (only the last
> one is applicable for DTS). Unless of course checkpatch would be
> wrong... but in this case it is correct. You did not follow coding
> style:
>
> WARNING: please, no spaces at the start of a line
> #134: FILE: arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi:109:
> + devfreq = <&bus_leftbus>;$
>
> ERROR: code indent should use tabs where possible
> #135: FILE: arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi:110:
> + status = "okay";$
Oh, it is a copy mistake, the copy operation makes the original tab
becomes spaces.
Should I send a new version to correct them?
>
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Regression: usb serial gadget on sama5d3 broken
From: Peter Rosin @ 2016-10-17 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <38ca0db7-9bc6-7258-b102-ea9fdeb9b03c@atmel.com>
On 2016-10-17 16:54, Nicolas Ferre wrote:
> Le 17/10/2016 ? 14:53, Peter Rosin a ?crit :
>> Hi!
>>
>> I'm suffering from a regression while using the usb gadget port on the
>> sama5d3 to get terminal access to the device in question (CONFIG_USB_G_SERIAL).
>>
>> I get this message when I try to connect:
>> udc: ep: Invalid setup request: 02.01 v0000 i0081 l0, halting endpoint...
>>
>> A bisect blames commit v4.7-rc1-21-gc32b5bcfa3c4 "ARM: dts: at91: Fix
>> USB endpoint nodes".
>>
>> And indeed, reverting that commit on top of v4.9-rc1 fixes things,
>> although that doesn't look like the best of fixes...
>>
>> BTW, the bisect was extremely painful since v4.7-rc1 seemed broken
>> somewhere in the overlayfs area. I hope I will never ever need to bisect
>> in the v4.6..v4.7 area again. This was the second time, the first time
>> I was chasing a gpio interrupt bug, but I never found out what was wrong
>> and stopped looking when v4.9-rc1 turned out to be ok even though v4.8
>> was bad, it was just too painful to look for things that already seemed
>> fixed.
>
> I guess that you are referring to the regression listed here:
> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1239220.html
>
> The patch is available and will hopefully land in an official kernel
> soon (4.8.1) as said by Felipe and Greg.
>
> Sorry for the inconvenience. Best regards,
Ok, I tried "usb: gadget: udc: atmel: fix endpoint name" and it fixes
things for me too. But shouldn't the memory for the now dynamic name be
allocated with devm_kasprintf instead of that plain kasprint? If you
are pedantic...
Cheers,
Peter
^ permalink raw reply
* [PATCH 1/2] i2c: bcm-iproc: constify i2c_adapter_quirks structures
From: Ray Jui @ 2016-10-17 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476552722-12352-2-git-send-email-Julia.Lawall@lip6.fr>
Hi Julia,
On 10/15/2016 10:32 AM, Julia Lawall wrote:
> Check for i2c_adapter_quirks structures that are only stored in the
> quirks field of an i2c_adapter structure. This field is declared
> const, so i2c_adapter_quirks structures that have this property can be
> declared as const also.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct i2c_adapter_quirks i at p = { ... };
>
> @ok@
> identifier r.i;
> struct i2c_adapter e;
> position p;
> @@
> e.quirks = &i at p;
>
> @bad@
> position p != {r.p,ok.p};
> identifier r.i;
> struct i2c_adapter_quirks e;
> @@
> e at i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> static
> +const
> struct i2c_adapter_quirks i = { ... };
> // </smpl>
>
> The effect on the layout of the .o file is shown by the following
> output of the size command, first before then after the
> transformation:
>
> text data bss dec hex filename
> 3458 744 8 4210 1072 drivers/i2c/busses/i2c-bcm-iproc.o
> 3490 720 8 4218 107a drivers/i2c/busses/i2c-bcm-iproc.o
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> ---
> drivers/i2c/busses/i2c-bcm-iproc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c
> index 326b3db..318df55 100644
> --- a/drivers/i2c/busses/i2c-bcm-iproc.c
> +++ b/drivers/i2c/busses/i2c-bcm-iproc.c
> @@ -395,7 +395,7 @@ static uint32_t bcm_iproc_i2c_functionality(struct i2c_adapter *adap)
> .functionality = bcm_iproc_i2c_functionality,
> };
>
> -static struct i2c_adapter_quirks bcm_iproc_i2c_quirks = {
> +static const struct i2c_adapter_quirks bcm_iproc_i2c_quirks = {
> /* need to reserve one byte in the FIFO for the slave address */
> .max_read_len = M_TX_RX_FIFO_SIZE - 1,
> };
>
Change looks good. Thanks.
Acked-by: Ray Jui <ray.jui@broadcom.com>
^ permalink raw reply
* [PATCH 1/2] ARM: vexpress: refine MCPM smp operations override criteria
From: Sudeep Holla @ 2016-10-17 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923140303.GA26672@red-moon>
On 23/09/16 15:03, Lorenzo Pieralisi wrote:
> On Fri, Sep 23, 2016 at 02:09:06PM +0100, Lorenzo Pieralisi wrote:
>> Current vexpress smp init code detects whether to override the
>> default smp ops with MCPM smp ops by matching the "cci-400"
>> compatible string, in that MCPM requires control over CCI ports
>> to manage low-power states entry/exit.
>>
>> The "cci-400" compatible string check is a necessary but not
>> sufficient condition for MCPM to work, because the cci-400
>> can be made visible to the kernel, but firmware can nonetheless
>> disable non-secure CCI ports control, while still allowing PMU
>> access; if booted in non-secure world, the kernel would still
>> blindly override smp operations with MCPM operations, resulting
>> in kernel faults when the CCI ports programming interface is
>> accessed from non-secure world.
>>
>> This means that the "cci-400" compatible string check would
>> result in a false positive in systems that eg boot in HYP mode,
>> where CCI ports non-secure access is explicitly not allowed,
>> and it is reported in the respective device tree nodes with
>> CCI ports marked as disabled.
>>
>> Refactor the smp operations initialization to make sure that
>> the kernel is actually allowed to take control over CCI ports
>> (by enabling MCPM smp operations) before overriding default
>> vexpress smp operations.
>>
>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Cc: Liviu Dudau <liviu.dudau@arm.com>
>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>> arch/arm/mach-vexpress/platsmp.c | 31 ++++++++++++++++++++++++-------
>> 1 file changed, 24 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
>> index 8b8d072..6cfd782 100644
>> --- a/arch/arm/mach-vexpress/platsmp.c
>> +++ b/arch/arm/mach-vexpress/platsmp.c
>> @@ -26,17 +26,34 @@
>> bool __init vexpress_smp_init_ops(void)
>> {
>> #ifdef CONFIG_MCPM
>> + int cpu;
>> + struct device_node *cpu_node, *cci_node;
>> +
>> /*
>> - * The best way to detect a multi-cluster configuration at the moment
>> - * is to look for the presence of a CCI in the system.
>> + * The best way to detect a multi-cluster configuration
>> + * is to detect if the kernel can take over CCI ports
>> + * control. Loop over possible CPUs and check if CCI
>> + * port control is available.
>> * Override the default vexpress_smp_ops if so.
>> */
>> - struct device_node *node;
>> - node = of_find_compatible_node(NULL, NULL, "arm,cci-400");
>> - if (node && of_device_is_available(node)) {
>> - mcpm_smp_set_ops();
>> - return true;
>> + for_each_possible_cpu(cpu) {
>> + bool available;
>> +
>> + cpu_node = of_get_cpu_node(cpu, NULL);
>> + if (WARN(!cpu_node, "Missing cpu device node!"))
>> + return false;
>> +
>> + cci_node = of_parse_phandle(cpu_node, "cci-control-port", 0);
>> + available = cci_node && of_device_is_available(cci_node);
>> + of_node_put(cci_node);
>> + of_node_put(cpu_node);
>> +
>> + if (!available)
>> + return false;
>> }
>> +
>> + mcpm_smp_set_ops();
>> + return true;
>> #endif
>> return false;
>
> For the records, while moving the code around I missed I was ending
> up with this idiotic double return, I have already reworked the patch
> and will squash changes in the final version if we agree on the bulk of
> the code.
>
I applied both patches to [1] with the fix for the above issue. Let me
know if that's fine. I have tested both hyp mode boot and SVC mode +
MCPM boot with latest u-boot by just fliping a bit in the firmware
(board.txt) without recompiling the kernel.
--
Regards,
Sudeep
[1] git.kernel.org/sudeep.holla/linux/h/vexpress/for-next
^ permalink raw reply
* [PATCH V3 RFT 3/5] ARM64: dts: bcm283x: Use dtsi for USB host mode
From: Eric Anholt @ 2016-10-17 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1471792204-21908-4-git-send-email-stefan.wahren@i2se.com>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> In case dr_mode isn't passed via DT, the dwc2 driver defaults
> to OTG mode. But the Raspberry Pi 3 is designed only for host mode.
> So fix this issue by linking to the dtsi file which set the dr_mode
> to host.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Applied Gerd's Tested-by and merged to bcm2835-dt-64-next.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161017/1eb7a5d5/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: sysreg: Fix use of XZR in write_sysreg_s
From: Will Deacon @ 2016-10-17 17:20 UTC (permalink / raw)
To: linux-arm-kernel
Commit 8a71f0c656e0 ("arm64: sysreg: replace open-coded mrs_s/msr_s with
{read,write}_sysreg_s") introduced a write_sysreg_s macro for writing
to system registers that are not supported by binutils.
Unfortunately, this was implemented with the wrong template (%0 vs %x0),
so in the case that we are writing a constant 0, we will generate
invalid instruction syntax and bail with a cryptic assembler error:
| Error: constant expression required
This patch fixes the template.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/sysreg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index e8d46e8e6079..6c80b3699cb8 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -286,7 +286,7 @@ asm(
#define write_sysreg_s(v, r) do { \
u64 __val = (u64)v; \
- asm volatile("msr_s " __stringify(r) ", %0" : : "rZ" (__val)); \
+ asm volatile("msr_s " __stringify(r) ", %x0" : : "rZ" (__val)); \
} while (0)
static inline void config_sctlr_el1(u32 clear, u32 set)
--
2.1.4
^ permalink raw reply related
* [PATCH v4 2/7] ARM: dts: bcm283x: Define standard pinctrl groups in the gpio node.
From: Eric Anholt @ 2016-10-17 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474274603-24215-3-git-send-email-kraxel@redhat.com>
Gerd Hoffmann <kraxel@redhat.com> writes:
> From: Eric Anholt <eric@anholt.net>
>
> The BCM2835-ARM-Peripherals.pdf documentation specifies what the
> function selects do for the pins, and there are a bunch of obvious
> groupings to be made. With these created, we'll be able to replace
> bcm2835-rpi.dtsi's main "set all of these pins to alt0" with
> references to specific groups we want enabled.
>
> Also add pinctrl groups for emmc and sdhost.
>
> Based on patches by Eric Anholt <eric@anholt.net>
I amended this line to "Based on patches by Eric Anholt, with fixups by
Gerd Hoffmann." to explain why it had me as author but you in signoff.
I had to resolve some conflicts on the way in because apparently you had
built this against a tree with 14 and 15 already dropped from alt0. I
think those resolutions were sufficiently mechanical that it didn't
merit a respin.
Merged the series to bcm2835-dt-next. Thanks for getting this done!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161017/8fe3d040/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] ARM: bus: da8xx-syscfg: new driver
From: Kevin Hilman @ 2016-10-17 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476721850-454-3-git-send-email-bgolaszewski@baylibre.com>
Bartosz Golaszewski <bgolaszewski@baylibre.com> writes:
> Create the driver for the da8xx System Configuration and implement
> support for writing to the three Master Priority registers.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
[...]
> +#define DA8XX_IO_PHYS 0x01c00000ul
> +#define DA8XX_SYSCFG0_BASE (DA8XX_IO_PHYS + 0x14000)
The base addr should come from DT.
Kevin
^ permalink raw reply
* [PATCH 1/3] ARM: memory: da8xx-ddrctl: new driver
From: Kevin Hilman @ 2016-10-17 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476721850-454-2-git-send-email-bgolaszewski@baylibre.com>
Bartosz Golaszewski <bgolaszewski@baylibre.com> writes:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
[...]
> diff --git a/drivers/memory/da8xx-ddrctl.c b/drivers/memory/da8xx-ddrctl.c
> new file mode 100644
> index 0000000..dcd0a61
> --- /dev/null
> +++ b/drivers/memory/da8xx-ddrctl.c
> @@ -0,0 +1,77 @@
> +/*
> + * TI da8xx DDR2/mDDR controller driver
> + *
> + * Copyright (C) 2016 BayLibre SAS
> + *
> + * Author:
> + * Bartosz Golaszewski <bgolaszewski@baylibre.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/io.h>
> +
> +#define DA8XX_DDR_CTL_BASE 0xB0000000
This base addr should be the reg property of the node.
> +#define DA8XX_PBBPR_OFFSET 0x00000020
> +#define DA8XX_PBBPR_REG(p) ((p) + DA8XX_PBBPR_OFFSET)
Kevin
^ permalink raw reply
* [PATCH] ARM: dts: mps2: remove skeleton.dtsi include and fix unit address warnings
From: Sudeep Holla @ 2016-10-17 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476704849-24039-1-git-send-email-vladimir.murzin@arm.com>
On 17/10/16 12:47, Vladimir Murzin wrote:
> Removale of skeleton.dtsi allows us also to fix the following
> warning from the dts compiler:
> Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
>
> by adding proper unit addresses to the memory nodes.
>
> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
It's always better to cc device-tree list, anyways applied this to [1].
--
Regards,
Sudeep
[1] git.kernel.org/sudeep.holla/linux/h/vexpress-dt/for-next
^ permalink raw reply
* master build: 2 failures 4 warnings (v4.8-11811-g35ff96d)
From: Thomas Gleixner @ 2016-10-17 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161014103344.GB3304@dell>
On Fri, 14 Oct 2016, Lee Jones wrote:
> On Tue, 11 Oct 2016, Mark Brown wrote:
>
> > On Tue, Oct 11, 2016 at 07:30:35AM +0100, Build bot for Mark Brown wrote:
> >
> > Linus' tree is currently failing to build arm and arm64 allmodconfigs
> > with:
> >
> > > arm64-allmodconfig
> > > ERROR: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
> >
> > > arm-allmodconfig
> > > ERROR: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
> >
> > due to 6556bdacf646fc (mfd: tps65217: Add support for IRQs) since
> > irq_set_parent() isn't exported. This has been present in -next
> > for getting on for a month, a patch was proposed adding the relevant
> > export but that isn't present in -next yet.
> >
> > The function is being used in order to enable lazy IRQ disabling for
> > threaded interrupts:
> >
> > https://www.spinics.net/lists/arm-kernel/msg532864.html
> >
> > What's the plan for getting this fixed in Linus' tree?
>
> Here's the conversation:
>
> https://www.spinics.net/lists/arm-kernel/msg531850.html
>
> I'm waiting on a firm answer from Arnd and Thomas before applying
> anything.
As I said, we can export it, if it's needed to make the driver modular. But
we definitely don't want to export it just to make the build happy.
Grigoryi has an excellent answer here:
https://www.spinics.net/lists/arm-kernel/msg532864.html
Only the driver authors/maintainers can decide whether this is the case or
not.
Thanks,
tglx
^ permalink raw reply
* 4.7.6->4.8.1 Possible regression
From: Alexander Shiyan @ 2016-10-17 16:47 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
After a kernel update from 4.7.6 to 4.8.1, the bug appear once kernel run "init".
...
VFS: Mounted root (squashfs filesystem) readonly on device 31:3.
devtmpfs: mounted
Freeing unused kernel memory: 144K (c04da000 - c04fe000)
This architecture does not have kernel memory protection.
Please press Enter to activate this console.
starting pid 448, tty '': '-/bin/ash'
Unable to handle kernel NULL pointer dereference at virtual address 00000008
pgd = c3b58000
[00000008] *pgd=800000000, *pte=00000000, *ppte=feff4140
Internal error: Oops: 63c11817 [#1] PREEMPT ARM
CPU: 0 PID: 448 Comm: ash Not tainted 4.8.1+ #1
Hardware name: Cirrus Logic CLPS711X (Device Tree Support)
task: c39e03a0 ti: c3b4e000 task.ti: c3b4e000
PC is at __dabt_svc+0x4c/0x60
LR is at do_page_fault+0x144/0x2ac
pc : [<c000d3ac>] lr : [<c000fcec>] psr: 60000093
sp : c3b4fe6c ip : 00000001 fp : b6f1bf88
r10: c387a5a0 r9 : 00000000 r8 : e4e0e001
r7 : bee3ef83 r6 : 00100000 r5 : 80000013 r4 : c022fcf8
r3 : 00000000 r2 : 00000008 r1 : bf000000 r0 : 00000000
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0000217f Table: c3b58055 DAC: 00000055
Process ash (pid: 448, stack limit = 0xc3b4e190)
Stack: (0xc3b4fe6c to 0xc3b50000)
fe60: bee3ef83 c05168d1 ffffffff 00000000 c3adfe80
fe80: c3a03300 00000000 c3b4fed0 c3a03400 bee3ef83 c387a5a0 b6f1bf88 00000001
fea0: c3b4febc 00000076 c022fcf8 80000013 ffffffff 0000003f bf000000 bee3ef83
fec0: 00000004 00000000 c3adfe80 c00e432c 00000812 00000005 00000001 00000006
fee0: b6f1b000 00000000 00010000 0003c944 0004d000 0004d439 00010000 b6f1b000
ff00: 00000005 00000000 00015ecc c3b4fed0 0000000a 00000000 00000000 c00a1dc0
ff20: befff000 c3a03300 c3b4e000 c0507cd8 c0508024 fffffff8 c3a03300 00000000
ff40: c0516a58 c00a35bc c39e03a0 000001c0 bea84ce8 0004e008 c3b3a000 c00a3ac0
ff60: c3b40374 c3b3a000 bea84d11 00000000 c0500188 bea84d11 bea84ce8 00000001
ff80: 0000000b c000a304 c3b4e000 00000000 bea84ce4 c00a3cd0 00000000 bea84d11
ffa0: bea84ce8 c000a160 bea84d11 bea84ce8 bea84d11 bea84ce8 0004e008 0004d450
ffc0: bea84d11 bea84ce8 00000001 0000000b b6f45ee4 00000000 b6f5ff70 bea84ce4
ffe0: b6f2f130 bea84cb0 b6f2f194 b6ef29f4 a0000010 bea84d11 02c7cffa 02c7cffd
[<c000d3ac>] (__dabt_svc) from [<c022fcf8>] (__copy_to_user_std+0xf8/0x330)
[<c022fcf8>] (__copy_to_user_std) from [<c00e432c>] (load_elf_binary+0x920/0x107c)
[<c00e432c>] (load_elf_binary) from [<c00a35bc>] (search_binary_handler+0x80/0x16c)
[<c00a35bc>] (search_binary_handler) from [<c00a3ac0>] (do_execveat_common+0x418/0x600)
[<c00a3ac0>] (do_execveat_common) from [<c00a3cd0>] (do_execve+0x28/0x30)
[<c00a3cd0>] (do_execve) from [<c000a160>] (ret_fast_syscall+0x0/0x30)
Code: e1a0200d eb00136b e321f093 e59d104c (e5891008)
---[ end trace 4b4f8086ebef98c5 ]---
process '-/bin/ash' (pid 448) exited. Scheduling for restart.
Git-bisect found a bad commit: "ARM: save and reset the address limit when entering an exception"
Reverting this commit on top of 4.8.1 solve this problem.
Can anyone have similar problems? Any ideas?
Thanks.
---
^ permalink raw reply
* [PATCH 1/3] arm64/dts: Add SMMUs to Juno
From: Sudeep Holla @ 2016-10-17 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <acf4f770eab43fec8c5b6e9cddb6dd0defc52138.1476706244.git.robin.murphy@arm.com>
On 17/10/16 13:13, Robin Murphy wrote:
> Juno has seperate MMU-401 instances in front of the DMA-330, both HDLCD
> controllers, the USB host controller, the PCIe root complex, and the
> CoreSight ETR. Since there is still work to do to make all the relevant
> subsystems interact nicely with the presence of an IOMMU, add the nodes
> to aid develompent and testing but leave them disabled by default to
> avoid nasty surprises.
>
> CC: Liviu Dudau <liviu.dudau@arm.com>
> CC: Sudeep Holla <sudeep.holla@arm.com>
Applied to [1] with $subject reformatted and typos fixed
--
Regards,
Sudeep
[1] git.kernel.org/sudeep.holla/linux/h/juno-dt/for-next
^ permalink raw reply
* [PATCH v7 REPOST 0/9] CPUs capacity information for heterogeneous systems
From: Juri Lelli @ 2016-10-17 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <66c7bbfd-ec3f-ff43-9a06-ae644d9ee9d9@arm.com>
Hi Sudeep,
On 17/10/16 17:39, Sudeep Holla wrote:
>
>
> On 17/10/16 16:46, Juri Lelli wrote:
> >Hi all,
> >
> >this is a repost of version 7 of "CPUs capacity information for heterogeneous
> >systems" patchset [1] (please refer to previous postings to get some context).
> >I only added Juno r1 dts, as discussed off-line with Sudeep meanwhile (no code
> >changes at all, so that's why I'm saying this is a repost).
> >
> >I'm reposting as I didn't receive any comment (despite pinging people) on the
> >original v7 posting (apart from Vincent acking patches 2 and 4, thanks!). I
> >then waited until merge window for 4.9 was closed.
> >
> >I'm thus now assuming that everybody is OK with the patches and that they can
> >be queued for 4.10 (we certainly need this plumbing at this point). Please
> >speak if my assumption is wrong (and provide feedback! :).
> >Otherwise I'm going to:
> >
> > - use Russell's patching system for patches 2 and 8
> > - ask Sudeep to pull patches 3,5,6 and 7
>
> I have applied 3 to [1] and 5,6,7 to [2]. Let me know if things change
> and you want me to drop them with some cosmetic subject change and
> updated changelog.
>
Thanks!
Best,
- Juri
> --
> Regards,
> Sudeep
>
> [1] git.kernel.org/sudeep.holla/linux/h/vexpress-dt/for-next
> [2] git.kernel.org/sudeep.holla/linux/h/juno-dt/for-next
>
^ permalink raw reply
* [PATCH 2/2] ARM: multi_v7_defconfig: Enable exynos-gsc driver as module
From: Krzysztof Kozlowski @ 2016-10-17 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475677469-1524-2-git-send-email-javier@osg.samsung.com>
On Wed, Oct 05, 2016 at 11:24:29AM -0300, Javier Martinez Canillas wrote:
> Exynos5 SoCs have a General SCALER (GSCALER) IP block that can be used
> to do video streams scaling and color space conversions by hardware.
> Enable support for its driver as a module so the GSCALER can be tested.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> ---
>
> arch/arm/configs/multi_v7_defconfig | 1 +
> 1 file changed, 1 insertion(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/2] ARM: exynos_defconfig: Enable exynos-gsc driver as module
From: Krzysztof Kozlowski @ 2016-10-17 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475677469-1524-1-git-send-email-javier@osg.samsung.com>
On Wed, Oct 05, 2016 at 11:24:28AM -0300, Javier Martinez Canillas wrote:
> Exynos5 SoCs have a General SCALER (GSCALER) IP block that can be used
> to do video streams scaling and color space conversions by hardware.
> Enable support for its driver as a module so the GSCALER can be tested.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
>
> arch/arm/configs/exynos_defconfig | 1 +
> 1 file changed, 1 insertion(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 3/5] [media] rc: meson-ir: Fix module autoload
From: Kevin Hilman @ 2016-10-17 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476719053-17600-4-git-send-email-javier@osg.samsung.com>
On Mon, Oct 17, 2016 at 8:44 AM, Javier Martinez Canillas
<javier@osg.samsung.com> wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
>
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>
> Before this patch:
>
> $ modinfo drivers/media/rc/meson-ir.ko | grep alias
> $
>
> After this patch:
>
> $ modinfo drivers/media/rc/meson-ir.ko | grep alias
> alias: of:N*T*Camlogic,meson-gxbb-irC*
> alias: of:N*T*Camlogic,meson-gxbb-ir
> alias: of:N*T*Camlogic,meson8b-irC*
> alias: of:N*T*Camlogic,meson8b-ir
> alias: of:N*T*Camlogic,meson6-irC*
> alias: of:N*T*Camlogic,meson6-ir
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* [PATCH v7 REPOST 0/9] CPUs capacity information for heterogeneous systems
From: Sudeep Holla @ 2016-10-17 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017154650.18779-1-juri.lelli@arm.com>
On 17/10/16 16:46, Juri Lelli wrote:
> Hi all,
>
> this is a repost of version 7 of "CPUs capacity information for heterogeneous
> systems" patchset [1] (please refer to previous postings to get some context).
> I only added Juno r1 dts, as discussed off-line with Sudeep meanwhile (no code
> changes at all, so that's why I'm saying this is a repost).
>
> I'm reposting as I didn't receive any comment (despite pinging people) on the
> original v7 posting (apart from Vincent acking patches 2 and 4, thanks!). I
> then waited until merge window for 4.9 was closed.
>
> I'm thus now assuming that everybody is OK with the patches and that they can
> be queued for 4.10 (we certainly need this plumbing at this point). Please
> speak if my assumption is wrong (and provide feedback! :).
> Otherwise I'm going to:
>
> - use Russell's patching system for patches 2 and 8
> - ask Sudeep to pull patches 3,5,6 and 7
I have applied 3 to [1] and 5,6,7 to [2]. Let me know if things change
and you want me to drop them with some cosmetic subject change and
updated changelog.
--
Regards,
Sudeep
[1] git.kernel.org/sudeep.holla/linux/h/vexpress-dt/for-next
[2] git.kernel.org/sudeep.holla/linux/h/juno-dt/for-next
^ permalink raw reply
* [PATCH] ARM: dts: novena: Enable PWM1
From: Marek Vasut @ 2016-10-17 16:34 UTC (permalink / raw)
To: linux-arm-kernel
Enable PWM1, otherwise the backlight cannot work.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
---
arch/arm/boot/dts/imx6q-novena.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-novena.dts b/arch/arm/boot/dts/imx6q-novena.dts
index 1723e89e..758bca9 100644
--- a/arch/arm/boot/dts/imx6q-novena.dts
+++ b/arch/arm/boot/dts/imx6q-novena.dts
@@ -451,6 +451,10 @@
status = "okay";
};
+&pwm1 {
+ status = "okay";
+};
+
&sata {
target-supply = <®_sata>;
fsl,transmit-level-mV = <1025>;
--
2.9.3
^ permalink raw reply related
* [PATCH] ARM: imx_v6_v7_defconfig: Select the es8328 codec driver
From: Marek Vasut @ 2016-10-17 16:34 UTC (permalink / raw)
To: linux-arm-kernel
Select CONFIG_SND_SOC_ES8328 so that we can have audio functional
by default on Kosagi Novena boards.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
---
arch/arm/configs/imx_v6_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 8e66e22..cbe7faf 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -257,6 +257,7 @@ CONFIG_SND_IMX_SOC=y
CONFIG_SND_SOC_PHYCORE_AC97=y
CONFIG_SND_SOC_EUKREA_TLV320=y
CONFIG_SND_SOC_IMX_WM8962=y
+CONFIG_SND_SOC_IMX_ES8328=y
CONFIG_SND_SOC_IMX_SGTL5000=y
CONFIG_SND_SOC_IMX_SPDIF=y
CONFIG_SND_SOC_IMX_MC13783=y
--
2.9.3
^ permalink raw reply related
* [PATCH] ARM: imx_v6_v7_defconfig: Increase CMA size
From: Marek Vasut @ 2016-10-17 16:34 UTC (permalink / raw)
To: linux-arm-kernel
Increase the CMA size to 64 MiB, otherwise it isn't possible to use
etnaviv driver on systems with 1920x1080 panel due to insufficient
memory .
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
---
arch/arm/configs/imx_v6_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 8ec4dbb..8e66e22 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -86,6 +86,7 @@ CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_STANDALONE is not set
CONFIG_DMA_CMA=y
+CONFIG_CMA_SIZE_MBYTES=64
CONFIG_IMX_WEIM=y
CONFIG_CONNECTOR=y
CONFIG_MTD=y
--
2.9.3
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: da850: add the syscfg and ddrctl nodes
From: Bartosz Golaszewski @ 2016-10-17 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476721850-454-1-git-send-email-bgolaszewski@baylibre.com>
Add the nodes for the System Configuration and DDR2/mDDR memory
controller drivers to da850.dtsi.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 6440002..6d56ef2 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -407,6 +407,16 @@
interrupts = <52>;
status = "disabled";
};
+
+ ddrctl: da850-ddrctl {
+ compatible = "ti,da850-ddrctl";
+ status = "disabled";
+ };
+
+ syscfg: da850-syscfg {
+ compatible = "ti,da850-syscfg";
+ status = "disabled";
+ };
};
aemif: aemif at 68000000 {
compatible = "ti,da850-aemif";
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] ARM: bus: da8xx-syscfg: new driver
From: Bartosz Golaszewski @ 2016-10-17 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476721850-454-1-git-send-email-bgolaszewski@baylibre.com>
Create the driver for the da8xx System Configuration and implement
support for writing to the three Master Priority registers.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
.../devicetree/bindings/bus/ti,da850-syscfg.txt | 63 +++++++
drivers/bus/Kconfig | 8 +
drivers/bus/Makefile | 2 +
drivers/bus/da8xx-syscfg.c | 206 +++++++++++++++++++++
4 files changed, 279 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-syscfg.txt
create mode 100644 drivers/bus/da8xx-syscfg.c
diff --git a/Documentation/devicetree/bindings/bus/ti,da850-syscfg.txt b/Documentation/devicetree/bindings/bus/ti,da850-syscfg.txt
new file mode 100644
index 0000000..07e5c38
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ti,da850-syscfg.txt
@@ -0,0 +1,63 @@
+* Device tree bindings for Texas Instruments da8xx system configuration driver
+
+The system configuration (SYSCFG) module is a system-level module containing
+status and top level control logic required by the device. The system
+configuration module consists of a set of memory-mapped status and control
+registers, accessible by the CPU, supporting all of the following system
+features, and miscellaneous functions and operations.
+
+Documentation:
+OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
+
+Required properties:
+
+- compatible: "ti,da850-syscfg"
+
+Optional properties:
+
+The below properties are used to specify the priority of master peripherals.
+They must be between 0-7 where 0 is the highest priority and 7 is the lowest.
+
+- ti,pri-arm-i: ARM_I port priority.
+
+- ti,pri-arm-d: ARM_D port priority.
+
+- ti,pri-upp: uPP port priority.
+
+- ti,pri-sata: SATA port priority.
+
+- ti,pri-pru0: PRU0 port priority.
+
+- ti,pri-pru1: PRU1 port priority.
+
+- ti,pri-edma30tc0: EDMA3_0_TC0 port priority.
+
+- ti,pri-edma30tc1: EDMA3_0_TC1 port priority.
+
+- ti,pri-edma31tc0: EDMA3_1_TC0 port priority.
+
+- ti,pri-vpif-dma-0: VPIF DMA0 port priority.
+
+- ti,pri-vpif-dma-1: VPIF DMA1 port priority.
+
+- ti,pri-emac: EMAC port priority.
+
+- ti,pri-usb0cfg: USB0 CFG port priority.
+
+- ti,pri-usb0cdma: USB0 CDMA port priority.
+
+- ti,pri-uhpi: HPI port priority.
+
+- ti,pri-usb1: USB1 port priority.
+
+- ti,pri-lcdc: LCDC port priority.
+
+If any of the above properties is absent, the default value will be used as
+defined in the documentation.
+
+Example for da850-lcdk is shown below.
+
+mstpri {
+ compatible = "ti,da850-mstpri";
+ ti,pri-lcdc = 0;
+};
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 5a2d47c..6276132 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -165,4 +165,12 @@ config VEXPRESS_CONFIG
help
Platform configuration infrastructure for the ARM Ltd.
Versatile Express.
+
+config DA8XX_SYSCFG
+ bool "TI da8xx system configuration driver"
+ depends on ARCH_DAVINCI_DA8XX
+ help
+ Driver for Texas Instruments da8xx system configuration. Allows to
+ adjust various SoC configuration options.
+
endmenu
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index c6cfa6b..3cba66a 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -21,3 +21,5 @@ obj-$(CONFIG_SIMPLE_PM_BUS) += simple-pm-bus.o
obj-$(CONFIG_TEGRA_ACONNECT) += tegra-aconnect.o
obj-$(CONFIG_UNIPHIER_SYSTEM_BUS) += uniphier-system-bus.o
obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o
+
+obj-$(CONFIG_DA8XX_SYSCFG) += da8xx-syscfg.o
diff --git a/drivers/bus/da8xx-syscfg.c b/drivers/bus/da8xx-syscfg.c
new file mode 100644
index 0000000..8a2cb4f
--- /dev/null
+++ b/drivers/bus/da8xx-syscfg.c
@@ -0,0 +1,206 @@
+/*
+ * TI da8xx System Configuration driver
+ *
+ * Copyright (C) 2016 BayLibre SAS
+ *
+ * Author:
+ * Bartosz Golaszewski <bgolaszewski@baylibre.com.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+
+#define DA8XX_IO_PHYS 0x01c00000ul
+#define DA8XX_SYSCFG0_BASE (DA8XX_IO_PHYS + 0x14000)
+
+#define DA8XX_MSTPRI0_REG 0x110
+#define DA8XX_MSTPRI1_REG 0x114
+#define DA8XX_MSTPRI2_REG 0x118
+
+#define DA8XX_MSTPRI_MAX 7
+
+struct da8xx_mstpri_descr {
+ const char *property;
+ int reg;
+ int shift;
+ int mask;
+};
+
+static const struct da8xx_mstpri_descr priorities[] = {
+ {
+ .property = "ti,pri-arm-i",
+ .reg = DA8XX_MSTPRI0_REG,
+ .shift = 0,
+ .mask = 0xfffffff0,
+ },
+ {
+ .property = "ti,pri-arm-d",
+ .reg = DA8XX_MSTPRI0_REG,
+ .shift = 4,
+ .mask = 0xffffff0f,
+ },
+ {
+ .property = "ti,pri-upp",
+ .reg = DA8XX_MSTPRI0_REG,
+ .shift = 16,
+ .mask = 0xfff0ffff,
+ },
+ {
+ .property = "ti,pri-sata",
+ .reg = DA8XX_MSTPRI0_REG,
+ .shift = 20,
+ .mask = 0xff0fffff,
+ },
+ {
+ .property = "ti,pri-pru0",
+ .reg = DA8XX_MSTPRI1_REG,
+ .shift = 0,
+ .mask = 0xfffffff0,
+ },
+ {
+ .property = "ti,pri-pru1",
+ .reg = DA8XX_MSTPRI1_REG,
+ .shift = 4,
+ .mask = 0xffffff0f,
+ },
+ {
+ .property = "ti,pri-edma30tc0",
+ .reg = DA8XX_MSTPRI1_REG,
+ .shift = 8,
+ .mask = 0xfffff0ff,
+ },
+ {
+ .property = "ti,pri-edma30tc1",
+ .reg = DA8XX_MSTPRI1_REG,
+ .shift = 12,
+ .mask = 0xffff0fff,
+ },
+ {
+ .property = "ti,pri-edma31tc0",
+ .reg = DA8XX_MSTPRI1_REG,
+ .shift = 16,
+ .mask = 0xfff0ffff,
+ },
+ {
+ .property = "ti,pri-vpif-dma-0",
+ .reg = DA8XX_MSTPRI1_REG,
+ .shift = 24,
+ .mask = 0xf0ffffff,
+ },
+ {
+ .property = "ti,pri-vpif-dma-1",
+ .reg = DA8XX_MSTPRI1_REG,
+ .shift = 28,
+ .mask = 0x0fffffff,
+ },
+ {
+ .property = "ti,pri-emac",
+ .reg = DA8XX_MSTPRI2_REG,
+ .shift = 0,
+ .mask = 0xfffffff0,
+ },
+ {
+ .property = "ti,pri-usb0cfg",
+ .reg = DA8XX_MSTPRI2_REG,
+ .shift = 8,
+ .mask = 0xfffff0ff,
+ },
+ {
+ .property = "ti,pri-usb0cdma",
+ .reg = DA8XX_MSTPRI2_REG,
+ .shift = 12,
+ .mask = 0xffff0fff,
+ },
+ {
+ .property = "ti,pri-uhpi",
+ .reg = DA8XX_MSTPRI2_REG,
+ .shift = 20,
+ .mask = 0xff0fffff,
+ },
+ {
+ .property = "ti,pri-usb1",
+ .reg = DA8XX_MSTPRI2_REG,
+ .shift = 24,
+ .mask = 0xf0ffffff,
+ },
+ {
+ .property = "ti,pri-lcdc",
+ .reg = DA8XX_MSTPRI2_REG,
+ .shift = 28,
+ .mask = 0x0fffffff,
+ },
+};
+
+static void da8xx_syscfg_set_mstpri(void __iomem *syscfg0, struct device *dev)
+{
+ const struct da8xx_mstpri_descr *pri_descr;
+ struct device_node *node = dev->of_node;
+ void __iomem *mstpri;
+ u32 old_pri, new_pri;
+ int ret, i;
+
+ for (i = 0; i < ARRAY_SIZE(priorities); i++) {
+ pri_descr = &priorities[i];
+
+ ret = of_property_read_u32(node, pri_descr->property, &new_pri);
+ if (ret)
+ continue;
+
+ if (new_pri > DA8XX_MSTPRI_MAX) {
+ dev_warn(dev,
+ "omitting property '%s' - value too high\n",
+ pri_descr->property);
+ continue;
+ }
+
+ mstpri = syscfg0 + pri_descr->reg;
+ old_pri = __raw_readl(mstpri);
+ old_pri &= pri_descr->mask;
+ new_pri <<= pri_descr->shift;
+ new_pri |= old_pri;
+
+ __raw_writel(new_pri, mstpri);
+ }
+}
+
+static int da8xx_syscfg_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ void __iomem *syscfg0;
+
+ syscfg0 = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
+ if (!syscfg0) {
+ dev_err(dev, "unable to map syscfg0\n");
+ return -EIO;
+ }
+
+ da8xx_syscfg_set_mstpri(syscfg0, dev);
+
+ iounmap(syscfg0);
+
+ return 0;
+}
+
+static const struct of_device_id da8xx_syscfg_of_match[] = {
+ { .compatible = "ti,da850-syscfg", },
+ { },
+};
+
+static struct platform_driver da8xx_syscfg_driver = {
+ .probe = da8xx_syscfg_probe,
+ .driver = {
+ .name = "da8xx-syscfg",
+ .of_match_table = da8xx_syscfg_of_match,
+ },
+};
+module_platform_driver(da8xx_syscfg_driver);
+
+MODULE_AUTHOR("Bartosz Golaszewski <bgolaszewski@baylibre.com>");
+MODULE_DESCRIPTION("TI da8xx System Configuration driver");
+MODULE_LICENSE("GPL v2");
--
2.9.3
^ permalink raw reply related
* [PATCH 1/3] ARM: memory: da8xx-ddrctl: new driver
From: Bartosz Golaszewski @ 2016-10-17 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476721850-454-1-git-send-email-bgolaszewski@baylibre.com>
Create a new driver for the da8xx DDR2/mDDR controller and implement
support for writing to the Peripheral Bus Burst Priority Register.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
.../memory-controllers/ti-da8xx-ddrctl.txt | 25 +++++++
drivers/memory/Kconfig | 8 +++
drivers/memory/Makefile | 1 +
drivers/memory/da8xx-ddrctl.c | 77 ++++++++++++++++++++++
4 files changed, 111 insertions(+)
create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
create mode 100644 drivers/memory/da8xx-ddrctl.c
diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
new file mode 100644
index 0000000..e340404
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
@@ -0,0 +1,25 @@
+* Device tree bindings for Texas Instruments da8xx DDR2/mDDR memory controller
+
+The DDR2/mDDR memory controller present on Texas Instruments da8xx SoCs memory
+maps a set of registers which allow to tweak the controller's behavior.
+
+Documentation:
+OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
+
+Required properties:
+
+- compatible: "ti,da850-ddrctl"
+
+Optional properties:
+
+- ti,pr-old-count: Priority raise old counter. Specifies the number of
+ memory transfers after which the DDR2/mDDR memory
+ controller will elevate the priority of the oldest
+ command in the command FIFO. Must be between 0-255.
+
+Example for da850 shown below.
+
+ddrctl {
+ compatible = "ti,da850-ddrctl";
+ ti,pr-old-count = <0x20>;
+};
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 4b4c0c3..ec80e35 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -134,6 +134,14 @@ config MTK_SMI
mainly help enable/disable iommu and control the power domain and
clocks for each local arbiter.
+config DA8XX_DDRCTL
+ bool "Texas Instruments da8xx DDR2/mDDR driver"
+ depends on ARCH_DAVINCI_DA8XX
+ help
+ This driver is for the DDR2/mDDR Memory Controller present on
+ Texas Instruments da8xx SoCs. It's used to tweak various memory
+ controller configuration options.
+
source "drivers/memory/samsung/Kconfig"
source "drivers/memory/tegra/Kconfig"
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index b20ae38..e88097fb 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o
obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
obj-$(CONFIG_JZ4780_NEMC) += jz4780-nemc.o
obj-$(CONFIG_MTK_SMI) += mtk-smi.o
+obj-$(CONFIG_DA8XX_DDRCTL) += da8xx-ddrctl.o
obj-$(CONFIG_SAMSUNG_MC) += samsung/
obj-$(CONFIG_TEGRA_MC) += tegra/
diff --git a/drivers/memory/da8xx-ddrctl.c b/drivers/memory/da8xx-ddrctl.c
new file mode 100644
index 0000000..dcd0a61
--- /dev/null
+++ b/drivers/memory/da8xx-ddrctl.c
@@ -0,0 +1,77 @@
+/*
+ * TI da8xx DDR2/mDDR controller driver
+ *
+ * Copyright (C) 2016 BayLibre SAS
+ *
+ * Author:
+ * Bartosz Golaszewski <bgolaszewski@baylibre.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+
+#define DA8XX_DDR_CTL_BASE 0xB0000000
+#define DA8XX_PBBPR_OFFSET 0x00000020
+#define DA8XX_PBBPR_REG(p) ((p) + DA8XX_PBBPR_OFFSET)
+
+#define DA8XX_PBBPR_MAX 0xff
+
+static void da8xx_ddrctl_set_pbbpr(void __iomem *ddrctl, struct device *dev)
+{
+ struct device_node *node = dev->of_node;
+ u32 pr_old_count;
+ int ret;
+
+ ret = of_property_read_u32(node, "ti,pr-old-count", &pr_old_count);
+ if (ret)
+ return;
+
+ if (pr_old_count > DA8XX_PBBPR_MAX) {
+ dev_warn(dev, "priority raise old counter value too high\n");
+ return;
+ }
+
+ __raw_writel(pr_old_count, DA8XX_PBBPR_REG(ddrctl));
+}
+
+static int da8xx_ddrctl_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ void __iomem *ddrctl;
+
+ ddrctl = ioremap(DA8XX_DDR_CTL_BASE, SZ_256);
+ if (!ddrctl) {
+ dev_err(dev, "unable to map memory controller registers\n");
+ return -EIO;
+ }
+
+ da8xx_ddrctl_set_pbbpr(ddrctl, dev);
+
+ iounmap(ddrctl);
+
+ return 0;
+}
+
+static const struct of_device_id da8xx_ddrctl_of_match[] = {
+ { .compatible = "ti,da850-ddrctl", },
+ { },
+};
+
+static struct platform_driver da8xx_ddrctl_driver = {
+ .probe = da8xx_ddrctl_probe,
+ .driver = {
+ .name = "da8xx-ddrctl",
+ .of_match_table = da8xx_ddrctl_of_match,
+ },
+};
+module_platform_driver(da8xx_ddrctl_driver);
+
+MODULE_AUTHOR("Bartosz Golaszewski <bgolaszewski@baylibre.com>");
+MODULE_DESCRIPTION("TI da8xx DDR2/mDDR controller driver");
+MODULE_LICENSE("GPL v2");
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox