[PATCH] Better timer and RTC handling for 8641HPCN.

[PATCH] Better timer and RTC handling for 8641HPCN.

[Jon Loeliger]

From: Zhang Wei <wei.zhang@freescale.com>

Give more IRQ numbers for MPIC IPIs and TIMERs use.
Added generic RTC support for MPC8641HPCN.

Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index f42f801..5ef6d61 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -28,7 +28,7 @@
 #include <mm/mmu_decl.h>
 #include <asm/udbg.h>
 #include <asm/i8259.h>
-
+#include <asm-generic/rtc.h>
 #include <asm/mpic.h>
 
 #include <sysdev/fsl_soc.h>
@@ -81,7 +81,7 @@ mpc86xx_hpcn_init_irq(void)
 	/* Alloc mpic structure and per isu has 16 INT entries. */
 	mpic1 = mpic_alloc(np, res.start,
 			MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
-			16, NR_IRQS - 4,
+			16, NR_IRQS - 10,
 			" MPIC     ");
 	BUG_ON(mpic1 == NULL);
 
@@ -452,4 +452,10 @@ define_machine(mpc86xx_hpcn) {
 	.time_init		= mpc86xx_time_init,
 	.calibrate_decr		= generic_calibrate_decr,
 	.progress		= udbg_progress,
+
+#ifdef CONFIG_GEN_RTC
+	/* RTC interface, using functions in include/asm-generic/rtc.h */
+	.get_rtc_time		= get_rtc_time,
+	.set_rtc_time		= set_rtc_time,
+#endif
 };
-- 
1.5.0.1.213.g509b

Re: [PATCH] Better timer and RTC handling for 8641HPCN.

[Kumar Gala]

On Mar 7, 2007, at 12:49 PM, Jon Loeliger wrote:

> From: Zhang Wei <wei.zhang@freescale.com>
>
> Give more IRQ numbers for MPIC IPIs and TIMERs use.
> Added generic RTC support for MPC8641HPCN.
>
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>

Nack.

You can't call the generic set_rtc_time from the  
ppc_md.set_rtc_time.  Take a look at:

http://ozlabs.org/pipermail/linuxppc-dev/2007-January/030440.html

- k

> ---
>  arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |   10 ++++++++--
>  1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/ 
> powerpc/platforms/86xx/mpc86xx_hpcn.c
> index f42f801..5ef6d61 100644
> --- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> +++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
> @@ -28,7 +28,7 @@
>  #include <mm/mmu_decl.h>
>  #include <asm/udbg.h>
>  #include <asm/i8259.h>
> -
> +#include <asm-generic/rtc.h>
>  #include <asm/mpic.h>
>
>  #include <sysdev/fsl_soc.h>
> @@ -81,7 +81,7 @@ mpc86xx_hpcn_init_irq(void)
>  	/* Alloc mpic structure and per isu has 16 INT entries. */
>  	mpic1 = mpic_alloc(np, res.start,
>  			MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
> -			16, NR_IRQS - 4,
> +			16, NR_IRQS - 10,
>  			" MPIC     ");

Why is the number of interrupts reduced by 10?

>  	BUG_ON(mpic1 == NULL);
>
> @@ -452,4 +452,10 @@ define_machine(mpc86xx_hpcn) {
>  	.time_init		= mpc86xx_time_init,
>  	.calibrate_decr		= generic_calibrate_decr,
>  	.progress		= udbg_progress,
> +
> +#ifdef CONFIG_GEN_RTC
> +	/* RTC interface, using functions in include/asm-generic/rtc.h */
> +	.get_rtc_time		= get_rtc_time,
> +	.set_rtc_time		= set_rtc_time,
> +#endif
>  };
> -- 
> 1.5.0.1.213.g509b
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] Better timer and RTC handling for 8641HPCN.

[Scott Wood]

On Wed, Mar 07, 2007 at 01:19:29PM -0600, Kumar Gala wrote:
> On Mar 7, 2007, at 12:49 PM, Jon Loeliger wrote:
> > From: Zhang Wei <wei.zhang@freescale.com>
> >
> > Give more IRQ numbers for MPIC IPIs and TIMERs use.
> > Added generic RTC support for MPC8641HPCN.
> >
> > Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> > Signed-off-by: Jon Loeliger <jdl@freescale.com>
> 
> Nack.
> 
> You can't call the generic set_rtc_time from the  
> ppc_md.set_rtc_time.  Take a look at:
> 
> http://ozlabs.org/pipermail/linuxppc-dev/2007-January/030440.html

set_rtc_time != rtc_set_time.  The latter is the one that goes through
the drivers/rtc stuff and needs a workqueue; the former (which this patch
uses) is in asm-generic/rtc.h, and appears to be interrupt-safe.

-Scott

Re: [PATCH] Better timer and RTC handling for 8641HPCN.

[Kumar Gala]

On Mar 7, 2007, at 1:34 PM, Scott Wood wrote:

> On Wed, Mar 07, 2007 at 01:19:29PM -0600, Kumar Gala wrote:
>> On Mar 7, 2007, at 12:49 PM, Jon Loeliger wrote:
>>> From: Zhang Wei <wei.zhang@freescale.com>
>>>
>>> Give more IRQ numbers for MPIC IPIs and TIMERs use.
>>> Added generic RTC support for MPC8641HPCN.
>>>
>>> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
>>> Signed-off-by: Jon Loeliger <jdl@freescale.com>
>>
>> Nack.
>>
>> You can't call the generic set_rtc_time from the
>> ppc_md.set_rtc_time.  Take a look at:
>>
>> http://ozlabs.org/pipermail/linuxppc-dev/2007-January/030440.html
>
> set_rtc_time != rtc_set_time.  The latter is the one that goes through
> the drivers/rtc stuff and needs a workqueue; the former (which this  
> patch
> uses) is in asm-generic/rtc.h, and appears to be interrupt-safe.

I ah, didn't notice.. Well I don't think set_rtc_time/get_rtc_time do  
anything useful for most ppc's, since it seems they use CMOS_READ/ 
CMOS_WRITE which is only defined in asm/mc146818rtc.h

- k

RE: [PATCH] Better timer and RTC handling for 8641HPCN.

[Zhang Wei-r63237]

Hi, Kumar and Scott,
=20
Thanks for your review. :-)

The MPC8641HPCN's RTC is a module of ULI1575, which is a legacy RTC
device with operate by I/O ports 0x70 and 0x71. So I use functions
defined in asm-generic/rtc.h to set and get rtc time.

Best Regards,
Zhang Wei

> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Thursday, March 08, 2007 3:49 AM
> To: Wood Scott-B07421
> Cc: Loeliger Jon-LOELIGER; Zhang Wei-r63237; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Better timer and RTC handling for 8641HPCN.
>=20
>=20
> On Mar 7, 2007, at 1:34 PM, Scott Wood wrote:
>=20
> > On Wed, Mar 07, 2007 at 01:19:29PM -0600, Kumar Gala wrote:
> >> On Mar 7, 2007, at 12:49 PM, Jon Loeliger wrote:
> >>> From: Zhang Wei <wei.zhang@freescale.com>
> >>>
> >>> Give more IRQ numbers for MPIC IPIs and TIMERs use.
> >>> Added generic RTC support for MPC8641HPCN.
> >>>
> >>> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> >>> Signed-off-by: Jon Loeliger <jdl@freescale.com>
> >>
> >> Nack.
> >>
> >> You can't call the generic set_rtc_time from the
> >> ppc_md.set_rtc_time.  Take a look at:
> >>
> >> http://ozlabs.org/pipermail/linuxppc-dev/2007-January/030440.html
> >
> > set_rtc_time !=3D rtc_set_time.  The latter is the one that=20
> goes through
> > the drivers/rtc stuff and needs a workqueue; the former=20
> (which this =20
> > patch
> > uses) is in asm-generic/rtc.h, and appears to be interrupt-safe.
>=20
> I ah, didn't notice.. Well I don't think=20
> set_rtc_time/get_rtc_time do =20
> anything useful for most ppc's, since it seems they use CMOS_READ/=20
> CMOS_WRITE which is only defined in asm/mc146818rtc.h
>=20
> - k
>=20

RE: [PATCH] Better timer and RTC handling for 8641HPCN.

[Zhang Wei-r63237]

Hi, Kumar,

