> -----Original Message----- > From: Paul Walmsley [mailto:paul@xxxxxxxxx] > Sent: Tuesday, December 15, 2009 12:38 PM > To: Cousson, Benoit > Cc: Sripathy, Vishwanath; Nayak, Rajendra; ext-ari.kauppi@xxxxxxxxx; linux- > omap@xxxxxxxxxxxxxxx; Woodruff, Richard; Menon, Nishanth > Subject: RE: [PATCHV2 1/4] OMAP3: introduce DPLL4 Jtype > > 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? > > Make sense. I will post new set of patches after incorporating all these. Thanks. > - Paul -- 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
