On Tue, Apr 3, 2012 at 2:55 PM, Will Deacon <will.deacon@xxxxxxx> wrote:
> Santosh,
>
> On Wed, Jan 18, 2012 at 12:33:23PM +0000, Shilimkar, Santosh wrote:
>> On Wed, Jan 18, 2012 at 1:24 PM, Ming Lei <ming.lei@xxxxxxxxxxxxx> wrote:
>> >>> diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
>> >>> b/arch/arm/mach-omap2/clockdomains44xx_data.c
>> >>> index 9299ac2..41d2260 100644
>> >>> --- a/arch/arm/mach-omap2/clockdomains44xx_data.c
>> >>> +++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
>> >>> @@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = {
>> >>> .prcm_partition = OMAP4430_PRM_PARTITION,
>> >>> .cm_inst = OMAP4430_PRM_EMU_CM_INST,
>> >>> .clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS,
>> >>> - .flags = CLKDM_CAN_HWSUP,
>> >>> + .flags = CLKDM_CAN_SWSUP,
>> >>> };
>> >> NAK.
>> >>
>> >> You don't need this patch. What you saw on CAMERA was indeed
>> >> a known bug but emulation domain has no such issues.
>> >>
>> >> So the accesses to emulation register should continue to work
>> >> with the clock-domain being kept under hardware supervision.
>> >
>> > But why can this patch make omap4 pmu work? Without the patch,
>> > there are no CTI interrupts generated for pmu irq.
>> >
>> Interesting. For me debugger works which also relies on Emulation domain.
>>
>> Need to see why CTI is behaving like this.
>
> Did you ever get to the bottom of this? This change really is required in
> order to generate PMU interrupts with the CTI and I don't know of any
> alternative to the above.
>
> Any suggestions?
>
Sorry I lost track of this one. There is one relevant patch in Kevin's queue
for 3.4/fixes. [1] which I generated for perf time stamp issue.
Can you try that patch and see if it helps the CTI issue as well ? There
is an outside chance that it might help. If it doesn't, we should commit
Ming Lei patch.
Regards
Santosh
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/089679.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
