* [PATCH v3 1/3] ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller
From: Carlo Caione @ 2014-01-28 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E78E3F.6080902@redhat.com>
On Tue, Jan 28, 2014 at 12:02 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> On 01/28/2014 11:40 AM, Maxime Ripard wrote:
>
> Jumping in here to try and clarify things, or so I hope at least :)
Thank you :) I'm sure you will explain this better than me.
> The PMIC irq line won't go low until an i2c write to its irq status
> registers write-clears all status bits for which the corresponding
> bit in the irq-mask register is set.
>
> And the only reason the NMI -> GIC also goes low is because the unmask
> operation writes a second ack to the NMI controller in the unmask
> callback of the NMI controller driver.
Exactly. PMIC -> NMI is cleared when the irq handler write-clears all
the IRQs on PMIC while NMI -> GIC is cleared by the ACK in the unmask
callback.
<snip>
> Hmm, I'm not going to say that using a raw irqchip here is a bad idea, it
> sounds like it would be better.
>
> But I don't think this will solve the need the mask / umask. The problem is
> we need to do an i2c write to clear the interrupt source, which needs to
> be done from a thread / workqueue. So when the interrupt handler finishes
> the source won't be cleared yet, and AFAIK then only way to deal with this
> is to mask the interrupt until we've cleared the interrupt source.
That's why the driver using the NMI controller has to use IRQF_ONESHOT
so that the interrupt is not unmasked after the hard interrupt context
handler but it is unmasked after the thread handler function has been
executed (calling the unmask callback)
Thank you for explaining this mess you couldn't be clearer than that.
--
Carlo Caione
^ permalink raw reply
* [linux-sunxi] [PATCH v2 1/5] clk: sunxi: Add support for USB clock-register reset bits
From: Emilio López @ 2014-01-28 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390426587-16287-2-git-send-email-hdegoede@redhat.com>
Hi Hans,
El 22/01/14 18:36, Hans de Goede escribi?:
> The usb-clk register is special in that it not only contains clk gate bits,
> but also has a few reset bits. This commit adds support for this by allowing
> gates type sunxi clks to also register a reset controller.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
(snip)
> static const struct gates_data sun4i_axi_gates_data __initconst = {
> @@ -818,6 +873,7 @@ static void __init sunxi_gates_clk_setup(struct device_node *node,
> struct gates_data *data)
> {
> struct clk_onecell_data *clk_data;
> + struct gates_reset_data *reset_data;
> const char *clk_parent;
> const char *clk_name;
> void *reg;
> @@ -861,6 +917,21 @@ static void __init sunxi_gates_clk_setup(struct device_node *node,
> clk_data->clk_num = i;
>
> of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
> +
> + /* Register a reset controler for gates with reset bits */
> + if (data->reset_mask == 0)
> + return;
> +
> + reset_data = kzalloc(sizeof(*reset_data), GFP_KERNEL);
> + if (!reset_data)
> + return;
> +
> + reset_data->reg = reg;
> + reset_data->lock = &clk_lock;
> + reset_data->rcdev.nr_resets = hweight32(data->reset_mask);
I know I made you change this, but after having a second look into
nr_resets, I think your original implementation makes more sense. This
will break if you use a mask with holes on it. Sorry :(
> + reset_data->rcdev.ops = &sunxi_gates_reset_ops;
> + reset_data->rcdev.of_node = node;
> + reset_controller_register(&reset_data->rcdev);
> }
Emilio
^ permalink raw reply
* [PATCH V3 2/2] ARM: multi_v7_defconfig: add mvebu drivers
From: Jason Cooper @ 2014-01-28 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9609875ac4d1bd7d628bd994e0646340d78e423d.1390936638.git.jason@lakedaemon.net>
Recent boot farm testing has highlighted some issues with mvebu and
multiplatform kernels. Increase the test coverage so we can discover
these issues earlier.
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
v2 -> v3:
- rebase onto arm-soc/for-next so arm-soc can apply directly for v3.14-rcX
v1 -> v2:
- split into two patches, update and +mvebu
arch/arm/configs/multi_v7_defconfig | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 1f3649d94bbb..ef877c44cd21 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -57,6 +57,7 @@ CONFIG_ARCH_ZYNQ=y
CONFIG_TRUSTED_FOUNDATIONS=y
CONFIG_PCI=y
CONFIG_PCI_MSI=y
+CONFIG_PCI_MVEBU=y
CONFIG_PCI_TEGRA=y
CONFIG_HIGHPTE=y
CONFIG_CMA=y
@@ -108,11 +109,13 @@ CONFIG_SATA_MV=y
CONFIG_NETDEVICES=y
CONFIG_SUN4I_EMAC=y
CONFIG_NET_CALXEDA_XGMAC=y
+CONFIG_MVNETA=y
CONFIG_KS8851=y
CONFIG_R8169=y
CONFIG_SMSC911X=y
CONFIG_STMMAC_ETH=y
CONFIG_TI_CPSW=y
+CONFIG_MARVELL_PHY=y
CONFIG_ICPLUS_PHY=y
CONFIG_USB_PEGASUS=y
CONFIG_USB_USBNET=y
@@ -155,10 +158,12 @@ CONFIG_I2C_CHARDEV=y
CONFIG_I2C_MUX=y
CONFIG_I2C_MUX_PINCTRL=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
+CONFIG_I2C_MV64XXX=y
CONFIG_I2C_SIRF=y
CONFIG_I2C_TEGRA=y
CONFIG_SPI=y
CONFIG_SPI_OMAP24XX=y
+CONFIG_SPI_ORION=y
CONFIG_SPI_PL022=y
CONFIG_SPI_SIRF=y
CONFIG_SPI_TEGRA114=y
@@ -177,6 +182,8 @@ CONFIG_BATTERY_SBS=y
CONFIG_CHARGER_TPS65090=y
CONFIG_POWER_RESET_GPIO=y
CONFIG_SENSORS_LM90=y
+CONFIG_THERMAL=y
+CONFIG_ARMADA_THERMAL=y
CONFIG_MFD_AS3722=y
CONFIG_MFD_CROS_EC=y
CONFIG_MFD_CROS_EC_SPI=y
@@ -245,6 +252,7 @@ CONFIG_MMC_SDHCI_SPEAR=y
CONFIG_MMC_SDHCI_BCM_KONA=y
CONFIG_MMC_OMAP=y
CONFIG_MMC_OMAP_HS=y
+CONFIG_MMC_MVSDIO=y
CONFIG_EDAC=y
CONFIG_EDAC_MM_EDAC=y
CONFIG_EDAC_HIGHBANK_MC=y
@@ -259,9 +267,11 @@ CONFIG_RTC_DRV_TPS65910=y
CONFIG_RTC_DRV_EM3027=y
CONFIG_RTC_DRV_PL031=y
CONFIG_RTC_DRV_VT8500=y
+CONFIG_RTC_DRV_MV=y
CONFIG_RTC_DRV_TEGRA=y
CONFIG_DMADEVICES=y
CONFIG_DW_DMAC=y
+CONFIG_MV_XOR=y
CONFIG_TEGRA20_APB_DMA=y
CONFIG_STE_DMA40=y
CONFIG_SIRF_DMA=y
--
1.8.5.3
^ permalink raw reply related
* [PATCH V3 1/2] ARM: multi_v7_defconfig: update for v3.14-rc1
From: Jason Cooper @ 2014-01-28 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390871129-4838-1-git-send-email-jason@lakedaemon.net>
Just the output of:
make ARCH=arm multi_v7_defconfig
make savedefconfig
mv defconfig arch/arm/configs/multi_v7_defconfig
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
v2 -> v3:
- rebase onto arm-soc/for-next so arm-soc can apply directly for v3.14-rcX
v1 -> v2:
- split into two patches, update and +mvebu
arch/arm/configs/multi_v7_defconfig | 13 -------------
1 file changed, 13 deletions(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index e2c0734f22da..1f3649d94bbb 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -58,7 +58,6 @@ CONFIG_TRUSTED_FOUNDATIONS=y
CONFIG_PCI=y
CONFIG_PCI_MSI=y
CONFIG_PCI_TEGRA=y
-CONFIG_SMP=y
CONFIG_HIGHPTE=y
CONFIG_CMA=y
CONFIG_ARM_APPENDED_DTB=y
@@ -176,7 +175,6 @@ CONFIG_GPIO_TPS6586X=y
CONFIG_GPIO_TPS65910=y
CONFIG_BATTERY_SBS=y
CONFIG_CHARGER_TPS65090=y
-CONFIG_POWER_RESET_AS3722=y
CONFIG_POWER_RESET_GPIO=y
CONFIG_SENSORS_LM90=y
CONFIG_MFD_AS3722=y
@@ -205,7 +203,6 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_MEDIA_USB_SUPPORT=y
CONFIG_DRM=y
CONFIG_DRM_TEGRA=y
-CONFIG_DRM_PANEL_SIMPLE=y
CONFIG_FB_ARMCLCD=y
CONFIG_FB_WM8505=y
CONFIG_FB_SIMPLE=y
@@ -222,7 +219,6 @@ CONFIG_SND_SOC_TEGRA_WM8753=y
CONFIG_SND_SOC_TEGRA_WM8903=y
CONFIG_SND_SOC_TEGRA_TRIMSLICE=y
CONFIG_SND_SOC_TEGRA_ALC5632=y
-CONFIG_SND_SOC_TEGRA_MAX98090=y
CONFIG_USB=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_EHCI_HCD=y
@@ -249,14 +245,6 @@ CONFIG_MMC_SDHCI_SPEAR=y
CONFIG_MMC_SDHCI_BCM_KONA=y
CONFIG_MMC_OMAP=y
CONFIG_MMC_OMAP_HS=y
-CONFIG_LEDS_GPIO=y
-CONFIG_LEDS_TRIGGER_TIMER=y
-CONFIG_LEDS_TRIGGER_ONESHOT=y
-CONFIG_LEDS_TRIGGER_HEARTBEAT=y
-CONFIG_LEDS_TRIGGER_GPIO=y
-CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
-CONFIG_LEDS_TRIGGER_TRANSIENT=y
-CONFIG_LEDS_TRIGGER_CAMERA=y
CONFIG_EDAC=y
CONFIG_EDAC_MM_EDAC=y
CONFIG_EDAC_HIGHBANK_MC=y
@@ -289,7 +277,6 @@ CONFIG_MFD_NVEC=y
CONFIG_KEYBOARD_NVEC=y
CONFIG_SERIO_NVEC_PS2=y
CONFIG_NVEC_POWER=y
-CONFIG_NVEC_PAZ00=y
CONFIG_TEGRA_IOMMU_GART=y
CONFIG_TEGRA_IOMMU_SMMU=y
CONFIG_MEMORY=y
--
1.8.5.3
^ permalink raw reply related
* [PATCH v3 07/24] drm/i2c: tda998x: set the video mode from the adjusted value
From: Darren Etheridge @ 2014-01-28 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140128181218.39d1d15e@armhf>
Jean-Francois Moine <moinejf@free.fr> wrote on Tue [2014-Jan-28 18:12:18 +0100]:
> On Thu, 23 Jan 2014 17:29:07 -0600
> Darren Etheridge <detheridge@ti.com> wrote:
>
> > > @@ -896,9 +897,9 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
> > > * TDA19988 requires high-active sync at input stage,
> > > * so invert low-active sync provided by master encoder here
> > > */
> > > - if (mode->flags & DRM_MODE_FLAG_NHSYNC)
> > > + if (adj_mode->flags & DRM_MODE_FLAG_NHSYNC)
> > > reg_set(priv, REG_VIP_CNTRL_3, VIP_CNTRL_3_H_TGL);
> > > - if (mode->flags & DRM_MODE_FLAG_NVSYNC)
> > > + if (adj_mode->flags & DRM_MODE_FLAG_NVSYNC)
> > > reg_set(priv, REG_VIP_CNTRL_3, VIP_CNTRL_3_V_TGL);
> > >
> >
> > Using the adj_mode->flags breaks a workaround I had done on BeagleBone Black
> > (tilcdc + tda998x) to resolve an issue with out of spec syncs from the
> > tlcdc. I invert the HSYNC in adj_mode->flags but don't want the tda998x to
> > really know that I am doing that so I use adj_mode in the tilcdc driver, and
> > mode here in the tda998x driver. The theory being adj_mode contains whatever
> > workarounds I need to do for the driving device and mode has the pristine
> > values that I want to send to the monitor. I would need to look if there is a
> > different way to solve this as I am guessing you are actually using adj_mode in
> > the manner it was intended.
>
> No. In fact, I just wanted the function to use only one mode.
>
> Looking at the other drivers, it seems that they don't touch the
> adjusted_mode, so, for the Cubox, mode and adjusted_mode have same
> values.
>
> I will do an other patch so that you will not have to touch the tilcdc
> driver.
>
Thanks, that would certainly be the easiest path to avoid the regression given
the other drivers that use tda998x don't currently use adj_mode. However I
don't disagree with your reasoning, it would make sense to only use values
from one of the strctures and not a mix and match. Anybody looking at only
the tda998x driver would be confused :) I'll work on finding a different
solution for this.
> --
> Ken ar c'henta? | ** Breizh ha Linux atav! **
> Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH v3 1/2] init/do_mounts.c: ignore final \n in name_to_dev_t
From: Sebastian Capella @ 2014-01-28 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131022175414.14753.58063@capellas-linux>
Quoting Sebastian Capella (2013-10-22 10:54:14)
> Quoting Sebastian Capella (2013-10-10 10:50:10)
> > Quoting Sebastian Capella (2013-10-03 16:47:35)
> > > Quoting Sebastian Capella (2013-10-03 14:42:46)
> > > I looked into removing the const from the store function, but I'm not sure
> > > this is the right idea, so I'm going to shelf that for now.
> > >
> > Below are the three options considered thus far. Do
> > you have any additional suggestions or preferences?
> >
> > 1) copy buffer, remove \n.
> > - v1 patch did this
> > - alternatively could use an array on the stack or a preallocated global
> > Pros:
> > . cleanest change
> > . could use strim() proposed by Andrew
> > Cons:
> > . adds memcpy
> > 2) make name_to_dev_t work with readonly buffer to ignore \n
> > - v2 and v3 patches do this
> > Pros:
> > . no memcpy, no big modifications to unrelated code
> > Cons:
> > . seems more appropriate to harden store functions to user input
> > than name_to_dev_t.
> > . a little complicated
> > 3) remove const from buffer and modify contents in place to remove \n
> > - remove const from sysfs_ops.store, modify dependent definitions
> > - remove const from kobj_attribute.store, modify dependent definitions
> > Pros:
> > . no memcpy
> > Cons:
> > . a lot of modifications
> > . const contract to not modify the input buffer seems the right way.
>
> Hi Andrew,
>
> Do you have any feedback for me on this?
>
> I'm happy do make any changes you think are correct, but I'm unsure if
> you're asking me for option #3 above. It's quite an intrusive change,
> and changes old, established code and I'd like confirmation that's what
> you'd like before proceeding down that path.
>
> I've submitted patches with both options #1 and #2 above.
>
> Thanks,
>
> Sebastian
Ping.
Sorry for the lapse in attention to this.
Could you please clarify what is needed for this to be acceptable?
I'm a little confused about what is being asked of me.
Thanks!
Sebastian
^ permalink raw reply
* [PATCH v2] arm/xen: Initialize event channels earlier
From: Julien Grall @ 2014-01-28 18:54 UTC (permalink / raw)
To: linux-arm-kernel
Event channels driver needs to be initialized very early. Until now, Xen
initialization was done after all CPUs was bring up.
We can safely move the initialization to an early initcall.
Also use a cpu notifier to:
- Register the VCPU when the CPU is prepared
- Enable event channel IRQ when the CPU is running
Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
Changes in v2:
- Check earlier if the event IRQ is valid
- We can safely register the VCPU when the cpu is booting
---
arch/arm/xen/enlighten.c | 71 ++++++++++++++++++++++++++++------------------
1 file changed, 44 insertions(+), 27 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 293eeea..b96723e 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -23,6 +23,7 @@
#include <linux/of_address.h>
#include <linux/cpuidle.h>
#include <linux/cpufreq.h>
+#include <linux/cpu.h>
#include <linux/mm.h>
@@ -154,7 +155,7 @@ int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
}
EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
-static void __init xen_percpu_init(void *unused)
+static void xen_percpu_init(void)
{
struct vcpu_register_vcpu_info info;
struct vcpu_info *vcpup;
@@ -193,6 +194,31 @@ static void xen_power_off(void)
BUG();
}
+static int xen_cpu_notification(struct notifier_block *self,
+ unsigned long action,
+ void *hcpu)
+{
+ switch (action) {
+ case CPU_STARTING:
+ xen_percpu_init();
+ break;
+ default:
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block xen_cpu_notifier = {
+ .notifier_call = xen_cpu_notification,
+};
+
+static irqreturn_t xen_arm_callback(int irq, void *arg)
+{
+ xen_hvm_evtchn_do_upcall();
+ return IRQ_HANDLED;
+}
+
/*
* see Documentation/devicetree/bindings/arm/xen.txt for the
* documentation of the Xen Device Tree format.
@@ -229,6 +255,10 @@ static int __init xen_guest_init(void)
xen_events_irq = irq_of_parse_and_map(node, 0);
pr_info("Xen %s support found, events_irq=%d gnttab_frame=%pa\n",
version, xen_events_irq, &grant_frames);
+
+ if (xen_events_irq < 0)
+ return -ENODEV;
+
xen_domain_type = XEN_HVM_DOMAIN;
xen_setup_features();
@@ -281,9 +311,21 @@ static int __init xen_guest_init(void)
disable_cpuidle();
disable_cpufreq();
+ xen_init_IRQ();
+
+ if (request_percpu_irq(xen_events_irq, xen_arm_callback,
+ "events", &xen_vcpu)) {
+ pr_err("Error request IRQ %d\n", xen_events_irq);
+ return -EINVAL;
+ }
+
+ xen_percpu_init();
+
+ register_cpu_notifier(&xen_cpu_notifier);
+
return 0;
}
-core_initcall(xen_guest_init);
+early_initcall(xen_guest_init);
static int __init xen_pm_init(void)
{
@@ -297,31 +339,6 @@ static int __init xen_pm_init(void)
}
late_initcall(xen_pm_init);
-static irqreturn_t xen_arm_callback(int irq, void *arg)
-{
- xen_hvm_evtchn_do_upcall();
- return IRQ_HANDLED;
-}
-
-static int __init xen_init_events(void)
-{
- if (!xen_domain() || xen_events_irq < 0)
- return -ENODEV;
-
- xen_init_IRQ();
-
- if (request_percpu_irq(xen_events_irq, xen_arm_callback,
- "events", &xen_vcpu)) {
- pr_err("Error requesting IRQ %d\n", xen_events_irq);
- return -EINVAL;
- }
-
- on_each_cpu(xen_percpu_init, NULL, 0);
-
- return 0;
-}
-postcore_initcall(xen_init_events);
-
/* In the hypervisor.S file. */
EXPORT_SYMBOL_GPL(HYPERVISOR_event_channel_op);
EXPORT_SYMBOL_GPL(HYPERVISOR_grant_table_op);
--
1.7.10.4
^ permalink raw reply related
* [PATCH v3] ARM: hw_breakpoint: Add ARMv8 support
From: Christopher Covington @ 2014-01-28 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140128183851.GK2885@mudshark.cambridge.arm.com>
Add the trivial support necessary to get hardware breakpoints
working for GDB on ARMv8 simulators running in AArch32 mode.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
v3: assume for now that ARMv9 and later will update FSR
v2: modify debug_exception_updates_fsr
arch/arm/include/asm/hw_breakpoint.h | 1 +
arch/arm/kernel/hw_breakpoint.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/hw_breakpoint.h b/arch/arm/include/asm/hw_breakpoint.h
index eef55ea..8e427c7 100644
--- a/arch/arm/include/asm/hw_breakpoint.h
+++ b/arch/arm/include/asm/hw_breakpoint.h
@@ -51,6 +51,7 @@ static inline void decode_ctrl_reg(u32 reg,
#define ARM_DEBUG_ARCH_V7_ECP14 3
#define ARM_DEBUG_ARCH_V7_MM 4
#define ARM_DEBUG_ARCH_V7_1 5
+#define ARM_DEBUG_ARCH_V8 6
/* Breakpoint */
#define ARM_BREAKPOINT_EXECUTE 0
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index 3d44660..9da35c6 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -167,7 +167,7 @@ static int debug_arch_supported(void)
/* Can we determine the watchpoint access type from the fsr? */
static int debug_exception_updates_fsr(void)
{
- return 0;
+ return get_debug_arch() >= ARM_DEBUG_ARCH_V8;
}
/* Determine number of WRP registers available. */
@@ -257,6 +257,7 @@ static int enable_monitor_mode(void)
break;
case ARM_DEBUG_ARCH_V7_ECP14:
case ARM_DEBUG_ARCH_V7_1:
+ case ARM_DEBUG_ARCH_V8:
ARM_DBG_WRITE(c0, c2, 2, (dscr | ARM_DSCR_MDBGEN));
isb();
break;
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by the Linux Foundation.
^ permalink raw reply related
* [PATCH v2 1/7] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
From: Mike Turquette @ 2014-01-28 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuA9ah1vsgpD04QhM5RApkCe9xcvpPkLvdwzgadKGWvngAt+g@mail.gmail.com>
On Mon, Jan 27, 2014 at 9:30 PM, Thomas Abraham <ta.omasab@gmail.com> wrote:
> Hi Mike,
>
> On Tue, Jan 28, 2014 at 1:55 AM, Mike Turquette <mturquette@linaro.org> wrote:
>> Quoting Thomas Abraham (2014-01-18 04:10:51)
>>> From: Thomas Abraham <thomas.ab@samsung.com>
>>>
>>> On some platforms such as the Samsung Exynos, changing the frequency
>>> of the CPU clock requires changing the frequency of the PLL that is
>>> supplying the CPU clock. To change the frequency of the PLL, the CPU
>>> clock is temporarily reparented to another parent clock.
>>>
>>> The clock frequency of this temporary parent clock could be much higher
>>> than the clock frequency of the PLL at the time of reparenting. Due
>>> to the temporary increase in the CPU clock speed, the CPU (and any other
>>> components in the CPU clock domain such as dividers, mux, etc.) have to
>>> to be operated at a higher voltage level, called the safe voltage level.
>>> This patch adds optional support to temporarily switch to a safe voltage
>>> level during CPU frequency transitions.
>>>
>>> Cc: Shawn Guo <shawn.guo@linaro.org>
>>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>>
>> I'm not a fan of this change. This corner case should be abstracted away
>> somehow. I had talked to Chander Kayshap previously about handling
>> voltage changes in clock notifier callbacks, which then renders any
>> voltage change as a trivial part of the clock rate transition. That
>> means that this "safe voltage" thing could be handled automagically
>> without any additional code in the CPUfreq driver.
>>
>> There are two nice ways to do this with the clock framework. First is
>> explicit re-parenting with voltage scaling done in the clock rate-change
>> notifiers:
>>
>> clk_set_parent(cpu_clk, temp_parent);
>> /* implicit voltage scaling to "safe voltage" happens above */
>> clk_set_rate(pll, some_rate);
>> clk_set_parent(cpu_clk, pll);
>> /* implicit voltage scaling to nominal OPP voltage happens above */
>>
>> The above sequence would require a separate exnyos CPUfreq driver, due
>> to the added clk_set_parent logic.
>>
>> The second way to do this is to abstract the clk re-muxing logic out
>> into the clk driver, which would allow cpufreq-cpu0 to be used for the
>> exynos chips.
>
> This is the approach this patch series takes (patch 2/7). The clock
> re-muxing logic is handled by a clock driver code. The difference from
> what you suggested is that the safe voltage (that may be optionally)
> required before doing the re-muxing is handled here in cpufreq-cpu0
> driver.
Right, I understand the approach taken in this series and I'm not sure
it is the right one. Why does the clock driver handle the remuxing if
it is a functional dependency of the ARM core? As far as I can tell
the remux does not happen because it is necessary to generate the
required clock rate, but because we don't want to run the ARM core out
of spec for a short time while the PLL relocks. Assuming I have that
part of it right, I prefer for the parent mux operation to be a part
of the CPUfreq driver's .target callback instead of hidden away in the
clock driver.
A common pattern I'm seeing for the last 18 months is code
consolidation for the sake of code consolidation and it is not always
a good thing. Having hardware-specific machine drivers under
drivers/cpufreq/ is the right way to go, and we should only
consolidate a driver to cpufreq-cpu0 if it makes sense.
>
> The safe voltage setup can be done in the notifier as you suggested.
> But, doing that in cpufreq-cpu0 driver will help other platforms reuse
> this feature if required. Also, if done here, the regulator handling
> is localized in this driver which otherwise would need to be handled
> in two places, cpufreq-cpu0 driver and the clock notifier.
The notifiers are reusable across other platforms. And the notifier
can be entirely set up within the cpufreq driver. Code location is not
a problem. See this RFC series:
https://lkml.org/lkml/2013/7/7/110
>
> So I tend to prefer the approach in this patch but I am willing to
> consider any suggestions. Shawn, it would be helpful if you could let
> us know your thoughts on this. I am almost done with testing the v3 of
> this series and want to post it so if there are any objections to the
> changes in this patch, please let me know.
Well I wonder if the whole approach could be more generalized. The DT
bindings for CPU frequencies could be used by any platform instead of
being Exynos-specific. We could construct a binding which captures an
arbitrary clock sub-tree snapshot. By that I mean a DT binding in
which any number of clocks and their parents and rates could be
specified in a table. Separately we could have a binding that links a
given clock at a given rate to some specified regulator and voltage.
So in this way the bindings are re-usable.
These DT ideas should be considered separately from the CPUfreq notes
outlined above, and I will respond to patch #3 in this series once I
have a chance.
Thanks,
Mike
>
> Thanks,
> Thomas.
>
>>
>> I'm more a fan of explicitly listing the Exact Steps for the cpu opp
>> transition in a separate exynos-specific CPUfreq driver, but that's
>> probably an unpopular view.
>>
>> Regards,
>> Mike
>>
>>> ---
>>> .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 7 ++++
>>> drivers/cpufreq/cpufreq-cpu0.c | 37 +++++++++++++++++--
>>> 2 files changed, 40 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>>> index f055515..37453ab 100644
>>> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
>>> @@ -19,6 +19,12 @@ Optional properties:
>>> - cooling-min-level:
>>> - cooling-max-level:
>>> Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
>>> +- safe-opp: Certain platforms require that during a opp transition,
>>> + a system should not go below a particular opp level. For such systems,
>>> + this property specifies the minimum opp to be maintained during the
>>> + opp transitions. The safe-opp value is a tuple with first element
>>> + representing the safe frequency and the second element representing the
>>> + safe voltage.
>>>
>>> Examples:
>>>
>>> @@ -36,6 +42,7 @@ cpus {
>>> 396000 950000
>>> 198000 850000
>>> >;
>>> + safe-opp = <396000 950000>
>>> clock-latency = <61036>; /* two CLK32 periods */
>>> #cooling-cells = <2>;
>>> cooling-min-level = <0>;
>>> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
>>> index 0c12ffc..075d3d1 100644
>>> --- a/drivers/cpufreq/cpufreq-cpu0.c
>>> +++ b/drivers/cpufreq/cpufreq-cpu0.c
>>> @@ -27,6 +27,8 @@
>>>
>>> static unsigned int transition_latency;
>>> static unsigned int voltage_tolerance; /* in percentage */
>>> +static unsigned long safe_frequency;
>>> +static unsigned long safe_voltage;
>>>
>>> static struct device *cpu_dev;
>>> static struct clk *cpu_clk;
>>> @@ -64,17 +66,30 @@ static int cpu0_set_target(struct cpufreq_policy *policy, unsigned int index)
>>> volt_old = regulator_get_voltage(cpu_reg);
>>> }
>>>
>>> - pr_debug("%u MHz, %ld mV --> %u MHz, %ld mV\n",
>>> + pr_debug("\n\n%u MHz, %ld mV --> %u MHz, %ld mV\n",
>>> old_freq / 1000, volt_old ? volt_old / 1000 : -1,
>>> new_freq / 1000, volt ? volt / 1000 : -1);
>>>
>>> /* scaling up? scale voltage before frequency */
>>> - if (!IS_ERR(cpu_reg) && new_freq > old_freq) {
>>> + if (!IS_ERR(cpu_reg) && new_freq > old_freq &&
>>> + new_freq >= safe_frequency) {
>>> ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
>>> if (ret) {
>>> pr_err("failed to scale voltage up: %d\n", ret);
>>> return ret;
>>> }
>>> + } else if (!IS_ERR(cpu_reg) && old_freq < safe_frequency) {
>>> + /*
>>> + * the scaled up voltage level for the new_freq is lower
>>> + * than the safe voltage level. so set safe_voltage
>>> + * as the intermediate voltage level and revert it
>>> + * back after the frequency has been changed.
>>> + */
>>> + ret = regulator_set_voltage_tol(cpu_reg, safe_voltage, tol);
>>> + if (ret) {
>>> + pr_err("failed to set safe voltage: %d\n", ret);
>>> + return ret;
>>> + }
>>> }
>>>
>>> ret = clk_set_rate(cpu_clk, freq_exact);
>>> @@ -86,7 +101,8 @@ static int cpu0_set_target(struct cpufreq_policy *policy, unsigned int index)
>>> }
>>>
>>> /* scaling down? scale voltage after frequency */
>>> - if (!IS_ERR(cpu_reg) && new_freq < old_freq) {
>>> + if (!IS_ERR(cpu_reg) &&
>>> + (new_freq < old_freq || new_freq < safe_frequency)) {
>>> ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
>>> if (ret) {
>>> pr_err("failed to scale voltage down: %d\n", ret);
>>> @@ -116,6 +132,8 @@ static struct cpufreq_driver cpu0_cpufreq_driver = {
>>>
>>> static int cpu0_cpufreq_probe(struct platform_device *pdev)
>>> {
>>> + const struct property *prop;
>>> + struct dev_pm_opp *opp;
>>> struct device_node *np;
>>> int ret;
>>>
>>> @@ -165,13 +183,24 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
>>> goto out_put_node;
>>> }
>>>
>>> + prop = of_find_property(np, "safe-opp", NULL);
>>> + if (prop) {
>>> + if (prop->value && (prop->length / sizeof(u32)) == 2) {
>>> + const __be32 *val;
>>> + val = prop->value;
>>> + safe_frequency = be32_to_cpup(val++);
>>> + safe_voltage = be32_to_cpup(val);
>>> + } else {
>>> + pr_err("invalid safe-opp level specified\n");
>>> + }
>>> + }
>>> +
>>> of_property_read_u32(np, "voltage-tolerance", &voltage_tolerance);
>>>
>>> if (of_property_read_u32(np, "clock-latency", &transition_latency))
>>> transition_latency = CPUFREQ_ETERNAL;
>>>
>>> if (!IS_ERR(cpu_reg)) {
>>> - struct dev_pm_opp *opp;
>>> unsigned long min_uV, max_uV;
>>> int i;
>>>
>>> --
>>> 1.6.6.rc2
>>>
^ permalink raw reply
* [GIT PULL] ARM: mvebu: DT boards for v3.14 (incr #6)
From: Jason Cooper @ 2014-01-28 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMiTSa=ECDiVtgO44At9tqYCb2Ap8KWwG=FBStVEycqKcQ@mail.gmail.com>
On Tue, Jan 28, 2014 at 10:36:51AM -0800, Olof Johansson wrote:
> On Mon, Jan 20, 2014 at 12:01 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> > All,
> >
> > I had a few boards that came in late in the cycle. I was holding on to
> > them for the next round, but after Olof's comment this morning:
> >
> > Re: [PATCH 0/2] DT updates for Hummingboard and new Cubox-i
> > http://www.spinics.net/lists/arm-kernel/msg301777.html
> >
> > I figured I'd send them off. As usual, they've been in -next for a
> > while. Also, this is an incremental request from tags/mvebu-dt-3.14-5
> > to tags/mvebu-dt-3.14-6 on the mvebu/dt branch.
> >
> > If this is going to be ok for the forseeable future, I'll do a separate
> > branch for new boards next time around.
>
> I should probably clarify my previous statement. I don't think we want
> a free-for-all on new DT contents all the way up until -rc<lownumber>,
> but what we can allow sometimes is new DT files when there's good
> reason to do so -- for example for platforms where a lot of new code
> has landed and it's been hard to sequence DT updates with the rest,
> etc.
ok, no problem.
> So, if you send these late requests please be prepared to motivate
> them. :) These don't look urgent to me so I think we'll queue them for
> 3.15 once -rc1 is out, if that's OK with you.
Yep, I just didn't want to miss the boat. :) Please drop this request
and I'll queue these up for post-rc1.
thx,
Jason.
^ permalink raw reply
* [PATCH v2] ARM: hw_breakpoint: Add ARMv8 support
From: Will Deacon @ 2014-01-28 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390933583-1278-1-git-send-email-cov@codeaurora.org>
On Tue, Jan 28, 2014 at 06:26:23PM +0000, Christopher Covington wrote:
> Add the trivial support necessary to get hardware breakpoints
> working for GDB on ARMv8 simulators running in AArch32 mode.
>
> Signed-off-by: Christopher Covington <cov@codeaurora.org>
> ---
>
> v2: modify debug_exception_updates_fsr
>
> arch/arm/include/asm/hw_breakpoint.h | 1 +
> arch/arm/kernel/hw_breakpoint.c | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/hw_breakpoint.h b/arch/arm/include/asm/hw_breakpoint.h
> index eef55ea..8e427c7 100644
> --- a/arch/arm/include/asm/hw_breakpoint.h
> +++ b/arch/arm/include/asm/hw_breakpoint.h
> @@ -51,6 +51,7 @@ static inline void decode_ctrl_reg(u32 reg,
> #define ARM_DEBUG_ARCH_V7_ECP14 3
> #define ARM_DEBUG_ARCH_V7_MM 4
> #define ARM_DEBUG_ARCH_V7_1 5
> +#define ARM_DEBUG_ARCH_V8 6
>
> /* Breakpoint */
> #define ARM_BREAKPOINT_EXECUTE 0
> diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
> index 3d44660..a711b27 100644
> --- a/arch/arm/kernel/hw_breakpoint.c
> +++ b/arch/arm/kernel/hw_breakpoint.c
> @@ -167,7 +167,7 @@ static int debug_arch_supported(void)
> /* Can we determine the watchpoint access type from the fsr? */
> static int debug_exception_updates_fsr(void)
> {
> - return 0;
> + return get_debug_arch() == ARM_DEBUG_ARCH_V8;
I'd probably make that >= to save on future changes.
With that change:
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [GIT PULL] ARM: mvebu: DT boards for v3.14 (incr #6)
From: Olof Johansson @ 2014-01-28 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120200110.GW29184@titan.lakedaemon.net>
On Mon, Jan 20, 2014 at 12:01 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> All,
>
> I had a few boards that came in late in the cycle. I was holding on to
> them for the next round, but after Olof's comment this morning:
>
> Re: [PATCH 0/2] DT updates for Hummingboard and new Cubox-i
> http://www.spinics.net/lists/arm-kernel/msg301777.html
>
> I figured I'd send them off. As usual, they've been in -next for a
> while. Also, this is an incremental request from tags/mvebu-dt-3.14-5
> to tags/mvebu-dt-3.14-6 on the mvebu/dt branch.
>
> If this is going to be ok for the forseeable future, I'll do a separate
> branch for new boards next time around.
I should probably clarify my previous statement. I don't think we want
a free-for-all on new DT contents all the way up until -rc<lownumber>,
but what we can allow sometimes is new DT files when there's good
reason to do so -- for example for platforms where a lot of new code
has landed and it's been hard to sequence DT updates with the rest,
etc.
So, if you send these late requests please be prepared to motivate
them. :) These don't look urgent to me so I think we'll queue them for
3.15 once -rc1 is out, if that's OK with you.
-Olof
^ permalink raw reply
* [Q] block / zynq: DMA bouncing
From: Jason Gunthorpe @ 2014-01-28 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140128134827.GK15937@n2100.arm.linux.org.uk>
On Tue, Jan 28, 2014 at 01:48:27PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 28, 2014 at 02:28:28PM +0100, Guennadi Liakhovetski wrote:
> > +static void __init zynq_memory_init(void)
> > +{
> > + /*
> > + * Reserve the 0-0x4000 addresses (before page tables and kernel)
> > + * which can't be used for DMA
> > + */
> > + if (!__pa(PAGE_OFFSET))
> > + memblock_reserve(0, 0x4000);
>
> Or maybe this:
>
> memblock_reserve(__pa(PAGE_OFFSET), __pa(swapper_pg_dir));
>
> since that's actually what you mean here.
Can you have a non-zero PAGE_OFFSET and swapper_pg_dir != 0x4000?
Crash dump kernel maybe?
Perhaps:
if (__pa(PAGE_OFFSET) < 0x8000)
memblock_reserve(__pa(PAGE_OFFSET),
min(__pa(swapper_pg_dir), 0x8000));
?
The Zynq TRM, UG585 pg 115, describes this issue. Physical addresses
below 0x8000 are not accessible to DMA from the AXI interconnect.
Though, how does a crash dump kernel know it needs to bounce buffer
the swapper if it dumps it via DMA?
Regards,
Jason
^ permalink raw reply
* [linux-pm] ARM hibernation / suspend-to-disk
From: Sebastian Capella @ 2014-01-28 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140128182245.18840.51279@capellas-linux>
Quoting Sebastian Capella (2014-01-28 10:22:45)
> Otherwise, I am still looking at how to get this upstream by verifying
> on omap 5. In my case, I still have the chicken egg problem, where I'm
> trying to verify on omap 5 with out of tree patches.
Sorry, incorrect, I'm verifying on Beaglebone black not OMAP 5.
^ permalink raw reply
* [PATCH V2 1/2] ARM: multi_v7_defconfig: update for v3.13-rc1
From: Jason Cooper @ 2014-01-28 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMh3qho=-3sN2-ju_-npggLSvD-s4Mnwt0EyVVh+YT7jYA@mail.gmail.com>
On Tue, Jan 28, 2014 at 10:22:31AM -0800, Olof Johansson wrote:
> On Tue, Jan 28, 2014 at 10:20 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> > Just the output of:
> >
> > make ARCH=arm multi_v7_defconfig
> > make savedefconfig
> > mv defconfig arch/arm/configs/multi_v7_defconfig
> >
> > Signed-off-by: Jason Cooper <jason@lakedaemon.net>
>
> Do you mean 3.14-rc1? If so, this will likely have conflicts with the
> multi_v7_defconfig that we still have in our for-next branch (should
> be queued in a regular branch now that all the contents has been
> merged in by Linus).
No, I meant v3.13-rc1. mvebu/defconfig branch is still based on
v3.13-rc1 since there is no stable tag for v3.14 yet.
Let me know how you'd like me to handle it. My main goal is to have
something locally I can build and test against as well. If you think
you can get this in in time for v3.14-rc1, I'll rebase this series
against arm-soc/for-next and then base all my branches off of v3.14-rc1
when it drops.
thx,
Jason.
^ permalink raw reply
* [PATCH v2] ARM: hw_breakpoint: Add ARMv8 support
From: Christopher Covington @ 2014-01-28 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390415365-17230-1-git-send-email-cov@codeaurora.org>
Add the trivial support necessary to get hardware breakpoints
working for GDB on ARMv8 simulators running in AArch32 mode.
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
v2: modify debug_exception_updates_fsr
arch/arm/include/asm/hw_breakpoint.h | 1 +
arch/arm/kernel/hw_breakpoint.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/hw_breakpoint.h b/arch/arm/include/asm/hw_breakpoint.h
index eef55ea..8e427c7 100644
--- a/arch/arm/include/asm/hw_breakpoint.h
+++ b/arch/arm/include/asm/hw_breakpoint.h
@@ -51,6 +51,7 @@ static inline void decode_ctrl_reg(u32 reg,
#define ARM_DEBUG_ARCH_V7_ECP14 3
#define ARM_DEBUG_ARCH_V7_MM 4
#define ARM_DEBUG_ARCH_V7_1 5
+#define ARM_DEBUG_ARCH_V8 6
/* Breakpoint */
#define ARM_BREAKPOINT_EXECUTE 0
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index 3d44660..a711b27 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -167,7 +167,7 @@ static int debug_arch_supported(void)
/* Can we determine the watchpoint access type from the fsr? */
static int debug_exception_updates_fsr(void)
{
- return 0;
+ return get_debug_arch() == ARM_DEBUG_ARCH_V8;
}
/* Determine number of WRP registers available. */
@@ -257,6 +257,7 @@ static int enable_monitor_mode(void)
break;
case ARM_DEBUG_ARCH_V7_ECP14:
case ARM_DEBUG_ARCH_V7_1:
+ case ARM_DEBUG_ARCH_V8:
ARM_DBG_WRITE(c0, c2, 2, (dscr | ARM_DSCR_MDBGEN));
isb();
break;
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by the Linux Foundation.
^ permalink raw reply related
* [linux-pm] ARM hibernation / suspend-to-disk
From: Sebastian Capella @ 2014-01-28 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140128141458.GD8713@xo-6d-61-c0.localdomain>
Quoting Pavel Machek (2014-01-28 06:14:58)
> > > what's the status of suspend-to-disk on ARM? The most recent discussion I
> > > found is:
> > > http://lists.linuxfoundation.org/pipermail/linux-pm/2012-November/034997.html
> > >
> > > with no replies at all. Is anyone still working on that? Anyone got it running?
Hi Pavel, Russ,
I have been looking and working with Russ' most recent branch based
on the 3.12 kernel, which includes the big pile of patches for OMAP.
(https://github.com/russdill/linux/commits/arm-hibernation-am33xx-v3.12)
He has hibernation mostly working and I have been able to run 1400 or
so entry/exits overnight there on beaglebone black without issue.
Combining this with device activity has been tricky. An active
network will lose the link on restore. Active SD traffic will
eventually hang (Last night ran for about 11 hours before hanging
after ~350 or so hibernations). I have not found where this is or
the cause.
> > For ARM hibernation support to get merged, there needs to be at least
> > one platform that supports it. the am335x code I have is not ready as it
> > still relies on PM patchsets that have not yet themselves been merged.
>
> Given that we have chicken-and-egg problem here, I believe it makes sense
> to merge generic ARM hibernation support now.
If you want to go ahead with upstreaming the base patch, Russ, would you
like me to do that for you or will you have time to do this?
Otherwise, I am still looking at how to get this upstream by verifying
on omap 5. In my case, I still have the chicken egg problem, where I'm
trying to verify on omap 5 with out of tree patches.
Thanks,
Sebastian
^ permalink raw reply
* [PATCH V2 1/2] ARM: multi_v7_defconfig: update for v3.13-rc1
From: Olof Johansson @ 2014-01-28 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14397edee7978df1d80e048d7cd02c826a91af56.1390932990.git.jason@lakedaemon.net>
On Tue, Jan 28, 2014 at 10:20 AM, Jason Cooper <jason@lakedaemon.net> wrote:
> Just the output of:
>
> make ARCH=arm multi_v7_defconfig
> make savedefconfig
> mv defconfig arch/arm/configs/multi_v7_defconfig
>
> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Do you mean 3.14-rc1? If so, this will likely have conflicts with the
multi_v7_defconfig that we still have in our for-next branch (should
be queued in a regular branch now that all the contents has been
merged in by Linus).
-Olof
^ permalink raw reply
* [PATCH V2 2/2] ARM: multi_v7_defconfig: add mvebu drivers
From: Jason Cooper @ 2014-01-28 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14397edee7978df1d80e048d7cd02c826a91af56.1390932990.git.jason@lakedaemon.net>
Recent boot farm testing has highlighted some issues with mvebu and
multiplatform kernels. Increase the test coverage so we can discover
these issues earlier.
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
v1 -> v2:
- updating the defconfig is a separate patch from this.
arch/arm/configs/multi_v7_defconfig | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 1e37e862baea..37133d9c960b 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -44,6 +44,9 @@ CONFIG_ARCH_VEXPRESS_CA9X4=y
CONFIG_ARCH_VIRT=y
CONFIG_ARCH_WM8850=y
CONFIG_ARCH_ZYNQ=y
+CONFIG_PCI=y
+CONFIG_PCI_MSI=y
+CONFIG_PCI_MVEBU=y
CONFIG_SMP=y
CONFIG_HIGHPTE=y
CONFIG_ARM_APPENDED_DTB=y
@@ -64,9 +67,11 @@ CONFIG_SATA_MV=y
CONFIG_NETDEVICES=y
CONFIG_SUN4I_EMAC=y
CONFIG_NET_CALXEDA_XGMAC=y
+CONFIG_MVNETA=y
CONFIG_KS8851=y
CONFIG_SMSC911X=y
CONFIG_STMMAC_ETH=y
+CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_SPEAR=y
CONFIG_SERIO_AMBAKMI=y
CONFIG_SERIAL_8250=y
@@ -89,10 +94,12 @@ CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
CONFIG_SERIAL_FSL_LPUART=y
CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
+CONFIG_I2C_MV64XXX=y
CONFIG_I2C_SIRF=y
CONFIG_I2C_TEGRA=y
CONFIG_SPI=y
CONFIG_SPI_OMAP24XX=y
+CONFIG_SPI_ORION=y
CONFIG_SPI_PL022=y
CONFIG_SPI_SIRF=y
CONFIG_SPI_TEGRA114=y
@@ -100,6 +107,8 @@ CONFIG_SPI_TEGRA20_SLINK=y
CONFIG_PINCTRL_SINGLE=y
CONFIG_GPIO_GENERIC_PLATFORM=y
CONFIG_GPIO_TWL4030=y
+CONFIG_THERMAL=y
+CONFIG_ARMADA_THERMAL=y
CONFIG_REGULATOR_AB8500=y
CONFIG_REGULATOR_GPIO=y
CONFIG_REGULATOR_TPS51632=y
@@ -136,6 +145,7 @@ CONFIG_MMC_SDHCI_TEGRA=y
CONFIG_MMC_SDHCI_SPEAR=y
CONFIG_MMC_OMAP=y
CONFIG_MMC_OMAP_HS=y
+CONFIG_MMC_MVSDIO=y
CONFIG_EDAC=y
CONFIG_EDAC_MM_EDAC=y
CONFIG_EDAC_HIGHBANK_MC=y
@@ -144,9 +154,11 @@ CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_TWL4030=y
CONFIG_RTC_DRV_PL031=y
CONFIG_RTC_DRV_VT8500=y
+CONFIG_RTC_DRV_MV=y
CONFIG_RTC_DRV_TEGRA=y
CONFIG_DMADEVICES=y
CONFIG_DW_DMAC=y
+CONFIG_MV_XOR=y
CONFIG_TEGRA20_APB_DMA=y
CONFIG_STE_DMA40=y
CONFIG_SIRF_DMA=y
@@ -155,6 +167,7 @@ CONFIG_IMX_SDMA=y
CONFIG_IMX_DMA=y
CONFIG_MXS_DMA=y
CONFIG_DMA_OMAP=y
+CONFIG_MEMORY=y
CONFIG_PWM=y
CONFIG_PWM_VT8500=y
CONFIG_OMAP_USB2=y
--
1.8.5.3
^ permalink raw reply related
* [PATCH V2 1/2] ARM: multi_v7_defconfig: update for v3.13-rc1
From: Jason Cooper @ 2014-01-28 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390871129-4838-1-git-send-email-jason@lakedaemon.net>
Just the output of:
make ARCH=arm multi_v7_defconfig
make savedefconfig
mv defconfig arch/arm/configs/multi_v7_defconfig
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
---
v1 -> v2:
- broke out updating the defconfig as a separate patch.
arch/arm/configs/multi_v7_defconfig | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 4a5903e04827..1e37e862baea 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -34,7 +34,6 @@ CONFIG_ARCH_TEGRA=y
CONFIG_ARCH_TEGRA_2x_SOC=y
CONFIG_ARCH_TEGRA_3x_SOC=y
CONFIG_ARCH_TEGRA_114_SOC=y
-CONFIG_TEGRA_PCI=y
CONFIG_TEGRA_EMC_SCALING_ENABLE=y
CONFIG_ARCH_U8500=y
CONFIG_MACH_HREFV60=y
@@ -68,7 +67,6 @@ CONFIG_NET_CALXEDA_XGMAC=y
CONFIG_KS8851=y
CONFIG_SMSC911X=y
CONFIG_STMMAC_ETH=y
-CONFIG_MDIO_SUN4I=y
CONFIG_KEYBOARD_SPEAR=y
CONFIG_SERIO_AMBAKMI=y
CONFIG_SERIAL_8250=y
@@ -102,14 +100,13 @@ CONFIG_SPI_TEGRA20_SLINK=y
CONFIG_PINCTRL_SINGLE=y
CONFIG_GPIO_GENERIC_PLATFORM=y
CONFIG_GPIO_TWL4030=y
-CONFIG_REGULATOR_GPIO=y
CONFIG_REGULATOR_AB8500=y
+CONFIG_REGULATOR_GPIO=y
CONFIG_REGULATOR_TPS51632=y
CONFIG_REGULATOR_TPS62360=y
CONFIG_REGULATOR_TWL4030=y
CONFIG_REGULATOR_VEXPRESS=y
CONFIG_DRM=y
-CONFIG_TEGRA_HOST1X=y
CONFIG_DRM_TEGRA=y
CONFIG_FB_ARMCLCD=y
CONFIG_FB_WM8505=y
@@ -124,8 +121,6 @@ CONFIG_USB_STORAGE=y
CONFIG_USB_CHIPIDEA=y
CONFIG_USB_CHIPIDEA_HOST=y
CONFIG_AB8500_USB=y
-CONFIG_NOP_USB_XCEIV=y
-CONFIG_OMAP_USB2=y
CONFIG_OMAP_USB3=y
CONFIG_SAMSUNG_USB2PHY=y
CONFIG_SAMSUNG_USB3PHY=y
@@ -155,7 +150,6 @@ CONFIG_DW_DMAC=y
CONFIG_TEGRA20_APB_DMA=y
CONFIG_STE_DMA40=y
CONFIG_SIRF_DMA=y
-CONFIG_TI_EDMA=y
CONFIG_PL330_DMA=y
CONFIG_IMX_SDMA=y
CONFIG_IMX_DMA=y
@@ -163,6 +157,7 @@ CONFIG_MXS_DMA=y
CONFIG_DMA_OMAP=y
CONFIG_PWM=y
CONFIG_PWM_VT8500=y
+CONFIG_OMAP_USB2=y
CONFIG_EXT4_FS=y
CONFIG_TMPFS=y
CONFIG_NFS_FS=y
--
1.8.5.3
^ permalink raw reply related
* [GIT PULL] ARM: mvebu: fixes for v3.13.x/v3.14-rc1
From: Kevin Hilman @ 2014-01-28 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127193434.GN29184@titan.lakedaemon.net>
Jason Cooper <jason@lakedaemon.net> writes:
> Kevin,
>
> Here's the pull we discussed earlier. Sorry my "send pull requests"
> cron job failed me.
>
> As usual, been in -next (a little long this time ;-) ), incremental from
> tags/mvebu-fixes-3.13 to tags/mvebu-fixes-3.13-2 in the mvebu/fixes
> branch.
>
> thx,
>
> Jason.
>
> The following changes since commit f8b94beb7e6a374cb0de531b72377c49857b35ca:
>
> i2c: mv64xxx: Document the newly introduced Armada XP A0 compatible (2014-01-14 02:09:17 +0000)
>
> are available in the git repository at:
>
> git://git.infradead.org/linux-mvebu.git tags/mvebu-fixes-3.13-2
>
> for you to fetch changes up to 19e61d41404fe4094c2d54943dbf883d9bbca864:
>
> ARM: mvebu: fix compilation warning on Armada 370 (i.e. non-SMP) (2014-01-21 00:55:47 +0000)
>
> ----------------------------------------------------------------
> mvebu fixes for v3.13 (incremental #2)
>
> - allow building and booting DT and non-DT plat-orion SoCs
> - catch proper return value for kirkwood_pm_init()
> - properly check return of of_iomap to solve boot hangs (mirabox, others)
> - remove a compile warning on Armada 370 with non-SMP.
>
> ----------------------------------------------------------------
Thanks, I've queued these up for v3.14-rc, but they won't show up in any
builds until -rc1 is out.
Kevin
^ permalink raw reply
* [Xen-devel] [PATCH] arm/xen: Initialize event channels earlier
From: Stefano Stabellini @ 2014-01-28 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E7F02A.7010508@linaro.org>
On Tue, 28 Jan 2014, Julien Grall wrote:
> On 01/28/2014 05:46 PM, Stefano Stabellini wrote:
> > On Tue, 28 Jan 2014, Julien Grall wrote:
> >>>> +static int xen_cpu_notification(struct notifier_block *self,
> >>>> + unsigned long action,
> >>>> + void *hcpu)
> >>>> +{
> >>>> + int cpu = (long)hcpu;
> >>>> +
> >>>> + switch (action) {
> >>>> + case CPU_UP_PREPARE:
> >>>> + xen_percpu_init(cpu);
> >>>> + break;
> >>>> + case CPU_STARTING:
> >>>> + xen_interrupt_init();
> >>>> + break;
> >>>
> >>> Is CPU_STARTING guaranteed to be called on the new cpu only?
> >>
> >> Yes.
> >>
> >>> If so, why not call both xen_percpu_init and xen_interrupt_init on
> >>> CPU_STARTING?
> >>
> >> Just in case that xen_vcpu is used somewhere else by a cpu notifier
> >> callback CPU_STARTING. We don't know which callback is called first.
> >
> > Could you please elaborate a bit more on the problem you are trying to
> > describe?
>
> We want to make sure that the vcpu is registered correctly. If not, we
> can't skip it and avoid xen to have a "dead" VCPU to schedule due to BUG_ON.
>
> I agree that now we have a BUG_ON in the middle of xen_percpu_init, but
> it's possible to return an error. In this case Linux will skip this cpu
> and continue to boot.
I think there are no benefits in having two separate functions
(xen_percpu_init and xen_interrupt_init) called at two different points
(CPU_UP_PREPARE and CPU_STARTING).
I would simply have one. Simpler is better.
> >>> As it stands I think you introduced a subtle change (that might be OK
> >>> but I think is unintentional): xen_percpu_init might not be called from
> >>> the same cpu as its target anymore.
> >>
> >> No, xen_percpu_init and xen_interrupt_init are called on the boot cpu at
> >> the end of xen_guest_init.
> >
> > Is CPU_UP_PREPARE guaranteed to be called on the target cpu? I think
> > not, therefore you would be executing xen_percpu_init for cpu1 on cpu0.
> >
>
> I don't see any issue to execute xen_percpu_init for cpu1 on cpu0, all
> the code is taking directly the vcpu ID to initialize.
Me neither, I was simply pointing out that you made this change without
writing it in the commit message (therefore I assume it might be
unintended).
^ permalink raw reply
* [Xen-devel] [PATCH] arm/xen: Initialize event channels earlier
From: Julien Grall @ 2014-01-28 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1401281742080.4373@kaball.uk.xensource.com>
On 01/28/2014 05:46 PM, Stefano Stabellini wrote:
> On Tue, 28 Jan 2014, Julien Grall wrote:
>>>> +static int xen_cpu_notification(struct notifier_block *self,
>>>> + unsigned long action,
>>>> + void *hcpu)
>>>> +{
>>>> + int cpu = (long)hcpu;
>>>> +
>>>> + switch (action) {
>>>> + case CPU_UP_PREPARE:
>>>> + xen_percpu_init(cpu);
>>>> + break;
>>>> + case CPU_STARTING:
>>>> + xen_interrupt_init();
>>>> + break;
>>>
>>> Is CPU_STARTING guaranteed to be called on the new cpu only?
>>
>> Yes.
>>
>>> If so, why not call both xen_percpu_init and xen_interrupt_init on
>>> CPU_STARTING?
>>
>> Just in case that xen_vcpu is used somewhere else by a cpu notifier
>> callback CPU_STARTING. We don't know which callback is called first.
>
> Could you please elaborate a bit more on the problem you are trying to
> describe?
We want to make sure that the vcpu is registered correctly. If not, we
can't skip it and avoid xen to have a "dead" VCPU to schedule due to BUG_ON.
I agree that now we have a BUG_ON in the middle of xen_percpu_init, but
it's possible to return an error. In this case Linux will skip this cpu
and continue to boot.
>>> As it stands I think you introduced a subtle change (that might be OK
>>> but I think is unintentional): xen_percpu_init might not be called from
>>> the same cpu as its target anymore.
>>
>> No, xen_percpu_init and xen_interrupt_init are called on the boot cpu at
>> the end of xen_guest_init.
>
> Is CPU_UP_PREPARE guaranteed to be called on the target cpu? I think
> not, therefore you would be executing xen_percpu_init for cpu1 on cpu0.
>
I don't see any issue to execute xen_percpu_init for cpu1 on cpu0, all
the code is taking directly the vcpu ID to initialize.
--
Julien Grall
^ permalink raw reply
* [PATCH] ARM: multi_v7: add mvebu and drivers to defconfig
From: Jason Cooper @ 2014-01-28 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGa+x86rOYy8CcYr2eVfwvBta4CJN+_mrWFyft=0Hus_E=DXjA@mail.gmail.com>
On Tue, Jan 28, 2014 at 07:59:47AM -0800, Kevin Hilman wrote:
> On Tue, Jan 28, 2014 at 7:39 AM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
> > On 28/01/2014 16:17, Kevin Hilman wrote:
> >> Jason Cooper <jason@lakedaemon.net> writes:
> >>
> >>> boot farms testing is highlighting some errors in mvebu. Let's get some
> >>> more coverage for multi_v7_defconfig kernels.
> >>>
> >>> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> >>> ---
> >>> Kevin,
> >>>
> >>> This is against tonight's master. Feel free to take it directly.
> >>>
> >>
> >> OK, but this one doesn't currently fix any known errors, right? (the
> >> pull request you sent yesterday fixes the boot regressions, IIUC.) The
> >> goal here is just to get more mvebu coverage in multi_v7_defconfig,
> >> correct?
> >>
> >> That being said, have a closer look at the Kconfig entries that are
> >> removed by the patch below, many of which will have an impact on other
> >> platforms.
> >
> > Hi Kevin,
> >
> > I may be wrong but I suspect this config file was generated with make savedefconfig.
> > this rule only generate the CONFIG that are not implied by other CONFIG,
> > so I wonder if all this changes are just due to of modificatino in the Kconfig
> > themselves.
>
> Yes, I suspect that as well, which means the changelog needs to have a
> bit more detail justifying those removals that look suspicious when
> just looking through the diff.
Agreed. I was debating doing two patches, but thought it would be
overkill. I'll resend a v2 as two patches. I'm also going to put it on
mvebu/defconfig branch so that I can also build and test against it
throughout the merge window.
thx,
Jason.
^ permalink raw reply
* [PATCH] arm64: setup: report non-optional CPU features
From: Alexander Van Brunt @ 2014-01-28 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140128172253.GD24617@arm.com>
There are a large number of Android applications that read "/proc/cpuinfo" to determine what CPU features are available. These applications are delivered as binaries and cannot be easily recompiled. Another example of code is the Android NDK framework. It will separately read "/proc/cpuinfo" and parse the "Features" list to get the list of CPU features.
Are there other architectures that report different information in "/proc/cpuinfo" depending on the personality? x86 doesn't. The problem I have with making this conditional on the personality is that CPU's "Features" list should be listing the features of the CPU not the features of the kernel mode. For example, the CPU does have the "thumb" feature even if the personality doesn't use it.
-----Original Message-----
From: Catalin Marinas [mailto:catalin.marinas at arm.com]
Sent: Tuesday, January 28, 2014 9:23 AM
To: Alexander Van Brunt
Cc: Will Deacon; Linux ARM Kernel
Subject: Re: [PATCH] arm64: setup: report non-optional CPU features
On Tue, Jan 28, 2014 at 01:23:41AM +0000, Alex Van Brunt wrote:
> There are a large number of popular applications compiled for ARMv7-A
> that read /proc/cpuinfo to find out what features the CPU has.
ELF_HWCAP should work fine. Which popular applications are these?
> But, when they are run
> on an arm64 kernel, they fail to run. This is because features that
> were optional on ARMv7 or earlier but are not optional on ARMv8-A like
> Thumb are not listed as a CPU feature using the arm64 kernel. To make
> those applications run, the kernel still needs to print the features in the list.
>
> This patch changes "cat /proc/cpuinfo" from printing:
>
> Features : fp asimd
>
> To printing:
>
> Features : fp asimd wp half thumb fastmult vfp edsp neon vfpv3d16 tlsi vfpv4 idiva idivt
That's not correct, the features reported are for the AArch64 mode, it doesn't make sense to overlap the AArch32 features here. There is COMPAT_ELF_HWCAP and the bits should be passed correctly to AArch32 binaries.
A solution would be to add a check for personality(current->personality) == PER_LINUX32 and report cpuinfo in an AArch32 compatible way and based on COMPAT_ELF_HWCAP.
--
Catalin
^ 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