Search Linux Wireless

Re: [PATCH 2/6] bcma: mips: explicit assign IRQ numbers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Great, Ive used "Reply" instead of "Reply to all"... :/

2013/1/6 Hauke Mehrtens <hauke@xxxxxxxxxx>:
> On 01/04/2013 08:43 AM, Rafał Miłecki wrote:
>> 2013/1/4 Hauke Mehrtens <hauke@xxxxxxxxxx>:
>>> The assignment of the IRQs to the cores of the chips by iterating over
>>> the cores is complicated and causes problems with SoC like the BCM4706
>>> with two GMAC core where just one should get a dedicated IRQ number.
>>
>> Well, the only problem on BCM4706 is that second (broken/dangling)
>> GMAC core gets it's own IRQ. With such a "waste" of one IRQ line we
>> may end up using shared IRQ for some other core like PCIE/USB.
>> This issue can be simply workarounded (with 2 LOC) and sounds sane:
>> bug in HW, specific workaround in a driver. We already have similar
>> workarounds for other "dangling" cores.
>>
>> I don't know about any other issues with BCM4706 IRQs.
>>
>> Are there any other (more serious?) issues on different SoCs? Any
>> advantages of hardcoding IRQs (per chipset) rather than keeping this
>> simple algorithm? Do the IRQ lines differ? Is this somehow better to
>> use (just an example) IRQ 3 instead of IRQ 4 for GMAC core?
>
> Normally the boot loader (CFE) assigns IRQs to the cores on the bus. The
> old code mostly worked because CFE did it correct most of the time.
>
> On my bcm4718 the I2S core (id 0x834) does not get any IRQ from CFE, but
> at least Nathan (nlhintz) wants to assign an IRQ (shared) to this core.

So can we simply resolve this by
> default:
> bcma_core_mips_set_irq(core, mcore->assigned_irqs);
?


> It is also possible to extend the algorithm to solve all these things,
> but I think the new code is better to understand.
>
> I do not think that there will be any new SoC using bcma and a mips cpu,
> I haven't seen an announcement for such a SoC at the Broadcom web page,
> just arm based devices, so I assume this list is complete.

I just think we should leave some fallback for other devices... and
that probably means the algorithm. But if we decide to leave (a fixed)
algorithm there, why to use hadrcoded version at all?

-- 
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux