diff for duplicates of <4EC6566C.70202@ti.com> diff --git a/a/1.txt b/N1/1.txt index ef83705..9dff7e2 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -30,7 +30,7 @@ On 11/10/2011 10:02 AM, Paul Walmsley wrote: > Okay. Maybe you can probably add some code in mach-omap2/devices.c to > build an omap_device for this for right now? I am not 100% sure whether > those cti0/1 interrupts should be associated with the MPU or with the -> DEBUGSS but Benoît might be able to answer this. +> DEBUGSS but Beno?t might be able to answer this. > >> Also, current arm perf code don't handle three IRQs(one pl310 irq and >> two CTI irq) inside one device correctly. @@ -62,7 +62,7 @@ On 11/10/2011 10:02 AM, Paul Walmsley wrote: > mach-omap2/clockdomains44xx_data.c and there's code to control it - see > for example clkdm_enable_idle(). But this code should not be called > directly by any device driver code or driver integration code. The thing -> to do here is to ask Benoît to release the hwmod data for the DEBUGSS +> to do here is to ask Beno?t to release the hwmod data for the DEBUGSS > hwmod, then someone will need to write an MFD driver for that which > exposes the PMU address space to the PMU platform driver. @@ -331,8 +331,3 @@ index 7695e5d..6cf21ee 100644 -- 1.7.0.4 - --- -To unsubscribe from this list: send the line "unsubscribe linux-omap" in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 115a8aa..2c00f2e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,17 +3,10 @@ "ref\0alpine.DEB.2.00.1111080750130.10451@utopia.booyaka.com\0" "ref\0CACVXFVMSJUT2Ac+bWetrLpbyOs6PqY+npNHsbvHipEVZ0gWdgQ@mail.gmail.com\0" "ref\0alpine.DEB.2.00.1111100152430.4195@utopia.booyaka.com\0" - "From\0Cousson, Benoit <b-cousson@ti.com>\0" - "Subject\0Re: [PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod\0" + "From\0b-cousson@ti.com (Cousson, Benoit)\0" + "Subject\0[PATCH v5 4/7] arm: omap4: hwmod: introduce emu hwmod\0" "Date\0Fri, 18 Nov 2011 13:58:20 +0100\0" - "To\0Ming Lei <ming.lei@canonical.com>\0" - "Cc\0Paul Walmsley <paul@pwsan.com>" - linux@arm.linux.org.uk - will.deacon@arm.com - tony@atomide.com - linux-arm-kernel@lists.infradead.org - linux-omap@vger.kernel.org - " khilman@deeprootsystems.com\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "Hi Ming Lei,\n" @@ -48,7 +41,7 @@ "> Okay. Maybe you can probably add some code in mach-omap2/devices.c to\n" "> build an omap_device for this for right now? I am not 100% sure whether\n" "> those cti0/1 interrupts should be associated with the MPU or with the\n" - "> DEBUGSS but Beno\303\256t might be able to answer this.\n" + "> DEBUGSS but Beno?t might be able to answer this.\n" "> \n" ">> Also, current arm perf code don't handle three IRQs(one pl310 irq and\n" ">> two CTI irq) inside one device correctly.\n" @@ -80,7 +73,7 @@ "> mach-omap2/clockdomains44xx_data.c and there's code to control it - see\n" "> for example clkdm_enable_idle(). But this code should not be called\n" "> directly by any device driver code or driver integration code. The thing\n" - "> to do here is to ask Beno\303\256t to release the hwmod data for the DEBUGSS\n" + "> to do here is to ask Beno?t to release the hwmod data for the DEBUGSS\n" "> hwmod, then someone will need to write an MFD driver for that which\n" "> exposes the PMU address space to the PMU platform driver.\n" "\n" @@ -348,11 +341,6 @@ " \t&omap44xx_dma_system_hwmod,\n" " \n" "-- \n" - "1.7.0.4\n" - "\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-omap\" in\n" - "the body of a message to majordomo@vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + 1.7.0.4 -74aa5ec876158204d3edc2c3b2029f711327508a513ed96ba71a6b8203f86bd3 +30f9d541e2a5e99eae490fc97e5e1de02f2167c2fd802f3b9007c570c7ee027a
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.