MIPS INTRNG changes

[Mori Hiroki]

Hi

Work fine this patch.

I checked this.

Corega CG-WLCVR54AG AR5312 
Nec WR1200 AR5315

Thanks

Hiroki Mori


----- Original Message -----
> From: Mori Hiroki <yamori813 at yahoo.co.jp>
> To: Landon J Fuller <landonf at freebsd.org>; "freebsd-mips at freebsd.org" <freebsd-mips at freebsd.org>
> Cc: 
> Date: 2017/11/15, Wed 23:23
> Subject: Re: MIPS INTRNG changes
> 
> Hi
> 
> sys/mips/atheros/ar531x/ is non-FDT and INTERNG.
> 
> I will check this patch on real cpu tomorrow.
> 
> Hiroki Mori 
> 
> 
> ----- Original Message -----
>>  From: Landon J Fuller <landonf at freebsd.org>
>>  To: freebsd-mips at freebsd.org
>>  Cc: 
>>  Date: 2017/11/15, Wed 07:50
>>  Subject: MIPS INTRNG changes
>> 
>>  Howdy -
>> 
>>  To support nested INTRNG interrupt controllers on non-FDT MIPS targets, 
> I've
>>  implemented a replacement for the cpu_establish_[hard|soft]intr() 
> workaround
>>  introduced in r305527 (D7692); I'll be commiting this in three days 
> unless
>>  anyone objects:
>> 
>>  https://reviews.freebsd.org/D12385
>> 
>>  Background:
>> 
>>  Since non-FDT INTRNG targets do not have an equivalent to 
> OFW_BUS_MAP_INTR(),
>>  it is necessary for the MIPS nexus driver to implicitly establish INTRNG
>>  interrupt mappings on behalf of child devices.
>> 
>>  The workaround introduced in r305527 implements this as follows, on non-FDT
>>  INTRNG MIPS targets:
>> 
>>  - mips/nexus.c assumes that all bus interrupt requests are for a MIPS
>>    interrupt managed by mips/mips_pic.c
>>  - Call mips_pic's cpu_create_intr_map() from nexus_activate_resource() 
> to
>>    allocate a new interrupt mapping on-demand.
>>  - Call mips_pic's cpu_get_irq_resource() from nexus_setup_intr() to 
> fetch a
>>    shared IRQ struct resource for the MIPS interrupt.
>> 
>>  In addition to assuming that all IRQs are owned by mips_pic, on-demand IRQ
>>  mapping in the BUS_ACTIVATE_RESOURCE() path produces some unexpected 
> behavior:
>> 
>>  - Any child bus that uses bus_generic_rl_alloc_resource() or 
>>  resource_list_alloc()
>>  to implement BUS_ALLOC_RESOURCE() will update the child device's 
> resource
>>  list entry to reference the newly mapped IRQ -- but only if the resource is
>>  allocated with the RF_ACTIVE flag, resulting in BUS_ACTIVATE_RESOURCE() 
> being
>>  called from BUS_ALLOC_RESOURCE() before the resource_list_entry update is
>>  performed.
>>  - BUS_ACTIVATE_RESOURCE() is itself not resource_list-aware; if RF_ACTIVE 
> is
>>  not set during allocation, and bus_activate_resource() is instead called
>>  directly, the child's resource list entry will _not_ updated to the 
> newly
>>  mapped IRQ.
>> 
>>  Since the resource_list_entry _may_ be updated to reference the IRQ 
> mapping, 
>>  IRQs
>>  mappings implicitly created in nexus_activate_resource() cannot be 
> implicitly
>>  unmapped in nexus_deactivate_resource() and must be leaked, as references 
> to
>>  the mapping may remain in a child's resource_list_entry.
>> 
>>  Rather than performing on-demand mapping during resource activation, my 
> changes
>>  preemptively produce (on non-FDT targets) a set of IRQ mappings for all 
> MIPS
>>  IRQs in nexus_attach(), using a fixed range of INTRNG IRQ assignments (0-7) 
> that
>>  may be statically referenced by child devices.
>> 
>>  With D12385, the mips nexus behavior will now be:
>> 
>>  - On non-FDT MIPS INTRNG targets, produce a set of fixed MIPS IRQ mappings
>>    in nexus_attach() for the MIPS IRQ range.
>>  - On all MIPS INTRNG targets, call mips_pic_activate_intr() from
>>    nexus_activate_resource() to perform activation; this will either perform
>>    mips_pic-specific activation if the IRQ is found in mips_pic' table 
> of
>>    MIPS IRQ mappings, or will call intr_activate_irq() for IRQs not managed 
> by
>>    mips_pic (e.g. IRQs mapped by a child PIC).
>>  - On all MIPS INTRNG targets, call mips_pic_deactivate_intr() from
>>    nexus_deactivate_resource(); this will either perform mips_pic-specific
>>    deactivation, or call intr_deactivate_irq() for IRQs not managed by
>>    mips_pic.
>> 
>>  Cheers,
>>  Landon
>> 
>>  _______________________________________________
>>  freebsd-mips at freebsd.org mailing list
>>  https://lists.freebsd.org/mailman/listinfo/freebsd-mips
>>  To unsubscribe, send any mail to 
>>  "freebsd-mips-unsubscribe at freebsd.org"
>> 
> _______________________________________________
> freebsd-mips at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-mips
> To unsubscribe, send any mail to 
> "freebsd-mips-unsubscribe at freebsd.org"
>