On Thu, Sep 15, 2016 at 02:39:47PM +0200, Linus Walleij wrote:
> On Wed, Sep 14, 2016 at 5:12 PM, Mika Westerberg
> wrote:
> > On Wed, Sep 14, 2016 at 02:46:01PM +0200, Linus Walleij wrote:
> >> > I'm going to re-read the hardware spec and see if there is anything we
> >> > can do about this. The
On Wed, Sep 14, 2016 at 5:12 PM, Mika Westerberg
wrote:
> On Wed, Sep 14, 2016 at 02:46:01PM +0200, Linus Walleij wrote:
>> > I'm going to re-read the hardware spec and see if there is anything we
>> > can do about this. The newer hardware (Skylake, Broxton) has a bit that
>> > tells the IRQ is ro
On Wed, Sep 14, 2016 at 02:46:01PM +0200, Linus Walleij wrote:
> > I'm going to re-read the hardware spec and see if there is anything we
> > can do about this. The newer hardware (Skylake, Broxton) has a bit that
> > tells the IRQ is routed directly to I/O-APIC but unfortunately Braswell
> > misse
On Wed, Sep 14, 2016 at 10:26 AM, Mika Westerberg
wrote:
> On Tue, Sep 13, 2016 at 10:57:31PM +0200, Linus Walleij wrote:
>> Isn't this (a list of what IRQs are reserved by BIOS) by sheer logic
>> something that ACPI should provide?
>>
>> Or is this one of those "well we could alter ACPI tables b
On Tue, Sep 13, 2016 at 10:57:31PM +0200, Linus Walleij wrote:
> On Tue, Sep 13, 2016 at 2:52 PM, Mika Westerberg
> wrote:
> > [Me]
> >> A-ha! But why are you registering a irqdomain entry for an interrupt
> >> that cannot be used, hm?
> >
> > Unfortunately there is no way to figure out from the h
On Tue, Sep 13, 2016 at 2:52 PM, Mika Westerberg
wrote:
> [Me]
>> A-ha! But why are you registering a irqdomain entry for an interrupt
>> that cannot be used, hm?
>
> Unfortunately there is no way to figure out from the hardware (or
> firmware) whether the interrupt is supposed to be used by the G
On Tue, Sep 13, 2016 at 02:22:25PM +0200, Linus Walleij wrote:
> On Tue, Sep 13, 2016 at 11:33 AM, Mika Westerberg
> wrote:
> > On Tue, Sep 13, 2016 at 11:18:49AM +0200, Linus Walleij wrote:
> >> On Mon, Sep 12, 2016 at 3:11 PM, Mika Westerberg
> >> wrote:
> >> > On Mon, Sep 12, 2016 at 09:04:44P
On Tue, Sep 13, 2016 at 11:33 AM, Mika Westerberg
wrote:
> On Tue, Sep 13, 2016 at 11:18:49AM +0200, Linus Walleij wrote:
>> On Mon, Sep 12, 2016 at 3:11 PM, Mika Westerberg
>> wrote:
>> > On Mon, Sep 12, 2016 at 09:04:44PM +0800, Phidias Chiang wrote:
>> >> On Mon, Sep 12, 2016 at 12:04:01PM +03
On Tue, Sep 13, 2016 at 11:18:49AM +0200, Linus Walleij wrote:
> On Mon, Sep 12, 2016 at 3:11 PM, Mika Westerberg
> wrote:
> > On Mon, Sep 12, 2016 at 09:04:44PM +0800, Phidias Chiang wrote:
> >> On Mon, Sep 12, 2016 at 12:04:01PM +0300, Mika Westerberg wrote:
> >> >
> >> > OK, I see what is going
On Mon, Sep 12, 2016 at 3:11 PM, Mika Westerberg
wrote:
> On Mon, Sep 12, 2016 at 09:04:44PM +0800, Phidias Chiang wrote:
>> On Mon, Sep 12, 2016 at 12:04:01PM +0300, Mika Westerberg wrote:
>> >
>> > OK, I see what is going on now. When I changed handle_simple_irq to
>> > handle_bad_irq, the IRQ c
On Mon, Sep 12, 2016 at 09:04:44PM +0800, Phidias Chiang wrote:
> On Mon, Sep 12, 2016 at 12:04:01PM +0300, Mika Westerberg wrote:
> >
> > OK, I see what is going on now. When I changed handle_simple_irq to
> > handle_bad_irq, the IRQ core in __irq_do_set_handler() thinks the
> > handler is uninst
On Mon, Sep 12, 2016 at 12:04:01PM +0300, Mika Westerberg wrote:
>
> OK, I see what is going on now. When I changed handle_simple_irq to
> handle_bad_irq, the IRQ core in __irq_do_set_handler() thinks the
> handler is uninstalled and masks the line.
>
> If you change handle_bad_irq to handle_simp
On Mon, Sep 12, 2016 at 02:56:56PM +0800, Phidias Chiang wrote:
> On Sun, Sep 11, 2016 at 11:05:06AM +0300, Mika Westerberg wrote:
> > On Fri, Sep 09, 2016 at 11:58:32AM +0300, Mika Westerberg wrote:
> > > On Fri, Sep 09, 2016 at 04:23:58PM +0800, Phidias Chiang wrote:
> > >
> > > Only other place
On Sun, Sep 11, 2016 at 11:05:06AM +0300, Mika Westerberg wrote:
> On Fri, Sep 09, 2016 at 11:58:32AM +0300, Mika Westerberg wrote:
> > On Fri, Sep 09, 2016 at 04:23:58PM +0800, Phidias Chiang wrote:
> >
> > Only other place where we touch INTMASK register is
> > chv_gpio_irq_mask_unmask(). Can yo
On Fri, Sep 09, 2016 at 11:58:32AM +0300, Mika Westerberg wrote:
> On Fri, Sep 09, 2016 at 04:23:58PM +0800, Phidias Chiang wrote:
> > On Fri, Sep 09, 2016 at 09:18:34AM +0300, Mika Westerberg wrote:
> > > On Fri, Sep 09, 2016 at 12:28:43AM +0800, Phidias Chiang wrote:
> > >
> > > Hmm, how can tha
On Fri, Sep 09, 2016 at 04:23:58PM +0800, Phidias Chiang wrote:
> On Fri, Sep 09, 2016 at 09:18:34AM +0300, Mika Westerberg wrote:
> > On Fri, Sep 09, 2016 at 12:28:43AM +0800, Phidias Chiang wrote:
> >
> > Hmm, how can that happen? The patch removes clearing of INTMASK and only
> > other place wh
On Fri, Sep 09, 2016 at 09:18:34AM +0300, Mika Westerberg wrote:
> On Fri, Sep 09, 2016 at 12:28:43AM +0800, Phidias Chiang wrote:
>
> Hmm, how can that happen? The patch removes clearing of INTMASK and only
> other place where it is cleared temporarily is on resume. Can you add
> dev_info() calls
On Fri, Sep 09, 2016 at 12:28:43AM +0800, Phidias Chiang wrote:
> On Thu, Sep 08, 2016 at 01:24:02PM +0300, Mika Westerberg wrote:
> > On Thu, Sep 08, 2016 at 06:13:03PM +0800, Phidias Chiang wrote:
> > > On Thu, Aug 18, 2016 at 04:58:13PM +0300, Mika Westerberg wrote:
> > > > On Thu, Aug 18, 2016
On Thu, Sep 08, 2016 at 01:24:02PM +0300, Mika Westerberg wrote:
> On Thu, Sep 08, 2016 at 06:13:03PM +0800, Phidias Chiang wrote:
> > On Thu, Aug 18, 2016 at 04:58:13PM +0300, Mika Westerberg wrote:
> > > On Thu, Aug 18, 2016 at 03:52:57PM +0200, Anisse Astier wrote:
> > > > On Thu, Aug 18, 2016 a
On Thu, Sep 08, 2016 at 06:13:03PM +0800, Phidias Chiang wrote:
> On Thu, Aug 18, 2016 at 04:58:13PM +0300, Mika Westerberg wrote:
> > On Thu, Aug 18, 2016 at 03:52:57PM +0200, Anisse Astier wrote:
> > > On Thu, Aug 18, 2016 at 2:13 PM, Mika Westerberg
> > > wrote:
> > > > On Wed, Aug 17, 2016 at
On Thu, Aug 18, 2016 at 04:58:13PM +0300, Mika Westerberg wrote:
> On Thu, Aug 18, 2016 at 03:52:57PM +0200, Anisse Astier wrote:
> > On Thu, Aug 18, 2016 at 2:13 PM, Mika Westerberg
> > wrote:
> > > On Wed, Aug 17, 2016 at 03:42:58PM +0200, Anisse Astier wrote:
> > >> pin 25 (GPIO_SUS6) GPIO ctrl
On Thu, Aug 18, 2016 at 03:52:57PM +0200, Anisse Astier wrote:
> On Thu, Aug 18, 2016 at 2:13 PM, Mika Westerberg
> wrote:
> > On Wed, Aug 17, 2016 at 03:42:58PM +0200, Anisse Astier wrote:
> >> pin 25 (GPIO_SUS6) GPIO ctrl0 0xec918201 ctrl1 0x05c1
> >
> > It is this one (GPIO_SUS6).
> >
> > I
On Thu, Aug 18, 2016 at 2:13 PM, Mika Westerberg
wrote:
> On Wed, Aug 17, 2016 at 03:42:58PM +0200, Anisse Astier wrote:
>> pin 25 (GPIO_SUS6) GPIO ctrl0 0xec918201 ctrl1 0x05c1
>
> It is this one (GPIO_SUS6).
>
> I wonder if we can relax the driver so that it only masks pins which are
> not c
On Wed, Aug 17, 2016 at 03:42:58PM +0200, Anisse Astier wrote:
> On Wed, Aug 17, 2016 at 10:13 AM, Mika Westerberg
> wrote:
> > On Tue, Aug 16, 2016 at 06:12:40PM +0200, Anisse Astier wrote:
> >> Hi Mika,
> >>
> >> Did you find a way to fix this issue ? I'm seeing a similar problem on a
> >> lapto
On Wed, Aug 17, 2016 at 10:13 AM, Mika Westerberg
wrote:
> On Tue, Aug 16, 2016 at 06:12:40PM +0200, Anisse Astier wrote:
>> Hi Mika,
>>
>> Did you find a way to fix this issue ? I'm seeing a similar problem on a
>> laptop where this masks the interrupt used for ACPI events (brightness,
>> lid, ba
On Tue, Aug 16, 2016 at 06:12:40PM +0200, Anisse Astier wrote:
> Hi Mika,
>
> On Tue, Jun 2, 2015 at 4:15 PM, Mika Westerberg
> wrote:
> > On Tue, Jun 02, 2015 at 03:53:40PM +0200, Linus Walleij wrote:
> >> On Mon, Jun 1, 2015 at 11:23 AM, Mika Westerberg
> >> wrote:
> >> > On Fri, May 22, 2015
Hi Mika,
On Tue, Jun 2, 2015 at 4:15 PM, Mika Westerberg
wrote:
> On Tue, Jun 02, 2015 at 03:53:40PM +0200, Linus Walleij wrote:
>> On Mon, Jun 1, 2015 at 11:23 AM, Mika Westerberg
>> wrote:
>> > On Fri, May 22, 2015 at 10:56:08AM +0300, Mika Westerberg wrote:
>> >> BIOS/platform may use some of
On Tue, Jun 02, 2015 at 03:53:40PM +0200, Linus Walleij wrote:
> On Mon, Jun 1, 2015 at 11:23 AM, Mika Westerberg
> wrote:
> > On Fri, May 22, 2015 at 10:56:08AM +0300, Mika Westerberg wrote:
> >> BIOS/platform may use some of the pins by themselves, such as providing SCI
> >> (System Control Inte
On Mon, Jun 1, 2015 at 11:23 AM, Mika Westerberg
wrote:
> On Fri, May 22, 2015 at 10:56:08AM +0300, Mika Westerberg wrote:
>> BIOS/platform may use some of the pins by themselves, such as providing SCI
>> (System Control Interrupt) from the embedded controller. The driver masks
>> all interrupts a
On Fri, May 22, 2015 at 10:56:08AM +0300, Mika Westerberg wrote:
> BIOS/platform may use some of the pins by themselves, such as providing SCI
> (System Control Interrupt) from the embedded controller. The driver masks
> all interrupts at probe time which prevents those pins from triggering
> inter
30 matches
Mail list logo
