Re: [PATCH 18/19] x86, io_apic: Introduce eoi_ioapic_pin call-back
On Sun, Aug 26, 2012 at 08:52:33PM +0200, Sebastian Andrzej Siewior wrote: > Basically you shuffle the code from up there, down there and call from behind > a function pointer. There are two things different this time: > - no version check >= 0x20 > I belive this is obsolete since this runs only on x86-64 with x(2)apic > support and assumes more or less version 0x20+ or we wouldn't be here at > all. Right, all systems that have interrupt remapping have an io-apic version of 0x20 or higher. > - the irq_remapped(cfg) check is gone. The cfg thing is per-interrupt basis > created so you _now_ you act like the interrupt is remapped even if it is > not. Or am I wrong here? That comes from the fact that with the current implementation (with and without my patches) IO-APIC interrupts are always remapped. So it is safe to remove that check. > > + > New line and the end? Why would that be? Coding leftover, I'll remove that. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/19] x86, io_apic: Introduce eoi_ioapic_pin call-back
On Sun, Aug 26, 2012 at 08:52:33PM +0200, Sebastian Andrzej Siewior wrote: Basically you shuffle the code from up there, down there and call from behind a function pointer. There are two things different this time: - no version check = 0x20 I belive this is obsolete since this runs only on x86-64 with x(2)apic support and assumes more or less version 0x20+ or we wouldn't be here at all. Right, all systems that have interrupt remapping have an io-apic version of 0x20 or higher. - the irq_remapped(cfg) check is gone. The cfg thing is per-interrupt basis created so you _now_ you act like the interrupt is remapped even if it is not. Or am I wrong here? That comes from the fact that with the current implementation (with and without my patches) IO-APIC interrupts are always remapped. So it is safe to remove that check. + New line and the end? Why would that be? Coding leftover, I'll remove that. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/19] x86, io_apic: Introduce eoi_ioapic_pin call-back
On Mon, Aug 20, 2012 at 03:56:04PM +0200, Joerg Roedel wrote:
> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
> index aac3f62..d4db390 100644
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -557,19 +557,10 @@ static void unmask_ioapic_irq(struct irq_data *data)
> * Otherwise, we simulate the EOI message manually by changing the trigger
> * mode to edge and then back to level, with RTE being masked during this.
> */
> -static void __eoi_ioapic_pin(int apic, int pin, int vector, struct irq_cfg
> *cfg)
> +void native_eoi_ioapic_pin(int apic, int pin, int vector)
> {
> if (mpc_ioapic_ver(apic) >= 0x20) {
> - /*
> - * Intr-remapping uses pin number as the virtual vector
> - * in the RTE. Actual vector is programmed in
> - * intr-remapping table entry. Hence for the io-apic
> - * EOI we use the pin number.
> - */
> - if (cfg && irq_remapped(cfg))
> - io_apic_eoi(apic, pin);
> - else
> - io_apic_eoi(apic, vector);
> + io_apic_eoi(apic, vector);
> } else {
> struct IO_APIC_route_entry entry, entry1;
>
> diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
> index e61a174..d62e757 100644
> --- a/drivers/iommu/irq_remapping.c
> +++ b/drivers/iommu/irq_remapping.c
> @@ -94,12 +94,24 @@ static void __init irq_remapping_setup_timer_pin(unsigned
> int ioapic_idx,
> /* Not needed with interrupt remapping */
> }
>
> +void eoi_ioapic_pin_remapped(int apic, int pin, int vector)
> +{
> + /*
> + * Intr-remapping uses pin number as the virtual vector
> + * in the RTE. Actual vector is programmed in
> + * intr-remapping table entry. Hence for the io-apic
> + * EOI we use the pin number.
> + */
> + io_apic_eoi(apic, pin);
> +}
> +
Basically you shuffle the code from up there, down there and call from behind
a function pointer. There are two things different this time:
- no version check >= 0x20
I belive this is obsolete since this runs only on x86-64 with x(2)apic
support and assumes more or less version 0x20+ or we wouldn't be here at
all.
- the irq_remapped(cfg) check is gone. The cfg thing is per-interrupt basis
created so you _now_ you act like the interrupt is remapped even if it is
not. Or am I wrong here?
> @@ -316,3 +328,4 @@ bool setup_remapped_irq(int irq, struct irq_cfg *cfg,
> struct irq_chip *chip)
> return false;
> }
> }
> +
New line and the end? Why would that be?
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/19] x86, io_apic: Introduce eoi_ioapic_pin call-back
On Mon, Aug 20, 2012 at 03:56:04PM +0200, Joerg Roedel wrote:
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index aac3f62..d4db390 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -557,19 +557,10 @@ static void unmask_ioapic_irq(struct irq_data *data)
* Otherwise, we simulate the EOI message manually by changing the trigger
* mode to edge and then back to level, with RTE being masked during this.
*/
-static void __eoi_ioapic_pin(int apic, int pin, int vector, struct irq_cfg
*cfg)
+void native_eoi_ioapic_pin(int apic, int pin, int vector)
{
if (mpc_ioapic_ver(apic) = 0x20) {
- /*
- * Intr-remapping uses pin number as the virtual vector
- * in the RTE. Actual vector is programmed in
- * intr-remapping table entry. Hence for the io-apic
- * EOI we use the pin number.
- */
- if (cfg irq_remapped(cfg))
- io_apic_eoi(apic, pin);
- else
- io_apic_eoi(apic, vector);
+ io_apic_eoi(apic, vector);
} else {
struct IO_APIC_route_entry entry, entry1;
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index e61a174..d62e757 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -94,12 +94,24 @@ static void __init irq_remapping_setup_timer_pin(unsigned
int ioapic_idx,
/* Not needed with interrupt remapping */
}
+void eoi_ioapic_pin_remapped(int apic, int pin, int vector)
+{
+ /*
+ * Intr-remapping uses pin number as the virtual vector
+ * in the RTE. Actual vector is programmed in
+ * intr-remapping table entry. Hence for the io-apic
+ * EOI we use the pin number.
+ */
+ io_apic_eoi(apic, pin);
+}
+
Basically you shuffle the code from up there, down there and call from behind
a function pointer. There are two things different this time:
- no version check = 0x20
I belive this is obsolete since this runs only on x86-64 with x(2)apic
support and assumes more or less version 0x20+ or we wouldn't be here at
all.
- the irq_remapped(cfg) check is gone. The cfg thing is per-interrupt basis
created so you _now_ you act like the interrupt is remapped even if it is
not. Or am I wrong here?
@@ -316,3 +328,4 @@ bool setup_remapped_irq(int irq, struct irq_cfg *cfg,
struct irq_chip *chip)
return false;
}
}
+
New line and the end? Why would that be?
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
