ARM: OMAP4: core retention support
Subsystems (6)
v3 cover ARM: OMAP4: core retention support
Hi,
Changes compared to previous version:
- split out the io_chain set as a separate set
- marked patch 3 as TEMP, this is only needed until Paul's pwrdm fixes get merged (http://marc.info/?l=linux-omap&m=133040749621183&w=2)
Depends on the io_chain set to provide wakeup capability from retention.
Tested with omap4430 blaze : suspend / resume works okay.
-Tero
PATCH v3 1/4 ARM: OMAP4: suspend: Program all domains to retention
From: Rajendra Nayak <[email protected]>
Remove the FIXME's in the suspend sequence since we now intend to support system level RET support.
--- arch/arm/mach-omap2/pm44xx.c | 6 ------ 1 files changed, 0 insertions(+), 6 deletions(-)
arch/arm/mach-omap2/pm44xx.c +0 -6
@@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)if (!strncmp (pwrdm->name,"cpu" ,3 ))return 0 ; -/* -* FIXME: Remove this check when core retention is supported -* Only MPUSS power domain is added in the list. -*/ -if (strcmp (pwrdm->name,"mpu_pwrdm" )) -return 0 ; pwrst =kmalloc (sizeof (struct power_state ),GFP_ATOMIC );if (!pwrst)
Signature · 1 line
1.7.4.1
PATCH v3 1/4 ARM: OMAP4: suspend: Program all domains to retention
Quoted 8 lines · Tero Kristo
From: Rajendra Nayak <[email protected]>
Remove the FIXME's in the suspend sequence since we now intend to support system level RET support.
Signed-off-by Rajendra Nayak <[email protected]>Signed-off-by Tero Kristo <[email protected]>Reviewed-by Santosh Shilimkar <[email protected]>
So this is the only patch in this series that is still needed. However...
It doesn't seem like this all by itself is ready for mainline as we'll suddenly start putting all powerdomains in retention without any additional support.
I guess at a minimum it needs working IO wakeup support from the IO daisy chain series. Are there other dependencies here?
If not, I can queue this when Paul is ready to merge the IO wakeup stuff.
Kevin
Quoted 21 lines
--- arch/arm/mach-omap2/pm44xx.c | 6 ------ 1 files changed, 0 insertions(+), 6 deletions(-)arch/arm/mach-omap2/pm44xx.c +0
-6@@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)if (!strncmp (pwrdm->name,"cpu" ,3 ))return 0 ; -/* -* FIXME: Remove this check when core retention is supported -* Only MPUSS power domain is added in the list. -*/ -if (strcmp (pwrdm->name,"mpu_pwrdm" )) -return 0 ; pwrst =kmalloc (sizeof (struct power_state ),GFP_ATOMIC );if (!pwrst)
PATCH v3 1/4 ARM: OMAP4: suspend: Program all domains to retention
Quoted 11 lines · Kevin Hilman
Quoted 8 lines · Tero Kristo
From: Rajendra Nayak <[email protected]>
Remove the FIXME's in the suspend sequence since we now intend to support system level RET support.
Signed-off-by Rajendra Nayak <[email protected]>Signed-off-by Tero Kristo <[email protected]>Reviewed-by Santosh Shilimkar <[email protected]>
Quoted 8 lines
So this is the only patch in this series that is still needed. However...
It doesn't seem like this all by itself is ready for mainline as we'll suddenly start putting all powerdomains in retention without any additional support.
I guess at a minimum it needs working IO wakeup support from the IO daisy chain series. Are there other dependencies here?
Only IO chain is needed for wakeup capability. Actually even with the current mainline kernel, I am unable to wake-up the device from MPU retention, as there are no wakeup sources. So this patch doesn't really change the behavior to worse even without any additional patches. :) But yea, good to wait until IO chain is in.
The other dependencies are that the stuff handled by patches 2,3 and 4 have to be handled somehow:
-patch2: must be in (this patch is queued by Paul) -patch3: will be taken care of by Paul's pwrdm fixes (I guess this is queued by Paul himself already)
-patch4: OMAP interrupt count must be increased (this is handled by Benoit's patch, which is queued by Tony)
-Tero
Quoted 27 lines
If not, I can queue this when Paul is ready to merge the IO wakeup stuff.
Kevin
Quoted 21 lines
--- arch/arm/mach-omap2/pm44xx.c | 6 ------ 1 files changed, 0 insertions(+), 6 deletions(-)arch/arm/mach-omap2/pm44xx.c +0
-6@@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)if (!strncmp (pwrdm->name,"cpu" ,3 ))return 0 ; -/* -* FIXME: Remove this check when core retention is supported -* Only MPUSS power domain is added in the list. -*/ -if (strcmp (pwrdm->name,"mpu_pwrdm" )) -return 0 ; pwrst =kmalloc (sizeof (struct power_state ),GFP_ATOMIC );if (!pwrst)
PATCH v3 1/4 ARM: OMAP4: suspend: Program all domains to retention
Quoted 18 lines · Tero Kristo
Quoted 17 lines · Kevin Hilman
Quoted 8 lines · Tero Kristo
From: Rajendra Nayak<[email protected]>
Remove the FIXME's in the suspend sequence since we now intend to support system level RET support.
Signed-off-by Rajendra Nayak<[email protected]>Signed-off-by Tero Kristo<[email protected]>Reviewed-by Santosh Shilimkar<[email protected]>So this is the only patch in this series that is still needed. However...
It doesn't seem like this all by itself is ready for mainline as we'll suddenly start putting all powerdomains in retention without any additional support.
Quoted 6 lines
Quoted 2 lines
I guess at a minimum it needs working IO wakeup support from the IO daisy chain series. Are there other dependencies here?
Only IO chain is needed for wakeup capability. Actually even with the current mainline kernel, I am unable to wake-up the device from MPU retention, as there are no wakeup sources. So this patch doesn't really
Why?, doesn't debug console wakeup work?
Quoted 2 lines
change the behavior to worse even without any additional patches. :) But yea, good to wait until IO chain is in.
IO chain, according to documentation :) should be needed only if you hit OSWR or OFF, async wakeups should be functional as long as you only hit CSWR.
Quoted 41 lines
The other dependencies are that the stuff handled by patches 2,3 and 4 have to be handled somehow:
(quoted diff) +0
-2-patch2: must be in (this patch is queued by Paul) -patch3: will be taken care of by Paul's pwrdm fixes (I guess this isqueued by Paul himself already)
-patch4: OMAP interrupt count must be increased (this is handled by Benoit's patch, which is queued by Tony)-Tero
Quoted 27 lines
If not, I can queue this when Paul is ready to merge the IO wakeup stuff.
Kevin
Quoted 21 lines
--- arch/arm/mach-omap2/pm44xx.c | 6 ------ 1 files changed, 0 insertions(+), 6 deletions(-)arch/arm/mach-omap2/pm44xx.c +0
-6@@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)if (!strncmp (pwrdm->name,"cpu" ,3 ))return 0 ; -/* -* FIXME: Remove this check when core retention is supported -* Only MPUSS power domain is added in the list. -*/ -if (strcmp (pwrdm->name,"mpu_pwrdm" )) -return 0 ; pwrst =kmalloc (sizeof (struct power_state ),GFP_ATOMIC );if (!pwrst)
PATCH v3 1/4 ARM: OMAP4: suspend: Program all domains to retention
Quoted 19 lines · Rajendra Nayak
Quoted 18 lines · Tero Kristo
Quoted 17 lines · Kevin Hilman
Quoted 8 lines · Tero Kristo
From: Rajendra Nayak<[email protected]>
Remove the FIXME's in the suspend sequence since we now intend to support system level RET support.
Signed-off-by Rajendra Nayak<[email protected]>Signed-off-by Tero Kristo<[email protected]>Reviewed-by Santosh Shilimkar<[email protected]>So this is the only patch in this series that is still needed. However...
It doesn't seem like this all by itself is ready for mainline as we'll suddenly start putting all powerdomains in retention without any additional support.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
I guess at a minimum it needs working IO wakeup support from the IO daisy chain series. Are there other dependencies here?
Only IO chain is needed for wakeup capability. Actually even with the current mainline kernel, I am unable to wake-up the device from MPU retention, as there are no wakeup sources. So this patch doesn't really
Why?, doesn't debug console wakeup work?
At least I couldn't get it to work. I tried with no_console_suspend kernel param to no avail. Don't know if I was missing something else.
-Tero
Quoted 50 lines
Quoted 3 lines
change the behavior to worse even without any additional patches. :) But yea, good to wait until IO chain is in.
IO chain, according to documentation :) should be needed only if you hit OSWR or OFF, async wakeups should be functional as long as you only hit CSWR.
Quoted 41 lines
The other dependencies are that the stuff handled by patches 2,3 and 4 have to be handled somehow:
(quoted diff) +0
-2-patch2: must be in (this patch is queued by Paul) -patch3: will be taken care of by Paul's pwrdm fixes (I guess this isqueued by Paul himself already)
-patch4: OMAP interrupt count must be increased (this is handled by Benoit's patch, which is queued by Tony)-Tero
Quoted 27 lines
If not, I can queue this when Paul is ready to merge the IO wakeup stuff.
Kevin
Quoted 21 lines
--- arch/arm/mach-omap2/pm44xx.c | 6 ------ 1 files changed, 0 insertions(+), 6 deletions(-)arch/arm/mach-omap2/pm44xx.c +0
-6@@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)if (!strncmp (pwrdm->name,"cpu" ,3 ))return 0 ; -/* -* FIXME: Remove this check when core retention is supported -* Only MPUSS power domain is added in the list. -*/ -if (strcmp (pwrdm->name,"mpu_pwrdm" )) -return 0 ; pwrst =kmalloc (sizeof (struct power_state ),GFP_ATOMIC );if (!pwrst)
PATCH v3 1/4 ARM: OMAP4: suspend: Program all domains to retention
Quoted 23 lines · Tero Kristo
Quoted 22 lines · Rajendra Nayak
Quoted 21 lines · Tero Kristo
Quoted 19 lines · Kevin Hilman
Quoted 8 lines · Tero Kristo
From: Rajendra Nayak<[email protected]>
Remove the FIXME's in the suspend sequence since we now intend to support system level RET support.
Signed-off-by Rajendra Nayak<[email protected]>Signed-off-by Tero Kristo<[email protected]>Reviewed-by Santosh Shilimkar<[email protected]>So this is the only patch in this series that is still needed. However...
It doesn't seem like this all by itself is ready for mainline as we'll suddenly start putting all powerdomains in retention without any additional support.
I guess at a minimum it needs working IO wakeup support from the IO daisy chain series. Are there other dependencies here?
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Only IO chain is needed for wakeup capability. Actually even with the current mainline kernel, I am unable to wake-up the device from MPU retention, as there are no wakeup sources. So this patch doesn't really
Why?, doesn't debug console wakeup work?
At least I couldn't get it to work. I tried with
no_console_suspendkernel param to no avail. Don't know if I was missing something else.
Did you try enabling wakeup for the debug console?
echo enabled > /sys/devices/platform/omap/omap_uart.2/tty/ttyO2/power/wakeup
Quoted 55 lines
-Tero
Quoted 50 lines
Quoted 3 lines
change the behavior to worse even without any additional patches. :) But yea, good to wait until IO chain is in.
IO chain, according to documentation :) should be needed only if you hit OSWR or OFF, async wakeups should be functional as long as you only hit CSWR.
Quoted 41 lines
The other dependencies are that the stuff handled by patches 2,3 and 4 have to be handled somehow:
(quoted diff) +0
-2-patch2: must be in (this patch is queued by Paul) -patch3: will be taken care of by Paul's pwrdm fixes (I guess this isqueued by Paul himself already)
-patch4: OMAP interrupt count must be increased (this is handled by Benoit's patch, which is queued by Tony)-Tero
Quoted 27 lines
If not, I can queue this when Paul is ready to merge the IO wakeup stuff.
Kevin
Quoted 21 lines
--- arch/arm/mach-omap2/pm44xx.c | 6 ------ 1 files changed, 0 insertions(+), 6 deletions(-)arch/arm/mach-omap2/pm44xx.c +0
-6@@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)if (!strncmp (pwrdm->name,"cpu" ,3 ))return 0 ; -/* -* FIXME: Remove this check when core retention is supported -* Only MPUSS power domain is added in the list. -*/ -if (strcmp (pwrdm->name,"mpu_pwrdm" )) -return 0 ; pwrst =kmalloc (sizeof (struct power_state ),GFP_ATOMIC );if (!pwrst)
PATCH v3 1/4 ARM: OMAP4: suspend: Program all domains to retention
Quoted 28 lines · Rajendra Nayak
Quoted 27 lines · Tero Kristo
Quoted 26 lines · Rajendra Nayak
Quoted 24 lines · Tero Kristo
Quoted 11 lines · Kevin Hilman
Quoted 8 lines · Tero Kristo
From: Rajendra Nayak<[email protected]>
Remove the FIXME's in the suspend sequence since we now intend to support system level RET support.
Signed-off-by Rajendra Nayak<[email protected]>Signed-off-by Tero Kristo<[email protected]>Reviewed-by Santosh Shilimkar<[email protected]>Quoted 8 lines
So this is the only patch in this series that is still needed. However...
It doesn't seem like this all by itself is ready for mainline as we'll suddenly start putting all powerdomains in retention without any additional support.
I guess at a minimum it needs working IO wakeup support from the IO daisy chain series. Are there other dependencies here?
Only IO chain is needed for wakeup capability. Actually even with the current mainline kernel, I am unable to wake-up the device from MPU retention, as there are no wakeup sources. So this patch doesn't really
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Why?, doesn't debug console wakeup work?
At least I couldn't get it to work. I tried with
no_console_suspendkernel param to no avail. Don't know if I was missing something else.Did you try enabling wakeup for the debug console?
echo enabled >/sys/devices/platform/omap/omap_uart.2/tty/ttyO2/power/wakeup
I think not, however I wonder why the wakeups are not enabled by default if this helps?
Quoted 57 lines
Quoted 56 lines
-Tero
Quoted 50 lines
Quoted 3 lines
change the behavior to worse even without any additional patches. :) But yea, good to wait until IO chain is in.
IO chain, according to documentation :) should be needed only if you hit OSWR or OFF, async wakeups should be functional as long as you only hit CSWR.
Quoted 41 lines
The other dependencies are that the stuff handled by patches 2,3 and 4 have to be handled somehow:
(quoted diff) +0
-2-patch2: must be in (this patch is queued by Paul) -patch3: will be taken care of by Paul's pwrdm fixes (I guess this isqueued by Paul himself already)
-patch4: OMAP interrupt count must be increased (this is handled by Benoit's patch, which is queued by Tony)-Tero
Quoted 27 lines
If not, I can queue this when Paul is ready to merge the IO wakeup stuff.
Kevin
Quoted 21 lines
--- arch/arm/mach-omap2/pm44xx.c | 6 ------ 1 files changed, 0 insertions(+), 6 deletions(-)arch/arm/mach-omap2/pm44xx.c +0
-6@@ -151,12 +151,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)if (!strncmp (pwrdm->name,"cpu" ,3 ))return 0 ; -/* -* FIXME: Remove this check when core retention is supported -* Only MPUSS power domain is added in the list. -*/ -if (strcmp (pwrdm->name,"mpu_pwrdm" )) -return 0 ; pwrst =kmalloc (sizeof (struct power_state ),GFP_ATOMIC );if (!pwrst)
PATCH v3 2/4 ARM: OMAP4: prm: fix interrupt register offsets
In reply to Tero KristoPrevious code used wrong instance for the interrupt register access. Use the right one which is OCP_SOCKET.
--- arch/arm/mach-omap2/prm44xx.c | 21 +++++++++++---------- 1 files changed, 11 insertions(+), 10 deletions(-)
arch/arm/mach-omap2/prm44xx.c +11 -10
@@ -145,8 +145,9 @@ static inline u32 _read_pending_irq_reg(u16 irqen_offs, u16 irqst_offs)u32 mask, st;/* XXX read mask from RAM? */ - mask =omap4_prm_read_inst_reg (OMAP4430_PRM_DEVICE_INST , irqen_offs); - st =omap4_prm_read_inst_reg (OMAP4430_PRM_DEVICE_INST , irqst_offs); + mask =omap4_prm_read_inst_reg (OMAP4430_PRM_OCP_SOCKET_INST , + irqen_offs); + st =omap4_prm_read_inst_reg (OMAP4430_PRM_OCP_SOCKET_INST , irqst_offs);return mask & st; }
@@ -178,7 +179,7 @@ void omap44xx_prm_read_pending_irqs(unsigned long *events)*/ void omap44xx_prm_ocp_barrier (void ) { -omap4_prm_read_inst_reg (OMAP4430_PRM_DEVICE_INST , +omap4_prm_read_inst_reg (OMAP4430_PRM_OCP_SOCKET_INST ,OMAP4_REVISION_PRM_OFFSET ); }
@@ -196,19 +197,19 @@ void omap44xx_prm_ocp_barrier(void)void omap44xx_prm_save_and_clear_irqen (u32 *saved_mask) { saved_mask[0 ] = -omap4_prm_read_inst_reg (OMAP4430_PRM_DEVICE_INST , +omap4_prm_read_inst_reg (OMAP4430_PRM_OCP_SOCKET_INST ,OMAP4_PRM_IRQSTATUS_MPU_OFFSET ); saved_mask[1 ] = -omap4_prm_read_inst_reg (OMAP4430_PRM_DEVICE_INST , +omap4_prm_read_inst_reg (OMAP4430_PRM_OCP_SOCKET_INST ,OMAP4_PRM_IRQSTATUS_MPU_2_OFFSET ); -omap4_prm_write_inst_reg (0 ,OMAP4430_PRM_DEVICE_INST , +omap4_prm_write_inst_reg (0 ,OMAP4430_PRM_OCP_SOCKET_INST ,OMAP4_PRM_IRQENABLE_MPU_OFFSET ); -omap4_prm_write_inst_reg (0 ,OMAP4430_PRM_DEVICE_INST , +omap4_prm_write_inst_reg (0 ,OMAP4430_PRM_OCP_SOCKET_INST ,OMAP4_PRM_IRQENABLE_MPU_2_OFFSET );/* OCP barrier */ -omap4_prm_read_inst_reg (OMAP4430_PRM_DEVICE_INST , +omap4_prm_read_inst_reg (OMAP4430_PRM_OCP_SOCKET_INST ,OMAP4_REVISION_PRM_OFFSET ); }
@@ -224,9 +225,9 @@ void omap44xx_prm_save_and_clear_irqen(u32 *saved_mask)*/ void omap44xx_prm_restore_irqen (u32 *saved_mask) { -omap4_prm_write_inst_reg (saved_mask[0 ],OMAP4430_PRM_DEVICE_INST , +omap4_prm_write_inst_reg (saved_mask[0 ],OMAP4430_PRM_OCP_SOCKET_INST ,OMAP4_PRM_IRQENABLE_MPU_OFFSET ); -omap4_prm_write_inst_reg (saved_mask[1 ],OMAP4430_PRM_DEVICE_INST , +omap4_prm_write_inst_reg (saved_mask[1 ],OMAP4430_PRM_OCP_SOCKET_INST ,OMAP4_PRM_IRQENABLE_MPU_2_OFFSET ); }
Signature · 1 line
1.7.4.1
Paul Walmsley
maintainerPATCH v3 2/4 ARM: OMAP4: prm: fix interrupt register offsets
Quoted 5 lines · Tero Kristo
Previous code used wrong instance for the interrupt register access. Use the right one which is
OCP_SOCKET.Signed-off-by Tero Kristo <[email protected]>Cc Paul Walmsley <[email protected]>
Thanks, queued.
- Paul
PATCH v3 3/4 TEMP: ARM: OMAP4: hwmod_data: Do not get DSP out of reset at boot time
In reply to Tero KristoFrom: Rajendra Nayak <[email protected]>
With no driver handling DSP, if brought out of reset, it stays active and does not assert standby. This leads to IVAHD powerdomain not transitioning and hence preventing chip retention.
This patch is no longer needed once Paul's powerdomain fixes are merged:
http://marc.info/?l=linux-omap&m=133040749621183&w=2
Just provided for testing purposes.
--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/omap_hwmod_44xx_data.c +1 -0
@@ -1160,6 +1160,7 @@ static struct omap_hwmod omap44xx_dsp_hwmod = { .name = "dsp", .class = &omap44xx_dsp_hwmod_class, .clkdm_name = "tesla_clkdm", + .flags = HWMOD_INIT_NO_RESET, .mpu_irqs = omap44xx_dsp_irqs, .rst_lines = omap44xx_dsp_resets, .rst_lines_cnt = ARRAY_SIZE(omap44xx_dsp_resets),
Signature · 1 line
1.7.4.1
PATCH v3 4/4 ARM: OMAP3+: add prcm chain interrupts to the interrupt list
In reply to Tero KristoCurrently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled from kernel config, however enabling this option breaks the OMAP kernel completely and it can't be used. Thus, OMAP_PRCM_IRQ_BASE was added to the end of the irq list, and the prm_common code was changed to use this instead of irq_desc allocation scheme.
Once SPARSE_IRQ is enabled for OMAP kernel, this patch can be reverted.
--- arch/arm/mach-omap2/prm_common.c | 14 +------------- arch/arm/plat-omap/include/plat/irqs.h | 6 +++++- 2 files changed, 6 insertions(+), 14 deletions(-)
arch/arm/mach-omap2/prm_common.c +1 -13
@@ -196,11 +196,6 @@ void omap_prcm_irq_cleanup(void) prcm_irq_setup->priority_mask =NULL ;irq_set_chained_handler (prcm_irq_setup->irq,NULL ); - -if (prcm_irq_setup->base_irq >0 ) -irq_free_descs (prcm_irq_setup->base_irq, - prcm_irq_setup->nr_regs *32 ); - prcm_irq_setup->base_irq =0 ; }void omap_prcm_irq_prepare (void )
@@ -282,14 +277,7 @@ int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)irq_set_chained_handler (irq_setup->irq, omap_prcm_irq_handler); - irq_setup->base_irq =irq_alloc_descs (-1 ,0 , irq_setup->nr_regs *32 , -0 ); - -if (irq_setup->base_irq <0 ) { -pr_err ("PRCM: failed to allocate irq descs: %d\n" , - irq_setup->base_irq); - goto err; - } + irq_setup->base_irq =OMAP_PRCM_IRQ_BASE ;for (i =0 ; i <= irq_setup->nr_regs; i++) { gc = irq_alloc_generic_chip("PRCM", 1,
arch/arm/plat-omap/include/plat/irqs.h +5 -1
@@ -428,8 +428,12 @@#define OMAP_GPMC_NR_IRQS 8#define OMAP_GPMC_IRQ_END (OMAP_GPMC_IRQ_BASE + OMAP_GPMC_NR_IRQS) +/* PRCM chain handler */ +#define OMAP_PRCM_IRQ_BASE (OMAP_GPMC_IRQ_END) +#define OMAP_PRCM_NR_IRQS 64 +#define OMAP_PRCM_IRQ_END (OMAP_PRCM_IRQ_BASE + OMAP_PRCM_NR_IRQS) -#define NR_IRQS OMAP_GPMC_IRQ_END +#define NR_IRQS OMAP_PRCM_IRQ_END#define OMAP_IRQ_BIT (irq) (1 << ((irq) % 32))
Signature · 1 line
1.7.4.1
PATCH v3 4/4 ARM: OMAP3+: add prcm chain interrupts to the interrupt list
Quoted 7 lines · Tero Kristo
Currently PRCM chain handler for OMAP4 requires
SPARSE_IRQto be enabled from kernel config, however enabling this option breaks the OMAP kernel completely and it can't be used. Thus,OMAP_PRCM_IRQ_BASEwas added to the end of the irq list, and theprm_commoncode was changed to use this instead ofirq_descallocation scheme.Once
SPARSE_IRQis enabled for OMAP kernel, this patch can be reverted.
Do you still need this, despite this fix from Benoit?
http://marc.info/?l=linux-arm-kernel&m=133043468329275&w=2
Quoted 58 lines
Signed-off-by Tero Kristo<[email protected]>Cc Paul Walmsley<[email protected]>--- arch/arm/mach-omap2/prm_common.c | 14 +------------- arch/arm/plat-omap/include/plat/irqs.h | 6 +++++- 2 files changed, 6 insertions(+), 14 deletions(-)arch/arm/mach-omap2/prm_common.c +1
-13@@ -196,11 +196,6 @@ void omap_prcm_irq_cleanup(void) prcm_irq_setup->priority_mask =NULL ;irq_set_chained_handler (prcm_irq_setup->irq,NULL ); - -if (prcm_irq_setup->base_irq>0 ) -irq_free_descs (prcm_irq_setup->base_irq, - prcm_irq_setup->nr_regs *32 ); - prcm_irq_setup->base_irq =0 ; }void omap_prcm_irq_prepare (void )@@ -282,14 +277,7 @@ int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)irq_set_chained_handler (irq_setup->irq, omap_prcm_irq_handler); - irq_setup->base_irq =irq_alloc_descs (-1 ,0 , irq_setup->nr_regs *32 , -0 ); - -if (irq_setup->base_irq<0 ) { -pr_err ("PRCM: failed to allocate irq descs: %d\n" , - irq_setup->base_irq); - goto err; - } + irq_setup->base_irq =OMAP_PRCM_IRQ_BASE ;for (i =0 ; i<= irq_setup->nr_regs; i++) { gc = irq_alloc_generic_chip("PRCM", 1,arch/arm/plat-omap/include/plat/irqs.h +5
-1@@ -428,8 +428,12 @@#define OMAP_GPMC_NR_IRQS 8#define OMAP_GPMC_IRQ_END (OMAP_GPMC_IRQ_BASE + OMAP_GPMC_NR_IRQS) +/* PRCM chain handler */ +#define OMAP_PRCM_IRQ_BASE (OMAP_GPMC_IRQ_END) +#define OMAP_PRCM_NR_IRQS 64 +#define OMAP_PRCM_IRQ_END (OMAP_PRCM_IRQ_BASE + OMAP_PRCM_NR_IRQS) -#define NR_IRQS OMAP_GPMC_IRQ_END +#define NR_IRQS OMAP_PRCM_IRQ_END#define OMAP_IRQ_BIT (irq) (1<< ((irq) % 32))
PATCH v3 4/4 ARM: OMAP3+: add prcm chain interrupts to the interrupt list
Quoted 11 lines · Rajendra Nayak
Quoted 7 lines · Tero Kristo
Currently PRCM chain handler for OMAP4 requires
SPARSE_IRQto be enabled from kernel config, however enabling this option breaks the OMAP kernel completely and it can't be used. Thus,OMAP_PRCM_IRQ_BASEwas added to the end of the irq list, and theprm_commoncode was changed to use this instead ofirq_descallocation scheme.Once
SPARSE_IRQis enabled for OMAP kernel, this patch can be reverted.Do you still need this, despite this fix from Benoit?
http://marc.info/?l=linux-arm-kernel&m=133043468329275&w=2
Not sure, I haven't tested that yet.
-Tero
Quoted 60 lines
Quoted 59 lines
Signed-off-by Tero Kristo<[email protected]>Cc Paul Walmsley<[email protected]>--- arch/arm/mach-omap2/prm_common.c | 14 +------------- arch/arm/plat-omap/include/plat/irqs.h | 6 +++++- 2 files changed, 6 insertions(+), 14 deletions(-)arch/arm/mach-omap2/prm_common.c +1
-13@@ -196,11 +196,6 @@ void omap_prcm_irq_cleanup(void) prcm_irq_setup->priority_mask =NULL ;irq_set_chained_handler (prcm_irq_setup->irq,NULL ); - -if (prcm_irq_setup->base_irq>0 ) -irq_free_descs (prcm_irq_setup->base_irq, - prcm_irq_setup->nr_regs *32 ); - prcm_irq_setup->base_irq =0 ; }void omap_prcm_irq_prepare (void )@@ -282,14 +277,7 @@ int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)irq_set_chained_handler (irq_setup->irq, omap_prcm_irq_handler); - irq_setup->base_irq =irq_alloc_descs (-1 ,0 , irq_setup->nr_regs *32 , -0 ); - -if (irq_setup->base_irq<0 ) { -pr_err ("PRCM: failed to allocate irq descs: %d\n" , - irq_setup->base_irq); - goto err; - } + irq_setup->base_irq =OMAP_PRCM_IRQ_BASE ;for (i =0 ; i<= irq_setup->nr_regs; i++) { gc = irq_alloc_generic_chip("PRCM", 1,arch/arm/plat-omap/include/plat/irqs.h +5
-1@@ -428,8 +428,12 @@#define OMAP_GPMC_NR_IRQS 8#define OMAP_GPMC_IRQ_END (OMAP_GPMC_IRQ_BASE + OMAP_GPMC_NR_IRQS) +/* PRCM chain handler */ +#define OMAP_PRCM_IRQ_BASE (OMAP_GPMC_IRQ_END) +#define OMAP_PRCM_NR_IRQS 64 +#define OMAP_PRCM_IRQ_END (OMAP_PRCM_IRQ_BASE + OMAP_PRCM_NR_IRQS) -#define NR_IRQS OMAP_GPMC_IRQ_END +#define NR_IRQS OMAP_PRCM_IRQ_END#define OMAP_IRQ_BIT (irq) (1<< ((irq) % 32))
PATCH v3 4/4 ARM: OMAP3+: add prcm chain interrupts to the interrupt list
In reply to Tero KristoQuoted 3 lines · Tero Kristo
Currently PRCM chain handler for OMAP4 requires
SPARSE_IRQto be enabled from kernel config, however enabling this option breaks the OMAP kernel completely and it can't be used.
No it does not. Look:
irq_alloc_descs(start, from, num, -1)
will allocate num interrupt descriptors from within from..NR_IRQS if sparse IRQ is disabled. So, provided there is sufficient space within the available NR_IRQS, irq_alloc_descs() works for non-sparse IRQ. There is no need to get rid of it at all.
If start is -1, then it will allocate from where-ever it can in the range from..NR_IRQS. Otherwise, it will fail if it can't get an allocation starting at 'start'.
If sparse IRQ is enabled, then it will start allocating from whatever the last figure output from the:
NR_IRQS:%d nr_irqs:%d %d
line.
PATCH v3 4/4 ARM: OMAP3+: add prcm chain interrupts to the interrupt list
Quoted 18 lines · Russell King - ARM Linux
Quoted 3 lines · Tero Kristo
Currently PRCM chain handler for OMAP4 requires
SPARSE_IRQto be enabled from kernel config, however enabling this option breaks the OMAP kernel completely and it can't be used.No it does not. Look:
irq_alloc_descs(start, from, num, -1)will allocate num interrupt descriptors from within from..NR_IRQS if sparse IRQ is disabled. So, provided there is sufficient space within the available
NR_IRQS,irq_alloc_descs()works for non-sparse IRQ. There is no need to get rid of it at all.If start is -1, then it will allocate from where-ever it can in the range from..NR_IRQS. Otherwise, it will fail if it can't get an allocation starting at 'start'.
Quoted 6 lines
If sparse IRQ is enabled, then it will start allocating from whatever the last figure output from the:
NR_IRQS:%d nr_irqs:%d %dline.
With the patch from Benoit
(http://marc.info/?l=linux-arm-kernel&m=133043468329275&w=2) this patch is no longer needed. Previously the NR_IRQS definition was too small for omap4 and the alloc_descs was failing because of that. It seems I overshoot with this patch of mine and dropped also the irq_alloc_desc implementation while fixing the problem.
-Tero
v3 cover ARM: OMAP4: core retention support
In reply to Tero KristoQuoted 4 lines · Tero Kristo
Hi,
Changes compared to previous version:
Quoted 8 lines
- split out the
io_chainset as a separate set
- marked patch 3 as TEMP, this is only needed until Paul's pwrdm fixes ?get merged (http://marc.info/?l=linux-omap&m=133040749621183&w=2)Depends on the
io_chainset to provide wakeup capability from retention.Tested with omap4430 blaze : suspend / resume works okay.
Thanks for fixing answering the comments on last version. For entire series you can add