> >  	/* Alloc mpic structure and per isu has 16 INT entries. */
> >  	mpic1 =3D mpic_alloc(np, res.start,
> >  			MPIC_PRIMARY | MPIC_WANTS_RESET |=20
> MPIC_BIG_ENDIAN,
> > -			16, NR_IRQS - 4,
> > +			16, NR_IRQS - 10,
> >  			" MPIC     ");
>=20
> Why is the number of interrupts reduced by 10?

There's IRQs reserved for mpic using in mpic.c around line 962:

	mpic->timer_vecs[0] =3D intvec_top - 8;
	mpic->timer_vecs[1] =3D intvec_top - 7;
	mpic->timer_vecs[2] =3D intvec_top - 6;
	mpic->timer_vecs[3] =3D intvec_top - 5;
	mpic->ipi_vecs[0]   =3D intvec_top - 4;
	mpic->ipi_vecs[1]   =3D intvec_top - 3;
	mpic->ipi_vecs[2]   =3D intvec_top - 2;
	mpic->ipi_vecs[3]   =3D intvec_top - 1;
	mpic->spurious_vec  =3D intvec_top;

So I reduces it by 10 for IRQs reserved (leave 1 more space for
further).

Thanks!

Best Regards,
Zhang Wei

Re: [PATCH] Better timer and RTC handling for 8641HPCN.

[Kumar Gala]

On Mar 7, 2007, at 7:56 PM, Zhang Wei-r63237 wrote:

> Hi, Kumar and Scott,
>
> Thanks for your review. :-)
>
> The MPC8641HPCN's RTC is a module of ULI1575, which is a legacy RTC
> device with operate by I/O ports 0x70 and 0x71. So I use functions
> defined in asm-generic/rtc.h to set and get rtc time.

Than you need to include <linux/mc146818rtc.h> in the file to get the  
CMOS_* defn.

- k

Re: [PATCH] Better timer and RTC handling for 8641HPCN.

[Kumar Gala]

On Mar 7, 2007, at 8:09 PM, Zhang Wei-r63237 wrote:

> Hi, Kumar,
>
>>>  	/* Alloc mpic structure and per isu has 16 INT entries. */
>>>  	mpic1 = mpic_alloc(np, res.start,
>>>  			MPIC_PRIMARY | MPIC_WANTS_RESET |
>> MPIC_BIG_ENDIAN,
>>> -			16, NR_IRQS - 4,
>>> +			16, NR_IRQS - 10,
>>>  			" MPIC     ");
>>
>> Why is the number of interrupts reduced by 10?
>
> There's IRQs reserved for mpic using in mpic.c around line 962:
>
> 	mpic->timer_vecs[0] = intvec_top - 8;
> 	mpic->timer_vecs[1] = intvec_top - 7;
> 	mpic->timer_vecs[2] = intvec_top - 6;
> 	mpic->timer_vecs[3] = intvec_top - 5;
> 	mpic->ipi_vecs[0]   = intvec_top - 4;
> 	mpic->ipi_vecs[1]   = intvec_top - 3;
> 	mpic->ipi_vecs[2]   = intvec_top - 2;
> 	mpic->ipi_vecs[3]   = intvec_top - 1;
> 	mpic->spurious_vec  = intvec_top;
>
> So I reduces it by 10 for IRQs reserved (leave 1 more space for
> further).

Why don't we set the number to 64 instead of NR_IRQS - 10.  This  
covers all the internal and external interrupts.

- k

RE: [PATCH] Better timer and RTC handling for 8641HPCN.

[Zhang Wei-r63237]

In fact, I've included <asm-generic/rtc.h> in mpc86xx_hpcn.c file, and
the file linux/mc146818rtc.h was included in asm-generic/rtc.h.

Thanks!
Zhang Wei

> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Thursday, March 08, 2007 10:47 AM
> To: Zhang Wei-r63237
> Cc: Wood Scott-B07421; Loeliger Jon-LOELIGER; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Better timer and RTC handling for 8641HPCN.
>=20
>=20
> On Mar 7, 2007, at 7:56 PM, Zhang Wei-r63237 wrote:
>=20
> > Hi, Kumar and Scott,
> >
> > Thanks for your review. :-)
> >
> > The MPC8641HPCN's RTC is a module of ULI1575, which is a legacy RTC
> > device with operate by I/O ports 0x70 and 0x71. So I use functions
> > defined in asm-generic/rtc.h to set and get rtc time.
>=20
> Than you need to include <linux/mc146818rtc.h> in the file to=20
> get the =20
> CMOS_* defn.
>=20
> - k
>=20
>=20
>=20

Re: [PATCH] Better timer and RTC handling for 8641HPCN.

[Kumar Gala]

On Mar 7, 2007, at 11:38 PM, Zhang Wei-r63237 wrote:

> In fact, I've included <asm-generic/rtc.h> in mpc86xx_hpcn.c file, and
> the file linux/mc146818rtc.h was included in asm-generic/rtc.h.

Uugh, sorry... was looking at asm/rtc.h not asm-generic/rtc.h (thus  
my confusion)

I don't think we should add new users of the old rtc code at this  
point.  We really should look at using the rtc class code.

I'm going to start a new thread on figuring out what we need to do  
for ppc_md.set_rtc_time/ppc_md.get_rtc_time and the rtc subsystem.

- k

>
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Thursday, March 08, 2007 10:47 AM
>> To: Zhang Wei-r63237
>> Cc: Wood Scott-B07421; Loeliger Jon-LOELIGER; linuxppc-dev@ozlabs.org
>> Subject: Re: [PATCH] Better timer and RTC handling for 8641HPCN.
>>
>>
>> On Mar 7, 2007, at 7:56 PM, Zhang Wei-r63237 wrote:
>>
>>> Hi, Kumar and Scott,
>>>
>>> Thanks for your review. :-)
>>>
>>> The MPC8641HPCN's RTC is a module of ULI1575, which is a legacy RTC
>>> device with operate by I/O ports 0x70 and 0x71. So I use functions
>>> defined in asm-generic/rtc.h to set and get rtc time.
>>
>> Than you need to include <linux/mc146818rtc.h> in the file to
>> get the
>> CMOS_* defn.
>>
>> - k
>>
>>
>>

RE: [PATCH] Better timer and RTC handling for 8641HPCN.

[Zhang Wei-r63237]

Hi, Kumar,=20

> >
> > So I reduces it by 10 for IRQs reserved (leave 1 more space for
> > further).
>=20
> Why don't we set the number to 64 instead of NR_IRQS - 10.  This =20
> covers all the internal and external interrupts.
>=20

If you want to set the IRQ amount number, it should be 80 instead of 64.
But I think setting it to NR_IRQS-10 could give more space for MPIC.

Thanks!
Zhang Wei

Re: [PATCH] Better timer and RTC handling for 8641HPCN.

[Kumar Gala]

On Mar 8, 2007, at 2:17 AM, Zhang Wei-r63237 wrote:

> Hi, Kumar,
>
>>>
>>> So I reduces it by 10 for IRQs reserved (leave 1 more space for
>>> further).
>>
>> Why don't we set the number to 64 instead of NR_IRQS - 10.  This
>> covers all the internal and external interrupts.
>>
>
> If you want to set the IRQ amount number, it should be 80 instead  
> of 64.
> But I think setting it to NR_IRQS-10 could give more space for MPIC.

Sure, but what's the point in allocating more interrupts than you  
actually will ever have?

I'd say lets make it 64 for now.  We don't yet support the messaging  
or MSI interrupts that exist beyond 64.

- k

Re: [PATCH] Better timer and RTC handling for 8641HPCN.

[Jon Loeliger]

On Wed, 2007-03-07 at 23:57, Kumar Gala wrote:
> On Mar 7, 2007, at 11:38 PM, Zhang Wei-r63237 wrote:
> 
> > In fact, I've included <asm-generic/rtc.h> in mpc86xx_hpcn.c file, and
> > the file linux/mc146818rtc.h was included in asm-generic/rtc.h.
> 
> Uugh, sorry... was looking at asm/rtc.h not asm-generic/rtc.h (thus  
> my confusion)
> 
> I don't think we should add new users of the old rtc code at this  
> point.  We really should look at using the rtc class code.
> 
> I'm going to start a new thread on figuring out what we need to do  
> for ppc_md.set_rtc_time/ppc_md.get_rtc_time and the rtc subsystem.
> 
> - k

So, I kinda lost track of the fate of this change....
Is there a better way to write this?  Are we waiting for
you to start a discussion about this?  Or will it be
applied as is for now and fixed up (?) later?

And we're to change the NR_IRQS-10 to a hard 64 as well, right?

Thanks,
jdl

Re: [PATCH] Better timer and RTC handling for 8641HPCN.

[Haiying Wang]

> And we're to change the NR_IRQS-10 to a hard 64 as well, right?
> 
If we need change to hard value here, we should use 80 instead 64
because there are 16 interrupt sources for 8259, 48 for internal, 12 for
external.

Haiying

Re: [PATCH] Better timer and RTC handling for 8641HPCN.

[Kumar Gala]

On Mar 8, 2007, at 1:19 PM, Haiying Wang wrote:

>> And we're to change the NR_IRQS-10 to a hard 64 as well, right?
>>
> If we need change to hard value here, we should use 80 instead 64
> because there are 16 interrupt sources for 8259, 48 for internal,  
> 12 for
> external.

but the 16 interrupts for 8259 have nothing to do with how many you  
allocate for MPIC.  64 is the number of MPIC interrupts (48 int + 12  
ext = 60).  I say 64 because of how the register addresses.

- k

Re: [PATCH] Better timer and RTC handling for 8641HPCN.

[Kim Phillips]

On Wed, 7 Mar 2007 23:57:36 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:

> 
> On Mar 7, 2007, at 11:38 PM, Zhang Wei-r63237 wrote:
> 
> > In fact, I've included <asm-generic/rtc.h> in mpc86xx_hpcn.c file, and
> > the file linux/mc146818rtc.h was included in asm-generic/rtc.h.
> 
> Uugh, sorry... was looking at asm/rtc.h not asm-generic/rtc.h (thus  
> my confusion)
> 
> I don't think we should add new users of the old rtc code at this  
> point.  We really should look at using the rtc class code.
> 
yes, removing the ppc_md hooks and configuring RTC_DRV_CMOS might be a more appropriate thing to do for this board.

Kim

RE: [PATCH] Better timer and RTC handling for 8641HPCN.

[Zhang Wei-r63237]

Please use 80.
We reserve the first 16 ints for legacy 8259 interrupts. And we want the
virq is the same value to hw-irq.

Thanks!
Zhang Wei

> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Friday, March 09, 2007 3:25 AM
> To: Wang Haiying-r54964
> Cc: Loeliger Jon-LOELIGER; linuxppc-dev@ozlabs.org; Zhang Wei-r63237
> Subject: Re: [PATCH] Better timer and RTC handling for 8641HPCN.
>=20
>=20
> On Mar 8, 2007, at 1:19 PM, Haiying Wang wrote:
>=20
> >> And we're to change the NR_IRQS-10 to a hard 64 as well, right?
> >>
> > If we need change to hard value here, we should use 80 instead 64
> > because there are 16 interrupt sources for 8259, 48 for internal, =20
> > 12 for
> > external.
>=20
> but the 16 interrupts for 8259 have nothing to do with how many you =20
> allocate for MPIC.  64 is the number of MPIC interrupts (48 int + 12 =20
> ext =3D 60).  I say 64 because of how the register addresses.
>=20
> - k
>=20

Re: [PATCH] Better timer and RTC handling for 8641HPCN.

[Kumar Gala]

On Mar 8, 2007, at 7:51 PM, Zhang Wei-r63237 wrote:

> Please use 80.
> We reserve the first 16 ints for legacy 8259 interrupts. And we  
> want the
> virq is the same value to hw-irq.

Why?

- k

RE: [PATCH] Better timer and RTC handling for 8641HPCN.

[Zhang Wei-r63237]

> > Please use 80.
> > We reserve the first 16 ints for legacy 8259 interrupts. And we =20
> > want the
> > virq is the same value to hw-irq.
>=20
> Why?

If the virq equals hw-irq, it's clear and simple to user.

Thanks!
Zhang Wei

Re: [PATCH] Better timer and RTC handling for 8641HPCN.

[Kumar Gala]

On Mar 8, 2007, at 10:23 PM, Zhang Wei-r63237 wrote:

>>> Please use 80.
>>> We reserve the first 16 ints for legacy 8259 interrupts. And we
>>> want the
>>> virq is the same value to hw-irq.
>>
>> Why?
>
> If the virq equals hw-irq, it's clear and simple to user.

