On Mon, Sep 05, 2016 at 01:12:05PM +0800, Hui Zhu wrote:
> On Mon, Sep 5, 2016 at 10:18 AM, Minchan Kim wrote:
> > On Thu, Aug 25, 2016 at 04:25:30PM +0800, Hui Zhu wrote:
> >> On Thu, Aug 25, 2016 at 2:09 PM, Sergey Senozhatsky
> >> wrote:
On Mon, Sep 05, 2016 at 01:12:05PM +0800, Hui Zhu wrote:
> On Mon, Sep 5, 2016 at 10:18 AM, Minchan Kim wrote:
> > On Thu, Aug 25, 2016 at 04:25:30PM +0800, Hui Zhu wrote:
> >> On Thu, Aug 25, 2016 at 2:09 PM, Sergey Senozhatsky
> >> wrote:
> >> > Hello,
> >> >
> >> > On (08/22/16 16:25), Hui
On Sun, Sep 04, 2016 at 02:14:06PM -0600, Jason Gunthorpe wrote:
> On Sat, Sep 03, 2016 at 09:26:05AM +0300, Jarkko Sakkinen wrote:
> > >
> > > OK, how would one get the chip instance?
>
> Most subsystems have a get function that returns a kref'd pointer. For
> TPM all we really need today is a
On Sun, Sep 04, 2016 at 02:14:06PM -0600, Jason Gunthorpe wrote:
> On Sat, Sep 03, 2016 at 09:26:05AM +0300, Jarkko Sakkinen wrote:
> > >
> > > OK, how would one get the chip instance?
>
> Most subsystems have a get function that returns a kref'd pointer. For
> TPM all we really need today is a
Hi Binoy
On 09/02/2016 02:37 PM, Binoy Jayan wrote:
> The field 'cpu' although part of the set of generic fields, is not made
> part of the key fields when mentioned in the trigger command. This hack
> suggested by Daniel marks it as one of the key fields and make it appear
> in the histogram
Hi Binoy
On 09/02/2016 02:37 PM, Binoy Jayan wrote:
> The field 'cpu' although part of the set of generic fields, is not made
> part of the key fields when mentioned in the trigger command. This hack
> suggested by Daniel marks it as one of the key fields and make it appear
> in the histogram
On 2016年09月02日 22:21, Tejun Heo wrote:
On Fri, Sep 02, 2016 at 09:50:07AM -0400, Tejun Heo wrote:
Hello,
On Fri, Sep 02, 2016 at 09:17:04AM +0800, qiaozhou wrote:
I don't know whether it's meaningful to still check pending work here, or
it's not suggested to use pm_qos_update_request in this
On 2016年09月02日 22:21, Tejun Heo wrote:
On Fri, Sep 02, 2016 at 09:50:07AM -0400, Tejun Heo wrote:
Hello,
On Fri, Sep 02, 2016 at 09:17:04AM +0800, qiaozhou wrote:
I don't know whether it's meaningful to still check pending work here, or
it's not suggested to use pm_qos_update_request in this
On Wed, Nov 25, 2015 at 05:41:25PM +0800, Jisheng Zhang wrote:
> This patch adds S2R support for berlin pwm driver.
>
> Signed-off-by: Jisheng Zhang
> ---
> Since v1:
> - implement .request and .free hooks, allocate/free the channel in
>
On Wed, Nov 25, 2015 at 05:41:25PM +0800, Jisheng Zhang wrote:
> This patch adds S2R support for berlin pwm driver.
>
> Signed-off-by: Jisheng Zhang
> ---
> Since v1:
> - implement .request and .free hooks, allocate/free the channel in
>berlin_pwm_request/berlin_pwm_free. Then use
Actual values for default configs of 'colors' section is like below.
(at ui/browser.c)
static struct ui_browser_colorset {
const char *name, *fg, *bg;
int colorset;
} ui_browser__colorsets[] = {
{
.colorset = HE_COLORSET_TOP,
.name =
Actual values for default configs of 'annotate' section is like below.
(at ui/browsers/annoate.c)
static struct annotate_browser_opt {
bool hide_src_code,
use_offset,
jump_arrows,
show_linenr,
show_nr_jumps,
Actual values for default configs of 'annotate' section is like below.
(at ui/browsers/annoate.c)
static struct annotate_browser_opt {
bool hide_src_code,
use_offset,
jump_arrows,
show_linenr,
show_nr_jumps,
Actual values for default configs of 'colors' section is like below.
(at ui/browser.c)
static struct ui_browser_colorset {
const char *name, *fg, *bg;
int colorset;
} ui_browser__colorsets[] = {
{
.colorset = HE_COLORSET_TOP,
.name =
In near future, default_config_item arrays will be added
(e.g. const struct default_config_item colors_config_items[])
To simply assign config key-value pairs to default_config_item,
add macros that are CONF_VAR() and CONF_*_VAR() for each type.
Cc: Namhyung Kim
Cc: Jiri
Set default config values for 'colors' section with 'colors_config_items[]'
instead of actual const char * type values.
(e.g. using colors_config_item[CONFIG_COLORS_TOP].value.s
instead of "red, default" string value for 'colors.top')
Cc: Namhyung Kim
Cc: Jiri Olsa
In near future, default_config_item arrays will be added
(e.g. const struct default_config_item colors_config_items[])
To simply assign config key-value pairs to default_config_item,
add macros that are CONF_VAR() and CONF_*_VAR() for each type.
Cc: Namhyung Kim
Cc: Jiri Olsa
Cc: Wang Nan
Cc:
Set default config values for 'colors' section with 'colors_config_items[]'
instead of actual const char * type values.
(e.g. using colors_config_item[CONFIG_COLORS_TOP].value.s
instead of "red, default" string value for 'colors.top')
Cc: Namhyung Kim
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc:
To easily set default config values into actual variables for 'colors' config,
it would be better that actual variables for each 'colors' config
have only one value like 'default_config_item' type.
If we use combined {fore,back}ground colors values in ui_browser_colorset,
it smoothly work to
Set default config values for 'annotate' section with 'annotate_config_items[]'
instead of actual bool type values.
(e.g. using annotate_config_items[CONFIG_ANNOTATE_USE_OFFSET].value.b
instead of 'true' bool type value for 'annotate.use_offset'.)
Cc: Namhyung Kim
Cc: Jiri
To easily set default config values into actual variables for 'colors' config,
it would be better that actual variables for each 'colors' config
have only one value like 'default_config_item' type.
If we use combined {fore,back}ground colors values in ui_browser_colorset,
it smoothly work to
Set default config values for 'annotate' section with 'annotate_config_items[]'
instead of actual bool type values.
(e.g. using annotate_config_items[CONFIG_ANNOTATE_USE_OFFSET].value.b
instead of 'true' bool type value for 'annotate.use_offset'.)
Cc: Namhyung Kim
Cc: Jiri Olsa
Cc: Masami
When initializing default perf config values,
we currently use values of actual type(int, bool, char *, etc.).
For example,
If there isn't a user config value for 'annotate.use_offset'
config variable at ~/.perfconfig,
default value for it is 'true' bool type value in perf like below.
At
Hello, :)
When initializing default perf config values,
we currently use values of actual type(int, bool, char *, etc.).
But I suggest using default config key-value pairs arrays.
For example,
If there isn't a user config value for 'annotate.use_offset'
config variable at ~/.perfconfig,
default
When initializing default perf config values,
we currently use values of actual type(int, bool, char *, etc.).
For example,
If there isn't a user config value for 'annotate.use_offset'
config variable at ~/.perfconfig,
default value for it is 'true' bool type value in perf like below.
At
Hello, :)
When initializing default perf config values,
we currently use values of actual type(int, bool, char *, etc.).
But I suggest using default config key-value pairs arrays.
For example,
If there isn't a user config value for 'annotate.use_offset'
config variable at ~/.perfconfig,
default
On Mon, Sep 05, 2016 at 06:38:21AM +0200, Christophe JAILLET wrote:
> Le 04/09/2016 à 20:23, Leon Romanovsky a écrit :
> >On Sun, Sep 04, 2016 at 05:57:20PM +0200, Christophe JAILLET wrote:
> >>Le 04/09/2016 à 14:20, Leon Romanovsky a écrit :
> >>>On Sat, Sep 03, 2016 at 07:33:29AM +0200,
On Tue, Mar 29, 2016 at 08:55:45PM +0200, Paul Kocialkowski wrote:
> The current TWL6030 code for the TWL PWM driver does not reliably disable the
> PWM output, as tested with LEDs. The previous commit to that driver introduced
> that regression.
>
> However, it does make sense to disable the PWM
On Mon, Sep 05, 2016 at 06:38:21AM +0200, Christophe JAILLET wrote:
> Le 04/09/2016 à 20:23, Leon Romanovsky a écrit :
> >On Sun, Sep 04, 2016 at 05:57:20PM +0200, Christophe JAILLET wrote:
> >>Le 04/09/2016 à 14:20, Leon Romanovsky a écrit :
> >>>On Sat, Sep 03, 2016 at 07:33:29AM +0200,
On Tue, Mar 29, 2016 at 08:55:45PM +0200, Paul Kocialkowski wrote:
> The current TWL6030 code for the TWL PWM driver does not reliably disable the
> PWM output, as tested with LEDs. The previous commit to that driver introduced
> that regression.
>
> However, it does make sense to disable the PWM
On Mon, Sep 5, 2016 at 10:18 AM, Minchan Kim wrote:
> On Thu, Aug 25, 2016 at 04:25:30PM +0800, Hui Zhu wrote:
>> On Thu, Aug 25, 2016 at 2:09 PM, Sergey Senozhatsky
>> wrote:
>> > Hello,
>> >
>> > On (08/22/16 16:25), Hui Zhu wrote:
>> >>
On Mon, Sep 5, 2016 at 10:18 AM, Minchan Kim wrote:
> On Thu, Aug 25, 2016 at 04:25:30PM +0800, Hui Zhu wrote:
>> On Thu, Aug 25, 2016 at 2:09 PM, Sergey Senozhatsky
>> wrote:
>> > Hello,
>> >
>> > On (08/22/16 16:25), Hui Zhu wrote:
>> >>
>> >> Current ZRAM just can store all pages even if the
This patch adds the documentation for rockchip dfi devfreq-event driver.
Signed-off-by: Lin Huang
Acked-by: Chanwoo Choi
---
Changes in v10:
- None
Changes in v9:
- reorder compatible and reg
Changes in v8:
- delete a unuse blank line
Changes in
base on dfi result, we do ddr frequency scaling, register
dmc driver to devfreq framework, and use simple-ondemand
policy.
Signed-off-by: Lin Huang
Signed-off-by: MyngJoo Ham
Reviewed-by: Chanwoo Choi
---
Changes in v10:
-
This patch adds the documentation for rockchip rk3399 dmc driver.
Signed-off-by: Lin Huang
Reviewed-by: Chanwoo Choi
---
Changes in v10:
- add rockchip prefix in property describe
Changes in v9:
- add ddr timing property to node
Changes in v8:
- add
This patch adds the documentation for rockchip dfi devfreq-event driver.
Signed-off-by: Lin Huang
Acked-by: Chanwoo Choi
---
Changes in v10:
- None
Changes in v9:
- reorder compatible and reg
Changes in v8:
- delete a unuse blank line
Changes in v7:
- None
Changes in v6:
- None
Changes in
base on dfi result, we do ddr frequency scaling, register
dmc driver to devfreq framework, and use simple-ondemand
policy.
Signed-off-by: Lin Huang
Signed-off-by: MyngJoo Ham
Reviewed-by: Chanwoo Choi
---
Changes in v10:
- None
Changes in v9:
- None
Changes in v8:
- None
Changes in v8:
- do
This patch adds the documentation for rockchip rk3399 dmc driver.
Signed-off-by: Lin Huang
Reviewed-by: Chanwoo Choi
---
Changes in v10:
- add rockchip prefix in property describe
Changes in v9:
- add ddr timing property to node
Changes in v8:
- add ddr timing properties
Changes in v7:
-
rk3399 platform have dfi controller can monitor ddr load,
and dcf controller to handle ddr register so we can get the
right ddr frequency and make ddr controller happy work(which
will implement in bl31). So we do ddr frequency scaling with
following flow:
kernel
rk3399 platform have dfi controller can monitor ddr load,
and dcf controller to handle ddr register so we can get the
right ddr frequency and make ddr controller happy work(which
will implement in bl31). So we do ddr frequency scaling with
following flow:
kernel
on rk3399 platform, there is dfi conroller can monitor
ddr load, base on this result, we can do ddr freqency
scaling.
Signed-off-by: Lin Huang
Signed-off-by: MyungJoo Ham
Acked-by: Chanwoo Choi
---
Changes in v10:
-None
when in ddr frequency scaling process, vop can not do enable or
disable operation, since in dcf we check vop clock to see whether
vop work. If vop work, dcf do ddr frequency scaling when vop
in vblank status, and we need to read vop register to check whether
vop go into vblank status. If vop not
on rk3399 platform, there is dfi conroller can monitor
ddr load, base on this result, we can do ddr freqency
scaling.
Signed-off-by: Lin Huang
Signed-off-by: MyungJoo Ham
Acked-by: Chanwoo Choi
---
Changes in v10:
-None
Changes in v9:
-None
Changes in v8:
-None
Changes in v7:
-access need
when in ddr frequency scaling process, vop can not do enable or
disable operation, since in dcf we check vop clock to see whether
vop work. If vop work, dcf do ddr frequency scaling when vop
in vblank status, and we need to read vop register to check whether
vop go into vblank status. If vop not
fix the following code:
-ret = expression;
-if (ret)
-return ret;
-return 0;
+return expression;
From: Masahiro Yamada
posted on the U-Boot mailinglist.
Signed-off-by: Heiko Schocher
---
fs/ubifs/budget.c | 7 ++-
fs/ubifs/gc.c
fix the following code:
-ret = expression;
-if (ret)
-return ret;
-return 0;
+return expression;
From: Masahiro Yamada
posted on the U-Boot mailinglist.
Signed-off-by: Heiko Schocher
---
fs/ubifs/budget.c | 7 ++-
fs/ubifs/gc.c | 6 ++
fs/ubifs/lpt_commit.c | 5
Hi Shaohua,
Today's linux-next merge of the md tree got a conflict in:
include/linux/raid/pq.h
between commit:
f5b55fa1f81d ("RAID/s390: provide raid6 recovery optimization")
from the s390 tree and commit:
a5e49b04af05 ("lib/raid6: Add AVX512 optimized recovery functions")
from the md
Hi Shaohua,
Today's linux-next merge of the md tree got a conflict in:
include/linux/raid/pq.h
between commit:
f5b55fa1f81d ("RAID/s390: provide raid6 recovery optimization")
from the s390 tree and commit:
a5e49b04af05 ("lib/raid6: Add AVX512 optimized recovery functions")
from the md
The NanoPi NEO is a minimal H3 based SBC. It comes with 256/512M RAM, a
micro SD slot, 10/100Mbit ethernet and a single USB-A port.
Signed-off-by: James Pettigrew
---
Changes in v3:
Fixed syntax errors
---
.../devicetree/bindings/vendor-prefixes.txt| 1 +
The NanoPi NEO is a minimal H3 based SBC. It comes with 256/512M RAM, a
micro SD slot, 10/100Mbit ethernet and a single USB-A port.
Signed-off-by: James Pettigrew
---
Changes in v3:
Fixed syntax errors
---
.../devicetree/bindings/vendor-prefixes.txt| 1 +
arch/arm/boot/dts/Makefile
2016-09-02 (金) の 09:35 -0400 に Josef Bacik さんは書きました:
> On 09/02/2016 03:46 AM, Naohiro Aota wrote:
> >
> > Currently, btrfs_relocate_chunk() is removing relocated BG by
> > itself. But
> > the work can be done by btrfs_delete_unused_bgs() (and it's better
> > since it
> > trim the BG). Let's
2016-09-02 (金) の 09:35 -0400 に Josef Bacik さんは書きました:
> On 09/02/2016 03:46 AM, Naohiro Aota wrote:
> >
> > Currently, btrfs_relocate_chunk() is removing relocated BG by
> > itself. But
> > the work can be done by btrfs_delete_unused_bgs() (and it's better
> > since it
> > trim the BG). Let's
Correct typo from 'destory' to 'destroy'.
Signed-off-by: Chao Yu
---
fs/f2fs/segment.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 93c5e26..ff4b723 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
Correct typo from 'destory' to 'destroy'.
Signed-off-by: Chao Yu
---
fs/f2fs/segment.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 93c5e26..ff4b723 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -2678,7 +2678,7
Some applications may create multimeida file with temporary name like
'*.jpg.tmp' or '*.mp4.tmp', then rename to '*.jpg' or '*.mp4'.
Now, f2fs can only detect multimedia filename with specified format:
"filename + '.' + extension", so it will make f2fs missing to detect
multimedia file with
Some applications may create multimeida file with temporary name like
'*.jpg.tmp' or '*.mp4.tmp', then rename to '*.jpg' or '*.mp4'.
Now, f2fs can only detect multimedia filename with specified format:
"filename + '.' + extension", so it will make f2fs missing to detect
multimedia file with
Hi Stephen,
2016-08-30 3:22 GMT+09:00 Stephen Boyd :
> On 08/29, Masahiro Yamada wrote:
>> Hi Stephen,
>>
>>
>> 2016-08-20 4:16 GMT+09:00 Stephen Boyd :
>> >>
>> >> >> +
>> >> >> + parent = of_get_parent(dev->of_node); /* parent should be syscon
Hi Stephen,
2016-08-30 3:22 GMT+09:00 Stephen Boyd :
> On 08/29, Masahiro Yamada wrote:
>> Hi Stephen,
>>
>>
>> 2016-08-20 4:16 GMT+09:00 Stephen Boyd :
>> >>
>> >> >> +
>> >> >> + parent = of_get_parent(dev->of_node); /* parent should be syscon
>> >> >> node */
>> >> >> + regmap =
Hello,
On (09/05/16 11:18), Minchan Kim wrote:
[..]
> If I understand Sergey's point right, he means there is no gain
> to save memory between before and after.
>
> With your approach, you can prevent unnecessary pageout(i.e.,
> uncompressible page swap out) but it doesn't mean you save the
>
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu.h
between commit:
566153874951 ("drm/amdgpu: fix lru size grouping v2")
from Linus' tree and commit:
c632d7994360 ("amdgpu: move ttm stuff to amdgpu_ttm.h")
from the drm tree.
I
Hello,
On (09/05/16 11:18), Minchan Kim wrote:
[..]
> If I understand Sergey's point right, he means there is no gain
> to save memory between before and after.
>
> With your approach, you can prevent unnecessary pageout(i.e.,
> uncompressible page swap out) but it doesn't mean you save the
>
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu.h
between commit:
566153874951 ("drm/amdgpu: fix lru size grouping v2")
from Linus' tree and commit:
c632d7994360 ("amdgpu: move ttm stuff to amdgpu_ttm.h")
from the drm tree.
I
On Fri, Sep 02, 2016 at 11:25:27AM -0500, Bjorn Helgaas wrote:
> On Wed, Aug 24, 2016 at 04:17:31PM +0200, Lukas Wunner wrote:
> > On Fri, Aug 19, 2016 at 04:30:25PM +0800, Chen Yu wrote:
> > > People reported that they can not do a poweroff nor a
> > > suspend to ram on their Mac Pro 11. After
On Fri, Sep 02, 2016 at 11:25:27AM -0500, Bjorn Helgaas wrote:
> On Wed, Aug 24, 2016 at 04:17:31PM +0200, Lukas Wunner wrote:
> > On Fri, Aug 19, 2016 at 04:30:25PM +0800, Chen Yu wrote:
> > > People reported that they can not do a poweroff nor a
> > > suspend to ram on their Mac Pro 11. After
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/drm_crtc.c
between commit:
6f00975c6190 ("drm: Reject page_flip for !DRIVER_MODESET")
from Linus' tree and commit:
f837297ad824 ("drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2")
from
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/drm_crtc.c
between commit:
6f00975c6190 ("drm: Reject page_flip for !DRIVER_MODESET")
from Linus' tree and commit:
f837297ad824 ("drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2")
from
On Thu, Sep 1, 2016 at 10:16 PM, Maxime Ripard
wrote:
> Add support for the class with a single factor, N, being a multiplier.
>
> Signed-off-by: Maxime Ripard
Acked-by: Chen-Yu Tsai
On Thu, Sep 1, 2016 at 10:16 PM, Maxime Ripard
wrote:
> Add support for the class with a single factor, N, being a multiplier.
>
> Signed-off-by: Maxime Ripard
Acked-by: Chen-Yu Tsai
The origin of the issue I've seen is related to
a missing memory barrier between check for task->state and
the check for task->on_rq.
The task being woken up is already awake from a schedule()
and is doing the following
do {
schedule()
set_current_state(TASK_(UN)INTERRUPTIBLE);
The origin of the issue I've seen is related to
a missing memory barrier between check for task->state and
the check for task->on_rq.
The task being woken up is already awake from a schedule()
and is doing the following
do {
schedule()
set_current_state(TASK_(UN)INTERRUPTIBLE);
On Fri, Sep 02, 2016 at 06:42:43PM +0200, Clemens Gruber wrote:
> On Fri, Sep 02, 2016 at 09:55:52AM +0800, Peter Chen wrote:
> > Do you have other 5V to USB_H1_VBUS? USB PHY needs 5V input voltage
> > as the source for USB LDO (3.0v), either from OTG or Host 1. I suspect
> > the lower vbus
On Fri, Sep 02, 2016 at 06:42:43PM +0200, Clemens Gruber wrote:
> On Fri, Sep 02, 2016 at 09:55:52AM +0800, Peter Chen wrote:
> > Do you have other 5V to USB_H1_VBUS? USB PHY needs 5V input voltage
> > as the source for USB LDO (3.0v), either from OTG or Host 1. I suspect
> > the lower vbus
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/mediatek/mtk_eth_soc.c
between commits:
d3bd1ce4db8e ("net: ethernet: mediatek: remove redundant free_irq for
devm_request_irq allocated irq")
7c6b0d76fa02 ("net: ethernet: mediatek: fix logic
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/mediatek/mtk_eth_soc.c
between commits:
d3bd1ce4db8e ("net: ethernet: mediatek: remove redundant free_irq for
devm_request_irq allocated irq")
7c6b0d76fa02 ("net: ethernet: mediatek: fix logic
On Mon, Aug 08, 2016 at 03:05:39PM +0200, Tomasz Nowicki wrote:
> Some platforms may not be fully compliant with generic set of PCI config
> accessors. For these cases we implement the way to overwrite accessors
> set. Algorithm traverses available quirk list (static array),
> matches against
On Mon, Aug 08, 2016 at 03:05:39PM +0200, Tomasz Nowicki wrote:
> Some platforms may not be fully compliant with generic set of PCI config
> accessors. For these cases we implement the way to overwrite accessors
> set. Algorithm traverses available quirk list (static array),
> matches against and
On Fri, Sep 02, 2016 at 06:03:06PM -0700, Stephen Boyd wrote:
> On Thu, Sep 1, 2016 at 8:17 PM, Peter Chen wrote:
> > On Wed, Aug 31, 2016 at 05:40:24PM -0700, Stephen Boyd wrote:
> >>
> >>
> >> if (cable->state)
> >> - val |= OTGSC_ID;
>
On Fri, Sep 02, 2016 at 06:03:06PM -0700, Stephen Boyd wrote:
> On Thu, Sep 1, 2016 at 8:17 PM, Peter Chen wrote:
> > On Wed, Aug 31, 2016 at 05:40:24PM -0700, Stephen Boyd wrote:
> >>
> >>
> >> if (cable->state)
> >> - val |= OTGSC_ID;
> >> +
On Fri, Sep 02, 2016 at 10:34:40AM +0200, Martin Kaiser wrote:
> Signed-off-by: Martin Kaiser
Applied, thanks.
> ---
> arch/arm/mach-imx/hardware.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-imx/hardware.h
On Fri, Sep 02, 2016 at 10:34:40AM +0200, Martin Kaiser wrote:
> Signed-off-by: Martin Kaiser
Applied, thanks.
> ---
> arch/arm/mach-imx/hardware.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-imx/hardware.h b/arch/arm/mach-imx/hardware.h
> index
>From 99e428a1808c8ca91ff473d487b52ca5d355d875 Mon Sep 17 00:00:00 2001
From: Chunfeng Yun
Date: Mon, 5 Sep 2016 10:27:07 +0800
Subject: [PATCH, v6 0/5] Add MediaTek USB3 DRD Driver
These patches introduce the MediaTek USB3 dual-role controller
driver.
The driver can
>From 99e428a1808c8ca91ff473d487b52ca5d355d875 Mon Sep 17 00:00:00 2001
From: Chunfeng Yun
Date: Mon, 5 Sep 2016 10:27:07 +0800
Subject: [PATCH, v6 0/5] Add MediaTek USB3 DRD Driver
These patches introduce the MediaTek USB3 dual-role controller
driver.
The driver can be configured as Dual-Role
USB3 DRD driver is added for MT8173-EVB, and xHCI driver
becomes its subnode
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 46 +--
arch/arm64/boot/dts/mediatek/mt8173.dtsi| 29 +
2 files
Some resources, such as IPPC register etc, shared with device
driver are moved into common glue layer when xHCI driver is the
host side of dual-role mode and they should be changed as optional
properties if they are required ones before. For clarity, add
a new part of binding to support host side
Hi James,
[auto build test ERROR on mripard/sunxi/for-next]
[also build test ERROR on v4.8-rc5 next-20160825]
[cannot apply to robh/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or
USB3 DRD driver is added for MT8173-EVB, and xHCI driver
becomes its subnode
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 46 +--
arch/arm64/boot/dts/mediatek/mt8173.dtsi| 29 +
2 files changed, 66 insertions(+), 9
Some resources, such as IPPC register etc, shared with device
driver are moved into common glue layer when xHCI driver is the
host side of dual-role mode and they should be changed as optional
properties if they are required ones before. For clarity, add
a new part of binding to support host side
Hi James,
[auto build test ERROR on mripard/sunxi/for-next]
[also build test ERROR on v4.8-rc5 next-20160825]
[cannot apply to robh/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or
add a DT binding doc for MediaTek USB3 DRD driver
Signed-off-by: Chunfeng Yun
Acked-by: Rob Herring
---
.../devicetree/bindings/usb/mt8173-mtu3.txt| 87
1 file changed, 87 insertions(+)
create mode 100644
add a DT binding doc for MediaTek USB3 DRD driver
Signed-off-by: Chunfeng Yun
Acked-by: Rob Herring
---
.../devicetree/bindings/usb/mt8173-mtu3.txt| 87
1 file changed, 87 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
This patch adds support for the MediaTek USB3 controller
integrated into MT8173. It can be configured as Dual-Role
Device (DRD), Peripheral Only and Host Only (xHCI) modes.
Signed-off-by: Chunfeng Yun
---
drivers/usb/Kconfig|2 +
This patch adds support for the MediaTek USB3 controller
integrated into MT8173. It can be configured as Dual-Role
Device (DRD), Peripheral Only and Host Only (xHCI) modes.
Signed-off-by: Chunfeng Yun
---
drivers/usb/Kconfig|2 +
drivers/usb/Makefile |1 +
Make IPPC register optional to support host side of dual-role mode,
due to it is moved into common glue layer for simplification.
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c | 36 +---
1 file changed, 29 insertions(+),
Make IPPC register optional to support host side of dual-role mode,
due to it is moved into common glue layer for simplification.
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c | 36 +---
1 file changed, 29 insertions(+), 7 deletions(-)
diff --git
On Mon, Aug 08, 2016 at 03:05:41PM +0200, Tomasz Nowicki wrote:
> Add infrastructure to support ThunderX PEM specific PCI configuration space
> access for ACPI based PCI host controller. This involves:
> 1. New initialization call thunder_pem_cfg_init() to create configuration
> space mapping
On Mon, Aug 08, 2016 at 03:05:41PM +0200, Tomasz Nowicki wrote:
> Add infrastructure to support ThunderX PEM specific PCI configuration space
> access for ACPI based PCI host controller. This involves:
> 1. New initialization call thunder_pem_cfg_init() to create configuration
> space mapping
On Wed, Aug 31, 2016 at 12:00:29PM -0500, Zhengyu Shen wrote:
> MMDC is a multi-mode DDR controller that supports DDR3/DDR3L x16/x32/x64
> and LPDDR2 two channel x16/x32 memory types. MMDC is configurable, high
> performance, and optimized. MMDC is present on i.MX6 Quad and i.MX6
> QuadPlus
On Wed, Aug 31, 2016 at 12:00:29PM -0500, Zhengyu Shen wrote:
> MMDC is a multi-mode DDR controller that supports DDR3/DDR3L x16/x32/x64
> and LPDDR2 two channel x16/x32 memory types. MMDC is configurable, high
> performance, and optimized. MMDC is present on i.MX6 Quad and i.MX6
> QuadPlus
Hi Joe,
On Sun, Sep 04, 2016 at 07:18:22PM -0700, Joe Perches wrote:
On Mon, 2016-09-05 at 10:13 +0800, kbuild test robot wrote:
Hi Joe,
Hi Fengguang
FYI, the error/warning still remains.
Is this really my responsibility?
I don't think so.
I didn't submit this patch to stable.
I don't
Hi Joe,
On Sun, Sep 04, 2016 at 07:18:22PM -0700, Joe Perches wrote:
On Mon, 2016-09-05 at 10:13 +0800, kbuild test robot wrote:
Hi Joe,
Hi Fengguang
FYI, the error/warning still remains.
Is this really my responsibility?
I don't think so.
I didn't submit this patch to stable.
I don't
1 - 100 of 580 matches
Mail list logo