Re: [PATCH 1/4] acpi,pci,irq: reduce resource requirements

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

 



On 3/14/2016 5:01 PM, Bjorn Helgaas wrote:
> On Mon, Mar 14, 2016 at 04:37:51PM -0400, Sinan Kaya wrote:
>> Hi Bjorn,
>>
>> On 3/14/2016 2:52 PM, Bjorn Helgaas wrote:
>>>> bool acpi_isa_irq_available(int irq)
>>>>> @@ -840,13 +881,6 @@ bool acpi_isa_irq_available(int irq)
>>>>>   */
>>>>>  void acpi_penalize_sci_irq(int irq, int trigger, int polarity)
>>>>>  {
>>>>> -	if (irq >= 0 && irq < ARRAY_SIZE(acpi_irq_penalty)) {
>>>>> -		if (trigger != ACPI_MADT_TRIGGER_LEVEL ||
>>>>> -		    polarity != ACPI_MADT_POLARITY_ACTIVE_LOW)
>>>>> -			acpi_irq_penalty[irq] += PIRQ_PENALTY_ISA_ALWAYS;
>>>>> -		else
>>>>> -			acpi_irq_penalty[irq] += PIRQ_PENALTY_PCI_USING;
>>>>> -	}
>>> I think we lost the validation of trigger mode and polarity, didn't
>>> we?
>>>
>>
>> This function gets called to inform ACPI that this is the SCI interrupt
>> and, trigger and polarity are their attributes.
>>
>> The return value is void and the caller is not interested in what ACPI thinks
>> about. 
>>
>> This function adjusts the SCI penalty based on correct attributes passed
>> (ISA_ALWAYS vs. PCI_USING).
>>
>> I agree that we lost this validation. 
>>
>> I can keep sci_trigger/sci_polarity somewhere and keep that into the calculation
>> in get function.
>>
>> Like this for instance,
>>
>> 	if (irq == acpi_gbl_FADT.sci_interrupt) {
>> +		if (sci_trigger != ACPI_MADT_TRIGGER_LEVEL ||
>> +		    sci_polarity != ACPI_MADT_POLARITY_ACTIVE_LOW)
>> +			penalty += PIRQ_PENALTY_ISA_ALWAYS;
>> +		else
>> 			penalty += PIRQ_PENALTY_PCI_USING; 
>> 	}
>>
>> Then, we can't get rid of the function just we can reduce the contents.
> 
> I think it's important to keep that check.
> 
> I raised the possibility of using irq_get_trigger_type() for all IRQs
> (not just the SCI).  Did you have a chance to look into that at all?
> 
> Bjorn
> 

Let's take care of SCI first. Is this OK? Would you include IRQ_TYPE_NONE below?

get_penalty
{
...
	if (irq == acpi_gbl_FADT.sci_interrupt) {
		if (irq_get_trigger_type(irq) == IRQ_TYPE_LEVEL_LOW)
			penalty += PIRQ_PENALTY_PCI_USING;
		else
			penalty += PIRQ_PENALTY_ISA_ALWAYS;
	}
}


Yes, I read your email and asked how you would deal with ARM64. There was
silence after that :) ARM64 doesn't have SCI and the PCI interrupts are
active high and level.

I pasted the code here again. It looks like you want to validate that
PCI interrupts are always level low. 

There could be also some other existing Intel platform or architecture 
that quite doesn't encode the interrupt properly.

 
   static int pci_compatible_trigger(int irq)
   {
     int type = irq_get_trigger_type(irq);

     return (type == IRQ_TYPE_LEVEL_LOW || type == IRQ_TYPE_NONE);
   }


   static unsigned int acpi_irq_get_penalty(int irq)
   {
     unsigned int penalty = 0;

     if (irq == acpi_gbl_FADT.sci_interrupt)
       	penalty += PIRQ_PENALTY_PCI_USING;

     penalty += acpi_irq_pci_sharing_penalty(irq);
     return penalty;
   }

   static int acpi_pci_link_allocate(struct acpi_pci_link *link)
   {
     unsigned int best = ~0;
     ...

     for (i = (link->irq.possible_count - 1); i >= 0; i--) {
       candidate = link->irq.possible[i];
       if (!pci_compatible_trigger(candidate))
         continue;

       penalty = acpi_irq_get_penalty(candidate);
       if (penalty < best) {
       	    irq = candidate;
            best = penalty;
       }
     }
   }


Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux