Hi Benoît, Vishwanath, Thanks for the info, Benoît. On Fri, 11 Dec 2009, Cousson, Benoit wrote: > >From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > >owner@xxxxxxxxxxxxxxx] On Behalf Of Paul Walmsley > >Sent: Thursday, December 10, 2009 10:24 PM > > > >Hi Vishwanath, > > > >On Tue, 1 Dec 2009, Sripathy, Vishwanath wrote: > > > >> > > Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 > > -----Original Message----- > > >> > From: Paul Walmsley [mailto:paul@xxxxxxxxx] > >> > Sent: Monday, November 30, 2009 3:00 PM > >> > To: Sripathy, Vishwanath > >> > Cc: ext-ari.kauppi@xxxxxxxxx; linux-omap@xxxxxxxxxxxxxxx; Woodruff, > >Richard; > >> > Menon, Nishanth > >> > Subject: Re: [PATCHV2 1/4] OMAP3: introduce DPLL4 Jtype > >> > > >> > Hello Vishwanath, > >> > > >> > a few comments: > >> > > >> > On Thu, 26 Nov 2009, Vishwanath BS wrote: > >> > > >> > > From: Richard Woodruff <r-woodruff2@xxxxxx> > >> > > > >> > > DPLL4 for 3630 introduces a changed block requiring special divisor > >bits and > >> > > additional reg fields. To allow for silicons to use this, this is > >introduced > >> > > as a omap3_has_jtype_dpll4() and is enabled for 3630 silicon > >> > > > >> > > Tested with 3630 ZOOM3 > >> > > >> > Could you please consider Ari Kauppi's suggestions that he posted on > >> > 30 and 31 October? They look good to me. Here is a link: > >> > > >> Regarding comments from Ari Kauppi on addition of dco_sel_mask and > >> sd_div_mask, yes I had a look at them. However I feel, it's better to > >> have these masks in the structure variable. Reason being this approach > >> will help us to support when dpll types for other dplls get changed in > >> future. For example, if dpll3 block is changed, then having new mask > >> will help us to support it. > > > >Is there a product coming out that will add more j-type DPLLs with > >different dco_sel_masks and sd_div_masks? If not, then let's go with > >Ari's suggested changes, since we don't really know if any more of these > >j-type DPLLs will be used. We can always add the fields back in when we > >need them. But if you know for sure that there is a chip variant coming > >out soon that will use more j-type DPLLs, let's talk about it. > > OMAP4 is using the same J-type for the DPLL_USB. The programming model > is "almost" the same... sd_div is a the same location, but dco_sel is > not there anymore because that DPLL will always be locked at 960MHz and > thus will not require the mode for frequency > 1GHz. At the DCO > location, we have the bypass_clksel, so the code will have to take care > of that. > > 31:24 DPLL_SD_DIV > 23 DPLL_BYP_CLKSEL > 19:8 DPLL_MULT > 7:0 DPLL_DIV Vishwanath, it sounds like it makes sense to hardcode the DPLL_SD_DIV and DCO_SEL shifts, since, so far, when present, they are always at the same offset. Instead of using a 'u8 jtype;' it seems to make sense to have a 'u8 flags' and have at least two flags there: DPLL_J_TYPE and DPLL_NO_DCO_SEL. (The latter flag would skip any DCO_SEL reads/writes for J-type DPLLs if it is set, so it will be usable for OMAP4. The code should also warn if DPLL_NO_DCO_SEL is set and DPLL_J_TYPE is not set.) Sound reasonable? - Paul
