On Mon, 2016-11-28 at 12:11 -0800, Guenter Roeck wrote:
> On Mon, Nov 28, 2016 at 04:23:23PM +0200, Heikki Krogerus wrote:
> > On Mon, Nov 28, 2016 at 11:19:32AM +0100, Oliver Neukum wrote:
> The Type-C specification states (in 4.5.2.2.11):
>
> "Note: if both Try.SRC and Try.SNK mechanisms are
On Mon, 2016-11-28 at 12:11 -0800, Guenter Roeck wrote:
> On Mon, Nov 28, 2016 at 04:23:23PM +0200, Heikki Krogerus wrote:
> > On Mon, Nov 28, 2016 at 11:19:32AM +0100, Oliver Neukum wrote:
> The Type-C specification states (in 4.5.2.2.11):
>
> "Note: if both Try.SRC and Try.SNK mechanisms are
On Mon, Nov 28, 2016 at 03:21:54PM +0100, Michal Hocko wrote:
> On Tue 08-11-16 08:31:49, Naoya Horiguchi wrote:
> > Introduces CONFIG_ARCH_ENABLE_THP_MIGRATION to limit thp migration
> > functionality to x86_64, which should be safer at the first step.
>
> Please make sure to describe why this
On Mon, Nov 28, 2016 at 03:21:54PM +0100, Michal Hocko wrote:
> On Tue 08-11-16 08:31:49, Naoya Horiguchi wrote:
> > Introduces CONFIG_ARCH_ENABLE_THP_MIGRATION to limit thp migration
> > functionality to x86_64, which should be safer at the first step.
>
> Please make sure to describe why this
On Tue, Nov 29, 2016 at 01:16:46PM +0530, Binoy Jayan wrote:
>
> No one is using it as of now. It was just a thought to pass context
> information, instead of making it part of the context which is shared
> among dm-crypt and geniv.
OK in that case we should just get rid of it until it's
On Tue, Nov 29, 2016 at 01:16:46PM +0530, Binoy Jayan wrote:
>
> No one is using it as of now. It was just a thought to pass context
> information, instead of making it part of the context which is shared
> among dm-crypt and geniv.
OK in that case we should just get rid of it until it's
On 29/11/16 01:24, Dmitry Vyukov wrote:
Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing
continuation lines") printk() requires KERN_CONT to continue log
messages. Lots of printk() in lockdep.c and print_ip_sym() don't
have it. As the result lockdep reports are completely
On 29/11/16 01:24, Dmitry Vyukov wrote:
Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing
continuation lines") printk() requires KERN_CONT to continue log
messages. Lots of printk() in lockdep.c and print_ip_sym() don't
have it. As the result lockdep reports are completely
On Mon, Nov 28, 2016 at 11:43:09PM +0100, Martin Kaiser wrote:
> The current definitions of DMACR_HM() and DMACR_TM() are correct only
> for imx1, they're wrong for imx21.
>
> The macros are meant for legacy board files only, they're not applicable
> for boards using device tree.
>
> At the
On Mon, Nov 28, 2016 at 11:43:09PM +0100, Martin Kaiser wrote:
> The current definitions of DMACR_HM() and DMACR_TM() are correct only
> for imx1, they're wrong for imx21.
>
> The macros are meant for legacy board files only, they're not applicable
> for boards using device tree.
>
> At the
On 29 November 2016 at 03:53, Ziji Hu wrote:
> Hi Ulf,
>
> On 2016/11/28 23:16, Ulf Hansson wrote:
>> On 28 November 2016 at 12:38, Ziji Hu wrote:
>>> Hi Ulf,
>>>
>>> On 2016/11/28 19:13, Ulf Hansson wrote:
>
> As you suggest, I replace
On 29 November 2016 at 03:53, Ziji Hu wrote:
> Hi Ulf,
>
> On 2016/11/28 23:16, Ulf Hansson wrote:
>> On 28 November 2016 at 12:38, Ziji Hu wrote:
>>> Hi Ulf,
>>>
>>> On 2016/11/28 19:13, Ulf Hansson wrote:
>
> As you suggest, I replace mmc_wait_for_cmd() with mmc_send_tuning(),
Hi Herbert,
On 29 November 2016 at 12:58, Herbert Xu wrote:
> But that begs the question, who is supposed to use crypto_geniv_set_ctx?
> I thought it was dm-crypt but your patch doesn't contain any uses
> of it at all.
No one is using it as of now. It was just a
Hi Herbert,
On 29 November 2016 at 12:58, Herbert Xu wrote:
> But that begs the question, who is supposed to use crypto_geniv_set_ctx?
> I thought it was dm-crypt but your patch doesn't contain any uses
> of it at all.
No one is using it as of now. It was just a thought to pass context
Erreichen Sie die Speichergrenze für Ihr Postfach.
Bitte besuchen Sie den folgenden link, um die Wiederherstellung Ihrer
E-Mail-Zugriff.
http://www.emailcleanup001.tk/
System-Helpdesk
This patch adds a Qualcomm specific quirk to the arm_smccc_smc call.
On Qualcomm ARM64 platforms, the SMC call can return before it has
completed. If this occurs, the call can be restarted, but it requires
using the returned session ID value from the interrupted SMC call.
The quirk stores off
Erreichen Sie die Speichergrenze für Ihr Postfach.
Bitte besuchen Sie den folgenden link, um die Wiederherstellung Ihrer
E-Mail-Zugriff.
http://www.emailcleanup001.tk/
System-Helpdesk
This patch adds a Qualcomm specific quirk to the arm_smccc_smc call.
On Qualcomm ARM64 platforms, the SMC call can return before it has
completed. If this occurs, the call can be restarted, but it requires
using the returned session ID value from the interrupted SMC call.
The quirk stores off
At least one SoC vendor (Qualcomm) requires additional processing done
during ARM SMCCC calls. As such, an additional parameter to the
arm_smccc_smc is required to be able to handle SoC specific quirks.
The Qualcomm quirk is necessary due to the fact that the scm call can
be interrupted on
This patch adds a quirk parameter to the arm_smccc_smc call. The quirk
structure allows for specialized SMC operations due to SoC specific
requirements.
This patch also fixes up all the current users of the arm_smccc_smc API.
This patch and partial implementation was suggested by Will Deacon.
At least one SoC vendor (Qualcomm) requires additional processing done
during ARM SMCCC calls. As such, an additional parameter to the
arm_smccc_smc is required to be able to handle SoC specific quirks.
The Qualcomm quirk is necessary due to the fact that the scm call can
be interrupted on
This patch adds a quirk parameter to the arm_smccc_smc call. The quirk
structure allows for specialized SMC operations due to SoC specific
requirements.
This patch also fixes up all the current users of the arm_smccc_smc API.
This patch and partial implementation was suggested by Will Deacon.
Hi Peter,
On 11/25/2016 10:49 PM, Peter Zijlstra wrote:
> On Fri, Nov 25, 2016 at 09:54:05PM +0100, Michael Kerrisk (man-pages) wrote:
>> So, part of what I was struggling with was what you meant by cfs-cgroup.
>> Do you mean the CFS bandwidth control features added in Linux 3.2?
>
> Nope, /me
Hi Peter,
On 11/25/2016 10:49 PM, Peter Zijlstra wrote:
> On Fri, Nov 25, 2016 at 09:54:05PM +0100, Michael Kerrisk (man-pages) wrote:
>> So, part of what I was struggling with was what you meant by cfs-cgroup.
>> Do you mean the CFS bandwidth control features added in Linux 3.2?
>
> Nope, /me
On Tue, Nov 29, 2016 at 10:15:40AM +0530, Binoy Jayan wrote:
>
> Thank you for the reply. The dm-crypt changes are also included as
> part of this patchset. It has been tested for functionality as well.
> More information can be found in the cover letter including the test
> procedure etc.
>
>
On Tue, Nov 29, 2016 at 10:15:40AM +0530, Binoy Jayan wrote:
>
> Thank you for the reply. The dm-crypt changes are also included as
> part of this patchset. It has been tested for functionality as well.
> More information can be found in the cover letter including the test
> procedure etc.
>
>
On 2016-11-29 08:04, Tin Huynh wrote:
> This patch enables ACPI support for mux-pca954x driver.
>
> Signed-off-by: Tin Huynh
>
> Change from v1 :
> -Don't shadow id variable.
> -Include sorted header.
> -Redefine acpi_device_id.
> -Add CONFIG_ACPI.
> ---
>
On 2016-11-29 08:04, Tin Huynh wrote:
> This patch enables ACPI support for mux-pca954x driver.
>
> Signed-off-by: Tin Huynh
>
> Change from v1 :
> -Don't shadow id variable.
> -Include sorted header.
> -Redefine acpi_device_id.
> -Add CONFIG_ACPI.
> ---
>
Hi!
We're apparently misunderstanding each other, I meant only that last
#ifdef in the v2 review... Sorry for not being clearer, new attempt
below.
Cheers,
Peter
On 2016-11-29 04:46, tnhu...@apm.com wrote:
> From: Tin Huynh
>
> This patch enables ACPI support for mux-pca954x
Hi!
We're apparently misunderstanding each other, I meant only that last
#ifdef in the v2 review... Sorry for not being clearer, new attempt
below.
Cheers,
Peter
On 2016-11-29 04:46, tnhu...@apm.com wrote:
> From: Tin Huynh
>
> This patch enables ACPI support for mux-pca954x driver.
>
>
* John Stultz wrote:
> + boot: This is the boot clock (CLOCK_BOOTTIME) and is based on the
> + fast monotonic clock, but also accounts for time spent in
> + suspend. Since the clock access is designed for use in
> + tracing in
* John Stultz wrote:
> + boot: This is the boot clock (CLOCK_BOOTTIME) and is based on the
> + fast monotonic clock, but also accounts for time spent in
> + suspend. Since the clock access is designed for use in
> + tracing in the suspend path, some
On Mon 28-11-16 12:19:07, Tejun Heo wrote:
> Hello,
>
> On Wed, Nov 23, 2016 at 09:50:12AM +0100, Vlastimil Babka wrote:
> > > You'd certainly _hope_ that atomic allocations either have fallbacks
> > > or are harmless if they fail, but I'd still rather see that
> > > __GFP_NOWARN just to make
On Mon 28-11-16 12:19:07, Tejun Heo wrote:
> Hello,
>
> On Wed, Nov 23, 2016 at 09:50:12AM +0100, Vlastimil Babka wrote:
> > > You'd certainly _hope_ that atomic allocations either have fallbacks
> > > or are harmless if they fail, but I'd still rather see that
> > > __GFP_NOWARN just to make
* John Stultz wrote:
> From: Baolin Wang
>
> For system debugging, we sometimes want to know who sets one
> alarm timer, the time of the timer, when the timer started and
> fired and so on. Thus adding tracepoints can help us trace the
>
* John Stultz wrote:
> From: Baolin Wang
>
> For system debugging, we sometimes want to know who sets one
> alarm timer, the time of the timer, when the timer started and
> fired and so on. Thus adding tracepoints can help us trace the
> alarmtimer information.
s/one alarm timer/an alarm
* John Stultz wrote:
> From: Chen Yu
>
> Previously we encountered some memory overflow issues due to
> the bogus sleep time brought by inconsistent rtc, which is
> triggered when pm_trace is enabled, and we have fixed it
> in recent kernel.
* John Stultz wrote:
> From: Chen Yu
>
> Previously we encountered some memory overflow issues due to
> the bogus sleep time brought by inconsistent rtc, which is
> triggered when pm_trace is enabled, and we have fixed it
> in recent kernel. However it's improper in the first place
> to call
Commit-ID: 8e8d8725d46d93ceffd3e708d905bc101a1905b5
Gitweb: http://git.kernel.org/tip/8e8d8725d46d93ceffd3e708d905bc101a1905b5
Author: Josh Poimboeuf
AuthorDate: Mon, 28 Nov 2016 17:06:35 -0600
Committer: Ingo Molnar
CommitDate: Tue, 29 Nov 2016
On 11/28/2016, 10:04 PM, Arnd Bergmann wrote:
> Testing with a gcc-7 snapshot produced an internal compiler error
> for this file:
>
> drivers/tty/nozomi.c: In function 'receive_flow_control':
> drivers/tty/nozomi.c:919:12: internal compiler error: in
> get_substring_ranges_for_loc, at
Commit-ID: 8e8d8725d46d93ceffd3e708d905bc101a1905b5
Gitweb: http://git.kernel.org/tip/8e8d8725d46d93ceffd3e708d905bc101a1905b5
Author: Josh Poimboeuf
AuthorDate: Mon, 28 Nov 2016 17:06:35 -0600
Committer: Ingo Molnar
CommitDate: Tue, 29 Nov 2016 08:10:05 +0100
On 11/28/2016, 10:04 PM, Arnd Bergmann wrote:
> Testing with a gcc-7 snapshot produced an internal compiler error
> for this file:
>
> drivers/tty/nozomi.c: In function 'receive_flow_control':
> drivers/tty/nozomi.c:919:12: internal compiler error: in
> get_substring_ranges_for_loc, at
On Tue, 29 Nov 2016 07:21:14 +0800
kbuild test robot <l...@intel.com> wrote:
> Hi Jacob,
>
> [auto build test ERROR on soc-thermal/next]
> [also build test ERROR on v4.9-rc7 next-20161128]
> [if your patch is applied to the wrong git tree, please drop us a
> note to
On Tue, 29 Nov 2016 07:21:14 +0800
kbuild test robot wrote:
> Hi Jacob,
>
> [auto build test ERROR on soc-thermal/next]
> [also build test ERROR on v4.9-rc7 next-20161128]
> [if your patch is applied to the wrong git tree, please drop us a
> note to help improve the system
* Tim Chen wrote:
> > + If unsure say Y here.
> >
> > If/when other architectures make use of this the Kconfig entry can be moved
> > into
> > the scheduler Kconfig - but for the time being it can stay in arch/x86/.
> >
> > Another variant would be to eliminate
* Tim Chen wrote:
> > + If unsure say Y here.
> >
> > If/when other architectures make use of this the Kconfig entry can be moved
> > into
> > the scheduler Kconfig - but for the time being it can stay in arch/x86/.
> >
> > Another variant would be to eliminate the Kconfig option
On Fri, Nov 25, 2016 at 05:57:20PM +0530, Anshuman Khandual wrote:
> On 11/08/2016 05:01 AM, Naoya Horiguchi wrote:
...
> > @@ -497,30 +541,15 @@ static int queue_pages_pte_range(pmd_t *pmd, unsigned
> > long addr,
> > struct page *page;
> > struct queue_pages *qp = walk->private;
> >
On Fri, Nov 25, 2016 at 05:57:20PM +0530, Anshuman Khandual wrote:
> On 11/08/2016 05:01 AM, Naoya Horiguchi wrote:
...
> > @@ -497,30 +541,15 @@ static int queue_pages_pte_range(pmd_t *pmd, unsigned
> > long addr,
> > struct page *page;
> > struct queue_pages *qp = walk->private;
> >
t; Caused by commits
>
> da40e7a4ba4d ("crypto: aes-ce - Convert to skcipher")
> 211f41af534a ("crypto: aesbs - Convert to skcipher")
>
> Missing dependencies?
>
> I have used the crypto tree from next-20161128 for today.
Indeed. This patch should fix the
t; Caused by commits
>
> da40e7a4ba4d ("crypto: aes-ce - Convert to skcipher")
> 211f41af534a ("crypto: aesbs - Convert to skcipher")
>
> Missing dependencies?
>
> I have used the crypto tree from next-20161128 for today.
Indeed. This patch should fix the
This patch enables ACPI support for mux-pca954x driver.
Signed-off-by: Tin Huynh
Change from v1 :
-Don't shadow id variable.
-Include sorted header.
-Redefine acpi_device_id.
-Add CONFIG_ACPI.
---
drivers/i2c/muxes/i2c-mux-pca954x.c | 27 ++-
1
This patch enables ACPI support for mux-pca954x driver.
Signed-off-by: Tin Huynh
Change from v1 :
-Don't shadow id variable.
-Include sorted header.
-Redefine acpi_device_id.
-Add CONFIG_ACPI.
---
drivers/i2c/muxes/i2c-mux-pca954x.c | 27 ++-
1 files changed, 26
From: Peter Zijlstra
Idle injection drivers such as Intel powerclamp and ACPI PAD drivers use
realtime tasks to take control of CPU then inject idle. There are two
issues with this approach:
1. Low efficiency: injected idle task is treated as busy so sched ticks
do
Hello
Since Linux 4.6 (and still in 4.9-rc5 at least), both AMD Bulldozer
cores of a single dual-core compute unit report the same core_id:
$ cat /sys/devices/system/cpu/cpu{?,??}/topology/core_id
0
0
1
1
2
2
3
0
3
[...]
Before 4.5 (and for a very long time), the kernel reported different
From: Peter Zijlstra
Idle injection drivers such as Intel powerclamp and ACPI PAD drivers use
realtime tasks to take control of CPU then inject idle. There are two
issues with this approach:
1. Low efficiency: injected idle task is treated as busy so sched ticks
do not stop during injected
Hello
Since Linux 4.6 (and still in 4.9-rc5 at least), both AMD Bulldozer
cores of a single dual-core compute unit report the same core_id:
$ cat /sys/devices/system/cpu/cpu{?,??}/topology/core_id
0
0
1
1
2
2
3
0
3
[...]
Before 4.5 (and for a very long time), the kernel reported different
When idle injection is used to cap power, we need to override
governor's choice of idle states. This patch allows caller to select
the deepest idle state on a CPU therefore achieve the maximum
potential power saving.
Signed-off-by: Jacob Pan
---
When idle injection is used to cap power, we need to override
governor's choice of idle states. This patch allows caller to select
the deepest idle state on a CPU therefore achieve the maximum
potential power saving.
Signed-off-by: Jacob Pan
---
drivers/cpuidle/cpuidle.c | 13 -
Changelog:
v5: - Fix compile error in cpuidle patch reported by 0-day.
- Reverse patch order for correct dependency.
v4: - Misc comments from Ingo are addressed, including style fix,
timeout handling, fork().
- Dropped powerclamp patch from this set, move to its
Changelog:
v5: - Fix compile error in cpuidle patch reported by 0-day.
- Reverse patch order for correct dependency.
v4: - Misc comments from Ingo are addressed, including style fix,
timeout handling, fork().
- Dropped powerclamp patch from this set, move to its
On Mon, Nov 28, 2016 at 01:49:31PM +, Aniroop Mathur wrote:
> Hello Mr. Vojtech Pavlik,
>
> On 28 Nov 2016 17:23, "vojt...@ucw.cz" wrote:
> >
> > Hi.
> >
> > ADI_INIT_DELAY/ADI_DATA_DELAY doesn't have to be exact, and a longer
> > sleep doesn't matter. In the
On Mon, Nov 28, 2016 at 01:49:31PM +, Aniroop Mathur wrote:
> Hello Mr. Vojtech Pavlik,
>
> On 28 Nov 2016 17:23, "vojt...@ucw.cz" wrote:
> >
> > Hi.
> >
> > ADI_INIT_DELAY/ADI_DATA_DELAY doesn't have to be exact, and a longer
> > sleep doesn't matter. In the initilization sequence -
It takes some time to look for inline stack for callgraph addresses.
So it provides a new option "--inline" to let user decide if enable
this feature.
Signed-off-by: Jin Yao
---
tools/perf/Documentation/perf-report.txt | 4
tools/perf/builtin-report.c
On 28-11-16, 10:27, Stephen Boyd wrote:
> On 11/23/2016 08:40 PM, Viresh Kumar wrote:
> > But even in these cases we wouldn't be using the voltage values within the
> > kernel as we will be giving only a performance state to the M3 core, right?
>
> Nope. In these cases we need to set a certain
It takes some time to look for inline stack for callgraph addresses.
So it provides a new option "--inline" to let user decide if enable
this feature.
Signed-off-by: Jin Yao
---
tools/perf/Documentation/perf-report.txt | 4
tools/perf/builtin-report.c | 2 ++
On 28-11-16, 10:27, Stephen Boyd wrote:
> On 11/23/2016 08:40 PM, Viresh Kumar wrote:
> > But even in these cases we wouldn't be using the voltage values within the
> > kernel as we will be giving only a performance state to the M3 core, right?
>
> Nope. In these cases we need to set a certain
If the address belongs to an inlined function, the source information
back to the first non-inlined function will be printed.
For example:
0.05% test2test2 [.] main
|
---/home/jinyao/perf-dev/test/test2.c:27 (inline)
/home/jinyao/perf-dev/test/test2.c:35
If the address belongs to an inlined function, the source information
back to the first non-inlined function will be printed.
For example:
0.05% test2test2 [.] main
|
---/home/jinyao/perf-dev/test/test2.c:27 (inline)
/home/jinyao/perf-dev/test/test2.c:35
For example:
-0.05% test2test2 [.] main
/home/jinyao/perf-dev/test/test2.c:27 (inline)
/home/jinyao/perf-dev/test/test2.c:35 (inline)
/home/jinyao/perf-dev/test/test2.c:45 (inline)
/home/jinyao/perf-dev/test/test2.c:61 (inline)
Signed-off-by: Jin Yao
For example:
-0.05% test2test2 [.] main
/home/jinyao/perf-dev/test/test2.c:27 (inline)
/home/jinyao/perf-dev/test/test2.c:35 (inline)
/home/jinyao/perf-dev/test/test2.c:45 (inline)
/home/jinyao/perf-dev/test/test2.c:61 (inline)
Signed-off-by: Jin Yao
It would be useful for perf to support a mode to query the
inline stack for callgraph addresses. This would simplify
finding the right code in code that does a lot of inlining.
For example, the c code:
static inline void f3(void)
{
int i;
for (i = 0; i < 1000;) {
It would be useful for perf to support a mode to query the
inline stack for a given callgraph address. This would simplify
finding the right code in code that does a lot of inlining.
The srcline.c has contained the code which supports to translate
the address to filename:line_nr. This patch just
It would be useful for perf to support a mode to query the
inline stack for callgraph addresses. This would simplify
finding the right code in code that does a lot of inlining.
For example, the c code:
static inline void f3(void)
{
int i;
for (i = 0; i < 1000;) {
It would be useful for perf to support a mode to query the
inline stack for a given callgraph address. This would simplify
finding the right code in code that does a lot of inlining.
The srcline.c has contained the code which supports to translate
the address to filename:line_nr. This patch just
On 11/29/2016 02:42 AM, Dave Hansen wrote:
> On 11/22/2016 06:19 AM, Anshuman Khandual wrote:
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -3715,7 +3715,7 @@ struct page *
>> .migratetype = gfpflags_to_migratetype(gfp_mask),
>> };
>>
>> -if (cpusets_enabled()) {
On 11/29/2016 02:42 AM, Dave Hansen wrote:
> On 11/22/2016 06:19 AM, Anshuman Khandual wrote:
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -3715,7 +3715,7 @@ struct page *
>> .migratetype = gfpflags_to_migratetype(gfp_mask),
>> };
>>
>> -if (cpusets_enabled()) {
On Tue, Nov 29, 2016 at 01:11:49AM +0530, Aniroop Mathur wrote:
> msleep(1~20) may not do what the caller intends, and will often sleep longer.
> (~20 ms actual sleep for any value given in the 1~20ms range)
> This is not the desired behaviour for many cases like device resume time,
> device
On Tue, Nov 29, 2016 at 01:11:49AM +0530, Aniroop Mathur wrote:
> msleep(1~20) may not do what the caller intends, and will often sleep longer.
> (~20 ms actual sleep for any value given in the 1~20ms range)
> This is not the desired behaviour for many cases like device resume time,
> device
Fixed a coding style issue
Signed-off-by: Elias Carter
---
drivers/staging/comedi/drivers/cb_pcidda.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers/cb_pcidda.c
b/drivers/staging/comedi/drivers/cb_pcidda.c
index
Fixed a coding style issue
Signed-off-by: Elias Carter
---
drivers/staging/comedi/drivers/cb_pcidda.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers/cb_pcidda.c
b/drivers/staging/comedi/drivers/cb_pcidda.c
index ccb37d1..9874147 100644
On Tue, Nov 29, 2016 at 01:11:31AM +0530, Aniroop Mathur wrote:
> msleep(1~20) may not do what the caller intends, and will often sleep longer.
> (~20 ms actual sleep for any value given in the 1~20ms range)
> This is not the desired behaviour for many cases like device resume time,
> device
Hi John,
Thank you for the patch.
On Monday 28 Nov 2016 21:04:41 John Stultz wrote:
> In chasing down a previous issue with EDID probing from calling
> drm_helper_hpd_irq_event() from irq context, Laurent noticed
> that the DRM documentation suggests that
> drm_kms_helper_hotplug_event() should
On Tue, Nov 29, 2016 at 01:11:31AM +0530, Aniroop Mathur wrote:
> msleep(1~20) may not do what the caller intends, and will often sleep longer.
> (~20 ms actual sleep for any value given in the 1~20ms range)
> This is not the desired behaviour for many cases like device resume time,
> device
Hi John,
Thank you for the patch.
On Monday 28 Nov 2016 21:04:41 John Stultz wrote:
> In chasing down a previous issue with EDID probing from calling
> drm_helper_hpd_irq_event() from irq context, Laurent noticed
> that the DRM documentation suggests that
> drm_kms_helper_hotplug_event() should
On Tue, Nov 29, 2016 at 01:08:22AM +0530, Aniroop Mathur wrote:
> msleep(1~20) may not do what the caller intends, and will often sleep longer.
> (~20 ms actual sleep for any value given in the 1~20ms range)
> This is not the desired behaviour for many cases like device resume time,
> device
On Tue, Nov 29, 2016 at 01:08:22AM +0530, Aniroop Mathur wrote:
> msleep(1~20) may not do what the caller intends, and will often sleep longer.
> (~20 ms actual sleep for any value given in the 1~20ms range)
> This is not the desired behaviour for many cases like device resume time,
> device
'vmw_cotable_alloc()' returns an error pointer on error, not NULL.
Propagate the error code, instead of returning -ENOMEM unconditionally
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 4 ++--
1 file changed, 2 insertions(+), 2
'vmw_cotable_alloc()' returns an error pointer on error, not NULL.
Propagate the error code, instead of returning -ENOMEM unconditionally
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
>
> > > > +
> > > > +/* Note: kernel crypto API realization */
> > > > +static int virtio_crypto_ablkcipher_setkey(struct crypto_ablkcipher
> > > > *tfm,
> > > > +const uint8_t *key,
> > > > +unsigned int keylen)
> >
>
> > > > +
> > > > +/* Note: kernel crypto API realization */
> > > > +static int virtio_crypto_ablkcipher_setkey(struct crypto_ablkcipher
> > > > *tfm,
> > > > +const uint8_t *key,
> > > > +unsigned int keylen)
> >
# sorry for late reply ...
On Fri, Nov 18, 2016 at 02:56:24AM +0300, Kirill A. Shutemov wrote:
> On Tue, Nov 08, 2016 at 08:31:52AM +0900, Naoya Horiguchi wrote:
> > If one of callers of page migration starts to handle thp, memory management
> > code
> > start to see pmd migration entry, so we
# sorry for late reply ...
On Fri, Nov 18, 2016 at 02:56:24AM +0300, Kirill A. Shutemov wrote:
> On Tue, Nov 08, 2016 at 08:31:52AM +0900, Naoya Horiguchi wrote:
> > If one of callers of page migration starts to handle thp, memory management
> > code
> > start to see pmd migration entry, so we
Hi John,
Thank you for the patch.
On Monday 28 Nov 2016 21:04:40 John Stultz wrote:
> I was recently seeing issues with EDID probing, where
> the logic to wait for the EDID read bit to be set by the
> IRQ wasn't happening and the code would time out and fail.
>
> Digging deeper, I found this
Hi John,
Thank you for the patch.
On Monday 28 Nov 2016 21:04:40 John Stultz wrote:
> I was recently seeing issues with EDID probing, where
> the logic to wait for the EDID read bit to be set by the
> IRQ wasn't happening and the code would time out and fail.
>
> Digging deeper, I found this
Execution 'ethtool -S' on fec device that is down causes OOPS on Vybrid
board:
Unhandled fault: external abort on non-linefetch (0x1008) at 0xe0898200
pgd = ddecc000
[e0898200] *pgd=9e406811, *pte=400d1653, *ppte=400d1453
Internal error: : 1008 [#1] SMP ARM
...
Reason of OOPS is that
Execution 'ethtool -S' on fec device that is down causes OOPS on Vybrid
board:
Unhandled fault: external abort on non-linefetch (0x1008) at 0xe0898200
pgd = ddecc000
[e0898200] *pgd=9e406811, *pte=400d1653, *ppte=400d1453
Internal error: : 1008 [#1] SMP ARM
...
Reason of OOPS is that
This patch adds infrastructure to manage multiple regulators and updates
the only user (cpufreq-dt) of dev_pm_opp_set{put}_regulator().
This is preparatory work for adding full support for devices with
multiple regulators.
Signed-off-by: Viresh Kumar
Tested-by: Dave
The generic set_opp() handler isn't sufficient for platforms with
complex DVFS. For example, some TI platforms have multiple regulators
for a CPU device. The order in which various supplies need to be
programmed is only known to the platform code and its best to leave it
to it.
This patch
This is a preparatory step for multiple regulator per device support.
Move the voltage/current variables to a new structure.
Signed-off-by: Viresh Kumar
Tested-by: Dave Gerlach
Reviewed-by: Stephen Boyd
---
The generic set_opp() handler isn't sufficient for platforms with
complex DVFS. For example, some TI platforms have multiple regulators
for a CPU device. The order in which various supplies need to be
programmed is only known to the platform code and its best to leave it
to it.
This patch
1 - 100 of 1846 matches
Mail list logo