* [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 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 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] 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] drm/sun4i: tcon: Initialize regmap after enabling bus clocks
From: Chen-Yu Tsai @ 2016-11-16 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116093732.12828-1-wens@csie.org>
If we attempt to read/write the TCON registers before the bus clock
is enabled, those accesses get ignored.
In practice this almost never occurs because U-boot had already enabled
the bus clock as part of its firmware provided framebuffer (simplefb).
Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
I was looking around the DRM driver and noticed this sequence was off.
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c6afb2448655..8c2db65ea229 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -506,16 +506,16 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
return ret;
}
- ret = sun4i_tcon_init_regmap(dev, tcon);
+ ret = sun4i_tcon_init_clocks(dev, tcon);
if (ret) {
- dev_err(dev, "Couldn't init our TCON regmap\n");
+ dev_err(dev, "Couldn't init our TCON clocks\n");
goto err_assert_reset;
}
- ret = sun4i_tcon_init_clocks(dev, tcon);
+ ret = sun4i_tcon_init_regmap(dev, tcon);
if (ret) {
- dev_err(dev, "Couldn't init our TCON clocks\n");
- goto err_assert_reset;
+ dev_err(dev, "Couldn't init our TCON regmap\n");
+ goto err_free_clocks;
}
ret = sun4i_tcon_init_irq(dev, tcon);
--
2.10.2
^ permalink raw reply related
* [RFCv2 PATCH 1/5] video: add HDMI state notifier support
From: Hans Verkuil @ 2016-11-16 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <00ad0ddf-3e52-62e6-f863-cae6eefd08c9@xs4all.nl>
On 11/15/16 21:41, Hans Verkuil wrote:
> Hi Philipp,
>
> On 11/15/2016 07:24 PM, Philipp Zabel wrote:
>> Hi Hans,
>>
>> Am Montag, den 14.11.2016, 16:22 +0100 schrieb Hans Verkuil:
>>> From: Hans Verkuil <hans.verkuil@cisco.com>
>>>
>>> Add support for HDMI hotplug and EDID notifiers, which is used to convey
>>> information from HDMI drivers to their CEC and audio counterparts.
>>>
>>> Based on an earlier version from Russell King:
>>>
>>> https://patchwork.kernel.org/patch/9277043/
>>>
>>> The hdmi_notifier is a reference counted object containing the HDMI state
>>> of an HDMI device.
>>>
>>> When a new notifier is registered the current state will be reported to
>>> that notifier at registration time.
>>>
>>> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>>> ---
>>> drivers/video/Kconfig | 3 +
>>> drivers/video/Makefile | 1 +
>>> drivers/video/hdmi-notifier.c | 136 ++++++++++++++++++++++++++++++++++++++++++
>>> include/linux/hdmi-notifier.h | 43 +++++++++++++
>>> 4 files changed, 183 insertions(+)
>>> create mode 100644 drivers/video/hdmi-notifier.c
>>> create mode 100644 include/linux/hdmi-notifier.h
>>>
>>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>>> index 3c20af9..1ee7b9f 100644
>>> --- a/drivers/video/Kconfig
>>> +++ b/drivers/video/Kconfig
>>> @@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
>>> config HDMI
>>> bool
>>>
>>> +config HDMI_NOTIFIERS
>>> + bool
>>> +
>>> if VT
>>> source "drivers/video/console/Kconfig"
>>> endif
>>> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
>>> index 9ad3c17..65f5649 100644
>>> --- a/drivers/video/Makefile
>>> +++ b/drivers/video/Makefile
>>> @@ -1,5 +1,6 @@
>>> obj-$(CONFIG_VGASTATE) += vgastate.o
>>> obj-$(CONFIG_HDMI) += hdmi.o
>>> +obj-$(CONFIG_HDMI_NOTIFIERS) += hdmi-notifier.o
>>>
>>> obj-$(CONFIG_VT) += console/
>>> obj-$(CONFIG_LOGO) += logo/
>>> diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
>>> new file mode 100644
>>> index 0000000..c2a4f1b
>>> --- /dev/null
>>> +++ b/drivers/video/hdmi-notifier.c
>>> @@ -0,0 +1,136 @@
>>> +#include <linux/export.h>
>>> +#include <linux/hdmi-notifier.h>
>>> +#include <linux/string.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/list.h>
>>> +
>>> +struct hdmi_notifiers {
>>> + struct list_head head;
>>> + struct device *dev;
>>> + struct hdmi_notifier *n;
>>> +};
>>
>> This struct is not used, can be removed.
>
> Indeed.
>
>>
>>> +static LIST_HEAD(hdmi_notifiers);
>>> +static DEFINE_MUTEX(hdmi_notifiers_lock);
>>> +
>>> +struct hdmi_notifier *hdmi_notifier_get(struct device *dev)
>>> +{
>>> + struct hdmi_notifier *n;
>>> +
>>> + mutex_lock(&hdmi_notifiers_lock);
>>> + list_for_each_entry(n, &hdmi_notifiers, head) {
>>> + if (n->dev == dev) {
>>> + mutex_unlock(&hdmi_notifiers_lock);
>>> + kref_get(&n->kref);
>>> + return n;
>>> + }
>>> + }
>>> + n = kzalloc(sizeof(*n), GFP_KERNEL);
>>> + if (!n)
>>> + goto unlock;
>>> + mutex_init(&n->lock);
>>> + BLOCKING_INIT_NOTIFIER_HEAD(&n->notifiers);
>>> + kref_init(&n->kref);
>>
>> + n->dev = dev;
>>
>> Currently n->dev is never set, so every caller of this function gets its
>> own hdmi_notifier.
>
> Oops! Well, I did say it was compile-tested only :-)
>
>>
>>> + list_add_tail(&n->head, &hdmi_notifiers);
>>> +unlock:
>>> + mutex_unlock(&hdmi_notifiers_lock);
>>> + return n;
>>> +}
>>> +EXPORT_SYMBOL_GPL(hdmi_notifier_get);
>>> +
>>> +static void hdmi_notifier_release(struct kref *kref)
>>> +{
>>> + struct hdmi_notifier *n =
>>> + container_of(kref, struct hdmi_notifier, kref);
>>> +
I also forgot to remove this notifier from the global list.
I've updated my git branch to fix this.
Hans
^ permalink raw reply
* [PATCH v2] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168
From: Marc Zyngier @ 2016-11-16 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582B52D6.6060907@caviumnetworks.com>
On 15/11/16 18:24, David Daney wrote:
> On 11/15/2016 01:26 AM, Marc Zyngier wrote:
>> On 15/11/16 07:00, Geetha sowjanya wrote:
>>> From: Tirumalesh Chalamarla <Tirumalesh.Chalamarla@cavium.com>
>>>
>>> This patch implements Cavium ThunderX erratum 28168.
>>>
>>> PCI requires stores complete in order. Due to erratum #28168
>>> PCI-inbound MSI-X store to the interrupt controller are delivered
>>> to the interrupt controller before older PCI-inbound memory stores
>>> are committed.
>>> Doing a sync on SMMU will make sure all prior data transfers are
>>> completed before invoking ISR.
>>>
>>> Signed-off-by: Tirumalesh Chalamarla <Tirumalesh.Chalamarla@cavium.com>
>>> Signed-off-by: Geetha sowjanya <gakula@caviumnetworks.com>
> [...]
>>> --- a/drivers/irqchip/irq-gic-v3.c
>>> +++ b/drivers/irqchip/irq-gic-v3.c
>>> @@ -28,6 +28,8 @@
>>> #include <linux/of_irq.h>
>>> #include <linux/percpu.h>
>>> #include <linux/slab.h>
>>> +#include <linux/msi.h>
>>> +#include <linux/pci.h>
>>>
>>> #include <linux/irqchip.h>
>>> #include <linux/irqchip/arm-gic-common.h>
>>> @@ -736,6 +738,20 @@ static inline void gic_cpu_pm_init(void) { }
>>>
>>> #define GIC_ID_NR (1U << gic_data.rdists.id_bits)
>>>
>>> +/*
>>> + * Due to #28168 erratum in ThunderX,
>>> + * we need to make sure DMA data transfer is done before MSIX.
>>> + */
>>> +static void cavium_irq_perflow_handler(struct irq_data *data)
>>> +{
>>> + struct pci_dev *pdev;
>>> +
>>> + pdev = msi_desc_to_pci_dev(irq_data_get_msi_desc(data));
>>
>> What happens if this is not a PCI device?
>>
>>> + if ((pdev->vendor != 0x177d) &&
>>> + ((pdev->device & 0xA000) != 0xA000))
>>> + cavium_arm_smmu_tlb_sync(&pdev->dev);
>>
>> I've asked that before. What makes Cavium devices so special that they
>> are not sensitive to this bug?
>
>
> This is a heuristic for devices connected to external PCIe buses as
> opposed to on-SoC devices (which don't suffer from the erratum).
>
> In any event what would happen if we got rid of this check and ...
>
>
>>
>>> +}
>>> +
>>> static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
>>> irq_hw_number_t hw)
>>> {
>>> @@ -773,6 +789,9 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
>>> return -EPERM;
>>> irq_domain_set_info(d, irq, hw, chip, d->host_data,
>>> handle_fasteoi_irq, NULL, NULL);
>>> + if (cpus_have_cap(ARM64_WORKAROUND_CAVIUM_28168))
>>> + __irq_set_preflow_handler(irq,
>>> + cavium_irq_perflow_handler);
>>
>
> ... move the registration of the preflow_handler into a
> msi_domain_ops.msi_finish() handler in irq-git-v3-its-pic-msi.c?
That's the kind of thing I was angling for. You'll have to store the
device pointer into the scratchpad (we still have plenty of space there)
so that msi_finish() can have a peek.
> There we will know that it is a pci device, and can walk up the bus
> hierarchy to see if there is a Cavium PCIe root port present. If such a
> port is found, we know we are on an external Cavium PCIe bus, and can
> register the preflow_handler without having to check the device identifiers.
Something like that (though I'm unclear why other devices wouldn't see a
root port, but that's probably me lacking some PCIe foo).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Lorenzo Pieralisi @ 2016-11-16 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <313844ca-d948-1297-84b2-669f3a7d57d2@arm.com>
Hi Joerg,
On Mon, Nov 14, 2016 at 06:25:16PM +0000, Robin Murphy wrote:
> On 14/11/16 15:52, Joerg Roedel wrote:
> > On Mon, Nov 14, 2016 at 12:00:47PM +0000, Robin Murphy wrote:
> >> If we've already made the decision to move away from bus ops, I don't
> >> see that it makes sense to deliberately introduce new dependencies on
> >> them. Besides, as it stands, this patch literally implements "tell the
> >> iommu-core which hardware-iommus exist in the system and a seperate
> >> iommu_ops ptr for each of them" straight off.
> >
> > Not sure which code you are looking at, but as I see it we have only
> > per-device iommu-ops now (with this patch). That is different from
> > having core-visible hardware-iommu instances where devices could link
> > to.
>
> The per-device IOMMU ops are already there since 57f98d2f61e1. This
> patch generalises the other end, moving the "registering an IOMMU
> instance" (i.e. iommu_fwentry) bit into the IOMMU core, from being
> OF-specific. I'd be perfectly happy if we rename iommu_fwentry to
> iommu_instance, fwnode_iommu_set_ops() to iommu_register_instance(), and
> such if that makes the design intent clearer.
I can easily make the changes Robin suggests above, I need to know
what to do with this patch it is the last blocking point for this
series and time is running out I can revert to using dev->bus to
retrieve iommu_ops (even though I do not think it makes sense given
what Robin outlines below) but I need to know please, we can't gate
an entire series for this patch that is just syntactic sugar.
Thanks !
Lorenzo
> If you'd also prefer to replace iommu_fwspec::ops with an opaque
> iommu_fwspec::iommu_instance pointer so that things are a bit more
> centralised (and users are forced to go through the API rather then call
> ops directly), I'd have no major objection either. My main point is that
> we've been deliberately putting the relevant building blocks in place -
> the of_iommu_{get,set}_ops stuff was designed from the start to
> accommodate per-instance ops, via the ops pointer *being* the instance
> token; the iommu_fwspec stuff is deliberately intended to provide
> per-device ops on top of that. The raw functionality is either there in
> iommu.c already, or moving there in patches already written, so if it
> doesn't look right all we need to focus on is making it look right.
>
> > Also the rest of iommu-core code still makes use of the per-bus ops. The
> > per-device ops are only used for the of_xlate fn-ptr.
>
> Hence my aforementioned patches intended for 4.10, directly following on
> from introducing iommu_fwspec in 4.9:
>
> http://www.mail-archive.com/iommu at lists.linux-foundation.org/msg14576.html
>
> ...the purpose being to provide a smooth transition from per-bus ops to
> per-device, per-instance ops. Apply those and we're 90% of the way there
> for OF-based IOMMU drivers (not that any of those actually need
> per-instance ops, admittedly; I did prototype it for the ARM SMMU ages
> ago, but it didn't seem worth the bother). Lorenzo's series broadens the
> scope to ACPI-based systems and moves the generically-useful parts into
> the core where we can easily build on them further if necessary. The
> major remaining work is to convert external callers of the current
> bus-dependent functions like iommu_domain_alloc(), iommu_present(), etc.
> to device-based alternatives.
>
> Robin.
^ permalink raw reply
* [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Jerome Brunet @ 2016-11-16 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <476b72f3-5efe-3551-6c24-0e378d655a0f@gmail.com>
On Tue, 2016-11-15 at 09:03 -0800, Florian Fainelli wrote:
> On 11/15/2016 08:30 AM, Andrew Lunn wrote:
> >
> > On Tue, Nov 15, 2016 at 03:29:12PM +0100, Jerome Brunet wrote:
> > >
> > > On some platforms, energy efficient ethernet with rtl8211 devices
> > > is
> > > causing issue, like throughput drop or broken link.
> > >
> > > This was reported on the OdroidC2 (DWMAC + RTL8211F). While the
> > > issue root
> > > cause is not fully understood yet, disabling EEE advertisement
> > > prevent auto
> > > negotiation from enabling EEE.
> > >
> > > This patch provides options to disable 1000T and 100TX EEE
> > > advertisement
> > > individually for the realtek phys supporting this feature.
> >
> > Looking at the code, i don't see anything specific to RealTek
> > here. This all seems generic. So should it be in phy.c and made a
> > generic OF property which can be applied to any PHY which supports
> > EEE.
>
> Agreed.
Good point, Thanks for pointing this out.
> Just to be sure, Jerome, you did verify that with EEE no longer
> advertised, ethtool --set-eee fails, right? The point is that you may
> be
> able to disable EEE on boot, but if there is a way to re-enable it
> later
> on, we would want to disable that too.
I was focused on getting the issue out of way I did not think that
someone could try something like this :)
I just tried and it is possible to re-enable eee, though it is not
simplest thing to do: using ethtool enable eee advertisement, enable
eee, restart the autonegotiation without bringing the interface down
(otherwise the phy config kicks and disable eee again). I reckon this
is not good and I need to address this.
There two kind of PHYs supporting eee, the one advertising eee by
default (like realtek) and the one not advertising it (like micrel).
If the property is going to be generic, I see two options and I'd like
your view on this:
1) The DT provided value could be seen as "preferred" (or boot
setting), which can be cleanly changed with ethtool later on. In this
case, I guess I need to provide a way to force eee advertisement as
well to be consistent.
2) The DT provided value could forbid the advertisement of eee. In this
case I need to return an error if ethtool tries to re-enable it. Phy
with eee advertisement off by default (and not forbidden) would still
need to activate it manually with ethtool after boot. I don't see why
someone would absolutely want eee activated at boot time so I guess
this is OK.
Do you have a preference ?
Thanks for this quick feedback !
Cheers
Jerome
^ permalink raw reply
* [PATCH] mxs-auart: count FIFO overrun errors
From: Greg Kroah-Hartman @ 2016-11-16 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479207929.4985.25.camel@reccoware.de>
On Tue, Nov 15, 2016 at 12:05:29PM +0100, Wolfgang Ocker wrote:
> The mxs-auart driver does not count FIFO overrun errors. These errors never
> appear in /proc/tty/driver/ttyAPP. This is because the OERR status bit is
> masked by read_status_mask in the rx interrupt function, but the
> AUART_STAT_OERR bit is never set in read_status_mask. The patch enables the
> counting of overrun errors.
>
> Signed-off-by: Wolfgang Ocker <weo@reccoware.de>
> ---
> ?drivers/tty/serial/mxs-auart.c | 2 +-
> ?1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
> index 770454e0dfa3..8c1c9112b3fd 100644
> --- a/drivers/tty/serial/mxs-auart.c
> +++ b/drivers/tty/serial/mxs-auart.c
> @@ -1016,7 +1016,7 @@ static void mxs_auart_settermios(struct uart_port *u,
> ? ctrl |= AUART_LINECTRL_EPS;
> ? }
> ?
> - u->read_status_mask = 0;
> + u->read_status_mask = AUART_STAT_OERR;
> ?
> ? if (termios->c_iflag & INPCK)
> ? u->read_status_mask |= AUART_STAT_PERR;
> --?
> 2.10.0
This patch is corrupted and can not be applied, what did you do here?
Please fix up and resend.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2 2/3] soc: rockchip: add driver handling grf setup
From: Heiko Stuebner @ 2016-11-16 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95cd052e-7e0d-d13b-fedb-21f7b49d17bb@rock-chips.com>
Hi Shawn,
Am Mittwoch, 16. November 2016, 17:33:21 CET schrieb Shawn Lin:
> ? 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... :)
yep, I still remember when we had strange mmc errors which simply came from
the soc switching away from the mmc function before the mmc driver was
finished, so I also find that functionality unhelpful ;-) .
> > 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 :)
I just noticed that there is a second inclusion of regmap.h here, which can go
away.
>
> > +
> > +#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.
I expect errors here to be very rare. I.e. Doug thought that regmap might
return errors if we write outside the mapped region, which would mean someone
really messed up in this core component or a core-element of the dts.
But in general the GRF is always a mmio-regmap, so there won't be any i2c/spi/
whatever errors possible.
Also settings are pretty individual, so if setting 1 fails, setting 2 can
still succeed and the boot can continue somewhat farther.
The overall target is supposed to always boot as far as possible, so that
people might recover or get more information and not fail (and die) early.
Heiko
^ permalink raw reply
* [PATCH] cpufreq: dt: Add support for r8a7743 and r8a7745
From: Geert Uytterhoeven @ 2016-11-16 10:05 UTC (permalink / raw)
To: linux-arm-kernel
Add the compatible strings for supporting the generic cpufreq driver on
the Renesas RZ/G1M (r8a7743) and RZ/G1E (r8a7745) SoCs.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Support for RZ/G1M and RZ/G1E is expected to land in v4.10.
drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index fcc5bcfe57efe1c3..0c73c7dbd5878919 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -55,6 +55,8 @@
{ .compatible = "renesas,r7s72100", },
{ .compatible = "renesas,r8a73a4", },
{ .compatible = "renesas,r8a7740", },
+ { .compatible = "renesas,r8a7743", },
+ { .compatible = "renesas,r8a7745", },
{ .compatible = "renesas,r8a7778", },
{ .compatible = "renesas,r8a7779", },
{ .compatible = "renesas,r8a7790", },
--
1.9.1
^ permalink raw reply related
* [PATCH] cpufreq: dt: Add support for r8a7743 and r8a7745
From: Viresh Kumar @ 2016-11-16 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479290751-9705-1-git-send-email-geert+renesas@glider.be>
On 16-11-16, 11:05, Geert Uytterhoeven wrote:
> Add the compatible strings for supporting the generic cpufreq driver on
> the Renesas RZ/G1M (r8a7743) and RZ/G1E (r8a7745) SoCs.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Support for RZ/G1M and RZ/G1E is expected to land in v4.10.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH v4 4/4] ARM: dts: da850: Add the usb otg device node
From: Alexandre Bailon @ 2016-11-16 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0c94c5e0-9d2c-fff5-1213-2fb2adb20ab0@ti.com>
On 11/15/2016 11:46 AM, 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
I have missed it. But why should I remove it?
Without it, usb otg won't work.
> rebase this on top of latest linux-davinci/master when ready for merging
> (driver changes accepted).
>
>> +
>> +&usb0 {
>> + 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..322a31a 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";
>> + };
>> + 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";
>> + };
>
> Can you separate out the soc specific changes from board changes? Please
> place the usb0 node above the mdio node. I am trying to get to a rough
> ordering based on reg property.
I will do.
>
> Thanks,
> Sekhar
>
Thanks,
Alexandre
^ permalink raw reply
* [PATCH v7] soc: qcom: add l2 cache perf events driver
From: Mark Rutland @ 2016-11-16 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e917b871-d6ee-d52b-aedc-b3ee75aed05f@codeaurora.org>
On Fri, Nov 11, 2016 at 04:52:35PM -0500, Leeder, Neil wrote:
> So is there a use-case for individual uncore PMUs when they can't be
> used in task mode or per-cpu?
>
> The main (only?) use will be in system mode, in which case surely it
> makes sense to provide a single aggregated count?
If you are aware of the system topology, the numbers may be more useful
than the summed count. If you aren't, it's still possible to sum them in
userspace.
Having them summed by the kernel means that the kernel is implying it
supports group semantics that it cannot, since it cannot start/stop all
counters in a group atomically if they're split across several units.
> With individual PMUs exposed there will be potentially dozens of
> nodes for userspace to collect from which would make perf
> command-line usage unwieldy at best.
FWIW, for uncore/system PMUs, even on x86 there are a number of
independent units.
Some PMUs (those which are symmetric across the topology) get hidden
behind the same struct PMU, but instances are still isolated (and their
values not summed).
Thanks,
Mark.
^ permalink raw reply
* [PATCH v4 4/4] ARM: dts: da850: Add the usb otg device node
From: Sekhar Nori @ 2016-11-16 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d2050c80-255e-25d6-99ba-7634f2c7e39a@baylibre.com>
On Wednesday 16 November 2016 04:05 PM, Alexandre Bailon wrote:
> On 11/15/2016 11:46 AM, 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
> I have missed it. But why should I remove it?
> Without it, usb otg won't work.
Grr, I replied to the wrong hunk. The part in da850-lcdk.dts needs to be
preserved (but please fix the indentation on the closing brace).
The part in da850.dtsi needs to be removed as it is already merged.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 0/2] replace IS_ERR_OR_NULL by IS_ERR
From: Julia Lawall @ 2016-11-16 10:43 UTC (permalink / raw)
To: linux-arm-kernel
Replace IS_ERR_OR_NULL by IS_ERR on knav_queue_open calls.
---
drivers/net/ethernet/ti/netcp_core.c | 6 +++---
drivers/soc/ti/knav_qmss_queue.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH 2/2] soc: ti: knav_qmss_queue: replace IS_ERR_OR_NULL by IS_ERR
From: Julia Lawall @ 2016-11-16 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479293014-18811-1-git-send-email-Julia.Lawall@lip6.fr>
knav_queue_open always returns an ERR_PTR value, never NULL. This can be
confirmed by unfolding the function calls and conforms to the function's
documentation. Thus, replace IS_ERR_OR_NULL by IS_ERR in error checks.
The change is made using the following semantic patch:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression x;
statement S;
@@
x = knav_queue_open(...);
if (
- IS_ERR_OR_NULL
+ IS_ERR
(x)) S
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
The patches in this series are completely independent of each other, except
for having been made from the same specification.
drivers/soc/ti/knav_qmss_queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index b73e353..d90df84 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -777,7 +777,7 @@ void *knav_pool_create(const char *name,
}
pool->queue = knav_queue_open(name, KNAV_QUEUE_GP, 0);
- if (IS_ERR_OR_NULL(pool->queue)) {
+ if (IS_ERR(pool->queue)) {
dev_err(kdev->dev,
"failed to open queue for pool(%s), error %ld\n",
name, PTR_ERR(pool->queue));
^ permalink raw reply related
* [PATCH v4 4/4] ARM: dts: da850: Add the usb otg device node
From: Alexandre Bailon @ 2016-11-16 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d4c8da0e-d66d-1268-78e5-d994399c9166@ti.com>
On 11/16/2016 11:41 AM, Sekhar Nori wrote:
> On Wednesday 16 November 2016 04:05 PM, Alexandre Bailon wrote:
>> On 11/15/2016 11:46 AM, 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
>
>> I have missed it. But why should I remove it?
>> Without it, usb otg won't work.
>
> Grr, I replied to the wrong hunk. The part in da850-lcdk.dts needs to be
> preserved (but please fix the indentation on the closing brace).
OK. Thanks for the confirmation.
>
> The part in da850.dtsi needs to be removed as it is already merged.
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH 1/2] drm/i2c: tda998x: allow interrupt to be shared
From: Russell King @ 2016-11-16 10:48 UTC (permalink / raw)
To: linux-arm-kernel
The TDA998x contains two different I2C devices - there is the HDMI
encoder, and the TDA9950 CEC engine. These two share the same interrupt
signal.
In order to allow a driver for the CEC engine to work, we need to be
able to share the interrupt with the CEC driver, so convert the handler
and registration to allow this to happen.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
This patch follows on from:
"drm/i2c: tda998x: power down pre-filter and color conversion"
which is now part of my drm-tda998x-devel branch, a branch which will
shortly be part of linux-next. This patch and the following patch are
not part of that branch yet.
I don't believe I received any testing for the power-down patch above
either, so if I can have some tested-bys/reviewed-bys for it and these
two patches, that'd be great. Thanks.
As my Juno has now been fixed, I've been able to test these two patches
on the HDLCD on Juno and Dove Cubox.
drivers/gpu/drm/i2c/tda998x_drv.c | 52 ++++++++++++++++++++-------------------
1 file changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index bf5eec0c1b4f..74fb59a35269 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -634,28 +634,30 @@ static irqreturn_t tda998x_irq_thread(int irq, void *data)
bool handled = false;
sta = cec_read(priv, REG_CEC_INTSTATUS);
- cec = cec_read(priv, REG_CEC_RXSHPDINT);
- lvl = cec_read(priv, REG_CEC_RXSHPDLEV);
- flag0 = reg_read(priv, REG_INT_FLAGS_0);
- flag1 = reg_read(priv, REG_INT_FLAGS_1);
- flag2 = reg_read(priv, REG_INT_FLAGS_2);
- DRM_DEBUG_DRIVER(
- "tda irq sta %02x cec %02x lvl %02x f0 %02x f1 %02x f2 %02x\n",
- sta, cec, lvl, flag0, flag1, flag2);
-
- if (cec & CEC_RXSHPDINT_HPD) {
- if (lvl & CEC_RXSHPDLEV_HPD)
- tda998x_edid_delay_start(priv);
- else
- schedule_work(&priv->detect_work);
-
- handled = true;
- }
+ if (sta & CEC_INTSTATUS_HDMI) {
+ cec = cec_read(priv, REG_CEC_RXSHPDINT);
+ lvl = cec_read(priv, REG_CEC_RXSHPDLEV);
+ flag0 = reg_read(priv, REG_INT_FLAGS_0);
+ flag1 = reg_read(priv, REG_INT_FLAGS_1);
+ flag2 = reg_read(priv, REG_INT_FLAGS_2);
+ DRM_DEBUG_DRIVER(
+ "tda irq sta %02x cec %02x lvl %02x f0 %02x f1 %02x f2 %02x\n",
+ sta, cec, lvl, flag0, flag1, flag2);
+
+ if (cec & CEC_RXSHPDINT_HPD) {
+ if (lvl & CEC_RXSHPDLEV_HPD)
+ tda998x_edid_delay_start(priv);
+ else
+ schedule_work(&priv->detect_work);
+
+ handled = true;
+ }
- if ((flag2 & INT_FLAGS_2_EDID_BLK_RD) && priv->wq_edid_wait) {
- priv->wq_edid_wait = 0;
- wake_up(&priv->wq_edid);
- handled = true;
+ if ((flag2 & INT_FLAGS_2_EDID_BLK_RD) && priv->wq_edid_wait) {
+ priv->wq_edid_wait = 0;
+ wake_up(&priv->wq_edid);
+ handled = true;
+ }
}
return IRQ_RETVAL(handled);
@@ -1542,7 +1544,7 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv)
/* initialize the optional IRQ */
if (client->irq) {
- int irqf_trigger;
+ unsigned long irq_flags;
/* init read EDID waitqueue and HDP work */
init_waitqueue_head(&priv->wq_edid);
@@ -1552,11 +1554,11 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv)
reg_read(priv, REG_INT_FLAGS_1);
reg_read(priv, REG_INT_FLAGS_2);
- irqf_trigger =
+ irq_flags =
irqd_get_trigger_type(irq_get_irq_data(client->irq));
+ irq_flags |= IRQF_SHARED | IRQF_ONESHOT;
ret = request_threaded_irq(client->irq, NULL,
- tda998x_irq_thread,
- irqf_trigger | IRQF_ONESHOT,
+ tda998x_irq_thread, irq_flags,
"tda998x", priv);
if (ret) {
dev_err(&client->dev,
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] drm/i2c: tda998x: allow sharing of the CEC device accesses
From: Russell King @ 2016-11-16 10:48 UTC (permalink / raw)
To: linux-arm-kernel
cec_read() is non-atomic in the presence of other I2C bus transactions
to the same device. This presents a problem when we add support for
the TDA9950 CEC engine part - both drivers can be trying to access the
device.
Avoid the inherent problems by switching to i2c_transfer() instead,
which allows us to perform more than one bus transaction atomically.
As this means we will be using I2C transactions rather than SMBUS, we
have to check that the host supports I2C functionality.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/gpu/drm/i2c/tda998x_drv.c | 53 +++++++++++++++++++++++++--------------
1 file changed, 34 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index 74fb59a35269..f59d6664315d 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -41,6 +41,7 @@ struct tda998x_priv {
struct i2c_client *hdmi;
struct mutex mutex;
u16 rev;
+ u8 cec_addr;
u8 current_page;
bool is_on;
bool supports_infoframes;
@@ -374,35 +375,46 @@ struct tda998x_priv {
static void
cec_write(struct tda998x_priv *priv, u16 addr, u8 val)
{
- struct i2c_client *client = priv->cec;
u8 buf[] = {addr, val};
+ struct i2c_msg msg = {
+ .addr = priv->cec_addr,
+ .len = 2,
+ .buf = buf,
+ };
int ret;
- ret = i2c_master_send(client, buf, sizeof(buf));
+ ret = i2c_transfer(priv->hdmi->adapter, &msg, 1);
if (ret < 0)
- dev_err(&client->dev, "Error %d writing to cec:0x%x\n", ret, addr);
+ dev_err(&priv->hdmi->dev, "Error %d writing to cec:0x%x\n",
+ ret, addr);
}
static u8
cec_read(struct tda998x_priv *priv, u8 addr)
{
- struct i2c_client *client = priv->cec;
u8 val;
+ struct i2c_msg msg[2] = {
+ {
+ .addr = priv->cec_addr,
+ .len = 1,
+ .buf = &addr,
+ }, {
+ .addr = priv->cec_addr,
+ .flags = I2C_M_RD,
+ .len = 1,
+ .buf = &val,
+ },
+ };
int ret;
- ret = i2c_master_send(client, &addr, sizeof(addr));
- if (ret < 0)
- goto fail;
-
- ret = i2c_master_recv(client, &val, sizeof(val));
- if (ret < 0)
- goto fail;
+ ret = i2c_transfer(priv->hdmi->adapter, msg, ARRAY_SIZE(msg));
+ if (ret < 0) {
+ dev_err(&priv->hdmi->dev, "Error %d reading from cec:0x%x\n",
+ ret, addr);
+ val = 0;
+ }
return val;
-
-fail:
- dev_err(&client->dev, "Error %d reading from cec:0x%x\n", ret, addr);
- return 0;
}
static int
@@ -1471,17 +1483,16 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv)
struct device_node *np = client->dev.of_node;
u32 video;
int rev_lo, rev_hi, ret;
- unsigned short cec_addr;
priv->vip_cntrl_0 = VIP_CNTRL_0_SWAP_A(2) | VIP_CNTRL_0_SWAP_B(3);
priv->vip_cntrl_1 = VIP_CNTRL_1_SWAP_C(0) | VIP_CNTRL_1_SWAP_D(1);
priv->vip_cntrl_2 = VIP_CNTRL_2_SWAP_E(4) | VIP_CNTRL_2_SWAP_F(5);
+ /* CEC I2C address bound to TDA998x I2C addr by configuration pins */
+ priv->cec_addr = 0x34 + (client->addr & 0x03);
priv->current_page = 0xff;
priv->hdmi = client;
- /* CEC I2C address bound to TDA998x I2C addr by configuration pins */
- cec_addr = 0x34 + (client->addr & 0x03);
- priv->cec = i2c_new_dummy(client->adapter, cec_addr);
+ priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
if (!priv->cec)
return -ENODEV;
@@ -1722,6 +1733,10 @@ static const struct component_ops tda998x_ops = {
static int
tda998x_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
+ if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
+ dev_warn(&client->dev, "adapter does not support I2C\n");
+ return -EIO;
+ }
return component_add(&client->dev, &tda998x_ops);
}
--
2.7.4
^ permalink raw reply related
* [PATCH v5 0/3] driver: Add DT support for DA8xx
From: Alexandre Bailon @ 2016-11-16 10:52 UTC (permalink / raw)
To: linux-arm-kernel
Changes in v2:
* Remove unrelated changes in patch 3
* Rename the device node in patch 4
Changes in v3:
* Fix few mistakes in DT binding sample
* Only build the device table if DT is enabled
Change in v4:
* Fix a nit
Changes in v5:
* Nothing. Resent the v4 in two seppaated series: one for platform and one for
driver.
Petr Kulhavy (3):
dt/bindings: Add binding for the DA8xx MUSB driver
usb: musb: core: added helper function for parsing DT
usb: musb: da8xx: Add DT support for the DA8xx driver
.../devicetree/bindings/usb/da8xx-usb.txt | 43 ++++++++++++++++++++
drivers/usb/musb/da8xx.c | 46 ++++++++++++++++++++++
drivers/usb/musb/musb_core.c | 19 +++++++++
drivers/usb/musb/musb_core.h | 6 +++
4 files changed, 114 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt
--
2.7.3
^ permalink raw reply
* [PATCH v5 1/3] dt/bindings: Add binding for the DA8xx MUSB driver
From: Alexandre Bailon @ 2016-11-16 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479293545-7516-1-git-send-email-abailon@baylibre.com>
From: Petr Kulhavy <petr@barix.com>
DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
Signed-off-by: Petr Kulhavy <petr@barix.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/usb/da8xx-usb.txt | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
new file mode 100644
index 0000000..ccb844a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
@@ -0,0 +1,43 @@
+TI DA8xx MUSB
+~~~~~~~~~~~~~
+For DA8xx/OMAP-L1x/AM17xx/AM18xx platforms.
+
+Required properties:
+~~~~~~~~~~~~~~~~~~~~
+ - compatible : Should be set to "ti,da830-musb".
+
+ - reg: Offset and length of the USB controller register set.
+
+ - interrupts: The USB interrupt number.
+
+ - interrupt-names: Should be set to "mc".
+
+ - dr_mode: The USB operation mode. Should be one of "host", "peripheral" or "otg".
+
+ - phys: Phandle for the PHY device
+
+ - phy-names: Should be "usb-phy"
+
+Optional properties:
+~~~~~~~~~~~~~~~~~~~~
+ - vbus-supply: Phandle to a regulator providing the USB bus power.
+
+Example:
+ usb_phy: usb-phy {
+ compatible = "ti,da830-usb-phy";
+ #phy-cells = <0>;
+ status = "okay";
+ };
+ usb0: usb at 200000 {
+ compatible = "ti,da830-musb";
+ reg = <0x00200000 0x10000>;
+ interrupts = <58>;
+ interrupt-names = "mc";
+
+ dr_mode = "host";
+ vbus-supply = <&usb_vbus>;
+ phys = <&usb_phy 0>;
+ phy-names = "usb-phy";
+
+ status = "okay";
+ };
--
2.7.3
^ permalink raw reply related
* [PATCH v5 2/3] usb: musb: core: added helper function for parsing DT
From: Alexandre Bailon @ 2016-11-16 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479293545-7516-1-git-send-email-abailon@baylibre.com>
From: Petr Kulhavy <petr@barix.com>
This adds the function musb_get_mode() to get the DT property "dr_mode"
Signed-off-by: Petr Kulhavy <petr@barix.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Tested-by: David Lechner <david@lechnology.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/usb/musb/musb_core.c | 19 +++++++++++++++++++
drivers/usb/musb/musb_core.h | 6 ++++++
2 files changed, 25 insertions(+)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index e01116e..9b44566 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
#include <linux/io.h>
#include <linux/dma-mapping.h>
#include <linux/usb.h>
+#include <linux/usb/of.h>
#include "musb_core.h"
#include "musb_trace.h"
@@ -130,6 +131,24 @@ static inline struct musb *dev_to_musb(struct device *dev)
return dev_get_drvdata(dev);
}
+enum musb_mode musb_get_mode(struct device *dev)
+{
+ enum usb_dr_mode mode;
+
+ mode = usb_get_dr_mode(dev);
+ switch (mode) {
+ case USB_DR_MODE_HOST:
+ return MUSB_HOST;
+ case USB_DR_MODE_PERIPHERAL:
+ return MUSB_PERIPHERAL;
+ case USB_DR_MODE_OTG:
+ case USB_DR_MODE_UNKNOWN:
+ default:
+ return MUSB_OTG;
+ }
+}
+EXPORT_SYMBOL_GPL(musb_get_mode);
+
/*-------------------------------------------------------------------------*/
#ifndef CONFIG_BLACKFIN
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 2cb88a49..76f00f6 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -617,4 +617,10 @@ static inline void musb_platform_post_root_reset_end(struct musb *musb)
musb->ops->post_root_reset_end(musb);
}
+/*
+ * gets the "dr_mode" property from DT and converts it into musb_mode
+ * if the property is not found or not recognized returns MUSB_OTG
+ */
+extern enum musb_mode musb_get_mode(struct device *dev);
+
#endif /* __MUSB_CORE_H__ */
--
2.7.3
^ permalink raw reply related
* [PATCH v5 3/3] usb: musb: da8xx: Add DT support for the DA8xx driver
From: Alexandre Bailon @ 2016-11-16 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479293545-7516-1-git-send-email-abailon@baylibre.com>
From: Petr Kulhavy <petr@barix.com>
This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver
Signed-off-by: Petr Kulhavy <petr@barix.com>
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Tested-by: David Lechner <david@lechnology.com>
---
drivers/usb/musb/da8xx.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 2440f88..f205a03 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -6,6 +6,9 @@
* Based on the DaVinci "glue layer" code.
* Copyright (C) 2005-2006 by Texas Instruments
*
+ * DT support
+ * Copyright (c) 2016 Petr Kulhavy <petr@barix.com>
+ *
* This file is part of the Inventra Controller Driver for Linux.
*
* The Inventra Controller Driver for Linux is free software; you
@@ -433,6 +436,21 @@ static int da8xx_musb_exit(struct musb *musb)
return 0;
}
+static inline u8 get_vbus_power(struct device *dev)
+{
+ struct regulator *vbus_supply;
+ int current_uA;
+
+ vbus_supply = regulator_get_optional(dev, "vbus");
+ if (IS_ERR(vbus_supply))
+ return 255;
+ current_uA = regulator_get_current_limit(vbus_supply);
+ regulator_put(vbus_supply);
+ if (current_uA <= 0 || current_uA > 510000)
+ return 255;
+ return current_uA / 1000 / 2;
+}
+
static const struct musb_platform_ops da8xx_ops = {
.quirks = MUSB_DMA_CPPI | MUSB_INDEXED_EP,
.init = da8xx_musb_init,
@@ -458,6 +476,12 @@ static const struct platform_device_info da8xx_dev_info = {
.dma_mask = DMA_BIT_MASK(32),
};
+static const struct musb_hdrc_config da8xx_config = {
+ .ram_bits = 10,
+ .num_eps = 5,
+ .multipoint = 1,
+};
+
static int da8xx_probe(struct platform_device *pdev)
{
struct resource musb_resources[2];
@@ -465,6 +489,7 @@ static int da8xx_probe(struct platform_device *pdev)
struct da8xx_glue *glue;
struct platform_device_info pinfo;
struct clk *clk;
+ struct device_node *np = pdev->dev.of_node;
int ret;
glue = devm_kzalloc(&pdev->dev, sizeof(*glue), GFP_KERNEL);
@@ -487,6 +512,16 @@ static int da8xx_probe(struct platform_device *pdev)
glue->dev = &pdev->dev;
glue->clk = clk;
+ if (IS_ENABLED(CONFIG_OF) && np) {
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata->config = &da8xx_config;
+ pdata->mode = musb_get_mode(&pdev->dev);
+ pdata->power = get_vbus_power(&pdev->dev);
+ }
+
pdata->platform_ops = &da8xx_ops;
glue->usb_phy = usb_phy_generic_register();
@@ -537,11 +572,22 @@ static int da8xx_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id da8xx_id_table[] = {
+ {
+ .compatible = "ti,da830-musb",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, da8xx_id_table);
+#endif
+
static struct platform_driver da8xx_driver = {
.probe = da8xx_probe,
.remove = da8xx_remove,
.driver = {
.name = "musb-da8xx",
+ .of_match_table = of_match_ptr(da8xx_id_table),
},
};
--
2.7.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox