Hello Kevin, > -----Original Message----- > From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] > Sent: Thursday, November 12, 2009 3:13 AM > To: Lohithakshan, Ranjith > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: Re: [PATCH] AM35xx: Clock table updates for AM3505/17 > > Ranjith Lohithakshan <ranjithl@xxxxxx> writes: > > > AM3505/17 though a OMAP3530 derivative have the following > > main differences > > > > - Removal of the following OMAP3 modules > > - IVA > > - ISP/CAM > > - Modem and D2D components (MAD2D, SAD2D) > > - USIM > > - SSI > > - Mailboxes > > - USB OTG > > - ICR > > - MSPRO > > - SmartReflex > > - SDRC replaced with EMIF4 Controller in the SDRC subsystem > > thus adding support for DDR2 memory devices > > - Addition of the following new modules > > - Ethernet MAC (CPGMAC) > > - CAN Controller (HECC) > > - New USB OTG Controller with integrated Phy > > - Video Processing Front End (VPFE) > > - Additional UART (UART4) > > - All security accelerators disabled on GP devices and not to > > be accessed or configured > > > > This patch defines CPU flags for AM3505/17 and update the > clock table. > > Clock support for new modules will be added by subsequent patches. > > > > Signed-off-by: Ranjith Lohithakshan <ranjithl@xxxxxx> > > A question on the approach here, as I'm wondering if this approach is > really needed. > > Rather than handling these details in the clock tree, why not handle > the special cases using the feature checks: omap_has_*(). > The differences (mainly removals) are many and too unique to AM3517/05. As per the chip spec, the clock related registers for the removed modules are not to be programmed and we need a way to prevent these clocks getting registered from the existing table (even if they are not enabled or used later). In my opinion, if we define feature macros for modules like (MSPRO, USIM,Mailbox etc) they will be too specific for the AM35xx use. Taking these aspects into consideration, I feel tha defining CK_35XX flags and using it in clock table appear to be better. Ranjith-- 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
