On Wed, 13 Mar 2013, Santosh Shilimkar wrote:
On Wednesday 13 March 2013 07:49 PM, Thomas Gleixner wrote:
Though making the rating of the dummy lower is definitely a good
thing, so a real hardware device which is detected later can replace
the dummy device. So yes, the rating should be low
the rating of the dummy clockevent so that
real clockevent device is selected when available.
Acked-by: Mark Rutland mark.rutl...@arm.com
Acked-by: Thomas Gleixner t...@linutronix.de
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/kernel/smp.c |2 +-
1 file changed
On Thu, 12 Sep 2013, Sricharan R wrote:
Signed-off-by: Sricharan R r.sricha...@ti.com
---
There is lockdep warning during the boot. This is because we try to
do one request_irq with in another and that results in kmalloc being
called from an atomic context, which generates the warning.
Any
On Thu, 12 Sep 2013, Felipe Balbi wrote:
On Thu, Sep 12, 2013 at 09:09:08PM +0530, Sricharan R wrote:
+unsigned int crossbar_request_irq(struct irq_data *d)
+{
+ int cb_no = d-hwirq;
+ int virq = allocate_free_irq(cb_no);
+ void *irq = cb-crossbar_map[cb_no].hwirq;
+ int err;
On Thu, 12 Sep 2013, Thomas Gleixner wrote:
On Thu, 12 Sep 2013, Felipe Balbi wrote:
On Thu, Sep 12, 2013 at 09:09:08PM +0530, Sricharan R wrote:
+unsigned int crossbar_request_irq(struct irq_data *d)
+{
+ int cb_no = d-hwirq;
+ int virq = allocate_free_irq(cb_no);
+ void *irq
On Thu, 12 Sep 2013, Santosh Shilimkar wrote:
Specifically for the IRQ case addressed here, the cross-bar IP
sits between the interrupt controller and peripheral interrupts.
CPU -- GIC - CROSSBAR - PERIPHERAL IRQs
Just to expand it better, cross-bar input IRQ lines are more than
On Thu, 12 Sep 2013, Santosh Shilimkar wrote:
On Thursday 12 September 2013 06:22 PM, Thomas Gleixner wrote:
Now the real question is, how that expansion mechanism is supposed to
work. There are two possible scenarios:
1) Expand the number of handled interrupts beyond the GIC capacity
On Thu, 12 Sep 2013, Santosh Shilimkar wrote:
On Thursday 12 September 2013 08:26 PM, Thomas Gleixner wrote:
Let me summarize:
- GIC supports up to 160 interrupts
- CROSSBAR supports up to 250 interrupts
- CROSSBAR routes up to 160 out of 250 interrupts to the GIC ones
On Wed, 18 Sep 2013, Sricharan R wrote:
On Wednesday 18 September 2013 07:22 PM, Sricharan R wrote:
Hi Thomas,
On Tuesday 17 September 2013 05:56 PM, Linus Walleij wrote:
On Fri, Sep 13, 2013 at 4:24 PM, Thomas Gleixner t...@linutronix.de
wrote:
So why can't you make use of irq
On Wed, 18 Sep 2013, Santosh Shilimkar wrote:
On Friday 13 September 2013 10:55 AM, Santosh Shilimkar wrote:
On Friday 13 September 2013 10:24 AM, Thomas Gleixner wrote:
[...]
Before you dig into MSI, lets talk about irq domains first.
GIC implements a legacy irq domain, i.e
On Tue, 1 Oct 2013, Rob Herring wrote:
On 10/01/2013 06:13 AM, Sricharan R wrote:
Is there an actual usecase on a single h/w design that you run out of
interrupts and it is a user decision which interrupts to use?
I don't think that matters. What matters is that you have a single DT
entry
On Mon, 30 Sep 2013, Sricharan R wrote:
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 1760ceb..c5778ab 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -72,6 +72,8 @@ struct gic_chip_data {
static
On Mon, 30 Sep 2013, Sricharan R wrote:
+/*
+ * @int_max: maximum number of supported interrupts
+ * @irq_map: array of interrupts to crossbar number mapping
+ * @crossbar_base: crossbar base address
+ * @register_offsets: offsets for each irq number
+ */
+struct crossbar_device {
+
On Wed, 30 Oct 2013, Sricharan R wrote:
@@ -700,11 +709,22 @@ static int gic_irq_domain_xlate(struct irq_domain *d,
*out_hwirq = intspec[1] + 16;
/* For SPIs, we need to add 16 more to get the GIC irq ID number */
- if (!intspec[0])
+ if (!intspec[0]) {
On Wed, 30 Oct 2013, Sricharan R wrote:
+static inline const u32 allocate_free_irq(int cb_no)
I understand the static inline part, but const u32 is more than
fishy. What's wrong with static inline int ?
+{
+ int i;
+
+ for (i = 0; i cb-int_max; i++) {
+ if
On Thu, 14 Nov 2013, Sricharan R wrote:
[V3] Addressed unnecessary warn-on and updated default
xlate function as per Thomas Gleixner comments
Reviewed-by: Thomas Gleixner t...@linutronix.de
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
On Mon, 3 Feb 2014, Sricharan R wrote:
I already have your reviewed-by tag for the first patch in this series.
Kevin was pointing out that irqchip maintainer tag is needed for this patch
as well
to be merged. We are planning to take this series through arm-soc tree.
Can i please
Use the proper functions. There is no need to fiddle with irq_desc.
Signed-off-by: Thomas Gleixner t...@linutronix.de
Cc: Shawn Guo shawn@linaro.org
Cc: arm linux-arm-ker...@lists.infradead.org
Cc: omap linux-omap@vger.kernel.org
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King rmk+ker
On Tue, 3 Jun 2014, Sricharan R wrote:
Please Cc all maintainers on such changes plus the relevant
mailinglist. See MAINTAINERS.
Thanks,
tglx
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Tue, 10 Jun 2014, Brian Norris wrote:
Other random thought: it seems like any irqchip driver which does lazy IRQ
masking ought to use IRQCHIP_MASK_ON_SUSPEND. So maybe the IRQ core should
just
do something like:
if (!chip-irq_disable)
chip-flags |=
On Fri, 13 Jun 2014, Jason Cooper wrote:
On Fri, Jun 13, 2014 at 09:48:24AM -0700, Joe Perches wrote:
On Fri, 2014-06-13 at 12:37 -0400, Jason Cooper wrote:
On Fri, Jun 13, 2014 at 09:14:34AM -0700, Joe Perches wrote:
On Fri, 2014-06-13 at 11:01 -0400, Jason Cooper wrote:
Please
On Tue, 26 Aug 2014, Marc Zyngier wrote:
A number of irqchip drivers are directly calling irq_find_mapping,
which may use a rcu_read_lock call when walking the radix tree.
Turns out that if you hit that point with CONFIG_PROVE_RCU enabled,
the kernel will shout at you, as using RCU in this
On Wed, 3 Sep 2014, Jason Cooper wrote:
On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
Hi Thomas,
On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner
t...@linutronix.de wrote:
On Tue, 26 Aug 2014, Marc Zyngier wrote:
A number of irqchip drivers are directly
On Wed, 3 Sep 2014, Marc Zyngier wrote:
[Dropping li...@openrisc.net from the CC list]
On 03/09/14 13:09, Thomas Gleixner wrote:
On Wed, 3 Sep 2014, Jason Cooper wrote:
On Wed, Aug 27, 2014 at 10:33:44AM +0100, Marc Zyngier wrote:
Hi Thomas,
On Tue, Aug 26 2014 at 10:34:51 pm BST
On Fri, 5 Sep 2014, Nishanth Menon wrote:
+ if (!palmas-wakeirq)
+ goto no_wake_irq;
+
+ ret = devm_request_irq(palmas-dev, palmas-wakeirq,
+palmas_wake_irq,
+IRQF_ONESHOT | pdata-irq_flags,
Why is this marked
On Thu, 18 Sep 2014, Nishanth Menon wrote:
+static irqreturn_t palmas_wake_irq(int irq, void *_palmas)
+{
+ /*
+ * Return Not handled so that interrupt is disabled.
And how is that interrupt disabled by returning IRQ_NONE? You mean it
gets disabled after it got reraised 10 times
On Thu, 18 Sep 2014, Nishanth Menon wrote:
On 17:57-20140918, Thomas Gleixner wrote:
I suppose I can improve the commit message to elaborate this better?
Will that help?
You also want to improve the comment in the empty handler.
+ */
+ return IRQ_NONE;
And it still does
On Fri, 19 Sep 2014, Nishanth Menon wrote:
On 08:37-20140919, Thomas Gleixner wrote:
The other omap drivers using this have the same issue ... And of
course they are subtly different.
The uart one handles the actual device interrupt, which is violating
the general rule of possible
On Fri, 19 Sep 2014, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [140919 10:37]:
From hardware point of view the wake-up events behave like interrupts
and could also be used as the only interrupt in some messed up cases.
That avoids all kinds of custom APIs from driver point
On Fri, 19 Sep 2014, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [140919 12:47]:
Why on earth are you wanting tasklets in there? That's just silly,
really.
Lack of a framework on driver side to cope with this in a generic
way? :p
So instead of creating such a thing we
Tony,
On Thu, 6 Nov 2014, Tony Lindgren wrote:
Any comments on the patch below? Let me know if you want to keep the
devm stuff out of kernel/irq/manage.c.
Sorry, this slipped through the cracks.
+static int setup_wakeirq(struct device *dev, unsigned int wakeirq,
+
On Thu, 13 Nov 2014, Tony Lindgren wrote:
Oops thanks for catching that. As the devres stuff is separate, I've
updated the patch to keep it that way by adding a minimal manage.h.
This avoids including internals.h in devres.c. Does that seem usable
for you?
What's wrong with internals.h?
On Wed, 10 Dec 2014, Joe Perches wrote:
As far as I can tell, there's no value indirecting
the cpu passed to this function via a void *.
Update all the callers and called functions from within
clockevents_notify.
Aside of that there is no value for this 'notification' function at
all. This
On Wed, 20 May 2015, Jiang Liu wrote:
On 2015/5/20 23:28, Thomas Gleixner wrote:
On Wed, 20 May 2015, Jiang Liu wrote:
-static void locomo_handler(unsigned int irq, struct irq_desc *desc)
+static void locomo_handler(struct irq_desc *desc)
{
struct locomo *lchip
On Wed, 20 May 2015, Jiang Liu wrote:
-static void locomo_handler(unsigned int irq, struct irq_desc *desc)
+static void locomo_handler(struct irq_desc *desc)
{
struct locomo *lchip = irq_desc_get_chip_data(desc);
+ unsigned int irq;
int req, i;
That leaves irq unitialized
On Fri, 19 Jun 2015, Kevin Hilman wrote:
On Wed, Jun 17, 2015 at 1:33 AM, Sebastian Andrzej Siewior
A handful of boot test failures on ARM/OMAP were found by kernelci.org
in next-20150619[1] and were bisected down to this patch, which hit
next-20150619 in the form of commit 881bd58d6e9e
On Mon, 6 Jul 2015, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [150706 07:20]:
On Mon, 6 Jul 2015, Tony Lindgren wrote:
The timekeeping accuracy issue certainly needs some thinking, and
also the resolution between the clocksources can be different.. In the
test case I have
On Mon, 6 Jul 2015, John Stultz wrote:
On Mon, Jul 6, 2015 at 12:12 AM, Tony Lindgren t...@atomide.com wrote:
Some persistent clocksources can be on a slow external bus. For shorter
latencies for RT use, let's allow toggling the clocksource during idle
between a faster non-persistent
On Mon, 6 Jul 2015, Tony Lindgren wrote:
Some persistent clocksources can be on a slow external bus. For shorter
latencies for RT use, let's allow toggling the clocksource during idle
between a faster non-persistent runtime clocksource and a slower persistent
clocksource.
I really cannot
On Mon, 27 Jul 2015, Sebastian Andrzej Siewior wrote:
On 07/27/2015 02:50 PM, Linus Walleij wrote:
Patch applied.
thanks.
Now this question appear in my head:
Is drivers/gpio full of stuff that will not work with the -RT kernel,
and is this a change that should be done mutatis
On Mon, 20 Jul 2015, Felipe Balbi wrote:
+ irqnr = intc_readl(INTC_SIR);
+ irqnr = ACTIVEIRQ_MASK;
+ WARN(!irqnr, Spurious IRQ ?\n);
Shouldn't that be WARN_ONCE?
Thanks,
tglx
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
On Wed, 15 Jul 2015, Tony Lindgren wrote:
Felipe,
* Tony Lindgren t...@atomide.com [150119 13:41]:
* Felipe Balbi ba...@ti.com [150102 10:50]:
as it turns out the current IRQ number will
*always* be available from SIR register which
renders the reads of PENDING registers as plain
On Mon, 19 Oct 2015, Sekhar Nori wrote:
> + /*
> + * A spurious IRQ can result if interrupt that triggered the
> + * sorting is no longer active during the sorting (10 INTC
> + * functional clock cycles after interrupt assertion). Or a
> + * change in interrupt mask
Mans,
On Fri, 9 Oct 2015, Mans Rullgard wrote:
> This passes a data pointer specified in the sched_clock_register()
> call to the read callback allowing simpler implementations thereof.
>
> In this patch, existing uses of this interface are simply updated
> with a null pointer.
I can't see any
Grygorii,
can you please provide a patch set against 4.1-RT? That stuff rejects
left and right.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Grygorii,
On Tue, 13 Oct 2015, Grygorii Strashko wrote:
> I'd very appreciate for any advice of how to better proceed with your request.
> - I can try to apply and re-send only patches marked by '*'
> - I can prepare branch with all above patches
Please provide a branch on top of 4.1.10 which
On Tue, 25 Aug 2015, Felipe Balbi wrote:
Hi Ingo,
Thanks for not cc'ing the irq maintainer
I'm facing an issue with CONFIG_DEBUG_SHIRQ and pm_runtime when using
devm_request_*irq().
If we using devm_request_*irq(), that irq will be freed after device
drivers' -remove() gets called.
Felipe,
On Tue, 29 Dec 2015, Felipe Balbi wrote:
> Anyway, the interesting part is that PRUSS has 64 events (on current
> incarnations at least) and PRUSS has 10 physical IRQ lines to the ARM
> land. Each of these 64 events can be routed to any of these 10 IRQ
> lines. This might not be very
Felipe,
On Wed, 30 Dec 2015, Felipe Balbi wrote:
> Thomas Gleixner <t...@linutronix.de> writes:
> > - Is there a "mapping" block between PRUSS and the host interrupt
> > controller
> >or is this "mapping" block part of PRUSS?
>
> The de
On Fri, 20 Nov 2015, John Stultz wrote:
> So its unlikely that the hardware both stays running through suspend,
> but also might halt in idle. That would be "unique".
The amount of creativity put into the next variants of differently
broken timers is amazing. So I wouldn't be too surprised if
101 - 150 of 150 matches
Mail list logo
