From: ext Paul Walmsley <paul@xxxxxxxxx> Subject: Re: [PATCH] OMAP3: mailbox initialization for all omap versions Date: Thu, 1 Apr 2010 14:33:22 +0200 > Hi Hiroshi, > > On Thu, 1 Apr 2010, Hiroshi DOYU wrote: > >> From: Hiroshi DOYU <Hiroshi.DOYU@xxxxxxxxx> >> Subject: Re: [PATCH] OMAP3: mailbox initialization for all omap versions >> Date: Thu, 01 Apr 2010 13:23:36 +0300 (EEST) >> >> > From: ext Tony Lindgren <tony@xxxxxxxxxxx> >> > Subject: Re: [PATCH] OMAP3: mailbox initialization for all omap versions >> > Date: Thu, 1 Apr 2010 11:52:04 +0200 >> > >> >> * Hiroshi DOYU <Hiroshi.DOYU@xxxxxxxxx> [100329 02:05]: >> >>> From: "Balbi Felipe (Nokia-D/Helsinki)" <felipe.balbi@xxxxxxxxx> >> >>> Subject: Re: [PATCH] OMAP3: mailbox initialization for all omap versions >> >>> Date: Mon, 29 Mar 2010 09:01:45 +0200 >> >>> > >> >>> > in that case, wouldn't it be better to split that into >> >>> > arch/arm/omap1/mbox.c arch/arm/omap2/mbox24xx.c >> >>> > arch/arm/omap2/mbox34xx.c arch/arm/omap2/mbox44xx.c ?? >> >>> > >> >>> > that way we don't need ifdefs on the code and we will only compile what >> >>> > we really need. >> >>> >> >>> This is feasible. >> >>> But I'm not so sure whether adding 4 new files with around only 10 >> >>> lines code is acceptable or not. >> >>> >> >>> Tony, any comment on the above? >> >>> >> >>> Basically there could be the case we need all resources if we want to >> >>> support omap1, 2, 3 and 4 at the same time, and the appropriate one >> >>> will be chosen at run time by CPUID. I'm not sure how mature "omap >> >>> multi arch" support is practically, but it's better to keep it as much >> >>> as possbile. >> >> >> >> I like Felipe's suggestion of adding devices2420.c, devices34xx.c, >> >> devices44xx.c or similar. Then do the device init from those with >> >> a arch_initcall that returns immediately if not running on the right >> >> soc. >> > >> > Ok, let's procced with this. I'll post something later. >> > >> >> Something like the following? > > Is it possible to try a hwmod conversion of this? Similar to the UART, > HSMMC, etc. work that Kevin has queued in his pm-wip/hwmods branch: I haven't followed this, but this looks more decriptive. I'll try. -- 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
