RE: [PATCH] Move PCIe node to correct place
On 05/15/2013 07:55 AM, Jay Agarwal wrote: Moving PCIe controller node to correct place so that it is sorted by register address in .dtsi file Reviewed-by: Stephen Warren swar...@nvidia.com Hi Thierry, If reviews are done, Can you please include this into your repository? -- To unsubscribe from this list: send the line unsubscribe linux-tegra in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] ARM: tegra114: cpuidle: add power down state
This series introduce CPU core power down state for CPU idle. When CPU go into this state, it saves it's context and needs a proper configuration in flow controller to power gate the CPU when CPU runs into WFI instruction. And the CPU also needs to set the IRQ as CPU power down idle wake up event in flow controller. To prevent race conditions and ensure proper interrupt routing on Cortex-A15 CPUs when they are power-gated, add a CPU PM notifier call-back to reprogram the GIC CPU interface on PM entry. The GIC CPU interface will be reset back to its normal state by the common GIC CPU PM exit callback when the CPU wakes up. Joseph Lo (3): ARM: tegra114: Reprogram GIC CPU interface to bypass IRQ on CPU PM entry ARM: tegra114: add low level support for CPU idle powered-down mode ARM: tegra114: cpuidle: add powered-down state arch/arm/mach-tegra/cpuidle-tegra114.c | 62 +- arch/arm/mach-tegra/flowctrl.h | 2 ++ arch/arm/mach-tegra/irq.c | 40 ++ arch/arm/mach-tegra/sleep-tegra30.S| 2 ++ 4 files changed, 105 insertions(+), 1 deletion(-) -- 1.8.3 -- To unsubscribe from this list: send the line unsubscribe linux-tegra in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: tegra114: Reprogram GIC CPU interface to bypass IRQ on CPU PM entry
There is a difference between GICv1 and v2 when CPU in power management
mode (aka CPU power down on Tegra). For GICv1, IRQ/FIQ interrupt lines
going to CPU are same lines which are also used for wake-interrupt.
Therefore, we cannot disable the GIC CPU interface if we need to use same
interrupts for CPU wake purpose. This creates a race condition for CPU
power off entry. Also, in GICv1, disabling GICv1 CPU interface puts GICv1
into bypass mode such that incoming legacy IRQ/FIQ are sent to CPU, which
means disabling GIC CPU interface doesn't really disable IRQ/FIQ to CPU.
GICv2 provides a wake IRQ/FIQ (for wake-event purpose), which are not
disabled by GIC CPU interface. This is done by adding a bypass override
capability when the interrupts are disabled at the CPU interface. To
support this, there are four bits about IRQ/FIQ BypassDisable in CPU
interface Control Register. When the IRQ/FIQ not being driver by the
CPU interface, each interrupt output signal can be deasserted rather
than being driven by the legacy interrupt input.
So the wake-event can be used as wakeup signals to SoC (system power
controller).
To prevent race conditions and ensure proper interrupt routing on
Cortex-A15 CPUs when they are power-gated, add a CPU PM notifier
call-back to reprogram the GIC CPU interface on PM entry. The
GIC CPU interface will be reset back to its normal state by
the common GIC CPU PM exit callback when the CPU wakes up.
Based on the work by: Scott Williams scwilli...@nvidia.com
Signed-off-by: Joseph Lo jose...@nvidia.com
---
arch/arm/mach-tegra/irq.c | 40
1 file changed, 40 insertions(+)
diff --git a/arch/arm/mach-tegra/irq.c b/arch/arm/mach-tegra/irq.c
index 0de4eed..1a74d56 100644
--- a/arch/arm/mach-tegra/irq.c
+++ b/arch/arm/mach-tegra/irq.c
@@ -18,10 +18,12 @@
*/
#include linux/kernel.h
+#include linux/cpu_pm.h
#include linux/interrupt.h
#include linux/irq.h
#include linux/io.h
#include linux/of.h
+#include linux/of_address.h
#include linux/irqchip/arm-gic.h
#include linux/syscore_ops.h
@@ -65,6 +67,7 @@ static u32 cpu_ier[TEGRA_MAX_NUM_ICTLRS];
static u32 cpu_iep[TEGRA_MAX_NUM_ICTLRS];
static u32 ictlr_wake_mask[TEGRA_MAX_NUM_ICTLRS];
+static void __iomem *tegra_gic_cpu_base;
#endif
bool tegra_pending_sgi(void)
@@ -213,8 +216,43 @@ int tegra_legacy_irq_syscore_init(void)
return 0;
}
+
+static int tegra_gic_notifier(struct notifier_block *self,
+ unsigned long cmd, void *v)
+{
+ switch (cmd) {
+ case CPU_PM_ENTER:
+ writel_relaxed(0x1E0, tegra_gic_cpu_base + GIC_CPU_CTRL);
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block tegra_gic_notifier_block = {
+ .notifier_call = tegra_gic_notifier,
+};
+
+static const struct of_device_id tegra114_dt_gic_match[] __initconst = {
+ { .compatible = arm,cortex-a15-gic },
+ { }
+};
+
+static void tegra114_gic_cpu_pm_registration(void)
+{
+ struct device_node *dn;
+
+ dn = of_find_matching_node(NULL, tegra114_dt_gic_match);
+ if (!dn)
+ return;
+
+ tegra_gic_cpu_base = of_iomap(dn, 1);
+
+ cpu_pm_register_notifier(tegra_gic_notifier_block);
+}
#else
#define tegra_set_wake NULL
+static void tegra114_gic_cpu_pm_registration(void) { }
#endif
void __init tegra_init_irq(void)
@@ -252,4 +290,6 @@ void __init tegra_init_irq(void)
if (!of_have_populated_dt())
gic_init(0, 29, distbase,
IO_ADDRESS(TEGRA_ARM_PERIF_BASE + 0x100));
+
+ tegra114_gic_cpu_pm_registration();
}
--
1.8.3
--
To unsubscribe from this list: send the line unsubscribe linux-tegra in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: tegra114: add low level support for CPU idle powered-down mode
The flow controller would take care the power sequence when CPU idle in powered-down mode. It powered gate the CPU when CPU runs into WFI instruction. And wake up the CPU when event be triggered. The sequence is below. * setting wfi bitmap for the CPU as the halt event in the FLOW_CTRL_CPU_HALT_REG to monitor the CPU running into WFI,then power gate it * setting IRQ and FIQ as wake up event to wake up CPU when event triggered Signed-off-by: Joseph Lo jose...@nvidia.com --- arch/arm/mach-tegra/flowctrl.h | 2 ++ arch/arm/mach-tegra/sleep-tegra30.S | 2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/arm/mach-tegra/flowctrl.h b/arch/arm/mach-tegra/flowctrl.h index 7a29bae..e56a950 100644 --- a/arch/arm/mach-tegra/flowctrl.h +++ b/arch/arm/mach-tegra/flowctrl.h @@ -28,6 +28,8 @@ #define FLOW_CTRL_SCLK_RESUME (1 27) #define FLOW_CTRL_HALT_CPU_IRQ (1 10) #defineFLOW_CTRL_HALT_CPU_FIQ (1 8) +#define FLOW_CTRL_HALT_GIC_IRQ (1 9) +#define FLOW_CTRL_HALT_GIC_FIQ (1 8) #define FLOW_CTRL_CPU0_CSR 0x8 #defineFLOW_CTRL_CSR_INTR_FLAG (1 15) #define FLOW_CTRL_CSR_EVENT_FLAG (1 14) diff --git a/arch/arm/mach-tegra/sleep-tegra30.S b/arch/arm/mach-tegra/sleep-tegra30.S index ada8821..5877f26 100644 --- a/arch/arm/mach-tegra/sleep-tegra30.S +++ b/arch/arm/mach-tegra/sleep-tegra30.S @@ -99,6 +99,8 @@ flow_ctrl_setting_for_lp2: cmp r10, #TEGRA30 moveq r3, #FLOW_CTRL_WAIT_FOR_INTERRUPT @ For LP2 movne r3, #FLOW_CTRL_WAITEVENT + orrne r3, r3, #FLOW_CTRL_HALT_GIC_IRQ + orrne r3, r3, #FLOW_CTRL_HALT_GIC_FIQ flow_ctrl_done: cmp r10, #TEGRA30 str r3, [r2] -- 1.8.3 -- To unsubscribe from this list: send the line unsubscribe linux-tegra in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: tegra114: cpuidle: add powered-down state
On 05/30/2013 01:19 PM, Joseph Lo wrote:
This supports CPU core power down on each CPU when CPU idle. When CPU go
into this state, it saves it's context and needs a proper configuration
in flow controller to power gate the CPU when CPU runs into WFI
instruction. And the CPU also needs to set the IRQ as CPU power down idle
wake up event in flow controller.
Signed-off-by: Joseph Lo jose...@nvidia.com
---
Hi Joseph,
a new flag has been added in the cpuidle framework to let this one to
handle the timer broadcast : CPUIDLE_FLAG_TIMER_STOP
It is the commit b60e6a0eb0273132cbb60a9806abf5f47a4aee1c
You can get rid of the clockevent notify stuff by adding this flag to
the state.
Also, can you clarify why tegra3 code is used in tegra114 ?
arch/arm/mach-tegra/cpuidle-tegra114.c | 62
+-
1 file changed, 61 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c
b/arch/arm/mach-tegra/cpuidle-tegra114.c
index 1d1c602..e7d21f5 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra114.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
@@ -17,19 +17,79 @@
#include linux/kernel.h
#include linux/module.h
#include linux/cpuidle.h
+#include linux/cpu_pm.h
+#include linux/clockchips.h
#include asm/cpuidle.h
+#include asm/suspend.h
+#include asm/smp_plat.h
+
+#include pm.h
+#include sleep.h
+
+#ifdef CONFIG_PM_SLEEP
+static int tegra114_idle_power_down(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index);
Isn't possible to move the driver declaration after the
tegra114_idle_power_down function, before the init function, so we
prevent a forward declaration ?
+#define TEGRA114_MAX_STATES 2
+#else
+#define TEGRA114_MAX_STATES 1
+#endif
static struct cpuidle_driver tegra_idle_driver = {
.name = tegra_idle,
.owner = THIS_MODULE,
- .state_count = 1,
+ .state_count = TEGRA114_MAX_STATES,
.states = {
[0] = ARM_CPUIDLE_WFI_STATE_PWR(600),
+#ifdef CONFIG_PM_SLEEP
+ [1] = {
+ .enter = tegra114_idle_power_down,
+ .exit_latency = 500,
+ .target_residency = 1000,
+ .power_usage= 0,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = powered-down,
+ .desc = CPU power gated,
+ },
+#endif
},
};
+#ifdef CONFIG_PM_SLEEP
+static int tegra114_idle_power_down(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ u32 cpu = is_smp() ? cpu_logical_map(dev-cpu) : dev-cpu;
IMO, it is up to the tegra_set_cpu_in_lp2 / tegra_clear_cpu_in_lp2
functions to do the cpu map conversion instead of adding this into a
routine working with logical cpu.
+ local_fiq_disable();
+
+ tegra_set_cpu_in_lp2(cpu);
+ cpu_pm_enter();
+
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev-cpu);
+ smp_wmb();
Why do you need a memory barrier here ?
+ cpu_suspend(0, tegra30_sleep_cpu_secondary_finish);
+
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev-cpu);
+
+ cpu_pm_exit();
+ tegra_clear_cpu_in_lp2(cpu);
+
+ local_fiq_enable();
+
+ smp_rmb();
Why do you need a memory barrier here ?
+ return index;
+}
+#endif
+
int __init tegra114_cpuidle_init(void)
{
+#ifdef CONFIG_PM_SLEEP
+ tegra_tear_down_cpu = tegra30_tear_down_cpu;
+#endif
Doesn't this code should go in the pm.c file ?
return cpuidle_register(tegra_idle_driver, NULL);
}
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
--
To unsubscribe from this list: send the line unsubscribe linux-tegra in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe linux-tegra -- To unsubscribe from this list: send the line unsubscribe linux-tegra in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/4] ARM: tegra: pcie: Enable PCIe controller on Cardhu
On 05/29/2013 04:10 AM, Jay Agarwal wrote: So, if I apply this series, I do see the PCIe bridge and Ethernet device get enumerated, but I don't see the USB3 controller get enumerated. I believe that is a PCIe device behind the same bridge on the same Tegra PCIe port. Shouldn't this device show up? I have also reproduced this problem. I see somehow no non- prefetchable memory is assigned to any of pcie devices. Probably that is the reason for USB3 (pci :04:00.0) not getting enumerated since it uses only non-prefetchable memory. 1. Bus4(on which usb3 device resides) always return 0x from it's config space. which means device is not present? 2. That's why it is not assigned any resources and hence no usb3 probe happens. 3. But same bus does return valid info like vendor/device id etc from it's config space in downstream kernel and hence usb3 probe does happen. Thierry, Stephen, 4. Any idea why bus4 should return 0x values in upstream kernel? Anything missing? 5. Also, how config space of all pcie devices are mapped? I mean if I change the config space offset in dts file, then also I find correct vendor/device id etc for bus0/device0/fun0. So how this mapping happens that even after changing the config space offset in PCIe address space, it always finds correct vendor/device id. Any idea on this? I did already reply the same day you sent the original email. My response was: Is there some reset/enable GPIO or regulator that needs to be programmed to enable the PCIe USB3 controller? Take a look at the schematic. If you can make it work by tweaking those GPIOs/... manually, then we can ignore this issue and fix it up later, since it's not directly related to the PCIe controller driver patches. It's more important to get the Ethernet working than USB, I think. To be honest though, I would expect you to be asking around inside NVIDIA to determine the answer here. As the PCIe SW expert, I'd expect you to drive this process. Try asking the Cardhu board and PCIe HW experts within NVIDIA. Did you make any progress on the issues with the Ethernet device? Stephen, I have taken care of all your comments, but Ethernet device is not working for me neither on cardhu nor harmony. Could be related to my process or board, Currently debugging this. Parallely, should I push my patches for review so that it is clear from other aspects? -- To unsubscribe from this list: send the line unsubscribe linux-tegra in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: tegra: pcie: Enable PCIe controller on Cardhu
On 05/30/2013 11:37 AM, Jay Agarwal wrote: ... I have taken care of all your comments, but Ethernet device is not working for me neither on cardhu nor harmony. Could be related to my process or board, Currently debugging this. Are you talking about a PCIe-based Ethernet device on Harmony, or the one that's built into the board? The on-board Ethernet device is USB, and should work fine already, and irrespective of any PCIe patches. I have only tried an XHCI USB controller in the PCIe slot on Harmony, so I can't say if Ethernet not working is a regression or not. Does the Ethernet device work with just Thierry's patches and not yours? Parallely, should I push my patches for review so that it is clear from other aspects? Well, if the patches don't work, I suppose there's not much use posting them since they'll just need changes before they can be usefully applied anyway. IIRC, most of my comments last time were fairly minor, so there isn't much need for a separate review of them, right? -- To unsubscribe from this list: send the line unsubscribe linux-tegra in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] dma: various minor clean ups for slave drivers
On Mon, May 27, 2013 at 03:14:30PM +0300, Andy Shevchenko wrote: Here is a set of small independent patches that clean up or fix minor things across DMA slave drivers. The series looks fine. I am going to wait a day more and apply, pls speak up if you disagree and ack if you agree -- ~Vinod Andy Shevchenko (12): imx-sdma: remove useless variable mxs-dma: remove useless variable edma: no need to assign residue to 0 explicitly ep93xx_dma: remove useless use of lock fsldma: remove useless use of lock mmp_pdma: remove useless use of lock mpc512x_dma: remove useless use of lock pch_dma: remove useless use of lock tegra20-apb-dma: remove useless use of lock ipu_idmac: re-use dma_cookie_status() mmp_tdma: set cookies as well when asked for tx status txx9dmac: return DMA_SUCCESS immediately from device_tx_status() drivers/dma/edma.c| 2 -- drivers/dma/ep93xx_dma.c | 10 +- drivers/dma/fsldma.c | 10 +- drivers/dma/imx-sdma.c| 9 +++-- drivers/dma/ipu/ipu_idmac.c | 5 + drivers/dma/mmp_pdma.c| 10 +- drivers/dma/mmp_tdma.c| 3 ++- drivers/dma/mpc512x_dma.c | 10 +- drivers/dma/mxs-dma.c | 4 +--- drivers/dma/pch_dma.c | 9 + drivers/dma/tegra20-apb-dma.c | 8 +++- drivers/dma/txx9dmac.c| 13 ++--- 12 files changed, 21 insertions(+), 72 deletions(-) -- 1.8.2.rc0.22.gb3600c3 -- -- To unsubscribe from this list: send the line unsubscribe linux-tegra in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] dma: various minor clean ups for slave drivers
On Thu, May 30, 2013 at 8:47 PM, Vinod Koul vinod.k...@intel.com wrote: On Mon, May 27, 2013 at 03:14:30PM +0300, Andy Shevchenko wrote: Here is a set of small independent patches that clean up or fix minor things across DMA slave drivers. The series looks fine. I am going to wait a day more and apply, pls speak up if you disagree and ack if you agree I'm not in hurry with it. Please, take your time and do whatever it requires. Thank you! -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line unsubscribe linux-tegra in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] dma: tegra20-apbdma: err message correction
On Mon, May 13, 2013 at 09:34:05AM +0530, Laxman Dewangan wrote: On Saturday 11 May 2013 10:00 PM, Dmitry Osipenko wrote: Fixed err msg params order on irq request fail. Signed-off-by: Dmitry Osipenko dig...@gmail.com Acked-by: Stephen Warren swar...@nvidia.com --- Looks good to me for both series. Acked-by: Laxman Dewangan ldewangannvidia.com @missing here :) -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-tegra in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] dma: tegra: avoid channel lock up after free
On Mon, May 13, 2013 at 10:20:36AM -0600, Stephen Warren wrote: On 05/11/2013 10:30 AM, Dmitry Osipenko wrote: Lock scenario: Channel 1 was allocated and prepared as slave_sg, used and freed. Now preparation of cyclic dma on channel 1 will fail with err DMA configuration conflict because tdc-isr_handler still setted to handle_once_dma_done. This happens because tegra_dma_abort_all() won't be called on channel freeing if pending list is empty and channel not busy. We need to clear isr_handler on channel freeing to avoid locking. ... Reposting with dma maintainers cc'd as suggested by Stephen. Added Stephen's ack. Applied, both thanks Just for reference (not need to repost again): You'd usually send the messages *to* the DMA maintainers since they will be taking the patches through their tree, and then Ccing anyone else. get_maintainer.pl is your friend for this -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-tegra in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
