On Wed, Dec 2, 2009 at 3:19 PM, Premi, Sanjeev <premi@xxxxxx> wrote: >> -----Original Message----- >> From: Sergey Lapin [mailto:slapinid@xxxxxxxxx] >> Sent: Wednesday, December 02, 2009 5:35 PM >> To: Premi, Sanjeev >> Cc: linux-omap@xxxxxxxxxxxxxxx >> Subject: Re: SR1: VDD autocomp is not active >> >> Hi, all! It seems discussion went off-list somehow, so I won't delete >> some quoting. >> >> On Wed, Dec 2, 2009 at 2:38 PM, Premi, Sanjeev <premi@xxxxxx> wrote: >> >> -----Original Message----- >> >> From: Sergey Lapin [mailto:slapinid@xxxxxxxxx] >> >> Sent: Wednesday, December 02, 2009 1:54 AM >> >> To: Premi, Sanjeev >> >> Subject: Re: SR1: VDD autocomp is not active >> >> >> >> > I did notice an earlier mail where you mentioned about >> >> using an older >> >> > kernel version. have to back-ported patches specific to silicon >> >> > identification on this kernel/ >> >> I use PM branch of linux-omap git. >> >> I just need to make my patches less disgusting by properly >> >> porting these. >> >> Actually now I think I could do this work even without >> >> appropriate tree, since >> >> amount of patches is not that big and API is not too >> different. These >> >> patches are >> >> not required to make board basically run. >> >> >> >> > >> >> > It appears that efuse data required for SmartReflex to >> work may not >> >> > be available on this silicon... leading to these messages. >> >> > >> >> > Right now, I am away from source code, will be able to >> verify in the >> >> > morning. >> >> Thanks, looking forward for your reply. >> > >> > You should try this with an ES3.1 silicon. If sr_enable() >> fails, we might >> > see this issue. >> It seems I only have ES2.1 silicon, so what should I do >> - disable SR functionality at all > [sp] Yes. It will be a good starting point. > >> - somehow set values the other way? > [sp] It will be difficult for you to ascertain these values. > >> It seems SR is possible on this silicon, only efuse data are absent, >> so is there a way I could somehow fake these (with some known >> working values), >> so the stuff works? > > [sp] The code will allow you to do so; but without right values > kernel execution can go haywire. Is it possible somehow to identify right silicon revision before ordering? I mean by part number or something? Also, is there some safe numbers somebody knows about, or is there some way of generating them? S. -- 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
