The existing scheduling domain hierarchy is defined to map to the cache
topology of the system. However, Energy Aware Scheduling (EAS) requires
more knowledge about the platform, and specifically needs to know about
the span of Performance Domains (PD), which do not always align with
caches.
To
In order to make sure Energy Aware Scheduling (EAS) doesn't hurt
systems not using it, add a new sched_feat, called ENERGY_AWARE,
guarding the access to EAS code paths.
Signed-off-by: Quentin Perret
---
kernel/sched/features.h | 7 +++
1 file changed, 7 insertions(+)
diff --git
Expose the Energy Model (read-only) of all performance domains in sysfs
for convenience. To do so, add a kobject to the CPU subsystem under the
umbrella of which a kobject for each performance domain is attached.
The resulting hierarchy is as follows for a platform with two
performance domains
In order to make sure Energy Aware Scheduling (EAS) doesn't hurt
systems not using it, add a new sched_feat, called ENERGY_AWARE,
guarding the access to EAS code paths.
Signed-off-by: Quentin Perret
---
kernel/sched/features.h | 7 +++
1 file changed, 7 insertions(+)
diff --git
Expose the Energy Model (read-only) of all performance domains in sysfs
for convenience. To do so, add a kobject to the CPU subsystem under the
umbrella of which a kobject for each performance domain is attached.
The resulting hierarchy is as follows for a platform with two
performance domains
Energy Aware Scheduling (EAS) in its current form is most relevant on
platforms with asymmetric CPU topologies (e.g. Arm big.LITTLE) since
this is where there is a lot of potential for saving energy through
scheduling. This is particularly true since the Energy Model only
includes the active power
Add another member to the family of per-cpu sched_domain shortcut
pointers. This one, sd_asym_cpucapacity, points to the lowest level
at which the SD_ASYM_CPUCAPACITY flag is set. While at it, rename the
sd_asym shortcut to sd_asym_packing to avoid confusions.
Generally speaking, the largest
This patch series introduces Energy Aware Scheduling (EAS) for CFS tasks
on platforms with asymmetric CPU topologies (e.g. Arm big.LITTLE).
For more details about the ideas behind it and the overall design,
please refer to the cover letter of version 5 [1].
1. Version History
--
By default, arch_scale_cpu_capacity() is only visible from within the
kernel/sched folder. Relocate it to include/linux/sched/topology.h to
make it visible to other clients needing to know about the capacity of
CPUs, such as the Energy Model framework.
Cc: Ingo Molnar
Cc: Peter Zijlstra
The existing scheduling domain hierarchy is defined to map to the cache
topology of the system. However, Energy Aware Scheduling (EAS) requires
more knowledge about the platform, and specifically needs to know about
the span of Performance Domains (PD), which do not always align with
caches.
To
Several subsystems in the kernel (task scheduler and/or thermal at the
time of writing) can benefit from knowing about the energy consumed by
CPUs. Yet, this information can come from different sources (DT or
firmware for example), in different formats, hence making it hard to
exploit without a
Schedutil requests frequency by aggregating utilization signals from
the scheduler (CFS, RT, DL, IRQ) and applying and 25% margin on top of
them. Since Energy Aware Scheduling (EAS) needs to be able to predict
the frequency requests, it needs to forecast the decisions made by the
governor.
In
Several subsystems in the kernel (task scheduler and/or thermal at the
time of writing) can benefit from knowing about the energy consumed by
CPUs. Yet, this information can come from different sources (DT or
firmware for example), in different formats, hence making it hard to
exploit without a
Schedutil requests frequency by aggregating utilization signals from
the scheduler (CFS, RT, DL, IRQ) and applying and 25% margin on top of
them. Since Energy Aware Scheduling (EAS) needs to be able to predict
the frequency requests, it needs to forecast the decisions made by the
governor.
In
On Tue 11-09-18 19:29:21, Matthew Wilcox wrote:
> On Tue, Sep 11, 2018 at 04:35:03PM -0700, Yang Shi wrote:
[...]
I didn't get to read the patch yet.
> > And, Michal prefers have VM_HUGETLB and VM_PFNMAP handled separately for
> > safe and bisectable sake, which needs call the regular
On Tue 11-09-18 19:29:21, Matthew Wilcox wrote:
> On Tue, Sep 11, 2018 at 04:35:03PM -0700, Yang Shi wrote:
[...]
I didn't get to read the patch yet.
> > And, Michal prefers have VM_HUGETLB and VM_PFNMAP handled separately for
> > safe and bisectable sake, which needs call the regular
On 09/12/2018 02:41 PM, Pingfan Liu wrote:
> Cc James, could you try to enable initcall_debug, and paste the
> shutdown seq with 722e5f2b1eec ("driver core: Partially revert "driver
> core: correct device's shutdown order"") and without it?
OK. And I will scheudule some testing orders, ahah,
On 09/12/2018 02:41 PM, Pingfan Liu wrote:
> Cc James, could you try to enable initcall_debug, and paste the
> shutdown seq with 722e5f2b1eec ("driver core: Partially revert "driver
> core: correct device's shutdown order"") and without it?
OK. And I will scheudule some testing orders, ahah,
From: Jiri Kosina
If spectrev2 mitigation has been enabled, we're filling RSB on context switch
in order to protect from various classess of spectrev2 attacks.
If this mitigation is enabled, say so in sysfs for spectrev2.
Signed-off-by: Jiri Kosina
---
arch/x86/kernel/cpu/bugs.c | 3 ++-
1
From: Jiri Kosina
If spectrev2 mitigation has been enabled, we're filling RSB on context switch
in order to protect from various classess of spectrev2 attacks.
If this mitigation is enabled, say so in sysfs for spectrev2.
Signed-off-by: Jiri Kosina
---
arch/x86/kernel/cpu/bugs.c | 3 ++-
1
From: Jiri Kosina
STIBP is a feature provided by certain Intel ucodes / CPUs. This feature
(once enabled) prevents cross-hyperthread control of decisions made by
indirect branch predictors.
Enable this feature if
- the CPU is vulnerable to spectre v2
- the CPU supports SMT and has SMT siblings
From: Jiri Kosina
STIBP is a feature provided by certain Intel ucodes / CPUs. This feature
(once enabled) prevents cross-hyperthread control of decisions made by
indirect branch predictors.
Enable this feature if
- the CPU is vulnerable to spectre v2
- the CPU supports SMT and has SMT siblings
From: Jiri Kosina
Currently, we are issuing IBPB only in cases when switching into a non-dumpable
process, the rationale being to protect such 'important and security sensitive'
processess (such as GPG) from data leak into a different userspace process via
spectre v2.
This is however completely
From: Jiri Kosina
Currently, we are issuing IBPB only in cases when switching into a non-dumpable
process, the rationale being to protect such 'important and security sensitive'
processess (such as GPG) from data leak into a different userspace process via
spectre v2.
This is however completely
Currently, linux kernel is basically not preventing userspace-userspace
spectrev2 attack, because:
- IBPB is basically unused (issued only for tasks that marked themselves
explicitly non-dumpable, which is absolutely negligible minority of all
software out there), therefore cross-process
Currently, linux kernel is basically not preventing userspace-userspace
spectrev2 attack, because:
- IBPB is basically unused (issued only for tasks that marked themselves
explicitly non-dumpable, which is absolutely negligible minority of all
software out there), therefore cross-process
On Wed, 12 Sep 2018, Srinivas Kandagatla wrote:
> On 11/09/18 16:33, Lee Jones wrote:
> > On Tue, 04 Sep 2018, Srinivas Kandagatla wrote:
> >
> > > Qualcomm WCD9335 Codec is a standalone Hi-Fi audio codec IC,
> > > It has mulitple blocks like Soundwire controller, codec,
> > > Codec processing
On Wed, 12 Sep 2018, Srinivas Kandagatla wrote:
> On 11/09/18 16:33, Lee Jones wrote:
> > On Tue, 04 Sep 2018, Srinivas Kandagatla wrote:
> >
> > > Qualcomm WCD9335 Codec is a standalone Hi-Fi audio codec IC,
> > > It has mulitple blocks like Soundwire controller, codec,
> > > Codec processing
On Wed, Sep 12, 2018 at 09:42:51AM +0100, Lee Jones wrote:
> On Wed, 12 Sep 2018, Matti Vaittinen wrote:
>
> > On Tue, Sep 11, 2018 at 01:40:29PM +0100, Lee Jones wrote:
> > > On Wed, 29 Aug 2018, Matti Vaittinen wrote:
> > >
> > > > There is a HW quirk in BD71837. The shutdown sequence timings
On Wed, Sep 12, 2018 at 09:42:51AM +0100, Lee Jones wrote:
> On Wed, 12 Sep 2018, Matti Vaittinen wrote:
>
> > On Tue, Sep 11, 2018 at 01:40:29PM +0100, Lee Jones wrote:
> > > On Wed, 29 Aug 2018, Matti Vaittinen wrote:
> > >
> > > > There is a HW quirk in BD71837. The shutdown sequence timings
On Wed, 12 Sep 2018, Matti Vaittinen wrote:
> On Tue, Sep 11, 2018 at 01:40:29PM +0100, Lee Jones wrote:
> > On Wed, 29 Aug 2018, Matti Vaittinen wrote:
> >
> > > There is a HW quirk in BD71837. The shutdown sequence timings for
> > > bucks/LDOs which are enabled via register interface are
On Wed, 12 Sep 2018, Matti Vaittinen wrote:
> On Tue, Sep 11, 2018 at 01:40:29PM +0100, Lee Jones wrote:
> > On Wed, 29 Aug 2018, Matti Vaittinen wrote:
> >
> > > There is a HW quirk in BD71837. The shutdown sequence timings for
> > > bucks/LDOs which are enabled via register interface are
On 12/09/18 07:52, Alexey Budankov wrote:
Hi,
Is there any plans or may be even progress on that so far?
It's hanging in the back of my mind. AFAIR after last round there was a
build failure or two to fix on more exotic (to me) hardware, and Jiri
Olsa provided a tools/perf snippet
On 12/09/18 07:52, Alexey Budankov wrote:
Hi,
Is there any plans or may be even progress on that so far?
It's hanging in the back of my mind. AFAIR after last round there was a
build failure or two to fix on more exotic (to me) hardware, and Jiri
Olsa provided a tools/perf snippet
On Wed, 12 Sep 2018, Alexandre Belloni wrote:
> On 11/09/2018 23:54:40+0100, Lee Jones wrote:
> > > > http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6438-32-bit-ARM926-Embedded-Microprocessor-SAM9G45_Datasheet.pdf
> > > >
> > > > USART doc starting p572, registers p621.
> >
> > After
On Wed, 12 Sep 2018, Alexandre Belloni wrote:
> On 11/09/2018 23:54:40+0100, Lee Jones wrote:
> > > > http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6438-32-bit-ARM926-Embedded-Microprocessor-SAM9G45_Datasheet.pdf
> > > >
> > > > USART doc starting p572, registers p621.
> >
> > After
On Wed, 12 Sep 2018, Alexandre Belloni wrote:
> On 11/09/2018 23:43:02+0100, Lee Jones wrote:
> > > I haven't read it, but I believe it's not unlike Renesas SCIF, which is
> > > served by both drivers/tty/serial/sh-sci.c and drivers/spi/spi-sh-sci.c.
> > > But the latter is not used from DT, so
On Wed, 12 Sep 2018, Alexandre Belloni wrote:
> On 11/09/2018 23:43:02+0100, Lee Jones wrote:
> > > I haven't read it, but I believe it's not unlike Renesas SCIF, which is
> > > served by both drivers/tty/serial/sh-sci.c and drivers/spi/spi-sh-sci.c.
> > > But the latter is not used from DT, so
On Tue, Sep 11, 2018 at 06:09:01AM -0700, Sodagudi Prasad wrote:
> May I know why client edev_ctl->poll_msec settings is not considered?
Looks like it has been like this since it was added. But, I take patches :)
Make sure to sanity-check ->poll_msec too, before accepting it. I.e.,
something
Hi Stephen,
On 2018/9/12 15:34, Stephen Rothwell wrote:
> Hi Chao,
>
> On Wed, 12 Sep 2018 15:19:16 +0800 Chao Yu wrote:
>>
>> To make sure, did -next tree enable erofs compiling now?
>
> Yes, from yesterday.
Great, thanks for your help. :)
>
>> Xiang has made two patches to fix integration
On Tue, Sep 11, 2018 at 06:09:01AM -0700, Sodagudi Prasad wrote:
> May I know why client edev_ctl->poll_msec settings is not considered?
Looks like it has been like this since it was added. But, I take patches :)
Make sure to sanity-check ->poll_msec too, before accepting it. I.e.,
something
Hi Stephen,
On 2018/9/12 15:34, Stephen Rothwell wrote:
> Hi Chao,
>
> On Wed, 12 Sep 2018 15:19:16 +0800 Chao Yu wrote:
>>
>> To make sure, did -next tree enable erofs compiling now?
>
> Yes, from yesterday.
Great, thanks for your help. :)
>
>> Xiang has made two patches to fix integration
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: 11 September 2018 11:25
> To: Shameerali Kolothum Thodi ;
> lorenzo.pieral...@arm.com
> Cc: will.dea...@arm.com; mark.rutl...@arm.com; Guohanjun (Hanjun Guo)
> ; John Garry ;
> pa...@codeaurora.org;
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: 11 September 2018 11:25
> To: Shameerali Kolothum Thodi ;
> lorenzo.pieral...@arm.com
> Cc: will.dea...@arm.com; mark.rutl...@arm.com; Guohanjun (Hanjun Guo)
> ; John Garry ;
> pa...@codeaurora.org;
Hi, Stefan
Anson Huang
Best Regards!
> -Original Message-
> From: Stefan Wahren
> Sent: Wednesday, September 12, 2018 4:28 PM
> To: Anson Huang ; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; Fabio Estevam
> ; robh...@kernel.org; mark.rutl...@arm.com;
>
Hi, Stefan
Anson Huang
Best Regards!
> -Original Message-
> From: Stefan Wahren
> Sent: Wednesday, September 12, 2018 4:28 PM
> To: Anson Huang ; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; Fabio Estevam
> ; robh...@kernel.org; mark.rutl...@arm.com;
>
When two or more devices are sharing their clock and voltage rails, they
share the same OPP table. But there are some corner cases where the OPP
core incorrectly creates separate OPP tables for them.
For example, CPU 0 and 1 share clock/voltage rails. The platform
specific code calls
When two or more devices are sharing their clock and voltage rails, they
share the same OPP table. But there are some corner cases where the OPP
core incorrectly creates separate OPP tables for them.
For example, CPU 0 and 1 share clock/voltage rails. The platform
specific code calls
Currently there are two separate ways to free the OPP table based on how
it is created in the first place.
We call _dev_pm_opp_remove_table() to free the static and/or dynamic
OPP, OPP list devices, etc. This is done for the case where the OPP
table is added while initializing the OPPs, like via
dev_pm_opp_cpumask_remove_table() is going to change in the next commit
and will not remove dynamic OPPs automatically. They must be removed
with a call to dev_pm_opp_remove().
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/mvebu-cpufreq.c | 9 ++---
1 file changed, 2 insertions(+), 7
Currently there are two separate ways to free the OPP table based on how
it is created in the first place.
We call _dev_pm_opp_remove_table() to free the static and/or dynamic
OPP, OPP list devices, etc. This is done for the case where the OPP
table is added while initializing the OPPs, like via
dev_pm_opp_cpumask_remove_table() is going to change in the next commit
and will not remove dynamic OPPs automatically. They must be removed
with a call to dev_pm_opp_remove().
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/mvebu-cpufreq.c | 9 ++---
1 file changed, 2 insertions(+), 7
Both _of_add_opp_table_v1() and _of_add_opp_table_v2() contain similar
code to get the OPP table and their parent routine also parses the DT to
find the OPP table's node pointer. This can be simplified by getting the
OPP table in advance and then passing it as argument to these routines.
Both _of_add_opp_table_v1() and _of_add_opp_table_v2() contain similar
code to get the OPP table and their parent routine also parses the DT to
find the OPP table's node pointer. This can be simplified by getting the
OPP table in advance and then passing it as argument to these routines.
The static OPPs don't always get freed with the OPP table, it can happen
before that as well. For example, if the OPP table is first created
using helpers like dev_pm_opp_set_supported_hw() and the OPPs are
created at a later point. Now when the OPPs are removed, the OPP table
stays until the time
The reference count is only required to be incremented for every call
that may lead to adding the OPP table. For static OPPs the same should
be done from the parent routine which adds all static OPPs together and
so only one refcount for all static OPPs.
Update code to reflect that.
The refcount
Only one platform was depending on this feature and it is already
updated now. Stop removing dynamic OPPs from _dev_pm_opp_remove_table().
This simplifies lot of paths and removes unnecessary parameters.
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 20 +---
The static OPPs don't always get freed with the OPP table, it can happen
before that as well. For example, if the OPP table is first created
using helpers like dev_pm_opp_set_supported_hw() and the OPPs are
created at a later point. Now when the OPPs are removed, the OPP table
stays until the time
The reference count is only required to be incremented for every call
that may lead to adding the OPP table. For static OPPs the same should
be done from the parent routine which adds all static OPPs together and
so only one refcount for all static OPPs.
Update code to reflect that.
The refcount
Only one platform was depending on this feature and it is already
updated now. Stop removing dynamic OPPs from _dev_pm_opp_remove_table().
This simplifies lot of paths and removes unnecessary parameters.
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 20 +---
Parse the DT properties present in the OPP table from
_of_init_opp_table(), which is a dedicated routine for DT parsing.
Minor relocation of helpers is required for this.
It is possible now for _managed_opp() to return a partially initialized
OPP table if the OPP table is created via the helpers
This is a preparatory patch required for the next commit which will
start using OPP table's node pointer in _of_init_opp_table(), which
requires the index in order to read the OPP table's phandle.
This commit adds the index argument in the call chains in order to get
it delivered to
Parse the DT properties present in the OPP table from
_of_init_opp_table(), which is a dedicated routine for DT parsing.
Minor relocation of helpers is required for this.
It is possible now for _managed_opp() to return a partially initialized
OPP table if the OPP table is created via the helpers
This is a preparatory patch required for the next commit which will
start using OPP table's node pointer in _of_init_opp_table(), which
requires the index in order to read the OPP table's phandle.
This commit adds the index argument in the call chains in order to get
it delivered to
The dev_list needs to be protected with a lock, else we may have
simultaneous access (addition/removal) to it and that would be racy.
Extend scope of the opp_table lock to protect dev_list as well.
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 21 +++--
drivers/opp/cpu.c
The dev_list needs to be protected with a lock, else we may have
simultaneous access (addition/removal) to it and that would be racy.
Extend scope of the opp_table lock to protect dev_list as well.
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 21 +++--
drivers/opp/cpu.c
Hello,
Niklas Cassle recently reported some regressions with his Qcom cpufreq
driver where he was getting some errors while creating the OPPs tables.
After looking into it I realized that the OPP core incorrectly creates
multiple OPP tables for the devices even if they are sharing the OPP
table
The OPP table was freed, but not the individual OPPs which is done from
_dev_pm_opp_remove_table(). Fix it by calling _dev_pm_opp_remove_table()
as well.
Cc: 4.18 # v4.18
Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper")
Signed-off-by: Viresh Kumar
---
drivers/opp/of.c
Hello,
Niklas Cassle recently reported some regressions with his Qcom cpufreq
driver where he was getting some errors while creating the OPPs tables.
After looking into it I realized that the OPP core incorrectly creates
multiple OPP tables for the devices even if they are sharing the OPP
table
The OPP table was freed, but not the individual OPPs which is done from
_dev_pm_opp_remove_table(). Fix it by calling _dev_pm_opp_remove_table()
as well.
Cc: 4.18 # v4.18
Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper")
Signed-off-by: Viresh Kumar
---
drivers/opp/of.c
On 12/09/18 03:21, Shawn Guo wrote:
On Tue, Sep 11, 2018 at 11:17:07AM +0100, Suzuki K Poulose wrote:
Switch to the updated coresight bindings.
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
Cc: Mathieu Poirier
Signed-off-by: Suzuki K Poulose
As per the
Hi Anson,
Am 12.09.2018 um 10:13 schrieb Anson Huang:
> Update VDD_SOC voltage to 1.25V for 900MHz operating point
> according to datasheet Rev. 1.3, 08/2018, 25mV is added to
> the minimum allowed values to cover power supply ripple.
is there a reason why the new datasheet isn't published yet?
On 12/09/18 03:21, Shawn Guo wrote:
On Tue, Sep 11, 2018 at 11:17:07AM +0100, Suzuki K Poulose wrote:
Switch to the updated coresight bindings.
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
Cc: Mathieu Poirier
Signed-off-by: Suzuki K Poulose
As per the
Hi Anson,
Am 12.09.2018 um 10:13 schrieb Anson Huang:
> Update VDD_SOC voltage to 1.25V for 900MHz operating point
> according to datasheet Rev. 1.3, 08/2018, 25mV is added to
> the minimum allowed values to cover power supply ripple.
is there a reason why the new datasheet isn't published yet?
Hi,
On 11.09.2018 17:19, Peter Zijlstra wrote:
> On Tue, Sep 11, 2018 at 08:35:12AM +0200, Ingo Molnar wrote:
>>> Well, explicit threading in the tool for AIO, in the simplest case, means
>>> incorporating some POSIX API implementation into the tool, avoiding
>>> code reuse in the first
Hi,
On 11.09.2018 17:19, Peter Zijlstra wrote:
> On Tue, Sep 11, 2018 at 08:35:12AM +0200, Ingo Molnar wrote:
>>> Well, explicit threading in the tool for AIO, in the simplest case, means
>>> incorporating some POSIX API implementation into the tool, avoiding
>>> code reuse in the first
On 09/12/2018 01:33 AM, Guenter Roeck wrote:
> On Wed, Sep 12, 2018 at 08:23:29AM +0930, Joel Stanley wrote:
>> On Wed, 12 Sep 2018 at 07:48, Jae Hyun Yoo
>> wrote:
>>>
>>> On 9/11/2018 1:41 PM, Guenter Roeck wrote:
On Tue, Sep 11, 2018 at 01:30:41PM -0700, Jae Hyun Yoo wrote:
>>
> I
On 09/12/2018 01:33 AM, Guenter Roeck wrote:
> On Wed, Sep 12, 2018 at 08:23:29AM +0930, Joel Stanley wrote:
>> On Wed, 12 Sep 2018 at 07:48, Jae Hyun Yoo
>> wrote:
>>>
>>> On 9/11/2018 1:41 PM, Guenter Roeck wrote:
On Tue, Sep 11, 2018 at 01:30:41PM -0700, Jae Hyun Yoo wrote:
>>
> I
On Wed, Sep 12, 2018 at 09:26:12AM +0200, Heiko Stübner wrote:
> Am Mittwoch, 12. September 2018, 05:12:48 CEST schrieb Manivannan Sadhasivam:
> > Hi Ezequiel,
> >
> > On Tue, Sep 11, 2018 at 04:40:29PM -0300, Ezequiel Garcia wrote:
> > > On Tue, 2018-09-11 at 08:00 +0530, Manivannan Sadhasivam
On Wed, Sep 12, 2018 at 09:26:12AM +0200, Heiko Stübner wrote:
> Am Mittwoch, 12. September 2018, 05:12:48 CEST schrieb Manivannan Sadhasivam:
> > Hi Ezequiel,
> >
> > On Tue, Sep 11, 2018 at 04:40:29PM -0300, Ezequiel Garcia wrote:
> > > On Tue, 2018-09-11 at 08:00 +0530, Manivannan Sadhasivam
Update VDD_SOC voltage to 1.25V for 900MHz operating point
according to datasheet Rev. 1.3, 08/2018, 25mV is added to
the minimum allowed values to cover power supply ripple.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6ull.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Update VDD_SOC voltage to 1.25V for 900MHz operating point
according to datasheet Rev. 1.3, 08/2018, 25mV is added to
the minimum allowed values to cover power supply ripple.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6ull.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hi,
On Tue, Sep 11, 2018 at 08:47:55PM +0200, Greg Kroah-Hartman wrote:
>
> Normally I do not review "RFC" patches as it implies the submitter does
> not think they are a valid solution. How about resending them as if you
> think this is something ready to be merged?
I had used "RFC" here
Hi,
On Tue, Sep 11, 2018 at 08:47:55PM +0200, Greg Kroah-Hartman wrote:
>
> Normally I do not review "RFC" patches as it implies the submitter does
> not think they are a valid solution. How about resending them as if you
> think this is something ready to be merged?
I had used "RFC" here
From: Bartosz Golaszewski
While working on the nvmem framework recently I noticed that there are
many providers that don't use the devm variant of nvmem_register().
This series contains relevant updates for eeprom drivers.
Note that these patches are independent from my other nvmem series[1].
From: Bartosz Golaszewski
Use resource managed variants of nvmem_register() and kzalloc().
Signed-off-by: Bartosz Golaszewski
---
drivers/misc/eeprom/eeprom_93xx46.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
From: Bartosz Golaszewski
Use the resource managed variant of nvmem_register().
Signed-off-by: Bartosz Golaszewski
---
drivers/misc/eeprom/at25.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/misc/eeprom/at25.c b/drivers/misc/eeprom/at25.c
index
From: Bartosz Golaszewski
Use resource managed variants of nvmem_register() and kzalloc().
Signed-off-by: Bartosz Golaszewski
---
drivers/misc/eeprom/eeprom_93xx46.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
From: Bartosz Golaszewski
Use the resource managed variant of nvmem_register().
Signed-off-by: Bartosz Golaszewski
---
drivers/misc/eeprom/at25.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/misc/eeprom/at25.c b/drivers/misc/eeprom/at25.c
index
From: Bartosz Golaszewski
While working on the nvmem framework recently I noticed that there are
many providers that don't use the devm variant of nvmem_register().
This series contains relevant updates for eeprom drivers.
Note that these patches are independent from my other nvmem series[1].
On (09/11/18 10:47), Petr Mladek wrote:
> > Oh, that was intentional. I consider repeated messages to be less
> > problematic than the missing ones.
>
> It makes some sense. But it might be problematic with slow consoles.
Right. And this is why I brought up Jan's patch.
And I agree that we
On (09/11/18 10:47), Petr Mladek wrote:
> > Oh, that was intentional. I consider repeated messages to be less
> > problematic than the missing ones.
>
> It makes some sense. But it might be problematic with slow consoles.
Right. And this is why I brought up Jan's patch.
And I agree that we
On Tue, Sep 11, 2018 at 01:40:29PM +0100, Lee Jones wrote:
> On Wed, 29 Aug 2018, Matti Vaittinen wrote:
>
> > There is a HW quirk in BD71837. The shutdown sequence timings for
> > bucks/LDOs which are enabled via register interface are changed.
> > At PMIC poweroff the voltage for BUCK6/7 is cut
On Tue, Sep 11, 2018 at 01:40:29PM +0100, Lee Jones wrote:
> On Wed, 29 Aug 2018, Matti Vaittinen wrote:
>
> > There is a HW quirk in BD71837. The shutdown sequence timings for
> > bucks/LDOs which are enabled via register interface are changed.
> > At PMIC poweroff the voltage for BUCK6/7 is cut
Thanks for your review,
On 10/09/18 21:06, Rob Herring wrote:
On Tue, Sep 04, 2018 at 11:24:57AM +0100, Srinivas Kandagatla wrote:
This patch add new bindings required to support MBHC
(Multi Button Headset Control) block in the codec.
This block is used for jack insert/removal detection,
Thanks for your review,
On 10/09/18 21:06, Rob Herring wrote:
On Tue, Sep 04, 2018 at 11:24:57AM +0100, Srinivas Kandagatla wrote:
This patch add new bindings required to support MBHC
(Multi Button Headset Control) block in the codec.
This block is used for jack insert/removal detection,
On Tue, Sep 11, 2018 at 02:49:47PM +0100, Lee Jones wrote:
> On Wed, 29 Aug 2018, Matti Vaittinen wrote:
>
> > Add ROHM BD71847 Power Management IC MFD binding information to
> > device-tree binding documents.
> >
> > Signed-off-by: Matti Vaittinen
> > ---
> >
On Tue, Sep 11, 2018 at 02:49:47PM +0100, Lee Jones wrote:
> On Wed, 29 Aug 2018, Matti Vaittinen wrote:
>
> > Add ROHM BD71847 Power Management IC MFD binding information to
> > device-tree binding documents.
> >
> > Signed-off-by: Matti Vaittinen
> > ---
> >
Hello,
On Tue, Sep 11, 2018 at 02:55:49PM +0100, Lee Jones wrote:
> On Wed, 29 Aug 2018, Matti Vaittinen wrote:
>
> > Few regulators in BD71837 and BD71847 can output voltages from
> > different voltage ranges. Register interface is arranged so that
> > used range is selected by toggling bits
Hello,
On Tue, Sep 11, 2018 at 02:55:49PM +0100, Lee Jones wrote:
> On Wed, 29 Aug 2018, Matti Vaittinen wrote:
>
> > Few regulators in BD71837 and BD71847 can output voltages from
> > different voltage ranges. Register interface is arranged so that
> > used range is selected by toggling bits
1301 - 1400 of 1468 matches
Mail list logo
