On Fri, 2017-05-05 at 09:18 +0800, Shawn Guo wrote:
> On Thu, May 04, 2017 at 04:34:14PM +0200, Marek Vasut wrote:
> > If you model the
> > power distribution correctly, the OPP hackery can be removed.
> The OPP hackery can be removed even without reg_arm/reg_soc modeling.
> That's why we can do
On Fri, 2017-05-05 at 09:18 +0800, Shawn Guo wrote:
> On Thu, May 04, 2017 at 04:34:14PM +0200, Marek Vasut wrote:
> > If you model the
> > power distribution correctly, the OPP hackery can be removed.
> The OPP hackery can be removed even without reg_arm/reg_soc modeling.
> That's why we can do
On Thu, May 04, 2017 at 04:34:14PM +0200, Marek Vasut wrote:
> On 05/04/2017 03:41 PM, Shawn Guo wrote:
> > So I guess you do not understand how the OPP hackery was born and why it
> > shouldn't be there for mainline kernel at all.
>
> The OPP hackery is there to keep both regulators configured
On Thu, May 04, 2017 at 04:34:14PM +0200, Marek Vasut wrote:
> On 05/04/2017 03:41 PM, Shawn Guo wrote:
> > So I guess you do not understand how the OPP hackery was born and why it
> > shouldn't be there for mainline kernel at all.
>
> The OPP hackery is there to keep both regulators configured
On 05/04/2017 03:41 PM, Shawn Guo wrote:
> On Thu, May 04, 2017 at 03:08:41PM +0200, Marek Vasut wrote:
>> On 05/04/2017 02:44 PM, Shawn Guo wrote:
>>> On Thu, May 04, 2017 at 12:06:11PM +0200, Marek Vasut wrote:
>
>
>
Mind you, my patch is not fixing any crash, it's correcting the
On 05/04/2017 03:41 PM, Shawn Guo wrote:
> On Thu, May 04, 2017 at 03:08:41PM +0200, Marek Vasut wrote:
>> On 05/04/2017 02:44 PM, Shawn Guo wrote:
>>> On Thu, May 04, 2017 at 12:06:11PM +0200, Marek Vasut wrote:
>
>
>
Mind you, my patch is not fixing any crash, it's correcting the
On Thu, May 04, 2017 at 03:08:41PM +0200, Marek Vasut wrote:
> On 05/04/2017 02:44 PM, Shawn Guo wrote:
> > On Thu, May 04, 2017 at 12:06:11PM +0200, Marek Vasut wrote:
> >> Mind you, my patch is not fixing any crash, it's correcting the
> >> regulator binding and removing the OPP override
On Thu, May 04, 2017 at 03:08:41PM +0200, Marek Vasut wrote:
> On 05/04/2017 02:44 PM, Shawn Guo wrote:
> > On Thu, May 04, 2017 at 12:06:11PM +0200, Marek Vasut wrote:
> >> Mind you, my patch is not fixing any crash, it's correcting the
> >> regulator binding and removing the OPP override
On 05/04/2017 02:44 PM, Shawn Guo wrote:
> On Thu, May 04, 2017 at 12:06:11PM +0200, Marek Vasut wrote:
>> On 05/04/2017 11:42 AM, Leonard Crestez wrote:
>>> I think there is a further misunderstanding here. I have a problem
>>> where imx6sx-sdb rev C boards crash on boot with upstream (but are
On 05/04/2017 02:44 PM, Shawn Guo wrote:
> On Thu, May 04, 2017 at 12:06:11PM +0200, Marek Vasut wrote:
>> On 05/04/2017 11:42 AM, Leonard Crestez wrote:
>>> I think there is a further misunderstanding here. I have a problem
>>> where imx6sx-sdb rev C boards crash on boot with upstream (but are
On Tue, Apr 25, 2017 at 07:57:59PM +0300, Leonard Crestez wrote:
> The board file for imx6sx-dbg overrides cpufreq operating points to use
s/imx6sx-dbg/imx6sx-sdb
> higher voltages. This is done because the board has a shared rail for
> VDD_ARM_IN and VDD_SOC_IN and when using LDO bypass the
On Tue, Apr 25, 2017 at 07:57:59PM +0300, Leonard Crestez wrote:
> The board file for imx6sx-dbg overrides cpufreq operating points to use
s/imx6sx-dbg/imx6sx-sdb
> higher voltages. This is done because the board has a shared rail for
> VDD_ARM_IN and VDD_SOC_IN and when using LDO bypass the
On Thu, May 04, 2017 at 12:06:11PM +0200, Marek Vasut wrote:
> On 05/04/2017 11:42 AM, Leonard Crestez wrote:
> > I think there is a further misunderstanding here. I have a problem
> > where imx6sx-sdb rev C boards crash on boot with upstream (but are
> > reported to work fine with rev B).
On Thu, May 04, 2017 at 12:06:11PM +0200, Marek Vasut wrote:
> On 05/04/2017 11:42 AM, Leonard Crestez wrote:
> > I think there is a further misunderstanding here. I have a problem
> > where imx6sx-sdb rev C boards crash on boot with upstream (but are
> > reported to work fine with rev B).
Hi Shawn,
On Thu, May 4, 2017 at 8:43 AM, Shawn Guo wrote:
> Per comments from Henri and Leonard, it sounds like the issue only
> happens on RevC board?
That's correct. I do not observe any crashes on my revA board.
Hi Shawn,
On Thu, May 4, 2017 at 8:43 AM, Shawn Guo wrote:
> Per comments from Henri and Leonard, it sounds like the issue only
> happens on RevC board?
That's correct. I do not observe any crashes on my revA board.
On Thu, Apr 27, 2017 at 01:17:12AM +, Peter Chen wrote:
>
> >
> >The board file for imx6sx-dbg overrides cpufreq operating points to use
> >higher
> >voltages. This is done because the board has a shared rail for VDD_ARM_IN and
> >VDD_SOC_IN and when using LDO bypass the shared voltage
On Thu, Apr 27, 2017 at 01:17:12AM +, Peter Chen wrote:
>
> >
> >The board file for imx6sx-dbg overrides cpufreq operating points to use
> >higher
> >voltages. This is done because the board has a shared rail for VDD_ARM_IN and
> >VDD_SOC_IN and when using LDO bypass the shared voltage
On 05/04/2017 11:42 AM, Leonard Crestez wrote:
> On Wed, 2017-05-03 at 21:33 +0200, Marek Vasut wrote:
>> On 05/03/2017 07:58 PM, Leonard Crestez wrote:
>>> On Wed, 2017-05-03 at 17:59 +0200, Marek Vasut wrote:
On 05/03/2017 04:58 PM, Leonard Crestez wrote:
> On Wed, 2017-05-03 at 16:26
On 05/04/2017 11:42 AM, Leonard Crestez wrote:
> On Wed, 2017-05-03 at 21:33 +0200, Marek Vasut wrote:
>> On 05/03/2017 07:58 PM, Leonard Crestez wrote:
>>> On Wed, 2017-05-03 at 17:59 +0200, Marek Vasut wrote:
On 05/03/2017 04:58 PM, Leonard Crestez wrote:
> On Wed, 2017-05-03 at 16:26
On Wed, 2017-05-03 at 21:33 +0200, Marek Vasut wrote:
> On 05/03/2017 07:58 PM, Leonard Crestez wrote:
> > On Wed, 2017-05-03 at 17:59 +0200, Marek Vasut wrote:
> > > On 05/03/2017 04:58 PM, Leonard Crestez wrote:
> > > > On Wed, 2017-05-03 at 16:26 +0200, Marek Vasut wrote:
> > > > > 2) It
On Wed, 2017-05-03 at 21:33 +0200, Marek Vasut wrote:
> On 05/03/2017 07:58 PM, Leonard Crestez wrote:
> > On Wed, 2017-05-03 at 17:59 +0200, Marek Vasut wrote:
> > > On 05/03/2017 04:58 PM, Leonard Crestez wrote:
> > > > On Wed, 2017-05-03 at 16:26 +0200, Marek Vasut wrote:
> > > > > 2) It
On 05/03/2017 07:58 PM, Leonard Crestez wrote:
> On Wed, 2017-05-03 at 17:59 +0200, Marek Vasut wrote:
>> On 05/03/2017 04:58 PM, Leonard Crestez wrote:
>>> On Wed, 2017-05-03 at 16:26 +0200, Marek Vasut wrote:
2) It actually fixes a problem with the voltage rails such that the DVFS
On 05/03/2017 07:58 PM, Leonard Crestez wrote:
> On Wed, 2017-05-03 at 17:59 +0200, Marek Vasut wrote:
>> On 05/03/2017 04:58 PM, Leonard Crestez wrote:
>>> On Wed, 2017-05-03 at 16:26 +0200, Marek Vasut wrote:
2) It actually fixes a problem with the voltage rails such that the DVFS
On Wed, 2017-05-03 at 17:59 +0200, Marek Vasut wrote:
> On 05/03/2017 04:58 PM, Leonard Crestez wrote:
> > On Wed, 2017-05-03 at 16:26 +0200, Marek Vasut wrote:
> > > 2) It actually fixes a problem with the voltage rails such that the DVFS
> > > works without leaving the system in unstable or
On Wed, 2017-05-03 at 17:59 +0200, Marek Vasut wrote:
> On 05/03/2017 04:58 PM, Leonard Crestez wrote:
> > On Wed, 2017-05-03 at 16:26 +0200, Marek Vasut wrote:
> > > 2) It actually fixes a problem with the voltage rails such that the DVFS
> > > works without leaving the system in unstable or
On 05/03/2017 04:58 PM, Leonard Crestez wrote:
> On Wed, 2017-05-03 at 16:26 +0200, Marek Vasut wrote:
>
>> On 05/03/2017 03:57 PM, Shawn Guo wrote:
>>>
>>> On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
On 04/25/2017 07:23 PM, Leonard Crestez wrote:
>
> Anyway,
On 05/03/2017 04:58 PM, Leonard Crestez wrote:
> On Wed, 2017-05-03 at 16:26 +0200, Marek Vasut wrote:
>
>> On 05/03/2017 03:57 PM, Shawn Guo wrote:
>>>
>>> On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
On 04/25/2017 07:23 PM, Leonard Crestez wrote:
>
> Anyway,
On Wed, 2017-05-03 at 16:26 +0200, Marek Vasut wrote:
> On 05/03/2017 03:57 PM, Shawn Guo wrote:
> >
> > On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
> > >
> > > On 04/25/2017 07:23 PM, Leonard Crestez wrote:
> > > >
> > > > Anyway, that version also sets the supply for reg_arm
On Wed, 2017-05-03 at 16:26 +0200, Marek Vasut wrote:
> On 05/03/2017 03:57 PM, Shawn Guo wrote:
> >
> > On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
> > >
> > > On 04/25/2017 07:23 PM, Leonard Crestez wrote:
> > > >
> > > > Anyway, that version also sets the supply for reg_arm
On 05/03/2017 04:41 PM, Shawn Guo wrote:
> On Wed, May 03, 2017 at 04:32:06PM +0200, Marek Vasut wrote:
>> On 05/03/2017 04:26 PM, Marek Vasut wrote:
>>> On 05/03/2017 03:57 PM, Shawn Guo wrote:
On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
> On 04/25/2017 07:23 PM, Leonard
On 05/03/2017 04:41 PM, Shawn Guo wrote:
> On Wed, May 03, 2017 at 04:32:06PM +0200, Marek Vasut wrote:
>> On 05/03/2017 04:26 PM, Marek Vasut wrote:
>>> On 05/03/2017 03:57 PM, Shawn Guo wrote:
On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
> On 04/25/2017 07:23 PM, Leonard
On Wed, May 03, 2017 at 04:32:06PM +0200, Marek Vasut wrote:
> On 05/03/2017 04:26 PM, Marek Vasut wrote:
> > On 05/03/2017 03:57 PM, Shawn Guo wrote:
> >> On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
> >>> On 04/25/2017 07:23 PM, Leonard Crestez wrote:
> Anyway, that version
On Wed, May 03, 2017 at 04:32:06PM +0200, Marek Vasut wrote:
> On 05/03/2017 04:26 PM, Marek Vasut wrote:
> > On 05/03/2017 03:57 PM, Shawn Guo wrote:
> >> On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
> >>> On 04/25/2017 07:23 PM, Leonard Crestez wrote:
> Anyway, that version
On 05/03/2017 04:26 PM, Marek Vasut wrote:
> On 05/03/2017 03:57 PM, Shawn Guo wrote:
>> On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
>>> On 04/25/2017 07:23 PM, Leonard Crestez wrote:
Anyway, that version also sets the supply for reg_arm and reg_soc. It
is not necessary
On 05/03/2017 04:26 PM, Marek Vasut wrote:
> On 05/03/2017 03:57 PM, Shawn Guo wrote:
>> On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
>>> On 04/25/2017 07:23 PM, Leonard Crestez wrote:
Anyway, that version also sets the supply for reg_arm and reg_soc. It
is not necessary
On 05/03/2017 03:57 PM, Shawn Guo wrote:
> On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
>> On 04/25/2017 07:23 PM, Leonard Crestez wrote:
>>> Anyway, that version also sets the supply for reg_arm and reg_soc. It
>>> is not necessary for fixing the crash I'm seeing but is good
On 05/03/2017 03:57 PM, Shawn Guo wrote:
> On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
>> On 04/25/2017 07:23 PM, Leonard Crestez wrote:
>>> Anyway, that version also sets the supply for reg_arm and reg_soc. It
>>> is not necessary for fixing the crash I'm seeing but is good
On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
> On 04/25/2017 07:23 PM, Leonard Crestez wrote:
> > Anyway, that version also sets the supply for reg_arm and reg_soc. It
> > is not necessary for fixing the crash I'm seeing but is good because it
> > will result in the minimum voltage
On Tue, Apr 25, 2017 at 07:28:06PM +0200, Marek Vasut wrote:
> On 04/25/2017 07:23 PM, Leonard Crestez wrote:
> > Anyway, that version also sets the supply for reg_arm and reg_soc. It
> > is not necessary for fixing the crash I'm seeing but is good because it
> > will result in the minimum voltage
>
>The board file for imx6sx-dbg overrides cpufreq operating points to use higher
>voltages. This is done because the board has a shared rail for VDD_ARM_IN and
>VDD_SOC_IN and when using LDO bypass the shared voltage needs to be a value
>suitable for both ARM and SOC.
>
>This was introduced in:
>
>The board file for imx6sx-dbg overrides cpufreq operating points to use higher
>voltages. This is done because the board has a shared rail for VDD_ARM_IN and
>VDD_SOC_IN and when using LDO bypass the shared voltage needs to be a value
>suitable for both ARM and SOC.
>
>This was introduced in:
On 04/25/2017 07:23 PM, Leonard Crestez wrote:
> On Tue, 2017-04-25 at 14:02 -0300, Fabio Estevam wrote:
>> On Tue, Apr 25, 2017 at 2:02 PM, Fabio Estevam wrote:
>>>
>>> Hi Leonard,
>>>
>>> On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez
>>> wrote:
On 04/25/2017 07:23 PM, Leonard Crestez wrote:
> On Tue, 2017-04-25 at 14:02 -0300, Fabio Estevam wrote:
>> On Tue, Apr 25, 2017 at 2:02 PM, Fabio Estevam wrote:
>>>
>>> Hi Leonard,
>>>
>>> On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez
>>> wrote:
The board file for imx6sx-dbg
On Tue, Apr 25, 2017 at 2:23 PM, Leonard Crestez
wrote:
> Wow, that was literally 15 minutes before my patch. In my defense I did
> search the archives before starting to format the patch but it had not
> arrived yet.
>
> Anyway, that version also sets the supply for
On Tue, Apr 25, 2017 at 2:23 PM, Leonard Crestez
wrote:
> Wow, that was literally 15 minutes before my patch. In my defense I did
> search the archives before starting to format the patch but it had not
> arrived yet.
>
> Anyway, that version also sets the supply for reg_arm and reg_soc. It
> is
On Tue, 2017-04-25 at 14:02 -0300, Fabio Estevam wrote:
> On Tue, Apr 25, 2017 at 2:02 PM, Fabio Estevam wrote:
> >
> > Hi Leonard,
> >
> > On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez
> > wrote:
> > >
> > > The board file for imx6sx-dbg
On Tue, 2017-04-25 at 14:02 -0300, Fabio Estevam wrote:
> On Tue, Apr 25, 2017 at 2:02 PM, Fabio Estevam wrote:
> >
> > Hi Leonard,
> >
> > On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez
> > wrote:
> > >
> > > The board file for imx6sx-dbg overrides cpufreq operating points to use
> > >
On Tue, Apr 25, 2017 at 2:02 PM, Fabio Estevam wrote:
> Hi Leonard,
>
> On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez
> wrote:
>> The board file for imx6sx-dbg overrides cpufreq operating points to use
>> higher voltages. This is done because the
On Tue, Apr 25, 2017 at 2:02 PM, Fabio Estevam wrote:
> Hi Leonard,
>
> On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez
> wrote:
>> The board file for imx6sx-dbg overrides cpufreq operating points to use
>> higher voltages. This is done because the board has a shared rail for
>> VDD_ARM_IN and
Hi Leonard,
On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez
wrote:
> The board file for imx6sx-dbg overrides cpufreq operating points to use
> higher voltages. This is done because the board has a shared rail for
> VDD_ARM_IN and VDD_SOC_IN and when using LDO bypass the
Hi Leonard,
On Tue, Apr 25, 2017 at 1:57 PM, Leonard Crestez
wrote:
> The board file for imx6sx-dbg overrides cpufreq operating points to use
> higher voltages. This is done because the board has a shared rail for
> VDD_ARM_IN and VDD_SOC_IN and when using LDO bypass the shared voltage
> needs
The board file for imx6sx-dbg overrides cpufreq operating points to use
higher voltages. This is done because the board has a shared rail for
VDD_ARM_IN and VDD_SOC_IN and when using LDO bypass the shared voltage
needs to be a value suitable for both ARM and SOC.
This was introduced in:
commit
The board file for imx6sx-dbg overrides cpufreq operating points to use
higher voltages. This is done because the board has a shared rail for
VDD_ARM_IN and VDD_SOC_IN and when using LDO bypass the shared voltage
needs to be a value suitable for both ARM and SOC.
This was introduced in:
commit
54 matches
Mail list logo