Olof Johansson
> Cc: Sascha Hauer
> Cc: Tony Lindgren
> Cc: Viresh Kumar
> Cc: Wan ZongShun
> Signed-off-by: Russell King
Reviewed-by: Thomas Gleixner
Please take this through the ARM tree. It's not conflicting with
anything in my tree.
--
To unsubscribe from thi
acks ASAP. Thanks to Mark for pointing this out with a patch
> for Samsung.
Acked-by: Thomas Gleixner
Sorry for the confusion, that patch should have hit the arm kernel
list two weeks ago, but for whatever reason it did not.
Thanks,
tglx
--
To unsubscribe from this list: send the
On Tue, 13 Dec 2011, Mike Turquette wrote:
> +void __clk_unprepare(struct clk *clk)
> +{
> + if (!clk)
> + return;
> +
> + if (WARN_ON(clk->prepare_count == 0))
> + return;
> +
> + if (--clk->prepare_count > 0)
> + return;
> +
> + WARN_ON(clk->ena
On Tue, 23 Oct 2012, Kevin Hilman wrote:
> Russell King - ARM Linux writes:
>
> > On Tue, Oct 16, 2012 at 03:07:49PM -0700, Kevin Hilman wrote:
> >> From: Thomas Gleixner
> >>
> >> Attempts to retrigger nested threaded IRQs currently fail because they
On Thu, 12 Sep 2013, Sricharan R wrote:
> Signed-off-by: Sricharan R
> ---
> 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 suggestions to
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;
>
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;
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 mor
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 handle
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
> >
> >- CR
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
> >> wrote:
>
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.
> >&
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 DEFINE_RAW_SPINLOCK(irq_controlle
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a m
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.
> >
> > C
Use the proper functions. There is no need to fiddle with irq_desc.
Signed-off-by: Thomas Gleixner
Cc: Shawn Guo
Cc: arm
Cc: omap
Cc: Tony Lindgren
Cc: Russell King
---
arch/arm/mach-imx/pm-imx6q.c|7 +++
arch/arm/mach-omap1/ams-delta-fiq.c |7 ++-
2 files changed
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 |= IRQCHIP_M
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:
> > >
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 t
On Wed, 13 Mar 2013, Santosh Shilimkar wrote:
> On Wednesday 13 March 2013 02:36 PM, Santosh Shilimkar wrote:
> > With recent arm broadcast time clean-up from Mark Rutland, the dummy
> > broadcast device is always registered with timer subsystem. And since
> > the rating of the dummy clock event is
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 y
> Date: Wed, 13 Mar 2013 12:33:16 +0530
> Subject: [PATCH 1/2] ARM: smp: Avoid dummy clockevent being preferred over
> real hardware clock-event
>
> With recent arm broadcast time clean-up from Mark Rutland, the dummy
> broadcast device is always registered with timer subsystem. An
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
> > wrote:
> > > On Tue, 26 Aug 2014, Marc Zyngier wrote:
> > >
&g
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:
> >>
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 mar
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 tim
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.
> >
> > > + */
> > &
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 violat
On Fri, 19 Sep 2014, Tony Lindgren wrote:
> * Thomas Gleixner [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 poi
On Fri, 19 Sep 2014, Tony Lindgren wrote:
> * Thomas Gleixner [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
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? de
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. T
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 unitiali
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)
> >
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 (fu
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, 6 Jul 2015, Tony Lindgren wrote:
> * Thomas Gleixner [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 h
On Mon, 6 Jul 2015, John Stultz wrote:
> On Mon, Jul 6, 2015 at 12:12 AM, 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 clocksou
On Wed, 15 Jul 2015, Tony Lindgren wrote:
> Felipe,
>
> * Tony Lindgren [150119 13:41]:
> > * Felipe Balbi [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
> > > unnecessary
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 me
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 d
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 ca
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 s
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 http://vger.kernel.org/major
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 c
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 affected
On Fri, 13 Nov 2015, Grygorii Strashko wrote:
> Any way, I'll wait for other comments a bit, replace save/restore with
> just pure re-enabling and re-send.
Please folks, trim your emails! I'm really tired of going through
hundreds of quoted (quoting level here was 10!!!) useless lines to
find a
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 such
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 usefu
Felipe,
On Wed, 30 Dec 2015, Felipe Balbi wrote:
> Thomas Gleixner writes:
> > - Is there a "mapping" block between PRUSS and the host interrupt
> > controller
> >or is this "mapping" block part of PRUSS?
>
> The description in TRM i
101 - 156 of 156 matches
Mail list logo
