> -----Original Message----- > From: Peter Ujfalusi [mailto:peter.ujfalusi@xxxxxxxxx] > Sent: Wednesday, October 06, 2010 11:32 AM > To: ABRAHAM, KISHON VIJAY > Cc: linux-omap@xxxxxxxxxxxxxxx; Kamat, Nishant; Varadarajan, > Charulatha; Datta, Shubhrajyoti; Basak, Partha > Subject: Re: [PATCH 4/7] [RFC] OMAP: hwmod implementation for MCBSP > > On Tuesday 05 October 2010 19:37:39 ext Kishon Vijay Abraham I wrote: > > Signed-off-by: Kishon Vijay Abraham I <kishon@xxxxxx> > > Signed-off-by: Charulatha V <charu@xxxxxx> > > Signed-off-by: Shubhrajyoti D <shubhrajyoti@xxxxxx> > > Cc: Partha Basak <p-basak2@xxxxxx> > > --- > > arch/arm/mach-omap2/mcbsp.c | 251 > > +++++++++---------------------- > arch/arm/plat-omap/include/plat/mcbsp.h | > > 6 +- > > arch/arm/plat-omap/mcbsp.c | 189 > +++++++++++------------- > > 3 files changed, 159 insertions(+), 287 deletions(-) > > So the plan is to kill OMAP1 support in McBSP (audio)? > We do have OMAP1 users, so IMHO dropping OMAP1 is not acceptable. This patch series would not break OMAP1 as they do not touch the omap_mcbsp_register_board_cfg() in mach-omap1. Usage of hwmod is applicable only for OMAP2plus cpus and it modifies the way in which the platform device is built & registered. It makes use of centralised database to fetch the addresses, irq, dma info etc., for OMAP2plus. OMAP1 cpus will still continue to have the old way of doing platform device registeration. pm_runtime APIs are already inplace to take care of enabling clocks in case of OMAP1. Hope this clarifies. > > -- > Péter > -- 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
