* [PATCH] drm/sun4i: Only count TCON endpoints as valid outputs
From: Chen-Yu Tsai @ 2016-11-16 9:37 UTC (permalink / raw)
To: linux-arm-kernel
The sun4i DRM driver counts the number of endpoints it found and
registers the whole DRM pipeline if any endpoints are found.
However, if the TCON and its child endpoints (LCD panels, TV encoder,
HDMI encoder, MIPI DSI encoder, etc.) aren't found, that means we
don't have any usable CRTCs, and the display pipeline is incomplete
and useless. The whole DRM display pipeline should only be registered
and enabled if there are proper outputs available.
The debug message "Queued %d outputs on pipeline %d\n" is also telling.
This patch makes the driver only count enabled TCON endpoints. If
none are found, the DRM pipeline is not used. This avoids screwing
up the simple framebuffer provided by the bootloader in cases where
we aren't able to support the display with the DRM subsystem, due
to lack of panel or bridge drivers, or just lack of progress.
Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
Hi Maxime,
This avoids DRM screwing up simplefb on my SinA31s, which does not
have the display pipeline enabled in its dts file. But the display
engine and backend are already enabled in the dtsi.
I think this is a better and proper (for the driver) fix. The
alternative would be to disable the display-engine node in the dts
by default. Last time I asked you wanted to have them enabled by
default?
It may also be possible to push the check further down, and check
against panel and encoder endpoints, but I think that complicates
things. The TCON is a necessary part of the output.
ChenYu
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index c3b21865443e..3603f34901b6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -243,9 +243,12 @@ static int sun4i_drv_add_endpoints(struct device *dev,
DRM_DEBUG_DRIVER("Adding component %s\n",
of_node_full_name(node));
component_match_add(dev, match, compare_of, node);
- count++;
}
+ /* Only count the tcon as an output */
+ if (sun4i_drv_node_is_tcon(node))
+ count++;
+
/* Inputs are listed first, then outputs */
port = of_graph_get_port_by_id(node, 1);
if (!port) {
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/3] soc: rockchip: add driver handling grf setup
From: Shawn Lin @ 2016-11-16 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115223900.30728-3-heiko@sntech.de>
? 2016/11/16 6:38, Heiko Stuebner ??:
> The General Register Files are an area of registers containing a lot
> of single-bit settings for numerous components as well full components
> like usbphy control. Therefore all used components are accessed
> via the syscon provided by the grf nodes or from the sub-devices
> created through the simple-mfd created from the grf node.
>
> Some settings are not used by anything but will need to be set up
> according to expectations on the kernel side.
>
> Best example is the force_jtag setting, which defaults to on and
> results in the soc switching the pin-outputs between jtag and sdmmc
> automatically depending on the card-detect status. This conflicts
> heavily with how the dw_mmc driver expects to do its work and also
> with the clock-controller, which has most likely deactivated the
> jtag clock due to it being unused.
I hate force_jtag personally... :)
>
> So far the handling of this setting was living in the mach-rockchip
> code for the arm32-based rk3288 but that of course doesn't work
> for arm64 socs and would also look ugly for further arm32 socs.
yes, I did this inside the loader.... when running arm64
>
> Also always disabling this setting is quite specific to linux and
> its subsystems, other operating systems might prefer other settings,
> so that the bootloader cannot really set a sane default for all.
>
> So introduce a top-level driver for the grf that handles these
> settings that need to be a certain way but nobody cares about.
>
> Other needed settings might surface in the future and can then
> be added here, but only as a last option. Ideally general GRF
> settings should be handled in the driver needing them.
>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> drivers/soc/rockchip/Kconfig | 10 ++++
> drivers/soc/rockchip/Makefile | 1 +
> drivers/soc/rockchip/grf.c | 134 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 145 insertions(+)
> create mode 100644 drivers/soc/rockchip/grf.c
>
> diff --git a/drivers/soc/rockchip/Kconfig b/drivers/soc/rockchip/Kconfig
> index 7140ff8..20da55d 100644
> --- a/drivers/soc/rockchip/Kconfig
> +++ b/drivers/soc/rockchip/Kconfig
> @@ -3,6 +3,16 @@ if ARCH_ROCKCHIP || COMPILE_TEST
> #
> # Rockchip Soc drivers
> #
> +
> +config ROCKCHIP_GRF
> + bool
> + default y
> + help
> + The General Register Files are a central component providing
> + special additional settings registers for a lot of soc-components.
> + In a lot of cases there also need to be default settings initialized
> + to make some of them conform to expectations of the kernel.
> +
> config ROCKCHIP_PM_DOMAINS
> bool "Rockchip generic power domain"
> depends on PM
> diff --git a/drivers/soc/rockchip/Makefile b/drivers/soc/rockchip/Makefile
> index 3d73d06..c851fa0 100644
> --- a/drivers/soc/rockchip/Makefile
> +++ b/drivers/soc/rockchip/Makefile
> @@ -1,4 +1,5 @@
> #
> # Rockchip Soc drivers
> #
> +obj-$(CONFIG_ROCKCHIP_GRF) += grf.o
> obj-$(CONFIG_ROCKCHIP_PM_DOMAINS) += pm_domains.o
> diff --git a/drivers/soc/rockchip/grf.c b/drivers/soc/rockchip/grf.c
> new file mode 100644
> index 0000000..0c85476a
> --- /dev/null
> +++ b/drivers/soc/rockchip/grf.c
> @@ -0,0 +1,134 @@
> +/*
> + * Rockchip Generic Register Files setup
> + *
> + * Copyright (c) 2016 Heiko Stuebner <heiko@sntech.de>
> + *
> + * 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/err.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
The order :)
> +
> +#define HIWORD_UPDATE(val, mask, shift) \
> + ((val) << (shift) | (mask) << ((shift) + 16))
> +
> +struct rockchip_grf_value {
> + const char *desc;
> + u32 reg;
> + u32 val;
> +};
> +
> +struct rockchip_grf_info {
> + const struct rockchip_grf_value *values;
> + int num_values;
> +};
> +
> +#define RK3036_GRF_SOC_CON0 0x140
> +
> +static const struct rockchip_grf_value rk3036_defaults[] __initconst = {
> + /*
> + * Disable auto jtag/sdmmc switching that causes issues with the
> + * clock-framework and the mmc controllers making them unreliable.
> + */
> + { "jtag switching", RK3036_GRF_SOC_CON0, HIWORD_UPDATE(0, 1, 11) },
> +};
> +
> +static const struct rockchip_grf_info rk3036_grf __initconst = {
> + .values = rk3036_defaults,
> + .num_values = ARRAY_SIZE(rk3036_defaults),
> +};
> +
> +#define RK3288_GRF_SOC_CON0 0x244
> +
> +static const struct rockchip_grf_value rk3288_defaults[] __initconst = {
> + { "jtag switching", RK3288_GRF_SOC_CON0, HIWORD_UPDATE(0, 1, 12) },
> +};
> +
> +static const struct rockchip_grf_info rk3288_grf __initconst = {
> + .values = rk3288_defaults,
> + .num_values = ARRAY_SIZE(rk3288_defaults),
> +};
> +
> +#define RK3368_GRF_SOC_CON15 0x43c
> +
> +static const struct rockchip_grf_value rk3368_defaults[] __initconst = {
> + { "jtag switching", RK3368_GRF_SOC_CON15, HIWORD_UPDATE(0, 1, 13) },
> +};
> +
> +static const struct rockchip_grf_info rk3368_grf __initconst = {
> + .values = rk3368_defaults,
> + .num_values = ARRAY_SIZE(rk3368_defaults),
> +};
> +
> +#define RK3399_GRF_SOC_CON7 0xe21c
> +
> +static const struct rockchip_grf_value rk3399_defaults[] __initconst = {
> + { "jtag switching", RK3399_GRF_SOC_CON7, HIWORD_UPDATE(0, 1, 12) },
> +};
> +
> +static const struct rockchip_grf_info rk3399_grf __initconst = {
> + .values = rk3399_defaults,
> + .num_values = ARRAY_SIZE(rk3399_defaults),
> +};
> +
> +static const struct of_device_id rockchip_grf_dt_match[] __initconst = {
> + {
> + .compatible = "rockchip,rk3036-grf",
> + .data = (void *)&rk3036_grf,
> + }, {
> + .compatible = "rockchip,rk3288-grf",
> + .data = (void *)&rk3288_grf,
> + }, {
> + .compatible = "rockchip,rk3368-grf",
> + .data = (void *)&rk3368_grf,
> + }, {
> + .compatible = "rockchip,rk3399-grf",
> + .data = (void *)&rk3399_grf,
> + },
> + { /* sentinel */ },
> +};
> +
> +static int __init rockchip_grf_init(void)
> +{
> + const struct rockchip_grf_info *grf_info;
> + const struct of_device_id *match;
> + struct device_node *np;
> + struct regmap *grf;
> + int ret, i;
> +
> + np = of_find_matching_node_and_match(NULL, rockchip_grf_dt_match, &match);
> + if (!np)
> + return -ENODEV;
> + if (!match || !match->data) {
> + pr_err("%s: missing grf data\n", __func__);
> + return -EINVAL;
> + }
> +
> + grf_info = match->data;
> +
> + grf = syscon_node_to_regmap(np);
> + if (IS_ERR(grf)) {
> + pr_err("%s: could not get grf syscon\n", __func__);
> + return PTR_ERR(grf);
> + }
> +
> + for (i = 0; i < grf_info->num_values; i++) {
> + const struct rockchip_grf_value *val = &grf_info->values[i];
> +
> + pr_debug("%s: adjusting %s in %#6x to %#10x\n", __func__,
> + val->desc, val->reg, val->val);
> + ret = regmap_write(grf, val->reg, val->val);
> + if (ret < 0)
> + pr_err("%s: write to %#6x failed with %d\n",
> + __func__, val->reg, ret);
So, when failing to do one of the settings, should we still let it goes?
Sometimes the log of postcore_initcall is easy to be neglected when
people finally find problems later but the very earlier log was missing
due to whatever reason like buffer limitation, etc.
> + }
> +
> + return 0;
> +}
> +postcore_initcall(rockchip_grf_init);
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* [PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support
From: Wei Xu @ 2016-11-16 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e78a288b-8bab-9441-2edb-6ec08e5103d7@hisilicon.com>
Hi Pan,
On 2016/11/16 8:56, wenpan wrote:
> Hi Marty?
> Does this confict with your patch? If not?I hope this could be merged first. Besides could you tell me the link to your related patch?
This is the link: https://patchwork.kernel.org/patch/9334743/
BR,
Wei
>
> Thanks,
> Pan
>
> On 2016/10/17 21:48, Arnd Bergmann wrote:
>> On Monday, October 17, 2016 8:07:03 PM CEST Pan Wen wrote:
>>> Add support for some HiSilicon SoCs which depend on ARCH_MULTI_V5.
>>>
>>> Signed-off-by: Pan Wen <wenpan@hisilicon.com>
>>>
>>
>> Looks ok. I've added Marty Plummer to Cc, he was recently proposing
>> patches for Hi3520, which I think is closely related to this one.
>> Please try to work together so the patches don't conflict. It should
>> be fairly straightforward since you are basically doing the same
>> change here.
>>
>> Arnd
>>
>> .
>>
>
>
> .
>
^ permalink raw reply
* [PATCH] ARM64: dma-mapping: preallocate DMA-debug hash tables in core_initcall
From: Marek Szyprowski @ 2016-11-16 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20161116092025eucas1p2ebaf3ead7de79130ca2656d532284e5b@eucas1p2.samsung.com>
fs_initcall is definitely too late to initialize DMA-debug hash tables,
because some drivers might get probed and use DMA mapping framework
already in core_initcall. Late initialization of DMA-debug results in
false warning about accessing memory, that was not allocated. This issue
has been observed on ARM 32bit, but the same driver can be used also on
ARM64.
This patch moves initialization of DMA-debug to core_initcall. This is
safe from the initialization perspective. dma_debug_do_init() internally
calls debugfs functions and debugfs also gets initialised at
core_initcall(), and that is earlier than arch code in the link order,
so it will get initialized just before the DMA-debug.
Reported-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
For more details on this issue, see the patch for ARM 32bit arch:
https://www.spinics.net/lists/arm-kernel/msg542721.html
https://www.spinics.net/lists/arm-kernel/msg542782.html
---
arch/arm64/mm/dma-mapping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 3f74d0d..8653426 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -538,7 +538,7 @@ static int __init dma_debug_do_init(void)
dma_debug_init(PREALLOC_DMA_DEBUG_ENTRIES);
return 0;
}
-fs_initcall(dma_debug_do_init);
+core_initcall(dma_debug_do_init);
#ifdef CONFIG_IOMMU_DMA
--
1.9.1
^ permalink raw reply related
* [PATCH] ARM: davinci_all_defconfig: add missing options for systemd
From: Sekhar Nori @ 2016-11-16 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hshqt6fyo.fsf@baylibre.com>
On Tuesday 15 November 2016 12:34 AM, Kevin Hilman wrote:
> Sekhar Nori <nsekhar@ti.com> writes:
>
>> Some kernel configuration options required for systemd
>> support are missing in davinci_all_defconfig. Add them.
>>
>> This is based on recommendations in:
>>
>> http://cgit.freedesktop.org/systemd/systemd/tree/README
>>
>> Options which kernel enables by default (and will thus be removed
>> upon next savedefconfig update) are not included.
>>
>> Tested on OMAP-L138 LCDK board with fully up to date armv5
>> archlinux filesystem.
>>
>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>
> Acked-by: Kevin Hilman <khilman@baylibre.com>
Applied to v4.10/defconfig
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: Sekhar Nori @ 2016-11-16 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479207611-18028-1-git-send-email-bgolaszewski@baylibre.com>
On Tuesday 15 November 2016 04:30 PM, Bartosz Golaszewski wrote:
> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
> controller drivers to da850.dtsi.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Applied to v4.10/dt
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 3/3] ARM: davinci: PM: support da8xx DT platforms
From: Sekhar Nori @ 2016-11-16 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115195421.19983-4-khilman@baylibre.com>
On Wednesday 16 November 2016 01:24 AM, Kevin Hilman wrote:
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Added a one line description which is essentially a copy of subject line.
Applied to v4.10/soc
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 2/3] ARM: davinci: PM: cleanup: remove references to pdata
From: Sekhar Nori @ 2016-11-16 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115195421.19983-3-khilman@baylibre.com>
On Wednesday 16 November 2016 01:24 AM, Kevin Hilman wrote:
> Since the PM core code is no longer using a fake platform_device or
> platform_data, remove references to 'pdata'.
>
> No functional changes.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Applied to v4.10/cleanup
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 1/3] ARM: davinci: PM: rework init, support DT platforms
From: Sekhar Nori @ 2016-11-16 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115195421.19983-2-khilman@baylibre.com>
On Wednesday 16 November 2016 01:24 AM, Kevin Hilman wrote:
> Remove fake platform device used for PM init. Move pdata values which
> are common across all current platforms into pm.c.
>
> Also, since PM is only used on da8xx, remove davinci_pm_init() from
> common init code, and only use in da850/omapl138 board files that are
> currently creating the fake platform_device.
>
> Suggested-by: Sekhar Nori <nsekhar@ti.com>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
> index 8929569b1f8a..3f1fb191c03f 100644
> --- a/arch/arm/mach-davinci/pm.c
> +++ b/arch/arm/mach-davinci/pm.c
> @@ -21,15 +21,23 @@
>
> #include <mach/common.h>
> #include <mach/da8xx.h>
> -#include "sram.h"
> +#include <mach/mux.h>
> #include <mach/pm.h>
>
> #include "clock.h"
> +#include "psc.h"
> +#include "sram.h"
>
> +#define DA850_PLL1_BASE 0x01e1a000
> #define DEEPSLEEP_SLEEPCOUNT_MASK 0xFFFF
> +#define DEEPSLEEP_SLEEPCOUNT 128
>
> static void (*davinci_sram_suspend) (struct davinci_pm_config *);
> -static struct davinci_pm_config *pdata;
> +static struct davinci_pm_config pm_config = {
> + .sleepcount = DEEPSLEEP_SLEEPCOUNT,
> + .ddrpsc_num = DA8XX_LPSC1_EMIF3C,
> +};
I added an empty line here while applying. This was pointed to by
checkpatch --strict
> +static struct davinci_pm_config *pdata = &pm_config;
And also adjusted the subject line since there is no DT support being
added in this patch anymore. New subject line:
ARM: davinci: PM: rework init, remove platform device
Applied to v4.10/cleanup
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 1/3] arm: hisi: add ARCH_MULTI_V5 support
From: wenpan @ 2016-11-16 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5893354.6MrIxqzRoI@wuerfel>
Hi Martyo<
Does this confict with your patcho<\x1f If noto<
I hope this could be merged first. Besides could you tell me the link to your related patch?
Thanks,
Pan
On 2016/10/17 21:48, Arnd Bergmann wrote:
> On Monday, October 17, 2016 8:07:03 PM CEST Pan Wen wrote:
>> Add support for some HiSilicon SoCs which depend on ARCH_MULTI_V5.
>>
>> Signed-off-by: Pan Wen <wenpan@hisilicon.com>
>>
>
> Looks ok. I've added Marty Plummer to Cc, he was recently proposing
> patches for Hi3520, which I think is closely related to this one.
> Please try to work together so the patches don't conflict. It should
> be fairly straightforward since you are basically doing the same
> change here.
>
> Arnd
>
> .
>
^ permalink raw reply
* [2/2] dmaengine: at_xdmac: fix spurious flag status for mem2mem transfers
From: Nicolas Ferre @ 2016-11-16 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7fbfd098-31d8-d184-37a9-8865fdb7fb8d@denx.de>
Le 28/10/2016 ? 23:57, Marek Vasut a ?crit :
> Hi,
>
> this patch [1] should also CC stable, since it fixes MMC operation in at
> least linux 4.4 .
>
> Thanks!
>
> [1] https://patchwork.kernel.org/patch/7681201/
I did that (without putting you in copy: sorry).
https://www.spinics.net/lists/stable/msg151272.html
Thanks a lot for the heads-up Marek!
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] ARM: zynq: Fix pmu register description coding style
From: Michal Simek @ 2016-11-16 8:32 UTC (permalink / raw)
To: linux-arm-kernel
Drop the space before/after '<' and '>'; and
separate the entries to be a bit more readable.
Reported-by: Julia Cartwright <julia@ni.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
arch/arm/boot/dts/zynq-7000.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 402b5bbe3b5b..f3ac9bfe580e 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -46,7 +46,8 @@
compatible = "arm,cortex-a9-pmu";
interrupts = <0 5 4>, <0 6 4>;
interrupt-parent = <&intc>;
- reg = < 0xf8891000 0x1000 0xf8893000 0x1000 >;
+ reg = <0xf8891000 0x1000>,
+ <0xf8893000 0x1000>;
};
regulator_vccpint: fixedregulator {
--
1.9.1
^ permalink raw reply related
* [linux-sunxi] Re: [PATCH v3 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply
From: Archit Taneja @ 2016-11-16 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67LR4KEb0tfGkT8+TqTauNyCMq1n6mRdXsa6TUJV0xncA@mail.gmail.com>
Hi,
On 11/15/2016 08:29 AM, Chen-Yu Tsai wrote:
> Hi,
>
> On Wed, Nov 2, 2016 at 9:33 AM, Chen-Yu Tsai <wens@csie.org> wrote:
>> On Mon, Oct 31, 2016 at 2:28 PM, Rob Herring <robh@kernel.org> wrote:
>>> On Sat, Oct 29, 2016 at 07:06:10PM +0800, Chen-Yu Tsai wrote:
>>>> Some dumb VGA DACs are active components which require external power.
>>>> Add support for specifying a regulator as its power supply.
>>>>
>>>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>>>> ---
>>>> .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
>>>
>>> For the binding,
>>>
>>> Acked-by: Rob Herring <robh@kernel.org>
>
> Any comments on this patch from the DRM people?
A comment below.
>
> ChenYu
>
>>>
>>> One code comment below...
>>>
>>>> drivers/gpu/drm/bridge/dumb-vga-dac.c | 35 ++++++++++++++++++++++
>>>> 2 files changed, 37 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>>> index 003bc246a270..164cbb15f04c 100644
>>>> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>>> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>>>> @@ -16,6 +16,8 @@ graph bindings specified in Documentation/devicetree/bindings/graph.txt.
>>>> - Video port 0 for RGB input
>>>> - Video port 1 for VGA output
>>>>
>>>> +Optional properties:
>>>> +- vdd-supply: Power supply for DAC
>>>>
>>>> Example
>>>> -------
>>>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>>> index afec232185a7..59781e031220 100644
>>>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>>>> @@ -12,6 +12,7 @@
>>>>
>>>> #include <linux/module.h>
>>>> #include <linux/of_graph.h>
>>>> +#include <linux/regulator/consumer.h>
>>>>
>>>> #include <drm/drmP.h>
>>>> #include <drm/drm_atomic_helper.h>
>>>> @@ -23,6 +24,7 @@ struct dumb_vga {
>>>> struct drm_connector connector;
>>>>
>>>> struct i2c_adapter *ddc;
>>>> + struct regulator *vdd;
>>>> };
>>>>
>>>> static inline struct dumb_vga *
>>>> @@ -124,8 +126,33 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>>>> return 0;
>>>> }
>>>>
>>>> +static void dumb_vga_enable(struct drm_bridge *bridge)
>>>> +{
>>>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>>>> + int ret;
>>>> +
>>>> + if (!IS_ERR(vga->vdd)) {
>>>
>>> if (IS_ERR())
>>> return;
>>>
>>> ...will save some intentation.
>>
>> I thought about that, though if someone were to add more stuff to
>> this, such as an enable GPIO, they might have to rework it. A standalone
>> block of code would be easier to work with. I'm OK either way though.
>>
>> ChenYu
>>
>>>
>>>> + ret = regulator_enable(vga->vdd);
>>>> +
>>>> + if (ret) {
>>>> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
>>>> + return;
>>>> + }
>>>> + }
>>>> +}
>>>> +
>>>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>>>> +{
>>>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>>>> +
>>>> + if (!IS_ERR(vga->vdd))
>>>> + regulator_disable(vga->vdd);
>>>> +}
>>>> +
>>>> static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>>>> .attach = dumb_vga_attach,
>>>> + .enable = dumb_vga_enable,
>>>> + .disable = dumb_vga_disable,
>>>> };
>>>>
>>>> static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>>>> @@ -169,6 +196,14 @@ static int dumb_vga_probe(struct platform_device *pdev)
>>>> return -ENOMEM;
>>>> platform_set_drvdata(pdev, vga);
>>>>
>>>> + vga->vdd = devm_regulator_get_optional(&pdev->dev, "vdd");
>>>> + if (IS_ERR(vga->vdd)) {
>>>> + ret = PTR_ERR(vga->vdd);
>>>> + if (ret == -EPROBE_DEFER)
>>>> + return -EPROBE_DEFER;
>>>> + dev_dbg(&pdev->dev, "No vdd regulator found: %d\n", ret);
A cleaner way would be to set vga->vdd to NULL here, and do:
int ret = 0;
if (vga->vdd)
ret = regulator_enable(vga->vdd);
if (ret) {
...
return;
}
/* if a gpio is added later */
if (vga->gpio)
ret = gpiod_set_value_cansleep(vga->gpio, 1);
if (ret) {
...
return;
}
...
We don't really care what error code is contained in vga->vdd once we have
identified whether we got a regulator or not.
The same thing can be done for ddc too, but that can done left for later.
If you're okay with the suggestion, can you re-spin a patch?
Thanks,
Archit
>>>> + }
>>>> +
>>>> vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
>>>> if (IS_ERR(vga->ddc)) {
>>>> if (PTR_ERR(vga->ddc) == -ENODEV) {
>>>> --
>>>> 2.9.3
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [upstream-release] [PATCH 1/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
From: Scott Wood @ 2016-11-16 7:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB5PR0401MB1925FB1FE45C15B0671E46D1F5BF0@DB5PR0401MB1925.eurprd04.prod.outlook.com>
On 11/15/2016 06:39 AM, Sriram Dash wrote:
>> From: Scott Wood
>> On 11/13/2016 11:27 PM, Sriram Dash wrote:
>>> diff --git a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>>> b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>>> new file mode 100644
>>> index 0000000..d934c80
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>>> @@ -0,0 +1,36 @@
>>> +Driver for Freescale USB 3.0 PHY
>>> +
>>> +Required properties:
>>> +
>>> +- compatible : fsl,qoriq-usb3-phy
>>
>
> Hi Scott,
>
>> This is a very vague compatible. Are there versioning registers within this register
>> block?
>>
>
> There are versioning registers for the phy (1.0 and 1.1). But the current erratum
> A008751 does not require the mentioning of the version numbers. Was planning
> to take care of the versioning when there is code diversity on the basis of the
> version number.
That is not how device tree bindings work. The describe the hardware,
not the driver.
That said, is the block version sufficient to tell whether a given chip
has this erratum? If so, you don't need a special property for the
erratum. If not, what is different about the PHY that is not described
by the versioning?
In any case, it would be nice to mention the version register and its
offset in the binding, just so that it becomes part of the definition of
this compatible string, and if we come out with some QorIQ chip with a
USB3 PHY that is totally different and doesn't have that version
register, it'll be clear that it needs a different compatible.
>>> +static inline u32 qoriq_usb3_phy_readl(void __iomem *addr, u32
>>> +offset) {
>>> + return __raw_readl(addr + offset);
>>> +}
>>> +
>>> +static inline void qoriq_usb3_phy_writel(void __iomem *addr, u32 offset,
>>> + u32 data)
>>> +{
>>> + __raw_writel(data, addr + offset);
>>> +}
>>
>> Why raw? Besides missing barriers, this will cause the accesses to be native-endian
>> which is not correct.
>>
>
> The only reason for __raw_writel is to make the code faster.
Does that really matter here?
> However, shall I use writel(with both barriers and byte swap) instead
Yes, if the registers are little-endian on all chips.
> and then make appropriate changes in the value 32'h27672B2A?
Not sure what you mean here.
> In my knowledge, there are more than 5 errata in pipeline,
Then please get all of these errata described in the device tree ASAP
(unless their presence can be reliably inferred from the block version,
as discussed above).
> However, in future, if any other erratum comes up, and it has to be applied
> at any point other than during init, then the variable has to be added in
> qoriq_usb3_phy struct and the property has to be read separately.
Or if the erratum is detected by some means other than a device tree
property...
-Scott
^ permalink raw reply
* [PATCH V2 fix 5/6] mm: hugetlb: add a new function to allocate a new gigantic page
From: Huang Shijie @ 2016-11-16 6:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479107259-2011-6-git-send-email-shijie.huang@arm.com>
There are three ways we can allocate a new gigantic page:
1. When the NUMA is not enabled, use alloc_gigantic_page() to get
the gigantic page.
2. The NUMA is enabled, but the vma is NULL.
There is no memory policy we can refer to.
So create a @nodes_allowed, initialize it with init_nodemask_of_mempolicy()
or init_nodemask_of_node(). Then use alloc_fresh_gigantic_page() to get
the gigantic page.
3. The NUMA is enabled, and the vma is valid.
We can follow the memory policy of the @vma.
Get @nodes_allowed by huge_nodemask(), and use alloc_fresh_gigantic_page()
to get the gigantic page.
Signed-off-by: Huang Shijie <shijie.huang@arm.com>
---
Since the huge_nodemask() is changed, we have to change this function a little.
---
mm/hugetlb.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 6995087..c33bddc 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1502,6 +1502,69 @@ int dissolve_free_huge_pages(unsigned long start_pfn, unsigned long end_pfn)
/*
* There are 3 ways this can get called:
+ *
+ * 1. When the NUMA is not enabled, use alloc_gigantic_page() to get
+ * the gigantic page.
+ *
+ * 2. The NUMA is enabled, but the vma is NULL.
+ * Create a @nodes_allowed, and use alloc_fresh_gigantic_page() to get
+ * the gigantic page.
+ *
+ * 3. The NUMA is enabled, and the vma is valid.
+ * Use the @vma's memory policy.
+ * Get @nodes_allowed by huge_nodemask(), and use alloc_fresh_gigantic_page()
+ * to get the gigantic page.
+ */
+static struct page *__hugetlb_alloc_gigantic_page(struct hstate *h,
+ struct vm_area_struct *vma, unsigned long addr, int nid)
+{
+ NODEMASK_ALLOC(nodemask_t, nodes_allowed, GFP_KERNEL | __GFP_NORETRY);
+ struct page *page = NULL;
+
+ /* Not NUMA */
+ if (!IS_ENABLED(CONFIG_NUMA)) {
+ if (nid == NUMA_NO_NODE)
+ nid = numa_mem_id();
+
+ page = alloc_gigantic_page(nid, huge_page_order(h));
+ if (page)
+ prep_compound_gigantic_page(page, huge_page_order(h));
+
+ NODEMASK_FREE(nodes_allowed);
+ return page;
+ }
+
+ /* NUMA && !vma */
+ if (!vma) {
+ if (nid == NUMA_NO_NODE) {
+ if (!init_nodemask_of_mempolicy(nodes_allowed)) {
+ NODEMASK_FREE(nodes_allowed);
+ nodes_allowed = &node_states[N_MEMORY];
+ }
+ } else if (nodes_allowed) {
+ init_nodemask_of_node(nodes_allowed, nid);
+ } else {
+ nodes_allowed = &node_states[N_MEMORY];
+ }
+
+ page = alloc_fresh_gigantic_page(h, nodes_allowed, true);
+
+ if (nodes_allowed != &node_states[N_MEMORY])
+ NODEMASK_FREE(nodes_allowed);
+
+ return page;
+ }
+
+ /* NUMA && vma */
+ if (huge_nodemask(vma, addr, nodes_allowed))
+ page = alloc_fresh_gigantic_page(h, nodes_allowed, true);
+
+ NODEMASK_FREE(nodes_allowed);
+ return page;
+}
+
+/*
+ * There are 3 ways this can get called:
* 1. With vma+addr: we use the VMA's memory policy
* 2. With !vma, but nid=NUMA_NO_NODE: We try to allocate a huge
* page from any node, and let the buddy allocator itself figure
--
2.5.5
^ permalink raw reply related
* [PATCH] clk: qoriq: added ls1012a clock configuration
From: Scott Wood @ 2016-11-16 6:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479275900-42365-1-git-send-email-yuantian.tang@nxp.com>
On Wed, 2016-11-16 at 13:58 +0800, yuantian.tang at nxp.com wrote:
> From: Tang Yuantian <Yuantian.Tang@nxp.com>
>
> Added ls1012a clock configuation information.
Do we really need the same line in the changelog twice?
>
> Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
> ---
> ?drivers/clk/clk-qoriq.c | 19 +++++++++++++++++++
> ?1 file changed, 19 insertions(+)
>
> diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
> index 1bece0f..563d874 100644
> --- a/drivers/clk/clk-qoriq.c
> +++ b/drivers/clk/clk-qoriq.c
> @@ -202,6 +202,14 @@ static const struct clockgen_muxinfo ls1021a_cmux = {
> ? }
> ?};
> ?
> +static const struct clockgen_muxinfo ls1012a_cmux = {
> + {
> + [0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
> + {},
> + [2] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
> + }
> +};
> +
Based on the "ls1021a_cmux" in the context it looks like this patch is
intended to apply on top of?https://patchwork.kernel.org/patch/8923541/?but I
don't see any mention of that.
> ?static const struct clockgen_muxinfo t1040_cmux = {
> ? {
> ? [0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
> @@ -482,6 +490,16 @@ static const struct clockgen_chipinfo chipinfo[] = {
> ? .pll_mask = 0x03,
> ? },
> ? {
> + .compat = "fsl,ls1012a-clockgen",
> + .cmux_groups = {
> + &ls1012a_cmux
> + },
> + .cmux_to_group = {
> + 0, -1
> + },
> + .pll_mask = 0x03,
> + },
> + {
> ? .compat = "fsl,ls1043a-clockgen",
> ? .init_periph = t2080_init_periph,
> ? .cmux_groups = {
> @@ -1284,6 +1302,7 @@ CLK_OF_DECLARE(qoriq_clockgen_2, "fsl,qoriq-clockgen-
> 2.0", clockgen_init);
> ?CLK_OF_DECLARE(qoriq_clockgen_ls1021a, "fsl,ls1021a-clockgen",
> clockgen_init);
> ?CLK_OF_DECLARE(qoriq_clockgen_ls1043a, "fsl,ls1043a-clockgen",
> clockgen_init);
> ?CLK_OF_DECLARE(qoriq_clockgen_ls2080a, "fsl,ls2080a-clockgen",
> clockgen_init);
> +CLK_OF_DECLARE(qoriq_clockgen_ls1012a, "fsl,ls1012a-clockgen",
> clockgen_init);
Please keep these lists of chips sorted (or as close as you can in the case of
the cmux structs which already have some sorting issues).
-Scott
^ permalink raw reply
* Default atomic_pool_size value & changing it
From: Rafał Miłecki @ 2016-11-16 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACna6rwQp+kzkBBOJ7Jv=AGibqA9XK2qj4pqXUnJwUGg29BpZg@mail.gmail.com>
On 15 November 2016 at 22:43, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> On 15 November 2016 at 22:37, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
>> On Tue, Nov 15, 2016 at 10:15:51PM +0100, Rafa? Mi?ecki wrote:
>>> I've hit problem with allocating enough coherent DMA memory. Obviously
>>> there is a limit of this memory as pointed by:
>>> [ 0.283667] DMA: preallocated 256 KiB pool for atomic coherent allocations
>>
>> This is for _atomic_ coherent allocations, not for normal coherent
>> allocations. Normal coherent allocations come from the CMA memory.
>> Make sure you have CMA enabled, and you have enough of it.
>>
>> Boot with cma=xxxMB with xxx set appropriately.
>
> Oh, that definitely sounds like worth trying
> # CONFIG_CMA is not set
> thanks for pointing it to me!
For my quick testing I silly used:
cpu_addr[i] = dma_zalloc_coherent(dev, size, &dma_addr[i], GFP_ATOMIC);
which obviously shouldn't be done in non-sleep mode and shouldn't need
GFP_ATOMIC.
I got it now, thanks again.
--
Rafa?
^ permalink raw reply
* [PATCH v2] staging: vc04_services: rework ioctl code path
From: Greg KH @ 2016-11-16 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479245234.28223.1.camel@crowfest.net>
On Tue, Nov 15, 2016 at 01:27:14PM -0800, Michael Zoran wrote:
> I'll see what I can do, but since this is getting closer to the
> holidays I'm planing to spend less time on this. Perhaps someone else
> may be interested in cleaning up the ioctl path?
>
> Since the old code uses obsolete kernel features, it's going to take
> some work to fix without adding any checkpatch.pl warnings.
When just moving code around, it's ok to keep the same warnings, they
can be fixed up correctly later on.
thanks,
greg k-h
^ permalink raw reply
* [PATCH V2 fix 4/6] mm: mempolicy: intruduce a helper huge_nodemask()
From: Huang Shijie @ 2016-11-16 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479107259-2011-5-git-send-email-shijie.huang@arm.com>
This patch intruduces a new helper huge_nodemask(),
we can use it to get the node mask.
This idea of the function is from the init_nodemask_of_mempolicy():
Return true if we can succeed in extracting the node_mask
for 'bind' or 'interleave' policy or initializing the node_mask
to contain the single node for 'preferred' or 'local' policy.
Signed-off-by: Huang Shijie <shijie.huang@arm.com>
---
The previous version does not treat the MPOL_PREFERRED/MPOL_INTERLEAVE cases.
This patch adds the code to set proper node mask for
MPOL_PREFERRED/MPOL_INTERLEAVE.
---
include/linux/mempolicy.h | 8 ++++++++
mm/mempolicy.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+)
diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
index 5e5b296..7796a40 100644
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -145,6 +145,8 @@ extern void mpol_rebind_task(struct task_struct *tsk, const nodemask_t *new,
enum mpol_rebind_step step);
extern void mpol_rebind_mm(struct mm_struct *mm, nodemask_t *new);
+extern bool huge_nodemask(struct vm_area_struct *vma,
+ unsigned long addr, nodemask_t *mask);
extern struct zonelist *huge_zonelist(struct vm_area_struct *vma,
unsigned long addr, gfp_t gfp_flags,
struct mempolicy **mpol, nodemask_t **nodemask);
@@ -261,6 +263,12 @@ static inline void mpol_rebind_mm(struct mm_struct *mm, nodemask_t *new)
{
}
+static inline bool huge_nodemask(struct vm_area_struct *vma,
+ unsigned long addr, nodemask_t *mask)
+{
+ return false;
+}
+
static inline struct zonelist *huge_zonelist(struct vm_area_struct *vma,
unsigned long addr, gfp_t gfp_flags,
struct mempolicy **mpol, nodemask_t **nodemask)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 6d3639e..5063a69 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1800,6 +1800,53 @@ static inline unsigned interleave_nid(struct mempolicy *pol,
#ifdef CONFIG_HUGETLBFS
/*
+ * huge_nodemask(@vma, @addr, @mask)
+ * @vma: virtual memory area whose policy is sought
+ * @addr: address in @vma
+ * @mask: a nodemask pointer
+ *
+ * Return true if we can succeed in extracting the policy nodemask
+ * for 'bind' or 'interleave' policy into the argument @mask, or
+ * initializing the argument @mask to contain the single node for
+ * 'preferred' or 'local' policy.
+ */
+bool huge_nodemask(struct vm_area_struct *vma, unsigned long addr,
+ nodemask_t *mask)
+{
+ struct mempolicy *mpol;
+ bool ret = true;
+ int nid;
+
+ if (!mask)
+ return false;
+
+ mpol = get_vma_policy(vma, addr);
+
+ switch (mpol->mode) {
+ case MPOL_PREFERRED:
+ if (mpol->flags & MPOL_F_LOCAL)
+ nid = numa_node_id();
+ else
+ nid = mpol->v.preferred_node;
+ init_nodemask_of_node(mask, nid);
+ break;
+
+ case MPOL_BIND:
+ /* Fall through */
+ case MPOL_INTERLEAVE:
+ *mask = mpol->v.nodes;
+ break;
+
+ default:
+ ret = false;
+ break;
+ }
+ mpol_cond_put(mpol);
+
+ return ret;
+}
+
+/*
* huge_zonelist(@vma, @addr, @gfp_flags, @mpol)
* @vma: virtual memory area whose policy is sought
* @addr: address in @vma for shared policy lookup and interleave policy
--
2.5.5
^ permalink raw reply related
* [PATCH v4 4/4] ARM: dts: da850: Add the usb otg device nodeg
From: Sekhar Nori @ 2016-11-16 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115211951.GH11011@uda0271908>
On Wednesday 16 November 2016 02:49 AM, Bin Liu wrote:
> On Tue, Nov 15, 2016 at 04:16:02PM +0530, Sekhar Nori wrote:
>> On Thursday 03 November 2016 09:29 PM, 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..9f5040c 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";
>>> + };
>>
>> As mentioned by David already, this node needs to be removed. Please
>> rebase this on top of latest linux-davinci/master when ready for merging
>> (driver changes accepted).
>
> Dropped this patch due to this comment.
Bin, Please do not apply dts or arch/arm/mach-davinci patches. I have a
bunch queued through my tree and more in pipeline and it will cause
unnecessary merge conflicts in linux-next or at Linus.
For future, I have asked Alexandre to send driver and dts patches as
separate series so there is no confusion on who should apply.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] clk: qoriq: added ls1012a clock configuration
From: yuantian.tang at nxp.com @ 2016-11-16 5:58 UTC (permalink / raw)
To: linux-arm-kernel
From: Tang Yuantian <Yuantian.Tang@nxp.com>
Added ls1012a clock configuation information.
Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
---
drivers/clk/clk-qoriq.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 1bece0f..563d874 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -202,6 +202,14 @@ static const struct clockgen_muxinfo ls1021a_cmux = {
}
};
+static const struct clockgen_muxinfo ls1012a_cmux = {
+ {
+ [0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
+ {},
+ [2] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
+ }
+};
+
static const struct clockgen_muxinfo t1040_cmux = {
{
[0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
@@ -482,6 +490,16 @@ static const struct clockgen_chipinfo chipinfo[] = {
.pll_mask = 0x03,
},
{
+ .compat = "fsl,ls1012a-clockgen",
+ .cmux_groups = {
+ &ls1012a_cmux
+ },
+ .cmux_to_group = {
+ 0, -1
+ },
+ .pll_mask = 0x03,
+ },
+ {
.compat = "fsl,ls1043a-clockgen",
.init_periph = t2080_init_periph,
.cmux_groups = {
@@ -1284,6 +1302,7 @@ CLK_OF_DECLARE(qoriq_clockgen_2, "fsl,qoriq-clockgen-2.0", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_ls1021a, "fsl,ls1021a-clockgen", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_ls1043a, "fsl,ls1043a-clockgen", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_ls2080a, "fsl,ls2080a-clockgen", clockgen_init);
+CLK_OF_DECLARE(qoriq_clockgen_ls1012a, "fsl,ls1012a-clockgen", clockgen_init);
/* Legacy nodes */
CLK_OF_DECLARE(qoriq_sysclk_1, "fsl,qoriq-sysclk-1.0", sysclk_init);
--
2.1.0.27.g96db324
^ permalink raw reply related
* [RESEND PATCH v1 05/11] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU
From: Anurup M @ 2016-11-16 5:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161115095148.GA29104@leverpostej>
On Tuesday 15 November 2016 03:21 PM, Mark Rutland wrote:
> On Mon, Nov 14, 2016 at 05:36:44AM +0530, Anurup M wrote:
>> On Friday 11 November 2016 12:00 AM, Mark Rutland wrote:
>>> On Thu, Nov 03, 2016 at 01:42:01AM -0400, Anurup M wrote:
>>>> + - scl-id : The Super Cluster ID. This can be the ID of the CPU die
>>>> + or IO die in the chip.
>>> What's this needed for?
>> This is used as suffix to the PMU name. hisi_l3c<scl-id>. (hisi_l3c2
>> - for scl-id = 2).
>> This is to identify the pmu correspond to which CPU die in the socket.
>>>> + - num-events : No of events supported by this PMU device.
>>>> +
>>>> + - num-counters : No of hardware counters available for counting.
>>> This isn't probeable or well-known?
>> My idea is to have the common properties of SoC PMU added here.
>> The num-events, num-counters etc. So that handling can be made
>> common in the driver.
>> Is it not recommended? Please share your comments.
> This feels like something that should be well-known for the programming
> model of the device. If the number of events and/or counters shange, I'd
> expect other things to also change such that the device is no longer
> compatible with previous versions.
>
> [...]
>
Agreed, it is possible that the versions can be still incompatible.
Shall move it to
driver in v2.
>> The below two properties (module-id, cfgen-map) differs between
>> chips hip05/06 and hip07.
> The module-id property sounds like a HW description, but it's not
> entirely clear to me what cfgen-map is; more comments on that below.
>
>> Please suggest.
>>>> + - module-id : Module ID to input for djtag. This property is an array of
>>>> + module_id for each L3 cache banks.
>>>> +
>>>> + - num-banks : Number of banks or instances of the device.
>>> What's a bank? Surely they have separate instances of the PMU?
>> Yes each bank is a separate instance of PMU.
>> If it is recommended to have each L3 cache bank registered as
>> separate PMU with perf, then this property will be removed.
> Generally, I think that separate instances are preferable.
>
>>> What order are these in?
>> The bank number will start from "1" till "4" for L3 cache as there
>> are four banks in hip05/06/07 chips.
>>>> + - cfgen-map : Config enable array to select the bank.
>>> Huh?
> As above, it's not clear to me what this property represents. Could you
> please clarify?
This property is used to select the bank. The naming lead to confusion.
I shall change it to bank_select.
If it is recommended to register each L3 cache bank as separate PMU then
this property will be moved to driver.
Thanks
Anurup
>
> Thanks,
> Mark.
^ permalink raw reply
* [PATCH 1/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
From: Sriram Dash @ 2016-11-16 5:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116000740.iq6ffcjanrrvrdnq@rob-hp-laptop>
>From: Rob Herring [mailto:robh at kernel.org]
>On Mon, Nov 14, 2016 at 10:56:54AM +0530, Sriram Dash wrote:
>> Adds qoriq usb 3.0 phy driver support for LS1043A platform.
>> Describes the qoriq usb 2.0 phy driver binding, currently used for
>> LS1043A platform.
>>
>> Signed-off-by: Sriram Dash <sriram.dash@nxp.com>
>> ---
>> .../devicetree/bindings/phy/phy-qoriq-usb3.txt | 36 ++++
>> drivers/phy/Kconfig | 8 +
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-qoriq-usb3.c | 202 +++++++++++++++++++++
>> 4 files changed, 247 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>> create mode 100644 drivers/phy/phy-qoriq-usb3.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>> b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>> new file mode 100644
>> index 0000000..d934c80
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
>> @@ -0,0 +1,36 @@
>> +Driver for Freescale USB 3.0 PHY
>> +
>> +Required properties:
>> +
>> +- compatible : fsl,qoriq-usb3-phy
>> +- reg : register mappings for Parameter Configuration Register
>> + and Phy base offset.
>> +- reg-names : "param_ctrl" and "phy_base"
>> +- phy_type : For multi port host USB controllers, should be one of
>> + "ulpi", or "serial". For dual role USB controllers,
>> + should be one of "ulpi", "utmi", "utmi_wide", or "serial".
Hi Rob,
>
>Do any of these really apply to a USB3 PHY?
>
The concerned USB3 phy used is UTMI. I agree to your point somewhat that
all the types are not required now. Anyway, shall I make it an optional
property, with the mention of only UTMI and ULPI?
>Rob
>
>> +
>> +Example:
>> + usbphy0: usb3-phy at 084F0000 {
>
>usb-phy at ...
>
Ok. Will change in the next rev for Documentation and dts (patch 2/2)
>> + compatible = "fsl,qoriq-usb3-phy";
>> + reg = <0x0 0x01570070 0x0 0xC>, <0x0 0x084F0000 0x0 0x5000>;
>> + reg-names = "param_ctrl", "phy_base";
>> + #phy-cells = <0>;
>> + phy_type = "utmi";
>> + };
>> +
>> + usbphy1: usb3-phy at 08500000 {
>> + compatible = "fsl,qoriq-usb3-phy";
>> + reg = <0x0 0x0157007C 0x0 0xC>, <0x0 0x08500000 0x0 0x5000>;
>> + reg-names = "param_ctrl", "phy_base";
>> + #phy-cells = <0>;
>> + phy_type = "utmi";
>> + };
>> +
>> + usbphy2: usb3-phy at 08510000 {
>> + compatible = "fsl,qoriq-usb3-phy";
>> + reg = <0x0 0x01570088 0x0 0xC>, <0x0 0x08510000 0x0 0x5000>;
>> + reg-names = "param_ctrl", "phy_base";
>> + #phy-cells = <0>;
>> + phy_type = "utmi";
>> + };
^ permalink raw reply
* [PATCH 2/3] thermal: hisilicon: fix for dependency
From: Leo Yan @ 2016-11-16 5:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479212695.2224.12.camel@intel.com>
On Tue, Nov 15, 2016 at 08:24:55PM +0800, Zhang Rui wrote:
> On Sat, 2016-11-12 at 20:05 +0800, Leo Yan wrote:
> > Hi Rui, Eduardo,
> >
> > On Wed, Aug 31, 2016 at 04:50:16PM +0800, Leo Yan wrote:
> > >
> > > The thermal driver is standalone driver which is used to enable
> > > thermal sensors, so it can be used with any cooling device and
> > > should not bind with CPU cooling device driver.
> > >
> > > This original patch is suggested by Amit Kucheria; so it's to
> > > polish the dependency in Kconfig, and remove the dependency with
> > > CPU_THERMAL.
> > Could you help review this patch? Or need me resend this patch? Sorry
> > I have not tracked this patches well before, this is one missed
> > patch for 96board Hikey.
> >
> as it still applies cleanly, the patch is queued for 4.10.
Thanks a lot.
> thanks,
> rui
> > Thanks,
> > Leo Yan
> >
> > >
> > > Signed-off-by: Leo Yan <leo.yan@linaro.org>
> > > ---
> > > ?drivers/thermal/Kconfig | 4 +++-
> > > ?1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> > > index 2d702ca..91ebab3 100644
> > > --- a/drivers/thermal/Kconfig
> > > +++ b/drivers/thermal/Kconfig
> > > @@ -177,8 +177,10 @@ config THERMAL_EMULATION
> > > ?
> > > ?config HISI_THERMAL
> > > ? tristate "Hisilicon thermal driver"
> > > - depends on (ARCH_HISI && CPU_THERMAL && OF) ||
> > > COMPILE_TEST
> > > + depends on ARCH_HISI || COMPILE_TEST
> > > ? depends on HAS_IOMEM
> > > + depends on OF
> > > + default y
> > > ? help
> > > ? ??Enable this to plug hisilicon's thermal sensor driver
> > > into the Linux
> > > ? ??thermal framework. cpufreq is used as the cooling device
> > > to throttle
^ permalink raw reply
* [PATCH fpga 8/9] fpga socfpga: Use the scatterlist interface
From: Jason Gunthorpe @ 2016-11-16 5:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1611150940270.3634@atull-VirtualBox2>
On Tue, Nov 15, 2016 at 09:47:05AM -0600, atull wrote:
> Not different.
>
> From 'fpga-mgr.txt':
> The programming sequence is:
> 1. .write_init
> 2. .write (may be called once or multiple times)
> 3. .write_complete
>
> The old write was be separate from write_init and write_complete
> because I figured that in the future someone may be streaming in
> the bitstream and not have the whole bitstream in memory.
What is the point of this if write_init gets a copy of the buffer -
what is that supposed to be?
If you see things this way why are you opposed to patch 9? I'll change
things around to call write multiple times and force the sg list into
write_init, which seems like what you intended anyhow..
Jason
^ 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