I don't think that's a good reason to over allocate.

There's a reason we have virtual IRQs now.  Its specifically to deal  
with issues like the 16 interrupts for 8259 and not have to do games  
to offset IRQs.

If we needed create some debugfs or sysfs info that translates VIRQ  
to HW irq

- k

RE: [PATCH] Better timer and RTC handling for 8641HPCN.

[Zhang Wei-r63237]

>=20
> >>> Please use 80.
> >>> We reserve the first 16 ints for legacy 8259 interrupts. And we
> >>> want the
> >>> virq is the same value to hw-irq.
> >>
> >> Why?
> >
> > If the virq equals hw-irq, it's clear and simple to user.
>=20
> I don't think that's a good reason to over allocate.
>=20
> There's a reason we have virtual IRQs now.  Its specifically to deal =20
> with issues like the 16 interrupts for 8259 and not have to do games =20
> to offset IRQs.
>=20
> If we needed create some debugfs or sysfs info that translates VIRQ =20
> to HW irq
>=20

I know that's the advantage of virtual IRQs. But in this platform, we
want to fix up the virq to hwirq and let users know which irq is coming
from which devices.

- z

IRQ numbering (was: Better timer and RTC handling for 8641HPCN.)

[Kumar Gala]

>>>>> Please use 80.
>>>>> We reserve the first 16 ints for legacy 8259 interrupts. And we
>>>>> want the
>>>>> virq is the same value to hw-irq.
>>>>
>>>> Why?
>>>
>>> If the virq equals hw-irq, it's clear and simple to user.
>>
>> I don't think that's a good reason to over allocate.
>>
>> There's a reason we have virtual IRQs now.  Its specifically to deal
>> with issues like the 16 interrupts for 8259 and not have to do games
>> to offset IRQs.
>>
>> If we needed create some debugfs or sysfs info that translates VIRQ
>> to HW irq
>>
>
> I know that's the advantage of virtual IRQs. But in this platform, we
> want to fix up the virq to hwirq and let users know which irq is  
> coming
> from which devices.

But how do I know IRQ 42 is really 26 for the MPIC.  What are you  
users doing that they can't handle the virtual irq concept?

It was pointed out, that you are coupling the IRQ # in the .dts with  
the kernel virtual number which is a bad idea.  In theory the device- 
tree description shouldn't be coupled this tightly to the kernel.

I think the Freescale reference boards should strive to show people  
how to do things properly since people tend to copy this code and use  
it as a starting point.  I doubt most 86xx designs are really going  
to have an 8259 controller on them and thus making things focus  
around it seems silly.

- k

RE: IRQ numbering (was: Better timer and RTC handling for 8641HPCN.)

[Zhang Wei-r63237]

> >>>>> Please use 80.
> >>>>> We reserve the first 16 ints for legacy 8259 interrupts. And we
> >>>>> want the
> >>>>> virq is the same value to hw-irq.
> >>>>
> >>>> Why?
> >>>
> >>> If the virq equals hw-irq, it's clear and simple to user.
> >>
> >> I don't think that's a good reason to over allocate.
> >>
> >> There's a reason we have virtual IRQs now.  Its=20
> specifically to deal
> >> with issues like the 16 interrupts for 8259 and not have=20
> to do games
> >> to offset IRQs.
> >>
> >> If we needed create some debugfs or sysfs info that translates VIRQ
> >> to HW irq
> >>
> >
> > I know that's the advantage of virtual IRQs. But in this=20
> platform, we
> > want to fix up the virq to hwirq and let users know which irq is =20
> > coming
> > from which devices.
>=20
> But how do I know IRQ 42 is really 26 for the MPIC.  What are you =20
> users doing that they can't handle the virtual irq concept?
>=20
> It was pointed out, that you are coupling the IRQ # in the .dts with =20
> the kernel virtual number which is a bad idea.  In theory the device-=20
> tree description shouldn't be coupled this tightly to the kernel.
>=20
> I think the Freescale reference boards should strive to show people =20
> how to do things properly since people tend to copy this code=20
> and use =20
> it as a starting point.  I doubt most 86xx designs are really going =20
> to have an 8259 controller on them and thus making things focus =20
> around it seems silly.
>=20
Hi, Kumar,

