| Message ID | 1281424059-24347-2-git-send-email-bryan.wu@canonical.com |
|---|---|
| State | Accepted |
| Delegated to: | Stefan Bader |
| Headers | show |
On 08/10/2010 12:07 AM, Bryan Wu wrote: > From: Shen Yong<b00984@freescale.com> > > switch low power mode will cause problems on previous version of > mc13892, which may break mc13892 chip. > This is a fix for ENGR00120510. > > BugLink: http://bugs.launchpad.net/bugs/615722 > > Signed-off-by: Shen Yong<b00984@freescale.com> > Signed-off-by: Bryan Wu<bryan.wu@canonical.com> > --- > arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c | 30 +++++++++++++++-------- > 1 files changed, 19 insertions(+), 11 deletions(-) > > diff --git a/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c b/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c > index e8a03cf..13869d0 100644 > --- a/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c > +++ b/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c > @@ -346,17 +346,25 @@ static int mc13892_regulator_init(struct mc13892 *mc13892) > pmic_write_reg(REG_MODE_1, value, 0xffffff); > > /* enable switch audo mode */ > - pmic_read_reg(REG_SW_4,&value, 0xffffff); > - register_mask = (SWMODE_MASK<< SW1MODE_LSB) | (SWMODE_MASK<< SW2MODE_LSB); > - value&= ~register_mask; > - value |= (SWMODE_AUTO<< SW1MODE_LSB) | (SWMODE_AUTO<< SW2MODE_LSB); > - pmic_write_reg(REG_SW_4, value, 0xffffff); > - > - pmic_read_reg(REG_SW_5,&value, 0xffffff); > - register_mask = (SWMODE_MASK<< SW3MODE_LSB) | (SWMODE_MASK<< SW4MODE_LSB); > - value&= ~register_mask; > - value |= (SWMODE_AUTO<< SW3MODE_LSB) | (SWMODE_AUTO<< SW4MODE_LSB); > - pmic_write_reg(REG_SW_5, value, 0xffffff); > + pmic_read_reg(REG_IDENTIFICATION,&value, 0xffffff); > + /* only for mc13892 2.0A */ > + if ((value& 0x0000FFFF) == 0x45d0) { > + pmic_read_reg(REG_SW_4,&value, 0xffffff); > + register_mask = (SWMODE_MASK<< SW1MODE_LSB) | > + (SWMODE_MASK<< SW2MODE_LSB); > + value&= ~register_mask; > + value |= (SWMODE_AUTO<< SW1MODE_LSB) | > + (SWMODE_AUTO<< SW2MODE_LSB); > + pmic_write_reg(REG_SW_4, value, 0xffffff); > + > + pmic_read_reg(REG_SW_5,&value, 0xffffff); > + register_mask = (SWMODE_MASK<< SW3MODE_LSB) | > + (SWMODE_MASK<< SW4MODE_LSB); > + value&= ~register_mask; > + value |= (SWMODE_AUTO<< SW3MODE_LSB) | > + (SWMODE_AUTO<< SW4MODE_LSB); > + pmic_write_reg(REG_SW_5, value, 0xffffff); > + } > > /* Enable coin cell charger */ > value = BITFVAL(CIONCHEN, 1) | BITFVAL(VCOIN, VCOIN_3_0V); Bryan, Do you have positive test results from testing this patch? We want to make sure this patch fixes the issue that we have been seeing. Brad
On 08/10/2010 11:36 PM, Brad Figg wrote: > On 08/10/2010 12:07 AM, Bryan Wu wrote: >> From: Shen Yong<b00984@freescale.com> >> >> switch low power mode will cause problems on previous version of >> mc13892, which may break mc13892 chip. >> This is a fix for ENGR00120510. >> >> BugLink: http://bugs.launchpad.net/bugs/615722 >> >> Signed-off-by: Shen Yong<b00984@freescale.com> >> Signed-off-by: Bryan Wu<bryan.wu@canonical.com> >> --- >> arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c | 30 +++++++++++++++-------- >> 1 files changed, 19 insertions(+), 11 deletions(-) >> >> diff --git a/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c b/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >> index e8a03cf..13869d0 100644 >> --- a/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >> +++ b/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >> @@ -346,17 +346,25 @@ static int mc13892_regulator_init(struct mc13892 *mc13892) >> pmic_write_reg(REG_MODE_1, value, 0xffffff); >> >> /* enable switch audo mode */ >> - pmic_read_reg(REG_SW_4,&value, 0xffffff); >> - register_mask = (SWMODE_MASK<< SW1MODE_LSB) | (SWMODE_MASK<< SW2MODE_LSB); >> - value&= ~register_mask; >> - value |= (SWMODE_AUTO<< SW1MODE_LSB) | (SWMODE_AUTO<< SW2MODE_LSB); >> - pmic_write_reg(REG_SW_4, value, 0xffffff); >> - >> - pmic_read_reg(REG_SW_5,&value, 0xffffff); >> - register_mask = (SWMODE_MASK<< SW3MODE_LSB) | (SWMODE_MASK<< SW4MODE_LSB); >> - value&= ~register_mask; >> - value |= (SWMODE_AUTO<< SW3MODE_LSB) | (SWMODE_AUTO<< SW4MODE_LSB); >> - pmic_write_reg(REG_SW_5, value, 0xffffff); >> + pmic_read_reg(REG_IDENTIFICATION,&value, 0xffffff); >> + /* only for mc13892 2.0A */ >> + if ((value& 0x0000FFFF) == 0x45d0) { >> + pmic_read_reg(REG_SW_4,&value, 0xffffff); >> + register_mask = (SWMODE_MASK<< SW1MODE_LSB) | >> + (SWMODE_MASK<< SW2MODE_LSB); >> + value&= ~register_mask; >> + value |= (SWMODE_AUTO<< SW1MODE_LSB) | >> + (SWMODE_AUTO<< SW2MODE_LSB); >> + pmic_write_reg(REG_SW_4, value, 0xffffff); >> + >> + pmic_read_reg(REG_SW_5,&value, 0xffffff); >> + register_mask = (SWMODE_MASK<< SW3MODE_LSB) | >> + (SWMODE_MASK<< SW4MODE_LSB); >> + value&= ~register_mask; >> + value |= (SWMODE_AUTO<< SW3MODE_LSB) | >> + (SWMODE_AUTO<< SW4MODE_LSB); >> + pmic_write_reg(REG_SW_5, value, 0xffffff); >> + } >> >> /* Enable coin cell charger */ >> value = BITFVAL(CIONCHEN, 1) | BITFVAL(VCOIN, VCOIN_3_0V); > > Bryan, > > Do you have positive test results from testing this patch? We want to make sure > this patch fixes the issue that we have been seeing. > Brad, Yeah, it can be confirmed by Ranjani from Freescale. I copied him in this email thread. Thanks,
On 08/11/2010 12:41 PM, Bryan Wu wrote: > On 08/10/2010 11:36 PM, Brad Figg wrote: >> On 08/10/2010 12:07 AM, Bryan Wu wrote: >>> From: Shen Yong<b00984@freescale.com> >>> >>> switch low power mode will cause problems on previous version of >>> mc13892, which may break mc13892 chip. >>> This is a fix for ENGR00120510. >>> >>> BugLink: http://bugs.launchpad.net/bugs/615722 >>> >>> Signed-off-by: Shen Yong<b00984@freescale.com> >>> Signed-off-by: Bryan Wu<bryan.wu@canonical.com> >>> --- >>> arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c | 30 +++++++++++++++-------- >>> 1 files changed, 19 insertions(+), 11 deletions(-) >>> >>> diff --git a/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c b/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >>> index e8a03cf..13869d0 100644 >>> --- a/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >>> +++ b/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >>> @@ -346,17 +346,25 @@ static int mc13892_regulator_init(struct mc13892 *mc13892) >>> pmic_write_reg(REG_MODE_1, value, 0xffffff); >>> >>> /* enable switch audo mode */ >>> - pmic_read_reg(REG_SW_4,&value, 0xffffff); >>> - register_mask = (SWMODE_MASK<< SW1MODE_LSB) | (SWMODE_MASK<< SW2MODE_LSB); >>> - value&= ~register_mask; >>> - value |= (SWMODE_AUTO<< SW1MODE_LSB) | (SWMODE_AUTO<< SW2MODE_LSB); >>> - pmic_write_reg(REG_SW_4, value, 0xffffff); >>> - >>> - pmic_read_reg(REG_SW_5,&value, 0xffffff); >>> - register_mask = (SWMODE_MASK<< SW3MODE_LSB) | (SWMODE_MASK<< SW4MODE_LSB); >>> - value&= ~register_mask; >>> - value |= (SWMODE_AUTO<< SW3MODE_LSB) | (SWMODE_AUTO<< SW4MODE_LSB); >>> - pmic_write_reg(REG_SW_5, value, 0xffffff); >>> + pmic_read_reg(REG_IDENTIFICATION,&value, 0xffffff); >>> + /* only for mc13892 2.0A */ >>> + if ((value& 0x0000FFFF) == 0x45d0) { >>> + pmic_read_reg(REG_SW_4,&value, 0xffffff); >>> + register_mask = (SWMODE_MASK<< SW1MODE_LSB) | >>> + (SWMODE_MASK<< SW2MODE_LSB); >>> + value&= ~register_mask; >>> + value |= (SWMODE_AUTO<< SW1MODE_LSB) | >>> + (SWMODE_AUTO<< SW2MODE_LSB); >>> + pmic_write_reg(REG_SW_4, value, 0xffffff); >>> + >>> + pmic_read_reg(REG_SW_5,&value, 0xffffff); >>> + register_mask = (SWMODE_MASK<< SW3MODE_LSB) | >>> + (SWMODE_MASK<< SW4MODE_LSB); >>> + value&= ~register_mask; >>> + value |= (SWMODE_AUTO<< SW3MODE_LSB) | >>> + (SWMODE_AUTO<< SW4MODE_LSB); >>> + pmic_write_reg(REG_SW_5, value, 0xffffff); >>> + } >>> >>> /* Enable coin cell charger */ >>> value = BITFVAL(CIONCHEN, 1) | BITFVAL(VCOIN, VCOIN_3_0V); >> >> Bryan, >> >> Do you have positive test results from testing this patch? We want to make sure >> this patch fixes the issue that we have been seeing. >> > > Brad, > > Yeah, it can be confirmed by Ranjani from Freescale. I copied him in this email > thread. > > Thanks, OK, so this sounds like we can take it. ACK
On 10 Aug 11, Stefan Bader wrote: > On 08/11/2010 12:41 PM, Bryan Wu wrote: > > On 08/10/2010 11:36 PM, Brad Figg wrote: > >> On 08/10/2010 12:07 AM, Bryan Wu wrote: > >>> From: Shen Yong<b00984@freescale.com> > >>> > >>> switch low power mode will cause problems on previous version of > >>> mc13892, which may break mc13892 chip. > >>> This is a fix for ENGR00120510. > >>> > >>> BugLink: http://bugs.launchpad.net/bugs/615722 > >>> > >>> Signed-off-by: Shen Yong<b00984@freescale.com> > >>> Signed-off-by: Bryan Wu<bryan.wu@canonical.com> > >>> --- > >>> arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c | 30 +++++++++++++++-------- > >>> 1 files changed, 19 insertions(+), 11 deletions(-) > >>> > >>> diff --git a/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c b/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c > >>> index e8a03cf..13869d0 100644 > >>> --- a/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c > >>> +++ b/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c > >>> @@ -346,17 +346,25 @@ static int mc13892_regulator_init(struct mc13892 *mc13892) > >>> pmic_write_reg(REG_MODE_1, value, 0xffffff); > >>> > >>> /* enable switch audo mode */ > >>> - pmic_read_reg(REG_SW_4,&value, 0xffffff); > >>> - register_mask = (SWMODE_MASK<< SW1MODE_LSB) | (SWMODE_MASK<< SW2MODE_LSB); > >>> - value&= ~register_mask; > >>> - value |= (SWMODE_AUTO<< SW1MODE_LSB) | (SWMODE_AUTO<< SW2MODE_LSB); > >>> - pmic_write_reg(REG_SW_4, value, 0xffffff); > >>> - > >>> - pmic_read_reg(REG_SW_5,&value, 0xffffff); > >>> - register_mask = (SWMODE_MASK<< SW3MODE_LSB) | (SWMODE_MASK<< SW4MODE_LSB); > >>> - value&= ~register_mask; > >>> - value |= (SWMODE_AUTO<< SW3MODE_LSB) | (SWMODE_AUTO<< SW4MODE_LSB); > >>> - pmic_write_reg(REG_SW_5, value, 0xffffff); > >>> + pmic_read_reg(REG_IDENTIFICATION,&value, 0xffffff); > >>> + /* only for mc13892 2.0A */ > >>> + if ((value& 0x0000FFFF) == 0x45d0) { > >>> + pmic_read_reg(REG_SW_4,&value, 0xffffff); > >>> + register_mask = (SWMODE_MASK<< SW1MODE_LSB) | > >>> + (SWMODE_MASK<< SW2MODE_LSB); > >>> + value&= ~register_mask; > >>> + value |= (SWMODE_AUTO<< SW1MODE_LSB) | > >>> + (SWMODE_AUTO<< SW2MODE_LSB); > >>> + pmic_write_reg(REG_SW_4, value, 0xffffff); > >>> + > >>> + pmic_read_reg(REG_SW_5,&value, 0xffffff); > >>> + register_mask = (SWMODE_MASK<< SW3MODE_LSB) | > >>> + (SWMODE_MASK<< SW4MODE_LSB); > >>> + value&= ~register_mask; > >>> + value |= (SWMODE_AUTO<< SW3MODE_LSB) | > >>> + (SWMODE_AUTO<< SW4MODE_LSB); > >>> + pmic_write_reg(REG_SW_5, value, 0xffffff); > >>> + } > >>> > >>> /* Enable coin cell charger */ > >>> value = BITFVAL(CIONCHEN, 1) | BITFVAL(VCOIN, VCOIN_3_0V); > >> > >> Bryan, > >> > >> Do you have positive test results from testing this patch? We want to make sure > >> this patch fixes the issue that we have been seeing. > >> > > > > Brad, > > > > Yeah, it can be confirmed by Ranjani from Freescale. I copied him in this email > > thread. > > > > Thanks, > > OK, so this sounds like we can take it. ACK I think Bryan meant we should wait for confirmation from Ranjani. _She_ will confirm if this fix doesn't brick BB2.5. BTW, is there any chance of unbricking bricked BB2.5 (like mine)? /Amit
On 08/11/2010 01:56 PM, Amit Kucheria wrote: > On 10 Aug 11, Stefan Bader wrote: >> On 08/11/2010 12:41 PM, Bryan Wu wrote: >>> On 08/10/2010 11:36 PM, Brad Figg wrote: >>>> On 08/10/2010 12:07 AM, Bryan Wu wrote: >>>>> From: Shen Yong<b00984@freescale.com> >>>>> >>>>> switch low power mode will cause problems on previous version of >>>>> mc13892, which may break mc13892 chip. >>>>> This is a fix for ENGR00120510. >>>>> >>>>> BugLink: http://bugs.launchpad.net/bugs/615722 >>>>> >>>>> Signed-off-by: Shen Yong<b00984@freescale.com> >>>>> Signed-off-by: Bryan Wu<bryan.wu@canonical.com> >>>>> --- >>>>> arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c | 30 +++++++++++++++-------- >>>>> 1 files changed, 19 insertions(+), 11 deletions(-) >>>>> >>>>> diff --git a/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c b/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >>>>> index e8a03cf..13869d0 100644 >>>>> --- a/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >>>>> +++ b/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >>>>> @@ -346,17 +346,25 @@ static int mc13892_regulator_init(struct mc13892 *mc13892) >>>>> pmic_write_reg(REG_MODE_1, value, 0xffffff); >>>>> >>>>> /* enable switch audo mode */ >>>>> - pmic_read_reg(REG_SW_4,&value, 0xffffff); >>>>> - register_mask = (SWMODE_MASK<< SW1MODE_LSB) | (SWMODE_MASK<< SW2MODE_LSB); >>>>> - value&= ~register_mask; >>>>> - value |= (SWMODE_AUTO<< SW1MODE_LSB) | (SWMODE_AUTO<< SW2MODE_LSB); >>>>> - pmic_write_reg(REG_SW_4, value, 0xffffff); >>>>> - >>>>> - pmic_read_reg(REG_SW_5,&value, 0xffffff); >>>>> - register_mask = (SWMODE_MASK<< SW3MODE_LSB) | (SWMODE_MASK<< SW4MODE_LSB); >>>>> - value&= ~register_mask; >>>>> - value |= (SWMODE_AUTO<< SW3MODE_LSB) | (SWMODE_AUTO<< SW4MODE_LSB); >>>>> - pmic_write_reg(REG_SW_5, value, 0xffffff); >>>>> + pmic_read_reg(REG_IDENTIFICATION,&value, 0xffffff); >>>>> + /* only for mc13892 2.0A */ >>>>> + if ((value& 0x0000FFFF) == 0x45d0) { >>>>> + pmic_read_reg(REG_SW_4,&value, 0xffffff); >>>>> + register_mask = (SWMODE_MASK<< SW1MODE_LSB) | >>>>> + (SWMODE_MASK<< SW2MODE_LSB); >>>>> + value&= ~register_mask; >>>>> + value |= (SWMODE_AUTO<< SW1MODE_LSB) | >>>>> + (SWMODE_AUTO<< SW2MODE_LSB); >>>>> + pmic_write_reg(REG_SW_4, value, 0xffffff); >>>>> + >>>>> + pmic_read_reg(REG_SW_5,&value, 0xffffff); >>>>> + register_mask = (SWMODE_MASK<< SW3MODE_LSB) | >>>>> + (SWMODE_MASK<< SW4MODE_LSB); >>>>> + value&= ~register_mask; >>>>> + value |= (SWMODE_AUTO<< SW3MODE_LSB) | >>>>> + (SWMODE_AUTO<< SW4MODE_LSB); >>>>> + pmic_write_reg(REG_SW_5, value, 0xffffff); >>>>> + } >>>>> >>>>> /* Enable coin cell charger */ >>>>> value = BITFVAL(CIONCHEN, 1) | BITFVAL(VCOIN, VCOIN_3_0V); >>>> >>>> Bryan, >>>> >>>> Do you have positive test results from testing this patch? We want to make sure >>>> this patch fixes the issue that we have been seeing. >>>> >>> >>> Brad, >>> >>> Yeah, it can be confirmed by Ranjani from Freescale. I copied him in this email >>> thread. >>> >>> Thanks, >> >> OK, so this sounds like we can take it. ACK > > I think Bryan meant we should wait for confirmation from Ranjani. _She_ will > confirm if this fix doesn't brick BB2.5. > > BTW, is there any chance of unbricking bricked BB2.5 (like mine)? > > /Amit > Ok, then I hold of with that until this has been confirmed. I have an updated tree ready to push and a source package ready for upload here. -Stefan
On 08/11/2010 08:37 PM, Stefan Bader wrote: > On 08/11/2010 01:56 PM, Amit Kucheria wrote: >> On 10 Aug 11, Stefan Bader wrote: >>> On 08/11/2010 12:41 PM, Bryan Wu wrote: >>>> On 08/10/2010 11:36 PM, Brad Figg wrote: >>>>> On 08/10/2010 12:07 AM, Bryan Wu wrote: >>>>>> From: Shen Yong<b00984@freescale.com> >>>>>> >>>>>> switch low power mode will cause problems on previous version of >>>>>> mc13892, which may break mc13892 chip. >>>>>> This is a fix for ENGR00120510. >>>>>> >>>>>> BugLink: http://bugs.launchpad.net/bugs/615722 >>>>>> >>>>>> Signed-off-by: Shen Yong<b00984@freescale.com> >>>>>> Signed-off-by: Bryan Wu<bryan.wu@canonical.com> >>>>>> --- >>>>>> arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c | 30 +++++++++++++++-------- >>>>>> 1 files changed, 19 insertions(+), 11 deletions(-) >>>>>> >>>>>> diff --git a/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c b/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >>>>>> index e8a03cf..13869d0 100644 >>>>>> --- a/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >>>>>> +++ b/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >>>>>> @@ -346,17 +346,25 @@ static int mc13892_regulator_init(struct mc13892 *mc13892) >>>>>> pmic_write_reg(REG_MODE_1, value, 0xffffff); >>>>>> >>>>>> /* enable switch audo mode */ >>>>>> - pmic_read_reg(REG_SW_4,&value, 0xffffff); >>>>>> - register_mask = (SWMODE_MASK<< SW1MODE_LSB) | (SWMODE_MASK<< SW2MODE_LSB); >>>>>> - value&= ~register_mask; >>>>>> - value |= (SWMODE_AUTO<< SW1MODE_LSB) | (SWMODE_AUTO<< SW2MODE_LSB); >>>>>> - pmic_write_reg(REG_SW_4, value, 0xffffff); >>>>>> - >>>>>> - pmic_read_reg(REG_SW_5,&value, 0xffffff); >>>>>> - register_mask = (SWMODE_MASK<< SW3MODE_LSB) | (SWMODE_MASK<< SW4MODE_LSB); >>>>>> - value&= ~register_mask; >>>>>> - value |= (SWMODE_AUTO<< SW3MODE_LSB) | (SWMODE_AUTO<< SW4MODE_LSB); >>>>>> - pmic_write_reg(REG_SW_5, value, 0xffffff); >>>>>> + pmic_read_reg(REG_IDENTIFICATION,&value, 0xffffff); >>>>>> + /* only for mc13892 2.0A */ >>>>>> + if ((value& 0x0000FFFF) == 0x45d0) { >>>>>> + pmic_read_reg(REG_SW_4,&value, 0xffffff); >>>>>> + register_mask = (SWMODE_MASK<< SW1MODE_LSB) | >>>>>> + (SWMODE_MASK<< SW2MODE_LSB); >>>>>> + value&= ~register_mask; >>>>>> + value |= (SWMODE_AUTO<< SW1MODE_LSB) | >>>>>> + (SWMODE_AUTO<< SW2MODE_LSB); >>>>>> + pmic_write_reg(REG_SW_4, value, 0xffffff); >>>>>> + >>>>>> + pmic_read_reg(REG_SW_5,&value, 0xffffff); >>>>>> + register_mask = (SWMODE_MASK<< SW3MODE_LSB) | >>>>>> + (SWMODE_MASK<< SW4MODE_LSB); >>>>>> + value&= ~register_mask; >>>>>> + value |= (SWMODE_AUTO<< SW3MODE_LSB) | >>>>>> + (SWMODE_AUTO<< SW4MODE_LSB); >>>>>> + pmic_write_reg(REG_SW_5, value, 0xffffff); >>>>>> + } >>>>>> >>>>>> /* Enable coin cell charger */ >>>>>> value = BITFVAL(CIONCHEN, 1) | BITFVAL(VCOIN, VCOIN_3_0V); >>>>> >>>>> Bryan, >>>>> >>>>> Do you have positive test results from testing this patch? We want to make sure >>>>> this patch fixes the issue that we have been seeing. >>>>> >>>> >>>> Brad, >>>> >>>> Yeah, it can be confirmed by Ranjani from Freescale. I copied him in this email >>>> thread. >>>> >>>> Thanks, >>> >>> OK, so this sounds like we can take it. ACK >> >> I think Bryan meant we should wait for confirmation from Ranjani. _She_ will >> confirm if this fix doesn't brick BB2.5. >> >> BTW, is there any chance of unbricking bricked BB2.5 (like mine)? >> >> /Amit >> > > Ok, then I hold of with that until this has been confirmed. I have an updated > tree ready to push and a source package ready for upload here. > Amit and Stefan, Actually, I sent out this patch after I got the confirmation from Ranjani via email. Ranjani, Could you please confirm it in public here? Sorry for treating you as a boy/man, -;) Thanks, -Bryan
Hi all, I have attached the email that I sent to Bryan Wu on 08/09/2010. I did verify Bryan's kernel that included the patch mentioned below on 2 BBG2.5 boards (that have Atlas 2.0 parts). I followed the steps mentioned in the attached email to upgrade the kernel and the 2 BBG2.5 boards booted fine after the kernel upgrade. Amit, I am sorry, apart from replacing the MX51 and/or the atlas part, I don't believe there is a way to "unbrick" the broken boards. Thanks, Ranjani -----Original Message----- From: Bryan Wu [mailto:bryan.wu@canonical.com] Sent: Wednesday, August 11, 2010 8:34 AM To: Stefan Bader; Amit Kucheria; Vaidyanathan Ranjani-RA5478 Cc: kernel-team@lists.ubuntu.com Subject: Re: [PATCH] ENGR00121057 switch low power mode only support in mc13892 2.0a On 08/11/2010 08:37 PM, Stefan Bader wrote: > On 08/11/2010 01:56 PM, Amit Kucheria wrote: >> On 10 Aug 11, Stefan Bader wrote: >>> On 08/11/2010 12:41 PM, Bryan Wu wrote: >>>> On 08/10/2010 11:36 PM, Brad Figg wrote: >>>>> On 08/10/2010 12:07 AM, Bryan Wu wrote: >>>>>> From: Shen Yong<b00984@freescale.com> >>>>>> >>>>>> switch low power mode will cause problems on previous version of >>>>>> mc13892, which may break mc13892 chip. >>>>>> This is a fix for ENGR00120510. >>>>>> >>>>>> BugLink: http://bugs.launchpad.net/bugs/615722 >>>>>> >>>>>> Signed-off-by: Shen Yong<b00984@freescale.com> >>>>>> Signed-off-by: Bryan Wu<bryan.wu@canonical.com> >>>>>> --- >>>>>> arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c | 30 +++++++++++++++-------- >>>>>> 1 files changed, 19 insertions(+), 11 deletions(-) >>>>>> >>>>>> diff --git a/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >>>>>> b/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >>>>>> index e8a03cf..13869d0 100644 >>>>>> --- a/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >>>>>> +++ b/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >>>>>> @@ -346,17 +346,25 @@ static int mc13892_regulator_init(struct mc13892 *mc13892) >>>>>> pmic_write_reg(REG_MODE_1, value, 0xffffff); >>>>>> >>>>>> /* enable switch audo mode */ >>>>>> - pmic_read_reg(REG_SW_4,&value, 0xffffff); >>>>>> - register_mask = (SWMODE_MASK<< SW1MODE_LSB) | (SWMODE_MASK<< SW2MODE_LSB); >>>>>> - value&= ~register_mask; >>>>>> - value |= (SWMODE_AUTO<< SW1MODE_LSB) | (SWMODE_AUTO<< SW2MODE_LSB); >>>>>> - pmic_write_reg(REG_SW_4, value, 0xffffff); >>>>>> - >>>>>> - pmic_read_reg(REG_SW_5,&value, 0xffffff); >>>>>> - register_mask = (SWMODE_MASK<< SW3MODE_LSB) | (SWMODE_MASK<< SW4MODE_LSB); >>>>>> - value&= ~register_mask; >>>>>> - value |= (SWMODE_AUTO<< SW3MODE_LSB) | (SWMODE_AUTO<< SW4MODE_LSB); >>>>>> - pmic_write_reg(REG_SW_5, value, 0xffffff); >>>>>> + pmic_read_reg(REG_IDENTIFICATION,&value, 0xffffff); >>>>>> + /* only for mc13892 2.0A */ >>>>>> + if ((value& 0x0000FFFF) == 0x45d0) { >>>>>> + pmic_read_reg(REG_SW_4,&value, 0xffffff); >>>>>> + register_mask = (SWMODE_MASK<< SW1MODE_LSB) | >>>>>> + (SWMODE_MASK<< SW2MODE_LSB); >>>>>> + value&= ~register_mask; >>>>>> + value |= (SWMODE_AUTO<< SW1MODE_LSB) | >>>>>> + (SWMODE_AUTO<< SW2MODE_LSB); >>>>>> + pmic_write_reg(REG_SW_4, value, 0xffffff); >>>>>> + >>>>>> + pmic_read_reg(REG_SW_5,&value, 0xffffff); >>>>>> + register_mask = (SWMODE_MASK<< SW3MODE_LSB) | >>>>>> + (SWMODE_MASK<< SW4MODE_LSB); >>>>>> + value&= ~register_mask; >>>>>> + value |= (SWMODE_AUTO<< SW3MODE_LSB) | >>>>>> + (SWMODE_AUTO<< SW4MODE_LSB); >>>>>> + pmic_write_reg(REG_SW_5, value, 0xffffff); >>>>>> + } >>>>>> >>>>>> /* Enable coin cell charger */ >>>>>> value = BITFVAL(CIONCHEN, 1) | BITFVAL(VCOIN, VCOIN_3_0V); >>>>> >>>>> Bryan, >>>>> >>>>> Do you have positive test results from testing this patch? We want >>>>> to make sure this patch fixes the issue that we have been seeing. >>>>> >>>> >>>> Brad, >>>> >>>> Yeah, it can be confirmed by Ranjani from Freescale. I copied him >>>> in this email thread. >>>> >>>> Thanks, >>> >>> OK, so this sounds like we can take it. ACK >> >> I think Bryan meant we should wait for confirmation from Ranjani. >> _She_ will confirm if this fix doesn't brick BB2.5. >> >> BTW, is there any chance of unbricking bricked BB2.5 (like mine)? >> >> /Amit >> > > Ok, then I hold of with that until this has been confirmed. I have an > updated tree ready to push and a source package ready for upload here. > Amit and Stefan, Actually, I sent out this patch after I got the confirmation from Ranjani via email. Ranjani, Could you please confirm it in public here? Sorry for treating you as a boy/man, -;) Thanks, -Bryan Hi Bryan, I tested your latest patch following your steps on a BBG2.5 board and the board booted up fine after the kernel upgrade. I did verify that the kernel update did go through correctly and the newly booted kernel was 2.6.31.608.16~pmic-imx51. I would think that this missing patch[4] was the root cause. Let me know if I can be of any further help. Regards, Ranjani -----Original Message----- From: Bryan Wu [mailto:bryan.wu@canonical.com] Sent: Friday, August 06, 2010 9:55 PM To: Vaidyanathan Ranjani-RA5478 Cc: Kline Paul-R3AADA; Oliver Grawert; David Mandala; Herring Robert-RA7055; Zhang Lily-R58066; Mireles Fernando-R65652; Kwiecinski Gerry-R43613; O'Donnell Charles-R41321; Michael Kress; Chang Marsha-R59459 Subject: Re: Need assistance with 2 bricked Babbage boards Ranjani, The release image [1] includes the kernel 2.6.31-607.13, which does not contain patch [2]. That's why we can install the whole Lucid release image successfully on 2.5 board. Patch [2] was introduced in 2.6.31-608.15 in our -updates kernel. Our security testing kernel package also includes that, so it will brick the 2.5 board after we install the security testing kernel package. The testing kernel package [3] includes Patch [4], so it is supposed to work fine after upgrade from 2.6.31-607.13 kernel directly. All the release history can be found here [5]. For the source of 10.04 release, please checkout our git tree and create a branch based on tag: Ubuntu-2.6.31-607.13 (git checkout -b Ubuntu-2.6.31-607.13 Ubuntu-2.6.31-607.13). Then the source code in that branch is the kernel source of 10.04 release. So please - install [1] on 2.5 board which works fine and won't brick the board. - upgrade to kernel [3]. - to see whether the board was bricked. [1] http://releases.ubuntu.com/lucid/ubuntu-10.04-netbook-armel+imx51.img [2] ENGR00120510 atlas switch mode control (d54fdc5ef76d406be4762b67aa3653b92ad345ea) [3] http://people.canonical.com/~roc/kernel/fsl_pmic/ [4] ENGR00121057 switch low power mode only support in mc13892 2.0a (73bbe2dd208a176d5227954572d6682cb28d123d) [5] https://launchpad.net/ubuntu/+source/linux-fsl-imx51 Thanks, -Bryan On 08/06/2010 11:47 PM, Vaidyanathan Ranjani-RA5478 wrote: > Bryan, David, > Before we test the new kernel on a 2.5 board, I had a couple of questions: > 1. Does the 10.04 ubuntu release have the following patch: > ENGR00120510 atlas switch mode control > (d54fdc5ef76d406be4762b67aa3653b92ad345ea) > 2. Does the 10.04 ubuntu release have the following patch : > ENGR00121057 switch low power mode only support in mc13892 2.0a > (73bbe2dd208a176d5227954572d6682cb28d123d) > > To avoid bricking of boards the second patch needs to be in the kernel image that Bryan mentions below: > http://people.canonical.com/~roc/kernel/fsl_pmic/ > > Looking through your git repositories, I am not able to identify what is included in the 10.04 release. Can you please point me to the sources for the 10.04 release? > > This will help me in identifying the issue better. As of now, we at FSL think the issue is because the ENGR00121057 patch is not included in the Canonical sources. And we know that this can cause boards to stop working. > > Can you please answer my questions? Also confirm which patch is included in the image Bryan wants us to try. > > Thanks, > Ranjani > > -----Original Message----- > From: Bryan Wu [mailto:bryan.wu@canonical.com] > Sent: Friday, August 06, 2010 5:09 AM > To: Kline Paul-R3AADA > Cc: Oliver Grawert; David Mandala; Herring Robert-RA7055; Zhang > Lily-R58066; Mireles Fernando-R65652; Kwiecinski Gerry-R43613; > O'Donnell Charles-R41321; Michael Kress; Vaidyanathan Ranjani-RA5478; > Chang Marsha-R59459 > Subject: Re: Need assistance with 2 bricked Babbage boards > > Paul, > > How about to test my kernel directly on 2.5 board? > > - Download our Ubuntu Lucid 10.04 release fsl-imx51 image [1] > - Install it on BB 2.5 board, it should works fine. > - Copy over my testing kernel package [1] to the board via USB > - run sudo dpkg -i xxxx.deb to upgrade kernel > - reboot again to see whether it works or is bricked again. > > Thanks a lot, > -Bryan > > [1] > http://releases.ubuntu.com/lucid/ubuntu-10.04-netbook-armel+imx51.img > [2] http://people.canonical.com/~roc/kernel/fsl_pmic/ > > > On 08/04/2010 11:57 PM, Kline Paul-R3AADA wrote: >> Bryan and Oliver, >> >> Any progress on building an image with the kernel fix patch? >> >> Regards, >> Paul >> >>> -----Original Message----- >>> From: Bryan Wu [mailto:bryan.wu@canonical.com] >>> Sent: Tuesday, August 03, 2010 5:06 AM >>> To: Kline Paul-R3AADA; Oliver Grawert >>> Cc: David Mandala; Herring Robert-RA7055; Zhang Lily-R58066; Mireles >>> Fernando-R65652; Kwiecinski Gerry-R43613; O'Donnell Charles-R41321; >>> Michael Kress; Vaidyanathan Ranjani-RA5478; Chang Marsha-R59459 >>> Subject: Re: Need assistance with 2 bricked Babbage boards >>> >>> Paul, >>> >>> Thanks a lot for catching the root cause so quickly. >>> >>> I've built a kernel package which includes the fixing patch. Please >>> find it >>> here: http://people.canonical.com/~roc/kernel/fsl_pmic/ >>> >>> And I added that patch in my git tree: >>> http://kernel.ubuntu.com/git?p=roc/ubuntu- >>> lucid.git;a=shortlog;h=refs/heads/pmic_fix >>> >>> I can't built a image which including the fixing kernel. Maybe >>> Oliver can help that. If it requires us to upload our kernel source >>> package, I will open a Launchpad bug and submit that patch for >>> merging into our Lucid kernel tree. >>> >>> Best Regards, >>> -Bryan >>> >>> On 08/03/2010 02:29 AM, Kline Paul-R3AADA wrote: >>>> David, >>>> >>>> Based on our observations to date, the odds are good that the >>>> problem you encountered is due to a known Atlas APL hardware >>>> erratum for >>> version >>>> 2.0 of that power management IC (see below). You have stated last >>> week >>>> that the MX51 kernel you had problems with does not include the >>> attached >>>> patch. Without this patch, Babbage 2.5 boards, which have the 2.0 >>> version >>>> of Atlas APL can be damaged. >>>> >>>> Could Bryan or Tim please send us a version of >>>> ubuntu-10.04-netbook-armel+imx51.img.gz >>>> which has the attached patch applied? We will then try it on one of >>> our >>>> Babbage 2.5 boards first so you do not have to risk any more of >>>> your >>> boards. >>>> >>>> This hardware errata was fixed in Atlas APL version 2.0A. We tried >>> the version >>>> of ubuntu-10.04-netbook-armel+imx51.img.gz you provided last week, >>> which does >>>> not have the attached patch, on a Babbage 3.0 board and it was fine. >>> This >>>> was expected because Babbage 3.0 boards have Atlas APL 2.0A, which >>> fixed >>>> hardware errata 7737. >>>> >>>> Erratum ID: 7737 Title: PWM/PFM >>>> transition bug. >>>> Module: Power. >>>> PWM to PFM transition may tie switcher output voltage to BP. That >>>> can damage the processor or any other component on the switcher >>>> supply. >>>> Workaround: Please make sure not to use PFM mode nor ACM mode to >>>> avoid damage to the processor. >>>> >>>> It’s likely that on the Babbage 2.5 boards with Atlas APL version >>>> 2, >>>> MX51 was fed BP (4.2V) at one of the switcher supplies and that >>>> fried the MX51. >>>> >>>> Sorry for all the inconvenience. >>>> >>>> Regards, >>>> Paul >>>> >>>>> -----Original Message----- >>>>> From: David Mandala [mailto:davidm@canonical.com] >>>>> Sent: Thursday, July 29, 2010 9:13 PM >>>>> To: Kline Paul-R3AADA >>>>> Cc: Herring Robert-RA7055; Zhang Lily-R58066; Mireles Fernando- >>> R65652; >>>>> Kwiecinski Gerry-R43613; O'Donnell Charles-R41321; Michael Kress >>>>> Subject: Re: Need assistance with 2 bricked Babbage boards >>>>> >>>>> Hi Paul, >>>>> >>>>> Thanks for the information, it's somewhat worrisome that we have >>>>> managed to brick the boards in a way you have never seen before. >>>>> I've asked the kernel team to hold up on releasing the security >>>>> kernel for babbage >>>>> (duh) and I wait for more info from you. >>>>> >>>>> Thanks again, >>>>> >>>>> David >>>>> >>>>> On 07/29/2010 07:16 PM, Kline Paul-R3AADA wrote: >>>>>> David, >>>>>> >>>>>> We received the two Babbage boards you sent. >>>>>> >>>>>> Here is the report so far from Fernando Mireles in our >>>>>> Applications >>>>>> team: >>>>>> >>>>>> "It actually looks like it is a problem with the mx51 and not the >>>>>> PMIC maybe. I just bypassed the bootup pmic interaction sequence >>>>>> needed by the babbage board to keep the power ON, and I went >>> through >>>>>> some of the PMICs output voltages and they were all ok. I tried >>>>>> connecting through JTAG and could not, I tried using ATK and >>>>>> could not, I tried booting a known working babbage android image >>>>>> and >>> could >>>>>> not (all on both boards)." >>>>>> >>>>>> We will continue investigating. >>>>>> >>>>>> Regards, Paul >>>>>> >>>>>>> -----Original Message----- From: David Mandala >>>>>>> [mailto:davidm@canonical.com] Sent: Wednesday, July 28, 2010 >>>>>>> 3:04 PM To: Kline Paul-R3AADA Cc: Herring Robert-RA7055; Zhang >>>>>>> Lily-R58066; Mireles Fernando-R65652; Kwiecinski Gerry-R43613; >>>>>>> O'Donnell Charles-R41321 Subject: Re: Need assistance with 2 >>>>>>> bricked Babbage boards >>>>>>> >>>>>>> Going out today, will arrive tomorrow to you, thanks. >>>>>>> >>>>>>> On 07/28/2010 02:30 PM, Kline Paul-R3AADA wrote: >>>>>>>> David, >>>>>>>> >>>>>>>> I suggest that you ship the boards to me and we can have >>>>>>>> someone look at them to confirm that the Atlas chips are >>>>>>>> damaged. My shipping >>>>>>> address >>>>>>>> is below. >>>>>>>> >>>>>>>> Regards, Paul >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Paul Kline Mail Drop: OE41 Freescale Semiconductor Inc 6501 >>>>>>>> William Cannon Drive West Austin, TX 78735 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- From: David Mandala >>>>>>>>> [mailto:davidm@canonical.com] Sent: Wednesday, July 28, 2010 >>>>>>>>> 2:10 PM To: Kline Paul-R3AADA Cc: Herring Robert-RA7055; Zhang >>>>>>>>> Lily-R58066; Mireles Fernando- >>>>>>> R65652; >>>>>>>>> Kwiecinski Gerry-R43613; O'Donnell Charles-R41321 Subject: Re: >>>>>>>>> Need assistance with 2 bricked Babbage boards >>>>>>>>> >>>>>>>>> Paul, >>>>>>>>> >>>>>>>>> Tim from the kernel team said "The patch attached in your >>>>>>>>> previous email is _not_ applied to the current Lucid fsl-imx51 >>>>>>>>> flavour. It does, however, apply cleanly to our non-security >>>>>>>>> mainline sources." >>>>>>>>> >>>>>>>>> So we can apply it but it's not been in our kernels to date. >>>>>>>>> >>>>>>>>> The boards just arrived back to me here in Dallas, can I get >>>>>>>>> them >>>>>>> down >>>>>>>>> to you for a quick hardware review to determine what is going >>>>>>>>> on >>>>>>> with >>>>>>>>> them? I can hand carry them down if that helps, I am worried >>>>>>>>> that >>>>>>> the >>>>>>>>> images we have could cause some problems. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> >>>>>>>>> On 07/27/2010 10:38 PM, Kline Paul-R3AADA wrote: >>>>>>>>>> David, >>>>>>>>>> >>>>>>>>>> The Freescale Linux BSP for the Babbage board also has >>>>>>>>>> CONFIG_BACKLIGHT_MXC_MC13892=y >>>>>>>>>> >>>>>>>>>> Lily Zhang from our team suggests that you check and see >>>>>>>>>> whether >>>>>>> the >>>>>>>>> attached >>>>>>>>>> patch is included in your kernel package for MX51. >>>>>>>>>> >>>>>>>>>> Regards, Paul >>>>>>>>>> >>>>>>>>>>> -----Original Message----- From: David Mandala >>>>>>>>>>> [mailto:davidm@canonical.com] Sent: Tuesday, July 27, 2010 >>>>>>>>>>> 3:32 PM To: Herring Robert-RA7055 Cc: Herring Robert-RA7055; >>>>>>>>>>> Kline Paul-R3AADA Subject: Re: Need assistance with 2 >>>>>>>>>>> bricked Babbage boards >>>>>>>>>>> >>>>>>>>>>> I really hope that is not the issue as every image we have >>>>>>>>>>> has >>>>>>> that >>>>>>>>>>> option set, it is a scary thought just how much damage that >>>>>>>>>>> could cause. >>>>>>>>>>> >>>>>>>>>>> On 07/27/2010 03:14 PM, Rob Herring wrote: >>>>>>>>>>>> Assuming that is the problem, it requires replacing the >>>>>>>>>>>> PMIC >>>>>>> chips >>>>>>>>>>> which >>>>>>>>>>>> doing isn't a 100% success ratio. >>>>>>>>>>>> >>>>>>>>>>>> Rob >>>>>>>>>>>> >>>>>>>>>>>> On Tue, 2010-07-27 at 15:06 -0500, David Mandala wrote: >>>>>>>>>>>>> Rob, >>>>>>>>>>>>> >>>>>>>>>>>>> I don't know but I'm checking now, will get back to you as >>>>>>>>>>>>> soon >>>>>>> as >>>>>>>>>>> do I >>>>>>>>>>>>> know. If this is what bricked the boards is it fixable, >>>>>>>>>>>>> by >>>>>>>>> software >>>>>>>>>>> (or >>>>>>>>>>>>> even hardware) replacement? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for the quick assistance. >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>> On 07/27/2010 01:47 PM, Rob Herring wrote: >>>>>>>>>>>>>> David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> The option CONFIG_BACKLIGHT_MXC_MC13892 is turned on. >>>>>>>>>>>>>> I think >>>>>>>>> this >>>>>>>>>>> can >>>>>>>>>>>>>> kill the PMIC chip, but I'm not sure if it requires the >>>>>>>>>>>>>> WVGA >>>>>>>>> panel >>>>>>>>>>> to be >>>>>>>>>>>>>> attached or can happen without it attached. I'm checking >>>>>>>>>>>>>> on >>>>>>> that. >>>>>>>>>>> Do you >>>>>>>>>>>>>> know if this option was off in the old kernel? >>>>>>>>>>>>>> >>>>>>>>>>>>>> We probably should get rid of any option that can brick >>>>>>>>>>>>>> the >>>>>>>>>>> boards... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Rob >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, 2010-07-27 at 11:22 -0500, David Mandala >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> Hi Paul, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've got a problem that I hope you can help me with. My >>>>>>> kernel >>>>>>>>>>> team put >>>>>>>>>>>>>>> together a security update kernel for 10.04 and asked us >>>>>>>>>>>>>>> to QA >>>>>>>>> it >>>>>>>>>>> on a >>>>>>>>>>>>>>> board. We installed the working Lucid image, apt-get >>>>>>>>>>>>>>> updated >>>>>>>>> the >>>>>>>>>>> kernel >>>>>>>>>>>>>>> and rebooted, the babbage got part way through the >>>>>>>>>>>>>>> kernel boot >>>>>>>>> and >>>>>>>>>>> hung, >>>>>>>>>>>>>>> we rebooted to try again, now the system won't even stay >>>>>>> powered >>>>>>>>>>> on to >>>>>>>>>>>>>>> attempt to load from the SD card! They tried it again >>>>>>>>>>>>>>> on >>>>>>>>> another >>>>>>>>>>> board >>>>>>>>>>>>>>> thinking the board had a hardware failure and did the >>>>>>>>>>>>>>> same >>>>>>> thing >>>>>>>>>>> again >>>>>>>>>>>>>>> so now I have two boards that won't boot!!! The kernel >>>>>>>>>>>>>>> team >>>>>>>>> wants >>>>>>>>>>> to >>>>>>>>>>>>>>> get the security update out but I'm blocking the release >>>>>>>>>>>>>>> until >>>>>>>>> we >>>>>>>>>>> know >>>>>>>>>>>>>>> what is going wrong, I don't want to brick a bunch of >>>>>>>>>>>>>>> hardware >>>>>>>>> out >>>>>>>>>>> in >>>>>>>>>>>>>>> the field. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have the image that bricks the boards, and the kernel >>>>>>> package. >>>>>>>>>>> I'm >>>>>>>>>>>>>>> happy to send or bring them down to you. Rob Herring >>>>>>>>>>>>>>> was at >>>>>>> the >>>>>>>>>>> sprint >>>>>>>>>>>>>>> and asked me to send along the kernel config that was >>>>>>>>>>>>>>> used to >>>>>>>>> make >>>>>>>>>>> the >>>>>>>>>>>>>>> kernel. It's attached and I've CC'ed Rob here. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The boards are in transit to me, I expect them in >>>>>>>>>>>>>>> tomorrow. >>>>>>>>> Might >>>>>>>>>>> it be >>>>>>>>>>>>>>> possible for me to bring them down to you this week? I >>>>>>>>>>>>>>> expect >>>>>>>>>>> them >>>>>>>>>>>>>>> tomorrow. What I'd like to do is document what happened >>>>>>>>>>>>>>> and >>>>>>>>> what >>>>>>>>>>> you >>>>>>>>>>>>>>> can do to bring the boards back (if we did it I'm >>>>>>>>>>>>>>> guessing >>>>>>>>> anyone >>>>>>>>>>> can do >>>>>>>>>>>>>>> it). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- David Mandala<davidm at canonical dot com> >>>>>>>>>>> http://www.canonical.com/ Public Key id: 45B2D952 Murphy TX, >>>>>>>>>>> 75094 +1.214.774.2569 O +1.972.693.4007 C >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- David Mandala<davidm at canonical dot com> >>>>>>>>> http://www.canonical.com/ Public Key id: 45B2D952 Murphy TX, >>>>>>>>> 75094 +1.214.774.2569 O +1.972.693.4007 C >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- David Mandala<davidm at canonical dot com> >>>>>>> http://www.canonical.com/ Public Key id: 45B2D952 Murphy TX, >>>>>>> 75094 >>>>>>> +1.214.774.2569 O +1.972.693.4007 C >>>>>> >>>>> >>>>> >>>>> -- >>>>> David Mandala <davidm at canonical dot com> >>>>> http://www.canonical.com/ Public Key id: 45B2D952 Murphy TX, 75094 >>>>> +1.214.774.2569 O +1.972.693.4007 C >>>> >> > >
On 08/11/2010 04:17 PM, Vaidyanathan Ranjani-RA5478 wrote: > Hi all, > I have attached the email that I sent to Bryan Wu on 08/09/2010. I did > verify Bryan's kernel that included the patch mentioned below on 2 > BBG2.5 boards (that have Atlas 2.0 parts). I followed the steps > mentioned in the attached email to upgrade the kernel and the 2 BBG2.5 > boards booted fine after the kernel upgrade. > > Amit, > I am sorry, apart from replacing the MX51 and/or the atlas part, I > don't believe there is a way to "unbrick" the broken boards. > > Thanks, > Ranjani > > > > -----Original Message----- > From: Bryan Wu [mailto:bryan.wu@canonical.com] > Sent: Wednesday, August 11, 2010 8:34 AM > To: Stefan Bader; Amit Kucheria; Vaidyanathan Ranjani-RA5478 > Cc: kernel-team@lists.ubuntu.com > Subject: Re: [PATCH] ENGR00121057 switch low power mode only support in > mc13892 2.0a > > On 08/11/2010 08:37 PM, Stefan Bader wrote: >> On 08/11/2010 01:56 PM, Amit Kucheria wrote: >>> On 10 Aug 11, Stefan Bader wrote: >>>> On 08/11/2010 12:41 PM, Bryan Wu wrote: >>>>> On 08/10/2010 11:36 PM, Brad Figg wrote: >>>>>> On 08/10/2010 12:07 AM, Bryan Wu wrote: >>>>>>> From: Shen Yong<b00984@freescale.com> >>>>>>> >>>>>>> switch low power mode will cause problems on previous version of >>>>>>> mc13892, which may break mc13892 chip. >>>>>>> This is a fix for ENGR00120510. >>>>>>> >>>>>>> BugLink: http://bugs.launchpad.net/bugs/615722 >>>>>>> >>>>>>> Signed-off-by: Shen Yong<b00984@freescale.com> >>>>>>> Signed-off-by: Bryan Wu<bryan.wu@canonical.com> >>>>>>> --- >>>>>>> arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c | 30 > +++++++++++++++-------- >>>>>>> 1 files changed, 19 insertions(+), 11 deletions(-) >>>>>>> >>>>>>> diff --git a/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >>>>>>> b/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >>>>>>> index e8a03cf..13869d0 100644 >>>>>>> --- a/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >>>>>>> +++ b/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c >>>>>>> @@ -346,17 +346,25 @@ static int mc13892_regulator_init(struct > mc13892 *mc13892) >>>>>>> pmic_write_reg(REG_MODE_1, value, 0xffffff); >>>>>>> >>>>>>> /* enable switch audo mode */ >>>>>>> - pmic_read_reg(REG_SW_4,&value, 0xffffff); >>>>>>> - register_mask = (SWMODE_MASK<< SW1MODE_LSB) | > (SWMODE_MASK<< SW2MODE_LSB); >>>>>>> - value&= ~register_mask; >>>>>>> - value |= (SWMODE_AUTO<< SW1MODE_LSB) | (SWMODE_AUTO<< > SW2MODE_LSB); >>>>>>> - pmic_write_reg(REG_SW_4, value, 0xffffff); >>>>>>> - >>>>>>> - pmic_read_reg(REG_SW_5,&value, 0xffffff); >>>>>>> - register_mask = (SWMODE_MASK<< SW3MODE_LSB) | > (SWMODE_MASK<< SW4MODE_LSB); >>>>>>> - value&= ~register_mask; >>>>>>> - value |= (SWMODE_AUTO<< SW3MODE_LSB) | (SWMODE_AUTO<< > SW4MODE_LSB); >>>>>>> - pmic_write_reg(REG_SW_5, value, 0xffffff); >>>>>>> + pmic_read_reg(REG_IDENTIFICATION,&value, 0xffffff); >>>>>>> + /* only for mc13892 2.0A */ >>>>>>> + if ((value& 0x0000FFFF) == 0x45d0) { >>>>>>> + pmic_read_reg(REG_SW_4,&value, 0xffffff); >>>>>>> + register_mask = (SWMODE_MASK<< SW1MODE_LSB) | >>>>>>> + (SWMODE_MASK<< SW2MODE_LSB); >>>>>>> + value&= ~register_mask; >>>>>>> + value |= (SWMODE_AUTO<< SW1MODE_LSB) | >>>>>>> + (SWMODE_AUTO<< SW2MODE_LSB); >>>>>>> + pmic_write_reg(REG_SW_4, value, 0xffffff); >>>>>>> + >>>>>>> + pmic_read_reg(REG_SW_5,&value, 0xffffff); >>>>>>> + register_mask = (SWMODE_MASK<< SW3MODE_LSB) | >>>>>>> + (SWMODE_MASK<< SW4MODE_LSB); >>>>>>> + value&= ~register_mask; >>>>>>> + value |= (SWMODE_AUTO<< SW3MODE_LSB) | >>>>>>> + (SWMODE_AUTO<< SW4MODE_LSB); >>>>>>> + pmic_write_reg(REG_SW_5, value, 0xffffff); >>>>>>> + } >>>>>>> >>>>>>> /* Enable coin cell charger */ >>>>>>> value = BITFVAL(CIONCHEN, 1) | BITFVAL(VCOIN, > VCOIN_3_0V); >>>>>> >>>>>> Bryan, >>>>>> >>>>>> Do you have positive test results from testing this patch? We want > >>>>>> to make sure this patch fixes the issue that we have been seeing. >>>>>> >>>>> >>>>> Brad, >>>>> >>>>> Yeah, it can be confirmed by Ranjani from Freescale. I copied him >>>>> in this email thread. >>>>> >>>>> Thanks, >>>> >>>> OK, so this sounds like we can take it. ACK >>> >>> I think Bryan meant we should wait for confirmation from Ranjani. >>> _She_ will confirm if this fix doesn't brick BB2.5. >>> >>> BTW, is there any chance of unbricking bricked BB2.5 (like mine)? >>> >>> /Amit >>> >> >> Ok, then I hold of with that until this has been confirmed. I have an >> updated tree ready to push and a source package ready for upload here. >> > > Amit and Stefan, > > Actually, I sent out this patch after I got the confirmation from > Ranjani via email. > > Ranjani, > > Could you please confirm it in public here? Sorry for treating you as a > boy/man, -;) > > Thanks, > -Bryan > Applied, pushed and uploaded (build will be blocked until point release is done). Thanks all. Stefan
diff --git a/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c b/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c index e8a03cf..13869d0 100644 --- a/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c +++ b/arch/arm/mach-mx51/mx51_babbage_pmic_mc13892.c @@ -346,17 +346,25 @@ static int mc13892_regulator_init(struct mc13892 *mc13892) pmic_write_reg(REG_MODE_1, value, 0xffffff); /* enable switch audo mode */ - pmic_read_reg(REG_SW_4, &value, 0xffffff); - register_mask = (SWMODE_MASK << SW1MODE_LSB) | (SWMODE_MASK << SW2MODE_LSB); - value &= ~register_mask; - value |= (SWMODE_AUTO << SW1MODE_LSB) | (SWMODE_AUTO << SW2MODE_LSB); - pmic_write_reg(REG_SW_4, value, 0xffffff); - - pmic_read_reg(REG_SW_5, &value, 0xffffff); - register_mask = (SWMODE_MASK << SW3MODE_LSB) | (SWMODE_MASK << SW4MODE_LSB); - value &= ~register_mask; - value |= (SWMODE_AUTO << SW3MODE_LSB) | (SWMODE_AUTO << SW4MODE_LSB); - pmic_write_reg(REG_SW_5, value, 0xffffff); + pmic_read_reg(REG_IDENTIFICATION, &value, 0xffffff); + /* only for mc13892 2.0A */ + if ((value & 0x0000FFFF) == 0x45d0) { + pmic_read_reg(REG_SW_4, &value, 0xffffff); + register_mask = (SWMODE_MASK << SW1MODE_LSB) | + (SWMODE_MASK << SW2MODE_LSB); + value &= ~register_mask; + value |= (SWMODE_AUTO << SW1MODE_LSB) | + (SWMODE_AUTO << SW2MODE_LSB); + pmic_write_reg(REG_SW_4, value, 0xffffff); + + pmic_read_reg(REG_SW_5, &value, 0xffffff); + register_mask = (SWMODE_MASK << SW3MODE_LSB) | + (SWMODE_MASK << SW4MODE_LSB); + value &= ~register_mask; + value |= (SWMODE_AUTO << SW3MODE_LSB) | + (SWMODE_AUTO << SW4MODE_LSB); + pmic_write_reg(REG_SW_5, value, 0xffffff); + } /* Enable coin cell charger */ value = BITFVAL(CIONCHEN, 1) | BITFVAL(VCOIN, VCOIN_3_0V);