* [PATCH] ARM: davinci: da850: Fix pwm name matching
From: David Lechner @ 2016-10-25 17:54 UTC (permalink / raw)
To: linux-arm-kernel
This fixes pwm name matching for DA850 familiy devices. When using device
tree, the da850_auxdata_lookup[] table caused pwm devices to have the exact
same name, which caused errors when trying to register the devices.
The names for clock matching in da850_clks[] also have to be updated to
to exactly match in order for the clock lookup to work correctly.
Signed-off-by: David Lechner <david@lechnology.com>
---
Tested working on LEGO MINDSTORMS EV3.
arch/arm/mach-davinci/da850.c | 10 +++++++---
arch/arm/mach-davinci/da8xx-dt.c | 10 +++++-----
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index ed3d0e9..6b78a8f 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -510,9 +510,13 @@ static struct clk_lookup da850_clks[] = {
CLK("vpif", NULL, &vpif_clk),
CLK("ahci_da850", NULL, &sata_clk),
CLK("davinci-rproc.0", NULL, &dsp_clk),
- CLK("ehrpwm", "fck", &ehrpwm_clk),
- CLK("ehrpwm", "tbclk", &ehrpwm_tbclk),
- CLK("ecap", "fck", &ecap_clk),
+ CLK("ehrpwm.0", "fck", &ehrpwm_clk),
+ CLK("ehrpwm.0", "tbclk", &ehrpwm_tbclk),
+ CLK("ehrpwm.1", "fck", &ehrpwm_clk),
+ CLK("ehrpwm.1", "tbclk", &ehrpwm_tbclk),
+ CLK("ecap.0", "fck", &ecap_clk),
+ CLK("ecap.1", "fck", &ecap_clk),
+ CLK("ecap.2", "fck", &ecap_clk),
CLK(NULL, NULL, NULL),
};
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 7947267..6ad8ddb 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -23,11 +23,11 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,davinci-i2c", 0x01e28000, "i2c_davinci.2", NULL),
OF_DEV_AUXDATA("ti,davinci-wdt", 0x01c21000, "davinci-wdt", NULL),
OF_DEV_AUXDATA("ti,da830-mmc", 0x01c40000, "da830-mmc.0", NULL),
- OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f00000, "ehrpwm", NULL),
- OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f02000, "ehrpwm", NULL),
- OF_DEV_AUXDATA("ti,da850-ecap", 0x01f06000, "ecap", NULL),
- OF_DEV_AUXDATA("ti,da850-ecap", 0x01f07000, "ecap", NULL),
- OF_DEV_AUXDATA("ti,da850-ecap", 0x01f08000, "ecap", NULL),
+ OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f00000, "ehrpwm.0", NULL),
+ OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f02000, "ehrpwm.1", NULL),
+ OF_DEV_AUXDATA("ti,da850-ecap", 0x01f06000, "ecap.0", NULL),
+ OF_DEV_AUXDATA("ti,da850-ecap", 0x01f07000, "ecap.1", NULL),
+ OF_DEV_AUXDATA("ti,da850-ecap", 0x01f08000, "ecap.2", NULL),
OF_DEV_AUXDATA("ti,da830-spi", 0x01c41000, "spi_davinci.0", NULL),
OF_DEV_AUXDATA("ti,da830-spi", 0x01f0e000, "spi_davinci.1", NULL),
OF_DEV_AUXDATA("ns16550a", 0x01c42000, "serial8250.0", NULL),
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64: Neaten show_regs, remove KERN_CONT
From: Linus Torvalds @ 2016-10-25 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+55aFwFQSass91gdGsjo4BkkAYmoFSn-Cpm6yF+SygF_tRp1g@mail.gmail.com>
On Tue, Oct 25, 2016 at 10:38 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Oct 24, 2016 at 9:42 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>>
>> That does not appear to be the case; as fr as I can tell the core prints a
>> timestamp per line as required. If I run:
>>
>> printk("TEST\nLINE1\nLINE2\nLINE3\nLINE4\n");
>
> Please don't do this.
Side note: even with my patch, the above kind of stuff hits other special cases.
In particular, the "extended header" that is printed to special
consoles (really just the network console) will only print one header
for each record. So you'll end up with the "normal" logs having time
appended to each line, but the extended logs that use
"msg_print_ext_body()" will have just a header for each record, and
then within the record the newlines will be escaped as "\0a", I think.
We could fix that too, but basically newlines in the middle of a
string has never really worked reliably. I think historically (long
long ago) they were just printed as-is, and did not have the loglevel
or the timestamp, for example. Now those should work for normal
logging, but there clearly are still cases where it breaks down.
Of course, you probably could argue that nobody cares too deeply about
the exact format of the extended logging, and you'd probably be right.
But still..
And yes, what we probably *should* do is to do the newline breaking
when adding things to the log, rather than doing it in the
"msg_print_text()" phase.
There's a reason why I actually would have liked to entirely rewrite
the whole printk mess. But there's also a reason I didn't - I'm not
quite _that_ much of a glutton for punishment.
Linus
^ permalink raw reply
* [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem
From: Tobias Jakobi @ 2016-10-25 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fa4114e0-9382-0653-7dc6-a63f1312d616@osg.samsung.com>
Hello Shuah,
Shuah Khan wrote:
> On 10/19/2016 04:27 PM, Shuah Khan wrote:
>> On 10/19/2016 08:16 AM, Inki Dae wrote:
>>> Hi Shuah,
>>>
>>> 2016-10-13 8:11 GMT+09:00 Shuah Khan <shuahkh@osg.samsung.com>:
>>>> Hi Inki,
>>>>
>>>> On 08/15/2016 10:40 PM, Inki Dae wrote:
>>>>
>>>>>>
>>>>>> okay the very first commit that added IOMMU support
>>>>>> introduced the code that rejects non-contig gem memory
>>>>>> type without IOMMU.
>>>>>>
>>>>>> commit 0519f9a12d0113caab78980c48a7902d2bd40c2c
>>>>>> Author: Inki Dae <inki.dae@samsung.com>
>>>>>> Date: Sat Oct 20 07:53:42 2012 -0700
>>>>>>
>>>>>> drm/exynos: add iommu support for exynos drm framework
>>>>>>
>>>>
>>>> I haven't given up on this yet. I am still seeing the following failure:
>>>>
>>>> Additional debug messages I added:
>>>> [ 15.287403] exynos_drm_gem_create_ioctl() 1
>>>> [ 15.287419] exynos_drm_gem_create() flags 1
>>>>
>>>> [ 15.311511] [drm:exynos_drm_framebuffer_init] *ERROR* Non-contiguous GEM memory is not supported.
>>>>
>>>> Additional debug message I added:
>>>> [ 15.318981] [drm:exynos_user_fb_create] *ERROR* failed to initialize framebuffer
>>>>
>>>> This is what happens:
>>>>
>>>> 1. exynos_drm_gem_create_ioctl() gets called with EXYNOS_BO_NONCONTIG request
>>>> 2. exynos_drm_gem_create(0 goes ahead and creates the GEM buffers
>>>> 3. exynos_user_fb_create() tries to associate GEM to fb and fails during
>>>> check_fb_gem_memory_type()
>>>>
>>>> At this point, there is no recovery and lightdm fails
>>>>
>>>> xf86-video-armsoc/src/drmmode_exynos/drmmode_exynos.c assumes contiguous
>>>> allocations are not supported in some exynos drm versions: The following
>>>> commit introduced this change:
>>>>
>>>> https://git.linaro.org/arm/xorg/driver/xf86-video-armsoc.git/commitdiff/3be1f6273441fe95dd442f44064387322e16b7e9
>>>>
>>>> excerpts from the diff:- if (create_gem->buf_type == ARMSOC_BO_SCANOUT)
>>>> - create_exynos.flags = EXYNOS_BO_CONTIG;
>>>> - else
>>>> - create_exynos.flags = EXYNOS_BO_NONCONTIG;
>>>> +
>>>> + /* Contiguous allocations are not supported in some exynos drm versions.
>>>> + * When they are supported all allocations are effectively contiguous
>>>> + * anyway, so for simplicity we always request non contiguous buffers.
>>>> + */
>>>> + create_exynos.flags = EXYNOS_BO_NONCONTIG;
>>>>
>>>
>>> Above comment, "Contiguous allocations are not supported in some
>>> exynos drm versions.", seems wrong assumption.
>>> The root cause, contiguous allocation is not supported, would be that
>>> they used Linux kernel which didn't have CMA region enough - as
>>> default 16MB, or didn't declare CMA region enough for the DMA device.
>>> So I think they should not force to flag EXYNOS_BO_NONCONTIG and they
>>> should manage the error case if the allocation failed.
>>
>> This assumption doesn't sound correct and forcing NONCONTIG isn't right
>> either.
>>
>>>
>>>> There might have been logic on exynos_drm that forced Contig when it coudn't
>>>> support NONCONTIG. At least, that is what this comment suggests. This assumption
>>>> doesn't appear to be a good one and not sure if this change was made to fix a bug.
>>>>
>>>> After the IOMMU support, this assumption is no longer true. Hence, with IOMMU
>>>> support, latest kernels have a mismatch with the installed xf86-video-armsoc
>>>>
>>>> This is what I am running into. This leads to the following question:
>>>>
>>>> 1. How do we ensure exynos_drm kernel changes don't break user-space
>>>> specifically xf86-video-armsoc
>>>> 2. This seems to have gone undetected for a while. I see a change in
>>>> exynos_drm_gem_dumb_create() that is probably addressing this type
>>>> of breakage. Commit 122beea84bb90236b1ae545f08267af58591c21b adds
>>>> handling for IOMMU NONCONTIG case.
>>>
>>> Seems this patch has a problem. This patch forces to flag NONCONTIG if
>>> iommu is enabled. The flag should be depend on the argument from
>>> user-space.
>>> I.e., if user-space requested a gem allocation with CONTIG flag, then
>>> Exynos drm driver should allocate contiguous memory even though iommu
>>> is enabled.
>>>
>>>>
>>>> Anyway, I am interested in getting the exynos_drm kernel side code
>>>> and xf86-video-armsoc in sync to resolve the issue.
>>>>
>>>> Could you recommend a going forward plan?
>>>
>>> My opinion are,
>>>
>>> 1. Do not force to flag EXYNOS_BO_NONCONTIG at xf86-video-armsoc
>
> Okay more on this. I fixed xf86-video-armso to ask for EXYNOS_BO_CONTIG
> for ARMSOC_BO_SCANOUT and EXYNOS_BO_NONCONTIG in all other cases.
>
> Revert of the commit: 3be1f6273441fe95dd442f44064387322e16b7e9
>
> With this change, now display manager starts just fine. However, it turns
> out xf86-video-armsoc is obsoleted in favor of xf86-video-modesetting. The
> last update to xf86-video-armsoc git was 3 years ago.
IIRC xf86-video-armsoc was created to facilitate integration with the
proprietary Mali userspace blob. I don't think that can be done with the
modesetting DDX.
> I am not sure where to send the fix and doesn't look like it is being
> maintained actively. I can pursue it further and try to get this into
> xf86-video-armsoc provided I can find the maintainer for this seemingly
> inactive project.
I was wondering if anyone has actually complained about this issue?
> I brought in the latest xf86-video-modesetting bits from
>
> https://cgit.freedesktop.org/xorg/driver/xf86-video-modesetting
>
> I removed xf86-video-armsoc and installed xf86-video-modesetting and that
> worked just fine. xf86-video-modesetting uses dumb_create interface instead
> of DRM_IOCTL_EXYNOS_GEM_CREATE.
>
> dumb_create interface eliminates the need for DRM_IOCTL_EXYNOS_GEM_CREATE
> in userspace. libdrm-2.4.71 does call DRM_IOCTL_EXYNOS_GEM_CREATE.
>
> The question is do we still need to continue to support the custom gem
> create interface DRM_IOCTL_EXYNOS_GEM_CREATE?
I'd say yes. With just the dumb_create interface it is not possible to
change the type of buffer you get. And if you want to support any kind
of hw acceleration in the DDX, you probably want to control at least the
caching behaviour of the buffer.
> Some drm drivers seem to support it and some don't.
Not sure I understand this. I don't think any other DRM driver except
for exynos supports this ioctl. But all drivers have their own ioctls to
request memory (DRM_IOCTL_ETNAVIV_GEM_NEW, DRM_IOCTL_VC4_CREATE_BO, etc.)
> Unfortunately, if userspace requests noncontig
> for scanout, we will continue to see problems with display manager when
> iommu is disabled. dumb create hides all of that, are there good reasons
> to continue to support it in exynos drm?
In addition to the stuff I said above, you can use it for render nodes.
That doesn't work for dumb_create.
> Exposing CONTIG and NONCONTIG to userspace appears to be causing problems
> when exynos drm determines it can't support non-contig GEM buffers in fb
> init after userspace allocates them.
Might be missing something here, but this whole thing just looks like a
bug in xf86-video-armsoc. No matter from which perspective you look, the
commit that changed all allocations to noncontig was plain wrong.
My guess: This was done to paper over some bug in some vendor kernel for
a product using an Exynos SoC.
With best wishes,
Tobias
>
>>> 2. Do not force to flag NONCONTIG at Exynos drm driver even though
>>> iommu is enabled and flag allocation type with the argument from
>>> user-space.
>>>
>
> exynos_drm_gem_dumb_create() doesn't take any flags, there is no need
> to change the above.
>
> thanks,
> -- Shuah
>
^ permalink raw reply
* [RFC v2] ARM: memory: da8xx-ddrctl: new driver
From: Kevin Hilman @ 2016-10-25 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477402876-22472-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>
> ---
> .../memory-controllers/ti-da8xx-ddrctl.txt | 20 +++
> drivers/memory/Kconfig | 8 +
> drivers/memory/Makefile | 1 +
> drivers/memory/da8xx-ddrctl.c | 175 +++++++++++++++++++++
> 4 files changed, 204 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..7e271dd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
> @@ -0,0 +1,20 @@
> +* Device tree bindings for Texas Instruments da8xx DDR2/mDDR memory controller
> +
> +The DDR2/mDDR memory controller present on Texas Instruments da8xx SoCs features
> +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-ddr-controller" - for da850 SoC based boards
> +- reg: a tuple containing the base address of the memory
> + controller and the size of the memory area to map
> +
> +Example for da850 shown below.
> +
> +ddrctl {
> + compatible = "ti,da850-ddr-controller";
> + reg = <0xB0000000 0x100>;
> +};
Axel's series for the USB PHY reminded me that the PHY also has some
config registers in this same area, and his series creates a syscon for
a similar range of registers.
Could you create a syscon for the SYSCFG0 registers, which would then
be used by ths driver and your other drivers/bus driver? Then the
binding would just reference the sysconf via phandle, and your driver
can use syscon_regmap_lookup_by_phandle()
> 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..66022df
> --- /dev/null
> +++ b/drivers/memory/da8xx-ddrctl.c
> @@ -0,0 +1,175 @@
> +/*
> + * 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/of_device.h>
> +#include <linux/of_fdt.h>
> +#include <linux/platform_device.h>
> +#include <linux/io.h>
> +
> +/*
> + * REVISIT: Linux doesn't have a good framework for the kind of performance
> + * knobs this driver controls. We can't use device tree properties as it deals
> + * with hardware configuration rather than description. We also don't want to
> + * commit to maintaining some random sysfs attributes.
> + *
> + * For now we just hardcode the register values for the boards that need
> + * some changes (as is the case for the LCD controller on da850-lcdk - the
> + * first board we support here). When linux gets an appropriate framework,
> + * we'll easily convert the driver to it.
> + */
> +
> +struct da8xx_ddrctl_config_knob {
> + const char *name;
> + u32 reg;
> + u32 mask;
> + u32 offset;
nit: call this shift instead, which will also map well onto the regmap
accessors (which you'll use when switching to syscon.)
> +};
> +
> +static const struct da8xx_ddrctl_config_knob da8xx_ddrctl_knobs[] = {
> + {
> + .name = "da850-pbbpr",
> + .reg = 0x20,
> + .mask = 0xffffff00,
> + .offset = 0,
> + },
> +};
> +
> +struct da8xx_ddrctl_setting {
> + const char *name;
> + u32 val;
> +};
> +
> +struct da8xx_ddrctl_board_settings {
> + const char *board;
> + const struct da8xx_ddrctl_setting *settings;
> +};
> +
> +static const struct da8xx_ddrctl_setting da850_lcdk_ddrctl_settings[] = {
> + {
> + .name = "da850-pbbpr",
> + .val = 0x20,
> + },
> + { }
> +};
> +
> +static const struct da8xx_ddrctl_board_settings da8xx_ddrctl_board_confs[] = {
> + {
> + .board = "ti,da850-lcdk",
> + .settings = da850_lcdk_ddrctl_settings,
> + },
> +};
> +
> +static const struct da8xx_ddrctl_config_knob *
> +da8xx_ddrctl_match_knob(const struct da8xx_ddrctl_setting *setting)
> +{
> + const struct da8xx_ddrctl_config_knob *knob;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(da8xx_ddrctl_knobs); i++) {
> + knob = &da8xx_ddrctl_knobs[i];
> +
> + if (strcmp(knob->name, setting->name) == 0)
> + return knob;
> + }
> +
> + return NULL;
> +}
> +
> +static const struct da8xx_ddrctl_setting *da8xx_ddrctl_get_board_settings(void)
> +{
> + const struct da8xx_ddrctl_board_settings *board_settings;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(da8xx_ddrctl_board_confs); i++) {
> + board_settings = &da8xx_ddrctl_board_confs[0];
Looks like that '0' should be 'i' ?
> + if (of_machine_is_compatible(board_settings->board))
> + return board_settings->settings;
> + }
> +
> + return NULL;
> +}
> +
> +static int da8xx_ddrctl_probe(struct platform_device *pdev)
> +{
> + const struct da8xx_ddrctl_config_knob *knob;
> + const struct da8xx_ddrctl_setting *setting;
> + struct device_node *node;
> + struct resource *res;
> + void __iomem *ddrctl;
> + struct device *dev;
> + u32 reg;
> +
> + dev = &pdev->dev;
> + node = dev->of_node;
> +
> + setting = da8xx_ddrctl_get_board_settings();
> + if (!setting) {
> + dev_err(dev, "no settings for board '%s'\n",
> + of_flat_dt_get_machine_name());
> + return -EINVAL;
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + ddrctl = devm_ioremap_resource(dev, res);
> + if (IS_ERR(ddrctl)) {
> + dev_err(dev, "unable to map memory controller registers\n");
> + return PTR_ERR(ddrctl);
> + }
> +
> + for (; setting->name; setting++) {
> + knob = da8xx_ddrctl_match_knob(setting);
> + if (!knob) {
> + dev_warn(dev,
> + "no such config option: %s\n", setting->name);
> + continue;
> + }
> +
> + if (knob->reg > (res->end - res->start - sizeof(u32))) {
> + dev_warn(dev,
> + "register offset of '%s' exceeds mapped memory size\n",
> + knob->name);
> + continue;
> + }
> +
> + reg = __raw_readl(ddrctl + knob->reg);
> + reg &= knob->mask;
> + reg |= setting->val << knob->offset;
> +
> + dev_dbg(dev, "writing 0x%08x to %s\n", reg, setting->name);
> +
> + __raw_writel(reg, ddrctl + knob->reg);
nit: I don't think you need the __raw accessors here.
But in any case, moving to syscon you'll be using regmap accessors, and
this can just be converted to a single regmap_update_bits.
Kevin
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id da8xx_ddrctl_of_match[] = {
> + { .compatible = "ti,da850-ddr-controller", },
> + { },
> +};
> +
> +static struct platform_driver da8xx_ddrctl_driver = {
> + .probe = da8xx_ddrctl_probe,
> + .driver = {
> + .name = "da850-ddr-controller",
> + .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");
^ permalink raw reply
* [PATCH] arm64: Neaten show_regs, remove KERN_CONT
From: Mark Rutland @ 2016-10-25 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+55aFwFQSass91gdGsjo4BkkAYmoFSn-Cpm6yF+SygF_tRp1g@mail.gmail.com>
On Tue, Oct 25, 2016 at 10:38:31AM -0700, Linus Torvalds wrote:
> On Mon, Oct 24, 2016 at 9:42 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > That does not appear to be the case; as fr as I can tell the core prints a
> > timestamp per line as required. If I run:
> >
> > printk("TEST\nLINE1\nLINE2\nLINE3\nLINE4\n");
>
> Please don't do this.
>
> It has historically not worked well, and it still doesn't actually
> work reliably. In particular, it currently works in the *logs* (ie
> dmesg), but not necessarily on screen (because "msg_print_text()" does
> do the "look for newlines in the middle", but console_cont_flush()
> does not).
Sure; I'll avoid that.
it seems that's a drop in the ocean, though. :/
[mark at leverpostej:~/src/linux]% git grep 'pr\(intk\|_.*\)(.*)' | grep '\\n[^"]' | wc -l
375
> So you can try the attached patch. It likely fixes your issues simply
> because it removes all the crazy code.
That worked for me. I see consistent results over the UART and in dmesg
with that applied atop of v4.9-rc2. Feel free to add:
Tested-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
^ permalink raw reply
* [PATCH] arm64: Neaten show_regs, remove KERN_CONT
From: Joe Perches @ 2016-10-25 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+55aFw4EP_qxZ8tcRUV=PcLx_XbwXXOU_yp3cJHVjazof_0MA@mail.gmail.com>
On Tue, 2016-10-25 at 10:55 -0700, Linus Torvalds wrote:
> And yes, what we probably *should* do is to do the newline breaking
> when adding things to the log, rather than doing it in the
> "msg_print_text()" phase.
Yeah.
One thing that'd be nice one day is to remove all the
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
lines and have printk do that instead using a singleton
or a lookup for KBUILD_MODNAME as appropriate.
> There's a reason why I actually would have liked to entirely rewrite
> the whole printk mess.But there's also a reason I didn't - I'm not
> quite _that_ much of a glutton for punishment.
You sure?
^ permalink raw reply
* [PATCH 0/3] drivers: iommu: declare iommu_gather_ops structures as const
From: Bhumika Goyal @ 2016-10-25 18:06 UTC (permalink / raw)
To: linux-arm-kernel
Constify iommu_gather_ops structures and replace __initdata with
__initconst where needed.
Bhumika Goyal (3):
drivers: iommu: arm-smmu: constify iommu_gather_ops structures
drivers: iommu: arm-smmu-v3: constify iommu_gather_ops structures
drivers: iommu: io-pgtable-arm: use const and __initconst for
iommu_gather_ops structures
drivers/iommu/arm-smmu-v3.c | 2 +-
drivers/iommu/arm-smmu.c | 2 +-
drivers/iommu/io-pgtable-arm.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/3] drivers: iommu: arm-smmu: constify iommu_gather_ops structures
From: Bhumika Goyal @ 2016-10-25 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477418772-12184-1-git-send-email-bhumirks@gmail.com>
Check for iommu_gather_ops structures that are only stored in the tlb
field of an io_pgtable_cfg structure. The tlb field is of type
const struct iommu_gather_ops *, so iommu_gather_ops structures
having this property can be declared as const.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/iommu/arm-smmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index c841eb7..a5bc8fb 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -640,7 +640,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
}
}
-static struct iommu_gather_ops arm_smmu_gather_ops = {
+static const struct iommu_gather_ops arm_smmu_gather_ops = {
.tlb_flush_all = arm_smmu_tlb_inv_context,
.tlb_add_flush = arm_smmu_tlb_inv_range_nosync,
.tlb_sync = arm_smmu_tlb_sync,
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] drivers: iommu: arm-smmu-v3: constify iommu_gather_ops structures
From: Bhumika Goyal @ 2016-10-25 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477418772-12184-1-git-send-email-bhumirks@gmail.com>
Check for iommu_gather_ops structures that are only stored in the tlb
field of an io_pgtable_cfg structure. The tlb field is of type
const struct iommu_gather_ops *, so iommu_gather_ops structures
having this property can be declared as const.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/iommu/arm-smmu-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 15c01c3..51d8be4 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1358,7 +1358,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
} while (size -= granule);
}
-static struct iommu_gather_ops arm_smmu_gather_ops = {
+static const struct iommu_gather_ops arm_smmu_gather_ops = {
.tlb_flush_all = arm_smmu_tlb_inv_context,
.tlb_add_flush = arm_smmu_tlb_inv_range_nosync,
.tlb_sync = arm_smmu_tlb_sync,
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] drivers: iommu: io-pgtable-arm: use const and __initconst for iommu_gather_ops structures
From: Bhumika Goyal @ 2016-10-25 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477418772-12184-1-git-send-email-bhumirks@gmail.com>
Check for iommu_gather_ops structures that are only stored in the tlb
field of an io_pgtable_cfg structure. The tlb field is of type
const struct iommu_gather_ops *, so iommu_gather_ops structures
having this property can be declared as const. Also, replace __initdata
with __initconst.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/iommu/io-pgtable-arm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index f5c90e1..412e21d 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -916,7 +916,7 @@ static void dummy_tlb_sync(void *cookie)
WARN_ON(cookie != cfg_cookie);
}
-static struct iommu_gather_ops dummy_tlb_ops __initdata = {
+static const struct iommu_gather_ops dummy_tlb_ops __initconst = {
.tlb_flush_all = dummy_tlb_flush_all,
.tlb_add_flush = dummy_tlb_add_flush,
.tlb_sync = dummy_tlb_sync,
--
1.9.1
^ permalink raw reply related
* [PATCH 4/9] pinctrl: meson: allow gpio to request irq
From: Linus Walleij @ 2016-10-25 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bbc268c8-35c3-206a-46b1-62cebef174b2@arm.com>
On Tue, Oct 25, 2016 at 4:47 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 25/10/16 15:22, Jerome Brunet wrote:
>> There is a few problems to guarantee that gpio == hwirq.
>> 1. We have 2 instances of pinctrl, to guarantee that the linux gpio
>> number == hwirq, we would have to guarantee the order in which they are
>> probed. At least this my understanding
>
> Maybe I wasn't clear enough, and my use of gpio is probably wrong. So
> Linux has a gpio number, which is obviously an abstract number (just
> like the Linux irq number). But the pad number, in the context of given
> SoC, is constant. So we have:
>
> pad->gpio
> hwirq->irq
>
> Why can't you have pad == hwirq, always? This is already what you have
> in the irqchip driver. This would simplify a lot of things.
My thought as well.
We usually refer to the local numberspace on the GPIO controller
as "offsets", so line offsets 0...31 on a gpiochip with 31 lines.
The ngpio in struct gpio_chip is the number of lines on that controller,
and should nominally map 1:1 to hwirq sources.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 4/9] pinctrl: meson: allow gpio to request irq
From: Linus Walleij @ 2016-10-25 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477409478.2482.113.camel@baylibre.com>
On Tue, Oct 25, 2016 at 5:31 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> On Tue, 2016-10-25 at 15:47 +0100, Marc Zyngier wrote:
>> Is gpio_to_irq() supposed to allocate an interrupt? Or merely to
>> report the existence of a mapping?
It should provide an IRQ corresponding to the gpio line, if possible.
However the semantic is such, that it is not necessary to call to_irq()
before using an IRQ: the irqchip and gpiochip abstractions should be
orthogonal.
This goes especially when using device tree or ACPI, where you
may reference an IRQ from something modeled as irqchip, which
is simultaneously a gpiochip.
> Linus, please correct me if I'm wrong,
> .to_irq gets the linux gpio number and returns the linux virtual irq
> numbers, 0 if there is no interrupt.
Yes. But it may *or may not* be called before using the IRQ.
So it should look up or try to create a mapping on request, but not
assume to have been called before using some line as IRQ.
The only thing you should assume to be called before an interrupt
is put to use is the stuff in irqchip. So you have to do your
dynamic irqdomain mapping elsewhere than .to_irq().
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3] drivers: psci: PSCI checker module
From: Paul E. McKenney @ 2016-10-25 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025154535.GA3107@red-moon>
On Tue, Oct 25, 2016 at 04:45:35PM +0100, Lorenzo Pieralisi wrote:
> [ +Paul, James ]
>
> Left most of the patch content in place so that they can follow it even
> if they weren't CC'ed.
>
> On Thu, Oct 20, 2016 at 03:51:15PM +0100, Kevin Brodsky wrote:
> > On arm and arm64, PSCI is one of the possible firmware interfaces
> > used for power management. This includes both turning CPUs on and off,
> > and suspending them (entering idle states).
> >
> > This patch adds a PSCI checker module that enables basic testing of
> > PSCI operations during startup. There are two main tests: CPU
> > hotplugging and suspending.
> >
> > In the hotplug tests, the hotplug API is used to turn off and on again
> > all CPUs in the system, and then all CPUs in each cluster, checking
> > the consistency of the return codes.
> >
> > In the suspend tests, a high-priority thread is created on each core
> > and uses low-level cpuidle functionalities to enter suspend, in all
> > the possible states and multiple times. This should allow a maximum
> > number of CPUs to enter the same sleep state at the same or slightly
> > different time.
> >
> > In essence, the suspend tests use a principle similar to that of the
> > intel_powerclamp driver (drivers/thermal/intel_powerclamp.c), but the
> > threads are only kept for the duration of the test (they are already
> > gone when userspace is started).
> >
> > While in theory power management PSCI functions (CPU_{ON,OFF,SUSPEND})
> > could be directly called, this proved too difficult as it would imply
> > the duplication of all the logic used by the kernel to allow for a
> > clean shutdown/bringup/suspend of the CPU (the deepest sleep states
> > implying potentially the shutdown of the CPU).
> >
> > Note that this file cannot be compiled as a loadable module, since it
> > uses a number of non-exported identifiers (essentially for
> > PSCI-specific checks and direct use of cpuidle) and relies on the
> > absence of userspace to avoid races when calling hotplug and cpuidle
> > functions.
> >
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Kevin Hilman <khilman@kernel.org>
> > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Sudeep Holla <sudeep.holla@arm.com>
> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
> > ---
>
> [...]
>
> > +static int find_clusters(const struct cpumask *cpus,
> > + const struct cpumask **clusters)
> > +{
> > + unsigned int nb = 0;
> > + cpumask_var_t tmp;
> > +
> > + if (!alloc_cpumask_var(&tmp, GFP_KERNEL))
> > + return -ENOMEM;
> > + cpumask_copy(tmp, cpus);
> > +
> > + while (!cpumask_empty(tmp)) {
> > + const struct cpumask *cluster =
> > + topology_core_cpumask(cpumask_any(tmp));
> > +
> > + clusters[nb++] = cluster;
> > + cpumask_andnot(tmp, tmp, cluster);
> > + }
> > +
> > + free_cpumask_var(tmp);
> > + return nb;
> > +}
> > +
> > +/*
> > + * offlined_cpus is a temporary array but passing it as an argument avoids
> > + * multiple allocations.
> > + */
> > +static unsigned int down_and_up_cpus(const struct cpumask *cpus,
> > + struct cpumask *offlined_cpus)
> > +{
> > + int cpu;
> > + int err = 0;
> > +
> > + cpumask_clear(offlined_cpus);
> > +
> > + /* Try to power down all CPUs in the mask. */
> > + for_each_cpu(cpu, cpus) {
> > + int ret = cpu_down(cpu);
> > +
> > + /*
> > + * cpu_down() checks the number of online CPUs before the TOS
> > + * resident CPU.
> > + */
> > + if (cpumask_weight(offlined_cpus) + 1 == nb_available_cpus) {
> > + if (ret != -EBUSY) {
> > + pr_err("Unexpected return code %d while trying "
> > + "to power down last online CPU %d\n",
> > + ret, cpu);
> > + ++err;
> > + }
> > + } else if (cpu == tos_resident_cpu) {
> > + if (ret != -EPERM) {
> > + pr_err("Unexpected return code %d while trying "
> > + "to power down TOS resident CPU %d\n",
> > + ret, cpu);
> > + ++err;
> > + }
> > + } else if (ret != 0) {
> > + pr_err("Error occurred (%d) while trying "
> > + "to power down CPU %d\n", ret, cpu);
> > + ++err;
> > + }
> > +
> > + if (ret == 0)
> > + cpumask_set_cpu(cpu, offlined_cpus);
> > + }
> > +
> > + /* Try to power up all the CPUs that have been offlined. */
> > + for_each_cpu(cpu, offlined_cpus) {
> > + int ret = cpu_up(cpu);
> > +
> > + if (ret != 0) {
> > + pr_err("Error occurred (%d) while trying "
> > + "to power up CPU %d\n", ret, cpu);
> > + ++err;
> > + } else {
> > + cpumask_clear_cpu(cpu, offlined_cpus);
> > + }
> > + }
> > +
> > + /*
> > + * Something went bad at some point and some CPUs could not be turned
> > + * back on.
> > + */
> > + WARN_ON(!cpumask_empty(offlined_cpus) ||
> > + num_online_cpus() != nb_available_cpus);
> > +
> > + return err;
> > +}
> > +
> > +static int hotplug_tests(void)
> > +{
> > + int err;
> > + cpumask_var_t offlined_cpus;
> > + int i, nb_cluster;
> > + const struct cpumask **clusters;
> > + char *page_buf;
> > +
> > + err = -ENOMEM;
> > + if (!alloc_cpumask_var(&offlined_cpus, GFP_KERNEL))
> > + return err;
> > + /* We may have up to nb_available_cpus clusters. */
> > + clusters = kmalloc_array(nb_available_cpus, sizeof(*clusters),
> > + GFP_KERNEL);
> > + if (!clusters)
> > + goto out_free_cpus;
> > + page_buf = (char *)__get_free_page(GFP_KERNEL);
> > + if (!page_buf)
> > + goto out_free_clusters;
> > +
> > + err = 0;
> > + nb_cluster = find_clusters(cpu_online_mask, clusters);
> > +
> > + /*
> > + * Of course the last CPU cannot be powered down and cpu_down() should
> > + * refuse doing that.
> > + */
> > + pr_info("Trying to turn off and on again all CPUs\n");
> > + err += down_and_up_cpus(cpu_online_mask, offlined_cpus);
> > +
> > + /*
> > + * Take down CPUs by cluster this time. When the last CPU is turned
> > + * off, the cluster itself should shut down.
> > + */
> > + for (i = 0; i < nb_cluster; ++i) {
> > + int cluster_id =
> > + topology_physical_package_id(cpumask_any(clusters[i]));
> > + ssize_t len = cpumap_print_to_pagebuf(true, page_buf,
> > + clusters[i]);
> > + /* Remove trailing newline. */
> > + page_buf[len - 1] = '\0';
> > + pr_info("Trying to turn off and on again cluster %d "
> > + "(CPUs %s)\n", cluster_id, page_buf);
> > + err += down_and_up_cpus(clusters[i], offlined_cpus);
> > + }
> > +
> > + free_page((unsigned long)page_buf);
> > +out_free_clusters:
> > + kfree(clusters);
> > +out_free_cpus:
> > + free_cpumask_var(offlined_cpus);
> > + return err;
> > +}
> > +
> > +static void dummy_callback(unsigned long ignored) {}
> > +
> > +static int suspend_cpu(int index, bool broadcast)
> > +{
> > + int ret;
> > +
> > + arch_cpu_idle_enter();
> > +
> > + if (broadcast) {
> > + /*
> > + * The local timer will be shut down, we need to enter tick
> > + * broadcast.
> > + */
> > + ret = tick_broadcast_enter();
> > + if (ret) {
> > + /*
> > + * In the absence of hardware broadcast mechanism,
> > + * this CPU might be used to broadcast wakeups, which
> > + * may be why entering tick broadcast has failed.
> > + * There is little the kernel can do to work around
> > + * that, so enter WFI instead (idle state 0).
> > + */
> > + cpu_do_idle();
> > + ret = 0;
> > + goto out_arch_exit;
> > + }
> > + }
> > +
> > + /*
> > + * Replicate the common ARM cpuidle enter function
> > + * (arm_enter_idle_state).
> > + */
> > + ret = CPU_PM_CPU_IDLE_ENTER(arm_cpuidle_suspend, index);
> > +
> > + if (broadcast)
> > + tick_broadcast_exit();
> > +
> > +out_arch_exit:
> > + arch_cpu_idle_exit();
> > +
> > + return ret;
> > +}
> > +
> > +static int suspend_test_thread(void *arg)
> > +{
> > + int cpu = (long)arg;
> > + int i, nb_suspend = 0, nb_shallow_sleep = 0, nb_err = 0;
> > + struct sched_param sched_priority = { .sched_priority = MAX_RT_PRIO-1 };
> > + struct cpuidle_device *dev;
> > + struct cpuidle_driver *drv;
> > + /* No need for an actual callback, we just want to wake up the CPU. */
> > + struct timer_list wakeup_timer =
> > + TIMER_INITIALIZER(dummy_callback, 0, 0);
> > +
> > + /* Wait for the main thread to give the start signal. */
> > + wait_for_completion(&suspend_threads_started);
> > +
> > + /* Set maximum priority to preempt all other threads on this CPU. */
> > + if (sched_setscheduler_nocheck(current, SCHED_FIFO, &sched_priority))
> > + pr_warn("Failed to set suspend thread scheduler on CPU %d\n",
> > + cpu);
> > +
> > + dev = this_cpu_read(cpuidle_devices);
> > + drv = cpuidle_get_cpu_driver(dev);
> > +
> > + pr_info("CPU %d entering suspend cycles, states 1 through %d\n",
> > + cpu, drv->state_count - 1);
> > +
> > + for (i = 0; i < NUM_SUSPEND_CYCLE; ++i) {
> > + int index;
> > + /*
> > + * Test all possible states, except 0 (which is usually WFI and
> > + * doesn't use PSCI).
> > + */
> > + for (index = 1; index < drv->state_count; ++index) {
> > + struct cpuidle_state *state = &drv->states[index];
> > + bool broadcast = state->flags & CPUIDLE_FLAG_TIMER_STOP;
> > + int ret;
> > +
> > + /*
> > + * Set the timer to wake this CPU up in some time (which
> > + * should be largely sufficient for entering suspend).
> > + * If the local tick is disabled when entering suspend,
> > + * suspend_cpu() takes care of switching to a broadcast
> > + * tick, so the timer will still wake us up.
> > + */
> > + mod_timer(&wakeup_timer, jiffies +
> > + usecs_to_jiffies(state->target_residency));
> > +
> > + /* IRQs must be disabled during suspend operations. */
> > + local_irq_disable();
> > +
> > + ret = suspend_cpu(index, broadcast);
> > +
> > + /*
> > + * We have woken up. Re-enable IRQs to handle any
> > + * pending interrupt, do not wait until the end of the
> > + * loop.
> > + */
> > + local_irq_enable();
> > +
> > + if (ret == index) {
> > + ++nb_suspend;
> > + } else if (ret >= 0) {
> > + /* We did not enter the expected state. */
> > + ++nb_shallow_sleep;
> > + } else {
> > + pr_err("Failed to suspend CPU %d: error %d "
> > + "(requested state %d, cycle %d)\n",
> > + cpu, ret, index, i);
> > + ++nb_err;
> > + }
> > + }
> > + }
> > +
> > + /*
> > + * Disable the timer to make sure that the timer will not trigger
> > + * later.
> > + */
> > + del_timer(&wakeup_timer);
> > +
> > + if (atomic_dec_return_relaxed(&nb_active_threads) == 0)
> > + complete(&suspend_threads_done);
> > +
> > + /* Give up on RT scheduling and wait for termination. */
> > + sched_priority.sched_priority = 0;
> > + if (sched_setscheduler_nocheck(current, SCHED_NORMAL, &sched_priority))
> > + pr_warn("Failed to set suspend thread scheduler on CPU %d\n",
> > + cpu);
> > + for (;;) {
> > + /* Needs to be set first to avoid missing a wakeup. */
> > + set_current_state(TASK_INTERRUPTIBLE);
> > + if (kthread_should_stop()) {
> > + __set_current_state(TASK_RUNNING);
> > + break;
> > + }
> > + schedule();
> > + }
> > +
> > + pr_info("CPU %d suspend test results: success %d, shallow states %d, errors %d\n",
> > + cpu, nb_suspend, nb_shallow_sleep, nb_err);
> > +
> > + return nb_err;
> > +}
> > +
> > +static int suspend_tests(void)
> > +{
> > + int i, cpu, err = 0;
> > + struct task_struct **threads;
> > + int nb_threads = 0;
> > +
> > + threads = kmalloc_array(nb_available_cpus, sizeof(*threads),
> > + GFP_KERNEL);
> > + if (!threads)
> > + return -ENOMEM;
> > +
> > + for_each_online_cpu(cpu) {
> > + struct task_struct *thread;
> > + /* Check that cpuidle is available on that CPU. */
> > + struct cpuidle_device *dev = per_cpu(cpuidle_devices, cpu);
> > + struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
> > +
> > + if (cpuidle_not_available(drv, dev)) {
> > + pr_warn("cpuidle not available on CPU %d, ignoring\n",
> > + cpu);
> > + continue;
> > + }
> > +
> > + thread = kthread_create_on_cpu(suspend_test_thread,
> > + (void *)(long)cpu, cpu,
> > + "psci_suspend_test");
> > + if (IS_ERR(thread))
> > + pr_err("Failed to create kthread on CPU %d\n", cpu);
> > + else
> > + threads[nb_threads++] = thread;
> > + }
> > + if (nb_threads < 1) {
> > + kfree(threads);
> > + return -ENODEV;
> > + }
> > +
> > + atomic_set(&nb_active_threads, nb_threads);
> > +
> > + /*
> > + * Stop cpuidle to prevent the idle tasks from entering a deep sleep
> > + * mode, as it might interfere with the suspend threads on other CPUs.
> > + * This does not prevent the suspend threads from using cpuidle (only
> > + * the idle tasks check this status).
> > + */
> > + cpuidle_pause();
> > +
> > + /*
> > + * Wake up the suspend threads. To avoid the main thread being preempted
> > + * before all the threads have been unparked, the suspend threads will
> > + * wait for the completion of suspend_threads_started.
> > + */
> > + for (i = 0; i < nb_threads; ++i)
> > + wake_up_process(threads[i]);
> > + complete_all(&suspend_threads_started);
> > +
> > + wait_for_completion(&suspend_threads_done);
> > +
> > + cpuidle_resume();
> > +
> > + /* Stop and destroy all threads, get return status. */
> > + for (i = 0; i < nb_threads; ++i)
> > + err += kthread_stop(threads[i]);
> > +
> > + kfree(threads);
> > + return err;
> > +}
> > +
> > +static int __init psci_checker(void)
> > +{
> > + int ret;
> > +
> > + /*
> > + * Since we're in an initcall, we assume that all the CPUs that all
> > + * CPUs that can be onlined have been onlined.
> > + *
> > + * The tests assume that hotplug is enabled but nobody else is using it,
> > + * otherwise the results will be unpredictable. However, since there
> > + * is no userspace yet in initcalls, that should be fine.
>
> I do not think it is. If you run a kernel with, say,
> CONFIG_LOCK_TORTURE_TEST, cpus may disappear from the radar while
> running the PSCI checker test itself; that at least would confuse the
> checker, and that's just an example.
>
> I added Paul to check what are the assumptions behind the torture test
> hotplug tests, in particular if there are any implicit assumptions for
> it to work (ie it is the only kernel test hotplugging cpus in and out
> (?)), what I know is that the PSCI checker assumptions are not correct.
Both CONFIG_LOCK_TORTURE_TEST and CONFIG_RCU_TORTURE_TEST can and will
hotplug CPUs. The locktorture.onoff_holdoff and rcutorture.onoff_holdoff
kernel parameters can delay the start of CPU-hotplug testing, and in
my testing I set this delay to 30 seconds after boot.
One approach would be to make your test refuse to run if either of
the lock/RCU torture tests was running. Or do what Lorenzo suggests
below. The torture tests aren't crazy enough to offline the last CPU.
Though they do try, just for effect, in cases where the last CPU is
marked cpu_is_hotpluggable(). ;-)
Thanx, Paul
> There is something simple you can do to get this "fixed".
>
> You can use the new API James implemented for hibernate,
> that allows you to disable (ie PSCI CPU OFF) all "secondary" cpus
> other than the primary one passed in as parameter:
>
> freeze_secondary_cpus(int primary);
>
> that function will _cpu_down() all online cpus other than "primary"
> in one go, without any interference allowed from other bits of the
> kernel. It requires an enable_nonboot_cpus() counterpart, and you
> can do that for every online cpus you detect (actually you can even
> avoid using the online cpu mask and use the present mask to carry
> out the test). If there is a resident trusted OS you can just
> trigger the test with primary == tos_resident_cpu, since all
> others are bound to fail (well, you can run them and check they
> do fail, it is a checker after all).
>
> You would lose the capability of hotplugging a "cluster" at a time, but
> I do not think it is a big problem, the test above would cover it
> and more importantly, it is safe to execute.
>
> Or we can augment the torture test API to restrict the cpumask
> it actually uses to offline/online cpus (I am referring to
> torture_onoff(), kernel/torture.c).
>
> Further comments appreciated since I am not sure I grokked the
> assumption the torture tests make about hotplugging cpus in and out,
> I will go through the commits logs again to find more info.
>
> Thanks !
> Lorenzo
>
> > + */
> > + nb_available_cpus = num_online_cpus();
> > +
> > + /* Check PSCI operations are set up and working. */
> > + ret = psci_ops_check();
> > + if (ret)
> > + return ret;
> > +
> > + pr_info("PSCI checker started using %u CPUs\n", nb_available_cpus);
> > +
> > + pr_info("Starting hotplug tests\n");
> > + ret = hotplug_tests();
> > + if (ret == 0)
> > + pr_info("Hotplug tests passed OK\n");
> > + else if (ret > 0)
> > + pr_err("%d error(s) encountered in hotplug tests\n", ret);
> > + else {
> > + pr_err("Out of memory\n");
> > + return ret;
> > + }
> > +
> > + pr_info("Starting suspend tests (%d cycles per state)\n",
> > + NUM_SUSPEND_CYCLE);
> > + ret = suspend_tests();
> > + if (ret == 0)
> > + pr_info("Suspend tests passed OK\n");
> > + else if (ret > 0)
> > + pr_err("%d error(s) encountered in suspend tests\n", ret);
> > + else {
> > + switch (ret) {
> > + case -ENOMEM:
> > + pr_err("Out of memory\n");
> > + break;
> > + case -ENODEV:
> > + pr_warn("Could not start suspend tests on any CPU\n");
> > + break;
> > + }
> > + }
> > +
> > + pr_info("PSCI checker completed\n");
> > + return ret < 0 ? ret : 0;
> > +}
> > +late_initcall(psci_checker);
> > --
> > 2.10.0
> >
>
^ permalink raw reply
* [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
From: Matt Ranostay @ 2016-10-25 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024201443.GB5989@amd>
On Mon, Oct 24, 2016 at 1:14 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Mon 2016-10-24 12:58:25, Matt Ranostay wrote:
>> Pavel + Sebastian this is the patchset that need I some input on :)
>
> Better then previous one.
>
> But my version of bq27xxx_battery.c already contains this:
This is for allowing udev rule to set the properties as well.
otherwise a kinda crude RUN = " echo value >
/sys/module/bq27xxx_battery/parameters/poll_interval" is required.
>
> static const struct kernel_param_ops param_ops_poll_interval = {
> .get = param_get_uint,
> .set = poll_interval_param_set,
> };
>
> ...so it should be possible to set poll interval already.
>
> Pavel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem
From: Shuah Khan @ 2016-10-25 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <580F9D0D.7000104@math.uni-bielefeld.de>
On 10/25/2016 11:57 AM, Tobias Jakobi wrote:
> Hello Shuah,
>
>
> Shuah Khan wrote:
>> On 10/19/2016 04:27 PM, Shuah Khan wrote:
>>> On 10/19/2016 08:16 AM, Inki Dae wrote:
>>>> Hi Shuah,
>>>>
>>>> 2016-10-13 8:11 GMT+09:00 Shuah Khan <shuahkh@osg.samsung.com>:
>>>>> Hi Inki,
>>>>>
>>>>> On 08/15/2016 10:40 PM, Inki Dae wrote:
>>>>>
>>>>>>>
>>>>>>> okay the very first commit that added IOMMU support
>>>>>>> introduced the code that rejects non-contig gem memory
>>>>>>> type without IOMMU.
>>>>>>>
>>>>>>> commit 0519f9a12d0113caab78980c48a7902d2bd40c2c
>>>>>>> Author: Inki Dae <inki.dae@samsung.com>
>>>>>>> Date: Sat Oct 20 07:53:42 2012 -0700
>>>>>>>
>>>>>>> drm/exynos: add iommu support for exynos drm framework
>>>>>>>
>>>>>
>>>>> I haven't given up on this yet. I am still seeing the following failure:
>>>>>
>>>>> Additional debug messages I added:
>>>>> [ 15.287403] exynos_drm_gem_create_ioctl() 1
>>>>> [ 15.287419] exynos_drm_gem_create() flags 1
>>>>>
>>>>> [ 15.311511] [drm:exynos_drm_framebuffer_init] *ERROR* Non-contiguous GEM memory is not supported.
>>>>>
>>>>> Additional debug message I added:
>>>>> [ 15.318981] [drm:exynos_user_fb_create] *ERROR* failed to initialize framebuffer
>>>>>
>>>>> This is what happens:
>>>>>
>>>>> 1. exynos_drm_gem_create_ioctl() gets called with EXYNOS_BO_NONCONTIG request
>>>>> 2. exynos_drm_gem_create(0 goes ahead and creates the GEM buffers
>>>>> 3. exynos_user_fb_create() tries to associate GEM to fb and fails during
>>>>> check_fb_gem_memory_type()
>>>>>
>>>>> At this point, there is no recovery and lightdm fails
>>>>>
>>>>> xf86-video-armsoc/src/drmmode_exynos/drmmode_exynos.c assumes contiguous
>>>>> allocations are not supported in some exynos drm versions: The following
>>>>> commit introduced this change:
>>>>>
>>>>> https://git.linaro.org/arm/xorg/driver/xf86-video-armsoc.git/commitdiff/3be1f6273441fe95dd442f44064387322e16b7e9
>>>>>
>>>>> excerpts from the diff:- if (create_gem->buf_type == ARMSOC_BO_SCANOUT)
>>>>> - create_exynos.flags = EXYNOS_BO_CONTIG;
>>>>> - else
>>>>> - create_exynos.flags = EXYNOS_BO_NONCONTIG;
>>>>> +
>>>>> + /* Contiguous allocations are not supported in some exynos drm versions.
>>>>> + * When they are supported all allocations are effectively contiguous
>>>>> + * anyway, so for simplicity we always request non contiguous buffers.
>>>>> + */
>>>>> + create_exynos.flags = EXYNOS_BO_NONCONTIG;
>>>>>
>>>>
>>>> Above comment, "Contiguous allocations are not supported in some
>>>> exynos drm versions.", seems wrong assumption.
>>>> The root cause, contiguous allocation is not supported, would be that
>>>> they used Linux kernel which didn't have CMA region enough - as
>>>> default 16MB, or didn't declare CMA region enough for the DMA device.
>>>> So I think they should not force to flag EXYNOS_BO_NONCONTIG and they
>>>> should manage the error case if the allocation failed.
>>>
>>> This assumption doesn't sound correct and forcing NONCONTIG isn't right
>>> either.
>>>
>>>>
>>>>> There might have been logic on exynos_drm that forced Contig when it coudn't
>>>>> support NONCONTIG. At least, that is what this comment suggests. This assumption
>>>>> doesn't appear to be a good one and not sure if this change was made to fix a bug.
>>>>>
>>>>> After the IOMMU support, this assumption is no longer true. Hence, with IOMMU
>>>>> support, latest kernels have a mismatch with the installed xf86-video-armsoc
>>>>>
>>>>> This is what I am running into. This leads to the following question:
>>>>>
>>>>> 1. How do we ensure exynos_drm kernel changes don't break user-space
>>>>> specifically xf86-video-armsoc
>>>>> 2. This seems to have gone undetected for a while. I see a change in
>>>>> exynos_drm_gem_dumb_create() that is probably addressing this type
>>>>> of breakage. Commit 122beea84bb90236b1ae545f08267af58591c21b adds
>>>>> handling for IOMMU NONCONTIG case.
>>>>
>>>> Seems this patch has a problem. This patch forces to flag NONCONTIG if
>>>> iommu is enabled. The flag should be depend on the argument from
>>>> user-space.
>>>> I.e., if user-space requested a gem allocation with CONTIG flag, then
>>>> Exynos drm driver should allocate contiguous memory even though iommu
>>>> is enabled.
>>>>
>>>>>
>>>>> Anyway, I am interested in getting the exynos_drm kernel side code
>>>>> and xf86-video-armsoc in sync to resolve the issue.
>>>>>
>>>>> Could you recommend a going forward plan?
>>>>
>>>> My opinion are,
>>>>
>>>> 1. Do not force to flag EXYNOS_BO_NONCONTIG at xf86-video-armsoc
>>
>> Okay more on this. I fixed xf86-video-armso to ask for EXYNOS_BO_CONTIG
>> for ARMSOC_BO_SCANOUT and EXYNOS_BO_NONCONTIG in all other cases.
>>
>> Revert of the commit: 3be1f6273441fe95dd442f44064387322e16b7e9
>>
>> With this change, now display manager starts just fine. However, it turns
>> out xf86-video-armsoc is obsoleted in favor of xf86-video-modesetting. The
>> last update to xf86-video-armsoc git was 3 years ago.
> IIRC xf86-video-armsoc was created to facilitate integration with the
> proprietary Mali userspace blob. I don't think that can be done with the
> modesetting DDX.
>
>
>
>> I am not sure where to send the fix and doesn't look like it is being
>> maintained actively. I can pursue it further and try to get this into
>> xf86-video-armsoc provided I can find the maintainer for this seemingly
>> inactive project.
> I was wondering if anyone has actually complained about this issue?
I sent email to the last person that modified the xf86-video-armsoc.
I will pursue fix to this.
>
>
>
>> I brought in the latest xf86-video-modesetting bits from
>>
>> https://cgit.freedesktop.org/xorg/driver/xf86-video-modesetting
>>
>> I removed xf86-video-armsoc and installed xf86-video-modesetting and that
>> worked just fine. xf86-video-modesetting uses dumb_create interface instead
>> of DRM_IOCTL_EXYNOS_GEM_CREATE.
>>
>> dumb_create interface eliminates the need for DRM_IOCTL_EXYNOS_GEM_CREATE
>> in userspace. libdrm-2.4.71 does call DRM_IOCTL_EXYNOS_GEM_CREATE.
>>
>> The question is do we still need to continue to support the custom gem
>> create interface DRM_IOCTL_EXYNOS_GEM_CREATE?
> I'd say yes. With just the dumb_create interface it is not possible to
> change the type of buffer you get. And if you want to support any kind
> of hw acceleration in the DDX, you probably want to control at least the
> caching behaviour of the buffer.
Right. Okay that makes sense.
>
>
>
>> Some drm drivers seem to support it and some don't.
> Not sure I understand this. I don't think any other DRM driver except
> for exynos supports this ioctl. But all drivers have their own ioctls to
> request memory (DRM_IOCTL_ETNAVIV_GEM_NEW, DRM_IOCTL_VC4_CREATE_BO, etc.)
>
>
>
>> Unfortunately, if userspace requests noncontig
>> for scanout, we will continue to see problems with display manager when
>> iommu is disabled. dumb create hides all of that, are there good reasons
>> to continue to support it in exynos drm?
> In addition to the stuff I said above, you can use it for render nodes.
> That doesn't work for dumb_create.
>
>
>> Exposing CONTIG and NONCONTIG to userspace appears to be causing problems
>> when exynos drm determines it can't support non-contig GEM buffers in fb
>> init after userspace allocates them.
> Might be missing something here, but this whole thing just looks like a
> bug in xf86-video-armsoc. No matter from which perspective you look, the
> commit that changed all allocations to noncontig was plain wrong.
>
> My guess: This was done to paper over some bug in some vendor kernel for
> a product using an Exynos SoC.
>
Yeah. The right fix in this case is fixing xf86-video-armsoc as you explained
dump_create is too generic for some use-cases.
thanks,
-- Shuah
^ permalink raw reply
* [PATCH 3/3] ARM: dts: socfpga: Enable QSPI on the Cyclone5 sockit
From: Dinh Nguyen @ 2016-10-25 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5e0adad1-8ef2-029f-cfcd-4a07c962fda2@opensource.altera.com>
On 10/25/2016 10:38 AM, Graham Moore wrote:
> On 10/20/2016 09:12 AM, Dinh Nguyen wrote:
>>
>>
>> On 10/20/2016 02:19 AM, Steffen Trumtrar wrote:
>>
>>>> + cdns,tslch-ns = <4>;
>>>> +
>>>> + partition at qspi-boot {
>>>> + /* 8MB for raw data. */
>>>> + label = "Flash 0 Raw Data";
>>>> + reg = <0x0 0x800000>;
>>>> + };
>>>> +
>>>> + partition at qspi-rootfs {
>>>> + /* 120MB for jffs2 data. */
>>>> + label = "Flash 0 jffs2 Filesystem";
>>>> + reg = <0x800000 0x7800000>;
>>>> + };
>>>> + };
>>>> +};
>>>> +
>>>
>>> What is the current preferred way of handling the partitions?
>>> This doesn't fit my Sockit configuration for example. So I would always
>>> have to patch the devicetree.
>>
>> I'm not 100% sure on this. Graham, do you have any insight?
>>>
>
> Well, strictly speaking, these partitions are only for the socdk, the
> Altera dev kit. Our sample designs and file systems expect this layout.
>
> Therefore, these partitions are not required for any other dev kits, and
> can probably be left out.
>
> Or, Steffen, if you have a standard layout you'd like to see, then put
> that in there.
>
> I think some people will have to patch the layout regardless.
>
Ok, I'll remove the partitions from the none Altera boards.
Dinh
^ permalink raw reply
* Applied "ASoC: s3c24xx_uda134x: Move global variables to driver's data structure" to the asoc tree
From: Mark Brown @ 2016-10-25 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1470317928-25365-9-git-send-email-s.nawrocki@samsung.com>
The patch
ASoC: s3c24xx_uda134x: Move global variables to driver's data structure
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 892ccf0f2173a9ede5448411e9475616fb21fb51 Mon Sep 17 00:00:00 2001
From: Sylwester Nawrocki <s.nawrocki@samsung.com>
Date: Tue, 25 Oct 2016 12:57:57 +0200
Subject: [PATCH] ASoC: s3c24xx_uda134x: Move global variables to driver's data
structure
Gather all driver's private variables in common data structure
and allocate the data structure dynamically.
Also unused ENFORCE_RATES symbol and local variable (leftovers
from an erroneous rebase) are removed.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/samsung/s3c24xx_uda134x.c | 79 ++++++++++++++++++++-----------------
1 file changed, 43 insertions(+), 36 deletions(-)
diff --git a/sound/soc/samsung/s3c24xx_uda134x.c b/sound/soc/samsung/s3c24xx_uda134x.c
index 7853fbe6ccc9..81a78940967c 100644
--- a/sound/soc/samsung/s3c24xx_uda134x.c
+++ b/sound/soc/samsung/s3c24xx_uda134x.c
@@ -19,9 +19,15 @@
#include <sound/s3c24xx_uda134x.h>
#include "regs-iis.h"
-
#include "s3c24xx-i2s.h"
+struct s3c24xx_uda134x {
+ struct clk *xtal;
+ struct clk *pclk;
+ struct mutex clk_lock;
+ int clk_users;
+};
+
/* #define ENFORCE_RATES 1 */
/*
Unfortunately the S3C24XX in master mode has a limited capacity of
@@ -36,15 +42,6 @@
possible an error will be returned.
*/
-static struct clk *xtal;
-static struct clk *pclk;
-/* this is need because we don't have a place where to keep the
- * pointers to the clocks in each substream. We get the clocks only
- * when we are actually using them so we don't block stuff like
- * frequency change or oscillator power-off */
-static int clk_users;
-static DEFINE_MUTEX(clk_lock);
-
static unsigned int rates[33 * 2];
#ifdef ENFORCE_RATES
static struct snd_pcm_hw_constraint_list hw_constraints_rates = {
@@ -57,26 +54,24 @@ static struct snd_pcm_hw_constraint_list hw_constraints_rates = {
static int s3c24xx_uda134x_startup(struct snd_pcm_substream *substream)
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct s3c24xx_uda134x *priv = snd_soc_card_get_drvdata(rtd->card);
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
-#ifdef ENFORCE_RATES
- struct snd_pcm_runtime *runtime = substream->runtime;
-#endif
int ret = 0;
- mutex_lock(&clk_lock);
+ mutex_lock(&priv->clk_lock);
- if (clk_users == 0) {
- xtal = clk_get(rtd->dev, "xtal");
- if (IS_ERR(xtal)) {
+ if (priv->clk_users == 0) {
+ priv->xtal = clk_get(rtd->dev, "xtal");
+ if (IS_ERR(priv->xtal)) {
dev_err(rtd->dev, "%s cannot get xtal\n", __func__);
- ret = PTR_ERR(xtal);
+ ret = PTR_ERR(priv->xtal);
} else {
- pclk = clk_get(cpu_dai->dev, "iis");
- if (IS_ERR(pclk)) {
+ priv->pclk = clk_get(cpu_dai->dev, "iis");
+ if (IS_ERR(priv->pclk)) {
dev_err(rtd->dev, "%s cannot get pclk\n",
__func__);
- clk_put(xtal);
- ret = PTR_ERR(pclk);
+ clk_put(priv->xtal);
+ ret = PTR_ERR(priv->pclk);
}
}
if (!ret) {
@@ -85,18 +80,19 @@ static int s3c24xx_uda134x_startup(struct snd_pcm_substream *substream)
for (i = 0; i < 2; i++) {
int fs = i ? 256 : 384;
- rates[i*33] = clk_get_rate(xtal) / fs;
+ rates[i*33] = clk_get_rate(priv->xtal) / fs;
for (j = 1; j < 33; j++)
- rates[i*33 + j] = clk_get_rate(pclk) /
+ rates[i*33 + j] = clk_get_rate(priv->pclk) /
(j * fs);
}
}
}
- clk_users += 1;
- mutex_unlock(&clk_lock);
+ priv->clk_users += 1;
+ mutex_unlock(&priv->clk_lock);
+
if (!ret) {
#ifdef ENFORCE_RATES
- ret = snd_pcm_hw_constraint_list(runtime, 0,
+ ret = snd_pcm_hw_constraint_list(substream->runtime, 0,
SNDRV_PCM_HW_PARAM_RATE,
&hw_constraints_rates);
if (ret < 0)
@@ -109,15 +105,18 @@ static int s3c24xx_uda134x_startup(struct snd_pcm_substream *substream)
static void s3c24xx_uda134x_shutdown(struct snd_pcm_substream *substream)
{
- mutex_lock(&clk_lock);
- clk_users -= 1;
- if (clk_users == 0) {
- clk_put(xtal);
- xtal = NULL;
- clk_put(pclk);
- pclk = NULL;
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct s3c24xx_uda134x *priv = snd_soc_card_get_drvdata(rtd->card);
+
+ mutex_lock(&priv->clk_lock);
+ priv->clk_users -= 1;
+ if (priv->clk_users == 0) {
+ clk_put(priv->xtal);
+ priv->xtal = NULL;
+ clk_put(priv->pclk);
+ priv->pclk = NULL;
}
- mutex_unlock(&clk_lock);
+ mutex_unlock(&priv->clk_lock);
}
static int s3c24xx_uda134x_hw_params(struct snd_pcm_substream *substream,
@@ -228,10 +227,18 @@ static struct snd_soc_card snd_soc_s3c24xx_uda134x = {
static int s3c24xx_uda134x_probe(struct platform_device *pdev)
{
struct snd_soc_card *card = &snd_soc_s3c24xx_uda134x;
+ struct s3c24xx_uda134x *priv;
int ret;
- platform_set_drvdata(pdev, card);
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ mutex_init(&priv->clk_lock);
+
card->dev = &pdev->dev;
+ platform_set_drvdata(pdev, card);
+ snd_soc_card_set_drvdata(card, priv);
ret = devm_snd_soc_register_card(&pdev->dev, card);
if (ret)
--
2.8.1
^ permalink raw reply related
* [PATCH 4/4] ARM: dts: da850: Add the usb otg device node
From: David Lechner @ 2016-10-25 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477406345-27192-5-git-send-email-abailon@baylibre.com>
On 10/25/2016 09:39 AM, Alexandre Bailon wrote:
> This adds the device tree node for the usb otg
> controller present in the da850 family of SoC's.
> This also enables the otg usb controller for the lcdk board.
>
> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
> ---
> arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
> arch/arm/boot/dts/da850.dtsi | 15 +++++++++++++++
> 2 files changed, 23 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
> index 7b8ab21..dca9735 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -158,6 +158,14 @@
> rx-num-evt = <32>;
> };
>
> +&usb_phy {
> + status = "okay";
> + };
> +
> +&usb20 {
> + status = "okay";
> +};
> +
> &aemif {
> pinctrl-names = "default";
> pinctrl-0 = <&nand_pins>;
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index f79e1b9..b11d395 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -372,6 +372,21 @@
> >;
> status = "disabled";
> };
> + usb_phy: usb-phy {
> + compatible = "ti,da830-usb-phy";
> + #phy-cells = <1>;
> + status = "disabled";
> + };
> + usb20: usb20 at 200000 {
This should be usb0: usb at 200000
> + compatible = "ti,da830-musb";
> + reg = <0x200000 0x10000>;
> + interrupts = <58>;
> + interrupt-names = "mc";
> + dr_mode = "otg";
> + phys = <&usb_phy 0>;
> + phy-names = "usb-phy";
> + status = "disabled";
> + };
> gpio: gpio at 226000 {
> compatible = "ti,dm6441-gpio";
> gpio-controller;
>
^ permalink raw reply
* [PATCH 3/3] drivers: iommu: io-pgtable-arm: use const and __initconst for iommu_gather_ops structures
From: Julia Lawall @ 2016-10-25 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477418772-12184-4-git-send-email-bhumirks@gmail.com>
On Tue, 25 Oct 2016, Bhumika Goyal wrote:
> Check for iommu_gather_ops structures that are only stored in the tlb
> field of an io_pgtable_cfg structure. The tlb field is of type
> const struct iommu_gather_ops *, so iommu_gather_ops structures
> having this property can be declared as const. Also, replace __initdata
> with __initconst.
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
> ---
> drivers/iommu/io-pgtable-arm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index f5c90e1..412e21d 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -916,7 +916,7 @@ static void dummy_tlb_sync(void *cookie)
> WARN_ON(cookie != cfg_cookie);
> }
>
> -static struct iommu_gather_ops dummy_tlb_ops __initdata = {
> +static const struct iommu_gather_ops dummy_tlb_ops __initconst = {
> .tlb_flush_all = dummy_tlb_flush_all,
> .tlb_add_flush = dummy_tlb_add_flush,
> .tlb_sync = dummy_tlb_sync,
> --
> 1.9.1
>
>
^ permalink raw reply
* [PATCH 2/3] drivers: iommu: arm-smmu-v3: constify iommu_gather_ops structures
From: Julia Lawall @ 2016-10-25 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477418772-12184-3-git-send-email-bhumirks@gmail.com>
On Tue, 25 Oct 2016, Bhumika Goyal wrote:
> Check for iommu_gather_ops structures that are only stored in the tlb
> field of an io_pgtable_cfg structure. The tlb field is of type
> const struct iommu_gather_ops *, so iommu_gather_ops structures
> having this property can be declared as const.
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
> ---
> drivers/iommu/arm-smmu-v3.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> index 15c01c3..51d8be4 100644
> --- a/drivers/iommu/arm-smmu-v3.c
> +++ b/drivers/iommu/arm-smmu-v3.c
> @@ -1358,7 +1358,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
> } while (size -= granule);
> }
>
> -static struct iommu_gather_ops arm_smmu_gather_ops = {
> +static const struct iommu_gather_ops arm_smmu_gather_ops = {
> .tlb_flush_all = arm_smmu_tlb_inv_context,
> .tlb_add_flush = arm_smmu_tlb_inv_range_nosync,
> .tlb_sync = arm_smmu_tlb_sync,
> --
> 1.9.1
>
>
^ permalink raw reply
* [PATCH 1/3] drivers: iommu: arm-smmu: constify iommu_gather_ops structures
From: Julia Lawall @ 2016-10-25 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477418772-12184-2-git-send-email-bhumirks@gmail.com>
On Tue, 25 Oct 2016, Bhumika Goyal wrote:
> Check for iommu_gather_ops structures that are only stored in the tlb
> field of an io_pgtable_cfg structure. The tlb field is of type
> const struct iommu_gather_ops *, so iommu_gather_ops structures
> having this property can be declared as const.
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
> ---
> drivers/iommu/arm-smmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index c841eb7..a5bc8fb 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -640,7 +640,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
> }
> }
>
> -static struct iommu_gather_ops arm_smmu_gather_ops = {
> +static const struct iommu_gather_ops arm_smmu_gather_ops = {
> .tlb_flush_all = arm_smmu_tlb_inv_context,
> .tlb_add_flush = arm_smmu_tlb_inv_range_nosync,
> .tlb_sync = arm_smmu_tlb_sync,
> --
> 1.9.1
>
>
^ permalink raw reply
* [RFC v2] ARM: memory: da8xx-ddrctl: new driver
From: Kevin Hilman @ 2016-10-25 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hy41ctipa.fsf@baylibre.com>
Kevin Hilman <khilman@baylibre.com> writes:
> 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>
>> ---
>> .../memory-controllers/ti-da8xx-ddrctl.txt | 20 +++
>> drivers/memory/Kconfig | 8 +
>> drivers/memory/Makefile | 1 +
>> drivers/memory/da8xx-ddrctl.c | 175 +++++++++++++++++++++
>> 4 files changed, 204 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..7e271dd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
>> @@ -0,0 +1,20 @@
>> +* Device tree bindings for Texas Instruments da8xx DDR2/mDDR memory controller
>> +
>> +The DDR2/mDDR memory controller present on Texas Instruments da8xx SoCs features
>> +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-ddr-controller" - for da850 SoC based boards
>> +- reg: a tuple containing the base address of the memory
>> + controller and the size of the memory area to map
>> +
>> +Example for da850 shown below.
>> +
>> +ddrctl {
>> + compatible = "ti,da850-ddr-controller";
>> + reg = <0xB0000000 0x100>;
>> +};
>
> Axel's series for the USB PHY reminded me that the PHY also has some
> config registers in this same area, and his series creates a syscon for
> a similar range of registers.
>
> Could you create a syscon for the SYSCFG0 registers, which would then
> be used by ths driver and your other drivers/bus driver? Then the
> binding would just reference the sysconf via phandle, and your driver
> can use syscon_regmap_lookup_by_phandle()
Nevermind. I though that the config register in this driver was also in
SYSCFG0, but I see now that it's in the reg region of the DDR controller
itself, so no syscon is needed.
Kevin
^ permalink raw reply
* [PATCH v2 3/4] clk: imx31: fix rewritten input argument of mx31_clocks_init()
From: Stephen Boyd @ 2016-10-25 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474848223-19728-4-git-send-email-vz@mleia.com>
On 09/26, Vladimir Zapolskiy wrote:
> Function mx31_clocks_init() is called during clock intialization on
> legacy boards with reference clock frequency passed as its input
> argument, this can be verified by examination of the function
> declaration found in arch/arm/mach-imx/common.h and actual function
> users which include that header file.
>
> Inside CCF driver the function ignores its input argument, by chance
> the used value in the function body is the same as input arguments on
> side of all callers.
>
> Fixes: d9388c843237 ("clk: imx31: Do not call mxc_timer_init twice when booting with DT")
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> ---
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 4/4] ARM: clk: imx31: properly init clocks for machines with DT
From: Stephen Boyd @ 2016-10-25 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474848223-19728-5-git-send-email-vz@mleia.com>
On 09/26, Vladimir Zapolskiy wrote:
> Clock initialization for i.MX31 powered machines with DT support
> should be done by a call of an init function registered with
> CLK_OF_DECLARE() in common clock framework.
>
> The change converts exported mx31_clocks_init_dt() into a static
> initialization function registered by CLK_OF_DECLARE().
>
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> ---
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 0/4] ARM: imx31: clock initialization fixes
From: Stephen Boyd @ 2016-10-25 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161023122844.GR30578@tiger>
On 10/23, Shawn Guo wrote:
> On Mon, Sep 26, 2016 at 03:03:39AM +0300, Vladimir Zapolskiy wrote:
> > The change is tested on qemu kzm target and mx31lite board, while both
> > targets don't have DTS in upstream, I had to write simple DTS files for
> > them, because the proposed change is for i.MX31 targets with OF support.
> >
> > i.MX31/OF/clock initialization seems to be broken currently, if
> > the series is not applied I can not get a working clock source during
> > early boot stage on a board with DTB supplied.
> >
> > Changes from v1 to v2, thanks to Uwe and Stephen for review:
> > * added one more new fix in imx31.dtsi which moves CCM device node
> > to AIPS2 bus,
> > * included to the series a fix of CCM interrupts in imx31.dtsi,
> > the change was sent as a separate patch, the change is included
> > to avoid a patch application dependency,
> > * as suggested by Uwe reworded one of the commits removing "stack
> > corruption" mentioning, the overwritten value is passed in a register,
> > * as suggested by Uwe squashed clk-imx31.c and imx31-dt.c changes
> > to avoid a runtime problem if only one of two patches are applied
> >
> > Vladimir Zapolskiy (4):
> > ARM: dts: imx31: fix clock control module interrupts description
> > ARM: dts: imx31: move CCM device node to AIPS2 bus devices
> > clk: imx31: fix rewritten input argument of mx31_clocks_init()
> > ARM: clk: imx31: properly init clocks for machines with DT
> >
> > .../devicetree/bindings/clock/imx31-clock.txt | 2 +-
> > arch/arm/boot/dts/imx31.dtsi | 14 +++---
> > arch/arm/mach-imx/common.h | 1 -
> > arch/arm/mach-imx/imx31-dt.c | 6 ---
> > drivers/clk/imx/clk-imx31.c | 52 +++++++++++-----------
>
> Hi Stephen,
>
> Can I have you ACK on the clk file, so that we can merge the series from
> arm-soc tree? Thanks.
>
Done.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ 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