I have used the a fake interrupt hole to avoid the hwirq overlapping.
Now the virq equals the hwirq.=20

I agree with the virq has lots of advantages than irq offset. But we can
not give the user a fixup irq list since the virq will be changed by
different device driver loading. And the user can not get the hwirq from
the user space application.

I think creating some debugfs or sysfs info that translates VIRQ to HW
irq is a _good_ idea, or just add some fields (irq host, hwirq) in
/proc/interrupts. If we have this, I'll fix all irqs in dts file and
remove the fake irq hole.

Before we have a virq-hwirq mapping list, I keep my option about the irq
number.

Thanks!
Zhang Wei

Re: IRQ numbering (was: Better timer and RTC handling for 8641HPCN.)

[Kumar Gala]

On Mar 11, 2007, at 9:37 PM, Zhang Wei-r63237 wrote:

>>>>>>> Please use 80.
>>>>>>> We reserve the first 16 ints for legacy 8259 interrupts. And we
>>>>>>> want the
>>>>>>> virq is the same value to hw-irq.
>>>>>>
>>>>>> Why?
>>>>>
>>>>> If the virq equals hw-irq, it's clear and simple to user.
>>>>
>>>> I don't think that's a good reason to over allocate.
>>>>
>>>> There's a reason we have virtual IRQs now.  Its
>> specifically to deal
>>>> with issues like the 16 interrupts for 8259 and not have
>> to do games
>>>> to offset IRQs.
>>>>
>>>> If we needed create some debugfs or sysfs info that translates VIRQ
>>>> to HW irq
>>>>
>>>
>>> I know that's the advantage of virtual IRQs. But in this
>> platform, we
>>> want to fix up the virq to hwirq and let users know which irq is
>>> coming
>>> from which devices.
>>
>> But how do I know IRQ 42 is really 26 for the MPIC.  What are you
>> users doing that they can't handle the virtual irq concept?
>>
>> It was pointed out, that you are coupling the IRQ # in the .dts with
>> the kernel virtual number which is a bad idea.  In theory the device-
>> tree description shouldn't be coupled this tightly to the kernel.
>>
>> I think the Freescale reference boards should strive to show people
>> how to do things properly since people tend to copy this code
>> and use
>> it as a starting point.  I doubt most 86xx designs are really going
>> to have an 8259 controller on them and thus making things focus
>> around it seems silly.
>>
> Hi, Kumar,
>
> I have used the a fake interrupt hole to avoid the hwirq overlapping.
> Now the virq equals the hwirq.

For what's written into the register, sure.. But who cares about  
that.  You still have to know that virq 16 equals internal mpic irq  
0.  What's written into vector field of the mpic register isn't too  
terribly useful to the user.

> I agree with the virq has lots of advantages than irq offset. But  
> we can
> not give the user a fixup irq list since the virq will be changed by
> different device driver loading. And the user can not get the hwirq  
> from
> the user space application.

I'm confused, what are users doing that they need to deal with this?

> I think creating some debugfs or sysfs info that translates VIRQ to HW
> irq is a _good_ idea, or just add some fields (irq host, hwirq) in
> /proc/interrupts. If we have this, I'll fix all irqs in dts file and
> remove the fake irq hole.
>
> Before we have a virq-hwirq mapping list, I keep my option about  
> the irq
> number.

You need to explain what people are doing that they need this  
information.  You are implying there would be some functionality lost  
by removing the offset.  As far as I can tell this is just a debug  
convenience.

- k

RE: IRQ numbering (was: Better timer and RTC handling for 8641HPCN.)

[Paul Mackerras]

Zhang Wei-r63237 writes:

> I think creating some debugfs or sysfs info that translates VIRQ to HW
> irq is a _good_ idea, or just add some fields (irq host, hwirq) in
> /proc/interrupts. If we have this, I'll fix all irqs in dts file and
> remove the fake irq hole.

It would have to be a (host, hwirq) pair.  A "hwirq" has no meaning by
itself, since in general we can have multiple interrupt controllers
and they will each have their own space of interrupt numbers.

> Before we have a virq-hwirq mapping list, I keep my option about the irq
> number.

There is no point trying to fake things up in the .dts so that you get
virq numbers that you expect.  The numbers in the .dts should be the
controller-relative "hwirq" numbers.

Paul.