* [PATCH 2/4] clk: samsung: Remove Exynos4415 driver (SoC not supported anymore)
From: Sylwester Nawrocki @ 2017-01-16 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170114123642.15581-3-krzk@kernel.org>
On 01/14/2017 01:36 PM, Krzysztof Kozlowski wrote:
> Support for Exynos4415 is going away because there are no internal nor
> external users.
>
> Since commit 46dcf0ff0de3 ("ARM: dts: exynos: Remove exynos4415.dtsi"),
> the platform cannot be instantiated so remove also the drivers.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Applied, thanks.
^ permalink raw reply
* [PATCH] usb: dwc3 dwc3_exynos_probe() change goto labels to meaningful names
From: Felipe Balbi @ 2017-01-16 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111164537.2981-1-shuahkh@osg.samsung.com>
Hi,
Shuah Khan <shuahkh@osg.samsung.com> writes:
> Change goto labels to meaningful names from a series of errNs.
>
> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
doesn't apply to testing/next, please rebase.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170116/ba4f2748/attachment.sig>
^ permalink raw reply
* [PATCH v7 0/4] arm64: arch_timer: Add workaround for hisilicon-161601 erratum
From: Ding Tianhong @ 2017-01-16 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <06fd3327-f451-bc0d-b80c-4200bc9fadaa@huawei.com>
On 2017/1/12 21:24, Ding Tianhong wrote:
>
> On 2017/1/12 17:11, Marc Zyngier wrote:
>> On 12/01/17 04:23, Ding Tianhong wrote:
>>> Hi Marc:
>>>
>>> How about this v7, if any suggestions very grateful.
>>
>> It's been less than 5 days since you posted this. I'll get to it once I
>> finish reviewing all the other patches that are sitting in the queue
>> right before yours.
>>
>
> Ok and sorry for the noisy.
>
Hi Marc?
After discussion with the chip developer, we decide to update the erratum id for this bug, so I will resend a new version
about this, if you has start to review this v7 patch set, I think I could wait until you have finished yet. :)
Thanks
Ding
> Thanks
> Ding
>
>> Thanks,
>>
>> M.
>>
^ permalink raw reply
* [PATCH v4] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Neil Armstrong @ 2017-01-16 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d3a00788-c3c1-4b10-90bf-2a8bc6a138f8@suse.de>
On 01/15/2017 03:43 PM, Andreas F?rber wrote:
> Am 13.01.2017 um 21:03 schrieb Kevin Hilman:
>> Neil Armstrong <narmstrong@baylibre.com> writes:
>>
>>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>>> this patch adds this reserved zone and redefines the usable memory range.
>>>
>>> The memory node is also moved from the dtsi files into the proper dts files
>>> to handle variants memory sizes.
>>>
>>> This patch also fixes the memory sizes for the following platforms :
>>> - gxl-s905x-p212 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>> - gxm-s912-q201 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>> - gxl-s905d-p231 : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>> - gxl-nexbox-a95x : 1GiB instead of 2GiB, a proper 2GiB dts should be pushed
>>>
>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>
>> Queued for v4.10-rc.
>
> What is the motivation for this change? I have a local U-Boot patch to
> detect the amount of memory available as done downstream, but U-Boot
> only updates the reg property that you seem to be abandoning here...
>
> So for devices that come in multiple RAM configurations - like R-Box Pro
> - this would require separate .dts files now! This looks very wrong to
> me, especially since I am not aware of other platforms doing the same.
> Instead, there's memory reservations for top and bottom done in U-Boot
> for reg, plus reserved-memory nodes for anything in the middle.
>
> Another thing to consider is that uEFI boot (bootefi) handles memory
> reservation differently yet again, on the bootloader level. I have had
> that working fine on Odroid-C2 and Vega S95.
>
> So if there's no bug this is fixing (none mentioned in commit message) I
> strongly object to this patch.
>
> Regards,
> Andreas
>
Hi Andreas,
Like I replied of my RFT patch :
I really disagree about relying on any work or properties added by any bootloader here, Amlogic SoCs has
a lot of u-boot versions in the field, and the Odroid-C2 is part of this.
Even if Odroid-c2 is in mainline U-Boot or not, the mainline Linux kernel should work using
any U-boot version even with the one provided by Amlogic on their openlinux distribution channel.
Handling multiple RAM configuration is another story, and the Arm-Soc and DT maintainers should give us
their advices.
Actually there is a severe bug fixed here that cause a huge crash if such memory is not reserved while
running stock u-boot version on various shipped products and Amlogic's own development boards.
The bug is easily triggered by running :
# stress --vm 4 --vm-bytes 128M --timeout 10s &
[ 46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
...
[ 47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
...
Note this is a fix targeted for 4.10 to make the system stable and various users reported some severe
crash now the system has more drivers and read-world use-cases are running on Amlogic SoCs.
Please feel free to push whatever changes that makes this memory reservation more coherent for 4.11,
and respect the behavior of already shipped u-boot version and mainline U-Boot, UEFI, whatever...
Neil
^ permalink raw reply
* [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems
From: Will Deacon @ 2017-01-16 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113201933-mutt-send-email-mst@kernel.org>
On Fri, Jan 13, 2017 at 08:23:35PM +0200, Michael S. Tsirkin wrote:
> On Fri, Jan 13, 2017 at 05:21:54PM +0000, Will Deacon wrote:
> > On Fri, Jan 13, 2017 at 06:46:32PM +0200, Michael S. Tsirkin wrote:
> > > On Fri, Jan 13, 2017 at 09:25:22AM +0000, Will Deacon wrote:
> > > > On Fri, Jan 13, 2017 at 12:12:56AM +0200, Michael S. Tsirkin wrote:
> > > > > I'd rather people didn't use SMMU with legacy devices.
> > > >
> > > > I'm afraid we've been doing that for two years and the model already
> > > > exists in a mature state, being actively used for development and
> > > > validation by ARM and our partners. One of the big things its used for
> > > > is to develop SMMU and GIC (our interrupt controller) code with PCI, so
> > > > dropping the SMMU from the picture isn't an option.
> > >
> > > Oh so this fixes a regression? This is something I didn't realize.
> >
> > Yes, thanks. The regression came about because we implemented SMMU-backed
> > DMA ops and only then was it apparent that the virtio stuff was bypassing
> > even with translation enabled (because it wasn't using the DMA API).
>
> Could you point out a commit ID?
There has been a fair amount of work in this area recently, but you're
probably after something like 876945dbf649 ("arm64: Hook up IOMMU dma_ops")
as the culprit, which is the point at which we started to swizzle DMA
ops for devices upstream of an SMMU automatically.
> > > A "Fixes:" tag can't hurt here. I then wonder
> > > might DMA ops ever use a DMA address which isn't a physical address
> > > from QEMU point of view? If that happens, this hack breaks
> > > because in legacy mode QEMU still uses the GPA.
> >
> > If QEMU doesn't advertise an SMMU, then it will work fine with the GPA,
> > because we won't swizzle the DMA ops for the master device. If QEMU does
> > advertise an SMMU, then we'll allocate DMA addresses to fit within the
> > the intersection of the SMMU aperture and device's DMA mask.
>
>
> Right but doesn't just poking from qemu into phys addresses work
> anymore? It used to ...
Provided that there's no SMMU, then it will continue to work. and my
understanding (from talking to Peter Maydell) is that qemu doesn't model
an SMMU for ARM-based machines.
Will
^ permalink raw reply
* [PATCH v3 1/2] of: base: add support to find the level of the last cache
From: Sudeep Holla @ 2017-01-16 10:40 UTC (permalink / raw)
To: linux-arm-kernel
It is useful to have helper function just to get the number of cache
levels for a given logical cpu. We can obtain the same by just checking
the level at which the last cache is present. This patch adds support
to find the level of the last cache for a given cpu.
It will be used on ARM64 platform where the device tree provides the
information for the additional non-architected/transparent/external
last level caches that are not integrated with the processors.
Cc: Mark Rutland <mark.rutland@arm.com>
Suggested-by: Rob Herring <robh+dt@kernel.org>
Acked-by: Rob Herring <robh+dt@kernel.org>
Tested-by: Tan Xiaojun <tanxiaojun@huawei.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/of/base.c | 26 ++++++++++++++++++++++++++
include/linux/of.h | 1 +
2 files changed, 27 insertions(+)
v2->v3:
- Dropped unnecessary pointer check
- Added Rob's Ack and Tan's Tested-by tags
v1->v2:
- Moved to using "cache-level" in the last level cache instead
of counting through all the nodes as suggested by Rob
diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4bea3c797d6..a30f541f0825 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -25,6 +25,7 @@
#include <linux/cpu.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/of_graph.h>
#include <linux/spinlock.h>
#include <linux/slab.h>
@@ -2268,6 +2269,31 @@ struct device_node *of_find_next_cache_node(const struct device_node *np)
}
/**
+ * of_find_last_cache_level - Find the level at which the last cache is
+ * present for the given logical cpu
+ *
+ * @cpu: cpu number(logical index) for which the last cache level is needed
+ *
+ * Returns the the level at which the last cache is present. It is exactly
+ * same as the total number of cache levels for the given logical cpu.
+ */
+int of_find_last_cache_level(unsigned int cpu)
+{
+ int cache_level = 0;
+ struct device_node *prev = NULL, *np = of_cpu_device_node_get(cpu);
+
+ while (np) {
+ prev = np;
+ of_node_put(np);
+ np = of_find_next_cache_node(np);
+ }
+
+ of_property_read_u32(prev, "cache-level", &cache_level);
+
+ return cache_level;
+}
+
+/**
* of_graph_parse_endpoint() - parse common endpoint node properties
* @node: pointer to endpoint device_node
* @endpoint: pointer to the OF endpoint data structure
diff --git a/include/linux/of.h b/include/linux/of.h
index d72f01009297..21e6323de0f3 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -280,6 +280,7 @@ extern struct device_node *of_get_child_by_name(const struct device_node *node,
/* cache lookup */
extern struct device_node *of_find_next_cache_node(const struct device_node *);
+extern int of_find_last_cache_level(unsigned int cpu);
extern struct device_node *of_find_node_with_property(
struct device_node *from, const char *prop_name);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/2] arm64: cacheinfo: add support to override cache levels via device tree
From: Sudeep Holla @ 2017-01-16 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484563244-14743-1-git-send-email-sudeep.holla@arm.com>
The cache hierarchy can be identified through Cache Level ID(CLIDR)
architected system register. However in some cases it will provide
only the number of cache levels that are integrated into the processor
itself. In other words, it can't provide any information about the
caches that are external and/or transparent.
Some platforms require to export the information about all such external
caches to the userspace applications via the sysfs interface.
This patch adds support to override the cache levels using device tree
to take such external non-architected caches into account.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Tested-by: Tan Xiaojun <tanxiaojun@huawei.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/kernel/cacheinfo.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/cacheinfo.c b/arch/arm64/kernel/cacheinfo.c
index 9617301f76b5..3f2250fc391b 100644
--- a/arch/arm64/kernel/cacheinfo.c
+++ b/arch/arm64/kernel/cacheinfo.c
@@ -84,7 +84,7 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
static int __init_cache_level(unsigned int cpu)
{
- unsigned int ctype, level, leaves;
+ unsigned int ctype, level, leaves, of_level;
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
for (level = 1, leaves = 0; level <= MAX_CACHE_LEVEL; level++) {
@@ -97,6 +97,17 @@ static int __init_cache_level(unsigned int cpu)
leaves += (ctype == CACHE_TYPE_SEPARATE) ? 2 : 1;
}
+ of_level = of_find_last_cache_level(cpu);
+ if (level < of_level) {
+ /*
+ * some external caches not specified in CLIDR_EL1
+ * the information may be available in the device tree
+ * only unified external caches are considered here
+ */
+ leaves += (of_level - level);
+ level = of_level;
+ }
+
this_cpu_ci->num_levels = level;
this_cpu_ci->num_leaves = leaves;
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] Broadcom USB DRD Phy driver for Northstar2
From: Raviteja Garimella @ 2017-01-16 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <587C90E2.5020105@ti.com>
Hi Kishon,
On Mon, Jan 16, 2017 at 2:52 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi,
>
> On Wednesday 30 November 2016 11:25 AM, Raviteja Garimella wrote:
>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>> SoC. The phy can be configured to be in Device mode or Host
>> mode based on the type of cable connected to the port. The
>> driver registers to extcon framework to get appropriate
>> connect events for Host/Device cables connect/disconnect
>> states based on VBUS and ID interrupts.
>>
>> Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
>> ---
>> drivers/phy/Kconfig | 13 +
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-bcm-ns2-usbdrd.c | 587 +++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 601 insertions(+)
>> create mode 100644 drivers/phy/phy-bcm-ns2-usbdrd.c
>>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index fe00f91..b3b6a73 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -479,6 +479,19 @@ config PHY_CYGNUS_PCIE
>> Enable this to support the Broadcom Cygnus PCIe PHY.
>> If unsure, say N.
>>
>> +config PHY_NS2_USB_DRD
>> + tristate "Broadcom Northstar2 USB DRD PHY support"
>> + depends on OF && (ARCH_BCM_IPROC || COMPILE_TEST)
>> + select GENERIC_PHY
>> + select EXTCON
>> + default ARCH_BCM_IPROC
>> + help
>> + Enable this to support the Broadcom Northstar2 USB DRD PHY.
>> + This driver initializes the PHY in either HOST or DEVICE mode.
>> + The host or device configuration is read from device tree.
>> +
>> + If unsure, say N.
>> +
>> source "drivers/phy/tegra/Kconfig"
>>
>> config PHY_NS2_PCIE
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index a534cf5..b733ba2 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -58,5 +58,6 @@ obj-$(CONFIG_PHY_TUSB1210) += phy-tusb1210.o
>> obj-$(CONFIG_PHY_BRCM_SATA) += phy-brcm-sata.o
>> obj-$(CONFIG_PHY_PISTACHIO_USB) += phy-pistachio-usb.o
>> obj-$(CONFIG_PHY_CYGNUS_PCIE) += phy-bcm-cygnus-pcie.o
>> +obj-$(CONFIG_PHY_NS2_USB_DRD) += phy-bcm-ns2-usbdrd.o
>> obj-$(CONFIG_ARCH_TEGRA) += tegra/
>> obj-$(CONFIG_PHY_NS2_PCIE) += phy-bcm-ns2-pcie.o
>> diff --git a/drivers/phy/phy-bcm-ns2-usbdrd.c b/drivers/phy/phy-bcm-ns2-usbdrd.c
>> new file mode 100644
>> index 0000000..460040d
>> --- /dev/null
>> +++ b/drivers/phy/phy-bcm-ns2-usbdrd.c
>> @@ -0,0 +1,587 @@
>> +/*
>> + * Copyright (C) 2016 Broadcom
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation version 2.
>> + *
>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/delay.h>
>> +#include <linux/extcon.h>
>> +#include <linux/gpio.h>
>> +#include <linux/gpio/consumer.h>
>> +#include <linux/init.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/io.h>
>> +#include <linux/irq.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/phy/phy.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/regmap.h>
>> +#include <linux/slab.h>
>> +#include <linux/workqueue.h>
>> +
>> +#define ICFG_DRD_AFE 0x0
>> +#define ICFG_MISC_STAT 0x18
>> +#define ICFG_DRD_P0CTL 0x1C
>> +#define ICFG_STRAP_CTRL 0x20
>> +#define ICFG_FSM_CTRL 0x24
>> +
>> +#define IDM_RST_BIT BIT(0)
>> +#define AFE_CORERDY_VDDC BIT(18)
>> +#define PHY_PLL_RESETB BIT(15)
>> +#define PHY_RESETB BIT(14)
>> +#define PHY_PLL_LOCK BIT(0)
>> +
>> +#define DRD_DEV_MODE BIT(20)
>> +#define OHCI_OVRCUR_POL BIT(11)
>> +#define ICFG_OFF_MODE BIT(6)
>> +#define PLL_LOCK_RETRY 1000
>> +
>> +#define EVT_DEVICE 0
>> +#define EVT_HOST 1
>> +#define EVT_IDLE 2
>> +
>> +#define DRD_HOST_MODE (BIT(2) | BIT(3))
>> +#define DRD_DEVICE_MODE (BIT(4) | BIT(5))
>> +#define DRD_HOST_VAL 0x803
>> +#define DRD_DEV_VAL 0x807
>> +#define GPIO_DELAY 20
>> +#define PHY_WQ_DELAY msecs_to_jiffies(600)
>> +
>> +struct ns2_phy_data;
>> +struct ns2_phy_driver {
>> + void __iomem *icfgdrd_regs;
>> + void __iomem *idmdrd_rst_ctrl;
>> + void __iomem *crmu_usb2_ctrl;
>> + void __iomem *usb2h_strap_reg;
>> + spinlock_t lock; /* spin lock for phy driver */
>> + bool host_mode;
>> + struct ns2_phy_data *data;
>> + struct extcon_specific_cable_nb extcon_dev;
>> + struct extcon_specific_cable_nb extcon_host;
>> + struct notifier_block host_nb;
>> + struct notifier_block dev_nb;
>> + struct delayed_work conn_work;
>> + struct extcon_dev *edev;
>> + struct gpio_desc *vbus_gpiod;
>> + struct gpio_desc *id_gpiod;
>> + int id_irq;
>> + int vbus_irq;
>> + unsigned long debounce_jiffies;
>> + struct delayed_work wq_extcon;
>> +};
>> +
>> +struct ns2_phy_data {
>> + struct ns2_phy_driver *driver;
>> + struct phy *phy;
>> + int new_state;
>> + bool poweron;
>> +};
>> +
>> +static const unsigned int usb_extcon_cable[] = {
>> + EXTCON_USB,
>> + EXTCON_USB_HOST,
>> + EXTCON_NONE,
>> +};
>> +
>> +static inline int pll_lock_stat(u32 usb_reg, int reg_mask,
>> + struct ns2_phy_driver *driver)
>> +{
>> + int retry = PLL_LOCK_RETRY;
>> + u32 val;
>> +
>> + do {
>> + udelay(1);
>> + val = readl(driver->icfgdrd_regs + usb_reg);
>> + if (val & reg_mask)
>> + return 0;
>> + } while (--retry > 0);
>> +
>> + return -EBUSY;
>> +}
>> +
>> +static int ns2_drd_phy_init(struct phy *phy)
>> +{
>> + struct ns2_phy_data *data = phy_get_drvdata(phy);
>> + struct ns2_phy_driver *driver = data->driver;
>> + unsigned long flags;
>> + u32 val;
>> +
>> + spin_lock_irqsave(&driver->lock, flags);
>> +
>> + val = readl(driver->icfgdrd_regs + ICFG_FSM_CTRL);
>> +
>> + if (data->new_state == EVT_HOST) {
>> + val &= ~DRD_DEVICE_MODE;
>> + val |= DRD_HOST_MODE;
>> + } else {
>> + val &= ~DRD_HOST_MODE;
>> + val |= DRD_DEVICE_MODE;
>> + }
>> + writel(val, driver->icfgdrd_regs + ICFG_FSM_CTRL);
>> +
>> + spin_unlock_irqrestore(&driver->lock, flags);
>> + return 0;
>> +}
>> +
>> +static int ns2_drd_phy_shutdown(struct phy *phy)
>> +{
>> + struct ns2_phy_data *data = phy_get_drvdata(phy);
>> + struct ns2_phy_driver *driver = data->driver;
>> + unsigned long flags;
>> + u32 val;
>> +
>> + spin_lock_irqsave(&driver->lock, flags);
>> + if (!data->poweron)
>> + goto exit;
>> +
>> + val = readl(driver->crmu_usb2_ctrl);
>> + val &= ~AFE_CORERDY_VDDC;
>> + writel(val, driver->crmu_usb2_ctrl);
>> +
>> + driver->host_mode = 0;
>> + val = readl(driver->crmu_usb2_ctrl);
>> + val &= ~DRD_DEV_MODE;
>> + writel(val, driver->crmu_usb2_ctrl);
>> +
>> + /* Disable Host and Device Mode */
>> + val = readl(driver->icfgdrd_regs + ICFG_FSM_CTRL);
>> + val &= ~(DRD_HOST_MODE | DRD_DEVICE_MODE | ICFG_OFF_MODE);
>> + writel(val, driver->icfgdrd_regs + ICFG_FSM_CTRL);
>> +
>> + data->poweron = 0;
>> +exit:
>> + spin_unlock_irqrestore(&driver->lock, flags);
>> + return 0;
>> +}
>> +
>> +static int ns2_drd_phy_poweron(struct phy *phy)
>> +{
>> + struct ns2_phy_data *data = phy_get_drvdata(phy);
>> + struct ns2_phy_driver *driver = data->driver;
>> + u32 extcon_event = data->new_state;
>> + unsigned long flags;
>> + int ret;
>> + u32 val;
>> +
>> + spin_lock_irqsave(&driver->lock, flags);
>> + if (extcon_event == EVT_DEVICE) {
>> + if (data->poweron)
>> + goto exit;
>> +
>> + writel(DRD_DEV_VAL, driver->icfgdrd_regs + ICFG_DRD_P0CTL);
>> +
>> + val = readl(driver->icfgdrd_regs + ICFG_FSM_CTRL);
>> + val &= ~(DRD_HOST_MODE | ICFG_OFF_MODE);
>> + val |= DRD_DEVICE_MODE;
>> + writel(val, driver->icfgdrd_regs + ICFG_FSM_CTRL);
>> +
>> + val = readl(driver->idmdrd_rst_ctrl);
>> + val &= ~IDM_RST_BIT;
>> + writel(val, driver->idmdrd_rst_ctrl);
>> +
>> + val = readl(driver->crmu_usb2_ctrl);
>> + val |= (AFE_CORERDY_VDDC | DRD_DEV_MODE);
>> + writel(val, driver->crmu_usb2_ctrl);
>> +
>> + /* Bring PHY and PHY_PLL out of Reset */
>> + val = readl(driver->crmu_usb2_ctrl);
>> + val |= (PHY_PLL_RESETB | PHY_RESETB);
>> + writel(val, driver->crmu_usb2_ctrl);
>> +
>> + ret = pll_lock_stat(ICFG_MISC_STAT, PHY_PLL_LOCK, driver);
>> + if (ret < 0) {
>> + dev_err(&phy->dev, "Phy PLL lock failed\n");
>> + goto err_shutdown;
>> + }
>> + } else {
>> + if (data->poweron && driver->host_mode)
>> + goto exit;
>> +
>> + writel(DRD_HOST_VAL, driver->icfgdrd_regs + ICFG_DRD_P0CTL);
>> +
>> + val = readl(driver->icfgdrd_regs + ICFG_FSM_CTRL);
>> + val &= ~(DRD_DEVICE_MODE | ICFG_OFF_MODE);
>> + val |= DRD_HOST_MODE;
>> + writel(val, driver->icfgdrd_regs + ICFG_FSM_CTRL);
>> +
>> + val = readl(driver->crmu_usb2_ctrl);
>> + val |= AFE_CORERDY_VDDC;
>> + writel(val, driver->crmu_usb2_ctrl);
>> +
>> + ret = pll_lock_stat(ICFG_MISC_STAT, PHY_PLL_LOCK, driver);
>> + if (ret < 0) {
>> + dev_err(&phy->dev, "Phy PLL lock failed\n");
>> + goto err_shutdown;
>> + }
>> +
>> + val = readl(driver->idmdrd_rst_ctrl);
>> + val &= ~IDM_RST_BIT;
>> + writel(val, driver->idmdrd_rst_ctrl);
>> +
>> + /* port over current Polarity */
>> + val = readl(driver->usb2h_strap_reg);
>> + val |= OHCI_OVRCUR_POL;
>> + writel(val, driver->usb2h_strap_reg);
>> +
>> + driver->host_mode = 1;
>> + }
>> +
>> + data->poweron = 1;
>> +exit:
>> + spin_unlock_irqrestore(&driver->lock, flags);
>> + return 0;
>> +
>> +err_shutdown:
>> + data->poweron = 1;
>> + spin_unlock_irqrestore(&driver->lock, flags);
>> + ns2_drd_phy_shutdown(phy);
>> + return ret;
>> +}
>> +
>> +static void connect_work(struct work_struct *work)
>> +{
>> + struct ns2_phy_driver *driver;
>> + struct ns2_phy_data *data;
>> + u32 extcon_event;
>> +
>> + driver = container_of(to_delayed_work(work),
>> + struct ns2_phy_driver, conn_work);
>> + data = driver->data;
>> + extcon_event = data->new_state;
>> +
>> + if (extcon_event == EVT_DEVICE || extcon_event == EVT_HOST) {
>> + ns2_drd_phy_init(data->phy);
>> + ns2_drd_phy_poweron(data->phy);
>> + } else if (extcon_event == EVT_IDLE) {
>> + ns2_drd_phy_shutdown(data->phy);
>> + }
>> +}
>> +
>> +static int drd_device_notify(struct notifier_block *self,
>> + unsigned long event, void *ptr)
>> +{
>> + struct ns2_phy_driver *driver = container_of(self,
>> + struct ns2_phy_driver, dev_nb);
>> +
>> + if (event) {
>> + pr_debug("Device connected\n");
>> + driver->data->new_state = EVT_DEVICE;
>> + schedule_delayed_work(&driver->conn_work, 0);
>> + } else {
>> + pr_debug("Device disconnected\n");
>> + driver->data->new_state = EVT_IDLE;
>> + schedule_delayed_work(&driver->conn_work, PHY_WQ_DELAY);
>> + }
>> +
>> + return NOTIFY_DONE;
>> +}
>> +
>> +static int drd_host_notify(struct notifier_block *self,
>> + unsigned long event, void *ptr)
>> +{
>> + struct ns2_phy_driver *driver = container_of(self,
>> + struct ns2_phy_driver, host_nb);
>> +
>> + if (event) {
>> + pr_debug("Host connected\n");
>> + driver->data->new_state = EVT_HOST;
>> + schedule_delayed_work(&driver->conn_work, 0);
>> + } else {
>> + pr_debug("Host disconnected\n");
>> + driver->data->new_state = EVT_IDLE;
>> + schedule_delayed_work(&driver->conn_work, PHY_WQ_DELAY);
>> + }
>> +
>> + return NOTIFY_DONE;
>> +}
>> +
>> +static void extcon_work(struct work_struct *work)
>> +{
>> + struct ns2_phy_driver *driver;
>> + int vbus;
>> + int id;
>> +
>> + driver = container_of(to_delayed_work(work),
>> + struct ns2_phy_driver, wq_extcon);
>> +
>> + id = gpiod_get_value_cansleep(driver->id_gpiod);
>> + vbus = gpiod_get_value_cansleep(driver->vbus_gpiod);
>> +
>> + if (!id && vbus) {
>> + extcon_set_cable_state_(driver->edev, EXTCON_USB_HOST, true);
>> + } else if (id && !vbus) {
>> + extcon_set_cable_state_(driver->edev, EXTCON_USB_HOST, false);
>> + extcon_set_cable_state_(driver->edev, EXTCON_USB, false);
>> + } else if (id && vbus) {
>> + extcon_set_cable_state_(driver->edev, EXTCON_USB, true);
>> + }
>> +}
>> +
>> +static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
>> +{
>> + struct ns2_phy_driver *driver = dev_id;
>> +
>> + queue_delayed_work(system_power_efficient_wq, &driver->wq_extcon,
>> + driver->debounce_jiffies);
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static int register_extcon_notifier(struct ns2_phy_driver *phy_driver,
>> + struct device *dev)
>> +{
>> + struct extcon_dev *edev;
>> + int ret;
>> +
>> + phy_driver->host_nb.notifier_call = drd_host_notify;
>> + phy_driver->dev_nb.notifier_call = drd_device_notify;
>> +
>> + edev = phy_driver->edev;
>> +
>> + /* Register for device change notification */
>> + ret = extcon_register_notifier(edev, EXTCON_USB,
>> + &phy_driver->dev_nb);
>> + if (ret < 0) {
>> + dev_err(dev, "can't register extcon_dev for %s\n", edev->name);
>> + return ret;
>> + }
>> +
>> + /* Register for host change notification */
>> + ret = extcon_register_notifier(edev, EXTCON_USB_HOST,
>> + &phy_driver->host_nb);
>> + if (ret < 0) {
>> + dev_err(dev, "can't register extcon_dev for %s\n", edev->name);
>> + goto err_dev;
>> + }
>> +
>> + /* Check the device cable connect state */
>> + ret = extcon_get_cable_state_(edev, EXTCON_USB);
>> + if (ret < 0) {
>> + dev_err(dev, "can't get extcon_dev state for %s\n", edev->name);
>> + goto err_host;
>> + } else if (ret) {
>> + phy_driver->data->new_state = EVT_DEVICE;
>> + }
>> +
>> + /* Check the host cable connect state */
>> + ret = extcon_get_cable_state_(edev, EXTCON_USB_HOST);
>> + if (ret < 0) {
>> + dev_err(dev, "can't get extcon_dev state for %s\n", edev->name);
>> + goto err_host;
>> + } else if (ret) {
>> + phy_driver->data->new_state = EVT_HOST;
>> + }
>> +
>> + return 0;
>> +
>> +err_host:
>> + ret = extcon_unregister_notifier(edev, EXTCON_USB_HOST,
>> + &phy_driver->host_nb);
>> +err_dev:
>> + ret = extcon_unregister_notifier(edev, EXTCON_USB,
>> + &phy_driver->dev_nb);
>> + return ret;
>> +}
>> +
>> +static struct phy_ops ops = {
>> + .init = ns2_drd_phy_init,
>
> Is this really being used by any controller driver? Can you point me to the
> controller driver that is using this driver?
This will be used by Synopsys UDC that's integrated into Broadcom's Northstar2
and Cygnus SoC's. I am currently working on upstream review comments for the
same in a different patch series. The "amd5536udc" driver is being modified for
platform device support (as per the suggestions I received in reviews).
>
>> + .power_on = ns2_drd_phy_poweron,
>> + .power_off = ns2_drd_phy_shutdown,
>
> missing .owner.
Will fix this.
Thanks,
Ravi
>
> Thanks
> Kishon
^ permalink raw reply
* USB: OHCI: high softirq load
From: Antoine Aubert @ 2017-01-16 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ad8a54c3-c83d-109f-5cc5-7e77e9deff12@overkiz.com>
Also, I made a big misunderstanding
With EHCI + OHCI = high level of softirq (USB2.0)
OHCI only = normal level
Le 16/01/2017 ? 11:31, Antoine Aubert a ?crit :
> Thx for your answer Boris
>
> Le 16/01/2017 ? 10:02, Boris Brezillon a ?crit :
>> Hi Antoine,
>>
>> On Mon, 16 Jan 2017 08:45:58 +0100
>> Antoine Aubert <a.aubert@overkiz.com> wrote:
>>
>>> Hi,
>>>
>>> Im working on a AT91SAM9G25cu board
>>> (arch/arm/boot/dts/at91-kizboxmini.dts). We use linux-4.1.31, and when
>>> OHCI is enabled, I got some wired effects.
>> Can you test on a more recent kernel (4.9 or 4.10-rc4)?
> I'll give a try, just need little time ;)
>>> eg with 3 FTDI pluged, interrupts: more than 3.5k/s, cpu softirq > 24%,
>>> loadavg > 0.5
>> Can you check which interrupt is triggered (cat /proc/interrupts),
> cat /proc/interrupts
> CPU0
> 16: 2286 atmel-aic 1 Level pmc, at91_tick, at91_rtc, ttyS0
> 17: 0 PMC 17 Level main_rc_osc
> 18: 0 PMC 0 Level main_osc
> 19: 0 PMC 16 Level mainck
> 20: 0 PMC 1 Level clk-plla
> 21: 0 PMC 6 Level clk-utmi
> 22: 0 PMC 3 Level clk-master
> 23: 945527 atmel-aic 17 Level tc_clkevt
> 24: 21815 atmel-aic 20 Level at_hdmac
> 25: 0 atmel-aic 21 Level at_hdmac
> 30: 120299 atmel-aic 24 Level eth0
> 31: 22783651 atmel-aic 22 Level ehci_hcd:usb1, ohci_hcd:usb2
> 99: 0 GPIO 16 Edge PB_RST
> 100: 0 GPIO 17 Edge PB_PROG
> Err: 0
>
>> and
>> enable debug messages in drivers/usb/host/ohci-at91.c?
> [ 0.000000] Booting Linux on physical CPU 0x0
> [ 0.000000] Linux version 4.1.31 (antoine at ltp.antoine) (gcc version
> 4.9.2 (GCC) ) #1 Mon Jan 16 11:04:03 CET 2017
> [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
> [ 0.000000] CPU: VIVT data cache, VIVT instruction cache
> [ 0.000000] Machine model: Overkiz Kizbox Mini RailDIN
> [ 0.000000] bootconsole [earlycon0] enabled
> [ 0.000000] Memory policy: Data cache writeback
> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 32512
> [ 0.000000] Kernel command line: panic=5 oops=panic root=ubi0:root
> rootfstype=ubifs ubi.mtd=ubi rw console=ttyS0,115200 earlyprintk
> loglevel=7 dyndbg='file ohci-at91.c +p'
> [ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
> [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536
> bytes)
> [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> [ 0.000000] Memory: 125076K/131072K available (3204K kernel code,
> 136K rwdata, 1116K rodata, 132K init, 84K bss, 5996K reserved, 0K
> cma-reserved)
> [ 0.000000] Virtual kernel memory layout:
> [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
> [ 0.000000] vmalloc : 0xc8800000 - 0xff000000 ( 872 MB)
> [ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB)
> [ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
> [ 0.000000] .text : 0xc0008000 - 0xc04404b4 (4322 kB)
> [ 0.000000] .init : 0xc0441000 - 0xc0462000 ( 132 kB)
> [ 0.000000] .data : 0xc0462000 - 0xc0484310 ( 137 kB)
> [ 0.000000] .bss : 0xc0484310 - 0xc0499550 ( 85 kB)
> [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> [ 0.000000] NR_IRQS:16 nr_irqs:16 16
> [ 0.000000] clocksource pit: mask: 0x7ffffff max_cycles: 0x7ffffff,
> max_idle_ns: 7167226906 ns
> [ 0.000000] sched_clock: 32 bits at 128 Hz, resolution 7812500ns,
> wraps every 16777215996093750ns
> [ 0.007812] Calibrating delay loop... 198.76 BogoMIPS (lpj=775168)
> [ 0.078125] pid_max: default: 32768 minimum: 301
> [ 0.085937] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
> [ 0.093750] Mountpoint-cache hash table entries: 1024 (order: 0, 4096
> bytes)
> [ 0.101562] CPU: Testing write buffer coherency: ok
> [ 0.101562] Setting up static identity map for 0x20008400 - 0x2000847c
> [ 0.117187] dynamic_debug:ddebug_tokenize: unclosed quote: file
> [ 0.125000] dynamic_debug:ddebug_exec_query: tokenize failed
> [ 0.132812] devtmpfs: initialized
> [ 0.164062] clocksource jiffies: mask: 0xffffffff max_cycles:
> 0xffffffff, max_idle_ns: 14931722236523437 ns
> [ 0.171875] pinctrl core: initialized pinctrl subsystem
> [ 0.179687] NET: Registered protocol family 16
> [ 0.187500] DMA: preallocated 256 KiB pool for atomic coherent
> allocations
> [ 0.195312] AT91: Detected SoC family: at91sam9x5
> [ 0.203125] AT91: Detected SoC: at91sam9g25, revision 1
> [ 0.226562] gpio-at91 fffff400.gpio: at address fefff400
> [ 0.234375] gpio-at91 fffff600.gpio: at address fefff600
> [ 0.242187] gpio-at91 fffff800.gpio: at address fefff800
> [ 0.250000] gpio-at91 fffffa00.gpio: at address fefffa00
> [ 0.257812] pinctrl-at91 ahb:apb:pinctrl at fffff400: initialized AT91
> pinctrl driver
> [ 0.265625] clocksource tcb_clksrc: mask: 0xffffffff max_cycles:
> 0xffffffff, max_idle_ns: 114675631333 ns
> [ 4.718750] UDP hash table entries: 256 (order: 0, 4096 bytes)
> [ 4.726562] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> [ 4.734375] NET: Registered protocol family 1
> [ 4.742187] futex hash table entries: 256 (order: -1, 3072 bytes)
> [ 4.789062] squashfs: version 4.0 (2009/01/31) Phillip Lougher
> [ 4.804687] io scheduler noop registered (default)
> [ 4.812500] fffff200.serial: ttyS0 at MMIO 0xfffff200 (irq = 16,
> base_baud = 8333333) is a ATMEL_SERIAL
> [ 4.820312] console [ttyS0] enabled
> [ 4.828125] bootconsole [earlycon0] disabled
> [ 4.851562] brd: module loaded
> [ 4.882812] loop: module loaded
> [ 4.898437] atmel_nand 40000000.nand: Use On Flash BBT
> [ 4.898437] atmel_nand 40000000.nand: Using dma0chan0 for DMA transfers.
> [ 4.906250] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xf1
> [ 4.914062] nand: Micron MT29F1G08ABAEAWP
> [ 4.921875] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048,
> OOB size: 64
> [ 4.929687] atmel_nand 40000000.nand: minimum ECC: 4 bits in 512 bytes
> [ 4.929687] atmel_nand 40000000.nand: Initialize PMECC params, cap:
> 4, sector: 512
> [ 4.945312] Bad block table found at page 65472, version 0x01
> [ 4.945312] Bad block table found at page 65408, version 0x01
> [ 4.953125] 2 ofpart partitions found on MTD device atmel_nand
> [ 4.960937] Creating 2 MTD partitions on "atmel_nand":
> [ 4.968750] 0x000000000000-0x000000020000 : "bootstrap"
> [ 4.976562] 0x000000020000-0x000008000000 : "ubi"
> [ 4.992187] macb f802c000.ethernet (unnamed net_device)
> (uninitialized): invalid hw address, using random
> [ 5.000000] libphy: MACB_mii_bus: probed
> [ 5.093750] macb f802c000.ethernet eth0: Cadence MACB rev 0x0001010c
> at 0xf802c000 irq 30 (8e:06:02:88:ed:97)
> [ 5.101562] macb f802c000.ethernet eth0: attached PHY driver [Micrel
> KSZ8081 or KSZ8091] (mii_bus:phy_addr=f802c000.etherne:01, irq=-1)
> [ 5.109375] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [ 5.117187] ehci-atmel: EHCI Atmel driver
> [ 5.125000] atmel-ehci 700000.ehci: EHCI Host Controller
> [ 5.125000] atmel-ehci 700000.ehci: new USB bus registered, assigned
> bus number 1
> [ 5.140625] atmel-ehci 700000.ehci: irq 31, io mem 0x00700000
> [ 5.156250] atmel-ehci 700000.ehci: USB 2.0 started, EHCI 1.00
> [ 5.156250] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> [ 5.164062] usb usb1: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [ 5.171875] usb usb1: Product: EHCI Host Controller
> [ 5.179687] usb usb1: Manufacturer: Linux 4.1.31 ehci_hcd
> [ 5.179687] usb usb1: SerialNumber: 700000.ehci
> [ 5.187500] hub 1-0:1.0: USB hub found
> [ 5.195312] hub 1-0:1.0: 3 ports detected
> [ 5.203125] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [ 5.203125] ohci-atmel: OHCI Atmel driver
> [ 5.210937] at91_ohci 600000.ohci: start
> [ 5.210937] at91_ohci 600000.ohci: USB Host Controller
> [ 5.218750] at91_ohci 600000.ohci: new USB bus registered, assigned
> bus number 2
> [ 5.226562] at91_ohci 600000.ohci: irq 31, io mem 0x00600000
> [ 5.289062] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
> [ 5.296875] usb usb2: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [ 5.304687] usb usb2: Product: USB Host Controller
> [ 5.304687] usb usb2: Manufacturer: Linux 4.1.31 ohci_hcd
> [ 5.312500] usb usb2: SerialNumber: at91
> [ 5.320312] hub 2-0:1.0: USB hub found
> [ 5.320312] at91_ohci 600000.ohci:
> ohci_at91_hub_control(c7a86800,0xa006,0x2900,0x0000,c78b8b60,000f)
> [ 5.320312] at91_ohci 600000.ohci: wHubCharacteristics 0x0002
> [ 5.328125] at91_ohci 600000.ohci: wHubCharacteristics after 0x0001
> [ 5.328125] hub 2-0:1.0: 1 port detected
> [ 5.328125] at91_ohci 600000.ohci:
> ohci_at91_hub_control(c7a86800,0xa000,0x0000,0x0000,c78b8b80,0004)
> [ 5.328125] at91_ohci 600000.ohci:
> ohci_at91_hub_control(c7a86800,0x2303,0x0008,0x0001,c78b8c00,0000)
> [ 5.328125] at91_ohci 600000.ohci: SetPortFeat: POWER
> [ 5.328125] rtc rtc0: alarm rollover not handled
> [ 5.335937] rtc rtc0: invalid alarm value: 1900-1-1 0:0:0
> [ 5.343750] at91_rtc fffffeb0.rtc: rtc core: registered fffffeb0.rtc
> as rtc0
> [ 5.351562] at91_rtc fffffeb0.rtc: AT91 Real Time Clock driver.
> [ 5.359375] AT91: Starting after software reset
> [ 5.367187] at91sam9_wdt: enabled (heartbeat=15 sec, nowayout=1)
> [ 5.375000] hidraw: raw HID events driver (C) Jiri Kosina
> [ 5.382812] usbcore: registered new interface driver usbhid
> [ 5.382812] usbhid: USB HID core driver
> [ 5.390625] NET: Registered protocol family 17
> [ 5.398437] bridge: automatic filtering via arp/ip/ip6tables has been
> deprecated. Update your scripts to load br_netfilter if you need this.
> [ 5.421875] ubi0: attaching mtd1
> [ 5.429687] at91_ohci 600000.ohci:
> ohci_at91_hub_control(c7a86800,0xa300,0x0000,0x0001,c7980a00,0004)
> [ 5.429687] at91_ohci 600000.ohci: GetPortStatus(0)
> [ 5.546875] usb 1-1: new high-speed USB device number 2 using atmel-ehci
> [ 5.703125] usb 1-1: New USB device found, idVendor=0424, idProduct=2512
> [ 5.703125] usb 1-1: New USB device strings: Mfr=0, Product=0,
> SerialNumber=0
> [ 5.718750] hub 1-1:1.0: USB hub found
> [ 5.718750] hub 1-1:1.0: 2 ports detected
> [ 5.906250] ubi0: scanning is finished
> [ 5.929687] ubi0: attached mtd1 (name "ubi", size 127 MiB)
> [ 5.937500] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976
> bytes
> [ 5.945312] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
> [ 5.945312] ubi0: VID header offset: 2048 (aligned 2048), data
> offset: 4096
> [ 5.953125] ubi0: good PEBs: 1019, bad PEBs: 4, corrupted PEBs: 0
> [ 5.960937] ubi0: user volume: 9, internal volumes: 1, max. volumes
> count: 128
> [ 5.968750] ubi0: max/mean erase counter: 22/16, WL threshold: 4096,
> image sequence number: 1226704751
> [ 5.976562] ubi0: available PEBs: 94, total reserved PEBs: 925, PEBs
> reserved for bad PEB handling: 16
> [ 5.984375] ubi0: background thread "ubi_bgt0d" started, PID 375
> [ 6.039062] input: gpio_keys as /devices/soc0/gpio_keys/input/input0
> [ 6.046875] at91_rtc fffffeb0.rtc: setting system clock to 2017-01-16
> 10:22:55 UTC (1484562175)
> [ 6.062500] usb 1-1.1: new full-speed USB device number 3 using
> atmel-ehci
> [ 6.085937] UBIFS (ubi0:7): background thread "ubifs_bgt0_7" started,
> PID 434
> [ 6.109375] UBIFS (ubi0:7): recovery needed
> [ 6.187500] usb 1-1.1: New USB device found, idVendor=2d71,
> idProduct=0703
> [ 6.195312] usb 1-1.1: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 6.203125] usb 1-1.1: Product: C
> [ 6.210937] usb 1-1.1: Manufacturer: OVERKIZ SAS
> [ 6.210937] usb 1-1.1: SerialNumber: 12-16
> [ 6.234375] UBIFS (ubi0:7): recovery completed
> [ 6.234375] UBIFS (ubi0:7): UBIFS: mounted UBI device 0, volume 7,
> name "root"
> [ 6.242187] UBIFS (ubi0:7): LEB size: 126976 bytes (124 KiB),
> min./max. I/O unit sizes: 2048 bytes/2048 bytes
> [ 6.250000] UBIFS (ubi0:7): FS size: 49393664 bytes (47 MiB, 389
> LEBs), journal size 9023488 bytes (8 MiB, 72 LEBs)
> [ 6.257812] UBIFS (ubi0:7): reserved for root: 0 bytes (0 KiB)
> [ 6.265625] UBIFS (ubi0:7): media format: w4/r0 (latest is w4/r0),
> UUID 8FB0025A-D045-4284-B10B-16D0A55EFC51, small LPT model
> [ 6.281250] VFS: Mounted root (ubifs filesystem) on device 0:13.
> [ 6.289062] devtmpfs: mounted
> [ 6.289062] Freeing unused kernel memory: 132K (c0441000 - c0462000)
> [ 6.359375] usb 1-1.2: new high-speed USB device number 4 using
> atmel-ehci
> [ 6.476562] usb 1-1.2: New USB device found, idVendor=0424,
> idProduct=2512
> [ 6.484375] usb 1-1.2: New USB device strings: Mfr=0, Product=0,
> SerialNumber=0
> [ 6.492187] hub 1-1.2:1.0: USB hub found
> [ 6.500000] hub 1-1.2:1.0: 2 ports detected
> [ 6.789062] usb 1-1.2.1: new full-speed USB device number 5 using
> atmel-ehci
> [ 6.921875] usb 1-1.2.1: New USB device found, idVendor=2d71,
> idProduct=0702
> [ 6.921875] usb 1-1.2.1: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 6.929687] usb 1-1.2.1: Product: B
> [ 6.937500] usb 1-1.2.1: Manufacturer: OVERKIZ SAS
> [ 6.945312] usb 1-1.2.1: SerialNumber: 12-16
> [ 7.132812] usb 1-1.2.2: new high-speed USB device number 6 using
> atmel-ehci
> [ 7.250000] usb 1-1.2.2: New USB device found, idVendor=0424,
> idProduct=2512
> [ 7.257812] usb 1-1.2.2: New USB device strings: Mfr=0, Product=0,
> SerialNumber=0
> [ 7.335937] hub 1-1.2.2:1.0: USB hub found
> [ 7.382812] hub 1-1.2.2:1.0: 2 ports detected
> [ 7.476562] usbcore: registered new interface driver usbserial
> [ 7.476562] usbcore: registered new interface driver usbserial_generic
> [ 7.484375] usbserial: USB Serial support registered for generic
> [ 7.632812] usbcore: registered new interface driver ftdi_sio
> [ 7.640625] usbserial: USB Serial support registered for FTDI USB
> Serial Device
> [ 7.648437] ftdi_sio 1-1.1:1.0: FTDI USB Serial Device converter detected
> [ 7.656250] usb 1-1.1: Detected FT232RL
> [ 7.679687] usb 1-1.2.2.1: new full-speed USB device number 7 using
> atmel-ehci
> [ 7.796875] usb 1-1.1: FTDI USB Serial Device converter now attached
> to ttyUSB0
> [ 7.804687] ftdi_sio 1-1.2.1:1.0: FTDI USB Serial Device converter
> detected
> [ 7.812500] usb 1-1.2.1: Detected FT232RL
> [ 7.820312] cfg80211: Calling CRDA to update world regulatory domain
> [ 7.828125] usb 1-1.2.2.1: New USB device found, idVendor=2d71,
> idProduct=0700
> [ 7.835937] usb 1-1.2.2.1: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 7.843750] usb 1-1.2.2.1: Product: A
> [ 7.851562] usb 1-1.2.2.1: Manufacturer: OVERKIZ SAS
> [ 7.851562] usb 1-1.2.2.1: SerialNumber: 12-16
> [ 7.914062] usb 1-1.2.1: FTDI USB Serial Device converter now
> attached to ttyUSB1
> [ 8.000000] ftdi_sio 1-1.2.2.1:1.0: FTDI USB Serial Device converter
> detected
> [ 8.007812] usb 1-1.2.2.1: Detected FT232RL
> [ 8.054687] usb 1-1.2.2.1: FTDI USB Serial Device converter now
> attached to ttyUSB2
> [ 8.187500] usb 1-1.2.2.2: new high-speed USB device number 8 using
> atmel-ehci
> [ 8.312500] usb 1-1.2.2.2: New USB device found, idVendor=7392,
> idProduct=7811
> [ 8.320312] usb 1-1.2.2.2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 8.328125] usb 1-1.2.2.2: Product: 802.11n WLAN Adapter
> [ 8.328125] usb 1-1.2.2.2: Manufacturer: Realtek
> [ 8.335937] usb 1-1.2.2.2: SerialNumber: 00e04c000001
>
>> Thanks,
>>
>> Boris
>>
>>> This issue disappear when disabling OHCI and use EHCI only.
>>>
>>> What are the usual causes, and where to begin with ?
>>>
>>> Thanks in advance,
>>>
> Thanks,
>
^ permalink raw reply
* [PATCH v2 1/3] dt: bindings: add documentation for zx2967 family reset controller
From: Baoyou Xie @ 2017-01-16 10:56 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds dt-binding documentation for zx2967 family
reset controller.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Reviewed-by: Shawn Guo <shawnguo@kernel.org>
---
.../devicetree/bindings/reset/zte,zx2967-reset.txt | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt
diff --git a/Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt b/Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt
new file mode 100644
index 0000000..b015508
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt
@@ -0,0 +1,20 @@
+ZTE zx2967 SoCs Reset Controller
+=======================================
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: should be one of the following.
+ * zte,zx296718-reset
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- #reset-cells: must be 1.
+
+example:
+
+ reset: reset-controller at 1461060 {
+ compatible = "zte,zx296718-reset";
+ reg = <0x01461060 0x8>;
+ #reset-cells = <1>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] MAINTAINERS: add zx2967 reset controller driver to ARM ZTE architecture
From: Baoyou Xie @ 2017-01-16 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484564194-18530-1-git-send-email-baoyou.xie@linaro.org>
Add the zx2967 reset controller driver as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2793808..08f8155 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1980,10 +1980,12 @@ L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-zx/
F: drivers/clk/zte/
+F: drivers/reset/reset-zx2967.c
F: drivers/soc/zte/
F: drivers/thermal/zx*
F: Documentation/devicetree/bindings/arm/zte.txt
F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
+F: Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt
F: Documentation/devicetree/bindings/soc/zte/
F: Documentation/devicetree/bindings/thermal/zx*
F: include/dt-bindings/soc/zx*.h
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/3] reset: zx2967: add reset controller driver for ZTE's zx2967 family
From: Baoyou Xie @ 2017-01-16 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484564194-18530-1-git-send-email-baoyou.xie@linaro.org>
This patch adds reset controller driver for ZTE's zx2967 family.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/reset/Kconfig | 6 +++
drivers/reset/Makefile | 1 +
drivers/reset/reset-zx2967.c | 125 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 132 insertions(+)
create mode 100644 drivers/reset/reset-zx2967.c
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 172dc96..f4cdfe9 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -86,6 +86,12 @@ config RESET_UNIPHIER
Say Y if you want to control reset signals provided by System Control
block, Media I/O block, Peripheral Block.
+config RESET_ZX2967
+ bool "ZTE ZX2967 Reset Driver"
+ depends on ARCH_ZX || COMPILE_TEST
+ help
+ This enables the reset controller driver for ZTE's zx2967 family.
+
config RESET_ZYNQ
bool "ZYNQ Reset Driver" if COMPILE_TEST
default ARCH_ZYNQ
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 13b346e..2cd3f6c 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -13,4 +13,5 @@ obj-$(CONFIG_RESET_STM32) += reset-stm32.o
obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
+obj-$(CONFIG_RESET_ZX2967) += reset-zx2967.o
obj-$(CONFIG_RESET_ZYNQ) += reset-zynq.o
diff --git a/drivers/reset/reset-zx2967.c b/drivers/reset/reset-zx2967.c
new file mode 100644
index 0000000..bc95261
--- /dev/null
+++ b/drivers/reset/reset-zx2967.c
@@ -0,0 +1,125 @@
+/*
+ * ZTE's zx2967 family reset controller driver
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/reset-controller.h>
+
+struct zx2967_reset {
+ void __iomem *reg_base;
+ spinlock_t lock;
+ struct reset_controller_dev rcdev;
+};
+
+static int zx2967_reset_act(struct reset_controller_dev *rcdev,
+ unsigned long id, bool assert)
+{
+ struct zx2967_reset *reset = NULL;
+ u32 bank = id / 32;
+ u32 offset = id % 32;
+ u32 reg;
+ unsigned long flags;
+
+ reset = container_of(rcdev, struct zx2967_reset, rcdev);
+
+ spin_lock_irqsave(&reset->lock, flags);
+
+ reg = readl(reset->reg_base + (bank * 4));
+ if (assert)
+ reg &= ~BIT(offset);
+ else
+ reg |= BIT(offset);
+ writel(reg, reset->reg_base + (bank * 4));
+
+ spin_unlock_irqrestore(&reset->lock, flags);
+
+ return 0;
+}
+
+static int zx2967_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ return zx2967_reset_act(rcdev, id, true);
+}
+
+static int zx2967_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ return zx2967_reset_act(rcdev, id, false);
+}
+
+static struct reset_control_ops zx2967_reset_ops = {
+ .assert = zx2967_reset_assert,
+ .deassert = zx2967_reset_deassert,
+};
+
+static int zx2967_reset_probe(struct platform_device *pdev)
+{
+ struct zx2967_reset *reset;
+ struct resource *res;
+
+ reset = devm_kzalloc(&pdev->dev, sizeof(*reset), GFP_KERNEL);
+ if (!reset)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ reset->reg_base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(reset->reg_base))
+ return PTR_ERR(reset->reg_base);
+
+ spin_lock_init(&reset->lock);
+
+ reset->rcdev.owner = THIS_MODULE;
+ reset->rcdev.nr_resets = resource_size(res) * 8;
+ reset->rcdev.ops = &zx2967_reset_ops;
+ reset->rcdev.of_node = pdev->dev.of_node;
+
+ dev_info(&pdev->dev, "reset controller cnt:%d",
+ reset->rcdev.nr_resets);
+
+ return devm_reset_controller_register(&pdev->dev, &reset->rcdev);
+}
+
+static int zx2967_reset_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static const struct of_device_id zx2967_reset_dt_ids[] = {
+ { .compatible = "zte,zx296718-reset", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, zx2967_reset_dt_ids);
+
+static struct platform_driver zx2967_reset_driver = {
+ .probe = zx2967_reset_probe,
+ .remove = zx2967_reset_remove,
+ .driver = {
+ .name = "zx2967-reset",
+ .of_match_table = zx2967_reset_dt_ids,
+ },
+};
+
+static int __init zx2967_reset_init(void)
+{
+ return platform_driver_register(&zx2967_reset_driver);
+}
+arch_initcall(zx2967_reset_init);
+
+static void __exit zx2967_reset_exit(void)
+{
+ platform_driver_unregister(&zx2967_reset_driver);
+}
+module_exit(zx2967_reset_exit);
+
+MODULE_AUTHOR("Baoyou Xie <baoyou.xie@linaro.org>");
+MODULE_DESCRIPTION("ZTE zx2967 Reset Controller Driver");
+MODULE_LICENSE("GPL");
--
2.7.4
^ permalink raw reply related
* [RFC PATCH v2 10/10] dt-bindings: Document devicetree binding for ARM SPE
From: Will Deacon @ 2017-01-16 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113184352.GE2472@leverpostej>
On Fri, Jan 13, 2017 at 06:43:52PM +0000, Mark Rutland wrote:
> On Fri, Jan 13, 2017 at 04:03:49PM +0000, Will Deacon wrote:
> > This patch documents the devicetree binding in use for ARM SPE.
> >
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Rob Herring <robh@kernel.org>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> > Documentation/devicetree/bindings/arm/spe-pmu.txt | 20 ++++++++++++++++++++
> > 1 file changed, 20 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/arm/spe-pmu.txt
> >
> > diff --git a/Documentation/devicetree/bindings/arm/spe-pmu.txt b/Documentation/devicetree/bindings/arm/spe-pmu.txt
> > new file mode 100644
> > index 000000000000..d6540b491af4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/spe-pmu.txt
> > @@ -0,0 +1,20 @@
> > +* ARMv8.2 Statistical Profiling Extension (SPE) Performance Monitor Units (PMU)
> > +
> > +ARMv8.2 introduces the optional Statistical Profiling Extension for collecting
> > +performance sample data using an in-memory trace buffer.
> > +
> > +** SPE Required properties:
> > +
> > +- compatible : should be one of:
> > + "arm,arm-spe-pmu-v1"
>
> The second "arm" here doesn't seem to add much. Should that be "armv8.2"
> instead?
I don't think armv8.2 is particularly helpful, because that effectively ties
together the SPE version and the architecture version, which I don't think
is strictly required. The reason I added it was so that you could describe
a partner implementation as something like:
acme,arm-spe-pmu-v1
and know that it was acme's implementation of an ARM architectural feature.
If I drop the second "arm", I was worried that it might conflict with other
namespaces (e.g. acme's signal-processing-element's power-management-unit).
What do you reckon?
Will
^ permalink raw reply
* Tegra baseline test results for v4.10-rc4
From: Jon Hunter @ 2017-01-16 11:08 UTC (permalink / raw)
To: linux-arm-kernel
Here are some basic Tegra test results for Linux v4.10-rc4.
Logs and other details at:
https://nvtb.github.io//linux/test_v4.10-rc4/20170116023103/
Test summary
------------
Build: zImage:
Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
Build: Image:
Pass: ( 1/ 1): defconfig
Boot to userspace: defconfig:
Pass: ( 4/ 4): qemu-vexpress64, tegra132-norrin,
tegra210-p2371-0000, tegra210-smaug
Boot to userspace: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
Boot to userspace: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: multi_v7_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
PM: System suspend: tegra_defconfig:
Pass: ( 5/ 5): tegra114-dalmore-a04, tegra124-jetson-tk1,
tegra124-nyan-big, tegra20-trimslice, tegra30-beaver
vmlinux object size
(delta in bytes from test_v4.10-rc3 (a121103c922847ba5010819a3f250f1f7fc84ab8)):
text data bss total kernel
+281 -248 0 +33 defconfig
+1307 -64 0 +1243 multi_v7_defconfig
+1003 +64 0 +1067 tegra_defconfig
Boot-time memory difference
(delta in bytes from test_v4.10-rc3 (a121103c922847ba5010819a3f250f1f7fc84ab8))
avail rsrvd high freed board kconfig dtb
. . . . qemu-vexpress64 defconfig __internal
. . . . tegra114-dalmore-a04 multi_v7_defconfig tegra114-dalmore
. . . . tegra114-dalmore-a04 tegra_defconfig tegra114-dalmore
. . . . tegra124-jetson-tk1 multi_v7_defconfig tegra124-jetson-tk1
. . . . tegra124-jetson-tk1 tegra_defconfig tegra124-jetson-tk1
. . . . tegra124-nyan-big multi_v7_defconfig tegra124-nyan-big
. . . . tegra124-nyan-big tegra_defconfig tegra124-nyan-big
. . . . tegra132-norrin defconfig tegra132-norrin
. . . . tegra20-trimslice multi_v7_defconfig tegra20-trimslice
. . . . tegra20-trimslice tegra_defconfig tegra20-trimslice
. . . . tegra210-p2371-0000 defconfig tegra210-p2371-0000
. . . . tegra210-smaug defconfig tegra210-smaug
. . . . tegra30-beaver multi_v7_defconfig tegra30-beaver
. . . . tegra30-beaver tegra_defconfig tegra30-beaver
--
nvpublic
^ permalink raw reply
* [PATCH] usb: gadget: udc: atmel: used managed kasprintf
From: Alexandre Belloni @ 2017-01-16 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87eg03nvuv.fsf@linux.intel.com>
On 16/01/2017 at 12:27:04 +0200, Felipe Balbi wrote :
>
> Hi,
>
> David Laight <David.Laight@ACULAB.COM> writes:
> > From: Alexandre Belloni
> >> Sent: 02 December 2016 16:19
> >> On 02/12/2016 at 15:59:57 +0000, David Laight wrote :
> >> > From: Alexandre Belloni
> >> > > Sent: 01 December 2016 10:27
> >> > > Use devm_kasprintf instead of simple kasprintf to free the allocated memory
> >> > > when needed.
> >> >
> >> > s/when needed/when the device is freed/
> >> >
> >> > > Suggested-by: Peter Rosin <peda@axentia.se>
> >> > > Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> >> > > ---
> >> > > drivers/usb/gadget/udc/atmel_usba_udc.c | 3 ++-
> >> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> >> > >
> >> > > diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
> >> > > index 45bc997d0711..aec72fe8273c 100644
> >> > > --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> >> > > +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> >> > > @@ -1978,7 +1978,8 @@ static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
> >> > > dev_err(&pdev->dev, "of_probe: name error(%d)\n", ret);
> >> > > goto err;
> >> > > }
> >> > > - ep->ep.name = kasprintf(GFP_KERNEL, "ep%d", ep->index);
> >> > > + ep->ep.name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "ep%d",
> >> > > + ep->index);
> >> >
> >> > Acually why bother mallocing such a small string at all.
> >> > The maximum length is 12 bytes even if 'index' are unrestricted.
> >> >
> >>
> >> IIRC, using statically allocated string is failing somewhere is the USB
> >> core but I don't remember all the details.
> >
> > I can't imagine that changing ep->ep.name from 'char *' to 'char [12]' would
> > make any difference.
>
> the actual name is managed by the UDC. Meaning, ep->ep.name should be a
> pointer, but it could very well just point to ep->name which would be
> char [12].
>
Yeah, I sent a patch that did just that.
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/478602.html
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] PCI: mvebu: change delay after reset to the PCIe spec mandated 100ms
From: Lucas Stach @ 2017-01-16 11:11 UTC (permalink / raw)
To: linux-arm-kernel
The current default of 20ms cause some devices, which are slow to initialize,
to not show up during the bus scanning. Change this to the PCIe spec mandated
100ms and document this in the DT binding.
>From PCIe base spec rev 3.0, chapter "6.6.1. Conventional Reset":
"To allow components to perform internal initialization, system software must
wait a specified minimum period following the end of a Conventional Reset of
one or more devices before it is permitted to issue Configuration Requests to
those devices.
With a Downstream Port that does not support Link speeds greater than
5.0 GT/s, software must wait a minimum of 100 ms before sending a
Configuration Request to the device immediately below that Port."
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
Documentation/devicetree/bindings/pci/mvebu-pci.txt | 3 ++-
drivers/pci/host/pci-mvebu.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 08c716b2c6b6..2de6f65ecfb1 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -78,7 +78,8 @@ and the following optional properties:
multiple lanes. If this property is not found, we assume that the
value is 0.
- reset-gpios: optional gpio to PERST#
-- reset-delay-us: delay in us to wait after reset de-assertion
+- reset-delay-us: delay in us to wait after reset de-assertion, if not
+ specified will default to 100ms, as required by the PCIe specification.
Example:
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 45a89d969700..0c9dd47ce74d 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -1162,7 +1162,7 @@ static int mvebu_pcie_powerup(struct mvebu_pcie_port *port)
return ret;
if (port->reset_gpio) {
- u32 reset_udelay = 20000;
+ u32 reset_udelay = 100000;
of_property_read_u32(port->dn, "reset-delay-us",
&reset_udelay);
--
2.11.0
^ permalink raw reply related
* USB: OHCI: high softirq load
From: Boris Brezillon @ 2017-01-16 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d49db4ac-fbeb-23ce-d48c-bd087c314328@overkiz.com>
On Mon, 16 Jan 2017 11:54:23 +0100
Antoine Aubert <a.aubert@overkiz.com> wrote:
> Also, I made a big misunderstanding
>
> With EHCI + OHCI = high level of softirq (USB2.0)
Well, the number of irqs and softirqs are likely to be related (you
usually trigger a softirq after you received an hardirq).
>
> OHCI only = normal level
What about EHCI only? And what happens if you only plug 1 device?
Please share the content of /proc/interrupts (and everything you think
is relevant) for each of these cases.
>
> Le 16/01/2017 ? 11:31, Antoine Aubert a ?crit :
> > Thx for your answer Boris
> >
> > Le 16/01/2017 ? 10:02, Boris Brezillon a ?crit :
> >> Hi Antoine,
> >>
> >> On Mon, 16 Jan 2017 08:45:58 +0100
> >> Antoine Aubert <a.aubert@overkiz.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> Im working on a AT91SAM9G25cu board
> >>> (arch/arm/boot/dts/at91-kizboxmini.dts). We use linux-4.1.31, and when
> >>> OHCI is enabled, I got some wired effects.
> >> Can you test on a more recent kernel (4.9 or 4.10-rc4)?
> > I'll give a try, just need little time ;)
> >>> eg with 3 FTDI pluged, interrupts: more than 3.5k/s, cpu softirq > 24%,
> >>> loadavg > 0.5
> >> Can you check which interrupt is triggered (cat /proc/interrupts),
> > cat /proc/interrupts
> > CPU0
> > 16: 2286 atmel-aic 1 Level pmc, at91_tick, at91_rtc, ttyS0
> > 17: 0 PMC 17 Level main_rc_osc
> > 18: 0 PMC 0 Level main_osc
> > 19: 0 PMC 16 Level mainck
> > 20: 0 PMC 1 Level clk-plla
> > 21: 0 PMC 6 Level clk-utmi
> > 22: 0 PMC 3 Level clk-master
> > 23: 945527 atmel-aic 17 Level tc_clkevt
> > 24: 21815 atmel-aic 20 Level at_hdmac
> > 25: 0 atmel-aic 21 Level at_hdmac
> > 30: 120299 atmel-aic 24 Level eth0
> > 31: 22783651 atmel-aic 22 Level ehci_hcd:usb1, ohci_hcd:usb2
> > 99: 0 GPIO 16 Edge PB_RST
> > 100: 0 GPIO 17 Edge PB_PROG
> > Err: 0
> >
> >> and
> >> enable debug messages in drivers/usb/host/ohci-at91.c?
Actually, I was asking for debug messages. You can enable them
dynamically with dynamic printk [1].
BTW, please use pastebin (or any other alternative) to share these
information.
Thanks,
Boris
[1]http://lxr.free-electrons.com/source/Documentation/dynamic-debug-howto.txt
^ permalink raw reply
* [PATCH 1/2] spi: pxa2xx: Prepare for edge-triggered interrupts
From: Jan Kiszka @ 2017-01-16 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484558690.2133.132.camel@linux.intel.com>
On 2017-01-16 10:24, Andy Shevchenko wrote:
> On Mon, 2017-01-16 at 10:05 +0100, Jan Kiszka wrote:
>> When using the a device with edge-triggered interrupts, such as MSIs,
>> the interrupt handler has to ensure that there is a point in time
>> during
>> its execution where all interrupts sources are silent so that a new
>> event can trigger a new interrupt again.
>>
>> This is achieved here by looping over SSSR evaluation. We need to take
>> into account that SSCR1 may be changed by the transfer handler, thus
>> we
>> need to redo the mask calculation, at least regarding the volatile
>> interrupt enable bit (TIE).
>
> Could you split this to two patches, one just move the code under
> question to a helper function (no functional change), the other does
> what you state in commit message here?
IMHO, factoring out some helper called from the loop in ssp_int won't be
a natural split due to the large number of local variables being shared
here. But maybe I'm not seeing the design you have in mind, so please
propose a useful helper function signature.
Thanks,
Jan
>
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>> drivers/spi/spi-pxa2xx.c | 50 +++++++++++++++++++++++++++----------
>> -----------
>> 1 file changed, 28 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
>> index dd7b5b4..24bf549 100644
>> --- a/drivers/spi/spi-pxa2xx.c
>> +++ b/drivers/spi/spi-pxa2xx.c
>> @@ -737,6 +737,7 @@ static irqreturn_t ssp_int(int irq, void *dev_id)
>> struct driver_data *drv_data = dev_id;
>> u32 sccr1_reg;
>> u32 mask = drv_data->mask_sr;
>> + irqreturn_t ret = IRQ_NONE;
>> u32 status;
>>
>> /*
>> @@ -760,37 +761,42 @@ static irqreturn_t ssp_int(int irq, void
>> *dev_id)
>>
>> sccr1_reg = pxa2xx_spi_read(drv_data, SSCR1);
>>
>> - /* Ignore possible writes if we don't need to write */
>> - if (!(sccr1_reg & SSCR1_TIE))
>> - mask &= ~SSSR_TFS;
>> -
>> /* Ignore RX timeout interrupt if it is disabled */
>> if (!(sccr1_reg & SSCR1_TINTE))
>> mask &= ~SSSR_TINT;
>>
>> - if (!(status & mask))
>> - return IRQ_NONE;
>> + while (1) {
>> + /* Ignore possible writes if we don't need to write
>> */
>> + if (!(sccr1_reg & SSCR1_TIE))
>> + mask &= ~SSSR_TFS;
>>
>> - if (!drv_data->master->cur_msg) {
>> + if (!(status & mask))
>> + return ret;
>>
>> - pxa2xx_spi_write(drv_data, SSCR0,
>> - pxa2xx_spi_read(drv_data, SSCR0)
>> - & ~SSCR0_SSE);
>> - pxa2xx_spi_write(drv_data, SSCR1,
>> - pxa2xx_spi_read(drv_data, SSCR1)
>> - & ~drv_data->int_cr1);
>> - if (!pxa25x_ssp_comp(drv_data))
>> - pxa2xx_spi_write(drv_data, SSTO, 0);
>> - write_SSSR_CS(drv_data, drv_data->clear_sr);
>> + if (!drv_data->master->cur_msg) {
>>
>> - dev_err(&drv_data->pdev->dev,
>> - "bad message state in interrupt handler\n");
>> + pxa2xx_spi_write(drv_data, SSCR0,
>> + pxa2xx_spi_read(drv_data,
>> SSCR0)
>> + & ~SSCR0_SSE);
>> + pxa2xx_spi_write(drv_data, SSCR1,
>> + pxa2xx_spi_read(drv_data,
>> SSCR1)
>> + & ~drv_data->int_cr1);
>> + if (!pxa25x_ssp_comp(drv_data))
>> + pxa2xx_spi_write(drv_data, SSTO, 0);
>> + write_SSSR_CS(drv_data, drv_data->clear_sr);
>>
>> - /* Never fail */
>> - return IRQ_HANDLED;
>> - }
>> + dev_err(&drv_data->pdev->dev,
>> + "bad message state in interrupt
>> handler\n");
>>
>> - return drv_data->transfer_handler(drv_data);
>> + /* Never fail */
>> + return IRQ_HANDLED;
>> + }
>> +
>> + ret |= drv_data->transfer_handler(drv_data);
>> +
>> + status = pxa2xx_spi_read(drv_data, SSSR);
>> + sccr1_reg = pxa2xx_spi_read(drv_data, SSCR1);
>> + }
>> }
>>
>> /*
>
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply
* [PATCH] usb: gadget: udc: atmel: used managed kasprintf
From: Felipe Balbi @ 2017-01-16 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116111128.ft2b5aa63y2qe35p@piout.net>
Hi,
Alexandre Belloni <alexandre.belloni@free-electrons.com> writes:
>> David Laight <David.Laight@ACULAB.COM> writes:
>> > From: Alexandre Belloni
>> >> Sent: 02 December 2016 16:19
>> >> On 02/12/2016 at 15:59:57 +0000, David Laight wrote :
>> >> > From: Alexandre Belloni
>> >> > > Sent: 01 December 2016 10:27
>> >> > > Use devm_kasprintf instead of simple kasprintf to free the allocated memory
>> >> > > when needed.
>> >> >
>> >> > s/when needed/when the device is freed/
>> >> >
>> >> > > Suggested-by: Peter Rosin <peda@axentia.se>
>> >> > > Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>> >> > > ---
>> >> > > drivers/usb/gadget/udc/atmel_usba_udc.c | 3 ++-
>> >> > > 1 file changed, 2 insertions(+), 1 deletion(-)
>> >> > >
>> >> > > diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
>> >> > > index 45bc997d0711..aec72fe8273c 100644
>> >> > > --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
>> >> > > +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
>> >> > > @@ -1978,7 +1978,8 @@ static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
>> >> > > dev_err(&pdev->dev, "of_probe: name error(%d)\n", ret);
>> >> > > goto err;
>> >> > > }
>> >> > > - ep->ep.name = kasprintf(GFP_KERNEL, "ep%d", ep->index);
>> >> > > + ep->ep.name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "ep%d",
>> >> > > + ep->index);
>> >> >
>> >> > Acually why bother mallocing such a small string at all.
>> >> > The maximum length is 12 bytes even if 'index' are unrestricted.
>> >> >
>> >>
>> >> IIRC, using statically allocated string is failing somewhere is the USB
>> >> core but I don't remember all the details.
>> >
>> > I can't imagine that changing ep->ep.name from 'char *' to 'char [12]' would
>> > make any difference.
>>
>> the actual name is managed by the UDC. Meaning, ep->ep.name should be a
>> pointer, but it could very well just point to ep->name which would be
>> char [12].
>>
>
> Yeah, I sent a patch that did just that.
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/478602.html
it's in my fixes now :-)
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170116/8307cc5b/attachment.sig>
^ permalink raw reply
* [RFC PATCH v2 03/10] arm64: KVM: Save/restore the host SPE state when entering/leaving a VM
From: Marc Zyngier @ 2017-01-16 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484323429-15231-4-git-send-email-will.deacon@arm.com>
Hi Will,
On 13/01/17 16:03, Will Deacon wrote:
> The SPE buffer is virtually addressed, using the page tables of the CPU
> MMU. Unusually, this means that the EL0/1 page table may be live whilst
> we're executing at EL2 on non-VHE configurations. When VHE is in use,
> we can use the same property to profile the guest behind its back.
>
> This patch adds the relevant disabling and flushing code to KVM so that
> the host can make use of SPE without corrupting guest memory, and any
> attempts by a guest to use SPE will result in a trap.
>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Alex Benn?e <alex.bennee@linaro.org>
> Cc: Christoffer Dall <christoffer.dall@linaro.org>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm64/include/asm/kvm_arm.h | 3 ++
> arch/arm64/include/asm/kvm_host.h | 7 ++++-
> arch/arm64/kvm/debug.c | 6 ++++
> arch/arm64/kvm/hyp/debug-sr.c | 66 +++++++++++++++++++++++++++++++++++++--
> arch/arm64/kvm/hyp/switch.c | 13 +++++++-
> 5 files changed, 91 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index 2a2752b5b6aa..6e99978e83bd 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -188,6 +188,9 @@
> #define CPTR_EL2_DEFAULT 0x000033ff
>
> /* Hyp Debug Configuration Register bits */
> +#define MDCR_EL2_TPMS (1 << 14)
> +#define MDCR_EL2_E2PB_MASK (UL(0x3))
> +#define MDCR_EL2_E2PB_SHIFT (UL(12))
> #define MDCR_EL2_TDRA (1 << 11)
> #define MDCR_EL2_TDOSA (1 << 10)
> #define MDCR_EL2_TDA (1 << 9)
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index e5050388e062..443b387021f2 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -229,7 +229,12 @@ struct kvm_vcpu_arch {
>
> /* Pointer to host CPU context */
> kvm_cpu_context_t *host_cpu_context;
> - struct kvm_guest_debug_arch host_debug_state;
> + struct {
> + /* {Break,watch}point registers */
> + struct kvm_guest_debug_arch regs;
> + /* Statistical profiling extension */
> + u64 pmscr_el1;
> + } host_debug_state;
>
> /* VGIC state */
> struct vgic_cpu vgic_cpu;
> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> index 47e5f0feaee8..dbadfaf850a7 100644
> --- a/arch/arm64/kvm/debug.c
> +++ b/arch/arm64/kvm/debug.c
> @@ -95,6 +95,7 @@ void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu)
> * - Performance monitors (MDCR_EL2_TPM/MDCR_EL2_TPMCR)
> * - Debug ROM Address (MDCR_EL2_TDRA)
> * - OS related registers (MDCR_EL2_TDOSA)
> + * - Statistical profiler (MDCR_EL2_TPMS/MDCR_EL2_E2PB)
> *
> * Additionally, KVM only traps guest accesses to the debug registers if
> * the guest is not actively using them (see the KVM_ARM64_DEBUG_DIRTY
> @@ -110,8 +111,13 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
>
> trace_kvm_arm_setup_debug(vcpu, vcpu->guest_debug);
>
> + /*
> + * This also clears MDCR_EL2_E2PB_MASK to disable guest access
> + * to the profiling buffer.
> + */
> vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK;
> vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM |
> + MDCR_EL2_TPMS |
This is RES0 on CPUs that do not implement SPE. Can we make this
conditional on SPE being available?
> MDCR_EL2_TPMCR |
> MDCR_EL2_TDRA |
> MDCR_EL2_TDOSA);
> diff --git a/arch/arm64/kvm/hyp/debug-sr.c b/arch/arm64/kvm/hyp/debug-sr.c
> index 4ba5c9095d03..f5154ed3da6c 100644
> --- a/arch/arm64/kvm/hyp/debug-sr.c
> +++ b/arch/arm64/kvm/hyp/debug-sr.c
> @@ -65,6 +65,66 @@
> default: write_debug(ptr[0], reg, 0); \
> }
>
> +#define PMSCR_EL1 sys_reg(3, 0, 9, 9, 0)
> +
> +#define PMBLIMITR_EL1 sys_reg(3, 0, 9, 10, 0)
> +#define PMBLIMITR_EL1_E BIT(0)
> +
> +#define PMBIDR_EL1 sys_reg(3, 0, 9, 10, 7)
> +#define PMBIDR_EL1_P BIT(4)
> +
> +#define psb_csync() asm volatile("hint #17")
Cute... ;-)
> +
> +static void __hyp_text __debug_save_spe_vhe(u64 *pmscr_el1)
> +{
> + /* The vcpu can run. but it can't hide. */
> +}
> +
> +static void __hyp_text __debug_save_spe_nvhe(u64 *pmscr_el1)
> +{
> + u64 reg;
> +
> + /* SPE present on this CPU? */
> + if (!cpuid_feature_extract_unsigned_field(read_sysreg(id_aa64dfr0_el1),
> + ID_AA64DFR0_PMSVER_SHIFT))
> + return;
> +
> + /* Yes; is it owned by EL3? */
> + reg = read_sysreg_s(PMBIDR_EL1);
> + if (reg & PMBIDR_EL1_P)
> + return;
> +
> + /* No; is the host actually using the thing? */
> + reg = read_sysreg_s(PMBLIMITR_EL1);
> + if (!(reg & PMBLIMITR_EL1_E))
> + return;
> +
> + /* Yes; save the control register and disable data generation */
> + *pmscr_el1 = read_sysreg_s(PMSCR_EL1);
> + write_sysreg_s(0, PMSCR_EL1);
> + isb();
> +
> + /* Now drain all buffered data to memory */
> + psb_csync();
> + dsb(nsh);
So let's hope that nobody will build a non-VHE, SPE capable system.
Because this feels like hitting the brakes each time we enter the guest
(if SPE is in use, that is...).
> +}
> +
> +static hyp_alternate_select(__debug_save_spe,
> + __debug_save_spe_nvhe, __debug_save_spe_vhe,
> + ARM64_HAS_VIRT_HOST_EXTN);
> +
> +static void __hyp_text __debug_restore_spe(u64 pmscr_el1)
> +{
> + if (!pmscr_el1)
> + return;
> +
> + /* The host page table is installed, but not yet synchronised */
> + isb();
I believe you can avoid that on VHE (host page tables haven't changed).
Also, if you now depend on the debug restore being run after the rest of
the sysregs, please add a comment in switch.c::__kvm_vcpu_run so that we
remember about that dependency.
> +
> + /* Re-enable data generation */
> + write_sysreg_s(pmscr_el1, PMSCR_EL1);
Same thing here, as we never disabled SPE the first place on VHE (and
we're probably only writing zeroes there).
> +}
> +
> void __hyp_text __debug_save_state(struct kvm_vcpu *vcpu,
> struct kvm_guest_debug_arch *dbg,
> struct kvm_cpu_context *ctxt)
> @@ -118,13 +178,15 @@ void __hyp_text __debug_cond_save_host_state(struct kvm_vcpu *vcpu)
> (vcpu->arch.ctxt.sys_regs[MDSCR_EL1] & DBG_MDSCR_MDE))
> vcpu->arch.debug_flags |= KVM_ARM64_DEBUG_DIRTY;
>
> - __debug_save_state(vcpu, &vcpu->arch.host_debug_state,
> + __debug_save_state(vcpu, &vcpu->arch.host_debug_state.regs,
> kern_hyp_va(vcpu->arch.host_cpu_context));
> + __debug_save_spe()(&vcpu->arch.host_debug_state.pmscr_el1);
> }
>
> void __hyp_text __debug_cond_restore_host_state(struct kvm_vcpu *vcpu)
> {
> - __debug_restore_state(vcpu, &vcpu->arch.host_debug_state,
> + __debug_restore_spe(vcpu->arch.host_debug_state.pmscr_el1);
> + __debug_restore_state(vcpu, &vcpu->arch.host_debug_state.regs,
> kern_hyp_va(vcpu->arch.host_cpu_context));
>
> if (vcpu->arch.debug_flags & KVM_ARM64_DEBUG_DIRTY)
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 75e83dd40d43..1ee5b06d81e5 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -103,7 +103,13 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
> static void __hyp_text __deactivate_traps_vhe(void)
> {
> extern char vectors[]; /* kernel exception vectors */
> + u64 mdcr_el2 = read_sysreg(mdcr_el2);
>
> + mdcr_el2 &= MDCR_EL2_HPMN_MASK |
> + MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT |
> + MDCR_EL2_TPMS;
> +
> + write_sysreg(mdcr_el2, mdcr_el2);
> write_sysreg(HCR_HOST_VHE_FLAGS, hcr_el2);
> write_sysreg(CPACR_EL1_FPEN, cpacr_el1);
> write_sysreg(vectors, vbar_el1);
> @@ -111,6 +117,12 @@ static void __hyp_text __deactivate_traps_vhe(void)
>
> static void __hyp_text __deactivate_traps_nvhe(void)
> {
> + u64 mdcr_el2 = read_sysreg(mdcr_el2);
> +
> + mdcr_el2 &= MDCR_EL2_HPMN_MASK;
> + mdcr_el2 |= MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT;
Same remark as above. I'm not completely confident writing new bits to
registers that do not necessarily implement the feature.
> +
> + write_sysreg(mdcr_el2, mdcr_el2);
> write_sysreg(HCR_RW, hcr_el2);
> write_sysreg(CPTR_EL2_DEFAULT, cptr_el2);
> }
> @@ -132,7 +144,6 @@ static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
>
> __deactivate_traps_arch()();
> write_sysreg(0, hstr_el2);
> - write_sysreg(read_sysreg(mdcr_el2) & MDCR_EL2_HPMN_MASK, mdcr_el2);
> write_sysreg(0, pmuserenr_el0);
> }
>
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v7 09/15] ACPI: platform-msi: retrieve dev id from IORT
From: Lorenzo Pieralisi @ 2017-01-16 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5879A8F3.7030303@huawei.com>
On Sat, Jan 14, 2017 at 12:28:35PM +0800, Hanjun Guo wrote:
> Hi Lorenzo,
>
> On 2017/1/13 20:11, Lorenzo Pieralisi wrote:
> > On Wed, Jan 11, 2017 at 11:06:33PM +0800, Hanjun Guo wrote:
> >> For devices connecting to ITS, it needs dev id to identify itself, and
> >> this dev id is represented in the IORT table in named component node
> >> [1] for platform devices, so in this patch we will scan the IORT to
> >> retrieve device's dev id.
> >>
> >> For named components we know that there are always two steps
> >> involved (second optional):
> >>
> >> (1) Retrieve the initial id (this may well provide the final mapping)
> >> (2) Map the id (optional if (1) represents the map type we need), this
> >> is needed for use cases such as NC (named component) -> SMMU -> ITS
> >> mappings.
> >>
> >> we have API iort_node_get_id() for step (1) above and
> >> iort_node_map_rid() for step (2), so create a wrapper
> >> iort_node_map_platform_id() to retrieve the dev id.
> >>
> >> [1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf
> > This patch should be split and IORT changes should be squashed with
> > patch 10.
>
> If split the changes for IORT and its platform msi, API introduced in IORT will
> not be used in a single patch, seems violate the suggestion of "new introduced API
> needs to be used in the same patch", did I miss something?
Yes, I would introduce iort_node_map_platform_id() and in the same
patch update current iort_node_get_id() users (ie iort_iommu_configure())
to it. No functional change intended.
Then in subsequent patches you can retrieve the ITS device id for
platform devices through it.
Code is in your series, you just have to reshuffle it slightly.
> >> Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >> Suggested-by: Tomasz Nowicki <tn@semihalf.com>
> >> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >> Cc: Marc Zyngier <marc.zyngier@arm.com>
> >> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >> Cc: Sinan Kaya <okaya@codeaurora.org>
> >> Cc: Tomasz Nowicki <tn@semihalf.com>
> >> Cc: Thomas Gleixner <tglx@linutronix.de>
> >> ---
> >> drivers/acpi/arm64/iort.c | 56 +++++++++++++++++++++++++++
> >> drivers/irqchip/irq-gic-v3-its-platform-msi.c | 4 +-
> >> include/linux/acpi_iort.h | 8 ++++
> >> 3 files changed, 67 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> >> index 069a690..95fd20b 100644
> >> --- a/drivers/acpi/arm64/iort.c
> >> +++ b/drivers/acpi/arm64/iort.c
> >> @@ -30,6 +30,7 @@
> >> #define IORT_MSI_TYPE (1 << ACPI_IORT_NODE_ITS_GROUP)
> >> #define IORT_IOMMU_TYPE ((1 << ACPI_IORT_NODE_SMMU) | \
> >> (1 << ACPI_IORT_NODE_SMMU_V3))
> >> +#define IORT_TYPE_ANY (IORT_MSI_TYPE | IORT_IOMMU_TYPE)
> >>
> >> struct iort_its_msi_chip {
> >> struct list_head list;
> >> @@ -406,6 +407,34 @@ static struct acpi_iort_node *iort_node_map_id(struct acpi_iort_node *node,
> >> return NULL;
> >> }
> >>
> >> +static
> >> +struct acpi_iort_node *iort_node_map_platform_id(struct acpi_iort_node *node,
> >> + u32 *id_out, u8 type_mask,
> >> + int index)
> >> +{
> >> + struct acpi_iort_node *parent;
> >> + u32 id;
> >> +
> >> + /* step 1: retrieve the initial dev id */
> >> + parent = iort_node_get_id(node, &id, IORT_TYPE_ANY, index);
> >> + if (!parent)
> >> + return NULL;
> >> +
> >> + /*
> >> + * optional step 2: map the initial dev id if its parent is not
> >> + * the target type we wanted, map it again for the use cases such
> >> + * as NC (named component) -> SMMU -> ITS. If the type is matched,
> >> + * return the parent pointer directly.
> >> + */
> >> + if (!(IORT_TYPE_MASK(parent->type) & type_mask))
> >> + parent = iort_node_map_id(parent, id, id_out, type_mask);
> >> + else
> >> + if (id_out)
> > Remove this pointer check.
>
> This was added because of NULL pointer reference, I passed NULL for id_out because I
> only want to get its parent node, I think we have four options:
>
> - Introduce a new API to get the parent only from the scratch, but it will duplicate the code
> a lot;
>
> - Don't check the id_out in iort_node_map_platform_id(), and introduce a wrapper and pass the
> dummy id for iort_node_map_platform_id() :
> static
> struct acpi_iort_node *iort_node_get_platform_parent{struct device *dev, u8 type_mask}
> {
> struct acpi_iort_node *node, *parent = NULL;
> int i;
> u32 dummy_id;
>
> node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
> iort_match_node_callback, dev);
>
> if (!node)
> return NULL;
>
> for (i = 0; i < node->mapping_count; i++) {
> /* we just want to get the parent node */
> parent = iort_node_map_platform_id(node, &dummy_id,
> IORT_MSI_TYPE, i);
> if (parent)
> break;
> }
>
> return parent;
> }
>
> - Similar solution as above but don't introduce wrapper, just use dummy_id if
> iort_node_map_platform_id() is called;
>
> - Use the solution I proposed in this patch.
>
> Please share you suggestion on this :)
I see. I would like to change the IORT mapping API functions to always pass
in an argument:
struct iort_idmap {
struct acpi_iort_node *parent;
u32 id;
};
and return an int, because current functions (eg iort_node_map_rid())
return a parent IORT node but also the mapped id as a value-result
and that's not easy to follow (also Sinan raised this point which I
think it is fair).
I think we'd better postpone this change to next cycle, so you can
leave the pointer check:
if (id_out)
I will clean this up later, basically what we would end up doing to just
retrieve the parent pointer would be the IORT equivalent of what we have
in DT:
of_parse_phandle()
-> __of_parse_phandle_with_args() #we call it with cell_count == 0
at the end of the day it is just to make code easier to follow, since it
is functions internal to IORT compilation unit it is ok for now to leave
it as-is.
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH v7 0/4] arm64: arch_timer: Add workaround for hisilicon-161601 erratum
From: Marc Zyngier @ 2017-01-16 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e0aa52a6-8dc7-65d6-6a3a-c753b6c9538e@huawei.com>
On 16/01/17 10:37, Ding Tianhong wrote:
>
>
> On 2017/1/12 21:24, Ding Tianhong wrote:
>>
>> On 2017/1/12 17:11, Marc Zyngier wrote:
>>> On 12/01/17 04:23, Ding Tianhong wrote:
>>>> Hi Marc:
>>>>
>>>> How about this v7, if any suggestions very grateful.
>>>
>>> It's been less than 5 days since you posted this. I'll get to it once I
>>> finish reviewing all the other patches that are sitting in the queue
>>> right before yours.
>>>
>>
>> Ok and sorry for the noisy.
>>
>
> Hi Marc?
>
> After discussion with the chip developer, we decide to update the erratum id for this bug, so I will resend a new version
> about this, if you has start to review this v7 patch set, I think I could wait until you have finished yet. :)
This has to be a stable erratum ID, and it won't be changed once the
workaround is merged (all you'll be able to do is to add new IDs where
the same fix is applicable). So please post the revised series, and make
sure that this is the *final* ID update.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 11/37] PCI: dwc: Split pcie-designware.c into host and core files
From: Kishon Vijay Abraham I @ 2017-01-16 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0a16c862-312f-655e-3d66-bdb0c1f78584@synopsys.com>
Hi Joao,
On Monday 16 January 2017 03:57 PM, Joao Pinto wrote:
>
> Hi,
>
> ?s 5:21 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
>> Hi Joao,
>>
>> On Friday 13 January 2017 10:19 PM, Joao Pinto wrote:
>>> ?s 10:26 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
>>>> Split pcie-designware.c into pcie-designware-host.c that contains
>>>> the host specific parts of the driver and pcie-designware.c that
>>>> contains the parts used by both host driver and endpoint driver.
>>>>
>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>>> ---
>>>> drivers/pci/dwc/Makefile | 2 +-
>>>> drivers/pci/dwc/pcie-designware-host.c | 619 ++++++++++++++++++++++++++++++++
>>>> drivers/pci/dwc/pcie-designware.c | 613 +------------------------------
>>>> drivers/pci/dwc/pcie-designware.h | 8 +
>>>> 4 files changed, 634 insertions(+), 608 deletions(-)
>>>> create mode 100644 drivers/pci/dwc/pcie-designware-host.c
>>>>
>>>> diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
>>>> index 7d27c14..3b57e55 100644
>>>> --- a/drivers/pci/dwc/Makefile
>>>> +++ b/drivers/pci/dwc/Makefile
>>>> @@ -1,4 +1,4 @@
>>>
>>> (snip...)
>>>
>>>> -static void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
>>>> - int type, u64 cpu_addr, u64 pci_addr,
>>>> - u32 size)
>>>> +void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
>>>> + u64 cpu_addr, u64 pci_addr, u32 size)
>>>> {
>>>> u32 retries, val;
>>>>
>>>> @@ -186,220 +151,6 @@ static void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
>>>> dev_err(pci->dev, "iATU is not being enabled\n");
>>>> }
>>>
>>> Kishon, iATU only makes sense in The Root Complex (host), so it should be inside
>>> the pcie-designware-host.
>>
>> That is not true. Outbound ATU should be programmed to access host side buffers
>> and inbound ATU should be programmed for the host to access EP mem space.
>
> Sorry, I was not clear enough. What I was trying to suggest is, since the ATU
> programming is done by the host, wouldn't be better to include it in the
> pcie-designware-host? It is just an architectural detail.
ATU programming is required in EP mode. See "[PATCH 24/37] PCI: dwc:
designware: Add EP mode support" in this patch series.
Anything that's required by both EP mode and RC mode, I've placed in
pcie-designware.c
Thanks
Kishon
^ permalink raw reply
* [RFC PATCH 06/10] arm64/sve: Disallow VL setting for individual threads by default
From: Yao Qi @ 2017-01-16 11:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484220369-23970-7-git-send-email-Dave.Martin@arm.com>
On 17-01-12 11:26:05, Dave Martin wrote:
> General-purpose code in userspace is not expected to work correctly
> if multiple threads are allowed to run concurrently with different
> vector lengths in a single process.
>
> This patch adds an explicit flag PR_SVE_SET_VL_THREAD to request
> this behaviour. Without the flag, vector length setting is
> permitted only for a single-threaded process (which matches the
> expected usage model of setting the vector length at process
> startup).
Hi Dave,
PR_SVE_SET_VL_THREAD can be arch-independent, IMO, because prctl
needs a scope. Looks some of them are system-wide, some of them are
about threads within the same process (like, PR_MPX_ENABLE_MANAGEMENT).
IOW, PR_SVE_SET_VL_THREAD can be general flag, to indicate the scope
of each new ptrcl command is per-thread.
I happen to see PR_SET_FP_MODE in man pages, which is about setting
FP register modes in runtime. It is a little similar to setting VL in
this patch. However the doc doesn't mention the effect or the scope
of this command.
--
Yao (??)
^ permalink raw reply
* [PATCH v7 15/15] irqchip: mbigen: Add ACPI support
From: Lorenzo Pieralisi @ 2017-01-16 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58799376.6040302@huawei.com>
On Sat, Jan 14, 2017 at 10:56:54AM +0800, Hanjun Guo wrote:
> Hi Lorenzo,
>
> On 2017/1/13 18:21, Lorenzo Pieralisi wrote:
> > On Wed, Jan 11, 2017 at 11:06:39PM +0800, Hanjun Guo wrote:
> >> With the preparation of platform msi support and interrupt producer
> >> in DSDT, we can add mbigen ACPI support now.
> >>
> >> We are using _PRS methd to indicate number of irq pins instead
> >> of num_pins in DT to avoid _DSD usage in this case.
> >>
> >> For mbi-gen,
> >> Device(MBI0) {
> >> Name(_HID, "HISI0152")
> >> Name(_UID, Zero)
> >> Name(_CRS, ResourceTemplate() {
> >> Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
> >> })
> >>
> >> Name (_PRS, ResourceTemplate() {
> >> Interrupt(ResourceProducer,...) {12,14,....}
> > I still do not understand why you are using _PRS for this, I think
> > the MBIgen configuration is static and if it is so the Interrupt
> > resource should be part of the _CRS unless there is something I am
> > missing here.
>
> Sorry for not clear in the commit message. MBIgen is an interrupt producer
> which produces irq resource to devices connecting to it, and MBIgen itself
> don't consume wired interrupts.
That's why you mark it as ResourceProducer, but that's not a reason to
put it in the _PRS instead of _CRS.
IIUC _PRS is there to provide a way to define the possible resource
settings of a _configurable_ device (ie programmable) so that the actual
resource value you would programme with a call to its _SRS is sane (ie
the OS has a way, through the _PRS, to detect what possible resource
settings are available for the device).
I think Rafael has more insights into how the _PRS is used on x86
systems so I would ask his point of view here before merrily merging
this code.
> Also devices connecting MBIgen may not consume all the interrupts produced
> by MBIgen, for example, MBIgen may produce 128 interrupts but only half of
> them are currently used, so _PRS here means "provide interrupt resources
> may consumed by devices connecting to it".
See above.
Lorenzo
^ 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